Android16 EDLA 认证测试CTS问题分析解决

文章目录

[Android16 EDLA 认证测试CTS问题分析解决](#Android16 EDLA 认证测试CTS问题分析解决)
- 一、前言
- 二、EDLA认证项分析解决
- - 1、修改系统签名和系统应用签名
  - - [比如 CtsBionicTestCases 模块报错：](#比如 CtsBionicTestCases 模块报错：)
  - 2、烧录key
  - - [CtsDevicePolicyManagerTestCases 模块报错：](#CtsDevicePolicyManagerTestCases 模块报错：)
  - 3、修改selinux权限
  - - [比如CtsSecurityHostTestCases 模块报错：](#比如CtsSecurityHostTestCases 模块报错：)
  - 4、查看关键字
  - - [比如：CtsWindowManagerDeviceDisplay 模块报错：](#比如：CtsWindowManagerDeviceDisplay 模块报错：)
    - [CtsInputTestCases 模块报错：](#CtsInputTestCases 模块报错：)
  - 5、分析代码
  - 6、回退代码验证
- 三、其他
- - 1、小结
  - [2、Android16 EDLA 认证测试CTS过程介绍](#2、Android16 EDLA 认证测试CTS过程介绍)
  - [3、Android EDLA 认证测试内容详解](#3、Android EDLA 认证测试内容详解)
  - [4、Android EDLA 认证提测前的基本开发和准备简要说明](#4、Android EDLA 认证提测前的基本开发和准备简要说明)

一、前言

Android EDLA 认证测试的主要内容是 CTS、GTS、VTS ，还有一些其他的。

Android16 的CTS的测试项有900多个模块，总共有两百九十多万项需要测试。

其中有个测试模块 CtsDeqpTestCases ，包含了两百八十多万项，这个模块基本不会报错；

剩下的九百多个模块，有的有上千项的，有的只有几十或者几项的；

如下图所示：

之前有讲解如何测试和查看这些报错的模块内容。

本文主要讲解CTS的某些Failed项解决思路。

二、EDLA认证项分析解决

下面是分析解决的几种参考思路。

1、修改系统签名和系统应用签名

比如 CtsBionicTestCases 模块报错：

虽然看不懂这个报错，但是我看BTS测试有个com.andorid.runtime 应用签名的报错；

查看com.andorid.runtime 就是 bionic 模块的，所以我后续是重新生成并替换了bionic 模块的签名文件解决的这个项报错。

2、烧录key

CtsDevicePolicyManagerTestCases 模块报错：

这个看起来是和系统key相关的。

烧录Google key（ ATTESTTATION-KEY ），上传设备的csr.json到google服务器，联网后能pass该项报错。

id att key + widevine key 是上传设备csr.json后，在设备联网后，自动安装的key。

3、修改selinux权限

比如CtsSecurityHostTestCases 模块报错：

还有些：

复制代码

AssertionError: Found illegal SELinux denial(s): avc: denied { read } for name="cache" dev="dm-8" ino=96

这些都是可以修改相关的.te文件解决selinux权限问题的。

4、查看关键字

比如：CtsWindowManagerDeviceDisplay 模块报错：

一般报错主要查看右边部分内容，右边有显示90°旋转和尺寸显示的报错。

这个是因为我的Tv系统默认是设置了强制横屏，所以需要把系统framework代码中强制横屏的代码去除就行。

一般 WindowManager的Failed项主要是修改了： frameworks\base\services\core\java\com\android\server\wm 导致。

可以设置一个prop属性，在测试CTS的时候，去除wm目录下自定义的修改；

否则很多预期的结果会不相符所以报Failed项。

CtsInputTestCases 模块报错：

这种按键值报错，一般是因为我们修改了按键的kl文件导致。

去除通用的Generic.kl.aosp 文件相关修改，如果需要新增的按键，可以在table下的专用kl文件下面修改。

还有些是键值替换会报错的情况，自定义回车变成换行键值。

CtsWallpaperTestCases 模块报错：

这个是壁纸测试报错；

也是可以使用prop属性设置，测试的山时候去除frameworks\base\services\core\java\com\android\server\wallpaper\WallpaperManagerService.java 的自定义修改，就可以规避这个报错。

其他方案上修改后是可以全部pass的，但是目前311D2 AN16 上[instant]的报错没有消除，还不知道如何处理。

还有很多其他项报错是可以通过查看关键字，看出具体报错内容的。

5、分析代码

其实不管是 CTS 哪个模块的报错都是可以查看代码分析的。

代码在系统源码的位置是：release.cts的不同目录下面.

比如下面这个Failed项 CtsWindowManagerDeviceBackNavigation 报错：

上面左边是表示报错的具体位置，右边是报错的具体信息和堆栈信息。

报错的具体位置中：

复制代码

android.server.wm.backnavigation.OnBackInvokedCallbackGestureTest#invokesCallback_cancelled

#号前面的表示包名和类名，右边是方法名

所以搜索报错位置的命令是：

复制代码

//搜索类名或者方法名：
find . -name XXX.java 
find . -name *.java | xargs grep -nr XXX

//具体报错搜索示例：
find . -name OnBackInvokedCallbackGestureTest.java 
find . -name *.java | xargs grep -nr invokesCallback_cancelled

搜索可以找到哪行的报错：

复制代码

release/cts$ ls
Android.bp  backported_fixes  CleanSpec.mk  development           error_prone_rules_tests.mk  helpers        libs    PREUPLOAD.cfg      suite         tests
apps        build             common        error_prone_rules.mk  flags                       hostsidetests  OWNERS  run_unit_tests.sh  test_defs.sh  tools
cts$ find . -name *.java | xargs grep -nr invokesCallback_cancelled
./tests/framework/base/windowmanager/src/android/server/wm/backnavigation/OnBackInvokedCallbackGestureTest.java:214:    public void invokesCallback_cancelled() throws InterruptedException {
release/cts$

查看具体代码：

查看代码可以看到里面是有很多断言判断的；

比如期待true，返回false，就是Failed；

其他某个数值，但是返回另外一个数值，也会Failed。

这个可以看下它断言的具体代码内容，这些都是Java代码。

虽然很多逻辑不一定好追，但是有些是可以通过代码逻辑分析出解决方案的。

这些代码都是对应CTS套件中的APK的，虽然系统编译的时候不编译cts的代码，

并且有些堆栈报错代码的行数是不对，但是断言代码的逻辑有参考意义的。

另外cts这些模块在源码是可以mm编译出apk的，估计可以替换CTS套件测试的某项apk，进行测试调试；

我是没有这样修改过，有兴趣的可以试试。

6、回退代码验证

虽然上面分析了一些情况，但是还有些是代码分析不出来，从关键字也无法分析的Failed项。

这种估计需要查看第一版是否存在这样的问题，有些是需要咨询厂家协助分析解决的；

有些是后期自己修改出来的，需要回退对策，确认哪个对策影响到的；

三、其他

1、小结

这里只是讲解了CTS几百个模块中某些情况的修改解决思路，主要有：

复制代码

（1）修改系统签名和系统应用签名
（2）烧录key
（3）修改selinux权限
（4）查看关键字
（5）查看源码
（6）回退代码

有些问题是需要添加一个prop属性，在测试CTS的时候使用原生逻辑进行规避操作的；

还有一些就是经验获取其他手段解决和规避这些问题了。

这些Failed项的处理很多我也还不熟悉，后续有机会搞个详细点的解决思路。

2、Android16 EDLA 认证测试CTS过程介绍

Android EDLA 认证测试的主要内容是 CTS、GTS、VTS ，还有一些其他的。

Android EDLA 认证项中CTS是数量最多的，因为很多framework或者系统应用的修改都会可能导致报错。

https://blog.csdn.net/wenzhi20102321/article/details/155891248

3、Android EDLA 认证测试内容详解

EDLA（Enterprise Device Licensing Agreement）是 Google 专为企业级 Android 设备设计的认证协议，

是 MADA（Mobile Application Distribution Agreement）的补充，

特别针对两类设备：无电池设备（如工业控制终端、数字标牌）和屏幕尺寸大于 18 英寸的设备（如交互式平板、OPS 电脑），屏幕尺寸最大可达 70 英寸。

核心目标：确保设备能安全集成 Google 服务，支持企业级管理功能，满足商业环境的高安全性和管控需求。

原文链接：https://blog.csdn.net/wenzhi20102321/article/details/155618324

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

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

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

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

原文链接：https://blog.csdn.net/wenzhi20102321/article/details/154583182