Android 호환성 정의 문서 변경 로그

Android 14

2024년 6월 26일

2. 기기 유형

  • 2.2.1. 하드웨어:

    변경사항 보기

    • [7.6.1/H-1-1] 단일 ABI(64비트 전용 또는 32비트 전용)만 지원해야 합니다(MUST).

    변경사항 보기

    새로운 요구사항 시작

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

  • 2.4.1. 하드웨어:

    변경사항 보기

    새로운 요구사항 시작

    Vulkan 지원을 포함하는 시계 기기 구현은 다음을 충족해야 합니다.

  • 2.5.1. 하드웨어:

    변경사항 보기

    새로운 요구사항 시작

    Vulkan 지원을 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

3. 소프트웨어

  • 3.2.2. 빌드 매개변수:

    ODM_SKU 매개변수의 경우:

    변경사항 보기

    필드의 값은 7비트 ASCII로 인코딩해야 하며 ^([0-9A-Za-z.,_-]+)$ 정규 표현식과 일치해야 합니다(MUST).

5. 멀티미디어 호환성

  • 5.1.3. 오디오 코덱 세부정보

    Vorbis 형식/코덱에 대한 세부정보가 추가되었습니다.

    변경사항 보기

    디코딩: 샘플링 레이트가 8000, 12000, 16000, 24000, 48000Hz인 모노, 스테레오, 5.0, 5.1 콘텐츠를 지원합니다.
    인코딩: 샘플링 레이트가 8000, 40.0, 40.0, 12000, 12000, 12000인 모노 및 스테레오 콘텐츠를 지원합니다.

7. 하드웨어 호환성

  • 7.1.4.2 Vulkan

    변경사항 보기

  • 7.7.1. USB 주변기기 모드:

    삭제 항목:

    변경사항 보기

    • Android 오픈소스 프로토콜 2.0 문서에 문서화된 AOAv2 오디오를 구현하면 안 됩니다(SHOULD NOT). AOAv2 오디오는 Android 버전 8.0(API 수준 26)부터 지원 중단됩니다.

9. 보안 모델 호환성

  • 9.7. 보안 기능:

    중복 콘텐츠를 삭제하려면 [C-SR-1] 을(를) [C-SR-7](으)로 변경하고 [C-SR-8]을 삭제했습니다.

    변경사항 보기

    • [C-SR-1] 초기화 이후에 읽기 전용으로 표시된 초기화(예: __ro_after_init)가 진행되는 동안에만 작성된 커널 데이터를 유지할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-2] 커널 코드 및 메모리의 레이아웃을 임의 선택하고 임의 선택을 위협하는 노출(예: /chosen/kaslr-seed Device Tree node 또는 EFI_RNG_PROTOCOL을 통한 CONFIG_RANDOMIZE_BASE 및 부트로더 엔트로피)을 피할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-3] 커널에 CFI(제어 흐름 무결성)을 사용 설정하여 코드 재사용 공격(예: CONFIG_CFI_CLANG 및 CONFIG_SHADOW_CALL_STACK)에 대한 추가적인 보호 기능을 제공할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-4] 사용 설정된 구성요소에서는 CFI(제어 흐름 무결성), SCS(섀도우 호출 스택) 또는 IntSan(정수 오버플로 삭제)을 사용 중지하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-5] CFI 및 IntSan에 설명된 것처럼 보안에 민감한 모든 추가적인 사용자 공간 구성요소에 CFI, SCS 및 IntSan을 사용 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-6] 초기화되지 않은 로컬 변수(CONFIG_INIT_STACK_ALL 또는 CONFIG_INIT_STACK_ALL_ZERO)의 사용을 방지하기 위해 커널에서 스택 초기화를 사용 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 또한 기기 구현은 컴파일러가 로컬 초기화를 하기 위해 사용하는 값을 가정해서는 안 됩니다(SHOULD NOT).

    • [C-SR-7] 초기화되지 않은 힙 할당(CONFIG_INIT_ON_ALLOC_DEFAULT_ON)의 사용을 방지하기 위해 커널에서 힙 초기화를 사용 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 이러한 할당을 초기화할 때 커널에서 사용하는 값을 가정하면 안 됩니다(SHOULD NOT).

  • 9.11. 키 및 사용자 인증 정보:

    변경사항 보기

    • [C-1-6] 다음 중 하나를 지원해야 합니다(MUST).
      • IKeymasterDevice 3.0
      • IKeymasterDevice 4.0
      • IKeymasterDevice 4.1
      • IKeyMintDevice 버전 1 또는
      • IKeyMintDevice 버전 2

  • 9.11.1. 보안 잠금 화면, 인증, 가상 기기:

    변경사항 보기

    • [C-8-3] API를 노출하여 서드 파티 앱에서 잠금 상태를 변경하는 데 사용하도록 하면 안 됩니다(MUST NOT).

    변경사항 보기

    • [C-12-4] TrustManagerService.revokeTrust()를 호출해야 합니다(MUST).
      • 신뢰 부여 후 최대 24시간이 경과한 후
      • 8시간의 유휴 기간 후
      • 구현이 [C-12-5]에 정의된 것처럼 암호화 방식으로 안전하고 정확한 범위를 사용하지 않는 경우 근접한 실제 기기와의 기본 연결이 끊긴 경우.
    • [C-12-5] [C-12-4] 의 요구사항을 충족하기 위해 안전하고 정확한 범위 지정에 의존하는 구현은 다음 솔루션 중 하나를 사용해야 합니다(MUST).
      • UWB를 사용한 구현은 다음을 충족해야 합니다.
        • 7.4.9에 설명된 UWB의 적합성, 인증, 정확성, 보정 요구사항을 충족해야 합니다(MUST).
        • 7.4.9에 나열된 P-STS 보안 모드 중 하나를 사용해야 합니다(MUST).
      • Wi-Fi NAN (Neighborhood Awareness Networking)을 사용한 구현은 다음을 충족해야 합니다.
        • 2.2.1 [7.4.2.5/H-SR-1]의 정확도 요구사항을 충족하고, 160MHz 이상의 대역폭을 사용하고, 접속 보정에 지정된 측정 설정 단계를 따라야 합니다 (MUST).
        • IEEE 802.11az에 정의된 보안 LTF를 사용해야 합니다(MUST).

2024년 4월 8일

2. 기기 유형

  • 2.2.1. 하드웨어:

    변경사항 보기

    새로운 요구사항 시작

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

    • [7.4.3/H-1-3] ADVERTISE_TX_POWER_HIGH로 송신하는 참조 기기에서 1m 거리의 BLE RSSI의 중앙값이 -50dBm+/-15dB가 되도록 Rx 오프셋을 측정하고 보상해야 합니다(MUST).
    • [7.4.3/H-1-4] ADVERTISE_TX_POWER_HIGH로 송신하고 1m 떨어진 거리에 배치된 참조 기기에서 스캔할 때 BLE RSSI의 중앙값이 -50dBm+/-15dB가 되도록 Tx 오프셋을 측정하고 보상해야 합니다(MUST).

  • 2.2.5. 보안 모델:

    변경사항 보기

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

    • [9.8/H-1-6] 성공적인 핫워드 결과마다 핫워드 감지 서비스 외부로 100바이트를 초과하는 데이터를 전송하도록 허용해서는 안 됩니다(MUST NOT). 단, HotwordAudioStream을 통해 전달된 오디오 데이터는 예외입니다.

    변경사항 보기

    [9.8/H-1-13]을 다음과 같이 변경합니다.

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

    변경사항 보기

    요구사항 [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3]을 삭제했습니다.

  • 2.2.7.2. 카메라:

    변경사항 보기

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

    • [7.5/H-1-3] 후면 기본 카메라의 경우 FULL 이상으로, 전면 기본 카메라의 경우 LIMITED 이상으로 android.info.supportedHardwareLevel 속성을 지원해야 합니다(MUST).

  • 2.3.2. 멀티미디어:

    변경사항 보기

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

    • [5.8/T-0-1] 기기가 판매되는 지역의 동영상 화면 재생 빈도에 따라 HDMI 출력 모드를 외부 디스플레이의 50Hz 또는 60Hz 화면 재생 빈도에서 작동하는 선택된 픽셀 형식의 최대 해상도로 설정해야 합니다(MUST). HDMI 출력 모드를 설정하여 50Hz 또는 60Hz 화면 재생 빈도로 지원 가능한 최대 해상도를 선택해야 합니다(MUST).

3. 소프트웨어

5. 멀티미디어 호환성

  • 5.3.8. Dolby Vision

    변경사항 보기

    HDR_TYPE_DOLBY_VISION을 통해 Dolby Vision 디코더 지원을 선언하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-3] 결합된 Dolby Vision 레이어의 트랙 ID와 이전 버전과 호환되는 기본 레이어(있는 경우)의 트랙 ID를 동일하게 설정해야 합니다(MUST).

7. 하드웨어 호환성

  • 7.1.1.1. 화면 크기 및 모양

    변경사항 보기

    UI_MODE_TYPE_NORMAL 크기 구성이 가능한 화면을 지원하고, 모서리가 둥근 물리적 디스플레이를 사용하여 이러한 화면을 렌더링하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 이러한 각 디스플레이는 다음 요구사항 중 하나 이상을 충족해야 합니다(MUST).
      • 1518dp x 1518dp 상자가 논리 디스플레이의 각 모서리에 고정되면 각 상자의 최소 1개 픽셀이 화면에 표시됩니다.

  • 7.4.3. 블루투스:

    변경사항 보기

    다음 요구사항을 복원했습니다.

    FEATURE_BLUETOOTH_LE를 선언하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-2] ADVERTISE_TX_POWER_HIGH로 송신하는 참조 기기 1m 거리에서 BLE RSSI의 중앙값이 -60dBm+/-10dB이 되도록 Rx 오프셋을 측정하고 보상할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 여기서 기기는 '평행 평면'에 위치하도록 방향이 지정되며 화면은 같은 방향을 향합니다.

    • [C-SR-3] ADVERTISE_TX_POWER_HIGH로 송신하고 1m 떨어진 거리에 배치된 참조 기기에서 스캔할 때 BLE RSSI의 중앙값이 -60dBm+/-10dB이 되도록 Tx 오프셋을 측정하고 보상할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 여기서 기기는 '평행 평면'에 위치하도록 방향이 지정되며 화면은 같은 방향을 향합니다.

    변경사항 보기

    요구사항 [C-10-3], [C-10-4]를 2.2.1. 하드웨어로 이동했습니다.

    • [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).

2023년 11월 20일

2. 기기 유형

  • 2.2.1. 하드웨어:

    변경사항 보기

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

  • 2.2.7.2. 카메라:

    변경사항 보기

    • [7.5/H-1-13] RGB 후면 카메라가 2개 이상인 경우 기본 후면 카메라의 LOGICAL_MULTI_CAMERA 기능을 지원해야 합니다(MUST).

  • 2.3.2. 멀티미디어:

    변경사항 보기

    • [5.8/T-0-1] 외부 디스플레이의 50Hz 또는 60Hz 화면 재생 빈도에서 작동하는 선택된 SDR 또는 HDR 형식의 최대 해상도로 HDMI 출력 모드를 설정해야 합니다(MUST).

      HDMI 출력 모드를 설정하여 50Hz 또는 60Hz 화면 재생 빈도로 지원 가능한 최대 해상도를 선택해야 합니다(MUST).

  • 2.4.5. 보안 모델:

    변경사항 보기

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

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

  • 6.1. 개발자 도구:

    변경사항 보기

    • [C-0-12] LMK_KILL_OCCURRED_FIELD_NUMBER Atom을 작성해야 합니다(MUST).

    변경사항 보기

    • [C-0-13] 셸 명령 dumpsys gpu --gpuwork를 구현해야 합니다(MUST).

9. 보안 모델 호환성

  • 9.7. 보안 기능:

    변경사항 보기

    SELinux를 지원할 수 있는 Linux 커널을 사용하는 기기 구현은 다음을 충족해야 합니다.

    변경사항 보기

    Linux 외의 커널 또는 SELinux가 없는 Linux를 사용하는 기기 구현은 다음을 충족해야 합니다.

2023년 10월 4일

2. 기기 유형

  • 2.2. 휴대기기 요구사항

    변경사항 보기

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

    • 화면의 실제 대각선 크기는 4인치3.3인치(API 수준 29 이하에서 출시된 기기 구현의 경우 2.5인치)에서 8인치 사이여야 합니다.

    새로운 요구사항 시작

    • 터치 스크린 입력 인터페이스가 있어야 합니다.

  • 2.2.1. 하드웨어:

    변경사항 보기

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

    • [7.1.1.1/H-0-1] 짧은 가장자리에서 최소 2.2인치, 긴 가장자리에서 최소 3.4인치로 측정되는 이 문서에 설명된 모든 요구사항을 충족하는 Android 호환 디스플레이를 최소 하나 이상 보유해야 합니다(MUST).

    소프트웨어 화면 회전을 지원하는 휴대기기 구현은 다음을 충족해야 합니다.

    • [7.1.1.1/H-1-1]* 서드 파티 애플리케이션에 사용할 수 있는 논리 화면은 짧은 가장자리에서 최소 2인치, 긴 가장자리에서 최소 2.7인치여야 합니다(MUST). Android API 수준 29 이하에서 출시된 기기는 이 요구사항에서 제외될 수 있습니다(MAY).

    소프트웨어 화면 회전을 지원하지 않는 휴대기기 구현은 다음을 충족해야 합니다.

    • [7.1.1.1/H-2-1]* 서드 파티 애플리케이션에 사용할 수 있는 논리 화면은 짧은 가장자리에서 최소 2.7인치여야 합니다(MUST). Android API 수준 29 이하에서 출시된 기기는 이 요구사항에서 제외될 수 있습니다(MAY).

    새로운 요구사항 시작

    • [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).

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

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

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

    1개 이상의 햅틱 액추에이터를 포함하는 휴대기기 구현은 다음을 충족해야 합니다.

    최소 하나의 범용 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.2/H-0-3] AV1

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

    • [5.3/H-0-6] AV1

  • 2.2.3. 소프트웨어:

    변경사항 보기

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

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

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

    • [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).

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

  • 2.2.4. 성능 및 전력

    변경사항 보기

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

    • [8.5/H-0-1] 설정 메뉴 에서 활성 포그라운드 서비스 또는 사용자가 시작한 작업이 있는 모든 앱을 볼 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). 여기에는 SDK 문서에 설명된 것처럼 시작된 각 서비스의 지속 시간도 포함됩니다. 또한 앱의 포그라운드 서비스 표시 및 포그라운드 서비스가 중지되는 기능을 중지할 수 있는 기능을 제공해야 합니다.
      • SDK 문서에 설명한 대로 일부 앱은 이러한 사용자 어포던스에서 중지되거나 나열되는 것에서 제외될 수 있습니다(MAY).

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

  • 2.2.5. 보안 모델:

    변경사항 보기

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

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

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

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

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

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

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

    • [9.8/H-1-1] 핫워드 감지 서비스가 시스템, ContentCaptureService 또는 SpeechRecognizer#createOnDeviceSpeechRecognizer()로 생성된 기기 내 음성 인식 서비스로만 데이터를 전송할 수 있도록 해야 합니다(MUST).
    • [9.8/H-1-6] 성공적인 핫워드 결과마다 핫워드 감지 서비스 외부로 100바이트를 초과하는 데이터(오디오 스트림 제외)를 전송하도록 허용해서는 안 됩니다(MUST NOT).

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

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

    • [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).

  • 2.2.7.1. 미디어:

    변경사항 보기

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

    새로운 요구사항 시작

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

    • [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 디코더 세션 개수를 알려야 합니다(MUST).
    • [5.1/H-1-2] 1080p 해상도@30fps의 세션 3개, 4K 해상도@30fps의 세션 3개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(AV1 제외)(MUST). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.
    • [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 인코더 세션 개수를 알려야 합니다(MUST).
    • [5.1/H-1-4] 1080p 해상도@30fps의 세션 4개, 4K 해상도@30fps의 세션 2개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(AV1 제외)(MUST). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.
    • [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances()와 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행될 수 있는 최대 하드웨어 동영상 인코더 및 디코더 세션 개수를 알려야 합니다(MUST).
    • [5.1/H-1-6] 4K@30fps 해상도(AV1 제외)의 세션 3개(인코더 세션 최대 2개 포함)와 1080p 해상도의 세션 3개와 동시에 실행되는 모든 코덱 조합에서 8비트(SDR) 하드웨어 동영상 디코더 및 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 6개를 지원해야 합니다(MUST). AV1 코덱은 1080p 해상도만 지원해야 하지만 여전히 1080p30fps에서 인스턴스 6개를 지원해야 합니다.
    • [5.1/H-1-19] 4K@30fps 해상도(AV1 제외)의 모든 코덱 조합(이중 최대 1개는 인코더 세션이며, 이 세션은 GL 표시 경로를 통해 RGBA_1010102 입력 형식으로 구성될 수 있음)에서 10비트(HDR) 하드웨어 동영상 디코더 및 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 3개를 지원해야 합니다(MUST). 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 동영상 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.1/H-1-9] 8비트(SDR) 및 10비트(HDR) 콘텐츠 모두 해상도 4K에서 30fps(AV1 제외)로 동시에 실행되는 모든 코덱 조합에서 보안 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 2개를 지원해야 합니다(MUST). AV1 코덱 세션은 이 요구사항에서 4K를 요구하더라도 1080p 해상도만 지원하면 됩니다.
    • [5.1/H-1-10] 4K 해상도@30fps(AV1 제외)의 세션 3개(보안 디코더 세션 1개 포함), 1080p 해상도@30fps의 비보안 세션 1개와 동시에 실행되는 모든 코덱 조합(최대 2개 세션이 10비트 HDR일 수 있음)에서 비보안 하드웨어 동영상 디코더 세션의 인스턴스 3개와 보안 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, AV1 이상)의 인스턴스 1개(총 4개의 인스턴스)를 지원해야 합니다(MUST). 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 동영상 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.1/H-1-14] AV1 하드웨어 디코더 메인 10, 레벨 4.1, 필름 입자 추가를 지원해야 합니다(MUST).
    • [5.1/H-1-15] 4K60을 지원하는 하드웨어 동영상 디코더가 하나 이상 있어야 합니다(MUST).
    • [5.1/H-1-16] 4K60을 지원하는 하드웨어 동영상 인코더가 하나 이상 있어야 합니다(MUST).
    • [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를 사용해야 합니다. 스트리밍 구성의 경우 앱이 자바 AudioTrack을 사용해야 합니다. 짧은 지연 시간과 스트리밍 구성에서 모두 HAL 출력 싱크는 타겟 출력 형식에 맞게 AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT, AUDIO_FORMAT_PCM_FLOAT 중 하나를 허용해야 합니다.
    • [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).
    • [5.12/H-1-1] 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).

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

    • [5.2/H-2-1] 향후 문서에 정의된 대로 하드웨어 AVC 및 HEVC 코덱의 동영상 인코더 속도-왜곡 곡선으로 정의된 최소 품질 타겟을 충족해야 합니다(MUST).

  • 2.2.7.2. 카메라:

    변경사항 보기

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

    • [7.5/H-1-1] 4k@30fps에서 동영상 캡처를 지원하는 최소 12 메가픽셀의 해상도를 가진 기본 후면 카메라가 있어야 합니다(MUST). 기본 후면 카메라는 카메라 ID가 가장 낮은 후면 카메라입니다.
    • [7.5/H-1-2] 해상도가 5메가픽셀 이상인 기본 전면 카메라가 있어야 하며, 1080p@30fps에서 동영상 캡처를 지원해야 합니다(MUST). 기본 전면 카메라는 카메라 ID가 가장 낮은 전면 카메라입니다.
    • [7.5/H-1-3] 두 기본 카메라 모두 android.info.supportedHardwareLevel 속성을 FULL 이상으로 지원해야 합니다(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 캡처 지연 시간이 1000 900ms 미만이어야 합니다(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).

  • 2.2.7.3. 하드웨어:

    변경사항 보기

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

    • [7.1.1.1/H-2-1] 화면 해상도가 1080p 이상이어야 합니다(MUST).
    • [7.1.1.3/H-2-1] 화면 밀도가 400dpi 이상이어야 합니다(MUST).
    • [7.1.1.3/H-3-1] 평균 1,000nit 이상을 지원하는 HDR 디스플레이가 있어야 합니다(MUST).
    • [7.6.1/H-2-1] 실제 메모리 크기가 8GB 이상이어야 합니다(MUST).

  • 2.2.7.4. 실적:

    변경사항 보기

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

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

  • 2.3.2. 멀티미디어:

    변경사항 보기

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

    • [5.2/T-0-3] AV1

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

  • 2.4.5. 보안 모델:

    변경사항 보기

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

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

  • 2.5.1. 하드웨어:

    변경사항 보기

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

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

    외부 뷰 카메라는 후방 카메라와 같이 기기 구현 외부의 장면을 이미지화하는 카메라입니다.

    Automotive 기기 구현:

    • 1개 이상의 외부 뷰 카메라를 포함해야 합니다(SHOULD).

    외부 뷰 카메라를 포함하는 Automotive 기기 구현은 다음을 충족해야 합니다.

    • [7.5/A-1-1] 외부 뷰 카메라가 핵심 요구사항을 준수하지 않는 경우 Android Camera API를 통해 액세스할 수 있게 해서는 안 됩니다(MUST NOT).
    • [7.5/A-SR-1] 카메라 미리보기를 회전하거나 가로로 미러링하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [7.5/A-SR-2] 최소 1.3메가픽셀의 해상도를 갖출 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • 고정 초점 또는 EDOF(필드의 확장 심도) 하드웨어를 보유해야 합니다(SHOULD).
    • 카메라 드라이버에 하드웨어 자동 초점 또는 소프트웨어 자동 초점을 구현할 수 있습니다(MAY).

    1개 이상의 외부 뷰 카메라를 포함하고 EVS(Exterior View System) 서비스를 로드하는 Automotive 기기 구현은 다음을 충족해야 합니다.

    • [7.5/A-2-1] 카메라 미리보기를 회전하거나 가로로 미러링하면 안 됩니다(MUST NOT).

    Automotive 기기 구현:

    • 서드 파티 애플리케이션에서 사용할 수 있는 하나 이상의 카메라를 포함할 수 있습니다(MAY).

    1개 이상의 카메라를 포함하고 이러한 카메라를 서드 파티 애플리케이션에서 사용할 수 있도록 하는 Automotive 기기 구현은 다음을 충족해야 합니다.

    • [7.5/A-3-1] android.hardware.camera.any 기능 플래그를 보고해야 합니다(MUST).
    • [7.5/A-3-2] 카메라를 시스템 카메라로 선언하면 안 됩니다(MUST NOT).
    • 섹션 7.5.3에 설명된 외장 카메라를 지원할 수 있습니다(MAY).
    • 섹션 7.5.1에 설명된 것처럼 후면 카메라에 제공되는 기능(예: 자동 초점 등)을 포함할 수 있습니다(MAY).

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

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

    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).

  • 2.5.3. 소프트웨어:

    변경사항 보기

    Automotive 기기 구현:

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

  • 2.5.5. 보안 모델:

    변경사항 보기

    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][C-3-X]를 사용하여 호출되는 정의된 역할을 보유하고 있는 앱에서만 카메라에 액세스하고 있을 때가 아니라 앱이 실시간 카메라 데이터에 액세스하고 있을 때 카메라 표시기를 표시해야 합니다(MUST).

    • [9.8.2/A-2-3] 설정 앱에서 카메라를 전환하는 사용자 어포던스를 제공해야 합니다(MUST).
    • [9.8.2/A-2-4] PermissionManager.getIndicatorAppOpUsageData()에서 반환될 때 카메라를 사용하는 최근 앱 및 활성 앱과 이러한 앱에 연결된 저작자 표시 메시지를 함께 표시해야 합니다(MUST).

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

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

3. 소프트웨어

  • 3.1. 관리 API 호환성

    변경사항 보기

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

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

  • 3.2.3.5. 조건부 애플리케이션 인텐트:

    변경사항 보기

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

  • 3.3.1. Application Binary Interface:

    변경사항 보기

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

    • [C-0-12] 코어 Vulkan 1.0 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에서는 해당하는 각 함수의 전체 구현이 예상되는 시기와 관련된 요구사항을 상세히 설명합니다.

  • 3.8.6. 테마:

    변경사항 보기

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

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

  • 3.8.8. 활동 전환:

    변경사항 보기

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

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

  • 3.9.2. 관리 프로필 지원

    변경사항 보기

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

    • [C-1-10] 포커스가 있고(사용자가 모든 활동 중에 마지막으로 상호작용한 창) 직장 프로필 앱에 속하는 topActivity 창에서 스크린샷을 캡처할 때 직장 프로필 저장소에 스크린샷 데이터를 저장해야 합니다(MUST).
    • [C-1-11] 개인 프로필 데이터가 직장 프로필에 저장되지 않도록 스크린샷을 직장 프로필에 저장할 때는 직장 프로필 애플리케이션 창을 제외하고 다른 모든 화면 콘텐츠는 캡처하면 안 됩니다(MUST NOT).

  • 3.9.5. 기기 정책 해결 프레임워크: 새로운 섹션

    변경사항 보기

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

    • [C-1-1] AOSP 문서에 설명된 대로 기기 정책 충돌을 해결해야 합니다(MUST).

5. 멀티미디어 호환성

  • 5.1.4. 이미지 인코딩:

    변경사항 보기

    기기 구현은 다음과 같은 이미지 인코딩을 인코딩할 수 있도록 지원해야 합니다(MUST).

    • [C-0-4] AVIF
      • 기기가 BITRATE_MODE_CQ 및 기준 프로필을 지원해야 합니다.

  • 5.1.5. 이미지 디코딩:

    변경사항 보기

    기기 구현은 다음과 같은 이미지 인코딩을 디코딩할 수 있도록 지원해야 합니다(MUST).

    [C-0-7] AVIF(기준 프로필)

  • 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)

  • 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.10. 미디어 코덱 특징 지정:

    변경사항 보기

    기기 구현이 동영상 코덱을 지원하는 경우:

    • [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)

  • 5.2. 동영상 인코딩:

    변경사항 보기

    동영상 인코더를 지원하고 서드 파티 앱에 제공하는 기기 구현은 다음을 충족해야 합니다.

    • 2개의 슬라이딩 윈도우에 걸쳐 intraframe(I-frame) 간격 간의 비트 전송률이 15%를 초과하면 안 됩니다(SHOULD NOT).
    • 1초의 슬라이딩 윈도우에 걸쳐 비트 전송률이 100%를 초과하면 안 됩니다(SHOULD NOT).

    기기 구현이 동영상 인코더를 지원하고 서드 파티 앱에 제공하며
    MediaFormat.KEY_BITRATE_MODE를 BITRATE_MODE_VBR로 설정하여 인코더가 가변 비트 전송률 모드로 작동하도록 하는 경우 최소 품질 하한선에 영향을 주지 않는 한 인코딩된 비트 전송률은 다음을 충족해야 합니다.

    • [C-5-1] MUST 1개의 슬라이딩 윈도우에 걸쳐 intraframe(I-frame) 간격 간의 비트 전송률이 15%를 초과하면 안 됩니다(SHOULDNOT).
    • [C-5-2] MUST 1초의 슬라이딩 윈도우에 걸쳐 비트 전송률이 100%를 초과하면 안 됩니다(SHOULDNOT).

    기기 구현이 동영상 인코더를 지원하고 이를 서드 파티 앱에 제공하며, MediaFormat.KEY_BITRATE_MODE를 BITRATE_MODE_CBR로 설정하여 인코더가 상수 비트 전송률 모드에서 작동하도록 하는 경우 인코딩된 비트 전송률은 다음을 충족해야 합니다.

    • [C-6-1](MUST) [C-SR-2] 1초의 슬라이딩 윈도우에 걸쳐 타겟 비트 전송률을 15% 초과하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 5.2.1. H.263

    변경사항 보기

    H.263 인코더를 지원하고 서드 파티 앱에 제공하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 기준 프로필 레벨 45를 사용하여 QCIF 해상도(176x144)를 지원해야 합니다(MUST). SQCIF 해상도는 선택사항입니다.
    • 지원되는 인코더에 대해 구성 가능한 비트 전송률을 동적으로 지원해야 합니다(SHOULD).

  • 5.2.5. H.265:

    변경사항 보기

    H.265 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 최대 512x512 해상도까지 기본 프로필 레벨 3을 지원해야 합니다(MUST).
    • 다음 표에 표시된 것처럼 HD 인코딩 프로필을 지원해야 합니다(SHOULD).
    • [C-SR-1] 하드웨어 인코더가 있는 경우 다음 표에 나온 대로 720x480 SD 프로필과 HD 인코딩 프로필을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 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.2. H.263

    변경사항 보기

    H.263 디코더를 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 기준 프로필 레벨 30(CIF, QCIF 및 SQCIF 해상도@30fps 384kbps) 및 레벨 45(QCIF 및 SQCIF 해상도@30fps 128kbps)를 지원해야 합니다(MUST).

  • 5.3.9. AV1

    변경사항 보기

    AV1 코덱을 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 10비트 콘텐츠를 포함하는 프로필 0을 지원해야 합니다(MUST).

    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.2. 음성 인식 캡처:

    변경사항 보기

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

    • 90dB 음압 수준(SPL)(마이크와 30cm 거리에서 옆에서 측정됨)에서 재생된 1,000Hz 사인 곡선 톤 소스가 음성 인식 오디오 소스를 녹음하는 데 사용된 모든 마이크별로 16비트 샘플에 대해 1,770~3,530 범위 내 2,500의 RMS를 포함하는 이상적인 응답(또는 부동 소수점/배정밀도 샘플의 경우 -22.35dB ±3dB 풀스케일)을 생성하도록 오디오 입력 민감도를 설정해야 합니다(SHOULD).

  • 5.5.2. 오디오 효과

    변경사항 보기

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

    • [C-1-4] 부동 소수점 입력 및 출력으로 오디오 효과를 지원해야 합니다(MUST).
    • [C-1-5] 오디오 효과가 최대 믹서 채널 개수(FCC_LIMIT라고도 함)까지 여러 채널을 지원해야 합니다(MUST).

  • 5.6. 오디오 지연 시간:

    변경사항 보기

    android.hardware.audio.output를 선언하는 기기 구현은 다음 요구사항을 충족하거나 초과할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-4] AudioTrack.getTimestamp 및 AAudioStream_getTimestamp에 의해 반환된 출력 타임스탬프가 +/- 1ms로 정확해야 합니다.

    • [C-SR-4] AAudioStream_getTimestamp에 의해 반환된 입력 및 출력 타임스탬프를 기반으로 계산된 왕복 지연 시간은 스피커, 유선 및 무선 헤드셋용 AAUDIO_PERFORMANCE_MODE_NONE 및 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY의 왕복 지연 시간 측정치를 기준으로 30msec 내에 포함될 것을 적극 권장합니다(STRONGLY RECOMMENDED).

7. 하드웨어 호환성

  • 7.1. 디스플레이 및 그래픽

    변경사항 보기

    Android에는 기기에 맞게 애플리케이션 애셋과 UI 레이아웃을 적절하게 자동으로 조정하여 서드 파티 애플리케이션이 다양한 하드웨어 구성 다양한 하드웨어 디스플레이 및 구성에서 제대로 실행될 수 있도록 하는 기능이 포함되어 있습니다. Android 호환 디스플레이는 Android 개발자 - 화면 호환성 개요, 이 섹션(7.1) 및 하위 섹션에 설명된 모든 동작 및 API와 이 CDD의 섹션 2에 설명된 추가 기기 유형별 동작을 구현하는 디스플레이 화면입니다.모든 서드 파티 Android 호환 애플리케이션 실행이 가능한 Android 호환 디스플레이에서는 기기 구현이 이 섹션에 상세히 설명된 것처럼 이러한 API와 동작을 제대로 구현해야 합니다(MUST).

    새로운 요구사항 시작

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

    • [C-0-1] 기본적으로 서드 파티 애플리케이션을 Android 호환 디스플레이에만 렌더링해야 합니다(MUST).

    이 섹션의 요구사항에 의해 참조되는 단위는 다음과 같이 정의됩니다.

    • 실제 대각선 크기. 조명이 들어온 디스플레이 부분의 두 반대편 모서리 사이의 거리(인치)입니다.
    • 인치당 도트 수(dpi)밀도. 직선형 가로 또는 세로 범위 1인치에 둘러싸인 픽셀 수입니다. 인치당 픽셀 수로 표시됩니다(ppi 또는 dpi). dpi ppi 및 dpi 값이 나열된 경우 가로 및 세로 dpi는 모두 나열된 범위 내에 속해야 합니다.
    • 가로세로 비율. 화면의 짧은 크기에 대한 긴 크기의 픽셀 비율입니다. 예를 들어 480x854픽셀인 디스플레이는 854/480 = 1.779 또는 대략 '16:9'가 됩니다.
    • 밀도 독립형 픽셀(dp). 160dpi 화면 화면 밀도 160으로 정규화된 가상 픽셀 단위입니다. 일부 밀도 d와 픽셀 수 p의 경우 밀도 독립형 픽셀 수 dp는 다음과 같이 계산됩니다. 픽셀 = dps * (밀도/160) dp = (160 / d) * p

  • 7.1.1.1. 화면 크기 및 모양

    변경사항 보기

    UI_MODE_TYPE_NORMAL 크기 구성이 가능한 화면을 지원하고, Android 호환 모서리가 둥근 물리적 디스플레이를 사용하여 이러한 화면을 렌더링하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 이러한 각 디스플레이는 다음 요구사항 중 하나 이상을 충족해야 합니다(MUST).
    • 둥근 모서리의 반경이 38dp 이하입니다.

    • 15dp x 15dp 상자가 논리 디스플레이의 각 모서리에 고정되면 각 상자의 최소 1개 픽셀이 화면에 표시됩니다.

    • 모서리가 직사각형인 디스플레이 모드로 전환할 수 있도록 사용자 어포던스를 포함해야 합니다(SHOULD).

    새로운 요구사항 시작

    NO_KEYS 키보드 구성만 가능하고 UI_MODE_TYPE_NORMAL UI 모드 구성 지원을 보고하려는 기기 구현은 다음을 충족해야 합니다.

    • [C-4-1] 596dpx384dp 이상의 레이아웃 크기(디스플레이 컷아웃 제외)를 보유해야 합니다(MUST).

    폴더블 Android 호환 디스플레이를 포함하거나, 여러 디스플레이 패널 사이에 접히는 힌지를 포함하고 그러한 디스플레이로 서드 파티 앱을 렌더링 할 수 있는 기기 구현은 다음을 충족해야 합니다.

    접을 수 있는 Android 호환 디스플레이를 포함하거나, 여러 디스플레이 패널 사이에 접히는 힌지를 포함하고 해당 힌지 또는 폴드가 전체 화면 애플리케이션 창을 반으로 가르는 기기 구현은 다음을 충족해야 합니다.

    • [C-3-1] 확장 API 또는 사이드카 API를 통해 힌지 또는 폴드의 위치, 경계 및 상태를 애플리케이션에 보고해야 합니다(MUST).

    접을 수 있는 Android 호환 디스플레이 영역을 하나 이상 포함하거나 여러 Android 호환 디스플레이 패널 영역 간에 접히는 힌지를 포함하고 이러한 디스플레이 영역을 애플리케이션에서 사용할 수 있도록 하는 기기 구현은 다음을 충족해야 합니다.

    • [C-4-1] 향후 문서에 설명된 대로 올바른 버전의 Window Manager 확장 프로그램 API 수준을 구현해야 합니다(MUST).

  • 7.1.1.2. 화면 가로세로 비율: 삭제됨

  • 7.1.1.3. 화면 밀도:

    변경사항 보기

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

    • [C-0-1] 기본적으로 기기 구현은 DENSITY_DEVICE_STABLE API를 통해 DisplayMetrics에 나열된 Android 프레임워크 밀도 중 하나만를 보고해야 하며(MUST) 이 값은 각 물리적 디스플레이의 정적 값이어야 합니다. 아무 때나 변경하면 안 됩니다(MUST NOT). 하지만, 기기는 초기 부팅 후에 사용자가 설정한 디스플레이 구성 변경사항(예: 디스플레이 크기)에 따라 다른 임의의 밀도 DisplayMetrics.density를 보고할 수도 있습니다(MAY).

    • 기기 구현은 논리 밀도가 지원하는 최솟값보다 보고된 화면 크기를 더 줄이지 않는 한 화면의 실제 밀도에 수치적으로 가장 근접한 값으로 표준 Android 프레임워크 밀도를 정의해야 합니다(SHOULD). 화면 크기의 실제 밀도 결과와 수치적으로 가장 근접한 표준 Android 프레임워크 밀도가 지원 및 호환되는 화면의 가장 작은 크기(너비 320dp)보다 작은 경우 기기 구현은 그다음으로 낮은 표준 Android 프레임워크 밀도를 보고해야 합니다(SHOULD).

    새로운 요구사항 시작

    • 화면의 물리적 밀도에 수치상으로 가장 근접한 표준 Android 프레임워크 밀도 또는 휴대기기의 상응하는 동일한 각도 시야 측정값에 매핑되는 값을 정의해야 합니다(SHOULD).

    기기의 디스플레이 크기를 변경하는 어포던스가 있으면 를 제공하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] 디스플레이 크기는 DENSITY_DEVICE_STABLE 기본 밀도의 1.5배보다 크게 디스플레이를 확장하거나 320dp(리소스 한정자 sw320dp와 같음)보다 작은 유효한 최소 화면 크기를 생성해서는 안 됩니다(순서는 상관없음)(MUST NOT).
    • [C-1-2] 디스플레이 크기는 DENSITY_DEVICE_STABLE 기본 밀도의 0.85배 미만으로 디스플레이를 조정하면 안 됩니다(MUST NOT).

  • 7.1.4.2 Vulkan

    변경사항 보기

    Vulkan 1.0 이상 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-3] 열거된 각 VkPhysicalDevice에 대해 Vulkan 1.0 Vulkan 1.1 API를 구현해야 합니다(MUST).

    • [C-1-5] 애플리케이션 패키지 외의 라이브러리에서 제공된 레이어를 나열하거나 Vulkan API를 추적하거나 가로챌 수 있는 다른 방법을 제공하면 안 됩니다(MUST NOT). 단, 애플리케이션의 android:debuggable 속성이 true로 설정되어 있거나 메타데이터 com.android.graphics.injectLayers.enable이 true로 설정된 경우는 예외입니다.

    • VkPhysicalDeviceProtectedMemoryFeatures 및 VK_EXT_global_priority를 지원해야 합니다(SHOULD).

    • [C-SR-5] VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory 및 VK_EXT_global_priority를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-6] HWUI와 함께 SkiaVk를 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    Vulkan 1.1 지원을 포함하고 여기에 설명된 Vulkan 기능 플래그를 선언하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-7] VK_KHR_external_fence_fd 확장 프로그램을 서드 파티 애플리케이션에 제공하고 애플리케이션이 펜스 페이로드를 POSIX 파일 설명자에 내보내고 POSIX 파일 설명자에서 펜스 페이로드를 가져올 수 있도록 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED)(여기 참고).

  • 7.3.10. 생체 인식 센서:

    변경사항 보기

    여러 개의 생체 인식 센서가 있는 기기 구현은 다음을 충족해야 합니다.

    • [C-7-1] 너무 여러 번 시도가 실패하여 생체 인식이 잠금 상태(즉, 사용자가 기본 인증으로 잠금 해제할 때까지 생체 인식이 사용 중지됨) 또는 시간 제한 잠금 상태(즉, 사용자가 시간 간격을 기다릴 때까지 생체 인식이 일시적으로 사용 중지됨)가 된 경우 하위 생체 인식 클래스의 다른 모든 생체 인식도 잠금 상태가 되어야 합니다(MUST). 시간 제한 잠금의 경우 생체 인식 인증의 백오프 시간은 시간 제한 잠금에서 모든 생체 인식의 최대 백오프 시간이어야 합니다(MUST).

    • [C-SR-12] 너무 여러 번 시도가 실패하여 생체 인식이 잠금 상태(즉, 사용자가 기본 인증으로 잠금 해제할 때까지 생체 인식이 사용 중지됨) 또는 시간 제한 잠금 상태(즉, 사용자가 시간 간격을 기다릴 때까지 생체 인식이 일시적으로 사용 중지됨)가 된 경우 동일한 생체 인식 클래스의 다른 모든 생체 인식도 잠금 상태가 될 것을 적극 권장합니다(STRONGLY RECOMMENDED). 시간 제한 잠금의 경우 생체 인식 인증의 백오프 시간은 시간 제한 잠금에서 모든 생체 인식의 최대 백오프 시간일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-7-2] 잠겨 있는 생체 인식의 잠금 카운터를 재설정하기 위해 사용자에게 권장되는 기본 인증(예: PIN, 패턴, 비밀번호)을 요구해야 합니다(MUST). 클래스 3 생체 인식은 동일하거나 낮은 클래스의 잠긴 생체 인식에 관한 잠금 카운터를 재설정할 수 있습니다(MAY). 클래스 2 또는 클래스 1 생체 인식은 생체 인식에 관한 잠금 재설정 작업을 완료해서는 안 됩니다(MUST NOT).

    생체 인식 센서를 클래스 1(이전의 편의)로 취급하려는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-12] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 40% 이하여야 합니다(MUST).

    • [C-SR-13] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 30% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-14] 생체 인식 센서의 생체 인식 클래스와 이를 사용 설정하는 해당 위험을 공개할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-SR-17] 새 AIDL 인터페이스(예: IFace.aidl 및 IFingerprint.aidl)를 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    생체 인식 센서를 클래스 2(이전의 약함)로 취급하려는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-15] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 20% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [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-7] 식별 가능한 생체 인식 데이터나 여기에서 파생된 데이터(퍼가기 등)에 대한 암호화되지 않은 액세스를 TEE 컨텍스트 또는 섹션 9.17의 요구사항을 충족하는 하이퍼바이저에 의해 제어되는 보호된 가상 머신 외의 애플리케이션 프로세서에 허용하면 안 됩니다(MUST NOT). Android 버전 9 이하에서 출시된 기기 업그레이드는 C-2-7에서 제외되지 않습니다.

    생체 인식 센서를 클래스 3(이전의 강함)으로 취급하려는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-16] Android 생체 인식 테스트 프로토콜에 따라 측정된 스푸핑 및 위장 수락률이 프레젠테이션 공격 도구(PAI) 종당 7% 이하일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 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.1. 전화:

    변경사항 보기

    Android API와 이 문서에서 사용되는 '전화 통신'이란 구체적으로 모바일(예: GSM, CDMA, LTE, NR) GSM 또는 CDMA 네트워크를 통해 음성 통화를 걸고 SMS 메시지를 전송하거나 모바일 데이터를 설정하는 것과 관련된 하드웨어를 의미합니다. '전화 통신'을 지원하는 기기는 제품에 맞게 통화, 메시지, 데이터 서비스의 일부 또는 전부를 제공하도록 선택할 수 있습니다.

    GSM 또는 CDMA 네트워크를 통해 이러한 음성 통화는 패킷 교환 방식이거나 이러한 방식이 아닐 수도 있지만 같은 네트워크를 사용하여 구현될 수 있는 모든 데이터 연결과 별개로 간주되는 Android의 목적과 관련이 있습니다. 즉, Android '전화 통신' 기능과 API란 구체적으로 음성 통화와 SMS를 의미합니다. 예를 들어 음성 통화를 걸거나 SMS 메시지를 전송/수신할 수 없는 기기 구현은 데이터 연결을 위해 셀룰러 네트워크를 사용하는지 여부와 상관없이 통신 기기로 간주되지 않습니다.

  • 7.4.2. IEEE 802.11 (Wi-Fi)

    변경사항 보기

    802.11 지원을 포함하고 기능을 서드 파티 애플리케이션에 노출하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-4] 멀티캐스트 DNS(mDNS)를 지원해야 하며(MUST) 다음을 비롯한 작업의 어떠한 시점에도 mDNS 패킷(224.0.0.251 또는 ff02::fb)을 필터링하면 안 됩니다(MUST NOT). 화면이 활성 상태가 아닌 경우. 타겟 시장에 적용되는 규제 요건에서 요구하는 전력 소비 범위 내에 유지하기 위해 이러한 패킷을 삭제하거나 필터링해야 하는 경우는 예외입니다. 대기 중 절전 모드 상태인 경우(Android 텔레비전 기기 구현의 경우).

  • 7.4.3. 블루투스:

    변경사항 보기

    FEATURE_BLUETOOTH_LE를 선언하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-2] ADVERTISE_TX_POWER_HIGH로 송신하는 참조 기기 1m 거리에서 BLE RSSI의 중앙값이 -60dBm+/-10dB이 되도록 Rx 오프셋을 측정하고 보상할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 여기서 기기는 '평행 평면'에 위치하도록 방향이 지정되며 화면은 같은 방향을 향합니다.
    • [C-SR-3] ADVERTISE_TX_POWER_HIGH로 송신하고 1m 떨어진 거리에 배치된 참조 기기에서 스캔할 때 BLE RSSI의 중앙값이 -60dBm+/-10dB이 되도록 Tx 오프셋을 측정하고 보상할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 여기서 기기는 '평행 평면'에 위치하도록 방향이 지정되며 화면은 같은 방향을 향합니다.

    • [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).

    블루투스 버전 5.0을 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-4] 다음을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • LE 2M PHY
    • LE 코덱 PHY
    • LE 광고 확장
    • 주기적인 광고
    • 광고 세트 10개 이상
    • LE 동시 연결 8개 이상. 각 연결은 두 연결 토폴로지 역할 중 하나에 있을 수 있습니다.
    • LE 링크 레이어 개인 정보 보호
    • 8개 이상의 항목으로 구성된 '해결 목록' 크기

  • 7.4.9. UWB

    변경사항 보기

    • [C-1-7] 참조 기기에서 1m 떨어진 지점에서 측정한 거리 측정값의 중앙값이 [0.75m, 1.25m] 이내에 있도록 해야 합니다(MUST). 여기서 지상 실측 거리는 전면이 위로 향하고 45도 기울어진 DUT의 상단 가장자리에서 측정됩니다.

  • 7.5.1. 후면 카메라:

    변경사항 보기

    후면 카메라는 기기 디스플레이 반대편에 위치한 카메라입니다. 즉, 기존 카메라처럼 기기 맞은편의 장면을 이미지화합니다.

    후면 카메라는 기존 카메라처럼 기기의 반대편에 있는 장면을 촬영하는 바깥쪽 카메라입니다. 즉, 기기에서 디스플레이 반대편에 있는 카메라입니다

  • 7.5.2. 전면 카메라:

    변경사항 보기

    전면 카메라는 기기 디스플레이와 같은 쪽에 위치한 카메라입니다. 이 카메라는 보통 사용자를 이미지화하는 데 사용됩니다(예: 화상 회의 및 유사 애플리케이션).

    전면 카메라는 일반적으로 화상 회의나 유사 애플리케이션에서 사용자를 촬영하는 데 사용되는 사용자 대상 카메라이며, 디스플레이와 같은 쪽에 위치한 카메라입니다.

  • 7.5.3. 외장 카메라:

    변경사항 보기

    외장 카메라는 기기 구현에서 언제든지 물리적으로 연결하거나 분리할 수 있으며 USB 카메라처럼 방향이 상관이 없는 카메라입니다.

  • 7.5.4. 카메라 API 동작:

    변경사항 보기

    기기 구현은 가용한 모든 카메라에 대해 다음과 같은 카메라 관련 API의 동작을 구현해야 합니다(MUST). 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-1] 서로 가까이에 있으며 같은 방향을 바라보는 여러 RGB 카메라를 포함하는 기기의 경우 실제 하위 기기와 같은 방향을 바라보는 모든 RGB 카메라로 구성된 기능 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA를 나열하는 논리 카메라 기기를 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 7.5.5. 카메라 방향:

    변경사항 보기

    다음 기준을 모두 충족하는 기기는 위 요구사항에서 제외됩니다.

    • 자동차 기기와 같이 사용자가 기기 구현을 회전할 수 없는 경우

  • 7.10. 햅틱

    변경사항 보기

    손에 쥐거나 착용하도록 고안된 기기에는 벨소리, 알람, 알림 및 일반 터치 피드백을 통해 주의를 끄는 등의 목적을 위해 애플리케이션에 제공되는 범용 햅틱 액추에이터가 포함될 수 있습니다.

    이러한 범용 햅틱 액추에이터를 포함하지 않는(DO NOT) 기기 구현은 다음을 충족해야 합니다.

    • [7.10/C] Vibrator.hasVibrator()에 false를 반환해야 합니다(MUST).

    이러한 범용 햅틱 액추에이터를 하나 이상 포함하는(DO) 기기 구현은 다음을 충족해야 합니다.

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

    섹션 2.2.1에서 기기별 요구사항을 참고하세요.

9. 보안 모델 호환성

  • 9.1. 권한:

    변경사항 보기

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

    • [C-0-4] 두 사용자 인터페이스의 고유한 구현을 하나만 보유해야 합니다(MUST).

    기기 구현이 시스템 UI 인텔리전스, 시스템 주변 오디오 인텔리전스, 시스템 오디오 인텔리전스, 시스템 알림 인텔리전스, 시스템 텍스트 인텔리전스 또는 시스템 영상 인텔리전스 역할을 보유한 패키지를 사전 설치하면 이러한 패키지는 다음을 충족해야 합니다.

    • [C-4-1] '9.8.6 콘텐츠 캡처' '9.8.6 OS 수준 및 대기 데이터와 9.8.15 샌드박스 API 구현' 섹션에 설명된 기기 구현 요구사항을 모두 충족해야 합니다(MUST).

    • [C-4-2] android.permission.INTERNET 권한을 보유하면 안 됩니다(MUST NOT). 이는 섹션 9.8.6에 나열된 STRONGLY RECOMMENDED보다 엄격합니다.
    • [C-4-3] 블루투스, 연락처, 미디어, 전화 통신, SystemUI 및 인터넷 API를 제공하는 구성요소를 제외하고 다른 앱에 결합하면 안 됩니다(MUST NOT). 이는 섹션 9.8.6에 나열된 STRONGLY RECOMMENDED보다 엄격합니다.

    VoiceInteractionService를 지원하는 기본 애플리케이션을 포함하는 기기 구현은 다음을 충족해야 합니다.

    • [C-5-1] ACCESS_FINE_LOCATION을 해당 애플리케이션의 기본값으로 부여하면 안 됩니다(MUST NOT).

  • 9.5. 멀티 사용자 지원:

    변경사항 보기

    위에서 설명한 추가 사용자 프로필을 만드는 기기 구현은 다음을 충족해야 합니다.

    • [C-4-5] 듀얼 인스턴스 애플리케이션 아이콘이 사용자에게 표시될 때 시각적으로 인식해야 합니다(MUST).
    • [C-4-6] 전체 클론 프로필 데이터를 삭제하기 위한 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-4-7] 사용자가 전체 클론 프로필 데이터 삭제를 선택하면 모든 클론 앱을 제거하고 비공개 앱 데이터 디렉터리 및 해당 콘텐츠를 삭제하며 클론 프로필 데이터를 삭제해야 합니다(MUST).
    • 마지막 클론 앱이 삭제되면 사용자에게 전체 클론 프로필 데이터를 삭제하라는 메시지를 표시해야 합니다(SHOULD).
    • [C-4-8] 클론 애플리케이션이 제거되면 앱 데이터가 삭제된다고 사용자에게 알리거나 애플리케이션이 기기에서 제거될 때 앱 데이터를 유지하는 옵션을 사용자에게 제공해야 합니다(MUST).
    • [C-4-9] 사용자가 제거 중에 데이터를 삭제하도록 선택한 경우 비공개 앱 데이터 디렉터리 및 콘텐츠를 삭제해야 합니다(MUST).

    • [C-4-14] 이 추가 프로필에서 실행되는 애플리케이션에 대해 별도의 권한을 보유하고 저장소를 관리해야 합니다(MUST).

    • [C-4-5] 런처 활동이 있는 추가 프로필의 애플리케이션만 상위 사용자 프로필이 이미 액세스할 수 있는 연락처에 액세스하도록 허용해야 합니다(MUST).

  • 9.7. 보안 기능:

    변경사항 보기

    메모리 안전 기술은 android:memtagMode 매니페스트 옵션을 사용하는 애플리케이션에서 높은 (90% 초과) 확률로 최소한 다음 버그 클래스를 완화하는 기술입니다.

    • 힙 버퍼 오버플로
    • 해제 후 사용
    • 이중 해제
    • 와일드 해제(malloc이 아닌 포인터 없음)

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

    • [C-SR-15] ro.arm64.memtag.bootctl_supported를 설정할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    시스템 속성 ro.arm64.memtag.bootctl_supported를 true로 설정하는 기기 구현은 다음을 충족해야 합니다.

    • [C-3-1] 시스템 속성 arm64.memtag.bootctl이 다음 값의 쉼표로 구분된 목록을 허용하도록 해야 하며(MUST) 다음 번 재부팅 시 원하는 효과가 적용됩니다.

      • memtag: 위에 정의된 메모리 안전 기술이 사용 설정됩니다.
      • memtag-once: 위에 정의된 메모리 안전 기술이 일시적으로 사용 설정되고 다음 재부팅 시 자동으로 사용 중지됩니다.
      • memtag-off: 위에 정의된 메모리 안전 기술이 사용 중지됩니다.

    • [C-3-2] 셸 사용자가 arm64.memtag.bootctl을 설정하도록 허용해야 합니다(MUST).

    • [C-3-3] 모든 프로세스가 arm64.memtag.bootctl을 읽도록 허용해야 합니다(MUST).

    • [C-3-4] 부팅 시 arm64.memtag.bootctl을 현재 요청된 상태로 설정해야 하며(MUST) 기기 구현이 시스템 속성을 변경하지 않고 상태를 수정하도록 허용하는 경우 속성도 업데이트해야 합니다(MUST).

    • [C-SR-16] memtag-once를 설정하고 기기를 재부팅하는 개발자 설정을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 호환되는 부트로더를 사용하면 Android 오픈소스 프로젝트가 MTE 부트로더 프로토콜을 통해 위의 요구사항을 충족합니다.

    • [C-SR-17] 사용자가 memtag를 사용 설정할 수 있는 설정을 보안 설정 메뉴에 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 9.8.2. 녹화:

    변경사항 보기

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

    • [C-0-2] MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay() 또는 독점 API를 통해 화면 전송 또는 화면 녹화가 사용 설정될 때마다을 캡처하는 세션이 시작될 때마다 AOSP와 정확히 동일한 메시지를 포함하는 사용자의 화면에 표시되는 민감한 정보가 캡처될 수 있도록 사용자 경고를 표시하고 명시적인 사용자 동의를 획득해야 합니다(MUST). 사용자에게 향후 사용자 동의 표시를 사용 중지하기 위한 어포던스를 제공하면 안 됩니다(MUST NOT).

    • [C-SR-1] AOSP에 구현된 메시지와 정확히 동일하지만 메시지에서 사용자 화면의 민감한 정보가 캡처된다고 사용자에게 명확히 경고하는 한 변경될 수 있는(CAN) 사용자 경고를 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • [C-0-4] 사용자가 android.app.role.COMPANION_DEVICE_APP_STREAMING 또는 android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING 기기 프로필과 associate()하도록 허용한 시스템 앱에서 세션이 시작되지 않는 한 화면을 캡처하기 위한 향후 사용자 동의 메시지를 사용 중지하는 어포던스를 사용자에게 제공하면 안 됩니다(MUST NOT).

  • 9.8.6. OS 수준 및 대기 데이터: 이 섹션은 콘텐츠 캡처 및 앱 검색에서 OS 수준 및 대기 데이터로 이름이 변경되었습니다.

    변경사항 보기

    System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query 또는 기타 전용 수단를 사용하는 Android는 기기 구현이 다음과 같은 애플리케이션 및 사용자 간 애플리케이션 데이터의 상호작용 민감한 데이터를 캡처할 수 있도록 메커니즘을 지원합니다.

    • AugmentedAutofillService를 통해 시스템에 전송되는 모든 화면 또는 기타 데이터
    • Content Capture API를 통해 액세스할 수 있는 모든 화면 또는 기타 데이터
    • FieldClassificationService API를 통해 액세스할 수 있는 모든 화면 또는 기타 데이터
    • AppSearchManager API를 통해 시스템에 전달되고 AppSearchGlobalManager.query를 통해 액세스할 수 있는 모든 애플리케이션 데이터

    • Content Capture 또는 Android 및 독점 API와 비슷한 기능을 가진 AppSearchManager API를 통해 애플리케이션이 시스템에 제공하는 기타 이벤트

    • 음성 인식기 구현에서 SpeechRecognizer#onDeviceSpeechRecognizer()를 사용하여 얻은 오디오 데이터
    • AudioRecord, SoundTrigger 또는 기타 오디오 API를 통해 백그라운드에서 연속적으로 얻은 오디오 데이터이며 사용자에게 표시되는 표시기가 아님
    • CameraManager 또는 기타 카메라 API를 통해 백그라운드에서 연속적으로 가져오는 카메라 데이터이며 사용자에게 표시되는 표시기가 아님

    위의 데이터 중 하나를 캡처하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-3] 데이터를 공유할 때마다 명시적인 사용자 동의를 얻는 경우를 제외하고 개인 정보 보호 메커니즘만 사용하여 이러한 모든 데이터 및 로그를 기기 외부로 전송해야 합니다(MUST). 개인 정보 보호 메커니즘은 '집계 분석만 허용하고 로깅된 이벤트나 파생된 결과가 개별 사용자에게 매칭되지 않도록 하는 메커니즘'으로 정의됩니다. 이는 사용자별 데이터가 내부에서 분석(예: RAPPOR 등의 개인 정보 차등 보호 기술을 사용하여 구현됨)되지 않도록 하기 위한 것입니다.

    • [C-1-5] 공유될 때마다 명시적으로 사용자 동의를 얻는 경우를 제외하고 이러한 데이터를 현재 섹션(9.8.6 콘텐츠 캡처 OS 수준 및 대기 데이터)에 설명된 요구사항을 따르지 않는 다른 OS 구성요소와 공유하면 안 됩니다(MUST NOT). 이러한 기능이 Android SDK API(AmbientContext, HotwordDetectionService)로 빌드되는 경우는 예외입니다.

    • [C-1-6] 데이터가 기기에 어떠한 형식으로든 저장되는 경우 저장될 때 ContentCaptureService 구현 또는 전용 수단이 수집하는 이러한 데이터를 삭제할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). 사용자가 데이터 삭제를 선택하는 경우 수집된 모든 이전 데이터를 삭제해야 합니다(MUST).

    • [C-SR-3] Android SDK API 또는 유사한 OEM 소유 오픈소스 저장소로 구현하거나 샌드박스 구현(9.8.15 샌드박스 처리된 API 구현 참고)에서 실행할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    Android는 SpeechRecognizer#onDeviceSpeechRecognizer()를 통해 네트워크를 사용하지 않고 기기에서 음성 인식을 실행할 수 있는 기능을 제공합니다. 기기 내 SpeechRecognizer 구현은 이 섹션에 설명된 정책을 따라야 합니다(MUST).

  • 9.8.10. 연결 버그 신고:

    변경사항 보기

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

    • [C-1-4] BUGREPORT_MODE_TELEPHONY를 사용하여 생성된 보고서에는 최소한 다음 정보가 포함되어야 합니다.
      • SubscriptionManagerService 덤프

  • 9.8.14. 인증 관리자: 삭제됨

  • 9.8.15. 샌드박스 API 구현: 새로운 섹션

    변경사항 보기

    Android는 여러 위임 API를 통해 보안 OS 수준 및 대기 데이터를 처리하는 메커니즘을 제공합니다. 이러한 처리는 권한 있는 액세스와 축소된 통신 기능(샌드박스 API 구현이라고 함)을 사용하여 사전 설치된 APK에 위임될 수 있습니다.

    모든 샌드박스 API 구현은 다음을 충족해야 합니다.

    • [C-0-1] INTERNET 권한을 요청하면 안 됩니다(MUST NOT).
    • [C-0-2] 개인 정보 보호 메커니즘을 통해 공개적으로 사용 가능한 오픈소스 구현으로 지원되는 구조화된 API 또는 Android SDK API를 통한 간접적인 방식으로만 인터넷에 액세스해야 합니다(MUST). 개인 정보 보호 메커니즘은 '집계 분석만 허용하고 로깅된 이벤트나 파생된 결과가 개별 사용자에게 매칭되지 않도록 하는 메커니즘'으로 정의됩니다. 이는 사용자별 데이터가 내부에서 분석(예: RAPPOR 등의 개인 정보 차등 보호 기술을 사용하여 구현됨)되지 않도록 하기 위한 것입니다.
    • [C-0-3] 서비스는 다음 항목을 제외하고 다른 시스템 구성요소와 별도로 유지해야 합니다(예: 서비스를 바인딩하지 않거나 프로세스 ID를 공유하지 않음)(MUST).
      • 전화 통신, 연락처, 시스템 UI 및 미디어
    • [C-0-4] 사용자가 서비스를 사용자가 설치할 수 있는 애플리케이션 또는 서비스로 대체하도록 허용해서는 안 됩니다(MUST NOT).
    • [C-0-5] 사전 설치된 서비스만 이러한 데이터를 캡처할 수 있도록 해야 합니다(MUST). 대체 기능이 AOSP에 내장되어 있는 경우는 예외입니다(예: 디지털 어시스턴트 앱).
    • [C-0-6] 사전 설치된 서비스 메커니즘 외에 다른 어떤 앱도 이러한 데이터를 캡처할 수 있도록 허용해서는 안 됩니다(MUST NOT). 이러한 캡처 기능이 Android SDK API로 구현되는 경우는 예외입니다.
    • [C-0-7] 서비스를 사용 중지할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-0-8] 서비스에서 보유한 Android 권한 관리를 위한 사용자 어포던스를 생략하면 안 되며(MUST NOT), 섹션 9.1. 권한에 설명된 Android 권한 모델을 따라야 합니다.

  • 9.8.16. 연속 오디오 및 카메라 데이터: 새로운 섹션

    변경사항 보기

    9.8.2 녹음 중, 9.8.6 OS 수준 및 대기 데이터, 9.8.15 샌드박스 API 구현에서 설명한 요구사항 외에도 AudioRecord나 SoundTrigger, 기타 Audio API를 통해 백그라운드에서 연속적으로 얻은 오디오 데이터 또는 CameraManager나 기타 Camera API를 통해 백그라운드에서 연속적으로 얻은 카메라 데이터를 사용하는 구현은 다음을 충족해야 합니다.

    • [C-0-1] 다음의 경우를 제외하고 해당하는 표시기(섹션 9.8.2 녹음 중에 따른 카메라 또는 마이크)를 적용해야 합니다(MUST).
    • [C-SR-1] 이러한 데이터를 활용하는 모든 기능에 대해 사용자 동의를 요구하고 기본적으로 사용 중지할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-SR-2] 동일한 처리(즉, 9.8.2 녹음 중, 9.8.6 OS 수준 및 대기 데이터, 9.8.15 샌드박스 API 구현, 9.8.16 연속 오디오 및 카메라 데이터에 설명된 제한사항 준수)를 원격 웨어러블 기기에서 들어오는 카메라 데이터에 적용할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    카메라 데이터가 원격 웨어러블 기기에서 제공되고 Android OS 또는 샌드박스 구현, WearableSensingManager로 빌드된 샌드박스 기능 외부에서 암호화되지 않은 형식으로 액세스되는 경우 다음을 충족해야 합니다.

    • [C-1-1] 원격 웨어러블 기기에 추가 표시기를 표시하도록 나타내야 합니다(MUST).

    기기가 할당된 키워드 없이 디지털 어시스턴트 애플리케이션에 참여할 수 있는 기능을 제공하는 경우(일반 사용자 쿼리 처리 또는 카메라를 통한 사용자 존재 분석) 다음을 충족해야 합니다.

    • [C-2-1] 이러한 구현은 android.app.role.ASSISTANT 역할을 보유한 패키지로 제공되어야 합니다(MUST).
    • [C-2-2] 이러한 구현은 HotwordDetectionService 또는 VisualQueryDetectionService Android API를 활용하도록 해야 합니다(MUST).

  • 9.8.17. 원격 분석: 새로운 섹션

    변경사항 보기

    Android는 StatsLog API를 사용하여 시스템 및 앱 로그를 저장합니다. 이러한 로그는 권한이 있는 시스템 애플리케이션에서 사용할 수 있는 StatsManager API를 통해 관리됩니다.

    StatsManager는 개인 정보 보호 메커니즘이 있는 기기에서 개인 정보 보호에 민감한 것으로 분류된 데이터를 수집하는 방법도 제공합니다. 특히 StatsManager::query API는 StatsLog에 정의된 제한된 측정항목 카테고리를 쿼리하는 기능을 제공합니다.

    StatsManager에서 제한된 측정항목을 쿼리하고 수집하는 모든 구현은 다음을 충족해야 합니다.

    • [C-0-1] 기기의 유일한 애플리케이션/구현이어야 하며 READ_RESTRICTED_STATS 권한을 보유해야 합니다(MUST).
    • [C-0-2] 개인 정보 보호 메커니즘을 사용하여 원격 분석 데이터 및 기기 로그만 전송해야 합니다(MUST). 개인 정보 보호 메커니즘은 '집계 분석만 허용하고 로깅된 이벤트나 파생된 결과가 개별 사용자에게 매칭되지 않도록 하는 메커니즘'으로 정의됩니다. 이는 사용자별 데이터가 내부에서 분석(예: RAPPOR 등의 개인 정보 차등 보호 기술을 사용하여 구현됨)되지 않도록 하기 위한 것입니다.
    • [C-0-3] 이러한 데이터를 기기의 사용자 ID(예: 계정)와 연결하면 안 됩니다(MUST NOT).
    • [C-0-4] 이러한 데이터를 현재 섹션(9.8.17 개인 정보 보호 원격 분석)에 설명된 요구사항을 따르지 않는 다른 OS 구성요소와 공유하면 안 됩니다(MUST NOT).
    • [C-0-5] 개인 정보 보호 원격 분석 수집, 사용 및 공유를 사용 설정/사용 중지할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-0-6] 데이터가 기기에서 어떠한 형식으로든 저장되는 경우 구현에서 수집하는 이러한 데이터를 삭제할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST). 사용자가 데이터 삭제를 선택하면 현재 기기에 저장된 모든 데이터를 삭제해야 합니다(MUST).
    • [C-0-7] 오픈소스 저장소에 기본 개인 정보 보호 프로토콜 구현을 공개해야 합니다(MUST).
    • [C-0-8] StatsLog에 정의된 제한된 측정항목 카테고리의 데이터 수집을 통제하려면 이 섹션의 데이터 이그레스 정책을 시행해야 합니다(MUST).

  • 9.10. 기기 무결성:

    변경사항 보기

    기기 구현

    페이지별로 파일 콘텐츠를 확인할 수 있는 기기 구현은 다음을 충족해야 합니다.

    • [C-0-3 C-2-1] 전체 파일을 읽지 않고 신뢰할 수 있는 키에 대해 암호화 방식으로 파일 콘텐츠를 확인할 수 있도록 지원합니다.

    • [C-0-4 C-2-2] 읽기 콘텐츠가 신뢰할 수 있는 키에 대해 확인되지 않는 위 [C-2-1]에 따라 확인되지 않는 경우 보호된 파일에 대한 읽기 요청이 성공하도록 허용해서는 안 됩니다(MUST NOT).

    • [C-2-4] 사용 설정된 파일에 관해 O(1)의 파일 체크섬을 반환해야 합니다(MUST).

  • 9.11. 키 및 사용자 인증 정보:

    변경사항 보기

    Android 키 저장소 시스템은 앱 개발자가 암호화 키를 컨테이너에 저장하고 KeyChain API 또는 Keystore API를 통해 암호화 작업에 사용할 수 있게 해줍니다. 기기 구현은 다음을 충족해야 합니다.

    • [C-0-3] 기본 인증 시도 실패 횟수를 제한해야 합니다(MUST).
    • [C-SR-2] 기본 인증 시도 실패 상한값을 20으로 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 사용자가 기능에 동의하고 이를 선택한 경우 기본 인증 시도 실패 제한을 초과하면 '초기화'를 실행합니다.

    기기 구현이 잠금 화면 잠금 해제를 위한 인증 방법을 추가 또는 수정하는 경우(알려진 보안 비밀에 기반하거나 화면 잠금을 위한 안전한 방식으로 취급하려는 새 인증 방법을 사용하는 경우):

    • [C-SR-3] PIN은 최소 6자리 또는 이에 상응하는 20비트 엔트로피를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-2-1] 길이가 6자리 미만인 PIN은 PIN 길이가 표시되지 않도록 사용자 상호작용 없이 자동 입력을 허용하면 안 됩니다(MUST NOT).

  • 9.11.1. 보안 잠금 화면, 인증, 가상 기기:

    변경사항 보기

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

    • [C-0-1] 기본 인증 시도 실패 횟수를 제한해야 합니다(MUST).
    • [C-SR-5] 기본 인증 시도 실패 상한값을 20으로 구현할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 사용자가 기능에 동의하고 이를 선택한 경우 기본 인증 시도 실패 제한을 초과하면 '초기화'를 실행합니다.

    숫자 PIN을 권장 기본 인증 방법으로 설정하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR-6] PIN은 최소 6자리 또는 이에 상응하는 20비트 엔트로피를 포함할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-SR-7] 길이가 6자리 미만인 PIN은 PIN 길이가 표시되지 않도록 사용자 상호작용 없이 자동 입력을 허용하지 않을 것을 적극 권장합니다(STRONGLY RECOMMENDEDT).

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

    [C-7-8] 사용자의 안전(예: 운전자 주의 분산 행동)이 우려되는 경우를 제외하고 최소 72시간 또는 그보다 짧은 시간마다 권장하는 기본 인증(예: PIN, 패턴, 비밀번호) 방법 중 하나를 사용자에게 요구해야 합니다(MUST).

    애플리케이션이 보조 가상 디스플레이를 만들도록 허용하고 VirtualDeviceManager 등을 통해 연결된 입력 이벤트를 지원하며 디스플레이가 VIRTUAL_DISPLAY_FLAG_SECURE로 표시되지 않는 경우 다음을 충족해야 합니다.

    [C-13-10] 가상 기기에서 시작된 앱의 설치를 사용 중지해야 합니다(MUST).

  • 9.17. Android 가상화 프레임워크

    변경사항 보기

    기기 구현에서 Android 가상화 프레임워크 API(android.system.virtualmachine.*)를 지원하는 경우 Android 호스트는 다음을 충족해야 합니다.

    • [C-1-1] android.system.virtualmachine 패키지로 정의된 모든 API를 지원해야 합니다(MUST).
    • [C-1-2] 보호된 가상 머신(pVM)의 관리를 위해 Android SELinux 및 권한 모델을 수정하면 안 됩니다(MUST NOT).

    • [C-1-3] 업스트림 Android 오픈소스 프로젝트(AOSP)에 제공된 system/sepolicy 내에 있는 neverallow 규칙을 수정하거나 생략하거나 교체하면 안 되며(MUST NOT) 정책은 존재하는 모든 neverallow 규칙을 사용하여 컴파일해야 합니다(MUST).

    • [C-1-4] 보호된 가상 머신pVM을 만들고 실행하도록 플랫폼 서명 코드 및 권한이 있는 앱만 허용해야 합니다(MUST). 신뢰할 수 없는 코드(예: 서드 파티 앱)를 허용하면 안 됩니다(MUST NOT). 참고: 이 내용은 향후 Android 버전에서 변경될 수 있습니다.

    • [C-1-5] 보호된 가상 머신pVM이 공장 출고 시 이미지 또는 그 업데이트의 일부가 아닌 코드를 실행하도록 허용하면 안 됩니다(MUST NOT). Android 자체 검사 부팅이 적용되지 않는 항목(예: 인터넷에서 다운로드하거나 사이드로드된 파일)은 보호된 가상 머신에서 실행되어서는 안 됩니다(MUST NOT).

    • [C-1-5] 디버그 불가능한 pVM이 권한이 있는 앱의 업데이트도 포함된 공장 출고 시 이미지 또는 플랫폼 업데이트 코드를 실행하도록 허용해야 합니다(MUST).

    기기 구현에서 Android 가상화 프레임워크 API(android.system.virtualmachine.*)를 지원하는 경우 보호된 가상 머신pVM 인스턴스는 다음을 충족해야 합니다.

    • [C-2-1] 보호된 가상 머신pVM의 가상화 APEX에서 사용 가능한 모든 운영체제를 실행할 수 있어야 합니다(MUST).
    • [C-2-2] 보호된 가상 머신pVM이 기기 구현자 또는 OS 공급업체에서 서명하지 않은 운영체제를 실행하도록 허용하면 안 됩니다(MUST NOT).
    • [C-2-3] 보호된 가상 머신pVM이 데이터를 코드로 실행(예: SELinux neverallow execmem)하도록 허용하면 안 됩니다(MUST NOT).

    • [C-2-4] 업스트림 Android 오픈소스 프로젝트(AOSP)에 제공된 system/sepolicy/microdroid 내에 있는 neverallow 규칙을 수정하거나 생략하거나 교체하면 안 됩니다(MUST NOT).

    • [C-2-5] Microdroid 이외의 운영체제에도 보호된 가상 머신pVM 심층 방어 메커니즘(예: pVM의 SELinux)을 구현해야 합니다(MUST).
    • [C-2-6] VM에서 실행할 초기 이미지를 확인할 수 없는 경우 pVM 펌웨어가이 부팅되지 않도록 해야 합니다(MUST). 확인은 VM 내에서 이뤄져야 합니다(MUST).
    • [C-2-7] instance.img의 무결성이 손상되면 pVM 펌웨어가이 부팅되지 않도록 해야 합니다(MUST).

    기기 구현에서 Android 가상화 프레임워크 API(android.system.virtualmachine.*)를 지원하는 경우 하이퍼바이저는 다음을 충족해야 합니다.

    • [C-3-1] VM(pVM 또는 호스트 VM)이 독점적으로 소유한 메모리 페이지는 다른 가상 머신(보호되든 보호되지 않든)이 아닌 가상 머신 자체 또는 하이퍼바이저에서만 액세스할 수 있도록 해야 합니다(MUST). 페이지 소유자가 명시적으로 공유하지 않는 한 어떤 pVM도 다른 항목(즉, 다른 pVM 또는 하이퍼바이저)에 속한 페이지에 액세스하도록 허용하면 안 됩니다(MUST NOT). 여기에는 호스트 VM이 포함됩니다. 이는 CPU 및 DMA 액세스에 모두 적용됩니다.
    • [C-3-2] pVM에서 사용한 후 그리고 호스트에 반환되기 전(예: pVM이 소멸됨)에 페이지를 완전 삭제해야 합니다(MUST).
    • [C-3-3SR-1] pVM 펌웨어가 pVM의 코드보다 먼저 로드되고 실행되어야 합니다(MUST)도록 할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-3-4] 각 VM이 pVM 인스턴스에 제공된 {부팅 인증서 체인(BCC) 및 복합 기기 식별자(CDI) 해당 VM 인스턴스에서만 파생될 수 있는 VM별 보안 비밀을 파생하고 초기화 및 OTA 시 변경되도록 해야 합니다(MUST).

    기기 구현에서 Android 가상화 프레임워크 API를 지원하는 경우 모든 영역에서 다음을 충족해야 합니다.

    • [C-4-1] Android 보안 모델 우회를 허용하는 pVM에 기능을 제공하면 안 됩니다(MUST NOT).

    Android 가상화 프레임워크 API를 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-5-1] 격리된 컴파일을 지원할 수 있어야 하지만(MUST) ART 런타임 업데이트 기기 배송 시 격리된 컴파일 기능을 사용 중지할 수 있습니다.

    기기 구현에서 Android 가상화 프레임워크 API를 지원하는 경우 키 관리는 다음을 충족해야 합니다.

    • [C-6-1] 잠금 해제된 기기에서도 사용자가 수정할 수 없는 지점에 DICE 체인을 루팅해야 합니다(MUST). (스푸핑을 방지하기 위함)

    • [C-SR-26-2] DICE를 VM별 보안 비밀 파생 메커니즘으로 사용할 것을 적극 권장합니다(STRONGLY RECOMMENDED). DICE를 제대로 실행해야 합니다(MUST). 즉, 올바른 값을 제공해야 합니다.

맨 위로