F-Droid client and server should start compressing apps that don’t extract their native libraries.
Compress how? Aren’t APKs still ZIPs?
@Licaon_Kter
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
/LE:
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 .apk.zip 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 ? 
examples:
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/libcroc.so
26809088 Stored 26809088 0% 00-00-1980 00:00 1a4cf72c lib/arm64-v8a/libcroc.so
26237998 Stored 26237998 0% 00-00-1980 00:00 8170eb1d lib/x86/libcroc.so
27315394 Stored 27315394 0% 00-00-1980 00:00 7f4a2036 lib/x86_64/libcroc.so
unzip -lv network.loki.messenger.fdroid_3315.apk | grep "\.so"
43160 Stored 43160 0% 01-01-1981 01:01 5b32cf35 lib/arm64-v8a/libaesgcm.so
2046192 Stored 2046192 0% 01-01-1981 01:01 26631264 lib/arm64-v8a/libconscrypt_jni.so
7135240 Stored 7135240 0% 01-01-1981 01:01 7bb6505f lib/arm64-v8a/libjingle_peerconnection_so.so
...