I've come to the conclusion that I actually really like Android as an operating system, the internals seem remarkably well thought out and ideal for the mobile use case (so long as you're running a userdebug build with the ability to adb root in when needed), most of people's issues aren't really with Android (although Google reducing the AOSP release schedule isn't a good sign).
I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without. It's installed as a location manager internally, which gives it a shitload of permissions by default that you never grant it. There's absolutely no reason everything (notifications, the app store, some location services) has to be packaged together into one thing instead of each having its own module that can be removed at will. Play integrity just plain shouldn't exist and as far as I'm concerned is purely there to ensure no one creates a real play services alternative or another mobile OS with Android compatibility.
The ideal outcome for me would be keeping Android but effectively dissolving Play Services and instead having the concept of a core services, where instead of apps choosing to use Firebase for notifications, they instead bind to the system notifications service, and as the user I choose which implementation I want, preferably with it not installed as a system app. I'm well aware that's not going to happen, but it seems like the most practical way to break up the Google/Apple monopoly to me, Android's great but Google's services aren't.
> I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without.
This is somehow by intention. In the ramp-up of Android adoption, Vendors and carriers started to fork Android and deviate too much from the core. Google needed a leverage to tie them to stay compatible to the ecosystem, Google Mobile Services (GMS) was the tool to do so. "Pass the compatibility test suite and you qualify to preload GMS".
Then, at some point, Google implemented API's in the OS which call Google's cloud infrastructure (e.g. Location services), which they didn't want to commit to the Android source for the risk of them being forked and modified, so they started to implement them in a precompiled "Google Play Services" module.
Over time, it seems Google Play Services became the preferred vehicle for Google to rollout any kind of API-changes to have them applied on all devices immediately, without waiting for the vendor to do an OS-Upgrade.
The result is that Google now promotes Google Play Service API's as the way for the most widely compatible implementation of an app. Which is...not wrong, but in the larger picture also the reason why Android is not considered "real" open-source (anymore).
> The ideal outcome for me would be keeping Android but effectively dissolving Play Services
Agree. There is still a very good OS in there, clearly written by considerate SW-Engineers.
> Google needed a leverage to tie them to stay compatible to the ecosystem, Google Mobile Services (GMS) was the tool to do so. "Pass the compatibility test suite and you qualify to preload GMS".
Yeah, it wasn't even totally the wrong thing when it happened. It was something I liked because you had both the manufacturers and the carriers getting in the way of OS updates.
For example, I bought a new Samsung Galaxy 4 years ago from Tmobile. Tmobile NEVER updated the phone past the initial release, even though samsung did the next android version (I forget which exactly, 9, 10?). But even samsung had dropped support for the phone basically after that single update.
The google move to pull things out of the OS and push them into the play store was welcome because it meant you were less likely to have unfixed bugs and problems due to vendor laziness.
But of course greed has taken over and now google is trying to change Android from an open source OS to a closed source one. Increasingly making it hard for the likes of GrapheneOS to exist.
First came Project Treble, where Android was refactored to actually have a stable ABI for drivers, by pretending Linux is a microkernel, all drivers run in userspace, use Android IPC to talk with the kernel, and are implemented in a mix of C++, Java and more recently Rust.
Since Android 8, traditional Linux kernel drivers are considered legacy.
Naturally all of this only works via PlayStore services, and is related to the "Google Play System Update", or similar, that you can find in the settings section.
> Over time, it seems Google Play Services became the preferred vehicle for Google to rollout any kind of API-changes to have them applied on all devices immediately, without waiting for the vendor to do an OS-Upgrade.
I wonder if further developing microg or similar would be a better use of resources than Postmarket, Ubuntu touch etc? Would that be a faster path to wider adoption and therefore better chance of challenging the Android/iOS duopoly?
MicroG is a open source reimplementstion of a subset of Google services, it doesn't talk to Google by default unless you enable the settings that enable it.
There is microg, which implements some of this by re-implementing Google Play services but allowing you to choose your own provider for services where this is possible: https://en.wikipedia.org/wiki/MicroG
I think you are in the minority of people that feel Android is a well built "OS". Maybe from an end-user point of view it "does what you want" but its underlying architecture I think is pretty poor.
I have spent the past 2 years off and on modifying AOSP (for "reasons") and I am constantly amazed the poor quality of the code base and badly architected the overall system is.
It's a bunch of re-inventions of the wheel (start-up daemon manager, IPC, HAL, GUI, etc) with the "upper layers" written in Java with a mix of C/C++. Mixing the metaphor of a Java "run time environment" with a Linux-based kernel results in a hodepodge of pieces and having seen it up close it makes sense why "Android" user experience varies so much device to device.
Did Android need it's own bastardized libc for example (bionic)? Did Android need to have it's own start-up daemon manager? A "HAL" in C++ (wrapping Linux kernel capability) with a bunch of bridges to Java via JNI?
Writing an application for Android is also a byztantine mess of NDK, SDKs, Java build systems (Maven, Gradle, etc), XML files, Java, Kotlin, etc. Why can't icons just be SVGs, why do these have to be in some XML-formatted resource? The list goes on.
No idea what you mean by "well built OS" when Android has so many corner cases and weird "hard coded work arounds" and crazy development process that its behavior is often unpredictable and downright irrational.
And what do you think iOS / macOS is based on? UNIX userland from the BSDs with the Mach kernel, Mach IPC, etc. Fun note: It's easier to cross-compile standard UNIX utilities and programs for iOS/macOS than it is Android since Android effectively has its own user-land.
macOS and by extention iOS are, by comprarison to Android, actually pretty well architected. The choice of kernel (Mach, Linux) is really not the limiting factor, it's how you plumb together the layers above the kernel and that's what Android has done badly.
Lastly, just because OpenMoko may or may not have done something ideally (~20 years ago?) doesn't mean the current efforts (postmarketOS, Plasma, PHOSH, Sailfish) have done it badly. Actually most of these efforts are leveraging the fairly refined parts of a modern Linux environment and are MUCH easier to work with at the lower levels than Android.
> I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without.
Wasn't the point of Play services to enable keeping OS "updated" regardless of the manufacturer schedule? Which is to say: they are tightly integrated because they were designed to be part of an operating system that Google can keep updated through Play Store even if the device OEM is slacking on porting upstream updates to the users.
I think it was one of those cases where "the road to hell was paved with good intentions".
I'm old enough and was very pro-android in the early days when it first released. I absolutely remember the frustrations around having vendors just REFUSE to update the OS on devices. Even things that were brand spanking new often got left to rot, and the OS updates in those days were genuinely meaningful software updates - Lots of new capabilities.
So I was actually ok with Google going down the route of moving critical software into an installable package that they controlled, that would provide a way to get new capabilities onto devices that manufacturers didn't give a shit about anymore.
---
But the problem is that "Google" today sure as hell isn't the google that I liked back then (and even that google was starting to shift tone).
And now this package is a backdoor that they can use like a beat-stick to force vendors to stay on their version of Android, and it functions to make "Android" (the distro that users actually use) functionally closed-source and non-permissive.
---
I still strongly believe that the appropriate regulation for this situation (across both iOS and Android) is that the company that makes the OS should be prohibited from running any sort of app store, and app stores must be selectable at device initialization (ex - the Internet Explorer ruling, but for app stores).
Somewhat, but only relevant when it comes to things like WebView but not other things. If there is a vulnerability elsewhere, your device on an older OS that the manufacturer has stopped supporting will not get any patches.
Google may think it's important to keep WebView always up to date with Play services. I couldn't care less. I still have to buy a new phone to get all updates.
I don't know what exactly do you mean by Android system. Does storage count? The idea of how applications aren't allowed to access each other's storage is very bad from the user perspective, for example.
Permission model of Andorid is hostile to the user and is designed to the benefit of the manufacturer. It undermines the users' ability to take advantage of their computer but allows the manufacturer / whoever installed the system to have undue and unwarranted access to the device.
My experience of using Android is very similar to using a corporate laptop configured by the least competent IT department of a large US bank: you are not allowed to do the basic and useful things, you are required to jump through a lot of hoops to have the remaining absolutely necessary things done, you cannot eliminate hostile functionality, you cannot be sure your personal stuff will remain personal (if it ever was...), it's a system that will automatically do things to you that you don't want done...
Basically, using Android sends me back to the early 2000s when this kind of setup was typical for MS Windows computers given to employees in large US companies.
If you're looking for way to get userdebug functionality without building a huge source tree, I created regraph[0]. It's similar to other solutions but does not inject sudo or root, other than the supported adb root path.
It starts with an upstream GrapheneOS build and modify the system image (super) in place, signed with the published userdebug keys.
I dunno, I wish Android had a cohesive backup strategy the way iOS does. iPhone is terrible but losing your phone and switching to a new is insanely easy, with all state back to exactly how it was before.
Android doesn't have it per se, but Seedvault runs on various Android-derived systems (notably but not only GrapheneOS) and does a bang-up job of backing up both applications and data
"Bang-up" is a good description of what Seedvault does, because your backup will have holes in it. Anything made with Android's backup system has the same problem.
Applications can specify that they can't be backed up, and you as a user have no way of overriding that. Highlights on my smartphone are Fennec (Firefox), Termux, Cromite, Element, Syncthing, various videogames and other utilities.
I absolutely want these backed up, and on any sensible system I'd just point restic to their storage locations and be done. On Android I need an arcane mess of Titanium Backup and TWRP, and god help me if I ever have to recover from a backup.
Swift Backup is the modern solution for backups if you have root access. It backups apps + data. I've migrated through 4 phones at this point without any notable issues. I use it to also do weekly backups of all my app+data which then gets Syncthing'd to a server and then snapshotted to my NAS in case I want to ever come back to a app version from weeks or months back.
> I actually really like Android as an operating system, the internals seem remarkably well thought out and ideal for the mobile use case
Just no. I developed for android for a long time and I have seldomly seen a worse and more confusing SDK and code base. I can give you many examples but the core layouting algorithm having quadratic complexity with the number of widgets and the single base-view class having 60.000 lines of code are just the tip of the iceberg.
I stopped in 2018. I realize that a lot has been done since then, but the base code wasn‘t changed, otherwise old apps wouldn‘t run anymore.
My gripe with android is that I think it wastes a lot of resources by being very inefficient in software. Just enable the debug mode to see what portion of your screen refreshes and repaints and stand back in awe while nothing changes and you still get hundreds of repaints.
> Just enable the debug mode to see what portion of your screen refreshes and repaints and stand back in awe while nothing changes and you still get hundreds of repaints.
And you are positive that this hasn't change in almost a decade?
> My gripe with android is that I think it wastes a lot of resources by being very inefficient in software.
As opposed to what? This thread is about Linux on Mobile. Are you saying that Linux on Mobile is a lot more efficient than Android? Like do you get more battery life with Linux on Mobile for the same usage?
So you say that "[Android] wastes a lot of resources by being very inefficient in software as opposed to iOS". How do you measure that? In my experience, people who have smartphone need to charge them every one or two days, and the battery gets worse over time but it usually stays usable for a few years.
If Android was "a lot less efficient", I would expect to see a difference in battery life. Do you?
> Android is largely Linux
Android (the OS) is largely NOT Linux (the OS). And if you compare Android to Linux on mobile, in terms of battery life, it is extremely different. It's pretty much what makes Linux on mobile a no-go for pretty much everyone (in good approximation).
You are allowed to not like Android or the Android codebase, but it is incorrect to say that Android is inefficient.
I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without. It's installed as a location manager internally, which gives it a shitload of permissions by default that you never grant it. There's absolutely no reason everything (notifications, the app store, some location services) has to be packaged together into one thing instead of each having its own module that can be removed at will. Play integrity just plain shouldn't exist and as far as I'm concerned is purely there to ensure no one creates a real play services alternative or another mobile OS with Android compatibility.
The ideal outcome for me would be keeping Android but effectively dissolving Play Services and instead having the concept of a core services, where instead of apps choosing to use Firebase for notifications, they instead bind to the system notifications service, and as the user I choose which implementation I want, preferably with it not installed as a system app. I'm well aware that's not going to happen, but it seems like the most practical way to break up the Google/Apple monopoly to me, Android's great but Google's services aren't.