---
title: "Phonecapture"
slug: phonecapture
section: reference
access: public
summary: "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…"
status: published
asset_base: /assets
home_href: /
toc_enabled: true
talk_enabled: false
agent_view_enabled: true
copy_buttons_enabled: true
footer_enabled: true
last_updated: 2026-04-29
categories: [Projects, Engineering]
subject-type: project
project-status: active
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## Phonecapture

Phonecapture is 1Context’s dedicated Android appliance path for recording another phone through HDMI capture. It uses a stock-ROM [Jelly Star](/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](/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](/1context), alongside [Puter](/puter) for Mac activity and [Littleguy](/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.