build fails due to missing resources #84
Comments
|
Likely the buildsystem is somewhat borked. Very likely in fact. I did not do a "from scratch" build in ages. I really really should get my build system in order ... 👀 Anyway, one problem is are the "non-free images" I am using from https://www.flaticon.com/ . I cannot add them to this repo according to their license. Therefore, one integral part of getting everything up and running is to get an API key from them so that the builder can download the resources required. I kind of find this important to address and I am feeling down about the Google app store rejecting my breast icons all of a sudden, so you are in luck: I will try to fix this now! |
That will make reproducible builds (see Reproducible Builds, special client support and more at IzzyOnDroid – your app is listed there) impossible then, as builders wouldn't sign up for API keys. Maybe a better approach would be finding free replacements, e.g. at svgrepo.com (those are mostly licensed CC0 as far as I could see)?
I didn't think I'd say "thank you, Google" one day and not meaning it as sarcasm 🤣 So I'll add a "Thank you, Paul" if you don't mind 😉 |
That is very much true. When I created the app, I kind of realized that this was the only non-free aspect of it. On the other hand, I had to realize that creating my own icons or scraping open sources was very time intensive and just did not yield the same quality of results. Flaticon, even though it is non-free has a solid and appealing selection of icons and therefore saved me a lot of time making this app exist in the first place. That said, for the builds, I am planning on creating a separate "source" for images based on a filler-texture. Then I can do full builds but I do not need to hook flaticon/freepik in the build system. This then opens up the possibility for alternative icon packs. Alternative icon packs, however, have their own rats tail attached to them. svgrepo.com seems to be a pretty nice source, but requires CC attributions. Not a problem per-se, just a lot of work. So, getting alternative icon packs, or replacing the current one to get rid of the freepik-license would probably need to become its own issue. There is also a completely different solution on the horizon that I discovered yesterday: The freepik api has changed once again, and it seems that the icon-downloads themselves are no longer hidden behind a api-key. This would be great: The images themselves are still protected by the freepik license itself (meh for an open source project, I know), but at the same time no API-key is needed for downloading them. I can actually investigate that solution before replacing the entire pictogram library. |
And that way, also opens a way to get rid of the NonFreeAssets anti-feature: the app itself could include a libre icon pack – which then can optionally replaced via manual download (on-demand from within the app, or simply by placing them into a specified/configurable location). Feeding three birds with one basket, so to say: no problematic build dependency, the AF dropped, and more flexibility/customization. I'd like that approach 😉
I was just browsing it yesterday as we need some icons "refreshed" here. All the icons I took a closer look at were licensed CC0 (aka "public domain"). Why would those require attribution? Of course YMMV, as other icons might use other licenses – I didn't check all 500k of their collection.
That sounds like a possibility as well – if a "central attribution" (like "icons are ⓒ xxx by freepik") suffices. Though that might still require NonFreeAssets then. For dropping that AF, the "multiple icon packs" approach would be the better fit. But yeah, both would work. |
The process installed NDK v.26.1.10909125 "Side by side". Any dependency I miss? OK, convert resources/help_images/screenshots/help_diaper_logging.png -crop "+0+170" -crop "-0-135" app/src/main/res/drawable/help_diaper_logging.pngI doubt that is deterministic (converting images rarely is, so better use the "final ones" directly). And if it's not, it will make Reproducible Builds impossible (which is the reason I try to build the app myself, see Reproducible Builds, special client support and more at IzzyOnDroid). Ah, and then So at this point, build crashes with And I haven't yet installed what I dug up from the So simply running extra_packages:
- make
- imagemagick
- python3
- pipenv
- python3-urllib3What build process would you advise then? In case it matters: the pod for building your app is using ubuntu:jammy here, with OpenJDK-21. |
|
Hey! Sorry, I got very ill since yesterday. One very quick pointer: https://github.com/babybuddy/babybuddy-for-android/blob/6588135e445aaf8fb3a4b516089b7030c43c1d83/README.md I updated the readme with the required packages list, had to determine the list myself again. I am still running all of this on ubuntu 22.04.5, but annoyingly, some of the Android features rely on JDK 18, not 21, so a custom JDK is required. Rest needs to wait until I am healthy again. |
Oof. That will make it unfit for RB then. We only support long-term JDKs (11, 17, 21 currently – with 17 being the default for now). Features being dropped with later releases are one of the reasons to not use such interim-JDKs for "production". Do you see any chance getting rid of that "unstable dependency", making the app build fine with 21 directly (i.e. not requiring JDK-18)? |
which btw also tells you why you should not rely on such in-between versions but rather use LTS releases (currently 11, 17, 21) as reference for what features to use. Features introduced by those "experimental" JDKs might be dropped again once the next LTS is released… |
|
Quick update from my side: I have recovered already and I did not forget about this. I tried to update to JDK 21, but I cannot get the builds to work. There seems to be "some weirdness" with how Android handles the JDK versions: https://developer.android.com/build/jdks . Took me some time to find this, I dug myself to that page via the gradle-docs, which was very convoluted. As you correctly point out, Version 11 or 17 are the ones I should be going for. I hope that this will work, will test it over the next few days! |
|
Best luck! 🤞 Btw, JDK-11 is quite old. Please try 17 first if 21 doesn't work for you. |
|
JDK 17 it is, #85 is merged. I think at least parts (huge parts) of your issues should have been addressed. Please check the software list on https://github.com/babybuddy/babybuddy-for-android?tab=readme-ov-file#build-instructions, or alternatively the I am not 100% sure if I can support 100% reproducible builds, I do not know the android toolchain well enough for that. |
|
Thanks, on it now. Seems your check script needs an update: it's OK, so thanks to that check script I was able to complete most dependencies. Going by my assumption that gradle takes care for the rest, I now comment it out to see if the build works. So yes, it does (also Android SDK for targetSdk 35) – but build fails: What might be missing there? Here's my recipe: ---
repository: https://github.com/babybuddy/babybuddy-for-android.git
updates: releases
notes:
- using ubuntu:noble due to the cython3 version required
versions:
- tag: v2.4.3
apks:
- apk_pattern: babybuddy-for-android-.*\.apk
apk_url: https://github.com/babybuddy/babybuddy-for-android/releases/download/$$TAG$$/babybuddy-for-android-$$TAG$$.apk
build:
- export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
- echo bash check-build-prerequisites.sh
- ./gradlew assembleRelease -PskipIntegrationTests
- find . -name '*.apk'
- mv app/build/outputs/apk/release/*unsigned.apk /outputs/unsigned.apk
build_home_dir: /build
build_repo_dir: /build/repo
build_user: build
provisioning:
android_home: /opt/sdk
build_tools:
cmake:
cmdline_tools:
version: '12.0'
url: https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip
sha256: 2d2d50857e4eb553af5a6dc3ad507a17adf43d115264b1afc116f95c92e5e258
extra_packages:
- python3
- cython3
- pipenv
- pandoc
- make
- gcc
- g++
- curl
- imagemagick
- jq
image: ubuntu:noble
jdk: openjdk-17-jdk-headless
ndk:
platform:
platform_tools:
tools:
verify_gradle_wrapper: trueBesides: it's a bad idea to convert images during build, that's almost sure to make RB fail (image conversion/compression usually is not deterministic), so better provide the "ready-to-use" images in the repo directly. |
|
I've just tried v2.5.0 now. Build failed with: As it requires a lot of believe to think a build involving images created on-the-fly with All the best for your project nevertheless! |
Trying to build the app using
./gradlew assembleReleaseon Debian bookworm with JDK 17 fails, as some resources seem to be missing:Could it be you forgot to check those in to this repo?
The text was updated successfully, but these errors were encountered: