# 感慨
经过三个月的蹉跎，项目终于可以推出1.0版本。中间经历过很多坑，中途我们的主程离职走了，我硬着头皮接替了他的工作，从cts框架的启动开始，一点一点地研究源码，debug来debug去，一点一点的理解其中的思想，到现在已经能在cts的框架的基础上做二次开发，能简单的认识到cts处理方式。很有幸我一进入自动化领域首先认识的是cts这套框架，随着研究的深入越来越佩服开发这套框架的google工程师们。我想说的是，做自动化框架开发的人都应该好好研究这个框架，肯定会受益匪浅。其实在学习的时候，我就已经写过好几篇文章，我也将其整理成合集，放到了[testerhome](http://testerhome.com/topics/1808)上。但那个时候毕竟还是懵懂时期，也没有跳出框架从全局来考虑，现在刚好有点时间，慢慢的把这几个月的研究成果总结一下。
# 设备管理的重要性
做Android自动化工具开发的都了解，你首先要解决的问题是设备管理问题，在支持 Mult Device的工具中尤其重要。新设备的加入、已有设备的断线离线，在执行case的过程中遇到设备离线了如何去恢复等等，都是在设备管理范畴之内的。那么cts是如何做到的？
## 1.包裹ADB
~~~
package com.android.tradefed.device;
import com.android.ddmlib.AndroidDebugBridge;
import com.android.ddmlib.AndroidDebugBridge.IDeviceChangeListener;
import com.android.ddmlib.IDevice;
/**
* A wrapper that directs {@link IAndroidDebugBridge} calls to the 'real'
* {@link AndroidDebugBridge}.
*/
class AndroidDebugBridgeWrapper implements IAndroidDebugBridge {
private AndroidDebugBridge mAdbBridge = null;
/**
* Creates a {@link AndroidDebugBridgeWrapper}.
*/
AndroidDebugBridgeWrapper() {
}
/**
* {@inheritDoc}
*/
@Override
public IDevice[] getDevices() {
if (mAdbBridge == null) {
throw new IllegalStateException("getDevices called before init");
}
return mAdbBridge.getDevices();
}
/**
* {@inheritDoc}
*/
@Override
public void addDeviceChangeListener(IDeviceChangeListener listener) {
AndroidDebugBridge.addDeviceChangeListener(listener);
}
/**
* {@inheritDoc}
*/
@Override
public void removeDeviceChangeListener(IDeviceChangeListener listener) {
AndroidDebugBridge.removeDeviceChangeListener(listener);
}
/**
* {@inheritDoc}
*/
@Override
public void init(boolean clientSupport, String adbOsLocation) {
AndroidDebugBridge.init(clientSupport);
mAdbBridge = AndroidDebugBridge.createBridge(adbOsLocation, false);
}
/**
* {@inheritDoc}
*/
@Override
public void terminate() {
AndroidDebugBridge.terminate();
}
/**
* {@inheritDoc}
*/
@Override
public void disconnectBridge() {
AndroidDebugBridge.disconnectBridge();
}
}
~~~
这里实际上用到了代理模式。cts中自定义的类`AndroidDebugBridgeWrapper`包裹了`AndroidDebugBridge`，我们只需要和`AndroidDebugBridgeWrapper`交互就行了。然后在`AndroidDebugBridge`的基础上自定义了一些方法。继承的方法中重要的是`addDeviceChangeListener`和`removeDeviceChangeListener`这两个方法，待会我们就要用到。
## 2.启动ADB
~~~
public class DeviceManager implements IDeviceManager {
......
private IAndroidDebugBridge mAdbBridge;
private ManagedDeviceListener mManagedDeviceListener;
......
/**
* The DeviceManager should be retrieved from the {@link GlobalConfiguration}
*/
public DeviceManager() {
}
/**
* Initialize the device manager. This must be called once and only once before any other
* methods are called.
*/
synchronized void init(IDeviceSelection globalDeviceFilter,
List<IDeviceMonitor> globalDeviceMonitors, IManagedTestDeviceFactory deviceFactory) {
......
mAdbBridge = createAdbBridge();
mManagedDeviceListener = new ManagedDeviceListener();
......
mAdbBridge.addDeviceChangeListener(mManagedDeviceListener);
......
mAdbBridge.init(false /* client support */, "adb");
......
}
/**
* Creates the {@link IAndroidDebugBridge} to use.
* <p/>
* Exposed so tests can mock this.
* @returns the {@link IAndroidDebugBridge}
*/
synchronized IAndroidDebugBridge createAdbBridge() {
return new AndroidDebugBridgeWrapper();
}
}
~~~
在`DeviceManage`类的`init`方法中，首先通过`createAdbBridge()`方法创建一个`IAndroidDebugBridge`对象，其实质是刚才定义的`AndroidDebugBridgeWrapper`对象。这样的话我们就得到了该对象的一个实例，接着我们调用了该实例的`init`方法(其实有2行代码我故意忽略了，后面会隆重登场)，这样`ADB`的初始化工作就完成了。
## 3.状态监听器
~~~
private class ManagedDeviceListener implements IDeviceChangeListener {
/**
* {@inheritDoc}
*/
@Override
public void deviceChanged(IDevice idevice, int changeMask) {
......
}
/**
* {@inheritDoc}
*/
@Override
public void deviceConnected(IDevice idevice) {
......
}
/**
* {@inheritDoc}
*/
@Override
public void deviceDisconnected(IDevice disconnectedDevice) {
......
}
}
~~~
在`DeviceManager`类中定义了一个私有类`ManagedDeviceListener`，该类实现了`ADB`中的接口`IDeviceChangeListener`。该接口实际上是观察者模式中的一个抽象观察者，我们定义的`ManagedDeviceListener`类是一个具体观察者。当我们注册为设备状态的观察者后，设备状态发生变化后，我们会被通知到。这个时候我们隆重请出刚才我们忽略的2行代码：
~~~
mManagedDeviceListener = new ManagedDeviceListener();
......
mAdbBridge.addDeviceChangeListener(mManagedDeviceListener);
~~~
这两行代码首先初始化了一个设备状态的具体观察者对象的实例，然后将其添加到通知列表中，这个时候`ADB`设备发生改变后，就会通知我们的对象，其中相应的三个方法`deviceChanged`,`deviceConnected`,`deviceDisconnected`会被调用，这个时候我们就可以通过一些处理得到新加入的设备，或者已有设备中离线的设备，然后将其删除。这样我们就能很好的监听着设备状态的改变。
## 4.得到设备
既然我们能准确的监听着设备状态的改变，我们就要用一个(或许是多个)容器去保存这些设备。具体的操作流程我觉得单独写一篇文章来讲比较好，这样才能对得起它良好的设计。
- 前言
- (1)-windows下cts配置
- (2)-cts调试环境的搭建
- (3)-基础库tradefederation配置
- (4)-任务的添加
- (5)-9大组件配置
- (6)-任务的执行
- (7)-任务执行的调度室
- (8)-IBuildProvider
- (9)-IDeviceRecovery
- (10)-TestDeviceOptions
- (11)-ICommandOptions
- (12)-ITargetPreparer
- (13)-任务执行过程
- (14)-任务执行过程
- (15)-任务执行完
- (16)-logcat信息收集系统
- (17)-fastboot状态监听器
- (18)-设备恢复
- (19)-设备状态的分类以及恢复模式的分类
- (20)-cts自身log系统
- (21)-测试结果收集系统
- (22)-自动检测设备
- (23)-设备分类
- (24)-case的组织