刷过机、解锁过引导加载程序的朋友大概都在通知栏里见过这条顽固提示“性能受到影响要停用。请查看引导加载程序通知”。它不像普通推送那样右滑就消失重启、清后台、甚至换一张 SIM 卡它依旧挂在那里点进去要么跳到一个语焉不详的说明页要么干脆没有任何反应。我第一次遇到它是在一台刚升级到 Android 11 的测试机上当时第一反应是某个预装应用在乱推消息抓着dumpsys翻了一遍才发现发这条通知的根本不是第三方 App而是系统自己。这条通知牵扯的东西其实不少引导加载程序bootloader的解锁状态、Android 11 之后收紧的完整性校验、系统级常驻通知的渠道机制以及在它背后一整套“通知该怎么发、能不能关、点击之后跳到哪里”的设计逻辑。后面这几件事不光是刷机玩家会遇到做 App 推送的、做跨端通知的、甚至做 PC 端提醒模块的同学迟早都要碰。所以这篇不打算只讲“怎么把这条通知弄掉”而是把它的来龙去脉、状态读取链路、可选的几种处理路线以及从开发视角看通知体系时容易忽略的坑一次讲透。有基础的同学可以直接跳到第 3 章看操作完全不懂的从第 1 章顺着读也不会卡。1. 这条通知到底是什么为什么偏偏在 Android 11 上冒出来1.1 引导加载程序解锁与系统完整性状态先把概念捋直。手机开机时最先跑起来的不是 Android而是一小段叫引导加载程序的代码它的职责是校验并加载后面的系统镜像。厂商出厂状态下这段代码处于“锁定”状态只肯加载官方签名过的镜像一旦你手动解锁它就变成了“谁签名的都认”。方便是真方便代价是整台设备的信任链从根上就断了。Android 从 7.0 开始全面推行AVBAndroid Verified Boot到 Android 11 这一代验证结果会被固化成一个启动属性常见的就是ro.boot.verifiedbootstate。它的典型取值有三个green表示完整校验通过也就是官方状态yellow表示加载了自定义密钥签名的镜像orange表示引导加载程序已解锁、校验被跳过。系统里有专门的应用会在启动后读取这个属性一旦发现不是green就挂一条通知出来提醒你。不同厂商的 ROM 对这套逻辑的实现差异很大所以文案也不统一。有的写“检测到引导加载程序已解锁”有的写“设备安全性降低”而这次这条“性能受到影响要停用。请查看引导加载程序通知”本质上是同一个来源的另一种措辞。它不是病毒不是广告也不是某个 App 的推送而是系统对自己状态的自我陈述。1.2 “性能受到影响”影响的到底是什么这句话读起来很吓人好像手机马上要变卡但实际上它说的“性能”跟跑分、帧率关系不大。真正受影响的是依赖硬件级信任链的那一类能力受影响的能力具体表现原因高等级 DRM 解码视频类 App 只能放出标清或中清无法启用最高画质解锁后 Widevine 安全等级会从 L1 掉到 L3支付与金融类校验部分 App 启动时提示环境异常或直接拒绝运行完整性校验结果不再可信系统在线更新部分机型无法接收官方 OTA 或更新失败更新包校验依赖锁定状态部分厂商的云服务云同步、查找设备等功能可能被限制厂商策略绑定设备可信状态所以“性能受到影响”更像是一个笼统的提示语厂商用它来概括上面这一串连锁反应。实测下来日常刷视频、聊天、打游戏的流畅度基本没变真正被卡住的是那几项对安全性敏感的功能。想验证一下也简单连上电脑跑一句adb shell getprop ro.boot.verifiedbootstate adb shell getprop ro.boot.flash.locked adb shell getprop ro.boot.veritymode如果第一条返回orange第二条返回0那基本可以确定这台机器处于解锁状态。想看得更全直接过滤一遍adb shell getprop | grep -i -E boot|verity|lock|warranty注意不同芯片平台、不同厂商的属性命名不完全一致比如有的机器用ro.secureboot.lockstate有的还会多一个记录解锁次数的属性。上面这几条读不到不代表没解锁以能不能刷入非官方镜像为准属性只是参考。1.3 为什么它是常驻、不可清除的通知普通通知用NotificationManager发出来用户可以右滑清掉。这条不一样它通常带着FLAG_ONGOING_EVENT和FLAG_NO_CLEAR两个标记前者告诉系统“这是个正在进行的事件”后者直接禁用了滑动清除。这类通知的设计初衷是会话类、导航类场景比如正在通话、正在导航用户不该误清。系统把它用在设备状态提醒上逻辑上也说得通只是体验上确实够烦人。还有一个细节容易被忽略Android 8.0 之后所有通知都必须归属于某个通知渠道NotificationChannel渠道一旦创建它的名称和描述只有应用自己能改用户只能在系统设置里调它的重要级别或者整个关掉。这条提醒挂在哪个渠道上直接决定了你能不能靠“关渠道”把它彻底静音。有些厂商把渠道名字起得很有误导性比如叫“系统优化提醒”你根本猜不到它是干这个的。所以第 2 章我们会先讲清楚怎么把这条件通知的“户口”查出来。2. 从开机到通知栏一条状态是怎么被系统读出来的2.1 启动链上的验证与属性固化整条链路其实很短但每一环都有讲究。开机时引导加载程序做两件事一是校验下一级镜像的签名二是把自己的状态写进启动参数。内核起来之后这些参数会被解析成ro.boot.*系列属性固化在属性服务里。因为前缀是ro意味着它们是只读的运行时改不了只能重启后重新指定这也是为什么你改不了这个状态——除非动引导加载程序本身。AVB 2.0 里还有一个vbmeta分区的概念里面存着各个分区的哈希描述和签名信息。解锁状态下vbmeta里的校验可以被跳过常见做法是刷入一个禁用校验的 vbmeta 或带--disable-verification参数这就是为什么有些机器解锁后依然能正常开机。但跳过校验这件事本身会被记录下来系统一读就知道。所以这里没有“伪装成官方”这种操作空间状态是事实不是可以随手擦掉的标记。2.2 系统应用读属性、发通知的链路属性固化之后会有系统级的应用或服务在启动完成后去读它。这一步通常发生在开机广播之后所以你看到的通知往往是开机几十秒才出现而不是立刻就有。发通知的代码逻辑大概是这样// 简化示意不同厂商实现差异很大 String state SystemProperties.get(ro.boot.verifiedbootstate, green); if (!green.equals(state)) { NotificationChannel channel new NotificationChannel( bootloader_status, 设备状态, NotificationManager.IMPORTANCE_LOW); nm.createNotificationChannel(channel); Notification n new Notification.Builder(ctx, bootloader_status) .setSmallIcon(R.drawable.ic_warning) .setContentTitle(性能受到影响要停用) .setContentText(请查看引导加载程序通知) .setOngoing(true) // 变成常驻 .setFlag(Notification.FLAG_NO_CLEAR, true) .build(); nm.notify(TAG_ID, n); }代码本身没什么玄机关键在于两点一是渠道的重要性级别二是是否带 ongoing 标记。前者决定了它会不会弹到屏幕顶部变成悬浮通知heads-up后者决定了你能不能划掉。看明白这两行你就知道为什么“点一下停用”这种动作有时候只是把这个渠道降级而不是真的解决问题。2.3 通知渠道、悬浮通知与“停用”按钮的真实含义“要停用”这几个字最容易让人误解。它并不是在说“请把这个功能停用”而是厂商给这段提示配的一个按钮文案点下去一般有两种结果一种是跳到“开发者选项”页面暗示你去关掉某些调试开关另一种是直接把这个提示渠道的重要级别降到最低通知从此不弹横幅但依然静静躺在通知栏里。换句话说点“停用”多数情况下只是让它闭嘴不是让它消失更不是把设备恢复成官方状态。顺带说一句悬浮通知。它对应的就是IMPORTANCE_HIGH加上全屏 Intent 那套机制在 Android 11 上使用全屏 Intent 需要声明USE_FULL_SCREEN_INTENT权限并且系统会对非通话、非闹钟类场景做限制。有些团队做“紧急公告”时喜欢用这种大通知来强提醒实测下来在 Android 11 上成功率并不稳定用户只要在设置里关掉渠道或者把通知权限收回就完全收不到了。强提醒这件事靠系统通知本身是保证不了的这点后面第 4 章还会展开。3. 三种处理路线静音、屏蔽、回滚3.1 路线一只求安静把通知降级这是最省事、风险最低的做法适合只是嫌它烦、并不打算改变设备状态的人。操作路径是长按这条通知系统会弹出通知设置入口进去之后你会看到它所属的渠道名称把重要级别从“高/默认”改成“静默”或者把“允许打扰”关掉。改完之后圈栏里还是会有一条但不再弹横幅、不再响铃也不会在锁屏上强占位置。这里有个小技巧如果长按之后只给了“关闭通知”而没让你选级别说明这条通知走的是应用级开关你可以先把整个应用的通知关掉再回去逐个渠道打开你需要的那些。系统应用的渠道通常在“应用信息 → 通知”里能看到完整列表名字五花八门挑的时候认准跟你看到的那条文案对得上的那个。提示把渠道降级之后部分机型的引导加载程序提醒会换个渠道再来一次。这时候别急着骂重复上面的操作把所有相关渠道都调一遍基本就安静了。我自己的那台机器一共调了两个渠道之后半年没再弹过。3.2 路线二adb 屏蔽渠道与通知权限如果你连“通知栏里挂着一条”都不能忍可以用 adb 从系统层面把它的通知权限摘掉。第一步是找出到底是谁发的通知adb shell dumpsys notification --noredact | grep -i -E pkg|channel | head -50带上--noredact是为了让输出不被脱敏能看到真实的包名和渠道 ID。找到目标包名后可以用 appops 直接掐掉它的通知能力# 关闭通知权限Android 13 及以上用这个 appop 最直接 adb shell cmd appops set 包名 POST_NOTIFICATION ignore # 想恢复的时候 adb shell cmd appops set 包名 POST_NOTIFICATION allow在 Android 11 上POST_NOTIFICATION这个 appop 并不是所有机型都支持因为运行时通知权限是 Android 13 才引入的。更通用一点的办法是直接停用对应的系统组件adb shell pm disable-user --user 0 包名或者只停用它下面负责发通知的那个 service粒度高一点副作用也小一点adb shell pm list packages -d # 看看已经被停用的都有谁 adb shell pm list packages | grep -i boot注意pm disable-user是真的把组件停掉了不是让它闭嘴。系统级应用被停用之后可能出现设置项打不开、状态栏图标异常、OTA 无法进行等连带问题。动这一层之前一定先记下完整的包名出问题用pm enable原样恢复。另外这些操作在部分厂商 ROM 上会因为权限收紧而失败报SecurityException或Permission Denial这时候别硬刚回到路线一。3.3 路线三从根上解决重新锁定引导加载程序如果你希望彻底恢复官方状态唯一正路是把引导加载程序重新锁上。前提是设备必须已经刷回官方原厂固件并且版本和机型完全对得上。步骤大体如下但每个厂商的命令差异不小务必先查自己的机型文档# 进入 fastboot 模式后 fastboot devices fastboot flashing lock # 部分老机型用 fastboot oem lock锁回去之后ro.boot.verifiedbootstate会恢复成green那条通知自然就没了前面提到的 DRM、支付类校验也会陆续恢复正常。代价必须说清楚锁定操作几乎一定会触发一次数据清除等同于恢复出厂设置照片、聊天记录、账号登录状态统统归零所以动手前先做完整备份。另外如果机器上跑的不是官方固件锁定后可能直接无法开机这就需要重新解锁救回来一来一回数据还是保不住。还有个现实问题——解锁这个动作本身在很多厂商的记录里是留痕的锁回去也不会自动抹掉这属于厂商政策范畴需要自己权衡。我个人的做法是手上这台测试机就一直保持解锁状态接受那几项功能不可用但把通知静音掉真正要用的主力机从来不碰引导加载程序。测试用机和日常用机分开是省掉一大堆麻烦的最简单办法。4. 开发者与测试同学更该关注的事自测包的通知差异4.1 测试机总在提示量产机为什么没有很多人是在做 Android 开发时撞上这条通知的原因是团队的测试机大多解锁过、刷过自定义镜像方便抓日志和调内核。这时候容易产生一种错觉明明代码没动怎么测试机上一直弹提示用户那边却安安静静答案就在引导加载程序状态上它跟你的应用代码完全无关。这件事的实际影响是排查干扰。测试机上同时挂着系统提醒、你自己应用的通知、还有推送 SDK 的通知肉眼根本分不清谁是谁。我一般的做法是先把系统那些常驻通知静音掉再用dumpsys notification按包名过一遍确认自己应用的通知确实发出去了、渠道确实建对了。特别是 Android 8.0 之后忘记createNotificationChannel会导致通知静默丢失代码不报错、日志没异常新手最容易在这里卡半天。顺便提一句跨引擎的场景比如在 UE4 里通过 JNI 桥接调用系统通知很多时候只是传了一个通知 ID 和一个字符串就完事渠道那一步直接省了。结果就是 Android 8.0 以上完全收不到通知8.0 以下反而正常很容易被误判成“高版本兼容性问题”。只要走NotificationManager渠道就必须建这是硬性要求。4.2 通知栏消息的送达链路与异步通知验签把视野放宽一点“通知”这个词在工程里其实有两种完全不同的含义。一种是给人看的通知栏消息比如推送 SDK 下发到手机上的那条横幅另一种是给系统看的通知也就是服务端之间的回调消息比如订单支付完成后第三方异步回调你告诉你“这笔单子成功了”。前者的关键指标是到达率和点击率后者的关键是不能被伪造所以必须做验签。异步通知验签的通用做法是服务端把参数按约定顺序拼接用双方共享的密钥做一次 HMAC或者用对方给的公钥做一次签名校验比对通过才认为这条通知有效。常见踩坑点有三个一是拼接时把空值参数漏掉了导致签名对不上二是编码不统一一方用 UTF-8 一方用 GBK三是没做幂等同一个回调被重复推送时业务被重复执行。这三个坑跟 Android 版本没关系但带来的困扰往往比那条引导加载程序通知大得多。至于通知栏消息这一侧链路一般是这样业务服务端调用推送服务下发推送服务把消息投递到系统级通道系统再交给目标应用展示。点击之后跳到哪里靠的是消息里携带的跳转标识。以鸿蒙设备上的场景为例如果想做到“点击通知直接进到 App 内某个页面”需要在消息里带上目标页面的标识参数并且端侧要同时处理冷启动和热启动两个入口——冷启动时要等应用初始化完成再跳热启动时要在回调里解析参数。只处理其中一个入口就会出现“有时候能跳、有时候跳到首页”的诡异现象。同理用 uni-push 这类方案给 App 推通知栏消息时透传消息和通知栏消息的处理路径完全不同通知栏消息由系统直接展示应用拿到的是点击事件透传消息则要应用自己建通知。混用这两种模式是“线上有点击、线下没点击”这类数据对不上的常见原因。4.3 跨端提醒机制横向对比现在做产品很少只做一端通知这件事在各端的机制差异相当大放在一起看看会更清楚平台通知机制要点常见限制排查入口Android 11 及以上必须建渠道渠道级别决定是否弹横幅渠道被用户关闭后收不到全屏 Intent 受限应用信息 → 通知 → 渠道列表鸿蒙设备推送消息点击可携带跳转参数冷启动与热启动需分别处理系统设置里的通知管理Windows 桌面端走系统 Toast受“通知和操作”设置影响专注助手开启时全部静默系统设置 → 系统 → 通知Linux 服务器登录时由系统打印过期提醒如密码到期属于系统行为应用层关不掉chage -l 用户查看策略最后一行稍微展开说。Linux 上那条“密码即将过期”的提醒机制跟这次的引导加载程序通知有点像——都是系统在启动或登录阶段读取某个持久化状态然后主动告诉你。它由chage配合/etc/login.defs里的PASS_MAX_DAYS等参数控制到期前若干天开始提醒到期后强制改密。想看当前策略chage -l username它同样属于“系统说了算”的那一类应用层没有开关可以关掉。做跨端通知模块的同学最好记住这条规律凡是来源是操作系统的提醒先去找系统侧的配置入口别在应用代码里折腾。5. 常见问题与排查速查表实际操作中遇到的问题五花八门把高频的几条整理成表遇到时可以直接对号入座现象可能原因处理思路通知划不掉带 ongoing 与 no-clear 标记长按进设置调低渠道级别点“停用”后过几天又出现只是降级了渠道状态没变重复调渠道或走第 3.3 路线关闭应用通知后其他提醒也没了关的是应用级开关而非渠道重新打开应用通知逐渠道调整adb 命令报权限拒绝厂商 ROM 收紧了权限换用系统设置界面操作恢复出厂设置后仍有提示引导加载程序状态没变确认是否已重新锁定应用通知在测试机收不到未创建通知渠道检查渠道 ID 是否与代码一致再说几条文档里不会写、但实际很有用的经验。第一条改任何东西之前先截图记录。渠道名称、包名、命令输出全部存一份。系统设置这种地方改乱了很难凭记忆还原有截图能省掉大量试错时间。第二条别在主力机上做实验。解锁、停用系统组件、刷 vbmeta 这类操作失败成本可能是整机无法开机。手上备一台便宜的测试机几百块的投入能换来极大的心理安全感。第三条dumpsys是你最好的朋友。不管是查通知来源、查渠道状态还是查某条通知为什么没显示adb shell dumpsys notification基本都能给出答案。刚开始输出很吓人用grep顺着包名和渠道 ID 过滤几次就熟悉了。第四条推送类和系统类通知分开治理。我见过不止一个团队因为系统提醒太吵干脆在设置里把整个应用的通知关了结果自家业务推送一起被掐掉数据断崖式下跌还找不到原因。养成习惯系统来源的提醒单独处理业务推送单独维护渠道两者互不干扰。第五条验签失败先查参数拼接再查密钥。绝大多数签名不通过都是参数顺序、空值处理、编码格式这三件事真正密钥配错的比例反而很低。排错顺序搞反了会在密钥上浪费很多时间。最后分享一个我自己一直在用的做法把测试机上的系统级常驻通知统一静音然后在每次排查推送问题时先用dumpsys确认这条通知的包名和渠道 ID跟预期对上了再往下查。这个习惯听起来很笨但它帮我省掉的返工时间远比调那几行 adb 命令多得多。