1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315
|
# Android Test Instructions
[TOC]
## Device Setup
### Physical Device Setup
#### ADB Debugging
In order to allow the ADB to connect to the device, you must enable USB
debugging:
* Before Android 4.1 (Jelly Bean):
* Go to "System Settings"
* Go to "Developer options"
* Check "USB debugging".
* Un-check "Verify apps over USB".
* On Jelly Bean and above, developer options are hidden by default. To unhide
them:
* Go to "About phone"
* Tap 10 times on "Build number"
* The "Developer options" menu will now be available.
* Check "USB debugging".
* Un-check "Verify apps over USB".
#### Screen
You **must** ensure that the screen stays on while testing: `adb shell svc power
stayon usb` Or do this manually on the device: Settings -> Developer options ->
Stay Awake.
If this option is greyed out, stay awake is probably disabled by policy. In that
case, get another device or log in with a normal, unmanaged account (because the
tests will break in exciting ways if stay awake is off).
#### Enable Asserts
```
adb shell setprop debug.assert 1
```
#### Disable Verify Apps
You may see a dialog like [this
one](http://www.samsungmobileusa.com/simulators/ATT_GalaxyMega/mobile/screens/06-02_12.jpg),
which states, _Google may regularly check installed apps for potentially harmful
behavior._ This can interfere with the test runner. To disable this dialog, run:
```
adb shell settings put global package_verifier_enable 0
```
### Emulator Setup
#### Option 1
Use an emulator (i.e. Android Virtual Device, AVD): Enabling Intel's
Virtualizaton support provides the fastest, most reliable emulator configuration
available (i.e. x86 emulator with GPU acceleration and KVM support). Remember to
build with `target_arch=ia32` for x86. Otherwise installing the APKs will fail
with `INSTALL_FAILED_NO_MATCHING_ABIS`.
1. Enable Intel Virtualization support in the BIOS.
2. Set up your environment:
```shell
. build/android/envsetup.sh
```
3. Install emulator deps:
```shell
build/android/install_emulator_deps.py --api-level=23
```
This script will download Android SDK and place it a directory called
android\_tools in the same parent directory as your chromium checkout. It
will also download the system-images for the emulators (i.e. arm and x86).
Note that this is a different SDK download than the Android SDK in the
chromium source checkout (i.e. `src/third_party/android_emulator_sdk`).
4. Run the avd.py script. To start up _num_ emulators use -n. For non-x86 use
--abi.
```shell
build/android/avd.py --api-level=23
```
This script will attempt to use GPU emulation, so you must be running the
emulators in an environment with hardware rendering available. See `avd.py
--help` for more details.
#### Option 2
Alternatively, you can create and run your own emulator using the tools provided
by the Android SDK. When doing so, be sure to enable GPU emulation in hardware
settings, since Chromium requires it to render.
## Building Tests
If you're adding a new test file, you'll need to explicitly add it to a gn
target. If you're adding a test to an existing file, you won't need to make gn
changes, but you may be interested in where your test winds up. In either case,
here are some guidelines for where a test belongs:
### C++
C++ test files typically belong in `<top-level directory>_unittests` (e.g.
`base_unittests` for `//base`). There are a few exceptions -- browser tests are
typically their own target (e.g. `content_browsertests` for `//content`, or
`browser_tests` for `//chrome`), and some unit test suites are broken at the
second directory rather than the top-level one.
### Java
Java test files vary a bit more widely than their C++ counterparts:
- Instrumentation test files -- i.e., tests that will run on a device --
typically belong in either `<top-level directory>_javatests` or `<top-level
directory>_test_java`. Regardless, they'll wind up getting packaged into one
of a few test APKs:
- `android_webview_test_apk` for anything in `//android_webview`
- `content_shell_test_apk` for anything in `//content` or below
- `chrome_public_test_apk` for most things in `//chrome`
- `chrome_sync_shell_test_apk` in a few exceptional cases
- JUnit or Robolectric test files -- i.e., tests that will run on the host --
typically belong in `<top-level directory>_junit_tests` (e.g.
`base_junit_tests` for `//base`), though here again there are cases
(particularly in `//components`) where suites are split at the second
directory rather than the top-level one.
Once you know what to build, just do it like you normally would build anything
else, e.g.: `ninja -C out/Release chrome_public_test_apk`
## Running Tests
All functional tests should be runnable via the wrapper scripts generated at
build time:
```sh
<output directory>/bin/run_<target_name> [options]
```
Note that tests are sharded across all attached devices unless explicitly told
to do otherwise by `-d/--device`.
The commands used by the buildbots are printed in the logs. Look at
https://build.chromium.org/ to duplicate the same test command as a particular
builder.
### INSTALL\_FAILED\_CONTAINER\_ERROR or INSTALL\_FAILED\_INSUFFICIENT\_STORAGE
If you see this error when the test runner is attempting to deploy the test
binaries to the AVD emulator, you may need to resize your userdata partition
with the following commands:
```shell
# Resize userdata partition to be 1G
resize2fs android_emulator_sdk/sdk/system-images/android-24/x86/userdata.img 1G
# Set filesystem parameter to continue on errors; Android doesn't like some
# things e2fsprogs does.
tune2fs -e continue android_emulator_sdk/sdk/system-images/android-24/x86/userdata.img
```
## Symbolizing Crashes
Crash stacks are logged and can be viewed using `adb logcat`. To symbolize the
traces, define `CHROMIUM_OUTPUT_DIR=$OUTDIR` where `$OUTDIR` is the argument you
pass to `ninja -C`, and pipe the output through
`third_party/android_platform/development/scripts/stack`. If
`$CHROMIUM_OUTPUT_DIR` is unset, the script will search `out/Debug` and
`out/Release`. For example:
```shell
# If you build with
ninja -C out/Debug chrome_public_test_apk
# You can run:
adb logcat -d | third_party/android_platform/development/scripts/stack
# If you build with
ninja -C out/android chrome_public_test_apk
# You can run:
adb logcat -d | CHROMIUM_OUTPUT_DIR=out/android third_party/android_platform/development/scripts/stack
# or
export CHROMIUM_OUTPUT_DIR=out/android
adb logcat -d | third_party/android_platform/development/scripts/stack
```
## JUnit tests
JUnit tests are Java unittests running on the host instead of the target device.
They are faster to run and therefore are recommended over instrumentation tests
when possible.
The JUnits tests are usually following the pattern of *target*\_junit\_tests,
for example, `content_junit_tests` and `chrome_junit_tests`.
When adding a new JUnit test, the associated `BUILD.gn` file must be updated.
For example, adding a test to `chrome_junit_tests` requires to update
`chrome/android/BUILD.gn`. If you are a GYP user, you will not need to do that
step in order to run the test locally but it is still required for GN users to
run the test.
```shell
# Build the test suite.
ninja -C out/Release chrome_junit_tests
# Run the test suite.
build/android/test_runner.py junit -s chrome_junit_tests --release -vvv
# Run a subset of tests. You might need to pass the package name for some tests.
build/android/test_runner.py junit -s chrome_junit_tests --release -vvv
-f "org.chromium.chrome.browser.media.*"
```
## Gtests
```shell
# Build a test suite
ninja -C out/Release content_unittests
# Run a test suite
out/Release/bin/run_content_unittests [-vv]
# Run a subset of tests
out/Release/bin/run_content_unittests [-vv] --gtest-filter ByteStreamTest.*
```
## Instrumentation Tests
In order to run instrumentation tests, you must leave your device screen ON and
UNLOCKED. Otherwise, the test will timeout trying to launch an intent.
Optionally you can disable screen lock under Settings -> Security -> Screen Lock
-> None.
Next, you need to build the app, build your tests, and then run your tests
(which will install the APK under test and the test APK automatically).
Examples:
ContentShell tests:
```shell
# Build the code under test
ninja -C out/Release content_shell_apk
# Build the tests themselves
ninja -C out/Release content_shell_test_apk
# Run the test (will automagically install the APK under test and the test APK)
out/Release/bin/run_content_shell_test_apk [-vv]
```
ChromePublic tests:
```shell
# Build the code under test
ninja -C out/Release chrome_public_apk
# Build the tests themselves
ninja -C out/Release chrome_public_test_apk
# Run the test (will automagically install the APK under test and the test APK)
out/Release/bin/run_chrome_public_test_apk [-vv]
```
AndroidWebView tests:
```shell
ninja -C out/Release android_webview_apk
ninja -C out/Release android_webview_test_apk
out/Release/bin/run_android_webview_test_apk [-vv]
```
In order to run a subset of tests, use -f to filter based on test class/method
or -A/-E to filter using annotations.
Filtering examples:
```shell
# Run a test suite
out/Debug/bin/run_content_shell_test_apk
# Run a specific test class
out/Debug/bin/run_content_shell_test_apk -f AddressDetectionTest.*
# Run a specific test method
out/Debug/bin/run_content_shell_test_apk -f \
AddressDetectionTest#testAddressLimits
# Run a subset of tests by size (Smoke, SmallTest, MediumTest, LargeTest,
# EnormousTest)
out/Debug/bin/run_content_shell_test_apk -A Smoke
# Run a subset of tests by annotation, such as filtering by Feature
out/Debug/bin/run_content_shell_test_apk -A Feature=Navigation
```
You might want to add stars `*` to each as a regular expression, e.g.
`*`AddressDetectionTest`*`
## Running Blink Layout Tests
See [Layout Tests](testing/layout_tests.md).
## Running GPU tests
(e.g. the "Android Debug (Nexus 7)" bot on the chromium.gpu waterfall)
See https://www.chromium.org/developers/testing/gpu-testing for details. Use
`--browser=android-content-shell`. Examine the stdio from the test invocation on
the bots to see arguments to pass to `src/content/test/gpu/run_gpu_test.py`.
|