Triage each issue independently
Open the app's Policy status page and inspect the individual issue details. Record the policy, deadline, affected artifact or listing, available action and owner. Account-level notices and app-level issues may require different people to respond.
Do not combine several notices into one vague task called “fix policy.” A target-API deadline, a data disclosure mismatch and an inaccessible review account need different evidence.
Track state beyond a screenshot
| Internal state | Evidence needed |
|---|---|
| Investigating | Reproduction and affected release identified |
| Fix prepared | Code/configuration change and test record |
| Submitted | New release or declaration submitted through Console |
| Awaiting review | Submission state and any requested information |
| Resolved | Console outcome plus confirmation of the corrected product |
A saved form is not necessarily submitted. A submitted release is not necessarily published. Capture the actual transition rather than telling the team the issue is fixed as soon as a developer pushes code.
Handle deadline extensions carefully
Some policies provide an app-specific extension request. Use the action shown in the issue details and retain the response. A general announcement about available extensions is not approval for your app.
Where a requirement does not offer an extension, do not assume customer support will create one. Plan the remediation against the stated deadline and escalate missing evidence early.
Reconcile Console with the product
After resolution, check that the live listing, privacy links, runtime configuration and shipped bundle reflect the approved change. A remote rollback can reintroduce behavior without changing the version code.
APKLint's developer-policy checklist can support the internal register. It does not synchronize with your private Console or know whether Google has closed a case.
Use Google's enforcement documentation and the linked policy source, plus the specific notice in your account. Preserve an audit trail of decisions without storing passwords, identity documents or reviewer credentials in a public issue tracker.
Track two notices without merging their completion states
Suppose an app has a target-API notice and a separate app-access issue. The first needs an inspected replacement artifact or an applicable documented extension; the second needs a working review route. Assign separate owners, evidence and deadlines. Completing the new build does not show that the review account can open the restricted feature.
For each issue, copy the exact affected package and action into an internal record. Preserve the notice's case identifier and a redacted description of its requirements. Avoid copying authentication links or reviewer credentials into a public project board.
Reconcile the internal status with the actual submission
When an engineer reports the fix ready, link the tested artifact and reproduction result. When the release operator submits it, record the actual submission state. Keep the issue awaiting the appropriate outcome until the relevant Console state changes; a successful local test and an accepted submission are different observations.
Use the enforcement guidance together with the app-specific notice to understand the action. A general description of policy handling does not reveal the private state of this app or authorize an unlisted extension.
If a correction requires a web page, open its public destination after publication and inspect the exact link used by the installed app. A repository commit containing the new privacy text is insufficient when the live destination still serves an old page.
Before marking the issue closed internally, verify that the approved change and distributed configuration agree. For an access issue, repeat the documented route with the maintained review account. For the target change, confirm the actual uploaded release identity. Keep the evidence specific to the cited problem.
Record a recurrence trigger such as an authentication change, SDK upgrade or remote feature activation. Link a later recurrence to the earlier root cause while preserving the new notice's identity. This makes the status register useful for preventing repeated failures instead of a collection of screenshots that appear resolved while the product has changed underneath them.
Sources and further reading
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
