Android OS development will now fully happen behind closed doors, but Google says it’s committed to releasing source code<\/h5>\n\n\n\n
By Mishaal Rahman<\/p>\n\n\n\n TL;DR<\/p>\n\n\n\n No matter the manufacturer, every Android phone<\/a> 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.<\/p>\n\n\n\n You\u2019re reading an Authority Insights<\/strong> story. Discover Authority Insights<\/a> for more exclusive reports, app teardowns, leaks, and in-depth tech coverage you won\u2019t find anywhere else.<\/p>\n\n\n\n The Android Open Source Project, or AOSP<\/a> 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\u2019s One UI<\/a>.<\/p>\n\n\n\n Like many other open-source projects, AOSP accepts code contributions from third-party developers. However, Google<\/a> conducts most AOSP development itself, as it \u201ctreats the Android project as a full-scale product development operation\u201d to \u201censure the vitality of Android as a platform and as an open-source project.\u201d 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<\/a> \u201cdevelopers and OEMs to use a single version [of Android] without tracking unfinished future work just to keep up.\u201d<\/p>\n\n\n\n A screenshot of the landing page for the Android Open Source Project.<\/p>\n\n\n\n To balance AOSP\u2019s 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\u2019s internal branch is restricted to companies with a Google Mobile Services (GMS)<\/a> licensing agreement.<\/p>\n\n\n\n While some OS components, such as Android\u2019s Bluetooth stack, are developed publicly in the AOSP branch, most components, including the core Android OS framework, are developed privately within Google\u2019s internal branch. Google confirmed to Android Authority<\/em> that it will soon shift all Android OS development to its internal branch, a change intended to streamline its development process.<\/p>\n\n\n\n Because Google develops large portions of Android in its internal branch, the public AOSP branch often lags far behind what\u2019s available privately. This difference is apparent when comparing feature and API availability between a clean AOSP build and Google\u2019s latest Android 16<\/a> beta, which was built from its internal branch. While the shift to trunk-based development<\/a> reduced this discrepancy, it persists and continues to pose challenges for Google.<\/p>\n\n\n\n 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<\/a> 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\u2019s length varies between AOSP and Google\u2019s internal branch. While a fix for this specific issue is straightforward, numerous other<\/a> AOSP patches trigger similar merge conflicts when integrated into Google\u2019s internal branch.<\/p>\n\n\n\n Likewise, developing Android\u2019s new unlocked-only storage area API required a Google engineer to cherry-pick a patch<\/a> 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Google confirmed to Android Authority<\/em> that it is committed to publishing Android\u2019s source code, so this change doesn\u2019t mean that Android is becoming closed-source<\/strong>. The company will continue to publish the source code for new Android releases, so when Google releases Android 16<\/a> later this year, we\u2019ll get the source code for the update. In addition, Google will continue to publish the source code for Android\u2019s Linux kernel fork<\/a>, as it is licensed under GPLv2, which mandates source code releases, and is separate from AOSP.<\/p>\n\n\n\n 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\u2019re 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.<\/p>\n\n\n\n A screenshot of the AOSP Gerrit, the web-based code review system used by Google.<\/p>\n\n\n\n Beginning next week, all Android development will occur within Google\u2019s internal branches<\/strong>, and the source code for changes will only be released when Google publishes a new branch containing those changes<\/strong>. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.<\/p>\n\n\n\n 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\u2019t expect this change to accelerate OS updates for your phone.<\/p>\n\n\n\n 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<\/a>, 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.<\/p>\n\n\n\n LineageOS 22.2<\/a> is based on the AOSP android-15.0.0_r20 release tag, which contains the latest changes in the March 2025 quarterly release.<\/p>\n\n\n\n External developers who enjoy reading or contributing to AOSP will likely be dismayed by this news, as it reduces their insight into Google\u2019s 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\u2019ll no longer be able to track changes in AOSP.<\/p>\n\n\n\n For reporters, this change means less access to potentially revealing information, as AOSP patches often provide insights into Google\u2019s development plans. For instance, a code change I spotted in AOSP revealed the Pixel\u2019s webcam feature<\/a> months before its official release. Similarly, I used hints in AOSP to deduce Android 16\u2019s 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<\/a>. 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.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n![\"Android](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Android_Open_Source_Project_landing_page_on_an_Android_phone-scaled.jpg\" "\\"Android")
<\/figure>\n\n\n\n\n
![\"Screenshot](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Screenshot_of_AOSP_homepage.jpg\" "\\"Screenshot")
<\/figure>\n\n\n\nTo simplify Android OS development, Google will no longer have two \u2018main\u2019 branches<\/h2>\n\n\n\n
![\"Comment](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Comment_about_merge_issue_for_new_accessibility_setting.png\" "\\"Comment")
<\/figure>\n\n\n\n![\"Screenshot](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Screenshot_of_code_change_fixing_merge_issue_for_storage_area_API.png\" "\\"Screenshot")
<\/figure>\n\n\n\nWhat does this mean for us?<\/h2>\n\n\n\n
![\"Screenshot](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Screenshot_of_AOSP_Gerrit.jpg\" "\\"Screenshot")
<\/figure>\n\n\n\n![\"Build](\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Build_ID_for_March_2025_quarterly_release_tag.jpg\" "\\"Build")
<\/figure>\n\n\n\n
\n\n\n\n