Android OS development goes completely private but Google still wants help from other developers

Earlier this week we broke the news that Google will soon Develop Android OS fully in private. Currently, Google is developing some Android OS components, such as Bluetooth Stack, public, but the company changes all work to its internal branch in an attempt to streamline the development process. The move has little effect on end users or app developers, but it affects the workflow to platform developers, especially those without ties to one of Google’s OEM partners. Fortunately, 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 made in response to this news.

First, Google has confirmed to Android Authority That platform developers will still be able to submit updates to the public Android Open Source project (AOSP) Gerrit, the online code assessment system used by Google for AOSP development. Developers working for a company with one Google Mobile Services (GMS) License can submit patches through partner Gerrit, who is not available to the public. In both cases, these updates will be reviewed by Google engineers, and if accepted, it will be cherry -packed and merged into the company’s internal branch of Android for inclusion in a future release.

Depending on the specific project, it is basically how external code contributions were already handled. However, this workflow is slightly different for AOSP-FIRST projects such as Bluetooth, virtualization or the construction system, as development on these projects has historically been done in public. Regardless, platform developers who are interested in submitting patches to AOSP may continue to do so, even when Google is taking the development of Android OS fully private, although they must be aware that their patches will be based on code that may be weeks behind Google’s internal code base. Any merger conflicts that occur must be solved between the platform developer and the Google engineers who are assigned to undergo the note.

According to documentation shared with Google’s OEM partners (and redistributed by Chinese media,), aosp-main The branch will be locked and set for writing protected. Therefore, platform developers are recommended to no longer sync aosp-main branch of building machines. Instead are platform developers cheer to sync with android-latest-releaseAs is always set to the latest AOSP release branch. At the moment this is pointing to android15-qpr2-releasewhich is the branch that corresponds to the second quarterly release of Android 15. In June it will probably automatically point to android16-releasethat should be the branch for the first release of Android 16.

The android-latest-release Branch is also where Google recommends suggesting new changes, such as changes sent to aosp-main will not be merged. Google said it will not notify developers of their proposed changes being 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 android-latest-release branch.

In addition to these work flow changes, Google also confirmed it:

• No changes will be made in the development process for Androidx, IE Android jetpack Support libraries. Jetpack libraries have always been fully developed in public and have never technically been a part of aosp-main (The main development branch of jetpack is actually androidx-main).
• Continuous integration (CI) builds off aosp-main will be stopped when the branch is locked, but Google will still release the CI building of some release branches (as android15-release,, android15-tests-dev), according to information covered 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 publish the CI building of its internal main branch.

Google’s decision to move the Android OS development behind closed doors will significantly simplify the development process, as it eliminates the need to handle merging conflicts between the public AOSP branch and its internal Android development branch. The company can justify this change by pointing out that external contributions are minimal compared to the total volume of annual changes. However, these contributions, although small in number, prove that Google receives some valuable input from external developers. Whether these changes will deter developers from proposing contributions remains to be seen, but they undoubtedly make AOSP less practical.