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):

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

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:

• Let’s talk security: Answering your top questions about Android developer verification
• Android developer verification: Early access starts now as we continue to build with your feedback

From F-Droid:

• F-Droid and Google’s Developer Registration Decree
• What We Talk About When We Talk About Sideloading

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.

First, we have https://aosp-devs.org, which forms the focus for the group and lays out our objectives. Probably the most significant thing we have created is the aosp-devs Discord server. This is one of the few - possibly only - places where developers can come together to talk about AOSP in a vendor neutral and developer focussed environment. As well as the general channel, there are channels dedicated to HAL, kernel, SDK addons, automotive and Android TV (atv). There is a jobs channel which works for both posting vacancies and to advertise that you are available for work. And, there is an events channel with details of forthcoming meetups, conferences and workshops. To date, there are over 600 developers signed up to aosp-devs Discord, and in a typical month we see contributions from at least 50 different people.

Another of our aims is to connect people through events. There are two strands here: online events, via the The AOSP and AAOS Meetup, and in-person events at conferences. Taking the first strand, there have been five meetups in 2025, with talks from eight distinguished presenters on topics ranging from Mastering SELinux in Android to the future of sideloading Android apps. All talks are recorded and published. In the second strand, members of the group met at:

• FOSDEM, in Brussels,
• Linaro Connect in Lisbon,
• OSS India in Hyderabad,
• OSS Europe in Amsterdam,
• IndiaFOSS, in Bengaluru,
• Droidcon Berlin

We will continue with both types of meetings into the future.

Every month we publish a newsletter which keeps a track on the major issues in the AOSP world, summarises important threads on Discord and lists upcoming events. The newsletter is a great way to keep up.

We are also active on social media. See our LinkedIn, Mastodon and Youtube accounts.

For the next 12 months, aosp-devs intends to continue the journey to create the AOSP community that was lacking before. We want to keep the momentum and be the place that connects AOSP and AAOS developers and fosters collaboration across the open source community. We will continue organizing events, online and offline, and spread news and knowledge about AOSP.

What does it cost to join aosp-devs? Nothing. Register on our Discord server, follow our newsletter and connect with developers and us at the offline and online events. See you there and let’s see what the next 12 months brings for our community!

FOSDEM 2025 - AOSP devroom - (nearly all) founding members

A quiet change in the device/google/ directory

AOSP includes configurations for a range of hardware and emulated targets - you can find them in the device/ directory, with subdirectories organized by manufacturer. Device configuration in this context refers to the configuration files, build scripts, kernel sources and binary blobs that you need to compile and flash a working build. Up to Android 16 device/google contained configuration for the Nexus and Pixel devices that are currently in their support window. But in Android 16, device/google contains only configurations based on the Cuttlefish emulator.

Google confirmed that the omission is intentional. Bill Ye posted the following on the Android Building mail list

“We remain committed to AOSP updates. You continue to have the option to build Cuttlefish and GSI targets from the sources for experimentation.”

Separately, Seang Chau posted this on X:

“We’re seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures. AOSP needs a reference target that is flexible, configurable, and affordable – independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes.”

What’s left in AOSP 16?

Despite the purge, AOSP still ships several buildable reference devices:

Why losing Pixel device configuration hurts

• More reverse‑engineering, less learning. Pixel configurations have long served as living documentation of how Google expects a modern Android device to be wired up. Without them, independent developers must diff factory images, sniff partitions and guess which kernel configs or SELinux rules changed.
• Harder for Custom ROMs. Developers working on GrapheneOS, LineageOS and others will have to reverse-engineer Pixel support from now on
• No longer an option for platform developers. A lot of people have used Pixels as development machines in the past to try out changes to platform code

Cuttlefish as reference platform

Cuttlefish is the main reference platform from now on, which is fine for most of the code but it becomes more restricted the closer you get to the hardware. Sure, there are emulation layers for most subsystems, and reasonably good support for secure boot, but there is always a point when emulation fails to match reality. Having the Pixel device configurations available was nice because it gave us several examples to work from, each with different characteristics and HALs. Furthermore, the Cuttlefish device configuration has a lot of Cuttlefish specifics which muddy the waters somewhat

Reading the tea leaves: cost cutting and a narrower funnel

Google hasn’t said the move is about money, but AOSP maintenance is undeniably a cost center - it generates no direct revenue. Combined with last quarter’s decision to make aosp‑main read‑only and do active development on a private branch, the message is clear: Google wants to spend fewer engineering hours on public infrastructure and more on shipping Android for its own products.

This is not a sign that Android will turn closed‑source. Google explicitly reiterated that “AOSP is not going away”, and the Apache 2.0 licence isn’t changing. But it is another step back from the “AOSP first” philosophy.

Where do we go from here? - A call to action

• Join the community. This is where aosp-devs.org can help by sharing knowledge on how device integration works. Join our Discord server if you have any questions or just want to share the wisdom on getting your device work.
• Upstream fixes to generic targets. Cuttlefish, Trout and Goldfish are still one Gerrit CL away; improvements there benefit everyone.
• Support community distros and reference boards. There is a lot going on beyond that offered by Google. There are many Custom ROM projects, including LineageOS, GrapheneOS, and /e/OS. For embedded Android there are community projects such as Glodroid and Raspberry Vanilla. Join those efforts or sponsor the work.

Android has always grown through collaboration. Google’s retreat makes that collaboration harder, but also more necessary than ever. The future of open Android now depends less on Mountain View and more on us.

TL;DR: AOSP remains open source and releases should increase in frequency

On 27 March 2025, Google announced changes to the Android platform development model. While some interpreted these changes as Android becoming more closed, the reality is more positive.

The Android Open Source Project (AOSP) is one of Google’s most influential open source contributions. It powers an incredibly broad range of devices, from phones and TVs to cars and even coffee machines. In fact, it’s the most widely deployed operating system in the world, used even by companies like Facebook and Amazon – organizations outside of Google’s officially approved ecosystem that do not have a licence to use the Google services (e.g. Google Mobile Services for smartphones and tablets, Google Automotive Services for cars, Google TV Services for TVs).

Therefore when Google changes how it develops Android, the implications are significant for everyone involved.

How AOSP development works at Google

Google’s engineering teams develop the Android operating system for emulators (e.g. Goldfish, Cuttlefish), Google Pixel devices and a limited number of Android partners that ship certified devices (i.e. licensed to use Google services) across the officially supported form factors smartphones and tablets, Android Automotive, Android TV, Wear, and Android XR.

These products don’t run AOSP directly. Instead, Google develops internal forks of Android, by form factor, that include proprietary frameworks, APIs, and hardware support. As a result, most of the new Android code is already developed in private and the tip of the AOSP main branch is never thoroughly tested by Google’s own teams, leading to frequent issues for downstream users who tried to build from it.

Still, on a roughly annual basis, Google would snapshot its internal development tree, remove proprietary code, and push out a stable AOSP branch (e.g. android-12.0.0_r1). This snapshot brought the majority of new code to the public, but only after it was ready for release.

What has changed

In simple terms, Google now actively discourages using the AOSP main branch by making it private. Meanwhile, they’re reinforcing their commitment to releasing stable, open source Android versions.

Here’s what this means:

• The development of the next Android release takes place privately until it’s ready for release, which is largely unchanged from before - except for the few projects previously developed as AOSP-first (Bionic, Bluetooth, Cuttlefish, Virtualization). It is important to note that in the past, even official Android OEMs struggled to contribute to projects that were not AOSP-first.

• Android will continue to be published to AOSP via the android-latest-release branch. After internal development concludes, a stable, thoroughly tested branch is pushed to AOSP. Thanks to the Trunk Stable improvements described below, this will now happen more frequently than in the past.

• The AOSP contribution process has changed and is likely more opaque. The new process could require more effort from submitters, and mirrors the work previously done within Google when contributions were made to non-AOSP-first projects.

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.

While this is disappointing for those who wish all development were public – it has largely already been the norm for Android. Therefore, in essence, very little changes and for most, it will remain business as usual – aside from making it harder to speculate upcoming features through the crumbles of AOSP-first projects.

How Trunk Stable could actually improve things

Google also recently announced a Trunk Stable development mode, which includes a new flag-based development model and more frequent Android releases - changes that could positively impact the downstream open source community.

Under this model, features are built behind feature flags and remain dormant until they’re ready to be enabled or included for a specific device or form factor. Internally, this approach lets Google improve quality, by only enabling features when ready, and avoid forking the codebase for each form factor, potentially leading to a more unified codebase across devices.

The new quarterly release schedule for the Android codebase - now including new features rather than just security fixes - offers several potential benefits for downstream projects:

• Faster access to new features: Features are no longer bound by the yearly release cycle and can be shipped quarterly if they’re ready.

• Less fragmentation and fewer bugs: Features can now be disabled until ready for release, after proper testing, or selectively enabled only for the form factors that need them. This can over time lead to a unified codebase across form factors.

Impact on other form factors like Android Automotive

For Android Automotive specifically, it should be business as usual. Automotive development has never been fully public, similar to the rest of Android. Google has not indicated that Automotive tags won’t remain public.

Moreover, Trunk Stable might help unify code across all form factors. By using the same core codebase, it could become easier for Google - and in turn, downstream developers - to build on top of a single, more frequently updated version.

Why we believe Android’s open source future is here to stay

Google significantly benefits from the innovation that arises from keeping Android open – expanding the reach of its core business by delivering its services as widely as possible.

The device ecosystem is an interconnected web of software and hardware suppliers that work together to deliver devices. All of these need access to an open source ecosystem so that they can develop their IP, which in return enables Google and its partners to build new devices and form factors.

One prominent example of large-scale innovation is the Android support for RISC-V. Though now officially embraced by Google, it was originally initiated by Alibaba and wouldn’t have been possible without AOSP being open source.

Conclusion

While the recent changes to the Android development model may feel unsettling to those who want fully transparent development, the impact on the broader Android ecosystem is minimal and does not practically change things too much.