Google says registered Android app stores get one tap installs from 1 December in 139 listed regions, not the US

A list of 139 regions, a date 34 days away, and a fee of 10,000 dollars a year

Google's own FAQ for its Registered App Stores programme lists the regions where a registered third party Android store can offer installs with one tap, and the United States is not among them. Counting the names on that list gives 139 entries (derived: Google prints no total). The page says the status becomes available "Starting December 1, 2026" on devices running Android 17 QPR2 or higher, which is 34 days after the day this briefing was written, 28 October 2026 (derived). A store gets there by passing a Google review, paying "an annual registration fee of $10,000", and sharing its whole app catalogue with Google for continuous malware scanning.

What that does not establish is the thing most readers will assume. A registered store is not a store whose apps Google has checked and approved. Google's requirements page says that "Google won't moderate the content available within registered app stores", and that the stores "remain responsible and liable for their entire catalog". The pages read for this briefing also do not say what, on the device, replaces the confirmation screens that the one tap flow removes. The Hacker News headline, seen only in a search result because that site answers automated requests with a challenge, says "approved" stores; Google's own word is "registered".

This briefing reads Google's own developer pages, its 4 March and 18 June 2026 Android Developers Blog posts, and two Google help pages, between 18:41 and 18:54 UTC on 28 October 2026. The enrolment, overview and requirements pages say "Last updated 2026-10-27 UTC" and the FAQ says "Last updated 2026-10-28 UTC", so wording may change. Android Authority's report of 27 October was read as a secondary source, for a Google spokesperson's statement and the Epic Games link it draws. The separate Android 17 Advanced Protection story is in an earlier briefing and is not repeated here.

What exactly changes: one tap for stores Google has registered

Google defines the programme in one sentence on its overview page: "A Registered App Store is a third-party app store that registers with Google to access additional platform capabilities, including one-tap installs, while upholding core ecosystem trust, security, and performance standards." The capabilities are two. Users can "download and install apps directly from the store without secondary system confirmation screens", and the store can send notifications about updates and status changes. The overview table adds a third: updates "in the background automatically with user control settings" instead of manual approval for each release.

Zoom

Two points keep this from being a free pass. Participation is optional: "If a store chooses not to participate, it retains the same experience as any sideloaded app on Android", and the FAQ repeats that third party stores "may continue to operate on Android as they do today without enrolling". And the rules still require consent. The requirements page says stores "must not install apps silently without user consent", must show a notification for background and remote installs, and, if an install began on another device, must show a notification that "does not close automatically". So the change is about friction, not about removing the user from the decision. Whether the removed screens carried a warning that mattered is the question the rest of this briefing returns to.

Who approves a store, and on what criteria

Google decides. Its overview describes a five step process: an interest form with identity details, public distribution links and the Google account used for the Android Developer Console; "pre-qualification", where Google "reviews the submission to validate the provided organization account, developer and package name verification status, and brand legitimacy"; payment of a fixed annual fee; an application and technical evaluation; then activation. A rejected store "may appeal this decision". "Brand legitimacy" is not defined on any page read.

Zoom

The requirements page groups the criteria under five headings. The table sets out the ones that bear on security, with Google's wording where it matters. Two things stand out. The harm thresholds lead to fees, not to removal: if more than 1 per cent of install attempts or 2 per cent of the apps in the catalogue over 30 days "are found to be PHA" (potentially harmful apps), Google "will assess variable fees required to screen and remediate high-risk catalogs". On an illustrative catalogue of 10,000 apps, 2 per cent is 200 apps (derived). Removal is stated for non payment, for failing requirements after notice, and "immediate deregistration" for stores whose primary purpose is the most serious illegal content.

What the criteria do not include is a standard for each app. They set what a store must do, and Google scans what the store sends. The catalogue is delivered to "a dedicated, secure Google Cloud Storage bucket" that Google provisions, and the overview page says stores must continuously share "the complete app catalog and ongoing app updates". That gives Google a full inventory of every registered store's apps, which is also a commercial position, and it is the reason the interest of the publisher needs stating: Google runs Google Play and Android, sets the fee and the rules, and receives each registered store's catalogue.

Which regions, from when, and the court context Google cites

The operative rule is a list, not the phrase "outside the US" that coverage used. The FAQ says that "Starting December 1, 2026, Registered App Store status is available on Android 17 QPR2 and higher devices in the following regions" and prints 139 names, from Albania to Zimbabwe. The United Kingdom, Germany, France, Canada, Australia, India, Japan and Brazil are on it. The United States is not, and neither is China (both derived, by searching the printed list). The list also includes Cuba, Iran and Russia. A separate Android help page, about developer verification, says its requirement "does not apply in regions where Google Mobile Services are unsupported or in territories subject to applicable trade sanctions". The pages read do not say how the two statements fit together, and this briefing draws no conclusion from the overlap.

Availability follows the user's "home account country", not their location. Short trips to unsupported regions "don't disrupt existing one-tap installs or automatic updates", and a permanent move changes the available features automatically.

The cause, as Google states it, is in its 4 March 2026 post on the Android Developers Blog. That post announces three changes together: more billing options, the Registered App Stores programme, and lower fees. It says: "With these updates, we have also resolved our disputes worldwide with Epic Games." On the programme itself it says it will "begin outside of the US first, and we intend to bring it to the US as well, subject to court approval", and promises a launch "with a version of a major Android release by the end of the year". Android Authority, a secondary source, reports a Google spokesperson saying "Eligible app stores outside the US can now apply to register their stores", and that the programme stems from a proposed settlement with Epic Games. Google's own pages for the stores do not mention a court or a regulator, and this briefing does not infer a motive beyond what Google writes.

The US has a different route. Google's FAQ says the Registered App Stores programme gives OS level capabilities such as one tap installs, whereas "Third-Party App Store on Play" is "a distinct Google Play program" that is "available in the US only". Google's Play policy page for US developers says that on 22 July 2026 both the Play Catalog Access programme and that Play programme "is now in effect", and that on 4 March 2026 "the parties have asked the US District Court to enter a revised Modified Injunction". That page still carries this sentence when read on 28 October, so the court status of the settlement is not something this briefing can state beyond Google's own words.

What stays in place: developer verification, and a verifier already on the phone

The one tap flow sits on top of Android developer verification, which Google describes as a requirement for "all apps to be registered by verified developers for users to install them on certified Android devices". A Google help page says a system service called Android Developer Verifier (package name "com.google.android.verifier") is installed on devices to validate that an app is registered to a verified developer. A user who tries to install an app from an unverified developer gets a notification and cannot install it, unless they complete "a one-time advanced flow in your phone settings", which includes "security checkpoints and a protective waiting period".

The timing matters. Google's 18 June post says the developer verification protections take effect on 30 September 2026, "starting with users in Brazil, Indonesia, Singapore, and Thailand", checking installs from seven named stores: Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. Global expansion for "all apps on certified Android devices" is promised for 2027. Registered third party stores are not on that list of seven. So on 1 December, 62 days after the 30 September start (derived), in most of the 139 listed regions the device wide check is not stated to apply to installs from these stores. Google's developer pages do say that "The verification capability will soon be expanded to all third-party Android app stores", without a date.

Where a registered store does run the check, it runs on the store side. Google's Android Developer ID API page tells stores that an app which "has not been registered by a verified developer" is NOT_INSTALLABLE and that the recommended action is "Block installation". The requirements page does not list use of that API as a condition. Whether a store must call it is therefore not stated in the pages read. That is an inference from reading the two pages side by side, labelled as such.

Zoom

What it means for sideloaded malware, and the friendly name

Google does not publish a malware claim for this change, and no figure on malware rates, scanning results or the number of stores that applied or were approved was found. What can be said is limited to mechanism, and what follows is inference from Google's own descriptions, not a finding.

Two effects pull in opposite directions. On the safety side, a registered store has an identified organisation behind it, is paid up, has had its APK scanned, and feeds its catalogue to a scanner, with fees if its catalogue looks bad and deregistration for the worst cases. That is more accountability than an anonymous APK site. On the friction side, the screens removed, the per install dialog and the Settings toggle, are the two moments where a user is currently asked whether to trust a source. Google's own table calls the registered flow "Preferred". A user trained to expect no confirmation screens from registered stores may be less alert to the confirmation screens that unregistered stores still show, and the pages read do not say how the two will look different.

The friendly name is "registered". It describes a relationship with Google: an application, a fee, a scan. It is not a content review. Google's page says it will not moderate what a registered store hosts, and the store is liable for it. The word "approved" in coverage turns a registration into an endorsement, and it should be read as the first, not the second. The threshold design also tells a reader something: a store can host potentially harmful apps up to 1 per cent of install attempts or 2 per cent of its catalogue over 30 days before Google states that fees apply (derived from Google's wording; Google does not say that below that level a store is safe).

The comparison with the Advanced Protection story is only this: both are Google controls whose strength depends on a user setting or a status. The Android 17 briefing covers that opt in design for accessibility abuse; this one adds a status a store opts into, with the same gap between the name and the control.

Technical details

Google's pages print platform declarations, thresholds, API endpoints and a verifier package name. They publish no malware indicators, hashes, domains or detection rules, because this is a programme, not an incident, so none are listed. Each block below is copied from the page named in its caption, read on 28 October 2026. Nothing here is exploit code. A defender uses these to know what a registered store declares and what Google's API tells a store about an app.

What a registered store must declare. These are the platform requirements as printed. A managed fleet can look for stores that declare these in an app inventory, subject to what the management product exposes (inference, not stated by Google).

Platform requirements:
App stores must handle the required intents for app stores.
The store must declare INSTALL_PACKAGES_AS_REGISTERED_APP_STORE.
The store must declare the REQUEST_INSTALL_PACKAGES permission.
The store must ensure it fixes major security vulnerabilities surfaced to them.

The harm threshold, and the on device verifier. The first block is the sentence that sets when fees apply. The second is the package name of the verifier service that Google says is installed on certified devices; managed fleets can confirm it is present.

If more than 1% of install attempts or 2% of apps in the catalog over a 30 day period are found to be PHA, Google will assess variable fees required to screen and remediate high-risk catalogs.

Android Developer Verifier (package name: com.google.android.verifier)

What Google's API tells a store about an app. These are the states and the recommended action as Google prints them. A store that follows the table blocks an app that is not registered. The page also prints that the "Pre-Authentication Certificate" is "valid for approximately one week" and that a replacement is issued "approximately three days before expiration".

INSTALLABLE_PRE_AUTH_CERTIFICATE_AVAILABLE
  The app has been registered by a verified developer and can be installed.
  Recommended OEM action: Proceed with installation. Provide the preAuthCertificate to the on-device installer.

INSTALLABLE_PRE_AUTH_CERTIFICATE_UNAVAILABLE
  The app has been registered by a verified developer and can be installed. The preAuthCertificate is currently unavailable due to a transient issue.
  Recommended OEM action: Proceed with installation. The device will perform a real-time online check since the preAuthCertificate can't be provided to the on-device installer.

NOT_INSTALLABLE
  The app has not been registered by a verified developer or has been blocked from being installed on GMS Android devices.
  Recommended OEM action: Block installation. Hide the app from your store or disable the install button. Notify the app's developer that they must complete Android developer verification.

The request shape, as Google prints it. The first line lists the apps in a store's watch list, called an App Attention Set. The key is a placeholder written by Google in square brackets, not a real credential.

curl -X GET -H "X-Goog-Api-Key: [key]" -H "Content-Type: application/json" \
"https://androiddeveloperid.googleapis.com/v1/appAttentionSets/curltest/packageCertificates?page_size=100"

Two observations on Google's own page, labelled as this site's reading. The sample response shows the state "INSTALLABLE", while the table above lists the longer state names. The sample's update time and expiry time are 10 days apart (29 September and 9 October 2026, derived), while the text says about one week. The page is new and likely to change, so developers integrating against it should re read it. The page prints a service level of 99 per cent availability for the API.

What to do, in the order worth doing

The first action is a decision about managed devices, because the flow reaches Android 17 QPR2 devices on 1 December. Each action below follows from a line in Google's pages, and none depends on a malware figure that Google has not published.

What could not be verified

• The Hacker News report. Its address answers a Cloudflare challenge to automated requests, so it was not read and is not cited. Its headline was learned from a search result only.
• Android Authority. Read once, as a secondary source (27 October 2026). A second Android Authority article, which a search result said reported that Epic Games and Google withdrew a proposed settlement in July 2026, answered with a Cloudflare block and was not read. Nothing in this briefing relies on it.
• Android 17 QPR2. The name and the 1 December start are as Google's pages state them. This briefing did not test a device.
• The first install of a store, the on device screens, and Play Protect. Not described on any page read.
• Enterprise controls. Google says administrators can block registered stores. The mechanism is not named.
• Counts. The number of stores that applied, were approved or were rejected is not published on any page read. The count of 139 regions is this site's, taken from the printed list.
• Whether the apps the stores carry are safe. No malware figure for any registered store was found.
• Time stamped. Pages were read between 18:41 and 18:54 UTC on 28 October 2026, and several were updated on 27 and 28 October.

The question that exposes the gap

When a registered store puts an app on a phone with one tap and no extra screen, what exactly has checked that app and that store at that moment, and where does Google say so?

Key facts