availability via F-Droid

[DJCrashdummy]

as the old 1.x version was at least available via Izzy's fdroid repo, i notified him that there is a new 2.x version with its source in a different repo: https://gitlab.com/IzzyOnDroid/repo/-/issues/572

it would be nice if you can give some feedback about the questions raised there.

---

for sure, making Minimum available via the main F-Droid repo would be even better. :wink:

[JunioJsv]

Hello, I just rotated the signing key to have compatibility with previous apks, take a look at the releases tab

[IzzySoft]

Hi @JunioJsv – I can hereby confirm the key rotation for the APK you've pointed out, thanks for the thoughtfulness! Details in the issue linked above by @DJCrashdummy. But as a side effect from having changed from Kotlin to Flutter, APK size has increased by factor 20 (from 1.2 MB to 22 MB), so the IzzyOnDroid repo will no longer keep historical versions (due to the per-app size limit of 30 MB). Still, you might wish to pick a badge to link to your app there from your Readme, next to the Google badge, maybe?

[JunioJsv]

I managed to reduce the apk, changing from universal mode to splitted per abi, take a look, they are less than 10MB now

[IzzySoft]

Ah, nice – yes, that would work. Two questions there:

1. which one do you want on IoD then, armeabi or arm64? armeabi is compatible with more devices (except the very few 64bit only), arm64 is better optimized for newer devices but would leave all 32bit devices out.
2. will you keep up the key rotation for a few versions (say, for 1..3 months) to give people a chance to update as long as they still run the Kotlin version?

[IzzySoft]

Oops?

2024-07-30 19:39:04,717 WARNING: "juniojsv.minimum_2145.apk" is signed by a key that is not allowed:
6a4d7370a8a01669b6ed5417eed984fc650b02c3d7b99cc5dbbbb586a3200af6
juniojsv.minimum_144.apk|3 malware alerts|25 libs
juniojsv.minimum_2145.apk|3 malware alerts|25 libs

So you returned to the original key? Which one is the one you'll be using from now on? The updater automatically picked one of the APKs "by choice" as it was not yet prepared for the splits. But it doesn't matter as that APK never went live: key pinning (to the new key) prevented it.

As for the malware alerts, here's the one from 144. The prefixed "2" at 145 probably indicates the arm64 variant. Keep in mind that by using Flutter's default numbering there, a switch from arm64 to armeabi (if needed; e.g. to restore to an old backup device with keeping the data, while the new one is at repair) is impossible, as versionCode of that will always be lower (here: 1145). There's a way to tell flutter to instead of versionCode + (ABI*1000) use e.g. (versionCode * 10) + ABI, which in this example would result in 1451 (armeabi) and 1452 (arm64), thus a switch would always be possible with an update.

[JunioJsv]

I generated the apks with my new signature, then re-signed them using apksigner to rotate the keys

[JunioJsv]

apparently there is no way to separate the apks by abi using bundletool which was the tool I used to create that universal apk with the rotated key

[JunioJsv]

Dude, I'm almost giving up on posting the apks on github, I'll just leave them on the Google Play

[JunioJsv]

I tested updating from apk 1.6.0 to version 2.0.2 with the rotated keys and there was no incompatibility in the signature

[JunioJsv]

I've already decided, I won't post any more apks on github, anyone who needs or wants an alternative version to Google Play will need to compile directly from the code

[IzzySoft]

So you want me to remove the app from IzzyOnDroid? Makes no sense to keep it there if there won't be updates anymore. A pity: a FOSS app that needs a proprietary walled garden to be used by everyone who cannot compile themselves :cry:

[IzzySoft]

PS: an alternative could of course be not to use bundletool – but instead just build split APKs instead of AABs and use apksigner to sign and rotate. Many roads lead to Rome :wink:

[JunioJsv]

Dude, I'll figure something out, but it might take some time to make the apks available with the correct signature, I'm busy with my main job

[DJCrashdummy]

same here, so no pressure @JunioJsv and take your time... at least thanks for releasing FOSS. and thanks a lot for releasing FOSS in a FOSS friendly way. :wink:

[IzzySoft]

but it might take some time

Eh, we're not on a hunt here. And yeah, "main job" can be a time-eater, full understanding (I also have one).

So thanks a lot for caring, @JunioJsv! Unfortunately I'm no Android dev (especially no Flutter dev) or I might have looked to give you a snippet or even provide you a PR for the split part…

Waiting for your update then, when it comes. Hope you don't mind a "ping" not more often than once a month to check?

[JunioJsv]

I just posted the versions using my old signature, the same as the other repository, use the app-armeabi-v7a-release.apk version I believe it has more compatibility because it is 32bits

[IzzySoft]

Full ack to 32bit. So we stay with the original key then? Just asking before we switch back-and-forth multiple times.

[JunioJsv]

that's right

[IzzySoft]

OK, switchover performed. I'm just not sure if those having installed the key-rotated APK can switch back as easily, but we will see. So thanks for your help!

Eh, one more question before I forget: can you tell me which path you build the app in, and what flutter version you're using? I could try and see if it would be RB (see Reproducible Builds, special client support and more in our repo) if you wish.

[JunioJsv]

So, the version of flutter that can be used to build the project is specified in pubspect.yaml, I'm currently using version 3.22.0, and the script to build is in the build_minimum.dart file

[IzzySoft]

So, the version of flutter that can be used to build the project is specified in pubspect.yaml

Where? I don't see it:

environment:
  sdk: '>=3.4.0 <4.0.0'

dependencies:
  flutter:
    sdk: flutter

No specific version. Easiest would be if you had the specific version as git submodule in your repo here.

and the script to build is in the build_minimum.dart file

Flutter embeds full paths into its native libs. So for a successful RB I'd need the absolute path this is build from (and ideally how you invoke the build). Your Kotlin app was RB btw…

[JunioJsv]

sdk: '>=3.4.0 <4.0.0'

[IzzySoft]

That means "any flutter version between that"? Would be much easier if it were a submodule (which is btw also what F-Droid.org recommends), so you could adjust the version by updating the submodule accordingly and one would not need to check whenever a build fails.

That said, without knowing the exact build path it makes not even sense to try :wink: