{"id":12210,"date":"2025-06-12T08:39:26","date_gmt":"2025-06-12T15:39:26","guid":{"rendered":"https:\/\/jasonsblog.ddns.net\/?p=12210"},"modified":"2025-06-12T08:39:26","modified_gmt":"2025-06-12T15:39:26","slug":"aosp-isnt-dead-but-google-just-landed-a-huge-blow-to-custom-rom-developers","status":"publish","type":"post","link":"https:\/\/jasonsblog.ddns.net\/index.php\/2025\/06\/12\/aosp-isnt-dead-but-google-just-landed-a-huge-blow-to-custom-rom-developers\/","title":{"rendered":"AOSP Isn\u2019t Dead, but Google Just Landed a Huge Blow to Custom Rom Developers"},"content":{"rendered":"\n<p>It would appear that Google is purposely trying to hamper custom ROM developers with their Pixel devices, a long favorite of custom ROM users not to mention those using Linux phone operating systems. There seems to be a lot of movement of <a href=\"https:\/\/jasonsblog.ddns.net\/index.php\/2024\/11\/11\/apple-removes-ability-to-run-unsigned-apps-in-macos-15-1\/\" target=\"_blank\" rel=\"noreferrer noopener\">big tech megacorps to further restrict their platforms<\/a>, and you&#8217;d have to think this lines up with the coming digital ID and digital surveillance system they have planned. One of the strategies to keep people from running custom ROMs is locked phones to carriers due to the price being subsidized. Also, Google has been vigorously working on an Android replacement that is closed source as well. With the right amount of disruptive cyber events, a complete lock down of computer equipment could be easily mandated. And Microsoft&#8217;s Windows 11 requirements and <a href=\"https:\/\/jasonsblog.ddns.net\/index.php\/2024\/05\/21\/microsoft-announces-technology-that-takes-screenshots-of-everything-you-do-this-is-pretty-creepy\/\" target=\"_blank\" rel=\"noreferrer noopener\">Recall<\/a> feature with AI analysis kind of gives away where they&#8217;re headed. <\/p>\n\n\n\n<p><a href=\"https:\/\/www.androidauthority.com\/google-not-killing-aosp-3566882\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/www.androidauthority.com\/google-not-killing-aosp-3566882\/<\/a><\/p>\n\n\n<div class=\"wp-block-ub-divider ub_divider ub-divider-orientation-horizontal\" id=\"ub_divider_1e93739a-ecaf-4d39-9774-9eacd57f7b28\"><div class=\"ub_divider_wrapper\" style=\"position: relative; margin-bottom: 2px; width: 100%; height: 2px; \" data-divider-alignment=\"center\"><div class=\"ub_divider_line\" style=\"border-top: 2px solid #ccc; margin-top: 2px; \"><\/div><\/div><\/div>\n\n\n<h5 class=\"wp-block-heading\">Some people are speculating that Google is planning to discontinue AOSP, but the company says these claims are false.<\/h5>\n\n\n\n<p>By Mishall Rahman<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/03\/Android_figures_standing_around_Pixel_phone_with_AOSP_home_page_showing-scaled.jpg\" alt=\"Android figures standing around Pixel phone with AOSP home page showing\" title=\"Android figures standing around Pixel phone with AOSP home page showing\"\/><\/figure>\n\n\n\n<p>TL;DR<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google has made it harder to build custom Android ROMs for Pixel phones by omitting their device trees and driver binaries from the latest AOSP release.<\/li>\n\n\n\n<li>The company says this is because it\u2019s shifting its AOSP reference target from Pixel hardware to a virtual device called \u201cCuttlefish\u201d to be more neutral.<\/li>\n\n\n\n<li>While Google insists AOSP isn\u2019t going away, developers must now reverse-engineer changes, making the process for supporting Pixel devices more difficult.<\/li>\n<\/ul>\n\n\n\n<p>Earlier this year, Google announced it would <a href=\"https:\/\/www.androidauthority.com\/google-android-development-aosp-3538503\/\">develop the Android OS fully in private<\/a> to simplify its development process. By focusing its efforts on a single internal branch, Google aimed to streamline work that was previously split. The news initially spooked some in the Android development community, but the controversy quickly subsided. The impact was minimal, as Google was already developing most of Android behind closed doors and promised that source code releases would continue. Now, however, a recent omission from Google has rekindled fears that the company might stop sharing source code for new Android releases. Google has stated these concerns are unfounded, but other new changes make it harder for the custom ROM community to thrive on Pixel devices.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Is AOSP going away? Google says no<\/h2>\n\n\n\n<p>As promised, Google published the <a href=\"https:\/\/www.androidauthority.com\/android-16-source-code-3563703\/\">source code for Android 16 this week<\/a>, allowing independent developers to compile their own builds of the new operating system. This source code was uploaded to the Android Open Source Project (<a href=\"https:\/\/www.androidauthority.com\/aosp-explained-1093505\/\">AOSP<\/a>), as usual, under the permissive Apache 2.0 license.<\/p>\n\n\n\n<p>However, multiple developers quickly noticed a glaring omission from the Android 16 source code release: the device trees for Pixel devices <a href=\"https:\/\/android.googlesource.com\/platform\/manifest\/+\/refs\/heads\/android16-release%5E%21\/\" target=\"_blank\" rel=\"noreferrer noopener\">were missing<\/a>. Google also failed to upload new <a href=\"https:\/\/developers.google.com\/android\/drivers\" target=\"_blank\" rel=\"noreferrer noopener\">driver binaries<\/a> for each Pixel device and released the kernel source code with a squashed commit history. Since Google has shared the device trees, driver binaries, and full kernel source code commit history for years, its omission in this week\u2019s release was concerning.<\/p>\n\n\n\n<p>These omissions led <a href=\"https:\/\/youtu.be\/K7-R3l9GWvI?t=76\" target=\"_blank\" rel=\"noreferrer noopener\">some to speculate<\/a> this week that Google was taking the first step in a plan to discontinue AOSP. In response, Google\u2019s VP and GM of Android Platform, Seang Chau, refuted these claims.&nbsp;He addressed the speculation in a <a href=\"https:\/\/x.com\/seangchau\/status\/1933029688202703062\" target=\"_blank\" rel=\"noreferrer noopener\">post on X<\/a>, stating that \u201cAOSP is NOT going away.\u201d<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/06\/Google-denies-discontinuing-AOSP.jpg\" alt=\"Google denies discontinuing AOSP\" title=\"Google denies discontinuing AOSP\"\/><\/figure>\n\n\n\n<p>He also confirmed the omission of Pixel device trees is intentional, stating that \u201cAOSP needs a reference target that is flexible, configurable, and affordable \u2014 independent of any particular hardware, including those from Google.\u201d Instead of supporting AOSP builds on Pixel devices, Google will support the virtual Android device \u201cCuttlefish\u201d as its reference target. Cuttlefish runs on PCs, allowing Google and platform developers to test new hardware features. Google will also continue to support GSI targets, which are generic system images that can be installed on nearly any Android device.<\/p>\n\n\n\n<p>On one hand, this logic is sound. Google wants to move away from using Pixels as the AOSP reference device and is making changes to that effect. As Seang Chau notes, \u201cAOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.\u201d In that regard, Cuttlefish is a more appropriate reference target because it isn\u2019t a heavily customized piece of consumer hardware like a <a href=\"https:\/\/www.androidauthority.com\/google-pixel-phones-ranked-3426118\/\">Pixel phone<\/a>. However, since Cuttlefish is a virtual device, it can only simulate how hardware features behave, making it an imperfect reference in some ways.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How do these changes affect custom ROM development?<\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.androidauthority.com\/wp-content\/uploads\/2025\/02\/LineageOS-Logo-2-of-3.jpg\" alt=\"LineageOS Logo (2 of 3)\" title=\"LineageOS Logo (2 of 3)\"\/><\/figure>\n\n\n\n<p>The more significant issue, however, is the impact this decision will have on developers who <a href=\"https:\/\/www.androidauthority.com\/build-custom-android-rom-720453\/\">build custom ROMs<\/a> \u2014 the community term for hobbyist forks of AOSP. Nolen Johnson, a long-time contributor and reviewer for the <a href=\"https:\/\/www.androidauthority.com\/lineageos-install-guide-893303\/\">LineageOS<\/a> project, says the process of building these ROMs for Pixel phones will become \u201cpainful\u201d moving forward.<\/p>\n\n\n\n<p>Previously, Google made it simple for developers to build AOSP for Pixel devices, but that support is now gone. Developers simply had to \u201cpull the configurations [that] Google created,\u201d add their customizations, and then build. Now, however, they will need to take the old device trees that Google released for Android 15 and \u201cblindly guess and reverse engineer from the prebuilt [binaries] what changes are needed each month.\u201d<\/p>\n\n\n\n<p>This is because making a full Android build for a device \u2014 not just a GSI \u2014 requires a device tree. This is a \u201ccollection of configuration files that define the hardware layout, peripherals, proprietary file listings, and other details for a specific device, allowing the build system to build a proper image for that device.\u201d While Google previously handled this work, developers must now create their own device trees without access to the necessary proprietary source code.<\/p>\n\n\n\n<p>Furthermore, Google\u2019s decision to squash the kernel source code\u2019s commit history also hinders custom development. The Pixel\u2019s kernel source code was often used as a \u201creference point for other devices to take features, bug fixes, and security patches from,\u201d but with the history now reduced to a single commit, this is no longer feasible.<\/p>\n\n\n\n<p>While Google is under no obligation to release device trees, provide driver binaries, or share the full kernel commit history (in fact, it\u2019s one of the few device makers to do these things), it has done so for years. The company\u2019s reason for doing so was because the Pixel was treated as a reference platform for AOSP, so developers needed an easy way to build for it.<\/p>\n\n\n\n<p>Google\u2019s decision to now discontinue the Pixel as an AOSP reference device is unfortunate, as it has pulled the rug from under developers like the teams at LineageOS and <a href=\"https:\/\/www.androidauthority.com\/grapheneos-3287030\/\">GrapheneOS<\/a> who build Android for Pixel devices. These developers will still be able to build AOSP for Pixel devices, but it will now be more difficult and painful to do so than before, as they will need to build their own device trees from scratch. This also brings Pixels down to the same level as other Android devices, as developers have long had to build their own device trees, pull binaries, and deal with squashed kernel source code commit history on other devices.<\/p>\n\n\n\n<p>The silver lining is that Pixels remain super easy to bootloader unlock and grab factory images for, but this will definitely increase the work needed to be done by developers for a stable custom ROM experience.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>It would appear that Google is purposely trying to hamper custom ROM developers with their Pixel devices, a long favorite of custom ROM users not to mention those using Linux phone operating systems. There seems to be a lot of movement of big tech megacorps to further restrict their platforms, and you&#8217;d have to think [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7],"tags":[],"class_list":["post-12210","post","type-post","status-publish","format-standard","hentry","category-tech","category-world"],"blocksy_meta":[],"featured_image_src":null,"author_info":{"display_name":"Jason","author_link":"https:\/\/jasonsblog.ddns.net\/index.php\/author\/jturning\/"},"_links":{"self":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/12210","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/comments?post=12210"}],"version-history":[{"count":1,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/12210\/revisions"}],"predecessor-version":[{"id":12211,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/posts\/12210\/revisions\/12211"}],"wp:attachment":[{"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/media?parent=12210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/categories?post=12210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jasonsblog.ddns.net\/index.php\/wp-json\/wp\/v2\/tags?post=12210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}