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

안드로이드 13

2023년 6월 26일

2. 기기 종류

  • 2.2.1. 하드웨어

    • 제거된 요구 사항 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

    • 기타 업데이트:

      개정판 보기

      Presence Calibration 에 지정된 측정 설정 단계를 따를 것을 적극 권장합니다(STRONGLY RECOMMENDED). 요구 사항 .

  • 2.5.1. 하드웨어

    개정판 보기

    자동차 기기 구현이 32비트인 경우:

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

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

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

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

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

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

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

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

3. 소프트웨어

  • 3.2.3.5. 조건부 신청 의도

    개정판 보기

    기기 구현이 android.hardware.telephony.calling을 보고하는 경우 android.hardware.telephony , 그들:

7. 하드웨어 호환성

9. 보안 모델 호환성

  • 9.1 권한

    개정판 보기

    장치 구현:

    • [C-0-5] 런타임 권한을 부여하면 안 됩니다(MUST NOT). 사전 설치된 다음을 제외하고 앱:

      • 장치 배송 시 설치되며, 그리고
      • 애플리케이션이 사용하기 전에 사용자의 동의를 얻을 수 있습니다. 그것 권한 ,

      또는

      • 런타임 권한은 기본 권한 부여 정책 에 의해 부여되거나 플랫폼 역할을 보유하기 위해 부여 됩니다. 사전 설치된 애플리케이션이 기본 핸들러로 설정된 인텐트 패턴과 연결됨 .

  • 9.11. 키 및 자격 증명

    • 요구 사항 [C-13-10] 및 9.11.4를 제거했습니다.

2023년 3월 20일

2. 기기 종류

  • 2.2.3. 소프트웨어

    개정판 보기

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

  • 2.3.2. 멀티미디어

    개정판 보기

    VP9 하드웨어 디코더가 있는 텔레비전 장치 구현이 VP9 디코딩 및 UHD 디코딩 프로필을 지원하는 경우:

    • [ 5.3.7 /T- 2-1 SR1 ] 프로필 2(10비트 색 심도)를 사용하여 초당 60프레임의 UHD 디코딩 프로필을 지원할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 2.5.1. 하드웨어

    개정판 보기

    자동차 기기 구현:

3. 소프트웨어

  • 3.18. 콘택트 렌즈

    개정판 보기

    새로운 요구 사항 시작

    새 연락처의 기본 계정: 연락처 제공자는 새 연락처를 만들 때 기본 계정 설정을 관리하기 위한 API를 제공합니다.

    기기 구현이 연락처 앱을 사전 로드하는 경우 사전 로드된 연락처 앱은 다음을 수행합니다.

    • [C-2-1] 계정 선택을 위한 UI를 시작하고 계정이 선택되면 설정을 연락처 제공자에 저장하기 위해 ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT 텐트를 처리해야 합니다(MUST).

    • [C-2-2] 초기에 계정을 선택하여 ContactsContracts.Contacts.CONTENT_TYPE 및 ContactsContract.RawContacts.CONTENT_TYPE 에 대한 Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT 처리할 때 기본 계정 설정을 준수해야 합니다(MUST).

  • 3.2.3.5. 조건부 신청 의도

    개정판 보기

    [2.2.3으로 이동]

    새로운 요구 사항 시작

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

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

  • 6.1. 개발자 도구

    개정판 보기

    • 원숭이
      • [C-0-8] Monkey 프레임워크를 포함하고 애플리케이션에서 사용할 수 있도록 해야 합니다(MUST).

7. 하드웨어 호환성

  • 7.3.13. IEEE 802.1.15.4(UWB)

    개정판 보기

    [7.4.9로 이동]

    새로운 요구 사항 시작

    802.1.15.4에 대한 지원을 포함하고 타사 애플리케이션에 기능을 노출하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-1] android.uwb에서 해당 Android API를 구현해야 합니다(MUST).
    • [C-1-2] 하드웨어 기능 플래그 android.hardware.uwb를 보고해야 합니다(MUST).
    • [C-1-3] Android 구현에 정의된 모든 관련 UWB 프로필을 지원해야 합니다(MUST).
    • [C-1-4] 사용자가 UWB 라디오 켜기/끄기 상태를 전환할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-1-5] UWB 라디오를 사용하는 앱이 UWB_RANGING 권한(NEARBY_DEVICES 권한 그룹 아래)을 보유하도록 강제해야 합니다(MUST).
    • [C-1-6] FIRA , CCC , CSA를 비롯한 표준 조직에서 정의한 관련 적합성 및 인증 테스트를 통과할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 7.4.1. 전화 통신

    개정판 보기

    장치 구현 GSM 또는 CDMA 전화 통신 포함 android.hardware.telephony 기능을 보고한 후 다음을 수행합니다.

    장치 구현 GSM 또는 CDMA 전화 통신 포함 android.hardware.telephony 기능을 보고 하고 시스템 상태 표시줄을 제공한 후 다음을 수행합니다.

    • [씨- 6 -7 -1 ] SIM 상태 정보를 제공하는 모든 어포던스에서 사용자에게 표시할 주어진 그룹 UUID 에 대한 대표 활성 구독을 선택해야 합니다(MUST). 이러한 어포던스의 예로는 상태 표시줄 셀룰러 신호 아이콘 또는 빠른 설정 타일이 있습니다.
    • [C-SR-1] 기기가 음성 통화 중이 아닌 한 대표 구독을 활성 데이터 구독 으로 선택할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 이 동안 대표 구독이 활성 음성 구독일 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    장치 구현 GSM 또는 CDMA 전화 통신 포함 android.hardware.telephony 기능을 보고한 후 다음을 수행합니다.

    • [C-6- 8 7 ] ETSI TS 102 221에 따라 각 UICC에 대한 논리 채널의 최대 수(총 20개)를 열고 동시에 사용할 수 있어야 합니다(MUST).
    • [C-6- 10 8 ] 활성 이동통신사 앱( TelephonyManager#getCarrierServicePackageName 으로 지정됨)에 다음 동작을 자동으로 또는 명시적인 사용자 확인 없이 적용하면 안 됩니다(MUST NOT).
      • 네트워크 액세스 취소 또는 제한
      • 권한 취소
      • AOSP에 포함된 기존 전원 관리 기능 이상으로 백그라운드 또는 포그라운드 앱 실행 제한
      • 앱 비활성화 또는 제거

    장치 구현 GSM 또는 CDMA 전화 통신 포함 android.hardware.telephony 기능 및 그룹 UUID를 공유하는 모든 활성 비기회 구독이 비활성화되거나 v기기에서 물리적으로 제거되거나 기회주의로 표시되면 기기가 다음을 수행합니다.

    • [씨- 7 8 -1] 동일한 그룹에 남아 있는 모든 활성 기회 구독을 자동으로 비활성화해야 합니다(MUST).

    GSM 전화 통신은 포함하지만 CDMA 전화 통신은 포함하지 않는 기기 구현은 다음을 충족해야 합니다.

    • [씨- 8 9 -1] PackageManager#FEATURE_TELEPHONY_CDMA 선언하면 안 됩니다(MUST NOT).
    • [씨- 8 9 -2] 선호 또는 허용된 네트워크 유형 비트마스크에서 3GPP2 네트워크 유형을 설정하려는 시도 시 IllegalArgumentException 발생시켜야 합니다(MUST).
    • [씨- 8 9 -3] TelephonyManager#getMeid 에서 빈 문자열을 반환해야 합니다(MUST).

    여러 포트 및 프로필이 있는 eUICC를 지원하는 기기 구현은 다음을 충족해야 합니다.

  • 7.4.9. UWB

    개정판 보기

    기기 구현이 android.content.pm.PackageManager 클래스를 통해 android.hardware.uwb 기능에 대한 지원을 보고하는 경우, 802.1.15.4에 대한 지원을 포함하고 타사 애플리케이션에 기능을 노출하는 기기 구현은 다음을 충족해야 합니다.

    새로운 요구 사항 시작

    • [C-1-1] android.uwb에서 해당 Android API를 구현해야 합니다(MUST).
    • [C-1-2] 하드웨어 기능 플래그 android.hardware.uwb를 보고해야 합니다(MUST).
    • [C-1-3] Android 구현에 정의된 모든 관련 UWB 프로필을 지원해야 합니다(MUST).
    • [C-1-4] 사용자가 UWB 라디오 켜기/끄기 상태를 전환할 수 있도록 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-1-5] UWB 라디오를 사용하는 앱이 UWB_RANGING 권한(NEARBY_DEVICES 권한 그룹 아래)을 보유하도록 강제해야 합니다(MUST).
    • [C-SR-1] FIRA , CCC , CSA 를 비롯한 표준 조직에서 정의한 관련 적합성 및 인증 테스트를 통과할 것을 적극 권장합니다(STRONGLY RECOMMENDED).
    • [C-1- 1 6 ] 무반사 챔버의 1m 거리에서 가시선 환경에서 측정값의 95%에 대해 거리 측정값이 +/-15cm 이내인지 확인해야 합니다(MUST).
    • [C-1- 2 7 ] 참조 장치에서 1m 떨어진 거리 측정의 중앙값이 [0.75m, 1.25m] 이내인지 확인해야 합니다.
    • [C-SR-2] 존재 보정 요구사항 에 지정된 측정 설정 단계를 따를 것을 적극 권장합니다(STRONGLY RECOMMENDED).

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

  • 7.8.2.2. 디지털 오디오 포트

    개정판 보기

    Android USB 헤드셋 사양 에 정의된 대로 USB-C 커넥터를 사용하고 Android 에코시스템에서 (USB 오디오 클래스)를 구현하는 헤드셋 및 기타 오디오 액세서리와 호환되기 위해 .

2022년 10월 19일

2. 기기 종류

  • 2.2.3 소프트웨어

    개정판 보기

    휴대기기 구현이 잠금 작업 모드 에서 실행되지 않는 경우 콘텐츠가 클립보드에 복사되면 다음을 수행합니다.

    • [3.8.17/H-1-1] 데이터가 클립보드에 복사되었다는 확인을 사용자에게 표시해야 합니다(예: '콘텐츠가 복사됨'이라는 미리보기 이미지 또는 경고). 또한 여기에 클립보드 데이터가 장치 간에 동기화되는지 여부를 표시합니다.

3. 소프트웨어

  • 3.2.3.5. 조건부 신청 의도

    개정판 보기

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

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

  • 3.4.1 웹뷰 호환성

    개정판 보기

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

7. 하드웨어 호환성

  • 7.4.2 IEEE 802.11(와이파이)

    개정판 보기

    IEEE 802.11 표준에 정의된 Wi-Fi 절전 모드 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

  • 7.4.3 블루투스

    개정판 보기

    저전력 블루투스(BLE) 지원을 포함하는 기기 구현은 다음을 충족해야 합니다.

    • [C-3-5] 기기가 스캐닝 또는 광고를 위해 BLE를 적극적으로 사용하는 경우 사용자 개인 정보를 보호하기 위해 15분 이하의 RPA(해결 가능 비공개 주소) 시간 초과를 구현하고 시간 초과 시 주소를 회전해야 합니다(MUST). 타이밍 공격을 방지하기 위해 타임아웃 간격도 5~15분 사이에서 무작위로 지정해야 합니다.

  • 7.5.5 카메라 방향

    개정판 보기

    기기 구현에 전면 또는 후면 카메라가 있는 경우 이러한 카메라는 다음과 같습니다.

    • [C-1-1] 카메라의 긴 치수가 화면의 긴 치수와 정렬되도록 방향을 맞춰야 합니다(MUST). 즉, 기기를 가로 방향으로 잡고 있을 때 카메라는 반드시 가로 방향으로 이미지를 캡처해야 합니다. 이는 장치의 자연스러운 방향에 관계없이 적용됩니다. 즉, 세로 기본 장치뿐만 아니라 가로 기본 장치에도 적용됩니다.

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

    • 이 장치는 폴더블 또는 힌지 디스플레이와 같은 가변 형상 화면을 구현합니다.
    • 장치의 접힘 또는 힌지 상태가 변경되면 장치가 세로 기본 방향에서 가로 기본 방향(또는 그 반대)으로 전환됩니다.

9. 보안 모델 호환성

  • 9.11 키 및 자격 증명

    개정판 보기

    기기 구현이 보안 잠금 화면을 지원하는 경우 다음을 충족해야 합니다.

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

  • 9.17 Android 가상화 프레임워크

    개정판 보기

    기기가 Android 가상화 프레임워크 API( android.system.virtualmachine.* )에 대한 지원을 구현하는 경우 Android 호스트는 다음을 수행합니다.

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

    기기가 Android 가상화 프레임워크 API( android.system.virtualmachine.* )에 대한 지원을 구현하는 경우 모든 보호된 가상 머신 인스턴스:

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

    기기가 Android 가상화 프레임워크 API에 대한 지원을 구현하는 경우 키 관리에 대해 다음을 수행합니다.

    • [C-6-2] DICE를 제대로 수행해야 합니다(즉, 올바른 값을 제공해야 함). 그러나 그 수준의 세부 사항까지 갈 필요는 없을 수도 있습니다.

2022년 8월 15일

2. 기기 종류

  • 2.2.1 하드웨어 : 하드웨어 요구 사항이 다음과 같이 변경됩니다.

    • 입력 장치:

      개정판 보기

      핸드헬드 장치 구현:

      • [ 7.2 .3/H-0-5] 뒤로 제스처가 시작되거나 뒤로 버튼( KEYCODE_BACK )이 DOWN으로 눌렸을 때 현재 포커스가 있는 창에서 OnBackInvokedCallback.onBackStarted() 호출해야 합니다(MUST).
      • [ 7.2 .3/H-0-6] 뒤로 제스처가 커밋되거나 뒤로 버튼을 놓을 때(UP) OnBackInvokedCallback.onBackInvoked() 호출해야 합니다(MUST).
      • [ 7.2 .3/H-0-7] 뒤로 제스처가 커밋되지 않았거나 KEYCODE_BACK 이벤트가 취소된 경우 OnBackInvokedCallback.onBackCancelled() 호출해야 합니다(MUST).

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

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

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

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

    • 오디오 대기 시간:

      개정판 보기

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

      • [ 5.6 /H-1-1] 평균 연속 왕복 대기 시간이 500 이어야 합니다(MUST). 800 평균 절대 편차가 50 미만인 5회 측정에서 밀리초 이하 100 ms, 다음 데이터 경로: "스피커에서 마이크", 3.5mm 루프백 어댑터(지원되는 경우), USB 루프백(지원되는 경우). 지원되는 경로가 하나 이상 있습니다.

      • [ 5.6 /H-1-1] 스피커에서 마이크까지의 데이터 경로를 통한 최소 5회 측정에서 평균 탭-톤 대기 시간이 500밀리초 이하여야 합니다(MUST).

    • 햅틱 입력:

      개정판 보기

      햅틱 액추에이터가 하나 이상 포함된 휴대기기 구현은 다음을 충족해야 합니다.

      • [ 7.10 /H]* 편심 회전 질량(ERM) 햅틱 액추에이터(진동기)를 사용하면 안 됩니다(SHOULD NOT).
      • [ 7.10 /H]* 일반적으로 기기를 손으로 잡거나 만지는 위치 근처에 액추에이터를 배치해야 합니다(SHOULD).
      • [ 7.10 /H]* android.view.HapticFeedbackConstants , 즉 ( CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, G ESTURE_START 및 GESTURE_END).
      • [ 7.10 /H]* android.os.VibrationEffect 의 명확한 햅틱 을 위한 모든 공개 상수, 즉(EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK 및 EFFECT_DOUBLE_CLICK) 및 android.os.VibrationEffect.Composition 의 풍부한 햅틱 을 위한 모든 실현 가능한 공개 PRIMITIVE_* 상수를 구현해야 합니다(SHOULD). (PRIMITIVE_CLICK 및 PRIMITIVE_TICK) (클릭, 틱, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). LOW_TICK 및 SPIN과 같은 이러한 프리미티브 중 일부는 진동기가 상대적으로 낮은 주파수를 지원할 수 있는 경우에만 실현 가능할 수 있습니다.

      • [ 7.10 /H]* 이러한 연결된 햅틱 상수 매핑을 사용해야 합니다.

      휴대기기 구현에 하나 이상의 선형 공진 액추에이터가 포함된 경우 다음을 충족해야 합니다.

      • [ 7.10 /H]* 세로 방향의 X축 (좌우) 에서 햅틱 액추에이터를 이동해야 합니다(SHOULD).

      • [ 7.10 /H]* 상수에 대한 구현 지침 에 설명된 대로 지원되지 않는 프리미티브에 대한 폴백 구성이 필요한 경우 확인하고 업데이트해야 합니다(SHOULD).

      • [7.10/H]* 여기에 설명된 대로 장애 위험을 완화하기 위해 대체 지원을 제공해야 합니다(SHOULD).

  • 2.2.3 소프트웨어 :

    • 인증 사소한 장치 제어:

      개정판 보기

      • [ 3.8 .16/H-1-5] ControlsProviderService 및 Control Control.isAuthRequired API를 통해 타사 애플리케이션에서 등록한 컨트롤에서 앱 지정 사소한 기기 컨트롤을 옵트아웃할 수 있는 사용자 어포던스를 제공해야 합니다(MUST).

    • MediaStyle 알림:

      개정판 보기

      핸드헬드 장치 구현이 MediaStyle 알림을 지원하는 경우:

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

  • 2.2.4 성능 및 성능 : 포그라운드 서비스를 실행하는 앱에 대한 새로운 요구 사항입니다.

    개정판 보기

    핸드헬드 장치 구현:

    • [ 8.5 /H-0-1] 포그라운드 서비스를 실행 중인 앱을 중지하고 활성화된 포그라운드 서비스가 있는 모든 앱과 각 서비스의 지속 시간을 표시할 수 있는 기능을 설정 메뉴에서 사용자 어포던스를 제공해야 합니다(MUST). SDK 문서 에 설명된 대로 시작되었습니다.
      • 일부 앱은 SDK 문서 에 설명된 대로 이러한 사용자 어포던스에 나열되거나 중지되지 않도록 면제될 수 있습니다(MAY).

  • 2.2.7.1 미디어 : 휴대용 요구 사항 미디어 섹션이 다음과 같이 업데이트되었습니다.

    개정판 보기

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

    • [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() 및 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행할 수 있는 하드웨어 동영상 디코더 세션의 최대 수를 광고해야 합니다(MUST).
    • [5.1/H-1-2] 1080p 해상도@30fps에서 동시에 실행되는 모든 코덱 조합에서 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, ​​AV1 이상)의 인스턴스 6개를 지원해야 합니다(MUST).
    • [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() 및 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행할 수 있는 최대 하드웨어 동영상 인코더 세션 수를 광고해야 합니다(MUST).
    • [5.1/H-1-4] 1080p 해상도@30fps에서 동시에 실행되는 모든 코덱 조합에서 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, ​​AV1 이상)의 인스턴스 6개를 지원해야 합니다(MUST).
    • [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() 및 VideoCapabilities.getSupportedPerformancePoints() 메서드를 통해 모든 코덱 조합에서 동시에 실행할 수 있는 최대 하드웨어 동영상 인코더 및 디코더 세션 수를 광고해야 합니다(MUST).
    • [5.1/H-1-6] 1080p@30fps 해상도에서 동시에 실행되는 모든 코덱 조합에서 하드웨어 동영상 디코더 및 하드웨어 동영상 인코더 세션(AVC, HEVC, VP9, ​​AV1 이상)의 인스턴스 6개를 지원해야 합니다(MUST).
    • [5.1/H-1-7] 부하가 있을 때 모든 하드웨어 동영상 인코더의 1080p 이하 동영상 인코딩 세션에 대해 코덱 초기화 지연 시간이 40ms 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-비디오 녹화 초기화와 함께 하드웨어 비디오 코덱을 사용하는 동시 1080p에서 720p 비디오 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.1/H-1-8] 부하가 있을 때 모든 오디오 인코더에 대해 128kbps 이하의 비트 전송률 오디오 인코딩 세션에 대해 코덱 초기화 지연 시간이 30ms 이하여야 합니다(MUST). 여기서 로드는 1080p 오디오-비디오 녹화 초기화와 함께 하드웨어 비디오 코덱을 사용하는 동시 1080p에서 720p 비디오 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.1/H-1-9] 1080p 해상도@30fps에서 동시에 실행되는 모든 코덱 조합에서 보안 하드웨어 동영상 디코더 세션(AVC, HEVC, VP9, ​​AV1 이상)의 인스턴스 2개를 지원해야 합니다(MUST).
    • [5.1/H-1-10] 모든 코덱에서 보안 하드웨어 비디오 디코더 세션 인스턴스 1개(총 4개 인스턴스)(AVC, HEVC, VP9, ​​AV1 이상)와 함께 비보안 하드웨어 비디오 디코더 세션 인스턴스 3개를 지원해야 합니다(MUST). 1080p resolution@30fps에서 동시에 실행되는 조합.
    • [5.1/ H-1-11] 기기의 모든 하드웨어 AVC, HEVC, VP9 또는 AV1 디코더에 보안 디코더를 지원해야 합니다(MUST).
    • [5.1/H-1-12] 동영상 디코더 초기화 지연 시간이 40ms 이하여야 합니다(MUST).
    • [5.1/H-1-13] 오디오 디코더 초기화 지연 시간이 30ms 이하여야 합니다(MUST).
    • [5.1/H-1-14] AV1 하드웨어 디코더 Main 10, Level 4.1을 지원해야 합니다(MUST).
    • [5.1/H-SR] AV1 하드웨어 디코더용 Film Grain을 지원하는 것이 좋습니다.
    • [5.1/H-1-15] 4K60을 지원하는 하드웨어 동영상 디코더가 1개 이상 있어야 합니다(MUST).
    • [5.1/H-1-16] 4K60을 지원하는 하드웨어 동영상 인코더가 1개 이상 있어야 합니다(MUST).
    • [5.3/H-1-1] 로드 중인 1080p 60fps 동영상 세션에 대해 10초에 1프레임 이상(즉, 0.167% 미만의 프레임 드롭) 드롭하면 안 됩니다(MUST NOT). 부하는 하드웨어 비디오 코덱과 128kbps AAC 오디오 재생을 사용하는 동시 1080p에서 720p 비디오 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.3/H-1-2] 로드 중인 60fps 동영상 세션에서 동영상 해상도가 변경되는 동안 10초에 1프레임 이상 드롭하면 안 됩니다(MUST NOT). 부하는 하드웨어 비디오 코덱과 128kbps AAC 오디오 재생을 사용하는 동시 1080p에서 720p 비디오 전용 트랜스코딩 세션으로 정의됩니다.
    • [5.6/H-1-1] OboeTester 탭-톤 테스트 또는 CTS Verifier 탭-톤 테스트를 사용하여 탭-톤 대기 시간이 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 중 하나를 수락해야 합니다.
    • [5.6/H-1-4] 4개 이상의 채널 USB 오디오 기기를 지원해야 합니다(DJ 컨트롤러에서 노래 미리보기에 사용됨).
    • [5.6/H-1-5] 클래스 호환 MIDI 기기를 지원하고 MIDI 기능 플래그를 선언해야 합니다(MUST).
    • [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

  • 2.2.7.2 카메라 : 미디어 성능 클래스 카메라 요구 사항 업데이트.

    개정판 보기

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

    • [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 캡처 지연 시간이 1000ms 미만이어야 합니다(MUST).
    • [7.5/H-1-6] 두 기본 카메라의 ITS 조명 조건(3000K)에서 CTS 카메라 성능 테스트로 측정한 카메라 2 시작 지연 시간(첫 번째 미리보기 프레임에 카메라 열기)이 500ms 미만이어야 합니다(MUST).
    • [7.5/H-1-8] 기본 후면 카메라에 대해 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 및 android.graphics.ImageFormat.RAW_SENSOR 지원해야 합니다(MUST).
    • [7.5/H-1-9] 720p 또는 1080p @ 240fps를 지원하는 후면 기본 카메라가 있어야 합니다(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 카메라가 1대보다 많은 경우 기본 카메라에 대한 LOGICAL_MULTI_CAMERA 기능을 지원해야 합니다(MUST).
    • [7.5/H-1-14] 기본 전면 및 기본 후면 카메라 모두에 대해 STREAM_USE_CASE 기능을 지원해야 합니다(MUST).

  • 2.2.7.3 하드웨어 : 하드웨어에 대한 미디어 성능 클래스 요구 사항 업데이트.

    개정판 보기

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

    • [7.1.1.1/H-2-1] 화면 해상도가 1080p 이상이어야 합니다(MUST).
    • [7.1.1.3/H-2-1] 화면 밀도가 400dpi 이상이어야 합니다(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.T 반환하는 경우 다음을 충족해야 합니다.

    • [8.2/H-1-1] 최소 125MB/s의 순차 쓰기 성능을 보장해야 합니다(MUST).
    • [8.2/H-1-2] 최소 10MB/s의 임의 쓰기 성능을 보장해야 합니다(MUST).
    • [8.2/H-1-3] 최소 250MB/s의 순차 읽기 성능을 보장해야 합니다(MUST).
    • [8.2/H-1-4] 최소 40MB/s의 임의 읽기 성능을 보장해야 합니다(MUST).

  • 2.5.1 하드웨어 : 3축 가속도계 및 3축 자이로스코프 요구 사항과 외부 카메라 요구 사항을 업데이트합니다.

    개정판 보기

    자동차 기기 구현:

    • [ 7.3 .1/A-0-4] Android 자동차 센서 좌표계를 준수해야 합니다(MUST).
    • [ 7.3 /A-SR] 3축 가속도계와 3축 자이로스코프를 포함할 것을 적극 권장합니다(STRONGLY_RECOMMENDED).
    • [ 7.3 /A-SR] TYPE_HEADING 센서를 구현하고 보고할 것을 STRONGLY_RECOMMENDED합니다(STRONGLY_RECOMMENDED).

    가속도계가 포함된 자동차 기기 구현은 다음을 충족해야 합니다.

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

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

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

    축이 3개 미만인 가속도계가 포함된 자동차 기기 구현은 다음을 충족해야 합니다.

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

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

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

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

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

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

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

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

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

    외부 보기 카메라는 후방 카메라 와 같이 장치 구현 외부의 장면을 이미지화하는 카메라입니다. 블랙박스 .

    자동차 기기 구현에 외부 카메라가 포함된 경우 이러한 카메라에 대해 다음을 충족해야 합니다.

    • [ 7.5 .5/A-SR] 카메라의 긴 치수가 수평선과 정렬되도록 방향을 잡을 것을 적극 권장합니다(STRONGLY RECOMMENDED).

    • Android 동기화 프레임워크를 지원해야 합니다(SHOULD).

    • 카메라 드라이버에 하드웨어 자동 초점 또는 소프트웨어 자동 초점이 구현되어 있을 수 있습니다(MAY).

    자동차 기기 구현에 하나 이상의 외부 보기 카메라가 포함되고 EVS(Exterior View System) 서비스를 로드하는 경우 이러한 카메라에 대해 다음을 수행해야 합니다.

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

    자동차 기기 구현:

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

    자동차 장치 구현에 하나 이상의 카메라가 포함되어 있고 이를 타사 애플리케이션에서 사용할 수 있도록 하는 경우 다음을 충족해야 합니다.

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

  • 2.5.5 보안 모델 : 자동차 장치의 카메라 권한에 대한 새로운 요구 사항.

    개정판 보기

    자동차 기기 구현이 android.hardware.camera.any 선언하는 경우 다음을 충족해야 합니다.

    • [ 9.8.2 /A-2-1] 앱이 실시간 카메라 데이터에 액세스할 때 카메라 표시기를 표시해야 합니다(MUST). 섹션 9.1 CDD를 통한 권한 에서 호출된 역할을 보유한 앱에서만 카메라에 액세스하는 경우가 아닌 경우 카메라 표시기를 표시해야 합니다. 식별자 [C-3-X].

    • [ 9.8.2 /A-2-2] 가시적인 사용자 인터페이스 또는 직접적인 사용자 상호작용이 있는 시스템 앱의 카메라 표시기를 숨기면 안 됩니다(MUST).

  • 2.6.1 태블릿 요구 사항 — 하드웨어 : 태블릿 화면 크기 요구 사항을 업데이트합니다.

    개정판 보기

    Android 태블릿 장치는 일반적으로 다음 기준을 모두 충족하는 Android 장치 구현을 나타냅니다.

    • 대각선으로 측정한 화면 디스플레이 크기가 7인치 이상 18인치 미만이어야 합니다.

    화면 크기

    • [ 7.1 .1.1/Tab-0-1] 7~18인치 범위의 화면이 있어야 합니다(MUST).

3. 소프트웨어

  • 3.2.2 빌드 매개변수 : getSerial() 의 업데이트된 ASCII 문자.

    개정판 보기

    • [C-0-1] 기기 구현 전체에서 일관되고 의미 있는 값을 제공하기 위해 아래 표에는 기기 구현이 준수해야 하는 이러한 값의 형식에 대한 추가 제한사항이 포함되어 있습니다.
    모수 세부
    getSerial() 모델 및 제조업체가 동일한 장치에서 사용 가능하고 고유한 하드웨어 일련 번호여야 합니다(또는 반환해야 함). 이 필드의 값은 7비트 ASCII로 인코딩할 수 있어야 하며 "^[a-zA-Z0-9]+$" 정규식과 일치해야 합니다.

  • 3.2.3.5 조건부 적용 의도 : 조건부 적용 의도에 대한 요구 사항 업데이트.

    개정판 보기

    대형 디스플레이(일반적으로 디스플레이 너비와 높이가 600dp+ 이상)를 포함하고 분할 기능을 지원하는 기기 구현은 다음을 충족해야 합니다.

  • 3.5.1 애플리케이션 제한 : 애플리케이션 제한 업데이트.

    개정판 보기

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

    • [C-1-1] 사용자가 제한된 앱 목록을 볼 수 있도록 허용해야 합니다(MUST).
    • [C-1-2] 각 앱에서 이러한 독점 제한을 모두 켜거나 끌 수 있는 사용자 어포던스를 제공해야 합니다(MUST).
    • [C-1-3] 열악한 시스템 상태 동작의 증거 없이 이러한 독점 제한을 자동으로 적용하면 안 되지만(MUST(MUST)), 중단된 wakelock, 장기 실행 서비스, 기타 기준과 같은 열악한 시스템 상태 동작이 감지되면 앱에 제한을 적용할 수 있습니다(MAY). 기준은 기기 구현자에 의해 결정될 수 있지만(MAY) 시스템 상태에 대한 앱의 영향과 관련되어야 합니다(MUST). 시장에서 앱의 인기 부족과 같이 시스템 상태와 순전히 관련되지 않은 다른 기준을 기준으로 사용해서는 안 됩니다(MUST NOT).
    • [C-1-4] 사용자가 앱 제한을 수동으로 해제한 경우 앱에 대해 이러한 독점 제한을 자동으로 적용하면 안 되며(MUST NOT) 사용자에게 이러한 독점 제한을 적용하도록 제안할 수 있습니다(MAY).

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

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

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

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

    • [C-1-9] UsageStats를 통해 이러한 모든 독점 제한 이벤트를 보고해야 합니다(MUST).

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

      • 소유권 제한에 대한 트리거링 조건.
      • 앱을 제한할 수 있는 대상과 방법.
      • 앱이 이러한 제한에서 제외되는 방법.
      • 앱이 사용자가 설치할 수 있는 앱에 대해 이러한 면제를 지원하는 경우 독점 제한 면제를 요청할 수 있는 방법.

    앱이 기기에 사전 설치되어 있고 사용자가 30일 이상 명시적으로 사용하지 않은 경우 [C-1-3] [C-1-5]가 면제됩니다.

  • 3.8.1 런처(홈 화면) : monochrome/adaptive-icon 지원 업데이트.

    개정판 보기

    기기 구현이 흑백 아이콘을 지원하는 경우 다음 아이콘은 다음과 같습니다.

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

  • 3.8.2 위젯 : 실행기에서 타사 앱 위젯 존재로 업데이트합니다.

    개정판 보기

    타사 앱 위젯을 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-1-2] AppWidgets에 대한 기본 제공 지원을 포함하고 AppWidgets를 추가, 구성, 보기 및 제거하기 위한 사용자 인터페이스 어포던스를 노출해야 합니다(MUST). 실행기 내에서 직접.

  • 3.8.3.1 알림 표시 : 헤드업 알림의 정의를 명확히 합니다.

    개정판 보기

    헤드업 알림은 사용자가 있는 표면과 독립적으로 들어올 때 사용자에게 표시되는 알림입니다.

  • 3.8.3.3 DND(방해 금지)/우선 모드 : DND(방해 금지) 요구 사항에 우선 모드를 포함하도록 업데이트합니다.

    개정판 보기

    3.8.3.3. DND(방해 금지) /우선 모드

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

  • 3.8.6 테마 : 동적 색조 팔레트에 대한 새로운 요구 사항.

    개정판 보기

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

    • [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 의 AOSP 문서에 지정된 대로 동적 색상 톤 팔레트를 생성해야 합니다( android.theme.customization.system_palette 및 android.theme.customization.theme_style 참조).

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

  • 3.8.17 클립보드 : 클립보드 콘텐츠에 대한 새로운 요구 사항 섹션을 추가했습니다.

    개정판 보기

    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 참조 구현은 이러한 클립보드 요구사항을 충족합니다.

  • 3.9.1.1 장치 소유자 프로비저닝 : 장치 소유자 프로비저닝 요구 사항 업데이트.

    개정판 보기

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

    • [C-1-1] 아래에 설명된 대로 기기 정책 클라이언트(DPC)를 기기 소유자 앱 으로 등록하는 것을 지원해야 합니다(MUST).
      • 기기 구현에 구성된 사용자와 사용자 데이터가 모두 없는 경우:
        • [C-1-5] 기기가 기능을 통해 근거리 통신(NFC) 지원을 선언하는 경우 DPC 애플리케이션을 기기 소유자 앱으로 등록 하거나 DPC 앱이 기기 소유자 또는 프로필 소유자가 될지 여부를 선택하도록 설정해야 합니다(MUST). android.hardware.nfc 플래그를 지정하고 MIME 유형이 MIME_TYPE_PROVISIONING_NFC 인 레코드가 포함된 NFC 메시지를 수신합니다.
        • [C-1-8] 기기 소유자 프로비저닝이 트리거된 후 DPC 앱이 android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES 의 값에 따라 기기 소유자 또는 프로필 소유자가 될지 여부를 선택할 수 있도록 ACTION_GET_PROVISIONING_MODE 인 텐트를 전송해야 합니다(MUST). 유효한 옵션이 하나만 있다는 것은 컨텍스트에서 확인할 수 있습니다. (예: 프로필 소유자 프로비저닝이 지원되지 않는 NFC 기반 프로비저닝).
        • [C-1-9] 사용된 프로비저닝 방법에 관계없이 프로비저닝 중에 기기 소유자가 설정된 경우 기기 소유자 앱에 ACTION_ADMIN_POLICY_COMPLIANCE 인텐트를 보내야 합니다(MUST). 기기 소유자 앱이 완료될 때까지 사용자는 설정 마법사를 진행할 수 없어야 합니다.
      • 기기 구현에 사용자 또는 사용자 데이터가 있는 경우:
        • [C-1-7] DPC 애플리케이션을 기기 소유자 앱으로 더 이상 등록하면 안 됩니다(MUST).
    • [C-1-2] 앱이 기기 소유자로 설정되기 전에 적절한 공개 알림(예 : AOSP 참조 )을 표시하고 최종 사용자로부터 긍정적인 동의를 얻어야 합니다(MUST). 화면상의 최종 사용자 상호 작용. 장치 소유자로 설정되는 앱에 동의하려면 프로비저닝 프로세스 전이나 도중에 긍정적인 조치를 취해야 합니다. 동의는 사용자 작업 또는 일부 프로그래밍 방식을 통해 이루어질 수 있지만 기기 소유자 프로비저닝이 시작되기 전에 적절한 공개 알림(AOSP 참조)이 표시되어야 합니다. 또한 장치 소유자 프로비저닝을 위해 (기업이) 사용하는 프로그래밍 방식 장치 소유자 동의 메커니즘은 기업용이 아닌 사용을 위한 Out-Of-Box Experience를 방해해서는 안 됩니다(MUST NOT).
    • [C-1-3] 동의를 하드 코딩하거나 다른 기기 소유자 앱의 사용을 방지하면 안 됩니다(MUST NOT).

    기기 구현에서 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).
    • DPC 애플리케이션을 "기기 소유자"로 등록하기 전에 기기에 사용자 데이터가 있을 수 있습니다(MAY).

  • 3.9.4 장치 관리 역할 요구 사항 : 장치 관리 역할 요구 사항에 대한 섹션이 추가되었습니다.

    개정판 보기

    3.9.4 장치 정책 관리 역할 요구 사항

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

    • [C-1-1] 섹션 9.1 에 정의된 기기 정책 관리 역할을 지원해야 합니다(MUST). 장치 정책 관리 역할을 보유한 애플리케이션은 config_devicePolicyManagement 패키지 이름으로 설정하여 정의할 수 있습니다(MAY). 애플리케이션이 미리 로드되지 않은 경우 패키지 이름 뒤에는 : 및 서명 인증서가 와야 합니다.

    위에서 설명한 대로 config_devicePolicyManagement 에 대해 패키지 이름이 정의되지 않은 경우:

    • [C-2-1] 기기 구현은 기기 정책 관리 역할 소유자 애플리케이션 없이 프로비저닝을 지원해야 합니다( AOSP는 참조 구현 제공 ).

    위에서 설명한 대로 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.18 연락처 : 새 연락처에 대한 정보를 추가합니다.

    개정판 보기

    새 연락처의 기본 계정: 연락처 제공자는 새 연락처를 만들 때 기본 계정 설정을 관리하기 위한 API를 제공합니다.

    기기 구현이 연락처 앱을 사전 로드하는 경우 사전 로드된 연락처 앱은 다음을 수행합니다.

    • [C-2-1] 계정 선택을 위한 UI를 시작하고 계정이 선택되면 설정을 연락처 제공자에 저장하기 위해 ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT 텐트를 처리해야 합니다(MUST).

    • [C-2-2] 초기에 계정을 선택하여 ContactsContracts.Contacts.CONTENT_TYPE 및 ContactsContract.RawContacts.CONTENT_TYPE 에 대한 Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT 처리할 때 기본 계정 설정을 준수해야 합니다(MUST).

4. 애플리케이션 패키징 호환성

5. 멀티미디어 호환성

  • 5.1.2 오디오 디코딩 : 다중 채널 오디오를 출력할 수 있는 디코더에 대한 새로운 요구 사항이 추가되었습니다.

    개정판 보기

    기기 구현이 android.media.MediaCodec API의 기본 AAC 오디오 디코더를 통해 다중 채널 스트림(예: 2개 이상의 채널)의 AAC 입력 버퍼를 PCM으로 디코딩하는 것을 지원하는 경우 다음이 지원되어야 합니다(MUST).

    • [C-7-1] KEY_MAX_OUTPUT_CHANNEL_COUNT 키로 디코딩을 사용하여 콘텐츠를 스테레오로 다운믹스할지(값 2를 사용하는 경우) 또는 기본 채널 수를 사용하여 출력할지를 제어하는 ​​애플리케이션에서 구성할 수 있어야 합니다(MUST). 해당 숫자와 같거나 큰 값을 사용할 때). 예를 들어 6 이상의 값은 5.1 콘텐츠를 공급할 때 디코더가 6개 채널을 출력하도록 구성합니다.
    • [C-7-2] 디코딩 시 디코더는 android.media.AudioFormat 상수(예: CHANNEL_OUT_5POINT1 )를 사용하여 KEY_CHANNEL_MASK 키로 출력 형식에 사용되는 채널 마스크를 광고해야 합니다(MUST).

    기기 구현이 기본 AAC 오디오 디코더 이외의 오디오 디코더를 지원하고 압축된 다중 채널 콘텐츠를 제공할 때 다중 채널 오디오(예: 2개 이상의 채널)를 출력할 수 있는 경우:

    • [C-SR] 디코더는 KEY_MAX_OUTPUT_CHANNEL_COUNT 키로 디코딩하여 콘텐츠를 스테레오로 다운믹싱할지(값 2 사용 시) 또는 기본 숫자를 사용하여 출력할지를 제어하는 ​​애플리케이션에서 구성할 수 있도록 할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 채널 수(해당 숫자와 같거나 큰 값을 사용하는 경우). 예를 들어 6 이상의 값은 5.1 콘텐츠를 공급할 때 디코더가 6개 채널을 출력하도록 구성합니다.
    • [C-SR] 디코딩할 때 디코더는 android.media.AudioFormat 상수(예: CHANNEL_OUT_5POINT1 )를 사용하여 KEY_CHANNEL_MASK 키로 출력 형식에 사용되는 채널 마스크를 광고할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 5.4.1 원시 오디오 캡처 및 마이크 정보 : 오디오 입력 스트림에 대해 지원되는 오디오 소스 업데이트.

    개정판 보기

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

  • 5.4.2 음성 인식을 위한 캡처 : 음성 인식 오디오 스트림에 대한 요구 사항 업데이트 및 마이크 게인 수준에 대한 요구 사항 추가.

    개정판 보기

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

    • 대략적인 진폭 대 주파수 특성(구체적으로 ±3dB, 100Hz ~ 4000Hz)으로 음성 인식 오디오 스트림을 녹음해야 합니다(SHOULD).
    • 1000Hz에서 90dB 음력 레벨(SPL) 소스가 16비트 샘플에 대해 2500의 RMS를 생성하도록 입력 감도가 설정된 음성 인식 오디오 스트림을 녹음해야 합니다(SHOULD).

    • 중간 주파수 범위에서 거의 평탄한 진폭 대 주파수 특성을 나타내야 합니다(SHOULD). 구체적으로 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크에 대해 100Hz~4000Hz에서 ±3dB입니다.
    • [C-SR]은 저주파 범위에서 진폭 수준을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 특히 음성 인식 오디오 소스를 녹음하는 데 사용되는 각각의 모든 마이크에 대해 중간 주파수 범위와 비교하여 30Hz~100Hz에서 ±20dB입니다.
    • [C-SR]은 고주파수 범위에서 진폭 수준을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 특히 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크의 중간 주파수 범위와 비교하여 4000Hz~22KHz에서 ±30dB입니다.
    • 90dB 음압 수준(SPL)(마이크 옆에서 측정)에서 재생되는 1000Hz 사인파 톤 소스가 16비트 샘플에 대해 1770 및 3530 범위 내에서 RMS 2500의 이상적인 응답을 생성하도록 오디오 입력 감도를 설정해야 합니다(SHOULD). 또는 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크에 대해 -22.35db ±3dB 풀 스케일(부동 소수점/배정밀도 샘플의 경우).

  • 5.4.6 마이크 게인 레벨 : 마이크 게인 레벨에 대한 요구 사항이 섹션 5.4.2로 이동되었습니다.

    개정판 보기

    5.4.6. 마이크 게인 레벨 [5.4.2로 이동]

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

    • 중간 주파수 범위에서 거의 평탄한 진폭 대 주파수 특성을 나타내야 합니다(SHOULD). 구체적으로 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크에 대해 100Hz~4000Hz에서 ±3dB입니다.
    • [C-SR]은 저주파 범위에서 진폭 수준을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 특히 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크의 중간 주파수 범위와 비교하여 5Hz~100Hz에서 ±20dB입니다.
    • [C-SR]은 고주파수 범위에서 진폭 수준을 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 특히 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크의 중간 주파수 범위와 비교하여 4000Hz~22KHz에서 ±30dB입니다.
    • 90dB 음압 레벨(SPL)에서 재생되는 1000Hz 사인파 톤 소스가 16비트 샘플에 대해 2500의 RMS(또는 부동 소수점/배정밀도 샘플에 대해 -22.35dB 풀 스케일)로 응답을 생성하도록 오디오 입력 감도를 설정해야 합니다(SHOULD). 음성 인식 오디오 소스를 녹음하는 데 사용되는 모든 마이크에 대해.

  • 5.5.4 오디오 오프로드 : 오디오 오프로드 재생 요구 사항을 업데이트합니다.

    개정판 보기

    오디오 오프로드 재생을 지원하는 기기 구현은 다음을 충족해야 합니다.

    • [C-SR] AudioTrack 끊김 없는 API 및 MediaPlayer용 미디어 컨테이너에서 지정한 경우 동일한 형식의 두 클립 간에 재생된 끊김 없는 오디오 콘텐츠를 트리밍할 것을 적극 권장합니다(STRONGLY RECOMMENDED).

  • 5.6 오디오 대기 시간 : 오디오 대기 시간 요구 사항 업데이트.

    개정판 보기

    이 섹션의 목적을 위해 다음 정의를 사용합니다.

    • 콜드 출력 지터 . 콜드 출력 대기 시간 값의 개별 측정 간의 변동성.
    • 콜드 입력 지터 . 콜드 입력 대기 시간 값의 개별 측정 간의 변동성.

    기기 구현이 android.hardware.audio.output 선언하는 경우 다음 요구사항을 충족하거나 초과해야 합니다(MUST).

    • [C-1-2] 500밀리초 이하의 콜드 출력 지연 시간.
    • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.
    • [C-SR] Minimize the cold output jitter.

    If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

    • [C-3-2] Cold input latency of 500 milliseconds or less.
    • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations include android.hardware.microphone , they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

    • [C-SR] Continuous input latency of 30 milliseconds or less.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .

  • 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU work information

      장치 구현:

      • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

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

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    장치 구현:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

    • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include an accelerometer, a 3-axis accelerometer, they:

    • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

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

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

    • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
    • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
      • Revoke or limit network access
      • Revoke permissions
      • Restrict background or foreground app execution beyond the existing power management features included in AOSP
      • Disable or uninstall the app

    If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

    See revision

    7.4.1.3. Cellular NAT-T Keepalive Offload

    장치 구현:

    • SHOULD include support for Cellular keepalive offload.

    If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
    • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
    • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

    If device implementations do not include support for cellular keepalive offload, they:

    • [C-2-1] MUST return ERROR_UNSUPPORTED.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
    • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    장치 구현:

    • SHOULD include support for Wi-Fi keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
      and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload, they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

    • [C-4-1] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
    • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations declare FEATURE_BLUETOOTH_LE , they:

    • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
    • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

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

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR] Are STRONGLY RECOMMENDED to provide support for:
      • LE 2M PHY
      • LE Codec PHY
      • LE Advertising Extension
      • Periodic advertising
      • At least 10 advertisement sets
      • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
      • LE Link Layer Privacy
      • A "resolving list" size of at least 8 entries

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

    • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
    • [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.

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

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
    • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
    • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
    • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. 장치 구현:

    • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    장치 구현:

    • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. 보안 격리는 커널 또는 사용자 공간 코드가 DMA를 포함하여 격리된 환경의 내부 상태에 액세스할 수 있는 모든 잠재적 메커니즘을 차단해야 합니다(MUST). 업스트림 AOSP(Android 오픈 소스 프로젝트)는 Trusty 구현을 사용하여 이 요구 사항을 충족하지만 다른 ARM TrustZone 기반 솔루션 또는 적절한 하이퍼바이저 기반 격리의 타사 검토 보안 구현이 대체 옵션입니다.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

    If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:

    • [C-13-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
    • [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. 장치 구현:

    The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), the Android host:

    • [C-1-1] MUST support all the APIs defined by the android.system.virtualmachine.* package.
    • [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
    • [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
    • [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
    • [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
    • [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
    • [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then the hypervisor:

    • [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
    • [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    If the device implements support for the Android Virtualization Framework APIs, then across all areas:

    • [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.

    If the device implements support for the Android Virtualization Framework APIs, then:

    • [C-5-1] MUST support Isolated Compilation of an ART runtime update.

    If the device implements support for the Android Virtualization Framework APIs, then for Key Management:

    • [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
    • [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top