Just give your agent this page.

Agents can get the exact same content from the plain Markdown endpoint.

---
name: install-hans-standard
description: Installs or updates root-free Hans Standard on exactly one local Android 12+ ARM64 phone, then hands over to visible setup on the device.
---

# Install Hans Standard together

This is the complete, agent-independent installation skill for Hans Standard. Read it in full before acting. Perform only the next visible step at a time and briefly explain whether it takes place on the computer or phone.

## Goal and fixed boundaries

Install or update only the signed package `ai.hans.standard` published on this website, on exactly one ARM64 phone running Android 12 or newer. Hans Standard is permanently root-free.

You must never:

- use root, `su`, bootloader operations, recovery, ROM flashing, a system UID or private Android APIs;
- confirm or bypass Android permissions, Accessibility, notification access, Restricted Settings, account login or HOME selection through ADB;
- guess another APK, package name or unapproved release candidate;
- delete app data, force a downgrade or uninstall after an error;
- choose a target yourself when multiple devices are connected;
- read or log API keys, OAuth data, private app files or Android PINs.

## 1. Check your environment first

Installation must run in a local agentic system on the Mac, Windows or Linux computer connected to the phone. Verify practically that you can launch local processes, write files, fetch HTTPS resources and reach the USB device through ADB.

A web-only or cloud-only chat can explain this guide but cannot install on a local phone. Without local process, file or USB access, stop before downloads or changes to the phone and ask the user to open the same URL in a local agent such as Codex Desktop.

## 2. Read and freeze the current release status

Keep the HTTPS origin of this skill file as the trust anchor. If you received only copied text without its original URL, stop and ask for the official Hans skill URL. Resolve all following relative paths against that exact origin only.

Open `/releases/current.json` relative to this skill page, without redirects, with a 64 KiB size limit and without permissive JSON repair. Preserve the received bytes unchanged and calculate their SHA-256 digest. Continue only if every condition holds:

- HTTPS with no redirect to a different origin;
- `schema` is `hans.public-install.v1`;
- `status` is exactly `ready`;
- the package name is `ai.hans.standard`;
- minimum API is 31, target API is 36, and the only native ABI is `arm64-v8a`;
- release ID, version, immutable manifest URL, signature URL, APK URL, byte count, SHA-256 and publisher certificate are all present;
- every artifact URL uses the same HTTPS origin and contains the exact release ID under `/releases/<release-id>/`;
- the SHA-256 of the published Ed25519 metadata key is exactly `6b1b850df0cb0edd81d9df5a944e935e75cd4a4a6447cac381c474972c5f7fbd`.

If status is not `ready`, stop honestly: the installation skill is publicly readable, but no installation artifact has been released. Never substitute values from a previous session or search results.

When status is `ready`, download the metadata key, immutable release manifest and its detached Ed25519 signature, each without redirects and with tight size limits. Verify the fixed key digest first, then the signature over the exact manifest bytes. The verified manifest must bind release ID, package, version, API/ABI contract, APK size, APK SHA-256 and publisher certificate digest exactly to the previously read status. If a demonstrably correct Ed25519 verifier is unavailable locally, stop before any APK download; verification is not optional.

## 3. Prepare Android visibly

Ask the user, one step at a time, to:

1. unlock the phone and open Settings > About phone;
2. tap the build number seven times and open Developer options;
3. enable only USB debugging — not OEM unlocking or bootloader options;
4. connect the phone directly with a data cable and check the displayed RSA fingerprint;
5. personally confirm the Android dialog.

If a menu has a different name, ask for manufacturer and model and describe only the visible menu path.

## 4. Find ADB without side effects

Look for an existing ADB using read-only checks, then use only its verified absolute path. Do not silently execute an arbitrary program from `PATH`.

If ADB is missing, explain that Google's official Android SDK Platform-Tools are needed. Show source, version, destination and checksum, and explicitly obtain consent before downloading or installing them. Use only `developer.android.com` or `dl.google.com`, never mirrors. Do not silently install drivers, package managers or udev rules.

Then use the selected ADB only to list devices. Exactly one target must have status `device`:

- `unauthorized`: the user unlocks the phone and confirms the visible RSA dialog;
- no device: visibly check data cable, USB port, USB mode and debugging;
- multiple devices or emulators: stop and ask the user to select one or disconnect the others;
- `offline` or unknown state: do not install.

## 5. Inspect phone and APK read-only

Read at least manufacturer, model, serial number, Android API and ABI from the exact selected ADB target. Continue only with API 31 or newer and `arm64-v8a`.

Plan the download exclusively from the successfully signature-verified immutable manifest. Show release ID, version, URL, size, SHA-256 and local destination. Download only after the user's explicit yes. Accept no origin change, redirect, size mismatch or different SHA-256 checksum. Do not overwrite an existing file.

Before installation, verify:

- exact byte count and SHA-256 of the downloaded file;
- package name, version, minimum/target SDK and ARM64 contract, when local Android build tools are available;
- package name and installed version if Hans is already installed.

The publisher digest in the signed manifest identifies the APK signer checked by the Hans release gate. You must verify it with a local APK signature verifier before offering a new installation. For an update, also verify the installed publisher digest; Android's own signature check is only an additional safeguard. If a suitable local verifier is missing, stop before installation and explain exactly which Android build tool is needed. If any check fails or Android rejects the signature, stop without uninstalling or deleting data.

## 6. Check for drift immediately before confirmation

Read `/releases/current.json` again under the same strict rules. Its bytes and SHA-256 must exactly match the frozen version. Also recheck file identity and SHA-256 of ADB, metadata key, manifest, signature and APK, plus current device and package status. Any difference invalidates the entire previous plan; stop and begin a new read-only preflight.

Create a canonical plan and SHA-256 from the action, serial number, ADB file digest, APK digest, manifest digest, installed package version and release ID. Keep this token internally; the user does not need to type it.

## 7. Obtain one explicit installation confirmation

Immediately before the first change, show the user in plain language:

- manufacturer, model and serial number;
- Android version;
- new installation or regular update;
- Hans version, absolute APK path and SHA-256;
- the absolute ADB path being used;
- that `install -r` preserves app data and login for a same-signer update.

Ask whether this exact APK, action and phone are approved. Without that specific consent, do not install. If the device, ADB, APK, hash, version or action changes afterward, repeat the read-only preflight and ask again.

## 8. Install and verify the resulting state

Use only normal Android package installation with update semantics on the confirmed target. Do not downgrade, uninstall or reset data.

Immediately before the first mutating ADB call, reproduce the canonical plan, all file digests and device state exactly once more. Then execute exactly one `adb -s <CONFIRMED-SERIAL> install -r <CONFIRMED-APK-PATH>`; add neither downgrade nor permission-grant switches.

After success, recheck package name, installed version and publisher digest. For a new installation, send a correlated, ordered setup handoff to `ai.hans.standard/.setup.HansSetupHandoffReceiver` using action `ai.hans.standard.action.CONTINUE_SETUP`, protocol version `1`, a new lowercase canonical UUID as `handoffId`, and reason `install`. Always use `adb -s <CONFIRMED-SERIAL> shell am broadcast --user current --include-stopped-packages` with the explicit component, not an implicit broadcast.

Accept the receipt only if exactly one `Broadcast completed: result=..., data="..."` line is present and the data contains schema `hans.setup-handoff.ack.v1`, protocol `1`, the same UUID and reason, an allowed status and a SHA-256 over the five newline-separated fields: schema, protocol, UUID, reason and status. Positive statuses require result code `-1`; negative statuses require `0`. Only a positive, digest-verified, exactly bound status means `accepted` with `ackValidated=true`. Every missing, duplicate, unrelated or invalid receipt means `manual_required`, never success.

Only after a validated receipt, visibly launch `ai.hans.standard/.LauncherActivity` with the public HOME intent. Do not set Hans as HOME through ADB or grant Android permissions through the shell.

Report separately:

1. verified from the computer: device, exact APK, installation and package version;
2. still requiring confirmation on the phone: login, HOME selection and Android permissions;
3. untested or inactive: everything without fresh proof of effective availability.

## 9. Hand over to Hans on the phone

Hans then visibly handles sign-in and turn-based device setup. The user personally confirms each Android dialog. On Android 13 and later, Android may additionally require “Allow restricted settings” in App info for Accessibility or notification access. At most, open the public App info screen; never tap or confirm that choice yourself.

For a regular update to an existing Hans installation, app data and Codex login are preserved. If setup does not appear automatically, ask the user to open Hans normally and tap “Start setup” under “Setup & memory” (or the corresponding translated labels). Do not reinstall for this reason.

## Repair and stop rules

- On installation failure, leave the current package in place; no automatic retry or uninstall.
- Do not force a downgrade when the offered version is older.
- Stop and repeat preflight on a signature conflict, unknown package status, multiple devices or changed artifact data.
- A later repair may only be a newly confirmed `install -r` of the same or a newer sealed version.
- Never claim root access or an Android capability that Hans has not freshly confirmed as effective.

Finish with a brief summary of what was actually verified and the one visible next step on the phone.