AndroidStudio生成正式簽名APP
看似最後的最後，也是開始的開始！！！
Android系統會將所有的APK檔案識別為應用程式的安裝包，類似於windows系統上的exe檔案。
android系統要求安裝到手機的APK必須進行簽名，但是我們直接使用AS在手機上進行測試的時候似乎沒有經過簽名操作，那是因為AS來執行程式的時候使用了一個預設的keystore檔案幫助我們進行簽名，那麼預設的簽名檔案你可以點選工具欄Gradle—>專案名—>Tasks—->android
雙擊signingReport,執行結果如圖所示
所以可以看到我的簽名檔案在 C:\Users\welive\.android\debug.keystore
正式簽名
1.使用AndroidStudio進行生成
Build—>Gencrate Signed APK 來生成正式簽名的APK
之後的操作按照提示進行：在最後一步
選擇 release正式版本，這樣生成的APK便是正式簽名下的正式版本了。在你 Folder下的路徑下就可以看到。
使用Gradle進行簽名
Gradle是一個非常先進的專案構建工具，在androidStudio中開發所有專案都是使用Gradle進行構建的。在之前的專案中。
想要精通Cradle，難度較大，不亞於重新學習一門語言。（Gradle是使用Groovy語言編寫的），而我們目前只需要做到使用Gradle進行專案構建就好了。
使用Gradle生成帶有簽名的APK檔案，點選app檔案目錄下的build.gradle檔案如下：
上面這個祕鑰是我自己隨便建立的，如果雷同，純屬巧合。
在檔案中新增一個閉包
signingConfigs {
config {
keyAlias 'wedfrend'
keyPassword '123456'
storeFile file('H:/wedfrend.jks')
storePassword '123456'
}
}然後我們要對其進行應用：
這裡我將其引用兩次，也就是說正式簽名的 祕鑰和測試簽名的祕鑰是一致的。
關鍵在：
正式編譯的配置檔案
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
}測試編譯的配置檔案
debug {
signingConfig signingConfigs.config
}配置完成之後我們如何生成APK，開啟AS的工具欄Gradle/app/tasks/build
雙擊：assembleDebug ———->測試 APK
雙擊：assembleRelease ———->正式APK
所以目前我們的生成APK兩種方式都使用完成。
當然，對應Gradle的祕鑰配置，AS提供視覺化的簡單操作：
專案檔案—>右鍵—>選擇Open Module settings
可以檢視到這個介面：
點選Signing：
我添加了一個名為 config的祕鑰，並填寫相應的資訊，這個就對用了app/build.gradle檔案的signingConfigs裡面的閉環。
然後在點選Buile Types:
左邊有兩個可選的：debug表示測試版本應用的祕鑰，然後在右邊的Signing Config點選選擇一個祕鑰，在app/build.gradle中對應
debug {
signingConfig signingConfigs.config
}同樣，release對應的是正式版本，對應
release {
···
signingConfig signingConfigs.config
}只是在這個例項中我使用的同一個祕鑰而已，當然你也可以在專案中測試和正式的祕鑰不同，但是在實際開發中，外界原因我們有時候還真的需要祕鑰一致，比如接入微信支付的應用，你的祕鑰如果測試和正式不同，那麼在測試的APK中永遠都是不可能成功調起微信支付的。
最後的囉嗦：
目前keystore的檔案資訊都是以明文的形式直接配置在build.gradle中，這樣按道理講不安全，android推薦是將這類敏感的資料配置在一個獨立的檔案裡面，然後在build.gradle中讀取這些資料。
我們按照這種思路再來一遍：
androidStudio專案的根目錄下有一個gradle.properties檔案，他是專門用來配置全域性鍵值對資料的，那麼現在我們在該檔案下配置：
然後修改app/build.gradle如下：
這樣一來，在build.gradle中就無法正檢視祕鑰資訊，對於我們 第三方版本控制的時候只需將本地的gradle.properties儲存好就行，只需在內部傳播就好了。
囉嗦這個的原因是：在公司裡，每個技術人的水平不同，大家都有自己的一套思維，所以萬一哪位比較厲害的人這樣子配置了，你看的確實雲裡霧裡的多尷尬！！！
結束了，2月份的計劃也算是完成，還算符合預期，也是因為這月新年伊始，工作量少了點，抽出時間來進行知識庫的整理，接下來的3月份，會結合servlet&jsp的知識進行後臺的技術整理，Are you ready???