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.
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.