Google Android Skills Review: Do 22 Official Agent Skills Make Android Work More Reliable?

Test window: August 8–9, 2026

Project: android/skills

License: Apache-2.0

Snapshot: 6,628 stars, 387 forks, last pushed August 7, 2026

Evidence split: 60% local tests, 40% verifiable repository facts

The short answer

Google Android Skills is not a universal Android coding assistant. It is a collection of official skills aimed at the long tail of Android development: system insets, Compose migration, performance traces, R8, Play policy, testing, and newer device surfaces.

Our score is 4.4 / 5.

• All 22 skills passed the relative-link check.
• 21 of 22 skills had complete frontmatter.
• A 20-prompt trigger test reached 100% overall agreement.
• In the edge-to-edge A/B test, the no-skill group reached a median of 9/12, while the skill group scored 12/12 in all three runs.
• We did not complete a real Gradle build, emulator install, or screenshot regression, so a static pass is not proof that the final UI is fixed.

The strongest use case is making a known Android workflow more repeatable. It is not a reason to install every skill, upgrade a production project blindly, or skip code review.

Scorecard

Weighted score: 4.4 / 5.

That score describes the engineering quality of the collection. It does not mean every project should install all 22 skills, and it does not replace compilation, device testing, or human review.

What the collection covers

The repository is split into 22 skills covering:

• build tooling and AGP upgrades;
• CameraX, Media3, and device capabilities;
• adaptive Compose layouts, theming, and XML migration;
• Navigation 3, system bars, and edge-to-edge;
• R8, Perfetto SQL, and trace analysis;
• Play Billing, Play policy, and Engage;
• Wear OS, TV, and XR;
• Android Intent security;
• test setup, screenshot tests, and a developer-tool CLI.

This distribution is deliberate. It spends less space on basic Compose advice and more on tasks where an agent can produce code that looks plausible but misses one important system constraint.

How we tested it

L0: static audit

We inspected every skill for:

• frontmatter fields including name, description, license, author, last-updated, and keywords;
• actual token counts using cl100k_base rather than disk-size estimates;
• the ratio between the entry file and its references;
• broken relative Markdown links;
• symptom-oriented trigger language in descriptions.

L1: trigger accuracy

We gave a clean agent only the names and descriptions, not the skill bodies. The test used ten prompts that should select edge-to-edge and ten similar prompts that should not.

The goal was to test the selection boundary, not whether the model could read the solution after the skill was already chosen.

L2: A/B output test

The same user request and the same deliberately flawed Compose fixture were run three times in each condition:

The output was graded with a 12-point checklist, including a negative check for double padding. Each group was summarized by its median.

L3: not completed

We did not run a real Gradle build, install the APK on an emulator, or compare screenshots. The results below measure static correctness and generation stability, not final device behavior.

L0 findings: engineering quality is not the same as disk size

All relative links were valid

The 22 skills contained no broken relative links. The reference tree contains roughly 568,915 tokens, so this is a meaningful signal that the generation pipeline preserves its internal structure.

21 of 22 frontmatter records were complete

The only missing field was last-updated on android-cli. The other records exposed the metadata needed for automated selection and freshness checks.

The largest reference tree is not necessarily the largest context cost

engage-sdk-integration has roughly 191,467 tokens in references but only 1,978 tokens in its entry file. Its disclosure ratio is 96.8, which means the large body is loaded only when needed.

The entries that deserve more attention are the ones whose main file is already large:

Three skills have no references layer at all: android-intent-security, edge-to-edge, and play-policy-insights. That is workable for small topics, but inconsistent with the collection’s broader progressive-disclosure pattern.

Batch timestamps reveal the sync model

Eighteen skills share the same last-updated date, August 6, 2026. Two are dated May 14, one July 13, and one has no date.

This looks like a batch-generated projection of official documentation rather than 22 independently maintained documents. The benefit is a consistent source; the risk is that an upstream change can alter an entire batch at once.

L1 findings: why edge-to-edge avoided false positives

The trigger test reached:

• 10/10 recall on positive prompts;
• 0/10 false positives;
• 20/20 overall agreement.

The important design choice is not keyword volume. It is the narrow boundary in the description:

1. symptoms such as buttons or lists being obscured by system bars;
2. subdomains such as IME insets and system-bar legibility;
3. a causal limit: it covers system-bar, keyboard, and inset problems, not every button failure.

That distinction separates “the bottom button is hidden behind the navigation bar” from “the button’s onClick does nothing.” A description such as “fix button issues” would be much easier to over-trigger.

The test also found overlap

• perfetto-trace-analysis matches jank and latency complaints, but its description assumes that a trace already exists;
• adaptive and navigation-3 both discuss list-detail and multi-pane layouts;
• styles mentions themes and custom components, but is really about Styles API adoption rather than diagnosing a dark-mode color bug;
• interaction failures and dark-mode color issues have no direct skill in the current set.

Coverage gaps are acceptable. Broad descriptions that become the default answer for every nearby problem are not.

L2 findings: the skill reduces variance

The fixture intentionally contained:

• target SDK 34;
• no enableEdgeToEdge call;
• hard-coded top padding;
• a LazyColumn without content padding;
• a FAB with raw padding near the bottom edge;
• no windowSoftInputMode setting;
• a light background with default status-bar icon contrast.

The 12 checks produced this result:

The base model was not incapable. Its best run reached 10/12, and all three runs handled the core API correctly.

The gain was consistency:

• consumeWindowInsets improved from 1/3 to 3/3;
• safe FAB handling improved from 1/3 to 3/3;
• Scaffold improved from 2/3 to 3/3;
• LazyColumn content padding improved from 2/3 to 3/3.

For a solo developer, a 9/12 run may be enough to continue. For a team, three different architectures for the same class of bug create review and maintenance cost. In this test the skill acted as a stabilizer, not as a magical new model.

The important counter-finding: consistency can suppress judgment

The skill requires target SDK 35 or later. All three B runs upgraded targetSdk from 34 to 35; none of the A runs did.

The base agents were not unaware of the requirement. Their reasoning was that fixing the inset bug did not necessarily authorize a broader target-SDK upgrade, which can affect permissions, background limits, and foreground services.

This is a real design tension:

• MUST is useful when the task cannot be completed safely without it;
• MUST is risky when it turns a recommended upgrade into an automatic side effect.

Skill authors should reserve MUST for necessary conditions. Long-term best practices should be marked PREFERRED and accompanied by their migration and rollback impact.

Version compatibility: the first-choice API may not exist

One B run found that the recommended IME-first approach was not available in the fixture’s Compose BOM 2024.12.01. It correctly fell back to the alternative safe-drawing approach.

That is a good recovery, but it also shows that the collection tracks newer SDK guidance closely. Before applying a skill, verify:

• minimum compile SDK;
• minimum Compose or Gradle version;
• experimental API opt-in requirements;
• the documented fallback for older dependencies.

What it does well

Evaluation-driven topics

The collection focuses on places where agents often miss subtle constraints rather than repeating beginner tutorials. This is a better use of context than a broad Android encyclopedia.

Contract-like instructions

MUST, PREFERRED, exclusions, output formats, and version branches help an agent converge on a repeatable result. The L2 variance result is practical evidence that this writing style works.

Executable tooling

Some entries include analysis scripts and a developer CLI direction. They can check, convert, run, capture, and report instead of merely explaining.

A first-party source pipeline

The repository is generated from official Android documentation. That gives the collection a clear source boundary and reduces manual link rot.

What it does poorly

Coverage is skewed toward the long tail

Wear, XR, TV, Play Engage, newer navigation, and performance analysis occupy a large share of the collection. A typical business app may use only a few entries regularly.

Version requirements are often ahead of production projects

Some entries expect newer AGP, compile SDK, experimental Compose APIs, or target SDK levels. They may be better treated as migration guides until the project is ready.

External contributions are closed

The repository currently does not accept public contributions. Issue reports are possible, but community fixes cannot be merged directly.

Scheduled synchronization is not enabled

The scheduled workflow is commented out, so updates depend on manual triggering. The batch timestamps support this reading.

android-cli remains untested here

It may be the most valuable capability-oriented entry because it gives an agent SDK, emulator, run, screenshot, and documentation actions. This review did not install it, so it remains a promising lead rather than a verified production recommendation.

Who should install what?

Start in a disposable project. Pin the skill and dependency versions, run a ten-minute task, introduce one failure, save logs and diffs, then compile and run on a device before adopting it in a real repository.

Final verdict

Google Android Skills is a strong engineering reference for agent-assisted Android work. The static audit is clean, the trigger boundaries are unusually precise, and the A/B test shows a measurable reduction in output variance.

It is not an Android universal assistant or a production guarantee. Its best role is to stabilize tasks that a model mostly understands but repeatedly gets wrong in the details. Use it selectively, verify versions, and treat every upgrade, permission, script, and external dependency as a separate engineering decision.

Evidence boundary: L0, L1, and L2 results come from the August 8–9, 2026 local snapshot. L3 build, emulator, and screenshot validation were not completed. Re-run the final checks in the target project before making a production claim.