Android OS development is going fully private, but Google still wants help from other developers

Earlier this week, we broke the news that Google will soon develop the Android OS fully in private. Currently, Google develops some Android OS components, such as the Bluetooth stack, in public, but the company is shifting all work to its internal branch in an effort to streamline its development process. The move has little effect on end users or app developers, but it does impact the workflow of platform developers, especially those without ties to one of Google’s OEM partners. Thankfully, Google has confirmed that the Android team will continue to accept code contributions from external developers, and it has also shed light on other changes that are being made in response to this news.

First, Google has confirmed to Android Authority that platform developers will still be able to submit patches to the public Android Open Source Project (AOSP) Gerrit, the web-based code review system used by Google for AOSP development. Developers who work for a company with a Google Mobile Services (GMS) license can submit patches through the partner Gerrit, which is not available to the public. In either case, these patches will be reviewed by Google engineers, and if accepted, will be cherrypicked and merged into the company’s internal branch of Android for inclusion in a future release.

Depending on the specific project, this is basically how external code contributions were already handled. However, this workflow is a bit different for AOSP-first projects like Bluetooth, Virtualization, or the build system, as development on these projects has historically been done in public. Regardless, platform developers who are interested in submitting patches to AOSP can continue to do so even once Google takes development of the Android OS fully private, though they’ll have to be aware that their patches will be based on code that could be weeks behind Google’s internal codebase. Any merge conflicts that arise will have to be resolved between the platform developer and the Google engineers assigned to review the patch.

According to documentation shared with Google’s OEM partners (and reposted by Chinese media), the aosp-main branch will be locked and set to read-only. Therefore, platform developers are advised to no longer sync the aosp-main branch to their build machines. Instead, platform developers are encouraged to sync to android-latest-release, which is always set to the latest AOSP release branch. Currently, this points to android15-qpr2-release, which is the branch corresponding to the second quarterly release of Android 15. In June, it’ll presumably automatically point to android16-release, which should be the branch for the initial release of Android 16.

The android-latest-release branch is also where Google advises proposing new changes, as changes submitted to aosp-main will not be merged. Google said it will not notify developers whether their proposed changes are accepted or rejected. Therefore, the only way to determine if a change is included in a future Android release is to check for it in the android-latest-release branch.

In addition to these workflow changes, Google also confirmed that:

• No changes will be made to the development process for AndroidX, i.e. Android Jetpack support libraries. Jetpack libraries have always been developed fully 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 be halted once the branch is locked, but Google will still release CI builds of some release branches (like android15-release, android15-tests-dev), according to information reposted by Chinese media. Furthermore, Google told us that it will continue to support the existing Android developer preview/beta programs, but that 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 significantly simplify its development process, as it eliminates the need to manage merge conflicts between the public AOSP branch and its internal Android development branch. The company can justify this change by bringing up that external contributions are minimal compared to the overall volume of annual changes. However, these contributions, though small in number, prove that Google does receive some valuable input from external developers. Whether these changes will deter developers from proposing contributions remains to be seen, but they undoubtedly make contributing to AOSP less convenient.