Run Android tests using GitHub actions #2945
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 8888886252Details
💛 - Coveralls |
…oid tests using an Android emulator.
ChrisThrasher
force-pushed
the
feature/run_android_tests
branch
from
70e3648
to
fdb604b
Compare
ChrisThrasher
approved these changes
May 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Title.
Runs Android tests on x86, x86_64 and arm64-v8a. armeabi-v7a is already quite old and there isn't emulator support for it.
To run the tests, an Android Virtual Device (AVD) is created with a default Android system image using the specified emulator API and emulator architecture. Not all combinations are available, the emulator API and architectures in this change are the latest I could find that would still be able to run the tests.
Because we only dynamic link on Android, we also need to copy all the executables and dynamic libraries (including libc++) over to the device as well as the resources that the tests themselves need to pass. The directory containing the libraries is specified using
LD_LIBRARY_PATHwhen running the executable. We can only copy files into a subdirectory of/data/local/tmp/on the device since everything else is read-only.Because Catch doesn't currently support a nice way of running tests on a foreign system, we have to make use of the
CROSSCOMPILING_EMULATORtarget property that Catch uses when building the command line that it executes. Instead of directly executing the test executable, it calls a specially crafted proxy shell script that takes care of setting the working directory on the device, settingLD_LIBRARY_PATHand adding the/data/local/tmp/directory prefix onto the absolute path to the executable that Catch passes to us. Hopefully Catch supports such use cases better in the future.Coverage data collection is missing because, well... it doesn't seem to be supported, or at least it wasn't obvious to me how to activate generation of profiling data when the executable is run.