Update System.IO.Compression to use the best compression.

[dellis1972]

System.IO.Compression uses the default compression level which is not the Smallest compression level. This change updates the compression level to the best compression level since the size of the Apk is very important.

Unfortunately, the SmallestSize compression enum level is not available on netstandard2.0. So we have to use a cast to get it to work.

[jonathanpeppers]

We may want this one to actually test System.IO.Compression in main:

• #9840

[jonathanpeppers]

Should we make an MSBuild property to toggle the enum?

Then we could consider debug mode using a "fast" compression and Release doing a "slow" but small compression?

[jpobst]

We should probably have performance data on this to understand the tradeoffs. For a Debug build compression time is probably more important than compression size.

Also, the Release aab is going to be recompressed by Google so a few percent probably doesn't matter there either, but if it's significant then it might be useful.

Archive size differences between LibZipSharp and SIC are available on #9623.

[dellis1972]

We should probably have performance data on this to understand the tradeoffs. For a Debug build compression time is probably more important than compression size.

Also, the Release aab is going to be recompressed by Google so a few percent probably doesn't matter there either, but if it's significant then it might be useful.

Archive size differences between LibZipSharp and SIC are available on #9623.

Were there specific apps you got the differences in #9623 on? I should probably do the same ones

[dellis1972]

We do need to consider upload size for aab as well. A smaller package means less bandwidth, people do still pay for data.

[jonpryor]

Do we want or need this? As-is?

Is this codepath even used?

For example, we know that right now System.IO.Compression is broken for us; see also dotnet/runtime#113306

Given that, why were the PR checks green? This suggests that we're not using System.IO.Compression right now. (See also: 7454deb, f3ef4fe.)

I'm not sure what we should do with this PR right now.

[jpobst]

Using an existing quick and dirty test I already had that simulates adding all our assemblies to a packaged_resources zip:

Compression Level	Time	Size
NoCompression	149 ms	65408901 bytes
Fastest	390 ms	23281585 bytes
Optimal	1332 ms	17289885 bytes
SmallestSize	2979 ms	16876305 bytes

(Tested on .NET 9)

This appears to take more than double the compression time for 2-3% smaller zip files.

[jonpryor]

@jpobst wrote:

This appears to take more than double the compression time for 2-3% smaller zip files.

That might be worth it, depending on adb install/etc. time (reducing .apk size should speed up installation). Though 2% size reduction doesn't feel like it'll quite make up for doubling the time.

"Fastest" might be best.

[dellis1972]

I'm gonna close this. Looks like we need a way to configure this from the users perspective. So that for debug we use fastest but for release we use max or optimal.