Optimizing apk's

[Guest sm4tik]

While tweaking my CM7 build process, I started looking at the optimizing script of CM and found out it uses aapt for repackaging the apk's after optimizing it's png's. Apkmanager, which I've been using occationally, uses 7z for the same job and the resulting apk's are quite a lot smaller (for instance LatinIME shrinks from ~12M to ~7M). Can someone tell if there are any downsides for using 7z over aapt? I've had zero issues with using the apk's created with apkmanager.

[Guest Hjanos]

While tweaking my CM7 build process, I started looking at the optimizing script of CM and found out it uses aapt for repackaging the apk's after optimizing it's png's. Apkmanager, which I've been using occationally, uses 7z for the same job and the resulting apk's are quite a lot smaller (for instance LatinIME shrinks from ~12M to ~7M). Can someone tell if there are any downsides for using 7z over aapt? I've had zero issues with using the apk's created with apkmanager.

I don't know it, just an idea:

Because 7-zipped apk-s are smaller (it uses better compression), when the system needs to decompress them (when it needs a file), it can take more time and uses more cpu

[Guest PhenomHTX]

it's same like LPX or UPX compression in Windows Mobile exe/dll files.But everythink what you compressed , must be decompressed before go to RAM, so CPU must unpack apk and then load this in RAM (apk is decompressed in RAM also). So low compression = faster loading, more free RAM, less ROM memory.

[Guest sm4tik]

Thanks for the answers, I figured it would be like that. An interesting thing would be to see some benchmarks too, and also how much of a difference does it actually make in real life. I'm not questioning the outcome, I'm just interested in the "how much" part :)

BTW, the script in CM leaves .dict's uncompressed, that's why the huge difference in LatinIME.

[Guest wbaw]

7zip works better. All the apks are already compressed (badly), so I don't think that decompressing a badly decompressed apk will be any different to decompressing a well compressed one, it's still using the same zip deflate method. NAND is quite slow too, so if the apk is smaller it will take less time to read it from the nand. Even if it does take a little more cpu time or ram to to decompress, I'm fairly sure it's usually outweighed by the savings in NAND space & the saving in the time it takes to read from NAND as a result of that.

The dictionaries in LatinIME still work just fine if they're compressed.

I notice when i do a fresh install or after a reboot of CM7 there is a noticeable delay in loading the keyboard for the first time, there seems to be less of a delay if it's compressed smaller, but I've not timed it. It's only the first time that it gets loaded into ram. The ~5mb extra nand space is a bonus.

There is less to be gained from the other apks, but they could all be a bit smaller.

So, I don't see any real downsides, it seems to work a little faster & it uses less nand space. Just don't forget to use zipalign as the final step. I did it for all the apk, zip & jar files in GSF.

The only apk that I've had a problem with is voice search, no idea why but it just force closes if I try to recompress it.

Edited August 8, 2011 by wbaw

[Guest sm4tik]

7zip works better. All the apks are already compressed (badly), so I don't think that decompressing a badly decompressed apk will be any different to decompressing a well compressed one, it's still using the same zip deflate method. NAND is quite slow too, so if the apk is smaller it will take less time to read it from the nand. Even if it does take a little more cpu time or ram to to decompress, I'm fairly sure it's usually outweighed by the savings in NAND space & the saving in the time it takes to read from NAND as a result of that.

The dictionaries in LatinIME still work just fine if they're compressed.

I notice when i do a fresh install or after a reboot of CM7 there is a noticeable delay in loading the keyboard for the first time, there seems to be less of a delay if it's compressed smaller, but I've not timed it. It's only the first time that it gets loaded into ram. The ~5mb extra nand space is a bonus.

There is less to be gained from the other apks, but they could all be a bit smaller.

So, I don't see any real downsides, it seems to work a little faster & it uses less nand space. Just don't forget to use zipalign as the final step. I did it for all the apk, zip & jar files in GSF.

The only apk that I've had a problem with is voice search, no idea why but it just force closes if I try to recompress it.

Thanks wbaw, much appreciated your answer as it comes with a little experience as a bonus :)

I was using my mod of LatinIME earlier which was compressed with 7z and had no problems with it. That was actually the cause I started looking at the way CM does it's apk optimization.

I thought I'd edit the optimizing script in CM source by changing the zip method used, leaving the rest alone (maybe see if there are some ultimate options for pngcrush ;) ). Zipaling is the last thing in the script, so no problems there. I'll keep an eye on the voice search, thanks for the warning!

BTW, how about framework? Is it best to just leave it alone or can it be treated as other apk's?

edit: Never mind the framework thing, just realized it's compressed with the same script so I'll just test it and see..

Edited August 8, 2011 by sm4tik

[Guest wbaw]

optipng -o7 should be used for png files rather than pngcrush, just be careful with .9.png files. voicesearch is a google app, not included in cm7 anyway.

Edited August 8, 2011 by wbaw

[Guest sm4tik]

Thanks for the tip, I'll swap pngcrush to optipng tomorrow and test the results. Will have to rebuild anyway as some of my previous changes got lost in the jungle.. not that I had anything to do with it :P

[Guest sm4tik]

So I replaced pngcrush with optipng and the resulting apk's are not that much smaller. The whole /system/app got shrunk by 36K and framework-res.apk actually got 40K bigger :P I'll let it stay for now anyway, though it does take a while longer than with pngcrush (optipng -o7 vs. pngcrush with no options).

Edited August 9, 2011 by sm4tik

[Guest wbaw]

I thought optipng was based on pngcrush, but with some extra optimisations & pngcrush wasn't maintained much now, but looks like I was wrong, pngcrush is still maintained. It's not going to make a huge difference anyway & you could always use both. advpng (from advancecomp utils), pngout & deflopt can also work to squeeze a little bit more out of a png file, but the size difference is small.

[Guest sm4tik]

I thought optipng was based on pngcrush, but with some extra optimisations & pngcrush wasn't maintained much now, but looks like I was wrong, pngcrush is still maintained. It's not going to make a huge difference anyway & you could always use both. advpng (from advancecomp utils), pngout & deflopt can also work to squeeze a little bit more out of a png file, but the size difference is small.

No harm done, I like experimenting and knew the difference wasn't going to be that big afterall :) Changing the script succesfully was more important to me than the outcome and ofc I always have the choice to revert.

[Guest sm4tik]

I just checked how pngcrush (1.7.15) I'm using was built, and found a sed one-liner in the PKGBUILD (Arch Linux build file) that could make a difference too.

# fix for better compression

sed -i 's|TOO_FAR 4096|TOO_FAR 32767|' deflate.c

It might be this is a change that will be included in the next release, I haven't checked the current source. This could explain why the difference was as small as it was, including the surprise it still is being developed. Wbaw, if you're reading this, you might want to try it out too as it's waaay faster than optipng -o7 :)

[Guest wbaw]

You can use both, optipng will only rewrite the file if it can make it smaller. Different png files will compress differently using different tools, so I use a few in sequence. I also use advpng, pngout & deflopt. I don't care how long it takes to compress & I have a fairly fast pc.

advzip will recompress a zip file using 7zip, only rewriting the file if it makes it smaller, although I think it lags behind the latest 7zip. Deflopt will also squeeze a few more bytes out of anything that uses deflate compression (zip, png, pdf, apk, jar, gz).

zipalign should always be the final optimisation step for zip, apk & jar files. it (may) add a little to the file size, but it should make decompression faster.

Edited August 12, 2011 by wbaw

[Guest sm4tik]

Well, that's a bunch of apps to sqeeze all the air out of those apk's :) I'll look into those little utils you mentioned with interest, they seem quite useful not only for this exploration but in general also. (..well maybe not for the average user ;) ) And I didn't know optipng only rewrites the file if it can make it smaller.

Thanks again, your help is much appreciated!