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.
Represent consent startup as explicit transitions
For an illustrative app, distinguish checking information, presenting a required form, eligible to request ads and unable to request ads. The interface can show ordinary app content throughout the supported states. Do not collapse checking information into eligible merely to remove a loading indicator; the UI's desire to finish startup is separate from the SDK's permission to request advertising.
The UMP integration guide documents the update, form, eligibility and privacy-options APIs. Keep one guarded owner of advertising startup because more than one callback can reach an eligible state. In a test harness, count how many times that owner starts and assert that the normal first-launch flow reaches it at most once.
Exercise callbacks in an inconvenient order
Test a returning user whose available status permits ad requests while a fresh update is still running. Then allow the update and form callbacks to complete. Confirm that these later callbacks do not duplicate initialization or schedule a second load solely because the eligibility check returns true again. Also test navigation away from the original activity during the update.
For a clean test installation, interrupt connectivity before the update completes. Record the SDK's resulting eligibility state and the app's response. An error message should not be transformed into a consent grant. A retained status from a previous session and a fresh installation with no usable status are distinct test conditions.
Use the supported privacy-options entry point when required, change the available choice and return to the application. Verify that the control remains accessible and that subsequent advertising behavior follows the updated SDK state. Do not let a custom settings toggle merely change its label while leaving the underlying consent state untouched.
Keep debug geography and consent-reset controls in the testing path. Include a release-configuration check for their absence, and record which test state was intentionally simulated. These experiments validate the application's callback and interface behavior; they do not determine every legal requirement for the app's audience, countries or additional SDKs. Review those data flows separately before treating the whole product's privacy work as complete.
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
