Android may soon restrict on-device ADB(kitsumed.github.io)
kitsumed.github.io
Android may soon restrict on-device ADB
https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/
483 comments
Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to continue using it in any meaningful capacity, because Google does not want you to develop applications on Android outside their controlled channels -- and it's a developer bridge, the battle was already lost when they did not back down from the changes forbidding normal, legitimate ̶s̶i̶d̶e̶l̶o̶a̶d̶i̶n̶g̶ installation.
>Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required.
This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.
>Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required.
This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.
> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.
So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
When Google first announced sideloading restrictions, somebody told “but we have ADB”, and who disagreed with them was criticized harshly.
Now, I’m waiting for a workaround to enable ADB, so sideloading can be handled now, too.
Android is not more open that iOS for a very long time now. The trend will continue.
Again, this is not a technical problem (the mindset of Google), so technological solutions won’t help.
Now, I’m waiting for a workaround to enable ADB, so sideloading can be handled now, too.
Android is not more open that iOS for a very long time now. The trend will continue.
Again, this is not a technical problem (the mindset of Google), so technological solutions won’t help.
Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.
This is huge, Android getting locked down to such levels should be sounding alarm bells. They are slowly removing everything that makes Android good.
I am worried that this might happen to websites soon.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.
As far as I can tell, this is a big overreaction to a misunderstanding.
I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.
The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.
I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.
The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.
There's only one reason for anyone, or for me, at least, to choose Android, and it's the only reason I've consistently chosen Android from the very first Google Developer Phone: It's more open.
So, they don't want me to even have that one reason to keep choosing Android, I guess.
So, they don't want me to even have that one reason to keep choosing Android, I guess.
finally my children will be secure and my bank account impenetrable!
Looking what's this is about - Shizuku
https://github.com/thedjchi/Shizuku/wiki/setup
So it requires
* Enable Developer Options if not already enabled (Generally, this is done by going to Settings > About device and tapping Build number 7 times).
* Enable both USB debugging and Wireless debugging. Tap "Allow" if prompted to allow wireless debugging on the current network.
* Tap Pair device with pairing code.
* Downloadd other apps like ShizuCallRecorder
Or seems to be exactly what this user described.
https://news.ycombinator.com/reply?id=49046291&goto=item%3Fi...
https://github.com/thedjchi/Shizuku/wiki/setup
So it requires
* Enable Developer Options if not already enabled (Generally, this is done by going to Settings > About device and tapping Build number 7 times).
* Enable both USB debugging and Wireless debugging. Tap "Allow" if prompted to allow wireless debugging on the current network.
* Tap Pair device with pairing code.
* Downloadd other apps like ShizuCallRecorder
Or seems to be exactly what this user described.
https://news.ycombinator.com/reply?id=49046291&goto=item%3Fi...
It's this stuff thats caused me to start degoogling as much as I can. I've started using nongmail emails and removing photos.
I Don't know what else I can do though, next up is switching to grapheneOS but I'm a ways off from that for now.
I Don't know what else I can do though, next up is switching to grapheneOS but I'm a ways off from that for now.
I was thinking a lot about how these restrictions are paved with good intentions, but every time these new security measures are implemented we see criminals adopt new strategies and continue going about their day like nothing ever happened.
I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).
I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).
https://archive.ph/gla4i
In case it is made private.
In case it is made private.
This assumes user is the only person with physical access to unlocked phone.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
Step back to the other issue (referenced in the page*), that Google would pushing on devices something that blocks applications that do not come from play.google.com . Was it not established that Google can only push that update on devices with a google account?
* https://keepandroidopen.org/
* https://keepandroidopen.org/
Google is going the Apple route. When will we get the year of the Linux Phone?
Thank you for telling me about Shizuku! Android world is so vast and full of resources
Android Wireless debugging is already a major pita to work with.
Requires a wifi connection to even work, so I need to carry a mobile wifi router with me, instead of having it bound to my secure WireGuard connection.
Next it assigns a random port number every time the wifi connection is interrupted, or when it considers now is a good time to reset the port number. It should be possible to set a stable port and and have it available, perhaps behind a few awkward UI/adb toggles.
> This feature was proposed following a major security issue identified as CVE-2026-0073, which allowed the Wireless ADB authentication process to be fully bypassed. What is proposed in this issue is actually a nice idea.
Clearly this is not an issue when the wireless authentication process works as intended. I see no need to change that at all. They just need to fix that bug.
It's quite difficult to do this. You need to enable wireless debugging. Then pair to a random port with a random pairing code and then connect to yet another random port. When it works as intended it's more than secure enough.
If they really want to restrict it, just let the user choose in the development settings what interface to listen to.
Clearly this is not an issue when the wireless authentication process works as intended. I see no need to change that at all. They just need to fix that bug.
It's quite difficult to do this. You need to enable wireless debugging. Then pair to a random port with a random pairing code and then connect to yet another random port. When it works as intended it's more than secure enough.
If they really want to restrict it, just let the user choose in the development settings what interface to listen to.
Android had a tradeoff - less vertical integration and more annoyances, a bit worse software quality, for a more open, customisable and utility-like experience. I loved that.
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
What I find most annoying aspect of all software from 2010s onwards is this stupid discourse and associated results:
- some people want A, or A might even be already in use
- A is problematic for $MODERATE_OR_MILD_REASON
- B is introduced and made default
- a config switch between A and B is never considered
So, so tiring. If I want to bind ADB to localhost, _let me_. It's my device and my problem, ffs.
- some people want A, or A might even be already in use
- A is problematic for $MODERATE_OR_MILD_REASON
- B is introduced and made default
- a config switch between A and B is never considered
So, so tiring. If I want to bind ADB to localhost, _let me_. It's my device and my problem, ffs.
Amazon crippled the ADB functionality on FireTV Sticks a while ago. Making it an absolute pain to build and debug TV apps on. Currently, the only way to test is to install a release build every time.
Dies this affect GrapheneOS or CalyxOS?
I assume Sailfish and Ubuntu Touch are completely unimpacted?
I assume Sailfish and Ubuntu Touch are completely unimpacted?
Every time I want to connect ADB to a device, it takes me far more time than it should. Having different ports for pairing and connecting is already a pain. I wonder what new hurdles will come up once they restrict adb to wlan0, even though atm I can't see any problems for my use cases (like pushing APKs, reading logs or connecting dev tools).
Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).
Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).
Well, I ordered my first iphone last week.
if I have a choice between a walled garden with ads and a walled garden without, the outcome us easy to guess.
Call me crazy but that actually makes sense. ADB is clearly meant for one device to control another, otherwise it's just a hack to bypass sandboxes.
I'd be interested to see whether this comes with a replacement for legitimate use cases. Removing a capability without offering an alternative tends to push developers toward even more fragile or in some cases "rule breaking" workarounds
I switched to a MacBook b/c I couldn't find a comparable PC laptop
I feel like an iPhone will be next. Good Android phones are already pricey
I feel like an iPhone will be next. Good Android phones are already pricey
The other proposed change (to restrict access to certain interfaces or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.