April 2026
Since March 2025 Google have made quite a few changes to the way that AOSP is developed and released to the world. In this blog post I want to summarise those changes and assess their impact.
The Android Open Source Project is the upstream of a large and varied ecosystem. Some of that ecosystem is within Google’s sphere of influence (smart phone manufacturers, TV, Automotive, Wearables), but there is much going on beyond. An unknown number of manufacturers embed Android into their products without the need to license services from Google (some Automotive manufacturers, in-flight entertainment, digital advertising, oscilloscopes, etc.). Not to mention the Custom ROM community who work to support older hardware and to create a Google-free experience (CalyxOS, /e/OS, GrapheneOS, LineageOS and many more). So, AOSP is important to a diverse range of people.
No more aosp-main
On 27th March 2025 Google announced that the aosp-main branch would become read-only, meaning that all development will happen on private branches, which will be pushed to public branches from time to time. We covered this in a blog article at the time.
In reality, this did not have much impact on downstream AOSP developers. Most of AOSP development was on private branches anyhow. The only real difference was the small number of “AOSP-first” projects that had been developed on aosp-main. They included Bionic, Bluetooth, Cuttlefish, and Virtualization. The Android common kernels (ACKs) continue to be developed in the open and upstreamed to kernel.org, while the Android Native Development Kit (NDK) continues to be developed in the open on GitHub.
Note that you can still propose changes on Gerrit, but using branch android-latest-release.
Consequence:
- no continuous access to the few projects that were developed AOSP-first
Android 16 arrives without Pixel support
The code drop for Android 16 was released to AOSP on 9th June 2025, and it was a big surprise that the support for Pixel devices was missing. There is a separate blog post on the topic already.
Consequences:
- Without the Pixel devices as a reference it becomes harder to create board support packages for all kinds of Android devices. From now on, we only have the Cuttlefish and Goldfish emulators, which are … not real hardware
- Developers working on custom-ROMs will have to reverse-engineer Pixel support from now on
Reduced frequency of code being released to AOSP
Previously we could expect at least one, and often multiple pushes of code to AOSP per month. The releases are documented on https://source.android.com/docs/setup/reference/build-numbers, and usually announced in the android-building group https://groups.google.com/g/android-building/.
But then in July 2025, Google indicated that they would release code to AOSP only four times per year: major release, QPR1, QPR2 and QPR3. Then in January 2026, this banner appeared at the top of all pages at source.android.com
Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, we recommend utilizing android-latest-release instead of aosp-main. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP.
So now there are only two AOSP releases per year, coinciding with the major release (Q2) and QPR2 (Q4)
It is interesting to see what has actually happened for Android 16:
Both r1 and r2 releases appeared on 9th June. They differ only in their build ID, they are otherwise identical. I have no information why r2 was necessary.
The r3 (QPR1) release was two months late, hence the code releases for QPR1 (r3) and QPR2 (r4) were only one month apart. Many sources commented on this, including Android Authority.
QPR3 was officially released to Pixel devices on 3rd March 2026, but since this came after the 2026 announcement of only two code drops per year there is no “r5” release corresponding to QPR3.
Consequence:
- Long lead times between updates being announced by Google and code being available for non Google partners. Probably has most impact on Custom ROM developers where there is an expectation from their users. Embedded Android developers are usually less interested in features.
Reduced frequency of security patches
Along with less frequent code drops we have a corresponding reduction in the number of security patches.
Security releases are made available in AOSP using tags of the form android-security-[version]_[release]. They contain nothing but fixes: no new functionality and no fixes specific to any of the QPR releases. They are always based on the r1 major release. There used to be one per month. Now we have one per quarter. It seems that this is not just for AOSP: OEM’s are only expected to ship one security update per quarter as well.
Looking at Android 16 we can see that there have been 5 security releases so far:
There was no announcement of the security r1 and r2 releases. Looking at the git repository, it seems that they were tagged on the same date: 20 November 2025.
Consequences:
- While end users hate updating software, it is the only way to keep systems safe. One update per quarter leaves devices vulnerable for (comparatively) long periods
- Less (or no) visibility of upcoming security patches for non Google partners
- The CVE embargo period is up to three months, during which CVE details may be leaked from the tens of thousands of developers who have access to the AOSP CVE dataset
Security bulletins
Google publish a security bulletin every month listing the CVEs fixed in AOSP:
https://source.android.com/security/bulletin.
The bulletin is divided into sections for the various subsystems, some of which are part of AOSP and some are proprietary. The ones that are in AOSP are labeled “Android Run Time”, “Framework”, and “System”. There are also two sections labeled “Kernel” and “Kernel components” which relate to the Android Common Kernel. Although these are also open source they are not part of AOSP so I have not including them in the table below.
A typical report looks like this (from December 2025, Framework):
| CVE |
References |
Type |
Severity |
Updated AOSP versions |
| CVE-2025-22420 |
A-337775777 |
EoP |
High |
13, 14, 15, 16 |
The reference (A-337775777) links to the commit for that fix which you could use to backport to your own branch. There are a few reports where the reference is not link to a fix. It is not clear why this happens. In the table below there is a column for reports without links
| Date |
CVEs |
No link |
| April 2025 |
24 |
0 |
| May 2025 |
24 |
0 |
| June 2025 |
15 |
0 |
| July 2025 |
0 |
0 |
| August 2025 |
3 |
1 |
| September 2025 |
54 |
1 |
| October 2025 |
0 |
0 |
| November 2025 |
1 |
0 |
| December 2025 |
43 |
2 |
| January 2026 |
0 |
0 |
| February 2026 |
0 |
0 |
| March 2026 |
47 |
4 |
| April 2026 |
1 |
0 |
July 2025 was the first time that no CVEs were reported in a monthly bulletin. On the other hand, there were large numbers posted in September, December and March, i.e. at the end of each quarter, which coincides with the AOSP security releases.
This is explained by the switch to a “Risk-Based Update System” (RBUS) as described in this post on Android Authority. Under this new system, only high-risk or actively exploited vulnerabilities are patched monthly, while the majority of non-critical security fixes are now bundled and delivered on a quarterly basis.
Consequence:
- The same as listed in the previous section, “Reduced frequency of security patches”
Developer registration
On 25th August 2025, Google announced A new layer of security for certified Android devices.
The effect of this change is that starting in September 2026, all apps installed on a certified Android device will require the developer to be registered with Google Play Console. It does not matter if the app is installed via Play Store or a third party app store (e.g. F-Droid). It will be possible to install locally via adb without registration so long as you enable developer mode and then enable USB debugging. A certified Android device is basically any device that is running Google services (GMS, GAS, GTVS).
In a blog post on 19th March Google described an “advanced flow” that will allow users to install from third party app stores - after following a 9 step procedure.
There has been much debate about this. Below are some links to relevant posts.
From Google:
From F-Droid:
My opinion is that if I own the device - phone, tablet, etc. - then I should be able to decide what software I run on it. I have a feeling that the security arguments deployed by Google are spurious and that this is really an exercise in control. If you agree with me, there is a campaign called Keep Android Open that you might want to check out.
Consequences:
- For developers who already have a Play Console account, nothing changes
- For developers who do not have and do not want to have a Play Console account, their apps can only be installed if the user explicitly allows it via the “advanced flow”. This is especially hard on small scale, often open source developers who just want to share some code, maybe a demo, or similar
- For developers who do not target certified devices, for example running an Embedded Android, developer registration is not an issue
Closing words
Quite a lot has happened to the way Google manages the AOSP code base in the last 12 months. Most of it can be put down, I think, to Google wanting to streamline the development of Android - remember that Google make very little revenue from the Android OS. Android only exists to point users at Google’s services. While AOSP is crucial to that enterprise, there is an incentive to develop AOSP as cheaply as possible.
The good news is that AOSP remains open source, and I think it always will be. There is too much infrastructure and too many links with partners that would have to be renegotiated in a proprietary world.
aosp-devs.org is looking at the consequences on developers of all these changes. We need to keep a look out that Google continue to fulfill commitments to distribute code, and fix security holes as they turn up.
]]>
FOSDEM 2025 - AOSP devroom - (nearly all) founding members