# Android hardening

The Android presentation layer uses resource strings for Kotlin-owned notices,
action labels, counts, and durations. Rust-owned presentation text remains opaque:
frontends do not parse or translate it. Repeated editor actions include the field
label, and hidden editor values are checked against the actual Android accessibility
node tree as well as Compose semantics. Compose accessibility checks run before
interactions in every app screen test.

Blank name searches do not traverse the password store. QR luminance inputs reject
zero or greater-than-4096 dimensions before allocating the decoder image; owned
decoded luminance bytes are zeroized. License loading runs on the IO dispatcher.
Editor keystrokes coalesce encrypted recovery checkpoints for 150 ms; save,
reorder, and recovery wait for the latest checkpoint. This changes persistence
scheduling, not authorization or the interactive unlock boundary.

## Native journey budgets

The `android_ci.py emulator <serial>` gate requires exactly one numeric measurement
for each journey below and rejects missing, duplicate, malformed, or over-budget
values. Raw fixture output remains local; published reports contain numeric values
and test status only. The large-tree fixture contains 1,000 valid encrypted entries
in 50 folders. These timings measure native/repository work, not rendered frame
latency or a physical device.

| Journey | Required budget | API 26 ARM64 / 4 KB | API 37 ARM64 / strict 16 KB |
| --- | ---: | ---: | ---: |
| 100 editor input updates | < 500 ms | 4 ms | 6 ms |
| Editor update p95 | < 32,000 μs | 61 μs | 102 μs |
| TOTP discovery cache rebuild | < 15,000 ms | 1,924 ms | 1,861 ms |
| QR image analysis | < 5,000 ms | 99 ms | 91 ms |
| 1,000-entry tree navigation | < 3,000 ms | 11 ms | 11 ms |
| 1,000-entry name search | < 5,000 ms | 27 ms | 26 ms |

Both configurations reported `OK (31 tests)` for app instrumentation and passed
the native core journey and bridge suite. Opt-in inspection and biometric tests
remain assumption-skipped unless explicitly requested; these runs do not establish
their manual coverage. Native load samples ranged from 32.7–35.2 ms on API 26 and
63.3–78.7 ms on API 37 with strict 16 KB pages. Five debug cold starts ranged from
202–279 ms and 708–1,086 ms respectively. These debug activity timings are separate
from release Macrobenchmark startup measurements.

## Adaptive checks

`Tier2WindowTest` exercises searchable Preferences and keyboard activation using
actual window dimensions. The API 26 emulator passed compact (411 dp), medium
(640 dp), expanded (1,067 dp), 200% font with RTL, landscape with 200% font and RTL,
and a smaller window with 200% font. Size, density, font scale, and rotation settings
were restored after the run. This covers window geometry; it does not establish
hinge occlusion or folded/tabletop posture behavior.

The shell consumes IME insets, and the activity explicitly requests `adjustResize`.
The optional `hardeningIme=true` instrumentation argument opens a real keyboard
and checks shell content bounds against the platform IME inset. It reproduced an
overlap before the shared-shell fix and passes afterward on API 26 and API 37 with
strict 16 KB pages. Temporarily enable `show_ime_with_hard_keyboard` for this check
and restore its original value afterward. Full app instrumentation also reported
`OK (31 tests)` with `hardeningRtl=true` on the strict 16 KB image.

## Release benchmarks

`android_ci.py performance <serial>` installs the benchmark app over the retained
installation and records five cold and five warm startup iterations. The benchmark
variant uses release code and shrinking, debug signing, and shell profiling; the
distributed release variant does not enable profiling. `ReportDrawnWhen` waits for
the shell to leave its native loading state. Compilation is preserved rather than
resetting application data.

The startup gate requires five complete numeric initial/full-display samples for
each mode, with cold startup below 5,000 ms and warm startup below 3,000 ms.
Before installing the generated profile, release-like median full-display times
were 268.6 ms cold / 131.2 ms warm on API 26 and 1,203.5 ms cold / 427.0 ms warm on
API 37. These emulator observations preserve existing compilation state and are
not a claim of profile speedup. Raw traces and device metadata stay local; CI
artifacts retain only API/ABI and the reviewed numeric samples.

`android_ci.py profiles <serial>` generates a profile from startup and the existing
Preferences journey. Generation requires API 34 or newer so compilation reset
does not fall back to reinstalling the app on older non-rooted images. Inspect the
generated local artifacts before promoting them into the app source set. Generation
uses a non-obfuscated `profile` variant, while startup measurements use the shrunk
`benchmark` variant. Both use release source code and debug signing.

The committed `app/src/main/baseline-prof.txt` was generated on the API 37 ARM64
emulator from the startup/Preferences journey on 2026-10-11, with 22,331 rules and
SHA-256 `687afdc199dacf0736dc1c577767dea9b81ddc987b5b61b02b5afed5e501b503`.
Regenerate it with the `profiles` command after changing those journeys; use the
untimestamped `BaselineProfile_startupAndPreferences-baseline-prof.txt` output,
check that application class names are unobfuscated, and rebuild the release APK
to verify its compiled `assets/dexopt/baseline.prof` remains within ART's size limit.

## Completion boundary

Issue #105 explicitly depends on every Android feature UI issue. CameraX (#106),
TOTP list/detail (#107), mutation workflows (#108), Credential Manager/Autofill
(#109), and TOTP discovery UI (#110) are still open. Their final screen accessibility,
camera interruption, cached-open/refresh presentation, and provider response
latency cannot be certified by tests of the existing screens. Keep #105 open until
those implementations and the remaining environment/posture checks are complete.
ARMv7 is package-validated; the installed runnable emulator images are ARM64.

On 2026-10-11 the user explicitly requested committing the independent implementation
now and delaying final coverage. Issues #106–#110 received `critical`; resume those
eligible Android enhancements in numeric order, then revisit #105. Remaining
checks include TalkBack/Switch Access and contrast/motion modes across the finished
screens, real hinge/posture and live-resize coverage, and low-memory, doze, battery,
network, camera-interruption, and storage-pressure scenarios. Do not close #105
based solely on the current instrumentation and window-geometry results.