Android的apk组成结构
APK 是 Android PacKage 的缩写,即 Android 安装包。将 APK 文件直接传到 Android 模拟器或 Android 手机中执行即可安装。 APK 文件其实是 zip 格式,但后缀名被修改为 apk ,在 windows 上可以通过 WinRar 等程序直接解压查看。
每个要安装到Android平台的应用都要被编译打包为一个单独的文件,后缀名为.apk,其中包含了应用的二进制代码、资源、配置文件等。APK文件其实是zip格式,但后缀名被修改为apk,
在Android 系统安装时,APK 程序会被存放在系统默认的APP 目录中。
文件或目录 |
作用 |
Assets目录 |
存放需要打包到APK的静态文件 |
META-INF/ |
也就是一个 manifest ,从 java jar 文件引入的描述包信息的目录,存放应用程序签名和证书,用来保证apk包的完整性和系统的安全性; |
res/ |
资源文件目录,存放应用程序的资源 |
libs/ |
如果存在的话,存放的是 ndk 编出来的 so 库,程序依赖的native库,包含针对特定处理器软件层的编译代码; |
AndroidManifest.xml |
程序全局配置文件,应用程序的配置文件,该文件包含了应用程序的名字,版本号,所需权限,注册服务、链接的其他应用程序,声明四大组件,以及调用信息等; |
classes.dex |
dalvik 字节码,可执行文件,包含应用程序的全部操作指令以及运行时数据,class.dex是由Java字节码转换的Dalvik字节码; |
resources.ars |
编译后的二进制资源文件,资源配置文件,APP资源能根据配置的变化,索引到相应的资源都要依赖它。 |
一般存放的是不会被编译处理的文件,一般是资源性质的文件或者配置文件; 存放需要打包到APK的静态文件,该目录与res目录不同之处在于,assets目录支持任意深度的子目录,我们的开发者可以根据自己的需求来任意部署文件夹的架构,而且res目录下的文件会在.R文件中生成与其对应的资源ID,,assets不会自动生成对应的id,访问的时候需要AssetManager类,
META-INF目录下存放的是签名信息,用来保证apk包的完整性和系统的安全。在eclipse编译生成一个apk包时,会对所有要打包的文件做一个校验计算,并把计算结果放在META-INF目录下。这就保证了apk包里的文件不能被随意替换。比如拿到一个apk包后,如果想要替换里面的一幅图片,一段代码, 或一段版权信息,想直接解压缩、替换再重新打包,基本是不可能的。如此一来就给病毒感染和恶意修改增加了难度,有助于保护系统的安全。
META-INF目录中包含的文件有CERT.RSA,CERT.DSA,CERT.SF和MANIFEST.MF。其中CERT.RSA是开发者利用私钥对APK进行签名的签名文件,CERT.SF和MANIFEST.MF记录了文件中文件的SHA-1哈希值。
软件修改后需要将里面的证书文件删除(***.RSA、***.SF、***.MF三个文件),否则软件无法安装。
res目录存放资源文件。包括图片,字符串等等。
res是resource的缩写,这个目录存放的东西是资源文件,存放这个文件夹下的所有文件都会和上文所说的,映射到Android工程中的.R文件中,生成对应的资源ID,访问的时候直接使用资源ID,即R.ID.FILENAME,res文件夹下可以包含多个文件夹;anim是存放动画文件的;drawable目录存放图形资源;layout目录存放布局文件;values目录存放一些特征值;colors.xml存放color的颜色值等等
*res/raw和assets的相同点: |
1.两者目录下的文件在打包后会原封不动的保存在apk包中,不会被编译成二进制。
*res/raw和assets的不同点:
1.res/raw中的文件会被映射到R.java文件中,访问的时候直接使用资源ID即R.id.filename;assets文件夹下的文件不会被映射到R.java中,访问的时候需要AssetManager类。
2.res/raw不可以有目录结构,而assets则可以有目录结构,也就是assets目录下可以再建立文件夹
目录 Directory |
资源类型 Resource Types |
res/anim/ |
Define pre-determined animations. Tween animations are saved in res/anim/ and accessed from the R.anim class. Frame animations are saved in res/drawable/ and accessed from the R.drawable class. 定义的是预置的动画对象。一般是逐帧动画 (Frame animations) 或补间动画( Tween animations )。而实际使用上,都是一些淡入淡出、缩放和移动等的补间动画居多。 |
res/color |
Define a color resources that changes based on the View state. Saved in res/color/ and accessed from the R.color class 定义一些 android view 状态变化时,使用的颜色值。这通常是绑定到一个界面元素上的,比如一个 button 被按下,弹起或 disable 时的颜色。 |
res/drawable/ res/drawable-hdpi res/drawable-land-hdpi res/drawable/mdpi res/drawable/ldpi res/drawable/port … |
Define various graphics with bitmaps or XML. Saved in res/drawable/ and accessed from the R.drawable class. 定义要被用到的位图资源文件。这些位图资源可以是 bitmap ,也可以是用 xml 描述的 bitmap 。 注意:文件后缀为 9.png 是一种特殊的位图,一般是通过 draw9patch 生成的,是一种可自动伸缩的位图资源。 Drawable 的其他目录形势, land 是横屏的, port 是竖屏的; hdpi 是高分辨率的, ldpi 是低分辨率的, hdpi 是高分辨率的。这里可以放置为特定情况下的界面优化资源。 |
res/layout/ |
Define the layout for your application UI. Saved in res/layout/ and accessed from the R.layout class. 定义的 UI layout ,被 aapt parser 后,可由 android 直接 render 成 view 界面。 这里也有横竖屏和 dpi 之分。 |
res/values/ |
可以被编译成很多种类型的资源的 XML 文件。 注意 : 不像其他的 res/ 文件夹,它可以保存任意数量的文件,这些文件保存了要创建资源的描述,而不是资源本身。 XML 元素类型控制这些资源应该放在 R 类的什么地方。 尽管这个文件夹里的文件可以任意命名,不过下面使一些比较典型的文件(文件命名的惯例是将元素类型包含在该名称之中): array.xml 定义数组 colors.xml 定义 color drawable 和 颜色的字符串值 (color string values) 。使用 Resource.getDrawable() 和 Resources.getColor() 分别获得这些资源。 dimens.xml 定义 尺寸值 (dimension value) 。使用 Resources.getDimension() 获得这些资源。 strings.xml 定义 字符串 (string) 值。使用 Resources.getString() 或者 Resources.getText() 获取这些资源。 getText() 会保留在 UI 字符串上应用的丰富的文本样式。 styles.xml 定义 样式 (style) 对象。 多国语言,由 values-xxx 的后缀组成。比如简体中文 :res/values-zh-rCN |
res/xml/ |
任意的 XML 文件,在运行时可以通过调用 Resources.getXML() 读取。 |
res/raw/ |
直接复制到设备中的任意文件。它们无需编译,添加到你的应用程序编译产生的压缩文件中。要使用这些资源,可以调用 Resources.openRawResource() ,参数是资源的 ID ,即 R.raw.somefilename 。 |
lib目录下的子目录armeabi存放的是一些so文件。这个地方多讲几句,都是在开发过程中摸索出来的。eclipse在打包的时候会根据文件名的命名规则(lib****.so)去打包so文件,开头和结尾必须分别为“lib”和“.so”,否则是不会打包到apk文件中的。其他非eclipse开发环境没有测试过。如果你是用SDK和NDK开发的话,这部分很重要,甚至可以通过把一些不是so文件的文件通过改名打包到apk中,具体能干些什么那就看你想干什么了,呵呵呵!
该目录用来存放应用程序所依赖的native库文件,native库一般是用C/C++进行编写的,这里的lib库可能包含4种不同类型,根据CPU型号的不同,我们大体可以分为ARM,ARM-v7a,MIPS,X86,分别对应着ARM架构,ARM-V7架构,MIPS架构和X86架构,这些so库在apk包中构成如上图:
其中,不同的CPU架构对应着不同的目录,每个目录中可以存放非常多的对应版本的so库,而且这个目录的结构固定,用户只能按照这个目录来存放自己的so库。目前市场上使用的移动终端大多是基于ARM或者ARM-v7a架构的。从厂家上来分是有三种,arm,x86,MIPS,arm 系列是绝大多数手机上使用的,x86 主要是运用在平板上,而 MIPS ,我基本上就没见过。
这是Android应用程序的配置文件,是一个用来描述Android应用“整体咨询”的设定文件,简单的说,这相对于Android应用向Android系统的“自我介绍”配置文件,Android系统可以根据Androidmanifest.xml文件来完整的了解这个APK应用程序的咨询。不难想到,每个Android应用程序都必须包含一个Androidmanifest.xml文件,并且它的名字是固定的,是禁止修改的。
该文件是每个应用都必须定义和包含的,它描述了应用的名字、版本、权限、引用的库文件等等信息[ , ],如要把apk上传到Google Market上,也要对这个xml做一些配置。在apk中的AndroidManifest.xml是经过压缩的,可以通过AXMLPrinter2工具[ , ]解开,
具体命令为:java -jar AXMLPrinter2.jar AndroidManifest.xml
在Android系统中,dex文件是可以直接在Dalvik虚拟机中加载运行的文件。通过ADT,经过复杂的编译,可以把java源代码转换为dex文 件。 那么这个文件的格式是什么样的呢?为什么Android不直接使用class文件,而采用这个不一样文件呢?其实它是针对嵌入式系统优化的结果,Dalvik虚拟机的指令码并不是标准的Java虚拟机指令码,而是使用了自己独有的一套指令集。如果有自己的编译系统,可以不生成class文件, 直接生成dex文件。dex文件中共用了很多类名称、常量字符串,使它的体积比较小,运行效率也比较高。但归根到底,Dalvik还是基于寄存器的虚拟机的一个实现。
DEX是Android系统的可执行文件,包括应用程序的全部操作指令,以及运行时数据。在程序编译过程中,java源文件先被编译成class文件,然后通过dx工具将多个class文件整合为一个dex文件,这样的文件结构使得各个类能够共享数据。
文件头(File Header)
Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。
字段名称 |
偏移值 |
长度 |
描述 |
magic |
0x0 |
8 |
'Magic'值,即魔数字段,格式如”dex/n035/0”,其中的035表示结构的版本。 |
checksum |
0x8 |
4 |
校验码。 |
signature |
0xC |
20 |
SHA-1签名。 |
file_size |
0x20 |
4 |
Dex文件的总长度。 |
header_size |
0x24 |
4 |
文件头长度,009版本=0x5C,035版本=0x70。 |
endian_tag |
0x28 |
4 |
标识字节顺序的常量,根据这个常量可以判断文件是否交换了字节顺序,缺省情况下=0x78563412。 |
link_size |
0x2C |
4 |
连接段的大小,如果为0就表示是静态连接。 |
link_off |
0x30 |
4 |
连接段的开始位置,从本文件头开始算起。如果连接段的大小为0,这里也是0。 |
map_off |
0x34 |
4 |
map数据基地址。 |
string_ids_size |
0x38 |
4 |
字符串列表的字符串个数。 |
string_ids_off |
0x3C |
4 |
字符串列表表基地址。 |
type_ids_size |
0x40 |
4 |
类型列表里类型个数。 |
type_ids_off |
0x44 |
4 |
类型列表基地址。 |
proto_ids_size |
0x48 |
4 |
原型列表里原型个数。 |
proto_ids_off |
0x4C |
4 |
原型列表基地址。 |
field_ids_size |
0x50 |
4 |
字段列表里字段个数。 |
field_ids_off |
0x54 |
4 |
字段列表基地址。 |
method_ids_size |
0x58 |
4 |
方法列表里方法个数。 |
method_ids_off |
0x5C |
4 |
方法列表基地址。 |
class_defs_size |
0x60 |
4 |
类定义类表中类的个数。 |
class_defs_off |
0x64 |
4 |
类定义列表基地址。 |
data_size |
0x68 |
4 |
数据段的大小,必须以4字节对齐。 |
data_off |
0x6C |
4 |
数据段基地址 |
魔数字段
魔数字段,主要就是Dex文件的标识符,它占用4个字节,在目前的源码里是 “dex\n”,它的作用主要是用来标识dex文件的,比如有一个文件也以dex为后缀名,仅此并不会被认为是Davlik虚拟机运行的文件,还要判断这 四个字节。另外Davlik虚拟机也有优化的Dex,也是通过个字段来区分的,当它是优化的Dex文件时,它的值就变成”dey\n”了。根据这四个字 节,就可以识别不同类型的Dex文件了。
跟在“dex\n”后面的是版本字段,主要用来标识Dex文件的版本。目前支持的版本号为“035\0”,不管是否优化的版本,都是使用这个版本号。
检验码字段
主要用来检查从这个字段开始到文件结尾,这段数据是否完整,有没有人修改过,或者传送过程中是否有出错等等。通常用来检查数据是否完整的算法,有 CRC32、有SHA128等,但这里采用并不是这两类,而采用一个比较特别的算法,叫做adler32,这是在开源zlib里常用的算法,用来检查文件 是否完整性。该算法由MarkAdler发明,其可靠程度跟CRC32差不多,不过还是弱一点点,但它有一个很好的优点,就是使用软件来计算检验码时比较 CRC32要快很多。可见Android系统,就算法上就已经为移动设备进行优化了。
SHA-1签名字段
dex文件头里,前面已经有了面有一个4字节的检验字段码了,为什么还会有SHA-1签名字段呢?不是重复了吗?可是仔细考虑一下,这样设计自有道理。因 为dex文件一般都不是很小,简单的应用程序都有几十K,这么多数据使用一个4字节的检验码,重复的机率还是有的,也就是说当文件里的数据修改了,还是很 有可能检验不出来的。这时检验码就失去了作用,需要使用更加强大的检验码,这就是SHA-1。SHA-1校验码有20个字节,比前面的检验码多了16个字 节,几乎不会不同的文件计算出来的检验是一样的。设计两个检验码的目的,就是先使用第一个检验码进行快速检查,这样可以先把简单出错的dex文件丢掉了, 接着再使用第二个复杂的检验码进行复杂计算,验证文件是否完整,这样确保执行的文件完整和安全。
map_off字段
这个字段主要保存map开始位置,就是从文件头开始到map数据的长度,通过这个索引就可以找到map数据。map的数据结构如下:
名称 |
大小 |
说明 |
size |
4字节 |
map里项的个数 |
list |
变长 |
每一项定义为12字节,项的个数由上面项大小决定。 |
编译后的二进制资源文件
用来记录资源文件和资源ID之间的映射关系,用来根据资源ID寻找资源。Android的开发是分模块的,res目录专门用来存放资源文件,当在代码中需要调用资源文件时,只需要调用方法“findviewbyid()”就可以得到资源文件,每当在res文件夹下放一个文件,aapt就会自动生成对应的ID保存在.R文件,我们调用这个ID就可以,但是只有这个ID还不够,.R文件只是保证编译程序不报错,实际上在程序运行时,系统要根据ID去寻找对应的资源路径,而resources.arsc文件就是用来记录这些ID和资源文件位置对应关系的文件。
----------------------------------------------------------------------------------------------------------------------------
Android 应用程序由各种组件组成,它们一起创建可工作的应用程序。Android有哪些组件呢?。下面一一介绍它们:
Activity组件是用户可以与之交互的可视界面。它可以包括按钮,图像, TextView 或任何其他可视组件;
Service组件在后台运行,并执行开发人员指定的特定任务。这些任务可以包括从 HTTP 下载文件到在后台播放音乐的任何内容;
Broadcast Receiver组件是 Android 应用程序中的接收器,通过Android 系统或设备中存在的其他应用程序,监听传入的广播消息。一旦它们接收到广播消息,就可以根据预定义的条件触发特定动作。条件可以为收到 SMS,来电呼叫,电量改变等等;
应用程序使用 Shared Preference组件,以便为应用程序保存小型数据集。此数据存储在名为 shared_prefs 的文件夹中。这些小数据集可以包括名值对,例如游戏中的用户得分和登录凭证。不建议在共享首选项中存储敏感信息,因为它们可能易受数据窃取和泄漏的影响。
Intent组件用于将两个或多个不同的 Android 组件绑定在一起。意图可以用于执行各种任务,例如启动动作,切换活动和启动服务。
内容供应器( Content Provider) :
Content Provider组件用于访问应用程序使用的结构化数据集。应用程序可以使用内容供应器访问和查询自己的数据或存储在手机中的数据。
Android 应用程序的生成过程,输入就是 eclipse 或源码中的工程及其下面的源文件;输出就是处理后的 apk 文件。整个过程可以如下图所示:
第一步:资源打包的工作,就是 aapt 这个工具完成的。
1. 在最后打包的 apk 中,所有的 xml 文件已经不是原来的文本文件了,是被 aapt parser 后,直接保存下来的 xml 数据结构,这样做的好处:到手机中无需再次 parser xml 文件,直接读到定义好的数据结构中就可以了。
2. drawable 中的 png 图片也被 aapt 给优化过了。
3. 所有的资源文件都被自动生成一个索引,并生成到 R.java 中。为什么这么做?我想一个是效率,另一个好处就是最大限度的在编译过程中由编译器给你找错 ( 通过 string 来索引很难做到 ) 。