Is there a possibility to change the webview in e/ ?
e/ says that their webview is a fork of bromite, but because the name ia the same one that Android , it makes it a bit confuse.
Webview like mulch from divestos seema more pro and have another name that is not Android so makes it easy to see that is a fork.
I don’t see what the problem is. It’s a fork of Bromite’s, which you know, so its name in the ROM isn’t and shouldn’t be a concern. A nit pick really.
But on the other hand, it would be nice if /e/ used Bromite’s or UnGoogled Chromium’s or Mulch’s WebView directly with no signature change so they could be updated regularly, via F-Droid for instance.
My Essential PH-1 mata runs an older /e/OS so I had to change things out to keep parts like that updated.
Alternatively, by using a fork, it would be nice if they kept that updated with upstream and offered a way to download and install that.
A regularly updated WebView is just as important as an updated Firefox-/Chromium-based browser, if not more so, given its use by various apps and alternative browsers.
If rooted then it is probably doable via a Magisk module. I do so on other ROMs but have not on /e/.
On the other hand, if the last Nanodroid Bromite Webview package can be flashed successfully then it can also be regularly updated via F-Droid (with Bromite repo added).
This will essentially be vanilla Chromium webview (com.android.webview).
A rooted ROM would not be necessary.
I say “successfully” for a few reasons. Whether or not the package handles current system root location and whether it can find and replace the existing webview.
/e/ for instance places its webview at /system/app/BrowserWebView/, which is a non-standard location. The installer package wouldn’t (didn’t) know how to remove/replace it.
I vaguely remember, on /e/OS Pie having to manually remove it. I had TWRP on that device at the time. Currently neither of my /e/ devices have TWRP.
Maybe today I’ll take a look at either method. In the case of the Nanodroid Bromite webview installer I’ll check to see if the updater script needs modification first.
Ouch on the microG thing. Heh, I would’ve warned against that.
To get the full NanoDroid package to only install certain items and exclude others requires setting up config files first. Not sure if you did that or not. Not just the full but also the microG package also.
I remember I’d use NanoDroid package for debloating and installing just F-Droid stuff, then flash a MinMicroG package on some older ROMs.
Anyway, the MinMicroG people have a standalone Aurora Services package you can get below.
I’m interested on the System Webview discussion. I think it’s an important feature for security but I’ don’t have and no more want a rooted phone if I can have a degoogled phone (this is the reason why I appreciate eOS).
My question is: can I change the Webview using root debug USB, a feature I have now on A12 (FP4, eOS v. 1.5 stable)?
Back in the day, before the package name change, we would try to get Bromite webview working on OEM stock ROMs. Whereas all custom ROMs use/supoort com.android.webview, stock ROMs did not. Only Google’s webview and Chrome products.
After going through the steps we’d cross our fingers and hope the ROM would boot. Usually not due to signature issues.
Fast forward to current time. Bromite’s webview is now org.bromite.webview. To use that one has to hope that custom ROMs today have added support for it. LineageOS in this case.
One can either go through the steps to find out (or search around to see if that’s the case) or just use the standard Chromium webview (com.android.webview) and not worry about the framework procedure.
Chromium webview is available for regular updates via F-Droid, using Bromite repo, so that’s cool.
You can get the Chromium webview from here…
EDIT: Even though I have Magisk and could’ve just used the WebView Manager module, I decided to mess around and use the NanoDroid Bromite WebView package. It didn’t go as easy for me as it did for @Matias_Javier . The /e/ BrowserWebView was still in play but I eventually fixed things. Now the Teracube has the latest webview.
YMMV.
Then there’s the other issue. Does one want just an updated webview or one with some privacy related patches.
Example is with WebRTC IP leaks.
I have a ROM that I wanted to set up in a different way, with no Firefox or Chromium-based browsers. Rooted but not with Magisk. One browser used is Fulguris. It has a WebRTC toggle which I turn off.
In a test I see the public and local IP addresses are present. An issue has been opened on their github by the dev himself. Since the webview may be (part of) the reason I tested the browser on four devices.
Two with Chromium/vanilla webview exposed the IPs, local and public. One with Bromite webview and the other with /e/'s webview did mot expose any IPs.
When I switched one of the first two to VPN over Tor then the public IP was not shown but the local IP was.
That’s just one example.
Still, none of us should have to jump through hoops or risk screwing up our systems to “fix” such an important part of the system.
Why not just use FireFox? Would broaden the appeal as well. Its important to remember, that if /e/ is to succeed, it cant be only for the tech savvy. When there are non-gogol mainstream alternatives, why not go for them?
Historically speaking I was never a fan of Magisk for a number of reasons. Didn’t start using it until /e/OS Pie on the Essential PH-1. Lineage SU was insufficient on a system-as-root setup (would not work with AdAway or Substratum for instance). With Pie and above, if one wanted root, Magisk was pretty much the only game in town.
On my Moto devices, where I was still multibooting, Magisk was definitely a no-go. When Bromite Webview changed package names I could only now use the updated vanilla/chromium webview. As mentioned earlier, we get WebRTC leaks and whatnot.
So I tried method 1 on crDroid Oreo, Moto G5s Plus sanders, non A/B SAR device. Has TWRP so adb wasn’t necessary. Flashing the zip didn’t work. No errors but I believe the zip expects system-as-root, treble compatible setup or something. The apk didn’t get installed to /vendor/overlay/.
Method 2, on the other hand, was a success. Manually placed the apk to the overlay location, bromite webview already installed as a user app. Now developer options showed both webviews. Selected Bromite and did WebRTC check. No leaks.
There you go, another way to possibly get Bromite WebView onto one’s system.
As far as I see, the second method uses Rooted Debugging. This isn’t plain root, it’s a switch in the Developer options which enables ADB to work as root if wanted or needed.
Not every /e/OS build might support Rooted Debugging, though, I’m not sure about the current status.