Compressing APKs for storage/download

F-Droid client and server should start compressing apps that don’t extract their native libraries.

Compress how? Aren’t APKs still ZIPs?

Android added support for loading native libraries directly from the APK a few years back, so if extractNativeLibs=false is set they are specially not compressed. So compressing the entire APK can result in significant savings.

See apk - Setting android:extractNativeLibs=false to reduce app size - Stack Overflow and <application>  |  Android Developers and R.attr  |  Android Developers

fdroidclient needs support for downloading/installing compressed apks
and fdroidserver needs a --force-compress flag along with auto detection (via extractNativeLibs=false in AndroidManifest AND not useLegacyPackaging in *.gradle)

Right, interesting.

fdroidserver issue I guess, if not a reproducible build then do X


Can you rephrase exactly again? Because you saying “we should compress if false” sounds the opposite of “It expects the libraries stored uncompressed in the APK (STORE method) and zipaligned. There’s no need to extract them during installation. On app startup, the libraries can be loaded (memmapped) directly from the APK.”

Native libraries in APKs should not be compressed by default.

If useLegacyPackaging is set or if extractNativeLibs=true, then they will be compressed and extracted on install.

You can check the compression ratio with unzip -lv whatever.apk | grep "\.so"

I thought the HTTP compression is enabled so everything is compressed?

Does HTTP compression attempt to compress such large files? Do all mirrors have it enabled?

Regardless, HTTP compress would be a waste since it’d be compressing every time instead of once before upload.

I don’t know if the apks are compressed. I know the index is compressed. Do you mean we should storage .apk.xz files?

Why is reproducible build related? I thought we need to decompress the apk when it’s installed.

I thought it’s about somehow enforcing better .ZIP compression in the .APKs not that we store and serve .7Z or .XZ

No, I was suggesting serving up in cases where fdroidserver determines it is beneficial, and fdroidclient would decompress the .zip and install the .apk like normal.

Yeah, sounds good, one bad thing is that the website might need APKs so we’d keep both APKs and .APK.XZ ? :frowning:


du -sh *
57M	app.organicmaps_22121812.apk
42M	app.organicmaps_22121812.apk.gz
41M	app.organicmaps_22121812.apk.zst
55M	chat.simplex.app_92.apk
50M	chat.simplex.app_92.apk.gz
50M	chat.simplex.app_92.apk.zst
102M	com.github.howeyc.crocgui_28.apk
50M	com.github.howeyc.crocgui_28.apk.gz
23M	com.github.howeyc.crocgui_28.apk.zst
32M	com.junkfood.seal_10814.apk
30M	com.junkfood.seal_10814.apk.gz
30M	com.junkfood.seal_10814.apk.zst
101M	im.vector.app_40105220.apk
93M	im.vector.app_40105220.apk.gz
93M	im.vector.app_40105220.apk.zst
185M	net.osmand.plus_4308.apk
161M	net.osmand.plus_4308.apk.gz
159M	net.osmand.plus_4308.apk.zst
83M	network.loki.messenger.fdroid_3315.apk
52M	network.loki.messenger.fdroid_3315.apk.gz
51M	network.loki.messenger.fdroid_3315.apk.zst
79M	org.mozilla.fennec_fdroid_1091120.apk
71M	org.mozilla.fennec_fdroid_1091120.apk.gz
71M	org.mozilla.fennec_fdroid_1091120.apk.zst
158M	org.supertuxkart.stk_312.apk
155M	org.supertuxkart.stk_312.apk.gz
153M	org.supertuxkart.stk_312.apk.zst

note 0% compression ratio

unzip -lv com.github.howeyc.crocgui_28.apk | grep "\.so"
26271864  Stored 26271864   0% 00-00-1980 00:00 fd6af864  lib/armeabi-v7a/
26809088  Stored 26809088   0% 00-00-1980 00:00 1a4cf72c  lib/arm64-v8a/
26237998  Stored 26237998   0% 00-00-1980 00:00 8170eb1d  lib/x86/
27315394  Stored 27315394   0% 00-00-1980 00:00 7f4a2036  lib/x86_64/
unzip -lv network.loki.messenger.fdroid_3315.apk | grep "\.so"
   43160  Stored    43160   0% 01-01-1981 01:01 5b32cf35  lib/arm64-v8a/
 2046192  Stored  2046192   0% 01-01-1981 01:01 26631264  lib/arm64-v8a/
 7135240  Stored  7135240   0% 01-01-1981 01:01 7bb6505f  lib/arm64-v8a/