Trichrome INSTALL_FAILED_MISSING_SHARED_LIBRARY

[wchen342]

@thestinger I am facing a problem trying to install Trichrome apk onto device. So I used generate_release.sh from Vanadium to sign both the TrichromeChrome.apk and TrichromeLibrary.apk, and then I tried to install them onto a device using adb install TrichromeLibrary.apk and then adb install TrichromeChrome.apk, but the second command always failed with

adb: failed to install TrichromeChrome.apk: Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY: Reconciliation failed...: Reconcile failed: Package org.ungoogled.chromium.stable requires differently signed static shared library; failing!]

My suspect is TrichromeLibrary.apk is a shared library so it should be copied to a system directory on the device instead of being installed, but does that mean there is no way for a user to simply install a Trichrome version of Chromium without root?

[thestinger]

You need to adjust the trichrome digest in args.gn to use your signing key fingerprint.

[thestinger]

https://grapheneos.org/build#browser-and-webview

[wchen342]

That solved the problem. Thanks for the help!

[lzlrd]

You need to adjust the trichrome digest in args.gn to use your signing key fingerprint.

Would you possibly be thinking of signing the Trichrome packages in releases as well as providing the TrichromeWebView package? As far as I understand, it is not possible to adjust the trichrome digest without rebuilding - rendering those packages in releases useless.

[wchen342]

What do you mean? The apks I published are already signed.

[lzlrd]

What do you mean? The apks I published are already signed.

I assumed from your message above that args.gn doesn't have your signing key's hash, as I'm still experiencing the INSTALL_FAILED_MISSING_SHARED_LIBRARY error with the latest release.

[wchen342]

You cannot have my singing key, otherwise you will be able to post apks as if they are compiled by me. You need to create your own signing keys and put its digest in the gn file.

[lzlrd]

You cannot have my singing key, otherwise you will be able to post apks as if they are compiled by me. You need to create your own signing keys and put its digest in the gn file.

I understand that. I'm asking if you build with your signing key in args.gn because I'm getting the INSTALL_FAILED_MISSING_SHARED_LIBRARY error from your releases.

[wchen342]

Yes it should be built with the signing key. Let me check the log to make sure.

EDIT: I check the logs. The keys are applied.

[lzlrd]

Yes it should be built with the signing key. Let me check the log to make sure.

EDIT: I check the logs. The keys are applied.

Any ideas why I'm getting the stated error with the latest release? I'm running Android 11 on a Pixel 5, if that helps.

I'm able to install the TrichromeLibrary, however it doesn't appear as installed (with package manager/pm) and installing the browser APK results in INSTALL_FAILED_MISSING_SHARED_LIBRARY.

PS: Chrome isn't bundled with ProtonAOSP, the ROM that I'm running.

[wchen342]

Interesting, I tested a local build and it did not work too. It used to work before and I am not sure what changed. I will investigate a little more.

[lzlrd]

Interesting, I tested a local build and it did not work too. It used to work before and I am not sure what changed. I will investigate a little more.

You may already know this, but I had to manually remove the library from /data/app (and /data/data) as pm wasn't picking it up. You may need to do the same to remove it before you test a newer build.

[wchen342]

I forgot to update the digest when I updated the keystore file. The next version shall be good.

[lzlrd]

I forgot to update the digest when I updated the keystore file. The next version shall be good.

This could probably use another issue (feel free to tell me to make one) but would you be willing to provide the TriChomeWebview package as well, for the next release?

[wchen342]

This could probably use another issue

As long as you won't lose track of it I am fine with this.

would you be willing to provide the TriChomeWebview

Is there any specific reason this is better than the general webview package? I kept getting compile problems on webview at this version so I am not sure I want to add another problematic target to compile.

[lzlrd]

Is there any specific reason this is better than the general webview package? I kept getting compile problems on webview at this version so I am not sure I want to add another problematic target to compile.

For users of TriChrome, it's preferred to use the TriChromeWebview package (as well as reducing space, it follows upstream). I haven't built Chromium for Android in a while, however if SystemWebview and the two base TriChrome* packages compile, you shouldn't really have any problems with TriChromeWebview.

For some reason, I've also had issues with non-Trichrome Webviews from Bromite and Ungoogled Chromium (applications don't load the Webview within their "context"). I built the TrichromeWebview variant of this repository (albeit with a few changes) a while back, and that was no longer the case.

[wchen342]

I can try to build the two webview together. There is another problem for me that the Github actions have a maximum queue time and run time limit so all the versions cannot be compiled together if there are too many variants. I will try and see how it goes and decide.

[wchen342]

Are you on arm or arm64? I think I will only compile the arm64 version since it is unlikely TriChrome can run on an arm device.

[lzlrd]

Are you on arm or arm64? I think I will only compile the arm64 version since it is unlikely TriChrome can run on an arm device.

I'm on arm64, but I don't see why TriChrome* won't work on arm (or even x86, if Google still supports that upstream). There are arm Android 11 devices out there, so TriChrome* should work fine on those.

[wchen342]

The problem is build time. I already have (arm, arm64, x86) x (ChromeModernPublic, TriChromePublic, SystemWebView) which equals 9 targets to build, and they will take roughly 40 hours to build on the runner. If I add three more targets that will become 70 hours.

[lzlrd]

The problem is build time. I already have (arm, arm64, x86) x (ChromeModernPublic, TriChromePublic, SystemWebView) which equals 9 targets to build, and they will take roughly 40 hours to build on the runner. If I add three more targets that will become 70 hours.

Oof. I'm no GitHub Actions expert, but is it possible to maybe split the runner per-architecture so they run in parallel?

[wchen342]

I have only one server sponsered by Gandi so I can only run one workflow at a time, and Github Actions does not support queueing workflows right now, and if a job is queued for more than 24 hours it will get canceled. So basically if the build time of all the variants exceeds 24 hours I will kind of manually triggers the build anyway but 72 hours is basically the upper limit of what is possible to run.

[lzlrd]

I have only one server sponsered by Gandi so I can only run one workflow at a time, and Github Actions does not support queueing workflows right now, and if a job is queued for more than 24 hours it will get canceled. So basically if the build time of all the variants exceeds 24 hours I will kind of manually triggers the build anyway but 72 hours is basically the upper limit of what is possible to run.

That is problematic. I guess just building TriChomeWebview for arm64 would do, then (it shouldn't be that long of an increase though, as TriChromeWebview is much smaller than SystemWebview).

[wchen342]

Actually it's the opposite because of how gn works. To build SystemWebview ninja will only needs to build the webview part and a part of the normal chormium target, but for TriChromeWebview it needs the TriChrome target. It is ~38000 targets vs. ~58000 targets. Also I do not do incremental build for the releases because I want to build each executable clean so for each target it will start from scratch with a new docker container.

[lzlrd]

Actually it's the opposite because of how gn works. To build SystemWebview ninja will only needs to build the webview part and a part of the normal chormium target, but for TriChromeWebview it needs the TriChrome target. It is ~38000 targets vs. ~58000 targets. Also I do not do incremental build for the releases because I want to build each executable clean so for each target it will start from scratch with a new docker container.

I understand but since the TriChome packages are meant to be together, I think it's fair to build them incrementally. I don't think even Google build each TriChrome package clean.

[lzlrd]

I'm not sure how helpful this is, but Packet/Equinix provide servers for OSS projects, which may be faster than what you're currently building on.

[wchen342]

I split the builds because I used to have a problem building ChromeModernPublic and SystemWebView together on arm64. ninja will mistakenly assume a file is built but it is actually not. I am not sure whether that can happen with TriChrome too. Another issue is I need to organize them by release in the workflow. I think it is better to group main browsers together so they are in on release, so I need to put the building of those browsers in one file.

Packet/Equinix provide servers for OSS projects

I haven't heard about this. But a problem with these build service is usually only a "cleaned" version of chromium without proprietary codes is allowed but I also needs to checkout extra files with gclient so I am not very sure I will meet the limit. This is also part of the reason no chromium forks are on F-Droid official server.

[lzlrd]

I split the builds because I used to have a problem building ChromeModernPublic and SystemWebView together on arm64. ninja will mistakenly assume a file is built but it is actually not. I am not sure whether that can happen with TriChrome too.

I meant that building all of TriChrome together should be fine, the rest can stay separate as usual.

Another issue is I need to organize them by release in the workflow. I think it is better to group main browsers together so they are in on release, so I need to put the building of those browsers in one file.

Sure, that's your call.

I haven't heard about this. But a problem with these build service is usually only a "cleaned" version of chromium without proprietary codes is allowed but I also needs to checkout extra files with gclient so I am not very sure I will meet the limit. This is also part of the reason no chromium forks are on F-Droid official server.

I mean, they have let Android "Custom ROMs" join in the past (no more due to the influx, rather than a change of ToS) so I don't see why this project would have any issues.

[lzlrd]

While we're here, https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html might call for an update sooner than later (see CVE-2021-21148).

[wchen342]

I already updated that. The binaries haven't been compiled yet.