Tighten keep rule

[elharo]

See #1491

@justcla suggests we can tighten this rule so the class is not always retained.

[justcla]

I recommend using conditional keep-rules. These can be triggered based on the inclusion of specific annotations in the app's code base.

[justcla]

From Unofficial R8 documentation:

-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.

[justcla]

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