android編譯不簽名

⑴ android系統簽名

有時候，我們開發的apk需要用到系統許可權，需要在AndroidManifest.xml中添加共享系統進程屬性：

這時候apk的簽名就需要是系統簽名(platform、shared或media)才能正常使用。
常用系統簽名方式

這種方式比較麻煩，你需要有編譯過的源碼環境，並按如下步驟：
1、拷貝App源碼到Android源碼的packages/apps/目錄下，且App源碼是普通(Eclipse)格式的
2、配置Android.mk，在其中添加

3、使用mm編譯App，生成的apk即系統簽名

這種方式比在源碼環境下簽名簡單，App可以在Eclipse或Android Studio下編譯，然後給apk重新簽名即可。
但這種方式在頻繁調試的時候比較痛苦，即使寫成腳本，也需要重復一樣的操作。
相關文件
platform.x509.pem、platform.pk8、signapk.jar

文件位置
platform.x509.pem、platform.pk8:

signapk.jar:

signapk源碼路徑:

簽名命令

步驟

1、將相關文件及源apk文件置於同一路徑下
2、檢查源apk包，去掉META-INF/CERT.SF 和 META-INF/CERT.RSA 文件
3、執行簽名命令即可

讓Android Studio集成系統簽名，需要用到一個工具 keytool-importkeypair ，詳見下文。

這個工具的作用是將系統簽名的相關信息導入到已有的簽名文件里。

工具的使用方法可以通過–help或README.textile來尋求幫助

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

我的做法是在App根目錄新建Signature文件夾專門存放簽名相關文件。
步驟

1、生成demo.jks簽名文件

2、編寫簽名腳本signature.sh，內容如下：

為腳本文件添加可執行許可權：

執行腳本：

3、配置builde.gradle

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

這樣debug或release apk就帶有系統簽名了。

如果想直接Run app就是release版且帶系統簽名的apk，還需修改：

這樣直接Run app就是帶系統簽名的release版apk了。

⑵ 安卓開發 導出apk文件 一定要設置簽名嗎

不需要簽名的

生成apk最懶惰的方法是：
只要你運行過android項目，到工作目錄的bin文件夾下就能找到與項目同名的apk文件，這種apk默認是已經使用debug用戶簽名的。

如果想要自己給apk簽名：

1. 簽名的意義
   為了保證每個應用程序開發商合法ID，防止部分開放商可能通過使用相同的Package Name來混淆替換已經安裝的程序，我們需要對我們發布的APK文件進行唯一簽名，保證我們每次發布的版本的一致性(如自動更新不會因為版本不一致而無法安裝)。
   2.簽名的步驟
   a.創建key
   b.使用步驟a中產生的key對apk簽名
   3.具體操作
   方法一： 命令行下對apk簽名（原理）
   創建key，需要用到keytool.exe (位於jdk1.6.0_24jrein目錄下)，使用產生的key對apk簽名用到的是jarsigner.exe (位於jdk1.6.0_24in目錄下)，把上兩個軟體所在的目錄添加到環境變數path後，打開cmd輸入
   D:>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*說明：-genkey 產生密鑰 -alias demo.keystore 別名 demo.keystore -keyalg RSA 使用RSA演算法對簽名加密 -validity 40000 有效期限4000天 -keystore demo.keystore */D:>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk demo.apk demo.keystore/*說明：-verbose 輸出簽名的詳細信息 -keystoredemo.keystore 密鑰庫位置 -signedjar demor_signed.apk demo.apk demo.keystore 正式簽名，三個參數中依次為簽名後產生的文件demo_signed，要簽名的文件demo.apk和密鑰庫demo.keystore.*/
   注意事項：android工程的bin目錄下的demo.apk默認是已經使用debug用戶簽名的，所以不能使用上述步驟對此文件再次簽名。正確步驟應該是:在工程點擊右鍵->Anroid Tools-Export Unsigned Application Package導出的apk採用上述步驟簽名。
   方法二：使用Eclipse導出帶簽名的apk
   Eclipse直接能導出帶簽名的最終apk，非常方便，推薦使用，步驟如下：
   第一步：導出。

   
   

2. 

   
   第六步：Next,Next,結束！
   方法三：使用IntelliJ IDEA導出帶簽名的apk
   方法步驟基本和Eclipse相同，大概操作路徑是：菜單Tools->Andrdoid->Export signed apk。
   4.簽名之後，用zipalign(壓縮對齊)優化你的APK文件。
   未簽名的apk不能使用，也不能優化。簽名之後的apk谷歌推薦使用zipalign.exe(位於android-sdk-windows ools目錄下)工具對其優化：
   D:>zipalign -v 4 demo_signed.apk final.apk
   如上，zipalign能夠使apk文件中未壓縮的數據在4個位元組邊界上對齊（4個位元組是一個性能很好的值），這樣android系統就可以使用mmap()(請自行查閱這個函數的用途)函數讀取文件，可以在讀取資源上獲得較高的性能，
   PS:1.在4個位元組邊界上對齊的意思就是，一般來說，是指編譯器吧4個位元組作為一個單位來進行讀取的結果，這樣的話，CPU能夠對變數進行高效、快速的訪問（較之前不對齊）。
   2.對齊的根源：android系統中的Davlik虛擬機使用自己專有的格式DEX，DEX的結構是緊湊的，為了讓運行時的性能更好，可以進一步用"對齊"進一步優化，但是大小一般會有所增加。
   5.簽名對你的App的影響。
   你不可能只做一個APP，你可能有一個宏偉的戰略工程，想要在生活，服務，游戲，系統各個領域都想插足的話，你不可能只做一個APP，谷歌建議你把你所有的APP都使用同一個簽名證書。
   使用你自己的同一個簽名證書，就沒有人能夠覆蓋你的應用程序，即使包名相同，所以影響有：
   1) App升級。 使用相同簽名的升級軟體可以正常覆蓋老版本的軟體，否則系統比較發現新版本的簽名證書和老版本的簽名證書不一致，不會允許新版本安裝成功的。
   2) App模塊化。android系統允許具有相同的App運行在同一個進程中，如果運行在同一個進程中，則他們相當於同一個App，但是你可以單獨對他們升級更新，這是一種App級別的模塊化思路。
   3) 允許代碼和數據共享。android中提供了一個基於簽名的Permission標簽。通過允許的設置，我們可以實現對不同App之間的訪問和共享，如下：
   AndroidManifest.xml：<permission android:protectionLevel="normal" />
   其中protectionLevel標簽有4種值：normal(預設值),dangerous, signature,signatureOrSystem。簡單來說，normal是低風險的，所有的App不能訪問和共享此App。dangerous是高風險的，所有的App都能訪問和共享此App。signature是指具有相同簽名的App可以訪問和共享此App。signatureOrSystem是指系統image中App和具有相同簽名的App可以訪問和共享此App，谷歌建議不要使用這個選項，因為簽名就足夠了，一般這個許可會被用在在一個image中需要共享一些特定的功能的情況下。

   ⑶ android studio生成原包後需要簽名嗎

   默認Android Studio簽名生成apk文件或不簽名的apk文件
   

   點擊「Build——>Build APK」生成默認簽名和默認不簽名的兩種文件

   點擊「Build——>General Signed apk」指定自定義簽名文件後，生成發布版本的簽名文件，如果沒有簽名文件，先創建一個

   

   ⑷ Android Studio 之簽名

   通過簽名可以確保數據來源的可靠性和數據的不可篡改性

   對 Apk 進行簽名，也就是在 Apk 中寫入一個指紋，寫入指紋後，Apk 中有任何修改，都會導致這個指紋無效，Android 系統在安裝 Apk 進行簽名校驗時就會不通過，進而無法安裝該 Apk

   如上圖：

   通常的簽名驗簽過程中，接收方收到消息後，會先向 CA 機構驗證證書的合法性，再進行簽名校驗。但 Apk 的證書通常由開發者自己製作，沒有向 CA 機構申請，Android 系統在安裝 Apk 時也並沒有校驗證書本身的合法性，只是從證書中提取公鑰和加密演算法，因此，如果對第三方 Apk 重新簽名，也能安裝到沒有安裝過這個 Apk 的系統中

   keystore 文件包含私鑰、公鑰和數字證書，分為很多種，Android 使用的是 java 標准 keystore 格式 JKS(Java Key Storage)

   Android App Bundle：用於通過 Google Play 發布的應用，需要升級到AS 3.2 以上版本才支持App Bundle 格式；
   APK：用於創建可部署到設備上的簽名 APK

   點擊 Finish 就會生成簽名文件與簽名後的 Apk

   當我們需要升級 Apk 版本的時候，需要再次對 Apk 文件進行簽名，可以通過配置 build.gradle 讓其自動生成簽名後的 Apk

   如果你的項目是開源的，需要把你的簽名信息寫在 local.properties 中，然後在 .gitignore 配置文件中加入 local.properties ，這樣 local.properties 就不會提交到開源項目中，簽名信息也就不會被人獲取

   local.properties：

   app/build.gradle:

   有時候我們的 apk 中某些功能需要系統簽名，例如靜默安裝。測試系統簽名的 apk，需要 root 許可權，而帶 Google APIs 的模擬器不能 root，因此要注意不能選擇帶 Google APIs 的模擬器

   下面執行的操作都是在 linux 中，如果 apk 是 window 中生成的，需要拷貝到 linux 操作，再將生成的系統簽名過得 apk 再拷貝到 window，比較麻煩，可以考慮後面的自動系統簽名，還是需要在 linux 操作一次，不過之後就可以只在 window 操作了

   這兩個文件在目錄 aosp/build/target/proct/security 下，如下圖

   在目錄 aosp/prebuilts/sdk/tools/lib 下，如下圖

   將前面獲取的 platform.pk8 、 platform.x509.pem 和 signapk.jar 文件放到需要簽名的 apk 同一個目錄，執行以下命令

   如果出現上面的錯誤：Failed to load any of the given libraries: [conscrypt_openjdk_jni-linux-x86_64, conscrypt_openjdk_jni-linux-x86_64-fedora, conscrypt_openjdk_jni]

   解決方法：

   到目錄 aosp/prebuilts/sdk/tools/linux/lib64 下，復制 libconscrypt_openjdk_jni.so 文件到需要簽名 apk 的同一個目錄，並將命令改為

   自動進行系統簽名的原理是：先生成一個 system.jks 文件，使用 keytool-importkeypair 對 system.jks 文件進行系統簽名，再 build.gradle 和 local.properties 進行配置，直接使用帶有系統簽名的 system.jks 對 apk 進行簽名，這樣編譯生成的apk文件就自帶系統簽名了

   按照前面的方法，生成一個 system.jks 文件，此時是在 window 系統中操作的

   進入 keytool-importkeypair 目錄，將 system.jks、platform.pk8、platform.x509.pem 文件拷貝進來，拷貝之後的目錄結構為

   使用 linux 中修改過的帶有系統簽名的 system.jks 文件將 window 中最開始生成的 system.jks 覆蓋掉，再像前面的自動簽名部分一樣，修改 build.gradle 和 local.properties 的配置，之後生成的 apk 就是系統簽名過的了

   測試方法是，在 AndroidManifest.xml 中添加 android:sharedUserId="android.uid.system" 後安裝到 非 Google APIs 的模擬器上 ， Google APIs 的模擬器不能 root，無法安裝

   會發現只有使用 system.jks 文件簽名後才能安裝，否則安裝失敗，會報以下的錯誤：

   ⑸ android 打成沒簽名的包 安裝不了嗎 為什麼編譯後在bin文件夾下又可以安裝

   沒簽名是不能安裝的，系統bin目錄下的安裝包是自動生成的，是簽過名的，默認簽名文件在eclipse 中可以選擇。一般都在c盤 user下

   ⑹ 在android系統中，怎麼反編譯系統APK文件而不破壞以前的簽名就是不需要在重新編譯後簽名。

   ApkDec-Release-0.1 試試這個工具

   ⑺ APK反編譯成功後為什麼不能簽名

   圖片在android編譯時是自動生成的索引，圖片改了對應的索引就不正確，肯定會失敗

   ⑻ 怎樣能讓android不驗證簽名安裝apk

   Android在安裝某個應用時，提示程序未安裝由以下原因造成：

   1、手機已經安裝了一個包名相同的應用。

   2、當前手機操作系統不滿足程序包要求的系統版本。

   3、手機存儲空間不足。

   4、安裝包已經損壞。

   解決辦法：

   1、查看本機是否有安裝，如果有直接卸載掉。

   2、查看一下程序包的版本，與當前手機是否一致。

   3、卸載手機一些無用或者很少用的應用，釋放手機存儲空間。

   4、重新下載安裝包。

   ⑼ Android app簽名不成功的方法

   直接通過Open Mole Settings設置的Android Studio簽名配置，每次編譯後簽名和已經內置在system/spp目錄下的已簽名應用不同。
   
   解決的方法：參考下面鏈接的第一種方法。
   
   https://www.jianshu.com/p/400df0d3d882?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

   ⑽ android 系統簽名

   也有提到怎麼單獨給一個apk簽名，這里補充一下android的簽名許可權控制機制。
   
   android的標准簽名key有：
   
        testkey
   
        media
   
       latform
   
       hared
   
       以上的四種，可以在源碼的/build/target/proct/security裡面看到對應的密鑰，其中shared.pk8代表私鑰，shared.x509.pem公鑰，一定是成對出現的。
   
       其中testkey是作為android編譯的時候默認的簽名key，如果系統中的apk的android.mk中沒有設置LOCAL_CERTIFICATE的值，就默認使用testkey。
   
      而如果設置成：
   
      LOCAL_CERTIFICATE := platform
   
       就代表使用platform來簽名，這樣的話這個apk就擁有了和system相同的簽名，因為系統級別的簽名也是使用的platform來簽名，此時使用android:sharedUserId="android.uid.system"才有用！
   
        在/build/target/proct/security目錄下有個README，裡面有說怎麼製作這些key以及使用問題（android4.2）：
   
        從上面可以看出來在源碼下的/development/tools目錄下有個make_key的腳本，通過傳入兩個參數就可以生成一對簽名用的key。
   
       其中第一個為key的名字，一般都默認成android本身有的，因為很多地方都默認使用了這些名字，我們自定義的話只需要對第二個參數動手腳，定義如下：
   
       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的過程中會提示輸入password，我的處理是不輸入，直接enter，不要密碼！後面解釋，用自定義的key替換/security下面的。
   
       可以看到android源碼裡面的key使用的第二個參數就是上面README裡面的，是公開的，所以要release版本的系統的話，肯定要有自己的簽名key才能起到一個安全控製作用。
   
       在上面提到如果apk中的編譯選項LOCAL_CERTIFICATE沒有設置的話，就會使用默認的testkey作為簽名key，我們可以修改成自己想要的key，按照上面的步驟製作一個releasekey，修改android配置在/build/core/config.mk中定義變數：
   
   在主makefile文件裡面：
   
   ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)
   
     BUILD_VERSION_TAGS += release-key
   
   這樣的話默認的所有簽名將會使用releasekey。
   
   修改完之後就要編譯了，如果上面的這些key在製作的時候輸入了password就會出現如下錯誤：
   
   我在網上找到了合理的解釋：
   
   其實會出現這個錯誤的最根本的原因是多線程的問題。在編譯的時候為了加速一般都會執行make -jxxx，這樣本來需要手動輸入密碼的時候，由於其它線程的運行，就會導致影響當前的輸入終端，所以就會導緻密碼無法輸入的情況！
   
   再編譯完成之後也可以在build.prop中查看到變數：
   
   這樣處理了之後編譯出來的都是簽名過的了，系統才算是release版本
   
   我發現我這樣處理之後，整個系統的算是全部按照我的要求簽名了。
   
   網上看到還有另外的簽名release辦法，但是應該是針對另外的版本的，借用學習一下：
   
   make -j4 PRODUCT-proct_mol-user dist
   
   這個怎麼跟平時的編譯不一樣,後面多了兩個參數PRODUCT-proct_mol-user 和 dist. 編譯完成之後回在源碼/out/dist/目錄內生成個proct_mol-target_files開頭的zip文件.這就是我們需要進行簽名的文件系統.
   
   我的proct_mol 是full_gotechcn,後面加「-user」代表的是最終用戶版本，關於這個命名以及proct_mol等可參考http://blog.csdn.net/jscese/article/details/23931159
   
   編譯出需要簽名的zip壓縮包之後，就是利用/security下面的准備的key進行簽名了：
   
   ./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security  out/dist/full_gotechcn-target_files.zip   out/dist/signed_target_files.zi
   
   簽名目標文件 輸出成signed_target_files.zi
   
   如果出現某些apk出錯，可以通過在full_gotechcn-target_files.zip前面加參數"-e =" 來過濾這些apk.
   
   然後再通過image的腳本生成imag的zip文件，這種方式不適用與我目前的工程源碼，沒有做過多驗證！
   
   Android簽名機制可劃分為兩部分：（1）ROM簽名機制；（2）第三方APK簽名機制。
   
   Android APK實際上是一個jar包，而jar包又是一個zip包。APK包的簽名實際上使用的是jar包的簽名機制：在zip中添加一個META的子目錄，其中存放簽名信息；而簽名方法是為zip包中的每個文件計算其HASH值，得到簽名文件(*.sf)，然後對簽名文件(.sf)進行簽名並把簽名保存在簽名塊文件(*.dsa)中。
   
   在編譯Android源碼生成ROM的過程中，會使用build/target/proct/security目錄中的4個key（media, platform, shared, testkey）來對apk進行簽名。其中，*.pk8是二進制形式（DER）的私鑰，*.x509.pem是對應的X509公鑰證書（BASE64編碼）。build/target/proct/security目錄中的這幾個默認key是沒有密碼保護的，只能用於debug版本的ROM。
   
   要生成Release版本的ROM，可先生成TargetFiles，再使用帶密碼的key對TargetFiles重新簽名，最後由重簽名的TargetFiles來生成最終的ROM。
   
   可以使用Android源碼樹中自帶的工具「development/tools/make_key」來生成帶密碼的RSA公私鑰對（實際上是通過openssl來生成的）: $ development/tools/make_key media 『/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName』 上面的命令將生成一個二進制形式（DER）的私鑰文件「media.pk8」和一個對應的X509公鑰證書文件「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腳本來使用F4 (0×10001)作為e值（openssl genrsa的-3參數改為-f4）。
   
   也可以使用JDK中的keytool來生成公私鑰對，第三方APK簽名一般都是通過keytool來生成公私鑰對的。
   
   可以使用openssl x509命令來查看公鑰證書的詳細信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout
   
   還可以使用JDK中的keytool來查看公鑰證書內容，但其輸出內容沒有openssl x509全面： $ keytool -printcert -v -file media.x509.pem
   
   有了key之後，可以使用工具「build/tools/releasetools/sign_target_files」來對TargetFiles重新簽名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目錄中需要有四個key（media, platform, shared, releasekey）。注意：這里的releasekey將代替默認的testkey（請參考build/tools/releasetools/sign_target_files腳本實現），也就是說，如果某個apk的Android.mk文件中的LOCAL_CERTIFICATE為testkey，那麼在生成TargetFiles時是使用的build/target/proct/security/testkey來簽名的，這里重新簽名時將使用new_keys_dir/releasekey來簽名。
   
   uild/tools/releasetools/sign_target_files_apks是通過host/linux-x86/framework/signapk.jar來完成簽名的。也可以直接使用host/linux-x86/framework/signapk.jar來對某個apk進行簽名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，」-w」表示還對整個apk包(zip包）進行簽名，並把簽名放在zip包的comment中。
   
   對於第三方應用開發者而言，對APK簽名相對要簡單得多。第三方應用開發一般採用JDK中的keytool和jarsigner來完成簽名密鑰的管理和APK的簽名。
   
   使用keytool來生成存儲有公私鑰對的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格式的公鑰證書，RFC 1421）
   
   導出公鑰證書： $ keytool -export -keystore mystore -alias mykey -file my.der （註：二進制格式公鑰證書，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （註：Base64格式公鑰證書，PEM）
   
   對APK進行簽名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey
   
   驗證簽名： $ jarsigner -verify -verbose -certs my_application.apk
   
   在進行Android二次開發時，有時需要把build/target/proct/security下面的公私鑰對轉換為keystore的形式，可以參考這篇文章：把Android源碼中的密碼對轉換為keystore的方法。