Android 15 的GRF平台开发说明
一、背景
Android GRF 估计很多人不清楚是啥，这个我也是开发Android15源码才知道的。
简单的说就是Android15的系统可以用Android14的开发板进行适配开发。
系统开发人员后面估计都会遇到，有兴趣的可以了解看看。
不同系统编译的脚本和命令，在不同SOC厂商可能是不同的，
这里不展开说明，大概有个了解就好了。
1、GRF: Google Requirements Freeze（谷歌需求冻结）,
是Google（操作系统）与SoC（System on Chip系统芯片）厂商的一种合作方式，
SoC在某个Android版本进行Freeze（冻结）之后，
连续4个Android版本不需要再升级vendor组件，以加快系统版本的适配和升级。
加入GRF的SoC，必须保证4个大版本Android的升级。
这种合作模式，对于IDH和ODM/OEM厂商也有很大的益处，
对于硬件改动小的板形，配合使用A14的SDK，即可快速完成对Android 15/16/17的适配。
2、Merge（系统固件合并）:
对于GRF的芯片，必须按照要求，使用GRF的SDK，编译出BSP以及Vendor相关的组件；
而需要过认证的版本（例如A15），则需要编译出Frameworks、App相关的组件。
两部分编译完成，进行合并操作，
生成完整的固件（**这里的固件并非临时固件，就是最终测试、量产的固件**），测试功能以及GMS等。
3、Android14 GRF 支持的版本平台
| 平台/认证版本 | GRF版本 | Android 15 | Android 16 | Android 17 |
|---|---|---|---|---|
| RK33XX | 14 | Y | Y | Y |
| RK3588 | 14 | Y | Y | Y |
| RK35XX | 14 | Y | Y | Y |
4、先不涉及代码修改，这里简单总结一下GRF：
1、GRF ，Google Requirements Freeze 表示谷歌需求冻结
某一个部分的需求冻结，后期改动会较小不影响正常使用；
比如Android14-17底层内核和vendor逻辑基本不变；
只需要适配Frameworks、APP、System 等固件即可使用最新版本的Android系统。
2、下载一个GRF的源码，后续四个系统版本都可以用这个开发板进行升级
简单的说就是Google后面会减少内核或硬件上的适配修改，主要适配上层逻辑，可以不用换新的硬件升级新的系统了。
二、Android15 GRF 代码适配
1、重新下载一份Android15 的GRF 系统代码
注意Android15 GRF的源码会下载两套代码，
一套是Android14 U的，一套是Android15 V的；
2、GMS代码配置
GMS相关配置，请参考GMS配置文档(Android_GMS_Developer_Guide)进行配置。
除了GMS的基本配置外，需要额外做一些配置以使GMS固件适配GRF。
GMS 即谷歌移动服务（Google Mobile Service） ，是谷歌旗下的一项服务，
让用户能通过移动设备使用谷歌搜索、谷歌地图、Gmail、YouTube 等产品。
GMS 一般比较少适配，大部分情况都是厂商适配完成后我们使用就行。
3、对于GRF SDK
编译固件前，需要确认你要做的认证版本，配置api，
以Android 15 + GRF 14为例，在GRF SDK (Android 14)中，增加以下修改：
不同平台的修改会不一样，这里举例3588的修改：
在Android14 u的源码目录：rk3588_u.mk
# First lunching is U, api_level is 34
-PRODUCT_SHIPPING_API_LEVEL := 34
+PRODUCT_SHIPPING_API_LEVEL := 35
4、对于认证SDK
编译固件前，需要确认GRF的版本是否需要VNDK，如果需要VNDK，则要求增加vndk适配包。
从AOSP 15开始，VNDK移除。
因此，只要GRF在15以前的版本，都需要增加vndk适配包，
注意这里不要修改PRODUCT_SHIPPING_API_LEVEL，在认证SDK（此处以Android 15为例）中，补丁如下：
在Android15 v的源码目录：rk3588_u.mk：rk3588_u.mk
-# First lunching is U, api_level is 34
+# Add VNDK support for GRF Vendor API Freeze A14
+PRODUCT_EXTRA_VNDK_VERSIONS := 34
+
+# First lunching is A14, api_level is 34
PRODUCT_SHIPPING_API_LEVEL := 34
PRODUCT_DTBO_TEMPLATE := $(LOCAL_PATH)/dt-overlay.in
对于 PRODUCT_SHIPPING_API_LEVEL 标签，Android13之前的方案也是有的，
但是可能作用并未定义使用，而且不是对标Android系统版本。
也有可以是rk芯片厂商的做法，其他厂商还未开发Android15，不确定具体情况。
从上面SDK和认证版本大概可以得知：
1、GRF SDK 是需要修改的 Android14 U源码的目录；
2、认证 SDK 是需要修改的 Android15 V源码的目录；
Android13 以后销售国外产品是必须走认证的，否则可能会被封杀。
5、编译说明
厂商提供了一个用于管理GRF SDK的管理工具，使用脚本工具时，
通过简单配置，可以最大程度的简化编译、合并等步骤。
推荐使用管理工具进行编译、合并、打包等。
（1）编译前准备
需要分别下载GRF SDK和SYSTEM SDK，以当前A15 (GRF 14版本) 过认证为例，
需要下载GRF SDK (Android 14) 以及SYSTEM SDK (Android 15)。
代码结构如下：
最终理想情况如下：
不管怎么样，最终就是要两个SKD合并成一个升级固件。
（2）使用SDK管理脚本工具
-
配置SDK
-
lunch产品
-
配置json文件
-
check配置
此功能为GMS专用，初步检查GMS认证相关的配置，是否符合CDD/VSR/GMS Requirements。
-
build编译固件
编译SDK组件，选择system时，编译frameworks及app组件，GMS包也属于此部分。
-
install，只拷贝、合并、打包。
执行此命令，会将前面编译好的vendor素材包及frameworks素材包拷贝到Rockdev中，同时进行merge、pack。
-
merge合并vendor和frameworks
执行此命令，会将前面编译好的vendor素材包及frameworks素材包进行合并，生成新的素材包及fastboot可烧写的固件包以及super.img。但不会生成update.img大固件。
-
pack
执行此命令，会将前面编译好的固件包打包成update.img大固件。如果环境变量中存在USE_OVERLAY=1，则会在打包update.img前，从overlay目录拷贝覆盖image。
-
distclean
执行此命令，会删除Rockdev以及SYSTEM_SDK和VENDOR_SDK的out/dist目录。
-
reset
清除SYSTEM_SDK和VENDOR_SDK的软链接以及配置文件config.json
（3）不使用SDK管理脚本工具
-
在GRF版本SDK中编译固件
确保此GRF版本SDK（例如Android 14）固件的基本功能正常，稳定性没有问题。确认OK后，编译素材包： -
在认证版本SDK中编译固件
确保此认证版本SDK（例如Android 15）固件的基本功能正常，稳定性没有问题，注意分区表要和GRF版本一致，硬件相关功能配置也要完全一致。确认OK后，编译素材包： -
合并素材包，生成新固件
合并步骤，需要在当前过认证的版本SDK中进行。例如A15 + GRF 14，我们需要在A15中编译出需要用到的工具，并使用此工具合并两个素材包。
合并素材包时，需要指定组合方式，分别传入frameworks（这里指当前过认证的版本，如Android 15）和vendor（这里指GRF初始版本，如Android 14）的素材包，执行命令，即可生成新的素材包及fastboot可烧写的镜像。执行结束后，产生fastboot可烧写的zip固件，以及合并后的素材包。包含`--output-super out_merged1/super.img`参数时会同时生成super.img，方便做大固件烧写。例如上述命令执行后，得到： ```shell 205@^_^@ | out_merged1 ls rk3588_u-img.zip rk3588_u-target_files-0001.zip super.img
三、烧写升级
使用RK烧写工具
客户可以按照需求自行选择烧写大固件或散包：
-
如果使用SDK管理工具，执行打包命令后，
会生成update.img大固件，直接加载大固件烧写即可。 -
如果不使用SDK管理工具，请自己烧写散包。
解压fastboot包即可得到各个分区的镜像，需要自己导入分区表。
动态分区(odm/odm_dlkm/product/system/system_dlkm/system_ext/vendor/vendor_dlkm)的镜像不需要导入分区表，
对应的super.img在执行命令后会同步生成。 -
或拷贝散包镜像自己打包update.img大固件，再进行烧写。
无论是编译还是烧写，不同的SOC厂商都是有差异的，这里是参考RK的。
四、附录
1、生成镜像以及对应关系
| 镜像 | 从哪个素材包生成 |
|---|---|
| boot.img | vendor |
| dtbo.img | vendor |
| init_boot.img | vendor |
| odm.img | vendor |
| odm_dlkm.img | vendor |
| product.img | frameworks |
| resource.img | vendor |
| system.img | frameworks |
| system_dlkm.img | vendor |
| system_ext.img | frameworks |
| uboot.img | vendor |
| vbmeta.img | 由新镜像重新签名生成 |
| vendor.img | vendor |
| vendor_boot.img | vendor |
| vendor_dlkm.img | vendor |
2、源码位置 —— VENDOR_SDK部分
VENDOR部分代码都位于VENDOR_SDK目录中，主要包含所有BSP相关的内容。例如loader、uboot、Android HAL、驱动等。
编译时可使用./merge_unity.sh build vendor编译，如需调试、单独编译某个so或bin，则需要像之前一样，在VENDOR_SDK中source build/envsetup.sh ; lunch，选择你的product后，使用m 模块名进行编译。
| 源码仓库 | 备注 |
|---|---|
| u-boot/rkbin | 到VENDOR_SDK中编译 |
| kernel | 到VENDOR_SDK中编译 |
| mkcombinedroot | 编译kernel时自动更新ko |
| hardware/* | 可在VENDOR_SDK中单独编译某个组件 |
| vendor/rockchip/* | 可在VENDOR_SDK中单独编译某个组件 |
| vendor/widevine | 可在VENDOR_SDK中单独编译某个组件 |
| bootable/* | 可在VENDOR_SDK中单独编译某个组件 |
| device/* | 配置需要和SYSTEM_SDK一致 |
| external/camera_engine_rkaiq | 可在VENDOR_SDK中单独编译某个组件 |
| external/uvc-gadget | 可在VENDOR_SDK中单独编译某个组件 |
3、源码位置 —— SYSTEM_SDK部分
SYSTEM部分代码都位于SYSTEM_SDK目录中，编译时可使用./merge_unity.sh build system编译，如需调试、单独编译某个so或bin，则需要像之前一样，在SYSTEM_SDK中source build/envsetup.sh ; lunch，选择你的product后，使用m 模块名进行编译。
| 源码仓库 | 备注 |
|---|---|
| frameworks | 到SYSTEM_SDK中编译 |
| packages | 到SYSTEM_SDK中编译 |
| system | 到SYSTEM_SDK中编译 |
| vendor/gms_express | RK提供的，符合GMS Express Plus要求 |
| vendor/partner_gms | 原生Google GMS包 |
| vendor/partner_modules | 原生Google GMS包 |
| vendor/rockchip/platform | 可在VENDOR_SDK中单独编译某个组件 |
五、其他
1、GRF小结
Android 14 后，可以下载一个GRF版本，
理论上支持后续四个版本的系统升级在同一个开发板上。
比如下载 Android14 版本的GRF代码，加上Android15 的代码，编译后就是Android15 的系统代码。
简单理解就是用Android14 的底层+Android15 SDK的上层。
当然也可以下载Android15 的GRF版本，
下载Android16、17 的源码，也是可以用同一个开发板。
其实也是类似手机的升级，,在线升级后，
发现从Android11 升级到了 Android12，也有可能有的是有硬件限制无法升级的情况。
2、Android GRF 起源
搜索看了下，GRF并不是Android14才有的，之前就有了。
Android GRF（Google Requirements Freeze）即谷歌需求冻结，是谷歌于 2020 年推出的一项策略。
（1）过程:
Project Treble 的不足：谷歌在 2017 年的 Android 8 时代推出了 Project Treble，
其将 Android 的供应商支持框架（Vendor）与 Android 本体解耦，
解除了驱动与系统版本的 “挂钩” 机制，但没有从根本上解决 Android 生态的碎片化问题，
还增加了芯片厂商维护多种 Vendor 版本的工作量。
Android 11 起实施该策略后，Vendor 版本被冻结，
谷歌承诺为各 Vendor 版本提供 N+3 的特性向后兼容。
比如骁龙 888 的 Vendor 版本适配 Android 11，
谷歌会保证在 Android 14 时，该 Vendor 版本仍能启动并通过兼容性测试。
虽然Android8有这个思路，但是真正实行是Android11；
但是也未大范围推广，估计Android14之后的版本会更多推广。
（2）减少开发复杂性
通过需求冻结提供更稳定和可预测的软件开发环境，帮助设备制造商提前规划并优化他们的资源，
减少开发复杂性，加快产品上市速度，并提高最终产品的质量和用户体验。
(3)影响
积极方面：对于芯片厂商来说，显著降低了其工程成本。
消极方面：谷歌必须保证 Android 新版本与先前 Vendor 版本的兼容性，
难以做到涉及硬件支持的特性在相同版本 Android 上体验一致。
扫一扫
556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
