Android签名机制及PMS中校验签名

一、签名机制

众所周知，在Android系统中，应用想要安装到设备中，必须要有签名才行，及时是debug的时候，开发工具也会对要运行的应用自动签名，那么我们先来了解一下这个签名究竟是什么。

首先Android系统为了防止以安装的应用被篡改，推出来的签名自检机制，来维护应用的安全性，可以说，签名就是一个保护个人应用不受侵害的一种机制。而且这里面说道了自检，也就是说，在Android系统中，应用的签名在安装的过程中是自行检查的，这点在本文的下面会详细说道。

那么，我们先来了解一下Android签名的整个过程，这个过程大体可以分为三个步骤，也对应了Android系统在校验签名时的三个步骤：

1、android应用打包apk的时候，会先对应用中所有的文件进行遍历，做一次SHA1算法，也就是计算出文件的摘要信息，然后再用Base64进行编码，然后将这些信息写入到MANIFEST.MF文件中。这个文件在META-INF文件夹下面，解压APK文件时就会看见了。当然，在对APK所有文件进行SHA1算法的时候，是不包括META-INF文件夹的（这句是废话）。

下文是支付宝的MANIFEST.MF文件打开后的一部分（用记事本就可以打开）；

Manifest-Version: 1.0
Created-By: 1.7.0_67 (Oracle Corporation)
Name: assets/emoji/emoji_195.png
SHA1-Digest: 2YVKFrBF45WOANd9G7zdpbAm6w0=
Name: assets/emoji/emoji_356.png
SHA1-Digest: VlPA09nbS5e3iae9WvAMq8O88BM=
Name: res/layout/envelope_notify.xml
SHA1-Digest: r4LUgyo6YoeqTvKQUyME82+XINs=
Name: lib/armeabi/libsgavmp.so
SHA1-Digest: DOwWbBL42qy+Z16EggSnCNYseDI=

从上文中可以看出，在MANIFEST.MF文件中，针对应用中每个文件的SHA1算法都会以键值对的方式写入。这是为了防止APK内容被篡改。想要验证的话，可以通过安装HashTab软件（下载地址： http://www.baidu.com/s?wd=hashtab&rsv_spt=1&issp=1&f=8&rsv_bp=0&ie=utf-8&tn=baiduhome_pg&bs=hashtable ），然后找到对应的文件，右键用HashTab打开，就能看到对应的SHA1值，再到Base64网站上转码后对比一下就可以了（网址： http://tomeko.net/online_tools/hex_to_base64.php?lang=en ）。

2、第二个步骤是将上文的MANIFEST.MF文件进行一次SHA1计算，然后同样Base64转码后写入到CERT.SF文件中，然后读取MANIFEST.MF文件中子条目的值再次SHA1计算，Base64转码写入到这个文件中。这个步骤同下面的第三个步骤统称为签名，都是用的签名工具来完成的。

Signature-Version: 1.0
Created-By: 1.0 (Android SignApk)
SHA1-Digest-Manifest: zg9ZRuDj9mgYGA7zbHu5lysUuxc=
Name: assets/emoji/emoji_195.png
SHA1-Digest: +HilKtU8N3AsfscyZ/3uHBc/5n4=
Name: assets/emoji/emoji_356.png
SHA1-Digest: 50goYIrW1+7aVHdrwsihe5t06pY=
Name: res/layout/envelope_notify.xml
SHA1-Digest: 1qtgFSOLlupySOaKR7m9pEgYrZM=

上文是支付宝应用中CERT.SF文件中的部分内容，我们可以发现确实和MANIFEST.MF文件中的内容类似（有的朋友可能会觉得这个步骤是重复的，下文中我会进行解释）。

3、第三个步骤是关键的步骤了，也就是对APK进行加密的过程。我们在打包签名的时候，开发工具会让我们使用一个私钥文件，如果没有就会让我们去创建一个。在Eclipse中，默认格式是.keystore文件，而在Android Studio中默认格式是.jks文件。这两个文件都是私钥库文件，里面存储了一些信息，包括所有者、有效期、证书指纹及算法等。有了私钥文件后，就可以对第二个步骤中生成的CERT.SF文件进行加密了，加密后会生成CERT.RSA文件。在Android中，总共有两种签名工具，一个是jarsigner，需要的是.keystore文件，而另一个是signapk签名用的是pk8、x509.pem文件（keystore文件可以和pk8、x509.pem文件互相转化）。这两个签名工具不同的是，jarsigner签名后生成的.SF和.RSA的名字是私钥库中别名的名字，而signapk生成的两个文件名则是默认的CERT。

生成.keystore文件是用的keytool.exe生成的，这个文件在jdk的bin目录下。生成.keystore的指令如下（最好手打，有时候编码问题，直接复制不一定能过）：

keytool -genkey -v -keystore highball-key.keystore(文件名) -alias highball-key(别名) -keyalg RSA -keysize 2048 -validity 10000

查看私钥文件的指令如下：

keytool -list -keystore a.keystore(keystore文件) -alias a(别名) -v

从上图中可以看到私钥库文件中的内容。这个文件是签名机制中最重要的文件，一定要保存好，如果丢失，那么上架的应用想要更新可就麻烦了。

私钥文件已经有了，就可以对APK进行加密了。加密的指令如下：

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore a.keystore(keystore文件) a.apk(apk文件) a-key(别名)

其实这一个指令可以完成整个这三个步骤，因为要对应到Android系统的签名校验原理，所以分开来说明。

生成.RSA文件后用记事本打开是乱码的，可以将后缀名改成.p7r。然后就可以打开查看了，截图如下:



从上图可以看出.RSA文件包含了加密后的公钥和指纹，这两个信息是非常重要的，在Android系统对apk签名校验的时候也要用到。手动加密完之后最好对apk进行对其操作：

zipalign -v 4 a.apk  a-release.apk(新的apk的命名)

校验对齐是否成功：

zipalign -c -v 4 a-release.apk(apk名)

二、多重签名

Android系统是支持多重签名的，这是在签名校验时，系统只是对相同名的.SF文件和.RSA文件进行校验，而且是在while循环中进行的校验，也就是说可以不止一对.SF和.RSA文件，详情在下文中会有说明。

如果要进行多重签名，那么经过本人多次试验后得出的结果是，不能用Eclipse或者Android Studio签名后的apk来进行二次签名，而是要导出未签名的apk。

导出未签名的apk，在Android Studio的操作如下图所示：

在Gradle视图中，找到对应的项目下的assemble，执行双击操作，然后就会在module所在文件夹的outputs\apk文件夹中出现未签名的apk。这个操作很简单就不详细描述了，得到的apk文件中是没有META-INF文件夹的。

接下来就可以按照前文介绍的操作，生成两个密钥库文件（.keystore文件）。然后对未签名apk进行两次签名操作，得到了两次签名的apk文件，其META-INF文件夹内容如下：



从上图我们可以发现，MANIFEST.MF文件只有一个，而.SF和.RSA文件则是有两对，名字是对应密钥库文件的别名。OK多重签名就成功搞定了，下面来看看在Android系统中，是如何针对应用签名进行校验的。

三、Android签名校验

Android系统下，针对应用的安装是在PMS（Package Manager Service）中完成的， PMS是一个比较庞大的系统服务，我们今天只研究PMS中关于签名校验的部分。同apk签名三步骤相对应，PMS中对签名校验也是分成了三个步骤，先是 验证CERT.SF文件的摘要信息和CERT.RSA中的签名信息数据是否一致、验证MANIFEST.MF文件和CERT.SF文件是否匹配，最后是校验 APK 中每个文件的算法同 MANIFEST.MF 文件中是否一致。

1、校验CERT.SF文件和CERT.RSA文件

首先说明一下校验这两个文件的原理。Android系统对这两个文件的校验，是拿到.RSA文件的流对象，用ASN1解码后拿到签名数据，然后从签名信息中分别获取相关信息（发布机构、序列号、签名算法、公钥等）。然后通过公钥对签名进行解密，获得了解密后的数据同.SF文件进行对比。

Android 系统对应用的安装过程是在 PackageManagerService 类中通过发送 handler 来处理针对包的一些消息的 , 比如说清理安装包 , 发送安装等 , 其中针对签名校验也在这里处理。

在PackageManagerService.java中执行安装的方法是installPackageLI(args,res);在这个方法中获取了PackageParser对象，PackageParser.java是用来解析APK包的，也就是说签名信息校验的工作是在这个类中开始进行的。而执行校验的方法是PackageParser.java中的collectCertificates方法：

private static void collectCertificates(Package pkg, File apkFile, int flags)
throws PackageParserException {
final String apkPath = apkFile.getAbsolutePath();

StrictJarFile jarFile = null;
try {
jarFile = new StrictJarFile(apkPath);

// Always verify manifest, regardless of source
final ZipEntry manifestEntry = jarFile.findEntry(ANDROID_MANIFEST_FILENAME);
if (manifestEntry == null) {
throw new PackageParserException(INSTALL_PARSE_FAILED_BAD_MANIFEST,
"Package " + apkPath + " has no manifest");
}
...
}
}

这里面new了一个StrictJarFile对象，这个类的构造方法中完成了CERT.SF文件和CERT.RSA文件中关于证书的校验。因为在这个构造方法中有个Boolean类型的变量的赋值，就是完成证书校验的关键。那么我们看一下这个变量是如何赋值的：

public StrictJarFile(String fileName) throws IOException {
this.nativeHandle = nativeOpenJarFile(fileName);
this.raf = new RandomAccessFile(fileName, "r");

try {
// Read the MANIFEST and signature files up front and try to
// parse them. We never want to accept a JAR File with broken signatures
// or manifests, so it's best to throw as early as possible.
HashMap<String, byte[]> metaEntries = getMetaEntries();
this.manifest = new Manifest(metaEntries.get(JarFile.MANIFEST_NAME), true);
this.verifier = new JarVerifier(fileName, manifest, metaEntries);

isSigned = verifier.readCertificates() && verifier.isSignedJar(); //完成校验方法
} catch (IOException ioe) {
nativeClose(this.nativeHandle);
throw ioe;
}

guard.open("close");
}

从截图中可以看到，总共执行了两个方法，先看一下readCertificates方法：

synchronized boolean readCertificates() {
if (metaEntries.isEmpty()) {
return false;
}

Iterator<String> it = metaEntries.keySet().iterator();
while (it.hasNext()) {
String key = it.next();
if (key.endsWith(".DSA") || key.endsWith(".RSA") || key.endsWith(".EC")) {
verifyCertificate(key);
it.remove();
}
}
return true;
}

从方法中可以看出，这个方法首先判断一下是否有MANIFEST.MF文件，如果没有就返回false，那么isSigned就会被赋值为false（这个变量的赋值会在后续方法中作为校验的参数）。然后会去找证书文件，而在android的项目中，一般多采用的是RSA加密算法，也就是生成的.RSA文件，所以这个方法会把.RSA文件找到，执行verifyCertificate方法：

private void verifyCertificate(String certFile) {
// Found Digital Sig, .SF should already have been read
String signatureFile = certFile.substring(0, certFile.lastIndexOf('.')) + ".SF";
byte[] sfBytes = metaEntries.get(signatureFile);
if (sfBytes == null) {
return;
}

byte[] manifestBytes = metaEntries.get(JarFile.MANIFEST_NAME);
// Manifest entry is required for any verifications.
if (manifestBytes == null) {
return;
}

byte[] sBlockBytes = metaEntries.get(certFile);
try {
Certificate[] signerCertChain = JarUtils.verifySignature(
new ByteArrayInputStream(sfBytes),
new ByteArrayInputStream(sBlockBytes)); // 校验执行的位置
if (signerCertChain != null) {
certificates.put(signatureFile, signerCertChain);
}
} catch (IOException e) {
return;
} catch (GeneralSecurityException e) {
throw failedVerification(jarName, signatureFile);
}
...
}

这是方法的一部分，通过.RSA文件的名字找到对应的.SF文件，然后在获取MANIFEST.MF文件和.RSA文件,到这里三个文件就都拿到了。拿到三个文件数据后，会调用JarUtils.verifySignature方法, 这个方法,参数是.SF文件和.RSA文件的内存流对象;这个方法中通过用X509文件解析了.RSA文件,这个方法最终的目的是获取到RSA文件中的证书;然后同.SF文件的数据进行对比，如果不相同会抛出异常：

...
if (md == null && daName != null) {
md = MessageDigest.getInstance(daName);
}
if (md == null) {
return null;
}

byte[] computedDigest = md.digest(sfBytes);
if (!Arrays.equals(existingDigest, computedDigest)) {
throw new SecurityException("Incorrect MD");
}
...

然后回到JarVerifier.java的verifyCertificate方法中，会将之前拿到的签名数据封装到集合中：

...
if (signerCertChain != null) {
certificates.put(signatureFile, signerCertChain);
}
...

在创建StrictJarFile对象的时候，就完成了对.RSA和.SF文件的校验操作。

2 、校验MANIFEST.MF文件和.SF文件对应的摘要值

在JarVerifier.java中的verifyCertificate方法中,会继续执行校验MANIFEST.MF文件和.SF文件的操作:

private void verifyCertificate(String certFile) {
// Found Digital Sig, .SF should already have been read
...
// Verify manifest hash in .sf file
Attributes attributes = new Attributes();
HashMap<String, Attributes> entries = new HashMap<String, Attributes>();
try {
ManifestReader im = new ManifestReader(sfBytes, attributes);
im.readEntries(entries, null);
} catch (IOException e) {
return;
}

// Do we actually have any signatures to look at?
if (attributes.get(Attributes.Name.SIGNATURE_VERSION) == null) {
return;
}

boolean createdBySigntool = false;
String createdBy = attributes.getValue("Created-By");
if (createdBy != null) {
createdBySigntool = createdBy.indexOf("signtool") != -1;
}

// Use .SF to verify the mainAttributes of the manifest
// If there is no -Digest-Manifest-Main-Attributes entry in .SF
// file, such as those created before java 1.5, then we ignore
// such verification.
if (mainAttributesEnd > 0 && !createdBySigntool) {
String digestAttribute = "-Digest-Manifest-Main-Attributes";
if (!verify(attributes, digestAttribute, manifestBytes, 0, mainAttributesEnd, false, true)) {
throw failedVerification(jarName, signatureFile);
}
}

// Use .SF to verify the whole manifest.
String digestAttribute = createdBySigntool ? "-Digest" : "-Digest-Manifest";
if (!verify(attributes, digestAttribute, manifestBytes, 0, manifestBytes.length, false, false)) {
Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
while (it.hasNext()) {
Map.Entry<String, Attributes> entry = it.next();
Manifest.Chunk chunk = manifest.getChunk(entry.getKey());
if (chunk == null) {
return;
}
if (!verify(entry.getValue(), "-Digest", manifestBytes,
chunk.start, chunk.end, createdBySigntool, false)) {
throw invalidDigest(signatureFile, entry.getKey(), jarName);
}
}
}
metaEntries.put(signatureFile, null);
signatures.put(signatureFile, entries);
}

上面代码中,前面一部分基本是校验的准备工作,主要是封装数据,真正的校验操作是上文中的verify方法:

private boolean verify(Attributes attributes, String entry, byte[] data,
int start, int end, boolean ignoreSecondEndline, boolean ignorable) {
for (int i = 0; i < DIGEST_ALGORITHMS.length; i++) {
String algorithm = DIGEST_ALGORITHMS[i];
String hash = attributes.getValue(algorithm + entry);
if (hash == null) {
continue;
}

MessageDigest md;
try {
md = MessageDigest.getInstance(algorithm);
} catch (NoSuchAlgorithmException e) {
continue;
}
if (ignoreSecondEndline && data[end - 1] == '\n' && data[end - 2] == '\n') {
md.update(data, start, end - 1 - start);
} else {
md.update(data, start, end - start);
}
byte[] b = md.digest();
byte[] hashBytes = hash.getBytes(StandardCharsets.ISO_8859_1);
return MessageDigest.isEqual(b, Base64.decode(hashBytes));
}
return ignorable;
}

调用这个方法就完成了MANIFEST.MF文件和.SF文件的对比.

3、校验APK文件摘要值同MANIFEST.MF文件中对应值是否相同

接下来回到PackageParser.java中的collectCertificates方法，创建 StrictJarFile对象后， 会检查一下是否有清单文件（AndroidManifest.xml），如果没有则直接抛出异常。然后遍历查询到META-INF文件

private static void collectCertificates(Package pkg, File apkFile, int flags)
throws PackageParserException {
...

// Always verify manifest, regardless of source
final ZipEntry manifestEntry = jarFile.findEntry(ANDROID_MANIFEST_FILENAME);
if (manifestEntry == null) {
throw new PackageParserException(INSTALL_PARSE_FAILED_BAD_MANIFEST,
"Package " + apkPath + " has no manifest");
}

final List<ZipEntry> toVerify = new ArrayList<>();
toVerify.add(manifestEntry);

// If we're parsing an untrusted package, verify all contents
if ((flags & PARSE_IS_SYSTEM) == 0) {
final Iterator<ZipEntry> i = jarFile.iterator();
while (i.hasNext()) {
final ZipEntry entry = i.next();

if (entry.isDirectory()) continue;
if (entry.getName().startsWith("META-INF/")) continue;
if (entry.getName().equals(ANDROID_MANIFEST_FILENAME)) continue;

toVerify.add(entry);
}
}

// Verify that entries are signed consistently with the first entry
// we encountered. Note that for splits, certificates may have
// already been populated during an earlier parse of a base APK.
for (ZipEntry entry : toVerify) {
final Certificate[][] entryCerts = loadCertificates(jarFile, entry);
if (ArrayUtils.isEmpty(entryCerts)) {
throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES,
"Package " + apkPath + " has no certificates at entry "
+ entry.getName());
}
final Signature[] entrySignatures = convertToSignatures(entryCerts);

if (pkg.mCertificates == null) {
pkg.mCertificates = entryCerts;
pkg.mSignatures = entrySignatures;
pkg.mSigningKeys = new ArraySet<PublicKey>();
for (int i=0; i < entryCerts.length; i++) {
pkg.mSigningKeys.add(entryCerts[i][0].getPublicKey());
}
} else {
if (!Signature.areExactMatch(pkg.mSignatures, entrySignatures)) {
throw new PackageParserException(
INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES, "Package " + apkPath
+ " has mismatched certificates at entry "
+ entry.getName());
}
}
}
} catch (GeneralSecurityException e) {
throw new PackageParserException(INSTALL_PARSE_FAILED_CERTIFICATE_ENCODING,
"Failed to collect certificates from " + apkPath, e);
} catch (IOException | RuntimeException e) {
throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES,
"Failed to collect certificates from " + apkPath, e);
} finally {
closeQuietly(jarFile);
}
}

对toVerify集合遍历, 这里面涉及到了最关键的方法：loadCertificates方法。

private static Certificate[][] loadCertificates(StrictJarFile jarFile, ZipEntry entry)
throws PackageParserException {
InputStream is = null;
try {
// We must read the stream for the JarEntry to retrieve
// its certificates.
is = jarFile.getInputStream(entry);
readFullyIgnoringContents(is);
return jarFile.getCertificateChains(entry);
} catch (IOException | RuntimeException e) {
throw new PackageParserException(INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION,
"Failed reading " + entry.getName() + " in " + jarFile, e);
} finally {
IoUtils.closeQuietly(is);
}
}

先看一下getInputStream方法：

public InputStream getInputStream(ZipEntry ze) {
final InputStream is = getZipInputStream(ze);

if (isSigned) {
JarVerifier.VerifierEntry entry = verifier.initEntry(ze.getName());
if (entry == null) {
return is;
}

return new JarFile.JarFileInputStream(is, ze.getSize(), entry);
}

return is;
}

在这个方法中，显示根据isSigned进行判断（上文中已经说明），然后获取的VerifierEntry对象。在initEntry方法：

VerifierEntry initEntry(String name) {
...

ArrayList<Certificate[]> certChains = new ArrayList<Certificate[]>();
Iterator<Map.Entry<String, HashMap<String, Attributes>>> it = signatures.entrySet().iterator();
while (it.hasNext()) {
Map.Entry<String, HashMap<String, Attributes>> entry = it.next();
HashMap<String, Attributes> hm = entry.getValue();
if (hm.get(name) != null) {
// Found an entry for entry name in .SF file
String signatureFile = entry.getKey();
Certificate[] certChain = certificates.get(signatureFile);
if (certChain != null) {
certChains.add(certChain);
}
}
}

// entry is not signed
if (certChains.isEmpty()) {
return null;
}
Certificate[][] certChainsArray = certChains.toArray(new Certificate[certChains.size()][]);

for (int i = 0; i < DIGEST_ALGORITHMS.length; i++) {
final String algorithm = DIGEST_ALGORITHMS[i];
final String hash = attributes.getValue(algorithm + "-Digest");
if (hash == null) {
continue;
}
byte[] hashBytes = hash.getBytes(StandardCharsets.ISO_8859_1);

try {
return new VerifierEntry(name, MessageDigest.getInstance(algorithm), hashBytes,
certChainsArray, verifiedEntries);
} catch (NoSuchAlgorithmException ignored) {
}
}
return null;
}

这个方法的目的是构造VerifierEntry对象，所以这个方法主要进行的就是准备构建这个对象的参数。这些参数分别是要验证文件的名字。第二个是计算摘要的对象。第三个参数是对应文件的摘要值，从代码中可以看到是ISO_8859_1格式的。第四个参数是证书链。最后一个参数是已经验证过的文件列表。

VerifierEntry对象创建成功后，会返回JarFileInputStream流对象。然后回到PackageParser.java的loadCartificates方法中，会继续走到readFullyIgnoringContents方法：

public static long readFullyIgnoringContents(InputStream in) throws IOException {
byte[] buffer = sBuffer.getAndSet(null);
if (buffer == null) {
buffer = new byte[4096];
}

int n = 0;
int count = 0;
while ((n = in.read(buffer, 0, buffer.length)) != -1) {
count += n;
}

sBuffer.set(buffer);
return count;
}

这里面就是正常的读取 read;但是我们从第一点中知道 , 这个 InputStream 对象实际上是 JarInputStream 对象 , 所以这里面 read 执行的方法实际上是在 JarInputStream 中重写的 read 方法。

@Override
public int read(byte[] buffer, int byteOffset, int byteCount) throws IOException {
if (done) {
return -1;
}
if (count > 0) {
int r = super.read(buffer, byteOffset, byteCount);
if (r != -1) {
int size = r;
if (count < size) {
size = (int) count;
}
entry.write(buffer, byteOffset, size);
count -= size;
} else {
count = 0;
}
if (count == 0) {
done = true;
entry.verify();  // 校验MANIFEST.MF文件中数据和APK中每个文件的摘要值
}
return r;
} else {
done = true;
entry.verify();
return -1;
}
}

verify方法:

void verify() {
byte[] d = digest.digest();
if (!MessageDigest.isEqual(d, Base64.decode(hash))) {
throw invalidDigest(JarFile.MANIFEST_NAME, name, name);
}
verifiedEntries.put(name, certChains);
}

OK,通过这些方法的执行,便可以校验了APK中各文件摘要值同MANIFEST.MF中对应的值是否相同 。

最后回到PackageParser.java中的collectCertificates方法,下面这个方法是上文中所有方法的初始位置:

public void collectCertificates(Package pkg, int flags) throws PackageParserException {
pkg.mCertificates = null;
pkg.mSignatures = null;
pkg.mSigningKeys = null;

collectCertificates(pkg, new File(pkg.baseCodePath), flags);

if (!ArrayUtils.isEmpty(pkg.splitCodePaths)) {
for (String splitCodePath : pkg.splitCodePaths) {
collectCertificates(pkg, new File(splitCodePath), flags);
}
}
}

执行完了重载的collectCertificates方法后,会去判断是否是一次安装,如果不是第一次安装,会再次执行 collectCertificates方法,如果签名不一致,会抛出异常:

private static void collectCertificates(Package pkg, File apkFile, int flags)
throws PackageParserException {
...
for (ZipEntry entry : toVerify) {
final Certificate[][] entryCerts = loadCertificates(jarFile, entry);
if (ArrayUtils.isEmpty(entryCerts)) {
throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES,
"Package " + apkPath + " has no certificates at entry "
+ entry.getName());
}
final Signature[] entrySignatures = convertToSignatures(entryCerts);

if (pkg.mCertificates == null) {
pkg.mCertificates = entryCerts;
pkg.mSignatures = entrySignatures;
pkg.mSigningKeys = new ArraySet<PublicKey>();
for (int i=0; i < entryCerts.length; i++) {
pkg.mSigningKeys.add(entryCerts[i][0].getPublicKey());
}
} else {
if (!Signature.areExactMatch(pkg.mSignatures, entrySignatures)) {
throw new PackageParserException(
INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES, "Package " + apkPath
+ " has mismatched certificates at entry "
+ entry.getName());
}
}
}
} catch (GeneralSecurityException e) {
throw new PackageParserException(INSTALL_PARSE_FAILED_CERTIFICATE_ENCODING,
"Failed to collect certificates from " + apkPath, e);
} catch (IOException | RuntimeException e) {
throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES,
"Failed to collect certificates from " + apkPath, e);
} finally {
closeQuietly(jarFile);
}
}

总结一下,在APK签名的时候,首先会遍历APK所有的文件,生成对应的摘要数据写入到META-INF文件夹的MENIFEST.MF文件中,接下来会将MENIFEST.MF文件的摘要值和它里面每个数据块的值重新做一次摘要算法,然后写入到.SF文件中.最后是通过秘钥库文件对.SF文件进行加密,然后将公钥数据,签名数据等信息写入到.RSA文件中.如上便是android下对APK的签名机制.

而在android中对APK的签名校验则顺序相反,先是解开.RSA文件,提取公钥和签名数据,找到对应的.SF文件进行对比.然后进行MENIFEST.MF和.SF文件的对比,最后则是对apk中各个文件的摘要数据同MANIFEST.MF文件进行校验.不过在最后还会校验在覆盖安装的时候,会再次执行校验流程.