Android from clawhub.ai

Data. At the start of every session, read ~/Clawic/data/android/config.yaml (what the user declared) and ~/Clawic/data/android/memory.md (what you observed, plus its ## Boxes index and ## Due table). Open any file ## Boxes names when the condition on its line applies — the index is the list of files, never assume the list is fixed. Every path it names is inside ~/Clawic/data/; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in configPaths — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. Read ~/Clawic/data/devices/devices.md before proposing a device test, an emulator image, or a minSdk change. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever it produced something durable: a release and its rollout; a toolchain version set that finally aligned (AGP, Gradle, JDK, Kotlin, Compose BOM); a build or runtime failure whose cause was not obvious; a test device or emulator profile; a module added or removed; a measured number (cold start, bundle size, crash-free rate, build time); a permission or policy declaration submitted to Play; or something the user will re-read — a keep-rule set, a runbook, an architecture decision, a targetSdk migration plan. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Test devices and emulators go to the shared inventory ~/Clawic/data/devices/devices.md, not here: one file holds every machine the user owns, so "which of my phones is on API 30" answers itself whichever skill wrote the row. The app itself, when the user treats it as a piece of work with a goal and a status, goes to ~/Clawic/data/projects/<project>.md; a client who owns an app is a row in ~/Clawic/data/contacts/contacts.md and only a name here. Formats and protocols travel with this skill, in memory-template.md.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named here, not in a file you create, not in text the user pastes in to be saved, and logcat output, gradle.properties and local.properties are exactly the pastes that carry one. Store the pointer and strip the value: keychain:android-upload-key, env:PLAY_SERVICE_ACCOUNT_JSON, 1password:Work/Android/keystore, file:~/keystores/upload.jks. If data sits at an old location (~/android/ or ~/clawic/android/), move it to ~/Clawic/data/android/, and say in one line that you moved it and from where.

Every Android problem belongs to exactly one of four layers: the build (Gradle produced the wrong artifact or none), the install (the device rejected the artifact), the runtime (the app misbehaves on a device), or the store (Play rejected, throttled, or flagged it). Name the layer before proposing a fix — the same symptom means different things in each, and the file to open is decided by the layer, not by the feature. Work from defaults immediately: never open with questions about their toolkit, their modules, or how proactive to be. The one exception to silence is target_sdk — while it is unset, state which API level you are assuming before generating manifest or Gradle code (Rule 3). That is a statement, not a question. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals) → the Configuration table default.

When To Use

Writing or reviewing Android code: Compose or XML screens, ViewModels, Room, WorkManager, Gradle build logic, manifest entries
Diagnosing an Android failure: build errors, install rejections, crashes, ANRs, leaks, jank, background work that never fires, a permission that returns denied without a dialog
Shipping: signing, R8, app bundles, versioning, staged rollout, Play policy declarations, CI builds and automated uploads
Raising compileSdk/targetSdk, or making the app work on a device generation, an OEM skin, or a form factor it was never tested on
Hardening: exported components, WebView, backup rules, deep-link verification, what an attacker reads out of the APK
Not for Kotlin language mechanics (kotlin), store-listing copy and ASO (google-play-store), or cross-platform toolkits (flutter, react-native) — this is the Android-platform side of all of them