In the standards field, Embrace, Extend, and Extinguish is a strategy for gaining users of an open standard, and breaking it to lock them in. This does not exactly match Android, as it is a software project, rather than a standard. But it resonates with its story of making the open source effectively unusable without proprietary extensions.
I've been an Android user for, I think over 10 years by now. Well, still am, out of necessity. But I'm fed up with it as a user. I feel like instead of empowerment, I have to fight with this device on every step to keep some control over my own device, and to not send more of my data to corporations.
Google hardly even bothers to keep the Android Open Source Project documentation separate from one for their proprietary Google Play Services.
Does any of your mobile apps send you push notifications? You can be almost certain they go through Google servers. More namely, Firebase Cloud Messaging. Google has made it easy to just add FCM libraries to your Android app, and made it hard to not use FCM.
-
Android 6 introduced Doze mode: "If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. In Doze mode, the system attempts to conserve battery by restricting apps' access to network and CPU-intensive services. It also prevents apps from accessing the network and defers their jobs, syncs, and standard alarms." As you might guess, this breaks background processes listening for notifications.
Solutions? "If possible, use Firebase Cloud Messaging (FCM) for downstream messaging."
-
Android 8 introduced background execution limits. "Apps that are running in the background now have limits on how freely they can access background services."
-
And yes, the point is that you use
WorkManager
. But you probably get the drill by now. "Your app receives a high priority message using Firebase Cloud Messaging." -
OEMs who heavily modify Android they ship are notorious for making it worse, by creating issues specific to their devices. "They kill background processes and render alarm clocks and other apps which rely on background processing useless."
Do any of your apps use location? There are system APIs for this! Oh, wait, what's this? "Note: The Google Location Services APIs, part of Google Play services, is the preferred way to access location services for apps. […] Clients of the traditional Android location APIs are encouraged to switch to the Google Location Services APIs wherever possible."
Anything scanning QR codes? Remember the old days of ZXing? Not anymore. And of course with incentives: "The Google code scanner API provides a complete solution for scanning codes without requiring your app to request camera permission". You don't have it? I hope you enjoy typing your password and SMS codes, because you're not logging in with the DigiD app.
And now, I couldn't just leave out SafetyNet, and its new replacement, Play Integrity API here. What do these do? I think the most important check: "tells you whether your app is running on a genuine Android device powered by Google Play services". What does "genuine Android device" even mean? I guess not that much control of your device, because you get an accordingly lower device integrity label of MEETS_BASIC_INTEGRITY
if your device "may have an unlocked bootloader".
Is there really no hope in Android world?
microG Project is trying to reimplement these proprietary APIs. There are 2 problems with that:
- Google keeps making new ones, requiring more work to reimplement them. We're talking about complicated stuff like ML models or speech synthesis.
- Google makes all the engineering choices that suit them. To work, microG has to make requests the same way as the Google Play services. microG allows you to e.g. get push notifications without using Google's proprietary code on your device. But this is still the same, fundamentally flawed way, where Google servers are in the middle. Good riddance, but not quite enough.
I've previously had some faith that Huawei shipping Android phones without the proprietary Google parts is gonna change something. Because, e.g. if you have to scan a QR code on both Google and Huawei, you could just use ZXing, which does not depend on either's environment, right? In reality, of course, developers really just do depend on both, write handling dependent on whether it's Google or Huawei, and ship it like that to the app stores. The whole difference is that instead of a Google ML Kit there is a Huawei ML Kit, and so on.
So, yeah. Hope, left me.