---
title: "Jelly Star"
slug: jelly-star
section: reference
access: public
summary: "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 af…"
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: [Tools, Infrastructure]
subject-type: tool
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## Jelly Star

The Jelly Star is the small Unihertz Android phone used as the near-term capture appliance for [phonecapture](/phonecapture). Inside [1Context](/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](/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](/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](/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). 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](/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](/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](/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](/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.