per-ABI builds?

[IzzySoft]

With v2.11.31 clearly exceeding the size limit of my repo (40 MB APK, 30 MB per-app limit), may I kindly ask for per-ABI builds of the Android APKs? The current APK holds native libs for armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips and mips64. I don't know if there are really devices running Android on Mips, and even the x86* are rather rare but having ~20 MB native libs each. I'd then offer either armeabi-v7a or arm64 via my repo and let you choose which of the two.

Thanks in advance!

[laurent22]

We probably won't do per-ABI builds as it's too much work to create this and maintain it. Ideally we'd reduce the size of the APK if we can but that also won't be easy. I don't assume you can increase the limit to 50 MB or more?

[laurent22]

Actually it looks like I commented out the NDK filter when I last upgraded React Native. Not sure why I did that, but I'm going to uncomment it and see if it works

[laurent22]

Hmm, no it doesn't help much because it's the Vosk lib that's taking a lot of space, and it's recompiled for each architecture

[IzzySoft]

I don't assume you can increase the limit to 50 MB or more?

First my repo runs on personal space, second one of the APIs I use has a hard limit at 32 MB. I have a work-around for the latter which is why I can make exceptions here and there, but I want to keep their numbers as low as possible. I've just pulled in the latest release manually (Github put it in the middle of page-2 again) and applied that exception to Joplin, but it would be "preferable" if the size were within limits again.

because it's the Vosk lib that's taking a lot of space, and it's recompiled for each architecture

I vaguely remember having heard that somewhere else before, but do not exactly remember where… Is it possible to put an ABI filter on that one? I guess (almost?) nobody will need Mips (but then, looking into the libs/ directory, size-wise Mips is almost not worth mentioning), and few would need x86 (probably emulators only). So if these two could be kept out, we might be below 32 MB again. A big "if" maybe…

Thanks for checking btw! Oh, and that's funny: I just checked the metadata at F-Droid where I assumed having seen the Vosk-issue before. Looks like that was Joplin. And the funny part: the net.cozic.joplin.yml no longer mentions Vosk – v2.11.10 was the last release I find it mentioned, 2.11.13 no longer has the corresponding scanignore: line. It was removed with this commit and with this because the corresponding path (packages/react-native-vosk/node_modules/react-native/build.gradle.kts) was no longer found. Strange. But there are no per-ABI builds at F-Droid either, so I'm not sure if this really is the case I remembered.

[laurent22]

I've tried adding the ABI filter and it does remove the mips, mip64 and armeabi folders but doesn't make much of a difference.

Somehow the resulting APK is even larger (43.3 MB vs 41.5 MB). Those folders anyway don't have much in it, just one .so file - I don't know if it's an optimisation or if those versions just wouldn't work anyway. They don't include libvosk for example so removing them doesn't change much.

So yes, libvosk is what makes a big difference - there's a different one in each of the supported architecture folder and each file is about 10 MB. Perhaps we should indeed release a different APK for each architecture but that's probably quite a bit of work. I'll add it to the backlog anyway so that we keep track of it.

[IzzySoft]

Thanks for investigating, Laurent! And thanks for adding it to the backlog. I understand that you cannot simply snip your fingers to have per-ABI builds ready, so I'll go with the full builds for now until you have them ready. Please give me a ping then – and also let me know which ABI I shall take then: armeabi-v7a for the widest support including older devices, or arm64 for newer devices including those few 64-bit-only ones but excluding all pure 32bit devices.