By ByteBot
Google’s Play Age Signals API is expanding to Australia and Canada this month, with a full global rollout locked in before end of 2026. The API — already live in Brazil since March and Texas since May — gives Android apps an age band for users without the app collecting a birthdate or government ID. Apple did the same in February. If your app reaches anyone under 18, this is the compliance infrastructure both platforms are building toward, and the window to implement proactively is narrowing.
How the API Works
Parents set their child’s age once inside Google Family Link. From that point, any app using the Play Age Signals API can call it at runtime and receive a band — 0–12, 13–15, 16–17, or 18+. The app never sees the birthdate, and the age signal isn’t shared between apps. It’s a privacy-preserving layer sitting between Google and your app.
The response has a few useful fields beyond the band. The ageRangeSource field tells you how confident to be in the signal: TIER_A is self-declared, TIER_D is government ID plus biometric verification. If a user hasn’t shared their age at all, every field returns null. You’ll need to define what your app does in that case — the safe default for regulated use cases is to treat unknown age as a minor.
Where It’s Live Now
The rollout timeline matters because different laws are driving each market:
- Brazil — Live since March 17, 2026 (Digital ECA compliance)
- Texas — Live since May 28, 2026 for accounts created after that date (SB2420)
- Australia and Canada — Rolling out mid-August 2026
- All markets — End of 2026
The Texas law (SB2420) is the current US pressure point. Utah and Louisiana had compliance dates of January 1, 2026. More US states are following the same pattern, and Google has committed to updating the API in advance of each new jurisdiction’s enforcement date.
How to Implement
The integration is straightforward. Add the dependency to your app’s build.gradle:
implementation 'com.google.android.play:age-signals:0.0.4'Then call the API at a point where you need to gate behavior — at login, at feature access, or on first launch:
val ageSignalsManager = AgeSignalsManagerFactory.create(context)
val request = AgeSignalsRequest.Builder().build()
ageSignalsManager.requestAgeSignals(request)
.addOnSuccessListener { result ->
when {
result.ageLower == null -> handleUnknownAge() // treat as minor
result.ageLower!! < 13 -> restrictToChildMode()
result.ageLower!! < 18 -> restrictToTeenMode()
else -> enableFullFeatures()
}
}
.addOnFailureListener { handleUnknownAge() }
The API is supported on Android 6.0 (API level 23) and above. Use FakeAgeSignalsManager in your test suite — real age signals can’t be tested on a development device.
Four more steps beyond the code itself: update your Google Play Console data safety form to reflect age signal usage, configure significant-change notifications requiring parental re-approval (rolling out in Play Console), review in-app purchase SKU age ratings for Texas compliance, and audit your ad SDK configuration to confirm behavioral ads aren’t served to under-18 bands.
The Single-Purpose Rule You Cannot Ignore
Google Play’s terms for Age Signals are strict: use the signal only to deliver age-appropriate experiences. Advertising, marketing, user profiling, analytics, and passing it to third-party SDKs are all prohibited. A violation terminates API access and can get the app suspended. If you have a data pipeline that collects everything the app knows about a user, age signals must not flow into it.
Apple Got There First — And That Sets the Standard
Apple launched its Declared Age Range API globally in February 2026, four months ahead of Google’s global expansion. Both APIs use opt-in parent-set bands, and both hand the app a range rather than a precise age. Google’s API adds one piece Apple doesn’t: the ageRangeSource tier, which tells you whether the age was self-declared or identity-verified. For apps that need higher assurance — financial services, certain health apps — that distinction matters.
The convergence of both major mobile platforms on the same privacy-preserving age verification model is a clear signal about where regulation is heading. Platform-level age verification is now infrastructure, not a feature. Apps that implement now control their own timeline. Apps that wait will implement under deadline pressure from a regulator or an app store policy update.
