Document app zygote on Q
Change-Id: I06a5a445f5a3a1463b5275c03499c05f46d5bc89
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1593392
Reviewed-by: Andrew Grieve <[email protected]>
Commit-Queue: Bo <[email protected]>
Cr-Commit-Position: refs/heads/master@{#656014}
diff --git a/docs/android_native_libraries.md b/docs/android_native_libraries.md
index 9c13e39..6fe246c9 100644
--- a/docs/android_native_libraries.md
+++ b/docs/android_native_libraries.md
@@ -121,8 +121,10 @@
* For renderer processes, the OS starts all Monochrome renderer processes by `fork()`ing the WebView zygote rather than the normal application zygote.
* In this case, RELRO sharing would be redundant since the entire process' memory is shared with the zygote with copy-on-write semantics.
* For Android Q+ (Trichrome):
- * TrichromeChrome no longer shares its RELRO data with WebView and no RELRO sharing occurs. TrichromeWebView works the same way as on Android N-P.
- * TrichromeChrome's renderer processes are no longer `fork()`ed from the WebView zygote. TrichromeWebView works the same way as on Android N-P.
+ * For non-renderer processes, TrichromeChrome no longer shares its RELRO data with WebView and no RELRO sharing occurs. TrichromeWebView works the same way as on Android N-P.
+ * For renderer processes, TrichromeChrome `fork()`s from a chrome-specific app zygote. `libmonochrome.so` is loaded in the zygote before `fork()`.
+ * Similar to O-P, app zygote provides copy-on-write memory semantics so RELRO sharing is redundant.
+ * For renderer processes, TrichromeWebView works the same way as on Android N-P.
## Library Prefetching
* During start-up, we `fork()` a process that reads a byte from each page of the library's memory (or just the ordered range of the library).
