Phonecapture
Phonecapture is 1Context’s dedicated Android appliance path for recording another phone through HDMI capture. It uses a stock-ROM Jelly Star, a UGREEN/MacroSilicon USB-C UVC capture dongle, and userspace UVC rather than Android Camera2, which did not expose the capture card. Its current state is a working but still failure-oriented appliance: it records retained MP4 clips, exposes status, recovers from idle and USB faults where possible, and now records enough lifecycle evidence to explain the next bad field failure.
Origin
Phonecapture appeared on March 25, 2026, beside the first cloud-backed Guardian work. The pressure was practical: 1Context needed a cheap, controllable way to observe phone behavior as evidence, not as a narrated report. The early choice was important. Instead of chasing a custom ROM or Camera2 integration, the path settled on stock Android plus userspace UVC on the Jelly Star.
The first proof was deliberately ordinary: H.264 MP4 clips at 1280x720, 10 fps, status files, color-bar/no-signal classification, wake and deep-idle behavior, and import tooling that preserved capture timestamps. That established the basic product claim: the appliance could keep physical capture artifacts, name common failure states, and move the files back to a Mac with their chronology intact.
Role in 1Context
Phonecapture belongs to the capture layer of 1Context, alongside Puter for Mac activity and Littleguy for wearable-camera research. Its job is narrower than either: record the output of another phone through HDMI/UVC and leave inspectable evidence about what it saw and how the recorder itself behaved.
The appliance produces retained video clips, status JSON, and lifecycle breadcrumbs. It consumes the HDMI/UVC signal from the capture dongle and the Android device’s own battery, charging, boot, package, and USB state. Downstream, the Mac importer became Fone, which turned the raw appliance output into something a desktop user could discover over LAN and import without relying on ADB.
This role matters because 1Context’s memory model is evidence-first. A phone demo, app failure, or UI state should not depend only on human recollection or screenshots. Phonecapture gives the project a second device that can witness a phone from the outside, then explain when the witness itself lost signal, went idle, rebooted, or lost its capture card.
History
On March 28, the phonecapture importer had a classic pipe failure: it waited for a child process to exit before draining stdout. The fix moved to adb exec-out tar streaming rather than per-file pulls, removing the deadlock. A real import folder reached 304 files and 361M; a follow-up found new files: 0. Commit 8f51264, Harden importer and cut 0.1.2 release, froze that stage. The same work clarified that the reliability enemy was native UVC recovery from result=-99, not steady-state capture.
On March 29, phonecapture became more appliance-like. The Jelly Star app stopped exaggerating wake states, shortened recording warmup, recorded actual MP4 container duration, and exposed a local HTTP transfer server on port 28781. The Mac menubar importer moved away from ADB dependence, gained LAN discovery, a Haptica icon, persistent destination settings, and a signed/notarized 0.1.6 release. A clean second Mac user imported 418 files into Downloads without preseeded config or ADB.
On March 30, the repo became a monorepo. The Jelly Star capture gap from 4pm to 11pm was traced to USB permission and idle recovery behavior. UvcCaptureService.java was patched so no-signal, sleep, and soft-idle states stayed warm instead of collapsing into stale permission limbo. A five-minute sleep test passed with wake-to-live around 1.47s. The Mac importer was renamed Fone and released as import-menubar-v0.1.8-alpha1; older standalone repos were archived or deleted after the monorepo took over.
On April 2, the work turned from recording to self-witnessing. Paul asked whether the kiosk could explain a field behavior where the Jelly Star sometimes shut down and did not fully return from power presses unless plugged in. There was no live device to inspect, so the answer had to come from code. The app had no explicit “only restart when charging” rule. It held a partial wake lock, kept a sticky foreground UvcCaptureService, and used DevicePolicyManager.reboot() after the dongle disappeared following a healthy capture session. Before this work, that reboot path had no charging-state guard.
The fix made future failures legible rather than claiming the cause was proven. ApplianceLifecycleStore.java began storing broadcast, service-kick, service-lifecycle, and auto-reboot breadcrumbs in device-protected preferences. BootCompletedReceiver.java began listening for boot, MY_PACKAGE_REPLACED, charger attach and detach, BATTERY_LOW, BATTERY_OKAY, and shutdown. MainActivity.java and UvcCaptureService.java exposed recent lifecycle events plus battery and charging state through status.json and uvc-status.json. The kiosk build passed with ./gradlew :app:assembleDebug.
Current State
As of the April 24 life story, Phonecapture is the dedicated Android appliance path. It records through a MacroSilicon UVC capture card on a Jelly Star, names states such as no_signal_colorbars, stale_static, live, and device_missing, and tries to recover from idle and USB failures. Its Mac-side importer is Fone, with LAN discovery and signed releases.
The most recent lesson is that the recorder must explain its own gaps. Phonecapture now stores lifecycle breadcrumbs, battery and charging state, boot and package-replacement events, and reboot decision context in device-protected preferences and status JSON.
Open Questions
The immediate unresolved question is recovery policy: automatic recovery reboot should likely be gated on charging state or a battery floor, then validated against status files after a real Jelly Star failure. The larger question is whether the Jelly Star remains a near-term appliance proof or gives way to custom hardware once battery, radio, USB permission, and capture behavior need tighter control.