Android App Bundle 常見問題

關於 Android App Bundle

Android App Bundle (AAB) 是什麼?

Android App Bundle (AAB) 是 2018 年推出的 Android 發布格式,除了 Google Play 和其他應用程式商店以外,Android Studio、Bazel、Buck、Cocos Creator、Gradle、Unity 和 Unreal 等建構工具也都支援此格式。

AAB 和 APK 有何不同?

應用程式套件只是一種發布格式,無法直接安裝在 Android 裝置上。Android 檔案包 (APK) 則是 Android 應用程式的可安裝和可執行格式。應用程式套件必須由發布商處理成 APK 的格式,才能安裝到裝置上。

AAB 是不是 Google Play 專用的格式?

AAB 並不是專屬格式。應用程式套件是一種開放原始碼,因此所有應用程式商店都能支援。Google Play 和部分其他應用程式商店均支援應用程式套件。

建立 AAB 是否會導致無法將應用程式發布至其他應用程式商店?

不會,您仍然可以將其發布至其他應用程式商店。建構應用程式時,您可以依據每個應用程式商店所需的發布格式,同時建構 AAB 和 APK。

需要完成哪些工作才能使用 AAB?

對大多數應用程式而言,建構 AAB 所要處理的工作與 APK 差不多,只需在執行建構程序時選取 AAB (而非 APK) 即可。但是,仍有部分應用程式可能需要進行一些變更,才能完全發揮 AAB 的優勢。

已經有開發人員在使用 AAB 了嗎?

是。目前已有超過 100 萬個應用程式和遊戲使用應用程式套件在 Google Play 發布正式版應用程式,包括多數熱門應用程式,有效安裝次數高達數十億次。如果您使用 Google Play 安裝應用程式,則裝置上的許多應用程式都是以應用程式套件形式發布的。

AAB 是否會導致使用者無法「側載」應用程式?

不會,AAB 並不會阻止使用者從任何來源安裝 APK。AAB 只是發布格式,並不會變更 Android 平台的運作方式。

如果開發人員透過 AAB 提供最佳化的 APK,那麼共用這些 APK 的使用者是否有可能遇到問題?

在 Android 上,無論應用程式是透過 APK 還是 AAB 發布,無法將 APK 直接從一個裝置轉移到另一個裝置都是很罕見的情況。具體來說,如果已針對一個裝置 (例如特定晶片架構) 對 APK 進行最佳化處理,那麼將這些 APK 直接轉移至另一個裝置時,如果目標裝置與原始裝置的屬性不匹配,則可能會遇到問題。在這樣的情況下,您需要為目標裝置安裝一個或一組適當的 APK。

我可以將檔案發布到多個應用程式商店嗎?

可以,不論您是否使用 AAB,都可以發布至多個應用程式商店。您可以在 Google Play 和其他支援 AAB 的應用程式商店中發布 AAB,同時在其他不支援 AAB 的應用程式商店或網站發布 APK。

AAB 的相關規定是否適用於發布至 Google Play 管理版的私人應用程式?

不適用。發布至 Google Play 管理版的私人應用程式可以使用 APK 或 AAB 發布。建立新的私人應用程式時,如果想發布自行簽署的私人 APK,可以選擇變更應用程式簽署金鑰,然後退出 Play 應用程式簽署計畫。

關於 Play 應用程式簽署

Play 應用程式簽署是什麼?

Android 中的每個 APK 都必須以應用程式簽署金鑰進行加密,才能變得可安裝。Android 平台會透過金鑰確保所有應用程式更新與裝置上安裝的應用程式相符,進而保證在初次安裝後,每次的應用程式更新都來自同一個金鑰持有人。這種做法可降低惡意應用程式更新的風險。Play 應用程式簽署於 2017 年推出,是 Google Play 的金鑰管理服務,用於保護及管理 Google Play 開發人員透過 Google Play 發行應用程式時所用的應用程式簽署金鑰。此外,在 Google Play Play 根據已上傳的 AAB 產生 APK 後,應用程式簽署功能還會對這些 APK 執行簽署作業。新應用程式都必須採用 Play 應用程式簽署,才能使用 AAB。

Google 為什麼要推出 Play 應用程式簽署功能?

多年以來,應用程式簽署金鑰一直是 Play 開發人員面臨的一個難題。遺失金鑰意味著無法再向使用者提供應用程式更新,且金鑰遭盜用可能導致使用者面臨惡意更新的風險。在軟體發行過程中,發行管道通常會為其發行的軟體儲存及管理金鑰,因為這樣做可以降低上述風險。Play 應用程式簽署於 2017 年推出,可避免 Play 發行金鑰遺失,並在金鑰遭盜用後保護 Play 使用者,同時讓開發人員從 Google 不斷改進的安全防護技術中獲益。

Google 如何確保 Play 應用程式簽署的安全性?

Google 保護開發人員的金鑰時,採用的是業界領先的安全基礎架構,這套架構同樣也用於保護 Google 自家金鑰。金鑰以加密形式儲存在鎖定的專用金鑰管理伺服器中,並使用嚴格的 ACL 和涵蓋所有作業的防竄改稽核記錄。線上詳細介紹了 Google 的雲端安全性作業與最佳做法。

我可以選擇 Play 用於應用程式的應用程式簽署金鑰嗎?

可以。建立新的應用程式時,您可以選擇讓 Google 代表您產生並儲存應用程式簽署金鑰,也可以選擇自己的應用程式簽署金鑰並上傳該金鑰的副本。

我想要使用在 Play 和其他應用程式商店中相同的應用程式簽署金鑰。仍然可以這麼做嗎?

如果您在考量應用程式更新的運作方式後,決定在多個應用程式商店中使用相同的簽署金鑰,仍然可以這麼做。請記得,這種做法將允許每個應用程式商店針對您的應用程式執行跨商店應用程式更新。有兩種執行方式:

  • 您可以在本機產生金鑰,然後將金鑰副本上傳到 Play。這麼一來,當您在為其他應用程式商店建構應用程式時,也可以使用 Google Play 所用的同一個金鑰。
  • 您可以使用 Google 產生的 Play 應用程式簽署金鑰,然後從 Play 管理中心下載以 Google 所產生金鑰簽署的發行 APK,並透過這些 APK 在其他應用程式商店或網站上發行應用程式。

如果不提供應用程式簽署金鑰副本,我可以使用 Play 應用程式簽署功能來簽署 2021 年 8 月前建立的應用程式嗎?

可以,Play 應用程式簽署功能針對 2021 年 8 月前建立的應用程式提供了一個「金鑰升級」選項,這樣一來,這類應用程式就能透過新的應用程式簽署金鑰,導入 Play 應用程式簽署功能。不過,如要使用這一選項,您必須先執行升級,然後為每個版本上傳兩個項目:應用程式套件和以舊應用程式簽署金鑰簽署的舊版 APK。Play 會使用您的 AAB 產生以升級金鑰簽署的 APK,以便用於新的安裝作業和更新;同時,Play 也會使用舊版 APK 為之前已安裝應用程式的使用者提供應用程式更新。經過一段時間後,先前安裝的應用程式也會遷移到升級的金鑰 (例如使用者換用新的行動裝置時)。

是否能夠為 2021 年 8 月之前和之後建立的應用程式使用相同的應用程式簽署金鑰?

我們通常不建議為多個應用程式使用同一個應用程式簽署金鑰,因為每個應用程式都使用專屬金鑰會比較安全。不過,如果您需要為多個應用程式使用相同的應用程式簽署金鑰,也是可以辦到。您可以在設定 Play 應用程式簽署時上傳現有應用程式簽署金鑰的副本。或者,如果您不想提供現有的應用程式簽署金鑰,則可以使用即將推出的「金鑰升級」選項,讓 2021 年 8 月前的應用程式開始使用 Play 應用程式簽署。這樣一來,2021 年 8 月之前和之後的應用程式就可以使用相同的新金鑰了。

我可以變更 Play 應用程式簽署功能所使用的應用程式簽署金鑰嗎?

可以,您可以在 Play 管理中心提出金鑰升級要求,藉此變更應用程式金鑰。

如何確認 Google Play 未對程式碼進行非預期變更?

您隨時可以從 Google Play 和 Play 管理中心的應用程式套件探索工具下載及檢查成果。此外,Play Developer API 即將推出一項功能,可讓您先驗證 APK 後再提交至測試群組。您也可以選用應用程式套件的程式碼透明性功能。透過這項功能,您和使用者可以要求 Google Play 這類應用程式商店為自己交付的程式碼負責。

應用程式套件的程式碼透明性機制如何運作?

程式碼透明性是選用功能,您可以藉助此功能讓發行應用程式的應用程式商店為其交付的程式碼負責。如要使用程式碼透明性功能,請於建構期間在應用程式中產生代表程式碼的程式碼透明性檔案 (具體來說,就是包含應用程式程式碼雜湊的檔案)。您可以使用僅由您自己持有的私人程式碼透明性金鑰來簽署該檔案。您無需向 Google 提供程式碼透明性金鑰。然後,您可以在裝置上檢查已安裝的 APK,並確認您簽署的程式碼透明性檔案仍與 APK 的程式碼相符。這可以保證,即使 APK 本身已於發行期間完成重新簽署,但經過程式碼透明性驗證的程式碼仍未遭到修改。如果出現不相符的情形,則代表程式碼在發行期間有所變更。程式碼透明性不會取代 APK 簽名,也不屬於 Android 平台。

在 Google Play 上發布大型應用程式和遊戲

使用 AAB 時,Google Play 有何應用程式大小限制?

從 AAB 產生的任何一組 APK 經過壓縮後的下載大小上限為 200 MB。也就是說,Google Play 會根據您的 AAB 產生所有可能需要的 APK。接著,Google Play 會確認個別裝置所接收的壓縮下載大小上限未超過 200 MB。您上傳的 AAB 可能比這個值大上許多,在 Google Play 使用 APK 時不可能會產生那麼大的檔案。

Google Play 是否支援 AAB 的擴充檔案 (OBB)?

不,Google Play 不支援 AAB 的擴充檔案。擴充檔案 (OBB) 是舊版 Google Play 特有的解決方案,可使用 APK 發布大型應用程式和遊戲。有些 Google 和第三方廠商適用於大於 200 MB 的 AAB。

如何在 Google Play 上發布大小超過 200 MB 的應用程式或遊戲?

使用 AAB 的大型應用程式和遊戲可以利用 Play 交付服務 (如 Play Asset Delivery 或 Play Feature Delivery) 來打破 200 MB 的大小限制,也可以使用第三方內容傳遞聯播網。

與擴充檔案 (OBB) 相比,Play Asset Delivery 有何優勢?

在 Google Play 中,APK 需要單獨的擴充檔案 (OBB) 才能為使用者提供其他資源。不過,由於 OBB 尚未簽署且儲存在應用程式的外部儲存空間中,因此並不是十分安全。使用 Play Asset Delivery (PAD) 之後,大小超過 200 MB 的遊戲就可以取代 OBB,在 Play 商店中以單一應用程式套件的形式發布整個遊戲。除了提供更順暢的發布程序和靈活的交付模式外,PAD 還意味著更新所需的裝置儲存空間更少,進而能夠提升安裝率。最後,現在約有 80% 的裝置支援 ASTC,您可以利用 PAD 的紋理壓縮格式指定功能,將 ASTC 提供給支援的裝置。您能夠以大量裝置為目標,同時有效運用可用的硬體和裝置儲存空間。

採用 AAB 格式後可使用哪些 Google Play 交付功能

Play 針對採用 AAB 格式的開發人員提供了哪些新功能?

Google Play 等應用程式商店會將 AAB 轉換為可安裝的 APK。負責任地維護 APK 有助於提供新功能和服務,為開發人員和使用者帶來諸多利益。Google Play 已經提供受到開發人員廣泛採用和喜愛的諸多服務,例如 Play Feature DeliveryPlay Asset Delivery

Play Feature Delivery 是什麼?

應用程式套件的其中一項功能是能將應用程式拆分為多個模組,稱為「功能模組」。這些模組可在不同時間動態提供給使用者和裝置 (這與過去不同,過去是將所有內容做為單一檔案在安裝時提供)。Play Feature Delivery 可讓您自訂要在哪個裝置上提供哪些功能模組,以及選擇提供時間,時間選項包括「安裝時」、「符合條件時」以及「隨選提供模式」。這樣不但能縮減應用程式大小,也能帶來更多安裝量,並提供更符合需求的應用程式體驗。例如,您可以將客戶支援等極少使用的功能隨選提供給需要相應功能的使用者,而不是在安裝時提供,從而縮減所有使用者的初始安裝大小。或者,您也可以向高階裝置提供完整的應用程式體驗,而向資料和裝置儲存空間有限的入門級裝置提供較小的應用程式體驗,同時額外提供選用的隨選功能。

Play Asset Delivery 是什麼?

Play Asset Delivery 可讓遊戲開發人員在最佳時間動態提供大型資產,從而改善使用者體驗並縮短使用者等待時間。使用 Play Asset Delivery 的遊戲還可利用紋理壓縮格式指定功能,以便使用者只會取得適合其裝置的素材資源,而不會浪費空間或頻寬。

是否可以在其他應用程式商店使用這些 Play 交付功能?

不可以,Play Feature Delivery 和 Play Asset Delivery 只適用於與 Google Play 商店直接互動的應用程式和遊戲。Google Play 以獨到的功能和服務從眾多應用程式商店中脫穎而出,並為 Play 開發人員和使用者提供附加價值和實用性,這些選用服務正是典型的範例。使用應用程式套件和 APK 的其他應用程式商店也會為開發人員提供其自己的應用程式商店服務。