APK size increased by factor 60

[IzzySoft]

What happened to the APKs that their size suddenly jumped from less than 5 MB with v1.0.1 to more than 120 MB with v1.1.1? That's more than 4 times the per-app-limit at IzzyOnDroid, so I had to disable updates for now. Is it possible to get back into the slot there? Otherwise we'd have to remove the app from IoD as that's far to much.

Thanks in advance for any help!

[anonfaded]

I tried to reduce the file size but i think that isn't possible because right now i have changed the whole app and 130+ changes have been made. Added new features and open source libraries like ffmpeg which takes around 60mb, and other dependencies similarly. So I'm not sure how to decrease the size while not removing the main features. In readme i have added new screenshots of UI and in release you can see the changelog, so can you please analyze it and then let me know if i can do something to reduce the size?

Chatgpt suggested to only include the useful features of ffmpeg and not whole library, as right now ffmpeg only adds watermark to videos, but in future I'll add editing functionalities too so idk if i should do something now or leave it as it is. Suggest please what to do?

[obfusk]

Open Video Editor switched to ffmpeg-kit-min, which is smaller. Maybe that is an option?

[anonfaded]

Open Video Editor switched to ffmpeg-kit-min, which is smaller. Maybe that is an option?

I'll try if it works, but that still won't reduce the size too much as other libraries are taking up space too

[obfusk]

Split ABI might help too.

[anonfaded]

Split ABI might help too.

I tried other versions of ffmpeg but only the ffmpeg.kit.video worked, and i can't do the ABI thing because i need a single universal app for all architectures. But the size is now around 95mb and i think it can't be optimized more, so is it ok? @IzzySoft

And new release with this new apk will be released today.

[IzzySoft]

No, 95 MB is still far beyond the limits for IzzyOnDroid. But there's no contradiction in providing per-ABI bulds and a "fat build" as well. For IoD I'd then just pick a single ABI – and whomever that one doesn't fit can pick the other one from here.

[anonfaded]

No, 95 MB is still far beyond the limits for IzzyOnDroid. But there's no contradiction in providing per-ABI bulds and a "fat build" as well. For IoD I'd then just pick a single ABI – and whomever that one doesn't fit can pick the other one from here.

The limitation is as in total or per apk? If its in total like new and old version, then what if you make only the latest version on IoD and delete all the old ones?

If not then I'll try doing the split thing, i haven't done it before so i hope it will work.

[IzzySoft]

The limitation is as in total or per apk?

Per app.

what if you make only the latest version on IoD and delete all the old ones?

Depending on APK size, up to 3 versions are kept. Which means once the APK crossed ~16 MB, there will be only 1 version kept, yes. So in case of FedCam, that would probably mean 1 version then. "Purging" happens automatically, based on the size (or rather the corresponding setting in the app's config here).

If not then I'll try doing the split thing, i haven't done it before so i hope it will work.

That would be great, thanks! As the "fat build" currently is at ~95 MB, it will most likely mean each split APK is slightly above 30 MB – but depending on how much above, we'd close an eye on that. So if it's 32 MB, that would not necessarily mean "you're out" 😉

[obfusk]

You could probably reduce the APK size by about 50% by compressing the .so files using android.packaging.jniLibs.useLegacyPackaging = true.

[anonfaded]

You could probably reduce the APK size by about 50% by compressing the .so files using android.packaging.jniLibs.useLegacyPackaging = true.

Ai said its not recommended method:
The suggestion to use android.packaging.jniLibs.useLegacyPackaging = true to reduce APK size by compressing .so files is outdated and not recommended for modern Android development.

[obfusk]

Everything is a trade-off. Sure, ChatGPT can tell you it's "not recommended". But it can't understand why or when it does make sense to use it.

I do agree it's not an ideal solution. Unlike ChatGPT I understand exactly what the downsides are. But It would reduce your current APK from 120MB to 60MB. I would not reject a useful method just because ChatGPT says it's "not recommended".

Google's recommended solution would be to use app bundles. But that's a recommendation that assumes publishing via Google Play (which has very different limits and distribution) and doesn't work at all for IzzyOnDroid.

My recommended solution would be to avoid having >100MB of .so files in the APK in the first place. But since you say you need those, you end up having to choose to make a trade-off somewhere else to stay within IzzyOnDroid's limits.

[obfusk]

Anyway, I'm just trying to provide you with various options to choose from to reduce the APK size. Few of them have zero downsides. Good luck figuring out what works best for you :)

[anonfaded]

Anyway, I'm just trying to provide you with various options to choose from to reduce the APK size. Few of them have zero downsides. Good luck figuring out what works best for you :)

I'm trying, right now doing the split thing but its also giving errors, lets see. If nothing works then i may leave IoD as i got no option, it will be hard to manage this for every release too...

[IzzySoft]

Best luck for a successful build, @anonfaded – and I'd always trust Fay's recommendation over that of any AI. Over that of most other people even at that, especially when it comes to "programming" topics.

The search engine's AI-generated responses have also said geologists recommend humans eat one rock per day.

(source: BBC)

You never know what sources AI relied on (Study Finds 52% of ChatGPT Answers Are Incorrect) – but I'm pretty sure the sources Fay relies on are sound 😉

[anonfaded]

Split ABI might help too.

It worked! thanks
@IzzySoft now the split apk sizes are in 24-28mb range so now its ready i guess. I have updated fastlane metadata with new screenshots some days ago so i also want that to be with new release on IoD, thanks in advance :)

[IzzySoft]

Great, thanks @anonfaded! Which ABI do you want me to pick then? armeabi for broader compatibility – or arm64 for better optimization on newer devices (but not supporting 32bit devices)?

[anonfaded]

Great, thanks @anonfaded! Which ABI do you want me to pick then? armeabi for broader compatibility – or arm64 for better optimization on newer devices (but not supporting 32bit devices)?

I'm not sure but you know better so you can pick any that will work on most devices, skipping 32bit or the rare/too old devices can be good i think

[IzzySoft]

It's rather only one device known to me that cannot deal with armeabi (a specific Google Pixel) – but multiple devices which cannot support arm64. I usually pick armeabi for apps that do not have many alternatives, and arm64 if there are already many alternatives. But the app author has tha last word on this, which is why I ask 😉 So we go with armeabi here?

[anonfaded]

yes sure, if later someone faces some issues then they can visit the GitHub and find the appropriate version for themselves

[IzzySoft]

That, and once 32bit devices are really no target anymore for your app, we can always switch over to arm64.

OK, done: next update will pull armeabi then. Both armeabi and arm64, have just be confirmed to be reproducible (see Reproducible Builds, special client support and more in our repo for some background on this), congrats!