We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run #GrapheneOS (

Frequently Asked Questions | GrapheneOS

and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost. In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early. We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release. Due to AOSP no longer having device support, we need to build it ourselves. We can start from the Android 15 QPR2 device support, remove the outdated code and update the configurations. We have tooling to automate generating device support setups which will need major expansions. Since our port to Android 16 is going to be delayed by a week or more, we're in the process of backporting the Android 16 firmware/drivers released on June 10 to the previous releases. This is not something we can do in general so we still need to port to Android 16 this month. Despite our lead developer who has done 90% of the ports for several years being conscripted into an army, we were still able to complete the initial port to Android 16 in under 2 days, but without device support. Our extensive preparation in April and especially May paid off. It's important to get an experimental release out quickly to begin extensive public testing. There are usually many issues found in testing. For a yearly release, we usually get out an experimental release in a day, an Alpha channel release in 2 days and need 4-6 more releases. Google has released a statement claiming AOSP is not being discontinued. This should be taken with a grain of salt, especially considering that they made similar public statements recently followed by discontinuing significant parts of AOSP on June 10.

X (formerly Twitter)

Seang Chau (@seangchau) on X

We're seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an op...

Google is in the process of likely having the company broken up due to losing an antitrust lawsuit from the US government and being in the process of losing several more. There's a high chance of Google losing control of Android in the next couple years.

U.S. Asks Judge to Break Up Google

The Justice Department said the best way to address the company’s monopoly in internet search was to force it to sell Chrome, among other measures.

The leaked information we received in April 2025 indicates that the reasoning they're making substantial cuts to Android is primarily cutting costs, perhaps in anticipation of it being split from Google. The courts should investigate Google's recent changes and cuts to Android.

In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable. Android 16 launched today and porting is going to be significantly more difficult than we were expecting. We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports. Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making #GrapheneOS devices sooner than we expected. We don't understand why these changes were made and it's a major turn in the wrong direction. Google is in the process of losing multiple antitrust cases in the US. Android and Chrome being split into separate companies has been requested by the DOJ. They may be preparing for it. We're hard at work on getting the port to Android 16 done but there's a large amount of additional work we weren't expecting. It can be expected to take longer than our usual ports due to the conscription issue combined with this. It's not good, but we have to deal with it. Having our own devices meeting our hardware requirements (

Frequently Asked Questions | GrapheneOS

would reduce the time pressure to migrate to new releases and could be used to obtain early access ourselves. Based on talks with OEMs, paying for what we need will cost millions of dollars.

GrapheneOS version 2025061000 released.

Releases | GrapheneOS

See the linked release notes for a summary of the improvements over the previous release. #GrapheneOS

A while ago, a forensics company suggested in the open they are able to overcome iOS automatic reboot timer indefinitely with a unique preservation tool. Automatic reboots force data to return to an encrypted at rest state until they are unlocked again, which mandates the threat actor having to brute force the device for decrypting sensitive data to access rather than bypassing the lock mechanism for an AFU device. Magnet Forensics (GrayKey) are a business leader in iOS forensic extractions and originally began only exploiting on iOS, although supporting other devices now, they are limited in support roster compared to Cellebrite who support a wide range of legacy devices with huge funding and business location that conscripts young technologists into hackers and engineers. GrayKey's founders contain former Apple security engineers. This preserve tool is bundled with their Advanced and Premier plans. Availability of such tools further demonstrates a need for a shorter default time than 72 hours, or a user-configurable option, just like what you can get in #GrapheneOS. Apple needs to put further work in protecting against physical attacks, even if they aren't able to know the tactics used to perform it, additional hardening could close out unknown vulnerabilities, disrupt actors and their progress by defense in depth. https://www.magnetforensics.com/blog/the-importance-of-preservation-for-ios-devices/ https://www.magnetforensics.com/resources/preserving-your-ios-extractions-with-magnet-graykey-and-graykey-preserve/

Discussed this in a SimpleX chat yesterday, but worth thinking leaving thoughts here: A software project that has received a fancy, formal security / privacy audit document shouldn't be considered a gold standard of trust alone. It is a practice that should build a larger image of trust. There's a lot that goes into an application being trustworthy or not. A PDF file from a team / field expert saying a program is good can only go so far. Just because a project may not have a document like this, doesn't mean they are not held under heavy scrutiny or that they do not have trust. It isn't always possible, not may it be fitting to review certain software in such a manner. In fact audited projects may be less scrutinised. A project can be audited but miss out on having potential important security / privacy features. Would you rather use a wallet that was alike to Bitcoin Core that had such a PDF you could read, or would you use a wallet like Samourai (forks) or Wasabi that didn't, knowing it had privacy features? Audits need to be continuous to be most effective. Software that is rapidly updating, adding new features, or ends up changing the architecture significantly are not a good fit for one-time audits. The document would just be an advertising gimmick and nothing more, since it either covers code doesnt exist now, or doesn't cover code that exists now. Security reviews shouldn't be a one time. A far better merit is an application being targeted by security researchers frequently, and vulnerability disclosures are a good sign of scrutinised, improving software. For something like GrapheneOS or a Linux distribution, these things don't work due to the sheer size of the projects and different conditions of users. Security researchers should routinely attempt to uncover vulnerabilities and developers should be campaigned to shift left. These formal reviews do work better for single user facing software projects, or for online services to prove technical claims about their services. But it doesn't mean that it would always be the same since the latest being published though.

#GrapheneOS: WebRTC is a peer-to-peer communications protocol for web sites and therefore causes numerous privacy issues through making direct connections between participants. By default our Vanadium browser disables the peer-to-peer aspect by only using server-based (proxied) connections. Vanadium provides a user-facing setting at Privacy and security > WebRTC IP handling policy. From least to most strict: Default Default public and private interfaces Default public interface only Disable non-proxied UDP For Vanadium, "Disabled non-proxied UDP" is the default. The tracking technique described at

Ars Technica

Meta and Yandex are de-anonymizing Android users’ web browsing identifiers

Abuse allows Meta and Yandex to attach persistent identifiers to detailed browsing histories.

is prevented by Vanadium's default "Disabled non-proxied UDP" value. It's also prevented by "Default public interface only", which does permit peer-to-peer connections but won't try to use the loopback interface for it. We have a list of most of the features provided by Vanadium at

Features overview | GrapheneOS

There are dozens of additional privacy and security features planned along with data import/export and improved support for system backups. It takes time to implement these things properly. Vanadium doesn't have billions or even millions of users which limits our ability to prevent fingerprinting. We plan to address this by launching it for use outside GrapheneOS including publishing it through the Play Store. We want to implement more of the planned features first.

#GrapheneOS version 2025060200 released. Android 16 is not released yet. This is an early June security update release based on the June 2025 security patch backports since the yearly Android Open Source Project and stock Pixel OS release scheduled for this month hasn't been published yet. Changes since the 2025060100 release: - full 2025-06-01 security patch level - System Updater: temporarily revert notification protection due to upstream Android UI issues for this feature with privileged apps (we still plan to do this but it will need to wait until we resolve the OS issue) - remove Chunghwa Telecom and Netlock Certificate Authorities (CAs) based on the decision by the Chrome Root Store (this does not impact Vanadium since it uses a more sophisticated browser root store rather than the OS root store and will distrust certificates from these CAs not added to Certificate Transparency logs before 2025-08-01 to avoid website compatibility issues)

Releases | GrapheneOS

Users of #Obtainium may be interested in this web site:

Open Source Apps APK for Android - OpenAPK

Download free open-source apps in APK format for Android, safe, ads-free and privacy friendly. Sourced from Github, Gitlab and beyond.

It appears to have "Add to Obtainium" buttons to add the source of the app for you. Good for searching known apps. Can be saved as a PWA. Obtainium maintainers also keep a list of app configs for more complex apps at

Complex Obtainium Apps

Crowdsourced "Hard to Add" App Configurations for Obtainium.

A better last resort option should app stores not be sufficient.