Play Age Signals API in 2026: A Step-by-Step Tutorial for Age Ranges, Significant Change Approvals, and

Age verification has moved from the app to the store. Texas SB 2420 is now in effect, Brazil's Digital ECA began returning age signals on 17 March 2026, and Google Play now hands developers an answer they used to have to guess: how old is this user? The Play Age Signals API (beta) is the client-side door to that answer. This tutorial follows the integration order that avoids a rewrite.

One framing to get straight first: Google Play does not mandate the API. The laws impose obligations on apps that distribute in those jurisdictions; Google supplies the tooling and leaves the compliance decision with you. Write down that decision — an audit trail beats a memory of a Slack thread.

Three dated facts, all from Google's own documentation, define the scope:

• Texas. The App Store Accountability Act (SB 2420) is in effect after a federal appeals court stayed the preliminary injunction issued in December 2025. For eligible users, Google Play returns age signals for accounts created after 28 May 2026, and further updates are promised ahead of age verification bills in other US states (Play Console help).
• Brazil. Since 17 March 2026 the API returns age signals for users in Brazil for requirements under the Digital ECA (Age Signals overview).
• Obligation split. The store verifies, parents approve, and the developer must ingest age ranges plus parental approval status for significant changes, and notify the store when a significant change happens. Play's own FAQ says plainly that it does not require the Age Signals API — the laws require age-appropriate experiences.

Practically, that means the API solves the hardest part (you cannot verify a birth date yourself without collecting identity data you would rather not hold) and leaves you the part you actually control: what the app does differently for a 13-15 band versus an 18+ band.

The client library is com.google.android.play:age-signals, and Google recommends the latest version, 0.0.4. Supported form factors are phones, foldables and tablets running Android 6.0 (API level 23) and higher. Add it to the app module:

• implementation 'com.google.android.play:age-signals:0.0.4'

Two constraints are easy to miss. First, this is a client-side, runtime API: age signals are retrieved while the app is open, not pushed to a backend, so any server-side gate has to be driven by what the app obtained and then decided how to transmit. Second, by using the API you accept its terms of service and agree to comply with Google Play developer policies.

Calling checkAgeSignals() first is the classic mistake. You must resolve the sharing status through requestAgeSignalsAccess(activity), which returns one of three states, and each demands different UI:

• SHARED — age signals may be read. This covers an adult who verified or self-declared in an eligible auto-share region, and a supervised minor whose parent shared age.
• NOT_SHARED — the user or their parent declined. Your fallback experience applies; do not re-prompt in a loop.
• VERIFICATION_REQUIRED — in applicable US states the user must verify in the Play Store before any signal exists. Send them there, and keep the request idempotent on return.

Region behaviour differs by design. Where choice is required (for example the EU, UK and Brazil), users pick Ask before sharing, Always share or Never share; under Ask before sharing Play renders a built-in in-app prompt. In applicable US states there is no in-app prompt at all — the Play Store owns verification, and calls return SHARED or VERIFICATION_REQUIRED. For supervised accounts, parents manage sharing in the Family Link app. If a user dismisses the prompt, Play re-shows it a few times and then suppresses it — which is why a hard block on NOT_SHARED is a product decision, not a technical default.

checkAgeSignals() returns the fields that decide your branch logic (response reference):

• ageLower / ageUpper — inclusive bounds of the user's band. Default bands are 0-12, 13-15, 16-17 and 18+. ageUpper is null for the highest open-ended band.
• ageRangeSource — TIER_A self-declared; TIER_B parent/guardian managed; TIER_C assessed via credit card, email, selfie assessment, government ID or tax ID; TIER_D government ID plus selfie assessment, or Digital ID. Treat the tier as a confidence grade and log it next to the branch you took.
• significantChangeStatus / significantChangeApprovalDate — APPROVED, PENDING, DECLINED, or null where the jurisdiction does not apply.
• installId — assigned to supervised installs, used for revoked app approval notices.

The trap: null bounds do not mean "child". Both bounds come back null for a verified adult, and they also come back null when status is NOT_SHARED or VERIFICATION_REQUIRED. If your code maps "null" to "restricted", you will lock out paying adults. Branch on the status first, then on the bounds, and treat null bounds as "unknown, use the default tier" unless the status says otherwise.

Default bands rarely match a real product rule. On the Age signals page in Play Console, the Custom age ranges tab accepts up to three minimum ages; minimum ages must be at least two years apart and can be changed once annually. Set one minimum of 15 and a 0-14 user returns ageLower=0, ageUpper=14 while a 15+ user returns only ageLower=15. Set 13 and 17 and you get three bands: 0-12, 13-16, 17+.

Because the change is annual, decide the bands from your product rules and your store listing commitments before you save. Re-tuning later is a change request, not a config tweak.

"Significant change" is defined by you, not by Google. When you make one — a new social feature, a change in data sharing, a new purchase surface — notify Play on the Age signals page in Play Console; no new app version is required. Parents then approve or decline, and you read the outcome through significantChangeStatus. Play states it will not revoke app access or disable an app when a parent declines: the consequence is yours to define, and the notification path for revoked approvals runs through installId.

Texas adds a separate track for money: in-app products may need their own age rating, distinct from the app's content rating. You can set it in Play Console or through the Publishing API, and Play surfaces it in the purchase approval flow for Texas users on Play Billing. Treat the SKU rating as part of the release checklist, not an afterthought — a purchase flow that skips it is the kind of gap that shows up as a compliance finding rather than a crash.

The error table is really two groups. Retryable: -1 API not available, -2 Play Store missing, -3 network, -4 Play Services missing, -5 cannot bind to service, -6 Play Store outdated, -7 Play Services outdated, -8 client transient error. Not retryable: -9 app not installed by Google Play, -10 SDK version no longer supported, -100 internal error (contact Play developer support with the API name in the subject).

For the first group, use a bounded retry with exponential backoff and an exit condition, and surface the actionable message (update the Play Store, check connectivity). For the second group, fail into your default experience immediately and log — a retry storm on APP_NOT_OWNED only wastes battery. Sideloaded builds will always land there, which is also why testing needs the documented fake manager rather than a hand-installed APK.

Two different data questions get confused here. The Play Age Signals client library itself does not collect or share data with third parties; the Play Store processes the signals on the device. What you do with the values after reading them is entirely yours, and that is where policy exposure lives: declare it in your privacy policy, keep retention to what the age-appropriate experience needs, and do not repurpose signals for advertising, profiling or analytics — the terms restrict use to providing age-appropriate experiences, and misuse terminates API access and puts the app itself at risk.

Google also recommends calling the API alongside the Play Integrity API so the response cannot be spoofed by a tampered build. That is a cheap addition when you are already integrating, and an expensive retrofit after an incident.

Pre-ship check: access status handled for all three states, null bounds never treated as "minor", custom bands frozen against your product rules, significant-change notification owned by a named person, IAP SKU ratings set for Texas, retryable errors bounded, privacy policy updated, Play Integrity considered. Eight items, none of which the store will verify for you.

Sources: Play Age Signals API documentation on developer.android.com (overview, integration, responses, error handling) and Play Console Help on upcoming US app store bills, both checked on 2026-10-23. Google Play does not publish enforcement thresholds or per-app legal determinations; none are inferred here.