Google is taking its age-verification plumbing worldwide. In a developer blog post published this week, the company said the Play Age Signals API reaches users in Australia and Canada by mid-August, with every remaining market following before the end of 2026. It has already been live in Brazil since March. The detail almost none of the coverage has picked up is that the API does not simply hand an app an age bracket. It also tells the app how that age was established, on a four-step scale running from "the user typed it in" to "government ID plus a selfie."

That distinction is the whole story. An age range sourced from a self-declaration is a suggestion. One sourced from a checked government ID is evidence. Google now ships both through the same call, labeled, and leaves each developer to decide what each one is allowed to unlock.

RelatedFlutter 3.44 adds agentic hot reload and GenUI

  • Rollout order. Live in Brazil since 17 March 2026 and for eligible Texas accounts since 28 May. Australia and Canada arrive by mid-August, the rest of the world later this year.
  • What comes back. An ageLower and ageUpper pair, with default buckets of 0-12, 13-15, 16-17 and 18+, plus an ageRangeSource tier describing how that age was established.
  • What you may not do with it. Google's terms bar using the signal for advertising, marketing, user profiling or analytics. Violations can cost API access and get the app pulled.
  • The silent case. If a user has not shared an age, every field returns null. There is no partial answer and no default to lean on.
The four AgeRangeSource assurance tiers in the Play Age Signals APIA ladder of four tiers. TIER_A is a user self-declaration, TIER_B is an age set by a parent or guardian, TIER_C is an age assessed by credit card, email, selfie or ID, and TIER_D is a government ID plus selfie or a digital ID. A fifth dashed row shows that when nothing is shared, every field in the response returns null. AGERANGESOURCE · HOW THE AGE WAS ESTABLISHED TIER_A User typed their own age TIER_B Set by a parent or guardian TIER_C Card, email or selfie check TIER_D Gov ID + selfie, or digital ID null Nothing shared: all fields null Same call, same bracket format. Only the tier tells you whether the number is worth trusting. genztech.blog
Fig 1 · API response The bracket is the easy part. The tier underneath it is what decides how much weight the bracket can carry.

What does the API actually return?

A developer calls into AgeSignalsManager and gets back an AgeSignalsResult. The age itself arrives as two integers: ageLower, from 0 to 18, and ageUpper, from 2 to 18. The upper bound comes back null for the top band, because 18+ has no ceiling. Google's default brackets are 0-12, 13-15, 16-17 and 18+, and an app can request custom ranges if those splits do not match the thresholds it has to enforce.

Alongside that sits ageRangeSource, the tier ladder in Fig 1, and a small set of fields aimed at supervised accounts. significantChangeStatus returns APPROVED, PENDING or DECLINED, which is how a parent signs off on a material change to an app a child already has installed, paired with a significantChangeApprovalDate. An installId string identifies supervised installs so an app can be told when approval is later revoked. Unsupervised accounts return null for all three.

Two status values cover the cases where there is nothing to hand over: NOT_SHARED, meaning the user has not agreed to share an age, and VERIFICATION_REQUIRED, meaning a check is still outstanding. Both collapse the entire response to nulls, tier included.

Which tier should gate which feature?

Google publishes the ladder but does not tell anyone what to do with it. That decision sits with the developer, and it is the one worth thinking through before writing the integration.

TierHow the age was establishedWhat it actually provesReasonable to gate on
TIER_AUser self-declaredIntent, not identity. Trivial to misstate.Default content filters, soft nudges
TIER_BSet by a parent or guardian via Family LinkAn adult in the household asserted itChild-account modes, chat and spend limits
TIER_CCredit card, email, selfie assessment, government ID or tax IDA real check happened, strength varies by methodMost regulated-content thresholds
TIER_DGovernment ID plus selfie, or a digital IDIdentity-grade assuranceAnything with legal exposure if you get it wrong

The practical trap is treating TIER_A as a pass. A self-declared 18+ is the same bracket a self-declared 13-year-old can produce in two taps, and any compliance argument built on it is thin. Reading the tier costs one extra field.

Why is Google shipping this now?

Because the laws arrived first, one jurisdiction at a time, and each one pushed the age check further down toward the app store. Google's own documentation names the statutes it is answering.

  1. 17 Mar 2026Brazil goes live First market to return signals, under the Digital ECA requirements
  2. 28 May 2026Texas accounts start returning signals Compliance with SB2420, with more US states planned
  3. 29 Jul 2026Worldwide expansion announced Android Developers Blog confirms the global timeline
  4. Mid-Aug 2026Australia and Canada Next two markets to switch on
  5. Late 2026Global rollout All remaining users, per Google's stated timeline

Apple is on the same track with its Declared Age Range and Significant Change APIs, for the same reason: when a legislature decides age checks belong at the store rather than inside each app, only two companies can implement it. That was precisely the architecture a US House subcommittee spent July debating across 19 online-safety bills. Google is now building the mechanism ahead of most of the legislation that would demand it.

What developers are explicitly not allowed to do with it

Here is the clause worth reading twice. Google restricts the signal to age-appropriate experiences and legal compliance, and prohibits using it for advertising, marketing, user profiling or analytics. The data may only be used by the app that requested it. Enforcement is stated plainly: violations can end API access and get the app suspended from Play.

RelatedBun Is Trialing a Full Rewrite From Zig to Rust

That matters because the usual fate of a new identity signal is to become an ad-targeting input within a release or two. A verified age bracket would be extremely valuable to an ad stack, which is exactly why the prohibition is written down rather than assumed. Whether it holds depends on enforcement nobody outside Google can audit, but the terms at least start in the right place.

What happens when the signal is not there?

Most of the time, probably nothing useful. Sharing is opt-in, parents control it through Family Link, and age ranges are never shared by default. Every app integrating this needs a real path for the null case, because that path is going to run constantly, especially in the first months of a market going live.

Google's own guidance points at the Play Integrity API to confirm calls are coming from an untampered app on a certified device. That is a reminder of what this system does and does not solve. It can tell an app that a parent set a child's age to 13-15. It cannot tell the app who is holding the phone.

Our take

The tier ladder is the genuinely good design decision here, and it is the part getting the least attention. A comparison being repeated in coverage of this launch has it backwards, claiming Google exposes only account status while Apple describes the assurance method. Google's own reference documentation lists four named source tiers. Read the docs, not the summaries.

The harder question is distribution. TIER_C and TIER_D require a real check that most users will never volunteer, so the bulk of live traffic will land at TIER_A or TIER_B, or return nothing at all. An app that gates a legally sensitive feature on any age signal it receives has not built compliance. It has built a log entry. The tier field is what turns the difference into something a developer can actually reason about, and ignoring it is the mistake this rollout is going to produce at scale.

What to watch · late 2026
  • Whether tier distribution ever gets published. Nobody outside Google can currently see what share of responses come back TIER_A versus TIER_D, and that ratio decides whether the system is useful or decorative.
  • Which US states land next. Texas was first. The documentation says more are planned, and each one arrives with its own thresholds.
  • Whether the advertising prohibition survives contact with the ad business. A verified age bracket is a valuable targeting signal, and the ban on using it that way is a policy line, not a technical one.
  • Australia's mid-August switch-on. It is the first market where a national under-16 regime and the store-level signal go live together, which makes it the closest thing to a real test.
Primary sources

Original analysis by GenZTech, based on Google's Android Developers Blog announcement and the Play Age Signals reference documentation.