Any ideas on building webview as AAR library instead of APK?

[Beomsik Min]

Hello,

I'm trying to embed Android Webview in my Android App.

So far I've looked "webview_instrumentation_apk" BUILD.gn target that meets the goal, but not sure how to modify the target to build AAR.

Is there any ideas, tips, or documentation on building WebviewInstrumentation as AAR or embedding in an Android App using Android Studio?

Thanks. 

[Torne (Richard Coles)]

We don't support embedding the WebView implementation in your app and there's no build support in the Chromium tree for making it into a library.

We recommend against doing this in general; amongst other things you will need to update this very frequently (every 2-3 weeks) for the lifetime of your app to keep up to date with security issues, which will make your app require frequent large updates.

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/f9d0e0ed-37d7-48b3-a896-424a272fe121n%40chromium.org.

[Bo Liu]

Also the rendering stack in WebViewInstrumentation.apk isn't production quality and has large gaping holes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/CAEV-rjfkAxJZQG%3D%2BjOgE_QgQEppwSyGMLd%2BfiLML2PdfZLj0OQ%40mail.gmail.com.

[John Dagdelen]

I want to bring this back up because while your concerns are valid, there are systems where the system webview is not kept up to date (many standalone VR headsets, for example.) As the Google play store is not available on those devices, it would be advantageous to be able to package a newer, more secure webview with an app. 

[Torne (Richard Coles)]

On Thu, 28 Sept 2023 at 15:34, John Dagdelen <jjdag...@gmail.com> wrote:

I want to bring this back up because while your concerns are valid, there are systems where the system webview is not kept up to date (many standalone VR headsets, for example.) As the Google play store is not available on those devices, it would be advantageous to be able to package a newer, more secure webview with an app. 

I understand that this would be helpful in cases like that, but we don't intend to support this in the foreseeable future.

Any version of WebView built as an app-embeddable library rather than as a system component, even if it was officially released by the WebView team, would not actually be a drop-in replacement for the system WebView. The "real" WebView implementation (system_webview_apk and related targets) can't be used directly by an app no matter how it's packaged - it only works in conjunction with the WebView APIs and integration code that are part of the Android framework, which aren't designed in a way that allows for the use of an app-specific implementation.

A number of apps and library projects have built a library version of WebView in the past, and some still do, but these are all based on the WebView instrumentation test shell as mentioned in the thread. The instrumentation test shell uses a completely different mechanism for actually rendering the pixels on the screen, and as Bo said previously, this is not production quality and does not support all the same functionality as the normal WebView rendering mechanism.

The API available in the instrumentation test shell is also very different to the system WebView API, and would require extensive changes to the code of your app to use it instead of WebView - this is an internal API within the Chromium codebase and as such it's lower-level and more complex, is not guaranteed to be stable between Chromium versions, is not thoroughly documented, and expects the caller to carefully uphold many of its threading/correctness requirements. Exposing an API that is more similar to the system WebView would be a significant amount of work and involve quite a lot of ongoing effort to maintain two different stable APIs in parallel - investing this effort would come at the expense of spending those resources on the WebView that is used by virtually all apps/devices.

We have done our best to ensure that AOSP device vendors can build and update their own version of WebView as easily and safely as is practical, using exactly the same mechanisms that the Play Store uses to update it on devices with the Google Play Services preinstalled. Unfortunately, not all device vendors take advantage of this (and in fairness to them, "as easily as is practical" is not always easy enough), leaving app developers in an awkward position when supporting those devices, as you say.