-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offer SD in alternative Android app stores (F-Droid, etc) #37
Comments
Hey! I'll see if it makes sense to add to the releases, but you can always download APKs for any Play store release here: https://apkpure.com/superduper/io.kbl.superduper |
Unfortunately, that needs Cloudflare and thus downloads cannot be automated. And it only offers APKX. Adding it to releases here would make automated checks/downloads possible. For some background: I was planning to add your app to the IzzyOnDroid repo. New releases would then become available there within 24h of your making the APKs available at a new release here. As far as I could tell without having an APK to cross-check, the IzzyOnDroid App Inclusion Policy should be met. And I especially like that, according to the Readme: "No account or internet connection required" – unfortunately a rare thing these days with "all things cloud" 😉 PS: To not only "ask to take" but also "offer to give": setting up the app at IzzyOnDroid requires establishing Fastlane structures; I'd take care for that. So they would be there then anyway – and I could offer you a PR with what is set up, so you could use that for PlayStore as well. Good thing with that is: you know best how your app should be presented. And by keeping description and graphics in sync with new releases, that would take care for the representation at IoD as well, as the updater could then fetch those details along with the APKs. If this sounds good to you, the IzzyOnDroid Fastlane Documentation might help you maintaining it (and I myself should you have questions with that). As with "Internet" above: no Fastlane binaries needed for this, just the Metadata (text files and graphics). Edit: Fastlane works for iOS as well, there's |
Interesting! Thank you for the extra context. I have been meaning to set up CI for this app on Github actions, but I'm currently just building locally. iOS is the biggest pain point for that. I've had not good experiences with Fastlane in the past and I just use the normal I looked at the Inclusion Policy and I see 2 potential issues: 1. The the apk is a bit on the thicc side: ~50mb. And 2. I let Google do the signing for me, so I think the APKs I make are unsigned. Barring that, I'd definitely take a look at a PR for CI! |
What I rather meant was the I know the fastlane binaries can be used to ship everything to Google & Co. But having cut my ties to Google many years ago (they've closed my account for inactivity back in… don't remember, 2017?) I'm not even using their store to get apps. I rather use "open sources". And to help others with that, started the IoD repo back in 2016.
Ugh? What did ApkPure make then to get the APKX down to about 15 MB? That was what I was going by. But nevertheless: if the "fat build" really exceeds the 30 MB, maybe ABI splits? As I wrote, I could not take a look at your APK(s) so I cannot tell. But especially with Flutter, native libs easily sum up to more than 10 MB per ABI (compressed). So if you currently have 4 of them in the "fat build", using e.g. arm64 or armeabi for IoD could bring them down below 30 MB. And honestly, as far as I can tell your app fills quite a niche: in the 12+ years I run my app listings and the almost 10 years I'm involved with app-repos like F-Droid.org or mine, I cannot remember many apps for eBikes (if any) in the FOSS field. So I could well imagine making an exception in this regard as long as it's not to big an exception 😜 I mean, should the per-ABI build slightly exceed the 30 MB one day, I'd not consider that a show-stopper (there are some, while few, exceptions already established).
Eek… So they put all those blobs in as well (see here). Well, it's not too hard to set up your own release keys – if you're OK with that – for signing "libre builds". Unfortunately, IoD has no options (yet) to offer signing (or even building) to developers… F-Droid however does and would then sign with a key generated there. They'd also need to build your app from source at that, so inclusion with their repo can take a little. Would be something to consider as well, though.
Apologies if I caused a misunderstanding there: I have no CI experience. What I was offering was just the |
I see. I'll admit I'm not that familiar with the different Android packaging options... I just do what Google tells me to. I'm the problem! In any case, I've been working on a fix that I just pushed a release for: https://github.com/blopker/superduper/releases/tag/v0.6.2%2B39. I've manually added the appbundle and the apk from my local build there. I think they are being signed by an 'upload key', but I'm not sure. If one of those works for you, I can get CI to make them without setting up fastlane pretty easily. If I need to figure out how to manually sign them, then it may take a bit to get to. |
😱
Let me check… Oof, the APK is still over 40 MB. OK, I've started this, so let's go through: downloading the APK and running it through my scanners now… OK, library check looks good, as expected. Signature check, as expected ("I just do what Google tells"), has:
That can easily be avoided by a tiny modification of your android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
} For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo. The signature itself looks fine! Proper DN and all. Now let's look into the APK itself: I see it is a "fat build", covering 3 ABIs. As expected, each ABI has native libs with ~15 MB (uncompressed) each – and also as expected, they are not compressed but So what would you say: have per-ABI builds and add one of them to IoD? You have the last word here also concerning which one to pick: armeabi supporting older 32bit-only devices as well (but leaving Google's Pixel 7a plus out as that's 64bit-only), thus having widest device support (we can switch to arm64 anytime 32bit-only devices are "no longer around") – or arm64 being better optimized for all 64bit devices, but leaving out all 32bit-only devices. |
Ok, thank you for the background here. I'm in the middle of moving, and I'm not sure when I'll have time to make all the changes needed for this. Also, while I'm fully aligned on the mission here, I'm not sure how many actual users want the app outside the Play store. I haven't had any requests for it yet. I'm going to leave this ticket open however and if it gains interest from the community I'll reprioritize. |
Thanks, as you see fit. With 150k daily visitors at IzzyOnDroid, a listing here would also increase visibility – in case that's an argument for you 😉 |
Just wondering if the APK is (or could be made) available for those without access to PlayStore – e.g. by attaching it to the corresponding release? Thanks in advance!
The text was updated successfully, but these errors were encountered: