转载自：http://blog.csdn.net/zengrun1992/article/details/40076767
APK是AndroidPackage的缩写，即Android安装包(apk)。APK是类似Symbian Sis或Sisx的文件格式。通过将APK文件直接传到Android模拟器或Android手机中执行即可安装。apk文件和sis一样，把android
sdk编译的工程打包成一个安装程序文件，格式为apk。 APK文件其实是zip格式，但后缀名被修改为apk，可以通过winrar等解压工具进行解压缩，进而进行汉化。
APK文件的结构如下图：
- META-INF
- res
- anim
- color
- drawable
- drawable-hdpi
- drawable-land
- drawable-land-hdpi
- drawable-mdpi
- drawable-port
- drawable-port-hdpi
- layout
- layout-land
- layout-port
- xml
- AndroidManifest.xml
- classes.dex
- resources.arsc
1、Manifest文件
AndroidManifest.xml是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等信息，如要把apk上传到Google Market上，也要对这个xml做一些配置。网上已有很多资料，在此就不多做介绍了。
在apk中的AndroidManifest.xml是经过压缩的，可以通过AXMLPrinter2工具解开，具体命令为：java -jar AXMLPrinter2.jar AndroidManifest.xml。
2、META-INF目录
META-INF目录下存放的是签名信息，用来保证apk包的完整性和系统的安全。
在eclipse编译生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。而在Android手机上安装apk包时，应用管理器会按照同样的算法对包里的文件做校验，如果校验结果与META-INF下的内容不一致，系统就不会安装这个apk。这就保证了apk包里的文件不能被随意替换。比如拿到一个apk包后，如果想要替换里面的一幅图片，一段代码， 或一段版权信息，想直接解压缩、替换再重新打包，基本是不可能的。如此一来就给病毒感染和恶意修改增加了难度，有助于保护系 统的安全。
软件修改后需要将里面的证书文件删除（***.RSA、***.SF、***.MF三个文件），否则软件无法安装。
3、classes.dex文件
在Android系统中，dex文件是可以直接在Dalvik虚拟机中加载运行的文件。通过ADT，经过复杂的编译，可以把java源代码转换为dex文 件。 那么这个文件的格式是什么样的呢？为什么Android不直接使用class文件，而采用这个不一样文件呢？其实它是针对嵌入式系统优化的结 果，Dalvik虚拟机的指令码并不是标准的Java虚拟机指令码，而是使用了自己独有的一套指令集。如果有自己的编译系统，可以不生成class文件， 直接生成dex文件。dex文件中共用了很多类名称、常量字符串，使它的体积比较小，运行效率也比较高。但归根到底，Dalvik还是基于寄存器的虚拟机 的一个实现。
文件头(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文件丢掉了， 接着再使用第二个复杂的检验码进行复杂计算，验证文件是否完整，这样确保执行的文件完整和安全。
SHA（Secure Hash Algorithm, 安全散列算法）是美国国家安全局设计，美国国家标准与技术研究院发布的一系列密码散列函数。SHA-1看起来和MD5算法很像，也许是Ron Rivest在SHA-1的设计中起了一定的作用。SHA-1的内部比MD5更强，其摘要比MD5的16字节长4个字节，这个算法成功经受了密码分析专家 的攻击，也因而受到密码学界的广泛推崇。这个算法在目前网络上的签名，BT软件里就有大量使用，比如在BT里要计算是否同一个种子时，就是利用文件的签名 来判断的。同一份8G的电影从几千BT用户那里下载，也不会出现错误的数据，导致电影不播放。
map_off字段
这个字段主要保存map开始位置，就是从文件头开始到map数据的长度，通过这个索引就可以找到map数据。map的数据结构如下：
| 名称 | 大小 | 说明 |
|---|---|---|
| size | 4字节 | map里项的个数 |
| list | 变长 | 每一项定义为12字节，项的个数由上面项大小决定。 |
4、res目录
res目录存放资源文件。
|
res/anim/ |
XML文件，它们被编译进逐帧动画（frame by frameanimation）或补间动画(tweenedanimation)对象 |
|
res/drawable/ |
.png、.9.png、.jpg文件，它们被编译进以下的Drawable资源子类型中： 要获得这种类型的一个资源，可以使用Resource.getDrawable(id) 为了获取资源类型，使用mContext.getResources().getDrawable(R.drawable.imageId) 注意：放在这里的图像资源可能会被aapt工具自动地进行无损压缩优化。比如，一个真彩色但并不需要256色的PNG可能会被转换为一个带调色板的8位PNG。这使得同等质量的图片占用更少的资源。所以我们得意识到这些放在该目录下的二进制图像在生成时可能会发生变化。如果你想读取一个图像位流并转换成一个位图(bitmap)，请把图像文件放在res/raw/目录下，这样可以避免被自动优化。 |
|
res/layout/ |
被编译为屏幕布局(或屏幕的一部分)的XML文件。参见布局声明(Declaring Layout) |
|
res/values/ |
可以被编译成很多种类型的资源的XML文件。
注意: 尽管这个文件夹里的文件可以任意命名，不过下面使一些比较典型的文件（文件命名的惯例是将元素类型包含在该名称之中）：
|
|
res/xml/ |
任意的XML文件，在运行时可以通过调用Resources.getXML()读取。 |
|
res/raw/
assets/ |
直接复制到设备中的任意文件。它们无需编译，添加到你的应用程序编译产生的压缩文件中。要使用这些资源，可以调用Resources.openRawResource()，参数是资源的ID，即R.raw.somefilename。 assets下也可以放置任意文件，使用Activity.this.getAssets().open("519.txt");打开 |
| *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目录下可以再建立文件夹
5、resources.arsc
编译后的二进制资源文件。通常本地化、汉化资源存储在该文件文件中。