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:

source.android.com/docs/securi…

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.

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 releases

Official releases of GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

^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:

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.