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文件进行校验.不过在最后还会校验在覆盖安装的时候,会再次执行校验流程.