Android16 【GSI】CtsMediaCodecTestCases等一些列Media测试存在Failed项
文章目录
- [Android16 【GSI】CtsMediaCodecTestCases等一些列Media测试存在Failed项](#Android16 【GSI】CtsMediaCodecTestCases等一些列Media测试存在Failed项)
一、前言
Android EDLA最近测试爆一大堆GSI CtsMediaXXXCases 的报错,刚开始不确定是哪里修改导致的问题。
后面多看一些日志和回退一些对策确认是Media编解码修改导致。
这些报错不仅在CTS 测试有,GSI 测试也有;
CTS测试通过后,GSI是不一定测试通过的;
因为测试GSI已经烧录了Google提供的system.ing会去除部分framework的修改;
【CTS】一些列Media测试存在Failed项:
https://blog.csdn.net/wenzhi20102321/article/details/157763004
修改GSI前可以先看看CTS的修改;
其实不烧录GSI镜像,也是可以使用命令测试GSI的测试项;只是不一定准确;
测试CTS和GSI测试项,都是使用同一个套件,只是测试的命令会有点不同;
烧录GSI镜像后,系统prop属性基本都清除了,那么需要如何修改判断呢?
本文主要一些分析参考,有遇到类似的可以看看。
二、分析修改
1、报错查看
一些列GSI报错如下:

其实GSI只是烧录了gsi固件,具体测试的套件还是cts的,所以报错的模块也是cts的。
部分报错如下:
CtsMediaRecorderTestCases:

CtsMediaMiscTestCases:

CtsMediaEncoderTestCases:

CtsMediaDecoderTestCases:

CtsMediaAudioTestCases:

CtsMediaV2TestCases:

上面只能看出一些大概测试意图,看不出具体报错信息,
如果要看具体报错堆栈,需要查看具体报告或者重测该项查看result中的html文件报告;
比如:

能看到更多一点堆栈信息,再看logcat日志估计能看到更多相关信息。
上面的报错可能是和修改如下代码会导致:
//这个是AML方案的
vendor/amlogic/common/codec2/vendorcomponents/videoencoder/C2VencComp.cpp
vendor/amlogic/common/codec2/vendorcomponents/videoencoder/C2VencIntfImpl.cpp
修改一下参数值比如:
C2Color::MATRIX_UNSPECIFIED 变成 C2Color::MATRIX_BT709 或者 C2Color::MATRIX_BT601
这个主要是修改4K编解码参数或者优化视频转码与优化编码性能会涉及到的代码;
比如:安兔兔跑分视频转码失败,需要进行优化系统编解码,就需要修改上面的代码。
因为烧录GSI主要就是去掉system的一些应用和属性、framework的部分修改;
但是cpp部分很多逻辑还是存在的,所以会造成一些Failed项。
2、分析修改
虽然烧录GSI镜像后,安装卸载应用的一些监听没了,无法设置自定义prop属性了;
但是烧录gsi镜像后,系统属性 ro.product.system.device 会变成 generic
console:/ $ getprop | grep system.device
[ro.product.system.device]: [t7_an400] //烧录gsi会变成:generic
console:/ $
可以在代码中通过这个判断属性可以判断是否跳过一些自定义修改的逻辑代码;
比如:
vendor/amlogic/common/codec2/vendorcomponents/videoencoder/C2VencIntfImpl.cpp
char ctsValue[128] = {0};
char gsiValue[128] = {0};
property_get("persist.skg.isinstall.cts", ctsValue, "false"); //自定义cts 属性判断
property_get("ro.product.system.device", gsiValue, "false"); //gsi 属性判断
if((strcmp(ctsValue, "true") == 0) || (strcmp(gsiValue, "generic") == 0)){ //原生逻辑
} else { //自定义的代码功能逻辑
}
这个只是参考修改。
三、其他
1、小结
其实只要影响到原生的流程就可能会爆Failed项错误;
修改编解码的代码可能会报很多cts和gsi的Failed项错误;
gsi解决方法就是:去除该功能或者通过prop属性ro.product.system.device测试的时候跳过某项功能逻辑。
2、Android EDLA CTS、GTS等各项测试命令汇总
上面的不同测试类型,需要下载不同的测试套件进行测试,测试后会有测试报告。
不同的测试项是对应不同的套件的,并且不同的套件,测试的命令也是有差异的;
主要是gsi和sts测试比较特殊。
https://blog.csdn.net/wenzhi20102321/article/details/157554964
3、单刷system.img指令
下面是Android16 烧录system镜像的参考命令:
adb reboot bootloader
fastboot flashing unlock
fastboot reboot fastboot
fastboot erase system
fastboot flash system system.img //从Google网址下载
fastboot -w
fastboot reboot
不管是user版本固件还是debug版本的固件,烧录gsi 的system镜像后,都是会变成user版本系统。