針對不同 API 級別建立多個 APK

如果您將應用程式發布到 Google Play,應建構並上傳 Android App Bundle。屆時 Google Play 就會自動套用 根據每位使用者的裝置設定產生並提供經過最佳化的 APK,因此使用者只需下載 執行應用程式所需的程式碼和資源如果您要 無法發布至 Google Play,但您必須自行建構、簽署及管理各個 APK。

開發 Android 應用程式,善用 Google Play 上的多個 APK 時, 請務必一開始就採用一些好習慣,避免不必要的頭痛 以便深入開發程序本課程將說明如何為 但每個 API 級別的 API 級別範圍略有不同。您也會取得一些工具 ,盡可能減少維護多個 APK 程式碼集的負擔。

確認您需要多個 APK

嘗試建立適用於多代 Android 的應用程式 平台,自然希望應用程式利用新裝置的新功能 而不犧牲回溯相容性看起來似乎只是多個 APK 支援服務是最好的解決方案,但這往往並非如此。使用單一 APK 這份修訂版 APK 開發人員指南中一節會提供一些實用資訊,說明如何 方法是使用單一 APK,包括使用支援資料庫。並瞭解如何 在單一 APK 中編寫僅於特定 API 級別執行的程式碼,不需要依賴 需要進行較昂貴的運算技術,例如來自 的反射 這篇文章

如果您可以管理,將應用程式限定於單一 APK 會有數個 優點,包括:

  • 發布及測試更簡單
  • 只要維護一個程式碼集
  • 應用程式可因應裝置設定變更進行調整
  • 只要在所有裝置上還原應用程式即可
  • 不用擔心市場偏好、來自「升級」的行為從一個 APK 到 或與哪個類別的裝置搭配使用的 APK

本課程的其餘部分假設您已研究過這個主題,但它剛好吸收 ,並判定多個 APK 是適用於 應用程式。

以圖表呈現需求

請先建立簡單的圖表,以便快速判斷您需要的 APK 數量與哪個 API 各 APK 的涵蓋範圍線上課程網頁的「平台版本」頁面 Android 開發人員網站提供執行特定作業系統的相對使用中裝置數量相關資料 Android 平台的版本此外,雖然一開始看起來很簡單 往往很難鎖定目標 API 級別,如果 APK 等級停止運作, 一些重疊的情況幸好,您可以輕鬆快速繪製需求圖表 方便日後參考

如要建立多個 APK 圖表,請從一列代表 Android 平台的不同 API 級別在結尾加上一個儲存格代表未來 最新推出的 Android 版本

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

現在只需在圖表中加上顏色,讓各種顏色都能代表一個 APK。在此舉例說明 可以對特定範圍的 API 級別套用每個 APK。

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

建立這張圖表後,請發布給您的團隊。專案團隊通訊 不再詢問「針對 API 級別 3 到 6 的 APK 怎麼了,相信您馬上就會更容易了。 Android 1.x 版本那是什麼樣的事情?」只要說 嗎?」

將所有通用程式碼和資源放入程式庫專案

無論您要修改現有的 Android 應用程式,還是從頭開始建立應用程式, 您在程式碼集執行的第一項工作 到目前為止最重要的是全部顯示 只需要更新一次 (例如語言本地化字串 色彩主題、共用程式碼中修正的錯誤),從而改善開發時間並減少 能輕鬆避開的錯誤機率

注意:雖然如何建立和 還可加快學習速度 請參閱建立 Android 程式庫一文。

如果您打算將現有應用程式轉換成支援多個 APK 的功能, 針對每個本地化字串檔案、值清單、佈景主題檢查程式碼集 不會因 APK 版本而改變的顏色、選單圖示和版面配置 全都在程式庫專案中不會大幅變更的程式碼 也要前往程式庫專案您可能會發現自己擴展到 類別,藉此將一或兩個方法從 APK 新增至 APK。

另一方面,如果您是從頭開始建立應用程式,請嘗試 並在程式庫專案中編寫程式碼, 個別 APK長期下來比起新增單一檔案 使用起來會更加方便 其次,接著幾個月,嘗試確定這個 blob 是否可以向上移動 不必向上螺絲,就能前往程式庫專區

建立新的 APK 專案

每個要發布的 APK 都有一個獨立的 Android 專案。簡單易用 請將程式庫專案和所有相關 APK 專案放在同一個上層資料夾下。 此外請注意,每個 APK 的套件名稱 (不一定要相同) 您就需要與程式庫分享套件名稱如果遵循配置的情況下有 3 個 APK 您的根目錄可能如下所示:

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

建立專案後,請將程式庫專案新增為每個 APK 專案的參照。如果 在您的程式庫專案中定義起始活動,並在 APK 中擴充該活動 專案。程式庫專案中定義的起始活動可讓您 應用程式初始化時,所以個別 APK 不需要 重新導入「通用」初始化 Analytics、執行授權檢查等 從 APK 到 APK 沒有太大變化的初始化程序。

調整資訊清單

如果使用者透過 Google Play 下載使用多個 APK 的應用程式, 要使用的 APK 是透過兩項簡單的規則選擇:

  • 資訊清單必須顯示特定 APK 符合資格
  • 在符合資格的 APK 中,版本號碼最高

舉例而言,假設我們尚未使用上述的多組 APK 為任何 APK 設定最高 API 級別。分別擷取每個 APK 的可能範圍 如下所示:

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 較高的 APK 必須具備較高的 版本代碼較高者,我們知道在 versionCode 值方面,紅色 ≥ 綠色 ≥ 藍色。因此,我們可以有效收合圖表,如下所示:

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

接著,我們再假設 Red APK 有額外要求。 瀏覽「Google Play 篩選器」頁面 《Android 開發人員指南》列出了可能的原因。對於 假設紅色需要前置鏡頭。事實上 紅色 APK 結合了前置鏡頭與 API 新增的甜美新功能 11.但事實證明,並非所有支援 API 11 的裝置都具備前置鏡頭! 好恐怖!

不過,如果使用者透過這類裝置瀏覽 Google Play,Google Play 會查看 請看,紅色將前置鏡頭列為必備條件,然後安靜無聲忽略, 即使在「數位天堂」中,「紅色」與「當天」的裝置不符。就會看到 綠色並非僅與採用 API 11 (因為未定義 maxSdkVersion) 的裝置具前瞻相容性。 而且不在乎前置鏡頭效果!應用程式仍可下載 顯示來自 Google Play 的資訊,因為儘管整部前置鏡頭出錯,Google Play 仍提供 支援該特定 API 級別的 APK。

如要將所有 APK 保留在個別的「測試群組」中,請務必取得理想的版本代碼 配置。您可以在 開發人員指南本例的 APK 組合只會處理 3 個可能 只須將每個 APK 除以 1000,只需將前幾個數字設為 該特定 APK 的 minSdkVersion,並從該處遞增。如下所示:

藍色:03001、03002、03003、03004...
綠色:07001、07002、07003、07004...
紅色:11001、11002、11003、11004...

總而言之,您的 Android 資訊清單看起來會像這樣:

藍色:

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

綠色:

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

紅色:

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

檢查正式發布前檢查清單

上傳到 Google Play 前,請仔細檢查以下項目。提醒您,上述應用程式與多個 APK 特別相關,無法針對上傳到 Google Play 的所有應用程式逐一呈現完整的檢查清單。

  • 所有 APK 的套件名稱都必須相同
  • 所有 APK 都必須使用相同的憑證簽署
  • 如果平台版本的 APK 重疊, minSdkVersion 較高的 APK 必須採用較高的版本代碼
  • 仔細檢查資訊清單篩選器是否有衝突資訊 (在 XLARGE 螢幕上僅支援杯蛋糕的 APK,其他人不會看到)
  • 每個 APK 的資訊清單在至少一個支援的螢幕、openGL 紋理或平台版本上都不得重複
  • 請嘗試在至少一部裝置上測試每個 APK。原因在於,您在開發機器上的企業中,擁有最可自訂的裝置模擬器。大發雷霆!

另外,建議您先檢查已編譯的 APK 再推送至市場,確保沒有出現 以免在 Google Play 上隱藏您的應用程式。如果使用 「aapt」如果偏好在終端機視窗中工作 可使用 Google Cloud CLI gcloud 指令列工具Aapt (Android 資產封裝工具) 是建構程序的一部分 也能輕鬆檢查 Android 應用程式

>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 輸出內容時,請確認所有 支援螢幕和相容螢幕,而且沒有非預期的「uses-feature」服務值 您之所以新增這些條件,是因為您在資訊清單中設定權限。在上述範例中 無法顯示在許多裝置上。

為什麼?藉由新增必要權限 SEND_SMS,android.hardware.telephony 的功能需求已間接增加。由於 API 11 是 Honeycomb (專為平板電腦進行最佳化的 Android 版本),且沒有任何 Honeycomb 裝置搭載電話硬體,Google Play 一律會篩除這個 APK,直到日後的裝置搭載 API 級別較高的版本「且」擁有電話硬體。

不過,只要在資訊清單中加入以下內容,就能輕鬆解決這個問題:

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

系統也會間接新增 android.hardware.touchscreen 要求。如果您想在非觸控螢幕裝置的電視上顯示 APK,請在資訊清單中加入以下內容:

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

完成正式發布前檢查清單後,請將 APK 上傳至 Google Play。瀏覽 Google Play 時,可能需要經過一段時間才會顯示該應用程式,但找到後,請執行最後一次檢查。將應用程式下載到您的任何測試裝置,確保 APK 指定了目標裝置。恭喜您完成設定!