ABANDONED [android] Create per-package configuration for multidex.

build/android/main_dex_classes.flags

 -keep @**.MainDex class * {
   *;
 }
 
 -keepclasseswithmembers class * {
   public static ** asInterface(android.os.IBinder);
 }
 
 # Required when code coverage is enabled.
 -keep class com.vladium.** {
     *;
 }
+
+-keep class **.PackageConfig {

[agrieve, 2017/04/21 15:43:31]

It's always preferable to use @UsedByReflection rather than adding flags. Would
that work in this case?

[jbudorick, 2017/04/21 16:03:57]

No, the annotations from org.chromium.base.annotations don't work here. I tried
quite a few ways to use @MainDex s.t. PackageConfig was covered by the -keep
above. The issue is in how and under what circumstances we generate these
per-target files via java_cpp_template in android_apk. We assume that any
android_apk target we generate is, at some level, dependent on //base:base_java.
That isn't necessarily the case -- currently, webapk_javatests has no base_java
dependency -- and when it isn't, the java files we have here break.
(webapk_javatests avoids this w/ NativeLibraries.java because it has no native
library.)

Anyhow, I tried all of the following:
 1. using @MainDex without modifying any dependencies. Fails when base_java
isn't one of the indirect dependencies of the android_apk.
 2. using @MainDex w/ base_java added into the deps written to the build_config
s.t. the resulting java_library_impl target is built against it. Fails when
there's no native library and thus no NativeLibraries.
 3. #2 but always generate NativeLibraries. Fails due to collision when building
test APKs.

I would like to figure out a way to use @MainDex here, but I'm beginning to
think that doing so would require reworking how and when we generate those
per-apk java files. That's a bit bigger scope than I want to take on at the
moment.

[agrieve, 2017/04/21 16:48:42]

Sounds good. Thanks for the details :)

+  public static final boolean IS_MULTIDEX_ENABLED;
+}