北极巨兔两个月前，我从合作厂商手里接过一台跑着 Android 14 的行业板卡，需求倒是不复杂：开机直接进客户界面、去掉不想要的下拉快捷项、让预装应用首次启动就能拿到该有的权限，最后把开机和应用响应速度压到可接受范围。听起来像"改改配置就行"，真正扎进去才发现这是一条涉及 SystemUI、PackageManagerService、开机流程和内存回收策略的完整 Android Framework 定制链路。这篇文章不写泛泛的入门理论，而是我在这类模块定制和系统优化项目中真实踩过的坑、用过的排查思路，以及最后怎么把成果讲清楚、写进简历的经验沉淀。
1. Framework开发的第一步：先画清系统分层与定制边界
1.1 别急着改代码，先理解Android把权力分给了谁
很多人一听到 "Framework定制" 就急着打开源码搜索 ActivityManagerService，但我建议先退一步，把 Android 的运行模型想清楚。
我自己常用的类比是：把整台安卓设备看作一座城市。Linux 内核是水电、道路交通这些基础设施；HAL 层是自来水厂、电厂的具体设备供应商；而位于 frameworks/base/services 的 SystemServer 是城市运行管理中心，在这里启动的 ActivityManagerService、PackageManagerService、WindowManagerService 相当于负责人口管理、工商注册和城市规划的部门。应用层是普通的商户和居民，SystemUI 则是设在政务大厅的那些办事窗口和户外显示大屏。
模块定制的本质是什么？要么改"大屏展示"——让某些按钮不出现、某些状态不展示；要么改"政务规则"——改变权限授予方式、改变后台进程调度策略；要么改"部门协作流程"——调整系统服务之间传递消息的优先级。如果不先搞清楚这次改动落在哪一层，很容易出现两种尴尬：在应用层用 Accessibility 模拟点击去绕过系统限制，或者把本来可以在资源 overlay 解决的问题搞成在系统服务里大动干戈。
以这次项目为例，客户设备运行的是厂商 BSP 提供的 Android 14 系统，以下三个问题分属不同层级：
- 开机后自动进入指定 Launcher，不再出现 SetupWizard，这是 Provision 和系统属性层面的定制。
- 下拉快捷设置栏只显示白名单开关，维修人员输入工程码后才显示完整列表，这是 SystemUI 的模块级改动。
- 预装应用首次启动直接拥有位置、存储等权限，不再需要用户逐个点击授权弹窗，这是 PackageManagerService 的默认授权策略问题。
三条改动看似独立，实际在代码上互相咬合。如果先不动手、花两天把涉及模块的调用关系画清楚，后期一定会在某个"为什么要带这个上下文"的问题上卡住。
1.2 两类定制路径与源码落点
我习惯把 Framework 定制分成"UI 感知型"和"系统策略型"。前者改的是用户能直接看到、触摸到的界面，代码大多落在 frameworks/base/packages/SystemUI、packages/apps/Settings 这类目录；后者改的是进程管理、组件管理、权限授予等"看不见但决定体验"的策略，代码落在 frameworks/base/services/core/java/com/android/server 下的各个服务里。
两者有个明显差异：改 SystemUI，单独编译模块、push 进设备就能快速验证，不影响核心系统服务；改动 ActivityManagerService 或 PackageManagerService，即使只是几行策略调整，也往往需要整机编译、重新烧录，而且一旦逻辑错误，可能造成开机起不来、应用安装异常等连锁问题。
下表是我面对一个定制需求时常用的"落点判断表"：
| 需求现象 | 最可能的定制模块 | 用户可见性 |
|---|---|---|
| 状态栏/下拉面板/通知布局不符合预期 | SystemUI | 高 |
| 某个 App 安装后默认权限不对 | DefaultPermissionGrantPolicy / 权限服务 | 中（设置页可见） |
| 后台任务一杀就死，或杀不掉 | ActivityManagerService / lmkd策略 | 低 |
| 开机流程多了几秒、启动服务顺序混乱 | init.rc / SystemServer 启动逻辑 | 低 |
| 多任务切换动画卡顿、窗口层级异常 | WindowManagerService / SurfaceFlinger | 高 |
判断完落点再动手，后面所有步骤都是在给这个判断补细节。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 源码编译环境：先把这个流程跑痛，后面才快
2.1 准备一套能反复编译的宿主环境
Framework 项目最劝退新人的不是代码本身，而是环境准备。我第一次干这活是在一台 16GB 内存的旧笔记本上，编译到一半直接 OOM，连错误日志都来不及看。后来换成 64GB 内存、500GB 可用磁盘的台式机才顺畅。行业板卡 BSP 通常自带一套 target 配置，一般流程是先把完整 AOSP 仓库同步下来，再叠加厂商的 kernel、device、vendor 目录。
源码获取方面，如果做的是纯 Google 设备，可以用清华 AOSP 镜像同步 manifest：
bash复制repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-14.0.0_r1
repo sync -j8
不过大多数行业项目拿到的是一份厂商的 BSP repo 清单，OpenHarmony、RK、QCOM 等方案商通常已经替你把 kernel 和 vendor 对齐到某个 AOSP 基线。这时我更建议直接按厂商文档操作，不要把厂商 BSP 自行上升到最新 AOSP tag——系统定制追求的是稳定基线，不是追新。
编译环境方面，Android 14 通常要求在 Ubuntu 20.04 或更新版本上编译，OpenJDK 版本跟随源码自带的要求，一般不需要自己另装。磁盘分区建议预留至少 300GB，因为除了源码本身，ccache、out 目录、最终镜像都会占用大量空间。
bash复制export USE_CCACHE=1
export CCACHE_EXEC=/usr/bin/ccache
ccache -M 100G
source build/envsetup.sh
lunch
输入 lunch 后选择厂商设备对应的 target，如果是模拟器调试验证，可以选 sdk_phone64_x86_64。首次全量编译建议直接 m -j16，CPU 核数多可以适当调大并行数。全量编译通常一到两个小时，取决于机器性能，这段时间不要干看着，可以去读 SystemServer 启动流程源码。
2.2 设备烧录与 userdebug 版本的调试价值
行业设备定制时，我强烈建议烧录 userdebug 版本而不是 user 版本。userdebug 保留了 adb root、remount 分区、更多日志输出等能力，很多问题没有这些权限会排查到怀疑人生。
全量编译完成后，常见的烧录方式是：
bash复制fastboot flashall -w
-w 会清空数据。如果设备上已经积累了重要的账号或调试数据，则去掉 -w，但系统升级中残留旧数据也可能引发一些诡异问题，所以能在开发板上直接清空重来反而是好事。
另外提一句，改完代码后不要每次走全量编译。SystemUI 这类模块单独编译加推送，可以让一次改动的验证周期从一小时缩短到两三分钟：
bash复制m SystemUI
adb root
adb remount
adb sync
adb reboot
如果只是资源文件或布局调整，多数情况下甚至连完整 sync 都不需要，直接替换对应 apk 再重启目标进程即可。这种"模块级编译 + 状态栏单进程重启"的循环才是 Framework 定制日常的真实节奏。
2.3 多次编译容易忽略的增量问题
跑过一次全量之后，后面的改动基本走增量编译。增量也会出问题：改了 Java/Kotlin 代码后没有生效，十有八九是编译产物缓存异常。我的习惯是遇到"代码明明改了但行为没变"时，先执行 m SystemUI 时看编译日志有没有真正把目标文件编进去，然后单独 touch 对应的源文件再编译，必要时直接删掉 out/target/product/<board>/system/priv-app/SystemUI 里的旧产物。
还有个大坑是 ccache 的命中率。如果改的是公共接口，比如修改了 framework 的 API，受影响的模块会连锁重编，ccache 命中率骤降，编译时间一下拉长。这不是环境坏了，而是依赖链变化，放平心态。
这些环境层面的细节，决定了后面真正动手改代码时的心情。
3. 模块定制实战：把SystemUI和默认授权策略改到符合业务
3.1 先处理"下拉面板只留白名单"这个需求
系统定制第一步往往没那么技术，而是需求拆解。客户原话是"不要让顾客把 WiFi 关了，但维修师傅得能调"。如果直接在 SystemUI 里删代码，需求一变又要重新编译，所以我用了更可维护的方案：通过 overlay 机制覆盖默认的快捷设置 Tile 列表。
Android 的 SystemUI 里，下拉面板的默认 Tile 列表由资源项控制，我们可以通过编译期 overlay 把列表收敛成白名单。比如在 overlay 包中定义资源值，只保留 wifi、蓝牙、勿扰等少量项。这样当普通模式启动时，SystemUI 读到的是定制后的列表；维修员进入工程模式后，再通过自定义的 QSTile 或配置项把完整列表恢复。
这里要特别说一句：不要试图在 SystemUI 里用 setVisible 控制系统已经创建的 Tile，就算你把它隐藏了，Tile 对应的服务可能仍然在响应按键广播或状态回调。真正干净的做法是在 Tile 的"创建源头"就决定好放哪些进来，否则后面会不断遇到"图标没了但功能还能触发"的怪问题。
3.2 让“系统能力”与“界面开关”保持同一套授权逻辑
客户第二个痛点是预装业务 App 首次启动会弹很多权限申请。对于无人值守的行业设备，让使用者去点权限弹窗本来就不现实。可供选择的方案有三条：
第一，在应用侧把 targetSdkVersion 调低，借旧版安装流程的默认授权逻辑自动获得权限，但这只是规避，系统设置里看到的权限状态会很怪，而且 Google 在后续版本不断收紧旧 target 的行为，这条路走不长远。
第二，通过默认权限授予服务，在系统首次启动后主动为白名单应用授予位置、存储等权限，代码存在于 frameworks/base/services/core/java/com/android/server/pm/permission/DefaultPermissionGrantPolicy.java，定制时可以往默认权限列表里加包名和权限组。
第三，使用 RoleManager 分配默认角色，这对通话、短信等系统默认应用更合适。
我最后走的是第二条，核心思路是：新增一个权限名单配置文件，让 DefaultPermissionGrantPolicy 在系统扫描到预装 App 时，一次性授予白名单权限组。与在 PMS 安装流程里直接插入权限代码相比，前者依然走系统完整的权限状态机，应用后续在 Settings 里看到的状态和真实授权情况是吻合的。
这块有个值得注意的行业惯例：不要对所有预装应用无脑默认授权。普通消费者产品这么干会带来隐私合规风险，行业设备至少也要按业务包拆分白名单，只授予它真实需要的权限，权限模型越克制，后续出安全审计问题的概率越小。
3.3 从"单点改完"到"链路验证"
SystemUI 面板改造和默认授权策略看似独立，但在验证时要一起跑：预装应用首次启动后，看 SystemUI 是否因为某个权限状态变化出现异常刷新；下拉面板里开关键的状态是否与实际权限状态一致。
我通常按这个顺序做闭环验证：
- 重新烧录镜像，确保是干净状态。
- 首次开机后直接
adb shell dumpsys package <包名>，检查权限列表是否有目标权限。 - 在界面里进入设置-应用，查看运行时权限页面，确认系统 UI 的认知与真实状态一致。
- 下拉状态栏，逐项操作白名单开关，确认没有异常崩溃和状态不同步。
一套下来如果都没问题，这次模块定制才算真正落地。
4. 系统优化不是调参数，是定位瓶颈再取舍
4.1 开机时长：从 31 秒压到 22 秒的定位过程
客户给的指标很具体：冷启动从按下电源键到出现 Launcher 桌面，不能超过 24 秒。实测原来的固件要 31 秒左右，多了 7 秒。盲目剪服务是最危险的做法，我的第一步永远是量化。
Android 系统本身提供了 bootstat 机制，烧录 userdebug 版本后可以直接查看各阶段耗时：
bash复制adb shell bootstat print
输出会给出 boot_progress_start、boot_progress_system_server_start、boot_progress_ams_ready、boot_progress_enable_screen 等节点的时间戳。对比之后，我这次的时间损耗主要在两块：SystemServer 里多个服务串行初始化耗时偏长，以及开机阶段 PackageManager 扫描预装应用耗时高。
针对服务初始化，我用的是"服务优先级拆分"思路：把不直接影响桌面显示的初始化挪到主流程之后，比如某些后台管理服务改为收到系统就绪广播后再自行初始化。这个改法风险低，但对代码位置要求很准，尤其要注意有没有代码在 ServiceManager 注册前就通过 checkService 拿引用，一旦拿成 null 后续会判空崩溃。
针对包扫描耗时，行业设备预装应用一般不多，但很多应用没有做 dex 预编译，第一次扫描会现场编译，慢就慢在这。优化手段是让这些白名单应用在出厂的 user 镜像里直接以 speed 编译产物存在，而不是首次开机时才编译。优化之后，开机时间实测落到 22.6 秒，总算满足客户要求。
4.2 内存与后台进程策略：别只盯着"杀进程"
行业设备最常见的系统优化误区是：内存不够，就想着怎么杀后台进程。且不谈杀得狠了导致应用拉起更频繁、CPU 消耗更高，很多业务场景根本不允许后台进程被杀掉。
在 Framework 层面，我更推荐先给进程分好"角色"，再用系统提供的策略去管理。常用的操作有：
bash复制# 把某个应用放入受限的standby bucket
adb shell am set-standby-bucket com.example.debug restricted
# 通过appops拒绝后台运行
adb shell cmd appops set com.example.debug RUN_IN_BACKGROUND deny
这些策略最终会影响 ActivityManagerService 对进程优先级的判断，以及 lmkd 在内存压力下回收的顺序。理解"进程优先级由 adj 值决定、回收顺序由 lmkd 决定"这条链路，比记住几十个命令更有价值。
我还会用 dumpsys meminfo 看进程的 PSS 占用，而不是看 RSS。PSS 会把共享库按比例分摊到每个进程，更接近真实占用。很多时候你以为某个应用占用 1GB，实际上是系统共享库被重复计算的假象。
4.3 流畅度优化：掉帧定位从主线程卡顿开始
系统卡顿、掉帧，判断起来比开机时间长更主观，但也更让人头大。我遇到的情况是：下拉面板偶尔掉帧、打开最近任务时有明显迟滞。
Framework 层排查这类问题，第一工具是 Perfetto。抓取一小段交互过程的 trace，先看 App 主线程是否有过长的任务，再看 SurfaceFlinger 合成是否超时。如果主线程出现长耗时，直接抓取该线程的堆栈，往往能定位到是哪个 Binder 调用阻塞了 UI；如果渲染线程没问题但 SurfaceFlinger 有掉帧，则要考虑图层数量或合成压力。
这次项目里发现的下拉面板掉帧原因很有意思：自定义 Tile 的刷新状态时，主线程里做了一次跨进程获取系统配置的同步调用，这个调用在最坏情况下会等上百毫秒。把状态刷新改成异步回调之后，掉帧现象就消失了。
这类问题往往不是"代码报错"，而是主线程里一次隐蔽的同步 Binder 调用。我养成了一个习惯：所有自定义 Tile 和通知相关回调里，禁止任何可能导致 Binder 同步等待的操作。
5. 定制落地后的bug排查：一次SystemUI崩溃与一次AVC拒绝
5.1 一次SystemUI偶现崩溃的完整排查链路
系统定制后最怕的不是功能不生效，而是偶现崩溃且无法稳定复现。我这次就遇到一个：快速下拉两三次后，SystemUI 偶尔会黑屏一下然后自动重启。
第一步不是急着看堆栈，而是想什么条件下最容易触发。我根据现象猜测：快速下拉时 Tile 状态刷新和通知栏展开动画并发执行，可能撞上某个空对象。随后用以下命令抓崩溃现场：
bash复制adb logcat -c
# 手动快速下拉操作若干次
adb logcat -b crash -d > crash.log
日志里果然有 SystemUI 进程的 FATAL EXCEPTION，栈顶指向自定义 Tile 的 handleClick 中读取一个 SharedPreferences 值并转换成 List 的代码。进一步分析发现，存储配置的 key 在维修员模式切换时被另一个线程清空，而 UI 线程在读取时没有做空集合判断，取到 null 后直接遍历，抛了空指针。
修复思路是先判断数据是否存在，再决定是否重建默认列表。这个 bug 的价值不在于那两行代码，而在于为什么偶现——因为它依赖两个线程的临界竞争，单线程复现很难。遇到这类偶现问题，第一优先级是想办法构造并发条件，而不是反复点界面"赌运气"。
5.2 系统能力调用被拦？先看SELinux的AVC拒绝
另一个坑更隐蔽。自定义 Tile 在维修员模式下需要调用某个系统服务接口切换系统配置，在 userdebug 版本里测试一切正常，但切到 user 版本后这个调用总是静默失败，日志里只有一行被大多数人忽略的记录：
bash复制dmesg | grep 'avc: denied'
这是 SELinux 策略拦截。userdebug 版本中 SELinux 处于 permissive 或宽容状态，问题不会暴露；user 版本强 enforcing，没有对应 allow 规则就被拒绝。很多 Framework 新手把精力花在检查调用代码上，绕了远路。
我当时的处理是定位 AVC denied 日志中出现的主体和客体类型，然后在对应 sepolicy 文件里补充 allow 规则，重新编译 boot 镜像验证。这类问题可以写进经验清单：只要发现"userdebug 正常、user 版本异常"的规律，第一反应就该是 SELinux。
5.3 定制后的回归测试不能只跑功能用例
Framework 改动最怕影响系统全局行为。我每次做完整定制后，至少会回归这几类点：
- 首次开机向导是否正常跳过，桌面是否直接出现。
- 系统设置、SystemUI、Launcher 三者的权限弹窗与后台行为是否正常。
- 安装、卸载、清除数据这些 PackageManager 基础操作是否正常。
- 通过
adb shell dumpsys activity检查关键进程是否因为新策略被频繁杀死和重启。
如果设备需要出货，有条件的话最好跑一遍对应版本的 CTS 兼容性测试框架，重点看 Framework 相关模块有没有破坏兼容性。行业设备虽然对 CTS 要求没那么高，但减少对公共 API 的影响是底线。
6. 怎样把Framework开发经验沉淀成别人能看懂的东西
6.1 用"业务问题-技术方案-量化结果"写项目经历
做完一个 Framework 定制项目，如果不整理，三个月后连自己都可能忘了当时绕过哪些坑。我习惯把一个项目拆成三层去记录：业务层客户痛点、系统层改动位置与方案、指标层优化前后数据。
用在简历或团队分享里，常用结构是：为 xx 行业设备定制 Android 14 系统，涉及 SystemUI 快捷面板模块定制、PackageManager 默认授权策略调整，实现开机进桌面时间从 31 秒缩短至 22.6 秒，后台内存占用降低约 18%，同时补齐 SELinux 安全策略。相比"熟悉Android Framework"这种空泛说法，这种写法面试官听完至少知道你真的动过代码、能定位问题。
面试时被问 Framework 项目，不要只讲"我改了什么"，要能讲清"改这个模块时，系统的启动顺序是什么、Binder 调用链经过谁、和 PMS/AMS 怎么协作"。这才是在真实定制项目中练出来的核心能力。
6.2 啃源码阶段的三个高频追问
复盘时，我发现面试官和团队新人最喜欢追问三个方向，恰好也是吃透 Framework 的关键：
第一是 Binder 通信机制。定制系统必然要跨进程调用系统服务，如果不理解 binder 线程池、oneway 调用和同步调用的区别，很难定位自定义 Tile 里那个造成卡顿的 Binder 等待问题。
第二是 Android 系统的启动流程。从 Bootloader 到 init，再到 Zygote、SystemServer 的启动顺序，业务里几乎所有模块定制时机都建立在这个流程上。比如我跳过 SetupWizard、调整服务初始化先后顺序，依赖的全是这套知识。
第三是进程与组件的生命周期管理。修改默认授权策略、调整后台进程限制，如果不懂 ActivityManagerService 如何管理进程优先级、lmkd 如何决定回收顺序，改动就像在没有地图的街区里开车。
6.3 一个更长期的建议
做 Framework 定制久了，最大的变化是看问题的视角：普通应用开发关心"我这个 App 能不能跑"，Framework 开发关心"整个系统里所有 App 是不是都在有序运行"。这个视角转化不是看几篇源码分析就能建立的，而是被一个个"改了 UI 导致系统服务崩溃""权限逻辑少了一条导致应用装不上"的现实问题逼出来的。
所以我给愿意往这个方向走的人的建议很简单：自己找一台可刷机的设备，从改开机动画、加一个系统属性这种小任务开始，然后去做一个真正有挑战的模块定制，比如给 SystemUI 加一个自定义快捷开关。这个过程会踩遍环境、权限、编译、SELinux 的坑，但每踩一次，你对系统层运行机制的理解就多一层。把手弄脏，比看一百遍架构图都有用。