2026-06-03Android全栈10 分钟阅读4219 字

【全栈第26课】毕业:外设完整 bring-up(全栈 26 课收官)🎓

Android 全栈工程师进阶教程第26课。毕业:外设完整 bring-up(全栈 26 课收官)🎓。基于公开 AOSP 知识整理,含原理、可编译示例、常见问题定位。

> 本文是《Android 全栈工程师进阶教程》系列第 26 课。完整 26 课见 GitHub 仓库。

【全栈第26课】毕业:外设完整 bring-up(全栈 26 课收官)🎓

0. 这节课你将得到什么

一张把全部 26 课串起来的能力地图,和一份"接一颗新外设从硬件到 App"的完整 checklist。这是你的毕业证 + 实战手册。学完你拥有:给你一颗新硬件,你能独立按流程把它接进系统、让 App 能用,并定位全栈任意一层的问题。

1. 背景:全栈不是会每一层,而是能打通每一层

单独会写驱动、会写 HAL、会写系统服务——这只是"会某一层"。全栈/BSP 的真本事是把它们打通:一个需求/一个问题,能贯穿应用→框架→HAL→驱动→硬件,知道每一层该做什么、出问题去哪查。这一课把前 25 课的点连成线、连成面。

2. 全局图:全栈知识地图(26 课)

┌─────────────── App 层 ───────────────┐
│ L2 getSystemService / L12 经 framework 调 HAL │
├─────────────── Framework 层(system_server)───┤
│ L1 Binder / L2 系统服务 / L3 生命周期           │
│ L4 Handler 消息 / L5 JNI / L6 SELinux           │
├─────────────── HAL 层(vendor 进程)───────────┤
│ L7 Treble/VINTF / L8 HIDL / L9 AIDL HAL         │
│ L10 framework 接入 / L11 HAL SELinux            │
├─────────────── Kernel 驱动层 ──────────────────┤
│ L13 GKI编译 / L14 字符驱动 / L15 platform+DTS   │
│ L16 I2C / L17 中断 / L18 电源 / L19 内核特性     │
├─────────────── 硬件层(I2C IC)─────────────────┤
└──────────────────────────────────────────────┘
贯穿全栈:L20 全链路 bring-up / L21 开机 / L22 定位武器库 / L23-25 实战 / L24 ramdump

3. 接一颗新触控 IC 的完整 bring-up checklist

按这个顺序做,每步对应一课,每步做完先验证再下一步:

硬件确认

原理图:IC 挂哪条 I2C、从设备地址、中断脚 GPIO、供电 regulator
示波器/万用表:确认上电时序、I2C 波形(L23)

Kernel 驱动(L13-L18)

DTS 加节点:compatible / reg(I2C 地址)/ interrupts / 供电(L15/L16)
写 i2c_driver,probe 读 CHIPID 验证通信(L16)
注册 input 设备,中断里 workqueue 读坐标 input_report 上报(L14/L17)
中断:gpiod_to_irq + request_threaded_irq + 下半部(L17)
电源:suspend 关 IC、resume 重新 init(L18)
编成 .ko 进 vendor,加进 modules.load(L13)
⚠️ 注意 6.11+ API:platform remove 返 void、class_create 单参数(真编译验证,见勘误)

HAL(L9-L11,若需要;触控走 input 子系统通常不用 HAL)

写 AIDL HAL(@VintfStability + stability:"vintf")(L9)
main 注册 + vintf_fragment 声明(L9)
HAL 进程 sepolicy:hal_server_domain + init_daemon_domain + service_contexts(L11)

Framework + App(L1-L6)

触控:IMS 自动接管 /dev/input/eventX(不用自己写 framework)
其他类:framework 服务调 HAL(L10),App getSystemService(L2),sepolicy(L6)

验证 + 定位(L20-L25)

从下往上逐层验证:i2cdetect → dmesg probe → getevent → 上层(L20/L23)
开机起来正常(L21);无异常重启(L24);功耗正常(suspend 关了外设,L25)

4. 前置准备

依赖前 25 课全部。本课是总集成,产出能力地图 + checklist。

5. 动手:用这张地图做一次"全栈思维演练"

拿你日常的任意一个 input ISS 单,问自己这串问题(这就是全栈思维):

这个现象在哪一层?(L22 武器库判断)
这一层我怎么验证它正常?(对应课的命令)
如果这层正常,上一层/下一层怎么查?(L20/L23 逐层)
找到根因后,改哪一层最合理?(架构判断:能在应用层修就别动 framework,能在 framework 修就别动驱动)
改完怎么验证不引入新问题?(编译 + 回归)

把每个 ISS 单都这样过一遍,这 26 课的知识就从"看过"变成"会用"。

6. 看底层:你现在能讲清的一条完整链路

一次触摸,从手指到屏幕响应:

手指触摸 → 触控 IC(硬件)
→ 拉中断脚(L17)→ 驱动上半部 schedule_work → 下半部 regmap_read 读坐标(L16)
→ input_report 上报 → /dev/input/eventX(L14)
→ IMS InputReader 读 → InputDispatcher 派发(L4 消息机制)
→ WMS 定焦点窗口 → App ViewRootImpl → onTouchEvent
→ App 调 getSystemService 用某系统服务(L2,经 Binder L1)
→ 该服务可能调 HAL(L10)→ HAL 操作另一硬件(L9)

这条链上每一跳你都能讲清原理、定位问题——这就是全栈。

7. 编译 & 运行(全栈验证习惯)

不管做什么改动,养成"从下往上逐层验证"的习惯:

# 驱动层
adb shell dmesg | grep <你的模块>
# HAL 层
adb shell lshal | grep <你的 HAL>
# framework 层
adb shell dumpsys <你的服务>
# App 层
adb logcat | grep <你的 App>

> 验证状态(诚实):本课为总集成/能力地图;各单课代码已分别验证(驱动 L14-L18 本机真编译、framework/HAL aidl 生成验证)。完整真机 bring-up 一颗硬件需真实 IC + 真机,这是你拿真设备时的实战。

8. 踩坑提醒(全栈通用)

改的层不对:能在应用层解决就别改 framework,能 framework 解决就别动驱动——越底层影响面越大、风险越高。
不逐层验证就跳着改:全栈问题一定从下往上(或反过来)逐层确认,跳步浪费时间。
只会看不会做:这 26 课如果只读不在真问题上练,会忘。用日常 ISS 单练。
忘了 API 跨版本变:写驱动一定对目标内核版本真编译(remove 签名、class_create 那些坑)。
不沉淀:每打通一个问题,记下来(像你的 docs/AGENT/),下次更快。

9. 常见问题分析与定位(全栈综合)

9.1 这一课的"问题"就是"任意全栈问题怎么下手"

万能起手式(任何现象):

adb bugreport bug.zip      # 先抓全现场(L22)

然后按 L22 决策树:判断在哪层 → 用对应工具 → 逐层排除。

9.2 全栈定位总图(把 L22-L25 合一)

任意现象
├─ 崩/重启 → 先定性(L24):logcat/dropbox(Java)→tombstone(native)→pstore(kernel)
├─ 卡顿/ANR → perfetto + traces.txt(L4/L22)
├─ 功能不工作 → 从上往下逐层(L20/L23):
│     App → logcat/getevent → framework dumpsys → HAL lshal → 驱动 dmesg → 硬件示波器
├─ 功耗/发热 → 分待机/使用(L25):wakelock/regulator 或 cpu/温度
├─ 开不了机 → 分水岭(L21):logo 前 dmesg,logo 后 logcat
└─ 拿不准在哪层 → bugreport 抓全 + 从你最熟的那层开始往两边推