Android 14系统定制：通过SettingsProvider数据库全局禁用软键盘的完整方案

上个月接了个 Android 14 的定制需求：一台带物理键盘的工业平板，客户要求“任何场景下，软键盘都不许弹出来，哪怕手点到输入框也不行”。一开始我觉得这活儿简单，不就是 hideSoftInputFromWindow 一调就完事吗？结果交付测试时被产品经理一顿喷：键盘还是弹，锁屏再解锁会飘出来，切到某些 App 直接无视代码。后面我才发现，这个需求真正要动的不是应用层那几行 Java，而是 Android 的系统设置数据库，也就是 SettingsProvider 这一整套链路。如果你也在做系统定制、ROM 适配或者设备管控，这篇东西值得你看完，少走我踩过的那些弯路。

1. 为什么“代码隐藏软键盘”在 Android 14 定制设备上不够用

1.1 三种完全不同的“隐藏”需求

开发里说的“隐藏软键盘”，其实至少分三种场景，每种的技术路线差得很远：

• 一次性隐藏：用户在某输入框触发键盘后，你点一下空白区域，让键盘缩回去。这种需求用 InputMethodManager.hideSoftInputFromWindow() 就够了，是应用开发最常见的姿势。
• 当前页面不准弹：进入某个页面后，输入框拿焦点但没有键盘弹出，比如免密登录页、扫码页。这种需要在 Window 上配置 WindowInsets 或软输入模式，或者给 EditText 关掉“焦点弹键盘”行为。
• 全局禁用软键盘：系统级需求，任何 App 在任何页面上都不许弹软键盘，或者只在连接硬件键盘时自动不弹。这种只能改系统决策源头，也就是设置数据库。

项目标题里说的“通过数据库隐藏软键盘”，指的就是第三种。它和前两种的本质区别是：前两种是“应用层请求系统隐藏”，第三种是“让系统根本不产生显示请求”。

1.2 代码层方案为什么会被系统设置反杀

很多做过 Android 开发的都知道 InputMethodManager 能隐藏键盘，但没深究过一个问题：你隐藏成功，是因为系统当前状态允许隐藏。一旦系统设置里某个开关启动了“强制显示”或“跟随硬件键盘自动显示”的策略，你应用层那一次 hide 请求可能只生效几毫秒。

具体到 Android 14，输入法框架已经非常重。键盘要不要弹，是由 InputMethodManagerService（简称 IMMS）根据窗口焦点、软输入模式、系统数据库里的输入法配置、物理键盘连接状态等多路信息综合决策的。应用层 hide 只是往这个决策系统里塞了一个“当前想隐藏”的信号。如果 IMMS 判断“按设置应该显示”，它照样弹。

比如系统里有一项配置叫 show_ime_with_hard_keyboard，它决定“连接物理键盘时是否也显示软键盘”。你把这项设为 1，再调用 hideSoftInputFromWindow，键盘是可以收回去，但用户再点一次输入框，系统会立刻重新弹出。因为设置数据库里写的就是“硬件键盘在的时候也要显示软键盘”，IMMS 每次重新评估焦点变化时都会触发 showSoftInput。

所以结论很简单：普通代码方案是“按一次暂停一次”，数据库方案才是“直接改掉裁判的判罚规则”。 做系统定制，必须走后者。

2. Android 14 的 SettingsProvider：软键盘与数据库之间到底怎么关联

2.1 三个系统设置表的分工

Android 系统设置数据库由 SettingsProvider 这个系统级 ContentProvider 统一管理，对外呈现为三张表：

• Settings.Global：全局设置，设备所有用户共享，比如屏幕超时、蓝牙开关键这种设备级开关。
• Settings.Secure：安全设置，区分用户，普通应用只读，写入需要系统权限或 WRITE_SECURE_SETTINGS。
• Settings.System：部分旧版设置的兼容区，普通应用有一些可写权限。

和输入法相关的绝大多数配置都在 Settings.Secure 里。原因也很直接：不同用户可能要用不同输入法，同一台设备的不同账号不应该互相污染输入法配置。

在 Android 14 上，这三张表的数据最终会持久化到设备上的 /data/system/users/<userId>/ 目录下，形如 settings_secure.xml、settings_global.xml、settings_system.xml。而传统意义上的 settings.db SQLite 数据库文件在某些版本、某些路径下仍然存在，但系统运行时的优先读来源是内存态和 XML 持久化层。这一点后面直接操作文件时特别重要，很多人在这上面翻车。

2.2 真正能影响输入法行为的几个关键 Key

我梳理了一下，和“隐藏软键盘”这个需求关联最强的设置项主要有这几个：

这里最关键的是第一个 show_ime_with_hard_keyboard。它对应的 Java 常量在 Settings.Secure 类里：

java复制public static final String SHOW_IME_WITH_HARD_KEYBOARD = "show_ime_with_hard_keyboard";

AOSP 默认值在不同的 ROM 里有所不同，但很多定制 ROM 默认把它改成了 0，也就是“连接实体键盘时软键盘自动隐藏”。不过如果你拿到的是 Android 14 原生设置，这项默认可能不是你想要的状态，所以一般都要主动写一遍。

2.3 设置项从数据库到输入法服务的完整链路

这部分理解了，你就能明白“改数据库为什么能生效”。

InputMethodManagerService 在系统启动时，以及每次 Settings.Secure 内容发生变化时，都会收到通知。这个通知机制用的是经典的 ContentObserver。IMMS 内部注册了一个 SettingsObserver，专门监听 Settings.Secure.CONTENT_URI，一旦发现 show_ime_with_hard_keyboard 或输入法相关项变了，就会重新计算系统当前 IME 的显示策略。

整个链路简化一下就是：

code复制设置项写入 SettingsProvider
        ↓
ContentResolver.notifyChange 通知所有观察者
        ↓
InputMethodManagerService 的 SettingsObserver 收到 onChange
        ↓
更新 mSettings 和输入法显示策略
        ↓
下一次输入框获取焦点时，按新策略决定是否弹出键盘

所以“通过数据库隐藏软键盘”的本质是：改掉输入法服务读取的那一个判断条件。 数据库只是个载体，真正干活的是 IMMS 的这套监听与决策机制。

3. 三条可落地的隐藏方案：从上层 API 到直接改配置源

这一节给三套我实际操作下来能用的方案，按使用场景从普通到系统级排序。

3.1 普通 App 方案：窗口与焦点层面拦截

先说局限性：这套方案只在你的 App 内有效，且无法对抗系统设置里强制显示 IME 的策略。但它是最常见的入门方案。

第一种，手动隐藏当前窗口的软键盘：

java复制public static void hideSoftKeyboard(Activity activity) {
    InputMethodManager imm = (InputMethodManager) activity.getSystemService(Context.INPUT_METHOD_SERVICE);
    if (imm == null) return;
    View decorView = activity.getWindow().peekDecorView();
    if (decorView != null) {
        imm.hideSoftInputFromWindow(decorView.getWindowToken(), 0);
    }
}

第二种，阻止 EditText 获焦时自动弹键盘。这是很多新手不知道的 API：

java复制editText.setShowSoftInputOnFocus(false);

这个属性在 API 21 就有了，Android 14 上依然有效。它会在焦点到达 EditText 时，不主动向系统请求显示 IME，效果就等同于“点输入框不弹键盘”。

第三种，在 AndroidManifest.xml 中给 Activity 配置全局软输入模式：

xml复制<activity
    android:name=".MainActivity"
    android:windowSoftInputMode="stateHidden|adjustResize">
</activity>

stateHidden 表示进入页面时软键盘默认隐藏，adjustResize 表示键盘弹出时调整窗口尺寸而不是直接遮挡。

这套方案的优点是通用、好写，缺点是没有状态持久化。进程被杀、Activity 重建、锁屏再解锁，设置就没了，你还是得重新调用。所以它适合普通应用开发，不适合设备级管控。

3.2 系统组件方案：通过 Settings API 写入开关

如果你是系统 App，有 WRITE_SECURE_SETTINGS 权限，或者你能用 adb 调 shell 命令，那就可以走真正的数据库路径。

直接在代码里写：

java复制Settings.Secure.putInt(
    getContentResolver(),
    Settings.Secure.SHOW_IME_WITH_HARD_KEYBOARD,
    0
);

这行代码会把系统数据库中 show_ime_with_hard_keyboard 这一项的值置为 0。只要 IMMS 收到变化通知，接下来所有输入框在连接实体键盘时都不会弹软键盘。

如果你只是调试，不需要写代码，一条 adb 命令搞定：

bash复制adb shell settings put secure show_ime_with_hard_keyboard 0

把它改回 1，就恢复默认的“物理键盘也在时显示软键盘”行为：

bash复制adb shell settings put secure show_ime_with_hard_keyboard 1

想确认当前值：

bash复制adb shell settings get secure show_ime_with_hard_keyboard

注意这里有个前提：运行 settings put secure 需要 WRITE_SECURE_SETTINGS 权限，普通第三方 App 是拿不到这个权限的。系统 App 如果等级不够，可以用 adb 授予：

bash复制adb shell pm grant 包名 android.permission.WRITE_SECURE_SETTINGS

虽然它属于 signature 级别权限，但 Android 从某版本开始允许 shell 显式授权给预置应用，实测在 Android 14 上是可行的。

3.3 ROM 修改方案：直接动持久化文件

如果你的需求是“设备出厂时就不弹软键盘”，或者在已经 root 的设备上做底层修改，那就要动到底层文件了。

先讲正规做法：修改 ROM 里的默认值文件。AOSP 源码路径一般在：

text复制frameworks/base/packages/SettingsProvider/res/values/defaults.xml

你可以在里面找到或者新增这样一行：

xml复制<setting name="show_ime_with_hard_keyboard" value="0" />

这样编译出来的系统，开机后 Settings.Secure 里这项默认就是 0，从第一秒开始就不弹软键盘。这个方案最适合 MID 设备、教育终端、收银机这类生产环境。

如果你手里是一台已经开机的 Android 14 设备，想直接改持久化文件，那么有两个注意点：

• Android 14 上，运行时真正读的是 SettingsProvider 的内存缓存，你直接改 XML 或数据库文件，重启前不会生效，甚至会被内存里的旧值覆盖回写。
• /data/system/users/0/settings_secure.xml 是当前用户设置的真实落盘位置之一。手改时要把 show_ime_with_hard_keyboard 对应的 <setting> 节点的 value 改成 0，package 属性最好保持不动，然后重启。

有些 ROM 上也能在老式数据库路径下用 sqlite3 打开 settings.db：

bash复制adb shell
su
sqlite3 /data/data/com.android.providers.settings/databases/settings.db

进到 sqlite 交互后执行：

sql复制update secure set value = '0' where name = 'show_ime_with_hard_keyboard';
select * from secure where name = 'show_ime_with_hard_keyboard';

不过我必须强调：Android 14 的 SettingsProvider 已经整体迁移到 XML 文件 + 内存态管理模式，sqlite 数据库文件并不总是最终持久化来源。 你在老设备上屡试不爽的 sqlite3 大法，在 14 上很可能改了个寂寞。我自己就因为这个被坑了大半天，改完 select 出来是 0，但系统重启后还是弹键盘。后面才发现真正生效的是 XML 文件和 settings put 命令。

所以我给你的建议很直接：能跑 settings put 的，永远优先用 settings put；只有连 shell 都不方便打开、但能 root 改文件的情况下，才去碰 XML；至于 sqlite3 那条路，新版本设备上别抱太大希望。

3.4 三条路径怎么选

4. Android 14 实测记录：改完不生效、缓存覆盖、键盘反复弹

这一节全部来自我这次项目里真实踩过的坑，一个比一个隐蔽。

4.1 现象一：settings put 返回成功但软键盘照旧

我最早用 adb shell settings put secure show_ime_with_hard_keyboard 0 设置完之后，拿着硬件键盘平板一测，点输入框键盘照样弹出来。第一反应是设置项名拼错了，可 settings get 查回来确实是 0。

后来查了 IMMS 的源码才想明白：InputMethodManagerService 对这个 key 的监听并不是“实时重算并立刻关闭当前已弹出的键盘”，它只影响下一次输入法状态切换时的决策。 也就是说，当你设置完时，如果某个输入框还处于焦点状态，IMMS 不会主动去把当前键盘按新策略关掉。你得让系统重新走一遍“输入法显示评估”流程。

解决办法实测下来有两个：

• 重启 SystemUI：adb shell pkill -f com.android.systemui，Android 14 上 SystemUI 会自动拉起，效果比较快。
• 把当前的 EditText 焦点清掉再重新获焦，比如切到桌面再切回来。

如果你在真机上测试遇到“设置完没反应”，先别急着怀疑思路，试试这一下，大概率就能看到变化。

4.2 现象二：直接修改 settings.db 后查询还是旧值

这就是我上面提到的 SQLite 大法失效问题。当时我 root 了一台 Android 14 测试机，sqlite3 打开 settings.db，把 show_ime_with_hard_keyboard 改成 0，select 确认已经改掉。然后重启，进 settings get，发现值还是 1。更诡异的是，再进 sqlite 查，数据库文件里居然变回了 1。

原因是 SettingsProvider 有一层内存态 SettingsState，它会在进程运行期间把读取到的值缓存起来。外部工具直接改磁盘文件，没有走 ContentProvider 的标准写入流程，也就没有更新内存态。重启后 SettingsProvider 从持久化文件重新加载，如果它加载的是 XML 而不是 SQLite DB，那你改的 SQLite 文件根本不在加载范围内。即便 XML 文件被改成 0，如果 SettingsProvider 在运行期间又执行了一次正常写入，它也可能把旧值回写覆盖掉。

所以结论就是：Android 14 上不要绕开 SettingsProvider 去改底层文件。 老老实实用 settings 命令、Settings.Secure.putInt 或直接改 defaults.xml 重新编译，这三条路至少是可预期的。

4.3 现象三：EditText 抢焦点导致“关了又开”

数据库开关设好了，物理键盘场景下软键盘确实不弹了。但需求里有一句话很要命：“任何场景都不许弹软键盘”。于是我发现，某些输入框在触碰时根本不走“硬件键盘显示策略”，而是走显式 show 请求，比如第三方 App 自己在 onTouchEvent 里调了 showSoftInput。

系统数据库里的 show_ime_with_hard_keyboard 只约束“系统根据硬件键盘状态自动决策”的场景，拦不住应用层显式调 showSoftInput。这时你是没法纯靠数据库解决的。只能叠加一个辅助手段，在焦点层面做拦截。

通用做法是给你的输入控件包一层，或者直接在 Dialog、Activity 的根布局上处理：

xml复制<LinearLayout
    android:focusableInTouchMode="true"
    android:focusable="true"
    android:descendantFocusability="beforeDescendants">
</LinearLayout>

配合代码里在必要时机清除焦点：

java复制rootView.requestFocus();

这样做的思路是：让根布局先抢走焦点，输入框拿不到焦点，就不会触发显式 show 请求。 数据库负责的是系统侧策略，焦点拦截负责的是应用侧请求，两边配合才能做到“任何场景都不弹”。

4.4 现象四：Android 14 IME 异步时序带来的隐藏延迟

Android 14 上输入法的显示和隐藏已经变成了一套异步状态机。早期版本你调 hideSoftInputFromWindow 后键盘可能立刻收回去，14 上这个请求要走 ImeTracker、窗口焦点校验、动画过渡等环节。如果调用时机不对，比如窗口还没完全获得焦点，或者正在切换窗口，hide 请求会被系统直接忽略或延后。

实际开发中，我建议把隐藏操作挂在 onWindowFocusChanged(true) 之后：

java复制@Override
public void onWindowFocusChanged(boolean hasFocus) {
    super.onWindowFocusChanged(hasFocus);
    if (hasFocus) {
        hideSoftKeyboard(this);
    }
}

这样能保证 IMMS 认为当前窗口是活跃的，hide 请求不会因为“目标窗口不在顶层”而被丢掉。这个小细节在 Android 14 上比在旧版本上重要得多。

5. 验证软键盘隐藏状态：用 dumpsys 和 logcat 说话

改完之后别急着肉眼判断。我见过太多人“明明弹了一下又收起，自我安慰说成功了”。验证要用系统工具看状态。

5.1 数据库状态的查询

不用打开设置界面，直接命令行确认：

bash复制adb shell settings get secure show_ime_with_hard_keyboard

如果输出 0，说明数据库里的策略已经是你想要的状态。但注意，这只是“策略值”，不保证 IMMS 已经加载它。

5.2 输入法服务实际决策的确认

关键一步是看 IMMS 当前记录的显示策略：

bash复制adb shell dumpsys input_method | grep -iE "mShowImeWithHardKeyboard|mInputShown|mImeWindowVis"

如果 mShowImeWithHardKeyboard 解析为 false，说明 IMMS 已经采用了你设置的新策略。如果这个值还是 true，那你刚才的 settings put 虽然写进数据库了，但没触发 IMMS 重新读取，回到 4.1 去重启 SystemUI 或清焦点。

5.3 窗口焦点和 IME 可见性的日志确认

再进一步，可以用日志确认整个链路是否正常：

bash复制adb logcat -s InputMethodManagerService ImeTracker

重点看有没有输出 hideSoftInput 相关的日志，特别是当设置项为 0 时，如果还看到 showSoftInput 被某个窗口请求出来，说明是应用层显式请求，这时要回到 4.3 的焦点拦截逻辑去处理。

另外可以看窗口管理侧当前是否有 IME 窗口：

bash复制adb shell dumpsys window | grep -iE "InputMethod|mImeShown"

如果确认没有 IME 窗口挂载，那才是真的“藏死”了。

这次项目做完，我最大的体会是：Android 的输入法隐藏不是一个单点问题，而是一条决策链。 数据库负责改决策条件，setShowSoftInputOnFocus(false) 负责拦应用侧请求，windowSoftInputMode 负责定窗口级策略，日志和 dumpsys 负责验证。你要是只盯着 hideSoftInputFromWindow 一个 API 使劲，Android 14 上一定会有各种姿势的“诈尸”键盘等着你。

另外再说一个后续可扩展的技巧：如果你做的是设备管控类应用，建议把“隐藏软键盘”这种策略做成一个开关，放到自己的管理后台下发，后台改的就是这个 show_ime_with_hard_keyboard 值。这样运维的时候不用抱着平板一根线一根线插了，远程一改，设备重启完就生效，比直接拿 sqlite 去戳文件省心得多。