ProGuard configuration
You can skip this guide if you are working solely with debug builds (android.emu.debug
, etc.),
but as soon as you move to the release builds, where the native code gets minified and obfuscated,
you are going to have problems with Detox if you leave your ProGuard rules not configured.
Since Detox relies on Android Reflection API to integrate with React Native on Android, you should keep ProGuard minification under tight control. Otherwise, you’ll be seeing Detox crashing or hanging up infinitely upon an attempt to run tests with your app built in release mode.
To fix that, you’d need to return to your app build script:
buildTypes {
…
release { /* (1) */
minifyEnabled true
/* (2) */ proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
+ /* (3) */ proguardFile "${rootProject.projectDir}/../node_modules/detox/android/detox/proguard-rules-app.pro"
}
}
release
build type is typically the one to have ProGuard enabled.- ProGuard files present by default in React Native projects. Check out Android docs to get to know more.
- Detox-specific exclude list for ProGuard.
In order for Detox to be able to work properly, in proguard-rules-app.pro
, it effectively declares rules that retain most of React-Native’s code (i.e. keep it unminified, unobfuscated) in your production APK.
Obfuscation
Exempting source files from the obfuscation means that their contents might be restored by unauthorized people, but this should not be an issue for you, because React Native is an open-source project per se.
If it nevertheless bothers you, there are workarounds such as defining multiple build flavors: one for running end-to-end tests with Detox, and the other one for publishing to the marketplaces:
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
releaseE2E {
initWith release
setMatchingFallbacks('release')
proguardFile "${rootProject.projectDir}/../node_modules/detox/android/detox/proguard-rules-app.pro"
}
}
As can be seen above, we use initWith
and setMatchingFallbacks
to extend the new releaseE2E
build type from
the existing one, and then we add an override to it, i.e. proguardFile
.
Following the example, you would then have to adjust your build
and binaryPath
properties accordingly:
{
apps: {
'android.release': {
type: 'android.apk',
- binaryPath: 'android/app/build/outputs/apk/release/app-release.apk',
+ binaryPath: 'android/app/build/outputs/apk/releaseE2E/app-releaseE2E.apk',
- build: 'cd android && ./gradlew assembleRelease assembleAndroidTest -DtestBuildType=release'
+ build: 'cd android && ./gradlew assembleReleaseE2E assembleAndroidTest -DtestBuildType=release'
},`
If your app already contains flavors – that makes things a bit trickier, but the approach can generally be adjusted to support that as well.
Last but not least: If you’re having issue with Detox' ProGuard rules, please report them here.
A special thanks to @GEllickson-Hover for reporting issues related to obfuscation in #2431.