[Android] Rework multidex and enable multidex for unit_tests_apk.

build/config/android/rules.gni

 # Copyright 2014 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 import("//base/android/linker/config.gni")
 import("//build/config/android/config.gni")
 import("//build/config/android/internal_rules.gni")
 import("//build/config/sanitizers/sanitizers.gni")
 import("//build/toolchain/toolchain.gni")
 import("//third_party/android_platform/config.gni")
@@ skipping 1465 matching lines @@
       if (_load_library_from_apk) {
         defines += [ "ENABLE_CHROMIUM_LINKER_LIBRARY_IN_ZIP_FILE" ]
       }
       if (_enable_chromium_linker_tests) {
         defines += [ "ENABLE_CHROMIUM_LINKER_TESTS" ]
       }
     }
     _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" ])
     supports_android = true
     requires_android = true
     override_build_config = _build_config
     deps = _android_manifest_deps + [ ":$build_config_target" ]
 
     android_manifest = _android_manifest
     chromium_code = true
@@ skipping 758 matching lines @@
   }
 
   android_library(target_name) {
     java_files = []
     srcjar_deps = [ ":${_template_name}__protoc_java" ]
     deps = [
       "//third_party/android_protobuf:protobuf_nano_javalib",
     ]
   }
 }