AdMob’s age-treatment API change needs a product decision

The age-treatment API change should be reviewed jointly by the people who own the game’s audience handling and the people who maintain its ad integration. Replacing a method name is only the implementation part of that work.

Preserve the decision behind the setting

Our recommendation is to document the intended treatment for each relevant product state before changing the SDK call. Include the point at which the application knows the required information and what it does while that information is unavailable. The implementation should follow the approved behaviour rather than inventing it inside an upgrade ticket.

A useful review compares the old and new request configuration for a controlled set of states. Record the build and dependency versions, the inputs supplied and the resulting configuration. A test should not require collecting unnecessary personal information from real players.

Avoid an automatic compliance claim

The release note documents an interface change. It does not certify a particular game’s age assurance, consent flow or legal compliance. Keep those questions assigned to the appropriate accountable owners.

For acquisition planning, the immediate action is to ensure that the launch build and audience promise are aligned. Do not infer from a new API that a campaign can suddenly target an additional audience. Close the SDK task only when the team can explain and verify the product behaviour it implements.

The governing record is Android release notes — 25.3.0. 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: COPPA and kids' privacy for game marketers; Privacy by design in UA data flows. These links provide background; this check does not independently verify their full contents.