Android WebView is a content embedder, meaning it depends on code in //content/ and lower layers (ex. //net/, //base/), but does not depend on sibling layers such as //chrome/ or //weblayer/. Android WebView can also depend on components.
Android WebView exposes Java APIs in the framework and AndroidX, which are responsible for loading chromium code from the WebView provider package. These APIs call into glue code (//android_webview/glue/ and //android_webview/support_library/ respectively).
The glue layers convert to chromium-defined types in the “AW” layer. The AW Java types typically call into browser C++ code via Java Native Interface (JNI) or call into Java methods in other layers which eventually use JNI (ex. //content/public/). These AW types are the layer we write automated instrumentation tests against.
In addition to browser C++ code, WebView also has a small amount of code in //android_webview/renderer/ (renderer process code) and //android_webview/common/ (shared between multiple processes), which are patterned off //content/browser/, //content/renderer/, and //content/common/. The bulk of WebView's code is defined in //content/ layer and below.
When an Android app embeds WebView, WebView‘s browser code runs in the app’s process (we call this the “browser process”). This means WebView code shares the same address space, and we generally consider the app to be trusted just like any other browser process code. WebView‘s browser process code runs in the same context as the embedding application, which means it has all the same permissions and limitations of the embedding app (ex. WebView only has network access if the app requeested it). One consequence of this is WebView uses the app’s data directory, so each app has a separate cookie jar, network cache, etc.
WebView follows Chrome‘s architecture by separating browser and renderer code. Due to platform limitations, WebView runs renderer content “in process” (in the browser process) on Android L, M, and N devices and “out of process” (in a separate renderer process) on Android O and above. See this document for details. WebView’s renderer process also runs in the app's context, although this process is sandboxed so it actually has even fewer permissions.
WebView runs other services (ex. GPU service, Network Service) in-process on all OS versions. This saves memory (which is why Chrome for Android does the same thing on low-memory devices), although WebView is technically blocked because there's no Android API to run a non-sandboxed process under another app's context.
Although WebView is typically embedded in other apps, it runs some code as its own context. This includes a limited amount of UI code as well as a service. See //android_webview/nonembedded/ for details.
Since Android Lollipop, WebView has been implemented by an updatable package. We ship WebView to users in one of 3 packaging variants: standalone WebView, Monochrome, and Trichrome. See Packaging Variants for details.
