Android EDLA 认证提测前的基本开发和准备简要说明

Android EDLA 认证提测前的基本开发和准备说明

一、前言

本文的EDLA提测并不是实验中送测，只是内部简单开发后能进行内部专门EDLA全项测试。

因为认证测试即使整天测试也需要1-2周的时间，所以一般由专门测试组进行测试，开发人员主要进行修改即可。

一般是系统改动较少的情况，内部提测一版认证测试，可以对比是否是自身修改导致的认证Failed项。

这里主要说明一下EDLA认证内部提测大概流程，有兴趣的可以收藏看看。

二、提测准备

1、获取源码正常编译通过

一般是从供应商获取到Android源码，获取不同方案对应的编译指令，确保编译OK。

2、下载并导入Google套件，GMS和mainline

合入google的GMS包和mainline包，才能够使用完整的google服务框架。

（1）GMS包下载：

https://docs.partner.android.com/gms/building/integrating/gms-download?hl=zh-cn

进入下载链接找到对应Android版本的GMS包即可。

GMS配置：

GMS的配置如下图，左侧点到配置GMS Makefile按照google官网的说明一步步配置即可。

（2）下载mainline包

进入网站后然后选择下载mainline包，注意，这里需要和原厂沟通下载几月份的mainline包，因为mainline和GMS不同，还需要进行一系列的适配，这些都需要原厂提供给我们Patch，mainline包的下载对比gms包较为复杂，

选择好maline包后，我们这里需要下载的是Preload里的，一般下载最新的版本，然后点击包含的内容，选择版本后，然后会跳转到CI界面，这里需要搜索partner，然后就能下载maline包了，如下列图片：

Mainline包的配置：

下载好maline包后按照包内对应目录进行新增或替换即可。

3、烧录key

（1）一般需要烧录的key

当代码移植这块完成后就要准备第一轮提测，这时候需要先烧录好Key，否则会有很多报错，需要烧录的key有：

 widevine key 						（Widevine 数字版权管理密钥, 加密视频内容）hdcp_tx14_key 						(HDCP 1.4 版本 发送端（TX）密钥，高清视频包含)hdcp_rx14_key 						(HDCP 1.4 版本 接收端（RX）密钥)hdcp_tx22_key		 				(HDCP 2.2 版本 发送端（TX）密钥)hdcp_rx22_key		 				(HDCP 2.2 版本 接收端（RX）密钥)keymaster3_key 					（Keymaster 3 硬件安全主密钥,保护应用数据存储）keymaster3_attest_dev_id_box key 	（Keymaster 3 设备认证身份密钥，Google应用校验）

其中，公版不烧widevine key的情况下是L3标准，不烧key会影响Google服务的相关测试。

据AML回复，*playready_private_key已不需要烧录*。

所以，GTS测试，A311D2 Android T需要烧录上述7个key；

VTS测试，A311D2 Android T需要烧录上述7个key；

CTS测试，A311D2 Android T需要烧录keymaster3等2个key。

key文件可以是.bin后缀的，也可以是.en后缀的文件。

一般情况高清视频负责接收就行了，所以tx14、tx22 有些方案是不烧录的。

所以关键的是五个key：

 widevine keyhdcp_rx14_key hdcp_rx22_keykeymaster3_key keymaster3_attest_dev_id_box key 	

这些key是如何切换获取的可以咨询供应商，一般是有专门工具的。

关于烧key流程，请参考Amlogic提供的烧key文档《BDS Android Provision Key User Guide (0.5)_CN.pdf》。

下面三个都是最重点的key，hdcp那些只会影响视频播放，Google 那些重要key未烧录会导致无法登录谷歌账号。

（2）目前Android16通用必须烧录的key说明

全平台通用，必须需要烧录的key:

1.google key（KEYMASTER3_KEY）
2.id att（keymaster3_attest_dev_id_box key）
3.widevine key

A14之前以上三个key都是需要烧录key文件，
A14之后，id att key + widevine key是需要通过指令提取生成csr.json文件（不同方案获取不同，需要供应商支持），
然后把csr.json上传到google对应的网站，联网VPN后google自动会下载生成bin文件在设备的某个分区 ;

也就是说上面三个重要key，只有google key（KEYMASTER3_KEY） 需要自己烧录，

另外两个可以联网系统会根据上传的设备信息，自己下载key都本机设备。

（3）验证id att + widevine key是否正常

如何校验下载的 id att + widevine key是否正常：

①安装供应商提供的drminfo.apk

该应用能看到设备的基本信息：

查看右边的System ID值，比如这里是 39999

这个值是公司立项的设备信息ID，可以通过立项申请通过信息中查看到：

②查看项目立项信息

这个39999 就是整个项目的设备系统固定的 widevine key 校验System ID。

对比drminfo 的System ID 立项信息的 widevine System ID，一致就是OK的。

如何申请key和项目立项：

1、申请 EDLA 认证 KEY 需要准备 GTS 的 GtsEdiHostTestCases 模块报告（一般都pass）、device ID file 和 PGP key；
2、需要google的partner账号去访问google的partner相关网站，此外还需要 google 给我们开通一系统权限；
3、把相关文件信息提交，验证通过后，就可以收到通知显示立项基本信息。

（4）查询当前系统已烧录的key

①查看可以烧录的key

t7_an400:/ $ tee_provision --list 
Amlogic Provision Key Type List: [ 0] 0x11 WIDEVINE_KEY 
[ 1] 0x21 PLAYREADY_PRIVATE_KEY 
[ 2] 0x22 PLAYREADY_PUBLIC_KEY 
[ 3] 0x31 HDCP_TX14_KEY 
[ 4] 0x32 HDCP_TX22_KEY 
[ 5] 0x33 HDCP_RX14_KEY 
[ 6] 0x34 HDCP_RX22_WFD 
[ 7] 0x35 HDCP_RX22_FW 
[ 8] 0x36 HDCP_RX22_FW_PRIVATE 
[ 9] 0x41 KEYMASTER_KEY 
[10] 0x42 KEYMASTER3_KEY 
[11] 0x43 KEYMASTER3_ATTEST_DEV_ID_BOX 
[12] 0x51 EFUSE_KEY 
...

②确认某个是否烧录成功。

一般每个烧录的key都查询一下：
t7_an400:/ # tee_provision -q -t 0x31 
[PROVISION-CA] query [0x31 HDCP_TX14_KEY] provisioned in TEE, length = 544 
bytes. 
t7_an400:/ # tee_provision -q -t 0x32 
[PROVISION-CA] query [0x32 HDCP_TX22_KEY] provisioned in TEE, length = 477 
bytes. 
t7_an400:/ # tee_provision -q -t 0x33 
[PROVISION-CA] query [0x33 HDCP_RX14_KEY] provisioned in TEE, length = 544 
bytes. 
255|t7_an400:/ # tee_provision -q -t 0x11  //not provisioned 证明未烧录该key
[PROVISION-CA] query [0x11 WIDEVINE_KEY] not provisioned. 
8|t7_an400:/ # 
其他的：
0x11、0x31、0x32、0x33、0x34、0x42、0x43

0x11 WIDEVINE_KEY +0x43 KEYMASTER3_ATTEST_DEV_ID_BOX 是系统自动下载的，需要连接VPN网络；

并且已经把本机生成的crs.json文件上传到Google专门网页，才会自动烧录这个WIDEVINE+id att key。

（5）烧录key命令：

这里是烧录不会自动下载的key文件。

以HDCP 1.4 RX为例：

1.将HDCP 1.4 Key push到主板sdcard或者放入U盘。

2.烧录HDCP 1.4。

//命令： 
console:/ tee_provision -i /sdcard/Hdcp14RX0.enc.factory-user.enc -t 0x33
//tee_provision命令在烧录的时候可以不用带-t参数，直接-i加key就行了，系统会自动判断烧录的是什么
key
//或者命令： 
console:/ tee_provision -i /sdcard/Hdcp14RX0.enc.factory-user.enc

烧录成功的提示：

如出现以下错误:

手动创建HDCP_RX14_KEY文件：

console:touch /mnt/vendor/factory/HDCP_RX14_KEY

重新执行一次烧录命令:

console:/ tee_provision -i /sdcard/Hdcp14RX0.enc.factory-user.enc -t 0x33

大部分情况是不会烧录失败的，如果不是上面的错误可以自行搜索解决。

（6）删除烧录的KEY

#tee_provision -d -t HDCP_TX14_KEY//-t 后面跟KEY的类型 
#tee_provision -d -t 0x31 //删除HDCP TX 1.4的KEY

删除后，可以查询是否还有这个key的信息。

系统加载GMS+mainline+烧录key，理论上就可以开始进行EDLA认证测试了；

但是某些具体的认证测试项，是需要其他文件和镜像搭配才能测试的，所以还需要提供另外一些文件；

4、内部认证提测自检表：

这个是简单参考的EDLA自检内容。有些公司会做得更加详细。

一般是需要全部ok才能提测的，如果遇到某些问题，内部可以跳过某项内容。

adb、Key这些肯定是要没有问题的。

5、软件提测版本

（1）EDLA软件提测前确认是否开启selinux

selinux需要改为增强模式（enforcing）。

（2）软件后续提测需要分别上传user版本和userdebug版本软件

STS测试用userdebug版本，其它测试用user版本；

GTS测试前需要GSI文件、

VTS测试前需要vendor_boot-debug.img和Google下载的gsi的system.img。

（3）Key文件

提供相关的key文件和说明文档。

三、其他

1、小结

上面只是简单流程，具体操作可能会有不同；

并且Google的网址内容一直在更新；需要不停的摸索。

2、Android16烧录镜像更新说明

Android16 烧录system、vendor_boot镜像可能会失败，下面是的可以参考：

（1）Android13 的烧录方式

adb reboot bootloader
fastboot flashing unlockfastboot reboot fastboot
fastboot delete-logical-partition product
fastboot delete-logical-partition product_a
fastboot delete-logical-partition product_b
fastboot flash system system.img
fastboot flash vendor_boot vendor_boot-debug.imgfastboot -wfastboot reboot 

在Android16 上烧录上面的镜像会报错或者失败！！！

（2）Android16的烧录方式

① 刷入system.img与vendor_boot-debug.img指令：

adb reboot-bootloader
fastboot flashing unlockfastboot flash vendor_boot_a vendor_boot-debug.img
fastboot flash vendor_boot_b vendor_boot-debug.imgfastboot reboot fastboot //fastbootd模式fastboot erase system
fastboot flash system system.img
fastboot -w
fastboot reboot

其实是次序不同，原理不太清楚。

②单刷vendor_boot-debug.img指令：

adb reboot-bootloader
fastboot flashing unlockfastboot flash vendor_boot_a vendor_boot-debug.img
fastboot flash vendor_boot_b vendor_boot-debug.imgfastboot -w
fastboot reboot

③单刷system.img指令：

adb reboot-bootloader
fastboot flashing unlock
fastboot reboot fastbootfastboot erase system
fastboot flash system system.img
fastboot -w
fastboot reboot 

可以看到system烧录需要进入fastbootd模式，vendor_boot 在fastboot摸索烧录就可以了。
上面命令也是仅供参考，可能有些系统不一样。
有的说是物理分区和抽象分区的区别，有兴趣的自行了解。