-
Notifications
You must be signed in to change notification settings - Fork 0
Overview of installation scenarios
Under all scenarios, patching of framework-res.apk still exists as a fallback.
However, this option is less user friendly and only viable if the system does not enforce the package signature of framework-res.apk or if it is signed with public keys that would allow anyone to re-sign a tampered system package.
The following is a summary of actions to be performed before a custom WebView package can be installed or updated normally by the user. Accordingly, this implies upgrading a system app or installing the WebView package as a user app entirely.
Always remove any conflicting preinstalled package when installing a custom WebView with a non-unique package name like com.android.webview.
| Situation | Action |
|---|---|
| RRO support | Pin package to appropriate signature |
| Package whitelisted / user build | Place WebView Stub |
| Package whitelisted / userdebug build | Remove preinstalled package |
| Package not whitelisted | Give up or patch framework-res.apk, expect bootloops |
"Package" refers to a custom WebView package and its current or potential package name interchangeably.
"Stub" refers to a minimal package that can be placed into the system partition to turn a custom WebView into a "preinstalled app" from androids point of view. It may also refer to a regular version of the custom WebView package as it delivers the same outcome in regards to preinstalling.
"Whitelist" assumes the untampered WebView provider whitelist built into the system unless in has been patched or overlayed.
Since some ROMs whitelist com.android.webview without pinning a signature, using this package name can allow custom WebView installation simply by replacing the appropriate package preinstalled in the system. This can be done by simple filesystem actions or a simple Magisk module.
However, if you are in a position where you can control the WebView provider whitelist, the most elegant solution is to whitelist a unique package name for the custom WebView and pin it to the signature of the official release APKs, as is commonly done with the Google System WebView or Chrome for example. This solution allows installing the custom WebView as a user application. Entities capable of controlling the whitelist:
- Device OEM / ROM Maintainer (whoever builds and ships android for your device)
- A user capable of recompiling and resigning
framework-res.apk - A user capable of "preinstalling" an Overlay package as seen from androids point of view, this usually implies placing it in the system partition either physically or using other means like Magisk.
The Problem with this elegant solution is that to support it, a custom WebView would have to change the package name for its releases, thereby losing any of the installation benefits to using com.android.webview, or the developers would have to find a way to publish their WebView provider application with two package names in parallel.
Either way it is likely not worth the trouble because anyone capable of manipulating the WebView provider whitelist is almost always also capable of removing a preinstalled com.android.webview package from the system to free up the package name, as it comes down to just deleting one apk file from the system partition. As a result, the only hard advantage of a unique package name is being able to install the custom WebView in parallel to a preinstalled com.android.webview package, allowing the user to decide at a later time. This should usually not be needed, since the decision to use the custom WebView is either commited to or may be undone by reverting the modifications to the device made during installation.
LineageOS ships userdebug builds for all devices. userdebug builds of AOSP do not enforce any pinned signature from the webview whitelist. This is a security issue because com.google.android.webview is commonly whitelisted but not preinstalled. A user trying to install the Google WebView could sideload a malicious WebView APK and the system would grant it all the privileges and access a regular WebView gets.
As a result, this has been patched in LineageOS 16.0 as of 2021-01-10 and LineageOS based custom ROMs should have merged this patch as well.
https://gitlab.com/LineageOS/issues/android/-/issues/2192
https://review.lineageos.org/c/LineageOS/android_frameworks_base/+/300878
I think that prior to Android 7.0, no WebView package must be a system app, i.e that installation as a user app was supported regardless of build type so long as the package name was whitelisted.
However, all i have to support this claim is that it applied to the Stock OxygenOS of my OnePlus X which was based on Android 5.1. Any links to relevant portions of the AOSP source code would be nice.