Android禁用OTA更新指南:ADB脚本清除系统更新弹窗与红点

发布时间:2026/8/31 19:26:24
Android禁用OTA更新指南:ADB脚本清除系统更新弹窗与红点 你的手机是不是每隔一段时间就弹出一条系统更新通知设置图标的右上角是不是始终挂着一个怎么都消不掉的小红点就算你把系统更新应用的通知权限关掉它过两天又会换个方式弹出来可能是锁屏界面可能是状态栏横幅也可能是打开设置时直接铺一个全屏更新页面。这个问题的根源不在“通知权限”而在系统里负责检查 OTA 更新的一组服务。只要那组服务仍然在后台运行它就一定会想方设法把“有新版本”这件事告诉你。本文要讲的就是如何用一段一键安装脚本在 Android 设备上禁用这些更新服务、清除设置存储里的小红点标记并从源头拦截 OTA 更新弹窗。先给出一个明确判断这个方法对动手能力有一定要求但它并不复杂。你不需要 Root不需要刷机只需要一台 Windows / macOS / Linux 电脑、一根数据线和一份靠谱的脚本。最关键的并不是执行命令而是搞清楚你到底禁用了哪些包以及为什么有些包绝对不能动。我会先解释这套机制再给出可直接运行的脚本最后列出最常见的坑和恢复办法。1. 这篇文章真正要解决的问题很多人都会遇到这几类情况系统更新弹窗频繁而且每次弹出来都是“正在检查更新”既占后台资源又打断当前操作。OTA 更新包已经下载好了但一直被搁置在存储空间里占掉几百 MB 甚至 1GB 以上清理又清理不掉。设置图标出现红点但点进去看完更新页面红点依然存在强迫症非常难受。尝试关闭“应用通知”或“禁用系统应用”结果发现很多系统包是灰的点不动或者重启后恢复原样。这些问题的本质是设备厂商预置的 OTA 更新链路没有被切断。OTA 更新的完整流程通常由三个部分组成负责联网查询的更新服务、负责下载安装的更新应用以及负责展示“设置小红点”和系统消息的 Setting 组件。只关掉其中一个其他两个仍然会继续工作弹窗自然就会出现。传统方案大多是“关通知”“清缓存”“停用更新应用”但往往只能管几天。原因是系统更新服务的包名因品牌、ROM 版本不同而有差异很多人在不清楚包名的情况下只能碰运气。这篇文章会提供一个“自动识别候选包 备份原状态 一键禁用 可恢复”的脚本让你不用到处查包名也不需要反复试错。但也要先说明边界这篇文章的方法只推荐用在你自己的设备、测试设备或已被授权维护的设备上。禁用系统更新意味着你的设备不会自动获得官方安全补丁长期使用会有安全风险。生产环境、工作主力机、涉及敏感业务的设备请务必先做备份并评估风险。对大多数普通用户而言最稳妥的操作顺序是先用备用机验证效果再决定是否在主机上执行。2. 小红点与 OTA 弹窗背后的技术机制2.1 设置小红点是怎么产生的设置图标的红点本质上是 Android 的“通知角标”机制。当 Settings 或系统更新相关应用发送了一条高优先级的通知桌面的 Launcher 就会读取到未读状态并在设置图标右上角画一个红点。在部分 ROM 中这个红点的数据会缓存在 SettingsProvider 中。即使你在通知栏里划掉了那条更新通知角标数据也不会立刻清除需要清掉“设置存储”或重启 Launcher 才能消失。这就解释了为什么很多人只是点开设置看看更新页面红点仍然存在。2.2 OTA 更新弹窗是从哪来的OTA 弹窗不是单一应用突然弹出来的而是由一条链路触发的某个系统服务检测到当前系统版本号和厂商服务器返回的最新版本号不一致。更新服务向用户发送通知或者直接拉起更新应用。更新应用联网下载更新包下载完成后发送“立即安装”类提醒。如果更新包已经存在那么每次开机、解锁或连接 Wi-Fi 时更新应用都会再次弹出提示。这里的核心不是“通知权限”而是负责查询版本和下载安装的进程。如果这些进程还在运行即使你关闭通知它们照样会在后台检查进程一旦拿到更新包还是会用系统级弹窗来提醒你。2.3 为什么“关闭通知”不是长久之计相比普通第三方应用系统更新组件有几个特殊权限部分系统应用的通知权限受保护用户在设置界面无法直接关闭。厂商 ROM 可能会在每次系统进程重启后重置用户的数据或偏好。OTA 更新服务可能在更新包下载后用其他包名重新拉起导致你之前关闭的那个包不再生效。更有效的思路是直接“禁用用户级更新服务”也就是通过pm disable-user让相关包对当前用户不可用。这样既不需要 Root也不会影响系统其他模块的正常启动因为 Android 的包管理机制会在底层拦截这些包的运行。下面用一个表格来对比几种常见处理方式的效果处理方式是否需要 Root效果风险关闭通知权限否短暂隐藏通知弹窗仍可能再次出现几乎无风险清除设置存储否小红点可能暂时消失但更新服务仍会重新触发会丢失部分本地设置禁用更新服务否能阻止大部分 OTA 弹窗可能误禁相关系统组件Hosts 拦截是能阻止域名请求但部分更新走 IP 直连需要维护规则误拦会影响其他服务Magisk 模块是能组合多种策略效果持久设备必须 Root风险较高3. 环境准备与前置条件在开始之前你需要准备以下环境一台 Android 设备。系统版本不限但建议 Android 8.0 及以上因为低版本系统的包管理行为有所不同。一台 Windows / macOS / Linux 电脑用于执行 ADB 命令。一条能传输数据的数据线不是只充电的那种。在手机上开启“开发者选项”和“USB 调试”。不同品牌开启方式不同一般是在“设置 - 关于手机”里连点版本号 7 次。ADB 工具。如果你的电脑已经安装了 Android Studio可以使用adb否则请单独安装 platform-tools。安装平台工具后可以在终端执行adb version验证是否可用。只要命令能正常输出版本号就说明环境没问题。版本号建议不要太老新版本对禁用系统应用的支持更好。连接设备后先用以下命令检查设备状态adb devices -l如果输出中出现unauthorized说明手机端还未授权请在手机屏幕上点击“允许 USB 调试”。如果输出中出现device则说明连接正常可以进入下一步。之后所有操作都在电脑终端中执行。脚本运行过程中需要网络吗一般不需要因为禁用的是本机包不依赖外网。4. 核心思路没有 Root 和有 Root 时怎么做4.1 无 Root 方案ADB 禁用更新服务没有 Root 的情况下我们依赖 Android 系统提供的pmpackage manager命令。它允许当前用户对部分系统应用执行disable-user也就是“仅对当前用户禁用”并不会卸载系统里的文件因此安全性相对较高。具体操作流程是扫描当前设备中包名包含update、updater、ota等关键字的包。排除明显高危的包例如com.android.settings、com.google.android.gms、com.google.android.play.services等。将这些更新相关包记录到备份文件中。执行pm disable-user --user 0禁止它们运行。重启设备观察效果。这个方案的优点是无 Root、可恢复、不破坏系统文件缺点是依赖厂商是否允许禁用这些包。部分 ROM 会将更新服务注册为受保护应用disable-user会直接报错这时就需要考虑 Root 方案。4.2 有 Root 方案冻结、Hosts、Magisk 模块如果你已经 Root可以做的事情更多使用冻结工具如 AppManager、SD Maid把更新服务彻底冻结。通过 hosts 文件拦截 OTA 更新服务器的域名请求。制作一个 Magisk 模块在开机时自动追加 hosts 规则或修改系统属性。不过Root 方案虽然能力强风险也更高。修改系统属性例如安全补丁日期可能影响应用兼容性拦截域名规则写错了可能让其他应用无法联网。因此下面我会把无 Root 的 ADB 方案作为主线Root / Magisk 作为进阶补充。绝大多数人的需求用无 Root 方案就足够了。5. 一键脚本实现ADB 方式完整代码这一节是全文的核心。我会提供一个可直接运行的 Bash 脚本以及配套的恢复脚本。你需要把脚本保存为本地文件然后通过终端执行。5.1 禁用 OTA 更新脚本这里的脚本会完成以下工作检查 ADB 是否可用检查设备是否连接。扫描设备中与 OTA 更新相关的候选包。排除高风险系统包避免误禁关键组件。将当前启用状态备份到本地。向用户确认后逐个禁用更新服务。输出后续验证建议。先创建脚本文件。在电脑上新建一个文件命名为disable_ota_update.sh写入以下内容#!/usr/bin/env bash set -euo pipefail # # disable_ota_update.sh # 用法: ./disable_ota_update.sh # 说明: 通过 ADB 禁用 Android 设备上的 OTA 更新相关组件 # 风险: 操作前请备份设备数据仅限本人设备使用 # ADB${ADB:-adb} # 1. 检查 ADB if ! command -v $ADB /dev/null 21; then echo [错误] 未找到 adb 命令请先安装 platform-tools。 exit 1 fi # 2. 检查设备连接状态 if ! $ADB get-state /dev/null 21; then echo [错误] 未检测到已连接设备请先开启 USB 调试并授权。 exit 1 fi # 3. 定义高风险包名这些包不建议禁用 DANGEROUS_PACKAGES( com.android.settings com.android.systemui com.google.android.gms com.google.android.gsf com.google.android.setupwizard com.android.providers.settings ) # 4. 扫描候选包 echo [信息] 正在扫描系统更新相关包... mapfile -t CANDIDATES ($ADB shell pm list packages | sed s/^package://g | grep -Ei update|updater|ota|systemupdate || true) if [[ ${#CANDIDATES[]} -eq 0 ]]; then echo [信息] 没有找到明显的 OTA 更新相关包。 echo [信息] 如果你的设备仍然弹窗请手动执行: adb shell pm list packages | grep -Ei update|ota exit 0 fi # 5. 过滤高风险包 FILTERED() for pkg in ${CANDIDATES[]}; do skip0 for danger in ${DANGEROUS_PACKAGES[]}; do if [[ $pkg $danger ]]; then echo [警告] 高危包 $pkg 将被跳过避免禁用系统设置或 GMS。 skip1 break fi done if [[ $skip -eq 0 ]]; then FILTERED($pkg) fi done if [[ ${#FILTERED[]} -eq 0 ]]; then echo [信息] 过滤高风险包后没有可禁用的候选包。脚本结束。 exit 0 fi # 6. 打印候选包并要求确认 echo echo [信息] 以下包将被禁用: for pkg in ${FILTERED[]}; do echo - $pkg done echo read -r -p [确认] 是否继续? (y/N) confirm if [[ ! $confirm ~ ^[Yy]$ ]]; then echo [信息] 用户取消操作脚本退出。 exit 0 fi # 7. 备份当前启用状态到本地 BACKUP_DIR./ota_backup mkdir -p $BACKUP_DIR : $BACKUP_DIR/enabled_packages.txt echo [信息] 正在备份当前启用的包状态... for pkg in ${FILTERED[]}; do if $ADB shell pm list packages -e | sed s/^package://g | grep -qxF $pkg; then echo $pkg $BACKUP_DIR/enabled_packages.txt fi done echo [信息] 已备份到 $BACKUP_DIR/enabled_packages.txt # 8. 禁用相关包 echo for pkg in ${FILTERED[]}; do echo [信息] 正在禁用 $pkg ... if $ADB shell pm disable-user --user 0 $pkg; then echo [成功] $pkg 已禁用 else echo [失败] $pkg 禁用失败可能是受保护系统应用 fi done # 9. 验证 echo echo [信息] 禁用操作完成。 echo [提示] 如果设置小红点仍然存在可以执行: adb shell pm clear com.android.settings echo [提示] 恢复脚本将在需要时帮你重新启用这些包。保存后在终端执行chmod x disable_ota_update.sh ./disable_ota_update.sh如果你的adb不在系统 PATH 中也可以用ADB/path/to/adb ./disable_ota_update.sh5.2 恢复 OTA 更新脚本为了避免误操作后无法恢复建议在运行上面脚本之前先准备好恢复脚本。新建一个文件restore_ota_update.sh写入以下内容#!/usr/bin/env bash set -euo pipefail # # restore_ota_update.sh # 用法: ./restore_ota_update.sh # 说明: 从 ota_backup/enabled_packages.txt 恢复禁用的系统包 # ADB${ADB:-adb} BACKUP_DIR./ota_backup if ! command -v $ADB /dev/null 21; then echo [错误] 未找到 adb 命令。 exit 1 fi if [[ ! -f $BACKUP_DIR/enabled_packages.txt ]]; then echo [错误] 没有找到备份文件 $BACKUP_DIR/enabled_packages.txt exit 1 fi echo [信息] 开始恢复备份中的包... while IFS read -r pkg; do if [[ -z $pkg ]]; then continue fi echo [信息] 正在重新启用 $pkg ... if $ADB shell pm enable $pkg; then echo [成功] $pkg 已恢复 else echo [失败] $pkg 恢复失败 fi done $BACKUP_DIR/enabled_packages.txt echo [信息] 恢复操作完成。建议重启设备后确认系统更新是否恢复工作。5.3 手工执行方式如果你不想用完整脚本也可以手工执行关键命令。先扫描候选包adb shell pm list packages | grep -Ei update|updater|ota然后查看某个包是否处于启用状态adb shell pm list packages -e | grep -Ei update|updater|ota禁用某个明确的包adb shell pm disable-user --user 0 包名重新启用adb shell pm enable 包名这里要特别提醒手工方式虽然简单但容易因为你搞混包名而误禁关键组件例如误禁了com.android.settings。这会导致设置无法打开甚至桌面崩溃。所以更推荐使用上面带过滤和备份的脚本。6. 进阶利用 Hosts 拦截与 Magisk 模块实现深度屏蔽如果你已经 Root可以考虑更深一层的屏蔽方案。但请注意这一步不是必须的也不适合所有人。6.1 Hosts 拦截的基本思路OTA 更新服务在联网时通常会请求固定的服务器域名。如果将这些域名解析到本地回环地址127.0.0.1那么更新服务就无法下载新版本信息也就不会触发弹窗。在传统 Root 设备上可以直接编辑/system/etc/hosts但 Android 10 及以上使用动态分区系统分区只读所以更推荐通过 Magisk 模块在开机时追加规则。你需要先确认设备实际访问哪些域名。方法有几种在路由器上查看设备联网日志。使用抓包工具在设备上抓取更新请求的域名。在更新服务被禁用前通过dumpsys或日志观察。这里不会给出具体的厂商域名因为不同设备、不同地区差异很大。如果你写错了域名可能什么效果都没有更危险的是如果误把某个公共域名拦掉会影响其他联网应用。6.2 Magisk 模块骨架Magisk 模块的本质是一个目录里面包含module.prop和若干脚本。下面是一个最小模块骨架用于在开机时追加 hosts 域名规则OTABlocker/ ├── module.prop ├── post-fs-data.sh └── block_hosts.txtmodule.prop内容idota_blocker nameOTA Blocker version1.0 versionCode1 authoryourname descriptionBlock OTA update domain requests on bootpost-fs-data.sh内容#!/system/bin/sh MODDIR${0%/*} if [ -f $MODDIR/block_hosts.txt ]; then cat $MODDIR/block_hosts.txt /system/etc/hosts fiblock_hosts.txt内容127.0.0.1 update.example.com 127.0.0.1 ota.example.net将整个目录压缩成 zip 后用 Magisk 内置的模块安装功能安装即可。这个模块只负责修改 hosts不会触碰系统其他文件卸载也比较干净。但我必须说明这个方案的实际效果取决于你能不能拿到准确的更新域名而且 OTA 更新请求不一定都走域名有些会走 IP 直连。若只是单纯想消灭弹窗ADB 禁用更新服务通常是更简单有效的方案Magisk 模块更适合作为辅助手段。6.3 不建议使用的方式修改安全补丁日期有些教程会建议修改ro.build.version.security_patch为2099-12-31以中断安全补丁检查。这样做确实能让部分设备认为“已经是最新版本”也会让设置里的小红点消失但代价是部分应用在运行时读取安全补丁日期一旦发现日期异常可能拒绝执行银行类、支付类业务某些系统服务也会出现兼容问题。所以在本文中我不推荐这种方式。尤其是工作主力机更不要为了消灭弹窗而改写系统安全属性。7. 运行结果与效果验证脚本执行完成后不能只看终端输出“禁用完成”还要实际验证效果。7.1 验证更新服务是否被禁用执行下面的命令检查已经被禁用的包是否包含你期待禁用的更新服务adb shell pm list packages -d | grep -Ei update|ota如果命令没有任何输出说明候选包没有被禁用可能是厂商使用了其他命名也可能脚本中的disable-user没有成功。此时需要回到第 5.3 节手动扫描包名。7.2 重启设备后观察结束 ADB 会话重启设备。重启后临时保留更新应用的包通常也会被禁用除非厂商有保护机制。观察以下现象设置图标右上角的小红点是否消失。下拉通知栏是否还有系统更新提醒。打开设置是否还会出现“系统更新”入口的角标。连接 Wi-Fi 后是否还会自动下载更新包。如果小红点已经消失说明清除角标或禁用更新服务起了作用如果红点还在继续排查。7.3 清理“设置”存储的补充操作对部分 ROM 来说设置小红点的数据是历史遗留缓存禁用更新服务后不会自动消失。这时需要清除 Settings 应用的数据adb shell pm clear com.android.settings注意这个命令会清除设置应用的本地数据包括你自定义的很多设置项例如通知偏好、显示偏好、部分应用权限设置。执行前请先备份或在备用机上验证。清除设置数据后桌面图标通常会自动恢复正常但可能需要重新设置壁纸、铃声音量等偏好。清除之后再次执行adb shell pm list packages -d | grep -Ei update|ota确认更新服务仍处于禁用状态。如果红点又出现大概率是某个更新组件被重新开启需要继续排查。8. 常见问题与排查思路问题现象可能原因排查方式解决方案运行脚本后没有任何候选包厂商更新服务包名不含常见关键字执行adb shell pm list packages并检查含 update/ota 的包手动识别并添加到脚本候选列表禁用后重启又被自动启用系统存在受保护应用的自动恢复机制查看pm list packages -d是否恢复使用 Root 方案冻结或联合 hosts 拦截设置小红点仍然存在角标数据缓存在 SettingsProvider 或 Launcher清除设置存储或桌面 Launcher 数据执行pm clear com.android.settings但要先备份禁用后系统设置闪退误禁用了设置相关包查看 logcat 或崩溃提示执行adb shell pm enable 包名或运行恢复脚本Google Play 服务异常误禁用了 GMS 相关包查看pm list packages -d恢复com.google.android.gms和com.google.android.gsf禁用包时提示not allowed受保护的厂商系统应用查看完整错误信息使用pm disable或 Root 方案更新包仍然在后台下载更新服务被禁用但下载服务/连接服务还在查看当前运行的下载服务补禁对应组件或使用 hosts 拦截域名排查工作的第一步永远是确认设备上实际存在的包名。不要凭经验去猜因为你可能在 A 品牌设备上看到的是com.android.updater到 B 品牌设备上就变成了com.xx.updater。先扫描再行动是这套方法最重要的一步。9. 最佳实践与工程建议9.1 不要盲目禁包系统更新服务通常只占所有系统包的一小部分。最理想的做法是只禁用包名中含update、updater、ota的包同时警惕高危包。禁用错一个就可能让系统设置无法打开甚至影响整个系统的稳定性。我的建议是脚本提供的过滤列表只是基础你应该在实际执行前再人工确认一遍。如果你不确定某个包是什么可以在终端用adb shell dumpsys package 包名查看包信息或者先在网上搜索确认。9.2 一定要备份当前状态脚本里的enabled_packages.txt备份文件非常重要。它记录了你禁用了哪些包、这些包原本是否是启用状态。如果有一天你想要恢复系统更新只需运行恢复脚本不用再去回忆之前动了哪些东西。9.3 选择正确的执行对象强烈建议不要在重要设备上立刻执行。先找一台备用手机或者不常用的旧设备完整跑一遍脚本确认无异常后再操作主力机。这样即使出现问题也不会影响正常使用。9.4 安全更新不能完全忽略禁用 OTA 更新意味着你不会自动收到安全补丁。如果你的设备用于支付、办公或存储敏感资料建议每隔一段时间手动开启更新服务下载并安装安全补丁然后再次禁用。不要因为弹窗烦恼就彻底放弃安全维护这是治标不治本的隐患。9.5 保留 ADB 调试入口执行完脚本后不建议立刻关闭 USB 调试。如果你需要恢复系统更新或者发现某个应用异常随时可以用adb shell pm enable恢复相关包。一旦关闭 USB 调试再想恢复就会多一道解锁步骤。9.6 面向不同 ROM 的通用策略每个厂商 ROM 的更新包名可能不一样但这套方法的核心思路是通用的先扫描再备份然后禁用最后验证。只要你愿意花几分钟看完输出结果就能把“一键安装”变成“按需定制”。如果某台设备限制较多再考虑 Root 方案或 Magisk 模块不需要在一开始就追求最复杂的手段。如果你在实机操作时遇到了脚本不认设备、找不到候选包、禁用后又被自动恢复这几种情况先把本文第 8 节的表格再读一遍。这套方案真正的门槛从来不是那几行命令而是你愿不愿意在动手之前先把设备上的包名和自己的预期目标都搞清楚。