Google Aiming for Gold2025-08-27
Google is currently speedrunning the Android Open Source Project (AOSP) into the ground even in spite of the current antitrust litigation. Below is a recap of the past few months since some bits are being overlooked.
- Google announced that after March they would no longer be publishing the source code for the in-development versions of Android. These branches were frequently used by systems for cherrypicking bug fixes to the stable releases before Google actually released them.
- Android 16 was released in June. Google made the stark decision with this release to no longer consider Google Pixels to be the AOSP reference devices. Pixel device trees and kernel sources with git history are now no longer available. This makes it much more difficult for AOSP forks to support Pixels because they will have to make their own device trees. You can read this thread here which has comments from GrapheneOS, CalyxOS, and LineageOS developers. See also additional information from GrapheneOS and CalyxOS.
- Source tags for the July and August Android Security Bulletins (ASB) have not been published. I'll restate that for clarity, there have been no public AOSP 16 source code releases for two months now.
- edit 08-28: GrapheneOS has since disclosed that Google will no longer be providing public monthly branches and is instead switching to 1 yearly major upgrade + 3 quarterly security/bug updates, with a very small monthly ASB that is handled separately from a branch for select security issues.
- edit 09-09: The August ASB patches still have no links. The September ASB patches have links but are all A15 tags. The A16 September QPR sources also have not been published. GrapheneOS has elaborated on this here.
- Google announced concrete plans to enforce government ID verification of developers and companies for apps not in the Play Store. This would likely be enforced by the proprietary Google Package Installer which they mandate for certified Android devices. This works by having (government ID verified) developers register their app package ID and associated signing key via the Play console. They notably plan to enforce install limits on apps that share a package ID of an existing registered app. It is furthermore currently unclear if they will allow developers to sign their own same package IDs with multiple keys without install limits.
- This will for example likely significantly impact all apps (3,896) on F-Droid.org that both don't use reproducible builds (746) and don't use a unique F-Droid.org package ID (49) (-10 for overlap) which accounts for roughly ~79.85% of their current index.
- Developers in sanctioned regions will be inherently prohibited from this program completely blocking use of their software.
- There is no mechanism declared for unmaintained apps, which directly hinders archival efforts and their future use.
- edit 09-18: This also means an internet connection is required to install apps.
- If you are a developer/organization please consider voicing any concern here.
These issues are rapidly stacking on top of others, such as the years long anti-competitive behavior of Google aggressively pushing developers to adopt Play Integrity which blocks non-certified systems even if they provide substantially added security measures such as GrapheneOS. As a short aside you might think Google doesn't consider GrapheneOS to be "big enough", except Play Services (GMS) actually explicitly checks for it and allows their Chromium-fork, Vanadium, to perform privileged FIDO2 operations.
At this point I would not be surprised if Google does a rug pull on bootloader unlocking for Pixel devices within the next year. To date no one has made a working bootloader unlock bypass for even the first generation (Verizon CID) Google Pixel from nearly nine years ago.
Moving forward, for those currently on stock Android please consider an aftermarket system like GrapheneOS. As for longterm, while the situation of "Linux phones" such as postmarketOS is extremely rough right now in terms of both usability and security, I encourage everyone to give them a try (on a PinePhone or SDM845 device exclusively) and contribute their skills if possible because we must have a viable third option.
The best outcome would be for AOSP (and Chromium) to actually become true reference implementations controlled by a neutral joint party that caters to everyone's interests. But that is just fantasy, Google is playing 4D chess and will vigorously seek to ensure control over their precious jewels.
Comment on this: Fediverse, Hacker News, Privacy Guides Forum