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:directBootAwaretrue并且在Direct Boot阶段就能启动那么FallbackHome就没有存在的必要了系统会直接拉起真正的LauncherFallbackHome自然不会被显示。但这条路径的代价很大。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:idid/fallback_home_text android:textstring/fallback_home_text ... / ProgressBar ... / /LinearLayoutstrings.xml里定义了fallback_home_text的值中文环境下就是正在启动…。4.2 改布局把提示换成纯黑背景最直接的做法是把fallback_home.xml整个替换成一个纯黑背景的View?xml version1.0 encodingutf-8? FrameLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_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是什么时候起来的、什么时候退出的比盲猜靠谱得多。