Google's plan to restrict sideloading on Android has a potential escape hatch for users

Last week, Google dropped a bombshell: The company plans to verify the identity of all developers who distribute apps for Android, even those outside the Play Store. Starting next year, if a developer chooses not to verify their identity, Android will prevent their apps from being installed on certified devices (ie. devices with Google Mobile Services). This news sent shockwaves through the enthusiast community, with many criticizing Google for transforming Android into an iOS-like walled garden.

Google claims its goal is to prevent bad actors from distributing malicious software under a cloak of anonymity. However, many believe the company has an ulterior motive, such as killing emulation on Android or hindering Android-based e-readers. In response, Sameer Samat, President of the Android Ecosystem at Google, said, “Sideloading is fundamental to Android, and it’s not going anywhere.” He added that the company’s new requirements aren’t designed to limit choice but rather to “make sure that if you download an app from a developer, regardless of where you get it, it’s actually from them.”

However, Samat’s statement did little to assuage people’s fears, as it didn’t explain a key part of the equation: the how. We know what Google wants to do (block Android apps from unverified developers), when it wants to do it (starting September 2026 and rolling out through 2027), and why (to reduce malware), but not how it’s going to enforce this policy on devices.

The most obvious method would be through Google Play Protect, the on-device security service available on all certified Android devices. As the system’s Package Verifier, Play Protect already has all the privileges needed to enforce Google’s new developer verification requirements, so it would make a lot of sense for it to take on these new responsibilities, especially since it already comes bundled with Google Mobile Services. But we’ve recently learned that Google is going another route — one that raises more questions than it answers. On the bright side, we’ve also learned that Google may leave some existing mechanisms to sideload apps intact, provided you’re comfortable using developer tools.

You’re reading the Authority Insights Newsletter, a weekly newsletter that reveals some new facet of Android that hasn’t been reported on anywhere else. If you’re looking for the latest scoops, the hottest leaks, and breaking news on Google’s Android operating system and other mobile tech topics, then we’ve got you covered.

Subscribe here to get this post delivered to your email inbox every Saturday.

Coming soon: Android Developer Verifier

Rather than enforce its new developer verification requirements through Play Protect, Google is apparently creating an entirely new system service called Android Developer Verifier. This new app will be responsible for validating whether an application package is associated with a verified Android developer, i.e., a developer who has registered with Google through the new Android Developer Console.

The Android Developer Verifier app can’t be found on current devices, unlike Play Protect (which is part of the Play Store). Instead, it will be distributed in the future, with Google mandating that its OEM partners preload the app on new devices launching with Android 16 QPR2 or later.

Why does it matter that Google is creating a new app instead of using Play Protect? This simple difference could have major ramifications.

First, it means the enforcement of the new developer verification requirements will likely be decoupled from the system’s package verification mechanism, which is handled by Play Protect. Therefore, disabling Play Protect probably won’t disable the Android Developer Verifier, assuming the latter lacks its own opt-out mechanism (which we doubt Google will offer).

I say “likely” because it’s possible the Android Developer Verifier app will communicate with Play Protect in some way, but in that case, why make it a separate app? After speaking with independent security researchers and platform developers, here are a few other potential reasons for this approach:

• It could simply be an organizational matter, where the Android platform security team developed it rather than the GMS (Google Mobile Services) team.
• From a security standpoint, decoupling it from GMS reduces the attack surface. If a malicious app compromises GMS, it could affect everything GMS manages. If Google makes the app open source, then that would allow its code to be independently audited, unlike Play Protect.
• By decoupling it from GMS, devices without GMS could also use the service, assuming Google releases the source code. Custom ROM developers, for example, could then modify the app to add their own trusted sources instead of only using Google’s. Developers who don’t want this feature could ignore the app entirely without affecting GMS functionality.

In my view, these are weak reasons. Google has never really cared for the minuscule number of custom ROM users, so the third point was unlikely a factor in their decision. The first two points make sense from a security and architectural perspective, but the trade-offs are enormous.

Using Play Protect would make it much easier for Google to enforce its new developer requirements, as the service is already on every certified Android device. In contrast, OEMs will have to push updates to include the Android Developer Verifier app. So far, Google has only announced plans to require the app on new devices, with no mention of a mandate for existing phones.

Since Google’s goal is to improve security, it would make sense to require the app on all devices, presumably by pushing OEMs to include it in updates. In that case, though, why leave it up to OEMs, who are known for slow rollouts — or no updates at all — for older devices? And if Google were planning to deploy the Android Developer Verifier app over-the-air (i.e., with no OS update required, similar to Android System SafetyCore), then why require OEMs to integrate it into their builds in the first place?

The decision to make Android Developer Verifier, as I said before, raises more questions than it answers. While it’s nice that custom ROM users could benefit, I’m not sure they have a lot to be excited about given Google’s recent decisions affecting AOSP. If Google is making Android Developer Verifier a separate app so it won’t be turned off when you turn off Play Protect, then that means regular users won’t have an easy time installing apps from outside the Google Play Store using the device’s built-in package installer anymore.

(We reached out to our contact at Google two days ago for a statement regarding the Android Developer Verifier app but didn’t hear back prior to publication.)

Fortunately, there might be a silver lining. On a FAQ page, Google says that you’ll be “free to install apps without verification with ADB.” ADB, or Android Debug Bridge, is a command-line tool used by developers to control their device from a PC. Installing apps via ADB is as simple as downloading the binary onto a PC, downloading the APK file for an Android app, and then executing a command to push and install the app onto a device. There are even open source tools for running ADB commands on-device, which should hopefully make it possible to install unverified apps without the need for a PC.

Allowing installation through ADB would reduce the headache for developers, who frequently need to install apps during early development. It would also allow power users comfortable with command-line tools to continue sideloading, while deterring most casual users — the most common target for scammers and hackers.

We hope that Google keeps its word and preserves ADB installation. The changes don’t go into effect for at least another year, leaving plenty of time for the company to change its mind. While we hope Google will at least allow ADB sideloading, we also realize it may ultimately decide to restrict this method to prevent scammers from exploiting it.

Special thanks to security researcher linuxct for helping review this article!

Want more?

Authority Insights is more than a newsletter — it’s the hub for all our best content. If you care about Android, you won’t want to miss any of our other exclusive reports.

Don’t have time to read them all? Subscribe to our Authority Insights Podcast to hear me and my co-host, C. Scott Brown, break down our top stories of the week.

This week’s top Authority Insights

Big changes are coming to Quick Share, including support for iPhones

Google is cleaning up the Gemini app, Discover feed, and Google Photos libraries

Keep your eyes peeled: Spotify and YouTube Music are getting new designs on Android Auto

More…

Other top stories