Hacker Newsnew | past | comments | ask | show | jobs | submit | MishaalRahman's commentslogin

If it helps, the 24-hour wait is a one-time process. You do it once, click the toggle to allow installing unregistered apps indefinitely, and then install whatever you want. You can even turn off developer options afterwards, per my understanding, and it won't impact your ability to install unregistered apps.


It does not help. This is friction imposed to reduce and eliminate sideloading in the name of safety.

I own my device, I choose the software running on it. Create friction points and I will chose another platform to execute my software.


different strokes i suppose. normally i like being able to use something the same day i buy it

95% of the apps i use are ''side loaded''. that includes a web browser, file browser, all the fossify apps for things like messaging, phone/contacts -- so the phone would be basically be a paperweight until that restriction is removed


For now.


Is the next prioritized epic to disable 24 hour wait for undesirable apks?


That does not help. That is a fundamentally fucking insane limitation that will completely destroy any developer's ability to develop without getting approval from Google. Regardless of my feelings of the annoyance of going through this process myself, 90% of users simply will not go through this process to install apps, killing any potential userbase. Google has no goddamn right to be the sole dictator of who is allowed to develop software for the largest platform in the world, to decide who is allowed to have a career in mobile software development and who is not, and you should be utterly ashamed of yourself for accepting a paycheck to defend this. I hope your shitty company and Apple both get their comeuppance in court for these monopolistic practices, and may we some day get a future where anyone is free to develop software without approval of a central police corp.


1) The one-time, one-day waiting period only applies if you go through the advanced flow to allow installing unregistered apps. You can still install registered apps (ie. apps made by developers who have verified their identity) even if they're distributed outside the Play Store.

2) You can use ADB to immediately install unregistered apps. ADB installs are not subject to the waiting period.


So let's say I'm F-Droid, an organization making a direct competitor to the Google Play Store and openly pointing out how much scammy shit is available in that store. My options are 1) submit my identity to Google (my competitor) so they can identify me and choose to revoke that verification at any point, or 2) I can tell all my users that they must go through these scary dialogs AND wait 1 day before they can use my competing product? That's cool, glad we've got the options laid out in front of us.

I forgot 3) instruct my users how to use ADB from another computer to install my competing app. Awesome.


It's really ridiculous.

You'd think regulators should make Google ship a 'Choose my store(s)' screen at setup, but Google thinks the opposite is the case and Google should also be able to control app distribution outside of the Playstore.


3) And how can we keep on using F-Droid and other app stores?

4) How can we install apps made by devs who won't do the verification dance with Google?


Developers who distribute Android apps on other app stores are not strictly required to undergo verification and thus can remain anonymous, but if they choose not to, then later this year (when the enforcement of verification goes active) their apps can only be installed on certified Android devices via ADB and/or the new advanced flow.

Thus, you can still install unregistered apps if they're distributed via F-Droid or other sources, but to do so, you will need to use ADB and/or go through the new advanced flow. And remember, the new advanced flow is a one-time process - once you go through with it, you can allow your device to install unregistered apps indefinitely!


I only hope this brilliant proposal is met with a new advanced fine from regulators.


Regulators will be super happy to know they can control what you can install on your phone just by telling Google to take apps down.


I know I'm writing a complaint to my country's regulator after this. This is just blatant anti-competitive behaviour.


From https://keepandroidopen.org/ :

"As of the date of this update, it exists only as a blog post and UI mockups. The community is being asked to accept a product announcement as a functional safeguard five months before the mandate takes effect."

"Until Google provides a shipping implementation that can be independently verified, our position remains unchanged: all apps from non-registered developers will be blocked once their lockdown goes into effect in September 2026."


Mishall This sounds illegal.

Bad implementation. Like the SAVE act that requires you to bring your up to date passport just to vote. It's clearly user hostile.


I want to use the apps that don't hellbent on your Google right away. This is MY phone. I paid my money. I don't want Google to dictate what I should do.


1) Fuck

2) Google


asian development bank?


Android Debug Bridge, a CLI for connecting to Android devices: https://developer.android.com/tools/adb


Exactly - the idea is to make it harder for scammers to create a false sense of urgency.


This is too long. It's Google locking in users with hostile user practices.


Right, this friction makes it much harder for a scammer to get away with saying something like, "wire me $10,000 right now or you won't see your child ever again!" as the potential victim is forced to wait 24 hours before they can install the scammer's malicious app, thus giving them time to think about it and/or call their trusted contacts.


The sheer arrogance that you think someone manipulated successfully will just re-think the situation and ask their friends/family. The naivety to assume all scammers are impulsive fools and don't do this for a living, as their primary line of work.

So Google's going to add some nonsense abstraction layer and when this fails to curb the problem after a 24 hour wait, it will be extended more maybe a week, and more information must be collected to release it. We all know how this goes.


Potencial victim's AI agents will wait patiently those 24 hours. In fact it may just wait exactly 24 hours and not one more second.


Goalposts moving, who says this on an official forum?


>Developers, including non-US citizens, are forced to give Google their government ID to distribute apps.

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.

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.


My friend's little kid likes to make games that he and his friends can play. As far as I am aware, these apps don't require any permissions.

Are apps like this more dangerous than browsing to a website? I thought they were entirely sandboxed from the rest of the device?


Not quite. You can do a lot of stuff that requires no permissions, or at least not ones that the user has to confirm (e.g. you get internet permission, sensor access, always run in the background etc. by default, but you do need to declare this in the manifest file iirc), which isn't possible on websites like that (a website will ask before it lets a site do limited things while you think the tab is closed)

Depending on your threat model, it might be mostly harmless


> Developers can choose to not undergo verification, thereby remaining anonymous. The only change is […]

"The only change" – with all due respect, are you even listening to yourself? The "only change" is that you, as a developer, will be completely excluded from publishing apps in the Play Store and that people effectively won't be able to install your app anymore! (Unless you were targeting only e.g. F-Droid users to begin with, which very few apps do.)

In essence, you are cutting down on the privacy of tens of thousands of honest developers around the world in the name of protecting users from scammers and you're pretending that 1) it's a nothingburger and 2) developers have a choice.


>The "only change" is that you, as a developer, will be completely excluded from publishing apps in the Play Store

Google Play already requires developer verification: https://support.google.com/googleplay/android-developer/answ...


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.

If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.


Why can't stores take over the "verification" process (like they do already)? Why do app developers have to be verified themselves, why does the verification have to be done by google? There are so many options, why choose google of all companies? Just laziness?


If I understand correctly, the F-Droid store itself would be possible to install without waiting period, as it's an app from a verified developer.

Would apps installed from F-Droid be subject to this process, or would they also be exempt? Could that be a solution that makes everyone happy? Android already tracks which app store an app originates from re: autoupdating.

Also: Can I skip the 24h by changing the my phone's clock?


> as it's an app from a verified developer.

Well that's if they go through the verification process, which does not seem like a thing they'd want to do - https://f-droid.org/en/2026/02/24/open-letter-opposing-devel...


If one verified app can install many unverified apps, either aurora droid or fdroid basic or one of the many other frontends would end up offering that feature quickly.

But there's been some comments that even that wouldn't be possible, every app would have to be verified individually, or be signed by a developer with less than 20 installs.

(Which of course then begs the question: Why not build a version of Fdroid that generates its own signing key and resigns every app on device?)


>- 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.


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.


Agreed. I also don't think this should be in developer settings; it's kinda insulting to imply that only developers need to have full control of their own devices.

Personally those two changes would mollify me somewhat, though the slippery slope concerns others have discussed in this thread remain. Additionally, I think there's a real anti competitive concern in that these changes negatively impact the market for non-Google-approved apps. (Perhaps the latter could be solved by allowing alternate app stores like F-Droid to completely bypass the verification requirement, allowing those stores' internal app verification processes to compete on equal footing with Google's.)


> 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.


Which applies just the same to the hypothetical option during initial device setup.


I don't think it does because of the workaround I mentioned upthread.


The victim also can't be on the phone with the scammer using that device during the setup process. We're talking about a very high-friction scenario.


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.


Such a silly statement. Of course tech can solve social engineering problem, we do so every day startign from UX design. This is a good solution to killing urgency.


Ux is made for humans. Humans can learn to exploit UX. This is as useless a battle as fighting piracy: you will destroy your product before you solve the problem.


Social engineering is destroyed with education, not with restriction and control.

Trading freedom for safety eliminates both.


That's an interesting idea wrt to enabling the advanced flow during initial device setup! I'll pass it along.


> 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.


> 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


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.


You can run adb install locally without 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.


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.


More than the number of people who will wait 24h


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.


How? Reading this it seems like only verified developers can skip this process. Most Fdroid developers won't be verified. I don't see where it says Fdroid would be exempt from this requirement. Would Fdroid be a verified developer?


No. F-Droid builds the apps on their server, and they cannot sign the apps with the developer's keys because that would require them to have access to the developers' Google accounts


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.


The only reason I run android over iOS is the freedom to install things I want on it. A waiting period is unacceptable as Android has proven that it can't be trusted not to tighten the grip further.

Reconsider.


If you prefer to keep your freedom when Android removes it, you may want to try GNU/Linux phones. Sent from my Librem 5.


The only reason I use an Android instead of an Apple phone is that I can install two apps off of github. I am actively making a certain number of very quantifiable sacrifices already at this very moment by not stepping into the orchard.

If you go forward with this, I am not coming back. I will never again in my life trust you. And believe me - I still have boycotts on-going 20 years later. Including microsoft. It is surprisingly easy to avoid you "Ubiquitous" companies once you get your mind into it.


Why don’t you create an option to bypass this whole thing permanently on adb then? You can even add your 24h delay.

I’m not convinced this is really to protect users from being hurt by scammers, it is really about protecting the users from doing what hurts your company interests.


>Why don’t you create an option to bypass this whole thing permanently on adb then? You can even add your 24h delay.

When you enable the advanced flow and choose the 'indefinite' option, that allows you to install unregistered apps 'permanently', which is effectively what you're asking for, no?

(I've gotten questions on whether this setting can be restored after a factory reset or when setting up a new device - I'll have to get back to you on that if you're wondering.)


> When you enable the advanced flow and choose the 'indefinite' option, that allows you to install unregistered apps 'permanently', which is effectively what you're asking for, no?

Is it a process that you do once and applies to any unregistered app I install now or in the future? Or do you have to repeat it for installing or upgrading different apps?

If it is the former then yes, it is effectively the same.


From the article:

> This flow is a one-time process for power users


At what point will you draw the line between "the user wants to do this because of his/her free will" and "the user wants to do this because someone else told them to"? Where will you stop?

All of this is just a bandaid, so why not stop at the state we are at _right now_, without some kind of 24h-long process to enable sideloading and let people be people? Yes, people make mistakes. But that is not your responsibility, especially if it comes at the cost of freedom. The most secure android device would probably be a brick, but you won't sell these, right?

Please instead take these resources and invest them into the app verification process in the play store. Way too many scams are right under your nose, no need to search in places where people are happy with the status quo.


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.


I think this is a "don't let the perfect be the enemy of the good thing". It's technically possible to get around, but adding more speed bumps in the way of scammers tends to drastically reduce the number of people who get scammed.


It's adding more speedbumps because one drunk person a few years ago ran into a tree. it still won't stop that, but now everyone suffers.


What good?


Will third party apps like bank apps be able to detect whether advanced mode is enabled or not, like how they currently detect if developer options is enabled?


That I'm not currently sure of.


> I'm the community engagement manager

On a scale from "not worried" to "let them eat shit", how is the product team thinking about the breakage you'll get from people moving off platform?


I don't want to install via ADB at all. This is MY phone.


So give me a way to completely disable this nonsense via ADB.

This is hot garbage. Eliminating third party app stores like F-Droid defeats the whole purpose many of us even bother running Android instead of locked down Apple stuff.


May I use ADB or Developer mode to disable the one-day period?


Yes, ADB disables the 1-day period.


How do you know this? It's been confirmed that you can use adb to temporarily bypass verification on a per-app basis, yes, but from what I can see, there's no indication that sideloading one app over adb will also skip the 1-day period.

This matters if you're sideloading an app store like F-Droid, because sideloaded app stores still have to go through PackageInstaller [1], which probably still enforces verification checks for adb-sideloaded apps?

[1] https://developer.android.com/reference/android/content/pm/P...


I see the chosen language of "certain unregistered applications" (I suppose company mandated) already hints on the goal of control aspect. I want to deploy apps on my device. They are my apps, it’s my device, and I should not be required to ask for permission to do so.


Can you answer this question:

If you install F-Droid via ADB, can F-Droid then install the apps from its catalog?


If you enable the advanced flow as described in the linked Android Developers Blog, then you can install any unregistered app, which includes those distributed by app stores like F-Droid.


Sorry if I wasn't clear, my question was about using adb so I don't have to do this process (so I don't have to wait 24h).

Buy a new phone, install F-Droid via adb, install F-Droid apps (the same day): is that possible?


> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.

if that's the case, why would the new flow help reduce fraud and scams? These are meant to be roadblocks, which the ADB bypass will just...you know, by pass it? Why can't the scammer coach the victim to use this instead then?


Do I need to be signed in to Google play to get the sideloading exception turned on? I don't sign in to it because I don't want to have my phone associated with a Google account. But I can't uninstall play completely on the devices I have.

It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?

> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.

Um yeah but then do I have to install every update via adb? I want to just use F-Droid.


I think the authentication is doing your face/fingerprint/passcode unlock?


Correct.


>It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?

You're authenticating that you're the device owner (via your device's saved biometrics or PIN/pattern/password).

>Um yeah but then do I have to install every update via adb? I want to just use F-Droid.

No, once you go through the advanced flow and choose the option to allow installing unregistered apps indefinitely, you can both install and update unregistered apps without going through the flow again (or using ADB).


This part I don't understand. I want to allow for a couple minutes, the time to install a unregistered app, and then go back to deny. I don't want to allow "for 7 days" or "indefinitely". In the text and screenshot of the announcement I see that you can switch these feature "on", but can they be switched "off"?


Ah thanks I'm glad I don't need a Google account to enable this.


Can apps detect whether the advanced flow for sideloading is enabled or not?


> ADB installs are not impacted by the waiting period

"If you don't like the food we're serving, you can always buy a farm"


Every single one of these steps are blatantly an attack on user freedom. The steps to unlocking the bootloader and install a different rom are not nearly as onerous. The only thing I will accept as reasonable, is a complete abandonment of this policy. Google has destroyed all trust I could have in it, and these weaselly worded concessions are based on a bullshit premise.


Thank you so much for clarifying! That is most definitely not as bad as I had feared.

I still feel, though, that having to go ahead and proclaim “I am a developer!” just to enable sideloading is a bit much, as almost certainly the vast majority of sideloaders aren’t developers. Nonetheless, it does keep sideloading as an option, and I do see why, from Google’s perspective, using the already-existing developer mode to gate the feature would be convenient in the short term. Perhaps the announcement should specify this -- I suspect a number of people who read it also noticed the lack of that clarification.

And yes, good point on ADB. That does make this less inconvenient for developers or power users, though doesn’t help non-developers very much.


A detailed breakdown of the settlement agreement between Google and Epic that was recently unveiled on Tuesday evening.


Seang is referring to Cuttlefish, which is indeed a virtual Android device that can be run on PCs.


This is not a dupe, this is a follow up to the original story.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: