This is part of a broader pattern that's been bugging me. Every year Android devices get a little more locked down, and every year the justification is "security." But removing adb sideload for OTA updates doesn't protect users from malware, it protects Samsung from users who want to control their own update timeline.
I had a Galaxy S21 that got stuck in a boot loop after an OTA went bad. The only fix was adb sideload a known-good firmware. Without that option I would've had to mail it to Samsung or buy a new phone. How is that better for anyone?
The cynical read is that this is about pushing people toward Samsung's own update infrastructure so they can better control the rollout cadence and eventually tie it to Samsung accounts or subscriptions. The optimistic read is that they're simplifying recovery mode for less technical users. Either way the people who actually need these tools are losing them.
exactly. "security for them" is the clearest framing i've seen. it's the same playbook as DRM - framed as protecting users from malicious firmware, actually protecting the vendor from users with firmware they didn't approve.
Note that this menu item was not used to install Android apps, which is what people often mean by "sideloading", especially with all the discourse around Google's new developer verification requirements. This menu item was used to manually install an OS update from a .zip file and already required that file to be signed by Samsung on locked devices.
On unlocked devices, you can install your own recovery that still has the option. So the removal doesn't prevent too much in practice. That ship sailed when Samsung stopped allowing bootloader unlocking on most of their phones.
Not surprising for Samsung to do this. Hacking on their devices (which are second to Apple at a hardware level) went downhill fast after they implemented eFuse-secured bootloaders.
What's interesting is that they tried hard to cater to the tinkerers before going in this direction. They "bought" (acqui-hired) CyanogenMod, contributed to open-source and had developer builds of their ROMs. I think they even had clean AOSP builds with the HAL and ABIs for their hardware baked in at some point. SafetyNet made it realistically impossible to daily a rooted phone in 2026 if you want to use banking, healthcare or most music apps, so it's safer for OEMs to tighten the screws on access to their hardware in kind.
My take is that they saw all of this as a risk to profits they could make from catering to regulated industries who would deploy their hardware en masse. It also didn't make sense to continue this investment after banks and healthcare put pressure on Google to step up privacy in Android, especially after Apple implemented Secure Enclave.
It's a pyrrhic victory regardless, in my opinion. If you're going to run a super-locked down Android device, you might as well go all-in with Apple. Their hardware ecosystem is better, their cloud services are better, they get first-priority for mobile apps, you get Blue Bubble Benefits, and their support (in-store and online) is on another level. Even MDM is better with Apple devices (through iOS Profiles). Shoot, even privacy-minded folks are better off on iOS with Lockdown mode.
This article isn't about the installation of regular apps. The "sideloading" it's referring to is the option to use the "adb sideload <OTA file>" command when booted into recovery mode to install OS updates. The functionality being removed is being able to install a proper OEM-signed OS update from a local file.
Old versions of Android do not comply with OS age-checking regulations in California, Brazil, and elsewhere. Samsung face legal repercussions including fines if residents of such jurisdictions are allowed to run an old OS. Yes, the laws apply to entities outside the borders of the territory.
This is part of a broader pattern that's been bugging me. Every year Android devices get a little more locked down, and every year the justification is "security." But removing adb sideload for OTA updates doesn't protect users from malware, it protects Samsung from users who want to control their own update timeline.
I had a Galaxy S21 that got stuck in a boot loop after an OTA went bad. The only fix was adb sideload a known-good firmware. Without that option I would've had to mail it to Samsung or buy a new phone. How is that better for anyone?
The cynical read is that this is about pushing people toward Samsung's own update infrastructure so they can better control the rollout cadence and eventually tie it to Samsung accounts or subscriptions. The optimistic read is that they're simplifying recovery mode for less technical users. Either way the people who actually need these tools are losing them.
> every year the justification is "security."
when they say security, they meant security for them.
Security against "Felony Contempt of Business Model".
Securing revenue streams.
exactly. "security for them" is the clearest framing i've seen. it's the same playbook as DRM - framed as protecting users from malicious firmware, actually protecting the vendor from users with firmware they didn't approve.
Well it's better for Samsung as they can probably sell you a new phone
Just part of the continued plan by Google and Samsung to lock down and make Android more like iOS.
Note that this menu item was not used to install Android apps, which is what people often mean by "sideloading", especially with all the discourse around Google's new developer verification requirements. This menu item was used to manually install an OS update from a .zip file and already required that file to be signed by Samsung on locked devices.
On unlocked devices, you can install your own recovery that still has the option. So the removal doesn't prevent too much in practice. That ship sailed when Samsung stopped allowing bootloader unlocking on most of their phones.
Not surprising for Samsung to do this. Hacking on their devices (which are second to Apple at a hardware level) went downhill fast after they implemented eFuse-secured bootloaders.
What's interesting is that they tried hard to cater to the tinkerers before going in this direction. They "bought" (acqui-hired) CyanogenMod, contributed to open-source and had developer builds of their ROMs. I think they even had clean AOSP builds with the HAL and ABIs for their hardware baked in at some point. SafetyNet made it realistically impossible to daily a rooted phone in 2026 if you want to use banking, healthcare or most music apps, so it's safer for OEMs to tighten the screws on access to their hardware in kind.
My take is that they saw all of this as a risk to profits they could make from catering to regulated industries who would deploy their hardware en masse. It also didn't make sense to continue this investment after banks and healthcare put pressure on Google to step up privacy in Android, especially after Apple implemented Secure Enclave.
It's a pyrrhic victory regardless, in my opinion. If you're going to run a super-locked down Android device, you might as well go all-in with Apple. Their hardware ecosystem is better, their cloud services are better, they get first-priority for mobile apps, you get Blue Bubble Benefits, and their support (in-store and online) is on another level. Even MDM is better with Apple devices (through iOS Profiles). Shoot, even privacy-minded folks are better off on iOS with Lockdown mode.
Grapheneos fuxors this
No, not ", including sideloading."
It's ", including installing software". Lets not let the enemy of general purpose computing define the framing of the discussion.
This article isn't about the installation of regular apps. The "sideloading" it's referring to is the option to use the "adb sideload <OTA file>" command when booted into recovery mode to install OS updates. The functionality being removed is being able to install a proper OEM-signed OS update from a local file.
Old versions of Android do not comply with OS age-checking regulations in California, Brazil, and elsewhere. Samsung face legal repercussions including fines if residents of such jurisdictions are allowed to run an old OS. Yes, the laws apply to entities outside the borders of the territory.
That's not how those laws work.
GDPR applies to entities outside the borders of the territory, yet most of the world doesn't give a shit.
Because it can't be enforced outside the borders of the territory.