Cts框架解析(6)-任务的执行

前两篇讲了任务的添加和9大项配置,这篇讲任务的执行。

任务的执行

任务的执行在CommandScheduler的run方法中,所以删除所有的断点,在run方法中打上断点,重启启动debug:

先看while循环下面的第一行代码

ExecutableCommand cmd = dequeueConfigCommand();
private ExecutableCommand dequeueConfigCommand() {
        try {
            // poll for a command, rather than block indefinitely, to handle shutdown case
            return mCommandQueue.poll(getCommandPollTimeMs(), TimeUnit.MILLISECONDS);
        } catch (InterruptedException e) {
            CLog.i("Waiting for command interrupted");
        }
        return null;
    }

从队列中取出第一个对象。如果队列中没有元素那就返回null。返回后,while中会判断如果为null的话,就会结束再次调用

ExecutableCommand cmd = dequeueConfigCommand();

直到cmd不为null。所以在

IDeviceSelection options = cmd.getConfiguration().getDeviceRequirements();

打上断点,按F8,程序会在cmd不为null时进入到上面的代码,停下来。

首先得到系统设备要求,根据该要求,判断是否有满足要求的设备并分配该设备。

原生的 要求就一个S/N号,ddms会根据该SN号分配一个IDevice,然后cts根据IDevice包装成ITestDevice对象返回。然后根据ITestDevice,IDeviceManager和ExecutableCommand开始真正的启动任务。我们先不急于讨论执行的过程,而是继续向下看:

addInvocationThread(invThread);
if (cmd.isLoopMode()) {
    addNewExecCommandToQueue(cmd.getCommandTracker());
}

先将正在执行的线程存到set中,然后将该命令再次放入任务队列中,这样的目的是为了能循环执行该任务。如果根据sn号没有分配成功ITestDevice,则会再次尝试一次,如果在规定时间内还没找到设备则放弃。最后做一些tearDown操作,然后将case运行过程中的log保存到文件。就算执行完了。

现在回头看一下执行任务的线程中是如何操作的:

private InvocationThread startInvocation(IDeviceManager manager, ITestDevice device,
            ExecutableCommand cmd) {
        final String invocationName = String.format("Invocation-%s", device.getSerialNumber());
        InvocationThread invocationThread = new InvocationThread(invocationName, manager, device,
                cmd);
        invocationThread.start();
        return invocationThread;
    }

InvocationThread为CommandScheduler私有内部类,继承与线程,这就属于线程里启动线程。所以直接看InvocationThread的run方法就ok了。在run方法里调用了ITestInvocation的invoke方法:

传入的对象分别为ITestDevice、IConfiguration、IRescheduler。前两个已经涉及到,最后一个IRescheduler是什么?自己看吧,也没啥意义。这样任务的前期的工作都已经搞定了,程序转到了TestInvocation的invoke方法。放到下一篇文章来讲,因为它很重要,相当于一个调度室的作用。

总结

写了6篇,总结一些cts的过程。

任务的开始点是接受命令行中的参数,如果判断为执行cts任务,那么会在Console.run方法中启动添加命令任务的线程ArgRunnable<CaptureList>和执行任务的线程CommandScheduler。添加任务线程ArgRunnable<CaptureList>会调用CommandScheduler对象方法addCommand来向ConditionPriorityBlockingQueue<ExecutableCommand>(采用先进先出的队列)这个队列中添加,而执行任务线程CommandScheduler会通过调用自己的私有方法dequeueConfigCommand来从

ConditionPriorityBlockingQueue<ExecutableCommand>去取可执行的任务,每次取第一个。然后调用InvocationThread这个线程去执行任务。InvocationThread这个线程调用TestInvocation.invoke方法去执行任务。

明白了么,其实很简单!

时间: 2024-08-07 23:29:00

Cts框架解析(6)-任务的执行的相关文章

Cts框架解析(5)

解析配置文件 Cts框架分为9大部分: cmd_options:命令行接受的参数选项,command包中. device_requirements:设备相关要求,device包中 device_options:设备参数,device包中 builde_provider:版本提供者,build包中 target_preparer:预置条件准备,targetprep包中 test:测试类型,存在testtype包中 device_recovery:任务执行过程中设备异常后的设备恢复,device包中

Cts框架解析(2)-cts调试环境的搭建

上一篇文章中说了怎样在windows搭建cts以及执行cts进行測试.这篇文章来讲讲怎样在eclipse中配置源代码,进行debug调试. 下载 cts源代码地址:https://android.googlesource.com/platform/cts 能够使用git下载到本地. 文件夹结构 watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaXRmb290YmFsbA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFC

Cts框架解析(9)-IDeviceRecovery

当设备处于offline状态时,cts框架就要调用IDeviceRecovery接口类去做相应的恢复工作. 接口 /* * Copyright (C) 2010 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the Licens

Cts框架解析(13)-任务执行过程

因为测试任务是个很复杂的过程,所以要单独拿出来讲,里面还涉及了result_reporter的内容.所以这是一个大块.首先把断点打在CtsTest的run方法中,删除其他断点,重新启动debug模式: 首先会调用checkFields检查一下命令行参数.然后生成plan里的包名信息.(要理解plan的意思,plan就是cts目录下plan文件下的xml文件,它里面配置的entry代表一个测试项,一个测试项里又包含多个测试的case).本程序执行的是Signature计划,我们就来看看这个xml文

Cts框架解析(7)-任务执行的调度室

TestInvocation /** * {@inheritDoc} */ @Override public void invoke(ITestDevice device, IConfiguration config, IRescheduler rescheduler) throws DeviceNotAvailableException, Throwable { try { mStatus = "fetching build"; config.getLogOutput().init(

Cts框架解析(15)-任务执行完

case执行完毕后,会回到CtsTest的run方法中: 这个时候会先将mRemainingTestPkgs列表的第一项移除,以便下一次取第一个的时候,取的是新的TestPackage对象,然后根据case的类别来做相应的重启操作,最后返回到主界面.最后,截图留下犯罪现场,下载之前安装的jar包.在finally语句块中report未执行的case.为执行的case是通过执行其testStarted方法,但是不执行testEnded方法,让监听器识别出这条case未执行. 当CtsTest的ru

Cts框架解析(1)-windows下cts配置

环境搭建 下载 cts工具的下载地址:http://source.android.com/compatibility/downloads.html windows选择Android4.4 R3 Compatibility Test Suite (CTS) - ARM下载. 文件夹结构 解压后的文件夹结构例如以下: watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaXRmb290YmFsbA==/font/5a6L5L2T/fontsize/400/fil

Cts框架解析(4)

Debug debug的入口在CtsConsole类,所以我们把第一个断点打在249行: Console console = new CtsConsole(); 按F6再按F5进入到Console.startConsole方法中. 按F5进入GlobalConfiguration.createGlobalConfiguration方法中. 该方法内主要是读取全局配置文件并设置IGlobalConfiguration接口对象sInstance.主要方法为95行读取文件的getGlobalConfi

Cts框架解析(6)-任务的运行

前两篇讲了任务的加入和9大项配置,这篇讲任务的运行. 任务的运行 任务的运行在CommandScheduler的run方法中,所以删除全部的断点,在run方法中打上断点,重新启动启动debug: 先看while循环以下的第一行代码 ExecutableCommand cmd = dequeueConfigCommand(); private ExecutableCommand dequeueConfigCommand() { try { // poll for a command, rather