一,环境准备工作
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进行修改
