james.maesandClaude Sonnet 5.5
f72b90d08c
Add scan value and symbology feedback, optional status wallpaper and managed server/orientation configuration, proven AIM profile readback, and administrator-controlled viewing UI. Extend native Echo acceptance for per-scan copies and add an opt-in real-provider Authentik harness isolated to the disposable test package. Verified: 222 JVM tests, lint with zero errors/warnings, debug/E2E/test APK builds, 23 Node tests and source standards. Updated TC22 Echo acceptance passes ten stages with simulated input/printing. Actual Authentik desktop acceptance passes; native Authentik and physical trigger/print validation remain pending. Normal TC22 updated with the matching signer and data preserved. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
4.0 KiB
Optional whole-device screen viewing
Status: accepted implementation scope; validation pending.
The existing mobile-scanners 1.1 transport captures only eligible QQQ app content. Its foreground/focus checks and PixelCopy implementation remain the default. Whole-device viewing needs an explicit semantic mode because the old server deliberately rejects background capture and its schemas prohibit other-app/OS pixels.
The additive 1.2 contract advertises supported capture modes in the session heartbeat. Missing capabilities and missing mode fields mean APP_CONTENT. DEVICE_SCREEN is selected only by an authenticated, approved device operator using Android's own consent dialog. An administrator cannot grant that consent. The existing admin-only viewer and current device/session authorization remain mandatory; a mode change invalidates old leases and pixels. Each new lease and frame carries its mode, preventing a full-display frame from being accepted as app-content capture. The session record exposes the current mode to the administrator.
Android uses a nonexported mediaProjection foreground service, an ongoing informational notification, one in-memory consent result, one virtual display and a bounded ImageReader. No audio, remote control, screen recording or saved screenshots are added. Frame size/rate/byte limits and ephemeral latest-only server retention stay unchanged. A single MobileSessionController owns heartbeats/uploads; device mode changes its capture source and allows background heartbeats while consent and the current authenticated session remain valid. Location telemetry retains its existing foreground-only rules.
Starting requires an explicit operator action and system approval for this sharing session, plus an enabled sharing notification. While waiting for an administrator's bounded lease, no frame is uploaded; absence of a lease times out after 30 seconds. Once viewing has begun, lease loss/expiry, network failure, system Stop, device lock, approval loss, logout, server change or controller disposal invalidates capture immediately and releases projection/display/images/service. A service watchdog independently enforces the lease deadline even during encoding or an outstanding request. There is no automatic restart or remembered consent. Activity recreation may end sharing and require fresh consent; it must never silently broaden or revive a grant. System Stop suspends viewing until a fresh sharing grant is started. The app has no Stop viewing, Allow viewing, or custom notification stop action. Android system consent and stop controls remain available.
Implementation files: Android SessionScreen/MobileSessionApi/MobileSessionController, new DeviceScreenCaptureService and operator control, ScannerActivity wiring and manifest; server MobileSessionService/MobileScreenService/MobileSessionSchemas/ScreenSpec, session metadata/H2 additive migration and extension version. Existing standard rendering and authenticated session APIs are reused; no parallel media server or business-screen framework is added.
Required tests cover old1.1 fallback, mode mismatch/lease rotation, revoked/ended sessions, bounded no-viewer timeout, late consent/capture after logout, denial/cancel/duplicate result, stale frame disposal, system Stop. Actual Android consent, background display capture, rotation/lock and protected-window behavior require a separate approved native test; synthetic tests do not establish physical capture acceptance.
Android's official MediaProjection guide requires new consent for each projection session, one-use projection tokens and callback cleanup. Android14+ requires the mediaProjection foreground-service type/permission and supports display or app selection. The device-screen control requests the default display where supported and keeps the system confirmation visible. Protected windows remain protected by Android; we do not attempt to bypass them. A consenting user may expose other apps and notifications, which the control must explain before starting.