1. 开机那行"正在启动"到底从哪冒出来的
RK3566和RK3568这两颗芯片在国产嵌入式板卡圈子里出镜率极高，四核A55的配置跑Android 11绰绰有余，做广告机、工控面板、桌面一体机的团队一抓一大把。但只要你烧过AOSP或者厂商提供的Android 11固件，开机时大概率都见过屏幕中央那行"正在启动…"的提示，有时候还配一个转圈的进度动画，停留两三秒甚至更久，然后才切到真正的Launcher。做消费类产品的话，这行字其实挺掉价的——用户看到"正在启动"会下意识觉得设备卡、系统慢，尤其是做桌面安卓电脑或者商显一体机的场景，客户第一眼看到的就是这个画面。
这行提示的学名来自一个叫FallbackHome的组件。它不是一个普通的App，而是Android系统在Direct Boot模式下临时顶班的"备胎桌面"。要彻底干掉它，得先搞清楚它为什么存在、什么时候被拉起、又是什么条件让它退出。很多人一上来就去改fallbackhome的apk或者直接删掉，结果要么编译不过，要么开机黑屏卡死，就是因为没弄明白这套机制背后的逻辑。
这篇内容面向的是正在用RK3566/RK3568做Android 11产品化落地的嵌入式工程师和系统定制开发者。我会把FallbackHome的触发链路、屏蔽它的几种可行路径、每种路径的取舍、以及实测中踩过的坑完整讲一遍。看完你应该能根据自己的产品形态，选一条最稳妥的方案落地，而不是照抄某个论坛帖子改完发现OTA升级或者恢复出厂设置时又出问题。
需要提前说明的是，下面涉及的文件路径和属性名都以AOSP Android 11为基准，RK原厂SDK在这块改动不大，但不同厂商的BSP可能有细微差异，实际操作时以你手上SDK的代码为准。
2. FallbackHome的触发链路与退出条件拆解
2.1 Direct Boot与用户解锁的时间差
Android 7.0引入Direct Boot之后，系统启动被切成了两个阶段。第一个阶段叫Direct Boot，此时设备已经开机，但用户数据还是加密状态、没被解锁，只有一部分标记了directBootAware的应用能跑。第二个阶段是用户解锁之后，也就是After Unlock，这时候完整的用户空间才可用。
问题就出在这个时间差上。系统启动到Direct Boot阶段时，真正的Launcher（比如Launcher3或者厂商定制的桌面）通常没有声明directBootAware，因为它要读取用户数据、加载用户配置，在加密状态下根本跑不起来。但系统又需要一个"Home"角色来维持界面，不然开机就是一片黑。于是AOSP准备了一个极简的Home实现——FallbackHome，它只做一件事：显示一个等待界面，等用户解锁后自己退出，把Home角色交还给真正的Launcher。
RK3566/RK3568的Android 11默认配置里，FallbackHome的界面资源就是那个"正在启动"的提示。所以本质上，你看到的不是bug，而是系统设计的一部分。
2.2 FallbackHome退出的判定逻辑
FallbackHome的代码在frameworks/base/packages/FallbackHome/目录下，核心逻辑在FallbackHome.java。它继承自Activity，在onCreate里注册了一个BroadcastReceiver，监听ACTION_USER_UNLOCKED和ACTION_PRE_BOOT_COMPLETED这两个广播。同时它还会通过UserManager查询当前用户是否已经解锁。
关键点在于它的退出条件：当检测到有真正的Home应用可用时，FallbackHome会调用finish()把自己关掉。这个"真正的Home可用"的判定，是通过PackageManager查询所有声明了android.intent.category.HOME的Activity，然后排除掉自己。如果查到了别的Home，就退出。
这里有个容易被忽略的细节：FallbackHome自己也在AndroidManifest里声明了category.HOME，所以它查询的时候必须把自己排除，否则会陷入"只有我自己，我不退出"的死循环。AOSP里是通过包名比对来排除的。
2.3 为什么有些板子停留特别久
理论上用户解锁很快，FallbackHome应该一闪而过。但实测中RK3566/RK3568上停留两三秒甚至更久很常见，原因通常有这么几个：
- 解锁本身慢：如果用了FBE（文件级加密）且密钥派生复杂，或者eMMC读写速度一般，用户解锁阶段会拖长。
- Launcher启动慢：真正的Launcher如果做了大量初始化（比如预加载一堆服务、读数据库），从被拉起 to 显示第一帧要时间，这期间FallbackHome还占着Home角色。
- FallbackHome的轮询间隔：它内部有个Handler做延迟检查，不是解锁瞬间就立刻退出，存在一个检查周期。
理解了这三点，你就明白为什么"屏蔽提示"和"加快开机"其实是两个相关但不同的问题。下面先解决屏蔽，再谈优化。
3. 三条屏蔽路径的取舍与实测对比
3.1 路径一：直接改FallbackHome的界面资源
最直观的做法是把FallbackHome显示的界面换成一张纯黑图或者透明背景，这样用户看不到"正在启动"几个字。具体操作是找到FallbackHome的布局文件，通常在frameworks/base/packages/FallbackHome/res/layout/下，把里面的TextView和ProgressBar去掉，或者把背景设成黑色。
这条路径的优点是改动小、风险低、不影响系统逻辑，FallbackHome该退出还是正常退出。缺点是治标不治本——界面还在，只是看不见了，如果某些场景下FallbackHome停留时间很长，用户会看到一段黑屏，体验上从"看到提示"变成"黑屏等待"，未必更好。
我实测下来，如果配合后面要讲的启动优化，这条路径其实是最省事的。适合那些不想动系统框架、只想快速出效果的团队。
3.2 路径二：让真正的Launcher支持Direct Boot
如果让真正的Launcher声明android:directBootAware="true"，并且在Direct Boot阶段就能启动，那么FallbackHome就没有存在的必要了，系统会直接拉起真正的Launcher，FallbackHome自然不会被显示。
但这条路径的代价很大。Launcher要支持Direct Boot，意味着它在用户解锁前就得能跑，而解锁前访问不了用户数据。你得把Launcher里所有依赖用户数据的逻辑都做延迟处理，等解锁后再加载。对于Launcher3这种复杂度，改造工作量不小，而且容易引入新的启动时序问题。
这条路径适合对开机体验要求极高、且有能力深度定制Launcher的团队。普通产品化项目不建议走。
3.3 路径三：从系统配置层面禁用FallbackHome
还有一条更彻底的路子：通过修改系统配置，让FallbackHome这个组件根本不参与Home角色的竞争。具体做法是在frameworks/base/core/res/res/values/config.xml里找到config_fallbackHomeComponent这个配置项，把它指向一个不存在的组件，或者直接清空。
不过要注意，这个配置项在不同Android版本里名字和存在性不一样。Android 11里FallbackHome的注册方式更偏向于通过AndroidManifest声明，而不是纯配置项控制。所以更可靠的做法是修改FallbackHome的AndroidManifest，把它的category.HOME声明去掉，或者把整个组件的enabled设为false。
但这里有个大坑：如果你把FallbackHome彻底禁用，而真正的Launcher又不支持Direct Boot，那么Direct Boot阶段系统会找不到任何Home应用，可能导致开机卡在黑屏或者直接进不去系统。这个坑我在早期项目里踩过，板子烧完直接卡在开机logo，串口log显示No home activity found。
所以路径三必须配合路径二一起用，或者至少保证有一个能在Direct Boot阶段顶班的Home。单独用路径三风险极高。
3.4 三条路径的对比
| 路径 | 改动量 | 风险 | 效果 | 适用场景 |
|---|---|---|---|---|
| 改界面资源 | 小 | 低 | 看不到提示，但可能有黑屏 | 快速出效果、配合启动优化 |
| Launcher支持Direct Boot | 大 | 中高 | 彻底无FallbackHome | 深度定制、高要求产品 |
| 禁用FallbackHome组件 | 中 | 高 | 彻底移除，但可能开不了机 | 需配合路径二 |
我的建议是：大多数项目走路径一，配合启动优化把FallbackHome的停留时间压到最短。这样改动可控，出问题也好回退。下面重点讲路径一的具体操作，以及怎么把停留时间压下去。
4. 动手改FallbackHome：从定位文件到编译验证
4.1 定位FallbackHome的源码与资源
在RK原厂SDK里，FallbackHome的源码路径一般是：
frameworks/base/packages/FallbackHome/进去之后你会看到这样的结构：
FallbackHome/ ├── AndroidManifest.xml ├── res/ │ ├── layout/ │ │ └── fallback_home.xml │ ├── values/ │ │ └── strings.xml │ └── drawable/ └── src/ └── com/android/internal/policy/impl/ └── FallbackHome.java布局文件fallback_home.xml就是那个"正在启动"界面的定义。打开它，你会看到类似这样的内容：
<LinearLayout ...> <TextView android:id="@+id/fallback_home_text" android:text="@string/fallback_home_text" ... /> <ProgressBar ... /> </LinearLayout>strings.xml里定义了fallback_home_text的值，中文环境下就是"正在启动…"。
4.2 改布局：把提示换成纯黑背景
最直接的做法是把fallback_home.xml整个替换成一个纯黑背景的View：
<?xml version="1.0" encoding="utf-8"?> <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:background="#FF000000" />这样FallbackHome启动时显示的就是一块纯黑，用户看不到任何文字和动画。等真正的Launcher起来后，画面直接切换过去，视觉上就是"黑一下然后进桌面"，比看到"正在启动"要自然得多。
如果你希望更平滑，可以把背景设成和Launcher启动画面一致的图片，这样切换时几乎无感。但要注意图片资源要放在FallbackHome的res目录下，且不能太大，否则会增加FallbackHome的加载时间。
4.3 改Java逻辑：缩短检查周期
光改界面还不够，如果FallbackHome本身退出慢，黑屏时间就长。前面提到它内部有个延迟检查机制，我们可以把这个周期调短。
打开FallbackHome.java，找到类似这样的逻辑：
private static final long USER_UNLOCKED_TIMEOUT = 1000;或者是一个Handler的postDelayed调用。把这个延迟值从默认的1000ms改成200ms甚至100ms，能让FallbackHome更快检测到Launcher可用并退出。
但这里要谨慎：延迟设得太短会导致频繁轮询，增加CPU占用。实测200ms是个比较平衡的值，既能明显缩短停留，又不会带来明显的性能开销。
另外，FallbackHome退出时调用的finish()之后，系统还需要一点时间做Home角色的切换。这部分时间我们控制不了，但可以通过优化Launcher的启动速度来间接缩短。
4.4 编译与验证
改完之后，FallbackHome属于framework层的一部分，需要重新编译system镜像。在RK SDK里通常是：
source build/envsetup.sh lunch rk3566_r-userdebug # 或对应的产品配置 make -j$(nproc) FallbackHome如果只改了FallbackHome，可以单独编译这个模块，然后push到板子上验证：
adb root adb remount adb push out/target/product/rk3566_r/system/framework/FallbackHome.apk /system/framework/ adb reboot注意FallbackHome在Android 11里可能被打包进framework-res.apk或者作为独立的FallbackHome.apk存在，具体看你SDK的配置。如果是前者，就得整体重编framework-res。
验证的时候重点看两点：一是开机过程中"正在启动"是否消失，二是系统能否正常进入Launcher。如果卡在黑屏进不去，串口log里搜FallbackHome和No home activity，基本能定位问题。
提示：改framework层之前一定要先备份原始文件，或者确保你的代码在git管理下。framework改错导致开不了机，恢复起来很麻烦，尤其是没有串口调试条件的时候。
5. 把开机时间一起压下去的几个配套动作
5.1 关掉不必要的开机动画
RK3566/RK3568的Android 11默认会播放开机动画，这个动画本身要占用启动时间。如果你的产品不需要动画，可以在device/rockchip/common/下找到相关配置，把bootanimation的启动关掉，或者把动画替换成一张静态图。
具体做法是修改BoardConfig.mk或者device.mk里的TARGET_BOOTANIMATION相关配置，把动画zip换成单帧图片。实测这样能省下几百毫秒到一秒不等，取决于动画的复杂度。
5.2 精简开机自启的服务
Android启动过程中会拉起大量系统服务，其中不少是产品用不到的。比如某些厂商SDK会默认带上蓝牙、NFC、打印服务等，如果你的板子根本没这些硬件，可以在frameworks/base/services/java/com/android/server/SystemServer.java里把对应的startService注释掉。
但这一步要非常小心，注释错了会导致系统起不来。建议一次只注释一个，编译验证通过后再继续。我一般会先看串口log里各个服务的启动耗时，挑那些耗时明显又用不到的动手。
5.3 优化Launcher的冷启动
真正的Launcher启动越快，FallbackHome退出后到桌面显示的时间就越短。优化Launcher冷启动的常见手段包括：
- 减少Application的onCreate里的初始化工作，能延迟的延迟。
- 把一些非必要的预加载放到后台线程。
- 检查是否有在主线程做IO操作，比如读配置文件、查数据库。
用adb shell am start -W可以测量Launcher的启动耗时，改之前改之后各测几次取平均，能直观看到效果。
5.4 用bootchart看启动瓶颈
如果想把开机优化做细，RK的Android 11支持bootchart。在device/rockchip/common/下开启bootchart配置，重新编译烧录后，系统会把启动过程的详细时间线记录到/data/bootchart/下。把这个目录pull出来，用脚本生成图表，就能看到每个阶段、每个服务花了多少时间。
我一般会重点看三个阶段：kernel启动、init阶段、zygote和system_server阶段。FallbackHome的显示时间通常落在system_server起来之后到Launcher起来之前这段，bootchart上能看得很清楚。
6. 实测中踩过的坑与排查思路
6.1 改完黑屏进不去系统
这是最常见的坑，原因基本是FallbackHome被改坏或者被禁用后，Direct Boot阶段没有Home可用。排查步骤：
- 接串口，看log里有没有
No home activity found或者FallbackHome相关的异常。 - 检查
AndroidManifest.xml里FallbackHome的category.HOME是否还在。 - 检查真正的Launcher是否声明了
directBootAware，如果没有，FallbackHome就不能禁用。
如果确认是这个问题，最快的恢复方式是把原始FallbackHome.apk push回去，或者重新烧录system镜像。
6.2 提示没了但黑屏时间变长
有朋友反馈改完布局后，黑屏时间反而比原来显示"正在启动"还长。这通常是因为FallbackHome的退出逻辑没优化，界面虽然黑了，但组件还在那儿占着Home角色不退出。
解决办法就是前面说的，把FallbackHome.java里的检查周期调短，同时优化Launcher启动。两者配合才能既看不到提示，又不会黑屏太久。
6.3 OTA升级后改动丢失
如果你是通过修改源码编译的方式做的改动，OTA升级时如果升级包是全量包，改动会保留；如果是增量包，且升级包基于原始代码，改动可能被覆盖。产品化项目里，这类framework层的改动一定要纳入版本管理，并且在OTA流程里做好校验。
6.4 恢复出厂设置后的表现
恢复出厂设置会清除用户数据，重新走一遍首次开机流程。这时候FallbackHome同样会被拉起。所以你的改动必须在首次开机场景下也验证通过，不能只测正常重启。
我一般会做这么几组测试：冷启动、热重启、恢复出厂后首次开机、OTA升级后首次开机。四组都过了，才算改动稳定。
7. 不同产品形态下的方案选择建议
做广告机或者商显一体机的团队，通常对开机画面有品牌要求，这时候可以把FallbackHome的背景换成品牌logo，既屏蔽了"正在启动"，又顺便做了品牌露出，一举两得。
做桌面安卓电脑或者工控面板的，用户对开机速度更敏感，建议走"改布局+缩短检查周期+Launcher冷启动优化"的组合拳，把整个开机到桌面的时间压到最短。
如果是做AIoT设备、开机后直接进某个专用应用的，其实可以考虑把那个专用应用声明成Home，这样FallbackHome退出后直接进你的应用，连Launcher都省了。这种场景下FallbackHome的屏蔽就更简单，改个背景就行。
不管哪种形态，核心原则是一样的：先保证系统能正常启动，再谈体验优化。任何可能导致开不了机的改动，都要有回退方案。
8. 我个人在实际项目中的几点体会
RK3566/RK3568这套平台我前后做过好几个项目，FallbackHome这个问题几乎每个项目都会遇到。最开始我也试过直接删组件，结果板子变砖，后来就学乖了，老老实实从界面和时序两个方向入手。
我的经验是，不要试图彻底消灭FallbackHome，它是Android启动流程的一部分，强行移除的收益和风险不成正比。把它变成一个用户感知不到的过渡，配合启动优化把过渡时间压到最短，这才是性价比最高的做法。
另外，改framework层的东西，一定要有串口调试条件。没有串口，改错了只能靠猜，效率极低。RK3566/RK3568的开发板一般都有调试串口，接上之后看log，很多问题几分钟就能定位。
最后分享一个小技巧：如果你不确定改动是否生效，可以在FallbackHome的onCreate和onDestroy里加log，编译后看串口输出。这样能精确知道FallbackHome是什么时候起来的、什么时候退出的，比盲猜靠谱得多。
