Android closed-source progress update: Google no longer offers Pixel firmware compilation

On June 10, US time, Aifaner independently learned that the AOSP code released by Google today does not provide the vendor binary of Pixel devices, that is, the necessary drivers and other documents as in previous years. The driver binary files officially provided by Google for each Pixel device are currently stuck in the Android 15.0.0 version. The Android 16 version AOSP code provided this time can only be built as a “Generic System Image” (GSI). GSI can be understood as a testing environment provided to OEMs, which is only used to verify whether the hardware level of the device is compatible with the latest Android operating system and complies with Google specifications. It is not a complete system and lacks many features. This new development not only reinforces the “Google gradually shrinks AOSP until it ceases to exist as an open-source project” mentioned by Love Fanger in the article, but also creates a huge obstacle for third-party operating systems (ROMs) developed for Pixel devices. In the past, Google would release the AOSP code along with the binary vendor of Pixel devices. ROM developers can package it manually, thus ensuring that ROM support for the device is complete. Since Google has been doing this in the past, it has brought great convenience to developers. All Pixel devices have also been used by developers as “native developer computers” for a long time. Pixel phones are often the first to be compatible with various third-party ROMs. Starting with Android 16, Google has decided not to provide this convenience. Developers will not be able to modify the AOSP code themselves, package it into firmware, and install it on Pixel devices. If third-party operating system (Android ROM) developers want to continue working, starting with Android 16, they will have to reverse engineer the Pixel upgrade package released by Google and do a lot of unnecessary adaptation work to make the ROM support Pixel. There are currently eight Pixel phones on sale in the US market. If ROM developers want to adapt them all, they will have to reverse engineer each one once. This will severely limit the scope of adaptation of third-party ROMs, affect their performance in the market, and cause restrictions on users of third-party ROMs. According to Aifaner’s understanding, in principle, only OEM partners who have signed a GMS agreement with Google can obtain the “full amount of AOSP” code in the past for the first time. This further means that ROMs developed based on AOSP code will be difficult to develop Android 16-based versions – unless the development team somehow signs a licensing agreement with Google, or through other OEMs that have signed up with Google to get the code the team needs. The well-known ROM team GrapheneOS also confirmed to Aifaner that some of the situations mentioned in our report have now become a reality. The team is also studying how to deal with this change at Google in the short and long term. The team posted on X (formerly Twitter) that because the team did not have OEM partner permissions, they could not get the AOSP code immediately, and they also got the “emasculated version” that lacked the proprietary part of the manufacturer’s code. This situation seriously slowed down the team’s development of GrapheneOS based on the Android 16 version and ported it to Pixel devices. “We are more prepared for the Android 16 version than all previous versions. Because we don’t have OEM partner permissions, we had to do a lot of reverse engineering. Even our developers used previous porting files to do exercises. “” However, these changes made by the Android team made it extremely difficult for us to port Android 16 and subsequent versions. This also made it more difficult for subsequent new Pixel devices to support GrapheneOS. It seems that we have to speed up the progress of GrapheneOS phones. “Although we have not made substantial contributions to Google’s commercial interests in the past, third-party ROM developers are still an important part of the Android operating system ecosystem. Many of the features that exist in the Android operating system today were originally submitted to the AOSP project by third-party ROM developers. The GrapheneOS team has previously posted an attempt to privately recruit OEMs to give themselves a full AOSP code. The team said: “The development we do upstream of Android has brought benefits to every Android OEM. If you can cooperate with us, you will benefit even more.” As for why Google is doing this, Aifaner mentioned in a previous exclusive report: Android open source has spawned a large and segmented market, such as third-party ROMs, non-certified Android devices, etc. The market is very active. But today, when the Android ecosystem is already very sound, these markets no longer benefit Google. Google may not need to continue to do free labor for these markets for reasons similar to “fat water does not flow out of the field”. Previously, in March this year, we cited a large number of independently obtained information to provide a fully detailed report on some of the major plans and actions within Google’s “Devices and Services” department. A large amount of information points out that Google plans to continuously reduce the open-source nature of the Android project through some low-key actions. What is confirmed to have happened so far is: * Google no longer maintains the current public branch of AOSP, and gradually closes the relevant supporting resources * Google no longer provides third-party unauthorized developers with the ability to compile and build Pixel devices. We have learned that Google is still discussing internally, but has not yet confirmed whether to do it, and the specific approach: * Google will no longer provide AOSP source code other than statutory open-source obligations (such as GPL and other agreement parts), but will provide it on demand; * Delay the release, or even no longer provide the full amount of AOSP source code; *… The idea of Google gradually narrowing the open-source attributes of Android has been around since the beginning of 2025 at the latest, and the decision-making level is at the senior management level of Google. The execution of the entire strategy will be completed over a longer period of time, at least for several years, until AOSP completely loses the significance of open-source attributes. The purpose behind these actions that have taken place or are still under discussion is not complicated: mainly to save expenses and increase revenue. Fortunately, the direct impact of closed-source AOSP on the industry is not catastrophic, and the intuitive impact on end point mobile phone users is minimal. The vast majority of mainstream mobile phone manufacturers have long signed various licensing partner agreements with Google. Vendors under the existing agreement can still get and use the latest Android source code, obtain Google GMS certification, pre-install Google Play, Gmail and other services and applications normally, and get Google support. Business as usual.