Skip to content

Work with Android's lock screen instead of around it - #61

Merged
windoze95 merged 1 commit into
mainfrom
android-lock
Oct 13, 2026
Merged

windoze95 merged 1 commit into
mainfrom
android-lock

Conversation

@windoze95

Copy link
Copy Markdown
Owner

Only Android's PIN protects an R1's data: storage is encrypted with a key tied to the PIN, and Android throttles guesses. robotOS's recovery cover can be bypassed through debugging, safe mode or other Android screens. This makes robotOS behave well once a PIN is set, and documents the setup.

  • Button while locked: pressGate() routes a press to LOCKED when KeyguardManager.isDeviceLocked. The press then only wakes the lock screen and still silences a ringing R1. Each ignored press is recorded in the event log.
  • Tap-to-sleep: ScreenPolicy.sleepNow() uses the root sleep key first, so Android's "lock after screen timeout" applies. Previously, once device admin was active, every tap called lockNow(), which locks immediately and would have demanded the PIN on every wake. lockNow() remains for lost mode and as the no-root fallback.
  • Open with this R1's PIN (Add recovery-screen PIN access with gateway unlock after five failures #45): the recovery page shows the button when Android has a secure credential and the R1 isn't restricted. It launches createConfirmDeviceCredentialIntent. On RESULT_OK, WorkspaceClient.confirmedByOwner() confirms the current fence ticket, grace included.
  • Tests: DeviceActivity.resetForTest() clears the static cover state between cases. Two existing tests had been passing only because of state left over from earlier cases.
  • Docs: INSTALL.md gains "Lock it with a PIN": the PIN, a 15-minute lock delay with "Power button instantly locks" off, and device admin from Host & devices. HUB.md explains the model.

Validation:

  • 387 Android tests, 5 new: the press gate, tap-to-sleep with and without root, the PIN path through Android's confirmation intent and result, and no PIN option for restricted or unsecured R1s. Lint has no new warnings.
  • A signed 0.6.7 preflight ran normally on the R1, which has no PIN yet. The locked-button and PIN paths will be checked on hardware once the owner sets a PIN.

Closes #45

Only Android's PIN protects the R1's data (storage encrypted with the
PIN, guessing limited by Android); robotOS's recovery cover can be
bypassed. This makes robotOS behave well once a PIN is set.

- The button does nothing while Android is locked except wake the lock
  screen and silence a ringing R1, so nobody can reach Hermes without
  the PIN.
- Tap-to-sleep uses the sleep key, so Android's "lock after screen
  timeout" applies. With device admin on it used lockNow(), which would
  have demanded the PIN after every tap. lockNow() remains for lost mode
  and as the fallback without root.
- The recovery screen offers "Open with this R1's PIN" when the host
  can't confirm a wake (#45). It uses Android's own PIN confirmation, so
  robotOS never stores the PIN and Android's guess limits apply. It never
  opens a lost, revoked or cleared R1, and the host's next answer still
  applies.
- Tests reset DeviceActivity's shared cover state between cases.
- INSTALL.md walks through the PIN, the 15-minute lock delay and device
  admin; HUB.md explains the protection model. Release notes for 0.6.7.

Closes #45
@windoze95
windoze95 merged commit cb22dd4 into main Oct 13, 2026
3 checks passed
@windoze95
windoze95 deleted the android-lock branch October 13, 2026 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add recovery-screen PIN access with gateway unlock after five failures

1 participant