Android Security AutoRepro  |  Android Open Source Project
Skip to main content
Docs
What's new?
Release notes
Latest security bulletins
Latest Compatibility Definition Document (CDD)
Site updates
Getting Started
About
Start
Download
Builds
Test
Create
Contribute
Community
Tools, build, and related reference
Security
Overview
Bulletins
Features
Testing
Best Practices
Core Topics
Architecture
Audio
Camera
Connectivity
Data
Display
Fonts
Graphics
Interaction
Media
Performance
Permissions
Power
Runtime
Settings
Storage
Tests
Updates
Virtualization
Compatibility
Compatibility Definition Document (CDD)
Compatibility Test Suite (CTS)
Android Devices
Cuttlefish
Enterprise
TV
Automotive
Overview
Software Defined Vehicle
In-vehicle Infotainment
Release Details
Reference
HIDL
HAL
Trade Federation
Security Test Suite
Android Code Search
/
English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Polski
Português – Brasil
Tiếng Việt
Türkçe
Русский
עברית
العربيّة
فارسی
हिंदी
বাংলা
ภาษาไทย
中文 – 简体
中文 – 繁體
日本語
한국어
Sign in
Documentation
What's New?
Getting Started
Security
Core Topics
Compatibility
Android Devices
Automotive
Reference
Docs
More
What's New?
Getting Started
Security
Core Topics
Compatibility
Android Devices
Automotive
Reference
Android Code Search
Overview
Security overview
Secure an Android device
Kernel security
App security
Implement security
Updates and resources
ASPIRE
Security reports
Enhancements
Acknowledgements
Android Security Bulletins
Bulletins home
Overview
2026 bulletins
July
June
May
April
March
February
January
Android 17
2025 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 16
Android 16 QPR2
2024 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 15
2023 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 14
Index
2022 bulletins
December
November
October
September
August
July
June
May
April
March
Android 12L
February
January
Android 13
Index
2021 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 12
Index
2020 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 11
Index
2019 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android 10
Index
2018 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2017 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2016 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2015 bulletins
December
November
October
September
August
Index
Pixel/Nexus bulletins
Overview
2026 bulletins
July
June
May
April
March
February
January
2025 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2024 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2023 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2022 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2021 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2020 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2019 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2018 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Index
2017 bulletins
December
November
October
Index
Android Automotive
Overview
2026 bulletins
July
June
May
April
March
February
January
2025 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2024 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2023 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2022 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2021 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
Android XR
Overview
2026 bulletins
July
June
May
April
March
February
January
Chromecast
Overview
2025 bulletins
December
2024 bulletins
December
September
July
March
2023 bulletins
December
September
June
April
2022 bulletins
December
October
July
Wear
Overview
2026 bulletins
July
June
May
April
March
February
January
2025 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2024 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2023 bulletins
December
November
October
September
August
Pixel Watch
Overview
2026 bulletins
June
March
2025 bulletins
December
November
October
September
August
July
June
May
April
March
February
January
2024 bulletins
December
August
July
June
May
April
March
February
January
2023 bulletins
December
September
June
Advisories
Overview
March 2016
Features
Overview
Application Sandbox
OMAPI vendor stable interface
App signing
Overview
APK signature scheme v2
APK signature scheme v3
APK signature scheme v3.1
APK signature scheme v4
Authentication
Overview
Gatekeeper
Rate-limiting
Weaver
Biometrics
Overview
Measure biometric security
Fingerprint HIDL
Face authentication HIDL
Android Protected Confirmation
Overview
Implementation
UI design
Accessibility
DICE
Overview
Applications
Encryption
Overview
File-based encryption
Full-disk encryption
Metadata encryption
Enable Adiantum
Hardware-wrapped keys
Keystore
Overview
Features
Key and ID attestation
Version binding
Authorization tags
KeyMint functions
Identity Credential APIs
Overview
SELinux
Overview
Concepts
Implementation
Customization
Build sepolicy
Policy compatibility
Validation
Write policy
Vendor init
Trusty TEE
Overview
Download and build
Trusty API reference
Verified Boot
Overview
Device state
Use Verified Boot
Boot flow
Implement dm-verity
Verify system_other partition
Reference implementation
On-device signing
Safety Center
Overview
Cellular security
Overview
Disable 2G
2G connectivity toggle
Mobile network security
Private space
GPU syscall filtering
Testing
Overview
Memory safety
Arm Memory Tagging Extension
Overview
MTE bootloader support
Understand MTE reports
MTE configuration
Sanitizers
Overview
AddressSanitizer
Kernel AddressSanitizer
Hardware-assisted AddressSanitizer
Understand HWASan reports
UndefinedBehaviorSanitizer
Other topics
Control flow integrity
Control flow integrity in the kernel
Execute-only memory
Fuzz with libFuzzer
GWP-ASan and KFENCE
Android Security AutoRepro
Scudo
ShadowCallStack
Tagged pointers
Zero initialized memory
Best practices
Overview
Organizational and operational security
System security
App security
Network security
Hardware security
Privacy security
What's new?
Release notes
Latest security bulletins
Latest Compatibility Definition Document (CDD)
Site updates
Getting Started
About
Start
Download
Builds
Test
Create
Contribute
Community
Tools, build, and related reference
Security
Overview
Bulletins
Features
Testing
Best Practices
Core Topics
Architecture
Audio
Camera
Connectivity
Data
Display
Fonts
Graphics
Interaction
Media
Performance
Permissions
Power
Runtime
Settings
Storage
Tests
Updates
Virtualization
Compatibility
Compatibility Definition Document (CDD)
Compatibility Test Suite (CTS)
Android Devices
Cuttlefish
Enterprise
TV
Automotive
Overview
Software Defined Vehicle
In-vehicle Infotainment
Release Details
Reference
HIDL
HAL
Trade Federation
Security Test Suite
Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, use android-latest-release. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP. For more information, see Changes to AOSP.
AOSP
Docs
Security
Android Security AutoRepro
Stay organized with collections
Save and categorize content based on your preferences.
The AutoRepro Gradle plugin is built on top of the
Android Trade Federation test harness to test all
Android devices for security patch tests against vulnerabilities in the
Android Security Bulletin.
These tests are exclusively for fixes that are associated or will be associated
with a Common Vulnerabilities and Exposures (CVE).
The plugin allows development of Tradefed 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 a Tradefed test.
It is primarily used to submit automatically reproducible proof-of-concepts for
the
Android Vulnerability Rewards Program.
Direct Download AutoRepro Example download
Browse AutoRepro Example and Templates open_in_new
Prerequisites
Instructions are provided for a 64-bit Linux PC.
Android Studio Ladybug or newer -
Can also be installed from your distro's package manager.
Android SDK 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.
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.
AAPT2. - Can also be
installed using your distro's package manager.
Java JDK 21 or newer - compatible with the Android SDK and Gradle.
Note: See the CTS guide for more
details on setting up ADB and AAPT2.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.
Get started using Android Studio
After extracting the example or template, open the directory in Android Studio
as an existing project and wait for Gradle sync to complete. There are several
preconfigured Android Studio run configurations.
Gradle tasks:
assembleSubmissionSources - Assemble the source files for the submission
zip.
assembleSubmissionZip - Assemble the submission zip for upload.
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.
Tip: Running copyInvocationResultsToSubmission can help your submission be
reviewed faster by directly providing logs and results from your device and
host.
AutoRepro invocation Android Studio run configurations:
autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64
The launcher configurations are in the form
autorepro_{device_root}_{device_arch}. It's generally preferable to use
nonroot because vulnerabilities requiring root are less severe. However, using
root to perform setup or cleanup can be acceptable so long as it is clearly
documented and is generally accepted as a valid nonroot state. For example, it's
acceptable to use root to fake send text messages to the device to avoid
requiring a second device and multiple SIM cards.
These will launch Tradefed for your test. Tradefed waits for a valid device to
be connected so ensure one is connected and ADB debugging authorized.
Integration with coding agents
The example and templates provide an AGENTS.md context file compatible with
Gemini in Android Studio, Gemini CLI, and other coding agents. It has content
with opinions on submission structuring and instructions on using AutoRepro. You
can use this to:
Automatically run AutoRepro for your device
Code review an existing submission for changes that can help your report get
accepted faster
Help structure a new PoC given information on the vulnerability
Write an AutoRepro test
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.
There are three parts to an AutoRepro test and three corresponding Gradle
plugins:
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.
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.
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.
A typical AutoRepro test flow usually follows one of two patterns:
Instrumented test app:
The host-side test pushes an APK consisting of an instrumented app or
service onto the device.
The host-side test starts the device-side JUnit tests that is bundled
with the APK through runDeviceTest().
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.
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.
NDK proof-of-concept:
The host-side test pushes and launches a Linux 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. 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.
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.
Proof-of-concept provability structuring
A high-quality PoC must do more than trigger a bug; it should provide verifiable
proof that a security boundary has been crossed. To achieve this, PoCs can
follow a specific three-step "fail-then-succeed" pattern:
Setup: Prepare the device by installing necessary apps, pushing files,
and ensuring the device is in the specific state required immediately before the
exploit. (Root usage is permitted for configuration if justified and
representative of a realistic end-user state).
Prove the Boundary: Before triggering the vulnerability, attempt the
target action and assert that it fails. For example, if the exploit allows
reading a protected file, you must first attempt to read it and confirm you
receive a "Permission Denied" error.
Trigger & Verify: Trigger the vulnerability, then immediately repeat the
action from Step 2. On a vulnerable device, this action should now succeed. To
verify this, you must use an assertion that fails on a vulnerable device with a
message starting with the exact prefix AUTOREPRO_VULNERABILITY_PROVEN:. This
message must include a concise description of the vulnerability and any captured
artifacts (such as leaked data or unexpected states) to definitively prove the
exploit was successful.
Example:
@Test
public void testPoc() throws Exception {
// 1. Setup: Prepare the device.
setup();
// 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
// This passes on all devices (safe or vulnerable) before the trigger runs.
assertDeviceIsSecure();
// 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
// the action from Step 2. On a vulnerable device, this action should now
// succeed, causing assertDeviceIsSecure() to fail with an
// AUTOREPRO_VULNERABILITY_PROVEN message.
triggerExploit();
assertDeviceIsSecure();
}
private void assertDeviceIsSecure() {
try {
String content = readProtectedFile();
// Where possible, put the content in the assertion message.
// Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
} catch (ThisVulnSpecificException e) {
Log.i(TAG, "protected against reading protected file", e);
}
}
My proof-of-concept attack doesn't need a test app or native executable
Most tests won't need both a device-side app and a native executable.
If your test does not involve the use a feature, delete the unnecessary gradle
subproject directories.
My proof-of-concept attack involves a second app or service
Add as many Gradle subprojects with AutoRepro plugins as you like.
Submit the AutoRepro test
To include test results from your device as part of the submission:
Optionally run the Gradle clean task to delete any old test runs.
Run the appropriate AutoRepro run configuration to invoke Tradefed for your
test and collect logs and results.
Run the copyInvocationResultsToSubmission task to copy the logs and
results into the submission sources directory.
Run the assembleSubmissionZip to create the
submission/build/autorepro-submission.zip file. Upload that file along with
your submission to the Android Vulnerability Reward Program. Ensure that the
attachment matches the pattern *autorepro-submission*.zip and that it is
uploaded with the initial report. Uploading submissions late will impact our
ability to properly review your report.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2026-06-17 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-17 UTC."],[],[]]
Build
Android repository
Requirements
Downloading
Preview binaries
Factory images
Driver binaries
Connect
@Android on X
@AndroidDev on X
Android Blog
Google Security Blog
Platform on Google Groups
Building on Google Groups
Porting on Google Groups
Get help
Android Help Center
Pixel Help Center
www.android.com
Google Mobile Services
Stack Overflow
Issue Tracker
About Android
Community
Legal
License
Privacy
Site feedback
Manage cookies
English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Polski
Português – Brasil
Tiếng Việt
Türkçe
Русский
עברית
العربيّة
فارسی
हिंदी
বাংলা
ภาษาไทย
中文 – 简体
中文 – 繁體
日本語
한국어