Security Test Suite Trade Federation (sts-tradefed) is built on top of the Android Trade Federation test harness to test all Android devices for security patch tests that don't fall into the Compatibility Test Suite. These tests are exclusively for fixes that are associated (or will be associated) with a Common Vulnerabilities and Exposures (CVE).
The SDK allows development of STS tests outside of the Android source tree using Android Studio or the standard Android SDK. It includes all utilities that are needed to build and run an STS test.
- 64-bit Linux PC.
- Android Studio (can also be installed from your distro's package manager.
- Android platform tools
fastboot) need to be installed and be in your
$PATH(i.e. you should be able to run
adbfrom the command line). The easiest way to install the platform tools is via your distro's package manager.
- If using Android Studio's SDK manager instead of standalone platform
tools, remember to add the SDK's
platform-toolsdirectory to your $PATH.
- If using Android Studio's SDK manager instead of standalone platform tools, remember to add the SDK's
- aapt, which can also be installed via your distro's package manager.
Get started using Android Studio
After extracting the archive, open the directory in Android Studio as an
existing project. Run the
assembleSTSx86 build target to
build the skeleton test, depending on the architecture of the target Android
device. Run the
runSTS build target to run the skeleton test on the connected
device (ADB must be authorized).
Get started using Gradle
After extracting the archive, set the
sdk.dir property in the
local.properties file at the root of the Gradle project, then run the
assembleSTSARM Gradle task to build the skeleton test. After the build is
finished, the test can be run by navigating (
build/android-sts/tools and executing the
$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties $ ./gradlew assembleSTSARM $ cd build/android-sts/tools $ ./sts-tradefed run sts-dynamic-develop -m hostsidetest
Write an STS test
There are three parts to an STS test:
- A host-side Tradefed test that interacts with the device through adb, in the
- An optional native proof-of-concept attack that is pushed onto the
adb pushand executed by the host-side test in the
- An optional app or service APK that is installed onto the device through
adb installand also launched by the host-side test. The app or service can also contain its own set of JUnit assertions that is reported to the host-side runner. This is in the
A typical STS test flow usually follows one of two patterns:
- The host-side test pushes and launches a native executable on the device.
- The native program crashes or returns a specific exit code.
- The host-side test checks for crashes, looks at the logcat backtrace, or looks for the specific exit code to determine whether the attack succeeded.
Instrumented test app:
- The host-side test pushes an APK consisting of an app or service onto the device.
- The host-side test starts the device-side JUnit tests that is bundled
with the APK through
- The device-side JUnit tests taps buttons and watches the app using UIAutomator, or otherwise accesses the Android system in ways that reveal security vulnerabilities.
- The success or failure of the device-side JUnit tests is returned to the host-side test, which can be used to determine if the test passed or not.
A combination of the two patterns (for example, running of a native program in
conjunction with device-side tests) is also possible. Some other instrumentation
frameworks, such as
frida-inject, are also available.
For details, see the
Security Test Suite reference docs and the
Tradefed reference docs.
My proof-of-concept attack does not need a test app and/or native executable
Most tests will not need both a device-side app and a native executable.
If your test does not involve the use of an on-device app/service, simply delete
test-app subdirectory. Similarly, if your test does not use a native
executable, delete the
native-poc subdirectory then Gradle-sync the project.
The project is set up to automatically skip building those modules when they
My proof-of-concept attack involves a second app/service
First, add a new Module to your project for your second app/service and write that like you would any other APK.
build.gradle at the root of this directory and add your module
following the instructions in
assembleStsx86. This will ensure the compiled APK is copied to the output
directory of STS and enables installing/calling of the new app form the test.
Finally, Gradle-sync the project.
Submitting the STS test
zipForSubmission task (either with Android Studio or with Gradle on the
command line). A new file,
codesubmission.zip, should be created in
directory at the root of the project. Upload that file along with your
submission to the Android Vulnerability Reward Program.