mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
f5ce88c93f
Three attempts inside one hour, then a day of silence, was calibrated for the wrong cost. The ~8.7MB re-download that throttle exists to prevent is already prevented by the APK cache — downloadAndInstall reuses a previously verified file, so attempts 2..N pull no bytes. What actually blocks these installs is a confirm dialog waiting for somebody to walk past, and giving up an hour in guarantees nobody has. The cap is now 40, roughly a working day at the 30-minute cadence, before falling back to the existing daily retry. Two things had to come with it, because raising the number alone would have made things worse: Telling the operator is now a SEPARATE threshold from giving up. It used to fire at the cap, so a bare bump would have pushed "this panel needs attention" from about an hour out to about twenty. It fires at ATTEMPTS_BEFORE_FLAGGING (3) instead, and statusFor keys on the same threshold, so a device reports manual_update_required as soon as a human is demonstrably needed and KEEPS reporting it while it retries. Previously the status dropped back to 'pending' once the backoff window elapsed, so a panel that needed hands looked healthy in between attempts. PackageInstaller sessions are now abandoned before a new one is opened. Every attempt stages a full copy of the APK via openWrite, and a session whose dialog is never accepted holds onto it. At three that was a rounding error; at forty it would be ~350MB of staged installs on hardware without it to spare, and would eventually trip the per-app session limit. The warning text no longer promises a 24h backoff it is not about to take, and says what would actually fix it — accept the prompt, or have the MDM delegate install permission. The three tests that broke encoded the old thresholds and were rewritten to the new intent rather than retuned to pass. |
||
|---|---|---|
| .. | ||
| main | ||
| test/java/com/remotedisplay/player | ||