v0.3.0 — SDK, Agent House, and model-routed Phone Use

v0.3.0 — SDK, Agent House, and model-routed Phone Use

This release ships the installable Android Agent Harness sample and the productized v0.3.0 SDK sources.

Install

Download android-agent-harness-sample-0.3.0-debug.apk from the release assets.

• Android 8.0 / API 26 or newer.
• The APK is debug-signed and intended for sideloading and development.
• Android may ask you to allow installation from an unknown source.
• Build metadata: versionName=0.3.0, versionCode=6.

Use low-limit, revocable development credentials. Provider keys and Codex tokens use Android Keystore-backed encryption, but a debuggable APK is not a production secret boundary.

Highlights

• A redesigned Android shell with Home, Chat, Agent House, and Settings screens.
• Fixed quick-entry card insets so rounded shadows are not clipped.
• Offline demo, experimental Codex account login, Kimi Plan, Ark Plan, and custom OpenAI-compatible providers.
• Provider-specific model selection, including all 13 Ark Plan presets configured by this release.
• Model-routed Phone Use: there is no fixed Chat/Phone selector or keyword router.
• Normal turns begin with an 8-step budget; the first actual device-tool call activates a sticky, one-tool-per-step Phone Use loop with an 80-step ceiling.
• A real Stop control cancels provider work, fences late results, and discards an incomplete conversation turn.
• Durable app-private conversation sessions with atomic replacement and session management.
• Agent House context with source/trust metadata.
• The Agent can append daily memories and create disabled skill drafts during conversation. A skill reaches later context only after user review and enablement.
• Six locally publishable SDK artifacts plus an independent consumer smoke test.

Safety and privacy

• Accessibility must be enabled manually by the user.
• Phone Use reads a bounded semantic accessibility tree, not screenshots or screen recordings.
• Payment, transfer, purchase, delete, uninstall, and similar high-risk actions pause for a human approval overlay.
• Model-supplied confirmation values cannot approve an action.
• Home is refused, and launch_app requires an explicit app name or package.
• Agent House writes cannot silently enable a skill, overwrite user-owned enabled skills, store credential-like content, or grant capabilities.

Current boundaries

• Codex login remains an experimental sample adapter rather than an official third-party Android authentication surface.
• Risk detection is semantic and best effort; unlabeled, canvas-drawn, foreign-language, and WebView-heavy controls may not be classified correctly.
• Streaming, screenshot/vision input, background autonomy, Heartbeat, Dream, persona proposals, and proactive scheduling are not included.

Verification

The release gate runs SDK/public-consumer tests, JVM and Android tests, lint, provenance and credential auditing, local SDK publication, and sample APK assembly.

v0.2.0 — installable APK with live chat and phone use

This release ships an APK. Install it, paste your own API credential, and chat with a live model through the harness — or press Send with no credential at all and watch the offline scripted loop run locally.

Install

Download android-agent-harness-sample-0.2.0-debug.apk below. Android 8.0 (API 26) or newer.

The APK is debug-signed and sideload-only, so Android will ask you to allow an unknown source. A debug build is also debuggable, which means anyone with adb access to your unlocked device can read the credential it stores — use a low-limit, revocable key and press Clear credential when you are done.

What you can do with it

• Chat with zero setup. No credential, no network: a deterministic scripted provider runs the full context → provider → tool → provider → transcript loop on device, and every tool call is visible in the transcript.
• Chat with your own model. Paste the base URL, model, and credential of any OpenAI-compatible chat-completions endpoint (OpenAI, DeepSeek, and anything speaking the same protocol). The credential lives only in the app's private preferences and is sent only to the endpoint you configured.
• Let the agent operate your phone. Phone mode gives the model an observe → one action → observe loop over a real Android accessibility tree: tap, set text, Back, swipe, scroll until text is visible, launch an app by name, wait for the screen to settle. Home is refused, because leaving the current app strands the task. Finishing requires evidence text actually visible on the screen being claimed.

How the dangerous parts are held down

• High-risk actions stop for a human. Pay, purchase, transfer, delete, uninstall, order confirmation — and their Chinese equivalents — pause before executing. The approval panel is drawn by the accessibility service itself, so it stays visible over whatever app the agent is driving; an approval hosted by this app's own window would be invisible exactly when it matters.
• The model cannot approve itself. A model-supplied confirmed=true is ignored entirely. Only a real tap on Allow approves; Deny, the visible countdown expiring, and a missing approval surface all count as refusal — and a refusal is reported back in wording that tells the model not to retry, so a denial cannot turn into an approval-fatigue loop.
• No pixels leave the device. There is no screenshot, screen recording, or image input anywhere in the loop. The agent sees the accessibility node tree rendered as bounded text (60 nodes, 80 characters each), password fields redacted.

Honest limits: risk matching is keyword-based and can miss a control labelled in an unlisted language or not labelled at all, and with no vision fallback, canvas-drawn and WebView-heavy screens are largely invisible.

Under the hood

device-loop gained typed failures with candidate lists, a stale-target guard, and approval decisions that distinguish "the user refused" from "nobody answered". device-loop-android assigns content-derived node ids that survive scrolling (positional ids used to re-point the model at the wrong control), and walks the tree iteratively with depth and node caps — a self-referencing virtual tree previously raised StackOverflowError, which walks straight through a RuntimeException catch. provider-openai refuses redirects so an Authorization header is never replayed to a Location host.

217 tests. Verified on an Android 34 emulator: install, offline turn, accessibility service connect, phone mode toggle, keyboard-up send, no crashes.

v0.1.0 — first public release

First public release: milestones M1-M4 of the extraction roadmap, all landed and CI-verified.

Highlights

• 60-second quickstart, no Android SDK: ./gradlew :demo:run proves the full context → provider → tool → provider → transcript path deterministically.
• harness-core — four explicit runtime boundaries (orchestrator, context coordinator, tool orchestrator, session store) with zero third-party runtime dependencies.
• provider-openai — zero-dependency OpenAI-compatible adapter (hand-written JSON codec, JDK HTTP client, environment-only credentials). Works with OpenAI, DeepSeek, or any compatible endpoint via the live demo subcommand.
• scenarios subcommand — the controlled context plane made visible: trust rejection, priority competition, content budgets (with droppedItemIds), tool-profile boundaries, and bounded runs.
• harness-eval — governed evolution: a candidate markdown-workspace overlay is promoted only when it improves at least one case and regresses none (eval subcommand).
• device-loop — observe → act → finish device operation with an explicit high-risk pause protocol; unconfirmed dangerous actions never execute (phone subcommand).
• Provenance discipline — the auditProvenance build task rejects embedded credentials, reference product namespaces, local machine paths, and binary sample assets across sources, tests, and docs.

64 tests across five modules; CI runs both the no-Android-SDK JVM path and the full checkM0.

See README and ROADMAP.md for what comes next.