We finally know how Android’s new app verification rules will actually work

Back in August, Google made an announcement that shocked Android enthusiasts and privacy advocates: Starting next year, Android will block the installation of apps from unverified developers. This applies not only to apps on the Play Store but also to apps distributed outside of it, sparking concern that Google wants to kill sideloading. After a few weeks of silence, Google finally addressed these concerns, insisting that sideloading is here to stay. The company also shared new details about how its developer verification requirements will be enforced, including that, in some cases, Android will require an active network connection to sideload apps.

Last month, we spotted evidence in the Android SDK suggesting developer verification could fail when a network connection is unavailable. We couldn’t confirm this behavior at the time, since Android’s developer verification requirements hadn’t yet gone into effect. This week, however, Google confirmed this will be the case. Alongside its blog post declaring that “sideloading is fundamental to Android,” Google also published a video explaining the reasoning behind the verification requirements and how it will be implemented next year. I pored over the video to learn as much as I could about these upcoming changes so you don’t have to.

How Android will verify apps

When you try to install an Android app, the operating system already performs a number of checks before allowing the installation to go through. These checks ensure an app with the same application ID (i.e., package name) isn’t already installed, that it isn’t built for an extremely old version of the OS, and, most importantly, that it hasn’t been flagged as malware by Google Play Protect.

Google is now tacking on an additional step to this process. The company has built a hook into the install flow, requiring any app being installed for the first time to go through verification. At the time of installation, Android will communicate with a “trusted entity” on the device called the Android Developer Verifier. This new, preloaded system service determines if the app’s developer has been verified, if any issues were encountered during verification, and finally, what installation policy to enforce.

To determine if an app’s developer has been verified, the Android Developer Verifier service needs to check that the package and the key used to sign it have been submitted to Google. It’s impossible to maintain a comprehensive on-device database of such package and key combinations, especially since so many new Android apps pop up each week. This is why Google says your phone will need a network connection to verify apps, though only in the “worst-case scenario.” The company plans to have the Developer Verifier service maintain a cache of the most popular apps it has already verified so they can be installed without a network connection.

Furthermore, Google says it’s working on a solution for app stores to bypass additional network calls. App stores can pass what’s called a “pre-auth token” — a “cryptographically verifiable blob” that’s associated with the package they want to install. This allows an app’s developer to be verified without any additional network calls to Google’s backend.

The second quarterly release of Android 16, ie. Android 16 QPR2, will be the first version of Android to natively support these changes. However, the verification policies won’t be enforced when the update rolls out in December, as Google is still working on its implementation and collecting metrics. The changes will be backported to older versions of Android through Google Play Protect, though Google says there may be some slight differences because this method leverages an existing app rather than the new, native verifier service built into the OS.

How Android’s verification requirements will affect students and hobbyists

When Google first announced its new developer verification requirements, it mentioned that it would create a “separate type of Android Developer Console account” for hobbyist and student developers, one that would have “fewer verification requirements” and a waiver for the $25 USD registration fee. At first glance, this seems like it would solve the needs of indie developers who distribute their apps for free on places like GitHub or F-Droid, but there’s a major catch.

Developers who register with Google as a student or hobbyist will face severe app distribution restrictions, namely a limit on the number of devices that can install their apps. To enforce this, any user wanting to install software from these developers must first retrieve a unique identifier from their device. The developer then has to input this identifier into the Android Developer Console to authorize that specific device for installation.

This two-way handshake between users and developers was intentionally designed to limit distribution. Google says that student/hobbyist accounts are only for developers who want to share an APK with a finite set of known people, not for those who want to distribute their apps broadly. Developers who sign up as a student or hobbyist but later decide they want a wider audience will have the option to convert their account, so they won’t be forever stuck with limited distribution.

These restrictions make sense in the context of Google’s overarching goals. Allowing unlimited distribution for student/hobbyist accounts would create a loophole for bad actors to exploit, so by limiting their reach, Google deters malicious developers from misusing this account type.

How Google will prevent bad actors from evading verification

Speaking of bad actors, Google says it designed its system to catch and prevent them from passing verification. For starters, developers won’t just be able to claim ownership over any existing package. To prove ownership, they must show they can sign apps using the same key as the app they’re claiming. This doesn’t require sharing private keys with Google, so the company itself won’t gain any signing rights. Google says its only goal is to stop bad actors from distributing harmful apps, such as malware. Therefore, it won’t place other policy restrictions on developers, like limiting the names and icons they can use for their apps.

Developers caught distributing malware will have restrictions placed on their accounts. For an unspecified period, all apps owned by these developers will be blocked from installation on user devices. This applies to any developer whose account is associated with malware distribution, even if that developer isn’t the malware author. Malware authors often try to buy out existing developer accounts to leverage them for distribution; Google says that, ultimately, developers are responsible for anything published under their account, justifying any action taken against them.

Another technique that malware authors use to get around verification is identity fraud. Google says it has some “secret sauce” — techniques that allow it to identify when developers are lying about their identity. The company has teams who perform verification and are trained in identifying false submissions, even ones generated using AI tools. Plus, the need to obtain a DUNS number will deter many bad actors from applying for an organizational account.

What about privacy, F-Droid, and enterprise use cases?

In its video, Google addressed several concerns users raised following the announcement. Regarding privacy, Google acknowledged that legitimate reasons for developer anonymity exist, such as when distributing apps for dissidents. That’s why the company stated it won’t share developer information publicly (though, notably, it didn’t commit to withholding this information from governments). Regardless, Google insists the status quo must change, arguing that developer anonymity poses risks to users that it can no longer overlook.

While Google didn’t directly address concerns that its policies will kill independent app stores like F-Droid, it did mention a small silver lining. The company said that in rare scenarios, it will allow package name duplication. For example, if an app on the Play Store shares a package name with an app from another source but has fewer installs, Google will work with the developers on a solution, which may require the Play Store developer to change their app’s package name.

Unfortunately, this carve-out is unlikely to help many developers on F-Droid. The problem stems from how F-Droid distributes apps: its team compiles source code provided by developers and then signs the apps themselves. This practice often creates two conflicting versions of an app — one from F-Droid and one from the original developer — that both use the same package name.

To prevent multiple developers from claiming ownership of the same package, Google will give preference to the developer whose version has the majority of known installs. For many apps on F-Droid, this means its team would effectively become the owner, even though they aren’t the original developers. The original creators would then be forced to change their package name to distribute their app elsewhere. This outcome is undesirable and violates F-Droid’s core philosophy, explaining its strong opposition to Google’s new policies.

Lastly, Google will make some exceptions for enterprises. An app installed via enterprise management tools on a managed device will be installable even if its developer isn’t registered. This carve-out exists because managed devices have a responsible third party — an IT admin — in charge of security. Unfortunately, Google says that entities distributing apps to offline devices will need to determine for themselves how to handle verification requests, such as by connecting to the web periodically.

Many questions still remain about Android’s new developer verification requirements, including which methods will bypass it. We already know that ADB installation works, but it’s unclear if that will extend to solutions like Shizuku, which allows for executing ADB commands using shell privileges. There’s still a long time before Google enforces its new policies, so details could change and new information may emerge. If we learn anything new, we’ll be sure to let you know — so follow us to stay up to date!