What is the role of apk files in Android system?

532 views
Skip to first unread message

Xuebin Zhang

unread,
Jul 22, 2015, 12:42:48 AM7/22/15
to android-platform
Hi All,

I met a very important problem in my work.

Is there anyone can explain the function of apk files in a Android App?

I remembered in early days, around 2011, the apk files can be deleted after installation to save up space. But it seems not true for today's system. We cannot delete the apk files even if this file type occupying a large storage space.
So I am wondering:
(1) Is apk file still necessary after installation of App? Will the application read this file when it is started? I run a block trace monitor and found that this apk file is not visited when the app is launching. We know that the apk file is a compressed format, it is used as installation package. So I guess it should be not necessary for app's start because if the app needs it, we need to use CPU to decompress such a large file and it seems it will be a big trouble for the app's launching.
(2) If it is not necessary. why the system doesn't allow the users to remove it? I managed to remove the apk file of Facebook and angrybird, the app cannot start then.

Any comments are appreciated! Thank you very much!!!


Sérgio Faria

unread,
Jul 22, 2015, 10:45:36 AM7/22/15
to android-...@googlegroups.com

Resources and assets are not extracted when installing, so the app always needs access to it.

I think classes.dex are not extracted to a different location, so you cannot delete that, as the dex may need to be optimized again.

The only thing that *may be* safe to delete in the zip file are libraries.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

Xuebin Zhang

unread,
Jul 22, 2015, 2:59:17 PM7/22/15
to android-platform
Hello Sérgio,

Thanks for your reply. 
Hum, yes, I checked the contents of related directories. It seems the resource pictures and assets are not extracted.
So the system will run a decompression to unpack the apk file when the App is started? Do you think it is a big trouble for the app starting?

And, for the dex file, I think it is extracted to /data/dalvik-cache when the app is installed.

Chris Tate

unread,
Jul 22, 2015, 3:22:49 PM7/22/15
to android-...@googlegroups.com
All of the decompression happens at install time, not runtime.  Icon assets etc. are stored uncompressed so they can be directly mmapped (shared) to limit memory footprint and optimize access time.

--
christopher tate


Xuebin Zhang

unread,
Jul 23, 2015, 11:59:09 AM7/23/15
to android-platform, ct...@google.com
Hi Chris,

Thanks for your explanations.
(1) If the assets are stored uncompressed in disk, why do we still need to keep the apk file?  I managed to pull an apk file out from the system, the app cannot be started again. And the apk file is indeed in a compressed format.(size will be expanded by 2X after decompression)
(2) And what's more, I didn't find the decompressed assets in system, i am not sure if I missed somewhere. So could you tell me where is the typical location to store the decompressed assets?

As far as I know, when an app is installed such as Facebook, 
(1)dex files will be extracted to /data/dalvik-cache/com.facebook.katana-1.dex
(2)library .so files will be extracted to data/app/com.facebook.katana-1/libs
(3) some cache files and sqlite files are located at: data/data/com.facebook.katana
(4) apk file will be kept at data/app/com.facebook.katana-1/base.apk

So I am not quite sure about your statement"uncompressed so they can be directly mmapped".
Could you explain a bit more about it?

Thanks and appreciated!

Dave Smith

unread,
Jul 23, 2015, 12:27:40 PM7/23/15
to android-platform, ct...@google.com, xuebinz...@gmail.com
Xuebin -

Your assessment of where extracted files are placed at install time (dex, native, etc.) is correct. The resources (drawable assets + XML) remain in the APK file and are read from it when needed. This is why you cannot remove the file.

Not everything inside of an APK is compressed. You can run zipinfo on any old APK file to see this. What you will notice is that the drawable assets (i.e. PNG files) and the resources.arsc file are not deflated, but simply stored uncompressed. These are the files that can be read and mapped directly. In particular, resources.arsc is important as it contains all the resource id lookups that an application will do frequently.

You may also notice that XML resources are stored deflated, and the AssetManager does uncompress them at runtime when the application requests that a resource be loaded (i.e. on-demand…they aren't all uncompressed at the same time when the app launches). Through several layers of abstraction, this boils down to the following native code in AssetManager.cpp (if you're interested). In the case of XML resources (like layouts, for example), the result of this read is cached; so the application only has to pay that cost once (disk read + uncompress).

--
Dave Smith, PE
@devunwired

Xuebin Zhang

unread,
Jul 24, 2015, 3:15:41 PM7/24/15
to android-platform, ct...@google.com, dasmi...@gmail.com
Hi Dave,

Thanks a lot for your informative reply! It is really helpful and makes a lot of sense.
I used zipinfo to look into the apk file and got a basic understanding of the apk content.

(1) I found the resources.arsc is deflated as well. in the zipinfo result, there is a "defN" mark for the resources.arsc. So it exists in a compressed format in the apk file.
However, I agree the way you described. I think this arsc file should be decompressed and extracted out like the lib and dex files, since it will be visited frequently. But I don't know why it is remained compressed in the package. And when an App is launched, the system seems needs to look up for this file first before it can load the assets/res files.

(2) So the resources.arsc works as a "mapping table" for this apk file, which provides a kind of "random read" feature for this semi-compressed file. When a resource/assets file is requested, we can locate its offset within this apk file. If we don't have such kind of lookup mapping table file, we have to uncompressed this whole package and keep all the uncompressed data in the memory, or we need to decompress this large file again.

(3) We already know that the dex file and lib files are extracted. I managed to remove the dex files and lib files from the apk file, and replace the original one. I found the App can be launched and running very well. So why does Android still keeps these file in the apk file? I guess it could be possible to add some code to the "android App installer" to save some storage space by removing the lib and dex files within apk.

Seems that I have too many questions...  :-)    
Thanks a lot for your patience to read it and I am appreciated very much..

Xuebin

Chris Tate

unread,
Jul 24, 2015, 3:40:41 PM7/24/15
to Xuebin Zhang, android-platform, dasmi...@gmail.com
Application updates are (when possible) deployed by Play Store as diff patches against the .apk file.  Modifying the APK as installed would break this capability.

--
christopher tate

Sérgio Faria

unread,
Jul 24, 2015, 5:56:32 PM7/24/15
to android-...@googlegroups.com
2015-07-24 19:03 GMT+01:00 Xuebin Zhang <xuebinz...@gmail.com>:
> (3) We already know that the dex file and lib files are extracted. I managed
> to remove the dex files and lib files from the apk file, and replace the
> original one. I found the App can be launched and running very well. So why
> does Android still keeps these file in the apk file? I guess it could be
> possible to add some code to the "android App installer" to save some
> storage space by removing the lib and dex files within apk.

/data/dalvik-cache holds the optimized dex (not classes.dex extracted
- check with sha1sum for example), which needs to be re-built when
Android is upgraded, so removing the dex file will break apps when the
system is upgraded. Removing classes.dex may also break apps that load
code of other apps (ex: some of those apps that have a free + paid
apk).

Xuebin Zhang

unread,
Jul 24, 2015, 8:53:14 PM7/24/15
to android-platform, sergi...@gmail.com

Oh, I see... 
To do a diff-patch based upgrade, the apk file in the client user end must be matched to the ones in the server end. 
So any customization of the apk file will lead to a upgrade failure, unless the sever is aware of this change.

Hi Sérgio's,
Yes you are corrected, the dex in dalvik is the optimized one. Thanks,
For the second point in your reply, I don't quite understand...
For example, if I need to call GoogleWallet from Yelp: when I install Yelp, I need the classes.dex of GoogleWallet?
Could you please explain a bit more on it?  Thank you..

Chris Tate

unread,
Jul 24, 2015, 9:25:47 PM7/24/15
to android-platform, sergi...@gmail.com
When the platform code changes (for example, when the system is updated via OTA), then every application on the device must be relinked / recompiled against the new OS binaries.  That's what is happening while the system presents the UI saying "Optimizing application N of M...".  This is only possible if the entire contents of the application APK files are still present.

--
chris


--
You received this message because you are subscribed to the Google Groups "android-platform" group.
Reply all
Reply to author
Forward
0 new messages