Feature Android Split Build

[k3b]

Currently android apk build is about 62Megabyte.

This is ok for modern android devices but not for my old android-10 which is always running out of internal memory.

When looking into the android generated apk file with a zip tool there are currently 4 libs one for each supported processor *arm64-v8a, armeabi-v7a x86 and x86_64

if there where one apk for each* supported processor the apk size could be reduced to 30 Megabyte.

For details see Migrate universal apks to split apks at Migrate universal apks to split apks (#2809) · Issues · F-Droid / Data · GitLab

Migrate universal apks to split apks (#2809) · Issue · fdroid/fdroiddata* *

[239]

The effort does not seem to be really justified by 32 MB - I’m sure there are better places to look for wasted storage, but of course there could be other good reasons for splitting.

[MysticBard]

just delete the apk after installation.

[bt90]

The files are still present on the phone. But I also agree that it’s not worth the effort.

[gadget]

@k3b

if there where one apk for each* supported processor the apk size could be reduced to 30 Megabyte.

Could probably save 10-20 times more just by pruning the web browser cache of older data.

[HeyThere]

@gadget

Could probably save 10-20 times more just by pruning the web browser cache of older data.

…and this is how we end up with more and more bloated software.

Just because space can be saved in other ways, doesn’t justify bundling useless architectures in the APK.

[gadget]

@HeyThere

@gadget

Could probably save 10-20 times more just by pruning the web browser cache of older data.

…and this is how we end up with more and more bloated software.

I totally agree. Features completely unrelated to the core functionality are bolted on, we end up with bloat. However with regards to Syncthing for Android, without those ABIs, Syncthing doesn’t function.

Just because space can be saved in other ways, doesn’t justify bundling useless architectures in the APK.

I happen to have an x86-based tablet, a PC stick, plus two phones that span all four CPU architectures. My tablet is no longer compatible with Google Play and F-Droid, but I can still sideload, so at least for me, having a single APK that supports all four devices is very convenient.

The case could be made that because I’m not fluent in most of the other languages translated for Syncthing’s UI, there should be an APK that only bundles English. So instead of a single APK, we should have one for each combination of CPU architecture + language. And while we’re at it, Unicode support also isn’t necessary for me, so reducing the footprint by switching to 7-bit ASCII would be wonderful.

But seriously, saving 30MB by increasing the complexity of the build process and distribution doesn’t seem worth it when there are much faster, easier, and impactful solutions available.

Except for the smallest of deployments, Syncthing’s database can easily be larger than 30MB. So a phone/tablet that’s bumping up against the internal storage capacity is going to have a truckload of other problems way more than shaving 30MB off Syncthing’s APK can ever resolve.