yore

de0u I found the issue just now! It turns out you must have less than 4 users on the device to be allowed using Private Space. From this documentation, I just assumed, I quote "You can’t use private space when: Your device has more than 4 users or profiles." I guess the guest is counted as one even if not used. Or it's "more than or equal 4". I delete 1 user, rebooted and "Private Space" was there!

othemad People keep asking about this because our worst nightmare is waking up one day to the news that GrapheneOs has been discontinued.

That would be bad!

That said, even if GrapheneOS suddenly halted today, there would still be some months during which it would arguably remain the most-secure Android variant, so there would be some time to decide what to do. And even if some Google change slowed down GrapheneOS development by some weeks per cycle continuing to run it would probably make sense.

Meanwhile, hopefully people who treasure GrapheneOS are making financial donations, and also hopefully contributing in other ways, such as being polite and constructive on this forum, researching facts instead of amplifying unsubstantiated rumors, citing sources, searching before posting, ... If developers can spend less time arguing against misconceptions they can spend more time developing.

grayway2
People keep asking about this because our worst nightmare is waking up one day to the news that GrapheneOs has been discontinued.

GmsCompatConfig version 156 released:

https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-156

See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

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

Android has always taken the approach of it being developed in private and then having the full sources and commit history published for each stable release. This approach used to be the norm for open source software many years ago, but now most projects do a lot of their development in the open.

Commit history being available also didn't used to be the norm many years ago but rather only tarballs for releases. It's very important for them to provide it, but it would be open source without it. They're still going to be providing it.

Certain sub-projects were developed in the open as part of the public Android Open Source Project repositories in the main branch but the bulk of the work was done in private. They maintained both a public main branch and an internal development branch and had to merge back and forth between them.

Recently, Google announced they'll be shifting most of the small subset of the OS developed in the AOSP main branch to being developed internally instead. The full commit history will still be available when stable releases are published as it for the majority of AOSP developed that way already.

AOSP main was not where most of the OS was developed and would get most of those changes merged into it shortly after each stable release.

AOSP main also doesn't correspond to Developer Preview and Beta releases, which are separate branches and what we need for porting before a Stable release.

The small subset of the OS developed via AOSP main moving away from it won't have a major impact on GrapheneOS. It did not provide us with early access to the code we need for porting GrapheneOS to an upcoming release before the day it gets released. That already required having partner access.

Android is remaining open source and simply being slightly less open about the development of certain components. We won't be able to see the commits as they're made for that small subset of components anymore but rather need to wait until they publish the full commit history for stable releases.

In contrast with Android, Chromium is developed almost entirely in the open and we can port and test all of our changes to the upcoming releases before there's a Stable release. This is very helpful and makes maintenance much easier for us. Doing this for Android already required partner access.

We've already been in the process of figuring out how to get partner access in a way that will be reliable and long term. There was only one year where we had early access to a new major release. We haven't had it for several years and we still manage to get the yearly releases out in a couple days.

secrec It does not share signal strengths or location. It's a different approach than Google's location service. It fetches location data for the 15 strongest signal strength APs based on their BSSID and stores that data in a local cache. We also ask for up to 100 nearby APs covering a large area to help fill the cache. The position estimation is local. We're going to be making our own database initially based on Apple's data and using that to create our own service with full offline support through downloading data for an arbitrary area. See https://discuss.grapheneos.org/d/21244-grapheneos-network-based-location-service-improvements for more information about how the current implementation works.

Vanadium version 135.0.7049.38.0 released:

https://github.com/GrapheneOS/Vanadium/releases/tag/135.0.7049.38.0

See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

GrapheneOS version 2025032500 released:

https://grapheneos.org/releases#2025032500

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

I saw this shared over a year ago, so maybe they have newer ones, but here's what was said in a public room on Matrix:

the official build hardware is 3 workstations: Ryzen 7950X with 128GB DDR5, i9-13900K with 128GB DDR4, Ryzen 5950X with 128GB DDR4

Zosh So what.. we spend all this money on what's supposed to be a smartphone with premium hardware only end up with a borked flashlight for no apparent reason!?

Hardware breaks. All hardware breaks eventually, some hardware breaks earlier. In only a billion years either Mars or Mercury might well crash into the Earth (source).

Software can break too, sometimes in subtle ways. Completely resetting all of the software on a device is very inconvenient, but it can greatly reduce uncertainty about whether a given phenomenon is due to hardware breaking or software breaking.

Probably nobody knows how often any given Pixel component tends to break. Google is probably in a better position to have good guesses than others (they handle in-warranty repairs and sell parts to third-party repair shops), but they probably don't hear about lots of failures, because people may decide to junk a device instead of fixing it. So maybe Pixels have an elevated rate of flashlight breakage compared to other phones, or maybe not.

If some part of some phone breaks at a rate that is genuinely elevated far above normal breakage rates, there may be lots of reports online, maybe class-action lawsuits, warranty extensions, etc. But if one Pixel in a million experiences flashlight failure there might be only a few scattered reports online from people with unusually bad luck.

Vanadium version 134.0.6998.135.0 released:

https://github.com/GrapheneOS/Vanadium/releases/tag/134.0.6998.135.0

See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

raccoondad Installing or updating GrapheneOS provides all of the latest SoC firmware. The reason we recommend updating first is because it's nice to have the latest fastboot mode firmware for using fastboot mode. It reduces the chance of anything going wrong. It also protects the device against the computer being used to flash it and avoids having unpatched known vulnerabilities in verified boot which could impact the initial verification via the verified boot key shown at boot. The recommendation is both due to compatibility and security reasons for the install. The end result of flashing GrapheneOS is the same regardless, since it flashes all the firmware itself, at least if the computer you used to flash it wasn't compromised.

Cyberslut6161 You do not need a Google account to update the stock OS. You're mistaken about that. The reason it's considered best practice to update it first is so that you have the latest fastboot firmware for when you start the flashing process. This minimizes the chance of encountering incompatibilities or bugs. Regardless of whether you do it, it will flash the latest firmware as the first step of installing, then switch to using it, so you'll have the latest firmware right away before it begins flashing the OS. Having it in advance reduces the chance you run into any issues with the start of the install process due to having the latest firmware patches including any fastboot mode bug fixes that are available.

Thanks for the invaluable work.

sha0

I disabled all automatic updates that I could identify. It is simply the case that in the industry, the vast majority of software development does not make efforts to keep UI changes separate from security-related changes, so I do sometimes forfeit security in favour of a stable UI. (A case of "beggars trying to be choosers," one could argue.)

You chose to have a device missing essential privacy, security and other patches. We cannot provide support for people on multiple year old OS releases.

It seems that the GrapheneOS feature for installing Google-related features was no longer supported by GrapheneOS infrastructure, by this point, for this older version of GrapheneOS. I was forced to seek a "less reputable" source for the Google-related features. After reviewing many of them, I found a source which seemed to be the least offensive to my distrust and I installed it. All seemed well.

Not something compatible with requesting support either. You're using some weird third party sourced Google Play apps on an old GrapheneOS version. Google doesn't support using their services without updating the apps.

March 19th, 2025: I unlocked my phone many times, but at some point in the afternoon, I tried to unlock my phone and my code was not accepted. I tried several times, then rebooted the phone. I have tried many times, since then, but without success. I believe the last note I saw reported that I've tried 192 times.

Sounds like you did something unintended as part of disabling the apps like disabling an OS component required for the OS to function. No way for us to know what you did.

Sometimes I see that the final digit of the retry-timer appears to switch back and forth a couple of times very quickly, as it counts down. For example, "3 2 3 2, 2 1 2 1, 1 0 1 0, 0 9 0 9, 9 8 9 8," etc. This isn't consistently observable, however; apparently random. This could be a simple UI flaw, although I can't quite imagine how that flawed logic might be.

You're on some multiple year old OS release. We don't need reports of old Android UI issues.

Perhaps because I use an older GrapheneOS, a specially-crafted image at a popular "free online sound meter" web-page (visited shortly before the problem) introduced bad software onto my phone and changed the lock-code software so that the phone accepts no code and logs all codes that I try and submits those codes to a malicious collector of codes. I've seen at least 2 other discussions in which a person having a comparable experience shares that "after a [few hours / few days], the code was suddenly accepted!" If the "bad software" includes such a timer and then releases the phone back to the relieved owner, then it seems likely to be imagined to be an owner error, all along, but having collected code-attempts from that owner.

Highly unlikely.

Perhaps because I unlocked another phone (having a different code) shortly before the problem, this scrambled up my memory of my usual code, but somehow this scrambling-up persists beyond 72 different codes that I've tried. (All of them "phone muscle-memory bells ringing" and not PIN codes for anything else I might have PIN codes for.) I've unlocked both phones multiple times within the same day before without becoming scrambled up, however.

That's possible. People often forget their PIN right after recently changing it or after not using the phone for a long time if either of those is relevant. Sometimes people don't recall changing it if they did it while very tired or otherwise impaired such as alcohol or other drugs.

Perhaps GrapheneOS decision-makers became aware of a security-concern so severe that they issued an unconditional software update through an emergency band, but this has broken my code-entry process.

There's no such thing.

Perhaps one or more cosmic rays reached the innards of the Titan M2 chip and ruined the bits of certain keys, so even if my unlock code is correct, it'll never work.

It would not boot anymore but rather would show the corruption screen asking you to wipe. It's near impossible for this concept to have happened.

All of this modern security is a double-edged sword: it's great at keeping people out of your data. Sometimes you are one of those people.

There's backup support, which works far better in the current GrapheneOS releases you refuse to use.

The Google Pixel 6a does not appear to support booting an alternative kernel. Normally in a case of potentially catastrophic data-loss, I'd take a DD copy of the storage block-device and deal with it later. For example, with other, older phones, I could boot TWRP, make a DD copy, install a new operating system on the phone (erasing data), then if the new OS seems unsuitable, I could once again use DD to restore the phone to the previous state, with all data intact. Not only does the Pixel 6a not appear to support 'fastboot boot <kernel>', but TWRP doesn't support the Pixel 6a, anyway. Having no DD, I can have no "snapshots" of known-good states, for this phone. Not only that, but the fancy chips (like Titan M2) imply that storage-keys might not even be stored on the disk: having the disk is not enough to represent the state of the device.

No, you're just used to having an insecure OS without the standard security model, unlocked device, a third party recovery image, no verified boot, non-working disk encryption which doesn't actually work without using a long passphrase, etc.

During the October Maps ordeal, because I could not use DD, I used SeedVault to try to back up my data, before I upgraded the GrapheneOS version. Since I do not have 2 Pixel 6a devices, I was unable to fully test a restoration and I had to cross my fingers. I was disappointed by the results: most of the apps (including Google apps) did not correctly restore to an installed state. Some apps were restored, but their data wasn't restored. The content of a SeedVault backup is not at all easy to work with from a computer: an unofficial extraction-tool exists, but one doesn't get a directory of files as they appeared in the FS on the phone. I would score SeedVault at a notch above useless, since I believe it did restore some pictures. For contrast, when I restore a DD backup of an old phone to that phone, that phone is as it was on the day I took the backup. Fortunately, at least one popular, privacy-oriented messaging app has decent backup and restore features, although not for their computer-based variant. I was also surprised to learn that Vanadium history isn't something that can be backed up nor restored, by design.

You're using an old OS release from before Seedvault worked far better than it did back then. What do you expect? You're choosing not to use most of the OS improvements but are complaining about what you're not using. GrapheneOS is dramatically better today than in 2022. If you want to use GrapheneOS from 2022, you are not having an experience which applies to people who use the current OS.

Maybe the "unlock timer" UI isn't representing whatever timing representations the "Titan M2" is keeping track of, so maybe many some of my attempts have failed because the UI did not indicate a distinction between "retry-timer is still in effect" versus "the attempt has been tried and rejected by Titan M2."

No, it is a UI showing the timer from the secure element as reported by it to the OS.

Maybe if I had "fingerprint unlock," I'd have some alternative. Why would anyone ever want to submit their fingerprint to any software that they hadn't written themselves, though, or lack imagination regarding finger-choppers breaking down the door?

You leave your fingerprints on everything you touch including the phone. It is not much of a secret. It is also not available to the software, just the secure element which does not store it but rather makes a fuzzy hash model it updates with each usage to gradually adapt to fingerprints changing over time along with covering a wider area of the finger. It is a secondary unlock mechanism for After First Unlock state, within 48 hours of last primary unlock and with 5 attempts total (20 for stock OS). It can be used with our 2-factor unlock feature with a random 4 digit PIN (failure to enter the PIN counts towards the fingerprint unlock attempt limit).

I appreciate many features of GrapheneOS.

Yet you don't actually use current GrapheneOS, you use some old version and some of your complaints are things which got massively improved over time. It is far better now than it used to be and we aren't really interested in hearing how an OS release from years ago isn't up to your standards yet you won't use the current GrapheneOS.

If you want to ask for help and give feedback here, you can use current GrapheneOS.

GrapheneOS version 2025032100 released:

https://grapheneos.org/releases#2025032100

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

Android 15 QPR2 introduced a bug where the Microphone indicator will sometimes remain active after Microphone usage ends. We've confirmed this issue is present in the stock Pixel OS for both Android 15 QPR2 and Android 16 Beta 3. We're working resolving the regression but haven't figured it out yet.

Here are several upstream issue reports:

https://issuetracker.google.com/issues/388151378
https://issuetracker.google.com/issues/392596949
https://issuetracker.google.com/issues/401832184

It does not mean that apps are actually continuing to use the Microphone. They introduced a bug where the OS can miss that it stopped.

The annual Proton Lifetime Charity Fundraiser from the Proton Foundation has concluded for 2024. We were one of 10 organizations selected for their fundraiser back in 2022 and received a donation amounting to $10,000!

Now they have sent us another $5000 as part of their commitment to support projects that were recipients in previous years. We want to thank the Proton community for all their generous donations making all of this possible and Proton Mail for matching their donations. Their financial contributions to other privacy and security software and organisations is commendable and we're happy to see their users are supportive as well.

Donations are what fund our work on upcoming features and improvements to GrapheneOS, maintaining our current ones, and the upkeep of our infrastructure.