1. 问题本质：原生 Launcher 的 HOME 属性到底卡住了什么
先交代一下背景。我手头这个定制项目是一个基于 Android 10 的行业终端 ROM，客户要求所有设备开机直接进入自有桌面“某轻桌面”，不允许出现系统原生 Launcher 的桌面、不允许开机选择桌面的弹窗、也不允许用户在设置里把默认桌面切回去。需求听起来很简单，真正落实的时候才发现，Android 10 的 Launcher 体系比想象中要拧巴得多。
原生 Launcher（在 AOSP 里通常叫 Launcher3）在 AndroidManifest.xml 里有这么一段核心声明：
<activity android:name="com.android.launcher3.Launcher" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity>KEY 就是那个android.intent.category.HOME。它在 Android 系统里的地位非常特殊：系统所有“返回桌面”的操作，本质上都是发一个ACTION_MAIN加CATEGORY_HOME的隐式 Intent，然后由PackageManagerService去解析这个 Intent，找到唯一一个合适的处理者。这里的“合适”是按优先级和默认状态综合裁决的，如果 ROM 里同时存在两个以上声明了 HOME 属性的应用，系统会怎么处理？要么弹框让用户选，要么在ActivityManager内部维护一个默认 HOME 的偏好记录。
所以问题很直接：只要原生 Launcher 还在 ROM 里且还带着 HOME 属性，它就会一直跟你的“某轻桌面”抢这个位置。就算你把自己桌面的 HOME 优先级改得再高，系统也可能在某些场景下把 Intent 解析到原生 Launcher 上，最典型的就是开机完成阶段和用户主动按 Home 键时。
那为什么不直接把原生 Launcher 从 ROM 里删掉，一了百了？很多做定制 ROM 的同事第一反应就是删。说实话，如果你做的 ROM 是纯展示机、功能机，删除是可行的。但只要你还要依赖系统里某些默认行为，或者后续要升级、要恢复出厂、要做自动化测试，删掉原生 Launcher 往往会让系统在多个隐式调用点直接返回 null，反而更容易引发连锁崩溃。这个在后面“调用报错”部分会详细说。
所以更稳妥的做法是：不删 Launcher 的 APK，保留它的 Activity 作为普通应用存在，但把它声明 HOME 属性的能力屏蔽掉。标题里说的“屏蔽原生 launcher 的 HOME 属性”，拆开来看其实就是两类动作：
- 静态屏蔽：修改 AndroidManifest.xml 或编译期处理，让 Launcher 不再声称自己处理 HOME intent。
- 动态屏蔽：运行时通过 PackageManager 的过滤或系统默认应用策略，让系统在解析 HOME intent 时跳过原生 Launcher。
这两种路线我都实际验证过，各有取舍，下面的篇幅我会把方案、补丁、踩坑全部展开。
2. 三种屏蔽方案的利弊拆解：为什么最终选择修改 PackageParser
屏蔽 HOME 属性绝不是“把那个 category 删掉”一个动作这么简单，它牵涉到系统如何解析、如何缓存、如何兜底，以及第三方应用能否感知到变化。我先把主流的三条技术路线摆出来，再解释我为什么在主项目里选其中一条。
2.1 方案 A：直接修改 Launcher3 的 AndroidManifest.xml
这是最直观的思路：在源码里把 Launcher3 的 intent-filter 里的CATEGORY_HOME去掉，或者干脆把整个 intent-filter 注释掉。我一开始也优先试了这个方案，因为它改动面最小，只影响 Launcher3 这一个模块。
但实际编译跑起来后，我发现这个方案有一个隐蔽的坑：Launcher3 的源码里不仅有 Manifest 声明，它的 Java 代码里也有大量基于 HOME 能力的状态逻辑。比如LauncherAppState初始化时会检测自己是否被系统当作默认桌面，某些版本的 Launcher3 还会在onResume时做一次resolveActivity自查，确认自己有资格响应 HOME intent。如果你只是删掉了 Manifest 里的声明，这些地方会抛出异常，表现成开机后 Launcher 进程不断重启或者直接黑屏。
而且，直接改 Manifest 的方式在维护性上很差。以后拉取上游版本更新，或者客户要求重新开启桌面切换功能，你得把改动的 diff 重新梳理一遍。对于代码管理规范的项目来说，这不是最优解。
2.2 方案 B：系统里保留双 Launcher，用 DefaultHome 策略压制
保留两个 Launcher，通过Settings.Secure或者PackageManager的setHomeActivity把“某轻桌面”设为默认。这个方案不做任何代码修改，理论上是风险最小的。
实际操作中却被 Android 10 的安全机制卡了一道。Android 10 里设置默认桌面存在两个限制：
- 非系统签名应用调用
setHomeActivity会抛SecurityException，即使你通过 ADB 授权也不行。 - 系统在开机引导阶段如果检测到多个 HOME 候选者，会强制拉起“选择应用”界面，这个界面在无头设备上就是个死结——没有屏幕输入，无法完成选择。
我在某个演示项目里试过一次，结果就是设备开机后卡在选择桌面界面，必须插上鼠标点选才能进系统。做行业 ROM 的都知道，这类设备很多时候根本不会配鼠标，这个方案直接 pass。
2.3 方案 C：在 PackageManagerService 层屏蔽 HOME 属性
这个方案是标题里“屏蔽属性”最彻底的落地方式。Android 系统在启动阶段会解析所有 APK 的 Manifest，把 intent-filter 信息解析成结构体存在PackageParser.Activity里，然后交到PackageManagerService构建ActivityInfo。我们要做的就是在这个链路上让 Launcher3 的 HOME 属性不再生效。
实现方式有两种：
- 修改
PackageParser，在解析阶段直接把指定包名下 Lifecycle 中intent-filter里的 HOME category 扔掉。 - 修改
PackageManagerService的queryIntentActivities/resolveActivity，在查询 HOME intent 时把指定包名过滤掉。
两种我都实现过。方式一（修改PackageParser）生效最彻底，因为解析阶段就把属性抹掉了，后续所有查询、缓存、默认值计算都不会再看到 HOME 属性。方式二（过滤查询）则更动态，可以在运行时决定保留哪些包可见 HOME 属性，但会有缓存同步的问题，处理不好会出现“查询结果还有旧数据”的幽灵现象。
最终我的主项目选择了方式一：在PackageParser里做定向屏蔽。接下来我把这一方案的详细实现展开讲。
3. 核心实现：在 PackageParser 中屏蔽 HOME 属性
先说动机：我希望原生 Launcher3 的 Activity 还在，但系统完全感知不到它可以作为桌面。既然感知不到，就不会有“多个桌面应用”的冲突，也不会有“解析 HOME intent 返回多个结果”的隐患。而“某轻桌面”作为系统里唯一声明 HOME 属性的应用，自然成为系统默认选择。
3.1 找到 PackageParser 的解析入口
Android 10 的PackageParser里，处理 activity intent-filter 的核心逻辑在parseActivity和parseIntentFilter方法。APK 的 binary XML 在解析时，intent-filter里的<category android:name="android.intent.category.HOME" />会被解析为IntentFilter的一个 category 成员。
在这个环节屏蔽，最简单的方式是：
在parseIntentFilter拿到IntentFilter对象之后，判断当前解析的 Activity 是不是我们要屏蔽的目标，再判断 filter 里有没有 HOME category，有的话直接移除。
关键代码位置大概是这样的伪代码结构：
private IntentFilter parseIntentFilter(...) { IntentFilter intentFilter = new IntentFilter(); // ... 解析 action / category / data ... }更进一步，PackageParser在解析完整个<activity>节点后，会把解析结果封装成Activity对象，这个对象里有intents列表。我更推荐在这里做二次过滤，因为这里的判断上下文更完整：你能拿到包名、类名、整个 activity 的所有 filter 列表。
3.2 完整补丁逻辑
注意这段代码只是示例结构，具体到你的 AOSP 版本需要微调变量名：
// 在 parseActivity 方法的尾部，Activity 对象构建完成后 if (isTargetLauncher(owner.packageName, activityName)) { Iterator<IntentFilter> it = activity.intents.iterator(); while (it.hasNext()) { IntentFilter filter = it.next(); if (filter.hasCategory(Intent.CATEGORY_HOME) && filter.hasAction(Intent.ACTION_MAIN)) { // 移除整个 filter，或者只移除 HOME category // 建议只移除 category，保留 filter，避免其他逻辑误判 filter.removeCategory(Intent.CATEGORY_HOME); } } }这里有一个细节必须注意：不要直接把整个 intent-filter 删掉。为什么？因为 Launcher3 除了 HOME 这个入口，它还需要响应WALLPAPER相关的 intent、某些快捷方式的启动 intent，保留 filter 但移除 HOME category 可以最大程度降低对其它逻辑的破坏。
3.3 为什么只移除 CATEGORY_HOME 而不动 MAIN
在IntentFilter中，ACTION_MAIN和CATEGORY_HOME是组合起来表达“我是桌面”这个语义的。只保留ACTION_MAIN而不带CATEGORY_HOME，这个 Activity 仍然可以通过显式包名或类名启动，但不会再被系统当作桌面候选。正是我们想要的效果：Launcher3 还在，但它不再是 HOME。
反过来，如果你只移除ACTION_MAIN而保留CATEGORY_HOME，某些系统模块（比如ActivityManagerService）在判断“是否存在 HOME 应用”时仍然会找到这个 filter，逻辑会走到“有候选者”的路径，但实际启动时又解析不到具体 Activity，反而更容易崩。
3.4 补充：屏蔽后如何保证“某轻桌面”成为唯一 HOME
在PackageParser屏蔽原生 Launcher 的 HOME 属性后，系统重新扫描包信息，查询 HOME intent 就只会剩下“某轻桌面”一个结果。此时无需任何默认值设置操作，ActivityManager在开机启动 HOME 时可以直接 resolve 到它。
但要注意：如果“某轻桌面”自己的 manifest 里没有写 HOME 属性，或者写得不对（比如漏了CATEGORY_DEFAULT），系统依然找不到桌面，开机后会黑屏。排查这种问题很折腾，所以我建议在干这个活之前，先确认目标桌面包名和 manifest 是完备的。
4. 屏蔽引发的调用报错：根因与修复方案
“屏蔽”本身不难，难的是屏蔽之后系统其它模块的报错。这个部分是我在整个项目里花时间最多的地方，因为 Android 系统内部对 HOME 应用的调用远不止“开机启动桌面”一个场景。我做了一张调用点清单，然后逐一处理。
4.1 调用点拆解：谁在依赖 HOME 属性
系统里对 HOME intent 的查询和解析主要分布在以下位置：
| 系统模块 | 调用场景 | 崩溃或异常表现 |
|---|---|---|
| ActivityManagerService | 启动 HOME 任务 / 切换桌面 | NullPointerException 或 ActivityNotFound |
| ActivityTaskManager | 任务栈管理 / 桌面任务识别 | 误判任务类型，导致返回逻辑错乱 |
| SystemUI | 最近任务列表、导航栏操作 | SystemUI 崩溃或最近任务显示异常 |
| PackageManagerService | 查询默认应用 / 解析系统应用状态 | 返回 null，调用方未判空则崩溃 |
| 开机引导 SetupWizard | 判断是否进入设置流程 | 认为无桌面，卡在初始化阶段 |
这些调用点的共同特点是：它们通过PackageManager.resolveActivity()拿到一个ResolveInfo，然后直接取.activityInfo使用。原生 Launcher 在的时候，这个返回值永远不为空。屏蔽之后，如果你的代码没有判空处理，就会抛NullPointerException。
4.2 最典型的崩溃：ActivityManager 无法解析 HOME
我在第一次复现中拿到的 Log 长这样：
FATAL EXCEPTION: main java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.pm.ActivityInfo android.content.pm.ResolveInfo.getActivityInfo()' on a null object reference at com.android.server.am.ActivityManagerService.getHomeIntent()根因很清楚：resolveActivity()返回的ResolveInfo为 null，而代码直接取.activityInfo。
修复不能只是加一个判空然后 return。你要考虑这个方法的调用者是什么状态。getHomeIntent是在系统需要启动桌面时被调用的，如果你直接 return null，上层拿不到 intent，依然会崩。所以正确做法是：在系统找不到 HOME 解析结果时，提供一个兜底的 ComponentName。
我采用的修复逻辑是：先正常 resolve，如果结果是 null，则尝试显式指定“某轻桌面”的包名和 Activity 类名进行兜底。这样系统的行为是：屏蔽原生 Launcher 后，绝大多数情况下仍能解析到“某轻桌面”；万一解析失败，也能通过显式包名拉起。
4.3 次典型：SystemUI 的 Recents 识别桌面任务出错
这个坑比较隐晦。SystemUI 的最近任务界面需要区分“当前是在桌面”还是“在某个应用里”，它内部也会去 resolve HOME。屏蔽之后，SystemUI 解析 HOME 拿到的结果为空，但它内部的逻辑分支假设这个值“至少不为空”，导致比较逻辑异常。
这个问题的表现不是立即崩溃，而是点击最近任务按钮时，界面空白或者直接退出。排查了很长时间，最后发现是显式判断逻辑的问题：
ComponentName defaultHome = getDefaultHomeComponent(); if (defaultHome != null && defaultHome.equals(currentActivity)) { // 显示桌面标记 }这个代码是有判空的，但问题在于getDefaultHomeComponent()内部调用了queryIntentActivities，而我们的屏蔽逻辑改的是解析阶段，这里的查询结果在某种缓存状态下仍然可能拿到旧数据。最终的修复方案是，在SystemUI中改用显式常量包名来判断“某轻桌面”的类名，而不是动态解析 HOME。
4.4 第三方应用的兼容问题
除了系统自身，第三方应用也会查询桌面。比如一些支付类应用、安全类应用，启动时会queryIntentActivities(ACTION_MAIN + CATEGORY_HOME)，用来判断设备上是否存在可用的桌面。屏蔽原生 Launcher 后，如果“某轻桌面”没有正确声明 HOME，查询结果可能是空列表，某些应用会弹错误提示甚至直接退出。
这个问题的不是屏蔽逻辑本身，而是目标替换应用的完备性。这里我专门加了一个校验脚本，排查“某轻桌面”的 Manifest 是不是真的被系统识别为唯一的 HOME 应用。
4.5 调用报错的统一修复思路
总结上面几类问题的修复方式，我形成了一套模板：
- 全局搜索
CATEGORY_HOME相关调用点，按“系统服务”“SystemUI”“第三方应用”三类梳理。 - 对系统服务类调用，优先确保
resolveActivity之后判空兜底。 - 对 SystemUI 类调用，能改显式判断就改显式判断。
- 对第三方应用，只能靠“某轻桌面”正确声明 HOME 来规避，没办法改对方代码。
5. 实操验证：编译刷机后的行为测试与问题排查
开发完补丁只是第一步。真正让我觉得这个项目“成”了，是刷机后的一系列行为测试。我把验证过程拆成几个维度，每个维度都有对应的判定标准，方便以后你复现时对齐。
5.1 开机流程验证
验证点：
- 开机后直接进入“某轻桌面”，不出现系统默认桌面。
- 开机过程中不出现“选择桌面应用”的弹窗。
- Launcher3 进程存在但不自启，
adb shell ps里没有 Launcher3 常驻进程。
实测结果：一切正常。唯一需要注意的是首次开机的 dex 优化耗时，屏蔽 HOME 属性后系统仍然要对 Launcher3 做 dex2oat，耗时和以前一样，没有减少。该等的还得等。
5.2 Home 键与任务切换验证
验证点：
- 在任意应用中按 Home 键，稳定回到“某轻桌面”。
- 最近任务列表能正常调出，且“某轻桌面”不被误判为普通应用。
- 多任务切换不丢任务栈。
这里遇到过一个反复：SystemUI 的最近任务里，“某轻桌面”偶尔会跟普通应用混在一起，表现为从最近任务列表中点击桌面图标时，启动的是原生 Launcher3 而不是“某轻桌面”。查下来是 SystemUI 里有一套针对 HOME 应用的逻辑，通过isHomeTask判断任务归属，而我们的屏蔽导致这个判断失效。修复方式上面讲过：在 SystemUI 的RecentsTaskLoader里直接用手工维护的包名列表替代动态解析。
5.3 常见问题速查表
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| 开机黑屏，无桌面 | “某轻桌面”未正确声明 HOME，或解析返回 null | 检查目标桌面 Manifest 的 intent-filter 是否带 CATEGORY_HOME 和 DEFAULT |
| 开机弹出选择桌面界面 | 屏蔽逻辑未生效，系统中仍有多个 HOME 候选 | 确认 PackageParser 补丁是否编译进 boot image，清掉 dalvik 缓存重测 |
| SystemUI 偶发崩溃 | HOME 解析为 null，Recents 逻辑未判空 | 在 SystemUI 相关类中替换为显式包名判断 |
| 第三方应用检测不到桌面 | 系统返回的 resolveActivity 为空 | 确保“某轻桌面”的 HOME 声明完整且唯一 |
| 原生 Launcher 偶尔自启 | 有其它隐式 intent（如 WallpaperPicker）触发了它 | 逐个排查 Launcher3 的所有 intent-filter，确认没有漏网的 action |
5.4 验证中我踩过的两个特别坑
第一个坑：修改 PackageParser 后没有生效。现象是补丁编译进去了，但刷机后原生 Launcher 仍然弹出来。浪费了一整天才发现，问题出在“某轻桌面”的 APK 是后装进/system/app的，而 PackageParser 的解析结果是带 cache 的。我改了代码但没有在 device 上做pm clear或重启清除PackageManager的缓存，导致屏蔽逻辑没有吃到。解决办法是：刷完精简件后做一次adb reboot，或者直接擦 data 分区。
第二个坑：只屏蔽了 HOME category，但 Launcher3 还有一个CATEGORY_APP_BROWSER的声明，在某些场景下系统会把它当作浏览器候选者之一。虽然不至于导致崩溃，但会让 intent 解析多出一个奇怪结果。建议做屏蔽时把 Launcher3 里所有不必要的 category 都收敛一下，别问为什么，问就是实测教训。
6. 更进一步：这套方案的扩展价值与注意事项
做完整套屏蔽 + 修复之后，你会发现这套思路不只是适用于“替换原生 Launcher”这一个场景。任何涉及到“系统默认组件替换”的定制需求，都能复用这套方法论。
比如：
- 替换系统默认相机：你不能直接删原生相机，否则第三方应用用
MediaStore.ACTION_IMAGE_CAPTURE调起相机时可能崩。正确做法是保留原生相机包，但屏蔽它响应外部 intent 的属性，再把自己相机应用声明为唯一可响应者。 - 替换系统默认拨号：某些系统服务会通过隐式 intent 查找拨号应用，原声拨号被删除后，VoIP 应用可能拉起失败。
- 替换系统默认短信：涉及到
SMS_DEFAULT_APP的权限协商，直接删除原生短信应用会导致系统短信权限一直处于未授权状态。
这些场景的共同点都是“不能删，只能屏蔽”。所以这套“PackageParser 层去除能力声明 + 上游调用方兜底修复”的方法论，在系统定制领域是可复用的。
但我必须提醒几个注意点：
第一，修改PackageParser属于核心框架改动，升级和移植的成本较高。如果你只是做一次性项目，可以考虑。如果是长期维护的产品线，建议把屏蔽逻辑做成可配置的，比如通过系统 property 或全局配置开关来控制是否屏蔽、屏蔽哪个包名，这样后续换机型和升级版本时不用每次重新改代码。
第二，PackageParser的改动会影响所有应用解析路径，不只是 Launcher。所以筛选条件一定要精确，务必用包名 + 类名双重匹配，不要用模糊匹配。我在开发时用到的包名都是用Process.myUserHandle()隔离过的，避免影响其它用户空间。
第三，不要忘记 CTS/GTS 的兼容性。某些认证测试会检查“系统是否包含默认 HOME 应用”，如果你把原生 Launcher 屏蔽得太彻底，可能导致测试失败。这个根据你客户的需求取舍，如果有认证诉求，推荐保留一个最小化的系统 Launcher 作为备用 HOME，但要在设置里固定使用“某轻桌面”。
最后说一个小技巧。很多定制 ROM 项目里，团队的开发环境会频繁make clean和重编。为了确认你改的 PackageParser 确实生效，可以在PackageManagerService里加一条调试日志，在解析 HOME intent 时打印所有候选者的包名。这样每次刷机后，看一眼 log 就知道屏蔽逻辑是否工作正常，省了大量反复验证的时间。
整个项目做下来，我个人最深刻的体会是：系统定制开发的难点不在“怎么改”，而在“改了之后哪些东西会坏”。HOME 属性牵扯到 ActivityManager 的任务管理、SystemUI 的界面逻辑、第三方应用的兼容行为，任何一个环节没考虑到，都会变成线上问题。我的建议是拿到需求后先做完整的调用链梳理，再动手写代码。把需要修改的调用点列成表，逐个击破，比边改边发现问题要高效得多。
