Goals:
- Don't ship manual registration code in monochrome (~50kb is my guess)
- Reduce complexity of start-up code
Constraints:
- May not have native code depend on java code being built (or else slow down builds)
The current design:
- source_sets targets use GN's generate_jni() to generate .cc from .java
- Passes the c++ namespace to the GN template
- Passes explicit list of .java files to the GN template
- Template generates code that does 3 things:
1. Generates wrappers that allow C++ to call Java methods
2. Generates wrappers that allow Java to call native methods
3. Generates registration functions the links the Java to it's native wrapper
- Every component has a hand-coded method that calls of its registration functions
- Main module has hand-coded method that calls all needed registration methods
New shiney design:
- source_sets targets use GN's generate_jni() to generate .cc from an android_library
- Passes the c++ namespace to the GN template
- Passes android_library target rather than java files
- Template generates code that does 3 things:
1. Generates wrappers that allow C++ to call Java methods
2. Generates wrappers that allow Java to call native methods
- shared_library targets will use a new template if they require manual registration.
- These will use an target's .build_config to locate all .java files
- It will use generate_jni() under-the-hood to re-parse all java files
- It will create a single method: RegisterJniNatives(bool main_dex_only)
- Delete all manually written code related to RegisterNatives. \o/
Example:
android_library("base_java") {
...
}
generate_jni("base_jni_headers") {
target = ":base_java" # Depends only on the .build_config under-the-hood
jni_package = "base"
}
generate_jni_registration("chrome_jni_registration") {
target = ":chrome_apk" # Depends only on the .build_config under-the-hood
output = "$target_gen_dir/chrome_jni_registration.h"
}
shared_library("chrome") {
sources = [
"../browser/android/chrome_entry_point.cc",
"$target_gen_dir/chrome_jni_registration.h",
]
...
}
Note: This new design will cause many more .java files to be parsed by generate_jni.py, and it will caused them to be parsed twice. This excess parsing is in exchange for build parallelism, and I think won't be noticed by build times (parsing is super quick)
Comment 1 by agrieve@chromium.org
, Feb 6 2017