open_webview

open_webview copied to clipboard

module_install_log_2023-11-13T00_11_32.304997.txt

Please help as I am not able to install this module.

But according to the recent changelog, this was made compatible with KernelSU. https://github.com/Magisk-Modules-Alt-Repo/open_webview#v231 https://github.com/Magisk-Modules-Alt-Repo/open_webview/releases/tag/v2.3.1

@foxjaw It works. Please, don't forget to give "Shell" root access in KernelSU or the installation will fail. I think that is your problem.

@amteza Right. Tq. But can you mention this in readme ? Caz most don't toggle it in the first place.

I did in XDA, but maybe @F3FFO can add it as a requirement in the README. I will send a PR to update it.

That's okay. Most genz & boomers actually stopped using XDA. All the FOSS android project forums are discussed right in their repositories, which makes the most sense btw.

Yep, the only reason I used XDA was because of a query from someone in there. In any case PR created.

@amteza I enabled su for shell but it still is not able to install the module. Attaching logs for reference: module_install_log_2023-11-20T08_25_18.046151.txt

@foxjaw does not happen with me, instead it does download the webview and install it as a user app.

@amteza I enabled su for shell but it still is not able to install the module. Attaching logs for reference: module_install_log_2023-11-20T08_25_18.046151.txt

The issue you are experiencing has nothing to do with KernelSU. I just checked the logs. Is like it is not downloading the required files chmod: /data/adb/modules_update/open_webview/addon/Volume-Key-Selector/tools: No such file or directory.

Are you putting together a proper .zip file executing create-module.sh? I will let the developer chime in.

Okay, can you try this one? open-webview.zip

Okay, can you try this one? open-webview.zip

Failed for me too attaching logs: KernelSU_install_log_2023-11-20-12-47-36.log

RMX3031:/ # su -c df -h
Filesystem        Size Used Avail Use% Mounted on
/dev/block/dm-0   1.4G 0.9G  509M  67% /
tmpfs             3.6G 2.6M  3.6G   1% /dev
tmpfs             3.6G    0  3.6G   0% /mnt
/dev/block/sdc5    59M  43M   16M  73% /mnt/vendor/oplusreserve
/dev/block/sdc15   27M 184K   27M   1% /metadata
/dev/block/dm-1   754M 654M  100M  87% /vendor
/dev/block/dm-2   2.5G 2.0G  512M  81% /product
/dev/block/dm-3   1.4G 1.3G  100M  94% /odm
/dev/block/dm-4   1.5G 1.0G  512M  69% /system_ext
tmpfs             3.6G  16K  3.6G   1% /apex
tmpfs             3.6G 560K  3.6G   1% /linkerconfig
/dev/block/sdc55  402M  56K  402M   1% /cache
/dev/block/sdc14   58M  19M   39M  34% /mnt/vendor/nvdata
/dev/block/sdc13   27M 184K   27M   1% /mnt/vendor/nvcfg
/dev/block/sdc17  3.7M 160K  3.5M   5% /mnt/vendor/protect_f
/dev/block/sdc18  3.7M 148K  3.5M   4% /mnt/vendor/protect_s
/dev/block/sdc16   47M 696K   47M   2% /mnt/vendor/persist
/dev/block/dm-32  108G  17G   91G  17% /data
tmpfs             3.6G    0  3.6G   0% /data_mirror
/dev/block/loop4  720K 692K   28K  97% /apex/com.android.sdkext@330400000
/dev/block/loop7  232K 108K  124K  47% /apex/com.android.scheduling@330400000
/dev/block/loop6  232K  96K  136K  42% /apex/com.android.apex.cts.shim@1
/dev/block/loop5  232K  80K  152K  35% /apex/com.android.ondevicepersonalization@330400000
/dev/block/loop9   45M  45M   28K 100% /apex/com.android.vndk.v33@1
/dev/block/loop8  1.8M 1.8M   28K  99% /apex/com.android.os.statsd@330400000
/dev/block/loop10  20M  20M   32K 100% /apex/com.android.btservices@339990000
/dev/block/loop13 8.5M 8.5M   36K 100% /apex/com.android.runtime@1
/dev/block/loop12 784K 756K   28K  97% /apex/com.android.tzdata@330400000
/dev/block/loop14  36M  36M   28K 100% /apex/com.android.i18n@1
/dev/block/loop11 3.3M 3.2M   32K 100% /apex/com.android.appsearch@330400000
/dev/block/dm-28  696K 668K   28K  96% /apex/com.android.ipsec@330400000
/dev/block/dm-26  5.8M 5.8M   28K 100% /apex/com.android.extservices@330400000
/dev/block/dm-27  2.8M 2.7M   28K 100% /apex/com.android.uwb@330400000
/dev/block/dm-25  8.4M 8.4M   28K 100% /apex/com.android.mediaprovider@330400000
/dev/block/dm-20  5.8M 5.7M   28K 100% /apex/com.android.media@330400000
/dev/block/dm-22  7.9M 7.9M   28K 100% /apex/com.android.adbd@330400000
/dev/block/dm-18  8.2M 8.1M   32K 100% /apex/com.android.wifi@330400000
/dev/block/dm-15   47M  46M   36K 100% /apex/com.android.art@330400000
/dev/block/dm-12  4.9M 4.9M   28K 100% /apex/com.android.conscrypt@330400000
/dev/block/dm-14   15M  14M   28K 100% /apex/com.android.permission@330400000
/dev/block/dm-23   19M  19M   28K 100% /apex/com.android.media.swcodec@330400000
/dev/block/dm-9   232K 196K   36K  85% /apex/com.android.adservices@330400000
/dev/block/dm-11   12M  12M   28K 100% /apex/com.android.cellbroadcast@330400000
/dev/block/dm-10  7.3M 7.2M   32K 100% /apex/com.android.neuralnetworks@330400000
/dev/block/dm-7   3.8M 3.8M   28K 100% /apex/com.android.resolv@330400000
/dev/block/dm-5   9.2M 9.2M   32K 100% /apex/com.android.tethering@330400000
/dev/block/loop31 299M  29M  270M  10% /data/adb/modules
KSU               299M  29M  270M  10% /system
KSU               299M  29M  270M  10% /system/etc
/data/media       108G  17G   91G  17% /mnt/runtime/default/emulated
/dev/fuse         108G  17G   91G  17% /mnt/installer/0/emulated

I think so have not tried along with ksu, but previously when I only had magisk then it was working for me.

Okay, give me some time today to do some testing. Are you trying Android 14? What device are you trying with?

I'm using ponces A14 GSI on Redmi Note 10. Nothing modified other than a kernel with kernelSU support Even tested @lss4's mulch-webview-overlay which doesn't seems to work either.

I've confirmed this is due to an overlay included in GSIs which added out-of-box support for Bromite back then. It appears to be taking precedence over other overlays, preventing them from taking effect.

So unless support for other WebViews gets added into that overlay, GSI users need to remove or replace it.

I've confirmed this is due to https://github.com/phhusson/treble_experimentations/issues/2591 included in GSIs which added out-of-box support for Bromite back then. It appears to be taking precedence over other overlays, preventing them from taking effect.

You've removed that APK and confirmed the issue? The overlay in this module has priority 9999, the priority in TrebleDroid's overlay is only 8998. This overlay should still take precedence over TrebleDroid's.

Lmao. I thought phhusson's was the purest AOSP without any modifications other than phh treble settings.

Well that's wrong, the treble settings app in itself is largely useless without a lot of framework changes to actually apply those changes

Strange that he's doing these underneath implementations silently.

I welcome any patch/recommendation on how to handle OEM's /vendor/overlay setting their own webviews. (Ideally this list of webviews simply wouldn't exist, and we'd trust the user)

You've removed that APK and confirmed the issue? The overlay in this module has priority 9999, the priority in TrebleDroid's overlay is only 8998. This overlay should still take precedence over TrebleDroid's.

Thanks for the advice. So the issue here is probably different from what's going on with my unofficial Mulch overlay builds, as mine (actually A4Alpha's) has a priority of 1 compared to your 8998.

@lss4's mulch-webview-overlay

Btw this worked for me previously since I was not able to install this module, and have not tried it with the current ROM that I am using. Also want to add that I had to use the manual way to make it work since both the magisk module and the trwp flashable did not work from the mulch-webview-overlay repo.

Also in my case, I am not able to see any other webview present that might be prioritized. Checked via:

su -c cmd overlay list | grep webview
su -c cmd package list packages | grep webview

I think the requirement to have a presence of webview packages as system app was something required only in older Android versions (around 9) and no longer holds true in newer Android versions.

This was mostly about a flag called availableByDefault which had effect back then but doesn't appear to be the case anymore -- For newer Android versions, if a package signature has been provided for a WebView provider, it can be installed as a user app regardless of that flag.

As such, I don't think the module needs to actually download and install the WebView packages as they're pretty large compared to the overlay itself. If the user happens to be offline, or has bad network connectivity, it would complicate things. Users should first install the overlays, then install the actual WebView package using their favorite methods and set it active.

EDIT: Looking at the previously reported install outputs... why is the module downloading things to /dev/tmp/? I don't think it's a valid place... shouldn't it be somewhere in /data like /data/local/tmp?

This overlay should still take precedence over TrebleDroid's.

@phhusson But it didn't. I've removed priomisc overlay through root and then saw mulch webview. And no, the module overlay had priority 1 btw.

If you're referring to my unofficial Mulch WebView overlay builds, then yes. That one indeed has a priority of 1. Maybe I'll consider increasing the priority high enough to see if it will override highpriomisc for GSI users.

Considering this module here (Open WebView) has a priority of 9999 its issue with KernelSU might be something different, as I previously replied.

@lss4's mulch-webview-overlay

Btw this worked for me previously since I was not able to install this module, and have not tried it with the current ROM that I am using. Also want to add that I had to use the manual way to make it work since both the magisk module and the trwp flashable did not work from the mulch-webview-overlay repo.

The official repo hasn't been updated, and by default it installs to /vendor/overlay which no longer works since most recent Android versions (13 QPR3) -- you need to install to /product/overlay.

FYI, TWRP flashable variants of my unofficial builds are untested and there's a good chance it won't work with non-vndklite GSI variants, or dynamic system partitions.

Also in my case, I am not able to see any other webview present that might be prioritized. Checked via:

su -c cmd overlay list | grep webview
su -c cmd package list packages | grep webview

For your first command, through adb shell and with the Mulch WebView overlay I'm currently using, same here -- the overlay package is not listed (even without grep), but it is indeed working per dumpsys webviewupdate output.

Also, Mulch's package name doesn't contain webview. It's called us.spotco.mulch_wv.

Also in my case, I am not able to see any other webview present that might be prioritized. Checked via:

su -c cmd overlay list | grep webview
su -c cmd package list packages | grep webview

For your first command, through adb shell and with the Mulch WebView overlay I'm currently using, same here -- the overlay package is not listed (even without grep), but it is indeed working per dumpsys webviewupdate output.

Also, Mulch's package name doesn't contain webview. It's called us.spotco.mulch_wv.

Just verified with the Experimental Release you posted that this is indeed true.

A complete & satisfactory solution is @lss4's overlay implementation, which is very small by itself & doesn't need to be online. And we can install/update the webview as per our convenience, considering the fact that webviews need not to be system installed.

Yup! I got it working on PocoF1 under CrDroid v10.1 ROM (A14) with KSU v0.7.6

Edit: @lss4 's repo: https://github.com/lss4/mulch-webview-overlay