search

BasicAirData / GPSLogger

A GPS logger for Android mobile devices
http://www.basicairdata.eu/projects/android/android-gps-logger/
GNU General Public License v3.0
385 stars 121 forks source link

Possibility to release on F Droid? #8

Open stpr-dev opened 7 years ago

stpr-dev commented 7 years ago

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 commented 6 years ago

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

GrazianoCapelli commented 4 years ago

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

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 commented 4 years ago

@rudloff may be able to help with these questions.

Rudloff commented 4 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 7 months ago

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.

2: Task failed with an exception.

3: Task failed with an exception.

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 commented 1 month ago

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 commented 1 month ago

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 https://github.com/greenrobot/EventBus/issues/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 commented 1 month ago

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 commented 2 weeks ago

@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 commented 2 weeks ago

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.