AOSP release schedule changed: what to ship now

Google’s new AOSP release schedule cuts public source drops from quarterly to twice per year, landing in Q2 and Q4 starting in 2026. That’s not just a calendar tweak—it reshapes how Android platform teams, custom ROM projects, and even app orgs budget engineering time for merges, feature flags, and security patch intake. Here’s how to adapt without losing velocity or security posture. (androidauthority.com)

What actually changed—and when

On January 6–7, 2026, Google confirmed that public Android Open Source Project code pushes will occur only twice a year going forward, synced to Q2 (major) and Q4 (minor). Historically, Google pushed source with each quarterly platform release; that’s over. A banner on the Android docs and a note from Google on the android-building list spelled out the shift. (androidauthority.com)

Practically, this means you won’t see standalone AOSP drops for QPR1 and QPR3. Instead, QPR1 lands inside the Q4 drop, and QPR3 rolls into the next major Q2 drop. Monthly security bulletins still publish on the first Monday (or next business day) of each month, and Pixel monthly updates continue. The cadence of advisories is intact even as full source drops consolidate. (piunikaweb.com)

Why Google says it’s doing this

Google ties the change to a “trunk-stable” model: keep the main internal branch shippable, hide in‑flight features behind flags, and reduce the complexity of maintaining multiple public release branches. Fewer public drops should mean less churn for downstreams and, in theory, more stability. Whether you agree or not, the incentive is clear: fewer transition points for OEMs and maintainers to chase. (androidauthority.com)

Does the new AOSP release schedule slow security patches?

No—at least not at the bulletin level. January’s Android Security Bulletin posted on January 6, 2026, like clockwork, and Google’s security pages still reference the standard monthly cadence. What changes is your path to integrate those fixes into a public AOSP baseline between Q2/Q4 drops. If you depend on public trees only, you’ll need a deliberate backport plan. (cyber.gc.ca)

Pixel’s monthly patches aren’t affected, according to multiple reports. OEMs with direct channels keep their pipelines. The pain concentrates on smaller device makers and open-source distributions that historically rebased on each quarterly public drop. (piunikaweb.com)

What this means for three different teams

1) OEM and ODM platform teams

Expect fewer clean rebasing opportunities. If you previously rebased on every QPR, you now have two big windows: Q2 and Q4. Plan feature integration to cluster around those, and budget a separate stream to ingest critical security and kernel fixes monthly. Resist piling feature work into ad-hoc midquarter cherry-picks; it’s how regressions slip through.

2) Custom ROM and security-focused distributions

You’ll spend more time curating patches between public drops. Maintain a stable patch lane fed by monthly bulletins and vendor advisories, and gate new features behind flags until the next Q2/Q4 baseline arrives. That keeps your release train moving without gambling on unreviewed upstream deltas.

3) App orgs that ship SDKs, device agents, or OEM integrations

Your dependencies (permissions models, media stack quirks, networking APIs) still evolve across QPRs, but you’ll test them first via previews and device OTAs rather than public AOSP. Keep your compatibility test farms fresh and add device diversity; a single Pixel channel won’t reveal vendor-specific breakage.

Branching that won’t bite you later

Google has been nudging the ecosystem toward a single stable manifest for a while. If your manifest still rides aosp-main, move to android-latest-release, which always tracks the most recent stable push. Treat it as your rebasing anchor in Q2/Q4; run a separate integration branch for monthly security backports. (source.android.com)

That split model keeps CI predictable: your mainline consumes only vetted release trees; your security lane carries minimal, audited deltas with strong test coverage. Yes, it adds discipline. It also stops a midquarter merge from derailing your certification schedule.

Security: keep the monthly muscle memory

The monthly security drumbeat continues. The January 2026 advisory published January 6 and referenced the standard 2026‑01‑01/05 patch levels. Even with fewer AOSP drops, you should continue to: (a) intake advisories monthly; (b) backport or overlay fixes; and (c) ship OTA updates on your established SLA. If you treat Q2/Q4 as your only “real” intake, you’ll drift months behind on critical CVEs. (cyber.gc.ca)

If you’re an Android lead juggling multiple initiatives this month, we already published a practical walkthrough of the January patch wave—use it to sanity‑check your triage and testing steps. See our January 2026 Android security update playbook for dev-ready sequences and checklist items.

Will QPR1 and QPR3 disappear?

You’ll still see devices get QPR1 and QPR3 features and fixes; they’ll just roll into the next public AOSP drop rather than appear as standalone source releases. Expect QPR1 deltas to land in the Q4 push and QPR3 to get folded into the next Q2 push. That avoids “orphan” public branches while keeping the platform’s user-facing quarterly rhythm. (piunikaweb.com)

How to ship under the new cadence: a 30/60/90 plan

Day 0–30: Stabilize and set guardrails

• Update your manifests and scripts to default to android-latest-release for baseline builds.
• Carve a dedicated monthly security branch and CI job that ingests the Android Security Bulletin patches on day one each month.
• Audit feature flags: every new capability should be flag‑guarded by default.
• Freeze nonessential platform changes two weeks before each monthly patch window. This preserves a clean lane for security regression testing.

Day 31–60: Rehearse the Q2/Q4 intake

• Run a mock “drop week” rehearsal: create a branch from your current baseline and practice the merge choreography (conflict resolution, HAL/API diffs, CTS/VTS runs, vendor kernel sync).
• Expand device coverage in CI: add at least one non‑Pixel reference device representative of your target OEMs.
• Define an owner map: platform intake DRI, security backport DRI, CTS/VTS DRI, sign‑off approvers.

Day 61–90: Automate and measure

• Automate bulletin ingestion: pull CVE lists, map to components, assign work items, and generate a nightly backport status report.
• Track two lead times: TTR‑CVE (time to remediate) and TTR‑drop (time from public AOSP push to your rebased internal release). These two numbers are your new north star.
• Build a “flag‑to‑ship” scorecard: how many features are behind flags, how many passed full perf/regression gates, and what’s ready to flip in the next quarterly OTA.

Testing focus areas that will save your Friday night

• Media and camera: codec and HAL shims can drift midquarter; keep golden video/photo tests.
• Telephony and IMS: run carrier certification sims after large backports.
• Power/perf: repeat battery and thermal runs after kernel and scheduler pulls.
• Privacy/permissions: verify runtime permission prompts on new builds; QPRs often tweak UX flows.
• Mainline modules: track module versioning and rollback safety; ensure your OTA pipeline respects module dependencies.

Risk register: where the new cadence can hurt

• Long‑lived feature branches: two big rebases a year tempt teams to park features for months. Fight that impulse with smaller, flag‑guarded increments.
• Security drift: without a monthly patch lane, your exposure widens. Treat security as a separate, never‑blocked stream.
• Vendor kernel lag: if your BSP depends on patches released with quarterly trees, make sure you have a private channel for kernel updates or a plan to forward‑port from public commits.
• Certification crunch: clustering big deltas into Q2/Q4 can overload QA. Spread your validation cadence with continuous integration and staged rollouts.

Zooming out: why this still matters to app teams

App developers don’t merge AOSP, but they live with the blast radius. When OEMs delay rebases, permissions and behavioral changes land late and unevenly across devices. That’s why your app CI should continuously test on beta channels and fresh OTAs, not just on a single “reference” build. Proactive testing catches behavior changes long before they reach a public AOSP tree.

Related deadlines you shouldn’t ignore this month

Two near‑term dates that frequently share the same engineering capacity pool: January’s Android security patch train (already live) and Apple’s App Store age rating questionnaire deadline on January 31, 2026. If you’re juggling mobile platform work across iOS and Android, block capacity now so neither slips. Apple has already reassigned ratings under the new system and will halt App Store updates for apps that don’t answer the new set of questions by the 31st. If you need a field guide for that process, read our ship‑ready playbook for App Store age ratings. (source.android.com)

“People Also Ask” quick answers

How will this change the timing of Android source code releases?

Public AOSP pushes consolidate into two drops: a major in Q2 and a minor in Q4. QPR1 rolls into Q4; QPR3 rolls into the next Q2. Monthly security bulletins and Pixel updates continue unaffected. (androidauthority.com)

What branch should I track now that aosp-main is de‑emphasized?

Use the android-latest-release manifest as your default baseline and layer monthly security backports on a dedicated branch. Google has explicitly recommended this manifest since 2025, and it aligns with the new rhythm. (source.android.com)

Will fewer AOSP drops affect custom ROMs?

Yes—mostly in process, not possibility. You’ll invest more in backporting and continuous security intake between Q2/Q4 drops, and you’ll lean harder on feature flags. Device support may stagger more unless you broaden test coverage.

Let’s get practical: the checklist

• Switch manifests to android-latest-release; pin a security backport branch.
• Keep a monthly bulletin intake ritual with measurable TTR‑CVE.
• Run a quarterly “drop week” rehearsal before Q2 and Q4.
• Flag‑gate every feature; define clear flip criteria.
• Expand device matrices beyond Pixel; include at least one major OEM and one mid‑tier device.

What to do next (this week)

• Update your CI to build from android-latest-release and create a parallel job for monthly security backports.
• Schedule a one‑hour risk review for kernel/BSP delta exposure.
• Align QA on a quarterly intake rehearsal ahead of the first Q2 drop.
• If Android work shares a team with billing/platform changes, block time for Play program updates. Our builder’s guide to Google Play external links can save cycles when you’re juggling deadlines. And if you need extra hands, see what we do and our mobile platform engineering services to get support fast.

Final thought

Two public drops a year puts more responsibility on us—the people shipping Android—to separate stability from stasis. Keep security monthly, features behind flags, and your rebases disciplined. Do that, and your users will barely notice anything changed, which is exactly the point.