一、打包过程
- 打包流程:
-
aapt阶段:
- 使用aapt来打包res资源文件,生成R.java、resources.arsc和res文件(二进制 & 非二进制如res/raw和pic保持原样)
-
aidl阶段
- AIDL (Android Interface Definition Language), Android接口定义语言,Android提供的IPC (Inter Process Communication,进程间通信)的一种独特实现。这个阶段处理.aidl文件,生成对应的Java接口文件
-
Java Compiler阶段
- 通过Java Compiler编译R.java、Java接口文件、Java源文件,生成.class文件
-
dex 阶段
- 通过dex命令,将.class文件和第三方库中的.class文件处理生成classes.dex
-
apkbuilder阶段
-
将classes.dex、resources.arsc、res文件夹(res/raw资源被原装不动地打包进APK之外,其它的资源都会被编译或者处理)、Other Resources(assets文件夹)、AndroidManifest.xml打包成apk文件
-
res/raw和assets的相同点:两者目录下的文件在打包后会原封不动的保存在apk包中,不会被编译成二进制
-
res/raw中的文件会被映射到R.java文件中,访问的时候直接使用资源ID即R.id.filename;assets文件夹下的文件不会被映射到R.java中,访问的时候需要AssetManager类
-
-
-
Jarsigner阶段
- 对apk进行签名,可以进行Debug和Release 签名
-
通过zipalign工具,将签名后的apk进行对齐处理
二、签名过程
-
签名是什么
-
作用:①确保消息来源的真实性 ②确保消息不会被第三方篡改
-
在 APK 中写入一个「指纹」。指纹写入以后,APK 中有任何修改,都会导致这个指纹无效,Android 系统在安装 APK 进行签名校验时就会不通过,从而保证了安全性
-
-
如何实现签名
-
消息摘要
-
消息数据上,执行一个单向的 Hash 函数,生成一个固定长度的Hash值,这个Hash值即是消息摘要
-
消息摘要只能保证消息的完整性,并不能保证消息的不可篡改性
-
-
数字签名
-
一个完整的数字签名方案应该由两部分组成:签名算法和验证算法
-
RSA 密码体制是一种公钥密码体制,公钥公开,私钥保密,它的加密解密算法是公开的
-
-
数字证书
-
-
Android中的签名方案
-
V1:基于Jar签名
-
MANIFEST.MF : 逐一遍历 APK 中的所有条目,如果是目录就跳过,如果是一个文件,就用 SHA1(或者 SHA256)消息摘要算法提取出该文件的摘要然后进行 BASE64 编码
-
CERT.SF : 对MANIFEST.MF 进行进一步摘要
-
CERT.RSA : 会把之前生成的 CERT.SF 文件,用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存
-
签名过程
image-20191227114115764.png -
校验过程
image-20191227114146264.png -
签名校验速度慢
- 校验过程中需要对apk中所有文件进行摘要计算,在 APK 资源很多、性能较差的机器上签名校验会花费较长时间,导致安装速度慢
-
完整性保障不够
- META-INF 目录用来存放签名,自然此目录本身是不计入签名校验过程的,可以随意在这个目录中添加文件,比如一些快速批量打包方案就选择在这个目录中添加渠道文件
-
-
V2:Android7.0引入
-
全文件签名方案,能发现对Apk的受保护部分进行的所有更改,从而有助于加快验证速度并增强完整性保证
-
v2 签名模式在原先 APK 块中增加了一个新的块(签名块),新的块存储了签名,摘要,签名算法,证书链,额外属性等信息
-
就是把 APK 按照 1M 大小分割,分别计算这些分段的摘要,最后把这些分段的摘要在进行计算得到最终的摘要也就是 APK 的摘要。然后将 APK 的摘要 + 数字证书 + 其他属性生成签名数据写入到 APK Signing Block 区块
-
签名过程:
image-20191227113659513.png -
校验流程:
image-20191227113629363.png
-
-
V3:Android9.0引入
-
它的格式大体和 v2 类似,在 v2 插入的签名块(Apk Signature Block v2)中,又添加了一个新快(Attr块)
-
校验过程
image-20191227114029079.png
-
-
网友评论