This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Improve resulting APK size by using @Keep annotation #12490
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #8978.
Up to this point, when Proguard was run we were keeping all class in the
com.mapbox.mapboxsdk
package, forbidding removal of unused methods or obfuscation. This PR proposes a switch to@Keep
annotation to indicate which resources should be left untouched by Proguard. This targets any code that references Java classes, methods or fields from JNI context, or generally via reflection.As this can be error-prone, because it's extremely easy to forget to add a
@Keep
annotation or an entry in theproguard-rules.pro
file, which will result in runtime errors, this PR adds lint checks that will make the tests fail. Those checks search for:native
modificator - those need to be kept at all costlong
and containsnative
substring in the name - by convention, this is how we name native pointer for peer objects. This should catch most of the cases, but is by no means sufficient, we need to pay attention to native pointers being kept ourselves.long
type parameter which containsnative
substring in the name - similarly to above, by convention, these are constructor invoked from JNI.For classes that are referenced by the JNI and are outside of the
com.mapbox.mapboxsdk
we should add an entry to theproguard-rules.pro
file.The most important thing is to remember about keeping Java fields, methods or constructors referenced from the native context, other than above, as those won't be highlighted by the lint check.
The quick tests show, that by minifying our test app we are able to:
What's worth noting is that this was done on the internal test app which uses the Maps SDK in nearly every possible way. Benefits in regular consumer apps will be even greater.
I tested the stability by running every single activity in the internal test app and exhausting its options, let me know if there is anything else I can do.
/cc @mapbox/maps-android @mapbox/gl-core