androidminisdk

A. android 中minSdkVersion 14和minSdkVersion 11的區別

適配的手機sdk最低版本，現在手機大多數都9.0了，但是還是有部分低的，一般minSdkVersion 19差不多適配了95%以上手機

B. 關於Android L最小的sdk版本是什麼解決方法

MiniMum Required SDK:最低支持的android api版本，低於這個版本的android手機不能安裝你的應用

Target SDK：你的應用最高支持android api版本

Compile With：哪個版本的android
SDK(1.5~4.2)編譯你的工程，也就是最適合的，最原生支持你的應用的android版本。

Theme ：這個隨意，主題選擇

說白了：就是最小，最大，和最適合的問題。
10種技巧可提升Android應用運行效果

技巧1：從優秀的編程開始

要採用已為用戶所接受的運演算法則和標準的設計樣式，這些被人們長期使用的編程法則也同樣適用於Android應用，尤其當這些應用使用內在設備服務時。

比如，假設你編寫的應用需要以地理定位服務為基礎。只需要在必要時開始注冊進行位置更新，在無需更新信息時，確保應用停止更新進程。這會幫助節省設備的電量和系統處理器的負擔。

技巧2：保持應用的靈活性

通過使用AsyncTask、IntentService或自定義背景服務來保持應用的靈活性。使用載入器來簡化載入時間較長數據的狀態管理，比如游標。不可讓應用在其他進程進行時顯得緩慢或完全靜止。

如果某些操作需要一定的時間和資源，應當將這個進程單獨分離出來非同步處理，這樣你的應用才能夠保持流暢的運行。可以運用這種方法的操作包括：磁碟讀寫，訪問內容供應方、資料庫和網路，其他需要較長時間的任務。

技巧3：使用最新的Android SDK版本和API

保持應用的更新，使用Android平台提供的最新內容。隨著Android平台的發展，它也在逐步改善中。某些功能被移除，或者替換成更好的選項。其核心API中的漏洞已修復，整個API性能已得到提升。該平台已引入裝載器之類的新API，幫助開發者編寫更為穩定和反應靈敏的應用。

Android
3.0應用支持硬體加速，你可以加以應用。應當理解的是，最佳的表現情況會隨著時間逐漸改變。睿智的開發者會更新平台發布的最新內容和API。

技巧4：檢查Strict Mode

你可以使用稱為「StrictMode」的Android
API來查找編程中的問題。StrictMode會幫助你識別應用是否正在耗費內存，也可以幫你檢查應用是否正在嘗試開展漫長的模塊化操作。

StrictMode類(註：即android.os.StrictMode)與Android 2.3同期發布。

技巧5：在發布之前停用或最小化調試和診斷

你在Android應用的開發中可能會將某些調試代碼構建其中。在應用發布之前確保這些功能被最小化或完全停用。

接下來，讓我們來討論如何用優秀的用戶界面設計原則讓你的應用載入速度更快。

技巧6：保持布局簡潔自然

簡潔自然的布局會加快載入速度。不要讓屏幕布局中充斥過多不必要的內容。花點時間開發用戶可以有效使用的簡潔用戶界面，不要將過多的功能性內容塞入單個屏幕中。這不僅對應用表現有幫助，而且會幫助用戶更有效地使用應用。

分割內容可以幫助劃分用戶界面功能性，同時不犧牲應用在各種不同設備上的靈活性。

技巧7：根據目標設備調整應用資源

根據特定的設備配置來調整資源，這樣它們就能夠有效地載入。在圖像資源方面，這個顯得尤為重要。如果你的應用中有大型的圖片資源需要載入，那麼要做好調整。

另一個技巧是，當以許多種設備為目標時，保持應用包文件大小合適，只需要在其中包含應用運行所需的核心資源即可，然後讓用戶根據具體設備下載應用其他內容。

技巧8：使用Hierarchy Viewer工具

Hierarchy
Viewer工具可以幫助你解除應用布局中的漏洞。它還提供了許多有價值的信息，比如每個View控制需要多長的時間。找到問題所屬領域，這樣解決問題會更加簡單。

技巧9：使用layoutopt工具

layoutopt工具是個簡單的命令行工具，可以幫助你識別不必要的控制和其他讓你布局資源崩潰的事項，提升其性能。它可以幫助你找到不必要的多餘布局控制。較少和較淺布局可優化應用運行性能。

最後，在自認為應用達到最好狀況時，對其進行測試。

技巧10：使用Traceview和其他Android應用壓縮工具

Android SDK中有許多可以壓縮應用的工具。可能最流行的工具就是Traceview，這個圖像工具可以幫助你調試和找到應用的性能問題。

C. 最近用小米手機在Android studio調試，安裝不了程序，怎麼解決

用小米來調試確實比較坑，需要注意的地方要多一點

首先，usb調試就不多說了，這是根本
然後，usb調試的地方下面有個usb安裝，這個也要打開
最後在設置頁面有個系統安全，裡面的允許安裝未知來源也要打開

D. 如何修改Android項目運行時需要的SDK版本

工具/原料：

adt-bundle-windows-x86_64-20140702

方法/步驟：

一、打開工程，如「HelloJni」

E. 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簽名簽名原理簡析

僅供參考，歡迎指正