mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 14:23:14 -06:00
A panel on prod looped on an update it could never apply, reporting a download failure that was not one. The staged-APK cache is keyed by FILENAME, and the filename is built from the version the SERVER advertised. Prod advertised 1.9.34 while still serving the 1.9.33 file, so the panel saved 1.9.33 as `ScreenTinker-1.9.34.apk`. On every retry it found that file, verified the signature — which passed, same key — reused it, and installed a no-op. The version never changed, so the update was offered again. Fixing the server did not help: the poisoned file is reused before anything is fetched. It took `adb rm` to break the loop. Two changes: CHECK THE VERSION INSIDE. A cached APK is reused only when the versionName in the file matches the version being installed, and a fresh download is checked the same way before install. A server serving stale bytes now fails with what actually happened — "server served 1.9.33 but advertised 1.9.34 — the update on the server is stale" — instead of a download error, and the bad file is deleted rather than kept to poison the next attempt. That makes this class self-healing: the panel recovers on its own once the server is fixed. A WAY TO CLEAR IT. `clear_update_cache` deletes every staged APK across all three staging directories, with a button on the device page next to Force Update. Gated on `system.self_update` — a player that can update itself is one that can hold a bad download. Only caches are deleted; they are re-fetched on demand. The version check should make the button rarely necessary. It exists because it would have turned tonight's hands-on ADB recovery into one click, and because a panel already holding a bad file predates the fix and cannot benefit from it. 1668/1668 pass; Android unit tests and lint clean. |
||
|---|---|---|
| .. | ||
| app | ||
| gradle/wrapper | ||
| build.gradle.kts | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| settings.gradle.kts | ||