Android 14定制ROM默认无锁屏的完整实现与避坑指南

定制 ROM 的时候很多需求看起来简单真正动手才发现全是细节。比如“默认锁屏方式改为无”一句话的需求背后牵扯到设置数据库默认值、Keyguard 的启动逻辑甚至还要处理“重锁”和“安全锁屏”的边界问题。这篇文章我把 Android 14 上整个实现思路、改动点、编译验证过程以及我踩过的坑完整记录下来给后面做同样需求的人一个参考。1. 需求拆解与整体思路1.1 这个需求到底在解决什么问题做定制系统的人应该都遇到过这类场景客户要求设备开机后直接进桌面不要锁屏不要滑动解锁也不要密码界面。常见于工控平板、收银机、演示机、车载中控这类专用设备或者某些定制 ROM 给特定用户群体使用。这里的“锁屏方式为无”不是简单的“把锁屏界面的风格设置为无”而是指系统默认的锁屏解锁方式直接就是 None无即设备解锁后不会进入 Keyguard 锁屏界面而是直接显示桌面。这和用户在设置里手动选择“无”的效果一致但差别在于我们要在出厂状态下就默认如此而且不能让用户通过简单的设置操作就回到默认的锁屏逻辑。另外一个容易被忽略的点是Android 的锁屏体系里包含“滑动锁屏”和“安全锁屏”两层。安全锁屏PIN、密码、图案由 LockSettingsService 管理而滑动锁屏和“无”由 Keyguard 逻辑控制两者是独立的。我们改的是后者即关闭“滑动锁屏”这一层让系统不会拉起 Keyguard 的解锁界面。如果设备里还配置了安全锁屏比如 DevicePolicy 强制要求设置 PIN那该弹 PIN 的时候还是会弹这是正常行为也不算需求冲突。1.2 为什么不能只在 Settings 里改一个开关第一次接手这个需求的人很容易想到直接查 Settings.Secure 里的LOCKSCREEN_DISABLED或者LOCK_SCREEN_WHEN_SLEEP在设置数据库里把默认值改了不就行了吗理论上没错但这只是“半成品”。因为 SettingsProvider 的默认值存在于 database 的初始种子数据里老设备升级或者数据分区残留时数据库里的旧值会覆盖默认值。而且很多第三方 ROM 或 GMS 包会在开机后写入自己的锁屏设置单纯改默认值很容易被覆盖。更关键的是Android 12 以后Keyguard 的显示控制逻辑做了一次比较大的调整KeyguardSecurityContainer对外暴露的显示逻辑不再单纯依赖 Settings 里的值还叠加了KeyguardUpdateMonitor的回调状态。换句话说即使你把设置项改成“无”某些场景下 Keyguard 还是会被拉起来比如一次未完成的解锁尝试、SIM 卡解锁请求、或者系统 OTA 后的首次启动。所以一个“避坑版”的实现思路应该是三层叠加第一层修改 SettingsProvider 的默认值让系统从初始化开始就处于“无锁屏”状态。第二层在 Keyguard 的显示控制逻辑里对“是否需要显示锁屏”的判断做补丁确保默认不显示。第三层处理“强解”逻辑也就是在开机完成、用户解锁完成等关键节点上确保系统不会因为状态机异常而强行点亮 Keyguard。1.3 方案选型改 frameworks 还是 overlay在没有 AOSP 源码权限、只做“轻定制”的情况下也可以用 overlay 的方式去覆盖默认配置。具体来说就是通过frameworks/base/core/res/res/values/config.xml里的config_lockScreenDisabled这个布尔值用 RRORuntime Resource Overlay或者直接在源码的 overlay 目录下覆盖为 true。这个方案的好处是侵入性小编译快不会碰 Java 层代码。但缺点也很明显它控制的是“锁屏是否完全禁用”的全局开关一旦打开连“安全锁屏”设置界面里的“滑动锁屏”选项都会被隐藏而且它主要作用于LockPatternUtils.isLockScreenDisabled的查询结果。如果你需要“能进设置查看但默认不锁屏”这种更细颗粒度的控制这个方案就不够用了。我给客户做需求时通常选择改 Java 层而不是只依赖 overlay。因为 overlay 方案对 Keyguard 的某些异步刷新场景比如休眠唤醒后重新评估一次显示状态控制不够彻底实际测试中会出现“息屏后再亮屏锁屏偶尔闪现一下”的问题。所以这篇文章的主线方案是“Java 层默认值 Keyguard 显示逻辑补丁”overlay 方案作为备选也会提到。2. 核心修改点逐一拆解2.1 修改 SettingsProvider 的默认锁屏配置先看第一层改动文件路径在frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java。在这个文件中能找到默认的Settings.Secure初始数据其中有一项就是Settings.Secure.LOCK_SCREEN_WHEN_SLEEP这个键的默认值定义在frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java的loadSecureSettings方法里不过更规范的做法是看frameworks/base/core/res/res/values/config.xml里的config_lockScreenWhenSleepDisabled是否被 overlay 覆盖。Android 14 里比较直接的方式是给Secure.Settings添加自定义的加载分支例如// 默认值改为 0即关闭锁屏 if (getIntForUser(resolver, Settings.Secure.LOCK_SCREEN_WHEN_SLEEP, userId) 0) { putIntForUser(resolver, Settings.Secure.LOCK_SCREEN_WHEN_SLEEP, 0, userId); }更稳妥的写法是直接覆盖config_lockScreenWhenSleepDisabled为 true。这个配置项在frameworks/base/core/res/res/values/config.xml里声明含义是“当设备休眠时是否禁用锁屏”。把它设为 true 后SettingsProvider 初始化时会把LOCK_SCREEN_WHEN_SLEEP的默认值置为 0。另外还有一个老牌键位Settings.Secure.LOCKSCREEN_DISABLED这个键在KeyguardSecurityContainer的显示逻辑里会用到但它在较新的 Android 版本中已经逐渐被config_lockScreenDisabled取代。如果你想覆盖得更全面建议同时关注这两个地方。实际修改时需要注意SettingsProvider 的种子数据对“直接插数据库”或者“调用 Settings 接口”都生效但如果你改了默认值后没有清理 userdata 分区针对同一个 user 的旧数据仍然保留原有值。所以测试时必须做到“刷机后首次开机”或者手动清除设置数据设置应用清除数据 /pm clear com.android.providers.settings。2.2 改 Keyguard 显示逻辑让锁屏界面默认不弹出来只看第一层改动大多数场景下能解决“解锁方式为无”的问题因为设置里的开关已经是“无”了。但我在实际测试中遇到了一个坑设备休眠唤醒后偶尔会闪一下 Keyguard 界面尤其是从“正在充电”或“AODAlways On Display”状态唤醒时概率大约 10% 左右。这个问题的根源在KeyguardSecurityContainer.showPrimarySecurityScreen()方法。它负责决定进入 Keyguard 后显示哪种安全界面。如果这里面的判断逻辑没有正确识别“无锁屏”状态它仍可能把默认的安全屏滑动锁屏展示出来。文件路径frameworks/base/packages/SystemUI/src/com/android/systemui/keyguard/KeyguardSecurityContainer.java关键判断逻辑在shouldShowSecurityScreen()或showPrimarySecurityScreen()中其中有一段类似下面这样的逻辑private void showPrimarySecurityScreen(boolean turningOff) { final boolean quietMode mSecurityMode SecurityMode.None !mUpdateMonitor.isDeviceInteractive(); // ... }Android 14 上要做“无锁屏”可以在进入该方法时直接判断锁屏是否被禁用如果禁用则强制跳到SecurityMode.None并直接dismissif (mLockPatternUtils.isLockScreenDisabled(KeyguardUpdateMonitor.getCurrentUser())) { mSecurityMode SecurityMode.None; // 绕过剩余的可视化逻辑直接回调解锁结果 getCallback().onCancelClicked(); return; }注意isLockScreenDisabled这个接口在 Android 14 里的签名是public boolean isLockScreenDisabled(int userId)它内部会综合Settings.Secure.LOCKSCREEN_DISABLED或config_lockScreenDisabled来判断。对这个方法做补丁能确保不管 Keyguard 被什么原因唤醒最终都不会展示锁屏界面。另外还有一个隐蔽的位置KeyguardViewMediator.doKeyguardLocked()。这个方法负责在系统准备显示锁屏时做前置判断Android 14 里它已经有了对isLockScreenDisabled的检查但它的判断时机偏晚在个别“快速按压电源键”场景下会漏掉。为了彻底可以在doKeyguardLocked()开头也加一个同样的判断直接返回不显示。2.3 处理“休眠后仍然重锁”的问题改完上面两层后屏幕上确实不会出现锁屏界面了但还有一个逻辑需要处理设备休眠后系统会认为“设备进入非交互状态”此时如果安全锁屏没有启用Keyguard 的状态机默认会走“锁屏重锁”的逻辑。表现为亮屏后直接跳过解锁但状态栏下拉面板里可能还会看到“锁定”图标一闪而过。这个现象背后的关键类是KeyguardUpdateMonitor和KeyguardSecurityCallback。想要“真正无锁屏”得让系统认为“当前用户始终是活跃的”即让isDeviceInteractive()和isDeviceLocked()之间形成默认的“无锁”关系。更简洁的做法是修改KeyguardSecurityContainer的onStartedGoingToSleep和onFinishedGoingToSleep回调在睡眠周期中不触发安全状态刷新Override public void onStartedGoingToSleep(int why) { if (mLockPatternUtils.isLockScreenDisabled( KeyguardUpdateMonitor.getCurrentUser())) { return; } super.onStartedGoingToSleep(why); }这种做法不会影响“按电源键休眠”也不会影响“双击亮屏”等交互只是让 Keyguard 不再因睡眠状态变化而重新显示。如果你不确定改哪些方法一个更稳妥的判断方式是先跑一次adb shell dumpsys window policy查看mShowingKeyguard的状态确认问题边界后再动手。3. 实际操作流程与编译验证3.1 前置准备源码环境与同步开始改代码之前确保你已经能完整编译 AOSP。如果你还没拉过 Android 14 的源码这里有几个关键检查点系统环境建议 Ubuntu 20.04 或更新版本内存 32 GB 以上磁盘剩余至少 400 GBAOSP 源码加输出物很容易吃掉 300 GB。安装依赖openjdk-11、git-core、gnupg、flex、bison、build-essential、zip、curl、zlib1g-dev、libc6-dev-i386、libncurses5-dev、lib32z1-dev等。确认repo工具可用并且已经同步 Android 14 的 release 分支常见的有android-14.0.0_r*系列。准备阶段最容易犯的错误是没同步到正确的 tag 就开改。不同 tag 之间同一文件的代码可能有细微差异比如KeyguardSecurityContainer在某些安全补丁版本中多了一个mIsSecure的判断条件直接套用旧补丁会编译失败。所以动手前先记下你的repo info里的版本号再去 Android Code Search 上对照同一版本源码。3.2 修改文件清单与具体 diff下面是我在 Android 14.0.0_r35 上实际验证过的修改你可以直接对照你的代码树做适配。文件一frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java在loadSecureSettings方法末尾或者你自定义的loadDefaultSecureSettings方法里加入对LOCK_SCREEN_WHEN_SLEEP的强制覆盖final int lockScreenWhenSleep getIntForUser(resolver, Settings.Secure.LOCK_SCREEN_WHEN_SLEEP, userId); if (lockScreenWhenSleep ! 0) { putIntForUser(resolver, Settings.Secure.LOCK_SCREEN_WHEN_SLEEP, 0, userId); }这段代码本身不会影响已有数据库因为前提是getIntForUser读到的默认值来自config_lockScreenWhenSleepDisabled。如果 overlay 已经把配置覆盖为禁用这里读到的就是 0直接跳过写入。如果还没改 overlay 但想快速验证可以暂时在这里直接putIntForUser强制为 0。提示这个文件非常大改的时候注意不要误把其他默认值逻辑也改了。建议先定位到loadSecureSettings在方法末尾追加自己的逻辑不要动原有的for循环。文件二frameworks/base/packages/SystemUI/src/com/android/systemui/keyguard/KeyguardSecurityContainer.java在showPrimarySecurityScreen方法最前面加一个快速返回Override protected void showPrimarySecurityScreen(boolean turningOff) { final int user KeyguardUpdateMonitor.getCurrentUser(); if (mLockPatternUtils.isLockScreenDisabled(user)) { mSecurityMode SecurityMode.None; getCallback().onCancelClicked(); return; } // 原有逻辑... }这里有个小坑SecurityMode.None是KeyguardSecurityModel.SecurityMode枚举里的一个值如果你的源码版本中该枚举名称不同比如有些版本叫Invalid编译会直接报错。先grep一下枚举定义再写代码别想当然。文件三frameworks/base/packages/SystemUI/src/com/android/systemui/keyguard/KeyguardViewMediator.java在doKeyguardLocked方法的最前面补上同样的判断private void doKeyguardLocked(Boolean showPreview) { final int user KeyguardUpdateMonitor.getCurrentUser(); if (mLockPatternUtils.isLockScreenDisabled(user) !mLockPatternUtils.isSecure(user)) { return; } // 原有逻辑... }这里我额外加了!isSecure(user)条件目的很明确如果这台设备被企业策略强制要求 PIN 或密码比如设备管理器方案我们不希望这里的补丁把安全锁屏绕过。实际需求是“无锁屏”而不是“无安全”所以这个条件可以作为安全冗余保留。3.3 编译关键模块与刷机验证改动涉及framework和SystemUI两个模块。如果你只想快速验证不需要整个镜像都重编可以选择性编译模块然后单独pushsource build/envsetup.sh lunch 你的产品名-userdebug make -j$(nproc) framework make -j$(nproc) SystemUI编译成功后输出文件一般在out/target/product/device/system/framework/framework.jar out/target/product/device/system_ext/priv-app/SystemUIGoogle/SystemUIGoogle.apk如果你的设备是 Google 原生机型且使用 SystemUIGoogle则路径为系统分区下的priv-app/SystemUIGoogle。普通 AOSP 模拟器通常是SystemUI别搞混。模块编译完成后用 adb 推送并重启adb root adb remount adb push out/target/product/device/system/framework/framework.jar /system/framework/framework.jar adb push out/target/product/device/system/framework/arm64/boot-framework.art /system/framework/arm64/boot-framework.art adb push SystemUI路径 /system_ext/priv-app/SystemUI/SystemUI.apk adb reboot如果是真机这种adb push方式只适合 userdebug 版本且开启了 remount 的机器一旦涉及禁用 dm-verityadb disable-verity操作最好先备份完整super镜像避免变砖。更稳妥的做法是直接编完整镜像然后 fastboot 刷机make -j$(nproc) fastboot flashall -w-w会清空数据这是最干净的验证方式。之前我遇到过用模块 push 的方式验证系统设置里锁屏选项显示正确但休眠唤醒偶尔闪现 Keyguard就是因为 SystemUI 的缓存状态没有被彻底重置清一次数据后才复现出真实表现。3.4 验证清单怎么确认真的改成功了改完之后不能只看“设置里显示无”那是表象。我的验收清单一般是这几条冷启动开机后直接进入 Launcher不出现任何 Keyguard 动画。按电源键休眠再点亮直接回到桌面。从 AOD 状态唤醒不闪烁、不跳锁屏。下拉状态栏不存在“已锁定”提示。设置安全锁屏界面显示“无”或对应定制文案。尝试设置 PIN 或密码后临时生效但锁屏方式重新选择为“无”后后续唤醒不再出现 Keyguard。最后一条尤其重要。如果你在改完源码后先在设置里设置了 PIN系统会切换成安全锁屏此时你测试“无锁屏”需求肯定是不通过的。出厂状态或恢复出厂设置后才是真正的默认“无”状态。所以验收时要么恢复出厂要么清除系统设置数据。4. 常见问题与排查技巧实录4.1 编译报错 out/soong/build.ninja failed这个错误在我第一次改 Android 14 时被坑过一次表现形式是编译刚开始就退出日志里出现FAILED: out/soong/build.ninja cd $(dirname out/soong/build.ninjacd大致的报错原因是 soong 重新生成 build 脚本时出现异常常见诱因有三种环境变量污染比如JAVA_HOME指向了不存在的 JDK 路径。源码目录的.repo状态不一致比如手动切换分支后残留旧产物。磁盘空间不足soong 生成脚本时需要一定的临时空间。排查方式按顺序走# 先清理 soong 相关产物重新生成 rm -rf out/soong source build/envsetup.sh lunch 你的产品名-userdebug make -j$(nproc) framework如果还不行把 out 目录整体清理一次或者至少rm -rf out/combined再重新跑。大多数情况下清理后都能恢复。如果依然失败检查df -h确认磁盘剩余空间尤其是out所在分区的空间。另外我在 Android 14 上遇到过一种特殊情况同时改了多个模块的Android.bp或Android.mk导致 soong 解析错误。比如你在SystemUI里新增了一个依赖库但没在Android.bp的deps里声明soong 生成阶段就会报出这种“奇怪”的错误。所以如果这次改动涉及bp文件优先检查自己的依赖声明。4.2 改完后锁屏仍然出现排查方向如果代码编译刷机后仍然看到锁屏不要急着怀疑代码没生效先按这个顺序排查第一个方向是数据库值。用adb shell settings get secure lock_screen_when_sleep查看当前值如果返回 1说明你改的 SettingsProvider 默认值没有起作用。最常见原因是你测试机上还保留着旧数据。settings put secure lock_screen_when_sleep 0可以手工验证但真正测默认值必须恢复出厂或清除 SettingsProvider 数据。第二个方向是 Keyguard 层的判断是否命中。在KeyguardSecurityContainer里加一行日志Log.d(KeyguardDD, lock disabled ...)然后adb logcat | grep KeyguardDD看有没有输出。如果没有输出说明代码分支没有走到需要检查isLockScreenDisabled是否返回了 false。这个接口对“安全锁屏”和“无锁屏”的判断有区分如果用户已经设置过 PIN它会返回 false这是符合预期的。第三个方向是新的异步任务。Android 14 上doKeyguardLocked的调用方非常多变UserSwitcher、StatusBar、NotificationShadeWindowController都有可能在各自状态回调里触发。如果只在KeyguardViewMediator里加了判断但不小心漏了StatusBarStateController的某个监听就会出现“解锁瞬间卡一下”或“锁屏一闪而过”。我的建议是加日志后抓完整 logcat再决定补丁位置。4.3 开机向导阶段锁屏仍然出现还有一种高频现场项目使用 SetupWizard首次开机时锁屏界面出现在向导前面用户还没进入系统就看到锁屏界面体验极差。这在定制 ROM 里非常常见。原因是 SetupWizard 运行期间KeyguardViewMediator在BOOT_COMPLETED后会做一次锁屏显示评估。我们在doKeyguardLocked里加了isLockScreenDisabled判断但这个阶段用户数据可能还未完全初始化SettingsProvider中的值可能还没被正确读取。解决办法有两个思路在KeyguardUpdateMonitor中当mDeviceProvisioned为 false 时即开机向导还没完成强制不显示 Keyguard。在KeyguardViewMediator中判断mLockPatternUtils.isLockScreenDisabled前先确认当前用户已解锁isUserUnlocked。从稳定性角度我推荐第二种思路if (!mLockPatternUtils.isLockScreenDisabled(user) || mUserManager.isUserUnlocked(user)) { // 原有逻辑 }注意这里只是示例方向具体条件要根据你的需求测试。有些项目希望向导期间完全不出现锁屏有些则允许“虽然默认无锁屏但向导期间仍显示锁屏”的老逻辑。我一般直接给客户做成前者因为向导期间弹锁屏确实很碍事。4.4 改完 Setting 界面“无锁屏”选项显示异常有些定制项目会在设置里新增一个选项让用户自行切换“无锁屏”和“滑动锁屏”但如果只改了系统默认值不处理界面对应逻辑用户切换后状态会不刷新。这个问题常见于Settings应用的SecuritySettings中LockScreenPreferenceController会对锁屏类型做监听并在onResume时刷新 UI。如果你只是从数据库层面把默认值改了界面可能仍显示旧的“滑动解锁”选项。解决路径是在定制的 Settings 应用里覆盖该 Controller 的updateState或displayPreference方法让它的可选列表与数据库实际值保持同步。但这里要提醒一句Settings 里的锁屏类型切换走的是LockPatternUtils.setLockScreenDisabled它底层会调用Settings.Secure.putInt写入LOCKSCREEN_DISABLED。如果你的补丁只在showPrimarySecurityScreen里做了判断没有同步修改这个方法的写入行为那么用户切换锁屏类型后系统依然会遵守默认“无锁屏”逻辑界面和实际表现会对不上。所以我一般建议在定制需求中要么完全隐藏锁屏类型选项要么把切换逻辑一并接管避免出现这种“半吊子”状态。5. 实用扩展无锁屏的完整指南当你把“默认锁屏方式为无”做完后还可以继续体验一下相关的联动问题。这里说几个我从实际项目里总结的扩展点供你做方案设计时参考。5.1 第三方锁屏应用对“无锁屏”的影响一旦系统默认是“无锁屏”第三方锁屏应用比如某些极简桌面、老人模式桌面自带的锁屏就不会被触发因为它们的显示前提是系统 Keyguard 存在。这在某些场景下是好事但如果你既要做“无锁屏”又要跑第三方锁屏那就得谨慎设计。一种可行的设计方案是保留系统 Keyguard 的“滑动解锁”层但把默认安全模式设为无。这样第三方锁屏应用的感知仍然成立用户感知为“第三方提供的锁屏界面”而不是系统锁屏。但这样一来就需要系统在“无锁屏”状态下还能响应第三方锁屏的addCallback操作复杂度会高不少。如果不是硬需求我建议直接不让三方锁屏参与。5.2 与“快速启动相机”等群众行为的兼容部分定制 ROM 会把“双击电源键快速启动相机”做成默认功能。当锁屏被禁用后此功能依赖的KeyguardViewMediator的onCameraLaunchRequested逻辑会受影响。你需要在KeyguardViewMediator中检查当isLockScreenDisabled为 true 时onCameraLaunchRequested仍然能正常向 Camera 应用发送启动 Intent但不触发 Keyguard 显示。这类交互逻辑的坑在于很多开发者只关注“不显示锁屏”忽略了 Camera 快捷手势在无锁屏状态下的行为。如果直接导致相机无法从锁屏快捷键打开用户会以为是相机应用的 bug其实就是系统状态机没有正确跳出“锁屏态”。5.3 多用户切换时可能出现的“锁屏残留”如果你的定制设备支持多用户且每个用户的锁屏设置不一致比如用户 A 设置了 PIN用户 B 是“无锁屏”那么切换用户时 Keyguard 的显示逻辑要特别留意。isLockScreenDisabled是按 userId 查的理论上不会串但KeyguardUpdateMonitor.getCurrentUser()在某些生命周期节点上可能还没切到新用户导致补丁判断失效。一个稳妥做法是在关键状态回调里主动拿当前前台用户而不是依赖缓存字段int currentUser ActivityManager.getCurrentUser(); if (mLockPatternUtils.isLockScreenDisabled(currentUser)) { // 快速关闭锁屏 }这样可以避免“切用户瞬间闪现锁屏”的尴尬。实测下来这个现象在 Android 14 的多用户切换里出现的概率比 Android 12 更高因为 Android 14 对用户切换动画做了调整Keyguard 的可见性判断滞后了半拍。5.4 深度定制彻底移除锁屏界面依赖如果你的需求是“设备上完全不希望存在锁屏 UI”的那种极端项目可以考虑直接把KeyguardSecurityContainer相关布局从 SystemUI 加载路径中移除或者用一个空的 Fragment 替代。但这种做法的风险也很大很多系统内的公版逻辑会因找不到 Keyguard 视图而触发空指针异常尤其是在“锁屏通知”和“指纹识别”这两个模块上。我做过一个“极简模式”的项目当时为了彻底不让锁屏出现踩过指纹模块的空指针坑。指纹解锁成功后会回调onBiometricAuthFailed该回调内部会尝试获取 Keyguard 视图层级如果视图被移除直接崩。所以如果你只是想让锁屏“看不见”别做“彻底移除”而是用上面的补丁方案让 Keyguard 存在但不可见。这个“存在但不可见”才是定制系统里稳定安全的状态。5.5 演示机与无人值守场景的额外建议如果是做演示机、展台这种完全无人值守的设备建议还要把“休眠时间改成从不”或者“充电时保持常亮”否则即便默认无锁屏息屏后重新亮屏的动画也会给人“被锁了一下”的错觉。这是产品体验层面的细节和源码改造无关但客户往往非常在意。在这些场景下还有一个容易被忽略的点系统 OTA 升级后SettingsProvider的种子数据可能会被重新加载一次如果新包的默认值仍然是无锁屏那没问题。但如果你用的是模块 push 方式验证升级后残留数据库可能把旧状态带过来导致升级后出现“锁屏回来了”的假象。做升级测试时务必用完整包升级不要用增量覆盖。最后再说一句实践心得改锁屏这种看似简单的功能最大的风险往往不是“不知道怎么改”而是“改了之后不知道哪里还会被它牵连”。我个人的习惯是每次着手这种涉及系统交互层的改动前先花半小时把KeyguardViewMediator、KeyguardSecurityContainer、KeyguardUpdateMonitor三个类的调用链走一遍搞清楚“哪些入口会触发锁屏”“哪些状态会导致显示/隐藏”再去动手改代码。这样下来即使后续需要适配 Android 15 甚至更高版本也能快速定位需要同步修改的节点而不是靠满屏日志去猜。如果你正在做类似定制而且版本刚好是 Android 14建议先把这篇文章第 3 章的 diff 部分放到你的代码里跑一下。跑通之后再去考虑“是否要隐藏设置项”“是否要多用户适配”这些上层问题。切记一点锁屏相关改动永远先考虑数据分区残留问题不然你会在“明明改了却没生效”这件事上浪费一整天。