Cellphones are many people's only internet access now. I probably won't ever go android again, and probably will never buy an iphone either, but would be interested in seeing a non-apple phone forum. I switched from my first android / first smartphone to BlackBerry a couple long years ago, and am hooked on my malware-free, hacker-free existence now, nothing could make it better for me except a BlackBerry laptop or desktop ; )

I don't know what it takes to start a forum here besides a willing moderator and enough interest.

Oh well. If I had more free time I'd take on running a forum.

Loving my Galaxy s7 My home computer is an iMac.

Ever since getting my Galaxy S8 I've been looking for more apps but not sure which ones are 'safe'. It would be good to hear what others have to say.

I've got a background in PCs, electronics, mainly a STEM education, started building PCs in the 1980s, learned Unix in the 90s and just this year got a couple of Android smart-phones. I build PCs from parts, have Linux running on my systems mainly, including a firewall/router box. What do I think of Android after using a couple of hand-helds for about 6 months now? Basically Android is Linux, just coded for ARM CPUs. I've caught mistakes made in how the devices I have were set up originally. Unfortunately the mistakes made in the devices I own/fixed reflect a sentiment based on the end-user experience perspective, what used to be called a GUI-centric perspective. That is, the developers of the devices/engineers/designers tried to configure the smart-phones to function as mini-Windows/Apple GUI interface heavy devices. With low-power ARM CPU based devices this is a mistake, as the ARM processors are RISC chips, reduced instruction-set computing processors. As such the code for running such devices, operating system & programs (colloquially called "apps" by Android users, etc) tends to be a bit more "dense" than for PCs which are built with CISC CPUs (complex instruction-set computing). Suffice it to say what ARM devices lack in on-chip processing power they make up for by loading the code they run with the microcode instructions the ARM CPU architecture lacks in order for the code to be run by the processors. The problem with this is it causes ARM based devices to run slower in a side-by-side comparison with PCs running Linux, Unix or Windows. The advantage to running ARM is the thriftiness of the architecture compared to CISC style chips made by Intel or AMD. There's no comparison between the amount of power an ARM based device sips by comparison to an x86/x86_64/IA64 based hand-held device. My worst Android smart-phone will easily run for 7 hours on a charge. Try to get an AMD or Intel based laptop to run that long. It's not possible because the CISC design of the systems and the code they run consume way too much power by comparison to the ARM design (by 2x as much)

But back to the flaws in the smart-phones I got this year. The main problem I found is the people setting the phones up to behave similarly to Apple or Windows PCs, emulating the smooth functionality of the GUI interface on PCs. This Imo is a mistake when done to Android devices powered by ARM processors. There's just not enough "horsepower" (to borrow a term) in ARM CPUs, even multi-core ARM CPUs, to do this to Android smart-phones. The effect of enabling "smooth" video transitions in the GUI interfaces of Androids causes a huge load on the CPU cores. In both my Android devices eventually I was forced to enable Developer Mode in them & get into the video/GUI settings in those options & turn *off* such smooth video transitioning types of settings. Also in both devices I found the original engineers/developers had actually enabled video processing to be done by the ARM CPU rather than the on-system graphics processor (GPU is the term for the graphics processor). I understand why this was done, the ARM CPU is way more energy efficient at processing video than the GPU, battery life is greatly extended this way, however setting Androids this way greatly overloads an already overworked chip architecture, which has denser code it has to crunch through in order to execute instructions as if the CPU was running a PC rather than a hand-held computer which fits in the palm of its users hands. Just with those 2 small changes I greatly sped up the performance of my Android devices, to the point where now they actually remind me of small hand-held versions of PCs running Linux, rather than overloaded systems struggling to execute dense code while also processing, audio, video, networking, etc. The downside to those small changes? The battery life on both devices dropped from 8 & 19 hours to 4 hours & 11 hours respectively (based on their respective battery sizes). The upside? Cold start times under 30 seconds to under 1 minute range, switching between running apps in about 1 second, apps minimizing almost instantly, apps opening in 30 seconds at most now, systems that are able to easily be brought under control now whenever an app starts misbehaving. Iow, hand-held devices that are actually operable, as if they were miniature PCs, which to my mind based on my education & experience, technically they are

My complaint over the Androids? The dearth of hard code tweaking information about the system online. I've found a lot of programmer forums & code for writing apps, not so much for tuning/tweaking/customizing the operating system itself. I consider this a problem, for Linux has been out since the early 90s and there have been volumes written about how to go about customizing it on the kernel mode level. I understand Android is Google's proprietary version of Linux & they frown on rooting devices running the OS, but I'd like to try some tweaks I routinely do with my Linux based servers & PCs for ARM because I like to experiment/tweak, & I believe the platform can be improved greatly with some simple changes in the start-up code. But therein lies the lack of information, at least, so far. Anyway, apologies for the length of this, I realize this forum is kind of quiet, I'm kind of just publicly reflecting here. I'll continue my search for information on tweaking the ARM Linux code in an effort to improve the performance (& decrease the dysfunction & irritation factors) in the little devices. So in closing I'm just gonna say when using these little suckers don't text & drive