Google has changed the Android Open Source Project (AOSP) source-code release cadence. Starting in 2026, Android source drops will land in Q2 and Q4 only—raising big questions for developers and custom ROMs.
January 7, 2026 — Google is making a major behind-the-scenes change to how (and how often) it publishes Android’s open-source code. A banner now displayed across the official Android Open Source Project (AOSP) documentation confirms that, effective in 2026, Google will publish Android source code to AOSP only in Q2 and Q4—a shift away from the more frequent cadence many developers and ROM communities have depended on.
The change is already reverberating across the Android ecosystem: for most everyday users, it won’t affect phone updates directly, but for platform developers, device makers, security researchers, and especially custom ROM projects, it could reshape how quickly the community can adopt (and build on) Google’s newest Android platform changes.
Key takeaways
- AOSP source releases are moving to a twice‑yearly schedule: Q2 and Q4.
- Google says the shift aligns with its “trunk stable” development model and is meant to improve ecosystem stability.
- Developers are being steered away from
aosp-mainand towardandroid-latest-releasefor building and contributions. 1 - Google-backed reporting indicates the cadence is effectively dropping from four source drops per year to two.
- Google says security patch releases are not changing, even as full platform source drops become less frequent. 2
What exactly is changing in Android’s AOSP source-code schedule?
Google’s official AOSP documentation now states that the company will publish source code to AOSP in Q2 and Q4 starting in 2026. The same notice recommends that developers building and contributing to AOSP should use android-latest-release rather than aosp-main, and notes that the android-latest-release manifest branch will point to the most recent release pushed to AOSP.
While Google’s public-facing Android story is often framed around consumer releases (“Android 17,” Pixel Feature Drops, OEM skins like One UI, etc.), AOSP is the foundational layer: it’s where the publicly available Android platform code lands—what independent developers can sync, build, fork, and customize. 1
Bottom line: the Android platform will continue evolving, but the public AOSP “source drops” will be bundled into two major releases per year instead of appearing after every quarterly platform release.
Why Google says it’s doing this: “trunk stable” and platform stability
Google’s banner frames the change as an effort to align with its trunk-stable development model and to “ensure platform stability for the ecosystem.”
For context, Google’s own AOSP documentation describes “Trunk Stable” as a model where official AOSP releases are “snapped” from a single internal main development branch, and where feature launch flags help keep that branch stable and safe for contributors.
In reporting published today, Android Authority says Google explained the rationale as improving stability and better aligning with trunk-stable workflows—reducing the burden and complexity of managing multiple release branches while still delivering stable code to platform developers. 2
Google’s guidance for developers: aosp-main isn’t the place to build anymore
One of the most important practical consequences is not just the twice‑yearly cadence—it’s the continued push away from the older workflow many developers were used to.
The AOSP FAQ makes it explicit:
- You can’t submit to
aosp-mainbecause it is read-only. 1 - Developers should propose changes to
android-latest-release(Repo users) or to the default revision branch referenced by theandroid-latest-releasemanifest (Git users). 1 - Google also notes that
aosp-mainhas been read-only since March 27, 2025, and that code fromandroid-latest-releaseis not merged intoaosp-main. 1
Google even provides a concrete Repo command for syncing:
repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifest
Separately, Google’s “Site updates” documentation explains that, starting March 27, 2025, the android-latest-release manifest references the latest public release branch (and notes the manifest is set to a then-latest branch, android16-qpr2-release).
What this means for custom ROMs
This is where the biggest debate is likely to land.
Custom ROM projects (and the maintainers behind them) depend on timely access to Android platform source. When AOSP updates land later—or land less often—it can slow down:
- feature adoption,
- device bring-up work,
- long-term maintenance branches,
- and early integration for new Android platform changes.
That’s why coverage of today’s change quickly framed it as bad news for custom ROMs—even if Google positions it as a stability win.
Android Authority’s reporting is especially direct about the magnitude of the shift, stating that Google previously released source code for every quarterly Android release (four per year) and is now reducing that to two releases per year, focused on Q2 and Q4.
Meanwhile, WebProNews and other outlets are already warning that fewer source drops could delay development cycles for ROM communities and potentially widen gaps between Google’s internal platform work and what external developers can build against.
Community reaction has also appeared quickly in enthusiast spaces. Threads discussing the news (including ROM-focused communities) show a mix of skepticism and concern—especially around whether fewer platform drops could indirectly slow the pace of downstream ROM updates.
Does this affect regular Android users?
Probably not—at least not directly.
Droid Life’s coverage put it bluntly: this is “developer-related stuff” and “doesn’t affect you at all,” because consumers get Android updates from their OEM (Samsung, Google, OnePlus, etc.) and not from AOSP source drops. 3
That said, there can be indirect effects:
- If you rely on custom ROMs to keep an older phone alive, slower AOSP drops can mean slower ROM feature updates.
- If you use privacy/security ROMs or alternate Android forks, the cadence could influence how quickly those projects can ship major platform changes.
- If you’re a developer tracking Android platform shifts early, fewer public source drops can reduce transparency into what’s coming next between releases.
But for the mainstream Android update pipeline—monthly security updates, OEM feature updates, carrier rollouts—Google’s AOSP cadence is only one piece of the puzzle.
What about security patches—will Android security updates slow down?
Google’s messaging is careful here.
The Android Authority report says the process for security patch releases “will not change,” and that Google will keep publishing monthly security patches on a dedicated security-only branch for relevant OS releases. 2
That distinction matters: even if full platform source drops are only Q2 and Q4, the security patch machinery can still keep moving on its existing schedule.
Still, many developers will watch closely to confirm in practice that the security-only branches and patch publication timelines remain consistent throughout 2026, especially as the new cadence plays out.
AOSP is still open source—but “open” doesn’t always mean “real-time”
One thing that often gets lost in these debates: Android’s openness has always been structured.
Google’s AOSP FAQ reiterates that most Android source code is licensed under the permissive Apache License 2.0 (rather than a copyleft license), and that Google oversees the core platform while encouraging broad adoption. 1
In other words, Android remains open source—but Google controls when major platform snapshots become public. This new schedule simply formalizes a less frequent release cadence that’s more tightly aligned with Google’s internal branch and release strategy.
What happens next: the 2026 timeline to watch
With the policy now visible on Google’s own AOSP pages, the next big question becomes execution:
- Q2 2026: Expect the first major AOSP source drop under the new twice‑yearly plan.
- Q4 2026: Expect the second major source drop.
- Between those, platform developers and ROM maintainers will likely rely more heavily on:
For teams that build on AOSP—OEMs, chipmakers, enterprise Android forks, and custom ROM developers—the practical work now is adapting pipelines to a world where “the next big batch of Android source code” arrives twice a year, not four times.
