Play Policy Insights in 2026: 2 tools share the name, and only 1 runs inside your coding agent

Summary. Buried at the bottom of Google Play's 15 July 2026 policy announcement is a tooling change worth more to most teams than the policy changes above it: "we've launched a new Android skill to help you with Play Policies. It's an open-source tool that grounds LLMs in Google Play Policies so your preferred AI assistant can evaluate your code right inside your IDE or CLI." The skill lives in the android/skills repository, which Google announced on 16 April 2026, carries an Apache License 2.0, and now holds roughly 20 skills across 53 commits with 6.4k stars. Play Policy Insights audits an app "against Google Play policies to verify compliance across permissions, account deletion, and data safety". Confusingly, Android Studio has shipped a separate lint feature under the same name, backed by the com.google.play.policy.insights:insights-lint artifact. They are different tools with different failure modes. The timing matters: three Play deadlines land between 26 August 2026 and 30 September 2026, and a suspended developer account is not something a $25 one-time registration fee buys back quickly.

This guide covers what an Android skill actually is, the exact CLI commands to install one, which agents it works with, what the policy skill checks, where the Android Studio lint fits instead, and how to put either into a release pipeline without pretending it replaces review.

Two tools, one name

Neither is an approval. Android Studio's own documentation for the lint says it "doesn't cover every policy, nor does it provide final app review decisions. Always review the full policy in the Policy Center to ensure compliance." The skills repository puts it more bluntly: "AI can make mistakes, so always double-check the results."

If you take one thing from this article: the skill is a development-time aid, the lint is an inspection pass, and Play review is the only decision that counts. Teams that conflate the three ship late.

What an Android skill actually is

Google's definition is precise, and worth reading before you treat this as another plugin format:

"Android skills follow the open-standard agent skills - markdown files (SKILL.md) that provide a technical specification of a task, and ground LLMs with information on specialized domains and workflows."

A skill is a Markdown file with YAML frontmatter carrying name and description, optionally metadata.author and metadata.version, followed by a Markdown body. The documented limits are a name of 64 characters or fewer, a description of 1,024 characters or fewer, and a body targeted at 10,000 to 20,000 characters. Alongside the file, a skill may ship sibling directories: scripts/, references/ and assets/.

Agents look for skills in .skills/ or .agent/skills/ at the project root. Activation is automatic: "The agent automatically activates skills that are relevant to your task." In Android Studio you can also force it: "you can also invoke a skill manually directly by typing @skill-name in the chat window."

That design has a consequence people miss. A skill is not code that executes deterministically. It is context that changes what the model knows and how it approaches a task. The output is still a model's judgement, which is exactly why the "double-check the results" line is in the README rather than in a footnote. Our note on AI coding agent harnesses covers where that boundary sits across tools.

Installing it

Installation runs through the Android CLI. The README's commands are short:

            # install a single skill into the current project
android skills add --skill=r8-analyzer --project=.

# install everything
android skills add --all
          

For the policy skill, substitute the skill name from the catalogue. The wider command set is what makes this usable in a team:

            android init                        # installs the base android-cli skill
android skills list --long          # what is installed, verbosely
android skills find <string>        # search the catalogue
android skills add --agent='gemini' edge-to-edge
android skills remove <skill>
          

Two behaviours to know before you run this on a shared machine. First, the default install location when you have no existing agent directories: "If you don't have any existing agent directories and don't specify particular agents, the skills will be installed for Gemini and Antigravity at ~/.gemini/antigravity/skills." That is a home-directory install, not a project one, so a developer who runs the bare command gets a global change. Use --project=. when you want the skill versioned with the repository.

Second, the flags are the whole interface: --all, --agent, --skill, --project. Pin --agent in your onboarding script rather than relying on detection, so every engineer on the team ends up with the same setup.

Which agents it works with

The CLI's telemetry section names three agent identifiers, GEMINI, CLAUDE and CODEX, which is a reasonable proxy for what Google actually tests against. If your team standardised on something outside that list, the community repackaging is the practical route, with the usual caveat that it is not Google-maintained.

What the policy skill checks

Google's catalogue entry is the authoritative description, and it is narrow: audit Android apps against Google Play policies "to verify compliance across permissions, account deletion, and data safety".

Those three areas are well chosen, because they are where policy meets code rather than policy meeting paperwork:

• Permissions. Declared permissions that no longer match what the app does are the single most common source of policy friction, and they accumulate silently as features are removed. This is also where the 27 January 2027 READ_CALL_LOG change lands, covered in our Play read call log verification migration guide.

• Account deletion. A requirement that is trivially checkable in code and routinely missing: an in-app path and a web path, both reachable.

• Data safety. The declaration in Play Console must match what the code and its SDKs actually collect and transmit. Drift here is a build-time fact, so a tool reading your code has a real chance of catching it.

We could not verify a published, enumerated list of individual checks inside the skill: GitHub subdirectory pages render empty to automated fetching, so the SKILL.md body itself was not readable for this article. Treat the three areas above as the documented scope and confirm the specifics from the file in your own checkout after you install it.

What the skill does not cover is everything a policy announcement adds each quarter. The 15 July 2026 update alone brought new anonymous-chat and child-safety obligations effective 26 August 2026, an app-registration requirement by 30 September 2026, and the annual target API level requirement by 31 August 2026. A grounding file is only as current as its last update, so read the skill's metadata.version and treat the Policy Deadlines page as the source of truth. Our breakdowns of the 26 August anonymous-chat rules, the July 2026 policy update and the developer verification checklist cover what the tooling will not tell you.

What else is in the repository

The policy skill arrived into an existing catalogue, and the rest of it is worth an afternoon. Verified folders in android/skills include build-system work (agp-9-upgrade), camera/camerax, device-ai/appfunctions, devtools/android-cli, identity/verified-email, jetpack-compose, navigation/navigation-3, performance/r8-analyzer, play, profilers, security/android-intent-security, system/edge-to-edge, testing/testing-setup, wear/wear-compose-m3, and an XR skill for Jetpack Compose Glimmer on display glasses.

The catalogue also lists a play-billing-library-version-upgrade skill, which pairs directly with the Play Billing Library migration deadline many teams are already working through, a perfetto-trace-analysis skill and a migrate-xml-views-to-jetpack-compose skill. For a team running an Android modernisation programme, the migration skills are arguably higher-value than the policy one, because migration is where an agent's context window is the binding constraint and a specification file is the cheapest way to widen it.

One governance note: "Public contributions are not accepted at this time." You can fork and adapt, but you cannot upstream a fix, so if your team maintains local policy rules, plan to maintain them locally.

Putting it in a release pipeline

A workable sequence for a team shipping every two weeks:

1. Install per project, not per laptop. android skills add --skill=<policy-skill> --project=. with the result committed, so every engineer and every CI container gets the same grounding file.

1. Pin the agent. Set --agent explicitly in your bootstrap script. Silent detection produces different behaviour on different machines, which is the worst failure mode for a compliance aid.

1. Run the agent pass during feature work, not at release. The value of a skill is that the model already has your code open. Asking it about permissions the day before submission wastes the mechanism.

1. Run the Android Studio inspection before the release branch cuts. Code then Inspect for Play Policy Insights gives a repeatable list rather than a conversation.

1. Keep a human policy gate. Both tools say explicitly that they are not review decisions. The gate is a named person checking the Policy Center against the Policy Deadlines page for anything announced since your last release.

1. Version the grounding. Record the skill's metadata.version in your release notes. When a policy changes and the skill has not, you want to know which one you shipped against.

The economics are simple enough not to need a spreadsheet. A policy rejection costs a review cycle, and a review cycle is measured in days against a deadline calendar that does not move. A grounding file that catches one permissions mismatch a quarter has paid for the twenty minutes it takes to install. Rejections are cheap to prevent and expensive to absorb.

Writing your own policy skill

Because contributions are closed and the format is open, the useful move for most teams is to write a second, internal skill that carries what Google's cannot: your own app's history with review, your permission justifications, and the policy areas Google's skill does not cover.

The format gives you the shape. A SKILL.md with YAML frontmatter carrying name (64 characters or fewer), description (1,024 characters or fewer), and optional metadata.author and metadata.version, then a Markdown body in the 10,000 to 20,000 character band. Sibling directories scripts/, references/ and assets/ hold anything that is not prose.

            ---
name: acme-play-review-history
description: Grounds the agent in Acme's Play review history, permission
  justifications, and the internal policy rules that go beyond Play's own.
metadata:
  author: platform-team
  version: 2026.08.1
---
          

Three things belong in the body that no vendor can supply. The first is your rejection history: every policy citation you have received, what triggered it, and what fixed it, written as rules rather than as anecdotes. The second is a justification per declared permission, so an agent reviewing a diff can tell a legitimate permission from a leftover. The third is your own bar where it is higher than Play's, which is common for teams also carrying enterprise or regional obligations.

Put it in .skills/ at the project root next to Google's, version it with metadata.version, and review it on the same cadence as the Policy Deadlines page. Two grounding files disagreeing is better than one file quietly out of date, because a disagreement surfaces in the agent's answer where a human can see it.

The description field is doing more work than it looks. Activation is automatic and description-driven, so a vague description means the skill fires on the wrong tasks or not at all. Write it as a trigger condition, naming the artefacts and situations it applies to, not as a summary of the contents.

India-specific considerations

Two notes for teams building from India.

The data-safety area the skill checks is the one that overlaps most directly with the Digital Personal Data Protection Act 2023. A Play data-safety declaration and a DPDP notice describe the same collection from two directions, and they drift apart in the same way, when an SDK is added and nobody updates the paperwork. Building one inventory of what the app collects, which both artefacts render from, is the fix; our DPDP Act engineering playbook sets out that structure.

Second, agent tooling introduces its own governance question for services teams. If a client's source is being read by a third-party agent to run a policy check, that is a data-flow your contracts and your security review need to have covered before the first android skills add. We work through that decision in our AI coding agent rollout and governance work, and the delivery model sits in our enterprise mobile app development guide.

FAQ

How eCorpIT can help

eCorpIT builds and ships Android and cross-platform products for clients in India and abroad, and store-policy work is a standing part of that delivery rather than a scramble before submission. Our senior engineering teams wire policy checks into the release pipeline, keep the data-safety declaration honest against what the SDKs actually collect, and set the governance around agent tooling so a third-party assistant reading client source is a decision rather than an accident. As a CMMI Level 5 and ISO 27001:2022 certified organisation, and a partner of Google, Microsoft and AWS, we design applications aligned with Play policy and DPDP Act requirements from the first sprint. If your release calendar is running into Play's, start at /contact-us/.

References

1. Google, Policy announcement: July 15, 2026, Play Console Help, retrieved 6 August 2026.

1. Google, Policy Deadlines, Play Console Help, retrieved 6 August 2026.

1. Google, Android skills, Android Developers, retrieved 6 August 2026.

1. Google, Browse Android skills, Android Developers, retrieved 6 August 2026.

1. Google, Android CLI, Android Developers, retrieved 6 August 2026.

1. Google, android/skills repository, GitHub, retrieved 6 August 2026.

1. Google, Play Policy Insights skill, GitHub, retrieved 6 August 2026.

1. Android Developers Blog, Build Android apps faster using any agent, 16 April 2026.

1. Android Developers Blog, Android CLI stable 1.0 for agent development, 19 May 2026.

1. skydoves, android-skills-mcp, GitHub, retrieved 6 August 2026.

1. Google, Get started with Play Console, Play Console Help, retrieved 6 August 2026.

_Last updated: 6 August 2026._