企业官网建设流程全解析

定制 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这个布尔值，用 RRO（Runtime 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 界面，尤其是从“正在充电”或“AOD（Always 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并直接dismiss：

if (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 GB（AOSP 源码加输出物很容易吃掉 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两个模块。如果你只想快速验证，不需要整个镜像都重编，可以选择性编译模块然后单独push：

source 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-verity（adb 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 部分放到你的代码里跑一下。跑通之后，再去考虑“是否要隐藏设置项”“是否要多用户适配”这些上层问题。切记一点：锁屏相关改动，永远先考虑数据分区残留问题，不然你会在“明明改了却没生效”这件事上浪费一整天。