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 ageSignalsStatus 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 sharing 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.4, call requestAgeSignalsAccess, then checkAgeSignals, and read an ageSignalsStatus 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 said on 29 July 2026 that Australia and Canada would follow by mid-August and all users worldwide later in 2026, but its documentation still names only Brazil and Texas as live. 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 ageSignalsStatus value, custom age ranges, error handling, and the buy-versus-build call for age assurance.
Update, 2 November 2026. Google released library version 0.0.4 in July 2026. It adds a required requestAgeSignalsAccess step that returns ageSignalsStatus, and replaces the old user status field with ageRangeSource and significantChangeStatus, so this guide now follows 0.0.4. Version 0.0.3 still returns responses but gets no new updates. Google's mid-August target for Australia and Canada has passed, but its documentation still names only Brazil and Texas as live. California adds its own age signal duty from 1 January 2027: see our AB 1043 checklist.
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 returns data where Play is legally required to share age-category data and, elsewhere, when the user or a parent chooses to share it. The terms still limit it to age-appropriate experiences, so it is not a general personalisation tool. 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 source tier 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.4'
Then create a manager, call requestAgeSignalsAccess from an Activity, and when the status is SHARED call checkAgeSignals. Both calls are asynchronous, and the second returns an AgeSignalsResult.
// Inside an Activity
private fun requestAgeSignals() {
val ageSignalsManager =
AgeSignalsManagerFactory.create(applicationContext)
// Passing the Activity lets Play show its sharing prompt if needed
val accessRequest = AgeSignalsAccessRequest.builder()
.setActivity(this)
.build()
ageSignalsManager
.requestAgeSignalsAccess(accessRequest)
.addOnSuccessListener { accessResult ->
when (accessResult.ageSignalsStatus()) {
AgeSignalsStatus.SHARED -> readAgeSignals(ageSignalsManager)
AgeSignalsStatus.VERIFICATION_REQUIRED -> {
// Ask the user to visit the Play Store to resolve their status
}
else -> {
// NOT_SHARED: fall back to your default experience
}
}
}
.addOnFailureListener { exception ->
// Handle the error codes in the table below
}
}
private fun readAgeSignals(manager: AgeSignalsManager) {
manager
.checkAgeSignals(AgeSignalsRequest.builder().build())
.addOnSuccessListener { ageSignalsResult ->
val ageLower = ageSignalsResult.ageLower()
val ageUpper = ageSignalsResult.ageUpper() // null for the top band
val ageRangeSource = ageSignalsResult.ageRangeSource()
val installId = ageSignalsResult.installId()
// Gate on the band and source. Where significant changes apply,
// disallow the gated experience if significantChangeStatus is DECLINED
}
.addOnFailureListener { exception ->
// Handle the error codes in the table below
}
}
Request a fresh response when your app opens, because the values can change, and Google Play may delay passing on a new range after a birthday. Play shows its in-app prompt only a few times after a decline or dismissal, so do not count on it appearing on every open. 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 ageSignalsStatus values, and what to do with each
The flow is driven by ageSignalsStatus, with ageLower (0 to 18) and ageUpper (2 to 18) giving the band once the status is SHARED. Version 0.0.4 no longer supports the old userStatus field or its VERIFIED, DECLARED and SUPERVISED values. This is the table to design your gating logic around.
| ageSignalsStatus | What it means | What your app should do |
|---|---|---|
| SHARED | The user or parent agreed to share, or the user is verified or supervised where sharing is mandatory | Call checkAgeSignals, then gate on ageLower/ageUpper |
| NOT_SHARED | The user or parent declined, or the sharing setting is Never Share | No signals come back; fall back to your default experience |
| VERIFICATION_REQUIRED | Age unknown, and the user is in a region where verification and sharing are mandatory | Ask the user to visit the Play Store to resolve their status |
When the status is SHARED, checkAgeSignals adds ageRangeSource, which says how the band was set. TIER_A is self-declared. TIER_B is managed by a parent or guardian. TIER_C is assessed by credit card, email address, selfie, government ID or tax ID. TIER_D is a government ID plus selfie, or a digital ID. The source and both age bounds are null when the status is NOT_SHARED or VERIFICATION_REQUIRED, and ageUpper is also null for the top band.
Where significant changes apply, supervised accounts can also return significantChangeStatus: hold the gated feature on PENDING, disallow it on DECLINED, and read significantChangeApprovalDate on APPROVED. The installId field, also for supervised installs, is a Play-generated identifier used only to notify you if a parent later revokes app approval.
In US states with mandatory sharing, the in-app prompt does not appear: users verify their age or set up supervision in the Play Store. Elsewhere the user's setting decides. Ask before sharing, the default, shows the prompt; Always Share and Never Share do not. Parents choose for supervised users in Family Link.
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
Google's documentation does not yet name India as a live market for the Play Age Signals API, though its global rollout is due later in 2026, and 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 Indian users may soon be able to share an age band by choice, 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: 2 November 2026.
