Build for v4.0.3 fails

[IzzySoft]

v4.0.3 cannot be built from source anymore:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeFossReleaseNativeLibs'.
> Could not resolve all files for configuration ':app:fossReleaseRuntimeClasspath'.
   > Could not resolve uk.co.jordanrobinson:android-color-picker:1.0.2.
     Required by:
         project :app
      > Could not resolve uk.co.jordanrobinson:android-color-picker:1.0.2.
         > Could not get resource 'https://artifactory.appodeal.com/appodeal-public/uk/co/jordanrobinson/android-color-picker/1.0.2/android-color-picker-1.0.2.pom'.
            > Could not GET 'https://artifactory.appodeal.com/appodeal-public/uk/co/jordanrobinson/android-color-picker/1.0.2/android-color-picker-1.0.2.pom'.
               > artifactory.appodeal.com: Name or service not known

Reason is that appodeal.com is in at least one blacklist (AdAway & StevenBlack – probably even more) and thus cannot be resolved from a server inside a "protected network" using such blacklists on DNS level for good reasons (protection).

You have their maven configured in your build.gradle; maybe that package is available from a trusted maven repo as well – or can be used via its git repo directly?

[IzzySoft]

OK, managed to get appodeal.com out of the DNS server's filter list temporary, and the app built fine – Reproducible Builds confirmed again (for some background, please see: Reproducible Builds, special client support and more at IzzyOnDroid).

Scanners however reported:

! repo/org.juanro.autumandu_403.apk declares sensitive permission(s):
  android.permission.READ_EXTERNAL_STORAGE android.permission.MANAGE_EXTERNAL_STORAGE
! repo/org.juanro.autumandu_403.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Could you please clarify what the storage permissions are needed for? As for DEPENDENCY_INFO_BLOCK, that can easily be avoided by a minor addition to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Thanks in advance!

[juanro49]

Hello!

Regarding the uk.co.jordanrobinson:android-color-picker:1.0.2 dependency that is in appodeal, I had to add it because that artifact was only in JCenter, which closed and is no longer available https://mvnrepository.com/artifact/uk.co.jordanrobinson/android-color-picker. I was looking in other artifact repositories and saw that it was available from https://artifactory.appodeal.com/appodeal-public/uk/co/jordanrobinson/android-color-picker/ and http://maven.wafour.com:8081/artifactory/libs-release/uk/co/jordanrobinson/android-color-picker/, I decided to add the first one. I think I could get it from https://jitpack.io/#jordanrobinson/android-color-picker, I would have to test.

As for the storage permission, it is used to be able to backup the database and the user can choose the path where to save the backups, being able to choose also the external storage of an SD card. I will take into account the suggestion of DEPENDENCY_INFO_BLOCK 😊

[IzzySoft]

I had to add it because that artifact was only in JCenter

Yeah, thought so. Closure of JCenter caused quite a mess with many apps (also here). I've searched as well and could not find a "suitable Maven repo". AppoDeal has the disadvantage of being an Ad company, which makes it a first-class candidate for block lists. Haven't heard of wafour.com before, so no idea what that might be. Jitpack would be great indeed, that's a "trusted name" in the Maven world.

Thanks for considering that! For now I know how to work around the block, but that would mean a failed build plus manual work on each release (I did it this time to make sure it's the only culprit, luckily it was).

Storage: if it's just a single directory, would SAF cover that without a permission – or is there something "blocking" that option? Just asking, if you say it's needed this way I'd add it to the app's "green list". I'm just always looking for "improvements of privacy" options 😉

I will take into account the suggestion of DEPENDENCY_INFO_BLOCK

Thanks! If you have concerns regarding PlayStore, we mostly care about the APK – so in that case, disabling it for the APK but leaving it active for the bundle would be OK already.

[juanro49]

I've tried jitpack, but all the builds it does give an error https://jitpack.io/#jordanrobinson/android-color-picker. I found this other repository, it should be more reliable https://archiva.haynespro.com/artifactory/repo/uk/co/jordanrobinson/android-color-picker/

As for storage, I currently use SAF to select the directory to backup to, but removing the permission and using SAF to backup as well would make the automatic periodic backup option not work.

I don't publish apps to the PlayStore, so I'm not worried about that. 😁

[IzzySoft]

I've tried jitpack, but all the builds it does give an error jitpack.io/#jordanrobinson/android-color-picker.

Looking at the logs:

Gradle version 2.2 is required. Current version is 6.7.1. If using the gradle wrapper, try editing the distributionUrl in /home/jitpack/build/gradle/wrapper/gradle-wrapper.properties to gradle-2.2-all.zip

WTF? 2.2 is ancient. Even 6.7.1 is old. But you're not alone, someone already filed an issue for that 2 weeks ago (no reply yet). Funnily, that's the only thing I found, so it cannot be a "generic" error. Still strange… But that SNAPSHOT succeeded? Oof…

I found this other repository, it should be more reliable

We'll find out I guess (the IP at least resolves fine here currently). Alternatively, you could also include that picker as a git submodule, and use gradlew publishToLocalMaven during build.

but removing the permission and using SAF to backup as well would make the automatic periodic backup option not work

Well, then it's "needed for the automatic periodic backup option" I'd say.Done, added it to the app's green list with that reason.

I don't publish apps to the PlayStore, so I'm not worried about that. 😁

Great! And full ack to that choice (I've cut my ties to that about 10 years ago).

So shall we leave the issue open until the next release then, to see if the build here runs smooth then? Should you decide for the localMaven, please let me know as then I'd need to adjust the build recipe here.