Start with the correct SDK disclosure
Identify whether the app uses the legacy Android SDK, Next-Gen SDK, Unity plugin or another wrapper. Read the disclosure guide for that implementation and version. Do not paste a legacy disclosure into a Next-Gen migration review without comparing it.
Google's current legacy guide documents automatically handled categories and optional configuration. That does not establish the correct form answer for every application using the SDK.
Add the app's own behavior
Review custom analytics events, account identifiers, crash metadata, remote configuration and any server-side ad reporting. A developer can add personal information to a payload even when the default SDK example does not.
| Change | Disclosure review |
|---|---|
| Add mediation network | Partner SDK, purposes and consent propagation |
| Remove AD_ID permission | Which identifier flow stops, and which remain |
| Enable optional reporting | Additional fields and recipients |
| Add child audience | Audience-specific SDK and data restrictions |
| Change consent behavior | Collection timing and available user choice |
Do not equate non-personalized advertising with no data processing. Similarly, encrypted transport is a security property, not proof that the app collects nothing.
Reconcile the three user-facing records
The Data Safety form, privacy policy and in-app consent/disclosure experience should agree. A policy saying analytics is optional needs a real implemented choice. A form claiming no sharing needs support under Google's definitions and exceptions, not just the fact that the SDK is a service provider.
Keep a versioned review record
Save the dependency inventory, vendor references and relevant configuration alongside the release. Recheck after adapter upgrades or remote feature changes.
APKLint's Data Safety Helper can structure the questions and highlight declared signals. It cannot observe every request or decide legal classifications for your business.
Use Google Mobile Ads data disclosure together with Play's Data Safety definitions. Treat a copied form answer without version and configuration evidence as an unresolved review item, not a reusable compliance template.
Trace one disclosure answer back to its implementation
Start a release worksheet with the SDK family and exact resolved version. For each relevant data category, record the component involved, purpose, destination and controlling setting. Add the source reference and the date reviewed. This makes a later answer change explainable when the app adds a mediation partner or enables an optional reporting feature.
The legacy Mobile Ads disclosure page identifies its version scope and describes automatic and configuration-dependent behavior. At this review it addresses legacy version 25.5.0. Treat that scope as part of the evidence: it is not a substitute for reviewing another SDK family, an older release or additional partner code.
Review an optional account label separately
Imagine that the app's own analytics wrapper adds a signed-in account label to an advertising diagnostic event. Even if a vendor's default example omits that label, the application has introduced another data flow. Identify the field's purpose and recipient, then decide whether it is actually needed. Removing an unnecessary field is a concrete implementation change; renaming it anonymous does not alter its contents.
Compare three runs using synthetic data: before the relevant choice, after the choice and after withdrawal where supported. Observe the app-controlled event construction and the available runtime diagnostics. Document limits of the observation: an unobserved request in a short session does not prove that a delayed or background path never transmits data.
Reconcile each intended form answer with Google Play's Data safety definitions, the privacy policy and the implemented user controls. The meanings of collection and sharing require the current definitions and the application's actual circumstances. A packet destination alone does not decide every classification or exception.
Have the release review retain both the worksheet and the built artifact's dependency inventory. When a setting changes remotely, reassess the affected rows even if no new APK was uploaded. This ties the disclosure to the behavior users can receive, rather than to a one-time source review that silently becomes outdated after account-side configuration changes.
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
