Android系統(tǒng)簽名

有時(shí)候，我們開(kāi)發(fā)的apk需要用到系統(tǒng)權(quán)限，需要在AndroidManifest.xml中添加共享系統(tǒng)進(jìn)程屬性：

在連山等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專(zhuān)注、極致的服務(wù)理念，為客戶(hù)提供網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),營(yíng)銷(xiāo)型網(wǎng)站建設(shè),外貿(mào)網(wǎng)站制作,連山網(wǎng)站建設(shè)費(fèi)用合理。

這時(shí)候apk的簽名就需要是系統(tǒng)簽名(platform、shared或media)才能正常使用。

常用系統(tǒng)簽名方式

這種方式比較麻煩，你需要有編譯過(guò)的源碼環(huán)境，并按如下步驟：

1、拷貝App源碼到Android源碼的packages/apps/目錄下，且App源碼是普通(Eclipse)格式的

2、配置Android.mk，在其中添加

3、使用mm編譯App，生成的apk即系統(tǒng)簽名

這種方式比在源碼環(huán)境下簽名簡(jiǎn)單，App可以在Eclipse或Android Studio下編譯，然后給apk重新簽名即可。

但這種方式在頻繁調(diào)試的時(shí)候比較痛苦，即使寫(xiě)成腳本，也需要重復(fù)一樣的操作。

相關(guān)文件

platform.x509.pem、platform.pk8、signapk.jar

文件位置

platform.x509.pem、platform.pk8:

signapk.jar:

signapk源碼路徑:

簽名命令

步驟

1、將相關(guān)文件及源apk文件置于同一路徑下

2、檢查源apk包，去掉META-INF/CERT.SF 和 META-INF/CERT.RSA 文件

3、執(zhí)行簽名命令即可

讓Android Studio集成系統(tǒng)簽名，需要用到一個(gè)工具 keytool-importkeypair ，詳見(jiàn)下文。

這個(gè)工具的作用是將系統(tǒng)簽名的相關(guān)信息導(dǎo)入到已有的簽名文件里。

工具的使用方法可以通過(guò)–help或README.textile來(lái)尋求幫助

platform.x509.pem、platform.pk8、keytool-importkeypair、demo.jks、signature.sh

我的做法是在App根目錄新建Signature文件夾專(zhuān)門(mén)存放簽名相關(guān)文件。

步驟

1、生成demo.jks簽名文件

2、編寫(xiě)簽名腳本signature.sh，內(nèi)容如下：

為腳本文件添加可執(zhí)行權(quán)限：

執(zhí)行腳本：

3、配置builde.gradle

在android區(qū)域下(與defaultConfig同級(jí))添加配置：

這樣debug或release apk就帶有系統(tǒng)簽名了。

如果想直接Run app就是release版且?guī)到y(tǒng)簽名的apk，還需修改：

這樣直接Run app就是帶系統(tǒng)簽名的release版apk了。

Android查看應(yīng)用簽名方法

查看應(yīng)用簽名的MD5、SHA1、SHA256值及簽名算法。

查看keystore文件簽名信息，前提要有keystore文件和密鑰，才能夠獲取keystore文件的簽名信息。

方法一：（適用于 AS）

1)打開(kāi) AS工具窗口欄右邊的 Gradle - Project - app - Tasks - android - signingReport,雙擊運(yùn)行 signingReport;

在沒(méi)有keystore文件和密鑰的情況下,要想查看我們所需應(yīng)用的簽名信息,就需要借助 keytool 工具來(lái)完成。

首先解壓要查看的apk包,通過(guò)數(shù)據(jù)證書(shū)管理工具 keytool 查看apk的簽名信息。具體步驟如下：

1）將apk修改后綴為 .rar 文件后進(jìn)行解壓；

2）進(jìn)入解壓后的 META-INF 目錄，找到該目錄下的 xxx.RSA 文件；

3）通過(guò)命令 cmd 打開(kāi)DOS窗口，輸入命令 ： keytool -printcert -file [RSA文件路徑]

在查看應(yīng)用簽名信息過(guò)程中，可能會(huì)遇到以下幾個(gè)問(wèn)題：

定位 keytool.exe 工具所在的目錄，使用相關(guān)操作命令查看簽名信息；

JKS(Java KeyStore) ：是 Java 的 keytools 證書(shū)工具支持的證書(shū)私鑰格式。jks 包含了公鑰和私鑰，可以通過(guò) keytool 工具來(lái)將公鑰和私鑰導(dǎo)出。因?yàn)榘怂借€，所以 jks 文件通常通過(guò)一個(gè)密碼來(lái)加以保護(hù)。一般用于 Java 或者 Tomcat 服務(wù)器。

PKCS #12 ：定義了一種存檔文件格式，用于實(shí)現(xiàn)存儲(chǔ)許多加密對(duì)象在一個(gè)單獨(dú)的文件中。通常用它來(lái)打包一個(gè)私鑰及有關(guān)的 X.509 證書(shū)，或者打包信任鏈的全部項(xiàng)目。

定位 keytool.exe 工具所在的目錄，使用操作命令轉(zhuǎn)換證書(shū)格式；

Android V1及V2簽名原理簡(jiǎn)析

Android為了保證系統(tǒng)及應(yīng)用的安全性，在安裝APK的時(shí)候需要校驗(yàn)包的完整性，同時(shí)，對(duì)于覆蓋安裝的場(chǎng)景還要校驗(yàn)新舊是否匹配，這兩者都是通過(guò)Android簽名機(jī)制來(lái)進(jìn)行保證的，本文就簡(jiǎn)單看下Android的簽名與校驗(yàn)原理，分一下幾個(gè)部分分析下：

簽名是摘要與非對(duì)稱(chēng)密鑰加密相相結(jié)合的產(chǎn)物，摘要就像內(nèi)容的一個(gè)指紋信息，一旦內(nèi)容被篡改，摘要就會(huì)改變，簽名是摘要的加密結(jié)果，摘要改變，簽名也會(huì)失效。Android APK簽名也是這個(gè)道理，如果APK簽名跟內(nèi)容對(duì)應(yīng)不起來(lái)，Android系統(tǒng)就認(rèn)為APK內(nèi)容被篡改了，從而拒絕安裝，以保證系統(tǒng)的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對(duì)于V3的輪密先不考慮。先看下只有V1簽名后APK的樣式：

再看下只有V2簽名的APK包樣式：

同時(shí)具有V1 V2簽名：

可以看到，如果只有V2簽名，那么APK包內(nèi)容幾乎是沒(méi)有改動(dòng)的，META_INF中不會(huì)有新增文件，按Google官方文檔：在使用v2簽名方案進(jìn)行簽名時(shí)，會(huì)在APK文件中插入一個(gè)APK簽名分塊，該分塊位于zip中央目錄部分之前并緊鄰該部分。在APK簽名分塊內(nèi)， 簽名和簽名者身份信息會(huì)存儲(chǔ)在APK簽名方案v2分塊中，保證整個(gè)APK文件不可修改 ，如下圖：

而V1簽名是通過(guò)META-INF中的三個(gè)文件保證簽名及信息的完整性：

V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內(nèi)容，如果狹義上說(shuō)簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個(gè)文件其實(shí)是一套機(jī)制，不能單單拿一個(gè)來(lái)說(shuō)事，

如果對(duì)APK中的資源文件進(jìn)行了替換，那么該資源的摘要必定發(fā)生改變，如果沒(méi)有修改MANIFEST.MF中的信息，那么在安裝時(shí)候V1校驗(yàn)就會(huì)失敗，無(wú)法安裝，不過(guò)如果篡改文件的同時(shí)，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校驗(yàn)就可以繞過(guò)。

CERT.SF個(gè)人覺(jué)得有點(diǎn)像冗余，更像對(duì)文件完整性的二次保證，同繞過(guò)MANIFEST.MF一樣，.SF校驗(yàn)也很容易被繞過(guò)。

CERT.RSA與CERT.SF是相互對(duì)應(yīng)的，兩者名字前綴必須一致，不知道算不算一個(gè)無(wú)聊的標(biāo)準(zhǔn)。看下CERT.RSA文件內(nèi)容：

CERT.RSA文件里面存儲(chǔ)了證書(shū)公鑰、過(guò)期日期、發(fā)行人、加密算法等信息，根據(jù)公鑰及加密算法，Android系統(tǒng)就能計(jì)算出CERT.SF的摘要信息，其嚴(yán)格的格式如下：

從CERT.RSA中，我們能獲的證書(shū)的指紋信息，在微信分享、第三方SDK申請(qǐng)的時(shí)候經(jīng)常用到，其實(shí)就是公鑰+開(kāi)發(fā)者信息的一個(gè)簽名：

除了CERT.RSA文件，其余兩個(gè)簽名文件其實(shí)跟keystore沒(méi)什么關(guān)系，主要是文件自身的摘要及二次摘要，用不同的keystore進(jìn)行簽名，生成的MANIFEST.MF與CERT.SF都是一樣的，不同的只有CERT.RSA簽名文件。也就是說(shuō)前兩者主要保證各個(gè)文件的完整性，CERT.RSA從整體上保證APK的來(lái)源及完整性，不過(guò)META_INF中的文件不在校驗(yàn)范圍中，這也是V1的一個(gè)缺點(diǎn)。V2簽名又是如何保證信息的完整性呢？

前面說(shuō)過(guò)V1簽名中文件的完整性很容易被繞過(guò)，可以理解 單個(gè)文件完整性校驗(yàn)的意義并不是很大 ，安裝的時(shí)候反而耗時(shí)，不如采用更加簡(jiǎn)單的便捷的校驗(yàn)方式。V2簽名就不針對(duì)單個(gè)文件校驗(yàn)了，而是 針對(duì)APK進(jìn)行校驗(yàn) ，將APK分成1M的塊，對(duì)每個(gè)塊計(jì)算值摘要，之后針對(duì)所有摘要進(jìn)行摘要，再利用摘要進(jìn)行簽名。

也就是說(shuō)，V2摘要簽名分兩級(jí)，第一級(jí)是對(duì)APK文件的1、3 、4 部分進(jìn)行摘要，第二級(jí)是對(duì)第一級(jí)的摘要集合進(jìn)行摘要，然后利用秘鑰進(jìn)行簽名。安裝的時(shí)候，塊摘要可以并行處理，這樣可以提高校驗(yàn)速度。

APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對(duì)消息數(shù)據(jù)執(zhí)行一個(gè)單向Hash，從而生成一個(gè)固定長(zhǎng)度的Hash值，這個(gè)值就是消息摘要，至于常聽(tīng)到的MD5、SHA1都是摘要算法的一種。理論上說(shuō)，摘要一定會(huì)有碰撞，但只要保證有限長(zhǎng)度內(nèi)碰撞率很低就可以，這樣就能利用摘要來(lái)保證消息的完整性，只要消息被篡改，摘要一定會(huì)發(fā)生改變。但是，如果消息跟摘要同時(shí)被修改，那就無(wú)從得知了。

而數(shù)字簽名是什么呢（公鑰數(shù)字簽名），利用非對(duì)稱(chēng)加密技術(shù)，通過(guò)私鑰對(duì)摘要進(jìn)行加密，產(chǎn)生一個(gè)字符串，這個(gè)字符串+公鑰證書(shū)就可以看做消息的數(shù)字簽名，如RSA就是常用的非對(duì)稱(chēng)加密算法。在沒(méi)有私鑰的前提下，非對(duì)稱(chēng)加密算法能確保別人無(wú)法偽造簽名，因此數(shù)字簽名也是對(duì)發(fā)送者信息真實(shí)性的一個(gè)有效證明。不過(guò)由于Android的keystore證書(shū)是自簽名的，沒(méi)有第三方權(quán)威機(jī)構(gòu)認(rèn)證，用戶(hù)可以自行生成keystore，Android簽名方案無(wú)法保證APK不被二次簽名。

知道了摘要跟簽名的概念后，再來(lái)看看Android的簽名文件怎么來(lái)的？如何影響原來(lái)APK包？通過(guò)sdk中的apksign來(lái)對(duì)一個(gè)APK進(jìn)行簽名的命令如下：

其主要實(shí)現(xiàn)在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數(shù)，函數(shù)比較長(zhǎng)，分幾步分析

先來(lái)看這一步，ApkUtils.findZipSections，這個(gè)函數(shù)主要是解析APK文件，獲得ZIP格式的一些簡(jiǎn)單信息，并返回一個(gè)ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目錄信息、中央目錄結(jié)尾信息等，對(duì)比到zip文件格式如下：

獲取到 ZipSections之后，就可以進(jìn)一步解析APK這個(gè)ZIP包，繼續(xù)走后面的簽名流程，

可以看到先進(jìn)行了一個(gè)V2簽名的檢驗(yàn)，這里是用來(lái)簽名，為什么先檢驗(yàn)了一次？第一次簽名的時(shí)候會(huì)直接走這個(gè)異常邏輯分支，重復(fù)簽名的時(shí)候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應(yīng)該是為了排除V2簽名，并獲取V2簽名以外的數(shù)據(jù)塊，因?yàn)楹灻旧聿荒鼙凰闳氲胶灻校髸?huì)解析中央目錄區(qū)，構(gòu)建一個(gè)DefaultApkSignerEngine用于簽名

先解析中央目錄區(qū)，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名算法)，并構(gòu)建DefaultApkSignerEngine，默認(rèn)情況下V1 V2簽名都是打開(kāi)的。

第五步與第六步的主要工作是：apk的預(yù)處理，包括目錄的一些排序之類(lèi)的工作，應(yīng)該是為了更高效處理簽名，預(yù)處理結(jié)束后，就開(kāi)始簽名流程，首先做的是V1簽名（默認(rèn)存在，除非主動(dòng)關(guān)閉）：

步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創(chuàng)建META-INFO文件夾下的一些簽名文件，更新中央目錄、更新中央目錄結(jié)尾等，流程不復(fù)雜，不在贅述，簡(jiǎn)單流程就是：

這里特殊提一下重復(fù)簽名的問(wèn)題： 對(duì)一個(gè)已經(jīng)V1簽名的APK再次V1簽名不會(huì)有任何問(wèn)題 ，原理就是：再次簽名的時(shí)候，會(huì)排除之前的簽名文件。

可以看到目錄、META-INF文件夾下的文件、sf、rsa等結(jié)尾的文件都不會(huì)被V1簽名進(jìn)行處理，所以這里不用擔(dān)心多次簽名的問(wèn)題。接下來(lái)就是處理V2簽名。

V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對(duì)V1簽名過(guò)的APK進(jìn)行分塊摘要，再集合簽名，V2簽名不會(huì)改變之前V1簽名后的任何信息，簽名后，在中央目錄前添加V2簽名塊，并更新中央目錄結(jié)尾信息，因?yàn)閂2簽名后，中央目錄的偏移會(huì)再次改變：

簽名校驗(yàn)的過(guò)程可以看做簽名的逆向，只不過(guò)覆蓋安裝可能還要校驗(yàn)公鑰及證書(shū)信息一致，否則覆蓋安裝會(huì)失敗。簽名校驗(yàn)的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機(jī)優(yōu)先檢測(cè)V2簽名，如果V2簽名不存在，再校驗(yàn)V1簽名，對(duì)于7.0以下的手機(jī)，不存在V2簽名校驗(yàn)機(jī)制，只會(huì)校驗(yàn)V1，所以，如果你的App的miniSdkVersion24(N)，那么你的簽名方式必須內(nèi)含V1簽名：

校驗(yàn)流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗(yàn)APK自己的完整性以外，還要校驗(yàn)證書(shū)是否一致只有證書(shū)一致（同一個(gè)keystore簽名），才有可能覆蓋升級(jí)。覆蓋安裝同全新安裝相比較多了幾個(gè)校驗(yàn)

這里只關(guān)心證書(shū)部分：

Android V1及V2簽名簽名原理簡(jiǎn)析

僅供參考，歡迎指正

獲取Android應(yīng)用簽名的幾種方式

打開(kāi) Android Studio，然后選擇右邊的 Gradle 標(biāo)簽，選擇一個(gè)項(xiàng)目，然后選擇 signingReport 這個(gè) Task，雙擊運(yùn)行

然后選擇右下角的 Gradle Console，就可以看到簽名信息了

使用解壓工具解壓 APK 文件，在 META-INF 文件夾拿到 CERT.RSA 文件。假設(shè) CERT.RSA 文件的路徑是 C:\Users\Administrator\Desktop\CERT.RSA 。在 CMD 中輸入

就可以得到簽名信息了

jks 作為簽名文件，也可以通過(guò)命令行來(lái)查看的其中的簽名信息，假設(shè)簽名文件的名稱(chēng)是 test_release.jks ，在終端中輸入

即可得到簽名信息

Android APP的簽名

Android APP的簽名

Android項(xiàng)目以它的包名作為唯一的標(biāo)識(shí)，如果在同一部手機(jī)上安裝兩個(gè)包名相同的APP，后者就會(huì)覆蓋前面安裝的應(yīng)用。為了避免Android APP被隨意覆蓋，Android要求對(duì)APP進(jìn)行簽名。下面介紹對(duì)APP進(jìn)行簽名的步驟

1、選擇builder菜單下的Generate Signed APK

2、彈出簽名向?qū)?duì)話框

3、在該對(duì)話框中選擇數(shù)字證書(shū)，如果沒(méi)有數(shù)字證書(shū)，可以點(diǎn)擊Create new按鈕，創(chuàng)建數(shù)字證書(shū)如下圖所示：

4、輸入證書(shū)的存儲(chǔ)路徑及文件名稱(chēng)，密碼，有效年份，發(fā)布人員的姓名，單位，所在城市，省份，國(guó)家等信息，后點(diǎn)擊OK按鈕，如下圖所示，系統(tǒng)會(huì)自動(dòng)帶入密碼

5、點(diǎn)擊Next選擇簽名后的安裝包存放路徑，構(gòu)建類(lèi)型，點(diǎn)擊finish完成安裝包的構(gòu)建

注意：

v2是Android 7.0中引入了簽名版本，v1是jar Signature來(lái)自JDK，只勾選v1簽名并不會(huì)影響什么，但是在7.0上不會(huì)使用更安全的驗(yàn)證方式，只勾選V2簽名7.0以下會(huì)直接安裝完顯示未安裝，7.0以上則使用了V2的方式驗(yàn)證，為了保證兼容性，可以同時(shí)勾選V1和V2。

在Debug調(diào)試版本中，默認(rèn)會(huì)調(diào)用調(diào)試用的簽名證書(shū)debug.keystore，該證書(shū)默認(rèn)存放在C:\Users你的用戶(hù)名.android下。

包名和簽名都相同的APP才可以覆蓋安裝

android 系統(tǒng)簽名

也有提到怎么單獨(dú)給一個(gè)apk簽名，這里補(bǔ)充一下android的簽名權(quán)限控制機(jī)制。

android的標(biāo)準(zhǔn)簽名key有：

?testkey

?media

latform

hared

以上的四種，可以在源碼的/build/target/product/security里面看到對(duì)應(yīng)的密鑰，其中shared.pk8代表私鑰，shared.x509.pem公鑰，一定是成對(duì)出現(xiàn)的。

其中testkey是作為android編譯的時(shí)候默認(rèn)的簽名key，如果系統(tǒng)中的apk的android.mk中沒(méi)有設(shè)置LOCAL_CERTIFICATE的值，就默認(rèn)使用testkey。

而如果設(shè)置成：

LOCAL_CERTIFICATE := platform

就代表使用platform來(lái)簽名，這樣的話這個(gè)apk就擁有了和system相同的簽名，因?yàn)橄到y(tǒng)級(jí)別的簽名也是使用的platform來(lái)簽名，此時(shí)使用android:sharedUserId="android.uid.system"才有用！

?在/build/target/product/security目錄下有個(gè)README，里面有說(shuō)怎么制作這些key以及使用問(wèn)題（android4.2）：

?從上面可以看出來(lái)在源碼下的/development/tools目錄下有個(gè)make_key的腳本，通過(guò)傳入兩個(gè)參數(shù)就可以生成一對(duì)簽名用的key。

其中第一個(gè)為key的名字，一般都默認(rèn)成android本身有的，因?yàn)楹芏嗟胤蕉寄J(rèn)使用了這些名字，我們自定義的話只需要對(duì)第二個(gè)參數(shù)動(dòng)手腳，定義如下：

C --- Country Name (2 letter code) ST --- State or Province Name (full name) L --- Locality Name (eg, city) O --- Organization Name (eg, company) OU --- Organizational Unit Name (eg, section) CN --- Common Name (eg, your name or your server’s hostname) emailAddress --- Contact email addre

另外在使用上面的make_key腳本生成key的過(guò)程中會(huì)提示輸入password，我的處理是不輸入，直接enter，不要密碼！后面解釋?zhuān)米远x的key替換/security下面的。

可以看到android源碼里面的key使用的第二個(gè)參數(shù)就是上面README里面的，是公開(kāi)的，所以要release版本的系統(tǒng)的話，肯定要有自己的簽名key才能起到一個(gè)安全控制作用。

在上面提到如果apk中的編譯選項(xiàng)LOCAL_CERTIFICATE沒(méi)有設(shè)置的話，就會(huì)使用默認(rèn)的testkey作為簽名key，我們可以修改成自己想要的key，按照上面的步驟制作一個(gè)releasekey，修改android配置在/build/core/config.mk中定義變量：

在主makefile文件里面：

ifeq?($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/product/security/releasekey)

BUILD_VERSION_TAGS?+=?release-key

這樣的話默認(rèn)的所有簽名將會(huì)使用releasekey。

修改完之后就要編譯了，如果上面的這些key在制作的時(shí)候輸入了password就會(huì)出現(xiàn)如下錯(cuò)誤：

我在網(wǎng)上找到了合理的解釋?zhuān)?/p>

其實(shí)會(huì)出現(xiàn)這個(gè)錯(cuò)誤的最根本的原因是多線程的問(wèn)題。在編譯的時(shí)候?yàn)榱思铀僖话愣紩?huì)執(zhí)行make -jxxx，這樣本來(lái)需要手動(dòng)輸入密碼的時(shí)候，由于其它線程的運(yùn)行，就會(huì)導(dǎo)致影響當(dāng)前的輸入終端，所以就會(huì)導(dǎo)致密碼無(wú)法輸入的情況！

再編譯完成之后也可以在build.prop中查看到變量：

這樣處理了之后編譯出來(lái)的都是簽名過(guò)的了，系統(tǒng)才算是release版本

我發(fā)現(xiàn)我這樣處理之后，整個(gè)系統(tǒng)的算是全部按照我的要求簽名了。

網(wǎng)上看到還有另外的簽名release辦法，但是應(yīng)該是針對(duì)另外的版本的，借用學(xué)習(xí)一下：

make?-j4?PRODUCT-product_modul-user?dist

這個(gè)怎么跟平時(shí)的編譯不一樣,后面多了兩個(gè)參數(shù)PRODUCT-product_modul-user 和 dist. 編譯完成之后回在源碼/out/dist/目錄內(nèi)生成個(gè)product_modul-target_files開(kāi)頭的zip文件.這就是我們需要進(jìn)行簽名的文件系統(tǒng).

我的product_modul 是full_gotechcn,后面加“-user”代表的是最終用戶(hù)版本，關(guān)于這個(gè)命名以及product_modul等可參考

編譯出需要簽名的zip壓縮包之后，就是利用/security下面的準(zhǔn)備的key進(jìn)行簽名了：

./build/tools/releasetools/sign_target_files_apks?-d?/build/target/product/security??out/dist/full_gotechcn-target_files.zip???out/dist/signed_target_files.zi

簽名目標(biāo)文件 輸出成signed_target_files.zi

如果出現(xiàn)某些apk出錯(cuò)，可以通過(guò)在full_gotechcn-target_files.zip前面加參數(shù)"-e =" 來(lái)過(guò)濾這些apk.

然后再通過(guò)image的腳本生成imag的zip文件，這種方式不適用與我目前的工程源碼，沒(méi)有做過(guò)多驗(yàn)證！

Android簽名機(jī)制可劃分為兩部分：（1）ROM簽名機(jī)制；（2）第三方APK簽名機(jī)制。

Android APK實(shí)際上是一個(gè)jar包，而jar包又是一個(gè)zip包。APK包的簽名實(shí)際上使用的是jar包的簽名機(jī)制：在zip中添加一個(gè)META的子目錄，其中存放簽名信息；而簽名方法是為zip包中的每個(gè)文件計(jì)算其HASH值，得到簽名文件(*.sf)，然后對(duì)簽名文件(.sf)進(jìn)行簽名并把簽名保存在簽名塊文件(*.dsa)中。

在編譯Android源碼生成ROM的過(guò)程中，會(huì)使用build/target/product/security目錄中的4個(gè)key（media, platform, shared, testkey）來(lái)對(duì)apk進(jìn)行簽名。其中，*.pk8是二進(jìn)制形式（DER）的私鑰，*.x509.pem是對(duì)應(yīng)的X509公鑰證書(shū)（BASE64編碼）。build/target/product/security目錄中的這幾個(gè)默認(rèn)key是沒(méi)有密碼保護(hù)的，只能用于debug版本的ROM。

要生成Release版本的ROM，可先生成TargetFiles，再使用帶密碼的key對(duì)TargetFiles重新簽名，最后由重簽名的TargetFiles來(lái)生成最終的ROM。

可以使用Android源碼樹(shù)中自帶的工具“development/tools/make_key”來(lái)生成帶密碼的RSA公私鑰對(duì)（實(shí)際上是通過(guò)openssl來(lái)生成的）: $ development/tools/make_key media ‘/C=CN/ST=Sichuan/L=Chengdu/O=MyOrg/OU=MyDepartment/CN=MyName’ 上面的命令將生成一個(gè)二進(jìn)制形式（DER）的私鑰文件“media.pk8”和一個(gè)對(duì)應(yīng)的X509公鑰證書(shū)文件“media.x509.pem”。其中，/C表示“Country Code”，/ST表示“State or Province”，/L表示“City or Locality”，/O表示“Organization”，/OU表示“Organizational Unit”，/CN表示“Name”。前面的命令生成的RSA公鑰的e值為3，可以修改development/tools/make_key腳本來(lái)使用F4 (0×10001)作為e值（openssl genrsa的-3參數(shù)改為-f4）。

也可以使用JDK中的keytool來(lái)生成公私鑰對(duì)，第三方APK簽名一般都是通過(guò)keytool來(lái)生成公私鑰對(duì)的。

可以使用openssl x509命令來(lái)查看公鑰證書(shū)的詳細(xì)信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout

還可以使用JDK中的keytool來(lái)查看公鑰證書(shū)內(nèi)容，但其輸出內(nèi)容沒(méi)有openssl x509全面： $ keytool -printcert -v -file media.x509.pem

有了key之后，可以使用工具“build/tools/releasetools/sign_target_files”來(lái)對(duì)TargetFiles重新簽名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目錄中需要有四個(gè)key（media, platform, shared, releasekey）。注意：這里的releasekey將代替默認(rèn)的testkey（請(qǐng)參考build/tools/releasetools/sign_target_files腳本實(shí)現(xiàn)），也就是說(shuō)，如果某個(gè)apk的Android.mk文件中的LOCAL_CERTIFICATE為testkey，那么在生成TargetFiles時(shí)是使用的build/target/product/security/testkey來(lái)簽名的，這里重新簽名時(shí)將使用new_keys_dir/releasekey來(lái)簽名。

uild/tools/releasetools/sign_target_files_apks是通過(guò)host/linux-x86/framework/signapk.jar來(lái)完成簽名的。也可以直接使用host/linux-x86/framework/signapk.jar來(lái)對(duì)某個(gè)apk進(jìn)行簽名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，”-w”表示還對(duì)整個(gè)apk包(zip包）進(jìn)行簽名，并把簽名放在zip包的comment中。

對(duì)于第三方應(yīng)用開(kāi)發(fā)者而言，對(duì)APK簽名相對(duì)要簡(jiǎn)單得多。第三方應(yīng)用開(kāi)發(fā)一般采用JDK中的keytool和jarsigner來(lái)完成簽名密鑰的管理和APK的簽名。

使用keytool來(lái)生成存儲(chǔ)有公私鑰對(duì)的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000

查看生成的密鑰信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （注：獲取Base64格式的公鑰證書(shū)，RFC 1421）

導(dǎo)出公鑰證書(shū)： $ keytool -export -keystore mystore -alias mykey -file my.der （注：二進(jìn)制格式公鑰證書(shū)，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （注：Base64格式公鑰證書(shū)，PEM）

對(duì)APK進(jìn)行簽名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey

驗(yàn)證簽名： $ jarsigner -verify -verbose -certs my_application.apk

在進(jìn)行Android二次開(kāi)發(fā)時(shí)，有時(shí)需要把build/target/product/security下面的公私鑰對(duì)轉(zhuǎn)換為keystore的形式，可以參考這篇文章：把Android源碼中的密碼對(duì)轉(zhuǎn)換為keystore的方法。

文章標(biāo)題：android簽名,android簽名算法
當(dāng)前路徑：http://chinadenli.net/article41/dsgpsed.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、網(wǎng)站改版、ChatGPT、App設(shè)計(jì)、服務(wù)器托管、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)