OEM background-execution survival testing (Samsung, Xiaomi, etc.)

[jsconu]

Split out from #1. Aggressive battery-optimization / background-app-killing on several major Android OEMs is a well-known way for exactly this kind of app (foreground service + accessibility service that need to keep running indefinitely) to silently stop working, hours or days after it looked fine in testing. No device-optimization-specific testing has been done at all yet.

What to check, per manufacturer (at minimum Samsung and Xiaomi, ideally also OnePlus/Oppo/Huawei if available)

• Does ScreenMonitorService (the foreground service) survive being backgrounded for several hours without the OS killing it?
• Does the AppLimitAccessibilityService stay enabled, or does the OEM's battery manager silently revoke/disable it?
• Does BootReceiver correctly restart tracking after a device reboot on these OEMs specifically (some restrict RECEIVE_BOOT_COMPLETED more aggressively)?
• Does the app need OEM-specific guidance surfaced in its UI (e.g. "also disable battery optimization for this app" with a deep link to the right settings screen, the way several other Android parental-control / call-blocking apps do) to work reliably on these devices? If so, that's a follow-up feature, not just a test finding.
• Document findings per-OEM in the README or a new docs/oem-notes.md so future contributors don't have to rediscover the same quirks.

This is inherently a "needs real hardware from that manufacturer, over a real multi-hour/day period" task - not something a quick emulator check can substitute for.