You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-if <class-spec> <one-keep-rule>
Conditionally apply one keep rule. If class members are specified, the class and all specified members must match. Otherwise, only the class need match. Class specification in the keep rule can contain back references to wildcards in the -if class specification. (ProGuard docs -if)
eg.
-if @KeepGoogleUtils keep public class com.google.api.client.googleapis.GoogleUtils
In the example above, users who want to keep the GoogleUtils only need to include the @KeepGoogleUtils annotation somewhere in the app source code.
If you can segment parts of the library that can be kept seprately, then you can create several different annotation. For example, if your library has a Payments section and a Mapping section and a Messaging section, and the code can be cleanly separated by package name or class names, then you could have annotations like @KeepGUtilsPayments, @KeepGUtilsMapping and @KeepGUtilsMessaging. That way the built binary doesn't need to include parts of the library that won't be used.
The keep rules that ship with the library should represent the segments.
eg.
-if @KeepGUtilsPayments keep public class com.google.api.client.googleapis.Payments -if @KeepGUtilsMapping keep public class com.google.api.client.googleapis.Mapping -if @KeepGUtilsMessaging keep public class com.google.api.client.googleapis.Messaging
Activity
justcla commentedon Feb 14, 2020
I recommend using conditional keep-rules. These can be triggered based on the inclusion of specific annotations in the app's code base.
justcla commentedon Feb 14, 2020
From Unofficial R8 documentation:
eg.
-if @KeepGoogleUtils keep public class com.google.api.client.googleapis.GoogleUtilsIn the example above, users who want to keep the GoogleUtils only need to include the
@KeepGoogleUtilsannotation somewhere in the app source code.justcla commentedon Feb 14, 2020
If you can segment parts of the library that can be kept seprately, then you can create several different annotation. For example, if your library has a Payments section and a Mapping section and a Messaging section, and the code can be cleanly separated by package name or class names, then you could have annotations like
@KeepGUtilsPayments,@KeepGUtilsMappingand@KeepGUtilsMessaging. That way the built binary doesn't need to include parts of the library that won't be used.The keep rules that ship with the library should represent the segments.
eg.