crash: don't handle browser SIGQUIT on Android.

On Android, SIGQUIT is masked by default and handled specially by ART to
generate stack traces on demand (usually during an ANR or bugreport) in
a way that does not intrinsically terminate the process (though the
process may be killed afterward in some cases).

Apps that use WebView sometimes unmask SIGQUIT in the browser process
due to having their own crash handler or similar, and if that happens,
we don't want to treat this as a browser process crash and generate a
minidump, as there's no real way to know why the signal was sent.

Just disable handling SIGQUIT on Android in the browser process. This
leaves child processes alone; they only run our code so can't end up
with SIGQUIT accidentally unmasked.

Fixed: 1077890
Change-Id: Iff896135f0ff417f92dbf660d58569774eb4a0ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2426471Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Commit-Queue: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#809915}

components/crash/core/app/crashpad_android.cc

@@ -521,6 +521,11 @@ class HandlerStarter {
       process_annotations["ptype"] = browser_ptype;
     }
 
+    // Don't handle SIGQUIT in the browser process on Android; the system masks
+    // this and uses it for generating ART stack traces, and if it gets unmasked
+    // (e.g. by a WebView app) we don't want to treat this as a crash.
+    GetCrashpadClient().SetUnhandledSignals({SIGQUIT});
+
     if (!base::PathExists(handler_path)) {
       use_java_handler_ =
           !GetHandlerTrampoline(&handler_trampoline_, &handler_library_);