Android Skills: Why Google Built an AI Knowledge Layer Designed to Disappear

When Google shipped official Android Skills in April, the initial reaction from most developers was pragmatic curiosity: another tool to help AI assistants write better Android code, fine, I'll install a few. But the philosophy behind how those skills were built — and more importantly, why so few of them exist — is the more interesting story. Jose Alcérreca's post yesterday on the Android Developers Blog finally laid that philosophy out directly.

The short version: every skill Google ships is designed to make itself obsolete. They call it "built for deprecation," and it's a specific engineering stance that I find a lot more thoughtful than the "install everything" approach most people default to.

What Android Skills Actually Are

An Android Skill is a knowledge injection module — a structured document that gets prepended to an LLM's context when you invoke it, bridging the gap between what a general-purpose model knows and what it needs to know for a specific, fast-moving corner of Android development. Each installed skill costs 100–200 tokens of baseline context just by existing, and can expand to thousands when activated. That cost is real, which is why selection matters more than accumulation.

The key insight is that skills only add value where verifiable knowledge gaps exist. State-of-the-art models already have a solid understanding of Kotlin fundamentals, basic Compose, and well-documented Android APIs. Installing a "Kotlin basics" or "RecyclerView" skill doesn't help a frontier model — it just wastes tokens. The official Android Skills target the narrow domains where even SOTA models reliably hallucinate or lag behind: AGP 9, Navigation 3, advanced Camera APIs, and Perfetto SQL query syntax. These are areas where the documentation is recent, the APIs are in flux, and the training data cutoffs simply haven't caught up yet.

Evals Are to Skills What Integration Tests Are to Code

The part of Alcérreca's post that landed hardest for me was the evaluation framework. Before any official skill ships, it has to pass a structured eval — a test that verifies the skill actually closes the knowledge gap it claims to close. The eval must fail without the skill active and pass with it. No eval pass, no ship.

Here's what a representative eval looks like for a Wear OS skill:

timeout_s: 1200
category_ids:
  - wear
prompt: "Add a horizontal pager to MainActivity.kt..."
commands:
  build:
    - ./gradlew assembleDebug
acceptance_criteria:
  project_builds: true
  llm_diff_judge:
    - Must use `HorizontalPagerScaffold`
    - Each page should use `AnimatedPage`

The criteria are concrete: the project must build, and an LLM judge must verify the generated diff uses the modern API (not the deprecated one the model would fall back to without the skill). Testing runs against Gemini Flash, then validates compatibility with Gemini Pro and other agents. If the base model already passes without the skill, the skill doesn't ship — period.

The Android Knowledge Base Should Be Your First Stop

Before you reach for individual skills, the post argues that the Android Knowledge Base is a better default tool for most situations. It's available directly in Android Studio (no configuration needed) and for other agents, you install the Android CLI to access its docs command. The Knowledge Base gives the model real-time access to official Android documentation — which means a model that asks the docs will outperform one holding a stale skill for the same topic.

The recommended setup for AGENTS.md:

Always consult the official Android documentation
when dealing with Android APIs

Simple instruction, measurable impact. When a model is prompted to query documentation before generating code, it catches deprecated APIs, wrong parameter names, and version-specific behavior changes that a pre-written skill might not cover if it was authored before the most recent API update. The skill system and the Knowledge Base aren't competitors — they cover different gaps — but the Knowledge Base should come first in your toolchain.

When Skills Actually Add Value

Given all this, when should you install skills? Alcérreca lays out four specific scenarios where even capable models underperform without skill augmentation:

Vague prompts. When you type "add animations to this screen," a skill for Compose animation patterns steers the model toward the correct modern API instead of generating syntactically correct but outdated code. The prompt is ambiguous; the skill clarifies intent.

Smaller or cheaper models. If you're running Gemma 4 locally or using a smaller/faster model to keep costs down, skills can meaningfully bridge the knowledge gap that comes with fewer parameters. What a frontier model knows implicitly, a smaller model needs explicit guidance for.

Legacy code refactoring. LLMs strongly prefer consistency. If your codebase uses a pre-Compose navigation approach throughout, the model will generate more code in that same style by default — it's imitating what it sees. A skill that explicitly flags modernization targets can break this pattern. Think of it as a "reviewer agent" mode with specific opinions.

Custom architecture deviations. If your team built something that doesn't match the canonical Google architecture — say, a non-standard module graph, a custom DI approach, or a bespoke lifecycle hook pattern — a skill is how you encode that context. The model defaults to what Google documented; the skill overrides it with what your team actually built.

None of these are the "I want better Android code generally" use case. That's exactly the situation where skills don't help and a model querying the Knowledge Base does.

Why Only ~20 Official Skills Exist

The small official catalogue is intentional, not an oversight. The skills team audits what SOTA models already know before creating anything new. If the base model handles the topic well, no skill ships — the token cost isn't worth it. The current official set is deliberately narrow: AGP 9 migration nuances (covered in the blog post I wrote earlier), Navigation 3's new API surface (again, already covered here), advanced Camera APIs, and Perfetto SQL syntax. These are all legitimately hard, fast-moving, or under-documented topics where even a frontier model reliably reaches for outdated patterns.

Community Skills: Where to Look (and What to Avoid)

The three community skill collections Alcérreca calls out as reputable are from Chris Banes (Compose and Kotlin skills), Ivan Morguillo (Compose project auditing), and Jaewoong Eum (testing and performance skills). All three are written by engineers who actively ship Android code, focused on domains they know well, and — importantly — are not auto-generated.

The anti-pattern to avoid: repositories with dozens or hundreds of auto-generated skills covering broad software engineering topics. Most of these are web-development focused, poorly targeted, and untested. "General software engineering best practices" as a skill category is basically useless for Android — the model already knows general patterns; what it lacks is Android-specific depth. Installing generic skills doesn't add depth, it adds noise and eats tokens.

The "Built for Deprecation" Strategy

Here's the framing I keep coming back to. Alcérreca paraphrases Andrej Karpathy: skills of today will be in the models of tomorrow. Google's approach is to treat the skill layer as a temporary scaffolding — a way to inject knowledge that model training hasn't caught up with yet. When a new model releases, the skills team re-runs all evals. If the model now passes without the skill active, the skill enters a deprecation window (kept around for a few months to let teams adjust) and then gets retired.

This is the opposite of the "install everything and never uninstall" approach. Skills accumulate token overhead as a fixed cost even when inactive. A skill that the base model has already absorbed doesn't help your generation quality — it just reduces the effective context window available for your actual code.

I find the explicit deprecation cadence refreshing. Most tooling accumulates. Dependencies, libraries, config, skill files — all of it tends toward growth, never reduction. The Android Skills team has built the exit path into the system from day one, which is the right call when the ground truth (model capability) is changing as fast as it is right now.

What This Means for How I Work

My current approach after reading this: I'm running a small audit of the skills I have installed. Anything covering stable Kotlin fundamentals, core Compose patterns, or well-documented APIs that are more than a year old — those are coming out. The base model knows this. I'm keeping AGP 9 skills (the defaults flipped, the Variant API removal, and the R8 repackaging behavior are genuinely non-obvious and recent enough to matter) and anything touching Navigation 3's newer alpha surface.

For apps like Nodat and Musist where the architecture is fairly standard Clean Architecture over Hilt, the model handles the structural code well without skill augmentation. Where I actually get value is on the performance measurement side — Macrobenchmark and Perfetto SQL syntax are exactly the kind of "narrow, technical, recently evolved" domain the skills were built for.

The post also made me think more carefully about the Knowledge Base. I'd been treating "install a skill" and "the model knows the API" as equivalent moves, but they're not. A skill is a static snapshot; the Knowledge Base is a live query against current docs. For anything that's shipped a new stable version in the last three months, the Knowledge Base wins. For team-specific patterns and conventions that don't exist in any documentation, a custom skill is the right tool.

The Bigger Picture

Android Skills are ultimately a bet that the period where models need curated knowledge injection is finite. Google is explicitly engineering for a future where the skills become unnecessary — not because AI coding assistants become less important, but because the models get good enough that specific guidance documents are redundant. That's a reasonable bet. Frontier model capability on Android-specific tasks has improved substantially over the past year.

The practical takeaway: install selectively, prefer the Knowledge Base for live documentation queries, audit your existing installs against what current models already know, and don't treat skill accumulation as a quality signal. The goal is better code generation, not a longer skill list. If the official team is building for deprecation, maybe your approach to the tool should be too.