Watchdog fails to recover when manager restarts after Shizuku server disappears

Environment

• Shizuku 13.7.0-thedjchi, Android 14, Xiaomi HyperOS 2.0.3.0, MediaTek device
• Unrooted, ADB startup with a TCP listener available

Observed

The Shizuku manager process is repeatedly terminated by the OEM, with historical Android ApplicationExitInfo reasons LOW_MEMORY (multiple events) and OTHER KILLS BY SYSTEM / SwipeUpClean (two events). The watchdog foreground service can subsequently be restarted, but Shizuku is not reliably brought back online without opening the manager and starting the server manually.

The exit-info records refer to the manager process, not necessarily the separate shizuku_server process; I am not attributing all daemon deaths to the OEM based on those records alone.

Source-level recovery gap

• ShizukuStateMachine initializes in STOPPED and emits CRASHED only on a RUNNING -> binder dead transition.
• WatchdogService only schedules server recovery when it observes CRASHED. If the manager is recreated after the server is already absent, there is no transition to trigger recovery.
• WatchdogService.onDestroy() disables the persisted watchdog preference, even when destruction wasn't requested by the user.

Expected

A watchdog-enabled manager should detect an absent server on startup and after missed binder-death events, schedule recovery with bounded retries, and preserve its enabled preference across normal lifecycle destruction. User-requested stops should still be respected.

A proposed fix is being prepared in a PR to this repository, with unit tests and a GitHub Actions APK build.