⑴ android studio 如何創建apk簽名
1、打開軟體
找到「Build」選項
2、打開生成apk簽名的窗口
Build---->Generate Signed APK...
3、 選擇創建新的密鑰
Creata new...
4、 選擇密鑰存儲路徑，並為密鑰命名
填寫信息
5、設置密碼，填寫或更改信息
密碼請牢記，密碼請牢記，密碼請牢記（三遍了）
證書內容貌似可以空白
6、ok，然後，下一步
如果遇到下圖的情況，不用擔心，繼續點擊ok
問題解決辦法：https://www.jianshu.com/p/67c2972182a0
7、然後，下一步
8、選擇簽名版本
v1或者v1&v2 然後點擊finish 即可，找到剛才保存的路徑，即可找到簽名文件
建議選擇v1&v2
⑵ Android基礎『V1V2V3簽名』
基礎概念
簽名：在 APK 中寫入一個「指紋」。指紋寫入以後，APK 中有任何修改，都會導致這個指紋無效，Android 系統在安裝 APK 進行簽名校驗時就會不通過，從而保證了安全性。
摘要演算法： 使用一段簡單的看上去隨機的不可逆向的固定長度的字元串來表示一個文件的唯一性。 常見的摘要演算法如MD5(128個比特位)、SHA-1演算法(160/192/256個比特位)。
公鑰密碼體制：也稱非對稱演算法，特點是 公鑰是公開的 ，私鑰是保密的。常見的如：RSA。
展開討論一下RSA：
Android中的簽名方案
V1 ：基於jarsigner(JDK自帶工具，使用keystore文件進行簽名) 或 apksigner(Android專門提供的，使用pk8、x509.pem進行簽名)。keystore和pk8/x509.pem可以相互轉換。
簽名原理：首先keystore文件包含一個MD5和一個SHA1摘要。 這也是很多開放平台需要我們上傳的摘要數據 。
簽名APK後會在META-INF文件夾下生產CERT.RSA、CERT.SF、MANIFEST.MF三個文件。
在apk中，/META-INF文件夾中保存著apk的簽名信息，一般至少包含三個文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。這三個文件就是對apk的簽名信息。
MANIFEST.MF中包含對apk中除了/META-INF文件夾外所有文件的簽名值，簽名方法是先SHA1()(或其他hash方法)在base64()。存儲形式是：Name加[SHA1]-Digest。
[CERT].SF是對MANIFEST.MF文件整體簽名以及其中各個條目的簽名。一般地，如果是使用工具簽名，還多包括一項。就是對MANIFEST.MF頭部信息的簽名，關於這一點前面源碼分析中已經提到。
[CERT].RSA包含用私鑰對[CERT].SF的簽名以及包含公鑰信息的數字證書。
是否存在簽名偽造可能：
修改(含增刪改)了apk中的文件，則：校驗時計算出的文件的摘要值與MANIFEST.MF文件中的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF,則：MANIFEST.MF修改過的條目的摘要與[CERT].SF對應的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF，則：計算出的[CERT].SF簽名與[CERT].RSA中記錄的簽名值不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，則：由於證書不可偽造，[CERT].RSA無法偽造。
V2 ：7.0新增的
簽名後的包會被分為四部分
1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
新應用簽名方案的簽名信息會被保存在區塊2（APK Signing Block） 中， 而區塊1（ Contents of ZIP entries ）、區塊3（ ZIP Central Directory ）、區塊4（ ZIP End of Central Directory ）是受保護的， 在簽名後任何對區塊1、3、4的修改都逃不過新的應用簽名方案的檢查 。
V3 ：9.0新增的
格式大體和 v2 類似，在 v2 插入的簽名塊（Apk Signature Block v2）中，又添加了一個新快（Attr塊） 。
在這個新塊中，會記錄我們之前的簽名信息以及新的簽名信息，以 密鑰轉輪的方案，來做簽名的替換和升級。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名 。
v3 簽名新增的新塊（attr）存儲了所有的簽名信息，由更小的 Level 塊，以 鏈表 的形式存儲。
其中每個節點都包含用於為之前版本的應用簽名的簽名證書，最舊的簽名證書對應根節點，系統會讓每個節點中的證書為列表中下一個證書簽名，從而為每個新密鑰提供證據來證明它應該像舊密鑰一樣可信。
這個過程有點類似 CA 證書的證明過程，已安裝的 App 的舊簽名，確保覆蓋安裝的 APK 的新簽名正確，將信任傳遞下去。
注意： 簽名方式只支持升級不支持降級，如安裝了V2的包，不能覆蓋替換為V1的包。
參考
Android App簽名(證書)校驗過程源碼分析
新一代開源Android渠道包生成工具Walle
Android 簽名機制 v1、v2、v3
⑶ 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的方法。
⑷ 如何用Android 源碼生成APK簽名文件
我們很多應用需要用到系統簽名，可以通過生成系統簽名文件，在生成apk時使用這個簽名，然後可以安裝到機器中，不需要放在源碼里編譯，重新刷系統。
先附上 50和 20機器人通用的debugkey(圖已經省略)
在Linux環境中，以Android源碼目錄為根目錄。
其中的platform.pk8是製作系統簽名需要的文件。
1、在這個目錄下，執行
生成臨時文件platform.pem
2、接著執行以下命令，將在目錄下生成platform.p12文件，它本質上應該就是一個數字證書
3、然後再執行以下命令出現以下信息，表示成功生成platform.jks
這個名字可以改成debug.keystore. 它的後綴本身是沒有關系，eclipse和AS都識別 platform.jks
4、然後在打包 apk 的時候選擇platform.jks文件，就可以直接用adb命令安裝apk到機器中了。
xxxx表示需要安裝的apk路徑
5、簽名的 Key store password和Key password都是android
⑸ Android Studio 生成正式簽名apk（app-release.apk）的兩種方式
方式一：使用Android Studio生成
1.點擊Build->Generate,首次點擊可能會提示輸入操作系統密碼
2.彈出如下對話框，因為我們還沒有生成過keystore ,所以點擊Create new，新建keystore
3.填寫相關內容
Key store path 是 keystore的存放路徑
Alias 是別名，填寫APP名稱即可，別的名稱你記得住的也行
validity 是有效期限。
兩種密碼結合上一幅圖看
填寫完成後點擊ok
（記得備份，因為以後這個apk的新版本都是用這個keystore了）
4.彈出此窗口，自動填充好了這密碼和別名，Next
如果點擊了Remember passwords 可能需要輸入操作系統密碼。
5.填寫路徑，選擇簽名版本，點擊Finish
V2是Android 7.0出現的更安全更快速的簽名方式。
點擊ShowInExplore，或者自己打開路徑，就可以看到app-release.apk了
方式二：使用Gradle 生成
1.編輯 根目錄文件 gradle.properties
添加如下內容:
KEY_PATH=D:/Android/test1.jks
KEY_PASS=12345678
ALIAS_NAME=test
ALIAS_PASS=12345678
2.編輯 app/build.gradle 讀取指定的路徑密碼
在android 閉包中添加signingConfigs閉包：
android {
compileSdkVersion 25
buildToolsVersion "25.0.3"
defaultConfig {
applicationId "com.example.test"
minSdkVersion 16
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
signingConfigs {
config {
storeFile file(KEY_PATH)
storePassword KEY_PASS
keyAlias ALIAS_NAME
keyPassword ALIAS_PASS
}
}
在buildTypes release 閉包中添加 signingConfig signingConfigs.config 應用前面的簽名配置(ps:signingConfigs閉包必須在buildTypes閉包前)
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
}
}
3.點擊右側工具欄的Gradle->項目名->:app->Tasks->build
assemble 用於生成測試版和正式版的apk
assembleDebug 用於生成測試版apk
⑹ Android開發對apk文件進行簽名
對apk簽名的步驟(適用於找回apk,對空包進行簽名)
1.復制java的jdk,bin目錄的絕對路徑(如果是默認安裝應該和我的路徑差不多)C:\Program Files\Java\jdk1.8.0_111\bin
2.進入cmd窗口,進入bin目錄(如果是新手,輸入cd C:\Program Files\Java\jdk1.8.0_111\bin)
輸入命令 jarsigner -verbose -keystore d:\project\360Wallpaper.keystore -signedjar d:\qihusign.apk d:\Qihuunsign.apk QIHU360
將簽名修改成自己簽名的路徑 ,生成的apk文件的名字路徑修改一下,再輸入需要簽名的apk文件路徑,最後輸入自己簽名的別名就可以
(新手,歡迎指正)