2018-07-03

一,环境准备工作

1， jdk环境

a，cts上：在android n之前需要jdk 1.7环境即可，在android n上需要使用jdk 1.8

b，在gts4.1-r1之后都需要使用jdk 1.8的环境

可以使用导入临时环境变量的方法将当前窗口的jdk环境配置成jdk 1.8，使用如下命令即可：

export JAVA_HOME=（此处填写jdk所在路径例如：/usr/lib/jvm/jdk1.8.0_121）

export CLASSPATH=.:JAVA_HOME/lib/dt.jar:JAVA_HOME/lib/tools.jar

export PATH=JAVA_HOME/bin:PATH

2，cts，gts 工具包

从google官网上获取当前最新的cts以及gts工具包

https://source.android.com/compatibility/cts/downloads

[图片上传失败...(image-be2f95-1530601444956)]

如上图所示，先选择android 版本号，在进行下载最新的工具，正常我们都下载ARM的工具包

由于google的cts工具有截止时间，故需要经常上该网站查看最新的版本，在该网站下载的工具都是最新的

3，media 包

跑cts的时候，需要在手机中导入media的包以支持跑media相关的case，该media资源包也在https://source.android.com/compatibility/cts/downloads 进行下载，下载解压后只要运行其中的copy_media.sh脚本即可自动拷贝进手机了（需要赋予该脚本执行权限之后才可以执行），若需要拷贝至多个手机在一台电脑上，只需要在脚本后面加all例如：

./copy_media.sh all

这样就可以将media包分别拷贝到当前连接的所有手机中

4，手机设置

基本电脑环境配置好之后，需要进行手机上的配置，具体详细的可以查询如下网站：

https://source.android.com/compatibility/cts/setup

也可以进行查看附件的文档 [图片上传失败...(image-5b0c2e-1530601444956)] ，建议去网站上查看，因为网站上比较准确，而且实时更新

二 执行CTS/GTS的一些命令

1，整跑

整跑cts的命令非常简单如下：

run cts

当前只有一台手机的时候直接使用该命令即可，若多台手机直接使用

run cts -s devicename (devicename 为使用adb devices 后查看到的devices name)

若使用多台手机跑cts 则需要使用shards 进行跑，如下：

run cts --shards n -s devicesname1 -s devicesname2 ....

shards 后面跟随的参数为参与整跑的手机数量

2，retry 未完成的报告

使用l r查看需要retry的报告的session id ，如下：

[图片上传失败...(image-6adf8b-1530601444956)]

使用如下命令：

run cts --retry sessionid -s devicesname

其中需要注意:

1),retry的手机必须为之前报告的手机或者手机之一

2),跑的两个版本必须一样(fingerprint必须一致)

3，单跑的命令

例如报告如下：

[图片上传失败...(image-1ecd47-1530601444956)]

我们跑该case的命令如下：

run gts -m GtsMediaTestCases -t com.google.android.media.gts.WidevineGenericOpsTests#testL1

若我们需要跑单包，则

run cts -m modoulesname即可，moudlesname 在报告的上可以查看

具体的详细命令可以通过终端help命令查看，如下：

[图片上传失败...(image-33bcb0-1530601444956)]

gts的命令和cts基本一致，只是需要将cts改成gts即可，如下：

run gts -m modulesname

三，送测需求

1，asus android N的送测，需要如下文件：

1),CTS报告以及waive link（若有fail项且wailve的情况）

2),GTS报告以及waive link（若有fail项且wailve的情况）

3),CTS-V报告以及waive link（若有fail项且wailve的情况）

4),AFW报告

5),check list报告（该checklist为asus特有的，满足要求后可以大概率获得google 的approve）

2，联想的送测和asus的不太一致。具体文件清单如下：

1),CTS报告以及waive link（若有fail项且wailve的情况）

2),GTS报告以及waive link（若有fail项且wailve的情况）

3),CTS-V报告以及waive link（若有fail项且wailve的情况）

4),AFW报告

5),FRP （该需求为联想特有，主要为开机向导截图）：

[图片上传失败...(image-dcd3c0-1530601444956)]

6),手机prop属性的文件

其中1-4的文件为google需求的文件，后续为客户特有的一些文件

3，关于cts，gts报告送测规则：

由于android 升级到N之后，cts的case大大的增加了，在M上只有十几万条case（6.0-r12上127000+条左右），然而在N上有430000+条的case，导致整跑的难度也大大的增加了，导致目前送测规则也发生了变化:

M的送测规则：由于M的工具不支持retry的命令，故需要重新建立plan进行retry

ps：M的整跑命令为run cts --plan CTS ，CTS代表整跑的plan，之后需要将上一次的fail项重新建立一个plan，然后进行跑该plan，且最多只能建立三个plan就不能建立了（由于超过三个plan会有大概率被google reject）。

N的送测规则：android N支持retry的命令，故直接将最后一份retry 全pass的报告送测即可，由于asus需要确认报告的可靠性，故他们需要完整的retry报告

四，关于本次ZQL1516 CTS送测的一些问题

1，CTS

本次cts送测过程十分曲折，原计划2017/4/4需要将首轮全pass的报告给到asus，由于种种原因，导致最后5/15才将首轮报告送测出去，下面详细列举本次cts报告的问题：

1),整跑卡住，并卡在asus卡机界面，cts卡在同一个包内

该问题最终花费十个工作日左右才解决，最终判断出根因是由于asus simcontact.apk以及在frameworks/base/中的修改导致无法继续整跑

2),camera相关问题

由于camera的HAL1以及HAL3的切换问题，导致camera的相关fail项，最终我们将camera切换至HAL1，同步关闭一批问题，然后剩下几个问题同步解决

3),media相关的问题

在最终MP版本软件上，修改硬解码相关配置文件，导致cts media相关的fail

总结：在重要版本发布的关键节点上，我们对camera，media相关的修改，需要将camear以及media相关的包都跑一遍，以防止影响重要版本发布

2，GTS

本次送测过程中，GTS遇到的重大问题就是widevine相关的问题，由于导致secboot，widevine相关的文件需要进行单独签名导致的相关fail

最终将对应的文件进行单独签名后，导入手机即可pass

3，CTS-V

CTS-V的fail项主要和测试手法相关，关于测试手法，我们需要详细阅读工具给的操作步骤，正常解决的cts-v的问题非常少，只有一两个，大部分的问题都是由于测试手法造成的，具体测试手法可以查看附件[图片上传失败...(image-c3a3ac-1530601444956)]

4，Checklist

由于之前和asus合作较少，导致我们一开始忽略了Checklist相关的内容，该项内容主要是为了提升google approve 的概率而需要检查的测试项，符合该checklist的东西之后能够大概率的通过google approve，例如：

[图片上传失败...(image-1c9b8f-1530601444954)]## 一,环境准备工作

1， jdk环境

a，cts上：在android n之前需要jdk 1.7环境即可，在android n上需要使用jdk 1.8

b，在gts4.1-r1之后都需要使用jdk 1.8的环境

可以使用导入临时环境变量的方法将当前窗口的jdk环境配置成jdk 1.8，使用如下命令即可：

export JAVA_HOME=（此处填写jdk所在路径例如：/usr/lib/jvm/jdk1.8.0_121）

export CLASSPATH=.:JAVA_HOME/lib/dt.jar:JAVA_HOME/lib/tools.jar

export PATH=JAVA_HOME/bin:PATH

2，cts，gts 工具包

从google官网上获取当前最新的cts以及gts工具包

https://source.android.com/compatibility/cts/downloads

[图片上传失败...(image-b08b5c-1530601446496)]

如上图所示，先选择android 版本号，在进行下载最新的工具，正常我们都下载ARM的工具包

由于google的cts工具有截止时间，故需要经常上该网站查看最新的版本，在该网站下载的工具都是最新的

3，media 包

跑cts的时候，需要在手机中导入media的包以支持跑media相关的case，该media资源包也在https://source.android.com/compatibility/cts/downloads 进行下载，下载解压后只要运行其中的copy_media.sh脚本即可自动拷贝进手机了（需要赋予该脚本执行权限之后才可以执行），若需要拷贝至多个手机在一台电脑上，只需要在脚本后面加all例如：

./copy_media.sh all

这样就可以将media包分别拷贝到当前连接的所有手机中

4，手机设置

基本电脑环境配置好之后，需要进行手机上的配置，具体详细的可以查询如下网站：

https://source.android.com/compatibility/cts/setup

也可以进行查看附件的文档 [图片上传失败...(image-b92e0f-1530601446496)] ，建议去网站上查看，因为网站上比较准确，而且实时更新

二 执行CTS/GTS的一些命令

1，整跑

整跑cts的命令非常简单如下：

run cts

当前只有一台手机的时候直接使用该命令即可，若多台手机直接使用

run cts -s devicename (devicename 为使用adb devices 后查看到的devices name)

若使用多台手机跑cts 则需要使用shards 进行跑，如下：

run cts --shards n -s devicesname1 -s devicesname2 ....

shards 后面跟随的参数为参与整跑的手机数量

2，retry 未完成的报告

使用l r查看需要retry的报告的session id ，如下：

[图片上传失败...(image-57921e-1530601446495)]

使用如下命令：

run cts --retry sessionid -s devicesname

其中需要注意:

1),retry的手机必须为之前报告的手机或者手机之一

2),跑的两个版本必须一样(fingerprint必须一致)

3，单跑的命令

例如报告如下：

[图片上传失败...(image-7cbe2e-1530601446495)]

我们跑该case的命令如下：

run gts -m GtsMediaTestCases -t com.google.android.media.gts.WidevineGenericOpsTests#testL1

若我们需要跑单包，则

run cts -m modoulesname即可，moudlesname 在报告的上可以查看

具体的详细命令可以通过终端help命令查看，如下：

[图片上传失败...(image-6dd95f-1530601446495)]

gts的命令和cts基本一致，只是需要将cts改成gts即可，如下：

run gts -m modulesname

三，送测需求

1，asus android N的送测，需要如下文件：

1),CTS报告以及waive link（若有fail项且wailve的情况）

2),GTS报告以及waive link（若有fail项且wailve的情况）

3),CTS-V报告以及waive link（若有fail项且wailve的情况）

4),AFW报告

5),check list报告（该checklist为asus特有的，满足要求后可以大概率获得google 的approve）

2，联想的送测和asus的不太一致。具体文件清单如下：

1),CTS报告以及waive link（若有fail项且wailve的情况）

2),GTS报告以及waive link（若有fail项且wailve的情况）

3),CTS-V报告以及waive link（若有fail项且wailve的情况）

4),AFW报告

5),FRP （该需求为联想特有，主要为开机向导截图）：

[图片上传失败...(image-60327c-1530601446495)]

6),手机prop属性的文件

其中1-4的文件为google需求的文件，后续为客户特有的一些文件

3，关于cts，gts报告送测规则：

由于android 升级到N之后，cts的case大大的增加了，在M上只有十几万条case（6.0-r12上127000+条左右），然而在N上有430000+条的case，导致整跑的难度也大大的增加了，导致目前送测规则也发生了变化:

M的送测规则：由于M的工具不支持retry的命令，故需要重新建立plan进行retry

ps：M的整跑命令为run cts --plan CTS ，CTS代表整跑的plan，之后需要将上一次的fail项重新建立一个plan，然后进行跑该plan，且最多只能建立三个plan就不能建立了（由于超过三个plan会有大概率被google reject）。

N的送测规则：android N支持retry的命令，故直接将最后一份retry 全pass的报告送测即可，由于asus需要确认报告的可靠性，故他们需要完整的retry报告

四，关于本次ZQL1516 CTS送测的一些问题

1，CTS

本次cts送测过程十分曲折，原计划2017/4/4需要将首轮全pass的报告给到asus，由于种种原因，导致最后5/15才将首轮报告送测出去，下面详细列举本次cts报告的问题：

1),整跑卡住，并卡在asus卡机界面，cts卡在同一个包内

该问题最终花费十个工作日左右才解决，最终判断出根因是由于asus simcontact.apk以及在frameworks/base/中的修改导致无法继续整跑

2),camera相关问题

由于camera的HAL1以及HAL3的切换问题，导致camera的相关fail项，最终我们将camera切换至HAL1，同步关闭一批问题，然后剩下几个问题同步解决

3),media相关的问题

在最终MP版本软件上，修改硬解码相关配置文件，导致cts media相关的fail

总结：在重要版本发布的关键节点上，我们对camera，media相关的修改，需要将camear以及media相关的包都跑一遍，以防止影响重要版本发布

2，GTS

本次送测过程中，GTS遇到的重大问题就是widevine相关的问题，由于导致secboot，widevine相关的文件需要进行单独签名导致的相关fail

最终将对应的文件进行单独签名后，导入手机即可pass

3，CTS-V

CTS-V的fail项主要和测试手法相关，关于测试手法，我们需要详细阅读工具给的操作步骤，正常解决的cts-v的问题非常少，只有一两个，大部分的问题都是由于测试手法造成的，具体测试手法可以查看附件[图片上传失败...(image-3a097-1530601446494)]

4，Checklist

由于之前和asus合作较少，导致我们一开始忽略了Checklist相关的内容，该项内容主要是为了提升google approve 的概率而需要检查的测试项，符合该checklist的东西之后能够大概率的通过google approve，例如：

[图片上传失败...(image-26f8bd-1530601446494)]

该项测试检查的是手机的dppi值以及屏幕的属性，需要和cts工具读取的手机参数一致才能pass，故该测试项fail需要驱动屏幕的owner进行修改

该项测试检查的是手机的dppi值以及屏幕的属性，需要和cts工具读取的手机参数一致才能pass，故该测试项fail需要驱动屏幕的owner进行修改