This doc outlines some tricks / gotchas / features of how we ship native code in Chrome on Android.
libchrome.sois stored uncompressed within the apk (with the name
crazy.libchrome.soto avoid extraction).
libmonochrome.sois stored uncompressed within the apk (an AndroidManifest.xml attribute disables extraction).
libchromium_android_linker.soand relies on the system's webview zygote for RELRO sharing.
libmonochrome.sois stored in the shared APK (TrichromeLibrary.apk) so that it can be shared with TrichromeWebView.
android_dlopen_ext()to enable RELRO sharing.
The packaging above extends to cover both 32-bit and 64-bit device configurations.
Chrome support 64-bit builds, but these do not ship to Stable. The system Webview APK that ships to those devices contains a 32-bit library, and for 64-bit devices, a 64-bit library as well (32-bit Webview client apps will use the 32-bit library, and vice-versa).
Monochrome's intent was to eliminate the duplication between the 32-bit Chrome and Webview libraries (most of the library is identical). In 32-bit Monochrome, a single combined library serves both Chrome and Webview needs. The 64-bit version adds an extra Webview-only library.
More recently, additional Monochrome permutations have arrived. First, Google Play will eventually require that apps offer a 64-bit version to compatible devices. In Monochrome, this implies swapping the architecture of the Chrome and Webview libraries (64-bit combined lib, and extra 32-bit Webview lib). Further down the road, silicon vendors may drop 32-bit support from their chips, after which a pure 64-bit version of Monochrome will apply. In each of these cases, the library name of the combined and Webview-only libraries must match (an Android platform requirement), so both libs are named libmonochrome.so (or libmonochrome_64.so in the 64-bit browser case).
Since 3 of these variations require a 64-bit build config, it makes sense to also support the 4th variant on 64-bit, thus allowing a single builder to build all variants (if desired). Further, a naming scheme must exist to disambiguate the various targets:
monochrome_(browser ABI)_(extra_webview ABI)
For example, the 64-bit browser version with extra 32-bit Webview is monochrome_64_32_apk. The combinations are as follows:
|32-bit||monochrome||The original 32-bit-only version|
|64-bit||monochrome||The original 64-bit version, with 32-bit combined lib and 64-bit Webview. This would be named monochrome_32_64_apk if not for legacy naming.|
|64-bit||monochrome_64_32||64-bit combined lib with 32-bit Webview library.|
|64-bit||monochrome_64||64-bit combined lib only, for eventual pure 64-bit hardware.|
|64-bit||monochrome_32||A mirror of the original 32-bit-only version on 64-bit, to allow building all products on one builder. The result won't be bit-identical to the original, since there are subtle compilation differences.|
Trichrome has the same 4 permutations as Monochrome, but adds another dimension. Trichrome returns to separate apps for Chrome and Webview, but places shared resources in a third shared-library APK. The table below shows which native libraries are packaged where. Note that dummy placeholder libraries are inserted where needed, since Android determines supported ABIs from the presence of native libraries, and the ABIs of a shared library APK must match its client app.
dlopen()s the main native library to load the remaining Crashpad handler code. A trampoline is used to de-duplicate shared code between Crashpad and the main native library packaged with it. This approach isn’t used for P- because the linker doesn't support loading executables on its command line until Q. This approach also requires building a suitable LD_LIBRARY_PATH to locate any shared libraries Chrome/WebView depends on.
What is it?
How we use it:
.sofiles with debug information removed via
What are they:
.eh_frame_hdr, but arm32 stores it in
readelf -S libchrome.so
How we use them:
minidump_stackwalk, which can create a stack trace given a snapshot of stack memory and the unstripped library (see //docs/testing/using_breakpad_with_content_shell.md)
JNI_OnLoad()is the only exported symbol (enforced by a linker script).
dlsym(), which doesn’t know about Crazy-Linker-opened libraries.
Java_*symbols are exported by linker script.
lib(mono)chrome.soenable “packed relocations”, or “APS2 relocations” in order to save binary size.
readelf -S libchrome.so
What is it?
GNU_RELRO. It contains data that the linker marks as read-only after it applies relocations.
readelf --segments libchrome.so
lib(mono)chrome.sothe region occupies about 2.4MiB on arm32 and 4.7 MiB on arm64
fork()ed from the app zygote (where the library is loaded) share RELRO (via
fork()'s copy-on-write semantics), but this region is not shared with other process types (privileged, utility, GPU)
How does it work?
GNU_RELROsegment copied into
GNU_RELROinto private memory and applies relocations as per normal.
libmonochrome.soat the same virtual address and apply RELRO sharing against the memory-mapped RELRO file.
WebViewLibraryPreloaderto call into the same WebView library loading code.
libmonochrome.sois loaded with the system‘s cached RELRO’s applied.
System.loadLibrary()is called afterwards.
fork()ing the WebView zygote rather than the normal application zygote.
ASharedMemory_create()to perform RELRO sharing, and then relies on a subsequent call to
System.loadLibrary()to enable JNI method resolution without loading the library a second time.
fork()s from a chrome-specific app zygote.
libmonochrome.sois loaded in the zygote before
memfd_create(2). This allows the region to survive forking from the app zygote, which will allow the zygote to share RELRO with all types of processes in the future.
Some Chrome code is placed in feature-specific libraries and delivered via Dynamic Feature Modules.
A linker-assisted partitioning system automates the placement of code into either the main Chrome library or feature-specific .so libraries. Feature code may continue to make use of core Chrome code (eg. base::) without modification, but Chrome must call feature code through a virtual interface.
How partitioning works
The lld linker is now capable of producing a partitioned library, which is effectively an intermediate single file containing multiple libraries. A separate tool (llvm-objcopy) then splits the file into standalone .so files, invoked through a partitioned shared library GN template.
The primary partition is Chrome's main library (eg. libchrome.so), and other partitions may contain feature code (eg. libvr.so). By specifying a list of C/C++ symbols to use as entrypoints, the linker can collect all code used only through these entrypoints, and place it in a particular partition.
To facilitate partitioning, all references from Chrome to the feature entrypoints must be indirect. That is, Chrome must obtain a symbol from the feature library through dlsym(), cast the pointer to its actual type, and call through the resulting pointer.
Feature code retains the ability to freely call back into Chrome‘s core code. When loading the library, the feature module system uses the feature name to look up a partition name (libfoo.so) in an address offset table built into the main library. The resulting offset is supplied to android_dlopen_ext(), which instructs Android to load the library in a particular reserved address region. This allows the feature library’s relative references back to the main library to work, as if the feature code had been linked into the main library originally. No dynamic symbol resolution is required here.
Implications on code placement
Builds that support partitioned libraries
Partitioned libraries are usable when all of the following are true:
fork()a process that reads a byte from each page of the library's memory (or just the ordered range of the library).
relocation_packerto pack relocations after linking, which complicated our build system and caused many problems for our tools because it caused logical addresses to differ from physical addresses.
lld, which supports packed relocations natively and doesn't have these problems.