Google’s Android Boss Confirms: Sideloading Isn’t Going Anywhere — Here’s What’s Changing and What’s Not
If you have been watching Google’s developer verification policy rollout with growing anxiety about the future of Android’s openness, Sameer Samat — head of Android at Google — has a direct message for you. Speaking in a recent interview with Android Authority, Samat was unambiguous: sideloading is not being removed from Android. It is not being phased out. But it is being made smarter — and that distinction matters enormously for understanding what Google is actually trying to do.
The Confirmation Android Users Have Been Waiting For
Sameer Samat, head of Android at Google, has confirmed that sideloading remains something that will continue on Android, saying it’s not going away, in a recent interview with Android Authority.
For a community that has spent months watching Google’s mandatory developer verification policy take shape — and more than 40 organizations including Proton, AdGuard, the Tor Project, the EFF, and F-Droid sign the Keep Android Open letter in protest — this is a meaningful statement from the top of the Android organization. Not a PR spokesperson, not a blog post, not an inferred policy position. The person responsible for Android’s direction saying plainly: sideloading is staying.
Sideloading has always been something that Android supported — in stark contrast to Apple’s iPhone — allowing owners to install apps that don’t come from Google Play.That fundamental distinction is what has defined Android’s relationship with power users, developers, privacy advocates, and the open-source community for over fifteen years. Samat’s confirmation preserves it.
This is directly relevant context for our earlier coverage of the developer registration policy backlash. At the time, coalition organizations warned that mandatory registration requirements — even for apps distributed outside the Play Store — represented what they called an “alien security model” for Android. Samat’s interview is Google’s clearest response to that criticism yet: the direction is not to close Android, but to add identity to it.
Why Google Is Changing Anything at All
Understanding what is actually changing requires understanding the problem Google is trying to solve — and Samat was candid about the scale of it.
Google recently noted there is “50 times more malware from internet-sideloaded sources” than from Google Play. That, according to the tech giant, saw governments pushing the company to address the problem.
Fifty times more malware. That is not a marginal risk differential — it is a categorically different threat surface. And when governments begin pressuring a platform provider about the security outcomes of their distribution model, the options are limited: restrict the capability, or add accountability to it. Google has chosen accountability.
Samat freely admitted that “the warnings we currently have are insufficient,” which is why developer verification is coming in to protect users.
This is an honest concession. The current Android sideloading warnings — vague alerts about unknown sources, permission dialogs that power users dismiss in seconds — were designed for a threat landscape that has changed dramatically. Modern malware is sophisticated, socially engineered, and deliberately designed to look like legitimate software. A generic “this app is from an unknown source” warning provides almost no real protection against a convincingly branded fake banking app or a malicious overlay tool.
What the New System Will Actually Look Like
The developer verification system Samat describes is designed to add a layer of identity to the sideloading flow without blocking it. The distinction is important: this is attribution, not gatekeeping.
The result will be that apps need to come from verified developers before they can be installed on certified Android devices. It will allow verified developers to distribute apps directly if they want to, but users will have an additional layer of protection.
In practice, this means that when a user attempts to install an app from outside the Play Store, the system will be able to tell them who made it — not just that it came from “an unknown source.” That is a fundamentally more useful piece of information for making an informed installation decision.
Samat explained: “We would like to be able to tell the user this app is from this source. Now, that doesn’t mean that the app is safe. The user still has to make decisions. But at least you know who it’s from, and you can decide better — do I trust this person, or do I not? That’s very important.”
That framing is the key to understanding Google’s intent here. The system is not trying to make installation decisions for users. It is trying to give users the information they need to make better decisions themselves. The agency stays with the user. The malware actor simply loses the anonymity that makes social engineering attacks so effective.
What Happens to Power Users and Developers
The question that privacy advocates, custom ROM enthusiasts, hobbyist developers, and F-Droid users have been most concerned about is whether the verification requirement will create an impossible barrier for legitimate unverified software. Samat’s answer addresses this directly.
Confirming previously reported news, Samat said: “We will have a flow that allows more sophisticated users to install software that has not been verified.” This will allow “experienced users” — such as hobbyists — to install their own apps, while making it more difficult for casual users to accidentally install malware.
This is a tiered approach rather than a binary one. Casual users — those most at risk from social engineering attacks, those least likely to understand what sideloading is or what risks it carries — will encounter significantly stronger friction before installing unverified software. That friction is the protection. Power users, developers building their own apps, enthusiasts running custom ROMs, and users deliberately choosing to install unverified software will have a path to do so.
The exact mechanics of how the “experienced user” flow will work — what the UX looks like, what verification steps it requires, whether it involves a one-time permission grant or a per-app decision — have not yet been fully specified publicly. That detail will matter significantly for the developer community, and it will be worth watching closely as Android 17’s beta cycle progresses toward the June 2026 stable release.
The Tension Google Is Navigating
Android has thrived because of its open nature. That’s one of the things that has attracted users and developers, while Apple continues to be a lot more closely regulated — a “walled garden,” as it’s often referred to. For many Android users, giving up those freedoms would be to abandon the reason they were attracted to the platform in the first place, so it’s a balance between maintaining openness for fans, while protecting those a little less savvy.
Samat is not wrong about this tension, and Google has no clean resolution to it. Every security measure that protects a novice user is also friction that frustrates an expert one. The history of Android’s security evolution is a history of Google attempting to walk this line — adding protection incrementally while preserving the openness that defines the platform’s identity.
What has changed in 2026 is the external pressure. Governments pushing back on malware distribution, the Epic settlement reshaping the Play Store’s competitive dynamics, and the growing adoption of Android in enterprise and healthcare contexts where security posture matters as a procurement criterion — all of these forces are pushing Google toward more accountability in the sideloading ecosystem. Developer verification is Google’s answer to all of them simultaneously.
For the privacy community specifically — the organizations that signed the Keep Android Open letter — the question now becomes whether the implementation of the “experienced user” bypass flow is genuinely accessible or whether it becomes a bureaucratic obstacle in practice. Google’s stated intent is the former. The advocacy community will be watching the actual implementation closely.
Where This Fits in the Bigger Android Ecosystem Picture
Samat’s confirmation connects directly to several other major platform shifts happening simultaneously in 2026. The new Registered App Stores program — part of the Google Play policy overhaul following the Epic Games settlement — creates a formal, OS-level pathway for third-party app stores to operate on Android with reduced friction. That program and the developer verification system are two sides of the same coin: making alternative distribution more legitimate and accountable, not less possible.
Android 16’s new anti-scam call protection — which we covered in detail in the Fairphone 6 Android 16 update article — blocks sideloading permission grants during active phone calls, directly targeting the most common vector for socially engineered sideloading attacks. That platform-level protection and the developer verification system are complementary defenses operating at different layers.
And for developers building apps intended for distribution outside the Play Store — through their own websites, through alternative app stores, or directly to enterprise customers — the developer verification requirement means that registering with Google becomes a practical requirement for reaching Android users even outside Google’s own distribution channel. That is the aspect of the policy that the Keep Android Open coalition has pushed back on most forcefully, and it remains the most genuinely contested element of Google’s approach.
The full implementation of developer verification is targeted for September 2026. Between now and then, the details of the experienced-user bypass flow and the exact registration requirements for unverified distribution will define whether the policy ultimately lands as a genuine security improvement or as the “alien security model” its critics warned about. Based on Samat’s interview, Google’s intent is clearly the former — but intent and implementation are two different things.