安卓簽名有什麼好處
① Android簽名機制之簽名文件和數字證書的作用
Android簽名機制目的是確保app的可靠通信，其一，要確定消息的來源確實是其申明
的那個人；其二，要保證信息在傳遞的過程中不被第三方篡改，即使被篡改了，也可以
發覺出來。
所謂數字簽名，就是為了解決這兩個問題而產生的，它是對非對稱加密技術與數字摘要
技術的一個具體的應用。
對於消息的發送者來說，先要生成一對公私鑰對，將公鑰給消息的接收者。
如果消息的發送者有一天想給消息接收者發消息，在發送的信息中，除了要包含原始的
消息外，還要加上另外一段消息。這段消息通過如下兩步生成：
1）對要發送的原始消息提取消息摘要；
2）對提取的信息摘要用自己的私鑰加密。
通過這兩步得出的消息，就是所謂的原始信息的數字簽名。
而對於信息的接收者來說，他所收到的信息，將包含兩個部分，一是原始的消息內容，
二是附加的那段數字簽名。他將通過以下三步來驗證消息的真偽：
1）對原始消息部分提取消息摘要，注意這里使用的消息摘要演算法要和發送方使用的一致；
2）對附加上的那段數字簽名，使用預先得到的公鑰解密；
3）比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發送者
發的，且內容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，
消息不可信。
通過這種所謂的數字簽名技術，確實可以有效解決可靠通信的問題。如果原始消息在傳
送的過程中被篡改了，那麼在消息接收者那裡，對被篡改的消息提取的摘要肯定和原始
的不一樣。並且，由於篡改者沒有消息發送方的私鑰，即使他可以重新算出被篡改消息
的摘要，也不能偽造出數字簽名。
那麼數字簽名呢？
綜上所述，數字簽名其實就是只有信息的發送者才能產生的別人無法偽造的一段數字
串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。
不知道大家有沒有注意，前面講的這種數字簽名方法，有一個前提，就是消息的接收者
必須要事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當成好
人，而真正的消息發送者給你發的消息會被你視作無效的。而且，很多時候根本就不具
備事先溝通公鑰的信息通道。那麼如何保證公鑰的安全可信呢？這就要靠數字證書來解
決了。
所謂數字證書，一般包含以下一些內容：
證書的發布機構（Issuer）
證書的有效期（Validity）
消息發送方的公鑰
證書所有者（Subject）
數字簽名所使用的演算法
數字簽名
可以看出，數字證書其實也用到了數字簽名技術。只不過要簽名的內容是消息發送方的
公鑰，以及一些其它信息。但與普通數字簽名不同的是，數字證書中簽名者不是隨隨便
便一個普通的機構，而是要有一定公信力的機構。這就好像你的大學畢業證書上簽名的
一般都是德高望重的校長一樣。一般來說，這些有公信力機構的根證書已經在設備出廠
前預先安裝到了你的設備上了。所以，數字證書可以保證數字證書里的公鑰確實是這個
證書的所有者的，或者證書可以用來確認對方的身份。數字證書主要是用來解決公鑰的
安全發放問題。
綜上所述，總結一下，數字簽名和簽名驗證的大體流程如下圖所示：
引用鏈接： https://www.cnblogs.com/dacainiao/p/5842987.html
② android包名修改了，還能用以前的簽名嗎
android包名修改了，仍然可用以前的簽名，用什麼簽名與包名無關。
同一個開發者的多個程序盡可能使用同一個數字證書 ，這可以帶來以下好處：
1、有利於程序升級，當新版程序和舊版程序的數字證書相同時，Android系統才會認為這兩個程序是同一個程序的不同版本。如果新版程序和舊版程序的數字證書不相同，則Android系統認為他們是不同的程序，並產生沖突，會要求新程序更改包名；
2、有利於程序的模塊化設計和開發。Android系統允許擁有同一個數字簽名的程序運行在一個進程中，Android程序會將他們視為同一個程序。所以開發者可以將自己的程序分模塊開發，而用戶只需要在需要的時候下載適當的模塊；
3、 可以通過許可權(permission)的方式在多個程序間共享數據和代碼。Android提供了基於數字證書的許可權賦予機制，應用程序可以和其他的程序共 享概功能或者數據給那那些與自己擁有相同數字證書的程序。如果某個許可權(permission)的protectionLevel是signature， 則這個許可權就只能授予那些跟該許可權所在的包擁有同一個數字證書的程序。
③ apk簽名是什麼意思
apk簽名相當於程序的身份識別代碼。
是Android application package英文縮寫。
它是為了確保消息來源的真實性，同時確保消息不會被第三方篡改。於是就產生了apk簽名。
在apk中寫入一個「指紋」。指紋寫入以後，Apk中有任何修改，都會導致這個指紋無效，Android系統在安裝Apk進行簽名校驗時就會不通過，從而保證了安全性。
(3)安卓簽名有什麼好處擴展閱讀：
作用
1、apk簽名用於程序編譯打包之後，手機在運行程序之前會先去驗證程序的簽名（可以看作類似於我們電腦上常說的md5）是否合法，只有通過了驗證的文件才會被運行，所以簽名軟體的作用的讓文件通過手機的驗證為合法，不同的手機、系統是對應不同的簽名的。
2、可以用簽名工具來更改。比如手機簽名工具ZipSigner 2，可以對手機上的文件進行直接簽名，支持apk、zip及jar格式，方便刷機或漢化的朋友。有些愛好修改安卓apk軟體的用戶有時候需要對apk文件進行修改。
但是如果在電腦上操作的話，打包簽名是十分復雜的，還必須安裝java環境，可以說打包一個包是十分麻煩的，這款簽名工具可以解決上述遇到的問題。
3、應用程序模塊化：Android 系統可以允許同一個證書簽名的多個應用程序在一個進程里運行，系統實際把他們作為一個單個的應用程序，此時就可以把我們的應用程序以模塊的方式進行部署，而用戶可以獨立的升級其中的一個模塊。
④ Android V1及V2簽名原理簡析
Android為了保證系統及應用的安全性，在安裝APK的時候需要校驗包的完整性，同時，對於覆蓋安裝的場景還要校驗新舊是否匹配，這兩者都是通過Android簽名機制來進行保證的，本文就簡單看下Android的簽名與校驗原理，分一下幾個部分分析下：
簽名是摘要與非對稱密鑰加密相相結合的產物，摘要就像內容的一個指紋信息，一旦內容被篡改，摘要就會改變，簽名是摘要的加密結果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內容對應不起來，Android系統就認為APK內容被篡改了，從而拒絕安裝，以保證系統的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對於V3的輪密先不考慮。先看下只有V1簽名後APK的樣式：
再看下只有V2簽名的APK包樣式：
同時具有V1 V2簽名：
可以看到，如果只有V2簽名，那麼APK包內容幾乎是沒有改動的，META_INF中不會有新增文件，按Google官方文檔：在使用v2簽名方案進行簽名時，會在APK文件中插入一個APK簽名分塊，該分塊位於zip中央目錄部分之前並緊鄰該部分。在APK簽名分塊內， 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中，保證整個APK文件不可修改 ，如下圖：
而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性：
V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內容，如果狹義上說簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個文件其實是一套機制，不能單單拿一個來說事，
如果對APK中的資源文件進行了替換，那麼該資源的摘要必定發生改變，如果沒有修改MANIFEST.MF中的信息，那麼在安裝時候V1校驗就會失敗，無法安裝，不過如果篡改文件的同時，也修改其MANIFEST.MF中的摘要值，那麼MANIFEST.MF校驗就可以繞過。
CERT.SF個人覺得有點像冗餘，更像對文件完整性的二次保證，同繞過MANIFEST.MF一樣，.SF校驗也很容易被繞過。
CERT.RSA與CERT.SF是相互對應的，兩者名字前綴必須一致，不知道算不算一個無聊的標准。看下CERT.RSA文件內容：
CERT.RSA文件裡面存儲了證書公鑰、過期日期、發行人、加密演算法等信息，根據公鑰及加密演算法，Android系統就能計算出CERT.SF的摘要信息，其嚴格的格式如下：
從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請的時候經常用到，其實就是公鑰+開發者信息的一個簽名：
除了CERT.RSA文件，其餘兩個簽名文件其實跟keystore沒什麼關系，主要是文件自身的摘要及二次摘要，用不同的keystore進行簽名，生成的MANIFEST.MF與CERT.SF都是一樣的，不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性，CERT.RSA從整體上保證APK的來源及完整性，不過META_INF中的文件不在校驗范圍中，這也是V1的一個缺點。V2簽名又是如何保證信息的完整性呢？
前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個文件完整性校驗的意義並不是很大 ，安裝的時候反而耗時，不如採用更加簡單的便捷的校驗方式。V2簽名就不針對單個文件校驗了，而是 針對APK進行校驗 ，將APK分成1M的塊，對每個塊計算值摘要，之後針對所有摘要進行摘要，再利用摘要進行簽名。
也就是說，V2摘要簽名分兩級，第一級是對APK文件的1、3 、4 部分進行摘要，第二級是對第一級的摘要集合進行摘要，然後利用秘鑰進行簽名。安裝的時候，塊摘要可以並行處理，這樣可以提高校驗速度。
APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對消息數據執行一個單向Hash，從而生成一個固定長度的Hash值，這個值就是消息摘要，至於常聽到的MD5、SHA1都是摘要演算法的一種。理論上說，摘要一定會有碰撞，但只要保證有限長度內碰撞率很低就可以，這樣就能利用摘要來保證消息的完整性，只要消息被篡改，摘要一定會發生改變。但是，如果消息跟摘要同時被修改，那就無從得知了。
而數字簽名是什麼呢（公鑰數字簽名），利用非對稱加密技術，通過私鑰對摘要進行加密，產生一個字元串，這個字元串+公鑰證書就可以看做消息的數字簽名，如RSA就是常用的非對稱加密演算法。在沒有私鑰的前提下，非對稱加密演算法能確保別人無法偽造簽名，因此數字簽名也是對發送者信息真實性的一個有效證明。不過由於Android的keystore證書是自簽名的，沒有第三方權威機構認證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。
知道了摘要跟簽名的概念後，再來看看Android的簽名文件怎麼來的？如何影響原來APK包？通過sdk中的apksign來對一個APK進行簽名的命令如下：
其主要實現在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數，函數比較長，分幾步分析
先來看這一步，ApkUtils.findZipSections，這個函數主要是解析APK文件，獲得ZIP格式的一些簡單信息，並返回一個ZipSections，
ZipSections包含了ZIP文件格式的一些信息，比如中央目錄信息、中央目錄結尾信息等，對比到zip文件格式如下：
獲取到 ZipSections之後，就可以進一步解析APK這個ZIP包，繼續走後面的簽名流程，
可以看到先進行了一個V2簽名的檢驗，這里是用來簽名，為什麼先檢驗了一次？第一次簽名的時候會直接走這個異常邏輯分支，重復簽名的時候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應該是為了排除V2簽名，並獲取V2簽名以外的數據塊，因為簽名本身不能被算入到簽名中，之後會解析中央目錄區，構建一個DefaultApkSignerEngine用於簽名
先解析中央目錄區，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名演算法)，並構建DefaultApkSignerEngine，默認情況下V1 V2簽名都是打開的。
第五步與第六步的主要工作是：apk的預處理，包括目錄的一些排序之類的工作，應該是為了更高效處理簽名，預處理結束後，就開始簽名流程，首先做的是V1簽名（默認存在，除非主動關閉）：
步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創建META-INFO文件夾下的一些簽名文件，更新中央目錄、更新中央目錄結尾等，流程不復雜，不在贅述，簡單流程就是：
這里特殊提一下重復簽名的問題： 對一個已經V1簽名的APK再次V1簽名不會有任何問題 ，原理就是：再次簽名的時候，會排除之前的簽名文件。
可以看到目錄、META-INF文件夾下的文件、sf、rsa等結尾的文件都不會被V1簽名進行處理，所以這里不用擔心多次簽名的問題。接下來就是處理V2簽名。
V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對V1簽名過的APK進行分塊摘要，再集合簽名，V2簽名不會改變之前V1簽名後的任何信息，簽名後，在中央目錄前添加V2簽名塊，並更新中央目錄結尾信息，因為V2簽名後，中央目錄的偏移會再次改變：
簽名校驗的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗公鑰及證書信息一致，否則覆蓋安裝會失敗。簽名校驗的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機優先檢測V2簽名，如果V2簽名不存在，再校驗V1簽名，對於7.0以下的手機，不存在V2簽名校驗機制，只會校驗V1，所以，如果你的App的miniSdkVersion<24(N)，那麼你的簽名方式必須內含V1簽名：
校驗流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗APK自己的完整性以外，還要校驗證書是否一致只有證書一致（同一個keystore簽名），才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗
這里只關心證書部分：
Android V1及V2簽名簽名原理簡析
僅供參考，歡迎指正
⑤ 安卓ROM簽名有什麼用請高手解答下，我把別人的ROM精簡了也加了自己喜歡的，但是沒簽名也照樣刷機成功了
簽名工具就相當於給ROM發一個身份證（額，這么比喻不知道合不合適~），就是系統會任何你這個是合法的，就可以運行，如果不簽名的話，就是黑戶~不合法的，系統不認可。我以前改rom的時候都會最後用簽名工具處理下，你說的沒簽名也能刷，這個情況我倒不是很清楚，不過我還是建議刷之前簽名下，以免以後系統不穩定或有什麼其他問題。