一、準備知識
在介紹簽名機制前，需要首先了解一下消息摘要、簽名文件、數字證書的知識。
1、消息摘要 - Message Digest
消息摘要（Message Digest），又稱數字摘要（Digital Digest）或數字指紋（Finger Print）。簡單來說，消息摘要就是在消息數據上，執行一個單向的Hash函數，生成一個固定長度的Hash值，這個Hash值即是消息摘要。關於這個Hash函數，我們來看看維基百科上的定義：
https://en.wikipedia.org/wiki/Cryptographic_hash_function
A cryptographic hash function is a special class of hash function that has certain properties which make it suitable for use in cryptography. It is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash function) which is designed to also be a one-way function, that is, a function which is infeasible to invert. The only way to recreate the input data from an ideal cryptographic hash function's output is to attempt a brute-force search of possible inputs to see if they produce a match, or use a rainbow table of matched hashes. Bruce Schneier has called one-way hash functions "the workhorses of modern cryptography".[1] The input data is often called the message, and the output (the hash value or hash) is often called the message digest or simply the digest.
The ideal cryptographic hash function has five main properties:
it is deterministic so the same message always results in the same hash
it is quick to compute the hash value for any given message
it is infeasible to generate a message from its hash value except by trying all possible messages
a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value
it is infeasible to find two different messages with the same hash value
Cryptographic hash functions have many information-security applications, notably in digital signatures, message authentication codes (MACs), and other forms of authentication. They can also be used as ordinary hash functions, to index data in hash tables, for fingerprinting, to detect duplicate data or uniquely identify files, and as checksums to detect accidental data corruption. Indeed, in information-security contexts, cryptographic hash values are sometimes called (digital) fingerprints, checksums, or just hash values, even though all these terms stand for more general functions with rather different properties and purposes.
A cryptographic hash function (specifically SHA-1) at work. A small change in the input (in the word "over") drastically changes the output (digest). This is the so-called avalanche effect.
上面提到的的加密Hash函數就是消息摘要算法。它有以下特徵：
-
無論輸入的消息有多長，計算出來的消息摘要的長度總是固定的。例如應用MD5算法摘要的消息有128個比特位，用SHA-1算法摘要的消息最終有160比特位的輸出，SHA-1的變體可以產生192比特位和256比特位的消息摘要。一般認爲，摘要的最終輸出越長，該摘要算法就越安全。
-
消息摘要看起來是“隨機的”。這些比特看上去是胡亂的雜湊在一起的。可以用大量的輸入來檢驗其輸出是否相同，一般，不同的輸入會有不同的輸出，而且輸出的摘要消息可以通過隨機性檢驗。但是，一個摘要並不是真正隨機的，因爲用相同的算法對相同的消息求兩次摘要，其結果必然相同；而若是真正隨機的，則無論如何都是無法重現的。因此消息摘要是“僞隨機的”。
-
消息摘要函數是單向函 數，即只能進行正向的信息摘要，而無法從摘要中恢復出任何的消息，甚至根本就找不到任何與原信息相關的信息。當然，可以採用強力攻擊的方法，即嘗試每一個 可能的信息，計算其摘要，看看是否與已有的摘要相同，如果這樣做，最終肯定會恢復出摘要的消息。但實際上，要得到的信息可能是無窮個消息之一，所以這種強力攻擊幾乎是無效的。
-
好的摘要算法，沒有人能從中找到“碰撞”，雖然“碰撞”是肯定存在的（由於長明文生成短摘要的Hash必然會產生碰撞）。即對於給定的一個摘要，不可能找到一條信息使其摘要正好是給定的。或者說，無法找到兩條消息，使它們的摘要相同。
正是由於以上特點，消息摘要算法被廣泛應用在“數字簽名”領域，作爲對明文的摘要算法。著名的消息摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的變體。
2、數字簽名 - Signature
數字簽名方案是一種以電子形式存儲消息簽名的方法。一個完整的數字簽名方案應該由兩部分組成：簽名算法和驗證算法。在講數字簽名之前，我們先簡單介紹幾個相關知識點：“公鑰密碼體制”、“對稱加密算法”、“非對稱加密算法”。
公鑰密碼體制(public-key cryptography)
公鑰密碼體制分爲三個部分，公鑰、私鑰、加密解密算法，它的加密解密過程如下：
-
加密：通過加密算法和公鑰對內容(或者說明文)進行加密，得到密文。加密過程需要用到公鑰。
-
解密：通過解密算法和私鑰對密文進行解密，得到明文。解密過程需要用到解密算法和私鑰。注意，由公鑰加密的內容，只能由私鑰進行解密，也就是說，由公鑰加密的內容，如果不知道私鑰，是無法解密的。
公 鑰密碼體制的公鑰和算法都是公開的(這是爲什麼叫公鑰密碼體制的原因)，私鑰是保密的。大家都以使用公鑰進行加密，但是隻有私鑰的持有者才能解密。在實際 的使用中，有需要的人會生成一對公鑰和私鑰，把公鑰發佈出去給別人使用，自己保留私鑰。目前使用最廣泛的公鑰密碼體制是RSA密碼體制。
對稱加密算法(symmetric key algorithms)
在對稱加密算法中，加密和解密都是使用的同一個密鑰。因此對稱加密算法要保證安全性的話，密鑰要做好保密，只能讓使用的人知道，不能對外公開。
非對稱加密算法(asymmetric key algorithms)
在非對稱加密算法中，加密使用的密鑰和解密使用的密鑰是不相同的。前面所說的公鑰密碼體制就是一種非對稱加密算法，他的公鑰和是私鑰是不能相同的，也就是說加密使用的密鑰和解密使用的密鑰不同，因此它是一個非對稱加密算法。
RSA簡介
RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。 由公鑰加密的內容可以並且只能由私鑰進行解密，而由私鑰加密的內容可以並且只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰都可以用來加密和解密，並且一方加密的內容可以由並且只能由對方進行解密。
加密：公鑰加密，私鑰解密的過程，稱爲“加密”。因爲公鑰是公開的，任何公鑰持有者都可以將想要發送給私鑰持有者的信息進行加密後發送，而這個信息只有私鑰持有者才能解密。
簽名： 私鑰加密，公鑰解密的過程，稱爲“簽名”。它和加密有什麼區別呢？因爲公鑰是公開的，所以任何持有公鑰的人都能解密私鑰加密過的密文，所以這個過程並不能 保證消息的安全性，但是它卻能保證消息來源的準確性和不可否認性，也就是說，如果使用公鑰能正常解密某一個密文，那麼就能證明這段密文一定是由私鑰持有者 發佈的，而不是其他第三方發佈的，並且私鑰持有者不能否認他曾經發布過該消息。故此將該過程稱爲“簽名”。
數字簽名
事實上，任何一個公鑰密碼體制都可以單獨地作爲一種數字簽名方案使用。如RSA作爲數字簽名方案使用時，可以定義如下：
這種簽名實際上就是用信源的私鑰加密消息，加密後的消息即成了籤體；而用對應的公鑰進 行驗證，若公鑰解密後的消息與原來的消息相同，則消息是完整的，否則消息不完整。它正好和公鑰密碼用於消息保密是相反的過程。因爲只有信源才擁有自己地私 鑰，別人無法重新加密源消息，所以即使有人截獲且更改了源消息，也無法重新生成籤體，因爲只有用信源的私鑰才能形成正確地籤體。同樣信宿只要驗證用信源的 公鑰解密的消息是否與明文消息相同，就可以知道消息是否被更改過，而且可以認證消息是否是確實來自意定的信源，還可以使信源不能否認曾經發送的消息。所以 這樣可以完成數字簽名的功能。
但這種方案過於單純，它僅可以保證消息的完整性，而無法確保消息的保密性。而且這種方案要對所有的消息進行加密操作，這在消息的長度比較大時，效率是非常低的，主要原因在於公鑰體制的加解密過程的低效性。所以這種方案一般不可取。
幾乎所有的數字簽名方案都要和快速高效的摘要算法（Hash函數）一起使用，當公鑰算法與摘要算法結合起來使用時，便構成了一種有效地數字簽名方案。
這個過程是：
-
用摘要算法對消息進行摘要。
-
再把摘要值用信源的私鑰加密。
通過以上兩步得到的消息就是所謂的原始信息的數字簽名，發送者需要將原始信息和數字簽名一同發送給接收者。而接收者在接收到原始信息和數字簽名後，通過以下3步驗證消息的真僞：
-
先把接收到的原始消息用同樣的摘要算法摘要，形成“準籤體”。
-
對附加上的那段數字簽名，使用預先得到的公鑰解密。
-
比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發送者發的，且內容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，消息不可信。
這種方法使公鑰加密只對消息摘要進行操作，因爲一種摘要算法的摘要消息長度是固定的，而且都比較“短”（相對於消息而言），正好符合公鑰加密的要求。這樣效率得到了提高，而其安全性也並未因爲使用摘要算法而減弱。
綜上所述，數字簽名是非對稱加密技術 + 消息摘要技術的結合。
3、數字證書 - Certificate
通過數字簽名技術，確實可以解決可靠通信的問題。一旦驗籤通過，接收者就能確信該消息是期望的發送者發送的，而發送者也不能否認曾經發送過該消息。大家有沒有注意到，前面講的數字簽名方法，有一個前提，就是消息的接收者必須事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當成好人，而真正的消息發送者給你發的消息會被你視作無效的。而且，很多時候根本就不具備事先溝通公鑰的信息通道。那麼如何保證公鑰的安全可信呢？這就要靠數字證書來解決了。
數字證書是一個經證書授權（Certificate Authentication）中心數字簽名的包含公鑰擁有者信息以及公鑰的文件。數字證書的格式普遍採用的是X.509V3國際標準，一個標準的X.509數字證書通常包含以下內容：
-
證書的發佈機構（Issuer）
- 該證書是由哪個機構（CA中心）頒發的。
-
證書的有效期（Validity）
- 證書的有效期，或者說使用期限。過了該日期，證書就失效了。
-
證書所有人的公鑰（Public-Key）
- 該證書所有人想要公佈出去的公鑰。
-
證書所有人的名稱（Subject）
- 這個證書是發給誰的，或者說證書的所有者，一般是某個人或者某個公司名稱、機構的名稱、公司網站的網址等。
-
證書所使用的簽名算法（Signature algorithm）
- 這個數字證書的數字簽名所使用的加密算法，這樣就可以使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。
-
證書發行者對證書的數字簽名（Thumbprint）
- 也就是該數字證書的指紋，用於保證數字證書的完整性，確保證書沒有被修改過。其原理就是在發佈證書時，CA機構會根據簽名算法（Signature algorithm）對整個證書計算其hash值（指紋）並和證書放在一起，使用者打開證書時，自己也根據簽名算法計算一下證書的hash值（指紋），如 果和證書中記錄的指紋對的上，就說明證書沒有被修改過。
可以看出，數字證書本身也用到了數字簽名技術，只不過簽名的內容是 整個證書（裏面包含了證書所有者的公鑰以及其他一些內容）。與普通數字簽名不同的是，數字證書的簽名者不是隨隨便便一個普通機構，而是CA機構。這就好像 你的大學畢業證書上簽名的一般都是德高望重的校長一樣。一般來說，這些CA機構的根證書已經在設備出廠前預先安裝到了你的設備上了。所以，數字證書可以保 證證書裏的公鑰確實是這個證書所有者的，或者證書可以用來確認對方的身份。可見，數字證書主要是用來解決公鑰的安全發放問題。
綜上所述，總結一下，數字簽名和簽名驗證的大體流程如下圖所示：
二、Android簽名機制
1、簽名工具
Android應用的簽名工具有兩種：jarsigner和signapk。它們的簽名算法沒什麼區別，主要是簽名使用的文件不同。
-
jarsigner：jdk自帶的簽名工具，可以對jar進行簽名。使用keystore文件進行簽名。生成的簽名文件默認使用keystore的別名命名。
-
signapk：Android sdk提供的專門用於Android應用的簽名工具。使用pk8、x509.pem文件進行簽名。其中pk8是私鑰文件，x509.pem是含有公鑰的文件。生成的簽名文件統一使用“CERT”命名。
既然這兩個工具都是給apk簽名的，那麼keystore文件和pk8,x509.pem他們之間是不是有什麼聯繫呢？答案是肯定的，他們之間是可以轉化的，這裏就不再分析如何進行轉化，網上的例子很多。
還有一個需要注意的知識點，如果我們查看一個keystore文件的內容，會發現裏面包含有一個MD5和SHA1摘要，這個就是keystore文件中私鑰的數據摘要，這個信息也是我們在申請很多開發平臺賬號時需要填入的信息。
2、簽名過程
首先我們任意選取一個簽名後的APK（SMSSDKSample-release.apk）解壓：
在META-INF文件夾下有三個文件：MANIFEST.MF、CERT.SF、CERT.RSA。它們就是簽名過程中生成的文件，姑且叫他們“簽名三兄弟”吧，把它們搞清楚了，你就精通簽名了。
（1）MANIFEST.MF
該 文件中保存的內容其實就是逐一遍歷apk中的所有條目，如果是目錄就跳過，如果是一個文件，就用SHA1（或者SHA256）消息摘要算法提取出該文件的 摘要然後進行BASE64編碼後，作爲“SHA1-Digest”屬性的值寫入到MANIFEST.MF文件中的一個塊中。該塊有一個“Name”屬性， 其值就是該文件在apk包中的路徑。
（2）CERT.SF
SHA1-Digest-Manifest-Main-Attributes：對MANIFEST.MF頭部的塊做SHA1（或者SHA256）後再用Base64編碼
SHA1-Digest-Manifest：對整個MANIFEST.MF文件做SHA1（或者SHA256）後再用Base64編碼
SHA1-Digest：對MANIFEST.MF的各個條目做SHA1（或者SHA256）後再用Base64編碼
對於SHA1-Digest值的驗證可以手動進行，將MANIFEST.MF中任意一個塊的內容複製並保存在一個新的文檔中，注意文末需要加兩個換行（這是由signapk的源碼決定的）
保存文件，然後對該文件計算其SHA1值後使用Base64編碼：
得到的值就是CERT.SF中相應條目的SHA1-Digest的值：
（3）CERT.RSA
這裏會把之前生成的 CERT.SF文件，用私鑰計算出簽名, 然後將簽名以及包含公鑰信息的數字證書一同寫入 CERT.RSA 中保存。這裏要注意的是，Android APK中的CERT.RSA證書是自簽名的，並不需要這個證書是第三方權威機構發佈或者認證的，用戶可以在本地機器自行生成這個自簽名證書。Android 目前不對應用證書進行 CA 認證。
什麼是自簽名證書
所謂自簽名證書是指自己給自己頒發的證書，即公鑰證書中Issuer（發佈者）和 Subject（所有者）是相同的。當然，APK也可以採用由CA頒發私鑰證書進行簽名。採用非自簽名時，最終APK的公鑰證書中就會包含證書鏈，並且會 存在多餘一個證書，證書間通過Issuer與Subject進行關聯，Issuer負責對Subject進行認證。當安裝APK時，系統只會用位於證書鏈 中最底層的證書對APK進行校驗，但並不會驗證證書鏈的有效性。在Https通信中使用自簽名證書時瀏覽器的顯示效果：
這裏我們看到的都是二進制文件，因爲RSA文件加密了，所以我們需要用openssl命令才能查看其內容：
openssl pkcs7 -inform DER -in /Users/jackie/Downloads/apk簽名機制/SMSSDKSample-release_new/original/META-INF/DEMOKEY_.RSA -text -noout -print_certs
關於這些信息，可以看下面這張圖：
綜上所述，一個完整的簽名過程如下所示：
3、簽名驗證過程
簽名驗證是發生在apk的安裝過程中，一共分爲三步：
（1）檢查apk中包含的所有文件，對應的摘要值與MANIFEST.MF文件中記錄的值一致。
（2）使用證書文件（RSA文件）檢驗簽名文件（SF文件）沒有被修改過。
（3）使用簽名文件（SF文件）檢驗MF文件沒有被修改過。
綜上所述，一個完整的簽名驗證過程如下所示：
爲什麼使用這樣的簽名流程呢？
我們假設一下，首先，如果你改變了apk包中的任何文件，那麼在apk安裝校驗時，改變後的文件摘要信息與MANIFEST.MF的檢驗信息不同，於是驗證失敗，程序就不能成功安裝。
其次，如果你對更改過的文件相應的算出新的摘要值，然後更改MANIFEST.MF文件裏面對應的屬性值，那麼必定與CERT.SF文件中算出的摘要值不一樣，照樣驗證失敗。
最後，如果你還不死心，繼續計算MANIFEST.MF的摘要值，相應的更改CERT.SF裏面的值，那麼數字簽名值必定與CERT.RSA文件中記錄的不一樣，還是失敗。
那麼能不能繼續僞造數字簽名呢？不可能，因爲沒有數字證書對應的私鑰。
三、APK Signature Scheme v2
在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。
APK 簽名方案 v2 是一種全文件簽名方案，該方案能夠發現對 APK 的受保護部分進行的所有更改，從而有助於加快驗證速度並增強完整性保證。
1、原因
爲什麼谷歌要做這個事情呢？第一點毋庸置疑，肯定是處於安全性的考慮，之前的校驗方式開發者可以在打包之後對apk做很多處理，第二爲了性能考慮，安裝校驗的時候不需要再解壓縮校驗，從而提升安裝速度。
2、v2帶來了什麼變化
由 於在 v1 僅針對單個ZIP條目進行驗證，因此，在 APK 簽署後可進行許多修改 - 可以移動甚至重新壓縮文件。事實上，編譯過程中要用到的 zipalign 工具就是這麼做的，它用於根據正確的字節限制調整 ZIP 條目，以改進運行時性能。而且我們也可以利用這個東西，在打包之後修改META-INF目錄下面的內容，或者修改Zip的註釋來實現多渠道的打包，在v1 簽名中都可以校驗通過。
v2 簽名將驗證歸檔中的所有字節，而不是單個 ZIP 條目，因此，在簽署後無法再運行 zipalign（必須在簽名之前執行）。正因如此，現在，在編譯過程中，Google將壓縮、調整和簽署合併成一步完成。
3、新的簽名方案就是一種擴展的Zip格式
使用 APK 簽名方案 v2 進行簽名時，會在 APK 文件中插入一個 APK 簽名分塊，該分塊位於“ZIP 中央目錄”部分之前並緊鄰該部分。在“APK 簽名分塊”內，v2 簽名和簽名者身份信息會存儲在 APK 簽名方案 v2 分塊中。
4、受完整性保護的內容
爲了保護APK內容，整個APK（zip文件格式）被分爲以下4個區塊：
-
ZIP 條目的內容（從偏移量 0 處開始一直到“APK 簽名分塊”的起始位置）
-
APK 簽名分塊
-
ZIP 中央目錄
-
ZIP 中央目錄結尾
APK 簽名方案 v2 負責保護第 1、3、4 部分的完整性，以及第 2 部分包含的“APK 簽名方案 v2 分塊”中的 signed data 分塊的完整性。
第 1、3 和 4 部分的完整性通過其內容的一個或多個摘要來保護，這些摘要存儲在 signed data 分塊中，而這些分塊則通過一個或多個簽名來保護。
5、新舊簽名方案的兼容
新的簽名格式向後兼容，因此，使用這種新格式簽名的 APK 可在更低版本的 Android 設備上進行安裝（會直接忽略添加到 APK 的額外數據），但前提是這些 APK 還帶有 v1 簽名。
驗 證程序會對照存儲在“APK 簽名分塊”中的 v2 簽名對 APK 的全文件哈希進行驗證。該哈希涵蓋除“APK 簽名分塊”（其中包含 v2 簽名）之外的所有內容。在“APK 簽名分塊”以外對 APK 進行的任何修改都會使 APK 的 v2 簽名作廢。v2
簽名被刪除的 APK 也會被拒絕，因爲 v1 簽名指明相應 APK 帶有 v2 簽名，所以 Android Nougat 及更高版本會拒絕使用 v1 簽名驗證 APK。這就是所謂的“防回滾保護”。
防回滾保護
攻擊者可能會試圖在支持對帶 v2 簽名的 APK 進行驗證的 Android 平臺上將帶 v2 簽名的 APK 作爲帶 v1 簽名的 APK 進行驗證。爲了防範此類攻擊，帶 v2 簽名的 APK 如果還帶 v1 簽名，其 META-INF/*.SF
文件的主要部分中必須包含 X-Android-APK-Signed 屬性。該屬性的值是一組以英文逗號分隔的 APK 簽名方案 ID（v2 方案的 ID 爲 2）。在驗證 v1 簽名時，對於此組中驗證程序首選的 APK 簽名方案（例如，v2 方案），如果 APK 沒有相應的簽名，APK 驗證程序必須要拒絕這些 APK。此項保護依賴於內容 META-INF/*.SF 文件受 v1 簽名保護這一事實。
6、新簽名方案v2對現存的渠道包生成工具的影響
之前的渠道包生成方案是通過在META-INF目錄下添加空文件，用空文件的名稱來作爲渠道的唯一標識。但在新的應用簽名方案下META-INF已經被列入了保護區了，向META-INF添加空文件的方案會對區塊1、3、4都會有影響。
另外一種比較流行的渠道包快速生成方案（修改Zip的註釋）也因爲上述原因，無法在新的應用簽名方案下進行正常工作。
如果新簽名方案v2後續改成強制要求，那現有的生成渠道包的方式就會無法工作，難道要退回到解放前嗎？
從 上面的描述可以看到，區塊1、3、4都是被保護的，任何針對這3個區塊的修改都會被新簽名方案v2檢測到，但區塊2（APK Signing Block）是不受簽名校驗規則保護的。美團的新一代打渠道包工具Walle就是往區塊2寫入一個自定義的ID-value，在App運行階段，可以通過 ZIP的EOCD（End of central directory）、Central directory等結構中的信息（涉及ZIP格式的相關知識，這裏不做展開描述）找到我們自己添加的ID-value，從而實現獲取渠道信息的功能，來 應對新簽名方案v2的。
四、知識點梳理
1、公鑰密碼體制：
-
公鑰密碼體制的公鑰和算法都是公開的，私鑰是保密的。一方加密的數據只能由另一方解密。
-
公鑰加密、私鑰解密，稱爲“加密”；私鑰加密、公鑰解密，稱爲“簽名”。公鑰密碼體制是目前唯一同時具備了加密與簽名功能的密碼體制。
2、消息摘要、數字簽名、數字證書的含義：
-
消息摘要又稱數字指紋，就是對一個消息做SHA/MD5算法，這個值是唯一的；
-
一個高效的數字簽名技術 = 消息摘要技術 + 非對稱加密技術（RSA算法）
-
數字證書中包含了證書持有者的信息、持有者的公鑰、證書籤發機構（CA）的信息、CA機構對證書本身的簽名信息以及其他一些信息，主要用於解決公鑰的安全發放問題
-
在Android簽名之後，其中SF就是簽名文件，RSA就是證書文件，我們可以用openssl來查看RSA文件中的證書信息和公鑰信息
-
Android APK中的CERT.RSA證書是自簽名的，並不需要這個證書是第三方權威機構發佈或者認證的
3、Android中的簽名有兩種方式：jarsigner和signapk。這兩種方式的區別是：
-
jarsigner簽名時，需要的是keystore文件，而signapk簽名的時候是pk8,x509.pem文件
-
jarsigner簽名之後的SF和RSA文件名默認是keystore的別名，而signapk簽名之後文件名是固定的:CERT
-
keystore文件和pk8,x509.pem文件之間可以互相轉化
4、新簽名方案v2：
-
v2是一種全文件簽名方案，對整個zip文件（包括zip元數據）進行簽名
-
v2方案下，zipalign需要在簽名之前執行
-
v2的簽名工具-apksigner，位於sdk的build-tools目錄下，但由於v2是Android7.0之後才推出的，所以只有版本>25的sdk中才能找到apksigner.jar
-
爲了兼容7.0以下設備，需要同時使用v1和v2簽名。此時，在7.0及以上設備中只會驗證v2簽名，如果試圖刪除v2簽名保留v1簽名，系統同樣會驗證不通過，即“防回滾保護”；而在7.0以下設備中，則只會驗證v1簽名
文/Mob開發者平臺 Android開發專家 魏士傑