Summary
- Google will now conduct all its active Android development internally, ceasing real-time code commits to the public AOSP branches.
- This change aims to improve efficiency by eliminating merge conflicts, though Google will continue to publish the final source code after development concludes.
- While end-users and app developers will see little impact, the move could make it harder for external contributors and reporters to track Android’s ongoing progress.
The open-source nature of Android is one of its biggest draws for many people — OEMs like Samsung use it to their advantage by making their own tweaks to the code for skinned versions like
One UI
, and people following closely often find hints of new features coming to the operating system when Google makes public changes to the Android Open Source Project.
While the source code for the world’s biggest mobile OS will remain open, Google has confirmed that development will now happen largely behind closed doors.
In a report for Android Authority, AOSP expert Mishaal Rahman outlined changes that Google is making to the process of developing Android. The Mountain View company confirmed that it is moving all of its own Android OS development to an internal branch, meaning the public branch of AOSP will no longer see Google’s individual commits while new versions are being worked on.
To be clear, however, Google will still make Android’s source code publicly available when a new version is finished — we just won’t see the smaller changes the company itself is making along the way.
What’s actually happening here?
Google maintains two separate branches of AOSP — one public, and one internal. The public branch can be viewed by anyone, but the private version is only accessible to Google itself, as well as Android OEMs and other companies with a Google Mobile Services (GMS) licensing agreement.
Rahman points out that most of AOSP’s development is done internally by Google itself and would only appear on the private branch even before this change. Third parties are able to submit code changes to the public branch, but Google reserves the right to refuse any of these before finalizing a new Android version and publishing its source.
By and large, all of this will remain unchanged even after today’s news. The public AOSP Gerrit will still be available, and third-party commits will still be visible there. Google will still publish the finalized source code — it’s just that, during development, the company will simply go from making most of its own AOSP changes behind closed doors to making all of them privately.
Yeah, but why is this happening?
According to Rahman, this change boils down to efficiency for Google’s internal teams. Previously, managing its own development across both the public AOSP branch and a separate internal branch created significant overhead.
The public branch of AOSP often lagged behind the work happening internally. When it came time to merge code between the two, Google’s engineers frequently ran into merge conflicts — clashes between the different code versions that required extra time and effort to resolve.
By moving all of its active development work into the internal branch, Google thinks it can eliminate these conflicts and streamline its workflow.
It’s worth noting that this doesn’t mean the public AOSP repositories are disappearing — Google will continue to publish finalized source code there, and third parties should still be able to submit contributions through the public Gerrit. Ultimately, the change is about where Google’s own engineers do their day-to-day coding during the development cycle.
Okay, now what’s the bottom line?
The biggest problem this move will create, at least from a functional standpoint, is that third-party developers contributing code to AOSP will likely have a harder time tracking changes being made to Android. This could discourage such developers from continuing to contribute, since Google may or may not be duplicating their efforts behind closed doors.
Beyond that, reporters like Rahman who track changes to AOSP will now have to do their code sleuthing in bulk when Google publishes the full source. As for end-users and Android app developers, this change shouldn’t have much of an impact.
In related news, Google recently pivoted to a Trunk Stable development process in the hopes of speeding up Android releases — something that has helped put Android 16’s timeline ahead of schedule this year. In an interview with Android Police Editor-in-Chief, James Peckham, Google’s Head of Android explained how this and other development factors are evolving:
Google’s Head of Android on Gemini in your phone, Android 16’s early release, the Pixel 6’s extra life, and more
Google’s Sameer Samat speaks to Android Police