WebView stub apk to simplify installation

[SebiderSushi]

Is your feature request related to privacy?

No, but hear me out guys (i swear)

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

A small (<~2MB) stub apk file signed by csagan5 and officially released. This file could be installed to the system or a magisk module folder to obtain the proper privileges and be registered in the system. As soon as the first upgrade is installed, it will bring the full WebView functionality.
This would be useful on devices with limited storage capabilities, especially under /system. For example the Nexus 4 with only 8GB of total internal storage in some devices and no sd card slot.
It should only be necessary to test, build, sign and publish such a stub apk once so the effort might just be worth it.
This would open up the possibility of compiling and publishing a single and concise Recovery flashing zip or Magisk Module (small and which does not access the internet). This could be used for a user-friendly installation, followed by a simple apk installation as done with every upgrade that will follow anyway.

Describe alternatives you have considered

Using a full SystemWebView apk and placing it in the system or magisk module folder.
This uses a mentionable amount of space which serves no more use as soon as an upgrade gets installed.
Installers like a Recovery flashing zip or a magsik module installer would need to either carry a full blown webview apk file for whatever target architecture applicable or access the internet to download them. On arm64 devices where an extracted webview library file needs to be present, such installers might not even install a working webview to begin with. In these cases the webview also just gets usable after the first upgrade or reinstall into the userdata partition.

[csagan5]

I understand what you mean, but I would not be able to develop this. You could start by developing something like this and see how it is to maintain it.

Anything related to the SystemWebView requires constant user support.

[SebiderSushi]

I could prepare and test a proof of concept. But in the end, it would have to be signed officially to allow installing official builds of Bromite SystemWebView as updates to it.

Also, an overview of the capabilities nesessary for the WebView apart from the permissions declared in its manifest and it being registered as a system web view might be good, so the stub apk would not accidentaly fail to reqest everything from the system.

Another idea i had was to fill any webview object another app might create using the stub apk would be filled with useful info. I.E. if only just the stub apk is installed, opening up my webview based browser would fill it with some notice that Bromite WebView is not yet completely installed and simply needs to be upgraded to function. As i'm, totally unfamiliar with the internals of an android webview i've got no clue how to achieve this.

As for the maintenance i think it might even be unnecessary to publish the apk for this more than once. As long as package name and signature don't change the stub apk shouldn't need to be altered. (and as long as there are no changes in any permissions or privileges that can only be declared in the original apk file - but i doubt these even exist in android)

[SebiderSushi]

Okay i just managed to get a super basic proof-of-concept work by just doing the following:

• Create a new Android Studio project without an activity from the template
• Remove generated app icons, themes and the dependencies from the gradle script
• Build & Sign that thing
• Download an official build of the Bromite System WebView and resign that with the same key
• Place the stub apk in /system/app/webview/ on an android Pie device and reboot
  At this point, no webview provider was listed in the development settings, but installing the resigned bromite webview build succeded and after that Bromite System WebView appered in the WebView list in the development settings and using webviews was possible.

Now it should be made sure that nothing is overlooked here and that the concept is applicable on android 10 onwards as well (The overlay story). But apart from making it work once i really don't see any expected maintaining burden here.

Copy of the source code i used for my test apk stub:
https://github.com/SebiderSushi/WebViewStub-ProofOfConcept
( But the only things i identified as critical so far are the package name and the signature. )

[SebiderSushi]

Okay i just tested this on a device running Lineage 17.1 and it worked as well.
What i did was alter the Magisk Installer by @linuxandria so that it would place my stub apk instead of downloading the official one.
The installer takes care of the overlay problem with android 10+.

All-in-all it went just as fine as with the Pie device - the stub did not turn up in the WevView provider list, but as soon as a re-signed complete WebView apk was installed, it appeared in the list and could be used by applications.

[csagan5]

Now it should be made sure that nothing is overlooked here and that the concept is applicable on android 10 onwards as well (The overlay story).

It could be tested on multiple Android versions using Android Virtual Devices.

But the only things i identified as critical so far are the package name and the signature.

Indeed, that's what allows to install another package with same name and signature. The version code of the stub should also be smaller.

@SebiderSushi regarding the package name: we could also use a Bromite-specific package name, however I am not sure about the breakage that would be involved. If we exclude users with an unlocked bootloader which can use pretty much any package name, what are the remaining use cases where keeping com.android.webview (as it is currently) is beneficial? Do you know what other webview developers do about it?

See also: https://github.com/bromite/bromite/wiki/Installing-SystemWebView#about-the-package-name

[SebiderSushi]

Sorry for letting this issue slide for so long.
I have recently noticed that i don't own any setup (device, stock rom, custom rom) where there are any complications installing the Bromite WebView. That is, is noticed that i was able to install and use Bromite WebView as a user app on all of my setups by simply removing the preinstalled com.android.webview apk file from the system image.
("all setups" implies everything that whitelists com.android.weview as a webview provider to begin with)

I was able to reproduce this in an AVD running Android Pie as well.

So basically i've realized that i actually don't own a use case for this, nor can i provide any testing resources that resemble any critical situation where installation to the system partition would be mandatory.

[SebiderSushi]

Otherwise, to get back to your question:
Due to the fact that System WebView providers must explicitly be whitelisted in the system Framework, choosing a bromite specific package name would be useful for anyone who is able to patch their system framework to whitelist that name. Other than that it would mostly just support use cases where keeping the system version of com.android.webview installed is desired.

The thing with the package name com.android.webview is that there are many ROMs in existence that list this package name as a webview provider WITHOUT also requiring it to be signed by a special key as done with Google Chrome or similar things. That is why using this package name is the easiest thing for people with unlocked bootloaders as well.
But as it stands by now (with AVB and stuff) it is mostly impossible to use a custom WebView implementation at all without an unlocked bootloader and things like Magisk or System partition access, since there is usually already a package preinstalled in the system for any whitelisted System WebView provider.

IIRC i might have seen com.google.android.webview whitelisted without signature pinning in one particular stock rom, but i can't quite imagine how google might react to using their package name.

Giving bromite a unique package name would be the technically correct thing to do, but unfortunately only works if users can patch their framework-res.apk or if the WebView is bundled in by the ROM maintainer or developer.

[csagan5]

IIRC i might have seen com.google.android.webview whitelisted without signature pinning in one particular stock rom, but i can't quite imagine how google might react to using their package name.

There is no advantage to swap com.android.webview with com.google.android.webview, but anywhere you see them without signature pinning it's a serious security bug.
They would not care about this because authenticity is guaranteed by the signature, not the package name (see the quote in https://github.com/bromite/bromite/wiki/Installing-SystemWebView#installation-without-root), but as I said there is no incentive to use a different package name given that it would only work on "backdoored" installations. And if you add a backdoor manually, you might as well just add a Bromite-specific package name with the correct signature.

Giving Bromite a unique package name would be the technically correct thing to do, but unfortunately only works if users can patch their framework-res.apk or if the WebView is bundled in by the ROM maintainer or developer.

If root were necessary for any SystemWebView installation procedure, then we could just go with a Bromite-specific package name. The wiki page mentions the debloater approach but I do not have proof that it works. It would contradict the security model guarantees. Perhaps you could do some research there?

[SebiderSushi]

These approaches can only work if the Android SystemWebView is not present, since Bromite SystemWebView uses the same package name and APK signature verification would fail otherwise.

As far as i understand it, the wiki page is aware of the security model implications and the debloater approach is meant for versions prior to Android 7.0, where there was no way to manually pick the WebView implementation in the developer settings. Because of that, disabling any other WebView providers higher in priority than com.android.webview is needed to force the system to fall back to com.android.webview.

[csagan5]

@SebiderSushi what needs to be done here? As far as I know nobody is working on this.

[SebiderSushi]

I'm not sure what you mean.

As far as the WebView stub apk is concerned, the following needs to be done (to my current knowledge):

Compile an apk file that basically contains just a Manifest with the correct package name. A reference proof of concept can be found here.

This apk file just needs to be signed with the same signature as the BromiteWebView release apks and the whole thing is done until further issues are revealed.

[csagan5]

It is slightly more complex than that:

• the SystemWebView needs to be built with the current package name com.android.webview
• it needs to be built also with a new package name
• the stub needs to be built

I cannot maintain the com.android.webview forever, but at the same time I am still not sure on which cases it is important to keep that package name.

[SebiderSushi]

Sure. I was just referring to the webview stub, as i'm seeing the question about the package name as a different topic. Regarding that, did you have a look at the overview that i linked in my previous comment on the other issue? I have put together a paragraph about the package name and about all possible considerations i'm seeing there, my conclusion being to keep com.android.webview.

As it currently stands, i think the lost benefits of using com.android.webview or the cost of building with two package names outweigh the gained benefits of a unique package name.

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.
 I think we can all agree that no one expects Google or some OEM to ever whitelist Bromite in AOSP or their branch of android.

[SebiderSushi]

com.android.webview might be whitelisted on a bunch of ROMs out there, but definitely is it whitelisted without a signature in LineageOS and also pure AOSP, so some OEMs might keep it that way if they also include com.android.webview with their builds.

That makes a lot of ROMs where a Magisk Module with just the files system/app/webview/BromiteWebViewStub.apk and system/app/webview/replace is enough to allow installation.
The alternative without magisk would be to cat BromiteWebViewStub.apk > /system/app/webview/webview.apk or something equivalent.

And on userdebug builds (All official LineageOS builds!), the stub apk isn't even needed and an rm -fr /system/app/webview is enough to allow installation.

The point: All of this applies to older Android versions without RRO support as well.
The cases left out by this are devices that do not whitelist com.android.webview and which need an RRO if applicable to get anywhere.

 Of couse, some metrics on this would be nicer than all of my assumptions. Real world data about the number of ROMs which fall into either of the aforementioned categories.

[csagan5]

is it whitelisted without a signature in LineageOS and also pure AOSP

Isn't this a security hole? I might understand the AOSP case, as OEMs are supposed to "complete it" before release, but how can LineageOS releases go out with this issue open?

And on userdebug builds (All official LineageOS builds!)

Ok, perhaps I do not understand how these are hardened for usage. My reference for a secure non-stock Android OS is GrapheneOS.

As it currently stands, i think the lost benefits of using com.android.webview or the cost of building with two package names outweigh the gained benefits of a unique package name.

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.

The project does not have - nor seek - affiliation; I have to make a decision regardless of what another popular - but separate - project decides.

Let's put it in another way: if the package name were org.bromite.webview, what would be the issues to use it on LineageOS or similar? I think nothing to worry about: they are already running with permissions wide open, and your paragraph about the package name seems to confirm it.

The only remaining issues are:

1. the inconvenience of the package name change for the current users
2. some stock ROM might have an unpinned com.android.webview whitelist, and they will lose the capability to install the webview

(1) will always be there, it's not on its own a good reason to never do any change/progress
I have no evidence for (2), nor numbers as you said.

did you have a look at the overview that i linked in my previous comment on the other issue?

Yes, but I reach different conclusions: the user should be capable of choosing the webview without rebooting into a boot manager or modifying the ROM, and re-using package names is just incorrect from the perspective of how Android works.

[SebiderSushi]

Again, as per security, i don't see the issue.
According to the Chromium dev comment cited in the original wiki installation guide and which i re-cited at the home page of mine:

WebView is extremely privileged because it's loaded into the address space of other applications, and so has access to the data and permissions of every single application which uses it - therefore, it can only be replaced by someone who already has the ability to compromise the application sandbox anyway: someone with root access, or the builder of the system image.

As such, i see it as sufficient to "stuff the security hole" by delivering either "user" builds or by preinstalling a package that fills the spot. Since anyone who can still replace the WebView then will still need root access they're pretty much there already. It don't see how it gets much worse for the victim if an attacker can also replace the webview on top of having at least full access to the system partition.

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Also, as GrapheneOS or any other current ROM will run at least on android Pie, an attacker with root access would also be able to place and register an RRO and replace the WebView whitelist with anything they want.
(That is, according to a test i did i was able to register an RRO on Pie and Ten, but not on Oreo or below. I am just at the start of learning about RROs though, but the point definitely stands for android Ten.)

[SebiderSushi]

Huh. Okay, i'll go into detail about your points now and then you can maybe point out how my explanation on the wiki could be understood otherwise or be unclear on certain aspects.
One thing i already see is that i only vaguely covered RROs there: This is due to my lack of knowledge about them.

I agree: Using unique package name is the correct thing to do. Being able to choose the WebView implementation in userspace is convenient and some use cases might require it (though i don't know any of them).

I think re-using com.android.webview is a valid compromise, for one because i don't see the use cases that require constantly switching the implementation but rather where the user simply wants to use a different WebView as a daily driver.
 And then again, the optimum, i.e. a user being able to install Bromite WebView as a user app just like the google WebView and use it without ever touching their system can exclusively happen if a wide range of ROMs whitelist Bromite WebView on their own.
Since we can never expect that, i think it would be rational to go for a compromise, as explained below.

Reminder: The following considerations are invalid when RRO support is present. That is, if older android versions were to be deprecated, a unique package name should definitely be used. At this time, i am unsure on which android versions RROs could be made to work, but during my tests with Marshmallow, Nougat, Oreo, Pie and Ten i was only able to register an RRO on Pie and above. I remember that @linuxandria statet RROs could theoretically be made compatible with android versions as low as 5.1, so we'll see how far we might get with this.
But consequently, going forward it will inevitably come to the day where using com.android.webview will be deprecated.

Now, as long as android versions where we cannot successfully override the WebView whitelist shall be supported by the Bromite WebView, the following consideration applies:

Without a custom WebView whitelist, the only hope to support any device, is by using the package name com.android.webview, as it is oftentimes whitelisted without pinning a signature.

Using another package name will not work, not even on LineageOS. They solely whitelist the Google WebView & a handful of Google Chrome variants (all pinned to a signature) and com.android.webview without pinning a signature.
The only open door with LineageOS in regards to WebView is that they ship userdebug builds, thereby allowing for a WebView installation after just removing the original package from the system instead of also placing a stub or the custom package in the system partition. Which is, again, no big deal if you are already in a position to remove the original webview. It is just a little more effort to do so as a user or an attacker.

The reason why i'm constantly bringing up LineageOS

These Numbers: https://www.lineageoslog.com/statistics

I think of LineageOS and LineageOS based custom ROMs as "probably a significant part of the Bromite WebView userbase". (Of course, other Projects like OmniROM are probably viable for use with custom webviews as well.)

I do this because of the following considerations:

• To install anything custom these days, you'll need an unlocked bootloader. Devices running custom ROMs would hence be unlocked as well.

• Users who like to tinker with their devices and to customize them, might be more likely to use a custom ROM as well

• And of course, it is my personal use case.

Obviously, any actual user metrics of Bromite WebView itself would be nice. As long as we don't have access to those, i only see that we can run speculations, flip a coin or deprecate anything we can't get an RRO to run on.
On that note: Easy xkcd for example conducts user surveys from time to time via google docs. Sadly, without a user interface it will be hard to catch a good portion of the users i guess.

[SebiderSushi]

TL;DR:

My current consideration is "being able to switch the webview in userspace" versus "devices with no other way to install a custom webview than by replacing com.android.webview".

Especially since i don't see use cases requiring the former, i am convinced that the latter aspect weighs much more.

The question boils down to:
Is there a significant portion of devices running the Bromite WebView where we have no option to override the WebView whitelist?

[SebiderSushi]

And again, what i've said depends on our current know-how about replacing the WebView whitelist. If anyone where to find new and better methods to replace the whitelist on real world devices, the whole argumentation will shift towards a unique package name.

Any setup where the whitelist can be overridden can properly be supported by Bromite WebView.

[csagan5]

As such, i see it as sufficient to "stuff the security hole" by delivering either "user" builds or by preinstalling a package that fills the spot. Since anyone who can still replace the WebView then will still need root access

I thought that you do not need root access if the package is there and without a signature.

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Let's ask @thestinger: there is no possibility to install a malicious webview (matching the whitelisted package name) on GrapheneOS without root access, correct?

Without a custom WebView whitelist, the only hope to support any device, is by using the package name com.android.webview, as it is oftentimes whitelisted without pinning a signature.

You forgot to mention that the user must also have root access. What about modding the OS through framework-res.apk to allow other webviews? Can it be done with root alone (I think no)? It can always be done with recovery access though, correct?

If anyone where to find new and better methods to replace the whitelist on real world devices, the whole argumentation will shift towards a unique package name.

I think it's possible to mod any ROM to support other webviews through a custom bootloader; see https://forum.xda-developers.com/showpost.php?s=16f45eae40ceea4635e4433c72137749&p=81313655&postcount=11

These Numbers: https://www.lineageoslog.com/statistics

Sorry, Bromite is not affiliated to LineageOS.

• And of course, it is my personal use case.

This makes you biased; kudos for exposing the bias, but I still have to make a choice based on the neutral case e.g. any user using any ROM.

[thestinger]

Let's ask @thestinger: there is no possibility to install a malicious webview (matching the whitelisted package name) on GrapheneOS without root access, correct?

Correct, and it uses verified boot. The OS is verified from the root of trust.

[thestinger]

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Also, as GrapheneOS or any other current ROM will run at least on android Pie, an attacker with root access would also be able to place and register an RRO and replace the WebView whitelist with anything they want.
(That is, according to a test i did i was able to register an RRO on Pie and Ten, but not on Oreo or below. I am just at the start of learning about RROs though, but the point definitely stands for android Ten.)

This is nonsensical. How exactly is a redundant signature check going to help in any situation? If an attacker has exploited the OS successfully to gain full root access, what's the relevant of this of having a signature hard-wired here? Also, you do understand that GrapheneOS has full verified boot just like the stock OS, right? It is not particularly relevant to this though...

[thestinger]

Android uses key pinning for every single app installation. If an app is built into the system image, the key is permanently pinned via the app being built into the system image. It doesn't make sense to talk about an attack where the app is replaced in the system image. An attacker would already need to have gained full root access to remount as writable and modify it. They could also modify the whitelist... how does it make any sense to propose that as an attack vector? Also, it's just going to be detected as tampering by verified on the next boot either way. Verified boot chains trust from the firmware and verifies all of the OS images.

Specifying a signature in config_webview_packages.xml is for cases where the app isn't bundled into the OS. You either list an app that's bundled into the OS without specifying a key pin or list an app that's not included in the OS with a key pin. Listing a key pin is a way to preserve security despite it not being built into the OS. It isn't the normal way to use this configuration. It would be unnecessarily complicated for everyone to need to modify this configuration file to specify the key of the bundled WebView and isn't how it's implemented. The OS provides signature verification for every installed package already.

[thestinger]

I can't think of any case where using com.android.webview would be helpful. If there is already an app bundled, then you can't install it. If there isn't one installed, the whitelist needs to have a pinned key. Either way, you need support for Bromite built into the OS. Doing it properly with the security model and update system preserved requires doing it as part of building before generating a signed release. Hacking it into an existing release by abandoning verified boot and update system compatibility (if you make any changes, you've broken incremental updates) doesn't really change anything. You can convert the resources to xml from binary xml, modify it and convert it back. Either way you're building it into the OS.

[csagan5]

You either list an app that's bundled into the OS without specifying a key pin or list an app that's not included in the OS with a key pin.

I can't think of any case where using com.android.webview would be helpful. If there is already an app bundled, then you can't install it.

The only insecure scenario is when there are whitelisted packages and the ROM comes without such packages installed. The previous discussions here on this issue are confusing when they don't explicitly mention this condition.

There are a lot of hypothesis cast here; my rationale is more or less: if com.android.webview is beneficial to non-root users of such insecure ROMs, I have no interest in supporting them.

So @SebiderSushi I think the research can be split into two trunks:

1. options to install the WebView without root and an unlocked bootloader (e.g. non-verified boot process)
2. options to install the WebView with root

You have already done a lot of investigation, what would make sense to me is to arrange this in some sort of user guide/flow diagram; each step should also be clear about the security implications.

[SebiderSushi]

I am aware that the only way to install a webview without breaking the security model is to have it supported at build time.

Thus, i am implying unlocked bootloaders (and consequently root/full system access) at all times aince it's the only realistic way to install a custom webview on an end user device without building a full rom to achieve that.

[SebiderSushi]

As a consequence i am not talking about any use cases that preserve AVB.

I am unaware of any ROM that would bundle Bromite support. That's what i meant when i was saying

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.

At no point did I want to imply any affiliation but without such a thing happening, the only remaining use case is users with unlocked bootloaders patching up their system partitions or installing Magisk Modules or whatever does the job.

[SebiderSushi]

I can't think of any case where using com.android.webview would be helpful. [...] You can convert the resources to xml from binary xml, modify it and convert it back. Either way you're building it into the OS.

Counterexample:

• unlocked bootloader
• user build that whitelists com.android.webview without pinning a signature
• preinstalled webview installed as /system/app/webview/webview.apk
• no RRO support (android 6 or something)

I can install Bromite WebView by running
cat bromitewebview.apk > /system/app/webview/webview.apk in TWRP for example.
And i can boot this and use Bromite WebView.
Just because Bromite WebView currently uses com.android.webview

How would i replace the webview whitelist in this scenario to support a unique package name if patching up framework-res.apk will not work because i can't re-sign it with the platform key?

[SebiderSushi]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

[androidacy-user]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

Kinda pointless as on 10+ browser and webview are separate in upstream chromium

[thestinger]

They're not really separate but rather it's split into 3 apks: browser, WebView and a library apk providing most of the code which is shared between them.

[thestinger]

The standalone WebView target is perfectly modern and still fully supported. The standalone browser apk targets are not intended for usage on modern devices. If you wanted to avoid having the library split out while still being a modern build, you would need to make a new target.

[androidacy-user]

They're not really separate but rather it's split into 3 apks: browser, WebView and a library apk providing most of the code which is shared between them.

For our intents separate packages separate apps, although I am aware of trichrome vs monochrome

[androidacy-user]

We're going to assume trichrome library is available on devices that needs it, and we're only worried about webview and to an extent browser

[thestinger]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

[androidacy-user]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

Well yes what's what I'm saying :)

[SebiderSushi]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

My motivation behind that question has beed the following idea:
The Bromite browser has its own package name, so it can already be whitelisted properly. If it were able to provide webview capabilities, most users should be fine after installing it.
Also, for users of both bromite webview and the bromite browser, this would reduce storage & bandwith usage.

Granted, debugging the standalone webview in parallel to having an upstream chromium webview package installed would still be impossible.

As for Trichrome vs. Monochrome: They are just both methods of deduplicating code right? And they are both valid and work, even on android 10+?
At least that's how i read this XDA post about it, with the benefits over Monochrome being that Trichrome has "fewer weird special cases and bugs."

[thestinger]

No, it's not simply a choice between different ways to share code.

[androidacy-user]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

My motivation behind that question has beed the following idea:
The Bromite browser has its own package name, so it can already be whitelisted properly. If it were able to provide webview capabilities, most users should be fine after installing it.
Also, for users of both bromite webview and the bromite browser, this would reduce storage & bandwith usage.

Granted, debugging the standalone webview in parallel to having an upstream chromium webview package installed would still be impossible.

As for Trichrome vs. Monochrome: They are just both methods of deduplicating code right? And they are both valid and work, even on android 10+?
At least that's how i read this XDA post about it, with the benefits over Monochrome being that Trichrome has "fewer weird special cases and bugs."

Trichrome is Android 10+, monochrome is =< 9

[thestinger]

The upstream build system also doesn't define standalone browser targets for modern Android. If you want that, you need to define them yourself, otherwise you'll be deploying builds not fully supporting the modern platform.

For the WebView, the standalone WebView target is fully supported across all supported versions. If you want to share the code with the browser, Trichrome is used on Android 10+ and Monochrome for earlier versions (ever since it became supported). Monochrome isn't supported on Android 10+ and Trichrome isn't supported before Android 10.

[thestinger]

It's incorrect to use ChromeModernPublic on Android 7+. You need to define your own target for a standalone browser. It will work, but it won't support the modern platform features including security improvements tied to API level.

It's similarly incorrect to use Monochrome on Android 10+, and it will not work as a WebView provider at all. It will only provide a working browser with the same issue as ChromeModernPublic, with a less ancient target API level.

[csagan5]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

APKs can bundle .so libraries and if they are exactly the same they will be shared in-memory (as any Linux does) thus reducing the memory footprint for both apps.

It's incorrect to use ChromeModernPublic on Android 6+. You need to define your own target for a standalone browser. It will work, but it won't support the modern platform features including privacy/security improvements tied to target API level.

@thestinger ChromeModernPublic is not the right target for a standalone browser? What do you use for Vanadium? I have always been referring to https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple-Chrome-Targets which is a bit scarce on the use cases.

[thestinger]

APKs can bundle .so libraries and if they are exactly the same they will be shared in-memory (as any Linux does) thus reducing the memory footprint for both app

TrichromeLibrary does that with both the native library and other resources. It uses the standard infrastructure for using an apk as a library (which goes beyond just a native library) in a way that's properly authenticated.

@thestinger ChromeModernPublic is not the right target for a standalone browser? What do you use for Vanadium? I have always been referring to https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple-Chrome-Targets which is a bit scarce on the use cases.

@csagan5 There is no modern standalone browser target because Chrome doesn't use it so they haven't defined one. Vanadium uses the Trichrome targets. TrichromeChrome + TrichromeLibrary without shipping TrichromeWebView is the only way to get a modern browser using only the upstream targets. We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion. Using the 64_32 targets is also now the correct way to prefer 64-bit processes and that's part of the Trichrome build infrastructure. You can use Trichrome without the WebView (by just using the browser and library apk) but it's not setup to build it as a single browser apk without the library.

[thestinger]

Modern doesn't actually mean modern - it meant modern at the time it existed, compared to the older one. It was replaced by Monochrome and then Trichrome. Chrome is never shipped as a standalone browser without the WebView so there is no upstream target for something they never use. Quite possible to make it but they don't since they have no use for it.

[csagan5]

We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

Bromite builds only the 64-bit version of the APKs so at least on this aspect I think the processes cannot run over 32-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion.

It could be a bloodbath, but I am compelled to try now.

Using the 64_32 targets is also now the correct way to prefer 64-bit processes and that's part of the Trichrome build infrastructure.

Sure, it would have the benefit to be compatible for both 32-bit and 64-bit architectures.

Modern doesn't actually mean modern - it meant modern at the time it existed, compared to the older one. It was replaced by Monochrome and then Trichrome.

Yes, I was aware of the relativity of "modern" - but what surprises me from your posts is that there is actually a substantial difference in the security features (and possibly not related to security alone?) when using MonoChrome < Android10 and TriChrome >= Android10. I have always been under the impression that the only advantage was the shared libraries/memory savings in conjunction with a SystemWebView, and nothing else.

Would you care to explain those differences, or otherwise point me to some official documentation for me to learn about it? I surely want to tackle this problem once I understand the entity of it.

[androidacy-user]

We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

Bromite builds only the 64-bit version of the APKs so at least on this aspect I think the processes cannot run over 32-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion.

It could be a bloodbath, but I am compelled to try now.

I remember a Google groups discussion on trichrome vs monochrome but I can't seem to find it now

[thestinger]

@csagan5 As long as targetSdkVersion is set to the proper value (29 for Android 10), it's not nearly as big of an issue as it used to be and I think they've probably changed this part for all the targets now due to the Play Store requirements.

[csagan5]

As long as targetSdkVersion is set to the proper value (29 for Android 10), it's not nearly as big of an issue as it used to be and I think they've probably changed this part for all the targets now due to the Play Store requirements.

Ok, thanks for your reply. So I could avoid using TriChrome by simply rebuilding ChromeModernPublic with a different targetSdkVersion? It makes sense that not including older bindings reduces exposure to less secure APIs.

[thestinger]

targetSdkVersion should always be 29 regardless of minSdkVersion. Trichrome has a much higher minSdkVersion and gets to avoid including legacy things and using legacy approaches like the crazy linker. I am not quite sure how to set up a proper truly modern standalone browser target at the moment though. There are a few things that need to be adjusted.

[wchen342]

@thestinger I have a question about Trichrome. The instructions here says Trichrome will produce two files, TrichromeChrome.aab and TrichromeLibrary.apk. From my understanding, TrichromeLibrary.apk is only the libary files which does not contain the main runnable, and TrichromeChrome.aab is a bundle file which cannot be installed directly on a phone like .apk. So how do you actually install the whole browser, without doing something fancy like extracting apk from aab?

[thestinger]

You can generate a universal apk from the bundle, or you can generate an apk specialized to the device that you're installing on which is what the Play Store does for developers who give their signing keys to Google. The tool for generating apks (universal or more specialized to devices) is open source (bundletool). I recommend looking at generate_release.sh in the Vanadium repository.

[csagan5]

Starting from the v97 release the Bromite SystemWebView will have its package name changed to org.bromite.webview.

As for stubs: please create a PoC that compiles with gradle or with the Chromium build tools and I will consider it.

Thanks for the useful discussions!

[androidacy-user]

Starting from the v97 release the Bromite SystemWebView will have its package name changed to org.bromite.webview.

As for stubs: please create a PoC that compiles with gradle or with the Chromium build tools and I will consider it.

Thanks for the useful discussions!

Do you have any idea when m97 will land for you guys? We need to properly implement it in WebView Manager if the package name is going to change.

[SebiderSushi]

Thanks for the update!

The idea for the stub was to leverage the fact that com.android.webview is whitelisted on virtually any rom and the signature doesn't matter as long as the WebView is installed to the system partition. The stub was supposed to facilitate that step in certain scenarios, e.g. a small, simple and static Magisk Module that does nothing besides placing the stub in the system partition. Now that the WebView has its unique package name there is no longer any realistic use for a stub.

Thanks for considering.