Android 15 호환성 정의

1. 소개

이 문서는 기기가 Android 15와 호환되기 위해 충족해야 하는 요구사항을 설명합니다.

'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'OPTIONAL'의 사용은 RFC2119에 정의된 IETF 표준에 의거합니다.

이 문서에 사용된 '기기 구현자' 또는 '구현자'는 Android 15를 실행하는 하드웨어/소프트웨어 솔루션을 개발하는 개인 또는 조직을 의미합니다. '기기 구현' 또는 '구현'은 이렇게 개발된 하드웨어/소프트웨어 솔루션입니다.

Android 15 호환 기기로 간주되려면 기기 구현이 호환성 정의에 나와 있는 요구사항을 충족해야 하며, 참조를 통해 통합된 모든 문서의 요구사항도 충족해야 합니다(MUST).

섹션 10에서 설명한 정의 또는 소프트웨어 테스트가 묵시적이거나 모호하거나 불완전한 경우 기기 구현자에게는 기존 구현과의 호환성을 확인해야 할 책임이 있습니다.

따라서 Android 오픈소스 프로젝트가 Android의 참조 자료이자 선호되는 구현입니다. 기기 구현자가 최대한 Android 오픈소스 프로젝트에서 제공하는 '업스트림' 소스 코드를 구현의 기반으로 삼을 것을 적극 권장합니다(STRONGLY RECOMMENDED). 일부 구성요소는 이론적으로 대체 구현으로 교체가 가능하지만 소프트웨어 테스트를 통과하기가 매우 어려울 수 있으므로 이 방식을 따르지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED). 구현자에게는 전체 동작이 표준 Android 구현과 호환되는지 확인해야 할 책임이 있습니다. 여기에는 호환성 테스트 모음도 포함되며 이에 국한되지 않습니다. 마지막으로, 이 문서에서는 특정 구성요소를 대체하거나 수정하는 행위를 명시적으로 금지합니다.

이 문서에 링크된 다수의 리소스는 Android SDK에서 직간접적으로 파생되었으며 SDK 문서의 정보와 기능적으로 동일합니다. 이 호환성 정의 또는 호환성 테스트 모음이 SDK 문서와 불일치하는 경우에는 SDK 문서가 우선시됩니다. 이 문서 곳곳에 링크된 리소스에서 제공되는 모든 기술 세부정보는 이 호환성 정의의 일부로 포함된 것으로 간주됩니다.

1.1. 문서 구조

1.1.1. 기기 유형별 요구사항

섹션 2에는 특정 기기 유형에 적용되는 모든 요구사항이 포함되어 있습니다. 섹션 2의 각 하위 섹션은 특정 기기 유형 전용입니다.

Android 기기 구현에 공통으로 적용되는 모든 기타 요구사항은 섹션 2 이후의 섹션에 나열되어 있습니다. 이 문서에서는 이러한 요구사항을 '핵심 요구사항'이라고 부릅니다.

1.1.2. 요구사항 ID

요구사항 ID는 MUST 요구사항에 할당됩니다.

  • ID는 MUST 요구사항에만 할당됩니다.
  • STRONGLY RECOMMENDED 요구사항은 [SR]로 표시되지만 ID는 할당되지 않습니다.
  • ID는 기기 유형 ID-조건 ID-요구사항 ID(예: C-0-1)로 구성됩니다.

각 ID는 아래와 같이 정의됩니다.

  • 기기 유형 ID(자세한 내용은 2. 기기 유형 참고)
    • C: 핵심(Core, 모든 Android 기기 구현에 적용되는 요구사항)‏
    • H: Android 휴대기기(Handheld Device)
    • T: Android 텔레비전 기기(Television Device)
    • A: Android Automotive 구현(Automotive Implementation)
    • W: Android 시계 구현(Watch Implementation)
    • Tab: Android 태블릿 구현(Tablet Implementation)
  • 조건 ID
    • 요구사항에 조건이 없으면 이 ID는 0으로 설정됩니다.
    • 요구사항에 조건이 있으면 1이 첫 번째 조건에 할당되며, 같은 섹션 및 같은 기기 유형 내에서 1씩 수가 증가합니다.
  • 요구사항 ID
    • 이 ID는 1로 시작하며, 같은 섹션 및 같은 조건 내에서 1씩 증가합니다.

1.1.3. 섹션 2의 요구사항 ID

섹션 2의 요구사항 ID는 두 부분으로 구성됩니다. 첫 번째는 위에 설명한 대로 섹션 ID에 해당합니다. 두 번째 부분은 폼 팩터와 폼 팩터별 요구사항을 나타냅니다.

섹션 ID 뒤에 위에서 설명한 요구사항 ID가 옵니다.

  • 섹션 2의 ID는 섹션 ID/기기 유형 ID-조건 ID-요구사항 ID(예: 7.4.3/A-0-1)로 구성됩니다.

2. 기기 유형

Android 오픈소스 프로젝트는 다양한 기기 유형 및 폼 팩터에 사용할 수 있는 소프트웨어 스택을 제공합니다. 기기의 보안을 지원하려면 섹션 9와 이 CDD의 다른 부분에서 설명하는 것처럼 대체 OS 또는 대체 커널 구현을 포함한 소프트웨어 스택이 안전한 환경에서 실행되어야 합니다. 상대적으로 더 나은 애플리케이션 배포 생태계가 구축되어 있는 몇 가지 기기 유형이 있습니다.

이 섹션에서는 이러한 기기 유형, 그리고 각 기기 유형에 적용 가능한 추가적인 요구사항과 권장사항을 설명합니다.

설명한 기기 유형에 속하지 않는 모든 Android 기기 구현은 여전히 이 호환성 정의의 다른 섹션에 명시된 모든 요구사항을 충족해야 합니다(MUST).

2.1. 기기 구성

기기 유형별 하드웨어 구성의 주요 차이점은 이 섹션 바로 뒤에 나오는 기기별 요구사항을 참고하세요.

2.2. 휴대기기 요구사항

Android 휴대기기란 mp3 플레이어, 스마트폰 또는 태블릿처럼 주로 손에 쥐는 Android 기기 구현을 의미합니다.

Android 기기 구현은 다음과 같은 기준을 모두 충족하는 경우 휴대기기로 분류됩니다.

  • 배터리처럼 휴대성을 제공하는 전원이 있어야 합니다.
  • 화면의 실제 대각선 크기는 4인치에서 8인치 사이여야 합니다.
  • 터치 스크린 입력 인터페이스가 있어야 합니다.

이 섹션의 나머지 부분에 기재된 추가적인 요구사항은 Android 휴대기기 구현에만 해당합니다.

참고: Android 태블릿 기기에 적용되지 않는 요구사항은 *로 표시됩니다.

2.2.1. 하드웨어

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.1.1.1/H-0-1] 짧은 가장자리에서 최소 2.2인치, 긴 가장자리에서 최소 3.4인치로 측정되는 Android 호환 디스플레이가 하나 이상 있어야 합니다(MUST).

  • [7.1.1.3/H-SR-1] 사용자가 디스플레이 크기(화면 밀도)를 변경할 수 있도록 어포던스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [7.1.1.1/H-0-2] 적어도 모든 내장 디스플레이의 가장 높은 해상도만큼 그래픽 버퍼의 GPU 구성을 지원해야 합니다(MUST).

  • [7.1.1.1/H-0-3]* 서드 파티 애플리케이션에 사용할 수 있는 각 UI_MODE_NORMAL 디스플레이를 짧은 가장자리에서 최소 2.2인치, 긴 가장자리에서 최소 3.4인치인 가로막는 것이 없는 물리적 디스플레이 영역에 매핑해야 합니다(MUST).

  • [7.1.1.3/H-0-1]* DENSITY_DEVICE_STABLE 값을 해당 디스플레이의 실제 물리적 밀도보다 92% 이상으로 설정해야 합니다(MUST).

Configuration.isScreenHdr()을 통한 HDR 디스플레이 지원을 주장하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.1.4.5/H-1-1] EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, VK_EXT_hdr_metadata 확장 프로그램 지원을 알려야 합니다(MUST).

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.1.4.6/H-0-1] 기기가 시스템 속성 graphics.gpu.profiler.support를 통해 GPU 프로파일링 기능을 지원하는지 보고해야 합니다(MUST).

시스템 속성 graphics.gpu.profiler.support를 통해 지원을 선언하는 휴대기기 구현은 다음을 충족해야 합니다.

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.1.5/H-0-1] 업스트림 Android 오픈소스 코드로 구현된 레거시 애플리케이션 호환성 모드 지원을 포함해야 합니다(MUST). 즉, 기기 구현이 호환성 모드가 활성화되는 트리거 또는 기준점을 변경하면 안 되며(MUST NOT) 호환성 모드 자체의 동작을 변경해서도 안 됩니다(MUST NOT).
  • [7.2.1/H-0-1] 서드 파티 입력 방식 편집기(IME) 애플리케이션 지원을 포함해야 합니다(MUST).
  • [7.2.3/H-0-2] '뒤로' 기능(KEYCODE_BACK)의 보통 누르기 및 길게 누르기 이벤트를 모두 포그라운드 애플리케이션에 전송해야 합니다(MUST). 이러한 이벤트는 시스템에 의해 소비되어서는 안 되며(MUST NOT), Android 기기 외부에서 트리거될 수 있습니다(예: Android 기기에 연결된 외부 하드웨어 키보드)(CAN).
  • [7.2.3/H-0-3] 홈 화면을 제공하는 모든 Android 호환 디스플레이에 홈 기능을 제공해야 합니다(MUST).
  • [7.2.3/H-0-4] Android 호환 디스플레이는 모두 '뒤로' 기능을 제공해야 하며 최소 1개 이상의 Android 호환 디스플레이는 최근 항목 기능도 제공해야 합니다(MUST).
  • [7.2.4/H-0-1] 터치 스크린 입력을 지원해야 합니다(MUST).
  • [7.2.4/H-SR-1] 사용자가 선택한 지원 앱을 실행할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 즉 VoiceInteractionService를 구현하는 앱, 또는 포그라운드 활동이 길게 누르기 이벤트를 처리하지 않는 경우 KEYCODE_MEDIA_PLAY_PAUSE 또는 KEYCODE_HEADSETHOOK를 길게 눌렀을 때 ACTION_ASSIST를 처리하는 활동을 구현하는 앱을 실행하는 것이 좋습니다.
  • [7.3.1/H-SR-1] 3축 가속도계를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 가속도계를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.3.1/H-1-1] 최소 100Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).

GPS/GNSS 수신기를 포함하고 android.hardware.location.gps 기능 플래그를 통해 애플리케이션에 기능을 보고하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.3.3/H-2-1] GPS/GNSS에서 계산된 위치가 아직 보고되지 않은 경우에도 감지되는 즉시 GNSS 측정을 보고해야 합니다(MUST).
  • [7.3.3/H-2-2] 위치 파악 이후 정지해 있거나 0.2m/s2 가속도 미만으로 이동해도 open-sky 조건에서 20m 이내의 위치 및 초당 0.2m 내의 속도를 시간 중 95% 이상 계산하는 데 충분한 GNSS 의사 거리 및 의사 거리 비율을 보고해야 합니다(MUST).

3축 자이로스코프를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/H-3-1] 최소 100Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [7.3.4/H-3-2] 초당 최대 1,000도의 방향 변화를 측정할 수 있어야 합니다(MUST).

음성 통화를 걸 수 있고 getPhoneType의 PHONE_TYPE_NONE 외의 값을 나타낼 수 있는 휴대기기는 다음을 충족해야 합니다.

  • [7.3.8/H] 근접 센서를 포함해야 합니다(SHOULD).

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.3.11/H-SR-1] 자유도가 6도인 포즈 센서를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.4.3](2024년 4월 8일 미리보기)

  • [7.4.3/H] 블루투스 및 블루투스 LE 지원을 포함해야 합니다(SHOULD).
  • [7.4.3/H-0-1] 블루투스 및 블루투스 LE 지원을 포함해야 합니다(MUST).

블루투스 LE 지원을 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.4.3/H-SR-1] 블루투스 LE 데이터 패킷 길이 확장 프로그램을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

[7.4.3](2024년 2월 26일 미리보기)

  • [7.4.3/H-0-1] 블루투스 및 블루투스 LE 지원을 포함해야 합니다(MUST).
  • [7.4.3/H-0-2] 블루투스 4.2를 지원해야 합니다(MUST).
  • [7.4.3/H-SR-1] 블루투스 LE 데이터 패킷 길이 확장 프로그램을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

[7.4.3](2023년 12월 11일 미리보기)

  • [7.4.3/H-0-1] 블루투스 및 블루투스 LE 지원을 포함해야 합니다(MUST).
  • [7.4.3/H-0-2] 블루투스 4.2 및 블루투스 LE 데이터 길이 확장 프로그램을 지원해야 합니다(MUST).
  • [7.4.3/H-0-3] 최소 247바이트의 GATT ATT_MTU를 지원해야 합니다(MUST).
  • [7.4.3/H-0-4] Matter 1.0 핵심 사양의 정의에 따라 3가지 특성 C1, C2, C3을 갖는 BTP 서비스를 지원해야 합니다(MUST).

새로운 요구사항 종료

PackageManager.FEATURE_WIFI_AWARE를 선언하여 Wi-Fi NAN(Neighbor Awareness Networking) 프로토콜을 지원하고 PackageManager.FEATURE_WIFI_RTT를 선언하여 Wi-Fi 위치(Wi-Fi 왕복 시간 — RTT)를 지원하는 기기는 다음을 충족해야 합니다.

  • [7.4.2.5/H-1-1] WifiRttManager#startRanging Android API를 통해 관찰한 대로 10cm, 1m, 3m, 5m 거리의 68번째 백분위수(누적 분포 함수로 계산한 대로)에서 160MHz 대역폭의 +/-1m 이내까지, 68번째 백분위수에서 80MHz 대역폭의 +/-2m 이내까지, 68번째 백분위수에서 40MHz 대역폭의 +/-4m 이내까지, 68번째 백분위수에서 20MHz 대역폭의 +/-8m 이내까지 정확하게 범위를 보고해야 합니다(MUST).

  • [7.4.2.5/H-SR-1] WifiRttManager#startRanging Android API를 통해 관찰한 대로 10cm 거리의 90번째 백분위수(누적 분포 함수로 계산한 대로)에서 160MHz 대역폭의 +/-1m 이내까지, 90번째 백분위수에서 80MHz 대역폭의 +/-2m 이내까지, 90번째 백분위수에서 40MHz 대역폭의 +/-4m 이내까지, 90번째 백분위수에서 20MHz 대역폭의 +/-8m 이내까지 정확하게 범위를 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

접속 보정에 지정된 측정 설정 단계를 따를 것을 적극 권장합니다(STRONGLY RECOMMENDED).

데이터 종량제 연결을 포함하는 휴대기기는 다음을 충족해야 합니다.

  • [7.4.7/H-1-1] 데이터 절약 모드를 제공해야 합니다(MUST).

CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA를 사용하여 기능을 나열하는 논리 카메라 기기를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.5.4/H-1-1] 기본으로 정상적인 시야(FOV)를 보유해야 하며(MUST) 50~95도여야 합니다(MUST).

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-0-1] 애플리케이션 비공개 데이터를 위한 최소 4GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).
  • [7.6.1/H-0-2] 커널 및 사용자 공간에 사용 가능한 메모리가 1GB 미만인 경우 ActivityManager.isLowRamDevice()에 대해 'true'를 반환해야 합니다(MUST).

휴대기기 구현이 32비트 ABI 지원만 선언하는 경우:

  • [7.6.1/H-1-1] 기본 디스플레이에서 최대 qHD(예: FWVGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 416MB여야 합니다(MUST).

  • [7.6.1/H-2-1] 기본 디스플레이에서 최대 HD+(예: HD, WSVGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 592MB여야 합니다(MUST).

  • [7.6.1/H-3-1] 기본 디스플레이에서 최대 FHD(예: WSXGA+)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 896MB여야 합니다(MUST).

  • [7.6.1/H-4-1] 기본 디스플레이에서 최대 QHD(예: QWXGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1,344MB여야 합니다(MUST).

64비트 ABI(32비트 ABI 유무와 관계없음) 지원을 선언하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-5-1] 기본 디스플레이에서 최대 qHD(예: FWVGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 816MB여야 합니다(MUST).

  • [7.6.1/H-6-1] 기본 디스플레이에서 최대 HD+(예: HD, WSVGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 944MB여야 합니다(MUST).

  • [7.6.1/H-7-1] 기본 디스플레이에서 최대 FHD(예: WSXGA+)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1,280MB여야 합니다(MUST).

  • [7.6.1/H-8-1] 기본 디스플레이에서 최대 QHD(예: QWXGA)의 프레임 버퍼 해상도를 사용하는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1,824MB여야 합니다(MUST).

위에서 언급한 '커널 및 사용자 공간에 사용 가능한 메모리'는 기기 구현에서 커널의 제어를 받지 않는 라디오, 동영상 등의 하드웨어 구성요소에 이미 전용으로 사용되고 있는 모든 메모리 외에 추가로 제공되는 메모리 공간을 의미합니다.

커널 및 사용자 공간에 사용 가능한 메모리가 1GB 이하인 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-9-1] android.hardware.ram.low 기능 플래그를 선언해야 합니다(MUST).
  • [7.6.1/H-9-2] 애플리케이션 비공개 데이터를 위한 최소 1.1GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).

커널 및 사용자 공간에 사용 가능한 메모리가 1GB 이상인 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-10-1] 애플리케이션 비공개 데이터를 위한 최소 4GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).
  • 기능 플래그 android.hardware.ram.normal을 선언해야 합니다(SHOULD).

커널 및 사용자 공간에 사용 가능한 메모리가 2GB 이상이고 4GB 미만인 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-SR-1] 32비트 사용자 공간(앱과 시스템 코드 모두)만 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

커널 및 사용자 공간에 사용 가능한 메모리가 2GB 미만인 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/H-1-1] 32비트 ABI만 지원해야 합니다(MUST).

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.6.2/H-0-1] 1GiB보다 작은 애플리케이션 공유 저장소를 제공해서는 안 됩니다(MUST NOT).
  • [7.7.1/H] 주변기기 모드를 지원하는 USB 포트를 포함해야 합니다(SHOULD).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.7.1/H-1-1](2023년 12월 11일 미리보기)

주변기기 모드를 지원하는 주변기기 모드에서 컨트롤러 조작을 지원하는 USB 포트를 포함하는 휴대기기는 다음을 충족해야 합니다.

  • [7.7.1/H-1-1] Android Open Accessory(AOA) API를 구현해야 합니다(MUST).

새로운 요구사항 종료

호스트 모드를 지원하는 USB 포트를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

휴대기기 구현은 다음을 충족해야 합니다.

  • [7.8.1/H-0-1] 마이크를 포함해야 합니다(MUST).
  • [7.8.2/H-0-1] 오디오 출력을 보유하고 android.hardware.audio.output을 선언해야 합니다(MUST).

VR 모드 지원을 위한 모든 성능 요구사항을 충족할 수 있고 이와 관련된 지원을 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.9.1/H-1-1] android.hardware.vr.high_performance 기능 플래그를 선언해야 합니다(MUST).
  • [7.9.1/H-1-2] android.app.Activity#setVrModeEnabled를 통해 VR 애플리케이션으로 사용 설정 가능한 android.service.vr.VrListenerService를 구현하는 애플리케이션을 포함해야 합니다(MUST).

섹션 7.7.2의 요구사항 외에 호스트 모드 및 구현(USB 오디오 클래스)에 1개 이상의 USB-C 포트를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.8.2.2/H-1-1] 다음과 같은 HID 코드의 소프트웨어 매핑을 제공해야 합니다(MUST).
함수 매핑 맥락 동작
A HID 사용 페이지: 0x0C
HID 사용: 0x0CD
커널 키: KEY_PLAYPAUSE
Android 키: KEYCODE_MEDIA_PLAY_PAUSE		 미디어 재생 입력: 짧게 누르기
출력: 재생 또는 일시중지
입력: 길게 누르기
출력: 음성 명령 실행
전송: 기기가 잠겨 있거나 화면이 꺼진 경우 android.speech.action.VOICE_SEARCH_HANDS_FREE 전송, 나머지 경우 android.speech.RecognizerIntent.ACTION_WEB_SEARCH 전송
수신 전화 입력: 짧게 누르기
출력: 통화 수락
입력: 길게 누르기
출력: 통화 거부
진행 중인 통화 입력: 짧게 누르기
출력: 통화 종료
입력: 길게 누르기
출력: 마이크 음소거 또는 음소거 해제
B HID 사용 페이지: 0x0C
HID 사용: 0x0E9
커널 키: KEY_VOLUMEUP
Android 키: VOLUME_UP		 미디어 재생, 진행 중인 통화 입력: 짧게 또는 길게 누르기
출력: 시스템 또는 헤드셋 볼륨 증가
C HID 사용 페이지: 0x0C
HID 사용: 0x0EA
커널 키: KEY_VOLUMEDOWN
Android 키: VOLUME_DOWN		 미디어 재생, 진행 중인 통화 입력: 짧게 또는 길게 누르기
출력: 시스템 또는 헤드셋 볼륨 감소
D HID 사용 페이지: 0x0C
HID 사용: 0x0CF
커널 키: KEY_VOICECOMMAND
Android 키: KEYCODE_VOICE_ASSIST		 전체. 모든 인스턴스에서 트리거될 수 있습니다. 입력: 짧게 또는 길게 누르기
출력: 음성 명령 실행
  • [7.8.2.2/H-1-2] 플러그 삽입 시 ACTION_HEADSET_PLUG를 트리거해야 합니다(MUST). 하지만 연결된 터미널 유형을 식별할 수 있도록 USB 오디오 인터페이스와 엔드포인트가 제대로 열거된 후에만 트리거해야 합니다(MUST).

감지된 USB 오디오 터미널 유형 0x0302는 다음을 충족해야 합니다.

  • [7.8.2.2/H-2-1] 'microphone' extra가 0으로 설정된 상태에서 인텐트 ACTION_HEADSET_PLUG를 브로드캐스트해야 합니다(MUST).

감지된 USB 오디오 터미널 유형 0x0402는 다음을 충족해야 합니다.

  • [7.8.2.2/H-3-1] 'microphone' extra가 1로 설정된 상태에서 인텐트 ACTION_HEADSET_PLUG를 브로드캐스트해야 합니다(MUST).

USB 주변기기가 연결되어 있는 동안 호출된 API AudioManager.getDevices()는 다음을 충족해야 합니다.

  • [7.8.2.2/H-4-1] USB 오디오 터미널 유형 필드가 0x0302인 경우 유형이 AudioDeviceInfo.TYPE_USB_HEADSET이고 역할이 isSink()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-2] USB 오디오 터미널 유형 필드가 0x0402인 경우 유형이 AudioDeviceInfo.TYPE_USB_HEADSET이고 역할이 isSink()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-3] USB 오디오 터미널 유형 필드가 0x0402인 경우 유형 AudioDeviceInfo.TYPE_USB_HEADSET이고 역할이 isSource()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-4] USB 오디오 터미널 유형 필드가 0x603인 경우 유형이 AudioDeviceInfo.TYPE_USB_DEVICE이고 역할이 isSink()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-5] USB 오디오 터미널 유형 필드가 0x604인 경우 유형이 AudioDeviceInfo.TYPE_USB_DEVICE이고 역할이 isSource()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-6] USB 오디오 터미널 유형 필드가 0x400인 경우 유형이 AudioDeviceInfo.TYPE_USB_DEVICE이고 역할이 isSink()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-4-7] USB 오디오 터미널 유형 필드가 0x400인 경우 유형이 AudioDeviceInfo.TYPE_USB_DEVICE이고 역할이 isSource()인 기기를 나열해야 합니다(MUST).

  • [7.8.2.2/H-SR-1] USB-C 오디오 주변기기 연결 시 USB 설명자를 열거하고 터미널 유형을 식별하고 인텐트 ACTION_HEADSET_PLUG를 1,000ms 내에 브로드캐스트할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.6/H-1-1 및 5.6/H-1-2](2024년 2월 5일 미리보기)

android.hardware.audio.output 및 android.hardware.microphone을 선언하는 휴대기기 구현의 경우에는 섹션 5.6의 RTL 및 TTL 요구사항을 참고하세요. 충족해야 합니다.

  • [5.6/H-1-1] 5회 측정 결과 평균 연속 왕복 지연 시간이 300ms 이하이고 평균 절대 편차가 30ms 미만이어야 합니다(MUST). 이때 데이터 경로는 '스피커에서 마이크', 3.5mm 루프백 어댑터(지원되는 경우), USB 루프백(지원되는 경우)입니다.

  • [5.6/H-1-2] 스피커에서 마이크까지의 데이터 경로에서 5회 이상 측정한 결과 평균 탭 투 톤 지연 시간이 300밀리초 이하여야 합니다(MUST).

새로운 요구사항 종료

선형 공진 액추에이터(LRA)는 질량이 원하는 모션 방향으로 이동하는 지배적 공진 주파수를 갖는 단일 질량 스프링 시스템입니다.

최소 하나의 범용 7.10 선형 공진 액추에이터를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.10/H] 일반적으로 기기를 손으로 잡거나 터치하는 위치 근처에 액추에이터를 배치해야 합니다(SHOULD).

  • [7.10/H] 기기의 자연스러운 방향의 X축(왼쪽에서 오른쪽)에서 햅틱 액추에이터를 이동해야 합니다(SHOULD).

X축 선형 공진 액추에이터(LRA)인 범용 햅틱 액추에이터를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [7.10/H] X축 LRA의 공진 주파수가 200Hz 미만이어야 합니다(SHOULD).

햅틱 상수 매핑을 따르는 휴대기기 구현은 다음을 충족해야 합니다.

2.2.2. 멀티미디어

휴대기기 구현은 다음과 같은 오디오 인코딩 및 디코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] MPEG-4 AAC 프로필(AAC LC)
  • [5.1/H-0-4] MPEG-4 HE AAC 프로필(AAC+)
  • [5.1/H-0-5] AAC ELD(향상된 저지연 AAC)

휴대기기 구현은 다음과 같은 동영상 인코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.2/H-0-1] H.264 AVC
  • [5.2/H-0-2] VP8
  • [5.2/H-0-3] AV1

휴대기기 구현은 다음과 같은 동영상 디코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9
  • [5.3/H-0-6] AV1

2.2.3. 소프트웨어

휴대기기 구현은 다음을 충족해야 합니다.

  • [3.2.3.1/H-0-1] SDK 문서의 설명처럼 ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, ACTION_CREATE_DOCUMENT 인텐트를 처리하는 애플리케이션을 보유해야 하며 DocumentsProvider API를 사용하여 문서 제공자 데이터에 액세스할 수 있도록 사용자에게 어포던스를 제공해야 합니다(MUST).
  • [3.2.3.1/H-0-2]* 여기에 나열된 다음 애플리케이션 인텐트로 정의한 모든 공개 인텐트 필터 패턴과 관련하여 인텐트 핸들러가 1개 이상의 애플리케이션 또는 서비스 구성요소를 미리 로드해야 합니다(MUST).
  • [3.2.3.1/H-SR-1] ACTION_SENDTO 또는 ACTION_SEND 또는 ACTION_SEND_MULTIPLE 인텐트를 처리할 수 있는 이메일 애플리케이션을 미리 로드하여 이메일을 보낼 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.4.1/H-0-1] android.webkit.Webview API의 온전한 구현을 제공해야 합니다(MUST).
  • [3.4.2/H-0-1] 일반 사용자의 웹 브라우징을 위한 독립형 브라우저 애플리케이션을 포함해야 합니다(MUST).
  • [3.8.1/H-SR-1] 바로가기, 위젯 및 widgetFeatures의 인앱 고정을 지원하는 기본 런처를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.1/H-SR-2] ShortcutManager API를 통해 서드 파티 앱에서 제공하는 추가적인 바로가기에 대한 빠른 액세스를 제공하는 기본 런처를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.1/H-SR-3] 앱 아이콘의 배지를 표시하는 기본 런처 앱을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.2/H-SR-1] 서드 파티 앱 위젯을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.3/H-0-1] 서드 파티 앱이 Notification 및 NotificationManager API 클래스를 통해 중요 이벤트를 사용자에게 알리도록 허용해야 합니다(MUST).
  • [3.8.3/H-0-2] 리치 알림을 지원해야 합니다(MUST).
  • [3.8.3/H-0-3] 사전 알림을 지원해야 합니다(MUST).
  • [3.8.3/H-0-4] 알림 창을 포함하여 사용자가 AOSP에 구현된 작업 버튼 또는 제어판 등의 사용자 어포던스를 통해 알림을 직접 제어(예: 답장, 일시중지, 닫기, 차단)할 수 있도록 해야 합니다(MUST).
  • [3.8.3/H-0-5] 알림 창의 RemoteInput.Builder setChoices()를 통해 제공되는 옵션을 표시해야 합니다(MUST).
  • [3.8.3/H-SR-1] 추가적인 사용자 상호작용 없이 알림 창의 RemoteInput.Builder setChoices()를 통해 제공되는 첫 번째 옵션을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.3/H-SR-2] 사용자가 알림 창의 모든 알림을 펼칠 때 알림 창의 RemoteInput.Builder setChoices()를 통해 제공되는 모든 옵션을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.3.1/H-SR-1] Notification.Remoteinput.Builder.setChoices에 의해 표시된 답장에 맞게 Notification.Action.Builder.setContextual이 true로 설정된 작업을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.8.4/H-SR-1] 지원 작업 처리를 위한 어시스턴트를 기기에 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

MediaStyle 알림을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.8.3.1/H-SR-2] 앱이 MediaSession 토큰으로 MediaStyle 알림을 게시할 때 사용자가 적절한 가용 미디어 경로 간에 전환할 수 있도록(예: 블루투스 기기 및 MediaRouter2Manager에 제공하는 경로) 시스템 UI에서 액세스하는 사용자 어포던스(예: 출력 전환기)를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

섹션 7.2.3에 설명된 최근 함수 탐색 키를 포함하는 기기 구현은 인터페이스를 변경하는 경우 다음을 충족해야 합니다.

  • [3.8.3/H-1-1] 화면 고정 동작을 구현해야 하며 기능을 전환할 수 있도록 사용자에게 설정 메뉴를 제공해야 합니다(MUST).

지원 작업을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.8.4/H-SR-2] 섹션 7.2.3에 설명된 지원 앱 실행을 위한 지정된 상호작용으로 HOME 키 길게 누르기를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 사용자가 선택한 지원 앱 즉, VoiceInteractionService 또는 ACTION_ASSIST 인텐트를 처리하는 활동을 구현하는 앱을 실행해야 합니다(MUST).

conversation notifications를 지원하고 알림 및 무음 비대화 알림과 별도의 섹션으로 그룹화하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.8.4/H-1-1]* 진행 중인 포그라운드 서비스 알림과 importance:high 알림을 제외하면 대화 알림을 비대화 알림보다 앞서 표시해야 합니다(MUST).

잠금 화면을 지원하는 Android 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.8.10/H-1-1] 미디어 알림 템플릿을 포함한 잠금 화면 알림을 표시해야 합니다(MUST).

보안 잠금 화면을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.9/H-1-1] Android SDK 문서에 정의된 모든 기기 관리 정책을 구현해야 합니다(MUST).

ControlsProviderService 및 Control API 지원을 포함하고 서드 파티 애플리케이션이 기기 제어를 게시하도록 허용하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.8.16/H-1-1] 기능 플래그 android.software.controls를 선언하고 이를 true로 설정해야 합니다(MUST).
  • [3.8.16/H-1-2] ControlsProviderService 및 Control API를 통해 서드 파티 애플리케이션이 등록한 제어에서 사용자가 즐겨 찾는 기기 제어를 추가, 수정, 선택, 작동할 수 있는 사용자 어포던스를 제공해야 합니다(MUST).
  • [3.8.16/H-1-3] 기본 런처의 세 가지 상호작용 내에서 이 사용자 어포던스에 액세스하는 권한을 제공해야 합니다(MUST).

  • [3.8.16/H-1-4] 사용자 어포던스에서 ControlsProviderService API 및 Control API에서 제공하는 특정 필드를 통해 컨트롤을 제공하는 각 서드 파티 앱의 이름과 아이콘을 정확하게 렌더링해야 합니다(MUST).

  • [3.8.16/H-1-5] ControlsProviderService와 Control Control.isAuthRequired API를 통해 서드 파티 애플리케이션이 등록한 컨트롤에서 앱이 지정한 인증이 간단한 기기 제어를 선택 해제할 수 있는 사용자 어포던스를 제공해야 합니다(MUST).

  • [3.8.16/H-1-6] 기기 구현은 다음과 같이 사용자 어포던스를 정확하게 렌더링해야 합니다(MUST).

    • 기기에서 config_supportsMultiWindow=true를 설정하고 앱이 유효한 활동(API에서 정의한 대로)의 ComponentName 등 ControlsProviderService 선언에서 메타데이터 META_DATA_PANEL_ACTIVITY를 선언하는 경우 앱은 이 사용자 어포던스에 언급된 활동을 삽입해야 합니다(MUST).
    • 앱이 메타데이터 META_DATA_PANEL_ACTIVITY를 선언하지 않으면 ControlsProviderService API에서 제공하는 지정된 필드와 Control API에서 제공하는 지정된 필드를 렌더링해야 합니다(MUST).

  • [3.8.16/H-1-7] 앱이 메타데이터 META_DATA_PANEL_ACTIVITY를 선언하는 경우 삽입된 활동을 실행할 때 EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS를 사용하여, [3.8.16/H-1-5]에서 정의된 설정 값을 전달해야 합니다(MUST).

반대로, 이러한 컨트롤을 구현하지 않는 휴대기기 구현은 다음을 충족해야 합니다.

작업 잠금 모드에서 실행되지 않는 휴대기기 구현은 콘텐츠를 클립보드에 복사할 때 다음을 충족해야 합니다.

  • [3.8.17/H-1-1] 데이터가 클립보드에 복사되었음을 알리는 확인 메시지(예: 썸네일 또는 '콘텐츠 복사됨' 알림)를 사용자에게 표시해야 합니다(MUST). 또한, 클립보드 데이터가 기기 간에 동기화된다면 이와 관련된 표시도 이 요구사항에 포함됩니다.

휴대기기 구현은 다음을 충족해야 합니다.

  • [3.10/H-0-1] 서드 파티 접근성 서비스를 지원해야 합니다(MUST).
  • [3.10/H-SR-1] TalkBack 오픈소스 프로젝트에서 제공하는 스위치 제어 및 TalkBack(사전 설치된 텍스트 음성 변환 엔진에서 지원되는 언어용) 접근성 서비스와 기능이 비슷하거나 이보다 뛰어난 접근성 서비스를 기기에서 미리 로드할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.11/H-0-1] 서드 파티 TTS 엔진 설치를 지원해야 합니다(MUST).
  • [3.11/H-SR-1] 기기에서 제공되는 언어를 지원하는 TTS 엔진을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.13/H-SR-1] 빠른 설정 UI 구성요소를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

FEATURE_BLUETOOTH 또는 FEATURE_WIFI 지원을 선언하는 Android 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.16/H-1-1] 컴패니언 기기 페어링 기능을 지원해야 합니다(MUST).

탐색 기능이 화면에 표시되는 경우 동작 기반 작업은 다음을 충족해야 합니다.

  • [7.2.3/H] 홈 기능의 동작 인식 영역이 화면 하단 기준 높이 32dp를 초과하면 안 됩니다(SHOULD NOT).

휴대기기 구현이 화면 왼쪽 및 오른쪽 가장자리의 동작으로 탐색 기능을 제공하는 경우 다음을 충족해 합니다.

  • [7.2.3/H-0-1] 탐색 기능의 각 동작 영역 측면의 너비가 40dp 미만이어야 합니다(MUST). 동작 영역의 기본 너비는 24dp여야 합니다(SHOULD).

보안 잠금 화면을 지원하고 커널 및 사용자 공간에 사용 가능한 메모리가 2GB 이상인 휴대기기 구현은 다음을 충족해야 합니다.

  • [3.9/H-1-2] android.software.managed_users 기능 플래그를 통해 관리 프로필 지원을 선언해야 합니다(MUST).

android.hardware.camera.any를 통해 카메라 지원을 선언하는 Android 휴대기기 구현은 다음을 충족해야 합니다.

설정 애플리케이션이 활동 임베딩을 사용하여 분할 기능을 구현하는 기기 구현은 다음을 충족해야 합니다.

사용자가 모든 종류의 전화를 걸 수 있도록 허용하는 기기 구현은 다음을 충족해야 합니다.

2.2.4. 성능 및 전력

  • [8.1/H-0-1] 일관적인 프레임 지연 시간. 프레임을 렌더링하기 위한 비일관적인 프레임 지연 시간 또는 지연이 초당 5프레임보다 자주 발생하면 안 되며(MUST NOT), 초당 1프레임 아래여야 합니다(SHOULD).
  • [8.1/H-0-2] 사용자 인터페이스 지연 시간. 기기 구현이 Android 호환성 테스트 모음(CTS)에서 정의한 10K 목록 항목 목록을 36초 이내에 스크롤하여 지연 시간이 짧은 사용자 환경을 보장해야 합니다(MUST).
  • [8.1/H-0-3] 작업 전환. 여러 애플리케이션이 실행된 경우, 실행 이후에 이미 실행 중인 애플리케이션을 다시 실행하는 데 소요되는 시간이 1초 미만이어야 합니다(MUST).

휴대기기 구현은 다음을 충족해야 합니다.

  • [8.2/H-0-1] 초당 최소 5MB의 순차 작성 성능을 보장해야 합니다(MUST).
  • [8.2/H-0-2] 초당 최소 0.5MB의 무작위 작성 성능을 보장해야 합니다(MUST).
  • [8.2/H-0-3] 초당 최소 15MB의 순차 판독 성능을 보장해야 합니다(MUST).
  • [8.2/H-0-4] 초당 최소 3.5MB의 무작위 판독 성능을 보장해야 합니다(MUST).

AOSP에 포함되었거나 AOSP에 포함된 기능을 확장하는 기기 전력 관리를 개선하는 기능을 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [8.3/H-1-1] 절전 모드 기능을 사용 설정 및 중지하기 위한 사용자 어포던스를 제공해야 합니다(MUST).
  • [8.3/H-1-2] 앱 대기 및 잠자기 절전 모드에서 제외된 모든 앱을 표시하기 위한 사용자 어포던스를 제공해야 합니다(MUST).

휴대기기 구현은 다음을 충족해야 합니다.

  • [8.4/H-0-1] Android 오픈소스 프로젝트 사이트에 문서화된 것처럼 각 하드웨어 구성요소의 전력 소모량 값과 시간 경과에 따른 대략적인 배터리 소모를 정의하는 구성요소별 전력 프로필을 제공해야 합니다(MUST).
  • [8.4/H-0-2] 모든 전력 소모량 값(mAh)을 보고해야 합니다(MUST).
  • [8.4/H-0-3] 각 프로세스의 UID별 CPU 전력 소모량을 보고해야 합니다(MUST). Android 오픈소스 프로젝트는 uid_cputime 커널 모듈 구현을 통해 요구사항을 충족합니다.
  • [8.4/H-0-4] adb shell dumpsys batterystats 셸 명령어를 통해 이러한 전력 사용량을 앱 개발자에게 제공해야 합니다(MUST).
  • [8.4/H] 하드웨어 구성요소 전력 사용량을 애플리케이션에 출처로 표시할 수 없는 경우 하드웨어 구성요소 자체를 출처로 표시해야 합니다(SHOULD).

화면 또는 동영상 출력을 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

휴대기기 구현은 다음을 충족해야 합니다.

  • [8.5/H-0-1] SDK 문서에 설명된 것과 같이 시작된 활성 포그라운드 서비스 또는 사용자가 시작한 작업이 있는 모든 앱과 이러한 서비스가 시작된 이후 각각의 경과 시간을 표시하는 사용자 어포던스를 제공해야 합니다(MUST).

  • [8.5/H-0-2] 포그라운드 서비스 또는 사용자가 시작한 작업을 실행하는 앱을 중지하는 사용자 어포던스를 제공해야 합니다(MUST).

2.2.5. 보안 모델

휴대기기 구현은 다음을 충족해야 합니다.

  • [9/H-0-1] android.hardware.security.model.compatible 기능을 선언해야 합니다(MUST).
  • [9.1/H-0-1] 서드 파티 앱이 android.permission.PACKAGE_USAGE_STATS 권한을 통해 사용 통계에 액세스할 수 있도록 허용하고, 사용자가 액세스 가능한 메커니즘을 제공하여 android.settings.ACTION_USAGE_ACCESS_SETTINGS 인텐트에 응답할 때 이러한 앱에 액세스하는 권한을 부여하거나 취소해야 합니다(MUST).

android.hardware.telephony 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/H-1-1] UserManager.isHeadlessSystemUserMode를 true로 설정하면 안 됩니다(MUST NOT).

휴대기기 구현은 다음을 충족해야 합니다.

  • [9.11/H-0-2] 격리된 실행 환경으로 키 저장소 구현을 백업해야 합니다(MUST).
  • [9.11/H-0-3] RSA, AES, ECDSA, HMAC 암호화 알고리즘 및 MD5, SHA1, SHA-2 계열 해시 함수를 구현하여 커널과 위에서 실행 중인 코드에서 안전하게 격리된 영역에서 Android 키 저장소 시스템의 지원되는 알고리즘을 제대로 지원해야 합니다(MUST). 안전한 격리는 커널 또는 사용자 공간 코드가 DMA를 포함한 격리된 환경의 내부 상태에 액세스하는 데 사용할 수 있는 모든 잠재적인 메커니즘을 차단해야 합니다(MUST). 업스트림 Android 오픈소스 프로젝트(AOSP)는 Trusty 구현을 사용하여 이러한 요구사항을 충족하지만 다른 ARM TrustZone 기반 솔루션이나 서드 파티에서 검토한, 올바른 하이퍼바이저 기반 격리의 안전한 구현도 대안이 될 수 있습니다.
  • [9.11/H-0-4] 격리된 실행 환경에서 잠금 화면 인증을 수행해야 하며, 인증에 성공한 경우에만 인증 귀속 키의 사용을 허용해야 합니다(MUST). 잠금 화면 사용자 인증 정보는 격리된 실행 환경에서만 잠금 화면 인증을 수행할 수 있도록 허용하는 방식으로 저장해야 합니다. 업스트림 Android 오픈소스 프로젝트는 이러한 요구사항을 충족하는 데 사용할 수 있는 게이트키퍼 하드웨어 추상화 계층(HAL)과 Trusty를 제공합니다.
  • [9.11/H-0-5] 증명 서명 키가 보안 하드웨어에 의해 보호되고 서명이 보안 하드웨어에서 수행되는 키 증명을 지원해야 합니다(MUST). 증명 서명 키는 키가 기기 식별자로 사용되지 않도록 충분히 많은 수의 기기에 공유해야 합니다(MUST). 이러한 요구사항을 충족할 수 있는 한 가지 방법은 최소 100,000개의 SKU가 생성되지 않은 이상 동일한 증명 키를 공유하는 것입니다. 100,000개 이상의 SKU가 생성된 경우에는 100,000개당 다른 키를 사용할 수 있습니다(MAY).

기기 구현이 이전 Android 버전에서 이미 출시되었다면 이러한 기기는 키 저장소가 격리된 실행 환경에서 지원되고 키 증명을 지원해야 한다는 요구사항을 충족할 필요가 없습니다. 다만 격리된 실행 환경에서 지원하는 키 저장소를 요구하는 android.hardware.fingerprint 기능을 선언하는 경우는 예외입니다.

보안 잠금 화면을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.11/H-1-1] 사용자가 가장 짧은 절전 모드 시간제한(잠금 해제에서 잠금 상태로의 전환 시간)을 15초 이내로 선택할 수 있도록 허용해야 합니다(MUST).
  • [9.11/H-1-2] 알림을 숨기고 9.11.1 보안 잠금 화면에서 설명된 기본 인증을 제외한 모든 형식의 인증을 사용 중지할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). AOSP는 잠금 모드로 요구사항을 충족합니다.

보안 잠금 화면이 있고 TrustAgentService System API를 구현하는 1개 이상의 Trust Agent를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [9.11.1/H-1-1] 72시간마다 한 번 이상, 권장되는 기본 인증 방법(예: PIN, 패턴, 비밀번호) 중 하나를 사용자에게 요구해야 합니다(MUST).

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/H-2-1] 기기 소유자가 기기에서 추가 사용자와 관련 기능을 관리할 수 있는 기능인 제한된 프로필을 지원해야 합니다(MUST). 기기 소유자는 제한된 프로필을 사용하여 추가 사용자가 작업할 수 있는 별도의 환경을 빠르게 설정하고, 이러한 환경에서 제공되는 앱의 세부적인 제한을 관리할 수 있습니다.

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/H-3-1] 제한된 프로필을 지원하면 안 되지만(MUST NOT) 음성 통화 및 SMS에 대한 다른 사용자의 액세스를 사용 설정/사용 중지하기 위한 제어의 AOSP 구현에 맞게 조정되어야 합니다(MUST).

UserManager.isHeadlessSystemUserMode를 true로 설정하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.5/H-4-1] 호출 기능이 있는 eSIM 지원이 아닌 eUICC 지원을 포함하면 안 됩니다(MUST NOT).
  • [9.5/H-4-2] android.hardware.telephony 지원을 선언하면 안 됩니다(MUST NOT).

Android는 System API VoiceInteractionService를 통해 마이크 액세스 표시 없이 안전한 상시 사용 설정 핫워드 감지 및 마이크 또는 카메라 액세스 표시 없이 상시 사용 설정 쿼리 감지를 위한 메커니즘을 지원합니다.

System API HotwordDetectionService 또는 마이크 액세스 표시 없이 핫워드 감지를 위한 다른 메커니즘을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.8/H-1-1] 핫워드 감지 서비스가 시스템, ContentCaptureService 또는 SpeechRecognizer#createOnDeviceSpeechRecognizer()로 생성된 기기 내 음성 인식 서비스로만 데이터를 전송할 수 있도록 해야 합니다(MUST).
  • [9.8/H-1-2] 핫워드 감지 서비스가 마이크 오디오 데이터 또는 마이크 오디오 데이터에서 파생된 데이터를 HotwordDetectionService API 통해 시스템 서버 또는 ContentCaptureManager API를 통해 ContentCaptureService로만 전송할 수 있도록 해야 합니다(MUST).
  • [9.8/H-1-3] 개별 하드웨어 트리거 요청을 위해 30초보다 긴 마이크 오디오를 핫워드 감지 서비스에 제공하면 안 됩니다(MUST NOT).
  • [9.8/H-1-4] 개별 요청을 위해 8초보다 긴 버퍼링된 마이크 오디오를 핫워드 감지 서비스에 제공하면 안 됩니다(MUST NOT).
  • [9.8/H-1-5] 30초가 넘는 버퍼링된 마이크 오디오를 음성 상호작용 서비스나 유사한 항목에 제공하면 안 됩니다(MUST NOT).
  • [9.8/H-1-6] 성공적인 핫워드 결과마다 핫워드 감지 서비스 외부로 100바이트를 초과하는 데이터(오디오 스트림 제외)를 전송하도록 허용해서는 안 됩니다(MUST NOT).
  • [9.8/H-1-7] 부정적인 핫워드 결과마다 핫워드 감지 서비스 외부로 5비트를 초과하는 데이터를 전송하도록 허용해서는 안 됩니다(MUST NOT).
  • [9.8/H-1-8] 시스템 서버에서 오는 핫워드 유효성 검사 요청에 관해 핫워드 감지 서비스 외부로의 데이터 전송만 허용해야 합니다(MUST).
  • [9.8/H-1-9] 사용자가 설치할 수 있는 애플리케이션이 핫워드 감지 서비스를 제공하도록 허용해서는 안 됩니다(MUST NOT).
  • [9.8/H-1-10] 핫워드 감지 서비스의 마이크 사용량에 관한 UI의 정량적 데이터를 표시해서는 안 됩니다(MUST NOT).
  • [9.8/H-1-11] 핫워드 감지 서비스의 모든 전송에 포함된 바이트 수를 기록하여 보안 연구자가 검사할 수 있도록 허용해야 합니다.
  • [9.8/H-1-12] 핫워드 감지 서비스에서 오는 모든 전송의 원시 콘텐츠를 기록하는 디버그 모드를 지원하여 보안 연구자가 검사할 수 있도록 허용해야 합니다(MUST).

  • [9.8/H-1-14] 성공적인 핫워드 결과가 음성 상호작용 서비스 또는 이와 유사한 항목으로 전송될 때 섹션 9.8.2에서 설명하는 것처럼 마이크 표시기를 표시해야 합니다(MUST).

  • [9.8/H-1-15] 성공적인 핫워드 결과에 제공된 오디오 스트림이 핫워드 감지 서비스에서 음성 상호작용 서비스로 단방향 전송되도록 해야 합니다(MUST).

  • [9.8/H-SR-1] 애플리케이션을 핫워드 감지 서비스 제공업체로 설정하기 전에 사용자에게 알릴 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [9.8/H-SR-2] 구조화되지 않은 데이터를 핫워드 감지 서비스 외부로 전송하는 것을 금지할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [9.8/H-SR-3] 최소 시간당 한 번 또는 하드웨어 트리거 이벤트가 30번 발생할 때마다(둘 중 먼저 발생하는 시점을 적용) 핫워드 감지 서비스를 호스팅하는 프로세스를 다시 시작할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

마이크 사용 표시 없이 핫워드 감지를 위해 시스템 API HotwordDetectionService 또는 유사한 메커니즘을 사용하는 애플리케이션을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [9.8/H-2-1] 지원되는 각 핫워드 구문에 관해 사용자에게 명시적인 알림을 제공해야 합니다(MUST).
  • [9.8/H-2-2] 핫워드 감지 서비스를 통해 원시 오디오 데이터 또는 원시 데이터에서 파생된 데이터를 보존해서는 안 됩니다(MUST NOT).
  • [9.8/H-2-3] 핫워드 감지 서비스, 오디오 데이터, 오디오를 전체 또는 부분적으로 재구성하는 데 사용되는 데이터 또는 핫워드 자체와 관련 없는 오디오 콘텐츠를 전송해서는 안 됩니다(MUST NOT). 단, ContentCaptureService 또는 기기 내 음성 인식 서비스로의 전송은 예외입니다.

마이크 또는 카메라 액세스 표시 없이 쿼리 감지를 위해 시스템 API VisualQueryDetectionService 또는 다른 메커니즘을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.8/H-3-1] 쿼리 감지 서비스가 시스템(ContentCaptureService) 또는 기기 내 음성 인식 서비스(SpeechRecognizer#createOnDeviceSpeechRecognizer()가 생성)로만 데이터를 전송하도록 해야 합니다(MUST).
  • [9.8/H-3-2] 오디오 또는 동영상 정보가 ContentCaptureService나 기기 내 음성 인식 서비스를 제외하고 VisualQueryDetectionService 외부로 전송되도록 허용하면 안 됩니다(MUST NOT).
  • [9.8/H-3-3] 기기가 디지털 어시스턴트 애플리케이션에 참여하려는 사용자 의도를 감지하면(예: 카메라를 통한 사용자 존재 감지) 시스템 UI에 사용자 알림을 표시해야 합니다(MUST).
  • [9.8/H-3-4] 사용자 쿼리가 감지되면 곧바로 마이크 표시기를 표시하고 감지된 사용자 쿼리를 UI에 표시해야 합니다(MUST).
  • [9.8/H-3-5] 사용자가 설치할 수 있는 애플리케이션이 시각적 쿼리 감지 서비스를 제공하는 것을 허용하면 안 됩니다(MUST NOT).

android.hardware.microphone을 선언하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/H-4-1] HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService 또는 CDD 식별자 [C-4-X]를 사용하여 섹션 9.1에서 호출된 역할을 보유하는 앱에서만 마이크에 액세스할 때가 아니라 앱이 마이크에서 전송되는 오디오 데이터에 액세스하고 있을 때 마이크 표시기를 표시해야 합니다(MUST).
  • [9.8.2/H-4-2] PermissionManager.getIndicatorAppOpUsageData()에서 반환될 때 마이크를 사용하는 최근 앱 및 활성 앱 목록을 앱과 연결된 저작자 표시 메시지와 함께 표시해야 합니다(MUST).
  • [9.8.2/H-4-3] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 마이크 표시기를 숨기면 안 됩니다(MUST NOT).
  • [9.8.2/H-4-4] PermissionManager.getIndicatorAppOpUsageData()에서 반환될 때 마이크를 사용하는 최근 앱 및 활성 앱 목록과 이러한 앱에 연결된 저작자 표시 메시지를 함께 표시해야 합니다(MUST).

android.hardware.camera.any를 선언하는 휴대기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/H-5-1] CDD 식별자[C-4-X]를 사용하는 섹션 9.1에서 호출되는 역할을 보유하고 있는 앱에서만 카메라에 액세스하고 있을 때가 아니라 앱이 실시간 카메라 데이터에 액세스하고 있을 때 카메라 표시기를 표시해야 합니다(MUST).
  • [9.8.2/H-5-2] PermissionManager.getIndicatorAppOpUsageData()에서 반환될 때 카메라를 사용하는 최근 앱 및 활성 앱과 이러한 앱에 연결된 저작자 표시 메시지를 함께 표시해야 합니다(MUST).
  • [9.8.2/H-5-3] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 카메라 표시기를 숨기면 안 됩니다(MUST NOT).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[9.10/H–1–1](2024년 2월 26일 미리보기)

자체 검사 부팅은 기기 소프트웨어의 무결성을 보장하는 기능입니다. 해당 기능을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [9.10/H–1–1] Android 부팅 시퀀스 중에 로드된 모든 읽기 전용 파티션을 확인해야 합니다(MUST).

새로운 요구사항 종료

2.2.6. 개발자 도구 및 옵션 호환성

휴대기기 구현(*태블릿은 해당 없음):

  • [6.1/H-0-1]* 셸 명령어 cmd testharness를 지원해야 합니다(MUST).

휴대기기 구현(*태블릿은 해당 없음):

  • Perfetto
    • [6.1/H-0-2]* cmdline이 perfetto 문서를 준수하는 셸 사용자에게 /system/bin/perfetto 바이너리를 노출시켜야 합니다(MUST).
    • [6.1/H-0-3]* perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf config를 입력하는 방식으로 허용해야 합니다(MUST).
    • [6.1/H-0-4]* perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf 트레이스를 출력하는 방식으로 작성해야 합니다(MUST).
    • [6.1/H-0-5]* perfetto 바이너리를 통해 최소 perfetto 문서에 정의된 데이터를 제공해야 합니다(MUST).
    • [6.1/H-0-6]* perfetto 추적 데몬은 기본적으로 사용 설정되어야 합니다(시스템 속성 persist.traced.enable)(MUST).

2.2.7. 휴대기기 미디어 성능 등급

미디어 성능 등급의 정의는 섹션 7.11을 참고하세요.

2.2.7.1. 미디어

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.U를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

Android 15(AOSP 실험용)의 미디어 성능 클래스 업데이트(2024년 2월 5일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

  • [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 디코더 세션 개수를 알려야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-2(2024년 2월 5일 미리보기)

  • [5.1/H-1-2] 1080p 해상도@30fps의 세션 3개, 4K 해상도@30fps의 세션 3개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(AV1 제외)(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.

새로운 요구사항 종료

  • [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 인코더 세션 개수를 알려야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-4(2024년 2월 5일 미리보기)

  • [5.1/H-1-4] 1080p 해상도@30fps의 세션 4개, 4K 해상도@30fps의 세션 2개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(AV1 제외)(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.

새로운 요구사항 종료

  • [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 인코더 및 디코더 세션 개수를 알려야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-5(2024년 2월 5일 미리보기)

  • [5.1/H-1-6] 4K@30fps 해상도(AV1 제외)의 세션 3개(인코더 세션 최대 2개 포함)와 1080p 해상도의 세션 3개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 디코더 및 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-19(2024년 2월 5일 미리보기)

  • [5.1/H-1-19] 4K@30fps 해상도(AV1 제외)의 모든 코덱 조합(이중 최대 1개는 인코더 세션이며, 이 세션은 GL 표시 경로를 통해 RGBA_1010102 입력 형식으로 구성될 수 있음)에서 10비트(HDR) 하드웨어 동영상 디코더 및 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 3개를 지원해야 합니다(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). GL 표시 경로에서 인코딩하는 경우 인코더로 HDR 메타데이터를 생성하지 않아도 됩니다. AV1 코덱 세션은 이 요구사항에서 4K를 요구하더라도 1080p 해상도만 지원하면 됩니다.

새로운 요구사항 종료

  • [5.1/H-1-7] 로드 중인 상태에서 모든 하드웨어 동영상 인코더의 1080p 이하 동영상 인코딩 세션의 코덱 초기화 지연 시간이 40ms 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-동영상 녹화 초기화와 함께 하드웨어 동영상 코덱을 사용하는 동시 실행 1080p~720p 동영상 전용 트랜스코딩 세션으로 정의됩니다. Dolby 비전 코덱의 경우 코덱 초기화 지연 시간이 50ms 이하여야 합니다(MUST).
  • [5.1/H-1-8] 로드 중인 상태에서 모든 오디오 인코더의 비트 전송률이 128kbps 이하인 오디오 인코딩 세션의 코덱 초기화 지연 시간이 30밀리초 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-동영상 녹화 초기화와 함께 하드웨어 동영상 코덱을 사용하는 동시 실행 1080p~720p 동영상 전용 트랜스코딩 세션으로 정의됩니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-9(2024년 2월 5일 미리보기)

  • [5.1/H-1-9] 8비트(SDR) 및 10비트(HDR) 콘텐츠 모두 해상도 4K에서 30fps(AV1 제외)로 동시에 실행되는 모든 코덱 조합에서 보안 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 2개를 지원해야 합니다(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). AV1 코덱 세션은 이 요구사항에서 4K를 요구하더라도 1080p 해상도만 지원하면 됩니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

5.1/H-1-10(2024년 2월 5일 미리보기)

  • [5.1/H-1-10] 4K 해상도@30fps(AV1 제외)의 세션 3개(보안 디코더 세션 1개 포함), 1080p 해상도@30fps의 비보안 세션 1개와 동시에 실행되는 모든 코덱 조합(최대 2개 세션이 10비트 HDR일 수 있음)에서 비보안 하드웨어 동영상 디코더 세션의 인스턴스 3개와 보안 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 1개(총 4개의 인스턴스)를 지원해야 합니다(MUST). 모든 세션에서 초당 두 개 이상의 프레임이 삭제되면 안 됩니다(MUST NOT). AV1 코덱 세션은 이 요구사항에서 4K를 요구하더라도 1080p 해상도만 지원하면 됩니다.

새로운 요구사항 종료

  • [5.1/H-1-11] 기기의 모든 하드웨어 AVC, HEVC, VP9 또는 AV1 디코더를 위한 보안 디코더를 지원해야 합니다(MUST).
  • [5.1/H-1-12] 로드 중인 상태에서 모든 하드웨어 동영상 디코더의 1080p 이하 동영상 디코딩 세션의 코덱 초기화 지연 시간이 40ms 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-동영상 재생 초기화와 함께 하드웨어 동영상 코덱을 사용하는 동시 실행 1080p~720p 동영상 전용 트랜스코딩 세션으로 정의됩니다. Dolby 비전 코덱의 경우 코덱 초기화 지연 시간이 50ms 이하여야 합니다(MUST).
  • [5.1/H-1-13] 로드 중인 상태에서 모든 오디오 디코더의 비트 전송률이 128kbps 이하인 오디오 디코딩 세션의 코덱 초기화 지연 시간이 30ms 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-동영상 재생 초기화와 함께 하드웨어 동영상 코덱을 사용하는 동시 실행 1080p~720p 동영상 전용 트랜스코딩 세션으로 정의됩니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.1/H-1-14](2024년 2월 5일 미리보기)

  • [5.1/H-1-14] GPU 구성에 대한 필름 입자 추가 효과로 AV1 하드웨어 디코더 메인 10, 레벨 4.1 및 필름 입자 추가을 지원해야 합니다(MUST).

새로운 요구사항 종료

  • [5.1/H-1-15] 4K60을 지원하는 하드웨어 동영상 디코더가 하나 이상 있어야 합니다(MUST).
  • [5.1/H-1-16] 4K60을 지원하는 하드웨어 동영상 인코더가 하나 이상 있어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.1/H-1-21](2024년 2월 5일 미리보기)

  • [5.1/H-1-21] 모든 하드웨어 동영상 디코더(AVC, HEVC, VP9, AV1 이상)의 FEATURE_DynamicColorAspect를 지원해야 합니다(MUST). 참고: 이는 애플리케이션이 디코딩 세션 중에 동영상 콘텐츠의 색상 측면을 업데이트할 수 있음을 의미합니다. 10비트 및 8비트 콘텐츠를 지원하는 디코더는 Surface 모드에서 8비트와 10비트 콘텐츠 간 동적 전환을 지원해야 합니다(MUST). HDR 전송 기능을 지원하는 디코더는 SDR 콘텐츠와 HDR 콘텐츠 간 동적 전환을 지원해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.1/H-1-22](2024년 2월 5일 미리보기)

  • [5.1/H-1-22] 카메라 지원 최대 해상도 또는 4K 중 더 낮은 것에 대한 회전 메타데이터와 관계없이 세로 모드 가로세로 비율에서 동영상 콘텐츠의 인코딩, 디코딩, GPU 편집, 표시를 지원해야 합니다(MUST). 참고: 코덱이 HDR을 지원하는 경우 여기에는 HDR 프로필이 포함됩니다. AV1 코덱은 1080p 해상도만 지원하면 됩니다. 이 요구사항은 하드웨어 코덱, GPU, DPU에만 적용됩니다.

새로운 요구사항 종료

  • [5.3/H-1-1] 로드 중인 상태에서 4K 60fps인 동영상 세션은 10초에 2프레임 이상 드롭(즉, 0.167퍼센트 미만의 프레임 드롭)하면 안 됩니다(MUST NOT).
  • [5.3/H-1-2] 4K 세션에서 로드 중인 상태에서 60fps 동영상 세션의 동영상 해상도가 변경되는 동안 10초에 2프레임 이상 드롭하면 안 됩니다(MUST NOT).
  • [5.6/H-1-1] CTS 인증 도구 탭 투 톤 테스트를 사용하여 탭 투 톤 지연 시간이 80밀리초 이하여야 합니다(MUST).
  • [5.6/H-1-2] 지원되는 데이터 경로 하나 이상에서 왕복 오디오 지연 시간이 80밀리초 이하여야 합니다(MUST).
  • [5.6/H-1-3] 3.5mm 오디오 잭(있는 경우)과 USB 오디오(짧은 지연 시간과 스트리밍 구성의 전체 데이터 경로를 통해 지원되는 경우)를 통해 스테레오 출력으로 24비트 이상의 오디오를 지원해야 합니다(MUST). 짧은 지연 시간 구성의 경우 앱은 짧은 지연 시간 콜백 모드에서 AAudio를 사용해야 합니다. 스트리밍 구성의 경우 앱이 Java AudioTrack을 사용해야 합니다. 짧은 지연 시간과 스트리밍 구성에서 모두 HAL 출력 싱크는 타겟 출력 형식에 맞게 AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT, AUDIO_FORMAT_PCM_FLOAT 중 하나를 허용해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.6/H-1-4](2024년 2월 5일 미리보기)

  • [5.6/H-1-4] 4개 이상의 채널 USB 오디오 기기를 지원해야 합니다(MUST). 이는 DJ 컨트롤러가 노래를 미리 보는 데 사용합니다.

새로운 요구사항 종료

  • [5.6/H-1-5] 클래스를 준수하는 MIDI 기기를 지원하고 MIDI 기능 플래그를 선언해야 합니다(MUST).
  • [5.6/H-1-9] 최소 12개의 채널 믹싱을 지원해야 합니다(MUST). 이는 7.1.4 채널 마스크를 사용하여 AudioTrack을 열고 모든 채널을 스테레오로 적절히 공간화하거나 다운믹스할 수 있음을 의미합니다.
  • [5.6/H-SR] 적어도 9.1.6 및 22.2 채널 마스크에 대한 지원과 함께 24 채널 믹싱을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [5.7/H-1-2] 아래 콘텐츠 복호화 기능으로 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL을 지원해야 합니다(MUST).
최소 샘플 크기 4MiB
최소 서브 샘플 수 - H264 또는 HEVC 32
최소 서브 샘플 수 - VP9 9
최소 서브 샘플 수 - AV1 288
최소 서브 샘플 버퍼 사이즈 1MiB
최소 일반 암호화 버퍼 사이즈 500KiB
최소 동시 실행 세션 수 30
세션당 최소 키 수 20
최소 총 키 수(모든 세션) 80
최소 총 DRM 키 수(모든 세션) 6
메시지 크기 16KiB
초당 복호화된 프레임 수 60fps
  • [5.1/H-1-17] AVIF 기준 프로필을 지원하는 하드웨어 이미지 디코더를 1개 이상 보유해야 합니다(MUST).
  • [5.1/H-1-18] 30fps 및 1Mbps에서 최대 480p 해상도를 인코딩할 수 있는 AV1 인코더를 지원해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.1/H-1-20](2024년 2월 5일 미리보기)

  • [5.1/H-1-20] 4K 해상도 또는 카메라 지원 최대 해상도 중 더 낮은 해상도로 기기에 있는 모든 하드웨어 AV1 및 HEVC 인코더의 Feature_HdrEditing 기능을 지원해야 합니다(MUST).

새로운 요구사항 종료

  • [5.12/H-SR] 기기에 있는 모든 하드웨어 AV1 및 HEVC 인코더에 Feature_HdrEditing 기능을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [5.12/H-1-2] 기기의 모든 하드웨어 AV1 및 HEVC 인코더에 RGBA_1010102 색상 형식을 지원해야 합니다(MUST).
  • [5.12/H-1-3] 8비트 및 10비트 모두 YUV 텍스처에서 샘플링할 수 있도록 EXT_YUV_target 확장 프로그램 지원을 광고해야 합니다(MUST).
  • [7.1.4/H-1-1] 데이터 처리 장치(DPU) 하드웨어 컴포저(HWC)에 6개 이상의 하드웨어 오버레이가 있어야 하며 그중 2개 이상 10비트 동영상 콘텐츠를 표시할 수 있어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

Android 15(AOSP 실험용)의 미디어 성능 클래스 업데이트(2024년 2월 5일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하고 하드웨어 AVC 또는 HEVC 인코더에 관한 지원을 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[5.2/H-2-2][철회됨](2024년 4월 8일 미리보기)

  • [5.2/H-2-2]
    다음 요구사항은 Android 15(AOSP 실험용)에서 철회되었습니다.

새로운 요구사항 종료

[5.2/H-2-2](2024년 2월 5일 미리보기)

  • [5.2/H-2-2] 60FPS 이상의 1080p에서 dav1d 소프트웨어 AV1 디코더를 사용하여 샘플 동영상을 렌더링해야 합니다(MUST).

새로운 요구사항 종료

2.2.7.2. 카메라

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.U를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

Android 15(AOSP 실험용)의 미디어 성능 클래스 업데이트(2024년 2월 5일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.5/H-1-1](2024년 2월 26일 미리보기)

  • [7.5/H-1-1] 4k@30fps, 1080p@60fps, 720p@60fps에서 동영상 캡처를 지원하는 최소 12 메가픽셀의 해상도를 가진 기본 후면 카메라가 있어야 합니다(MUST). 기본 후면 카메라는 카메라 ID가 가장 낮은 후면 카메라입니다.

새로운 요구사항 종료

[7.5/H-1-1](2024년 2월 5일 미리보기)

  • [7.5/H-1-1] 4k@30fps, 1080p@60fps, 720p@60fps에서 동영상 캡처를 지원하는 최소 12 메가픽셀의 해상도를 가진 기본 후면 카메라가 있어야 합니다(MUST). 이러한 캡처 속도의 프레임 드롭률은 X%보다 크면 안 됩니다(X는 2024년 1분기까지 미정)(MUST NOT). 기본 후면 카메라는 카메라 ID가 가장 낮은 후면 카메라입니다.

새로운 요구사항 종료

  • [7.5/H-1-2] 해상도가 5메가픽셀 이상인 기본 전면 카메라가 있어야 하며, 1080p@30fps에서 동영상 캡처를 지원해야 합니다(MUST). 기본 전면 카메라는 카메라 ID가 가장 낮은 전면 카메라입니다.
  • [7.5/H-1-3] 후면 기본 카메라의 경우 FULL 이상으로, 전면 기본 카메라의 경우 LIMITED 이상으로 android.info.supportedHardwareLevel 속성을 지원해야 합니다(MUST).
  • [7.5/H-1-4] 두 기본 카메라 모두 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME을 지원해야 합니다(MUST).
  • [7.5/H-1-5] 두 기본 카메라용 ITS 조명 조건(3000K)에서 CTS 카메라 PerformanceTest로 측정한 1080p 해상도의 camera2 JPEG 캡처 지연 시간이 1000ms 미만이어야 합니다(MUST).
  • [7.5/H-1-6] 두 기본 카메라용 ITS 조명 조건(3000K)에서 CTS 카메라 PerformanceTest로 측정한 camera2 시작 지연 시간(첫 번째 미리보기 프레임에 카메라 열기)이 500ms 미만이어야 합니다(MUST).
  • [7.5/H-1-8] 기본 후면 카메라에 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW와 android.graphics.ImageFormat.RAW_SENSOR를 지원해야 합니다(MUST).
  • [7.5/H-1-9] 후면 기본 카메라가 240fps로 720p 또는 1080p를 지원해야 합니다(MUST).
  • [7.5/H-1-10] 같은 방향을 바라보는 울트라와이드 RGB 카메라가 있는 경우 기본 카메라의 최소 ZOOM_RATIO는 1.0 미만이어야 합니다(MUST).
  • [7.5/H-1-11] 기본 카메라에 전후면 동시 스트리밍을 구현해야 합니다(MUST).
  • [7.5/H-1-12] 기본 전면 카메라와 기본 후면 카메라에서 모두 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION을 지원해야 합니다(MUST).
  • [7.5/H-1-13] RGB 후면 카메라가 2개 이상인 경우 기본 후면 카메라의 LOGICAL_MULTI_CAMERA 기능을 지원해야 합니다(MUST).
  • [7.5/H-1-14] 기본 전면 카메라와 기본 후면 카메라 모두 STREAM_USE_CASE 기능을 지원해야 합니다(MUST).
  • [7.5/H-1-15] 기본 카메라용 CameraX 및 Camera2 확장 프로그램을 모두 사용하여 야간 모드 확장 프로그램을 지원해야 합니다(MUST).
  • [7.5/H-1-16] 기본 카메라의 DYNAMIC_RANGE_TEN_BIT 기능을 지원해야 합니다(MUST).
  • [7.5/H-1-17] 기본 카메라의 CONTROL_SCENE_MODE_FACE_PRIORITY 및 얼굴 인식(STATISTICS_FACE_DETECT_MODE_SIMPLE 또는 STATISTICS_FACE_DETECT_MODE_FULL)을 지원해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.5/H-1-18](2024년 2월 5일 미리보기)

  • [7.5/H-1-18] 기본 후면 카메라와 기본 전면 카메라의 JPEG_R을 지원해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.5/H-1-19](2024년 4월 8일 미리보기)

  • [7.5/H-1-19] 기본 후면 카메라의 경우 최대 크기 16:9 가로세로 비율 JPEG를 사용하는 1080p HLG10 미리보기와 최대 크기 16:9 가로세로 비율 JPEG 스트림 조합을 사용하는 720p HLG10 미리보기의 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION을 지원해야 합니다(MUST).

새로운 요구사항 종료

[7.5/H-1-19](2024년 2월 26일 미리보기)

  • [7.5/H-1-19] 기본 후면 카메라의 경우 최대 크기 JPEG를 사용하는 1080p HLG10 미리보기와 최대 크기 JPEG 스트림 조합을 사용하는 720p HLG10 미리보기의 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION을 지원해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.5/H-1-20](2024년 4월 8일 미리보기)

  • [7.5/H-1-20] 네이티브 카메라 앱에서 기본 후면 카메라와 기본 전면 카메라의 JPEG_R을 기본적으로 출력해야 합니다(MUST).

새로운 요구사항 종료

2.2.7.3. 하드웨어

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.U를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

Android 15(AOSP 실험용)의 미디어 성능 클래스 업데이트(2024년 2월 5일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

  • [7.1.1.1/H-2-1] 화면 해상도가 1080p 이상이어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.1.1.3/H-2-1](2024년 2월 5일 미리보기)

  • [7.1.1.3/H-2-1] 기기의 화면 너비가 600dp보다 작다면 화면 밀도가 400dpi 이상이어야 합니다(MUST).

새로운 요구사항 종료

  • [7.1.1.3/H-3-1] 평균 1,000nit 이상을 지원하는 HDR 디스플레이가 있어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.6.1/H-2-1](2024년 4월 8일 미리보기)

  • [7.6.1/H-2-1] 실제 메모리 크기가 8GB 이상이어야 하며, android.app.ActivityManager.MemoryInfo에서 보고된 대로 커널에 6.64GB 이상을 사용할 수 있어야 합니다(MUST).

새로운 요구사항 종료

2.2.7.4. 성능

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.U를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

Android 15(AOSP 실험용)의 미디어 성능 클래스 업데이트(2024년 2월 5일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

  • [8.2/H-1-1] 초당 최소 150MB/s의 순차 작성 성능을 보장해야 합니다(MUST).
  • [8.2/H-1-2] 초당 최소 10MB/s의 무작위 작성 성능을 보장해야 합니다(MUST).
  • [8.2/H-1-3] 초당 최소 250MB/s의 순차 판독 성능을 보장해야 합니다(MUST).
  • [8.2/H-1-4] 초당 최소 100MB/s의 무작위 판독 성능을 보장해야 합니다(MUST).
  • [8.2/H-1-5] 초당 최소 50MB/s의 2배 판독 및 1배 작성 성능으로 병렬 순차 판독 및 작성 성능을 보장해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

2.2.7.5. 그래픽

[2.2.7.5 그래픽](2024년 4월 8일 미리보기)

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

[2.2.7.5 그래픽](2024년 2월 5일 미리보기)
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS에 android.os.Build.VERSION_CODES.V를 반환하는 휴대기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

2.3. 텔레비전 요구사항

Android 텔레비전 기기는 3미터 떨어진 곳의 사용자가 디지털 미디어, 게임, 앱 또는 라이브 TV를 소비하는 데 사용되는 엔터테인먼트 인터페이스('lean back' 또는 '3m 사용자 인터페이스')인 Android 기기 구현입니다.

Android 기기 구현은 다음과 같은 기준을 모두 충족하는 경우 텔레비전으로 분류됩니다.

  • 사용자로부터 3m 떨어진 디스플레이에서 렌더링되는 사용자 인터페이스를 원격으로 제어하기 위한 메커니즘을 제공합니다.
  • 대각선 길이가 24인치 이상인 화면 디스플레이가 내장되어 있거나 디스플레이용 VGA, HDMI, DisplayPort, 무선 포트와 같은 동영상 출력 포트를 포함합니다.

이 섹션의 나머지 부분에 기재된 추가적인 요구사항은 Android 텔레비전 기기 구현에만 해당합니다.

2.3.1. 하드웨어

텔레비전 기기 구현:

  • [7.2.2/T-0-1] D패드를 지원해야 합니다(MUST).
  • [7.2.3/T-0-1] 홈 및 '뒤로' 기능을 제공해야 합니다(MUST).
  • [7.2.3/T-0-2] '뒤로' 기능(KEYCODE_BACK)의 보통 누르기 및 길게 누르기 이벤트를 모두 포그라운드 애플리케이션에 전송해야 합니다(MUST).
  • [7.2.6.1/T-0-1] 게임 컨트롤러 지원 기능을 포함하고 android.hardware.gamepad 기능 플래그를 선언해야 합니다(MUST).
  • [7.2.7/T] 사용자가 터치 미지원 탐색 및 핵심 탐색 키 입력에 액세스할 수 있도록 리모컨을 제공해야 합니다(SHOULD).

3축 자이로스코프를 포함하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/T-1-1] 최소 100Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [7.3.4/T-1-2] 초당 최대 1,000도의 방향 변화를 측정할 수 있어야 합니다(MUST).

텔레비전 기기 구현:

  • [7.4.3/T-0-1] 블루투스 및 블루투스 LE를 지원해야 합니다(MUST).
  • [7.6.1/T-0-1] 애플리케이션 비공개 데이터를 위한 최소 4GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).

호스트 모드를 지원하는 USB 포트를 포함하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [7.5.3/T-1-1] USB 포트를 통해 연결되지만 항상 연결되어 있을 필요는 없는 외장 카메라에 대한 지원을 포함해야 합니다(MUST).

TV 기기 구현이 32비트인 경우 다음을 충족해야 합니다.

  • [7.6.1/T-1-1] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 896MB여야 합니다(MUST).

    • 소형/일반 화면에서 400dpi 이상
    • 대형 화면에서 xhdpi 이상
    • 초대형 화면에서 tvdpi 이상

TV 기기 구현이 64비트인 경우 다음을 충족해야 합니다.

  • [7.6.1/T-2-1] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1280MB여야 합니다(MUST).

    • 소형/일반 화면에서 400dpi 이상
    • 대형 화면에서 xhdpi 이상
    • 초대형 화면에서 tvdpi 이상

위에서 언급한 '커널 및 사용자 공간에 사용 가능한 메모리'는 기기 구현에서 커널의 제어를 받지 않는 라디오, 동영상 등의 하드웨어 구성요소에 이미 전용으로 사용되고 있는 모든 메모리 외에 추가로 제공되는 메모리 공간을 의미합니다.

텔레비전 기기 구현:

  • [7.8.1/T] 마이크를 포함해야 합니다(SHOULD).
  • [7.8.2/T-0-1] 오디오 출력을 보유하고 android.hardware.audio.output을 선언해야 합니다(MUST).

2.3.2. 멀티미디어

텔레비전 기기 구현은 다음과 같은 오디오 인코딩 및 디코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.1/T-0-1] MPEG-4 AAC 프로필(AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC 프로필(AAC+)
  • [5.1/T-0-3] AAC ELD(향상된 저지연 AAC)

텔레비전 기기 구현은 다음과 같은 동영상 인코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8
  • [5.2/T-0-3] AV1

텔레비전 기기 구현:

  • [5.2.2/T-SR-1] 초당 30프레임으로 된 720p 및 1080p 해상도 동영상의 H.264 인코딩을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

텔레비전 기기 구현은 다음과 같은 동영상 디코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

텔레비전 기기 구현은 섹션 5.3.1에 설명된 MPEG-2 디코딩을 다음의 표준 동영상 프레임 속도와 해상도에서 지원해야 합니다(MUST).

  • [5.3.1/T-1-1] 기본 프로필 하이 레벨 사용 시 29.97fps에서 HD 1080p.
  • [5.3.1/T-1-2] 기본 프로필 하이 레벨 사용 시 59.94fps에서 HD 1080i. 인터레이스된 MPEG-2 동영상의 인터레이스를 해제하고 이를 서드 파티 애플리케이션에서 사용할 수 있도록 합니다(MUST).

텔레비전 기기 구현은 섹션 5.3.4에 설명된 H.264 디코딩을 다음의 표준 동영상 프레임 속도와 해상도에서 지원해야 합니다(MUST).

  • [5.3.4/T-1-1] 기준 프로필 사용 시 60fps에서 HD 1080p
  • [5.3.4/T-1-2] 기본 프로필 사용 시 60fps에서 HD 1080p
  • [5.3.4/T-1-3] 하이 프로필 레벨 4.2 사용 시 60fps에서 HD 1080p

H.265 하드웨어 디코더를 포함하는 텔레비전 기기 구현은 섹션 5.3.5에 설명된 H.265 디코딩을 다음의 표준 동영상 프레임 속도와 해상도에서 지원해야 합니다(MUST).

  • [5.3.5/T-1-1] 기본 프로필 레벨 4.1 사용 시 60fps에서 HD 1080p

H.265 하드웨어 디코더를 포함하는 텔레비전 기기 구현이 H.265 디코딩과 UHD 디코딩 프로필을 지원하는 경우 다음을 충족해야 합니다.

  • [5.3.5/T-2-1] Main10 Level 5 기본 티어 프로필로 60fps에서 UHD 디코딩 프로필을 지원해야 합니다(MUST).

텔레비전 기기 구현은 섹션 5.3.6에 설명된 VP8 디코딩을 다음의 표준 동영상 프레임 속도와 해상도에서 지원해야 합니다(MUST).

  • [5.3.6/T-1-1] 60fps에서 HD 1080p인 디코딩 프로필

VP9 하드웨어 디코더를 포함하는 텔레비전 기기 구현은 섹션 5.3.7에 설명된 VP9 디코딩을 다음의 표준 동영상 프레임 속도와 해상도에서 지원해야 합니다(MUST).

  • [5.3.7/T-1-1] 프로필 0(8비트 색심도) 사용 시 60fps에서 HD 1080p

VP9 하드웨어 디코더를 포함하는 텔레비전 기기 구현이 VP9 디코딩 및 UHD 디코딩 프로필을 지원하는 경우 다음을 충족해야 합니다.

  • [5.3.7/T-2-1] 프로필 0(8비트 색심도)으로 60fps에서 UHD 디코딩 프로필을 지원해야 합니다(MUST).
  • [5.3.7/T-SR1] 프로필 2(10비트 색심도)로 60fps에서 UHD 디코딩 프로필을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

텔레비전 기기 구현:

  • [5.5/T-0-1] 지원되는 출력의 시스템 마스터 볼륨 및 디지털 오디오 출력 볼륨 증명과 관련된 지원을 포함해야 합니다(MUST). 단, 오디오 디코딩이 기기에서 이루어지는 압축된 오디오 패스 스루 출력은 예외입니다.

디스플레이가 내장되어 있지 않지만 대신 HDMI를 통해 연결된 외부 디스플레이를 지원하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [5.8/T-0-1] 기기가 판매되는 지역의 동영상 화면 재생 빈도에 따라 HDMI 출력 모드를 외부 디스플레이의 50Hz 또는 60Hz 화면 재생 빈도에서 작동하는 선택된 픽셀 형식의 최대 해상도로 설정해야 합니다(MUST).
  • [5.8/T-SR-1] 사용자가 구성 가능한 HDMI 화면 재생 빈도 선택기를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [5.8] 기기가 판매되는 지역의 동영상 화면 재생 빈도에 따라 HDMI 출력 모드 화면 재생 빈도를 50Hz 또는 60Hz로 설정해야 합니다(SHOULD).

디스플레이가 내장되어 있지 않지만 대신 HDMI를 통해 연결된 외부 디스플레이를 지원하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [5.8/T-1-1] HDCP 2.2를 지원해야 합니다(MUST).

UHD 디코딩은 지원하지 않지만 대신 HDMI를 통해 연결된 외부 디스플레이를 지원하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [5.8/T-2-1] HDCP 1.4를 지원해야 합니다(MUST).

2.3.3. 소프트웨어

텔레비전 기기 구현:

  • [3/T-0-1] 기능 android.software.leanback 및 android.hardware.type.television을 선언해야 합니다(MUST).
  • [3.2.3.1/T-0-1] 여기에 나열된 애플리케이션 인텐트로 정의된 모든 공개 인텐트 필터 패턴과 관련하여 인텐트 핸들러가 1개 이상의 애플리케이션 또는 서비스 구성요소를 미리 로드해야 합니다(MUST).
  • [3.4.1/T-0-1] android.webkit.Webview API의 온전한 구현을 제공해야 합니다(MUST).

잠금 화면을 지원하는 Android 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [3.8.10/T-1-1] 미디어 알림 템플릿을 포함한 잠금 화면 알림을 표시해야 합니다(MUST).

텔레비전 기기 구현:

  • [3.8.14/T-SR-1] PIP(picture-in-picture) 모드 멀티 윈도우를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.10/T-0-1] 서드 파티 접근성 서비스를 지원해야 합니다(MUST).
  • [3.10/T-SR-1] Talkback 오픈소스 프로젝트에서 제공하는 스위치 제어 및 Talkback(사전 설치된 텍스트 음성 변환 엔진에서 지원되는 언어용) 접근성 서비스와 기능이 비슷하거나 이보다 뛰어난 접근성 서비스를 기기에서 미리 로드할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기능 android.hardware.audio.output을 보고하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [3.11/T-SR-1] 기기에서 제공되는 언어를 지원하는 TTS 엔진을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [3.11/T-1-1] 서드 파티 TTS 엔진 설치를 지원해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[3.12/T-0-1](2024년 2월 26일 미리보기)

텔레비전 기기 구현:

  • [3.12/T-0-1] TV 입력 프레임워크를 지원해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[3/T-0-2, 3/T-0-3. 3/T-1-1](2024년 2월 26일 미리보기)

Android 텔레비전 입력 프레임워크(TIF)는 Android 텔레비전 서비스의 라이브 콘텐츠 전달을 간소화합니다. TIF는 Android 텔레비전 기기를 제어하는 입력 모듈 생성을 위한 표준 API를 제공합니다.

텔레비전 기기 구현:

  • [3/T-0-2] 플랫폼 기능 android.software.live_tv를 선언해야 합니다(MUST).
  • [3/T-0-3] TIF API와 서드 파티 TIF 기반 입력 서비스를 사용하는 애플리케이션을 기기에 설치하여 사용할 수 있도록 모든 TIF API를 지원해야 합니다(MUST).

Android 텔레비전 튜너 프레임워크(TF)[2024년 3분기까지 링크 미정]는 튜너의 라이브 콘텐츠 처리를 Android 텔레비전 기기에 있는 IP의 스트리밍 콘텐츠와 통합합니다. 튜너 프레임워크는 Android 텔레비전 튜너를 사용하는 입력 서비스를 만드는 표준 API를 제공합니다.

튜너를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [3/T-1-1] Tuner Framework API를 사용하는 애플리케이션을 기기에 설치하여 사용할 수 있도록 모든 Tuner Framework API를 지원해야 합니다(MUST).

새로운 요구사항 종료

2.3.4. 성능 및 전력

  • [8.1/T-0-1] 일관적인 프레임 지연 시간. 프레임을 렌더링하기 위한 비일관적인 프레임 지연 시간 또는 지연이 초당 5프레임보다 자주 발생하면 안 되며(MUST NOT), 초당 1프레임 아래여야 합니다(SHOULD).
  • [8.2/T-0-1] 초당 최소 5MB의 순차 작성 성능을 보장해야 합니다(MUST).
  • [8.2/T-0-2] 초당 최소 0.5MB의 무작위 작성 성능을 보장해야 합니다(MUST).
  • [8.2/T-0-3] 초당 최소 15MB의 순차 판독 성능을 보장해야 합니다(MUST).
  • [8.2/T-0-4] 초당 최소 3.5MB의 무작위 판독 성능을 보장해야 합니다(MUST).

AOSP에 포함되었거나 AOSP에 포함된 기능을 확장하는 기기 전력 관리를 개선하는 기능을 포함하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [8.3/T-1-1] 절전 모드 기능을 사용 설정 및 중지하기 위한 사용자 어포던스를 제공해야 합니다(MUST).

배터리가 없는 텔레비전 기기 구현은 다음을 충족해야 합니다.

배터리가 있는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [8.3/T-1-3] 앱 대기 및 잠자기 절전 모드에서 제외된 모든 앱을 표시하기 위한 사용자 어포던스를 제공해야 합니다(MUST).

텔레비전 기기 구현:

  • [8.4/T-0-1] Android 오픈소스 프로젝트 사이트에 문서화된 것처럼 각 하드웨어 구성요소의 전력 소모량 값과 시간 경과에 따른 대략적인 배터리 소모를 정의하는 구성요소별 전력 프로필을 제공해야 합니다(MUST).
  • [8.4/T-0-2] 모든 전력 소모량 값(mAh)을 보고해야 합니다(MUST).
  • [8.4/T-0-3] 각 프로세스의 UID별 CPU 전력 소모량을 보고해야 합니다(MUST). Android 오픈소스 프로젝트는 uid_cputime 커널 모듈 구현을 통해 요구사항을 충족합니다.
  • [8.4/T] 하드웨어 구성요소 전력 사용량을 애플리케이션에 출처로 표시할 수 없는 경우 하드웨어 구성요소 자체를 출처로 표시해야 합니다(SHOULD).
  • [8.4/T-0-4] adb shell dumpsys batterystats 셸 명령어를 통해 이러한 전력 사용량을 앱 개발자에게 제공해야 합니다(MUST).

2.3.5. 보안 모델

텔레비전 기기 구현:

  • [9/T-0-1] android.hardware.security.model.compatible 기능을 선언해야 합니다(MUST).
  • [9.11/T-0-1] 격리된 실행 환경으로 키 저장소 구현을 지원해야 합니다(MUST).
  • [9.11/T-0-2] RSA, AES, ECDSA, HMAC 암호화 알고리즘 및 MD5, SHA1, SHA-2 계열 해시 함수를 구현하여 커널과 위에서 실행 중인 코드에서 안전하게 격리된 영역에서 Android 키 저장소 시스템의 지원되는 알고리즘을 제대로 지원해야 합니다(MUST). 안전한 격리는 커널 또는 사용자 공간 코드가 DMA를 포함한 격리된 환경의 내부 상태에 액세스하는 데 사용할 수 있는 모든 잠재적인 메커니즘을 차단해야 합니다(MUST). 업스트림 Android 오픈소스 프로젝트(AOSP)는 Trusty 구현을 사용하여 이러한 요구사항을 충족하지만 다른 ARM TrustZone 기반 솔루션이나 서드 파티에서 검토한, 올바른 하이퍼바이저 기반 격리의 안전한 구현도 대안이 될 수 있습니다.
  • [9.11/T-0-3] 격리된 실행 환경에서 잠금 화면 인증을 수행해야 하며, 인증에 성공한 경우에만 인증 귀속 키의 사용을 허용해야 합니다(MUST). 잠금 화면 사용자 인증 정보는 격리된 실행 환경에서만 잠금 화면 인증을 수행할 수 있도록 허용하는 방식으로 저장해야 합니다. 업스트림 Android 오픈소스 프로젝트는 이러한 요구사항을 충족하는 데 사용할 수 있는 게이트키퍼 하드웨어 추상화 계층(HAL)과 Trusty를 제공합니다.
  • [9.11/T-0-4] 증명 서명 키가 보안 하드웨어에 의해 보호되고 서명이 보안 하드웨어에서 수행되는 키 증명을 지원해야 합니다(MUST). 증명 서명 키는 키가 기기 식별자로 사용되지 않도록 충분히 많은 수의 기기에 공유해야 합니다(MUST). 이러한 요구사항을 충족할 수 있는 한 가지 방법은 최소 100,000개의 SKU가 생성되지 않은 이상 동일한 증명 키를 공유하는 것입니다. 100,000개 이상의 SKU가 생성된 경우에는 100,000개당 다른 키를 사용할 수 있습니다(MAY).

기기 구현이 이전 Android 버전에서 이미 출시되었다면 이러한 기기는 키 저장소가 격리된 실행 환경에서 지원되고 키 증명을 지원해야 한다는 요구사항을 충족할 필요가 없습니다. 다만 격리된 실행 환경에서 지원하는 키 저장소를 요구하는 android.hardware.fingerprint 기능을 선언하는 경우는 예외입니다.

보안 잠금 화면을 지원하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [9.11/T-1-1] 사용자가 최대 15초 이내의 최소 허용 시간 제한으로 잠금 해제에서 잠금 상태로 전환하기 위한 절전 모드 시간 제한을 선택할 수 있도록 허용해야 합니다(MUST).

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/T-2-1] 기기 소유자가 기기에서 추가 사용자 및 관련 기능을 관리할 수 있는 기능인 제한된 프로필을 지원해야 합니다(MUST). 기기 소유자는 제한된 프로필을 사용하여 추가 사용자가 작업할 수 있는 별도의 환경을 빠르게 설정하고, 이러한 환경에서 제공되는 앱의 세부적인 제한을 관리할 수 있습니다.

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/T-3-1] 제한된 프로필을 지원하면 안 되지만(MUST NOT) 음성 통화 및 SMS는 다른 사용자의 액세스를 사용 설정/사용 중지하기 위한 제어의 AOSP 구현에 맞게 조정되어야 합니다(MUST).

android.hardware.microphone를 선언하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/H-4-1] HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService 또는 섹션 9.1 권한에서 CDD 식별자 [C-3-X]를 사용하여 호출된 역할을 보유한 앱에서 마이크를 액세스할 때만 아니라 앱이 마이크에서 전송되는 오디오 데이터에 액세스하고 있을 때 마이크 표시기를 표시해야 합니다(MUST).
  • [9.8.2/T-4-2] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 마이크 표시기를 숨기면 안 됩니다(MUST NOT).

android.hardware.camera.any를 선언하는 텔레비전 기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/H-5-1] 섹션 9.1에서 CDD 식별자 [C-3-X]를 사용하여 호출되는 역할을 보유하고 있는 앱에서만 카메라를 액세스하고 있을 때가 아니라 앱이 실시간 카메라 데이터에 액세스하고 있을 때 카메라 표시기를 표시해야 합니다(MUST).
  • [9.8.2/T-5-2] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 카메라 표시기를 숨기면 안 됩니다(MUST NOT).

2.3.6. 개발자 도구 및 옵션 호환성

텔레비전 기기 구현:

  • Perfetto
    • [6.1/T-0-1] cmdline이 perfetto 문서를 준수하는 셸 사용자에게 /system/bin/perfetto 바이너리를 노출시켜야 합니다(MUST).
    • [6.1/T-0-2] perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf config를 입력하는 방식으로 허용해야 합니다(MUST).
    • [6.1/T-0-3] perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf 트레이스를 출력하는 방식으로 작성해야 합니다(MUST).
    • [6.1/T-0-4] perfetto 바이너리를 통해 최소 perfetto 문서에 정의된 데이터를 제공해야 합니다(MUST).

2.4. 시계 요구사항

Android 시계 기기는 손목과 같은 신체에 착용하도록 되어있는 Android 기기 구현입니다.

Android 기기 구현은 다음과 같은 기준을 모두 충족하는 경우 시계로 분류됩니다.

  • 화면의 실제 대각선 길이가 1.1~2.5인치여야 합니다.
  • 몸에 착용할 수 있도록 하기 위한 메커니즘이 있어야 합니다.

이 섹션의 나머지 부분에 기재된 추가적인 요구사항은 Android 시계 기기 구현과 관련이 있습니다.

2.4.1. 하드웨어

시계 기기 구현:

  • [7.1.1.1/W-0-1] 화면의 실제 대각선 크기가 1.1~2.5인치여야 합니다(MUST).

  • [7.2.3/W-0-1] 홈 기능을 사용자에게 제공해야 합니다(MUST). 뒤로 기능도 제공해야 하지만(MUST) UI_MODE_TYPE_WATCH인 경우는 예외입니다.

  • [7.2.4/W-0-1] 터치스크린 입력을 지원해야 합니다(MUST).

  • [7.3.1/W-SR-1] 3축 가속도계를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

GPS/GNSS 수신기를 포함하고 android.hardware.location.gps 기능 플래그를 통해 애플리케이션에 기능을 보고하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [7.3.3/W-1-1] GPS/GNSS에서 계산된 위치가 아직 보고되지 않은 경우에도 감지되는 즉시 GNSS 측정을 보고해야 합니다(MUST).
  • [7.3.3/W-1-2] 위치 파악 이후 정지해 있거나 0.2m/s2 가속도 미만으로 이동해도 open-sky 조건에서 20m 이내의 위치 및 초당 0.2m 내의 속도를 시간 중 95% 이상 계산하는 데 충분한 GNSS 의사 거리 및 의사 거리 비율을 보고해야 합니다(MUST).

3축 자이로스코프를 포함하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/W-2-1] 초당 최대 1,000도의 방향 변화를 측정할 수 있어야 합니다(MUST).

시계 기기 구현:

  • [7.4.3/W-0-1] 블루투스를 지원해야 합니다(MUST).

  • [7.6.1/W-0-1] 애플리케이션 비공개 데이터를 위한 최소 1GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).

  • [7.6.1/W-0-2] 커널 및 사용자 공간에 사용 가능한 최소 416MB 메모리를 보유해야 합니다(MUST).

  • [7.8.1/W-0-1] 마이크를 포함해야 합니다(MUST).

  • [7.8.2/W] 오디오 출력을 보유할 수 있습니다(MAY).

2.4.2. 멀티미디어

추가 요구사항 없음.

2.4.3. 소프트웨어

시계 기기 구현:

  • [3/W-0-1] 기능 android.hardware.type.watch를 선언해야 합니다(MUST).
  • [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH를 지원해야 합니다(MUST).
  • [3.2.3.1/W-0-1] 여기에 나열된 애플리케이션 인텐트로 정의된 모든 공개 인텐트 필터 패턴과 관련하여 인텐트 핸들러가 1개 이상의 애플리케이션 또는 서비스 구성요소를 미리 로드해야 합니다(MUST).

시계 기기 구현:

  • [3.8.4/W-SR-1] 지원 작업 처리를 위한 어시스턴트를 기기에 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

android.hardware.audio.output 기능 플래그를 선언하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [3.10/W-1-1] 서드 파티 접근성 서비스를 지원해야 합니다(MUST).
  • [3.10/W-SR-1] Talkback 오픈소스 프로젝트에서 제공하는 스위치 제어 및 Talkback(사전 설치된 텍스트 음성 변환 엔진에서 지원되는 언어용) 접근성 서비스와 기능이 비슷하거나 이보다 뛰어난 접근성 서비스를 기기에서 미리 로드할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기능 android.hardware.audio.output을 보고하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [3.11/W-SR-1] 기기에서 제공되는 언어를 지원하는 TTS 엔진을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [3.11/W-0-1] 서드 파티 TTS 엔진 설치를 지원해야 합니다(MUST).

2.4.4. 성능 및 전력

AOSP에 포함되었거나 AOSP에 포함된 기능을 확장하는 기기 전력 관리를 개선하는 기능을 포함하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [8.3/W-SR-1] 앱 대기 및 잠자기 절전 모드에서 제외된 모든 앱을 표시하기 위한 사용자 어포던스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [8.3/W-SR-2] 절전 모드 기능을 사용 설정 및 사용 중지하기 위한 사용자 어포던스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

시계 기기 구현:

  • [8.4/W-0-1] Android 오픈소스 프로젝트 사이트에 문서화된 것처럼 각 하드웨어 구성요소의 전력 소모량 값과 시간 경과에 따른 구성요소에 의한 대략적인 배터리 소모를 정의하는 구성요소별 전력 프로필을 제공해야 합니다(MUST).
  • [8.4/W-0-2] 모든 전력 소모량 값(mAh)을 보고해야 합니다(MUST).
  • [8.4/W-0-3] 각 프로세스의 UID별 CPU 전력 소모량을 보고해야 합니다(MUST). Android 오픈소스 프로젝트는 uid_cputime 커널 모듈 구현을 통해 요구사항을 충족합니다.
  • [8.4/W-0-4] adb shell dumpsys batterystats 셸 명령어를 통해 이러한 전력 사용량을 앱 개발자에게 제공해야 합니다(MUST).
  • [8.4/W] 하드웨어 구성요소 전력 사용량을 애플리케이션에 출처로 표시할 수 없는 경우 하드웨어 구성요소 자체를 출처로 표시해야 합니다(SHOULD).

2.4.5. 보안 모델

시계 기기 구현:

  • [9/W-0-1] android.hardware.security.model.compatible 기능을 선언해야 합니다(MUST).

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하지 않는 시계 기기 구현은 다음을 충족해야 합니다.

  • [9.5/W-1-1] 기기 소유자가 기기에서 추가 사용자 및 관련 기능을 관리할 수 있는 기능인 제한된 프로필을 지원해야 합니다(MUST). 기기 소유자는 제한된 프로필을 사용하여 추가 사용자가 작업할 수 있는 별도의 환경을 빠르게 설정하고, 이러한 환경에서 제공되는 앱의 세부적인 제한을 관리할 수 있습니다.

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하는 시계 기기 구현은 다음을 충족해야 합니다.

  • [9.5/W-2-1] 제한된 프로필을 지원하면 안 되지만(MUST NOT) 음성 통화 및 SMS는 다른 사용자의 액세스를 사용 설정/중지하는 제어 구현을 AOSP 구현에 맞게 조정해야 합니다(MUST).

보안 잠금 화면이 있고 TrustAgentService System API를 구현하는 1개 이상의 Trust Agent를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [9.11.1/W-1-1] 72시간마다 한 번 이상, 권장되는 기본 인증 방법(예: PIN, 패턴, 비밀번호) 중 하나를 사용자에게 요구해야 합니다(MUST).

2.5. 자동차 요구사항

Android Automotive 구현은 Android를 시스템이나 인포테인먼트 기능의 부분 또는 전체를 맡는 운영체제로 실행하는 차량 헤드 단위입니다.

Android 기기 구현은 기능 android.hardware.type.automotive를 선언하거나 다음과 같은 기준을 모두 충족하는 경우 Automotive로 분류됩니다.

  • 자동차의 일부로 내장되거나 자동차에 연결 가능합니다.
  • 운전석의 화면을 기본 디스플레이로 사용합니다.

이 섹션의 나머지 부분에 기재된 추가적인 요구사항은 Android 자동차 기기 구현과 관련이 있습니다.

2.5.1. 하드웨어

Automotive 기기 구현:

  • [7.1.1.1/A-0-1] 화면의 실제 대각선 크기가 최소 6인치여야 합니다(MUST).
  • [7.1.1.1/A-0-2] 화면 크기 레이아웃이 최소 750dp x 480dp여야 합니다(MUST).
  • [7.2.3/A-0-1] 홈 기능을 제공해야 하며(MUST) 뒤로 및 최근 항목 기능을 제공할 수 있습니다(MAY).
  • [7.2.3/A-0-2] '뒤로' 기능(KEYCODE_BACK)의 보통 누르기 및 길게 누르기 이벤트를 모두 포그라운드 애플리케이션에 전송해야 합니다(MUST).
  • [7.3/A-0-1] GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED, PARKING_BRAKE_ON을 구현 및 보고해야 합니다(MUST).
  • [7.3/A-0-2] NIGHT_MODE 플래그 값이 대시보드 주간/야간 모드와 일치해야 하며(MUST) 주변광 센서 입력에 기반해야 합니다(SHOULD). 기본 주변광 센서는 광도계와 같을 수 있습니다(MAY).
  • [7.3/A-0-3] 센서에 추가 정보 필드 TYPE_SENSOR_PLACEMENT를 제공된 모든 센서에 관한 SensorAdditionalInfo의 일부로 제공해야 합니다(MUST).
  • [7.3/A-SR1] GPS/GNSS를 추가 센서와 융합하여 위치를 추측항법으로 확인할 수 있습니다(MAY). 위치가 추측항법으로 확인된 경우 해당하는 센서 유형 또는 사용된 차량 속성 ID를 구현 및 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [7.3/A-0-4] LocationManager#requestLocationUpdates()를 통해 요청된 위치는 맵과 일치해서는 안 됩니다(MUST NOT).

  • [7.3.1/A-0-4] Android 자동차 센서 좌표계를 준수해야 합니다(MUST).

  • [7.3/A-SR-1] 3축 가속도계와 3축 자이로스코프를 포함할 것을 적극 권장합니다(STRONGLY_RECOMMENDED).

  • [7.3/A-SR-2] TYPE_HEADING 센서를 구현하고 보고할 것을 적극 권장합니다(STRONGLY_RECOMMENDED).

OpenGL ES 3.1을 지원하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.1.4.1/A-0-1] OpenGL ES 3.1 이상을 선언해야 합니다(MUST).
  • [7.1.4.1/A-0-2] Vulkan 1.1을 지원해야 합니다(MUST).
  • [7.1.4.1/A-0-3] Vulkan 로더를 포함하고 모든 기호를 내보내야 합니다(MUST).

가속도계를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.1/A-1-1] 최소 100Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).

3축 가속도계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [7.3.1/A-SR-1] 제한된 축 가속도계용 복합 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 미만의 가속도계를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.1/A-1-3] TYPE_ACCELEROMETER_LIMITED_AXES 센서를 구현하고 보고해야 합니다(MUST).
  • [7.3.1/A-1-4] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED 센서를 구현하고 보고해야 합니다(MUST).

자이로스코프를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/A-2-1] 최소 100Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [7.3.4/A-2-3] 초당 최대 250도의 방향 변화를 측정할 수 있어야 합니다(MUST).
  • [7.3.4/A-SR-1] 해상도를 최대화할 수 있도록 자이로스코프의 측정 범위를 +/-250dp로 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 자이로스코프를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/A-SR-2] 제한된 축 자이로스코프용 복합 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 미만의 자이로스코프를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES 센서를 구현하고 보고해야 합니다(MUST).
  • [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED 센서를 구현하고 보고해야 합니다(MUST).

GPS/GNSS 수신기를 포함하지만 셀룰러 네트워크 기반 데이터 연결은 포함하지 않는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.3/A-3-1] GPS/GNSS 수신기를 맨 처음 켰을 때 또는 4일 이상이 지난 후의 위치를 60초 안으로 지정해야 합니다(MUST).
  • [7.3.3/A-3-2] 7.3.3/C-1-2와 7.3.3/C-1-6에 설명된 것처럼 다른 위치 요청(즉, 맨 처음 키는 경우나 4일 이상이 지나고 확인하는 것 외의 요청)을 모두 충족하는 최초 수정 시간 구간을 확인해야 합니다(MUST). 7.3.3/C-1-2 요구사항은 일반적으로 셀룰러 네트워크 기반 데이터 연결이 없는 차량에서 충족되는데, 이때 수신기에서 계산된 GNSS 궤도 예측을 사용하거나 마지막으로 알려진 차량의 위치를 추측항법으로 최소 60초 이상 7.3.3/C-1-3을 만족하는 위치 정확도와 함께 사용하기도 하며 두 가지 방법을 모두 사용할 때도 있습니다.

TYPE_HEADING 센서를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/A-4-3] 최소 1Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [7.3.4/A-SR-3] 최소 10Hz의 주파수까지 이벤트를 보고할 것을 적극 권장합니다(STRONGLY_RECOMMENDED).
  • 진북을 참조해야 합니다(SHOULD).
  • 차량이 정지 상태인 경우에도 사용할 수 있어야 합니다(SHOULD).
  • 감도가 1도 이상이어야 합니다(SHOULD).

Automotive 기기 구현:

  • [7.4.3/A-0-1] 블루투스(MUST)와 블루투스 LE(SHOULD)를 지원해야 합니다.
  • [7.4.3/A-0-2] Android 자동차 구현은 다음과 같은 블루투스 프로필을 지원해야 합니다(MUST).
    • 핸즈프리 프로필(HFP)을 통한 전화 통화
    • 오디오 전송 프로필(A2DP)을 통한 미디어 재생
    • 원격 제어 프로필(AVRCP)을 통한 미디어 재생 제어
    • 전화번호부 액세스 프로필(PBAP)을 사용한 연락처 공유

  • [7.4.3/A-SR-1] 메시지 액세스 프로필(MAP)을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [7.4.5/A] 셀룰러 네트워크 기반 연결 지원을 포함해야 합니다(SHOULD).

  • [7.4.5/A] 시스템 앱에 제공해야 하는 네트워크에 대해 시스템 API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 상수를 사용할 수 있습니다(MAY).

AM/FM 브로드캐스트 라디오 지원을 포함하고 이 기능을 모든 애플리케이션에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [7.4/A-0-1] FEATURE_BROADCAST_RADIO 지원을 선언해야 합니다(MUST).

후면 카메라는 차량의 원하는 곳 어디에나 위치하여 차량 외부를 향하는 바깥쪽 카메라를 의미합니다. 즉, 후면 카메라는 후방 카메라와 같이 차량 본체의 반대편을 촬영합니다.

전면 카메라는 차량의 원하는 곳 어디에나 위치하여 차량 내부를 향하는 사용자 대상 카메라를 의미합니다. 즉, 전면 카메라는 화상 회의나 이와 비슷한 애플리케이션을 위해 사용자를 촬영합니다.

Automotive 기기 구현:

  • [7.5/A-SR-1] 1대 이상의 바깥쪽 카메라를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • 1대 이상의 사용자 대상 카메라를 포함할 수 있습니다(MAY).
  • [7.5/A-SR-2] 여러 카메라의 동시 스트리밍을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

바깥쪽 카메라를 1대 이상 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-1-1] 카메라의 긴 쪽이 Android Automotive 센서 축의 XY 평면과 정렬되도록 방향을 설정해야 합니다(MUST).
  • [7.5/A-SR-3] 고정 초점 또는 EDOF(확장 심도) 하드웨어를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [7.5/A-1-2] 바깥쪽 기본 카메라는 카메라 ID가 가장 낮은 바깥쪽 카메라여야 합니다(MUST).

사용자 대상 카메라를 1대 이상 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-2-1] 사용자 대상 기본 카메라는 카메라 ID가 가장 낮은 사용자 대상 카메라여야 합니다(MUST).
  • 카메라의 긴 쪽이 Android Automotive 센서 축의 XY 평면과 정렬되도록 방향을 설정할 수 있습니다(MAY).

android.hardware.Camera 또는 android.hardware.camera2 API를 통해 액세스할 수 있는 카메라를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-3-1] 섹션 7.5의 핵심 카메라 요구사항을 준수해야 합니다(MUST).

android.hardware.Camera 또는 android.hardware.camera2 API를 통해 액세스할 수 없는 카메라를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-4-1] 확장 뷰 시스템 서비스를 통해 액세스할 수 있어야 합니다(MUST).

확장 뷰 시스템 서비스를 통해 액세스할 수 있는 카메라를 1대 이상 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-5-1] 카메라 미리보기를 회전하거나 가로로 미러링하면 안 됩니다(MUST NOT).
  • [7.5/A-SR-4] 해상도가 1.3메가픽셀 이상일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Extended View System 서비스와 android.hardware.Camera 또는 android.hardware.Camera2 API를 통해 액세스할 수 있는 카메라를 1대 이상 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-6-1] 동일한 카메라 ID를 보고해야 합니다(MUST).

독점 카메라 API를 제공하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.5/A-7-1] android.hardware.camera2 API 또는 Extended View System API를 사용하여 이러한 카메라 API를 구현해야 합니다(MUST).

Automotive 기기 구현:

  • [7.6.1/A-0-1] 애플리케이션 비공개 데이터를 위한 최소 4GB의 비휘발성 저장소('/data' 파티션)를 보유해야 합니다(MUST).

  • [7.6.1/A] 플래시 저장소의 성능과 수면이 개선되도록 데이터 파티션 형식을 지정해야 합니다(SHOULD). 예를 들면 f2fs 파일 시스템을 사용합니다.

내부 일체형 저장소의 일부를 통해 공유된 외부 저장소를 제공하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [7.6.1/A-SR-1] 외부 저장소에서 실행되는 작업의 I/O 오버헤드를 줄일 것을 적극 권장합니다(STRONGLY RECOMMENDED). 예를 들면 SDCardFS를 사용합니다.

Automotive 기기 구현이 64비트인 경우:

  • [7.6.1/A-2-1] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 816MB여야 합니다(MUST).

    • 소형/일반 화면에서 280dpi 이하
    • 초대형 화면에서 ldpi 이하
    • 대형 화면에서 mdpi 이하

  • [7.6.1/A-2-2] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 944MB여야 합니다(MUST).

    • 소형/일반 화면에서 xhdpi 이상
    • 대형 화면에서 hdpi 이상
    • 초대형 화면에서 mdpi 이상

  • [7.6.1/A-2-3] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1280MB여야 합니다(MUST).

    • 소형/일반 화면에서 400dpi 이상
    • 대형 화면에서 xhdpi 이상
    • 초대형 화면에서 tvdpi 이상

  • [7.6.1/A-2-4] 다음 밀도가 사용되는 경우 커널 및 사용자 공간에 사용 가능한 메모리가 최소 1824MB여야 합니다(MUST).

    • 소형/일반 화면에서 560dpi 이상
    • 대형 화면에서 400dpi 이상
    • 초대형 화면에서 xhdpi 이상

위에서 언급한 '커널 및 사용자 공간에 사용 가능한 메모리'는 기기 구현에서 커널의 제어를 받지 않는 라디오, 동영상 등의 하드웨어 구성요소에 이미 전용으로 사용되고 있는 모든 메모리 외에 추가로 제공되는 메모리 공간을 의미합니다.

Automotive 기기 구현:

  • [7.7.1/A] 주변기기 모드를 지원하는 USB 포트를 포함해야 합니다(SHOULD).

Automotive 기기 구현:

  • [7.8.1/A-0-1] 마이크를 포함해야 합니다(MUST).

Automotive 기기 구현:

  • [7.8.2/A-0-1] 오디오 출력을 보유하고 android.hardware.audio.output을 선언해야 합니다(MUST).

2.5.2. 멀티미디어

Automotive 기기 구현은 다음과 같은 오디오 인코딩 및 디코딩 형식을 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.1/A-0-1] MPEG-4 AAC 프로필(AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC 프로필(AAC+)
  • [5.1/A-0-3] AAC ELD(향상된 저지연 AAC)

Automotive 기기 구현은 다음과 같은 동영상 인코딩 형식을 지원하고 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

Automotive 기기 구현은 다음과 같은 동영상 디코딩 형식을 지원하고 서드 파티 애플리케이션에 제공해야 합니다(MUST).

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

Automotive 기기 구현은 다음과 같은 동영상 디코딩을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [5.3/A-SR-1] H.265 HEVC

2.5.3. 소프트웨어

Automotive 기기 구현:

  • [3/A-0-1] 기능 android.hardware.type.automotive를 지원해야 합니다(MUST).

  • [3/A-0-2] uiMode = UI_MODE_TYPE_CAR를 지원해야 합니다(MUST).

  • [3/A-0-3] android.car.* 네임스페이스의 모든 공개 API를 지원해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[3/A-0-4][철회됨](2024년 4월 8일 미리보기)
다음 요구사항은 Android 15(AOSP 실험용)에서 철회되었습니다.

새로운 요구사항 종료

[3/A-0-4](2023년 12월 11일 미리보기)

  • [3/A-0-4] 자동차 화면용 Adapt 앱을 지원해야 합니다(MUST).

새로운 요구사항 종료

android.car.CarPropertyManager와 android.car.VehiclePropertyIds를 사용하여 독점 API를 제공하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [3/A-1-1] 시스템 애플리케이션에서 속성을 사용하는 것에 특수 권한을 주거나 서드 파티 애플리케이션에서 해당 속성을 사용하는 것을 막으면 안 됩니다(MUST NOT).
  • [3/A-1-2] SDK에 이미 존재하는 차량 속성을 복제해서는 안 됩니다(MUST NOT).

Automotive 기기 구현:

  • [3.2.1/A-0-1] Automotive 권한 참조 페이지에 문서화된 모든 권한 상수를 지원하고 적용해야 합니다(MUST).

  • [3.2.3.1/A-0-1] 여기에 나열된 애플리케이션 인텐트로 정의된 모든 공개 인텐트 필터 패턴과 관련하여 인텐트 핸들러가 1개 이상의 애플리케이션 또는 서비스 구성요소를 미리 로드해야 합니다(MUST).

  • [3.4.1/A-0-1] android.webkit.Webview API의 온전한 구현을 제공해야 합니다(MUST).

  • [3.8/A-0-1] 현재 포그라운드 사용자가 아닌 전체 보조 사용자가 활동을 실행하고 모든 디스플레이에서 UI에 액세스하도록 허용하면 안 됩니다(MUST NOT).

  • [3.8.3/A-0-1] 서드 파티 애플리케이션의 요청을 받았을 때 Notification.CarExtender API를 사용하는 알림을 표시해야 합니다(MUST).

  • [3.8.4/A-SR-1] 지원 작업 처리를 위한 어시스턴트를 기기에 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

눌러서 말하기 버튼을 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [3.8.4/A-1-1] 사용자가 선택한 지원 앱 즉, VoiceInteractionService를 구현하는 앱을 실행하기 위해 지정된 상호작용으로 눌러서 말하기 버튼을 짧게 눌러야 합니다(MUST).

Automotive 기기 구현:

  • [3.8.3.1/A-0-1] Notifications on Automotive OS SDK 문서의 설명처럼 리소스를 올바르게 렌더링해야 합니다(MUST).
  • [3.8.3.1/A-0-2] Notification.Builder.addAction()을 통해 제공되는 위치에 알림 작업에 대해 PLAY 및 MUTE를 표시해야 합니다(MUST).
  • [3.8.3.1/A] 알림 채널별 제어와 같은 리치 관리 작업의 사용을 제한해야 합니다(SHOULD). 애플리케이션마다 UI 어포던스를 사용하여 제어를 축소할 수 있습니다(MAY).

사용자 HAL 속성을 지원하는 Automotive 기기 구현은 다음을 충족해야 합니다.

Automotive 기기 구현:

기본 런처 앱을 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

Automotive 기기 구현:

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[3.14/A-0-8](2024년 4월 8일 미리보기)

새로운 요구사항 종료

  • [3.8/A] immersive documentation의 설명처럼 전체 화면 모드로 전환하기 위한 애플리케이션 요청을 제한할 수 있습니다(MAY).
  • [3.8/A] 상태 표시줄과 탐색 메뉴가 항상 표시되도록 유지할 수 있습니다(MAY).
  • [3.8/A] 시스템 UI 요소 배경색을 변경하기 위한 애플리케이션 요청을 제한하여 요소가 항상 명확하게 표시되도록 할 수 있습니다(MAY).

2.5.4. 성능 및 전력

Automotive 기기 구현:

  • [8.2/A-0-1] 시스템 API android.car.storagemonitoring.CarStorageMonitoringManager를 통해 상태를 개발자에게 제공할 수 있도록 각 프로세스 UID의 비휘발성 저장소에 판독 및 작성된 바이트 수를 보고해야 합니다(MUST). Android 오픈소스 프로젝트는 uid_sys_stats 커널 모듈을 통해 요구사항을 충족합니다.
  • [8.3/A-1-3] 차고 모드를 지원해야 합니다(MUST).
  • [8.3/A] 다음 경우를 제외하고 운전을 마칠 때마다 최소 15분 동안 차고 모드를 유지해야 합니다(SHOULD).
    • 배터리가 방전된 경우
    • 예약된 유휴 작업이 없는 경우
    • 운전자가 차고 모드를 종료하는 경우
  • [8.4/A-0-1] Android 오픈소스 프로젝트 사이트에 문서화된 것처럼 각 하드웨어 구성요소의 전력 소모량 값과 시간 경과에 따른 대략적인 배터리 소모를 정의하는 구성요소별 전력 프로필을 제공해야 합니다(MUST).
  • [8.4/A-0-2] 모든 전력 소모량 값을 밀리암페어 시간(mAh)으로 보고해야 합니다(MUST).
  • [8.4/A-0-3] 각 프로세스의 UID별 CPU 전력 소모량을 보고해야 합니다(MUST). Android 오픈소스 프로젝트는 uid_cputime 커널 모듈 구현을 통해 요구사항을 충족합니다.
  • [8.4/A] 하드웨어 구성요소 전력 사용량을 애플리케이션에 출처로 표시할 수 없는 경우 하드웨어 구성요소 자체를 출처로 표시해야 합니다(SHOULD).
  • [8.4/A-0-4] adb shell dumpsys batterystats 셸 명령어를 통해 이러한 전력 사용량을 앱 개발자에게 제공해야 합니다(MUST).

2.5.5. 보안 모델

여러 사용자를 지원하는 Automotive 기기 구현은 다음을 충족해야 합니다.

android.hardware.microphone를 선언하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/A-1-1] HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService 또는 CDD 식별자 [C-4-X]를 사용하여 섹션 9.1에서 호출된 역할을 보유하는 앱에서만 마이크에 액세스할 때가 아니라 앱이 마이크에서 전송되는 오디오 데이터에 액세스하고 있을 때 마이크 표시기를 표시해야 합니다(MUST).
  • [9.8.2/A-1-2] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 마이크 표시기를 숨기면 안 됩니다(MUST NOT).
  • [9.8.2/A-1-3] 설정 앱에서 마이크를 전환하는 사용자 어포던스를 제공해야 합니다(MUST).

android.hardware.camera.any를 선언하는 Automotive 기기 구현은 다음을 충족해야 합니다.

  • [9.8.2/A-2-1] 섹션 9.1 권한에서 CDD 식별자 [C-4-X]로 정의된 역할을 보유하고 있는 앱에서만 카메라에 액세스하고 있을 때가 아니라 앱이 실시간 카메라 데이터에 액세스하고 있을 때 카메라 표시기를 표시해야 합니다(MUST).
  • [9.8.2/A-2-2] 사용자 인터페이스가 표시되거나 직접적인 사용자 상호작용이 있는 시스템 앱의 카메라 표시기를 숨기면 안 됩니다(MUST NOT).
  • [9.8.2/A-2-3] 설정 앱에서 카메라를 전환하는 사용자 어포던스를 제공해야 합니다(MUST).
  • [9.8.2/A-2-4] PermissionManager.getIndicatorAppOpUsageData()에서 반환될 때 카메라를 사용하는 최근 앱 및 활성 앱과 이러한 앱에 연결된 저작자 표시 메시지를 함께 표시해야 합니다(MUST).

Automotive 기기 구현:

  • [9/A-0-1] android.hardware.security.model.compatible 기능을 선언해야 합니다(MUST).
  • [9.11/A-0-1] 격리된 실행 환경으로 키 저장소 구현을 지원해야 합니다(MUST).
  • [9.11/A-0-2] RSA, AES, ECDSA, HMAC 암호화 알고리즘 및 MD5, SHA1, SHA-2 계열 해시 함수를 구현하여 커널과 위에서 실행 중인 코드에서 안전하게 격리된 영역에서 Android 키 저장소 시스템의 지원되는 알고리즘을 제대로 지원해야 합니다(MUST). 안전한 격리는 커널 또는 사용자 공간 코드가 DMA를 포함한 격리된 환경의 내부 상태에 액세스하는 데 사용할 수 있는 모든 잠재적인 메커니즘을 차단해야 합니다(MUST). 업스트림 Android 오픈소스 프로젝트(AOSP)는 Trusty 구현을 사용하여 이러한 요구사항을 충족하지만 다른 ARM TrustZone 기반 솔루션이나 서드 파티에서 검토한, 올바른 하이퍼바이저 기반 격리의 안전한 구현도 대안이 될 수 있습니다.
  • [9.11/A-0-3] 격리된 실행 환경에서 잠금 화면 인증을 수행해야 하며, 인증에 성공한 경우에만 인증 귀속 키의 사용을 허용해야 합니다(MUST). 잠금 화면 사용자 인증 정보는 격리된 실행 환경에서만 잠금 화면 인증을 수행할 수 있도록 허용하는 방식으로 저장해야 합니다. 업스트림 Android 오픈소스 프로젝트는 이러한 요구사항을 충족하는 데 사용할 수 있는 게이트키퍼 하드웨어 추상화 계층(HAL)과 Trusty를 제공합니다.
  • [9.11/A-0-4] 증명 서명 키가 보안 하드웨어에 의해 보호되고 서명이 보안 하드웨어에서 수행되는 키 증명을 지원해야 합니다(MUST). 증명 서명 키는 키가 기기 식별자로 사용되지 않도록 충분히 많은 수의 기기에 공유해야 합니다(MUST). 이러한 요구사항을 충족할 수 있는 한 가지 방법은 최소 100,000개의 SKU가 생성되지 않은 이상 동일한 증명 키를 공유하는 것입니다. 100,000개 이상의 SKU가 생성된 경우에는 100,000개당 다른 키를 사용할 수 있습니다(MAY).

기기 구현이 이전 Android 버전에서 이미 출시되었다면 이러한 기기는 키 저장소가 격리된 실행 환경에서 지원되고 키 증명을 지원해야 한다는 요구사항을 충족할 필요가 없습니다. 다만 격리된 실행 환경에서 지원하는 키 저장소를 요구하는 android.hardware.fingerprint 기능을 선언하는 경우는 예외입니다.

Automotive 기기 구현:

  • [9.14/A-0-1] Android 프레임워크 하위 시스템의 메시지를 게이트키핑해야 합니다(MUST). 예를 들면 허용된 메시지 유형과 메시지 소스를 허용 목록에 추가해야 합니다.
  • [9.14/A-0-2] Android 프레임워크 또는 서드 파티 앱의 서비스 거부 공격을 감시해야 합니다(MUST). 이는 악성 소프트웨어가 차량 네트워크를 트래픽으로 플러딩시켜 차량 하위 시스템 오작동으로 이어지지 않도록 보호해 줍니다.

2.5.6. 개발자 도구 및 옵션 호환성

Automotive 기기 구현:

  • Perfetto
    • [6.1/A-0-1] cmdline이 perfetto 문서를 준수하는 셸 사용자에게 /system/bin/perfetto 바이너리를 노출시켜야 합니다(MUST).
    • [6.1/A-0-2] perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf config를 입력하는 방식으로 허용해야 합니다(MUST).
    • [6.1/A-0-3] perfetto 바이너리가 perfetto 문서에 정의된 스키마를 준수하는 protobuf 트레이스를 출력하는 방식으로 작성해야 합니다(MUST).
    • [6.1/A-0-4] perfetto 바이너리를 통해 최소 perfetto 문서에 정의된 데이터를 제공해야 합니다(MUST).

2.6. 태블릿 요구사항

Android 태블릿 기기는 일반적으로 다음의 모든 기준을 모두 충족하는 Android 기기 구현을 의미합니다.

  • 양손으로 잡고 사용합니다.
  • 폴더형 또는 컨버터블 구성이 없습니다.
  • 표준 연결(예: USB, 블루투스)을 통해 기기와 연결되는 물리적 키보드 구현입니다.

  • 휴대성을 제공하는 전원(예: 배터리)이 있습니다.

  • 대각선으로 측정한 화면 디스플레이 크기가 7인치보다 크고 18인치보다 작습니다.

태블릿 기기 구현의 요구사항이 휴대기기 구현과 비슷해야 합니다. 예외는 해당 섹션의 *로 표시되며 이 섹션에서 참조로 표시됩니다.

2.6.1. 하드웨어

자이로스코프

3축 자이로스코프를 포함하는 태블릿 기기 구현은 다음을 충족해야 합니다.

  • [7.3.4/Tab-1-1] 초당 최대 1,000도의 방향 변화를 측정할 수 있어야 합니다(MUST).

최소 메모리 및 저장소(섹션 7.6.1)

휴대기기 요구사항의 소형/일반 화면과 관련하여 나열된 화면 밀도는 태블릿에 적용되지 않습니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[7.7.1/탭](2023년 12월 11일 미리보기)

USB 주변기기 모드(섹션 7.7.1)

주변기기 모드를 지원하는 USB 포트를 포함하는 태블릿 기기 구현은 다음을 충족해야 합니다.

  • [7.7.1/탭] Android Open Accessory(AOA) API를 구현할 수 있습니다(MAY).

새로운 요구사항 종료

가상 현실 모드(섹션 7.9.1)

가상 현실 고성능(섹션 7.9.2)

가상 현실 요구사항은 태블릿에 적용되지 않습니다.

2.6.2. 보안 모델

키 및 사용자 인증 정보(섹션 9.11)

섹션 [9.11]을 참고하세요.

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하지 않는 태블릿 기기 구현은 다음을 충족해야 합니다.

  • [9.5/T-1-1] 기기 소유자가 기기에서 추가 사용자 및 관련 기능을 관리할 수 있는 기능인 제한된 프로필을 지원해야 합니다(MUST). 기기 소유자는 제한된 프로필을 사용하여 추가 사용자가 작업할 수 있는 별도의 환경을 빠르게 설정하고, 이러한 환경에서 제공되는 앱의 세부적인 제한을 관리할 수 있습니다.

멀티 사용자를 포함하고 android.hardware.telephony 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [9.5/T-2-1] 제한된 프로필을 지원하면 안 되지만(MUST NOT) 음성 통화 및 SMS는 다른 사용자의 액세스를 사용 설정/중지하는 제어 구현을 AOSP 구현에 맞게 조정해야 합니다(MUST).

2.6.2. 소프트웨어

  • [3.2.3.1/Tab-0-1] 여기에 나열된 애플리케이션 인텐트로 정의된 모든 공개 인텐트 필터 패턴과 관련하여 인텐트 핸들러가 1개 이상의 애플리케이션 또는 서비스 구성요소를 미리 로드해야 합니다(MUST).

3. 소프트웨어

3.1. 관리 API 호환성

관리되는 Dalvik 바이트 코드 실행 환경은 Android 애플리케이션의 주된 매개체입니다. Android 애플리케이션 프로그래밍 인터페이스(API)는 관리되는 런타임 환경에서 실행되는 애플리케이션에 노출되는 Android 플랫폼 인터페이스 집합입니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] Android SDK 또는 업스트림 Android 소스 코드에서 '@SystemApi' 마커로 데코레이트된 모든 API에 의해 노출되는 모든 문서화된 API의 온전한 구현(모든 문서화된 동작 포함)을 제공해야 합니다(MUST).

  • [C-0-2] TestApi 주석(@TestApi)으로 표시된 모든 클래스, 메서드, 관련 요소를 지원/보존해야 합니다(MUST).

  • [C-0-3] 이 기능성 정의에 의해 구체적으로 허용되지 않는 경우를 제외하고는 관리 API를 생략하거나 API 인터페이스 또는 서명을 변경하거나 문서화된 동작에서 벗어나거나 노옵스(no-ops)를 포함하면 안 됩니다(MUST NOT).

  • [C-0-4] Android가 API를 포함하는 일부 하드웨어 기능이 생략된 경우에도 계속해서 API의 존재를 유지하고 합리적인 방식으로 동작해야 합니다(MUST). 이 시나리오의 구체적인 요구사항은 섹션 7을 참고하세요.

  • [C-0-5] AOSP의 부팅 클래스 경로에 있는 자바 언어 패키지에서 메서드 및 필드로 정의되고 공개 SDK의 일부를 형성하지 않는 비 SDK 인터페이스를 서드 파티 앱에서 사용하도록 허용하면 안 됩니다(MUST NOT). 여기에는 SDK 문서의 설명처럼 @hide 주석으로 데코레이트되었지만 @SystemAPI로는 데코레이트되지 않은 API, 그리고 비공개 및 package-private 클래스 멤버가 포함됩니다.

  • [C-0-6] AOSP의 적절한 API 수준 브랜치와 관련된 prebuilts/runtime/appcompat/hiddenapi-flags.csv 경로의 차단 목록 플래그를 통해 제공되는 동일한 제한된 목록의 모든 비 SDK 인터페이스와 함께 배송되어야 합니다(MUST).

  • [C-0-7] 서명된 config 동적 업데이트 메커니즘을 지원하여 비 SDK 인터페이스를 제한된 목록에서 제거해야 하며, 이때 AOSP에 존재하는 기존 공개 키를 사용하여 모든 APK의 서명된 구성을 삽입해야 합니다(MUST).

    하지만 다음을 실행할 수 있습니다.

    • 숨겨진 API가 있거나 기기 구현에서 다르게 구현된 경우 숨겨진 API를 차단 목록으로 이동하거나 모든 제한된 목록에서 삭제할 수 있습니다(MAY).
    • 숨겨진 API가 이미 AOSP에 없다면 숨겨진 API를 제한된 목록에 추가할 수 있습니다(MAY).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-0-8](2024년 4월 8일 미리보기)

  • [C-0-8] API 수준 23 24 미만을 타겟팅하는 애플리케이션의 설치를 지원하면 안 됩니다(MUST NOT).

새로운 요구사항 종료

[C-0-8](2023년 12월 11일 미리보기)

  • [C-0-8] API 수준 23 25 미만을 타겟팅하는 애플리케이션의 설치를 지원하면 안 됩니다(MUST NOT).

새로운 요구사항 종료

3.1.1. Android 확장 프로그램

Android는 특정 API 수준의 확장 버전을 업데이트하여 해당 API 수준의 관리되는 API 표시 경로 확장을 지원합니다. 해당 API 수준에 대한 확장이 있는 경우 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API는 제공된 apiLevel의 확장 버전을 반환합니다.

Android 기기 구현:

  • [C-0-1] 공유 라이브러리 ExtShared 및 서비스 ExtServices 둘 다의 AOSP 구현을 미리 로드해야 하며, 버전은 각 API 수준별로 허용되는 최소 버전 이상이어야 합니다(MUST). 예를 들어 API 수준 24를 실행하는 Android 7.0 기기 구현은 최소 버전 1을 포함해야 합니다.

  • [C-0-2] AOSP에서 정의된 유효한 확장 프로그램 버전 번호만 반환해야 합니다(MUST).

  • [C-0-3] 섹션 3.1의 요구사항에 따라 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)에서 반환된 확장 프로그램 버전이 정의한 모든 API는 다른 관리되는 API를 지원하는 것과 동일한 방식으로 지원해야 합니다(MUST).

3.1.2. Android 라이브러리

Apache HTTP 클라이언트 지원 중단으로 인해 기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] org.apache.http.legacy 라이브러리를 bootclasspath에 삽입하면 안 됩니다(MUST NOT).
  • [C-0-2] 앱이 다음 조건 중 하나를 충족하는 경우에만 org.apache.http.legacy 라이브러리를 애플리케이션 클래스 경로에 추가해야 합니다(MUST).
    • API 수준 28 이하를 타겟팅합니다.
    • <uses-library>의 android:name 속성을 org.apache.http.legacy로 설정하여 라이브러리가 필요하다는 내용을 매니페스트에 선언합니다.

AOSP 구현은 이러한 요구사항을 충족합니다.

3.2. 소프트 API 호환성

Android는 섹션 3.1의 관리 API 외에 중요한 런타임 전용 'soft' API도 포함하고 있습니다. 이러한 API는 애플리케이션 컴파일 시간에 적용할 수 없는 Android 애플리케이션의 인텐트, 권한과 유사 측면 등의 형식을 취합니다.

3.2.1. 권한

  • [C-0-1] 기기 구현은 권한 참조 페이지에 문서화된 모든 권한 상수를 지원 및 적용해야 합니다(MUST). 섹션 9에는 Android 보안 모델과 관련된 추가 요구사항이 나열되어 있습니다.

3.2.2. 빌드 매개변수

Android API에는 현재 기기를 설명해주는 android.os.Build 클래스의 상수 개수가 포함되어 있습니다.

  • [C-0-1] 기기 구현 전체에 걸친 일관적이고 의미 있는 값을 제공하기 위해 아래 표에는 기기 구현에서 준수해야 하는(MUST) 형식에 관한 추가 제한이 포함되어 있습니다.
매개변수 세부정보
VERSION.RELEASE 현재 실행 중인 Android 시스템의 버전은 인간이 읽을 수 있는 형식입니다. 이 필드에는 Android 15에 허용되는 버전 문자열에 정의된 문자열 값 중 하나가 있어야 합니다(MUST).
VERSION.SDK 현재 실행 중인 Android 시스템의 버전입니다. 서드 파티 애플리케이션 코드에 액세스 가능한 형식입니다. Android 15의 경우 이 필드가 정수 값 15_INT를 보유해야 합니다(MUST).
VERSION.SDK_INT 현재 실행 중인 Android 시스템의 버전입니다. 서드 파티 애플리케이션 코드에 액세스 가능한 형식입니다. Android 15의 경우 이 필드가 정수 값 15INT를 보유해야 합니다(MUST).
VERSION.INCREMENTAL 현재 실행 중인 Android 시스템의 특정 빌드를 지정하며 기기 구현자가 선택한 값입니다. 사람이 읽을 수 있는 형식입니다. 이 값은 최종 사용자에게 제공되는 상이한 빌드에 재사용되면 안 됩니다(MUST NOT). 이 필드의 일반적인 용도는 어떤 빌드 번호 또는 소스 제어 변경 식별자가 빌드를 생성하는 데 사용되었는지를 나타내는 것입니다. 필드의 값은 출력 가능한 7비트 ASCII로 인코딩되어야 하며 ^[^ :\/~]+$ 정규 표현식과 일치해야 합니다(MUST).
BOARD 기기에서 사용하는 특정 내부 하드웨어를 식별하며 기기 구현자가 선택한 값입니다. 사람이 읽을 수 있는 형식입니다. 이 필드는 기기 보드의 특정 버전을 나타내는 데 사용될 수 있습니다. 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9-]+$ 정규 표현식과 일치해야 합니다(MUST).
BRAND 최종 사용자에게 알려진 기기와 관련된 브랜드 이름을 반영하는 값입니다. 인간이 읽을 수 있는 형식이어야 하며(MUST) 기기를 마케팅하는 기기 제조업체 또는 회사 브랜드를 나타내야 합니다(SHOULD). 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9_-]+$ 정규 표현식과 일치해야 합니다(MUST).
SUPPORTED_ABIS 네이티브 코드의 명령 집합(CPU 유형 + ABI 규칙) 이름입니다. 섹션 3.3. 네이티브 API 호환성을 참고하세요.
SUPPORTED_32_BIT_ABIS 네이티브 코드의 명령 집합(CPU 유형 + ABI 규칙) 이름입니다. 섹션 3.3. 네이티브 API 호환성을 참고하세요.
SUPPORTED_64_BIT_ABIS 네이티브 코드의 두 번째 명령 집합(CPU 유형 + ABI 규칙) 이름입니다. 섹션 3.3. 네이티브 API 호환성을 참고하세요.
CPU_ABI 네이티브 코드의 명령 집합(CPU 유형 + ABI 규칙) 이름입니다. 섹션 3.3. 네이티브 API 호환성을 참고하세요.
CPU_ABI2 네이티브 코드의 두 번째 명령 집합(CPU 유형 + ABI 규칙) 이름입니다. 섹션 3.3. 네이티브 API 호환성을 참고하세요.
DEVICE 하드웨어 기능의 구성과 기기의 산업 디자인을 식별하는 개발 이름 또는 코드명을 포함하며 기기 구현자가 선택한 값입니다. 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9-]+$ 정규 표현식과 일치해야 합니다(MUST). 이 기기 이름은 제품의 전체 기간 동안 변경되면 안 됩니다(MUST NOT).
FINGERPRINT 이 빌드를 고유하게 식별하는 문자열입니다. 사람이 쉽게 읽을 수 있어야 합니다(SHOULD). 다음 템플릿을 따라야 합니다(MUST).

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

예:

acme/myproduct/
    mydevice:15/LMYXX/3359:userdebug/test-keys

지문은 공백 문자를 포함하면 안 됩니다(MUST NOT). 필드의 값은 7비트 ASCII로 인코딩해야 합니다(MUST).
HARDWARE 커널 명령줄 또는 /proc의 하드웨어 이름입니다. 인간이 쉽게 읽을 수 있어야 합니다(SHOULD). 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9-]+$ 정규 표현식과 일치해야 합니다(MUST).
HOST 빌드가 기반한 호스트를 고유하게 식별하는 문자열입니다. 사람이 읽을 수 있는 형식입니다. 이 필드의 구체적인 형식에 대한 요구사항은 없습니다. 단, null 또는 빈 문자열("")이면 안 됩니다(MUST NOT).
ID 기기 구현자가 특정 릴리스를 참조하기 위해 선택한 식별자입니다. 사람이 읽을 수 있는 형식입니다. 이 필드는 android.os.Build.VERSION.INCREMENTAL과 같을 수 있지만 최종 사용자가 소프트웨어 빌드 간에 구분할 수 있을 정도로 의미 있는 값이어야 합니다(SHOULD). 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9._-]+$ 정규 표현식과 일치해야 합니다(MUST).
MANUFACTURER 제품 OEM(Original Equipment Manufacturer)의 상표명입니다. 이 필드의 구체적인 형식에 대한 요구사항은 없습니다. 단, null 또는 빈 문자열("")이면 안 됩니다(MUST NOT). 이 필드는 제품의 전체 기간 동안 변경되면 안 됩니다(MUST NOT).
SOC_MANUFACTURER 제품에 사용되는 기본 단일 칩 시스템(SOC)의 제조업체 상표명입니다. SOC 제조업체가 같은 기기는 동일한 상수 값을 사용해야 합니다. 사용할 올바른 상수는 SOC 제조업체에 문의하세요. 이 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^([0-9A-Za-z ]+) 정규 표현식과 일치해야 하지만(MUST) 공백으로 시작하거나 끝나서는 안 되고(MUST NOT) 'unknown'과 같아서도 안 됩니다(MUST NOT). 이 필드는 제품의 전체 기간 동안 변경되면 안 됩니다(MUST NOT).
SOCMODEL 제품에 사용되는 기본 단일 칩 시스템(SOC)의 모델 이름입니다. SOC 모델이 동일한 기기는 동일한 상수 값을 사용해야 합니다. 사용할 올바른 상수는 SOC 제조업체에 문의하세요. 이 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^([0-9A-Za-z ./+-]+)$ 정규 표현식과 일치해야 하지만(MUST) 공백으로 시작하거나 끝나서는 안 되고(MUST NOT) 'unknown'과 같아서도 안 됩니다(MUST NOT). 이 필드는 제품의 전체 기간 동안 변경되면 안 됩니다(MUST NOT).
MODEL 최종 사용자에게 알려진 기기 이름을 포함하며 기기 구현자가 선택한 값입니다. 이는 기기를 마케팅하고 최종 사용자에게 판매하는 데 사용되는 같은 이름이어야 합니다(SHOULD). 이 필드의 구체적인 형식에 대한 요구사항은 없습니다. 단, null 또는 빈 문자열("")이면 안 됩니다(MUST NOT). 이 필드는 제품의 전체 기간 동안 변경되어서는 안 됩니다(MUST NOT).
PRODUCT 같은 브랜드 내에서 고유해야 하는(MUST) 구체적인 제품(SKU)의 개발 이름 또는 코드명을 포함하는 기기 개발자가 선택한 값입니다. 인간이 읽을 수 있어야 하지만(MUST) 최종 사용자가 봐야 할 필요는 없습니다. 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9_-]+$ 정규 표현식과 일치해야 합니다(MUST). 이 제품 이름은 제품의 전체 기간 동안 변경되면 안 됩니다(MUST NOT).
ODMSKU 기기의 특정 구성을 추적하는 데 사용되는 SKU(재고 관리 단위)를 포함하며 기기 구현자가 선택한 값(선택사항)입니다(예: 기기 판매 시 포함되는 주변기기). 이 필드의 값은 7비트 ASCII로 인코딩해야 하며 '[0-9A-Za-z.,-])' 정규 표현식과 일치해야 합니다(MUST).
SERIAL 'UNKNOWN'을 반환해야 합니다(MUST).
TAGS 빌드를 추가로 구분하며 기기 구현자가 선택한 쉼표로 구분된 태그 목록입니다. 태그는 7비트 ASCII로 인코딩되어 ^[a-zA-Z0-9._-]+ 정규 표현식과 일치해야 하며 세 가지 일반적인 Android 플랫폼 서명 구성인 release-key, dev-key, test-key에 해당하는 값 중 하나를 취해야 합니다(MUST).
TIME 빌드 발생 시점의 타임스탬프를 나타내는 값입니다.
TYPE 빌드의 런타임 구성을 지정하며 기기 구현자가 선택한 값입니다. 이 필드는 세 가지의 일반적인 Android 런타임 구성인 user, userdebug, eng에 해당하는 값 중 하나를 취해야 합니다(MUST).
USER 빌드를 생성한 사용자 또는 자동 사용자의 이름 또는 사용자 ID입니다. 이 필드의 구체적인 형식에 대한 요구사항은 없습니다. 단, null 또는 빈 문자열("")이면 안 됩니다(MUST NOT).
SECURITY_PATCH 빌드의 보안 패치 수준을 나타내는 값입니다. 지정된 Android 공개 보안 게시판을 통해 설명되는 모든 문제에 대해 어떠한 식으로든 취약하지 않은 빌드를 나타내야 합니다(MUST). Android 공개 보안 게시판 또는 Android 보안 권고에 정의된 문자열과 일치하도록 [YYYY-MM-DD] 형식(예: '2015-11-01')을 취해야 합니다(MUST).
BASEOS 빌드의 FINGERPRINT 매개변수를 나타내는 값입니다. Android 공개 보안 게시판에서 제공되는 패치의 경우를 제외하고는 이 빌드와 동일합니다. 올바른 값을 보고해야 하며, 이러한 빌드가 존재하지 않는 경우 빈 문자열("")을 보고해야 합니다(MUST).
BOOTLOADER 기기에 사용되는 특정 내부 부트로더 버전을 식별하며 기기 구현자가 선택한 값입니다. 인간이 읽을 수 있는 형식입니다. 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9.-]+$ 정규 표현식과 일치해야 합니다(MUST).
getRadioVersion() 기기에 사용되는 특정 내부 라디오/모뎀 버전을 식별하며 기기 구현자가 선택한 값(사람이 읽을 수 있는 형식)이거나 이러한 값을 반환해야 합니다(MUST). 내부 라디오/모뎀이 없는 기기는 NULL을 반환해야 합니다(MUST). 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9._-,]+$ 정규 표현식과 일치해야 합니다(MUST).
getSerial() 하드웨어 일련번호이거나 이러한 일련번호를 반환해야 합니다(MUST). 일련번호는 MODEL과 MANUFACTURER가 같은 모든 기기에 걸쳐 제공되어야 하며 고유해야 합니다(MUST). 필드의 값은 7비트 ASCII로 인코딩해야 하며 ^[a-zA-Z0-9]+$ 정규 표현식과 일치해야 합니다(MUST).

3.2.3. 인텐트 호환성

3.2.3.1. 공통 애플리케이션 인텐트

Android 인텐트는 애플리케이션 구성요소가 다른 Android 구성요소의 기능을 요청할 수 있게 해줍니다. Android 업스트림 프로젝트에는 애플리케이션 목록이 포함되어 있습니다. 이 목록은 일반 작업 실행을 위한 여러 인텐트 패턴을 구현합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 여기에 나열된 다음 애플리케이션 인텐트에서 정의한 모든 공개 인텐트 필터 패턴에서 인텐트 핸들러가 포함된 애플리케이션 또는 서비스 구성요소를 하나 이상 미리 로드하고 fulfillment를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 즉, SDK에 설명된 이러한 공통 애플리케이션 인텐트에 대한 개발자의 기대를 충족해야 합니다.

각 기기 유형에 대한 필수 애플리케이션 인텐트는 섹션 2를 참고하세요.

3.2.3.2. 인텐트 확인

  • [C-0-1] Android는 확장 가능한 플랫폼이므로 기기 구현자는 섹션 3.2.3.1에서 참조되는 각 인텐트 패턴이 서드 파티 애플리케이션에 의해 재정의되도록 허용해야 합니다(MUST). 설정은 예외입니다. 업스트림 Android 오픈소스 구현은 이를 기본으로 허용합니다.

  • [C-0-2] 기기 구현자는 시스템 애플리케이션의 인텐트 패턴 사용에 대한 특수 권한을 추가하거나 서드 파티 애플리케이션이 이러한 패턴에 바인딩되거나 제어 권한을 취하는 것을 막으면 안 됩니다(MUST NOT). 이러한 금지사항으로는 구체적으로 같은 인텐트 패턴을 처리하는 여러 애플리케이션 간에 사용자가 선택할 수 있게 해주는 '선택기' 사용자 인터페이스를 사용 중지하는 경우가 있으며, 이에 국한되지는 않습니다.

  • [C-0-3] 기기 구현은 사용자가 인텐트의 기본 활동을 수정할 수 있는 사용자 인터페이스를 제공해야 합니다(MUST).

  • 하지만 기기 구현은 기본 활동이 데이터 URI에 대한 더 구체적인 속성을 제공하는 경우 특정 URI 패턴(e.g. http://play.google.com)의 기본 활동을 제공할 수 있습니다(MAY). 예를 들어 데이터 URI 'http://www.android.com'을 지정하는 인텐트 필터 패턴은 'http://'에 대한 브라우저의 핵심 인텐트 패턴보다 훨씬 구체적입니다.

Android에는 서드 파티 앱이 특정 유형의 웹 URI 인텐트에 대한 신뢰할 수 있는 기본 앱 연결 동작을 선언할 수 있게 해주는 메커니즘도 포함되어 있습니다. 이러한 신뢰할 수 있는 권한이 앱의 인텐트 필터 패턴에서 선언되면 기기 구현은 다음을 충족해야 합니다.

  • [C-0-4] 업스트림 Android 오픈소스 프로젝트의 패키지 관리자가 구현한 디지털 애셋 링크 사양에 정의된 인증 단계를 실행하여 모든 인텐트 필터에 관한 인증을 시도해야 합니다(MUST).
  • [C-0-5] 애플리케이션 설치 도중 인텐트 필터에 관한 인증을 시도하고 정상적으로 인증된 모든 URI 인텐트 필터를 URI의 앱 핸들러로 설정해야 합니다(MUST).
  • URI 인텐트 필터가 정상적으로 인증되었지만 다른 후보 URI 필터는 인증에 실패한 경우 특정 URI 인텐트 필터를 URI의 기본 앱 핸들러로 설정할 수 있습니다(MAY). 이를 실행하는 기기 구현은 설정 메뉴에서 적절한 URI별 패턴 재정의를 사용자에게 제공해야 합니다(MUST).
  • 다음과 같이 설정에서 앱별 앱 링크 제어 기능을 사용자에게 제공해야 합니다(MUST).
    • [C-0-6] 사용자는 앱의 기본 앱 링크 동작 전체를 항상 열기, 항상 묻기 또는 열지 않음으로 재정의할 수 있어야 합니다(MUST). 이는 모든 후보 URI 인텐트 필터에 동일하게 적용되어야 합니다.
    • [C-0-7] 사용자는 후보 URI 인텐트 필터 목록을 확인할 수 있어야 합니다(MUST).
    • 기기 구현은 사용자가 인텐트 필터별 기준으로 정상적으로 인증된 특정 후보 URI 인텐트 필터를 재정의할 수 있도록 기능을 제공할 수 있습니다(MAY).
    • [C-0-8] 기기 구현이 일부 후보 URI 인텐트 필터는 인증에 성공하지만 일부는 실패할 수 있도록 허용하는 경우, 기기 구현은 사용자가 특정 후보 URI 인텐트 필터를 보고 재정의할 수 있도록 기능을 제공해야 합니다(MUST).
3.2.3.3. 인텐트 네임스페이스
  • [C-0-1] 기기 구현은 ACTION, CATEGORY 또는 android.나 com.android. 네임스페이스의 다른 키 문자열을 사용하여 새 인텐트 또는 브로드캐스트 인텐트 패턴을 적용하는 어떠한 Android 구성요소도 포함하면 안 됩니다(MUST NOT).
  • [C-0-2] 기기 구현자는 ACTION, CATEGORY 또는 다른 조직에 속하는 패키지 공간의 다른 키 문자열을 사용하여 새 인텐트 또는 브로드캐스트 인텐트 패턴을 적용하는 어떠한 Android 구성요소도 포함하면 안 됩니다(MUST NOT).
  • [C-0-3] 기기 구현자는 섹션 3.2.3.1에 나열된 인텐트 패턴을 변경하거나 확장하면 안 됩니다(MUST NOT).
  • 기기 구현은 네임스페이스를 명확히 사용하고 자체 조직에 확실하게 연결된 인텐트 패턴을 포함할 수 있습니다(MAY). 이러한 금지 내용은 섹션 3.6에서 자바 언어 클래스에 대해 명시된 내용과 비슷합니다.
3.2.3.4. 인텐트 브로드캐스트

서드 파티 애플리케이션은 특정 인텐트를 브로드캐스트하여 하드웨어 또는 소프트웨어 환경의 변화를 전달받기 위해 플랫폼에 의존합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] SDK 문서에 설명된 적절한 시스템 이벤트에 대한 응답으로 여기에 나열된 공개 브로드캐스트 인텐트를 브로드캐스트해야 합니다(MUST). 이 요구사항은 섹션 3.5와 충돌하지 않으며, 이는 백그라운드 애플리케이션 제한사항을 SDK 문서에서도 설명하기 때문입니다. 또한 특정 브로드캐스트 인텐트는 하드웨어 지원을 조건으로 합니다. 기기가 필요한 하드웨어를 지원하는 경우 인텐트를 브로드캐스트하고 SDK 문서와 함께 동작을 인라인으로 제공해야 합니다(MUST).
3.2.3.5. 조건부 애플리케이션 인텐트

Android에는 사용자가 홈 화면이나 SMS와 같은 기본 애플리케이션을 쉽게 선택할 수 있게 해주는 설정이 포함되어 있습니다.

해당하는 경우, 기기 구현은 유사한 설정 메뉴를 제공해야 하며(MUST) 아래의 SDK 문서에서 설명된 인텐트 필터 패턴 및 API 메서드와 호환되어야 합니다.

android.software.home_screen을 보고하는 기기 구현은 다음을 충족해야 합니다.

android.hardware.telephony.calling을 보고하는 기기 구현은 다음을 충족해야 합니다.

android.hardware.nfc.hce을 보고하는 기기 구현은 다음을 충족해야 합니다.

android.hardware.nfc를 보고하는 기기 구현은 다음을 충족해야 합니다.

android.hardware.bluetooth를 보고하는 기기 구현은 다음을 충족해야 합니다.

DND 기능을 지원하는 기기 구현은 다음을 지원해야 합니다.

  • [C-6-1] 사용자가 DND 정책 구성 앱 액세스를 부여하거나 거부할 수 있는 활동으로(MUST) UI_MODE_TYPE_NORMAL을 포함하는 구현인 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 인텐트에 응답하는 활동을 구현해야 합니다(MUST).

사용자가 기기에 서드 파티 입력 방식을 사용하도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-7-1] android.settings.INPUT_METHOD_SETTINGS 인텐트에 응답하도록 서드 파티 입력 방식을 추가하고 구성할 수 있도록 사용자가 액세스 가능한 메커니즘을 제공해야 합니다(MUST).

서드 파티 접근성 서비스를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-8-1] android.settings.ACCESSIBILITY_SETTINGS 인텐트를 적용하여 미리 로드된 접근성 서비스와 함께 서드 파티 접근성 서비스를 사용 설정 및 중지할 수 있는 사용자가 액세스 가능한 메커니즘을 제공해야 합니다(MUST).

Wi-Fi 간편 연결 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

데이터 절약 모드를 제공하는 기기 구현은 다음을 충족해야 합니다. * [C-10-1] 설정의 사용자 인터페이스에서 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 인텐트를 처리하는 사용자 인터페이스를 제공하여 사용자가 목록에 애플리케이션을 추가하거나 제거할 수 있게 해야 합니다(MUST).

데이터 절약 모드를 제공하지 않는 기기 구현은 다음을 충족해야 합니다.

android.hardware.camera.any를 통해 카메라 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

android.software.device_admin을 보고하는 기기 구현은 다음을 충족해야 합니다.

android.software.autofill 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

사전 설치된 앱을 포함하고 있거나 서드 파티 앱이 사용 통계에 액세스 가능하도록 허용하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-2] android.permission.PACKAGE_USAGE_STATS 권한을 선언하는 앱의 android.settings.ACTION_USAGE_ACCESS_SETTINGS 인텐트에 응답할 때 사용 통계 액세스를 부여하거나 취소하도록 사용자가 액세스할 수 있는 메커니즘을 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

사전 설치된 앱을 비롯한 모든 앱이 사용 통계에 액세스하지 못하게 하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-15-1] android.settings.ACTION_USAGE_ACCESS_SETTINGS 인텐트 패턴을 처리하는 활동을 계속 보유해야 하지만 이를 노옵(no-op)으로 구현해야 합니다(MUST). 즉, 사용자가 액세스를 거부당할 때와 같은 동작을 취해야 합니다(MUST).

설정에서 AutofillService_passwordsActivity로 지정한 활동의 링크 또는 유사한 메커니즘을 통한 사용자 비밀번호 링크를 표시하는 기기 구현은 다음을 충족해야 합니다.

  • [C-16-1] 설치된 모든 자동 완성 서비스에 관해 이러한 링크를 표시해야 합니다(MUST).

VoiceInteractionService를 지원하고 이 API를 사용하는 애플리케이션을 한 번에 1개 이상 설치하는 기기는 다음을 충족해야 합니다.

android.hardware.audio.output 기능을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-3] android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA 및 android.speech.tts.engine.GET_SAMPLE_TEXT 인텐트를 적용하고, 여기 SDK에 설명된 것처럼 이러한 인텐트를 처리하는 활동을 보유할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Android에는 이전에 Dreams로 불렸던 대화형 화면 보호기 지원 기능이 포함되어 있습니다. 화면 보호기를 사용하면 전원에 연결된 기기가 유휴 상태이거나 탁상용 도크에 도킹된 경우 애플리케이션과 상호작용할 수 있습니다. 기기 구현은 다음을 충족해야 합니다.

  • 화면 보호기에 대한 지원을 포함하고 사용자가 android.settings.DREAM_SETTINGS 인텐트에 대한 응답으로 화면 보호기를 구성할 수 있도록 설정 옵션을 제공해야 합니다(SHOULD).

android.hardware.nfc.uicc 또는 android.hardware.nfc.ese를 보고하는 기기 구현은 다음을 충족해야 합니다.

3.2.4. 보조/다중 디스플레이에서의 활동

2개 이상의 디스플레이에서 정상적인 Android 활동을 실행하도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.software.activities_on_secondary_displays 기능 플래그를 설정해야 합니다(MUST).
  • [C-1-2] 기본 디스플레이에서 실행 중인 활동과 유사한 API 호환성을 보장해야 합니다(MUST).
  • [C-1-3] ActivityOptions.setLaunchDisplayId() API를 통해 타겟 디스플레이를 지정하지 않은 상태에서 새 활동이 실행된 경우 실행의 주체가 된 활동과 동일한 디스플레이에 새 활동을 랜딩시켜야 합니다(MUST).
  • [C-1-4] Display.FLAG_PRIVATE 플래그를 포함하는 디스플레이가 제거되면 모든 활동을 삭제해야 합니다(MUST).
  • [C-1-5] 보안 잠금 화면으로 기기가 잠기면 모든 화면의 콘텐츠를 안전하게 숨겨야 합니다(MUST). 단, 앱에서 Activity#setShowWhenLocked() API를 사용하여 잠금 화면 상단을 표시하기로 선택한 경우는 예외입니다.
  • 활동이 보조 디스플레이에서 실행된 경우 표시, 올바른 작동과 호환성 유지가 가능하도록 디스플레이에 해당하는 android.content.res.Configuration을 보유해야 합니다(SHOULD).

기기 구현이 보조 디스플레이에서 정상적인 Android 활동을 실행하도록 허용하고 보조 디스플레이에 android.view.Display.FLAG_PRIVATE 플래그가 있는 경우 다음을 충족해야 합니다.

  • [C-3-1] 디스플레이, 시스템, 그리고 이미 디스플레이에 있는 활동의 소유자만 실행이 가능해야 합니다. 누구나 android.view.Display.FLAG_PUBLIC 플래그가 있는 디스플레이를 실행할 수 있습니다.

3.3. 네이티브 API 호환성

네이티브 코드 호환성은 쉽지 않은 문제입니다. 따라서 기기 구현자는 다음을 충족해야 합니다.

  • [C-SR-1] 아래에 나열된 업스트림 Android 오픈소스 프로젝트의 라이브러리 구현을 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3.3.1. Application Binary Interfaces

관리되는 Dalvik 바이트코드는 적절한 기기 하드웨어 아키텍처에 대해 컴파일된 ELF .so 파일로 애플리케이션 .apk 파일에서 제공되는 네이티브 코드로 호출될 수 있습니다. 네이티브 코드는 기본 프로세스 기술의 영향을 많이 받습니다. 따라서 Android는 Android NDK에 Application Binary Interface(ABI) 수를 정의합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 1개 이상의 정의된 Android NDK ABI와 호환되어야 합니다(MUST).
  • [C-0-2] 표준 자바 네이티브 인터페이스(JNI) 의미 체계를 사용하여 네이티브 코드를 호출하도록 관리형 환경에서 실행되는 코드를 지원해야 합니다(MUST).
  • [C-0-3] 소스 호환(헤더 호환) 및 바이너리 호환(ABI의 경우)이 되어야 하며 아래 목록의 각 필수 라이브러리를 포함해야 합니다(MUST).
  • [C-0-5] android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, android.os.Build.SUPPORTED_64_BIT_ABIS 매개변수를 통해 기기에서 지원하는 네이티브 Application Binary Interface(ABI)를 정확하게 보고해야 합니다(MUST). 각 항목은 가장 높은 선호도에서 가장 낮은 선호도 순으로 정렬된, 쉼표로 구분된 ABI 목록입니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-0-6](2024년 2월 26일 미리보기)

  • [C-0-6] 위의 매개변수를 통해 다음 ABI 목록의 하위 집합을 보고해야 하며(MUST) 목록에 없는 ABI는 보고하면 안 됩니다(MUST NOT).

새로운 요구사항 종료

  • [C-0-7] 네이티브 API를 제공하는 다음과 같은 모든 라이브러리를 네이티브 코드를 포함하는 앱에 제공해야 합니다.

    • libaaudio.so(AAudio 네이티브 오디오 지원)
    • libamidi.so(네이티브 MIDI 지원, 기능 android.software.midi가 섹션 5.9의 설명처럼 수취된 경우)
    • libandroid.so(네이티브 Android 활동 지원)
    • libc(C 라이브러리)
    • libcamera2ndk.so
    • libdl(동적 링커)
    • libEGL.so(기본 OpenGL Surface 관리)
    • libGLESv1_CM.so(OpenGL ES 1.x)
    • libGLESv2.so(OpenGL ES 2.0)
    • libGLESv3.so(OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog(Android 로깅)
    • libmediandk.so(네이티브 미디어 API 지원)
    • libm(수학 라이브러리)
    • libneuralnetworks.so(Neural Networks API)
    • libOpenMAXAL.so(OpenMAX AL 1.0.1 지원)
    • libOpenSLES.so(OpenSL ES 1.0.1 오디오 지원)
    • libRS.so
    • libstdc++(C++ 최소 지원)
    • libvulkan.so(Vulkan)
    • libz(Zlib 압축)
    • JNI 인터페이스

  • [C-0-8] 위에 나열된 네이티브 라이브러리에 공개 함수를 추가하거나 제거하면 안 됩니다(MUST NOT).

  • [C-0-9] /vendor/etc/public.libraries.txt에서 서드 파티 앱에 직접적으로 노출되는 추가적인 비 AOSP 라이브러리를 나열해야 합니다(MUST).

  • [C-0-10] AOSP에서 시스템 라이브러리로 구현 및 제공되는 다른 어떠한 네이티브 라이브러리도 API 수준 24 이상을 타겟팅하는 예약 중인 서드 파티 앱에 노출시키면 안 됩니다(MUST NOT).

  • [C-0-11] NDK에 정의된 모든 OpenGL ES 3.1 및 Android 확장 팩 함수 기호를 libGLESv3.so 라이브러리를 통해 내보내야 합니다(MUST). 모든 기호가 있어야 하지만(MUST) 섹션 7.1.4.1에서는 해당하는 각 함수의 전체 구현이 예상되는 시기와 관련된 요구사항을 상세히 설명합니다.

  • [C-0-12] 코어 Vulkan 1.1 함수 기호의 함수 기호는 물론 VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, VK_KHR_get_physical_device_properties2 확장자까지 libvulkan.so 라이브러리를 통해 내보내야 합니다(MUST). 모든 기호가 있어야 하지만(MUST) 섹션 7.1.4.2에서는 해당하는 각 함수의 전체 구현이 예상되는 시기와 관련된 요구사항을 상세히 설명합니다.

  • 업스트림 Android 오픈소스 프로젝트에서 제공되는 소스 코드와 헤더 파일을 사용하여 빌드되어야 합니다(SHOULD).

Android 향후 버전에는 추가 ABI 지원이 도입될 수 있습니다.

3.3.2. 32비트 ARM 네이티브 코드 호환성

armeabi ABI 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] armeabi-v7a도 지원해야 하며 지원 내용을 보고해야 합니다(MUST). armeabi는 기존 앱과의 하위 호환성을 위해서만 사용되기 때문입니다.

이 ABI를 사용하는 앱과 관련하여 armeabi-v7a ABI 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음 행을 /proc/cpuinfo에 포함해야 하며(MUST) 다른 ABI에서 읽는 경우에도 같은 기기의 값을 변경하면 안 됩니다(SHOULD NOT).

    • Features:는 기기에서 지원하는 모든 선택적 ARMv7 CPU 기능 목록 앞에 표시됩니다.
    • CPU architecture:는 기기에서 지원하는 가장 높은 ARM 아키텍처를 설명하는 정수 앞에 표시됩니다(예: ARMv8 기기의 경우 '8').

  • [C-2-2] ABI가 네이티브 CPU 지원 또는 소프트웨어 에뮬레이션을 통해 ARMv8 아키텍처에 구현된 경우에도 항상 다음과 같은 작업의 가용성을 유지해야 합니다(MUST).

    • SWP 및 SWPB 명령어
    • CP15ISB, CP15DSB 및 CP15DMB 배리어 연산

  • [C-2-3] 고급 SIMD(NEON) Extension 지원을 포함해야 합니다(MUST).

3.4. 웹 호환성

3.4.1. WebView 호환성

android.webkit.Webview API의 온전한 구현을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.software.webview를 보고해야 합니다(MUST).
  • [C-1-2] android.webkit.WebView API의 Android 15 브랜치에 업스트림 Android 오픈소스 프로젝트의 Chromium 프로젝트 빌드를 사용해야 합니다(MUST).

  • [C-1-3] WebView로 보고된 사용자 에이전트 문자열이 다음 형식이어야 합니다(MUST).

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, Gecko 등) 버전/4.0 $(CHROMIUM_VER) 모바일 Safari/537.36

    • $(VERSION) 문자열의 값이 android.os.Build.VERSION.RELEASE의 값과 같아야 합니다.
    • $(MODEL) 문자열은 비워둘 있지만(MAY) 비지 않은 경우에는 android.os.Build.MODEL과 같은 값을 취해야 합니다(MUST).
    • 'Build/$(BUILD)'는 생략될 수 있지만(MAY) 있는 경우에는 $(BUILD) 문자열이 android.os.Build.ID와 같은 값이어야 합니다(MUST).
    • $(CHROMIUM_VER) 문자 열의 값은 업스트림 Android 오픈소스 프로젝트의 Chromium 버전이어야 합니다(MUST).
    • 기기 구현은 사용자 에이전트 문자열에서 모바일을 생략할 수 있습니다(MAY).

  • WebView 구성요소는 최대한 많은 수의 HTML5 기능 지원을 포함해야 하며(SHOULD) 기능을 지원하는 경우 HTML5 사양을 준수해야 합니다(SHOULD).

  • [C-1-4] WebView를 인스턴스화하는 애플리케이션과 구분되는 프로세스의 제공된 콘텐츠나 원격 URL 콘텐츠를 렌더링해야 합니다(MUST). 구체적으로 별도의 렌더기 프로세스는 낮은 권한을 보유하고 별도의 사용자 ID로 실행되어야 하며 앱의 데이터 디렉터리에 액세스할 수 없고 직접적으로 네트워크에 액세스할 수 없으며 바인더를 통한 최소 요구 시스템 서비스에 대한 액세스만 보유해야 합니다(MUST). WebView의 AOSP 구현은 이러한 요구사항을 충족합니다.

32비트이거나 기능 플래그 android.hardware.ram.low를 선언하는 기기 구현은 C-1-3에서 제외됩니다.

3.4.2. 브라우저 호환성

일반 웹 브라우징을 위한 독립형 브라우저 애플리케이션을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] HTML5에 연결된 이러한 각 API를 지원해야 합니다(MUST).
  • [C-1-2] HTML5/W3C webstorage API를 지원해야 하며(MUST) HTML5/W3C IndexedDB API를 지원해야 합니다(SHOULD). 웹 개발 표준화 기관이 webstorage보다는 IndexedDB를 선호하기 시작한 만큼 IndexedDB는 향후 Android 버전의 필수 구성요소가 될 것으로 예상됩니다.
  • 독립형 브라우저 애플리케이션에 사용자 에이전트 문자열을 전달할 수 있습니다(MAY).
  • 업스트림 WebKit 브라우저 애플리케이션 또는 서드 파티의 대체 애플리케이션 중 무엇을 기반으로 삼더라도 독립형 브라우저 애플리케이션에 최대한 많은 HTML5 지원을 구현해야 합니다(SHOULD).

하지만 독립형 브라우저 애플리케이션을 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 섹션 3.2.3.1의 설명처럼 계속해서 공개 인텐트 패턴을 지원해야 합니다(MUST).

3.5. API 동작 호환성

기기 구현은 다음을 충족해야 합니다.

  • [C-0-9] 섹션 3.5.1의 설명처럼 제한되지 않는 이상 API 동작 호환성이 설치된 모든 앱에 적용되도록 해야 합니다(MUST).
  • [C-0-10] API 동작 호환성이 기기 구현자가 선택한 앱에 대해서만 보장되도록 하는 허용 목록 추가 접근 방식을 구현하면 안 됩니다(MUST NOT).

각 API 유형(관리형, 소프트, 네이티브 및 웹)의 동작은 업스트림 Android 오픈소스 프로젝트의 기본 구현과 일치해야 합니다. 몇 가지 구체적인 호환성 영역은 다음과 같습니다.

  • [C-0-1] 기기가 표준 인텐트의 동작이나 의미 체계를 변경하면 안 됩니다(MUST NOT).
  • [C-0-2] 기기가 특정 유형의 시스템 구성요소(예: 서비스, 활동, 콘텐츠 제공업체 등)의 수명 주기 또는 수명 주기 의미 체계를 변경하면 안 됩니다(MUST NOT).
  • [C-0-3] 기기가 표준 권한의 의미 체계를 변경하면 안 됩니다(MUST NOT).
  • 기기가 백그라운드 애플리케이션에 적용된 제한사항을 변경하면 안 됩니다(MUST NOT). 백그라운드 앱은 구체적으로 다음을 충족해야 합니다.
    • [C-0-4] GnssMeasurement 및 GnssNavigationMessage의 출력 수신을 위해 앱에 의해 등록되는 콜백에 대한 실행을 중단해야 합니다(MUST).
    • [C-0-5] LocationManager API 클래스 또는 WifiManager.startScan() 메서드를 통해 앱에 제공되는 업데이트 빈도를 비율 제한해야 합니다(MUST).
    • [C-0-6] API 수준 25 이상을 타겟팅하는 앱은 앱 매니페스트에서 표준 Android 인텐트의 암시적 브로드캐스트에 대해 broadcast receiver를 등록하도록 허용하면 안 됩니다(MUST NOT). 단, 브로드캐스트 인텐트가 "signature" 또는 "signatureOrSystem" protectionLevel 권한을 요구하거나 예외 목록에 있는 경우는 예외입니다.
    • [C-0-7] API 수준 25 이상을 타겟팅하는 앱은 앱이 서비스의 stopSelf() 메서드를 호출한 경우처럼 앱의 백그라운드 서비스를 중지해야 합니다(MUST). 단, 사용자에게 표시되는 작업을 처리하도록 앱이 임시 허용 목록에 배치된 경우는 예외입니다.
    • [C-0-8] API 수준 25 이상을 타겟팅하는 앱은 앱에서 유지하고 있는 wakelock을 해제해야 합니다(MUST).
  • [C-0-11] 앱이 insertProviderAt() 또는 removeProvider()를 통해 목록을 수정하지 않은 이상 기기는 다음과 같은 보안 제공업체를 Security.getProviders() 메서드의 최초 7개 배열 값으로 반환해야 하며(MUST), 이때 Provider.getName()에 의해 반환된 이름과 순서 및 클래스를 준수해야 합니다. 기기는 아래의 지정된 제공업체 목록 이후에 추가 제공업체를 반환할 수 있습니다(MAY).
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

위의 목록은 전체 목록이 아닙니다. 호환성 테스트 모음(CTS)은 동작 호환성과 관련하여 플랫폼의 전부가 아닌 중요한 부분을 테스트합니다. 구현자는 Android 오픈소스 프로젝트와의 동작 호환성을 보장해야 합니다. 따라서 기기 구현자는 가능한 경우 시스템의 중요한 일부를 다시 구현하는 대신 Android 오픈소스 프로젝트를 통해 제공되는 소스 코드를 사용해야 합니다(SHOULD).

3.5.1. 애플리케이션 제한사항

앱을 제한하는 독점 메커니즘을 구현하고(예: SDK에 설명된 API 동작을 변경하거나 제한) 이 메커니즘이 제한된 앱 대기 버킷보다 더 제한적인 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 사용자가 제한된 앱 목록을 확인할 수 있도록 허용해야 합니다(MUST).
  • [C-1-2] 각 앱에서 이러한 모든 독점 제한을 사용 설정/사용 중지하는 사용자 어포던스를 제공해야 합니다(MUST).

  • [C-1-3] 시스템 상태 동작 불량의 증거 없이 이러한 독점 제한을 자동으로 적용하면 안 됩니다(MUST NOT). 하지만 장기간 wakelock, 오래 실행되는 서비스 및 기타 기준과 같은 시스템 상태 동작 불량이 감지되는 경우에는 앱에 제한을 적용할 수 있습니다(MAY). 기준은 기기 구현자가 결정할 수 있지만(MAY) 시스템 상태에 대한 앱의 영향과 관련이 있어야 합니다(MUST). 앱의 시장 인지도 부족과 같이 시스템 상태와 부분적으로만 관련이 있는 기준은 기준으로 사용하면 안 됩니다(MUST NOT).

  • [C-1-4] 사용자가 앱 제한을 수동으로 사용 중지한 경우 이러한 독점 제한을 앱에 자동으로 적용하면 안 되며(MUST NOT), 사용자에게 이러한 독점 제한을 적용하도록 권장할 수는 있습니다(MAY).

  • [C-1-5] 이러한 독점 제한이 앱에 자동으로 적용된 경우 사용자에게 알려야 합니다(MUST). 이러한 정보는 독점 제한이 적용되기 전 24시간 이내에 제공되어야 합니다(MUST).

  • [C-1-6] 앱의 모든 API 호출에 대해 ActivityManager.isBackgroundRestricted() 메서드는 true를 반환해야 합니다.

  • [C-1-7] 사용자가 명시적으로 사용하는 최상위 포그라운드 앱을 제한하면 안 됩니다(MUST NOT).

  • [C-1-8] 사용자가 앱을 명시적으로 사용하기 시작할 때마다 앱의 이러한 독점 제한을 정지하여 최상위 포그라운드 애플리케이션이 되도록 해야 합니다(MUST).

  • [C-1-10] 독점 제한이 적용되는 방식을 설명하는 공개적이고 명확한 문서 또는 웹사이트를 제공해야 합니다(MUST). 이 문서나 웹사이트는 Android SDK 문서에서 연결할 수 있어야 하며(MUST) 다음을 포함해야 합니다(MUST).

    • 독점 제한의 트리거 조건
    • 앱을 제한할 수 있는 사항 및 방법
    • 이러한 제한에서 앱을 제외할 수 있는 방법
    • 사용자가 설치할 수 있는 앱에 이러한 예외를 지원하는 경우 앱이 독점 제한으로부터 예외를 요청하는 방법

앱이 기기에 사전 설치되어 있고 사용자가 30일 넘게 명시적으로 사용한 적이 없는 경우 [C-1-3], [C-1-5]는 제외됩니다.

AOSP에서 구현되는 앱 제한사항을 확장하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 이 문서에 설명된 구현을 따라야 합니다(MUST).

3.5.2. 애플리케이션 최대 절전 모드

AOSP에 포함되거나 AOSP에 포함된 기능을 확장하는 앱 최대 절전 모드를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] [C-1-6]과 [C-1-3]을 제외하고 섹션 3.5.1의 모든 요구사항을 충족해야 합니다(MUST).
  • [C-1-2] 사용자가 일정 기간 앱을 사용하지 않았다는 증거가 있을 때만 사용자에 관한 제한사항을 앱에 적용합니다(MUST). 이 기간은 1개월 이상으로 지정하는 것을 적극 권장합니다(STRONGLY RECOMMENDED). 사용량은 UsageStats#getLastTimeVisible() API를 통한 명시적인 사용자 상호작용 또는 새 API인 UsageStats#getLastTimeAnyComponentUsed()로 추적되어 앱이 강제 종료 상태에서 벗어나도록 하는 작업(예: 서비스 결합, 콘텐츠 제공자, 결합, 명시적 브로드캐스트 등)으로 정의되어야 합니다(MUST).
  • [C-1-3] 패키지가 특정 기간 동안 모든 사용자에게 사용되지 않은 증거가 있는 경우에만 모든 기기 사용자에게 영향을 주는 제한사항을 적용해야 합니다(MUST). 이 기간은 1개월 이상으로 지정하는 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-4] 활동 인텐트, 서비스 결합, 콘텐츠 제공자 요청 또는 명시적 브로드캐스트에 응답할 수 없는 앱을 렌더링하면 안 됩니다(MUST NOT).

AOSP의 앱 최대 절전 모드는 위의 요구사항을 충족합니다.

3.6. API 네임스페이스

Android는 자바 프로그래밍 언어로 정의된 패키지 및 클래스 네임스페이스 규칙을 따릅니다. 서드 파티 애플리케이션과의 호환성을 보장하고 싶은 기기 구현자는 이러한 패키지 네임스페이스에 금지된 수정사항(아래 참고)을 적용하면 안 됩니다(MUST NOT).

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

즉, 다음을 충족해야 합니다.

  • [C-0-1] 메서드 또는 클래스 서명을 변경하거나 클래스 또는 클래스 필드를 제거하는 방식으로 Android 플랫폼의 공개 노출된 API를 수정하면 안 됩니다(MUST NOT).
  • [C-0-2] 상기 네임스페이스의 API에 공개 노출된 요소(클래스나 인터페이스 또는 기존 클래스나 인터페이스에 대한 메서드 등), 테스트 또는 시스템 API를 추가하면 안 됩니다(MUST NOT). '공개 노출된 요소'는 업스트림 Android 소스 코드에서 사용되는 '@hide' 마커로 표시되지 않은 모든 구성입니다.

기기 구현자는 API의 기본 구현을 수정할 수 있지만(MAY) 이러한 수정사항은 다음을 충족해야 합니다.

  • [C-0-3] 공개 노출된 모든 API의 명시된 동작과 자바 언어 서명에 영향을 미치면 안 됩니다(MUST NOT).
  • [C-0-4] 개발자에게 알리거나 달리 노출되면 안 됩니다(MUST NOT).

단, 기기 구현자는 표준 Android 네임스페이스 외부에 맞춤 API를 추가할 수 있지만(MAY) 맞춤 API가 다음을 충족해야 합니다.

  • [C-0-5] 다른 조직의 소유이거나 다른 조직과 관련이 있는 네임스페이스에 있으면 안 됩니다(MUST NOT). 예를 들어 기기 구현자는 API를 com.google.* 또는 유사 네임스페이스에 추가하면 안 됩니다(MUST NOT). 이는 Google만 가능합니다. 마찬가지로 Google은 API를 다른 회사의 네임스페이스에 추가하면 안 됩니다(MUST NOT).
  • [C-0-6] <uses-library> 메커니즘을 통해 명시적으로 API를 사용하는 앱만 이러한 API의 메모리 사용량 증가에 따른 영향을 받도록 Android 공유 라이브러리에 패키징해야 합니다(MUST).

기기 구현자는 NDK API 외부의 네이티브 언어로 맞춤 API를 추가할 수 있지만(MAY), 맞춤 API는 다음을 충족해야 합니다.

  • [C-1-1] 여기에 설명된 것처럼 NDK 라이브러리 또는 다른 조직이 소유한 라이브러리에 있으면 안 됩니다(MUST NOT).

기기 구현자가 위의 패키지 네임스페이스 중 하나의 개선을 제안하는 경우(예: 기존 API에 유용한 새 기능을 추가하거나 새 API를 추가) 구현자는 source.android.com을 방문하여 해당 사이트의 정보에 따라 변경사항 및 코드를 기여하기 위한 프로세스를 시작해야 합니다(SHOULD).

위의 제한사항은 자바 프로그래밍 언어로 API 이름을 지정하기 위한 표준 규칙과 일치합니다. 이 섹션은 단순히 이러한 규칙을 강조하고 이 호환성 정의에 포함하여 구속력을 지니도록 하는 데 목적이 있습니다.

3.7. 런타임 호환성

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 전체 Dalvik Executable(DEX) 형식과 Dalvik 바이트 코드 사양 및 의미 체계를 지원해야 합니다(MUST).

  • [C-0-2] 업스트림 Android 플랫폼에 따라 다음 표에 명시된 대로 메모리를 할당하도록 Dalvik 런타임을 구성해야 합니다(MUST). 화면 크기 및 화면 밀도 정의는 섹션 7.1.1을 참고하세요.

  • Dalvik Executable 형식의 참조 업스트림 구현인 Android RunTime(ART)과 패키지 관리 시스템의 참조 구현을 사용해야 합니다(SHOULD).

  • 다양한 실행 모드와 타겟 아키텍처에서 퍼즈 테스트를 실행하여 런타임의 안정성을 확인해야 합니다(SHOULD). Android 오픈소스 프로젝트 웹사이트에서 JFuzz 및 DexFuzz를 참고하세요.

아래에 명시된 메모리 값은 최솟값으로 간주되며, 기기 구현은 애플리케이션별로 추가 메모리를 할당할 수 있습니다(MAY).

화면 레이아웃 화면 밀도 최소 애플리케이션 메모리
Android 시계 120dpi(ldpi) 32MB
140dpi(140dpi)
160dpi(mdpi)
180dpi(180dpi)
200dpi(200dpi)
213dpi(tvdpi)
220dpi(220dpi) 36MB
240dpi(hdpi)
280dpi(280dpi)
320dpi(xhdpi) 48MB
360dpi(360dpi)
400dpi(400dpi) 56MB
420dpi(420dpi) 64MB
480dpi(xxhdpi) 88MB
560dpi(560dpi) 112MB
640dpi(xxxhdpi) 154MB
소형/일반 120dpi(ldpi) 32MB
140dpi(140dpi)
160dpi(mdpi)
180dpi(180dpi) 48MB
200dpi(200dpi)
213dpi(tvdpi)
220dpi(220dpi)
240dpi(hdpi)
280dpi(280dpi)
320dpi(xhdpi) 80MB
360dpi(360dpi)
400dpi(400dpi) 96MB
420dpi(420dpi) 112MB
480dpi(xxhdpi) 128MB
560dpi(560dpi) 192MB
640dpi(xxxhdpi) 256MB
대형 120dpi(ldpi) 32MB
140dpi(140dpi) 48MB
160dpi(mdpi)
180dpi(180dpi) 80MB
200dpi(200dpi)
213dpi(tvdpi)
220dpi(220dpi)
240dpi(hdpi)
280dpi(280dpi) 96MB
320dpi(xhdpi) 128MB
360dpi(360dpi) 160MB
400dpi(400dpi) 192MB
420dpi(420dpi) 228MB
480dpi(xxhdpi) 256MB
560dpi(560dpi) 384MB
640dpi(xxxhdpi) 512MB
특대형 120dpi(ldpi) 48MB
140dpi(140dpi) 80MB
160dpi(mdpi)
180dpi(180dpi) 96MB
200dpi(200dpi)
213dpi(tvdpi)
220dpi(220dpi)
240dpi(hdpi)
280dpi(280dpi) 144MB
320dpi(xhdpi) 192MB
360dpi(360dpi) 240MB
400dpi(400dpi) 288MB
420dpi(420dpi) 336MB
480dpi(xxhdpi) 384MB
560dpi(560dpi) 576MB
640dpi(xxxhdpi) 768MB

3.8. 사용자 인터페이스 호환성

3.8.1. 런처(홈 화면)

Android에는 런처 애플리케이션(홈 화면)과 기기 런처(홈 화면) 대체를 위한 서드 파티 애플리케이션 지원이 포함되어 있습니다.

서드 파티 애플리케이션이 기기 홈 화면을 대체하도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 플랫폼 기능 android.software.home_screen을 선언해야 합니다(MUST).
  • [C-1-2] 서드 파티 애플리케이션이 <adaptive-icon> 태그를 사용하여 아이콘을 제공하고 PackageManager 메서드를 사용하여 아이콘을 검색하는 경우 AdaptiveIconDrawable 객체를 반환해야 합니다(MUST).

바로가기의 인앱 고정을 지원하는 기본 런처를 포함하는 기기 구현은 다음을 충족해야 합니다.

반대로 바로가기의 인앱 고정을 지원하지 않는 기기 구현은 다음을 충족해야 합니다.

서드 파티 앱이 ShortcutManager API를 통해 제공하는 추가적인 바로가기에 관한 빠른 액세스를 제공하는 기본 런처를 구현하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 모든 문서화된 바로가기 기능(예: 정적 및 동적 바로가기와 고정된 바로가기)을 지원하고 ShortcutManager API 클래스의 API를 온전히 구현해야 합니다(MUST).

앱 아이콘의 배지를 표시하는 기본 런처를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] NotificationChannel.setShowBadge() API 메서드를 존중해야 합니다(MUST). 즉, 값이 true로 설정되었고 앱의 모든 알림 채널에서 값을 false로 설정했을 때 앱 아이콘 배지 지정 스키마를 표시하지 않는 경우 앱 아이콘에 연결된 시각적 어포던스를 표시해야 합니다.
  • 서드 파티 애플리케이션이 독점 API를 사용하여 독점 배지 지정 스키마 지원을 나타내는 경우 독점 배지 지정 스키마로 앱 아이콘 배지를 재정의할 수 있지만(MAY) Notification.Builder.setNumber() 및 Notification.Builder.setBadgeIconType() API와 같은 SDK에 설명된 알림 배지 API를 통해 제공되는 리소스와 값을 사용해야 합니다(SHOULD).

기기 구현이 흑백 아이콘을 지원하는 경우 이러한 아이콘은 다음을 충족해야 합니다.

  • [C-6-1] 사용자가 명시적으로 사용 설정한 경우에만(예: 설정 또는 배경화면 선택 도구 메뉴를 통해) 사용해야 합니다(MUST).

3.8.2. 위젯

Android는 구성요소 유형과 해당하는 API, 그리고 애플리케이션이 'AppWidget'을 최종 사용자에게 노출하도록 허용하는 수명 주기를 정의하는 방식으로 서드 파티 앱 위젯을 지원합니다.

서드 파티 앱 위젯을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 플랫폼 기능 android.software.app_widgets에 지원을 선언해야 합니다(MUST).
  • [C-1-2] AppWidgets에 기본 지원을 포함하고 AppWidgets를 추가, 구성, 확인 및 제거하기 위한 사용자 인터페이스 어포던스를 노출해야 합니다(MUST).
  • [C-1-3] 표준 그리드 크기가 4x4인 위젯을 렌더링할 수 있어야 합니다(MUST). 자세한 내용은 Android SDK 문서의 앱 위젯 디자인 가이드를 참고하세요.
  • 잠금 화면에서 애플리케이션 위젯을 지원할 수 있습니다(MAY).

서드 파티 앱 위젯과 바로가기의 인앱 고정을 지원하는 기기 구현은 다음을 충족해야 합니다.

3.8.3. 알림

Android에는 서드 파티 앱 개발자가 기기의 하드웨어 구성요소(소리, 진동, 조명 등)와 소프트웨어 기능(알림 창, 시스템 표시줄 등)을 사용하여 사용자에게 중요한 이벤트를 알리고 사용자의 관심을 끌 수 있게 해주는 Notification 및 NotificationManager API가 포함되어 있습니다.

3.8.3.1. 알림 표시

서드 파티 앱이 사용자에게 중요한 이벤트를 알리도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SDK 문서에 설명된 하드웨어 기능을 사용하는 알림을 지원해야 하며 기기 구현 하드웨어를 통한 확장이 가능해야 합니다(MUST). 예를 들어 진동을 포함하는 기기 구현은 진동 API를 올바르게 구현해야 합니다(MUST). 기기 구현에 하드웨어가 부족한 경우 해당하는 API를 노옵스(no-ops)로 구현해야 합니다(MUST). 이 동작은 섹션 7에 자세히 설명되어 있습니다.
  • [C-1-2] API 또는 상태/시스템 표시줄 아이콘 스타일 가이드에서 제공된 모든 리소스(아이콘, 애니메이션 파일 등)를 올바르게 렌더링해야 하지만(MUST) 참조 Android 오픈소스 구현에서 제공하는 사용자 환경을 대체하는 알림 사용자 환경을 제공할 수 있습니다(MAY).
  • [C-1-3] API에 설명된 동작을 제대로 적용 및 구현하여 알림을 업데이트, 제거, 그룹화해야 합니다(MUST).
  • [C-1-4] SDK에 문서화된 NotificationChannel API의 전체 동작을 제공해야 합니다(MUST).
  • [C-1-5] 각 채널 및 앱 패키지 수준별로 특정 서드 파티 앱의 알림을 차단하고 수정할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
  • [C-1-6] 또한 삭제된 알림 채널을 표시하기 위한 사용자 어포던스도 제공해야 합니다(MUST).

  • [C-1-7] 추가적인 사용자 상호작용 없이 알림 텍스트와 함께 Notification.MessagingStyle을 통해 제공되는 모든 리소스(이미지, 스티커, 아이콘 등)를 올바르게 렌더링해야 합니다(MUST). 예를 들면 setGroupConversation을 통해 설정된 그룹 대화의 android.app.Person을 통해 제공되는 아이콘을 포함한 모든 리소스를 표시해야 합니다(MUST).

  • [C-SR-1] 알림 리스너 권한을 부여받은 앱에 노출되는 알림을 사용자가 제어할 수 있도록 어포던스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 이러한 알림 리스너마다 사용자가 이 리스너에 연결된 알림 유형을 제어할 수 있도록 하는 세부사항이 있어야 합니다(MUST). 유형에는 '대화', '알림', '무음', '중요하고 지속적인' 알림이 포함되어야 합니다(MUST).

  • [C-SR-2] 특정 알림 리스너에 알림을 제외할 앱을 사용자가 지정할 수 있도록 어포던스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-3] 사용자가 알림을 여러 차례 닫은 후에는 각 채널 및 앱 패키지 수준별로 특정 서드 파티 앱의 알림을 차단할 수 있도록 사용자 어포던스를 자동으로 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 리치 알림을 지원해야 합니다(SHOULD).

  • 우선순위가 높은 알림을 헤드업 알림으로 표시해야 합니다(SHOULD).

  • 알림을 일시 중지하기 위한 사용자 어포던스를 보유해야 합니다(SHOULD).

  • 운전자 주의 분산 행동과 같은 안전 문제를 완화할 수 있도록 서드 파티 앱이 사용자에게 중요한 이벤트를 언제 알릴 수 있는지에 관한 표시 및 시점만 관리할 수 있습니다(MAY).

Android 11은 대화 알림을 지원합니다. 대화 알림은 MessagingStyle을 사용하고 게시된 사람 단축키 ID를 제공합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-4] 진행 중인 포그라운드 서비스 알림 및 importance:high 알림을 제외하고, 비대화 알림에 앞서 conversation notifications를 그룹화하여 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기기 구현이 conversation notifications를 지원하고 앱이 bubbles의 필수 데이터를 제공하는 경우 다음을 충족해야 합니다.

  • [C-SR-5] 이 대화를 도움말 풍선으로 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). AOSP 구현은 기본 시스템 UI, 설정, 런처로 이러한 요구사항을 충족합니다.

리치 알림을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 표시된 리소스 요소와 관련하여 Notification.Style API 클래스 및 서브클래스를 통해 제공되는 추가 리소스를 사용해야 합니다(MUST).
  • Notification.Style API 클래스 및 서브클래스에 정의된 각 리소스 요소(아이콘, 제목, 요약 텍스트 등)를 모두 표시해야 합니다(SHOULD).

운전자 알림은 사용자가 노출되는 표면과는 별도로 사용자에게 표시되는 알림입니다. 보행 중 주의 알림을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 헤드업 알림이 표시된 경우 Notification.Builder API 클래스에 설명된 헤드업 알림 뷰 및 리소스를 사용해야 합니다(MUST).
  • [C-3-2] SDK에 설명된 추가적인 사용자 상호작용 없이 Notification.Builder.addAction()을 통해 제공되는 작업과 알림 콘텐츠를 함께 표시해야 합니다(MUST).
3.8.3.2. 알림 리스너 서비스

Android에는 사용자가 명시적으로 사용 설정한 앱이 게시 또는 업데이트되는 모든 알림의 사본을 수신할 수 있도록 허용하는 NotificationListenerService API가 포함되어 있습니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 설치 및 사용자 설정된 모든 수신기 서비스에 알림 전체를 정확하고 빠르게 업데이트해야 합니다(MUST). 여기에는 알림 객체에 추가된 모든 메타데이터도 포함됩니다.
  • [C-0-2] snoozeNotification() API 호출을 존중해야 하며, API 호출에 설정된 일시 중지 기간 이후에는 알림을 닫고 콜백을 호출해야 합니다(MUST).

알림 일시 중지를 위한 사용자 어포던스를 보유한 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] NotificationListenerService.getSnoozedNotifications() 등의 표준 API를 통해 일시 중지된 알림 상태를 제대로 반영해야 합니다(MUST).
  • [C-1-2] 영구/포그라운드 서비스가 아닌 이상 설치된 각 서드 파티 앱에서 알림을 일시중지할 수 있도록 이러한 사용자 어포던스를 제공해야 합니다(MUST).
3.8.3.3. DND(방해 금지 모드)/우선순위 모드

DND 기능(우선순위 모드라고도 함)을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기기 구현이 사용자가 DND 정책 구성 액세스를 서드 파티 앱에 부여하거나 거부할 수 있는 수단을 제공한 경우 애플리케이션에서 생성한 자동 DND 규칙과 사용자 생성/사전 정의 규칙을 함께 표시해야 합니다(MUST).
  • [C-1-3] NotificationManager.Policy와 함께 전달된 suppressedVisualEffects 값을 선정해야 하며(MUST), 앱이 SUPPRESSED_EFFECT_SCREEN_OFF 또는 SUPPRESSED_EFFECT_SCREEN_ON 플래그를 설정한 경우 시각적 효과를 사용하여 DND 설정 메뉴에서 억제되었음을 사용자에게 알려야 합니다(SHOULD).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

3.8.3.4. 민감한 알림 보호

[3.8.3.4 민감한 알림 보호](2024년 4월 8일 미리보기)

기기 구현:

  • [C-1-1] 알림 콘텐츠에서 알림 리스너까지 민감한 정보를 수정하는 알림 어시스턴트 서비스(NAS)를 포함해야 합니다(MUST). 단, 리스너 서비스가 다음과 같은 경우는 예외입니다.

    • uid가 10000 미만인 시스템 서명 앱
    • 시스템 UI
    • 셸
    • 지정된 호환 기기 앱(CompanionDeviceManager에서 정의함)
    • SYSTEM_AUTOMOTIVE_PROJECTION 역할
    • SYSTEM_NOTIFICATION_INTELLIGENCE 역할
    • HOME 역할

ExtService에 포함된 NotificationAssistantServices의 AOSP 구현은 이러한 요구사항을 충족합니다.

새로운 요구사항 종료

[3.8.3.4 민감한 알림 보호](2024년 2월 26일 미리보기)

기기 구현:

  • [C-1-1] 알림 콘텐츠에서 알림 리스너까지 민감한 정보를 수정하는 알림 어시스턴트 서비스(NAS)를 포함해야 합니다(MUST). 단, 해당 서비스가 다음과 같은 경우는 예외입니다.

    • uid가 10000 미만인 시스템 서명 앱
    • SysUI
    • 셸
    • 지정된 호환 기기 앱(CompanionDeviceManager에서 정의함)
    • SYSTEM_AUTOMOTIVE_PROJECTION 역할
    • SYSTEM_NOTIFICATION_INTELLIGENCE 역할
    • HOME 역할

ExtService에 포함된 NotificationAssistantServices의 AOSP 구현은 이러한 요구사항을 충족합니다.

새로운 요구사항 종료

[3.8.3.4 민감한 알림 보호](2024년 2월 5일 미리보기)

기기 구현:

  • [C-1-1] 알림 콘텐츠에서 알림 리스너까지 민감한 정보를 수정하는 알림 어시스턴트 서비스(NAS)를 포함해야 하고(MUST) 비 예외 알림 리스너 서비스에 민감한 정보를 전송하면 안 됩니다(MUST NOT). 단, 해당 서비스가 다음과 같은 경우는 예외입니다.

    • SysUI 및 시스템 서버 앱
    • 셸
    • 지정된 호환 기기 앱(CompanionDeviceManager API에서 결정됨)
    • SYSTEM_AUTOMOTIVE_PROJECTION 역할
    • SYSTEM_NOTIFICATION_INTELLIGENCE 역할
    • 처리되는 알림이 특정 NLS와 동일한 패키지에서 전송됨
    • HOME 역할

ExtService에 포함된 NotificationAssistantServices의 AOSP 구현은 이러한 요구사항을 충족합니다.

새로운 요구사항 종료

3.8.4. 지원 API

또한 Android에는 애플리케이션이 현재 컨텍스트의 정보를 기기의 어시스턴트와 어느 정도 공유할지 선택할 수 있게 해주는 지원 API도 포함되어 있습니다.

지원 작업을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음 중 하나를 사용하여 컨텍스트가 언제 공유되는지 최종 사용자에게 명확히 나타내야 합니다(MUST).
    • 지원 앱이 컨텍스트에 액세스할 때마다 Android 오픈소스 프로젝트 구현의 지속 시간과 밝기를 충족하거나 초과하는 화면의 가장자리 주변에 흰색 표시등을 표시합니다.
    • 사전 설치된 지원 앱의 경우 기본 음성 입력 및 지원 앱 설정 메뉴에서 2개의 탐색 이내로 떨어진 사용자 어포던스를 제공하고, 핫워드 또는 지원 탐색 키 입력을 통해 사용자가 지원 앱을 명시적으로 호출한 경우 컨텍스트만 공유합니다.
  • [C-2-2] 섹션 7.2.3의 설명처럼 지원 앱을 실행하도록 지정된 상호작용은 사용자가 선택한 지원 앱 즉, VoiceInteractionService 또는 ACTION_ASSIST 인텐트를 처리하는 활동을 구현하는 앱을 실행해야 합니다(MUST).

3.8.5. 알림 및 토스트 메시지

애플리케이션은 Toast API를 사용하여 잠시 후에 사라지는 짧은 비 모달 문자열을 최종 사용자에게 표시할 수 있으며 TYPE_APPLICATION_OVERLAY 창 유형 API를 사용하여 알림 창을 다른 앱에 겹쳐 오버레이로 표시할 수 있습니다.

화면 또는 동영상 출력을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 앱이 TYPE_APPLICATION_OVERLAY를 사용하는 알림 창을 표시하지 못하도록 차단하기 위한 사용자 어포던스를 제공해야 합니다(MUST). AOSP 구현은 알림 창에 컨트롤을 포함하여 이러한 요구사항을 충족합니다.

  • [C-1-2] 토스트 API를 선정해야 하며 애플리케이션의 토스트 알림을 최종 사용자에게 명확하게 표시해야 합니다(MUST).

3.8.6. 테마

Android는 애플리케이션이 전체 활동 또는 애플리케이션에 걸쳐 스타일을 적용하는 메커니즘으로 '테마'를 제공합니다.

Android에는 'Holo' 및 'Material' 테마 계열이 정의된 스타일 모음으로 포함되어 있습니다. 애플리케이션 개발자는 Android SDK에서 정의한 Holo 테마의 분위기와 디자인을 매칭하고 싶은 경우 이러한 테마 계열을 사용할 수 있습니다.

화면 또는 동영상 출력을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 애플리케이션에 노출되는 Holo 테마 속성을 변경하면 안 됩니다(MUST NOT).
  • [C-1-2] 'Material' 테마 계열을 지원해야 하며(MUST) 애플리케이션에 노출되는 Material 테마 속성이나 애셋을 변경하면 안 됩니다(MUST NOT).

  • [C-1-3] Roboto가 지원하는 언어의 'sans-serif' 글꼴 모음을 Roboto 버전 2.x로 설정하거나 사용자 어포던스를 제공하여 'sans-serif' 글꼴 모음을 Roboto가 지원하는 언어의 Roboto 버전 2.x로 변경해야 합니다(MUST).

  • [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES의 AOSP 문서에 명시된 것처럼 동적 색상 색조 팔레트를 생성해야 합니다(android.theme.customization.system_palette 및 android.theme.customization.theme_style 참고)(MUST).

  • [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 문서(android.theme.customization.theme_styles 참고)에 나열된 색상 테마 스타일 즉, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, MONOCHROMATIC을 사용하여 동적 색상 색조 팔레트를 생성해야 합니다(MUST).

    android.theme.customization.system_palette와 함께 전송 시 동적 색상 색조 팔레트를 생성하는 데 사용되는 '소스 색상'입니다(Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES에 문서화됨).

  • [C-1-6] CAM16 크로마 값이 5 이상이어야 합니다(MUST).

    • 선택할 수 있는 유효한 소스 색상을 여러 개 제공하는 com.android.systemui.monet.ColorScheme#getSeedColors를 통해 배경화면에서 파생되어야 합니다(SHOULD).

    • 제공된 색상이 위의 소스 색상 요구사항을 충족하지 않는 경우 0xFF1B6EF3 값을 사용해야 합니다(SHOULD).

Android에는 '기기 기본값' 테마 계열도 정의된 스타일 모음으로 포함되어 있습니다. 애플리케이션 개발자는 기기 구현자가 정의한 대로 기기 테마의 디자인과 분위기를 일치시키고 싶은 경우 이 테마를 사용하면 됩니다.

Android는 투명한 시스템 표시줄을 포함하는 변형 테마를 지원합니다. 애플리케이션 개발자는 이 테마를 사용하여 앱 콘텐츠를 포함하는 상태 및 탐색 메뉴 뒤의 영역을 채울 수 있습니다. 이 구성에서 일관적인 개발자 환경을 지원하기 위해서는 여러 기기 구현에 걸쳐 상태 표시줄 아이콘 스타일이 유지되는 것이 중요합니다.

시스템 상태 표시줄을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 아이콘이 상태 문제를 나타내지 않거나 앱이 WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS 플래그를 사용하여 조명 상태 표시줄을 요청하지 않는 이상 시스템에서 발행한 시스템 상태 아이콘(신호 강도 및 배터리 수준) 및 알림에 흰색을 사용해야 합니다(MUST).
  • [C-2-2] 앱에서 조명 상태 표시줄을 요청하는 경우 Android 기기 구현은 시스템 상태 아이콘의 색을 검은색으로 변경해야 합니다(MUST). 자세한 내용은 R.style을 참고하세요.

3.8.7. 라이브 배경화면

Android는 구성요소 유형과 해당하는 API, 그리고 애플리케이션이 1개 이상의 '라이브 배경화면'을 최종 사용자에게 노출하도록 허용하는 수명 주기를 정의합니다. 라이브 배경화면은 다른 애플리케이션 뒤에 배경화면으로 표시되는 제한된 입력 기능을 포함하는 애니메이션, 패턴, 유사 이미지입니다.

하드웨어는 다른 애플리케이션에 관한 부정적인 효과 없이 합리적인 프레임 속도에서 기능 제한 없이 모든 라이브 배경화면을 실행할 수 있는 경우 안정적인 실행이 가능하다고 간주됩니다. 하드웨어 한계로 인해 배경화면 또는 애플리케이션이 충돌하거나 오작동하거나 CPU 또는 배터리 전력을 과도하게 사용하거나 허용될 수 없는 낮은 프레임 속도로 실행되는 경우, 하드웨어는 라이브 배경화면을 실행할 수 없는 것으로 간주됩니다. 예를 들어 일부 라이브 배경화면은 OpenGL 2.0 또는 3.x 컨텍스트를 사용하여 콘텐츠를 렌더링할 수 있습니다. 라이브 배경화면은 여러 OpenGL 컨텍스트를 지원하지 않는 하드웨어에서 안정적으로 실행되지 않습니다. 이는 OpenGL 컨텍스트의 라이브 배경화면 사용이 마찬가지로 OpenGL 컨텍스트를 사용하는 다른 애플리케이션과 충돌할 수 있기 때문입니다.

  • 위의 설명처럼 라이브 배경화면을 안정적으로 실행할 수 있는 기기 구현은 라이브 배경화면을 구현해야 합니다(SHOULD).

라이브 배경화면을 구현하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 플랫폼 기능 플래그 android.software.live_wallpaper를 보고해야 합니다(MUST).

3.8.8. 활동 전환

업스트림 Android 소스 코드에는 개요 화면이 포함되어 있습니다. 이 시스템 수준 사용자 인터페이스는 사용자가 마지막으로 애플리케이션을 이탈한 시점의 애플리케이션 그래픽 상태를 사용하여 작업을 전환하고 최근에 액세스한 활동과 작업을 표시합니다.

섹션 7.2.3에 설명된 최근 함수 탐색 키를 포함하는 기기 구현은 인터페이스를 변경할 수 있습니다(MAY).

섹션 7.2.3에 설명된 최근 함수 탐색 키를 포함하는 기기 구현은 인터페이스를 변경하는 경우 다음을 충족해야 합니다.

  • [C-1-1] 표시된 활동을 최소 7개까지 지원해야 합니다(MUST).
  • 한 번에 활동 4개 이상의 제목을 표시해야 합니다(SHOULD).
  • 최근 항목에 강조 색상, 아이콘, 화면 제목을 표시해야 합니다(SHOULD).
  • 종료 어포던스('x')를 표시해야 하지만(SHOULD) 사용자가 화면과 상호작용할 때까지 이를 지연할 수 있습니다(MAY).
  • 이전 활동으로 쉽게 전환할 수 있도록 바로가기를 구현해야 합니다(SHOULD).
  • 최근 함수 키를 두 번 탭하면 가장 최근에 사용한 앱 2개 간의 작업 빠른 전환을 트리거해야 합니다(SHOULD).
  • 최근 함수 키를 길게 누르면 분할 화면 멀티 윈도우 모드(지원되는 경우)를 트리거해야 합니다(SHOULD).
  • 연계된 최근 항목을 함께 이동하는 그룹으로 표시할 수 있습니다(MAY).
  • [C-SR-1] 개요 화면에 업스트림 Android 사용자 인터페이스(또는 유사한 썸네일 이미지 기반 인터페이스)를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3.8.9. 입력 관리

Android에는 입력 관리 및 서드 파티 입력 방식 편집기(IME)와 관련된 지원 기능이 포함되어 있습니다.

사용자가 기기에 서드 파티 입력 방식을 사용하도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 플랫폼 기능 android.software.input_methods를 선언하고 Android SDK 문서에 정의된 IME API를 지원해야 합니다(MUST).

3.8.10. 잠금 화면 미디어 컨트롤

원격 제어 클라이언트 API는 Android 5.0에서 지원 중단되며, 대신 미디어 애플리케이션을 잠금 화면에 표시되는 재생 컨트롤과 통합할 수 있는 미디어 알림 템플릿이 지원됩니다.

3.8.11. 화면 보호기(이전의 Dreams)

화면 보호기를 구성하기 위한 설정 인텐트는 섹션 3.2.3.5를 참고하세요.

3.8.12. 위치

위치 좌표를 제공할 수 있는 하드웨어 센서(예: GPS)를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-2] 설정 내 위치 메뉴에 위치의 현재 상태를 표시해야 합니다(MUST).
  • [C-1-3] 설정 내 위치 메뉴에 위치 모드를 표시하면 안 됩니다(MUST NOT).

3.8.13. 유니코드 및 글꼴

Android에는 유니코드 10.0에 정의된 이모티콘 문자를 지원하는 기능이 포함되어 있습니다.

화면 또는 동영상 출력을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 이러한 이모티콘을 색상 문양으로 렌더링할 수 있어야 합니다(MUST).
  • [C-1-2] 다음을 지원하는 기능을 포함해야 합니다(MUST):
    • 여러 두께를 포함하는 Roboto 2 글꼴—기기에서 제공되는 언어의 sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light
    • 확장 라틴 문자 A, B, C, D 범위를 비롯한 라틴어, 그리스어, 키릴 문자, 그리고 유니코드 7.0 화폐 기호 블록의 모든 글리프에 적용되는 전체 유니코드 7.0
  • [C-1-3] 시스템 이미지에서 NotoColorEmoji.tff를 삭제하거나 수정하면 안 됩니다(MUST NOT). NotoColorEmoji.tff에서 새로운 그림 이모티콘 글꼴을 추가하여 그림 이모티콘을 재정의할 수 있습니다.
  • 유니코드 기술 보고서 #51에 명시된 피부 톤과 다양한 이모티콘을 지원해야 합니다(SHOULD).

IME를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • 이러한 이모티콘 문자의 입력 방식을 사용자에게 제공해야 합니다(SHOULD).

Android에는 Myanmar 글꼴 렌더링 지원 기능이 포함되어 있습니다. Myanmar에는 일반적으로 'Zawgyi'라고 알려진 여러 비 유니코드 준수 글꼴이 있습니다. 이는 미얀마 언어를 렌더링하는 데 사용됩니다.

버마어 지원 기능을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 텍스트는 유니코드 준수 글꼴을 기본값으로 렌더링해야 합니다(MUST). 유니코드 비 준수 글꼴은 사용자가 언어 선택 도구에서 선택하지 않는 한 기본 글꼴로 설정하면 안 됩니다(MUST NOT).
  • [C-2-2] 기기에서 유니코드 비 준수 글꼴이 지원되는 경우 유니코드 글꼴 및 유니코드 비 준수 글꼴을 지원해야 합니다(MUST). 유니코드 비 준수 글꼴은 유니코드 글꼴을 삭제하거나 덮어쓰면 안 됩니다(MUST NOT).
  • [C-2-3] 스크립트 코드 Qaag가 포함되어 있는 언어 코드가 지정된 경우에만(예: my-Qaag) 유니코드 비 준수 글꼴로 텍스트를 렌더링해야 합니다(MUST). 다른 ISO 언어 또는 지역 코드(할당됨, 할당되지 않음, 예약됨)를 사용하여 미얀마어 유니코드 비 준수 글꼴을 나타낼 수 없습니다. 앱 개발자 및 웹페이지 작성자는 다른 언어에서와 마찬가지로 my-Qaag를 지정된 언어 코드로 명시할 수 있습니다.

3.8.14. 멀티 윈도우

여러 활동을 동시에 표시하기 위한 기능을 보유한 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Android SDK 멀티 윈도우 모드 지원 문서에 설명된 애플리케이션 동작 및 API에 따라 이러한 멀티 윈도우 모드를 구현하고 다음과 같은 요구사항을 충족해야 합니다(MUST).
  • [C-1-2] 이 SDK에 설명된 AndroidManifest.xml 파일의 앱에 의해 설정된 android:resizeableActivity를 선정해야 합니다(MUST).
  • [C-1-3] 화면 높이가 440dp 미만이고 화면 너비가 440dp 미만인 경우 화면 분할 또는 자유 형식 모드를 제공하면 안 됩니다(MUST NOT).
  • [C-1-4] PIP 모드를 제외하고는 활동이 멀티 윈도우 모드의 220dp보다 작은 크기로 변경되면 안 됩니다(MUST NOT).
  • 화면 크기가 xlarge인 기기 구현은 자유 형식 모드를 지원해야 합니다(SHOULD).

멀티 윈도우 모드와 분할 화면 모드를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-2] 화면 분할 멀티 윈도우의 도킹된 활동을 잘라내야 하지만(MUST) 런처 앱이 포커스가 맞춰진 창인 경우 일부 콘텐츠를 표시해야 합니다(SHOULD).
  • [C-2-3] 서드 파티 런처 애플리케이션의 선언된 AndroidManifestLayout_minWidth 및 AndroidManifestLayout_minHeight 값을 선정해야 하며(MUST) 도킹된 활동의 일부 콘텐츠를 표시하는 과정에서 이러한 값을 재정의하면 안 됩니다.

멀티 윈도우 모드 및 PIP 멀티 윈도우 모드를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 앱이 다음을 실행하는 경우 PIP 멀티 윈도우 모드로 활동을 실행해야 합니다(MUST). *API 수준 26 이상을 타겟팅하고 android:supportsPictureInPicture를 선언하는 경우 *API 수준을 25 이하로 타겟팅하고 android:resizeableActivity 및 android:supportsPictureInPicture를 둘 다 선언하는 경우
  • [C-3-2] setActions() API를 통해 현재 PIP 활동에 의해 명시된 대로 SystemUI에 작업을 노출해야 합니다(MUST).
  • [C-3-3] setAspectRatio() API를 통해 PIP 활동에 의해 명시된 대로 1:2.39 이상 및 2.39:1 이하의 가로세로 비율을 지원해야 합니다(MUST) .
  • [C-3-4] KeyEvent.KEYCODE_WINDOW를 사용하여 PIP 창을 제어해야 합니다(MUST). PIP 모드가 구현되지 않은 경우 키를 포그라운드 활동에 제공해야 합니다(MUST).
  • [C-3-5] 앱이 PIP 모드에서 표시되지 않도록 차단하기 위한 사용자 어포던스를 제공해야 합니다(MUST). AOSP 구현은 알림 창에 컨트롤을 포함하여 이러한 요구사항을 충족합니다.

  • [C-3-6] 애플리케이션이 AndroidManifestLayout_minWidth 및 AndroidManifestLayout_minHeight의 값을 선언하지 않으면 다음과 같이 PIP 창의 최소 너비 및 높이를 할당해야 합니다(MUST).

    • Configuration.uiMode가 UI_MODE_TYPE_TELEVISION 이외의 값으로 설정된 기기는 108dp의 최소 너비와 높이를 할당해야 합니다(MUST).
    • Configuration.uiMode가 UI_MODE_TYPE_TELEVISION로 설정된 기기는 240dp의 최소 너비와 135dp의 최소 높이를 할당해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-4-1 및 C-5-1](2024년 2월 5일 미리보기)

폴더블 Android 호환 디스플레이 영역을 하나 이상 포함하거나, 여러 Android 호환 디스플레이 영역 간에 접이식 힌지를 포함하고 이러한 영역을 애플리케이션에서 사용할 수 있도록 하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 멀티 윈도우 모드를 지원해야 합니다(MUST).

멀티 윈도우 모드를 지원하는 기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

3.8.15. 디스플레이 컷아웃

Android는 SDK 문서의 설명처럼 디스플레이 컷아웃을 지원합니다. DisplayCutout API는 가장자리의 디스플레이 컷아웃이나 곡선 디스플레이로 인해 애플리케이션에서 작동하지 않을 수 있는 디스플레이 가장자리의 영역을 정의합니다.

디스플레이 컷아웃을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-5] 기기의 가로세로 비율이 1.0(1:1)인 경우 컷아웃을 포함하면 안 됩니다(MUST NOT).
  • [C-1-2] 가장자리당 2개 이상의 컷아웃을 포함하면 안 됩니다(MUST NOT).
  • [C-1-3] SDK의 설명처럼 WindowManager.LayoutParams API를 통해 앱에서 설정한 디스플레이 컷아웃 플래그를 선정해야 합니다(MUST).
  • [C-1-4] DisplayCutout API에 정의된 모든 컷아웃 측정항목의 올바른 값을 보고해야 합니다(MUST).

3.8.16. 기기 제어

Android에는 서드 파티 애플리케이션에서 사용자의 빠른 상태 및 작업을 위한 기기 제어를 게시할 수 있도록 하는 ControlsProviderService 및 Control API가 포함되어 있습니다.

섹션 2_2_3에서 기기별 요구사항을 참고하세요.

3.8.17. 클립보드

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 9.8.6 콘텐츠 캡처 및 앱 검색에 언급된 서비스를 제외하고 명시적인 사용자 작업(예: 오버레이의 버튼 누르기) 없이 구성요소, 활동, 서비스 또는 모든 네트워크 연결에 클립보드 데이터를 전송해서는 안 됩니다(MUST NOT).

ClipData.getDescription().getExtras()에 android.content.extra.IS_SENSITIVE가 포함된 모든 ClipData 항목의 콘텐츠를 클립보드에 복사할 때 사용자에게 표시되는 미리보기를 생성하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 사용자에게 표시되는 미리보기를 수정해야 합니다(MUST).

AOSP 참조 구현은 이러한 클립보드 요구사항을 충족합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

3.8.18. 현지화 및 언어 선택[철회됨]

3.8.18 [철회됨](2024년 4월 8일 미리보기)

다음 요구사항은 Android 15(AOSP 실험용)에서 철회되었습니다.

새로운 요구사항 종료

3.8.18(2024년 2월 5일 미리보기)

여러 언어를 지원하는 기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

3.9. 기기 관리

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[3.9/C-1-1 및 C-1-2](2024년 2월 26일 미리보기)

Android에는 보안 인식 애플리케이션을 허용 Android Device Administration API Device Policy Manager API를 통해 시스템 수준에서 기기 정책 컨트롤러 애플리케이션이 기기 관리 기능(예: 비밀번호 정책 적용 또는 원격 초기화 실행)을 실행할 수 있는 기능이 포함되어 있습니다.

Android SDK 문서에 정의된 모든 기기 관리 정책을 구현하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.software.device_admin을 선언해야 합니다(MUST).
  • [C-1-2] 섹션 3.9.1 및 섹션 3.9.1.1에 설명된 기기 소유자 프로비저닝을 지원해야 합니다(MUST).

새로운 요구사항 종료

3.9.1 기기 프로비저닝

3.9.1.1. 기기 소유자 프로비저닝

android.software.device_admin을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 아래에 설명된 기기 소유자 앱으로 DPC(Device Policy Client) 등록을 지원해야 합니다(MUST).
    • 사용자 및 사용자 데이터가 모두 구성되어 있지 않은 기기 구현은 다음을 충족해야 합니다.
      • [C-1-5] 기기에서 기능 플래그 android.hardware.nfc를 통해 근거리 무선통신(NFC) 지원을 선언하고 MIME 유형이 MIME_TYPE_PROVISIONING_NFC인 레코드가 포함된 NFC 메시지를 수신하는 경우 DPC 애플리케이션을 기기 소유자 앱으로 등록하거나 DPC 앱이 기기 소유자 또는 프로필 소유자가 될지 선택할 수 있도록 해야 합니다(MUST).
      • [C-1-8] 유효한 옵션이 하나만 있는 컨텍스트에서 결정할 수 있는 경우를 제외하고 android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES 값에 따라 DPC 앱이 기기 소유자가 될지 또는 프로필 소유자가 될지 선택할 수 있도록 기기 소유자 프로비저닝이 트리거된 후에 ACTION_GET_PROVISIONING_MODE 인텐트를 전송해야 합니다(MUST).
      • [C-1-9] 사용된 프로비저닝 방법과 관계없이 프로비저닝 중에 기기 소유자가 설정된다면 기기 소유자 앱에 ACTION_ADMIN_POLICY_COMPLIANCE 인텐트를 전송해야 합니다(MUST). 기기 소유자 앱이 완료될 때까지 사용자가 설정 마법사에서 진행할 수 없어야 합니다.
    • 사용자 또는 사용자 데이터가 있는 기기 구현은 다음을 충족해야 합니다.
      • [C-1-7] 이제 DPC 애플리케이션을 기기 소유자 앱으로 등록하면 안 됩니다(MUST NOT).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-2~C-2-3](2024년 2월 26일 미리보기)

  • [C-1-2] 화면에서 최종 사용자 상호작용이 있기 전에 기기가 프로그래매틱 방식으로 소매 데모 모드용으로 구성되지 않는 한 앱이 기기 소유자로 설정되기 전에 적절한 공개 알림(예: AOSP에 참조된 알림)을 표시하고 최종 사용자로부터 확실한 동의를 얻어야 합니다(MUST). android.software.device_admin을 선언하지만 독점 기기 소유자 관리 솔루션을 포함하고 자체 솔루션에서 구성된 애플리케이션을 표준 Android DevicePolicyManager API에서 인정하는 표준 '기기 소유자'에 대한 '기기 소유자 상응 대상'으로 업그레이드하기 위한 메커니즘을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 업그레이드 중인 특정 앱이 합법적인 기업 기기 관리 솔루션에 속하고 '기기 소유자'에 준하는 권한을 보유하도록 독점 솔루션에 구성되었음을 확인하기 위한 프로세스가 구축되어 있어야 합니다(MUST).

  • [C-2-2] DPC 애플리케이션을 '기기 소유자'로 등록하기 전에 android.app.action.PROVISION_MANAGED_DEVICE에 의해 시작된 흐름과 같은 AOSP 기기 소유자 동의 공개를 표시해야 합니다(MUST).

  • [C-2-3] 동의를 하드 코딩하거나 다른 기기 소유자 앱의 사용을 막으면 안 됩니다(MUST NOT).

새로운 요구사항 종료

3.9.1.2. 관리 프로필 프로비저닝

android.software.managed_users를 선언하는 기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-2](2024년 2월 26일 미리보기)

  • [C-1-2] 관리 프로필 프로비저닝 프로세스(android.app.action.PROVISION_MANAGED_PROFILE을 사용하는 DPC 또는 플랫폼에서 시작된 흐름), 동의 화면, 사용자 환경은 AOSP 구현과 일치해야 합니다(MUST).

새로운 요구사항 종료

  • [C-1-3] 특정 시스템 기능이 기기 정책 컨트롤러(DPC)에 의해 사용 중지되었음을 사용자에게 표시할 수 있도록 설정 내에 다음과 같은 사용자 어포던스를 제공해야 합니다(MUST).

    • 특정 설정이 기기 관리자에 의해 제한되었음을 나타내기 위한 일관된 아이콘 또는 다른 사용자 어포던스(예: 업스트림 AOSP 정보 아이콘).
    • setShortSupportMessage를 통해 기기 관리자가 제공하는 간단한 설명 메시지
    • DPC 애플리케이션의 아이콘

  • [C-1-4] 프로비저닝이 android.app.action.PROVISION_MANAGED_PROFILE 인텐트로 시작되고 DPC가 핸들러를 구현했을 때 프로필 소유자가 설정되어 있다면 ACTION_PROVISIONING_SUCCESSFUL 인텐트의 핸들러를 직장 프로필에서 시작해야 합니다(MUST).

  • [C-1-5] 프로비저닝이 android.app.action.PROVISION_MANAGED_PROFILE 인텐트로 시작할 때 ACTION_PROFILE_PROVISIONING_COMPLETE 브로드캐스트를 직장 프로필 DPC로 전송해야 합니다(MUST).

  • [C-1-6] DPC 앱이 기기 소유자가 될지, 프로필 소유자가 될지 선택할 수 있도록(android.app.action.PROVISION_MANAGED_PROFILE 인텐트로 트리거하는 경우 제외) 프로필 소유자 프로비저닝이 트리거된 후에 ACTION_GET_PROVISIONING_MODE 인텐트를 전송해야 합니다(MUST).

  • [C-1-7] android.app.action.PROVISION_MANAGED_PROFILE 인텐트로 트리거하는 프로비저닝을 제외하고 사용된 프로비저닝 방법과 관계없이 프로비저닝 중에 프로필 소유자가 설정되면 ACTION_ADMIN_POLICY_COMPLIANCE를 직장 프로필로 전송해야 합니다(MUST). 프로필 소유자 앱이 완료될 때까지 사용자가 설정 마법사에서 진행할 수 없어야 합니다.

  • [C-1-8] 사용된 프로비저닝 방법에 관계없이 프로필 소유자가 설정된 경우 개인 프로필 DPC에 ACTION_MANAGED_PROFILE_PROVISIONED 브로드캐스트를 전송해야 합니다(MUST).

3.9.2. 관리 프로필 지원

android.software.managed_users를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.app.admin.DevicePolicyManager API를 통해 관리 프로필을 지원해야 합니다(MUST).
  • [C-1-2] 하나의 관리 프로필만 생성을 허용해야 합니다(MUST).
  • [C-1-3] AOSP 업스트림 작업 배지와 유사한 아이콘 배지를 사용하여 관리 애플리케이션과 위젯, 그리고 최근 항목 및 알림 등의 기타 배지가 지정된 UI 요소를 나타내야 합니다(MUST).
  • [C-1-4] AOSP 업스트림 작업 배지와 유사한 알림 아이콘을 표시하여 사용자가 관리 프로필 애플리케이션 내에 있음을 나타내야 합니다(MUST).
  • [C-1-5] 기기가 절전 모드에서 해제되고(ACTION_USER_PRESENT) 포그라운드 애플리케이션이 관리 프로필 내에 있는 경우 사용자가 관리 프로필에 있음을 나타내는 토스트 메시지를 표시해야 합니다(MUST).
  • [C-1-6] 관리 프로필이 존재하는 경우 사용자가 관리 프로필에서 기본 사용자로 또는 그 반대로 인텐트를 전달할 수 있도록 인텐트 '선택기'에 시각적 어포던스를 표시해야 합니다(MUST)(기기 정책 컨트롤러에 의해 사용 설정된 경우).
  • [C-1-7] 관리 프로필이 존재하는 경우 기본 사용자 및 관리 프로필 둘 다에 대해 다음과 같은 사용자 어포던스를 노출해야 합니다(MUST).
    • 기본 사용자 및 관리 프로필의 배터리, 위치, 모바일 데이터 및 저장소 사용량과 관련된 별도의 계정.
    • 기본 사용자 또는 관리 프로필 내에 설치된 VPN 애플리케이션의 독립적 관리.
    • 기본 사용자 또는 관리 프로필 내에 설치된 애플리케이션의 독립적 관리.
    • 기본 사용자 또는 관리 프로필 내 계정의 독립적 관리.
  • [C-1-8] 기기 정책 컨트롤러가 허용하는 경우 사전 설치된 다이얼러, 연락처 및 메시지 앱이 기본 프로필 옆의 관리 프로필(존재하는 경우)에서 발신자 정보를 검색하고 조회할 수 있는지 확인해야 합니다(MUST).
  • [C-1-9] 여러 사용자가 사용 설정된 기기에 적용 가능한 모든 보안 요구사항을 충족하는지 확인해야 합니다(MUST)(섹션 9.5 참고). 하지만 관리 프로필은 기본 사용자 외의 또 다른 추가 사용자로 계산되지 않습니다.
  • [C-1-10] 포커스가 있고(사용자가 모든 활동 중에 마지막으로 상호작용한 창) 직장 프로필 앱에 속하는 topActivity 창에서 스크린샷을 캡처할 때 직장 프로필 저장소에 스크린샷 데이터를 저장해야 합니다(MUST).
  • [C-1-11] 개인 프로필 데이터가 직장 프로필에 저장되지 않도록 스크린샷을 직장 프로필에 저장할 때는 직장 프로필 애플리케이션 창을 제외하고 다른 모든 화면 콘텐츠는 캡처하면 안 됩니다(MUST NOT).

android.software.managed_users 및 android.software.secure_lock_screen을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 관리 프로필에서만 실행되는 앱에만 액세스 권한을 부여하려면 다음 요구사항을 충족하는 별도의 잠금 화면을 지정할 수 있는 기능을 지원해야 합니다(MUST).
    • 기기 구현이 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 인텐트를 적용하고 관리 프로필의 별도 잠금 화면 사용자 인증 정보를 구성하기 위한 인터페이스를 표시해야 합니다(MUST).
    • 관리 프로필의 잠금 화면 사용자 인증 정보는 Android 오픈소스 프로젝트 사이트에 문서화된 것처럼 상위 프로필과 동일한 사용자 인증 정보 저장소 및 관리 메커니즘을 사용해야 합니다(MUST).
    • getParentProfileInstance에 의해 반환된 DevicePolicyManager 인스턴스에 관해 호출되지 않은 이상 DPC 비밀번호 정책이 관리 프로필의 잠금 화면 사용자 인증 정보에만 적용되어야 합니다(MUST).
  • 관리 프로필의 연락처가 사전 설치된 통화 기록, 수신 전화 UI, 진행 중 및 부재중 전화 알림, 연락처 및 메시지 앱에 표시된 경우 관리 프로필 애플리케이션을 나타내는 데 사용되는 동일한 배지로 연락처의 배지를 지정해야 합니다(SHOULD).

3.9.3. 관리 사용자 지원

android.software.managed_users를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] isLogoutEnabled가 true를 반환할 때 현재 사용자에서 로그아웃하고 멀티 사용자 세션의 기본 사용자로 다시 전환할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). 사용자 어포던스는 기기를 잠금 해제하지 않은 상태에서 잠금 화면에서 액세스할 수 있어야 합니다(MUST).

기기 구현에서 android.software.device_admin을 선언하고 기기 내 사용자 어포던스를 제공하여 보조 사용자를 추가하는 경우 다음을 충족해야 합니다.

  • [C-SR-1] 이 기기가 관리되고 있다는 것을 사용자가 알 수 있도록 계정이 새 보조 사용자에 추가되기 전에 android.app.action.PROVISION_MANAGED_DEVICE로 시작된 흐름에 표시된 것과 동일한 AOSP 기기 소유자 동의 공개를 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3.9.4. 기기 정책 관리 역할 요구사항

android.software.device_admin 또는 android.software.managed_users를 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 섹션 9.1에 정의된 기기 정책 관리 역할을 지원해야 합니다(MUST). 기기 정책 관리 역할이 있는 애플리케이션은 패키지 이름으로 config_devicePolicyManagement를 설정하여 정의할 수 있습니다(MAY). 애플리케이션이 미리 로드되지 않는 한 패키지 이름 뒤에는 :과 서명 인증서가 있어야 합니다.

위에 설명된 대로 config_devicePolicyManagement에 패키지 이름이 정의되지 않은 경우 다음을 충족해야 합니다.

패키지 이름이 위에 설명된 대로 config_devicePolicyManagement에 정의된 경우 다음을 충족해야 합니다.

  • [C-3-1] 애플리케이션이 사용자의 모든 프로필에 설치되어야 합니다(MUST).
  • [C-3-2] 기기 구현은 config_devicePolicyManagementUpdater를 설정하여 프로비저닝 전에 기기 정책 관리 역할 보유자를 업데이트하는 애플리케이션을 정의할 수 있습니다(MAY).

패키지 이름이 위에 설명된 대로 config_devicePolicyManagementUpdater에 정의된 경우 다음을 충족해야 합니다.

  • [C-4-1] 애플리케이션이 기기에 사전 설치되어 있어야 합니다(MUST).
  • [C-4-2] 애플리케이션은 android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER를 확인하는 인텐트 필터를 구현해야 합니다(MUST).

3.9.5. 기기 정책 해결 프레임워크

android.software.device_admin 또는 android.software.managed_users를 보고하는 기기 구현은 다음을 충족해야 합니다.

3.10. 접근성

Android는 장애가 있는 사용자가 기기를 좀 더 쉽게 탐색할 수 있도록 도와주는 접근성 레이어를 제공합니다. 또한 Android는 접근성 서비스 구현이 사용자 및 시스템 이벤트의 콜백을 수신하고 시스템 이벤트, 그리고 텍스트 음성 변환, 햅틱 반응 및 트랙볼/D패드 탐색과 같은 피드백 메커니즘을 생성할 수 있도록 지원하는 플랫폼 API를 제공합니다.

서드 파티 접근성 서비스를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 접근성 API SDK 문서에 설명된 Android 접근성 프레임워크의 구현을 제공해야 합니다(MUST).
  • [C-1-2] SDK에 문서화된 것처럼 접근성 이벤트를 생성하고 적절한 AccessibilityEvent를 모든 등록된 AccessibilityService 구현에 전달해야 합니다(MUST).
  • [C-1-4] AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON을 선언하는 접근성 서비스를 제어하는 사용자 어포던스를 제공해야 합니다(MUST). 시스템 탐색 메뉴가 있는 기기 구현의 경우 사용자에게 시스템 탐색 메뉴의 버튼을 통해 이러한 서비스를 제어할 수 있도록 허용해야 합니다(SHOULD).

사전 설치된 접근성 서비스를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 데이터 저장소가 파일 기반 암호화(FBE)로 암호화되는 경우 이러한 접근성 서비스를 직접 부팅 인식 앱으로 구현해야 합니다(MUST).
  • 사용자가 관련 접근성 서비스는 물론 글꼴 크기, 디스플레이 크기와 확대 동작을 조정할 수 있는 옵션까지 사용 설정할 수 있도록 즉각적인 설정 흐름의 메커니즘을 제공해야 합니다(SHOULD).

3.11. TTS(텍스트 음성 변환)

Android에는 애플리케이션이 텍스트 음성 변환(TTS) 서비스를 활용하고 서비스 제공업체가 TTS 서비스를 구현할 수 있는 API가 포함되어 있습니다.

기능 android.hardware.audio.output을 보고하는 기기 구현은 다음을 충족해야 합니다.

서드 파티 TTS 엔진 설치를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 사용자가 시스템 수준에서 사용할 TTS 엔진을 선택할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

3.12. TV 입력 프레임워크

[3.12](2024년 2월 26일 미리보기)

Android 텔레비전 입력 프레임워크(TIF)는 Android 텔레비전 서비스의 라이브 콘텐츠 전달을 간소화합니다. TIF는 Android 텔레비전 기기를 제어하는 입력 모듈 생성을 위한 표준 API를 제공합니다.

TIF를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 플랫폼 기능 android.software.live_tv를 선언해야 합니다(MUST).
  • [C-1-2] 이러한 API와 서드 파티 TIF 기반 입력 서비스를 사용하는 애플리케이션을 기기에 설치하고 사용할 수 있도록 모든 TIF API를 지원해야 합니다(MUST).

새로운 요구사항 종료

3.13. 빠른 설정

Android는 자주 사용하거나 급히 필요한 작업에 빠르게 액세스할 수 있도록 빠른 설정 UI 구성요소를 제공합니다.

빠른 설정 UI 구성요소를 포함하고 서드 파티 빠른 설정을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 사용자가 서드 파티 앱의 quicksettings API를 통해 제공된 타일을 추가하거나 제거할 수 있도록 허용해야 합니다(MUST).
  • [C-1-2] 서드 파티 앱의 타일을 빠른 설정에 자동으로 추가하면 안 됩니다(MUST NOT).
  • [C-1-3] 서드 파티 앱의 모든 사용자 추가 타일을 시스템에서 제공한 빠른 설정 타일 옆에 표시해야 합니다(MUST).

3.14. 미디어 UI

기기 구현에 MediaBrowser 또는 MediaSession을 통해 서드 파티 애플리케이션과 상호작용하는 비 음성인식 애플리케이션(앱)이 포함된 경우 앱은 다음을 충족해야 합니다.

  • [C-1-2] MediaDescription의 설명처럼 getIconBitmap() 또는 getIconUri()를 통해 획득한 아이콘과 getTitle()을 통해 획득한 제목을 명확하게 표시해야 합니다(MUST). 안전 규정(운전자 주의 분산 행동 방지 등)을 준수하도록 제목을 축소할 수 있습니다(MAY).

  • [C-1-3] 이러한 서드 파티 애플리케이션에서 제공한 콘텐츠를 표시할 때마다 서드 파티 애플리케이션 아이콘을 표시해야 합니다(MUST).

  • [C-1-4] 사용자가 전체 MediaBrowser 계층 구조와 상호작용할 수 있도록 허용해야 합니다. 안전 규정(운전자 주의 분산 행동 등)을 준수하도록 계층 구조의 일부에 대한 액세스를 제한할 수 있지만(MAY) 콘텐츠 또는 콘텐츠 제공자에 따른 우대를 적용하면 안 됩니다(MUST NOT).

  • [C-1-5] MediaSession.Callback#onMediaButtonEvent의 KEYCODE_MEDIA_NEXT로 KEYCODE_HEADSETHOOK 또는 KEYCODE_MEDIA_PLAY_PAUSE를 두 번 탭하는 방식을 고려해야 합니다(MUST).

3.15. 인스턴트 앱

인스턴트 앱을 지원하는 기기 구현은 다음과 같은 요구사항을 충족해야 합니다(MUST).

  • [C-1-1] 인스턴트 앱에는 android:protectionLevel을 "instant"로 설정하는 권한만 부여해야 합니다(MUST).
  • [C-1-2] 다음 중 하나에 해당하지 않는 이상 인스턴트 앱은 암시적 인텐트를 통해 설치된 앱과 상호작용하면 안 됩니다(MUST NOT).
    • 구성요소의 인텐트 패턴이 노출되었고 CATEGORY_BROWSABLE을 보유하는 경우
    • 작업이 ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE 중 하나인 경우
    • 타겟은 android:visibleToInstantApps를 통해 명시적으로 노출됩니다.
  • [C-1-3] 구성요소가 android:visibleToInstantApps를 통해 노출되지 않는 이상 인스턴트 앱이 설치된 앱과 명시적으로 상호작용하면 안 됩니다(MUST NOT).
  • [C-1-4] 인스턴트 앱이 설치된 애플리케이션에 명시적으로 연결되지 않는 이상 설치된 앱이 기기의 인스턴트 앱에 관한 세부정보를 확인하면 안 됩니다(MUST NOT).

  • 기기 구현은 인스턴트 앱과의 상호작용을 위해 다음과 같은 사용자 어포던스를 제공해야 합니다(MUST). AOSP는 기본 시스템 UI, 설정 및 런처 요구사항을 충족합니다. 기기 구현은 다음을 충족해야 합니다.

    • [C-1-5] 각 개별 앱 패키지에 관해 로컬에서 캐싱된 인스턴트 앱을 보고 삭제할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-1-6] 인스턴트 앱이 포그라운드에서 실행되는 동안 접을 수 있는 영구적인 사용자 알림을 제공해야 합니다(MUST). 이러한 사용자 알림은 인스턴트 앱은 설치할 필요가 없다는 내용을 포함해야 하며, 사용자를 설정의 애플리케이션 정보 화면으로 안내하는 사용자 어포던스를 제공해야 합니다(MUST). 작업이 Intent.ACTION_VIEW로 설정되고 'http' 또는 'https'의 스키마를 포함하는 인텐트를 사용하여 정의된 웹 인텐트를 통해 실행된 인스턴트 앱의 경우, 사용자가 추가 사용자 어포던스를 통해 인스턴트 앱을 실행하지 않고 구성된 웹브라우저로 관련 링크를 실행할 수 있도록 허용해야 합니다(SHOULD)(기기에 브라우저가 있는 경우).
    • [C-1-7] 기기에서 최근 항목 기능을 사용할 수 있는 경우 실행 중인 인스턴트 앱을 최근 항목 기능에서 액세스하도록 허용해야 합니다(MUST).

  • [C-1-8] 여기 SDK에 나열된 인텐트의 인텐트 핸들러가 포함된 애플리케이션 또는 서비스 구성요소를 하나 이상 미리 로드하고 인텐트가 인스턴트 앱에 표시되도록 설정해야 합니다(MUST).

3.16. 호환 기기 페어링

Android에는 호환 기기의 연결을 보다 효과적으로 관리하고 앱이 이 기능에 액세스할 수 있도록 CompanionDeviceManager API를 제공하기 위한 호환 기기 페어링 지원 기능이 포함되어 있습니다.

호환 기기 페어링 기능을 지원하는 기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-3](2024년 2월 5일 미리보기)

  • [C-1-3] 사용자가 호환 기기의 존재 및 작동 가능 여부를 선택/확인할 수 있는 사용자 어포던스를 제공해야 하며(MUST) 이는 추가나 수정 없이 AOSP에서 구현된 동일한 메시지를 사용해야 합니다(MUST).

새로운 요구사항 종료

3.17. 무거운 앱

기능 FEATURE_CANT_SAVE_STATE를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 시스템에서 실행되는 cantSaveState를 지정하는 앱을 한 번에 하나만 설치해야 합니다(MUST). 사용자가 명시적으로 종료하지 않은 상태에서 이러한 앱에서 벗어나는 경우(예: 시스템에 남은 활성 활동이 없는 상태에서 뒤로를 누르는 대신 시스템의 활성 활동을 그대로 둔 상태에서 홈을 누르는 경우) 기기 구현은 포그라운드 서비스와 같이 계속해서 실행될 것으로 예상되는 다른 작업의 경우와 마찬가지로, RAM에서 해당 앱을 우선순위로 지정해야 합니다(MUST). 이러한 앱이 백그라운드에 있는 동안에는 시스템이 계속해서 전원 관리 기능을 앱에 적용할 수 있습니다(예: CPU 및 네트워크 액세스 제한).
  • [C-1-2] 사용자가 cantSaveState 속성으로 선언된 두 번째 앱을 실행하면 일반 상태 저장/복원 메커니즘에 참여하지 않는 앱을 선택할 수 있도록 UI 어포던스를 제공해야 합니다(MUST).
  • [C-1-3] cantSaveState를 지정하는 앱에 정책의 다른 변경사항을 적용하면 안 됩니다(MUST NOT, 예: CPU 성능 또는 스케줄링 우선순위 지정 변경).

기능 FEATURE_CANT_SAVE_STATE를 선언하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 앱에서 설정한 cantSaveState 속성을 무시해야 하며(MUST) 이러한 속성에 따른 앱 동작을 변경하면 안 됩니다(MUST NOT).

3.18. 연락처

Android에는 애플리케이션이 기기에 저장된 연락처 정보를 관리할 수 있는 Contacts Provider API가 포함되어 있습니다. 기기에 직접 입력된 연락처 데이터는 일반적으로 웹 서비스와 동기화되지만 기기에 로컬로만 상주할 수 있습니다(MAY). 기기에만 저장된 연락처를 로컬 연락처라고 합니다.

원시 연락처의 열인 ACCOUNT_NAME 및 ACCOUNT_TYPE이 계정의 해당 Account.name 및 Account.type 필드와 일치할 때 RawContacts는 계정과 '연결'되거나 계정에 '저장'됩니다.

기본 로컬 계정: 기기에만 저장되고 AccountManager의 계정과 연결되지 않은 원시 연락처의 계정으로, ACCOUNT_NAME 및 ACCOUNT_TYPE 열이 null 값으로 설정된 상태로 생성됩니다.

맞춤 로컬 계정: 기기에만 저장되고 AccountManager의 계정과 연결되지 않은 원시 연락처의 계정으로, ACCOUNT_NAME 및 ACCOUNT_TYPE 열이 최소 하나 이상의 null이 아닌 값으로 설정된 상태로 생성됩니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 맞춤 로컬 계정을 만들지 않는 것을 적극 권장합니다(STRONGLY RECOMMENDED).

맞춤 로컬 계정을 사용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 맞춤 로컬 계정의 ACCOUNT_NAME이 ContactsContract.RawContacts.getLocalAccountName에서 반환되어야 합니다(MUST).
  • [C-1-2] 맞춤 로컬 계정의 ACCOUNT_TYPE이 ContactsContract.RawContacts.getLocalAccountType에서 반환되어야 합니다(MUST).
  • [C-1-3] 기본 로컬 계정을 사용하는 서드 파티 애플리케이션이 삽입한 원시 연락처(즉, ACCOUNT_NAME 및 ACCOUNT_TYPE에 null 값 설정)는 맞춤 로컬 계정에 삽입되어야 합니다(MUST).
  • [C-1-4] 맞춤 로컬 계정에 삽입된 원시 연락처는 계정을 추가 또는 삭제할 때 삭제되어서는 안 됩니다(MUST NOT).
  • [C-1-5] 맞춤 로컬 계정에서 삭제 작업을 실행하면 CALLER_IS_SYNCADAPTER 매개변수가 true로 설정된 경우처럼 원시 연락처가 즉시 삭제되어야 합니다(MUST). 이는 CALLER\_IS\_SYNCADAPTER 매개변수가 false로 설정되거나 지정되지 않은 경우에도 마찬가지입니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

3.19. 언어 설정

[3.19. 언어 설정](2024년 2월 26일 미리보기)

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 성별이 적용된 번역을 지원하지 않는 언어에 대해 성별 언어 처리를 선택하는 사용자 어포던스를 제공하면 안 됩니다(MUST NOT). 자세한 내용은 문법 리소스를 참고하세요.

새로운 요구사항 종료

4. 애플리케이션 패키징 호환성

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 공식 Android SDK에 포함된 'aapt' 도구로 생성한 Android '.apk' 파일을 설치하고 실행할 수 있어야 합니다(MUST).

    • 위의 요구사항을 충족하기가 어려울 수 있으므로 기기 구현은 AOSP 참조 구현의 패키지 관리 시스템을 사용하는 것이 좋습니다(RECOMMENDED).

  • [C-0-2] APK 서명 체계 v3.1, APK 서명 체계 v3, APK 서명 체계 v2, JAR 서명을 사용하여 '.apk' 파일 인증을 지원해야 합니다(MUST).

  • [C-0-3] 파일이 다른 호환 기기에 제대로 설치되거나 실행되지 않을 수 있으므로 .apk, Android 매니페스트, Dalvik 바이트 코드, RenderScript 바이트 코드 형식을 확장해서는 안 됩니다(MUST NOT).

  • [C-0-4] 패키지의 현재 '기록 설치 프로그램' 외의 앱이 DELETE_PACKAGE 권한 관련 SDK의 설명처럼 사용자의 확인 없이 앱을 자동으로 설치 제거하도록 허용하면 안 됩니다(MUST NOT). 유일한 예외는 PACKAGE_NEEDS_VERIFICATION 인텐트를 처리하는 시스템 패키지 인증 앱과 ACTION_MANAGE_STORAGE 인텐트를 처리하는 저장소 관리 앱입니다.

  • [C-0-5] android.settings.MANAGE_UNKNOWN_APP_SOURCES 인텐트를 처리하는 활동이 있어야 합니다(MUST).

  • [C-0-6] 설치를 요청하는 앱이 다음과 같은 모든 요구사항을 충족하지 않는 이상 알 수 없는 소스의 애플리케이션 패키지를 설치하면 안 됩니다(MUST NOT).

    • REQUEST_INSTALL_PACKAGES 권한을 선언하거나 android:targetSdkVersion을 24 이하로 설정해야 합니다(MUST).
    • 알 수 없는 출처의 앱을 설치할 수 있도록 사용자가 권한을 부여한 상태여야 합니다(MUST).

  • 애플리케이션별로 알 수 없는 소스의 앱 설치를 위한 권한을 부여/취소할 수 있도록 사용자 어포던스를 제공해야 하지만(SHOULD) 기기 구현에 이러한 옵션을 추가하고 싶지 않다면 노옵(no-op)으로 구현한 다음 startActivityForResult()에 RESULT_CANCELED를 반환할 수도 있습니다(MAY). 하지만 이러한 경우에도 옵션에 표시되지 않는 이유를 사용자에게 표시해야 합니다(SHOULD).

  • [C-0-7] 같은 시스템 API PackageManager.setHarmfulAppWarning에 의해 잠재적으로 위험하다고 표시된 애플리케이션의 활동을 실행하기 전에 경고 대화상자와 시스템 API PackageManager.setHarmfulAppWarning을 통해 사용자에게 제공되는 경고 문자열을 표시해야 합니다(MUST).

  • 경고 대화상자에서 애플리케이션을 설치 제거할지 아니면 실행할지 선택할 수 있도록 사용자 어포던스를 제공해야 합니다(SHOULD).

  • [C-0-8] 여기서 문서로 확인할 수 있듯이 증분 파일 시스템 지원을 구현해야 합니다(MUST).

  • [C-0-9] APK 서명 체계 v4와 APK 서명 체계 v4.1을 사용하여 .apk 파일 인증을 지원해야 합니다(MUST).

5. 멀티미디어 호환성

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] MediaCodecList에 의해 선언된 모든 코덱마다 섹션 5.1에 정의된 미디어 형식, 인코더, 디코더, 파일 유형, 컨테이너 형식을 지원해야 합니다(MUST).
  • [C-0-2] MediaCodecList를 통해 서드 파티 애플리케이션에 제공되는 인코더, 디코더 지원을 선언하고 보고해야 합니다(MUST).
  • [C-0-3] 인코딩 가능한 모든 형식을 제대로 디코딩하여 서드 파티 앱에 제공할 수 있어야 합니다(MUST). 여기에는 인코드가 생성하는 모든 비트스트림과 CamcorderProfile에서 보고되는 프로필이 포함됩니다.

기기 구현은 다음을 충족해야 합니다.

  • 최소 코덱 지연 시간을 목표로 삼아야 합니다. 즉, 다음을 충족해야 합니다(SHOULD).
    • 입력 버퍼를 소비하고 저장하면 안 되며(SHOULD NOT) 처리된 후에만 입력 버퍼를 반환해야 합니다.
    • 디코딩된 버퍼를 SPS 등의 표준으로 명시된 시간을 초과하여 유지하면 안 됩니다(SHOULD NOT).
    • 인코딩된 버퍼를 GOP 구조에서 요구하는 시간을 초과하여 유지하면 안 됩니다(SHOULD NOT).

아래 섹션에 나열된 모든 코덱은 Android 오픈소스 프로젝트의 기본 Android 구현에서 소프트웨어 구현으로 제공됩니다.

Google이나 Open Handset Alliance 모두 이러한 코덱이 서드 파티 특허로부터 자유롭다는 내용을 진술하지 않습니다. 이 소스 코드를 하드웨어나 소프트웨어 제품에 사용하려는 사용자는 이 코드를 오픈소스 소프트웨어나 셰어웨어 등에 구현할 때 관련 특허 소유자의 특허 라이선스가 요구될 수 있음에 유의해야 합니다.

5.1. 미디어 코덱

5.1.1. 오디오 인코딩

자세한 내용은 5.1.3. 오디오 코덱 세부정보를 참고하세요.

android.hardware.microphone을 선언하는 기기 구현은 다음과 같은 오디오 형식을 인코딩하여 서드 파티 앱에 제공할 수 있도록 지원해야 합니다(MUST).

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

모든 오디오 인코더는 다음을 지원해야 합니다(MUST).

5.1.2. 오디오 디코딩

자세한 내용은 5.1.3. 오디오 코덱 세부정보를 참고하세요.

android.hardware.audio.output 기능 지원을 선언하는 기기 구현은 다음과 같은 오디오 형식의 디코딩을 지원해야 합니다.

  • [C-1-1] MPEG-4 AAC 프로필(AAC LC)
  • [C-1-2] MPEG-4 HE AAC 프로필(AAC+)
  • [C-1-3] MPEG-4 HE AACv2 프로필(향상된 AAC+)
  • [C-1-4] AAC ELD(향상된 저지연 AAC)
  • [C-1-11] xHE-AAC(USAC 기준 프로필 및 ISO/IEC 23003-4 동적 범위 제어 프로필을 포함하는 ISO/IEC 23003-3 확장형 HE AAC 프로필)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] 최대 24비트, 192kHz 샘플 속도 및 8채널의 고해상도 오디오 형식을 비롯한 PCM/WAVE. 이러한 요구사항은 디코딩에만 적용되며, 기기는 재생 단계가 진행되는 동안 다운샘플 및 다운믹스가 가능합니다.
  • [C-1-10] Opus

기기 구현이 android.media.MediaCodec API의 기본 AAC 오디오 디코더를 통해 멀티채널 스트림(3개 이상의 채널)의 AAC 입력 버퍼를 PCM에 디코딩하도록 지원하는 경우 다음을 지원해야 합니다(MUST).

  • [C-2-1] 다운믹스 없이 디코딩이 실행되어야 합니다(예: 5.0 AAC 스트림은 PCM의 5채널로, 5.1 AAC 스트림은 PCM의 6채널로 디코딩)(MUST).
  • [C-2-2] ISO/IEC 14496-3의 '동적 범위 제어(DRC)'에 정의된 것처럼 동적 범위 메타데이터가 있어야 하며 오디오 디코더의 동적 범위 관련 동작 구성을 위한 android.media.MediaFormat DRC 키가 있어야 합니다(MUST). AAC DRC 키는 API 21에서 도입되었으며 KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, KEY_AAC_ENCODED_TARGET_LEVEL입니다.
  • [C-SR-1] 모든 AAC 오디오 디코더가 위의 C-2-1 및 C-2-2 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

USAC 오디오, MPEG-D(ISO/IEC 23003-4) 디코딩 시:

  • [C-3-1] 음량 및 DRC 메타데이터를 MPEG-D DRC 동적 범위 제어 프로필 레벨 1에 따라 변환 및 적용해야 합니다(MUST).
  • [C-3-2] 디코더가 android.media.MediaFormat 키(KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 및 KEY_AAC_DRC_EFFECT_TYPE)로 설정된 구성에 따라 동작해야 합니다(MUST).

MPEG-4 AAC, HE AAC, HE AACv2 프로필 디코더:

  • ISO/IEC 23003-4 동적 범위 제어 프로필을 사용하여 음량 및 동적 범위를 지원할 수 있습니다(MAY).

ISO/IEC 23003-4가 지원되고 ISO/IEC 23003-4 및 ISO/IEC 14496-3 메타데이터가 둘 다 디코딩된 비트스트림에 있는 경우:

  • ISO/IEC 23003-4 메타데이터가 우선해야 합니다(SHALL).

모든 오디오 디코더가 다음과 같은 출력을 지원해야 합니다(MUST).

기기 구현이 android.media.MediaCodec API의 기본 AAC 오디오 디코더를 통해 멀티채널 스트림(3개 이상의 채널)의 AAC 입력 버퍼를 PCM에 디코딩하도록 지원하는 경우 다음을 지원해야 합니다(MUST).

  • [C-7-1] 콘텐츠가 스테레오로 다운믹스되는지(2라는 값을 사용할 때) 또는 기본 채널 수를 사용하여 출력되는지(채널 수 이상인 값을 사용할 때) 제어하기 위해 KEY_MAX_OUTPUT_CHANNEL_COUNT 키로 디코딩을 사용하는 애플리케이션이 구성할 수 있어야 합니다(MUST). 예를 들어 6 이상의 값은 5.1 콘텐츠가 제공될 때 6개 채널을 출력하도록 디코더를 구성합니다.
  • [C-7-2] 디코딩 시 디코더는 android.media.AudioFormat 상수(예: CHANNEL_OUT_5POINT1)를 사용하여 KEY_CHANNEL_MASK 키와 함께 출력 형식에 사용되고 있는 채널 마스크를 알려야 합니다(MUST).

기기 구현이 기본 AAC 오디오 디코더 외의 오디오 디코더를 지원하고 압축된 다중 채널 콘텐츠가 제공될 때 다중 채널 오디오(예: 채널 3개 이상)를 출력할 수 있는 경우 다음을 충족해야 합니다.

  • [C-SR-2] 콘텐츠가 스테레오로 다운믹스되는지(2라는 값을 사용할 때) 또는 기본 채널 수를 사용하여 출력되는지(채널 수 이상인 값을 사용할 때) 제어하기 위해 KEY_MAX_OUTPUT_CHANNEL_COUNT 키로 디코딩을 사용하는 애플리케이션이 디코더를 구성할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 예를 들어 6 이상의 값은 5.1 콘텐츠가 제공될 때 6개 채널을 출력하도록 디코더를 구성합니다.
  • [C-SR-3] 디코딩 시 디코더가 android.media.AudioFormat 상수(예: CHANNEL_OUT_5POINT1)를 사용하여 KEY_CHANNEL_MASK 키와 함께 출력 형식에 사용되고 있는 채널 마스크를 알릴 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.1.3. 오디오 코덱 세부정보

형식/코덱 세부정보 지원해야 하는 파일 유형/컨테이너 형식
MPEG-4 AAC 프로필
(AAC LC)		 표준 샘플링 레이트가 8~48kHz인 모노/스테레오/5.0/5.1 콘텐츠 지원
  • 3GPP(.3gp)
  • MPEG-4(.mp4, .m4a)
  • ADTS 원본 AAC(.aac, ADIF 지원 안 됨)
  • MPEG-TS(.ts, 탐색 불가, 디코딩 전용)
  • Matroska(.mkv, 디코딩 전용)
MPEG-4 HE AAC 프로필(AAC+) 표준 샘플링 레이트가 16~48kHz인 모노/스테레오/5.0/5.1 콘텐츠 지원
  • 3GPP(.3gp)
  • MPEG-4(.mp4, .m4a)
MPEG-4 HE AACv2
프로필(향상된 AAC+)		 표준 샘플링 레이트가 16~48kHz인 모노/스테레오/5.0/5.1 콘텐츠 지원
  • 3GPP(.3gp)
  • MPEG-4(.mp4, .m4a)
AAC ELD(개선된 저지연 AAC) 표준 샘플링 레이트가 16~48kHz인 모노/스테레오 콘텐츠 지원
  • 3GPP(.3gp)
  • MPEG-4(.mp4, .m4a)
USAC 표준 샘플링 레이트가 7.35~48kHz인 모노/스테레오 콘텐츠 지원 MPEG-4(.mp4, .m4a)
AMR-NB 8kHz에서 샘플링된 4.75~12.2kbps 3GPP(.3gp)
AMR-WB AMR-WB(Adaptive Multi-Rate - Wideband) 음성 코덱 정의처럼 16kHz에서 샘플링된 초당 6.60kbit~23.85kbit인 9레이트 3GPP(.3gp)
FLAC 인코더와 디코더 모두 최소 모노/스테레오 모드가 지원되어야 합니다(MUST). 최대 192kHz의 샘플링 레이트와 16비트 및 24비트 해상도를 지원해야 합니다. FLAC 24비트 오디오 데이터 처리를 부동 소수점 오디오 구성과 함께 제공해야 합니다(MUST).
  • FLAC(.flac)
  • MPEG-4(.mp4, .m4a, 디코딩 전용)
  • Matroska(.mkv, 디코딩 전용)
MP3 모노/스테레오 8-320Kbps 상수(CBR) 또는 가변 비트 전송률(VBR)
  • MP3(.mp3)
  • MPEG-4(.mp4, .m4a, 디코딩 전용)
  • Matroska(.mkv, 디코딩 전용)
MIDI MIDI 유형 0 및 1. DLS 버전 1 및 2. XMF 및 모바일 XMF. 벨소리 형식 RTTTL/RTX, OTA, iMelody 지원
  • 유형 0 및 1(.mid, .xmf, .mxmf)
  • RTTTL/RTX(.rtttl, .rtx)
  • iMelody(.imy)
Vorbis
  • Ogg(.ogg)
  • MPEG-4(.mp4, .m4a, 디코딩 전용)
  • Matroska(.mkv)
  • Webm(.webm)
PCM/WAVE PCM 코덱은 16비트 선형 PCM 및 16비트 부동을 지원해야 합니다(MUST). WAVE 추출기는 16비트, 24비트, 32비트 선형 PCM, 32비트 부동(최대 하드웨어 제한 레이트)을 지원해야 합니다. 샘플링 레이트는 8kHz~192kHz에서 지원되어야 합니다(MUST). WAVE(.wav)
Opus 디코딩: 샘플링 레이트가 8,000, 12,000, 16,000, 24,000, 48,000Hz인 모노, 스테레오, 5.0, 5.1 콘텐츠를 지원합니다.
인코딩: 샘플링 레이트가 8,000, 12,000, 16,000, 24,000, 48,000Hz인 모노 및 스테레오 콘텐츠를 지원합니다.
  • Ogg(.ogg)
  • MPEG-4(.mp4, .m4a, 디코딩 전용)
  • Matroska(.mkv)
  • Webm(.webm)

5.1.4. 이미지 인코딩

자세한 내용은 5.1.6. 이미지 코덱 세부정보를 참고하세요.

기기 구현은 다음과 같은 이미지 인코딩을 인코딩할 수 있도록 지원해야 합니다(MUST).

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [C-0-4] AVIF
    • 기기가 BITRATE_MODE_CQ 및 기준 프로필을 지원해야 합니다.

미디어 유형 MIMETYPE_IMAGE_ANDROID_HEIC에 android.media.MediaCodec을 통한 HEIC 인코딩을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] BITRATE_MODE_CQ 비트 전송률 제어 모드, HEVCProfileMainStill 프로필 및 512x512px 프레임 크기를 지원하는 하드웨어 가속 HEVC 인코더 코덱을 제공해야 합니다(MUST).

5.1.5. 이미지 디코딩

자세한 내용은 5.1.6. 이미지 코덱 세부정보를 참고하세요.

기기 구현은 다음과 같은 이미지 인코딩을 디코딩할 수 있도록 지원해야 합니다(MUST).

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Raw
  • [C-0-7] AVIF(기준 프로필)

HEVC 동영상 디코딩을 지원하는 기기 구현은 다음을 충족해야 합니다. * [C-1-1] HEIF(HEIC) 이미지 디코딩을 지원해야 합니다(MUST).

높은 비트 심도 형식(채널당 9비트 이상)을 지원하는 이미지 디코더

  • [C-2-1] 애플리케이션에 의해 요청된 경우 android.graphics.Bitmap의 ARGB_8888 config 등을 통해 8비트 동등 형식 출력을 지원해야 합니다(MUST).

5.1.6. 이미지 코덱 세부정보

형식/코덱 세부정보 지원되는 파일 형식/컨테이너 형식
JPEG 기본+프로그레시브 JPEG(.jpg)
GIF GIF(.gif)
PNG PNG(.png)
BMP BMP(.bmp)
WebP WebP(.webp)
원시 데이터 ARW(.arw), CR2(.cr2), DNG(.dng), NEF(.nef), NRW(.nrw), ORF(.orf), PEF(.pef), RAF(.raf), RW2(.rw2), SRW(.srw)
HEIF 이미지, 이미지 컬렉션, 이미지 시퀀스 HEIF(.heif), HEIC(.heic)
AVIF(기준 프로필) 이미지, 이미지 컬렉션, 이미지 시퀀스 기준 프로필 HEIF 컨테이너(.avif)

MediaCodec API를 통해 노출된 이미지 인코더 및 디코더

  • [C-1-1] CodecCapabilities를 통해 YUV420 8:8:8 유동적인 색상 형식(COLOR_FormatYUV420Flexible)을 지원해야 합니다(MUST).

  • [C-SR-1] 입력 Surface 모드의 경우 RGB888 색상 형식을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-1-3] 평면 또는 반평면 YUV420 8:8:8 색상 형식인 COLOR_FormatYUV420PackedPlanar(COLOR_FormatYUV420Planar와 같음) 또는 COLOR_FormatYUV420PackedSemiPlanar(COLOR_FormatYUV420SemiPlanar와 같음)를 1개 이상 지원해야 합니다(MUST). 둘 다 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.1.7. 동영상 코덱

  • 웹 동영상 스트리밍 및 화상 회의 서비스의 무난한 품질을 위해서는 기기 구현이 요구사항을 충족하는 하드웨어 VP8 코덱을 사용해야 합니다(SHOULD).

기기 구현이 동영상 디코더 또는 인코더를 포함되는 경우:

  • [C-1-1] 동영상 코덱이 표준 및 구성에 명시된 압축 및 압축 해제된 최대 실행 가능한 프레임을 수용하는 출력 및 입력 bytebuffer를 지원해야 하지만(MUST) 과할당하면 안 됩니다.

  • [C-1-2] 동영상 인코더 및 디코더가 CodecCapabilities를 통해 YUV420 8:8:8 유동적인 색상 형식(COLOR_FormatYUV420Flexible)을 지원해야 합니다(MUST).

  • [C-1-3] 동영상 인코더 및 디코더가 평면 또는 반평면 YUV420 8:8:8 색상 형식인 COLOR_FormatYUV420PackedPlanar(COLOR_FormatYUV420Planar와 같음) 또는 COLOR_FormatYUV420PackedSemiPlanar(COLOR_FormatYUV420SemiPlanar와 같음)를 1개 이상 지원해야 합니다(MUST). 둘 다 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-1] 동영상 인코더 및 디코더가 하드웨어에 최적화된 평면 또는 반평면 YUV420 8:8:8 색상 형식(YV12, NV12, NV21 또는 이에 준하는 공급업체 최적화 형식)을 1개 이상 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-1-5] 비트 심도가 높은 형식(채널당 9비트 이상)을 지원하는 동영상 인코더는 애플리케이션에서 요청한 경우 8비트 동등 형식에 대한 출력을 지원해야 합니다(MUST). 이는 android.media.MediaCodecInfo를 통해 YUV420 8:8:8 색상 형식을 지원하는 방식으로 반영되어야 합니다.

Display.HdrCapabilities를 통해 HDR 프로필 지원을 알리는 기기는 다음을 충족해야 합니다.

  • [C-2-1] HDR 정적 메타데이터 파싱 및 처리를 지원해야 합니다(MUST).

MediaCodecInfo.CodecCapabilities 클래스의 FEATURE_IntraRefresh를 통해 내부 새로고침 지원을 알리는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 10~60프레임의 새로고침 기간을 지원하고 구성된 새로고침 기간의 20% 내로 정확하게 작동해야 합니다(MUST).

애플리케이션이 KEY_COLOR_FORMAT 형식 키를 사용하여 달리 지정하지 않는 이상 동영상 디코더 구현은 다음을 충족해야 합니다.

  • [C-4-1] Surface 출력을 사용하여 구성된 경우 하드웨어 디스플레이에 최적화된 색상 형식을 기본 설정해야 합니다(MUST).
  • [C-4-2] Surface 출력을 사용하지 않도록 구성된 경우 CPU 판독에 최적화된 YUV420 8:8:8 색상 형식을 기본 설정해야 합니다(MUST).

5.1.8. 동영상 코덱 목록

형식/코덱 세부정보 지원해야 하는 파일 유형/컨테이너 형식
H.263
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
  • Matroska(.mkv, 디코딩 전용)
H.264 AVC 자세한 내용은 섹션 5.2 및 5.3을 참고하세요.
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
  • MPEG-2 TS(.ts, 탐색 불가)
  • Matroska(.mkv, 디코딩 전용)
H.265 HEVC 자세한 내용은 섹션 5.3을 참고하세요.
  • MPEG-4(.mp4)
  • Matroska(.mkv, 디코딩 전용)
MPEG-2 기본 프로필
  • MPEG2-TS(.ts, 탐색 불가)
  • MPEG-4 (.mp4, 디코딩 전용)
  • Matroska(.mkv, 디코딩 전용)
MPEG-4 SP
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
  • Matroska(.mkv, 디코딩 전용)
VP8 자세한 내용은 섹션 5.2 및 5.3을 참고하세요.
VP9 자세한 내용은 섹션 5.3을 참고하세요.
AV1 자세한 내용은 섹션 5.2 및 섹션 5.3을 참고하세요.
  • MPEG-4(.mp4)
  • Matroska(.mkv, 디코딩 전용)

5.1.9. 미디어 코덱 보안

기기 구현 시 아래 설명처럼 미디어 코덱 보안 기능을 준수하는지 확인해야 합니다(MUST).

Android에는 크로스 플랫폼 멀티미디어 가속 API인 OMX는 물론 오버헤드가 낮은 멀티미디어 가속 API인 Codec 2.0까지 지원합니다.

멀티미디어를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Android 오픈소스 프로젝트에서처럼 OMX나 Codec 2.0 API(또는 둘 다)를 통해 미디어 코덱을 지원해야 하며(MUST), 보안 보호를 사용 중지하거나 우회하면 안 됩니다. 모든 코덱이 OMX 또는 Codec 2.0 API를 사용해야 한다(MUST)고 한정하는 것은 아니지만 API 중 최소한 하나 이상은 사용할 수 있어야 하고(MUST) 가용 API 지원에는 보안 보호가 포함되어야 합니다(MUST).
  • [C-SR-1] Codec 2.0 API에 지원을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Codec 2.0 API를 지원하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 기기에서 지원하는 각 미디어 형식 및 유형(인코더 또는 디코더)과 관련하여 Android 오픈소스 프로젝트의 해당 OMX 소프트웨어 코덱(제공되는 경우)을 포함해야 합니다(MUST).
  • [C-2-2] 이름이 'OMX.google.'로 시작하는 코덱은 Android 오픈소스 프로젝트 소스 코드에 기반해야 합니다(MUST).
  • [C-SR-2] OMX 소프트웨어 코덱은 메모리 매퍼 외의 하드웨어 드라이버 액세스가 없는 코덱 프로세스에서 실행할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Codec 2.0 API를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 기기에서 지원하는 각 미디어 형식 및 유형(인코더 또는 디코더)과 관련하여 Android 오픈소스 프로젝트의 해당 Codec 2.0 소프트웨어 코덱(제공되는 경우)을 포함해야 합니다(MUST).
  • [C-3-2] Android 오픈소스 프로젝트에서 제공되는 Codec 2.0 소프트웨어 코덱을 소프트웨어 코덱 프로세스에 포함하여, 활용하는 소프트웨어 코덱 범위를 좁힐 수 있어야 합니다(MUST).
  • [C-3-3] 이름이 'c2.android.'로 시작하는 코덱은 Android 오픈소스 프로젝트 소스 코드에 기반해야 합니다(MUST).

5.1.10. 미디어 코덱 특징 지정

미디어 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] MediaCodecInfo API를 통해 미디어 코덱 특정 지정의 올바른 값을 반환해야 합니다(MUST).

특히 다음 항목이 중요합니다.

  • [C-1-2] 이름이 'OMX.'로 시작하는 코덱은 OMX API를 사용해야 하며 OMX IL 이름 지정 가이드라인을 준수하는 이름을 보유해야 합니다(MUST).
  • [C-1-3] 이름이 'c2.'로 시작하는 코덱은 Codec 2.0 API를 사용해야 하며 Android용 Codec 2.0 이름 지정 가이드라인을 준수하는 이름을 보유해야 합니다(MUST).
  • [C-1-4] 이름이 'OMX.google.' 또는 'c2.android.'로 시작하는 코덱은 공급업체 또는 하드웨어 가속으로 특성이 지정되면 안 됩니다(MUST NOT).
  • [C-1-5] 메모리 할당자 및 매퍼 외의 하드웨어 드라이버에 대한 액세스를 보유한 코덱 프로세스(공급업체 또는 시스템)에서 실행되는 코덱은 소프트웨어 전용으로 특성이 지정되면 안 됩니다(MUST NOT).
  • [C-1-6] Android 오픈소스 프로젝트에 없거나 해당 프로젝트의 소스 코드에 기반하지 않는 코덱은 공급업체로 특성이 지정되어야 합니다(MUST).
  • [C-1-7] 하드웨어 가속을 활용하는 코덱은 하드웨어 가속으로 특성이 지정되어야 합니다(MUST).
  • [C-1-8] 코덱 이름은 혼동을 일으키면 안 됩니다(MUST NOT). 예를 들어 이름이 'decoders'인 코덱은 디코딩을 지원해야 하며(MUST) 이름이 'encoders'인 코덱은 인코딩을 지원해야 합니다(MUST). 이름에 미디어 형식이 포함된 코덱은 이러한 형식을 지원해야 합니다(MUST).

기기 구현이 동영상 코덱을 지원하는 경우:

  • [C-2-1] 모든 동영상 코덱은 코덱으로 지원되는 경우 다음 크기별로 달성 가능한 프레임 속도 데이터를 공개해야 합니다(MUST)().
SD(저화질) SD(고화질) HD 720p HD 1080p UHD
동영상 해상도
  • 176x144px(H263, MPEG2, MPEG4)
  • 352x288px(MPEG4 인코더, H263, MPEG2)
  • 320x180px(VP8, VP8)
  • 320x240px(기타)
  • 704x576px(H263)
  • 640x360px(VP8, VP9)
  • 640x480px(MPEG4 인코더)
  • 720x480px(기타, AV1)
  • 1408x1152px(H263)
  • 1280x720px(기타, AV1)
 1920x1080px(MPEG4 외, AV1) 3840x2160px(HEVC, VP9, AV1)
  • [C-2-2] 하드웨어 가속으로 특성이 지정되는 동영상 코덱은 성능 포인트 정보를 공개해야 합니다(MUST). 또한 동영상 코덱은 서로 다른 표준 성능 포인트 지원을 받지 않는 이상 지원하는 모든 표준 성능 포인트(PerformancePoint API에 나열됨)를 나열해야 합니다(MUST).
  • 또한 코덱은 나열된 표준 항목 중 하나가 아닌 지속 동영상 성능을 지원하는 경우 확장된 성능 포인트를 게시해야 합니다(SHOULD).

5.2. 동영상 인코딩

기기 구현이 동영상 인코더를 지원하고 서드 파티 앱에 제공하며
MediaFormat.KEY_BITRATE_MODE를 BITRATE_MODE_VBR로 설정하여 인코더가 가변 비트 전송률 모드로 작동하도록 하는 경우 최소 품질 하한선에 영향을 주지 않는 한 인코딩된 비트 전송률은 다음을 충족해야 합니다.

  • 1개의 슬라이딩 윈도우에 걸쳐 intraframe(I-frame) 간격 간의 비트 전송률이 15%를 초과하면 안 됩니다(SHOULD NOT).
  • 1초의 슬라이딩 윈도우에 걸쳐 비트 전송률이 100%를 초과하면 안 됩니다(SHOULD NOT).

기기 구현이 동영상 인코더를 지원하고 이를 서드 파티 앱에 제공하며, MediaFormat.KEY_BITRATE_MODE를 BITRATE_MODE_CBR로 설정하여 인코더가 상수 비트 전송률 모드에서 작동하도록 하는 경우 인코딩된 비트 전송률은 다음을 충족해야 합니다.

  • [C-SR-2] 1초의 슬라이딩 윈도우에 걸쳐 타겟 비트 전송률이 15%를 초과하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).

android.hardware.camera.any 기능 플래그를 통해 대각선 길이가 최소 2.5인치인 내장형 화면 디스플레이를 포함하거나 동영상 출력 포트를 포함하거나 카메라 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] VP8 또는 H.264 동영상 인코더 중 하나 이상의 지원을 포함해야 하며 이를 서드 파티 애플리케이션에 제공해야 합니다(MUST).
  • VP8 및 H.264 동영상 인코더를 둘 다 지원하고 이를 서드 파티 애플리케이션에 제공해야 합니다(SHOULD).

H.264, VP8, VP9 또는 HEVC 동영상 인코더 중 하나를 지원하고 이를 서드 파티 애플리케이션에 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 동적으로 구성 가능한 비트 전송률을 지원해야 합니다(MUST).
  • 동영상 인코더가 입력 버퍼의 타임스탬프를 토대로 즉각적인 프레임 기간을 파악해야 하는 경우(SHOULD) 가변 프레임 속도를 지원해야 하며 해당 프레임 기간에 따라 비트 버킷을 할당해야 합니다(SHOULD).

MPEG-4 SP 동영상 인코더를 지원하고 이를 서드 파티 앱에 제공하는 기기 구현은 다음을 충족해야 합니다.

  • 지원되는 인코더에 대해 구성 가능한 비트 전송률을 동적으로 지원해야 합니다(SHOULD).

기기 구현이 하드웨어 가속 동영상 또는 이미지 인코더를 제공하고 android.camera API를 통해 노출된 연결되었거나 연결 가능한 하드웨어 카메라를 1개 이상 지원하는 경우 다음을 충족해야 합니다.

  • [C-4-1] 모든 하드웨어 가속 동영상 및 이미지 인코더는 하드웨어 카메라에서 인코딩 프레임을 지원해야 합니다(MUST).
  • 모든 동영상 또는 이미지 인코더를 통해 하드웨어 카메라의 인코딩 프레임을 지원해야 합니다(SHOULD).

HDR 인코딩을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 원활한 트랜스코딩 API를 위해 HDR 형식에서 SDR 형식으로 변환할 수 있는 플러그인을 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.2.1. H.263

H.263 인코더를 지원하고 서드 파티 앱에 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기준 프로필 레벨 45를 사용하여 QCIF 해상도(176x144)를 지원해야 합니다(MUST). SQCIF 해상도는 선택사항입니다.

5.2.2. H.264

H.264 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기준 프로필 레벨 3을 지원해야 합니다(MUST). 하지만 ASO(임의 슬라이스 정렬), FMO(탄력적 매크로블록 정렬) 및 RS(중복 슬라이스)는 선택사항입니다. 또한 다른 Android 기기와의 호환성을 유지하기 위해서는 인코더가 ASO, FMO 및 RS를 기준 프로필에 사용하지 않는 것이 좋습니다(RECOMMENDED).
  • [C-1-2] 다음 표에서 SD(표준 화질) 동영상 인코딩 프로필을 지원해야 합니다(MUST).
  • 기본 프로필 레벨 4를 지원해야 합니다(SHOULD).
  • 아래 표에 표시된 것처럼 HD(고화질) 동영상 프로필을 지원해야 합니다(SHOULD).

미디어 API를 통해 720p 또는 1080p 해상도 동영상에 대한 H.264 인코딩 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음 표의 인코딩 프로필을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p
동영상 해상도 320x240px 720x480px 1280x720px 1920x1080px
동영상 프레임 속도 20fps 30fps 30fps 30fps
동영상 비트 전송률 384Kbps 2Mbps 4Mbps 10Mbps

5.2.3. VP8

VP8 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SD 동영상 인코딩 프로필을 지원해야 합니다(MUST).
  • 다음 HD(고화질) 동영상 인코딩 프로필을 지원해야 합니다(SHOULD).
  • [C-1-2] Matroska WebM 파일 작성을 지원해야 합니다(MUST).
  • WebM 프로젝트 RTC 하드웨어 코딩 요구사항을 충족하는 하드웨어 VP8 코덱을 제공하여 웹 동영상 스트리밍 또는 화상 회의 서비스의 무난한 품질을 보장해야 합니다.

미디어 API를 통해 720p 또는 1080p 해상도 동영상에 대한 VP8 인코딩 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음 표의 인코딩 프로필을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p
동영상 해상도 320x180px 640x360px 1280x720px 1920x1080px
동영상 프레임 속도 30fps 30fps 30fps 30fps
동영상 비트 전송률 800Kbps 2Mbps 4Mbps 10Mbps

5.2.4. VP9

VP9 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-2] 프로필 0 레벨 3을 지원해야 합니다(MUST).
  • [C-1-1] Matroska WebM 파일 작성을 지원해야 합니다(MUST).
  • [C-1-3] CodecPrivate 데이터를 생성해야 합니다(MUST).
  • 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원해야 합니다(SHOULD).
  • [C-SR-1] 하드웨어 인코더가 있는 경우 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
SD HD 720p HD 1080p UHD
동영상 해상도 720x480px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30fps
동영상 비트 전송률 1.6Mbps 4Mbps 5Mbps 20Mbps

기기 구현이 미디어 API를 통해 프로필 2 또는 프로필 3을 지원한다고 주장하는 경우:

  • 12비트 형식 지원은 선택사항입니다.

5.2.5. H.265

H.265 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 최대 512x512 해상도까지 기본 프로필 레벨 3을 지원해야 합니다(MUST).
  • [C-SR-1] 하드웨어 인코더가 있는 경우 다음 표에 나온 대로 720x480 SD 프로필과 HD 인코딩 프로필을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
SD HD 720p HD 1080p UHD
동영상 해상도 720x480px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30fps
동영상 비트 전송률 1.6Mbps 4Mbps 5Mbps 20Mbps

5.2.6. AV1

AV1 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 8비트 및 10비트 콘텐츠를 포함한 기본 프로필을 지원해야 합니다(MUST).

  • [C-1-2] 성능 데이터를 게시해야 합니다(MUST). 즉, 아래 표에서 지원되는 해상도의 경우 getSupportedFrameRatesFor() 또는 getSupportedPerformancePoints() API를 통해 성능 데이터를 보고해야 합니다.

  • [C-1-3] HDR 메타데이터를 허용하고 비트스트림으로 출력해야 합니다(MUST).

AV1 인코더가 하드웨어 가속을 사용하는 경우 다음을 충족해야 합니다.

  • [C-2-1] 아래 표에서 최대 HD1080p 인코딩 프로필을 지원해야 합니다(MUST).
SD HD 720p HD 1080p UHD
동영상 해상도 720x480px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30fps
동영상 비트 전송률 5Mbps 8Mbps 16Mbps 50Mbps

5.3. 동영상 디코딩

VP8, VP9, H.264 또는 H.265 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기기 구현은 모든 VP8, VP9, H.264, H.265 코덱의 동일한 스트림 내에서 표준 Android API를 통해 실시간으로 동적 동영상 해상도와 프레임 속도 전환을 지원하고 기기의 각 코덱이 지원하는 최대 해상도까지 지원해야 합니다(MUST).

5.3.1. MPEG-2

MPEG-2 디코더를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기본 프로필 고수준을 지원해야 합니다(MUST).

5.3.2. H.263

H.263 디코더를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기준 프로필 레벨 30(CIF, QCIF 및 SQCIF 해상도@30fps 384kbps) 및 레벨 45(QCIF 및 SQCIF 해상도@30fps 128kbps)를 지원해야 합니다(MUST).

5.3.3. MPEG-4

MPEG-4 디코더를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 단순 프로필 레벨 3을 지원해야 합니다(MUST).

5.3.4. H.264

H.264 디코더를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 기본 프로필 레벨 3.1 및 기준 프로필을 지원해야 합니다(MUST). 하지만 ASO(임의 슬라이스 정렬), FMO(탄력적 매크로블록 정렬) 및 RS(중복 슬라이스)는 선택사항입니다.
  • [C-1-2] 아래 표에 나열되어 있고 기준 프로필 및 기본 프로필 레벨 3.1(720p30 포함)로 인코딩된 SD(표준 화질) 프로필로 동영상을 디코딩할 수 있어야 합니다(MUST).
  • 다음 표에 표시된 것처럼 HD(고화질) 프로필로 동영상을 디코딩할 수 있어야 합니다(SHOULD).

Display.getSupportedModes() 메서드에 의해 보고된 높이가 동영상 해상도 이상인 경우 기기 구현은:

  • [C-2-1] 다음 표의 HD 720p 동영상 디코딩 프로필을 지원해야 합니다(MUST).
  • [C-2-2] 다음 표의 HD 1080p 동영상 디코딩 프로필을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p
동영상 해상도 320x240px 720x480px 1280x720px 1920x1080px
동영상 프레임 속도 30fps 30fps 60fps 30fps(60fps텔레비전)
동영상 비트 전송률 800Kbps 2Mbps 8Mbps 20Mbps

5.3.5. H.265(HEVC)

H.265 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 다음 표에 표시된 것처럼 메인 프로필 레벨 3 기본 티어 및 SD 동영상 디코딩 프로필을 지원해야 합니다(MUST).
  • 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원해야 합니다(SHOULD).
  • [C-1-2] 하드웨어 디코더가 있는 경우 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원해야 합니다(MUST).

Display.getSupportedModes() 메서드에 의해 보고된 높이가 동영상 해상도 이하인 경우:

  • [C-2-1] 기기 구현이 720, 1080, UHD 프로필의 H.265 또는 VP9 디코딩 중 하나 이상을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p UHD
동영상 해상도 352x288px 720x480px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30/60fps(H.265 하드웨어 디코딩을 포함하는 60fps텔레비전) 60fps
동영상 비트 전송률 600Kbps 1.6Mbps 4Mbps 5Mbps 20Mbps

기기 구현이 미디어 API을 통해 HDR 프로필을 지원한다고 주장하는 경우:

  • [C-3-1] 기기 구현이 애플리케이션의 필수 HDR 메타데이터를 허용해야 하며, 비트스트림 또는 컨테이너의 필수 HDR 메타데이터를 추출하고 출력할 수 있게 지원해야 합니다(MUST).
  • [C-3-2] 기기 구현이 기기 화면이나 표준 기기 출력 포트(예: HDMI)에 HDR 콘텐츠를 제대로 표시해야 합니다(MUST).

5.3.6. VP8

VP8 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 다음 표의 SD 디코딩 프로필을 지원해야 합니다(MUST).
  • 요구사항을 충족하는 하드웨어 VP8 코덱을 지원해야 합니다(SHOULD).
  • 다음 표의 HD 디코딩 프로필을 지원해야 합니다(SHOULD).

Display.getSupportedModes() 메서드에 의해 보고된 높이가 동영상 해상도 이상인 경우:

  • [C-2-1] 기기 구현이 다음 표에서 720p 프로필을 지원해야 합니다(MUST).
  • [C-2-2] 기기 구현이 다음 표에서 1080p 프로필을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p
동영상 해상도 320x180px 640x360px 1280x720px 1920x1080px
동영상 프레임 속도 30fps 30fps 30fps(60fps텔레비전) 30(60fps텔레비전)
동영상 비트 전송률 800Kbps 2Mbps 8Mbps 20Mbps

5.3.7. VP9

VP9 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 다음 표에 표시된 것처럼 SD 동영상 디코딩 프로필을 지원해야 합니다(MUST).
  • 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원해야 합니다(SHOULD).

VP9 코덱 및 하드웨어 디코더를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음 표에 표시된 것처럼 HD 디코딩 프로필을 지원해야 합니다(MUST).

Display.getSupportedModes() 메서드에 의해 보고된 높이가 동영상 해상도 이하인 경우:

  • [C-3-1] 기기 구현이 720, 1080, UHD 프로필의 VP9 또는 H.265 디코딩 중 하나 이상을 지원해야 합니다(MUST).
SD(저화질) SD(고화질) HD 720p HD 1080p UHD
동영상 해상도 320x180px 640x360px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30fps(60fpsVP9 하드웨어 디코딩을 포함하는 텔레비전) 60fps
동영상 비트 전송률 600Kbps 1.6Mbps 4Mbps 5Mbps 20Mbps

기기 구현이 'CodecProfileLevel' 미디어 API를 통해 VP9Profile2 또는 VP9Profile3을 지원한다고 주장하는 경우:

  • 12비트 형식 지원은 선택사항입니다.

기기 구현이 미디어 API를 통해 HDR 프로필(VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus)을 지원한다고 주장하는 경우:

  • [C-4-1] 기기 구현이 애플리케이션의 필수 HDR 메타데이터(모든 HDR 프로필에 KEY_HDR_STATIC_INFO, HDR10Plus 프로필에 'KEY_HDR10_PLUS_INFO')를 허용해야 합니다(MUST). 또한 비트스트림 및 컨테이너의 필수 HDR 메타데이터를 추출하고 출력할 수 있도록 지원해야 합니다(MUST).
  • [C-4-2] 기기 구현이 기기 화면이나 표준 기기 출력 포트(예: HDMI)에 HDR 콘텐츠를 제대로 표시해야 합니다(MUST).

5.3.8. Dolby Vision

HDR_TYPE_DOLBY_VISION을 통해 Dolby Vision 디코더 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Dolby Vision을 지원하는 추출기를 제공해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-2](2023년 12월 11일 미리보기)

  • [C-1-2] 기기 화면 또는 표준 동영상 출력 포트(예: HDMI)를 통해 연결된 외부 디스플레이에 Dolby Vision 콘텐츠를 제대로 표시해야 합니다(MUST).

새로운 요구사항 종료

  • [C-1-3] 결합된 Dolby Vision 레이어의 트랙 ID와 이전 버전과 호환되는 기본 레이어(있는 경우)의 트랙 ID를 동일하게 설정해야 합니다(MUST).

5.3.9. AV1

AV1 코덱을 지원하고 서드 파티 애플리케이션에서 사용할 수 있도록 하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 8비트 및 10비트 콘텐츠를 포함한 기본 프로필을 지원해야 합니다(MUST).

하드웨어 가속 디코더를 포함하는 AV1 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] Display.getSupportedModes() 메서드에 의해 보고된 높이가 720p 이상이면 아래 표에서 최소한 HD 720p 동영상 디코딩 프로필을 디코딩할 수 있어야 합니다(MUST).
  • [C-2-2] Display.getSupportedModes() 메서드에 의해 보고된 높이가 1080p 이상이면 아래 표에서 최소한 HD 1080p 동영상 디코딩 프로필을 디코딩할 수 있어야 합니다(MUST).
SD HD 720p HD 1080p UHD
동영상 해상도 720x480px 1280x720px 1920x1080px 3840x2160px
동영상 프레임 속도 30fps 30fps 30fps 30fps
동영상 비트 전송률 5Mbps 8Mbps 16Mbps 50Mbps

미디어 API를 통해 HDR 프로필을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 비트스트림 또는 컨테이너에서 HDR 메타데이터를 추출하고 출력하도록 지원해야 합니다(MUST).
  • [C-3-2] 기기 화면이나 표준 동영상 출력 포트(예: HDMI)에 HDR 콘텐츠를 제대로 표시해야 합니다(MUST).

5.4. 오디오 녹음

이 섹션에 요약된 요구사항의 일부는 SHOULD로 나열되어 있습니다. Android 4.3 이후 출시될 버전의 호환성 정의에서 이를 MUST로 변경할 계획이기 때문입니다. 기존 및 새 Android 기기는 SHOULD로 나열된 이러한 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 그러지 않으면 향후 버전으로 업그레이드될 때 Android 호환성을 유지할 수 없습니다.

5.4.1. 원본 오디오 캡처 및 마이크 정보

android.hardware.microphone를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 성공적으로 열린 AudioRecord 또는 AAudio 입력 스트림의 원시 오디오 콘텐츠 캡처를 허용해야 합니다(MUST). 최소한 다음 특성을 지원해야 합니다(MUST).

  • 다음 특성을 포함하는 원본 오디오 콘텐츠를 캡처할 수 있도록 허용해야 합니다(SHOULD).

    • 형식: 선형 PCM, 16비트 및 24비트
    • 샘플링 레이트: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000Hz
    • 채널: 기기 마이크의 개수와 같은 수의 채널

  • [C-1-2] 업샘플링 없이 위의 샘플링 레이트로 캡처해야 합니다(MUST).

  • [C-1-3] 위에서 주어진 샘플링 레이트가 다운샘플링으로 캡처되는 경우 적절한 앤티앨리어싱 필터를 포함해야 합니다(MUST).

  • AM 라디오, 그리고 다음 특성을 의미하는 원본 오디오 콘텐츠의 DVD 품질 캡처를 허용해야 합니다(SHOULD).

    • 형식: 선형 PCM, 16비트
    • 샘플링 레이트: 22050, 48000Hz
    • 채널: 스테레오

  • [C-1-4] MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED 또는 VOICE_PERFORMANCE를 사용하는 활성 AudioRecord를 위해 MicrophoneInfo API를 선정하고 AudioManager.getMicrophones() API를 통해 서드 파티 애플리케이션에서 액세스할 수 있는 기기에서 제공되는 마이크의 정보를 적절히 채워야 합니다(MUST). AM 라디오, 그리고 원본 오디오 콘텐츠의 DVD 품질 캡처를 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 16000:22050 또는 44100:48000보다 높은 비율에서 업샘플링 없이 캡처해야 합니다(MUST).

  • [C-2-2] 모든 업샘플링 또는 다운샘플링에 적절한 앤티앨리어싱 필터를 포함해야 합니다(MUST).

5.4.2. 음성 인식 캡처

android.hardware.microphone을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 샘플링 레이트 44100 및 48000 중 하나에서 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 오디오 소스를 캡처해야 합니다(MUST).
  • [C-1-2] AudioSource.VOICE_RECOGNITION 오디오 소스에서 오디오 스트림을 녹음하는 경우 모든 노이즈 감소 오디오 처리를 기본으로 사용 중지해야 합니다(MUST).

  • [C-1-3] AudioSource.VOICE_RECOGNITION 오디오 소스의 오디오 스트림을 녹음하는 경우 모든 입력 신호량 자동 조절을 기본으로 중지해야 합니다(MUST).

  • 음성 인식 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수의 대략적인 고정 주파수 대비 진폭(100Hz~4,000Hz에서 ±3dB)을 표시해야 합니다(SHOULD)

  • [C-SR-1] 저주파수 범위의 진폭 레벨(음성 인식 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수 범위 대비 30Hz~100Hz에서 ±20dB)을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-2] 고주파수 범위의 진폭 레벨(음성 인식 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수 범위 대비 4000Hz~22KHz에서 ±30dB)을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 90dB 음압 수준(SPL)(마이크 옆에서 측정됨)에서 재생된 1,000Hz 사인 곡선 톤 소스가 음성 인식 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 16비트 샘플에 대해 1,770~3,530 범위 내 2,500의 RMS를 포함하는 이상적인 응답(또는 부동 소수점/배정밀도 샘플의 경우 -22.35dB ±3dB 풀스케일)을 생성하도록 오디오 입력 민감도를 설정해야 합니다(SHOULD).

  • PCM 진폭 수준이 최소 30dB 범위(-18dB~12dB re 90dB SPL)에 걸친 마이크의 입력 SPL 변화를 선형으로 추적할 수 있도록 음성 인식 오디오 스트림을 녹음해야 합니다(SHOULD).

  • 90dB SPL 마이크 입력 레벨에서 1kHz의 총고조파왜곡(THD)이 1% 미만이 되도록 음성 인식 오디오 스트림을 녹음해야 합니다(SHOULD).

음성 인식에 관해 조정된 android.hardware.microphone 및 노이즈 제거(감소) 기술을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] android.media.audiofx.NoiseSuppressor API로 오디오 효과를 제어할 수 있도록 허용해야 합니다(MUST).
  • [C-2-2] AudioEffect.Descriptor.uuid 필드를 통해 각 노이즈 제거 기술 구현을 고유하게 식별해야 합니다(MUST).

5.4.3. 재생 경로 변경 캡처

android.media.MediaRecorder.AudioSource 클래스에는 REMOTE_SUBMIX 오디오 소스가 포함됩니다.

android.hardware.audio.output 및 android.hardware.microphone을 둘 다 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 애플리케이션이 android.media.AudioRecord API를 사용하여 다음을 제외한 모든 오디오 스트림 혼합을 캡처하도록 REMOTE_SUBMIX 오디오 소스를 제대로 구현해야 합니다(MUST).

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. AEC(Acoustic Echo Canceler)

android.hardware.microphone를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • 음성 의사소통에 관해 조정되고 AudioSource.VOICE_COMMUNICATION을 사용하여 캡처할 때 캡처 경로에 적용되는 AEC(Acoustic Echo Canceler) 기술을 구현해야 합니다(SHOULD).

AudioSource.VOICE_COMMUNICATION 선택 시에 캡처 오디오 경로에 삽입되는 AEC를 제공하는 기기 구현은 다음을 충족해야 합니다.

5.4.5. 동시 캡처

android.hardware.microphone을 선언하는 기기 구현은 이 문서에 설명된 동시 캡처를 구현해야 합니다(MUST). 구체적으로는 다음과 같습니다.

  • [C-1-1] AudioSource.VOICE_RECOGNITION을 통한 접근성 서비스 캡처 및 AudioSource를 통한 1개 이상의 애플리케이션 캡처에 의한 마이크 동시 액세스를 허용해야 합니다(MUST).
  • [C-1-2] 어시스턴트 역할을 보유한 사전 설치된 애플리케이션 및 AudioSource.VOICE_COMMUNICATION 또는 AudioSource.CAMCORDER를 제외한 AudioSource를 통한 1개 이상의 애플리케이션 캡처에 의한 마이크 동시 액세스를 허용해야 합니다(MUST).
  • [C-1-3] 애플리케이션이 AudioSource.VOICE_COMMUNICATION 또는 AudioSource.CAMCORDER로 캡처하는 동안 접근성 서비스를 제외한 다른 모든 애플리케이션에 대한 오디오 캡처를 음소거해야 합니다(MUST). 하지만 한 앱이 AudioSource.VOICE_COMMUNICATION을 통해 캡처할 때 CAPTURE_AUDIO_OUTPUT 권한을 보유한 사전 설치된 독점 앱이 마이크에 액세스하는 경우, 다른 앱이 음성 호출을 캡처할 수 있습니다.
  • [C-1-4] 2개 이상의 애플리케이션이 동시 캡처 중이고 이러한 앱 상단에 UI가 없는 경우 가장 최근에 캡처를 시작한 애플리케이션이 오디오를 수신합니다.

5.5. 오디오 재생

Android에는 앱이 섹션 7.8.2에 정의된 오디오 출력 주변기기를 통해 오디오를 재생하도록 허용하기 위한 지원 기능이 포함되어 있습니다.

5.5.1. 원본 오디오 재생

android.hardware.audio.output을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 다음 특성을 포함하는 원본 오디오 콘텐츠의 재생을 허용해야 합니다(MUST).

    • 소스 형식: 선형 PCM, 16비트, 8비트, 부동
    • 채널: 모노, 스테레오, 최대 8채널을 보유한 유효한 멀티채널 구성
    • 샘플링 레이트(Hz):
      • 위에 나열된 채널 구성에서 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000
      • 모노 및 스테레오에서 96000

5.5.2. 오디오 효과

Android는 기기 구현을 위한 오디오 효과용 API를 제공합니다.

기능 android.hardware.audio.output을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] AudioEffect 서브클래스 Equalizer 및 LoudnessEnhancer를 통해 제어 가능한 EFFECT_TYPE_EQUALIZER 및 EFFECT_TYPE_LOUDNESS_ENHANCER 구현을 지원해야 합니다(MUST).
  • [C-1-2] Visualizer 클래스를 통해 제어 가능한 시각화 기기 API 구현을 지원해야 합니다(MUST).
  • [C-1-3] AudioEffect 서브클래스 DynamicsProcessing을 통해 제어 가능한 EFFECT_TYPE_DYNAMICS_PROCESSING 구현을 지원해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-4](2024년 2월 5일 미리보기)

  • [C-1-4] 효과 결과가 프레임워크 오디오 파이프라인에 반환될 때 부동 소수점 입력 및 출력으로 오디오 효과를 지원해야 합니다(MUST). 이는 이퀄라이저와 같은 일반적인 삽입이나 aux 효과를 나타냅니다. 효과 결과를 프레임워크 오디오 파이프라인에서 볼 수 없는 경우(예: 후처리 또는 오프로드 효과) 동일한 동작이 적극 권장됩니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-5](2024년 2월 5일 미리보기)

  • [C-1-5] 오디오 효과가 최대 믹서 채널 개수(FCC_LIMIT라고도 함)까지 여러 채널을 지원해야 합니다(MUST)(효과 결과가 프레임워크 오디오 파이프라인에 반환되는 경우). 이는 일반적인 삽입이나 aux 효과를 나타내며 채널 개수를 변경하는 다운믹스, 업믹스, 공간화 효과 등 특수 효과는 제외됩니다. 효과 결과를 프레임워크 오디오 파이프라인에서 볼 수 없는 경우(예: 후처리 또는 오프로드 효과) 동일한 동작이 권장됩니다.

새로운 요구사항 종료

  • AudioEffect 서브클래스 BassBoost, EnvironmentalReverb, PresetReverb 및 Virtualizer를 통해 제어 가능한 EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB 및 EFFECT_TYPE_VIRTUALIZER 구현을 지원해야 합니다(SHOULD).
  • [C-SR-1] 부동 소수점 및 멀티채널의 효과를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.5.3. 오디오 출력 볼륨

Automotive 기기 구현:

  • AudioAttributes, 그리고 android.car.CarAudioManager에 공개 정의된 차량 오디오 사용에 의해 정의된 콘텐츠 유형 또는 사용을 활용하여 각 오디오 스트림의 오디오 볼륨을 개별 조절할 수 있도록 허용해야 합니다(SHOULD).

5.5.4. 오디오 오프로드

오디오 오프로드 재생을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 콘텐츠가 AudioTrack gapless API와 MediaPlayer의 미디어 컨테이너에 의해 지정된 경우 동일한 형식을 사용하는 두 개의 클립 사이에서 끊김 없이 재생된 오디오 콘텐츠를 자를 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.6. 오디오 지연 시간

오디오 지연 시간은 오디오 신호가 시스템을 통과하는 동안의 시간 지연입니다. 많은 애플리케이션 클래스에서 실시간 사운드 효과를 실현하려면 짧은 지연 시간이 필수적입니다.

이 섹션의 용도와 관련해서는 다음 정의를 사용하세요.

  • 출력 지연 시간. 애플리케이션이 PCM으로 코딩된 데이터의 프레임을 작성하는 시점부터 해당 사운드가 기기 내 트랜스듀서 또는 신호에서 환경에 주어지는 시점 간의 간격은 포트를 통해 기기를 이탈하며 외부에서 관찰 가능합니다.
  • 콜드 출력 지연 시간. 요청 전에 오디오 출력 시스템이 유휴 상태였고 꺼져 있던 경우, 그 시점의 타임스탬프를 기준으로 출력 스트림의 시작과 첫 번째 프레임의 프레젠테이션 시간 사이의 시간입니다.
  • 연속 출력 지연 시간. 기기에서 오디오 재생을 시작한 다음 이어지는 프레임 출력이 지연되는 시간입니다.
  • 입력 지연 시간. 사운드가 기기 트랜스듀서에서 환경에 의해 기기에 주어졌거나 신호가 포트를 통해 기기에 진입하는 시점부터 애플리케이션이 PCM으로 코딩된 데이터의 해당 프레임을 읽는 시점까지의 간격입니다.
  • 손실된 입력. 사용할 수 없거나 제공되지 않는 입력 신호의 앞부분입니다.
  • 콜드 입력 지연 시간. 요청 전에 오디오 입력 시스템이 유휴 상태였고 꺼져 있었던 경우 스트림의 시작과 첫 번째 유효한 프레임이 수신된 시간 사이의 시간입니다.
  • 연속 입력 지연 시간. 기기가 오디오를 캡처하는 동안의 후속 프레임 입력 지연 시간입니다.
  • 연속 왕복 지연 시간. 연속 입력 지연 시간, 연속 출력 지연 시간과 하나의 버퍼 기간을 합한 값입니다. 버퍼 기간은 앱이 신호를 처리하고 입력 및 출력 스트림 간의 격차를 완화할 시간을 줍니다.
  • OpenSL ES PCM 버퍼 큐 API. Android NDK 내의 PCM 관련 OpenSL ES API 집합입니다.
  • AAudio 네이티브 오디오 API. Android NDK 내의 AAudio API 집합입니다.
  • 타임스탬프. 스트림 내 상대 프레임의 위치와 프레임이 연결된 엔드포인트의 오디오 파이프라인에 진입하거나 빠져나갈 것으로 예상되는 시간의 쌍입니다. AudioTimestamp를 참고하세요.
  • 결함. 오디오 신호가 일시적으로 중단되었거나 잘못된 샘플 값을 불러왔습니다. 일반적으로 출력의 버퍼 언더런, 입력의 버퍼 오버런이나 디지털 또는 아날로그 노이즈의 다른 모든 소스에 의해 발생합니다.
  • 평균 절대 편차(MAD). 값 집합 평균의 절대 편차의 평균입니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[TTL, RTL, MPC, FEATURE_AUDIO_PRO 정의]

  • 탭 투 톤 지연 시간(TTL): CTS 인증 도구로 측정되며 화면을 탭한 시점부터 이 탭의 결과로 생성된 톤이 스피커에서 들리는 시점까지의 시간입니다. 이는 출력용 AAudio 네이티브 오디오 API를 사용한 5회 측정에 대한 평균입니다.

  • 왕복 지연 시간(RTL): CTS 인증 도구로 측정되며 AAudio 네이티브 오디오 API를 사용하여 출력을 입력으로 다시 전달하는 루프백 경로를 통해 측정된 5회 측정에 대한 평균 연속 지연 시간입니다. 루프백 경로는 다음과 같습니다.

    • 스피커/마이크: 내장 스피커-내장 마이크
    • 아날로그: 3.5mm 아날로그 잭과 루프백 어댑터
    • USB: USB-3.5mm 어댑터, 루프백 어댑터 또는 USB 오디오 인터페이스 및 루프백 케이블

  • FEATURE_AUDIO_PRO. android.hardware.audio.pro 기능이 선언되었습니다.

  • MPC. 미디어 성능 등급

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[head-tracking-latency 정의](2024년 2월 26일 미리보기)

  • 머리 추적 지연 시간. 관성 측정 장치(IMU)에서 캡처한 머리 움직임으로부터 헤드폰 트랜스듀서가 이 움직임으로 인해 발생한 소리 변화를 감지하기까지 걸리는 시간입니다.

새로운 요구사항 종료

android.hardware.audio.output을 선언하는 기기 구현은 다음 요구사항을 충족하거나 초과해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-1](2024년 2월 5일 미리보기)

  • [C-1-1] AudioTrack.getTimestamp 및 AAudioStream_getTimestamp에 의해 반환된 출력 타임스탬프가 +/- 2밀리초로 정확해야 합니다.

새로운 요구사항 종료

  • [C-1-2] 콜드 출력 지연 시간이 500밀리초 이하여야 합니다.

  • [C-1-3] AAudioStreamBuilder_openStream()을 사용하여 출력 스트림을 여는 시간이 1,000밀리초 미만이어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-4](2024년 2월 5일 미리보기)

  • [C-1-4] AAudioStream_getTimestamp에 의해 반환된 입력 및 출력 타임스탬프에 기반하여 계산된 왕복 지연 시간은 스피커, 유선 및 무선 헤드셋용 AAUDIO_PERFORMANCE_MODE_NONE 및 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY의 왕복 지연 시간 측정치를 기준으로 200msec 내에 포함되어야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-1, C-SR-2, C-SR-4](2024년 2월 5일 미리보기)

android.hardware.audio.output을 선언하는 기기 구현은 다음 요구사항을 충족하거나 초과할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-1] 스피커 데이터 경로를 통한 콜드 출력 지연 시간이 100밀리초 이하여야 합니다.

  • [C-SR-2] 탭 투 톤 지연 시간이 80밀리초 이하여야 합니다.

  • [C-SR-4] AAudioStream_getTimestamp에 의해 반환된 입력 및 출력 타임스탬프를 기반으로 계산된 왕복 지연 시간은 스피커, 유선 및 무선 헤드셋용 AAUDIO_PERFORMANCE_MODE_NONE 및 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY의 왕복 지연 시간 측정치를 기준으로 30msec 내에 포함될 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-5, C-SR-6, C-SR-7](2024년 2월 5일 미리보기)

하나 이상의 지원되는 오디오 출력 장치에서 연속 출력 지연 시간과 콜드 출력 지연 시간에 AAudio 네이티브 오디오 API를 사용하는 경우 초기 보정 후에 위의 요구사항을 충족하는 기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-2-1](2024년 2월 5일 미리보기)

AAudio 네이티브 오디오 API를 통해 저지연 오디오 요구사항을 충족하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 저지연 오디오 지원을 보고하면 안 됩니다(MUST NOT).

새로운 요구사항 종료

android.hardware.microphone을 포함하는 기기 구현은 다음과 같은 입력 오디오 요구사항을 충족해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-3-1](2024년 2월 5일 미리보기)

  • [C-3-1] AudioRecord.getTimestamp 또는 AAudioStream_getTimestamp에 의해 반환되는 입력 타임스탬프의 오류를 +/- 2ms로 제한해야 합니다. 여기서 '오류'란 정확한 값의 편차를 의미합니다.

새로운 요구사항 종료

  • [C-3-2] 콜드 입력 지연 시간이 500ms 이하여야 합니다.
  • [C-3-3] AAudioStreamBuilder_openStream()을 사용하여 입력 스트림을 여는 시간이 1,000밀리초 미만이어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-8, C-SR-11](2024년 2월 5일 미리보기)

android.hardware.microphone을 포함하는 기기 구현은 다음과 같은 입력 오디오 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-8] 마이크 데이터 경로를 통한 콜드 입력 지연 시간이 100밀리초 이하입니다.
  • [C-SR-11] AudioRecord.getTimestamp 또는 AAudioStream_getTimestamp에서 반환하는 입력 타임스탬프의 오류를 +/- 1ms로 제한합니다.

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-12](2024년 2월 5일 미리보기)

android.hardware.audio.output 및 android.hardware.microphone을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-12] 하나 이상의 지원되는 경로에서 평균 절대 편차가 10밀리초 미만일 때 5번의 측정에서 평균 연속 왕복 지연 시간을 50밀리초 이하로 유지할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[RTL 요구사항](2024년 2월 5일 미리보기)

다음 표에서는 android.hardware.audio.output 및 android.hardware.microphone을 선언하는 2.2.1에 정의된 휴대기기 구현을 위한 RTL 요구사항을 정의합니다.

기기 및 선언 RTL(ms) MAD(ms) 루프백 경로
휴대기기 250 30 스피커/마이크, 아날로그 3.5mm(지원되는 경우), USB(지원되는 경우)
>= MPC_T(14) 80 15 하나 이상의 경로
FEATURE_AUDIO_LOW_LATENCY 50 10 하나 이상의 경로
FEATURE_AUDIO_PRO 25 5 하나 이상의 경로
FEATURE_AUDIO_PRO 20 5 아날로그(지원되는 경우)
FEATURE_AUDIO_PRO 25 5 USB(아날로그가 지원되지 않는 경우)

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[TTL 요구사항](2024년 2월 5일 미리보기)

다음 표에서는 android.hardware.audio.output 및 android.hardware.microphone을 선언하는 2.2.1에 정의된 휴대기기 구현을 위한 TTL 요구사항을 정의합니다.

기기 및 선언 TTL(ms)
휴대기기 250
>= MPC_T(14) 80
MPC_S(13) 100
FEATURE_AUDIO_PRO 80

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-4-1](2024년 2월 26일 미리보기)

머리 추적이 포함된 spatial audio 지원을 포함하고 PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 머리 추적에서 오디오 업데이트까지 최대 지연 시간 300ms를 표시해야 합니다(MUST).

새로운 요구사항 종료

5.7. 네트워크 프로토콜

기기 구현은 Android SDK 문서에 명시된 오디오 및 동영상 재생 관련 미디어 네트워크 프로토콜을 지원해야 합니다(MUST).

기기 구현에서 지원해야 하는 각 코덱 및 컨테이너 형식의 경우 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] HTTP 및 HTTPS를 통해 코덱 또는 컨테이너를 지원해야 합니다(MUST).

  • [C-1-2] HTTP 실시간 스트리밍 임시 프로토콜, 버전 7을 통해 아래의 미디어 세그먼트 형식 표에 표시된 것처럼 해당 미디어 세그먼트 형식을 지원해야 합니다(MUST).

  • [C-1-3] 아래 RTSP 표와 같이 해당 RTSP 페이로드 형식을 지원해야 합니다(MUST). 예외 사항은 섹션 5.1의 표 각주를 참고하세요.

미디어 세그먼트 형식

세그먼트 형식 참조 필수 코덱 지원
MPEG-2 전송 스트림 ISO 13818 동영상 코덱:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
H264 AVC, MPEG2-4 SP 및 MPEG-2에 관한 자세한 내용은 섹션 5.1.8을
참고하세요.

오디오 코덱:

  • AAC
AAC 및 변형에 관한 자세한 내용은 섹션 5.1.3을 참고하세요.
ADTS 프레이밍 및 ID3 태그를 포함하는 AAC ISO 13818-7 AAC 및 변형에 관한 자세한 내용은 섹션 5.1.1을 참고하세요.
WebVTT WebVTT

RTSP(RTP, SDP)

프로필 이름 참조 필수 코덱 지원
H264 AVC RFC 6184 H264 AVC에 관한 자세한 내용은 섹션 5.1.8을 참고하세요.
MP4A-LATM RFC 6416 AAC 및 변형에 관한 자세한 내용은 섹션 5.1.3을 참고하세요.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		H263에 관한 자세한 내용은 섹션 5.1.8을 참고하세요.
H263-2000 RFC 4629 H263에 관한 자세한 내용은 섹션 5.1.8을 참고하세요.
AMR RFC 4867 AMR-NB에 관한 자세한 내용은 섹션 5.1.3을 참고하세요.
AMR-WB RFC 4867 AMR-WB에 관한 자세한 내용은 섹션 5.1.3을 참고하세요.
MP4V-ES RFC 6416 MPEG-4 SP에 관한 자세한 내용은 섹션 5.1.8을 참고하세요.
mpeg4-generic RFC 3640 AAC 및 변형에 관한 자세한 내용은 섹션 5.1.3을 참고하세요.
MP2T RFC 2250 자세한 내용은 HTTP 라이브 스트리밍 아래의 MPEG-2 전송 스트림을 참고하세요.

5.8. 보안 미디어

보안 동영상 출력을 지원하고 보안 Surface를 지원할 수 있는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Display.FLAG_SECURE에 지원을 선언해야 합니다(MUST).

Display.FLAG_SECURE 지원을 선언하고 무선 디스플레이 프로토콜을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] Miracast와 같은 무선 프로토콜을 통해 연결된 디스플레이에서 HDCP 2.x 이상과 같은 강력한 암호화 메커니즘을 통해 연결을 보호해야 합니다(MUST).

Display.FLAG_SECURE 지원을 선언하고 유선 외부 디스플레이를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 사용자가 액세스 가능한 유선 포트를 통해 연결된 모든 외부 디스플레이에 대해 HDCP 1.2 이상을 지원해야 합니다(MUST).

5.9. MIDI(Musical Instrument Digital Interface)

android.content.pm.PackageManager 클래스를 통해 기능 android.software.midi 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 일반 비 MIDI 연결을 제공하는 모든 MIDI 지원 하드웨어 전송을 통한 MIDI를 지원해야 합니다(MUST)(전송이 다음과 같은 경우).

    • USB 호스트 모드, 섹션 7.7
    • 중앙 역할에서 작동하는 블루투스 LE를 통한 MIDI, 섹션 7.4.3

  • [C-1-2] 앱 간 MIDI 소프트웨어 전송(가상 MIDI 기기)을 지원해야 합니다.

  • [C-1-3] libamidi.so(네이티브 MIDI 지원)를 포함해야 합니다(MUST).

  • USB 주변기기 모드(섹션 7.7)를 통해 MIDI를 지원해야 합니다(SHOULD).

5.10. 전문 오디오

android.content.pm.PackageManager 클래스를 통해 기능 android.hardware.audio.pro 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.hardware.audio.low_latency 기능에 지원을 보고해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-2](2024년 2월 5일 미리보기)

  • [C-1-2] 연속 왕복 오디오 지연 시간이 섹션 5.6 오디오 지연 시간에 정의된 FEATURE_AUDIO_PRO 지연 시간 요구사항을 충족해야 합니다(MUST). 1개 이상의 지원되는 경로에서 25ms 이하여야 합니다

새로운 요구사항 종료

  • [C-1-3] USB 호스트 모드와 USB 주변기기 모드를 지원하는 USB 포트를 포함해야 합니다(MUST).
  • [C-1-4] 기능 android.software.midi 지원을 보고해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-4](2024년 2월 5일 미리보기)

  • [C-1-5] AAudio 네이티브 오디오 API와 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY를 사용하여 지연 시간 및 USB 오디오 지연 시간 요구사항을 충족해야 합니다(MUST).

새로운 요구사항 종료

  • [C-1-6] 콜드 출력 지연 시간이 200ms 이하여야 합니다(MUST).
  • [C-1-7] 콜드 입력 지연 시간이 200밀리초 이하여야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-8, C-SR-1, C-SR-2, C-SR-3](2024년 2월 5일 미리보기)

  • [C-1-8] 스피커에서 마이크까지의 데이터 경로에서 5회 이상 측정한 결과 평균 탭 투 톤 지연 시간이 80ms 이하여야 합니다(MUST).
  • [C-SR-1] 섹션 5.6 오디오 지연 시간에 정의된 것처럼 스피커에서 마이크로 가는 경로에서 5회 측정한 결과의 평균 절대 편차가 5ms 미만일 때 20ms 이하의 지연 시간을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-2] MMAP 경로에서 AAudio native audio API를 사용하여 연속 왕복 오디오 지연 시간, 콜드 입력 지연 시간 및 콜드 출력 지연 시간의 Pro Audio 요구사항과 USB 오디오 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-3] 오디오가 활성화되고 CPU 로드가 변화하는 동안 CPU 성능 수준을 일관되게 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 이는 Android 앱 SynthMark를 사용하여 테스트해야 합니다(SHOULD). SynthMark는 시스템 성능을 측정하는 시뮬레이션된 오디오 프레임워크에서 실행되는 소프트웨어 신시사이저를 사용합니다. 벤치마크 설명은 SynthMark 문서를 참고하세요. SynthMark 앱은 '자동화된 테스트' 옵션을 사용하여 실행해야 하며 다음과 같은 결과를 달성해야 합니다.

    • voicemark.90 >= 음성 32개
    • latencymark.fixed.little <= 15msec
    • latencymark.dynamic.little <= 50msec

  • 표준 시간 기준의 오디오 클록 부정확도와 드리프트를 최소화해야 합니다(SHOULD).

  • 둘 다 활성화된 경우 CPU CLOCK_MONOTONIC에 대한 오디오 클록 드리프트를 최소화해야 합니다(SHOULD).

  • 기기 트랜스듀서를 통한 오디오 지연 시간을 최소화해야 합니다(SHOULD).

  • USB 디지털 오디오를 통한 오디오 지연 시간을 최소화해야 합니다(SHOULD).

  • 모든 경로를 통한 오디오 지연 시간 측정을 문서화해야 합니다(SHOULD).

  • 오디오 버퍼 완료 콜백 입력 시간에서 잡음을 최소화해야 합니다(SHOULD). 이는 콜백에 의한 전체 CPU 대역폭의 사용 가능한 비율에 영향을 미칩니다.

  • 보고된 지연 시간에서 일반 사용 시 오디오 결함이 0이어야 합니다(SHOULD).

  • 채널 간 지연 시간 차이가 없어야 합니다(SHOULD).

  • 모든 전송을 통한 MIDI 평균 지연 시간을 최소화해야 합니다(SHOULD).

  • 모든 전송을 통한 로드(잡음) 하의 MIDI 지연 시간 가변성을 최소화해야 합니다(SHOULD).

  • 모든 전송을 통한 정확한 MIDI 타임스탬프를 제공해야 합니다(SHOULD).

  • 기기 트랜스듀서를 통한 오디오 신호 노이즈(콜드 스타트 직후의 기간 포함)를 최소화해야 합니다(SHOULD).

  • 입력과 출력 모두 활성 상태인 경우 해당하는 엔드포인트의 입력 측과 출력 측 간에 오디오 클록 차이가 0이어야 합니다(SHOULD). 해당하는 엔드포인트의 예로는 기기 마이크 및 스피커나 오디오 잭 입력 및 출력 등이 있습니다.

  • 둘 다 활성 상태인 경우 같은 스레드의 해당하는 엔드포인트의 입력 및 출력 측면의 오디오 버퍼 완료 콜백을 처리해야 하며 입력 콜백의 반환 직후에 출력 콜백을 입력해야 합니다(SHOULD). 또는 같은 스레드의 콜백을 호출하는 것이 불가능한 경우에는 입력 콜백을 입력한 직후에 출력 콜백을 입력하여 애플리케이션이 입력 및 출력 측의 일관적인 시점을 취하도록 허용합니다.

  • 해당하는 엔드포인트의 입력 및 출력 측의 HAL 오디오 버퍼링 간 위상차를 최소화해야 합니다(SHOULD).

  • 터치 지연 시간을 최소화해야 합니다(SHOULD).

  • 로드(잡음) 하의 터치 지연 시간 가변성을 최소화해야 합니다(SHOULD).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-4](2024년 2월 5일 미리보기)

위의 요구사항을 모두 충족하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-4] android.content.pm.PackageManager 클래스를 통해 android.hardware.audio.pro 기능 지원을 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

4극 3.5mm 오디오 잭을 포함하는 기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-2-1](2024년 2월 5일 미리보기)

  • [C-2-1] 섹션 5.6 오디오 지연 시간에 정의된 것처럼 오디오 루프백 동글을 사용하는 오디오 잭 경로에서 5회 이상 측정한 결과 평균 절대 편차가 5ms 미만일 때 평균 연속 왕복 오디오 지연 시간이 20ms 이하여야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-5](2024년 2월 5일 미리보기)

새로운 요구사항 종료

4극 3.5mm 오디오 잭을 생략하고 USB 호스트 모드를 지원하는 USB 포트를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] USB 오디오 클래스를 구현해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-3-2, C-SR-6, C-SR-7](2024년 2월 5일 미리보기)

  • [C-3-2] USB 오디오 클래스를 사용하는 USB 호스트 모드 포트에서 5회 측정의 평균 절대 편차가 5밀리초 미만일 때 평균 연속 왕복 오디오 지연 시간이 25밀리초 이하여야 합니다(MUST). (이는 USB-3.5mm 어댑터와 오디오 루프백 동글을 사용하거나 입력을 출력에 연결하는 패치 케이블이 있는 USB 오디오 인터페이스를 사용하여 측정할 수 있습니다).
  • [C-SR-6] 마찬가지로 이러한 요구사항을 지원하는 USB 오디오 주변기기와 함께 사용하는 경우 최대 8채널의 동시 I/O, 96kHz 샘플링 레이트 및 24비트 또는 32비트 심도를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-7] MMAP 경로에서 AAudio 네이티브 오디오 API를 사용하여 이러한 요구사항 그룹을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[HDMI 포트 요구사항](2024년 2월 5일 미리보기)

HDMI 포트를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • 최소 1개의 구성(20비트 또는 24비트 심도, 192kHZ)에서 비트 심도 손실 또는 리샘플링 없이 스테레오 출력 및 8채널 출력을 지원해야 합니다(SHOULD).

새로운 요구사항 종료

5.11. 처리되지 않은 오디오 캡처

Android에는 android.media.MediaRecorder.AudioSource.UNPROCESSED 오디오 소스를 통해 처리되지 않은 오디오를 녹음하는 기능 지원이 포함되어 있습니다. OpenSL ES에서는 녹음 미리 설정 SL_ANDROID_RECORDING_PRESET_UNPROCESSED로 액세스 가능합니다.

처리되지 않는 오디오 소스를 지원하고 서드 파티 앱에 제공하려는 의도를 지닌 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.media.AudioManager 속성 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED를 통해 지원을 보고해야 합니다(MUST).

  • [C-1-2] 처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수의 대략적인 고정 주파수 대비 진폭(100Hz~7,000Hz에서 ±10dB)을 표시해야 합니다(MUST).

  • [C-1-3] 저주파수 범위의 진폭 레벨(처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수 범위 대비 5Hz~100KHz에서 ±20 dB)을 표시해야 합니다(MUST)

  • [C-1-4] 고주파수 범위의 진폭 레벨(처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 중주파수 범위 대비 7,000Hz~22KHz에서 ±30 dB)을 표시해야 합니다(MUST)

  • [C-1-5] 94dB SPL(음압 수준)에서 재생된 1,000Hz 사인 곡선 톤 소스가 처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 16비트 샘플에 대해 520의 RMS를 포함하는 응답(또는 부동 소수점/배정밀도 샘플의 경우 -36dB 풀스케일)을 생성하도록 오디오 입력 민감도를 설정해야 합니다(MUST).

  • [C-1-6] 처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 60dB 이상에서 SNR(signal-to-noise ratio)을 취해야 합니다(MUST). 반면에 SNR은 94dB SPL, 그리고 자체 노이즈의 동등한 SPL(A-가중) 간의 차이로 측정됩니다.

  • [C-1-7] 처리되지 않은 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 90dB SPL 입력 수준에서의 1kHZ에 대한 총고조파왜곡(THD)이 1% 미만이어야 합니다(MUST).

  • [C-1-8] 레벨을 원하는 범위로 가져오기 위한 레벨 배율을 제외하고는 경로에 다른 어떠한 신호 처리(예: 자동 게인 컨트롤, 고역 통과 필터 또는 에코 취소)도 포함하면 안 됩니다(MUST NOT). 즉, 다음과 같아야 합니다.

    • [C-1-9] 어떠한 이유로든 아키텍처에 존재하는 모든 신호 처리는 사용 중지되어야 하며 신호 경로에 0의 지연 시간이나 추가 지연 시간을 효과적으로 가져와야 합니다(MUST).
    • [C-1-10] 레벨 배율은 경로에 있어도 되지만 신호 경로에 지연 또는 지연 시간을 가져오면 안 됩니다(MUST NOT).

모든 SPL 측정은 테스트 중인 마이크 바로 옆에서 이루어집니다. 구성에 마이크가 여러 개인 경우 이러한 요구사항이 각 마이크에 적용됩니다.

android.hardware.microphone을 선언하지만 처리되지 않은 오디오 소스는 지원하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 메서드에 대해 null을 반환하여 지원 부족을 제대로 나타내야 합니다(MUST).
  • [C-SR-1] 처리되지 않은 녹음 소스의 신호 경로와 관련된 요구사항을 최대한 많이 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

5.12. HDR 동영상

Android 13에서는 향후 문서에 설명된 것처럼 HDR 기술을 지원합니다.

픽셀 형식

동영상 디코더가 COLOR_FormatYUVP010 지원을 알리는 경우 다음을 충족해야 합니다.

  • [C-1-1] CPU-읽기를 위한 P010 형식(ImageReader, MediaImage, ByteBuffer)을 지원해야 합니다(MUST). Android 13에서 P010은 Y 및 UV 평면의 임의 스트라이드를 허용하도록 완화됩니다.

  • [C-1-2] P010 출력 버퍼는 GPU에서 샘플링할 수 있어야 합니다(GPU_SAMPLING 사용으로 할당된 경우)(MUST). 이렇게 하면 앱에서 GPU 구성과 맞춤 톤 매핑이 가능해집니다.

동영상 디코더가 COLOR_Format32bitABGR2101010 지원을 알리는 경우 다음을 충족해야 합니다.

  • [C-2-1] 출력 표면 및 CPU에서 읽을 수 있는 (ByteBuffer 출력)을 위한 RGBA_1010102 형식을 지원해야 합니다(MUST).

COLOR_FormatYUVP010 지원을 알리는 동영상 인코더는 다음을 충족해야 합니다.

  • [C-3-1] 입력 표면 및 CPU 쓰기 가능(ImageWriter, MediaImage, ByteBuffer) 입력을 위한 P010 형식을 지원해야 합니다(MUST).

동영상 인코더가 COLOR_Format32bitABGR2101010 지원을 알리는 경우 다음을 충족해야 합니다.

  • [C-4-1] 입력 표면 및 CPU 쓰기 가능(ImageWriter, ByteBuffer) 입력을 위한 RGBA_1010102 형식을 지원해야 합니다(MUST). 참고: 인코더에는 다양한 전송 곡선 간 변환이 필요하지 않습니다.

HDR 캡처 요구사항

HDR 프로필을 지원하는 모든 동영상 인코더의 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] HDR 메타데이터가 정확하다고 가정하면 안 됩니다(MUST NOT). 예를 들어 인코딩된 프레임에는 최대 휘도 수준을 넘는 픽셀이 있거나 히스토그램은 프레임을 나타내지 않을 수 있습니다.

  • 인코딩된 스트림에 적합한 HDR 정적 메타데이터를 생성하기 위해 HDR 동적 메타데이터를 집계해야 하고 각 인코딩 세션이 끝날 때 이를 출력해야 합니다(SHOULD).

CamcorderProfile API를 사용하여 HDR 캡처를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-1] Camera2 API를 통해서도 HDR 캡처를 지원해야 합니다(MUST).

  • [C-6-2] 지원되는 각 HDR 기술에서 하드웨어 가속 동영상 인코더를 하나 이상 지원해야 합니다(MUST).

  • [C-6-3] 최소 HLG 캡처를 지원해야 합니다(MUST).

  • [C-6-4] HDR 기술에 해당하는 경우 HDR 메타데이터를 캡처된 동영상 파일에 쓰기를 지원해야 합니다(MUST). AV1, HEVC, DolbyVision의 경우 메타데이터가 인코딩된 비트스트림에 포함됩니다.

  • [C-6-5] P010 및 COLOR_FormatYUVP010을 지원해야 합니다(MUST).

  • [C-6-6] 캡처된 프로필의 기본 하드웨어 가속 디코더에서 HDR에서 SDR로의 톤 매핑을 지원해야 합니다(MUST). 즉, 기기에서 HDR10+ HEVC를 캡처할 수 있는 경우 기본 HEVC 디코더는 캡처된 스트림을 SDR로 디코딩할 수 있어야 합니다(MUST).

HDR 편집 요구사항

HDR 편집을 지원하는 동영상 인코더가 포함된 기기 구현은 다음을 충족해야 합니다.

  • HDR 메타데이터가 없는 경우 이를 생성하는 데 최소 지연 시간을 사용해야 하며(SHOULD) 메타데이터가 일부 프레임에만 있고 다른 프레임에는 없는 상황을 적절하게 처리해야 합니다(SHOULD). 이 메타데이터는 정확해야 합니다(SHOULD). 예를 들어 프레임의 실제 최대 휘도와 히스토그램을 나타내야 합니다.

기기 구현이 FEATURE_HdrEditing을 지원하는 코덱을 포함하는 경우 코덱은 다음을 충족해야 합니다.

  • [C-7-1] HDR 프로필을 하나 이상 지원해야 합니다(MUST).

  • [C-7-2] 코덱에서 알리는 모든 HDR 프로필을 위해 FEATURE_HdrEditing을 지원해야 합니다(MUST). 즉, 지원되는 HDR 프로필 중 HDR 메타데이터를 사용하는 모든 HDR 프로필에 코덱이 존재하지 않는 경우 HDR 메타데이터 생성을 지원해야 합니다(MUST).

  • [C-7-3] HDR로 디코딩된 신호를 완전히 보존하는 다음과 같은 동영상 인코더 입력 형식을 지원해야 합니다(MUST).

    • 입력 표면과 ByteBuffer 모두에 RGBA_1010102(이미 타겟 전송 곡선에 있음)이며 COLOR_Format32bitABGR2101010 지원을 알려야 합니다(MUST).

기기 구현이 FEATURE_HdrEditing을 지원하는 코덱을 포함하는 경우 기기는 다음을 충족해야 합니다.

  • [C-7-4] EXT_YUV_target OpenGL 확장에 관한 지원을 알려야 합니다(MUST).

6. 개발자 도구 및 옵션 호환성

6.1. 개발자 도구

기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-0-2](2024년 2월 5일 미리보기)

  • [C-0-2] Android SDK에 문서화된 adb, 그리고 앱 개발자가 사용 가능하고 AOSP에서 제공하는 dumpsys, cmd stats, Simpleperf 등의 셸 명령어를 지원해야 합니다(MUST).

새로운 요구사항 종료

  • [C-0-11] 셸 명령어 cmd testharness를 지원해야 합니다(MUST). 영구 데이터 블록이 없는 이전 Android 버전의 기기 구현 업그레이드는 C-0-11에서 면제될 수 있습니다(MAY).
  • [C-0-3] dumpsys 명령어를 통해 로깅된 기기 시스템 이벤트(batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats)의 형식이나 콘텐츠를 변경하면 안 됩니다(MUST NOT).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-0-10](2023년 12월 11일 미리보기)

  • [C-0-10] 다음 이벤트를 생략 없이 기록해야 하며, cmd stats 셸 명령어 및 StatsManager 시스템 API 클래스가 이벤트를 액세스하고 사용할 수 있어야 합니다(MUST).
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyboardConfigured
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • TouchpadUsage
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

새로운 요구사항 종료

  • [C-0-4] 기기 측 adb 데몬이 기본으로 비활성화되어야 하며(MUST) Android 디버그 브리지를 켜기 위한 사용자가 액세스 가능한 메커니즘이 있어야 합니다(MUST).
  • [C-0-5] 보안 adb를 지원해야 합니다(MUST). Androids는 보안 adb 지원 기능을 포함합니다. 보안 adb는 알려진 인증된 호스트에 adb를 사용 설정합니다.
  • [C-0-6] adb가 호스트 시스템에서 연결되도록 허용하는 메커니즘을 제공해야 합니다(MUST). 구체적으로는 다음과 같습니다.

USB 포트 없이 주변기기 모드를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 이더넷 또는 Wi-Fi 등의 근거리 통신망을 통해 adb를 구현해야 합니다(MUST).
  • [C-3-2] Windows 7, 8, 10용 드라이버를 제공하여 개발자가 adb 프로토콜을 사용하여 기기에 연결하도록 해야 합니다(MUST).

Wi-Fi 또는 이더넷을 통해 호스트 머신에 대한 adb 연결을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] AdbManager#isAdbWifiSupported() 메서드가 true를 반환하도록 해야 합니다(MUST).

Wi-Fi 또는 이더넷을 통해 호스트 머신에 대한 adb 연결을 지원하고 카메라가 하나 이상 포함된 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] AdbManager#isAdbWifiQrSupported() 메서드가 true를 반환하도록 해야 합니다(MUST).

  • Dalvik 디버그 모니터 서비스(ddms)

    • [C-0-7] Android SDK에 문서화된 것처럼 모든 ddms 기능을 지원해야 합니다(MUST). ddms는 adb를 사용하므로 ddms 지원이 기본으로 비활성화되어야 하지만(SHOULD) 위의 경우처럼 사용자가 Android 디버그 브리지를 활성화할 때마다 지원되어야 합니다(MUST).

  • SysTrace

    • [C-0-9] Android SDK에 문서화된 것처럼 systrace 도구를 지원해야 합니다(MUST). Systrace는 기본으로 비활성화되어야 하며, Systrace를 켜기 위한 사용자가 액세스 가능한 메커니즘이 있어야 합니다(MUST).

  • Perfetto

    • [C-SR-1] /system/bin/perfetto 바이너리를 셸 사용자에게 노출할 것을 적극 권장합니다(STRONGLY RECOMMENDED). cmdline은 이를 perfetto 문서로 컴파일합니다.
    • [C-SR-2] perfetto 바이너리는 입력으로 perfetto 문서에 정의된 스키마로 컴파일하는 protobuf config를 수락할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-SR-3] perfetto 바이너리는 perfetto 문서에 정의된 스키마를 준수하는 protobuf 트레이스를 출력하는 방식으로 작성할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-SR-4] perfetto 바이너리를 통해 적어도 perfetto 문서에 설명된 데이터 소스를 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 로우 메모리 킬러

    • [C-0-12] 앱이 로우 메모리 킬러에 의해 종료되는 경우 statsd 로그에 LMK_KILL_OCCURRED_FIELD_NUMBER Atom을 작성해야 합니다(MUST).

  • 테스트 하네스 모드 셸 명령어 cmd testharness를 지원하고 cmd testharness enable을 실행하는 기기 구현은 다음을 충족해야 합니다.

    • [C-2-1] ActivityManager.isRunningInUserTestHarness()에 대해 true를 반환해야 합니다(MUST).
    • [C-2-2] 테스트 하네스 모드 문서에서 설명한 것처럼 테스트 하네스 모드를 구현해야 합니다(MUST).

  • GPU 작업 정보

    기기 구현은 다음을 충족해야 합니다.

    • [C-0-13] 셸 명령어 dumpsys gpu --gpuwork를 구현하여 power/gpu_work_period 커널 tracepoint에서 반환된 집계된 GPU 작업 데이터를 표시하거나 tracepoint가 지원되지 않는 경우 데이터를 표시하지 않아야 합니다(MUST). AOSP 구현은 frameworks/native/services/gpuservice/gpuwork/에 있습니다.

android.hardware.vulkan.version 기능 플래그를 통해 Vulkan 1.0 이상 지원을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 앱 개발자가 GPU 디버그 레이어를 사용 설정/사용 중지할 수 있도록 어포던스를 제공해야 합니다(MUST).
  • [C-1-2] GPU 디버그 레이어가 사용 설정된 경우 애플리케이션의 기본 디렉터리에서 감지된 외부 도구(플랫폼이나 애플리케이션 패키지의 일부가 아닌)에서 제공하는 라이브러리의 레이어를 열거하여 vkEnumerateInstanceLayerProperties() 및 vkCreateInstance() API 메서드를 지원해야 합니다(MUST).

6.2. 개발자 옵션

Android에는 개발자가 애플리케이션 개발 관련 설정을 구성할 수 있도록 하기 위한 지원 기능이 포함되어 있습니다.

기기 구현은 개발자 옵션과 관련된 일관적인 환경을 제공해야 하며 다음을 충족해야 합니다(MUST).

  • [C-0-1] android.settings.APPLICATION_DEVELOPMENT_SETTINGS 인텐트를 설정하여 애플리케이션 개발과 관련된 설정을 표시해야 합니다(MUST). 업스트림 Android 구현은 기본으로 개발자 옵션 메뉴를 숨기며, 사용자가 설정 > 기기 정보 > 빌드 번호 메뉴 항목을 7회 누른 후에 개발자 옵션을 실행하도록 지원합니다.
  • [C-0-2] 기본적으로 개발자 옵션을 숨겨야 합니다(MUST).
  • [C-0-3] 개발자 옵션을 사용 설정할 때 특정 서드 파티 앱을 다른 앱보다 우대하지 않는 명확한 메커니즘을 제공해야 합니다(MUST). 개발자 옵션 사용 설정 방법을 설명하는 공개적으로 표시된 문서나 웹사이트를 제공해야 합니다(MUST). 이 문서나 웹사이트는 Android SDK 문서에서 연결 가능해야 합니다(MUST).
  • 개발자 옵션이 사용 설정되는 경우 사용자에게 계속해서 시각적 알림을 표시해야 하며 사용자의 안전을 고려해야 합니다(SHOULD).
  • 메뉴를 시각적으로 숨기거나 사용 중지하여 개발자 옵션 메뉴에 대한 액세스를 일시적으로 제한함으로써 사용자의 안전을 고려해야 하는 경우의 시나리오와 관련된 방해를 예방할 수 있습니다(MAY).

7. 하드웨어 호환성

기기에 서드 파티 개발자의 해당 API가 있는 특정 하드웨어 구성요소가 포함된 경우:

  • [C-0-1] 기기 구현이 Android SDK 문서의 설명처럼 해당 API를 구현해야 합니다(MUST).

SDK의 API가 선택사항으로 명시된 하드웨어 구성요소와 상호작용하고 기기 구현이 해당 구성요소를 보유하지 않은 경우 다음을 충족해야 합니다.

  • [C-0-2] 구성요소 API와 관련된 온전한 클래스 정의(SDK에 문서화됨)를 계속해서 표시해야 합니다(MUST).
  • [C-0-3] API의 동작은 합당한 방식에 따라 노옵스(no-ops)로 구현되어야 합니다(MUST).
  • [C-0-4] SDK 문서에서 허용하는 경우 API 메서드가 null 값을 반환해야 합니다(MUST).
  • [C-0-5] SDK 문서에서 null 값을 허용하지 않는 경우 API 메서드가 클래스의 노옵(no-op) 구현을 반환해야 합니다(MUST).
  • [C-0-6] API 메서드가 SDK 문서에 의해 문서화되지 않은 예외를 반환하면 안 됩니다(MUST NOT).
  • [C-0-7] 기기 구현이 같은 빌드 지문의 android.content.pm.PackageManager 클래스에 관해 getSystemAvailableFeatures() 및 hasSystemFeature(String) 메서드를 통한 정확한 하드웨어 구성 정보를 일관되게 보고해야 합니다(MUST).

이러한 요구사항이 적용되는 시나리오의 일반적인 예로는 전화 통신 API가 있습니다. 휴대전화 기기가 아닌 경우에도 이러한 API를 합당한 노옵스(no-ops)로 구현해야 합니다.

7.1. 디스플레이 및 그래픽

Android에는 기기에 애플리케이션 애셋과 UI 레이아웃을 적절한 방식으로 자동 조정하여 서드 파티 애플리케이션이 다양한 하드웨어 디스플레이 및 구성에서 제대로 실행될 수 있도록 해주는 기능이 포함되어 있습니다. Android 호환 디스플레이는 Android 개발자 - 화면 호환성 개요, 이 섹션(7.1) 및 하위 섹션에 설명된 모든 동작 및 API와 이 CDD의 섹션 2에 설명된 추가 기기 유형별 동작을 구현하는 디스플레이 화면입니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 기본적으로 서드 파티 애플리케이션을 Android 호환 디스플레이에만 렌더링해야 합니다(MUST).

이 섹션의 요구사항에 의해 참조되는 단위는 다음과 같이 정의됩니다.

  • 실제 대각선 크기. 조명이 들어온 디스플레이 부분의 두 반대편 모서리 사이의 거리(인치)입니다.
  • 밀도. 직선형 가로 또는 세로 범위 1인치에 둘러싸인 픽셀 수입니다. 인치당 픽셀 수로 표시됩니다(ppi 또는 dpi). ppi 및 dpi 값이 나열된 경우 가로 및 세로 dpi는 모두 나열된 범위 내에 속해야 합니다.
  • 가로세로 비율. 화면의 짧은 크기에 대한 긴 크기의 픽셀 비율입니다. 예를 들어 480x854픽셀인 디스플레이는 854/480 = 1.779 또는 대략 '16:9'가 됩니다.
  • 밀도 독립형 픽셀(dp). 화면 밀도 160으로 정규화된 가상 픽셀 단위입니다. 일부 밀도 d와 픽셀 수 p의 경우 밀도 독립형 픽셀 수 dp는 다음과 같이 계산됩니다. dp = (160 / d) * p

7.1.1. 화면 구성

7.1.1.1. 화면 크기 및 모양

Android UI 프레임워크는 다양한 논리 화면 레이아웃 크기를 지원하며, 애플리케이션이 SCREENLAYOUT_SIZE_MASK 및 Configuration.smallestScreenWidthDp를 포함하는 Configuration.screenLayout을 통해 현재 구성의 화면 레이아웃 크기를 쿼리할 수 있게 해줍니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] Android SDK 문서에 정의된 것처럼 Configuration.screenLayout의 올바른 레이아웃 크기를 보고해야 합니다(MUST). 구체적으로는 기기 구현이 아래처럼 정확하고 논리적인 밀도 독립형 픽셀(dp) 화면 크기를 보고해야 합니다(MUST).

    • Configuration.uiMode가 UI_MODE_TYPE_WATCH 외의 값으로 설정되고 Configuration.screenLayout에 small 크기를 보고하는 기기는 최소 426dp x 320dp여야 합니다(MUST).
    • Configuration.screenLayout에 normal 크기를 보고하는 기기는 최소 480dp x 320=dp여야 합니다.
    • Configuration.screenLayout에 large 크기를 보고하는 기기는 최소 640dp x 480=dp여야 합니다.
    • Configuration.screenLayout에 xlarge 크기를 보고하는 기기는 최소 960dp x 720=dp여야 합니다.

  • [C-0-2] Android SDK 문서에 설명된 것처럼 AndroidManifest.xml의 <supports-screens> 속성을 통해 화면 크기에 따른 애플리케이션의 명시적인 지원을 올바르게 선정해야 합니다(MUST).

  • 모서리가 둥근 Android 호환 디스플레이를 보유할 수 있습니다(MAY).

UI_MODE_TYPE_NORMAL 크기 구성이 가능한 화면을 지원하고, 모서리가 둥근 물리적 디스플레이를 사용하여 이러한 화면을 렌더링하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 이러한 각 디스플레이는 다음 요구사항 중 하나 이상을 충족해야 합니다(MUST).

    • 둥근 모서리의 반경이 38dp 이하입니다.
    • 18dp x 18dp 상자가 논리 디스플레이의 각 모서리에 고정되면 각 상자의 최소 1개 픽셀이 화면에 표시됩니다.

  • 모서리가 직사각형인 디스플레이 모드로 전환할 수 있도록 사용자 어포던스를 포함해야 합니다(SHOULD).

NO_KEYS 키보드 구성만 가능하고 UI_MODE_TYPE_NORMAL UI 모드 구성 지원을 보고하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 596dpx384dp 이상의 레이아웃 크기(디스플레이 컷아웃 제외)를 보유해야 합니다(MUST).

사이드카 API 또는 확장 API를 올바르게 구현하는 방법에 관한 자세한 내용은 Window Manager Jetpack의 공개 문서를 참고하세요.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-4-1](2024년 2월 5일 미리보기)

접을 수 있는 Android 호환 디스플레이 영역을 하나 이상 포함하거나 여러 Android 호환 디스플레이 패널 영역 간에 접히는 힌지를 포함하고 이러한 디스플레이 영역을 애플리케이션에서 사용할 수 있도록 하는 기기 구현은 다음을 충족해야 합니다.

새로운 요구사항 종료

7.1.1.2. 화면 가로세로 비율

이 섹션은 Android 14에서 삭제되었습니다.

7.1.1.3. 화면 밀도

Android UI 프레임워크는 애플리케이션 개발자가 애플리케이션 리소스를 타겟팅하는 데 도움이 되도록 표준 논리 밀도 집합을 정의합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] DENSITY_DEVICE_STABLE API를 통해 DisplayMetrics에 나열된 Android 프레임워크 밀도 중 하나를 보고해야 하며(MUST) 이 값은 각 물리적 디스플레이의 정적 값이어야 합니다. 하지만, 기기는 초기 부팅 후에 사용자가 설정한 디스플레이 구성 변경사항(예: 디스플레이 크기)에 따라 다른 DisplayMetrics.density를 보고할 수도 있습니다(MAY).

  • 화면의 물리적 밀도에 수치상으로 가장 근접한 표준 Android 프레임워크 밀도 또는 휴대기기의 상응하는 동일한 각도 시야 측정값에 매핑되는 값을 정의해야 합니다(SHOULD).

기기의 디스플레이 크기를 변경하는 어포던스를 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 디스플레이를 DENSITY_DEVICE_STABLE의 1.5배보다 크게 확장하거나 320dp(리소스 한정자 sw320dp와 같음)보다 작은 유효한 최소 화면 크기를 생성해서는 안 됩니다(순서는 상관없음)(MUST NOT).
  • [C-1-2] 디스플레이 크기를 DENSITY_DEVICE_STABLE의 0.85배보다 작게 조정하면 안 됩니다(MUST NOT).
  • 우수한 사용성과 일관적인 글꼴 크기를 보장하려면 다음과 같이 확장된 기본 디스플레이 옵션을 제공하는 동시에 위에 명시된 제한사항을 준수하는 것이 좋습니다(RECOMMENDED).
    • 소형: 0.85x
    • 일반: 1x(기본 디스플레이 크기)
    • 중대형: 1.15x
    • 대형: 1.3x
    • 초대형 1.45x

15(AOSP 실험용)에 관한 새로운 요구사항 시작

7.1.1.4. 디스플레이 재정의

[철회됨] 7.1.1.4(2024년 2월 26일 미리보기)

다음 요구사항은 Android 15(AOSP 실험용)에서 철회되었습니다.

새로운 요구사항 종료

7.1.1.4(2024년 2월 5일 미리보기)

기기 구현은 앱별 재정의 API나 독점 메커니즘을 통해 애플리케이션별 디스플레이 설정을 재정의하는 사용자 어포던스를 제공할 수 있습니다(MAY).

애플리케이션별 디스플레이 설정(예: screenOrientation, Activity#setRequestedOrientation(), resizeableActivity, minAspectRatio, maxAspectRatio)을 재정의하는 사용자 어포던스를 하나 이상 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 사용자 동의를 얻어야 하고 재정의로 인해 예상치 못한 애플리케이션 디스플레이 또는 기타 사용자 환경 문제가 발생할 수 있음을 명시적으로 나타내야 합니다(MUST).
  • [C-1-2] 이러한 재정의를 되돌리는 방법을 명확히 나타내야 합니다(MUST).
  • [C-1-3] 이러한 재정의를 되돌리는 유사하게 액세스 가능한 사용자 어포던스를 제공해야 합니다(MUST).
  • [C-1-4] 사용자가 일괄 작업으로 앱을 재정의하도록 허용하면 안 됩니다(MUST NOT).
  • [C-1-5] 재정의를 사용 중지하는 API를 준수해야 합니다(MUST).

새로운 요구사항 종료

7.1.2. 디스플레이 측정항목

Android 호환 디스플레이 또는 Android 호환 디스플레이 화면에서 동영상을 출력하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.util.DisplayMetrics API에 정의된 모든 Android 호환 디스플레이 측정항목의 올바른 값을 보고해야 합니다(MUST).

내장형 화면이나 동영상 출력을 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 에뮬레이션된 기본 view.Display와 관련하여 android.util.DisplayMetrics API에 정의된 Android 호환 디스플레이의 올바른 값을 보고해야 합니다(MUST).

7.1.3. 화면 방향

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 어떤 화면을 지원하는지(android.hardware.screen.portrait 또는 android.hardware.screen.landscape) 보고해야 하며(MUST) 1개 이상의 지원되는 방향을 보고해야 합니다(MUST). 예를 들어 텔레비전 또는 노트북처럼 방향이 고정된 가로 화면의 기기는 android.hardware.screen.landscape만 보고해야 합니다(SHOULD).
  • [C-0-2] android.content.res.Configuration.orientation, android.view.Display.getOrientation() 또는 다른 API를 통해 쿼리될 때마다 현재 기기 구현의 올바른 값을 보고해야 합니다(MUST).

두 화면 방향을 모두 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 애플리케이션의 동적 방향을 가로 또는 세로 화면 방향으로 지원해야 합니다(MUST). 즉, 기기는 애플리케이션이 요청하는 지정 방향을 지원하도록 고려해야 합니다.
  • [C-1-2] 방향을 변경할 때 보고된 화면 크기나 밀도가 변경되어서는 안 됩니다(MUST NOT).
  • 가로 또는 세로 방향을 기본으로 설정할 수 있습니다(MAY).

7.1.4. 2D 및 3D 그래픽 가속

7.1.4.1. OpenGL ES

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 관리 API(예: GLES10.getString() 메서드 사용) 및 네이티브 API를 통해 지원되는 OpenGL ES 버전(1.1, 2.0, 3.0, 3.1, 3.2)을 올바르게 식별해야 합니다(MUST).
  • [C-0-2] 지원 대상으로 식별된 모든 OpenGL ES 버전과 관련하여 해당하는 관리 API 및 네이티브 API 지원을 모두 포함해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[이동됨] [C-0-3 및 C-0-4](2024년 2월 26일 미리보기)

다음 요구사항은 CDD에서 GMS 섹션 3.2.9 OpenGL ES(ANGLE)로 이동되었습니다.

새로운 요구사항 종료

[C-0-3 및 C-0-4](2024년 2월 5일 미리보기)

ActivityManager.isLowRamDevice()에 false를 반환하는 기기 구현은 다음을 충족해야 합니다.

  • [C-0-3] ANGLE 라이브러리 libEGL_angle.so, libGLESv1_CM_angle.so, libGLESv2_angle.so를 포함해야 합니다(MUST). 참조: AOSP 참조 코드는 기본적으로 /system/${LIB} 디렉터리에 이들 바이너리를 포함합니다.
  • [C-0-4] 네이티브 OpenGL ES 드라이버를 대체하는 ANGLE 라이브러리를 사용 설정 및 중지하는 애플리케이션 개발자용 어포던스를 설정 아래 개발자 옵션을 제공해야 합니다(MUST). 이 요구사항은 개발자 테스트를 위한 것이며 이 대체 설정의 기본값은 disabled여야 합니다(MUST).

새로운 요구사항 종료

[C-0-3 및 C-0-4](2023년 12월 11일 미리보기)

  • [C-0-3] ANGLE 라이브러리 libEGL_angle.so, libGLESv1_CM_angle.so, libGLESv2_angle.so를 포함해야 합니다(MUST). 참조: AOSP 참조 코드는 기본적으로 /system/${LIB} 디렉터리에 이들 바이너리를 포함합니다.
  • [C-0-4] 설정 아래에 네이티브 OpenGL ES 드라이버를 대체하는 ANGLE 라이브러리를 사용 설정 및 중지하는 개발자 옵션을 제공해야 합니다(MUST). 이 요구사항은 개발자 테스트를 위한 것이며 기본값은 disabled일 수 있습니다.

새로운 요구사항 종료

화면 또는 동영상 출력을 포함하는 기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-1](2023년 12월 11일 미리보기)

  • [C-1-1] Android SDK 문서에 포함 및 설명된 OpenGL ES 1.1, 및 2.0, 3.0, 3.1을 둘 다 지원해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-1](2023년 12월 11일 미리보기)

  • [C-SR-1] OpenGL ES 3.1을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

새로운 요구사항 종료

  • OpenGL ES 3.2를 지원해야 합니다(SHOULD).

OpenGL ES dEQP 테스트는 여러 테스트 목록으로 파티션이 나누어지며, 각각에는 연결된 날짜/버전 번호가 있습니다. 이러한 테스트는 external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt의 Android 소스 트리에 있습니다. 자체적으로 보고한 수준에서 Vulkan을 지원하는 기기는 이 수준 이전의 모든 테스트 목록에서 dEQP 테스트를 통과할 수 있음을 표시합니다.

OpenGL ES 버전을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] OpenGL ES 관리 API 및 네이티브 API를 통해 구현한 다른 모든 OpenGL ES 확장 프로그램을 보고해야 하며(MUST) 지원하지 않는 확장 프로그램 문자열은 보고하면 안 됩니다(MUST NOT).
  • [C-2-2] EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable 및 EGL_ANDROID_GLES_layers 확장 프로그램을 지원해야 합니다(MUST).
  • [C-2-3] android.software.opengles.deqp.level 기능 플래그를 통해 지원되는 OpenGL ES dEQP 테스트의 가장 높은 버전을 보고해야 합니다(MUST).
  • [C-2-4] 최소한 android.software.opengles.deqp.level 기능 플래그에 보고된 132383489 버전(2020년 3월 1일부터)은 지원해야 합니다(MUST).
  • [C-2-5] 지원되는 OpenGL ES 버전마다 버전 132383489와 android.software.opengles.deqp.level 기능 플래그에 지정된 버전 사이의 테스트 목록에 있는 OpenGL ES dEQP 테스트를 모두 통과해야 합니다(MUST).
  • [C-SR-2] EGL_KHR_partial_update 및 OES_EGL_image_external 확장 프로그램을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • getString() 메서드로 지원하는 모든 텍스처 압축 형식(보통 공급업체 전용)을 정확하게 보고해야 합니다(SHOULD).

  • EGL_IMG_context_priority 및 EGL_EXT_protected_content 확장 프로그램을 지원해야 합니다(SHOULD).

OpenGL ES 3.0 또는 3.1, 3.2 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] libGLESv2.so 라이브러리의 OpenGL ES 2.0 함수 기호 외에 이러한 버전의 해당하는 함수 기호까지 내보내야 합니다(MUST).
  • [C-SR-3] OES_EGL_image_external_essl3 확장 프로그램을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

OpenGL ES 3.2를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] OpenGL ES Android 확장 프로그램 팩 전체를 지원해야 합니다(MUST).

OpenGL ES Android 확장 프로그램 팩 전체를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] android.hardware.opengles.aep 기능 플래그를 통해 지원을 식별해야 합니다(MUST).

EGL_KHR_mutable_render_buffer 확장 프로그램 지원을 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-1] EGL_ANDROID_front_buffer_auto_refresh 확장 프로그램도 지원해야 합니다(MUST).
7.1.4.2. Vulkan

Android에는 고성능 3D 그래픽을 위한 오버헤드가 낮은 크로스 플랫폼 API인 Vulkan 지원 기능이 포함되어 있습니다.

OpenGL ES 3.1을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] Vulkan 1.3 지원을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-4-1] Vulkan 변형 버전을 지원하면 안 됩니다(MUST NOT). 즉, Vulkan 핵심 버전의 변형 부분이 0이어야 합니다(MUST).

화면 또는 동영상 출력을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-2] Vulkan 1.3 지원을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Vulkan dEQP 테스트는 각각 연결된 날짜/버전이 있는 여러 테스트 목록으로 파티션이 나뉩니다. 이러한 테스트는 external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt의 Android 소스 트리에 있습니다. 자체적으로 보고한 수준에서 Vulkan을 지원하는 기기는 이 수준 이전의 모든 테스트 목록에서 dEQP 테스트를 통과할 수 있음을 표시합니다.

Vulkan 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.hardware.vulkan.level 및 android.hardware.vulkan.version 기능 플래그로 올바른 정수 값을 보고해야 합니다(MUST).
  • [C-1-2] Vulkan 네이티브 API vkEnumeratePhysicalDevices()에 1개 이상의 VkPhysicalDevice를 열거해야 합니다(MUST).
  • [C-1-3] 열거된 각 VkPhysicalDevice에 대해 Vulkan 1.1 API를 온전히 구현해야 합니다(MUST).
  • [C-1-4] Vulkan 네이티브 API vkEnumerateInstanceLayerProperties() 및 vkEnumerateDeviceLayerProperties()를 통해 애플리케이션 패키지 내 네이티브 라이브러리 디렉터리에서 이름이 libVkLayer*.so로 지정된 네이티브 라이브러리에 포함된 레이어를 열거해야 합니다(MUST).
  • [C-1-5] 애플리케이션 패키지 외의 라이브러리에서 제공된 레이어를 나열하거나 Vulkan API를 추적하거나 가로챌 수 있는 다른 방법을 제공하면 안 됩니다(MUST NOT). 단, 애플리케이션의 android:debuggable 속성이 true로 설정되어 있거나 com.android.graphics.injectLayers.enable 메타데이터가 true로 설정된 경우는 예외입니다.
  • [C-1-6] Vulkan 네이티브 API를 통해 지원하는 모든 확장 프로그램 문자열을 보고해야 하며(MUST) 반대로 올바르게 지원하지 않는 확장 프로그램 문자열은 보고하면 안 됩니다(MUST NOT).
  • [C-1-7] VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain 및 VK_KHR_incremental_present 확장 프로그램을 지원해야 합니다(MUST).
  • [C-1-8] android.software.vulkan.deqp.level 기능 플래그를 통해 지원되는 Vulkan dEQP 테스트의 최대 버전을 보고해야 합니다(MUST).
  • [C-1-9] android.software.vulkan.deqp.level 기능 플래그에 보고된 132317953 버전(2019년 3월 1일부터)을 최소한으로 지원해야 합니다(MUST).
  • [C-1-10] 테스트 목록의 모든 Vulkan dEQP 테스트를 132317953 버전과 android.software.vulkan.deqp.level 기능 플래그에서 지정된 버전 사이로 전달해야 합니다(MUST).
  • [C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue 또는 VK_KHR_video_encode_queue 확장 프로그램 지원을 열거하면 안 됩니다(MUST NOT).
  • [C-SR-3] VK_KHR_driver_properties 및 VK_GOOGLE_display_timing 확장 프로그램을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-12] VK_KHR_performance_query 확장 프로그램 지원을 열거하면 안 됩니다(MUST NOT).
  • [C-1-13] Android 기준 2021 프로필에 명시된 요구사항을 충족해야 합니다(MUST).
  • [C-SR-4] Android 기준 2022 프로필에 명시된 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-5] VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory 및 VK_EXT_global_priority를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-6] HWUI와 함께 SkiaVk를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-SR-8 및 C-1-14](2023년 12월 11일 미리보기)

Vulkan 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-8] Vulkan 로더를 수정하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-14] Vulkan 기기 확장자 유형 'KHR', 'GOOGLE' 또는 'ANDROID'가 android.software.vulkan.deqp.level 기능 플래그에 포함되어 있지 않은 이상 열거하지 않아야 합니다(MUST NOT).

새로운 요구사항 종료

Vulkan 1.0 지원을 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] Vulkan 기능 플래그(예: android.hardware.vulkan.level, android.hardware.vulkan.version)를 선언하면 안 됩니다(MUST NOT).
  • [C-2-2] Vulkan 네이티브 API vkEnumeratePhysicalDevices()에 대해 VkPhysicalDevice를 열거하면 안 됩니다(MUST NOT).

Vulkan 1.1 지원을 포함하고 여기에 설명된 Vulkan 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] SYNC_FD 외부 semaphore 지원을 노출하고 유형 및 VK_ANDROID_external_memory_android_hardware_buffer 확장 프로그램을 처리해야 합니다(MUST).

  • [C-SR-7] VK_KHR_external_fence_fd 확장 프로그램을 서드 파티 애플리케이션에 제공하고 애플리케이션이 펜스 페이로드를 POSIX 파일 설명자에 내보내고 POSIX 파일 설명자에서 펜스 페이로드를 가져올 수 있도록 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED)(여기 참고).

7.1.4.3. RenderScript
  • [C-0-1] 기기 구현은 Android SDK 문서의 설명처럼 Android RenderScript를 지원해야 합니다(MUST).
7.1.4.4. 2D 그래픽 가속

Android에는 애플리케이션이 매니페스트 태그 android:hardwareAccelerated 또는 직접적인 API 호출 사용을 통해 애플리케이션, 활동, 창 또는 보기 수준에서 2D 그래픽의 하드웨어 가속을 사용 설정하고 싶어한다고 선언할 수 있도록 하기 위한 메커니즘이 포함되어 있습니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 하드웨어 가속을 기본으로 사용 설정해야 하며(MUST), 개발자가 android:hardwareAccelerated="false”를 설정하거나 Android View API를 통해 직접 하드웨어 가속을 사용 중지하는 방식으로 요청하는 경우 하드웨어 가속을 사용 중지해야 합니다(MUST).
  • [C-0-2] 하드웨어 가속에 대한 Android SDK 문서와 동일한 동작을 보여야 합니다(MUST).

Android에는 개발자가 하드웨어 가속 OpenGL ES 텍스처를 UI 계층 구조의 렌더링 타겟으로 직접 통합할 수 있는 TextureView 객체가 포함되어 있습니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-3] TextureView API를 지원해야 하며(MUST) 업스트림 Android 구현과 동일한 동작을 보여야 합니다(MUST).
7.1.4.5. 고색 재현 디스플레이

Configuration.isScreenWideColorGamut()을 통해 고색 재현 디스플레이 지원을 주장하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 색상 보정된 디스플레이가 있어야 합니다(MUST).
  • [C-1-2] 영역이 CIE 1931 xyY 공간의 sRGB 색 영역 전체를 포괄하는 디스플레이가 있어야 합니다(MUST).
  • [C-1-3] 영역이 CIE 1931 xyY 공간 내 DCI-P3의 90% 이상의 영역을 포함하는 디스플레이가 있어야 합니다(MUST).
  • [C-1-4] OpenGL ES 3.1 또는 3.2를 지원하고 올바르게 보고해야 합니다(MUST).
  • [C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear 및 EGL_EXT_gl_colorspace_display_p3_passthrough 확장 프로그램 지원을 알려야 합니다(MUST).
  • [C-SR-1] GL_EXT_sRGB를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

반대로 고색 재현 디스플레이를 지원하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] CIE 1931 xyY 공간 내 sRGB의 100% 이상을 차지해야 하지만(SHOULD) 화면 색 영역은 정의되지 않습니다.

7.1.5. 레거시 애플리케이션 호환성 모드

Android에서는 화면 크기 독립성이 마련되기 이전 오래된 Android 버전용으로 개발되지 않은 레거시 애플리케이션을 위해, '중형' 화면 크기와 동등한 모드(너비 320dp)에서 프레임워크가 작동하는 '호환성 모드'를 지정합니다.

7.1.6. 화면 기술

Android 플랫폼에는 애플리케이션이 풍부한 그래픽을 Android 호환 디스플레이에 렌더링할 수 있게 해주는 API가 포함되어 있습니다. 기기는 이 문서에서 구체적으로 허용하지 않는 이상 Android SDK에서 정의한 이러한 API를 모두 지원해야 합니다(MUST).

모든 기기 구현의 Android 호환 디스플레이는 다음을 충족해야 합니다.

  • [C-0-1] 16비트 컬러 그래픽을 렌더링할 수 있어야 합니다(MUST).
  • 24비트 컬러 그래픽을 지원하는 디스플레이를 지원해야 합니다(SHOULD).
  • [C-0-2] 애니메이션을 렌더링할 수 있어야 합니다(MUST).
  • [C-0-3] 픽셀 가로세로 비율(PAR)이 0.9~1.15여야 합니다(MUST). 즉, 픽셀 가로세로 비율이 정사각형에 가까워야 하며(1.0) 공차는 10~15%여야 합니다(MUST).

7.1.7. 보조 디스플레이

Android에는 외부 디스플레이 액세스를 위한 미디어 공유 기능과 개발자 API 지원을 위한 보조 Android 호환 디스플레이 지원 기능 포함되어 있습니다.

무선, 유선 또는 내장된 추가 디스플레이 연결을 통해 외부 디스플레이를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Android SDK 문서의 설명처럼 DisplayManager 시스템 서비스 및 API를 구현해야 합니다(MUST).

7.2. 입력 장치

기기 구현은 다음을 충족해야 합니다.

7.2.1. 키보드

서드 파티 입력 방식 편집기(IME) 애플리케이션을 포함하는 기기 구현은 다음을 충족해야 합니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] android.content.res.Configuration.keyboard에 정의된 형식(QWERTY 또는 12키) 중 하나와 일치하지 않는 하드웨어 키보드를 포함하면 안 됩니다(MUST NOT).
  • 추가적인 소프트 키보드 구현을 포함해야 합니다(SHOULD).
  • 하드웨어 키보드를 포함할 수 있습니다(MAY).

7.2.2. 터치 미지원 탐색

Android에는 터치 미지원 탐색을 위한 메커니즘으로 D패드, 트랙볼과 휠 지원 기능이 포함되어 있습니다.

기기 구현은 다음을 충족해야 합니다.

터치 미지원 탐색이 부족한 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 텍스트 선택 및 편집을 위한 입력 관리 엔진과 호환되는 합당한 대체 사용자 인터페이스 메커니즘을 제공해야 합니다(MUST). 업스트림 Android 오픈소스 구현에는 터치 미지원 탐색 입력이 부족한 기기에 사용하기 적합한 선택 메커니즘이 포함됩니다.

7.2.3. 탐색 키

홈, 최근 항목 및 뒤로 기능은 보통 전용 실제 버튼이나 터치스크린의 고유한 부분과의 상호작용을 통해 제공되며 Android 탐색 패러다임의 중요한 부분을 차지합니다. 따라서 기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 텔레비전 기기 구현과 관련하여 <intent-filter>가 ACTION=MAIN 및 CATEGORY=LAUNCHER 또는 CATEGORY=LEANBACK_LAUNCHER로 설정된 액티비티를 포함하는 설치된 애플리케이션을 실행할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). 홈 기능은 이러한 사용자 어포던스를 위한 메커니즘이어야 합니다(SHOULD).
  • 최근 항목 및 '뒤로' 기능의 버튼을 제공해야 합니다(SHOULD).

홈, 최근 항목 또는 '뒤로' 기능을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 액세스 가능한 경우 단일 행동(예: 탭, 더블클릭 또는 동작)으로 액세스 가능해야 합니다(MUST).
  • [C-1-2] 어떤 단일 행동이 각 기능을 트리거하는지 명확하게 나타내야 합니다(MUST). 버튼에 눈에 보이는 버튼을 표시하거나 화면의 탐색 메뉴 부분에 소프트웨어 아이콘을 표시하거나 즉각적인 설정 경험 도중 단계별 시연 흐름을 안내하는 등의 경우를 이러한 표시 방식의 예로 들 수 있습니다.

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 메뉴 기능의 입력 메커니즘은 Android 4.0 이후에 지원 중단되어 작업 모음으로 대체되었으므로 제공하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-2] 모든 탐색 기능을 취소 가능한 형태로 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED). '취소 가능'은 스와이프가 특정 기준점을 넘어 해제되지 않으면 탐색 기능(예: 홈으로 가기, 뒤로 가기 등)이 실행되지 않도록 하는 사용자 기능으로 정의됩니다.

메뉴 기능을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 작업 더보기 메뉴 팝업이 비어 있지 않고 작업 모음이 보일 때마다 작업 오버플로 버튼을 표시해야 합니다(MUST).
  • [C-2-2] 작업 모음의 더보기 버튼을 선택하여 표시된 작업 오버플로 팝업의 위치를 수정하면 안 되지만(MUST NOT) 메뉴 기능을 선택하여 표시된 경우에는 화면의 수정된 위치에서 작업 오버플로 팝업을 렌더링할 수 있습니다(MAY).

이전 버전과의 호환성 기능과 관련된 메뉴 기능을 제공하지 않는 기기 구현은 다음을 충족해야 합니다. * [C-3-1] targetSdkVersion이 10 미만인 경우 실제 버튼, 소프트웨어 키 또는 동작으로 메뉴 기능을 애플리케이션에 제공해야 합니다(MUST). 이 메뉴 기능은 다른 탐색 기능과 함께 숨김 처리되지 않는 이상 액세스 가능해야 합니다.

지원 기능을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 다른 탐색 키에 액세스 가능한 경우 단일 행동(예: 탭, 더블클릭 또는 동작)으로 지원 기능에 액세스할 수 있게 해야 합니다(MUST).
  • [C-SR-3] 홈 기능 길게 누르기를 지정된 상호작용으로 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

화면의 고유한 부분을 사용하여 탐색 키를 표시하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] 탐색 키는 애플리케이션이 아닌 화면의 특정 부분을 사용하도록 해야 하며(MUST) 애플리케이션에서 제공하는 화면의 일부를 가리거나 간섭해서는 안 됩니다(MUST NOT).
  • [C-5-2] 섹션 7.1.1의 요구사항을 충족하는 애플리케이션에게 디스플레이의 일부를 제공해야 합니다(MUST).
  • [C-5-3] SDK 문서에 따라 화면의 특정 부분(탐색 메뉴)이 제대로 숨겨진 것처럼 View.setSystemUiVisibility() API 메서드를 통해 앱에서 설정한 플래그를 선정해야 합니다(MUST).

탐색 기능이 화면에 표시되는 경우 동작 기반 작업은 다음을 충족해야 합니다.

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets()는 홈 동작 인식 영역을 보고하는 용도로만 사용해야 합니다(MUST).
  • [C-6-2] View#setSystemGestureExclusionRects()를 통해 포그라운드 애플리케이션에서 제공하는 배타적 rect에서 시작하지만 WindowInsets#getMandatorySystemGestureInsets()에 속하지 않는 동작은 View#setSystemGestureExclusionRects() 관련 문서에 명시된 최대 제외 한도 내에서 배타적 rect가 허용하는 한 탐색 기능을 위해 가로채기 당해서는 안 됩니다(MUST NOT).
  • [C-6-3] 이전에 포그라운드 앱이 MotionEvent.ACTION_DOWN 이벤트로 전송된 경우 터치가 시스템 동작을 위해 가로채기 당하기 시작하면 포그라운드 앱에서 MotionEvent.ACTION_CANCEL 이벤트를 전송해야 합니다(MUST).
  • [C-6-4] 화면의 버튼 기반 탐색 위치(예: 설정)로 전환할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
  • 화면을 바라보는 방향을 기준으로 하단 가장자리에서 위로 스와이프되는 홈 기능을 제공해야 합니다(SHOULD).
  • 홈 동작과 같은 영역에서 위로 스와이프하고 길게 눌렀다가 해제되는 최근 항목 기능을 제공해야 합니다(SHOULD).
  • WindowInsets#getMandatorySystemGestureInsets() 내에서 시작되는 동작은 포그라운드 애플리케이션이 View#setSystemGestureExclusionRects()를 통해 제공하는 배타적 rect의 영향을 받으면 안 됩니다(SHOULD NOT).

탐색 기능이 화면을 바라보는 방향 기준 왼쪽 및 오른쪽 가장자리에서 제공된 경우:

  • [C-7-1] 탐색 기능이 '뒤로' 기능처럼 작동하고 화면을 바라보는 방향 기준 왼쪽과 오른쪽 가장자리 모두로 스와이프되게 제공되어야 합니다(MUST).
  • [C-7-2] 맞춤형으로 스와이프할 수 있는 시스템 패널이 왼쪽 또는 오른쪽 가장자리에 제공되는 경우 화면의 1/3 내에 배치해야 하며, 이를 드래그할 경우 '뒤로'가 아닌 앞에서 언급한 패널이 호출된다는 점을 명확하게 지속적으로 표시해야 합니다(MUST). 시스템 패널은 화면 가장자리의 상단 1/3 아래에 안착하도록 사용자가 구성할 수 있지만(MAY) 시스템 패널이 가장자리의 1/3보다 길면 안 됩니다(MUST NOT).
  • [C-7-3] 포그라운드 앱에 View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT 또는 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 플래그 중 하나가 설정된 경우 가장자리에서의 스와이프는 AOSP에 구현된 대로 동작해야 합니다(MUST). 관련 내용은 SDK에 문서화되어 있습니다.
  • [C-7-4] 포그라운드 앱에 View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT 또는 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 플래그 중 하나가 설정된 경우 스와이프가 가능한 맞춤 시스템 패널은 AOSP에 구현된 대로 사용자가 가져오거나 시스템 표시줄(즉, 탐색 메뉴 및 상태 표시줄)을 어둡게 하는 것을 해제할 때까지 숨겨진 상태여야 합니다(MUST).

뒤로 탐색 기능이 제공되고 사용자가 뒤로 동작을 취소하는 경우 다음을 충족해야 합니다.

  • [C-8-1] OnBackInvokedCallback.onBackCancelled()를 호출해야 합니다(MUST).
  • [C-8-2] OnBackInvokedCallback.onBackInvoked()는 호출하면 안 됩니다(MUST NOT).
  • [C-8-3] KEYCODE_BACK 이벤트는 전달되면 안 됩니다(MUST NOT).

뒤로 탐색 기능이 제공되지만 포그라운드 애플리케이션에 등록된 OnBackInvokedCallback이 없는 경우 다음을 충족해야 합니다.

  • 시스템은 AOSP에서 제공한 것처럼 사용자가 뒤로 간다고 나타내는 포그라운드 애플리케이션에 애니메이션을 제공해야 합니다(SHOULD).

시스템 API setNavBarMode 지원을 제공하여 android.permission.STATUS_BAR 권한이 있는 모든 시스템 앱이 탐색 메뉴 모드를 설정할 수 있도록 하는 기기 구현은 다음을 충족해야 합니다.

  • [C-9-1] AOSP 코드에 제공되는 것처럼 어린이용 아이콘 또는 버튼 기반 탐색 지원을 제공해야 합니다(MUST).

7.2.4. 터치스크린 입력

Android에는 터치스크린, 터치패드, 모조 터치 입력 장치와 같은 다양한 포인터 입력 시스템 지원이 포함되어 있습니다. 터치스크린 기반 기기 구현은 사용자가 화면의 항목을 직접 조작하는 듯한 인상을 느끼도록 디스플레이에 연결됩니다. 사용자가 화면을 직접 터치하기 때문에 시스템은 조작 중인 객체를 표시하기 위해 추가적인 어포던스를 요구할 필요가 없습니다.

기기 구현은 다음을 충족해야 합니다.

  • 마우스 형식 또는 터치와 같은 특정 유형의 포인터 입력 시스템이 있어야 합니다(SHOULD).
  • 완전히 독립적인 트랙 포인터를 지원해야 합니다(SHOULD).

기본 Android 호환 디스플레이에 터치스크린(단일 터치 이상)을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Configuration.touchscreen API 필드에 TOUCHSCREEN_FINGER를 보고해야 합니다(MUST).
  • [C-1-2] android.hardware.touchscreen 및 android.hardware.faketouch 기능 플래그를 보고해야 합니다(MUST).

기본 Android 호환 디스플레이에서 단일 터치 이상을 추적하는 터치스크린을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 기기의 터치스크린 유형과 일치하는 적절한 기능 플래그 android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand를 보고해야 합니다(MUST).

기본 Android 호환 디스플레이에 입력할 때 마우스 또는 트랙볼(즉, 화면을 직접 터치하지 않음)과 같은 외부 입력 장치에 의존하고 섹션 7.2.5의 모조 터치 요구사항을 충족하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] android.hardware.touchscreen으로 시작하는 기능 플래그를 보고해서는 안 됩니다(MUST NOT).
  • [C-3-2] android.hardware.faketouch만 보고해야 합니다(MUST).
  • [C-3-3] Configuration.touchscreen API 필드에 TOUCHSCREEN_NOTOUCH를 보고해야 합니다(MUST).

7.2.5. 모조 터치 입력

모조 터치 인터페이스는 터치스크린 기능 하위 집합에 가까운 사용자 입력 시스템을 제공합니다. 예를 들어 화면 커서를 구동하는 마우스나 리모컨은 터치에 가깝지만 사용자가 먼저 가리키거나 포커스를 맞춘 후에 클릭해야 합니다. 마우스, 트랙패드, 자이로 기반 에어 마우스, 자이로 포인터, 조이스틱, 멀티 터치 트랙패드 등의 여러 입력 기기가 모조 터치 상호작용을 지원합니다. Android에는 기능 상수 android.hardware.faketouch가 포함되어 있으며 이는 터치 기반 입력(기본 동작 지원 포함)을 적절히 에뮬레이션하는 마우스나 트랙패드 같은 포인터 기반 Hi-Fi 비 터치 입력 장치에 해당합니다. 상수를 통해 에뮬레이션된 터치스크린 기능의 하위 집합을 지원하는지 알 수 있습니다.

터치스크린을 포함하지는 않지만 대체제로 또 다른 포인터 입력 시스템을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • android.hardware.faketouch 기능 플래그 지원을 선언해야 합니다(SHOULD).

android.hardware.faketouch 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 포인터 위치의 절대 X축 및 Y축 화면 위치를 보고하고 화면에 포인터가 보이게 표시해야 합니다(MUST).
  • [C-1-2] 포인터가 화면 위 또는 아래로 이동하면 발생하는 상태 변경을 지정하는 작업 코드를 포함하는 터치 이벤트를 보고해야 합니다(MUST).
  • [C-1-3] 포인터가 화면 속 객체의 위아래로 이동할 수 있도록 지원해야 합니다(MUST). 그러면 사용자가 화면 객체를 탭해 에뮬레이션할 수 있습니다.
  • [C-1-4] 시간 임곗값 이내에 화면 객체의 같은 위치에서 포인터를 아래, 위, 아래, 위로 이동할 수 있도록 지원해야 합니다(MUST). 그러면 사용자가 화면의 객체를 두 번 탭하여 에뮬레이션할 수 있습니다.
  • [C-1-5] 포인터를 화면의 임의 지점 아래로 이동하고 화면의 다른 임의 지점 아래로 이동했다가 위로 이동할 수 있도록 지원해야 합니다(MUST). 그러면 사용자가 터치 드래그를 에뮬레이션할 수 있습니다.
  • [C-1-6] 포인터를 아래로 이동할 수 있도록 지원해야 합니다(MUST). 그러면 사용자가 객체를 화면의 다른 위치로 빠르게 이동한 후 포인터를 화면 위로 이동하여 화면의 객체를 플링할 수 있습니다.

android.hardware.faketouch.multitouch.distinct 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] android.hardware.faketouch에 지원을 선언해야 합니다(MUST).
  • [C-2-2] 2개 이상의 개별 포인터 입력에 관한 고유한 추적을 지원해야 합니다(MUST).

android.hardware.faketouch.multitouch.jazzhand 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] android.hardware.faketouch 지원을 선언해야 합니다(MUST).
  • [C-3-2] 5개(손가락 추적) 이상의 포인터 입력에 관한 고유한 추적을 온전히 개별적으로 지원해야 합니다(MUST).

7.2.6. 게임 컨트롤러 지원

7.2.6.1. 버튼 매핑

기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] HID 이벤트를 아래 표에 나열된 해당 InputEvent 상수에 매핑할 수 있어야 합니다(MUST). 업스트림 Android 구현은 이러한 요구사항을 충족합니다.

아래 표에 나열된 모든 이벤트를 입력할 수 있도록 컨트롤러를 포함하거나 상자에 별도의 컨트롤러를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] android.hardware.gamepad 기능 플래그를 선언해야 합니다(MUST).
버튼 HID 사용2 Android 버튼
A1 0x09 0x0001 KEYCODE_BUTTON_A(96)
B1 0x09 0x0002 KEYCODE_BUTTON_B(97)
X1 0x09 0x0004 KEYCODE_BUTTON_X(99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y(100)
D패드 위쪽1
D패드 아래쪽1		 0x01 0x00393 AXIS_HAT_Y4
D패드 왼쪽1
D패드 오른쪽1		 0x01 0x00393 AXIS_HAT_X4
왼쪽 검지 버튼1 0x09 0x0007 KEYCODE_BUTTON_L1(102)
오른쪽 검지 버튼1 0x09 0x0008 KEYCODE_BUTTON_R1(103)
왼쪽 스틱 클릭1 0x09 0x000E KEYCODE_BUTTON_THUMBL(106)
오른쪽 스틱 클릭1 0x09 0x000F KEYCODE_BUTTON_THUMBR(107)
뒤로1 0x0c 0x0224 KEYCODE_BACK(4)

1 KeyEvent

2 위의 HID 사용은 게임패드 CA(0x01 0x0005) 내에서 선언해야 합니다.

3 이러한 사용은 논리 최솟값 0, 논리 최댓값 7, 실제 최솟값 0, 실제 최댓값 315, 도 단위, 보고 크기 4를 포함해야 합니다. 논리 값은 세로축을 기준으로 시계 방향으로 정의됩니다. 예를 들어 논리 값 0은 회전이 없고 위로 버튼을 누르고 있음을 나타내는 반면 논리 값 1은 45도의 회전, 그리고 위로 및 왼쪽 키를 누르고 있음을 나타냅니다.

4 MotionEvent

아날로그 컨트롤1 HID 사용 Android 버튼
왼쪽 트리거 0x02 0x00C5 AXIS_LTRIGGER
오른쪽 트리거 0x02 0x00C4 AXIS_RTRIGGER
왼쪽 조이스틱 0x01 0x0030
0x01 0x0031		 AXIS_X
AXIS_Y
오른쪽 조이스틱 0x01 0x0032
0x01 0x0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. 리모컨

섹션 2.3.1에서 기기별 요구사항을 참조하세요.

7.3. 센서

서드 파티 개발자의 해당하는 API를 보유한 특정 센서 유형을 포함하는 기기 구현은 센서에 관한 Android SDK 문서 및 Android 오픈소스 문서의 설명처럼 해당 API를 구현해야 합니다(MUST).

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] android.content.pm.PackageManager 클래스별 센서 유무 여부를 정확하게 보고해야 합니다(MUST).
  • [C-0-2] SensorManager.getSensorList() 및 유사 메서드를 통해 지원되는 센서의 정확한 목록을 반환해야 합니다(MUST).
  • [C-0-3] 다른 모든 센서 API에 관해 합당한 방식으로 동작해야 합니다(MUST). 애플리케이션이 리스너를 등록하려고 시도할 때 적절히 true 또는 false를 반환하거나 해당하는 센서가 없을 때 센서 리스너를 호출하지 않는 경우를 예로 들 수 있습니다.

서드 파티 개발자의 해당하는 API를 보유한 특정 센서 유형을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Android SDK 문서에 정의된 것처럼 각 센서에 관련 국제단위계(미터법)를 사용하여 모든 센서 측정을 보고해야 합니다(MUST).
  • [C-1-2] 센서 데이터는 센서 스트림의 경우 sample_time 2배에 100ms를 더한 만큼을 최대 지연 시간으로 보고하며 애플리케이션 프로세서가 활성화된 경우의 최대 지연 시간은 0ms으로 보고해야 합니다(MUST). 이러한 지연에는 필터링 지연이 포함되지 않습니다.
  • [C-1-3] 첫 번째 센서 샘플을 활성화되고 있는 센서의 sample_time 2배에 400ms를 더한 시간 이내에 보고해야 합니다(MUST). 이 샘플은 정확도가 0이어도 괜찮습니다.
  • [C-1-4] Android SDK 문서에서 연속 센서로 표시한 모든 API의 경우 기기 구현은 계속해서 주기적 데이터 샘플을 제공해야 합니다(MUST). 주기적 데이터 샘플의 잡음은 3% 미만이어야 하며(SHOULD), 여기서 잡음은 연속 이벤트 간의 보고된 타임스탬프 값의 표준 편차로 정의됩니다.
  • [C-1-5] 센서 이벤트 스트림이 기기 CPU가 정지 상태로 전환되거나 정지 상태에서 해제되는 것을 막지 않도록(MUST NOT) 해야 합니다(MUST).
  • [C-1-6] Android SDK 문서에 정의된 것처럼 나노초 단위의 이벤트 시간을 보고하여 이벤트가 발생하고 SystemClock.elapsedRealtimeNano() 클록과 동기화된 시간을 나타내야 합니다(MUST).
  • [C-SR-1] 타임스탬프 동기화 오류가 100ms 미만일 것을 적극 권장합니다(STRONGLY RECOMMENDED). 타임스탬프 동기화 오류가 1ms 미만이어야 합니다(SHOULD).
  • 여러 센서가 활성화되면 전력 소모량이 개별 센서의 보고된 전력 소모량의 합계를 초과하면 안 됩니다(SHOULD NOT).

위의 목록은 전체 목록이 아니며, 센서에 관한 Android SDK 및 Android 오픈소스 문서를 공신력 있는 문서를 간주해야 합니다.

서드 파티 개발자의 해당하는 API를 보유한 특정 센서 유형을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-6] 모든 센서에 0이 아닌 해상도를 설정하고 Sensor.getResolution() API 메서드를 통해 값을 보고해야 합니다(MUST).

일부 센서 유형은 복합적입니다. 즉, 1개 이상의 다른 센서에서 제공된 데이터에서 파생될 수 있습니다. (예: 방향 센서 및 선형 가속 센서)

기기 구현은 다음을 충족해야 합니다.

  • 센서 유형에 설명한 대로 실제 센서(전제조건)를 포함하는 경우 이러한 센서 유형을 구현해야 합니다(SHOULD).

복합 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 복합 센서에 관한 Android 오픈소스 문서에 설명된 것처럼 센서를 구현해야 합니다(MUST).

서드 파티 개발자를 위한 해당 API가 있는 특정 센서 유형을 포함하고 센서가 하나의 값만 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 센서의 해상도를 1로 설정하고 Sensor.getResolution() API 메서드를 통해 해당 값을 보고해야 합니다(MUST).

SensorAdditionalInfo#TYPE_VEC3_CALIBRATION을 지원하는 특정 센서 유형을 포함하고 센서가 서드 파티 개발자에게 노출되는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 제공된 데이터에 팩토리에서 결정한 고정된 보정 매개변수를 포함하면 안 됩니다(MUST NOT).

3축 가속도계, 3축 자이로스코프 센서 또는 자기계 센서의 조합을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-2] 가속도계, 자이로스코프, 자기계가 고정된 상대 위치를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 그러면 기기를 변형할 수 있는 경우(예: 폴더블) 센서 축은 모든 가능한 기기 변환 상태 전반에 걸쳐 센서 좌표계와 정렬되고 일치된 상태를 유지합니다.

7.3.1. 가속도계

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 3축 가속도계를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

가속도계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 최소 50Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [C-1-3] Android API에 설명된 것처럼 Android 센서 좌표계를 준수해야 합니다(MUST).
  • [C-1-4] 모든 축에서 최대 4배의 중력(4g) 이상에서 자유 낙하 측정이 가능해야 합니다(MUST).
  • [C-1-5] 해상도가 최소 12비트여야 합니다(MUST).
  • [C-1-6] 표준 편차가 0.05m/s^ 이하여야 하며(MUST), 여기서 표준 편차는 가장 빠른 샘플링 레이트에서 최소 3초에 걸쳐 수집된 샘플의 축당 기준으로 계산되어야 합니다.
  • 최소 200Hz까지 이벤트를 보고해야 합니다(SHOULD).
  • 해상도가 최소 16비트여야 합니다(SHOULD).
  • 수명 주기에 걸쳐 특성이 변화하고 상쇄되는 경우 사용 도중에 보상되어야 하며 기기 재부팅 간의 보상 매개변수를 보존해야 합니다(SHOULD).
  • 온도 보상이 이루어져야 합니다(SHOULD).

3축 가속도계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] TYPE_ACCELEROMETER 센서를 구현하고 보고해야 합니다(MUST).
  • [C-SR-4] TYPE_SIGNIFICANT_MOTION 복합 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-5] TYPE_ACCELEROMETER_UNCALIBRATED 센서를 구현하고 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED). Android 기기는 앞으로 이러한 내용이 필수가 될 수 있는 향후 플랫폼 버전으로 업그레이드가 가능하도록 이러한 요구사항을 충족할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • Android SDK 문서에 설명된 것처럼 TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER 복합 센서를 구현해야 합니다(SHOULD).

3축 미만의 가속도계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES 센서를 구현하고 보고해야 합니다(MUST).
  • [C-SR-6] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED 센서를 구현하고 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기기 구현이 3축 가속도계를 포함하고 TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER 복합 센서가 하나라도 구현된 경우 다음을 충족해야 합니다.

  • [C-4-1] 전력 소모량의 합계가 항상 4mW 미만이어야 합니다(MUST).
  • 기기가 동적 또는 정적 상태인 경우 각각 2mW 및 0.5mW 미만이어야 합니다(SHOULD).

3축 가속도계와 3축 자이로스코프 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] TYPE_GRAVITY 및 TYPE_LINEAR_ACCELERATION 복합 센서를 구현해야 합니다(MUST).
  • [C-SR-7] TYPE_GAME_ROTATION_VECTOR 복합 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 가속도계, 3축 자이로스코프 센서와 자기계 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-1] TYPE_ROTATION_VECTOR 복합 센서를 구현해야 합니다(MUST).

7.3.2. 자기계

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 3축 자기계(나침반)를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 자기계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] TYPE_MAGNETIC_FIELD 센서를 구현해야 합니다(MUST).
  • [C-1-2] 최대 10Hz의 주파수까지 이벤트를 보고할 수 있어야 하며(MUST) 최소 50Hz의 주파수까지 이벤트를 보고해야 합니다(SHOULD).
  • [C-1-3] Android API에 설명된 것처럼 Android 센서 좌표계를 준수해야 합니다(MUST).
  • [C-1-4] 포화 전에 각 축에서 -900µT~+900µT로 측정이 가능해야 합니다(MUST).
  • [C-1-5] 자기계를 동적(전류 감소) 및 정적(자기 감소) 자기장에서 멀리 배치하여 강철 오프셋 값이 700µT 미만(MUST), 값이 200µT 미만(SHOULD)이 되도록 해야 합니다.
  • [C-1-6] 해상도가 0.6µT 이상이어야 합니다(MUST).
  • [C-1-7] 강철 바이어스의 온라인 보정 및 보상을 지원하고 기기 재부팅 간의 보상 매개변수를 보존해야 합니다(MUST).
  • [C-1-8] 연철 보정을 적용해야 합니다(MUST). 보정은 기기 사용 또는 프로덕션 도중에 수행할 수 있습니다.
  • [C-1-9] 가장 빠른 샘플링 레이팅에서 최소 3초에 걸쳐 수집된 샘플의 축당 기준으로 계산된 표준 편차가 1.5µT 이하여야 하며(MUST) 표준 편차가 0.5µT 이하여야 합니다(SHOULD).
  • [C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED 센서를 구현해야 합니다(MUST).

3축 자기계, 가속도계 센서와 3축 자이로스코프 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] TYPE_ROTATION_VECTOR 복합 센서를 구현해야 합니다(MUST).

3축 자기계와 가속도계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • TYPE_GEOMAGNETIC_ROTATION_VECTOR 센서를 구현할 수 있습니다(MAY).

3축 자기계, 가속도계와 TYPE_GEOMAGNETIC_ROTATION_VECTOR 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 10mW 미만을 소비해야 합니다(MUST).
  • 센서가 각 배치 모드에 대해 10Hz에서 등록되는 경우 3mW 미만을 소비해야 합니다(SHOULD).

7.3.3. GPS

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] GPS/GNSS 수신기를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

GPS/GNSS 수신기를 포함하고 android.hardware.location.gps 기능 플래그를 통해 애플리케이션에 기능을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] LocationManager#requestLocationUpdate를 통해 요청된 경우 최소 1Hz의 속도에서 위치 출력을 지원해야 합니다(MUST).
  • [C-1-2] 0.5Mbps 또는 더 빠른 속도의 인터넷에 연결된 경우 10초 내에(최초 고정을 위한 빠른 시간) open-sky 조건(강한 신호, 용인 가능한 다중 경로, HDOP < 2)의 위치를 파악할 수 있어야 합니다(MUST). 이러한 요구사항은 보통 도우미 또는 예측 GPS/GNSS 기술을 사용하여 GPS/GNSS 락온 시간을 최소화하는 방식으로 충족됩니다. 지원 데이터에는 참조 시간, 참조 위치 및 위성 달력/시계가 포함됩니다.
    • [C-1-6] 이러한 위치를 계산한 후에는 위치 요청이 재시작된 경우 기기 구현이 5초 내에 open-sky의 위치(최초 위치 계산 후 1시간까지)를 파악해야 합니다(MUST). 이는 후속 요청이 데이터 연결 없이 또는 전원을 껐다 켠 후에 이루어진 경우에도 마찬가지입니다.

  • 위치 파악 이후 정지해 있거나 1m/s2 가속도 미만으로 이동하는 open-sky 조건의 경우 다음을 충족해야 합니다.

    • [C-1-3] 20m 내의 위치와 초당 0.5m 내의 속도를 파악할 수 있어야 합니다(최소 95%의 경우)(MUST).
    • [C-1-4] GnssStatus.Callback을 통해 1개의 별자리에서 최소 8개의 위성을 동시에 추적하고 보고해야 합니다(MUST).
    • 여러 별자리에서 최소 24개의 위성을 동시에 추적할 수 있어야 합니다(SHOULD)(예: Glonass, Beidou, Galileo 중 하나 이상의 GPS+).

  • [C-SR-2] 긴급 전화 도중 GNSS Location Provider API를 통해 정상적인 GPS/GNSS 위치 출력을 계속해서 전송할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-3] GnssStatus 메시지에서 보고된 모든 추적된 별자리의 GNSS 측정을 보고할 것을 적극 권장합니다(SBAS는 예외)(STRONGLY RECOMMENDED).

  • [C-SR-4] AGC 및 GNSS 측정 빈도를 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-5] 모든 정확도 예상값(방위, 속도 및 수직)을 GPS/GNSS 위치의 일부로 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-6] GNSS 측정을 감지되는 즉시 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 이는 GPS/GNSS에서 계산된 위치가 아직 보고되지 않은 경우에도 마찬가지입니다.

  • [C-SR-7] 위치 파악 이후 정지해 있거나 0.2m/s2 가속도 미만으로 이동해도 open-sky 조건에서 20m 이내의 위치 및 초당 0.2m 내의 속도를 시간 중 95% 이상 계산하는 데 충분한 GNSS 의사 거리 및 의사 거리 비율을 보고하도록 할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

7.3.4. 자이로스코프

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 자이로스코프 센서를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

자이로스코프를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 최소 50Hz의 주파수까지 이벤트를 보고할 수 있어야 합니다(MUST).
  • [C-1-4] 해상도가 12비트 이상이어야 합니다(MUST).
  • [C-1-5] 온도 보상이 이루어져야 합니다(MUST).
  • [C-1-6] 사용 도중 보정 및 보상이 이루어져야 하며 기기 재부팅 간의 보상 매개변수를 보존해야 합니다(MUST).
  • [C-1-7] 편차가 Hz당 1e-7 rad^2 / s^2(Hz당 편차 또는 rad^2 / s) 이하여야 합니다. 편차는 샘플 레이팅에 따라 다를 수 있지만 이 값으로 제한되어야 합니다(MUST). 즉, 1Hz 샘플링 레이트에서 자이로의 편차를 측정하는 경우 1e-7 rad^2/s^2 이하여야 합니다(SHOULD).
  • [C-SR-2] 기기가 실온에서 고정된 경우 보정 오류는 0.01rad/s 미만일 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-3] 해상도가 16비트 이상일 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • 최소 200Hz까지 이벤트를 보고해야 합니다(SHOULD).

3축 자이로스코프를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] TYPE_GYROSCOPE 센서를 구현해야 합니다(MUST).
  • [C-SR-4] TYPE_GYROSCOPE_UNCALIBRATED 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 미만의 자이로스코프를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] TYPE_GYROSCOPE_LIMITED_AXES 센서를 구현하고 보고해야 합니다(MUST).
  • [C-SR-5] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED 센서를 구현하고 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

3축 자이로스코프, 가속도계 센서와 자기계 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] TYPE_ROTATION_VECTOR 복합 센서를 구현해야 합니다(MUST).

3축 가속도계와 3축 자이로스코프 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] TYPE_GRAVITY 및 TYPE_LINEAR_ACCELERATION 복합 센서를 구현해야 합니다(MUST).
  • [C-SR-6] TYPE_GAME_ROTATION_VECTOR 복합 센서를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

7.3.5. 기압계

기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 기압계(외기압 센서)를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기압계를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] TYPE_PRESSURE 센서를 구현하고 보고해야 합니다(MUST).
  • [C-1-2] 5Hz 이상에서 이벤트를 전달할 수 있어야 합니다(MUST).
  • [C-1-3] 온도 보상이 이루어져야 합니다(MUST).
  • [C-SR-2] 300hPa~1100hPa 범위의 압력 측정값을 보고할 수 있도록 할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • 절대 정확도가 1hPa여야 합니다(SHOULD).
  • 상대 정확도가 20hPa 범위에 대해 0.12hPa여야 합니다(~1m accuracy over 해수면의 ~200m 변화에 대해 ~1m의 정확도와 같음).

7.3.6. 온도계

온도계(온도 센서)를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 주변 온도 센서에 대해 SENSOR_TYPE_AMBIENT_TEMPERATURE를 정의해야 하고(MUST), 센서는 사용자가 기기와 상호작용하는 곳에서 주변 온도(실내/차량 내)를 섭씨로 측정해야 합니다(MUST).

CPU 온도와 같이 주변 온도 외의 온도를 측정하는 온도계 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

피부 온도를 모니터링하는 센서를 포함하는 기기 구현은 다음을 충족해야 합니다.

7.3.7. 광도계

  • 기기 구현은 광도계(주변광 센서)를 포함할 수 있습니다(MAY).

7.3.8. 근접 센서

  • 기기 구현은 근접 센서를 포함할 수 있습니다(MAY).

근접 센서를 포함하고 바이너리 'near' 또는 'far' 판독값만 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 객체의 근접도를 화면과 같은 방향에서 측정해야 합니다(MUST). 즉, 화면에 가까운 객체를 감지하도록 근접 센서의 방향을 설정해야 하는데(MUST), 이 센서 유형의 주된 용도가 사용자가 휴대전화를 사용 중인지 감지하는 것이기 때문입니다. 방향이 다른 근접 센서를 포함하는 기기 구현은 이 API를 통해 액세스할 수 없어야 합니다(MUST NOT).
  • [C-1-2] 정확도가 1비트 이상이어야 합니다(MUST).
  • [C-1-3] 0센티미터를 근거리 판독으로 사용하고 5센티미터를 원거리 판독으로 사용해야 합니다(MUST).
  • [C-1-4] 최대 범위 및 해상도 5를 보고해야 합니다(MUST).

7.3.9. Hi-Fi 센서

이 섹션에서 정의한 고품질 센서 집합을 포함하고 이를 서드 파티 앱에 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.hardware.sensor.hifi_sensors 기능 플래그를 통해 기능을 식별해야 합니다(MUST).

android.hardware.sensor.hifi_sensors를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 다음과 같은 TYPE_ACCELEROMETER 센서가 있어야 합니다(MUST).

    • 측정 범위가 최소 -8g~+8g이고(MUST), 최소 -16g~+16g일 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • 측정 해상도가 최소 2048 LSB/g여야 합니다(MUST).
    • 최소 측정 주파수가 12.5Hz 이하여야 합니다(MUST).
    • 최대 측정 주파수가 400Hz 이상이어야 하며(MUST) SensorDirectChannel RATE_VERY_FAST를 지원해야 합니다(SHOULD).
    • 측정 노이즈가 400μg/√Hz 이하여야 합니다(MUST).
    • 최소 3000개의 센서 이벤트의 버퍼링 기능으로 이 센서의 non-wake-up 형식을 구현해야 합니다(MUST).
    • 일괄 전력 소모량이 3mW보다 나쁘면 안 됩니다(MUST).
    • [C-SR-1] Nyquist 주파수가 최소 80%인 3dB 측정 대역폭과 이 대역폭 내의 백색 소음 스펙트럼을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • 30μg √Hz 미만의 가속 랜덤워크를 실온에서 테스트해야 합니다(SHOULD).
    • 온도 대비 바이어스 변화가 ≤ +/- 1mg/°C여야 합니다(SHOULD).
    • 최적선 비선형성이 ≤ 0.5%, 온도 대비 민감도 변화가 ≤ 0.03%/C°여야 합니다(SHOULD).
    • 기기 작동 온도 범위의 교차 축 민감도가 < 2.5%, 교차 축 민감도의 편차가 < 0.2%여야 합니다(SHOULD).

  • [C-2-2] 품질 요구사항이 TYPE_ACCELEROMETER와 같은 TYPE_ACCELEROMETER_UNCALIBRATED를 보유해야 합니다(MUST).

  • [C-2-3] 다음과 같은 TYPE_GYROSCOPE 센서가 있어야 합니다(MUST).

    • 측정 범위가 최소 -1000~+1000dps여야 합니다.
    • 측정 해상도가 최소 16LSB/dps여야 합니다(MUST).
    • 최소 측정 주파수가 12.5Hz 이하여야 합니다(MUST).
    • 최대 측정 주파수가 400Hz 이상이어야 하며(MUST) SensorDirectChannel RATE_VERY_FAST를 지원해야 합니다(SHOULD).
    • 측정 노이즈가 0.014°/s/√Hz를 초과하면 안 됩니다(MUST).
    • [C-SR-2] Nyquist 주파수가 최소 80%인 3dB 측정 대역폭과 이 대역폭 내의 백색 소음 스펙트럼을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • 0.001 °/s √Hz 미만의 가속 랜덤워크를 실온에서 테스트해야 합니다(SHOULD).
    • 온도 대비 바이어스 변화가 ≤ +/- 0.05 °/ s / °C여야 합니다(SHOULD).
    • 온도 대비 민감도 변화가 ≤ 0.02% / °C여야 합니다(SHOULD).
    • 최적선 비선형성이 ≤ 0.2%여야 합니다(SHOULD).
    • 노이즈 밀도가 ≤ 0.007 °/s/√Hz여야 합니다(SHOULD).
    • 기기가 고정된 경우 보정 오류가 10~40℃의 온도 범위에서 0.002 rad/s 미만이어야 합니다(SHOULD).
    • g-민감도가 0.1°/s/g 미만이어야 합니다(SHOULD).
    • 기기 작동 온도 범위의 교차 축 민감도가 < 4.0%, 교차 축 민감도의 편차가 < 0.3%여야 합니다(SHOULD).

  • [C-2-4] 품질 요구사항이 TYPE_GYROSCOPE 같은 TYPE_GYROSCOPE_UNCALIBRATED를 보유해야 합니다(MUST).

  • [C-2-5] 다음과 같은 TYPE_GEOMAGNETIC_FIELD 센서가 있어야 합니다(MUST).

    • 측정 범위가 최소 -900~+900μT여야 합니다(MUST).
    • 측정 해상도가 최소 5 LSB/uT여야 합니다(MUST).
    • 최소 측정 주파수가 5Hz 이하여야 합니다(MUST).
    • 최대 측정 주파수가 50Hz 이상이어야 합니다(MUST).
    • 측정 노이즈가 0.5uT를 초과하면 안 됩니다(MUST).

  • [C-2-6] 품질 요구사항이 TYPE_GEOMAGNETIC_FIELD와 같은 TYPE_MAGNETIC_FIELD_UNCALIBRATED를 보유해야 하며 다음을 충족해야 합니다.

    • 최소 600개의 센서 이벤트의 버퍼링 기능으로 이 센서의 non-wake-up 형식을 구현해야 합니다(MUST).
    • [C-SR-3] 보고 속도가 50Hz 이상인 경우 백색 소음 스펙트럼을 1Hz에서 최소 10Hz일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-2-7] 다음과 같은 TYPE_PRESSURE 센서가 있어야 합니다(MUST).

    • 측정 범위가 최소 300~1100hPa여야 합니다(MUST).
    • 측정 해상도가 최소 80LSB/hPa여야 합니다(MUST).
    • 최소 측정 주파수가 1Hz 이하여야 합니다(MUST).
    • 최대 측정 주파수가 10Hz 이상이어야 합니다(MUST).
    • 측정 노이즈가 2Pa/√Hz를 초과하면 안 됩니다(MUST).
    • 최소 300개의 센서 이벤트의 버퍼링 기능으로 이 센서의 non-wake-up 형식을 구현해야 합니다(MUST).
    • 일괄 전력 소모량이 2mW보다 나쁘면 안 됩니다(MUST).

  • [C-2-8] TYPE_GAME_ROTATION_VECTOR 센서가 있어야 합니다(MUST).

  • [C-2-9] 다음과 같은 TYPE_SIGNIFICANT_MOTION 센서가 있어야 합니다(MUST).

    • 전력 소모량이 0.5mW(기기가 고정된 경우) 및 1.5mW(기기가 움직이는 경우)보다 나쁘면 안 됩니다(MUST).

  • [C-2-10] 다음과 같은 TYPE_STEP_DETECTOR 센서가 있어야 합니다(MUST).

    • 최소 100개의 센서 이벤트의 버퍼링 기능으로 이 센서의 non-wake-up 형식을 구현해야 합니다(MUST).
    • 전력 소모량이 0.5mW(기기가 고정된 경우) 및 1.5mW(기기가 움직이는 경우)보다 나쁘면 안 됩니다(MUST).
    • 일괄 전력 소모량이 4mW보다 나쁘면 안 됩니다(MUST).

  • [C-2-11] 다음과 같은 TYPE_STEP_COUNTER 센서가 있어야 합니다(MUST).

    • 전력 소모량이 0.5mW(기기가 고정된 경우) 및 1.5mW(기기가 움직이는 경우)보다 나쁘면 안 됩니다(MUST).

  • [C-2-12] 다음과 같은 TILT_DETECTOR 센서가 있어야 합니다(MUST).

    • 전력 소모량이 0.5mW(기기가 고정된 경우) 및 1.5mW(기기가 움직이는 경우)보다 나쁘면 안 됩니다(MUST).

  • [C-2-13] 가속도계, 자이로스코프 및 자기계에 의해 보고된 동일한 실제 이벤트의 이벤트 타임스탬프는 상호 간격이 2.5ms 이내여야 합니다(MUST). 가속도계 및 자이로스코프에 의해 보고된 동일한 실제 이벤트의 이벤트 타임스탬프는 상호 간격이 0.25ms 이내여야 합니다(SHOULD).

  • [C-2-14] 자이로스코프 센서 이벤트 타임스탬프가 카메라 하위 시스템과 같은 시간 베이스에 있어야 하며 오류가 1ms 이내여야 합니다(MUST).

  • [C-2-15] 데이터가 위의 실제 센서에 제공되는 시점에서 5ms 이내에 샘플을 애플리케이션에 제공해야 합니다(MUST).

  • [C-2-16] 다음 센서 조합이 사용 설정되었을 때 기기가 움직이는 경우에는 기기가 정적이고 2.0mW일 때의 전력 소모량이 0.5mW보다 높으면 안 됩니다(MUST NOT).

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] TYPE_PROXIMITY 센서를 보유할 수 있지만(MAY) 있는 경우 최소 버퍼 기능이 100개의 센서 이벤트여야 합니다(MUST).

이 섹션의 모든 전력 소모량 요구사항에는 애플리케이션 프로세서의 전력 소모량이 포함되지 않습니다. 여기에는 전체 센서 체인(센서, 지원되는 모든 회로, 모든 전용 센서 처리 시스템 등)에서 사용하는 전력이 포함됩니다.

직접 센서 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] isDirectChannelTypeSupported 및 getHighestDirectReportRateLevel API를 통한 직접 채널 유형 및 직접 보고 속도 수준을 올바르게 선언해야 합니다(MUST).
  • [C-3-2] 센서 직접 채널 지원을 선언하는 모든 센서의 센서 직접 채널 유형 2개 중 하나 이상을 지원해야 합니다(MUST).
  • 다음 유형의 기본 센서(non-wakeup 변형)와 관련된 센서 직접 채널을 통한 이벤트 보고를 지원해야 합니다(SHOULD).
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 생체 인식 센서

생체 인식 잠금 해제 보안 측정에 대한 배경 정보는 생체 인식 보안 측정 문서를 참고하세요.

보안 잠금 화면을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • 생체 인식 센서 포함(SHOULD).

생체 인식 센서는 스푸핑 및 위장 수락률과 생체 인식 파이프라인의 보안에 따라 클래스 3(이전 강함), 클래스 2(이전 약함), 또는 클래스 1(이전 편의)로 분류될 수 있습니다. 이러한 분류는 생체 인식 센서가 플랫폼 및 서드 파티 애플리케이션과 상호작용해야 하는 기능을 결정합니다. 센서가 클래스 1, 클래스 2 또는 클래스 3으로 분류되려면 아래에 설명된 추가 요구사항을 충족해야 합니다. 클래스 2 및 클래스 3 생체 인식 모두 아래에 설명된 추가 기능을 얻습니다.

android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt 및 android.provider.Settings.ACTION_BIOMETRIC_ENROLL을 통해 서드 파티 애플리케이션에 생체 인식 센서를 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 이 문서에 정의된 것처럼 클래스 3 또는 클래스 2 생체 인식 요구사항을 충족해야 합니다(MUST).
  • [C-4-2] Authenticators 클래스 및 가능한 모든 조합에서 상수로 정의된 각 매개변수 이름을 인식해야 합니다(MUST). 반대로, 인증자 및 해당 조합의 공개 상수로 문서화된 것 이외에 canAuthenticate(int) 및 setAllowedAuthenticators(int) 메서드에 전달된 정수 상수를 선정하거나 인식해서는 안 됩니다(MUST NOT).
  • [C-4-3] 클래스 3 또는 클래스 2 생체 인식이 있는 기기에 ACTION_BIOMETRIC_ENROLL 작업을 구현해야 합니다(MUST). 이 작업은 Class 3 또는 Class 2 생체 인식의 등록 진입점만 표시해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-4-4](2024년 4월 8일 미리보기)

  • [C-4-4] 애플리케이션이 PromptContentView 콘텐츠 표시 형식을 사용하여 BiometricPrompt에 맞춤 콘텐츠를 추가할 수 있도록 허용해야 합니다(MUST). 콘텐츠 표시 형식은 이미지, 링크, 대화형 콘텐츠 또는 BiometricPrompt API의 일부가 아닌 다른 형식의 미디어를 허용하도록 확장해서는 안 됩니다(MUST NOT). 이 콘텐츠를 변경하거나 가리거나 자르지 않는 스타일 조정(위치, 패딩, 여백, 서체 변경 등)은 할 수 있습니다.

새로운 요구사항 종료

[C-4-4](2024년 2월 5일 미리보기)

  • [C-4-4] 맞춤 BiometricPrompt UI를 지원하는 경우 BiometricPrompt의 콘텐츠 표시 형식(제목 텍스트, 설명 텍스트, 콘텐츠 본문 템플릿 등)을 기본적으로 변경하면 안 됩니다(MUST NOT). 콘텐츠 표시 형식은 이미지, 링크, 대화형 콘텐츠 또는 BiometricPrompt API의 일부가 아닌 다른 형식의 미디어를 허용하도록 확장해서는 안 됩니다(MUST NOT). 이 콘텐츠를 크게 변경하거나 가리지 않는 사소한 스타일 조정(패딩, 여백, 위치 등)은 가능합니다.

새로운 요구사항 종료

[C-4-4](2023년 12월 11일 미리보기)

  • [C-4-4] 맞춤 BiometricPrompt UI를 지원하는 경우 BiometricPrompt의 콘텐츠 표시 형식(제목 텍스트, 설명 텍스트, 콘텐츠 본문 템플릿 등)을 기본적으로 변경하면 안 됩니다(MUST NOT). 콘텐츠 표시 형식은 이미지, 링크, 인터랙티브 콘텐츠 또는 BiometricPrompt API의 일부가 아닌 다른 형식의 미디어를 허용하도록 확장할 수 없습니다. 이 콘텐츠를 크게 변경하거나 가리지 않는 사소한 스타일 조정(패딩, 여백, 위치 등)은 허용될 수 있습니다(MAY).

새로운 요구사항 종료

수동 생체 인식을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-5-1] 기본적으로 추가 확인 단계(예: 버튼 누르기)가 있어야 합니다(MUST).
  • [C-SR-1] 사용자가 애플리케이션 환경설정을 재정의하고 항상 추가 확인 단계를 요구하는 설정을 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-2] 운영체제나 커널 손상이 스푸핑할 수 없도록 확인 작업을 안전하게 만들 것을 적극 권장합니다(STRONGLY RECOMMENDED). 예를 들어 이는 실제 버튼 기반의 확인 행동이 실제 버튼 누르기 외의 다른 어떠한 수단으로도 구동할 수 없는 보안 요소(SE)의 입력 전용 GPIO(범용 입출력) 핀을 통해 라우팅됨을 의미합니다.
  • [C-5-2] 애플리케이션이 로그인 흐름을 활용하도록 설정할 수 있는 setConfirmationRequired(boolean)에 해당하는 암시적 인증 흐름(확인 단계 없음)을 추가로 구현해야 합니다(MUST).

여러 개의 생체 인식 센서가 있는 기기 구현은 다음을 충족해야 합니다.

  • [C-7-1] 너무 여러 번 시도가 실패하여 생체 인식이 잠금 상태(즉, 사용자가 기본 인증으로 잠금 해제할 때까지 생체 인식이 사용 중지됨) 또는 시간 제한 잠금 상태(즉, 사용자가 시간 간격을 기다릴 때까지 생체 인식이 일시적으로 사용 중지됨)가 된 경우 하위 생체 인식 클래스의 다른 모든 생체 인식도 잠금 상태가 되어야 합니다(MUST). 시간 제한 잠금의 경우 생체 인식 인증의 백오프 시간은 시간 제한 잠금에서 모든 생체 인식의 최대 백오프 시간이어야 합니다(MUST).

  • [C-SR-12] 너무 여러 번 시도가 실패하여 생체 인식이 잠금 상태(즉, 사용자가 기본 인증으로 잠금 해제할 때까지 생체 인식이 사용 중지됨) 또는 시간 제한 잠금 상태(즉, 사용자가 시간 간격을 기다릴 때까지 생체 인식이 일시적으로 사용 중지됨)가 된 경우 동일한 생체 인식 클래스의 다른 모든 생체 인식도 잠금 상태가 될 것을 적극 권장합니다(STRONGLY RECOMMENDED). 시간 제한 잠금의 경우 생체 인식 인증의 백오프 시간은 시간 제한 잠금에서 모든 생체 인식의 최대 백오프 시간일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-7-2] 잠겨 있는 생체 인식의 잠금 카운터를 재설정하기 위해 사용자에게 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)을 요구해야 합니다(MUST). 클래스 3 생체 인식은 동일하거나 낮은 클래스의 잠긴 생체 인식에 관한 잠금 카운터를 재설정할 수 있습니다(MAY). 클래스 2 또는 클래스 1 생체 인식은 생체 인식에 관한 잠금 재설정 작업을 완료해서는 안 됩니다(MUST NOT).

  • [C-SR-3] 인증마다 하나의 생체 인식만 확인할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 예를 들어, 기기에서 지문 센서와 얼굴 센서를 모두 사용할 수 있는 경우 그중 하나를 확인한 후에 onAuthenticationSucceeded를 전송해야 합니다.

서드 파티 애플리케이션에 대한 키 저장소의 키 액세스를 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-1] 아래 섹션에 정의된 것처럼 클래스 3의 요구사항을 충족해야 합니다(MUST).
  • [C-6-2] 인증에 BIOMETRIC_STRONG이 요구되거나 인증이 CryptoObject로 호출되는 경우 클래스 3 생체 인식만 표시해야 합니다(MUST).

생체 인식 센서를 클래스 1(이전의 편의)로 취급하려는 기기 구현은 다음을 충족해야 합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-1](2023년 12월 11일 미리보기)

  • [C-1-1] 오수락률이 0.002% 0.001% 미만이어야 합니다(MUST).

새로운 요구사항 종료

  • [C-1-2] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 7%를 초과하는 경우 이 모드가 강력한 PIN, 패턴 또는 비밀번호보다 덜 안전할 수 있음을 공개하고 사용 설정에 따른 위험을 명확하게 열거해야 합니다(MUST).
  • [C-1-9] 생체 인식 인증의 경우 최대 20번의 잘못된 시도와 최대 90초의 백오프 시간 후 사용자에게 권장 기본 인증(예: PIN, 패턴, 비밀번호)을 요구해야 합니다(MUST). 여기서 잘못된 시도란 캡처 화질은 충분하지만(BIOMETRIC_ACQUIRED_GOOD), 등록된 생체 인식과 일치하지 않는 시도를 의미합니다.
  • [C-SR-4] Android 생체 인식 테스트 프로토콜로 측정했을 때 스푸핑 및 위장 수락률이 7%를 초과한 경우 [C-1-9]에 지정된 생체 인식 인증의 잘못된 시도 총횟수를 더 낮출 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-3] 생체 인식 인증 시도 비율을 제한해야 하며(MUST), 여기서 잘못된 시도는 캡처 화질은 충분하지만(BIOMETRIC_ACQUIRED_GOOD) 등록된 생체 인식과 일치하지 않는 경우를 의미합니다.
  • [C-SR-5] [C-1-9]에 의한 잘못된 시도의 최대 횟수의 경우 생체 인식 인증의 잘못된 시도가 5회이면 최소 30초 후에 시도하도록 비율을 제한할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 여기서 잘못된 시도는 캡처 화질은 충분하지만(BIOMETRIC_ACQUIRED_GOOD), 등록된 생체 인식과 일치하지 않는 경우를 의미합니다.
  • [C-SR-6] TEE에 모든 비율 제한 로직을 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-10] 섹션 9.11의 [C-0-2]에 설명된 것처럼 기본 인증 백오프가 처음 트리거된 후에는 생체 인식을 중지해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-11](2023년 12월 11일 미리보기)

  • [C-1-11] Android 생체 인식 테스트 프로토콜을 사용하여 측정했을 때 (1) 수준 A 프레젠테이션 공격 도구(PAI) 종의 스푸핑 및 위장 수락률이 30% 이하이고 (2) 수준 B PAI 종의 스푸핑 및 위장 수락률이 40% 이하인 상태에서 스푸핑 및 위장 수락률이 30% 이하여야 합니다(MUST).

새로운 요구사항 종료

  • [C-1-4] 사용자가 TEE에 의해 보호되는 기존 또는 새 기기의 사용자 인증 정보(PIN/패턴/비밀번호)를 확인하거나 추가하도록 하여 먼저 신뢰 체인을 확립하지 않고서는 새 생체 인식을 추가할 수 없도록 해야 합니다(MUST). Android 오픈소스 프로젝트 구현은 프레임워크에서 이를 위한 메커니즘을 제공합니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-5](2023년 12월 11일 미리보기)

  • [C-1-5] 사용자 계정이 삭제된 경우(초기화를 통한 삭제 포함) 또는 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)이 삭제된 경우 사용자와 관련된 식별 가능한 모든 생체 인식 데이터를 완전히 삭제해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-7](2024년 4월 8일 미리보기)

  • [C-1-7] 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)을 24시간 이하 주기로 한 번씩 사용자에게 요구해야 합니다(MUST). 참고: Android 버전 9 이하에서 출시된 기기를 업그레이드하려면 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)을 72시간 이하 주기로 한 번씩 사용자에게 요구해야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-8](2023년 12월 11일 미리보기)

  • [C-1-8] 다음의 경우가 발생한 후에는 사용자에게 권장되는 기본 인증(예: PIN, 패턴, 비밀번호) 또는 클래스 3(STRONG) 생체 인식을 요구해야 합니다(MUST).
    • 유휴 제한 시간 4시간 또는
    • 생체 인식 인증 시도 3회 실패.
    • 유휴 시간 제한 기간과 인증 실패 횟수는 기기 사용자 인증 정보 확인에 성공하면 초기화됩니다. 참고: Android 9 및 이전 버전에서 출시된 기기 업그레이드는 C-1-8에서 제외될 수 있습니다(MAY).

새로운 요구사항 종료

  • [C-SR-7] Android 오픈소스 프로젝트에서 제공되는 프레임워크의 논리를 사용하여 새 기기에 [C-1-7] 및 [C-1-8]에 지정된 제약 조건을 적용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-14](2023년 12월 11일 미리보기)

  • [C-SR-8C-1-14] 기기에서 측정된 오거부율이 10% 미만일 것을 적극 권장합니다(STRONGLY RECOMMENDED)이어야 합니다(MUST).

새로운 요구사항 종료

  • [C-SR-9] 등록된 각 생체 인식에 대해 생체 인식이 감지된 시점부터 화면이 잠금 해제될 때까지의 지연 시간이 1초 미만일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-12](2023년 12월 11일 미리보기)

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-13](2023년 12월 11일 미리보기)

  • [C-SR-13C-1-13] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 30% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED)여야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-14](2024년 4월 8일 미리보기)

  • [C-1-14] 기기에서 측정된 오거부율이 10% 미만이어야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-15](2023년 12월 11일 미리보기)

  • [C-1-15] 사용자가 하나 또는 여러 개의 생체 인식 등록을 삭제하도록 허용해야 합니다(MUST).

새로운 요구사항 종료

  • [C-SR-14] 생체 인식 센서의 생체 인식 클래스와 이를 사용 설정하는 해당 위험을 공개할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-17] 새 AIDL 인터페이스(예: IFace.aidl 및 IFingerprint.aidl)를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

생체 인식 센서를 클래스 2(이전의 약함)로 취급하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 위의 클래스 1에 대한 모든 요구사항을 충족해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-2-2](2023년 12월 11일 미리보기)

  • [C-2-2] Android 생체 인식 테스트 프로토콜에 따라 측정된 (1) 수준 A 프레젠테이션 공격 도구(PAI) 종의 스푸핑 및 위장 수락률이 20% 이하이고 (2) 수준 B PAI 종의 스푸핑 및 위장 수락률이 30% 이하인 상태에서 스푸핑 및 위장 수락률이 20% 이하여야 합니다(MUST).

새로운 요구사항 종료

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-2-10](2023년 12월 11일 미리보기)

  • [C-SR-15C-2-10] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 20% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED)여야 합니다(MUST).

새로운 요구사항 종료

  • [C-2-3] 신뢰할 수 있는 실행 환경(TEE)과 같은 Android 사용자 또는 커널 공간 외의 격리된 실행 환경, 또는 격리된 실행 환경에 대한 보안 채널이 포함된 칩 또는 섹션 9.17의 요구사항을 충족하는 보호된 가상 머신에서 생체 인식 매칭을 실행해야 합니다(MUST).
  • [C-2-4] 격리된 실행 환경이나 격리된 실행 환경에 대한 보안 채널이 포함된 칩(Android 오픈소스 프로젝트 사이트의 구현 가이드라인 참고), 섹션 9.17의 요구사항을 충족하는 하이퍼바이저에 의해 제어되는 보호된 가상 머신 외부에서 획득, 판독 또는 변경할 수 없도록 모든 식별 가능한 데이터를 암호화하고 암호화 방식으로 인증해야 합니다(MUST).
  • [C-2-5] 카메라 기반 생체 인식의 경우 생체 인식 기반 인증 또는 등록이 진행되는 동안 다음을 충족해야 합니다.
    • 격리된 실행 환경이나 격리된 실행 환경에 대한 보안 채널이 포함된 칩, 섹션 9.17의 요구사항을 충족하는 하이퍼바이저에 의해 제어되는 보호된 가상 머신 외부에서 카메라 프레임이 판독 또는 변경되지 않도록 방지하는 모드에서 카메라를 작동해야 합니다(MUST).
    • RGB 단일 카메라 솔루션의 경우 카메라를 격리된 실행 환경 외부에서 판독하여 등록을 위한 미리보기 등의 작업을 지원할 수 있지만(CAN) 여전히 변경은 불가능해야 합니다(MUST NOT).
  • [C-2-6] 개별 생체 인식 등록 간의 구분을 위해 서드 파티 애플리케이션을 사용 설정하면 안 됩니다(MUST NOT).
  • [C-2-7] 식별 가능한 생체 인식 데이터나 여기에서 파생된 데이터(퍼가기 등)에 대한 암호화되지 않은 액세스를 TEE 컨텍스트 또는 섹션 9.17의 요구사항을 충족하는 하이퍼바이저에 의해 제어되는 보호된 가상 머신 외의 애플리케이션 프로세서에 허용하면 안 됩니다(MUST NOT). Android 버전 9 이하에서 출시된 기기 업그레이드는 C-2-7에서 제외되지 않습니다.

  • [C-2-8] 운영체제 또는 커널 손상으로 인해 데이터가 직접 삽입되어 사용자로 잘못 인증되지 않도록 안전한 처리 파이프라인을 보유해야 합니다(MUST). 참고: Android 버전 9 이하에서 이미 출시되었고 시스템 소프트웨어 업데이트를 통해 요구사항 C-2-8을 충족할 수 없는 기기 구현은 요구사항에서 제외될 수 있습니다(MAY).

  • [C-SR-10] 모든 생체 인식 모달리티에 대한 활성 감지와 얼굴 생체 인식에 대한 주의 감지를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-2-9] 생체 인식 센서를 서드 파티 애플리케이션에서 사용할 수 있도록 해야 합니다(MUST).

생체 인식 센서를 클래스 3 (이전의 강함)으로 취급하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] [C-1-7], [C-1-8]을 제외하고, 위의 클래스 2 요구사항을 모두 충족해야 합니다(MUST).
  • [C-3-2] 하드웨어 지원 키 저장소 구현이 있어야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-3-3](2023년 12월 11일 미리보기)

  • [C-3-3] Android 생체 인식 테스트 프로토콜에 따라 측정된 (1) 수준 A 프레젠테이션 공격 도구(PAI) 종의 스푸핑 및 위장 수락률이 7% 이하이고 (2) 수준 B PAI 종의 스푸핑 및 위장 수락률이 20% 이하인 상태에서 스푸핑 및 위장 수락률이 7% 이하여야 합니다(MUST).

새로운 요구사항 종료

  • [C-3-4] 72시간마다 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)을 사용자에게 요구해야 합니다(MUST).
  • [C-3-5] Class 3 생체 인식 중 하나라도 다시 등록되면 기기에서 지원되는 모든 Class 3 생체 인식의 인증자 ID를 다시 생성해야 합니다(MUST).
  • [C-3-6] 서드 파티 애플리케이션에 생체 인식 지원 키 저장소 키를 사용 설정해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-3-7](2023년 12월 11일 미리보기)

  • [C-SR-16C-3-7] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 7% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED)여야 합니다(MUST).

새로운 요구사항 종료

언더 디스플레이 지문 센서(UDFPS)를 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-11] UDFPS의 터치 가능 영역이 3버튼 탐색을 방해하지 않도록 적극 권장합니다(STRONGLY RECOMMENDED). 일부 사용자는 접근성 용도로 이 기능이 필요할 수 있습니다.

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-8-1~C-8-6][철회됨](2024년 4월 8일 미리보기)

다음 요구사항은 Android 15(AOSP 실험용)에서 철회되었습니다.

새로운 요구사항 종료

[C-8-1~C-8-6](2023년 12월 11일 미리보기)

결합을 위한 생체 인식 센서(즉, 특정 사용 사례에 대해 결합되는 기본 사용자 인증 방법으로 사용)를 허용하려는 기기 구현은 다음을 충족해야 합니다.

  • [C-8-1] 이 섹션에 정의된 것처럼 클래스 3의 요구사항을 충족해야 합니다(MUST). 아래의 대체 요구사항으로 인해 특정 상황에서 사용성이 우려가 되는 경우 클래스 3 생체 인식이 결합에 참여하지 않도록 제외할 수 있습니다(MAY).
  • [C-8-2] 한 번에 둘 이상의 결합된 생체 인식을 허용할 없습니다(MUST NOT). 예를 들어, 여러 개의 생체 인식 모달리티를 사용 및 운영 가능한 경우(예: 얼굴과 지문) 한 번에 하나의 모달리티 및 하나의 모달리티 등록(예: 예: 하나의 등록된 지문)만 결합될 수 있습니다.
  • [C-8-3] 결합된 생체 인식이 요구되는 경우 기기 사용자 인증 정보(PIN/패턴/비밀번호)로의 대체를 허용할 수 없습니다(MUST NOT).
  • [C-8-4] 새로 등록된 또는 이전에 등록된 생체 인식이 결합된 생체 인식으로 추가되도록 표시하도록 요구하거나 현재 결합된 생체 인식이 결합된 생체 인식을 새로 등록된 생체 인식 또는 이전에 등록된 생체 인식으로 변경되도록 표시하도록 요구해야 합니다(MUST).
  • [C-8-5] 애플리케이션이 인증 흐름을 위해 결합된 생체 인식을 요청하는 데 사용할 수 있는 setRequireBoundBiometric(boolean)을 구현해야 합니다(MUST).
  • [C-8-6] 결합된 생체 인식을 요청되는 시점과 관계없이 다른 클래스 3 생체 인식과 동일하게 처리해야 합니다(setRequireBoundBiometric(boolean))(MUST). 예를 들어, 결합된 생체 인식은 요청된 경우 또는 애플리케이션이 다른 경우에는 사용 가능했을 CryptoObject를 사용하지 못하도록 하는 경우 제외할 수 없습니다.

새로운 요구사항 종료

7.3.11. 포즈 센서

기기 구현은 다음을 충족해야 합니다.

  • 자유도가 6도인 포즈 센서를 지원할 수 있습니다(MAY).

자유도가 6도인 포즈 센서를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] TYPE_POSE_6DOF 센서를 구현하고 보고해야 합니다(MUST).
  • [C-1-2] 회전 벡터 단독인 경우보다 훨씬 정확해야 합니다(MUST).

7.3.12. 힌지 각도 센서

힌지 각도 센서를 지원하는 기기 구현은 다음을 충족해야 합니다.

7.3.13. IEEE 802.1.15.4(UWB)

802.1.15.4 지원을 포함하고 기능을 서드 파티 애플리케이션에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-2] 하드웨어 기능 플래그 android.hardware.uwb를 보고해야 합니다(MUST).
  • [C-1-3] AOSP 구현에 정의된 다음과 같은 모든 구성 세트(FIRA UCI 매개변수의 사전 정의된 조합)를 지원해야 합니다(MUST).
    • CONFIG_ID_1: FiRa 정의 유니캐스트 STATIC STS DS-TWR 범위 지정, 지연 모드, 범위 지정 간격 240ms
    • CONFIG_ID_2: FiRa 정의 일대다 STATIC STS DS-TWR 범위 지정, 지연 모드, 범위 지정 간격 200ms. 일반적인 사용 사례: 스마트폰이 여러 스마트 기기와 상호작용합니다.
    • CONFIG_ID_3: CONFIG_ID_1과 동일. 단, 도래각(AoA) 데이터는 보고되지 않습니다.
    • CONFIG_ID_4: CONFIG_ID_1과 동일. 단, P-STS 보안 모드는 사용 설정됩니다.
    • CONFIG_ID_5: CONFIG_ID_2와 동일. 단, P-STS 보안 모드는 사용 설정됩니다.
    • CONFIG_ID_6: CONFIG_ID_3과 동일. 단, P-STS 보안 모드는 사용 설정됩니다.
    • CONFIG_ID_7: CONFIG_ID_2와 동일. 단, P-STS 개별 controlee 키 모드는 사용 설정됩니다.
  • [C-1-4] 사용자가 UWB 무선 켜짐/꺼짐 상태를 전환할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
  • [C-1-5] UWB 무선을 사용하는 앱이 NEARBY_DEVICES 권한 그룹의 UWB_RANGING 권한을 보유하도록 해야 합니다(MUST).

FIRA, CCC, CSA를 비롯하여 표준 조직에서 정의한 관련 적합성 테스트 및 인증 테스트를 통과하면 802.1.15.4가 올바르게 작동하도록 할 수 있습니다.

7.4. 데이터 연결

7.4.1. 전화 통신

Android API와 이 문서에서 사용되는 '전화 통신'이란 구체적으로 모바일(예: GSM, CDMA, LTE, NR) GSM 또는 CDMA 네트워크를 통해 음성 통화를 걸고 SMS 메시지를 전송하거나 모바일 데이터를 설정하는 것과 관련된 하드웨어를 의미합니다. '전화 통신'을 지원하는 기기는 제품에 맞게 통화, 메시지, 데이터 서비스의 일부 또는 전부를 제공하도록 선택할 수 있습니다.

  • Android는 전화 통신 하드웨어를 포함하지 않는 기기에 사용될 수 있습니다(MAY). 즉, Android는 휴대전화가 아닌 기기와 호환됩니다.

GSM 또는 CDMA 전화 통신을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 통신에 따라 android.hardware.telephony 기능 플래그 및 기타 하위 기능 플래그를 선언해야 합니다(MUST).
  • [C-1-2] 해당 기술의 API에 관한 온전한 지원을 구현해야 합니다(MUST).
  • SetAllowedNetworkTypeBitmap()으로 설정된 네트워크 유형에 관계없이 긴급 전화 도중에 사용 가능한 모든 모바일 서비스 유형(2G, 3G, 4G, 5G 등)을 허용해야 합니다(SHOULD).

전화 통신 하드웨어를 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 전체 API를 노옵스(no-ops)로 구현해야 합니다(MUST).

eUICC 또는 eSIM/임베디드 SIM을 지원하고 eSIM 기능을 서드 파티 개발자에게 제공하기 위한 독점 메커니즘을 포함하는 기기 구현은 다음을 충족해야 합니다.

시스템 속성 ro.telephony.iwlan\_operation\_mode를 'legacy'로 설정하지 않는 기기 구현은 다음을 충족해야 합니다.

멀티미디어 전화 통신 서비스(MMTEL)와 Rich Communication Services(RCS) 기능 모두에 단일 IP 멀티미디어 서브시스템(IMS) 등록을 지원하고 모든 IMS 신호 트래픽에 관해 단일 IMS 등록을 사용하는 것과 관련해 모바일 이동통신사 요구사항을 준수할 것으로 예상되는 기기 구현은 다음을 충족해야 합니다.

android.hardware.telephony 기능을 보고하는 기기 구현은 다음을 충족해야 합니다.

android.hardware.telephony 기능을 보고하고 시스템 상태 표시줄을 제공하는 기기 구현은 다음을 충족해야 합니다.

  • [C-7-1] SIM 상태 정보를 제공하는 모든 어포던스에서 사용자에게 표시할 지정된 그룹 UUID의 대표적인 활성 구독을 선택해야 합니다(MUST). 이러한 어포던스의 예로는 상태 표시줄 모바일 데이터 신호 아이콘 또는 빠른 설정 타일이 있습니다.
  • [C-SR-1] 대표 구독이 활성 데이터 구독으로 선택될 것을 적극 권장합니다(STRONGLY RECOMMENDED). 단, 기기가 음성 통화 중인 경우는 제외되며 이때는 대표 구독이 활성 음성 구독일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

android.hardware.telephony 기능을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-7] ETSI TS 102 221당 각 UICC의 최대 논리 채널 수(총 20개)를 열고 동시에 활용할 수 있어야 합니다(MUST).
  • [C-6-8] 다음 동작을 자동으로 또는 명시적인 사용자 확인 없이 활성 이동통신사 앱(TelephonyManager#getCarrierServicePackageName에서 지정)에 적용하면 안 됩니다(MUST NOT).
    • 네트워크 액세스 취소 또는 제한
    • 권한 취소
    • AOSP에 포함된 기존 전원 관리 기능 이상으로 백그라운드 또는 포그라운드 앱 실행 제한
    • 앱 사용 중지 또는 제거

기기 구현이 android.hardware.telephony 기능을 보고하고 그룹 UUID를 공유하는 모든 활성 상태의 비상황별 구독이 사용 중지되거나 물리적으로 기기에서 삭제되거나 상황별이라고 표시되는 경우 기기는 다음을 충족해야 합니다.

  • [C-8-1] 동일한 그룹의 나머지 모든 활성 상태의 상황별 구독을 자동으로 사용 중지해야 합니다(MUST).

GSM 전화 통신은 포함하고 CDMA 전화 통신은 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA를 선언하면 안 됩니다(MUST NOT).
  • [C-9-2] 기본 또는 허용되는 네트워크 유형 비트마스크에서 3GPP2 네트워크 유형을 설정하려고 시도할 때 IllegalArgumentException이 발생해야 합니다(MUST).
  • [C-9-3] TelephonyManager#getMeid에서 빈 문자열을 반환해야 합니다(MUST).

여러 포트와 프로필이 있는 eUICC를 지원하는 기기 구현은 다음을 충족해야 합니다.

7.4.1.1. 번호 차단 호환성

android.hardware.telephony.calling 기능을 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 번호 차단 지원을 포함해야 합니다(MUST).
  • [C-1-2] SDK 문서에 설명된 것처럼 BlockedNumberContract 및 해당 API를 온전히 구현해야 합니다(MUST).

  • [C-1-3] 앱과의 어떠한 상호작용도 없이 'BlockedNumberProvider'의 전화번호로 온 모든 통화와 메시지를 차단해야 합니다(MUST). 유일한 예외는 SDK 문서에 설명된 것처럼 번호 차단이 일시 해제된 경우입니다.

  • [C-1-4] 차단된 통화의 경우 플랫폼 통화 기록 제공업체에 기록해야 하며(MUST) 사전 설치된 다이얼러 앱에서 기본 통화 기록 보기 외 통화를 BLOCKED_TYPE으로 필터링해야 합니다(MUST).

  • [C-1-5] 차단된 메시지의 경우 전화 통신 제공업체에 작성하면 안 됩니다(MUST NOT).

  • [C-1-6] TelecomManager.createManageBlockedNumbersIntent() 메서드에 의해 반환된 인텐트로 열리는 차단 번호 관리 UI를 구현해야 합니다(MUST).

  • [C-1-7] 보조 사용자가 기기에서 차단된 번호를 보거나 수정하도록 허용하면 안 됩니다(MUST NOT). 이는 Android 플랫폼에서 기본 사용자가 기기의 전화 통신 서비스에 대한 온전한 제어 권한(단일 인스턴스)을 보유한다고 가정하기 때문입니다. 보조 사용자를 위해 모든 차단 관련 UI를 숨기더라도(MUST) 차단 목록은 계속 사용할 수 있어야 합니다(MUST).

  • 기기를 Android 7.0으로 업데이트하면 차단된 번호를 제공업체로 이전해야 합니다(SHOULD).

  • 사전 설치된 다이얼러 앱에서 차단된 통화를 표시하는 사용자 어포던스를 제공해야 합니다(SHOULD).

7.4.1.2. 텔레콤 API

android.hardware.telephony.calling를 보고하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SDK에 설명된 ConnectionService API를 지원해야 합니다(MUST).
  • [C-1-2] 새로운 수신 전화를 표시해야 하며 사용자가 CAPABILITY_SUPPORT_HOLD를 통해 지정된 통화 대기 기능을 지원하지 않는 서드 파티 앱에 의해 발신된 통화 진행 도중 수신 전화를 수락하거나 거부할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
  • [C-1-3] InCallService를 구현하는 애플리케이션이 있어야 합니다(MUST).

  • [C-SR-1] 수신 전화를 수락하면 진행 중인 통화가 끊긴다는 내용을 사용자에게 알릴 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    AOSP 구현은 사용자가 수신 전화를 수락할 경우 다른 통화가 끊긴다는 내용을 나타내는 헤드업 알림으로 이러한 요구사항을 충족합니다.

  • [C-SR-2] 서드 파티 앱이 PhoneAccount의 EXTRA_LOG_SELF_MANAGED_CALLS 추가 키를 true로 설정하는 경우 통화 기록 항목과 서드 파티 앱 이름을 통화 기록에 표시하는 기본 다이얼러 앱을 미리 로드할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • [C-SR-3] 아래처럼 android.telecom API와 관련된 오디오 헤드셋의 KEYCODE_MEDIA_PLAY_PAUSE 및 KEYCODE_HEADSETHOOK 이벤트를 처리할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

7.4.1.3. 모바일 데이터 NAT-T 연결 유지 오프로드

기기 구현은 다음을 충족해야 합니다.

  • 모바일 데이터 연결 유지 오프로드 지원을 포함해야 합니다(SHOULD).

모바일 데이터 연결 유지 오프로드 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SocketKeepAlive API를 지원해야 합니다(MUST).
  • [C-1-2] 모바일 데이터를 통한 동시 연결 유지 슬롯을 하나 이상 지원해야 합니다(MUST).
  • [C-1-3] 무선 라디오 HAL에서 지원하는 만큼의 동시 모바일 데이터 연결 유지 슬롯을 지원해야 합니다(MUST).
  • [C-SR-1] 무선 인스턴스당 모바일 데이터 연결 유지 슬롯을 3개 이상 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

모바일 데이터 연결 유지 오프로드 지원을 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] ERROR_UNSUPPORTED를 반환해야 합니다.

7.4.2. IEEE 802.11(Wi-Fi)

기기 구현은 다음을 충족해야 합니다.

  • 802.11의 형식 중 1개 이상을 지원해야 합니다(SHOULD).

802.11 지원을 포함하고 기능을 서드 파티 애플리케이션에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 해당하는 Android API를 구현해야 합니다(MUST).
  • [C-1-2] 하드웨어 기능 플래그 android.hardware.wifi를 보고해야 합니다(MUST).
  • [C-1-3] SDK 문서에 설명된 것처럼 멀티캐스트 API를 구현해야 합니다(MUST).

15(AOSP 실험용)에 관한 새로운 요구사항 시작

[C-1-4](2023년 12월 11일 미리보기)

  • [C-1-4] 멀티캐스트 DNS(mDNS)를 지원해야 하며(MUST) 화면이 활성 상태가 아닌 경우 등 작업의 어떠한 시점에도 mDNS 패킷(224.0.0.251 또는 ff02::fb)을 필터링하면 안 됩니다(MUST NOT). 단, 타겟 시장에 적용되는 규제 요건에서 요구하는 전력 소비 범위 내에 유지하기 위해 이러한 패킷을 삭제하거나 필터링해야 하는 경우는 예외입니다.

  • [C-1-4] mDNS를 지원해야 하며(MUST), 멀티캐스트 잠금이 적용되어 있지 않고 패킷이 APF에 의해 필터링되지 않는 한 화면이 활성 상태가 아닌 경우를 비롯해 작업의 어떠한 시점에도 mDNS 패킷(224.0.0.251 또는 ff02::fb)을 필터링하면 안 됩니다(MUST NOT). 패킷은 NsdManager API를 통해 애플리케이션에 의해 현재 요구되는 어떠한 mDNS 작업도 충족하도록 요구되지 않습니다. 단, 타겟 시장에 적용되는 규제 요구사항에 따라 요구되는 전원 소비 범위 내에 머물기 위해서는 mDNS 패킷을 필터링해야 하는 경우 기기가 mDNS 패킷을 필터링할 수 있습니다(MAY).

새로운 요구사항 종료

  • [C-1-5] 애플리케이션 트래픽에 기본으로 사용되고 getActiveNetwork 및 registerDefaultNetworkCallback 등의 ConnectivityManager API 메서드에 의해 반환되는 현재 활성화된 Network를 전환하기 위한 충분한 지표로 WifiManager.enableNetwork() API 메서드 호출을 취급하면 안 됩니다(MUST NOT). 즉, Wi-Fi 네트워크가 인터넷 액세스를 제공하고 있음을 정상적으로 확인한 경우에는 다른 네트워크 제공업체(예: 모바일 데이터)에서 제공한 인터넷 액세스만 사용 중지할 수 있습니다(MAY).
  • [C-1-6] ConnectivityManager.reportNetworkConnectivity() API 메서드가 호출되면 Network의 인터넷 액세스를 재평가하는 것이 좋으며, 평가를 통해 현재 Network가 더 이상 인터넷 액세스를 제공하지 않는다는 내용이 파악된 후에는 인터넷 액세스를 제공하는 다른 가용한 네트워크(예: 모바일 데이터)로 전환할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-1-7] STA가 끊긴 동안에는 각 스캔의 시작 부분에서 소스 MAC 주소와 프로브 요청 프레임의 시퀀스 번호를 임의 선택해야 합니다(MUST).
  • [C-1-8] 하나의 일관된 MAC 주소를 사용해야 합니다(MUST). 스캔이 절반 정도 진행되었을 때 MAC 주소를 임의로 선택하면 안 됩니다(MUST NOT).
  • [C-1-9] 하나의 스캔에서 프로브 요청 간에 프로브 요청 시퀀스 번호를 정상적으로(순차적으로) 반복해야 합니다(MUST).
  • [C-1-10] 스캔의 마지막 프로브 요청과 다음 스캔의 첫 번째 프로브 요청 간에 프로브 요청 시퀀스 번호를 임의 선택해야 합니다(MUST).
  • [C-SR-1] 연결이 진행 중인 상태와 연결된 상태에서 액세스 포인트(AP)로의 모든 STA 통신에 사용되는 소스 MAC 주소를 임의 선택할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • 기기는 통신하는 각 SSID(Passpoint용 FQDN)에 서로 다른 임의의 MAC 주소를 사용해야 합니다(MUST).
    • 기기는 사용자에게 무작위로 순서가 지정된 옵션 및 무작위로 순서가 지정되지 않은 옵션으로 SSID(Passpoint용 FQDN)당 무작위 순서 지정을 제어하는 옵션을 제공해야 하며(MUST), 새 Wi-Fi 구성이 무작위로 순서가 지정되는 기본 모드를 설정해야 합니다(MUST).
  • [C-SR-2] 생성하는 모든 AP에 임의의 BSSID를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • MAC 주소는 AP에서 사용하는 SSID에 따라 무작위로 지정되고 유지되어야 합니다(MUST).
    • 기기는 사용자에게 이 기능을 사용 중지할 수 있는 옵션을 제공할 수 있습니다(MAY). 이러한 옵션이 제공되면 무작위 순서 지정이 기본적으로 사용 설정되어야 합니다(MUST).

IEEE 802.11 표준에 정의된 것처럼 Wi-Fi 절전 모드 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • 앱이 데이터를 저장할 때마다 Wi-Fi 절전 모드를 꺼야 합니다(SHOULD). WIFI_MODE_FULL_HIGH_PERF 잠그거나WIFI_MODE_FULL_LOW_LATENCY 잠금을 통해WifiManager.createWifiLock() 그리고WifiManager.WifiLock.acquire() API와 잠금이 활성화되어 있습니다.
  • [C-3-2] 기기가 WiFi 저지연 잠금(WIFI_MODE_FULL_LOW_LATENCY) 모드인 동안의 기기 및 액세스 포인트 간 평균 왕복 지연 시간은 Wi-Fi High Perf 잠금(WIFI_MODE_FULL_HIGH_PERF) 모드 도중의 지연 시간보다 짧아야 합니다(MUST).
  • [C-SR-3] 저지연 잠금(WIFI_MODE_FULL_LOW_LATENCY)이 획득 및 적용될 때마다 Wi-Fi 왕복 지연 시간을 최소화할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

Wi-Fi 및 위치 스캔용 Wi-Fi를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] WifiManager.isScanAlwaysAvailable API 메서드를 통해 읽은 값을 사용 설정/사용 중지할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
7.4.2.1. Wi-Fi Direct

기기 구현은 다음을 충족해야 합니다.

  • Wi-Fi Direct(Wi-Fi P2P) 지원을 포함해야 합니다(SHOULD).

Wi-Fi Direct 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SDK 문서에 설명된 것처럼 해당하는 Android API를 구현해야 합니다(MUST).
  • [C-1-2] 하드웨어 기능 android.hardware.wifi.direct를 보고해야 합니다(MUST).
  • [C-1-3] 일반 Wi-Fi 작업을 지원해야 합니다(MUST).
  • [C-1-4] Wi-Fi 및 Wi-Fi Direct 작업을 동시에 지원해야 합니다(MUST).
  • [C-SR-1] 새로 구성된 모든 Wi-Fi Direct 연결의 소스 MAC 주소를 임의 선택할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

기기 구현은 다음을 충족해야 합니다.

TDLS 지원이 포함되고 TDLS가 WiFiManager API에 의해 사용 설정되는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] WifiManager.isTdlsSupported를 통해 TDLS 지원을 선언해야 합니다(MUST).
  • 가능하고 유용한 경우에만 TDLS를 사용해야 합니다(SHOULD).
  • 어느 정도의 휴리스틱을 보유해야 하며(SHOULD) 성능이 Wi-Fi 액세스 포인트를 통하는 것보다 저조한 경우 TDLS를 사용하면 안 됩니다(SHOULD NOT).
7.4.2.3. Wi-Fi Aware

기기 구현은 다음을 충족해야 합니다.

  • Wi-Fi Aware 지원을 포함해야 합니다(SHOULD).

Wi-Fi Aware 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SDK 문서에 설명된 것처럼 WifiAwareManager API를 구현해야 합니다(MUST).
  • [C-1-2] android.hardware.wifi.aware 기능 플래그를 선언해야 합니다(MUST).
  • [C-1-3] Wi-Fi 및 Wi-Fi Aware 작업을 동시에 지원해야 합니다(MUST).
  • [C-1-4] 30분이 넘지 않는 구간과 Wi-Fi Aware가 사용 설정될 때마다 Aware 범위 지정 작업이 진행 중이거나 Aware 데이터-경로가 활성 상태가 아닌 경우(데이터-경로가 활성 상태인 동안은 무작위 순서 지정이 발생하지 않을 것으로 예상됨)에 한해 Wi-Fi Aware 관리 인터페이스 주소를 무작위로 지정해야 합니다(MUST).

섹션 7.4.2.5에 설명된 것처럼 Wi-Fi Aware 및 Wi-Fi 위치 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

7.4.2.4. Wi-Fi Passpoint

802.11(Wi-Fi) 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Wi-Fi Passpoint 지원을 포함해야 합니다(MUST).
  • [C-1-2] SDK 문서에 설명된 것처럼 WifiManager API와 관련된 Passpoint를 구현해야 합니다(MUST).
  • [C-1-3] GAS(Generic Advertisement Service) 및 ANQP(Access Network Query Protocol) 같은 네트워크 검색 및 선택과 구체적으로 관련된 IEEE 802.11u 표준을 지원해야 합니다(MUST).
  • [C-1-4] android.hardware.wifi.passpoint 기능 플래그를 선언해야 합니다(MUST).
  • [C-1-5] AOSP 구현을 따라 Passpoint 네트워크를 찾고 매칭하고 연결해야 합니다(MUST).
  • [C-1-6] Wi-Fi Alliance Passpoint R2에 정의된 기기 프로비저닝 프로토콜의 최소 하위 집합(EAP-TTLS 인증 및 SOAP-XML)을 지원해야 합니다(MUST).
  • [C-1-7] 핫스팟 2.0 R3 사양에 설명된 대로 AAA 서버 인증서를 처리해야 합니다(MUST).
  • [C-1-8] Wi-Fi 선택 도구를 통한 사용자 프로비저닝 제어를 지원해야 합니다(MUST).
  • [C-1-9] 재부팅 후에도 Passpoint 구성이 유지되어야 합니다(MUST).
  • [C-SR-1] 이용약관 동의 기능을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
  • [C-SR-2] 장소 정보 기능을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

사용자 제어 스위치를 사용 중지하는 전역 Passpoint가 제공되는 경우 구현은 다음을 충족해야 합니다.

  • [C-3-1] Passpoint를 기본적으로 사용 설정해야 합니다(MUST).
7.4.2.5. Wi-Fi 위치(Wi-Fi 왕복 시간 - RTT)

기기 구현은 다음을 충족해야 합니다.

Wi-Fi 위치 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SDK 문서에 설명된 것처럼 WifiRttManager API를 구현해야 합니다(MUST).
  • [C-1-2] android.hardware.wifi.rtt 기능 플래그를 선언해야 합니다(MUST).
  • [C-1-3] RTT가 실행되고 있는 Wi-Fi 인터페이스가 액세스 포인트에 연결되지 않은 상태에서 각 RTT 버스트의 소스 MAC 주소를 임의 선택해야 합니다(MUST).
  • [C-1-4] 누적 배포 함수로 계산한 대로 68번째 백분위수에서 80MHz 대역폭의 2미터 이내까지 정밀해야 합니다(MUST).
  • [C-SR-1] 누적 배포 함수로 계산한 대로 68번째 백분위수에서 80MHz 대역폭의 1.5미터 이내까지 정확하게 보고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
7.4.2.6. Wi-Fi 연결 유지 오프로드

기기 구현은 다음을 충족해야 합니다.

  • Wi-Fi 연결 유지 오프로드 지원을 포함해야 합니다(SHOULD).

Wi-Fi 연결 유지 오프로드 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] SocketKeepAlive API를 지원해야 합니다(MUST).
  • [C-1-2] Wi-Fi를 통한 동시 연결 유지 슬롯을 3개 이상 지원해야 합니다(MUST).

Wi-Fi 연결 유지 오프로드 지원을 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

7.4.2.7. Wi-Fi 간편 연결(기기 프로비저닝 프로토콜)

기기 구현은 다음을 충족해야 합니다.

Wi-Fi 간편 연결 지원을 포함하고 기능을 서드 파티 앱에 노출하는 기기 구현은 다음을 충족해야 합니다.

7.4.2.8. 엔터프라이즈 Wi-Fi 서버 인증서 유효성 검사

Wi-Fi 서버 인증서의 유효성이 검증되지 않거나 Wi-Fi 서버 도메인 이름이 설정되지 않은 경우 기기 구현은 다음을 충족해야 합니다.

  • [C-SR-1] 설정 앱에서 엔터프라이즈 Wi-Fi 네트워크를 수동으로 추가하는 옵션을 사용자에게 제공하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).
7.4.2.9. 처음 사용 시 신뢰(TOFU)

처음 사용 시 신뢰(TOFU)를 지원하고 사용자가 WPA/WPA2/WPA3-Enterprise 구성을 정의하도록 허용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 사용자에게 TOFU 사용을 선택하는 옵션을 제공해야 합니다(MUST).

7.4.3. 블루투스

블루투스 오디오 프로필을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • 고급 오디오 코덱과 블루투스 오디오 코덱(예: LDAC)을 지원해야 합니다(SHOULD).

HFP, A2DP, AVRCP를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • 최소 5개 이상의 기기 연결을 지원해야 합니다(SHOULD).

android.hardware.vr.high_performance 기능을 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] 블루투스 4.2 및 블루투스 LE 데이터 길이 확장 프로그램을 지원해야 합니다(MUST).

Android에는 블루투스 및 블루투스 저전력 지원 기능이 포함되어 있습니다.

블루투스 및 블루투스 저전력 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 관련 플랫폼 기능(각각 android.hardware.bluetooth 및 android.hardware.bluetooth_le)을 선언하고 플랫폼 API를 구현해야 합니다(MUST).
  • 기기에 A2DP, AVRCP, OBEX, HFP 등의 관련 블루투스 프로필을 적절히 구현해야 합니다(SHOULD).

저전력 블루투스(BLE)에 대한 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 하드웨어 기능 android.hardware.bluetooth_le를 선언해야 합니다(MUST).
  • [C-3-2] SDK 문서 및 android.bluetooth에 설명된 것처럼 블루투스 API 기반의 GATT(일반 속성 프로필)를 사용 설정해야 합니다(MUST).
  • [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported()의 올바른 값을 보고하여 ScanFilter API 클래스의 필터링 논리가 구현되었는지 나타내야 합니다(MUST).
  • [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported()의 올바른 값을 보고하여 저전력 광고가 지원되는지 나타내야 합니다(MUST).

  • [C-3-5] 15분 이하의 RPA(Resolvable Private Address) 시간 제한을 구현하고 기기에서 스캔 또는 광고를 위해 BLE를 적극적으로 사용할 경우 시간 초과 시 주소를 순환하여 사용자의 개인 정보를 보호해야 합니다(MUST). 타이밍 공격을 방지하려면 시간 제한 간격도 5~15분이어야 합니다.

  • ScanFilter API 구현 시 블루투스 칩셋에 대한 필터링 논리의 오프로드를 지원해야 합니다(SHOULD).

  • 블루투스 칩셋에 대한 일괄 스캔의 오프로드를 지원해야 합니다(SHOULD).

  • 4개 이상의 슬롯을 포함하는 다중 광고를 지원해야 합니다(SHOULD).

블루투스 LE를 지원하고 위치 스캔에 블루투스 LE를 사용하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 시스템 API BluetoothAdapter.isBleScanAlwaysAvailable()을 통해 판독된 값을 사용 설정/사용 중지할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).

블루투스 LE를 사용한 보청기 오디오 지원에 설명된 것처럼 블루투스 LE 및 보청기 프로필을 포함하는 기기 구현은 다음을 충족해야 합니다.

블루투스 및 블루투스 저전력 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • [C-6-1] 요청하는 앱이 현재 포그라운드/백그라운드 상태에 따라 android.permission.ACCESS_FINE_LOCATION 권한 확인을 성공적으로 전달하지 않는 한 기기의 위치를 얻어내는 데 사용될 수 있는 블루투스 메타데이터(예: 스캔 결과) 액세스를 제한해야 합니다(MUST).

블루투스 또는 저전력 블루투스 지원을 포함하고 있고 블루투스에서 위치를 얻어오지 않는다는 개발자의 선언이 앱 매니페스트에 포함되지 않은 기기 구현은 다음을 충족해야 합니다.

BluetoothAdapter.isLeAudioSupported() API에 true를 반환하는 기기 구현은 다음을 충족해야 합니다.

  • [C-7-1] 유니캐스트 클라이언트를 지원해야 합니다(MUST).
  • [C-7-2] 2M PHY를 지원해야 합니다(MUST).
  • [C-7-3] LE 확장 광고를 지원해야 합니다(MUST).
  • [C-7-4] CIG에서 CIS 연결을 2개 이상 지원해야 합니다(MUST).
  • [C-7-5] BAP 유니캐스트 클라이언트, CSIP 세트 코디네이터, MCP 서버, PVC 컨트롤러, CCP 서버를 동시에 사용 설정해야 합니다(MUST).
  • [C-SR-1] HAP 유니캐스트 클라이언트를 사용 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

BluetoothAdapter.isLeAudioBroadcastSourceSupported() API에 true를 반환하는 기기 구현은 다음을 충족해야 합니다.

  • [C-8-1] BIG에서 BIS 링크를 2개 이상 지원해야 합니다(MUST).
  • [C-8-2] BAP 브로드캐스트 소스, BAP 브로드캐스트 도우미를 동시에 사용 설정해야 합니다(MUST).
  • [C-8-3] LE 주기적 광고를 지원해야 합니다(MUST).

BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API에 true를 반환하는 기기 구현은 다음을 충족해야 합니다.

  • [C-9-1] PAST(Periodic Advertising Sync Transfer)를 지원해야 합니다(MUST).
  • [C-9-2] LE 주기적 광고를 지원해야 합니다(MUST).

FEATURE_BLUETOOTH_LE를 선언하는 기기 구현은 다음을 충족해야 합니다.

  • [C-10-1] 시야 범위 내에서 ADVERTISE_TX_POWER_HIGH로 송신하는 참조 기기로부터 1m 떨어진 거리에서 측정한 값의 95%에 대해 RSSI 측정값이 +/-9dB 이내에 있어야 합니다(MUST).

  • [C-10-2] 3개 채널 각각의 측정값과 안테나 각각의 측정값(안테나를 여러 개 사용하는 경우)이 측정값의 95%에 대해 서로 +/-3dB 이내가 되도록 채널당 편차를 줄이기 위한 Rx/Tx 수정사항을 포함해야 합니다(MUST).

  • [C-10-3] ADVERTISE_TX_POWER_HIGH로 송신하는 참조 기기에서 1m 거리의 BLE RSSI의 중앙값이 -55dBm+/-10dB가 되도록 Rx 오프셋을 측정하고 보상해야 합니다(MUST).

  • [C-10-4] ADVERTISE_TX_POWER_HIGH로 송신하고 1m 떨어진 거리에 배치된 참조 기기에서 스캔할 때 BLE RSSI의 중앙값이 -55dBm+/-10dB가 되도록 Tx 오프셋을 측정하고 보상해야 합니다(MUST).

접속 보정 요구사항에 명시된 측정 설정 단계를 따를 것을 적극 권장합니다(STRONGLY RECOMMENDED).

7.4.4. 근거리 무선통신

기기 구현은 다음을 충족해야 합니다.

  • NFC(근거리 무선통신)와 관련된 트랜시버 및 관련 하드웨어를 포함해야 합니다(SHOULD).
  • [C-0-1] NFC 지원을 포함하지 않거나 android.hardware.nfc 기능을 선언하지 않는 경우에도 android.nfc.NdefMessage 및 android.nfc.NdefRecord API를 구현해야 합니다(MUST). 이는 해당 클래스가 프로토콜과 상관없는 데이터 표시 형식을 나타내기 때문입니다.

NFC 하드웨어를 포함하고 이를 서드 파티 앱에 제공할 예정인 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] android.content.pm.PackageManager.hasSystemFeature() 메서드에서 android.hardware.nfc 기능을 보고해야 합니다(MUST).
  • 아래와 같이 다음 NFC 표준을 통해 NDEF 메시지를 읽고 쓸 수 있어야 합니다(MUST).
  • [C-1-2] NFC 포럼 기술 사양 NFCForum-TS-DigitalProtocol-1.0에 정의된 것처럼 다음 NFC 표준을 통해 NFC 포럼 읽기/쓰기로 기능할 수 있어야 합니다(MUST).
    • NfcA(ISO14443-3A)
    • NfcB(ISO14443-3B)
    • NfcF(JIS X 6319-4)
    • IsoDep(ISO 14443-4)
    • NFC 포럼 태그 유형 1, 2, 3, 4, 5(NFC 포럼에 의해 정의됨)

  • [C-SR-1] 다음 NFC 표준을 통해 NDEF 메시지는 물론 원본 데이터까지 읽고 쓸 수 있을 것을 적극 권장합니다(STRONGLY RECOMMENDED). NFC 표준은 STRONGLY RECOMMENDED로 명시되어 있지만 향후 버전의 호환성 정의에서는 이를 MUST로 변경할 예정입니다. 이러한 표준은 이 버전에서 선택사항이지만 향후 버전에서는 필수로 전환됩니다. 이 Android 버전을 실행하는 기존 기기와 새 기기는 향후 플랫폼 릴리스 버전으로 업그레이드할 수 있도록 이러한 요구사항을 충족할 것을 적극 권장합니다.

  • [C-1-13] NFC 검색 모드에서는 지원되는 모든 기술을 폴링해야 합니다(MUST).

  • 기기가 켜진 상태(화면이 활성화되고 잠금 화면이 잠금 해제된 경우)에서는 NFC 검색 모드여야 합니다(SHOULD).

  • 박막 NFC 바코드 제품의 바코드와 URL(인코딩된 경우)을 읽을 수 있어야 합니다(SHOULD).

위에 언급된 JIS, ISO 및 NFC 포럼 사용에 공개적으로 사용 가능한 링크는 제공되지 않습니다.

Android에는 NFC 호스트 카드 에뮬레이션(HCE) 모드 지원 기능이 포함되어 있습니다.

HCE(NfcA 또는 NfcB용)를 지원하는 NFC 컨트롤러 칩셋을 포함하고 애플리케이션 ID(AID) 라우팅을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] android.hardware.nfc.hce 기능 상수를 보고해야 합니다(MUST).
  • [C-2-2] Android SDK에 정의된 것처럼 NFC HCE API를 지원해야 합니다(MUST).

NfcF용 HCE를 지원하는 NFC 컨트롤러 칩셋을 포함하고 서드 파티 애플리케이션용 기능을 구현하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] android.hardware.nfc.hcef 기능 상수를 보고해야 합니다(MUST).
  • [C-3-2] Android SDK에 정의된 것처럼 NfcF 카드 에뮬레이션 API를 구현해야 합니다(MUST).

이 섹션의 설명처럼 일반 NFC 지원을 포함하고 읽기/쓰기 역할에 MIFARE 기술(MIFARE Classic, MIFARE Ultralight, NDEF on MIFARE Classic)을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] Android SDK에 문서화된 것처럼 해당하는 Android API를 구현해야 합니다(MUST).
  • [C-4-2] android.content.pm.PackageManager.hasSystemFeature()메서드에서 com.nxp.mifare 기능을 보고해야 합니다(MUST). 이는 표준 Android 기능이 아니므로 android.content.pm.PackageManager 클래스에 상수로 표시되지 않습니다.

7.4.5. 네트워킹 프로토콜 및 API

7.4.5.1. 최소 네트워크 기능

기기 구현은 다음을 충족해야 합니다.

  • [C-0-1] 1개 이상의 데이터 네트워킹 형식을 지원해야 합니다(MUST). 구체적으로 기기 구현은 초당 200Kbit 이상의 데이터 표준을 1개 이상 지원해야 합니다(MUST). 이러한 요구사항을 충족하는 기술로는 EDGE, HSPA, EV-DO, 802.11g, 이더넷 및 블루투스 PAN 등이 있습니다.
  • 또한 실제 네트워킹 표준(이더넷 등)이 기본 데이터 연결인 경우 802.11(Wi-Fi)과 같은 범용 무선 데이터 표준 1개 이상 지원을 포함해야 합니다(SHOULD).
  • 1개 이상의 데이터 연결 형식을 구현할 수 있습니다(MAY).
7.4.5.2. IPv6

기기 구현은 다음을 충족해야 합니다.

  • [C-0-2] IPv6 네트워킹 스택을 포함하고 java.net.Socket 및 java.net.URLConnection 등의 관리 API와 AF_INET6 소켓 등의 네이티브 API를 사용하여 IPv6 통신을 지원해야 합니다(MUST).
  • [C-0-3] IPv6을 기본으로 사용 설정해야 합니다(MUST).
    • IPv6 통신이 IPv4 만큼 안정적인지 확인해야 합니다(MUST). 예시는 다음과 같습니다.
      • [C-0-4] 잠자기 모드에서 IPv6 연결을 유지해야 합니다(MUST).
      • [C-0-5] 속도 제한으로 인해 기기가 최소 180초의 RA 전체 기간을 사용하는 모든 IPv6 규격 네트워크에서 IPv6 연결을 손실하면 안 됩니다(MUST NOT).
  • [C-0-6] IPv6 네트워크에 연결되면 네트워크에 대한 직접적인 IPv6 연결 기능을 포함하는 서드 파티 애플리케이션을 제공해야 하며(MUST), 이때 어떠한 형식의 주소 또는 포트 변환도 기기에서 로컬 방식으로 발생하면 안 됩니다. 관리 API(예: Socket#getLocalAddress 또는 Socket#getLocalPort)와 NDK API(예: getsockname() 또는 IPV6_PKTINFO) 모두 네트워크에서 패킷을 전송하고 수신하는 데 실제로 사용되고 인터넷(웹) 서버에 소스 IP와 포트로 표시되는 IP 주소와 포트를 반환해야 합니다(MUST).

IPv6 지원의 필수 수준은 다음 요구사항에 표시된 것처럼 네트워크 유형에 따라 다릅니다.

Wi-Fi를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-1-1] Wi-Fi의 듀얼 스택 및 IPv6 전용 작업을 지원해야 합니다(MUST).

이더넷을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-2-1] 이더넷에서 듀얼 스택 및 IPv6 전용 작업을 지원해야 합니다(MUST).

모바일 데이터를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-3-1] 모바일에서 IPv6 작업(IPv6 전용 및 듀얼 스택)을 지원해야 합니다(MUST).

2개 이상의 네트워크 유형(예: Wi-Fi 및 모바일 데이터)을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • [C-4-1] 기기가 2개 이상의 네트워크 유형에 동시에 연결되는 경우 각 네트워크에서 위의 요구사항을 동시에 충족해야 합니다(MUST).
7.4.5.3. 종속 포털

종속 포털은 인터넷 액세스를 위해 로그인이 필요한 네트워크를 의미합니다.

android.webkit.Webview API의 온전한 구현을 제공하는 기기 구현은 다음을 충족해야 합니다.