F-Droid adjustments
IzzySoft opened this issue · 10 comments
As this is neither a bug nor a feature request, I hope you forgive me removing the template.
IIRC you've applied for F-Droid inclusion. For the UpdateChecker to work, it would need literal values for versionCode and versionName – as the checker only performs RegEx-matching on the build.gradle. Could that be accomplished?
And while being here: is there any reason for the heavy obfuscation (proguard I guess)? This being FOSS, transparency would be preferred. The code is open anyway, so no need to obfuscate, right? 😉
Hey @IzzySoft do not worry about the template, it would've complicated things in this case.
First, let me thank you for accepting my app in your repo, much appreciated! I get what you're saying about the version and there's no problem fixing it. It was over complicated anyway. As for the obfuscation, I enabled proguard to reduce app size as much as possible, but didn't think of obfuscation. This is my first time working with Gradle and Android Studio, so I'm a bit inexperienced, but I totally agree with you about the transparency. So, I added -dontobfuscate to the proguard rules, I hope that's enough. The apk is now ~300kb bigger but I can live with that.
I'm pushing these changes to master, let me know if versionCode and versionName are good for the UpdateChecker. I can also publish a new release with these changes if necessary.
do not worry about the template, it would've complicated things in this case.
That was my thinking – glad you agree 😃
thank you for accepting my app in your repo
Gladly! I'm a big fan of Nextcloud myself (though for password management I use KeepassXC).
I enabled proguard to reduce app size as much as possible, but didn't think of obfuscation.
Yupp, thought so. And of course minify is a good choice, kicking out unused code parts (what's not there cannot cause bugs, security issues etc). What I find a bit confusing is how obfuscation should save those other 300k. A few bytes here and there because of the "name shortening", OK, but 300k? Strange. But yeah, that's a compromise. If you want me to check the resulting APK with my scanner let me know; otherwise you'll see the difference in the library sectioon of the next version 😉
let me know if versionCode and versionName are good for the UpdateChecker
Yes, they look fine now, thanks!
I can also publish a new release with these changes if necessary.
I don't know what stage you are at with F-Droid currently. If you're going for the merge request, we'd need the changes tagged (you could e.g. go for a 2.0.1). As soon as you do (and attach the corresponding APK), my updater would fetch it within 24h and my library scanner would tell us if you succeeded with Proguard.
A few bytes here and there because of the "name shortening", OK, but 300k? Strange.
Yep, that's what I thought too, and I have no clue why is that.
If you want me to check the resulting APK with my scanner let me know
I would appreciate it actually, just to know if it's something I can fix (and, maybe, if I can reduce the size without obfuscation). However, I wouldn't want to waste your time. So, if it's not a hassle to you, I would share the signed APK of the new version here before creating a new GitHub release.
Feel free to do so! OTOH, my library scanner is FOSS, too, so also feel free to grab it to give it a try yourself. You can find it here (for the full-fledged version) – or here for a simple variant made for CI integration at F-Droid (see comment at the top of the file for requirements (1 line) and an example call (second line)). This might be the best approach if you want to have multiple runs to try 😉
my library scanner is FOSS, too, so also feel free to grab it to give it a try yourself
That's cool, thank you! I will surely use it from now on.
In the meantime, I thought I could upload APKs directly here in comments but I can't, so this is a share link to my Nextcloud server: https://nx17597.your-storageshare.de/s/B4FXZf2ATkrJDHZ . Inside it, you'll find two APKs: one obfuscated, the other not. Apart from that, they're identical. Check them out whenever you please and let me know if you find something wrong.
Obfuscated:
Libraries detected:
-------------------
* Android Support v4 (/android/support/v4): Development Framework
* AppCompat (/androidx/appcompat): Utility
* Biometric (/androidx/biometric): Utility
* Jetpack Compose (/androidx/compose): Development Framework
* Constraint Layout Library (/androidx/constraintlayout): Utility
* Androidx Core (/androidx/core): Utility
* Lifecycle (/androidx/lifecycle): Utility
* Navigation (/androidx/navigation): Utility
* Google Material Design (/com/google/android/material): Utility
* Ktor (/io/ktor): Development Framework
* kotlinx.coroutines (/kotlinx/coroutines): Utility
* Kotlin serialization (/kotlinx/serialization): Utility
No offending libs found.
Not obfuscated:
Libraries detected:
-------------------
* Android Support v4 (/android/support/v4): Development Framework
* Arch (/androidx/arch): Utility
* AppCompat (/androidx/appcompat): Utility
* Biometric (/androidx/biometric): Utility
* Jetpack Compose (/androidx/compose): Development Framework
* Constraint Layout Library (/androidx/constraintlayout): Utility
* Androidx Core (/androidx/core): Utility
* Lifecycle (/androidx/lifecycle): Utility
* Loader (/androidx/loader): Utility
* Navigation (/androidx/navigation): Utility
* Transition (/androidx/transition): UI Component
* Vectordrawable (/androidx/vectordrawable): UI Component
* Accompanist (/com/google/accompanist): Utility
* Google Material Design (/com/google/android/material): Utility
* Ktor (/io/ktor): Development Framework
* Kotlin (/kotlin): Utility
* kotlinx.coroutines (/kotlinx/coroutines): Utility
* Kotlin serialization (/kotlinx/serialization): Utility
* Simple Logging Facade for Java (/org/slf4j): Utility
No offending libs found.
So funny to see which libs get obfuscated: Arch, Loader, Transition, Vectordrawable, Accompanist, Kotlin, SLF4J. Most of them either AndroidX or KotlinX components. Now idea why.
It's funny indeed. I never thought obfuscation could lead to this. Even Accompanist, which is used directly in my code, is not even detected when obfuscation is enabled. I think I'll look for more details on this one, seems interesting. Thank you for the help.
Anyway, a 300kb increase is not the end of the world, and I support transparency. I'm gonna publish the not obfuscated 2.0.1 release tomorrow morning. There shouldn't be issues with your UpdateChecker but, if any, let me know. Feel free to close here.
Thanks a lot! And yes, I feel transparency an important part of establishing trust – especially if it's not an independent party (like F-Droid) running the builds. Seeing obfuscation in an app always leaves at least a touch of doubt of what should be hidden there.
I'll wait for tomorrow's update and then cross-check with the full Apktool output my updater saves (above I just ran the "simple mode" which abandons the output automatically after having gathered results – the updater keeps it for a second run checking for new libraries yet unknown to the scanner), then will report back here and close if all is fine (which I expect it will be).
Thanks again for your great support, Nicolas!
Well, the new release is live. Can't wait for the response!
Not a single obfuscation left (and no unknown libs, if we do not count the AndroidX components I did not yet configure separately). So all fine: mission accomplished, closing the solved issue. Thanks once more!