tree: 67f966c0ca4d7b9a32c000e2f58d73991ba8b265 [path history] [tgz]
  1. jsdialog/
  2. mock/
  3. nfc_apk/
  4. rules/
  5. util/
  6. adding_new_tests.md
  7. EmulatedVrController.java
  8. OWNERS
  9. README.md
  10. TestVrShellDelegate.java
  11. VrBrowserCompositorViewHolderTest.java
  12. VrBrowserControllerInputTest.java
  13. VrBrowserDialogTest.java
  14. VrBrowserNativeUiTest.java
  15. VrBrowserNavigationTest.java
  16. VrBrowserTestFramework.java
  17. VrBrowserTransitionTest.java
  18. VrBrowserWebInputEditingTest.java
  19. VrDaydreamReadyModuleInstallTest.java
  20. VrFeedbackInfoBarTest.java
  21. VrInstallUpdateInfoBarTest.java
  22. WebVrTestFramework.java
  23. WebXrArSessionTest.java
  24. WebXrArTestFramework.java
  25. WebXrTestFramework.java
  26. WebXrVrDeviceTest.java
  27. WebXrVrInputTest.java
  28. WebXrVrTabTest.java
  29. WebXrVrTestFramework.java
  30. WebXrVrTransitionTest.java
  31. xr_instrumentation_deep_dive.md
  32. XrTestFramework.java
chrome/android/javatests/src/org/chromium/chrome/browser/vr/README.md

XR Instrumentation Tests

TL;DR For Most Local Repros

  1. Get a rooted Pixel device of some sort.
  2. Make sure “VR Services” is up to date in the Playstore.
  3. Set lock screen timeout to at least 5 minutes. If screen is locked or device goes to sleep while tests are still running, they will fail.
  4. Run ninja -C out/Debug chrome_public_test_vr_apk && out/Debug/bin/run_chrome_public_test_vr_apk --num-retries=0 --shared-prefs-file=//chrome/android/shared_preference_files/test/vr_ddview_skipdon_setupcomplete.json --test-filter=<failing test case> Don't touch phone while the tests are running.

NOTE The message “Main Unable to find package info for org.chromium.chrome” is usually displayed when the test package is being installed and does not indicate any problem.

Introduction

This directory contains all the Java-side infrastructure for running instrumentation tests for XR (VR/Virtual Reality and AR/Augmented Reality) features currently in Chrome:

  • WebVR - Experience VR content on the web
  • WebXR - Successor to WebVR, experience VR and AR content on the web
  • VR Browser - Browse the 2D web from a VR headset

These tests are integration/end-to-end tests run in the full Chromium browser on actual Android devices.

Directories

These are the files and directories that are relevant to XR instrumentation testing.

Subdirectories

  • mock/ - Contains all the classes for mock implementations of XR classes.
  • nfc_apk/ - Contains the code for the standalone APK for NFC simulation. Used by Telemetry tests, not instrumentation tests, but kept here since it uses code from util/.
  • rules/ - Contains all the XR-specific JUnit4 rules for handling functionality such as running tests multiple times in different activities and handling the fake VR pose tracker service.
  • util/ - Contains utility classes with code that is used by multiple test classes and that does not make sense to include in the core test framework.

Other Directories

Building

AR

The AR instrumentation tests can be built with the monochrome_public_test_ar_apk target, which will also build monochrome_public_apk to test with.

VR

The VR instrumentation tests can be built with the chrome_public_test_vr_apk target, which will also build chrome_public_apk to test with.

Running

Both the VR and AR tests are run using the generated script in your build output directory's bin/ directory, e.g. out/foo/bin/run_chrome_public_test_vr_apk to run the VR tests. You will likely need to pass some or all of the following arguments in order for the tests to run properly, though.

NOTE The instrumentation tests can only be run on rooted devices.

Common Arguments

additional-apk

--additional-apk path/to/apk/to/install

Installs the specified APK before running the tests. No-ops if the provided APK is already installed on the device and their versions match.

For VR tests, you'll likely want to use --additional-apk third_party/gvr-android-sdk/test-apks/vr_services/vr_services_current.apk to ensure that the VrCore version used is the one used for automated testing at whatever your current git revision is.

For AR tests, you'll likely want to use --additional-apk third_party/arcore-android-sdk/test-apks/arcore/arcore_current.apk to ensure that the ArCore version used is the one used for automated testing at whatever your current git revision is.

NOTE Using this argument for VR on most Pixel devices will fail, as VrCore is pre-installed as a system app. This can be dealt with in the following ways:

  • Remove VrCore as a system app by following the instructions here. This will permanently solve the issue unless you reflash your device.
  • Use --replace-system-package com.google.vr.vrcore,//third_party/gvr-android-sdk/test-apks/vr_services/vr_services_current.apk instead. This will take significantly longer, as it requires rebooting, and must be done every time you run the tests.
  • Skip this argument entirely and just ensure that the VrCore version on the device is up to date via the Play Store.

test-filter

--test-filter TestClass#TestCase

Allows you to limit the set of tests run to a particular test class or subset of tests within a test class. Use of the * wildcard is supported, e.g. --test-filter VrBrowserTransitionTest#* will run all tests in the VrBrowserTransitionTest class.

local-output/json-results-file

--local-output --json-results-file output.json

Sets the test runner to generate a local results summary after running all tests and print out a file URL pointing to the summary. This allows you to view both logcat output for a particular test and its post-failure screenshot.

num-retries

--num-retries <#>

Sets the test runner to retry failed tests a certain number of times. The default is 2, resulting in a max of 3 test runs. Usually used as --num-retries 0 when debugging to reduce test runtime and make flakiness more visible.

repeat

--repeat <#>

Sets the test runner to repeat the tests a certain number of times. The default is 0, resulting in only one iteration. Usually used to repeat a test many times in order to check for or reproduce flakiness.

VR-Specific Arguments

shared-prefs-file

--shared-prefs-file path/to/preference/json/file

Configures VrCore according to the provided file, e.g. changing the paired headset. The two most common files used are:

  • //chrome/android/shared_preference_files/test/vr_cardboard_skipdon_setupcomplete.json This will pair the device with a Cardboard headset and disable controller emulation.
  • //chrome/android/shared_preference_files/test/vr_ddview_skipdon_setupcomplete.json This will pair the device with a Daydream View headset, set the DON flow to be skipped, and enable controller emulation.

The test runner will automatically revert any changed settings back to their pre-test values after the test suite has completed. If for whatever reason you want to manually apply settings outside of a test, you can do so with //build/android/apply_shared_preference_file.py.

vr-settings-service-enabled

--vr-settings-service-enabled --annotation=Restriction=VR_Settings_Service

Tells the test runner to allow the running of tests that utilize the VR settings service to dynamically change VrCore settings during a test instead of relying on whatever was set by the shared preference file that was applied. This is used as a catch-all for less standard tests, such as those that require the DON flow to be enabled or that need to switch the paired viewer mid-test.

This should only be used when --shared-prefs-file is passed //chrome/android/shared_preference_files/test/vr_enable_vr_settings_service.json as otherwise trying to use the service will be a NOOP.

Adding New Tests

See adding_new_tests.md.