Description
The consumer ProGuard rules bundled with the Mapbox Maps and Search SDKs contain several app-wide and package-wide rules that significantly restrict R8 shrinking, optimization, and obfuscation outside Mapbox code.
We found this using AGP’s R8 configuration analyzer.
Versions
com.mapbox.maps:android-ndk27:11.16.4
com.mapbox.common:common-ndk27:24.16.4
com.mapbox.search:mapbox-search-android-ndk27:2.15.0
com.mapbox.search:base-ndk27:2.15.0
- Android Gradle Plugin:
9.3.1
- R8 full mode
proguard-android-optimize.txt
- Minification and resource shrinking enabled
Highest-impact rules
Global enum rule
com.mapbox.search:base-ndk27:2.15.0 bundles:
-keepclassmembers enum * {
<fields>;
}
Because this targets enum *, it affects enums throughout the entire application and all dependencies—not only Mapbox enums.
In our application it matches 10,916 fields and prevents shrinking, optimization, and obfuscation for them.
Could this be scoped to Mapbox Search enum types that require name preservation?
Entire Maps SDK package
-keep class !com.mapbox.maps.extension.**,!com.mapbox.maps.plugin.**,com.mapbox.maps.** {
*;
}
This matches:
- 748 classes
- 3,725 fields
- 4,815 methods
- 9,288 items total
Could this rule be narrowed to classes and members accessed through JNI, reflection, or serialization?
Entire Mapbox Common package
-keep class com.mapbox.common.** {
*;
}
This matches:
- 711 classes
- 1,405 fields
- 3,322 methods
- 5,438 items total
Could this be replaced with surgical rules for JNI-bound or reflectively accessed types?
Entire Gson library
com.mapbox.maps:android-ndk27:11.16.4 bundles:
-keep class com.google.gson.** {
*;
}
This keeps the complete Gson implementation, including code unrelated to Mapbox.
In our application it matches:
- 221 classes
- 469 fields
- 1,244 methods
- 1,934 items total
Modern Gson versions bundle their own consumer rules. Could this blanket rule be removed and replaced with rules targeting only Mapbox models that require Gson reflection?
Search bindgen package
-keep class com.mapbox.search.internal.bindgen.** {
*;
}
This matches:
- 114 classes
- 636 fields
- 820 methods
- 1,570 items total
If these classes are JNI-bound, could the rule permit optimization or shrinking where native lookup does not depend on the affected symbol?
Redundant rules
SerializedName fields
Mapbox Search bundles:
-keepclassmembers,allowobfuscation class * {
@com.google.gson.annotations.SerializedName <fields>;
}
This matches 703 fields. The analyzer reports it as subsumed by Gson’s bundled conditional rule:
-if class *
-keepclasseswithmembers,allowobfuscation class <1> {
@com.google.gson.annotations.SerializedName <fields>;
}
Could the Mapbox copy be removed in favour of Gson’s consumer configuration?
Unused legacy package rules
The following rules match no items in our application:
-keep class com.mapbox.mapboxsdk.log.** {
*;
}
-keep class com.mapbox.mapboxsdk.text.** {
*;
}
Could these legacy rules be removed from the current Maps SDK consumer configuration?
Aggregate impact
Accounting for overlap with rules from other dependencies, Mapbox-originating rules uniquely restrict approximately:
- 25,010 items from optimization
- 17,046 items from shrinking
- 15,901 items from obfuscation
These are R8 pre-optimization item counts, not APK byte-size measurements, and some rules are clearly required for correct JNI or reflection behaviour. They indicate the available optimization headroom if the consumer rules can be made more surgical.
Requested improvement
Would you consider reviewing the bundled consumer rules to:
- Scope wildcard rules to Mapbox-owned packages.
- Preserve only types and members accessed through JNI, reflection, or serialization.
- Apply
allowoptimization, allowshrinking, or allowobfuscation where safe.
- Remove the blanket Gson keep rule and rely on Gson’s bundled configuration.
- Remove rules subsumed by dependency-provided consumer rules.
- Remove unused rules for legacy Mapbox packages.
Description
The consumer ProGuard rules bundled with the Mapbox Maps and Search SDKs contain several app-wide and package-wide rules that significantly restrict R8 shrinking, optimization, and obfuscation outside Mapbox code.
We found this using AGP’s R8 configuration analyzer.
Versions
com.mapbox.maps:android-ndk27:11.16.4com.mapbox.common:common-ndk27:24.16.4com.mapbox.search:mapbox-search-android-ndk27:2.15.0com.mapbox.search:base-ndk27:2.15.09.3.1proguard-android-optimize.txtHighest-impact rules
Global enum rule
com.mapbox.search:base-ndk27:2.15.0bundles:Because this targets
enum *, it affects enums throughout the entire application and all dependencies—not only Mapbox enums.In our application it matches 10,916 fields and prevents shrinking, optimization, and obfuscation for them.
Could this be scoped to Mapbox Search enum types that require name preservation?
Entire Maps SDK package
This matches:
Could this rule be narrowed to classes and members accessed through JNI, reflection, or serialization?
Entire Mapbox Common package
This matches:
Could this be replaced with surgical rules for JNI-bound or reflectively accessed types?
Entire Gson library
com.mapbox.maps:android-ndk27:11.16.4bundles:This keeps the complete Gson implementation, including code unrelated to Mapbox.
In our application it matches:
Modern Gson versions bundle their own consumer rules. Could this blanket rule be removed and replaced with rules targeting only Mapbox models that require Gson reflection?
Search bindgen package
This matches:
If these classes are JNI-bound, could the rule permit optimization or shrinking where native lookup does not depend on the affected symbol?
Redundant rules
SerializedName fields
Mapbox Search bundles:
This matches 703 fields. The analyzer reports it as subsumed by Gson’s bundled conditional rule:
Could the Mapbox copy be removed in favour of Gson’s consumer configuration?
Unused legacy package rules
The following rules match no items in our application:
Could these legacy rules be removed from the current Maps SDK consumer configuration?
Aggregate impact
Accounting for overlap with rules from other dependencies, Mapbox-originating rules uniquely restrict approximately:
These are R8 pre-optimization item counts, not APK byte-size measurements, and some rules are clearly required for correct JNI or reflection behaviour. They indicate the available optimization headroom if the consumer rules can be made more surgical.
Requested improvement
Would you consider reviewing the bundled consumer rules to:
allowoptimization,allowshrinking, orallowobfuscationwhere safe.