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’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’s Windows 11 requirements and Recall feature with AI analysis kind of gives away where they’re headed.
https://www.androidauthority.com/google-not-killing-aosp-3566882/
Some people are speculating that Google is planning to discontinue AOSP, but the company says these claims are false.
By Mishall Rahman
TL;DR
- 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.
- The company says this is because it’s shifting its AOSP reference target from Pixel hardware to a virtual device called “Cuttlefish” to be more neutral.
- While Google insists AOSP isn’t going away, developers must now reverse-engineer changes, making the process for supporting Pixel devices more difficult.
Earlier this year, Google announced it would develop the Android OS fully in private 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.
Is AOSP going away? Google says no
As promised, Google published the source code for Android 16 this week, allowing independent developers to compile their own builds of the new operating system. This source code was uploaded to the Android Open Source Project (AOSP), as usual, under the permissive Apache 2.0 license.
However, multiple developers quickly noticed a glaring omission from the Android 16 source code release: the device trees for Pixel devices were missing. Google also failed to upload new driver binaries 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’s release was concerning.
These omissions led some to speculate this week that Google was taking the first step in a plan to discontinue AOSP. In response, Google’s VP and GM of Android Platform, Seang Chau, refuted these claims. He addressed the speculation in a post on X, stating that “AOSP is NOT going away.”
He also confirmed the omission of Pixel device trees is intentional, stating that “AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google.” Instead of supporting AOSP builds on Pixel devices, Google will support the virtual Android device “Cuttlefish” 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.
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, “AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.” In that regard, Cuttlefish is a more appropriate reference target because it isn’t a heavily customized piece of consumer hardware like a Pixel phone. However, since Cuttlefish is a virtual device, it can only simulate how hardware features behave, making it an imperfect reference in some ways.
How do these changes affect custom ROM development?
The more significant issue, however, is the impact this decision will have on developers who build custom ROMs — the community term for hobbyist forks of AOSP. Nolen Johnson, a long-time contributor and reviewer for the LineageOS project, says the process of building these ROMs for Pixel phones will become “painful” moving forward.
Previously, Google made it simple for developers to build AOSP for Pixel devices, but that support is now gone. Developers simply had to “pull the configurations [that] Google created,” add their customizations, and then build. Now, however, they will need to take the old device trees that Google released for Android 15 and “blindly guess and reverse engineer from the prebuilt [binaries] what changes are needed each month.”
This is because making a full Android build for a device — not just a GSI — requires a device tree. This is a “collection 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.” While Google previously handled this work, developers must now create their own device trees without access to the necessary proprietary source code.
Furthermore, Google’s decision to squash the kernel source code’s commit history also hinders custom development. The Pixel’s kernel source code was often used as a “reference point for other devices to take features, bug fixes, and security patches from,” but with the history now reduced to a single commit, this is no longer feasible.
While Google is under no obligation to release device trees, provide driver binaries, or share the full kernel commit history (in fact, it’s one of the few device makers to do these things), it has done so for years. The company’s 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.
Google’s 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 GrapheneOS 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.
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.