Files
IronStorage/docs/android/password-navigation.md
hugo 8c9341f214
Android ARM verification / rust (push) Failing after 46m4s
Android ARM verification / android (push) Failing after 9s
Dependency security audit / rustsec (push) Successful in 22s
Implement Rust-owned adaptive Android password navigation (#96)
2026-10-09 12:25:02 +02:00

3.6 KiB

Android password navigation (#96)

The Passwords tab loads typed Rust pages from the configured app-private store. Folder traversal uses repository snapshots and capability-scoped metadata; it never reads encrypted entry contents, loads a key, or requests authentication. Rust supplies paths, parent paths, stable row IDs, kinds, icons, titles and entry counts.

Rust hashes object revisions and page membership. Actions and restored selections must match the current page revision. A replacement at the same path cannot inherit an old selection. Missing folders return to the nearest existing ancestor; malformed or inaccessible stores report an error with explicit refresh. The permission checks avoid changing revisions when already-private objects are reopened.

Compact windows push into folders and entry detail; expanded windows use Material 3 Adaptive list/detail panes, including hinge-aware directives. The same checked state drives both layouts. Folder context and status messages scroll with their pane, so landscape and large fonts retain usable content. Keyboard focus, activation, labelled overflow controls, long press, heading semantics and custom accessibility actions use the same revision-checked Rust targets. The actions dialog offers Open and object details; future mutation actions can consume the same checked target.

Only path, selected ID and page revision enter saved state. Restore and foreground refresh revalidate them in Rust. The native worker serializes requests and discards obsolete results. Entry selection opens a locked detail view without authentication; explicit Unlock uses the existing Rust authentication lease and structured entry presentation. Rust checks the target before and after opening it. Secrets are absent from saved state, submitted passphrases are cleared, and leaving/backgrounding the screen clears presentation and locks the lease. Expired leases clear displayed fields. The remaining viewer, biometric and lifecycle features retain their own milestone issues.

Validation

Rust regressions cover Unicode and long names, 32 levels, empty folders, verified restoration, identical-byte replacement objects, deleted ancestors, invalid paths, and idempotent private permissions. Native instrumentation creates its isolated folders and encrypted entries through Rust APIs, traverses them with authentication locked, recreates the runtime, opens structured masked detail, replaces an entry and rejects the old selection before authentication. Compose instrumentation exercises keyboard activation, touch/overflow, detail unlock/lock, stale refresh, expanded panes and large fonts.

Computer-use checks operate the persistent user-created local store, without installing app-data packages or resetting its data. The emulator matrix remains ARM64 API 26/4 KB, API 37/4 KB and API 37/strict 16 KB; ARMv7 is built and audited. Manual TalkBack speech was not observed; labelled semantics and custom actions are exercised through the Compose UI. Physical-device testing is excluded from this milestone's validation scope.

The issue delivery passed all four required workspace gates (462 tests), the full Android verification build, strict dependency/license and ARM/16 KB package audits, and native/Compose instrumentation plus five cold starts on each of the three persistent emulators. Compose checks include Enter, D-pad Center, labelled custom accessibility actions, touch/overflow, compact unlock errors, and expanded panes at 200% font scale. Computer use verified the configured store's empty root, landscape list/detail panes, refresh without authentication and portrait recovery. No emulator, repository, preferences or Keystore data was reset.