At the point of writing this article, I'm still using an Android phone. I even think new Android releases add some pretty nice features. Despite that, I'm not content with the platform, and in this article I'll try to explain why.
Announced in 2007, the project sounded extremely promising. A FLOSS Linux-based mobile platform that any OEM can use, architecture-independent, made by Google? Sign me up! Even now, to most people, Android sounds like the best choice, as it allows them to do everything they expect to be able to do on a smartphone while having a wide range of phones to select from and having decent customizability.
However, today's Android is a far cry from the promise we were sold in 2007. While the core Android system is indeed open-source, the same can't be said about the addons OEMs had been adding. Linux kernel is licensed under the GPL, which forces OEMs to share their kernel changes, and there's even an initiative from Google targeting the use of upstream Linux in their devices (Known as "Project Mainline"), however that doesn't prevent companies from including binary blobs and proprietary userspace drivers and kernel modules. Even if you flash a custom ROM, the OEM-provided kernel (at least that can be patched) and userspace must still be used, making it impossible to control the code your device runs. Some succeeded in porting Alpine and GNU/Linux to certain phones, however those usually run Android compatibility layers just to make OEM drivers work, and thus aren't any more free than an AOSP-based ROM.
Google has also been successful in creating a walled garden of their own, moving useful APIs into their proprietary auto-updated framework. AOSP development model is far from being democratic as well, it can be said Google entirely controls the platform. There are some forks, but rather than building something new and fresh they offer the users "AOSP flavors".
As an example, there used to be two kinds of encryption available - full-disk encryption and file-based encryption. Full-disk encryption is probably self-explanatory - you just enter a password on boot to unlock the filesystem. File-based encryption is a bit similar, but instead of having the entire filesystem unlocked, you can unlock small bits of it, which, for example, allows your alarm to ring even if the device is shut down, or lets apps work in the background even if the rest of your files are locked. However, full-disk encryption had one important feature - it didn't rely on your encryption password for normal work, you only needed it at boot. On the other hand, file-based encryption depends on your password. This led to an important change - you could no longer set separate boot and account passwords. Having separate boot and account passwords is very important for privacy - it's fairly easy for a determinate attacker to catch you entering your password on camera, and you're incentivized to use easier passwords, as it's a chore to enter a long password every time you want to use the device. This is not a change I would expect to see in free software - but Google considered the feature useless and removed it, and none of the forks added it back. In the same way, AOSP forks always heavily depend on upstream - they can't afford to lose patch compatibility and get behind the times, as over time old Android versions start getting less and less support.
Development tooling is also terrible. While Android used to be largely "use whatever tools you want to use", Google found that inconvenient. Nowadays, if you don't use Android Studio and the official binary SDK builds you're in for lots of pain. For example, there's an official API to log function calls, but to use it without Android Studio, I had to write my own library to parse the log format. Just like the OS, the tooling is controlled by Google, making it hard to develop Android apps if you don't want to do it "the Google way", which includes writing lots of boilerplate to create the smallest apps, and being forced to write for the JVM even if you just want to create a small native app. I simply resorted to using Termux to write scripts as opposed to fully fledged applications, as that at least doesn't require me to write tons of boilerplate. Now, Termux is being crippled by Google, but at least that didn't affect me as I both don't use Play Store and run a custom ROM. In the future they might change something in AOSP and break Termux completely, but I plan to migrate long before that happens.
Now, it can't be overstated how much I appreciate the work enthusiasts have put into making Android better and more usable for everyone by creating applications, custom ROMs, recoveries, app stores, and even porting other operating systems to phones originally running Android. At the point of writing this article I am using a Xiaomi device with a FLOSS ROM and no proprietary applications installed (Of course, the drivers are proprietary), and I used rooted custom Android ROMs with Google apps on all of my previous smartphones. That said, I don't feel like I can comfortably create my own apps due to the amount of boilerplate required, nor do I feel like I control my system. I can't change the look of the statusbar, I can't change the look of the lockscreen, I can't set separate boot and unlock passwords, I can't give secondary profiles administrator access, I can't do anything but use the ROMs and apps I've been provided. That might work fine for most people, most of everyone else can probably bear with it and accept the bloated vendored development environment - but I'm completely fed up.
Which is why I ordered a Pinephone Pro! It should give me the best part of Android - namely the vast app ecosystem, while giving me the freedom to easily tinker with the system the way I see fit. I can even say I see no downsides, besides perhaps the small battery used, which I plan to fix by purchasing a keyboard case.
In fact, this is a common pattern I see in other areas. Take, for example, Windows. A tech illiterate person will see no difference between Windows and Linux, perhaps they will notice it looks different, but ultimately they'll be able to perform all the tasks they need on both systems. No special knowledge is required to launch the browser on a typical GNU/Linux system, compared to Windows. However, as the user's tech literacy increases, so does their familiarity with the OS. At some point they get used to Windows - they know how to do common tasks, they can configure their system the way they want (Like disabling automatic updates), they don't particularly have to troubleshoot anything - it all just works (Unless it doesn't, in which case there's nothing you can do about it except reinstall Windows and pray). If such a user switches to Linux, they'll consider it extremely alien - after all, when they used Windows, they understood the user interfaces, but they didn't understand the processes they activate. That makes it hard for intermediate users to switch to Linux - they will perhaps recognize some of the technical and privacy benefits, but the fact Linux requires you to understand certain tasks, as opposed to Windows which requires you to simply understand the goal of the task, is a dealbreaker for them. However, if we increase the tech literacy even more, they will be comfortable enough with computers to really understand what's going on - and they will apreciate Linux for not only achieving what they want, but letting them control exactly how it is done.
And it's the same with mobile Linux - someone who just needs a phone to be able to make calls and send SMS would be satisfied with a Pinephone, provided the hardware quirks are sorted out. However, if they want to start installing proprietary banking or social networking apps, they will quickly notice mobile Linux is less than ideal for these use cases. In fact, some of my programmer friends don't even take mobile Linux seriously, seeing it as a toy rather than a system worthy of daily driving. Android works really well for those in the middle of the spectrum, but its monolith design and development model alienates those who want to have control over their computing.
I don't expect my choice to be the best choice for everyone. However, please consider what I wrote in this article - which is written by a longtime Android user. Android negatively impacts user freedom even if you try your hardest to steer free of Google - and that's something fundamental to the platform, rather than something can be fixed. Much like I recommend Firefox (or its forks) over Chromium (or its forks), I recommend mobile Linux distros over Android - even if some Android apps won't work, you will have control over your phone in exchange.
Have any comments, questions, feedback? You can click here to leave it, publicly or privately!