android-docs

android-docs

The Android Knowledge Base shipped with the Android CLI is curated for agent use: each entry is a kb:// URL whose contents follow Android's official guidance. Prefer it over WebSearch for any topic owned by the Android team — search results are noisier and frequently outdated.

When this skill wins over alternatives

Topic	Use this skill	Use Context7 / WebSearch	Use Native knowledge
Compose recomposition rules	✅
Foreground service types (Android 14+)	✅
Edge-to-edge / window insets	✅
Background work / WorkManager	✅
App startup / Baseline Profiles	✅
Accessibility / TalkBack	✅
Retrofit / OkHttp / Moshi		✅ Context7
Hilt / Dagger / Koin		✅ Context7
General Kotlin idioms			✅
Gradle / AGP changelogs	✅ (build topics)

If unsure, try android docs search first — search is fast and a miss is information itself.

Workflow

# 1. Search
android docs search 'How do I improve my app performance?'
# → returns kb:// URLs with snippets

# 2. Pick the most relevant URL, fetch full content
android docs fetch kb://android/topic/performance/overview

# 3. Synthesize an answer for the user, citing the kb:// URL

Search query craft

• Use natural-language questions. The KB is tuned for them: "How do I implement edge-to-edge?" works better than "edge to edge insets api".
• Include the API level if relevant. "foreground service types Android 14".
• Include the framework keyword. "Compose recomposition lazy column" beats "recomposition lazy column".
• Don't quote. This isn't Google Search; literal quotes don't add precision.

Citation style

When using KB content in an answer, cite the kb:// URL directly. The user can re-fetch it themselves:

> Per [kb://android/topic/performance/baseline-profiles], the recommended setup is …

This is more durable than copying https://developer.android.com/... links because the KB version is what the CLI actually fetches, and is locked to a known revision.

Operating rules

1. Search first, fetch second. Don't fetch a guessed kb:// URL — IDs change. Always search and pick from real results.
2. One fetch per topic, not five. If the first fetch is a top-level overview that points at sub-pages, follow those — don't shotgun-fetch every search result.
3. Cite what you used. Always include the kb:// URL in the answer so the user can verify and explore further.
4. Fall back to WebSearch only when KB returns nothing relevant. Document the gap in the answer ("KB has no entry for this; pulling from external sources").
5. Don't paraphrase silently. When the KB has authoritative wording (e.g., a foreground service type list), quote the relevant sentence verbatim and cite.
6. Don't fetch and dump. Read the fetched content, synthesize, and answer the actual question. Don't paste the whole KB page back to the user.

Anti-patterns

• ❌ Going straight to WebSearch / WebFetch for "how do I do X in Compose" without trying android docs search first.
• ❌ Relying on training data for fast-moving topics (Compose APIs, foreground service types, edge-to-edge, predictive back). KB is more current.
• ❌ Citing developer.android.com URLs that you didn't actually read in this session — pretend-citation.
• ❌ Mixing multiple KB excerpts without citing each one.
• ❌ Using KB for third-party SDK questions (Stripe, Firebase Crashlytics, Retrofit) — those are not in the Android KB.

Error recovery

Issue	What to do
search returns no results	Try a broader / rephrased query. If still nothing, fall back to Context7 (Android Jetpack libs are documented there) or WebSearch — and tell the user.
fetch <kb-url> returns empty	The URL was malformed or stale. Search again with a different query.
Search results all look off-topic	The query may be too narrow or use jargon the KB doesn't index. Re-phrase as a "how do I" question.
User asks about a topic that's clearly third-party	Don't force the KB. Hand off to the Context7 path.