GrapheneOS

Android regularly adds and splits permissions for new API levels. Legacy apps are handled by treating them as requesting the permission to provide a toggle for it. For example, Android 13 converted the existing toggle for disabling notifications for an app into a new POST_NOTIFICATIONS permission.

The Android Open Source Project has infrastructure for this since it's a regular part of the app sandbox and permission model improving. We add Network and Sensors permission toggles in GrapheneOS where Network is based on the existing low-level INTERNET permission and Sensors is entirely new.

Nearly all apps are unaware of these non-standard permissions just as they're unaware of new permissions added by Android before they get upgraded. Therefore, we enable them by default for compatibility but provide the ability for users to disable them at install time like the standard permissions.

For Network, apps request INTERNET, so we provide a toggle for rejecting that request in the initial app install dialog. If it's added in an upgrade, it's disabled by default. For Sensors, apps don't request it so we handle it similarly to how Android handled POST_NOTIFICATIONS for existing apps.

When Network is disabled, we act as if the network is down for compatibility. We won't run network-dependent jobs, various APIs will report it as down and we give errors matching it being down. When Sensors is disabled, sensors not covered by standard permissions give zeroed data and no events.

For usability, apps trying to use those sensors when Sensors is disabled will trigger a notification from the OS which can be disabled on a per-app basis. This informs users about what's going on so they'll know the app is either doing something sketchy or that it may actually require it.

F-Droid has an incorrect approach to installing apps which wrongly warns users about the standard Android POST_NOTIFICATIONS permission, our OTHER_SENSORS permission and previous Android permission additions/splits. They wrongly blamed GrapheneOS and didn't fix it:

https://archive.ph/MtB2J

They're now realizing that it happens with standard Android permissions added / split in new releases. Their approach to installing apps has been incorrect in multiple ways for many years and this is one of them. Their approach to listing which permissions are used by apps is also very incorrect.

F-Droid has a long history of denying issues including covering up serious security flaws. In some cases they eventually ship a fix but still deny it. It's a major factor in why F-Droid is not a safe or trustworthy source of apps due to major security issues not being acknowledged or addressed.

Multiple of the F-Droid developers wrongly blaming their app bug on GrapheneOS in that issue are Calyx contractors. They prioritize attacking GrapheneOS with inaccurate claims and fabricated stories about our team over fixing a bug in their app impacting both GrapheneOS and non-GrapheneOS users.

We've repeatedly brought up F-Droid not properly listing permissions or checking for them. Their understanding of Android's permission model is wrong. The way they list permissions misleads and misinforms users. It's one of many major F-Droid flaws they consistently don't acknowledge or fix.

Due to F-Droid deliberately causing friction and annoyances for GrapheneOS users, we'll be implementing a feature similar to our sandboxed Google Play compatibility layer for it. We'll can resolve deliberate issues created for GrapheneOS users ourselves as we did with Revolut.

GrapheneOS is currently under a state sponsored attack attempting to misrepresent it as being for criminals, which we covered a bit at https://grapheneos.social/@GrapheneOS/114784469162979608. These poorly researched, biased and inaccurate news stories have led to more harassment towards our community and team.

These attacks are taking a multi pronged approach including pushing existing fabricated stories and harassment towards our team. We'd appreciate if our community was more active than usual in debunking misinformation and attacks on our team. It's a very abnormal wave of attacks.

GrapheneOS based on Android 16 has been through extensive public Alpha/Beta testing and should reach our Stable channel today. We'll continue fixing various upstream Android 16 regressions such as the back button issue impacting the stock Pixel OS we fixed in our latest release.

July Android Security Bulletin will likely be published today. We obtained early access to the signed partner preview and confirmed no additional patches were required, so we set the 2025-07-01 patch level last month after we backported Pixel 2025-06-05 driver/firmware patches.

Tomorrow will likely be the first monthly update of Android 16 with a new Android Open Source Project and Pixel stock OS release. We won't need to backport Pixel driver/firmware patches since we're on Android 16 and can simply incorporate and ship the monthly update within hours.

It can be extraordinarily difficult to backport driver/firmware patches due to dependencies on the new major release. We were only able to backport everything required for the 2025-06-05 security patch level because Android 15 QPR2 is much closer to Android 16 than Android 15.

After our Android 16 port was completed yesterday, we started fixing an Android tapjacking vulnerability disclosed last month:

https://taptrap.click/

We have a fix implemented and it will be included in our next release, likely with the monthly Android 16 update tomorrow.

This vulnerability was disclosed to Google in October 2024 and Android still hasn't fixed it. Security researchers should report vulnerabilities to GrapheneOS in addition to Google. This now joins our many other GrapheneOS exclusive fixes for serious Android vulnerabilities.

We've decided to make another release today with our fix for the Android tapjacking vulnerability because we need to fix a DisplayPort alternate mode regression specific to 8th generation Pixels which doesn't impact 9th generation Pixels.

Tags:

• 2025070600 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070500 release:

• backport fix for back button regression in Android 16 from Android 16 QPR1 Beta 2.1
• Pixel 8, Pixel 8 Pro, Pixel 8a: restore using asymmetric MTE mode for userspace instead of the default asynchronous mode
• add back switching to using the Natural display color mode by default
• migrate more device support to adevtool and remove more unused configuration
• improve per-device integration for USB-C port control and pogo pins control to make maintenance easier
• adevtool: remove obsolete overlay handling implementation
• remove Circle to Search feature declaration
• enable Runtime Resource Overlay (RRO) enforcement

Tags:

• 2025070500 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070301 release:

• partially revert upstream changes in Android 16 breaking parts of the lockscreen layout including the date and media info
• Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL: add back feature declaration for Pixel Thermometer support lost in our Android 16 device port migration which prevented fresh installs of the app
• Terminal (virtual machine management app): disable VM console feature since it isn't supported by the stable release of Android 16 outside of debug builds and trying to use it breaks installing the new images (the feature can be enabled once the core OS supports it in production builds)
• update Pixel HAL compatibility matrix version numbers for Android 16
• add lockscreen synchronization failsafe to protect against unknown vulnerabilities
• improve code quality and add unit tests for our strict CVE-2024-50089 protection
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.94
• fix port of our 2-factor fingerprint authentication tests to Android 16

Tags:

• 2025070301 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070300 release:

• fix upstream Android 16 issue causing very large Binder transactions due to the size scaling based on the number of apps installed across all users including base OS apps
• reduce virtual memory reserved for Binder buffers back to 1MiB now that we have a direct fix for the upstream issue causing more to be required and using a larger virtual memory reservation size appears to have a small chance of failing
• revert our fix for a screenshot process crash that's now fixed upstream in Android 16

GrapheneOS based on Android 16 is now available in our Beta channel. There are 2 main known issues which will be fixed in the next release: lockscreen date and media info are not properly displayed due to an upstream AOSP bug and Pixel Thermometer doesn't appear in our App Store.

Last month, we provided the 2025-06-01 Android/Pixel security patch level early in the month before the stock OS release as preparation and then backported Android 16 firmware and kernel/userspace driver patches to provide the 2025-06-05 Android and then Pixel patch levels.

Our 2025062700 release raised the overall patch level to 2025-07-01 since we got early access to it with a verifiable signature and know we already provide the patches. We usually do an early Android Security Bulletin release before the stock OS but it was done for July in June.

Android Security Bulletins are backports of High/Critical severity patches to older Android. Starting this month, the initial release of Android 16 is one of those older releases. It's split into AOSP userspace patches (YYYY-MM-01) and driver/firmware/Linux patches (YYYY-MM-05)

YYYY-MM-05 patch level has a device-specific portion with more driver/firmware patches. For Pixels, it's the Pixel Update Bulletin. Most Pixel Update Bulletin patches aren't specific to Pixels but the Android Security Bulletin doesn't cover Samsung cellular, Broadcom Wi-Fi, etc.

Pixel Update Bulletin patches are what we had to backport to Android 15 QPR2:

https://source.android.com/docs/security/bulletin/pixel/2025-06-01

These were for firmware/drivers/services for Samsung cellular (including the Radio Interface Layer), Broadcom/Qualcomm Wi-Fi/Bluetooth, NVT touchscreen, fingerprint and TPU.

The only part truly specific to Pixels was the TPU patch. Bear that in mind when you look at those Pixel Update Bulletins. Other devices are meant to have their own bulletins covering the same things if they use those components and also further patches. It's fully up to OEMs.

Android Security Bulletin (ASB) is published on the first Monday of the month unless it's a US/Google holiday in which case it gets pushed ahead a day or two. The Android release for the month is a separate thing from the ASB backports, usually published the day after the ASB.

ASB is likely July 7 and the Android OS release is likely July 8. Our aim is to have Android 16 in our Stable channel prior to July 8 so we can ship the initial monthly update to Android 16 instead of needing to backport Pixel Update Bulletin patches which could be infeasible.

Each month, Android has a new stable OS release. It's a monthly, quarterly or yearly release. Quarterly and yearly releases move along the development branch about the same amount and have a similar amount of changes. Those have months of public Developer Previews / Betas first.

Pixels ship the latest monthly, quarterly and yearly release each month. Non-Pixels ship an initial yearly Android release and then only Android Security Bulletin backports until they ship the next yearly release. ASB backports are a subset of the AOSP patches, not all of them.

GrapheneOS needs to follow the stable releases in order to provide the full AOSP privacy/security patches. It also needs to keep up with them in order to ship Pixel driver/firmware patches which are made for the latest stable release, but we'd still need to do this on non-Pixels.

ICEBlock is making incredibly false privacy claims for marketing. They falsely claim it provides complete anonymity when it doesn't. They're ignoring both data kept by Apple and data available to the server but not stored. They're also spreading misinformation about Android:

https://www.iceblock.app/android

Their claims about push notifications on Android compared to iOS are completely false. Both Firebase Cloud Messaging (FCM) and the Apple Push Notification service (APNs) function in a similar way with similar privacy. However, Android does not force using FCM and apps can use other push systems.

iOS forces uses Apple services including getting apps through Apple where they have a record of which apps each person and account has installed and using their push notification service. Both FCM and APNs have tokens. Android doesn't allow apps to access device IDs. Push tokens aren't device IDs.

Apple and Google can identify devices/users based on push tokens obtained by law enforcement from services. Unlike Google, Apple only recently began requiring warrants:

https://www.reuters.com/technology/apple-now-requires-judges-consent-hand-over-push-notification-data-2023-12-12/

ICEBlock's claims about this are highly inaccurate and they haven't acknowledged corrections.

Tags:

• 2025070300 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070100 release:

• increase virtual memory reserved for Binder buffers from 1MiB to 8MiB due to Android 16 having a very large Binder transaction scaling up based on the number of apps and profiles which can go beyond the total size limit and break fully booting the OS, which occurred for a tiny number of our Alpha testers (if you were one of the tiny number of Alpha channel testers running into this, you can sideload this release to resolve the issue)
• fix issues with display of the end session button to avoid it being wrongly displayed for Owner or not displayed for secondary users (we may remove this part of the upstream end session UI or make it optional since the functionality is also in the power menu)
• update Pixel USB HAL to Android 16 (this was omitted in the initial port due to needing special handling for our USB-C port and pogo pins control feature)
• always use UTC as the time zone for build date properties
• kernel (6.6): update to latest GKI LTS branch revision

European authoritarians and their enablers in the media are misrepresenting GrapheneOS and even Pixel phones as if they're something for criminals. GrapheneOS is opposed to the mass surveillance police state these people want to impose on everyone.

https://www.xatakandroid.com/sociedad/cada-vez-que-vemos-google-pixel-pensamos-que-puede-ser-narcotraficante-movil-perfecto-para-crimen-sencilla-razon

There are ongoing coordinated attempts at misleading people about GrapheneOS and Signal in multiple European countries. A consistent pattern are completely unsubstantiated claims about exploits with no evidence. These are contradicted by actual evidence, leaks and their behavior.

GrapheneOS is not immune to exploitation, but the fearmongering done in these ongoing attacks on it is very clearly fabricated. They feel threatened enough by GrapheneOS to engage in coordinated attempts at convincing people that it's unable to protect their privacy and security.

GrapheneOS eliminates many classes of remotely exploitable vulnerabilities and makes the vast majority far harder to exploit. It even puts up a strong fight against attacks advanced forensic data extraction tools with physical access. See https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation for an example.

There's currently an example of one of these attacks on the project ongoing across Swedish forums and social media. This reached our forum at https://discuss.grapheneos.org/d/23535-unsubstantiated-claims-about-sweden-exploiting-grapheneos-with-no-evidence. An account pretending to be just asking questions goes on to pretend to be an expert citing non-existent sources.

This same thing is currently ongoing across several Swedish forums and on social media. It's generally not in English which makes it inaccessible to the broader GrapheneOS and privacy community so they can get away with extraordinary, unsubstantiated claims much more easily.

GrapheneOS is not supposed to stop people installing malware and granting it invasive permission. It does provide alternatives to being coerced into granting invasive permissions by apps via our Storage Scopes, Contact Scopes and other permissions, but it's a user choice.

GrapheneOS similarly not supposed to prevent authorized access to data by someone with the PIN/password and access to the device. Rather, we provide far stronger protection against unauthorized access via exploit protections, 2-factor fingerprint unlock, duress PIN/password, etc.

Our features page at https://grapheneos.org/features provides an overview of how GrapheneOS improves privacy, security and other areas compared to the most secure Android devices running the stock OS. It's not immune to exploitation and cannot be. Products making that claim are scams.

Not being immune to exploitation doesn't mean it can be successfully exploited in a given real world scenario. It's significantly harder to develop and deploy an exploit successfully. It can be exploited, but it doesn't mean it is happening especially at scale or consistently.

Having far from perfect security does not mean real world attacks including sophisticated ones will be successful in practice. Don't fall for security nihilism propaganda. We'll keep working on advancing security for general purpose computing devices. It will keep getting better.

https://bsky.app/profile/iceblock.app/post/3lmzykc7rb42d

Apple stores which devices/users install which apps. They have the device IDs. US government could obtain a list of people who installed the app if a court authorized it. Not clear what they mean by having to store device IDs. Those IDs aren't accessible to Android apps.

ANDROID_ID is a per-app-per-profile random ID. Not clear why they would need it. Android has privacy-preserving hardware-based attestation if they're talking about making it harder to spoof a location. Can't prevent either iOS or Android users making false reports via attestation APIs regardless.

https://bsky.app/profile/iceblock.app/post/3lswryqarlk2l

Making posts with inaccurate technical claims about Android doesn't inspire confidence. It's a closed source app with a closed source service fully under their control. Why is that the approach if their goal is helping people rather than monetizing interest in it?

https://bsky.app/profile/iceblock.app/post/3lpewifycls27

Apple records which apps people install and requires an account to use their app store. Apple Push Notification Service (APNs) has comparable privacy to Firebase Cloud Messaging (FCM). However, iOS apps must use APNs for push while Android apps do not have to use FCM.

Android apps can implement their own push service or allow the user to choose a service via the UnifiedPush framework. Play Store has a policy of requiring FCM for most use cases for battery reasons but there are exceptions. Unlike iOS, Android allows installing apps from other app stores / sources.

ICEBlock app is very clearly misleading people about privacy and their safety. Apple has a list of which accounts/devices have installed the app. They will provide it to the US government if they receive a court order. FCM is also not less private than APNS and FCM doesn't work the way they claim.

iPhones have good overall privacy and security but Apple does collect telemetry, forces people to have accounts and knows which apps each user/device has installed. They do not have magical privacy and security properties. An app like this claiming iOS gives them 100% anonymity is very strange.

iOS has significantly worse support for VPNs than Android and requires using Apple services. Android exists without Google services and people can install apps from elsewhere. The mandatory or effectively mandatory services on Google Mobile Services devices and iOS have comparable privacy.

Tags:

• 2025070100 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025063000 release:

• Exynos 5400 modem Pixels (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): temporarily disable hardened_malloc and hardware memory tagging for shared_modem_platform executable due to an upstream write-after-free bug
• Launcher: fix upstream bug causing a crash for the interface to add lockscreen widgets (currently a tablet only feature until Android 16 QPR1)
• Vanadium: update to version 138.0.7204.63.0
• add debug build functionality for toggling off hardened_malloc usage for vendor processes to make narrowing down issues quicker

Changes in version 138.0.7204.45.2:

• backport upstream port of Local Network Checks site settings to Android to provide per-site control with a prompt when sites try to use it instead of the status quo where Vanadium enforces Local Network Checks for the browser with only a global toggle for disabling it

A full list of changes from the previous release (version 138.0.7204.45.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

This is the initial official release of GrapheneOS based on Android 16 after the June 10th release of Android 16. Device support for Pixels was removed from the Android Open Source Project for Android 16 and had to be reimplemented which is why it took so much longer than usual. Please join our testing chat room if you're interesting in testing this experimental release. We'll be making a series of releases this week to fix several known issues and other issues.

Tags:

• 2025063000 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025062700 release:

• full Android 16 port with all GrapheneOS features available (we previously shipped some parts of Android 16 backported to Android 15 QPR2 to provide the 2025-06-05 and then 2025-07-01 Pixel patch level)
• migrate to using adevtool to handle a much larger portion of device support since the Android Open Source Project no longer includes device support for Pixels
• adevtool: add new arcslib infrastructure for extracting resource overlays from the stock Pixel OS
• adevtool: use fixed build number and build date for state regeneration to reduce diffs
• don't disable external ports at boot on debug builds for internal development for debugging early boot failures

Our initial highly experimental release based on Android 16 has been published for all sixteen of the supported devices (Pixel 6 through Pixel 9a). It should only be installed on a spare device you don't depend on. It won't brick devices but there will be broken functionality.

If you have a spare device and want to help test, join our testing chat room. It can be installed either by updating an existing GrapheneOS installation or doing a CLI install. We'll make the staging site web installer use it a bit later. Don't put it on your daily driver yet.

We've received enough feedback for the initial experimental release. There were recent regressions in the port due to SELinux policy changes which resulted in the testing being less useful than expected due to major issues with third party apps which weren't present previously.

We've implemented a workaround for this issue and are also addressing lockscreen UI issues caused by porting our 2-factor fingerprint authentication feature to Android 16. We'll also try to get fixes for various issues related to device-specific configuration being missing too.

Our aim is to have another much more robust and functional experimental Android 16 release in around 8 hours. SELinux policy issue breaking third party app compatibility was unexpected. It only occurred on production builds, not debug builds, so we missed it in earlier testing.

We've found a proper solution rather than a workaround for the SELinux issue. It was caused by an upstream Android 16 change incompatible with how we provided compatibility with several apps banning GrapheneOS including Revolut. We've also included our new overlay automation.

cross-posted from: https://lemmy.world/post/32194340

Is it a good enough solution for IMEI tracking to use an alternative device to provide a hotspot connection?

This approach appears to protect any new device that hasn't inserted a SIM card from being identified.

But I'm not sure how much information is carried to the second device by using hotspot.

Is this a good solution so far? Should I try to spoof IMEI?

Tags:

• 2025062700 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025062000 release:

• raise security patch level to 2025-07-01 since it's already provided without applying any additional patches
• kernel (6.1): update to latest GKI LTS branch revision
• Pixel 6, Pixel 6 Pro, Pixel 6a: remove AOSP configuration marking android.hardware.location.network as unavailable since it has meant to be declared available since our 2023062300 release adding emulated network location and we also have our own opt-in network location implementation since our 2025022700 release
• Vanadium: update to version 138.0.7204.35.0
• Vanadium: update to version 138.0.7204.45.0
• Vanadium: update to version 138.0.7204.45.1
• Vanadium: update to version 138.0.7204.45.2

Changes in version 138.0.7204.45.2:

• backport upstream port of Local Network Checks site settings to Android to provide per-site control with a prompt when sites try to use it instead of the status quo where Vanadium enforces Local Network Checks for the browser with only a global toggle for disabling it

A full list of changes from the previous release (version 138.0.7204.45.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

All I can fins online is how to disable previews, but I want to enable them. I can only see the sender and message content on my main admin user, but I try to use it as little as possible.

All notifications on the lock screen are disabled, I don't know if that's relevant.

Changes in version 138.0.7204.45.1:

• update to Chromium 138.0.7204.45
• temporarily revert backport of site settings functionality for granting local network access to sites due to a crash (this goes back to only being able to globally disable Local Network Checks via a chrome://flags toggle instead of having a per-site toggle / prompt to permit local network access)

A full list of changes from the previous release (version 138.0.7204.45.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Changes in version 138.0.7204.45.0:

• update to Chromium 138.0.7204.45
• backport upstream port of Local Network Checks site settings to Android to provide per-site control with a prompt when sites try to use it

A full list of changes from the previous release (version 138.0.7204.35.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We've made it clear we're shipping Android 16 soon and that the supported devices will remain supported.

Pixels remain the only devices providing a high level of security combined with proper secure support for using another OS. We hope to have more options by the end of 2026 based on contact with an OEM interested in meeting our requirements but there's no specific timeline.

Our very reasonable hardware requirements are listed at https://grapheneos.org/faq#future-devices. We expect industry standard security patches/features, not anything exotic. Multiple OEMs have indicated they should have no issue meeting these requirements with the next generation Snapdragon SoC.

In 2017, Pixel 2 added an off-the-shelf secure element (SE) with Weaver and insider attack resistance. Weaver provides aggressive throttling to make disk encryption work without a strong passphrase. Insider attack resistance means SE firmware updates require Owner user unlock.

Weaver has a key-value mapping with a slot for each profile on the device where providing the correct authentication token gets back a stored random token needed as an extra input for disk encryption. It's a few hundred lines of code. It's what makes a random 6 digit PIN work.

Most Android devices still lack a secure element providing Weaver, a StrongBox KeyMint and other standard functionality. Weaver was shipped by the Pixel 2 (2017) and StrongBox by the Pixel 3 (2018). It's not a high expectation for devices to provide these features in 2025.

Most Android devices similarly lack proper privacy/security patches for drivers/firmware from day 1 and don't provide long term support. It's not a high expectation. OEMs get 1 month early access and should always ship Android Security Bulletin (ASB) and similar patches on time.

Pixel 8 and later provide 7 years of proper updates. Our minimum requirement is 5 years which has been the case since the Pixel 6. This requirement eliminates most devices despite us keeping it at 5 years. Getting security patches on time for 5 years isn't a high expectation.

ARM provides standard exploit protections used by firmware and software to defend attack exploitation.

Pointer Authentication Codes (PAC) and Branch Target Identication (BTI) are near universal with ARMv9. Memory Tagging Extension (MTE) is more important and often omitted.

All of the standard ARM Cortex cores provide PAC, BTI and MTE. SoC vendors simply need to keep the security features intact and provide basic integration for them. OEMs need to do the same. We greatly expand usage of all 3 of these and were the first to use MTE in production.

MTE support launched with the Pixel 8 when it moved to ARMv9, but the stock OS still doesn't use it by default. In GrapheneOS, we always use it for the Linux kernel and nearly all base OS processes including apps. We provide a toggle to enable it for all user installed apps.

We use it for known compatible user installed apps by default but it's incredibly good at detecting memory corruption and uncovers a lot of bugs. Due to this, we integrated it into our user-facing crash reporting system and per-app exceptions can be made for user installed apps.

With Android 16, Pixel stock OS uses MTE for the small subset of users enabling Advanced Protection. It doesn't use it for the kernel or most of the OS, only a small portion of the OS and a tiny number of apps marked compatible. The implementation is also much weaker than ours.

Our MTE integration is one of the biggest security features we offer. Qualcomm still hasn't added MTE support, but it's supposed to be available with their 2025 SoC launch. Exynos and MediaTek added it for flagships. Samsung integrated support for it as a development feature.

Snapdragon provides solid overall security. It includes a basic secure element for the flagships. Our expectation is Snapdragon will add MTE this year and OEMs willing to do the work of providing proper security features and patches can make devices meeting our standards in 2026.

The most secure non-Pixel devices disallow using another OS or don't allow another OS to use important hardware-based security features. Samsung flagships would be the next best option if they didn't do this. Our expectation is we need to work with an OEM, so we're doing that.

GrapheneOS will continue supporting the current devices we support until their end-of-life dates. We'll also add support for new Pixels as long as they meet our requirements. We've tried to make that clear, but recent posts about changes to AOSP have been widely misrepresented.

Prior to Android 16, Pixels had first class support in the Android Open Source Project as the official reference devices. This was never one of our requirements and no other device provides it. Many people are promoting hardware and software with atrocious security based on this.

A device without proper privacy/security patches or the hardware-based security features we expect didn't become a better option due to Pixels losing something no other device has ever provided. There isn't a non-Pixel device providing Android 15 QPR2 device trees let alone 16.

Tags:

• 2025062000 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025061900 release:

• fix an issue with our added infrastructure for overriding the minimum SDK version for APK-based components backported from Android 16 (Samsung Shannon IMS/RCS was not active resulting in VoLTE, VoNR, VoWi-Fi, SMS via LTE/NR/Wi-Fi and RCS not working so the 2025061900 release was quickly cancelled before being rolled out to a large number of Alpha channel users)

We need help testing our experimental Android 16 support. If you have a spare 6th, 7th, 8th or 9th generation Pixel, you can help us test early builds for Android 16 soon. You can join our testing chat room via Matrix or Discord if you want to help. https://grapheneos.org/contact#community-chat.