Android Age Verification: How Play Age Signals Works

Last updated: 2026-10-03

Android age verification for apps on Google Play uses the Play Age Signals API, a Google library in beta that requests the user's age range from the Play Store app on the device. On July 29, 2026, Google announced the API's expansion to all Play developers globally, with rollout to all users later in 2026. It had begun returning signals in Brazil on March 17, 2026 and in Texas for accounts created after May 28, 2026 (overview). The app receives an age range and a code for how that range was established, and Google withholds the birthdate, the ID or selfie used to check it, and the parent relationship.

For iOS, see our Declared Age Range API explainer; state laws are compared in our table of app store age verification laws.

What is the Google Play Age Signals API?

The Play Age Signals API is the client library com.google.android.play:age-signals, supported on Android 6.0 (API level 23) and higher. Its default ranges are 0-12, 13-15, 16-17 and 18+. A developer can replace them with up to three minimum ages, at least two years apart, set in Play Console and changeable once a year.

The current version, 0.0.4 (July 2026), replaced userStatus with ageRangeSource and significantChangeStatus and added the access call (release notes).

Which laws make Google Play share an age range, and from when?

Two laws apply as of October 3, 2026. Brazil's Digital Statute of the Child and Adolescent, Lei 15.211/2025, took effect on March 17, 2026. Its article 12, III requires app stores and operating system providers to enable, through a secure API, the provision of an age signal ("sinal de idade") to app providers, "exclusivamente para o cumprimento das finalidades desta Lei" (solely to meet the purposes of the law). Texas SB 2420 is enforceable during the appeal: the Fifth Circuit stayed the preliminary injunctions pending appeal on June 4, 2026 (No. 25-51073), and the Supreme Court denied an application to vacate the stay on July 6. Utah, Louisiana, Alabama and California follow between January 1 and July 1, 2027; dates, duties and penalties are in the state table linked above.

From Google's Play Console help page:

While we have user privacy and trust concerns with these new verification laws, Google Play has designed APIs, systems, and tools to help you meet your obligations.

How does an Android app ask for a user's age range?

Google's request page documents three steps:

1. AgeSignalsManagerFactory.create(context) creates the manager.
2. requestAgeSignalsAccess(), with the current Activity, returns ageSignalsStatus: SHARED, NOT_SHARED or VERIFICATION_REQUIRED.
3. On SHARED, checkAgeSignals() returns the range and the other fields.

In US states with app store laws, the app shows no prompt; the user verifies age or sets up supervision in the Play Store app, and until then the status is VERIFICATION_REQUIRED. Elsewhere the outcome depends on the user's Play setting: "Ask before sharing" shows an in-app prompt, "Always Share" and "Never Share" skip it. If the user dismisses or declines, "the in-app prompt will be shown a few times before the prompt is suppressed." For a supervised child, the parent decides in Family Link.

Google's July 29 post states: "Age ranges are never shared by default". The Play Store setting is Settings > Family > Age range sharing, default "Ask before sharing", with a per-app "Share age range" switch (Google Play Help).

What does the app receive, and what does Google withhold?

Google's responses page lists the fields checkAgeSignals() returns:

The tiers, quoted from the same page: TIER_A, "User has self declared their age"; TIER_B, "User's age is managed by a parent or a guardian"; TIER_C, "assessed by using credit card, email address, selfie assessment, Government ID, or Tax ID"; TIER_D, "a combination of Government ID and selfie assessment, or Digital ID."

Google Play Help states: "Google Play will never provide your exact age or birthdate." The card, ID image or selfie behind a TIER_C or TIER_D result is absent from the response, as is the Family Link relationship. Google's July 2025 age assurance post describes a machine-learning model that estimates age from "a variety of signals already associated with a user's account, such as the types of information a user has searched for or the categories of videos they've watched on YouTube." Whether that estimate produces any ageRangeSource tier is open; the tier list names "selfie assessment" and no account-signal estimation, and a Google statement on the mapping would settle it.

The installId "does not persist across device resets", and developers "are not permitted to use it for other purposes" than revocation notices (revoked approvals page).

Is the age signal safe? Can it be faked or read by an SDK?

Two security gaps remain: the response is unsigned, and any code in the app process, an ads SDK included, can obtain the Context the call needs. Exploiting either is untested on a device.

The 0.0.4 library, downloaded from Google's Maven repository and unpacked on October 3, 2026, binds to the Play Store app (com.android.vending) with the intent action com.google.android.finsky.ageverification.BIND and receives the result as an Android Bundle over Binder, with six keys: age.range.lower, age.range.upper, age.range.source, significant.change.status, significant.change.approval.date and install.id. All six are plain values: the library has no signature, nonce or token field and no network code. A developer's server has no way to verify the range from the response alone.

The library does verify the Play Store. When AgeSignalsManagerFactory.create builds the manager, a check that logs under the tag PhoneskyVerificationUtils compares the Play Store package's signing certificates with two hard-coded SHA-256 digests; the second digest is accepted only on devices whose build tags contain dev-keys or test-keys. On a mismatch it logs "Play Store package certs are not valid", opens no connection, and the request returns error -2, PLAY_STORE_NOT_FOUND (error reference). This path is traced in the 0.0.4 bytecode and untested on a device.

Google's answer to spoofing, from the responses page:

Use the Play Integrity API when calling the Play Age Signals API to verify that the call is coming from an untampered version of your app on a certified Android-powered device, protecting the response from potential spoofing or abuse.

Open: on a rooted device, or in a repackaged app instrumented with Frida, a hook on the AgeSignalsResult getters or the Binder callback could return any range, after the certificate check passes. A device test that hooks the callback, with and without a Play Integrity verdict, would establish it.

Whether the call succeeds from inside an SDK is also untested; a test app with the call inside a third-party library would establish it. The API terms state: "You may not use the Play Age Signals API for any other purpose including, but not limited to, advertising, marketing, user profiling, or analytics." Google's Age Signals API and User Data policy prohibits "Selling, sharing, or transferring the data to any third party for any reason, except as strictly required by law". California's amended Digital Age Assurance Act bars a developer from sharing the signal "with a third party for a purpose not required by this title" (Civ. Code 1798.501(d)(4), AB 1856), from January 1, 2027.

How can an app get around the signal, and what happens if it does?

An app avoids the signal by never calling the API, by being installed outside Google Play, or by creating accounts on a website, which bypasses the store flow. On each route, COPPA still covers an operator of a child-directed service or one with actual knowledge of collecting a child's personal information, and the CCPA treats willful disregard of age as actual knowledge (Civ. Code 1798.120(c)).

Google lets developers skip the API ("Google Play doesn't mandate the use of these features") and declines to geo-block states: "We do not plan to change our approach to app releases and country targeting. However, you are free to implement your own geo-restriction solutions in your app" (Play Console help). An app installed outside Google Play gets error -9, APP_NOT_OWNED: "The app was not installed by Google Play" (error reference).

Exposure attaches at three levels:

• Google Play. For a prohibited use, the terms provide for "termination of your API access and suspension or takedown of your apps from Google Play."
• State law. Texas, Utah, Louisiana and Alabama put verification duties on developers; enforcement ranges from the Texas DTPA and state attorneys general to a private action in Utah (state table linked above). Whether a state treats an app that never calls the API as in violation is open; no enforcement action on it was found as of October 3, 2026.
• Actual knowledge. In California, from January 1, 2027, a developer that receives a signal is deemed to know the user's age range "even if the developer willfully disregards the signal" (1798.501(d)(2)(A)), with Attorney General penalties of up to $2,500 per affected child for negligent violations and $7,500 for intentional ones (1798.503(a)). A received bracket under 13 bears on actual knowledge under the COPPA Rule, and under 16 on the CCPA's opt-in rule for selling or sharing (1798.120(c)). Outside California's statute, how a court treats a received bracket under COPPA is untested; no case was found.

What do a binary scan and a traffic capture show?

The library adds these artifacts to an APK or AAB (confirmed in the 0.0.4 package):

• The manifest activity com.google.android.play.agesignals.AgeSharingConsentWrapperActivity.
• Classes in com.google.android.play.agesignals, such as AgeSignalsManagerFactory and AgeSignalsResult.
• The AIDL interface names com.google.android.play.agesignals.protocol.IAgeSignalsService, IAgeSignalsServiceCallback and IAgeSignalsAccessCallback.
• The intent action com.google.android.finsky.ageverification.BIND and the Bundle keys listed above.
• The version string com.google.android.play:age-signals@@0.0.4.

R8, Android's code shrinker, can rename public classes in a release build. The manifest entry, intent action, interface names and Bundle keys are string constants, expected to survive renaming; searching a minified release build for them would confirm it. The package containing the call to AgeSignalsManagerFactory.create shows whether app code or an SDK makes it, and com.google.android.play.core.integrity shows whether the Play Integrity library is also present. Presence shows the code is in the build; whether the app calls it takes a device test, and what it does with the answer takes a capture.

The signal is delivered on the device over Binder, so a traffic capture contains no request for it. The capture shows what the app and its SDKs send after the call: age or bracket fields in the app's own API requests, analytics user properties with values such as 13-15, regs.coppa and user.yob in OpenRTB 2.6 bid requests, and whether device.ifa, the advertising ID, is still sent for an account in an under-13 or under-16 bracket. The capture establishes what was sent; tying a value to Play Age Signals takes the binary evidence plus matching timing and values.

What does a CanITrustThat scan show for the age signal?

A CanITrustThat scan lists the ad and analytics SDKs in an Android build, with file and line for each finding, and the decompiled build it produces contains the Play Age Signals artifacts listed above when the library is present. A traffic capture on a test device records what each request contained, which host received it, and whether it was sent before or after consent; see what a scan checks and the limits of a scan.

I treat static findings as leads: an app whose build contains the Play Age Signals classes and three ad SDKs goes on the capture list, and a captured request that contains ifa for an account in an under-13 bracket is the evidence. Scanned apps are listed in the app index, and I can scan a list of Android apps in bulk ahead of the 2027 effective dates. Sign up for a CanITrustThat account to run your own research, or let us run an investigation for you.