Hello!
Maximum compression level for .apk in the repository, please start using.
This way, you can save a lot of space on the server hdd and reduce mobile internet traffic.
- very much, unload in the end, the communication channels of your server.
1 Like
Isn’t that like level 6 ZIP always?
Well, surely there are more, even better.
But Android APKs are a certain format, .ZIP, so it must conform to it.
original size: 10646430
#using the libdeflate compressor. This is the default level of compression
advzip -z F-Droid-recent.apk
10646430 7811282 73% F-Droid-recent.apk
10646430 7811282 73%
# -4, --shrink-insane
# Set the compression level to “insane” using the zopfli compressor. You can define the compressor iterations with the -i, --iter option.
advzip -z4 F-Droid-recent.apk
7811282 7802174 99% F-Droid-recent.apk
7811282 7802174 99%
I think the default preset used is probably the middle preset zip, right?
Are there problems with reproducible builds if F-Droid starts to compress stronger? Do RB depend on the same hash sum?
It will break reproducible build. And I thoguht the compression needs to be done manually. See https://github.com/simplex-chat/simplex-chat/blob/v4.6.0/scripts/android/build-android.sh#L97-L100 for example.
build-android.sh#L97-L100 gets beyond my scope. Do you mean that zipalign sorts the beginning of files in the zip archive to 4 and that creates problems?
man zipalign:
-z Recompress using Zopfli
Couldn’t -z be used by all authors in the line from zipalign?
Couldn’t there an extra “advzip -z4 &&” after
&& zip -rq5 “$tmp/simplex-chat-armv7.apk” . &&
The file format isn’t changed by using zopfli.
I posted actual numbers here, it’d be way better to just zstd the app: Compressing APKs for storage/download - #12 by SkewedZeppelin
Are you sure, that the size of crocgui.zstd is right? I get at least 41MB with zstd -19
102M com.github.howeyc.crocgui_28.apk
50M com.github.howeyc.crocgui_28.apk.gz
23M com.github.howeyc.crocgui_28.apk.zst
48M crocgui_28.apk.gz # zopfli (-i15 =default)
41M crocgui_28.apk.zst # zstd -19
@Jens a lot can change in 10 months
you should stick to the default levels with zstd, or not go past 7 as it becomes very slow to compress
Are you planning to start testing, comparing the current level zip compression size to the maximum?
And after testing, 10 applications, decide to change the compression preset to “max”.
feel free to test and offer your feedback 
I’ve already offered you.
That’s a strange response…
“why don’t you do this and that” is not feedback
Feedback is what Jens and SkewedZeppelin posted above, actual numbers and such
To be more exactly in this conversation:
“Why don’t you…” is in general a kind of feedback but with the following suggestive question “And after testing, 10 applications, decide to change the compression preset to “max”.” imho unpolite.
In the open source/open data world changing the behaviour of a e.g. program is called feature request as a special kind of feedback.
Many (most?) open source/open data projects are driven by volunteers and some have paid workers. The volunteers spend their free time for things and if they are not interested, then it won’t be done. Even if there are paid workers they have rules how to spend their paid hours.
@sks2012 If there is nobody doing the job, do it on your own or wait at least imho a year after this thread has closed to repost this topic and link to this thread.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.