Build failure - TrichromeLibrary: No source files specified
Closed this issue · 15 comments
Hi,
I'm getting the below error while I'm trying to build aosp with opengapps. I see that there are some latest changes around the same TrichromeLlibrary (ref: commit). Please let me know if there is anything that needs to be done to overcome this error.
I'm currently builing aosp android-10.0.0_r15 with stock variant of opengapps for walleye. @MarijnS95 Please help here if possible.
Error:
zipinfo: cannot find zipfile directory in one of vendor/opengapps/sources/arm64/app/com.google.android.apps.translate/23/nodpi/64000865.apk or
vendor/opengapps/sources/arm64/app/com.google.android.apps.translate/23/nodpi/64000865.apk.zip, and cannot find vendor/opengapps/sources/arm64/app/com.google.android.apps.translate/23/nodpi/64000865.apk.ZIP, period.
[ 97% 510/521] including vendor/opengapps/build/modules/TrichromeLibrary/Android.mk ...
FAILED:
vendor/opengapps/build/modules/GoogleWebViewOverlay/Android.mk: error: TrichromeLibrary: No source files specified
build/make/core/prebuilt_internal.mk:37: error: done.
20:02:25 ckati failed with: exit status 1
#### failed to build some targets (04:09 (mm:ss)) ####
For anyone else facing the issue, you might want to revert the last commit on master.
@Viv3k Also apologies to you for breaking the build. That commit (entire Pull Request) should not have been merged until after the dependencies were added to the relevant (auto) fetch scripts and included in the source repositories.
Though, without this commit your build should have a broken Chrome/WebViewChrome until it is updated from the Play store (or another browser/webview is used) or com.google.android.trichrome is manually pushed to the system.
@NicholasBuse Tagging you again for support with the crawlers/fetch scripts: what should be done to get TrichromeLibrary added to the source repos and automatically updated?
What needs to get added to the source repo(s)? .APK, .SO? Which repo (all, arm, etc.) what path?
Where would these be crawled from? Currently I'm only running APKMirror and Aptoide reliably. The Playstore crawler needs some work...
@NicholasBuse Thanks for your response. It's just an APK (that contains libmonochrome.so) called com.google.android.trichromelibrary.
- The path is
app/com.google.android.trichromelibrary/29/nodpi/<version>.apk; - The version downloaded from the play store only has an ARM library (but a 64-bit
libdummy.so. Metadata saysnative-code: 'arm64-v8a'andalt-native-code: 'armeabi-v7a'🤔 ); - Unfortunately it's not available on APKMirror nor Aptoide (yet?).
Looks like that playstore crawler needs some dusting off... But not sure I'm up for the task.
I've added the com.google.android.trichromelibrary to the ten branch of the arm64 repo: https://gitlab.opengapps.org/opengapps/arm64/commit/eda39cc41efd1aa27b256b89e4cfc618e1ea57d3
I'm not sure this exists in the Play Store, the only place I found this was the Pixel factory image (and this is the source of this commit's APK). And it's arm64-api29-only from the looks of it.
Thanks @nezorflame !
The trichromelibrary doesn't seem to have a Play page as it's a transparent (to the user) library that gets automatically installed and updated with WebView/Chrome.
I have also retrieved these from the Pixel image.
The latest version that the store will update to is 394507938. Looks like you correctly matched 373018658 against the chrome/webview version on the ten branch, but a merge from master added a newer version 390410838. In my short testing, version clashes cause crashing as well which is unfortunate if there's no stable source to pull these from in sync with Chrome/WebView.
It is indeed only API 29, but I am not sure about the binary format. The apk clearly contains a lib for armeabi-v7a only. Is there still a 32-bit device with Android 10 around where we can confirm this with?
There are multiple devices with Q ports, even the good old Nexus 5.
I'll try to test this before NY.
There are multiple devices with Q ports, even the good old Nexus 5.
I'll try to test this before NY.
I'll look forward to your test then.
I managed to set up an account over at the gitlab instance, but am unable to fork any repository. The goal is to synchronize the version numbers up which need to be identical between Chrome/WebViewChrome/TrichromeLibrary, which otherwise refuse to start. If you provide me access to push a new branch or create a fork I can create a PR to correct this.
I've enabled forks for your account (for some reason they're not enabled
globally, I'll figure it out this month).
Thanks, the update/version-synchronization has been PRed!
I read something a while ago about GitLab not dealing with LFS on forks properly. Though, when I created the repo it said 0MB files, after creating the PR my repo is at 1.5GB. That is likely the result of modifying a branch, with all the LFS objects now duplicated to my fork instead of being borrowed from the parent repo - which will fill up a server quickly if everyone starts creating forks. That said, the shared object/LFS store should be aware of multiple repos depending on those in the event of a prune operation, which they might still be working on.
@nezorflame Just merged the ARM64 MR which means this issue could realistically be closed.
However, the error will still occur on master checkouts for android 9 and below builds until the apks on the ten branch make its way there.
Instead of adding another ugly SDK version guard like I did to fix #238 I was thinking about altering the script to make apks "optional". The AOSP build system receives an empty prebuilt path, about which it should only complain if the surrounding package is added as dependency (eg. GAPPS_PRODUCT_PACKAGES += FaceLock). Let me know if this is desired!
@MarijnS95 I think that'd be fine.
Thanks again for helping us out! Hopefully the ten branch will be merged soon as we publish the Q branches and make builds for 10 official.
We've merged the ten branches on Gitlab, make sure you've also switched back to the master branches.
We've merged the
tenbranches on Gitlab, make sure you've also switched back to themasterbranches.
@nezorflame Awesome, thanks! I'll make sure to submit the changes for "optional" apks (postponing checks until a prebuilt module is depended upon) anyway.
Instead of adding another ugly SDK version guard like I did to fix #238 I was thinking about altering the script to make apks "optional". The AOSP build system receives an empty prebuilt path, about which it should only complain if the surrounding package is added as dependency (eg.
GAPPS_PRODUCT_PACKAGES += FaceLock). Let me know if this is desired!
That was a premature observation; the AOSP build system validates the sources even when the package is never depended upon (which is slightly expected). The only solution would be to prevent calling include $(BUILD_PREBUILT), which will only generate errors on builds that use enforce-product-packages-exist (and the package is subsequently added to PRODUCT_PACKAGES). While possible that sounds like maintenance hell.
TrichromeLibrary made it into master branches anyway, but will likely fail the SDK version match and thus throw this error again regardless. We'll have to come up with something regardless.