小編在之前給大家介紹過很多android項目打包的經驗，本篇內容我們通過一個項目實例來給大家講解android每一步打包和簽名的過程。

android打包

以下是原理圖：

由android的項目經過編譯和打包，形成了:

.dex 文件

resources.arsc

uncompiled resources

AndroidManifest.xml

解壓了一個普通的apk文件，解壓出來的文件如下：

classes.dex 是.dex文件。resources.arsc是resources resources文件。AndroidManifest.xml是AndroidManifest.xml文件。res是uncompiled resources。META-INF是簽名文件夾。

其中resources.arsc相等于是資源文件的索引，方便查找資源文件

具體打包流程圖：

android簽名

android簽名后文件中多了個META-INF其中有三個文件：

下面分析一下3個文件的具體如何生成的apksinger：

1、MANIFEST.MF

逐一遍歷里面的所有條目，如果是目錄或者三個文件(MANIFEST.MF,CERT.RSA,CERT.SF)就跳過，如果是一個文件，就用SHA1（或者SHA256）消息摘要算法提取出該文件的摘要然后進行BASE64編碼后，作為“SHA1-Digest”屬性的值寫入到MANIFEST.MF文件中的一個塊中。該塊有一個“Name”屬性，其值就是該文件在apk包中的路徑。

2、CERT.SF：

1》計算這個MANIFEST.MF文件的整體SHA1值，再經過BASE64編碼后，記錄在CERT.SF主屬性塊（在文件頭上）的“SHA1-Digest-Manifest”屬性值值下

2》逐條計算MANIFEST.MF文件中每一個塊的SHA1，并經過BASE64編碼后，記錄在CERT.SF中的同名塊中，屬性的名字是“SHA1-Digest

3、CERT.RSA

這里會把之前生成的 CERT.SF文件， 用私鑰計算出簽名, 然后將簽名以及包含公鑰信息的數字證書一同寫入 CERT.RSA 中保存。CERT.RSA是一個滿足PKCS7格式的文件。

為何要這么來簽名

上面我們就介紹了簽名apk之后的三個文件的詳細內容，那么下面來總結一下，Android中為何要用這種方式進行加密簽名，這種方加密是不是最安全的呢？下面我們來分析一下，如果apk文件被篡改后會發生什么。

首先，如果你改變了apk包中的任何文件，那么在apk安裝校驗時，改變后的文件摘要信息與MANIFEST.MF的檢驗信息不同，于是驗證失敗，程序就不能成功安裝。

其次，如果你對更改的過的文件相應的算出新的摘要值，然后更改MANIFEST.MF文件里面對應的屬性值，那么必定與CERT.SF文件中算出的摘要值不一樣，照樣驗證失敗。

最后，如果你還不死心，繼續計算MANIFEST.MF的摘要值，相應的更改CERT.SF里面的值，那么數字簽名值必定與CERT.RSA文件中記錄的不一樣，還是失敗。

那么能不能繼續偽造數字簽名呢？不可能，因為沒有數字證書對應的私鑰。

所以，如果要重新打包后的應用程序能再Android設備上安裝，必須對其進行重簽名。

從上面的分析可以得出，只要修改了Apk中的任何內容，就必須重新簽名，不然會提示安裝失敗，當然這里不會分析，后面一篇文章會注重分析為何會提示安裝失敗。