· 9 min read

Google's Play Age Signals API Goes Global by December — Texas Already Made It Non-Optional

Tools Building in Public

Google Play started returning age-band signals to eligible Texas app accounts back in late May, quietly, ahead of a state law that carries $10,000-per-violation penalties. On July 29, Google made the same tool (the Play Age Signals API) a global commitment: Brazil already has it, Australia and Canada get it by mid-August, and every market gets it by the end of 2026. If you ship an Android app, this stopped being a "read about it later" story the day Texas started enforcing.

What the API actually does

The Play Age Signals API gives your app an age band instead of a birthdate. The default bands are 0-12, 13-15, 16-17, and 18+, and you can customize them: Google lets you set up to three minimum ages for your app in Play Console, spaced at least two years apart, changeable once a year. No date of birth, no ID scan, no selfie. You call the API at runtime, and if the user (or their parent) has chosen to share an age signal, you get the band back.

That "chosen to share" part matters. Age ranges are not shared by default. Parents opt their kids in once, centrally, inside Family Link (Google's parental-controls app) rather than app by app. Adults can share their own age range when an app prompts them for it. Either way, nothing reaches your app until someone actively agrees to hand it over. This is the same shape as what Apple already shipped: Apple rolled out its own age-verification tools globally back in February. Google is roughly five months behind on the "worldwide" part, though it's been live for specific jurisdictions since March.

One restriction worth flagging before you integrate: if you use the Age Signals API at all, Google's global privacy terms kick in, and you're barred from using the age signal for targeted ads or handing it to third-party analytics providers, regardless of where your users are. That's not a regional carve-out: it applies everywhere you use the API, even in markets with no age-verification law at all.

The rollout timeline, and who's actually driving it

Brazil got the API on March 17, 2026, tied to the country's Digital ECA child-safety statute. Texas got it for new accounts created after May 28, 2026, tied to SB 2420, the state's App Store Accountability Act. Australia and Canada are next, mid-August. Everyone else, including the rest of the US, gets it by December 31.

Notice the pattern: every date on that list maps to a law, not a product milestone. Google isn't rolling this out because age-band signals were sitting in a backlog waiting for their turn. It's rolling out region by region as regulators force the issue. Texas's law took effect June 4 after the Fifth Circuit lifted a five-month injunction, survived an emergency Supreme Court challenge in early July, and is now headed to an expedited Fifth Circuit hearing on the First Amendment question in August, while it stays fully enforceable in the meantime. Other states have similar app store accountability bills moving through their legislatures. This is the actual driver, and it's why "worldwide by year-end" reads more like a compliance deadline Google set for itself than a roadmap item.

The part that trips people up: optional API, non-optional law

Google's own language here is careful. Play Console's developer documentation says flatly that Google Play doesn't mandate use of the Age Signals API: you're free to integrate it or not, and Google frames it as one tool among several for delivering age-appropriate experiences. That's true, narrowly. Nobody at Google is going to reject your app binary because you didn't call this specific API.

But the laws behind the rollout don't care which API you use: they care whether your app complies. Texas SB 2420 requires app stores to sort every new account into an age category (under 13, 13-15, 16-17, 18+) and requires linked parental consent for minors before downloads or purchases go through. Developers who don't implement the required compliance stack face civil penalties up to $10,000 per violation. If your app has any age-gated feature (social features, chat, purchases, content filtering) and you have Texas users, the practical reality is that you need an age signal from somewhere, and Google's API is the path of least resistance since the platform already built it for you. "Optional" is the honest word for the API. It is not the honest word for the underlying obligation once your state, or country, has a law like this on the books.

What indie devs need to do now

Start by figuring out whether you actually have age-gated surface area. Chat, user-generated content, in-app purchases, anything remotely social or transactional: that's the stuff regulators care about. A single-player utility app with no social layer has much less exposure than a messaging or marketplace app, and the amount of work scales accordingly.

If you do have age-gated features, the integration itself is small (a runtime API call and a response you branch on), but the fallback UX is the part people skip and then scramble on later. What does your app show a user who declines to share an age signal? What happens to a user in a region where the API isn't live yet, but who might be a minor? You want that fallback decided and built before your region's date hits, not improvised the week a Play Console policy email shows up in your inbox. Set a calendar reminder for your target markets' rollout dates now (mid-August for Australia and Canada, year-end for everywhere else) and don't treat "worldwide by year-end" as a soft deadline. Waiting for a warning email is how solo devs end up doing this integration under a policy strike instead of on their own schedule.

What I'd actually do

If you have zero age-gated features, ignore this for now and revisit it if that changes. There's no reason to build against an API you don't need. If you do have age-gated features and any meaningful US user base, I'd integrate this quarter, not wait for December. Texas is enforceable today, other states are lining up behind it, and the cost of building the fallback UX under deadline pressure is much higher than building it now while nobody's watching. The actual dev work (one API call, a UI branch for "no signal available," a UI branch for each band you care about) is a day, maybe two, for most small apps. That's cheap insurance against a $10,000-per-violation exposure you didn't know you had.

The honest counter-take: Texas SB 2420 is still in active litigation, and the First Amendment challenge could plausibly gut it before the Fifth Circuit rules on the merits. If that happens, some of the US regulatory pressure eases, and "worldwide by year-end" starts looking more like Google's own product timeline than a legal necessity. I don't think that's a good reason to wait, though: Brazil's law isn't in dispute, other US states aren't waiting on the Texas outcome to file their own versions, and the API integration cost is low enough that building it now and having it sit unused in a friendlier legal environment is a much better failure mode than needing it in October and not having it.

Author

Lukas

Sources

More Tools articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts