GrapheneOS [Unofficial]

2824 readers
44 users here now

Welcome to the GrapheneOS (Unofficial) community

This feed is currently only used for announcements and news.

Official support available on our forum and matrix chat rooms

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility.

Links

More Site links

Social Media

This is a community based around the GrapheneOS projects including the hardened Android Open Source Project fork, Auditor, AttestationServer, the hardened malloc implementation and other projects.

founded 4 years ago
MODERATORS
1
 
 

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.

2
 
 

We need an Android OEM or someone working at one to provide us with early access to the Android 16 sources in order to have a smooth port this year. We need this before June. We requested it to help with this very difficult situation (see the linked thread) and still need it.

https://grapheneos.social/@GrapheneOS/114359660453627718

GrapheneOS Foundation can sign an NDA for this. We can act as a contractor for an Android OEM or one of their contractors. We need this early access so that we can start early due to the developer who usually does most of it being unavailable. If you can get us this, please help.

Since we still haven't received early access to Android 16 sources, we'll need to begin deciding which subset of the GrapheneOS features must be ported and which ones could be initially dropped and added back in the following weeks in order to keep doing full security patches.

For example, our 2-factor fingerprint unlock feature is going to be particularly hard to port due to massive changes to the lockscreen code in Android 16. We can drop it for the initial release and add it back later with user configuration being preserved so it works as before.

Without early access, our porting process is likely going to involve making an initial release with dozens of GrapheneOS features missing to get initial Alpha testing going, then adding back features alongside fixing many upstream regressions and a small number of porting issues.

In the past few years, we've typically been able to make an experimental release with all of our features ported within a day or two of the new yearly release being pushed to the Android Open Source Project. It tends to take a week to reach Stable, which was already too long.

Over time, we've added many more features including ones which are harder to port including sandboxed Google Play compatibility layer, Storage Scopes, Contact Scopes, 2-factor unlock and much more. Some MUST be ported for an initial release, others could be temporarily omitted.

We hired an extremely talented developer in 2021 who later became our lead developer. He was doing the majority of this porting work from 2022 on. He's currently stuck in a military training camp due to being forcibly conscripted so we need standard early OEM access this year.

If you want to see GrapheneOS continue, please help us get early access to Android 16 sources before the end of the month. We ideally need all of it so we can do early builds for the emulator, but even just having a few of the most important repositories early would help a lot.

In exchange for an OEM providing us with early access, we can help with fixing multiple severe vulnerabilities and weaknesses fixed by GrapheneOS which are not being reported to Google due to them blocking us from having partner access. We can help in far more ways than that too.

Every Android OEM licensing GMS has access to what we need and could provide it to us under a contract where we're working on GrapheneOS with it for their benefit. Every Android OEM has substantially benefited from our upstream work, and could benefit more if they worked with us.

3
 
 

GRAPHENEOS IS HIRING

Are you an experienced AOSP developer?

Interested in working full time, fully remotely on GrapheneOS?

Can you hit the ground running?

https://grapheneos.org/hiring

Global opportunity paid via Wise (local bank transfers), BTC, ETH or XMR.

4
3
submitted 3 years ago* (last edited 3 years ago) by akc3n@lemmy.ml to c/grapheneos@lemmy.ml
 
 

Hello and welcome to !grapheneos@lemmy.ml !

Our Lemmy GrapheneOS community is currently unofficial, reserved, and used for announcements/news.

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility.

https://grapheneos.org/

https://attestation.app/

https://github.com/GrapheneOS

Official chat rooms: #grapheneos:grapheneos.org and #offtopic:grapheneos.org

This is a community based around the GrapheneOS projects including the hardened Android Open Source Project fork, Auditor, AttestationServer, the hardened malloc implementation and other projects.


All installs should follow the Official Install Guide. No other guides are recommended or supported.

If your question is related to device support, please see the Which devices will be supported in the future? for criteria and the Which devices are recommended? for recommend devices from the FAQ section of the official site.

If your question is related to app support, please check the Usage Guide. Sections like Bugs uncovered by security features should help if you have a native app with a security issue uncovered by hardening. If you want to know what browser to use please reference Web browsing. In general, Vanadium is almost always the recommendation for security and privacy.

If your question is related to a feature request, please check the issue trackers. OS issue tracker, Vanadium for other GrapheneOS project check the Reporting issue.


GrapheneOS has a very active community primarily based around the official chat rooms on Matrix and where most of the core community, including contributors, to the project have discussions. Most of those people are not active here on Lemmy's !grapheneos@lemmy.ml community.

The official GrapheneOS space groups together all of the official rooms along with members of the community who join the space. You can join the space at #community:grapheneos.org

Links to join our new official chat rooms via the Element web client:

Matrix Room Description
#grapheneos:grapheneos.org Best place to request support, ask questions or get involved in the project
#offtopic:grapheneos.org Discuss topics not strictly related to GrapheneOS
#dev:grapheneos.org Discuss GrapheneOS app and OS development
#testing:grapheneos.org Provide feedback on Beta channel releases
#releases:grapheneos.org Release announcements
#infra:grapheneos.org Infrastructure monitoring and discussion

You can use the client and home server of your choice. For new users, the Element web app or mobile app with matrix.org as your home server is a sensible choice.

Please contact the moderators of this community if you have any questions or concerns.

5
 
 

https://foxnews.com/tech/new-android-attack-tricks-you-giving-dangerous-permissions

GrapheneOS, a security-focused operating system based on Android, confirmed that its current version is also affected. However, it plans to release a fix in its next update.

No, we said that on July 7 and then shipped https://grapheneos.org/releases#2025070700 fixing it.

They likely found https://x.com/GrapheneOS/status/1942235186923499549 but didn't realize our next release was shipped later that day. The TapTrap site from the researchers at https://taptrap.click/ documents that we fixed it. Our fix works well and many users tried the proof of concept app to confirm it.

Android 16 was released June 10 and we'd already done our final Android 15 QPR2 releases with backports of Android 16 drivers/firmware when we were informed about TapTrap near the end of June. Once our port to 16 was near Stable, one of our devs spent a few hours fixing TapTrap.

The researchers reported it to Android on October 31, 2024 and Android still hasn't fixed it. We fixed the vulnerability by only allowing third party apps to use custom activity animations for their own activities. It's likely Android doesn't want to remove part of the feature.

6
 
 

Swissquote Bank is in the process of adding official support for GrapheneOS to their main app. They've published a Beta version of the app with GrapheneOS support for us to share with our users. Can use https://appdistribution.firebase.google.com/testerapps/1:922102381011:android:b7cac4eab8e5776d/releases/4rp8ha7plvg00 to obtain it via the sandboxed Play Store.

Swissquote previously added GrapheneOS support to their Yuh financial app. They're following our guide on using hardware attestation as an alternative to Play Integrity able to support more than Google Mobile Services hardware and operating systems: https://grapheneos.org/articles/attestation-compatibility-guide.

The link we provided might not work in Vanadium since Firebase appears to use the Client Hints headers to detect the OS version. We set the OS version in the Client Hints headers to the frozen User Agent value which is Android 10. May need to install and use Chrome to access it.

We've previously seen an issue where a site used the Client Hints provided OS version to ban using incredibly out-of-date Android versions. We didn't remove the Client Hints headers because that trips bot detection. Reusing the frozen User Agent values was working quite well.

7
 
 

A Dutch bank (Triodos Bankieren NL) has added explicit support for GrapheneOS and will be testing it going forward:

https://github.com/PrivSec-dev/banking-apps-compat-report/issues/133#issuecomment-3087638715

They join a growing number of banking apps actively permitting users to use a much more secure device instead of trying to ban it instead.

8
 
 

Apple and Google both provide support for offline speech-to-text using local models. Users can configure it to be fully offline.

The Murena Voice to Text service in /e/OS sends the user's audio to OpenAI which is hidden away in their terms of service:

https://community.e.foundation/t/voice-to-text-feature-using-open-ai/70509

/e/OS is heavily marketed as private but in reality it has enormous privacy issues like this with their default apps and services. It's also heavily marketed as avoiding Google services but yet has privileged integration for Google services and connects to multiple by default.

/e/OS doesn't keep up with basic privacy or security patches for the OS or browser engine used not only for the default browser but also the WebView used by many apps including email clients and far more for rendering web-based content. For more info see https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private.

/e/OS is not a threat to mass surveillance but rather significantly helps with it by making exploiting devices to extract data or take remote control over them far easier. They do not keep up with basic High and Critical severity patches. All devices sold by Murena are insecure.

Even on Pixels, /e/OS is extremely far behind on providing the current High and Critical severity privacy and security patches due to being so far behind on OS updates. They mislead users by setting a fake security patch level and changing the UI to mask what's happening.

Murena is a for-profit company and /e/OS is very clearly built and managed for the benefit of Murena. Despite this, /e/OS receives a huge amount of EU government funding. If you're an EU taxpayer, your money is being used to build this extraordinarily insecure and non-private OS.

9
 
 

Tags:

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

  • Dialer: always show scrollbar for button grid when there are more than 6 buttons to make it clear it can be scrolled
  • Dialer: move RTT button to the end since it's rarely used
  • Network Location: improve position estimation implementation to provide better performance, accuracy and stability
  • Network Location: add support for detecting location based on cell towers when Wi-Fi-based location can't obtain any position estimate
  • add back "Prevent ringing" gesture via Power + Volume Up which was lost in the port to Android 16
  • Settings: fix discharge time estimates not being shown when charging optimization (charging limit) enabled
  • Settings: avoid explanation in per-app Play Integrity API settings being cut off
  • fully prevent empty end session button being shown
  • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.145
  • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.98
  • include more color overlays from the stock Pixel OS
  • add back desktop mode toggle to developer options which was missing due to Android 16 requiring enabling config_isDesktopModeDevOptionSupported in addition to the config_isDesktopModeSupported feature we were already enabling
  • adevtool: add infrastructure for defining synthetic overlays and migrate to using it (automates more of device support and results in the battery charging limit text being updated)
  • adevtool: heavily optimize state collection by only calculating what gets built instead of building it
  • enable optimization of pausing wallpaper rendering for Pixel Camera
  • Terminal (virtual machine management app): temporarily disable GUI support until Android 16 regression causing surfaceflinger crash is resolved
  • Seedvault: update to 15-5.6 (will be replaced with a better backup implementation in the future)
  • Vanadium: update to version 138.0.7204.157.0
  • GmsCompatConfig: update to version 159
10
 
 

Changes in version 4:

  • temporarily allow Dynamic Code Loading via memory for the sandboxed Play Store by default until it's resolved upstream or by us coercing it to stop doing it (users can still disallow Dynamic Code Loading via memory for it as it doesn't appear to cause many issues but we don't want to have errors occurring for regular users)
  • update Gradle to 8.14.3
  • update Android Gradle plugin to 8.11.1
  • update Protobuf Gradle plugin to 0.9.5
  • update Protobuf library to 4.31.1
  • update Kotlin to 2.1.21
  • update SDK to 36 (Android 16)
  • update target API level to 36 (Android 16)
  • switch modern Gradle Java toolchain configuration
  • improve code style

A full list of changes from the previous release (version 3) 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.

11
 
 

We published this response to a recent article promoting insecure devices with /e/OS with inaccurate claims, including inaccurate comparisons to GrapheneOS:

https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

The founder of /e/OS has responded with misinformation promoting /e/OS and attacking GrapheneOS.

We made a post with accurate info on our forum in response to inaccurate information, that's all. There's a lot more we could have covered. See https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6/ for several examples such as /e/OS having unique user tracking in their update client not communicated to users.

The founder of /e/OS responded to the post we made on our forum here:

https://mastodon.social/@gael/114874688715085353

Gaël Duval has repeatedly personally targeted the founder of GrapheneOS in response to us posting accurate information responding to misinformation from /e/OS and their supporters.

Contrary to what's claimed in this thread, /e/OS does not improve privacy. /e/OS massively reduces privacy compared to the Android Open Source Project in multiple ways. /e/OS is consistently very far behind on shipping important privacy improvements in new major Android releases.

/e/OS regularly lags many weeks, months and even years behind on shipping important privacy and security patches. They roll back various parts of the privacy and security model, add a bunch of privileged Google service integration and their own privacy invasive services too.

The link posted at https://mastodon.social/@gael/114875028964272029 shows /e/OS shipping the previous round of Chromium privacy/security patches a couple weeks late. It regularly takes them months instead of weeks. They take far longer to ship many of the important driver, firmware and AOSP patches.

The link also shows they're using the wrong Chromium tags for Android and frequently results in missing Android-specific privacy/security patches. Chromium 138.0.7204.97 was a June 30th release for Windows, not Android. The Android tag for June 30th was 138.0.7204.63.

https://chromereleases.googleblog.com/2025/07/stable-channel-update-for-desktop_15.htmlhttps://chromereleases.googleblog.com/2025/06/chrome-for-android-update_30.html

Patches in Chromium Stable channel updates for Android are often only in the Android tags, not the Windows ones.

The current Android release is 138.0.7204.157, with security patches beyond 138.0.7204.63:

https://chromiumdash.appspot.com/releases?platform=Android

These were minor releases of Chromium. It's trivial to incorporate the changes and ship them on release day within hours. Even major releases of Chromium every ~4 weeks are easy to ship on release day because major releases are open source for weeks in advance, unlike Android.

As can be seen by looking back through https://github.com/GrapheneOS/Vanadium/releases and comparing it to the Android release dashboard linked above, we ship the Chromium Stable and Early Stable releases on release day. This is not impressive. Shipping privacy/security patches is the bare minimum.

Our forum post and this thread were both posted in response to inaccurate info about GrapheneOS posted to promote /e/OS. Once again personally targeting our founder with fabricated stories and harassment from their community is what /e/OS has done before and continues doing.

/e/OS targeted the founder of DivestOS in a similar way and /e/OS supporters directed a massive amount of harassment towards him. It played a significant role in DivestOS being discontinued. /e/OS will not achieve the same thing targeting our founder and should stop doing it.

/e/OS is extraordinarily insecure and non-private due to lagging so far behind on patches and crippling Android Open Source Project privacy/security protections. Selling many devices many months or even years of missing Critical severity patches and hiding it in the UI is wrong.

Murena's services are not nearly as private as claimed and not at all on the same level as serious options such as Proton's software suite. Many of their services recently went down from early October 2024 through March 2025:

https://community.e.foundation/t/update-on-murena-io-service-outage/61781

It's somehow a paid service.

12
 
 

Changes in version 159:

  • add stubs for AdvancedProtectionManager which was preventing us moving the post-Android-16 sandboxed Google Play services to our App Store's Stable channel (GrapheneOS enables far better security features by default with per-feature and per-app controls where that makes sense instead of the all or nothing iOS Lockdown Mode approach copied by Android 16 which we don't plan to imitate)
  • update target API level to 36 (Android 16)
  • update Android Gradle plugin to 8.11.1
  • update Gradle to 8.14.2

A full list of changes from the previous release (version 158) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

13
 
 

We've published a response with corrections to iFixit article presenting a highly insecure and non-private option as being the best choice for people who care about privacy:

https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

Not bundling Google Mobile Services doesn't mean a device/OS has good privacy.

14
 
 

Changes in version 138.0.7204.157.0:

  • update to Chromium 138.0.7204.157
  • change default value for "Protected content" (DRM) site setting to ASK instead of BLOCK (we changed this from ALLOW to BLOCK because ASK wasn't an option at the time we changed it)
  • stop marking 64-bit-only builds as multiArch to enable installation on devices supporting 32-bit apps such as 6th generation Pixels
  • use Vanadium Config version as the subresource filter rules version instead of having a separate version for it

A full list of changes from the previous release (version 138.0.7204.63.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.

15
 
 

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)
16
 
 

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.

17
 
 

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.

18
 
 

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
19
 
 

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
20
 
 

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.

21
 
 

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
22
 
 

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.

23
 
 

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
24
 
 

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.

25
 
 

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.

view more: next ›