Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Changelog tài liệu định nghĩa khả năng tương thích của Android

Android 13

Ngày 19 tháng 10 năm 2022

2. Loại thiết bị

  • 2.2.3 Phần mềm

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị cầm tay không chạy ở chế độ tác vụ khóa , thì khi nội dung được sao chép vào khay nhớ tạm, chúng sẽ:

    • [3.8.17/H-1-1] PHẢI đưa ra xác nhận cho người dùng rằng dữ liệu đã được sao chép vào khay nhớ tạm (ví dụ: hình thu nhỏ hoặc cảnh báo về “Đã sao chép nội dung.”). Ngoài ra, hãy bao gồm ở đây một dấu hiệu nếu dữ liệu khay nhớ tạm sẽ được đồng bộ hóa giữa các thiết bị.

3. Phần mềm

  • 3.2.3.5. Ý định ứng dụng có điều kiện

    Xem bản sửa đổi

    Nếu ứng dụng Cài đặt của triển khai thiết bị triển khai chức năng phân tách , bằng cách sử dụng hoạt động nhúng, thì chúng:

    Nếu việc triển khai thiết bị hỗ trợ VoiceInteractionService và có nhiều ứng dụng sử dụng API này được cài đặt cùng lúc, chúng sẽ:

  • 3.4.1 Khả năng tương thích của chế độ xem web

    Xem bản sửa đổi

    • [C-1-4] PHẢI hiển thị' nội dung được cung cấp hoặc nội dung URL từ xa trong một quy trình khác với ứng dụng khởi tạo WebView. Cụ thể, quy trình kết xuất riêng biệt PHẢI giữ đặc quyền thấp hơn, chạy dưới dạng ID người dùng riêng biệt, không có quyền truy cập vào thư mục dữ liệu của ứng dụng, không có quyền truy cập mạng trực tiếp và chỉ có quyền truy cập vào các dịch vụ hệ thống yêu cầu tối thiểu qua Binder. Việc triển khai AOSP của WebView đáp ứng yêu cầu này.

7. Khả năng tương thích phần cứng

  • 7.4.2 IEEE 802.11 (WiFi)

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị bao gồm hỗ trợ cho chế độ tiết kiệm năng lượng Wi-Fi như được xác định trong tiêu chuẩn IEEE 802.11, thì chúng:

  • 7.4.3 Bluetooth

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị bao gồm hỗ trợ cho Bluetooth Low Energy (BLE), chúng sẽ:

    • [C-3-5] PHẢI triển khai thời gian chờ Địa chỉ riêng có thể phân giải (RPA) không quá 15 phút và xoay địa chỉ khi hết thời gian chờ để bảo vệ quyền riêng tư của người dùng khi thiết bị đang tích cực sử dụng BLE để quét hoặc quảng cáo. Để ngăn chặn các cuộc tấn công theo thời gian, khoảng thời gian chờ cũng PHẢI được sắp xếp ngẫu nhiên trong khoảng từ 5 đến 15 phút.

  • 7.5.5 Hướng máy ảnh

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị có camera phía trước hoặc phía sau, thì (các) camera đó:

    • [C-1-1] PHẢI được định hướng sao cho kích thước dài của máy ảnh thẳng hàng với kích thước dài của màn hình. Nghĩa là, khi thiết bị được giữ theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang. Điều này áp dụng bất kể hướng tự nhiên của thiết bị; nghĩa là, nó áp dụng cho các thiết bị chính theo chiều ngang cũng như các thiết bị chính theo chiều dọc.

    Các thiết bị đáp ứng tất cả các tiêu chí sau đây được miễn yêu cầu ở trên:

    • Thiết bị triển khai màn hình có hình dạng thay đổi, chẳng hạn như màn hình có thể gập lại hoặc có bản lề.
    • Khi trạng thái gập hoặc bản lề của thiết bị thay đổi, thiết bị sẽ chuyển đổi giữa hướng dọc-chính sang hướng ngang-chính (hoặc ngược lại).

9. Khả năng tương thích của mô hình bảo mật

  • 9.11 Khóa và thông tin xác thực

    Xem bản sửa đổi

    Khi triển khai thiết bị hỗ trợ màn hình khóa an toàn, thiết bị sẽ:

    • [C-1-6] PHẢI hỗ trợ IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice phiên bản 1 hoặc IKeyMintDevice phiên bản 2.

  • 9.17 Khung ảo hóa Android

    Xem bản sửa đổi

    Nếu thiết bị triển khai hỗ trợ cho Android Virtualization Framework APIs ( android.system.virtualmachine.* ), thì máy chủ Android:

    • [C-1-3] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc không bao giờ cho phép có trong hệ thống/chính sách bảo mật được cung cấp trong Dự án nguồn mở Android ngược dòng (AOSP) và chính sách PHẢI biên dịch với tất cả các quy tắc không bao giờ cho phép hiện có.

    Nếu thiết bị triển khai hỗ trợ cho Android Virtualization Framework APIs ( android.system.virtualmachine.* ), thì mọi phiên bản Máy ảo được bảo vệ:

    • [C-2-4] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc không bao giờ cho phép có trong hệ thống/chính sách bảo mật/microdroid được cung cấp trong Dự án nguồn mở Android ngược dòng (AOSP).

    Nếu thiết bị triển khai hỗ trợ cho Android Virtualization Framework APIs, thì đối với Quản lý khóa:

    • [C-6-2] PHẢI làm DICE đúng cách tức là cung cấp các giá trị chính xác. Nhưng nó có thể không phải đi đến mức độ chi tiết đó.

Ngày 15 tháng 8 năm 2022

2. Loại thiết bị

  • 2.2.1 Phần cứng : Thay đổi về yêu cầu phần cứng như sau.

    • Thiết bị đầu vào:

      Xem bản sửa đổi

      Triển khai thiết bị cầm tay:

      • [ 7.2 .3/H-0-5] PHẢI gọi OnBackInvokedCallback.onBackStarted() trên cửa sổ được đặt tiêu điểm hiện tại khi cử chỉ quay lại bắt đầu hoặc nút quay lại ( KEYCODE_BACK ) được nhấn XUỐNG.
      • [ 7.2 .3/H-0-6] PHẢI gọi OnBackInvokedCallback.onBackInvoked() khi cử chỉ quay lại được thực hiện hoặc nút Quay lại được nhả (LÊN).
      • [ 7.2 .3/H-0-7] PHẢI gọi OnBackInvokedCallback.onBackCancelled() khi cử chỉ quay lại không được thực hiện hoặc sự kiện KEYCODE_BACK bị hủy.

      Nếu các thiết bị hỗ trợ giao thức Mạng nhận thức hàng xóm WiFi (NAN) bằng cách khai báo PackageManager.FEATURE_WIFI_AWARE và Vị trí Wi-Fi (Wi-Fi Round Trip Time — RTT) bằng cách khai báo PackageManager.FEATURE_WIFI_RTT , thì chúng:

      • [ 7.4 .2.5/H-1-1] PHẢI báo cáo phạm vi chính xác trong phạm vi +/- 1 mét ở băng thông 160 MHz ở phân vị thứ 68 (như được tính bằng Chức năng phân phối tích lũy), +/- 2 mét ở băng thông 80 MHz ở phân vị thứ 68, +/- 4 mét ở băng thông 40 MHz ở phân vị thứ 68 và +/- 8 mét ở băng thông 20 MHz ở phân vị thứ 68 ở khoảng cách 10 cm, 1 m, 3 m và 5 m, như được quan sát qua API WifiRttManager#startRanging Android .

      • [ 7.4 .2.5/H-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để báo cáo phạm vi chính xác trong phạm vi +/- 1 mét ở băng thông 160 MHz ở phân vị thứ 90 (như được tính bằng Chức năng phân phối tích lũy), +/- 2 mét ở 80 MHz băng thông ở phân vị thứ 90, +/-4 mét ở băng thông 40 MHz ở phân vị thứ 90 và +/- 8 mét ở băng thông 20 MHz ở phân vị thứ 90 ở khoảng cách 10 cm, như được quan sát qua API WifiRttManager#startRanging Android .

      MẠNH KHUYẾN NGHỊ thực hiện theo các bước thiết lập phép đo được chỉ định trong Yêu cầu hiệu chuẩn hiện diện .

    • Độ trễ âm thanh:

      Xem bản sửa đổi

      Nếu việc triển khai Thiết bị cầm tay khai báo android.hardware.audio.outputandroid.hardware.microphone , thì chúng:

      • [ 5.6 /H-1-1] PHẢI có độ trễ Chuyến đi khứ hồi liên tục trung bình là 500 800 mili giây hoặc ít hơn trên 5 phép đo, với Độ lệch tuyệt đối trung bình nhỏ hơn 50 100 ms, qua các đường dẫn dữ liệu sau: "loa tới micrô", bộ chuyển đổi vòng lặp 3,5 mm (nếu được hỗ trợ), vòng lặp USB (nếu được hỗ trợ). ít nhất một đường dẫn được hỗ trợ.

      • [ 5.6 /H-1-1] PHẢI có độ trễ trung bình của Nhấn để chuyển âm là 500 mili giây trở xuống trong ít nhất 5 phép đo qua đường dẫn dữ liệu từ loa đến micrô.

    • Đầu vào xúc giác:

      Xem bản sửa đổi

      Nếu việc triển khai thiết bị cầm tay bao gồm ít nhất một bộ truyền động haptic, chúng sẽ:

      • [ 7.10 /H]* KHÔNG NÊN sử dụng bộ truyền động haptic khối lượng quay lệch tâm (ERM) (bộ rung).
      • [ 7.10 /H]* NÊN bố trí vị trí của bộ dẫn động gần vị trí mà tay thường cầm hoặc chạm vào thiết bị.
      • [ 7.10 /H]* NÊN triển khai tất cả các hằng số công khai để có xúc giác rõ ràng trong android.view.HapticFeedbackConstants cụ thể là (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRMTURE_END và START, GESTURE_END).
      • [ 7.10 /H]* NÊN triển khai tất cả các hằng số công khai để có haptics rõ ràng trong android.os.VibrationEffect cụ thể là (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK và EFFECT_DOUBLE_CLICK) và tất cả các hằng số PRIMITIVE_* công khai khả thi cho haptics phong phú trong android.os.VibrationEffect.Composition cụ thể là (PRIMITIVE_CLICK và PRIMITIVE_TICK) (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Một số nguyên mẫu này, chẳng hạn như LOW_TICK và SPIN chỉ có thể khả thi nếu bộ rung có thể hỗ trợ các tần số tương đối thấp.

      • [ 7.10 /H]* NÊN sử dụng các ánh xạ hằng số xúc giác được liên kết này .

      Nếu việc triển khai thiết bị cầm tay bao gồm ít nhất một bộ truyền động cộng hưởng tuyến tính, chúng sẽ:

      • [ 7.10 /H]* NÊN di chuyển bộ truyền động xúc giác theo trục X (trái-phải) của hướng dọc.

      • [ 7.10 /H]* NÊN xác minh và cập nhật nếu cần cấu hình dự phòng cho các nguyên mẫu không được hỗ trợ như được mô tả trong hướng dẫn triển khai cho hằng số.

      • [7.10/H]* NÊN cung cấp hỗ trợ dự phòng để giảm thiểu nguy cơ lỗi như được mô tả tại đây .

  • 2.2.3 Phần mềm :

    • Kiểm soát thiết bị tầm thường Auth:

      Xem bản sửa đổi

      • [ 3.8 .16/H-1-5] PHẢI cung cấp cho người dùng khả năng chọn không tham gia các biện pháp kiểm soát thiết bị xác thực tầm thường do ứng dụng chỉ định từ các biện pháp kiểm soát do ứng dụng bên thứ ba đăng ký thông qua ControlsProviderService và API Control Control.isAuthRequired .

    • Thông báo MediaStyle:

      Xem bản sửa đổi

      Nếu việc triển khai thiết bị cầm tay hỗ trợ thông báo MediaStyle thì:

      • [3.8.3.1/H-1-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để cung cấp khả năng chi trả cho người dùng (ví dụ: “bộ chuyển đổi đầu ra”) được truy cập từ giao diện người dùng hệ thống cho phép người dùng chuyển đổi giữa các tuyến phương tiện khả dụng thích hợp (ví dụ: thiết bị bluetooth và các tuyến được cung cấp cho MediaRouter2Manager ) khi ứng dụng đăng thông báo MediaStyle bằng mã thông báo MediaSession .

  • 2.2.4 Hiệu suất và sức mạnh : Yêu cầu mới đối với các ứng dụng chạy dịch vụ tiền cảnh.

    Xem bản sửa đổi

    Triển khai thiết bị cầm tay:

    • [ 8.5 /H-0-1] PHẢI cung cấp cho người dùng khả năng chi trả trong menu Cài đặt với khả năng dừng ứng dụng đang chạy dịch vụ nền trước và hiển thị tất cả các ứng dụng có dịch vụ nền trước đang hoạt động và thời lượng của từng dịch vụ này kể từ khi nó đã bắt đầu như được mô tả trong tài liệu SDK .
      • Một số ứng dụng CÓ THỂ được miễn khỏi bị dừng hoặc được liệt kê trong khả năng chi trả của người dùng như được mô tả trong tài liệu SDK .

  • 2.2.7.1 Phương tiện : Cập nhật phần Phương tiện Yêu cầu Cầm tay như sau:

    Xem bản sửa đổi

    Nếu việc triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS thì chúng:

    • [5.1/H-1-1] PHẢI quảng cáo số phiên bộ giải mã video phần cứng tối đa có thể chạy đồng thời trong bất kỳ tổ hợp codec nào thông qua các phương thức CodecCapabilities.getMaxSupportedInstances()VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-2] PHẢI hỗ trợ 6 phiên bản phiên giải mã video phần cứng (AVC, HEVC, VP9, ​​AV1 trở lên) trong bất kỳ tổ hợp codec nào chạy đồng thời ở độ phân giải 1080p@30 khung hình/giây.
    • [5.1/H-1-3] PHẢI quảng cáo số lượng phiên bộ mã hóa video phần cứng tối đa có thể chạy đồng thời trong bất kỳ tổ hợp codec nào thông qua các phương thức CodecCapabilities.getMaxSupportedInstances()VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-4] PHẢI hỗ trợ 6 phiên bản bộ mã hóa video phần cứng (AVC, HEVC, VP9, ​​AV1 trở lên) trong bất kỳ tổ hợp codec nào chạy đồng thời ở độ phân giải 1080p@30fps.
    • [5.1/H-1-5] PHẢI quảng cáo số phiên bộ mã hóa và giải mã video phần cứng tối đa có thể chạy đồng thời trong bất kỳ tổ hợp codec nào thông qua các phương thức CodecCapabilities.getMaxSupportedInstances()VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-6] PHẢI hỗ trợ 6 phiên bản của bộ giải mã video phần cứng và phiên bộ mã hóa video phần cứng (AVC, HEVC, VP9, ​​AV1 trở lên) trong mọi tổ hợp codec chạy đồng thời ở độ phân giải 1080p@30fps.
    • [5.1/H-1-7] PHẢI có độ trễ khởi tạo codec từ 40 mili giây trở xuống đối với phiên mã hóa video 1080p trở xuống cho tất cả các bộ mã hóa video phần cứng khi đang tải. Tải ở đây được định nghĩa là phiên chuyển mã đồng thời chỉ dành cho video 1080p sang 720p bằng cách sử dụng codec video phần cứng cùng với quá trình khởi tạo ghi âm thanh-video 1080p.
    • [5.1/H-1-8] PHẢI có độ trễ khởi tạo codec từ 30 ms trở xuống đối với phiên mã hóa âm thanh tốc độ bit 128 kbps trở xuống cho tất cả các bộ mã hóa âm thanh khi đang tải. Tải ở đây được định nghĩa là phiên chuyển mã đồng thời chỉ dành cho video 1080p sang 720p bằng cách sử dụng codec video phần cứng cùng với quá trình khởi tạo ghi âm thanh-video 1080p.
    • [5.1/H-1-9] PHẢI hỗ trợ 2 phiên bản phiên giải mã video phần cứng an toàn (AVC, HEVC, VP9, ​​AV1 trở lên) trong bất kỳ tổ hợp codec nào chạy đồng thời ở độ phân giải 1080p@30 khung hình/giây.
    • [5.1/H-1-10] PHẢI hỗ trợ 3 phiên bản phiên giải mã video phần cứng không bảo mật cùng với 1 phiên bản giải mã video phần cứng bảo mật (tổng cộng 4 phiên bản) (AVC, HEVC, VP9, ​​AV1 trở lên) trong bất kỳ codec nào kết hợp chạy đồng thời ở độ phân giải 1080p@30fps.
    • [5.1/ H-1-11] PHẢI hỗ trợ bộ giải mã an toàn cho mọi bộ giải mã phần cứng AVC, HEVC, VP9 hoặc AV1 trên thiết bị.
    • [5.1/H-1-12] PHẢI có độ trễ khởi tạo bộ giải mã video từ 40 mili giây trở xuống.
    • [5.1/H-1-13] PHẢI có độ trễ khởi tạo bộ giải mã âm thanh từ 30 mili giây trở xuống.
    • [5.1/H-1-14] PHẢI hỗ trợ bộ giải mã phần cứng AV1 Chính 10, Mức 4.1.
    • [5.1/H-SR] Rất khuyến khích hỗ trợ Film Grain cho bộ giải mã phần cứng AV1.
    • [5.1/H-1-15] PHẢI có ít nhất 1 bộ giải mã video phần cứng hỗ trợ 4K60.
    • [5.1/H-1-16] PHẢI có ít nhất 1 bộ mã hóa video phần cứng hỗ trợ 4K60.
    • [5.3/H-1-1] KHÔNG ĐƯỢC giảm nhiều hơn 1 khung hình trong 10 giây (tức là giảm ít hơn 0,167 phần trăm khung hình) đối với phiên video 1080p 60 khung hình/giây đang tải. Tải được định nghĩa là phiên chuyển mã đồng thời chỉ dành cho video 1080p sang 720p bằng cách sử dụng codec video phần cứng, cũng như phát lại âm thanh AAC 128 kbps.
    • [5.3/H-1-2] KHÔNG ĐƯỢC giảm hơn 1 khung hình trong 10 giây khi thay đổi độ phân giải video trong phiên video 60 khung hình/giây đang tải. Tải được định nghĩa là phiên chuyển mã đồng thời chỉ dành cho video 1080p sang 720p bằng cách sử dụng codec video phần cứng, cũng như phát lại âm thanh AAC 128 kbps.
    • [5.6/H-1-1] PHẢI có độ trễ chạm để nhận âm thanh từ 80 mili giây trở xuống bằng cách sử dụng thử nghiệm nhấn để nhận âm thanh của OboeTester hoặc thử nghiệm để nhấn vào âm thanh của CTS Verifier.
    • [5.6/H-1-2] PHẢI có độ trễ âm thanh khứ hồi từ 80 mili giây trở xuống trên ít nhất một đường dẫn dữ liệu được hỗ trợ.
    • [5.6/H-1-3] PHẢI hỗ trợ âm thanh >=24 bit cho đầu ra âm thanh nổi qua giắc cắm âm thanh 3,5 mm nếu có và qua âm thanh USB nếu được hỗ trợ qua toàn bộ đường dẫn dữ liệu đối với cấu hình phát trực tuyến và độ trễ thấp. Đối với cấu hình có độ trễ thấp, ứng dụng nên sử dụng AAudio ở chế độ gọi lại có độ trễ thấp. Đối với cấu hình phát trực tuyến, ứng dụng phải sử dụng Java AudioTrack. Trong cả cấu hình phát trực tuyến và độ trễ thấp, đầu ra HAL chìm phải chấp nhận AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT hoặc AUDIO_FORMAT_PCM_FLOAT cho định dạng đầu ra mục tiêu của nó.
    • [5.6/H-1-4] PHẢI hỗ trợ >=4 thiết bị âm thanh USB kênh (Thiết bị này được bộ điều khiển DJ sử dụng để xem trước bài hát.)
    • [5.6/H-1-5] PHẢI hỗ trợ các thiết bị MIDI tương thích với lớp và khai báo cờ tính năng MIDI.
    • [5.7/H-1-2] PHẢI hỗ trợ MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL với khả năng giải mã nội dung bên dưới.
    Cỡ mẫu tối thiểu 4 MiB
    Số lượng mẫu phụ tối thiểu - H264 hoặc HEVC 32
    Số lượng mẫu con tối thiểu - VP9 9
    Số lượng mẫu phụ tối thiểu - AV1 288
    Kích thước bộ đệm mẫu con tối thiểu 1 MiB
    Kích thước bộ đệm tiền điện tử chung tối thiểu 500 KiB
    Số lượng phiên đồng thời tối thiểu 30
    Số lượng khóa tối thiểu mỗi phiên 20
    Tổng số khóa tối thiểu (tất cả các phiên) 80
    Tổng số lượng khóa DRM tối thiểu (tất cả các phiên) 6
    Kích thước tin nhắn 16 KiB
    Khung hình được giải mã trên giây 60 khung hình/giây

  • 2.2.7.2 Máy ảnh : Cập nhật các yêu cầu về Máy ảnh của Lớp hiệu suất phương tiện.

    Xem bản sửa đổi

    Nếu việc triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS thì chúng:

    • [7.5/H-1-1] PHẢI có camera chính phía sau với độ phân giải ít nhất 12 megapixel hỗ trợ quay video ở 4k@30fps. Máy ảnh chính phía sau là máy ảnh phía sau có ID máy ảnh thấp nhất.
    • [7.5/H-1-2] PHẢI có camera chính phía trước với độ phân giải ít nhất là 5 megapixel và hỗ trợ quay video ở 1080p@30fps. Máy ảnh mặt trước chính là máy ảnh mặt trước có ID máy ảnh thấp nhất.
    • [7.5/H-1-3] PHẢI hỗ trợ thuộc tính android.info.supportedHardwareLevel ở dạng FULL hoặc tốt hơn cho cả hai máy ảnh chính.
    • [7.5/H-1-4] PHẢI hỗ trợ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME cho cả hai máy ảnh chính.
    • [7.5/H-1-5] PHẢI có độ trễ chụp ảnh JPEG của camera2 < 1000 ms đối với độ phân giải 1080p như được đo bằng Kiểm tra hiệu suất máy ảnh CTS trong điều kiện ánh sáng ITS (3000K) cho cả hai máy ảnh chính.
    • [7.5/H-1-6] PHẢI có độ trễ khởi động camera2 (mở camera để xem khung hình xem trước đầu tiên) < 500 mili giây như được đo bằng Kiểm tra hiệu suất camera CTS trong điều kiện ánh sáng ITS (3000K) cho cả hai camera chính.
    • [7.5/H-1-8] PHẢI hỗ trợ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWandroid.graphics.ImageFormat.RAW_SENSOR cho camera sau chính.
    • [7.5/H-1-9] PHẢI có camera chính phía sau hỗ trợ 720p hoặc 1080p @ 240fps.
    • [7.5/H-1-10] PHẢI có ZOOM_RATIO tối thiểu < 1.0 cho các camera chính nếu có một camera góc siêu rộng RGB hướng về cùng một hướng.
    • [7.5/H-1-11] PHẢI triển khai truyền phát đồng thời từ trước ra sau trên máy ảnh chính.
    • [7.5/H-1-12] PHẢI hỗ trợ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION cho cả camera chính phía trước và phía sau.
    • [7.5/H-1-13] PHẢI hỗ trợ khả năng LOGICAL_MULTI_CAMERA cho camera chính nếu có nhiều hơn 1 camera RGB hướng về cùng một hướng.
    • [7.5/H-1-14] PHẢI hỗ trợ khả năng STREAM_USE_CASE cho cả camera chính phía trước và phía sau.

  • 2.2.7.3 Phần cứng : Cập nhật các yêu cầu của Lớp hiệu suất phương tiện cho Phần cứng.

    Xem bản sửa đổi

    Nếu việc triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS thì chúng:

    • [7.1.1.1/H-2-1] PHẢI có độ phân giải màn hình ít nhất là 1080p.
    • [7.1.1.3/H-2-1] PHẢI có mật độ màn hình ít nhất là 400 dpi.
    • [7.6.1/H-2-1] PHẢI có ít nhất 8 GB bộ nhớ vật lý.

  • 2.2.7.4 Hiệu suất : Các bản cập nhật cho Lớp Hiệu suất Phương tiện cho Hiệu suất.

    Xem bản sửa đổi

    Nếu việc triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS thì chúng:

    • [8.2/H-1-1] PHẢI đảm bảo hiệu suất ghi tuần tự ít nhất là 125 MB/s.
    • [8.2/H-1-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên ít nhất là 10 MB/s.
    • [8.2/H-1-3] PHẢI đảm bảo hiệu suất đọc tuần tự ít nhất là 250 MB/s.
    • [8.2/H-1-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên ít nhất là 40 MB/s.

  • 2.5.1 Phần cứng : Cập nhật các yêu cầu về gia tốc kế 3 trục và con quay hồi chuyển 3 trục, cũng như các yêu cầu về camera quan sát bên ngoài.

    Xem bản sửa đổi

    Triển khai thiết bị ô tô:

    • [ 7.3 .1/A-0-4] PHẢI tuân thủ hệ tọa độ cảm biến ô tô của Android .
    • [ 7.3 /A-SR] ĐƯỢC MẠNH MẼ_REKHÔNG bao gồm gia tốc kế 3 trục và con quay hồi chuyển 3 trục.
    • [ 7.3 /A-SR] MẠNH MẼ_REKHUYÊN triển khai và báo cáo cảm biến TYPE_HEADING .

    Nếu việc triển khai thiết bị Ô tô bao gồm một gia tốc kế, chúng sẽ:

    • [ 7.3 .1/A-1-1] PHẢI có khả năng báo cáo các sự kiện với tần số tối thiểu là 100 Hz.

    Nếu việc triển khai thiết bị bao gồm gia tốc kế 3 trục, chúng sẽ:

    • [ 7.3 .1/A-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để triển khai cảm biến tổng hợp cho gia tốc kế trục giới hạn.

    Nếu việc triển khai thiết bị Ô tô bao gồm một cảm biến gia tốc có ít hơn 3 trục, chúng sẽ:

    • [ 7.3 .1/A-1-3] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_LIMITED_AXES .
    • [ 7.3 .1/A-1-4] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED .

    Nếu việc triển khai thiết bị ô tô bao gồm con quay hồi chuyển, chúng sẽ:

    • [ 7.3 .4/A-2-1] PHẢI có khả năng báo cáo các sự kiện với tần số tối thiểu là 100 Hz.
    • [ 7.3 .4/A-2-3] PHẢI có khả năng đo các thay đổi về hướng lên tới 250 độ mỗi giây.
    • [ 7.3 .4/A-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để định cấu hình phạm vi đo của con quay hồi chuyển thành +/-250dps để tối đa hóa độ phân giải có thể.

    Nếu việc triển khai thiết bị Ô tô bao gồm con quay hồi chuyển 3 trục, chúng sẽ:

    • [ 7.3 .4/A-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để triển khai cảm biến tổng hợp cho con quay hồi chuyển trục giới hạn.

    Nếu việc triển khai thiết bị Ô tô bao gồm con quay hồi chuyển có ít hơn 3 trục, thì chúng:

    • [ 7.3 .4/A-4-1] PHẢI triển khai và báo cáo cảm biến TYPE_GYROSCOPE_LIMITED_AXES .
    • [ 7.3 .4/A-4-2] PHẢI triển khai và báo cáo cảm biến TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED .

    Nếu việc triển khai thiết bị ô tô bao gồm cảm biến TYPE_HEADING , chúng sẽ:

    • [ 7.3 .4/A-4-3] PHẢI có khả năng báo cáo các sự kiện với tần số tối thiểu là 1 Hz.
    • [ 7.3 .4/A-SR] STRONGLY_RECOMMENDED để báo cáo các sự kiện có tần suất tối thiểu là 10 Hz.
    • NÊN có liên quan đến hướng bắc thực sự.
    • NÊN có ngay cả khi xe đứng yên.
    • NÊN có độ phân giải ít nhất là 1 độ.

    Camera quan sát bên ngoài là camera ghi lại các cảnh bên ngoài thiết bị thực hiện, giống như camera chiếu hậu một camera hành trình .

    Nếu việc triển khai thiết bị Ô tô bao gồm một camera quan sát bên ngoài, thì đối với một camera như vậy, chúng sẽ:

    • [ 7.5 .5/A-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ nên định hướng sao cho chiều dài của máy ảnh thẳng hàng với đường chân trời.

    • CÓ THỂ triển khai lấy nét tự động phần cứng hoặc tự động lấy nét phần mềm trong trình điều khiển máy ảnh.

    Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều camera quan sát bên ngoài và tải dịch vụ Hệ thống quan sát bên ngoài (EVS), thì đối với camera như vậy, chúng sẽ:

    • [ 7.5 /A-2-1] KHÔNG ĐƯỢC xoay hoặc phản chiếu theo chiều ngang phần xem trước của máy ảnh.

    Triển khai thiết bị ô tô:

    • CÓ THỂ bao gồm một hoặc nhiều máy ảnh có sẵn cho các ứng dụng của bên thứ ba.

    Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một camera và cung cấp camera đó cho các ứng dụng của bên thứ ba thì chúng sẽ:

    • [ 7.5 /A-3-1] PHẢI báo cáo cờ tính năng android.hardware.camera.any .
    • [ 7.5 /A-3-2] KHÔNG ĐƯỢC khai báo máy ảnh là máy ảnh hệ thống .
    • CÓ THỂ hỗ trợ máy ảnh bên ngoài được mô tả trong phần 7.5.3 .
    • CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, v.v.) khả dụng cho máy ảnh phía sau như được mô tả trong phần 7.5.1 .

  • 2.5.5 Mô hình bảo mật : Yêu cầu mới về quyền truy cập máy ảnh đối với thiết bị ô tô.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị Ô tô khai báo android.hardware.camera.any , thì chúng:

    • [ 9.8.2 /A-2-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập dữ liệu máy ảnh trực tiếp, nhưng không hiển thị khi máy ảnh chỉ được truy cập bởi (các) ứng dụng nắm giữ các vai trò được gọi trong Phần 9.1 Quyền với CDD mã định danh [C-3-X].

    • [ 9.8.2 /A-2-2] KHÔNG ĐƯỢC ẩn chỉ báo máy ảnh đối với các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc tương tác trực tiếp với người dùng.

  • 2.6.1 Yêu cầu về máy tính bảng — Phần cứng : Cập nhật các yêu cầu về kích thước màn hình máy tính bảng.

    Xem bản sửa đổi

    Thiết bị Máy tính bảng Android đề cập đến việc triển khai thiết bị Android thường đáp ứng tất cả các tiêu chí sau:

    • Có kích thước hiển thị màn hình lớn hơn 7” và nhỏ hơn 18”, được đo theo đường chéo.

    Kích thước màn hình

    • [ 7.1 .1.1/Tab-0-1] PHẢI có màn hình trong khoảng từ 7 đến 18 inch.

3. Phần mềm

  • 3.2.2 Tham số bản dựng : Các ký tự ASCII được cập nhật trong getSerial() .

    Xem bản sửa đổi

    • [C-0-1] Để cung cấp các giá trị nhất quán, có ý nghĩa trong quá trình triển khai thiết bị, bảng bên dưới bao gồm các hạn chế bổ sung về định dạng của các giá trị này mà việc triển khai thiết bị PHẢI tuân theo.
    Tham số Thông tin chi tiết
    getSerial() PHẢI (là hoặc trả lại) một số sê-ri phần cứng, số này PHẢI có sẵn và duy nhất trên các thiết bị có cùng MẪU và NHÀ SẢN XUẤT. Giá trị của trường này PHẢI được mã hóa dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9]+$” .

  • 3.2.3.5 Mục đích ứng dụng có điều kiện : Cập nhật các yêu cầu đối với mục đích ứng dụng có điều kiện.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị bao gồm một màn hình lớn (thường có chiều rộng và chiều cao màn hình là 600dp+) và hỗ trợ chức năng phân chia , thì chúng:

  • 3.5.1 Hạn chế ứng dụng : Cập nhật các hạn chế ứng dụng.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị triển khai cơ chế độc quyền để hạn chế ứng dụng (ví dụ: thay đổi hoặc hạn chế hành vi API được mô tả trong SDK) và cơ chế đó hạn chế hơn Nhóm dự phòng ứng dụng bị hạn chế , thì chúng:

    • [C-1-1] PHẢI cho phép người dùng xem danh sách các ứng dụng bị hạn chế.
    • [C-1-2] PHẢI cung cấp cho người dùng đủ khả năng để bật/tắt tất cả các hạn chế về quyền sở hữu này trên mỗi ứng dụng.
    • [C-1-3] KHÔNG ĐƯỢC tự động áp dụng các hạn chế độc quyền này khi không có bằng chứng về tình trạng hoạt động kém của hệ thống, nhưng CÓ THỂ áp dụng các hạn chế đối với các ứng dụng khi phát hiện tình trạng hoạt động kém của hệ thống như khóa đánh thức bị kẹt, dịch vụ chạy lâu và các tiêu chí khác. Các tiêu chí CÓ THỂ được xác định bởi người triển khai thiết bị nhưng PHẢI liên quan đến tác động của ứng dụng đối với tình trạng hệ thống. Các tiêu chí khác không hoàn toàn liên quan đến tình trạng hệ thống, chẳng hạn như ứng dụng không phổ biến trên thị trường, KHÔNG ĐƯỢC sử dụng làm tiêu chí.
    • [C-1-4] KHÔNG ĐƯỢC tự động áp dụng các hạn chế độc quyền này cho ứng dụng khi người dùng đã tắt các hạn chế ứng dụng theo cách thủ công và CÓ THỂ đề xuất người dùng áp dụng các hạn chế độc quyền này.
    • [C-1-5] PHẢI thông báo cho người dùng nếu những hạn chế về quyền sở hữu này được tự động áp dụng cho một ứng dụng. Thông tin đó PHẢI được cung cấp trong khoảng thời gian 24 giờ trước khi áp dụng các hạn chế về quyền sở hữu này.

    • [C-1-6] PHẢI trả về giá trị true cho phương thức ActivityManager.isBackgroundRestricted() đối với bất kỳ lệnh gọi API nào từ một ứng dụng.

    • [C-1-7] KHÔNG ĐƯỢC hạn chế ứng dụng nền trước hàng đầu được người dùng sử dụng một cách rõ ràng.

    • [C-1-8] PHẢI tạm dừng các hạn chế độc quyền này đối với một ứng dụng bất cứ khi nào người dùng bắt đầu sử dụng ứng dụng một cách rõ ràng, biến nó thành ứng dụng nền trước hàng đầu.

    • [C-1-9] PHẢI báo cáo tất cả các sự kiện hạn chế quyền sở hữu này thông qua Sử dụngStats.

    • [C-1-10] PHẢI cung cấp tài liệu hoặc trang web công khai và rõ ràng mô tả cách áp dụng các hạn chế về quyền sở hữu. Tài liệu hoặc trang web này PHẢI có thể liên kết được từ tài liệu SDK Android và PHẢI bao gồm:

      • Kích hoạt điều kiện cho các hạn chế độc quyền.
      • Điều gì và làm thế nào một ứng dụng có thể bị hạn chế.
      • Làm thế nào một ứng dụng có thể được miễn trừ khỏi những hạn chế như vậy.
      • Cách một ứng dụng có thể yêu cầu miễn trừ hạn chế quyền sở hữu, nếu ứng dụng hỗ trợ miễn trừ như vậy đối với ứng dụng mà người dùng có thể cài đặt.

    Nếu một ứng dụng được cài đặt sẵn trên thiết bị và chưa bao giờ được người dùng sử dụng một cách rõ ràng trong hơn 30 ngày, [C-1-3] [C-1-5] sẽ được miễn trừ.

  • 3.8.1 Trình khởi chạy (Màn hình chính) : Các bản cập nhật để hỗ trợ cho monochrome/adaptive-icon .

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị hỗ trợ các biểu tượng đơn sắc , các biểu tượng sau:

    • [C-6-1] PHẢI được sử dụng chỉ khi người dùng bật chúng một cách rõ ràng (ví dụ: thông qua Cài đặt hoặc menu chọn hình nền).

  • 3.8.2 Tiện ích : Cập nhật sự hiện diện của tiện ích ứng dụng bên thứ ba trong Trình khởi chạy.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị hỗ trợ các tiện ích ứng dụng của bên thứ ba, chúng sẽ:

    • [C-1-2] PHẢI bao gồm hỗ trợ tích hợp cho AppWidgets và hiển thị khả năng chi trả của giao diện người dùng để thêm, định cấu hình, xem và xóa AppWidgets trực tiếp trong Trình khởi chạy.

  • 3.8.3.1 Trình bày thông báo : Làm rõ định nghĩa về thông báo cảnh báo.

    Xem bản sửa đổi

    Thông báo lưu ý là thông báo được hiển thị cho người dùng khi chúng xuất hiện độc lập với bề mặt mà người dùng đang truy cập.

  • 3.8.3.3 DND (Không làm phiền) / Chế độ ưu tiên : Cập nhật để bao gồm Chế độ ưu tiên trong các yêu cầu DND (Không làm phiền).

    Xem bản sửa đổi

    3.8.3.3. DND (Không làm phiền) / Chế độ ưu tiên

    Nếu việc triển khai thiết bị hỗ trợ tính năng DND (còn được gọi là Chế độ ưu tiên), chúng sẽ:

  • 3.8.6 Chủ đề : Yêu cầu mới đối với bảng màu động.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị bao gồm đầu ra màn hình hoặc video, chúng sẽ:

    • [C-1-4] PHẢI tạo các bảng tông màu động như được chỉ định trong tài liệu AOSP của Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (xem android.theme.customization.system_paletteandroid.theme.customization.theme_style ).

    • [C-1-5] PHẢI tạo các bảng tông màu động bằng cách sử dụng các kiểu chủ đề màu được liệt kê trong tài liệu Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (xem android.theme.customization.theme_styles ), cụ thể là TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD .

      "Màu nguồn" được sử dụng để tạo các bảng tông màu động khi được gửi bằng android.theme.customization.system_palette (như được ghi trong Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

    • [C-1-6] PHẢI có giá trị sắc độ CAM16 từ 5 trở lên.

      • NÊN lấy từ hình nền qua com.android.systemui.monet.ColorScheme#getSeedColors , cung cấp nhiều màu nguồn hợp lệ để chọn một màu.

      • NÊN sử dụng giá trị 0xFF1B6EF3 , nếu không có màu nào được cung cấp đáp ứng yêu cầu về màu nguồn ở trên.

  • 3.8.17 Clipboard : Đã thêm phần yêu cầu mới cho nội dung trên clipboard.

    Xem bản sửa đổi

    3.8.17. bảng tạm

    Triển khai thiết bị:

    • [C-0-1] KHÔNG ĐƯỢC gửi dữ liệu khay nhớ tạm đến bất kỳ thành phần, hoạt động, dịch vụ nào hoặc qua bất kỳ kết nối mạng nào mà không có hành động rõ ràng của người dùng (ví dụ: nhấn nút trên lớp phủ), ngoại trừ các dịch vụ được đề cập trong 9.8.6 Nội dung Chụp và tìm kiếm ứng dụng .

    Nếu việc triển khai thiết bị tạo bản xem trước mà người dùng có thể nhìn thấy khi nội dung được sao chép vào khay nhớ tạm cho bất kỳ mục ClipData nào trong đó ClipData.getDescription().getExtras() chứa android.content.extra.IS_SENSITIVE , thì chúng:

    • [C-1-1] PHẢI biên tập lại bản xem trước hiển thị của người dùng

    Việc triển khai tham chiếu AOSP đáp ứng các yêu cầu về khay nhớ tạm này.

  • 3.9.1.1 Cấp phép của chủ sở hữu thiết bị : Cập nhật các yêu cầu cấp phép của chủ sở hữu thiết bị.

    Xem bản sửa đổi

    Nếu việc triển khai thiết bị khai báo android.software.device_admin , thì chúng:

    • [C-1-1] PHẢI hỗ trợ đăng ký Máy khách chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị như được mô tả bên dưới:
      • Khi việc triển khai thiết bị không có người dùng cũng như dữ liệu người dùng được định cấu hình, nó sẽ:
        • [C-1-5] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị hoặc bật ứng dụng DPC để chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, nếu thiết bị tuyên bố hỗ trợ Giao tiếp trường gần (NFC) thông qua tính năng gắn cờ android.hardware.nfc và nhận được thông báo NFC chứa bản ghi có loại MIME MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] PHẢI gửi mục đích ACTION_GET_PROVISIONING_MODE sau khi cấp phép chủ sở hữu thiết bị được kích hoạt để ứng dụng DPC có thể chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, tùy thuộc vào giá trị của android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , trừ khi it can be determined from context that there is only one valid option. (such as for NFC based provisioning where Profile Owner provisioning is not supported).
        • [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
      • When the device implementation has users or user data, it:
        • [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
    • [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction. require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use.
    • [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

    If device implementations declare android.software.device_admin , but also include a proprietary Device Owner device management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

    • [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
    • [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by android.app.action.PROVISION_MANAGED_DEVICE prior to enrolling the DPC application as "Device Owner".
    • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
    • MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

  • 3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.

    See revision

    3.9.4 Device Policy Management Role Requirements

    If device implementations report android.software.device_admin or android.software.managed_users , then they:

    • [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting config_devicePolicyManagement to the package name. The package name MUST be followed by : and the signing certificate unless the application is preloaded.

    If a package name is not defined for config_devicePolicyManagement as described above:

    If a package name is defined for config_devicePolicyManagement as described above:

    • [C-3-1] The application MUST be installed on all profiles for a user .
    • [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting config_devicePolicyManagementUpdater .

    If a package name is defined for config_devicePolicyManagementUpdater as described above:

    • [C-4-1] The application MUST be preinstalled on the device.
    • [C-4-2] The application MUST implement an intent filter which resolves android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

  • 3.18 Contacts : Adding information for new contacts.

    See revision

    Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.

    If device implementations preload a contacts app, then the pre-loaded contacts app:

    • [C-2-1] MUST handle the intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.

    • [C-2-2] MUST honor the default account setting when handling Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT for the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

5. Multimedia Compatibility

  • 5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.

    See revision

    If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the android.media.MediaCodec API, then the following MUST be supported:

    • [C-7-1] MUST be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

    If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:

    • [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.

    See revision

    If device implementations declare android.hardware.microphone , they:

  • 5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.

    See revision

    If device implementations declare android.hardware.microphone , they:

    • SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
    • SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.

    See revision

    5.4.6. Microphone Gain Levels [Moved to 5.4.2]

    If device implementations declare android.hardware.microphone , they:

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

    See revision

    If device implementations support audio offload playback , they:

    • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.

  • 5.6 Audio Latency : Updates to the audio latency requirements.

    See revision

    For the purposes of this section, use the following definitions:

    • cold output jitter . The variability among separate measurements of cold output latency values.
    • cold input jitter . The variability among separate measurements of cold input latency values.

    If device implementations declare android.hardware.audio.output , they MUST meet or exceed the following requirements:

    • [C-1-2] Cold output latency of 500 milliseconds or less.
    • [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

      Device implementations:

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

    If device implementations include a screen or video output, they:

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

    Device implementations:

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

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

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

    Device implementations:

    • 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

    Device implementations:

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

    It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .

    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.

    It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .

  • 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. Device implementations:

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

    Device implementations:

    • [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. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.

  • 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. Device implementations:

    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