Thread by @GrapheneOS

We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS () and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.grapheneos.org/faq#future-dev…

In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early.

We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release.

Due to AOSP no longer having device support, we need to build it ourselves. We can start from the Android 15 QPR2 device support, remove the outdated code and update the configurations. We have tooling to automate generating device support setups which will need major expansions.

Since our port to Android 16 is going to be delayed by a week or more, we're in the process of backporting the Android 16 firmware/drivers released on June 10 to the previous releases. This is not something we can do in general so we still need to port to Android 16 this month.

Despite our lead developer who has done 90% of the ports for several years being conscripted into an army, we were still able to complete the initial port to Android 16 in under 2 days, but without device support. Our extensive preparation in April and especially May paid off.

It's important to get an experimental release out quickly to begin extensive public testing. There are usually many issues found in testing. For a yearly release, we usually get out an experimental release in a day, an Alpha channel release in 2 days and need 4-6 more releases.

Google has released a statement claiming AOSP is not being discontinued. This should be taken with a grain of salt, especially considering that they made similar public statements recently followed by discontinuing significant parts of AOSP on June 10.

https://x.com/seangchau/status/1933029688202703062

Google is in the process of likely having the company broken up due to losing an antitrust lawsuit from the US government and being in the process of losing several more. There's a high chance of Google losing control of Android in the next couple years.

nytimes.com/2025/04/21/tec…

The leaked information we received in April 2025 indicates that the reasoning they're making substantial cuts to Android is primarily cutting costs, perhaps in anticipation of it being split from Google. The courts should investigate Google's recent changes and cuts to Android.

Google has been accelerating their crackdown on alternate mobile hardware and software with the Play Integrity API combined with laying off many people working on Android and cutting parts of the project. They disallow their OEM partners from competing so others cannot take over.

It's no wonder that Android and Chrome engineers at Google are leaking tons of information when the company is in an extraction mode trying to get as much out of each as possible prior to Google being broken up. Regulatory action needs to move faster and take this into account.

A successful mobile OS will need near perfect iOS or Android app compatibility. For Android, compatibility means a solid fork of AOSP even if it's only used within a VM on a more modern microkernel-based OS. Google made an open platform, unlike Apple, and could not prevent this.

For years, Google has been using extraordinarily anti-competitive Google Mobile Services (GMS) licensing agreements with OEMs to disallow competition. To further prevent competition, they made the Play Integrity API where apps devs are convinced to check for valid GMS licensing.

Google's GMS licensing to OEMs has been a barrier to GrapheneOS and others being able to work with Android OEMs. Courts in multiple countries have found this to be illegal. Play Integrity API, Play Store automatic protection, etc. are GMS license enforcement via code instead.

If the Pixel 10 does meet our requirements, we'll support it, but it will take significantly more time and effort to develop support for it. At the end of the year, Qualcomm should finally release a new SoC providing hardware memory tagging. If they do, we can shift focus to it.

Once an OEM offering the service of making custom devices has a platform based on a new Qualcomm Snapdragon SoC with hardware memory tagging support, we can do a crowdfunding campaign to raise the money needed to have them build a device for us. We have talked with a couple OEMs.

The baseline will be several million dollars, which can be spread out across the cost of preordered devices. This is the cost of making a modern, secure device with a secure element and the other requirements we have for one instead of a low-end device with outdated hardware.

There will be a cost of a million or more dollars per year of additional support. Providing 7 years of proper support like Pixels would be very expensive. We definitely wouldn't be releasing a new device every year as the overlapping costs for all of it would be ridiculous.

@lefty_meltdown The requirements listed at are currently only provided by Pixels. That's why we think it will be necessary to pay an OEM to make a custom Snapdragon device for us with everything we need and longer term support than non-Pixel OEMs are providing.grapheneos.org/faq#future-dev…

@Shalom2026 @m3658024941 @OmbraMono iodéOS is a fork of LineageOS which is a fork of AOSP. Changes to AOSP which impact us negatively are also going to impact them negatively through LineageOS.

Pixels are still the only devices meeting our hardware requirements. Using less secure devices doesn't solve anything.