We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support. motorolanews.com/motorola-th…

Vanadium version 150.0.7871.63.1 released: github.com/GrapheneOS/Vanadi… See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog. Forum discussion thread: discuss.grapheneos.org/d/376… #GrapheneOS #privacy #security #browser

Vanadium version 150.0.7871.63.0 released: github.com/GrapheneOS/Vanadi… See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog. Forum discussion thread: discuss.grapheneos.org/d/374… #GrapheneOS #privacy #security #browser

GrapheneOS version 2026062800 released: grapheneos.org/releases#2026… See the linked release notes for a summary of the improvements over the previous release. Forum discussion thread: discuss.grapheneos.org/d/372… #GrapheneOS #privacy #security

GrapheneOS opposes authoritarianism. It's a core part of why we're building privacy technology as part of a non-profit open source project. We're opposed to it regardless of whether it comes from left, center or right. The flood of people lying about what we believe and have said won't change this. Our beliefs are not defined by what people who use GrapheneOS or donate to it believe. We decide what's acceptable within our community and we do a lot of moderation. We don't police what's done fully outside it. We clearly won't only have users, donors and supporters with beliefs aligned with ours. We don't usually allow much political discussion in our community unless it's directly related to GrapheneOS. Today has been a very good demonstration of why that's the case. Many people are unable to tolerate even a minor disagreement on semantics without being absolutely enraged over it.

Our update servers are sponsored by Mullvad, ReliableSite, Cherry Servers, Zare and Xenyth. You can see those here: grapheneos.org/articles/grap… The screenshot shows bandwidth usage for Frankfurt with staggered rollout to 10th gen, then 9th, then 8th and finally 7th 6th together.

2026062300 is now available in Stable for all of the supported devices. Bandwidth usage in Frankfurt is now at 20Gbps and the other locations have also increased a similar proportion. We'll need more update servers within a year or two but we have enough to avoid staggering the largest updates.

GrapheneOS update downloads are usually around 20MB to 80MB when updating from a recent release. The download for updating from our final Android 16 QPR2 release to Android 17 ranges from 620MB to 760MB depending on device model. We're in the process of rolling it out to the Stable channel now. Current bandwidth usage with 2026062300 in Stable for only 9th and 10th gen Pixels: Frankfurt: 12Gbps out of 50Gbps Amsterdam: 6Gbps out of 20Gbps Toronto: 6Gbps out of 10Gbps Los Angeles: 6Gbps out of 10Gbps London: 4Gbps out of 10Gbps Dallas: 2.5Gbps out of 50Gbps Miami: 2Gbps out of 10Gbps

Just filed an EU DMA complaint against Alphabet for gatekeeping against secure Android derivatives like @GrapheneOS via Play Integrity. TL;DR: not certified ≠ not secure. Google lacks a FRAND certification process for non-OEMs that comply with objective security requirements.

Android 16 added certificate transparency enforcement for apps. It checks Signed Certificate Timestamps proving certificates were logged in at least 2 logs for certificates with <= 180 day expiry or 3 logs for > 180 day. It was opt-in for targeting Android 16 but is opt-out for targeting Android 17. Some users have reported seeing a connection to gstatic.com when the device starts charging which is due to certificate transparency logs being fetched. We've been planning to review certificate transparency log updates for a while but hadn't gotten to it yet. We'll have our own approach soon.

Download Manager is an Android component handling long-term HTTP(S) downloads for apps in the background. Apps with the INTERNET permission (GrapheneOS Network toggle) can offload their downloads to it. Download Manager doesn't trigger any connections itself. developer.android.com/refere… Unlike regular apps with a unique uid/gid, DownloadManager shares a UID with several other OS media components. Components with a shared UID have shared permission toggles, data usage statistics, etc. Apps attributing connections to apps based on UID often attribute it to another app in the group. Chromium uses Android's DownloadManager for a bunch of functionality including user downloads, saving and updating offline pages. Search the Chromium sources for DownloadManager to get an overview. DownloadManagerService is a Chromium service implemented on top of Android's DownloadManager. By default, apps are limited in how much they can run in the background. Users can change the default Optimized to Restricted to delay tasks apps want to run in the background to the next time the app is started including being started by another app. Apps can run for a little bit after being run. Download Manager exists to provide a way for apps to trigger a download for a large file while running and then get woken up when it completes. It avoids the app needing to continuously run to perform the download, which would require a foreground service to keep running when user switches away. MTP Host and several other media components share a UID with Download Manager. Connection monitoring software attributing connections to those is incorrect and doesn't correctly handle shared UID apps. RethinkDNS properly attributes it to the UID group instead of picking an arbitrary app to blame. DownloadManager is used by the OS, Vanadium and many user installed apps. The connections don't come from DownloadManager or the other media components such as MTP Host. Downloads can be set to require charging or idle, causing those to trigger it: developer.android.com/refere…

AppCompatConfig version 7 released: github.com/GrapheneOS/platfo… See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog. Forum discussion thread: discuss.grapheneos.org/d/367… #GrapheneOS #privacy #security

Vanadium version 149.0.7827.197.0 released: github.com/GrapheneOS/Vanadi… See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog. Forum discussion thread: discuss.grapheneos.org/d/367… #GrapheneOS #privacy #security #browser

GrapheneOS version 2026062300 released: grapheneos.org/releases#2026… See the linked release notes for a summary of the improvements over the previous release. Forum discussion thread: discuss.grapheneos.org/d/367… #GrapheneOS #privacy #security

Hyundai and Kia added official GrapheneOS support to their apps months before Volkswagen banned GrapheneOS: discuss.grapheneos.org/d/316… Pressure from Volkswagen customers on them can achieve the same thing. There's no legitimate reason to ban GrapheneOS so they'll undo it with pressure. Leave a 1 star review for Volkswagen's apps on the Play Store asking them to stop banning GrapheneOS. Explain it's a far more secure operating system and fully possible for them to verify the hardware, OS and their app on it if they insist on doing it. It's far more secure than anything they allow. Google has misled companies about what the Play Integrity API provides. It doesn't genuinely enforce having a secure device or legitimate app, it only pretends to. It leaves huge security holes open. It enforces Google's business interests and bans having a reasonably secure device with GrapheneOS. Most companies are unlikely to stop using the Play Integrity API but most are willing to start permitting GrapheneOS via hardware attestation with enough pressure. In addition to every user of their app on GrapheneOS leaving a 1 star review on the Play Store, multiple other steps can be taken too. Every GrapheneOS user with one of their cars using the app should file a customer support request. Keep answering them and countering the template responses. Escalate the request higher up. Tell them you want money back for the vehicle due to reduced functionality after the fact and insist on it. They can trivially stop enforcing the anti-security and anti-competitive Play Integrity API or easily add hardware-based verification of GrapheneOS. Link to grapheneos.org/articles/atte… in the customer support request, but don't add any links to Play Store reviews to avoid filtering. A bunch of apps have added explicit support for GrapheneOS due to pressure from our users. Our userbase is rapidly growing and we'll gain the ability to apply massive pressure to companies doing this. We plan to ship a feature for our Info app for people to opt-in to getting asked for their help. GrapheneOS is production quality OS from a non-profit paying around 15 people to work on it. It's far more secure than anything supported by the Play Integrity API. We have an official partnership with Motorola and we'll have more. Just counter template responses and insist on compensation or a fix.

Resolving most of Google's anti-competitive behavior with Android would be straightforward for regulators: ban the Google Mobile Services licensing model and require Google to make their apps and services work on any AOSP-based OS without privacy invasive access and massive control over the OS. Android was successful due to being open source and an open platform. Google chose that approach to catch up and get near universal adoption by OEMs and carriers. They've gradually phased in illegal anti-competitive practices making it into a bait and switch. They can be forced to roll it all back.

Google heavily criticized Apple for their closed iMessage ecosystem and initial refusal to implement RCS. Apple then took ages to provide end-to-end encryption support for RCS and it was kept as an iMessage exclusive feature until recently. Google is doing the same kind of thing as Apple with RCS. RCS isn't truly an open standard or open ecosystem. It isn't open to anyone making a client working with any carriers which can interoperate with the Apple and Google implementations. Google does device integrity checks which supposedly exist to combat spam without testing it works on GrapheneOS.

Google shipped an out-of-band update to droidguard breaking using RCS with sandboxed Google Play. We've already fixed it and it will be included in the OS release we're making later today (2026062300). That will likely be our first Android 17 to reach our Stable channel. github.com/GrapheneOS/platfo… Our 2026062200 release is currently available in our Alpha channel and will likely be available in our Beta channel soon. It may be solid enough to reach our Stable channel but it won't have the opportunity to get there since our 2026062300 release will replace it once it's built, signed and tested.