[TOC]
As WebView is an Android system component (rather than just an app), WebView
imposes additional requirements on the developer workflow. In particular,
WebView requires a physical device or emulator with a userdebug
or eng
Android image. WebView doesn’t support development on user
builds.
To build WebView, or run WebView’s automated tests, you’ll need to set up either an emulator or a physical device.
You can check which Android image you have on your device with the following:
# If you don't have `adb` in your path, you can source this file to use
# the copy from chromium's Android SDK.
$ source build/android/envsetup.sh
# If this outputs "userdebug" or "eng" then you're OK! If this outputs "user"
# then you must reflash your physical device or configure a new emulator
# following this guide.
$ adb shell getprop ro.build.type
userdebug
*** promo
Unless you have a hardware-specific bug, or need to use a pre-release Android
version, a physical device is usually unnecessary. An x86
emulator should be
easier to setup.
You can generally follow chromium’s Android
emulator instructions. You should choose a Google
APIs image. The AOSP-based image will also work, but imposes additional
developer hurdles. Note that you shouldn’t use a Google Play image for
development purposes because they are user
builds, see Why won’t a user
image work below.
Googlers can consult internal instructions here.
External contributors can flash a prebuilt userdebug
image (based off
aosp-master) onto a Pixel device with Android Flash
Tool. This requires a
browser capable of WebUSB (we recommend the latest Google Chrome stable
release).
*** note This takes significantly longer than the two previous methods, so please strongly consider one of the above first.
Prerequisite: a machine capable of building Android.
Clone an AOSP checkout, picking a branch supported for your device (you’ll need a branch above 5.0.0) from the list of branches:
mkdir aosp/ && cd aosp/ && \
repo init -u https://android.googlesource.com/platform/manifest -b android-9.0.0_r33 && \
repo sync -c -j<number>
You can obtain binary drivers for Nexus/Pixel devices here. Drivers should match your device and branch. Extract and run the shell script:
# Change the filenames to match your device/branch (this uses "crosshatch" as an
# example)
tar -xvzf /path/to/qcom-crosshatch-pd1a.180720.030-bf86f269.tgz
./extract-qcom-crosshatch.sh # Extracts to the vendor/ folder
You can build AOSP and flash your device with:
source build/envsetup.sh
device="crosshatch" # Change this depending on your device hardware
lunch aosp_${device}-userdebug
make -j<number>
# Flash to device
adb reboot bootloader
fastboot -w flashall
For more information, please defer to official instructions.
user
images have all of Android’s security features turned on (and they can’t
be disabled). In particular, you won’t be able to install a locally built
WebView:
user
images are release-keys
signed, which means local WebView builds
can’t install over the preinstalled standalone WebView. This blocks
development on L-M, since this is the only WebView provider.monochrome_{public_}apk
, this is not a valid WebView provider. Unlike on
userdebug
/eng
images, the WebView update service performs additional
signature checks on user
images, only loading code that has been signed by
one of the expected signatures—as above, these keys are not available
for local builds.Both of the above are important security features: these protect users from running malware in the context of WebView (which runs inside the context of apps).