Android 多APK設計專題之為不同的API Level創建不同的應用APK

多APK支持是 Android Market 的一個新特性，它允許您為同一款應用對應不同的設備API Level 創建不同的APK，Android Market 會自動進行管理，通過識別用戶設備的系統等級，比如2.2，2.3，4.0等等，然後會選擇適合該設備的APK來讓用戶安裝。

為不同的API Level設計的APK，可以進行特別的優化設置，比如GL紋理設置， API級別，屏幕尺寸，或其中的多個組合。

本節課就帶領大家熟悉一下多APK的設計思路，您可以從中找到必要的開發工具和開發維護多個版本APK的方法。

 

確認您需要多個APKs

當您設計一款應用程序，為了滿足多版本多設備之間的需求，在不犧牲向後兼容性的情況下，又可以利用最新版本的新特性，似乎多APK支持是個不錯的解決方案。但事實並非如此，您可以通過閱讀資料《 》和《》來學習怎樣在單一APK中實現上面提到的功能需求，以及怎樣利用我們的支持庫，同時也可以了解一下如何來編碼實現。

使用單一APK有如下優勢：

• 發布和測試更容易
• 只需要維護一個代碼庫
• 應用程序能夠自適應設備配置的變化
• 應用恢復功能跨設備通用
• 應用升級容易

本文的余下章節，假定您已經認為您確實需要多APKs的解決方案，而不使用單一 APK 的方法。

圖示化需求

可以通過創建一個簡單的圖表來確定需要幾個APK來支持，以及每個APK與之對應的API Level范圍。您可以在Android 平台版本的信息頁面（ ）中找到有用的參考資料，通過這種方法可以快速確定需要的APK個數和每個APK對應的API Level范圍，尤其在出現API Level范圍有重疊情況的時候更加有效，同時也方便了日後參考。

創建一個水平的列表來表示出當前已經發布的Android 版本號，在列表的最後一個位置放置一個+號來代表未來發布的版本。

3 4 5 6 7 8 9 10 11 12 13 +

對上面的列表進行著色，每一種顏色對應一個APK，之後您的團隊就可以以此來進行討論還開發。

3 4 5 6 7 8 9 10 11 12 13 +

設計公共庫

無論是修改已有的代碼做二次開發，還是從頭開發一個新的應用，第一件事情就是提取公共的代碼庫，這些代碼可以被不同的應用使用，並且只需要在一處編寫和維護，比如多語言支持（language-localized strings），顏色主題（color themes），bug修復代碼等，提供公共代碼可以大大提高開發效率和節省開發時間，以及降低更新代碼時引入的錯誤。

注：如何提取和創建公共的代碼庫，可參照下面的文章

如果您打算將已開發的單一APK轉化為多APK支持，那麼以下資源通常可以放置到公共代碼庫中，比如字符串資源文件（localized string file），常量值（list of values），顏色定義（theme colors），菜單圖標（menu icons ）和可共用的布局文件（layout ）。或者，您打算從頭開發一個應用，這時候也應該先開發公共的代碼庫，然後將各個APK不同的特定代碼部分移動到具體的APK中，便於代碼的管理和以後的擴展，當開發過一段時間之後，您可以逆向從各個不同的APK中再提取公共的部分來更新公共代碼庫。

建立工程項目

每一個獨立的APK對應於一個獨立的工程文件夾，為了方便代碼的組織和管理，所有APK項目的工程文件夾和公共項目文件夾應該放在同一個根目錄下面，並且所有的APK項目應該是相同的包名（package name）。示例代碼展示了建立上面列舉的3個獨立APK的項目文件夾，組織結構如下：

   alexlucas:~/code/multi-apks-root$ ls
   foo-blue
   foo-green
   foo-lib
   foo-red

工程目錄建立好以後，每個獨立的APK項目都可以引用公共項目庫，一般將啟動Activity（starting Activity ）放在公共項目庫中，然後獨立的APK工程中可以繼承和擴展該Activity，這樣便於將初始化代碼集中在一個地方，例如 initializing Analytics, running licensing checks, and any other initialization procedures。

配置 Manifests 文件

當用戶通過Android Market下載支持多APK的應用時，Market過濾器會依據如下的規則來選擇合適的APK版本：

• manifest 中聲明的版本號必須匹配
• manifest 中聲明匹配的所有版本號中最大者優先

用我們前面討論過的例子來進行說明，假如 manifest 中未設置支持的最大API等級（max API level） 選項，則每一個APK對應的API Level 如下：

3 4 5 6 7 8 9 10 11 12 13 + 3 4 5 6 7 8 9 10 11 12 13 + 3 4 5 6 7 8 9 10 11 12 13 +

minSdkVersion 越大則代表支持越高版本的代碼，那麼如上圖 red ≥ green ≥ blue，則上圖可以合並如下：

3 4 5 6 7 8 9 10 11 12 13 +

現在，假如 Red APK 使用了一種其他APK沒有的新功能，比如前置相機，API Level 11以後支持。當用戶設備通過Android Market進行程序下載的時候，Market Filters就會檢測設備的信息，看是否是Level 11以上，是否有前置相機，如果不符合條件的話，Red APK就不會列在下載清單中，用戶也就沒法下載。事實上，目前仍有很多的設備還沒有達到Level 11，也沒有配置前置相機，那麼如何解決此類問題呢。

幸運的是，Android Market會自動處理這種情況，它發現當前設備與Red APK的manifest 文件聲明不符，會簡單忽略它，然後繼續檢測Green APK，因為 Green APK沒有設置maxSdkVersion 選項，本身又向前兼容，這樣不管設備的版本是不是Level 11以上，也不管設備是否有前置攝像頭，Green APK 仍然可用，用戶也可以下載。

為了便於管理所有的APKs，應該合理設置版本號（version code scheme）。推薦閱讀指南《》，我們的例子中有3個獨立的APK，每一個可以設置1000的版本號范圍，前幾位的數字（minSdkVersion ）用來標志不同的APK，每次更新程序依次遞增。示例如下：

   Blue: 03001, 03002, 03003, 03004...
   Green: 07001, 07002, 07003, 07004...
   Red:11001, 11002, 11003, 11004...

綜合以上，您的 Android Manifests 文件可能如下：

Blue:

   <manifest xmlns:android="<a href="http://schemas.android.com/apk/res/android">http://schemas.android.com/apk/res/android</a>"    android:versionCode="03001" android:versionName="1.0" package="com.example.foo">    <uses-sdk android:minSdkVersion="3" />    ... 

Green:

   <manifest xmlns:android="<a href="http://schemas.android.com/apk/res/android">http://schemas.android.com/apk/res/android</a>"    android:versionCode="07001" android:versionName="1.0" package="com.example.foo">    <uses-sdk android:minSdkVersion="7" />    ... 

Red:

   <manifest xmlns:android="<a href="http://schemas.android.com/apk/res/android">http://schemas.android.com/apk/res/android</a>"    android:versionCode="11001" android:versionName="1.0" package="com.example.foo">    <uses-sdk android:minSdkVersion="11" />    ... 

發布前的檢測清單

在將您的應用發布到Android Market之前，請仔細檢查下面清單中列舉的項目。請記住這些檢查只適用於多APKs的程序設計，本文無法列出要發布到Android Market程序的所有檢測項目。

• 所有的APKs擁有相同的包名
• 所有的APKs必須使用相同的簽名文件
• 如果多個APKs的平台兼容版本有重疊，那麼擁有較高minSdkVersion版本的APK必須擁有較高的版本號（version code）
• 檢查manifest配置文件中的filter，防止出現矛盾的地方（例如，APK聲明為只支持屏幕類型為XLARGE的cupcake版本，那麼此APK將不能被任何設備下載）
• 每一個APK的manifest配置文件必須是唯一的，至少支持一種類型的屏幕，OpenGL紋理，或者Android固件版本
• 每一個APK都至少在一個平台上做過測試，開發環境中可以建立多個不同類型自定義的模擬器，請盡量做完整的測試

利用 Aapt (the Android Asset Packaging Tool) 工具來做最後的打包和檢查工作，有效防止意外的小錯誤導致您的應用無法在Android Market的下載清單中正常顯示出來。

   >aapt dump badging
   package: name='com.example.hello' versionCode='1' versionName='1.0'
   sdkVersion:'11'
   uses-permission:'android.permission.SEND_SMS'
   application-label:'Hello'
   application-icon-120:'res/drawable-ldpi/icon.png'
   application-icon-160:'res/drawable-mdpi/icon.png'
   application-icon-240:'res/drawable-hdpi/icon.png'
   application: label='Hello' icon='res/drawable-mdpi/icon.png'
   launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon=''
   uses-feature:'android.hardware.telephony'
   uses-feature:'android.hardware.touchscreen'
   main
   supports-screens: 'small' 'normal' 'large' 'xlarge'
   supports-any-density: 'true'
   locales: '--_--'
   densities: '120' '160' '240'

仔細檢查aapt工具的輸出，看看有沒有設置有矛盾的地方，尤其是關於支持的屏幕類型（supports-screens ）和兼容的屏幕類型（ compatible-screens），沒有預期之外的多余的用戶功能（uses-feature）權限，在上面的示例中，該APK在很多設備中都不可見。

什麼原因導致的呢？因為上面的APK配置文件中加入了發信息（SEND_SMS）權限，android.hardware.telephony 特性就被隱式自動添加了。API 11 是Honeycomb （專門為平板設計的系統），而該設備沒有支持電話的硬件（telephony hardware），Android Market就會將此APK過濾掉，導致 Honeycomb 設備沒法下載和安裝該APK，直到未來的設備APK Level升級，加入了支持電話的硬件，這個APK才能被下載安裝。

幸運的是，我們可以只簡單的修改一下配置文件即可解決這個問題：

   <uses-feature android:name="android.hardware.telephony" android:required="false" />

完成了以上的檢查工作，提交APKs到Android Market。經過審核後，您就可以在Android Market中下載和安裝這些應用到您的測試設備中，確保所有的APKs都正確匹配配置文件中聲明的設備類型，APK在預期的設備平台上會正常工作，到此為止，恭喜您，多APK設計的工作就完成了。

參考文摘：

 

原文：http://blog.zhourunsheng.com/2012/02/android-%e5%a4%9aapk%e8%ae%be%e8%ae%a1%e4%b8%93%e9%a2%98%e4%b9%8b%e4%b8%ba%e4%b8%8d%e5%90%8c%e7%9a%84api-level%e5%88%9b%e5%bb%ba%e4%b8%8d%e5%90%8c%e7%9a%84%e5%ba%94%e7%94%a8apk/ | 潤物無聲