安卓15 ROM定制：彻底移除设置菜单选项的完整链路指南-代码聚汇网

定制ROM这件事，做久了你会发现一个规律：真正让人头秃的往往不是加功能，而是做减法。安卓15的ROM定制里，“去掉设置里不需要的菜单选项”是被点名最多的需求之一，无论是运营商集采设备、行业定制平板，还是个人玩家刷第三方ROM后追求清爽，都会碰到。很多人以为这就是把某个Preference删掉那么简单，实际动手才知道，设置菜单在安卓系统里是个横跨多个模块的“庞然大物”，一个入口背后可能牵扯到设置主页、二级列表、全局搜索、通知栏快捷开关，甚至第三方应用的Intent跳转。这篇文章我把整个链路拆开讲清楚。

如果你正准备定制安卓15的ROM，或者手头有一个第三方ROM想精简设置界面，这篇文章适合你。我会从分类判断、方案选型、源码级操作、反编译兜底，到联动清理和踩坑复盘，完整走一遍“去掉某个设置菜单选项”的流程，包括大量可复现的命令和代码片段。

1. 定制ROM真正在做的事：设置入口的“减法”背后是系统能力边界的收窄

设置应用在安卓系统里的位置很特殊。它不像普通的第三方App，删了就没了，而是和SystemUI、SettingsProvider、系统服务紧密耦合。你看到的“设置”图标，点进去之后是一个由Activity、Fragment、Preference、SearchIndexable组成的动态界面，菜单项是否显示、点击后跳到哪里、是否能被搜索到，分别由不同模块控制。所以“去掉一个菜单选项”本质上不是删除一行布局代码，而是收窄这个系统能力对用户暴露的边界。

以我经手的项目为例，定制方要求“设置里不能出现开发者选项”，表面需求就一句话，但背后的真实动机通常分几种：

行业设备防误操作。比如教育平板、医疗终端、自助终端，普通用户一旦打开开发者选项乱调USB调试、动画缩放，设备大概率会被玩坏，客服电话会被打爆。
运营商定制需求。运营商要求隐藏与自身业务无关的菜单项，比如“SIM卡管理”“无线打印”“NFC触点支付”等，保证界面纯净。
定制ROM的“去谷歌化”或“去厂商化”。第三方ROM经常要移除系统更新入口、云服务入口、账号同步入口。
合规或安全验收。某些项目在等保或行业验收时，要求用户不可见系统级配置入口。

不同动机决定了你采用什么深度去操作。只做界面隐藏，还是连Activity、Intent、搜索索引一起封死，效果完全不同。这也是很多第一次做ROM定制的人栽跟头的地方：改完XML重启，菜单确实没了，但桌面长按图标、下拉通知栏或全局搜索里依然能跳进去，需求方一验收就翻车。

这里要先建立一个认知：安卓设置菜单的“可见性”是多层叠加的结果。某个入口被看到，至少需要同时满足这几个条件：

对应的Preference/Activity在配置文件中存在。
该入口的显示条件（系统属性、Settings数据库值、运行时判断）为真。
承载它的父级页面（Fragment或Activity）本身可用。
系统搜索索引里没有残留入口。
第三方应用没有通过显式Intent直接拉起这个Activity。

所以，正确的做法是在动手前先把目标菜单项的“存在路径”全部摸清，而不是急着改代码。我一般会先做一张信息表：菜单显示名称、对应的PreferenceKey、所属的Fragment/XML、Activity名称、是否注册了SearchIndexableProvider、是否被其他应用Intent引用。信息收集齐了，方案自然就清晰了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手前先分清：你要去掉的菜单项到底属于哪一层

“设置菜单选项”是个很宽泛的说法，代码层面的存在形式完全不同。我习惯把需要移除的菜单项分成四类，每一类的处理方式和风险都不一样。

2.1 第一类：设置主页里的一级入口

这类菜单项直接出现在设置首页的列表中，是GridView或ListView里的一个item，对应的通常是某个Preference或一个带有图标和标题的Entry。编码上对应的是顶层配置XML，比如AOSP里的res/xml/top_level_settings.xml。

这类入口的特点是最容易被看到、也最容易处理。处理方式一般是直接删除XML节点，或者给该Preference加android:visible="false"。

但要注意，一级入口往往只是一个“入口”，它指向的深层页面可能还有大量内容。比如“网络和互联网”这个一级入口，点进去是Wi-Fi、移动网络、热点等一堆东西。“开发者选项”也是一个一级入口。只删一级入口，深层Fragment仍然存在，只是没有从设置主页进入的途径。

2.2 第二类：二级页面里的具体条目

这类菜单项存在于某个Fragment的PreferenceScreen中，比如“关于手机”里的“状态信息”、“法律信息”，或者“系统”里的“语言和输入法”。它们以Preference的形式存在于XML布局文件里。

处理方式和第一类类似，但风险更高。因为二级页面里的Preference经常被代码动态引用，比如findPreference("key")之后做点击事件绑定、初始化可见性、更新摘要等。如果你直接删除XML节点，而Java代码里还保留着对该Preference的引用，运行时就会出现空指针异常，整个Fragment直接白屏甚至崩溃。

2.3 第三类：由系统属性或数据库控制的动态菜单

这类菜单项本身在代码里存在，但显不显示由SystemProperties.get()或Settings.Global/Secure/System的某个值决定。最典型的就是开发者选项：Settings.Global.DEVELOPMENT_SETTINGS_ENABLED为1才显示，而且这个值会被系统在某些条件下自动重置。还有很多运营商定制菜单，会根据SIM卡的MCC/MNC动态决定是否出现。

处理这类菜单，正确姿势不是删代码，而是控制开关源。你可以通过overlay配置、开机脚本把属性值固定，或者在代码里改默认值。如果直接删除代码，反而可能引发其他模块因为找不到配置项而异常。

2.4 第四类：跨模块复用的“共享入口”

这类最坑。某些设置项虽然在“设置”App里展示，但真正的入口不止一处。比如“已安装应用”列表，设置里有一个入口，桌面长按图标也可能出现“应用信息”的快捷方式，甚至第三方桌面直接调用ACTION_APPLICATION_DETAILS_SETTINGS。再比如“通知使用权”，设置里有，安全中心或某些管家App里也可能有跳转入口。

如果你只处理设置App内的入口，其他地方依然可以进来，需求很可能被判定为“未完全实现”。所以这类菜单项需要全局搜索所有引用它的IntentFilter，做整体收口。

我通常用一张表把四类菜单项的特征和推荐处理深度列出来，方便团队评审时对齐预期：

菜单类型	典型示例	主要代码位置	处理深度	风险等级
主页一级入口	开发者选项、系统	top_level_settings.xml	删XML节点或隐藏	低
二级页条目	关于手机里的法律信息	Fragment对应的PreferenceScreen XML	删节点+同步Java引用	中
动态控制项	运营商定制菜单	SettingsProvider/SystemProperties	改开关源或默认值	中
跨模块共享入口	应用信息、通知使用权	Manifest+外部Intent	全局搜索并封堵	高

判断完类型再动手，基本能避免八成以上的返工。

3. 四种主流的菜单移除方案与各自的适用边界

针对上面的分类，实际项目里常用的移除方案有四套。每一套都有自己的适用场景，也有明显的代价，选错方案轻则效果不完整，重则系统崩溃。我按“是否重新编译系统”和“操作深度”两条线来对比。

3.1 方案A：编译期源码修剪

这是最正统的做法，适合手里有完整AOSP或厂商源码、并且有完整编译环境的团队。直接修改源码中Settings模块的XML和Java代码，删除不想要的Preference、Activity或Service声明，然后编译出新的Settings.apk。

优点：干净彻底，代码和资源一起处理，不存在运行时残留。你可以在编译期直接把对应Activity从Manifest里摘掉，连被第三方Intent拉起的机会都没有。

缺点：对编译环境和代码理解要求高。AOSP的Settings模块代码量巨大，一个Settings.apk的源码有几十万行Java/Kotlin，要理清依赖关系需要不少时间。另外，每次同步上游代码都要处理冲突。

适用场景：长期维护的ROM项目，产品线固定，有专门的系统工程师。

3.2 方案B：overlay配置覆盖

安卓从很早的版本开始就支持RRO（Runtime Resource Overlay）和SRO（Static Resource Overlay）。你可以不修改Settings主APK，而是额外编译一个overlay APK，运行时覆盖目标资源的可见性属性、文案、甚至部分行为。

优点：和主系统解耦，升级时不容易被覆盖；代码管理清晰，一个overlay包对应一个定制需求。对没有完整源码权限、但有SDK编译能力的团队很友好。

缺点：只能覆盖资源和部分运行时行为，无法直接删除代码逻辑。比如某个Preference虽然在XML里被设为不可见，但代码里如果显式调用了setVisible(true)，运行时还是会显示。另外，SearchIndexable的索引入口属于代码逻辑，overlay管不了，得配合其他方法。

适用场景：基于厂商ROM做轻度定制，不想改动SystemUI和Settings主包的场景。

3.3 方案C：运行时动态控制

这种方式不修改任何代码文件，而是通过系统属性、数据库值或云端配置来控制菜单显示。比较典型的是开发者选项的切换开关，还有部分ROM里的“隐藏系统应用”“显示刘海屏开关”这类动态逻辑。

优点：可以在不改动系统的情况下，通过设置数据库命令即时生效，甚至可以做成远程下发控制。

缺点：需要目标菜单已经预埋了相应的控制逻辑。如果原ROM没有这个逻辑，你还是要写代码，那就不属于方案C的范畴了。

适用场景：菜单项本身已经有动态开关接口，比如开发者选项；或者你有能力修改框架层代码预埋控制点。

3.4 方案D：反编译后直接修改APK

当你手里没有源码，只拿到一个完整的ROM包或一个第三方ROM的刷机包时，最现实的方式就是反编译Settings.apk，直接改smali或XML资源，再重打包放回系统镜像。

优点：门槛低，一台电脑、一个apktool就能干活，不用搭AOSP编译环境。

缺点：兼容性风险大。安卓15的资源编译方式和早期版本已经有很大差异，apktool偶尔会反编译失败或重打包后在真机上崩溃。另外，修改后需要关闭系统的签名校验或重新签名，否则无法覆盖系统分区。

适用场景：个人玩家、小型工作室，或者只是想快速验证思路的场景。

下面把四套方案摆在一起对比：

维度	源码修剪	Overlay	动态控制	反编译修改
源码依赖	必须有	可有可无	看实现	不需要
完整性	彻底	部分	受限	较彻底
维护成本	高	低	低	中
风险	中	低	低	高
适合人群	专业团队	轻量定制	快速验证	个人玩家

实际项目中我最常用的是B和A的组合。主体功能用源码修剪保证干净，一些需要灵活开关的菜单用overlay或数据库来控制。既满足当前需求，又给后续运维留了口子。

4. 实战链路：AOSP源码方式移除“开发者选项”入口的完整操作

前面铺垫了这么多，接下来进入真正的实操。这一节我以“移除开发者选项入口”为例，完整走一遍AOSP源码方式的操作流程。选这个例子是因为它横跨了设置主页、Provider控制、搜索索引、系统属性和SystemUI，几乎覆盖了所有知识点，看完这个案例，其他菜单项基本都能举一反三。

先说明环境假设：你的AOSP源码树已经编译通过，设备是Pixel或支持解锁BL的机型，能正常刷入userdebug版本。如果这些条件不满足，请先补齐环境，这一步没有捷径。

4.1 定位代码位置：从XML开始顺藤摸瓜

拿到源码后，第一步确认Settings模块的位置。AOSP里Settings的路径是packages/apps/Settings，安卓15依然是这个路径。打开后你会看到大量按功能命名的子目录，这就是一个庞大的工程。

开发者选项在设置主页面的入口，定义在res/xml/top_level_settings.xml里。打开这个文件，搜索“development”关键词，会看到类似这样的节点：

xml复制<Preference
    android:key="development_settings"
    android:icon="@drawable/ic_settings_development"
    android:order="13"
    android:title="@string/development_settings_title"
    apps:keywords="@string/keywords_development_settings"
    apps:allowDividerAbove="true"
    apps:allowDividerBelow="true"
    apps:controller="com.android.settings.development.DevelopmentSettingsDashboardController"/>

注意最后一行——apps:controller。这是Settings模块里比较新的写法，把页面跳转逻辑抽离到Controller类中，而不是直接在Activity里处理。这是安卓15的Settings架构相比早期版本的一个明显变化，意味着某些入口的显隐判断在Controller的isAvailable()方法里。

找到这个Controller文件路径：

code复制packages/apps/Settings/src/com/android/settings/development/DevelopmentSettingsDashboardController.java

打开看核心逻辑：

java复制public class DevelopmentSettingsDashboardController extends BasePreferenceController {

    public DevelopmentSettingsDashboardController(Context context, String preferenceKey) {
        super(context, preferenceKey);
    }

    @Override
    public int getAvailabilityStatus() {
        return Settings.Global.getInt(mContext.getContentResolver(),
                Settings.Global.DEVELOPMENT_SETTINGS_ENABLED, 0) != 0
                ? AVAILABLE : CONDITIONALLY_UNAVAILABLE;
    }
}

这段代码说明开发者选项是否在设置主页显示，最终由Settings.Global.DEVELOPMENT_SETTINGS_ENABLED这个数据库值决定。默认情况下，初次开机该值为0，所以普通用户看不到开发者选项。只有进入“关于手机”连续点击版本号7次才会触发系统把该值改为1，然后Controller返回AVAILABLE，菜单项出现。

这个机制对我们做定制非常重要：如果只是想隐藏开发者选项，理论上只要保证这个数据库值永远为0即可。但需求往往是“开发人员自己也看不到入口”，那就不能只依赖系统默认逻辑，需要从多个层面下手。

4.2 修改XML入口：两级隐藏避免界面残留

最直接的方式是修改top_level_settings.xml。有两种改法，我建议优先使用第二种。

第一种，直接删除整个Preference节点：

xml复制<!-- Preference development_settings 已移除 -->

删除后重新编译，设置主页面上就不会再有开发者选项的item。这个方式简单粗暴，但如果后续想恢复，只能改源码重新编译，不够灵活。

第二种，保留节点，但强制不可见：

xml复制<Preference
    android:key="development_settings"
    android:icon="@drawable/ic_settings_development"
    android:order="13"
    android:title="@string/development_settings_title"
    apps:keywords="@string/keywords_development_settings"
    apps:allowDividerAbove="true"
    apps:allowDividerBelow="true"
    android:visible="false"
    apps:controller="com.android.settings.development.DevelopmentSettingsDashboardController"/>

注意我加了android:visible="false"。这种做法比删除更安全，因为如果代码里有其他地方还在findPreference("development_settings")，至少不会因为节点不存在而NPE。你还可以把Preference先隐藏，运行时按需再显式设置为可见，可扩展性更好。

但只改主页XML并不够。设置里还有个入口可能被忽略：页面顶部的搜索框。用户输入“开发者选项”几个字，全局搜索依然能搜到，点击结果也可以直接跳转到该页面，因为搜索索引机制不依赖top_level_settings.xml里的可见性。

4.3 处理SearchIndexableProvider：让搜索彻底找不到

Settings模块的搜索索引由SearchIndexableProvider机制实现。简单来说，所有可以被搜索到的设置项，都会有一个对应的BaseSearchIndexProvider类，提供索引数据给系统搜索框架。开发者选项的搜索索引定义在DevelopmentSettings相关的类里。

如果你只是隐藏了主页入口而没有处理搜索索引，用户依然能在设置的搜索框里搜到这个页面。做定制时这是最常见的遗漏点之一。

处理方式有两条路：

一条是删除或注释掉对应的IndexableProvider注册。然后到res/xml/development_settings.xml里搜索android:searchable="true"或者搜索SEARCH_INDEX_DATA_PROVIDER相关的代码。

另一条是在DevelopmentSettings类中把索引数据生成逻辑做条件过滤。以Indexable类为例：

java复制public static final SearchIndexProvider SEARCH_INDEX_DATA_PROVIDER =
        new BaseSearchIndexProvider() {
            @Override
            public List<SearchIndexableRaw> getRawDataToIndex(Context context, boolean enabled) {
                final List<SearchIndexableRaw> result = new ArrayList<>();
                if (!isDevelopmentSettingsEnabled(context)) {
                    return result;
                }
                // 原有逻辑...
                return result;
            }
        };

这样改完之后，系统在执行索引重建时，如果开发者选项处于关闭状态，就不会把相关数据写入搜索索引，搜索自然找不到。

4.4 修改Manifest：封堵Intent跳转的外部入口

设置主页入口和搜索入口都处理完后，还有一个重大问题：第三方应用或系统其他模块可以通过Intent显式拉起开发者选项页面。比如有些辅助类App会在引导流程中直接跳转到开发者选项，或者快速的adb shell am start指令也可以直达页面。

要彻底封堵，需要把DevelopmentSettingsDashboardActivity从AndroidManifest里处理一下。先在packages/apps/Settings/AndroidManifest.xml中找到这段：

xml复制<activity android:name=".development.DevelopmentSettingsDashboardActivity"
    android:exported="true"
    android:label="@string/development_settings_title" >
    <intent-filter android:matchDefaultLaunchers="false">
        <action android:name="com.android.settings.DEVELOPMENT_SETTINGS" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="com.android.settings.SHORTCUT" />
    </intent-filter>
</activity>

这里有两种处理思路：

第一种，把android:exported改为false。这样连显式Intent都无法从外部拉起。

第二种，删掉intent-filter里的action和category，只保留Activity定义，让它不对外暴露任何入口。

我建议优先把exported改成false。因为Settings内部模块之间有些跳转可能还是需要直接调用这个Activity，完全删掉filter会导致一些深层页面跳转异常。改成false后，外部App和adb shell am start都会被系统拦截，而系统内部以Context.startActivity方式调用时不受影响。

4.5 编译验证：完整命令和检查点

改完这几处之后，重新编译Settings模块。AOSP编译Settings有两种层级：全量编译和单模块编译。只改了Settings相关代码时，可以单模块编译，速度会快很多。

bash复制source build/envsetup.sh
lunch aosp_<device>-userdebug
mmm packages/apps/Settings

或者用新版AOSP的构建命令：

bash复制source build/envsetup.sh
lunch <target>
m Settings SettingsProvider

编译产物路径一般是out/target/product/<device>/system/apex/com.android.settings/或者out/target/product/<device>/system_ext/priv-app/Settings/，具体取决于APEX配置。安卓15里Settings可能被放进APEX容器中，你需要检查out/target/product/<device>/system/下的目录结构。

拿到新的Settings相关产物后，用adb推送到设备：

bash复制adb root
adb remount
adb push out/target/product/<device>/system_ext/priv-app/Settings/Settings.apk /system_ext/priv-app/Settings/
adb reboot

如果Settings在APEX里，操作会复杂一些：

bash复制adb push out/target/product/<device>/system/apex/com.android.settings.apex /system/apex/
adb reboot

重启后进入设置页面验证：

设置主页已经没有开发者选项。
设置顶部搜索“开发者”没有任何结果。
尝试用adb shell am start -n com.android.settings/.development.DevelopmentSettingsDashboardActivity，系统提示“Permission Denied”或直接无响应。

到这一步，开发者选项在界面上已经被“封死”了。

5. 没有源码怎么办：用APKTool反编译Settings实现同类需求

很多情况下你拿不到AOSP源码，手里只有一个完整的ROM包，或是一个已经刷好的设备里提取出的Settings APK。这种场景我遇到过不少次，尤其是第三方ROM的定制优化。操作方式和源码路径类似，但全程在反编译后的产物上操作，细节上有些差异。

先说工具链。以下工具在Windows和Linux上都有对应版本，我用的是Linux环境：

apktool 2.9.x以上，要对安卓15的资源格式支持良好
JDK 17
adb
一个支持刷机的设备或用具

完整流程如下。

5.1 提取Settings APK并反编译

设备已root的情况下，直接从/system_ext/priv-app/Settings/或/system/priv-app/Settings/下把APK拉出来。具体路径因ROM而异，先找找再拉取：

bash复制adb root
adb remount
adb shell ls /system_ext/priv-app/Settings/
adb pull /system_ext/priv-app/Settings/Settings.apk ./

APK拿到后反编译：

bash复制apktool d Settings.apk -o settings_decode

如果反编译报错，大概率是框架资源没有安装。先安装系统框架：

bash复制apktool if framework-res.apk

framework-res.apk一般位于/system/framework/framework-res.apk，同样用adb pull拉下来。

5.2 修改XML和smali的差异点

反编译成功后，目录结构是：

code复制settings_decode/
├── AndroidManifest.xml
├── res/
│   └── xml/
│       └── top_level_settings.xml
└── smali/
    └── com/
        └── android/
            └── settings/
                └── development/
                    └── DevelopmentSettingsDashboardController.smali

对于XML部分，操作和源码修改类似，直接编辑res/xml/top_level_settings.xml，把目标Preference节点删除或加上android:visible="false"。

但有个区别：反编译出的AndroidManifest.xml里，Activity的android:exported属性值通常已经被apktool以字面量形式展示，可以直接修改。找到对应的Activity节点，把android:exported改成"false"即可。

smali层面的修改比较繁琐。如果只是隐藏菜单，你不一定需要改smali——XML隐藏已经能达到界面效果。但前文提到的Controller isAvailable()返回逻辑，如果你希望默认值完全不可用，即使系统把DEVELOPMENT_SETTINGS_ENABLED置为1也强制不显示，那就需要改smali。

在DevelopmentSettingsDashboardController.smali中找到getAvailabilityStatus方法的实现，把第一个if-nez v0, :cond_xxx改成无条件走CONDITIONALLY_UNAVAILABLE分支，即直接返回不可用状态。这类修改需要对smali语法有基本理解，否则容易改出问题，建议先在模拟器上验证。

5.3 重打包和签名

反编译修改完成后重打包：

bash复制apktool b settings_decode -o Settings_new.apk

重打包出来的APK签名是debug签名的“testkey”，无法直接替代系统里的原始APK，因为系统分区有签名校验。你需要做两步处理：

第一步，将APK签名改为系统签名。如果你有原本系统的platform keystore，用apksigner重新签名：

bash复制apksigner sign --ks platform.keystore --ks-key-alias platform --ks-pass pass:android --key-pass pass:android Settings_new.apk

没有系统签名的时候，只能关闭系统的签名校验。对于解锁BL的设备，可以在bootloader层面禁用AVB（Android Verified Boot）：

bash复制adb reboot bootloader
fastboot flashing unlock
fastboot disable-verity
fastboot reboot

这只是开发机的做法。产品化ROM一定要有正式签名流程，直接用testkey签名打包会导致设备无法启动或应用不可用。

第二步，把重签名后的APK推回系统分区：

bash复制adb root
adb remount
adb push Settings_new.apk /system_ext/priv-app/Settings/Settings.apk
adb reboot

对于首次定制ROM的尝试，我建议先在模拟器或备用机上验证一轮再上真机，避免因为资源编译问题导致设置应用直接崩溃，毕竟那是所有设置的入口。

6. 隐藏到极致：搜索、SystemUI快捷开关与Activity入口联动清理

很多做ROM定制的人都会遇到同一个问题：设置里的菜单项明明已经删了，但用户还是能通过其他入口找到这个功能。这种现象不是代码没删干净，而是你只处理了“设置”这一个入口，没有处理系统里其他对同一功能开放的入口。尤其是以下几处，很容易被遗漏。

6.1 系统搜索索引的残留

这个在前面已经提过。Settings模块的搜索索引比较“顽固”，它有独立的索引数据源。有些ROM里，即使改了XML隐藏Preference，如果不清理索引Provider，用户用全局搜索依然能搜到。清理时要同时注意两点：

一是SearchIndexablesProvider注册的数据源。找到目标Preference对应的Indexable类，注释或修改它。

二是系统搜索索引可能有缓存。第一次修改后，需要到“设置-存储-清除数据”里把“设置”和“系统搜索”两个应用的数据清掉，或者用adb命令触发索引重建：

bash复制adb shell settings put global search_index_build_version 0

也可以直接删除索引相关数据库再重启，不过一般清应用数据就够了。

6.2 SystemUI快捷开关

很多用户习惯在下拉通知栏直接操作某些开关。如果你要隐藏的是“开发者选项”“NFC”“热点”这类功能，SystemUI的快捷设置面板（Quick Settings）里可能还保留有对应的Tile。设置入口被移除后，用户依然习惯性下拉控制栏去点那个图标，点击后会弹错或进到设置空白页，体验非常糟糕。

处理方式是修改SystemUI里的对应Tile。以NFC为例，你需要在packages/apps/SystemUI/src/com/android/systemui/qs/tiles/NfcTile.java中找到isAvailable()方法，改成返回false：

java复制@Override
public boolean isAvailable() {
    return false;
}

或者更彻底一些，从res/xml/quick_settings_tiles_default.xml、quick_settings_tiles_stock.xml里删除对应的Tile标签。

安卓15里SystemUI的修改也涉及资源重编，如果你是在源码环境下操作，直接改文件；如果走反编译路线，找到SystemUI.apk里的res/xml/quick_settings_tiles_stock.xml同样可以改。

6.3 桌面AppInfo入口和长按快捷方式

有些设置入口会被桌面借道。比如长按“设置”App图标，弹出的快捷方式列表里可能包含“开发者选项”“应用信息”等直达入口。这些快捷方式在Settings的Manifest里通过<shortcut>标签定义，也有的是动态生成的。

处理方式是审查packages/apps/Settings/res/xml/目录下的shortcut XML文件，删除或注释掉对应的shortcut条目。因为这套机制在企业定制里应用很多，一旦不清理，应用商店的某些桌面App依然可以拉起对应设置页。

6.4 三方应用Intent跳转

最隐蔽的入口是第三方应用的Intent跳转。某些系统应用或预装应用会直接通过startActivity(new Intent("com.android.settings.DEVELOPMENT_SETTINGS"))拉起设置页面。你在Manifest里把exported改成false之后，这类跳转会直接失败，对用户表现为“应用打不开某个页面”。如果需求方只能接受“入口隐藏”，不能接受“跳转失败”，那需要保持exported=true，同时在该Activity的onCreate里做权限判断，只允许指定应用跳转。

我没必要在这里写复杂的权限校验代码，但核心思路是：在Activity的onCreate里检查getCallingPackage()，如果不是白名单内的包名，直接finish()。这种方式兼顾了隐藏和兼容。

7. 踩坑实录：删菜单导致崩溃的典型场景与修复思路

做ROM定制这几年，我在“删除设置菜单项”上踩过的坑，比加功能的坑多得多。很多问题并不是出现在修改的那一刻，而是后续使用中才暴露。这里挑几个典型场景，给你打个预防针。

7.1 只删XML不删代码引用，空指针崩溃

最早我犯过的错误就是直接删掉一个Preference节点，因为觉得这个菜单没用了。结果发现运行到某个Fragment时，代码里有一个findPreference("some_key")，节点没了返回null，下一行就调用了setTitle()，直接NPE。整个设置页面闪退。

修复思路：删除XML节点前，先全局搜索这个PreferenceKey在Java代码里的所有引用。用grep确认：

bash复制grep -r "some_key" packages/apps/Settings/src/

如果引用比较多，建议不要删节点，用android:visible="false"隐藏。先保住稳定性，再考虑彻底清理代码。

7.2 删除有依赖关系的菜单导致联动页面异常

有些菜单项之间存在隐式依赖。比如你移除了“安全性与隐私”里的“屏幕锁定”，但锁屏设置里还引用着“安全性与隐私”的某些状态字段。删除后，其他页面可能拿不到正确状态，出现显示异常或点击无效。

我遇到过最典型的案例是：删除了“SIM卡管理”菜单，之后拨号盘和移动网络设置全部崩溃。原因就是Phone相关服务在初始化时尝试读取SIM卡设置界面的一些数据库字段，字段不存在或状态不一致就抛异常。

修复思路：遇到这类问题，不要硬删，要把“菜单入口隐藏”和“核心数据保留”做拆分。界面可以隐藏，底层数据和服务不要动。像SIM卡管理这种和电话系统强耦合的入口，隐藏XML就够，千万别去删Provider或系统服务里的关联逻辑。

7.3 搜索索引未清理，点击结果白屏

菜单隐藏后，系统搜索索引没有同步清理，用户搜索到了但点击后什么也不显示，或者直接跳到一个空白Fragment。这比搜不到更恶心，因为用户不知道是系统异常还是菜单确实被移除了。

修复思路：前面说过，修改时要同步处理SearchIndexablesProvider。还有一招是在代码里对已经删掉的Preference做过滤——把getRawDataToIndex返回的列表里对应key全部过滤掉。这样即使系统索引没有重建，也不会搜出已删菜单。

7.4 系统升级把定制覆盖掉

定制完ROM，设备后续如果执行了OTA升级或增量包，很可能把你改过的Settings、SystemUI覆盖回官方版本。这个问题在个人定制ROM里很常见，有些玩家刷了第三方ROM，重置或升级后定制内容失效。

修复思路：如果你是做产品化交付，需要使用update_script确保每次OTA升级后重新应用定制修改；或者在系统分区里增加一个overlay包，用overlay的方式承载全部定制内容，这样升级时只要overlay包还在，效果就能保留。

7.5 删除设置项导致“设置”应用启动变慢

这个不算是错误，但值得提一下。某些菜单项在后头挂了复杂的初始化逻辑，比如网络、账号、备份这类菜单，它们的加载会触发一堆系统服务查询。删除之后确实会让设置页面加载更快，但要注意，如果删的菜单是某些后台服务仍在依赖的“状态观察者”，系统服务还会不断查询，反而不降反升。删除前先用dumpsys activity和dumpsys settings观察一下相关服务是否被设置项持有引用。

8. 最终验证清单与交付前检查

改完代码、编译完成、刷机成功，并不代表这个需求就算做完了。交付之前，我会按下面的清单逐项检查，确保没有任何遗漏。这份清单也适合你给需求方做验收演示时逐条过。

检查项	预期结果	验证方法
设置主页一级入口	目标菜单不出现	打开设置逐页查看
二级页面内条目	目标条目不出现	进入相关父级页面下拉检查
全局搜索	搜索关键词无结果	设置顶部搜索框输入关键词
SystemUI快捷开关	对应Tile不出现	下拉通知栏查看
长按快捷方式	无对应快捷入口	桌面长按设置图标查看
三方Intent跳转	拉起失败或被拦截	使用`adb shell am start`测试
相关功能不崩溃	依赖该菜单的功能可用	逐一操作关联功能
开机启动正常	无ANR、无鉴权失败	刷机后连续重启三次检查
搜索索引重建后	仍不出现残留	清数据后重新构建索引再查

除了界面层面的验证，我还会用Monkey做一轮压力测试，确保设置App在随机操作下不崩溃：

bash复制adb shell monkey -p com.android.settings 10000

如果Monkey跑完没有崩溃、没有ANR，基本可以认为本次定制在稳定性上没有大问题。然后根据需要回归验证其他模块——电话、短信、网络、蓝牙——确保删除的菜单项没有破坏系统核心功能。

做完这些检查再交付，心里就有底了。定制ROM这件事，最怕的不是不会做，而是做了一部分以为做完了。设置菜单的“去除”动作涉及的是一个生态级的入口管理系统，不是改一个文件那么简单。你把所有包都看住，才算真正把这个菜单项“去掉”了。

安卓15 ROM定制：彻底移除设置菜单选项的完整链路指南