Clone this repo:
  1. a9bd47e Merge stage-aosp-master into pi-dev-plus-aosp am: 18ca7dfd42 by Xin Li · 1 year, 11 months ago android10-c2f2-release android10-c2f2-s1-release android10-c2f2-s2-release android10-d4-release android10-d4-s1-release android10-dev android10-mainline-media-release android10-mainline-networking-release android10-mainline-resolv-release android10-mainline-tzdata-release android10-qpr1-b-release android10-qpr1-b-s1-release android10-qpr1-c-release android10-qpr1-c-s1-release android10-qpr1-d-release android10-qpr1-mainline-release android10-qpr1-release android10-qpr2-release android10-qpr2-s1-release android10-qpr2-s2-release android10-qpr2-s3-release android10-qpr2-s4-release android10-qpr3-release android10-qpr3-s1-release android10-tests-dev android10-tests-release android11-d1-b-release android11-d1-release android11-d1-s1-release android11-d1-s5-release android11-d1-s6-release android11-d1-s7-release android11-dev android11-gsi android11-mainline-release android11-mainline-sparse-2020-dec-release android11-platform-release android11-qpr1-d-release android11-qpr1-d-s1-release android11-qpr1-release android11-qpr1-s1-release android11-qpr1-s2-release android11-release android11-s1-release android11-security-release android11-tests-dev android11-tests-release master ndk-sysroot-r21 android-10.0.0_r12 android-10.0.0_r13 android-10.0.0_r14 android-10.0.0_r15 android-10.0.0_r16 android-10.0.0_r18 android-10.0.0_r19 android-10.0.0_r20 android-10.0.0_r21 android-10.0.0_r22 android-10.0.0_r23 android-10.0.0_r24 android-10.0.0_r25 android-10.0.0_r26 android-10.0.0_r27 android-10.0.0_r28 android-10.0.0_r29 android-10.0.0_r30 android-10.0.0_r31 android-10.0.0_r32 android-10.0.0_r33 android-10.0.0_r34 android-10.0.0_r35 android-10.0.0_r36 android-10.0.0_r37 android-10.0.0_r38 android-10.0.0_r39 android-10.0.0_r40 android-10.0.0_r41 android-10.0.0_r42 android-10.0.0_r43 android-10.0.0_r44 android-10.0.0_r45 android-10.0.0_r7 android-10.0.0_r8 android-10.0.0_r9 android-11.0.0_r1 android-11.0.0_r10 android-11.0.0_r11 android-11.0.0_r12 android-11.0.0_r13 android-11.0.0_r14 android-11.0.0_r15 android-11.0.0_r16 android-11.0.0_r17 android-11.0.0_r18 android-11.0.0_r19 android-11.0.0_r2 android-11.0.0_r20 android-11.0.0_r21 android-11.0.0_r22 android-11.0.0_r23 android-11.0.0_r24 android-11.0.0_r25 android-11.0.0_r26 android-11.0.0_r27 android-11.0.0_r28 android-11.0.0_r3 android-11.0.0_r4 android-11.0.0_r5 android-11.0.0_r7 android-11.0.0_r8 android-11.0.0_r9 android-cts-10.0_r2 android-cts-10.0_r3 android-cts-10.0_r4 android-cts-10.0_r5 android-cts-10.0_r6 android-cts-11.0_r1 android-cts-11.0_r2 android-mainline-10.0.0_r10 android-mainline-10.0.0_r11 android-mainline-10.0.0_r4 android-mainline-10.0.0_r5 android-mainline-10.0.0_r6 android-mainline-10.0.0_r7 android-mainline-10.0.0_r8 android-mainline-10.0.0_r9 android-mainline-11.0.0_r1 android-mainline-11.0.0_r2 android-mainline-11.0.0_r3 android-mainline-11.0.0_r4 android-platform-11.0.0_r1 android-platform-11.0.0_r2 android-platform-11.0.0_r3 android-r-beta-2 android-r-beta-3 android-r-preview-1 android-r-preview-2 android-r-preview-3 android-r-preview-4 android-security-11.0.0_r1 android-vts-10.0_r2 android-vts-10.0_r3 android-vts-10.0_r4 android-vts-10.0_r5 android-vts-10.0_r6 android-vts-11.0_r1 android-vts-11.0_r2
  2. 18ca7df Merge stage-aosp-master into pi-dev-plus-aosp by Xin Li · 1 year, 11 months ago
  3. c35094c DO NOT MERGE - Merge pi-dev@5234907 into stage-aosp-master by Xin Li · 2 years ago android-o-mr1-iot-release-1.0.13 android-o-mr1-iot-release-1.0.14
  4. dde439c Add project owners. am: bc185fa033 am: 8eddc3bbe6 am: 901beded26 by Hyunwoo Ko · 2 years ago
  5. 901bede Add project owners. am: bc185fa033 am: 8eddc3bbe6 by Hyunwoo Ko · 2 years ago

VTS Dashboard


The VTS Dashboard displays the summarized results of the Multi Device Tests along with graphs.


Steps to run locally:

  1. Google App Engine uses Java 8. Install Java 8 before running running locally: ‘sudo apt install openjdk-8-jdk’

    To use java 8: Copy the following lines in ~/.bashrc :

    function setup_jdk() {
      # Remove the current JDK from PATH
      if [ -n "$JAVA_HOME" ] ; then
      export JAVA_HOME=$1
      export PATH=$JAVA_HOME/bin:$PATH

    function use_java8() {
    #  setup_jdk /usr/java/jre1.8.0_73
      setup_jdk /usr/lib/jvm/java-8-openjdk-amd64

    Then from cmd:
    $ use_java8
  1. Maven is used for build. Install Maven 3.3.9: Download maven from:

    Steps to Install Maven:

    1. Unzip the Binary tar: tar -zxf apache-maven-3.3.3-bin.tar.gz

    2. Move the application directory to /usr/local sudo cp -R apache-maven-3.3.3 /usr/local

    3. Make a soft link in /usr/bin for universal access of mvn sudo ln -s /usr/local/apache-maven-3.3.3/bin/mvn /usr/bin/mvn

    4. Verify maven installation: $ mvn -v

      The output should resemble this:

      Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: /opt/apache-maven-3.3.9 Java version: 1.8.0_45-internal, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: “linux”, version: “3.13.0-88-generic”, arch: “amd64”, family: “unix”

  2. Install Google Cloud SDK. Follow the instructions listed on official source:

    The default location where the application searches for a google-cloud-sdk is: /usr/local/share/google/google-cloud-sdk

    Therefore move the extracted folder to this location: /usr/local/share/google/

    Otherwise, to have a custom location, specify the location of google-cloud-sdk in test/vti/dashboard/pom.xml by putting the configuration:


within the ‘’ plugin tag :

To run GAE on local machine:

$ cd test/vti/dashboard $ mvn appengine:devserver

To deploy to Google App Engine

$ cd test/vti/dashboard $ mvn appengine:update


Update config file through gcloud command

You can deploy or update GAE's a config file without deploying the whole project. The next commands show how to do it.

gcloud app deploy --project=<YOUR-PROJECT-NAME> cron.xml
gcloud app deploy --project=<YOUR-PROJECT-NAME> queue.xml
gcloud app deploy --project=<YOUR-PROJECT-NAME> datastore-indexes.xml

Test Data


When you start your local GAE server, you will see empty page as the local datastore do not have any data. So we need to put some sample data into local datastore so that developers are able to continue to develop new features or fix bugs. Thus, we developed the next two test APIs, which are only available in your local dev environment.

How to set test data on json files for generating mock data on local dev server

If you want to generate some mock data for your local development, you need to set some fake data on json files under the testdata folder. However, you need to abide by some rules in doing this, otherwise you will end up with errors from the mock data dev API.

First, in test-plan-report-data.json, you need to set the same number of data under “testCaseNames” and “results”. For example, if you put 5 elements of data in “testCaseNames”, you should put the same number of data under “results”.

"testCaseRunList": [
    "testCaseNames": [
    "results": [

Second, in test-report-data.json file, you need to make sure that “testModules” should have the “testName”'s value under “testRunList” and the “testTimes” should have the “startTimestamp”'s value in the test-report-data.json file.


  "testRunList": [
      "testName": "BionicUnitTests", <- "testModules" should be copied from here
      "type": 1,
      "startTimestamp":1515562811, <- "testTimes" should be copied from here
      "testName": "CpuProfilingTest", <- "testModules" should be copied from here
      "type": 2,
      "startTimestamp":1515562811, <- "testTimes" should be copied from here


    "testPlanName": "vts-serving-staging-fuzz",
    "testModules": ["BionicUnitTests", "CpuProfilingTest"],
    "testTimes": [1515562811, 1515562811]
    "testPlanName": "vts-serving-staging-hal-conventional",
    "testModules": ["BionicUnitTests", "CpuProfilingTest"],
    "testTimes": [1515562811, 1515562811]

“testModules” and “testTimes”'s elements order is also matter.

Command to generate mock data through API

The next two commands will generate mock data in your local dev datastore. The execution order of the commands is very important, otherwise you can't find some of the data in your local datastore. Thus, please execute the below command as I wrote in order.

curl -d @testdata/test-report-data.json -m 30 -X POST -H "Content-Type: application/json" --verbose
curl -d @testdata/test-plan-report-data.json -m 30 -X POST -H "Content-Type: application/json" --verbose


The following steps list how to create a monitoring service for the VTS Dashboard.

Create a Stackdriver account

  1. Go to Google Cloud Platform Console:

  2. In the Google Cloud Platform Console, select Stackdriver > Monitoring. If your project is not in a Stackdriver account you'll see a message to create a new project.

  3. Click Create new Stackdriver account and then Continue.

  4. With your project shown, click Create account.

  5. In the page, “Add Google Cloud Platform projects to monitor”, click Continue to skip ahead.

  6. In the page, “Monitor AWS accounts”, click Done to skip ahead.

  7. In a few seconds you see the following message: “Finished Initial collection” Click Launch Monitoring.

  8. In the page, “Get reports by email”, click No reports and Continue.

  9. You will see your Stackdriver account dashboard. Close the “Welcome to Stackdriver” banner if you don't need it.

Steps to create an uptime check and an alerting policy

  1. Go to Stack Monitoring console:

  2. Go to Alerting > Uptime Checks in the top menu and then click Add Uptime Check. You see the New Uptime Check panel.

  3. Fill in the following fields for the uptime check:

    Check type: HTTP Resource Type: Instance Applies To: Single, lamp-1-vm Leave the other fields with their default values.

  4. Click Test to verify your uptime check is working.

  5. Click Save. After you click on save you'll see a panel to ‘Create Alerting Policy’

  6. Fill out the configuration for notifications and click save policy.

Test the check and alert

This procedure can take up to fifteen minutes.

To test the check and alert, go to the VM Instances page, select your instance, and click Stop from the top menu. You‘ll have to wait up to five minutes for the next uptime check to fail. The alert and notification don’t happen until the next failure occurs.

To correct the “problem,” return to the VM Instances page, select your instance, and click Start from the top menu.