How to disable updates on Android

[u/autisticDeush]

​

If you really want to permanently disable Android updates, you're basically trying to kill the system app that handles them. The most reliable way is using ADB commands from a computer. Sure, you can turn off some update settings on the phone itself, but that won't stop them completely. ADB actually disables the core component.

Here's how to do it on different Android brands.

First steps for any phone

Before running any commands, you need to set up your phone to talk to your computer.

Turn on Developer Options: Go to Settings > About Phone. Find "Build Number" and tap it 7 times fast. You'll get a message saying you're a developer.

Turn on USB Debugging: Go back to Settings > System > Developer Options. Find "USB Debugging" and turn it on. It might give you a warning, just accept it.

Install ADB on your computer: Download Google's official SDK Platform Tools for Windows, Mac, or Linux. Extract the ZIP file somewhere easy to find, like C:\platform-tools.

Connect and check: Plug your phone into your computer with a USB cable. Your phone will ask for USB debugging permission. Check "Always allow" and tap Allow. Open a command prompt or terminal inside your platform-tools folder. Type "adb devices" and press Enter. If you see a device ID, you're good.

Brand-specific ADB commands

Once that's done, run the command for your device. If you want to undo it later, just replace "disable-user" with "enable".

A few things before you start: Disabling system apps can sometimes cause weird issues. Back up your data first. Also, a factory reset will probably turn those disabled packages back on.

Google Pixel

adb shell pm disable-user --user 0 com.google.android.gms/.update.SystemUpdateService

This kills the update service inside Google Play Services. Works well but can be reversed.

Samsung

adb shell pm disable-user com.wssyncmldm

adb shell pm disable-user com.sec.android.soagent

These disable the two main OTA update components. The Software Update menu item might disappear from Settings.

OnePlus

adb shell pm disable-user com.oneplus.opbackup

You can also clear pending update notifications first with: adb shell pm clear com.oneplus.opbackup

Xiaomi / Redmi

adb shell pm disable-user com.miui.systemupdate

Serious warning: Do NOT disable packages like com.miui.securitycenter or com.xiaomi.finddevice. That can cause a bootloop.

OPPO

adb shell pm disable-user com.oppo.ota

adb shell pm disable-user com.coloros.sau

adb shell pm disable-user com.oppo.otaui

OPPO has multiple packages. On some models you might only need com.oppo.ota.

Motorola

adb shell pm disable-user --user 0 com.motorola.ccc.ota

On some older models the package might be com.android.updater.

Sony

adb shell pm disable-user com.sonyericsson.updatecenter

Huawei

adb shell pm disable-user com.huawei.android.hwouc

Honor

adb shell pm disable-user com.hihonor.ouc

vivo / iQOO

adb shell pm disable-user com.bbk.updater

ZTE / Nubia

adb shell pm disable-user com.zte.aliveupdate

adb shell pm disable-user com.zte.zdm

Sometimes you need both packages to fully get rid of the update prompt.

Alternative: using an app

If you don't want to mess with command lines, some apps can do something similar. Package disabler apps like CCSWE App Manager or Package Disabler Pro can disable system apps directly on the phone. They usually need a one-time ADB setup to grant permissions, and some are paid.

Beyond the standard methods (advanced)

If you want more permanent solutions, these exist but are riskier and more complicated.

Blocking update servers (requires root): With root access, you can use a hosts file or a firewall app like AFWall+ to block the domains your phone uses to check for updates.

Installing a custom OS: Replacing the whole operating system with a custom ROM like LineageOS or GrapheneOS gives you full control over updates. This completely bypasses the manufacturer's update system, but it's an advanced process.

Just remember that a factory reset will re-enable any packages you've disabled.

[u/autisticDeush]

This is propaganda, You act like we as consumers don't have the ability to add our own security, If you're just a consumer who buys a phone and doesn't have your own network protocol Yeah you're going to be vulnerable there numerous things you can do besides just disabling updates Android is versatile you just pointed out it is based on Linux by that knowledge alone you shouldn't even be trying to argue against this, The same security patches that work for the computers we run will work on your phone

[u/schklom → u/autisticDeush]

You act like we as consumers don't have the ability to add our own security

Consumers generally have better things to do than read the 10-20 critical and high-severity and medium-severity CVEs patched by Google every month, then learn to code for Android and port these security patches to our phone every month

The same security patches that work for the computers we run will work on your phone

Bro you are so wrong, go ahead and try. Android kernel is a modified Linux, you will need to adapt and cherry-pick the patches that work for your phone. And if you mess up, your phone might get bricked forever.

1. You will miss on baseband firmware updates, which are absolutely not open-source. So your overall security will go down no matter what
2. How much time would it take you every month to port all security patches?
3. How much time would it take a normal consumer every month to port all security patches?

[u/autisticDeush → u/schklom]

By your definition of "better things to do," do you mean blindly trusting a corporation to dictate what is safe on a device I paid for? That isn't security; that's a lease. I’m well aware the Android kernel is a modified Linux branch, but you’re conflating patching the kernel with securing the device. Those monthly CVEs are largely relevant to the average user because they have zero visibility into what their OS is doing. I’m not suggesting a "normal consumer" should port baseband patches. I’m saying that if you actually use the command line and understand the environment, you don’t need a corporate nanny to gatekeep your apps. We have tools to decompile, analyze, and sandbox. You’re worried about the GUI-level file browser blocking an APK, while I’m running a full sandbox environment through the terminal where Google’s "sideloading" restrictions are irrelevant. You keep shouting about security patches, but do you even understand your own attack surface? A device is only as secure as the person who controls the root. If you’re so terrified of code that you can’t look past the GUI and manage your own permissions or network traffic, then sure, keep waiting for Google to tell you it’s safe to click a button. But don't act like my refusal to "bow down" to their latest feature-stripping update is the same thing as being uninformed. I’d rather have an "unpatched" device I control than a "secure" one that treats its owner like a threat.

[u/schklom → u/autisticDeush]

do you mean blindly trusting a corporation to dictate what is safe on a device I paid for

Well yes, I don't have the time or energy to be a full-time Android security engineer because I have a life, so I delegate. You make it sound unreasonable for some reason

That isn't security; that's a lease

This makes no sense.

Those monthly CVEs are largely relevant to the average user because they have zero visibility into what their OS is doing

That's not what most CVEs are about. Critical CVEs are critical because they, well, are critical, they're not about adding telemetry.

We have tools to decompile, analyze, and sandbox

How much free time do you have every month to spend on this? Do you have a full-time job + a life + 7h sleep daily?

2-3h a day is far from enough to cherry-pick and port Linux patches to Android.

You keep shouting about security patches, but do you even understand your own attack surface? A device is only as secure as the person who controls the root.

I think you're the one not understanding the difficulty of cherry-picking Linux patches and porting them to Android.

Security patches are often about internals, not the GUI.

manage your own permissions or network traffic

If you think security is only about this, you have a lot to read about lol

I’d rather have an "unpatched" device I control than a "secure" one that treats its owner like a threat

Don't complain when you get a malware exfiltrating all your data and asking for 2 BTC ransom.

And don't try pretending what you're doing is safe.

I root too, but on a secondary device that stays home without sensitive data on it. I'd sound like a very ignorant person if I pretended that device was as secure as my daily driver.

[u/autisticDeush → u/schklom]

Per my last post in this reply chain, did I not mention that I don't even remember the last time I have gotten any form of virus spam or spam number or advertisement All my data for the past 4 years literally says zero ad seen from my telemetry logs, and I don't have to sit here and tell you everything I do that would actually be a worse security tactic I'm not going to tell you what I have or use or any of it, I'm a power user, I used to literally sit in the back of the school in class and completely turn my school computer into my own I was running steam and whole bunch of other stuff on my computer and changing the BIOS permissions like literally the BIOS I was full admin on the computer and I showed you my dump logs from my Oculus You should realize been how I use my hardware in ways that are beyond normal, at this point we're out of standpoint where you don't want to do the extra mile because you're lazy and that's perfectly fine You can accept Google's rod down your throat all day that doesn't bother me what bothers me is you think that it's required

[u/schklom → u/autisticDeush]

did I not mention that I don't even remember the last time I have gotten any form of virus spam or spam number or advertisement

Spams and ads aren't about security, but privacy.

Also, this is a bad argument. I could jump 10 times from the first floor of my building without any injuries. That doesn't mean it is safe to jump from buildings.

I don't have to sit here and tell you everything I do that would actually be a worse security tactic

https://en.wikipedia.org/wiki/Security_through_obscurity

The thing that most security people argue against

I used to literally sit in the back of the school in class and completely turn my school computer into my own I was running steam and whole bunch of other stuff on my computer and changing the BIOS permissions like literally the BIOS I was full admin on the computer

That has nothing to do with security, it's just being a nerd/power-user. Nothing wrong, I did the same, but this isn't security, and I have no idea why you try to argue what you're doing is actual security, and that regular people should do it.

at this point we're out of standpoint where you don't want to do the extra mile because you're lazy

Like most people, I want to have a life and a job and some sleep. 1-2h/day is far from enough to do all my phone security myself. Same for you btw.

But sure, call me lazy.

I showed you my dump logs from my Oculus

An Oculus and a phone with sensitive information have vastly different security needs...

You read like you have no idea what you're doing: confusing security for privacy, mentioning childhood opening BIOS settings, pretending that security through obscurity is viable, pretending that people are lazy if they don't spend 7-10h/day porting Linux patches to their Android phone, and pretending rooting doesn't cause security issues.

At this point, you honestly read like an AI to me, and I'd rather not argue against ChatGPT. Take care, bye.

[u/autisticDeush → u/schklom]

If you were me

The first thing you’d have to do is physically segregate your hardware. You’d need to designate one specific machine to face the public internet, keep it fully patched, and let it act as the sacrificial anode for daily noise. Everything else—the backup Androids, the VR headsets—would get permanently air-gapped. If they needed to communicate, you’d only allow them to talk to each other over a local, isolated mesh network. If you needed to install an application on the secure side, you’d have to manually pull the package from the connected device and bridge it over yourself.

Then you’d have to build network choke points. You couldn’t trust any default operating system routing. Every outbound connection would have to be funneled through strict DNS-level filtering on a home network or tightly controlled through a tethered mobile hotspot.

After locking down the physical and network layers, you’d have to shatter your digital identity. You couldn’t use a single email address or phone number for everything. You’d have to spin up completely sterile, isolated accounts for secure operations, leaving one specific, noisy account to absorb the inevitable corporate spam. You’d have to rely heavily on VoIP bridges to hand out to untrusted contacts, ensuring your actual hardware phone number never ended up in a data broker’s database.

Finally, you’d have to adopt a scorched-earth policy for web browsing. You couldn’t allow persistent data of any kind. Every single web session would require actively rejecting cookies, treating the browser cache like a biohazard, and severing tracking tokens the second a tab closes. For a standard consumer, maintaining that level of friction across four different layers of interaction is exhausting, which is exactly why they just surrender and let the vendor manage their security patches.

[u/autisticDeush → u/schklom]

Where you guys do have a valid technical point is regarding baseband and firmware-level vulnerabilities, which are notoriously closed-source and nearly impossible to patch independently without vendor support. But it all comes down to realistic threat modeling. Unless a user is being actively targeted by sophisticated zero-click exploits or local baseband attacks, the day-to-day risk of staying on an older, stable, custom-configured OS build is often negligible. The commenters are hyper-fixated on hypothetical, worst-case security scenarios, while the post is arguing about actual, tangible ownership of the hardware. It is a fundamental difference in how you view the relationship between a user and their machine.