LZ-Says：寫代碼寫得突然蒙比了，來來回回折騰了小2個月，亂啊~
前言
話說從Eclipse轉化到Android Studio後，一直都沒打個包，發個版本，今天想送出測試打個版本，丫的一看，和Eclipse不一樣了。在此記錄下，順便拓展下其他小知識點，友善你我他。
進入主題 AS打包步驟如下
1.選擇 Build –> Generate Signed APK…
2.選擇密鑰存放位址，密碼，别名，密碼
2.1 因為我們是首次打包，是以需要建立keystore，Android Studio中叫做jks(如果之前已經有keystore或者jks，可忽略此步)
3.擷取項目對應的jks檔案後next，選擇apk存放位址以及項目打包版本(正式版 or 測試版)，選擇V1，點選Finish。
戶外小拓展
1. Android為什麼要進行打包，簽名？
apk，實際就是一個zip包，大家可以修改字尾解壓後檢視，LZ解壓的如下：
所有的Android應用程式都要求用一個證書進行數字簽名，Android系統不會安裝沒有進行簽名的App。平時我們的程式可以在模拟器上安裝并運作，是因為在應用程式開發期間是以Debug狀态進行編譯的，是以ADT會自動用預設的密鑰和證書來進行簽名，而在以釋出模式編譯時，apk檔案就不會得到自動簽名，這樣就需要進行手工簽名。手工簽名的簽名檔案當然是公司/開發者自己造的
給apk簽名可以帶來以下好處（其實簽名是必須的）：
1.應用程式更新：如果你希望使用你造的App的使用者無縫更新到最新版本，那麼你造的app就必須用同一個證書進行簽名。這是由于傲嬌的Android系統隻有識别出你造的App是以同一個證書簽名的，才會允許安裝更新的應用程式。如果你不小心采用了不同的證書，那麼系統會要求你的應用程式采用不同的包名，在這種情況下手機相當于安裝了一個全新的應用程式。如果想更新應用程式，簽名證書要相同，包名稱要相同，Android就是如此傲嬌 !
2.應用程式子產品化： Android系統可以允許多個應用程式在一個程序裡運作，但前提是他們都是用同一個證書簽名的。實際上，系統把他們作為一個應用程式對待的，此時你可以把應用程式以子產品的方式進行部署，而使用者可以獨立的更新其中的一個子產品。這就是子產品化，又叫插件化！
3.代碼或者資料共享： Android提供了基于簽名的權限機制，那麼一個應用程式就可以為另一個以相同證書簽名的應用程式公開自己的功能。以同一個證書對多個應用程式進行簽名，利用基于簽名的權限檢查，你就可以在應用程式間以安全的方式共享代碼和資料了 。
2. keystore簡介
java的密鑰庫、用來進行通信加密用的、比如數字簽名。keystore就是用來儲存密鑰對的，比如公鑰和私鑰。
3. jks簡介
JAVA的keytools證書工具支援的證書私鑰格式
4. signature version v1 v2
通過檢視谷歌官方資料和各位同仁見解，我們可以知道如下幾點：
1.Android 7.0 引入一項新的應用簽名方案 APK Signature Scheme v2，它能提供更快的應用安裝時間和更多針對未授權 APK 檔案更改的保護。在預設情況下，Android Studio 2.2 和 Android Plugin for Gradle 2.2 會使用 APK Signature Scheme v2 和傳統簽名方案來簽署應用；
ps：在這裡我們可以知道這個東西是谷歌針對Android7.0推出的新的簽名方案，也就是說，當you的app需要相容7.0時，才會遇到這個東西。貌似市面上主流的依舊是android 5.0 and 6.0，雖然有了8.0的苗頭，但是目前身邊人還未使用7.0，暫時先不考慮了
經過同仁測試，使用v1的時候在5.0和7.0均未發現問題，當使用v2包的話，5.0就中槍了，提示“找不到簽名證書”。
各位注意！！！
LZ了解
個人感覺keystore和jks差不多，都是屬于一個容器。而這個容器裡面存儲着辨別(敏感資訊)，我們一般通過這個辨別，去對我們的應用進行辨別加密)。
使用Android Studio打包的時候，你可以使用eclipse中的keystore，也可以使用jks。
2017年12月15日09:49:59更新
以下摘抄自360：
美國時間12月9日，Google在其官網通告了一個名為“Janus”的安卓漏洞，該漏洞可以讓攻擊者繞過安卓系統的簽名校驗，直接在APP内惡意植入代碼。
影響範圍：
- 所有Android 5.0以上系統；
- 所有僅采用了Android APK Signature Scheme V1簽名機制的App。
12月13日，360加強保團隊緊急上線了針對Janus漏洞的解決方案，該方案對Janus漏洞進行掃描、檢測并采取相應的安全保護措施，有效地防止黑客通過Janus漏洞修改原始Dex檔案，插入惡意代碼和廣告，保護廣大使用者及開發者利益
Janus漏洞原理
Janus漏洞産生的根源在于将DEX檔案和APK檔案拼接之後校驗簽名時隻校驗了檔案的APK部分，而虛拟機執行時卻執行了檔案的DEX部分，導緻了漏洞的發生。由于這種同時為APK檔案和DEX檔案的二進制性，聯想到羅馬的二進制之神Janus，将該漏洞命名為Janus漏洞。
Android支援兩種應用簽名方案，一種是基于JAR簽名的方案（v1方案），另一種是Android Nougat(7.0)中引入的APK簽名方案（v2方案）。
v1簽名不保護APK的某些部分，例如ZIP中繼資料。APK驗證程式需要處理大量不可信（尚未經過驗證）的資料結構，然後會舍棄不受簽名保護的資料。這會導緻相當大的受攻擊面。
Janus漏洞危害
代号為“Janus”的安卓漏洞（漏洞編号：CVE-2017-13156），能夠讓惡意攻擊者在完全不修改App開發者簽名的情況下，通過植入惡意dex代碼，對App實施惡意代碼注入，逃避Android簽名校驗機制甚至擷取系統ROOT權限。
如何避免Janus漏洞？
1. 更新至V2簽名
在Android Studio中強制開啟V2簽名，如下圖所示：
或在app的build.gradle的android标簽下加入如下: