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

base/android/java/src/org/chromium/base/PackageBuildConfig.java

Index: base/android/java/src/org/chromium/base/PackageBuildConfig.java
diff --git a/base/android/java/src/org/chromium/base/PackageBuildConfig.java b/base/android/java/src/org/chromium/base/PackageBuildConfig.java
new file mode 100644
index 0000000000000000000000000000000000000000..ee9cc9fea8a7845716072903a81fef215d6a421d
--- /dev/null
+++ b/base/android/java/src/org/chromium/base/PackageBuildConfig.java
@@ -0,0 +1,35 @@
+// Copyright 2017 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.
+
+package org.chromium.base;
+
+import android.content.Context;
+
+import java.lang.reflect.Field;
+
+/**
+ *  Access point for per-package build configuration.
+ */
+public class PackageBuildConfig {
+    private static final String TAG = "cr_base";
+
+    /**
+     *  Whether multidex is enabled for the package corresponding to {@code context}.
+     *
+     *  @param The context for which the multidex state should be returned.
+     */
+    public static boolean isMultidexEnabled(Context context) {
+        String packageName = context.getPackageName();
+        try {
+            ClassLoader loader = context.getClassLoader();
+            Class<?> packageConfig =
+                    loader.loadClass(String.format("%s.PackageConfig", packageName));

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

Would this technique work with using the existing BuildConfig class? Wondering
if the explicit getClassLoader() is enough without needing to also create
classes with different names.

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

It could. My intention was to keep the two separate for conceptual reasons --
BuildConfig handles build-scope constants, while PackageBuildConfig handles
package-scope constants. Perhaps that's unnecessary, though.

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

I think I'd prefer having just one BuildConfig then. It's already per-package
since it has COMPRESSED_LOCALES as well.

[jbudorick, 2017/04/21 19:03:04]

I was wrong -- if we want to keep the Log message at all, this needs to stay out
of template form. Thoughts?

+            Field isMultidexEnabledField = packageConfig.getField("IS_MULTIDEX_ENABLED");
+            return isMultidexEnabledField.getBoolean(null);
+        } catch (Exception e) {
+            Log.e(TAG, "Unable to determine whether multidex is enabled for %s", packageName, e);

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

Should this be a fatal error (e.g. don't bother catching it, or rethrow as
RuntimeException). Does it ever happen in practice?

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

It shouldn't happen except when making changes for multidex, so I hit it a lot
:)

As to whether or not it should be fatal -- given the current implementation of
PackageConfig, probably, though not being able to find PackageConfig is fine for
single-dex APKs. Unsurprisingly, for multidex APKs, hitting this is very bad and
is absolutely fatal slightly later in the startup process.

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

Given your explanation, maybe better to make it a Log.d() so that it's stripped
in release binaries?

[jbudorick, 2017/04/21 19:03:04]

Done.

+        }
+        return false;
+    }
+}