Jelly Star
The Jelly Star is the small Unihertz Android phone used as the near-term capture appliance for phonecapture. Inside 1Context, it represents the practical phone-as-recorder path: stock ROM, userspace UVC, retained clips, status files, and recovery behavior that can be inspected after failures. As of the most recent relevant entries, it is still in appliance development rather than a finished hardware product, but it has crossed from research plan into real kiosk builds, imports, and field failure instrumentation.
Origin
The Jelly Star entered the project on March 25, 2026, when phonecapture needed a dedicated Android device that could record HDMI capture input without becoming a normal phone UX. The first question was whether to flash a full custom ROM or begin with a kiosk app on stock Android. Research and device constraints pushed the project toward the stock-ROM route: Android dedicated-device APIs, lock task mode, adb workflows from macOS, and a kiosk app that could be made hard to misuse without owning the whole operating system.
The pressure came from capture reliability. Guardian and the broader memory work needed evidence from physical devices, not just desktop and cloud traces. A Jelly Star plus UGREEN/MacroSilicon USB-C capture dongle became the cheapest credible appliance proof before custom hardware. That decision also rejected two tempting shortcuts: Camera2 wishful thinking and early custom-ROM work.
Role in 1Context
The Jelly Star sits at the hardware edge of phonecapture. It consumes HDMI capture through a MacroSilicon UVC card and records retained H.264 MP4 clips, with status sidecars that describe what the appliance believed it was seeing. Those files then move to the Mac through importer tooling, first through ADB-oriented paths and then through LAN discovery in Fone.
Its role is different from Puter. Puter records the Mac itself: screen, audio, OCR or vision-derived observations, and UI events. The Jelly Star records another phone or external device through HDMI capture. Together they show why 1Context treats capture as plural. There is no single recorder that covers every memory source cleanly.
History
On March 25, the Jelly Star plan became concrete. The repository gained docs/jelly-star-kiosk-plan.md, with the stock kiosk-first decision, Android development setup, device-owner commands, battery-saving notes, and a V1 target around 1280x720 at 10 fps. A second research pass produced docs/jelly-star-second-round.md, clarifying that wireless adb was practically required because the phone has one USB-C port and must also host the capture dongle.
The same day, the first useful proof landed: the Jelly Star and UGREEN/MacroSilicon dongle could behave as a stock-ROM userspace-UVC appliance. The important output was not a polished app. It was retained H.264 MP4 clips, status files, no-signal classification, wake and deep-idle observations, and import tooling that preserved capture timestamps.
By March 28, the Jelly Star was producing the kind of data volume that shaped Guardian import design. A single day could create more than 300 files. That helped push Guardian away from per-file upload and toward shard transport, backend expansion, and later bundle-oriented thinking.
On March 29, phonecapture became more product-like. The Jelly Star app shortened recording warmup, reported actual MP4 container duration, and exposed a local HTTP transfer server on port 28781. The Mac importer became Fone, gained LAN discovery, a Haptica icon, persistent destination settings, and signed/notarized releases. A clean second Mac user imported 418 files into Downloads without preseeded configuration or ADB.
April 2 brought the power and recovery work. The Jelly Star had shown a bad field behavior: it sometimes shut down or failed to come fully back from power presses unless plugged in, even when the battery was not known to be empty. With no live device reachable, the work stayed code-backed. The app did not contain an explicit “only restart when charging” rule, but DevicePolicyManager.reboot() could run after dongle disappearance. The fix made future failures legible: lifecycle breadcrumbs, boot and package-replacement events, charger attach and detach, BATTERY_LOW, BATTERY_OKAY, shutdown events, and battery or charging state in status.json and uvc-status.json.
By April 7, a new Jelly Star was visible over USB as JELLYS0000058229, the latest kiosk app had been installed, and the device was described as being in real appliance mode. The same work revisited OS-integration paths, including privileged app possibilities, but the stock kiosk approach remained the practical path.
Current State
The Jelly Star is the working near-term phonecapture appliance. It runs the Android kiosk app, records UVC capture input, reports states such as no_signal_colorbars, stale_static, live, and device_missing, and leaves enough local status for diagnosis. Fone is the companion Mac importer for pulling those memories over the network.
It is not the final hardware answer for 1Context. The life-story explicitly treats it as a near-term proof while custom hardware remains a later option if battery, radio, and capture behavior exceed what a phone can promise.
Open Questions
The main unresolved question is recovery policy. April 2 made reboot decisions inspectable, but the next intended step was to gate automatic recovery reboot on charging state or a battery floor, then read the status files after a real Jelly failure.
The second question is how long the stock-ROM path can hold. It has avoided custom ROM cost so far, but USB permission friction, one-port development limits, idle behavior, and appliance lockdown remain the boundaries to watch.