res PNG filesize inflated upon packaging

by piecewise » Mon, 04 May 2009 09:22:01 GMT


Sponsored Links
 I've got ~200 png files in the /res/drawable folder, mostly interface
and sprite sheet stuff. They're all indexed pngs, and weigh in at a
grand total of a bit over 400kb.

When I run aapt to package them into the apk, their filesize nearly
doubles. Opening the apk up with 7zip and extracting the drawables
confirms it: 790kb.

Does anyone have any idea why this would be happening? I thought the
packaging process was meant to compress the pngs, not inflate them! :P

Cheers,
Tom
--~--~---------~--~----~------------~-------~--~----~



res PNG filesize inflated upon packaging

by piecewise » Mon, 04 May 2009 12:03:34 GMT


 Further research reveals that aapt is indeed un-indexing the PNGs.
Once packed, they're back in full RGB mode.

I can get around this by deleting res/drawable from the .apk before
signing and dumping the original in, but this is a bit of a PITA.

I've had a look at the commandline switches for aapt: -0 says "don't
compress files" but that still doesn't affect the de-indexing of my
pngs!
--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


res PNG filesize inflated upon packaging

by Jeff Sharkey » Mon, 04 May 2009 13:41:29 GMT


 Is the compressed APK size comparable to the 400kB original size?  The
790kB you quoted seems to be the unpacked size.  On the device,
resources are kept in their compressed state.  Also, I believe that
aapt in 1.5 runs drawables through pngcrush, so I'm not sure why they
are growing.

j







-- 
Jeff Sharkey
jshar...@google.com

--~--~---------~--~----~------------~-------~--~----~



res PNG filesize inflated upon packaging

by piecewise » Mon, 04 May 2009 15:01:11 GMT


 In the compressed APK they're still 790kb. I... uh... I don't know why
I said "extracting", earlier. I just meant viewing them in 7-zip. It's
Monday. :P

It's mostly an academic issue now anyway, as I've modified our ant
script to use 7-zip's commandline interface to manually extract the
RGB png's and replace them with the indexed ones. A bit hacky, I know,
but it works ok!

I'm still curious as to why this is going on, though. I'm not using
1.5; I'm only using 1.1. Is it possible that aapt in 1.1 uses pngcrush
as well, and is for some reason changing the colour mode of the pngs
from indexed to full RGB?

Cheers,
Tom





--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. tabbed InfoWindow

hello
I would like to know how to make this application.



when the user selects a location it appears 'tabbed InfoWindow'
containing the information.

thanks

-- 

2. Subclass android.app.Application to save global state?

I want a handle to my sqlite database to be available to many activities.
I read about subclassing Application, and storing things there.  Then I
should be able to get them through getApplicationContext().  An article
explaining this says that I must "specify that class in the application
tag in your manifest".  What would that <application> tag attribute look
like?

Also, in the docs for android.app.Application, this is said:

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more 
modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can 
be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.


I don't really understand this, although I know what a singleton is.

Also, if android reclaims my apps memory after a long period of disuse,
does the app actually have to start up again from scratch when it comes back?
Can there be no static state through that process?

Thanks,

Tobiah

--

3. Android WebView

4. Help me about publish fee

5. [WTI] komik 3D

6. "Failed to find provider info for" ContentProvider

7. NPAPI plugin support