應用程式更新的運作方式
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本指南將說明 Android 平台和 Google Play 如何處理應用程式更新，並針對要在多個應用程式商店中發布應用程式的開發人員討論各種選項。
Android 如何處理應用程式更新
每個 Android 應用程式都有專屬的應用程式 ID，樣式類似於 Java 或 Kotlin 套件名稱，例如 com.example.myapp。這組 ID 可明確識別裝置上的每個應用程式。Android 裝置一次只能安裝一個具有指定應用程式 ID 的應用程式。
為了讓 Android 平台接受更新，應用程式必須符合下列條件：
- 更新版的應用程式 ID 必須與已安裝的應用程式相同。
- 更新版的簽署憑證必須與已安裝應用程式的簽署憑證相同，或是包含有效的輪替證明。
- 更新版的版本代碼必須高於或等於已安裝應用程式的版本代碼。
- 在某些情況下，使用者可能需要接受更新。
請注意，只要更新版具有相同的簽署憑證和相同或更高的版本代碼，系統就不會啟用內建功能來阻止透過不同安裝程式更新應用程式。
如要安裝不符合上述條件的應用程式，使用者必須先解除安裝目前安裝的版本，這項操作會從裝置清除所有應用程式資料。
Google Play 如何更新應用程式
Google Play 會根據下列原則，採用適當的應用程式更新方式：
- 讓使用者保持最新狀態。建議您讓應用程式保持在最新狀態，除了確保使用者的安全，避免發生安全性問題外，還能讓他們享有最新改善功能。
- 尊重使用者的選擇。Google Play 會根據使用者所選更新偏好設定，更新與使用者帳戶相關聯的應用程式，例如允許或禁止使用計量付費資料。
- 尊重開發人員的選擇。Google Play 在判斷應用程式更新時，會採用開發人員的設定選項。
- 避免浪費資源。在最佳時機下載更新，藉此保留電池續航力，並利用壓縮和修補等技術盡可能減少資料用量。
針對已安裝在裝置上的特定應用程式，Google Play 會在應用程式符合下列條件時進行更新：
- 應用程式已在 Google Play 發布，且具有相同的應用程式 ID。
- 已發布應用程式的簽署憑證與目前安裝版本的簽署憑證相符，或者包含有效的輪替證明。
- 應用程式屬於使用者的程式庫，或是由原始設備製造商 (OEM) 預先載入。
- 根據開發人員定義的指定目標選項，此使用者和此裝置可使用該應用程式。
- 與 Google Play 提供的版本相比，已安裝的應用程式已過時。
只要符合這些條件，Google Play 就能更新應用程式。下列各子節詳細說明瞭列出的部分條件。
請注意，有時 Google Play 會代表開發人員下載應用程式內容，或在應用程式二進位檔上執行維護作業，而不變更 Android 版本代碼，例如完成部分下載或下載隨選分割。
在 Google Play 發布
Google Play 會使用應用程式 ID 來識別在 Google Play 發布的應用程式。如果已安裝的應用程式與在 Google Play 發布的應用程式，兩者應用程式 ID 相符，就符合這項條件。
屬於使用者的程式庫
只要發生下列任一情形，就算符合這項條件：
- 裝置上任何有效的 Google 帳戶，先前都是透過輕觸 Google Play 的安裝或購買按鈕取得應用程式。
- 原始設備製造商 (OEM) 在系統映像檔中預先載入應用程式。
使用者也可以手動從程式庫中移除應用程式。
版本過時
Google Play 會檢查版本代碼，藉此判斷裝置上安裝的應用程式版本是否已過時。如果 Google Play 提供的下載版本具有高於安裝版本的版本代碼，Google Play 就會將安裝版應用程式視為過時。
在多個應用程式商店發布應用程式
在多個應用程式商店發布應用程式時，您可以透過幾種方式控管跨商店更新。以下各節將說明這些選項及其潛在優缺點。
防止跨商店更新
您可能想要避免讓各個應用程式商店針對您的應用程式執行任何跨商店應用程式更新。如果您在每個應用程式商店中發布的應用程式內容都不同，就可以選擇這麼做。方法是使用兩個不同的應用程式 ID 發布應用程式，或是使用相同的應用程式 ID 和兩個不同的簽署金鑰發布應用程式。
建議您盡量不要重複使用簽署金鑰，以降低金鑰遭到盜用的風險，因此請為每個應用程式商店使用不同的應用程式簽署金鑰，這樣可以防止跨商店更新。
無論選擇哪種方法，Android 都會將缺少相符應用程式 ID 和簽署金鑰的應用程式視為不相容。如果使用者想從某個商店切換至另一個商店，就必須刪除已安裝的應用程式 (這麼做會刪除與該應用程式相關聯的所有資料)，然後從另一個商店重新安裝。
允許跨商店更新
您可能想要讓各個應用程式商店針對您的應用程式執行跨商店應用程式更新。如果您在所有應用程式商店中發布的內容都相同，並且想優先確保使用者處於最新狀態，就可以選擇這麼做。只要在您發布應用程式的所有應用程式商店中使用相同的應用程式 ID 和簽署金鑰，那麼無論使用者原本在哪裡下載應用程式，每個應用程式商店都可以更新應用程式的安裝程式。
不過，視每個應用程式商店選擇實作跨商店應用程式更新的方式而定，這可能會導致使用者無法預測的行為。例如，使用者可能會停用某個商店的更新，但沒想到其他商店可以繼續提供更新。
如果您先前允許跨商店更新，但想要優先使用裝置提供的特定更新來源，那麼您可以在偏好的應用程式商店中，使用較高的版本代碼發布該應用程式，並持續在其他應用程式商店中使用較低的版本代碼發布該應用程式。從偏好來源安裝較高版本代碼的更新後，其他應用程式商店就無法在該裝置上執行交叉更新。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# How app updates work\n\nThis guide explains how the Android platform and Google Play handle app updates\nand discusses various options for developers who publish their apps on multiple\napp stores.\n\nHow Android handles app updates\n-------------------------------\n\nEvery Android app has a unique [application\nID](/studio/build/configure-app-module#set-application-id) that looks like a\nJava or Kotlin package name, such as `com.example.myapp`. This ID uniquely\nidentifies each app on the device. Android devices can only have one app with a\ngiven application ID installed at a time.\n\nIn order for an update to be accepted by the Android platform, the following\nconditions must be met:\n\n- The application ID of the update must be the same as the installed app.\n- The signing certificate of the update must be the same as the signing certificate of the installed app, or it must contain a valid [proof-of-rotation](https://source.android.com/docs/security/features/apksigning/v3).\n- The version code of the update must be higher or equal to the version code of the installed app.\n- In some cases, the user may need to [accept the\n update](/reference/android/content/pm/PackageInstaller.SessionParams#setRequireUserAction(int)).\n\nNote that there is no built-in prevention against different installers updating\nan app when the updates have the same signing certificate and the same or higher\nversion code.\n\nTo install an app that doesn't meet the conditions above, a user must first\nuninstall the currently installed version, which erases all app data from the\ndevice.\n\nHow Google Play updates apps\n----------------------------\n\nGoogle Play's approach to updating apps is based on the following principles:\n\n- **Keep users up to date.** Keeping apps up to date is recommended to keep users safe from security issues and benefit from the latest feature improvements.\n- **Respect user choice.** Google Play updates apps that are associated with users' accounts and based on their chosen update preferences, such as allowing or disallowing the use of metered data.\n- **Respect developer choice.** Google Play uses the developers' configuration options when determining app updates.\n- **Avoid wasted resources.** Conserve battery life by optimizing when updates are downloaded, and minimize data use using techniques such as compression and patching.\n\nFor a given app installed on a device, Google Play updates the app if it meets\nthe following conditions:\n\n- The app is [published on Google Play](#published-on-play) with the same application ID.\n- The published app's signing certificate matches the currently installed version's signing certificate, or it contains a valid [proof-of-rotation](https://source.android.com/docs/security/features/apksigning/v3).\n- The app is [part of the user's library](#user-library), or was preloaded by an OEM.\n- The app is available for this user and this device, according to the developer-defined targeting options.\n- The installed app is [out of date](#out-of-date), compared to the version available on Google Play.\n\nAs long as these conditions are met, Google Play is able to update the app. The\nsubsections below provide detail on some of the conditions listed.\n\nNote that there are other times when Google Play downloads app content or\nperforms maintenance on app binaries on developers' behalf without changing the\nAndroid version code---for example, when completing partial downloads or\ndownloading on-demand\n[splits](/reference/tools/gradle-api/7.4/com/android/build/api/dsl/Splits).\n\n### Published on Google Play\n\nGoogle Play uses the application ID to uniquely identify applications published\non Google Play. This condition is met if the installed app's application ID\nmatches the application ID of an app published on Google Play.\n\n### Part of user's library\n\nThis condition is met if one of the following is true:\n\n- Any active Google Account on the device has previously acquired the app by tapping the install or purchase button on Google Play.\n- The OEM preloaded the app as part of the system image.\n\nUsers also have the ability to manually remove apps from their\n[libraries](https://play.google.com/apps).\n\n### Out of date\n\nGoogle Play determines whether an app installed on a device is out of date by looking at the version code---if the version available for download on Google Play has a higher version code than the installed version, then Google Play considers the installed app to be out of date.\n\nApps on multiple app stores\n---------------------------\n\nThere are a few ways that you can control cross-store updates when you publish\nan app on multiple app stores. The following sections cover these options and\ntheir potential benefits and drawbacks.\n\n### Prevent cross-store updates\n\nYou might want to prevent each app store from performing any cross-store app\nupdates for your app. You might choose to do this if the content of your app is\ndifferent on each app store. This can be achieved by publishing the app with two\ndifferent application IDs, or by publishing the app with the same application ID\nand two different signing keys.\n\nYou might want to minimize reuse of your signing key to reduce risk from a key\ncompromise, and so use a different app signing key for each app store. Doing so\nwould prevent cross-store updates.\n\nRegardless of which approach you choose, Android treats apps without a matching\napplication ID and signing key as incompatible. A user wishing to switch from\none store to another will need to delete the installed app---which will delete all\ndata associated with that app---and reinstall from the other store.\n\n### Allow cross-store updates\n\nYou might want to allow each app store to perform cross-store app updates for\nyour app. You might choose to do this if you distribute your app with the same\ncontent on all app stores and you want to prioritize users being up to date. As\nlong as you use the same application ID and signing keys across all app stores\nwhere you publish your app, then each app store has the ability to update\ninstallations of your app regardless of where the user downloaded the app\ninitially.\n\nHowever, this can lead to unpredictable behavior for your users depending on how\neach app store chooses to implement cross-store app updates. For example, a user\nmight disable updates from one store, not realizing that another store might\ncontinue to provide updates.\n\nIf you previously allowed cross-store updates but you want to start preferring a\nparticular update source when it's present on the device, you can release your\napp with a higher version code on your preferred app store and continue to\nrelease with lower version codes on other app stores. Once the higher version\ncode update from the preferred source has been installed, the other app stores\nwill not be able to cross-update on that device."]]
