0xedbGoogle details new 24-hour process to sideload unverified Android apps
https://android-developers.googleblog.com/2026/03/android-de...
This is going to hurt legitimate sideloading way more than actually necessary to reduce scams:
- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need. This kills the pathway for new users to sideload apps that have similar functionality to those on the Play Store.
The rest -- restarting, confirming you aren't being coached, and per-install warnings -- would be just as effective alone to "protect users," but with those prior two points, it's clear that this is just simply intended to make sideloading so inconvenient that many won't bother or can't (dev mode req.).
>- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
Hi, I'm the community engagement manager @ Android. It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
>- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need.
ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
Someone is just going to make a nice GUI application for sideloading apks with a single drag-and-drop, so if your idea is that ADB is a way to ensure only "users who know what they're doing" are gonna sideload, you've done nothing. This is all security theatre.
> “For a lot of people in the world, their phone is their only computer, and it stores some of their most private information,” Samat said.
Not applying the policy to adb installs makes a lot more sense if the people this is trying to protect don't have a computer
If you mean things like Shizuku or local adb connection through Termux, it's quite an awkward process to set up even for someone like me who's been building Android apps since 2011. Like, you can do if you really really need it, but most people won't bother. You have to do it again after every reboot, too.
Scammers will figure something out to help that workflow smoother, you can count on that.
People who want your money always want to have really great UX. I remember how painless buying lottery tickets online was, it was the smoothest checkout experience in all of online shopping I have ever done.
I've seen a few apps that run locally on Android and hook into the ADB connection over loopback networking to do certain things.
This just adds the step of "download Cool ABD Installer from the play store" to the set of directions I would think.
Google could easily put an end to that if they wanted. Just block adb access from the loopback address and VPN. I'm surprised this isn't already in place. The setup flow for those apps you're referring to is awkward enough that it's clear it was never intentional to be able to access adb on-device.
The scammers don't even need to make a GUI, they just need to get you to enable adb-over-tcp and bridge that to their network somehow - an ssh client app would do the trick.
How many people do you suspect are gullible enough to fall for these scammers but also competent enough to install an SSH client and enable port-forwarding for an ADB proxy? Like fifteen people worldwide?
How many people are gullible enough right now to plug a phone to a laptop over USB and execute an exe on an operating system with no sandboxing at all? ADB even seems to work over webusb. (at that point you may as well give up on hacking the phone, but I digress). That's exactly why I believe the problem is more complicated and why Google's solution is not really fixing anything, not for the users.
There's going to be a lot of people who don't have a laptop/desktop handy right now - because they're out of the house, because it's unplugged in a cupboard, or because they borrow it from a friend or use an internet cafe when they need that. So a requirement to use that and connect your phone to it is effectively similar to the 24 hr waiting period: time to think, time to mention it to a friend who's heard about this scam before. This is why phones are such an attractive target in the first place.
scrcpy can already do that.
Why do you keep harping on about ADB installs. That's not helpful. It doesn't help me install open source apps from FDroid. It's ridiculous that you think booting up a computer and using ADB is a reasonable workaround. It isn't.
You would be able to install f droid and it's apps without going through this flow.
If you enable the advanced flow as described in the Android Developers Blog, then you can install unregistered apps regardless of source. That includes apps from sources like F-Droid.
Don't be mistaken, it's the delay I'm complaining about, not how to instal F-Droid or apps through it.
It is not reasonable to advocate for ADB if the 24 hour wait is too long.
I'll copy what I wrote elsewhere. Fraud uses social tactics and legitimate tools in the vast majority of cases. Developer verification will have absolutely no effect on that.
Impinging on my property rights cannot and will not protect or help fraud victims.
> It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
Ok, but why is this advertised to applications in the first place? It's quite literally none of their business that developer options are enabled and it's a constant source of pain when some government / banking apps think they're being more "secure" by disallowing this.
I don't think Google should be changing Android this way at all, and fear that it will later be used for evil. That said, I thought of an improvement:
Allow a toggle with no waiting period during initial device setup. The user is almost certainly not being guided by a scammer when they're first setting up their device, so this addresses the concern Google claims is driving the verification requirement. I'll be pretty angry if I have to wait a day to install F-Droid and finish setting up a new phone.
Evil, for the record would mean blocking developers of things that do not act against the user's wishes, but might offend governments or interfere with Google's business model, like the article's example of an alternative YouTube client that bypasses Google’s ads. Youtube is within its rights to try to block such clients, but preventing my device from installing them when that's what I want to do is itself a malicious act.
> Allow a toggle with no waiting period during initial device setup
I like this idea in principle but I think it could become a workaround that the same malicious entities would be willing to exploit, by just coercing their victims to "reset" their phones to access that toggle.
That wipes all the data on the device and requires logging back in to accounts. It seems to me that's high enough friction to resist most coercion.
Isn't app data, photos etc. usually synced with the Google account? Besides, Google claims that the scammers are using social engineering to create a feeling of panic and urgency, so I think the victim would be willing to reset and log in to the accounts again in such a frame of mind.
Some is, some is optional, some isn't.
I'm sure there's a hypothetical scenario where someone successfully runs a scam that way, but there's also a hypothetical scenario where a 24 hour wait doesn't succeed at interrupting the scam.
The perfect is the enemy of the good.
I don't think it does because of the workaround I mentioned upthread.
None of this is stopping a malicious entity. We keep trying to use tech (poorly thought out tech at that) to solve issues of social engineering. And no one is asking for a solution, either; it's being jammed in for control.
That's an interesting idea wrt to enabling the advanced flow during initial device setup! I'll pass it along.