Possibility to release on F Droid?

[stpr-dev]

Hello there!

Your app looks interesting, I would sure like to try it! Would it be possible to release it on F-Droid? It will be very helpful if you can.

[nicolasmaia]

To that end, it's important to know whether this app depends on non-free libraries

[GrazianoCapelli]

Hello there!
GPS Logger only depends on 6 free libraries:

• Android Support v4
• Android Support v7
• Android Support v13
• Android Design Support Library
• Glide
• EventBus

The app doesn't depend on Google’s proprietary “play-services”, it doesn't use proprietary tracking/analytic dependencies, it's ad free, and it does not sign up for any API Keys.
Anyone with a bit of Java knowledge can verify it by looking into the source code.

As a start,
Our App is already included into the IzzyOnDroid F-Droid Repository;
F-Droid users can already install it in a easy way, without any additional work for us.

Anyway,
We are used to publish APKs into Releases section of this GitHub repo.
I read the F-Droid Reproducible Builds Page, and I'm interested to deepen the topic, in order to evaluate with the Team to publish exclusively the (upstream-)developer signed APKs on F-Droid (using the Binaries directive):

1. How can we verify if our APK (for example our Latest Release) could be good for the inclusion?
2. In case, what should we change into our code/settings in order to make it reproducible and pass the verification test?

We would need to have something automatic (like Izzy does) for updates, and to use our original APK, avoiding to have many APKs with different signatures around the Web.
Might it be possible?

[nicolasmaia]

@Rudloff may be able to help with these questions.

[Rudloff]

I tried fdroid scanner on v2.2.4 and it did not found any problem. So I think we can package it easily.
Reproducible builds are a lot more work though (and I am not an expert).

The next step would be to open a RFP: https://gitlab.com/fdroid/rfp/issues/new

[zedxxx]

The next step would be to open a RFP: https://gitlab.com/fdroid/rfp/issues/new

Done: https://gitlab.com/fdroid/rfp/-/issues/1991

[GrazianoCapelli]

Yesterday I fixed the gradle vs wrapper version mismatch and I added the missing distributionSha256Sum for gradle-6.5-bin.zip on develop branch, in order to be aligned in the next incoming v3.1.0 release; thanks for the reporting.

Please publish exclusively the (upstream-)developer signed APKs on F-Droid (using the Binaries directive).
As a note I would like to point out that our app is already included in the IzzyOnDroid F-Droid Repository;

[Poussinou]

F-Droid will publish a self-signed app (with their own keys) because we're building apps from source and signing them afterward.

There is a possibility to publish the developer-signed apk if the build is reproducible, but it can be very complicated...

Maybe @IzzySoft can explain better than me ;)

[IzzySoft]

Please publish exclusively the (upstream-)developer signed APKs on F-Droid

As Poussinou correctly pointed out, that would violate F-Droid's rules. We exclusively publish what we build from code we have checked. This way users can trust the APK they get has what the code promises, no "funny things" added.

If you want your signature on those APKs, there's indeed the way of "reproducible builds" – where the APK you build and the one build by F-Droid, both stripped of their signatures, are binary identical. Tricky to reach, but possible. In that case, when the check succeeds, we take the APK signed by you and add our own on top. You can read more here.

[GrazianoCapelli]

With Gradle 8.0 the app compiles and runs in debug mode, but I have difficulties with lint when I assemble the release.

The process aborts with the following message:

---

Executing tasks: [:app:assembleRelease] in project /home/Graziano/Dropbox/Projects/GPSLogger

Task :app:createReleaseVariantModel UP-TO-DATE
Task :app:preBuild UP-TO-DATE
Task :app:preReleaseBuild UP-TO-DATE
Task :app:generateReleaseBuildConfig UP-TO-DATE
Task :app:javaPreCompileRelease UP-TO-DATE
Task :app:checkReleaseAarMetadata UP-TO-DATE
Task :app:generateReleaseResValues UP-TO-DATE
Task :app:mapReleaseSourceSetPaths UP-TO-DATE
Task :app:generateReleaseResources UP-TO-DATE
Task :app:mergeReleaseResources UP-TO-DATE
Task :app:createReleaseCompatibleScreenManifests
UP-TO-DATE Task :app:extractDeepLinksRelease UP-TO-DATE
Task :app:processReleaseMainManifest UP-TO-DATE
Task :app:processReleaseManifest UP-TO-DATE
Task :app:processReleaseManifestForPackage UP-TO-DATE
Task :app:processReleaseResources UP-TO-DATE
Task :app:compileReleaseJavaWithJavac Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details.
Task :app:rearrangeClass ./build/generated/ap_generated_sources/release/out/eu/basicairdata/graziano/gpslogger/EventBusIndex.java
Task :app:compileSingleFileRelease Task :app:extractProguardFiles UP-TO-DATE
Task :app:lintVitalAnalyzeRelease FAILED
Task :app:mergeReleaseJniLibFolders UP-TO-DATE
Task :app:mergeReleaseNativeLibs NO-SOURCE
Task :app:stripReleaseDebugSymbols NO-SOURCE
Task :app:extractReleaseNativeSymbolTables NO-SOURCE
Task :app:mergeReleaseNativeDebugMetadata NO-SOURCE
Task :app:checkReleaseDuplicateClasses UP-TO-DATE
Task :app:dexBuilderRelease FAILED
Task :app:desugarReleaseFileDependencies UP-TO-DATE
Task :app:mergeExtDexRelease UP-TO-DATE
Task :app:mergeReleaseArtProfile UP-TO-DATE
Task :app:mergeReleaseShaders UP-TO-DATE
Task :app:compileReleaseShaders NO-SOURCE
Task :app:generateReleaseAssets UP-TO-DATE
Task :app:mergeReleaseAssets UP-TO-DATE
Task :app:compressReleaseAssets UP-TO-DATE
Task :app:processReleaseJavaRes FAILED
Task :app:optimizeReleaseResources UP-TO-DATE
Task :app:collectReleaseDependencies UP-TO-DATE
Task :app:sdkReleaseDependencyData UP-TO-DATE
Task :app:validateSigningRelease UP-TO-DATE
Task :app:writeReleaseAppMetadata UP-TO-DATE
Task :app:writeReleaseSigningConfigVersions UP-TO-DATE

FAILURE: Build completed with 3 failures.

1: Task failed with an exception.

• What went wrong: A problem was found with the configuration of task ':app:lintVitalAnalyzeRelease' (type 'AndroidLintAnalysisTask').

  • Gradle detected a problem with the following location: '/home/Graziano/Dropbox/Projects/GPSLogger/app/build/intermediates/javac/release/classes'.

    Reason: Task ':app:lintVitalAnalyzeRelease' uses this output of task ':app:compileSingleFileRelease' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:

    1. Declare task ':app:compileSingleFileRelease' as an input of ':app:lintVitalAnalyzeRelease'.
    2. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:lintVitalAnalyzeRelease' using Task#dependsOn.
    3. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:lintVitalAnalyzeRelease' using Task#mustRunAfter.

    Please refer to https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

• Try:

  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ==============================================================================

2: Task failed with an exception.

• What went wrong: A problem was found with the configuration of task ':app:dexBuilderRelease' (type 'DexArchiveBuilderTask').

  • Gradle detected a problem with the following location: '/home/Graziano/Dropbox/Projects/GPSLogger/app/build/intermediates/javac/release/classes'.

    Reason: Task ':app:dexBuilderRelease' uses this output of task ':app:compileSingleFileRelease' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:

    1. Declare task ':app:compileSingleFileRelease' as an input of ':app:dexBuilderRelease'.
    2. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:dexBuilderRelease' using Task#dependsOn.
    3. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:dexBuilderRelease' using Task#mustRunAfter.

    Please refer to https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

• Try:

  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ==============================================================================

3: Task failed with an exception.

• What went wrong: A problem was found with the configuration of task ':app:processReleaseJavaRes' (type 'ProcessJavaResTask').

  • Gradle detected a problem with the following location: '/home/Graziano/Dropbox/Projects/GPSLogger/app/build/intermediates/javac/release/classes'.

    Reason: Task ':app:processReleaseJavaRes' uses this output of task ':app:compileSingleFileRelease' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:

    1. Declare task ':app:compileSingleFileRelease' as an input of ':app:processReleaseJavaRes'.
    2. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:processReleaseJavaRes' using Task#dependsOn.
    3. Declare an explicit dependency on ':app:compileSingleFileRelease' from ':app:processReleaseJavaRes' using Task#mustRunAfter.

    Please refer to https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

• Try:

  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ==============================================================================

• Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/8.0/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 820ms 34 actionable tasks: 6 executed, 28 up-to-date

---

If I remove the script the 3 errors are gone.

Some users on Stack Overflow suggested to disable the new lint checks; I think that it is not a solution, but I tried it and the error was still present.

I tried to read some documentation in order to figure out how to solve the problem but no way, I have no idea how to apply the tips that gradle suggested.

Someone can help me?
In the meantime I must revert the changes and wait that EventBus solves its problem.

[IzzySoft]

I can successfully build the app from the latest release by just running ./gradlew assembleRelease, but it isn't reproducible:

-------------------------------
--- /dev/fd/63  2024-07-09 00:38:46.810923997 +0200
+++ /dev/fd/62  2024-07-09 00:38:46.814923968 +0200
@@ -1,11 +1,11 @@
   META-INF/com/android/build/gradle/app-metadata.properties
   32-bit CRC value (hex):                         17782998
   assets/dexopt/baseline.prof
-  32-bit CRC value (hex):                         a5745cd8
+  32-bit CRC value (hex):                         b643c58a
   assets/dexopt/baseline.profm
   32-bit CRC value (hex):                         9fcd5fa2
   classes.dex
-  32-bit CRC value (hex):                         29ffa4c0
+  32-bit CRC value (hex):                         1a17c4f1
   DebugProbesKt.bin
   32-bit CRC value (hex):                         e5f78a88
   META-INF/androidx.activity_activity-ktx.version
@@ -2076,9 +2076,3 @@
   32-bit CRC value (hex):                         01957c93
   resources.arsc
   32-bit CRC value (hex):                         bd72299e

classes.dex differs quite a lot. Was the APK really built from the commit the tag points to? If not, from which? Please always build from a clean tree of where the tag points to. For additional hints, please see our hints on reproducible builds.

Thanks in advance for helping with RB!

[GrazianoCapelli]

Unfortunately I know that GPS Logger is not reproducible.
I tried to find the reason using the diffoscope, and I found that the non-reproducible part is the generation of EventBus EventBusIndex.class made by EventBus during every build phase.
I opened the issue greenrobot/EventBus#715 in order to help to fix it, and to date I'm waiting the EventBus developers.

Some time ago I tried a patch suggested from the F-Droid apps merge request. The build was reproducible, but I found difficulties to assembly the release due to the new gradle checks.
Some weeks ago they wrote me how to address the additional issue, but I I'm having no time to work on it. I planned to release an app update before the end of August, including the patch suggested: starting by the next update the app should be reproducible.

[IzzySoft]

Thanks a lot! If you could give me a ping when that release is ready, I'd retry the RB at IzzyOnDroid and let you know (expecting my feedback to be faster, but no guarantees for that).

[GrazianoCapelli]

@IzzySoft I applied the patch including the 3 lines suggested by linsui (commit 25ee867, into the issue-8 branch) and Android Studio generates the release signed APK successfully. It seems to work.

BUT

If I create the signed APK, then I clean the project (Build -> Clean Project) and I try to create a second signed APK to check the differences, the second time the command returns a python error. I must restart Android Studio to generate another APK.
Maybe the problem is in some python variable of the suggested patch...

Thus at this time I prefer to stay still and don't add any patch to the develop code.

[IzzySoft]

I've never used Android Studio and thus cannot tell. We're using rbtlog to build, which uses containers. Those are "clean" by default as they are abandoned at the end of the process, so each build starts "virgin". rbtlog can also be used to just build, not only to check for RB.