Android may soon restrict on-device ADB

When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.

Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key.

This once again isn't about security of users, this is about security of the company's interests.

In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.

I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.

Ads and tracking, obviously (https://localmess.github.io/)

All these changes Google is doing to Android aren't for you as the user, they are to protect their business interests from the user.

It depends on how you define a bad actor.

"rootless privacy tools based on Shizuku."

It's not for the security of the owner; it is for the security of the government.

Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.

The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...

Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.

Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...

In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.

This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass (or even if another app did it).

But sure, Google evil.

Speak for yourself. Sent from my GNU/Linux phone Librem 5.

Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.

I think there's a difference between criticism of a policy and being brigaded by a reddit mob.

Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.

I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.

That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.

Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video games. Can't do pretty much anything.

That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.

This is not even Google's mindset, the control strings of this mindset stretch far beyond its management and board of directors.

That's the OBEY from the timeless Carpenter's classic.

We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.

You mean the new recaptcha that requires remote attestation?

https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...

Obviously, it doesn't have the fee part. But Google can decide soon for a substantial number of websites which devices can visit them and which not.

You would have the "new web" consisting of the top n major websites paying this fee.

And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.

You don't have to pay a fee directly, but you can't use open source web browsers.

edit: I not realizing that I been replying to wrong comment

I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.

(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

The only other alternative available is SMS but that is being phased out (rightly so) for being insecure.

For the popular apps you mention, there is Waydroid to run Android apps.

Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.

They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.

The article shows that this is technically possible for bad actors to use it, assuming the user allow it, but highly unlikely in practice: https://kitsumed.github.io/blog/posts/android-may-soon-restr...

I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.

I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.

EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.

as long as such personal freedoms gives users the ability to skirt the profit motives of companies making these devices, there will always be a force to try restrict it.

The internet, as it has been, is quite an anomaly, but inevitably, power that the people have gets usurped one way or another. It's just a matter of time.

Not saying it will be good or arrive anywhere in the next 5 years but they are very persistent and that tends to work in their favour.

and google is doing all they can to try shut it down, because they saw how profitable a walled garden like iOS really is.

and conveniently, google now has access to your photo, the meta data, and potentially able to scan it for advertising purposes.

Not everyone has the same threat model as you, $BIGTECHCORP.

"Changing between A and B requires a device reset."

Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.

Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)

That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.

Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.

And why should modern corpo maintain additional complexity to pander to 1% of privacy-aware tech-savvy users?

It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup.

At that point, ADB no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.

As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.

Like Google Mobile Services on stock Android?

For most, this is the last resort / only way possible. As AOSP refuse to add secure permission or services to allow third-party application to do specific actions.

If this get fixed, it will be the end of thoses project on-device for non-rooted ROMs. Sure, you could still run it via a computer, or to be far fetched, start Shizuku via a computer. But that's no longer "on-device". It kill a lot of usages, including developers who need it "on-the-fly".

I personally don't have a problem with a mediocre-performance phone but it should not be expensive. Not to mention app ecosystems - there aren't a lot of Linux apps for Linux phones.

It doesn't get better even if you pay 2500$, which is extra silly.

It's just that few people bother using it. But that number might increase if Android continues it's war against its users.

Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.

[1]: https://github.com/rikkaapps/shizuku#how-does-shizuku-work

Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.

> Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?

You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.

FWIW, similar kinds of attacks is exactly why side-loading apps is about to require a reboot and 24 hour cooldown. Which you mention at the end. It sucks, but it's a decent compromise; power users like me will just do the dance and pick the "indefinite" option the moment they unpack their new phone, and rest of the people will never even know about it until they're half-way through being scammed.

I personally don't believe doing anything more in this direction is warranted.