安卓代码中为什么会有 sys 部件和 vendor 部件?

Android system 与 vendor 部件拆分的本质是 Project Treble 架构解耦

一、为什么要拆成两部分？

历史痛点（Treble 之前）

Android 8.0 之前，系统框架与硬件驱动强耦合混编：

每升级一次 Android 大版本，SoC 厂商必须同步重写 / 适配全部底层驱动
OEM 厂商再基于新版 vendor 做整机适配
层层传递导致安卓碎片化严重、版本更新周期极长（很多机型停更）

拆分核心目的

Google 推出 Project Treble，用稳定的 Vendor Interface（HIDL/AIDL）做中间隔离层，实现：

System 镜像通用化：同代 Android 所有设备共用一套 system.img
Vendor 镜像独立化：硬件驱动独立封装，只跟芯片走
解耦迭代：系统升级不强制要求驱动同步升级（GRF 机制就是基于此延伸）

二、system 部件（系统分区）作用

核心定位：Android 通用操作系统层，Google 主导，与硬件无关

分类	包含内容
系统框架	Android Framework（AMS/WMS/PMS 等系统服务）
运行时	ART 虚拟机、系统库（libc、libandroid_runtime 等）
系统应用	Settings、SystemUI、电话、短信等内置系统 App
通用 HAL 接口定义	HIDL/AIDL 接口头文件（定义规范，不包含实现）
原生服务	surfaceflinger、servicemanager、zygote 等

关键特征

由 AOSP 统一维护，理论上所有设备同版本通用
每次 Android 大版本升级主要更新的就是这部分
通过稳定接口调用 vendor 层的硬件能力

三、vendor 部件（厂商分区）作用

核心定位：硬件抽象与驱动层，SoC/OEM 厂商主导，跟硬件走

分类	包含内容
内核模块	Linux 内核驱动（.ko 文件）、设备树 dtb/dtbo
HAL 实现	各硬件模块的 HAL 层实现（相机、音频、传感器、GPU 等）
厂商守护进程	高通的 qseecomd、MTK 的各类 mtk 守护进程
固件	WiFi、蓝牙、Modem、GPU 等硬件固件（firmware）
厂商库	如高通 adreno GPU 驱动库、各类芯片专属 SDK

关键特征

与具体芯片强绑定，不同 SOC 完全不通用
由芯片厂商（高通 / MTK / 展锐）提供，OEM 再叠加 ODM 定制
版本独立于 system，符合 GRF 规则时可跨多个 Android 版本复用

四、两者的边界与协作关系

┌─────────────────────────────────┐│         System 分区              │  Google 维护，通用│  Framework / System Apps / ART  │├─────────────────────────────────┤  ← HIDL/AIDL 稳定接口（契约）│         Vendor 分区              │  芯片厂商维护，硬件相关│  HAL 实现 / 驱动 / 固件 / 守护进程│└─────────────────────────────────┘

核心规则

System 不能直接调用 Vendor 内部实现，必须通过定义好的接口
接口向前兼容：旧版 vendor 能被新版 system 调用（GRF 的基础）
编译分离：system 和 vendor 分开编译、分开打包镜像、分开 OTA 升级

五、一句话总结

system 是通用的安卓操作系统本体，vendor 是硬件驱动与抽象层的封装包，两者通过稳定接口解耦，目的是让系统升级不再强依赖驱动重写，从架构层面解决安卓更新慢的问题。

（注：部分内容可能由 AI 生成）