企业官网建设流程全解析

做Android系统定制的人应该都体验过这种时刻：版本发到测试手里，功能逻辑全没问题，结果回归的时候从一个不起眼的下拉操作揪出一个白屏bug。我这次遇到的就是Android 10.0 SystemUI下拉状态栏长按蓝牙和互联网图标直接白屏的问题。长按蓝牙图标，整个屏幕从顶部闪白，SystemUI界面卡住不动，两三秒后才自己恢复；长按互联网图标表现一模一样，更烦人的是白屏期间快捷开关全部点不了。

第一反应是SystemUI崩了，可logcat里干干净净，没有FATAL EXCEPTION，没有crash日志。这反而说明问题不是系统UI进程崩溃重启，而是某种跳转链路断开后残留了一个空白窗口。这篇文章就把我从现象复现、日志定位、根因确认到代码修复的过程完整捋一遍，给在AOSP定制里遇到同类问题的人一个可以直接抄作业的排查思路。

1. 长按白屏不是个例：先把这个bug的场景和影响面说清楚

1.1 我遇到的现场复盘

Android 10.0的快捷设置面板和之前版本有一个明显差别：Wi-Fi和移动数据被合并成了一个按钮，系统里叫Internet，中文翻译过来就是"互联网"这一块。下拉状态栏的时候，你可以直接看到这个长条形的模块，点一下会弹出一个聚合面板，里面有Wi-Fi开关、移动数据开关、飞行模式入口。长按这个模块，正常情况下应该跳转到系统的数据使用设置页或者Wi-Fi设置页。

蓝牙图标在快捷设置面板里也是独立存在的。点一下只是切换开关，长按则应该进入蓝牙设置页面。

我当时的复现操作很简单：

1. 状态栏下拉一次，再下拉一次，展开完整的快捷设置区域。
2. 用拇指长按蓝牙图标，大约过了800毫秒，屏幕开始白掉。
3. 白屏不是整块突然变白，而是从顶部状态栏区域往下蔓延，最后整个SystemUI区域变成纯白。
4. 大约2到3秒后，屏幕自动恢复，又能看到下拉面板了，但快捷开关的展开动画会有明显卡顿。
5. 对互联网模块做同样操作，现象一模一样。

比较关键的是，这个过程里SystemUI进程没有崩溃。如果崩溃重绘，桌面壁纸和icons会闪一下，但实际没有。那说明是某个Activity在启动过程中卡住或者失败了，把窗口状态搞坏了。

1.2 这个问题不是所有设备都出现

我一开始以为是测试机偶发问题，但测了另一台手机，同样复现。对比了两台机器的共同点后，方向就清楚了：这两台都跑了经过深度裁剪的AOSP定制系统，Settings应用被大量替换和瘦身，很多原生页面被移除或者改了名字。

反过来，在原生Android 10.0的SystemUI里，长按蓝牙和互联网Tile的链路是完整的。Settings里该有的Action都注册着，对应的Activity也都存在，所以不会出问题。但只要定制过Settings，比如精简了蓝牙设置模块、改了数据流量页面的入口、或者把部分设置页面移到了另一个APK里，那SystemUI里写死的那套隐式Intent就可能找不到目标，白屏随之而来。

这也是为什么这类问题在ROM开发圈、系统集成项目里非常典型：SystemUI这个模块本身没有变，但依赖的下游变了，上游没感知。

2. 从QSTile长按到设置页：白屏之前到底发生了什么

2.1 Android 10的Tile长按逻辑

SystemUI里的快捷开关，在AOSP中称之为QSTile（Quick Settings Tile）。蓝牙对应的是BluetoothTile，互联网对应的是InternetTile。这两个类位于frameworks/base/packages/SystemUI/src/com/android/systemui/qs/tiles/目录下。

每个QSTile的核心逻辑都差不多，平时我们执行点击会走handleClick()，长按走的是getLongClickIntent()或者是handleLongClick()。Android 10里，很多Tile实现的长按事件逻辑是通过返回一个Intent，然后交给SystemUI统一的Host去启动。这个过程和普通App里startActivity()完全一样，只是调用方是系统进程，不需要Activity上下文。

以蓝牙Tile为例，源码里的长按Intent大致是这样产生的：

@Override protected Intent getLongClickIntent() { return new Intent(Settings.ACTION_BLUETOOTH_SETTINGS); }

如果定制ROM没有对Settings做改动，Settings.ACTION_BLUETOOTH_SETTINGS会在Settings的AndroidManifest.xml里匹配到对应的Activity。但一旦Settings被精简，这个Action缺少对应的Activity节点，resolveActivity()就会返回null。

注意，ActivityManager在启动一个无法解析的隐式Intent时，如果调用方没有做防护，通常会抛ActivityNotFoundException。但对于系统进程发起的启动请求，某些定制ROM的改动或者异常拦截策略会把异常吞掉，表现就是启动流程走到了半路，Activity没起来，窗口系统又已经把SystemUI的窗口做了切换或覆盖，于是留下一个白屏窗口。

2.2 为什么是白屏而不是闪退

普通App里startActivity一个不存在的Activity，基本会是闪退加黑屏，因为App进程自己崩了。但SystemUI的长按跳转用的是系统级启动，而且Settings还在它自己的进程里。问题微妙的地方在于：如果目标Activity的类找不到，Settings进程并不会整个崩溃，只是ActivityManager标记这个启动失败。而窗口管理器可能已经准备要切换窗口，此时SystemUI原本的显示内容被撤下，新Activity又没能绘制任何内容，白屏便出现了。

另一个常见原因是Settings的Application启动太慢，或者Settings进程被系统杀死后冷启动，需要重建进程。如果这个过程中有某个ContentProvider超时，Settings进程迟迟不能完成初始化，就会有一种"看起来白屏了好一会儿才恢复"的体验。

再深挖一层，Android 10的SystemUI本身使用了大量系统窗口类型，比如TYPE_STATUS_BAR、TYPE_NAVIGATION_BAR，而屏幕上的Quick Settings区域实际是由NotificationShadeWindowView承载的。SystemUI在启动一个Activity时，窗口状态发生变化，如果这个变化没有被正确处理，就会出现窗口内容丢帧、白块覆盖、闪烁等现象。定制ROM里如果改了窗口动画缩放比例或者过渡动画，这种现象会更明显。

所以，要修这个白屏，不光是改个Intent指向就完了，还得想清楚这条跳转链路里每一步可能出的岔子。这也是我习惯把日志和运行状态都确认清楚再动手的原因。

3. 日志和命令双管齐下：一步步把问题圈到Intent头上

3.1 最直接的三条验证命令

排查这种问题，我不建议上来就翻几百兆的logcat。先用最直接的方式验证SystemUI长按的最终目标是哪个Intent、这个Intent能不能在Settings里被解析。

第一步，确认长按蓝牙到底发的是什么Intent。Android系统给了我们一个上帝视角：adb shell dumpsys activity activities | grep -i intent，但最好是先看SystemUI自己的log标签。有的定制版本在SystemUI里留下过Intent相关打印，如果没有，就只好从代码层面确认。

第二步，手动用am命令去启动长按应该启动的那个目标。比如蓝牙设置页：

adb shell am start -a android.settings.BLUETOOTH_SETTINGS

如果在终端里能正常打开蓝牙设置，说明Settings注册了对应的Action，那么问题在SystemUI侧的概率就小一些。如果am命令报了Error type 3或者Activity class does not exist，问题就非常明确了，Intent根本解析不到目标Activity。

同理，互联网入口，Android 10常见的长按目标是数据使用设置页：

adb shell am start -a android.settings.DATA_USAGE_SETTINGS

第三步，如果am命令能打开，但长按还是白屏，就还需要看当前的焦点窗口和Activity栈，确定跳转后到底停在了哪里：

adb shell dumpsys window | grep -E "mCurrentFocus|mFocusedApp" adb shell dumpsys activity activities | grep -E "ResumedActivity|topResumedActivity"

在我排查的那台机器上，am start直接报了Activity不存在。这就等于实锤了一份证据链：SystemUI发出的Intent在Settings里找不到接收者，白屏就是因为这个断裂。

3.2 从logcat里再抠一层证据

虽然am start已经定位到了问题，但我还是习惯再抓一次系统日志做交叉验证，特别是要看ActivityTaskManager有没有打印启动失败的警告。复现一次白屏，抓日志的方式如下：

adb logcat -c adb logcat -v time > bug.log # 在手机上操作长按蓝牙，复现白屏 # 等白屏恢复后，Ctrl+C中断抓取

然后过滤关键信息。重点关注这几个模式：

grep -iE "ActivityNotFound|Unable to resolve activity|resolveActivity|SystemUI|Settings" bug.log

正常情况下会在这份log里看到类似下面的报错：

ActivityTaskManager: Unable to resolve activity Intent { act=android.settings.BLUETOOTH_SETTINGS } for startup: Not found ActivityTaskManager: START u0 { act=android.settings.BLUETOOTH_SETTINGS } from uid 1000 failed

这就把问题锁定得死死的。

还有一个隐藏的坑值得注意：有些定制ROM会把Settings的Activity导出属性改成false。这种情况下即使Intent能解析到Activity，SystemUI以普通权限去启动也会被拒绝，log里会报SecurityException: Permission Denial: starting Intent ... not exported from uid。这是和"目标Activity不存在"表现类似但根因完全不同的情况，一定要区分开。

下面这张表是我排查这类问题时常用的日志关键字对照，可以直接存下来当参考。

3.3 还原完整排查链路

我这次的实际排查顺序是：

1. 长按蓝牙，确认白屏必现。
2. adb logcat -c后复现，抓日志，看到Unable to resolve activity。
3. 执行adb shell am start -a android.settings.BLUETOOTH_SETTINGS，终端报Activity not found。
4. 打开Settings安装包里的AndroidManifest.xml，搜BLUETOOTH_SETTINGS，确实找不到对应节点。原来这个ROM的定制过程把蓝牙设置入口整体迁移到了一个独立App里，Settings里只留了一个跳转出口，但出口指向的类名已经被改了。
5. 去SystemUI里找到BluetoothTile的长按Intent，改成指向实际存在的Activity。

链路非常清晰，没有绕弯。这套顺序也可以直接用在其他同样的"长按快捷开关白屏"问题上，把SystemUI的Intent、Settings的注册、ActivityManager日志三个点核对完，85%的情况都能定位。

4. 修蓝牙和修互联网入口：两个看似相同、细节不同的处理

4.1 蓝牙入口：把隐式Intent改成显式Intent

既然问题出在隐式Intent找不到目标，最简单的修复方式就是在SystemUI里把长按蓝牙的Intent改成显式的，直接指定ComponentName。

先找到BluetoothTile.java，看它的getLongClickIntent()，原始代码一般长这样：

@Override protected Intent getLongClickIntent() { return new Intent(Settings.ACTION_BLUETOOTH_SETTINGS); }

我改成显式Intent指向Settings里实际存在的蓝牙设置页面。在AOSP Settings中，这个页面通常是com.android.settings.Settings$BluetoothSettingsActivity，如果是那种把蓝牙设置迁到独立App的ROM，则需要改成独立App里的Activity。修改后的代码类似这样：

@Override protected Intent getLongClickIntent() { Intent intent = new Intent(Settings.ACTION_BLUETOOTH_SETTINGS); ComponentName component = new ComponentName( "com.android.settings", "com.android.settings.Settings$BluetoothSettingsActivity"); intent.setComponent(component); return intent; }

如果目标Activity不是public或未导出，一次显式启动可能会遇到SecurityException。Android系统签名进程对Settings里的Activity通常有特权，但如果碰到严格限制还是被拒绝，就要用另一个办法：找到Settings中真正导出的Activity再指向它。大多数情况下，Settings$BluetoothSettingsActivity在manifest里是导出的，因为系统启动器、SystemUI、语音助手都要通过它进入蓝牙设置。

改完重新编译SystemUI，push进去重启，长按蓝牙就能正常跳转了。但这只是第一步，别忘了长按互联网入口也可能是同类问题。

4.2 互联网入口：DataUsage页面找不到时的降级方案

Android 10里，互联网模块的Tile类是InternetTile。长按InternetTile时，AOSP的常见行为是启动数据使用设置页，也就是Settings.ACTION_DATA_USAGE_SETTINGS。有些定制ROM会把它改成无线网络设置，所以得先确认你们自己的产品定义，别盲改。

我遇到的那台设备数据流量页面被精简，但保留了一个"数据使用汇总"的Fragment入口，实际Activity是com.android.settings.Settings$DataUsageSummaryActivity。于是InternetTile的长按Intent同样改成显式ComponentName：

@Override protected Intent getLongClickIntent() { Intent intent = new Intent(Settings.ACTION_DATA_USAGE_SETTINGS); ComponentName component = new ComponentName( "com.android.settings", "com.android.settings.Settings$DataUsageSummaryActivity"); intent.setComponent(component); return intent; }

这里有一点和蓝牙不同：互联网Tile长按的时候，通常要判断当前状态。如果设备只开了Wi-Fi没插SIM卡，有些ROM希望直接跳Wi-Fi设置；如果开了移动数据，则跳流量使用页面。所以更合理的做法是根据dataSaver、mobileData等状态选择不同Intent，但那样分支会多一些。

对我们这次的修复来说，目标是让白屏消失。最简单粗暴的路径就是让Intent永远能解析到某个存在的Activity。如果产品上确定不想要跳转页面，也可以用另一种方式：把长按事件降级成Toast或者弹面板提示，不跳任何Activity。这属于产品决策，代码上完全可行：

@Override protected Intent getLongClickIntent() { // 不返回Intent，改为在handleLongClick中显示Toast return null; }

如果你不确定将来Settings还会怎么改，我更推荐的是下面这种带兜底的通用写法。

4.3 通用兜底策略：用PackageManager验证目标

与其每次把隐式Intent改成显式Intent，下次Settings又把Activity类名改了然后再次白屏，不如在SystemUI侧加一道解析校验。跳转前先用PackageManager.resolveActivity()检查Intent能否解析，解析不到就记一条warning日志，并兜底不启动。

拿蓝牙举例，在BluetoothTile里可以这样处理长按逻辑：

@Override protected Intent getLongClickIntent() { return new Intent(Settings.ACTION_BLUETOOTH_SETTINGS); } // 在真正启动前加一次校验 private boolean canResolveIntent(Intent intent) { return mContext.getPackageManager().resolveActivity(intent, 0) != null; }

当然，getLongClickIntent()本身只是返回Intent，SystemUI框架内部会自己调用startActivity，我们在Tile内部插一脚的常规做法是重写handleLongClick()，把原来默认的跳转逻辑替换成带校验的版本：

@Override public void handleLongClick() { Intent intent = getLongClickIntent(); if (intent != null && mContext.getPackageManager().resolveActivity(intent, 0) == null) { Log.w(TAG, "long click intent can not be resolved: " + intent); // 兜底Toast提示 return; } super.handleLongClick(); }

这样的好处是：下次Settings再被调整，SystemUI不会再白屏，只会出现日志警告。对用户来说最多是没有反应，不至于卡住整个下拉状态栏。这在实际量产项目中非常重要，因为Settings的改动往往不是一次性的。

其实这套思路可以泛化到所有快捷开关Tile的长按行为。大家可以回去检查一下自己定制系统里的其他入口，比如Wi-Fi、热点、NFC、护眼模式，凡是长按会跳转Settings的，都建议统一加上resolveActivity校验。这是低成本高收益的做法。

5. 刷机验证与定制ROM里的后续提醒

5.1 验证清单：修完不是复测一次就完事

SystemUI修改完成后，需要编译SystemUI模块。AOSP环境下一般是：

source build/envsetup.sh lunch <你的产品名> make SystemUI -j16

如果是单独push，可以用adb root后：

adb remount adb push SystemUI.apk /system/system_ext/priv-app/SystemUI/SystemUI.apk adb reboot

我这里只说push的前提是userdebug或eng版本。如果是user版本，就得走整包升级，不能直接remount。

重启之后，复测不能只做一次长按。我的建议是按下表逐项过：

每条都过了，才敢说这个修复是稳的。特别是锁屏状态下那一项，很多Rom会意外触发别的入口，要多留个心眼。

5.2 定制系统里这条链路还容易踩的坑

修完这个bug后，我把SystemUI里快捷开关的长按跳转都扫了一遍，发现定制ROM里类似的坑远比想象中多。随便列几个就能值回这篇博客的时间：

第一，Settings的Activity是exported=false。如果你用显式Intent去启动一个非导出的Activity，系统会直接拒掉。这种情况在有些厂商SDK里出现过，因为他们把设置项的Activity故意设为不对外。解决办法是启动Settings父Activity，或者找一个真正导出的壳页面。

第二，目标Activity的进程问题。如果Settings应用整体配置了进程属性，比如android:process="com.android.settings.remote"，那Settings可能运行在多个进程里，偶尔会出现冷启动慢导致白屏。可以通过提前预热Settings进程来缓解，但这不是SystemUI代码层面能根治的。

第三，多个应用同时声明同一个Intent-filter。定制系统如果同时装了Settings和另一个设置App，隐式Intent可能弹出系统解析器。在SystemUI这种系统窗口的背景下，解析器弹不出来或者被安全策略拦掉，表现同样接近白屏。这种场景下显式Intent更是首选。

第四，长按后跳的是ACTION_APPLICATION_DETAILS_SETTINGS这种动态Intent。这种Intent的目标包名写死在本机上可能没问题，但一旦Settings的包名被改，就找不到目标了。很多白屏bug就是这种看似无害的Intent在咬人。

第五，Android 10的SystemUI还有一个和蓝牙相关的隐藏逻辑：长按蓝牙图标在某些版本里会优先尝试弹出蓝牙设备列表弹窗，如果弹窗需要的SliceProvider或者ContentProvider不存在，也会出现白屏。这种需要在log里关注Slice、ContentProvider相关关键字。

我这次修的其实就是典型的Intent解析失败问题，但上面几个坑在隔壁项目里都真实发生过。所以大家排查白屏时一定要打开思路，多确认现状再改代码，不要看到一份网上教程就照搬，因为不同ROM的Settings结构差异很大。

最后分享一个我自己的操作习惯：改完SystemUI后，先用adb shell am start把长按对应的Intent单独测一遍，确认Settings侧是通的，再回到手机上去长按。如果单独启动也是白屏，那重点就应该放到Settings那边，而不是SystemUI。这样界定问题边界，省下的时间不是一点半点。