GitLab

For Chromecast, Content Shell, and non-monochrome Clank/Webview:

The Crashpad handler is a standalone executable, packaged like a
loadable module and named libcrashpad_handler.so in order to not be
ignored by Android's APK installer.

For Monochrome:

The Crashpad handler is linked into libmonochrome.so. At crash-time
/system/bin/app_process{32,64} is exec-ed, running CrashpadMain.java
which loads libmonochrome.so and runs the native HandlerMain().

This strategy is not used for non-monochrome APKs (i.e. pre-N) because
on L, Android's loader is not yet capable of loading native libraries
from the APK. This is normally performed by the Chromium linker which
can't be used by CrashpadMain.java because /system/bin/app_process
doesn't initialize the process like a normal Android application
(specifically, no ContextImpl has been created, so any calls to e.g.
appContext.getApplicationInfo() will segfault).

Binary-Size: MonochromePublic.apk increases in size by 100 KB.
ChromeModernPublic.apk increases in size by 203KB (587 KB
increase in install size because libcrashpad_handler.so is extracted
from the APK). Possible mitigations for this increase are TODO:

For J, K: We could link the handler directly into libchrome.so and let
that be our handler executable. This would de-dup portions of libbase
that are currently linked into both libchrome.so and
libcrashpad_handler.so.

For L, M: It might be possible to get the chromium linker (or Bionic's
linker on M) to dlopen libchrome.so from the APK for a trampoline
libcrashpad_handler.so to de-dup libbase.

Bug: crashpad:30
Change-Id: If5b3752f26455e5c7aef3278b4bd2076ef1b7b65
Reviewed-on: https://chromium-review.googlesource.com/1150774Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594853}