On this page · 12 sections
- What the Play Age Signals API is
- Why this landed now: the legal driver
- How the request flow works
- The userStatus values, and what to do with each
- Custom age ranges
- Handle errors like a runtime dependency, not a sure thing
- What you may and may not do with the signal
- Play Age Signals vs Apple's Declared Age Range vs rolling your own
- India-specific considerations
- How eCorpIT can help
- FAQ
- References
Summary. The Google Play Age Signals API (beta) lets an Android app read a user's age range and verification status at runtime without collecting a birthday, an ID document or a face scan. You add one dependency, com.google.android.play:age-signals:0.0.3, call checkAgeSignals, and read a userStatus plus an ageLower and ageUpper band. Google returns the default bands 0-12, 13-15, 16-17 and 18+. It started returning signals for users in Brazil on 17 March 2026 and for eligible Texas users whose accounts were created after 28 May 2026, part of compliance with the Texas App Store Accountability Act (SB 2420). Google has said it will reach Australia and Canada by mid-August 2026 and every remaining market by the end of 2026. The stakes are real: under India's Digital Personal Data Protection (DPDP) Act 2023, breaching the children's-data obligations can draw penalties of up to ₹200 crore, and a child is anyone under 18. This guide covers the SDK setup, the request flow with code, every userStatus value, custom age ranges, error handling, and the buy-versus-build call for age assurance.
What the Play Age Signals API is
The Play Age Signals API is a runtime interface with the Google Play Store. Your app calls it, and the Play Store runs its own processes to return an age signal. The API only returns data for users in regions where Play is legally required to provide age-category data, so it is a compliance tool first and a personalisation tool second. It is supported on phones, foldables and tablets running Android 6.0 (API level 23) and higher.
The design goal is data minimisation. Instead of asking a 14-year-old to type a birthday your app then has to store and protect, the app receives a coarse age band that Google already holds, and a status that says how that band was established. Apple shipped a comparable Declared Age Range approach, and both systems exist because a wave of app-store age-assurance laws now require developers to know, at least approximately, whether a user is a minor.
Why this landed now: the legal driver
The Texas App Store Accountability Act (SB 2420) was signed on 27 May 2025. It requires app stores to verify a user's age at account creation, obtain parental consent for anyone under 18 before a download or in-app purchase, and share age and consent information with developers. It also requires developers to assign an age rating using four bands: under 13, 13-15, 16-17, and 18 and over, the same bands the API returns. After the Fifth Circuit stayed a preliminary injunction and the US Supreme Court cleared the way for enforcement in July 2026, the law took effect while litigation continues. Utah passed its own App Store Accountability Act in 2025, and more US states are following.
For app teams the practical result is that age assurance is no longer optional in several markets, and the Play Age Signals API is Google's supported way to receive the signal rather than building your own age-collection flow that then becomes a data-protection liability.
How the request flow works
The integration is small. Add the dependency to your module build.gradle:
implementation 'com.google.android.play:age-signals:0.0.3'
Then create a manager and call checkAgeSignals. The call is asynchronous and returns an AgeSignalsResult.
val ageSignalsManager =
AgeSignalsManagerFactory.create(applicationContext)
ageSignalsManager
.checkAgeSignals(AgeSignalsRequest.builder().build())
.addOnSuccessListener { ageSignalsResult ->
val installId = ageSignalsResult.installId()
if (ageSignalsResult.userStatus() ==
AgeSignalsVerificationStatus.SUPERVISED_APPROVAL_DENIED) {
// Disallow access to the gated experience
} else {
// Handle VERIFIED, DECLARED, SUPERVISED and the rest
}
}
Request a fresh response when your app opens, because the values can change, and Google updates a user's cached age signals within two to eight weeks of their birthday. Google also recommends calling the Play Integrity API alongside Age Signals so you can confirm the request comes from an untampered build on a certified device, which protects the response from spoofing.
The userStatus values, and what to do with each
The response is driven by userStatus, with ageLower (0 to 18) and ageUpper (2 to 18) giving the band. This is the table to design your gating logic around.
| userStatus | What it means | What your app should do |
|---|---|---|
| VERIFIED | Google verified the age via a government ID, credit card or facial age estimation | Trust ageLower/ageUpper; gate confidently |
| DECLARED | The age was declared by the user, a parent or a guardian | Use the band; treat as self-attested |
| SUPERVISED | A supervised Google Account managed by a parent who set the age | Use the band and mostRecentApprovalDate |
| SUPERVISED_APPROVAL_PENDING | A supervised account with a change awaiting parent approval | Hold the gated feature until approved |
| SUPERVISED_APPROVAL_DENIED | A supervised account where the parent denied a change | Disallow the gated experience |
| UNKNOWN | Age unknown but the user is in a regulated region | In US states, ask the user to visit the Play Store to resolve status |
| null | User is outside a regulated region, or does not share age | Fall back to your default experience |
A SUPERVISED response also returns an installID, a Play-generated identifier used only to notify you if a parent later revokes app approval. In Brazil the possible values narrow to DECLARED, UNKNOWN or null; in applicable US states you can also see VERIFIED and the three SUPERVISED states.
Custom age ranges
The default bands are 0-12, 13-15, 16-17 and 18+, but you can define your own on the Age signals page in the Google Play Console. You may set up to three minimum ages, they must be at least two years apart, and you can change them once a year. If you set minimum ages of 13 and 17, for example, a 13-to-16-year-old returns ageLower = 13 and ageUpper = 16, and a 17-year-old returns ageLower = 17. Match the thresholds to the ages your app actually needs to distinguish rather than carrying all four default bands you will never branch on.
Handle errors like a runtime dependency, not a sure thing
Because the API depends on the Play Store and Play Services, calls fail for ordinary reasons: an outdated Play Store, no network, or an app not installed by Google Play. Design a bounded retry rather than blocking the user.
| Error | Code | Retryable |
|---|---|---|
| API_NOT_AVAILABLE | -1 | Yes, ask the user to update the Play Store |
| PLAY_STORE_NOT_FOUND | -2 | Yes, ask the user to install or enable Play |
| NETWORK_ERROR | -3 | Yes, ask the user to check connectivity |
| CANNOT_BIND_TO_SERVICE | -5 | Yes, retry with exponential backoff |
| APP_NOT_OWNED | -9 | No, the app was not installed by Google Play |
| SDK_VERSION_OUTDATED | -10 | No, ship an app update using a newer SDK |
For an in-session user, retry with a maximum attempt count as the exit condition so a transient failure does not break the flow. Errors -9 and -10 are not retryable and need a code or install fix instead.
What you may and may not do with the signal
The terms of service are strict, and misuse can end your API access and get an app removed from Google Play. You may use the signal only to provide age-appropriate content and experiences in compliance with laws. You may not use it for advertising, marketing, user profiling or analytics. The Play Age Signals client library collects no data itself, but you still own the Data safety declaration for whatever you do with the response, and you remain responsible for compliance with the Age Signals API and User Data policy.
Play Age Signals vs Apple's Declared Age Range vs rolling your own
Age assurance is now a cross-platform problem, so the honest comparison is three-way.
| Approach | Data collected from the user | Coverage | Maintenance burden |
|---|---|---|---|
| Play Age Signals API | None; Google returns a band | Regulated regions, expanding to worldwide by end 2026 | Low; an SDK call and gating logic |
| Apple Declared Age Range | None; the OS returns a range | Apple platforms | Low; a platform API |
| Build your own age gate | Birthday, ID or face scan you must store | Wherever you build it | High; you own the data and its risk |
The platform APIs win on data-protection risk because you never hold the sensitive identifier. Building your own age gate is only worth it when you operate somewhere neither store yet covers, and even then the collected data becomes a liability you have to secure. For teams shipping on both stores, the clean pattern is a single internal age-assurance layer that reads Play Age Signals on Android and the Declared Age Range on iOS, then applies one gating policy, as covered in our App Store age-assurance readiness guide and our enterprise mobile app development playbook.
India-specific considerations
India is not yet a region where the Play Age Signals API returns data, but the direction of travel is clear. Under the DPDP Act 2023 a child is anyone under 18, and a data fiduciary must obtain verifiable parental consent before processing a child's personal data, with behavioural monitoring and targeted advertising to children prohibited. The DPDP Rules were notified on 13 November 2025, with substantive obligations due by 13 May 2027, and breaches of the children's-data provisions can draw penalties of up to ₹200 crore. Indian teams building for a mixed global and domestic audience should design the age-assurance layer now, wire Play Age Signals for regulated markets, and keep the parental-consent flow ready for DPDP, the same architecture we describe in our DPDP consent manager readiness guide. Track Google's rollout, since India could become an applicable region as its rules mature, and align with the wider Google Play policy changes for 2026 and Android developer verification timelines.
How eCorpIT can help
eCorpIT is a Gurugram-based, senior-led engineering organisation, founded in 2021 and certified for CMMI Level 5, MSME and ISO 27001:2022. We build age-assurance layers that read Play Age Signals on Android and the Declared Age Range on iOS behind one gating policy, add Play Integrity checks, and design applications aligned with DPDP Act 2023 and US app-store requirements. If you need to ship compliant age gating without turning it into a data-protection liability, contact us for a scoped review.
FAQ
References
_Last updated: 1 August 2026._
