News

News

ℹ️
Some major news related to the project can be found here. Do not expect updates here often, check the changelog and the Matrix Support room for more updates.

2025-09-03

If Google simply decides to take the other route

Rumors had been circulating since March 2025, gaining credibility until everything finally became crystal(?) clear:

  • Google changes the way it publishes Android code changes
  • Google does not care about custom OS development at all (unless you are “Samsung/Oppo/etc,” which are not what most referring to as a “custom OS”)
  • Google owns Android (no suprise, everyone knew it but ..)
  • wasn’t there a well known motto …? (don’t be evil!?, well and then the “don’t be evil” demote..)
  • but keep in mind: AOSP = [A]ndroid [O]pen [S]ource [P]roject !?

What happened?

Source code hiding?

First of all I feel like there is a big misunderstanding when it comes to the latest decisions by Google. I hear a lot of people saying things like Android becomes closed-source, Android code changes are all hidden in the future or Custom OS development will die now!

The change announced by Google sounds like a dramatic step at first, but let’s take a closer look at the whole thing.

Google decided to change its way of releasing the source code for Android. In short: only when a new stable version will be released, they will release (i.e. tag/create a branch of) its source code to the public. They said the [A]ndroid [O]pen [S]ource [P]roject stays open source (could Google even stop doing so?*).

* (Android as it is right now will always stay open source but Google can stop at any time and switch to a different license for any new code - if that is not depending on other open source parts with conflicting licenses. As Android is a whole universe of dependencies this might never happen and is way more complicated as it sounds first. Yes, Google owns Android and if they change their mind like they did with their motto then who knows what could happen. Personally I do not expect this though. What will more likely happen is more proprietary parts on top of Android and more bindings to their “Google Play Integrity”, of course.)

To be more clear: this change affects the AOSP-main branch only. Nobody uses that branch anyways. It was always unstable and not reliable so it is actually a good move by Google making it read-only and instead refering to the new android-latest-release branch but.. well it might be just because the whole process is new but we do not had any code published for Android 16 since several months (but we can still use their gerrit, e.g. searching for android16-release). For older releases like Android 15 and earlier there are public available code changes (as usual by tags) since yesterday, 2nd of September, though.

The reason behind this change is understandable though, mainly they claim it reduces a lot of work within Google’s development process:

What will change is the frequency of public source code releases for specific Android components. Some components like the build system, update engine, Bluetooth stack, Virtualization framework, and SELinux configuration are currently AOSP-first, meaning they’re developed fully in public. Most Android components like the core OS framework are primarily developed internally, although some features, such as the unlocked-only storage area API, are still developed within AOSP. (source)

Because Google develops large portions of Android in its internal branch, the public AOSP branch often lags far behind what’s available privately. […] This discrepancy forces Google to spend time and effort merging patches between the public AOSP branch and its internal branch. Due to how different the branches are, merge conflicts often arise. (source)

If it turns true that e.g. the framework part (really) gets completely hidden, custom OS developers are not able to get code changes in-time anymore (better said: for all parts which are not AOSP-first). They have to wait until Google releases the internal code changes to the public.

So we can access and see code changes for A15 and earlier but not for A16 at all - while this might change in the next days, too. Likely they keep going with the older Android versions as before and do the branch approach with A16 and later only?!

Let’s remove pixel trees

The other part of Google’s new approach is that they completely removed the device tree’s for their Google Pixel devices from the sources. This move is bad as these were used as a reference for custom OS developers and helped a lot to understand implementations of new features etc. Google’s statement: use the cuttlefish emulator (emulator != hardware, especially when it comes to testing!!) must be a joke (spoiler: no, it isn’t).

Don’t be evil (?)

.. btw: Google’s “new” interpretation of don’t be evil has a longer history which adds to the bad taste..

.. while on it: it does not stop here. Google recently pulled all factory images for its Google Pixel 4a (sunfish) device except the latest containing their “fix” (i.e. reducing battery capacity) for a battery issue. They also removed all the image downloads for its Google Pixel 6 (bluejay) device except the latest one, again due to a battery issue. While it sounds like a good choice it leaves a(nother) bad taste especially if your device is not affected and/or you require older binaries frome an older image.

What does this mean for users?

If Google has been teasing the community for years with ever-new ideas for demotivating developers, why is this new thing any different?

TL;DR: not (that) much (what users will see actually. of course delays will happen, especially in the next months)

Actually, this all leaves a / an even more bad taste. Google does not care if a project like LineageOS or GrapheneOS (or even AXP.OS) get in trouble when they change their processes while especially the first 2 mentioned are the main reasons for the great success of Android at all. It would have been nice to consult with the community and involve them in the process but that’s just wishful thinking if it comes to Google.

The recent changes making custom development harder and require reverse-engineering for Pixel devices now (as it needs to be done with almost any other vendor). Also the way how ASB patches will be integrated needs to be adapted depending on how Google proceeds.

So, will there be no custom OS anymore for Google devices?

Don’t worry, this will not happen (anytime soon) but all custom OS devs were used to the fact the Google was friendly, i.e. not evil, and shared things other vendors never did. It’s “just” another bad taste that Google leaves us with.

Android Security Bulletins

last but not least.. all this also influences security patching.

This change includes the ASB security patches as well, of course. We already saw this in the August 2025 ASB and now with the September 2025 ASB which both do not have any code references (atm of writing this).

In opposite ASB’s before that change had code references linked, e.g. June 2025 ASB and any other before that date.

Until now custom OS like DivestOS (R.I.P), AXP.OS and others(?) scraped the ASB bulletin site to pick the required code changes for an ASB level. This is not possible anymore due to the mentioned changes.

OSV.dev to the rescue?

While doing some research I stumbled over the osv.dev project provided by Google themself which provides full details about all CVE’s, their meaning and all that even before they are published at e.g. nvd.nist.gov or cve.org ?!

Example with CVE-2025-0089

This will be further investigated in the coming weeks, and if it proves to be reliable, it will be incorporated into the automated build process for AXP.OS.

Where to go from here?

At the moment it is totally unclear if the code we can access right now and the osv.dev links are intentional and to be expected the same way in the future or if these will be hidden as well. We will see how Google will proceed, which and how they tag new patches etc (while tags like android-security-V.v.v_rXX sound valid this is not mentioned in their new release-cycle and so might stop to appear at any time).

Things regarding the whole source code release process might also completely change in the next months until all has settled but we will see.

In any case AXP.OS will provide further updates which will include the regular changes and also include the CVE kernel patches like from the beginning. These kernel security patches are fully independent from the Android source code and based on AXP.OS’ own patching process.
Due to the nature of how AXP.OS kernels getting patched from upstream and the CIP project CVE fixes are often included long before an Android CVE has been even created.

Credits & links

AXP.OS is heavily based on LineageOS and uses a massive amount of patches by the GrapheneOS project and others like CalyxOS.
-> See also the Credits page of the AXP.OS project

some further readings:

Last updated on
ImprintPrivacy Policy