Following our exclusive report earlier this week about Google's plans to develop the Android operating system entirely in private, the company has now provided additional clarification about how this will impact the broader development community. While this transition has minimal effect on everyday users and app developers, it significantly alters the workflow for platform developers, particularly those without direct connections to Google's OEM partners. Fortunately, Google has confirmed to our team that the Android team will continue to accept and review code contributions from external developers, alongside sharing details about other changes resulting from this decision.

The most important confirmation is that platform developers will still be able to submit patches through the public Android Open Source Project (AOSP) Gerrit code review system. For developers working at companies with Google Mobile Services (GMS) licenses, submissions can continue through the partner Gerrit, which remains restricted to authorized partners. In both scenarios, Google engineers will review these patches and, if approved, will incorporate them into the company's internal Android branch for potential inclusion in future releases.

For many projects, this approach largely mirrors how external contributions were already handled. However, the situation differs for AOSP-first projects like Bluetooth, Virtualization, and the build system, which have traditionally been developed in public. Despite these changes, platform developers interested in contributing to AOSP can continue to do so after Google completes its transition to private development. They should be aware, however, that their patches will be based on code that might be weeks behind Google's internal codebase, and any merge conflicts will need to be resolved between the developer and the Google engineers reviewing the patch.

The android-latest-release branch currently points to the android15-qpr2-release branch.

According to documentation shared with Google's OEM partners (which was later reposted by Chinese tech media), the aosp-main branch will be locked and set to read-only. Platform developers are advised to stop syncing the aosp-main branch to their build machines. Instead, they should sync to android-latest-release, which always points to the most recent AOSP release branch. Currently, this points to android15-qpr2-release, corresponding to the second quarterly release of Android 15. By June, it will likely automatically redirect to android16-release, which should be the branch for Android 16's initial release.

The android-latest-release branch is also where Google recommends proposing new changes, as submissions to aosp-main will no longer be merged. Google has stated that it won't notify developers whether their proposed changes are accepted or rejected. Therefore, the only way to determine if a change makes it into a future Android release is to check for it in the android-latest-release branch.

Code contributions can be made to the android-latest-release branch in the AOSP Gerrit.

In addition to these workflow changes, Google also confirmed several other important points:

• No changes will be made to the development process for AndroidX (Android Jetpack support libraries). These libraries have always been developed entirely in public and have never technically been part of aosp-main. The main development branch for Jetpack is actually androidx-main.
• Continuous Integration (CI) builds of aosp-main will stop once the branch is locked, but according to information shared by Chinese media, Google will continue to release CI builds of certain release branches (such as android15-release, android15-tests-dev). Google also told our team that it will maintain support for existing Android developer preview/beta programs, though it has no plans to release CI builds of its internal main branch.

Google's decision to move Android OS development behind closed doors will greatly simplify its development process by eliminating the need to manage merge conflicts between the public AOSP branch and its internal Android development branch. The company can reasonably justify this change by pointing to the relatively small number of external contributions compared to the massive volume of internal changes made annually. However, these contributions, though limited in quantity, demonstrate that Google does receive valuable input from the external developer community. Whether these changes will discourage developers from proposing future contributions remains uncertain, but they undoubtedly make the process of contributing to AOSP less straightforward than before.