2 commits

Author	SHA1	Message	Date
ScreenTinker	3333d5e968	Stop Android panels losing controls when they update ... A declared capability set REPLACES the per-platform baseline rather than merging with it, so anything the baseline grants and the player omits is a control the operator loses by updating. Three were being lost. - display.brightness: the per-window dim (setWindowBrightness) is Tier 0 — no permission, no owner, no WRITE_SETTINGS — and MainActivity applies it unconditionally. It was simply never declared. - remote.screenshot / remote.stream: gated on the accessibility service, while captureScreen() falls through to ScreenshotCapture.captureView, a plain view draw with no permission check. A Tier-0 panel lost live view and screenshots by updating, and a GRANTED MediaProjection never became a capability either — consent given, capture working, server still refusing, because nothing re-declared. - system.device_owner: no player declared it, so the server accepted system.kiosk as a stand-in for every Tier-2 command. Declaring the canonical name makes refusals say what they mean; the stand-in can retire one release after this reaches displays. display.power stays conditional on purpose: screen_on works anywhere via a wake lock but screen_off needs owner/admin/accessibility, and a control that sleeps a panel it cannot wake is worse than no control. It is the sole entry in the DELIBERATE set in player-parity-baselines.test.js. Also fixes the capture-bootstrap gate in device-detail.js. It hung off can('remote.screenshot'), which hid the button from exactly the panels that need it. The gate is now Android-and-nothing-else, NOT "Android that lacks capture": /api/devices/:id ships capabilitiesFor(), which flattens declared and baseline into one array, and the android baseline contains remote.screenshot — so a "lacks capture" test hides the button from all ~440 undeclared panels in the field. isAndroidDevice() mirrors platformFamily() with all four signals in order; an Android-test-only helper classified every Tizen TV as Android, since Tizen registers android_version 'Tizen 6.5'. Tests: the suite could not see any of this. Mutation testing showed deleting either capability line, or reverting isAndroidDevice to its buggy form, left all tests green. Added an update-invariant test (declared set vs baseline, with an argued exception list), a test that executes the shipped helper rather than the harness stub, and a legacy-panel test using the shape the API actually returns instead of one it never produces. All four mutations now fail. Verified on a real Android 16 device across all three tiers: Tier 0 captures live video (no accessibility, no MediaProjection, no owner), Tier 1 gains display.power via accessibility, Tier 2 declares system.device_owner and every Tier-2 command delivers. An in-place upgrade from the pre-change build lost nothing and gained exactly these three. Baselines deliberately NOT moved — a baseline entry moves in the release AFTER the one carrying the player fix, once it has reached displays. Parity gaps 3 and 4 were implemented, audited and reverted; docs/player-parity.md records why so the next attempt starts from the traps. Gap 3 (wiring "Force update") meets an unbounded synchronous download against a 120s watchdog and a 3-attempt counter with no version binding, so three presses refuse a panel every future version. Gap 4 (deferring to BS.capabilities()) removes working screenshot/stream from diskless BrightSigns that capture to RAM, over-declares transitions, and rides a probe timeout that discards a late answer permanently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 10:31:33 -05:00
ScreenTinker	0082191f9b	Show only the controls a display can actually honour ... Every device control was offered to every display. A browser tab was shown "Reboot device", a Tizen TV was shown screen power, a player with no framebuffer read was shown a live view that stayed black. They all looked like working buttons and did nothing — the "reports success and changes nothing" shape that keeps costing people days. Players now declare what they can do at registration, because only the player knows at runtime: an Android panel gains real screenshots when accessibility is switched on and loses Tier-2 when device owner is revoked. The dashboard hides what is not supported rather than disabling it, and the Info tab lists the capability set so a missing control is explainable. The declaration is three-state and the middle state is load bearing: NULL means "has never told us anything" and falls back to a per-platform baseline, because several hundred displays in the field will not update before this deploys and blanking their controls would be a far worse bug. An empty array means "I genuinely can do nothing" and is honoured. Hiding a button is not enforcement, so unsupported commands are also refused server-side — the socket is reachable directly and a stale tab still renders the old controls. Group sends report skipped devices separately from sent ones; counting an unreachable member as "sent" is how an operator walks away believing the whole group rebooted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 14:24:52 -05:00