Instant Apps are a key feature of 10, so it's essential that they work properly. Instant Apps are implicitly installed, so they have a restricted set of capabilities and run in a more restrictive security sandbox. Due to the pervasive nature of these restrictions, any part of the system is at risk for not properly working with Instant Apps. A CTS test subset is created to ensure that behaviors allowed by Instant Apps are working. The key idea is to minimize the size growth of CTS by isolating the minimal set of tests to port. CTS running in Instant Apps mode means installing the test APK as an Instant App and running the tests.
Instant App restrictions
Instant Apps aren't installed by the user, so they run in a restricted sandbox with the following restrictions:
- Can hold only certain permissions.
- Can't see other apps unless those apps are marked as visible to Instant Apps.
- Can access only certain system settings.
- Can access only certain system properties.
- Can't expose services/providers.
- Can receive and send with special rules around broadcasts.
In addition, Instant Apps have to opt in to allowing the new security sandbox to add more restrictions. This wide range of special behaviors around Instant Apps cross cut the entire platform, so there needs to be a way to validate that Instant Apps work as expected for all devices in the ecosystem.
Tests running in Instant Apps mode
Not all CTS modules have tests applicable to Instant Apps. If the functionality tested by the module has interaction with the system server, then these tests should be run in the Instant Apps mode. For example, the OpenGL tests aren't interacting with the system server and so there's no need to run them in Instant Apps mode while the accessibility tests interact with the system server but there is a need to run them in Instant Apps mode.
In addition to identifying which modules are applicable, users need to determine which tests in these modules are relevant. For example, testing service-specific behaviors for a pluggable architecture (for example, AccessibilityService) isn't applicable for Instant App mode as Instant Apps can't expose services to other apps (including the platform) while tests validating app-side behaviors are applicable for Instant Apps mode. Another example is a test that validates behaviors behind a permission that an Instant App can't hold aren't relevant in Instant App mode. There's a set of tests that apply only to Instant Apps that validate the rules around how they behave, for example, not exposing services, or not seeing other apps. Typically, these are already written and don't require porting.
Test failures in Instant Apps mode
If the test is failing because it validates functionality that Instant Apps can't access, then it
isn't applicable in Instant Apps mode. Mark the test to run only in Full App mode by annotating
it with @AppModeFull. You can apply this annotation to the class level to exclude all
tests in it.
If the test fails because some functionality accessible to Instant Apps is broken, file a bug.
Troubleshooting
If your test fails with Failed to install MyCtsModule.apk on DEVICE. Reason: '-116', look for PackageManager messages on logcat. For example, if it says Can't replace Full App with Instant App: your_app, then adb uninstall your app first.