Death, taxes and <i>escalating safety</i> are the only certainities in this tech dominated world. So, be ready for more safety in the next round few months/years down the line. Eventually Android will become as <i>secure</i> as ios. We need a third alternative before that day comes.<p>It's not a win by any means. I hope that we don't stop making noise.
This is going to hurt legitimate sideloading <i>way</i> more than actually necessary to reduce scams:<p>- 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?<p>- 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.<p>The rest -- restarting, confirming you aren't being coached, and per-install warnings -- would be just as effective <i>alone</i> 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.).
The one-day waiting period is so arbitrary. Have they demonstrated any supporting data? We know google loves to flaunt data.<p>Something like Github's approach of forcing users to type the name of the repo they wish to delete would seem to be more than sufficient to protect technically disinclined users while still allowing technically aware users to do what they please with their own device.
To paste code into the chrome dev console you just need to type “allow pasting”
> The one-day waiting period is so arbitrary.<p>Scammers aren't going to wait on the phone for a day with your elderly parent.
Scammers already will spend multiple days on a scam call. Watch some Kitboga videos, he'll strings them along for a week.<p>"Google will call you again tomorrow to get you your refund."<p>There, we've successfully circumvented all of Google's security engineering on this "feature."
Sure, but what about a 30 minute delay? 1 hour? 2 hour?<p>24 is just so long.<p>But also, my expectation is that a scammer is going to just automate the flow here anyways. Cool, you hit the "24 hour" wait period, I'll call you back tomorrow, the next day, or the next day and continue the scam process.<p>It might stop some less sophisticated spammers for a little bit, but I expect that it'll just be a few tweaks to make it work again.
Have you ever watched Kitboga? Scammers call people back all the time. They keep spreadsheets of their marks like a CRM. It takes time to build trust and victimize someone, and these scammers are very patient.
> - 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?<p>What apps are those? I've yet to run into any of my banking apps that refuse to run with developer mode enabled. I've seen a few that do that for rooted phones but that's a different story. I've been running android for a decade and a half now with developer mode turned on basically the whole time and never had an app refuse to load because of it.
Wero in Europe. It's really insane. They make wero to make us less dependent on US tech and then hamstring it in this way.
RBC in Canada for instance, just having developer mode enabled blocks it here
>- 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?<p>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.<p>If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.<p>>- 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.<p>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.<p>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.<p>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
So... we're just going to move the scam into convincing the end user to run an application on their PC to ADB sideload the Scam App. Got it, simple enough. It's not hard to coach a user into clicking the "no, I'm not being coached" button, too, to guide them towards the ADB enable flow.
We'll see when this rolls out, but I don't foresee the package manager checking for developer mode when <i>launching</i> "unverified" apps, just when <i>installing</i> them. AFAICT the verification service is only queried on install currently.
Googler here (community engagement for Android) - I looked into the developer options question, and 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.<p>If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
You have to wait one day only once, when enabling the feature. I agree that enabling developer mode could be a problem but mostly because it's buried below screens and multiple touches. As a data point, I enabled developer mode on all my devices since 2011 and no banking app complained about it. But it could depend by the different banking systems of our countries.
As described developer mode is only required at install time. Remains to be seen in the actual implementation, but as described in the post developer mode can be switched off after apps have been side loaded.
> some apps (e.g., banking apps) will refuse to operate and such when developer mode is on<p>JFC. Why would an app be allowed to know this? Just another datapoint for fingerprinting.
Yes, it is really dumb that some of these settings are exposed to all apps with no permission gating [0]. But it will likely always be possible to fingerprint based on enabled developer options because there are preferences which can only be enabled via the developer options UI and (arguably) need to be visible to apps.<p>0: <a href="https://developer.android.com/reference/android/provider/Settings.Global#DEVELOPMENT_SETTINGS_ENABLED" rel="nofollow">https://developer.android.com/reference/android/provider/Set...</a>
Do you need a Google account to opt out of the restriction? It says something about authenticating.<p>I don't have a Google account on my Androids. But I can't remove play services on them, sadly. As an intermediate protection I just don't sign in to Google play, that gives them at least a bit less identifying information to play with.<p>I hope this can be done without a Google account.
The forced ID for developers outside the Play store is already killing open source projects you could get on F-Droid. The EU really needs to identify this platform gatekeeping as a threat. As an EU citizen I should not be forced to give government ID to a US company, which can blacklist me without recourse, in order to share apps with other EU citizens on devices we own.
Is there an accurate, neutral third party link about this that we can make the primary link instead?<p><a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...</a>?<p>Edit: I've put one up there now - if there's a better article, let us know and we can change it again. I put the submitted URL in the toptext.
That's a lot of words to explain how to install things on the device I supposedly own.<p>Wondering how long the blogpost would be if it explained what the flow for corpoloading applications approved by Google's shareholders would be?
This 24-hour wait time nonsense is a humiliation ritual designed to invalidate any expectation of Android being an open platform. The messaging is very clear and the writing's on the wall now, there's nowhere to go from here but down.
It's getting harder and harder to be an Android enthusiast. Especially given the hypocrisy of Google Play containing an awful lot of malware.
I'm generally OK with this, but the 24 hour hang time does seem a bit onerous.<p>Most of the apps on my phone are installed from F-Droid. I guess the next time I get a new phone I'll have to wait at least 24 hours for it to become useful.<p>I'm seriously considering Graphene for a next personal device and whatever the cheapest iOS device is for work.
The apps might not be available though. Many developers are simply stopping in the face of Google's invasive policies. I don't blame them. Say goodbye to useful apps like Newpipe.
If my employer wants me to use a phone for work, they can buy whatever phone they want for me. I'm not going to buy a separate one just for them.
24 hour mandatory wait time to side load!? All apps I want to use on my phone are not in the Play Store. So I buy a new phone (or wipe a used phone) and then I can’t even use it for 24 hours?
Am I going to have to wait 24hrs to have Google's malware and spyware forceloaded onto my phone, or is this a different category of malware?
The 24 hour wait period is the largest of the annoyances in this list, but given that adb installs still work, I think this is a list of things I can ultimately live with.
This is eminently reasonable.<p>Now if only Android would allow for stronger sandboxing of apps (i.e. lie to them about any and all system settings).
Can you set your clock forward or does this also require phoning home to a central server to install an app on your computer?
Honestly, <i>if coerced sideloading is a real attack vector</i>, then this seems to be a pretty fair compromise.<p>I just remain skeptical that this tactic is successful on modern Android, with all the settings and scare screens you need to go through in order to sideload an app and grant dangerous permissions.<p>I expect scammers will move to pre-packaged software with a bundled ADB client for Windows/Mac, then the flow is "enable developer options" -> "enable usb debugging" -> "install malware and grant permissions with one click over ADB". People with laptops are more lucrative targets anyway.
> Honestly, <i>if coerced sideloading is a real attack vector</i>, [...]<p>I don't believe that it is. I follow this "scene" pretty closely, and that means I read about successful scams all the time. They happen in huge numbers. Yet I have never encountered a reliable report of one that utilized a "sideloaded"[1] malicious app. Not once. Phishing email messages and web sites, sure. This change will not help counter those, though.<p>I don't even see what you could accomplish with a malicious app that you couldn't otherwise. I would certainly be interested to hear of any real world cases demonstrating the danger.<p>[1] When I was a kid, this was called "installing."
I predict that they're going to introduce further restrictions, but I think the restrictions will only apply to certain powerful Android permissions.<p>The use case they're trying to protect against is malware authors "coaching" users to install their app.<p>In November, they specifically called out anonymous malware apps with the permission to intercept text messages and phone calls (circumventing two-factor authentication). <a href="https://android-developers.googleblog.com/2025/11/android-developer-verification-early.html" rel="nofollow">https://android-developers.googleblog.com/2025/11/android-de...</a><p>After today's announced policy goes into effect, it will be easier to coach users to install a Progressive Web App ("Installable Web Apps") than it will be to coach users to sideload a native Android app, even if the Android app has no permissions to do anything more than what an Installable Web App can do: make basic HTTPS requests and store some app-local data. (99% of apps need no more permissions than that!)<p>I think Google believes it should be easy to install a web app. It should be just as easy to sideload a native app with limited permissions. But it should be very hard/expensive for a malware author to <i>anonymously</i> distribute an app with the permission to intercept texts and calls.
I don't think Google has a strategy around what should be easy for users to do. PWAs still lack native capabilities and are obviously shortcuts to Chrome, and Google pushes developers to Trusted Web Activities which need to be published on the Play Store or sideloaded.<p>But these developer verification policies don't make any exceptions for permission-light apps, nor do they make it harder to sideload apps which request dangerous permissions, they just identify developers. I also suspect that making developer verification dependent on app manifest permissions opens up a bypass, as the package manager would need to check both on each update instead of just on first install.
> But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.<p>And how hard/expensive should it be for the developer of a legitimate F/OSS app to intercept calls/texts?
Yep, I have a legitimate use case for exactly this. It integrates directly with my application and gives it native phone capabilities that are unavailable if I were to use a VoIP provider of any kind.
As a legitimate developer developing an app with the power to take over the phone, I think it's appropriate to ask you to verify your identity. It should be an affordable one-time verification process.<p>This should not be required for apps that do HTTPS requests and store app-local data, like 99%+ of all apps, including 99% of F-Droid apps.<p>But, in my opinion, the benefit of <i>anonymity</i> to you is much smaller than the harm of anonymous malware authors coaching/coercing users to install phone-takeover apps.<p>(I'm sure you and I won't agree about this; I bet you have a principled stand that you should be able to anonymously distribute malware phone-takeover apps because "I own my device," and so everyone must be vulnerable to being coerced to install malware under that ethical principle. It's a reasonable stance, but I don't share it, and I don't think most people share it.)
For a security-sensitive permission like intercepting texts and calls, I'm not sure it makes sense for that to be <i>anonymous</i> at all, not even for local development, not even for students/hobbyists.<p>Getting someone to verify their identity before they have the permission to completely takeover my phone feels pretty reasonable to me. It should be a cheap, one-time process to verify your identity and develop an app with that much power.<p>I can already hear the reply, "What a slippery slope! <i>First</i> Google will make you verify identity for complete phone takeovers, but soon enough they'll try to verify developer identity for <i>all</i> apps."<p>But if I'm forced to choose between "any malware author can anonymously intercept texts and calls" or "only identified developers can do that, and maybe someday Google will go too far with it," I'm definitely picking the latter.
tl;dr:<p>- You need to enable developer mode<p>- You need to click through a few scare dialogs<p>- You need to wait 24h once<p>I wonder how long this will last before they lock it down further. There was a lot of pushback this time around and they still ended up increasing the temperature of the metaphorical boiling frog. It still seems like they're pushing towards the Apple model where those who don't want to self-dox and/or pay get a very limited key (what Google currently calls "limited distribution accounts").
Those working in Google (AOSP) that write these code should be ashamed of themselves. Eventually they are doing a bad thing for the society.
I'll say it again: this isn't a problem for Android to solve. Scammers will naturally adapt their "processes" to account for this 24-hour requirement and IMO it might make it seem more legitimate to the victim because there's less urgency.<p>The onus of protecting people's wealth should fall on the bank / institution who manages that persons wealth.<p>Nevertheless, this solution is better than ID verification for devs.
Why should the bank/institution be responsible for protecting individuals from themselves? They don't have police power- protecting people from bad actors is like, <i>the</i> reason to have a state. If the state wishes to farm it out to third parties, then we don't need the state anymore!
Yea I have no idea why the original commenter thinks Banks should have the power to tell me what I can and can't do with my own money.<p>It's nice that Zelle has checks and identity information shown to you when you're sending money, but if I click through 5 screens that say "Yes I know this person" but I actually don't.....no amount of regulation is going to solve that.
The bank/institution is where the money is leaving from therefore they should implement policies that protect vulnerable customers like seniors, for example. I don't know how that looks but it seems reasonable that they could put limits on an account flagged "vulnerable person"<p>I'm not sure what you're getting at with the rant about police power and a state? Google isn't the government either. What would legislation provide that banks can't already do today?
It's not like the Google Play store hasn't been known to host malicious apps, yet you are not required to wait 24 hours before you install apps from their store.<p>I suspect they are hoping users just give up and go to the play store instead. Google touts about "Play Protect" which scans all apps on the device, even those from unknown sources so these measures can barely be justified.<p>Imagine if Microsoft said you need to wait 24 hours before installing a program not from their store, which is against the entire premise of windows.<p>Computing, I once believed was based on an open idea that people made software and you could install it freely, yes there are bad actors, but that's why we had antivirus and other protection methods, now we're inch by inch losing those freedoms. iOS wants you to enter your date of birth now.<p>The future feels very uncertain, but we need to protect the little freedoms we have left, once they're gone, they're gone for good.
Seems like a very reasonable compromise. What's the catch?
Developers, including non-US citizens, are forced to give Google their government ID to distribute apps. This enables Google to track and censor projects, like NewPipe, an alternative open source Youtube frontend, by revoking signing permissions for developers.
>Developers, including non-US citizens, are forced to give Google their government ID to distribute apps.<p>Developers can choose to not undergo verification, thereby remaining anonymous. The only change is that their applications will need to be installed via ADB and/or this new advanced flow on certified Android devices.<p>Either way, you can still distribute your apps wherever you want. If you verify your identity, then there are no changes to the existing installation flow from a user perspective. If you choose not to verify your identity, then the installation will still be possible but only through high-friction methods (ADB, advanced flow). These methods are high-friction so anonymous scammers can't easily coerce their victims into installing malicious software.
That's not correct - the flow described in the post outlines the requirements to install any apps that haven't had their signature registered with Google.<p>That means those apps still keep on existing, they are just more of a hassle to install.
This. Side loading being restricted is only one part of the problem; the other is mandatory developer verification for apps distributed through the Play Store.
I don't see that on the page
They already announced it. Here they only mention the special case where it does not apply:<p>> In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee.<p>i.e. Government-issued ID and fees are needed for more than 20 devices, e,g, every app on F-Droid
<a href="https://developer.android.com/developer-verification" rel="nofollow">https://developer.android.com/developer-verification</a><p>Note that the OP is about side loading, i.e. installing apps from non-Play Store sources and thereby circumventing developer verification.
I don't find it reasonable that Google wants to make me wait 24h to install software on a device I own.
Meh. I get the annoyance, but it's a one time cost for a small subset of their users. I would prefer if there was a flow during device setup that allowed you to opt into developer mode (with all the attendant big scary warnings), but it's a pretty reasonable balance for the vast majority of their users. (I suspect the number of scammers that are able to get a victim to buy a whole new device and onboard it is probably very low).
They'll just remove the "Advanced" ability in a few years once they've frog boiled people into jumping through hoops to use their phone the way they want.
That I have to wait 24 Hours on my own device to install software?
It's a little inconvenient for someone setting up a new phone to have to wait a full day to install unregistered apps. But while I can't speak for others, it's a price I'm personally willing to pay to make the types of scams they mention much less effective. The perfect is the enemy of the good.