A F/LOSS Build?

[ghost]

Hey,

would you be open to provide a F/LOSS build flavor (basically with the modifications done by F-Droid) and provide that APK alongside your current ones at Github? Because then IzzyOnDroid Repo from F-Droid could add it to their Repo. Because I and many Users don't trust the Main F-Droid Repo and this way, we would have the best solution for everyone. Because IzzyOnDroid Repo always checks the Apps, which would be more secure. Look here: https://android.izzysoft.de/articles/named/iod-scan-apkchecks?lang=en

[IzzySoft]

I've tried to build the foss flavor (using ./gradlew assembleFossRelease) from the latest tag (2.5.0), but the build failed:

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache state could not be cached: field `importDirs` of task `:app:compileFossReleaseAidl` of type `com.android.build.gradle.tasks.AidlCompile`: error writing value of type 'org.gradle.api.internal.artifacts.configurations.Re
> Could not resolve all files for configuration ':app:fossReleaseCompileClasspath'.
   > Could not find com.github.AppDevNext:AndroidChart:3.1.0.24.
     Required by:
         project :app

Looks like it could not find com.github.AppDevNext:AndroidChart, though that should be at Jitpack.io. Do you have any clue why that fails?

Background: OP asked to have your app included with IzzyOnDroid, and I tried to set up checks for Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Any help is appreciated!

@PrivacyAndSecurity the foss flavor is F/LOSS here. The AppCenter code used there is a "stub" (an empty shell not doing anything, just providing the same interfaces). I hope that will stay the same when the app moves to Firebase…

[ghost]

I've tried to build the foss flavor (using ./gradlew assembleFossRelease) from the latest tag (2.5.0), but the build failed:

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache state could not be cached: field `importDirs` of task `:app:compileFossReleaseAidl` of type `com.android.build.gradle.tasks.AidlCompile`: error writing value of type 'org.gradle.api.internal.artifacts.configurations.Re
> Could not resolve all files for configuration ':app:fossReleaseCompileClasspath'.
   > Could not find com.github.AppDevNext:AndroidChart:3.1.0.24.
     Required by:
         project :app

Looks like it could not find com.github.AppDevNext:AndroidChart, though that should be at Jitpack.io. Do you have any clue why that fails?

Background: OP asked to have your app included with IzzyOnDroid, and I tried to set up checks for Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Any help is appreciated!

@PrivacyAndSecurity the foss flavor is F/LOSS here. The AppCenter code used there is a "stub" (an empty shell not doing anything, just providing the same interfaces). I hope that will stay the same when the app moves to Firebase…

I hope so too!

[zhaobozhen]

In fact, I've made the FOSS version of the build product available on the Release page.

See: https://github.com/LibChecker/LibChecker/releases/download/2.5.0/LibChecker-2.5.0.89b31e95-2159-foss-release.apk

Similarly, FOSS products are provided with each CI release.

https://github.com/LibChecker/LibChecker/actions/workflows/android.yml

You are free to download it if you wish.

[zhaobozhen]

I hope that will stay the same when the app moves to Firebase…

Surely I will.

[IzzySoft]

Ah, how could I have missed the workflow? Or maybe I missed at least some details (I was running with JDK-17, while the workflow specifies 21 – though it would surprise me if that caused missing a dependency – and yeah, as expected, with 21 build fails with the very same message). Now I just need to figure out what the Github specific variables mean in "plain git", e.g. what does github.event.head_commit.id resolve to, and thus what does VERSION=$(echo ${{ github.event.head_commit.id }} contain? My builder doesn't run in a Github environment.

Btw: the workflow has

    run: ./gradlew -PappVerName=${{ env.VERSION }} app:assembleRelease

I've searched the entire repo for appVerName – that's the only place that came up, so I wonder what gradle is supposed to do with it. Well, I'm no Android dev, so maybe I miss something; but usually -P provides parameters one evaluates in build.gradle, no?

I've made the FOSS version of the build product available on the Release page.

Thanks – that's where the IzzyOnDroid update checker looks for them, and where I took the APK from. My build question rather concerns reproducible builds, as outlined above – which when successful, prove your APK was really built from the source it claims, and thus is another security layer.

[zhaobozhen]

Ah, how could I have missed the workflow? Or maybe I missed at least some details (I was running with JDK-17, while the workflow specifies 21 – though it would surprise me if that caused missing a dependency – and yeah, as expected, with 21 build fails with the very same message). Now I just need to figure out what the Github specific variables mean in "plain git", e.g. what does github.event.head_commit.id resolve to, and thus what does VERSION=$(echo ${{ github.event.head_commit.id }} contain? My builder doesn't run in a Github environment.

Btw: the workflow has

    run: ./gradlew -PappVerName=${{ env.VERSION }} app:assembleRelease

I've searched the entire repo for appVerName – that's the only place that came up, so I wonder what gradle is supposed to do with it. Well, I'm no Android dev, so maybe I miss something; but usually -P provides parameters one evaluates in build.gradle, no?

I've made the FOSS version of the build product available on the Release page.

Thanks – that's where the IzzyOnDroid update checker looks for them, and where I took the APK from. My build question rather concerns reproducible builds, as outlined above – which when successful, prove your APK was really built from the source it claims, and thus is another security layer.

This parameter is used by me for debugging in my own environment, you can compile it directly with the following command.

run: ./gradlew app:assembleRelease

[IzzySoft]

That's exactly what I did: checking out the repo, changing into it's root, making sure gradlew is executable, run ./gradlew app:assembleFossRelease (as I want the foss flavor defined here). And with that I get above build failure (Ubuntu jammy, JDK-21, in a clean Podman container – in case it matters; we use rbtlog here to verify if an app build is reproducible).

[zhaobozhen]

That's exactly what I did: checking out the repo, changing into it's root, making sure gradlew is executable, run ./gradlew app:assembleFossRelease (as I want the foss flavor defined here). And with that I get above build failure (Ubuntu jammy, JDK-21, in a clean Podman container – in case it matters; we use rbtlog here to verify if an app build is reproducible).

I finally found the reason. https://jitpack.io/#com.github.AppDevNext/AndroidChart
It seems that version 3.1.0.24 was built failed. So gradle can't download this dependency correctly.

I have triggered re-building this version. Now it should works.

[IzzySoft]

Thanks! Builds now, but the resulting APK is not identical to yours. Seems you somewhere insert buildtime:

 |: if-eqz v2, 009b // +0016
-|: const-string v2, "2024-09-04T12:30:42.417658Z"
+|: const-string v2, "2024-12-05T09:16:28.257540054Z"
 |: filled-new-array {v2}, [Ljava/lang/Object;

Most likely here. That is non-deterministic and will differ on each build. Is that really needed? If you'd remove that, the app would be RB:

build:
  - sed -r 's/Instant.now\(\).toString\(\)/"2024-09-04T12:30:42.417658Z"/' -i build-logic/src/main/kotlin/Projects.kt
  - chmod +x gradlew
  - ./gradlew :app:assembleFossRelease

(the sed replaces your dynamic build timestamp with the one the diff showed to be in your APK – but that would need manual adjustments for each new release, after having the RB fail so we can diff it, as only then we'd know what build time was placed there). With that adjustment:

    "upstream_signed_apk_sha256": "5416c92f350842ad014bdf670053282292bc59e9a4b8baa7692c2af6e86bfd51",
    "built_unsigned_apk_sha256": "60394dfd816dac010e70448a64e775e5635c5929338c4e8733b7a0b34c1d4d6c",
    "signature_copied_apk_sha256": "5416c92f350842ad014bdf670053282292bc59e9a4b8baa7692c2af6e86bfd51"

You see the first and the last hash (your APK, ours with the signature copied from yours) are identical then.

So may I kindly ask you to not insert that dynamic timestamp with future releases? Thanks in advance!

[IzzySoft]

Oh, PS: you also might wish to pick a badge to add to the other two in your Readme and link it to your app at IzzyOnDroid 😃 The green shield for a successful RB is already up (in the hope you'll grant my above wish).

[zhaobozhen]

Thanks! Builds now, but the resulting APK is not identical to yours. Seems you somewhere insert buildtime:

 |: if-eqz v2, 009b // +0016
-|: const-string v2, "2024-09-04T12:30:42.417658Z"
+|: const-string v2, "2024-12-05T09:16:28.257540054Z"
 |: filled-new-array {v2}, [Ljava/lang/Object;

Most likely here. That is non-deterministic and will differ on each build. Is that really needed? If you'd remove that, the app would be RB:

build:
  - sed -r 's/Instant.now\(\).toString\(\)/"2024-09-04T12:30:42.417658Z"/' -i build-logic/src/main/kotlin/Projects.kt
  - chmod +x gradlew
  - ./gradlew :app:assembleFossRelease

(the sed replaces your dynamic build timestamp with the one the diff showed to be in your APK – but that would need manual adjustments for each new release, after having the RB fail so we can diff it, as only then we'd know what build time was placed there). With that adjustment:

    "upstream_signed_apk_sha256": "5416c92f350842ad014bdf670053282292bc59e9a4b8baa7692c2af6e86bfd51",
    "built_unsigned_apk_sha256": "60394dfd816dac010e70448a64e775e5635c5929338c4e8733b7a0b34c1d4d6c",
    "signature_copied_apk_sha256": "5416c92f350842ad014bdf670053282292bc59e9a4b8baa7692c2af6e86bfd51"

You see the first and the last hash (your APK, ours with the signature copied from yours) are identical then.

So may I kindly ask you to not insert that dynamic timestamp with future releases? Thanks in advance!

Hey, I have removed the dynamic build time logic in this commit 452d3b8. This issue will not happen in the future releases.

Oh, PS: you also might wish to pick a badge to add to the other two in your Readme and link it to your app at IzzyOnDroid 😃 The green shield for a successful RB is already up (in the hope you'll grant my above wish).

Yes, I would be happy to add the badge. However, I noticed that the padding value of the image provided in the repository is different from the other badges. This makes the page layout look less visually appealing. Could you kindly provide an additional version of the badge with padding values matching the other two badges?

[IzzySoft]

Hey, I have removed the dynamic build time logic in this commit 452d3b8.

sure? It's still there, even at HEAD.

I noticed that the padding value of the image provided in the repository is different from the other badges.

There's more than one. Your screenshot shows the one without padding. From the assets directory:

So you might wish to take the first one? It should match the padding of the other two.

[zhaobozhen]

Hey, I have removed the dynamic build time logic in this commit 452d3b8.

sure? It's still there, even at HEAD.

I noticed that the padding value of the image provided in the repository is different from the other badges.

There's more than one. Your screenshot shows the one without padding. From the assets directory:

So you might wish to take the first one? It should match the padding of the other two.

Yes, the first one is perfect! Thanks!

[IzzySoft]

Great! Thanks for including it! And can you please make sure that build time insertion was not just forgotten to commit/push? The change was not part of the linked commit at least, and the line still exists in Projects.kt.

[zhaobozhen]

Great! Thanks for including it! And can you please make sure that build time insertion was not just forgotten to commit/push? The change was not part of the linked commit at least, and the line still exists in Projects.kt.

I forgot it. I will remove it in the future.

[IzzySoft]

Thanks! Please do so before the next release 😉