Facts:

October 1st, 2022: I purchased a Google Pixel 6a, after researching GrapheneOS and then choosing that device. At some point very shortly after that purchase, I installed GrapheneOS "TP1A.220905.004.A2"; probably the "2022092800" iteration:

I set up a lock-screen code that was different than my previous cellular telephone. I set up the "instant lock" so that this code would be required immediately after I press the multi-purpose top button to lock the device.

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

All was well until Google decision-makers ruined one of my favourite features in Google Maps, for my GrapheneOS scenario:

September 9th, 2024: After updating to the latest GrapheneOS and finding that (predictably) the UI had changed and that there was no Maps improvement, I reverted to "TP1A.220905.004.A2". At that time, I probably chose the same lock-screen code as before, but perhaps I chose a different one.

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.

At some point in November or December, YouTube UI changes and the broken Maps feature yielded enough frustration that I disabled all Google apps and features that I could identify, including the Play Services and another related "background" app. After that, all was well...

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.

After reaching 9XX seconds for the retry-timer that appears after a failure, very rarely I see that the retry-timer indicates a very low number that I'd seen when my count of attempts was much lower, such as 120 seconds. Most of the time, the number that appears is 9XX seconds. If I then reboot the phone and try to enter a code, it seems that the retry-timer that appears is something like a continuation of the time remaining from the previous attempt: sometimes in the 8XX range.

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.

Imagined possibilities for what has happened:

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.

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.

Perhaps a blood-vessel in my brain broke and neurons responsible for the "muscle-memory" of unlocking my phone were destroyed.

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.

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.

Thoughts about this ordeal, so far:

Write down your unlock-code. (Some readers might respond, "Well, duh," but some readers might respond, "Oh, I'm going to do that, right now.") Maybe not literally, in case you're worried about an unauthorized person obtaining it from a search of your papers, but maybe in a password management system that isn't on your phone, or with a trusted party, or requiring multiple trusted parties to reveal it. Having certainty about the correct code permits this bisection of the problem-space:

  • Yes, I know the code is correct, so the problem is that the phone is broken or hacked.
  • No, I don't know the code is correct, so I could be the problem, or the phone could be broken or hacked.

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.

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.

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.

Back up your data at least once per week. Also during that October ordeal, I decided to back up my data more frequently than I had been. That frequency wasn't great enough, since I now have no access to recent data that I wish I had access to.

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."

I've read about the retry-timer, here:

It's not clear to me why the UI isn't indicating "Retry in 1 day" to me, after my 192 attempts, but is indicating 9XX seconds, at the most. Either I've misunderstood something or that article isn't applicable to my device or the UI isn't accurate or the phone has been hacked and the code-entry is malicious software. Assuming that there is a flaw with the UI which is misleading me, I will ensure that I wait a full 24 hours, in-between my next attempts.

Despite 2 nights of sleep so far, I haven't woken up with the unlock-code muscle-memory suddenly restored with great certainty. Assuming that I've forgotten for now, maybe it'll come to me some day in the future, but it seems that if I want to preserve this data, I'll have to set this phone aside and use another phone, for productivity. I must have unlocked this phone at least 40 times per day since I bought it, so it's very surprising to suddenly "lose" this.

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?

I appreciate many features of GrapheneOS.

Here is another, similar discussion:

    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.

      Thank you for your response, GrapheneOS.

      I must admit that given that my 2 other forum discussions have just been locked, perhaps what I've typed has offended one or more GrapheneOS folks. What can I type and/or do to try to repair the relationship? The "obvious" answer is "use the latest GrapheneOS," it seems, but that has challenges, which I'll explain later on.

      In one of the now-locked topics, I was simply asking a question, then shared a self-answer, which someone else in the community liked, then a response from today seems to be that if I don't use the latest GrapheneOS version, I should not participate in the forum.

      In another of the now-locked topics, I explained that I had indeed updated my GrapheneOS version to the latest one available for my device, which then involved obtaining the Google features via that latest GrapheneOS' Google-fetching features, but that Google Maps' Timeline feature still didn't work. Perhaps that was somehow unclear from my message.

      Later in that same topic, I'm accused of going on an ignorant rant and attacking GrapheneOS and software developers without understanding how it works. Perhaps that response might be viewed in a different light, given the clarification of my previous paragraph, just above. I don't think that's a fair characterization.

      I haven't intended to "attack" anyone. I'm unsure if some of the imagined possibilities I shared in the top message from today might have been offensive, but they weren't meant to be. I'm sure that many GrapheneOS users are distrustful of other parties: that's probably why they appreciate the efforts, time, and money spent by GrapheneOS folks towards extra privacy and security. The imaginary scenarios were intended to be aligned with other scenarios that I've read in other discussions. They weren't accusations, which is why I used the word "imagined." I appreciate your kind response ("no such thing") to one of them, which provides clarity for the community and for the curious.

      I am a software developer, since roughly 1991. I am also a person who has major struggles with UI changes. I'm sure that there are many reasons for why much software these days mashes UI changes with security changes, but that causes me no end of grief. Please forgive me for occasionally voicing this concern to other software developers, at relevant times. Some day, maybe they'll be received well. I'd be delighted to enjoy the latest fruits of GrapheneOS, relative to security. Unfortunately, these do not appear to come separately from UI changes. (As an example, the unlock-code entry-dots are circles on my old GrapheneOS, but changed to pointy shapes in the latest Pixel 6a GrapheneOS in October.)

      In response to "third party sourced Google Play apps": I've tried to clarify the situation, above: I did try the latest GrapheneOS and thus the latest Google Play software, in October. It didn't help Maps, so I reverted GrapheneOS.

      I shared the timeline in today's first message. I disabled all Google items in either November or December. I do not perceive a relationship between that activity and my sudden grief 2 days ago, unless there was a ticking time-bomb or an exploit caused by those disabled apps.

      I thought someone in the community here might respond with something like, "Ah yes, the old PIN screen with the weird count-down numbers. This is a known malware by celebrated hacker-group X and you've surely fallen victim to it, doubtless due to your old GrapheneOS version," or with something like, "Ah yes, looking carefully, I see that this fluctuating count-down timer is still the case, today. Neat! What a minor UI quirk, though." I'm sorry if this was perceived as a gripe about GrapheneOS: it wasn't.

      In response to "Highly unlikely", as you doubtless known image-processing vulnerabilities come along, from time to time, and not even all that long ago. CVE-2023-41064 is a recent example for a different platform:

      So that imagined scenario was just a whimsical example. These imagined scenarios were just that: imagined and not projected as reality, nor accusatory of GrapheneOS incompetence.

      In response to "used to having an insecure OS," what I'm used to is laptop and desktop and data-centre computers: having trust-keys on a chip, adjusted through a password-protected interface, where those keys are used to verify boot pay-loads, which then boot an OS which requests another password for LUKS-protected data. This is a clean separation between the data and the machine and so yes, the data can be placed into any other machine and accessed, if the data-password is known. If the "standard security model" (in the context of GrapheneOS and/or Android) is that the device should be a single point of failure for the accessibility of the data, then yes, I guess I'm not used to that.

      Given some of the responses, it seems that I jumped into GrapheneOS too early: that is, I got used to the UI before backup/restore features were ironed out and now that they have been, I can't access those features without also confronting all the UI changes that will have come along for the ride.

      Why are Androids and cellular telephones appearing to depart further and further from the laptop and desktop computer ecosystem, despite these former devices also being computers? I want my data to be conveniently accessible in a non-Android Linux. SeedVault only appears to have unofficial relatives for plain Linux. Why doesn't it produce a .tar.gz.gpg file, or some other format that standard Linux tools can manipulate with ease? Why does it require an already distrustful user to download unofficial software, in order to get at their precious data? Please note that I'm not actually asking this paragraph's questions with the hope of a response to them: they probably belong in a different topic after I am positioned to satisfy the "I'm using the latest GrapheneOS" condition. What I'm trying to do is to share context about the harsh score that I gave to SeedVault. I'm sure that SeedVault developers worked and continue to work very hard, and that their efforts are enjoyed by many or even most users. That's admirable. I wish it had worked well for my goals in its 2022 iteration.

      About the secure element's retry-timer, after waiting more than 24 hours since my last attempt and trying again, the count of failed attempts has changed from 192 to 162 and the count-down message indicated that I ought to try again in "653 seconds." I took a picture. After waiting for that count-down to complete and after trying again, the message again noted "162 times" and to try again after 9XX seconds, but I didn't catch it with a picture. If it's true that the UI is reporting what the secure element reports, then perhaps this discrepancy can be explained by malware or perhaps it can be explained as unworthy of any attention because it's from a 2022 GrapheneOS version. I was expecting to be hindered by 1 attempt per day. Surely all of the newer GrapheneOS users having more than 140 attempts will be hindered at such a rate with clarity about that rate.

      In an effort to foster a shared understanding of the recent responses to my attempts for discussion, would this be a fair notice for someone considering using GrapheneOS?:

      Please note that it should be clear that GrapheneOS project participants (such as developers) have a focus on security and privacy, above all else; we're quite good at it and we certainly strive for it. Without infinite resources available to the project, the fact of the matter is that some considerations rank less than others, in priority. It's also unlikely that everyone can be satisfied by any project, so we make decisions about trade-offs and attention using our best judgment, which should go without saying.

      For example, it's convenient for us to make releases in which security enhancements, privacy enhancements, feature enhancements, and user interface changes are all bundled together. The alternative strategy to release these subjects separately would be extremely cumbersome and complicated; you wouldn't enjoy it and we wouldn't enjoy it. We're always hoping to work for your best interests.

      With this strategy, we expect, for example, that a tiny majority of GrapheneOS users might object to a seemingly trivial UI change, but still benefit from the overwhelming majority of the rest of the release. Some of our decisions are informed by considering the majority of users, as opposed to a tiny minority. Some UI changes are inherited by other parts of the Android ecosystem; outside of GrapheneOS efforts. If you are a person who suffers greatly from UI changes, GrapheneOS might not be the best choice for you. We know that some elderly folks and some folks having disabilities and even some other folks might be in such a situation. (You are unlikely to find a better alternative, though, elsewhere!)

      Also, please keep in mind that sometimes updates don't always work as planned. Sometimes a bug might strike in even the largest crowd of software users. This possibility for GrapheneOS updates is no different than for any other software updates, although we don't find it likely.

      If you do not keep up to date with GrapheneOS, not only do you expose yourself to historical risks that we address in our updates, but we're not interested in diverting resources to attend to the fall-out from your out-dated position. GrapheneOS participants want to maximize value.

      NOTE: The above is not a quotation from any GrapheneOS project participant. It is imagined by me as the type of notice that might be fair to share with people who are interested in GrapheneOS.

      Please try to read what I type with openness to charitable interpretations. I might not be an expert at writing frankly and leading to positive interpretations, such as light-hearted responses. I always hope for those, however. I apologize if what I typed included not-well-received criticism.