45 ms·

> 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 wi

> 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.

djfergus 2mo ago
Thank you (and the GP post) for the insight. 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?
- palata 2mo ago
  Well microg is just the client side, but it still communicates with the Google servers, right?
  - KetoManx64 2mo ago
    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.
ignoramous 2mo ago
> 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. Not really. That's a different thing viz. Android Pony Express: https://source.android.com/docs/core/ota/apex https://source.android.com/docs/core/ota/apex
cogman10 2mo ago
> 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.
- Godsend69 2mo ago
  [dead]
pjmlp 2mo ago
You are missing a few steps there. 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. https://source.android.com/docs/core/architecture/hal https://source.android.com/docs/core/architecture/hal However adoption by OEMs was still not enforced, because "our partners freedom" kind of thing, So Project Mainline come to be, where Android was further modularised and userspace components could be updated via PlayStore. https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system With, as already mentioned by others, APEX as delivery format, https://source.android.com/docs/core/ota/apex https://source.android.com/docs/core/ota/apex 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.
- grapheneos 2mo ago
  Traditional Linux kernel drivers are not considered legacy and upstream drivers can be used when available. Treble does not imply anything about the kernel driver design. The whole Treble vendor HAL layer including all the userspace code and kernel modules is an implementation detail of the device. It's a stable API/ABI for the system image to make it easier to update to new major Android versions without overhauling the device support code. It was also used as an opportunity to heavily sandbox most of the HALs as part of splitting them out of running in system_server, media processes, Bluetooth processes, etc. It did not result in significant changes to kernel drivers. GKI (Generic Kernel Image) support did result in significant kernel driver changes by requiring them to use a far smaller subset of the kernel API and work with a GKI image for testing. Certified devices don't need to use a GKI in production and mostly don't but do need to work with it for testing. That's supposed to make it possible to much more easily update the kernel in a similar way as Treble did for the OS. This has forced writing drivers in a way that's much easier to port to new kernel versions which encourages updating the kernel to new LTS branches. It has the downside of making Android itself upgrading the AOSP kernel trees to new LTS revisions within a branch much harder since there's supposed to be a stable ABI. It would be much more purely beneficial if they dropped the stable ABI while keeping the restriction on the subset of the ABI usable by modules. Implementing drivers largely in userspace is entirely a choice for the companies writing the drivers. It's much better for security and robustness to have most of the code in sandboxed userspace processes than the kernel. There's no requirement from Android or Google certification to do this. It's simply regarded as a good engineering practice by most. The reason the Linux kernel puts so much into the kernel is because it doesn't control the userspace. They're largely putting code into highly privileged kernel space for organizational reasons. If they had a way to write large portions of the drivers in userspace, then many upstream Linux drivers would likely be written that way. It's a huge problem that there isn't a standard and accepted way to do that rather than a good thing. Many out-of-tree drivers for Android devices largely being in isolated userspace processes is a major security benefit which shouldn't exist because upstream drivers should be able to be written as sandboxed processes too. The APEX modules used as part of the device independent base OS are open source parts of the Android Open Source Project. Google Play mainline updates are Play Store shipped builds of the code for those for Google Mobile Services devices. It didn't result in anything being removed from AOSP.
grapheneos 2mo ago
APIs haven't truly moved from AOSP to Play services. Location services are fully functional in the Android Open Source Project and do not require cloud infrastructure. Network-based location and geocoding are in AOSP as APIs and require an app implementing it. In GrapheneOS, we have our own app implementing both. We host geocoding via Nominatim. We currently use Apple's location service as an opt-in feature via either direct usage or our own proxy but we plan to provide our own database instead of only a proxy. Google Play services is nearly entirely for using Google services rather than functionality independent of Google services. Certain functionality such as security key support was put into Play services to make it available on all devices despite not shipping with it. In the case of security keys, AOSP now has a standard API for it with apps able to provide it. There are multiple apps providing security key support as a supplementary credential manager which can be used alongside a main password manager. It is true that Play services sometimes ships new functionality unrelated to Google services, but they didn't move functionality from AOSP to it. It's new functionality which wasn't previously in AOSP. Our main issue with it was what they did with security keys but they promised us it would be resolved and years later it was resolved. It took a lot longer than it should have and it's wrong that it happened the way that it did but it's not an issue anymore. The main issue are the licensing terms for Google Mobile Services and the Play Integrity API device and strong integrity levels enforcing licensing it. That's how Google locks out competition and locks in OEMs with them. It's the massive problem which needs to be addressed by regulators, not any of the things they focus on instead. Android gained market share through being an open platform with open source code. Google should be forced to stop degrading that and locking out competition. If they want to implement fancy things in Play services tied to their services, that's fine. People can compete with them. On the other hand, what they're doing with the Play Integrity API and beyond it is not fair and prevents competition. Unfortunately, regulators largely don't understand how Google harms competition and solves the wrong problems. The remedies for their anti-competitive behavior consistently don't address the core issues and allow it to continue getting worse.

djfergus 2mo ago

Thank you (and the GP post) for the insight. 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?

palata 2mo ago
Well microg is just the client side, but it still communicates with the Google servers, right?
- KetoManx64 2mo ago
  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.

ignoramous 2mo ago

> 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. Not really. That's a different thing viz. Android Pony Express: https://source.android.com/docs/core/ota/apex https://source.android.com/docs/core/ota/apex

cogman10 2mo ago

> 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.

Godsend69 2mo ago
[dead]

pjmlp 2mo ago

You are missing a few steps there. 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. https://source.android.com/docs/core/architecture/hal https://source.android.com/docs/core/architecture/hal However adoption by OEMs was still not enforced, because "our partners freedom" kind of thing, So Project Mainline come to be, where Android was further modularised and userspace components could be updated via PlayStore. https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system With, as already mentioned by others, APEX as delivery format, https://source.android.com/docs/core/ota/apex https://source.android.com/docs/core/ota/apex 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.

grapheneos 2mo ago
Traditional Linux kernel drivers are not considered legacy and upstream drivers can be used when available. Treble does not imply anything about the kernel driver design. The whole Treble vendor HAL layer including all the userspace code and kernel modules is an implementation detail of the device. It's a stable API/ABI for the system image to make it easier to update to new major Android versions without overhauling the device support code. It was also used as an opportunity to heavily sandbox most of the HALs as part of splitting them out of running in system_server, media processes, Bluetooth processes, etc. It did not result in significant changes to kernel drivers. GKI (Generic Kernel Image) support did result in significant kernel driver changes by requiring them to use a far smaller subset of the kernel API and work with a GKI image for testing. Certified devices don't need to use a GKI in production and mostly don't but do need to work with it for testing. That's supposed to make it possible to much more easily update the kernel in a similar way as Treble did for the OS. This has forced writing drivers in a way that's much easier to port to new kernel versions which encourages updating the kernel to new LTS branches. It has the downside of making Android itself upgrading the AOSP kernel trees to new LTS revisions within a branch much harder since there's supposed to be a stable ABI. It would be much more purely beneficial if they dropped the stable ABI while keeping the restriction on the subset of the ABI usable by modules. Implementing drivers largely in userspace is entirely a choice for the companies writing the drivers. It's much better for security and robustness to have most of the code in sandboxed userspace processes than the kernel. There's no requirement from Android or Google certification to do this. It's simply regarded as a good engineering practice by most. The reason the Linux kernel puts so much into the kernel is because it doesn't control the userspace. They're largely putting code into highly privileged kernel space for organizational reasons. If they had a way to write large portions of the drivers in userspace, then many upstream Linux drivers would likely be written that way. It's a huge problem that there isn't a standard and accepted way to do that rather than a good thing. Many out-of-tree drivers for Android devices largely being in isolated userspace processes is a major security benefit which shouldn't exist because upstream drivers should be able to be written as sandboxed processes too. The APEX modules used as part of the device independent base OS are open source parts of the Android Open Source Project. Google Play mainline updates are Play Store shipped builds of the code for those for Google Mobile Services devices. It didn't result in anything being removed from AOSP.

grapheneos 2mo ago

APIs haven't truly moved from AOSP to Play services. Location services are fully functional in the Android Open Source Project and do not require cloud infrastructure. Network-based location and geocoding are in AOSP as APIs and require an app implementing it. In GrapheneOS, we have our own app implementing both. We host geocoding via Nominatim. We currently use Apple's location service as an opt-in feature via either direct usage or our own proxy but we plan to provide our own database instead of only a proxy. Google Play services is nearly entirely for using Google services rather than functionality independent of Google services. Certain functionality such as security key support was put into Play services to make it available on all devices despite not shipping with it. In the case of security keys, AOSP now has a standard API for it with apps able to provide it. There are multiple apps providing security key support as a supplementary credential manager which can be used alongside a main password manager. It is true that Play services sometimes ships new functionality unrelated to Google services, but they didn't move functionality from AOSP to it. It's new functionality which wasn't previously in AOSP. Our main issue with it was what they did with security keys but they promised us it would be resolved and years later it was resolved. It took a lot longer than it should have and it's wrong that it happened the way that it did but it's not an issue anymore. The main issue are the licensing terms for Google Mobile Services and the Play Integrity API device and strong integrity levels enforcing licensing it. That's how Google locks out competition and locks in OEMs with them. It's the massive problem which needs to be addressed by regulators, not any of the things they focus on instead. Android gained market share through being an open platform with open source code. Google should be forced to stop degrading that and locking out competition. If they want to implement fancy things in Play services tied to their services, that's fine. People can compete with them. On the other hand, what they're doing with the Play Integrity API and beyond it is not fair and prevents competition. Unfortunately, regulators largely don't understand how Google harms competition and solves the wrong problems. The remedies for their anti-competitive behavior consistently don't address the core issues and allow it to continue getting worse.