AdMob 25’s UMP dependency deserves its own QA note

Consent behaviour should not disappear inside a generic “ad SDK updated” release note. The AdMob 25 dependency change provides a specific version to trace through the application and its configured user journey.

Inspect the resolved dependency

Our recommendation is to check the build’s resolved UMP version rather than assuming that a dependency declaration tells the whole story. Identify any explicit overrides and the component responsible for presenting or refreshing the consent flow.

Then exercise the product states the team has approved for testing. Record geography or test configuration, prior consent state, app version and the resulting behaviour. A screenshot of a dialog is not enough to establish what happens after dismissal, on a later session or before an ad request.

Keep the claim proportionate

This change record establishes a documented dependency update. It does not establish that the new dependency changes consent rates, improves revenue or makes a game compliant with every applicable requirement. Those conclusions would need separate evidence and review.

For growth teams, the useful request is a release note that identifies what was tested and whether measurement or delivery configuration changed alongside it. If acquisition results move after release, that record makes diagnosis more disciplined. It does not turn the timing of a release into proof of causation.

The governing record is Android release notes — 25.0.0 dependency update. This edition checks the provider documentation; it does not inspect a studio account or certify a shipped build.

Inspect the evidence

Download the applicability and deadline record. The extraction separates documented facts from our analysis and unknowns.

Further reading in the existing archive: Privacy by design in UA data flows; Every platform privacy change is a pricing change. These links provide background; this check does not independently verify their full contents.