Using the same lock screen PIN since receiving Brax3.
Absolutely sure of the PIN code. However, suddenly today the phone will not unlock with the known PIN.
Any known mechanism or bug that would cause this issue? Any way to recover without losing data?
Hey there. We’re not aware of any bug related to the PIN. It’s the first time reported on any OS version so far, as far as we can see.
There is no way to recover it without losing data (it’s a security feature). You will need to factory reset the device via recovery mode, and set it up again.
If using your PIN is a concern in the future, we’d recommend setting up a fingerprint authentication as well. It’s safe as it’s stored locally only and not share in the cloud.
@tech-support thank you for the reply.
Another strange issue is that when the phone prompts: “Try again in ___ seconds | Too many attempts with incorrect PIN”, the seconds-remaining display flips back and forth for the current time remaining. For example, if it is counting down 59, 58, 57, it will alternate “59, 58, 59” and then “58, 57, 58” and then “57, 56, 57” and so on.
An obvious question would be: How can a user trust a device if this can happen? This is not a noob error; the PIN is definitely known and correct, yet the phone is suddenly rejecting it. Is this probably due to a disk- or file-level corruption, and how could it occur? (What’s the mechanism by which this failure is possible?)
There was a similar iodé report here, where the solution apparently was to let the battery drain to ~10% and enter the PIN again:
That’s a fair feedback. As is with technology, technology will sometimes fail. As far as your privacy is concerned, better to fail as false negative than false positive when it comes to unlock your device.
This seems to be an upstream Android issue based on some reports we’re reading.
We have reported this issue to the iode devs. We’re not sure whether it’s the same issue that’s been reported in the post you shared and if there is anything they can do to identify and fix this.
@tech-support thank you for your swift replies - much appreciated.
After further reflection on this situation, it could be argued that the idea – better to fail as false negative than false positive – may be logically true but practically false in a situation where hardware is unreliable. If, at any time, a device is unreliable enough to erroneously lock out a legitimate user and render important data inaccessible in the name of security, this evokes a sense of great insecurity about the device and any data stored on it. In other words, an unreliable device itself becomes a security problem for any data it stores. In many years of owning smartphones, not one has ever rejected its correct PIN until Brax3.
There is data on the current Brax3 in question which only exists on the phone and must be recovered. The phone has not been factory reset or wiped.
I have some additional questions for you.
It seems that this issue would be due to an anomalous failure either in (a) the MTK hardware-based encryption scheme and/or (b) a disk- or file-level corruption of encryption keys/database(s).
Similar issues have been reported for Android devices on various forums, including iodé- and Lineage-specific posts. As you mentioned, it may be an upstream Android issue. Is there a possibility that a future iodé firmware release may correct the issue such that the original, correct PIN would once again work to unlock the phone, if the phone was left as-is for now and upgraded via SP-Flash tool in the future?
As PIN entries are attempted on the lock screen, the time interval between allowed entries increases and is now above 1,900 seconds. Is there a certain number of PIN attempts at which iodé-7.7-20260724 will permanently lock the phone or automatically wipe/factory-reset it?
Understood if some of this is better discussed via email. Please write at [email protected] if you prefer that route, and thanks again for your insights so far.
No, not really. We’re not sure what is causing this issue, but even if we understood what is causing it, there will be no way to deduce and guess the PIN on the device.
If a fix for this issue (that we have not yet confirmed is a real issue on the OS running on the BraX3) is available upstream, it will be implemented in the OS, of course. But we do not know if that will be enabling the unlocking of the device with the PIN previously set.
There is no wipe function triggered by failed unlock attempts. It’s a feature we’re working on for an upcoming device in our roadmap (Brax Wink), but not available on this OS on the BraX3.
DUMPSYS OF BAD BRAX3 (BB3) LOCK_SETTINGS
adb shell dumpsys lock_settings
Current lock settings service state:
User State:
User 0
LSKF-based SP protector ID: [redacted535]
SID: c0d82468ce80b4e5
Quality: 0
CredentialType: PIN
SeparateChallenge: true
Metrics: unknownKeys in namespace:
synthetic_password_[redacted535]Storage:
User 0 [/data/system_de/0/spblob]:
58 2026-09-20 01:30:13 0000000000000000.handle
8 2026-07-31 23:32:53 [redacted535].failure_counter
72 2026-09-20 01:30:13 [redacted535].metrics
93 2026-09-20 01:30:13 [redacted535].pwd
16384 2026-09-20 01:30:13 [redacted535].secdis
186 2026-09-20 01:30:13 [redacted535].spblobStrongAuth:
PrimaryAuthFlags state:
userId=0, primaryAuthFlags=9NonStrongBiometricAllowed state:
RebootEscrow:
mRebootEscrowWanted=false
mRebootEscrowReady=false
mRebootEscrowListener=com.android.server.recoverysystem.RecoverySystemService@814e108
mLoadEscrowDataErrorCode=0
mPendingRebootEscrowKey is not set
RebootEscrowProvider type is null
Event log:SoftwareRateLimiter:
Enforcing: false
userId=0, protectorId=[redacted535]
numFailures=159
numDuplicateWrongGuesses=0
statsCredentialType=3
timeSinceBootOfLastFailure=PT1M50.454S
lockoutEndTime=PT0S
numSavedWrongGuesses=0PasswordHandleCount: 0
ThirdPartyAppsStarted: true
A couple additional details for the malfunctioning Brax3, which is still not factory-reset:
Just noticed that the lockscreen is currently showing the date July 31 (while today is actually September 30), and adb shell date result is Fri Jul 31 21:43:12 CDT 2026. The date had been synced correctly prior to the PIN failure, and no manual/intentional process was used to change the date or reset the phone; so perhaps simultaneous with the PIN failure, other items such as datetime were also erroneously reset or changed.
Also, posted below (separate post) is a lock_settings service dump from the failed-PIN bricked Brax3 (“BB3”). Compared to a Brax3 (same firmware) with its PIN still working (“WB3”), two differences are noted:
StrongAuth: PrimaryAuthFlags state:
Metrics:
It seems strange that the working Brax3 (WB3) has metrics=known while the non-working Brax3 (BB3) has metrics=unknown.
Things happen sometimes for no rhyme or reason and you just use the solutions that are available to remedy it. Sucks for sure 
but sounds like you need to do the reset to fix it like they suggested almost 2 weeks back.
@BobO yes but that involves destroying required data.
How many digits are u using for your PIN? 
About a year ago I had the same issue with one of my BraX3 phones. I was using a 20 digit PIN and after weeks of using it that way with no problems, all of a sudden it wouldn’t let me in. I did wind up getting in by letting the phone rest for 10 hours and then tried again. It finally took my long PIN. Once in I changed it to an 8 digit PIN and have had no problems since.
@Lazarus thank you for this info. The PIN here is a 4-digit sequence.
Wow-I guess the fingerprint backup is the only thing left.
@tech-support - quick question:
When running a lock_settings service dump (“adb shell dumpsys lock_settings”) from any normally-working Brax3 device, even after making wrong PIN entries on the lockscreen, the User State: Metrics: value is always “known”.
With the malfunctioning Brax3, that User State: Metrics: value is “unknown”.
What does that Metrics value specifically mean or signify in the lock_settings dump? What would cause it to be “unknown” while it is “known” on a normally-working device?
Based on our research, it means the lock-settings service currently has no password-metrics object available for that user. In this case, it could be a consequence of the unsuccessful unlock, rather than the reason the PIN is rejected.