apk打包流程

aapt给每一个非assets目录的资源定义一个资源ID，它是一个4字节（byte = 32bit）的数字，格式是PPTTNNNN，PP代表资源所属的包（package），TT代表资源的类型（Type），NNNN代表这个类型下面的资源名称（Entry ID）。

对签名后的apk进行解压缩，在META-INF目录下一般会有三个文件： MANIFEST.MF、CERT.SF和CERT.RSA 三个文件，这里用不同的证书和签名方式得到的名字可能不同。

APK包在安装的时候,是按照RSA->SF->MF的顺序依次校验的：**先用公钥信息还原签名信息，然后和.SF文件中的信息进行比对，然后用同样的摘要算法对.MF文件里的每一个条目计算对应的摘要信息，然后比对.MF是否一致。

缺点

简单来说，v2签名模式在原先apk块中添加了一个新的块（签名块），新的块存储了签名、摘要、签名算法、证书链和一些额外的属性等。这个块有特定的格式。

apk的格式签名后变成了下面4个部分

其中第三部分有一个偏移值直接指向了第二部分的开始位置，而每个第二部分如Central directory header1 .... Central directory header n 的有一个便宜字段指向了其中对应的第一部分。

签名块包括对apk第一部分、第二部分和第三部分的二进制内容做加密保护，摘要算法以及签名算法。签名块本身不做加密，这里需要特殊注意的是由于第三部分包含了对第二部分的引用偏移，因此如果签名块做了改变，比如在签名过程中增加了一种签名算法，或者增加签名者等信息就会导致这个偏移发生改变，因此在算摘要信息的时候需要剔除这个音粗要以第三部分对签名块的偏移来做计算。

接下来我们看看具体的apk签名块格式，改格式分为4个部分：

怎样找到v2分块的位置：ZIP中央结尾记录->中央目录其实偏移量->固定magic值，然后就可以定位v2分块的位置。

v2签名块负责保护第1、3、4部分的完整性，以及第二部分包含的APK签名方案 v2分块中的 signed data 分块的完整性。第1、3、4部分的完整性是通过内容摘要来保护的，这些摘要保存在 signed data 分块中，而 signed data 分块的完整性是通过签名保证的。下面开计算摘要的过程

第1、3和4部分的摘要要采用以下的计算方法

从上面我们可以知道v2模式块有点类似于

APK文件的组成部分及apk打包流程是Android开发中的基础知识点，做一个简单的记录。

apk文件是Android应用包文件格式，其本质是一个压缩文件。将apk文件拖动到Android Studio中即可查看里面的内容，如下图：

从上图中可以看到apk包里的几个重要组成部分：

打包流程的经典流程图如下：

其中七个椭圆形内容对应了打包流程中的七个重要步骤，也对应着打包中的七个重要工具，具体如下：

对上面七个重要的打包流程进一步说明。

aapt打包资源文件，生成R.java文件，resources.arsc等文件。

aapt在打包资源文件之前会检测 AndroidManifest.xml 文件的合法性，对res目录下的资源目录进行扫描合法性，因此资源命名有问题时会在编译阶段就会直接报错。

需要注意的是xml文件会被编译为二进制的，因此我们并不能直接打开apk包中的xml文件。

AIDL是Android接口定义语言，是Android进程间通讯的一种实现方式。

此步骤中会对aidl文件进行处理，生成java文件。

通过javaCompiler对java文件进行编译，生成class文件。

dx工具将class文件转变为Android系统Dalvik虚拟机可执行的Dex文件。

将classes.dex，res文件夹等所有文件打包成apk文件。

生成APK包之后还需要进行签名处理，Release签名需要我们自己去进行配置。

常用的签名方式有两种：jarsigner和apksigner。

Zipalign是Android平台上APK文件对齐的整理工具，能够对APK中未压缩的数据进行4字节对齐。

需要注意的是根据采用签名方式的不同，对齐处理的先后顺序有所区别。

APK打包流程备忘。

---