# ADR 015: Old phones as a physical device lab and cellular watchdog - HTML version: https://robbiepalmer.me/projects/homelab/adrs/015-phone-device-lab - Project: Home Lab (https://robbiepalmer.me/projects/homelab.md) - Status: Proposed - Date: 2026-08-22 # Context I have three working phones that no longer have a daily job: * An Honor View 20 running Android 10. * An Honor Magic5 Pro running a newer Android release. * An iPhone 6s running iOS 15. The lab already has better server hardware. The Mac mini runs persistent applications, and the Raspberry Pi provides an independent DNS and printing node. A phone would be worse at either job. Android background limits, ageing batteries, and awkward service management would add failure modes without removing any existing ones. The phones have something the servers do not: real mobile browsers, touch input, batteries, sensors, and mobile radios. Those capabilities fit two problems already present in the lab. First, the Mac mini hosts coding agents that work on web applications. Preview testing now happens in desktop browsers and emulators. Real Android and iOS hardware would let an agent reproduce mobile browser bugs, record the result, and test a pull request on the devices people actually hold. Second, [Netdata](/projects/homelab/adrs/009-netdata) shares fate with the network it monitors. If both AdGuard Home resolvers fail, or the home loses power or internet access, Netdata may be unable to deliver the alert. A phone using mobile data can observe the lab from outside that failure. Requirements: 1. Agents can run repeatable browser checks and collect screenshots from each phone without someone tapping through the test by hand. 2. The setup stays private. Test devices must not expose debugging ports to the LAN or gain broad access to the tailnet. 3. A watchdog must use a network path independent of the home LAN and its DNS. 4. The phones must not become another source of irreplaceable data or credentials. 5. Battery wear and heat must be visible rather than hidden behind a permanent charger. # Decision, proposed Build a small physical device lab attached to the Mac mini. Keep all three phones on their stock operating systems. ## Mobile browser testing Connect the phones to a powered USB hub on the Mac mini. USB is the default because it supplies power, avoids opening wireless debugging ports, and keeps device discovery predictable. * Use ADB, Chrome remote debugging, and `scrcpy` to control the Honor phones. Add Appium only when a test needs touch automation that ADB and browser tools cannot express cleanly. * Use Safari Web Inspector for the iPhone 6s. Add Appium's XCUITest driver when repeatable Safari interaction is worth the extra signing and provisioning work. * Run checks through mise tasks on the Mac mini. The first useful tasks are `mise //:phones:status`, `mise //:phones:android:smoke`, `mise //:phones:ios:smoke`, and `mise //:phones:screenshot`. * Keep tests small. Open the preview, exercise the changed path, record the viewport and OS version, save a screenshot, and return a clear pass or failure to the agent. The three devices cover different failure modes. The View 20 catches old Android and WebView behaviour. The Magic5 Pro covers a newer Android browser on fast hardware. The iPhone 6s preserves an iOS 15 Safari target that a modern iPhone no longer represents. ## Cellular watchdog Give the View 20 a second job after the device-lab pilot works. Install a cheap data SIM, keep Wi-Fi disabled for watchdog checks, and join it to Tailscale. Termux, Termux:API, and Termux:Boot will run a small check loop that: * Queries each AdGuard Home instance directly by its fixed Tailscale IP. * Checks explicit health endpoints on the Mac mini and Raspberry Pi. * Distinguishes one failed service from loss of the whole home connection. * Sends an alert over mobile data using a credential that can do nothing else. * Reports its own battery level, temperature, last successful run, and current network type. The watchdog gets a tagged Tailscale identity. Tailnet policy will allow that tag to reach only DNS and named health-check ports. It will not inherit the broader trust granted to personal devices. The View 20 also has an infrared transmitter. Termux:API can expose a few named, tailnet-only commands for the television or other IR appliances. This is optional and does not justify the deployment by itself. ## Power and physical care Keep the vendor's battery-protection settings enabled where available. The device status task should report battery temperature and charging state. A smart plug or controllable USB port can cycle charging instead of holding every phone at 100 percent. Any swollen, damaged, or persistently hot battery retires the device immediately. # Operating-system choice Do not base the project on replacing the operating systems. Huawei [stopped providing bootloader unlock codes](https://www.phonearena.com/news/huawei-honor-bootloader-unlock-discontinued_id105187) for Huawei and Honor devices released after May 2018. Honor [launched the View 20 in December 2018](https://www.honor.com/global/blog/honor-launches-new-honor-view20-in-china/), so it missed the official unlock window. The Magic5 Pro has no documented official unlock path either. Neither phone appears in the supported-device lists for [Ubuntu Touch](https://devices.ubuntu-touch.io/) or [/e/OS](https://doc.e.foundation/devices). The iPhone 6s can boot experimental Linux through the checkm8-based [Hoolock Linux](https://github.com/HoolockLinux) work. Hoolock states that its ports are not ready for the devices' normal uses. That makes it a good weekend experiment and a bad foundation for monitoring or testing. Stock software also preserves the browser versions that make the phones useful as test targets. A custom ROM would replace the old platform the device lab is meant to cover. # Alternatives ## Run DNS on a phone * **Pros.** Another physical resolver could survive a Mac mini or Pi reboot. * **Cons.** A normal Android application cannot provide a dependable LAN DNS service on port 53 without privileges. Background process limits and the locked bootloaders make reliability worse. The lab already has two proper resolvers on separate machines. * **Decision.** Rejected. Use the phone to check DNS, not to serve it. ## Use a phone as a permanent camera * **Pros.** Reuses the camera, screen, battery, and Wi-Fi radio in one device. * **Cons.** A permanently charging phone is awkward to mount and monitor. For recipe or document datasets, my normal phone is already in my hand and has the better capture workflow. A dedicated camera would be more reliable for continuous monitoring. * **Decision.** Rejected. The camera does not solve a problem I have. ## Use the phones as compute workers * **Pros.** The Magic5 Pro has a fast mobile processor and plenty of memory. * **Cons.** Thermal throttling, Android process management, and device-specific acceleration make jobs hard to reproduce. The proposed 1060 and 4080 workers have better cooling, storage, and software control. * **Decision.** Rejected. Use phone hardware for phone testing. ## Use a phone only as a status display * **Pros.** Easy to set up and pleasant to glance at. * **Cons.** A display does not justify keeping a battery-powered computer awake all day. Any of the test devices can show a dashboard when it is otherwise idle. * **Decision.** Keep as a secondary use, not a workload of its own. # Pilot acceptance criteria Keep this ADR Proposed until the lab can demonstrate all of the following: * The Mac mini detects every connected phone and records its model, OS version, connection state, and battery state. * An agent opens a protected pull-request preview on both Honor phones, runs a small browser test, and returns screenshots without manual interaction. * Safari on the iPhone 6s opens the same preview and yields a screenshot or an inspectable WebKit session. Full iOS automation is optional for the pilot. * Test artifacts include enough device metadata to reproduce a failure. * Protected previews use a preview-only test identity and short-lived access. Personal accounts and persistent preview tokens never go on a lab phone. * Every test run clears its browser storage and authenticated session before returning the phone to the device pool. * Debugging access is limited to the Mac mini, and Tailscale policy gives lab phones no general access to private services. * If the cellular watchdog is built, a deliberate failure of each resolver and a simulated total LAN outage both produce the expected alert over mobile data. # Consequences ### Pros * Pull requests gain coverage on three real mobile platforms already sitting unused. * Coding agents can gather mobile evidence instead of asking me to reproduce every problem by hand. * The cellular watchdog closes a monitoring gap that another LAN service cannot close. * Each phone keeps the stock browser behaviour that makes it a useful test target. ### Cons * USB device state, Android authorization, Apple signing, and browser tooling all need occasional repair. * The iPhone path is less automatable than Android and may remain a manual smoke test. * An old Android phone on the tailnet adds risk even with narrow access rules. * Batteries need active care. These devices cannot disappear behind a cabinet and stay plugged in forever. --- Markdown index of this site: https://robbiepalmer.me/llms.txt