Google Play Compliance & Launch Checklist

Comprehensive pre-submission audit and compliance verification for Google Play Store publishing. Includes 2025-2026 policy updates with special sections for financial/loan apps.

Policy effective date: March 4, 2026 (unless otherwise stated per section).

Execution Contract (MUST read before starting)

This skill has 14 reference files. A full audit MUST load all 14. "Progressive disclosure" does NOT mean "skip files you think you know" — it means load each file before you make a claim against it, then cite the specific section.

The Six Rules

1. All 14 references MUST be loaded. If a reference does not apply to the target app (e.g., App has no store listing assets yet), the auditor MUST explicitly mark it "Not Applicable" with a one-line reason in the Coverage Report. Silent skipping is forbidden.
2. Parallel execution is the default. Spawn 5 Task subagents in a single message so they run concurrently. See "Parallel Execution Pattern" below for the exact grouping. The main agent merges findings and produces the final report.
3. Every finding MUST cite its reference. Output format is not optional — see "Output Format" below. A finding without both Reference: and Policy Source: is invalid and must be rejected.
4. The Reference Coverage Report is mandatory. Before the audit report is complete, emit a Coverage table with 14 rows. No Coverage table → the report is incomplete.
5. No conclusions from memory. If you cannot cite the reference file section you relied on, you do not have the finding. "I remember Personal Loans policy says X" is not acceptable — you must have actually loaded loan-harassment.md in this session before claiming a Personal Loans violation.

6. Judge outcome against policy. Never prescribe implementation as policy. Every finding must answer two structural questions, with both answers visible in the Output Format:

   • Declaration gate: Does Google provide a declaration channel for this policy (Permissions Declaration, Data Safety, Financial Declaration)? If yes and the developer's declaration status is unknown to the auditor, severity is NEEDS_CONFIRMATION — never BLOCKER/WARNING. If no channel exists (e.g., DexClassLoader, hidden functionality, using SMS data for credit underwriting), the policy is absolute and direct judgment is allowed.
   • Outcome vs. implementation: The Required by policy: field must contain verbatim or near-verbatim policy text — if you cannot quote it, you do not have a policy requirement. Any engineering preference (sender allow-lists, keyword filters, server-side checks, SP-key guards, specific APIs like SMS Retriever) goes in Suggested implementation: and must be explicitly marked "non-policy, auditor's suggestion only." Code existence alone is not a violation — the auditor judges what is actually exfiltrated, transmitted, or done, not what the code might do under some interpretation.

   Why: Past audits failed by packaging engineering preferences (e.g., "you must add a sender whitelist" or "OTP must use SMS Retriever API") as policy demands, and by judging code patterns (e.g., READ_SMS + uploadInfo) as violations without checking declaration status or actual transmission outcome. The Output Format below makes both gates structurally mandatory — a finding that fails either gate is invalid and must be rejected by the main agent.

Parallel Execution Pattern

Launch 5 Task subagents in parallel (a single assistant message with 5 tool calls). Each subagent owns a group of reference files and returns findings in the Output Format.

Subagent prompt template (use this when dispatching each subagent):

You are subagent {A|B|C|D|E} of a parallel Google Play compliance audit.

Your reference files: {list}
Your audit scope: {focus}
Target app path: {absolute path}

Instructions:
1. Read EACH of your reference files in full before auditing.
2. For each finding, produce the full Output Format block including
   ALL ELEVEN mandatory fields:
     status, Category, Finding, Evidence, Reference, Policy Source,
     Declaration Channel, Declaration Status,
     Required by policy, Suggested implementation, Deadline.
3. Apply Rule 6 (Six Rules):
   - If the policy has a declaration channel and you cannot confirm
     the developer's declaration status, status = NEEDS_CONFIRMATION
     (never BLOCKER/WARNING).
   - `Required by policy:` must be a verbatim or near-verbatim quote
     from the policy URL. If you cannot quote it, do not write the
     finding — you do not have a policy requirement.
   - Any implementation mechanism (sender allow-lists, specific APIs,
     SP-key names, server-side filtering, etc.) goes ONLY in
     `Suggested implementation:` prefixed "non-policy, auditor's
     suggestion only" — never in Required by policy or Finding.
4. If a reference does not apply to the target app, return:
   "Not Applicable: <one-line reason>" for that file.
5. Return ALL findings as a single markdown list when done.

Main agent responsibilities after subagents return:

1. Merge all 5 subagent outputs.
2. Deduplicate overlapping findings (same file:line + same policy).
3. Validate every finding against Rule 6 hard constraints:
   • Missing Reference: or Policy Source: → drop.
   • Declaration Channel ≠ None AND Declaration Status = Unknown AND status ≠ NEEDS_CONFIRMATION → downgrade to NEEDS_CONFIRMATION.
   • Required by policy: contains prescriptive implementation language not in policy text → move to Suggested implementation: before emitting.
   • Required by policy: cannot be traced to a quote at the cited URL → downgrade to INFO or drop.
4. Sort by severity: BLOCKER > WARNING > INFO. NEEDS_CONFIRMATION findings are listed in a separate section after INFO, never tallied with the others.
5. Produce the Reference Coverage Report.
6. Emit the final report in this order: Summary → Findings (BLOCKER → WARNING → INFO) → Pending Confirmation (NEEDS_CONFIRMATION) → Coverage Report → Launch Day Checklist.
7. Write the final report to a markdown file in the current working directory: play-store-audit-report.md. The file must contain the complete audit report in markdown format.

Pre-Submission Audit Process

Output each finding as a full block with all eleven fields. All fields are mandatory — none may be omitted:

[GP-XXXXX] status: BLOCKER | WARNING | INFO | NEEDS_CONFIRMATION
  Category: <section number, e.g. "3.1.4" or "IP.2">
  Finding: <factual observation — what the code/manifest/listing actually does>
  Evidence: <file:line — describe ACTUAL behavior (e.g. "uploads full SMS body via POST /api/sync"), not just code existence (e.g. "calls uploadInfo()")>
  Reference: <reference file>#<section anchor>
  Policy Source: <official Google Play policy URL>
  Declaration Channel: <Permissions Declaration | Data Safety | Financial Declaration | None>
  Declaration Status: <Confirmed | Pending | Unknown | Not Applicable>
  Required by policy: <verbatim or near-verbatim policy text + URL — if you cannot quote it, the requirement is not from policy>
  Suggested implementation: <engineering option(s), explicitly prefixed "non-policy, auditor's suggestion only" — or "None">
  Deadline: <policy enforcement date if applicable, else "Active">

Hard constraints (main agent MUST enforce before emitting the report):

1. Missing reference — A finding without both Reference: and Policy Source: is invalid. Drop it.
2. Declaration gate consistency — If Declaration Channel ≠ None AND Declaration Status = Unknown, then status: MUST be NEEDS_CONFIRMATION. Findings that violate this are invalid; downgrade or drop.
3. Policy-quote consistency — If Required by policy: does not contain a quote from a policy URL (or paraphrases beyond recognition), the policy basis is fabricated. Drop or downgrade to INFO.
4. Prescription leakage — If Required by policy: contains specific implementation mechanisms (sender allow-lists, particular APIs, SP-key names, server-side filter requirements) that do not appear in the policy text, move that content to Suggested implementation: before emitting.

Example A — absolute prohibition, no declaration channel:

[GP-00101] status: BLOCKER
  Category: 14.3 — Loan Harassment: prohibited data for credit scoring
  Finding: App self-discloses that user SMS content feeds the credit-scoring model.
  Evidence:
    - app/src/main/res/values/strings.xml:9 — discloses SMS data used for "evaluación crediticia"
    - app/src/main/java/.../AppInfoR.kt:79-86 — SMS body uploaded under field SP_SMS to api.example.com/uploadInfo
  Reference: loan-harassment.md#14.3
  Policy Source: https://support.google.com/googleplay/android-developer/answer/9876821#personal-loans
  Declaration Channel: None
  Declaration Status: Not Applicable
  Required by policy: Personal Loans apps may not use prohibited data sources (including SMS data) for credit underwriting decisions. See Personal Loans Policy (URL above).
  Suggested implementation: None — the policy prohibition is on the use case itself; HOW the developer separates legitimate SMS use cases (e.g., OTP, transaction alerts) from credit scoring is the developer's choice.
  Deadline: Active

Example B — declaration-gated policy, status unknown:

[GP-00102] status: NEEDS_CONFIRMATION
  Category: 11.4 — Spyware Cat.4 (Personal SMS exfiltration)
  Finding: App reads SMS via Telephony.Sms.CONTENT_URI and transmits filtered rows to a backend; auditor cannot determine from static review whether the actually-transmitted set excludes non-financial or personal SMS.
  Evidence: app/src/main/java/.../SmsHelper.kt:42-88 — query + LIKE filter + POST /api/sms/sync (body field included)
  Reference: spyware-policy.md#114-category-4-personal-smscall-log-exfiltration-critical-for-loan-apps
  Policy Source: https://support.google.com/googleplay/android-developer/answer/14745000
  Declaration Channel: Permissions Declaration
  Declaration Status: Unknown
  Required by policy: "Personal loans or budgeting apps exfiltrating or sharing non-financial or personal SMS history of a user." (Spyware policy — URL above). All SMS use cases also require Permissions Declaration approval per SMS/Call Log policy.
  Suggested implementation: None — auditor judges only the outcome (whether non-financial/personal SMS leaves the device). The developer chooses the mechanism.
  Deadline: Active
  Resolution requires: (a) Permissions Declaration status (Confirmed/Pending/Rejected), and (b) evidence that the actually-transmitted SMS set contains no non-financial or personal records.

Severity definitions:

• BLOCKER: App will be rejected or removed. Auditor has direct evidence of policy violation. Must fix before submission.
• WARNING: May trigger review delay or future enforcement. Fix recommended.
• INFO: Best practice improvement. No immediate enforcement risk.
• NEEDS_CONFIRMATION: Code triggers a declaration-gated policy, but the declaration status or actual outcome cannot be determined from static review. The auditor MUST NOT escalate to BLOCKER/WARNING without (a) declaration evidence from the developer/Play Console, and (b) evidence that the actual runtime outcome meets the policy. Reported in a separate section of the final report, never mixed into BLOCKER/WARNING tallies.

Reference File Index (all 14 must be loaded for a full audit)

Each reference file contains the full policy details, code audit commands, and checklists for its topic. Per the Execution Contract, an auditor MUST load all 14 files during a full audit and MUST explicitly mark any file as "Not Applicable" in the Coverage Report if they skip it.

Reference Coverage Report (mandatory output)

Emit this table once, at the end of the audit report, immediately before the Launch Day Checklist. Fill in every row.

## Reference Coverage Report

| # | Reference | Loaded | Findings | Notes |
|---|-----------|--------|----------|-------|
| 1 | build-and-signing.md | ✅ | <N> | — |
| 2 | permissions.md | ✅ | <N> | — |
| 3 | financial-declaration.md | ✅ | <N> | — |
| 4 | data-privacy.md | ✅ | <N> | — |
| 5 | store-listing.md | ✅ / ⏭ Not Applicable | <N> | <reason if N/A> |
| 6 | deceptive-behavior.md | ✅ | <N> | — |
| 7 | spyware-policy.md | ✅ | <N> | — |
| 8 | device-abuse.md | ✅ | <N> | — |
| 9 | consent-flow.md | ✅ | <N> | — |
| 10 | loan-harassment.md | ✅ | <N> | — |
| 11 | deployment.md | ✅ | <N> | — |
| 12 | code-audit.md | ✅ | — | Used as grep pattern source |
| 13 | intellectual-property.md | ✅ | <N> | — |
| 14 | restricted-content.md | ✅ | <N> | — |

Coverage: <M>/14 loaded, <K> marked Not Applicable
Total findings: <T> (<B> BLOCKER, <W> WARNING, <I> INFO)
Pending confirmation: <N> NEEDS_CONFIRMATION (not part of the verdict; require developer evidence to resolve)

Loaded column values:

• ✅ — Reference was read and findings (or a clean result) were produced.
• ⏭ Not Applicable — Reference was read, but scope does not apply. Must include reason in Notes.
• ❌ Skipped — Any row with this value means the audit is incomplete and the report must be treated as a draft, not a decision.

19. Launch Day Checklist (Final)

## Pre-Submit
- [ ] Target API level >= 35
- [ ] AAB format (not APK)
- [ ] R8/ProGuard enabled, resources shrunk
- [ ] Version code incremented
- [ ] ProGuard mapping saved
- [ ] SMS/Call Log permissions: either removed, or Permissions Declaration Form submitted with exception approval
- [ ] Personal loan apps: no prohibited permissions (contacts, photos, phone numbers, fine location)
- [ ] `READ_CONTACTS`: if declared, Contact Picker evaluated and documented as insufficient (effective Oct 28, 2026, Android 17+)
- [ ] One-time precise location uses `onlyForLocationButton` flag; persistent precise location has Play Developer Declaration
- [ ] Geofencing uses Geofence API, not a foreground service
- [ ] All foreground services have declared types

## Play Console
- [ ] App signing configured (Play App Signing)
- [ ] Store listing complete (icon, screenshots, descriptions)
- [ ] Financial Features Declaration completed
- [ ] Content rating questionnaire completed
- [ ] Data Safety form completed (ALL SDKs audited)
- [ ] Privacy policy URL active and linked
- [ ] Account deletion web link provided
- [ ] Contact email configured
- [ ] Pricing & distribution set (free/paid, target countries, in-app purchases declared)
- [ ] All Permissions Declaration Forms submitted

## Financial App Specific
- [ ] App category = "Finance"
- [ ] Loan terms in app description (APR, repayment, representative cost)
- [ ] Licensing documents uploaded for target countries
- [ ] No short-term loans (< 60 days)
- [ ] No access to photos/contacts for lending decisions — applies to loan apps, accessory loan/credit apps (calculators, guides), and EWA apps (SMS governed by Section 3.1 exception policy)
- [ ] EWA apps: fees transparent ($1–$5 or 1–5%), no debt creation, no credit bureau reporting

## Spyware & Privacy (Section 11)
- [ ] Prominent disclosure shown BEFORE any data collection or SDK init
- [ ] User can DECLINE data collection and still use basic functionality
- [ ] No SDK transmits data before user consent
- [ ] No non-financial or personal SMS history exfiltrated or shared (loan/budgeting apps)
- [ ] All collected data types disclosed in consent + privacy policy + Data Safety
- [ ] No data collection unrelated to app functionality
- [ ] No background data uploads without user-visible notification

## Deceptive Behavior (Section 10)
- [ ] No system UI mimicry
- [ ] No hidden functionality or remote code execution
- [ ] Disclosure-vs-reality gap audit passed (all collected data is disclosed)
- [ ] No behavior changes based on undisclosed server flags

## Device Abuse (Section 12)
- [ ] No device settings modification
- [ ] No accessibility service abuse
- [ ] No autonomous action initiation/planning/execution via Accessibility API (Oct 2025 update)
- [ ] No app interference or preventing uninstallation
- [ ] App respects FLAG_SECURE set by other apps (no screen capture of secure content)

## Loan App Harassment (Section 14)
- [ ] No contact access for debt collection
- [ ] No automated messages to user's contacts
- [ ] No threatening/shaming language
- [ ] Prohibited data NOT used for credit scoring

## Consent Flow (Section 13)
- [ ] Consent → Permission → Collection order verified
- [ ] Each permission denial handled gracefully
- [ ] Loading indicator during data uploads
- [ ] Third-party data sharing disclosed

## Policy
- [ ] No deceptive behavior
- [ ] Permissions minimal and justified
- [ ] Account deletion available in-app and via web link
- [ ] Privacy policy matches Data Safety declarations
- [ ] No trademark / copyright / counterfeit issues (IP section) — no unauthorized bank, lender, or regulator logos
- [ ] No restricted content in strings, notifications, or store listing (RC section) — especially no harassing / shaming language in collection notifications

## Testing
- [ ] Internal testing track verified
- [ ] Closed testing track passed review
- [ ] Pre-launch report reviewed (no critical issues)
- [ ] Tested on Pixel devices
- [ ] No crashes or ANRs above threshold

## Submit
- [ ] Release notes written (what's new)
- [ ] Staged rollout configured (start at 10-20%)
- [ ] Monitoring dashboards ready
- [ ] Review response team alerted

20. Common Rejection Reasons & Fixes

How to use this table: It is a quick reference for the most common compliance paths — NOT a finding template. When drafting an actual finding, use the Output Format above and per Rule 6 separate the Fix content below into:

• Required by policy: — only the outcome-level requirement that maps to verbatim policy text (e.g., "stop using SMS data for credit underwriting").
• Suggested implementation: — any specific mechanism listed below (e.g., "switch to Photo Picker", "use Geofence API", "delete the manifest entry") — prefixed "non-policy, auditor's suggestion only".

The Fix column may bundle both for brevity; the Output Format must keep them apart.

21. Key Policy Deadlines (2025-2026)

References

• Policy Announcement: July 15, 2026
• Google Play Developer Program Policy
• Policy Deadlines
• Policy Announcements
• Financial Features Declaration (may redirect — see Financial Services Policy for current guidance)
• Financial Services Policy
• Permissions and APIs that Access Sensitive Information
• SMS/Call Log Permission Policy
• Permissions and APIs that Access Sensitive Information (Updated)
• QUERY_ALL_PACKAGES Permission Policy
• Photo and Video Permissions Policy
• Foreground Service Requirements
• Account Deletion Requirements
• Data Safety Form Guide
• Android Developer - Foreground Service Types
• Policy Announcement: April 10, 2025
• Policy Announcement: July 17, 2024
• Policy Announcement: July 10, 2025
• Policy Announcement: April 15, 2026
• Understanding restricted permissions with minimum scope alternatives
• Contact Picker: Privacy-First Contact Sharing — Android Developers Blog
• Redefining Location Privacy — Android Developers Blog
• Android Developer - Default Handlers
• Spyware Policy
• Understanding Spyware Policy
• Deceptive Behavior Policy
• Device and Network Abuse Policy
• User Data Policy
• Prominent Disclosure Requirements
• Personal Loans Policy
• Stalkerware Policy
• Intellectual Property Policy
• Google Play Developer Program Policy — Restricted Content

For OWASP-level code security audit, see the security-audit skill.