Android 14
Ngày 8 tháng 4 năm 2024
2. Loại thiết bị
Xem bản sửa đổi
Bắt đầu yêu cầu mới
Nếu việc triển khai thiết bị cầm tay khai báo
FEATURE_BLUETOOTH_LEthì chúng:- [ 7.4 .3/H-1-3] PHẢI đo và bù độ lệch Rx để đảm bảo BLE RSSI trung bình là -50dBm +/-15 dB ở khoảng cách 1m tính từ thiết bị tham chiếu đang truyền ở
ADVERTISE_TX_POWER_HIGH. - [ 7.4 .3/H-1-4] PHẢI đo và bù độ lệch Tx để đảm bảo BLE RSSI trung bình là -50dBm +/-15 dB khi quét từ thiết bị tham chiếu được đặt ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH.
- [ 7.4 .3/H-1-3] PHẢI đo và bù độ lệch Rx để đảm bảo BLE RSSI trung bình là -50dBm +/-15 dB ở khoảng cách 1m tính từ thiết bị tham chiếu đang truyền ở
Xem bản sửa đổi
Nếu việc triển khai thiết bị cầm tay hỗ trợ API hệ thống
HotwordDetectionServicehoặc cơ chế khác để phát hiện từ nóng mà không có chỉ báo truy cập micrô, thì chúng:- [9.8/H-1-6] KHÔNG ĐƯỢC cho phép truyền hơn 100 byte dữ liệu ra khỏi dịch vụ phát hiện từ nóng trên mỗi kết quả từ nóng thành công ngoại trừ dữ liệu âm thanh được truyền qua HotwordAudioStream .
Xem bản sửa đổi
Thay đổi [9.8/H-1-13] thành:
- [9.8/H-SR-3] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ khởi động lại quá trình lưu trữ dịch vụ phát hiện từ nóng ít nhất một lần mỗi giờ hoặc mỗi 30 sự kiện kích hoạt phần cứng, tùy điều kiện nào đến trước.
Xem bản sửa đổi
Đã xóa các yêu cầu [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
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.Uchoandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASSthì chúng:- [ 7.5 /H-1-3] PHẢI hỗ trợ thuộc tính
android.info.supportedHardwareLevelở mứcFULLhoặc cao hơn cho camera chính phía sau vàLIMITEDtrở lên cho camera chính phía trước.
- [ 7.5 /H-1-3] PHẢI hỗ trợ thuộc tính
Xem bản sửa đổi
Nếu việc triển khai thiết bị Tivi không có màn hình tích hợp mà thay vào đó hỗ trợ màn hình ngoài được kết nối qua HDMI, chúng sẽ:
- [ 5.8 /T-0-1] PHẢI đặt chế độ đầu ra HDMI ở độ phân giải cao nhất cho định dạng pixel đã chọn hoạt động với tốc độ làm mới 50Hz hoặc 60Hz cho màn hình ngoài, tùy thuộc vào tốc độ làm mới video cho khu vực bán thiết bị PHẢI
đặt chế độ đầu ra HDMI để chọn độ phân giải tối đa có thể được hỗ trợ với tốc độ làm mới 50Hz hoặc 60Hz.
- [ 5.8 /T-0-1] PHẢI đặt chế độ đầu ra HDMI ở độ phân giải cao nhất cho định dạng pixel đã chọn hoạt động với tốc độ làm mới 50Hz hoặc 60Hz cho màn hình ngoài, tùy thuộc vào tốc độ làm mới video cho khu vực bán thiết bị PHẢI
3. Phần mềm
Xem bản sửa đổi
- Đã xóa yêu cầu [C-1-9]
5. Khả năng tương thích đa phương tiện
Xem bản sửa đổi
Nếu việc triển khai thiết bị tuyên bố hỗ trợ bộ giải mã Dolby Vision thông qua
HDR_TYPE_DOLBY_VISIONthì chúng:- [C-1-3] PHẢI đặt ID rãnh ghi của (các) lớp cơ sở tương thích ngược (nếu có) giống với ID rãnh ghi của lớp Dolby Vision kết hợp.
7. Khả năng tương thích phần cứng
7.1.1.1. Kích thước và hình dạng màn hình :
Xem bản sửa đổi
Nếu việc triển khai thiết bị hỗ trợ màn hình có khả năng cấu hình kích thước
UI_MODE_TYPE_NORMALvà sử dụng (các) màn hình vật lý có góc tròn để hiển thị các màn hình này thì chúng:- [C-1-1] PHẢI đảm bảo đáp ứng ít nhất một trong các yêu cầu sau cho mỗi màn hình như vậy:
- Khi
một hộp 15và 18 dp x1518 dp được cố định ở mỗi góc của màn hình logic, ít nhất một pixel của mỗi hộp sẽ hiển thị trên màn hình.
- Khi
- [C-1-1] PHẢI đảm bảo đáp ứng ít nhất một trong các yêu cầu sau cho mỗi màn hình như vậy:
Xem bản sửa đổi
Khôi phục các yêu cầu sau:
Nếu việc triển khai thiết bị khai báo
FEATURE_BLUETOOTH_LEthì chúng:[C-SR-2] ĐƯỢC KHUYẾN NGHỊ MẠNH để đo và bù cho độ lệch Rx để đảm bảo BLE RSSI trung bình là -60dBm +/- 10 dB ở khoảng cách 1m tính từ thiết bị tham chiếu truyền ở
ADVERTISE_TX_POWER_HIGH, trong đó các thiết bị được định hướng sao cho chúng nằm trên 'các mặt phẳng song song' với các màn hình hướng về cùng một hướng.[C-SR-3] ĐƯỢC KHUYẾN NGHỊ MẠNH để đo và bù cho độ lệch Tx để đảm bảo BLE RSSI trung bình là -60dBm +/- 10 dB khi quét từ thiết bị tham chiếu được đặt ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH, trong đó các thiết bị được định hướng sao cho chúng nằm trên 'các mặt phẳng song song' với các màn hình hướng về cùng một hướng.
Xem bản sửa đổi
Đã chuyển các yêu cầu [C-10-3] và [C-10-4] sang 2.2.1. Phần cứng .
- [C-10-3] PHẢI đo và bù độ lệch Rx để đảm bảo BLE RSSI trung bình là -55dBm +/- 10 dB ở khoảng cách 1m tính từ thiết bị tham chiếu đang truyền ở
ADVERTISE_TX_POWER_HIGH. - [C-10-4] PHẢI đo và bù cho độ lệch Tx để đảm bảo BLE RSSI trung bình là -55dBm +/- 10 dB khi quét từ thiết bị tham chiếu được đặt ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH.
Ngày 20 tháng 11 năm 2023
2. Loại thiết bị
Xem bản sửa đổi
Nếu việc triển khai thiết bị cầm tay tuyên bố hỗ trợ bất kỳ ABI 64 bit nào (có hoặc không có bất kỳ ABI 32 bit nào):
Xem bản sửa đổi
- [ 7.5 /H-1-13] PHẢI hỗ trợ khả năng
LOGICAL_MULTI_CAMERAcho camera chính phía sau nếu có nhiều hơn 1 camera phía sau RGB.
- [ 7.5 /H-1-13] PHẢI hỗ trợ khả năng
Xem bản sửa đổi
[ 5.8 /T-0-1] PHẢI đặt chế độ đầu ra HDMI ở độ phân giải cao nhất cho định dạng SDR hoặc HDR đã chọn hoạt động với tốc độ làm mới 50Hz hoặc 60Hz cho màn hình ngoài.
PHẢI đặt chế độ đầu ra HDMI để chọn độ phân giải tối đa có thể được hỗ trợ với tốc độ làm mới 50Hz hoặc 60Hz.
Xem bản sửa đổi
- [9/W-0-1] PHẢI khai báo
android.hardware.security.model.compatible feature.
- [9/W-0-1] PHẢI khai báo
6. Khả năng tương thích của các công cụ và tùy chọn dành cho nhà phát triển
6.1. Những công cụ phát triển :
Xem bản sửa đổi
- [C-0-12] PHẢI ghi nguyên tử
LMK_KILL_OCCURRED_FIELD_NUMBERvào
Xem bản sửa đổi
- [C-0-13] PHẢI triển khai lệnh shell
dumpsys gpu --gpuworkđể hiển thị
- [C-0-12] PHẢI ghi nguyên tử
9. Khả năng tương thích của mô hình bảo mật
Xem bản sửa đổi
Nếu việc triển khai thiết bị sử dụng nhân Linux có khả năng hỗ trợ SELinux thì chúng:
Xem bản sửa đổi
Nếu việc triển khai thiết bị sử dụng kernel không phải Linux hoặc Linux không có SELinux, thì chúng:
Ngày 4 tháng 10 năm 2023
2. Loại thiết bị
Xem bản sửa đổi
Việc triển khai thiết bị Android được phân loại là Thiết bị cầm tay nếu chúng đáp ứng tất cả các tiêu chí sau:
- Có kích thước màn hình đường chéo vật lý trong khoảng từ 4 inch
3,3 inch (hoặc 2,5 inch đối với việc triển khai thiết bị được cung cấp trên API cấp 29 trở về trước)đến 8 inch.
Bắt đầu yêu cầu mới
- Có giao diện nhập liệu màn hình cảm ứng.
- Có kích thước màn hình đường chéo vật lý trong khoảng từ 4 inch
Xem bản sửa đổi
Triển khai thiết bị cầm tay:
- [ 7.1 .1.1/H-0-1] PHẢI có ít nhất một
màn hình tương thích với Android đáp ứng tất cả các yêu cầu được mô tả trong tài liệu này.màn hình có kích thước tối thiểu là 2,2” ở cạnh ngắn và 3,4” ở cạnh dài.
Nếu việc triển khai thiết bị cầm tay hỗ trợ xoay màn hình phần mềm thì chúng:
- [ 7.1 .1.1/H-1-1]* PHẢI cung cấp màn hình logic dành cho các ứng dụng của bên thứ ba có kích thước tối thiểu là 2 inch trên (các) cạnh ngắn và 2,7 inch trên (các) cạnh dài. Các thiết bị chạy trên API Android cấp 29 trở xuống CÓ THỂ được miễn yêu cầu này.
Nếu việc triển khai thiết bị cầm tay không hỗ trợ xoay màn hình phần mềm thì chúng:
- [ 7.1 .1.1/H-2-1]* PHẢI cung cấp màn hình logic dành cho các ứng dụng của bên thứ ba có kích thước tối thiểu là 2,7 inch trên (các) cạnh ngắn. Các thiết bị chạy trên API Android cấp 29 trở xuống CÓ THỂ được miễn yêu cầu này.
Bắt đầu yêu cầu mới
[ 7.1 .1.1/H-0-3]* PHẢI ánh xạ từng màn hình
UI_MODE_NORMALđược cung cấp cho các ứng dụng của bên thứ ba lên một khu vực hiển thị vật lý không bị cản trở có kích thước ít nhất là 2,2 inch ở cạnh ngắn và 3,4 inch ở cạnh dài.[ 7.1 .1.3/H-0-1]* PHẢI đặt giá trị của
DENSITY_DEVICE_STABLElà 92% hoặc lớn hơn mật độ vật lý thực tế của màn hình tương ứng.
Nếu việc triển khai thiết bị cầm tay khai báo
android.hardware.audio.outputvàandroid.hardware.microphone, thì chúng:[ 5.6 /H-1-1] PHẢI có Độ trễ khứ hồi trung bình liên tục là 300 mili giây hoặc ít hơn trong 5 phép đo, với Độ lệch tuyệt đối trung bình nhỏ hơn 30 mili giây , trên các đường dẫn dữ liệu sau: "loa đến micrô", 3,5 mm bộ điều hợp loopback (nếu được hỗ trợ), loopback USB (nếu được hỗ trợ).
[ 5.6 /H-1-2] PHẢI có độ trễ Nhấn để âm trung bình là 300 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ô.
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 xúc giác thì chúng:
- [ 7.10 /H]* KHÔNG NÊN sử dụng bộ truyền động xúc giác (bộ rung) khối lượng quay lệch tâm (ERM).
- [ 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, CONFIRM, REJECT, GESTURE_START và GESTURE_END).
- [ 7.10 /H]* NÊN triển khai tất cả các hằng số công khai cho xúc giác 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 xúc giác phong phú trong android.os.VibrationEffect.Composition cụ thể là ( CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Một số nguyên thủy này, chẳng hạn như LOW_TICK và SPIN chỉ có thể khả thi nếu bộ rung có thể hỗ trợ tần số tương đối thấp. - [7.10/H]* NÊN làm theo hướng dẫn để ánh xạ các hằng số công khai trong android.view.HapticFeedbackConstants với các hằng số android.os.VibrationEffect được đề xuất, với các mối quan hệ biên độ tương ứng.
- [ 7.10 /H]* NÊN tuân theo đánh giá chất lượng đối với API createOneShot() và createWaveform() .
- [ 7.10 /H]* NÊN xác minh rằng kết quả của API android.os.Vibrator.hasAmplitudeControl() công khai phản ánh chính xác khả năng của bộ rung.
- [ 7.10 /H]* NÊN đặt vị trí của bộ truyền động gần vị trí mà thiết bị thường được cầm hoặc chạm vào bằng tay.
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 7.10 cho mục đích chung thì chúng:
- [ 7.10 /H] NÊN đặt vị trí của bộ truyền động gần vị trí mà thiết bị thường được cầm hoặc chạm vào bằng tay.
- [ 7.10 /H] NÊN di chuyển bộ truyền động xúc giác theo trục X (trái-phải) theo hướng
dọctự nhiên của thiết bị .
Nếu việc triển khai thiết bị cầm tay có bộ truyền động xúc giác cho mục đích chung là bộ truyền động cộng hưởng tuyến tính trục X (LRA), thì chúng:
- [ 7.10 /H] NÊN có tần số cộng hưởng của LRA trục X dưới 200 Hz.
- [ 7.1 .1.1/H-0-1] PHẢI có ít nhất một
Xem bản sửa đổi
Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng mã hóa video sau và cung cấp chúng cho các ứng dụng của bên thứ ba:
- [ 5.2 /H-0-3] AV1
Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng giải mã video sau và cung cấp chúng cho các ứng dụng của bên thứ ba:
- [ 5.3 /H-0-6] AV1
Xem bản sửa đổi
Nếu việc triển khai thiết bị bao gồm phím điều hướng chức năng gần đây như được nêu chi tiết trong phần 7.2.3 làm thay đổi giao diện, chúng sẽ:
- [ 3.8 .3/H-1-1] PHẢI triển khai hành vi ghim màn hình và cung cấp cho người dùng menu cài đặt để chuyển đổi tính năng này.
Nếu việc triển khai thiết bị cầm tay bao gồm hỗ trợ cho
ControlsProviderServicevà APIControl, đồng thời cho phép các ứng dụng của bên thứ ba xuất bản các điều khiển thiết bị thì chúng:- [ 3.8 .16/H-1-6] Việc triển khai thiết bị PHẢI hiển thị chính xác khả năng chi trả của người dùng như sau:
- Nếu thiết bị đã đặt
config_supportsMultiWindow=truevà ứng dụng khai báo siêu dữ liệuMETA_DATA_PANEL_ACTIVITYtrong phần khai báoControlsProviderService, bao gồm cả ComponentName của một hoạt động hợp lệ (như được xác định bởi API), thì ứng dụng PHẢI nhúng hoạt động nói trên vào khả năng chi trả của người dùng này. - Nếu ứng dụng không khai báo siêu dữ liệu
META_DATA_PANEL_ACTIVITYthì ứng dụng PHẢI hiển thị các trường được chỉ định do APIControlsProviderServicecung cấp cũng như mọi trường được chỉ định do API kiểm soát cung cấp.
- Nếu thiết bị đã đặt
- [ 3.8 .16/H-1-7] Nếu ứng dụng khai báo siêu dữ liệu
META_DATA_PANEL_ACTIVITYthì ứng dụng PHẢI chuyển giá trị của cài đặt được xác định trong [3.8.16/H-1-5] bằng cách sử dụngEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSkhi khởi chạy hoạt động được nhúng.
Nếu việc triển khai thiết bị cho phép người dùng thực hiện bất kỳ loại cuộc gọi nào, họ
- [ 7.4.1.2 /H-0-1] PHẢI khai báo cờ tính năng
android.software.telecom. - [ 7.4.1.2 /H-0-2] PHẢI triển khai khuôn khổ viễn thông .
2.2.4. Hiệu suất và sức mạ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 khả năng chi trả của người dùng
trong menu Cài đặtđể xem tất cả các ứng dụng có dịch vụ trên nền trước đang hoạt động hoặc công việc do người dùng bắt đầu, bao gồm cả thời lượng của từng dịch vụ này kể từ khi dịch vụ này bắt đầu như được mô tả trong tài liệu SDK .và khả năng dừng ứng dụng đang chạy dịch vụ trên nền trước hoặc công việc do người dùng thực hiện.với khả năng dừng ứng dụng đang chạy dịch vụ trên nền trước và hiển thị tất cả các ứng dụng có dịch vụ trên nền trước đang hoạt động cũng như thời lượng của từng dịch vụ này kể từ khi dịch vụ bắt đầu như được mô tả trong tài liệu SDK .- Một số ứng dụng CÓ THỂ được miễn 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 .
- [ 8.5 /H-0-1] PHẢI cung cấp khả năng chi trả của người dùng
- [ 8.5 /H-0-2]PHẢI cung cấp khả năng chi trả của người dùng để dừng ứng dụng đang chạy dịch vụ trên nền trước hoặc công việc do người dùng bắt đầu.
Xem bản sửa đổi
Nếu việc triển khai thiết bị tuyên bố hỗ trợ cho android.hardware.telephony thì chúng:
- [ 9.5 /H-1-1] KHÔNG PHẢI đặt
UserManager.isHeadlessSystemUserModethànhtrue.
Nếu việc triển khai thiết bị có màn hình khóa an toàn và bao gồm một hoặc nhiều tác nhân tin cậy triển khai API hệ thống TrustAgentService , thì chúng:
- [ 9.11.1 /H-1-1] PHẢI thách thức người dùng sử dụng một trong các phương thức xác thực chính được đề xuất (ví dụ: mã PIN, mẫu, mật khẩu) thường xuyên hơn 72 giờ một lần.
Nếu việc triển khai thiết bị cầm tay đặt UserManager.isHeadlessSystemUserMode thành true , thì chúng
Nếu việc triển khai thiết bị cầm tay hỗ trợ System API HotwordDetectionService hoặc một cơ chế khác để phát hiện từ nóng mà không có chỉ báo truy cập micrô, thì chúng:
- [9.8/H-1-1] PHẢI đảm bảo rằng dịch vụ phát hiện từ nóng chỉ có thể truyền dữ liệu tới Hệ thống,
ContentCaptureServicehoặc dịch vụ nhận dạng giọng nói trên thiết bị được tạo bởiSpeechRecognizer#createOnDeviceSpeechRecognizer(). - [9.8/H-1-6] KHÔNG ĐƯỢC cho phép truyền hơn 100 byte dữ liệu (không bao gồm luồng âm thanh) ra khỏi dịch vụ phát hiện từ nóng trên mỗi kết quả từ nóng thành công.
- [9.8/H-1-15] PHẢI đảm bảo rằng các luồng âm thanh được cung cấp trên các kết quả từ nóng thành công được truyền một chiều từ dịch vụ phát hiện từ nóng đến dịch vụ tương tác bằng giọng nói.
Nếu việc triển khai thiết bị bao gồm một ứng dụng sử dụng System API HotwordDetectionService hoặc cơ chế tương tự để phát hiện từ nóng mà không có chỉ báo sử dụng micrô thì ứng dụng đó:
- [9.8/H-2-3] KHÔNG PHẢI truyền từ dịch vụ phát hiện từ nóng, dữ liệu âm thanh, dữ liệu có thể được sử dụng để tái tạo lại (toàn bộ hoặc một phần) âm thanh hoặc nội dung âm thanh không liên quan đến chính từ nóng đó, ngoại trừ
ContentCaptureServicehoặc dịch vụ nhận dạng giọng nói trên thiết bị.
Nếu việc triển khai thiết bị cầm tay hỗ trợ API hệ thống VisualQueryDetectionService hoặc cơ chế khác để phát hiện truy vấn mà không có chỉ báo truy cập micrô và/hoặc máy ảnh, thì chúng:
- [9.8/H-3-1] PHẢI đảm bảo rằng dịch vụ phát hiện truy vấn chỉ có thể truyền dữ liệu tới Hệ thống hoặc
ContentCaptureServicehoặc dịch vụ nhận dạng giọng nói trên thiết bị (được tạo bởiSpeechRecognizer#createOnDeviceSpeechRecognizer()). - [9.8/H-3-2] KHÔNG ĐƯỢC cho phép bất kỳ thông tin âm thanh hoặc video nào được truyền ra khỏi
VisualQueryDetectionService, ngoại trừContentCaptureServicehoặc dịch vụ nhận dạng giọng nói trên thiết bị. - [9.8/H-3-3] PHẢI hiển thị thông báo người dùng trong Giao diện người dùng hệ thống khi thiết bị phát hiện ý định tương tác của người dùng với Ứng dụng Trợ lý Kỹ thuật số (ví dụ: bằng cách phát hiện sự hiện diện của người dùng qua camera).
- [9.8/H-3-4] PHẢI hiển thị chỉ báo micrô và hiển thị truy vấn người dùng được phát hiện trong giao diện người dùng ngay sau khi phát hiện truy vấn của người dùng.
- [9.8/H-3-5] KHÔNG PHẢI cho phép ứng dụng do người dùng cài đặt cung cấp dịch vụ phát hiện truy vấn trực quan.
2.2.7.1. Phương tiện truyền thô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:
- PHẢI đáp ứng các yêu cầu về phương tiện được liệt kê trong Android 13 CDD phần 2.2.7.1 .
Bắt đầu yêu cầu mới
Nếu việc triển khai thiết bị cầm tay trả vềandroid.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS thì chúng:- [5.1/H-1-1] PHẢI quảng cáo số lượng phiên giải mã video phần cứng tối đa có thể chạy đồng thời trong bất kỳ kết hợp codec nào thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()và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 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong mọi kết hợp codec chạy đồng thời với 3 phiên ở độ phân giải 1080p@30 khung hình/giây và 3 phiên ở độ phân giải 4k@30fps, trừ khi AV1. Codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p nhưng vẫn phải hỗ trợ 6 phiên bản ở 1080p30fps.
- [5.1/H-1-3] PHẢI quảng cáo số 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ỳ kết hợp codec nào thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()vàVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-4] PHẢI hỗ trợ 6 phiên bản phiên mã hóa video phần cứng 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong mọi kết hợp codec chạy đồng thời với 4 phiên ở độ phân giải 1080p@30 khung hình/giây và 2 phiên ở độ phân giải 4k@30fps, trừ khi AV1. Codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p nhưng vẫn phải hỗ trợ 6 phiên bản ở 1080p30fps.
- [5.1/H-1-5] PHẢI quảng cáo số lượng phiên mã hóa và giải mã video phần cứng tối đa có thể chạy đồng thời trong mọi kết hợp codec thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()vàVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-6] PHẢI hỗ trợ 6 phiên bản bộ giải mã video phần cứng 8 bit (SDR) và phiên mã hóa video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong mọi kết hợp codec chạy đồng thời với 3 phiên ở 4K Độ phân giải @30fps (trừ AV1), trong đó tối đa 2 phiên là phiên mã hóa và 3 phiên ở độ phân giải 1080p. Codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p nhưng vẫn phải hỗ trợ 6 phiên bản ở 1080p30fps.
- [5.1/H-1-19] PHẢI hỗ trợ 3 phiên bản bộ giải mã video phần cứng 10 bit (HDR) và phiên mã hóa video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong mọi kết hợp codec chạy đồng thời ở độ phân giải 4K@30fps (trừ AV1), trong đó tối đa 1 phiên là phiên mã hóa, có thể được định cấu hình ở định dạng đầu vào RGBA_1010102 thông qua bề mặt GL. Không cần phải tạo siêu dữ liệu HDR bằng bộ mã hóa nếu mã hóa từ bề mặt GL. Phiên codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này yêu cầu 4K.
- [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 hoặc nhỏ hơn đối với 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. Đối với codec tầm nhìn Dolby, độ trễ khởi tạo codec PHẢI là 50 mili giây trở xuống.
- [5.1/H-1-8] PHẢI có độ trễ khởi tạo codec từ 30 mili giây trở xuống cho phiên mã hóa âm thanh tốc độ bit 128 kbps hoặc thấp hơn 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 mọi kết hợp codec chạy đồng thời ở độ phân giải 4k@30 khung hình/giây (trừ AV1) cho cả 8- bit (SDR) và nội dung HDR 10 bit. Phiên codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này yêu cầu 4K.
- [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 phiên giải mã video phần cứng an toàn (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 với 3 phiên ở độ phân giải 4K@30 khung hình/giây (trừ AV1), bao gồm một phiên giải mã an toàn và 1 phiên an toàn nn ở độ phân giải 1080p@30 khung hình/giây trong đó tối đa 2 phiên có thể ở chế độ HDR 10 bit. Phiên codec AV1 chỉ được yêu cầu để hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này yêu cầu 4K.
- [5.1/H-1-11] PHẢI hỗ trợ bộ giải mã an toàn cho mọi bộ giải mã AVC, HEVC, VP9 hoặc AV1 phần cứng trên thiết bị.
- [5.1/H-1-12] PHẢI có độ trễ khởi tạo codec từ 40 ms trở xuống đối với phiên giải mã video 1080p hoặc nhỏ hơn đối với tất cả các bộ giải mã 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 khởi tạo phát lại âm thanh-video 1080p. Đối với codec tầm nhìn Dolby, độ trễ khởi tạo codec PHẢI là 50 mili giây trở xuống.
- [5.1/H-1-13] PHẢI có độ trễ khởi tạo codec từ 30 mili giây trở xuống đối với phiên giải mã âm thanh tốc độ bit 128 kbps hoặc thấp hơn đối với tất cả các bộ giải mã â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 khởi tạo phát lại âm thanh-video 1080p.
- [5.1/H-1-14] PHẢI hỗ trợ bộ giải mã phần cứng AV1 Main 10, Cấp 4.1 và hạt phim.
- [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 bỏ 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) cho phiên video 4K 60 khung hình/giây khi đang tải.
- [5.3/H-1-2] KHÔNG ĐƯỢC bỏ quá 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 đối với phiên 4K.
- [5.6/H-1-1] PHẢI có độ trễ nhấn-to-tone từ 80 mili giây trở xuống bằng cách sử dụng thử nghiệm nhấn-to-tone của Trình xác minh CTS.
- [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 âm thanh 3,5 mm nếu có và qua âm thanh USB nếu được hỗ trợ thông 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, phần chìm đầu ra HAL phải chấp nhận
AUDIO_FORMAT_PCM_24_BIT,AUDIO_FORMAT_PCM_24_BIT_PACKED,AUDIO_FORMAT_PCM_32_BIThoặcAUDIO_FORMAT_PCM_FLOATcho định dạng đầu ra mục tiêu của nó. - [5.6/H-1-4] PHẢI hỗ trợ >=4 kênh thiết bị âm thanh USB (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 tuân thủ lớp và khai báo cờ tính năng MIDI.
- [5.6/H-1-9] PHẢI hỗ trợ trộn ít nhất 12 kênh. Điều này ngụ ý khả năng mở AudioTrack với mặt nạ kênh 7.1.4 và sắp xếp không gian hoặc trộn tất cả các kênh thành âm thanh nổi một cách chính xác.
- [5.6/H-SR] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để hỗ trợ trộn 24 kênh với ít nhất hỗ trợ cho mặt nạ kênh 9.1.6 và 22.2.
- [5.7/H-1-2] PHẢI hỗ trợ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALLvớ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 con 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 phụ tối thiểu | 1 MiB |
| Kích thước bộ đệm mật mã 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ố 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ã mỗi giây | 60 khung hình/giây |
- [5.1/H-1-17] PHẢI có ít nhất 1 bộ giải mã hình ảnh phần cứng hỗ trợ Cấu hình cơ sở AVIF.
- [5.1/H-1-18] PHẢI hỗ trợ bộ mã hóa AV1 có thể mã hóa độ phân giải lên tới 480p ở tốc độ 30 khung hình/giây và 1Mbps.
-
[5.12/H-1-1] PHẢI[5.12/H-SR] Được khuyến nghị mạnh mẽ để hỗ trợ tính năngFeature_HdrEditingcho tất cả các bộ mã hóa AV1 và HEVC phần cứng có trên thiết bị. - [5.12/H-1-2] PHẢI hỗ trợ định dạng màu RGBA_1010102 cho tất cả các bộ mã hóa AV1 và HEVC phần cứng có trên thiết bị.
- [5.12/H-1-3] PHẢI quảng cáo hỗ trợ cho tiện ích mở rộng EXT_YUV_target để lấy mẫu từ kết cấu YUV ở cả 8 và 10 bit.
- [7.1.4/H-1-1] PHẢI có ít nhất 6 lớp phủ phần cứng trong Bộ soạn thảo phần cứng (HWC) của Bộ xử lý dữ liệu (DPU), trong đó ít nhất 2 lớp trong số đó có khả năng hiển thị nội dung video 10 bit.
Nếu việc triển khai thiết bị cầm tay trả về android.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS và chúng bao gồm hỗ trợ cho bộ mã hóa AVC hoặc HEVC phần cứng thì chúng:
- [5.2/H-2-1] PHẢI đáp ứng mục tiêu chất lượng tối thiểu được xác định bởi đường cong biến dạng tốc độ của bộ mã hóa video đối với các codec AVC và HEVC phần cứng, như được xác định trong tài liệu sắp tới.
Xem bản sửa đổi
android.os.Build.VERSION_CODES.U 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 có độ phân giải ít nhất 12 megapixel hỗ trợ quay video ở tốc độ 4k@30fps. Camera phía sau chính là camera phía sau có ID camera thấp nhất.
- [ 7.5 /H-1-2] PHẢI có camera chính mặt trước có độ phân giải ít nhất 6 megapixel và hỗ trợ quay video ở tốc độ 1080p@30fps. Camera mặt trước chính là camera mặt trước có ID camera thấp nhất.
- [ 7.5 /H-1-3] PHẢI hỗ trợ thuộc tính
android.info.supportedHardwareLevelở mức ĐẦY ĐỦ hoặc cao hơn cho cả hai camera chính. - [ 7.5 /H-1-4] PHẢI hỗ trợ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEcho cả hai camera chính. - [ 7.5 /H-1-5] PHẢI có độ trễ chụp ảnh JPEG của camera2 < 1000
900ms đối với độ phân giải 1080p được đo bằng Kiểm tra hiệu suất của camera CTS trong điều kiện ánh sáng ITS (3000K) cho cả hai camera chính. - [ 7.5 /H-1-6] PHẢI có độ trễ khởi động camera2 (mở camera tới khung hình xem trước đầu tiên) < 500 mili giây được đo bằng Kiểm tra hiệu suất của 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_RAWvàandroid.graphics.ImageFormat.RAW_SENSORcho 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 camera chính nếu có camera RGB siêu rộng quay về cùng một hướng.
- [ 7.5 /H-1-11] PHẢI triển khai tính năng phát trực tiếp từ trước ra sau đồng thời trên camera chính.
- [ 7.5 /H-1-12] PHẢI hỗ trợ
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONcho cả camera chính phía trước và phía sau chính. - [ 7.5 /H-1-13] PHẢI hỗ trợ khả năng
LOGICAL_MULTI_CAMERAcho 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_CASEcho cả camera chính phía trước và phía sau chính. - [ 7.5 /H-1-15] PHẢI hỗ trợ các tiện ích mở rộng Chế độ
ban đêm và Bo mạchthông qua cả tiện ích mở rộng CameraX và Camera2 cho máy ảnh chính. - [ 7.5 /H-1-16] PHẢI hỗ trợ khả năng DYNAMIC_RANGE_TEN_BIT cho camera chính.
- [ 7.5 /H-1-17] PHẢI hỗ trợ Control_SCENE_MODE_FACE_PRIORITY và nhận diện khuôn mặt ( STATISTICS_FACE_DETECT_MODE_SIMPLE hoặc STATISTICS_FACE_DETECT_MODE_FULL ) cho camera chính.
Xem bản sửa đổi
android.os.Build.VERSION_CODES.U 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.1.1.3/H-3-1] PHẢI có màn hình HDR hỗ trợ mức trung bình ít nhất 1000 nits.
- [7.6.1/H-2-1] PHẢI có ít nhất 8 GB bộ nhớ vật lý.
Xem bản sửa đổi
android.os.Build.VERSION_CODES.U 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à 150 MB/s.
- [8.2/H-1-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên ít nhất 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 100 MB/s.
- [8.2/H-1-5] PHẢI đảm bảo hiệu suất đọc và ghi tuần tự song song với hiệu suất đọc gấp 2 lần và hiệu suất ghi ít nhất là 50 MB/s.
Xem bản sửa đổi
Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng mã hóa video sau và cung cấp chúng cho các ứng dụng của bên thứ ba:
- [ 5.2 /T-0-3] AV1
Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng giải mã video sau và cung cấp chúng cho các ứng dụng của bên thứ ba:
- [ 5.3.2 /T-0-7] AV1
Xem bản sửa đổi
Nếu việc triển khai thiết bị có màn hình khóa an toàn và bao gồm một hoặc nhiều tác nhân tin cậy triển khai API hệ thống TrustAgentService , thì chúng:
- [ 9.11.1 /W-1-1] PHẢI thách thức người dùng sử dụng một trong các phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khóa, mật khẩu) thường xuyên hơn 72 giờ một lần.
Xem bản sửa đổi
Nếu việc triển khai thiết bị bao gồm hỗ trợ cho đài phát sóng AM/FM và hiển thị chức năng cho bất kỳ ứng dụng nào, thì chúng:
- [ 7.4
.10/A-0-1] PHẢI khai báo hỗ trợ choFEATURE_BROADCAST_RADIO.
Camera quan sát bên ngoài là camera ghi lại các cảnh bên ngoài quá trình triển khai thiết bị, giống như camera chiếu hậu.
Triển khai thiết bị ô tô:
- NÊN bao gồm một hoặc nhiều camera quan sát bên ngoài.
Nếu việc triển khai thiết bị Ô tô bao gồm camera quan sát bên ngoài thì đối với camera đó, chúng sẽ:
- [ 7.5 /A-1-1] KHÔNG PHẢI có máy ảnh xem bên ngoài có thể truy cập được thông qua API máy ảnh Android , trừ khi chúng tuân thủ các yêu cầu cốt lõi của máy ảnh.
- [ 7.5 /A-SR-1] RẤT KHUYẾN NGHỊ không xoay hoặc phản chiếu theo chiều ngang phần xem trước của máy ảnh.
- [ 7.5 /A-SR-2] RẤT KHUYẾN NGHỊ nên có độ phân giải ít nhất là 1,3 megapixel.
- NÊN có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh mở rộng).
- CÓ THỂ triển khai tính năng tự động lấy nét phần cứng hoặc phần mềm tự động lấy nét 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 một camera như vậy, chúng:
- [ 7.5 /A-2-1] KHÔNG ĐƯỢC xoay hoặc phản 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 camera 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 nó cho các ứng dụng của bên thứ ba thì chúng:
- [ 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 PHẢI khai báo camera là camera hệ thống .
- CÓ THỂ hỗ trợ camera 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.) có sẵn cho máy ảnh phía sau như được mô tả trong phần 7.5.1 .
Camera phía sau nghĩa là camera hướng ra ngoài, có thể được đặt ở bất kỳ vị trí nào trên xe và hướng ra bên ngoài cabin xe; nghĩa là nó ghi lại các cảnh ở phía xa thân xe, giống như camera chiếu hậu.
Camera phía trước là camera hướng về phía người dùng, có thể được đặt ở bất kỳ vị trí nào trên xe và hướng vào bên trong cabin xe; đó là hình ảnh người dùng, chẳng hạn như đối với hội nghị truyền hình và các ứng dụng tương tự.
Triển khai thiết bị ô tô:
- [7.5/A-SR-1] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ nên bao gồm một hoặc nhiều camera hướng ra ngoài.
- CÓ THỂ bao gồm một hoặc nhiều camera hướng tới người dùng.
- [7.5/A-SR-2] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ để hỗ trợ phát trực tuyến đồng thời nhiều camera.
Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một camera có mặt thế giới thì đối với máy ảnh như vậy, thì họ:
- [7.5/A-1-1] phải được định hướng sao cho kích thước dài của camera phù hợp với mặt phẳng XY của các trục cảm biến ô tô Android.
- [7.5/A-SR-3] được khuyến nghị mạnh mẽ để có phần cứng tập trung cố định hoặc EDOF (độ sâu mở rộng của trường).
- .
Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một máy ảnh đang đối mặt với người dùng thì đối với máy ảnh như vậy:
- .
- Có thể được định hướng sao cho kích thước dài của máy ảnh thẳng hàng với mặt phẳng XY của các trục cảm biến ô tô Android.
Nếu việc triển khai thiết bị ô tô bao gồm một camera có thể truy cập thông qua android.hardware.Camera hoặc android.hardware.camera2 API, thì họ: họ:
- [7.5/A-3-1] phải tuân thủ các yêu cầu của camera cốt lõi trong Phần 7.5.
Nếu việc triển khai thiết bị ô tô bao gồm một camera không thể truy cập được thông qua android.hardware.Camera hoặc android.hardware.camera2 API, thì họ: họ:
- [7.5/A-4-1] Phải có thể truy cập thông qua Dịch vụ hệ thống xem mở rộng.
Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều camera có thể truy cập thông qua dịch vụ hệ thống xem mở rộng, cho một máy ảnh như vậy, thì họ:
- [7.5/a-5-1] Không được xoay hoặc phản chiếu theo chiều ngang của máy ảnh xem trước.
- [7.5/A-SR-4] được khuyến nghị mạnh mẽ để có độ phân giải ít nhất 1,3 megapixel.
Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều camera có thể truy cập thông qua cả dịch vụ hệ thống xem mở rộng và android.hardware.Camera hoặc android.hardware.Camera2 API thì cho một máy ảnh như vậy, họ: họ:
- [7.5/A-6-1] Phải báo cáo cùng một ID camera.
Nếu việc triển khai thiết bị ô tô cung cấp API camera độc quyền, thì họ:
Xem sửa đổi
Việc triển khai thiết bị ô tô:
Xem sửa đổi
Nếu việc triển khai thiết bị ô tô khai báo android.hardware.microphone , họ:
Nếu việc triển khai thiết bị ô tô khai báo android.hardware.camera.any , thì họ:
Nếu việc triển khai thiết bị có màn hình khóa an toàn và bao gồm một hoặc nhiều tác nhân tin cậy, trong đó thực hiện API Hệ thống TrustAgentService , thì họ:
3. Phần mềm
3.1. Khả năng tương thích API được quản lý :
Xem sửa đổi
Thực hiện thiết bị:
- [C-0-8] Không được hỗ trợ cài đặt các ứng dụng nhắm mục tiêu cấp API nhỏ hơn 23.
3.2.3.5. Ý định ứng dụng có điều kiện :
Xem sửa đổi
Nếu báo cáo triển khai thiết bị
android.hardware.nfc.uicchoặcandroid.hardware.nfc.ese, họ:- [C-19-1] Phải triển khai NFCADAPTER.Action_Transaction_Detected API (như là EVT_Transaction, được xác định bởi Đặc tả kỹ thuật của Hiệp hội GSM Ts.26-Yêu cầu cầm tay NFC) .
3.3.1. Giao diện nhị phân ứng dụng :
Xem sửa đổi
Thực hiện thiết bị:
- [C-0-12] MUST export function symbols for the core
Vulkan 1.0Vulkan 1.1 function symbols, as well as theVK_KHR_surface,VK_KHR_android_surface,VK_KHR_swapchain,VK_KHR_maintenance1, andVK_KHR_get_physical_device_properties2extensions through thelibvulkan.solibrary. Lưu ý rằng trong khi tất cả các biểu tượng phải có mặt, Phần 7.1.4.2 mô tả chi tiết hơn các yêu cầu khi thực hiện đầy đủ từng chức năng tương ứng được dự kiến.
- [C-0-12] MUST export function symbols for the core
Xem 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, họ:
- [C-1-5]
EXPRESSIVEtạoVIBRANTbảngandroid.theme.customization.theme_stylesmàuSPRITZbằng cách sửFRUIT_SALADcác kiểu chủTONAL_SPOTRAINBOWMONOCHROMATICliệt kê trongSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES.
- [C-1-5]
Xem sửa đổi
Nếu các triển khai thiết bị bao gồm khóa điều hướng chức năng Recents như chi tiết trong Phần 7.2.3 thay đổi giao diện, thì họ:
- [C-1-2] phải thực hiện hành vi ghim màn hình và cung cấp cho người dùng menu Cài đặt để chuyển đổi tính năng.
3.9.2 Hỗ trợ hồ sơ được quản lý :
Xem sửa đổi
Nếu việc triển khai thiết bị khai báo
android.software.managed_users, họ:- [C-1-10] phải đảm bảo rằng dữ liệu ảnh chụp màn hình được lưu trong lưu trữ hồ sơ công việc khi ảnh chụp màn hình được chụp bằng cửa sổ
topActivitycó tiêu điểm (người dùng tương tác với tất cả các hoạt động) và thuộc về hồ sơ công việc ứng dụng . - [C-1-11] Không được ghi lại bất kỳ nội dung màn hình nào khác (thanh hệ thống, thông báo hoặc bất kỳ nội dung hồ sơ cá nhân nào) ngoại trừ cửa sổ ứng dụng hồ sơ công việc/cửa sổ khi lưu ảnh chụp màn hình vào hồ sơ công việc (để đảm bảo dữ liệu hồ sơ cá nhân là không được lưu trong hồ sơ công việc).
- [C-1-10] phải đảm bảo rằng dữ liệu ảnh chụp màn hình được lưu trong lưu trữ hồ sơ công việc khi ảnh chụp màn hình được chụp bằng cửa sổ
3.9.5 Khung giải quyết chính sách thiết bị : Phần mới
Xem sửa đổi
Nếu báo cáo triển khai thiết bị
android.software.device_adminhoặcandroid.software.managed_users, thì họ: họ:- [C-1-1] Phải giải quyết các xung đột chính sách của thiết bị như được ghi lại trong tài liệu AOSP.
5. Khả năng tương thích đa phương tiện
Xem sửa đổi
Việc triển khai thiết bị phải hỗ trợ mã hóa mã hóa hình ảnh sau:
- [C-0-4] Avif
- Các thiết bị phải hỗ trợ
BITRATE_MODE_CQvà cấu hình cơ sở.
- Các thiết bị phải hỗ trợ
- [C-0-4] Avif
Xem sửa đổi
Việc triển khai thiết bị phải hỗ trợ giải mã mã hóa hình ảnh sau:
[C-0-7] AVIF (Hồ sơ cơ sở)
5.1.6. Chi tiết Codec hình ảnh :
Xem sửa đổi
Định dạng/codec Chi tiết Các loại tệp/định dạng container được hỗ trợ JPEG Cơ sở+tiến bộ Jpeg (.jpg) GIF Gif (.gif) PNG PNG (.png) BMP BMP (.BMP) WebP Trang web (.webp) thô Arw (.arw), cr2 (.cr2), dng (.dng), nef (.nef), nrw (.nrw), orf (.orf), pef (.pef), raf (.raf), rw2 ( .RW2), SRW (.SRW) HEIF Hình ảnh, bộ sưu tập hình ảnh, chuỗi hình ảnh Heif (.heif), heic (.heic) AVIF (Hồ sơ cơ sở) Hình ảnh, bộ sưu tập hình ảnh, cấu hình cơ sở trình tự hình ảnh Container heif (.avif) 5.1.8. Danh sách Codec video :
Xem sửa đổi
Định dạng/codec Chi tiết Các loại tệp/định dạng container được hỗ trợ H.263 - 3GPP (.3GP)
- MPEG-4 (.MP4)
- Matroska (.mkv, chỉ giải mã)
H.264 AVC Xem Phần 5.2 và 5.3 để biết chi tiết - 3GPP (.3GP)
- MPEG-4 (.MP4)
- MPEG-2 TS (.ts, không thể tìm kiếm)
- Matroska (.mkv, chỉ giải mã)
H.265 HEVC Xem Phần 5.3 để biết chi tiết - MPEG-4 (.MP4)
- Matroska (.mkv, chỉ giải mã)
MPEG-2 Tiểu sử chính - Mpeg2-ts (.ts, không thể tìm kiếm)
- MPEG-4 (.MP4, chỉ giải mã)
- Matroska (.mkv, chỉ giải mã)
MPEG-4 sp - 3GPP (.3GP)
- MPEG-4 (.MP4)
- Matroska (.mkv, chỉ giải mã)
VP8 Xem Phần 5.2 và 5.3 để biết chi tiết - WebM (.webm)
- Matroska (.mkv)
VP9 Xem Phần 5.3 để biết chi tiết - WebM (.webm)
- Matroska (.mkv)
AV1 Xem Phần 5.2 và Mục 5.3 để biết chi tiết - MPEG-4 (.MP4)
- Matroska (.mkv, chỉ giải mã)
5.1.10. Đặc tính codec phương tiện truyền thông :
Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ các codec video:
- [C-2-1] Tất cả các codec video phải xuất bản dữ liệu tốc độ khung hình có thể đạt được cho các kích thước sau nếu được codec hỗ trợ:
SD (chất lượng thấp) SD (Chất lượng cao) HD 720p HD 1080p UHD Độ phân giải video - 176 x 144 PX (H263, MPEG2, MPEG4)
- 352 X 288 PX (Bộ mã hóa MPEG4, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (khác)
- 704 X 576 PX (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 PX (Bộ mã hóa MPEG4)
- 720 x 480 px (Khác, AV1 )
- 1408 X 1152 PX (H263)
- 1280 x 720 px (Khác, AV1 )
1920 x 1080 px (ngoài MPEG4, AV1 ) 3840 x 2160 PX (HEVC, VP9, AV1 ) Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hóa video nào và cung cấp nó cho các ứng dụng của bên thứ ba, thì họ:- Không nên, qua hai cửa sổ trượt, hơn 15% so với các khoảng bitrate giữa các khoảng thời gian giữa các khung (khung i).
- Không nên quá 100% so với tốc độ bit trên cửa sổ trượt là 1 giây.
Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hóa video nào và cung cấp cho nó cho các ứng dụng của bên thứ ba và đặt
MediaFormat.KEY_BITRATE_MODEtoBITRATE_MODE_VBRđể bộ mã hóa hoạt động ở chế độ bitrate biến đổi, sau đó, miễn là nó không ảnh hưởng đến tầng chất lượng tối thiểu , tốc độ bit được mã hóa: Tỷ lệ bit được mã hóa:-
[C-5-1] Phảikhông nên, qua một cửa sổ trượt, hơn 15% so với các khoảng bitrate giữa các khoảng thời gian bên trong (khung i). -
[C-5-2] Phảikhông nên quá 100% so với tỷ lệ bit trên cửa sổ trượt là 1 giây.
Nếu các triển khai thiết bị hỗ trợ bất kỳ bộ mã hóa video nào và cung cấp nó cho các ứng dụng của bên thứ ba và đặt
MediaFormat.KEY_BITRATE_MODEthànhBITRATE_MODE_CBRđể bộ mã hóa hoạt động ở chế độ bitrate không đổi, thì đó-
[C-6-1] phải[C-SR-2] được khuyến nghị mạnh mẽ là không quá 15% so với tốc độ bit mục tiêu trên cửa sổ trượt là 1 giây.
Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ bộ mã hóa H.263 và cung cấp nó cho các ứng dụng của bên thứ ba, thì họ:
- [C-1-1] Phải hỗ trợ độ phân giải QCIF (176 x 144) bằng cách sử dụng hồ sơ cơ sở cấp độ 45. Độ phân giải SQCIF là tùy chọn.
-
Nên hỗ trợ bitrates có thể định cấu hình động cho bộ mã hóa được hỗ trợ.
Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ H.265 codec, họ: họ:
- [C-1-1] phải hỗ trợ hồ sơ chính cấp 3 lên tới 512 x 512 độ phân giải .
-
Nên hỗ trợ các cấu hình mã hóa HD như được chỉ ra trong bảng sau. - [C-SR-1] được khuyến nghị mạnh mẽ để hỗ trợ cấu hình 720 x 480 SD và cấu hình mã hóa HD như được chỉ ra trong bảng sau nếu có bộ mã hóa phần cứng.
5.2.6. AV1 : Phần mới
Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ codec AV1 thì họ: họ:
- [C-1-1] phải hỗ trợ hồ sơ chính bao gồm nội dung 8 bit và 10 bit.
[C-1-3] Phải chấp nhận siêu dữ liệu HDR và xuất nó vào BitStream
Nếu bộ mã hóa AV1 được tăng tốc phần cứng, thì nó: nó:
- [C-2-1] Phải hỗ trợ và bao gồm hồ sơ mã hóa HD1080P từ bảng dưới đây:
SD HD 720p HD 1080p UHD Độ phân giải video 720 x 480 px 1280 x 720 pixel 1920 x 1080 px 3840 x 2160 px Tỉ lệ khung hình video 30 khung hình/giây 30 khung hình/giây 30 khung hình/giây 30 khung hình/giây Tốc độ bit của video 5 Mb/giây 8 Mbps 16 Mb/giây 50 Mb/giây Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ bộ giải mã H.263, họ:
- .
Xem sửa đổi
Nếu việc triển khai thiết bị hỗ trợ codec AV1, họ:- [C-1-1] Phải hỗ trợ hồ sơ 0 bao gồm nội dung 10 bit.
Nếu việc triển khai thiết bị hỗ trợ Codec AV1 và cung cấp cho các ứng dụng của bên thứ ba, thì họ:
- [C-1-1] phải hỗ trợ hồ sơ chính bao gồm nội dung 8 bit và 10 bit.
Nếu việc triển khai thiết bị cung cấp hỗ trợ cho codec AV1 với bộ giải mã tăng tốc phần cứng thì họ:
- [C-2-1] phải có khả năng giải mã ít nhất HD 720p Hồ sơ giải mã video từ bảng bên dưới khi chiều cao được báo cáo bằng phương thức
Display.getSupportedModes()bằng hoặc lớn hơn 720p. - [C-2-2] phải có khả năng giải mã ít nhất HD 1080p Hồ sơ giải mã video từ bảng bên dưới khi chiều cao được báo cáo bằng phương thức
Display.getSupportedModes()bằng hoặc lớn hơn 1080p.
SD HD 720p HD 1080p UHD Độ phân giải video 720 x 480 px 1280 x 720 pixel 1920 x 1080 px 3840 x 2160 px Tỉ lệ khung hình video 30 khung hình/giây 30 khung hình/giây 30 khung hình/giây 30 khung hình/giây Tốc độ bit của video 5 Mb/giây 8 Mbps 16 Mb/giây 50 Mb/giây Nếu việc triển khai thiết bị hỗ trợ hồ sơ HDR thông qua API phương tiện, thì họ:
- [C-3-1] Phải hỗ trợ chiết xuất và xuất ra siêu dữ liệu HDR từ BITSTREAM và/hoặc container.
- [C-3-2] phải hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).
5.4.2. Nắm bắt để nhận dạng giọng nói :
Xem sửa đổi
Nếu việc triển khai thiết bị khai báo
android.hardware.microphone, họ:- Đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình hình sin 1000 Hz được phát ở mức áp suất âm thanh 90 dB (SPL) (được đo
ở khoảng cách 30 cm từbên cạnh micrô) mang lại phản hồi lý tưởng của RMS 2500 trong phạm vi 1770 và 3530 cho các mẫu 16 bit (hoặc -22,35 dB ± 3DB tỷ lệ toàn bộ cho các mẫu điểm nổi/chính xác) cho mỗi và mỗi micrô được sử dụng để ghi lại nguồn âm thanh nhận dạng giọng nói.
- Đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình hình sin 1000 Hz được phát ở mức áp suất âm thanh 90 dB (SPL) (được đo
Xem sửa đổi
Nếu việc triển khai thiết bị khai báo tính năng
android.hardware.audio.output, họ:- [C-1-4] phải hỗ trợ các hiệu ứng âm thanh với đầu vào và đầu ra điểm nổi.
- [C-1-5] phải đảm bảo rằng các hiệu ứng âm thanh hỗ trợ nhiều kênh lên đến số lượng kênh trộn còn được gọi là fcc_limit.
Xem sửa đổi
Nếu việc triển khai thiết bị khai báo
android.hardware.audio.output, họ được khuyến nghị đáp ứng hoặc vượt quá các yêu cầu sau:- [C-SR-4] Thời gian đầu ra được trả về bởi audiotrack.gettimestamp và
AAudioStream_getTimestamplà chính xác đến +/- 1 ms.
- [C-SR-4] Các độ trễ khứ hồi được tính toán dựa trên dấu thời gian đầu vào và đầu ra được trả về bởi
AAudioStream_getTimestampđược khuyến nghị mạnh mẽ trong vòng 30 msec của độ trễ của vòng tròn được đo choAAUDIO_PERFORMANCE_MODE_NONEvàAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
- [C-SR-4] Thời gian đầu ra được trả về bởi audiotrack.gettimestamp và
7. Khả năng tương thích phần cứng
Xem sửa đổi
Android bao gồm các cơ sở tự động điều chỉnh tài sản ứng dụng và bố cục UI một cách thích hợp cho thiết bị để đảm bảo rằng các ứng dụng của bên thứ ba chạy tốt trên
nhiều cấu hình phần cứng .Nhiều loại màn hình phần cứng và cấu hình. Màn hình tương thích Android là màn hình hiển thị thực hiện tất cả các hành vi và API được mô tả trong các nhà phát triển Android-Tổng quan về khả năng tương thích màn hình , phần này (7.1) và các tiểu mục của nó, cũng như bất kỳ hành vi cụ thể loại thiết bị bổ sung nào được ghi lại trong Phần 2 của 2 của 2 CDD này.Trên (các) màn hình tương thích Android trong đó tất cả các ứng dụng tương thích Android của bên thứ ba có thể chạy, việc triển khai thiết bị phải thực hiện đúng các API và hành vi này, như chi tiết trong phần này.Bắt đầu các yêu cầu mới
Thực hiện thiết bị:
- [C-0-1] Theo mặc định, phải hiển thị các ứng dụng của bên thứ ba trên màn hình tương thích Android.
Các đơn vị được tham chiếu bởi các yêu cầu trong phần này được xác định như sau:
- Kích thước chéo vật lý . Khoảng cách tính bằng inch giữa hai góc đối diện của phần được chiếu sáng của màn hình.
-
Dots trên mỗi inch (dpi)Mật độ . Số lượng pixel được bao gồm bởi một nhịp ngang hoặc dọc tuyến tính là 1 1 , được biểu thị dưới dạng pixel mỗi inch (PPI hoặc DPI) . Trong đó các giá trịDPIPPI và DPI được liệt kê, cả DPI ngang và dọc phải nằm trong phạm vi được liệt kê . - Tỷ lệ khung hình . Tỷ lệ của các pixel của kích thước dài hơn so với kích thước ngắn hơn của màn hình. Ví dụ, màn hình hiển thị 480x854 pixel sẽ là 854/480 = 1.779, hoặc gần như 16: 9: 9.
- pixel độc lập mật độ (DP) .
Đơnvị pixel ảo được chuẩn hóa thành mật độ mànhình 160 dpilà 160. Đối với một số mật độ D và một số pixel p, số lượng pixel độc lập mật độ DP, được tính là:pixel = dps * (mật độ/160)dp = (160 / d) * p .
7.1.1.1. Kích thước và hình dạng màn hình :
Xem sửa đổi
Nếu các triển khai thiết bị hỗ trợ màn hình có khả năng cấu hình kích thước
UI_MODE_TYPE_NORMALvà bao gồm (các) hiển thị vật lýtương thích Androidvới các góc tròn để hiển thị các màn hình này , chúng sẽ:- [C-1-1] phải đảm bảo rằng ít nhất một trong các yêu cầu sau đây được đáp ứng cho mỗi màn hình như vậy :
- Bán kính của các góc tròn nhỏ hơn hoặc bằng 38 dp.
Khi hộp 15 dp x 15 dp được neo ở mỗi góc của màn hình logic, ít nhất một pixel của mỗi hộp có thể nhìn thấy trên màn hình.
Nên bao gồm khả năng chi trả của người dùng để chuyển sang chế độ hiển thị với các góc hình chữ nhật.
Bắt đầu các yêu cầu mới
Nếu việc triển khai thiết bị chỉ có khả năng cấu hình bàn phím
NO_KEYSvà dự định báo cáo hỗ trợ cho cấu hình Chế độ UIUI_MODE_TYPE_NORMAL, thì họ: họ:- [C-4-1] Phải có kích thước bố cục, không bao gồm bất kỳ điểm cắt hiển thị nào, ít nhất 596 dp x 384 dp trở lên.
Nếu việc triển khai thiết bị bao gồm (các) màn hình tương thích Android có thể gập lại hoặc bao gồm bản lề gấp giữa nhiều bảng hiển thị và cung cấp (các) màn hình như vậy để hiển thị các ứng dụng của bên thứ ba, thì họ:
Nếu việc triển khai thiết bị bao gồm (các) màn hình tương thích Android có thể gập lại hoặc bao gồm bản lề gấp giữa nhiều bảng hiển thị và nếu bản lề hoặc gập qua cửa sổ ứng dụng toàn màn hình, họ sẽ:
- [C-3-1] Phải báo cáo vị trí, giới hạn và trạng thái bản lề hoặc gấp qua các tiện ích mở rộng hoặc API sidecar cho ứng dụng.
Nếu việc triển khai thiết bị bao gồm một hoặc nhiều khu vực hiển thị tương thích Android có thể gập lại hoặc bao gồm bản lề gấp giữa nhiều khu vực bảng điều khiển hiển thị tương thích Android và cung cấp các khu vực hiển thị như vậy cho các ứng dụng, họ:
- [C-4-1] Phải triển khai phiên bản chính xác của cấp API tiện ích mở rộng Window Manager như được mô tả trong tài liệu sắp tới.
7.1.1.2. Tỷ lệ khung hình màn hình : Đã loại bỏ
Xem sửa đổi
Thực hiện thiết bị:
- [C-0-1]
Theo mặc định, việc triển khai thiết bịchỉphải báo cáo một trong các mật độ khung Android được liệt kê trênDisplayMetricsthông qua APIDENSITY_DEVICE_STABLEvà giá trị này phải là giá trị tĩnh cho mỗi màn hình vật lýkhông được thay đổi bất cứ lúc nào; Tuy nhiên,tuy nhiên, thiết bị có thể báo cáo mộtDisplayMetrics.densitymật độ tùy ýkhác nhau. Mật độ theo các thay đổi cấu hình hiển thị được thực hiện bởi người dùng (ví dụ: kích thước hiển thị) được đặt sau khi khởi động ban đầu.
- Việc triển khai thiết bị nên xác định mật độ khung Android tiêu chuẩn gần nhất với mật độ vật lý của màn hình, trừ khi mật độ logic đó đẩy kích thước màn hình được báo cáo dưới mức tối thiểu được hỗ trợ. Nếu mật độ khung Android tiêu chuẩn gần nhất với mật độ vật lý sẽ dẫn đến kích thước màn hình nhỏ hơn kích thước màn hình tương thích được hỗ trợ nhỏ nhất (chiều rộng 320 dP), việc triển khai thiết bị sẽ báo cáo mật độ khung Android tiêu chuẩn thấp nhất tiếp theo.
Bắt đầu các yêu cầu mới
- Nên xác định mật độ khung Android tiêu chuẩn gần nhất với mật độ vật lý của màn hình hoặc giá trị sẽ ánh xạ tới cùng các phép đo trường góc nhìn tương đương của thiết bị cầm tay.
Nếu việc triển khai thiết bị cung cấp,
cókhả năng thay đổi kích thước hiển thị của thiết bị , thì họ :-
.DENSITY_DEVICE_STABLE - [C-1-2]
Kích thước hiển thị không được chia tỷ lệ bất kỳ quymô nào không được mở rộng màn hình nhỏ hơn 0,85 lầnmật độ gốcDENSITY_DEVICE_STABLE.
- [C-0-1]
Xem sửa đổi
Nếu việc triển khai thiết bị bao gồm hỗ trợ cho Vulkan
1.0 trở lên, thì họ:[C-1-3] phải thực hiện đầy đủ API
Vulkan 1.0Vulkan 1.1 cho mỗiVkPhysicalDeviceđược liệt kê.[C-1-5] Không
trueliệt kê các lớp được cung cấp bởi các thư viện bên ngoài gói ứng dụng hoặc cung cấp các cách truy tìmcom.android.graphics.injectLayers.enablechặn API Vulkanandroid:debuggablecom.android.graphics.injectLayers.enableĐặt thànhtrue.
- Nên hỗ trợ
VkPhysicalDeviceProtectedMemoryFeaturesvàVK_EXT_global_priority.
- [C-1-13] phải đáp ứng các yêu cầu được chỉ định bởi hồ sơ cơ sở Android 2021 .
[C-SR-5] được khuyến nghị mạnh mẽ để hỗ trợ
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryvàVK_EXT_global_priority.[C-SR-6] được khuyến nghị sử dụng
SkiaVkvới HWUI.
Nếu việc triển khai thiết bị bao gồm hỗ trợ cho Vulkan 1.1 và khai báo bất kỳ cờ tính năng Vulkan nào được mô tả ở đây , thì họ:
- [C-SR-7] được khuyến nghị mạnh mẽ để thực hiện tiện ích mở rộng
VK_KHR_external_fence_fdcó sẵn cho các ứng dụng của bên thứ ba và cho phép ứng dụng xuất tải trọng hàng rào vào và nhập tải trọng hàng rào từ các mô tả tệp POSIX như được mô tả ở đây .
7.3.10. Cảm biến sinh trắc học :
Xem sửa đổi
Nếu việc triển khai thiết bị có nhiều cảm biến sinh trắc học, thì chúng:
[C-7-1] phải, khi sinh trắc học bị khóa (nghĩa là sinh trắc học bị vô hiệu hóa cho đến khi người dùng mở khóa xác thực chính) hoặc khóa thời gian (tức là sinh trắc học tạm thời bị vô hiệu hóa cho đến khi người dùng chờ khoảng thời gian) Do quá nhiều nỗ lực thất bại, cũng khóa tất cả các sinh trắc học khác của một lớp sinh trắc học thấp hơn. Trong trường hợp khóa thời gian, thời gian ngược để xác minh sinh trắc học phải là thời gian ngược tối đa của tất cả các sinh trắc học trong khóa giới hạn thời gian.
[C-SR-12] được khuyến nghị mạnh mẽ, khi sinh trắc học bị khóa (tức là sinh trắc học bị vô hiệu hóa cho đến khi người dùng mở khóa xác thực chính) hoặc khóa thời gian khoảng thời gian) do quá nhiều nỗ lực thất bại, cũng khóa tất cả các sinh trắc học khác của cùng một lớp sinh trắc học. Trong trường hợp khóa thời gian, thời gian ngược để xác minh sinh trắc học được khuyến khích là thời gian ngược tối đa của tất cả các sinh trắc học trong khóa giới hạn thời gian.
[C-7-2] Phải thách thức người dùng cho xác thực chính được đề xuất (ví dụ: pin, mẫu, mật khẩu) để đặt lại bộ đếm khóa cho một sinh trắc học bị khóa. Sinh trắc học lớp 3 có thể được phép đặt lại bộ đếm khóa cho một sinh trắc học bị khóa cùng lớp hoặc cấp thấp hơn. Không được phép sinh trắc học lớp 2 hoặc lớp 1 để hoàn thành thao tác khóa đặt lại cho bất kỳ sinh trắc học nào.
Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là loại 1 (trước đây là tiện lợi ), thì họ:
[C-1-12] phải có tỷ lệ chấp nhận giả mạo và mạo danh không cao hơn 40% cho mỗi loài công cụ tấn công (PAI) , được đo bằng các giao thức kiểm tra sinh trắc học Android .
[C-SR-13] được khuyến nghị mạnh mẽ để có tỷ lệ chấp nhận giả mạo và mạo danh không cao hơn 30% cho mỗi loài công cụ tấn công (PAI) , được đo bằng các giao thức kiểm tra sinh trắc học Android .
[C-SR-14] được khuyến nghị mạnh mẽ để tiết lộ lớp sinh trắc học của cảm biến sinh trắc học và các rủi ro tương ứng của việc cho phép nó.
[C-SR-17] được khuyến nghị mạnh mẽ để triển khai các giao diện AIDL mới (chẳng hạn như,
IFace.aidlvàIFingerprint.aidl).
Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là loại 2 (trước đây yếu ), thì họ:
- [C-SR-15] được khuyến nghị mạnh mẽ để có tỷ lệ chấp nhận giả mạo và mạo danh không cao hơn 20% cho mỗi loài công cụ tấn công (PAI) , được đo bằng các giao thức kiểm tra sinh trắc học Android .
- [C-2-3] phải thực hiện khớp sinh trắc học trong môi trường thực thi bị cô lập bên ngoài người dùng Android hoặc không gian nhân, chẳng hạn như môi trường thực thi đáng tin cậy (TEE)
hoặctrên chip có kênh an toàn đến môi trường thực hiện bị cô lập hoặc trên Máy ảo đáp ứng các yêu cầu trong Phần 9.17 . - [C-2-4] Phải có tất cả các dữ liệu được mã hóa được mã hóa và xác thực bằng mật mã sao cho chúng không thể thu được, đọc hoặc thay đổi bên ngoài môi trường thực thi bị cô lập hoặc chip có kênh an toàn đến môi trường thực thi bị cô lập như được ghi lại trong hướng dẫn thực hiện Trên trang web dự án nguồn mở Android hoặc máy ảo được bảo vệ được điều khiển bởi trình ảo hóa đáp ứng các yêu cầu trong Phần 9.17 .
- [C-2-5] Đối với sinh trắc học dựa trên camera, trong khi xác thực hoặc ghi danh dựa trên sinh trắc học đang xảy ra:
- Phải vận hành camera ở chế độ ngăn khung máy ảnh được đọc hoặc thay đổi bên ngoài môi trường thực thi bị cô lập hoặc chip có kênh an toàn đến môi trường thực thi bị cô lập hoặc máy ảo được bảo vệ được điều khiển bởi hypervisor đáp ứng các yêu cầu trong Phần 9.17 .
- Đối với các giải pháp camera đơn RGB, khung máy ảnh có thể đọc được bên ngoài môi trường thực hiện bị cô lập để hỗ trợ các hoạt động như xem trước để đăng ký, nhưng vẫn không thể thay đổi.
- [C-2-7] Không được cho phép truy cập không được mã hóa vào dữ liệu sinh trắc học có thể xác định hoặc bất kỳ dữ liệu nào có nguồn gốc từ nó (như nhúng) vào bộ xử lý ứng dụng bên ngoài bối cảnh của TEE hoặc máy ảo được bảo vệ được điều khiển bởi trình khử trùng đáp ứng các yêu cầu trong phần 9,17 . Các thiết bị nâng cấp được khởi chạy trên phiên bản Android 9 hoặc sớm hơn không được miễn trừ khỏi C-2-7.
Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là loại 3 (trước đây là mạnh ), thì họ:
- [C-SR-16] được khuyến nghị mạnh mẽ để có tỷ lệ chấp nhận giả mạo và mạo danh không cao hơn 7% cho mỗi loài công cụ tấn công (PAI) , được đo bằng các giao thức kiểm tra sinh trắc học Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Xem sửa đổi
Nếu việc triển khai thiết bị bao gồm hỗ trợ cho 802.1.15.4 và hiển thị chức năng cho ứng dụng của bên thứ ba, thì họ:
- [C-1-2] Phải báo cáo tính năng phần cứng Cờ
android.hardware.uwb. - [C-1-3] phải hỗ trợ tất cả các bộ cấu hình sau (các kết hợp được xác định trước của các tham số FIRA UCI ) được xác định trong triển khai AOSP.
-
CONFIG_ID_1: unicastSTATIC STS DS-TWRdo FIRA xác định, chế độ hoãn lại, khoảng thời gian 240 ms. -
CONFIG_ID_2:STATIC STS DS-TWRđược xác định bởi FIRA, Chế độ hoãn lại, khoảng thời gian 200 ms. Trường hợp sử dụng điển hình: Điện thoại thông minh tương tác với nhiều thiết bị thông minh. -
CONFIG_ID_3: giống nhưCONFIG_ID_1, ngoại trừ dữ liệu góc độ (AOA) không được báo cáo. -
CONFIG_ID_4: Giống nhưCONFIG_ID_1, ngoại trừ chế độ bảo mật P-STS được bật. -
CONFIG_ID_5: Giống nhưCONFIG_ID_2, ngoại trừ chế độ bảo mật P-STS được bật. -
CONFIG_ID_6: Giống nhưCONFIG_ID_3, ngoại trừ chế độ bảo mật P-STS được bật. -
CONFIG_ID_7: Tương tự nhưCONFIG_ID_2, ngoại trừ chế độ khóa con điều khiển cá nhân P-STS được bật.
-
- [C-1-4] phải cung cấp khả năng chi trả cho người dùng để cho phép người dùng chuyển đổi trạng thái bật/tắt radio UWB.
- [C-1-5] phải thực thi rằng các ứng dụng sử dụng Radio UWB giữ quyền của
UWB_RANGING(theo nhóm quyềnNEARBY_DEVICES).
Thông qua các bài kiểm tra chứng nhận và phù hợp có liên quan được xác định bởi các tổ chức tiêu chuẩn, bao gồm FIRA , CCC và CSA giúp đảm bảo các chức năng 802.1.15.4 một cách chính xác.
- [C-1-2] Phải báo cáo tính năng phần cứng Cờ
Xem sửa đổi
Điện thoại điện thoại trực tiếp được sử dụng bởi API Android và tài liệu này đề cập cụ thể đến phần cứng liên quan đến việc thực hiện các cuộc gọi thoại và gửi tin nhắn SMS hoặc thiết lập dữ liệu di động thông qua mạng di động (ví dụ GSM, CDMA, LTE, NR) GSM hoặc CDMA. Một thiết bị hỗ trợ điện thoại trực tuyến có thể chọn cung cấp một số hoặc tất cả các dịch vụ gọi, nhắn tin và dữ liệu phù hợp với sản phẩm.
thông qua mạng GSM hoặc CDMA. Mặc dù các cuộc gọi thoại này có thể chuyển đổi gói, nhưng chúng cho mục đích của Android được coi là độc lập với bất kỳ kết nối dữ liệu nào có thể được triển khai bằng cùng một mạng. Nói cách khác, chức năng và API của điện thoại Android và API được đề cập cụ thể đến các cuộc gọi thoại và SMS. Chẳng hạn, việc triển khai thiết bị không thể thực hiện các cuộc gọi hoặc gửi/nhận tin nhắn SMS không được coi là thiết bị điện thoại, bất kể họ sử dụng mạng di động để kết nối dữ liệu.Xem sửa đổi
Nếu việc triển khai thiết bị bao gồm hỗ trợ cho 802.11 và hiển thị chức năng cho ứng dụng của bên thứ ba, thì họ:
- [C-1-4] phải hỗ trợ DNS phát đa hướng (MDN) và không được lọc các gói MDNS (224.0.0.251 hoặc FF02 :: FB ) bất cứ lúc nào hoạt động, bao gồm cả khi màn hình không ở trạng thái hoạt động, trừ khi giảm hoặc giảm hoặc giảm Lọc các gói này là cần thiết để ở trong phạm vi tiêu thụ điện năng theo yêu cầu của các yêu cầu quy định áp dụng cho thị trường mục tiêu.
Đối với việc triển khai thiết bị truyền hình Android, ngay cả khi ở trạng thái sức mạnh dự phòng.
- [C-1-4] phải hỗ trợ DNS phát đa hướng (MDN) và không được lọc các gói MDNS (224.0.0.251 hoặc FF02 :: FB ) bất cứ lúc nào hoạt động, bao gồm cả khi màn hình không ở trạng thái hoạt động, trừ khi giảm hoặc giảm hoặc giảm Lọc các gói này là cần thiết để ở trong phạm vi tiêu thụ điện năng theo yêu cầu của các yêu cầu quy định áp dụng cho thị trường mục tiêu.
Xem sửa đổi
Nếu việc triển khai thiết bị khai báo tính năng_bluetooth_le, họ:
- [C-SR-2] được khuyến nghị mạnh mẽ để đo và bù cho phần bù RX để đảm bảo trung bình ble rssi là -60dbm +/- 10 dB ở khoảng
ADVERTISE_TX_POWER_HIGH1M trên 'các mặt phẳng song song' với các màn hình đối diện với cùng một hướng. - [C-SR-3] được khuyến nghị mạnh mẽ để đo và bù cho phần bù TX để đảm bảo BLE RSSI trung bình là -60dbm +/- 10 dB khi quét từ thiết bị tham chiếu được định vị ở khoảng cách 1M và truyền tại
ADVERTISE_TX_POWER_HIGH, nơi các thiết bị được định hướng sao cho chúng nằm trên 'các mặt phẳng song song' với các màn hình đối diện với cùng một hướng.
- [C-10-3] phải đo và bù cho phần bù RX để đảm bảo RSSI BLE trung bình là -55dbm +/- 10 dB ở khoảng cách 1M từ thiết bị tham chiếu truyền tại
ADVERTISE_TX_POWER_HIGH. - [C-10-4] phải đo và bù cho phần bù TX để đảm bảo RSSI BLE trung bình là -55dbm +/- 10 dB khi quét từ thiết bị tham chiếu được định vị ở khoảng cách 1M và truyền tại
ADVERTISE_TX_POWER_HIGH.
Nếu việc triển khai thiết bị hỗ trợ Bluetooth phiên bản 5.0, thì họ:
- [C-SR-4] được khuyến nghị mạnh mẽ để cung cấp hỗ trợ cho:
- Le 2m phy
- Le Codec Phy
- Le mở rộng quảng cáo
- Quảng cáo định kỳ
- Ít nhất 10 bộ quảng cáo
- Ít nhất 8 kết nối đồng thời. Mỗi kết nối có thể nằm trong một trong hai vai trò cấu trúc liên kết kết nối.
- Quyền riêng tư lớp liên kết LE
- Kích thước "danh sách giải quyết" của ít nhất 8 mục
- [C-SR-2] được khuyến nghị mạnh mẽ để đo và bù cho phần bù RX để đảm bảo trung bình ble rssi là -60dbm +/- 10 dB ở khoảng
Xem sửa đổi
- [C-1-7] phải đảm bảo rằng trung bình của các phép đo khoảng cách ở mức 1m từ thiết bị tham chiếu nằm trong [0,75m, 1,25m], trong đó khoảng cách sự thật mặt đất được đo từ cạnh trên của DUT.
Giữ úp mặt và nghiêng 45 độ.
- [C-1-7] phải đảm bảo rằng trung bình của các phép đo khoảng cách ở mức 1m từ thiết bị tham chiếu nằm trong [0,75m, 1,25m], trong đó khoảng cách sự thật mặt đất được đo từ cạnh trên của DUT.
Xem sửa đổi
Một camera phía sau là một camera nằm ở bên cạnh thiết bị đối diện với màn hình; Đó là, nó hình ảnh các cảnh ở phía xa của thiết bị, giống như một máy ảnh truyền thống.
Một camera phía sau là một máy ảnh hướng về thế giới, hình ảnh các cảnh ở phía xa của thiết bị, giống như một máy ảnh truyền thống; Trên các thiết bị cầm tay, đó là một máy ảnh nằm ở bên cạnh thiết bị đối diện với màn hình.
7.5.2. Mặt trước của máy ảnh :
Xem sửa đổi
Một camera phía trước là một camera nằm ở cùng phía của thiết bị với màn hình; Đó là, một máy ảnh thường được sử dụng để hình ảnh người dùng, chẳng hạn như để hội nghị truyền hình và các ứng dụng tương tự.
Một camera phía trước là một camera đối mặt với người dùng thường được sử dụng để hình ảnh người dùng, chẳng hạn như đối với hội nghị truyền hình và các ứng dụng tương tự; Trên các thiết bị cầm tay, đó là một máy ảnh nằm ở cùng phía của thiết bị với màn hình.
Xem sửa đổi
Một camera bên ngoài là một camera có thể được gắn hoặc tách rời khỏi việc triển khai thiết bị bất cứ lúc nào và có thể đối mặt với bất kỳ hướng nào; chẳng hạn như máy ảnh USB.
Xem sửa đổi
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator().
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator(). - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstantsnamely (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_STARTandGESTURE_END). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffectnamely (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKandEFFECT_DOUBLE_CLICK) and all feasible publicPRIMITIVE_*constants for rich haptics inandroid.os.VibrationEffect.Compositionnamely (CLICK,TICK,LOW_TICK,QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD). Some of these primitives, such asLOW_TICKandSPINmay only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstantsto the recommendedandroid.os.VibrationEffectconstants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()andcreateWaveform()APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl().
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()andandroid.os.Vibrator.arePrimitivesSupported()APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
9. Security Model Compatibility
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionServicethey:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATIONas the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW -
Intent.ACTION_SENDTO -
Intent.ACTION_SEND -
Intent.ACTION_EDIT -
Intent.ACTION_INSERT -
Intent.ACTION_INSERT_OR_EDIT -
Intent.ACTION_SEND_MULTIPLE -
Intent.ACTION_PICK -
Intent.ACTION_GET_CONTENT -
MediaStore.ACTION_IMAGE_CAPTURE -
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagModemanifest option:- heap buffer overflow
- use after free
- miễn phí gấp đôi
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported.
If device implementations set the system property
ro.arm64.memtag.bootctl_supportedto true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctlto accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag: a Memory Safety technology as defined above is enabled -
memtag-once: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl.[C-3-4] MUST set
arm64.memtag.bootctlto the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay(),VirtualDeviceManager.createVirtualDisplay(), or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()with theandroid.app.role.COMPANION_DEVICE_APP_STREAMINGor theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGdevice profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
ContentCaptureService,AugmentedAutofillService,AppSearchGlobalManager.query, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillServiceto the system. - Any screen or other data accessible via
Content CaptureAPI. - Any screen or other data accessible via
FieldClassificationServiceAPI - Any application data passed to the system via the
AppSearchManagerAPI and accessible viaAppSearchGlobalManager.query.
- Any other events that an application provides to the system via the
Content CaptureAPI or orAppSearchManagerAPI a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord,SoundTriggeror other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is đã chia sẻ. Unless such functionality is built as an Android SDK API (AmbientContext,HotwordDetectionService).[C-1-6] MUST provide user affordance to erase such data that the
ContentCaptureServiceifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephonyfeature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONYMUST contain at least the following information:-
SubscriptionManagerServicedump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Sự cho phép .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService,WearableSensingService,VisualQueryDetector). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORDas an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentServiceSystem API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of bận tâm.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-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
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.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [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 only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM 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.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM 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 MachinepVM 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 MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto 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 ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
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 pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
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 be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
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- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the