Ah, android: can’t live with it, can’t live without it. The always present mobile operating system, the only competitor of iOS.
But throughout the years, our favorite droid has changed, a lot. But you know what hasn’t changed? How fragmented it all is. And the damage google does to the ecosystem.
The only thing iOS does better.
Yes, I said it. iOS does do better at one thing then Android: unification. No billion OEMs and devices to guess what works where, no removing an API you just got used to. No added OEM bloatware or adware.
Sure iOS has fewer devices to make them all work. And heaven knows one of Android’s strengths is the diversity. But that same diversity leads to OEMs doing their own thing way too often, and things don’t work as expected. One prime example? Battery optimization.
On one device, your app just needs a notification to stay in the background. Another the user must dig deep into obscure settings to keep it alive. And then some, you just can’t keep it alive. Don’t believe me? Check out https://dontkillmyapp.com. The fact that such a list really must exist is telling, to say the least about the matter.
And that’s not all. From Package Manager, to app-ops, to more, OEMs like to mess things up, for users and developers alike.
Stable API? What’s that?
Much like any OS, android adds and removes APIs each release. That’s fair. Unlike other OSes, Android does this with neither rhyme nor reason.
The API that most developers started using when it came with android 10? Removed in android 11, for “security concerns” they won’t elaborate on. Remove exec() call for all apps because a few abuse it? Let’s do it! Break ALL THE APPS (see here for one of the apps effected). Force apps to use Storage Access Framework (SAF) even though it’s up to 14 times slower? DO IT!
Although some changes were made for legitimate reasons, Google often ignores community feedback and does it’s own thing when implementing them, no matter who’s effected.
And let’s not forget OEM skin customization, either: you’ll find APIs removed or severely handicapped on Huawei, Xiaomi, Samsung, or OnePlus devices. From changes in the theme engine, to changes in package (app) installation, to bizarre SELinux (Security Enhanced Linux, the core of Android security restrictions) policies, to restrictions on permissions, OEMs can do what they very well please, including violation of GPL (Android uses the linux kernel, which is GPL licensed and therefore requires source release. We’re no legal experts though, and OEMs seem to think the GPL doesn’t apply to them, so we may be incorrect).
Updates: what are those?
Google’s tried to fix this, to be fair. Project Treble, Seamless Updates, Project Mainline. All supposed to take care of one problem: timely updates.
But each successor either failed or had a minor rate of success. Project Treble was great for us tinkerers, but didn’t help updates as much as Google hoped: many devices that shipped with Treble either got no updates or few. Project Mainline is promising, because it does modularization of some core android components and updates them via Google Play. But even that is botched: they still do very slow roll outs, and two of us on the team here at Androidacy are on the January Google Play patch, even though the March one is long released.
Only Pixel owners get those sweet, sweet monthly updates. The rest of us have to wait months if we ever get updates. And that’s bad for everyone, from a security perspective and a shiny new update perspective.
Down with the tinkerers
Are you an Android tinkerer? I know I am!
But with each release, that gets harder. Google has made it easier than ever to lock down and restrict devices; from preventing even disabling OEM bloatware, to carrier locks, to OEM unlocking (aka unlocking bootloader), they’ve tied that down.
Even if you get a Pixel, beware where you buy it from: only the ones sold by Google can be fully unlocked, to harness the full tweaking potential of Android.
They removed an API Substratum (theming engine) used back in Oreo on the upgrade to Pie. They’ve enforced SELinux restrictions to make running Magisk (a root solution) as hard as possiblem and OEMs have been happy to help: from encrypted boot images, to bizarre partition setups, and more.
And the now infamous one: SafetyNet. Each release of android and update to Google Play Services, it’s gotten better from new software detection methods to hardware backed attestation, and it gets harder to make McDonald’s think you’re not rooted. Yes, apparently that’s such a high security app that it needs an additional couple layers of verification that the device is full of bloatware, insecure, and locked down, ahem, I mean in factory condition.
You can argue that some apps do legitimately need assurance that they’re running on a fully secured and verified device, and you’d be right. However, Google really needs to work on tightening their requirements and enforcing them.
It’s not just Google
Of course, any OS is only as good as it’s community, and the Android community shows that to us clearly. From toxic developers, to money hungry app creators, to unhelpful support personnel, each member of the community isn’t helping.
With app developers, there’s three kinds: ones that actually care, ones that only care about their money, and ones that just suck. You have apps that do nothing but crash or haven’t been updated since 2017, ones that it’s clear that the developers put more work into anti piracy measures than the actual app, and the few that are actually good. Not every app is bad. But quite a few are 80% ads or anti piracy measures.
It’s evident even the play store has no quality control. And the aforementioned unstable API probably isn’t helpful, either.
I myself, and everyone here at Androidacy, have no intention of ditching our favorite droid. But as much as we love it. it makes it hard to keep doing so. And at this point, it really feels like a one way street. *sniffles* I gotta talk to my relationship therapist now, I feel abused by Android *sniffle*