Follow the session sequence
Request a consent-information update at app launch using the current UMP API. Load and show a required form through the documented helper, then check canRequestAds() before proceeding with ad initialization or requests that depend on that state.
Google's guide also checks eligibility immediately after requesting the update because a previous session may already provide usable consent status. Prevent both callbacks from starting duplicate initialization.
Refresh consent information
↓
Show a form when required
↓
Check canRequestAds()
↓
Initialize/request once through a guarded owner
This is a control-flow outline, not drop-in Kotlin. Use the implementation for your UMP and Mobile Ads SDK versions.
Handle errors without inventing consent
A network error does not mean the user agreed. Follow the documented SDK status behavior and check whether ads may be requested using the available state. Do not replace a failed update with true or reset production consent repeatedly until a form disappears.
Keep the app's non-ad functionality usable where appropriate rather than blocking the entire product behind an endless consent spinner.
Provide privacy options when required
Inspect the privacy-options requirement status and expose a clear, persistent entry point when the SDK requires it. Opening that control should present the supported privacy-options form, not a custom imitation that fails to update SDK state.
Test the branches deliberately
Use registered test devices and UMP's debug geography controls for development. Test acceptance, rejection, returning users, offline startup and reopening privacy options. Remove forced test geography and debug-only reset behavior from the production build.
For mediation, also verify partner-specific consent propagation and audience controls before initialization. UMP is not a blanket legal opinion about every SDK.
APKLint's advertising checker can help inspect related declarations, but it cannot observe the user's live consent status. Use the official UMP sequence and retain a tested state diagram with the release so later callback changes do not reintroduce duplicate requests.
Sources and further reading
Reference review: 22 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
