自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
适用于免安装应用的 CTS
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
免安装应用是 Android 10 的一项重要功能,因此必须确保这些应用能够正常运行。免安装应用是隐式安装的,因此它们仅具有有限的功能,并需要在限制更多的安全沙盒中运行。由于这些限制普遍存在,因此系统的任何部分都存在无法正常运行免安装应用的风险。为此,我们创建了一个 CTS 测试子集来确保免安装应用允许的行为正常运作。核心理念就是,尽可能少地隔离要移植的测试,以此来最大限度地限制 CTS 大小的增长。在免安装应用模式下运行 CTS,意味着将测试 APK 作为免安装应用进行安装并运行测试。
免安装应用限制
免安装应用并非由用户安装,因此它们需要在受限沙盒中运行,并受到以下限制:
- 只能拥有特定权限。
- 无法看到其他应用,除非这些应用已标记为对免安装应用可见。
- 只能访问特定的系统设置。
- 只能访问特定的系统属性。
- 无法公开服务/提供程序。
- 可以按照与广播有关的特殊规则收发消息。
此外,免安装应用还必须选择允许新的安全沙盒添加更多限制。免安装应用的这类特殊行为广泛存在于整个平台上,因此需要有一种方法来验证免安装应用是否能在生态系统中的所有设备上按预期运行。
在免安装应用模式下运行的测试
并非所有 CTS 模块都包含适用于免安装应用的测试。如果模块所测试的功能需要和系统服务器进行交互,那么这些测试就应该在免安装应用模式下运行。例如,OpenGL 测试不会和系统服务器进行交互,因此无需在免安装应用模式下运行,而无障碍功能测试需要和系统服务器进行交互,因此需要在免安装应用模式下运行。
用户除了需要确定哪些模块适用之外,还需要确定这些模块中的哪些测试是相关的。例如,测试可插拔架构(例如 AccessibilityService)的服务特定行为不适用于免安装应用模式,因为免安装应用无法向其他应用(包括平台)公开服务,而验证应用端行为的测试则适用于免安装应用模式。再比如,如果某个免安装应用无法拥有某项权限,则验证此权限背后的行为的测试不适用于免安装应用模式。有一组仅适用于免安装应用的测试,可用于验证与此类应用的行为方式(例如,不公开服务或看不到其他应用)有关的规则。通常情况下,这些测试已经编写好,且不需要移植。
免安装应用模式下的测试失败情况
如果测试因验证免安装应用无法访问的功能而失败,则表示该测试不适合在免安装应用模式下运行。您可以使用 @AppModeFull
注释测试,将其标记为仅可在完整应用模式下运行。您可以在类级别应用此注释,以排除类中的所有测试。
如果测试因免安装应用可以访问的某项功能被破坏而失败,请提交错误。
问题排查
如果您的测试失败并且系统显示“Failed to install MyCtsModule.apk on DEVICE. Reason: '-116'”消息,请在 logcat 上查找 PackageManager 消息。例如,如果系统显示“Can't replace Full App with Instant App: your_app”消息,则 adb 会先卸载您的应用。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-05-08。
[null,null,["最后更新时间 (UTC):2025-05-08。"],[],[],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."]]