[Feature] Upload other arch variants (especially aarch64/arm64-v8a) to IzzyOnDroid

[inmaldrerah]

Please upload other variants (especially aarch64) to IzzyOnDroid. Currently there is only armeabi-v7a, which is problematic if the app is automatically updated by F-droid, as this app does not allow using the armeabi-v7a variant on an arm64-v8a device. (Or maybe this requirement can be loosen?)

[devnoname120]

@IzzySoft

[IzzySoft]

This is for @XayahSuSuSu to decide. We can only provide one APK per release; if the devs want us to pick "the other one", that can be done – but only "instead", not "in addition to".

this app does not allow using the armeabi-v7a variant on an arm64-v8a device. (Or maybe this requirement can be loosen?)

Does your device support armeabi? It's not the APK not allowing that, it's a question of what ABIs the device (and its ROM) supports.

[devnoname120]

@IzzySoft Would a multi-arch APK work as well?

The APK installs fine but then in the app a list of requirements is shown and the armv7 architecture has a red cross next to it. IMO if we want to support one or the other then arm64 makes more sense because armv7 is getting very old and newer devices don't support it.

[IzzySoft]

How do you plan keeping that below the 30 MB per-app size limit then? At best, you'd end up with something "just" below it. But then, we could no longer provide the last 2 releases – which means, at the time a new update is pushed, some people will receive a 404 when trying to install the previous version as the index on their clients has not yet been updated (by default and with the official client, the index is updated once per day).

[XayahSuSuSu]

The APK installs fine but then in the app a list of requirements is shown and the armv7 architecture has a red cross next to it. IMO if we want to support one or the other then arm64 makes more sense because armv7 is getting very old and newer devices don't support it.

I'll fix that

[IzzySoft]

@XayahSuSuSu so you want us to switch to arm64 at IzzyOnDroid? Because if so, that's something to be fixed at our end (telling our updater which APK to fetch).

As for "newer devices don't support it": that very much depends on the vendor. I just got my brand new device, and it still supports armeabi 😉 I only know of a few devices no longer supporting armeabi; mostly Google Pixel.

[XayahSuSuSu]

@XayahSuSuSu so you want us to switch to arm64 at IzzyOnDroid? Because if so, that's something to be fixed at our end (telling our updater which APK to fetch).

As for "newer devices don't support it": that very much depends on the vendor. I just got my brand new device, and it still supports armeabi 😉 I only know of a few devices no longer supporting armeabi; mostly Google Pixel.

For the most compatibility, I think armv7 is still the best choice, maybe I can allow armv8 devices passing the environment detection on armv7 apk, this seems better for both of us :)

[inmaldrerah]

Thanks all. That's a good solution. Sorry I wasn't aware of the size limitation of IzzyOnDroid.

If there is a good reason not to use armv7 on aarch64 devices (e.g. operates faster), maybe this is more about the F-Droid client I'm using (which is Droid-ify) not supporting more customized auto update (e.g. update to 64 bit only).

[IzzySoft]

The client should only offer ABIs supported by your device/ROM. So if your device supports armeabi, and there's only armeabi available as update, that would be used: when compatible, only versionCode counts (higher versionCode = newer version = update). If both (armeabi + arm64) are available, the APK with the higher versionCode will be used for update – which should be arm64 then, if correctly configured by the resp. developers. If both have the same versionCode, I'd assume (not sure there) it would pick by the order of preference shown by the device.

In your case: IzzyOnDroid only offers armeabi for this app, so that will be used. If the app is available in another repository, it must have the same signature (here: must be signed by @XayahSuSuSu) to make a cross-update possible. F-Droid e.g. uses its own signing keys unless the app was established as reproducible build, so if not, you could not cross-update.