Some of the java-related hacks we use for apk targets are problematic for tests, app bundles, and trichrome:

* BuildHooks
Used by the bytecode rewriter to handle java assertions. A dep is added to every java library that supports Android unless no_build_hooks is specified. 

* BuildHooksAndroid
Used by the bytecode rewriter to access compressed resources. A dummy version is used at java_library compile time but excluded from the library jar, and the real version is added at the apk level (uses the default if no dep is passed to the apk target). Again, a dep is added to every java library that supports Android unless no_build_hooks is specified.

* BuildConfig
Generated file that contains some global constants and some target specific constants (ex. the list of locales that we have pakfiles for). base_java depends on a dummy version of this target and the real version is added at the apk level. 


* NativeLibraries
Generated file that contains some global GN constants and the native library name(s) and version numbers. base_java depends on a dummy version of this target and the real version is added at the apk level. 


The biggest problem with these features is that they don't play nice with multi-apk structures since duplicate classes aren't permitted in java and they're (almost) unconditionally added to each apk target. 

A simple fix for right now is just to hide these features behind some GN variable that isn't set for app bundle feature modules, targets with apk_under_test, and for trichrome's library target (can either add a new target type or reuse app bundle templates). 

Caveats: the dependent apks won't compile without base apk and aren't guaranteed to be functional on their own.

Related issue 689038: We should change LibraryLoader.java to not know about the list of native libraries and have this information passed in from callers that initiate library loading so that base_java doesn't need to depend on NativeLibraries.java.