how to build custom webview and custom webview.apk without build AOSP framework and without reflash custom image

1,178 views
Skip to first unread message

Allen Gu

unread,
Sep 24, 2020, 9:55:25 PM9/24/20
to android-webview-dev
Hi googlers

I am a 3rd-app RD, and I‘m working on a project 
where I need to wrap  a custom view (just like android webview with a diffenent package, aka com.custom.myview)。

and I repo&clone a upstream chromium code, set system_webview_package_name with custom package (just like system_webview_package_name = "com.mycompany.webview")

then I choose a WebView variant and build my own webview.apk with package com.mycompany.webview
autoninja -C out/Default system_webview_apk
or 
autoninja -C out/Default monochrome_public_apk
autoninja -C out/Default trichrome_webview_apk

Because my company is not a device vendor or OEMs like HUAWEI or Samsung, my company just a traditional APP developer, 
So I can't custom and modify AOSP framework and config config_webview_packages.xml, set webview provider freely

Even more, I can't sign myown webview.apk with platform key, and can't  reflash custom system image。

In the situation above, How can I wrap my own com.custom.myview, and build and install mywebview.apk(com.mycompany.webview),  and make these work fine and smoothly in all android devicez with user image or user-debug, eng image.

BTW, I have the follow ideas according chromium architecture
1. I just wrap my customview(com.custom.myview) based content API and content shell
   ----but content shell is just a demo, have little fuction
2. I wrap my customview based chrome for android
   -----maybe wrap customview base chrome for andriod have heavy workload
3. I wrap my customview based AOSP webview and android_webview in chromium src
  ----can I just build android_webview as aar, or can I move webview code to android_webview, and then build mywebview.apk
4.  I just skip glue layer and use only the lower level interfaces like AwContents, and wrap myview, just like instrumentation shell does, AwTestContainerView
currently I'm working with fourth idea, based AwContents
webview_instrumentation_apk , this embeds a copy of the AwContents (webview's internal core) in the apk rather than using the system webview 


Maybe,  my question  mentioned  above  is a little confused, 
In other words,  Whether  it is reasonable towards the  fourth idea that based AwContents, or what about the remaing three ideas.

Any help and proposal would be appreciated!

Torne (Richard Coles)

unread,
Sep 25, 2020, 11:38:14 AM9/25/20
to Allen Gu, android-webview-dev
On Thu, 24 Sep 2020 at 21:55, Allen Gu <guhua...@gmail.com> wrote:
Hi googlers

I am a 3rd-app RD, and I‘m working on a project 
where I need to wrap  a custom view (just like android webview with a diffenent package, aka com.custom.myview)。

and I repo&clone a upstream chromium code, set system_webview_package_name with custom package (just like system_webview_package_name = "com.mycompany.webview")

then I choose a WebView variant and build my own webview.apk with package com.mycompany.webview
autoninja -C out/Default system_webview_apk
or 
autoninja -C out/Default monochrome_public_apk
autoninja -C out/Default trichrome_webview_apk

Because my company is not a device vendor or OEMs like HUAWEI or Samsung, my company just a traditional APP developer, 
So I can't custom and modify AOSP framework and config config_webview_packages.xml, set webview provider freely

Even more, I can't sign myown webview.apk with platform key, and can't  reflash custom system image。

In the situation above, How can I wrap my own com.custom.myview, and build and install mywebview.apk(com.mycompany.webview),  and make these work fine and smoothly in all android devicez with user image or user-debug, eng image.

We don't support or recommend doing this at all - one important reason is that you'd need to update this WebView build very frequently to stay current with security fixes, basically forever, which is a lot of work to sign up for. It's also quite difficult to use another APK as a library in this way (the system WebView can only do it through complex use of internal system APIs), so you would almost certainly need to embed the Chromium code into the app that's going to use it - if you have more than one app that wants to use this, that means building it into each app separately, which takes up lots more space and RAM.
In general this also just isn't very RAM-efficient even with only one app, since you can't share the costs of loading the WebView implementation with other apps on the device.
 
BTW, I have the follow ideas according chromium architecture
1. I just wrap my customview(com.custom.myview) based content API and content shell
   ----but content shell is just a demo, have little fuction
2. I wrap my customview based chrome for android
   -----maybe wrap customview base chrome for andriod have heavy workload

Basing your app on content_shell or the Chromium browser itself are both pretty viable and reasonable options if you're willing to pay the cost of updating it frequently forever, and don't involve the WebView code. This is how other Chromium-based browsers on Android work (like Opera, Edge, etc). There's nothing special you need to do to do this.
 
3. I wrap my customview based AOSP webview and android_webview in chromium src
  ----can I just build android_webview as aar, or can I move webview code to android_webview, and then build mywebview.apk

There isn't any practical way to use the system WebView APIs and the //android_webview/glue code in your own app - these aren't something you can usefully call directly, they are only used by the framework WebView API implementations. There is no way to make the framework APIs use your own WebView instead of the one configured by the device manufacturer. There is also no way to build WebView as an AAR - we build in a very complex way that has nontrivial dependencies on exactly how it's packaged into a final APK, so it can't be made into a standard library at all.
 
4.  I just skip glue layer and use only the lower level interfaces like AwContents, and wrap myview, just like instrumentation shell does, AwTestContainerView
currently I'm working with fourth idea, based AwContents
webview_instrumentation_apk , this embeds a copy of the AwContents (webview's internal core) in the apk rather than using the system webview 

Some apps/companies do this, yes, and hook it up similarly to how the instrumentation test shell works. We don't support this and these APIs are not stable - future changes to Chromium might break your code. But ultimately it's up to you if you want to do the work and pay the future maintenance costs. Many of the apps which currently do this are using extremely outdated versions of the Chromium code with many known serious security vulnerabilities, though, which isn't very responsible to their users :(
 

Maybe,  my question  mentioned  above  is a little confused, 
In other words,  Whether  it is reasonable towards the  fourth idea that based AwContents, or what about the remaing three ideas.

Any help and proposal would be appreciated!

--
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/06742626-f3a8-4064-8973-967b62fa4b5an%40chromium.org.

Allen Gu

unread,
Sep 26, 2020, 5:23:11 AM9/26/20
to android-webview-dev, to...@chromium.org, android-webview-dev, Allen Gu

Toby , Thanks a lot for your detailed explanation and  proposal。

BTW, There is just only one app that will use my-customview。

As we know,  Weblayer is built on top of src/content which is a sibli ng or chrome and webview.
it is powerful enough to build a model browser, include all the same web platform features as chrome, as fast and secure as chrome。

3rd Apps can embed WebLayer such as they embed WebView。

WebLayer is currently an experimental API we develop for internal projects ,we make no guarantees of the stability at this time。

What's the current situationthe and milestone of weblayer,how long does it take to stabilize ?
Maybe I can just choose weblayer, emded weblayer into my app, when weblayer is stabilize 。

Torne (Richard Coles)

unread,
Sep 28, 2020, 11:08:16 AM9/28/20
to Allen Gu, android-webview-dev
On Sat, 26 Sep 2020 at 05:23, Allen Gu <guhua...@gmail.com> wrote:

Toby , Thanks a lot for your detailed explanation and  proposal。

BTW, There is just only one app that will use my-customview。

As we know,  Weblayer is built on top of src/content which is a sibli ng or chrome and webview.
it is powerful enough to build a model browser, include all the same web platform features as chrome, as fast and secure as chrome。

3rd Apps can embed WebLayer such as they embed WebView。

WebLayer is currently an experimental API we develop for internal projects ,we make no guarantees of the stability at this time。

What's the current situationthe and milestone of weblayer,how long does it take to stabilize ?
Maybe I can just choose weblayer, emded weblayer into my app, when weblayer is stabilize 。

WebLayer is not designed to be embedded into the application binary; it's loaded from a common implementation on the device similarly to WebView (and currently in the experimental version this is via the WebView implementation package). So even if this was ready for apps to use it would just get you the same version of Chromium that you get from WebView (just configured somewhat differently to provide a more browser-like experience) - this isn't really a way to accomplish what you want either.

Allen Gu

unread,
Sep 28, 2020, 7:45:40 PM9/28/20
to android-webview-dev, to...@chromium.org, android-webview-dev, Allen Gu
Ok, I understand, Thanks again!

Torne (Richard Coles)

unread,
Oct 29, 2024, 12:14:20 PM10/29/24
to Rahul Shyokand, android-webview-dev, guhua...@gmail.com


On Tue, 29 Oct 2024 at 10:46, Rahul Shyokand <rshy...@gmail.com> wrote:
Hi Everyone,
I was hunting for a similar output, where the WebView standard version will be part of app.
Not sure if there are any recent work arounds on this which are officially supported.

No, nothing has changed here. We do not have any official support for embedding a WebView-derived engine into an app, and we do not currently have any plans to support this.
 
I tried the same like building possible variants of WebView from Chromium Code using provided documents.


autoninja -C out/Default monochrome_public_apk
autoninja -C out/Default trichrome_webview_apk
autoninja -C out/Default system_webview_apk 

Still once the build is developed, there is no other way to integrate with existing apk.
We can handle more app load time and also fine if there are any app size changes. The use-case of the application is critical enough to require independent in-app integrated sdk but requires more modular approach like an aar or jar file of the browsers.
If the WebView can be integrated with less frequent updates as the security is not very critical issue.

Looking to know your understanding and guidance on how it can be done.

Thanks

Rahul Shyokand

unread,
Oct 29, 2024, 1:14:53 PM10/29/24
to android-webview-dev, guhua...@gmail.com, to...@chromium.org, android-webview-dev
Hi Everyone,
I was hunting for a similar output, where the WebView standard version will be part of app.
Not sure if there are any recent work arounds on this which are officially supported.

I tried the same like building possible variants of WebView from Chromium Code using provided documents.

autoninja -C out/Default monochrome_public_apk
autoninja -C out/Default trichrome_webview_apk
autoninja -C out/Default system_webview_apk 

Still once the build is developed, there is no other way to integrate with existing apk.
We can handle more app load time and also fine if there are any app size changes. The use-case of the application is critical enough to require independent in-app integrated sdk but requires more modular approach like an aar or jar file of the browsers.
If the WebView can be integrated with less frequent updates as the security is not very critical issue.

Looking to know your understanding and guidance on how it can be done.

Thanks

On Tuesday, September 29, 2020 at 5:15:40 AM UTC+5:30 guhua...@gmail.com wrote:
Reply all
Reply to author
Forward
0 new messages