This file documents the use of a chroot environment in on-device testing of the Android Runtime (ART). Using a chroot allows tests to run a standalone ART from a locally built source tree on a device running (almost any) system image and does not interfere with the Runtime installed in the device's system partition.
The Android Runtime (ART) supports testing in a chroot-based environment, by setting up a chroot directory in a ART_TEST_CHROOT
directory located under /data/local
(e.g. ART_TEST_CHROOT=/data/local/art-test-chroot
) on a device, installing ART and all other required artifacts there, and having tests use adb shell chroot $ART_TEST_CHROOT <command>
to execute commands on the device within this environment.
This way to run tests using a "standalone ART" ("guest system") only affects files in the data partition (the system partition and other partitions are left untouched) and is as independent as possible from the Android system ("host system") running on the device. This has some benefits:
master-art
) to build ART and the required dependencies for testing;/data/local/art-test-chroot1
, /data/local/art-test-chroot2
, etc.).Note that using this chroot-based approach requires root access to the device (i.e. be able to run adb root
successfully).
unset ART_TEST_ANDROID_ROOT
unset CUSTOM_TARGET_LINKER
unset ART_TEST_ANDROID_ART_ROOT
unset ART_TEST_ANDROID_RUNTIME_ROOT
unset ART_TEST_ANDROID_I18N_ROOT
unset ART_TEST_ANDROID_TZDATA_ROOT
ART_TEST_CHROOT
:export ART_TEST_CHROOT=/data/local/art-test-chroot
aosp/master-art
tree:export SOONG_ALLOW_MISSING_DEPENDENCIES=true export BUILD_BROKEN_DISABLE_BAZEL=true . ./build/envsetup.sh
lunch arm_krait-eng
lunch armv8-eng
lunch arm_v7_v8-eng
lunch silvermont-eng
lunch aosp_riscv64-eng
export PATH="$(pwd)/prebuilts/runtime:$PATH" export ADB="$ANDROID_BUILD_TOP/prebuilts/runtime/adb"
aosp/main
tree:. ./build/envsetup.sh
lunch aosp_arm-eng
lunch aosp_arm64-eng
lunch aosp_x86-eng
lunch aosp_x86_64-eng
lunch aosp_riscv64-eng
m adb
art/tools/buildbot-build.sh --targetAfter building it is fine to see it finish with an error like:
linkerconfig E [...] variableloader.cc:83] Unable to access VNDK APEX at path: <path>: No such file or directory
art/tools/buildbot-cleanup-device.sh
art/tools/buildbot-setup-device.sh
art/tools/buildbot-sync.sh
art/tools/run-gtests.sh -j4
/apex/
:art/tools/run-gtests.sh \ /apex/com.android.art/bin/art/arm64/art_cmdline_tests \ /apex/com.android.art/bin/art/arm64/art_dexdump_tests
--
; see the following examples.--gtest_list_tests
:art/tools/run-gtests.sh \ /apex/com.android.art/bin/art/arm64/art_cmdline_tests \ -- --gtest_list_tests
--gtest_filter
:art/tools/run-gtests.sh \ /apex/com.android.art/bin/art/arm64/art_cmdline_tests \ -- --gtest_filter="*TestJdwp*"
--help
:art/tools/run-gtests.sh \ /apex/com.android.art/bin/art/arm64/art_cmdline_tests \ -- --help
art_runtime_tests
defined in art/runtime/gc/space/image_space_test.cc
may fail when using the full AOSP tree (b/119815008).m clean-oat-host
before the build step (art/tools/buildbot-build.sh --target
) above.-j
option of script art/tools/run-gtests.sh
is not honored yet (b/129930445). However, gtests themselves support parallel execution, which can be specified via the gtest option -j
:art/tools/run-gtests.sh -- -j4
art/test/testrunner/testrunner.py --target --64
art/test/testrunner/testrunner.py --target --32
art/tools/run-libcore-tests.sh --mode=device --variant=X64
art/tools/run-libcore-tests.sh --mode=device --variant=X32
art/tools/run-libjdwp-tests.sh --mode=device --variant=X64
art/tools/run-libjdwp-tests.sh --mode=device --variant=X32
art/tools/buildbot-teardown-device.sh
art/tools/buildbot-cleanup-device.sh