On July 29, Google announced that it will expand Google Play's "Play Age Signals API" to all users worldwide during 2026. What apps receive is not a birth date but an age band, and the API can also distinguish whether that information is based on parental management, self-declaration, or age estimation/verification. This begins a global division of labor in which the store prepares age-related information and each app changes its content, features, and safety settings accordingly. However, the API is still in beta, and boundaries remain depending on user consent and distribution channel.
From Brazil to Worldwide Within the Year
The Play Age Signals API is already returning real age signals in Brazil. Google plans to next expand coverage to Australia and Canada by mid-August 2026, and then roll it out to users worldwide later that year. While the API will be opened to developers globally, the plan calls for gradually expanding the user base. "Worldwide rollout" does not mean a completed state, but rather indicates a process to be carried out by the end of the year.
There are also boundaries to the scope of support. According to Google's developer documentation, supported devices are smartphones, foldables, and tablets running Android 6.0 (API level 23) or higher. The API can only be used by apps updated through Google Play. It is not a common age-verification mechanism for all of Android, including apps that don't go through Play, Wear OS, or Android TV.
Ahead of this rollout, Google released library version 0.0.4 in July 2026. It separates requestAgeSignalsAccess(), which checks within the app whether sharing is permitted, from checkAgeSignals(), which actually retrieves the age signal. This allows the user confirmation screen and the process of reading age information to be handled separately.
Four Age Bands, Plus the Source of the Information
The standard age bands are four categories: "0–12," "13–15," "16–17," and "18 and over." Developers can specify up to three minimum ages tailored to their app, but the cutoffs must be at least two years apart, and they can only be changed once per year. For example, if a developer sets the minimum age to 15, the API will return either "0–14" or "15 and over." The design is such that it doesn't pass the exact age, only informing the app of the relevant feature boundary.
The initial sharing status an app receives will be one of SHARED, NOT_SHARED, or VERIFICATION_REQUIRED. If shared, the app can obtain the age band; if declined, it cannot. In regions where verification is legally required and the age has not been verified, the app should direct the user to the Play Store to resolve the status. In applicable regions in the United States, apps do not show an in-app sharing confirmation screen; instead, age verification and parental supervision settings on the Play Store are used.
The basis for the age band is returned as one of four tiers:
| Tier | Source of Age Information Indicated by the API |
|---|---|
| TIER_A | User self-declaration |
| TIER_B | Parent-managed age |
| TIER_C | Estimation/verification via credit card, email address, selfie-based judgment, government-issued ID, or taxpayer number |
| TIER_D | Combination of government-issued ID and selfie, or digital ID |
Therefore, the fact that an age band was returned is not the same as the fact that the age was verified with identification. TIER_A is self-declared, and TIER_B is information entered by a parent. Apps can decide on content restrictions or default settings while looking at both the age band and the source of that information.
Family Link Centralizes Sharing, and Usage Is Narrowly Restricted
By default, a child's parent-managed age band is not shared with apps. When a parent chooses to share via Family Link, Play apps that have integrated the Play Age Signals API can receive the signal. This setting can be changed or disabled later, and parents don't need to input the age separately for each app. Adults can share their own age band when requested by an app.
Meanwhile, the API's terms of service narrowly restrict the use of age information. Developers may only use it to provide legally required age-appropriate content or experiences within the requesting app itself. Diversion for advertising, marketing, user profiling, or analytics is prohibited. Misuse could lead not only to suspension of API access but also to suspension of app publication or removal from Google Play.
According to Google, the client library itself does not collect data. During a query, the Play Store handles the processing, and the app receives back results such as the age band and its source. However, how the app processes the data after receiving it, and Google Play's "Data safety" declaration, remain the developer's responsibility.
The API is also not a mechanism that automatically determines child-appropriate settings. Google noted that a weather app and a video/entertainment app don't need the same safety settings, leaving it up to developers to decide how to adjust content and features. What is standardized is the handing-off of the age signal; the safety measures that follow depend on how the app implements them.
From Regulatory Compliance to a Common Component—But Still Unfinished
The reason the first region of actual operation was Brazil is that age assessment became a legal requirement there. The country's Digital ECA took effect on March 17, 2026, requiring app stores and OSes to provide auditable, safe age-assessment methods and a privacy-conscious age signal API. While it bans continuous, unrestricted sharing of children's personal data, it requires that covered services have a mechanism to receive age information. The Play Age Signals API began returning real data in Brazil on the effective date.
Texas's App Store Accountability Act also requires stores to provide developers with age categories and parental consent status. The law's categories—under 13, 13–15, 16–17, and 18 and over—match the API's standard four bands. Additionally, developers must notify the store before making major changes to their terms of service or privacy policy. Notification is also required for content that affects age categorization, added monetization, and major feature changes.
Google has documented a flow in which these "material changes" are registered in Play Console up to 90 days in advance, with a maximum of three at a time, and parental approval status is returned to the app as APPROVED, PENDING, or DECLINED. It also plans a mechanism that provides an installId indicating the combination of user and device for which approval has been revoked, along with a 90-day CSV list of revocations. However, as of July 21, 2026, the Console features for material changes and approval revocation are not yet operational. Despite the worldwide rollout announcement, the operational features needed to handle parental re-approval remain unavailable.
Apple, too, offers a Declared Age Range API that shares age bands without passing the exact birth date. Starting February 24, 2026, in Australia, Brazil, and Singapore, the App Store itself blocks downloads of apps intended for users 18 and over by users who cannot be confirmed as adults. Both companies are shifting age verification to the store and account layer while leaving in-app handling to developers.
The policy proposal Google presented in 2025 envisioned only the apps that need it obtaining consent and receiving minimal age information, restricting its use, and centralizing parental controls into a single dashboard. This worldwide rollout extends that same design to regions not covered by legal mandates. What should be watched by the end of 2026 is whether the signal becomes available as scheduled in all regions, and when the still-missing features—needed for developers to actually translate age bands into functional controls—will become operational.