blopker / superduper

iOS and Android app to manage your ebike.
MIT License
35 stars 6 forks source link

Offer SD in alternative Android app stores (F-Droid, etc) #37

Open IzzySoft opened 5 months ago

IzzySoft commented 5 months ago

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!

blopker commented 5 months ago

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

IzzySoft commented 5 months ago

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" :wink:

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 /fastlane/metadata/android for Android, and /fastlane/metadata/ios for iOS.

blopker commented 5 months ago

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 flutter build * commands, then use Transporter and Google to sign/upload the packages. Although if you have a Fastlane setup that is set and forget, that would be appealing to me.

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!

IzzySoft commented 5 months ago

if you have a Fastlane setup that is set and forget

What I rather meant was the fastlane/ directory with the current description and graphics. I don't use the fastlane tooling either, just a text editor for descriptions, and manually add the graphics. So maybe graphics need to be updated once a year, descriptions once they no longer fit – and optionally the per-release changelogs on each release.

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.

The the apk is a bit on the thicc side: ~50mb

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 :stuck_out_tongue_winking_eye: 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).

I let Google do the signing for me

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.

I'd definitely take a look at a PR for CI!

Apologies if I caused a misunderstanding there: I have no CI experience. What I was offering was just the fastlane/ directory with its contents, called "metadata" – descriptions and graphics in fastlane format, so to say. As I'd have to set up those anyway to get the app into the IoD repo (F-Droid would ask you to provide that as well).

blopker commented 5 months ago

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.

IzzySoft commented 5 months ago

I just do what Google tells me to.

:scream:

I've been working on a fix that I just pushed a release

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:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

That can easily be avoided by a tiny modification of your build.gradle:

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 Stored. So, if you could provide per-ABI builds, each of that would come at about (rotates numbers in the brain: 48 - 2 * 12 to be "pessimistic") around less than 25 MB, which again would fit the inclusion criteria :smiley:

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.

blopker commented 5 months ago

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.

IzzySoft commented 4 months ago

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 :wink: