Android GRF策略通过需求冻结提供了更稳定和可预测的软件开发环境,帮助设备制造商提前规划并优化他们的资源。
高通的QSSI方案通过创建一个通用的系统镜像,简化了多设备平台上的软件开发和维护工作。通过分离基础系统镜像(如 system.img)和设备特定的镜像(如vendor.img)QSSI 促进了更好的软件模块化。
这两种方案都旨在减少开发复杂性,加快产品上市速度,并提高最终产品的质量和用户体验。
1 Android GRF 策略
1.1 自 Android 11 起Google 开始实施GRF的更新策略。
在 Google Requirements Freeze 引入之后,Vendor 版本将被冻结,而 Google 将承诺为各 Vendor 版本提供 N+3 的特性向后兼容保证。例如首次利用 GRF 特性的骁龙 888,Vendor 版本适配当年的 Android 11,那么即便后续升级 Android 版本,Vendor 版本也不再变动,而 Google 将保证 Android 14 能够支持 11 的 Vendor 版本启动,并通过新版本的兼容性测试。
优点:GRF 减轻了上游 SoC 供应商的维护压力,
缺点:由于 Google 必须保证 Android 新版本与先前 Vendor 版本的兼容性,而无法做到涉及硬件支持的特性在相同版本 Android 上体验一致。例如由于涉及 Vendor 改动,即使 Google 在 Android 12 上引入了禁用 2G 的开关,也无法推广到所有 Android 12 的设备上。同时 Google 对 GRF 的承诺只到 N+3,若 OEM 厂商想扩展支持到 4 个大版本升级,将必须自行移植最新版本涉及 Vendor 的特性需求,以通过对应版本的兼容性测试。
1.2 Android系统分为Vendor和SSI两个部分
Vendor里封装了硬件的一些驱动,这些文件随着手机硬件的不同而有所改变,而SSI则偏向于软件层面,两个不同硬件的手机可以使用同一套SSI,例如小米手机有很多型号,但它们用的都是同一套SSI(不准确,大概理解就行)。 SSI 是 OEM 通用的映像,可以存在于多个设备上。它不包含任何特定用于硬件或特定于产品的组件。根据定义,指定 SSI 中的所有内容都在使用该 SSI 的所有设备之间共享。SSI 可由单个 /system 映像组成,也可由 /system 和 /system_ext 分区组成
1.3 使用 VNDK
VNDK 为 Android 版本迭代时发生的 API/ABI 变更所导致的问题提供了解决途径。用于实现操作系统的模块化,并确保应用程序二进制接口(ABI)的稳定性。VNDK是为了解决 Android 系统在设备制造商(OEM)和硬件供应商之间因软件更新而引起的兼容性问题。
2 高通system和vendor分离方案
2.1 QSSI(Qualcomm Single System Image)是高通推出的一种用于编译 Android 设备固件的策略
从 Android Q(即 Android 10)版本开始支持。QSSI 的目的是简化和加速 Android 设备的开发和升级过程,通过创建一个统一的系统镜像来服务于不同的设备,而不需要为每种设备或SoC单独编译。
QSSI的主要用途是编译出一个可以在多个设备上运行的统一的system.img。system.img包含了Android操作系统的主要部分,包括应用程序、用户界面和系统级服务。
添加图片注释,不超过 140 字(可选)
2.2 编译QSSI涉及以下主要步骤
-
lunch qssi:这个命令设置编译环境以编译QSSI系统镜像(system.img)。在这个过程中,所有与设备无关的通用组件都会被编译。这个镜像作为多个目标设备的基础。
-
lunch target:这个命令用于设置编译环境以编译特定目标设备的其余镜像,如boot.img、vendor.img等。这一步确保设备特定的组件,如特定SoC的驱动程序和优化,被正确编译并集成。
通过这种分离的编译方法,高通能够提供一个核心的系统镜像,该镜像包含所有通用的Android代码和服务,而设备制造商只需要关注于其特定硬件的适配和优化。这样不仅提高了开发效率,也简化了后续的更新和维护过程。
Android自从Q之后实现了动态分区, 将system和vendor等分区打包到一个super分区中,使得super分区中个子分区更加灵活地划分空间,所以高通编译命令也有了一些变化。