Google Just Quietly Changed How Android Open Source Works , And Almost Nobody Noticed

Sometime in the past few months, a small banner appeared at the top of source.android.com. No press release, no Google I/O keynote slide, no tweet thread. Just a few sentences sitting above the fold on a documentation site most people never visit unless they're building a custom ROM or bringing up a new device.

Here's what it says, in plain terms: starting in 2026, Google will only publish AOSP source code twice a year — in Q2 and Q4. And developers pulling the platform source should stop using the branch they've relied on for over a decade.

If you've spent any real time inside AOSP, this is a bigger deal than it looks.

What Actually Changed

Two concrete things:

1. Source drops are now biannual, not continuous. For most of Android's history, aosp-main behaved like a genuinely living branch — Google's internal platform work eventually surfaced there, and anyone syncing the repo could watch the operating system evolve in something close to real time (with obvious gaps for unreleased features). That's over. Public source pushes now happen twice a year, timed to Q2 and Q4.

2. aosp-main is being retired in favor of android-latest-release. The new manifest branch doesn't track ongoing development at all — it always points to whatever the most recent official release is (something like an android16-qprX-release tag), full stop. If you're still writing setup docs or CI configs that reference aosp-main, they're now pointing at a branch Google is walking away from.

# The old way (deprecated going forward)
repo init -u https://android.googlesource.com/platform/manifest -b aosp-main
 
# What Google now recommends
repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release

One thing that isn't changing: monthly security patches. Those keep shipping on their existing android-security branches, on the existing monthly cadence, independent of the new biannual source releases.

This Didn't Come Out of Nowhere

If you've only skimmed Android news, this looks like a random infrastructure tweak. If you've been paying attention to Android platform engineering over the last two years, it's the next step in a pattern:

Google has been rolling out Trunk Stable, an internal development model that replaces long-lived feature branches with everything landing directly in one internal main branch, gated by feature flags instead of branch merges. It's part of why Android 16 shipped ahead of Android's usual yearly cadence.
Around 2025, Google stopped folding Pixel-specific changes into AOSP altogether, shifting toward developing new releases entirely inside closed internal branches before pushing a finished snapshot out.
Components that used to get meaningful public development in the open — the Bluetooth stack, the build system, the update engine, parts of the virtualization framework — have been quietly pulled back behind the same wall. Put together, the story isn't "AOSP publishes less often." It's "the era of watching Android get built, live, in public, is basically over." What you get now is a finished release, dropped twice a year, rather than a running commit history you can follow.

Why This Actually Matters (Even If You'll Never Clone AOSP)

Google's own framing is that this is developer infrastructure — nothing a regular Android user will ever notice. That's true for app developers targeting the SDK. It's not true for a decent-sized chunk of the ecosystem:

Custom ROM projects (LineageOS, GrapheneOS, and the dozens of smaller device-specific projects) rebase their work on top of AOSP. Two source drops a year instead of a rolling stream means longer gaps between the moment Google fixes or breaks something and the moment ROM maintainers can even see the diff.
OEMs and chipset vendors who fork AOSP for their own device lines lose the ability to track platform changes incrementally, which makes it harder to catch integration issues early instead of all at once, twice a year.
Students, researchers, and engineers learning AOSP — historically one of the best ways to actually understand how Android works under the hood — now learn from a periodic snapshot instead of a living project with visible commit history and rationale. None of this breaks anything overnight. It just quietly narrows who gets to watch Android being built, and turns AOSP from something closer to "an open project" into something closer to "a release artifact with source code attached."

What To Actually Do About It

If you touch AOSP in any professional capacity, the action items are small but worth doing now, before your tooling breaks on the next drop:

Swap aosp-main for android-latest-release in any repo manifests, CI pipelines, or onboarding docs your team maintains.
Stop expecting incremental platform commits between releases. Plan integration and testing work around two windows a year (Q2, Q4) instead of continuous syncing.
Keep security patching on its own track — android-security branches are unaffected, so don't conflate your platform-tracking strategy with your patch strategy.
If you maintain a fork or a custom build, budget more review time right after each release drop — you'll be absorbing roughly six months of platform change in one sync instead of catching it incrementally.

The Bigger Question

None of this makes Android closed source — the code is still released, still under the same license, still buildable by anyone. But "open source" was never just about the license. Part of what made AOSP genuinely useful to the wider ecosystem was that you could watch it happen — see the commits, understand the reasoning, catch problems early.

That part is what's quietly going away. Google didn't announce it at I/O. It showed up as a banner on a docs site, worded like a routine infrastructure update. Maybe that's exactly what it is. Or maybe it's the clearest signal yet of how much of Android's actual development has already moved behind closed doors — and how comfortable Google now is admitting it in a single paragraph nobody was meant to read twice.

Are you affected by this change — building a ROM, maintaining a fork, or just learning AOSP? I'd like to hear how teams are adjusting their workflows for the new release cadence.

Sources: source.android.com · AOSP Automotive release notes