check/skills/android/SKILL.md
MUST be invoked before any work involving: the `kind: android` schema kind, a `target: android` deploy (the external `deploy:android` substrate), the `apk:` layer package format (installing Android apps declaratively), the android deploy preresolver, an in-pod emulator OR a remote/physical adb-endpoint device, or nested `pod → android` deployment. The first-class Android device + app surface that sits above the `adb:`/`appium:` check verbs.
npx skillsauth add overthinkos/overthink-plugins androidInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
apk package formatAndroid is a first-class deploy substrate in charly, modeled on kind: k8s.
Two cooperating concepts:
kind: android — a DEVICE (the substrate). Either an in-pod emulator
(referenced by image:) or a remote/physical adb endpoint (adb: {host: <host:port>}). The analogue of kind: k8s (the cluster).apk package format — Android apps declared in LAYERS (NOT a kind),
parallel to package:/aur:. A target: android deploy applies its layers'
apk: packages onto the device. The app is the deployable workload, the way a
candy: image (a candy: node carrying base:/from:) is the workload for a pod/k8s deploy.This sits ABOVE the device-interaction verbs: the adb: (/charly-check:adb)
and appium: (/charly-check:appium) declarative check verbs drive a running
device; kind: android + target: android declaratively describe a device and
the apps installed on it. The install machinery is shared — see "One installer
(R3)".
kind: android — the device# charly.yml — each device is its own name-first entity (the android: discriminator
# holds scalars; non-scalar fields become child nodes)
pixel9a-36: # in-pod emulator device
android:
box: android-emulator # `box:` source field → the `candy:` image that BAKES the emulator + system image
device: pixel_9a # informational (documents the baked AVD profile)
api_level: 36 # informational (the API level is a BUILD property of image:)
pixel9a-36-google_account: # non-scalar field → child node
google_account: # credential-store secret-key refs for apkeep google-play
email_secret: GOOGLE_ACCOUNT_EMAIL
token_secret: GOOGLE_AAS_TOKEN
my-phone: # remote/physical device
android:
serial: 192.168.1.50:5555
my-phone-adb: # non-scalar field → child node
adb:
host: 192.168.1.50:5555 # an adb SERVER addr (a host running `adb connect`)
Device source is exclusive: image: XOR adb:.
image: (in-pod) — apkeep runs INSIDE the emulator pod (engine exec);
the pod's own adb installs onto its emulator. Needs nothing extra on the host.adb: (remote/physical) — apkeep runs ON THE HOST; the APK is pushed to
the endpoint via goadb (or adb -H <host> -P <port> for the apkeep-download
path). The host needs android-tools (adb) + apkeep for the package: path
(PKGBUILD optdepends; apkeep ships as an upstream binary — no Arch package);
the committed-apk: path needs neither (pure goadb push).Build-vs-runtime boundary (load-bearing). The Android system image + API
level are baked into the referenced candy: image at BUILD time (sdkmanager in
the android-sdk layer). kind: android REFERENCES that image — it never drives
a build. device:/api_level: are documentation, not assertions or build
drivers. Two API levels = two images, each with its own kind: android.
apk: — the package format (declared in layers)# candy/my-android-apps/charly.yml — name-first: the candy name is the top-level key,
# the apk: list is a child node
my-android-apps:
candy:
version: 2026.145.1700
my-android-apps-apk:
apk:
- package: org.fdroid.fdroid # apkeep download by id
source: apk-pure # apk-pure(default) | google-play | f-droid | huawei-app-gallery
arch: x86_64 # native ABI (apk-pure) — match the emulator
- apk: tests/data/MyApp.apk # committed local APK (project-root- or layer-relative), goadb push
Each entry is package: (apkeep) XOR apk: (committed file). source:
applies only to package:. The format compiles to an ApkInstallStep that
ONLY target: android executes — at image build and on
local/vm/pod/k8s targets it is recorded-skipped (there is no Android device
there; this is the same "wrong-venue skip" aur: uses off-Arch). A layer
carrying only apk: is valid install content.
Compared to a sideloaded APK: apps with a static-library dependency (e.g. Chrome's Trichrome) can't be sideloaded — install those via the Play Store image (preinstalled) instead.
target: android deploy# charly.yml — the device deploys INTO the emulator pod (pod → android), so it is a
# resource node placed UNDER the android-stack deploy (was nested:)
android-stack:
pod:
image: android-emulator
device: # deploy-into: applies apk: layers onto the device
android:
from: pixel9a-36 # → the kind: android device, deployed onto the emulator pod
device-add_candy:
add_candy:
- my-android-apps # layers whose apk: packages install onto the device
charly bundle add android-stack.device resolves the device, gates on
sys.boot_completed, and installs the add_candy: candies' apk: packages via
the external deploy:android substrate (F1 — served out-of-process by
candy/plugin-adb). Apps ride in on add_candy: (the same overlay mechanism
local/vm targets use) — there is no separate apk-list field. charly bundle del
best-effort pm uninstalls each package: id (replayed from the deploy's
recorded reverse ops; the device/pod lifecycle is owned by the pod deploy).
A top-level (non-nested) target: android deploy works too — for an image:
device it resolves the running container by image name; for an adb: device it
talks straight to the endpoint.
pod → android)Mirrors vm → k8s. The emulator runs in a pod; the device deploys onto it; the
apps deploy onto the device. target: android is a passthrough hop in the
deploy chain (the device shares its host pod's adb venue / the endpoint addr —
there is no shell venue to "enter"), so charly check live pod.android runs the
device's checks against the pod's published adb port. A pod's children can only
deploy AFTER charly start (the container doesn't exist at charly bundle add time),
so charly bundle add --node-only brings the pod up first and the children deploy
afterwards by dotted path; charly check run <bed> automates this (deploy pod →
config → start → deploy nested children → check-live).
candy/plugin-adb owns ALL Android device interaction — the adb: check verb,
the deploy:android substrate, AND the goadb-backed charly status probe — so
the goadb dependency + the single apk install path (install.go:
installByPackage apkeep+adb / installFromHostApk goadb push / uninstall)
live in ONE plugin, never duplicated across verb and deploy.
The deploy is split host ⇄ plugin (the F1 substrate-kind-plugin seam):
charly/android_deploy_preresolve.go, the registered android deploy
preresolver) resolves the device endpoint (engine inspect / ${HOST_PORT:N} /
google-play creds from the credential store) and collects the apk install specs
from the deploy's compiled plans (committed-APK paths → absolute host paths),
shipping them in DeployVenue.Substrate (a spec.AndroidDeployVenue).candy/plugin-adb/deploy.go, the deploy:android provider) gates
on sys.boot_completed, installs each app with retry (reusing the SAME
install/install-app method handlers the adb: verb dispatches), and returns
the pm uninstall teardown ops the host records + replays at charly bundle del.So the apk format, the check verbs, and the deploy substrate can never drift on
single/split/.xapk handling — they all flow through the one provider.
check-android-emulator-pod nests two devices: device (in-pod, installs
F-Droid via apkeep) and device-net (the same emulator addressed as a remote
adb ENDPOINT, installs the committed ApiDemos via goadb) — proving both device
kinds with no physical hardware. The android-emulator-layer check ASSERTS the
results (apk-fdroid-present/-launch, apk-net-apidemos-present).
target: android is an EXTERNAL deploy substrate (F1): it resolves to
externalDeployTarget over the E3b reverse channel, served by candy/plugin-adb.
There is no in-proc android deploy target.
charly/android_spec.go — AndroidSpec / AndroidAdbEndpoint /
AndroidGoogleAccount / ApkPackageSpec.charly/android_deploy_cmd.go — host-side device-endpoint resolution
(findAndroidSpec, resolveAndroidDevice, adbAddrForContainer, the
${HOST_PORT:N} helper) + the AndroidDevice handle. Shared by the deploy
preresolver AND the charly status AndroidCollector (no goadb in core).charly/android_deploy_preresolve.go — the registered deploy:android
preresolver: resolves the device + collects the apk install specs
(collectAndroidInstalls, resolveApkPath) into a spec.AndroidDeployVenue.charly/deploy_preresolve.go — the GENERAL per-substrate preresolver hook
registry (any external substrate registers one; only the body is substrate-specific).charly/provider_deploy.go — externalizedDeploySubstrates (the F1 source of
truth) + the relaxed checkDeployProviderBijection (in-proc XOR externalized).charly/plugin_prescan.go — isExternalDeploySubstrate (a substrate kind is
external iff in externalizedDeploySubstrates).charly/spec/deploy_wire.go — DeployVenue.Substrate + AndroidDeployVenue.candy/plugin-adb/deploy.go — the deploy:android provider (boot gate + install
loop with retry + uninstall reverse ops); install.go — the shared installer.charly/install_plan.go — ApkInstallStep; charly/install_build.go —
compileApkStep (the preresolver reads this step host-side; no DeployTarget executes it).charly/unified.go — loader wiring (mirrors every k8s site).charly/deploy.go BundleNode.Android; charly/bundle_add_cmd.go dispatch +
--node-only; charly/deploy_chain.go / charly/deploy_tree.go passthrough./charly-check:adb — low-level device control (the verbs the installer shares)./charly-check:appium — UI automation against the device./charly-core:deploy — target: android is one of the deploy targets./charly-image:layer — the apk: field is part of the layer schema./charly-internals:install-plan — the IR ApkInstallStep plugs into./charly-kubernetes:kubernetes — the kind: k8s pattern kind: android mirrors.MUST be invoked for any task involving kind: android, target: android
(the external deploy:android substrate), the apk: layer package format, an
adb-endpoint device, or nested pod → android deployment. Invoke BEFORE reading the android_*.go
source or editing a device's charly.yml / a layer's apk: list.
tools
Use when authoring or modifying a charly PLUGIN — a candy with a `plugin:` block that contributes Providers (verbs/kinds/deploy-targets/steps/builders/commands), its own CUE schema, builtin (compiled-in) or external (out-of-tree git repo). Covers the unified Provider model, the per-plugin CUE-schema contract (single source → Go params for dev + schema-over-Describe RPC for runtime), the SDK, and the loader.
tools
The CUE data-validation / configuration CLI (cue), pinned to v0.16.1. Use when working with the cue candy, installing the cue binary into a box or onto a target:local dev host, or running the offline schema-vendoring pipeline that feeds charly's egress validation.
tools
CUE EGRESS validation — validating (and, where it adds value, generating) the config files charly WRITES to a system BEFORE the bytes hit disk. MUST be invoked before working on charly/egress.go, the vendored schemas under candy/plugin-egress/egress-schemas/vendor/, the ValidateEgress / registerVendoredEgressKind path, the offline `task cue:vendor` pipeline, or adding an egress schema for any written artifact (cloud-init, k8s manifests, traefik routes, runtime config, install ledger, systemd/quadlet units, ssh_config, libvirt XML).
tools
Kubernetes cluster-probe declarative check verb — the `kube:` check verb (nodes, pods, ingress, storage class, addon health, apply/delete, and arbitrary resource GETs) served out-of-process by the candy/plugin-kube plugin (vendored client-go; no external kubectl required).