qqq-android/docs/history/SESSION-STATE-through-2026-11-04.md

Historical record, superseded by current status. Do not treat as current.

November 4 — production signing custody (current; supersedes the signing-deferral notes below)

The owner decided on signed-APK/MDM distribution with a new QRun-owned Android key, stored in a QRun vault in the owner's Personal 1Password account. Key alias qqq-mobile-release, PKCS12 RSA 4096, certificate SHA-256 BDDB2D2F45A5925C643A83ABAF616C1EAB2387DC5CDA7B645A6F4C0D5B17A9FF, valid through 2056-10-27; app ID io.qrun.mobile.scanner. Backup recovery was verified 2026-11-04 (recovered file hash, keystore opened, certificate compared). Root built unsigned 1.0.0/versionCode 2 (lintRelease + assembleRelease: 0 errors, 0 warnings, 2 information) from source matching protected main 0ae2101f082c241ca6a70462dc9ec3057aa6c906 (only docs differ), then signed it in isolation with apksigner at 2026-11-04T16:22:05Z; the key was not passed to the application build. Local signed artifact and verification are complete: QQQ-Mobile-1.0.0.apk, SHA-256 EE5AC896B8985AF6F11B2E883955925D6571A2913D74A4AACCDB564B79394D51; v2+v3 verify, exactly one signer with the certificate above, 16 KiB alignment pass, non-debuggable, app ID io.qrun.mobile.scanner. It is not installed, published or production-qualified; the development-signed TC22 install and data are intact. Remaining: qualification of the actual production-signed APK on a migrated or different device (normal device untouched), first distribution (needs an HTTPS server), and paused CI wiring. No Infisical/CI activation, no scanner release workflow, no tags; the shared CI hold is unchanged. Runtime app code is unchanged from main 0ae2101; Android guide PR 12 is still open. The November 4 manual all-pass was for the development-signed build and is not requested again; it does not qualify the new signer. See RELEASING.md. Entries below, including the deferral of signing, are historical.

November 4 — signing readiness documentation (historical)

RELEASING.md was rewritten as concise Gitea-first release readiness. This documentation update has been checked against the actual Gradle configuration and Gitea caller. No keys, secrets, tags, releases, CI, build or source were changed. Central main Android lifecycle 3634 passed and published SDK AARs but is not a scanner-APK signing pipeline. Local Gradle signing via SCANNER_KEYSTORE/SCANNER_STORE_PASSWORD/SCANNER_KEY_ALIAS/SCANNER_KEY_PASSWORD exists; release builds are unsigned without them. Production signing still needs the owner's channel decision (direct/MDM vs Play), an organization-owned key with secure storage and a backup owner, and signed-APK device acceptance. The operator reported manual acceptance all-pass on November 4; the last recorded installed build was development-signed. Signing/distribution remains last; older entries below are historical.

November 3 — verified widget-state reset fix

ProcessViewModel.reset() now clears widgetState so last scanner feedback no longer carries into a new run. The regression proves ordinary step updates retain feedback and reset clears it. Root verified all 57 mobileapp JVM tests (zero failures/errors/skips), scanner lint (zero errors/warnings), debug APK assembly and the 255-file standards gate. Prior head 9cf789c passed hosted CI3553 in 16m22s; this fix still needs its own hosted checks and normal PR10 → PR8 → main integration. The installed APK and manual acceptance are separate gates; signing/distribution remains deferred.

November 3 — current checkpoint (verified; supersedes all older entries below)

• Source: f72b90d08cf29d2785cef1d5c5e7eeaf75f9afd2 is the signed application-code commit published in PR 10, independently read back over SSH before this documentation update. Gitea CI 3480 succeeded on it (unit-test, device-test, package, secrets and gate; root read the UI). Root also verified a clean git merge-tree of f72b90d with actual main b75fdac and merged nothing. Pull requests #8 and #10 remain open; no 1.0 is released. This documentation update leaves runtime code unchanged from CI-passing f72b90d.
• Installed: the updated normal APK 4AAB6951D3B0ABDDD4F5A8DC6790DCD84233EE08179B68DB108BF77909AB850E is installed with the same signer and no data clear. Connected, Apps/Settings, portrait, location on and the brand-only system wallpaper preview were verified. No wallpaper or company profile was applied.
• Fresh verification: 222 JVM tests, lint 0 errors/0 warnings (2 info), APK builds, 23 Node tests, 255-file source standards pass. A fresh disposable TC22 Echo ten-stage run passed 109/109 semantic requests (simulated inputs and printing).
• Authentik: fresh real desktop acceptance passes (nonce rejection, A login, logout with old-cookie replay rejected, fresh B without clearing cookies, logout) against the same isolated TLS fixture. The opt-in native harness is integrated and compiled, and its 8 launcher guards pass; the on-device run still needs the temporary CA and PIN interaction. No trust bypass. The normal server on 57832 is unchanged and ready.
• Server side: server 45f9cbd is signed and pushed (Gitea PR 7); the public QQQ 4.1.0-RC.21 source update is prepared for the next signed commit. The final RC.21 gate passed: 377 unique tests (Generation 179, Printing bridge 16, scanner 53, demo 8, mobile Record Files 18, Echo 68, Echo demo 35), zero failures/errors/skips, Checkstyle PASS, plus 15 real admin-browser E2E on public RC.21; the earlier MySQL timeouts did not recur. This is public core RC.21 with qualified owner inputs (three private pu507 libraries still resolve through the owner Printing POM), not a fully public or released cohort. The normal runtime core was not upgraded.
• Still open (not claimed): Generation canonical owner integration and public reproducible owner inputs; primary source CI, merge and release; manual TC22 trigger, value/type, AIM, label count, rescan, photo, GPS, projection and profile checks (operator remote); native Authentik CA, PIN and callback; signing/distribution, explicitly last. The normal TC22 shows Echo setup, Copies 1, Connected.

November 3 — final client installed; Authentik harness integrated (earlier; superseded by the checkpoint above)

The verified debug APK 4AAB6951D3B0ABDDD4F5A8DC6790DCD84233EE08179B68DB108BF77909AB850E is installed on the normal TC22 with the same signer and install -r. Existing sign-in, device approval and Connected status survived. Navigation, portrait setting, foreground-location toggle and the brand-only system wallpaper preview were verified; wallpaper was not applied. Feedback, managed configuration and AIM code are now installed, with physical trigger/fidelity still unqualified.

Fresh verification passes 222 JVM tests, lint zero errors/warnings, debug/E2E/test APK builds, 23 Node tests and the 255-file source standard check. The updated disposable TC22 Echo suite passed all ten stages with every request matching semantic operations; simulated input/printing only. The actual Authentik desktop test passed again on November 3 with strict TLS: nonce rejection, operator A, company logout, old-cookie rejection and fresh operator B. The opt-in real Authentik Android harness is now in the repository and compiles; native execution awaits temporary CA installation/device interaction. No normal app/server trust change was made.

Echo server source is signed and published at 45f9cbd in Gitea PR7. Generation copies now has an isolated canonical Git integration, with additive PostgreSQL migration verified on real PostgreSQL17. Shared source/dependency publication and hosted CI remain separate gates; no production 1.0 release or physical print claim. Earlier installed-APK/uncompiled-harness notes below are historical.

November 2 — Echo copies live and native acceptance complete

Echo setup now exposes optional Copies per scan, default 1, range 1–100. The server pins it for the run and submits one job with that copy count for each scan. The normal TC22 is connected and left on the fresh setup screen showing 1. Its installed APK remains D8109C61E71660D2195337DA988F7F692CC4A0DBE95F61230930D6549CAB4D9B; no client upgrade was needed for this generic semantic field.

Disposable TC22 Echo acceptance passed ten stages and 116/116 documented requests, including default 1, rejecting 0/101, selected 3 across two scans, recreation and Apps/Leave. Inputs and printing are simulated; physical label count is unconfirmed. The combined source passes 222 JVM tests, lint with zero errors/warnings, APK compilation and 15 Node tests. New scan-feedback, managed-profile/wallpaper and AIM source is not installed on the normal app.

The existing local server on port 57832 now advertises mobile-scanners 1.5 and mobile-record-files 1.0, retaining the original database, approval, accounts and printer settings. Server/owner gates passed 377 unique tests across the qualified module runs. Generation copies changes remain in the isolated owner handoff, awaiting canonical adoption/publication. Physical trigger/print/rescan, camera/GPS/projection and native Authentik remain open; the operator is remote and temporary CA installation is unconfirmed. Signing/distribution stays last. Older checkpoints below are historical; see FINISH-1.0.md for the current ledger.

November 2 — administrator viewing controls

Removed app-authored Stop viewing / Allow viewing, Stop device screen sharing and the custom notification Stop sharing action. The visible indicator, Android consent/system revocation, password/lifecycle guards, server authorization and lease expiry remain unchanged. The existing native regression verifies an informational non-clickable indicator with no stop/allow buttons, continued JPEG frames after resume, background frame clearing, administrator session termination and fresh login.

Verification: 185 JVM tests (44 core, 56 mobileapp, 85 host), eight Node guard tests, lint zero errors/warnings (two existing informational hints), debug/QA/test APK builds, and the real TC22 session-monitor scenario passed; all 112 native requests matched published semantic operations. The disposable QA packages were removed. Whole-device Android consent was not rerun for this UI removal.

Installed the verified debug APK D8109C61E71660D2195337DA988F7F692CC4A0DBE95F61230930D6549CAB4D9B on the normal TC22 with install -r and no data clear. The process restart required sign-in; restored the existing scanner account and verified Connected, the Echo catalog entry and existing approval. Local server57832 remains HTTP200 and the print service remains Running. This APK also contains the previously verified optional raw-scan metadata client, gated off against the unchanged installed mobile1.4 server. Existing unrelated source/test changes are preserved. No commits, publication or broader release work resumed for this scoped request.

November 2 — current checkpoint

Source candidate: immutable ScannerCapture retains SDK raw bytes as canonical Base64 before the callback returns and routes them through the ordinary semantic process payload. New optional fields are sent only after same-server discovery advertises mobile-scanners >=1.5,<2; older servers still receive the five legacy keys. Barcode text and symbology remain unchanged, scan/capture string representations are redacted, and a failed-submit regression proves the entire event is resent unchanged. Verification passes 185 JVM tests (44 core, 56 mobileapp, 85 host), lint with zero errors/warnings (two existing informational hints), debug/E2E APK builds and QA Android-test compilation. New native tests and operator installation have not run. The SDK configuration is unchanged and AIM extraction is not implemented by this transport slice.

Completed and verified:

• Android source fb3cc5d is signed and published as Gitea PR 10. It passes 174 JVM tests (44 core, 55 mobileapp, 75 host), lint with zero errors and zero warnings, and the debug APK build.
• The native SameOriginInterceptor fixes the cookie-bearing heartbeat that returned 403. The server's same-origin guard is not weakened.
• The normal TC22 installation was updated without clearing data. Existing login and device approval, heartbeat, the real print client's printer, fresh 4x1 media and published document selection, and Cancel then Leave all work against the one local server.
• That server is one QQQ demo on host port 57832. It runs Mobile Scanners/Echo, Collaboration/Record Files, Document Generation and Printing (API 1.10.0, mobile 1.4.0, printing 2.3.0). On this workstation, device port 8080 forwards to host port 57832. The original accounts, enrollment and approval are retained.
• The Printing owner has aligned the loaded 4x1 stock (101600 x 25400 microns at 300 dpi) and updated the real media revision. A real Echo 4x1 barcode document is published. The TC22 selected the actual printer, the fresh 4x1 media and that document, and Next succeeded and shows Scanner ready and Connected.
• The emulator is off because it stalls this workstation. Do not restart it automatically.

Not yet done:

• No physical Echo print or rescan has been proven. One separate synthetic HTTP Echo event reached the actual Windows spooler; physical paper and handheld print/rescan remain unconfirmed. One physical scan of QQQ-TEST-123456 has been requested from the user.
• Still open for 1.0: physical Code128 and leading-zero QR scan, print and rescan; full provider, camera, GPS, projection and device qualification; public coherent artifacts; primary Gitea CI; and final signing and distribution. Signing is deliberately last, by the user's decision. The first demo working does not collapse these requirements, and nothing here claims release readiness.
• Core native API merge continuation PR 1337 (a42f9e5) was reviewed with no actionable conflict regression and its 57 focused tests were verified. Normal CI and publication are not established, and default dependencies are not repinned.

The entries below are historical. Where they describe the printer media report, the 4x1 document or the same-origin fix as pending, this checkpoint supersedes them.

November 2 — native cookie Origin compatibility verified on TC22

The combined Echo Demo on57832 (reached through device port8080) returned200 for login, then403 for the cookie-bearing session heartbeat POST, because Android's native QQQ requests omitted Origin. The server's same-origin guard remains enforced. Core now has a small SameOriginInterceptor: it sets Origin from the actual request URL's canonical scheme/host/port only (default ports omitted, IPv6 bracketed, never credentials/input/headers) and is installed last so additional headers cannot override it. It is used by NetworkQQQRepository and the DeviceApi, MobileSessionApi and RecordFilesApi clients. Version discovery, presentation/logo fetches, OIDC/browser/token requests and redirect refusal are unchanged.

All174 JVM tests passed (44core/55mobileapp/75host), with zero failures/errors/skips. Lint has zero errors/warnings and two existing informational hints; debug APK build passed. MockWebServer tests cover exact Origin plus cookie on real POSTs, canonicalization, override resistance and redirect non-forwarding. Session and record-file host tests assert the header on their actual requests.

The verified APK (SHA256 0B872005B2FA84F693E73CC49133F5C1C02F732A034AA0635A2B50682A61A98E) was installed on the normal TC22 without clearing its data. Existing scanner login and device approval work against the actual combined server; heartbeat remains connected. Echo opens its three required choices, the approved printer and its reported media load, and Cancel -> Leave returns to the app normally. This directly qualifies setup/session/cancel against the strict host, not a physical print. The earlier112-request/two-synthetic-scan acceptance remains separate. (Superseded: the printing owner has since reported the 4x1 media and the 4x1 document is published; see the current checkpoint above. Physical printing is still unproven.) Emulator stays off.

November 1 — required Document choice verified on the real TC22

Echo asks for printer, paper/label size and Document once; all subsequent scans use those server-pinned choices. Android production code is unchanged: the generic semantic INTEGER/PVS/dependency controls handle it. The updated separate E2E app passed all7 stages on the actual TC22 (select Document, clear stale choices on parent change, validate required fields, queue two scans, recreate without duplication, Apps/Leave/CLOSED). All112 requests matched published semantic operations. Disposable app/reverse/fixture cleanup passed, normal app/data preserved, emulator off. Printing and scanner inputs are simulated; physicalScannerQualified/physicalPrintingQualified remain false.

Verification:99 focused/host JVM tests,8 Node guards, zero lint errors/warnings and both disposable APKs compiled; after a test-only fixed-footer click correction, the actual TC22 acceptance passed. Companion server source8da274e is signed/pushed with45 library and24 composed demo tests passing. Private live server53118 still has header fix101efc8 pending document-choice rollout; real printer pairing retry awaits the current Windows consent. Installed normal APK324227CC... remains sourcea2f0080, whose production code is identical to this test-only change. Full physical/provider/camera/GPS/projection/public artifact/signing gates remain open.

November 1 — Echo native semantic choices verified on TC22

Claude implemented named process possible values using the actual published searchProcessPossibleValues JSON contract, dependent-field metadata, cancellation/error/retry and stale-response rejection. The unchanged Echo fixture now completes login, enrollment/approval, printer/media selection once, two accepted synthetic scans, rotation/recreation without duplicates, and Apps/Leave closing the run on the real TC22. All86observed requests matched published semantic operations. Disposable-package cleanup passed; normal package/data and real printers were preserved.

Validation:169JVMtests,8Nodeguards,236-file source standards, zero lint errors/warnings and bothE2EAPKs pass. This is simulated printing, not EMDK or physical output qualification. The remaining immediate blocker is the real Generation/Printing adapter and template/host composition, followed by physical print/rescan. Normal installed APK remains625a275; normal server API1.9/mobile1.1. Production signing remains deferred.

Session state

Echo semantic presentation source checkpoint

The optional extension 1.4 acknowledgmentLabel and manualEntryEnabled hints are published on feature/echo-scanner-presentation (draft PR9). Existing defaults remain Saved scan/manual enabled; Echo uses Print queued/manual disabled. Strict compilation, 167 JVM cases, lint zero errors/warnings and debug assembly pass. Hardware, lifecycle and receipt predicates are unchanged. The server companion passes 69 consumer cases plus two contract cases; the optional Echo module passes 15 strict QQQ/H2 tests.

The normal TC22 remains the separately installed 625a275 build (APK AF13778A…3E9216), preserving sign-in/data. Its About screen was opened and Query artwork, both public links and licenses verified through filtered accessibility data. New Echo-native UI/actual owner adapters/physical printing remain unqualified; printing and document/scripting owners have acknowledged their implementation lanes. The running normal server remains API1.9/mobile1.1. Production signing/distribution stays the owner's final step.

November 1 standards fixes and About update

Applied the scoped standards review: copyright/SPDX, explicit imports, declaration headers, native official/three-space formatter profile, mechanical CI source gate and Kotlin warnings-as-errors. Strict compilation and163 JVM tests pass; all46 disposable sample native tests pass on TC22, and production QA instrumentation compiles. The native suite uses fixture providers; actual Android external-browser/provider acceptance remains separate. The existing formatter reports one unstable Gradle script and full formatter CI runner provisioning remains explicit in the review.

Settings → About QQQ Mobile now shows bundled Query artwork, app version, Dogfooding/Query public links and open-source licenses. The normal APK rebuild uses drawable-nodpi for the artwork. No credential/device parameters are added to website links. The preceding diagnostics/default-on GPS update remains installed until the preserving update recorded below; actual GPS fix is still open.

The real API1.10 Authentik desktop sequence now passes negative nonce rejection, A login, explicit company logout, old-cookie rejection, fresh B credentials/principal in the same retained browser context, and B local logout. Its provider-specific User Logout flow is required for company sign-out; default ordinary client logout stays local. Server0b53f34 is published and all8hosted checks pass. CorePR1369's exact architecture allow-list correction is being verified; full fresh core CI is not yet green.

November 1 diagnostics and location update

Diagnostics now uses a full-screen, scrollable native view with a connection summary, local-time newest-first activity, All/Problems filters, pause/resume, copy/share/clear and Back. Existing footer and menu entry points still block process input while diagnostics is open. Location reporting defaults on for approved signed-in foreground sessions; Android grants remain required, explicit opt-out persists and automatic permission requests are not repeated after denial. Controls remain under Settings → Device permissions.

The combined client passes 159 JVM tests, zero-error/zero-warning debug lint, normal/E2E APK builds and the focused diagnostics interaction test on TC22 using the separate E2E package. The new UI/default policy still needs normal-package field observation. This does not establish a physical GPS fix, background tracking, real provider sign-out or production release readiness.

The preceding signed checkpoint1c766bf was installed in place as APK E34AC3C6…C1874EB with private backup, matching signer and no data clear. The operator and backend confirm one Code128 and one QR event on these bytes, including exact leading-zero value001234567890 from EMDK/QRCODE. Apps → menu → Scan Capture round trip was also confirmed. The normal server remains API1.9/mobile1.1; API1.10 core159 tests, current contract3 tests and coherent scanner/demo/files/browser78 cases pass separately while real Authentik acceptance continues.

November 1 native authentication checkpoint

The optional company sign-out and original-nonce client changes pass 151 JVM tests, zero-error/zero-warning lint, debug assembly and native-test compilation. All 28 selected OAuth2 login/logout and authentication-lifecycle native tests also pass on the TC22 in the disposable sample application, with no failures or skips. The normal scanner package/data were preserved and its Activity is foreground again. These native tests use synthetic provider adapters; they do not establish real Authentik or external-browser acceptance.

Independent review covered all 26 implementation/test/documentation files in the frozen patch and found no security candidates (completed scan c358cde3-b51d-4451-b07d-8d1afe6c4485). This is a patch review, not a fresh audit of every unchanged file. Native OAuth now requires API1.10, the advertised nonce-validation feature and REQUIRED policy; TABLE authentication remains compatible. Company sign-out is separately advertised and explicitly selected; the automatic sign-out policy remains undecided.

The paired server changes and real A-to-company-logout-to-B acceptance remain in progress. Earlier real-provider testing established operator A and local QQQ invalidation, but retained browser SSO silently reused A; that failed handoff remains failed. This checkpoint is source publication, not a production release or installation of these bytes on the normal TC22 package. Signing/distribution remain the owner's final step. All historical entries below retain their original scope.

November 1 status and visible QR fixture

All eleven hosted checks at portrait-default7de2b508 passed. Public QR fixture checkpoint2e0fd962 is signed and pushed; docs/TEST-BARCODES.md records independent ZXing decoding of001234567890. Physical QR acceptance is still pending. Normal TC22 APK C89161C…C6340 remains installed with portrait requested, and the backend now has nine trusted EMDK Code128 events (eight on prior F3AF and one after the portrait update).

Release1.0 remains incomplete: actual Authentik acceptance remains pending; the local TLS proxy correction is verified, and provider configuration returned a validation error under diagnosis; physical QR, camera/gallery, navigation/failure, projection and GPS acceptance remain open. Filesystem portability passes142 discovered/138 passed/four existing skips, and the separate RF HTTP consumer now passes18 cases on a transitional custom-filesystem tuple. This supersedes its earlier fixture-compilation failure; it does not establish immutable/default dependency adoption or change the normal API1.9/mobile1.1 runtime on57832. Signing/distribution remain last by owner instruction. Current summaries supersede dated open-state statements below without changing their historical evidence or sealed review scopes.

November 1 portrait default installed; prior source fully green

The user requested portrait lock by default. Missing/invalid preferences now choose Portrait; all explicit saved choices remain available. Four focused policy tests, debug lint (zero errors/warnings) and debug assembly pass. Development APK C89161C…C6340 was installed in place after signer verification and a new private-data backup; no app data was cleared. Android reports the normal Activity resumed with SCREEN_ORIENTATION_PORTRAIT, and a direct screenshot confirms the signed-in Apps menu. Barcode/lifecycle acceptance of these new APK bytes remains pending; earlier F3AF physical evidence is preserved.

All eleven hosted checks at229fce3 passed, including both GitHub native runs (jobs124829276568/124828879619):35 shared cases, PixelCopy and all seven semantic scenarios. Logs show session-login-action-ready, session-fresh-login and the semantic request audit in both runs. Server documentation checkpoint2de8470 also passes all eight checks. Fresh checks will qualify the portrait-default source update. The operator confirmed the eight earlier Code128 events were deliberate trigger pulls. The QR was not visible in chat; a direct image link was supplied after unreliable browser automation, and current QR acceptance remains pending.

November 1 physical EMDK positive control verified

The operator reported Saved scan on the normal F3AF development app. Direct ownership-guarded backend inspection verifies eight new Code128 records for QQQ-TEST-123456, source zebra-emdk, TC22 attribution and eight distinct event IDs. This closes the current trusted hardware positive-control gap for Code128 only. Operator confirmation of repeated trigger intent and the current leading-zero QR remain pending; physical acceptance records exact APK/runtime and remaining lifecycle/retry/ownership gates. No normal app/data clear or QA run occurred.

Strict Firefox profile-only CA trust now passes issuer/hostname checks using the supported PLAYWRIGHT_FIREFOX_POLICIES_JSON entry point. Windows trust is unchanged; the earlier Windows-root approval question is obsolete. Actual provider startup/exchange remains unexecuted while an independently reviewed known-listener guard is prepared for genuine TIME_WAIT rows. Independent architecture closure of Android229/server2de reports no additional concrete source blocker and maps A1-A11 controls/tests; runtime/deployment/dependency/signing limits remain. Record Files compatibility now has a concrete exact-revision filesystem dependency gate in a new private cache; no frozen0515/default/runtime adoption occurred.

November 1 native CI — rotation passes, fresh-login test readiness under correction

Android5ba PR run41297344726 passed:35 shared native cases, PixelCopy and all seven semantic scenarios, including session-monitor. The duplicate push run41297340376 also passed rotation/recreation/mirroring/administrator termination, then timed out waiting for Username after clicking Log back in. Its request audit shows completed Android logout200 and no second Android manageSession. Static review confirms that the test awaited only the label, which also renders while the logout action is disabled. This supports a test-readiness race; the failure artifact does not record the button state at the click, so no production cause is asserted. The correction waits for a final signed-out message and enabled action, asserts enabled and clicks once; it retains all fresh-login/session assertions. The opt-in device-screen test uses the same readiness requirement. Fresh native execution remains required.

Independent release automation review of three exact5ba files found no actionable source finding; scope and hashes retain external-configuration limits. A separate API1.9/mobile1.2 backend-only smoke passed readiness and shutdown with private credentials removed. Its launcher initially failed closed on the Node shim PID; actual Node resolution corrected the helper, and the unsuccessful fixture also cleaned up. No TC22 QA test, ordinary-app cleanup or normal-server replacement occurred.

November 1 TC22 walkthrough — reported disappearance investigated

After the operator reported that touching the handheld crashed or moved the app, direct ADB inspection found the normal scanner process alive and its Activity resumed/focused, with no crash-buffer entries. A direct screen capture showed the connected sign-in screen; the black desktop mirror was not reliable evidence of an app crash. Restored the existing scanner demo login using locally encrypted credentials, and a subsequent direct capture confirmed the Apps menu. Opened Scan Capture to resume the manual walkthrough. No production defect has been reproduced or fixed by this inspection; physical trigger/navigation acceptance remains pending. No QA instrumentation or app cleanup was launched over the operator's normal app.

November 1 morning — normal app updated; native test correction pending hosted verification

The normal TC22 application is now updated in place to the reviewed development APK F3AF638E…E9FAA. Matching signing identity and a new owner-only private-data backup were verified; app data/enrollment were not cleared. Non-streaming installation completed and the normal process is running against the preserved API1.9/mobile1.1 demo. This supersedes older unchanged-normal-APK statements below. Operator login/navigation/scanning confirmation is pending; no production release is claimed.

Published e04fdb2 passed CircleCI and CodeQL, but both GitHub native runs failed the same session test: it requested rotation then another Activity recreation without waiting for configuration convergence, and the barcode draft was empty. The test now waits for landscape/resumed configuration and asserts the draft after rotation and again after explicit recreation. This is a test synchronization correction awaiting native execution, not a demonstrated production draft fix. Physical barcode attempts separately hit a wrong expected value (operator confirmed the old test code), a transient focus assertion and an ADB timeout; none is a full hardware pass. Focus preconditions now wait briefly within the120second stage deadline, and install timeouts identify the operation.

The opt-in QA screen-consent harness, shared HTTP helpers and both QA/E2E test packages compile. Its early safety checks reject missing operator opt-in and both protected demo ports without device access. Actual consent/Home/Stop/expiry/end-session acceptance remains pending. The harness author stopped at the workspace agent-credit limit; root completed the compile corrections and continues directly. A real Authentik fixture is compiled with pinned images downloaded, but no services or OS trust changes have occurred; temporary Windows CA approval is still pending.

November 1 — refined device-screen client and published paired server

The refined client passes137 JVM tests, all package/lint gates, fresh four-APK inspection and the TC22 ordinary-UID scan-ingress regression. Continuous image draining retains one latest buffer; repeated Share is blocked through service binding. Fresh independent follow-up review found no concrete issue. The source-pinned1.2 server 1041693 is published and passes39 server/six demo/all15 browser tests with strict195-JAR/2,441-class provenance in a cloned private Maven cache. Hosted client CI now targets that exact source. No actual projection consent/physical trigger is proved; the normal APK remains unchanged and its running demo remains qualified1.1. See candidate scope and hashes.

November 1 — initial consent-based device-screen checkpoint

The optional device-screen client and paired1.2 server pass initial compilation and automated gates:135 Android JVM tests, lint/all package builds,39 server and six real-HTTP demo tests. Parent and fresh independent static review found no reportable client issue across the nine changed-file inventory; actual consent and projection behavior remain unverified. See scope, hashes and remaining acceptance. The normal operator APK and qualified1.1 demo remain separate. Frame freshness/binding refinements and final native acceptance are still required.

November 1 — hosted Back focus failure and physical-trigger checkpoint

Published Android head 6845abc5289fa975e6f50b23b159c3131a82eee1 has a successful CodeQL check; not all CI is green. CircleCI android-test job 140 fails three NavigationTests before injecting Back: their Activity is resumed and the device is interactive/unlocked, but Activity/decor window focus stays false for five seconds. Both job attempts reproduce the failure. Retained JUnit contains no focused-window owner, so the cause is not yet established. Failure-only diagnostics now classify the focused window as own/system/other, report bounded own-window flags and the known network-dialog visibility; they retain the five-second focus requirement and actual Back injection. CircleCI unit job 141 passed. One GitHub native run failed and the other was still running at inspection; neither is claimed successful.

The physical QA attempt using APK hash prefix CFFF reached its first hardware-ready stage but recorded no acknowledged operator scan. A final near-deadline HTTP poll timed out; this is not physical scanner acceptance. Evidence is preserved under C:/Users/james/.cache/qqq-tc22-physical-attempt-20261101-0210; physicalTriggerVerified remains false. A separate, unqualified test follow-up is prepared to avoid sub-second status polls and label deadline failures without extending the 120-second stage bound. Its compilation is deferred until the concurrent scanner changes are ready; it is not part of this diagnostic checkpoint.

The earlier normal-server ownership hold is resolved. After correcting the CIM positive control, the owner completed the reviewed upgrade to the frozen ecf/b14 API 1.9 / mobile-scanners 1.1 TABLE runtime. A fresh backup, original-column invariants, old-after-new recovery logins before and after stopping the predecessor, and live login/metadata/logout for both demo accounts passed. Two devices and three scans, including the leading-zero value, were preserved. Private evidence is retained in C:/Users/james/.cache/qqq-normal-api19-002594902b1942bda2480c512ed644ab/normal-verification.json. The normal operator APK remains unchanged. Further optional screen-capture source is under separate implementation; these diagnostic edits do not qualify it.

October 31 — published client checkpoint and probe target clarity

Signed client checkpoint d316567 is published to existing draftPR8 and the clean canonical feature checkout is fast-forwarded to it. Fresh hosted checks found two CodeQL intent-redirection annotations in the separate permissionless test probe. Inline static triage at that exact revision classified both as not actionable: the exact QA/E2E package allowlist dominates both fixed-action broadcast sends, no arbitrary activity/service is launched, and the probe adds no sender authority. No alert was dismissed or completed audit rewritten. The probe now maps accepted requests to explicit final package literals rather than forwarding even the validated caller string. Probe-only build/lint and repeated ordinary-UID eight-forgery/manual-positive acceptance pass; production APK hashes are unchanged. Publish this source clarity follow-up and inspect fresh CodeQL/client checks before release. Physical trigger and whole-handheld viewing scope questions remain pending.

October 31 — final SDK/navigation candidate verified for publication

All three Android Back handlers and the toolbar arrow now use one live Main-owned drawer-first action, preserving standalone fallbacks. The native regression first proved a real process-level bypass opening Leave behind the drawer; the corrected case passes with one actual Android Back, preserved process/draft and zero cancellations. It also covers seven other overlay/focus gates. Current source passes127 JVM tests,34 TC22 shared cases in115.717s and the additional overlay case in17.948s. A distinct-signer ordinary-UID test passes against the exact current QA APK: eight forged broadcasts cause zero extra process steps/records, while a manual positive control saves through the real API. Actual physical trigger proof is still false/pending; the barcode-visibility question is unanswered.

All four APKs pass fresh DEX, manifest, native-hash and packaged-notice inspection. Independent review of the final SDK/navigation patch found no concrete defects requiring changes. See exact hashes and evidence boundaries. The final code is ready for an explicitly authorized signed source checkpoint; hosted client checks must run after publication. Coreecf has18 hosted successes and published serverbf174a6 has8. New whole-handheld viewing scope clarification is pending; current capture is QQQ Mobile only. Normal operator app/server and emulator remain unchanged by these tests.

October 31 — coherent backend accepted and published; final Android gate running

The owner explicitly authorized signed commits and publication after automatic review required direct commit approval. Core ecf0f550 is published to draftPR1334. Server code b14d925 plus acceptance documentation bf174a6 is published to draftPR6. Fresh37 server/five demo tests, strict runtime provenance (195 JARs/2,440 unique QQQ classes/zero duplicates, Guava33.7.2-jre/H2 2.2.224), actual API1.9/mobile1.1 discovery and all15 browser tests pass. The normal operator runtime remains unchanged. Hosted checks are running; one Windows job failed to download PSScriptAnalyzer before project analysis and received one scoped retry.

The trusted scanner now also blocks physical input behind drawer/Settings/Diagnostics/Account/leave overlays and lost window focus, with a live callback guard. Two new coordinator tests and one production-widget QA native regression are added. Auth0 stable3.0.0 and Coil3.0.4 replace inherited prereleases; two native raster/SVG/error rendering cases are added. These source changes require the new combined build and device run. The first build correctly rejected stale notices: AboutLibraries10.9.2 did not declare its dependency graph as an incremental input. A lazy resolved-coordinate input now invalidates its standard generator; strict license/version gates remain enabled. The combined gate is running again. Earlier APK hashes and hardware evidence do not qualify these changes.

October 31 — trusted scanning packages verified; runtime provenance caught a mixed dependency

The approved optional EMDK implementation passes all 49 scanner JVM tests, debug/release lint, debug/unsigned-release/E2E assembly, and production-path QA/probe assembly. The separately signed adversarial probe has a verified distinct test certificate; its temporary private key was deleted. These results do not establish physical trigger or injection resistance: disposable TC22 acceptance is next, and the normal operator APK remains unchanged.

Exact-source core ecf0f550a0357cec6387c2b54efca128a405a629 passes the full selected dependency closure: 4,507 tests discovered, zero failures/errors, 16 existing skips, plus the configured coverage/static gates. Scanner server a8ed108 passes 37 tests and its demo passes five. Runtime provenance then correctly rejected an old RC.20 backend dependency in the demo classpath. Browser and QA fixture execution are held while the consumer dependency management is corrected; these test passes are not qualification of that mixed runtime. The verifier remains strict, and no shared artifact or normal server was replaced.

October 31 final client audit and isolated integration follow-up

The owner explicitly accepted Zebra's EMDK terms and selected native trusted scanning. The optional adapter is now being implemented; the earlier 32-test result does not qualify that new hardware path. Wrapper checkpoint 7e0cbee and the five verified client security fixes df532ff are signed local commits, not yet pushed. Core's local 331a99d additionally pins patched Guava; its full selected dependency-closure suite and verification analyses are running in a fresh private repository. On Windows, only the inspected cosmetic shell coverage-summary execution is omitted because of quoting; actual coverage checks and static analyses remain enabled. Hosted Ubuntu retains that summary.

The completed remediation batch passes 109 JVM tests, scanner lint with zero errors/warnings, debug/native-test and unsigned sample release assembly. All 32 selected TC22 native cases pass in 117.325 seconds, including ten new authentication lifecycle tests. Actual packaged sample release controls deny cleartext and backup and include all ten cloud/transfer exclusions. Five audit fixes have regression evidence; trusted scan ingress remains open pending the separate EMDK license decision. The new debug APK 8c4d3886...c512a is not installed over the operator app. See the scoped review checkpoint.

The deep client audit completed and sealed against clean published d1de0bf, with one medium and five low findings. The medium finding is delayed password-session adoption after logout/server switch, including retained original-server models. Low findings cover sample release cleartext, failed Auth0 local sign-out, unauthenticated exported scan input, stale legacy Auth0 callbacks, and sample session backup. Source fixes are being prepared with delayed-response/provider and host regression tests; none is closed merely from editing source. Static coverage is partial, with external provider/server/dependency implementations and bundled binary implementation gaps excluded. Real configured Authentik and physical operator acceptance remain separate.

An isolated fix/hosted-native-ci checkout keeps this work separate from the audited source and installed operator app. Core draft PR #1334 publishes reviewed native API 1.9, credential-safe logging and explicit-null parser fixes at 00f6c49ef4c21bedb7c62ccad535bd6de1008948. Focused source gates passed 154 tests with two pre-existing disabled cases, plus a separate 17-test null/HTTP gate. Server a8ed108 canonical UTC migration passes 37 root and five demo tests and every hosted check.

A fresh private Maven repository and unique CI-only core version are qualifying the fixture from those exact commits; no shared artifacts or operator runtime are replaced. Hosted acceptance must include the nullable admin form and session-monitor scenarios. A failure-only focus diagnostic preserves the five-second guard and actual Back input; the cause of the hosted focus loss remains unproven.

October 31 unconfirmed scan exit correction

The operator reported Leave process permanently disabled with “The last scan is not confirmed.” The existing JVM harness reproduced that settled missing receipts remained a hard navigation block. A new regression failed before the correction. Settled unconfirmed scans now show an explicit warning that they may already be saved; Stay retains the original retry event, while Leave process uses the existing server cancellation and clears the event after cancellation succeeds. Failed cancellation retains the event and exposes a separate, explicit Leave anyway choice that clears local state without another request; the dialog warns that the server process may still run and saved changes are not undone. Active requests and pending photos remain hard blockers, and receipt validation is unchanged. Added JVM guards/cancellation/fallback cases and a native lost-response/malformed-receipt/Stay/failed-cancellation/explicit-exit regression. Final bounded verification passed all 46 mobile JVM tests, scanner lint/debug APK and sample/test APK assembly in 18 seconds. The TC22 follow-up passed all 21 selected native cases in 53.482 seconds, including the new lost-response/failed-cancellation/explicit-exit case. The operator update is being coordinated separately; actual configured Authentik acceptance remains pending.

October 31 navigation/authentication review checkpoint

The combined client checkpoint passed 102 JVM tests (26 core, 43 mobileapp, 33 scanner), scanner lint, debug/E2E APK assembly and native-test compilation. The final follow-up build passed in 1m3s (266 tasks, 34 executed). The TC22 rerun passed all 20 selected navigation/input/account/OAuth tests in 49.235 seconds, including all seven synthetic AppAuth cases. The first run exposed Back during drawer opening; the handler now also handles a drawer targeting Open, and the native helper waits for settled UI before hardware Back. Native acceptance evidence distinguishes real handheld execution from the simulated browser/provider. No actual Authentik sign-in is claimed. New hosted CI is required after publication.

Independent source review found no concrete defect in the native authentication/navigation patch; this is not final security or deployment clearance. AppAuth package evidence confirms 131 bundled entries, 126 external runtime dependencies, nine complete texts and unchanged eight native libraries in the inspected debug/E2E APKs. OAuth2 depends on the companion core UI API1.9 native-session contract, still pending publication/host adoption. TABLE_BASED remains usable on compatible API1.8 servers. Production signing/distribution and actual shared-operator/provider acceptance remain separate gates.

October 31 semantic authentication — synthetic native acceptance passed

The combined source passes 102 JVM tests (core26/mobile43/scanner33), scanner lint and debug/E2E/test APK assembly. All seven synthetic native OAuth cases and the navigation/input/account suite passed on TC22 as described above. Generated notices contain 131 entries including AppAuth. The initial sandbox run stopped at the existing debug-key lock; scoped rerun preserved the key and completed successfully. Testing used the separate sample package; no emulator or normal operator installation was started for this checkpoint.

The native descriptor now requires an advertised prompt: "login" policy, applied through AppAuth and bound to each pending attempt. Missing/unsupported prompt policies fail closed. Focused tests cover policy changes and mismatched returned requests; the real shared-handheld acceptance gate includes switching operators with an existing browser SSO session. This requests fresh authentication; it is not global IdP logout or verified auth_time proof.

The owner requires Authentik when configured by the server. Generic OAuth2 browser sign-in is implemented against an additive UI API1.9 nativeSessionLogin capability, with explicit issuer/discovery/callback metadata and an authenticationFlow marker on the existing session exchange. AppAuth performs authorization with S256; the secret and code exchange stay on QQQ. TABLE_BASED remains unchanged and native bearer metadata is kept distinct. Client gates, callback/lifecycle checks, deferred cookie adoption and focused tests are implemented; actual configured Authentik acceptance remains pending. See AUTHENTICATION.md. No live provider settings or operator data were changed.

October 31 navigation correction — native acceptance passed

The primary navigation uses one hamburger drawer with All apps and server-authorized app entries, plus Settings and Diagnostics fixed at its bottom. The duplicate toolbar Apps button and Switch app overflow action are removed. Back remains beside the hamburger within apps/processes, Account stays separate, and prelogin/pending-approval drawers hide business destinations. Drawer dismissal and secondary surfaces preserve active work; selecting a primary destination retains the existing leave and pending-upload guards. Compilation and the selected native navigation suite passed, including the drawer-opening Back correction above. The successful checkpoint below describes earlier session/photo acceptance. No installed operator app, server or data was changed for this correction.

Current verified checkpoint — October 31

All 12 shared TC22 navigation/input/account tests pass. TC22 orientation (all five persisted policies), offline licenses, synthetic camera/gallery/rotation/remote-logout cleanup, and the full session-monitor scenario pass. Session monitoring includes real JPEG app pixels, background clearing, renewed viewing on resume, operator pause, administrator termination and fresh login. Photo/session request audits match published semantic operations. JVM reports total 91 tests (22 core, 36 mobileapp, 33 scanner), zero failures; scanner lint passes. Notice coverage gates and packaged APK inspection pass for debug/release/E2E (125 runtime dependencies, 130 entries and nine complete license texts), and negative omission/blank-text cases fail as required with generated metadata restored.

The false-offline investigation was a test-clock issue, not a demonstrated timezone defect. The independent standalone file-backed JVM test in America/Chicago passed across 18 seconds. No timezone workaround or relaxed heartbeat/offline policy was added. Remaining work: publish the Android review checkpoint and verify fresh hosted CI, finish independent full audits/native attribution, qualify immutable optional dependencies/CI and real lens/operator acceptance, then return to signing/distribution as the owner requested. The normal installed app and operator demo remain on their earlier versions; isolated test acceptance is not deployment. Historical entries below preserve earlier failures and are superseded by this checkpoint.

Viewing diagnosis resolved the apparent offline state: the test advanced only16ms of Compose coroutine time per250ms wall polling, so heartbeat LaunchedEffect timers did not run during125 widget polls. The standalone non-UTC file-JVM regression passed and audit ordering confirmed zero heartbeats during those polls. The helper now advances by elapsed monotonic wall time. The next TC22 run reached session-mirror-frame: actual app JPEG pixels were delivered/decoded and background clearing passed. It then failed the already-identified old resume assertion because no viewer demand was renewed. Resume now polls the admin widget again; rebuild/full scenario rerun is active in the current turn. No production heartbeat interval or offline threshold was relaxed. The standalone regression source is in the companion demo, added by the read-only diagnosis agent and verified separately.

Latest viewing diagnostics: eligibility is available=true, but no indicator/frame upload occurs; 125 widget requests and 18 native heartbeats succeed. A real HTTP regression now explicitly requests the viewer widget as a browser (without the Android client header) before the native heartbeat; both demo tests PASS, ruling out the simple cross-channel lease-isolation hypothesis in that fixture. Actual core widget response fields are layout, blocks, type, blockTypeName; corrected the diagnostic extractor to read blocks (the earlier blank status was an incorrect subBlocks assumption). That diagnostic change needs rebuild/rerun to obtain the actual server widget status. All runs in this checkpoint are terminal. No production state-sharing change was made on an unproven hypothesis.

The window-focus synchronization rerun advanced past capture eligibility: no APP_NOT_FOCUSED failure remains in that run. It now times out at the viewer indicator. Request audit shows 125 successful web widget renders and 18 successful Android heartbeats, with no screen-upload operation. Added bounded failure diagnostics for current server availability/reason and the widget's status text (never image data or credentials), to distinguish lease issuance from client rendering. This newest diagnostic needs rebuild/rerun. All native processes from that run are terminal. Android changes are staged as a review checkpoint, but later focus/diagnostic edits remain unstaged; re-stage and verify before committing.

Screen-viewing follow-up reproduced a stale tracked-focus flag: server reported APP_NOT_FOCUSED while instrumentation confirmed interactive=true, no keyguard/device lock, both Activity/decor focus=true and lifecycle RESUMED. ScannerActivity now observes actual view-tree window-focus events, resynchronizes on resume, and removes the observer on destruction. Existing captureAppScreen independently checks actual decor focus, so capture protection remains enforced. Scanner unit/lint/E2E APK verification passed (build1m19s); the focused real-server TC22 scenario is rerunning in the active root turn. The operator demo remains on extension1.0; no normal-app update was made.

TC22 photo acceptance PASSES against the verified guarded0352 fixture: synthetic external-camera result automatically uploads, exact hash/size/provenance/parent and collection association are inspected, gallery staging survives rotation/recreation, leaving is blocked while pending, and remote session termination clears the private copied original without deleting the selected gallery source. All recorded native requests match published semantic operations. The run exposed and fixed a real UI-thread defect: ScannerActivity now dispatches unauthorized-session navigation on the main thread and ignores callbacks for a superseded session. Scanner unit/lint/APK rebuild passed before the successful native rerun. Fixture owner metadata remains in the private task cache; do not infer a normal-app deployment or actual lens capture from this synthetic result. Real session-viewing acceptance is starting next in the active root turn.

TC22 navigation/input/account acceptance now PASSES all 12 tests on rebuilt sample APKs. Orientation (all five policies) and offline licenses also pass. The guarded Record Files private launcher needed execution outside the sandbox for its process to survive; current private fixture PID111928 was started with a 900-second lifetime, with protected metadata path in the task cache. The first native photo run reached Saved and verified exact bytes/provenance/parent, then failed because the test assumed stored collection order was zero-based. Actual owner storage is one-based while manifest/receipt order is zero-based. Corrected that assertion and the duplicate Apps selector; photo rebuild exec64104 is active in the current turn, then rerun the synthetic camera/gallery/rotation/remote-logout scenario. Preserve fixture ownership and stop only that verified fixture when finished. Session mirroring acceptance and final audits remain open.

Latest navigation rerun is terminal: 11 of 12 TC22 tests pass. Restored account/server assertions now pass. The remaining failure selected both the menu action and the closed drawer heading named Switch app; a stable menu-action identifier and matching test selector are added. Those last two changes need rebuild/rerun. No native test or fixture remains active from this run.

TC22 follow-up: orientation and offline licenses each PASS their instrumentation scenario. Shared navigation ran 12 tests: 10 passed, with failures from duplicate visible/closed-drawer Apps selectors and an old account-dialog expectation that server selection still lived there. Added a stable toolbar Apps identifier, preserved the account user assertion, and verified restored server selection under Settings instead. Rebuilt sample/test APKs successfully; navigation rerun is starting in the current root turn. Guarded server changes and passing 18-test evidence are committed/pushed as84ffd7c on the existing draft PR; no merge or production release.

Latest TC22 result: the rebuilt orientation acceptance PASSED (one instrumentation test covering all five policies, persisted selection, actual fixed screen axis, Activity recreation and a fresh Activity launch). The bounded configuration-convergence wait resolved the prior timing failure; the axis assertion remains enforced. Guarded Record Files integration now passes all 18 tests and runtime/Checkstyle verification, with evidence retained in the companion module. Root is running TC22 licenses followed by shared navigation acceptance as exec session85018; poll that handle before starting another device run. No operator-app update or production release is implied by isolated test acceptance.

Latest verification follow-up: the notice-integrated APK build log ends BUILD SUCCESSFUL. Explicit TC22 orientation acceptance ran and failed because the observed screen axis was still portrait when landscape was requested. A bounded 15-second configuration convergence wait was added to the native test while retaining its final axis assertion; rebuild/rerun remains required. The disposable test runner cleaned its resources. Emulator remains closed. Record Files guarded-artifact verification has four unresolved intake-event concurrency test failures; see the companion integration session state. No production release is qualified.

2026-10-31 Android acceptance follow-up: the bounded pre-notices build passed 89 JVM tests (core22/mobile36/scanner31), normal and isolated APK assembly, and scanner lint with zero errors/warnings; broader modules retain inherited vector/dependency warnings. The emulator remains off after confirmed workstation stutter. On TC22, session capture remained safely blocked with APP_NOT_FOCUSED after recreation; no mirror frame was uploaded. The 12 shared navigation/input/account tests then ran: six passed and six failed (stale account/server-confirmation assertions, duplicate catalog/drawer text selectors, and a hardware Back case). Assertion corrections and window-focus diagnostics are prepared; these failures are not counted as passes. Orientation Settings, retained manual draft state, synthetic photo E2E, explicit physical photo fixture support, and bundled-license Settings entry are now implemented but require the next compilation/native acceptance. The license owner is running the bounded integration qualification. Ordinary scanner app/data, DataWedge settings and existing USB reverses were preserved.

2026-10-31 — Navigation hierarchy and release preparation

Owner explicitly deferred signing/distribution to the final step until the channel is chosen. No signing key or production signing configuration has been created. Continue implementation, audits, native/physical acceptance, documentation and ordinary CI; do not create release tags or force a distribution decision early.

Workstation interruption: user reports whole-desktop pauses whenever the emulator acts and explicitly confirmed the workstation is smooth after closing it. All local emulator/build runs were paused and emulator-5554 shut down gracefully without clearing application data. TC22 remains connected. Sampled host had 48 logical CPUs, CPU17%, about152GiB free RAM of256GiB, GPU10% with6.1GiB/30GiB used; these samples do not rule out brief spikes. WHPX is operational outside the sandbox. The running host-GPU emulator log includes OpenGL context preemption/restore failure and external-memory import errors; graphics interoperability is a hypothesis, not a proven root cause. Saved AVD config now uses software graphics, previous config backed up locally, but no comparison run has been made. Do not restart the emulator automatically. Continue acceptance on TC22/hosted CI or schedule a controlled software-renderer comparison later.

Android checkpoint: primary Apps, an app-switching drawer, separate Account and Settings, host device/location settings and shared leave confirmation are implemented. A bounded build with the emulator closed passed 85 JVM tests (core22/mobile35/scanner28), scanner lint with zero errors/warnings, isolated scanner APK/test APK and shared native-test compilation. The focused native long-form test passed after waiting for actual IME dismissal; the earlier immediate assertion raced its animation. Expanded native navigation cases are compiled but not run. Photo capture/picker, registered Record Files transport, stable retry identity, exact receipts and lifecycle tests are implemented. Subsequent camera auto-upload/destruction cleanup, the public mobile-record-files vocabulary gate and associated tests await the next bounded build after concurrent asset/backend work finishes. No emulator restart is authorized; physical acceptance uses the separate explicit runner in DEVICE-TESTING.md.

The session native test now passes login/approval/catalog/process and recreation, including parent-app metadata and denied-location reporting, against the corrected file-H2 server. It still timed out before the administrator-viewing indicator. The test now waits for explicit screen eligibility and renews the widget viewer lease like the real admin poller; that change is unverified. Actual PixelCopy pixel-boundary instrumentation passed earlier, but full session/mirror/admin-end native acceptance is not complete. Ordinary synchronous process responses have no generic status endpoint: the host retains the process reference, prevents replay and describes uncertainty before explicit cancellation; it does not promise unsupported result checking.

Current plan: finish native navigation/session acceptance; integrate camera/gallery with the actual Record Files runtime; freeze paired revisions for final independent reviews; qualify signed delivery and hosted CI before publication. Apps → app → process is primary navigation. Account/sign-out, Settings and diagnostics are secondary surfaces that preserve active work. Toolbar and Android Back share one guarded leave policy. See NAVIGATION-UX.md; implementation and native acceptance are underway, not yet complete.

Latest intermediate results: Android 76 JVM tests and lint with zero errors/warnings; shared native 11/12, with the remaining form/IME assertion under investigation. Companion server 37 tests, two real HTTP acceptance tests and all 15 browser E2E tests pass. The H2 last-connection close/compaction issue was reproduced and fixed with the demo database lifetime setting; the browser suite now completes in 59.4 seconds. These counts describe their tested intermediate source, not a final release.

Record Files now has actual registered ingestion routes and a frozen 19-file consumer bundle (retained-contract-20261031-0238), all hashes verified by the optional integration owner. Camera/gallery implementation will use its existing storage and durable receipts. Atomic authorization across revocation and upload commit remains a shared contract issue; runtime compatibility and native acceptance are still being qualified.

Release preparation adds optional environment-only signing, validated version properties and a separate scanner-tag workflow that calls the native verification lane before building/signing/publishing. Actionlint passes. The signing identity/secrets, actual signed build/upgrade and final publication have not been configured or verified. See RELEASING.md. Debug/E2E defaults and the operator's installed TC22 application are preserved.

2026-10-30 — Sessions, screen viewing and audit corrections (uncommitted)

The host now requires mobile-scanners >=1.1.0 <2.0.0 and uses registered heartbeat/end/screen operations. Session telemetry contains screen metadata only. Administrator viewing leases enable bounded own-window PixelCopy JPEGs with a visible operator stop control. Capture blocks login/password screens, unrendered transitions, background/unfocused windows and ended sessions; checks repeat after capture and before upload. Foreground location is optional and permission denial leaves scanning usable. Device approval displays the server-generated short name and supports administrator renaming through QQQ.

Audit fixes require complete scanner receipts and reject invalid explicit maxLength. Navigation now follows NavController's actual destination, including system Back and controller replacement. Shared renderer/authentication fixes are being completed by the parallel review agent. Current intermediate verification: 75 JVM tests passed, APK builds passed, lint zero errors/eight warnings before dependency catalog cleanup. Actual PixelCopy instrumentation passed after an emulator startup ANR was resolved by a cold restart preserving data. Shared native suite passed 11 of 12 tests; a new short-viewport login regression found the IME obscuring the button and its fix is awaiting rerun. Both new navigation tests passed. Real-server session/end/viewing scenarios are implemented but await the rebuilt companion server and final native run. These are work-in-progress results, not publication or production acceptance.

At this October 30 checkpoint, Record Files camera/gallery routes were unavailable. The October 31 checkpoint above supersedes that dependency status. Version one remains online only.

2026-10-30 — Semantic API migration in progress

The current work makes the scanner host use the registered semantic UI API contract for every client operation. Public /qqq/v1/version discovery gates credentials, branding and metadata; the supported range is core >=1.8.0 <2.0.0 and mobile-scanners >=1.0.0 <2.0.0, with android advertised in clientChannels. The four mobile extension operations now resolve under /qqq/v1/qbit/mobile-scanners. The native renderer applies server-directed completion, field/step updates, form submission and cancellation, and explicitly blocks unsupported required controls. Review fixes honor hidden fields and explicit null clearing, and keep generic fields named eventId separate from scanner retry context. See UI-API.md for the exact rendering boundary; this is not a claim of full web-client parity.

The final combined JVM suites passed 53 tests: core 21, mobileapp 23 and scanner-host 9. Lint passed with zero errors and six warnings; normal debug and isolated E2E/test APKs assembled. A native administration regression exposed that core QQQ completes a process by omitting nextStep from its COMPLETE response. The renderer now honors that server signal, preserves the final display step until submitted, and closes completed processes without issuing cancellation; a ViewModel regression verifies the full sequence. The companion qbit passed root verification/install with 23 tests and demo HTTP verification; all six migrated browser E2E scenarios passed in 2.9 minutes. The first native run exposed HTTP400 because the server had not registered the Android client channel. The server now registers it while preserving existing channel policies, and the real HTTP regression sends the Android header on all requests and passes. All six native semantic scenarios passed across focused runs: incompatible core major, missing extension, missing Android channel, supported-server scan, additive-future metadata scan, and native administrative approve/revoke/cancel. The first five passed before the terminal-state correction; the final administration scenario passed afterward in 255.917 seconds. Its OpenAPI audit matched all 31 requests to 13 published operations, including backend cancellation. Safe stage markers show both processes reaching completion and Close, then a populated form being cancelled without changing persisted status. The emulator was CPU-bound with animations enabled; the runner now wakes/unlocks only the selected emulator, temporarily disables its animation scales and restores them during cleanup, allows 60 seconds for UI conditions and 300 seconds for instrumentation. The six shared native sample tests also passed. Hosted Android verification remains pending; earlier records below apply to their earlier revisions.

Active plan: publish the Android branch and verify hosted results. The companion server is published at 7dd02b8874882ca2edcdcd89109b3dee6b4b0c88 with all server CI checks green, and the Android workflow pins that revision. The six shared native sample instrumentation tests passed on API35. The local server and emulator restarted after the workstation crash with data preserved.

Physical acceptance now includes the Zebra TC22 on Android 14 with DataWedge 13.0.325. The latest normal APK was installed with login/enrollment preserved; browser record approval displayed one device approved. The native catalog and Scan Capture opened with Connected status. The DataWedge profile associates all scanner-app activities, enables barcode input, disables keystroke output, and sends the SCAN action/default category as a broadcast to the explicit package with signature checking enabled. The user performed two deliberate physical triggers and saw Saved scan. The matching persisted Code128 row was independently inspected in the backend: synthetic barcode QQQ-TEST-123456, symbology LABEL-TYPE-CODE128, source scanner, user scanner, TC22/Android14/app0.1.0, mobileScanApp/mobileScanCapture, and capture/receipt timestamps. The two deliberate Code128 triggers produced two records, one event per trigger. A subsequent physical QR scan also displayed Saved scan; the independently inspected row preserved the leading-zero barcode 001234567890, symbology LABEL-TYPE-QRCODE, scanner source and the same TC22/user/app/process attribution with capture/receipt timestamps. The table contained exactly three records for two Code128 triggers and one QR trigger. Connection-loss/retry and revoked-device behavior still need physical-device acceptance; emulator checks do not replace those cases.

Earlier verification records

2026-10-30 process E2E follow-up: added a real scanner-host Compose instrumentation scenario against a fresh QQQ demo database. It drives server selection and login, confirms pending enrollment, approves through the real admin process, selects the native app/process, submits a leading-zero manual barcode, waits for the actual saved-scan acknowledgment, independently queries durable provenance, and verifies a revoked device cannot save through its already-open process. The final scenario passed on API35 (one end-to-end test, 50.932 seconds), including completion of administrative result screens. It uses the separate io.qrun.mobile.scanner.e2e application; the operator's app, accounts, data and existing forwarding are preserved. Random test credentials are passed through stdin to private app storage and redacted from reports. The runner removes both test APKs and cleans up its temporary server/database and dedicated forwarding; only the normal scanner package remained installed after verification. Added a pinned companion-server checkout and this E2E to the push/PR emulator lane; hosted execution remains unverified until publication. Final required Gradle verification passed: 28 JVM tests, lint zero errors/six existing warnings, normal debug APK and isolated E2E/test APKs assembled. Actionlint, Node syntax validation and diff whitespace checks passed.

2026-10-30 follow-up: the scanner could show a blocking “No Network Connection” dialog while its server footer correctly said Connected. The shared legacy callback used one Boolean for multiple networks; losing either network incorrectly marked all connectivity unavailable. It now tracks network handles, with two regression tests that fail against the old logic. Scanner hosts opt out of the legacy internet-presence modal and use the existing server reachability footer; server authentication and device approval are unchanged. All 28 JVM tests and six native API35 instrumentation tests passed, lint has zero errors/six warnings, and the replacement APK was installed without clearing app data. Scanner activity and its existing session were restored after tests.

The local AVD is configured for host NVIDIA graphics (hw.gpu.enabled=yes, hw.gpu.mode=host), with the previous config backed up under the user's cache. Reopening with -gpu host -no-snapshot and restoring adb reverse showed Home frame percentiles of 16/17/18 ms (50th/90th/99th) and scanner 19/22/48 ms. These are post-restart observations, not a controlled before/after benchmark; the original slow process had already exited. The actual previous renderer had used the GPU despite the saved AVD setting, so disabled GPU is not established as the root cause. The admin browser is open at the demo login on port57832.

2026-10-29 verification: all 26 JVM tests passed, lint reported zero errors/six warnings, and the debug APK assembled successfully. Runtime diagnostics now include sanitized native API and device-request outcomes, in addition to branding and heartbeat events. Android 15 system-bar insets were corrected after emulator inspection. The shared mobile library now declares its connectivity permission for all consumers. Login copy uses a neutral title beneath the customer branding. CI APK artifacts include their own SHA256SUMS; local builds can be hashed with Get-FileHash.

Repository implementation is published for review in PR #8; it has not been merged or released. The branding/diagnostics commit a5621c5 passed all hosted CircleCI, scanner build and CodeQL checks. The optional manually dispatched hosted emulator lane was skipped; local native emulator tests passed. The companion qbit is published at https://github.com/QRun-IO/qbit-mobile-scanners, with all hosted server/CodeQL/demo checks passing and protected branches/security settings enabled.

Final-APK acceptance passed: six native UI tests, safe Android 15 header insets, customer branding, neutral login text, diagnostic panel and Connected → Disconnected → Connected recovery. APK SHA256: A25451EA7A1360474428F1B806134DDFD059190FB99E81B4F69E720808C3209C. The visible API35 emulator is left at login with http://127.0.0.1:8080/ forwarded to host demo port57832. No credentials were entered or scans submitted through the emulator; the full operator/approval/capture walkthrough and physical TC22 remain pending. The server HTTP acceptance suite separately verifies the complete authorization/capture flow.

Earlier implementation records follow; the publication and emulator statements above supersede their original pending status.

Runtime branding and diagnostics added: public server metadata supplies display name, primary color, and an optional HTTPS logo; malformed/missing metadata uses QQQ defaults and server changes reset presentation. A persistent foreground connection footer checks the public status endpoint, with bounded credential-free diagnostics Copy/Clear. Shared top-bar colors now use the matching Material foreground role and its connectivity callback is disposed correctly. Branding/status protocol, isolation, malformed input, response redaction, and log bounds have JVM regression tests. Validation passed: full 23 JVM tests (core12, mobileapp4, scanner7), debug APK assembly, and lint with zero errors / six warnings. The new APK SHA256 is F388AF488688DE87811FE32C94D07601DC3DD61ADAC139069ADCFA627E21D01C. Updated emulator UI acceptance is pending.

Follow-up: diagnostics now also collect fixed native QQQ/device request outcomes through an optional, exception-isolated observer (status and latency only). Added regression cases for HTTP errors, transport failure, observer exceptions, and category formatting. Emulator confirmed F388 branding/login/Connected footer/diagnostics; observed Android15 system-bar overlap corrected with safe-drawing insets. Final verification for these follow-ups is pending.

2026-10-29: Implementing QQQ Mobile scanner host and native host extensions. First target is Zebra TC22, online only. Backend companion is qbit-mobile-scanners; metadata-defined apps/processes remain the native execution model. Device approval is mandatory. Local demo uses QQQ TABLE_BASED auth on QQQ4.1.0-RC.20.

Implemented server selection, per-server enrollment credentials, approval gate, SCANNER widget DataWedge input, explicit same-event retry, native password login, host extension points, and removal of session/token logging from touched authentication paths. No commit or push.

Validation passed: 19 JVM tests (core12, mobileapp4, scanner3), debug APK assembly, APK signature verification, and lint with zero errors. Five lint warnings remain: three inherited Navigation custom-check compatibility warnings and two dependency/catalog notices. Real sanitized demo HTTP metadata/process/init fixtures deserialize through the native DTOs. Server logout, HttpOnly-cookie login, and per-origin header isolation have regression tests. Physical TC22 acceptance remains required.

Previous pre-branding debug APK SHA256: B3E160CE3279C369CEDB425AC6E777A2729CE8A2E430E7D6F46D35C6376F8214.

Repository readiness added: pinned GitHub scanner tests/lint/APK artifacts and optional emulator workflow; CODEOWNERS, contribution/security/conduct guidance, issue/PR templates, Dependabot, changelog, editor/line-ending policy, and scoped agent instructions. actionlint, shellcheck, shfmt, and git diff --check passed. Upstream main 63fca89 was fast-forwarded and all implementation files restored without conflicts; the managed CircleCI Android profile and QRun-IO Maven registry updates are preserved. The full Gradle verification command passed again after reconciliation (16 executed tasks, remaining unchanged tasks up to date). Remote CI and emulator acceptance have not yet been recorded here.