自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
免安裝應用程式的 CTS
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
即時應用程式是 Android 10 的關鍵功能,因此必須確保其正常運作。即時應用程式是隱含安裝的,因此功能受限,且在更嚴格的安全沙箱中執行。由於這些限制的普遍性,系統的任何部分都可能無法正常與即時應用程式搭配運作。建立 CTS 測試子集,確保免安裝應用程式允許的行為正常運作。重點在於隔離要移植的測試最小組合,盡量減少 CTS 的大小成長。在免安裝應用程式模式中執行 CTS 是指將測試 APK 設為免安裝應用程式並執行測試。
免安裝應用程式限制
使用者不會安裝即時應用程式,因此這些應用程式會在受限沙箱中執行,並受到下列限制:
- 只能包含特定權限。
- 除非這些應用程式標示為可供 Instant Apps 瀏覽,否則無法查看其他應用程式。
- 只能存取特定系統設定。
- 只能存取特定系統屬性。
- 無法公開服務/供應器。
- 可透過廣播的特殊規則接收及傳送內容。
此外,即時應用程式必須選擇加入,才能允許新的安全性沙箱新增更多限制。免安裝應用程式相關的特殊行為範圍廣泛,涵蓋整個平台,因此需要有一種方法,可驗證免安裝應用程式是否可在生態系統中的所有裝置上正常運作。
在免安裝應用程式模式下執行的測試
並非所有 CTS 模組都有適用於 Instant Apps 的測試。如果模組測試的功能會與系統伺服器互動,則應在即時應用程式模式下執行這些測試。舉例來說,OpenGL 測試不會與系統伺服器互動,因此不需要在「免安裝應用程式」模式下執行,但無障礙測試會與系統伺服器互動,因此需要在「免安裝應用程式」模式下執行。
除了找出適用的模組,使用者還需要判斷這些模組中的哪些測試相關。舉例來說,針對可插入式架構 (例如 AccessibilityService) 測試服務專屬行為,不適用於即時應用程式模式,因為即時應用程式無法將服務公開給其他應用程式 (包括平台),但測試驗證應用程式端行為適用於即時應用程式模式。另一個例子是測試,驗證免安裝應用程式無法保留的權限背後的行為,在免安裝應用程式模式中不相關。我們有一系列只適用於免安裝應用程式的測試,可驗證免安裝應用程式的行為規則,例如不公開服務或不顯示其他應用程式。通常這些程式碼已編寫完成,因此不需要轉移。
在免安裝應用程式模式中測試失敗
如果測試驗證的是免安裝應用程式無法存取的功能,則無法在免安裝應用程式模式中使用。如要將測試標示為僅在「完整應用程式」模式下執行,請加上 @AppModeFull
註解。您可以將這個註解套用至類別層級,藉此排除其中的所有測試。
如果測試失敗,是因為部分可供免安裝應用程式存取的功能無法正常運作,請回報錯誤。
疑難排解
如果測試失敗,並顯示「在裝置上無法安裝 MyCtsModule.apk」,原因:'-116',請在 logcat 中尋找 PackageManager 訊息。舉例來說,如果顯示「Can't replace Full App with Instant App: your_app」,表示 adb 會先解除安裝您的應用程式。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# CTS for Instant Apps\n\nInstant Apps are a key feature of 10, so it's essential that they work\nproperly. Instant Apps are implicitly installed, so they have a restricted set of\ncapabilities and run in a more restrictive security sandbox. Due to the pervasive nature\nof these restrictions, any part of the system is at risk for not properly working with Instant\nApps. A CTS test subset is created to ensure that behaviors allowed by Instant Apps are\nworking. The key idea is to minimize the size growth of CTS by isolating the\nminimal set of tests to port. CTS running in Instant Apps mode means\ninstalling the test APK as an Instant App and running the tests.\n\nInstant App restrictions\n------------------------\n\n\nInstant Apps aren't installed by the user, so they run in a restricted sandbox with\nthe following restrictions:\n\n- Can hold only certain permissions.\n- Can't see other apps unless those apps are marked as visible to Instant Apps.\n- Can access only certain system settings.\n- Can access only certain system properties.\n- Can't expose services/providers.\n- Can receive and send with special rules around broadcasts.\n\n\nIn addition, Instant Apps have to opt in to allowing the new security sandbox to add more\nrestrictions. This wide range of special behaviors around Instant Apps cross cut\nthe entire platform, so there needs to be a way to validate that Instant Apps work as expected for all\ndevices in the ecosystem.\n\nTests running in Instant Apps mode\n----------------------------------\n\n\nNot all CTS modules have tests applicable to Instant Apps. If the functionality tested by\nthe module has interaction with the system server, then these tests should be run in the\nInstant Apps mode. For example, the OpenGL tests aren't interacting with the system server and so\nthere's no need to run them in Instant Apps mode while the accessibility tests interact with the\nsystem server but there is a need to run them in Instant Apps mode.\n\n\nIn addition to identifying which modules are applicable, users need to determine\nwhich tests in these modules are relevant. For example, testing service-specific behaviors for\na pluggable architecture (for example, AccessibilityService) isn't applicable for Instant App\nmode as Instant Apps can't expose services to other apps (including the platform) while tests\nvalidating app-side behaviors are applicable for Instant Apps mode. Another example is a test that\nvalidates behaviors behind a permission that an Instant App can't hold aren't relevant in Instant\nApp mode. There's a set of tests that apply only to Instant Apps that validate the rules around\nhow they behave, for example, not exposing services, or not seeing other apps. Typically,\nthese are already written and don't require porting.\n\nTest failures in Instant Apps mode\n----------------------------------\n\n\nIf the test is failing because it validates functionality that Instant Apps can't access, then it\nisn't applicable in Instant Apps mode. Mark the test to run only in Full App mode by annotating\nit with `@AppModeFull`. You can apply this annotation to the class level to exclude all\ntests in it.\n\n\nIf the test fails because some functionality accessible to Instant Apps is broken,\n[file a bug](/docs/setup/contribute/report-bugs).\n\nTroubleshooting\n---------------\n\n\nIf your test fails with *Failed to install MyCtsModule.apk on DEVICE. Reason: '-116'* ,\nlook for PackageManager messages on logcat. For example, if it says *Can't replace Full\nApp with Instant App: your_app*, then adb uninstall your app first."]]