1. The Play Age Signals API (beta) is a runtime interface between your app and the Google Play Store: your app asks, at runtime, for a user's age range, the source of that age signal, and supervision status. Usage is not literally mandated - Google Play states it does not require developers to use the API - but the US "app store accountability" bills place independent obligations on many apps that serve users in those states, and Google's message to developers is explicit: it is your responsibility to decide whether and how these laws apply to your app (https://support.google.com/googleplay/android-developer/answer/16569691). 2. Where signals are live now: Google's own docs record that on March 17, 2026 the API started returning age signals for users in Brazil for requirements under Digital ECA, and that it has started returning age signals for eligible Texas users who created their accounts after May 28, 2026 as part of compliance with Texas SB2420, with further updates promised ahead of age verification bills in other US states (https://developer.android.com/google/play/age-signals/overview). If you ship to those markets, assume the signal exists for a growing share of your install base. 3. Integration facts: the library ships as com.google.android.play:age-signals:0.0.4 (0.0.4 is the version Google recommends), supports phones, foldables and tablets on Android 6.0 (API 23) and higher, and is called client-side while the app is open - not automatically at install (https://developer.android.com/google/play/age-signals/use-age-signals-api). Default bands are 0-12, 13-15, 16-17 and 18+; if your app has its own minimum ages you can define up to three custom bands (minimum ages at least two years apart, editable once per year) on the Age signals page in Play Console. 4. Handle the response properly, including the nulls. ageRangeSource tells you how trustworthy the age is: 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 or Digital ID. ageLower/ageUpper return null when ageSignalsStatus is NOT_SHARED or VERIFICATION_REQUIRED, and ageUpper is null for the top band (for example 18+). significantChangeStatus returns APPROVED, PENDING or DECLINED only in jurisdictions where significant changes apply - it returns null for every unsupervised account and for supervised accounts with no recorded changes. Treat null and NOT_SHARED as "age unknown", never as "adult", and never crash on a null band (https://developer.android.com/google/play/age-signals/understand-age-signals-responses). 5. Significant changes and revoked approvals are developer-side duties: it is your call what counts as a significant change to your app, and you notify Google Play of it from the Age signals page in Play Console without publishing a new app version. Play Console also reports when a parent revokes approval, and Google states it will not revoke app access or disable your app based on significant-change approval outcomes - you read the current status from the API (significantChangeStatus / significantChangeApprovalDate) and act on it yourself. 6. Billing and Data safety: apps using Play Billing can assign an age rating to in-app products (SKUs), which is separate from the app's own content rating and can be set in Play Console or via the Publishing API - Play then shows it in the purchase approval flow for users in Texas. On data disclosure, the Age Signals client library collects no data of its own; the request is handled by the Play Store process under the Play Terms of Service, which is what you disclose in the Data safety section. Google also requires that your use of API data follow Play's rules on how that data must be handled (https://developer.android.com/google/play/age-signals/overview). 7. Practical checklist: call the API rather than building your own ID-based age gate; pair it with the Play Integrity API so the response cannot be spoofed by a tampered client; make the unknown/not-shared path a first-class branch in your age-gating logic; configure custom age bands in Play Console to match your app's minimum ages; keep the SDK updated; and document the flow in your privacy policy so the age-assurance behaviour matches what you declared in Data safety.