Static Library Java code


This document describes how static library targets can be used to share common Java code between multiple APKs. More detail can be found at go/proguarding-trichrome.


Currently (Jan 2020) trichrome library is the only target to make use of static shared library APKs and is used to share common code used by both Chrome and Webview.


Java code sharing is mostly implemented at this point but there is one remaining blocker related to how native method resolution works in Webview.

How it works

Build variables

For android_apk_or_module base templates:

static_library_provider: Specifies that this target depends on a static shared library APK. When synchronized proguard is turned on, the static_library_provider becomes the target that provides the final dex file.

static_library_dependent_targets: If set, generates final dex files for itself and for all targets in the static_library_dependent_targets list.

static_library_synchronized_proguard: Turns on synchronized proguard for targets that also set static_library_provider.

.build_config is responsible for figuring out where code and related artifacts for the static_library_provider and static_library_dependent_targets belongs. The main difference from regular .build_configs is the mapping recording which input jars belong to each final dex file. Ex:

"deps_info": {
  "static_library_dependent_classpath_configs": {
      "gen/android_webview/trichrome_webview_apk.build_config": [
      "gen/chrome/android/trichrome_chrome_bundle.build_config": [
      "gen/chrome/android/trichrome_library_apk.build_config": [

Synchronized ProGuard

TrichromeChromeBundle (base module) and TrichromeWebview do not have a final dex or proguard step. Instead the library APK creates a “fat” dex from the .build_config:deps_info:java_runtime_classpath.

Then, the mapping of .build_config -> owned input jars stored in the .build_config is used by dexsplitter to generate final .dex files for TrichromeLibrary, TrichromeChrome, and TrichromeWebview.


For Java code to be shared between Chrome and Webview in Trichrome, we ensure that Chrome and Webview use the same resource IDs. This requires a few adjustments to how resources are created.

  1. Webview's resources are compiled first without any changes.
  2. Chrome's resources are compiled second, but use the same resource IDs as Webview when possible.
  3. When synchronized proguarding is turned on, the files generated in the previous step are discarded. The shared static library APK target (trichrome library) takes the output R.txt files from the previous steps and includes those resources in its own generation.


  • Building trichrome_chrome_bundle or trichrome_webview_apk (and various arch variants) will ensure the correct library target is also built.
  • Using the generated wrapper script from the main APK is sufficient (no need to explicitly install the library).
    • bin/trichrome_chrome_bundle run will ensure TrichromeChromeBundle and TrichromeLibrary are installed before launching Chrome.