AOSP Release Schedule Just Changed: What to Ship Now

Google has cut the AOSP release schedule in half. Instead of quarterly public source drops, Android will publish to AOSP twice a year—in Q2 and Q4. That’s not just trivia for ROM maintainers. It changes when OEMs integrate platform code, how quickly security fixes flow into downstream builds, and the planning rhythm for any company that ships on Android. If you own app reliability, device integrations, or custom builds, this is your new operating calendar.

What exactly changed in the AOSP release schedule?

Starting in 2026, Google will publish AOSP source code twice a year. The company frames this around its trunk‑stable development model: keep the main branch shippable, gate new features behind launch flags, and cut public source drops at predictable points. You’ll also see guidance to build against android-latest-release rather than aosp-main so your pipelines always track the most recent official dump. Practically, expect a bigger Q2 drop (major) and a smaller Q4 drop (maintenance).

If you previously timed merges or platform validation around the four quarterly platform releases, you’ll now map your work into two larger integration windows. Based on Google’s own banner language and industry reporting, the changes that would have landed in intermediate QPRs get folded into the nearest biannual drop. That reduces branch juggling but increases the size and blast radius of each integration.

Who should care beyond ROM builders?

Plenty of teams:

• OEMs and ODMs aligning BSPs, drivers, and compliance.

• App developers with device‑specific features or native code that need early testing on pre‑release builds.

• Security leaders who coordinate monthly patches versus platform jumps.

• Product managers who plan feature flags, rollout risk, and store submission timing.

Even if you ship only apps, the timing of platform changes influences emulator baselines, OEM ROM availability, OEM compatibility tests, and your end‑to‑end QA matrix. It also nudges when users will actually see platform‑level behavior changes that can break assumptions in networking, permissions, media, and background execution.

The new cadence, at a glance

Here’s the practical picture we’re planning against in 2026:

• Q2: AOSP major source drop. Larger API and behavior surface, plus a big wave of fixes that accumulated since late winter.

• Q4: AOSP maintenance drop. Stabilization work and the “rolled up” changes that didn’t warrant a separate release earlier in the year.

• Monthly: Security bulletins and device patches continue on their own track. Some OEMs bundle additional bug fixes; others ship pure security patches.

This is the part many miss: your security posture isn’t tied to the biannual cadence. You still need a monthly rhythm for ingesting CVE fixes, even as you plan platform integrations twice a year.

Security patches vs. platform drops: how to plan both

Monthly bulletins continue; that’s separate from source‑drop timing. As of January 11, 2026, the January Android security bulletin is out, and Pixel’s monthly rollout cadence remains its own decision. OEM variance is normal, and that won’t change just because AOSP drops are less frequent. Treat platform merges and security patches as two orthogonal tracks with clear owners.

If you need a playbook for triaging and testing monthly CVEs, use our Android January 2026 Security Update: Dev Playbook. The model there—score impact, reproduce on reference devices, fast‑track hotfixes—works every month, regardless of what Google does with AOSP sourcing.

Planning with the Biannual Android Rhythm (BAR) framework

Adopt a simple operating framework we use with clients: BAR—Define, Integrate, Harden, and Ship around two anchor windows, then keep a monthly CVE drumbeat in parallel.

1) Define (now through late Q1)

• Freeze assumptions: which APIs, NDK levels, and Play services versions are non‑negotiable for your next release?

• Inventory risks: background task scheduling, scoped storage quirks, SELinux policy deltas, WebView version dependencies, and media/codec paths.

• Align on branches: point CI at android-latest-release, not aosp-main, for build reproducibility when Q2 lands.

2) Integrate (Q2 drop + 3–4 weeks)

• Merge once, with discipline. Plan a single, audited integration train. Avoid ad‑hoc cherry‑picks unless a CVE or blocker forces it.

• Feature flags everywhere. If you adopt new platform capabilities, guard them. You can ship dormant functionality without risking a rollback.

• Test on real silicon. Emulator parity is better than ever, but audio, camera, GPU, and modem edge cases only show up on devices.

3) Harden (post‑merge + 4–6 weeks)

• Stabilize power and thermal behavior; run 72‑hour soak tests with radio stress and background sync.

• Validate compliance: CTS/VTS, Play Integrity, permission prompts, and background restriction policies.

• Security drills: instrument for crash loops, ANRs, and exploit mitigations; validate rollback protections.

4) Ship (feature‑flagged rollouts)

• Roll out in cohorts, watch telemetry, and keep hotfix branches clean to preserve patch velocity.

• Document deltas for support and sales so downstream teams know what changed and why.

Checklist: what to do before the Q2 2026 drop

Run this list in the next 30–45 days:

• Update CI manifests to follow android-latest-release; archive the older quarterly merge jobs.

• Map your device test fleet to the top 10 markets you serve; ensure at least one flagship, one mid‑range, and one low‑RAM device per major OEM you target.

• Lock a red/yellow/green risk matrix for kernel and driver dependencies (GPU, camera ISP, modem). Red paths get extra soak time.

• Split monthly CVE patching into its own pipeline with a three‑day SLA for triage and a seven‑day SLA for rollout on business‑critical devices.

• Establish feature‑flag naming rules and ownership so flags don’t sprawl.

• Pre‑draft user‑facing copy and release notes for permission and behavior changes you expect with Q2.

Will the biannual cadence slow app‑level innovation?

For most app teams, no. Your feature velocity lives above the platform. Jetpack libraries, Play services, and AndroidX evolve continuously. What changes is the rhythm of large behavior shifts: they’ll cluster around Q2 and, to a lesser extent, Q4. That’s good for predictability. If you ship native code or lean on private APIs (don’t), the bigger integration waves will require tighter smoke tests and more canary users.

OEMs, ODMs, and custom ROMs: what to expect

With fewer public source drops, the pressure to stabilize each cycle rises. Expect OEMs to align their internal branches to the Q2/Q4 cadence, target one major platform uplift per year, and push the rest as monthly patches or feature toggles. For custom ROM projects, you’ll spend less time merging quarterly churn and more time hardening two big releases. That cuts maintenance overhead but raises the stakes of your integration weeks.

One nuance: the quarterly platform release (QPR) concept isn’t gone from the closed development world, but public AOSP drops no longer mirror every QPR. In practice, that means code once visible in QPR1 or QPR3 will arrive rolled into Q4 or the next Q2. Plan your change logs and contributor onboarding accordingly.

People also ask

Does this change monthly security updates?

No. Monthly bulletins and device patches continue. Treat them as a separate pipeline with their own SLAs and test plans. Platform source drops don’t gate CVE response.

Do we still get source for every QPR?

Not as separate public dumps. Expect a Q2/Q4 biannual flow. If you’re maintaining a fork, adjust your merge calendar and contributor milestones to those two windows.

How should app teams without native code prepare?

Keep your device lab current, run beta OS builds early, and exercise permission, notifications, background work, and media paths. Most of your surface is governed by AndroidX and Play services, which ship independently of AOSP drops.

Risks and gotchas you should budget time for

• API surface drift. Hidden or deprecated behavior may not fully surface until you integrate the larger Q2 drop. Build “blast radius time” into your schedule.

• Vendor blobs and driver lag. GPU and camera paths are where stability goes to die. Keep tight loops with silicon vendors and insist on pre‑Q2 candidate builds for real‑world testing.

• Regression masking. Bigger merges can hide intermittent bugs. Use trace‑based profiling and chaos tests that shuffle radios, camera, and background sync under load.

• Store policy coupling. If you’re also shipping policy‑driven changes this month—like external purchase links on Google Play or revised content controls on iOS—coordinate release trains so you don’t stack risk on one day. For a dated Android policy checklist, see our Google Play External Links: What to Ship by Jan 28. If you’re cross‑platform, Apple’s new age‑rating questionnaire is due January 31, 2026; we outlined the practical steps in App Store Age Rating Update: Ship by Jan 31.

A practical integration plan your execs will accept

Executives care about predictability, not semantics. Promise—and deliver—two safe integration seasons a year with monthly security hygiene. Communicate the dates early, publish the risk register, and commit to kill switches for high‑risk features. Most importantly, decouple policy‑driven changes from platform merges unless a single build is unavoidable.

Instrumentation that pays for itself during Q2/Q4

• Gatekeeper dashboards that track crash‑free sessions, ANRs, cold‑start regressions, and battery drain deltas before and after the merge.

• Synthetic monitors for network, camera, media playback, and background jobs. Trigger them on every canary build, not just release candidates.

• Device farm automation with vendor‑specific test lists—Bluetooth + audio handoff, camera focus under low light, cellular handover during video calls.

How this interacts with store releases and growth

Big platform merges are when risk clusters, so don’t also ship a price change, ad network SDK swap, or conversion‑critical UI redesign in the same week. Stagger. If growth needs an experiment, use a feature flag with a server‑side kill switch and make sure your analytics SDKs are already verified on the new platform build.

If you’re reworking billing or links for regulatory reasons, you’ll find our deeper guidance in the Google Play External Links: 2026 Builder’s Guide. For iOS, your marketing and legal teams may also ask you to update content filters and labels—coordinate those with engineering so you don’t block submissions late in the month.

BAR in action: a 60–90 day sample timeline

• Week 0–2: Define. Finalize target SDKs, NDK version, and device test list. Align CI to android-latest-release and freeze schema changes.

• Week 3–6: Integrate. Land the Q2 AOSP drop on a dedicated branch, flag new features, and start vendor driver validation.

• Week 7–10: Harden. Run full CTS/VTS, power/thermal soaks, and stress labs. Pre‑brief support on user‑visible changes.

• Week 11+: Ship. Stage rollouts to 5% → 25% → 50% cohorts, watch telemetry, and hold a clean hotfix branch for CVEs or blockers.

What about teams shipping device‑embedded apps?

If you build preloaded apps or device experiences, insist on earlier OEM drops for your reference devices. Validate background execution limits, notification channels, storage, and permissions. The delta between your app’s assumptions and OEM customizations often appears only after the platform merge, so front‑load the tests and require a sign‑off before marketing sets a date.

What to do next

• Set your 2026 integration seasons: one centered on the Q2 AOSP drop and one on the Q4 drop. Publish them to the company calendar.

• Split security patching into a monthly lane with firm SLAs. Don’t let CVEs “wait for Q2.”

• Point CI to android-latest-release and archive quarterly merge jobs.

• Build and enforce feature‑flag discipline. Ship dark, light up later.

• Rehearse your canary rollout and rollback plan before the Q2 merge train leaves.

• If you need help aligning engineering and product around this shift, our mobile engineering services team can step in to run your first cycle.

Zooming out

Fewer public source drops don’t mean less change; they mean change happens in larger, more predictable waves. That predictability is a gift if you treat it like one. Put your calendar where your mouth is, decouple security operations from platform integration, and make feature flags your default. Do those things, and the new cadence won’t slow you down—it’ll make you steadier.