Assemble the submission packet
Create a folder or internal record containing the release identity, artifact checksum, signing fingerprint, store copy, images, policy URLs, data-flow inventory and reviewer instructions. Exclude credentials from broadly shared copies.
Check current target-API and native compatibility requirements before building. A bundle that uploads successfully can still have review or publication blockers.
Match each declaration to evidence
| Declaration | Evidence to inspect |
|---|---|
| Ads | Actual SDKs and placements, including mediation |
| Data Safety | On-device and off-device flows, vendor disclosures |
| Target audience/content rating | Real content, interactions and intended users |
| App access | A working route into all restricted features |
| Sensitive permissions | Core use case and applicable approval conditions |
Do not copy the answers from a different app simply because both use the same framework. Backend features and configuration can change the correct response.
Confirm account-specific access gates
New personal developer accounts may need closed testing and production-access approval. Identity verification and required contact details are separate from app review. Inspect the account's Dashboard tasks instead of assuming every account follows an identical sequence.
The current app creation guide is the starting point for setup, and review preparation explains the app-content work.
Review the candidate as a user
Install the production-like build, follow the listing's promised task and compare the result. Check privacy/deletion links on a mobile browser. Confirm screenshots represent the current interface rather than an old prototype.
APKLint's policy checker can organize these questions and inspect declared characteristics. It cannot determine the state of your private Console or replace a functioning reviewer account.
Before submission, reconcile the candidate with the current target-API rules. Keep a record of what was submitted so a later notice can be investigated against the same version, not whatever happens to be on the developer's laptop.
Reconcile an optional feature across the submission
Imagine a scanner app whose local document processing is available to everyone while cloud synchronization requires an account. Walk both paths in the candidate. Check that the listing, privacy policy, Data safety answers and review instructions describe the same distinction. A declaration copied from the earlier local-only version can become wrong after synchronization is introduced.
Prepare a review account with safe sample documents and the entitlement needed to reach the restricted feature. Have another tester follow the supplied instructions from a clean profile. A successful login that leads to an empty or locked workspace does not demonstrate access to the feature under review.
Assign each gate to the person who can resolve it
A target-SDK rejection belongs to the artifact and build configuration; an unavailable production track can involve account eligibility; a broken privacy link belongs to the published web destination. Record the exact blocker and owner. Editing the app description is unlikely to solve a build or identity problem.
The review-preparation guidance and the app's current Dashboard identify the applicable setup work. Treat a completed form as a declaration to verify against the product, rather than evidence that the product automatically complies because the form saved.
Review remote configuration with the release package. If synchronization, advertising or account creation can be activated independently of the binary, include the planned launch settings in the evidence. The reviewer and end user should not receive materially different undocumented experiences.
Retain the submission's artifact checksum and a redacted snapshot of its declarations. If a policy notice arrives later, compare it with what was actually submitted and with any intervening server changes. The current local branch may no longer represent the reviewed state.
After approval, verify the publicly available listing and installation under the intended market and account conditions. Approval is one workflow state; it does not prove that every selected country, device or release timing setting matches the team's launch plan. Resolve those distribution details before announcing availability to the affected audience.
Sources and further reading
- Google Play: Create and set up your app
- Google Play: Prepare your app for review
- Google Play: Target API level requirements
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
