Closed IzzySoft closed 11 months ago
No answer, @stud0709 ? Yesterday's release has the very same issues. So I've had to remove your app for now. As the inclusion criteria say: Those things are no-gos with security apps. Additionally, the APK size is beyond the size limit as well since v0.23 (probably because of that even). Sorry for that. Please let me know when the issue is solved, and I can probably list your app again.
Hi, did not see your message somehow, sorry...
Anyway: a user had issues with zxing as a barcode engine. Google offers ML Kit as a modern barcode solution, and this worked for that particular user and device. Zxing is still there as a fallback.
So that is kind of a dilemma I cannot solve right now. Zxing does not work everywhere, ML brings undesired dependencies and adds to the app size (which can be overcome by lazy loading the ML library upon installation)...
What would you do in my place?
Best,
stud0709
Using build flavors might be a good approach. Have one flavor as-is now (let's call it play
as it's the one going to PlayStore), and a second one (let's call it foss
as it should come without the proprietary dependencies). Then use playImplementation
instead of implementation
for the MLKit (and what other non-free things you need along that) to keep it/them out of the foss
build flavor.
It will probably need some other (hopefully minor) adjustments to the code, e.g. to deal with the absence of MLKit in the foss
flavor (I'm no Android dev, so I unfortunately cannot help with that), but that's basically what other projects do in comparable cases. You can use the same applicationId
for both, allowing users to switch between – or use a new applicationId
(e.g. adding .foss
to it) so both can be installed simultaneously, as you wish. You can then attach both to releases giving them distinct names (like including the flavor name with their file names), and everyone can pick their favorite variant. I'd then pick the foss
one for my repo and re-establish your app there. Size of that should then be back below 30 MB as well I guess.
How does that sound to you?
It sounds like a hint I have to understand first, as I am not an Android dev either.
There is not a big deal to get rid of ML again, but I'll have to understand this release related stuff first. I know of at least one person who relies on ML, it would be unfair.
I'll come back to you as soon as I have made some progress here.
Best,
stud0709
Fair enough, thanks! Wish you good progress!
please check if you can work with v0.27 (a pre-release)
Yupp, that looks wonderful! Allowed me to even close an eye and permit me to keep 2 versions (though in sum that would exceed the 30 MB limit), to avoid the 404 when the repo updated but a client didn't yet fetch its latest index).
Reactivated the app again, v0.27 will show up with the next sync around 7 pm UTC then. Thanks a lot!
With the latest release, the APK size (39 MB) now exceeds the per-app size limit in my repo (30 MB) – and further comes with a couple of proprietary components, so it no longer is fully FOSS:
For now I've removed this version from my repo (and re-established the previous release), and also disabled updates. Do you see a chance for an APK matching the inclusion criteria – or will we have to remove the app from my repo?
Btw: while the size would be no problem with f-droid.org, those libraries are show-stoppers there as well.