Here's how Google was able to move up Android 16's release date

The Android release schedule is undergoing major changes next year. Instead of rolling out the next major release of Android in August, September, or October of 2025, Google has announced that it will release Android 16 sometime in Q2 of 2025. That’s not all, though, as Google also announced that it will introduce a minor release with new developer APIs in Q4 of 2025. This is all part of Google’s plan to speed up Android’s release schedule so it better aligns with new device launches and brings new APIs to apps more quickly, but in order to accomplish this, Google had to make some major changes to the way it develops Android. Here’s why Google is moving up Android 16’s release date, as well as how it did it.

How Android’s current release schedule slows down new API rollouts

Although Google only pushes out a single major release of Android every year, it also pushes out three more minor updates known as quarterly platform releases (QPRs).

You’re probably familiar with these QPRs by now, as Google has been continuously running beta programs for them for the past few years. In fact, there’s one running right now for the first QPR of Android 15. These QPR beta programs have been successful in letting Google fix bugs and roll out new features more quickly, but they haven’t really done anything for app developers.

That’s because QPRs generally do not include any changes that matter to app developers, as they’re updates on top of an Android release that has already reached ‘Platform Stability.’ When a version of Android reaches Platform Stability, its app-impacting system behaviors and APIs are frozen, meaning they can’t be changed unless the SDK version is incremented. Android 15, for example, reached its Platform Stability milestone with Beta 3’s release in June. That means that every upcoming QPR of Android 15 will only include bug fixes and new user features but not anything that impacts how Android apps behave or what they can do.

There are exceptions to this, though. Android 12L was the second QPR of Android 12, and it introduced new APIs. Before that, there was Android 8.1, which was the first QPR of Android 8. These kinds of minor releases have been rare, though, which means that if there’s some new API that Google wants to introduce, it either has to wait until the next major release to do so or find some way to roll it out outside of the OS like through Project Mainline or Google Play Services updates.

However, with how fast new technologies like generative AI are advancing, Google wants to bring new APIs — especially new APIs for AI functionality — in front of apps more quickly.

To do that, Google is not only releasing Android 16 earlier than usual next year but also speeding up Android’s SDK release schedule by making the QPR it plans to roll out in Q4 of 2025 into a minor release with new APIs.

Part of the reason why Google rarely rolled out minor releases with new APIs in the past is that it was difficult to add new functionality without breaking existing things. Solving this problem required Google to change the way it develops new Android features, as Seang Chau, VP and GM of the Android Platform, explained to me during an interview on the Android Faithful podcast.

How the trunk stable project helped Google speed up Android’s release cycle

Earlier this year, Google switched Android over to what’s called a trunk-based development model, where all of its developers now work off of a single internal branch of code with short-lived branches being spun out when necessary.

In the past, Google would create long-lived branches of code for every new major release or QPR it was working on. When it was done working on these branches, it would merge all this code back to the internal main branch, which sometimes broke things or caused regressions as the features it was working on were only tested against the forked branches.

Under a trunk-based development model, though, all features are tested against the same internal main branch, making it easier to catch regressions before they’re shipped to production.

Since all the code is now in one branch, Google created a new internal flagging system called aconfig (Android Config) to control the availability of everything from new features to new APIs and even bug fixes.

The changes that Google made to Android as a result of moving over to this trunk-based development model and aconfig flagging system are why I was able to first demonstrate Private Space on an Android 14 beta release even though you probably know it as an Android 15 feature. Ever since the first Android release under this new development model — which was Android 14 QPR2 — the only thing separating QPRs from major releases is what flags were used to build them and what flags are enabled, as the underlying codebase is now the same.

Seang told me that Google’s move to a trunk-based development model for Android gave the company “the confidence to make sure that [it] could add these APIs — these non-breaking APIs — more frequently throughout the year.” This is because, from a development perspective, the model allows Google to build new features in a way that’s high-quality right out the gate. It also lets them “experiment with long-term things, things that might take [them] 3 months, 6 months, 9 months, or a couple of years” and add them to builds “without breaking existing functionality.”

Google is working with its OEM and SoC partners to make sure they stick as closely as possible to this new trunk-based development model so that they have less work cut out for them. The company also told me it’s working with its partners to help them roll out minor releases like the one in Q4 2025, so it’s not just Pixel devices that get them. As an outside observer, it’s clear to me just how impactful the switch to a trunk-based development model has been for the Android team, so I hope that other companies that work with AOSP also adopt this model.

My interview with Seang can be found in the video embedded below. We touched upon the Android 16 release date changes and other Google announcements, such as the accelerated Android release schedule. My coverage of these topics on Android Authority goes more in-depth, of course, but I still recommend giving the interview a listen, as it also brings up some new announcements relevant to app developers.