The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
In normal cases, adb_clean.py cleaning the temporal directory is a good
idea because all the tests run in a clean state, and previous executions
do not influence the current one.
However, when iterating and running only one or two tests with
utils/run-test, removing all the artifacts and uploading them to the
device can turn each iteration into waiting a couple of minutes. Since
the changes in between tests should only touch a couple of libraries (or
none at all, if the test itself is the modification), avoiding a full
clean is beneficial.
The commit modifies `adb_clean.py` to allow providing the environment
variable `SKIP_ANDROID_CLEAN`, which will simply not execute the script.
Since the introduction of #24146, only the modified
artifacts will be uploaded, and the test iteration can be very fast
(including no time, if there are no changes).
In recent adb versions, the push command supports a new option --sync
which performs checksumming of the files to transmit against the files
already in the device. This increases the effective transmission speed
of the inital step in the test for Android.
It should not affect the speed of each tests, since they are pushed to
different folders, and also they are removed when they are successful.
However, the test executables are small compared to the size of the
libraries from the stadard library and dependencies.
This should exclusively affect Android and only to people testing the
executable tests (not CI).
At least test_rth.swift is checking the name of the executable
during the test, so renaming every executable to __executable in
Android will never work.
Also, during the rth tool execution, all the results from before
and after are pushed for every test. Since Android copies the
passed files without relative paths, the library files will
overwrite each other, making the test fail.
Depends on #19949 (more or less)
Some tests need more than just the executable to be pushed. For
example the resilience tests need the executable and the linked
library to be pushed. adb_test_runner.py only pushed the
executable.
The changes look into the arguments passed to the executable
and figure out which ones refer to files. Those files are pushed
to the device and transformed to refer to the path on the device
instead (the resilience test do not actually use the argument
values themselves, but maybe others do).
When running tests in an Android device, the environment variables
were not passed to the device, which make some test fail, like
stdlib/HashingRandomization that test with and without the
environment variable SWIFT_DETERMINISTIC_HASHING.
The changes implement a process similar to what the iOS simulator
already seem to do: a variable prefix which is pick up by the
adb_test_runner.py and send to the device for the test.
This adds support for running tests for the stdlib built
for Android, both on the host machine and on an Android device.
The Android variant of Swift may be built and tested using
the following `build-script` invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
-T \ # Run all tests.
--android \ # Build for Android.
--android-deploy-device-path /data/local/tmp \ # Temporary directory on the device where Android tests are run.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
See docs/Testing.rst for more details.
