9/6-9/10

一周总结报告

9/6-9/10这一周主要是学习了广播接收与发送BroadcastReceiver、ADB命令与XTS问题处理流程、ContentProvider与ContentResolver的使用、三方问题处理以及完成PDX226项目的自测。

一、         BrocastReceiver

1. 简介

BroadcastReceiver本质上是一个全局监听器，用于监听系统全局的广播消息。（属于系统级的的监听器，它拥有自己的进程，只要存在与之匹配的Intent被广播出来，BroadcastReceiver就会被激发）。BroadcastReceiver用于接收程序（包括用户开发的程序和系统内建的程序）所发出的BroadcastIntent。

1. 广播类型

普通广播：完全异步执行的广播，当发出广播后，广播接收器几乎会在同一时刻接收到广播消息，所以没有先后顺序可言，效率比较高，无法被截断。开发者自己定义 intent 的广播（最常用）。

有序广播：同步执行的广播，广播发出后，会有一个广播接收器接收广播消息，当这个广播接收器中的逻辑执行完毕后广播才会继续传递。有先后顺序，优先级较高的接收器先收到广播消息并且可以截断正在传递的广播，使得后面的接收器无法收到广播消息。有序广播的接收者可以将数据传递给下一个接收者，比如A得到Broadcast后，可以往它的结果对象中存入数据，当Broadcast传给B时，B可以从A的对象中得到A存入的数据。

系统广播：Android内置很多系统级别广播，如手机开机后发一条广播，电池电量发生变化发一条广播等等。

本地广播：可理解为一种局部广播，广播的发送者和接收者都同属于一个 App。相比于全局广播（普通广播），本地广播优势主要是安全性高、效率高。使用这个机制发出的广播只能够在应用程序的内部进行传递，并且广播接收器也只能接收来自应用程序发出的广播。

1. 创建广播

动态注册：在代码中先定义并设置一个 IntentFilter 对象，然后在需要注册的地方调Context.registerReceiver()方法。如果用动态方式注册的BroadcastReceiver的Context对象被销毁时，BroadcastReceiver也就自动取消注册了。

静态注册：在AndroidManifest.xml中用<receiver>标签生命注册，并在标签内用<intent- filter>标签设置过滤器。

注：动态注册广播不是常驻型广播，也就是说广播跟随activity的生命周期。静态注册是常驻型，当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。

1. 生命周期

BroadcastReceiver 的生命周期，从对象调用它开始，到 onReceiver 方法执行完成之后结束。每次广播被接收后都会创建 BroadcastReceiver对象，并在onReceiver 方法中执行完就销毁。如果我们在 Activity 中注册了BroadcastReceiver，当这个 Activity销毁的时候要主动撤销注册否则会出现异常。

二、         ContentProvider

1. 概述

ContentProvider的作用是为不同的应用之间数据共享，提供统一的接口。ContentProvider通过uri来标识其它应用要访问的数据，通过ContentResolver的增、删、改、查方法实现对共享数据的操作。还可以通过注册ContentObserver来监听数据是否发生了变化来对应的刷新页面。

1. Uri

Uri是ContentResolver和ContentProvider进行数据交换的标识。

例：content://com.example. contentprovide.MyContentProvider/words

URI可分为三个部分：

• content://：这个部分是Android的ContentProvider规定的，就像上网的协议默认是http://一样。暴露ContentProvider、访问ContentProvider的协议默认是content://。
• com.example. contentprovide.MyContentProvider：这个部分就是ContentProvider的authorities。系统就是由这个部分来找到操作哪个ContentProvider的。只要访问指定的ContentProvider，这个部分就是固定的。
• words：资源部分（或可称为数据部分）。当访问者需要访问不同资源时，这个部分是动态改变的。

1. ContentResolver

ContentProvider相当于一个“网站”，它的作用是暴露可供操作的数据；其他应用程序则通过ContentResolver来操作ContentProvider所暴露的数据，ContentProvider相当于HttpClient。

方法：insert()、delete()、update()、query()。

1. ContentProvider与ContentResolver的关系

ContentResolver对指定Uri执行CRUD等数据操作，但Uri并不是真正的数据中心，因此这些CRUD操作会委托给该Uri对应的ContentProvider来实现。

通常来说，假如A应用通过ContentResolver执行CRUD操作，这些CRUD操作都需要指定Uri参数，Android系统就根据该Uri找到对应的ContentProvider（该ContentProvider通常属于B应用），ContentProvider则负责实现CRUD方法，完成对底层数据的增、删、改、查等操作，这样就可以让A应用访问、修改B应用的数据了。

三、         ADB命令与XTS问题处理流程

1、ADB命令

adb 命令可用于执行各种设备操作:开关机、安装/卸载应用、文件和设备间的复制、修改屏幕分辨率、keyevent按键等等。通过了 CTS 验证，需要将测试报告提交给 Google，来取得 android market的认证，XTS问题的处理流程。

2、XTS问题处理

CTS 测试的全称是：Compatibility Test Suite，即Google兼容性测试工具。当定制了Android系统的电子产品开发出来后，就必须要通过最新的 CTS 检测，以保证标准的 android  application 能够在该平台下正常运行。通过了 CTS 验证，需要将测试报告提交给 Google，来取得 android market的认证。

CTS包含自动化测试和手动测试两大类：

其中自动化测试有：

（1）CTS/cts-instant（兼容性测试套件）：可管理测试执行情况，利用套件重试功能仅重试失败的测试而不是完整的套件，从而大大减少重新运行所花的时间；

（2）GTS（谷歌移动服务测试）：谷歌移动测试认证；

（3）STS（安全测试套件）：用于测试：安全补丁正确应用、相应的安全漏洞已修复、设备本身无安全漏洞；

（4）CTS-ON-GSI：Android8.0之后，由于平台架构的更改，需要进行GSI版本的CTS测试。

手动测试为：CTS_VERIFIER，主要用于测试那些自动测试系统无法测试的功能。

XTS问题处理方式有5种：

（1）下载客户版本复测，确认是否为环境问题；

（2）MTK online查询确认是否为历史问题；

（3）对比版本排查；

（4）查找源码寻找问题原因；

（5）提case找高通/MTK协助分析。

四、         三方问题

三方问题主要来源于华勤内部测试+客户测试+场测+试用反馈+售后；三方问题出现后需要查看最新版本是否复现、对比机是否复现进一步分析解决。

1、一般三方问题如何处理

下载最新版本进行测试，若复现问题，下载最新版本在对比机中进行测试；若未复现，则说明是版本的问题，建议测试员在最新版本下复测，pass后问题关闭。

若对比机中问题复现，则说明属于应用本身问题，澄清原因，走won't fix状态；若未复现，则分析log，根据异常，按模块分配问题。

2、GMS问题

         GMS是 Google提供的Mobile Device上的一系列应用服务。

遇到GMS问题如何处理：

首先确认对比机现象：如对比现象一致，则认为是GMS问题。然后确认GMS包中各个组件版本，升级到最新版本是否能解决问题，对比机GMS包版本也要升级到最新。查看对应时间点处GMS包相关log，确认是否有异常，再进一步分析解决。

五、         PDX226自测

本周进行了两次PDX226的自测，周一的自测fail项较多，同时学会使用命令测试EMEI号：adb shell

wprod_dci imei r

周五的自测fail项相对减少了很多，自测较顺利。