KindnessInfinity

Tags:

• 2025070800 (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 2025070700 release:

• update to BP2A.250705.008 vendor files (July 2025 Pixel monthly release)
• disable temporary unconditional system crash notifications since we've gotten the initial feedback we needed since releasing our port to Android 16 (users can enable this themselves via Settings > Security and privacy > More security and privacy > Notify about system process crashes)
• NFC: always show standard confirmation dialog before opening a URL instead of it only being enabled for a small subset of users
• temporarily remove NFC auto-turn-off feature since it can cause NFC HAL or system_server crashes in rare edge cases and we need to entirely reimplement it inside of the NFC APEX module to avoid the problems (there were rare issues reported prior to Android 16 but 1 user reported an NFC HAL crash loop on Android 16 making it clear we need to drop this until we redo it in a better way)

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

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.

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

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.

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

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.

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.