Agreed that we should remove the implicit dependency on base_java.

There are some global constants that could be moved out of NativeLibraries.java (ANDROID_APP_CPU_FAMILY_MIPS, .. ). 

Some of the other fields exist outside of NativeLibraries.java or could be calculated (NATIVE_LIBRARIES_VERSION_NUMBER, ENABLE_CHROMIUM_LINKER).

Slightly better might be:
  * Make NativeLibraries.java an interface in its own java_library() and have a stub implementation in the library that's excluded from the jar via. jar_excluded_patterns (see AppHoolsImpl)
  * Have base_java depend on the interface and make LibraryLoader take an object of type NativeLibraries 
  * Have the clients of LibraryLoader pass in the singleton instance of NativeLibraries when using LibraryLoader
  * Have the real implementation injected at build time at the apk level if native libraries are actually used by the apk

Still pretty hacky but better than what we have today and can likely be made cleaner if/when we start using dagger for DI.

Plan mostly sgtm. Couple more ideas:

1) I don't know if using an interface buys us anything if we're also going to do the jar_excluded_patterns trick for the impl. E.g. just use the impl directly.
2) Would be nice to have the "real implementation injected at build time", but only if //base is depended on. What I'm thinking for this is:
  * Have java_library targets be able to specify a script to run that will generate a srcjar. (for base, it would generate NativeLibraries.java and BuildConfig.java)
    * Record the script path in the .build_config
    * Also record the args, but allow a %s placeholder for the apk build_config.
       * e.g. ["--classpath", "@FileArg(%s:javac:classpath)"]
  * When creating the java_library within android_apk, have an action that generates a .srcjar by running all scripts accumulated by deps, and merging them into a final srcjar.

Looking a bit closer I don't actually see where NativeLibraries.java depends on base_java? There's a bit of a layering issue here but I can't think of any suitable workarounds. 

#2 is a good idea but given that it'll only stop NativeLibraries.java from being added to all apks with shared libraries I'm inclined to leave this as-is for now until we can come up with a proper fix.