1. 需求很小但三个无卡提示的来源各不相同上周接到一个挺典型的定制需求一台演示平板固件是 AOSP 基础上改的不插 SIM 卡只走 Wi-Fi。产品经理给的反馈很直接——锁屏左上角一直挂着没有SIM卡下拉通知栏里也有一条无SIM卡看着很掉档次也容易让客户误以为设备有问题。要我把它去掉。这个需求听起来不大真正动手才发现问题远不止删一行文字这么简单。锁屏界面和下拉框里的提示虽然都叫没有SIM卡但根本不在同一个控件里甚至连数据源都可能不一样。如果你只是照着某个模块的布局文件把 TextView 隐藏掉大概率会出现锁屏干净了、下拉栏还在或者下拉栏没了、锁屏又冒出来这种按下葫芦浮起瓢的情况。先说清楚一个容易被忽略的事实这类提示的信息源头在 Telephony 层而不是界面层。系统通过SubscriptionManager拿到当前订阅信息再通过TelephonyManager拿到 SIM 状态状态值为SIM_STATE_ABSENT时上层各模块就会各自决定要不要展示对应的文案。也就是说锁屏、下拉框、设置页每一个 UI 模块都是独立地去订阅这个状态然后自己做显示决策。你要删提示就得逐个模块去处理没有一个全局开关能一键搞定。适合看这篇文章的人主要是做定制 ROM、行业设备固件、或者手头有整机源码又想魔改系统 UI 的开发者。如果你手上只有 APK 没有源码我会在第 4 章讲反编译改 smali 的路径同样可以参考。先给你一张定位图后面各个部分会展开说明位置负责模块典型类/组件显示形态锁屏界面KeyguardCarrierText锁屏时钟附近的运营商/SIM状态文本状态栏SystemUIPhoneStatusBarPolicy状态栏图标、运营商文本下拉通知面板SystemUICellularTile/NotificationController蜂窝数据磁贴子标题、通知提醒设置页SettingsSIM 状态卡片无SIM卡状态行1.1 锁屏左上角与下拉框里分别是什么控件锁屏左上角那个没有SIM卡在 AOSP 里绝大多数情况是 Keyguard 的CarrierText画出来的。它本质上就是一个TextView被塞在锁屏布局里比如keyguard_status_bar.xml或者keyguard_carrier_text.xml。锁屏界面整体会隐藏系统状态栏把日期、时钟、运营商这些信息重新排布到锁屏布局上所以状态栏里的无SIM卡文本会被 Keyguard 自己的 CarrierText 承接住。下拉框里的就不一样了。下拉框分两个区域上面是快捷开关区Quick Settings下面才是通知列表区。快捷开关区里有个蜂窝网络磁贴CellularTile没有 SIM 卡时它的副标题会显示无SIM卡如果是通知列表里出现一条常驻提醒那多半是PhoneStatusBarPolicy这类策略类在 SIM 状态变化时发了一条通知。可以这样理解锁屏上的提示是界面自己在显示状态而下拉框里的提示分两种——一种是磁贴副标题一种是系统通知。它们的处理方式完全不同。1.2 数据源头SIM 状态从 Telephony 到 UI 的链路完整链路大概是这样的TelephonyManager / SubscriptionManager ↓ SIM_STATE_ABSENT KeyguardUpdateMonitor Keyguard 的监听器 ↓ CarrierText.updateCarrierText() ↓ 锁屏显示没有SIM卡 PhoneStatusBarPolicy / CellularTile SystemUI 的监听器 ↓ 状态栏图标 / 蜂窝磁贴副标题 / 通知 ↓ 下拉框显示没有SIM卡关键点在于Keyguard 和 SystemUI 虽然同属一个 SystemUI 进程Keyguard 已经是 SystemUI 的一部分但它们的监听和回调是独立注册的。你改了 Keyguard 的显示逻辑SystemUI 那边的监听照样会触发该显示还是会显示。所以第一件要做的事就是先分清你看到的那条提示到底属于哪一路。1.3 为什么这类提示默认删不掉很多刚接触系统 UI 定制的人会习惯性去设置里找开关然而Android 原生根本没有隐藏无SIM卡提示这个选项因为对于手机形态的设备来说没有SIM卡属于关键状态提示——影响拨号、短信、通话、网络等核心功能运营商和用户都需要看到这个状态。但对纯 Wi-Fi 设备、演示机、行业平板来说这提示确实是纯噪音。明白了这是多个模块独立展示同一个状态之后接下来的处理思路就清楚了不是去全局广播一个别显示的信号而是逐个模块屏蔽对应 UI 的渲染。下面按锁屏和下拉框两个场景分开讲。2. 锁屏左上角没有SIM卡先找到 CarrierText 再决定怎么断锁屏的处理逻辑相对好定位因为 AOSP 里这块逻辑很集中。核心类就是CarrierText.java代码路径一般在packages/apps/Keyguard/src/com/android/keyguard/CarrierText.java。部分新版本 AOSP 会放在packages/apps/SystemUI/shared/src/com/android/systemui/statusbar/policy/KeyguardCarrierText之类的地方但搜索CarrierText这个关键字总能找到。2.1 CarrierText 在这个版本里是怎么工作的CarrierText的updateCarrierText()方法会遍历当前的 SubscriptionInfo 列表拿每个 SIM 的 sim state 去做文案映射。伪代码差不多是这样private CharSequence getCarrierTextBasedOnSubState(SubscriptionInfo info) { int simState info.getSimState(); switch (simState) { case TelephonyManager.SIM_STATE_ABSENT: return mNoSimString; // 没有SIM卡 case TelephonyManager.SIM_STATE_NETWORK_LOCKED: return mNetworkLockedString; case TelephonyManager.SIM_STATE_NOT_READY: return mSimNotReadyString; case TelephonyManager.SIM_STATE_PERM_DISABLED: return mSimPermDisabledString; case TelephonyManager.SIM_STATE_CARD_IO_ERROR: return mSimCardIoErrorString; default: return info.getCarrierName(); } }mNoSimString是从R.string.keyguard_no_sim_card这类资源里读的。所以理论上最简单粗暴的改法是把这个 string 资源改成空字符串。但这里有个坑有些版本的 Keyguard 布局在 SIM 卡缺失时连整个CarrierText的可见性都会改字符串改空了布局仍可能占着位置。另外EMERGENCY CALL BUTTON仅紧急呼叫按钮往往紧挨着这个文本处理不好会让紧急信息按钮显示错位。2.2 方案A用 config_showCarrierText 关闭文本显示这是改动最小、最干净的方式。Keyguard 的布局里本来就预留了配置开关R.bool.config_showCarrierText控制锁屏是否显示运营商文字R.bool.config_showEmergencyCallLabel控制是否显示紧急呼叫按钮在 AOSP 的packages/apps/Keyguard/res/values/config.xml里你能看到默认值。定制时不要直接改 SystemUI/Keyguard 的源码资源而是做一个运行时资源覆盖包RRO overlay这样升级和回溯都方便。overlay 的Android.bp大致长这样runtime_resource_overlay { name: NoSimOverlay, theme: NoSimOverlay, product_specific: true, }同目录下放res/values/bools.xmlresources bool nameconfig_showCarrierTextfalse/bool /resources然后把这个 overlay 编进系统镜像或者用adb install方式叠加运行。这样锁屏上的 CarrierText 整块都会消失包括没有SIM卡无服务等所有运营商文案一步到位。但要注意这个开关影响的只是 Keyguard 里的文本状态栏顶部如果还显示运营商信息需要单独处理。如果你的定制锁屏是状态栏被锁屏遮住、时间下移的样式那这个方案基本够用如果是锁屏顶部直接透出状态栏的样式就得连带处理 SystemUI 里的运营商文本。2.3 方案BKeyguard 布局覆盖让 CarrierText 消失如果你已经进到系统源码里或者只想在布局层面做隐藏可以覆盖 Keyguard 的布局文件。找到包含 carrier text 的那个布局比如keyguard_status_bar.xml把整个控件高度设置为 0dp或者加一句android:visibilitygone通过 overlay 覆盖整个 xml 文件时要注意把原布局里的其他控件照抄出来只改 CarrierText 相关节点否则容易把锁屏结构改坏。我在实际项目里见过有人把keyguard_status_bar.xml覆盖后忘了保留日期View结果锁屏日期直接没了开机后全家都来找我。2.4 方案C没有源码时反编译 CarrierText 强制返回空手上只有成品 ROM 包、没有源码的情况下可以用apktool反编译SystemUI.apkKeyguard 在较新版本里已经合并进 SystemUI。反编译出来后在 smali 目录里搜CarrierText重点找getCarrierTextBasedOnSubState方法。思路是在方法开头直接把返回值置为空字符串让它后面的判断全部跳过.method private getCarrierTextBasedOnSubState(Landroid/telephony/SubscriptionInfo;)Ljava/lang/CharSequence; .locals 2 const-string v0, return-object v0 .end method这只是演示思路实际 smali 还要匹配你那个版本的方法签名和寄存器数量不建议直接照抄。改完 smali 之后要重打包并签名系统应用必须使用平台签名否则 SystemUI 起不来会卡在启动界面。3. 下拉框里的没有SIM卡通知、图标、子标题要分开处理下拉框通知面板里的没有SIM卡比锁屏复杂因为它的来源至少有三四种不先定位就直接改方案大概率是白折腾。3.1 先判断它到底以什么形态出现在下拉框找个有 SIM 卡槽但不插卡的机器下拉通知面板观察提示出现在哪个位置出现在快捷开关区域通常紧挨着移动数据磁贴显示为灰色小字那基本是CellularTile的 subtitle。出现在通知列表顶部像一个常驻提醒左上有 SIM 卡图标这是 SIM 状态通知。出现在状态栏残留也就是下拉面板顶部仍然透出状态栏图标没有SIM卡。这三种来源完全不同处理方式也各不相同。下面逐个拆。3.2 Scenario 1通知列表里的 SIM 卡提醒这种是最好处理的。AOSP 里PhoneStatusBarPolicy的updateSimState()方法会在 SIM 状态变化时调mNetworkController或直接发通知。新版本里负责这条通知的类叫SimStatusNotification在 SystemUI 的statusbar/policy或phone包里它会在SIM_STATE_ABSENT时发布一条Notification。最优雅的处理方式是直接禁用这个通知渠道而不是在通知管理层面拦截。在 SystemUI 侧你可以自己搜索发送通知的代码把对应的notify()调用禁用或让simState SIM_STATE_ABSENT时不发送通知即可。如果你不想改代码还有一个偏门但有效的招在设备的res/values/strings.xml里把sim_missing等相关字符串改为空字符串。但这一招对通知标题有效对通知里带的正文图标无效属于表面处理不太推荐。3.3 Scenario 2快捷开关区的蜂窝数据子标题另一种常见形态是下拉面板快捷开关区里的移动数据磁贴下面跟着一行小字无SIM卡。这个位置的文案来自CellularTile。CellularTile.getStateDescription()或getDetailAdapter()会根据当前订阅状态返回子标题。处理思路有两个方向方向一改逻辑。在源码里找到类似if (mSubscriptionInfo null || isSimAbsent())的分支不让它输出无SIM卡文案。这需要你重新编译 SystemUI。方向二做 overlay 覆盖字符串。如果无SIM卡这行字是从 SystemUI 的字符串资源读的通常是cellular_detail_no_sim或status_bar_no_sim_message你可以用 overlay 把对应 string 改成空字符串。但要注意有些版本的CellularTile不是直接读资源而是从SubsidySettings或CarrierConfig获取如果改字符串无效就说明文案被写死在代码里了只能走方向一。3.4 Scenario 3状态栏残留图标被带进下拉还有一种情况锁屏界面其实已经把状态栏隐藏了但下拉通知面板顶部仍然会显示状态栏的一部分——比如信号格图标和一个×把面板拉下来后能看到状态栏里那条没有SIM卡仍然在。这种形态的源头根本不在下拉框里而在状态栏本身的策略。AOSP 里状态栏图标是否显示 SIM 缺失标记由PhoneStatusBarPolicy监听onSimStateChanged后调用updateSimState()代码逻辑里会对SIM_STATE_ABSENT做处理比如显示slot_sim_missing这个图标。要处理它应该去PhoneStatusBarPolicy或StatusBarPolicy的 sim 更新逻辑里把对SIM_STATE_ABSENT的处理屏蔽掉。用资源 overlay 是解决不了这个的因为图标是否出现是代码根据状态设置 icon 的。这是整个需求里最容易被忽视的一处——很多人改完锁屏、改完下拉框最后发现状态栏还有一条来回白忙活。4. 三种改造路径怎么选源码、资源覆盖、反编译聊完具体位置再来系统性对比三种实现路径。很多人在这一步纠结很久我的建议是先看你能不能拿到源码再看你需要的改动深度。4.1 源码级修改的特点与适用场景如果你手里有完整的系统源码或者至少有 SystemUI 源码这是最彻底的方案。你可以直接改逻辑连显示状态与数据源不一致这种后患都一起解决。比如在CarrierText里注释掉对SIM_STATE_ABSENT的处理、在CellularTile里让无 SIM 时副标题为空、在PhoneStatusBarPolicy里跳过 sim 缺失的图标展示。优点改的是判断逻辑不是表面遮挡重启后不会恢复可以精确控制哪些状态显示、哪些状态隐藏后续其他项目复用方便缺点每次改动都要编译整个 SystemUI迭代效率低对没有源码的团队或外包项目来说不现实4.2 资源覆盖RRO能做到和做不到的边界资源覆盖是定制 ROM 最常用的手段之一特点是不碰代码只换资源。它能覆盖的包括字符串资源改成空字符串布尔配置config_showCarrierText等布局文件里的可见性/尺寸但是不能覆盖代码中直接拼接的字符也不能改变控件的生成逻辑。我见过有人在 overlay 里改了所有相关 string 为空结果通知栏和磁贴的文案还在就是因为那个版本的 SystemUI 直接把无SIM卡定义在 Java 代码里根本不走资源。所以用资源覆盖前最好先反编译确认一下目标文案到底是不是从资源读的。确认方式把 APK 解包用aapt dump strings或者在res/values*/strings.xml里搜索目标文案能找到说明可以覆盖找不到就只能改代码。4.3 反编译修改的实际操作要点只有 APK 没有源码时反编译是唯一出路。基于我多次改 SystemUI 的经验流程如下用apktool d SystemUI.apk解包在smali/目录里搜索关键字比如无SIM卡直接搜字符串会定位到 smali 里的常量、no_sim、sim_missing、SIM_STATE_ABSENT定位到相关方法理清逻辑后再改回编译apktool b对 APK 做平台签名必须确认系统应用签名一致adb push到/system/priv-app/SystemUI/SystemUI.apk或打包进系统镜像提示改 SystemUI 之前一定先做完整备份否则一旦签名不对或者 smali 改错SystemUI 进程会在开机阶段反复崩溃设备基本只能重刷。4.4 选型对比表维度源码级修改资源覆盖RRO反编译修改改动范围逻辑层资源层代码逻辑能处理状态栏图标能不能能能处理代码写死文案能不能能重启后是否稳定稳定稳定稳定开发周期长需编译短可动态加载中等需反编译重打包对开发者的要求有完整源码环境懂资源系统会 smali 和 APK 签名系统版本升级时的维护成本中代码会变低资源和配置相对稳定高smali 随版本变化大我个人在大多数项目里的推荐顺序是有源码优先改源码没源码但目标文案能定位到资源时用 overlay只有非改代码不可时才上反编译。前两种都比第三种安全得多。5. 踩坑记录与验证清单最后聊几个实操中容易翻车的地方全是真实项目里踩过的坑。5.1 只删UI不处理数据源重启后提示又回来了这是最常见的坑。有人直接改布局把 CarrierText 的可见性设为 gone重启后发现锁屏确实干净了但下拉通知栏里那条无SIM卡还在——因为 SIM 状态通知根本不是 Keyguard 发的你只是把锁屏的显示关掉了SystemUI 的 SIM 监听器照样工作、照样发通知。正确做法是先按第 3 章里的三类形态把下拉框的提示来源全部列出来再逐个处理。哪怕你只想删锁屏也要挨个确认状态栏图标有没有、下拉磁贴副标题有没有、通知列表有没有。只有全部列完处理完才叫真正删除。5.2 仅紧急呼叫和无SIM卡是两种完全不同的状态有些设备在不插 SIM 卡时锁屏显示仅紧急呼叫有的显示没有SIM卡这是由SIM_STATE_ABSENT和当前是否注册上网络决定的。如果你只是把没有SIM卡这个字符串改成了空但CarrierText里还有一种状态对应的是仅限紧急呼叫或运营商名字那么下次系统状态切换后这些文案还是会再次出现。因此不要只针对一个状态做处理。直接用config_showCarrierText false把整块 CarrierText 关掉是最彻底的因为它不区分状态。反编译改 smali 时同理返回空字符串要放在getCarrierTextBasedOnSubState方法入口处而不是只改某一个 case。5.3 系统签名、只读分区、apk 覆盖顺序改 SystemUI/Keyguard 之后还有一个工程问题系统分区默认只读直接adb push会失败或者成功但重启被还原。正确流程是先adb rootadb remount重新挂载 /system 为可写推入新 APK改完立即adb reboot还有一点容易被忽略SystemUI.apk 是系统私有应用必须用平台签名platform key签名不是随便一个自签名就行。签名不一致时系统会拒绝加载直接导致 SystemUI 崩溃。如果你手上没有平台密钥就不要走反编译改 APK 这条路。5.4 版本差异Android 12 之后的 QS 布局改动Android 12 之后快捷开关面板的布局和渲染逻辑有了很大变化。CellularTile的副标题渲染逻辑从原来的TextView改成了由QSTileView统一管理部分场景下文案不再直接来自CellularTile的字符串资源而是来自TilesProvider或者系统网络的NetworkController。所以网上搜到的一些改某行代码就能隐藏无SIM卡的老教程在 Android 12/13/14 上很可能失效。动手前一定要确认设备的确切 Android 版本然后反编译对应版本的 SystemUI 去定位不要拿旧经验硬套。5.5 交付前的验证清单改完之后下面这组验证动作建议逐一走一遍锁屏界面左上角/时钟附近是否还有没有SIM卡或无服务字样下拉通知面板快捷开关区有无无SIM卡副标题下拉通知面板通知列表里有无 SIM 卡相关常驻通知状态栏锁屏和桌面状态栏是否还有 SIM 缺失图标重启一次确认所有修改都持久生效插入一张有效 SIM 卡确认正常状态下还能显示运营商名称如果要求保留的话验证时尤其要注意无 SIM 状态下系统可能过几秒才刷新状态不是立即显示。有些模块用了异步监听改完之后要等一会儿或者开关一次飞行模式才能确认修改真的生效。上面这些坑我基本每一条都亲自踩过。尤其是锁屏删了、下拉框还在这个循环我花了一整天才明白是因为状态栏图标、磁贴副标题、通知提醒三者的监听器是独立注册的。所以说这是个小需求其实一点都不小——真正做定制系统的哪个不是被这种看起来一句话的事磨出来的。