Generated banner for Play Policy Insights
Generated logo for Play Policy Insights

Play Policy Insights

Android (Google)OfficialCreated by Google LLCDistributed by Android (Google)

  • Skill
  • Review and audit
  • Security
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Automated auditor designed to verify Android applications against Google Play Policy domains. It cross-references static code analysis with Play Store declarations to generate deterministic compliance reports, identifying undeclared data collection, architectural risks, and missing disclosures across Permissions and APIs Hygiene, User Account and Identity, and Data Safety and Privacy domains.
— the description by Google LLC

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Play Policy Insights is an automated auditing tool designed to evaluate Android applications for compliance with Google Play Policy domains. It performs static code analysis and cross-references findings with Play Store declarations to identify potential issues such as undeclared data collection, architectural risks, and missing disclosures. The skill operates through a structured two-phase protocol, managing fact gathering, triage, and goal-oriented analysis to generate comprehensive compliance reports.

What it does

  • Performs static analysis on Android application codebases.
  • Cross-references code findings with Play Store policy declarations.
  • Identifies undeclared data collection and missing privacy disclosures.
  • Audits permissions, API hygiene, and user account/identity implementations.
  • Generates deterministic compliance reports for pre-submission review.
  • Supports both delegated and sequential execution modes for audit tasks.

When to use it

  • Before submitting an Android application to the Google Play Store.
  • When verifying compliance with Data Safety and Privacy policies.
  • To audit an app's use of restricted permissions and sensitive APIs.
  • To ensure demo login credentials and account deletion flows meet policy standards.

Advantages

  • Provides a structured, repeatable audit process for policy compliance.
  • Reduces manual effort by automating static analysis and report generation.
  • Ensures consistent evaluation across different audit domains.
  • Includes built-in safeguards for file system management and task execution.

Usage examples

“Run a compliance audit on the Android app located in /path/to/app_code.”
The agent initializes the audit environment, performs static analysis, executes goal-oriented checks, and generates a final compliance_report.md.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/android/play-policy-insights/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip play-policy-insights.zip -d .agents/skills

Documentation by Google LLC

Play Policy Insights: data safety, login credentials, and restricted permissions

You must audit Android apps for three specific policy domains. You must check data safety, demo login credentials, and restricted permissions.

Path Resolution

  • repo_root: Absolute path to the directory containing this SKILL.md.

  • app_dir:: Absolute path to the directory containing app's code.

  • temp_dir: Absolute path to the scratch directory at the workspace root. It is located at .scratch/play_policy_insights_<uuid>. Containment Mandate: You must confine all file system writes, intermediate artifacts, and logs strictly to this directory. This ensures the skill remains portable and safe across diverse execution environments, including local harnesses and CI/CD pipelines, by avoiding reliance on system-level temporary paths or user home directories.

Critical mandates

  • Execution Mode Awareness Before starting Phase 2, evaluate if your execution environment provides a tool to spawn or delegate tasks to general-purpose sub-agents (e.g., tools often named invoke_agent, delegate_task, or spawn_worker, using generic agent profiles like 'generalist' or 'coding_agent').

  • If YES, you MUST use Mode A (Delegation).

  • If NO, use Mode B (Sequential Self-Execution). You must read the prompt files intended for the subagents, follow their instructions, and write the expected output files to disk.

  • Sub-agents orchestration:

    • If you use "Mode A (Delegation)", wait for "SUCCESS" confirmation from sub-agents to know when they are done.

    • Idempotency & Timeout Safeguard: If a sub-agent fails or times out, you MUST verify the presence and integrity of its target output file (e.g., <temp_dir>/worker_<goal_name>.json) before retrying. If the file exists and contains valid JSON, treat the execution as SUCCESS and proceed. Otherwise, retry up to three times.

  • Fail-fast mandate: The automated audit in Phase 1 is the source of truth. If orchestrator.py fails, you must stop immediately with an explanation of failure. Do not use manual auditing as a fallback.

The two-phase protocol

Phase 1: Fact gathering and triage
  1. Initialize and triage:

    • Run python3 <repo_root>/scripts/orchestrator.py init <app_dir>.

    • This will create the scratch environment, perform static analysis, map the codebase, identify audit goals, and produce prompts for subagents for each audit goal and prompts for designated critic and aggregator subagents.

    • You must wait (up to 5 minutes) for the script to finish.

  2. Capture environment: Note values of the temp_dir, and activated_goals from the JSON output. You will need them in Phase 2.

  3. Evaluate goals: If activated_goals is empty, skip to step 3 of Phase 2 (Aggregation). Otherwise, proceed to step 1 of Phase 2 (Detailed analysis).

Phase 2: Goal-oriented audit

Determine your execution capabilities and proceed with either Mode A OR Mode B.

Mode A: Orchestrator WITH Delegation Capabilities (Parallel)
  1. Detailed analysis: For each goal in activated_goals (e.g., permissions_and_apis, data_safety_part_1, data_safety_part_2), delegate to a sub-agent. Concurrency Limit: You must not spawn more than 3 sub-agents simultaneously. Spawn the first batch of up to 3, wait for their completions, and then spawn the next batch. Repeat until all goals are complete. Pass the prompt: "Read your instructions from <temp_dir>/prompt_worker_<goal_name>.md and execute. MANDATORY: You must use your file-writing capabilities to save your final JSON findings directly to the file system at <temp_dir>/worker_<goal_name>.json. You are strictly forbidden from outputting the JSON in your chat response. To minimize context usage, your final response must be exactly 'SUCCESS' and nothing else." Validate: Confirm every <temp_dir>/worker_<goal_name>.json exists and contains valid JSON. If a sub-agent fails or times out, but the valid JSON output file is already present on disk, do NOT retry; proceed normally. Only retry the corresponding worker (up to three times) if the file is missing or invalid.

  2. Aggregate Findings: Execute the python aggregation command: python3 <repo_root>/scripts/orchestrator.py aggregate <temp_dir>. This produces aggregated_findings.json and returns a JSON object containing critic_chunks representing the number of chunks to verify (e.g., {"temp_dir": "...", "critic_chunks": 2}).

  3. Parallel Critic review: For each chunk index i from 1 to critic_chunks, delegate to a sub-agent. Concurrency Limit: You must not spawn more than 3 critic sub-agents simultaneously. Batch them in groups of 3 as above. Pass the prompt: "Read your instructions from <temp_dir>/prompt_critic_<i>.md and execute. MANDATORY: You must use your file-writing capabilities to save your final JSON findings directly to the file system at <temp_dir>/critic_output_<i>.json. You are strictly forbidden from outputting the JSON in your chat response. To minimize context usage, your final response must be exactly 'SUCCESS' and nothing else." Validate: Confirm each <temp_dir>/critic_output_<i>.json exists and contains valid JSON before proceeding. If it failed or timed out, but the valid JSON file is present, proceed normally. Otherwise, retry that specific critic chunk.

  4. Proceed to Finalization (Step 4 below)

Mode B: Orchestrator WITHOUT Delegation Capabilities (Sequential)
  1. Detailed Analysis: For each goal in activated_goals, sequentially:

    • Read the contents of <temp_dir>/prompt_worker_<goal_name>.md.

    • Execute the instructions contained within that file yourself.

    • CRITICAL: You MUST format your findings exactly as requested in the prompt and save them to <temp_dir>/worker_<goal_name>.json. Do not summarize findings in your thoughts or chat; move to the next task.

    • Validate: Confirm <temp_dir>/worker_<goal_name>.json exists before moving to the next goal.

  2. Aggregate Findings: Execute the python aggregation command: python3 <repo_root>/scripts/orchestrator.py --aggregate <temp_dir>. This produces aggregated_findings.json and returns a JSON object containing critic_chunks representing the number of chunks to verify.

  3. Sequential Critic review: For each chunk index i from 1 to critic_chunks, sequentially:

    • Read the contents of <temp_dir>/prompt_critic_<i>.md.

    • Execute the steps yourself and save your findings to <temp_dir>/critic_output_<i>.json.

    • Validate: Confirm <temp_dir>/critic_output_<i>.json exists before moving to the next chunk.

  4. Proceed to Finalization (Step 4 below)

Finalization (Both Modes)
  1. Present findings: Run python3 <repo_root>/scripts/generate_report.py <temp_dir>. It will produce <temp_dir>/compliance_report.md. Present this output file to user.

  2. STOP: The audit is complete. Await further instructions.

Files

resources/common_mandates.md

Execution Mandates

Technical Rules
  1. Absolute Paths Only: Always resolve and use absolute paths.

  2. Containment: Write all artifacts strictly within {{TEMP_DIR}}.

  3. Fail-fast: If any required input file is missing, stop immediately and report the failure.

Surgical Input Protocol & Efficient Search (MANDATORY)
  • Direct Evidence First: Prioritize files listed in the Context & Evidence sections. Use the provided file/line evidence (e.g., from Data Sources or Sinks) to jump directly to the relevant code. Do not perform broad workspace searches if these surgical starting points are available.

  • Path Filtering Over File Crawling: Locate target files by name, path, or extension first using directory/file listing tools before performing any text/content-based searches. Restrict searches and file reads strictly to the target {{APP_DIR}}.

  • Strict Exclusions (The Noise Wall): Configure search, glob, and find tools to ignore build, cache, dependencies, and testing folders. You MUST exclude matches from: **/build/**, **/.gradle/**, **/.scratch/**, **/androidTest/**, **/test/**, **/node_modules/**.

  • Targeted Extensions: Restrict content searches and file reads strictly to source and configuration files: .java, .kt, .xml, .gradle, .kts (and .js, .ts, .jsx, .tsx, .dart if a hybrid/cross-platform environment is analyzed). Never search or read inside compiled .class files, binary resources, or output assets.

  • Surgical Queries & Limiters: Use highly specific search patterns (e.g., search for getLastKnownLocation or deleteAccount instead of general words like location or delete). If search tools support limits or pagination, cap results at a maximum of 50 matches. Do not load unlimited search results into your context window.

  • Parallel Reading Required (Turn Efficiency): You are operating under a strict maximum turn limit. To prevent timeouts, you MUST request to read multiple target files concurrently in a single response. Do not read the evidence files sequentially one-by-one. Issue all of your file-reading tool calls simultaneously whenever possible.

Evidentiary Standard & Guardrails (CRITICAL)

To prevent over-auditing, false positives, and speculative "prosecution" of compliant code during extrapolation:

  1. Presumption of Compliance: Treat code as compliant unless there is definitive, visible evidence in the provided files of a policy violation. If code is ambiguous, or if network/database logic is hidden behind abstractions (e.g., calling an interface or repository method like clearSession()), you must assume standard compliant behavior. Do NOT guess or speculate about what happens behind interfaces.

  2. Benefit of the Doubt: When compliance cannot be strictly verified due to code abstractions or missing source file contexts, you must downgrade your finding:

    • Never flag a 🔴 Critical or 🟡 Important finding based on suspicion or lack of context.

    • Instead, output a 🔵 Suggestion (informational) to advise the developer on what to double-check in their backend or configuration.

  3. Exclusion of Local State: Local-only processing (e.g., caching theme settings, user-selected visual configurations, or on-device-only database operations) is explicitly exempt from Data Safety collection or Account Deletion mandates.

  4. Concrete Attributions: Every 🔴 Critical or 🟡 Important finding must cite the exact file, line number, or configuration block containing the direct violation. If you cannot cite the exact line of code containing the violation, you cannot flag it as a violation.

  5. Empty-List Discipline: If no policy violations, discrepancies, or review items are identified during your audit, you MUST represent this as an empty array [] for that field (e.g., "findings": [], "verified_findings": [], or "manual_verification_required": []). DO NOT populate arrays with "dummy" objects, placeholder strings, or "N/A" / "None" values.

  6. Heuristics & Extrapolation Boundaries: Whenever applying specific heuristics defined in your goal (e.g., searching for implicit logger leaks or SDK siphoning), you must strictly bound them to the provided evidence and their immediate callers. You are strictly forbidden from initiating broad, unbounded searches for custom paths or variables across the wider codebase. Base your extrapolation only within the specific files already provided to you in the prompt.

Finalization & Output Mandates (CRITICAL)
  • Iterative Saving: If your investigation requires multiple steps, save partial or intermediate JSON states to disk as you progress. Do not hold all data in memory until the very end to prevent data loss upon interruption.

  • Strict File Output (NO TRIPLE BACKTICKS): You MUST save your final JSON output to disk at the exact path specified in the goal schema using your file-writing capabilities.

    • CRITICAL: The content written to the file MUST be pure, raw JSON. DO NOT wrap the contents inside the JSON file with Markdown code blocks (such as triple backticks json ...). Writing markdown blocks into the file makes the JSON unparseable by the compiler.

  • NO Chat Summaries: MANDATORY: DO NOT summarize your findings, explain your reasoning, or output JSON in your final chat response. Your chat output wastes context and is ignored by the orchestrator.

  • Verification Before Termination: You MUST only terminate and return the "SUCCESS" string after you have explicitly verified that your JSON file successfully wrote to disk and contains valid JSON (e.g., by reading the file back or checking the directory contents).

  • Final response: Your final response MUST be exactly the word: "SUCCESS" and nothing else.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Google LLC
Publisher
Android (Google) (Official)
Distributed by
Android (Google)
Source
android/skills · play/play-policy-insights · commit bf68e2d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.txt)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google LLC or Android (Google).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download play-policy-insights.zip