{"id":4193,"date":"2026-08-22T00:17:43","date_gmt":"2026-08-22T00:17:43","guid":{"rendered":"https:\/\/indapp.io\/en\/?p=4193"},"modified":"2026-08-21T22:21:26","modified_gmt":"2026-08-21T22:21:26","slug":"android-verification-rules-split-pwa-distribution","status":"publish","type":"post","link":"https:\/\/indapp.io\/nl\/android-verification-rules-split-pwa-distribution\/","title":{"rendered":"Android\u2019s New Verification Rules Split PWA Distribution in Two"},"content":{"rendered":"

The same web app can now take two very different routes onto an Android home screen. One route starts with a URL and ends with a browser-installed PWA. The other turns that web experience into an Android package for an app store or direct download. The product may look nearly identical after launch, but Android\u2019s new verification rules make the distribution systems fundamentally different.<\/p>\n

That distinction stopped being architectural trivia on August 20. Android published detailed instructions for developers distributing apps outside Google Play, including new rules for identity, signing keys, package names and small-scale sharing. For teams that wrap a PWA in a Trusted Web Activity, the message is simple: the moment the web app becomes an Android package, it inherits Android\u2019s new trust gate.<\/p>\n

What Android has now made explicit<\/h2>\n

Developers distributing only outside Google Play are being directed to the Android Developer Console<\/a>. Registration connects three things that teams sometimes manage separately: a verified developer identity, an Android package name and the SHA-256 fingerprint of the app\u2019s signing certificate.<\/p>\n

For an existing package, entering a name and fingerprint is not necessarily enough. Android says the developer may need to upload a signed APK containing a supplied challenge in its assets. That process is designed to prove possession of the private signing key rather than simply accepting whoever types a familiar package name first.<\/p>\n

The most consequential detail is how Android plans to handle collisions. If one signing key accounts for more than half of the known installations associated with a package name, that developer receives priority. When no key has a majority, keys associated with at least 50 installs can become eligible. If no key reaches that threshold, registration can become first come, first served. Android also describes a process for requesting shared use or presenting evidence when the default allocation does not fit a legitimate case.<\/p>\n

In other words, a package identifier is no longer just a string selected during a build. For off-Play distribution, it becomes part of a verifiable chain linking the developer, signing history and installed app base. Teams that have changed signing keys, produced multiple wrappers or allowed partners to publish differently signed builds should treat this as an inventory problem now\u2014not during the final week before enforcement.<\/p>\n

Android created two account lanes<\/h2>\n

Professional developers and organizations can use full distribution<\/a>, which Android says supports unlimited apps and installations. Individuals must provide identity and address documentation. Organizations additionally need information such as a D-U-N-S number, a verified website and official organizational records.<\/p>\n

Students and hobbyists have a narrower alternative. Android\u2019s new limited distribution account<\/a> is free, does not require a government ID and can register an unlimited number of apps. Its audience, however, is capped at 20 authorized devices. Sharing uses a handshake involving a QR code or link, device-owner consent and registration through the console. A Google Account, two-step verification and a linked payments profile are still required.<\/p>\n

Android says limited accounts became available to everyone in August. The first enforcement date is September 30, 2026, when the protections take effect on certified Android devices in Brazil, Indonesia, Singapore and Thailand. Developers using the limited route are being told to register package names and authorize devices before that deadline because those steps can take time.<\/p>\n

Why PWA teams are affected\u2014sometimes<\/h2>\n

A browser-installed PWA is not an Android APK. It does not acquire an Android package name merely because a user adds it to a home screen, and the new Android Developer Console workflow does not become part of that installation. The manifest, service worker, HTTPS origin and browser remain the important layers.<\/p>\n

A Trusted Web Activity is different. Chrome\u2019s technical overview<\/a> describes it as a way to open PWA content from an Android application. Digital Asset Links verify that the Android app and the website belong to the same developer, allowing the web experience to open without the normal browser toolbar.<\/p>\n

That Android application has a package name and signing key. It can be uploaded to a store or distributed as an APK. It therefore falls inside Android\u2019s package-registration system even if almost every visible screen comes from the web. This conclusion follows from combining Android\u2019s rules for distributed packages with Chrome\u2019s architecture for Trusted Web Activities.<\/p>\n

The useful boundary is not native versus web.<\/strong> It is browser installation versus Android package installation. A PWA can participate in either route, and a team offering both has two separate distribution systems to maintain.<\/p>\n

Wie zou zich moeten bekommeren<\/h2>\n