A F/LOSS Build?
Closed this issue · 10 comments
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
I don't have the plan for a third build variant, and the best I can do would be uploading the F-Droid build to GitHub as a sign of my trust in them.
I don't have the plan for a third build variant, and the best I can do would be uploading the F-Droid build to GitHub as a sign of my trust in them.
I understand that. Okay, that would be great!
Done, I've uploaded app-release-fdroid.apk to latest release. Please feel free to comment on this issue in the future in case I missed uploading it for a future release, because it can be easily forgotten due to the delay in F-Droid build.
Done, I've uploaded
app-release-fdroid.apkto latest release. Please feel free to comment on this issue in the future in case I missed uploading it for a future release, because it can be easily forgotten due to the delay in F-Droid build.
Thank you so much! Okay, I will! I understand that, of course.
the best I can do would be uploading the F-Droid build to GitHub as a sign of my trust in them.
That makes not much sense, sorry. That's the version built and signed by F-Droid, not by you. And it would mean waiting until F-Droid has built it, then you uploading it to Github, and then the IoD updater downloading it again – so you'd have to wait a week or more from the time you make a release until it becomes available at IzzyOnDroid.
In that case it would be more useful if you could took a look at the F-Droid build recipe and add that to your Github workflow as separate build – would be much faster, and also automated then.
- versionName: 1.7.4
versionCode: 39
commit: 61a3cffede303d159ee9ad805319b89c21c3aa04
subdir: app
gradle:
- yes
rm:
- app/src/main/java/me/zhanghai/android/files/nonfree
prebuild: find -type f -exec sed -i '/\/\/#ifdef NONFREE/,/\/\/#endif/d' {} +
ndk: 26.3.11579264That's from F-Droid's recipe. So for your workflow, you'd basically copy the current build block (e.g. to a copy named build-foss), and add two steps there before "Build with gradle":
rm -rf app/src/main/java/me/zhanghai/android/files/nonfreefind -type f -exec sed -i '/\/\/#ifdef NONFREE/,/\/\/#endif/d' {} +
That should then result in the same APK as F-Droid builds, just signed by you – and available much earlier. Of course, setting up a F/LOSS build flavor would be the cleaner variant – but that seems to work as well (or F-Droid wouldn't ship a working APK).
Oh, of course you should have it assembleRelease then, and sign it 😉 I guess the release is not build via CI here? I see no reference to that in the workflow.
Thanks for replying - I do know how to do that, but I didn't want to do that so that I don't need to worry about yet another release variant (and R8 mapping etc). If the F-Droid build doesn't comply with the inclusion requirement for IzzyOnAndroid I think I'll just stay out of it for now.
@zhanghai I think it's less work to implement it this way than to have manually check when F-Droid's builds are ready and transfer them over. And it's faster, too (as you don't have to wait for F-Droid's build cycle). And if you'd establish it as a proper build flavor, it wouldn't even require a separate build run but the additional APK would be generated in the same build. But it's of course your decision.
So is this a final "no" then, or would you consider?
I would love to see that too!
Sorry, an extra build maintained by myself is at least a No for now.
Okay, but it would make the work for you and everyone much easier!