fix(android): declare WAKE_LOCK — the stream's Wi-Fi locks never actually engaged

WifiLock.acquire() enforces the WAKE_LOCK permission, which the manifest never declared — every acquisition since the first Wi-Fi lock shipped threw SecurityException, silently swallowed by a bare runCatching. The phone's own accounting proved it (dumpsys wifi: high_perf/low_latency active_time_ms = 0 across weeks of streams): every on-device session ran with Wi-Fi power save fully active, whatever the code intended. Verified live after the fix: both locks registered in WifiLockManager, mPowerSaveDisableRequests=2, ping RTT to the streaming phone 3.8 ms avg. A failed acquire now logs loudly — this class of failure must never be invisible again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-07 08:07:42 +02:00
parent b271d0c816
commit 08ab2b6bee
2 changed files with 16 additions and 3 deletions
@@ -13,6 +13,12 @@
         reception needs it (also an OEM Wi-Fi power-save hedge). -->
    <uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
+    <!-- WifiLock.acquire() ENFORCES this (a normal permission, granted at install). Without it the
+         stream's Wi-Fi locks throw SecurityException and power save stays on: downlink delivery
+         clumps at beacon intervals — hundreds of ms of latency mush + periodic whole-frame loss.
+         Its absence went unnoticed for weeks because the acquire was wrapped in a silent
+         runCatching (now logged). -->
+    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <!-- Enforced from Android 17 (SDK 37) for ALL local-network traffic incl. the QUIC socket.
         Harmless to declare on earlier releases. -->
    <uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />