2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
인스턴트 앱용 CTS
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
인스턴트 앱은 10의 핵심 기능이므로 제대로 작동하는 것이 중요합니다. 인스턴트 앱은 암시적으로 설치되므로 제한된 기능 세트를 가지며 더 제한적인 보안 샌드박스에서 실행됩니다. 이러한 제한사항의 광범위한 특성으로 인해 시스템의 일부가 인스턴트 앱과 제대로 작동하지 않을 위험이 있습니다. CTS 테스트 하위 세트를 생성하여 인스턴트 앱에서 허용하는 동작이 작동하는지 확인할 수 있습니다. 핵심 아이디어는 최소한의 테스트 세트를 포트로 분리하여 CTS의 크기 증가를 최소화하는 것입니다. 인스턴트 앱 모드에서 CTS 실행은 곧 테스트 APK를 인스턴트 앱으로 설치하여 테스트를 실행한다는 것을 의미합니다.
인스턴트 앱 제한사항
인스턴트 앱은 사용자가 설치하지 않으므로 제한된 샌드박스에서 실행되며 다음 제한사항이 적용됩니다.
- 특정 권한만 보유할 수 있습니다.
- 다른 앱이 인스턴트 앱에 공개되는 대상으로 표시되지 않는 한 앱을 볼 수 없습니다.
- 특정 시스템 설정에만 액세스할 수 있습니다.
- 특정 시스템 속성에만 액세스할 수 있습니다.
- 서비스/제공자를 노출할 수 없습니다.
- 브로드캐스트와 관련된 특별한 규칙으로 수신하고 전송할 수 있습니다.
또한 인스턴트 앱은 새로운 보안 샌드박스에서 더 많은 제한사항을 추가할 수 있도록 선택해야 합니다. 인스턴트 앱과 관련된 광범위하고 특별한 특성은 플랫폼 전체에 적용되므로 인스턴트 앱이 모든 Android 기기에서 예상대로 작동하는지 확인하는 방법이 있어야 합니다
인스턴트 앱 모드에서 테스트 실행
일부 CTS 모듈에는 인스턴트 앱에 적용되는 테스트가 없습니다. 모듈에서 테스트한 기능이 시스템 서버와 상호작용한다면 이러한 테스트는 인스턴트 앱 모드에서 실행해야 합니다. 예를 들어 OpenGL 테스트는 시스템 서버와 상호작용하지 않으므로 인스턴트 앱 모드에서 이 테스트를 실행할 필요가 없지만, 접근성 테스트는 시스템 서버와 상호작용하므로 인스턴트 앱 모드에서 이 테스트를 실행할 필요가 있습니다.
적용 가능한 모듈을 식별하는 것 외에도 사용자는 이러한 모듈에서 어떤 테스트가 적절한지 결정해야 합니다. 예를 들어 플러그형 아키텍처(예: AccessibilityService)의 서비스별 동작 테스트는 인스턴트 앱 모드에 적용할 수 없습니다. 인스턴트 앱이 플랫폼을 포함한 다른 앱에 서비스를 노출할 수 없기 때문입니다. 하지만 앱 측 동작의 유효성을 검사하는 테스트는 인스턴트 앱 모드에 적용할 수 있습니다. 또 다른 예는 인스턴트 앱이 보유할 수 없는 권한 뒤에 있는 동작의 유효성을 검사하는 테스트지만 인스턴트 앱 모드에서는 적절하지 않습니다. 예를 들어 서비스를 노출하지 않거나 다른 앱을 볼 수 없는 등의 동작 방식과 관련된 규칙을 검증하는 인스턴트 앱에만 적용되는 테스트 세트가 있습니다. 일반적으로 이러한 테스트는 이미 작성되어 있으며 포팅이 필요하지 않습니다.
인스턴트 앱 모드의 테스트 실패
인스턴트 앱이 액세스할 수 없는 기능의 유효성을 검사하기 때문에 테스트가 실패하면 이 테스트는 인스턴트 앱 모드에 적용할 수 없습니다. 테스트에 @AppModeFull
로 주석을 달아 테스트를 전체 앱 모드에서만 실행하도록 표시합니다. 이 주석을 클래스 수준에 적용하여 클래스 수준의 모든 테스트를 제외할 수 있습니다.
인스턴트 앱에서 액세스할 수 있는 일부 기능이 손상되어 테스트가 실패하면 버그를 신고합니다.
문제 해결
기기에 MyCtsModule.apk를 설치하지 못함, 이유: '-116'으로 테스트가 실패하면 logcat에서 PackageManager 메시지를 찾습니다. 예를 들어 메시지가 전체 앱을 인스턴트 앱으로 바꿀 수 없음: your_app이라고 표시되면 먼저 앱을 제거(adb uninstall)합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-05-09(UTC)
[null,null,["최종 업데이트: 2025-05-09(UTC)"],[],[],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."]]