[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-25 UTC。"],[],[],null,["# Android Security AutoRepro\n\nThe AutoRepro Gradle plugin is built on top of the\n[Android Trade Federation](/docs/core/tests/tradefed) test harness to test all\nAndroid devices for security patch tests against vulnerabilities in the\n[Android Security Bulletin](/docs/security/bulletin).\nThese tests are exclusively for fixes that are associated or will be associated\nwith a Common Vulnerabilities and Exposures (CVE).\n\nThe plugin allows development of Tradefed tests outside of the Android source\ntree using Android Studio or the standard Android SDK. It includes all utilities\nthat are needed to build and run a Tradefed test.\n\nIt is primarily used to submit automatically reproducible proof-of-concepts for\nthe\n[Android Vulnerability Rewards Program](https://bughunters.google.com/about/rules/android-friends/6171833274204160/android-and-google-devices-security-reward-program-rules).\n\n[Download AutoRepro Example download](https://android-security-tools.googlesource.com/autorepro/+archive/main/example.tar.gz)\n\nPrerequisites\n-------------\n\nInstructions are provided for a 64-bit Linux PC.\n\n- [Android Studio Ladybug or newer](https://developer.android.com/studio) - Can also be installed from your distro's package manager.\n- [Android SDK platform tools](https://developer.android.com/studio/releases/platform-tools) (`adb`, `fastboot`) - Need to be installed and be in your `$PATH` (That is, you should be able to run `adb` from the command line). The easiest way to install the platform tools is using your distro's package manager.\n - If using Android Studio's SDK manager instead of standalone platform tools, remember to add the SDK's `platform-tools` directory to your `$PATH` for command-line development.\n- [AAPT2](https://developer.android.com/tools/aapt2). - Can also be installed using your distro's package manager.\n- Java JDK 21 or newer - compatible with the Android SDK and Gradle.\n\n| **Note:** See [the CTS guide](/docs/compatibility/cts/setup#adb-aapt) for more details on setting up ADB and AAPT2.\n| **Caution:** AutoRepro only officially supports 64-bit Linux machines. While tests written with AutoRepro may build and run on Windows or macOS, they must also be compatible with Linux for submission.\n\nGet started using Android Studio\n--------------------------------\n\nAfter extracting the example or template, open the directory in Android Studio\nas an existing project and wait for Gradle sync to complete. There are several\npreconfigured Android Studio run configurations.\n\nGradle tasks:\n\n- `assembleSubmissionSources` - Assemble the source files for the submission zip.\n- `assembleSubmissionZip` - Assemble the submission zip for upload.\n- `copyInvocationResultsToSubmission` - Copy the results from previous Tradefed invocations into the AutoRepro submission sources directory to assist with the review process. Note that this contains logs from both the host and device; review the contents before or after running this.\n\n| **Tip:** Running `copyInvocationResultsToSubmission` can help your submission be reviewed faster by directly providing logs and results from your device and host.\n\nAutoRepro invocation Android Studio run configurations:\n\n- `autorepro_nonroot_arm64`\n- `autorepro_nonroot_x86_64`\n- `autorepro_root_arm64`\n- `autorepro_root_x86_64`\n\nThe launcher configurations are in the form\n`autorepro_{device_root}_{device_arch}`. It's generally preferable to use\nnonroot because vulnerabilities requiring root are less severe. However, using\nroot to perform setup or cleanup can be acceptable so long as it is clearly\ndocumented and is generally accepted as a valid nonroot state. For example, it's\nacceptable to use root to fake send text messages to the device to avoid\nrequiring a second device and multiple SIM cards.\n\nThese will launch Tradefed for your test. Tradefed waits for a valid device to\nbe connected so ensure one is connected and ADB debugging authorized.\n\nWrite an AutoRepro test\n-----------------------\n\n| **Note:** An AutoRepro test fails when the device is vulnerable and passes when the device is patched or otherwise not vulnerable. One major advantage of this approach is that the failure message should contain detailed information about the vulnerability and any artifacts generated by the PoC. The test should return an `ASSUMPTION_FAILURE` (for example, by using JUnit `Assume` instead of `Assert`) when it can't determine whether the device is vulnerable or not.\n\nThere are three parts to an AutoRepro test and three corresponding Gradle\nplugins:\n\n1. Gradle plugin `id(\"com.android.security.autorepro.javahosttest\")` The single host-side Tradefed test that interacts with the device through ADB. The example uses it in the `submission/hostTest/` directory.\n2. Gradle plugin `id(\"com.android.security.autorepro.apptest\")` An app or service APK that is installed onto the device through `adb install` and 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. The example uses it in the `submission/appTest/` and directory.\n3. Gradle plugin `id(\"com.android.security.autorepro.ndktest\")` An optional NDK-based proof-of-concept attack that is pushed onto the device through `adb push` and executed by the host-side test. The example uses it in the `submission/ndkTest/` directory.\n\nA typical AutoRepro test flow usually follows one of two patterns:\n\n- Instrumented test app:\n\n 1. The host-side test pushes an APK consisting of an instrumented app or service onto the device.\n 2. The host-side test starts the device-side JUnit tests that is bundled with the APK through `runDeviceTest()`.\n 3. The device-side JUnit tests taps buttons and watches the app using UIAutomator, or otherwise accesses the Android APIs in ways that reveal security vulnerabilities.\n 4. 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. The failure message should contain detailed information on why the assertion failed and any specific objects, values, exceptions, stacktraces, or other artifacts as proof of vulnerability.\n- NDK proof-of-concept:\n\n 1. The host-side test pushes and launches a Linux executable on the device.\n 2. The native program crashes or returns a specific exit code.\n 3. 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. The failure message should contain detailed information on why the assertion failed and any specific structs, values, stacktraces, or other artifacts as proof of vulnerability.\n\nA combination of the two patterns (for example, running of a native program in\nconjunction with device-side tests) is also possible. Some other instrumentation\nframeworks, such as `frida-inject`, are also available. For details, see the\n[Security Test Suite reference docs](/reference/sts/packages) and the\n[Tradefed reference docs](/reference/tradefed/packages).\n\n### My proof-of-concept attack doesn't need a test app or native executable\n\nMost tests will not need both a device-side app and a native executable.\n\nIf your test does not involve the use a feature, delete the unnecessary gradle\nsubproject directories.\n\n### My proof-of-concept attack involves a second app/service\n\nAdd as many Gradle subprojects with AutoRepro plugins as you like.\n\nSubmit the AutoRepro test\n-------------------------\n\nTo include test results from your device as part of the submission:\n\n- Optionally run the Gradle `clean` task to delete any old test runs.\n- Run the appropriate AutoRepro run configuration to invoke Tradefed for your test and collect logs and results.\n- Run the `copyInvocationResultsToSubmission` task to copy the logs and results into the submission sources directory.\n\nRun the `assembleSubmissionZip` to create the\n`submission/build/autorepro-submission.zip` file. Upload that file along with\nyour submission to the Android Vulnerability Reward Program. Ensure that the\nattachment matches the pattern `*autorepro-submission*.zip` and that it is\nuploaded with the initial report. Uploading submissions late will impact our\nability to properly review your report."]]
