Google is making big changes to how it develops the Android OS

No matter the manufacturer, every Android phone has one thing in common: its software base. Manufacturers can heavily customize the look and feel of the Android OS they ship on their Android devices, but under the hood, the core system functionality is derived from the same open-source foundation: the Android Open Source Project. After over 16 years, Google is making big changes to how it develops the open source version of Android in an effort to streamline its development.

The Android Open Source Project, or AOSP for short, is an operating system that Google releases under the Apache 2.0 License. Apache 2.0 is a software license that allows anyone to use, distribute, or modify and distribute operating systems based on AOSP without the need to pay any licensing fees or release source code. This permissive licensing structure has facilitated the widespread adoption of AOSP, leading to the creation of customized forks like Samsung’s One UI.

Like many other open-source projects, AOSP accepts code contributions from third-party developers. However, Google conducts most AOSP development itself, as it “treats the Android project as a full-scale product development operation” to “ensure the vitality of Android as a platform and as an open-source project.” Therefore, Google has the final say on what code can be merged into AOSP and when new version source code is released. The company develops AOSP components privately to allow “developers and OEMs to use a single version [of Android] without tracking unfinished future work just to keep up.”

To balance AOSP’s open nature with its product development strategy, Google maintains two primary Android branches: the public AOSP branch and its internal development branch. The AOSP branch is accessible to anyone, while Google’s internal branch is restricted to companies with a Google Mobile Services (GMS) licensing agreement.

While some OS components, such as Android’s Bluetooth stack, are developed publicly in the AOSP branch, most components, including the core Android OS framework, are developed privately within Google’s internal branch. Google confirmed to Android Authority that it will soon shift all Android OS development to its internal branch, a change intended to streamline its development process.

To simplify Android OS development, Google will no longer have two ‘main’ branches

Because Google develops large portions of Android in its internal branch, the public AOSP branch often lags far behind what’s available privately. This difference is apparent when comparing feature and API availability between a clean AOSP build and Google’s latest Android 16 beta, which was built from its internal branch. While the shift to trunk-based development reduced this discrepancy, it persists and continues to pose challenges for Google.

This discrepancy forces Google to spend time and effort merging patches between the public AOSP branch and its internal branch. Due to how different the branches are, merge conflicts often arise. Take for example this patch that enables screen magnifier functionality for the navigation bar and keyboard. The patch introduces a new accessibility setting, which is placed at the end of the list of accessibility settings. This creates a merge conflict as the list’s length varies between AOSP and Google’s internal branch. While a fix for this specific issue is straightforward, numerous other AOSP patches trigger similar merge conflicts when integrated into Google’s internal branch.

Likewise, developing Android’s new unlocked-only storage area API required a Google engineer to cherry-pick a patch from the internal branch to AOSP to resolve a merge conflict. This is because while the API was developed in AOSP, the file containing new Android build flags was developed internally. As a result, a patch updating the build flag files had to be submitted internally and then applied to AOSP.

There are likely countless examples of merge conflicts like this, which is why Google is doing away with its current two-pronged Android development strategy and instead shifting all development internally.

What does this mean for us?

Google confirmed to Android Authority that it is committed to publishing Android’s source code, so this change doesn’t mean that Android is becoming closed-source. The company will continue to publish the source code for new Android releases, so when Google releases Android 16 later this year, we’ll get the source code for the update. In addition, Google will continue to publish the source code for Android’s Linux kernel fork, as it is licensed under GPLv2, which mandates source code releases, and is separate from AOSP.

What will change is the frequency of public source code releases for specific Android components. Some components like the build system, update engine, Bluetooth stack, Virtualization framework, and SELinux configuration are currently AOSP-first, meaning they’re developed fully in public. Most Android components like the core OS framework are primarily developed internally, although some features, such as the unlocked-only storage area API, are still developed within AOSP.

Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.

This change will have minimal impact on regular users. While it streamlines Android OS development for Google, potentially affecting the speed of new version development and bug reduction, the overall effect will likely be imperceptible. Therefore, don’t expect this change to accelerate OS updates for your phone.

This change will also have minimal impact on most developers. App developers are unaffected, as it pertains only to platform development. Platform developers, including those who build custom ROMs, will largely also see little change, since they typically base their work on specific tags or release branches, not the main AOSP branch. Similarly, companies that release forked AOSP products rarely use the main AOSP branch due to its inherent instability.

External developers who enjoy reading or contributing to AOSP will likely be dismayed by this news, as it reduces their insight into Google’s development efforts. Without a GMS license, contributing to Android OS development becomes more challenging, as the available code will consistently lag behind by weeks or months. This news will also make it more challenging for some developers to keep up with new Android platform changes, as they’ll no longer be able to track changes in AOSP.

For reporters, this change means less access to potentially revealing information, as AOSP patches often provide insights into Google’s development plans. For instance, a code change I spotted in AOSP revealed the Pixel’s webcam feature months before its official release. Similarly, I used hints in AOSP to deduce Android 16’s earlier release date, while a now-deleted code change I spotted last week gave us our first public mention of the upcoming Google Pixel 10. While these types of leaks likely did not trigger this change, it will undoubtedly affect our ability to report on upcoming Android features and devices.

Ultimately, I think this change makes sense, even if the optics look bad for Google. Google had three options here: Maintain the status quo, shift all development internally, or make all development public. Considering Google’s stated rationale for private Android development and its recent transition to trunk-based development, its decision to consolidate work under a single, internal branch, streamlining both OS development and source code releases, is understandable.

Google will share more details about this change when it announces it later this week. If you’re interested in learning more, be sure to keep an eye out for the announcement and new documentation on source.android.com.