Hacker News Reader

Comment by dataflow | Hacker News Reader

Hey, question. While I'm also miffed about Google's decision and see your point about the term sideloading, there is another elephant in the room you seem to not be addressing here.

You write:

> “Sideloading is Not Going Away” is clear, concise, and false_

But isn't Google saying that you will still be able to sideload via ADB? Which would mean their statement is true, and that your claim that Google's statement is files is itself false?

I'm so confused why you never even mention ADB or its relevance to sideloading, which they refer to rather explicitly in their blog post. At the very least, if you think ADB doesn't change anything, you could mention it and say so. Could you explain this seemingly critical omission?

View on HN

Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do

The number of people that don't even own a general purpose computer is huge. And for those that do, ADB is a ridiculous thing to get setup for a particular device. I get paid to work on android software, and I don't even want to put up with the hassle.

you don't need a computer to run adb. there's install with options

For now

Yes. And a bigger question is, why should I have to? This is a perfectly functional computer, it is more than capable of downloading a file and running it.

It's really sad that Apple and Google (and to some extent MS though they're just behind in this race to the anti-consumer bottom) happened upon this "solution to malware" (note: not a real solution) of "OS vendor vets and controls all software." It's a lazy way, it's an ineffective way, and it has made computers - incredibly flexible, programmable devices - more like cable boxes or telephones from past decades, that you had to rent from a monopolist and had no control over.

Also if the majority of sideloaders go away because it's become more difficult, what will happen to the development scene? Will it stall out from lack of developer interest because there's such a small audience compared to before? (Despite it still being possible.)

I see googles actions as lashing out at everyone because theyre being attacked for their monopoly activities.

They want to punish customers for electing regulators who care about consumer protections.

This is large scale abusive boyfriend behavior, doubling down.

Anyone who defends google/Android has been heeled in fear.

There's no spite or emotion, it's a company. They want to kill NewPipe etc. to force everything through apps they control and can monetize. It's just about money.

A company is a group of individuals acting together for a goal that could not individually be achieved, the legal personality of the company exists to reduce (not eliminate) the liability and coherently steer the members of it. Those shareholders/business partners individually wouldn't be able to earn this much money nor have this much work done by employees of each.

Yes, there is. The people who got rich absolutely think they deserve it all.

You could make a glossy PC client around it. On the meta quest there's an app called SideQuest that does just that because meta doesn't permit apps to install other apps. It's still a fairly big thing there.

I'm happy about the adb loophole, but I'm worried this would be just the start of the slippery slope, and Google would find a way to lock down adb next, citing the risk of malware sideloaded by fancy tools wrapping adb, once they start popping up.

True though I don't believe Google's goal is truly security here. I think it's more an excuse and the real reason is tightening control.

As I understand it, the delivery mechanism won't matter: Play Store,ADB, F-Droid, Bluetooth, or website. If the APK isn't signed by a Google-approved developer, it's not going to install.

If there's some ADB command that one can issue to install unsigned APKs for now, it's a temporary reprieve at best. Two Android versions later, the update from Google will read "Only 0.02% of users installed apps using adb, but the corresponding malware incidence rate was 873% more than the Play Store. Due to the outsized risk, we're disabling adb installations going forward"

No, that adb command is how you test install things. They wouldn't want to force public uploads to Play just to test.

They could go the apple way and sign an annoyingly shortlived cert.

Won't fly given the existence of tons of playless Android forks that F-Droid or other methods can easily be deployed to.

Not so. The new mandate isn't that all APKs must be uploaded anywhere, only that all APKs must be signed by approved developer keys. So to test new builds, devs will only have to sign with their approved key, then upload. No extra hassle once you already have an approved key.

I'm not sure it works that way. _In general_ before the recent announcement you are supposed to sign the debug build (what you feed into adb to install) with your debug key that's different from the release nor upload key, and the debug key is never submitted to google.

Of course _maybe_ at some point google will also force you to submit your debug key to them. But I don't believe that's the case now.

Sure, you would test-install apps via any delivery method of your choice, including USB-C cable or WiFi, after Google attests that your test-app signature is whitelised[0]. After all, there is no legitimate reason[1] to not sign your app, since you want it to closely match the distributed version as much as possible, and there won't exist unsigned distributable apps.

0. Developer has valid signatures and in Google's good graces, and application hasn't been installed on more than 16 devices

1. Oh, you CI/CD signing infra won't let you? You better fix your workflows to match the Google way.

adb is a developer tool. You need a tethered and trusted computer to be able to transfer an app using adb, and you need to enable "developer mode" on the device, which is an arcane dance that involves navigation through an obscure tree of settings and then quickly tapping a mystery spot 5+ times. Google can't block adb, because that is how Android apps are developed and tested, just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

This is so far from a realistic and acceptable substitute that I question the honesty of anyone who claims that "adb will still work, so no problem!"

I hope that explains my seemingly critical omission.

> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per year "developer program" free in order to use the devtools to test the app on your physical device.

If Google is also blocking preventing you from loading your own software onto your own phone with adb unless you pay a free, then this would be a very important thing to call out explicitly.

You recall correctly, but that did end in 2015, when Apple ended the requirement that developers sign up for their paid developer program to be able to develop and test iPhone apps. I've written about that elsewhere: https://appfair.org/blog/gpl-and-the-app-stores#fn:3

The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone: technically possible without paying a fee, but enough friction that no one would seriously consider as an alternative solution for publishing their apps to a general audience.

Apple has actually increased the friction since: you now have to enable a scare-screened developer mode, reboot your device, install the app, get an error that the app is untrusted, then go to the part of Settings used for corporate management profiles to enable your own developer profile, and only THEN will the app actually launch and run.

> The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone

The Apple situation is still significantly worse than ADB, because (at least without a paid-for developer account) AFAIK you're limited to a certain number of in-development app that you can install simultaneously and you definitely need to reinstall them every few days. ADB currently has no such restrictions.

I think your position is valid.

Note: Apple restricts apps uploaded with Xcode, (depending on how it is signed I believe) to 7 days or 1 year. adb currently doesn't have this limit.

But what if they find that somebody made 'sideloading' 'too easy' again. E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop. Then their currently proposed new rule would become ineffective and due to whatever thought process they arrived at their current conclusion, could place similar limits on adb.

> E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop.

That idea already exists and is called Shizuku. You don't even need another phone, because ADB also has a mode for wireless debugging via the network, so you can just use that to locally connect to the ADB daemon running on your own phone.

The reason for its omission should be obvious. First, most people who "sideload" apps do not have ADB installed, and may not have the technical knowledge to do so. Second, the ability to do so can be taken away just as arbitrarily as the right to do so without it.

Perhaps the author is speaking purely from a "consumer" point of view, rather than developer/pro types who of course can bypass restrictions using common dev tools.

I believe f-droid strives to be a simple platform of from-source builds for non-Googled apps that anyone can use.

>But isn't Google saying that you will still be able to sideload via ADB?

No, it will not. Nothing will install an application without a Google approved signature on it. They will remove ad blocks from your Android and you will like it. "The beatings will continue until morale improves" sort of behavior.

I'm hopeful that the mystery OEM that GrapheneOS is targeting is in fact Sony Xperia. If it isn't, I'm just going to stop carrying a smartphone when all my installed apps stop working on it.

> No, it will not. Nothing will install an application without a Google approved signature on it.

How do you interpret this then:

>> You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.

Isn't that the opposite of what you wrote? What am I missing?

I interpret that as you will be able to install an unverified app. And you will get the annoying unverified app screen every time you launch it. And it will very likely be crippled in other ways, as it is unverified.

>Lando: But that wasn't our deal!

>Vader: I have modified our deal. Pray I do not modify it further.

Joke's on them. I'm not using ad-blocks, but have been training my neural network (non-AI) to ignore them.

Can you provide supporting evidence? A place where they say Sideloading is now becoming ADB installing?

This is what they say in their blog post:

You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.

If you see a loophole in the clear argument they're making there, I'd love to know. I don't see any obvious ones.

I'm just not sure people have been referring to that method when saying 'sideloading' and Google didn't mention sideloading specifically there.

This is what they say in the quote this article is about:

"Does this mean sideloading is going away on Android?

Absolutely not. Sideloading is fundamental to Android and it is not going away. Our new developer identity requirements are designed to protect users and developers from bad actors, not to limit choice. We want to make sure that if you download an app, it’s truly from the developer it claims to be published from, regardless of where you get the app. Verified developers will have the same freedom to distribute their apps directly to users through sideloading or through any app store they prefer."

In this paragraph they don't mention ABD at all similar to how in your paragraph they don't mention sideloading.

I see, wow. That's such a frustrating lack of clarity on Google's part and (consequently?) those responding to the blog post...

As far as I now, historically, "sideloading" has always meant "installing from some mechanism other than the Play Store", and everyone has been referring to adb-based installations as "sideloading" as long as I can remember (example [1]). If Google or others don't call using adb sideloading, then I have no idea what they would call it, and I'm thoroughly confused.

[1] https://www.xda-developers.com/how-to-sideload-apps-android-...

TVs are an entirely different class of sideloading than Phones.

Not only will sideloading via ADB continue to work, installing from most other third-party app stores will continue to work. The developers on the Amazon, Samsung, and Epic app stores won't have a hard time with the developer verification process. F-Droid is in a uniquely inconvenient position that they have a legitimate app store, but its design causes them to have a hard time with developer verification.

> won't have a hard time with the developer verification process

Unless any government powerful enough has reason to make Google reject developers. Hell, doesn't even have to be a government. Do anything that annoys Google, goodbye rights for your app to be installed on any Android. Why would you ignore the obvious and main caveat? It doesn't matter what store it "continues to work on". Google can revoke privileges overnight with little to no recourse for the developer, regardless of the merit of such action, the usefulness of the app, or how much people want/need that app. This is literally heading in the direction of Kafkaesque.

F-Droid is also the only one that does reproducible builds which is a big security feature. One that is precisely the cause of making this hard. But it also makes it safer than even the play store. It should really be accommodated.

Reply on news.ycombinator.com