[Android] Rework multidex and enable multidex for unit_tests_apk.

build/config/android/rules.gni

Index: build/config/android/rules.gni
diff --git a/build/config/android/rules.gni b/build/config/android/rules.gni
index d54779689bbd5c9b1b7b03292c4938a4d1b81f77..5be33d3a4a7dc70336efb1675916c447b6c1a72a 100644
--- a/build/config/android/rules.gni
+++ b/build/config/android/rules.gni
@@ -1483,6 +1483,19 @@ template("android_apk") {
     _srcjar_deps += [ ":${_template_name}__native_libraries_java" ]
   }
 
+  java_cpp_template("${_template_name}__multidex_config_java") {
+    package_name = "org/chromium/base/multidex"
+    sources = [
+      "//base/android/java/templates/ChromiumMultiDex.template",
+    ]
+
+    defines = []
+    if (enable_multidex) {
+      defines += [ "ENABLE_MULTIDEX" ]
+    }
+  }
+  _srcjar_deps += [ ":${_template_name}__multidex_config_java" ]

[agrieve, 2016/01/12 03:48:28]

I think this adds ChromiumMultidex.java to *every* android_apk. Not sure we want
that... If we want this to work so that the file is only included when base_java
is included, then it'll need to add logic to write_build_config.py I think. 

I think maybe the best thing to do is add support for generating a BuildConfig
class like Gradle does. I could certainly help with that. WDYT?

[jbudorick, 2016/01/12 04:48:11]

Didn't do anything here yet pending further discussion.

On 2016/01/12 03:48:28, agrieve wrote:
It does, though ChromiumMultiDex.java is now just a single static function that
imports nothing. There are a few APKs that don't appear to depend on base_java
(mostly customtabs related), but it's definitely an edge case at the moment.
I'm not particularly familiar with Gradle, but at a glance that seems reasonable
to me. What would we put in there? MultiDex + NativeLibraries + ?

[agrieve, 2016/01/12 20:25:46]

Ironically, the best docs I could find are from buck:
https://buckbuild.com/rule/android_build_config.html

For gradle / ant apps, the build injects a class called
YOUR_APP_PACKAGE.BuildConfig, which by default just has DEBUG = true / false. We
could add this and extend it to also include ENABLE_MULTIDEX.

The annoying thing about it though is that to access the var from base/, you'd
need to extract the app's package from a Context and use reflection to find the
BuildConfig class.

So... perhaps it isn't actually any better.

Other ideas:
1. Use a <meta-data> in the AndroidManifest.xml instead. Not sure if for some
reason this is slow to access at runtime.
2. Use a class that you know will never end up in the primary dex file, try to
access it, and if it fails you know you need multidex.

I don't think I like either idea better than just adding a class to every apk...
So, lgtm and I'll continue to think about this.

+
   java_target = "${_template_name}__java"
   java_library_impl(java_target) {
     forward_variables_from(invoker, [ "run_findbugs" ])