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.

Trang này được dịch bởi Cloud Translation API.

Định nghĩa về khả năng tương thích với Android 14

1. Giới thiệu

Tài liệu này liệt kê các yêu cầu phải được đáp ứng để thiết bị tương thích với Android 14.

Việc sử dụng các từ "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "KHÔNG SẼ", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" là theo tiêu chuẩn IETF được xác định trong RFC2119.

Trong tài liệu này, "người triển khai thiết bị" hoặc "người triển khai" là một người hoặc tổ chức phát triển giải pháp phần cứng/phần mềm chạy Android 14. "Triển khai thiết bị" hoặc "triển khai" là giải pháp phần cứng/phần mềm được phát triển.

Để được xem là tương thích với Android 14, việc triển khai thiết bị PHẢI đáp ứng các yêu cầu được nêu trong Định nghĩa về khả năng tương thích này, bao gồm mọi tài liệu được đưa vào thông qua tham chiếu.

Trong trường hợp định nghĩa này hoặc các thử nghiệm phần mềm được mô tả trong mục 10 không đề cập, không rõ ràng hoặc chưa hoàn chỉnh, thì người triển khai thiết bị có trách nhiệm đảm bảo khả năng tương thích với các phương thức triển khai hiện có.

Vì lý do này, Dự án nguồn mở Android vừa là tài liệu tham khảo vừa là phương thức triển khai ưu tiên của Android. NÊN triển khai triển khai thiết bị theo mức độ lớn nhất có thể dựa trên mã nguồn "nguồn cấp trên" có trong Dự án nguồn mở Android. Mặc dù có thể giả định rằng một số thành phần có thể được thay thế bằng các phương thức triển khai thay thế, nhưng bạn KHÔNG NÊN làm theo phương pháp này vì việc vượt qua các bài kiểm thử phần mềm sẽ trở nên khó khăn hơn đáng kể. Người triển khai có trách nhiệm đảm bảo khả năng tương thích đầy đủ về hành vi với cách triển khai Android chuẩn, bao gồm cả Bộ kiểm thử khả năng tương thích. Cuối cùng, xin lưu ý rằng tài liệu này nghiêm cấm một số hoạt động thay thế và sửa đổi thành phần.

Nhiều tài nguyên được liên kết trong tài liệu này được lấy trực tiếp hoặc gián tiếp từ SDK Android và sẽ có chức năng giống với thông tin trong tài liệu của SDK đó. Trong mọi trường hợp, nếu Định nghĩa về khả năng tương thích hoặc Bộ kiểm thử khả năng tương thích không đồng ý với tài liệu SDK, thì tài liệu SDK được coi là có thẩm quyền. Mọi thông tin chi tiết kỹ thuật được cung cấp trong các tài nguyên được liên kết trong toàn bộ tài liệu này đều được coi là một phần của Định nghĩa về khả năng tương thích này.

1.1 Cấu trúc tài liệu

1.1.1. Yêu cầu theo loại thiết bị

Mục 2 chứa tất cả các yêu cầu áp dụng cho một loại thiết bị cụ thể. Mỗi tiểu mục của Mục 2 dành riêng cho một loại thiết bị cụ thể.

Tất cả các yêu cầu khác áp dụng chung cho mọi hoạt động triển khai thiết bị Android được liệt kê trong các phần sau Mục 2. Các yêu cầu này được gọi là "Yêu cầu cốt lõi" trong tài liệu này.

1.1.2. Mã yêu cầu

Mã yêu cầu được chỉ định cho các yêu cầu PHẢI.

Mã nhận dạng chỉ được chỉ định cho các yêu cầu PHẢI.
Các yêu cầu NÊN CÓ được đánh dấu là [SR] nhưng không được chỉ định mã nhận dạng.
Mã này bao gồm: Mã loại thiết bị – Mã điều kiện – Mã yêu cầu (ví dụ: C-0-1).

Mỗi mã được xác định như sau:

Mã loại thiết bị (xem thêm trong phần 2. Loại thiết bị)
- C: Core (Yêu cầu áp dụng cho tất cả hoạt động triển khai thiết bị Android)
- H: Thiết bị cầm tay Android
- T: Thiết bị Android TV
- Đáp: Triển khai Android Automotive
- W: Triển khai Android Watch
- Thẻ: Triển khai trên máy tính bảng Android
Mã điều kiện
- Khi yêu cầu không có điều kiện, mã nhận dạng này được đặt thành 0.
- Khi yêu cầu có điều kiện, hệ thống sẽ chỉ định 1 cho điều kiện thứ nhất và số này sẽ tăng thêm 1 trong cùng một mục và cùng một loại thiết bị.
Mã yêu cầu
- Mã nhận dạng này bắt đầu từ 1 và tăng thêm 1 trong cùng một mục và cùng một điều kiện.

1.1.3. Mã yêu cầu trong Phần 2

Mã yêu cầu trong Phần 2 có hai phần. Giá trị đầu tiên tương ứng với mã phần như mô tả ở trên. Phần thứ hai xác định kiểu dáng và yêu cầu cụ thể về kiểu dáng.

theo sau là Mã yêu cầu được mô tả ở trên.

Mã trong Mục 2 bao gồm: Mã mục / Mã loại thiết bị – Mã điều kiện – Mã yêu cầu (ví dụ: 7.4.3/A-0-1).

2. Loại thiết bị

Dự án nguồn mở Android cung cấp một ngăn xếp phần mềm có thể được sử dụng cho nhiều loại thiết bị và kiểu dáng. Để hỗ trợ bảo mật trên thiết bị, ngăn xếp phần mềm, bao gồm mọi hệ điều hành thay thế hoặc phương thức triển khai nhân thay thế, dự kiến sẽ thực thi trong một môi trường an toàn như mô tả trong phần 9 và các phần khác trong CDD này. Có một số loại thiết bị có hệ sinh thái phân phối ứng dụng tương đối tốt hơn.

Phần này mô tả các loại thiết bị đó, cũng như các yêu cầu và đề xuất bổ sung áp dụng cho từng loại thiết bị.

Tất cả các phương thức triển khai thiết bị Android không thuộc bất kỳ loại thiết bị nào được mô tả VẪN PHẢI đáp ứng tất cả các yêu cầu trong các phần khác của Định nghĩa về khả năng tương thích này.

2.1 Cấu hình thiết bị

Để biết những điểm khác biệt chính về cấu hình phần cứng theo loại thiết bị, hãy xem các yêu cầu dành riêng cho thiết bị trong phần sau.

2.2. Yêu cầu đối với thiết bị cầm tay

Thiết bị cầm tay Android đề cập đến việc triển khai thiết bị Android thường được sử dụng bằng cách cầm thiết bị trong tay, chẳng hạn như máy nghe nhạc mp3, điện thoại hoặc máy tính bảng.

Các hoạt động triển khai thiết bị Android được phân loại là Thiết bị cầm tay nếu đáp ứng tất cả các tiêu chí sau:

Có nguồn điện có thể di chuyển, chẳng hạn như pin.
Có kích thước màn hình đường chéo thực tế trong khoảng từ 4 inch ~~3,3 inch (hoặc 2,5 inch đối với các thiết bị triển khai được vận chuyển trên API cấp 29 trở xuống)~~ đến 8 inch.
Có giao diện nhập bằng màn hình cảm ứng.

Các yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho việc triển khai thiết bị cầm tay Android.

Lưu ý: Những yêu cầu không áp dụng cho thiết bị Máy tính bảng Android sẽ được đánh dấu bằng dấu *.

2.2.1. Phần cứng

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 và đá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 2,2 inch ở cạnh ngắn và 3,4 inch ở cạnh dài.
[7.1.1.3/H-SR-1] NÊN cung cấp cho người dùng khả năng thay đổi kích thước màn hình (mật độ màn hình).
[7.1.1.1/H-0-2] PHẢI hỗ trợ thành phần GPU của vùng đệm đồ hoạ có kích thước tối thiểu bằng độ phân giải cao nhất của mọi màn hình tích hợp.

Bắt đầu yêu cầu mới

[7.1.1.1/H-0-3]* PHẢI liên kết từng màn hình UI_MODE_NORMAL được cung cấp cho các ứng dụng bên thứ ba với một khu vực hiển thị thực tế không bị che khuất, có kích thước tối thiểu 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_STABLE là 92% trở lên so với mật độ thực tế, vật lý của màn hình tương ứng.

Kết thúc các yêu cầu mới

Nếu việc triển khai Thiết bị cầm tay hỗ trợ tính năng xoay màn hình bằng phần mềm, thì các thiết bị đó:

[7.1.1.1/H-1-1]* PHẢI đảm bảo màn hình logic được cung cấp cho các ứng dụng bên thứ ba có kích thước tối thiểu 2 inch ở(các) cạnh ngắn và 2,7 inch ở(các) cạnh dài. Các thiết bị được vận chuyển trên Android API 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ợ tính năng xoay màn hình bằng phần mềm, thì các thiết bị đó:

[7.1.1.1/H-2-1]* PHẢI đảm bảo màn hình logic được cung cấp cho các ứng dụng bên thứ ba có kích thước tối thiểu là 2,7 inch ở(các) cạnh ngắn. Các thiết bị được vận chuyển trên Android API 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

Nếu việc triển khai thiết bị cầm tay có hỗ trợ Vulkan, thì các thiết bị đó:

[7.1.4.2/H-1-1] PHẢI đáp ứng các yêu cầu do Hồ sơ cơ sở Android 2021 chỉ định.

Kết thúc các yêu cầu mới

Nếu việc triển khai thiết bị cầm tay tuyên bố hỗ trợ màn hình dải động cao thông qua Configuration.isScreenHdr() , thì các thiết bị đó:

[7.1.4.5/H-1-1] PHẢI quảng cáo việc hỗ trợ các tiện ích EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace và VK_EXT_hdr_metadata.

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

[7.1.4.6/H-0-1] PHẢI báo cáo xem thiết bị có hỗ trợ tính năng phân tích GPU hay không thông qua thuộc tính hệ thống graphics.gpu.profiler.support.

Nếu các hoạt động triển khai Thiết bị cầm tay khai báo hỗ trợ thông qua thuộc tính hệ thống graphics.gpu.profiler.support, thì các hoạt động đó:

[7.1.4.6/H-1-1] PHẢI báo cáo dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ cho bộ đếm GPU và các giai đoạn kết xuất GPU được xác định trong tài liệu Perfetto.
[7.1.4.6/H-1-2] PHẢI báo cáo các giá trị tuân thủ cho bộ đếm GPU của thiết bị theo proto gói theo dõi bộ đếm GPU.
[7.1.4.6/H-1-3] PHẢI báo cáo các giá trị tuân thủ cho GPU RenderStages của thiết bị theo proto gói theo dõi giai đoạn kết xuất.
[7.1.4.6/H-1-4] PHẢI báo cáo điểm theo dõi Tần số GPU theo định dạng được chỉ định: power/gpu_frequency.

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

[7.1.5/H-0-1] PHẢI hỗ trợ chế độ tương thích với ứng dụng cũ do mã nguồn mở Android thượng nguồn triển khai. Tức là việc triển khai thiết bị KHÔNG ĐƯỢC thay đổi các điều kiện kích hoạt hoặc ngưỡng kích hoạt chế độ tương thích và KHÔNG ĐƯỢC thay đổi hành vi của chính chế độ tương thích.
[7.2.1/H-0-1] PHẢI hỗ trợ các ứng dụng Trình chỉnh sửa phương thức nhập (IME) của bên thứ ba.
[7.2.3/H-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước. Hệ thống KHÔNG ĐƯỢC sử dụng các sự kiện này và CÓ THỂ được kích hoạt bên ngoài thiết bị Android (ví dụ: bàn phím phần cứng ngoài được kết nối với thiết bị Android).
[7.2.3/H-0-3] PHẢI cung cấp chức năng Màn hình chính trên tất cả màn hình tương thích với Android có cung cấp màn hình chính.
[7.2.3/H-0-4] PHẢI cung cấp chức năng Quay lại trên tất cả màn hình tương thích với Android và chức năng Gần đây trên ít nhất một màn hình tương thích với Android.
[7.2.4/H-0-1] PHẢI hỗ trợ phương thức nhập bằng màn hình cảm ứng.
[7.2.4/H-SR-1] Bạn NÊN chạy ứng dụng hỗ trợ do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService hoặc một hoạt động xử lý ACTION_ASSIST khi nhấn và giữ KEYCODE_MEDIA_PLAY_PAUSE hoặc KEYCODE_HEADSETHOOK nếu hoạt động trên nền trước không xử lý các sự kiện nhấn và giữ đó.
[7.3.1/H-SR-1] BẠN NÊN đưa gia tốc kế 3 trục vào.

Nếu việc triển khai Thiết bị cầm tay bao gồm gia tốc kế 3 trục, thì các thiết bị đó:

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

Nếu việc triển khai Thiết bị cầm tay bao gồm một bộ thu GPS/GNSS và báo cáo tính năng này cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps, thì các thiết bị đó:

[7.3.3/H-2-1] PHẢI báo cáo các phép đo GNSS ngay khi phát hiện được, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
[7.3.3/H-2-2] PHẢI báo cáo khoảng thời gian giả và tốc độ khoảng thời gian giả của GNSS, trong điều kiện bầu trời quang đãng sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét trên giây vuông, đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0, 2 mét trên giây, ít nhất là 95% thời gian.

Nếu việc triển khai Thiết bị cầm tay bao gồm con quay hồi chuyển 3 trục, thì các thiết bị đó:

[7.3.4/H-3-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
[7.3.4/H-3-2] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1000 độ mỗi giây.

Các phương thức triển khai thiết bị cầm tay có thể thực hiện cuộc gọi thoại và cho biết bất kỳ giá trị nào khác ngoài PHONE_TYPE_NONE trong getPhoneType:

[7.3.8/H] PHẢI có cảm biến tiệm cận.

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

[7.3.11/H-SR-1] NÊN hỗ trợ cảm biến tư thế với 6 bậc tự do.
[7.4.3/H] PHẢI hỗ trợ Bluetooth và Bluetooth LE.

Nếu các thiết bị hỗ trợ giao thức WiFi Neighbor Awareness Networking (NAN) bằng cách khai báo PackageManager.FEATURE_WIFI_AWARE và Vị trí Wi-Fi (Thời gian trọn vòng Wi-Fi – RTT) bằng cách khai báo PackageManager.FEATURE_WIFI_RTT, thì các thiết bị đó:

[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 Hàm phân phối tích luỹ), +/-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 WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] Bạn NÊN 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 Hàm phân phối tích luỹ), +/-2 mét ở băng thông 80 MHz ở 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 WifiRttManager#startRanging Android API.

Bạn CẦN LÀM theo các bước thiết lập tính năng đo lường được chỉ định trong phần Điều chỉnh sự hiện diện.

Bắt đầu yêu cầu mới

Nếu các hoạt động triển khai Thiết bị cầm tay khai báo FEATURE_BLUETOOTH_LE, thì các hoạt động đó:

[7.4.3/H-1-3] PHẢI đo lường và bù cho độ lệch Rx để đảm bảo RSSI BLE trung bình là -50dBm +/-15 dB ở khoảng cách 1m từ thiết bị tham chiếu truyền ở ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] PHẢI đo lường và bù cho độ lệch Tx để đảm bảo RSSI BLE trung bình là -50dBm +/-15 dB khi quét từ một thiết bị tham chiếu ở khoảng cách 1m và truyền ở ADVERTISE_TX_POWER_HIGH.

Kết thúc các yêu cầu mới

Nếu việc triển khai Thiết bị cầm tay bao gồm một thiết bị máy ảnh logic liệt kê các tính năng bằng cách sử dụng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, thì các thiết bị đó:

[7.5.4/H-1-1] PHẢI có trường nhìn (FOV) thông thường theo mặc định và PHẢI nằm trong khoảng từ 50 đến 90 độ.

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

[7.6.1/H-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").
[7.6.1/H-0-2] PHẢI trả về "true" cho ActivityManager.isLowRamDevice() khi có ít hơn 1 GB bộ nhớ cho nhân và không gian người dùng.

Nếu quá trình triển khai thiết bị cầm tay chỉ khai báo hỗ trợ ABI 32 bit:

[7.6.1/H-1-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 416 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến qHD (ví dụ: FWVGA).
[7.6.1/H-2-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 592 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến HD+ (ví dụ: HD, WSVGA).
[7.6.1/H-3-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu 896 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến FHD (ví dụ: WSXGA+).
[7.6.1/H-4-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1344 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến QHD (ví dụ: QWXGA).

Nếu việc triển khai thiết bị cầm tay khai báo hỗ trợ bất kỳ ABI 64 bit nào (có hoặc không có ABI 32 bit):

[7.6.1/H-5-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 816 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến qHD (ví dụ: FWVGA).
[7.6.1/H-6-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 944 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến HD+ (ví dụ: HD, WSVGA).
[7.6.1/H-7-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1280 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến FHD (ví dụ: WSXGA+).
[7.6.1/H-8-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1824 MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung hình lên đến QHD (ví dụ: QWXGA).

Xin lưu ý rằng "bộ nhớ có sẵn cho nhân và không gian người dùng" ở trên đề cập đến không gian bộ nhớ được cung cấp ngoài mọi bộ nhớ đã dành riêng cho các thành phần phần cứng như đài, video, v.v. không thuộc quyền kiểm soát của nhân trong quá trình triển khai thiết bị.

Nếu việc triển khai thiết bị cầm tay bao gồm bộ nhớ có dung lượng nhỏ hơn hoặc bằng 1 GB dành cho nhân và không gian người dùng, thì các thiết bị đó:

[7.6.1/H-9-1] PHẢI khai báo cờ tính năng android.hardware.ram.low.
[7.6.1/H-9-2] PHẢI có ít nhất 1,1 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").

Nếu việc triển khai thiết bị cầm tay bao gồm hơn 1 GB bộ nhớ có sẵn cho nhân và không gian người dùng, thì các thiết bị đó:

[7.6.1/H-10-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").
NÊN khai báo cờ tính năng android.hardware.ram.normal.

Nếu việc triển khai thiết bị cầm tay bao gồm bộ nhớ từ 2 GB trở lên và dưới 4 GB cho nhân và không gian người dùng, thì các thiết bị đó:

[7.6.1/H-SR-1] NÊN chỉ hỗ trợ không gian người dùng 32 bit (cả ứng dụng và mã hệ thống)

Nếu việc triển khai thiết bị cầm tay có ít hơn 2 GB bộ nhớ cho nhân và không gian người dùng, thì các thiết bị đó:

[7.6.1/H-1-1] PHẢI chỉ hỗ trợ một ABI (chỉ 64 bit hoặc chỉ 32 bit).

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

[7.6.2/H-0-1] KHÔNG ĐƯỢC cung cấp bộ nhớ dùng chung của ứng dụng nhỏ hơn 1 GiB.
[7.7.1/H] PHẢI có cổng USB hỗ trợ chế độ ngoại vi.

Nếu việc triển khai thiết bị cầm tay bao gồm một cổng USB hỗ trợ chế độ thiết bị ngoại vi, thì các thiết bị đó:

[7.7.1/H-1-1] PHẢI triển khai API Phụ kiện mở Android (AOA).

Nếu việc triển khai Thiết bị cầm tay bao gồm một cổng USB hỗ trợ chế độ máy chủ, thì các thiết bị đó:

[7.7.2/H-1-1] PHẢI triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android.

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

[7.8.1/H-0-1] PHẢI có micrô.
[7.8.2/H-0-1] PHẢI có đầu ra âm thanh và khai báo android.hardware.audio.output.

Nếu việc triển khai thiết bị cầm tay có thể đáp ứng tất cả các yêu cầu về hiệu suất để hỗ trợ chế độ VR và hỗ trợ chế độ này, thì các thiết bị đó:

[7.9.1/H-1-1] BẮT BUỘC khai báo cờ tính năng android.hardware.vr.high_performance.
[7.9.1/H-1-2] PHẢI bao gồm một ứng dụng triển khai android.service.vr.VrListenerService mà các ứng dụng VR có thể bật thông qua android.app.Activity#setVrModeEnabled.

Nếu việc triển khai Thiết bị cầm tay bao gồm một hoặc nhiều cổng USB-C ở chế độ máy chủ và triển khai (lớp âm thanh USB), ngoài các yêu cầu trong mục 7.7.2, thì các cổng đó:

[7.8.2.2/H-1-1] PHẢI cung cấp bản đồ phần mềm sau đây của các mã HID:

Chức năng	Ánh xạ	Ngữ cảnh	Hành vi
A	Trang sử dụng HID: 0x0C Sử dụng HID: 0x0CD Khoá hạt nhân: `KEY_PLAYPAUSE` Khoá Android: `KEYCODE_MEDIA_PLAY_PAUSE`	Phát lại phương tiện	Đầu vào: Nhấn ngắn Đầu ra: Phát hoặc tạm dừng
		Phát lại phương tiện	Đầu vào: Nhấn và giữ Đầu ra: Chạy lệnh thoại Gửi: `android.speech.action.VOICE_SEARCH_HANDS_FREE` nếu thiết bị bị khoá hoặc màn hình tắt. Gửi `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` nếu không
		Cuộc gọi đến	Đầu vào: Nhấn ngắn Đầu ra: Chấp nhận cuộc gọi
		Cuộc gọi đến	Đầu vào: Nhấn và giữ Kết quả: Từ chối cuộc gọi
		Cuộc gọi đang diễn ra	Đầu vào: Nhấn ngắn Đầu ra: Kết thúc cuộc gọi
		Cuộc gọi đang diễn ra	Đầu vào: Nhấn và giữ Đầu ra: Tắt hoặc bật micrô
B	Trang sử dụng HID: 0x0C Mức sử dụng HID: 0x0E9 Khoá hạt nhân: `KEY_VOLUMEUP` Khoá Android: `VOLUME_UP`	Phát nội dung nghe nhìn, Cuộc gọi đang diễn ra	Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Tăng âm lượng của hệ thống hoặc tai nghe
C	Trang sử dụng HID: 0x0C Mức sử dụng HID: 0x0EA Khoá hạt nhân: `KEY_VOLUMEDOWN` Khoá Android: `VOLUME_DOWN`	Phát nội dung nghe nhìn, Cuộc gọi đang diễn ra	Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Giảm âm lượng của hệ thống hoặc tai nghe
D	Trang sử dụng HID: 0x0C Sử dụng HID: 0x0CF Khoá hạt nhân: `KEY_VOICECOMMAND` Khoá Android: `KEYCODE_VOICE_ASSIST`	Tất cả. Có thể được kích hoạt trong bất kỳ thực thể nào.	Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Chạy lệnh thoại

[7.8.2.2/H-1-2] PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm phích cắm, nhưng chỉ sau khi các giao diện âm thanh USB và điểm cuối được liệt kê đúng cách để xác định loại thiết bị đầu cuối được kết nối.

Khi phát hiện loại thiết bị đầu cuối âm thanh USB 0x0302, các thiết bị này sẽ:

[7.8.2.2/H-2-1] PHẢI truyền Intent ACTION_HEADSET_PLUG với "microphone" bổ sung được đặt thành 0.

Khi phát hiện loại thiết bị đầu cuối âm thanh USB 0x0402, các thiết bị này sẽ:

[7.8.2.2/H-3-1] PHẢI truyền phát Ý định ACTION_HEADSET_PLUG với "microphone" bổ sung được đặt thành 1.

Khi API AudioManager.getDevices() được gọi trong khi thiết bị ngoại vi USB được kết nối, các API này sẽ:

[7.8.2.2/H-4-1] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò là isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0302.
[7.8.2.2/H-4-2] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.
[7.8.2.2/H-4-3] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.
[7.8.2.2/H-4-4] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò là isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x603.
[7.8.2.2/H-4-5] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x604.
[7.8.2.2/H-4-6] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.
[7.8.2.2/H-4-7] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.
[7.8.2.2/H-SR-1] Bạn NÊN thực hiện việc liệt kê các mô tả USB, xác định loại thiết bị đầu cuối và truyền tin về Ý định ACTION_HEADSET_PLUG trong vòng chưa đến 1000 mili giây sau khi kết nối thiết bị ngoại vi âm thanh USB-C.

Nếu các hoạt động triển khai Thiết bị cầm tay khai báo android.hardware.audio.output và android.hardware.microphone, thì các hoạt động đó:

[5.6/H-1-1] PHẢI có độ trễ trung bình liên tục của một vòng là 300 mili giây trở xuống trong 5 lần đ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ô", bộ chuyển đổi vòng lặp 3,5 mm (nếu được hỗ trợ), USB vòng lặp (nếu được hỗ trợ).
[5.6/H-1-2] PHẢI có độ trễ trung bình của tính năng Nhấn để phát âm là 300 mili giây trở xuống trong ít nhất 5 lần đo lường trên đườ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ì các thiết bị đó:

[7.10/H]* KHÔNG ĐƯỢC sử dụng bộ truyền động xúc giác (máy rung) có khối lượng quay lệch tâm (ERM).

[7.10/H]* NÊN triển khai tất cả hằng số công khai cho cảm ứng 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ả hằng số công khai cho tính năng 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ả hằng số PRIMITIVE_* công khai khả thi cho tính năng haptics 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ố loại dữ liệu gốc này, chẳng hạn như LOW_TICK và SPIN, có thể chỉ 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 liên kết 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]* PHẢI tuân theo quy trình đánh giá chất lượng cho các API createOneShot() và createWaveform().

[7.10/H]* PHẢI 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 chức 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à người dùng thường cầm hoặc chạm vào thiết bị.

Bộ truyền động cộng hưởng tuyến tính (LRA) là một hệ thống lò xo một khối lượng có tần số cộng hưởng chính, trong đó khối lượng dịch chuyển theo hướng chuyển động mong muốn.

Nếu quá trình triển khai Thiết bị cầm tay bao gồm ít nhất một công cụ kích hoạt cộng hưởng tuyến tính 7.10 dùng cho nhiều mục đích, thì các thiết bị đó:

Bắt đầu yêu cầu mới

[7.10/H] NÊN đặt vị trí của bộ truyền động gần vị trí mà người dùng thường cầm hoặc chạm vào thiết bị.

Kết thúc các yêu cầu mới

[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 ~~tự nhiên~~ của thiết bị.

Nếu các hoạt động triển khai Thiết bị cầm tay có một bộ truyền động xúc giác dùng cho nhiều mục đích là bộ truyền động cộng hưởng tuyến tính theo trục X (LRA), thì các hoạt động đó:

[7.10/H] BAN PHẢI có tần số cộng hưởng của LRA trục X dưới 200 Hz.

Nếu việc triển khai thiết bị cầm tay tuân theo việc liên kết hằng số xúc giác, thì các thiết bị đó:

[7.10/H]* NÊN xác minh trạng thái triển khai bằng cách chạy API android.os.Vibrator.areAllEffectsSupported() và android.os.Vibrator.arePrimitivesSupported().
[7.10/H]* NÊN thực hiện đánh giá chất lượng cho các hằng số xúc giá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 loại dữ liệu gốc không được hỗ trợ như mô tả trong hướng dẫn triển khai cho các hằng số.

2.2.2. Đa phương tiện

Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

[5.1/H-0-1] AMR-NB
[5.1/H-0-2] AMR-WB
[5.1/H-0-3] Hồ sơ MPEG-4 AAC (AAC LC)
[5.1/H-0-4] Hồ sơ MPEG-4 HE AAC (AAC+)
[5.1/H-0-5] AAC ELD (AAC độ trễ thấp nâng cao)

Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

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

Bắt đầu yêu cầu mới

[5.2/H-0-3] AV1

Kết thúc các yêu cầu mới

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 đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

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

Bắt đầu yêu cầu mới

[5.3/H-0-6] AV1

Kết thúc các yêu cầu mới

2.2.3. Phần mềm

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

[3.2.3.1/H-0-1] PHẢI có một ứng dụng xử lý các ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE và ACTION_CREATE_DOCUMENT như mô tả trong tài liệu SDK, đồng thời cung cấp cho người dùng khả năng truy cập vào dữ liệu của nhà cung cấp tài liệu bằng cách sử dụng API DocumentsProvider.
[3.2.3.1/H-0-2]* PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, đối với tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
[3.2.3.1/H-SR-1] Bạn NÊN tải trước một ứng dụng email có thể xử lý ý định ACTION_SENDTO hoặc ACTION_SEND hoặc ACTION_SEND_MULTIPLE để gửi email.
[3.4.1/H-0-1] PHẢI cung cấp cách triển khai đầy đủ API android.webkit.Webview.
[3.4.2/H-0-1] PHẢI có một ứng dụng Trình duyệt độc lập để người dùng duyệt web thông thường.
[3.8.1/H-SR-1] Bạn NÊN triển khai trình chạy mặc định hỗ trợ ghim lối tắt, tiện ích và widgetFeatures trong ứng dụng.
[3.8.1/H-SR-2] Bạn NÊN triển khai một trình chạy mặc định để truy cập nhanh vào các lối tắt bổ sung do các ứng dụng bên thứ ba cung cấp thông qua API ShortcutManager.
[3.8.1/H-SR-3] Bạn NÊN đưa vào một ứng dụng trình chạy mặc định hiển thị huy hiệu cho các biểu tượng ứng dụng.
[3.8.2/H-SR-1] NÊN hỗ trợ các tiện ích ứng dụng của bên thứ ba.
[3.8.3/H-0-1] PHẢI cho phép các ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý thông qua các lớp API Notification và NotificationManager.
[3.8.3/H-0-2] PHẢI hỗ trợ thông báo đa dạng thức.
[3.8.3/H-0-3] PHẢI hỗ trợ thông báo quan trọng.
[3.8.3/H-0-4] PHẢI có ngăn thông báo, cho phép người dùng trực tiếp kiểm soát (ví dụ: trả lời, tạm ngưng, đóng, chặn) thông báo thông qua các tính năng hỗ trợ người dùng như nút hành động hoặc bảng điều khiển được triển khai trong AOSP.
[3.8.3/H-0-5] PHẢI hiển thị các lựa chọn được cung cấp thông qua RemoteInput.Builder setChoices() trong ngăn thông báo.
[3.8.3/H-SR-1] Bạn NÊN hiển thị lựa chọn đầu tiên được cung cấp thông qua RemoteInput.Builder setChoices() trong ngăn thông báo mà không cần người dùng tương tác thêm.
[3.8.3/H-SR-2] NÊN hiển thị tất cả các lựa chọn được cung cấp thông qua RemoteInput.Builder setChoices() trong ngăn thông báo khi người dùng mở rộng tất cả thông báo trong ngăn thông báo.
[3.8.3.1/H-SR-1] Bạn NÊN hiển thị các thao tác mà Notification.Action.Builder.setContextual được đặt thành true cùng dòng với các câu trả lời do Notification.Remoteinput.Builder.setChoices hiển thị.
[3.8.4/H-SR-1] Bạn NÊN triển khai một trợ lý trên thiết bị để xử lý Thao tác hỗ trợ.

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

[3.8.3.1/H-SR-2] NÊN cung cấp một chức năng cho người dùng (ví dụ: trình chuyển đổi đầu ra) 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 nội dung nghe nhìn có sẵn phù hợp (ví dụ: thiết bị Bluetooth và tuyến được cung cấp cho MediaRouter2Manager) khi một ứng dụng đăng thông báo MediaStyle có mã thông báo MediaSession.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị bao gồm cả 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 thay đổi giao diện, thì các thiết bị đó:

[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 một trình đơn cài đặt để bật/tắt tính năng này.

Kết thúc các yêu cầu mới

Nếu các phương thức triển khai Thiết bị cầm tay hỗ trợ Thao tác hỗ trợ, thì các phương thức đó:

[3.8.4/H-SR-2] Bạn NÊN sử dụng thao tác nhấn và giữ phím HOME làm thao tác tương tác được chỉ định để chạy ứng dụng hỗ trợ như mô tả trong mục 7.2.3. PHẢI chạy ứng dụng hỗ trợ do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService hoặc một hoạt động xử lý ý định ACTION_ASSIST.

Nếu việc triển khai Thiết bị cầm tay hỗ trợ conversation notifications và nhóm các thông báo đó vào một phần riêng biệt với thông báo cảnh báo và thông báo không phải cuộc trò chuyện ở chế độ im lặng, thì các thông báo đó sẽ:

[3.8.4/H-1-1]* PHẢI hiển thị thông báo cuộc trò chuyện trước thông báo không phải cuộc trò chuyện, ngoại trừ thông báo dịch vụ trên nền trước đang diễn ra và thông báo importance:high.

Nếu việc triển khai thiết bị cầm tay Android hỗ trợ màn hình khoá, thì các thiết bị đó:

[3.8.10/H-1-1] PHẢI hiển thị Thông báo trên màn hình khoá, bao gồm cả Mẫu thông báo đa phương tiện.

Nếu việc triển khai thiết bị cầm tay hỗ trợ màn hình khoá bảo mật, thì các thiết bị đó:

[3.9/H-1-1] PHẢI triển khai toàn bộ các chính sách về việc quản trị thiết bị được xác định trong tài liệu SDK Android.

Nếu việc triển khai thiết bị cầm tay bao gồm hỗ trợ cho các API ControlsProviderService và Control, đồng thời cho phép các ứng dụng bên thứ ba phát hành các chế độ điều khiển thiết bị, thì các API đó:

[3.8.16/H-1-1] PHẢI khai báo cờ tính năng android.software.controls và đặt cờ này thành true.
[3.8.16/H-1-2] PHẢI cung cấp cho người dùng khả năng thêm, chỉnh sửa, chọn và vận hành các chế độ điều khiển thiết bị yêu thích của người dùng từ các chế độ điều khiển do ứng dụng bên thứ ba đăng ký thông qua ControlsProviderService và API Control.
[3.8.16/H-1-3] PHẢI cung cấp quyền truy cập vào tính năng hỗ trợ người dùng này trong vòng 3 lượt tương tác từ Trình chạy mặc định.
[3.8.16/H-1-4] PHẢI hiển thị chính xác tên và biểu tượng của từng ứng dụng bên thứ ba cung cấp các chế độ điều khiển thông qua API ControlsProviderService cũng như mọi trường được chỉ định do các API Control cung cấp trong chức năng hỗ trợ người dùng này.
[3.8.16/H-1-5] PHẢI cung cấp cho người dùng khả năng chọn không sử dụng các chế độ kiểm soát thiết bị không quan trọng về việc xác thực do ứng dụng chỉ định từ các chế độ kiểm soát do ứng dụng bên thứ ba đăng ký thông qua ControlsProviderService và API Control Control.isAuthRequired.

Bắt đầu yêu cầu mới

[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 tương tác của người dùng như sau:
- Nếu thiết bị đã đặt config_supportsMultiWindow=true và ứng dụng khai báo siêu dữ liệu META_DATA_PANEL_ACTIVITY trong phần khai báo ControlsProviderService, bao gồm cả ComponentName của một hoạt động hợp lệ (do API xác định), thì ứng dụng PHẢI nhúng hoạt động đó vào khả năng hỗ trợ người dùng này.
- Nếu không khai báo siêu dữ liệu META_DATA_PANEL_ACTIVITY, thì ứng dụng PHẢI hiển thị các trường được chỉ định do API ControlsProviderService cung cấp cũng như mọi trường được chỉ định do API Control cung cấp.
[3.8.16/H-1-7] Nếu ứng dụng khai báo siêu dữ liệu META_DATA_PANEL_ACTIVITY, thì ứng dụng PHẢI truyền giá trị của chế độ cài đặt được xác định trong [3.8.16/H-1-5] bằng cách sử dụng EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS khi khởi chạy hoạt động được nhúng.

Kết thúc các yêu cầu mới

Ngược lại, nếu việc triển khai thiết bị cầm tay không triển khai các chế độ kiểm soát như vậy, thì:

[3.8.16/H-2-1] PHẢI báo cáo null cho các API ControlsProviderService và Control.
[3.8.16/H-2-2] PHẢI khai báo cờ tính năng android.software.controls và đặt cờ này thành false.

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

[3.8.17/H-1-1] PHẢI hiển thị thông báo xác nhận cho người dùng rằng dữ liệu đã được sao chép vào bảng nhớ tạm (ví dụ: hình thu nhỏ hoặc cảnh báo "Nội dung đã sao chép"). Ngoài ra, hãy đưa vào đây thông tin cho biết liệu dữ liệu bảng nhớ tạm có được đồng bộ hoá trên các thiết bị hay không.

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

[3.10/H-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
[3.10/H-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của TalkBack và Tiếp cận bằng công tắc (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.
[3.11/H-0-1] PHẢI hỗ trợ việc cài đặt các công cụ TTS của bên thứ ba.
[3.11/H-SR-1] Bạn NÊN đưa một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị vào.
[3.13/H-SR-1] Bạn NÊN đưa thành phần giao diện người dùng Cài đặt nhanh vào.

Nếu việc triển khai thiết bị cầm tay Android khai báo hỗ trợ FEATURE_BLUETOOTH hoặc FEATURE_WIFI, thì các thiết bị đó:

[3.16/H-1-1] PHẢI hỗ trợ tính năng ghép nối thiết bị đồng hành.

Nếu hàm điều hướng được cung cấp dưới dạng một thao tác trên màn hình, dựa trên cử chỉ:

[7.2.3/H] Khu vực nhận dạng cử chỉ cho chức năng Trang chủ PHẢI có chiều cao không quá 32 dp tính từ cuối màn hình.

Nếu việc triển khai thiết bị cầm tay cung cấp một chức năng điều hướng dưới dạng cử chỉ từ bất kỳ vị trí nào trên cạnh trái và phải của màn hình:

[7.2.3/H-0-1] Chiều rộng của khu vực cử chỉ của hàm điều hướng PHẢI nhỏ hơn 40 dp ở mỗi bên. Theo mặc định, chiều rộng của vùng cử chỉ PHẢI là 24 dp.

Nếu việc triển khai thiết bị cầm tay hỗ trợ màn hình khoá bảo mật và có bộ nhớ lớn hơn hoặc bằng 2 GB cho hạt nhân và không gian người dùng, thì các thiết bị đó:

[3.9/H-1-2] PHẢI khai báo tính năng hỗ trợ hồ sơ được quản lý thông qua cờ tính năng android.software.managed_users.

Nếu các hoạt động triển khai thiết bị cầm tay Android khai báo tính năng hỗ trợ máy ảnh thông qua android.hardware.camera.any, thì các hoạt động đó:

[7.5.4/H-1-1] PHẢI tuân thủ ý định android.media.action.STILL_IMAGE_CAMERA và android.media.action.STILL_IMAGE_CAMERA_SECURE và khởi chạy máy ảnh ở chế độ ảnh tĩnh như mô tả trong SDK.
[7.5.4/H-1-2] PHẢI tuân thủ ý định android.media.action.VIDEO_CAMERA để chạy máy ảnh ở chế độ video như mô tả trong SDK.

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

[3.2.3.1/ H-1-1] PHẢI có một hoạt động xử lý ý định Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY khi chức năng phân tách đang bật. Hoạt động PHẢI được bảo vệ bằng android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK và PHẢI bắt đầu hoạt động của Ý định được phân tích cú pháp từ Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị cho phép người dùng thực hiện cuộc gọi bất kỳ, thì 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 khung viễn thông.

Kết thúc các yêu cầu mới

2.2.4. Hiệu suất và nguồn điện

[8.1/H-0-1] Độ trễ khung hình nhất quán. Độ trễ khung hình không nhất quán hoặc độ trễ khi kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình/giây và PHẢI dưới 1 khung hình/giây.
[8.1/H-0-2] Độ trễ giao diện người dùng. Việc triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách gồm 10.000 mục danh sách theo định nghĩa của Bộ kiểm thử tính tương thích với Android (CTS) trong vòng chưa đến 36 giây.
[8.1/H-0-3] Chuyển đổi tác vụ. Khi nhiều ứng dụng đã được khởi chạy, việc khởi chạy lại một ứng dụng đang chạy sau khi ứng dụng đó đã được khởi chạy PHẢI mất ít hơn 1 giây.

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

[8.2/H-0-1] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 5 MB/giây.
[8.2/H-0-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 0,5 MB/giây.
[8.2/H-0-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 15 MB/giây.
[8.2/H-0-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu là 3,5 MB/giây.

Nếu việc triển khai Thiết bị cầm tay bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị có trong AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

[8.3/H-1-1] PHẢI cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.
[8.3/H-1-2] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ tiết kiệm pin Chế độ chờ ứng dụng và Nghỉ.

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

[8.4/H-0-1] PHẢI cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức hao pin ước tính do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android.
[8.4/H-0-2] PHẢI báo cáo tất cả giá trị tiêu thụ điện năng bằng miliampe giờ (mAh).
[8.4/H-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. Dự án nguồn mở Android đáp ứng yêu cầu thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/H-0-4] PHẢI cung cấp mức sử dụng năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.
[8,4/giờ] NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.

Nếu việc triển khai Thiết bị cầm tay bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[8.4/H-1-1] PHẢI tuân thủ ý định android.intent.action.POWER_USAGE_SUMMARY và hiển thị trình đơn cài đặt cho biết mức sử dụng nguồn này.

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

[8.5/H-0-1] PHẢI cung cấp một chức năng cho người dùng ~~trong trình đơn Cài đặt~~ để xem tất 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 khởi tạo, bao gồm cả thời lượng của từng dịch vụ này kể từ khi bắt đầu như mô tả trong tài liệu SDK. ~~và khả năng dừng một ứ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 khởi tạo.~~
với khả năng dừng một ứng dụng đang chạy dịch vụ trên nền trước và hiển thị tất cả ứng dụng có dịch vụ trên 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 bắt đầu như mô tả trong tài liệu SDK.

Một số ứng dụng CÓ THỂ được miễn bị dừng hoặc được liệt kê trong một tính năng hỗ trợ người dùng như vậy như mô tả trong tài liệu SDK.

Bắt đầu yêu cầu mới

[8.5/H-0-2]PHẢI cung cấp cho người dùng khả năng dừng một ứ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 khởi tạo.

Kết thúc các yêu cầu mới

2.2.5. Mô hình bảo mật

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

[9/H-0-1] BẮT BUỘC phải khai báo tính năng android.hardware.security.model.compatible.
[9.1/H-0-1] PHẢI cho phép ứng dụng bên thứ ba truy cập vào số liệu thống kê về mức sử dụng thông qua quyền android.permission.PACKAGE_USAGE_STATS và cung cấp cơ chế mà người dùng có thể truy cập để cấp hoặc thu hồi quyền truy cập vào các ứng dụng đó nhằm phản hồi ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Bắt đầu yêu cầu mới

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ android.hardware.telephony, thì các hoạt động đó:

[9.5/H-1-1] KHÔNG ĐƯỢC đặt UserManager.isHeadlessSystemUserMode thành true.

Kết thúc các yêu cầu mới

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

[9.11/H-0-2] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
[9.11/H-0-3] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và trên đó. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) thượng nguồn đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một phương thức triển khai bảo mật được bên thứ ba xem xét về việc tách biệt dựa trên trình điều khiển ảo hoá thích hợp là các lựa chọn thay thế.
[9.11/H-0-4] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi tách biệt và chỉ khi xác thực thành công, mới cho phép sử dụng các khoá liên kết với quy trình xác thực. Bạn PHẢI lưu trữ thông tin xác thực màn hình khoá theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện xác thực màn hình khoá. Dự án nguồn mở Android thượng nguồn cung cấp Lớp trừu tượng phần cứng của Gatekeeper (HAL) và Trusty, có thể được dùng để đáp ứng yêu cầu này.
[9.11/H-0-5] PHẢI hỗ trợ chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quá trình ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI được chia sẻ trên số lượng thiết bị đủ lớn để ngăn việc sử dụng khoá làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu sản xuất hơn 100.000 đơn vị của một SKU, bạn CÓ THỂ sử dụng một khoá khác nhau cho mỗi 100.000 đơn vị.

Xin lưu ý rằng nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ, thì thiết bị đó sẽ được miễn yêu cầu phải có kho khoá được hỗ trợ bởi một môi trường thực thi riêng biệt và hỗ trợ tính năng chứng thực khoá, trừ phi thiết bị đó khai báo tính năng android.hardware.fingerprint yêu cầu kho khoá được hỗ trợ bởi một môi trường thực thi riêng biệt.

Khi triển khai thiết bị cầm tay hỗ trợ màn hình khoá bảo mật, các thiết bị đó:

[9.11/H-1-1] PHẢI cho phép người dùng chọn thời gian chờ ngắn nhất khi chuyển sang trạng thái ngủ, tức là thời gian chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, trong vòng 15 giây trở xuống.
[9.11/H-1-2] PHẢI cung cấp cho người dùng khả năng ẩn thông báo và tắt tất cả các hình thức xác thực, ngoại trừ xác thực chính được mô tả trong 9.11.1 Màn hình khoá an toàn. AOSP đáp ứng yêu cầu về chế độ khoá.

Bắt đầu yêu cầu mới

Nếu các phương thức triển khai thiết bị có màn hình khoá bảo mật 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ì các phương thức đó:

[9.11.1/H-1-1] PHẢI yêu cầu 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ở khoá, mật khẩu) thường xuyên hơn một lần mỗi 72 giờ.

Kết thúc các yêu cầu mới

Nếu việc triển khai Thiết bị cầm tay bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/H-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các chức năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.

Nếu việc triển khai Thiết bị cầm tay bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/H-3-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để cho phép /tắt người dùng khác truy cập vào cuộc gọi thoại và SMS.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị cầm tay đặt UserManager.isHeadlessSystemUserMode thành true, thì

[9.5/H-4-1] KHÔNG ĐƯỢC hỗ trợ eUICC hoặc eSIM có chức năng gọi điện.
[9.5/H-4-2] KHÔNG ĐƯỢC khai báo hỗ trợ cho android.hardware.telephony.

Kết thúc các yêu cầu mới

Android, thông qua API Hệ thống VoiceInteractionService, hỗ trợ một cơ chế phát hiện từ khoá kích hoạt luôn bật một cách an toàn mà không cần chỉ báo truy cập micrô và phát hiện truy vấn luôn bật mà không cần chỉ báo truy cập micrô hoặc máy ảnh.

Nếu việc triển khai Thiết bị cầm tay hỗ trợ API hệ thống HotwordDetectionService hoặc một cơ chế khác để phát hiện cụm từ kích hoạt mà không có chỉ báo truy cập micrô, thì các thiết bị đó:

[9.8/H-1-1] PHẢI đảm bảo rằng dịch vụ phát hiện cụm từ kích hoạt chỉ có thể truyền dữ liệu đến Hệ thống, ContentCaptureService, hoặc dịch vụ nhận dạng lời nói trên thiết bị do SpeechRecognizer#createOnDeviceSpeechRecognizer() tạo.
[9.8/H-1-2] PHẢI đảm bảo rằng dịch vụ phát hiện cụm từ kích hoạt chỉ có thể truyền dữ liệu âm thanh của micrô hoặc dữ liệu bắt nguồn từ micrô đó đến máy chủ hệ thống thông qua API HotwordDetectionService hoặc đến ContentCaptureService thông qua API ContentCaptureManager.
[9.8/H-1-3] KHÔNG ĐƯỢC cung cấp âm thanh micrô dài hơn 30 giây cho một yêu cầu kích hoạt bằng phần cứng riêng lẻ cho dịch vụ phát hiện cụm từ kích hoạt.
[9.8/H-1-4] KHÔNG ĐƯỢC cung cấp âm thanh micrô được lưu vào bộ đệm cũ hơn 8 giây cho một yêu cầu riêng lẻ đến dịch vụ phát hiện từ khoá.
[9.8/H-1-5] KHÔNG ĐƯỢC cung cấp âm thanh micrô được lưu vào bộ đệm lâu hơn 30 giây cho dịch vụ tương tác bằng giọng nói hoặc thực thể tương tự.
[9.8/H-1-6] KHÔNG ĐƯỢC cho phép truyền nhiều hơn 100 byte dữ liệu qua dịch vụ phát hiện cụm từ kích hoạt trên mỗi kết quả cụm từ kích hoạt thành công ngoại trừ dữ liệu âm thanh được truyền qua HotwordAudioStream.
[9.8/H-1-7] KHÔNG ĐƯỢC cho phép truyền nhiều hơn 5 bit dữ liệu ra khỏi dịch vụ phát hiện cụm từ kích hoạt trên mỗi kết quả cụm từ kích hoạt âm tính.
[9.8/H-1-8] PHẢI chỉ cho phép truyền dữ liệu ra khỏi dịch vụ phát hiện cụm từ kích hoạt theo yêu cầu xác thực cụm từ kích hoạt từ máy chủ hệ thống.
[9.8/H-1-9] KHÔNG ĐƯỢC cho phép ứng dụng mà người dùng có thể cài đặt cung cấp dịch vụ phát hiện cụm từ kích hoạt.
[9.8/H-1-10] KHÔNG ĐƯỢC hiển thị trong dữ liệu định lượng trên giao diện người dùng về việc sử dụng micrô của dịch vụ phát hiện từ khoá kích hoạt.
[9.8/H-1-11] PHẢI ghi lại số byte có trong mỗi lần truyền từ dịch vụ phát hiện cụm từ kích hoạt để cho phép các nhà nghiên cứu bảo mật kiểm tra.
[9.8/H-1-12] PHẢI hỗ trợ chế độ gỡ lỗi ghi lại nội dung thô của mọi lượt truyền từ dịch vụ phát hiện cụm từ kích hoạt để cho phép các nhà nghiên cứu bảo mật kiểm tra.
[9.8/H-1-14] PHẢI hiển thị chỉ báo micrô, như mô tả trong phần 9.8.2, khi kết quả cụm từ kích hoạt thành công được truyền đến dịch vụ tương tác bằng giọng nói hoặc thực thể tương tự.

Bắt đầu yêu cầu mới

[9.8/H-1-15] PHẢI đảm bảo rằng các luồng âm thanh được cung cấp trên kết quả cụm từ kích hoạt thành công được truyền một chiều từ dịch vụ phát hiện cụm từ kích hoạt đến dịch vụ tương tác bằng giọng nói.

Kết thúc các yêu cầu mới

[9.8/H-SR-1] Bạn NÊN thông báo cho người dùng trước khi đặt một ứng dụng làm nhà cung cấp dịch vụ phát hiện cụm từ kích hoạt.
[9.8/H-SR-2] KHUYẾN CÁO KHÔNG được truyền dữ liệu không có cấu trúc ra khỏi dịch vụ phát hiện cụm từ kích hoạt.
[9.8/H-SR-3] Bạn NÊN khởi động lại quy trình lưu trữ dịch vụ phát hiện cụm từ kích hoạt í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, tuỳ theo thời điểm nào đến trước.

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng sử dụng API hệ thống HotwordDetectionService hoặc cơ chế tương tự để phát hiện cụm từ kích hoạt mà không có chỉ báo sử dụng micrô, thì ứng dụng đó:

[9.8/H-2-1] PHẢI thông báo rõ ràng cho người dùng về từng cụm từ kích hoạt được hỗ trợ.
[9.8/H-2-2] KHÔNG ĐƯỢC lưu giữ dữ liệu âm thanh thô hoặc dữ liệu bắt nguồn từ dữ liệu âm thanh thô đó thông qua dịch vụ phát hiện cụm từ kích hoạt.
[9.8/H-2-3] KHÔNG ĐƯỢC truyền từ dịch vụ phát hiện cụm từ kích hoạt, dữ liệu âm thanh, dữ liệu có thể dùng để tái tạo (một phần hoặc toàn bộ) âm thanh hoặc nội dung âm thanh không liên quan đến cụm từ kích hoạt, ngoại trừ ContentCaptureService hoặc dịch vụ nhận dạng lời nói trên thiết bị.

Bắt đầu yêu cầu mới

Nếu các hoạt động triển khai Thiết bị cầm tay hỗ trợ API Hệ thống VisualQueryDetectionService hoặc một cơ chế khác để phát hiện truy vấn mà không có chỉ báo truy cập vào micrô và/hoặc máy ảnh, thì các hoạt độ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 đến Hệ thống, ContentCaptureService hoặc dịch vụ nhận dạng lời nói trên thiết bị (do SpeechRecognizer#createOnDeviceSpeechRecognizer() tạo).
[9.8/H-3-2] KHÔNG ĐƯỢC cho phép truyền bất kỳ thông tin âm thanh hoặc video nào ra khỏi VisualQueryDetectionService, ngoại trừ ContentCaptureService hoặc dịch vụ nhận dạng lời nói trên thiết bị.
[9.8/H-3-3] PHẢI hiển thị thông báo cho người dùng trong giao diện người dùng hệ thống khi thiết bị phát hiện ý định của người dùng tương tác 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 thông qua máy ảnh).
[9.8/H-3-4] PHẢI hiển thị chỉ báo micrô và hiển thị cụm từ tìm kiếm của người dùng đã phát hiện trong giao diện người dùng ngay sau khi phát hiện cụm từ tìm kiếm của người dùng.
[9.8/H-3-5] KHÔNG ĐƯỢC cho phép ứng dụng mà người dùng có thể cài đặt cung cấp dịch vụ phát hiện truy vấn hình ảnh.

Kết thúc các yêu cầu mới

Nếu các hoạt động triển khai Thiết bị cầm tay khai báo android.hardware.microphone, thì các hoạt động đó:

[9.8.2/H-4-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService hoặc các ứng dụng giữ vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X].
[9.8.2/H-4-2] PHẢI hiển thị danh sách các ứng dụng Gần đây và Đang hoạt động sử dụng micrô như được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.

Nếu các hoạt động triển khai Thiết bị cầm tay khai báo android.hardware.camera.any, thì các hoạt động đó:

[9.8.2/H-5-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không được hiển thị khi máy ảnh chỉ được(các) ứng dụng có vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X].
[9.8.2/H-5-2] PHẢI hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng camera được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.

2.2.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển

Triển khai thiết bị cầm tay (* Không áp dụng cho máy tính bảng):

[6.1/H-0-1]* PHẢI hỗ trợ lệnh shell cmd testharness.

Triển khai thiết bị cầm tay (* Không áp dụng cho máy tính bảng):

Perfetto
- [6.1/H-0-2]* PHẢI hiển thị tệp nhị phân /system/bin/perfetto cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto.
- [6.1/H-0-3]* Tệp nhị phân perfetto PHẢI chấp nhận cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/H-0-4]* Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/H-0-5]* PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [6.1/H-0-6]* Theo mặc định, bạn PHẢI bật trình nền theo dõi perfetto (thuộc tính hệ thống persist.traced.enable).

2.2.7. Lớp học về hiệu suất nội dung đa phương tiện trên thiết bị cầm tay

Xem Mục 7.11 để biết định nghĩa về lớp hiệu suất nội dung nghe nhìn.

2.2.7.1. Nội dung nghe nhìn

Nếu các phương thứ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ì các phương thức đó:

PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn được liệt kê trong phần 2.2.7.1 của CDD Android 13.

Bắt đầu yêu cầu mới

Nếu các phương thứ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ì các phương thức đó:

[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ỳ tổ hợp bộ mã hoá và giải mã 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 bộ giải mã video phần cứng 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên bản ở độ phân giải 1080p@30 khung hình/giây và 3 phiên bản ở độ phân giải 4K@30 khung hình/giây. Bạn chỉ cần hỗ trợ độ phân giải 1080p cho bộ mã hoá và giải mã AV1, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 1080p30fps.
[5.1/H-1-3] PHẢI quảng cáo số lượng phiên mã hoá video phần cứng tối đa có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã 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 mã hoá video phần cứng 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào 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@30 khung hình/giây. Bạn chỉ cần hỗ trợ độ phân giải 1080p cho bộ mã hoá và giải mã AV1, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 1080p30fps.
[5.1/H-1-5] PHẢI quảng cáo số lượng tối đa phiên mã và giải mã video phần cứng có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã nào 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 bản bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên bản ở độ phân giải 4K@30fps, trong đó tối đa 2 phiên bản là phiên bản bộ mã hoá và 3 phiên bản ở độ phân giải 1080p. Bạn chỉ cần hỗ trợ độ phân giải 1080p cho bộ mã hoá và giải mã AV1, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 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 bản bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời ở độ phân giải 4K@30fps, trong đó tối đa 1 phiên bản là phiên bản bộ mã hoá, có thể được định cấu hình ở định dạng đầu vào RGBA_1010102 thông qua một bề mặt GL. Bạn không bắt buộc phải tạo siêu dữ liệu HDR bằng bộ mã hoá nếu mã hoá từ nền tảng GL. Các phiên bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này là 4K.
[5.1/H-1-7] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 40 mili giây trở xuống đối với phiên mã hoá video 1080p trở xuống cho tất cả bộ mã hoá video phần cứng khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy tính năng quay video và âm thanh 1080p. Đối với bộ mã hoá và giải mã Dolby Vision, độ trễ khởi chạy bộ mã hoá và giải mã PHẢI là 50 mili giây trở xuống.
[5.1/H-1-8] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 30 mili giây trở xuống đối với phiên mã hoá âm thanh có tốc độ bit từ 128 kb/giây trở xuống cho tất cả bộ mã hoá âm thanh khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy tính năng quay video và âm thanh 1080p.
[5.1/H-1-9] PHẢI hỗ trợ 2 phiên giải mã video phần cứng bảo mật (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời ở độ phân giải 1080p@30 khung hình/giây cho cả nội dung 8 bit (SDR) và 10 bit HDR.
[5.1/H-1-10] PHẢI hỗ trợ 3 phiên bản bộ giải mã video phần cứng không bảo mật cùng với 1 phiên bản bộ 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ỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên bản ở độ phân giải 4K@30 khung hình/giây, bao gồm một phiên bản bộ giải mã bảo mật và 1 phiên bản không bảo mật ở độ phân giải 1080p@30 khung hình/giây, trong đó tối đa 2 phiên bản có thể ở định dạng HDR 10 bit. Các phiên bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này là 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 chạy bộ mã hoá và giải mã là 40 mili giây trở xuống cho phiên giải mã video 1080p trở xuống cho tất cả bộ giải mã video phần cứng khi đang tải. Tải ở đây được xác định là một phiên chuyển mã chỉ video 1080p sang 720p đồng thời sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy phát âm thanh và video 1080p. Đối với bộ mã hoá và giải mã Dolby Vision, độ trễ khởi chạy bộ mã hoá và giải mã PHẢI là 50 mili giây trở xuống.
[5.1/H-1-13] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 30 mili giây trở xuống cho phiên giải mã âm thanh có tốc độ bit 128 kbps trở xuống cho tất cả bộ giải mã âm thanh khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy phát âm thanh và 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ã hoá video phần cứng hỗ trợ 4K60.
[5.3/H-1-1] KHÔNG ĐƯỢC bỏ lỡ nhiều hơn 1 khung hình trong 10 giây (tức là tỷ lệ bỏ lỡ khung hình dưới 0,167%) đối với phiên phát video 4K 60 khung hình/giây khi tải.
[5.3/H-1-2] KHÔNG ĐƯỢC bỏ lỡ nhiều hơn 1 khung hình trong 10 giây khi thay đổi độ phân giải video trong một phiên video 60 khung hình/giây khi tải cho một phiên 4K.
[5.6/H-1-1] PHẢI có độ trễ nhấn để phát âm thanh từ 80 mili giây trở xuống bằng cách sử dụng quy trình kiểm thử nhấn để phát âm thanh của Trình xác minh CTS.
[5.6/H-1-2] PHẢI có độ trễ âm thanh trọn vòng 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ợ) thông qua toàn bộ đường dẫn dữ liệu để có độ trễ thấp và cấu hình phát trực tuyến. Đối với cấu hình độ trễ thấp, ứng dụng phải sử dụng AAudio ở chế độ gọi lại độ trễ thấp. Đối với cấu hình truyền trực tuyến, ứng dụng phải sử dụng AudioTrack Java. Trong cả cấu hình truyền trực tuyến và độ trễ thấp, bồn lưu trữ đầu ra HAL 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.
[5.6/H-1-4] PHẢI hỗ trợ thiết bị âm thanh USB có >=4 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 tuân thủ lớp và khai báo cờ tính năng MIDI.
[5.6/H-1-9] PHẢI hỗ trợ ít nhất 12 kênh trộn. Điều này ngụ ý khả năng mở một AudioTrack có mặt nạ kênh 7.1.4 và tạo âm thanh không gian hoặc kết hợp 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] NÊN hỗ trợ tính năng trộn 24 kênh với ít nhất là hỗ trợ 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_ALL bằng các tính năng giải mã nội dung dưới đây.

Kích thướ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 phụ tối thiểu – VP9	9
Số lượng mẫu con tối thiểu – AV1	288
Kích thước vùng đệm lấy mẫu con tối thiểu	1 MiB
Kích thước vùng đệm mã hoá chung tối thiểu	500 KiB
Số phiên đồng thời tối thiểu	30
Số lượng khoá tối thiểu trên mỗi phiên	20
Tổng số khoá tối thiểu (tất cả phiên)	80
Tổng số khoá DRM tối thiểu (tất cả phiên)	6
Kích thước thư	16 KiB
Số khung hình đã giải mã/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ợ Hồ sơ cơ sở của AVIF.
[5.1/H-1-18] PHẢI hỗ trợ bộ mã hoá AV1 có thể mã hoá lên đến độ phân giải 480p ở tốc độ 30 khung hình/giây và 1 Mb/giây.
~~[5.12/H-1-1] PHẢI~~ [5.12/H-SR] Bạn nên hỗ trợ tính năng Feature_HdrEditing cho tất cả bộ mã hoá 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ả bộ mã hoá phần cứng AV1 và HEVC có trên thiết bị.
[5.12/H-1-3] PHẢI quảng cáo tính năng hỗ trợ tiện ích EXT_YUV_target để lấy mẫu từ hoạ tiết 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 đơn vị xử lý màn hình (DPU), trong đó ít nhất 2 lớp phủ có thể hiển thị nội dung video 10 bit.

Nếu các hoạt động 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à bao gồm cả hỗ trợ cho bộ mã hoá AVC hoặc HEVC phần cứng, thì các hoạt động đó:

[5.2/H-2-1] PHẢI đáp ứng mục tiêu chất lượng tối thiểu do các đường cong độ méo tỷ lệ của bộ mã hoá video xác định cho bộ mã hoá và giải mã AVC và HEVC phần cứng, như được xác định trong bài kiểm thử Run Performance Class 14 (PC14)-Video encoding quality (VEQ) (Chạy bài kiểm thử Hiệu suất cấp 14 (PC14) – Chất lượng mã hoá video (VEQ)).

Kết thúc các yêu cầu mới

2.2.7.2. Camera

PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn được liệt kê trong phần 2.2.7.2 của CDD Android 13.

Bắt đầu yêu cầu mới

[7.5/H-1-1] PHẢI có camera chính ở mặt sau với độ phân giải tối thiểu là 12 megapixel, hỗ trợ quay video ở độ phân giải 4K@30 khung hình/giây. Máy ảnh mặt sau chính là máy ảnh mặt sau có mã máy ảnh thấp nhất.
[7.5/H-1-2] PHẢI có camera chính ở mặt trước với độ phân giải tối thiểu là 6 megapixel và hỗ trợ quay video ở độ phân giải 1080p@30fps. Máy ảnh mặt trước chính là máy ảnh mặt trước có mã máy ảnh thấp nhất.
[7.5/H-1-3] PHẢI hỗ trợ thuộc tính android.info.supportedHardwareLevel là FULL trở lên đối với camera chính sau và LIMITED trở lên đối với camera chính trước.
[7.5/H-1-4] PHẢI hỗ trợ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME cho cả hai camera chính.
[7.5/H-1-5] PHẢI có độ trễ chụp ảnh JPEG camera2 < 1000 ~~900~~ ms cho độ phân giải 1080p được đo bằng PerformanceTest của máy ảnh CTS trong các điều kiện chiếu sáng ITS (3000K) cho cả hai camera chính.
[7.5/H-1-6] PHẢI có độ trễ khởi động camera2 (mở máy ảnh đến khung hình xem trước đầu tiên) < 500 mili giây theo đo lường của PerformanceTest máy ảnh CTS trong điều kiện chiếu sáng ITS (3000K) cho cả hai máy ảnh chính.
[7.5/H-1-8] PHẢI hỗ trợ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW và android.graphics.ImageFormat.RAW_SENSOR cho máy ảnh sau chính.
[7.5/H-1-9] PHẢI có camera chính ở mặt sau hỗ trợ độ phân giải 720p hoặc 1080p ở tốc độ 240 khung hình/giây.
[7.5/H-1-10] PHẢI có ZOOM_RATIO tối thiểu < 1.0 cho máy ảnh chính nếu có máy ảnh RGB góc siêu rộng hướng về cùng một hướng.
[7.5/H-1-11] PHẢI triển khai tính năng truyền trực tuyến đồng thời trước và sau trên camera chính.
[7.5/H-1-12] PHẢI hỗ trợ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION cho cả camera chính ở mặt trước và camera chính ở mặt sau.
[7.5/H-1-13] PHẢI hỗ trợ chức năng LOGICAL_MULTI_CAMERA cho máy ảnh chính mặt sau nếu có nhiều hơn 1 máy ảnh mặt sau RGB.
[7.5/H-1-14] PHẢI hỗ trợ chức năng STREAM_USE_CASE cho cả máy ảnh chính ở mặt trước và máy ảnh chính ở mặt sau.
[7.5/H-1-15] PHẢI hỗ trợ ~~tiện ích Bokeh và~~ chế độ ban đêm thông qua cả tiện ích CameraX và Camera2 cho máy ảnh chính.
[7.5/H-1-16] PHẢI hỗ trợ chức 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à tính năng phát hiện khuôn mặt (STATISTICS_FACE_DETECT_MODE_SIMPLE hoặc STATISTICS_FACE_DETECT_MODE_FULL) cho máy ảnh chính.

Kết thúc các yêu cầu mới

2.2.7.3. Phần cứng

PHẢI đáp ứng các yêu cầu về nội dung đa phương tiện được liệt kê trong phần 2.2.7.3 của CDD Android 13.

Bắt đầu yêu cầu mới

[7.1.1.1/H-2-1] PHẢI có độ phân giải màn hình tối thiểu là 1080p.
[7.1.1.3/H-2-1] PHẢI có mật độ điểm ảnh màn hình tối thiểu là 400 dpi.
[7.1.1.3/H-3-1] PHẢI có màn hình HDR hỗ trợ độ sáng trung bình tối thiểu là 1.000 nit.
[7.6.1/H-2-1] PHẢI có ít nhất 8 GB bộ nhớ vật lý.

Kết thúc các yêu cầu mới

2.2.7.4. Hiệu suất

PHẢI đáp ứng các yêu cầu về hiệu suất được liệt kê trong mục 2.2.7.4 của CDD Android 13.

Bắt đầu yêu cầu mới

[8.2/H-1-1] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 150 MB/giây.
[8.2/H-1-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 10 MB/giây.
[8.2/H-1-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 250 MB/giây.
[8.2/H-1-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu là 100 MB/giây.
[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 gấp 1 lần, ít nhất là 50 MB/giây.

Kết thúc các yêu cầu mới

2.3. Yêu cầu đối với TV

Thiết bị Android Television là một cách triển khai thiết bị Android đóng vai trò là giao diện giải trí để người dùng ngồi cách xa khoảng 3 mét có thể thưởng thức nội dung đa phương tiện kỹ thuật số, phim, trò chơi, ứng dụng và/hoặc truyền hình trực tiếp (gọi là "giao diện người dùng thư giãn" hoặc "giao diện người dùng 3 mét").

Các phương thức triển khai thiết bị Android được phân loại là TV nếu đáp ứng tất cả các tiêu chí sau:

Đã cung cấp một cơ chế để điều khiển từ xa giao diện người dùng được kết xuất trên màn hình có thể cách người dùng 3 mét.
Có màn hình tích hợp với chiều đường chéo lớn hơn 24 inch HOẶC có cổng đầu ra video, chẳng hạn như VGA, HDMI, DisplayPort hoặc cổng không dây để hiển thị.

Các yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho việc triển khai thiết bị Android Television.

2.3.1. Phần cứng

Triển khai thiết bị truyền hình:

[7.2.2/T-0-1] PHẢI hỗ trợ D-pad.
[7.2.3/T-0-1] PHẢI cung cấp các hàm Trang chủ và Quay lại.
[7.2.3/T-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước.
[7.2.6.1/T-0-1] PHẢI hỗ trợ tay điều khiển trò chơi và khai báo cờ tính năng android.hardware.gamepad.
[7.2.7/T] NÊN cung cấp một thiết bị điều khiển từ xa để người dùng có thể truy cập vào các phương thức nhập điều hướng không chạm và các phím điều hướng cốt lõi.

Nếu việc triển khai thiết bị truyền hình có sử dụng con quay hồi chuyển 3 trục, thì các thiết bị đó:

[7.3.4/T-1-1] PHẢI có khả năng báo cáo các sự kiện lên đến tần số tối thiểu là 100 Hz.
[7.3.4/T-1-2] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1000 độ mỗi giây.

Triển khai thiết bị truyền hình:

[7.4.3/T-0-1] PHẢI hỗ trợ Bluetooth và Bluetooth LE.
[7.6.1/T-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").

Nếu việc triển khai thiết bị truyền hình có cổng USB hỗ trợ chế độ máy chủ, thì các thiết bị đó:

[7.5.3/T-1-1] PHẢI hỗ trợ máy ảnh bên ngoài kết nối thông qua cổng USB này nhưng không nhất thiết phải luôn kết nối.

Nếu việc triển khai thiết bị TV là 32 bit:

[7.6.1/T-1-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 896 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- 400dpi trở lên trên màn hình nhỏ/bình thường
- xhdpi trở lên trên màn hình lớn
- tvdpi trở lên trên màn hình cực lớn

Nếu việc triển khai thiết bị TV là 64 bit:

[7.6.1/T-2-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1280 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- 400dpi trở lên trên màn hình nhỏ/bình thường
- xhdpi trở lên trên màn hình lớn
- tvdpi trở lên trên màn hình cực lớn

Triển khai thiết bị truyền hình:

[7.8.1/T] PHẢI có micrô.
[7.8.2/T-0-1] PHẢI có đầu ra âm thanh và khai báo android.hardware.audio.output.

2.3.2. Đa phương tiện

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

[5.1/T-0-1] Hồ sơ MPEG-4 AAC (AAC LC)
[5.1/T-0-2] Hồ sơ MPEG-4 HE AAC (AAC+)
[5.1/T-0-3] AAC ELD (AAC độ trễ thấp nâng cao)

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

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

Bắt đầu yêu cầu mới

[5.2/T-0-3] AV1

Kết thúc các yêu cầu mới

Triển khai thiết bị truyền hình:

[5.2.2/T-SR-1] NÊN hỗ trợ tính năng mã hoá H.264 cho video có độ phân giải 720p và 1080p ở tốc độ 30 khung hình/giây.

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 đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

[5.3.3/T-0-1] MPEG-4 SP
[5.3.4/T-0-2] H.264 AVC
[5.3.5/T-0-3] H.265 HEVC
[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
[5.3.1/T-0-6] MPEG-2

Bắt đầu yêu cầu mới

[5.3.2/T-0-7] AV1

Kết thúc các yêu cầu mới

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã MPEG-2, như được nêu chi tiết trong Phần 5.3.1, ở tốc độ khung hình và độ phân giải video tiêu chuẩn lên đến và bao gồm:

[5.3.1/T-1-1] HD 1080p với tốc độ 29,97 khung hình/giây với Cấp cao của hồ sơ chính.
[5.3.1/T-1-2] HD 1080i với tốc độ 59,94 khung hình/giây với Cấp cao của hồ sơ chính. Các ứng dụng này PHẢI tách video MPEG-2 nội suy và cung cấp video đó cho các ứng dụng bên thứ ba.

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã H.264, như được nêu chi tiết trong Phần 5.3.4, ở tốc độ khung hình và độ phân giải video tiêu chuẩn lên đến và bao gồm:

[5.3.4/T-1-1] HD 1080p với tốc độ 60 khung hình/giây bằng Hồ sơ cơ sở
[5.3.4/T-1-2] HD 1080p với tốc độ 60 khung hình/giây theo Profile chính
[5.3.4/T-1-3] HD 1080p với tốc độ 60 khung hình/giây với Profile cấp cao 4.2

Việc triển khai thiết bị truyền hình có bộ giải mã phần cứng H.265 PHẢI hỗ trợ giải mã H.265, như được nêu chi tiết trong Mục 5.3.5, ở tốc độ khung hình video tiêu chuẩn và độ phân giải lên đến và bao gồm:

[5.3.5/T-1-1] HD 1080p với tốc độ 60 khung hình/giây với Profile chính cấp 4.1

Nếu việc triển khai thiết bị truyền hình bằng bộ giải mã phần cứng H.265 hỗ trợ giải mã H.265 và hồ sơ giải mã UHD, thì các thiết bị đó:

[5.3.5/T-2-1] PHẢI hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ Cấp chính Main10 cấp 5

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã VP8, như được nêu chi tiết trong Phần 5.3.6, ở tốc độ khung hình và độ phân giải video tiêu chuẩn lên đến và bao gồm:

[5.3.6/T-1-1] Hồ sơ giải mã HD 1080p với tốc độ 60 khung hình/giây

Việc triển khai thiết bị truyền hình có bộ giải mã phần cứng VP9 PHẢI hỗ trợ giải mã VP9, như được nêu chi tiết trong Mục 5.3.7, ở tốc độ khung hình video tiêu chuẩn và độ phân giải lên đến và bao gồm:

[5.3.7/T-1-1] HD 1080p với tốc độ 60 khung hình/giây với hồ sơ 0 (độ sâu màu 8 bit)

Nếu các phương thức triển khai thiết bị truyền hình có bộ giải mã phần cứng VP9 hỗ trợ giải mã VP9 và hồ sơ giải mã UHD, thì các phương thức đó:

[5.3.7/T-2-1] PHẢI hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ 0 (độ sâu màu 8 bit).
[5.3.7/T-SR1] NÊN hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ 2 (độ sâu màu 10 bit).

Triển khai thiết bị truyền hình:

[5.5/T-0-1] PHẢI hỗ trợ âm lượng chính của hệ thống và độ giảm âm lượng đầu ra âm thanh kỹ thuật số trên các đầu ra được hỗ trợ, ngoại trừ đầu ra truyền âm thanh nén (không giải mã âm thanh trên thiết bị).

Nếu việc triển khai thiết bị truyền hình không có màn hình tích hợp, nhưng hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các thiết bị đó:

[5.8/T-0-1] PHẢI đặt chế độ đầu ra HDMI thành độ 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, tuỳ 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-SR-1] NÊN cung cấp bộ chọn tốc độ làm mới HDMI có thể định cấu hình của người dùng.
[5.8] NÊN đặt tốc độ làm mới chế độ đầu ra HDMI thành 50Hz hoặc 60Hz, tuỳ thuộc vào tốc độ làm mới video cho khu vực bán thiết bị.

Nếu việc triển khai thiết bị truyền hình không có màn hình tích hợp, nhưng hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các thiết bị đó:

[5.8/T-1-1] PHẢI hỗ trợ HDCP 2.2.

Nếu việc triển khai thiết bị truyền hình không hỗ trợ giải mã UHD mà thay vào đó hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các thiết bị đó:

[5.8/T-2-1] PHẢI hỗ trợ HDCP 1.4

2.3.3. Phần mềm

Triển khai thiết bị truyền hình:

[3/T-0-1] BẮT BUỘC phải khai báo các tính năng android.software.leanback và android.hardware.type.television.
[3.2.3.1/T-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
[3.4.1/T-0-1] PHẢI cung cấp cách triển khai đầy đủ API android.webkit.Webview.

Nếu việc triển khai thiết bị Android TV hỗ trợ màn hình khoá,thì các thiết bị đó:

[3.8.10/T-1-1] PHẢI hiển thị Thông báo trên màn hình khoá, bao gồm cả Mẫu thông báo đa phương tiện.

Triển khai thiết bị truyền hình:

[3.8.14/T-SR-1] Bạn NÊN hỗ trợ chế độ nhiều cửa sổ hình trong hình (PIP).
[3.10/T-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
[3.10/T-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của tính năng Tiếp cận bằng công tắc và TalkBack (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.

Nếu việc triển khai thiết bị truyền hình báo cáo tính năng android.hardware.audio.output, thì các thiết bị đó:

[3.11/T-SR-1] Bạn NÊN đưa một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị vào.
[3.11/T-1-1] PHẢI hỗ trợ việc cài đặt các công cụ TTS của bên thứ ba.

Triển khai thiết bị truyền hình:

[3.12/T-0-1] PHẢI hỗ trợ Khung đầu vào TV.

2.3.4. Hiệu suất và nguồn điện

[8.1/T-0-1] Độ trễ khung hình nhất quán. Độ trễ khung hình không nhất quán hoặc độ trễ khi kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình/giây và PHẢI dưới 1 khung hình/giây.
[8.2/T-0-1] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 5 MB/giây.
[8.2/T-0-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 0,5 MB/giây.
[8.2/T-0-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 15 MB/giây.
[8.2/T-0-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu là 3,5 MB/giây.

Nếu việc triển khai thiết bị truyền hình bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị có trong AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

[8.3/T-1-1] PHẢI cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.

Nếu việc triển khai thiết bị truyền hình không có pin, thì:

[8.3/T-1-2] PHẢI đăng ký thiết bị dưới dạng thiết bị không dùng pin như mô tả trong phần Hỗ trợ thiết bị không dùng pin.

Nếu việc triển khai thiết bị truyền hình có pin, thì:

[8.3/T-1-3] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ tiết kiệm pin Chế độ chờ ứng dụng và Nghỉ.

Triển khai thiết bị truyền hình:

[8.4/T-0-1] PHẢI cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức tiêu hao pin gần đúng do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android.
[8.4/T-0-2] PHẢI báo cáo tất cả giá trị tiêu thụ điện năng theo giờ miliampe (mAh).
[8.4/T-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. Dự án nguồn mở Android đáp ứng yêu cầu thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/T] NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.
[8.4/T-0-4] PHẢI cung cấp mức sử dụng năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.

2.3.5. Mô hình bảo mật

Triển khai thiết bị truyền hình:

[9/T-0-1] PHẢI khai báo tính năng android.hardware.security.model.compatible.
[9.11/T-0-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
[9.11/T-0-2] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và trên đó. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) thượng nguồn đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một phương thức triển khai bảo mật được bên thứ ba xem xét về việc tách biệt dựa trên trình điều khiển ảo hoá thích hợp là các lựa chọn thay thế.
[9.11/T-0-3] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi tách biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Bạn PHẢI lưu trữ thông tin xác thực màn hình khoá theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện xác thực màn hình khoá. Dự án nguồn mở Android thượng nguồn cung cấp Lớp trừu tượng phần cứng của Gatekeeper (HAL) và Trusty, có thể được dùng để đáp ứng yêu cầu này.
[9.11/T-0-4] PHẢI hỗ trợ chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quá trình ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc sử dụng khoá làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu sản xuất hơn 100.000 đơn vị của một SKU, bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.

Nếu việc triển khai thiết bị truyền hình hỗ trợ màn hình khoá bảo mật, thì các thiết bị đó:

[9.11/T-1-1] PHẢI cho phép người dùng chọn thời gian chờ chế độ Ngủ để chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, với thời gian chờ tối thiểu cho phép lên đến 15 giây hoặc ít hơn.

Nếu việc triển khai thiết bị truyền hình bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/T-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các chức năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.

Nếu việc triển khai thiết bị truyền hình bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/T-3-1] KHÔNG ĐƯỢC hỗ trợ các hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để cho phép /vô hiệu hoá người dùng khác truy cập vào cuộc gọi thoại và tin nhắn SMS.

Nếu việc triển khai thiết bị truyền hình khai báo android.hardware.microphone, thì các thiết bị đó:

[9.8.2/T-4-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được truy cập bởi HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng giữ vai trò được nêu trong Mục 9.1 về Quyền có giá trị nhận dạng CDD C-3-X].
[9.8.2/T-4-2] KHÔNG được ẩn chỉ báo micrô cho 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.

Nếu việc triển khai thiết bị truyền hình khai báo android.hardware.camera.any, thì các thiết bị đó:

[9.8.2/T-5-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không được hiển thị khi máy ảnh chỉ được(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền truy cập bằng giá trị nhận dạng CDD [C-3-X] truy cập.
[9.8.2/T-5-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.3.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển

Triển khai thiết bị truyền hình:

Perfetto
- [6.1/T-0-1] PHẢI hiển thị tệp nhị phân /system/bin/perfetto cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto.
- [6.1/T-0-2] Tệp nhị phân perfetto PHẢI chấp nhận cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/T-0-3] Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/T-0-4] PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.

2.4. Yêu cầu về đồng hồ

Thiết bị Android Watch là một thiết bị Android được triển khai để đeo trên cơ thể, có thể là trên cổ tay.

Các hoạt động triển khai thiết bị Android được phân loại là Đồng hồ nếu đáp ứng tất cả các tiêu chí sau:

Có màn hình với chiều dài đường chéo thực tế trong khoảng từ 1,1 đến 2,5 inch.
Có cơ chế để đeo trên cơ thể.

Các yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho việc triển khai thiết bị Android Watch.

2.4.1. Phần cứng

Xem cách triển khai thiết bị:

[7.1.1.1/W-0-1] PHẢI có màn hình có kích thước đường chéo thực tế trong khoảng từ 1,1 đến 2,5 inch.
[7.2.3/W-0-1] PHẢI cung cấp cho người dùng chức năng Trang chủ và chức năng Quay lại, ngoại trừ khi ở trong UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] PHẢI hỗ trợ phương thức nhập bằng màn hình cảm ứng.
[7.3.1/W-SR-1] NÊN có gia tốc kế 3 trục.

Nếu quá trình triển khai thiết bị đồng hồ bao gồm một bộ thu GPS/GNSS và báo cáo tính năng này cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps, thì các thiết bị đó:

[7.3.3/W-1-1] PHẢI báo cáo các phép đo GNSS ngay khi phát hiện được, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
[7.3.3/W-1-2] PHẢI báo cáo khoảng thời gian và tốc độ giả lập GNSS, trong điều kiện ngoài trời sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét trên giây vuông, đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0, 2 mét trên giây, ít nhất là 95% thời gian.

Nếu việc triển khai thiết bị đồng hồ có sử dụng con quay hồi chuyển 3 trục, thì các thiết bị đó:

[7.3.4/W-2-1] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1000 độ mỗi giây.

Xem cách triển khai thiết bị:

[7.4.3/W-0-1] PHẢI hỗ trợ Bluetooth.
[7.6.1/W-0-1] PHẢI có ít nhất 1 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").
[7.6.1/W-0-2] PHẢI có ít nhất 416 MB bộ nhớ cho nhân và không gian người dùng.
[7.8.1/W-0-1] PHẢI có micrô.
[7,8,2/W] CÓ THỂ có đầu ra âm thanh.

2.4.2. Đa phương tiện

Không có yêu cầu bổ sung.

2.4.3. Phần mềm

Xem cách triển khai thiết bị:

[3/W-0-1] PHẢI khai báo tính năng android.hardware.type.watch.
[3/W-0-2] PHẢI hỗ trợ uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.

Xem cách triển khai thiết bị:

[3.8.4/W-SR-1] Bạn NÊN triển khai một trợ lý trên thiết bị để xử lý Thao tác hỗ trợ.

Xem các cách triển khai thiết bị đồng hồ khai báo cờ tính năng android.hardware.audio.output:

[3.10/W-1-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
[3.10/W-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của TalkBack và Tiếp cận bằng công tắc (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.

Nếu việc triển khai thiết bị đồng hồ báo cáo tính năng android.hardware.audio.output, thì các thiết bị đó:

[3.11/W-SR-1] Bạn NÊN đưa một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị vào.
[3.11/W-0-1] PHẢI hỗ trợ việc cài đặt các công cụ TTS của bên thứ ba.

2.4.4. Hiệu suất và nguồn điện

Nếu việc triển khai thiết bị Watch bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị có trong AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

[8.3/W-SR-1] Bạn NÊN cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ Trạng thái chờ ứng dụng và chế độ Tiết kiệm pin.
[8.3/W-SR-2] Bạn NÊN cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.

Xem cách triển khai thiết bị:

[8.4/W-0-1] PHẢI cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức hao pin gần đúng do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android.
[8.4/W-0-2] PHẢI báo cáo tất cả giá trị tiêu thụ điện năng theo đơn vị miliampe giờ (mAh).
[8.4/W-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. Dự án nguồn mở Android đáp ứng yêu cầu thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/W-0-4] PHẢI cung cấp mức sử dụng năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.
[8,4/W] NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.

2.4.5. Mô hình bảo mật

Xem cách triển khai thiết bị:

[9/W-0-1] PHẢI khai báo tính năng android.hardware.security.model.compatible.

Nếu việc triển khai thiết bị Watch bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/W-1-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.

Nếu việc triển khai thiết bị Watch bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/W-2-1] KHÔNG ĐƯỢC hỗ trợ các hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để cho phép /vô hiệu hoá người dùng khác truy cập vào cuộc gọi thoại và tin nhắn SMS.

Bắt đầu yêu cầu mới

[9.11.1/W-1-1] PHẢI yêu cầu 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ở khoá, mật khẩu) thường xuyên hơn một lần mỗi 72 giờ.

Kết thúc các yêu cầu mới

2.5. Yêu cầu về ô tô

Triển khai Android Automotive đề cập đến đầu phát trung tâm trên ô tô chạy Android làm hệ điều hành cho một phần hoặc toàn bộ hệ thống và/hoặc chức năng thông tin giải trí.

Các hoạt động triển khai thiết bị Android được phân loại là Automotive nếu các hoạt động đó khai báo tính năng android.hardware.type.automotive hoặc đáp ứng tất cả các tiêu chí sau.

Được nhúng vào hoặc có thể cắm vào một xe ô tô.
Sử dụng màn hình ở hàng ghế lái làm màn hình chính.

Các yêu cầu bổ sung trong phần còn lại của mục này dành riêng cho việc triển khai thiết bị Android Automotive.

2.5.1. Phần cứng

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

[7.1.1.1/A-0-1] PHẢI có màn hình có kích thước đường chéo vật lý tối thiểu là 6 inch.
[7.1.1.1/A-0-2] PHẢI có bố cục kích thước màn hình tối thiểu là 750 dp x 480 dp.
[7.2.3/A-0-1] PHẢI cung cấp hàm Home (Trang chủ) và CÓ THỂ cung cấp hàm Back (Quay lại) và Recent (Gần đây).
[7.2.3/A-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước.
[7.3/A-0-1] PHẢI triển khai và báo cáo GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED và PARKING_BRAKE_ON.
[7.3/A-0-2] Giá trị của cờ NIGHT_MODE PHẢI nhất quán với chế độ ban ngày/ban đêm của trang tổng quan và PHẢI dựa trên dữ liệu đầu vào của cảm biến ánh sáng xung quanh. Cảm biến ánh sáng xung quanh cơ bản CÓ THỂ giống với Photometer.
[7.3/A-0-3] PHẢI cung cấp trường thông tin bổ sung của cảm biến TYPE_SENSOR_PLACEMENT trong SensorAdditionalInfo cho mọi cảm biến được cung cấp.
[7.3/A-SR1] CÓ THỂ dự đoán vị trí Vị trí bằng cách kết hợp GPS/GNSS với các cảm biến bổ sung. Nếu Vị trí là vị trí dự đoán, bạn NÊN triển khai và báo cáo các loại Cảm biến tương ứng và/hoặc Mã nhận dạng tài sản của xe được sử dụng.
[7.3/A-0-4] Vị trí được yêu cầu thông qua LocationManager#requestLocationUpdates() KHÔNG ĐƯỢC so khớp với bản đồ.
[7.3.1/A-0-4] PHẢI tuân thủ hệ thống toạ độ cảm biến ô tô của Android.
[7.3/A-SR-1] Bạn NÊN_ĐƯỢC_ĐỀ_XUẤT sử dụng gia tốc kế 3 trục và con quay hồi chuyển 3 trục.
[7.3/A-SR-2] Bạn NÊN triển khai và báo cáo cảm biến TYPE_HEADING.

Nếu các phương thức triển khai thiết bị ô tô hỗ trợ OpenGL ES 3.1, thì các phương thức đó:

[7.1.4.1/A-0-1] PHẢI khai báo OpenGL ES 3.1 trở lên.
[7.1.4.1/A-0-2] PHẢI hỗ trợ Vulkan 1.1.
[7.1.4.1/A-0-3] PHẢI bao gồm trình tải Vulkan và xuất tất cả các ký hiệu.

Nếu việc triển khai thiết bị Automotive có sử dụng gia tốc kế, thì các thiết bị đó:

[7.3.1/A-1-1] PHẢI có thể báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.

Nếu triển khai gia tốc kế 3 trục trên thiết bị, thì các thiết bị đó:

[7.3.1/A-SR-1] Bạn NÊN 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 gia tốc kế có ít hơn 3 trục, thì các thiết bị đó:

[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, thì các thiết bị đó:

[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 suất tối thiểu là 100 Hz.
[7.3.4/A-2-3] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 250 độ mỗi giây.
[7.3.4/A-SR-1] Bạn NÊN định cấu hình phạm vi đo lường của con quay hồi chuyển thành +/-250dps để tối đa hoá độ 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, thì các thiết bị đó:

[7.3.4/A-SR-2] NÊN 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ì các thiết bị đó:

[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ị Automotive bao gồm bộ thu GPS/GNSS nhưng không bao gồm khả năng kết nối dữ liệu dựa trên mạng di động, thì các thiết bị đó:

[7.3.3/A-3-1] PHẢI xác định vị trí trong lần đầu tiên bật bộ thu GPS/GNSS hoặc sau 4 ngày trở lên trong vòng 60 giây.
[7.3.3/A-3-2] PHẢI đáp ứng các tiêu chí về thời gian khắc phục lỗi đầu tiên như mô tả trong 7.3.3/C-1-2 và 7.3.3/C-1-6 đối với tất cả các yêu cầu vị trí khác (tức là các yêu cầu không phải là lần đầu tiên hoặc sau 4 ngày trở lên). Yêu cầu 7.3.3/C-1-2 thường được đáp ứng trong các xe không có kết nối dữ liệu dựa trên mạng di động, bằng cách sử dụng thông tin dự đoán quỹ đạo GNSS được tính toán trên bộ thu hoặc sử dụng vị trí xe đã biết gần đây nhất cùng với khả năng dự đoán vị trí trong ít nhất 60 giây với độ chính xác vị trí đáp ứng 7.3.3/C-1-3 hoặc kết hợp cả hai.

Nếu quá trình triển khai thiết bị ô tô bao gồm cảm biến TYPE_HEADING, thì các thiết bị đó:

[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 suất tối thiểu là 1 Hz.
[7.3.4/A-SR-3] NÊN báo cáo các sự kiện có tần suất tối thiểu là 10 Hz.
PHẢI tham chiếu đến hướng bắc thực.
PHẢI có sẵn ngay cả khi xe đang đứng yên.
NÊN có độ phân giải tối thiểu là 1 độ.

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

[7.4.3/A-0-1] PHẢI hỗ trợ Bluetooth và NÊN hỗ trợ Bluetooth LE.
[7.4.3/A-0-2] Việc triển khai Android Automotive PHẢI hỗ trợ các hồ sơ Bluetooth sau:
- Gọi điện thoại qua Cấu hình rảnh tay (HFP).
- Phát nội dung nghe nhìn qua Cấu hình phân phối âm thanh (A2DP).
- Điều khiển chế độ phát nội dung nghe nhìn qua Cấu hình điều khiển từ xa (AVRCP).
- Chia sẻ danh bạ bằng Cấu hình truy cập danh bạ (PBAP).
[7.4.3/A-SR-1] Bạn NÊN hỗ trợ Hồ sơ truy cập tin nhắn (MAP).
[7.4.5/A] PHẢI hỗ trợ kết nối dữ liệu dựa trên mạng di động.
[7.4.5/A] CÓ THỂ sử dụng hằng số NetworkCapabilities#NET_CAPABILITY_OEM_PAID của API hệ thống cho các mạng mà ứng dụng hệ thống có thể sử dụng.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ đài phát thanh AM/FM và hiển thị chức năng này cho mọi ứng dụng, thì các thiết bị đó:

[7.4~~.10~~/A-0-1] PHẢI khai báo hỗ trợ FEATURE_BROADCAST_RADIO.

Kết thúc các yêu cầu mới

Máy ảnh quan sát bên ngoài là máy ảnh chụp hình ảnh bên ngoài phạm vi triển khai thiết bị, chẳng hạn như camera lùi.

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

PHẢI có 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 cả camera quan sát bên ngoài, thì đối với camera đó, các thiết bị này:

[7.5/A-1-1] KHÔNG ĐƯỢC cho phép truy cập vào camera quan sát bên ngoài thông qua API máy ảnh Android, trừ phi các camera đó tuân thủ các yêu cầu cốt lõi của máy ảnh.

[7.5/A-SR-1] KHÔNG NÊN xoay hoặc phản chiếu theo chiều ngang bản xem trước của máy ảnh.

[7.5/A-SR-2] Bạn NÊN có độ phân giải tối thiểu là 1,3 megapixel.

PHẢI có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường hình ảnh mở rộng).

CÓ THỂ triển khai tính năng tự động lấy nét bằng phần cứng hoặc tự động lấy nét bằng 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 ngang bả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 bên thứ ba.

Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một máy ảnh và cung cấp máy ảnh đó cho các ứng dụng bên thứ ba, thì các ứng dụ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 ĐƯỢ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 như mô tả trong mục 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 mặt sau như mô tả trong mục 7.5.1.

Bắt đầu yêu cầu mới

Máy ảnh mặt sau là máy ảnh quay 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 khoang xe; tức là máy ảnh này chụp lại cảnh ở phía xa của thân xe, chẳng hạn như camera lùi.

Máy ảnh mặt trước là máy ảnh 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 khoang xe; tức là máy ảnh này chụp hình người dùng, chẳng hạn như cho ứng dụng 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] NÊN có một hoặc nhiều camera quay ra ngoài.
CÓ THỂ có một hoặc nhiều máy ảnh quay về phía người dùng.
[7.5/A-SR-2] NÊN hỗ trợ tính năng truyền phát đồng thời nhiều máy ảnh.

Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một camera hướng ra ngoài, thì đối với camera đó, các thiết bị này:

[7.5/A-1-1] PHẢI được định hướng để kích thước dài của máy ảnh phù hợp với mặt phẳng X-Y của trục cảm biến trên ô tô Android.
[7.5/A-SR-3] NÊN có phần cứng lấy nét cố định hoặc EDOF (Tiêu cự sâu mở rộng).
[7.5/A-1-2] PHẢI có máy ảnh chính quay ra ngoài làm máy ảnh quay ra ngoài có mã máy ảnh thấp nhất.

Nếu việc triển khai thiết bị ô tô bao gồm ít nhất một máy ảnh hướng về phía người dùng, thì đối với máy ảnh đó:

[7.5/A-2-1] Máy ảnh chính hướng về phía người dùng PHẢI là máy ảnh hướng về phía người dùng có mã máy ảnh thấp nhất.
CÓ THỂ được định hướng để kích thước dài của máy ảnh phù hợp với mặt phẳng X-Y của trục cảm biến Android Automotive.

Nếu việc triển khai thiết bị ô tô bao gồm một máy ảnh có thể truy cập được thông qua API android.hardware.Camera hoặc android.hardware.camera2, thì các thiết bị đó:

[7.5/A-3-1] PHẢI tuân thủ các yêu cầu chính về máy ảnh trong mục 7.5.

Nếu quá trình triển khai thiết bị ô tô bao gồm một máy ảnh không thể truy cập được thông qua API android.hardware.Camera hoặc android.hardware.camera2, thì các thiết bị đó:

[7.5/A-4-1] PHẢI truy cập được qua dịch vụ Hệ thống chế độ xem mở rộng.

Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều máy ảnh có thể truy cập được thông qua Dịch vụ hệ thống chế độ xem mở rộng, thì đối với máy ảnh đó, chúng:

[7.5/A-5-1] KHÔNG ĐƯỢC xoay hoặc phản chiếu bản xem trước của máy ảnh theo chiều ngang.
[7.5/A-SR-4] NÊN có độ phân giải tối thiểu là 1,3 megapixel.

Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều máy ảnh có thể truy cập được thông qua cả Dịch vụ hệ thống chế độ xem mở rộng và API android.hardware.Camera hoặc android.hardware.Camera2, thì đối với máy ảnh như vậy, chúng:

[7.5/A-6-1] PHẢI báo cáo cùng một Mã máy ảnh.

Nếu việc triển khai thiết bị Automotive cung cấp API máy ảnh độc quyền, thì các API đó:

[7.5/A-7-1] PHẢI triển khai API máy ảnh như vậy bằng API android.hardware.camera2 hoặc API Hệ thống khung hiển thị mở rộng.

Kết thúc các yêu cầu mới

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

[7.6.1/A-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").
[7.6.1/A] NÊN định dạng phân vùng dữ liệu để cải thiện hiệu suất và thời lượng sử dụng trên bộ nhớ flash, ví dụ: sử dụng hệ thống tệp f2fs.

Nếu việc triển khai thiết bị Automotive cung cấp bộ nhớ ngoài dùng chung thông qua một phần bộ nhớ trong không thể tháo rời, thì các thiết bị đó:

[7.6.1/A-SR-1] Bạn NÊN giảm chi phí I/O trên các thao tác được thực hiện trên bộ nhớ ngoài, chẳng hạn như bằng cách sử dụng SDCardFS.

Nếu việc triển khai thiết bị ô tô là 64 bit:

[7.6.1/A-2-1] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 816 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- 280dpi trở xuống trên màn hình nhỏ/bình thường
- ldpi trở xuống trên màn hình cực lớn
- mdpi trở xuống trên màn hình lớn
[7.6.1/A-2-2] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 944 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- xhdpi trở lên trên màn hình nhỏ/bình thường
- hdpi trở lên trên màn hình lớn
- mdpi trở lên trên màn hình cực lớn
[7.6.1/A-2-3] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1280 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- 400dpi trở lên trên màn hình nhỏ/bình thường
- xhdpi trở lên trên màn hình lớn
- tvdpi trở lên trên màn hình cực lớn
[7.6.1/A-2-4] Dung lượng bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI có dung lượng tối thiểu là 1824 MB nếu sử dụng bất kỳ mật độ nào sau đây:
- 560dpi trở lên trên màn hình nhỏ/bình thường
- 400dpi trở lên trên màn hình lớn
- xhdpi trở lên trên màn hình cực lớn

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

[7.7.1/A] PHẢI có cổng USB hỗ trợ chế độ ngoại vi.

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

[7.8.1/A-0-1] PHẢI có micrô.

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

[7.8.2/A-0-1] PHẢI có đầu ra âm thanh và khai báo android.hardware.audio.output.

2.5.2. Đa phương tiện

Việc triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

[5.1/A-0-1] Hồ sơ MPEG-4 AAC (AAC LC)
[5.1/A-0-2] Hồ sơ MPEG-4 HE AAC (AAC+)
[5.1/A-0-3] AAC ELD (AAC độ trễ thấp nâng cao)

Quá trình triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

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

Việc triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:

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

Bạn NÊN triển khai các thiết bị ô tô để hỗ trợ tính năng giải mã video sau:

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

2.5.3. Phần mềm

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

[3/A-0-1] PHẢI khai báo tính năng android.hardware.type.automotive.
[3/A-0-2] PHẢI hỗ trợ uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] PHẢI hỗ trợ tất cả API công khai trong không gian tên android.car.*.

Nếu việc triển khai thiết bị Automotive cung cấp một API độc quyền bằng cách sử dụng android.car.CarPropertyManager với android.car.VehiclePropertyIds, thì các API đó:

[3/A-1-1] KHÔNG ĐƯỢC đính kèm các đặc quyền đặc biệt vào việc sử dụng các thuộc tính này của ứng dụng hệ thống hoặc ngăn ứng dụng bên thứ ba sử dụng các thuộc tính này.
[3/A-1-2] KHÔNG ĐƯỢC sao chép thuộc tính xe đã tồn tại trong SDK.

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

[3.2.1/A-0-1] PHẢI hỗ trợ và thực thi tất cả các hằng số quyền như được ghi nhận trong trang tham khảo về Quyền trong ô tô.
[3.2.3.1/A-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, đối với tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
[3.4.1/A-0-1] PHẢI cung cấp cách triển khai đầy đủ API android.webkit.Webview.

Bắt đầu yêu cầu mới

[3.8/A-0-1] KHÔNG ĐƯỢC cho phép người dùng phụ toàn quyền không phải là người dùng trên nền trước hiện tại khởi chạy các hoạt động và có quyền truy cập vào giao diện người dùng trên bất kỳ màn hình nào.

Kết thúc các yêu cầu mới

[3.8.3/A-0-1] PHẢI hiển thị thông báo sử dụng API Notification.CarExtender khi ứng dụng bên thứ ba yêu cầu.
[3.8.4/A-SR-1] Bạn nên triển khai một trợ lý trên thiết bị để xử lý Thao tác hỗ trợ.

Nếu việc triển khai thiết bị Automotive có nút nhấn để nói, thì các thiết bị đó:

[3.8.4/A-1-1] PHẢI sử dụng thao tác nhấn nhanh vào nút nhấn để nói làm thao tác tương tác được chỉ định để chạy ứng dụng hỗ trợ do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService.

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

[3.8.3.1/A-0-1] PHẢI hiển thị tài nguyên đúng cách như mô tả trong tài liệu SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] PHẢI hiển thị biểu tượng CHƠI và TẮT TIẾNG cho các hành động thông báo thay vì các hành động được cung cấp thông qua Notification.Builder.addAction()
[3.8.3.1/A] NÊN hạn chế việc sử dụng các tác vụ quản lý đa dạng như các chế độ kiểm soát theo kênh thông báo. CÓ THỂ sử dụng tính năng hỗ trợ giao diện người dùng cho mỗi ứng dụng để giảm các chế độ điều khiển.

Nếu việc triển khai thiết bị ô tô hỗ trợ các thuộc tính HAL của người dùng, thì các thuộc tính đó:

[3.9.3/A-1-1] PHẢI triển khai tất cả Thuộc tính vòng đời người dùng
- INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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

[3.14/A-0-1] PHẢI bao gồm một khung giao diện người dùng để hỗ trợ các ứng dụng bên thứ ba sử dụng API đa phương tiện như mô tả trong phần 3.14.
[3.14/A-0-2] PHẢI cho phép người dùng tương tác một cách an toàn với Ứng dụng đa phương tiện khi đang lái xe.
[3.14/A-0-3] PHẢI hỗ trợ thao tác CAR_INTENT_ACTION_MEDIA_TEMPLATE ẩn ý của Ý định với CAR_EXTRA_MEDIA_PACKAGE bổ sung.
[3.14/A-0-4] PHẢI cung cấp một khả năng để điều hướng đến hoạt động ưu tiên của Ứng dụng đa phương tiện, nhưng PHẢI chỉ bật hoạt động này khi Các hạn chế về trải nghiệm người dùng trên ô tô không có hiệu lực.
[3.14/A-0-5] PHẢI hiển thị thông báo lỗi do Ứng dụng đa phương tiện đặt ra và PHẢI hỗ trợ các tính năng bổ sung không bắt buộc ERROR_RESOLUTION_ACTION_LABEL và ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] PHẢI hỗ trợ tính năng tìm kiếm trong ứng dụng cho các ứng dụng hỗ trợ tính năng tìm kiếm.
[3.14/A-0-7] PHẢI tuân thủ định nghĩa của CONTENT_STYLE_BROWSABLE_HINT và CONTENT_STYLE_PLAYABLE_HINT khi hiển thị hệ phân cấp MediaBrowser.

Nếu quá trình triển khai thiết bị ô tô bao gồm một ứng dụng trình chạy mặc định, thì các ứng dụng đó:

[3.14/A-1-1] PHẢI bao gồm các dịch vụ đa phương tiện và mở các dịch vụ đó bằng ý định CAR_INTENT_ACTION_MEDIA_TEMPLATE.

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

[3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để chuyển sang chế độ toàn màn hình như mô tả trong immersive documentation.
[3.8/A] CÓ THỂ luôn hiển thị thanh trạng thái và thanh điều hướng.
[3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để thay đổi màu sắc đằng sau các thành phần trên giao diện người dùng của hệ thống, để đảm bảo các thành phần đó luôn hiển thị rõ ràng.

2.5.4. Hiệu suất và nguồn điện

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

[8.2/A-0-1] PHẢI báo cáo số lượng byte được đọc và ghi vào bộ nhớ không bay hơi cho mỗi UID của quy trình để nhà phát triển có thể xem số liệu thống kê thông qua API hệ thống android.car.storagemonitoring.CarStorageMonitoringManager. Dự án nguồn mở Android đáp ứng yêu cầu thông qua mô-đun hạt nhân uid_sys_stats.
[8.3/A-1-3] PHẢI hỗ trợ Chế độ gara.
[8.3/A] PHẢI ở Chế độ gara ít nhất 15 phút sau mỗi lần lái xe, trừ phi:
- Pin đã hết.
- Không có công việc nào ở trạng thái rảnh được lên lịch.
- Trình điều khiển thoát khỏi Chế độ nhà để xe.
[8.4/A-0-1] PHẢI cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức tiêu hao pin gần đúng do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android.
[8.4/A-0-2] PHẢI báo cáo tất cả giá trị tiêu thụ điện năng theo giờ miliampe (mAh).
[8.4/A-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. Dự án nguồn mở Android đáp ứng yêu cầu thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/A] NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.
[8.4/A-0-4] PHẢI cung cấp mức sử dụng năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.

2.5.5. Mô hình bảo mật

Nếu việc triển khai thiết bị Automotive hỗ trợ nhiều người dùng, thì các thiết bị đó:

[9.5/A-1-1] KHÔNG ĐƯỢC cho phép người dùng tương tác hoặc chuyển sang Người dùng hệ thống không có giao diện người dùng, ngoại trừ việc cung cấp thiết bị.
[9.5/A-1-2] PHẢI chuyển sang Người dùng phụ trước BOOT_COMPLETED.
[9.5/A-1-3] PHẢI hỗ trợ tính năng tạo Người dùng khách ngay cả khi đã đạt đến số lượng người dùng tối đa trên một thiết bị.

Bắt đầu yêu cầu mới

Nếu quá trình triển khai thiết bị Automotive khai báo android.hardware.microphone, thì các thiết bị đó:

[9.8.2/A-1-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng giữ vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X].
[9.8.2/A-1-2] KHÔNG được ẩn chỉ báo micrô cho 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.
[9.8.2/A-1-3] PHẢI cung cấp cho người dùng khả năng bật/tắt micrô trong ứng dụng Cài đặt.

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị Automotive khai báo android.hardware.camera.any, thì các thiết bị đó:

[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 vào dữ liệu máy ảnh trực tiếp, nhưng không được hiển thị khi(các) ứng dụng chỉ truy cập vào máy ảnh có vai trò như đã xác định ~~được gọi ra~~ trong Mục 9.1 Quyền với giá trị nhận dạng CDD [C-4-X]~~[C-3-X]~~.
[9.8.2/A-2-2] KHÔNG được ẩn chỉ báo máy ảnh cho 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.

Bắt đầu yêu cầu mới

[9.8.2/A-2-3] PHẢI cung cấp cho người dùng khả năng bật/tắt máy ảnh trong ứng dụng Cài đặt.
[9.8.2/A-2-4] PHẢI hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng camera được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.

Kết thúc các yêu cầu mới

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

[9/A-0-1] PHẢI khai báo tính năng android.hardware.security.model.compatible.
[9.11/A-0-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
[9.11/A-0-2] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và trên đó. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) thượng nguồn đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một phương thức triển khai bảo mật được bên thứ ba xem xét về việc tách biệt dựa trên trình điều khiển ảo hoá thích hợp là các lựa chọn thay thế.
[9.11/A-0-3] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi tách biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Bạn PHẢI lưu trữ thông tin xác thực màn hình khoá theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện xác thực màn hình khoá. Dự án nguồn mở Android thượng nguồn cung cấp Lớp trừu tượng phần cứng của Gatekeeper (HAL) và Trusty, có thể được dùng để đáp ứng yêu cầu này.
[9.11/A-0-4] PHẢI hỗ trợ chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quá trình ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc sử dụng khoá làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu sản xuất hơn 100.000 đơn vị của một SKU, bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.

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

[9.14/A-0-1] PHẢI kiểm soát thông báo từ các hệ thống con của xe trong khung Android, ví dụ: đưa vào danh sách cho phép các loại thông báo và nguồn thông báo được phép.
[9.14/A-0-2] PHẢI giám sát các cuộc tấn công từ chối dịch vụ từ khung Android hoặc ứng dụng bên thứ ba. Điều này giúp bảo vệ khỏi phần mềm độc hại làm ngập mạng xe bằng lưu lượng truy cập, có thể dẫn đến các hệ thống phụ của xe hoạt động không đúng cách.

2.5.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển

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

Perfetto
- [6.1/A-0-1] PHẢI hiển thị tệp nhị phân /system/bin/perfetto cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto.
- [6.1/A-0-2] Tệp nhị phân perfetto PHẢI chấp nhận cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/A-0-3] Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/A-0-4] PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.

2.6. Yêu cầu đối với máy tính bảng

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:

Sử dụng bằng cách cầm bằng cả hai tay.
Không có cấu hình dạng vỏ sò hoặc có thể chuyển đổi.
Các phương thức triển khai bàn phím thực tế được sử dụng với thiết bị kết nối bằng phương thức kết nối tiêu chuẩn (ví dụ: USB, Bluetooth).
Có nguồn điện cung cấp khả năng di động, chẳng hạn như pin.
Có kích thước màn hình lớn hơn 7 inch và nhỏ hơn 18 inch, đo theo đường chéo.

Việc triển khai thiết bị máy tính bảng có các yêu cầu tương tự như việc triển khai thiết bị cầm tay. Các ngoại lệ được biểu thị bằng dấu * trong phần đó và được ghi chú để tham khảo trong phần này.

2.6.1. Phần cứng

Con quay hồi chuyển

Nếu việc triển khai thiết bị máy tính bảng bao gồm con quay hồi chuyển 3 trục, thì các thiết bị đó:

[7.3.4/Tab-1-1] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1000 độ mỗi giây.

Bộ nhớ và dung lượng lưu trữ tối thiểu (Mục 7.6.1)

Mật độ màn hình được liệt kê cho màn hình nhỏ/bình thường trong các yêu cầu về thiết bị cầm tay không áp dụng cho máy tính bảng.

Chế độ thiết bị ngoại vi USB (Mục 7.7.1)

Nếu việc triển khai thiết bị máy tính bảng bao gồm một cổng USB hỗ trợ chế độ thiết bị ngoại vi, thì các thiết bị đó:

[7.7.1/Tab] CÓ THỂ triển khai API Phụ kiện mở Android (AOA).

Chế độ thực tế ảo (Mục 7.9.1)

Hiệu suất cao trong thực tế ảo (Mục 7.9.2)

Các yêu cầu về thực tế ảo không áp dụng cho máy tính bảng.

2.6.2. Mô hình bảo mật

Khoá và thông tin xác thực (Mục 9.11)

Hãy tham khảo Mục [9.11].

Nếu việc triển khai thiết bị máy tính bảng bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/T-1-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.

Nếu việc triển khai thiết bị máy tính bảng bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[9.5/T-2-1] KHÔNG ĐƯỢC hỗ trợ các hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để cho phép /vô hiệu hoá người dùng khác truy cập vào cuộc gọi thoại và SMS.

2.6.2. Phần mềm

[3.2.3.1/Tab-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.

3. Phần mềm

3.1. Khả năng tương thích với API được quản lý

Môi trường thực thi mã byte Dalvik được quản lý là phương tiện chính cho các ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là tập hợp các giao diện nền tảng Android hiển thị cho các ứng dụng chạy trong môi trường thời gian chạy được quản lý.

Triển khai trên thiết bị:

[C-0-1] PHẢI cung cấp các phương thức triển khai hoàn chỉnh, bao gồm tất cả hành vi được ghi nhận, của mọi API được ghi nhận mà SDK Android hiển thị hoặc mọi API được trang trí bằng điểm đánh dấu "@SystemApi" trong mã nguồn Android thượng nguồn.
[C-0-2] PHẢI hỗ trợ/duy trì tất cả các lớp, phương thức và phần tử liên kết được đánh dấu bằng chú thích TestApi (@TestApi).
[C-0-3] KHÔNG ĐƯỢC bỏ qua bất kỳ API nào được quản lý, thay đổi giao diện hoặc chữ ký API, đi chệch hướng khỏi hành vi được ghi nhận hoặc bao gồm các thao tác không hoạt động, ngoại trừ trường hợp được Định nghĩa về khả năng tương thích này cho phép cụ thể.
[C-0-4] VẪN PHẢI duy trì các API và hoạt động một cách hợp lý, ngay cả khi một số tính năng phần cứng mà Android bao gồm API bị bỏ qua. Hãy xem mục 7 để biết các yêu cầu cụ thể cho trường hợp này.
[C-0-5] KHÔNG ĐƯỢC cho phép ứng dụng bên thứ ba sử dụng giao diện không phải SDK. Giao diện này được xác định là các phương thức và trường trong gói ngôn ngữ Java nằm trong đường dẫn lớp khởi động trong AOSP và không thuộc SDK công khai. Điều này bao gồm các API được trang trí bằng chú thích @hide nhưng không phải bằng @SystemAPI, như mô tả trong tài liệu SDK và các thành viên lớp riêng tư và gói riêng tư.
[C-0-6] PHẢI đi kèm với mọi giao diện không phải SDK trong cùng một danh sách bị hạn chế như được cung cấp thông qua cờ danh sách tạm thời và danh sách từ chối trong đường dẫn prebuilts/runtime/appcompat/hiddenapi-flags.csv cho nhánh cấp độ API thích hợp trong AOSP.
[C-0-7] PHẢI hỗ trợ cơ chế cập nhật động cấu hình đã ký để xoá các giao diện không phải SDK khỏi danh sách bị hạn chế bằng cách nhúng cấu hình đã ký vào bất kỳ tệp APK nào, sử dụng các khoá công khai hiện có trong AOSP.

Tuy nhiên, các chiến dịch này:
- CÓ THỂ, nếu một API ẩn không có hoặc được triển khai theo cách khác trên quá trình triển khai thiết bị, hãy di chuyển API ẩn đó vào danh sách từ chối hoặc loại bỏ API đó khỏi tất cả danh sách bị hạn chế.
- CÓ THỂ, nếu một API ẩn chưa tồn tại trong AOSP, hãy thêm API ẩn vào bất kỳ danh sách bị hạn chế nào.

Bắt đầu yêu cầu mới

[C-0-8] KHÔNG ĐƯỢC hỗ trợ cài đặt các ứng dụng nhắm đến cấp độ API thấp hơn 23.

Kết thúc các yêu cầu mới

3.1.1. Tiện ích Android

Android hỗ trợ mở rộng giao diện API được quản lý của một cấp độ API cụ thể bằng cách cập nhật phiên bản tiện ích cho cấp độ API đó. API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) trả về phiên bản tiện ích của apiLevel được cung cấp, nếu có tiện ích cho cấp độ API đó.

Cách triển khai trên thiết bị Android:

[C-0-1] PHẢI tải trước quá trình triển khai AOSP của cả thư viện dùng chung ExtShared và dịch vụ ExtServices có phiên bản lớn hơn hoặc bằng phiên bản tối thiểu được phép cho mỗi cấp độ API. Ví dụ: các hoạt động triển khai thiết bị Android 7.0, chạy API cấp 24 PHẢI bao gồm ít nhất phiên bản 1.
[C-0-2] CHỈ được trả về số phiên bản tiện ích hợp lệ do AOSP xác định.
[C-0-3] PHẢI hỗ trợ tất cả các API do các phiên bản tiện ích do android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) trả về xác định theo cách tương tự như các API được quản lý khác được hỗ trợ, tuân theo các yêu cầu trong phần 3.1.

3.1.2. Thư viện Android

Do ngừng sử dụng ứng dụng Apache HTTP, các hoạt động triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC đặt thư viện org.apache.http.legacy vào đường dẫn lớp khởi động.
[C-0-2] CHỈ được thêm thư viện org.apache.http.legacy vào đường dẫn lớp của ứng dụng khi ứng dụng đáp ứng một trong các điều kiện sau:
- Nhắm đến API cấp 28 trở xuống.
- Khai báo trong tệp kê khai rằng ứng dụng cần thư viện bằng cách đặt thuộc tính android:name của <uses-library> thành org.apache.http.legacy.

Việc triển khai AOSP đáp ứng các yêu cầu này.

3.2. Khả năng tương thích mềm của API

Ngoài các API được quản lý trong phần 3.1, Android cũng bao gồm một API "mềm" quan trọng chỉ trong thời gian chạy, dưới dạng các yếu tố như ý định, quyền và các khía cạnh tương tự của ứng dụng Android không thể được thực thi tại thời điểm biên dịch ứng dụng.

3.2.1. Quyền

[C-0-1] Người triển khai thiết bị PHẢI hỗ trợ và thực thi tất cả hằng số quyền như được ghi nhận trong Trang tham khảo về quyền. Xin lưu ý rằng mục 9 liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật của Android.

3.2.2. Tham số bản dựng

API Android bao gồm một số hằng số trên lớp android.os.Build dùng để mô tả thiết bị hiện tại.

[C-0-1] Để cung cấp các giá trị nhất quán và có ý nghĩa trên các hoạt động triển khai thiết bị, bảng bên dưới bao gồm các quy định hạn chế bổ sung về định dạng của các giá trị này mà hoạt động triển khai thiết bị PHẢI tuân thủ.

Thông số	Thông tin chi tiết
VERSION.RELEASE	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. Trường này PHẢI có một trong các giá trị chuỗi được xác định trong Chuỗi phiên bản được phép cho Android 14.
VERSION.SDK	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 14, trường này PHẢI có giá trị số nguyên 14_INT.
VERSION.SDK_INT	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 14, trường này PHẢI có giá trị số nguyên 14_INT.
VERSION.INCREMENTAL	Giá trị do người triển khai thiết bị chọn, chỉ định bản dựng cụ thể của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. KHÔNG ĐƯỢC sử dụng lại giá trị này cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Trường này thường được dùng để cho biết số bản dựng hoặc giá trị nhận dạng thay đổi trong hệ thống quản lý nguồn đã được dùng để tạo bản dựng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit có thể in và khớp với biểu thức chính quy “^[^ :\/~]+$”.
BẢNG	Giá trị do người triển khai thiết bị chọn để xác định phần cứng nội bộ cụ thể mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Bạn có thể sử dụng trường này để cho biết bản sửa đổi cụ thể của bảng điều khiển cấp nguồn cho thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
THƯƠNG HIỆU	Giá trị phản ánh tên thương hiệu được liên kết với thiết bị mà người dùng cuối biết. PHẢI ở định dạng mà con người có thể đọc được và NÊN đại diện cho nhà sản xuất thiết bị hoặc thương hiệu công ty mà thiết bị được tiếp thị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
SUPPORTED_32_BIT_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
SUPPORTED_64_BIT_ABIS	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI2	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
THIẾT BỊ	Giá trị do người triển khai thiết bị chọn, chứa tên phát triển hoặc tên mã xác định cấu hình của các tính năng phần cứng và thiết kế công nghiệp của thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9_-]+$". Tên thiết bị này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
VÂN TAY	Một chuỗi nhận dạng duy nhất bản dựng này. Tên này PHẢI ở dạng mà con người có thể đọc được một cách hợp lý. Tiêu đề phải tuân theo mẫu sau: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/myproduct/ mydevice:14/LMYXX/3359:userdebug/test-keys Vân tay KHÔNG ĐƯỢC chứa ký tự khoảng trắng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit.
PHẦN CỨNG	Tên của phần cứng (từ dòng lệnh hạt nhân hoặc /proc). Tên này PHẢI dễ đọc đối với con người. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9_-]+$".
MÁY CHỦ	Một chuỗi nhận dạng duy nhất máy chủ lưu trữ mà bản dựng được tạo, ở định dạng mà con người đọc được. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
ID	Giá trị nhận dạng do người triển khai thiết bị chọn để tham chiếu đến một bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống với android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị đủ ý nghĩa để người dùng cuối có thể phân biệt giữa các bản dựng phần mềm. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+$”.
NHÀ SẢN XUẤT	Tên thương mại của Nhà sản xuất thiết bị gốc (OEM) của sản phẩm. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
SOC_MANUFACTURER	Tên thương mại của nhà sản xuất hệ thống trên chip (SOC) chính được sử dụng trong sản phẩm. Các thiết bị có cùng nhà sản xuất SOC phải sử dụng cùng một giá trị không đổi. Vui lòng hỏi nhà sản xuất SOC về hằng số chính xác cần sử dụng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit, PHẢI khớp với biểu thức chính quy “^([0-9A-Za-z ]+)”, KHÔNG ĐƯỢC bắt đầu hoặc kết thúc bằng dấu cách và KHÔNG ĐƯỢC bằng "unknown". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
SOC_MODEL	Tên mô hình của hệ thống chính trên chip (SOC) dùng trong sản phẩm. Các thiết bị có cùng mô hình SOC phải sử dụng cùng một giá trị không đổi. Vui lòng hỏi nhà sản xuất SOC về hằng số chính xác cần sử dụng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^([0-9A-Za-z ._/+-]+)$", KHÔNG ĐƯỢC bắt đầu hoặc kết thúc bằng dấu cách và KHÔNG ĐƯỢC bằng "unknown". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
KIỂU MÁY	Giá trị do người triển khai thiết bị chọn, chứa tên của thiết bị mà người dùng cuối biết. Tên này PHẢI giống với tên mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
SẢN PHẨM	Giá trị do người triển khai thiết bị chọn, chứa tên phát triển hoặc tên mã của sản phẩm cụ thể (SKU) PHẢI là duy nhất trong cùng một thương hiệu. PHẢI là văn bản mà con người có thể đọc được, nhưng không nhất thiết là để người dùng cuối xem. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9_-]+$". Tên sản phẩm này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
ODM_SKU	Một giá trị không bắt buộc do người triển khai thiết bị chọn, chứa SKU (Mã đơn vị lưu kho) dùng để theo dõi các cấu hình cụ thể của thiết bị, ví dụ: mọi thiết bị ngoại vi đi kèm với thiết bị khi bán. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^([0-9A-Za-z.,_-]+)$`.
SỐ SÊ-RI	PHẢI trả về "UNKNOWN".
THẺ TỪ KHOÁ	Danh sách các thẻ được phân tách bằng dấu phẩy do người triển khai thiết bị chọn để phân biệt thêm bản dựng. Các thẻ PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+” và PHẢI có một trong các giá trị tương ứng với 3 cấu hình ký điển hình của nền tảng Android: khoá phát hành, khoá nhà phát triển và khoá kiểm thử.
THỜI GIAN	Giá trị đại diện cho dấu thời gian của thời điểm bản dựng xảy ra.
LOẠI	Giá trị do người triển khai thiết bị chọn, chỉ định cấu hình thời gian chạy của bản dựng. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình thời gian chạy Android thông thường: user, userdebug hoặc eng.
NGƯỜI DÙNG	Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) đã tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
SECURITY_PATCH	Giá trị cho biết cấp bản vá bảo mật của một bản dựng. Bản dựng PHẢI cho biết rằng bản dựng không gặp phải bất kỳ vấn đề nào được mô tả trong Bản tin công khai về bảo mật Android được chỉ định. Ngày phát hành PHẢI ở định dạng [YYYY-MM-DD], khớp với một chuỗi đã xác định được nêu trong Bản tin công khai về bảo mật Android hoặc trong Thông báo bảo mật Android, ví dụ: "2015-11-01".
BASE_OS	Một giá trị đại diện cho tham số FINGERPRINT của bản dựng giống hệt với bản dựng này, ngoại trừ các bản vá được cung cấp trong Bản tin bảo mật công khai của Android. Phương thức này PHẢI báo cáo giá trị chính xác và nếu không có bản dựng nào như vậy, hãy báo cáo một chuỗi trống ("").
BOOTLOADER	Giá trị do người triển khai thiết bị chọn để xác định phiên bản trình tải khởi động nội bộ cụ thể được sử dụng trong thiết bị, ở định dạng mà con người có thể đọc được. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9._-]+$".
getRadioVersion()	PHẢI (là hoặc trả về) một giá trị do người triển khai thiết bị chọn để xác định phiên bản radio/mô-đun nội bộ cụ thể được sử dụng trong thiết bị, ở định dạng mà con người có thể đọc được. Nếu không có đài/mô-đun nội bộ nào, thiết bị PHẢI trả về giá trị NULL. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9._-,]+$".
getSerial()	PHẢI (là hoặc trả về) 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ó thể mã hoá 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. Khả năng tương thích với ý định

3.2.3.1. Ý định phổ biến của ứng dụng

Ý định Android cho phép các thành phần ứng dụng yêu cầu chức năng từ các thành phần Android khác. Dự án ngược dòng Android bao gồm danh sách các ứng dụng triển khai một số mẫu ý định để thực hiện các thao tác phổ biến.

Triển khai trên thiết bị:

[C-SR-1] Bạn NÊN tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây và cung cấp phương thức thực hiện, tức là đáp ứng kỳ vọng của nhà phát triển đối với các ý định ứng dụng phổ biến này như mô tả trong SDK.

Vui lòng tham khảo Mục 2 để biết các ý định ứng dụng bắt buộc cho từng loại thiết bị.

3.2.3.2. Giải quyết ý định

[C-0-1] Vì Android là một nền tảng có thể mở rộng, nên việc triển khai thiết bị PHẢI cho phép các ứng dụng bên thứ ba ghi đè từng mẫu ý định được tham chiếu trong mục 3.2.3.1, ngoại trừ phần Cài đặt. Theo mặc định, việc triển khai nguồn mở Android ngược dòng cho phép điều này.
[C-0-2] Người triển khai thiết bị KHÔNG ĐƯỢC đính kèm các đặc quyền đặc biệt vào việc sử dụng các mẫu ý định này của ứng dụng hệ thống hoặc ngăn các ứng dụng bên thứ ba liên kết và giả định quyền kiểm soát các mẫu này. Quy định cấm này bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng "Công cụ chọn" cho phép người dùng chọn giữa nhiều ứng dụng đều xử lý cùng một mẫu ý định.
[C-0-3] Việc triển khai thiết bị PHẢI cung cấp giao diện người dùng để người dùng sửa đổi hoạt động mặc định cho ý định.
Tuy nhiên, việc triển khai thiết bị CÓ THỂ cung cấp các hoạt động mặc định cho các mẫu URI cụ thể (ví dụ: http://play.google.com) khi hoạt động mặc định cung cấp một thuộc tính cụ thể hơn cho URI dữ liệu. Ví dụ: mẫu bộ lọc ý định chỉ định URI dữ liệu "http://www.android.com" cụ thể hơn mẫu ý định cốt lõi của trình duyệt cho "http://".

Android cũng bao gồm một cơ chế để các ứng dụng bên thứ ba khai báo hành vi liên kết ứng dụng mặc định có thẩm quyền cho một số loại ý định URI web nhất định. Khi các nội dung khai báo có thẩm quyền như vậy được xác định trong mẫu bộ lọc ý định của ứng dụng, việc triển khai thiết bị sẽ:

[C-0-4] PHẢI cố gắng xác thực mọi bộ lọc ý định bằng cách thực hiện các bước xác thực được xác định trong thông số kỹ thuật về Đường liên kết đến tài sản kỹ thuật số do Trình quản lý gói triển khai trong Dự án nguồn mở Android ngược dòng.
[C-0-5] PHẢI xác thực bộ lọc ý định trong quá trình cài đặt ứng dụng và đặt tất cả bộ lọc ý định URI đã xác thực thành công làm trình xử lý ứng dụng mặc định cho URI của chúng.
CÓ THỂ đặt các bộ lọc ý định URI cụ thể làm trình xử lý ứng dụng mặc định cho URI của chúng, nếu các bộ lọc đó được xác minh thành công nhưng các bộ lọc URI đề xuất khác không xác minh được. Nếu triển khai thiết bị thực hiện việc này, thì thiết bị PHẢI cung cấp cho người dùng các ghi đè mẫu phù hợp cho mỗi URI trong trình đơn cài đặt.
PHẢI cung cấp cho người dùng các chế độ kiểm soát Đường liên kết trong ứng dụng theo ứng dụng trong phần Cài đặt như sau:
- [C-0-6] Người dùng PHẢI có thể ghi đè toàn diện hành vi liên kết ứng dụng mặc định để ứng dụng: luôn mở, luôn hỏi hoặc không bao giờ mở, đồng thời phải áp dụng như nhau cho tất cả bộ lọc ý định URI đề xuất.
- [C-0-7] Người dùng PHẢI xem được danh sách các bộ lọc ý định URI đề xuất.
- Việc triển khai thiết bị CÓ THỂ cho phép người dùng ghi đè các bộ lọc ý định URI đề xuất cụ thể đã được xác minh thành công, trên cơ sở mỗi bộ lọc ý định.
- [C-0-8] Việc triển khai thiết bị PHẢI cung cấp cho người dùng khả năng xem và ghi đè các bộ lọc ý định URI đề xuất cụ thể nếu việc triển khai thiết bị cho phép một số bộ lọc ý định URI đề xuất xác minh thành công trong khi một số bộ lọc khác có thể không xác minh được.

3.2.3.3. Không gian tên ý định

[C-0-1] Việc triển khai thiết bị KHÔNG ĐƯỢC bao gồm bất kỳ thành phần Android nào thực hiện bất kỳ mẫu ý định mới hoặc ý định truyền tin nào bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khoá khác trong không gian tên android.* hoặc com.android.*.
[C-0-2] Trình triển khai thiết bị KHÔNG ĐƯỢC đưa vào bất kỳ thành phần Android nào thực hiện bất kỳ ý định mới hoặc mẫu ý định truyền tin nào bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khoá khác trong không gian gói thuộc về một tổ chức khác.
[C-0-3] Người triển khai thiết bị KHÔNG ĐƯỢC thay đổi hoặc mở rộng bất kỳ mẫu ý định nào được liệt kê trong mục 3.2.3.1.
Việc triển khai thiết bị CÓ THỂ bao gồm các mẫu ý định sử dụng không gian tên được liên kết rõ ràng và rõ ràng với tổ chức của riêng thiết bị. Quy định cấm này tương tự như quy định được chỉ định cho các lớp ngôn ngữ Java trong mục 3.6.

3.2.3.4. Ý định truyền tin

Các ứng dụng bên thứ ba dựa vào nền tảng để truyền tin một số ý định nhất định nhằm thông báo cho các ứng dụng đó về những thay đổi trong môi trường phần cứng hoặc phần mềm.

Triển khai trên thiết bị:

[C-0-1] PHẢI truyền phát các ý định truyền tin công khai được liệt kê tại đây để phản hồi các sự kiện hệ thống thích hợp như mô tả trong tài liệu SDK. Xin lưu ý rằng yêu cầu này không xung đột với mục 3.5 vì giới hạn đối với các ứng dụng chạy ở chế độ nền cũng được mô tả trong tài liệu SDK. Ngoài ra, một số ý định truyền tin nhất định còn phụ thuộc vào khả năng hỗ trợ phần cứng. Nếu thiết bị hỗ trợ phần cứng cần thiết, thì chúng PHẢI truyền tin các ý định và cung cấp hành vi phù hợp với tài liệu SDK.

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

Android có các chế độ cài đặt giúp người dùng dễ dàng chọn ứng dụng mặc định, chẳng hạn như cho Màn hình chính hoặc SMS.

Khi thích hợp, việc triển khai thiết bị PHẢI cung cấp một trình đơn cài đặt tương tự và tương thích với mẫu bộ lọc ý định và các phương thức API được mô tả trong tài liệu SDK như bên dưới.

Nếu quá trình triển khai thiết bị báo cáo android.software.home_screen, thì các quá trình đó:

[C-1-1] PHẢI tuân thủ ý định android.settings.HOME_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho Màn hình chính.

Nếu quá trình triển khai thiết bị báo cáo android.hardware.telephony.calling, thì các quá trình đó:

[C-2-1] PHẢI cung cấp trình đơn cài đặt sẽ gọi ý định android.provider.Telephony.ACTION_CHANGE_DEFAULT để hiển thị hộp thoại thay đổi ứng dụng SMS mặc định.
[C-2-2] PHẢI tuân thủ ý định android.telecom.action.CHANGE_DEFAULT_DIALER để hiển thị hộp thoại cho phép người dùng thay đổi ứng dụng Điện thoại mặc định.
- PHẢI sử dụng giao diện người dùng của ứng dụng Điện thoại mặc định do người dùng chọn cho các cuộc gọi đến và đi, ngoại trừ các cuộc gọi khẩn cấp sẽ sử dụng ứng dụng Điện thoại cài sẵn.
[C-2-3] PHẢI tuân thủ ý định android.telecom.action.CHANGE_PHONE_ACCOUNTS để cung cấp cho người dùng khả năng định cấu hình ConnectionServices liên kết với PhoneAccounts, cũng như PhoneAccount mặc định mà nhà cung cấp dịch vụ viễn thông sẽ sử dụng để thực hiện cuộc gọi đi. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách đưa trình đơn "Tuỳ chọn tài khoản gọi" vào trình đơn cài đặt "Cuộc gọi".
[C-2-4] PHẢI cho phép android.telecom.CallRedirectionService cho một ứng dụng có vai trò android.app.role.CALL_REDIRECTION.
[C-2-5] PHẢI cung cấp cho người dùng khả năng chọn một ứng dụng có vai trò android.app.role.CALL_REDIRECTION.
[C-2-6] PHẢI tuân thủ ý định android.intent.action.SENDTO và android.intent.action.VIEW và cung cấp một hoạt động để gửi/hiển thị tin nhắn SMS.
[C-SR-1] Bạn NÊN tuân thủ các ý định android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW và android.intent.action.DIAL bằng một ứng dụng quay số được tải trước có thể xử lý các ý định này và thực hiện như mô tả trong SDK.

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc.hce, thì các quá trình đó:

[C-3-1] PHẢI tuân thủ ý định android.settings.NFC_PAYMENT_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho tính năng Thanh toán không tiếp xúc.
[C-3-2] PHẢI tuân thủ ý định android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT để hiển thị một hoạt động mở hộp thoại yêu cầu người dùng thay đổi dịch vụ mô phỏng thẻ mặc định cho một danh mục nhất định như mô tả trong SDK.

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc, thì các quá trình đó:

[C-4-1] PHẢI tuân thủ các ý định này android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, để hiển thị một hoạt động đáp ứng kỳ vọng của nhà phát triển đối với các ý định này như mô tả trong SDK.

Nếu quá trình triển khai thiết bị báo cáo android.hardware.bluetooth, thì các quá trình đó:

[C-5-1] PHẢI tuân thủ ý định "android.bluetooth.adapter.action.REQUEST_ENABLE" và hiển thị một hoạt động hệ thống để cho phép người dùng bật Bluetooth.
[C-5-2] PHẢI tuân thủ ý định "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" và hiển thị một hoạt động hệ thống yêu cầu chế độ có thể phát hiện.

Nếu việc triển khai thiết bị hỗ trợ tính năng Không làm phiền, thì các thiết bị đó sẽ:

[C-6-1] PHẢI triển khai một hoạt động phản hồi ý định ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Đối với các hoạt động triển khai bằng UI_MODE_TYPE_NORMAL, PHẢI là một hoạt động mà người dùng có thể cấp hoặc từ chối quyền truy cập của ứng dụng vào cấu hình chính sách DND.

Nếu việc triển khai thiết bị cho phép người dùng sử dụng phương thức nhập của bên thứ ba trên thiết bị, thì họ:

[C-7-1] PHẢI cung cấp một cơ chế mà người dùng có thể truy cập để thêm và định cấu hình các phương thức nhập của bên thứ ba nhằm phản hồi ý định android.settings.INPUT_METHOD_SETTINGS.

Nếu việc triển khai thiết bị hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba, thì các dịch vụ đó:

[C-8-1] PHẢI tuân thủ ý định android.settings.ACCESSIBILITY_SETTINGS để cung cấp cơ chế mà người dùng có thể truy cập nhằm bật và tắt các dịch vụ hỗ trợ tiếp cận của bên thứ ba cùng với các dịch vụ hỗ trợ tiếp cận được tải trước.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Wi-Fi Easy Connect và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-9-1] PHẢI triển khai API Ý định Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI như mô tả trong tài liệu SDK.

Nếu việc triển khai thiết bị cung cấp chế độ tiết kiệm dữ liệu, thì các thiết bị đó:

[C-10-1] PHẢI cung cấp giao diện người dùng trong phần cài đặt để xử lý ý định Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, cho phép người dùng thêm hoặc xoá ứng dụng khỏi danh sách cho phép.

Nếu không cung cấp chế độ tiết kiệm dữ liệu, thì các hoạt động triển khai thiết bị sẽ:

[C-11-1] PHẢI có một hoạt động xử lý ý định Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS nhưng CÓ THỂ triển khai hoạt động đó dưới dạng không hoạt động.

Nếu hoạt động triển khai thiết bị khai báo hỗ trợ máy ảnh thông qua android.hardware.camera.any, thì các hoạt động đó:

[C-12-3] PHẢI xử lý và PHẢI chỉ cho phép các ứng dụng Android được cài đặt sẵn xử lý các ý định sau đây MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE và MediaStore.ACTION_VIDEO_CAPTURE như mô tả trong tài liệu SDK.

Nếu quá trình triển khai thiết bị báo cáo android.software.device_admin, thì các quá trình đó:

[C-13-1] PHẢI tuân thủ ý định android.app.action.ADD_DEVICE_ADMIN để gọi giao diện người dùng đưa người dùng đến quy trình thêm quản trị viên thiết bị vào hệ thống (hoặc cho phép họ từ chối).
[C-13-2] PHẢI tuân thủ các ý định android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD và android.app.action.START_ENCRYPTION, đồng thời có một hoạt động để thực hiện các ý định này như mô tả trong SDK tại đây.

Nếu quá trình triển khai thiết bị khai báo cờ tính năng android.software.autofill, thì các thiết bị đó:

[C-14-1] PHẢI triển khai đầy đủ các API AutofillService và AutofillManager, đồng thời tuân thủ ý định android.settings.REQUEST_SET_AUTOFILL_SERVICE để hiển thị trình đơn cài đặt ứng dụng mặc định nhằm bật và tắt tính năng tự động điền cũng như thay đổi dịch vụ tự động điền mặc định cho người dùng.

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng được cài đặt sẵn hoặc muốn cho phép các ứng dụng bên thứ ba truy cập vào số liệu thống kê về mức sử dụng, thì các thiết bị đó:

[C-SR-2] NÊN cung cấp cơ chế mà người dùng có thể truy cập để cấp hoặc thu hồi quyền truy cập vào số liệu thống kê về mức sử dụng để phản hồi ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS cho các ứng dụng khai báo quyền android.permission.PACKAGE_USAGE_STATS.

Nếu việc triển khai thiết bị có ý định không cho phép bất kỳ ứng dụng nào, bao gồm cả ứng dụng cài đặt sẵn, truy cập vào số liệu thống kê về mức sử dụng, thì các thiết bị đó:

[C-15-1] VẪN PHẢI có một hoạt động xử lý mẫu ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS nhưng PHẢI triển khai hoạt động đó dưới dạng không hoạt động, tức là có hành vi tương đương như khi người dùng bị từ chối quyền truy cập.

Nếu hoạt động triển khai thiết bị hiển thị các đường liên kết đến các hoạt động do AutofillService_passwordsActivity chỉ định trong phần Cài đặt hoặc các đường liên kết đến mật khẩu của người dùng thông qua một cơ chế tương tự, thì các đường liên kết đó:

[C-16-1] PHẢI hiển thị các đường liên kết đó cho tất cả dịch vụ tự động điền đã cài đặt.

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 một lúc, thì các thiết bị đó:

[C-18-1] PHẢI tuân thủ ý định android.settings.ACTION_VOICE_INPUT_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho tính năng nhập liệu bằng giọng nói và trợ lý.

Nếu việc triển khai thiết bị báo cáo tính năng android.hardware.audio.output, thì các thiết bị đó:

[C-SR-3] Bạn NÊN tuân thủ ý định android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT có một hoạt động để cung cấp thực hiện cho các ý định này như mô tả trong SDK tại đây.

Android hỗ trợ trình bảo vệ màn hình tương tác, trước đây gọi là Dreams. Trình bảo vệ màn hình cho phép người dùng tương tác với các ứng dụng khi thiết bị được kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế sạc trên bàn. Triển khai trên thiết bị:

PHẢI hỗ trợ trình bảo vệ màn hình và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình trình bảo vệ màn hình nhằm phản hồi ý định android.settings.DREAM_SETTINGS.

Bắt đầu yêu cầu mới

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc.uicc hoặc android.hardware.nfc.ese, thì các thiết bị đó:

[C-19-1] PHẢI triển khai API Ý định NfcAdapter.ACTION_TRANSACTION_DETECTED (dưới dạng "EVT_TRANSACTION" do quy cách kỹ thuật TS.26 của Hiệp hội GSM – Yêu cầu đối với thiết bị cầm tay NFC) xác định.

Kết thúc các yêu cầu mới

3.2.4. Hoạt động trên màn hình phụ/nhiều màn hình

Nếu việc triển khai thiết bị cho phép khởi chạy Hoạt động Android thông thường trên nhiều màn hình, thì các thiết bị đó:

[C-1-1] PHẢI đặt cờ tính năng android.software.activities_on_secondary_displays.
[C-1-2] PHẢI đảm bảo khả năng tương thích của API tương tự như một hoạt động chạy trên màn hình chính.
[C-1-3] PHẢI đưa hoạt động mới đến cùng một màn hình với hoạt động đã khởi chạy hoạt động đó, khi hoạt động mới được khởi chạy mà không chỉ định màn hình mục tiêu thông qua API ActivityOptions.setLaunchDisplayId().
[C-1-4] PHẢI huỷ bỏ tất cả hoạt động khi xoá màn hình có cờ Display.FLAG_PRIVATE.
[C-1-5] PHẢI ẩn nội dung một cách an toàn trên tất cả màn hình khi thiết bị được khoá bằng màn hình khoá bảo mật, trừ phi ứng dụng chọn hiển thị trên đầu màn hình khoá bằng API Activity#setShowWhenLocked().
NÊN có android.content.res.Configuration tương ứng với màn hình đó để hiển thị, hoạt động chính xác và duy trì khả năng tương thích nếu một hoạt động được khởi chạy trên màn hình phụ.

Nếu việc triển khai thiết bị cho phép khởi chạy Hoạt động Android thông thường trên màn hình phụ và màn hình phụ có cờ android.view.Display.FLAG_PRIVATE:

[C-3-1] Chỉ chủ sở hữu của màn hình, hệ thống và các hoạt động đã có trên màn hình đó mới CÓ THỂ chạy trên màn hình đó. Mọi người đều có thể khởi chạy trên màn hình có cờ android.view.Display.FLAG_PUBLIC.

3.3. Khả năng tương thích với API gốc

Khả năng tương thích của mã gốc là một thách thức. Vì lý do này, người triển khai thiết bị là:

[C-SR-1] Bạn NÊN sử dụng các phương thức triển khai thư viện được liệt kê bên dưới từ Dự án nguồn mở Android ngược dòng.

3.3.1. Giao diện nhị phân của ứng dụng

Mã byte Dalvik được quản lý có thể gọi vào mã gốc được cung cấp trong tệp .apk của ứng dụng dưới dạng tệp .so ELF được biên dịch cho cấu trúc phần cứng thiết bị thích hợp. Vì mã gốc phụ thuộc nhiều vào công nghệ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân ứng dụng (ABI) trong Android NDK.

Triển khai trên thiết bị:

[C-0-1] PHẢI tương thích với một hoặc nhiều ABI Android NDK đã xác định.
[C-0-2] PHẢI hỗ trợ mã chạy trong môi trường được quản lý để gọi vào mã gốc, sử dụng ngữ nghĩa Giao diện gốc Java (JNI) tiêu chuẩn.
[C-0-3] PHẢI tương thích với nguồn (tức là tương thích với tiêu đề) và tương thích với tệp nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách bên dưới.
[C-0-5] PHẢI báo cáo chính xác Giao diện nhị phân của ứng dụng gốc (ABI) mà thiết bị hỗ trợ, thông qua các tham số android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS và android.os.Build.SUPPORTED_64_BIT_ABIS, mỗi tham số là một danh sách ABI được phân tách bằng dấu phẩy, được sắp xếp từ ABI được ưu tiên nhất đến ABI được ưu tiên ít nhất.
[C-0-6] BẮT BUỘC báo cáo, thông qua các thông số ở trên, một tập hợp con trong danh sách ABI sau đây và KHÔNG ĐƯỢC báo cáo bất kỳ ABI nào không có trong danh sách.
- armeabi (không còn được NDK hỗ trợ dưới dạng mục tiêu)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] PHẢI cung cấp tất cả các thư viện sau đây, cung cấp API gốc cho các ứng dụng có mã gốc:
- libaaudio.so (Hỗ trợ âm thanh gốc AAudio)
- libamidi.so (hỗ trợ MIDI gốc, nếu tính năng android.software.midi được xác nhận như mô tả trong Phần 5.9)
- libandroid.so (hỗ trợ hoạt động gốc trên Android)
- libc (thư viện C)
- libcamera2ndk.so
- libdl (trình liên kết động)
- libEGL.so (quản lý nền tảng OpenGL gốc)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Ghi nhật ký Android)
- libmediandk.so (hỗ trợ API nội dung nghe nhìn gốc)
- libm (thư viện toán học)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (hỗ trợ OpenMAX AL 1.0.1)
- libOpenSLES.so (hỗ trợ âm thanh OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (Hỗ trợ tối thiểu cho C++)
- libvulkan.so (Vulkan)
- libz (nén Zlib)
- Giao diện JNI
[C-0-8] KHÔNG ĐƯỢC thêm hoặc xoá các hàm công khai cho các thư viện gốc được liệt kê ở trên.
[C-0-9] PHẢI liệt kê các thư viện không phải AOSP khác được hiển thị trực tiếp cho ứng dụng bên thứ ba trong /vendor/etc/public.libraries.txt.
[C-0-10] KHÔNG ĐƯỢC hiển thị bất kỳ thư viện gốc nào khác, được triển khai và cung cấp trong AOSP dưới dạng thư viện hệ thống, cho các ứng dụng bên thứ ba nhắm đến API cấp 24 trở lên vì các thư viện này được đặt trước.
[C-0-11] PHẢI xuất tất cả các biểu tượng hàm OpenGL ES 3.1 và Gói tiện ích Android, như được xác định trong NDK, thông qua thư viện libGLESv3.so. Xin lưu ý rằng mặc dù tất cả các ký hiệu PHẢI có mặt, nhưng mục 7.1.4.1 mô tả chi tiết hơn về các yêu cầu đối với thời điểm triển khai đầy đủ từng hàm tương ứng.
[C-0-12] PHẢI xuất các biểu tượng hàm cho các biểu tượng hàm ~~Vulkan 1.0~~ Vulkan 1.1 cốt lõi, cũng như các tiện ích VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 và VK_KHR_get_physical_device_properties2 thông qua thư viện libvulkan.so. Xin lưu ý rằng mặc dù tất cả các ký hiệu PHẢI có mặt, nhưng mục 7.1.4.2 mô tả chi tiết hơn về các yêu cầu đối với thời điểm triển khai đầy đủ từng hàm tương ứng.
NÊN được tạo bằng mã nguồn và tệp tiêu đề có trong Dự án nguồn mở Android ngược dòng.

Xin lưu ý rằng các bản phát hành Android trong tương lai có thể hỗ trợ thêm các ABI.

3.3.2. Khả năng tương thích với mã gốc ARM 32 bit

Nếu quá trình triển khai thiết bị báo cáo việc hỗ trợ ABI armeabi, thì các quá trình đó:

[C-3-1] CŨNG PHẢI hỗ trợ armeabi-v7a và báo cáo việc hỗ trợ đó, vì armeabi chỉ dùng để tương thích ngược với các ứng dụng cũ.

Nếu quá trình triển khai thiết bị báo cáo việc hỗ trợ ABI armeabi-v7a, thì đối với các ứng dụng sử dụng ABI này, chúng sẽ:

[C-2-1] PHẢI đưa các dòng sau vào /proc/cpuinfo và KHÔNG được thay đổi các giá trị trên cùng một thiết bị, ngay cả khi các ABI khác đọc các giá trị đó.
- Features:, theo sau là danh sách các tính năng CPU ARMv7 không bắt buộc mà thiết bị hỗ trợ.
- CPU architecture:, theo sau là một số nguyên mô tả cấu trúc ARM được hỗ trợ cao nhất của thiết bị (ví dụ: "8" đối với thiết bị ARMv8).
[C-2-2] PHẢI luôn duy trì các thao tác sau, ngay cả trong trường hợp ABI được triển khai trên kiến trúc ARMv8, thông qua tính năng hỗ trợ CPU gốc hoặc thông qua tính năng mô phỏng phần mềm:
- Hướng dẫn SWP và SWPB.
- Thao tác rào chắn CP15ISB, CP15DSB và CP15DMB.
[C-2-3] PHẢI hỗ trợ tiện ích Advanced SIMD (còn gọi là NEON).

3.4. Khả năng tương thích với web

3.4.1. Khả năng tương thích với WebView

Nếu quá trình triển khai thiết bị cung cấp quá trình triển khai đầy đủ của API android.webkit.Webview, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo android.software.webview.
[C-1-2] PHẢI sử dụng bản dựng Dự án Chromium từ Dự án nguồn mở Android ngược dòng trên nhánh Android 14 để triển khai API android.webkit.WebView.
[C-1-3] Chuỗi tác nhân người dùng do WebView báo cáo PHẢI có định dạng như sau:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của android.os.Build.VERSION.RELEASE.
- Chuỗi $(MODEL) CÓ THỂ để trống, nhưng nếu không để trống thì CHẤP NHẬN có cùng giá trị với android.os.Build.MODEL.
- Bạn CÓ THỂ bỏ qua "Build/$(BUILD)", nhưng nếu có, chuỗi $(BUILD) PHẢI giống với giá trị của android.os.Build.ID.
- Giá trị của chuỗi $(CHROMIUM_VER) PHẢI là phiên bản Chromium trong Dự án nguồn mở Android ngược dòng.
- Việc triển khai thiết bị CÓ THỂ bỏ qua Di động trong chuỗi tác nhân người dùng.
Thành phần WebView PHẢI hỗ trợ nhiều tính năng HTML5 nhất có thể và nếu hỗ trợ tính năng này thì PHẢI tuân thủ quy cách HTML5.
[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 tạo bản sao WebView. Cụ thể, quy trình kết xuất riêng biệt PHẢI có đặc quyền thấp hơn, chạy dưới dạng mã nhận dạng 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 trực tiếp vào mạng và chỉ có quyền truy cập vào các dịch vụ hệ thống bắt buộc tối thiểu qua Binder. Việc triển khai WebView trên AOSP đáp ứng yêu cầu này.

Xin lưu ý rằng nếu việc triển khai thiết bị là 32 bit hoặc khai báo cờ tính năng android.hardware.ram.low, thì các thiết bị đó sẽ được miễn C-1-3.

3.4.2. Khả năng tương thích với trình duyệt

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng Trình duyệt độc lập để duyệt web chung, thì các ứng dụng đó:

[C-1-1] PHẢI hỗ trợ từng API sau đây liên kết với HTML5:
[C-1-2] PHẢI hỗ trợ API webstorage HTML5/W3C và NÊN hỗ trợ API IndexedDB HTML5/W3C. Xin lưu ý rằng khi các tổ chức tiêu chuẩn phát triển web chuyển sang ưu tiên IndexedDB thay vì webstorage, IndexedDB dự kiến sẽ trở thành một thành phần bắt buộc trong phiên bản Android trong tương lai.
CÓ THỂ gửi một chuỗi tác nhân người dùng tuỳ chỉnh trong ứng dụng Trình duyệt độc lập.
NÊN triển khai tính năng hỗ trợ nhiều HTML5 nhất có thể trên ứng dụng Trình duyệt độc lập (dù dựa trên ứng dụng Trình duyệt WebKit thượng nguồn hay ứng dụng thay thế của bên thứ ba).

Tuy nhiên, nếu quá trình triển khai thiết bị không bao gồm ứng dụng Trình duyệt độc lập, thì các thiết bị đó:

[C-2-1] VẪN PHẢI hỗ trợ các mẫu ý định công khai như mô tả trong phần 3.2.3.1.

3.5. Khả năng tương thích về hành vi của API

Triển khai trên thiết bị:

[C-0-9] PHẢI đảm bảo rằng khả năng tương thích về hành vi của API được áp dụng cho tất cả các ứng dụng đã cài đặt, trừ phi các ứng dụng đó bị hạn chế như mô tả trong Mục 3.5.1.
[C-0-10] KHÔNG ĐƯỢC triển khai phương pháp danh sách cho phép chỉ đảm bảo khả năng tương thích về hành vi của API đối với các ứng dụng do trình triển khai thiết bị chọn.

Hành vi của từng loại API (được quản lý, mềm, gốc và web) phải nhất quán với cách triển khai ưu tiên của Dự án nguồn mở Android ở thượng nguồn. Một số khía cạnh cụ thể về khả năng tương thích là:

[C-0-1] Thiết bị KHÔNG ĐƯỢC thay đổi hành vi hoặc ngữ nghĩa của một ý định chuẩn.
[C-0-2] Thiết bị KHÔNG ĐƯỢC thay đổi vòng đời hoặc ngữ nghĩa vòng đời của một loại thành phần hệ thống cụ thể (chẳng hạn như Dịch vụ, Hoạt động, ContentProvider, v.v.).
[C-0-3] Thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của một quyền tiêu chuẩn.
Thiết bị KHÔNG ĐƯỢC thay đổi các giới hạn được thực thi đối với ứng dụng chạy nền. Cụ thể hơn, đối với các ứng dụng chạy nền:
- [C-0-4] chúng PHẢI ngừng thực thi các lệnh gọi lại do ứng dụng đăng ký để nhận đầu ra từ GnssMeasurement và GnssNavigationMessage.
- [C-0-5] ứng dụng PHẢI giới hạn tốc độ cập nhật được cung cấp cho ứng dụng thông qua lớp API LocationManager hoặc phương thức WifiManager.startScan().
- [C-0-6] nếu ứng dụng nhắm đến API cấp 25 trở lên, thì ứng dụng KHÔNG ĐƯỢC phép đăng ký trình nhận truyền tin cho các thông báo truyền tin ngầm ẩn của ý định Android chuẩn trong tệp kê khai của ứng dụng, trừ phi ý định truyền tin yêu cầu quyền protectionLevel "signature" hoặc "signatureOrSystem" hoặc nằm trong danh sách miễn trừ.
- [C-0-7] nếu ứng dụng nhắm đến API cấp 25 trở lên, thì ứng dụng PHẢI dừng các dịch vụ trong nền của ứng dụng, giống như khi ứng dụng đã gọi phương thức stopSelf() của các dịch vụ, trừ phi ứng dụng được đưa vào danh sách cho phép tạm thời để xử lý một tác vụ mà người dùng có thể nhìn thấy.
- [C-0-8] nếu ứng dụng nhắm đến API cấp 25 trở lên, thì ứng dụng đó PHẢI giải phóng các khoá chế độ thức mà ứng dụng giữ.
[C-0-11] Thiết bị PHẢI trả về các trình cung cấp dịch vụ bảo mật sau đây dưới dạng 7 giá trị mảng đầu tiên từ phương thức Security.getProviders(), theo thứ tự đã cho và với tên đã cho (do Provider.getName() trả về) và các lớp, trừ phi ứng dụng đã sửa đổi danh sách thông qua insertProviderAt() hoặc removeProvider(). Thiết bị CÓ THỂ trả về các nhà cung cấp bổ sung sau danh sách nhà cung cấp được chỉ định bên dưới.
1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider – sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Danh sách bên trên chưa đầy đủ. Bộ kiểm tra tính tương thích (CTS) kiểm tra một số phần quan trọng của nền tảng để biết khả năng tương thích về hành vi, nhưng không phải tất cả. Bên triển khai có trách nhiệm đảm bảo khả năng tương thích về hành vi với Dự án nguồn mở Android. Vì lý do này, người triển khai thiết bị NÊN sử dụng mã nguồn có sẵn thông qua Dự án nguồn mở Android (nếu có thể) thay vì triển khai lại các phần quan trọng của hệ thống.

3.5.1. Hạn chế ứng dụng

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

[C-1-1] PHẢI cho phép người dùng xem danh sách ứ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ế độc quyền 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ề hành vi sức khoẻ hệ thống kém, nhưng CÓ THỂ áp dụng các hạn chế đối với ứng dụng khi phát hiện hành vi sức khoẻ hệ thống kém như bị kẹt khoá chế độ thức, các dịch vụ chạy trong thời gian dài và các tiêu chí khác. Các tiêu chí này CÓ THỂ do người triển khai thiết bị xác định 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. KHÔNG được sử dụng các tiêu chí khác không liên quan hoàn toàn đế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, làm tiêu chí.
[C-1-4] KHÔNG ĐƯỢC tự động áp dụng các quy định hạn chế độc quyền này cho ứng dụng khi người dùng đã tắt các quy định 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 quy định hạn chế độc quyền này.
[C-1-5] PHẢI thông báo cho người dùng nếu các hạn chế độc quyền này được tự động áp dụng cho ứng dụng. Bạn PHẢI cung cấp thông tin đó trong khoảng thời gian 24 giờ trước khi áp dụng các quy định hạn chế độc quyền này.
[C-1-6] PHẢI trả về giá trị true cho phương thức ActivityManager.isBackgroundRestricted() đối với mọi lệnh gọi API từ ứng dụng.
[C-1-7] KHÔNG ĐƯỢC hạn chế ứng dụng trên cùng ở nền trước mà người dùng sử dụng một cách rõ ràng.
[C-1-8] PHẢI tạm ngưng các quy định 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 ứng dụng đó thành ứng dụng trên nền trước hàng đầu.
[C-1-10] PHẢI cung cấp một tài liệu hoặc trang web công khai và rõ ràng mô tả cách áp dụng các quy định 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 từ tài liệu SDK Android và PHẢI bao gồm:
- Điều kiện kích hoạt các quy định hạn chế về quyền sở hữu.
- Nội dung và cách thức hạn chế một ứng dụng.
- Cách một ứng dụng có thể được miễn trừ khỏi các quy định hạn chế đó.
- Cách một ứng dụng có thể yêu cầu miễn trừ các quy định hạn chế về quyền sở hữu, nếu các quy định đó hỗ trợ việc miễn trừ cho các ứ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à người dùng chưa từng sử dụng ứng dụng đó trong hơn 30 ngày, thì [C-1-3] [C-1-5] sẽ được miễn trừ.

Nếu việc triển khai thiết bị mở rộng các hạn chế về ứng dụng được triển khai trong AOSP, thì các hạn chế đó:

[C-2-1]PHẢI tuân theo cách triển khai được mô tả trong tài liệu này.

3.5.2. Trạng thái ngủ đông của ứng dụng

Nếu quá trình triển khai thiết bị bao gồm tính năng Ngủ đông ứng dụng có trong AOSP hoặc mở rộng tính năng có trong AOSP, thì các thiết bị đó:

[C-1-1] PHẢI đáp ứng tất cả các yêu cầu trong mục 3.5.1 ngoại trừ [C-1-6] và [C-1-3].
[C-1-2] PHẢI chỉ áp dụng quy định hạn chế đối với ứng dụng cho người dùng khi có bằng chứng cho thấy người dùng đó không sử dụng ứng dụng trong một khoảng thời gian. Bạn NÊN chọn khoảng thời gian từ một tháng trở lên. LƯỢNG SỬ DỤNG PHẢI được xác định bằng một hành động tương tác rõ ràng của người dùng thông qua API UsageStats#getLastTimeVisible() hoặc bất kỳ điều gì khiến ứng dụng thoát khỏi trạng thái buộc dừng, bao gồm cả liên kết dịch vụ, liên kết nhà cung cấp nội dung, thông báo truyền tin rõ ràng, v.v., sẽ được theo dõi bằng API mới UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] CHỈ được áp dụng các quy định hạn chế ảnh hưởng đến tất cả người dùng thiết bị khi có bằng chứng cho thấy GÓI ĐÓ chưa được BẤT KỲ người dùng nào sử dụng trong một khoảng thời gian nào đó. Bạn NÊN chọn khoảng thời gian từ một tháng trở lên.
[C-1-4] KHÔNG ĐƯỢC khiến ứng dụng không thể phản hồi ý định hoạt động, liên kết dịch vụ, yêu cầu của nhà cung cấp nội dung hoặc thông báo truyền tin rõ ràng.

Chế độ ngủ đông ứng dụng trong AOSP đáp ứng các yêu cầu trên.

3.6. Không gian tên API

Android tuân theo các quy ước về không gian tên gói và lớp do ngôn ngữ lập trình Java xác định. Để đảm bảo khả năng tương thích với các ứng dụng bên thứ ba, người triển khai thiết bị KHÔNG ĐƯỢC thực hiện bất kỳ sửa đổi bị cấm nào (xem bên dưới) đối với các không gian tên gói sau:

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

Tức là:

[C-0-1] KHÔNG ĐƯỢC sửa đổi các API được hiển thị công khai trên nền tảng Android bằng cách thay đổi bất kỳ phương thức hoặc chữ ký lớp nào, hoặc bằng cách xoá các lớp hoặc trường lớp.
[C-0-2] KHÔNG ĐƯỢC thêm bất kỳ phần tử nào được hiển thị công khai (chẳng hạn như lớp hoặc giao diện, hoặc trường hoặc phương thức vào các lớp hoặc giao diện hiện có) hoặc API Kiểm thử hoặc API Hệ thống vào các API trong không gian tên ở trên. "Thành phần hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng điểm đánh dấu "@hide" như được sử dụng trong mã nguồn Android ngược dòng.

Người triển khai thiết bị CÓ THỂ sửa đổi phương thức triển khai cơ bản của các API, nhưng các sửa đổi đó:

[C-0-3] KHÔNG ĐƯỢC ảnh hưởng đến hành vi đã nêu và chữ ký ngôn ngữ Java của bất kỳ API nào được công khai.
[C-0-4] KHÔNG ĐƯỢC quảng cáo hoặc hiển thị cho nhà phát triển.

Tuy nhiên, người triển khai thiết bị CÓ THỂ thêm các API tuỳ chỉnh bên ngoài không gian tên Android tiêu chuẩn, nhưng các API tuỳ chỉnh:

[C-0-5] KHÔNG ĐƯỢC nằm trong không gian tên thuộc sở hữu hoặc tham chiếu đến một tổ chức khác. Ví dụ: người triển khai thiết bị KHÔNG ĐƯỢC thêm API vào com.google.* hoặc không gian tên tương tự: chỉ Google mới có thể làm như vậy. Tương tự, Google KHÔNG ĐƯỢC thêm API vào không gian tên của các công ty khác.
[C-0-6] PHẢI được đóng gói trong một thư viện dùng chung của Android để chỉ những ứng dụng sử dụng các API đó một cách rõ ràng (thông qua cơ chế <uses-library>) mới bị ảnh hưởng bởi mức sử dụng bộ nhớ tăng lên của các API đó.

Người triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh bằng ngôn ngữ gốc, bên ngoài API NDK, nhưng API tuỳ chỉnh:

[C-1-1] KHÔNG ĐƯỢC nằm trong thư viện NDK hoặc thư viện thuộc sở hữu của một tổ chức khác như mô tả tại đây.

Nếu một người triển khai thiết bị đề xuất cải thiện một trong các không gian tên gói ở trên (chẳng hạn như bằng cách thêm chức năng mới hữu ích vào một API hiện có hoặc thêm một API mới), thì người triển khai đó PHẢI truy cập vào source.android.com và bắt đầu quy trình đóng góp các thay đổi và mã, theo thông tin trên trang web đó.

Xin lưu ý rằng các quy định hạn chế ở trên tương ứng với các quy ước tiêu chuẩn để đặt tên cho API trong ngôn ngữ lập trình Java; mục này chỉ nhằm củng cố các quy ước đó và ràng buộc các quy ước đó thông qua việc đưa vào Định nghĩa về khả năng tương thích này.

3.7. Khả năng tương thích với thời gian chạy

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ định dạng có thể thực thi Dalvik (DEX) đầy đủ và quy cách và ngữ nghĩa mã byte Dalvik.
[C-0-2] PHẢI định cấu hình thời gian chạy Dalvik để phân bổ bộ nhớ theo nền tảng Android thượng nguồn và theo quy định của bảng sau. (Xem phần 7.1.1 để biết định nghĩa về kích thước màn hình và mật độ màn hình.)
NÊN sử dụng Android RunTime (ART), phương thức triển khai tham chiếu ngược dòng của Định dạng thực thi Dalvik và hệ thống quản lý gói của phương thức triển khai tham chiếu.
NÊN chạy kiểm thử tìm lỗi mã nguồn trong nhiều chế độ thực thi và cấu trúc mục tiêu để đảm bảo tính ổn định của thời gian chạy. Tham khảo JFuzz và DexFuzz trên trang web Dự án nguồn mở Android.

Xin lưu ý rằng các giá trị bộ nhớ được chỉ định bên dưới được coi là giá trị tối thiểu và việc triển khai thiết bị CÓ THỂ phân bổ nhiều bộ nhớ hơn cho mỗi ứng dụng.

Bố cục màn hình	Mật độ màn hình	Bộ nhớ tối thiểu của ứng dụng
Android Watch	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
nhỏ/bình thường	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96 MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
lớn	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)	48MB
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)	80MB
	180 dpi (180dpi)	96 MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288 MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Khả năng tương thích của giao diện người dùng

3.8.1. Trình chạy (Màn hình chính)

Android bao gồm một ứng dụng trình chạy (màn hình chính) và hỗ trợ các ứng dụng bên thứ ba để thay thế trình chạy thiết bị (màn hình chính).

Nếu quá trình triển khai thiết bị cho phép các ứng dụng bên thứ ba thay thế màn hình chính của thiết bị, thì các ứng dụng đó:

[C-1-1] BẮT BUỘC khai báo tính năng nền tảng android.software.home_screen.
[C-1-2] PHẢI trả về đối tượng AdaptiveIconDrawable khi ứng dụng bên thứ ba sử dụng thẻ <adaptive-icon> để cung cấp biểu tượng và các phương thức PackageManager để truy xuất biểu tượng được gọi.

Nếu việc triển khai thiết bị bao gồm một trình chạy mặc định hỗ trợ tính năng ghim lối tắt trong ứng dụng, thì các thiết bị đó:

[C-2-1] PHẢI báo cáo true cho ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] PHẢI có khả năng hỗ trợ người dùng yêu cầu người dùng trước khi thêm lối tắt do ứng dụng yêu cầu thông qua phương thức API ShortcutManager.requestPinShortcut().
[C-2-3] PHẢI hỗ trợ lối tắt được ghim và lối tắt tĩnh và động như được ghi nhận trên trang Lối tắt ứng dụng.

Ngược lại, nếu việc triển khai thiết bị không hỗ trợ ghim lối tắt trong ứng dụng, thì các thiết bị đó:

[C-3-1] PHẢI báo cáo false cho ShortcutManager.isRequestPinShortcutSupported().

Nếu việc triển khai thiết bị triển khai một trình chạy mặc định cung cấp quyền truy cập nhanh vào các lối tắt bổ sung do các ứng dụng bên thứ ba cung cấp thông qua API ShortcutManager, thì các trình chạy đó:

[C-4-1] PHẢI hỗ trợ tất cả các tính năng lối tắt được ghi nhận (ví dụ: lối tắt tĩnh và động, ghim lối tắt) và triển khai đầy đủ các API của lớp API ShortcutManager.

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng trình chạy mặc định hiển thị huy hiệu cho biểu tượng ứng dụng, thì các huy hiệu đó:

[C-5-1] PHẢI tuân thủ phương thức API NotificationChannel.setShowBadge(). Nói cách khác, hãy hiển thị một tính năng trực quan liên kết với biểu tượng ứng dụng nếu giá trị được đặt thành true và không hiển thị bất kỳ chương trình gắn huy hiệu biểu tượng ứng dụng nào khi tất cả các kênh thông báo của ứng dụng đã đặt giá trị thành false.
CÓ THỂ ghi đè huy hiệu biểu tượng ứng dụng bằng giao thức huy hiệu độc quyền khi các ứng dụng bên thứ ba cho biết hỗ trợ giao thức huy hiệu độc quyền thông qua việc sử dụng các API độc quyền, nhưng PHẢI sử dụng tài nguyên và giá trị được cung cấp thông qua API huy hiệu thông báo được mô tả trong SDK, chẳng hạn như Notification.Builder.setNumber() và API Notification.Builder.setBadgeIconType().

Nếu quá trình triển khai thiết bị hỗ trợ biểu tượng đơn sắc, thì các biểu tượng này:

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

3.8.2. Tiện ích

Android hỗ trợ các tiện ích ứng dụng của bên thứ ba bằng cách xác định loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị “AppWidget” cho người dùng cuối.

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

[C-1-1] PHẢI khai báo hỗ trợ tính năng nền tảng android.software.app_widgets.
[C-1-2] PHẢI có tính năng hỗ trợ tích hợp cho AppWidgets và hiển thị các tính năng giao diện người dùng để thêm, định cấu hình, xem và xoá AppWidgets
[C-1-3] PHẢI có khả năng hiển thị các tiện ích có kích thước 4 x 4 trong lưới tiêu chuẩn. Hãy xem Nguyên tắc thiết kế tiện ích ứng dụng trong tài liệu SDK Android để biết thông tin chi tiết.
CÓ THỂ hỗ trợ tiện ích ứng dụng trên màn hình khoá.

Nếu việc triển khai thiết bị hỗ trợ tiện ích ứng dụng bên thứ ba và tính năng ghim lối tắt trong ứng dụng, thì các tiện ích đó:

[C-2-1] PHẢI báo cáo true cho AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] PHẢI có khả năng hỗ trợ người dùng yêu cầu người dùng trước khi thêm lối tắt do ứng dụng yêu cầu thông qua phương thức API AppWidgetManager.requestPinAppWidget().

3.8.3. Thông báo

Android bao gồm các API Notification và NotificationManager cho phép nhà phát triển ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý và thu hút sự chú ý của người dùng bằng cách sử dụng các thành phần phần cứng (ví dụ: âm thanh, độ rung và ánh sáng) và các tính năng phần mềm (ví dụ: ngăn thông báo, thanh hệ thống) của thiết bị.

3.8.3.1. Trình bày thông báo

Nếu việc triển khai thiết bị cho phép ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý, thì các ứng dụng đó:

[C-1-1] PHẢI hỗ trợ các thông báo sử dụng các tính năng phần cứng, như mô tả trong tài liệu SDK và trong phạm vi có thể với phần cứng triển khai thiết bị. Ví dụ: nếu việc triển khai thiết bị bao gồm một bộ rung, thì thiết bị đó PHẢI triển khai chính xác các API rung. Nếu quá trình triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7.
[C-1-2] PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp ảnh động, v.v.) được cung cấp trong API hoặc trong hướng dẫn về kiểu biểu tượng của Thanh trạng thái/Hệ thống, mặc dù các tài nguyên này CÓ THỂ mang lại trải nghiệm người dùng thay thế cho thông báo so với trải nghiệm do cách triển khai tham chiếu Android Open Source cung cấp.
[C-1-3] PHẢI tuân thủ và triển khai đúng cách các hành vi được mô tả cho API để cập nhật, xoá và nhóm thông báo.
[C-1-4] PHẢI cung cấp toàn bộ hành vi của API NotificationChannel được ghi lại trong SDK.
[C-1-5] PHẢI cung cấp cho người dùng khả năng chặn và sửa đổi thông báo của một ứng dụng bên thứ ba nhất định theo từng kênh và cấp gói ứng dụng.
[C-1-6] CŨNG PHẢI cung cấp cho người dùng khả năng hiển thị các kênh thông báo đã xoá.
[C-1-7] PHẢI hiển thị chính xác tất cả tài nguyên (hình ảnh, hình dán, biểu tượng, v.v.) được cung cấp thông qua Notification.MessagingStyle cùng với văn bản thông báo mà không cần người dùng tương tác thêm. Ví dụ: PHẢI hiển thị tất cả tài nguyên, bao gồm cả biểu tượng được cung cấp thông qua android.app.Person trong cuộc trò chuyện nhóm được đặt thông qua setGroupConversation.
[C-SR-1] NÊN cung cấp một tính năng để người dùng kiểm soát các thông báo hiển thị cho những ứng dụng đã được cấp quyền Trình nghe thông báo. Độ chi tiết PHẢI như vậy để người dùng có thể kiểm soát cho từng trình nghe thông báo như vậy những loại thông báo được kết nối với trình nghe này. Các loại này PHẢI bao gồm thông báo "cuộc trò chuyện", "cảnh báo", "không âm thanh" và "liên tục quan trọng".
[C-SR-2] NÊN cung cấp một tính năng để người dùng chỉ định các ứng dụng cần loại trừ khỏi việc thông báo cho bất kỳ trình nghe thông báo cụ thể nào.
[C-SR-3] NÊN tự động hiển thị một khả năng cho phép người dùng chặn thông báo của một ứng dụng bên thứ ba nhất định theo từng kênh và cấp gói ứng dụng sau khi người dùng đóng thông báo đó nhiều lần.
PHẢI hỗ trợ thông báo đa dạng thức.
NÊN hiển thị một số thông báo có mức độ ưu tiên cao hơn dưới dạng thông báo quan trọng.
NÊN có khả năng người dùng tạm ẩn thông báo.
CHỈ ĐƯỢC quản lý chế độ hiển thị và thời điểm ứng dụng bên thứ ba có thể thông báo cho người dùng về các sự kiện đáng chú ý để giảm thiểu các vấn đề về an toàn, chẳng hạn như làm người lái xe mất tập trung.

Android 11 ra mắt tính năng hỗ trợ thông báo cuộc trò chuyện. Đây là các thông báo sử dụng MessagingStyle và cung cấp mã lối tắt People đã xuất bản.

Triển khai trên thiết bị:

[C-SR-4] Bạn NÊN nhóm và hiển thị conversation notifications trước các thông báo không phải cuộc trò chuyện, ngoại trừ các thông báo dịch vụ trên nền trước đang diễn ra và thông báo importance:high.

Nếu việc triển khai thiết bị hỗ trợ conversation notifications và ứng dụng cung cấp dữ liệu bắt buộc cho bubbles, thì các thiết bị đó:

[C-SR-5] Bạn NÊN hiển thị cuộc trò chuyện này dưới dạng bong bóng trò chuyện. Việc triển khai AOSP đáp ứng các yêu cầu này bằng giao diện người dùng hệ thống, cài đặt và trình chạy mặc định.

Nếu việc triển khai thiết bị hỗ trợ thông báo đa dạng thức, thì các thiết bị đó:

[C-2-1] PHẢI sử dụng chính xác các tài nguyên được cung cấp thông qua lớp API Notification.Style và các lớp con của lớp đó cho các phần tử tài nguyên được trình bày.
NÊN trình bày từng phần tử tài nguyên (ví dụ: biểu tượng, tiêu đề và văn bản tóm tắt) được xác định trong lớp API Notification.Style và các lớp con của lớp đó.

Thông báo quan trọng là thông báo được trình bày cho người dùng khi thông báo đó đến độc lập với giao diện mà người dùng đang sử dụng. Nếu quá trình triển khai thiết bị hỗ trợ thông báo quan trọng, thì các thiết bị đó:

[C-3-1] PHẢI sử dụng thành phần hiển thị và tài nguyên thông báo quan trọng như mô tả trong lớp API Notification.Builder khi hiển thị thông báo quan trọng.
[C-3-2] PHẢI hiển thị các thao tác được cung cấp thông qua Notification.Builder.addAction() cùng với nội dung thông báo mà không cần người dùng tương tác thêm như mô tả trong SDK.

3.8.3.2. Dịch vụ trình nghe thông báo

Android bao gồm các API NotificationListenerService cho phép ứng dụng (sau khi người dùng bật rõ ràng) nhận bản sao của tất cả thông báo khi thông báo được đăng hoặc cập nhật.

Triển khai trên thiết bị:

[C-0-1] PHẢI cập nhật toàn bộ thông báo một cách chính xác và kịp thời cho tất cả các dịch vụ trình nghe đã cài đặt và do người dùng bật, bao gồm mọi siêu dữ liệu được đính kèm vào đối tượng Thông báo.
[C-0-2] PHẢI tuân thủ lệnh gọi API snoozeNotification(), đồng thời đóng thông báo và thực hiện lệnh gọi lại sau khoảng thời gian báo cáo được đặt trong lệnh gọi API.

Nếu việc triển khai thiết bị có khả năng hỗ trợ người dùng tạm ẩn thông báo, thì chúng:

[C-1-1] PHẢI phản ánh chính xác trạng thái thông báo bị tạm ngưng thông qua các API chuẩn như NotificationListenerService.getSnoozedNotifications().
[C-1-2] PHẢI cung cấp tính năng này cho người dùng để họ có thể tạm hoãn thông báo từ mỗi ứng dụng bên thứ ba đã cài đặt, trừ phi đó là thông báo từ các dịch vụ liên tục/trên nền trước.

3.8.3.3. Chế độ 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 Không làm phiền (còn gọi là Chế độ ưu tiên), thì các thiết bị đó sẽ:

[C-1-1] BẮT BUỘC, khi việc triển khai thiết bị đã cung cấp cho người dùng một phương tiện để cấp hoặc từ chối quyền truy cập vào cấu hình chính sách Không làm phiền cho các ứng dụng bên thứ ba, hãy hiển thị Quy tắc DND tự động do các ứng dụng tạo cùng với các quy tắc do người dùng tạo và được xác định trước.
[C-1-3] PHẢI tuân thủ các giá trị suppressedVisualEffects được truyền dọc theo NotificationManager.Policy và nếu một ứng dụng đã đặt bất kỳ cờ nào trong số SUPPRESSED_EFFECT_SCREEN_OFF hoặc SUPPRESSED_EFFECT_SCREEN_ON, thì ứng dụng đó PHẢI cho người dùng biết rằng các hiệu ứng hình ảnh bị tắt trong trình đơn cài đặt chế độ Không làm phiền.

3.8.4. API Trợ lý

Android bao gồm API Trợ lý để cho phép các ứng dụng chọn lượng thông tin về ngữ cảnh hiện tại được chia sẻ với trợ lý trên thiết bị.

Nếu việc triển khai thiết bị hỗ trợ thao tác Hỗ trợ, thì các thiết bị đó:

[C-2-1] PHẢI cho người dùng cuối biết rõ thời điểm chia sẻ ngữ cảnh bằng cách:
- Mỗi khi ứng dụng trợ lý truy cập vào ngữ cảnh, hãy hiển thị một ánh sáng trắng xung quanh các cạnh của màn hình đáp ứng hoặc vượt quá thời lượng và độ sáng của quá trình triển khai Dự án nguồn mở Android.
- Đối với ứng dụng hỗ trợ được cài đặt sẵn, hãy cung cấp cho người dùng một khả năng hỗ trợ ít hơn hai thao tác điều hướng từ trình đơn cài đặt ứng dụng hỗ trợ và phương thức nhập bằng giọng nói mặc định, đồng thời chỉ chia sẻ ngữ cảnh khi người dùng gọi ứng dụng hỗ trợ một cách rõ ràng thông qua cụm từ kích hoạt hoặc phương thức nhập bằng phím điều hướng hỗ trợ.
[C-2-2] Hoạt động tương tác được chỉ định để chạy ứng dụng hỗ trợ như mô tả trong mục 7.2.3 PHẢI chạy ứng dụng hỗ trợ do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService hoặc một hoạt động xử lý ý định ACTION_ASSIST.

3.8.5. Cảnh báo và thông báo ngắn

Các ứng dụng có thể sử dụng API Toast để hiển thị các chuỗi ngắn không theo phương thức phương thức cho người dùng cuối và các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn, đồng thời sử dụng API loại cửa sổ TYPE_APPLICATION_OVERLAY để hiển thị cửa sổ cảnh báo dưới dạng lớp phủ trên các ứng dụng khác.

Nếu quá trình triển khai thiết bị bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[C-1-1] PHẢI cung cấp cho người dùng khả năng chặn ứng dụng hiển thị cửa sổ cảnh báo sử dụng TYPE_APPLICATION_OVERLAY. Cách triển khai AOSP đáp ứng yêu cầu này bằng cách có các chế độ điều khiển trong ngăn thông báo.
[C-1-2] PHẢI tuân thủ Toast API và hiển thị thông báo ngắn từ các ứng dụng cho người dùng cuối theo một cách rất rõ ràng.

3.8.6. Giao diện

Android cung cấp "giao diện" dưới dạng một cơ chế để các ứng dụng áp dụng kiểu trên toàn bộ Hoạt động hoặc ứng dụng.

Android bao gồm một gia đình giao diện "Holo" và "Material" dưới dạng một tập hợp các kiểu được xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn khớp với giao diện của giao diện Holo do SDK Android xác định.

Nếu quá trình triển khai thiết bị bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[C-1-1] KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Holo nào hiển thị với các ứng dụng.
[C-1-2] PHẢI hỗ trợ gia đình giao diện "Material" và KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Material nào hoặc các thành phần hiển thị với ứng dụng.
[C-1-3] PHẢI đặt bộ phông chữ "sans-serif" thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ hoặc cung cấp cho người dùng khả năng thay đổi phông chữ dùng cho bộ phông chữ "sans-serif" thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ.
[C-1-4] PHẢI tạo bảng sắc độ màu động như được chỉ định trong tài liệu AOSP về Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (xem android.theme.customization.system_palette và android.theme.customization.theme_style).
[C-1-5] PHẢI tạo bảng sắc độ màu động bằng cách sử dụng các kiểu giao diện 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, vàMONOCHROMATIC.

"Màu nguồn" dùng để tạo bảng sắc độ màu động khi được gửi bằng android.theme.customization.system_palette (như được ghi lại trong Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] PHẢI có giá trị sắc độ CAM16 từ 5 trở lên.
- NÊN được lấy từ hình nền thông 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.

Android cũng bao gồm một nhóm giao diện "Mặc định của thiết bị" dưới dạng một tập hợp các kiểu được xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn khớp giao diện của giao diện thiết bị như được xác định bởi trình triển khai thiết bị.

Việc triển khai thiết bị CÓ THỂ sửa đổi các thuộc tính giao diện mặc định của thiết bị hiển thị với các ứng dụng.

Android hỗ trợ giao diện biến thể với các thanh hệ thống mờ, cho phép nhà phát triển ứng dụng lấp đầy khu vực phía sau thanh trạng thái và thanh điều hướng bằng nội dung ứng dụng của họ. Để mang lại trải nghiệm nhất quán cho nhà phát triển trong cấu hình này, điều quan trọng là bạn phải duy trì kiểu biểu tượng thanh trạng thái trên nhiều cách triển khai thiết bị.

Nếu việc triển khai thiết bị bao gồm thanh trạng thái hệ thống, thì các thiết bị đó:

[C-2-1] PHẢI sử dụng màu trắng cho biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) và thông báo do hệ thống đưa ra, trừ phi biểu tượng đó cho biết trạng thái có vấn đề hoặc ứng dụng yêu cầu thanh trạng thái sáng bằng cách sử dụng cờ WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] Việc triển khai thiết bị Android PHẢI thay đổi màu của các biểu tượng trạng thái hệ thống thành màu đen (để biết thông tin chi tiết, hãy tham khảo R.style) khi một ứng dụng yêu cầu thanh trạng thái sáng.

3.8.7. Hình nền động (Live Wallpaper)

Android xác định một loại thành phần, API và vòng đời tương ứng cho phép ứng dụng hiển thị một hoặc nhiều "Hình nền động" cho người dùng cuối. Hình nền động là ảnh động, mẫu hoặc hình ảnh tương tự với chức năng nhập hạn chế, hiển thị dưới dạng hình nền, phía sau các ứng dụng khác.

Phần cứng được coi là có khả năng chạy hình nền động một cách đáng tin cậy nếu có thể chạy tất cả hình nền động, không có giới hạn về chức năng, ở tốc độ khung hình hợp lý mà không ảnh hưởng bất lợi đến các ứng dụng khác. Nếu các giới hạn về phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, hoạt động không đúng cách, tiêu thụ quá nhiều CPU hoặc pin hoặc chạy ở tốc độ khung hình thấp không chấp nhận được, thì phần cứng đó được coi là không thể chạy hình nền động. Ví dụ: một số hình nền động có thể sử dụng ngữ cảnh OpenGL 2.0 hoặc 3.x để hiển thị nội dung của chúng. Hình nền động sẽ không chạy ổn định trên phần cứng không hỗ trợ nhiều ngữ cảnh OpenGL vì việc sử dụng ngữ cảnh OpenGL của hình nền động có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.

Các phương thức triển khai thiết bị có thể chạy hình nền động một cách đáng tin cậy như mô tả ở trên PHẢI triển khai hình nền động.

Nếu triển khai hình nền động, các thiết bị sẽ:

[C-1-1] PHẢI báo cáo cờ tính năng nền tảng android.software.live_wallpaper.

3.8.8. Chuyển đổi hoạt động

Mã nguồn Android ngược dòng bao gồm màn hình tổng quan, một giao diện người dùng cấp hệ thống để chuyển đổi tác vụ và hiển thị các hoạt động và tác vụ được truy cập gần đây bằng hình thu nhỏ của trạng thái đồ hoạ của ứng dụng tại thời điểm người dùng rời khỏi ứng dụng lần gần nhất.

Việc triển khai thiết bị, bao gồm cả phím điều hướng chức năng gần đây như được nêu chi tiết trong mục 7.2.3 CÓ THỂ làm thay đổi giao diện.

[C-1-1] PHẢI hỗ trợ ít nhất 7 hoạt động hiển thị.
PHẢI hiển thị ít nhất tiêu đề của 4 hoạt động cùng một lúc.

~~[C-1-2] PHẢI triển khai hành vi ghim màn hình và cung cấp cho người dùng một trình đơn cài đặt để bật/tắt tính năng này.~~

NÊN hiển thị màu làm nổi bật, biểu tượng, tiêu đề màn hình trong phần gần đây.
NÊN hiển thị một đối tượng đóng ("x") nhưng CÓ THỂ trì hoãn việc này cho đến khi người dùng tương tác với màn hình.
NÊN triển khai một lối tắt để dễ dàng chuyển sang hoạt động trước đó.
NÊN kích hoạt thao tác chuyển đổi nhanh giữa hai ứng dụng được sử dụng gần đây nhất, khi nhấn đúp vào phím chức năng gần đây.
NÊN kích hoạt chế độ nhiều cửa sổ chia đôi màn hình (nếu được hỗ trợ) khi nhấn và giữ phím chức năng gần đây.
CÓ THỂ hiển thị các nội dung gần đây được liên kết dưới dạng một nhóm di chuyển cùng nhau.
[C-SR-1] Bạn NÊN sử dụng giao diện người dùng Android ngược dòng (hoặc giao diện dựa trên hình thu nhỏ tương tự) cho màn hình tổng quan.

3.8.9. Quản lý đầu vào

Android hỗ trợ tính năng Quản lý phương thức nhập và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba.

Nếu việc triển khai thiết bị cho phép người dùng sử dụng phương thức nhập của bên thứ ba trên thiết bị, thì họ:

[C-1-1] PHẢI khai báo tính năng nền tảng android.software.input_methods và hỗ trợ các API IME như được xác định trong tài liệu SDK Android.

3.8.10. Điều khiển nội dung nghe nhìn trên màn hình khoá

API ứng dụng điều khiển từ xa không còn được dùng nữa từ Android 5.0 mà thay vào đó là Mẫu thông báo nội dung nghe nhìn cho phép các ứng dụng đa phương tiện tích hợp với các nút điều khiển phát hiển thị trên màn hình khoá.

3.8.11. Trình bảo vệ màn hình (trước đây là Ước mơ)

Xem phần 3.2.3.5 để biết ý định cài đặt nhằm định cấu hình trình bảo vệ màn hình.

3.8.12. Vị trí

Nếu quá trình triển khai thiết bị bao gồm một cảm biến phần cứng (ví dụ: GPS) có thể cung cấp toạ độ, thì các thiết bị đó

[C-1-2] PHẢI hiển thị trạng thái hiện tại của thông tin vị trí trong trình đơn Vị trí trong phần Cài đặt.
[C-1-3] KHÔNG ĐƯỢC hiển thị các chế độ vị trí trong trình đơn Vị trí trong phần Cài đặt.

3.8.13. Unicode và phông chữ

Android hỗ trợ các ký tự biểu tượng cảm xúc được xác định trong Unicode 10.0.

Nếu quá trình triển khai thiết bị bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[C-1-1] PHẢI có khả năng hiển thị các ký tự biểu tượng cảm xúc này ở dạng ký tự màu.
[C-1-2] PHẢI hỗ trợ:
- Phông chữ Roboto 2 có nhiều độ đậm – sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light cho các ngôn ngữ có trên thiết bị.
- Bao gồm đầy đủ Unicode 7.0 cho tiếng Latinh, tiếng Hy Lạp và tiếng Cyrillic, bao gồm cả các phạm vi Latinh mở rộng A, B, C và D, cũng như tất cả các ký tự trong khối ký hiệu tiền tệ của Unicode 7.0.
[C-1-3] KHÔNG ĐƯỢC xoá hoặc sửa đổi NotoColorEmoji.tff trong hình ảnh hệ thống. (Bạn có thể thêm phông chữ biểu tượng cảm xúc mới để ghi đè biểu tượng cảm xúc trong NotoColorEmoji.tff)
PHẢI hỗ trợ màu da và các biểu tượng cảm xúc đa dạng về gia đình như được chỉ định trong Báo cáo kỹ thuật Unicode số 51.

Nếu quá trình triển khai thiết bị bao gồm IME, thì các thiết bị đó:

PHẢI cung cấp phương thức nhập cho người dùng để nhập các ký tự biểu tượng cảm xúc này.

Android hỗ trợ hiển thị phông chữ Myanmar. Myanmar có một số phông chữ không tuân thủ Unicode, thường được gọi là "Zawgyi" để hiển thị các ngôn ngữ Myanmar.

Nếu việc triển khai thiết bị có hỗ trợ tiếng Miến Điện, thì các thiết bị đó:

[C-2-1] PHẢI hiển thị văn bản bằng phông chữ tuân thủ Unicode làm mặc định; KHÔNG ĐƯỢC đặt phông chữ không tuân thủ Unicode làm phông chữ mặc định trừ phi người dùng chọn phông chữ đó trong bộ chọn ngôn ngữ.
[C-2-2] PHẢI hỗ trợ phông chữ Unicode và phông chữ tuân thủ Unicode nếu thiết bị hỗ trợ phông chữ tuân thủ Unicode. Phông chữ không tuân thủ Unicode KHÔNG ĐƯỢC xoá hoặc ghi đè phông chữ Unicode.
[C-2-3] PHẢI hiển thị văn bản bằng phông chữ không tuân thủ Unicode CHỈ KHI mã ngôn ngữ có mã tập lệnh Qaag được chỉ định (ví dụ: my-Qaag). Bạn không thể sử dụng mã ngôn ngữ hoặc mã khu vực ISO nào khác (dù đã chỉ định, chưa chỉ định hay được đặt trước) để tham chiếu đến phông chữ không tuân thủ Unicode cho Myanmar. Nhà phát triển ứng dụng và tác giả trang web có thể chỉ định my-Qaag làm mã ngôn ngữ được chỉ định như đối với mọi ngôn ngữ khác.

3.8.14. Nhiều cửa sổ

Nếu có khả năng hiển thị nhiều hoạt động cùng lúc, thì các hoạt động triển khai thiết bị sẽ:

[C-1-1] PHẢI triển khai(các) chế độ nhiều cửa sổ như vậy theo hành vi của ứng dụng và API được mô tả trong tài liệu hỗ trợ chế độ nhiều cửa sổ của SDK Android và đáp ứng các yêu cầu sau:
[C-1-2] PHẢI tuân thủ android:resizeableActivity do ứng dụng đặt trong tệp AndroidManifest.xml như mô tả trong SDK này.
[C-1-3] KHÔNG ĐƯỢC cung cấp chế độ chia đôi màn hình hoặc chế độ hình dạng tuỳ ý nếu chiều cao màn hình nhỏ hơn 440 dp và chiều rộng màn hình nhỏ hơn 440 dp.
[C-1-4] KHÔNG ĐƯỢC đổi kích thước hoạt động thành kích thước nhỏ hơn 220 dp trong các chế độ nhiều cửa sổ, ngoại trừ chế độ Hình trong hình.
Việc triển khai thiết bị có kích thước màn hình xlarge PHẢI hỗ trợ chế độ hình dạng tuỳ ý.

Nếu việc triển khai thiết bị hỗ trợ(các) chế độ nhiều cửa sổ và chế độ chia đôi màn hình, thì các chế độ đó:

[C-2-2] PHẢI cắt hoạt động được kêt nối của chế độ nhiều cửa sổ chia đôi màn hình nhưng NÊN hiển thị một số nội dung của hoạt động đó, nếu ứng dụng Trình chạy là cửa sổ được lấy làm tâm điểm.
[C-2-3] PHẢI tuân thủ các giá trị AndroidManifestLayout_minWidth và AndroidManifestLayout_minHeight đã khai báo của ứng dụng trình chạy bên thứ ba và không ghi đè các giá trị này trong quá trình hiển thị một số nội dung của hoạt động được kêt nối.

Nếu việc triển khai thiết bị hỗ trợ(các) chế độ nhiều cửa sổ và chế độ nhiều cửa sổ Hình trong hình, thì các chế độ đó:

[C-3-1] PHẢI chạy các hoạt động ở chế độ nhiều cửa sổ hình trong hình khi ứng dụng: * Nhắm đến API cấp 26 trở lên và khai báo android:supportsPictureInPicture * Nhắm đến API cấp 25 trở xuống và khai báo cả android:resizeableActivity và android:supportsPictureInPicture.
[C-3-2] PHẢI hiển thị các thao tác trong SystemUI theo cách được chỉ định bởi hoạt động PIP hiện tại thông qua API setActions().
[C-3-3] PHẢI hỗ trợ tỷ lệ khung hình lớn hơn hoặc bằng 1:2,39 và nhỏ hơn hoặc bằng 2,39:1, như được chỉ định bởi hoạt động PIP thông qua API setAspectRatio().
[C-3-4] PHẢI sử dụng KeyEvent.KEYCODE_WINDOW để điều khiển cửa sổ PIP; nếu không triển khai chế độ PIP, thì khoá PHẢI có sẵn cho hoạt động trên nền trước.
[C-3-5] PHẢI cung cấp cho người dùng khả năng chặn một ứng dụng hiển thị ở chế độ PIP; việc triển khai AOSP đáp ứng yêu cầu này bằng cách có các chế độ điều khiển trong ngăn thông báo.
[C-3-6] PHẢI phân bổ chiều rộng và chiều cao tối thiểu sau đây cho cửa sổ PIP khi ứng dụng không khai báo giá trị nào cho AndroidManifestLayout_minWidth và AndroidManifestLayout_minHeight:
- Các thiết bị có Configuration.uiMode được đặt khác với UI_MODE_TYPE_TELEVISION PHẢI phân bổ chiều rộng và chiều cao tối thiểu là 108 dp.
- Các thiết bị có Configuration.uiMode được đặt thành UI_MODE_TYPE_TELEVISION PHẢI phân bổ chiều rộng tối thiểu là 240 dp và chiều cao tối thiểu là 135 dp.

3.8.15. Vết cắt trên màn hình

Android hỗ trợ Vết cắt trên màn hình như mô tả trong tài liệu SDK. API DisplayCutout xác định một vùng ở cạnh màn hình có thể không hoạt động cho một ứng dụng do màn hình cắt hoặc màn hình cong ở(các) cạnh.

Nếu quá trình triển khai thiết bị bao gồm(các) phần cắt màn hình, thì các phần cắt đó:

[C-1-5] KHÔNG ĐƯỢC có(các) phần cắt nếu tỷ lệ khung hình của thiết bị là 1.0(1:1).
[C-1-2] KHÔNG ĐƯỢC có nhiều hơn một phần cắt trên mỗi cạnh.
[C-1-3] PHẢI tuân thủ các cờ cắt màn hình do ứng dụng đặt thông qua API WindowManager.LayoutParams như mô tả trong SDK.
[C-1-4] PHẢI báo cáo giá trị chính xác cho tất cả chỉ số cắt được xác định trong API DisplayCutout.

3.8.16. Điều khiển thiết bị

Android bao gồm các API ControlsProviderService và Control để cho phép các ứng dụng bên thứ ba phát hành các chế độ điều khiển thiết bị cho trạng thái và hành động nhanh cho người dùng.

Hãy xem Mục 2_2_3 để biết các yêu cầu dành riêng cho thiết bị.

3.8.17. Bảng nhớ tạm

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC gửi dữ liệu bảng 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ủ) hoặc chỉ báo về nội dung đang được gửi, ngoại trừ các dịch vụ được đề cập trong phần 9.8.6 Tính năng tìm kiếm nội dung và ứ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 nhìn thấy khi nội dung được sao chép vào bảng nhớ tạm cho bất kỳ mục ClipData nào mà ClipData.getDescription().getExtras() chứa android.content.extra.IS_SENSITIVE, thì các bản xem trước đó:

[C-1-1] BẮT BUỘC phải loại bỏ bản xem trước mà người dùng nhìn thấy

Cách triển khai tham chiếu AOSP đáp ứng các yêu cầu này đối với bảng nhớ tạm.

3.9. Quản trị thiết bị

Android có các tính năng cho phép các ứng dụng nhận biết bảo mật thực hiện các chức năng quản trị thiết bị ở cấp hệ thống, chẳng hạn như thực thi chính sách mật khẩu hoặc xoá từ xa thông qua API Quản trị thiết bị Android.

Nếu việc triển khai thiết bị triển khai toàn bộ các chính sách quản trị thiết bị được xác định trong tài liệu SDK Android, thì các chính sách đó:

[C-1-1] PHẢI khai báo android.software.device_admin.
[C-1-2] PHẢI hỗ trợ việc cấp phép cho chủ sở hữu thiết bị như mô tả trong mục 3.9.1 và mục 3.9.1.1.

3.9.1 Cấp phép thiết bị

3.9.1.1 Cấp phép cho chủ sở hữu thiết bị

Nếu các hoạt động triển khai thiết bị khai báo android.software.device_admin, thì các hoạt động đó:

[C-1-1] PHẢI hỗ trợ việc đăng ký Ứng dụng chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị như mô tả dưới đây:
- Khi quá trình triển khai thiết bị không có người dùng và dữ liệu người dùng được định cấu hình, thì quá trình này 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 cho phép ứ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ị khai báo hỗ trợ Giao tiếp phạm vi gần (NFC) thông qua cờ tính năng 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 ý định ACTION_GET_PROVISIONING_MODE sau khi kích hoạt tính năng cấp phép cho chủ sở hữu thiết bị để ứ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ơ, tuỳ thuộc vào các giá trị của android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, trừ phi có thể xác định được từ ngữ cảnh rằng chỉ có một tuỳ chọn hợp lệ.
  - [C-1-9] PHẢI gửi ý định ACTION_ADMIN_POLICY_COMPLIANCE đến ứng dụng Chủ sở hữu thiết bị nếu Chủ sở hữu thiết bị được thiết lập trong quá trình cấp phép, bất kể phương thức cấp phép được sử dụng. Người dùng không được phép tiếp tục trong Trình hướng dẫn thiết lập cho đến khi ứng dụng Chủ sở hữu thiết bị hoàn tất.
- Khi quá trình triển khai thiết bị có người dùng hoặc dữ liệu người dùng, thì quá trình này:
  - [C-1-7] KHÔNG ĐƯỢC đăng ký bất kỳ ứng dụng DPC nào làm Ứng dụng của chủ sở hữu thiết bị nữa.
[C-1-2] PHẢI hiển thị thông báo công bố thích hợp (như được tham chiếu trong AOSP) và có được sự đồng ý xác nhận của người dùng cuối trước khi ứng dụng được đặt làm Chủ sở hữu thiết bị, trừ phi thiết bị được định cấu hình theo phương thức lập trình cho Chế độ minh hoạ tại cửa hàng bán lẻ trước khi người dùng cuối tương tác trên màn hình. Nếu việc triển khai thiết bị khai báo android.software.device_admin, nhưng cũng bao gồm một giải pháp quản lý thiết bị độc quyền và cung cấp cơ chế để quảng bá một ứng dụng được định cấu hình trong giải pháp của họ dưới dạng "Tương đương với Chủ sở hữu thiết bị" với "Chủ sở hữu thiết bị" tiêu chuẩn do các API DevicePolicyManager Android tiêu chuẩn công nhận, thì các API đó:
[C-2-1] PHẢI có quy trình để xác minh rằng ứng dụng cụ thể đang được quảng bá thuộc về một giải pháp quản lý thiết bị doanh nghiệp hợp pháp và đã được định cấu hình trong giải pháp độc quyền để có quyền tương đương với "Chủ sở hữu thiết bị".
[C-2-2] PHẢI hiển thị thông tin công bố về sự đồng ý của Chủ sở hữu thiết bị AOSP giống như quy trình do android.app.action.PROVISION_MANAGED_DEVICE khởi tạo trước khi đăng ký ứng dụng DPC làm "Chủ sở hữu thiết bị".
[C-2-3] KHÔNG ĐƯỢC mã hoá cứng trạng thái đồng ý hoặc ngăn việc sử dụng các ứng dụng khác của chủ sở hữu thiết bị.

3.9.1.2 Cấp phép hồ sơ được quản lý

Nếu các hoạt động triển khai thiết bị khai báo android.software.managed_users, thì các hoạt động đó:

[C-1-1] PHẢI triển khai API cho phép ứng dụng Trình điều khiển chính sách thiết bị (DPC) trở thành chủ sở hữu của Hồ sơ được quản lý mới.
[C-1-2] Quy trình cấp hồ sơ được quản lý (quy trình do DPC khởi tạo bằng cách sử dụng android.app.action.PROVISION_MANAGED_PROFILE) hoặc do nền tảng khởi tạo), màn hình đồng ý và trải nghiệm người dùng PHẢI phù hợp với cách triển khai AOSP.
[C-1-3] PHẢI cung cấp các chức năng sau đây cho người dùng trong phần Cài đặt để cho người dùng biết khi nào một chức năng cụ thể của hệ thống đã bị Trình điều khiển chính sách thiết bị (DPC) tắt:
- Một biểu tượng nhất quán hoặc các tính năng hỗ trợ người dùng khác (ví dụ: biểu tượng thông tin AOSP ngược dòng) để thể hiện thời điểm một chế độ cài đặt cụ thể bị Quản trị viên thiết bị hạn chế.
- Thông báo giải thích ngắn gọn do Quản trị viên thiết bị cung cấp thông qua setShortSupportMessage.
- Biểu tượng của ứng dụng DPC.
[C-1-4] PHẢI chạy trình xử lý cho ý định ACTION_PROVISIONING_SUCCESSFUL trong hồ sơ công việc nếu Chủ sở hữu hồ sơ được thiết lập khi quá trình cấp phép được bắt đầu bằng ý định android.app.action.PROVISION_MANAGED_PROFILE và DPC đã triển khai trình xử lý.
[C-1-5] PHẢI gửi thông báo truyền tin ACTION_PROFILE_PROVISIONING_COMPLETE đến DPC hồ sơ công việc khi quá trình cấp phép được bắt đầu bằng ý định android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] PHẢI gửi ý định ACTION_GET_PROVISIONING_MODE sau khi quá trình cấp phép cho chủ sở hữu hồ sơ đượ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ơ, ngoại trừ trường hợp quá trình cấp phép được kích hoạt bằng ý định android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] PHẢI gửi ý định ACTION_ADMIN_POLICY_COMPLIANCE đến hồ sơ công việc khi Chủ sở hữu hồ sơ được thiết lập trong quá trình cấp phép, bất kể phương thức cấp phép nào được sử dụng, ngoại trừ khi ý định android.app.action.PROVISION_MANAGED_PROFILE kích hoạt quá trình cấp phép. Người dùng không được phép tiếp tục trong Trình hướng dẫn thiết lập cho đến khi ứng dụng Chủ sở hữu hồ sơ hoàn tất.
[C-1-8] PHẢI gửi thông báo truyền tin ACTION_MANAGED_PROFILE_PROVISIONED đến DPC hồ sơ cá nhân khi Chủ sở hữu hồ sơ được thiết lập, bất kể phương thức cấp phép được sử dụng.

3.9.2 Hỗ trợ hồ sơ được quản lý

Nếu các hoạt động triển khai thiết bị khai báo android.software.managed_users, thì các hoạt động đó:

[C-1-1] PHẢI hỗ trợ hồ sơ được quản lý thông qua các API android.app.admin.DevicePolicyManager.
[C-1-2] PHẢI cho phép tạo một và chỉ một hồ sơ được quản lý.
[C-1-3] PHẢI sử dụng huy hiệu biểu tượng (tương tự như huy hiệu công việc ngược dòng AOSP) để đại diện cho các ứng dụng và tiện ích được quản lý cũng như các thành phần giao diện người dùng được gắn huy hiệu khác như Gần đây và Thông báo.
[C-1-4] PHẢI hiển thị biểu tượng thông báo (tương tự như huy hiệu công việc ngược dòng AOSP) để cho biết thời điểm người dùng đang sử dụng ứng dụng hồ sơ được quản lý.
[C-1-5] PHẢI hiển thị thông báo ngắn cho biết người dùng đang ở trong hồ sơ được quản lý nếu và khi thiết bị thức dậy (ACTION_USER_PRESENT) và ứng dụng trên nền trước nằm trong hồ sơ được quản lý.
[C-1-6] Khi có hồ sơ được quản lý, PHẢI hiển thị một tính năng hỗ trợ trực quan trong "Bộ chọn" Ý định để cho phép người dùng chuyển tiếp ý định từ hồ sơ được quản lý đến người dùng chính hoặc ngược lại, nếu Trình điều khiển chính sách thiết bị bật tính năng này.
[C-1-7] Khi có hồ sơ được quản lý, PHẢI hiển thị các tính năng hỗ trợ người dùng sau đây cho cả người dùng chính và hồ sơ được quản lý:
- Tính riêng mức sử dụng pin, vị trí, dữ liệu di động và bộ nhớ cho người dùng chính và hồ sơ được quản lý.
- Quản lý độc lập các Ứng dụng VPN được cài đặt trong hồ sơ người dùng chính hoặc hồ sơ được quản lý.
- Quản lý độc lập các ứng dụng được cài đặt trong hồ sơ người dùng chính hoặc hồ sơ được quản lý.
- Quản lý độc lập các tài khoản trong người dùng chính hoặc trang doanh nghiệp được quản lý.
[C-1-8] PHẢI đảm bảo rằng các ứng dụng trình quay số, danh bạ và nhắn tin được cài đặt sẵn có thể tìm kiếm và tra cứu thông tin người gọi từ hồ sơ được quản lý (nếu có) cùng với thông tin từ hồ sơ chính, nếu Trình kiểm soát chính sách thiết bị cho phép.
[C-1-9] PHẢI đảm bảo rằng hồ sơ này đáp ứng tất cả các yêu cầu bảo mật áp dụng cho một thiết bị có nhiều người dùng được bật (xem mục 9.5), mặc dù hồ sơ được quản lý không được tính là một người dùng khác ngoài người dùng chính.

Bắt đầu yêu cầu mới

[C-1-10] PHẢI đảm bảo rằng dữ liệu ảnh chụp màn hình được lưu trong bộ nhớ hồ sơ công việc khi ảnh chụp màn hình được chụp bằng cửa sổ topActivity có tâm điểm (tâm điểm mà người dùng tương tác gần đây nhất trong số tất cả các hoạt động) và thuộc về ứng dụng hồ sơ công việc.
[C-1-11] KHÔNG ĐƯỢC chụp bất kỳ nội dung màn hình nào khác (thanh hệ thống, thông báo hoặc nội dung hồ sơ cá nhân bất kỳ) ngoại trừ cửa sổ/cửa sổ của ứng dụng hồ sơ công việc khi lưu ảnh chụp màn hình vào hồ sơ công việc (để đảm bảo rằng dữ liệu hồ sơ cá nhân không được lưu trong hồ sơ công việc).

Kết thúc các yêu cầu mới

Nếu các hoạt động triển khai thiết bị khai báo android.software.managed_users và android.software.secure_lock_screen, thì các hoạt động đó:

[C-2-1] PHẢI hỗ trợ khả năng chỉ định một màn hình khoá riêng biệt đáp ứng các yêu cầu sau để cấp quyền truy cập cho các ứng dụng chỉ chạy trong hồ sơ được quản lý.
- Việc triển khai thiết bị PHẢI tuân thủ ý định DevicePolicyManager.ACTION_SET_NEW_PASSWORD và hiển thị một giao diện để định cấu hình thông tin xác thực màn hình khoá riêng cho hồ sơ được quản lý.
- Thông tin xác thực trên màn hình khoá của hồ sơ được quản lý PHẢI sử dụng cùng một cơ chế quản lý và lưu trữ thông tin xác thực như hồ sơ gốc, như được ghi nhận trên Trang web dự án nguồn mở Android.
- Chính sách mật khẩu của DPC CHỈ ĐƯỢC áp dụng cho thông tin xác thực màn hình khoá của hồ sơ được quản lý, trừ phi được gọi trên thực thể DevicePolicyManager do getParentProfileInstance trả về.
Khi danh bạ trong hồ sơ được quản lý hiển thị trong nhật ký cuộc gọi được cài đặt sẵn, giao diện người dùng trong cuộc gọi, thông báo về cuộc gọi đang diễn ra và cuộc gọi nhỡ, danh bạ và ứng dụng nhắn tin, chúng PHẢI được gắn huy hiệu giống với huy hiệu dùng để chỉ các ứng dụng trong hồ sơ được quản lý.

3.9.3 Hỗ trợ người dùng được quản lý

Nếu các hoạt động triển khai thiết bị khai báo android.software.managed_users, thì các hoạt động đó:

[C-1-1] PHẢI cung cấp cho người dùng khả năng đăng xuất khỏi người dùng hiện tại và chuyển về người dùng chính trong phiên nhiều người dùng khi isLogoutEnabled trả về true. Người dùng PHẢI truy cập được vào tính năng hỗ trợ từ màn hình khoá mà không cần mở khoá thiết bị.

Nếu các phương thức triển khai thiết bị khai báo android.software.device_admin và cung cấp một tính năng hỗ trợ người dùng trên thiết bị để thêm Người dùng phụ, thì các phương thức đó:

[C-SR-1] Bạn NÊN hiển thị cùng một thông tin công bố về sự đồng ý của Chủ sở hữu thiết bị AOSP đã hiển thị trong quy trình do android.app.action.PROVISION_MANAGED_DEVICE khởi tạo, trước khi cho phép thêm tài khoản trong Người dùng phụ mới, để người dùng hiểu rằng thiết bị được quản lý.

3.9.4 Yêu cầu về vai trò Quản lý chính sách thiết bị

Nếu quá trình triển khai thiết bị báo cáo android.software.device_admin hoặc android.software.managed_users, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ vai trò quản lý chính sách thiết bị như được xác định trong mục 9.1. Bạn CÓ THỂ xác định ứng dụng giữ vai trò quản lý chính sách thiết bị bằng cách đặt config_devicePolicyManagement thành tên gói. Tên gói PHẢI theo sau là : và chứng chỉ ký, trừ phi ứng dụng được tải sẵn.

Nếu bạn không xác định tên gói cho config_devicePolicyManagement như mô tả ở trên:

[C-2-1] Việc triển khai thiết bị PHẢI hỗ trợ việc cấp phép mà không cần ứng dụng của chủ sở hữu vai trò quản lý chính sách thiết bị (AOSP cung cấp phương thức triển khai tham chiếu).

Nếu tên gói được xác định cho config_devicePolicyManagement như mô tả ở trên:

[C-3-1] Ứng dụng PHẢI được cài đặt trên tất cả hồ sơ cho một người dùng.
[C-3-2] Việc triển khai thiết bị CÓ THỂ xác định một ứng dụng cập nhật chủ sở hữu vai trò quản lý chính sách thiết bị trước khi cấp phép bằng cách thiết lập config_devicePolicyManagementUpdater.

Nếu tên gói được xác định cho config_devicePolicyManagementUpdater như mô tả ở trên:

[C-4-1] Ứng dụng PHẢI được cài đặt trước trên thiết bị.
[C-4-2] Ứng dụng PHẢI triển khai một bộ lọc ý định giúp phân giải android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

Bắt đầu yêu cầu mới

3.9.5 Khung giải quyết chính sách thiết bị

Nếu quá trình triển khai thiết bị báo cáo android.software.device_admin hoặc android.software.managed_users, thì các thiết bị đó:

[C-1-1] PHẢI giải quyết xung đột chính sách thiết bị như được ghi nhận trong Khung giải quyết chính sách thiết bị.

Kết thúc các yêu cầu mới

3.10. Hỗ trợ tiếp cận

Android cung cấp một lớp hỗ trợ tiếp cận giúp người dùng khuyết tật dễ dàng thao tác trên thiết bị của họ hơn. Ngoài ra, Android cung cấp các API nền tảng cho phép triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho người dùng và sự kiện hệ thống, đồng thời tạo ra các cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng bằng bi xoay/d-pad.

Nếu việc triển khai thiết bị hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba, thì các dịch vụ đó:

[C-1-1] PHẢI cung cấp cách triển khai khung hỗ trợ tiếp cận Android như mô tả trong tài liệu SDK về API hỗ trợ tiếp cận.
[C-1-2] PHẢI tạo sự kiện hỗ trợ tiếp cận và phân phối AccessibilityEvent thích hợp cho tất cả các hoạt động triển khai AccessibilityService đã đăng ký như được ghi lại trong SDK.
[C-1-4] PHẢI cung cấp cho người dùng khả năng kiểm soát các dịch vụ hỗ trợ tiếp cận khai báo AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Lưu ý rằng đối với việc triển khai thiết bị có thanh điều hướng hệ thống, các thiết bị đó PHẢI cho phép người dùng có lựa chọn nút trong thanh điều hướng của hệ thống để kiểm soát các dịch vụ này.

Nếu việc triển khai thiết bị bao gồm các dịch vụ hỗ trợ tiếp cận được cài đặt sẵn, thì các dịch vụ đó:

[C-2-1] PHẢI triển khai các dịch vụ hỗ trợ tiếp cận được cài đặt sẵn này dưới dạng ứng dụng Nhận biết khởi động trực tiếp khi bộ nhớ dữ liệu được mã hoá bằng phương thức Mã hoá dựa trên tệp (FBE).
NÊN cung cấp một cơ chế trong quy trình thiết lập ban đầu để người dùng bật các dịch vụ hỗ trợ tiếp cận có liên quan, cũng như các tuỳ chọn để điều chỉnh cỡ chữ, kích thước màn hình và cử chỉ phóng to.

3.11. Chuyển văn bản sang lời nói

Android bao gồm các API cho phép ứng dụng sử dụng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ triển khai các dịch vụ TTS.

Nếu việc triển khai thiết bị báo cáo tính năng android.hardware.audio.output, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ các API khung TTS Android.

Nếu quá trình triển khai thiết bị hỗ trợ việc cài đặt công cụ TTS của bên thứ ba, thì các công cụ đó:

[C-2-1] PHẢI cung cấp khả năng hỗ trợ người dùng để cho phép người dùng chọn công cụ TTS để sử dụng ở cấp hệ thống.

3.12. Khung đầu vào TV

Khuôn khổ đầu vào Android Television (TIF) đơn giản hoá việc phân phối nội dung trực tiếp đến các thiết bị Android Television. TIF cung cấp một API tiêu chuẩn để tạo các mô-đun đầu vào điều khiển thiết bị Android Television.

Nếu các phương thức triển khai thiết bị hỗ trợ TIF, thì các phương thức đó:

[C-1-1] BẮT BUỘC khai báo tính năng nền tảng android.software.live_tv.
[C-1-2] PHẢI hỗ trợ tất cả API TIF để có thể cài đặt và sử dụng ứng dụng sử dụng các API này và dịch vụ dữ liệu đầu vào dựa trên TIF của bên thứ ba trên thiết bị.

3.13. Cài đặt nhanh

Android cung cấp một thành phần giao diện người dùng Cài đặt nhanh cho phép truy cập nhanh vào các thao tác thường dùng hoặc cần thiết khẩn cấp.

Nếu việc triển khai thiết bị bao gồm một thành phần giao diện người dùng Cài đặt nhanh và hỗ trợ Cài đặt nhanh của bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI cho phép người dùng thêm hoặc xoá các thẻ thông tin được cung cấp thông qua API quicksettings từ ứng dụng bên thứ ba.
[C-1-2] KHÔNG ĐƯỢC tự động thêm thẻ thông tin từ ứng dụng của bên thứ ba trực tiếp vào phần Cài đặt nhanh.
[C-1-3] PHẢI hiển thị tất cả thẻ thông tin do người dùng thêm từ các ứng dụng bên thứ ba cùng với thẻ cài đặt nhanh do hệ thống cung cấp.

3.14. Giao diện người dùng đa phương tiện

Nếu quá trình triển khai thiết bị bao gồm các ứng dụng không kích hoạt bằng giọng nói (Ứng dụng) tương tác với các ứng dụng bên thứ ba thông qua MediaBrowser hoặc MediaSession, thì Ứng dụng:

[C-1-2] PHẢI hiển thị rõ ràng các biểu tượng thu được qua getIconBitmap() hoặc getIconUri() và các tiêu đề thu được qua getTitle() như mô tả trong MediaDescription. Có thể rút ngắn tiêu đề để tuân thủ các quy định về an toàn (ví dụ: gây mất tập trung cho người lái xe).
[C-1-3] PHẢI hiển thị biểu tượng ứng dụng bên thứ ba bất cứ khi nào hiển thị nội dung do ứng dụng bên thứ ba này cung cấp.
[C-1-4] PHẢI cho phép người dùng tương tác với toàn bộ hệ thống phân cấp MediaBrowser. CÓ THỂ hạn chế quyền truy cập vào một phần của hệ phân cấp để tuân thủ các quy định về an toàn (ví dụ: làm người lái xe mất tập trung), nhưng KHÔNG ĐƯỢC ưu tiên xử lý dựa trên nội dung hoặc nhà cung cấp nội dung.
[C-1-5] PHẢI xem xét thao tác nhấn đúp vào KEYCODE_HEADSETHOOK hoặc KEYCODE_MEDIA_PLAY_PAUSE dưới dạng KEYCODE_MEDIA_NEXT cho MediaSession.Callback#onMediaButtonEvent.

3.15. Ứng dụng tức thì

Nếu triển khai thiết bị hỗ trợ Ứng dụng tức thì, thì thiết bị đó PHẢI đáp ứng các yêu cầu sau:

[C-1-1] Chỉ được cấp quyền cho Ứng dụng tức thì có android:protectionLevel được đặt thành "instant".
[C-1-2] Ứng dụng tức thì KHÔNG ĐƯỢC tương tác với các ứng dụng đã cài đặt thông qua ý định ngầm ẩn, trừ phi một trong những điều kiện sau đây là đúng:
- Bộ lọc mẫu ý định của thành phần được hiển thị và có CATEGORY_BROWSABLE
- Thao tác là một trong các thao tác ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Mục tiêu được hiển thị rõ ràng bằng android:visibleToInstantApps
[C-1-3] Ứng dụng tức thì KHÔNG ĐƯỢC tương tác rõ ràng với các ứng dụng đã cài đặt, trừ khi thành phần được hiển thị thông qua android:visibleToInstantApps.
[C-1-4] Ứng dụng đã cài đặt KHÔNG ĐƯỢC xem thông tin chi tiết về Ứng dụng tức thì trên thiết bị, trừ phi Ứng dụng tức thì kết nối rõ ràng với ứng dụng đã cài đặt.
Việc triển khai thiết bị PHẢI cung cấp các tính năng hỗ trợ người dùng sau đây để tương tác với Ứng dụng tức thì. AOSP đáp ứng các yêu cầu với giao diện người dùng hệ thống, phần cài đặt và trình chạy mặc định. Triển khai trên thiết bị:
- [C-1-5] PHẢI cung cấp cho người dùng khả năng xem và xoá Ứng dụng tức thì được lưu vào bộ nhớ đệm cục bộ cho từng gói ứng dụng riêng lẻ.
- [C-1-6] PHẢI cung cấp một thông báo liên tục cho người dùng có thể thu gọn trong khi Ứng dụng tức thì đang chạy ở nền trước. Thông báo cho người dùng này PHẢI cho biết rằng Ứng dụng tức thì không yêu cầu cài đặt và cung cấp cho người dùng một tính năng giúp họ chuyển đến màn hình thông tin ứng dụng trong phần Cài đặt. Đối với Ứng dụng tức thì được khởi chạy thông qua ý định web, như được xác định bằng cách sử dụng ý định có hành động được đặt thành Intent.ACTION_VIEW và có giao thức "http" hoặc "https", một khả năng khác của người dùng PHẢI cho phép người dùng không khởi chạy Ứng dụng tức thì và khởi chạy đường liên kết được liên kết bằng trình duyệt web đã định cấu hình, nếu có trình duyệt trên thiết bị.
- [C-1-7] PHẢI cho phép truy cập vào các Ứng dụng tức thì đang chạy từ chức năng Gần đây nếu chức năng Gần đây có trên thiết bị.
[C-1-8] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định cho các ý định được liệt kê trong SDK tại đây và hiển thị các ý định đó cho Ứng dụng tức thì.

3.16. Ghép nối thiết bị đồng hành

Android hỗ trợ tính năng ghép nối thiết bị đồng hành để quản lý liên kết với thiết bị đồng hành hiệu quả hơn và cung cấp API CompanionDeviceManager cho các ứng dụng để truy cập vào tính năng này.

Nếu việc triển khai thiết bị hỗ trợ tính năng ghép nối thiết bị đồng hành, thì các thiết bị đó:

[C-1-1] BẮT BUỘC phải khai báo cờ tính năng FEATURE_COMPANION_DEVICE_SETUP .
[C-1-2] PHẢI đảm bảo triển khai đầy đủ các API trong gói android.companion .
[C-1-3] PHẢI cung cấp cho người dùng các tính năng hỗ trợ để người dùng có thể chọn/xác nhận rằng thiết bị đồng hành hiện có và đang hoạt động.

3.17. Ứng dụng nặng

Nếu quá trình triển khai thiết bị khai báo tính năng FEATURE_CANT_SAVE_STATE, thì các thiết bị đó:

[C-1-1] PHẢI chỉ có một ứng dụng đã cài đặt chỉ định cantSaveState đang chạy trong hệ thống tại một thời điểm. Nếu người dùng rời khỏi một ứng dụng như vậy mà không thoát ứng dụng một cách rõ ràng (ví dụ: nhấn nút màn hình chính trong khi rời khỏi một hoạt động đang hoạt động trong hệ thống, thay vì nhấn nút quay lại khi không còn hoạt động nào đang hoạt động trong hệ thống), thì việc triển khai thiết bị PHẢI ưu tiên ứng dụng đó trong RAM như đối với các ứng dụng khác dự kiến sẽ tiếp tục chạy, chẳng hạn như dịch vụ trên nền trước. Khi một ứng dụng như vậy chạy ở chế độ nền, hệ thống vẫn có thể áp dụng các tính năng quản lý nguồn điện cho ứng dụng đó, chẳng hạn như giới hạn CPU và quyền truy cập mạng.
[C-1-2] PHẢI cung cấp một chức năng trên giao diện người dùng để chọn ứng dụng sẽ không tham gia vào cơ chế lưu/khôi phục trạng thái thông thường sau khi người dùng chạy một ứng dụng thứ hai được khai báo bằng thuộc tính cantSaveState.
[C-1-3] KHÔNG ĐƯỢC áp dụng các thay đổi khác trong chính sách cho các ứng dụng chỉ định cantSaveState, chẳng hạn như thay đổi hiệu suất CPU hoặc thay đổi mức độ ưu tiên lên lịch.

Nếu quá trình triển khai thiết bị không khai báo tính năng FEATURE_CANT_SAVE_STATE, thì các thiết bị đó:

[C-1-1] PHẢI bỏ qua thuộc tính cantSaveState do ứng dụng đặt và KHÔNG ĐƯỢC thay đổi hành vi của ứng dụng dựa trên thuộc tính đó.

3.18. Danh bạ

Android bao gồm các API Contacts Provider để cho phép các ứng dụng quản lý thông tin liên hệ được lưu trữ trên thiết bị. Dữ liệu liên hệ được nhập trực tiếp vào thiết bị thường được đồng bộ hoá với một dịch vụ web, nhưng dữ liệu này cũng CÓ THỂ chỉ nằm trên thiết bị. Những người liên hệ chỉ được lưu trữ trên thiết bị được gọi là người liên hệ cục bộ.

RawContacts được "liên kết với" hoặc "lưu trữ trong" một Tài khoản khi các cột ACCOUNT_NAME và ACCOUNT_TYPE cho các liên hệ thô khớp với các trường Account.name và Account.type tương ứng của tài khoản.

Tài khoản cục bộ mặc định: một tài khoản cho các liên hệ thô chỉ được lưu trữ trên thiết bị và không liên kết với Tài khoản trong AccountManager. Tài khoản này được tạo bằng các giá trị rỗng cho cột ACCOUNT_NAME và ACCOUNT_TYPE.

Tài khoản cục bộ tuỳ chỉnh: tài khoản cho các liên hệ thô chỉ được lưu trữ trên thiết bị và không liên kết với Tài khoản trong AccountManager. Tài khoản này được tạo bằng ít nhất một giá trị khác rỗng cho các cột ACCOUNT_NAME và ACCOUNT_TYPE.

Triển khai trên thiết bị:

[C-SR-1] KHÔNG NÊN tạo tài khoản cục bộ tuỳ chỉnh.

Nếu việc triển khai thiết bị sử dụng tài khoản cục bộ tuỳ chỉnh:

[C-1-1] ContactsContract.RawContacts.getLocalAccountName PHẢI trả về ACCOUNT_NAME của tài khoản cục bộ tuỳ chỉnh
[C-1-2] ContactsContract.RawContacts.getLocalAccountType PHẢI trả về ACCOUNT_TYPE của tài khoản cục bộ tuỳ chỉnh
[C-1-3] Bạn PHẢI chèn các thông tin liên hệ thô do các ứng dụng bên thứ ba chèn bằng tài khoản cục bộ mặc định (tức là bằng cách đặt giá trị rỗng cho ACCOUNT_NAME và ACCOUNT_TYPE) vào tài khoản cục bộ tuỳ chỉnh.
[C-1-4] KHÔNG được xoá các liên hệ thô được chèn vào tài khoản cục bộ tuỳ chỉnh khi thêm hoặc xoá tài khoản.
[C-1-5] Các thao tác xoá được thực hiện đối với tài khoản cục bộ tuỳ chỉnh PHẢI dẫn đến việc xoá ngay các địa chỉ liên hệ thô (như thể tham số CALLER_IS_SYNCADAPTER được đặt thành true), ngay cả khi tham số CALLER\_IS\_SYNCADAPTER được đặt thành false hoặc không được chỉ định.

4. Khả năng tương thích của tính năng đóng gói ứng dụng

Triển khai thiết bị:

[C-0-1] PHẢI có khả năng cài đặt và chạy các tệp ".apk" của Android do công cụ "aapt" tạo ra trong SDK Android chính thức.
- Vì yêu cầu trên có thể gây khó khăn, nên bạn NÊN sử dụng hệ thống quản lý gói của quá trình triển khai tham chiếu AOSP để triển khai thiết bị.
[C-0-2] PHẢI hỗ trợ xác minh tệp ".apk" bằng cách sử dụng Lược đồ chữ ký APK phiên bản 3.1, Lược đồ chữ ký APK phiên bản 3, Lược đồ chữ ký APK phiên bản 2 và ký JAR.
[C-0-3] KHÔNG ĐƯỢC mở rộng định dạng .apk, Tệp kê khai Android, mã byte Dalvik hoặc mã byte RenderScript theo cách ngăn các tệp đó cài đặt và chạy chính xác trên các thiết bị tương thích khác.
[C-0-4] KHÔNG ĐƯỢC cho phép các ứng dụng khác ngoài "trình cài đặt bản ghi" hiện tại của gói gỡ cài đặt ứng dụng một cách thầm lặng mà không có bất kỳ xác nhận nào của người dùng, như được ghi lại trong SDK cho quyền DELETE_PACKAGE. Các trường hợp ngoại lệ duy nhất là ứng dụng trình xác minh gói hệ thống xử lý ý định PACKAGE_NEEDS_VERIFICATION và ứng dụng trình quản lý bộ nhớ xử lý ý định ACTION_MANAGE_STORAGE.
[C-0-5] PHẢI có một hoạt động xử lý ý định android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] KHÔNG ĐƯỢC cài đặt gói ứng dụng từ các nguồn không xác định, trừ phi ứng dụng yêu cầu cài đặt đáp ứng tất cả các yêu cầu sau:
- Tệp này PHẢI khai báo quyền REQUEST_INSTALL_PACKAGES hoặc đặt android:targetSdkVersion ở mức 24 trở xuống.
- Người dùng PHẢI cấp quyền cài đặt ứng dụng từ các nguồn không xác định.
NÊN cung cấp cho người dùng khả năng cấp/thu hồi quyền cài đặt ứng dụng từ các nguồn không xác định cho mỗi ứng dụng, nhưng CÓ THỂ chọn triển khai tính năng này dưới dạng không hoạt động và trả về RESULT_CANCELED cho startActivityForResult() nếu việc triển khai thiết bị không muốn cho phép người dùng có lựa chọn này. Tuy nhiên, ngay cả trong những trường hợp như vậy, ứng dụng CẦN cho người dùng biết lý do không có lựa chọn như vậy.
[C-0-7] PHẢI hiển thị hộp thoại cảnh báo với chuỗi cảnh báo được cung cấp thông qua API hệ thống PackageManager.setHarmfulAppWarning cho người dùng trước khi khởi chạy một hoạt động trong ứng dụng đã được đánh dấu là có thể gây hại bởi cùng một API hệ thống PackageManager.setHarmfulAppWarning.
NÊN cung cấp cho người dùng khả năng chọn gỡ cài đặt hoặc chạy ứng dụng trên hộp thoại cảnh báo.
[C-0-8] PHẢI triển khai tính năng hỗ trợ Hệ thống tệp tăng dần như được ghi nhận tại đây.
[C-0-9] PHẢI hỗ trợ việc xác minh tệp .apk bằng Lược đồ chữ ký APK v4 và Lược đồ chữ ký APK v4.1.

5. Khả năng tương thích đa phương tiện

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ các định dạng nội dung nghe nhìn, bộ mã hoá, bộ giải mã, loại tệp và định dạng vùng chứa được xác định trong phần 5.1 cho từng bộ mã hoá và giải mã do MediaCodecList khai báo.
[C-0-2] PHẢI khai báo và báo cáo việc hỗ trợ bộ mã hoá, bộ giải mã có sẵn cho các ứng dụng bên thứ ba thông qua MediaCodecList.
[C-0-3] PHẢI có khả năng giải mã đúng cách và cung cấp cho các ứng dụng bên thứ ba tất cả định dạng mà ứng dụng đó có thể mã hoá. Điều này bao gồm tất cả các luồng bit mà bộ mã hoá tạo ra và các hồ sơ được báo cáo trong CamcorderProfile.

Triển khai trên thiết bị:

NÊN hướng đến độ trễ bộ mã hoá và giải mã tối thiểu, nói cách khác, các bộ mã hoá và giải mã này
- KHÔNG ĐƯỢC sử dụng và lưu trữ vùng đệm đầu vào và chỉ trả về vùng đệm đầu vào sau khi xử lý.
- KHÔNG NÊN giữ lại vùng đệm đã giải mã lâu hơn thời gian quy định theo tiêu chuẩn (ví dụ: SPS).
- KHÔNG NÊN giữ lại các vùng đệm đã mã hoá lâu hơn thời gian mà cấu trúc GOP yêu cầu.

Tất cả bộ mã hoá và giải mã được liệt kê trong phần bên dưới đều được cung cấp dưới dạng các phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên từ Dự án nguồn mở Android.

Xin lưu ý rằng cả Google và Liên minh điện thoại mở đều không đưa ra bất kỳ tuyên bố nào rằng các bộ mã hoá và giải mã này không có bằng sáng chế của bên thứ ba. Những người dự định sử dụng mã nguồn này trong các sản phẩm phần cứng hoặc phần mềm nên lưu ý rằng việc triển khai mã này, bao gồm cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế của các chủ sở hữu bằng sáng chế có liên quan.

5.1. Bộ mã hoá và giải mã nội dung nghe nhìn

5.1.1. Mã hoá âm thanh

Xem thêm thông tin chi tiết trong phần 5.1.3. Chi tiết về bộ mã hoá và giải mã âm thanh.

Nếu quá trình triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình đó PHẢI hỗ trợ việc mã hoá các định dạng âm thanh sau và cung cấp các định dạng đó cho ứng dụng bên thứ ba:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

Tất cả bộ mã hoá âm thanh PHẢI hỗ trợ:

[C-3-1] Khung âm thanh thứ tự byte gốc PCM 16 bit thông qua API android.media.MediaCodec.

5.1.2. Giải mã âm thanh

Xem thêm thông tin chi tiết trong phần 5.1.3. Chi tiết về bộ mã hoá và giải mã âm thanh.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ tính năng android.hardware.audio.output, thì các hoạt động đó phải hỗ trợ giải mã các định dạng âm thanh sau:

[C-1-1] Hồ sơ MPEG-4 AAC (AAC LC)
[C-1-2] Hồ sơ MPEG-4 HE AAC (AAC+)
[C-1-3] Hồ sơ MPEG-4 HE AACv2 (AAC+ nâng cao)
[C-1-4] AAC ELD (AAC độ trễ thấp nâng cao)
[C-1-11] xHE-AAC (Hồ sơ HE AAC mở rộng ISO/IEC 23003-3, bao gồm cả Hồ sơ cơ sở USAC và Hồ sơ kiểm soát phạm vi động ISO/IEC 23003-4)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE bao gồm các định dạng âm thanh có độ phân giải cao lên đến 24 bit, tốc độ lấy mẫu 192 kHz và 8 kênh. Xin lưu ý rằng yêu cầu này chỉ dành cho việc giải mã và thiết bị được phép giảm mẫu và giảm âm trong giai đoạn phát.
[C-1-10] Opus

Nếu việc triển khai thiết bị hỗ trợ giải mã vùng đệm đầu vào AAC của các luồng đa kênh (tức là nhiều hơn hai kênh) thành PCM thông qua bộ giải mã âm thanh AAC mặc định trong API android.media.MediaCodec, thì bạn PHẢI hỗ trợ những tính năng sau:

[C-2-1] BẮT BUỘC phải giải mã mà không cần giảm âm thanh (ví dụ: phải giải mã luồng AAC 5.0 thành 5 kênh PCM, phải giải mã luồng AAC 5.1 thành 6 kênh PCM).
[C-2-2] Siêu dữ liệu về dải động PHẢI được xác định trong "Chế độ điều khiển dải động (DRC)" theo ISO/IEC 14496-3 và các khoá DRC android.media.MediaFormat để định cấu hình các hành vi liên quan đến dải động của bộ giải mã âm thanh. Các khoá DRC AAC được giới thiệu trong API 21 và bao gồm: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL và KEY_AAC_ENCODED_TARGET_LEVEL.
[C-SR-1] Tất cả bộ giải mã âm thanh AAC đều NÊN đáp ứng các yêu cầu C-2-1 và C-2-2 ở trên.

Khi giải mã âm thanh USAC, MPEG-D (ISO/IEC 23003-4):

[C-3-1] Siêu dữ liệu về độ to và DRC PHẢI được diễn giải và áp dụng theo Cấu hình điều khiển phạm vi động MPEG-D DRC Cấp 1.
[C-3-2] Bộ giải mã PHẢI hoạt động theo cấu hình được đặt bằng các khoá android.media.MediaFormat sau: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL và KEY_AAC_DRC_EFFECT_TYPE.

Bộ giải mã hồ sơ MPEG-4 AAC, HE AAC và HE AACv2:

CÓ THỂ hỗ trợ điều khiển độ to và dải động bằng Hồ sơ điều khiển dải động ISO/IEC 23003-4.

Nếu ISO/IEC 23003-4 được hỗ trợ và nếu cả siêu dữ liệu ISO/IEC 23003-4 và siêu dữ liệu ISO/IEC 14496-3 đều có trong luồng bit đã giải mã, thì:

Siêu dữ liệu ISO/IEC 23003-4 PHẢI được ưu tiên.

Tất cả bộ giải mã âm thanh PHẢI hỗ trợ đầu ra:

[C-6-1] Khung âm thanh theo thứ tự byte gốc PCM 16 bit thông qua API android.media.MediaCodec.

[C-7-1] PHẢI có thể được ứng dụng định cấu hình bằng cách sử dụng tính năng giải mã bằng khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát việc nội dung có được kết hợp xuống âm thanh nổi (khi sử dụng giá trị 2) hay không hoặc được xuất bằng số lượng kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình bộ giải mã để xuất 6 kênh khi được cung cấp nội dung 5.1.
[C-7-2] Khi giải mã, bộ giải mã PHẢI quảng cáo mặt nạ kênh đang được sử dụng trên định dạng đầu ra bằng khoá KEY_CHANNEL_MASK, sử dụng hằng số android.media.AudioFormat (ví dụ: CHANNEL_OUT_5POINT1).

Nếu việc triển khai thiết bị hỗ trợ bộ giải mã âm thanh khác với bộ giải mã âm thanh AAC mặc định và có thể xuất âm thanh đa kênh (tức là nhiều hơn 2 kênh) khi được cung cấp nội dung đa kênh nén, thì:

[C-SR-2] Ứng dụng NÊN có thể định cấu hình bộ giải mã bằng cách sử dụng tính năng giải mã bằng khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát việc nội dung có được kết hợp xuống âm thanh nổi hay không (khi sử dụng giá trị 2) hoặc được xuất bằng số lượng kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình bộ giải mã để xuất 6 kênh khi được cung cấp nội dung 5.1.
[C-SR-3] Khi giải mã, bộ giải mã NÊN quảng cáo mặt nạ kênh đang được sử dụng trên định dạng đầu ra bằng khoá KEY_CHANNEL_MASK, sử dụng hằng số android.media.AudioFormat (ví dụ: CHANNEL_OUT_5POINT1).

5.1.3. Thông tin chi tiết về bộ mã hoá và giải mã âm thanh

Định dạng/Bộ mã hoá và giải mã	Thông tin chi tiết	Các loại tệp/Định dạng vùng chứa được hỗ trợ
Hồ sơ MPEG-4 AAC (AAC LC)	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 với tốc độ lấy mẫu tiêu chuẩn từ 8 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC thô ADTS (.aac, không hỗ trợ ADIF) MPEG-TS (.ts, không thể tua, chỉ giải mã) Matroska (.mkv, chỉ giải mã)
Hồ sơ MPEG-4 HE AAC (AAC+)	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Hồ sơ MPEG-4 HE AACv2 (AAC+ nâng cao)	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC độ trễ thấp nâng cao)	Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu chuẩn từ 7,35 đến 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 đến 12,2 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)
AMR-WB	9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 16 kHz, như được xác định tại AMR-WB, Đa tỷ lệ thích ứng – Bộ mã hoá và giải mã giọng nói băng tần rộng	3GPP (.3gp)
FLAC	Đối với cả bộ mã hoá và bộ giải mã: PHẢI hỗ trợ ít nhất chế độ Đơn âm và Âm thanh nổi. PHẢI hỗ trợ tốc độ lấy mẫu lên đến 192 kHz; PHẢI hỗ trợ độ phân giải 16 bit và 24 bit. Cấu hình âm thanh dấu phẩy động PHẢI có chức năng xử lý dữ liệu âm thanh FLAC 24 bit.	FLAC (.flac) MPEG-4 (.mp4, .m4a, chỉ giải mã) Matroska (.mkv, chỉ giải mã)
MP3	Âm thanh đơn kênh/âm thanh nổi 8-320 Kb/giây không đổi (CBR) hoặc tốc độ bit biến thiên (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, chỉ giải mã) Matroska (.mkv, chỉ giải mã)
MIDI	MIDI Loại 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF dành cho thiết bị di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody	Loại 0 và 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Giải mã: Hỗ trợ nội dung đơn âm, âm thanh nổi, 5.0 và 5.1 với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. Mã hoá: Hỗ trợ nội dung đơn âm và âm thanh nổi với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, chỉ giải mã) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Bộ mã hoá và giải mã PCM PHẢI hỗ trợ PCM tuyến tính 16 bit và dấu phẩy động 16 bit. Trình trích xuất WAVE phải hỗ trợ PCM tuyến tính 16 bit, 24 bit, 32 bit và dấu phẩy động 32 bit (tốc độ lên đến giới hạn của phần cứng). Tốc độ lấy mẫu PHẢI được hỗ trợ từ 8 kHz đến 192 kHz.	WAVE (.wav)
Opus	Giải mã: Hỗ trợ nội dung đơn âm, âm thanh nổi, 5.0 và 5.1 với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. Mã hoá: Hỗ trợ nội dung đơn âm và âm thanh nổi với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, chỉ giải mã) Matroska (.mkv) Webm (.webm)

5.1.4. Mã hoá hình ảnh

Xem thêm thông tin chi tiết trong phần 5.1.6. Thông tin chi tiết về bộ mã hoá và giải mã hình ảnh.

Việc triển khai thiết bị PHẢI hỗ trợ việc mã hoá hình ảnh theo các phương thức sau:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP

Bắt đầu yêu cầu mới

[C-0-4] AVIF
- Thiết bị phải hỗ trợ BITRATE_MODE_CQ và Hồ sơ cơ sở.

Kết thúc các yêu cầu mới

Nếu việc triển khai thiết bị hỗ trợ mã hoá HEIC thông qua android.media.MediaCodec cho loại nội dung nghe nhìn MIMETYPE_IMAGE_ANDROID_HEIC, thì các thiết bị đó:

[C-1-1] PHẢI cung cấp bộ mã hoá và giải mã HEVC tăng tốc phần cứng hỗ trợ chế độ kiểm soát tốc độ bit BITRATE_MODE_CQ, hồ sơ HEVCProfileMainStill và kích thước khung hình 512 x 512 px.

5.1.5. Giải mã hình ảnh

Xem thêm thông tin chi tiết trong phần 5.1.6. Thông tin chi tiết về bộ mã hoá và giải mã hình ảnh.

Việc triển khai thiết bị PHẢI hỗ trợ giải mã các phương thức mã hoá hình ảnh sau:

[C-0-1] JPEG
[C-0-2] Ảnh GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Thô
[C-0-7] AVIF (Hồ sơ cơ sở)

Nếu việc triển khai thiết bị hỗ trợ giải mã video HEVC, thì các thiết bị đó: * [C-1-1] PHẢI hỗ trợ giải mã hình ảnh HEIF (HEIC).

Bộ giải mã hình ảnh hỗ trợ định dạng độ sâu bit cao (9 bit trở lên trên mỗi kênh):

[C-2-1] PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu ứng dụng yêu cầu, ví dụ: thông qua cấu hình ARGB_8888 của android.graphics.Bitmap.

5.1.6. Thông tin chi tiết về bộ mã hoá và giải mã hình ảnh

Định dạng/Bộ mã hoá và giải mã	Thông tin chi tiết	Các loại tệp/Định dạng vùng chứa được hỗ trợ
JPEG	Cơ sở + luỹ tiến	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.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ồ sơ cơ sở về hình ảnh, bộ sưu tập hình ảnh, trình tự hình ảnh	Vùng chứa HEIF (.avif)

Bộ mã hoá và giải mã hình ảnh được hiển thị thông qua API MediaCodec

[C-1-1] PHẢI hỗ trợ định dạng màu linh hoạt YUV420 8:8:8 (COLOR_FormatYUV420Flexible) thông qua CodecCapabilities.
[C-SR-1] NÊN hỗ trợ định dạng màu RGB888 cho chế độ Surface đầu vào.
[C-1-3] PHẢI hỗ trợ ít nhất một trong các định dạng màu YUV420 8:8:8 phẳng hoặc bán phẳng: COLOR_FormatYUV420PackedPlanar (tương đương với COLOR_FormatYUV420Planar) hoặc COLOR_FormatYUV420PackedSemiPlanar (tương đương với COLOR_FormatYUV420SemiPlanar). Bạn NÊN hỗ trợ cả hai định dạng này.

5.1.7. Bộ mã hoá và giải mã video

Để có chất lượng chấp nhận được cho các dịch vụ phát trực tuyến video trên web và hội nghị truyền hình, việc triển khai thiết bị PHẢI sử dụng bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu.

Nếu quá trình triển khai thiết bị bao gồm bộ giải mã hoặc bộ mã hoá video:

[C-1-1] Bộ mã hoá và giải mã video PHẢI hỗ trợ kích thước vùng đệm byte đầu ra và đầu vào phù hợp với khung hình nén và không nén lớn nhất có thể theo quy định của tiêu chuẩn và cấu hình, nhưng cũng không được phân bổ quá mức.
[C-1-2] Bộ mã hoá và giải mã video PHẢI hỗ trợ các định dạng màu linh hoạt YUV420 8:8:8 (COLOR_FormatYUV420Flexible) thông qua CodecCapabilities.
[C-1-3] Bộ mã hoá và giải mã video PHẢI hỗ trợ ít nhất một trong các định dạng màu phẳng hoặc bán phẳng YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (tương đương với COLOR_FormatYUV420Planar) hoặc COLOR_FormatYUV420PackedSemiPlanar (tương đương với COLOR_FormatYUV420SemiPlanar). Bạn NÊN hỗ trợ cả hai định dạng này.
[C-SR-1] Bạn NÊN hỗ trợ ít nhất một trong các định dạng màu YUV420 8:8:8 phẳng hoặc bán phẳng được tối ưu hoá bằng phần cứng (YV12, NV12, NV21 hoặc định dạng được tối ưu hoá tương đương của nhà cung cấp) cho bộ mã hoá và giải mã video.
[C-1-5] Bộ giải mã video hỗ trợ định dạng độ sâu bit cao (9 bit trở lên trên mỗi kênh) PHẢI hỗ trợ xuất ra định dạng tương đương 8 bit nếu ứng dụng yêu cầu. Điều này PHẢI được phản ánh bằng cách hỗ trợ định dạng màu YUV420 8:8:8 thông qua android.media.MediaCodecInfo.

Nếu việc triển khai thiết bị quảng cáo tính năng hỗ trợ hồ sơ HDR thông qua Display.HdrCapabilities, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ phân tích cú pháp và xử lý siêu dữ liệu tĩnh HDR.

Nếu hoạt động triển khai thiết bị quảng cáo tính năng hỗ trợ làm mới nội bộ thông qua FEATURE_IntraRefresh trong lớp MediaCodecInfo.CodecCapabilities, thì các hoạt động đó:

[C-3-1] PHẢI hỗ trợ khoảng thời gian làm mới trong khoảng từ 10 đến 60 khung hình và hoạt động chính xác trong vòng 20% khoảng thời gian làm mới đã định cấu hình.

Trừ phi ứng dụng chỉ định cách khác bằng cách sử dụng khoá định dạng KEY_COLOR_FORMAT, các hoạt động triển khai bộ giải mã video:

[C-4-1] PHẢI đặt mặc định là định dạng màu được tối ưu hoá cho màn hình phần cứng nếu được định cấu hình bằng đầu ra Surface.
[C-4-2] PHẢI mặc định là định dạng màu YUV420 8:8:8 được tối ưu hoá để đọc CPU nếu được định cấu hình để không sử dụng đầu ra Surface.

5.1.8. Danh sách bộ mã hoá và giải mã video

Định dạng/Bộ mã hoá và giải mã	Thông tin chi tiết	Các loại tệp/Định dạng vùng chứa đượ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 thông tin chi tiết	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, không thể tua) Matroska (.mkv, chỉ giải mã)
H.265 HEVC	Xem mục 5.3 để biết thông tin chi tiết	MPEG-4 (.mp4) Matroska (.mkv, chỉ giải mã)
MPEG-2	Cấu hình chính	MPEG2-TS (.ts, không thể tua) 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 mục 5.2 và 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv)
VP9	Xem mục 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv)
AV1	Xem mục 5.2 và mục 5.3 để biết thông tin chi tiết	MPEG-4 (.mp4) Matroska (.mkv, chỉ giải mã)

5.1.9. Bảo mật bộ mã hoá và giải mã nội dung nghe nhìn

Việc triển khai thiết bị PHẢI đảm bảo tuân thủ các tính năng bảo mật bộ mã hoá và giải mã nội dung nghe nhìn như mô tả bên dưới.

Android hỗ trợ OMX, một API tăng tốc nội dung đa phương tiện trên nhiều nền tảng, cũng như Codec 2.0, một API tăng tốc nội dung đa phương tiện có mức hao tổn thấp.

Nếu việc triển khai thiết bị hỗ trợ nội dung đa phương tiện, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ bộ mã hoá và giải mã nội dung nghe nhìn thông qua API OMX hoặc Codec 2.0 (hoặc cả hai) như trong Dự án nguồn mở Android và không được tắt hoặc lách các biện pháp bảo vệ bảo mật. Điều này không có nghĩa là mọi bộ mã hoá và giải mã PHẢI sử dụng API OMX hoặc Codec 2.0, mà chỉ có nghĩa là PHẢI có khả năng hỗ trợ ít nhất một trong các API này và khả năng hỗ trợ cho các API có sẵn PHẢI bao gồm các biện pháp bảo vệ bảo mật.
[C-SR-1] Bạn NÊN hỗ trợ API Codec 2.0.

Nếu việc triển khai thiết bị không hỗ trợ API Codec 2.0, thì các thiết bị đó:

[C-2-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm OMX tương ứng từ Dự án nguồn mở Android (nếu có) cho từng định dạng và loại nội dung nghe nhìn (bộ mã hoá hoặc bộ giải mã) mà thiết bị hỗ trợ.
[C-2-2] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google". PHẢI dựa trên mã nguồn Dự án nguồn mở Android.
[C-SR-2] Bạn NÊN chạy bộ mã hoá và giải mã phần mềm OMX trong một quy trình bộ mã hoá và giải mã không có quyền truy cập vào trình điều khiển phần cứng ngoài trình ánh xạ bộ nhớ.

Nếu việc triển khai thiết bị hỗ trợ API Codec 2.0, thì các thiết bị đó:

[C-3-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm Codec 2.0 tương ứng từ Dự án nguồn mở Android (nếu có) cho từng định dạng và loại nội dung nghe nhìn (bộ mã hoá hoặc bộ giải mã) mà thiết bị hỗ trợ.
[C-3-2] PHẢI lưu trữ bộ mã hoá và giải mã phần mềm Codec 2.0 trong quy trình bộ mã hoá và giải mã phần mềm như được cung cấp trong Dự án nguồn mở Android để có thể cấp quyền truy cập vào bộ mã hoá và giải mã phần mềm một cách chặt chẽ hơn.
[C-3-3] Bộ mã hoá và giải mã có tên bắt đầu bằng "c2.android". PHẢI dựa trên mã nguồn Dự án nguồn mở Android.

5.1.10. Phân tích bộ mã hoá và giải mã nội dung nghe nhìn

Nếu phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã nội dung nghe nhìn, thì các phương thức đó:

[C-1-1] PHẢI trả về các giá trị chính xác của thông tin mô tả bộ mã hoá và giải mã nội dung nghe nhìn thông qua API MediaCodecInfo.

Cụ thể:

[C-1-2] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX". PHẢI sử dụng các API OMX và có tên tuân thủ nguyên tắc đặt tên OMX IL.
[C-1-3] Bộ mã hoá và giải mã có tên bắt đầu bằng "c2". PHẢI sử dụng API Codec 2.0 và có tên tuân thủ nguyên tắc đặt tên Codec 2.0 cho Android.
[C-1-4] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google" hoặc "c2.android". KHÔNG được mô tả là nhà cung cấp hoặc tăng tốc phần cứng.
[C-1-5] Các bộ mã hoá và giải mã chạy trong quy trình bộ mã hoá và giải mã (nhà cung cấp hoặc hệ thống) có quyền truy cập vào trình điều khiển phần cứng (ngoài trình phân bổ và ánh xạ bộ nhớ) KHÔNG ĐƯỢC coi là chỉ phần mềm.
[C-1-6] Bộ mã hoá và giải mã không có trong Dự án nguồn mở Android hoặc không dựa trên mã nguồn trong dự án đó PHẢI được mô tả là của nhà cung cấp.
[C-1-7] Bộ mã hoá và giải mã sử dụng tính năng tăng tốc phần cứng PHẢI được mô tả là tăng tốc phần cứng.
[C-1-8] Tên bộ mã hoá và giải mã KHÔNG ĐƯỢC gây hiểu lầm. Ví dụ: bộ mã hoá và giải mã có tên "decoders" (bộ giải mã) PHẢI hỗ trợ giải mã và những bộ mã hoá và giải mã có tên "encoders" (bộ mã hoá) PHẢI hỗ trợ mã hoá. Bộ mã hoá và giải mã có tên chứa định dạng nội dung đa phương tiện PHẢI hỗ trợ các định dạng đó.

Nếu phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã video:

[C-2-1] Tất cả bộ mã hoá và giải mã video PHẢI phát hành dữ liệu tốc độ khung hình có thể đạt được cho các kích thước sau đây nếu bộ mã hoá và giải mã 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ã hoá 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 pixel (trình mã hoá MPEG4) 720 x 480 pixel (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)

[C-2-2] Bộ mã hoá và giải mã video được mô tả là tăng tốc phần cứng PHẢI phát hành thông tin về điểm hiệu suất. Mỗi điểm hiệu suất chuẩn PHẢI liệt kê tất cả các điểm hiệu suất chuẩn được hỗ trợ (liệt kê trong API PerformancePoint), trừ phi các điểm hiệu suất chuẩn đó được một điểm hiệu suất chuẩn khác được hỗ trợ bao gồm.
Ngoài ra, họ PHẢI xuất bản các điểm hiệu suất mở rộng nếu hỗ trợ hiệu suất video ổn định ngoài một trong các điểm hiệu suất tiêu chuẩn được liệt kê.

5.2. Mã hoá video

Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hoá video nào và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba, thì các ứng dụng đó:

KHÔNG ĐƯỢC vượt quá 15% tốc độ bit giữa các khoảng thời gian trong khung hình (I-frame) trong hai cửa sổ trượt.

KHÔNG ĐƯỢC vượt quá 100% tốc độ bit trong khoảng thời gian trượt là 1 giây.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hoá video nào và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba, đồng thời đặt
MediaFormat.KEY_BITRATE_MODE thành BITRATE_MODE_VBR để bộ mã hoá hoạt động ở chế độ Tốc độ bit thay đổi, thì miễn là tốc độ bit đó không ảnh hưởng đến chất lượng tối thiểu, tốc độ bit được mã hoá :

~~[C-5-1] PHẢI~~ KHÔNG NÊN vượt quá 15% tốc độ bit giữa các khoảng thời gian khung hình nội bộ (I-frame) trong một cửa sổ trượt.
~~[C-5-2] PHẢI~~ NÊN KHÔNG vượt quá 100% tốc độ bit trong một cửa sổ trượt dài 1 giây.

Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hoá video nào và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba, đồng thời đặt MediaFormat.KEY_BITRATE_MODE thành BITRATE_MODE_CBR để bộ mã hoá hoạt động ở chế độ tốc độ bit không đổi, thì tốc độ bit được mã hoá:

~~[C-6-1] PHẢI~~ [C-SR-2] NÊN KHÔNG vượt quá 15% tốc độ bit mục tiêu trong khoảng thời gian trượt là 1 giây.

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị bao gồm màn hình hiển thị được nhúng có chiều chéo ít nhất là 2,5 inch hoặc bao gồm cổng đầu ra video hoặc khai báo hỗ trợ máy ảnh thông qua cờ tính năng android.hardware.camera.any, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ ít nhất một trong các bộ mã hoá video VP8 hoặc H.264 và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba.
PHẢI hỗ trợ cả bộ mã hoá video VP8 và H.264, đồng thời cung cấp bộ mã hoá này cho các ứng dụng bên thứ ba.

Nếu việc triển khai thiết bị hỗ trợ bất kỳ bộ mã hoá video H.264, VP8, VP9 hoặc HEVC nào và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba, thì các ứng dụng đó:

[C-2-1] PHẢI hỗ trợ tốc độ bit có thể định cấu hình linh động.
NÊN hỗ trợ tốc độ khung hình biến thiên, trong đó bộ mã hoá video NÊN xác định thời lượng khung hình tức thì dựa trên dấu thời gian của vùng đệm đầu vào và phân bổ bộ chứa bit dựa trên thời lượng khung hình đó.

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá video MPEG-4 SP và cung cấp bộ mã hoá này cho các ứng dụng bên thứ ba, thì các ứng dụng đó:

PHẢI hỗ trợ tốc độ bit có thể định cấu hình linh động cho bộ mã hoá được hỗ trợ.

Nếu việc triển khai thiết bị cung cấp bộ mã hoá hình ảnh hoặc video tăng tốc phần cứng và hỗ trợ một hoặc nhiều(các) máy ảnh phần cứng được đính kèm hoặc có thể cắm được hiển thị thông qua API android.camera:

[C-4-1] tất cả bộ mã hoá hình ảnh và video tăng tốc phần cứng PHẢI hỗ trợ việc mã hoá khung hình từ(các) camera phần cứng.
PHẢI hỗ trợ việc mã hoá khung hình từ(các) máy ảnh phần cứng thông qua tất cả bộ mã hoá hình ảnh hoặc video.

Nếu việc triển khai thiết bị cung cấp tính năng mã hoá HDR, thì các thiết bị đó:

[C-SR-1] NÊN cung cấp trình bổ trợ cho API chuyển mã liền mạch để chuyển đổi từ định dạng HDR sang định dạng SDR.

5.2.1. H.263

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá H.263 và cung cấp bộ mã hoá này cho các ứng dụng bên thứ ba, thì các ứng dụng đó:

[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. Không bắt buộc phải có độ phân giải SQCIF.
~~PHẢI hỗ trợ tốc độ bit có thể định cấu hình linh động cho bộ mã hoá được hỗ trợ.~~

5.2.2. H.264

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.264, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ cơ sở cấp 3. Tuy nhiên, bạn KHÔNG BẮT BUỘC phải hỗ trợ ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp khối xếp lớn linh hoạt) và RS (Lát cắt dư thừa). Hơn nữa, để duy trì khả năng tương thích với các thiết bị Android khác, bạn NÊN không sử dụng ASO, FMO và RS cho Hồ sơ cơ sở bằng bộ mã hoá.
[C-1-2] PHẢI hỗ trợ các hồ sơ mã hoá video SD (Độ phân giải chuẩn) trong bảng sau.
PHẢI hỗ trợ Hồ sơ chính cấp 4.
PHẢI hỗ trợ các hồ sơ mã hoá video HD (Độ phân giải cao) như được chỉ định trong bảng sau.

Nếu việc triển khai thiết bị báo cáo hỗ trợ mã hoá H.264 cho video có độ phân giải 720p hoặc 1080p thông qua API đa phương tiện, thì các API đó:

[C-2-1] PHẢI hỗ trợ các hồ sơ mã hoá trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	20 khung hình/giây	30 fps	30 fps	30 fps
Tốc độ bit của video	384 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

5.2.3. VP8

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ hồ sơ mã hoá video SD.
PHẢI hỗ trợ các hồ sơ mã hoá video HD (Độ phân giải cao) sau đây.
[C-1-2] PHẢI hỗ trợ ghi tệp Matroska WebM.
NÊN cung cấp bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu về mã hoá phần cứng RTC của dự án WebM để đảm bảo chất lượng chấp nhận được của dịch vụ truyền phát video trên web và hội nghị truyền hình.

Nếu việc triển khai thiết bị báo cáo hỗ trợ mã hoá VP8 cho video có độ phân giải 720p hoặc 1080p thông qua API đa phương tiện, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ các hồ sơ mã hoá trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

5.2.4. VP9

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9, thì các thiết bị đó:

[C-1-2] PHẢI hỗ trợ Hồ sơ 0 Cấp 3.
[C-1-1] PHẢI hỗ trợ ghi tệp Matroska WebM.
[C-1-3] PHẢI tạo dữ liệu CodecPrivate.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.
[C-SR-1] NÊN hỗ trợ các hồ sơ giải mã HD như được chỉ định trong bảng sau nếu có bộ mã hoá phần cứng.

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

Nếu việc triển khai thiết bị tuyên bố hỗ trợ Hồ sơ 2 hoặc Hồ sơ 3 thông qua Media API:

Không bắt buộc phải hỗ trợ định dạng 12 bit.

5.2.5. H.265

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.265, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ chính cấp 3 có độ phân giải tối đa là 512 x 512.
~~PHẢI hỗ trợ các hồ sơ mã hoá HD như được chỉ định trong bảng sau.~~
[C-SR-1] NÊN hỗ trợ hồ sơ SD 720 x 480 và hồ sơ mã hoá HD như được chỉ định trong bảng sau nếu có bộ mã hoá phần cứng.

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

Bắt đầu yêu cầu mới

5.2.6. AV1

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ chính bao gồm nội dung 8 bit và 10 bit.
[C-1-2] PHẢI phát hành dữ liệu hiệu suất, tức là báo cáo dữ liệu hiệu suất thông qua API getSupportedFrameRatesFor() hoặc getSupportedPerformancePoints() cho các độ phân giải được hỗ trợ trong bảng bên dưới.
[C-1-3] PHẢI chấp nhận siêu dữ liệu HDR và xuất siêu dữ liệu đó sang luồng bit

Nếu bộ mã hoá AV1 được tăng tốc phần cứng, thì bộ mã hoá đó:

[C-2-1] PHẢI hỗ trợ tối đa và bao gồm cả hồ sơ mã hoá HD1080p trong bảng dưới đây:

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	5 Mb/giây	8 Mb/giây	16 Mb/giây	50 Mb/giây

Kết thúc các yêu cầu mới

5.3. Giải mã video

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, VP9, H.264 hoặc H.265, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ độ phân giải video động và chuyển đổi tốc độ khung hình thông qua các API Android tiêu chuẩn trong cùng một luồng cho tất cả bộ mã hoá và giải mã VP8, VP9, H.264 và H.265 theo thời gian thực và lên đến độ phân giải tối đa mà mỗi bộ mã hoá và giải mã hỗ trợ trên thiết bị.

5.3.1. MPEG-2

Nếu quá trình triển khai thiết bị hỗ trợ bộ giải mã MPEG-2, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Cấp cao của Hồ sơ chính.

5.3.2. H.263

Nếu các phương thức triển khai thiết bị hỗ trợ bộ giải mã H.263, thì các phương thức đó:

[C-1-1] PHẢI hỗ trợ Cấu hình cơ sở cấp 30 (độ phân giải CIF, QCIF và SQCIF ở tốc độ 30 khung hình/giây 384 kbit/giây) và cấp 45 (độ phân giải QCIF và SQCIF ở tốc độ 30 khung hình/giây 128 kbit/giây).

5.3.3. MPEG-4

Nếu triển khai thiết bị bằng bộ giải mã MPEG-4, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ đơn giản cấp 3.

5.3.4. H.264

Nếu việc triển khai thiết bị hỗ trợ bộ giải mã H.264, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ chính cấp 3.1 và Hồ sơ cơ sở. Hỗ trợ ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp macroblock linh hoạt) và RS (Lát cắt dư thừa) là KHÔNG BẮT BUỘC.
[C-1-2] PHẢI có khả năng giải mã video có hồ sơ SD (Độ phân giải chuẩn) nêu trong bảng sau và được mã hoá bằng Hồ sơ cơ sở và Hồ sơ chính cấp 3.1 (bao gồm cả 720p30).
PHẢI có khả năng giải mã video theo hồ sơ HD (Độ phân giải cao) như được chỉ định trong bảng sau.

Nếu chiều cao do phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải video, thì việc triển khai thiết bị sẽ:

[C-2-1] PHẢI hỗ trợ các cấu hình giải mã video HD 720p trong bảng sau.
[C-2-2] PHẢI hỗ trợ các hồ sơ giải mã video HD 1080p trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	30 fps	30 fps	60 khung hình/giây	30 khung hình/giây (60 khung hình/giây^TV)
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	8 Mb/giây	20 Mb/giây

5.3.5. H.265 (HEVC)

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.265, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Cấp chính của Hồ sơ chính cấp 3 và hồ sơ giải mã video SD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.
[C-1-2] PHẢI hỗ trợ các hồ sơ giải mã HD như được chỉ định trong bảng sau nếu có bộ giải mã phần cứng.

Nếu chiều cao do phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải video, thì:

[C-2-1] Việc triển khai thiết bị PHẢI hỗ trợ ít nhất một trong các tính năng giải mã H.265 hoặc VP9 của hồ sơ 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30/60 khung hình/giây (60 khung hình/giây^{TV có giải mã phần cứng H.265})	60 khung hình/giây
Tốc độ bit của video	600 Kb/giây	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

Nếu việc triển khai thiết bị tuyên bố hỗ trợ Hồ sơ HDR thông qua API Media:

[C-3-1] Việc triển khai thiết bị PHẢI chấp nhận siêu dữ liệu HDR bắt buộc từ ứng dụng, cũng như hỗ trợ trích xuất và xuất siêu dữ liệu HDR bắt buộc từ luồng bit và/hoặc vùng chứa.
[C-3-2] Việc triển khai thiết bị 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.3.6. VP8

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ các hồ sơ giải mã SD trong bảng sau.
NÊN sử dụng bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu.
NÊN hỗ trợ các hồ sơ giải mã HD trong bảng sau.

Nếu chiều cao do phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải video, thì:

[C-2-1] Việc triển khai thiết bị PHẢI hỗ trợ các hồ sơ 720p trong bảng sau.
[C-2-2] Việc triển khai thiết bị PHẢI hỗ trợ hồ sơ 1080p trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây^TV)	30 (60 khung hình/giây^{Truyền hình})
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	8 Mb/giây	20 Mb/giây

5.3.7. VP9

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ các cấu hình giải mã video SD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.

Nếu phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9 và bộ giải mã phần cứng:

[C-2-1] PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.

Nếu chiều cao do phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải video, thì:

[C-3-1] Việc triển khai thiết bị PHẢI hỗ trợ ít nhất một trong các tính năng giải mã VP9 hoặc H.265 của hồ sơ 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây^{TV có giải mã phần cứng VP9})	60 khung hình/giây
Tốc độ bit của video	600 Kb/giây	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

Nếu hoạt động triển khai thiết bị tuyên bố hỗ trợ VP9Profile2 hoặc VP9Profile3 thông qua API nội dung nghe nhìn 'CodecProfileLevel':

Không bắt buộc phải hỗ trợ định dạng 12 bit.

Nếu việc triển khai thiết bị tuyên bố hỗ trợ Hồ sơ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) thông qua API đa phương tiện:

[C-4-1] Việc triển khai thiết bị PHẢI chấp nhận siêu dữ liệu HDR bắt buộc (KEY_HDR_STATIC_INFO cho tất cả hồ sơ HDR, cũng như 'KEY_HDR10_PLUS_INFO' cho hồ sơ HDR10Plus) từ ứng dụng. Các bộ mã hoá và giải mã này cũng PHẢI hỗ trợ việc trích xuất và xuất siêu dữ liệu HDR bắt buộc từ luồng bit và/hoặc vùng chứa.
[C-4-2] Việc triển khai thiết bị 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.3.8. Dolby Vision

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ bộ giải mã Dolby Vision thông qua HDR_TYPE_DOLBY_VISION, thì các hoạt động đó:

[C-1-1] PHẢI cung cấp trình trích xuất có khả năng hỗ trợ Dolby Vision.
[C-1-2] PHẢI hiển thị đúng nội dung Dolby Vision 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).
[C-1-3] PHẢI đặt mã theo dõi của(các) lớp cơ sở tương thích ngược (nếu có) giống với mã theo dõi của lớp Dolby Vision kết hợp.

5.3.9. AV1

Nếu việc triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Hồ sơ 0, bao gồm cả nội dung 10 bit.

Bắt đầu yêu cầu mới

Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1 và cung cấp bộ mã hoá và giải mã đó cho các ứng dụng bên thứ ba, thì các phương thức đó:

[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ị hỗ trợ bộ mã hoá và giải mã AV1 bằng bộ giải mã tăng tốc phần cứng, thì các thiết bị đó:

[C-2-1] PHẢI có thể giải mã ít nhất là hồ sơ giải mã video HD 720p trong bảng bên dưới khi chiều cao do phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn 720p.
[C-2-2] PHẢI có thể giải mã ít nhất là các hồ sơ giải mã video HD 1080p trong bảng bên dưới khi chiều cao do phương thức Display.getSupportedModes() báo cáo 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 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	5 Mb/giây	8 Mb/giây	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 đa phương tiện, thì các thiết bị đó:

[C-3-1] PHẢI hỗ trợ trích xuất và xuất siêu dữ liệu HDR từ luồng bit và/hoặc vùng chứa.
[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).

Kết thúc các yêu cầu mới

5.4. Ghi âm

Mặc dù một số yêu cầu được nêu trong phần này được liệt kê là NÊN kể từ Android 4.3, nhưng Định nghĩa về khả năng tương thích cho các phiên bản trong tương lai dự kiến sẽ thay đổi các yêu cầu này thành PHẢI. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này được liệt kê là NÊN, nếu không, các thiết bị này sẽ không thể đạt được khả năng tương thích với Android khi được nâng cấp lên phiên bản trong tương lai.

5.4.1. Tính năng ghi âm thanh thô và thông tin về micrô

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các hoạt động đó:

[C-1-1] PHẢI cho phép ghi lại nội dung âm thanh thô cho mọi luồng INPUT AudioRecord hoặc AAudio được mở thành công. Ở mức tối thiểu, bạn PHẢI hỗ trợ các đặc điểm sau:
- Định dạng: PCM tuyến tính, 16 bit
- Tốc độ lấy mẫu: 8000, 11025, 16000, 44100, 48000 Hz
- Kênh: Đơn âm
- Nguồn âm thanh: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, hoặc VOICE_PERFORMANCE. Điều này cũng áp dụng cho các giá trị đặt trước đầu vào tương đương trong AAudio, ví dụ: AAUDIO_INPUT_PRESET_CAMCORDER.
NÊN cho phép ghi lại nội dung âm thanh thô có các đặc điểm sau:
- Định dạng: PCM tuyến tính, 16 bit và 24 bit
- Tốc độ lấy mẫu: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- Kênh: Số lượng kênh bằng số lượng micrô trên thiết bị
[C-1-2] PHẢI quay ở tốc độ lấy mẫu cao hơn mà không cần lấy mẫu lên.
[C-1-3] PHẢI bao gồm bộ lọc khử răng cưa thích hợp khi các tốc độ lấy mẫu nêu trên được chụp bằng cách giảm tần số lấy mẫu.
PHẢI cho phép ghi lại nội dung âm thanh thô ở chất lượng đài AM và DVD, nghĩa là có các đặc điểm sau:
- Định dạng: PCM tuyến tính, 16 bit
- Tốc độ lấy mẫu: 22050, 48000 Hz
- Số kênh: Âm thanh nổi
[C-1-4] PHẢI tuân thủ API MicrophoneInfo và điền chính xác thông tin cho các micrô có sẵn trên thiết bị mà các ứng dụng bên thứ ba có thể truy cập thông qua API AudioManager.getMicrophones(), đối với AudioRecord đang hoạt động bằng cách sử dụng MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED hoặc VOICE_PERFORMANCE. Nếu việc triển khai thiết bị cho phép ghi nội dung âm thanh thô ở chất lượng DVD và đài AM, thì các thiết bị đó:
[C-2-1] PHẢI ghi lại mà không cần lấy mẫu lên ở tỷ lệ nào cao hơn 16000:22050 hoặc 44100:48000.
[C-2-2] PHẢI bao gồm một bộ lọc khử răng cưa thích hợp cho mọi hoạt động lấy mẫu lên hoặc lấy mẫu xuống.

5.4.2. Ghi âm để nhận dạng giọng nói

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các hoạt động đó:

[C-1-1] PHẢI ghi lại nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ở một trong các tốc độ lấy mẫu là 44100 và 48000.
[C-1-2] Theo mặc định, BẮT BUỘC phải tắt mọi quá trình xử lý âm thanh giảm tiếng ồn khi ghi luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
[C-1-3] Theo mặc định, BẮT BUỘC phải tắt mọi chế độ kiểm soát độ khuếch đại tự động khi ghi luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
PHẢI thể hiện các đặc điểm biên độ so với tần số gần như bằng phẳng trong dải tần số trung bình: cụ thể là ±3dB từ 100 Hz đến 4000 Hz cho từng micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
[C-SR-1] NÊN cho thấy các mức biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 30 Hz đến 100 Hz so với dải tần số trung bình cho mỗi micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
[C-SR-2] NÊN cho thấy các mức biên độ trong dải tần số cao: cụ thể là từ ±30 dB từ 4000 Hz đến 22 KHz so với dải tần số trung bình cho từng micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
NÊN đặt độ nhạy đầu vào âm thanh sao cho nguồn âm thanh dạng sóng sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 90 dB (được đo ~~ở khoảng cách 30 cm từ~~ bên cạnh micrô) sẽ cho ra phản hồi lý tưởng là RMS 2500 trong phạm vi từ 1770 đến 3530 đối với các mẫu 16 bit (hoặc -22,35 db ±3dB Full Scale đối với các mẫu dấu phẩy động/độ chính xác kép) cho mọi micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
NÊN ghi luồng âm thanh nhận dạng giọng nói để các mức biên độ PCM theo dõi tuyến tính các thay đổi về SPL đầu vào trong phạm vi ít nhất là 30 dB từ -18 dB đến +12 dB so với 90 dB SPL tại micrô.
NÊN ghi luồng âm thanh nhận dạng giọng nói với độ méo hài tổng (THD) dưới 1% đối với 1 kHz ở mức đầu vào SPL 90 dB tại micrô.

Nếu quá trình triển khai thiết bị khai báo android.hardware.microphone và các công nghệ triệt tiêu (giảm) tiếng ồn được điều chỉnh để nhận dạng giọng nói, thì các công nghệ đó sẽ:

[C-2-1] PHẢI cho phép kiểm soát hiệu ứng âm thanh này bằng API android.media.audiofx.NoiseSuppressor.
[C-2-2] PHẢI xác định riêng từng cách triển khai công nghệ giảm nhiễu thông qua trường AudioEffect.Descriptor.uuid.

5.4.3. Ghi lại để định tuyến lại quá trình phát

Lớp android.media.MediaRecorder.AudioSource bao gồm nguồn âm thanh REMOTE_SUBMIX.

Nếu các hoạt động triển khai thiết bị khai báo cả android.hardware.audio.output và android.hardware.microphone, thì các hoạt động đó:

[C-1-1] PHẢI triển khai đúng cách nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng sử dụng API android.media.AudioRecord để ghi âm từ nguồn âm thanh này, ứng dụng đó sẽ ghi lại tất cả các luồng âm thanh ngoại trừ những luồng sau:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Trình khử tiếng vọng âm thanh

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các hoạt động đó:

NÊN triển khai công nghệ Loại bỏ tiếng vọng âm thanh (AEC) được điều chỉnh để giao tiếp bằng giọng nói và áp dụng cho đường dẫn chụp khi chụp bằng AudioSource.VOICE_COMMUNICATION.

Nếu việc triển khai thiết bị cung cấp một Trình loại bỏ tiếng vọng âm thanh được chèn vào đường dẫn âm thanh ghi lại khi chọn AudioSource.VOICE_COMMUNICATION, thì các thiết bị đó:

[C-SR-1] NÊN khai báo thông tin này thông qua phương thức API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
[C-SR-2] ĐỀ_XUẤT_MẠNH để cho phép kiểm soát hiệu ứng âm thanh này bằng API AcousticEchoCanceler.
[C-SR-3] NÊN xác định riêng từng cách triển khai công nghệ AEC thông qua trường AudioEffect.Descriptor.uuid.

5.4.5. Chụp đồng thời

Nếu quá trình triển khai thiết bị khai báo android.hardware.microphone,thì chúng PHẢI triển khai tính năng chụp đồng thời như mô tả trong tài liệu này. Cụ thể:

[C-1-1] PHẢI cho phép truy cập đồng thời vào micrô bằng một dịch vụ hỗ trợ tiếp cận ghi lại bằng AudioSource.VOICE_RECOGNITION và ít nhất một ứng dụng ghi lại bằng AudioSource bất kỳ.
[C-1-2] PHẢI cho phép quyền truy cập đồng thời vào micrô của một ứng dụng được cài đặt sẵn có vai trò Trợ lý và ít nhất một ứng dụng ghi lại bằng bất kỳ AudioSource nào ngoại trừ AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER.
[C-1-3] PHẢI tắt tính năng ghi âm cho mọi ứng dụng khác, ngoại trừ dịch vụ hỗ trợ tiếp cận, trong khi một ứng dụng đang ghi âm bằng AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER. Tuy nhiên, khi một ứng dụng đang ghi lại thông qua AudioSource.VOICE_COMMUNICATION, thì một ứng dụng khác có thể ghi lại cuộc gọi thoại nếu đó là ứng dụng đặc quyền (được cài đặt sẵn) có quyền CAPTURE_AUDIO_OUTPUT.
[C-1-4] Nếu hai hoặc nhiều ứng dụng đang ghi lại đồng thời và nếu không có ứng dụng nào có giao diện người dùng ở trên cùng, thì ứng dụng bắt đầu ghi lại gần đây nhất sẽ nhận được âm thanh.

5.5. Phát âm thanh

Android hỗ trợ cho phép các ứng dụng phát âm thanh thông qua thiết bị ngoại vi đầu ra âm thanh như được xác định trong phần 7.8.2.

5.5.1. Phát âm thanh thô

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.audio.output, thì các hoạt động đó:

[C-1-1] PHẢI cho phép phát nội dung âm thanh thô có các đặc điểm sau:
- Định dạng nguồn: PCM tuyến tính, 16 bit, 8 bit, dấu phẩy động
- Kênh: Âm thanh đơn kênh, âm thanh nổi, cấu hình đa kênh hợp lệ với tối đa 8 kênh
- Tốc độ lấy mẫu (tính bằng Hz):
  - 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 ở cấu hình kênh nêu trên
  - 96000 ở chế độ đơn âm và âm thanh nổi

5.5.2. Hiệu ứng âm thanh

Android cung cấp API cho hiệu ứng âm thanh để triển khai trên thiết bị.

Nếu quá trình triển khai thiết bị khai báo tính năng android.hardware.audio.output, thì các quá trình đó:

[C-1-1] PHẢI hỗ trợ các hoạt động triển khai EFFECT_TYPE_EQUALIZER và EFFECT_TYPE_LOUDNESS_ENHANCER có thể kiểm soát được thông qua các lớp con AudioEffect Equalizer và LoudnessEnhancer.
[C-1-2] PHẢI hỗ trợ việc triển khai API trình trực quan hoá, có thể kiểm soát thông qua lớp Visualizer.
[C-1-3] PHẢI hỗ trợ việc triển khai EFFECT_TYPE_DYNAMICS_PROCESSING có thể kiểm soát được thông qua lớp con AudioEffect DynamicsProcessing.

Bắt đầu yêu cầu mới

[C-1-4] PHẢI hỗ trợ hiệu ứng âm thanh với đầu vào và đầu ra dấu phẩy động.
[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 bộ trộn còn gọi là FCC_LIMIT.

Kết thúc các yêu cầu mới

NÊN hỗ trợ các hoạt động triển khai EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB và EFFECT_TYPE_VIRTUALIZER có thể kiểm soát thông qua các lớp con AudioEffect BassBoost, EnvironmentalReverb, PresetReverb và Virtualizer.
[C-SR-1] NÊN hỗ trợ các hiệu ứng ở dấu phẩy động và nhiều kênh.

5.5.3. Âm lượng đầu ra âm thanh

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

NÊN cho phép điều chỉnh âm lượng âm thanh riêng biệt cho từng luồng âm thanh bằng cách sử dụng loại nội dung hoặc cách sử dụng do AudioAttributes xác định và cách sử dụng âm thanh trên ô tô được xác định công khai trong android.car.CarAudioManager.

5.5.4. Giảm tải âm thanh

Nếu việc triển khai thiết bị hỗ trợ phát âm thanh khi giảm tải, thì các thiết bị đó:

[C-SR-1] Bạn NÊN cắt nội dung âm thanh phát không gián đoạn giữa hai đoạn với cùng định dạng khi được API AudioTrack không gián đoạn và vùng chứa nội dung đa phương tiện cho MediaPlayer chỉ định.

5.6. Độ trễ âm thanh

Độ trễ âm thanh là độ trễ thời gian khi tín hiệu âm thanh truyền qua một hệ thống. Nhiều lớp ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng âm thanh theo thời gian thực.

Trong mục này, hãy sử dụng các định nghĩa sau:

độ trễ đầu ra. Khoảng thời gian giữa thời điểm một ứng dụng ghi một khung dữ liệu được mã hoá PCM và thời điểm âm thanh tương ứng được hiển thị cho môi trường tại một bộ chuyển đổi trên thiết bị hoặc tín hiệu rời khỏi thiết bị thông qua một cổng và có thể được quan sát bên ngoài.
Độ trễ đầu ra nguội. Khoảng thời gian giữa lúc bắt đầu luồng đầu ra và thời gian hiển thị khung hình đầu tiên dựa trên dấu thời gian, khi hệ thống đầu ra âm thanh ở trạng thái rảnh và tắt nguồn trước yêu cầu.
độ trễ đầu ra liên tục. Độ trễ đầu ra cho các khung hình tiếp theo, sau khi thiết bị phát âm thanh.
độ trễ đầu vào. Khoảng thời gian giữa thời điểm âm thanh được môi trường trình bày cho thiết bị tại một bộ chuyển đổi trên thiết bị hoặc tín hiệu đi vào thiết bị thông qua một cổng và thời điểm ứng dụng đọc khung tương ứng của dữ liệu được mã hoá PCM.
mất dữ liệu đầu vào. Phần đầu của tín hiệu đầu vào không thể sử dụng hoặc không có.
Độ trễ đầu vào nguội. Khoảng thời gian giữa lúc bắt đầu truyền phát và khi nhận được khung hình hợp lệ đầu tiên, khi hệ thống đầu vào âm thanh ở trạng thái rảnh và tắt trước yêu cầu.
độ trễ đầu vào liên tục. Độ trễ đầu vào cho các khung hình tiếp theo, trong khi thiết bị đang ghi âm.
độ trễ trọn vòng liên tục. Tổng độ trễ đầu vào liên tục cộng với độ trễ đầu ra liên tục cộng với một khoảng thời gian đệm. Khoảng thời gian đệm cho phép ứng dụng xử lý tín hiệu và thời gian để ứng dụng giảm thiểu sự khác biệt về pha giữa luồng đầu vào và đầu ra.
API hàng đợi bộ đệm PCM OpenSL ES. Tập hợp các API OpenSL ES liên quan đến PCM trong Android NDK.
API âm thanh gốc AAudio. Tập hợp các API AAudio trong Android NDK.
Dấu thời gian. Một cặp bao gồm vị trí khung tương đối trong luồng và thời gian ước tính khi khung đó vào hoặc rời khỏi quy trình xử lý âm thanh trên điểm cuối được liên kết. Xem thêm về AudioTimestamp.
lỗi. Sự gián đoạn tạm thời hoặc giá trị mẫu không chính xác trong tín hiệu âm thanh, thường là do vùng đệm bị thiếu đối với đầu ra, vùng đệm bị tràn đối với đầu vào hoặc bất kỳ nguồn nhiễu kỹ thuật số hoặc tương tự nào khác.
độ lệch tuyệt đối trung bình. Giá trị trung bình của giá trị tuyệt đối của độ lệch so với giá trị trung bình cho một tập hợp giá trị.
Độ trễ nhấn để phát âm thanh. Khoảng thời gian từ khi màn hình được nhấn đến khi âm thanh được tạo ra do thao tác nhấn đó phát ra trên loa.

Nếu việc triển khai thiết bị khai báo android.hardware.audio.output, thì các thiết bị đó PHẢI đáp ứng hoặc vượt quá các yêu cầu sau:

[C-1-1] Dấu thời gian đầu ra do AudioTrack.getTimestamp và AAudioStream_getTimestamp trả về có độ chính xác +/- 2 mili giây.
[C-1-2] Độ trễ đầu ra nguội từ 500 mili giây trở xuống.
[C-1-3] Việc mở luồng đầu ra bằng AAudioStreamBuilder_openStream() PHẢI mất ít hơn 1000 mili giây.

Nếu triển khai thiết bị khai báo android.hardware.audio.output, bạn NÊN đáp ứng hoặc vượt quá các yêu cầu sau:

[C-SR-1] Độ trễ đầu ra nguội từ 100 mili giây trở xuống qua đường dẫn dữ liệu của loa.
[C-SR-2] Độ trễ nhấn để phát âm thanh từ 80 mili giây trở xuống.

~~[C-SR-4] Dấu thời gian đầu ra do AudioTrack.getTimestamp và AAudioStream_getTimestamp trả về chính xác đến +/- 1 mili giây.~~

Bắt đầu yêu cầu mới

[C-SR-4] Bạn NÊN đặt độ trễ trọn vòng được tính toán dựa trên dấu thời gian đầu vào và đầu ra do AAudioStream_getTimestamp trả về trong vòng 30 mili giây so với độ trễ trọn vòng được đo lường cho AAUDIO_PERFORMANCE_MODE_NONE và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY đối với loa, tai nghe có dây và không dây.

Kết thúc các yêu cầu mới

Nếu việc triển khai thiết bị đáp ứng các yêu cầu trên, sau khi hiệu chuẩn ban đầu, khi sử dụng API âm thanh gốc AAudio, đối với độ trễ đầu ra liên tục và độ trễ đầu ra nguội trên ít nhất một thiết bị đầu ra âm thanh được hỗ trợ, thì các độ trễ này là:

[C-SR-5] NÊN báo cáo âm thanh có độ trễ thấp bằng cách khai báo cờ tính năng android.hardware.audio.low_latency.
[C-SR-6] NÊN đáp ứng các yêu cầu về âm thanh có độ trễ thấp thông qua API AAudio.
[C-SR-7] BẠN NÊN đảm bảo rằng đối với các luồng trả về AAUDIO_PERFORMANCE_MODE_LOW_LATENCY từ AAudioStream_getPerformanceMode(), giá trị do AAudioStream_getFramesPerBurst() trả về nhỏ hơn hoặc bằng giá trị do android.media.AudioManager.getProperty(String) trả về cho khoá thuộc tính AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Nếu việc triển khai thiết bị không đáp ứng các yêu cầu về âm thanh có độ trễ thấp thông qua API âm thanh gốc AAudio, thì các thiết bị đó:

[C-2-1] KHÔNG ĐƯỢC báo cáo hỗ trợ âm thanh có độ trễ thấp.

Nếu triển khai thiết bị bao gồm android.hardware.microphone, thì các thiết bị đó PHẢI đáp ứng các yêu cầu sau đây về âm thanh đầu vào:

[C-3-1] Giới hạn lỗi trong dấu thời gian đầu vào do AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp trả về ở mức +/- 2 mili giây. "Lỗi" ở đây có nghĩa là độ lệch so với giá trị chính xác.
[C-3-2] Độ trễ đầu vào nguội từ 500 mili giây trở xuống.
[C-3-3] Việc mở luồng đầu vào bằng AAudioStreamBuilder_openStream() PHẢI mất ít hơn 1000 mili giây.

Nếu triển khai thiết bị bao gồm android.hardware.microphone, bạn NÊN đáp ứng các yêu cầu sau đây về âm thanh đầu vào:

[C-SR-8] Độ trễ đầu vào nguội từ 100 mili giây trở xuống qua đường dẫn dữ liệu micrô.
[C-SR-11] Giới hạn lỗi trong dấu thời gian đầu vào do AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp trả về ở mức +/- 1 mili giây.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.audio.output và android.hardware.microphone, thì các hoạt động đó:

[C-SR-12] NÊN có Độ trễ trọn vòng liên tục trung bình là 50 mili giây trở xuống trên 5 lần đo lường, với Độ lệch tuyệt đối trung bình dưới 10 mili giây trên ít nhất một đường dẫn được hỗ trợ.

5.7. Giao thức mạng

Việc triển khai thiết bị PHẢI hỗ trợ các giao thức mạng đa phương tiện để phát âm thanh và video như được chỉ định trong tài liệu SDK Android.

Đối với mỗi bộ mã hoá và giải mã và định dạng vùng chứa mà quá trình triển khai thiết bị bắt buộc phải hỗ trợ, quá trình triển khai thiết bị:

[C-1-1] PHẢI hỗ trợ bộ mã hoá và giải mã hoặc vùng chứa đó qua HTTP và HTTPS.
[C-1-2] PHẢI hỗ trợ các định dạng phân đoạn nội dung đa phương tiện tương ứng như trong bảng định dạng phân đoạn nội dung đa phương tiện bên dưới qua Giao thức dự thảo Phát trực tuyến qua HTTP, Phiên bản 7.
[C-1-3] PHẢI hỗ trợ các định dạng tải trọng RTSP tương ứng như trong bảng RTSP bên dưới. Đối với các trường hợp ngoại lệ, vui lòng xem chú thích cuối bảng trong mục 5.1.

Định dạng phân đoạn nội dung nghe nhìn

Định dạng phân đoạn	(Các) tài liệu tham khảo	Hỗ trợ bộ mã hoá và giải mã bắt buộc
Luồng truyền tải MPEG-2	ISO 13818	Bộ mã hoá và giải mã video: H264 AVC MPEG-4 SP MPEG-2 Hãy xem mục 5.1.8 để biết thông tin chi tiết về H264 AVC, MPEG2-4 SP, và MPEG-2. Bộ mã hoá và giải mã âm thanh: (chuẩn) AAC Hãy xem mục 5.1.3 để biết thông tin chi tiết về AAC và các biến thể của nó.
AAC với khung ADTS và thẻ ID3	ISO 13818-7	Xem mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC
WebVTT	WebVTT

Định dạng phân đoạn

(Các) tài liệu tham khảo

Hỗ trợ bộ mã hoá và giải mã bắt buộc

Luồng truyền tải MPEG-2

ISO 13818

Bộ mã hoá và giải mã video:

H264 AVC
MPEG-4 SP
MPEG-2

Hãy xem mục 5.1.8 để biết thông tin chi tiết về H264 AVC, MPEG2-4 SP,
và MPEG-2.

Bộ mã hoá và giải mã âm thanh:

(chuẩn) AAC

Hãy xem mục 5.1.3 để biết thông tin chi tiết về AAC và các biến thể của nó.

AAC với khung ADTS và thẻ ID3

ISO 13818-7

Xem mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC

WebVTT

RTSP (RTP, SDP)

Tên hồ sơ	(Các) tài liệu tham khảo	Hỗ trợ bộ mã hoá và giải mã bắt buộc
H264 AVC	RFC 6184	Xem mục 5.1.8 để biết thông tin chi tiết về H264 AVC
MP4A-LATM	RFC 6416	Xem mục 5.1.3 để biết thông tin chi tiết về AAC và các biến thể của AAC
H263-1998	RFC 3551 RFC 4629 RFC 2190	Xem phần 5.1.8 để biết thông tin chi tiết về H263
H263-2000	RFC 4629	Xem phần 5.1.8 để biết thông tin chi tiết về H263
AMR	RFC 4867	Xem phần 5.1.3 để biết thông tin chi tiết về AMR-NB
AMR-WB	RFC 4867	Xem phần 5.1.3 để biết thông tin chi tiết về AMR-WB
MP4V-ES	RFC 6416	Xem phần 5.1.8 để biết thông tin chi tiết về MPEG-4 SP
mpeg4-generic	RFC 3640	Xem mục 5.1.3 để biết thông tin chi tiết về AAC và các biến thể của AAC
MP2T	RFC 2250	Xem Luồng truyền tải MPEG-2 bên dưới phần Phát trực tuyến dựa trên HTTP để biết thông tin chi tiết

5.8. Secure Media

Nếu việc triển khai thiết bị hỗ trợ đầu ra video an toàn và có khả năng hỗ trợ các nền tảng bảo mật, thì các thiết bị đó:

[C-1-1] PHẢI khai báo hỗ trợ cho Display.FLAG_SECURE.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ Display.FLAG_SECURE và hỗ trợ giao thức hiển thị không dây, thì các hoạt động đó:

[C-2-1] PHẢI bảo mật đường liên kết bằng một cơ chế mã hoá mạnh như HDCP 2.x trở lên đối với các màn hình được kết nối thông qua các giao thức không dây như Miracast.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ Display.FLAG_SECURE và hỗ trợ màn hình ngoài có dây, thì các hoạt động đó:

[C-3-1] PHẢI hỗ trợ HDCP 1.2 trở lên cho tất cả màn hình ngoài được kết nối thông qua cổng có dây mà người dùng có thể truy cập.

5.9. Giao diện kỹ thuật số cho nhạc cụ (MIDI)

Nếu việc triển khai thiết bị báo cáo hỗ trợ tính năng android.software.midi thông qua lớp android.content.pm.PackageManager, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ MIDI qua tất cả phương thức truyền tải phần cứng có khả năng MIDI mà các phương thức này cung cấp khả năng kết nối chung không phải MIDI, trong đó các phương thức truyền tải đó là:
- Chế độ máy chủ USB, mục 7.7
- MIDI qua Bluetooth LE đóng vai trò trung tâm, mục 7.4.3
[C-1-2] PHẢI hỗ trợ việc truyền phần mềm MIDI giữa các ứng dụng (thiết bị MIDI ảo)
[C-1-3] BẮT BUỘC phải bao gồm libamidi.so (hỗ trợ MIDI gốc)
PHẢI hỗ trợ MIDI qua chế độ thiết bị ngoại vi USB, mục 7.7

5.10. Âm thanh chuyên nghiệp

Nếu quá trình triển khai thiết bị báo cáo hỗ trợ tính năng android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo khả năng hỗ trợ tính năng android.hardware.audio.low_latency.
[C-1-2] PHẢI có độ trễ âm thanh trọn vòng liên tục, như được xác định trong phần 5.6 Độ trễ âm thanh là 25 mili giây trở xuống trên ít nhất một đường dẫn được hỗ trợ.
[C-1-3] PHẢI có(các) cổng USB hỗ trợ chế độ máy chủ USB và chế độ ngoại vi USB.
[C-1-4] PHẢI báo cáo khả năng hỗ trợ tính năng android.software.midi.
[C-1-5] PHẢI đáp ứng độ trễ và các yêu cầu về âm thanh USB bằng cách sử dụng API âm thanh gốc AAudio và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] PHẢI có độ trễ đầu ra nguội từ 200 mili giây trở xuống.
[C-1-7] PHẢI có độ trễ đầu vào nguội từ 200 mili giây trở xuống.
[C-1-8] PHẢI có độ trễ trung bình của tính năng Nhấn để phát âm thanh là 80 mili giây trở xuống trong ít nhất 5 lần đo lường trên đường dẫn dữ liệu từ loa đến micrô.
[C-SR-1] Bạn NÊN đáp ứng độ trễ như được xác định trong phần 5.6 Độ trễ âm thanh, từ 20 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây trên đường dẫn từ loa đến micrô.
[C-SR-2] Bạn NÊN đáp ứng các yêu cầu về Âm thanh chuyên nghiệp đối với độ trễ âm thanh liên tục, độ trễ đầu vào nguội và độ trễ đầu ra nguội cũng như các yêu cầu về âm thanh USB bằng cách sử dụng API Âm thanh gốc AAudio trên đường dẫn MMAP.
[C-SR-3] NÊN cung cấp mức hiệu suất CPU nhất quán trong khi âm thanh đang hoạt động và tải CPU đang thay đổi. Bạn nên kiểm thử điều này bằng ứng dụng Android SynthMark. SynthMark sử dụng một trình tổng hợp phần mềm chạy trên khung âm thanh mô phỏng để đo lường hiệu suất hệ thống. Hãy xem tài liệu về SynthMark để biết nội dung giải thích về các điểm chuẩn. Bạn cần chạy ứng dụng SynthMark bằng tuỳ chọn "Kiểm thử tự động" và đạt được các kết quả sau:
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 mili giây
- latencymark.dynamic.little <= 50 mili giây
PHẢI giảm thiểu độ không chính xác và độ trễ của đồng hồ âm thanh so với thời gian chuẩn.
NÊN giảm thiểu độ trễ đồng hồ âm thanh so với CLOCK_MONOTONIC của CPU khi cả hai đều đang hoạt động.
NÊN giảm thiểu độ trễ âm thanh qua các bộ chuyển đổi trên thiết bị.
NÊN giảm thiểu độ trễ âm thanh qua âm thanh kỹ thuật số qua USB.
NÊN ghi lại kết quả đo lường độ trễ âm thanh trên tất cả các đường dẫn.
NÊN giảm thiểu độ trễ trong thời gian nhập lệnh gọi lại hoàn tất bộ đệm âm thanh, vì điều này ảnh hưởng đến tỷ lệ phần trăm băng thông CPU đầy đủ có thể sử dụng của lệnh gọi lại.
PHẢI không có lỗi âm thanh nào khi sử dụng bình thường ở độ trễ được báo cáo.
PHẢI cung cấp độ trễ giữa các kênh bằng 0.
NÊN giảm thiểu độ trễ trung bình của MIDI trên tất cả các phương thức truyền tải.
NÊN giảm thiểu độ biến thiên độ trễ MIDI khi tải (jitter) trên tất cả các phương thức truyền tải.
NÊN cung cấp dấu thời gian MIDI chính xác trên tất cả các phương thức truyền tải.
NÊN giảm thiểu nhiễu tín hiệu âm thanh qua các bộ chuyển đổi trên thiết bị, bao gồm cả khoảng thời gian ngay sau khi khởi động nguội.
NÊN cung cấp độ lệch xung nhịp âm thanh bằng 0 giữa phía đầu vào và đầu ra của các điểm cuối tương ứng, khi cả hai đều đang hoạt động. Ví dụ về các điểm cuối tương ứng bao gồm micrô và loa trên thiết bị hoặc đầu vào và đầu ra của giắc cắm âm thanh.
NÊN xử lý lệnh gọi lại hoàn tất bộ đệm âm thanh cho phía đầu vào và đầu ra của các điểm cuối tương ứng trên cùng một luồng khi cả hai đều đang hoạt động và nhập lệnh gọi lại đầu ra ngay sau khi trả về từ lệnh gọi lại đầu vào. Hoặc nếu không thể xử lý các lệnh gọi lại trên cùng một luồng, hãy nhập lệnh gọi lại đầu ra ngay sau khi nhập lệnh gọi lại đầu vào để cho phép ứng dụng có thời gian nhất quán cho các bên đầu vào và đầu ra.
NÊN giảm thiểu độ lệch pha giữa việc lưu trữ âm thanh HAL cho các bên đầu vào và đầu ra của các điểm cuối tương ứng.
NÊN giảm thiểu độ trễ khi chạm.
NÊN giảm thiểu độ biến thiên của độ trễ cảm ứng khi tải (jitter).

Nếu việc triển khai thiết bị đáp ứng tất cả các yêu cầu nêu trên, thì:

[C-SR-4] NÊN báo cáo tính năng hỗ trợ android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager.

Nếu việc triển khai thiết bị bao gồm giắc âm thanh 3,5 mm 4 dây, thì các thiết bị đó:

[C-2-1] PHẢI có Độ trễ âm thanh trọn vòng liên tục trung bình, như được xác định trong phần 5.6 Độ trễ âm thanh, từ 20 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây trên đường dẫn giắc cắm âm thanh bằng cách sử dụng Audio Loopback Dongle.
[C-SR-5] BẠN NÊN tuân thủ phần Thông số kỹ thuật của thiết bị di động (giắc cắm) của Thông số kỹ thuật của tai nghe âm thanh có dây (phiên bản 1.1).

Nếu việc triển khai thiết bị bỏ qua giắc âm thanh 3,5 mm 4 dây và bao gồm(các) cổng USB hỗ trợ chế độ máy chủ USB, thì các thiết bị đó:

[C-3-1] PHẢI triển khai lớp âm thanh USB.
[C-3-2] PHẢI có Độ trễ âm thanh liên tục trung bình là 25 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây qua cổng chế độ máy chủ USB bằng cách sử dụng lớp âm thanh USB. (Bạn có thể đo lường bằng cách sử dụng bộ chuyển đổi USB-3, 5 mm và USB Loopback Dongle hoặc sử dụng giao diện âm thanh USB với cáp nối kết nối đầu vào với đầu ra).
[C-SR-6] NÊN hỗ trợ I/O đồng thời lên đến 8 kênh cho mỗi hướng, tốc độ lấy mẫu 96 kHz và độ sâu 24 bit hoặc 32 bit, khi sử dụng với các thiết bị ngoại vi âm thanh USB cũng hỗ trợ các yêu cầu này.
[C-SR-7] Bạn NÊN đáp ứng nhóm yêu cầu này bằng cách sử dụng API âm thanh gốc AAudio qua đường dẫn MMAP.

Nếu triển khai cổng HDMI, thiết bị sẽ:

PHẢI hỗ trợ đầu ra âm thanh nổi và 8 kênh ở độ sâu 20 bit hoặc 24 bit và 192 kHz mà không làm mất độ sâu bit hoặc lấy mẫu lại, trong ít nhất một cấu hình.

5.11. Chụp cho chưa xử lý

Android hỗ trợ tính năng ghi âm thanh chưa xử lý thông qua nguồn âm thanh android.media.MediaRecorder.AudioSource.UNPROCESSED. Trong OpenSL ES, bạn có thể truy cập vào SL_ANDROID_RECORDING_PRESET_UNPROCESSED cài đặt trước bản ghi.

Nếu việc triển khai thiết bị có ý định hỗ trợ nguồn âm thanh chưa qua xử lý và cung cấp nguồn âm thanh đó cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo tính năng hỗ trợ thông qua thuộc tính android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] PHẢI thể hiện các đặc điểm biên độ so với tần số gần như phẳng trong dải tần số trung bình: cụ thể là ±10 dB từ 100 Hz đến 7000 Hz đối với từng micrô dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-3] PHẢI hiển thị các mức biên độ trong phạm vi tần số thấp: cụ thể là từ ±20 dB từ 5 z đến 100 Hz so với phạm vi tần số trung bình cho mỗi micrô dùng để ghi nguồn âm thanh chưa xử lý.
[C-1-4] PHẢI hiển thị các mức biên độ trong dải tần số cao: cụ thể là từ ±30 dB từ 7000 Hz đến 22 KHz so với dải tần số trung bình cho từng micrô dùng để ghi nguồn âm thanh chưa xử lý.
[C-1-5] PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn âm thanh hình sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 94 dB sẽ tạo ra phản hồi có RMS là 520 đối với các mẫu 16 bit (hoặc -36 dB Full Scale đối với các mẫu dấu phẩy động/độ chính xác gấp đôi) cho mọi micrô dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-6] PHẢI có tỷ lệ tín hiệu trên tạp âm (SNR) ở mức 60 dB trở lên đối với mọi micrô dùng để ghi nguồn âm thanh chưa qua xử lý. (trong khi SNR được đo bằng chênh lệch giữa 94 dB SPL và SPL tương đương của tiếng ồn tự thân, theo trọng số A).
[C-1-7] PHẢI có tổng độ méo hài (THD) nhỏ hơn 1% đối với 1 kHZ ở mức đầu vào SPL 90 dB tại mỗi micrô dùng để ghi nguồn âm thanh chưa xử lý.
[C-1-8] KHÔNG được có bất kỳ quá trình xử lý tín hiệu nào khác (ví dụ: Tự động kiểm soát độ lợi, Bộ lọc thông cao hoặc Huỷ tiếng vọng) trong đường dẫn ngoài hệ số mức để đưa mức độ đến phạm vi mong muốn. Hay nói cách khác:
- [C-1-9] Nếu có bất kỳ hoạt động xử lý tín hiệu nào trong cấu trúc vì bất kỳ lý do nào, thì hoạt động đó PHẢI bị tắt và phải đưa ra hiệu quả không có độ trễ hoặc độ trễ bổ sung cho đường dẫn tín hiệu.
- [C-1-10] Mặc dù được phép nằm trên đường dẫn, nhưng hệ số mức KHÔNG ĐƯỢC gây ra độ trễ hoặc độ trễ cho đường dẫn tín hiệu.

Tất cả các phép đo SPL đều được thực hiện ngay bên cạnh micrô đang được kiểm thử. Đối với nhiều cấu hình micrô, các yêu cầu này áp dụng cho từng micrô.

Nếu việc triển khai thiết bị khai báo android.hardware.microphone nhưng không hỗ trợ nguồn âm thanh chưa xử lý, thì các thiết bị đó:

[C-2-1] PHẢI trả về null cho phương thức API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) để cho biết chính xác việc không được hỗ trợ.
[C-SR-1] VẪN NÊN đáp ứng nhiều yêu cầu nhất có thể đối với đường dẫn tín hiệu của nguồn ghi chưa xử lý.

5.12. HDR Video

Android 13 hỗ trợ các công nghệ HDR như mô tả trong tài liệu sắp ra mắt.

Định dạng pixel

Nếu bộ giải mã video quảng cáo hỗ trợ COLOR_FormatYUVP010, thì:

[C-1-1] PHẢI hỗ trợ định dạng P010 để đọc bằng CPU (ImageReader, MediaImage, ByteBuffer). Trong Android 13, P010 được nới lỏng để cho phép bước tuỳ ý cho các mặt phẳng Y và UV.
[C-1-2] GPU PHẢI lấy mẫu được vùng đệm đầu ra P010 (khi được phân bổ với mức sử dụng GPU_SAMPLING). Điều này cho phép các ứng dụng kết hợp GPU và ánh xạ tông màu tuỳ chỉnh.

Nếu bộ giải mã video quảng cáo hỗ trợ COLOR_Format32bitABGR2101010, thì bộ giải mã đó:

[C-2-1] PHẢI hỗ trợ định dạng RGBA_1010102 cho nền tảng đầu ra và có thể đọc được bằng CPU (đầu ra ByteBuffer).

Nếu bộ mã hoá video quảng cáo hỗ trợ COLOR_FormatYUVP010, thì bộ mã hoá đó:

[C-3-1] PHẢI hỗ trợ định dạng P010 cho giao diện đầu vào và đầu vào có thể ghi bằng CPU (ImageWriter, MediaImage, ByteBuffer).

Nếu bộ mã hoá video quảng cáo hỗ trợ COLOR_Format32bitABGR2101010, thì bộ mã hoá đó:

[C-4-1] PHẢI hỗ trợ định dạng RGBA_1010102 cho nền tảng đầu vào và đầu vào có thể ghi bằng CPU (ImageWriter, ByteBuffer). Lưu ý: Bộ mã hoá KHÔNG cần chuyển đổi giữa các đường cong chuyển đổi.

Yêu cầu đối với tính năng quay video HDR

Đối với tất cả bộ mã hoá video hỗ trợ hồ sơ HDR, cách triển khai thiết bị:

[C-5-1] KHÔNG ĐƯỢC giả định rằng siêu dữ liệu HDR là chính xác. Ví dụ: khung được mã hoá có thể có các pixel vượt quá mức độ chói đỉnh hoặc biểu đồ có thể không đại diện cho khung.
NÊN tổng hợp siêu dữ liệu động HDR để tạo siêu dữ liệu tĩnh HDR thích hợp cho các luồng đã mã hoá và xuất siêu dữ liệu đó vào cuối mỗi phiên mã hoá.

Nếu việc triển khai thiết bị hỗ trợ tính năng chụp HDR bằng API CamcorderProfile, thì các API đó:

[C-6-1] PHẢI hỗ trợ tính năng chụp HDR thông qua API Camera2.
[C-6-2] PHẢI hỗ trợ ít nhất một bộ mã hoá video tăng tốc phần cứng cho mỗi công nghệ HDR được hỗ trợ.
[C-6-3] PHẢI hỗ trợ (tối thiểu) tính năng quay HLG.
[C-6-4] PHẢI hỗ trợ ghi siêu dữ liệu HDR (nếu áp dụng cho công nghệ HDR) vào tệp video đã quay. Đối với AV1, HEVC và DolbyVision, điều này có nghĩa là đưa siêu dữ liệu vào luồng bit đã mã hoá.
[C-6-5] PHẢI hỗ trợ P010 và COLOR_FormatYUVP010.
[C-6-6] PHẢI hỗ trợ ánh xạ tông màu HDR sang SDR trong bộ giải mã tăng tốc phần cứng mặc định cho hồ sơ đã chụp. Nói cách khác, nếu một thiết bị có thể quay video HDR10+ HEVC, thì bộ giải mã HEVC mặc định PHẢI có thể giải mã luồng đã quay ở SDR.

Yêu cầu đối với việc chỉnh sửa video HDR

Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá video hỗ trợ chỉnh sửa HDR, thì các bộ mã hoá đó:

NÊN sử dụng độ trễ tối thiểu để tạo siêu dữ liệu HDR khi không có siêu dữ liệu, đồng thời NÊN xử lý linh hoạt các trường hợp siêu dữ liệu xuất hiện ở một số khung hình và không xuất hiện ở một số khung hình khác. Siêu dữ liệu này PHẢI chính xác (ví dụ: đại diện cho độ chói cực đại thực tế và biểu đồ của khung hình).

Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá và giải mã hỗ trợ FEATURE_HdrEditing, thì các bộ mã hoá và giải mã đó:

[C-7-1] PHẢI hỗ trợ ít nhất một hồ sơ HDR.
[C-7-2] PHẢI hỗ trợ FEATURE_HdrEditing cho tất cả hồ sơ HDR do bộ mã hoá và giải mã đó quảng cáo. Nói cách khác, bộ mã hoá và giải mã PHẢI hỗ trợ việc tạo siêu dữ liệu HDR khi không có siêu dữ liệu HDR cho tất cả hồ sơ HDR được hỗ trợ.
[C-7-3] PHẢI hỗ trợ các định dạng đầu vào bộ mã hoá video sau đây để bảo toàn hoàn toàn tín hiệu được giải mã HDR:
- RGBA_1010102 (đã có trong đường cong chuyển mục tiêu) cho cả bề mặt đầu vào và ByteBuffer và PHẢI quảng cáo tính năng hỗ trợ COLOR_Format32bitABGR2101010.

Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá và giải mã hỗ trợ FEATURE_HdrEditing, thì thiết bị:

[C-7-4] PHẢI quảng cáo tính năng hỗ trợ tiện ích OpenGL EXT_YUV_target.

6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển

6.1. Công cụ dành cho nhà phát triển

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ Công cụ dành cho nhà phát triển Android được cung cấp trong SDK Android.
Cầu gỡ lỗi Android (adb)
- [C-0-2] PHẢI hỗ trợ adb như được ghi nhận trong SDK Android và các lệnh shell được cung cấp trong AOSP. Nhà phát triển ứng dụng có thể sử dụng các lệnh này, bao gồm cả dumpsys cmd stats
- [C-0-11] PHẢI hỗ trợ lệnh shell cmd testharness. Việc nâng cấp quá trình triển khai thiết bị từ một phiên bản Android cũ hơn mà không có khối dữ liệu ổn định CÓ THỂ được miễn C-0-11.
- [C-0-3] KHÔNG ĐƯỢC thay đổi định dạng hoặc nội dung của các sự kiện hệ thống thiết bị (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) được ghi lại thông qua lệnh dumpsys.
- [C-0-10] PHẢI ghi lại, không được bỏ qua và cho phép truy cập vào các sự kiện sau đây cho lệnh shell cmd stats và lớp API Hệ thống StatsManager.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] PHẢI có trình nền adb phía thiết bị không hoạt động theo mặc định và PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
- [C-0-5] PHẢI hỗ trợ adb bảo mật. Android hỗ trợ adb bảo mật. adb bảo mật cho phép adb trên các máy chủ đã xác thực đã biết.
- [C-0-6] PHẢI cung cấp cơ chế cho phép kết nối adb từ máy chủ. Cụ thể:
Nếu các phương thức triển khai thiết bị không có cổng USB hỗ trợ chế độ thiết bị ngoại vi, thì các phương thức đó:
- [C-3-1] PHẢI triển khai adb thông qua mạng cục bộ (chẳng hạn như Ethernet hoặc Wi-Fi).
- [C-3-2] PHẢI cung cấp trình điều khiển cho Windows 7, 8 và 10, cho phép nhà phát triển kết nối với thiết bị bằng giao thức adb.
Nếu việc triển khai thiết bị hỗ trợ kết nối adb với máy chủ qua Wi-Fi hoặc Ethernet, thì các thiết bị đó:
- [C-4-1] PHẢI có phương thức AdbManager#isAdbWifiSupported() trả về true.
Nếu việc triển khai thiết bị hỗ trợ kết nối adb với máy chủ qua Wi-Fi hoặc Ethernet và có ít nhất một máy ảnh, thì các thiết bị đó:
- [C-5-1] PHẢI có phương thức AdbManager#isAdbWifiQrSupported() trả về true.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] PHẢI hỗ trợ tất cả tính năng ddms như được ghi nhận trong SDK Android. Vì ddms sử dụng adb, nên tính năng hỗ trợ ddms theo mặc định KHÔNG được kích hoạt, nhưng KHÔNG PHẢI được hỗ trợ bất cứ khi nào người dùng đã kích hoạt Cầu gỡ lỗi Android, như trên.
SysTrace
- [C-0-9] PHẢI hỗ trợ công cụ systrace như được ghi nhận trong SDK Android. Theo mặc định, Systrace phải ở trạng thái không hoạt động và PHẢI có một cơ chế mà người dùng có thể truy cập để bật Systrace.
Perfetto
- [C-SR-1] Bạn NÊN hiển thị tệp nhị phân /system/bin/perfetto cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto.
- [C-SR-2] Bạn NÊN chấp nhận tệp nhị phân perfetto làm dữ liệu đầu vào cho cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-3] Bạn NÊN ghi tệp nhị phân perfetto dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-4] Bạn NÊN cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
Trình tắt ứng dụng khi bộ nhớ thấp
- [C-0-12] PHẢI ghi một Atom LMK_KILL_OCCURRED_FIELD_NUMBER vào nhật ký statsd khi một ứng dụng bị Trình loại bỏ bộ nhớ thấp chấm dứt.
Chế độ khai thác kiểm thử Nếu hoạt động triển khai thiết bị hỗ trợ lệnh shell cmd testharness và chạy cmd testharness enable, thì các hoạt động đó:
- [C-2-1] PHẢI trả về true cho ActivityManager.isRunningInUserTestHarness()
- [C-2-2] PHẢI triển khai Chế độ khai thác kiểm thử như mô tả trong tài liệu về Chế độ khai thác kiểm thử.
Thông tin công việc của GPU

Triển khai trên thiết bị:
- [C-0-13] PHẢI triển khai lệnh shell dumpsys gpu --gpuwork để hiển thị dữ liệu công việc GPU tổng hợp do điểm theo dõi hạt nhân power/gpu_work_period trả về hoặc không hiển thị dữ liệu nếu điểm theo dõi không được hỗ trợ. Cách triển khai AOSP là frameworks/native/services/gpuservice/gpuwork/.

Nếu việc triển khai thiết bị báo cáo việc hỗ trợ Vulkan 1.0 trở lên thông qua cờ tính năng android.hardware.vulkan.version, thì các thiết bị đó:

[C-1-1] PHẢI cung cấp một chức năng để nhà phát triển ứng dụng bật/tắt các lớp gỡ lỗi GPU.
[C-1-2] PHẢI, khi bật các lớp gỡ lỗi GPU, hãy liệt kê các lớp trong thư viện do các công cụ bên ngoài cung cấp (tức là không phải là một phần của nền tảng hoặc gói ứng dụng) có trong thư mục cơ sở của các ứng dụng có thể gỡ lỗi để hỗ trợ các phương thức API vkEnumerateInstanceLayerProperties() và vkCreateInstance().

6.2. Tuỳ chọn cho nhà phát triển

Android hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng.

Việc triển khai thiết bị PHẢI mang lại trải nghiệm nhất quán cho Tuỳ chọn cho nhà phát triển, cụ thể:

[C-0-1] PHẢI tuân thủ ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiển thị các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Theo mặc định, việc triển khai Android thượng nguồn sẽ ẩn trình đơn Tuỳ chọn cho nhà phát triển và cho phép người dùng chạy Tuỳ chọn cho nhà phát triển sau khi nhấn 7 lần vào mục trình đơn Cài đặt > Giới thiệu về thiết bị > Số bản dựng.
[C-0-2] PHẢI ẩn Tuỳ chọn cho nhà phát triển theo mặc định.
[C-0-3] PHẢI cung cấp một cơ chế rõ ràng để không ưu tiên một ứng dụng bên thứ ba so với ứng dụng khác nhằm bật Tuỳ chọn cho nhà phát triển. PHẢI cung cấp tài liệu hoặc trang web công khai mô tả cách bật Tuỳ chọn cho nhà phát triển. Tài liệu hoặc trang web này PHẢI có thể liên kết từ tài liệu SDK Android.
NÊN có thông báo trực quan liên tục cho người dùng khi tuỳ chọn cho nhà phát triển được bật và sự an toàn của người dùng là mối lo ngại.
CÓ THỂ tạm thời hạn chế quyền truy cập vào trình đơn Tuỳ chọn cho nhà phát triển bằng cách ẩn hoặc tắt trình đơn để tránh gây mất tập trung trong các trường hợp cần quan tâm đến sự an toàn của người dùng.

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

Nếu một thiết bị có một thành phần phần cứng cụ thể có API tương ứng cho nhà phát triển bên thứ ba:

[C-0-1] Việc triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu SDK Android.

Nếu một API trong SDK tương tác với một thành phần phần cứng được nêu là không bắt buộc và quá trình triển khai thiết bị không có thành phần đó:

[C-0-2] Vẫn PHẢI trình bày các định nghĩa lớp hoàn chỉnh (như được SDK ghi lại) cho các API thành phần.
[C-0-3] Hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo một cách hợp lý.
[C-0-4] Phương thức API PHẢI trả về giá trị rỗng khi tài liệu SDK cho phép.
[C-0-5] Phương thức API PHẢI trả về các phương thức triển khai không hoạt động của các lớp mà tài liệu SDK không cho phép giá trị rỗng.
[C-0-6] Phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được tài liệu SDK ghi lại.
[C-0-7] Việc triển khai thiết bị PHẢI báo cáo nhất quán thông tin cấu hình phần cứng chính xác thông qua các phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager cho cùng một vân tay bản dựng.

Một ví dụ điển hình về trường hợp áp dụng các yêu cầu này là API điện thoại: Ngay cả trên các thiết bị không phải điện thoại, các API này phải được triển khai dưới dạng không hoạt động hợp lý.

7.1. Màn hình và đồ hoạ

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 giao diện người dùng cho phù hợp với thiết bị để đảm bảo rằng các ứng dụng bên thứ ba chạy tốt trên ~~nhiều cấu hình phần cứng.~~ nhiều màn hình và cấu hình phần cứng. Màn hình tương thích với Android là màn hình hiển thị triển khai tất cả các hành vi và API được mô tả trong phần Nhà phát triển Android – Tổng quan về khả năng tương thích của màn hình, phần này (7.1) và các tiểu mục của phần này, cũng như mọi hành vi cụ thể theo loại thiết bị khác được ghi nhận trong phần 2 của CDD này. Trên(các) màn hình tương thích với Android mà tất cả ứng dụng tương thích với Android của bên thứ ba có thể chạy, việc triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

Bắt đầu yêu cầu mới

Triển khai trên thiết bị:

[C-0-1] Theo mặc định, PHẢI chỉ hiển thị các ứng dụng bên thứ ba trên màn hình tương thích với Android.

Kết thúc các yêu cầu mới

Các đơn vị được tham chiếu theo yêu cầu trong phần này được xác định như sau:

Kích thước đường chéo thực tế. 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 trên màn hình.
~~số điểm trên mỗi inch (dpi)~~mật độ. Số pixel trong một khoảng không gian tuyến tính theo chiều ngang hoặc chiều dọc là 1”, được biểu thị bằng pixel trên mỗi inch (ppi hoặc dpi). Khi liệt kê các giá trị ~~dpi~~ ppi và dpi, cả dpi theo chiều ngang và chiều dọc đều phải nằm trong phạm vi đã liệt kê.
tỷ lệ khung hình. Tỷ lệ 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 480x854 pixel sẽ là 854/480 = 1, 779, hay gần bằng "16:9".
pixel không phụ thuộc vào mật độ (dp). ~~Đơn vị pixel ảo~~ A được chuẩn hoá thành ~~mật độ màn hình 160 dpi~~ mật độ màn hình 160. Đối với một số mật độ d và số pixel p, số pixel không phụ thuộc vào mật độ dp được tính theo công thức: ~~pixels = dps * (density/160)~~ dp = (160 / d) * p .

7.1.1. Cấu hình màn hình

7.1.1.1. Kích thước và hình dạng màn hình

Khung giao diện người dùng Android hỗ trợ nhiều kích thước bố cục màn hình logic khác nhau và cho phép các ứng dụng truy vấn kích thước bố cục màn hình của cấu hình hiện tại thông qua Configuration.screenLayout với SCREENLAYOUT_SIZE_MASK và Configuration.smallestScreenWidthDp.

Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo kích thước bố cục chính xác cho Configuration.screenLayout như được xác định trong tài liệu SDK Android. Cụ thể, việc triển khai thiết bị PHẢI báo cáo kích thước màn hình pixel (dp) không phụ thuộc vào mật độ logic chính xác như bên dưới:
- Các thiết bị có Configuration.uiMode được đặt thành bất kỳ giá trị nào khác ngoài UI_MODE_TYPE_WATCH và báo cáo kích thước small cho Configuration.screenLayout, PHẢI có kích thước tối thiểu là 426 dp x 320 dp.
- Các thiết bị báo cáo kích thước normal cho Configuration.screenLayout, PHẢI có kích thước tối thiểu là 480 dp x 320 dp.
- Các thiết bị báo cáo kích thước large cho Configuration.screenLayout, PHẢI có kích thước tối thiểu là 640 dp x 480 dp.
- Các thiết bị báo cáo kích thước xlarge cho Configuration.screenLayout, PHẢI có kích thước tối thiểu là 960 dp x 720 dp.
[C-0-2] PHẢI tuân thủ đúng thông tin hỗ trợ kích thước màn hình đã nêu của ứng dụng thông qua thuộc tính <supports-screens> trong AndroidManifest.xml, như mô tả trong tài liệu SDK Android.
CÓ THỂ có(các) màn hình tương thích với Android với các góc bo tròn.

Nếu việc triển khai thiết bị hỗ trợ màn hình có thể sử dụng cấu hình kích thước UI_MODE_TYPE_NORMAL và ~~bao gồm màn hình tương thích với Android~~ sử dụng màn hình thực có góc bo tròn để hiển thị các màn hình này, thì:

[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 bo tròn nhỏ hơn hoặc bằng 38 dp.
- Khi ~~hộp 15~~18 dp theo 1518 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 sẽ hiển thị trên màn hình.
NÊN bao gồm khả năng hỗ trợ người dùng để chuyển sang chế độ hiển thị có góc vuông.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị chỉ có thể thực hiện cấu hình bàn phím NO_KEYS và dự định báo cáo hỗ trợ cho cấu hình chế độ giao diện người dùng UI_MODE_TYPE_NORMAL, thì các thiết bị đó:

[C-4-1] PHẢI có kích thước bố cục, không bao gồm bất kỳ phần cắt màn hình nào, tối thiểu là 596 dp x 384 dp trở lên.

Kết thúc các yêu cầu mới

Nếu việc triển khai thiết bị bao gồm (các) màn hình tương thích với Android có thể gập lại hoặc có bản lề gập giữa nhiều bảng hiển thị và cung cấp (các) màn hình đó để hiển thị ứng dụng của bên thứ ba, thì (các) màn hình đó:

[C-2-1] PHẢI triển khai phiên bản ổn định mới nhất hiện có của API tiện ích hoặc phiên bản ổn định của API phụ xe để thư viện Window Manager Jetpack sử dụng.

Nếu việc triển khai thiết bị bao gồm(các) màn hình tương thích với Android có thể gập lại hoặc có bản lề gập giữa nhiều bảng hiển thị và nếu bản lề hoặc đường gập cắt ngang cửa sổ ứng dụng toàn màn hình, thì các màn hình đó:

[C-3-1] PHẢI báo cáo vị trí, giới hạn và trạng thái của bản lề hoặc màn hình gập thông qua các tiện ích hoặc API sidecar cho ứng dụng.

Để biết thông tin chi tiết về cách triển khai chính xác API phụ hoặc API tiện ích, hãy tham khảo tài liệu công khai về Trình quản lý cửa sổ Jetpack.

Bắt đầu yêu cầu mới

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 với 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 hiển thị tương thích với Android và cung cấp các khu vực hiển thị đó cho ứng dụng, thì các khu vực hiển thị đó:

[C-4-1] PHẢI triển khai đúng phiên bản của cấp độ API Tiện ích Trình quản lý cửa sổ như mô tả trong Tiện ích Trình quản lý cửa sổ.

Kết thúc các yêu cầu mới

7.1.1.2. Tỷ lệ khung hình màn hình

Mặc dù không có quy định hạn chế về tỷ lệ khung hình của màn hình thực cho (các) màn hình tương thích với Android, nhưng tỷ lệ khung hình của màn hình logic nơi các ứng dụng bên thứ ba được hiển thị (có thể được lấy từ các giá trị chiều cao và chiều rộng được báo cáo thông qua API view.Display và API Cấu hình) PHẢI đáp ứng các yêu cầu sau:

[C-0-1] Việc triển khai thiết bị với Configuration.uiMode được đặt thành UI_MODE_TYPE_NORMAL PHẢI có giá trị tỷ lệ khung hình nhỏ hơn hoặc bằng 1,86 (khoảng 16:9), trừ phi ứng dụng đáp ứng một trong các điều kiện sau:

Ứng dụng đã khai báo rằng ứng dụng hỗ trợ tỷ lệ khung hình màn hình lớn hơn thông qua giá trị siêu dữ liệu android.max_aspect.

Ứng dụng khai báo rằng có thể đổi kích thước thông qua thuộc tính android:resizeableActivity.

Ứng dụng nhắm đến API cấp 24 trở lên và không khai báo android:maxAspectRatio sẽ hạn chế tỷ lệ khung hình được phép.

[C-0-3] Việc triển khai thiết bị với Configuration.uiMode được đặt thành UI_MODE_TYPE_WATCH PHẢI có giá trị tỷ lệ khung hình được đặt thành 1.0 (1:1).

7.1.1.3. Mật độ màn hình

Khung giao diện người dùng Android xác định một tập hợp mật độ logic tiêu chuẩn để giúp nhà phát triển ứng dụng nhắm đến tài nguyên ứng dụng.

Triển khai trên thiết bị:

[C-0-1] ~~Theo mặc định, việc triển khai thiết bị~~ PHẢI báo cáo ~~chỉ~~ một trong các mật độ khung Android được liệt kê trên DisplayMetrics thông qua DENSITY_DEVICE_STABLE API và giá trị này phải là giá trị tĩnh cho mỗi màn hình thực. ~~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ột ~~mật độ tuỳ ý~~ DisplayMetrics.density khác theo các thay đổi về cấu hình màn hình do người dùng thực hiện (ví dụ: kích thước màn hình) được đặt sau khi khởi động ban đầu.

Việc triển khai thiết bị PHẢI xác định mật độ khung Android tiêu chuẩn gần nhất về mặt số học với mật độ thực tế của màn hình, trừ phi mật độ logic đó đẩy kích thước màn hình được báo cáo xuống dưới mức tối thiểu được hỗ trợ. Nếu mật độ khung Android chuẩn gần nhất về mặt số học với mật độ thực tế 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), thì việc triển khai thiết bị PHẢI báo cáo mật độ khung Android chuẩn thấp nhất tiếp theo.

Bắt đầu yêu cầu mới

NÊN xác định mật độ khung Android tiêu chuẩn gần nhất về mặt số học với mật độ vật lý của màn hình hoặc một giá trị sẽ liên kết với cùng một phép đo trường nhìn góc tương đương của thiết bị cầm tay.

Kết thúc các yêu cầu mới

Nếu quá trình 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ì:

[C-1-1] ~~Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ~~ KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ màn hình lớn hơn 1,5 lần DENSITY_DEVICE_STABLE ~~mật độ gốc~~ hoặc tạo kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320dp (tương đương với bộ hạn định tài nguyên sw320dp), tuỳ theo điều kiện nào đến trước.
[C-1-2] ~~Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ~~ KHÔNG ĐƯỢC điều chỉnh tỷ lệ màn hình nhỏ hơn 0,85 lần DENSITY_DEVICE_STABLE ~~mật độ gốc~~.
Để đảm bảo khả năng hữu dụng và kích thước phông chữ nhất quán, bạn NÊN cung cấp tỷ lệ sau đây cho các tuỳ chọn Màn hình gốc (trong khi tuân thủ các giới hạn được chỉ định ở trên)
- Nhỏ: 0,85x
- Mặc định: 1x (Tỷ lệ hiển thị gốc)
- Lớn: 1,15x
- Lớn hơn: 1,3 lần
- Lớn nhất 1,45x

7.1.2. Chỉ số về Mạng Hiển thị

Nếu việc triển khai thiết bị bao gồm(các) màn hình tương thích với Android hoặc đầu ra video đến(các) màn hình tương thích với Android, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo giá trị chính xác cho tất cả chỉ số màn hình tương thích với Android được xác định trong API android.util.DisplayMetrics.

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

[C-2-1] PHẢI báo cáo chính xác các giá trị của màn hình tương thích với Android như được xác định trong API android.util.DisplayMetrics cho view.Display mặc định được mô phỏng.

7.1.3. Hướng màn hình

Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo hướng màn hình mà ứng dụng hỗ trợ (android.hardware.screen.portrait và/hoặc android.hardware.screen.landscape) và PHẢI báo cáo ít nhất một hướng được hỗ trợ. Ví dụ: một thiết bị có màn hình ngang cố định, chẳng hạn như TV hoặc máy tính xách tay, CHỈ NÊN báo cáo android.hardware.screen.landscape.
[C-0-2] PHẢI báo cáo đúng giá trị cho hướng hiện tại của thiết bị, bất cứ khi nào được truy vấn thông qua android.content.res.Configuration.orientation, android.view.Display.getOrientation() hoặc các API khác.

Nếu cách triển khai thiết bị hỗ trợ cả hai hướng màn hình, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ hướng động của các ứng dụng theo hướng màn hình dọc hoặc ngang. Tức là thiết bị phải tuân theo yêu cầu của ứng dụng về hướng màn hình cụ thể.
[C-1-2] KHÔNG ĐƯỢC thay đổi kích thước hoặc mật độ màn hình được báo cáo khi thay đổi hướng.
CÓ THỂ chọn hướng dọc hoặc ngang làm hướng mặc định.

7.1.4. Tăng tốc đồ hoạ 2D và 3D

7.1.4.1 OpenGL ES

Triển khai trên thiết bị:

[C-0-1] PHẢI xác định chính xác các phiên bản OpenGL ES được hỗ trợ (1.1, 2.0, 3.0, 3.1, 3.2) thông qua các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) và các API gốc.
[C-0-2] PHẢI hỗ trợ tất cả API được quản lý và API gốc tương ứng cho mọi phiên bản OpenGL ES mà họ xác định là hỗ trợ.

Nếu quá trình triển khai thiết bị bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ cả OpenGL ES 1.1 và 2.0, như được nêu và nêu chi tiết trong tài liệu về SDK Android.
[C-SR-1] NÊN hỗ trợ OpenGL ES 3.1.
PHẢI hỗ trợ OpenGL ES 3.2.

Các thử nghiệm dEQP OpenGL ES được phân chia thành một số danh sách thử nghiệm, mỗi danh sách có một ngày/số phiên bản liên kết. Các tệp này nằm trong cây nguồn Android tại external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. Thiết bị hỗ trợ OpenGL ES ở cấp độ tự báo cáo cho biết rằng thiết bị đó có thể vượt qua các bài kiểm thử dEQP trong tất cả danh sách kiểm thử từ cấp độ này trở xuống.

Nếu việc triển khai thiết bị hỗ trợ bất kỳ phiên bản OpenGL ES nào, thì các phiên bản đó:

[C-2-1] PHẢI báo cáo thông qua API do OpenGL ES quản lý và API gốc về mọi tiện ích OpenGL ES khác mà họ đã triển khai, và ngược lại, KHÔNG được báo cáo chuỗi tiện ích mà họ không hỗ trợ.
[C-2-2] PHẢI hỗ trợ các tiện ích EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable và EGL_ANDROID_GLES_layers.
[C-2-3] PHẢI báo cáo phiên bản tối đa của các thử nghiệm dEQP OpenGL ES được hỗ trợ thông qua cờ tính năng android.software.opengles.deqp.level.
[C-2-4] PHẢI hỗ trợ ít nhất phiên bản 132383489 (kể từ ngày 1 tháng 3 năm 2020) như đã báo cáo trong cờ tính năng android.software.opengles.deqp.level.
[C-2-5] PHẢI vượt qua tất cả các bài kiểm thử dEQP OpenGL ES trong danh sách kiểm thử giữa phiên bản 132383489 và phiên bản được chỉ định trong cờ tính năng android.software.opengles.deqp.level, cho mỗi phiên bản OpenGL ES được hỗ trợ.
[C-SR-2] NÊN hỗ trợ các tiện ích EGL_KHR_partial_update và OES_EGL_image_external.
PHẢI báo cáo chính xác thông qua phương thức getString(), mọi định dạng nén hoạ tiết mà chúng hỗ trợ, thường là dành riêng cho nhà cung cấp.
PHẢI hỗ trợ các tiện ích EGL_IMG_context_priority và EGL_EXT_protected_content.

Nếu việc triển khai thiết bị khai báo hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2, thì các thiết bị đó:

[C-3-1] PHẢI xuất các ký hiệu hàm tương ứng cho các phiên bản này ngoài các ký hiệu hàm OpenGL ES 2.0 trong thư viện libGLESv2.so.
[C-SR-3] Bạn NÊN hỗ trợ tiện ích OES_EGL_image_external_essl3.

Nếu các phương thức triển khai thiết bị hỗ trợ OpenGL ES 3.2, thì các phương thức đó:

[C-4-1] PHẢI hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES.

Nếu quá trình triển khai thiết bị hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES, thì các thiết bị đó:

[C-5-1] PHẢI xác định tính năng hỗ trợ thông qua cờ tính năng android.hardware.opengles.aep.

Nếu các hoạt động triển khai thiết bị hiển thị tính năng hỗ trợ cho tiện ích EGL_KHR_mutable_render_buffer, thì các hoạt động đó:

[C-6-1] CŨNG PHẢI hỗ trợ tiện ích EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android hỗ trợ Vulkan, một API nhiều nền tảng, mức hao tổn thấp dành cho đồ hoạ 3D hiệu suất cao.

Nếu các phương thức triển khai thiết bị hỗ trợ OpenGL ES 3.1, thì các phương thức đó:

[C-SR-1] Bạn NÊN hỗ trợ Vulkan 1.3.
[C-4-1] KHÔNG ĐƯỢC hỗ trợ phiên bản biến thể Vulkan (tức là phần biến thể của phiên bản lõi Vulkan PHẢI bằng 0).

Nếu quá trình triển khai thiết bị bao gồm màn hình hoặc đầu ra video, thì các thiết bị đó:

[C-SR-2] NÊN hỗ trợ Vulkan 1.3.

Các kiểm thử dEQP Vulkan được phân chia thành một số danh sách kiểm thử, mỗi danh sách có một ngày/phiên bản liên kết. Các tệp này nằm trong cây nguồn Android tại external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. Một thiết bị hỗ trợ Vulkan ở cấp tự báo cho biết rằng thiết bị đó có thể vượt qua các bài kiểm thử dEQP trong tất cả danh sách kiểm thử từ cấp này trở xuống.

Nếu việc triển khai thiết bị bao gồm hỗ trợ Vulkan ~~1.0 trở lên~~, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo giá trị số nguyên chính xác bằng cờ tính năng android.hardware.vulkan.level và android.hardware.vulkan.version.
[C-1-2] PHẢI liệt kê ít nhất một VkPhysicalDevice cho API gốc Vulkan vkEnumeratePhysicalDevices().
[C-1-3] PHẢI triển khai đầy đủ các API ~~Vulkan 1.0~~ Vulkan 1.1 cho mỗi VkPhysicalDevice được liệt kê.
[C-1-4] PHẢI liệt kê các lớp, có trong thư viện gốc có tên là libVkLayer*.so trong thư mục thư viện gốc của gói ứng dụng, thông qua API gốc Vulkan vkEnumerateInstanceLayerProperties() và vkEnumerateDeviceLayerProperties().
[C-1-5] KHÔNG ĐƯỢC liệt kê các lớp do thư viện cung cấp bên ngoài gói ứng dụng hoặc cung cấp các cách khác để theo dõi hoặc chặn API Vulkan, trừ phi ứng dụng có thuộc tính android:debuggable được đặt thành true hoặc siêu dữ liệu com.android.graphics.injectLayers.enable được đặt thành true .
[C-1-6] PHẢI báo cáo tất cả chuỗi mở rộng mà chúng hỗ trợ thông qua API gốc Vulkan và ngược lại , KHÔNG ĐƯỢC báo cáo chuỗi mở rộng mà chúng không hỗ trợ chính xác.
[C-1-7] PHẢI hỗ trợ các tiện ích VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain và VK_KHR_incremental_present.
[C-1-8] PHẢI báo cáo phiên bản tối đa của Vulkan dEQP Tests được hỗ trợ thông qua cờ tính năng android.software.vulkan.deqp.level.
[C-1-9] PHẢI hỗ trợ ít nhất phiên bản 132317953 (kể từ ngày 1 tháng 3 năm 2019) như đã báo cáo trong cờ tính năng android.software.vulkan.deqp.level.
[C-1-10] PHẢI vượt qua tất cả các bài kiểm thử Vulkan dEQP trong danh sách kiểm thử giữa phiên bản 132317953 và phiên bản được chỉ định trong cờ tính năng android.software.vulkan.deqp.level.
[C-1-11] KHÔNG ĐƯỢC liệt kê tính năng hỗ trợ cho các tiện ích VK_KHR_video_queue, VK_KHR_video_decode_queue hoặc VK_KHR_video_encode_queue.
[C-SR-3] NÊN hỗ trợ các tiện ích VK_KHR_driver_properties và VK_GOOGLE_display_timing.

~~PHẢI hỗ trợ VkPhysicalDeviceProtectedMemoryFeatures và VK_EXT_global_priority.~~

[C-1-12] KHÔNG ĐƯỢC liệt kê tính năng hỗ trợ cho tiện ích VK_KHR_performance_query.

~~[C-1-13] PHẢI đáp ứng các yêu cầu do Hồ sơ cơ sở Android 2021 chỉ định.~~

[C-SR-4] NÊN đáp ứng các yêu cầu do Hồ sơ cơ sở Android 2022 chỉ định.

Bắt đầu yêu cầu mới

[C-SR-5] Bạn NÊN hỗ trợ VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory và VK_EXT_global_priority.
[C-SR-6] Bạn NÊN sử dụng SkiaVk với HWUI.

Kết thúc các yêu cầu mới

Nếu không hỗ trợ Vulkan 1.0, các phương thức triển khai thiết bị sẽ:

[C-2-1] KHÔNG ĐƯỢC khai báo bất kỳ cờ tính năng nào của Vulkan (ví dụ: android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] KHÔNG ĐƯỢC liệt kê bất kỳ VkPhysicalDevice nào cho API gốc Vulkan vkEnumeratePhysicalDevices().

Nếu quá trình triển khai thiết bị bao gồm tính năng hỗ trợ Vulkan 1.1 và khai báo bất kỳ cờ tính năng Vulkan nào được mô tả tại đây , thì các thiết bị đó:

[C-3-1] PHẢI hiển thị tính năng hỗ trợ cho loại cờ và tay điều khiển bên ngoài SYNC_FD cũng như tiện ích VK_ANDROID_external_memory_android_hardware_buffer.

Bắt đầu yêu cầu mới

[C-SR-7] Bạn NÊN cung cấp tiện ích VK_KHR_external_fence_fd cho các ứng dụng bên thứ ba và cho phép ứng dụng xuất tải trọng hàng rào sang và nhập tải trọng hàng rào từ các chỉ số mô tả tệp POSIX như mô tả tại đây.

Kết thúc các yêu cầu mới

7.1.4.3 RenderScript

[C-0-1] Việc triển khai thiết bị PHẢI hỗ trợ Android RenderScript, như được nêu chi tiết trong tài liệu SDK Android.

7.1.4.4 Tăng tốc đồ hoạ 2D

Android có một cơ chế để các ứng dụng khai báo rằng chúng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp Ứng dụng, Hoạt động, Cửa sổ hoặc Khung hiển thị thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp.

Triển khai trên thiết bị:

[C-0-1] PHẢI bật tính năng tăng tốc phần cứng theo mặc định và PHẢI tắt tính năng tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách đặt android:hardwareAccelerated="false" hoặc tắt tính năng tăng tốc phần cứng trực tiếp thông qua API Khung hiển thị Android.
[C-0-2] PHẢI thể hiện hành vi nhất quán với tài liệu SDK Android về tính năng tăng tốc phần cứng.

Android bao gồm một đối tượng TextureView cho phép nhà phát triển trực tiếp tích hợp các kết cấu OpenGL ES được tăng tốc phần cứng làm mục tiêu kết xuất trong hệ phân cấp giao diện người dùng.

Triển khai trên thiết bị:

[C-0-3] PHẢI hỗ trợ API TextureView và PHẢI thể hiện hành vi nhất quán với cách triển khai Android ngược dòng.

7.1.4.5 Màn hình gam màu rộng

Nếu các hoạt động triển khai thiết bị tuyên bố hỗ trợ màn hình gam màu rộng thông qua Configuration.isScreenWideColorGamut() , thì các hoạt động đó:

[C-1-1] PHẢI có màn hình được hiệu chỉnh màu.
[C-1-2] PHẢI có màn hình có gam màu bao phủ toàn bộ gam màu sRGB trong không gian xyY CIE 1931.
[C-1-3] PHẢI có màn hình có gam màu có diện tích ít nhất là 90% DCI-P3 trong không gian xyY CIE 1931.
[C-1-4] PHẢI hỗ trợ OpenGL ES 3.1 hoặc 3.2 và báo cáo đúng cách.
[C-1-5] PHẢI quảng cáo tính năng hỗ trợ tiện ích EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear và EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] Bạn NÊN hỗ trợ GL_EXT_sRGB.

Ngược lại, nếu việc triển khai thiết bị không hỗ trợ màn hình gam màu rộng, thì các thiết bị đó:

[C-2-1] PHẢI bao phủ 100% trở lên của sRGB trong không gian xyY CIE 1931, mặc dù gamut màu màn hình không được xác định.

7.1.5. Chế độ tương thích với ứng dụng cũ

Android chỉ định một "chế độ tương thích" trong đó khung hoạt động ở chế độ tương đương với kích thước màn hình "bình thường" (chiều rộng 320 dp) để mang lại lợi ích cho các ứng dụng cũ không được phát triển cho các phiên bản Android cũ trước khi có tính năng độc lập với kích thước màn hình.

7.1.6. Công nghệ màn hình

Nền tảng Android bao gồm các API cho phép ứng dụng kết xuất đồ hoạ đa dạng thức cho màn hình tương thích với Android. Thiết bị PHẢI hỗ trợ tất cả các API này theo định nghĩa của SDK Android, trừ phi được cho phép cụ thể trong tài liệu này.

Tất cả màn hình tương thích với Android của quá trình triển khai thiết bị:

[C-0-1] PHẢI có khả năng kết xuất đồ hoạ màu 16 bit.
PHẢI hỗ trợ màn hình có thể hiển thị đồ hoạ màu 24 bit.
[C-0-2] PHẢI có khả năng kết xuất ảnh động.
[C-0-3] PHẢI có tỷ lệ khung hình pixel (PAR) nằm trong khoảng từ 0,9 đến 1,15. Tức là tỷ lệ khung hình pixel PHẢI gần vuông (1, 0) với dung sai 10 đến 15%.

7.1.7. Màn hình phụ

Android hỗ trợ các màn hình phụ tương thích với Android để bật các tính năng chia sẻ nội dung nghe nhìn và API dành cho nhà phát triển để truy cập vào màn hình ngoài.

Nếu việc triển khai thiết bị hỗ trợ màn hình ngoài thông qua kết nối có dây, không dây hoặc kết nối màn hình bổ sung được nhúng, thì các thiết bị đó:

[C-1-1] PHẢI triển khai dịch vụ hệ thống và API DisplayManager như mô tả trong tài liệu SDK Android.

7.2. Thiết bị Đầu vào

Triển khai trên thiết bị:

[C-0-1] PHẢI có cơ chế nhập, chẳng hạn như màn hình cảm ứng hoặc chế độ điều hướng không chạm để di chuyển giữa các thành phần trên giao diện người dùng.

7.2.1. Bàn phím

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ các ứng dụng Trình chỉnh sửa phương thức nhập (IME) của bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI khai báo cờ tính năng android.software.input_methods.
[C-1-2] PHẢI triển khai đầy đủ Input Management Framework
[C-1-3] PHẢI có bàn phím phần mềm được cài đặt sẵn.

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC đưa bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard (QWERTY hoặc 12 phím).
NÊN bao gồm các phương thức triển khai bàn phím mềm bổ sung.
CÓ THỂ có bàn phím phần cứng.

7.2.2. Điều hướng không chạm

Android hỗ trợ bàn phím di chuyển, bi xoay và bánh xe dưới dạng cơ chế điều hướng không chạm.

Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo giá trị chính xác cho android.content.res.Configuration.navigation.

Nếu việc triển khai thiết bị thiếu tính năng điều hướng không chạm, thì thiết bị đó:

[C-1-1] PHẢI cung cấp một cơ chế giao diện người dùng thay thế hợp lý để chọn và chỉnh sửa văn bản, tương thích với Công cụ quản lý đầu vào. Việc triển khai nguồn mở Android ngược dòng bao gồm một cơ chế lựa chọn phù hợp để sử dụng với các thiết bị thiếu phương thức nhập điều hướng không chạm.

7.2.3. Phím điều hướng

Các hàm Home (Màn hình chính), Recents (Gần đây) và Back (Quay lại) thường được cung cấp thông qua hoạt động tương tác với một nút vật lý chuyên dụng hoặc một phần riêng biệt của màn hình cảm ứng. Đây là những hàm thiết yếu đối với mô hình điều hướng của Android và do đó, các phương thức triển khai thiết bị:

[C-0-1] PHẢI cung cấp cho người dùng khả năng khởi chạy các ứng dụng đã cài đặt có hoạt động với <intent-filter> được đặt bằng ACTION=MAIN và CATEGORY=LAUNCHER hoặc CATEGORY=LEANBACK_LAUNCHER để triển khai thiết bị truyền hình. Hàm Trang chủ PHẢI là cơ chế cho khả năng hỗ trợ người dùng này.
NÊN cung cấp các nút cho chức năng Gần đây và Quay lại.

Nếu bạn cung cấp các chức năng Trang chủ, Gần đây hoặc Quay lại, thì các chức năng này sẽ:

[C-1-1] PHẢI truy cập được bằng một thao tác (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi có thể truy cập được bất kỳ thao tác nào trong số này.
[C-1-2] PHẢI cho biết rõ hành động nào sẽ kích hoạt từng hàm. Ví dụ về các chỉ báo như vậy bao gồm việc in biểu tượng rõ ràng trên nút, hiển thị biểu tượng phần mềm trên phần thanh điều hướng của màn hình hoặc hướng dẫn người dùng thực hiện quy trình minh hoạ từng bước trong trải nghiệm thiết lập ngay khi xuất xưởng.

Triển khai trên thiết bị:

[C-SR-1] KHÔNG NÊN cung cấp cơ chế nhập cho hàm Trình đơn vì hàm này không còn được dùng nữa mà thay vào đó là thanh thao tác kể từ Android 4.0.
[C-SR-2] Bạn NÊN cung cấp tất cả các chức năng điều hướng có thể huỷ. "Có thể huỷ" được xác định là khả năng của người dùng để ngăn chặn việc thực thi hàm điều hướng (ví dụ: quay lại màn hình chính, quay lại, v.v.) nếu thao tác vuốt không được thả ra sau một ngưỡng nhất định.

Nếu quá trình triển khai thiết bị cung cấp chức năng Trình đơn, thì các thiết bị đó:

[C-2-1] PHẢI hiển thị nút trình đơn mục bổ sung thao tác bất cứ khi nào cửa sổ bật lên của trình đơn mục bổ sung thao tác không trống và thanh thao tác hiển thị.
[C-2-2] KHÔNG ĐƯỢC sửa đổi vị trí của cửa sổ bật lên mục bổ sung thao tác được hiển thị bằng cách chọn nút mục bổ sung trong thanh thao tác, nhưng CÓ THỂ hiển thị cửa sổ bật lên mục bổ sung thao tác ở vị trí đã sửa đổi trên màn hình khi cửa sổ này được hiển thị bằng cách chọn hàm Trình đơn.

Nếu việc triển khai thiết bị không cung cấp hàm Trình đơn, thì để tương thích ngược, các thiết bị đó sẽ:

[C-3-1] PHẢI cung cấp chức năng Trình đơn cho các ứng dụng khi targetSdkVersion nhỏ hơn 10, thông qua nút thực, khoá phần mềm hoặc cử chỉ. Bạn có thể truy cập vào hàm Trình đơn này trừ phi hàm này bị ẩn cùng với các hàm điều hướng khác.

Nếu việc triển khai thiết bị cung cấp Hàm hỗ trợ, thì các thiết bị đó:

[C-4-1] PHẢI cho phép truy cập vào hàm Hỗ trợ bằng một thao tác duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi có thể truy cập vào các phím điều hướng khác.
[C-SR-3] NÊN sử dụng thao tác nhấn và giữ trên hàm HOME làm thao tác tương tác được chỉ định này.

Nếu việc triển khai thiết bị sử dụng một phần riêng biệt của màn hình để hiển thị các phím điều hướng, thì các phím đó:

[C-5-1] Các phím điều hướng PHẢI sử dụng một phần riêng biệt của màn hình, không dành cho ứng dụng và KHÔNG ĐƯỢC che khuất hoặc can thiệp vào phần màn hình dành cho ứng dụng.
[C-5-2] PHẢI cung cấp một phần màn hình cho các ứng dụng đáp ứng các yêu cầu được xác định trong mục 7.1.1.
[C-5-3] PHẢI tuân thủ các cờ do ứng dụng đặt thông qua phương thức API View.setSystemUiVisibility() để phần riêng biệt này của màn hình (còn gọi là thanh điều hướng) được ẩn đúng cách như được ghi nhận trong SDK.

Nếu hàm điều hướng được cung cấp dưới dạng một thao tác trên màn hình, dựa trên cử chỉ:

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() CHỈ được dùng để báo cáo vùng nhận dạng cử chỉ Home (Trang chủ).
[C-6-2] Các cử chỉ bắt đầu trong một hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp thông qua View#setSystemGestureExclusionRects(), nhưng nằm ngoài WindowInsets#getMandatorySystemGestureInsets(), KHÔNG ĐƯỢC chặn cho chức năng điều hướng, miễn là hình chữ nhật loại trừ được cho phép trong giới hạn loại trừ tối đa như được chỉ định trong tài liệu về View#setSystemGestureExclusionRects().
[C-6-3] PHẢI gửi cho ứng dụng trên nền trước một sự kiện MotionEvent.ACTION_CANCEL sau khi các thao tác chạm bắt đầu bị chặn cho một cử chỉ hệ thống, nếu trước đó ứng dụng trên nền trước đã được gửi một sự kiện MotionEvent.ACTION_DOWN.
[C-6-4] PHẢI cung cấp cho người dùng khả năng chuyển sang thao tác điều hướng dựa trên nút trên màn hình (ví dụ: trong phần Cài đặt).
NÊN cung cấp chức năng Màn hình chính bằng cách vuốt lên từ cạnh dưới cùng của hướng hiện tại của màn hình.
NÊN cung cấp chức năng Gần đây bằng cách vuốt lên và giữ trước khi thả, từ cùng một khu vực với cử chỉ Trang chủ.
Các cử chỉ bắt đầu trong WindowInsets#getMandatorySystemGestureInsets() KHÔNG được ảnh hưởng bởi các hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp thông qua View#setSystemGestureExclusionRects().

Nếu một hàm điều hướng được cung cấp từ bất kỳ vị trí nào trên cạnh trái và phải của hướng hiện tại của màn hình:

[C-7-1] Hàm điều hướng PHẢI là Quay lại và được cung cấp dưới dạng thao tác vuốt từ cả cạnh trái và phải theo hướng hiện tại của màn hình.
[C-7-2] Nếu các bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh được cung cấp ở cạnh trái hoặc bên phải, thì các bảng điều khiển đó PHẢI được đặt trong 1/3 trên cùng của màn hình với một chỉ báo hình ảnh rõ ràng, liên tục cho biết việc kéo vào sẽ gọi các bảng điều khiển đã đề cập, do đó không phải là Quay lại. Người dùng CÓ THỂ định cấu hình bảng điều khiển hệ thống sao cho bảng điều khiển nằm dưới 1/3 trên cùng của(các) cạnh màn hình, nhưng bảng điều khiển hệ thống KHÔNG ĐƯỢC sử dụng lâu hơn 1/3 của(các) cạnh.
[C-7-3] Khi ứng dụng trên nền trước có cờ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT hoặc WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, thao tác vuốt từ các cạnh PHẢI hoạt động như được triển khai trong AOSP, được ghi lại trong SDK.
[C-7-4] Khi ứng dụng trên nền trước có các cờ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT hoặc WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, thì các bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh PHẢI được ẩn cho đến khi người dùng đưa vào hoặc làm sáng thanh hệ thống (còn gọi là thanh điều hướng và thanh trạng thái) như đã triển khai trong AOSP.

Nếu bạn cung cấp chức năng điều hướng quay lại và người dùng huỷ cử chỉ Quay lại, thì:

[C-8-1] PHẢI gọi OnBackInvokedCallback.onBackCancelled().
[C-8-2] KHÔNG ĐƯỢC gọi OnBackInvokedCallback.onBackInvoked().
[C-8-3] KHÔNG được gửi sự kiện KEYCODE_BACK.

Nếu bạn cung cấp hàm điều hướng quay lại nhưng ứng dụng trên nền trước KHÔNG đăng ký OnBackInvokedCallback, thì:

Hệ thống PHẢI cung cấp ảnh động cho ứng dụng trên nền trước cho biết người dùng đang quay lại, như được cung cấp trong AOSP.

Nếu việc triển khai thiết bị hỗ trợ API hệ thống setNavBarMode để cho phép mọi ứng dụng hệ thống có quyền android.permission.STATUS_BAR đặt chế độ thanh điều hướng, thì các thiết bị đó:

[C-9-1] PHẢI hỗ trợ các biểu tượng phù hợp với trẻ em hoặc thao tác điều hướng dựa trên nút như được cung cấp trong mã AOSP.

7.2.4. Nhập bằng màn hình cảm ứng

Android hỗ trợ nhiều hệ thống nhập bằng con trỏ, chẳng hạn như màn hình cảm ứng, bàn di chuột và thiết bị nhập bằng thao tác chạm giả. Quy trình triển khai thiết bị dựa trên màn hình cảm ứng được liên kết với màn hình để người dùng có cảm giác trực tiếp thao tác với các mục trên màn hình. Vì người dùng đang trực tiếp chạm vào màn hình, nên hệ thống không yêu cầu thêm bất kỳ tính năng nào để cho biết các đối tượng đang được thao tác.

Triển khai trên thiết bị:

PHẢI có một hệ thống nhập con trỏ nào đó (giống như chuột hoặc cảm ứng).
PHẢI hỗ trợ các con trỏ được theo dõi hoàn toàn độc lập.

Nếu việc triển khai thiết bị bao gồm màn hình cảm ứng (một lần chạm trở lên) trên màn hình chính tương thích với Android, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo TOUCHSCREEN_FINGER cho trường API Configuration.touchscreen.
[C-1-2] PHẢI báo cáo cờ tính năng android.hardware.touchscreen và android.hardware.faketouch.

Nếu việc triển khai thiết bị bao gồm một màn hình cảm ứng có thể theo dõi nhiều thao tác chạm trên màn hình chính tương thích với Android, thì các thiết bị đó:

[C-2-1] PHẢI báo cáo các cờ tính năng thích hợp android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand tương ứng với loại màn hình cảm ứng cụ thể trên thiết bị.

Nếu việc triển khai thiết bị dựa vào một thiết bị đầu vào bên ngoài như chuột hoặc con lăn (tức là không trực tiếp chạm vào màn hình) để nhập trên màn hình chính tương thích với Android và đáp ứng các yêu cầu về thao tác chạm giả trong mục 7.2.5, thì các thiết bị đó:

[C-3-1] KHÔNG ĐƯỢC báo cáo bất kỳ cờ tính năng nào bắt đầu bằng android.hardware.touchscreen.
[C-3-2] PHẢI chỉ báo cáo android.hardware.faketouch.
[C-3-3] PHẢI báo cáo TOUCHSCREEN_NOTOUCH cho trường API Configuration.touchscreen.

7.2.5. Nhập bằng cách chạm giả

Giao diện cảm ứng giả cung cấp hệ thống hoạt động đầu vào của người dùng gần giống với một số tính năng của màn hình cảm ứng. Ví dụ: chuột hoặc điều khiển từ xa điều khiển con trỏ trên màn hình gần giống như thao tác chạm, nhưng yêu cầu người dùng phải trỏ hoặc lấy nét trước rồi mới nhấp. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột không dây dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các hoạt động tương tác giả bằng thao tác chạm. Android bao gồm hằng số tính năng android.hardware.faketouch, tương ứng với một thiết bị đầu vào không cảm ứng (dựa trên con trỏ) có độ trung thực cao, chẳng hạn như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ phương thức nhập dựa trên cảm ứng (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng của chức năng màn hình cảm ứng.

Nếu việc triển khai thiết bị không bao gồm màn hình cảm ứng nhưng bao gồm một hệ thống nhập con trỏ khác mà họ muốn cung cấp, thì các thiết bị đó:

NÊN khai báo hỗ trợ cờ tính năng android.hardware.faketouch.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ android.hardware.faketouch, thì các hoạt động đó:

[C-1-1] PHẢI báo cáo vị trí màn hình X và Y tuyệt đối của vị trí con trỏ và hiển thị con trỏ hình ảnh trên màn hình.
[C-1-2] PHẢI báo cáo sự kiện chạm bằng mã hành động chỉ định thay đổi trạng thái xảy ra trên con trỏ di chuyển xuống hoặc lên trên màn hình.
[C-1-3] PHẢI hỗ trợ con trỏ xuống và lên trên một đối tượng trên màn hình, cho phép người dùng mô phỏng thao tác nhấn vào một đối tượng trên màn hình.
[C-1-4] PHẢI hỗ trợ con trỏ xuống, con trỏ lên, con trỏ xuống rồi con trỏ lên ở cùng một vị trí trên một đối tượng trên màn hình trong một ngưỡng thời gian, cho phép người dùng mô phỏng thao tác nhấn đúp trên một đối tượng trên màn hình.
[C-1-5] PHẢI hỗ trợ con trỏ xuống tại một điểm tuỳ ý trên màn hình, con trỏ di chuyển đến bất kỳ điểm tuỳ ý nào khác trên màn hình, theo sau là con trỏ lên, cho phép người dùng mô phỏng thao tác kéo bằng cảm ứng.
[C-1-6] PHẢI hỗ trợ con trỏ xuống, sau đó cho phép người dùng nhanh chóng di chuyển đối tượng sang một vị trí khác trên màn hình, rồi con trỏ lên trên màn hình, cho phép người dùng hất một đối tượng trên màn hình.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ android.hardware.faketouch.multitouch.distinct, thì các hoạt động đó:

[C-2-1] PHẢI khai báo hỗ trợ android.hardware.faketouch.
[C-2-2] PHẢI hỗ trợ tính năng theo dõi riêng biệt của hai hoặc nhiều đầu vào con trỏ độc lập.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ android.hardware.faketouch.multitouch.jazzhand, thì các hoạt động đó:

[C-3-1] PHẢI khai báo tính năng hỗ trợ cho android.hardware.faketouch.
[C-3-2] PHẢI hỗ trợ tính năng theo dõi riêng biệt 5 (theo dõi một bàn tay gồm các ngón tay) hoặc nhiều đầu vào con trỏ một cách hoàn toàn độc lập.

7.2.6. Hỗ trợ tay điều khiển trò chơi

7.2.6.1. Ánh xạ nút

Triển khai trên thiết bị:

[C-1-1] PHẢI có khả năng liên kết các sự kiện HID với các hằng số InputEvent tương ứng như được liệt kê trong các bảng dưới đây. Việc triển khai Android ngược dòng đáp ứng yêu cầu này.

Nếu việc triển khai thiết bị nhúng một tay điều khiển hoặc vận chuyển bằng một tay điều khiển riêng biệt trong hộp cung cấp phương tiện để nhập tất cả các sự kiện được liệt kê trong bảng bên dưới, thì các thiết bị đó:

[C-2-1] PHẢI khai báo cờ tính năng android.hardware.gamepad

Nút	Mức sử dụng HID²	Nút Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Có¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Bàn phím di chuyển lên¹ Bàn phím di chuyển xuống¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad trái1 D-pad phải¹	0x01 0x0039³	AXIS_HAT_X⁴
Nút vai trái¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Nút vai phải¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Nhấp vào cần điều khiển bên trái¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Nhấp vào cần điều khiển bên phải¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Quay lại¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Bạn phải khai báo các trường hợp sử dụng HID nêu trên trong một CA bàn phím trò chơi (0x01 0x0005).

3 Mức sử dụng này phải có Giá trị tối thiểu hợp lý là 0, Giá trị tối đa hợp lý là 7, Giá trị tối thiểu thực tế là 0, Giá trị tối đa thực tế là 315, Đơn vị là Độ và Kích thước báo cáo là 4. Giá trị logic được xác định là xoay theo chiều kim đồng hồ ra khỏi trục dọc; ví dụ: giá trị logic 0 thể hiện không xoay và nút lên đang được nhấn, trong khi giá trị logic 1 thể hiện xoay 45 độ và cả nút lên và nút trái đang được nhấn.

4 MotionEvent

Điều khiển tương tự¹	Mức sử dụng HID	Nút Android
Bộ kích hoạt bên trái	0x02 0x00C5	AXIS_LTRIGGER
Bộ kích hoạt bên phải	0x02 0x00C4	AXIS_RTRIGGER
Cần điều khiển bên trái	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Cần điều khiển bên phải	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Điều khiển từ xa

Hãy xem Mục 2.3.1 để biết các yêu cầu dành riêng cho thiết bị.

7.3. Cảm biến

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, thì quá trình triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu về SDK Android và tài liệu về nguồn mở Android về cảm biến.

Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo chính xác sự hiện diện hoặc vắng mặt của cảm biến theo lớp android.content.pm.PackageManager.
[C-0-2] PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự.
[C-0-3] PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về true hoặc false khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.).

Nếu việc triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, thì họ:

[C-1-1] PHẢI báo cáo tất cả kết quả đo lường của cảm biến bằng cách sử dụng các giá trị thích hợp của Hệ thống đo lường quốc tế (theo hệ mét) cho từng loại cảm biến như được xác định trong tài liệu về SDK Android.
[C-1-2] PHẢI báo cáo dữ liệu cảm biến có độ trễ tối đa là 100 mili giây + 2 * sample_time đối với trường hợp luồng cảm biến có độ trễ tối đa được yêu cầu là 0 ms khi bộ xử lý ứng dụng đang hoạt động. Độ trễ này không bao gồm bất kỳ độ trễ lọc nào.
[C-1-3] PHẢI báo cáo mẫu cảm biến đầu tiên trong vòng 400 mili giây + 2 * thời gian_mẫu của cảm biến đang được kích hoạt. Mẫu này có thể chấp nhận được khi có độ chính xác là 0.
[C-1-4] Đối với mọi API mà tài liệu SDK Android chỉ định là cảm biến liên tục, việc triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ, MÀ PHẢI có độ trễ dưới 3%, trong đó độ trễ được xác định là độ lệch chuẩn của chênh lệch giữa các giá trị dấu thời gian được báo cáo giữa các sự kiện liên tiếp.
[C-1-5] PHẢI đảm bảo rằng luồng sự kiện cảm biến KHÔNG được ngăn CPU thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức từ trạng thái tạm ngưng.
[C-1-6] PHẢI báo cáo thời gian sự kiện bằng nano giây như được xác định trong tài liệu SDK Android, đại diện cho thời gian sự kiện xảy ra và được đồng bộ hoá với đồng hồ SystemClock.elapsedRealtimeNano().
[C-SR-1] NÊN có lỗi đồng bộ hoá dấu thời gian dưới 100 mili giây và PHẢI có lỗi đồng bộ hoá dấu thời gian dưới 1 mili giây.
Khi nhiều cảm biến được kích hoạt, mức tiêu thụ điện năng KHÔNG ĐƯỢC vượt quá tổng mức tiêu thụ điện năng được báo cáo của từng cảm biến.

Danh sách trên chưa đầy đủ; hành vi được ghi nhận của SDK Android và Tài liệu nguồn mở Android về các cảm biến được coi là có thẩm quyền.

Nếu việc triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, thì họ:

[C-1-6] PHẢI đặt độ phân giải khác 0 cho tất cả cảm biến và báo cáo giá trị thông qua phương thức API Sensor.getResolution().

Một số loại cảm biến là tổng hợp, nghĩa là chúng có thể được lấy từ dữ liệu do một hoặc nhiều cảm biến khác cung cấp. (Ví dụ: cảm biến hướng và cảm biến gia tốc tuyến tính.)

Triển khai trên thiết bị:

NÊN triển khai các loại cảm biến này, khi các loại cảm biến này bao gồm các cảm biến vật lý cần thiết như mô tả trong các loại cảm biến.

Nếu quá trình triển khai thiết bị bao gồm cảm biến tổng hợp, thì các thiết bị đó:

[C-2-1] PHẢI triển khai cảm biến như mô tả trong tài liệu về cảm biến tổng hợp của Android Open Source.

Nếu hoạt động triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba và cảm biến chỉ báo cáo một giá trị, thì hoạt động triển khai thiết bị:

[C-3-1] PHẢI đặt độ phân giải thành 1 cho cảm biến và báo cáo giá trị thông qua phương thức API Sensor.getResolution().

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể hỗ trợ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION và cảm biến này được hiển thị cho các nhà phát triển bên thứ ba, thì họ:

[C-4-1] KHÔNG ĐƯỢC đưa bất kỳ thông số hiệu chuẩn cố định nào do nhà máy xác định vào dữ liệu được cung cấp.

Nếu việc triển khai thiết bị bao gồm sự kết hợp của gia tốc kế 3 trục, cảm biến con quay hồi chuyển 3 trục hoặc cảm biến từ kế, thì đó là:

[C-SR-2] NÊN đảm bảo gia tốc kế, con quay hồi chuyển và cảm biến từ trường có vị trí tương đối cố định, chẳng hạn như nếu thiết bị có thể biến đổi (ví dụ: có thể gập lại), các trục cảm biến vẫn được căn chỉnh và nhất quán với hệ toạ độ cảm biến trong tất cả các trạng thái biến đổi thiết bị có thể có.

7.3.1. Gia tốc kế

Triển khai trên thiết bị:

[C-SR-1] NÊN có gia tốc kế 3 trục.

Nếu triển khai gia tốc kế trên thiết bị, thì các thiết bị đó:

[C-1-1] PHẢI có thể báo cáo các sự kiện có tần suất tối thiểu là 50 Hz.
[C-1-3] PHẢI tuân thủ hệ toạ độ cảm biến Android như mô tả chi tiết trong API Android.
[C-1-4] PHẢI có khả năng đo lường từ trạng thái rơi tự do lên đến bốn lần trọng lực(4g) trở lên trên bất kỳ trục nào.
[C-1-5] PHẢI có độ phân giải tối thiểu là 12 bit.
[C-1-6] PHẢI có độ lệch chuẩn không lớn hơn 0,05 m/s^, trong đó độ lệch chuẩn phải được tính trên cơ sở mỗi trục trên các mẫu được thu thập trong khoảng thời gian ít nhất 3 giây ở tốc độ lấy mẫu nhanh nhất.
NÊN báo cáo các sự kiện lên đến ít nhất 200 Hz.
NÊN có độ phân giải tối thiểu là 16 bit.
NÊN được hiệu chỉnh trong khi sử dụng nếu các đặc điểm thay đổi trong vòng đời và được bù, đồng thời giữ nguyên các tham số bù giữa các lần khởi động lại thiết bị.
PHẢI được bù trừ nhiệt độ.

Nếu triển khai gia tốc kế 3 trục trên thiết bị, thì các thiết bị đó:

[C-2-1] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER.
[C-SR-4] Bạn NÊN triển khai cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION.
[C-SR-5] Bạn NÊN triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_UNCALIBRATED. Bạn NÊN đáp ứng yêu cầu này cho thiết bị Android để có thể nâng cấp lên bản phát hành nền tảng trong tương lai, trong đó yêu cầu này có thể trở thành BẮT BUỘC.
NÊN triển khai các cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER như mô tả trong tài liệu SDK Android.

Nếu việc triển khai thiết bị bao gồm một gia tốc kế có ít hơn 3 trục, thì các thiết bị đó:

[C-3-1] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] Bạn NÊN 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ị bao gồm gia tốc kế 3 trục và bất kỳ cảm biến tổng hợp nào trong số TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER được triển khai:

[C-4-1] Tổng mức tiêu thụ điện năng của các thiết bị này PHẢI luôn nhỏ hơn 4 mW.
NÊN có công suất dưới 2 mW và 0,5 mW khi thiết bị ở trạng thái động hoặc tĩnh.

Nếu việc triển khai thiết bị bao gồm gia tốc kế 3 trục và cảm biến con quay hồi chuyển 3 trục, thì các thiết bị đó:

[C-5-1] PHẢI triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
[C-SR-7] Bạn NÊN triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR.

Nếu việc triển khai thiết bị bao gồm gia tốc kế 3 trục, cảm biến con quay hồi chuyển 3 trục và cảm biến từ kế, thì các thiết bị đó:

[C-6-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

7.3.2. Từ kế

Triển khai trên thiết bị:

[C-SR-1] NÊN sử dụng từ kế (la bàn) 3 trục.

Nếu việc triển khai thiết bị bao gồm một cảm biến từ trường 3 trục, thì các thiết bị đó:

[C-1-1] PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD.
[C-1-2] PHẢI có thể báo cáo các sự kiện có tần suất tối thiểu là 10 Hz và NÊN báo cáo các sự kiện có tần suất tối thiểu là 50 Hz.
[C-1-3] PHẢI tuân thủ hệ toạ độ cảm biến Android như mô tả chi tiết trong API Android.
[C-1-4] PHẢI có khả năng đo từ -900 µT đến +900 µT trên mỗi trục trước khi bão hoà.
[C-1-5] PHẢI có giá trị bù sắt cứng nhỏ hơn 700 µT và NÊN có giá trị dưới 200 µT, bằng cách đặt máy đo từ trường cách xa trường từ động (do dòng điện tạo ra) và trường từ tĩnh (do nam châm tạo ra).
[C-1-6] PHẢI có độ phân giải bằng hoặc dày hơn 0,6 µT.
[C-1-7] PHẢI hỗ trợ việc hiệu chỉnh và bù trợ trực tuyến độ lệch từ tính cứng, đồng thời duy trì các tham số bù trợ giữa các lần khởi động lại thiết bị.
[C-1-8] PHẢI áp dụng tính năng bù sắt mềm – bạn có thể thực hiện việc hiệu chuẩn trong khi sử dụng hoặc trong quá trình sản xuất thiết bị.
[C-1-9] PHẢI có độ lệch chuẩn, được tính trên cơ sở mỗi trục trên các mẫu được thu thập trong khoảng thời gian ít nhất 3 giây ở tốc độ lấy mẫu nhanh nhất, không lớn hơn 1,5 µT; NÊN có độ lệch chuẩn không lớn hơn 0,5 µT.
[C-1-10] PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Nếu việc triển khai thiết bị bao gồm một từ kế 3 trục, một cảm biến gia tốc kế và một cảm biến con quay hồi chuyển 3 trục, thì các thiết bị đó:

[C-2-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Nếu việc triển khai thiết bị bao gồm một máy đo từ trường 3 trục, một gia tốc kế, thì các thiết bị đó:

CÓ THỂ triển khai cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Nếu việc triển khai thiết bị bao gồm một cảm biến từ kế 3 trục, một gia tốc kế và cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR, thì các thiết bị đó:

[C-3-1] PHẢI tiêu thụ ít hơn 10 mW.
NÊN tiêu thụ ít hơn 3 mW khi cảm biến được đăng ký cho chế độ hàng loạt ở tần số 10 Hz.

7.3.3. GPS

Triển khai trên thiết bị:

[C-SR-1] NÊN có bộ thu GPS/GNSS.

Nếu việc triển khai thiết bị bao gồm bộ thu GPS/GNSS và báo cáo chức năng này cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ đầu ra vị trí với tốc độ tối thiểu là 1 Hz khi được yêu cầu thông qua LocationManager#requestLocationUpdate.
[C-1-2] PHẢI xác định được vị trí trong điều kiện ngoài trời (tín hiệu mạnh, đa đường truyền không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian nhanh để xác định vị trí lần đầu tiên), khi kết nối với kết nối Internet có tốc độ dữ liệu từ 0,5 Mb/giây trở lên. Yêu cầu này thường được đáp ứng bằng cách sử dụng một số hình thức kỹ thuật GPS/GNSS được hỗ trợ hoặc dự đoán để giảm thiểu thời gian khoá GPS/GNSS (Dữ liệu hỗ trợ bao gồm Thời gian tham chiếu, Vị trí tham chiếu và Bảng thông tin thiên văn/Đồng hồ vệ tinh).
- [C-1-6] Sau khi thực hiện phép tính vị trí như vậy, việc triển khai thiết bị PHẢI xác định vị trí của thiết bị, ở ngoài trời, trong vòng 5 giây, khi các yêu cầu vị trí được khởi động lại, tối đa một giờ sau khi thực hiện phép tính vị trí ban đầu, ngay cả khi yêu cầu tiếp theo được thực hiện mà không có kết nối dữ liệu và/hoặc sau một chu kỳ nguồn.
Trong điều kiện ngoài trời sau khi xác định vị trí, khi đứng yên hoặc di chuyển với gia tốc dưới 1 mét trên giây bình phương:
- [C-1-3] PHẢI xác định được vị trí trong phạm vi 20 mét và tốc độ trong phạm vi 0, 5 mét/giây, ít nhất là 95% thời gian.
- [C-1-4] PHẢI đồng thời theo dõi và báo cáo qua GnssStatus.Callback ít nhất 8 vệ tinh từ một chòm sao.
- PHẢI có khả năng theo dõi đồng thời ít nhất 24 vệ tinh, từ nhiều chòm sao (ví dụ: GPS + ít nhất một trong các vệ tinh Glonass, Beidou, Galileo).
[C-SR-2] Bạn NÊN tiếp tục phân phối đầu ra vị trí GPS/GNSS thông thường thông qua API Trình cung cấp vị trí GNSS trong khi gọi điện khẩn cấp.
[C-SR-3] Bạn NÊN báo cáo các phép đo GNSS từ tất cả các chòm sao được theo dõi (như được báo cáo trong thông báo GnssStatus), ngoại trừ SBAS.
[C-SR-4] NÊN báo cáo AGC và Tần suất đo lường GNSS.
[C-SR-5] Bạn NÊN báo cáo tất cả thông tin ước tính về độ chính xác (bao gồm cả Độ lệch, Tốc độ và Độ cao) trong mỗi vị trí GPS/GNSS.
[C-SR-6] Bạn NÊN báo cáo các phép đo GNSS ngay khi phát hiện được, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
[C-SR-7] Bạn NÊN báo cáo khoảng thời gian giả và tốc độ khoảng thời gian giả của GNSS. Trong điều kiện bầu trời quang đãng sau khi xác định vị trí, khi đứng yên hoặc di chuyển với gia tốc dưới 0,2 mét trên giây vuông, các giá trị này đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0,2 mét trên giây, ít nhất là 95% thời gian.

7.3.4. Con quay hồi chuyển

Triển khai trên thiết bị:

[C-SR-1] NÊN có cảm biến con quay hồi chuyển.

Nếu việc triển khai thiết bị bao gồm con quay hồi chuyển, thì các thiết bị đó:

[C-1-1] PHẢI có thể báo cáo các sự kiện có tần suất tối thiểu là 50 Hz.
[C-1-4] PHẢI có độ phân giải từ 12 bit trở lên.
[C-1-5] PHẢI được bù trừ nhiệt độ.
[C-1-6] PHẢI được hiệu chỉnh và bù trong khi sử dụng, đồng thời duy trì các tham số bù giữa các lần khởi động lại thiết bị.
[C-1-7] PHẢI có độ biến thiên không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (độ biến thiên trên mỗi Hz hoặc rad^2 / s). Độ lệch được phép thay đổi theo tốc độ lấy mẫu, nhưng PHẢI bị ràng buộc bởi giá trị này. Nói cách khác, nếu bạn đo lường độ biến thiên của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì độ biến thiên này KHÔNG được lớn hơn 1e-7 rad^2/s^2.
[C-SR-2] Bạn NÊN để lỗi hiệu chỉnh dưới 0,01 rad/giây khi thiết bị đứng yên ở nhiệt độ phòng.
[C-SR-3] NÊN có độ phân giải từ 16 bit trở lên.
NÊN báo cáo các sự kiện lên đến ít nhất 200 Hz.

Nếu việc triển khai thiết bị bao gồm con quay hồi chuyển 3 trục, thì các thiết bị đó:

[C-2-1] PHẢI triển khai cảm biến TYPE_GYROSCOPE.
[C-SR-4] Bạn nên triển khai cảm biến TYPE_GYROSCOPE_UNCALIBRATED.

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

[C-3-1] PHẢI triển khai và báo cáo cảm biến TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] Bạn NÊN 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ị bao gồm con quay hồi chuyển 3 trục, cảm biến gia tốc kế và cảm biến từ kế, thì các thiết bị đó:

[C-4-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Nếu quá trình triển khai thiết bị bao gồm gia tốc kế 3 trục và cảm biến con quay hồi chuyển 3 trục, thì các thiết bị đó:

[C-5-1] PHẢI triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
[C-SR-6] Bạn NÊN triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR.

7.3.5. Khí áp kế

Triển khai trên thiết bị:

[C-SR-1] Bạn NÊN đưa vào một áp kế (cảm biến áp suất không khí xung quanh).

Nếu triển khai thiết bị có áp kế, thì các thiết bị đó:

[C-1-1] PHẢI triển khai và báo cáo cảm biến TYPE_PRESSURE.
[C-1-2] PHẢI có khả năng phân phối sự kiện ở tốc độ 5 Hz trở lên.
[C-1-3] PHẢI được bù trừ nhiệt độ.
[C-SR-2] NÊN có khả năng báo cáo kết quả đo áp suất trong phạm vi từ 300hPa đến 1100hPa.
PHẢI có độ chính xác tuyệt đối là 1hPa.
PHẢI có độ chính xác tương đối là 0,12hPa trong phạm vi 20hPa (tương đương với độ chính xác ~1m trong khoảng thay đổi ~200m ở mực nước biển).

7.3.6. Nhiệt kế

Nếu việc triển khai thiết bị bao gồm nhiệt kế môi trường xung quanh (cảm biến nhiệt độ), thì các thiết bị đó:

[C-1-1] PHẢI xác định SENSOR_TYPE_AMBIENT_TEMPERATURE cho cảm biến nhiệt độ môi trường xung quanh và cảm biến PHẢI đo nhiệt độ môi trường xung quanh (phòng/cabin xe) từ nơi người dùng đang tương tác với thiết bị theo độ C.

Nếu quá trình triển khai thiết bị bao gồm cảm biến nhiệt kế đo nhiệt độ khác với nhiệt độ môi trường xung quanh, chẳng hạn như nhiệt độ CPU, thì các thiết bị đó:

[C-2-1] KHÔNG ĐƯỢC xác định SENSOR_TYPE_AMBIENT_TEMPERATURE cho cảm biến nhiệt độ.

Nếu việc triển khai thiết bị bao gồm một cảm biến để theo dõi nhiệt độ da, thì các thiết bị đó:

[C-SR-1] Bạn NÊN hỗ trợ API PowerManager.getThermalHeadroom.

7.3.7. Máy đo sáng

Việc triển khai thiết bị CÓ THỂ bao gồm máy đo quang phổ (cảm biến ánh sáng xung quanh).

7.3.8. Cảm biến độ gần

Việc triển khai thiết bị CÓ THỂ bao gồm cảm biến độ gần.

Nếu việc triển khai thiết bị bao gồm cảm biến khoảng cách và chỉ báo cáo giá trị đọc nhị phân "gần" hoặc "xa", thì các thiết bị đó:

[C-1-1] PHẢI đo khoảng cách của một đối tượng theo cùng hướng với màn hình. Tức là cảm biến khoảng cách PHẢI được định hướng để phát hiện các đối tượng gần màn hình, vì ý định chính của loại cảm biến này là phát hiện điện thoại mà người dùng đang sử dụng. Nếu việc triển khai thiết bị bao gồm cảm biến khoảng cách với bất kỳ hướng nào khác, thì bạn KHÔNG ĐƯỢC truy cập vào cảm biến đó thông qua API này.
[C-1-2] PHẢI có độ chính xác từ 1 bit trở lên.
[C-1-3] PHẢI sử dụng 0 cm làm giá trị đọc gần và 5 cm làm giá trị đọc xa.
[C-1-4] PHẢI báo cáo phạm vi và độ phân giải tối đa là 5.

7.3.9. Cảm biến có độ trung thực cao

Nếu việc triển khai thiết bị bao gồm một bộ cảm biến chất lượng cao hơn như được xác định trong phần này và cung cấp các cảm biến đó cho ứng dụng bên thứ ba, thì các cảm biến đó:

[C-1-1] PHẢI xác định chức năng thông qua cờ tính năng android.hardware.sensor.hifi_sensors.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.sensor.hifi_sensors, thì các hoạt động đó:

[C-2-1] PHẢI có cảm biến TYPE_ACCELEROMETER:
- PHẢI có phạm vi đo lường từ -8g đến +8g và NÊN có phạm vi đo lường từ -16g đến +16g.
- PHẢI có độ phân giải đo lường tối thiểu là 2048 LSB/g.
- PHẢI có tần số đo lường tối thiểu là 12,5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 400 Hz trở lên; NÊN hỗ trợ SensorDirectChannel RATE_VERY_FAST.
- PHẢI có độ nhiễu đo lường không vượt quá 400 μg/√Hz.
- PHẢI triển khai một dạng không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 3000 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng theo lô không tệ hơn 3 mW.
- [C-SR-1] Bạn NÊN có băng thông đo lường 3dB tối thiểu là 80% tần số Nyquist và phổ nhiễu trắng trong băng thông này.
- PHẢI có tốc độ đi ngẫu nhiên của gia tốc nhỏ hơn 30 μg √Hz được kiểm tra ở nhiệt độ phòng.
- PHẢI có sự thay đổi về độ lệch so với nhiệt độ ≤ +/- 1 mg/°C.
- PHẢI có độ phi tuyến tính của đường phù hợp nhất ≤ 0,5% và độ thay đổi độ nhạy so với nhiệt độ ≤ 0,03%/C°.
- PHẢI có độ nhạy theo trục chéo < 2,5 % và độ biến thiên của độ nhạy theo trục chéo < 0,2% trong phạm vi nhiệt độ hoạt động của thiết bị.
[C-2-2] PHẢI có TYPE_ACCELEROMETER_UNCALIBRATED có cùng yêu cầu về chất lượng như TYPE_ACCELEROMETER.
[C-2-3] PHẢI có cảm biến TYPE_GYROSCOPE:
- PHẢI có phạm vi đo lường từ -1000 đến +1000 dps.
- PHẢI có độ phân giải đo lường tối thiểu là 16 LSB/dps.
- PHẢI có tần số đo lường tối thiểu là 12,5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 400 Hz trở lên; NÊN hỗ trợ SensorDirectChannel RATE_VERY_FAST.
- PHẢI có độ nhiễu đo lường không vượt quá 0,014°/giây/√Hz.
- [C-SR-2] Bạn NÊN có băng thông đo lường 3dB tối thiểu là 80% tần số Nyquist và phổ nhiễu trắng trong băng thông này.
- PHẢI có tốc độ đi ngẫu nhiên dưới 0,001 °/s √Hz được kiểm tra ở nhiệt độ phòng.
- NÊN có sự thay đổi độ lệch so với nhiệt độ ≤ +/- 0,05 °/ s / °C.
- PHẢI có mức thay đổi độ nhạy so với nhiệt độ ≤ 0,02% / °C.
- PHẢI có độ phi tuyến tính của đường phù hợp nhất ≤ 0,2%.
- PHẢI có mật độ nhiễu ≤ 0,007 °/s/√Hz.
- PHẢI có lỗi hiệu chuẩn nhỏ hơn 0,002 rad/s trong phạm vi nhiệt độ từ 10 đến 40 ℃ khi thiết bị đứng yên.
- PHẢI có độ nhạy g dưới 0,1°/giây/g.
- PHẢI có độ nhạy theo trục chéo < 4,0 % và độ biến thiên độ nhạy theo trục chéo < 0,3% trong phạm vi nhiệt độ hoạt động của thiết bị.
[C-2-4] PHẢI có TYPE_GYROSCOPE_UNCALIBRATED với các yêu cầu về chất lượng giống như TYPE_GYROSCOPE.
[C-2-5] PHẢI có cảm biến TYPE_GEOMAGNETIC_FIELD:
- PHẢI có phạm vi đo lường ít nhất là từ -900 đến +900 μT.
- PHẢI có độ phân giải đo lường ít nhất là 5 LSB/uT.
- PHẢI có tần số đo lường tối thiểu là 5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 50 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 0,5 uT.
[C-2-6] PHẢI có TYPE_MAGNETIC_FIELD_UNCALIBRATED có các yêu cầu về chất lượng giống như TYPE_GEOMAGNETIC_FIELD và ngoài ra:
- PHẢI triển khai một dạng không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 600 sự kiện cảm biến.
- [C-SR-3] Bạn NÊN có phổ nhiễu trắng từ 1 Hz đến ít nhất 10 Hz khi tốc độ báo cáo là 50 Hz trở lên.
[C-2-7] PHẢI có cảm biến TYPE_PRESSURE:
- PHẢI có phạm vi đo lường từ 300 đến 1100 hPa.
- PHẢI có độ phân giải đo lường tối thiểu là 80 LSB/hPa.
- PHẢI có tần suất đo lường tối thiểu là 1 Hz trở xuống.
- PHẢI có tần suất đo tối đa từ 10 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 2 Pa/√Hz.
- PHẢI triển khai một dạng không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 300 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng theo lô không tệ hơn 2 mW.
[C-2-8] PHẢI có cảm biến TYPE_GAME_ROTATION_VECTOR.
[C-2-9] PHẢI có cảm biến TYPE_SIGNIFICANT_MOTION:
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang di chuyển.
[C-2-10] PHẢI có cảm biến TYPE_STEP_DETECTOR:
- PHẢI triển khai một dạng không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 100 sự kiện cảm biến.
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang di chuyển.
- PHẢI có mức tiêu thụ điện năng theo lô không tệ hơn 4 mW.
[C-2-11] PHẢI có cảm biến TYPE_STEP_COUNTER:
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang di chuyển.
[C-2-12] PHẢI có cảm biến TILT_DETECTOR:
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang di chuyển.
[C-2-13] Dấu thời gian của sự kiện về cùng một sự kiện vật lý do Con quay hồi chuyển, Con quay hồi chuyển và Máy đo từ trường báo cáo PHẢI nằm trong khoảng 2, 5 mili giây so với nhau. Dấu thời gian của sự kiện về cùng một sự kiện vật lý do Con quay hồi chuyển và Gia tốc kế báo cáo PHẢI nằm trong khoảng 0,25 mili giây so với nhau.
[C-2-14] PHẢI có dấu thời gian sự kiện cảm biến Con quay hồi chuyển trên cùng một cơ sở thời gian với hệ thống con máy ảnh và trong phạm vi lỗi 1 mili giây.
[C-2-15] PHẢI phân phối mẫu cho ứng dụng trong vòng 5 mili giây kể từ thời điểm ứng dụng có dữ liệu trên bất kỳ cảm biến vật lý nào nêu trên.
[C-2-16] KHÔNG ĐƯỢC tiêu thụ nhiều năng lượng hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 2,0 mW khi thiết bị đang di chuyển khi bất kỳ tổ hợp nào của các cảm biến sau được bật:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] CÓ THỂ có cảm biến TYPE_PROXIMITY, nhưng nếu có, PHẢI có dung lượng bộ đệm tối thiểu là 100 sự kiện cảm biến.

Xin lưu ý rằng tất cả các yêu cầu về mức tiêu thụ điện năng trong phần này không bao gồm mức tiêu thụ điện năng của Bộ xử lý ứng dụng. Mức tiêu thụ này bao gồm cả nguồn điện do toàn bộ chuỗi cảm biến tiêu thụ – cảm biến, mọi mạch điện hỗ trợ, mọi hệ thống xử lý cảm biến chuyên dụng, v.v.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ cảm biến trực tiếp, thì các thiết bị đó:

[C-3-1] PHẢI khai báo chính xác việc hỗ trợ các loại kênh trực tiếp và cấp độ tỷ lệ báo cáo trực tiếp thông qua API isDirectChannelTypeSupported và getHighestDirectReportRateLevel.
[C-3-2] PHẢI hỗ trợ ít nhất một trong hai loại kênh trực tiếp của cảm biến cho tất cả cảm biến khai báo hỗ trợ kênh trực tiếp của cảm biến.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
PHẢI hỗ trợ báo cáo sự kiện thông qua kênh trực tiếp của cảm biến cho cảm biến chính (biến thể không đánh thức) thuộc các loại sau:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Cảm biến sinh trắc học

Để biết thêm thông tin cơ bản về tính năng Đo lường bảo mật khi mở khoá bằng sinh trắc học, vui lòng xem tài liệu về tính năng Đo lường bảo mật bằng sinh trắc học.

Nếu triển khai màn hình khoá bảo mật, thiết bị sẽ:

PHẢI có cảm biến sinh trắc học

Cảm biến sinh trắc học có thể được phân loại là Lớp 3 (trước đây là Mạnh), Lớp 2 (trước đây là Yếu) hoặc Lớp 1 (trước đây là Tiện lợi) dựa trên tỷ lệ chấp nhận giả mạo và giả mạo, cũng như dựa trên độ bảo mật của quy trình sinh trắc học. Việc phân loại này xác định các chức năng mà cảm biến sinh trắc học cần có để giao tiếp với nền tảng và với các ứng dụng của bên thứ ba. Cảm biến cần đáp ứng các yêu cầu bổ sung như được nêu chi tiết bên dưới nếu muốn được phân loại là Lớp 1, Lớp 2 hoặc Lớp 3. Cả thông tin sinh trắc học Lớp 2 và Lớp 3 đều có các chức năng bổ sung như được nêu chi tiết bên dưới.

Nếu việc triển khai thiết bị cung cấp cảm biến sinh trắc học cho các ứng dụng bên thứ ba thông qua android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt và android.provider.Settings.ACTION_BIOMETRIC_ENROLL, thì các ứng dụng đó:

[C-4-1] PHẢI đáp ứng các yêu cầu đối với thông tin sinh trắc học Lớp 3 hoặc Lớp 2 như được xác định trong tài liệu này.
[C-4-2] PHẢI nhận dạng và tuân thủ từng tên tham số được xác định là hằng số trong lớp Authenticator và mọi tổ hợp của các tên đó. Ngược lại, KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số số nguyên được truyền đến các phương thức canAuthenticate(int) và setAllowedAuthenticators(int) khác với các hằng số được ghi nhận là hằng số công khai trong Authenticators và mọi tổ hợp của các hằng số đó.
[C-4-3] BẮT BUỘC triển khai thao tác ACTION_BIOMETRIC_ENROLL trên các thiết bị có dữ liệu sinh trắc học Lớp 3 hoặc Lớp 2. Thao tác này PHẢI chỉ hiển thị các điểm truy cập đăng ký cho dữ liệu sinh trắc học Lớp 3 hoặc Lớp 2.

Nếu việc triển khai thiết bị hỗ trợ tính năng sinh trắc học thụ động, thì các thiết bị đó:

[C-5-1] Theo mặc định, BẮT BUỘC phải yêu cầu thêm một bước xác nhận (ví dụ: nhấn nút).
[C-SR-1] NÊN có chế độ cài đặt cho phép người dùng ghi đè lựa chọn ưu tiên của ứng dụng và luôn yêu cầu bước xác nhận đi kèm.
[C-SR-2] Bạn NÊN bảo mật thao tác xác nhận để hệ điều hành hoặc hạt nhân bị xâm phạm không thể giả mạo thao tác đó. Ví dụ: điều này có nghĩa là thao tác xác nhận dựa trên nút vật lý được định tuyến thông qua một chân đầu vào/đầu ra (GPIO) đa năng chỉ có đầu vào của một phần tử bảo mật (SE) không thể được điều khiển bằng bất kỳ phương tiện nào khác ngoài thao tác nhấn nút vật lý.
[C-5-2] PHẢI triển khai thêm quy trình xác thực ngầm ẩn (không có bước xác nhận) tương ứng với setConfirmationRequired(boolean) mà các ứng dụng có thể thiết lập để sử dụng cho quy trình đăng nhập.

Nếu việc triển khai thiết bị có nhiều cảm biến sinh trắc học, thì các cảm biến đó:

Bắt đầu yêu cầu mới

[C-7-1] PHẢI, khi một phương thức nhận dạng sinh trắc học bị khoá (tức là phương thức nhận dạng sinh trắc học bị vô hiệu hoá cho đến khi người dùng mở khoá bằng phương thức xác thực chính) hoặc bị khoá theo thời gian (tức là phương thức nhận dạng sinh trắc học bị tạm thời vô hiệu hoá cho đến khi người dùng chờ một khoảng thời gian) do quá nhiều lần thử không thành công, cũng phải khoá tất cả các phương thức nhận dạng sinh trắc học khác thuộc lớp sinh trắc học thấp hơn. Trong trường hợp khoá có giới hạn thời gian, thời gian đợi để xác minh bằng sinh trắc học PHẢI là thời gian đợi tối đa của tất cả dữ liệu sinh trắc học trong trường hợp khoá có giới hạn thời gian.
[C-SR-12] NÊN, khi một phương thức sinh trắc học bị khoá (tức là phương thức sinh trắc học bị vô hiệu hoá cho đến khi người dùng mở khoá bằng phương thức xác thực chính) hoặc bị khoá theo thời gian (tức là phương thức sinh trắc học bị tạm thời vô hiệu hoá cho đến khi người dùng chờ một khoảng thời gian) do quá nhiều lần thử không thành công, cũng khoá tất cả các phương thức sinh trắc học khác thuộc cùng một lớp sinh trắc học. Trong trường hợp khoá có giới hạn thời gian, bạn NÊN đặt thời gian đợi để xác minh bằng sinh trắc học là thời gian đợi tối đa của tất cả phương thức sinh trắc học trong trường hợp khoá có giới hạn thời gian.
[C-7-2] PHẢI thách thức người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) để đặt lại bộ đếm khoá khi phương thức xác thực sinh trắc học bị khoá. Dữ liệu sinh trắc học Loại 3 CÓ THỂ được phép đặt lại bộ đếm khoá cho dữ liệu sinh trắc học bị khoá thuộc cùng loại hoặc loại thấp hơn. KHÔNG ĐƯỢC cho phép phương thức xác thực sinh trắc học Loại 2 hoặc Loại 1 hoàn tất thao tác khoá đặt lại cho bất kỳ phương thức xác thực sinh trắc học nào.

Kết thúc các yêu cầu mới

[C-SR-3] Bạn NÊN chỉ yêu cầu xác nhận một thông tin sinh trắc học cho mỗi lần xác thực (ví dụ: nếu cả cảm biến vân tay và cảm biến khuôn mặt đều có trên thiết bị, thì bạn nên gửi onAuthenticationSucceeded sau khi xác nhận bất kỳ thông tin sinh trắc học nào trong số đó).

Để quá trình triển khai thiết bị cho phép truy cập vào khoá kho khoá cho các ứng dụng bên thứ ba, các ứng dụng đó phải:

[C-6-1] PHẢI đáp ứng các yêu cầu đối với Lớp 3 như được xác định trong phần này bên dưới.
[C-6-2] CHỈ ĐƯỢC hiển thị thông tin sinh trắc học Lớp 3 khi quy trình xác thực yêu cầu BIOMETRIC_STRONG hoặc quy trình xác thực được gọi bằng CryptoObject.

Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 1 (trước đây là Tiện lợi), thì các thiết bị đó:

[C-1-1] PHẢI có tỷ lệ chấp nhận sai dưới 0,002%.
[C-1-2] PHẢI công bố rằng chế độ này có thể kém an toàn hơn so với mã PIN, hình mở khoá hoặc mật khẩu khó đoán và liệt kê rõ ràng các rủi ro khi bật chế độ này, nếu tỷ lệ chấp nhận hành vi giả mạo và mạo danh cao hơn 7% theo Nghị định về thử nghiệm sinh trắc học của Android.
[C-1-9] PHẢI thách thức người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) sau không quá 20 lần thử sai và không dưới 90 giây thời gian chờ để xác minh sinh trắc học – trong đó lần thử sai là lần có chất lượng thu thập đủ (BIOMETRIC_ACQUIRED_GOOD) không khớp với thông tin sinh trắc học đã đăng ký.
[C-SR-4] Bạn NÊN giảm tổng số thử nghiệm sai cho quy trình xác minh sinh trắc học được chỉ định trong [C-1-9] nếu tỷ lệ chấp nhận giả mạo và mạo danh cao hơn 7% theo đo lường của Giao thức kiểm thử sinh trắc học Android.
[C-1-3] PHẢI giới hạn số lần xác minh sinh trắc học – trong đó, một lần thử nghiệm không hợp lệ là một lần thử nghiệm có chất lượng chụp đủ (BIOMETRIC_ACQUIRED_GOOD) nhưng không khớp với dữ liệu sinh trắc học đã đăng ký.
[C-SR-5] BạN NÊN đặt giới hạn số lần thử trong ít nhất 30 giây sau 5 lần thử xác minh sinh trắc học không thành công cho số lần thử xác minh sinh trắc học không thành công tối đa theo [C-1-9] – trong đó, một lần thử không thành công là một lần thử có chất lượng thu thập đủ (BIOMETRIC_ACQUIRED_GOOD) nhưng không khớp với thông tin sinh trắc học đã đăng ký.
[C-SR-6] Bạn NÊN có tất cả logic giới hạn tốc độ trong TEE.
[C-1-10] PHẢI tắt tính năng sinh trắc học sau khi thời gian chờ xác thực chính được kích hoạt lần đầu như mô tả trong [C-0-2] của phần 9.11.
[C-1-11] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 30%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 30% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh của các loại PAI cấp B không cao hơn 40%, theo đo lường của Giao thức kiểm thử sinh trắc học Android.
[C-1-4] PHẢI ngăn việc thêm thông tin sinh trắc học mới mà không thiết lập chuỗi tin cậy trước bằng cách yêu cầu người dùng xác nhận thông tin xác thực hiện có hoặc thêm thông tin xác thực thiết bị mới (mã PIN/mẫu/mật khẩu) do TEE bảo mật; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện việc này.
[C-1-5] PHẢI xoá hoàn toàn tất cả dữ liệu sinh trắc học có thể nhận dạng của người dùng khi tài khoản của người dùng bị xoá (bao gồm cả việc đặt lại về trạng thái ban đầu).
[C-1-6] PHẢI tuân thủ cờ riêng lẻ cho thông tin sinh trắc học đó (tức là DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE hoặc DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] PHẢI yêu cầu người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất 24 giờ một lần. Lưu ý: Khi nâng cấp các thiết bị chạy Android phiên bản 9 trở xuống, bạn PHẢI yêu cầu người dùng xác thực chính theo phương thức được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất 72 giờ một lần.
[C-1-8] PHẢI thách thức người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) hoặc thông tin sinh trắc học Lớp 3 (MẠNH) sau một trong những trường hợp sau:
- thời gian chờ khi không hoạt động là 4 giờ, HOẶC
- 3 lần xác thực bằng sinh trắc học không thành công.
- Thời gian chờ khi không hoạt động và số lần xác thực không thành công sẽ được đặt lại sau khi xác nhận thành công thông tin đăng nhập của thiết bị. Lưu ý: Việc nâng cấp các thiết bị chạy Android phiên bản 9 trở xuống CÓ THỂ được miễn C-1-8.
[C-SR-7] Bạn NÊN sử dụng logic trong khung do Dự án nguồn mở Android cung cấp để thực thi các quy tắc ràng buộc được chỉ định trong [C-1-7] và [C-1-8] cho các thiết bị mới.
[C-SR-8] NÊN có tỷ lệ từ chối sai dưới 10%, theo đo lường trên thiết bị.
[C-SR-9] NÊN có độ trễ dưới 1 giây, được đo từ khi phát hiện dữ liệu sinh trắc học cho đến khi mở khoá màn hình, đối với mỗi dữ liệu sinh trắc học đã đăng ký.

Bắt đầu yêu cầu mới

[C-1-12] PHẢI có tỷ lệ chấp nhận hành vi 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 bằng bản trình bày (PAI), được đo lường theo Nghị định về thử nghiệm sinh trắc học của Android.
[C-SR-13] Bạn NÊN có tỷ lệ chấp nhận hành vi 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 bằng bản trình bày (PAI), được đo lường theo Giao thức kiểm thử sinh trắc học của Android.
[C-SR-14] NÊN công bố 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 khi bật cảm biến đó.
[C-SR-17] Bạn NÊN triển khai các giao diện AIDL mới (chẳng hạn như IFace.aidl và IFingerprint.aidl).

Kết thúc các yêu cầu mới

Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 2 (trước đây là Yếu), thì các thiết bị đó:

[C-2-1] PHẢI đáp ứng tất cả các yêu cầu đối với Lớp 1 ở trên.
[C-2-2] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 20%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 20% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp B không cao hơn 30%, theo đo lường của Giao thức kiểm thử sinh trắc học của Android.

Bắt đầu yêu cầu mới

[C-SR-15] Bạn NÊN có tỷ lệ chấp nhận hành vi 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 bằng bản trình bày (PAI), theo đo lường của Giao thức kiểm thử sinh trắc học của Android.

Kết thúc các yêu cầu mới

[C-2-3] PHẢI thực hiện việc so khớp sinh trắc học trong một môi trường thực thi biệt lập bên ngoài không gian người dùng hoặc hạt nhân Android, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE), ~~hoặc~~ trên một khối có kênh bảo mật đến môi trường thực thi biệt lập hoặc trên Máy ảo được bảo vệ đáp ứng các yêu cầu trong Mục 9.17.
[C-2-4] PHẢI mã hoá và xác thực bằng mật mã tất cả dữ liệu nhận dạng để không thể thu thập, đọc hoặc thay đổi dữ liệu đó bên ngoài môi trường thực thi tách biệt hoặc một khối có kênh bảo mật đến môi trường thực thi tách biệt như được ghi nhận trong nguyên tắc triển khai trên trang web Dự án nguồn mở Android hoặc Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát đáp ứng các yêu cầu trong Mục 9.17.
[C-2-5] Đối với thông tin sinh trắc học dựa trên máy ảnh, trong khi quá trình xác thực hoặc đăng ký dựa trên sinh trắc học đang diễn ra:
- PHẢI vận hành máy ảnh ở chế độ ngăn không cho đọc hoặc thay đổi khung hình máy ảnh bên ngoài môi trường thực thi tách biệt hoặc một khối có kênh bảo mật đến môi trường thực thi tách biệt hoặc một Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát đáp ứng các yêu cầu trong Mục 9.17.
- Đối với các giải pháp máy ảnh đơn RGB, bạn CÓ THỂ đọc được các khung hình máy ảnh bên ngoài môi trường thực thi riêng biệt để hỗ trợ các thao tác như xem trước để đăng ký, nhưng KHÔNG ĐƯỢC thay đổi.
[C-2-6] KHÔNG ĐƯỢC cho phép các ứng dụng bên thứ ba phân biệt giữa các lần đăng ký sinh trắc học riêng lẻ.
[C-2-7] KHÔNG ĐƯỢC cho phép truy cập không mã hoá vào dữ liệu sinh trắc học có thể nhận dạng hoặc bất kỳ dữ liệu nào bắt nguồn từ dữ liệu đó (chẳng hạn như dữ liệu nhúng) vào Bộ xử lý ứng dụng bên ngoài ngữ cảnh của TEE hoặc Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát đáp ứng các yêu cầu trong Mục 9.17. Các thiết bị nâng cấp được phát hành trên Android phiên bản 9 trở xuống không được miễn khỏi C-2-7.
[C-2-8] PHẢI có quy trình xử lý an toàn để hệ điều hành hoặc hạt nhân bị xâm phạm không thể cho phép chèn dữ liệu trực tiếp để xác thực giả mạo người dùng. Lưu ý: Nếu việc triển khai thiết bị đã được triển khai trên Android phiên bản 9 trở xuống và không thể đáp ứng yêu cầu C-2-8 thông qua bản cập nhật phần mềm hệ thống, thì các thiết bị đó CÓ THỂ được miễn trừ yêu cầu này.
[C-SR-10] Bạn NÊN đưa tính năng phát hiện chuyển động sống vào tất cả các phương thức sinh trắc học và tính năng phát hiện sự chú ý vào tính năng sinh trắc học Khuôn mặt.
[C-2-9] PHẢI cung cấp cảm biến sinh trắc học cho các ứng dụng bên thứ ba.

Nếu việc triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 3 (trước đây là Mạnh), thì các thiết bị đó:

[C-3-1] PHẢI đáp ứng tất cả các yêu cầu của Lớp 2 ở trên, ngoại trừ [C-1-7] và [C-1-8].
[C-3-2] PHẢI triển khai kho khoá dựa trên phần cứng.
[C-3-3] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 7%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 7% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp B không cao hơn 20%, theo Nghị định về thử nghiệm sinh trắc học của Android.
[C-3-4] PHẢI yêu cầu người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất 72 giờ một lần.
[C-3-5] PHẢI tạo lại Mã nhận dạng trình xác thực cho tất cả các phương thức sinh trắc học Lớp 3 được hỗ trợ trên thiết bị nếu có phương thức nào đó được đăng ký lại.
[C-3-6] Phải bật khoá kho khoá được hỗ trợ bằng sinh trắc học cho các ứng dụng bên thứ ba.

Bắt đầu yêu cầu mới

[C-SR-16] Bạn NÊN có tỷ lệ chấp nhận hành vi 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 bằng bản trình bày (PAI), được đo lường theo Giao thức kiểm thử sinh trắc học của Android.

Kết thúc các yêu cầu mới

Nếu cách triển khai thiết bị chứa cảm biến vân tay dưới màn hình (UDFPS), thì các thiết bị đó:

[C-SR-11] Bạn NÊN ngăn khu vực có thể chạm của UDFPS can thiệp vào thao tác điều hướng bằng 3 nút (một số người dùng có thể yêu cầu điều này cho mục đích hỗ trợ tiếp cận).

7.3.11. Cảm biến tư thế

Triển khai trên thiết bị:

CÓ THỂ hỗ trợ cảm biến tư thế với 6 bậc tự do.

Nếu việc triển khai thiết bị hỗ trợ cảm biến tư thế với 6 bậc tự do, thì các thiết bị đó:

[C-1-1] PHẢI triển khai và báo cáo cảm biến TYPE_POSE_6DOF.
[C-1-2] PHẢI chính xác hơn so với chỉ vectơ xoay.

7.3.12. Cảm biến góc bản lề

Nếu việc triển khai thiết bị hỗ trợ cảm biến góc bản lề, thì các thiết bị đó:

[C-1-1] PHẢI triển khai và báo cáo TYPE_HINGLE_ANGLE.
[C-1-2] PHẢI hỗ trợ ít nhất hai lần đọc trong khoảng từ 0 đến 360 độ (bao gồm cả 0 và 360 độ).
[C-1-3] PHẢI trả về cảm biến đánh thức cho getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ 802.1.15.4 và hiển thị chức năng này cho ứng dụng bên thứ ba, thì các thiết bị đó:

Bắt đầu yêu cầu mới

[C-1-2] PHẢI báo cáo cờ tính năng phần cứng android.hardware.uwb.
[C-1-3] PHẢI hỗ trợ tất cả các nhóm cấu hình sau (các tổ hợp tham số FIRA UCI được xác định trước) được xác định trong quá trình triển khai AOSP.
- CONFIG_ID_1: Đo khoảng cách STATIC STS DS-TWR một địa chỉ do FiRa xác định, chế độ trì hoãn, khoảng thời gian đo khoảng cách 240 mili giây.
- CONFIG_ID_2: Phạm vi STATIC STS DS-TWR một với nhiều do FiRa xác định, chế độ trì hoãn, khoảng thời gian đo từ 200 mili giây. Trường hợp sử dụng thông thường: điện thoại thông minh tương tác với nhiều thiết bị thông minh.
- CONFIG_ID_3: Tương tự như CONFIG_ID_1, ngoại trừ dữ liệu Góc tới (AoA) không được báo cáo.
- CONFIG_ID_4: Tương tự như CONFIG_ID_1, ngoại trừ chế độ bảo mật P-STS được bật.
- CONFIG_ID_5: Tương tự như CONFIG_ID_2, ngoại trừ chế độ bảo mật P-STS được bật.
- CONFIG_ID_6: Tương tự 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ế độ khoá điều khiển riêng lẻ P-STS được bật.
[C-1-4] PHẢI cung cấp cho người dùng một chức năng để cho phép người dùng bật/tắt trạng thái vô tuyến UWB.
[C-1-5] PHẢI thực thi việc các ứng dụng sử dụng đài UWB phải có quyền UWB_RANGING (trong nhóm quyền NEARBY_DEVICES).

Việc vượt qua các bài kiểm thử chứng nhận và tuân thủ liên quan do các tổ chức tiêu chuẩn (bao gồm cả FIRA, CCC và CSA) xác định giúp đảm bảo 802.1.15.4 hoạt động chính xác.

Kết thúc các yêu cầu mới

7.4. Kết nối dữ liệu

7.4.1. Điện thoại

"Điện thoại" mà các API Android và tài liệu này sử dụng đề cập cụ thể đến phần cứng liên quan đến việc thực hiện 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" 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ể được chuyển đổi gói hoặc không, nhưng đối với Android, các cuộc gọi này được coi là độc lập với mọi kết nối dữ liệu 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 "thoại" của Android đề cập cụ thể đến cuộc gọi thoại và tin nhắn SMS. Ví dụ: các phương thức triển khai thiết bị không thể thực hiện 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ể thiết bị có sử dụng mạng di động để kết nối dữ liệu hay không.

Android CÓ THỂ được sử dụng trên các thiết bị không có phần cứng điện thoại. Tức là Android tương thích với các thiết bị không phải điện thoại.

Nếu việc triển khai thiết bị bao gồm điện thoại GSM hoặc CDMA, thì các thiết bị đó:

[C-1-1] BẮT BUỘC khai báo cờ tính năng android.hardware.telephony và các cờ tính năng phụ khác theo công nghệ.
[C-1-2] PHẢI triển khai hỗ trợ đầy đủ cho API của công nghệ đó.
NÊN cho phép tất cả các loại dịch vụ di động hiện có (2G, 3G, 4G, 5G, v.v.) trong cuộc gọi khẩn cấp (bất kể loại mạng do SetAllowedNetworkTypeBitmap() đặt).

Nếu việc triển khai thiết bị không bao gồm phần cứng điện thoại, thì các thiết bị đó:

[C-2-1] PHẢI triển khai đầy đủ các API dưới dạng không hoạt động.

Nếu việc triển khai thiết bị hỗ trợ eUICC hoặc eSIM/SIM nhúng và bao gồm một cơ chế độc quyền để cung cấp chức năng eSIM cho các nhà phát triển bên thứ ba, thì các thiết bị đó:

[C-3-1] PHẢI khai báo cờ tính năng android.hardware.telephony.euicc.

Nếu quá trình triển khai thiết bị không đặt thuộc tính hệ thống ro.telephony.iwlan\_operation\_mode thành "cũ", thì các quá trình đó:

[C-4-1] KHÔNG ĐƯỢC báo cáo "NETWORK_TYPE_IWLAN" thông qua NetworkRegistrationInfo#getAccessNetworkTechnology() khi NetworkRegistrationInfo#getTransportType() được báo cáo là "TRANSPORT_TYPE_WWAN" cho cùng một thực thể NetworkRegistrationInfo.

Nếu việc triển khai thiết bị hỗ trợ một lượt đăng ký Hệ thống con đa phương tiện qua IP (IMS) cho cả dịch vụ điện thoại đa phương tiện (MMTEL) và tính năng dịch vụ giao tiếp đa dạng (RCS) và dự kiến tuân thủ các yêu cầu của nhà mạng di động về việc sử dụng một lượt đăng ký IMS cho tất cả lưu lượng tín hiệu IMS, thì các thiết bị đó:

[C-5-1] PHẢI khai báo cờ tính năng android.hardware.telephony.ims và cung cấp cách triển khai đầy đủ API ImsService cho cả MMTEL và API trao đổi chức năng của người dùng RCS.
[C-5-2] BẮT BUỘC phải khai báo cờ tính năng android.hardware.telephony.ims.singlereg và cung cấp cách triển khai đầy đủ API SipTransport, API GbaService, chỉ báo chuyên dụng của phương thức truyền tải bằng cách sử dụng HAL IRadio 1.6 và cấp phép qua Máy chủ cấu hình tự động (ACS) hoặc cơ chế cấp phép độc quyền khác bằng cách sử dụng API Cấu hình IMS.

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony, thì:

[C-6-1] SmsManager#sendTextMessage và SmsManager#sendMultipartTextMessage PHẢI dẫn đến các lệnh gọi tương ứng đến CarrierMessagingService để cung cấp chức năng nhắn tin văn bản. SmsManager#sendMultimediaMessage và SmsManager#downloadMultimediaMessage PHẢI dẫn đến các lệnh gọi tương ứng đến CarrierMessagingService để cung cấp chức năng nhắn tin đa phương tiện.
[C-6-2] Ứng dụng do android.provider.Telephony.Sms#getDefaultSmsPackage chỉ định PHẢI sử dụng API SmsManager khi gửi và nhận tin nhắn SMS và MMS. Việc triển khai tài liệu tham khảo AOSP trong các gói/ứng dụng/Messaging đáp ứng yêu cầu này.
[C-6-3] Ứng dụng phản hồi Intent#ACTION_DIAL PHẢI hỗ trợ nhập mã trình quay số tuỳ ý có định dạng là *#*#CODE#*#* và kích hoạt thông báo truyền tin TelephonyManager#ACTION_SECRET_CODE tương ứng.
[C-6-4] Ứng dụng phản hồi Intent#ACTION_DIAL PHẢI sử dụng VoicemailContract.Voicemails#TRANSCRIPTION để hiển thị bản chép lời thư thoại kèm theo hình ảnh cho người dùng nếu ứng dụng đó hỗ trợ bản chép lời thư thoại kèm theo hình ảnh.
[C-6-5] PHẢI biểu thị tất cả SubscriptionInfo bằng UUID nhóm tương đương dưới dạng một gói thuê bao duy nhất trong tất cả các tính năng hiển thị cho người dùng, cho thấy và kiểm soát thông tin thẻ SIM. Ví dụ về các đặc điểm hữu dụng như vậy bao gồm giao diện cài đặt khớp với Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS hoặc EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] KHÔNG ĐƯỢC hiển thị hoặc cho phép kiểm soát bất kỳ SubscriptionInfo nào có UUID nhóm khác rỗng và bit cơ hội trong bất kỳ tính năng nào hiển thị với người dùng cho phép định cấu hình hoặc kiểm soát các chế độ cài đặt thẻ SIM.

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony và cung cấp thanh trạng thái hệ thống, thì:

[C-7-1] PHẢI chọn một gói thuê bao đang hoạt động đại diện cho một UUID nhóm nhất định để hiển thị cho người dùng trong mọi tính năng cung cấp thông tin về trạng thái SIM. Ví dụ về các đặc điểm hữu dụng như vậy bao gồm biểu tượng tín hiệu di động trên thanh trạng thái hoặc thẻ cài đặt nhanh.
[C-SR-1] Bạn NÊN chọn gói thuê bao đại diện là gói thuê bao dữ liệu đang hoạt động, trừ phi thiết bị đang thực hiện cuộc gọi thoại, trong trường hợp này, bạn NÊN chọn gói thuê bao đại diện là gói thuê bao thoại đang hoạt động.

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony, thì:

[C-6-7] PHẢI có khả năng mở và đồng thời sử dụng số lượng tối đa của các kênh logic (tổng cộng 20) cho mỗi UICC theo ETSI TS 102 221.
[C-6-8] KHÔNG ĐƯỢC tự động áp dụng bất kỳ hành vi nào sau đây cho các ứng dụng của nhà mạng đang hoạt động (do TelephonyManager#getCarrierServicePackageName chỉ định) hoặc áp dụng mà không có sự xác nhận rõ ràng của người dùng:
- Thu hồi hoặc giới hạn quyền truy cập mạng
- Thu hồi quyền
- Hạn chế việc thực thi ứng dụng ở chế độ nền hoặc chế độ nền trước ngoài các tính năng quản lý nguồn hiện có trong AOSP
- Tắt hoặc gỡ cài đặt ứng dụng

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony và tất cả các gói thuê bao không cơ hội đang hoạt động và dùng chung một UUID nhóm bị tắt, bị xoá khỏi thiết bị hoặc được đánh dấu là cơ hội, thì thiết bị đó:

[C-8-1] PHẢI tự động tắt tất cả các gói thuê bao tiện lợi còn lại đang hoạt động trong cùng một nhóm.

Nếu việc triển khai thiết bị bao gồm điện thoại GSM nhưng không bao gồm điện thoại CDMA, thì thiết bị đó:

[C-9-1] KHÔNG ĐƯỢC khai báo PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] PHẢI gửi một IllegalArgumentException khi cố gắng đặt bất kỳ loại mạng 3GPP2 nào trong mặt nạ bit loại mạng ưu tiên hoặc được cho phép.
[C-9-3] PHẢI trả về một chuỗi trống từ TelephonyManager#getMeid.

Nếu việc triển khai thiết bị hỗ trợ eUICC có nhiều cổng và hồ sơ, thì các thiết bị đó:

[C-10-1] PHẢI khai báo cờ tính năng android.hardware.telephony.euicc.mep.

7.4.1.1. Khả năng tương thích với tính năng Chặn số

Nếu việc triển khai thiết bị báo cáo tính năng android.hardware.telephony.calling, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ tính năng chặn số
[C-1-2] PHẢI triển khai đầy đủ BlockedNumberContract và API tương ứng như mô tả trong tài liệu SDK.
[C-1-3] PHẢI chặn tất cả cuộc gọi và tin nhắn từ một số điện thoại trong "BlockedNumberProvider" mà không có bất kỳ hoạt động tương tác nào với ứng dụng. Trường hợp ngoại lệ duy nhất là khi việc chặn số tạm thời được gỡ bỏ như mô tả trong tài liệu SDK.
[C-1-4] PHẢI ghi vào nhà cung cấp nhật ký cuộc gọi của nền tảng cho một cuộc gọi bị chặn và PHẢI lọc các cuộc gọi bằng BLOCKED_TYPE ra khỏi chế độ xem nhật ký cuộc gọi mặc định trong ứng dụng quay số được cài đặt sẵn.
[C-1-5] KHÔNG ĐƯỢC ghi vào Nhà cung cấp dịch vụ điện thoại cho một tin nhắn bị chặn.
[C-1-6] PHẢI triển khai giao diện người dùng quản lý số điện thoại bị chặn. Giao diện này được mở bằng ý định do phương thức TelecomManager.createManageBlockedNumbersIntent() trả về.
[C-1-7] KHÔNG ĐƯỢC cho phép người dùng phụ xem hoặc chỉnh sửa các số điện thoại bị chặn trên thiết bị vì nền tảng Android giả định rằng người dùng chính có toàn quyền kiểm soát các dịch vụ điện thoại, một phiên bản duy nhất trên thiết bị. Tất cả giao diện người dùng liên quan đến việc chặn PHẢI được ẩn đối với người dùng phụ và danh sách người dùng bị chặn PHẢI được tuân thủ.
NÊN di chuyển các số bị chặn vào nhà cung cấp khi thiết bị cập nhật lên Android 7.0.
NÊN cung cấp cho người dùng khả năng hiển thị các cuộc gọi bị chặn trong ứng dụng quay số được cài đặt sẵn.

7.4.1.2. Telecom API

Nếu quá trình triển khai thiết bị báo cáo android.hardware.telephony.calling, thì các quá trình đó:

[C-1-1] PHẢI hỗ trợ các API ConnectionService được mô tả trong SDK.
[C-1-2] PHẢI hiển thị cuộc gọi đến mới và cung cấp cho người dùng khả năng chấp nhận hoặc từ chối cuộc gọi đến khi người dùng đang thực hiện cuộc gọi do ứng dụng bên thứ ba thực hiện và ứng dụng đó không hỗ trợ tính năng giữ cuộc gọi được chỉ định thông qua CAPABILITY_SUPPORT_HOLD.
[C-1-3] PHẢI có một ứng dụng triển khai InCallService.
[C-SR-1] NÊN thông báo cho người dùng rằng việc trả lời cuộc gọi đến sẽ làm gián đoạn cuộc gọi đang diễn ra.

Việc triển khai AOSP đáp ứng các yêu cầu này bằng một thông báo quan trọng cho người dùng biết rằng việc trả lời cuộc gọi đến sẽ khiến cuộc gọi khác bị bỏ qua.
[C-SR-2] Bạn NÊN tải trước ứng dụng quay số mặc định cho thấy mục nhập nhật ký cuộc gọi và tên của ứng dụng bên thứ ba trong nhật ký cuộc gọi khi ứng dụng bên thứ ba đặt khoá bổ sung EXTRA_LOG_SELF_MANAGED_CALLS trên PhoneAccount thành true.
[C-SR-3] Bạn NÊN xử lý các sự kiện KEYCODE_MEDIA_PLAY_PAUSE và KEYCODE_HEADSETHOOK của tai nghe âm thanh cho các API android.telecom như bên dưới:
- Gọi Connection.onDisconnect() khi phát hiện thấy một sự kiện nhấn phím ngắn trong cuộc gọi đang diễn ra.
- Gọi Connection.onAnswer() khi phát hiện thấy một sự kiện nhấn phím ngắn trong cuộc gọi đến.
- Gọi Connection.onReject() khi phát hiện thấy sự kiện nhấn và giữ phím trong cuộc gọi đến.
- Bật/tắt trạng thái tắt tiếng của CallAudioState.

7.4.1.3. Chuyển tải tính năng duy trì hoạt động NAT-T của mạng di động

Triển khai trên thiết bị:

NÊN hỗ trợ tính năng giảm tải keepalive trên mạng di động.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ giảm tải tính năng duy trì kết nối di động và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ SocketKeepAlive API.
[C-1-2] PHẢI hỗ trợ ít nhất một khe keepalive đồng thời qua mạng di động.
[C-1-3] PHẢI hỗ trợ nhiều khe keepalive di động đồng thời như được hỗ trợ bởi HAL của đài phát thanh di động.
[C-SR-1] Bạn RẤT NÊN hỗ trợ ít nhất 3 khe giữ kết nối di động cho mỗi phiên bản radio.

Nếu quá trình triển khai thiết bị không hỗ trợ tính năng giảm tải keepalive qua mạng di động, thì các thiết bị đó:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Triển khai trên thiết bị:

PHẢI hỗ trợ một hoặc nhiều dạng 802.11.

Nếu quá trình triển khai thiết bị bao gồm tính năng hỗ trợ 802.11 và hiển thị chức năng cho ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] BẮT BUỘC phải triển khai API Android tương ứng.
[C-1-2] PHẢI báo cáo cờ tính năng phần cứng android.hardware.wifi.
[C-1-3] PHẢI triển khai multicast API như mô tả trong tài liệu SDK.

Bắt đầu yêu cầu mới

[C-1-4] PHẢI hỗ trợ DNS đa địa chỉ (mDNS) và KHÔNG ĐƯỢC lọ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ừ phi khoá đa địa chỉ không được giữ và các gói được lọc bằng APF. Các gói này không bắt buộc phải đáp ứng bất kỳ thao tác mDNS nào mà các ứng dụng hiện yêu cầu thông qua API NsdManager. Tuy nhiên, thiết bị CÓ THỂ lọc các gói mDNS nếu cần thiết để duy trì trong phạm vi tiêu thụ điện năng theo yêu cầu của các quy định áp dụng cho thị trường mục tiêu.
Ngay cả khi màn hình không ở trạng thái đang hoạt động.

Đối với việc triển khai thiết bị Android Television, ngay cả khi ở trạng thái nguồn điện ở chế độ chờ.
[C-1-5] KHÔNG ĐƯỢC coi lệnh gọi phương thức API WifiManager.enableNetwork() là chỉ báo đầy đủ để chuyển đổi Network đang hoạt động được sử dụng theo mặc định cho lưu lượng truy cập ứng dụng và được các phương thức API ConnectivityManager trả về, chẳng hạn như getActiveNetwork và registerDefaultNetworkCallback. Nói cách khác, nhà cung cấp dịch vụ có THỂ chỉ tắt quyền truy cập Internet do bất kỳ nhà cung cấp mạng nào khác cung cấp (ví dụ: dữ liệu di động) nếu họ xác thực thành công rằng mạng Wi-Fi đang cung cấp quyền truy cập Internet.
[C-1-6] KHUYẾN KHÍCH mạnh mẽ việc đánh giá lại quyền truy cập Internet trên Network khi phương thức API ConnectivityManager.reportNetworkConnectivity() được gọi và sau khi quá trình đánh giá xác định rằng Network hiện tại không còn cung cấp quyền truy cập Internet, hãy chuyển sang bất kỳ mạng nào khác có sẵn (ví dụ: dữ liệu di động) cung cấp quyền truy cập Internet.
[C-1-7] PHẢI tạo địa chỉ MAC nguồn và số thứ tự của các khung yêu cầu thăm dò ngẫu nhiên, một lần ở đầu mỗi lần quét, trong khi STA bị ngắt kết nối.
[C-1-8] PHẢI sử dụng một địa chỉ MAC nhất quán (KHÔNG ĐƯỢC tạo địa chỉ MAC ngẫu nhiên giữa chừng trong quá trình quét).
[C-1-9] PHẢI lặp lại số thứ tự yêu cầu thăm dò như bình thường (tuần tự) giữa các yêu cầu thăm dò trong một lượt quét.
[C-1-10] PHẢI tạo số thứ tự yêu cầu thăm dò ngẫu nhiên giữa yêu cầu thăm dò cuối cùng của một lần quét và yêu cầu thăm dò đầu tiên của lần quét tiếp theo.
[C-SR-1] NÊN tạo địa chỉ MAC nguồn ngẫu nhiên dùng cho mọi hoạt động giao tiếp của STA với Điểm truy cập (AP) trong khi liên kết và liên kết.
- Thiết bị PHẢI sử dụng một địa chỉ MAC ngẫu nhiên khác nhau cho mỗi SSID (FQDN cho Passpoint) mà thiết bị giao tiếp.
- Thiết bị PHẢI cung cấp cho người dùng một tuỳ chọn để kiểm soát việc tạo ngẫu nhiên cho mỗi SSID (FQDN cho Passpoint) bằng các tuỳ chọn tạo ngẫu nhiên và không tạo ngẫu nhiên, đồng thời PHẢI đặt chế độ mặc định để các cấu hình Wi-Fi mới được tạo ngẫu nhiên.
[C-SR-2] Bạn NÊN sử dụng BSSID ngẫu nhiên cho mọi AP mà ứng dụng tạo.
- Địa chỉ MAC PHẢI được tạo ngẫu nhiên và duy trì cho mỗi SSID mà AP sử dụng.
- THIẾT BỊ CÓ THỂ cung cấp cho người dùng lựa chọn tắt tính năng này. Nếu cung cấp tuỳ chọn như vậy, bạn PHẢI bật tính năng ngẫu nhiên theo mặc định.

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

NÊN tắt chế độ tiết kiệm pin Wi-Fi bất cứ khi nào một ứng dụng mua khoá WIFI_MODE_FULL_HIGH_PERF hoặc khoá WIFI_MODE_FULL_LOW_LATENCY thông qua API WifiManager.createWifiLock() và WifiManager.WifiLock.acquire() và khoá đang hoạt động.
[C-3-2] Độ trễ trung bình của một vòng truyền giữa thiết bị và điểm truy cập khi thiết bị ở chế độ Khoá Wi-Fi có độ trễ thấp (WIFI_MODE_FULL_LOW_LATENCY) PHẢI nhỏ hơn độ trễ trong chế độ Khoá Wi-Fi có hiệu suất cao (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] Bạn NÊN giảm thiểu độ trễ trọn vòng Wi-Fi bất cứ khi nào Khóa độ trễ thấp (WIFI_MODE_FULL_LOW_LATENCY) được thu nạp và có hiệu lực.

Nếu việc triển khai thiết bị hỗ trợ Wi-Fi và sử dụng Wi-Fi để quét vị trí, thì các thiết bị đó:

[C-2-1] PHẢI cung cấp cho người dùng khả năng bật/tắt giá trị được đọc thông qua phương thức API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Triển khai trên thiết bị:

PHẢI hỗ trợ Wi-Fi Direct (Wi-Fi ngang hàng).

Nếu việc triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì các thiết bị đó:

[C-1-1] PHẢI triển khai API Android tương ứng như mô tả trong tài liệu SDK.
[C-1-2] PHẢI báo cáo tính năng phần cứng android.hardware.wifi.direct.
[C-1-3] PHẢI hỗ trợ hoạt động Wi-Fi thông thường.
[C-1-4] PHẢI hỗ trợ đồng thời các hoạt động Wi-Fi và Wi-Fi Direct.
[C-SR-1] NÊN tạo địa chỉ MAC nguồn ngẫu nhiên cho tất cả các kết nối Wi-Fi Direct mới tạo.

7.4.2.2. Thiết lập đường liên kết trực tiếp được tạo đường hầm qua Wi-Fi

Triển khai trên thiết bị:

PHẢI hỗ trợ Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS) như mô tả trong Tài liệu SDK Android.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ TDLS và TDLS được bật bằng WiFiManager API, thì các thiết bị đó:

[C-1-1] PHẢI khai báo hỗ trợ TDLS thông qua WifiManager.isTdlsSupported.
Chỉ NÊN sử dụng TDLS khi có thể VÀ có lợi.
NÊN có một số phương pháp phỏng đoán và KHÔNG sử dụng TDLS khi hiệu suất của phương thức này có thể kém hơn so với khi đi qua điểm truy cập Wi-Fi.

7.4.2.3. Wi-Fi Aware

Triển khai trên thiết bị:

PHẢI hỗ trợ tính năng Nhận biết Wi-Fi.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Wi-Fi Aware và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI triển khai các API WifiAwareManager như mô tả trong tài liệu SDK.
[C-1-2] PHẢI khai báo cờ tính năng android.hardware.wifi.aware.
[C-1-3] PHẢI hỗ trợ đồng thời các thao tác Wi-Fi và Wi-Fi Aware.
[C-1-4] PHẢI tạo địa chỉ giao diện quản lý Wi-Fi Aware ngẫu nhiên theo khoảng thời gian không quá 30 phút và bất cứ khi nào Wi-Fi Aware được bật, trừ phi một thao tác đo khoảng cách Aware đang diễn ra hoặc một đường dẫn dữ liệu Aware đang hoạt động (không dự kiến tạo ngẫu nhiên trong khi đường dẫn dữ liệu đang hoạt động).

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Wi-Fi Aware và Wi-Fi Location như mô tả trong Mục 7.4.2.5 và hiển thị các chức năng này cho ứng dụng bên thứ ba, thì các chức năng đó:

[C-2-1] PHẢI triển khai các API khám phá có nhận biết vị trí: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm và onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ 802.11 (Wi-Fi), thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Wi-Fi Passpoint.
[C-1-2] PHẢI triển khai các API WifiManager liên quan đến Passpoint như mô tả trong tài liệu SDK.
[C-1-3] PHẢI hỗ trợ tiêu chuẩn IEEE 802.11u, liên quan cụ thể đến việc Khám phá và lựa chọn mạng, chẳng hạn như Dịch vụ quảng cáo chung (GAS) và Giao thức truy vấn mạng truy cập (ANQP).
[C-1-4] BẮT BUỘC phải khai báo cờ tính năng android.hardware.wifi.passpoint.
[C-1-5] PHẢI tuân theo cách triển khai AOSP để khám phá, so khớp và liên kết với các mạng Passpoint.
[C-1-6] PHẢI hỗ trợ ít nhất một nhóm nhỏ các giao thức cấp phép thiết bị sau đây như được xác định trong Wi-Fi Alliance Passpoint R2: xác thực EAP-TTLS và SOAP-XML.
[C-1-7] PHẢI xử lý chứng chỉ máy chủ AAA như mô tả trong quy cách Hotspot 2.0 R3.
[C-1-8] PHẢI hỗ trợ người dùng kiểm soát việc cấp phép thông qua bộ chọn Wi-Fi.
[C-1-9] PHẢI duy trì cấu hình Passpoint sau khi khởi động lại.
[C-SR-1] Bạn NÊN hỗ trợ tính năng chấp nhận điều khoản và điều kiện.
[C-SR-2] NÊN hỗ trợ tính năng Thông tin về địa điểm.

Nếu bạn cung cấp nút chuyển chế độ kiểm soát của người dùng để tắt Passpoint trên toàn cầu, hãy triển khai:

[C-3-1] PHẢI bật Passpoint theo mặc định.

7.4.2.5. Vị trí Wi-Fi (Thời gian trọn vòng của Wi-Fi – RTT)

Triển khai trên thiết bị:

PHẢI hỗ trợ Vị trí Wi-Fi.

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ Vị trí Wi-Fi và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI triển khai các API WifiRttManager như mô tả trong tài liệu SDK.
[C-1-2] PHẢI khai báo cờ tính năng android.hardware.wifi.rtt.
[C-1-3] PHẢI tạo địa chỉ MAC nguồn ngẫu nhiên cho mỗi luồng RTT được thực thi trong khi giao diện Wi-Fi mà RTT đang được thực thi không được liên kết với một Điểm truy cập.
[C-1-4] PHẢI chính xác trong vòng 2 mét ở băng thông 80 MHz tại phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ).
[C-SR-1] Bạn NÊN báo cáo chính xác phạm vi này trong vòng 1,5 mét với băng thông 80 MHz ở phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ).

7.4.2.6. Chuyển Wi-Fi Keepalive sang chế độ tải xuống

Triển khai trên thiết bị:

PHẢI hỗ trợ tính năng giảm tải Wi-Fi keepalive.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ giảm tải Wi-Fi keepalive và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ API SocketKeepAlive.
[C-1-2] PHẢI hỗ trợ ít nhất 3 khe keepalive đồng thời qua Wi-Fi

Nếu việc triển khai thiết bị không hỗ trợ tính năng giảm tải Wi-Fi keepalive, thì các thiết bị đó:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (Giao thức cấp phép thiết bị)

Triển khai trên thiết bị:

PHẢI hỗ trợ Kết nối Wi-Fi dễ dàng (DPP).

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Wi-Fi Easy Connect và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI có phương thức WifiManager#isEasyConnectSupported() trả về true.

7.4.2.8. Xác thực chứng chỉ máy chủ Wi-Fi doanh nghiệp

Nếu chứng chỉ máy chủ Wi-Fi không được xác thực hoặc tên miền của máy chủ Wi-Fi không được đặt, thì việc triển khai thiết bị sẽ:

[C-SR-1] KHÔNG NÊN cung cấp cho người dùng tuỳ chọn thêm Mạng Wi-Fi doanh nghiệp theo cách thủ công trong ứng dụng Cài đặt.

7.4.2.9. Tin cậy vào lần sử dụng đầu tiên (TOFU)

Nếu việc triển khai thiết bị hỗ trợ tính năng Tin cậy khi sử dụng lần đầu (TOFU) và cho phép người dùng xác định cấu hình WPA/WPA2/WPA3-Enterprise, thì họ:

[C-4-1] PHẢI cung cấp cho người dùng một lựa chọn để sử dụng TOFU.

7.4.3. Bluetooth

Nếu việc triển khai thiết bị hỗ trợ hồ sơ Âm thanh Bluetooth, thì các thiết bị đó:

PHẢI hỗ trợ Bộ mã hoá và giải mã âm thanh nâng cao và Bộ mã hoá và giải mã âm thanh Bluetooth (ví dụ: LDAC)

Nếu việc triển khai thiết bị hỗ trợ HFP, A2DP và AVRCP, thì các thiết bị đó:

PHẢI hỗ trợ ít nhất 5 thiết bị được kết nối.

Nếu quá trình triển khai thiết bị khai báo tính năng android.hardware.vr.high_performance, thì các quá trình đó:

[C-1-1] PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data Length Extension.

Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp.

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ Bluetooth và Bluetooth Năng lượng thấp, thì các thiết bị đó:

[C-2-1] PHẢI khai báo các tính năng nền tảng có liên quan (tương ứng là android.hardware.bluetooth và android.hardware.bluetooth_le) và triển khai các API nền tảng.
NÊN triển khai các hồ sơ Bluetooth có liên quan như A2DP, AVRCP, OBEX, HFP, v.v. cho phù hợp với thiết bị.

Nếu triển khai hỗ trợ Bluetooth năng lượng thấp (BLE) trên thiết bị, thì các thiết bị đó:

[C-3-1] PHẢI khai báo tính năng phần cứng android.hardware.bluetooth_le.
[C-3-2] PHẢI bật các API Bluetooth dựa trên GATT (hồ sơ thuộc tính chung) như mô tả trong tài liệu SDK và android.bluetooth.
[C-3-3] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isOffloadedFilteringSupported() để cho biết liệu logic lọc cho các lớp API ScanFilter có được triển khai hay không.
[C-3-4] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isMultipleAdvertisementSupported() để cho biết liệu có hỗ trợ Quảng cáo tiết kiệm năng lượng hay không.
[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 vòng địa chỉ tại thời điểm 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 chủ động 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 tạo ngẫu nhiên trong khoảng từ 5 đến 15 phút.
NÊN hỗ trợ việc giảm tải logic lọc cho bộ vi mạch Bluetooth khi triển khai ScanFilter API.
NÊN hỗ trợ việc chuyển quá trình quét hàng loạt sang chipset Bluetooth.
PHẢI hỗ trợ nhiều quảng cáo với ít nhất 4 vị trí.

Nếu việc triển khai thiết bị hỗ trợ Bluetooth LE và sử dụng Bluetooth LE để quét vị trí, thì các thiết bị đó:

[C-4-1] PHẢI cung cấp cho người dùng khả năng bật/tắt giá trị được đọc thông qua API Hệ thống BluetoothAdapter.isBleScanAlwaysAvailable().

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Bluetooth LE và Hồ sơ thiết bị trợ thính, như mô tả trong phần Hỗ trợ âm thanh của thiết bị trợ thính bằng Bluetooth LE, thì các thiết bị đó:

[C-5-1] PHẢI trả về true cho BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Nếu việc triển khai thiết bị bao gồm hỗ trợ Bluetooth hoặc Bluetooth năng lượng thấp, thì các thiết bị đó:

[C-6-1] PHẢI hạn chế quyền truy cập vào mọi siêu dữ liệu Bluetooth (chẳng hạn như kết quả quét) có thể dùng để xác định vị trí của thiết bị, trừ phi ứng dụng yêu cầu đã vượt qua thành công quy trình kiểm tra quyền android.permission.ACCESS_FINE_LOCATION dựa trên trạng thái nền trước/nền hiện tại của ứng dụng.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ Bluetooth hoặc Bluetooth năng lượng thấp và tệp kê khai ứng dụng không có nội dung khai báo của nhà phát triển cho biết rằng họ không lấy thông tin vị trí từ Bluetooth, thì họ:

[C-6-2] PHẢI kiểm soát quyền truy cập Bluetooth qua android.permission.ACCESS_FINE_LOCATION.

Nếu quá trình triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioSupported(), thì các quá trình đó:

[C-7-1] PHẢI hỗ trợ ứng dụng unicast.
[C-7-2] PHẢI hỗ trợ PHY 2M.
[C-7-3] PHẢI hỗ trợ quảng cáo Mở rộng LE.
[C-7-4] PHẢI hỗ trợ ít nhất 2 kết nối CIS trong một CIG.
[C-7-5] PHẢI bật đồng thời ứng dụng unicast BAP, bộ điều phối nhóm CSIP, máy chủ MCP, trình điều khiển VCP, máy chủ CCP.
[C-SR-1] Bạn NÊN bật ứng dụng unicast HAP.

Nếu quá trình triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), thì các quá trình đó:

[C-8-1] PHẢI hỗ trợ ít nhất 2 đường liên kết BIS trong một BIG.
[C-8-2] PHẢI bật nguồn truyền tin BAP, trợ lý truyền tin BAP đồng thời.
[C-8-3] PHẢI hỗ trợ quảng cáo định kỳ LE.

Nếu quá trình triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), thì các quá trình đó:

[C-9-1] PHẢI hỗ trợ tính năng PAST (Chuyển dữ liệu đồng bộ hoá quảng cáo định kỳ).
[C-9-2] PHẢI hỗ trợ quảng cáo định kỳ LE.

Nếu các hoạt động triển khai thiết bị khai báo FEATURE_BLUETOOTH_LE, thì các hoạt động đó:

[C-10-1] PHẢI có kết quả đo RSSI nằm trong khoảng +/-9dB đối với 95% số lần đo ở khoảng cách 1m từ thiết bị tham chiếu truyền ở ADVERTISE_TX_POWER_HIGH trong môi trường có tầm nhìn trực tiếp.
[C-10-2] PHẢI bao gồm các giá trị sửa lỗi Rx/Tx để giảm độ lệch trên mỗi kênh để các phép đo trên mỗi trong số 3 kênh, trên mỗi ăng-ten (nếu sử dụng nhiều ăng-ten) nằm trong phạm vi +/-3dB so với nhau trong 95% số phép đo.
[C-SR-2] Bạn NÊN đo lường và bù độ lệch Rx để đảm bảo RSSI BLE trung bình là -60dBm +/-10 dB ở khoảng cách 1m từ thiết bị tham chiếu truyền tại 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 màn hình hướng về cùng một hướng.
[C-SR-3] Bạn NÊN đo lường và bù cho độ lệch Tx để đảm bảo RSSI BLE trung bình là -60dBm +/-10 dB khi quét từ một thiết bị tham chiếu ở 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 màn hình hướng về cùng một hướng.

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 lường và bù cho độ lệch 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 ở ADVERTISE_TX_POWER_HIGH.

[C-10-4] PHẢI đo lường và bù trừ độ lệch Tx để đảm bảo RSSI BLE trung bình là -55dBm +/-10 dB khi quét từ một thiết bị tham chiếu ở khoảng cách 1m và truyền ở ADVERTISE_TX_POWER_HIGH.

Bạn NÊN làm theo các bước thiết lập tính năng đo lường được chỉ định trong phần Yêu cầu về việc hiệu chuẩn sự hiện diện.

Nếu việc triển khai thiết bị hỗ trợ Bluetooth phiên bản 5.0, thì các thiết bị đó:

[C-SR-4] Bạn NÊN hỗ trợ:

LE 2M PHY

PHY bộ mã hoá và giải mã LE

Phần mở rộng quảng cáo LE

Quảng cáo định kỳ

Ít nhất 10 nhóm quảng cáo

Ít nhất 8 kết nối đồng thời LE. Mỗi kết nối có thể ở một trong hai vai trò liên kết cấu trúc liên kết.

Quyền riêng tư của lớp liên kết LE

Kích thước "danh sách phân giải" tối thiểu là 8 mục

7.4.4. Giao tiếp trường gần

Triển khai trên thiết bị:

PHẢI bao gồm bộ thu phát và phần cứng liên quan cho tính năng Giao tiếp phạm vi gần (NFC).
[C-0-1] PHẢI triển khai các API android.nfc.NdefMessage và android.nfc.NdefRecord ngay cả khi các API này không hỗ trợ NFC hoặc khai báo tính năng android.hardware.nfc vì các lớp này đại diện cho một định dạng trình bày dữ liệu độc lập với giao thức.

Nếu triển khai thiết bị bao gồm phần cứng NFC và dự định cung cấp phần cứng đó cho các ứng dụng bên thứ ba, thì thiết bị đó:

[C-1-1] PHẢI báo cáo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature().
PHẢI có khả năng đọc và ghi tin nhắn NDEF thông qua các tiêu chuẩn NFC sau đây:
[C-1-2] PHẢI có khả năng hoạt động như một trình đọc/ghi của NFC Forum (như được xác định trong quy cách kỹ thuật của NFC Forum NFCForum-TS-DigitalProtocol-1.0) thông qua các tiêu chuẩn NFC sau:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Loại thẻ NFC Forum 1, 2, 3, 4, 5 (do NFC Forum xác định)
[C-SR-1] NÊN có khả năng đọc và ghi thông báo NDEF cũng như dữ liệu thô thông qua các tiêu chuẩn NFC sau đây. Xin lưu ý rằng mặc dù các tiêu chuẩn NFC được nêu là ĐỀ XUẤT MẠNH, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai dự kiến sẽ thay đổi các tiêu chuẩn này thành PHẢI. Các tiêu chuẩn này không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị hiện tại và mới chạy phiên bản Android này nên đáp ứng các yêu cầu này ngay từ bây giờ để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-1-13] PHẢI thăm dò ý kiến về tất cả công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
PHẢI ở chế độ khám phá NFC khi thiết bị ở trạng thái thức với màn hình đang hoạt động và màn hình khoá đã mở khoá.
PHẢI có khả năng đọc mã vạch và URL (nếu được mã hoá) của sản phẩm Mã vạch NFC màng mỏng.

Xin lưu ý rằng các đường liên kết có sẵn công khai không có sẵn cho các thông số kỹ thuật của JIS, ISO và NFC Forum được trích dẫn ở trên.

Android hỗ trợ chế độ Giả lập thẻ dựa trên máy chủ (HCE) NFC.

Nếu quá trình triển khai thiết bị bao gồm một chipset bộ điều khiển NFC có thể hỗ trợ HCE (đối với NfcA và/hoặc NfcB) và hỗ trợ định tuyến Mã ứng dụng (AID), thì các thiết bị đó:

[C-2-1] PHẢI báo cáo hằng số tính năng android.hardware.nfc.hce.
[C-2-2] PHẢI hỗ trợ API HCE NFC như được xác định trong SDK Android.

Nếu việc triển khai thiết bị bao gồm một chipset bộ điều khiển NFC có thể hỗ trợ HCE cho NfcF và triển khai tính năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

[C-3-1] PHẢI báo cáo hằng số tính năng android.hardware.nfc.hcef.
[C-3-2] PHẢI triển khai API mô phỏng thẻ NfcF như được xác định trong SDK Android.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ NFC chung như mô tả trong phần này và hỗ trợ các công nghệ MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF trên MIFARE Classic) ở vai trò trình đọc/ghi, thì các thiết bị đó:

[C-4-1] PHẢI triển khai các API Android tương ứng theo tài liệu của SDK Android.
[C-4-2] PHẢI báo cáo tính năng com.nxp.mifare từ phương thức android.content.pm.PackageManager.hasSystemFeature(). Xin lưu ý rằng đây không phải là tính năng Android tiêu chuẩn và do đó không xuất hiện dưới dạng hằng số trong lớp android.content.pm.PackageManager.

7.4.5. Giao thức và API mạng

7.4.5.1. Khả năng mạng tối thiểu

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ một hoặc nhiều hình thức kết nối dữ liệu. Cụ thể, việc triển khai thiết bị PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu có tốc độ 200 Kbit/giây trở lên. Ví dụ về các công nghệ đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet và Bluetooth PAN.
CŨNG NÊN hỗ trợ ít nhất một tiêu chuẩn dữ liệu không dây phổ biến, chẳng hạn như 802.11 (Wi-Fi), khi tiêu chuẩn kết nối mạng vật lý (chẳng hạn như Ethernet) là kết nối dữ liệu chính.
CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu.

7.4.5.2. IPv6

Triển khai trên thiết bị:

[C-0-2] PHẢI bao gồm ngăn xếp mạng IPv6 và hỗ trợ giao tiếp IPv6 bằng các API được quản lý, chẳng hạn như java.net.Socket và java.net.URLConnection, cũng như các API gốc, chẳng hạn như ổ cắm AF_INET6.
[C-0-3] PHẢI bật IPv6 theo mặc định.
- PHẢI đảm bảo rằng giao tiếp IPv6 cũng đáng tin cậy như IPv4, ví dụ:
  - [C-0-4] PHẢI duy trì kết nối IPv6 ở chế độ nghỉ.
  - [C-0-5] Việc giới hạn tốc độ KHÔNG ĐƯỢC làm thiết bị mất kết nối IPv6 trên bất kỳ mạng nào tuân thủ IPv6 sử dụng thời gian hoạt động của RA tối thiểu là 180 giây.
[C-0-6] PHẢI cung cấp cho các ứng dụng bên thứ ba khả năng kết nối IPv6 trực tiếp với mạng khi kết nối với mạng IPv6, mà không có bất kỳ hình thức dịch địa chỉ hoặc cổng nào diễn ra cục bộ trên thiết bị. Cả API được quản lý như Socket#getLocalAddress hoặc Socket#getLocalPort và API NDK như getsockname() hoặc IPV6_PKTINFO đều PHẢI trả về địa chỉ IP và cổng thực sự được dùng để gửi và nhận gói trên mạng, đồng thời hiển thị dưới dạng IP nguồn và cổng đến máy chủ Internet (web).

Cấp độ hỗ trợ IPv6 bắt buộc phụ thuộc vào loại mạng, như trong các yêu cầu sau.

Nếu việc triển khai thiết bị hỗ trợ Wi-Fi, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ hoạt động chỉ IPv6 và ngăn xếp kép trên Wi-Fi.

Nếu việc triển khai thiết bị hỗ trợ Ethernet, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ hoạt động chỉ IPv6 và ngăn xếp kép trên Ethernet.

Nếu việc triển khai thiết bị hỗ trợ Dữ liệu di động, thì các thiết bị đó:

[C-3-1] PHẢI hỗ trợ hoạt động IPv6 (chỉ IPv6 và có thể là ngăn xếp kép) trên mạng di động.

Nếu việc triển khai thiết bị hỗ trợ nhiều loại mạng (ví dụ: Wi-Fi và dữ liệu di động), thì:

[C-4-1] PHẢI đồng thời đáp ứng các yêu cầu trên trên mỗi mạng khi thiết bị đồng thời kết nối với nhiều loại mạng.

7.4.5.3. Trang xác thực

Trang xác thực là một mạng yêu cầu đăng nhập để truy cập Internet.

Nếu các phương thức triển khai thiết bị cung cấp phương thức triển khai đầy đủ của android.webkit.Webview API, thì các phương thức đó:

[C-1-1] PHẢI cung cấp ứng dụng trang xác thực để xử lý ý định ACTION_CAPTIVE_PORTAL_SIGN_IN và hiển thị trang đăng nhập trang xác thực bằng cách gửi ý định đó khi gọi đến API Hệ thống ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] PHẢI phát hiện cổng thông tin truy cập và hỗ trợ đăng nhập qua ứng dụng cổng thông tin truy cập khi thiết bị kết nối với bất kỳ loại mạng nào, bao gồm cả mạng di động/mạng di động, Wi-Fi, Ethernet hoặc Bluetooth.
[C-1-3] PHẢI hỗ trợ đăng nhập vào cổng truy cập bằng DNS văn bản thô khi thiết bị được định cấu hình để sử dụng chế độ nghiêm ngặt của DNS riêng.
[C-1-4] PHẢI sử dụng DNS đã mã hoá theo tài liệu SDK cho android.net.LinkProperties.getPrivateDnsServerName và android.net.LinkProperties.isPrivateDnsActive đối với tất cả lưu lượng truy cập mạng không giao tiếp rõ ràng với cổng truy cập.
[C-1-5] PHẢI đảm bảo rằng trong khi người dùng đăng nhập vào cổng truy cập nội bộ, mạng mặc định mà các ứng dụng sử dụng (do ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback trả về và được các API kết nối mạng Java như java.net.Socket và các API gốc như connect()) là bất kỳ mạng nào khác có sẵn cung cấp quyền truy cập Internet (nếu có).

7.4.6. Cài đặt đồng bộ hóa

Triển khai trên thiết bị:

[C-0-1] PHẢI bật chế độ cài đặt tự động đồng bộ hoá chính theo mặc định để phương thức getMasterSyncAutomatically() trả về "true".

7.4.7. Trình tiết kiệm dữ liệu

Nếu việc triển khai thiết bị bao gồm một kết nối có đo lượng dữ liệu, thì đó là:

[C-SR-1] BẠN NÊN cung cấp chế độ tiết kiệm dữ liệu.

Nếu việc triển khai thiết bị cung cấp chế độ tiết kiệm dữ liệu, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ tất cả API trong lớp ConnectivityManager như mô tả trong tài liệu SDK

Nếu không cung cấp chế độ tiết kiệm dữ liệu, thì các hoạt động triển khai thiết bị sẽ:

[C-2-1] PHẢI trả về giá trị RESTRICT_BACKGROUND_STATUS_DISABLED cho ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] KHÔNG ĐƯỢC truyền phát ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Phần tử bảo mật

Nếu việc triển khai thiết bị hỗ trợ các phần tử bảo mật có khả năng sử dụng Open Mobile API và cung cấp các phần tử đó cho ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] PHẢI liệt kê các trình đọc phần tử bảo mật hiện có thông qua API android.se.omapi.SEService.getReaders().
[C-1-2] PHẢI khai báo cờ tính năng chính xác thông qua android.hardware.se.omapi.uicc cho thiết bị có phần tử bảo mật dựa trên UICC, android.hardware.se.omapi.ese cho thiết bị có phần tử bảo mật dựa trên eSE và android.hardware.se.omapi.sd cho thiết bị có phần tử bảo mật dựa trên SD.

7.4.9. UWB (băng tần siêu rộng)

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ 802.1.15.4 và hiển thị chức năng này cho ứng dụng bên thứ ba, thì các thiết bị đó:

[C-1-1] BẮT BUỘC phải triển khai API Android tương ứng trong android.uwb.
[C-1-2] PHẢI báo cáo cờ tính năng phần cứng android.hardware.uwb.
[C-1-3] PHẢI hỗ trợ tất cả hồ sơ UWB có liên quan được xác định trong quá trình triển khai Android.
[C-1-4] PHẢI cung cấp cho người dùng một chức năng để cho phép người dùng bật/tắt trạng thái vô tuyến UWB.
[C-1-5] PHẢI thực thi việc các ứng dụng sử dụng đài UWB phải có quyền UWB_RANGING (trong nhóm quyền NEARBY_DEVICES).
[C-SR-1] Bạn NÊN vượt qua các bài kiểm thử chứng nhận và tuân thủ liên quan do các tổ chức tiêu chuẩn xác định, bao gồm cả FIRA, CCC và CSA.
[C-1-6] PHẢI đảm bảo các phép đo khoảng cách nằm trong phạm vi +/-15 cm đối với 95% số phép đo trong môi trường đường ngắm ở khoảng cách 1 m trong buồng không phản chiếu.
[C-1-7] PHẢI đảm bảo rằng giá trị trung bình của các phép đo khoảng cách ở 1m từ thiết bị tham chiếu nằm trong khoảng [0,75m, 1,25m], trong đó khoảng cách thực tế được đo từ cạnh trên của DUT. ~~được giữ hướng lên trên và nghiêng 45 độ.~~
[C-SR-2] Bạn NÊN làm theo các bước thiết lập tính năng đo lường được chỉ định trong Các yêu cầu về việc hiệu chuẩn sự hiện diện.

7.5. Camera

Nếu việc triển khai thiết bị bao gồm ít nhất một máy ảnh, thì các thiết bị đó:

[C-1-1] BẮT BUỘC phải khai báo cờ tính năng android.hardware.camera.any.
[C-1-2] Ứng dụng PHẢI có thể đồng thời phân bổ 3 bitmap RGBA_8888 bằng kích thước của hình ảnh do cảm biến máy ảnh có độ phân giải lớn nhất trên thiết bị tạo ra, trong khi máy ảnh đang mở để xem trước cơ bản và chụp ảnh tĩnh.
[C-1-3] PHẢI đảm bảo rằng ứng dụng máy ảnh mặc định được cài đặt sẵn xử lý các ý định MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE hoặc MediaStore.ACTION_VIDEO_CAPTURE, chịu trách nhiệm xoá vị trí của người dùng trong siêu dữ liệu hình ảnh trước khi gửi đến ứng dụng nhận khi ứng dụng nhận không có ACCESS_FINE_LOCATION.

Nếu việc triển khai thiết bị hỗ trợ khả năng đầu ra HDR 10 bit, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ ít nhất hồ sơ HDR HLG cho mọi thiết bị máy ảnh hỗ trợ đầu ra 10 bit.
[C-2-2] PHẢI hỗ trợ đầu ra 10 bit cho camera chính mặt sau hoặc camera chính mặt trước.
[C-SR-1] NÊN hỗ trợ đầu ra 10 bit cho cả hai máy ảnh chính.
[C-2-3] PHẢI hỗ trợ cùng một hồ sơ HDR cho tất cả camera phụ thực có khả năng BACKWARD_COMPATIBLE của một camera logic và chính camera logic đó.

Đối với các thiết bị máy ảnh Logic hỗ trợ HDR 10 bit triển khai API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, các thiết bị này:

[C-3-1] PHẢI hỗ trợ việc chuyển đổi giữa tất cả các máy ảnh thực có khả năng tương thích ngược thông qua chế độ điều khiển CONTROL_ZOOM_RATIO trên máy ảnh logic.

7.5.1. Camera sau

Máy ảnh mặt sau là máy ảnh nằm ở cạnh thiết bị đối diện với màn hình; tức là máy ảnh này chụp hình các cảnh ở phía xa của thiết bị, giống như máy ảnh truyền thống.

Bắt đầu yêu cầu mới

Máy ảnh mặt sau là máy ảnh quay ra ngoài, chụp ảnh các cảnh ở phía xa của thiết bị, giống như máy ảnh truyền thống; trên các thiết bị cầm tay, đó là máy ảnh nằm ở cạnh của thiết bị đối diện với màn hình.

Kết thúc các yêu cầu mới

Triển khai trên thiết bị:

PHẢI có camera mặt sau.

Nếu việc triển khai thiết bị bao gồm ít nhất một máy ảnh mặt sau, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera và android.hardware.camera.any.
[C-1-2] PHẢI có độ phân giải tối thiểu là 2 megapixel.
PHẢI triển khai tính năng tự động lấy nét 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 (trong suốt đối với phần mềm ứng dụng).
CÓ THỂ có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường mở rộng).
CÓ THỂ có đèn flash.

Nếu máy ảnh có đèn flash:

[C-2-1] Đèn flash KHÔNG ĐƯỢC sáng trong khi một thực thể android.hardware.Camera.PreviewCallback đã được đăng ký trên một nền tảng xem trước của Máy ảnh, trừ phi ứng dụng đã bật đèn flash một cách rõ ràng bằng cách bật các thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON của đối tượng Camera.Parameters. Xin lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng máy ảnh hệ thống tích hợp sẵn của thiết bị, mà chỉ áp dụng cho các ứng dụng bên thứ ba sử dụng Camera.PreviewCallback.

7.5.2. Camera mặt trước

Máy ảnh mặt trước là máy ảnh nằm ở cùng một bên của thiết bị với màn hình; tức là máy ảnh thường dùng để chụp ảnh người dùng, chẳng hạn như cho hội nghị truyền hình và các ứng dụng tương tự.

Bắt đầu yêu cầu mới

Máy ảnh mặt trước là máy ảnh hướng về phía người dùng, thường dùng để chụp ảnh người dùng, chẳng hạn như cho hội nghị truyền hình và các ứng dụng tương tự; trên thiết bị cầm tay, đó là máy ảnh nằm ở cùng một bên của thiết bị với màn hình.

Kết thúc các yêu cầu mới

Triển khai trên thiết bị:

CÓ THỂ có máy ảnh mặt trước.

Nếu việc triển khai thiết bị bao gồm ít nhất một máy ảnh mặt trước, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera.any và android.hardware.camera.front.
[C-1-2] PHẢI có độ phân giải tối thiểu là VGA (640x480 pixel).
[C-1-3] KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm mặc định cho Camera API và KHÔNG ĐƯỢC định cấu hình API để coi máy ảnh mặt trước là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị.
[C-1-4] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng do ứng dụng chỉ định khi ứng dụng hiện tại yêu cầu rõ ràng rằng màn hình Máy ảnh phải được xoay thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation(). Ngược lại, bản xem trước PHẢI được phản chiếu dọc theo trục ngang mặc định của thiết bị khi ứng dụng hiện tại không yêu cầu rõ ràng việc xoay màn hình Máy ảnh thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation().
[C-1-5] KHÔNG ĐƯỢC phản ánh luồng hình ảnh tĩnh hoặc video đã chụp cuối cùng được trả về lệnh gọi lại của ứng dụng hoặc được cam kết lưu vào bộ nhớ phương tiện.
[C-1-6] PHẢI phản chiếu hình ảnh do postview hiển thị theo cách tương tự như luồng hình ảnh xem trước của máy ảnh.
CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, đèn flash, v.v.) có sẵn cho máy ảnh mặt sau như mô tả trong phần 7.5.1.

Nếu người dùng có thể xoay chế độ triển khai thiết bị (chẳng hạn như tự động thông qua gia tốc kế hoặc theo cách thủ công thông qua dữ liệu đầu vào của người dùng):

[C-2-1] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng hiện tại của thiết bị.

7.5.3. Máy ảnh gắn ngoài

Bắt đầu yêu cầu mới

Máy ảnh bên ngoài là máy ảnh có thể được gắn hoặc tháo rời khỏi quá trình triển khai thiết bị bất cứ lúc nào và có thể hướng về bất kỳ hướng nào; chẳng hạn như máy ảnh USB.

Kết thúc các yêu cầu mới

Triển khai trên thiết bị:

CÓ THỂ hỗ trợ máy ảnh bên ngoài không nhất thiết phải luôn kết nối.

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ máy ảnh bên ngoài, thì các thiết bị đó:

[C-1-1] PHẢI khai báo cờ tính năng nền tảng android.hardware.camera.external và android.hardware camera.any.
[C-1-2] PHẢI hỗ trợ USB Video Class (UVC 1.0 trở lên) nếu máy ảnh bên ngoài kết nối thông qua cổng máy chủ USB.
[C-1-3] PHẢI vượt qua các bài kiểm thử CTS của máy ảnh khi kết nối với một thiết bị máy ảnh bên ngoài thực tế. Bạn có thể xem thông tin chi tiết về quy trình kiểm thử CTS của máy ảnh tại source.android.com.
PHẢI hỗ trợ các phương thức nén video như MJPEG để cho phép chuyển các luồng chưa mã hoá chất lượng cao (tức là luồng hình ảnh thô hoặc được nén độc lập).
CÓ THỂ hỗ trợ nhiều máy ảnh.
CÓ THỂ hỗ trợ mã hoá video dựa trên máy ảnh.

Nếu tính năng mã hoá video dựa trên máy ảnh được hỗ trợ:

[C-2-1] Phải truy cập được luồng không mã hoá / MJPEG đồng thời (độ phân giải QVGA trở lên) để triển khai thiết bị.

7.5.4. Hành vi của Camera API

Android bao gồm hai gói API để truy cập vào máy ảnh, API android.hardware.camera2 mới hơn hiển thị chế độ điều khiển máy ảnh cấp thấp cho ứng dụng, bao gồm cả các luồng chụp/truyền trực tuyến không sao chép hiệu quả và các chế độ điều khiển theo khung hình của độ phơi sáng, độ lợi, độ lợi cân bằng trắng, chuyển đổi màu, loại bỏ nhiễu, làm sắc nét và nhiều chế độ khác.

Gói API cũ,android.hardware.Camera, được đánh dấu là không dùng nữa trong Android 5.0 nhưng vẫn có sẵn để các ứng dụng sử dụng. Việc triển khai thiết bị Android PHẢI đảm bảo tiếp tục hỗ trợ API như mô tả trong phần này và trong SDK Android.

Tất cả các tính năng phổ biến giữa lớp android.hardware.Camera không dùng nữa và gói android.hardware.camera2 mới hơn PHẢI có hiệu suất và chất lượng tương đương trong cả hai API. Ví dụ: với các chế độ cài đặt tương đương, tốc độ và độ chính xác của tính năng tự động lấy nét phải giống nhau và chất lượng của hình ảnh được chụp phải giống nhau. Các tính năng phụ thuộc vào ngữ nghĩa khác nhau của hai API không bắt buộc phải có tốc độ hoặc chất lượng khớp nhau, nhưng PHẢI khớp gần nhất có thể.

Việc triển khai thiết bị PHẢI triển khai các hành vi sau đây cho các API liên quan đến máy ảnh, cho tất cả máy ảnh có sẵn. Triển khai trên thiết bị:

[C-0-1] PHẢI sử dụng android.hardware.PixelFormat.YCbCr_420_SP cho dữ liệu xem trước được cung cấp cho lệnh gọi lại ứng dụng khi ứng dụng chưa bao giờ gọi android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] PHẢI ở định dạng mã hoá NV21 khi một ứng dụng đăng ký một thực thể android.hardware.Camera.PreviewCallback và hệ thống gọi phương thức onPreviewFrame() và định dạng xem trước là YCbCr_420_SP, dữ liệu trong byte[] được chuyển vào onPreviewFrame(). Tức là NV21 PHẢI là giá trị mặc định.
[C-0-3] PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số android.graphics.ImageFormat.YV12) cho bản xem trước của máy ảnh cho cả máy ảnh mặt trước và mặt sau cho android.hardware.Camera. (Máy ảnh và bộ mã hoá video phần cứng có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng việc triển khai thiết bị PHẢI hỗ trợ chuyển đổi sang YV12.)
[C-0-4] PHẢI hỗ trợ các định dạng android.hardware.ImageFormat.YUV_420_888 và android.hardware.ImageFormat.JPEG dưới dạng đầu ra thông qua API android.media.ImageReader cho các thiết bị android.hardware.camera2 quảng cáo chức năng REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE trong android.request.availableCapabilities.
[C-0-5] VẪN PHẢI triển khai đầy đủ Camera API có trong tài liệu SDK Android, bất kể thiết bị có tính năng tự động lấy nét bằng phần cứng hay các tính năng khác. Ví dụ: các máy ảnh không có tính năng tự động lấy nét VẪN PHẢI gọi mọi thực thể android.hardware.Camera.AutoFocusCallback đã đăng ký (mặc dù điều này không liên quan đến máy ảnh không có tính năng tự động lấy nét). Xin lưu ý rằng điều này áp dụng cho máy ảnh mặt trước; ví dụ: mặc dù hầu hết máy ảnh mặt trước không hỗ trợ tự động lấy nét, nhưng các lệnh gọi lại API vẫn phải được "giả mạo" như mô tả.
[C-0-6] PHẢI nhận dạng và tuân thủ từng tên tham số được xác định là hằng số trong lớp android.hardware.Camera.Parameters và lớp android.hardware.camera2.CaptureRequest. Ngược lại, việc triển khai thiết bị KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số chuỗi được truyền đến phương thức android.hardware.Camera.setParameters(), ngoại trừ các hằng số được ghi nhận là hằng số trên android.hardware.Camera.Parameters. Tức là, việc triển khai thiết bị PHẢI hỗ trợ tất cả các thông số Máy ảnh chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại thông số Máy ảnh tuỳ chỉnh. Ví dụ: các hoạt động triển khai thiết bị hỗ trợ chụp ảnh bằng kỹ thuật hình ảnh dải động cao (HDR) PHẢI hỗ trợ thông số máy ảnh Camera.SCENE_MODE_HDR.
[C-0-7] PHẢI báo cáo cấp độ hỗ trợ thích hợp bằng thuộc tính android.info.supportedHardwareLevel như mô tả trong SDK Android và báo cáo cờ tính năng khung thích hợp.
[C-0-8] CŨNG PHẢI khai báo các chức năng máy ảnh riêng lẻ của android.hardware.camera2 thông qua thuộc tính android.request.availableCapabilities và khai báo cờ tính năng thích hợp; PHẢI xác định cờ tính năng nếu bất kỳ thiết bị máy ảnh nào được đính kèm hỗ trợ tính năng đó.
[C-0-9] PHẢI truyền phát ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một bức ảnh mới và mục nhập của bức ảnh đó đã được thêm vào kho phương tiện.
[C-0-10] PHẢI truyền phát ý định Camera.ACTION_NEW_VIDEO bất cứ khi nào máy ảnh ghi lại một video mới và mục nhập của hình ảnh đã được thêm vào kho phương tiện.
[C-0-11] PHẢI có tất cả máy ảnh có thể truy cập được thông qua API android.hardware.Camera không dùng nữa cũng có thể truy cập được thông qua API android.hardware.camera2.
[C-0-12] PHẢI đảm bảo rằng giao diện khuôn mặt KHÔNG bị thay đổi, bao gồm nhưng không giới hạn ở việc thay đổi hình dạng khuôn mặt, màu da khuôn mặt hoặc làm mịn da mặt cho bất kỳ API android.hardware.camera2 hoặc android.hardware.Camera nào.
[C-SR-1] Đối với các thiết bị có nhiều máy ảnh RGB ở gần nhau và hướng về cùng một hướng, bạn NÊN hỗ trợ thiết bị máy ảnh logic liệt kê chức năng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, bao gồm tất cả các máy ảnh RGB hướng về hướng đó dưới dạng thiết bị phụ thực.

Nếu việc triển khai thiết bị cung cấp API máy ảnh độc quyền cho các ứng dụng bên thứ ba, thì các API đó:

[C-1-1] PHẢI triển khai API máy ảnh như vậy bằng API android.hardware.camera2.
CÓ THỂ cung cấp thẻ nhà cung cấp và/hoặc tiện ích cho API android.hardware.camera2.

7.5.5. Hướng máy ảnh

Nếu việc triển khai thiết bị có máy ảnh mặt trước hoặc mặt sau, thì(các) máy ảnh đó:

[C-1-1] PHẢI được định hướng để kích thước dài của máy ảnh phù hợp với kích thước dài của màn hình. Tức 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ị; tức là áp dụng cho các thiết bị chính theo hướng ngang cũng như thiết bị chính theo hướng dọc.

Những thiết bị đáp ứng tất cả các tiêu chí sau đây sẽ được miễn tuân thủ yêu cầu trên:

Thiết bị triển khai màn hình hình học biến đổ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).

Bắt đầu yêu cầu mới

Các phương thức triển khai thiết bị mà người dùng không thể xoay, chẳng hạn như thiết bị ô tô.

Kết thúc các yêu cầu mới

7.6. Bộ nhớ và dung lượng lưu trữ

7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu

Triển khai trên thiết bị:

[C-0-1] PHẢI bao gồm một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ sử dụng để tải tệp dữ liệu xuống và các ứng dụng đó PHẢI có khả năng tải các tệp riêng lẻ có kích thước tối thiểu 100 MB xuống vị trí "bộ nhớ đệm" mặc định.

7.6.2. Bộ nhớ dùng chung của ứng dụng

Triển khai trên thiết bị:

[C-0-1] PHẢI cung cấp bộ nhớ để các ứng dụng chia sẻ, còn gọi là "bộ nhớ ngoài dùng chung", "bộ nhớ dùng chung của ứng dụng" hoặc theo đường dẫn Linux "/sdcard" mà bộ nhớ đó được gắn vào.
[C-0-2] PHẢI được định cấu hình với bộ nhớ dùng chung được gắn theo mặc định, nói cách khác là "trực tiếp", bất kể bộ nhớ được triển khai trên thành phần bộ nhớ trong hay phương tiện bộ nhớ có thể tháo rời (ví dụ: Khe cắm thẻ kỹ thuật số bảo mật).
[C-0-3] PHẢI gắn bộ nhớ dùng chung của ứng dụng trực tiếp trên đường dẫn Linux sdcard hoặc đưa vào một đường liên kết tượng trưng Linux từ sdcard đến điểm gắn thực tế.
[C-0-4] PHẢI bật bộ nhớ có giới hạn theo mặc định cho tất cả ứng dụng nhắm đến API cấp 29 trở lên, ngoại trừ trường hợp sau:
- Khi ứng dụng đã yêu cầu android:requestLegacyExternalStorage="true" trong tệp kê khai.
[C-0-5] PHẢI loại bỏ siêu dữ liệu vị trí, chẳng hạn như thẻ Exif GPS, được lưu trữ trong các tệp phương tiện khi các tệp đó được truy cập thông qua MediaStore, ngoại trừ trường hợp ứng dụng gọi có quyền ACCESS_MEDIA_LOCATION.

Việc triển khai thiết bị CÓ THỂ đáp ứng các yêu cầu trên bằng cách sử dụng một trong những cách sau:

Bộ nhớ có thể tháo rời mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ Secure Digital (SD).
Một phần bộ nhớ trong (không thể tháo rời) được triển khai trong Dự án nguồn mở Android (AOSP).

Nếu việc triển khai thiết bị sử dụng bộ nhớ có thể tháo rời để đáp ứng các yêu cầu trên, thì các thiết bị đó:

[C-1-1] PHẢI triển khai một thông báo ngắn hoặc giao diện người dùng bật lên để cảnh báo người dùng khi không có phương tiện lưu trữ nào được lắp vào khe.
[C-1-2] PHẢI bao gồm một phương tiện lưu trữ được định dạng FAT (ví dụ: thẻ SD) hoặc cho thấy trên hộp và tài liệu khác có sẵn tại thời điểm mua rằng phương tiện lưu trữ phải được mua riêng.

Nếu việc triển khai thiết bị sử dụng một phần bộ nhớ không thể tháo rời để đáp ứng các yêu cầu trên, thì các thiết bị đó:

NÊN sử dụng phương thức triển khai AOSP của bộ nhớ dùng chung của ứng dụng nội bộ.
CÓ THỂ chia sẻ bộ nhớ với dữ liệu riêng tư của ứng dụng.

Nếu việc triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, thì các thiết bị đó:

[C-3-1] PHẢI cung cấp cơ chế để truy cập vào dữ liệu trên bộ nhớ dùng chung của ứng dụng từ máy tính lưu trữ.
NÊN hiển thị nội dung từ cả hai đường dẫn bộ nhớ một cách minh bạch thông qua dịch vụ quét nội dung đa phương tiện của Android và android.provider.MediaStore.
CÓ THỂ sử dụng bộ nhớ khối lượng lớn USB, nhưng PHẢI sử dụng Giao thức truyền nội dung nghe nhìn để đáp ứng yêu cầu này.

Nếu việc triển khai thiết bị có cổng USB ở chế độ thiết bị ngoại vi USB và hỗ trợ giao thức Truyền nội dung đa phương tiện, thì các thiết bị đó:

PHẢI tương thích với máy chủ MTP Android tham chiếu, Android File Transfer.
NÊN báo cáo loại thiết bị USB là 0x00.
NÊN báo cáo tên giao diện USB là "MTP".

7.6.3. Bộ nhớ thích ứng

Nếu thiết bị dự kiến là thiết bị di động (không giống như TV), thì việc triển khai thiết bị sẽ là:

[C-SR-1] NÊN triển khai bộ nhớ có thể sử dụng ở một vị trí ổn định lâu dài, vì việc vô tình ngắt kết nối các bộ nhớ này có thể gây ra tình trạng mất/hỏng dữ liệu.

Nếu cổng thiết bị lưu trữ có thể tháo rời nằm ở vị trí ổn định lâu dài, chẳng hạn như trong ngăn pin hoặc nắp bảo vệ khác, thì việc triển khai thiết bị sẽ là:

[C-SR-2] NÊN triển khai bộ nhớ thích ứng.

7.7. USB

Nếu triển khai thiết bị có cổng USB, thì các thiết bị đó:

PHẢI hỗ trợ chế độ thiết bị ngoại vi USB và PHẢI hỗ trợ chế độ máy chủ USB.
PHẢI hỗ trợ tính năng tắt tính năng báo hiệu dữ liệu qua USB.

7.7.1. Chế độ thiết bị ngoại vi USB

Nếu việc triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ ngoại vi:

[C-1-1] Cổng PHẢI kết nối được với máy chủ USB có cổng USB loại A hoặc loại C tiêu chuẩn.
[C-1-2] PHẢI báo cáo giá trị chính xác của iSerialNumber trong mô tả thiết bị tiêu chuẩn USB thông qua android.os.Build.SERIAL.
[C-1-3] PHẢI phát hiện bộ sạc 1,5A và 3,0A theo tiêu chuẩn điện trở Type-C và PHẢI phát hiện các thay đổi trong quảng cáo nếu bộ sạc hỗ trợ USB Type-C.
[C-SR-1] Cổng PHẢI sử dụng kiểu dáng USB micro-B, micro-AB hoặc Type-C. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-SR-2] Cổng PHẢI nằm ở cuối thiết bị (theo hướng tự nhiên) hoặc bật tính năng xoay màn hình phần mềm cho tất cả ứng dụng (bao gồm cả màn hình chính) để màn hình vẽ chính xác khi thiết bị được định hướng với cổng ở dưới cùng. Bạn NÊN đáp ứng các yêu cầu này đối với các thiết bị Android hiện có và mới để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-SR-3] NÊN triển khai tính năng hỗ trợ để vẽ dòng điện 1,5 A trong tiếng chirp và lưu lượng truy cập HS như được chỉ định trong thông số kỹ thuật về sạc pin USB, bản sửa đổi 1.2. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-SR-4] KHÔNG NÊN hỗ trợ các phương thức sạc độc quyền sửa đổi điện áp Vbus ngoài mức mặc định hoặc thay đổi vai trò của bồn lưu trữ/nguồn vì điều này có thể dẫn đến các vấn đề về khả năng tương tác với sạc hoặc thiết bị hỗ trợ các phương thức Cung cấp nguồn qua USB tiêu chuẩn. Mặc dù việc này được gọi là "RẤT NÊN", nhưng trong các phiên bản Android trong tương lai, chúng tôi có thể YÊU CẦU tất cả thiết bị loại C hỗ trợ khả năng tương tác đầy đủ với bộ sạc loại C tiêu chuẩn.
[C-SR-5] NÊN hỗ trợ tính năng Cấp nguồn cho dữ liệu và hoán đổi vai trò nguồn khi chúng hỗ trợ USB Type-C và chế độ máy chủ USB.
NÊN hỗ trợ tính năng Cung cấp nguồn điện để sạc điện áp cao và hỗ trợ các Chế độ thay thế như hiển thị ra ngoài.
NÊN triển khai API và thông số kỹ thuật của Phụ kiện mở Android (AOA) như được ghi nhận trong tài liệu SDK Android.

Nếu triển khai thiết bị bao gồm cổng USB và triển khai thông số kỹ thuật AOA, thì các thiết bị đó:

[C-2-1] PHẢI khai báo hỗ trợ tính năng phần cứng android.hardware.usb.accessory.
[C-2-2] Lớp bộ nhớ khối lượng lớn USB PHẢI bao gồm chuỗi "android" ở cuối chuỗi iInterface mô tả giao diện của bộ nhớ khối lượng lớn USB

7.7.2. Chế độ máy chủ USB

Nếu việc triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ, thì các thiết bị đó:

[C-1-1] PHẢI triển khai API máy chủ USB Android như được ghi nhận trong SDK Android và PHẢI khai báo khả năng hỗ trợ tính năng phần cứng android.hardware.usb.host.
[C-1-2] PHẢI triển khai tính năng hỗ trợ để kết nối các thiết bị ngoại vi USB tiêu chuẩn, nói cách khác, các thiết bị đó PHẢI:
- Có cổng loại C trên thiết bị hoặc vận chuyển kèm theo(các) cáp điều chỉnh cổng độc quyền trên thiết bị thành cổng USB loại C tiêu chuẩn (thiết bị USB Type-C).
- Có cổng loại A trên thiết bị hoặc vận chuyển kèm theo(các) cáp điều chỉnh cổng độc quyền trên thiết bị thành cổng USB loại A tiêu chuẩn.
- Có cổng micro-AB trên thiết bị. Cổng này PHẢI đi kèm với cáp thích ứng với cổng loại A tiêu chuẩn.
[C-1-3] KHÔNG ĐƯỢC vận chuyển kèm theo bộ chuyển đổi từ cổng USB loại A hoặc cổng micro-AB sang cổng loại C (ổ cắm).
[C-SR-1] Bạn NÊN triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android.
PHẢI hỗ trợ sạc thiết bị ngoại vi USB đã kết nối khi ở chế độ máy chủ; quảng cáo dòng nguồn ít nhất là 1,5A như được chỉ định trong phần Thông số kết thúc của Thông số kỹ thuật của cáp và đầu nối USB Type-C Bản sửa đổi 1.2 cho đầu nối USB Type-C hoặc sử dụng phạm vi dòng đầu ra của Cổng sạc hạ nguồn (CDP) như được chỉ định trong Thông số kỹ thuật sạc pin USB, bản sửa đổi 1.2 cho đầu nối Micro-AB.
PHẢI triển khai và hỗ trợ các tiêu chuẩn USB Type-C.

Nếu việc triển khai thiết bị bao gồm cổng USB hỗ trợ chế độ máy chủ và lớp âm thanh USB, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ lớp USB HID.
[C-2-2] PHẢI hỗ trợ tính năng phát hiện và liên kết các trường dữ liệu HID sau đây được chỉ định trong Bảng sử dụng USB HID và Yêu cầu sử dụng lệnh thoại với các hằng số KeyEvent như bên dưới:
- Trang sử dụng (0xC) Mã sử dụng (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Trang sử dụng (0xC) Mã sử dụng (0x0E9): KEYCODE_VOLUME_UP
- Trang sử dụng (0xC) Mã sử dụng (0x0EA): KEYCODE_VOLUME_DOWN
- Trang sử dụng (0xC) Mã nhận dạng sử dụng (0x0CF): KEYCODE_VOICE_ASSIST

Nếu việc triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và Khung truy cập bộ nhớ (SAF), thì các thiết bị đó:

[C-3-1] PHẢI nhận dạng mọi thiết bị MTP (Giao thức truyền phương tiện) được kết nối từ xa và cho phép truy cập vào nội dung của các thiết bị đó thông qua ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT. .

Nếu việc triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và USB Type-C, thì các thiết bị đó:

[C-4-1] PHẢI triển khai chức năng Cổng hai vai trò như được xác định theo quy cách USB Type-C (mục 4.5.1.3.3). Đối với Cổng có vai trò kép, trên các thiết bị có giắc cắm âm thanh 3,5 mm, tính năng phát hiện bồn lưu trữ USB (chế độ máy chủ) CÓ THỂ tắt theo mặc định nhưng người dùng PHẢI có thể bật tính năng này.
[C-SR-2] NÊN hỗ trợ DisplayPort, PHẢI hỗ trợ Tốc độ dữ liệu USB SuperSpeed và NÊN hỗ trợ tính năng Cung cấp nguồn để hoán đổi vai trò dữ liệu và nguồn.
[C-SR-3] KHÔNG NÊN hỗ trợ Chế độ phụ kiện bộ chuyển đổi âm thanh như mô tả trong Phụ lục A của Bản sửa đổi 1.2 về thông số kỹ thuật của cáp và đầu nối USB Type-C.
NÊN triển khai mô hình Try.* phù hợp nhất với kiểu dáng thiết bị. Ví dụ: thiết bị cầm tay PHẢI triển khai mô hình Try.SNK.

7.8. Âm thanh

7.8.1. Micrô

Nếu việc triển khai thiết bị bao gồm micrô, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo hằng số tính năng android.hardware.microphone.
[C-1-2] PHẢI đáp ứng các yêu cầu về bản ghi âm trong mục 5.4.
[C-1-3] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
[C-SR-1] Bạn NÊN hỗ trợ tính năng ghi âm gần siêu âm như mô tả trong mục 7.8.3.

Nếu bỏ qua micrô trong quá trình triển khai thiết bị, thì các thiết bị đó:

[C-2-1] KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.microphone.
[C-2-2] BẮT BUỘC phải triển khai API ghi âm âm thanh ở chế độ không hoạt động, theo mục 7.

7.8.2. Đầu ra âm thanh

Nếu việc triển khai thiết bị bao gồm loa hoặc cổng đầu ra âm thanh/đa phương tiện cho thiết bị ngoại vi đầu ra âm thanh, chẳng hạn như giắc âm thanh 3,5 mm 4 dây hoặc cổng chế độ máy chủ USB sử dụng lớp âm thanh USB, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo hằng số tính năng android.hardware.audio.output.
[C-1-2] PHẢI đáp ứng các yêu cầu về phát âm thanh trong mục 5.5.
[C-1-3] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
[C-SR-1] NÊN hỗ trợ chế độ phát gần siêu âm như mô tả trong mục 7.8.3.

Nếu việc triển khai thiết bị không bao gồm loa hoặc cổng đầu ra âm thanh, thì các thiết bị đó:

[C-2-1] KHÔNG ĐƯỢC báo cáo tính năng android.hardware.audio.output.
[C-2-2] PHẢI triển khai các API liên quan đến Đầu ra âm thanh ở chế độ không hoạt động.

Trong mục đích của phần này, "cổng đầu ra" là một giao diện vật lý, chẳng hạn như giắc âm thanh 3,5 mm, HDMI hoặc cổng chế độ máy chủ USB có lớp âm thanh USB. Tính năng hỗ trợ đầu ra âm thanh qua các giao thức dựa trên sóng vô tuyến như Bluetooth, Wi-Fi hoặc mạng di động không đủ điều kiện để được coi là "cổng đầu ra".

7.8.2.1. Cổng âm thanh tương tự

Để tương thích với tai nghe và các phụ kiện âm thanh khác sử dụng đầu cắm âm thanh 3,5 mm trên hệ sinh thái Android, nếu việc triển khai thiết bị bao gồm một hoặc nhiều cổng âm thanh tương tự, thì các cổng đó:

[C-SR-1] NÊN có ít nhất một trong các cổng âm thanh là giắc cắm âm thanh 3,5 mm 4 dây.

Nếu việc triển khai thiết bị có giắc âm thanh 3,5 mm 4 dây, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ phát âm thanh qua tai nghe âm thanh nổi và tai nghe âm thanh nổi có micrô.
[C-1-2] PHẢI hỗ trợ giắc cắm âm thanh TRRS theo thứ tự chân cắm CTIA.
[C-1-3] PHẢI hỗ trợ tính năng phát hiện và liên kết với mã phím cho 3 dải trở kháng tương đương sau đây giữa micrô và dây dẫn nối đất trên giắc cắm âm thanh:
- 70 ohm trở xuống: KEYCODE_HEADSETHOOK
- 210-290 ohm: KEYCODE_VOLUME_UP
- 360-680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm phích cắm, nhưng chỉ sau khi tất cả các tiếp điểm trên phích cắm chạm vào các phân đoạn liên quan trên giắc cắm.
[C-1-5] PHẢI có khả năng điều khiển ít nhất 150mV ± 10% điện áp đầu ra trên impedance loa 32 ohm.
[C-1-6] PHẢI có điện áp lệch micrô trong khoảng từ 1,8V đến 2,9V.
[C-1-7] PHẢI phát hiện và liên kết với mã phím cho phạm vi điện trở tương đương sau đây giữa micrô và dây dẫn nối đất trên phích cắm âm thanh:
- 110-180 ohm: KEYCODE_VOICE_ASSIST
[C-SR-2] Bạn NÊN hỗ trợ các phích cắm âm thanh theo thứ tự chân OMTP.
[C-SR-3] Bạn NÊN hỗ trợ tính năng ghi âm từ tai nghe âm thanh nổi có micrô.

Nếu việc triển khai thiết bị có giắc âm thanh 3,5 mm 4 dây và hỗ trợ micrô, đồng thời truyền android.intent.action.HEADSET_PLUG với micrô giá trị bổ sung được đặt thành 1, thì các thiết bị đó:

[C-2-1] PHẢI hỗ trợ tính năng phát hiện micrô trên phụ kiện âm thanh đã cắm.

7.8.2.2. Cổng âm thanh kỹ thuật số

Xem Mục 2.2.1 để biết các yêu cầu dành riêng cho thiết bị.

7.8.3. Sóng siêu âm gần

Âm thanh gần siêu âm là băng tần từ 18,5 kHz đến 20 kHz.

Triển khai trên thiết bị:

PHẢI báo cáo chính xác khả năng hỗ trợ âm thanh gần siêu âm thông qua API AudioManager.getProperty như sau:

Nếu PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND là "true", thì nguồn âm thanh VOICE_RECOGNITION và UNPROCESSED PHẢI đáp ứng các yêu cầu sau:

[C-1-1] Độ nhạy trung bình của micrô trong dải tần số từ 18,5 kHz đến 20 kHz KHÔNG ĐƯỢC thấp hơn 15 dB so với độ nhạy ở tần số 2 kHz.
[C-1-2] Tỷ lệ tín hiệu/nhiễu không cân bằng của micrô trên 18,5 kHz đến 20 kHz đối với âm tần 19 kHz ở -26 dBFS PHẢI không thấp hơn 50 dB.

Nếu PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND là "true":

[C-2-1] Độ nhạy trung bình của loa trong dải tần số 18,5 kHz – 20 kHz PHẢI thấp hơn độ nhạy ở 2 kHz ít nhất 40 dB.

7.8.4. Tính toàn vẹn của tín hiệu

Triển khai trên thiết bị:

NÊN cung cấp đường dẫn tín hiệu âm thanh không bị lỗi cho cả luồng đầu vào và đầu ra trên thiết bị cầm tay, được xác định bằng việc không có lỗi nào được đo lường trong quá trình kiểm thử một phút cho mỗi đường dẫn. Kiểm thử bằng OboeTester "Kiểm thử lỗi tự động".

Quy trình kiểm thử này yêu cầu một đầu nối âm thanh vòng lặp, được sử dụng trực tiếp trong giắc cắm 3,5 mm và/hoặc kết hợp với bộ chuyển đổi USB-C sang 3,5 mm. BẠN PHẢI kiểm thử tất cả cổng đầu ra âm thanh.

OboeTester hiện hỗ trợ các đường dẫn AAudio, vì vậy, bạn NÊN kiểm thử các tổ hợp sau để tìm lỗi bằng AAudio:

Chế độ Perf	Chia sẻ	Tốc độ lấy mẫu đầu ra	Trong Chans	Out Chans
LOW_LATENCY	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	1	2
LOW_LATENCY	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	2	1
LOW_LATENCY	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	1	2
LOW_LATENCY	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	2	1

Một luồng đáng tin cậy PHẢI đáp ứng các tiêu chí sau đây về Tỷ lệ tín hiệu trên nhiễu (SNR) và Tổng độ méo hài (THD) đối với tín hiệu sin 2000 Hz.

Bộ chuyển đổi	THD	SNR
loa tích hợp chính, được đo bằng micrô tham chiếu bên ngoài	< 3%	>= 50 dB
micrô tích hợp chính, được đo bằng loa tham chiếu bên ngoài	< 3%	>= 50 dB
giắc cắm analog 3,5 mm tích hợp, được kiểm thử bằng bộ chuyển đổi vòng lặp	Chưa đến 1%	>= 60 dB
Bộ chuyển đổi USB đi kèm với điện thoại, được kiểm thử bằng bộ chuyển đổi vòng lặp	< 1%	>= 60 dB

7.9. Thực tế ảo

Android bao gồm các API và cơ sở để xây dựng ứng dụng "Thực tế ảo" (VR), bao gồm cả trải nghiệm VR chất lượng cao trên thiết bị di động. Việc triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

7.9.1. Chế độ thực tế ảo

Android hỗ trợ Chế độ thực tế ảo, một tính năng xử lý việc kết xuất thông báo theo chế độ nổi và tắt các thành phần giao diện người dùng hệ thống đơn sắc khi ứng dụng thực tế ảo có tiêu điểm người dùng.

7.9.2. Chế độ thực tế ảo – Hiệu suất cao

Nếu các phương thức triển khai thiết bị hỗ trợ chế độ VR, thì các phương thức đó:

[C-1-1] PHẢI có ít nhất 2 lõi vật lý.
[C-1-2] PHẢI khai báo tính năng android.hardware.vr.high_performance.
[C-1-3] PHẢI hỗ trợ chế độ hiệu suất cao bền vững.
[C-1-4] PHẢI hỗ trợ OpenGL ES 3.2.
[C-1-5] PHẢI hỗ trợ android.hardware.vulkan.level 0.
PHẢI hỗ trợ android.hardware.vulkan.level 1 trở lên.
[C-1-6] PHẢI triển khai EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, và hiển thị các tiện ích trong danh sách các tiện ích EGL có sẵn.
[C-1-8] PHẢI triển khai GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, và hiển thị các tiện ích trong danh sách tiện ích GL hiện có.
[C-SR-1] Bạn NÊN triển khai GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, và hiển thị các tiện ích trong danh sách tiện ích GL hiện có.
[C-SR-2] RẤT NÊN hỗ trợ Vulkan 1.1.
[C-SR-3] Bạn NÊN triển khai VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image và hiển thị trong danh sách các tiện ích Vulkan hiện có.
[C-SR-4] Bạn NÊN hiển thị ít nhất một gia đình hàng đợi Vulkan trong đó flags chứa cả VK_QUEUE_GRAPHICS_BIT và VK_QUEUE_COMPUTE_BIT, và queueCount ít nhất là 2.
[C-1-7] GPU và màn hình PHẢI có thể đồng bộ hoá quyền truy cập vào vùng đệm trước dùng chung để hiển thị chế độ kết xuất mắt luân phiên của nội dung VR ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất mà không có hiện tượng rách hình ảnh rõ ràng.
[C-1-9] PHẢI triển khai tính năng hỗ trợ cho cờ AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA và AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT như mô tả trong NDK.
[C-1-10] PHẢI triển khai tính năng hỗ trợ cho AHardwareBuffer bằng bất kỳ tổ hợp nào của cờ sử dụng AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT cho ít nhất các định dạng sau: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] Bạn NÊN hỗ trợ việc phân bổ AHardwareBuffer với nhiều lớp, cờ và định dạng được chỉ định trong C-1-10.
[C-1-11] PHẢI hỗ trợ giải mã H.264 ở độ phân giải tối thiểu 3840 x 2160 với tốc độ 30 khung hình/giây, được nén ở tốc độ trung bình 40 Mb/giây (tương đương với 4 phiên bản 1920 x 1080 ở tốc độ 30 khung hình/giây – 10 Mb/giây hoặc 2 phiên bản 1920 x 1080 ở tốc độ 60 khung hình/giây – 20 Mb/giây).
[C-1-12] PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã ít nhất là 1920 x 1080 ở tốc độ 30 khung hình/giây được nén ở tốc độ trung bình là 10 Mb/giây và NÊN có khả năng giải mã 3840 x 2160 ở tốc độ 30 khung hình/giây-20 Mb/giây (tương đương với 4 phiên bản 1920 x 1080 ở tốc độ 30 khung hình/giây-5 Mb/giây).
[C-1-13] PHẢI hỗ trợ API HardwarePropertiesManager.getDeviceTemperatures và trả về giá trị chính xác cho nhiệt độ da.
[C-1-14] PHẢI có màn hình được nhúng và độ phân giải PHẢI tối thiểu là 1920 x 1080.
[C-SR-6] NÊN có độ phân giải màn hình tối thiểu là 2560 x 1440.
[C-1-15] Màn hình PHẢI cập nhật ít nhất 60 Hz khi ở Chế độ thực tế ảo.
[C-1-17] Màn hình PHẢI hỗ trợ chế độ độ bền thấp với độ bền ≤ 5 mili giây, độ bền được xác định là khoảng thời gian một pixel phát ra ánh sáng.
[C-1-18] PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data Length Extension (Tiện ích mở rộng độ dài dữ liệu Bluetooth LE) mục 7.4.3.
[C-1-19] PHẢI hỗ trợ và báo cáo đúng cách Loại kênh trực tiếp cho tất cả các loại cảm biến mặc định sau:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] Bạn NÊN hỗ trợ loại kênh trực tiếp TYPE_HARDWARE_BUFFER cho tất cả các loại kênh trực tiếp được liệt kê ở trên.
[C-1-21] PHẢI đáp ứng các yêu cầu liên quan đến con quay hồi chuyển, gia tốc kế và từ kế cho android.hardware.hifi_sensors, như được chỉ định trong mục 7.3.9.
[C-SR-8] Bạn NÊN hỗ trợ tính năng android.hardware.sensor.hifi_sensors.
[C-1-22] PHẢI có độ trễ chuyển động từ đầu đến cuối đến photon không cao hơn 28 mili giây.
[C-SR-9] Bạn NÊN có độ trễ chuyển động đến photon từ đầu đến cuối không cao hơn 20 mili giây.
[C-1-23] PHẢI có tỷ lệ khung hình đầu tiên, là tỷ lệ giữa độ sáng của các pixel trên khung hình đầu tiên sau khi chuyển đổi từ màu đen sang màu trắng và độ sáng của các pixel trắng ở trạng thái ổn định, ít nhất là 85%.
[C-SR-10] NÊN có tỷ lệ khung hình đầu tiên ít nhất là 90%.
CÓ THỂ cung cấp một lõi dành riêng cho ứng dụng trên nền trước và CÓ THỂ hỗ trợ API Process.getExclusiveCores để trả về số lượng lõi CPU dành riêng cho ứng dụng trên nền trước hàng đầu.

Nếu lõi độc quyền được hỗ trợ, thì lõi đó:

[C-2-1] PHẢI không cho phép bất kỳ quy trình không gian người dùng nào khác chạy trên đó (ngoại trừ trình điều khiển thiết bị mà ứng dụng sử dụng), nhưng CÓ THỂ cho phép một số quy trình hạt nhân chạy khi cần.

7.10. Xúc giác

Bắt đầu yêu cầu mới

Các thiết bị cầm tay hoặc đeo có thể bao gồm một bộ truyền động xúc giác dùng cho nhiều mục đích, có sẵn cho các ứng dụng cho các mục đích bao gồm cả việc thu hút sự chú ý thông qua chuông nhạc, chuông báo, thông báo cũng như phản hồi chung về thao tác chạm.

Nếu quá trình triển khai thiết bị KHÔNG bao gồm một bộ truyền động xúc giác dùng cho nhiều mục đích như vậy, thì các thiết bị đó:

[7.10/C] PHẢI trả về giá trị false cho Vibrator.hasVibrator().

Nếu quá trình triển khai thiết bị CÓ bao gồm ít nhất một bộ truyền động xúc giác có mục đích chung như vậy, thì các thiết bị đó:

[C-1-1] PHẢI trả về true cho Vibrator.hasVibrator().
KHÔNG NÊN sử dụng bộ truyền động xúc giác (máy rung) có khối lượng xoay lệch tâm (ERM).
NÊN triển khai tất cả hằng số công khai cho cảm ứng 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).
NÊN triển khai tất cả hằng số công khai cho cảm ứng 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ả hằng số PRIMITIVE_* công khai khả thi cho cảm ứng 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ố trong số các giá trị gốc này, chẳng hạn như LOW_TICK và SPIN, có thể chỉ khả thi nếu bộ rung có thể hỗ trợ tần số tương đối thấp.
NÊN làm theo hướng dẫn liên kết hằng số công khai trong android.view.HapticFeedbackConstants với hằng số android.os.VibrationEffect được đề xuất, với các mối quan hệ biên độ tương ứng.
NÊN sử dụng các bản đồ hằng số xúc giác được liên kết này.
NÊN làm theo quy trình đánh giá chất lượng cho API createOneShot() và createWaveform().
PHẢI 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.
NÊN xác minh các chức năng để mở rộng quy mô độ lớn bằng cách chạy android.os.Vibrator.hasAmplitudeControl().

Nếu việc triển khai thiết bị tuân theo ánh xạ hằng số xúc giác, thì các thiết bị đó:

NÊN xác minh trạng thái triển khai bằng cách chạy các API android.os.Vibrator.areAllEffectsSupported() và android.os.Vibrator.arePrimitivesSupported().
NÊN thực hiện đánh giá chất lượng cho các hằng số xúc giác.
NÊN xác minh và cập nhật cấu hình dự phòng cho các loại dữ liệu gốc không được hỗ trợ nếu cần, như mô tả trong hướng dẫn triển khai cho các hằng số.
PHẢI cung cấp tính năng hỗ trợ dự phòng để giảm nguy cơ thất bại như mô tả tại đây.

Kết thúc các yêu cầu mới

~~Xem Mục 2.2.1 để biết các yêu cầu dành riêng cho thiết bị.~~

7.11. Lớp hiệu suất nội dung nghe nhìn

Bạn có thể lấy lớp hiệu suất nội dung nghe nhìn của quá trình triển khai thiết bị từ API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Các yêu cầu đối với lớp hiệu suất nội dung nghe nhìn được xác định cho từng phiên bản Android, bắt đầu từ phiên bản R (phiên bản 30). Giá trị đặc biệt là 0 cho biết thiết bị không thuộc lớp hiệu suất nội dung nghe nhìn.

Nếu việc triển khai thiết bị trả về giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các thiết bị đó:

[C-1-1] PHẢI trả về ít nhất một giá trị là android.os.Build.VERSION_CODES.R.
[C-1-2] PHẢI là cách triển khai thiết bị cầm tay.
[C-1-3] PHẢI đáp ứng tất cả các yêu cầu đối với "Lớp hiệu suất nội dung nghe nhìn" được mô tả trong mục 2.2.7.

Nói cách khác, lớp hiệu suất nội dung nghe nhìn trong Android T chỉ được xác định cho các thiết bị cầm tay ở phiên bản T, S hoặc R.

Hãy xem mục 2.2.7 để biết các yêu cầu cụ thể theo thiết bị.

8. Hiệu suất và nguồn điện

Một số tiêu chí về hiệu suất và công suất tối thiểu rất quan trọng đối với trải nghiệm người dùng và ảnh hưởng đến các giả định cơ sở mà nhà phát triển sẽ có khi phát triển ứng dụng.

8.1. Tính nhất quán của trải nghiệm người dùng

Người dùng cuối có thể được cung cấp giao diện người dùng mượt mà nếu có một số yêu cầu tối thiểu nhất định để đảm bảo tốc độ khung hình và thời gian phản hồi nhất quán cho các ứng dụng và trò chơi. Việc triển khai thiết bị, tuỳ thuộc vào loại thiết bị, CÓ THỂ có các yêu cầu có thể đo lường được đối với độ trễ giao diện người dùng và việc chuyển đổi tác vụ như mô tả trong mục 2.

8.2. Hiệu suất truy cập I/O tệp

Việc cung cấp một đường cơ sở chung cho hiệu suất truy cập tệp nhất quán trên bộ nhớ dữ liệu riêng của ứng dụng (phân vùng /data) cho phép nhà phát triển ứng dụng đặt ra kỳ vọng phù hợp để giúp thiết kế phần mềm của họ. Việc triển khai thiết bị, tuỳ thuộc vào loại thiết bị, CÓ THỂ có một số yêu cầu nhất định được mô tả trong phần 2 đối với các thao tác đọc và ghi sau:

Hiệu suất ghi tuần tự. Đo lường bằng cách ghi tệp 256 MB bằng vùng đệm ghi 10 MB.
Hiệu suất ghi ngẫu nhiên. Đo lường bằng cách ghi tệp 256 MB bằng vùng đệm ghi 4 KB.
Hiệu suất đọc tuần tự. Đo lường bằng cách đọc tệp 256 MB bằng bộ đệm ghi 10 MB.
Hiệu suất đọc ngẫu nhiên. Đo lường bằng cách đọc tệp 256 MB bằng vùng đệm ghi 4 KB.

8.3. Chế độ tiết kiệm pin

Nếu việc triển khai thiết bị bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị có trong AOSP (ví dụ: Bộ chứa chế độ chờ ứng dụng, Chế độ nghỉ) hoặc mở rộng các tính năng để áp dụng các hạn chế nghiêm ngặt hơn so với Bộ chứa chế độ chờ ứng dụng BỊ HẠN CHẾ, thì các tính năng đó:

[C-1-1] KHÔNG ĐƯỢC sai khác với cách triển khai AOSP đối với việc kích hoạt, duy trì, thuật toán đánh thức và sử dụng chế độ cài đặt hệ thống toàn cục hoặc DeviceConfig của chế độ Trạng thái chờ ứng dụng và chế độ tiết kiệm pin Ngủ.
[C-1-2] KHÔNG ĐƯỢC sai khác với cách triển khai AOSP để sử dụng chế độ cài đặt chung hoặc DeviceConfig nhằm quản lý việc điều tiết công việc, chuông báo và mạng cho các ứng dụng trong mỗi bộ chứa cho chế độ chờ ứng dụng.
[C-1-3] KHÔNG ĐƯỢC khác với cách triển khai AOSP về số lượng Nhóm chế độ chờ ứng dụng dùng cho Chế độ chờ ứng dụng.
[C-1-4] PHẢI triển khai Bộ chứa chế độ chờ ứng dụng và Chế độ nghỉ như mô tả trong phần Quản lý nguồn.
[C-1-5] PHẢI trả về true cho PowerManager.isPowerSaveMode() khi thiết bị ở chế độ tiết kiệm pin.
[C-1-6] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn khỏi chế độ Trạng thái chờ ứng dụng và chế độ tiết kiệm pin Chế độ nghỉ hoặc bất kỳ tính năng tối ưu hoá pin nào và PHẢI triển khai ý định ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS để yêu cầu người dùng cho phép một ứng dụng bỏ qua tính năng tối ưu hoá pin.
[C-SR-1] NÊN cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.
[C-SR-2] NÊN cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ Trạng thái chờ ứng dụng và chế độ tiết kiệm pin Ngủ.

Nếu việc triển khai thiết bị mở rộng các tính năng quản lý nguồn điện có trong AOSP và tiện ích đó áp dụng các hạn chế nghiêm ngặt hơn so với Bộ chứa chế độ chờ ứng dụng hiếm, hãy tham khảo phần 3.5.1.

Ngoài các chế độ tiết kiệm pin, việc triển khai thiết bị Android CÓ THỂ triển khai bất kỳ hoặc tất cả 4 trạng thái nguồn điện khi ngủ theo định nghĩa của Giao diện nguồn và cấu hình nâng cao (ACPI).

Nếu quá trình triển khai thiết bị triển khai các trạng thái nguồn S4 như được xác định bởi ACPI, thì các trạng thái đó sẽ:

[C-1-1] CHỈ ĐƯỢC chuyển sang trạng thái này sau khi người dùng thực hiện một hành động rõ ràng để đưa thiết bị vào trạng thái không hoạt động (ví dụ: bằng cách đóng nắp là một phần của thiết bị hoặc tắt xe hoặc TV) và trước khi người dùng kích hoạt lại thiết bị (ví dụ: bằng cách mở nắp hoặc bật lại xe hoặc TV).

Nếu quá trình triển khai thiết bị triển khai các trạng thái nguồn S3 như được xác định bởi ACPI, thì các trạng thái đó sẽ:

[C-2-1] PHẢI đáp ứng C-1-1 ở trên, hoặc PHẢI chỉ chuyển sang trạng thái S3 khi các ứng dụng bên thứ ba không cần tài nguyên hệ thống (ví dụ: màn hình, CPU).

Ngược lại, PHẢI thoát khỏi trạng thái S3 khi các ứng dụng bên thứ ba cần tài nguyên hệ thống, như mô tả trên SDK này.

Ví dụ: trong khi các ứng dụng bên thứ ba yêu cầu giữ màn hình bật thông qua FLAG_KEEP_SCREEN_ON hoặc giữ CPU chạy thông qua PARTIAL_WAKE_LOCK, thiết bị KHÔNG ĐƯỢC chuyển sang trạng thái S3, trừ phi như mô tả trong C-1-1, người dùng đã thực hiện hành động rõ ràng để đưa thiết bị vào trạng thái không hoạt động. Ngược lại, tại thời điểm một tác vụ mà các ứng dụng bên thứ ba triển khai thông qua JobScheduler được kích hoạt hoặc Giải pháp gửi thông báo qua đám mây của Firebase được phân phối đến các ứng dụng bên thứ ba, thiết bị PHẢI thoát khỏi trạng thái S3 trừ phi người dùng đã đặt thiết bị ở trạng thái không hoạt động. Đây không phải là các ví dụ toàn diện và AOSP triển khai các tín hiệu đánh thức mở rộng để kích hoạt chế độ đánh thức từ trạng thái này.

8.4. Kế toán mức tiêu thụ điện năng

Việc tính toán và báo cáo chính xác hơn về mức tiêu thụ điện năng sẽ cung cấp cho nhà phát triển ứng dụng cả các biện pháp khuyến khích và công cụ để tối ưu hoá mẫu sử dụng điện năng của ứng dụng.

Triển khai trên thiết bị:

[C-SR-1] BẠN NÊN cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức hao pin ước tính do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android.
[C-SR-2] BẠN NÊN báo cáo tất cả giá trị tiêu thụ điện năng theo đơn vị milliampe giờ (mAh).
[C-SR-3] NÊN báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. Dự án nguồn mở Android đáp ứng yêu cầu này thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[C-SR-4] NÊN cung cấp mức sử dụng năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.
NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.

8.5. Hiệu suất nhất quán

Hiệu suất có thể biến động đáng kể đối với các ứng dụng chạy trong thời gian dài và có hiệu suất cao, do các ứng dụng khác chạy ở chế độ nền hoặc do CPU điều tiết do giới hạn nhiệt độ. Android bao gồm các giao diện lập trình để khi thiết bị có khả năng, ứng dụng trên cùng ở chế độ nền trước có thể yêu cầu hệ thống tối ưu hoá việc phân bổ tài nguyên để giải quyết những biến động như vậy.

Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo chính xác việc hỗ trợ Chế độ hiệu suất cao bền vững thông qua phương thức API PowerManager.isSustainedPerformanceModeSupported().
PHẢI hỗ trợ Chế độ hiệu suất cao bền vững.

Nếu việc triển khai thiết bị báo cáo hỗ trợ Chế độ hiệu suất cao bền vững, thì các thiết bị đó:

[C-1-1] PHẢI cung cấp cho ứng dụng trên cùng ở chế độ nền trước một mức hiệu suất nhất quán trong ít nhất 30 phút khi ứng dụng yêu cầu.
[C-1-2] PHẢI tuân thủ API Window.setSustainedPerformanceMode() và các API liên quan khác.

Nếu quá trình triển khai thiết bị bao gồm hai hoặc nhiều lõi CPU, thì các lõi đó:

NÊN cung cấp ít nhất một lõi độc quyền mà ứng dụng trên cùng ở nền trước có thể đặt trước.

Nếu việc triển khai thiết bị hỗ trợ việc đặt trước một lõi dành riêng cho ứng dụng trên cùng ở chế độ nền trước, thì các thiết bị đó:

[C-2-1] PHẢI báo cáo thông qua phương thức API Process.getExclusiveCores() số nhận dạng của các nhân độc quyền mà ứng dụng trên nền trước hàng đầu có thể đặt trước.
[C-2-2] PHẢI không cho phép bất kỳ quy trình không gian người dùng nào ngoại trừ trình điều khiển thiết bị mà ứng dụng sử dụng để chạy trên các nhân độc quyền, nhưng CÓ THỂ cho phép một số quy trình nhân chạy khi cần.

Nếu việc triển khai thiết bị không hỗ trợ lõi độc quyền, thì các thiết bị đó:

[C-3-1] PHẢI trả về danh sách trống thông qua phương thức API Process.getExclusiveCores().

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

Triển khai trên thiết bị:

[C-0-1] PHẢI triển khai mô hình bảo mật nhất quán với mô hình bảo mật của nền tảng Android như được xác định trong tài liệu tham khảo về Quyền và bảo mật trong các API trong tài liệu dành cho nhà phát triển Android.
[C-0-2] PHẢI hỗ trợ cài đặt các ứng dụng tự ký mà không yêu cầu thêm bất kỳ quyền/giấy chứng nhận nào từ bên thứ ba/cơ quan nào.

Nếu quá trình triển khai thiết bị khai báo tính năng android.hardware.security.model.compatible, thì các quá trình đó:

[C-1-1] PHẢI hỗ trợ các yêu cầu được liệt kê trong các tiểu mục sau.

9.1. Quyền

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình quyền trên Android và mô hình vai trò trên Android như được xác định trong tài liệu dành cho nhà phát triển Android. Cụ thể, các ứng dụng này KHÔNG ĐƯỢC bỏ qua, thay đổi hoặc bỏ qua bất kỳ quyền và vai trò nào được xác định như mô tả trong tài liệu SDK.
CÓ THỂ thêm các quyền khác, miễn là chuỗi mã nhận dạng quyền mới không nằm trong không gian tên android.\*.
[C-0-2] Quyền có protectionLevel là PROTECTION_FLAG_PRIVILEGED chỉ được cấp cho các ứng dụng được cài đặt sẵn trong(các) đường dẫn đặc quyền của ảnh hệ thống (cũng như tệp APEX) và nằm trong tập hợp con của các quyền được liệt kê trong danh sách cho phép rõ ràng cho từng ứng dụng. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách đọc và tuân thủ các quyền được liệt kê trong danh sách cho phép cho từng ứng dụng từ các tệp trong đường dẫn etc/permissions/ và sử dụng đường dẫn system/priv-app làm đường dẫn đặc quyền.

Quyền có mức độ bảo vệ nguy hiểm là quyền khi bắt đầu chạy. Các ứng dụng có targetSdkVersion > 22 sẽ yêu cầu các quyền này trong thời gian chạy.

Triển khai trên thiết bị:

[C-0-3] PHẢI hiển thị một giao diện chuyên dụng để người dùng quyết định có cấp các quyền khi bắt đầu chạy được yêu cầu hay không, đồng thời cung cấp một giao diện để người dùng quản lý các quyền khi bắt đầu chạy.

~~[C-0-4] PHẢI có một và chỉ một phương thức triển khai cả hai giao diện người dùng.~~

[C-0-5] KHÔNG ĐƯỢC cấp bất kỳ quyền khi bắt đầu chạy nào cho ứng dụng, trừ phi:
- Các ứng dụng này được cài đặt tại thời điểm vận chuyển thiết bị VÀ
- Bạn có thể lấy sự đồng ý của người dùng trước khi ứng dụng sử dụng quyền,
  
  HOẶC
- Quyền khi bắt đầu chạy được cấp theo chính sách cấp quyền mặc định hoặc để giữ một vai trò trên nền tảng.
[C-0-6] CHỈ được cấp quyền android.permission.RECOVER_KEYSTORE cho các ứng dụng hệ thống đăng ký một Tác nhân khôi phục được bảo mật đúng cách. Một Agent khôi phục được bảo mật đúng cách được xác định là một agent phần mềm trên thiết bị đồng bộ hoá với một bộ nhớ từ xa ngoài thiết bị, được trang bị phần cứng bảo mật có khả năng bảo vệ tương đương hoặc mạnh hơn so với nội dung mô tả trong Dịch vụ Google Cloud Key Vault để ngăn chặn các cuộc tấn công bằng phương thức brute-force vào yếu tố tri thức trên màn hình khoá.

Triển khai trên thiết bị:

[C-0-7] PHẢI tuân thủ các thuộc tính quyền truy cập thông tin vị trí của Android khi một ứng dụng yêu cầu dữ liệu vị trí hoặc hoạt động thể chất thông qua API Android chuẩn hoặc cơ chế độc quyền. Dữ liệu đó bao gồm nhưng không giới hạn ở:
- Vị trí của thiết bị (ví dụ: vĩ độ và kinh độ) như mô tả trong mục 9.8.8.
- Thông tin có thể dùng để xác định hoặc ước tính vị trí của thiết bị (ví dụ: SSID, BSSID, Mã nhận dạng ô hoặc vị trí của mạng mà thiết bị kết nối).
- Hoạt động thể chất của người dùng hoặc cách phân loại hoạt động thể chất.

Cụ thể hơn, việc triển khai thiết bị:

[C-0-8] PHẢI có sự đồng ý của người dùng để cho phép ứng dụng truy cập vào dữ liệu vị trí hoặc hoạt động thể chất.
[C-0-9] CHỈ ĐƯỢC cấp quyền khi bắt đầu chạy cho ứng dụng có đủ quyền như mô tả trên SDK. Ví dụ: TelephonyManager#getServiceState yêu cầu android.permission.ACCESS_FINE_LOCATION).

Các trường hợp ngoại lệ duy nhất đối với các thuộc tính quyền truy cập thông tin vị trí trên Android là dành cho các ứng dụng không truy cập vào Thông tin vị trí để lấy hoặc xác định vị trí của người dùng; cụ thể:

Khi ứng dụng có quyền RADIO_SCAN_WITHOUT_LOCATION.
Đối với mục đích thiết lập và định cấu hình thiết bị, trong đó các ứng dụng hệ thống giữ quyền NETWORK_SETTINGS hoặc NETWORK_SETUP_WIZARD.

Bạn có thể đánh dấu quyền là bị hạn chế để thay đổi hành vi của quyền đó.

[C-0-10] KHÔNG ĐƯỢC cấp quyền được đánh dấu bằng cờ hardRestricted cho một ứng dụng, trừ phi:
- Tệp APK của ứng dụng nằm trong phân vùng hệ thống.
- Người dùng chỉ định một vai trò liên kết với các quyền hardRestricted cho một ứng dụng.
- Trình cài đặt cấp hardRestricted cho một ứng dụng.
- Ứng dụng được cấp hardRestricted trên một phiên bản Android cũ.
[C-0-11] Ứng dụng có quyền softRestricted CHỈ ĐƯỢC có quyền truy cập hạn chế và KHÔNG ĐƯỢC có quyền truy cập đầy đủ cho đến khi được đưa vào danh sách cho phép như mô tả trong SDK, trong đó quyền truy cập đầy đủ và hạn chế được xác định cho từng quyền softRestricted (ví dụ: READ_EXTERNAL_STORAGE).
[C-0-12] KHÔNG ĐƯỢC cung cấp bất kỳ hàm hoặc API tuỳ chỉnh nào để bỏ qua các hạn chế về quyền được xác định trong API setPermissionPolicy và setPermissionGrantState.
[C-0-13] PHẢI sử dụng API AppOpsManager để ghi lại và theo dõi mọi hoạt động truy cập có lập trình vào dữ liệu được bảo vệ bằng các quyền nguy hiểm từ các hoạt động và dịch vụ Android.
[C-0-14] CHỈ được chỉ định vai trò cho các ứng dụng có chức năng đáp ứng các yêu cầu về vai trò.
[C-0-15] KHÔNG được xác định các vai trò trùng lặp hoặc có chức năng siêu tập của các vai trò do nền tảng xác định.

Nếu báo cáo android.software.managed_users, thiết bị sẽ:

[C-1-1] KHÔNG ĐƯỢC để quản trị viên cấp các quyền sau đây một cách ngầm ẩn:
- Vị trí (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Máy ảnh (CAMERA)
- Micrô (RECORD_AUDIO)
- Cảm biến cơ thể (BODY_SENSORS)
- Hoạt động thể chất (ACTIVITY_RECOGNITION)

Nếu việc triển khai thiết bị cung cấp cho người dùng khả năng chọn ứng dụng nào có thể vẽ lên các ứng dụng khác bằng một hoạt động xử lý ý định ACTION_MANAGE_OVERLAY_PERMISSION, thì các ứng dụng đó:

[C-2-1] PHẢI đảm bảo rằng tất cả hoạt động có bộ lọc ý định cho ý định ACTION_MANAGE_OVERLAY_PERMISSION đều có cùng một màn hình giao diện người dùng, bất kể ứng dụng khởi tạo hoặc bất kỳ thông tin nào mà ứng dụng đó cung cấp.

Nếu các hoạt động triển khai thiết bị báo cáo android.software.device_admin, thì các hoạt động đó:

[C-3-1] PHẢI hiển thị tuyên bố từ chối trách nhiệm trong quá trình thiết lập thiết bị được quản lý toàn diện (thiết lập chủ sở hữu thiết bị) nêu rõ rằng quản trị viên CNTT sẽ có quyền cho phép ứng dụng kiểm soát các chế độ cài đặt trên điện thoại, bao gồm cả micrô, máy ảnh và vị trí, với các lựa chọn để người dùng tiếp tục thiết lập hoặc thoát khỏi quy trình thiết lập, TRỪ phi quản trị viên đã chọn không kiểm soát các quyền trên thiết bị.

Nếu quá trình triển khai thiết bị cài đặt trước bất kỳ gói nào chứa vai trò Trí tuệ giao diện người dùng hệ thống, Trí tuệ âm thanh môi trường xung quanh hệ thống, Trí tuệ âm thanh hệ thống, Trí tuệ thông báo hệ thống, Trí tuệ văn bản hệ thống hoặc Trí tuệ hình ảnh hệ thống, thì các gói đó:

[C-4-1] PHẢI đáp ứng tất cả các yêu cầu được nêu trong phần triển khai thiết bị trong các phần ~~"9.8.6 Content Capture"~~ "9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".

[C-4-2] KHÔNG ĐƯỢC có quyền android.permission.INTERNET. Yêu cầu này nghiêm ngặt hơn yêu cầu NÊN DÙNG được liệt kê trong mục 9.8.6.

[C-4-3] KHÔNG ĐƯỢC liên kết với các ứng dụng khác, ngoại trừ các ứng dụng hệ thống sau: Bluetooth, Danh bạ, Nội dung nghe nhìn, Điện thoại, SystemUI và các thành phần cung cấp API Internet. Yêu cầu này nghiêm ngặt hơn mức KHUYÊN CÁO MẠNH liệt kê trong phần 9.8.6.

Bắt đầu yêu cầu mới

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng mặc định để hỗ trợ VoiceInteractionService, thì các thiết bị đó:

[C-5-1] KHÔNG ĐƯỢC cấp ACCESS_FINE_LOCATION làm mặc định cho ứng dụng đó.

Kết thúc các yêu cầu mới

9.2. UID và cách ly quy trình

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình hộp cát của ứng dụng Android, trong đó mỗi ứng dụng chạy dưới dạng UID kiểu Unix duy nhất và trong một quy trình riêng biệt.
[C-0-2] PHẢI hỗ trợ chạy nhiều ứng dụng với cùng một mã nhận dạng người dùng Linux, miễn là các ứng dụng đó được ký và tạo đúng cách, như được xác định trong Tài liệu tham khảo về quyền và bảo mật.

9.3. Quyền đối với hệ thống tệp

Triển khai trên thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình quyền truy cập vào tệp Android như được xác định trong Tài liệu tham khảo về bảo mật và quyền.

9.4. Môi trường thực thi thay thế

Việc triển khai thiết bị PHẢI duy trì tính nhất quán của mô hình bảo mật và quyền của Android, ngay cả khi các thiết bị đó bao gồm các môi trường thời gian chạy thực thi ứng dụng bằng một số phần mềm hoặc công nghệ khác ngoài Định dạng thực thi Dalvik hoặc mã gốc. Hay nói cách khác:

[C-0-1] Môi trường thời gian chạy thay thế PHẢI là ứng dụng Android và tuân thủ mô hình bảo mật Android tiêu chuẩn, như mô tả ở nơi khác trong mục 9.
[C-0-2] KHÔNG ĐƯỢC cấp quyền truy cập vào các tài nguyên được bảo vệ bằng các quyền không được yêu cầu trong tệp AndroidManifest.xml của môi trường thời gian chạy thông qua cơ chế <uses-permission>.
[C-0-3] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cho phép các ứng dụng sử dụng các tính năng được bảo vệ bằng các quyền của Android chỉ dành cho ứng dụng hệ thống.
[C-0-4] Mô hình hộp cát Android và các ứng dụng đã cài đặt sử dụng môi trường thời gian chạy thay thế PHẢI tuân thủ mô hình hộp cát Android và KHÔNG ĐƯỢC sử dụng lại hộp cát của bất kỳ ứng dụng nào khác đã cài đặt trên thiết bị, ngoại trừ thông qua các cơ chế Android tiêu chuẩn về mã nhận dạng người dùng dùng chung và chứng chỉ ký.
[C-0-5] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC khởi chạy bằng, cấp hoặc được cấp quyền truy cập vào hộp cát tương ứng với các ứng dụng Android khác.
[C-0-6] KHÔNG được chạy, cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của người dùng cấp cao (gốc) hoặc của bất kỳ mã nhận dạng người dùng nào khác bằng môi trường thời gian chạy thay thế.
[C-0-7] Khi các tệp .apk của môi trường thời gian chạy thay thế được đưa vào hình ảnh hệ thống của quá trình triển khai thiết bị, tệp đó PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng khác đi kèm với quá trình triển khai thiết bị.
[C-0-8] Khi cài đặt ứng dụng, môi trường thời gian chạy thay thế PHẢI có được sự đồng ý của người dùng đối với các quyền trên Android mà ứng dụng sử dụng.
[C-0-9] Khi một ứng dụng cần sử dụng tài nguyên thiết bị có quyền tương ứng trên Android (chẳng hạn như Máy ảnh, GPS, v.v.), môi trường thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng sẽ có thể truy cập vào tài nguyên đó.
[C-0-10] Khi môi trường thời gian chạy không ghi lại các chức năng của ứng dụng theo cách này, môi trường thời gian chạy PHẢI liệt kê tất cả các quyền mà chính môi trường thời gian chạy nắm giữ khi cài đặt bất kỳ ứng dụng nào sử dụng môi trường thời gian chạy đó.
Môi trường thời gian chạy thay thế NÊN cài đặt ứng dụng thông qua PackageManager vào các hộp cát Android riêng biệt (mã nhận dạng người dùng Linux, v.v.).
Môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android duy nhất do tất cả ứng dụng sử dụng môi trường thời gian chạy thay thế chia sẻ.

9.5. Hỗ trợ nhiều người dùng

Android có tính năng hỗ trợ nhiều người dùng và hỗ trợ tính năng tách biệt người dùng hoàn toàn cũng như nhân bản hồ sơ người dùng với tính năng tách biệt một phần(tức là một hồ sơ người dùng bổ sung thuộc loại android.os.usertype.profile.CLONE).

Việc triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN cho phép nhiều người dùng nếu họ sử dụng phương tiện có thể tháo rời làm bộ nhớ ngoài chính.

Nếu việc triển khai thiết bị hỗ trợ nhiều người dùng, thì các thiết bị đó:

[C-1-2] BẮT BUỘC, đối với mỗi người dùng, hãy triển khai một mô hình bảo mật nhất quán với mô hình bảo mật của nền tảng Android như được xác định trong tài liệu tham khảo về Quyền và bảo mật trong API.
[C-1-3] PHẢI có các thư mục bộ nhớ ứng dụng dùng chung (còn gọi là /sdcard) riêng biệt và tách biệt cho mỗi phiên bản người dùng.
[C-1-4] PHẢI đảm bảo rằng các ứng dụng do một người dùng cụ thể sở hữu và chạy thay mặt cho người dùng đó không thể liệt kê, đọc hoặc ghi vào các tệp do người dùng khác sở hữu, ngay cả khi dữ liệu của cả hai người dùng được lưu trữ trên cùng một phương tiện hoặc hệ thống tệp.
[C-1-5] PHẢI mã hoá nội dung của thẻ SD khi bật chế độ nhiều người dùng bằng cách sử dụng khoá chỉ được lưu trữ trên phương tiện không thể tháo rời mà chỉ hệ thống mới có thể truy cập nếu việc triển khai thiết bị sử dụng phương tiện có thể tháo rời cho các API bộ nhớ ngoài. Vì điều này sẽ khiến máy tính lưu trữ không đọc được nội dung nghe nhìn, nên việc triển khai thiết bị sẽ yêu cầu chuyển sang MTP hoặc một hệ thống tương tự để cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại.

Nếu việc triển khai thiết bị bao gồm cả việc hỗ trợ nhiều người dùng, thì đối với tất cả người dùng, ngoại trừ những người dùng được tạo riêng để chạy các phiên bản song song của cùng một ứng dụng, họ sẽ:

[C-2-1] PHẢI có các thư mục bộ nhớ ứng dụng dùng chung riêng biệt và tách biệt (còn gọi là /sdcard) cho mỗi phiên bản người dùng.
[C-2-2] PHẢI đảm bảo rằng các ứng dụng do một người dùng cụ thể sở hữu và chạy thay mặt cho người dùng đó không thể liệt kê, đọc hoặc ghi vào các tệp do người dùng khác sở hữu, ngay cả khi dữ liệu của cả hai người dùng được lưu trữ trên cùng một phương tiện hoặc hệ thống tệp.

Việc triển khai thiết bị CÓ THỂ tạo một hồ sơ người dùng bổ sung duy nhất thuộc loại android.os.usertype.profile.CLONE đối với người dùng chính (và chỉ đối với người dùng chính) nhằm mục đích chạy các phiên bản song song của cùng một ứng dụng. Các phiên bản song song này chia sẻ bộ nhớ được tách biệt một phần, được trình chạy hiển thị cho người dùng cuối cùng cùng một lúc và xuất hiện trong cùng một chế độ xem gần đây. Ví dụ: bạn có thể dùng tính năng này để hỗ trợ người dùng cài đặt hai phiên bản riêng biệt của một ứng dụng trên thiết bị có hai SIM.

Nếu việc triển khai thiết bị tạo hồ sơ người dùng bổ sung như đã thảo luận ở trên, thì các hồ sơ đó:

[C-3-1] PHẢI chỉ cung cấp quyền truy cập vào bộ nhớ hoặc dữ liệu mà hồ sơ người dùng gốc đã có thể truy cập hoặc thuộc quyền sở hữu trực tiếp của hồ sơ người dùng bổ sung này.
[C-3-2] KHÔNG ĐƯỢC đặt làm hồ sơ công việc.
[C-3-3] PHẢI tách riêng các thư mục dữ liệu ứng dụng riêng tư khỏi tài khoản người dùng gốc.
[C-3-4] KHÔNG ĐƯỢC cho phép tạo hồ sơ người dùng bổ sung nếu đã cấp quyền cho Chủ sở hữu thiết bị (xem phần 3.9.1) hoặc cho phép cấp quyền cho Chủ sở hữu thiết bị mà không xoá hồ sơ người dùng bổ sung trước.

Bắt đầu yêu cầu mới

Nếu việc triển khai thiết bị tạo hồ sơ người dùng bổ sung như đã thảo luận ở trên, thì các hồ sơ đó:

[C-4-5] PHẢI phân biệt rõ ràng các biểu tượng ứng dụng phiên bản kép khi người dùng nhìn thấy các biểu tượng đó.

[C-4-6] PHẢI cung cấp cho người dùng khả năng xoá toàn bộ dữ liệu hồ sơ của bản sao.

[C-4-7] PHẢI gỡ cài đặt tất cả ứng dụng Clone, xoá thư mục dữ liệu ứng dụng riêng tư và nội dung của các thư mục đó, đồng thời xoá dữ liệu hồ sơ Clone khi người dùng chọn xoá toàn bộ dữ liệu hồ sơ Clone.

NÊN nhắc người dùng xoá toàn bộ dữ liệu Hồ sơ sao chép khi ứng dụng sao chép cuối cùng bị xoá.

[C-4-8] PHẢI thông báo cho người dùng rằng dữ liệu ứng dụng sẽ bị xoá khi ứng dụng bản sao bị gỡ cài đặt, hoặc cung cấp cho người dùng lựa chọn giữ lại dữ liệu ứng dụng khi ứng dụng bị gỡ cài đặt khỏi thiết bị.

[C-4-9] PHẢI xoá các thư mục dữ liệu ứng dụng riêng tư và nội dung của các thư mục đó khi người dùng chọn xoá dữ liệu trong quá trình gỡ cài đặt.

[C-4-1] PHẢI cho phép các ứng dụng của người dùng chính trên thiết bị xử lý các ý định dưới đây bắt nguồn từ hồ sơ bổ sung:
- 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] PHẢI kế thừa tất cả các quy định hạn chế đối với người dùng trong chính sách thiết bị và các quy định hạn chế không phải đối với người dùng đã chọn(danh sách bên dưới) áp dụng cho người dùng chính của thiết bị cho hồ sơ người dùng bổ sung này.
[C-4-3] PHẢI chỉ cho phép ghi danh bạ từ hồ sơ bổ sung này thông qua các ý định sau:
[C-4-4] KHÔNG ĐƯỢC chạy tính năng đồng bộ hoá danh bạ cho các ứng dụng chạy trong hồ sơ người dùng bổ sung này.

~~[C-4-14] PHẢI có quyền và chế độ quản lý bộ nhớ riêng biệt cho các ứng dụng chạy trong hồ sơ bổ sung này~~

[C-4-5] PHẢI chỉ cho phép các ứng dụng trong hồ sơ bổ sung có hoạt động trình chạy truy cập vào những người liên hệ mà hồ sơ người dùng gốc có thể truy cập.

Kết thúc các yêu cầu mới

9.6. Cảnh báo về tin nhắn dịch vụ

Android hỗ trợ cảnh báo người dùng về mọi tin nhắn SMS đặc biệt gửi đi. Tin nhắn Premium SMS là tin nhắn văn bản được gửi đến một dịch vụ đã đăng ký với nhà mạng và có thể tính phí người dùng.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ android.hardware.telephony, thì các hoạt động đó:

[C-1-1] PHẢI cảnh báo người dùng trước khi gửi tin nhắn SMS đến các số điện thoại được xác định bằng biểu thức chính quy được xác định trong tệp /data/misc/sms/codes.xml trên thiết bị. Dự án nguồn mở Android cấp trên cung cấp phương thức triển khai đáp ứng yêu cầu này.

9.7. Tính năng bảo mật

Việc triển khai thiết bị PHẢI đảm bảo tuân thủ các tính năng bảo mật trong cả hạt nhân và nền tảng như mô tả dưới đây.

Hộp cát Android bao gồm các tính năng sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) của Linux tăng cường bảo mật (SELinux), hộp cát seccomp và các tính năng bảo mật khác trong hạt nhân Linux. Triển khai trên thiết bị:

[C-0-1] PHẢI duy trì khả năng tương thích với các ứng dụng hiện có, ngay cả khi SELinux hoặc bất kỳ tính năng bảo mật nào khác được triển khai bên dưới khung Android.
[C-0-2] KHÔNG ĐƯỢC có giao diện người dùng hiển thị khi một lỗi vi phạm bảo mật được phát hiện và bị tính năng bảo mật triển khai bên dưới khung Android chặn thành công, nhưng CÓ THỂ có giao diện người dùng hiển thị khi một lỗi vi phạm bảo mật chưa bị chặn xảy ra dẫn đến việc khai thác thành công.
[C-0-3] KHÔNG ĐƯỢC triển khai SELinux hoặc bất kỳ tính năng bảo mật nào khác bên dưới khung Android mà người dùng hoặc nhà phát triển ứng dụng có thể định cấu hình.
[C-0-4] KHÔNG ĐƯỢC cho phép một ứng dụng có thể ảnh hưởng đến một ứng dụng khác thông qua một API (chẳng hạn như API Quản trị thiết bị) để định cấu hình một chính sách làm mất khả năng tương thích.
[C-0-5] PHẢI chia khung nội dung đa phương tiện thành nhiều quy trình để có thể cấp quyền truy cập theo phạm vi hẹp hơn cho từng quy trình như mô tả trên trang web Dự án nguồn mở Android.
[C-0-6] PHẢI triển khai cơ chế hộp cát cho ứng dụng hạt nhân cho phép lọc các lệnh gọi hệ thống bằng chính sách có thể định cấu hình từ các chương trình đa luồng. Dự án nguồn mở Android ngược dòng đáp ứng yêu cầu này thông qua việc bật seccomp-BPF với tính năng đồng bộ hoá nhóm luồng (TSYNC) như mô tả trong phần Cấu hình hạt nhân của source.android.com.

Tính toàn vẹn của hạt nhân và các tính năng tự bảo vệ là yếu tố không thể thiếu trong tính bảo mật của Android. Triển khai trên thiết bị:

[C-0-7] PHẢI triển khai các cơ chế bảo vệ tràn vùng đệm ngăn xếp nhân. Ví dụ về các cơ chế như vậy là CC_STACKPROTECTOR_REGULAR và CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] PHẢI triển khai các biện pháp bảo vệ bộ nhớ hạt nhân nghiêm ngặt, trong đó mã có thể thực thi chỉ có thể đọc, dữ liệu chỉ có thể đọc không thể thực thi và không thể ghi, còn dữ liệu có thể ghi không thể thực thi (ví dụ: CONFIG_DEBUG_RODATA hoặc CONFIG_STRICT_KERNEL_RWX).
[C-0-9] PHẢI triển khai tính năng kiểm tra giới hạn kích thước đối tượng tĩnh và động của các bản sao giữa không gian người dùng và không gian hạt nhân (ví dụ: CONFIG_HARDENED_USERCOPY) trên các thiết bị ban đầu được vận chuyển bằng API cấp 28 trở lên.
[C-0-10] KHÔNG ĐƯỢC thực thi bộ nhớ không gian người dùng khi thực thi ở chế độ hạt nhân (ví dụ: PXN phần cứng hoặc được mô phỏng thông qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị ban đầu được vận chuyển với API cấp 28 trở lên.
[C-0-11] KHÔNG ĐƯỢC đọc hoặc ghi bộ nhớ không gian người dùng trong hạt nhân bên ngoài các API truy cập usercopy thông thường (ví dụ: PAN phần cứng hoặc được mô phỏng thông qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị ban đầu được vận chuyển bằng API cấp 28 trở lên.
[C-0-12] PHẢI triển khai tính năng tách biệt bảng trang hạt nhân nếu phần cứng dễ bị CVE-2017-5754 trên tất cả thiết bị ban đầu được vận chuyển với API cấp 28 trở lên (ví dụ: CONFIG_PAGE_TABLE_ISOLATION hoặc CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] PHẢI triển khai tính năng tăng cường dự đoán nhánh nếu phần cứng dễ bị CVE-2017-5715 trên tất cả thiết bị ban đầu được vận chuyển với API cấp 28 trở lên (ví dụ: CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] NÊN giữ dữ liệu hạt nhân chỉ được ghi trong quá trình khởi chạy và được đánh dấu là chỉ có thể đọc sau khi khởi chạy (ví dụ: __ro_after_init).
[C-SR-2] Bạn NÊN sắp xếp ngẫu nhiên bố cục của mã nhân và bộ nhớ, đồng thời tránh các trường hợp rò rỉ có thể làm hỏng tính ngẫu nhiên (ví dụ: CONFIG_RANDOMIZE_BASE với entropy của trình tải khởi động thông qua /chosen/kaslr-seed Device Tree node hoặc EFI_RNG_PROTOCOL).
[C-SR-3] NÊN bật tính năng tính toàn vẹn của luồng điều khiển (CFI) trong hạt nhân để tăng cường bảo vệ trước các cuộc tấn công tái sử dụng mã (ví dụ: CONFIG_CFI_CLANG và CONFIG_SHADOW_CALL_STACK).
[C-SR-4] KHÔNG NÊN tắt tính năng Tính toàn vẹn của luồng điều khiển (CFI), Ngăn xếp lệnh gọi bóng (SCS) hoặc Tẩy lỗi tràn số nguyên (IntSan) trên các thành phần đã bật tính năng này.
[C-SR-5] Bạn NÊN bật CFI, SCS và IntSan cho mọi thành phần không gian người dùng nhạy cảm với bảo mật khác như giải thích trong CFI và IntSan.
[C-SR-6] Bạn NÊN bật tính năng khởi chạy ngăn xếp trong nhân để ngăn việc sử dụng các biến cục bộ chưa khởi chạy (CONFIG_INIT_STACK_ALL hoặc CONFIG_INIT_STACK_ALL_ZERO). Ngoài ra, việc triển khai thiết bị KHÔNG NÊN giả định giá trị mà trình biên dịch sử dụng để khởi chạy các biến cục bộ.
[C-SR-7] Bạn NÊN bật tính năng khởi tạo vùng nhớ khối xếp trong nhân để ngăn việc sử dụng các vùng nhớ khối xếp chưa được khởi tạo (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) và KHÔNG NÊN giả định giá trị mà nhân sử dụng để khởi tạo các vùng nhớ khối xếp đó.

Nếu quá trình triển khai thiết bị sử dụng một nhân Linux có khả năng hỗ trợ SELinux, thì các thiết bị đó:

[C-1-1] PHẢI triển khai SELinux.
[C-1-2] PHẢI đặt SELinux thành chế độ thực thi toàn cục.
[C-1-3] PHẢI định cấu hình tất cả miền ở chế độ thực thi. Không được phép sử dụng miền ở chế độ cho phép, bao gồm cả miền dành riêng cho một thiết bị/nhà cung cấp.
[C-1-4] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc neverallow có trong thư mục system/sepolicy được cung cấp trong Dự án nguồn mở Android (AOSP) ngược dòng và chính sách PHẢI biên dịch với tất cả các quy tắc neverallow hiện có, cho cả miền AOSP SELinux cũng như miền dành riêng cho thiết bị/nhà cung cấp.
[C-1-5] PHẢI chạy các ứng dụng bên thứ ba nhắm đến API cấp 28 trở lên trong hộp cát SELinux cho mỗi ứng dụng với các quy định hạn chế SELinux cho mỗi ứng dụng trên thư mục dữ liệu riêng tư của mỗi ứng dụng.
NÊN giữ lại chính sách SELinux mặc định được cung cấp trong thư mục system/sepolicy của Dự án nguồn mở Android ngược dòng và chỉ thêm vào chính sách này cho cấu hình dành riêng cho thiết bị của riêng họ.

Nếu quá trình triển khai thiết bị sử dụng nhân không phải Linux hoặc Linux không có SELinux, thì các thiết bị đó:

[C-2-1] PHẢI sử dụng hệ thống kiểm soát quyền truy cập bắt buộc tương đương với SELinux.

Nếu việc triển khai thiết bị sử dụng các thiết bị I/O có thể DMA, thì các thiết bị đó:

[C-SR-9] Bạn NÊN tách riêng từng thiết bị I/O có thể sử dụng DMA bằng cách sử dụng IOMMU (ví dụ: ARM SMMU).

Android chứa nhiều tính năng phòng thủ chuyên sâu, là thành phần không thể thiếu trong tính năng bảo mật thiết bị. Ngoài ra, Android tập trung vào việc giảm các lớp lỗi phổ biến chính dẫn đến chất lượng và tính bảo mật kém.

Để giảm lỗi bộ nhớ, việc triển khai thiết bị cần:

[C-SR-10] NÊN kiểm thử bằng các công cụ phát hiện lỗi bộ nhớ không gian người dùng như MTE cho thiết bị ARMv9, HWASan cho thiết bị ARMv8 trở lên hoặc ASan cho các loại thiết bị khác.
[C-SR-11] Bạn NÊN kiểm thử bằng các công cụ phát hiện lỗi bộ nhớ nhân như KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS cho thiết bị ARMv9, CONFIG_KASAN_SW_TAGS cho thiết bị ARMv8 hoặc CONFIG_KASAN_GENERIC cho các loại thiết bị khác).
[C-SR-12] Bạn NÊN sử dụng các công cụ phát hiện lỗi bộ nhớ trong bản phát hành công khai như MTE, GWP-ASan và KFENCE.

Nếu việc triển khai thiết bị sử dụng TEE dựa trên Arm TrustZone, thì các thiết bị đó:

[C-SR-13] NÊN sử dụng giao thức tiêu chuẩn để chia sẻ bộ nhớ giữa Android và TEE, chẳng hạn như Khung phần mềm Arm cho Armv8-A (FF-A).
[C-SR-14] Bạn NÊN hạn chế các ứng dụng đáng tin cậy chỉ truy cập vào bộ nhớ đã được chia sẻ rõ ràng với chúng thông qua giao thức trên. Nếu thiết bị hỗ trợ cấp độ ngoại lệ Arm S-EL2, thì trình quản lý phân vùng bảo mật sẽ thực thi cấp độ này. Nếu không, hệ điều hành TEE sẽ thực thi điều này.

Bắt đầu yêu cầu mới

Công nghệ An toàn bộ nhớ là công nghệ giúp giảm thiểu ít nhất các loại lỗi sau đây với xác suất cao (> 90%) trong các ứng dụng sử dụng tuỳ chọn tệp kê khai android:memtagMode:

tràn vùng đệm vùng nhớ khối xếp
sử dụng sau khi giải phóng
giải phóng hai lần
giải phóng không hợp lệ (giải phóng con trỏ không phải malloc)

Triển khai trên thiết bị:

[C-SR-15] NÊN đặt ro.arm64.memtag.bootctl_supported.

Nếu quá trình triển khai thiết bị đặt thuộc tính hệ thống ro.arm64.memtag.bootctl_supported thành true, thì các thiết bị đó:

[C-3-1] PHẢI cho phép thuộc tính hệ thống arm64.memtag.bootctl chấp nhận danh sách các giá trị sau đây được phân tách bằng dấu phẩy, với hiệu ứng mong muốn được áp dụng trong lần khởi động lại tiếp theo:
- memtag: công nghệ An toàn bộ nhớ như được xác định ở trên đã được bật
- memtag-once: một công nghệ An toàn bộ nhớ như đã xác định ở trên sẽ được bật tạm thời và tự động tắt sau lần khởi động lại tiếp theo
- memtag-off: một công nghệ An toàn bộ nhớ như đã xác định ở trên bị tắt
[C-3-2] PHẢI cho phép người dùng shell đặt arm64.memtag.bootctl.
[C-3-3] PHẢI cho phép mọi quy trình đọc arm64.memtag.bootctl.
[C-3-4] PHẢI đặt arm64.memtag.bootctl thành trạng thái hiện được yêu cầu khi khởi động, đồng thời PHẢI cập nhật thuộc tính này nếu việc triển khai thiết bị cho phép sửa đổi trạng thái mà không thay đổi thuộc tính hệ thống.
[C-SR-16] Bạn NÊN hiện chế độ Cài đặt cho nhà phát triển để đặt memtag-once và khởi động lại thiết bị. Với trình tải khởi động tương thích, Dự án nguồn mở Android đáp ứng các yêu cầu nêu trên thông qua giao thức trình tải khởi động MTE.

~~[C-SR-17] NÊN hiện một Chế độ cài đặt trong trình đơn Cài đặt bảo mật cho phép người dùng bật memtag.~~

Kết thúc các yêu cầu mới

9.8. Quyền riêng tư

9.8.1. Nhật ký sử dụng

Android lưu trữ nhật ký lựa chọn của người dùng và quản lý nhật ký đó bằng UsageStatsManager.

Triển khai trên thiết bị:

[C-0-1] PHẢI giữ lại nhật ký hoạt động của người dùng đó trong một khoảng thời gian hợp lý.
[C-SR-1] NÊN giữ nguyên khoảng thời gian lưu giữ 14 ngày như đã định cấu hình theo mặc định trong quá trình triển khai AOSP.

Android lưu trữ các sự kiện hệ thống bằng cách sử dụng giá trị nhận dạng StatsLog và quản lý nhật ký đó thông qua StatsManager và API Hệ thống IncidentManager.

Triển khai trên thiết bị:

[C-0-2] PHẢI chỉ bao gồm các trường được đánh dấu bằng DEST_AUTOMATIC trong báo cáo sự cố do lớp API hệ thống IncidentManager tạo.
[C-0-3] KHÔNG ĐƯỢC sử dụng giá trị nhận dạng sự kiện hệ thống để ghi lại bất kỳ sự kiện nào khác ngoài những sự kiện được mô tả trong tài liệu SDK StatsLog. Nếu các sự kiện hệ thống bổ sung được ghi lại, thì các sự kiện đó CÓ THỂ sử dụng một giá trị nhận dạng nguyên tử khác trong phạm vi từ 100.000 đến 200.000.

9.8.2. Đang ghi

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC tải trước hoặc phân phối các thành phần phần mềm gốc có chức năng gửi thông tin cá nhân của người dùng (ví dụ: thao tác nhấn phím, văn bản hiển thị trên màn hình, báo cáo lỗi) ra khỏi thiết bị khi chưa có sự đồng ý của người dùng hoặc thông báo rõ ràng về các thông báo đang diễn ra.
[C-0-2] PHẢI hiển thị cảnh báo cho người dùng và có được sự đồng ý rõ ràng của người dùng cho phép ghi lại mọi thông tin nhạy cảm hiển thị trên màn hình của người dùng~~, bao gồm chính xác thông báo giống như AOSP~~ ~~bất cứ khi nào~~ mỗi khi một phiên để ghi lại màn hình ~~truyền hoặc quay màn hình~~ ~~được bật~~ bắt đầu thông qua MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay() hoặc các API độc quyền. ~~KHÔNG ĐƯỢC cung cấp cho người dùng cơ hội tắt chế độ hiển thị sự đồng ý của người dùng trong tương lai.~~
[C-0-3] PHẢI có thông báo liên tục cho người dùng trong khi bật tính năng truyền màn hình hoặc quay màn hình. AOSP đáp ứng yêu cầu này bằng cách hiển thị biểu tượng thông báo đang diễn ra trong thanh trạng thái.

Bắt đầu yêu cầu mới

[C-SR-1] NÊN hiển thị cảnh báo cho người dùng, thông báo này giống hệt với thông báo được triển khai trong AOSP nhưng CÓ THỂ được thay đổi miễn là thông báo cảnh báo rõ ràng cho người dùng rằng mọi thông tin nhạy cảm trên màn hình của người dùng đều được ghi lại.
[C-0-4] KHÔNG ĐƯỢC cung cấp cho người dùng khả năng vô hiệu hoá các lời nhắc trong tương lai về việc người dùng đồng ý chụp ảnh màn hình, trừ phi phiên được bắt đầu bằng một ứng dụng hệ thống mà người dùng đã cho phép associate() bằng android.app.role.COMPANION_DEVICE_APP_STREAMING hoặc hồ sơ thiết bị android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.
Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị bao gồm chức năng trong hệ thống giúp chụp nội dung hiển thị trên màn hình và/hoặc ghi luồng âm thanh phát trên thiết bị không phải thông qua API Hệ thống ContentCaptureService hoặc các phương tiện độc quyền khác được mô tả trong Mục 9.8.6 Dữ liệu cấp hệ điều hành và dữ liệu môi trường xung quanh, thì các chức năng đó:

[C-1-1] PHẢI có thông báo liên tục cho người dùng bất cứ khi nào chức năng này được bật và đang chủ động chụp/ghi lại.

Nếu quá trình triển khai thiết bị bao gồm một thành phần được bật sẵn, có thể ghi âm âm thanh xung quanh và/hoặc ghi âm âm thanh phát trên thiết bị để suy luận thông tin hữu ích về ngữ cảnh của người dùng, thì các thành phần đó:

[C-2-1] KHÔNG ĐƯỢC lưu trữ trong bộ nhớ cố định trên thiết bị hoặc truyền ra khỏi thiết bị âm thanh thô đã ghi hoặc bất kỳ định dạng nào có thể chuyển đổi trở lại thành âm thanh gốc hoặc bản sao gần giống, trừ khi có sự đồng ý rõ ràng của người dùng.

"Chỉ báo micrô" là một thành phần hiển thị trên màn hình, luôn hiển thị với người dùng và không thể bị che khuất, người dùng hiểu là micrô đang được sử dụng(thông qua văn bản, màu sắc, biểu tượng hoặc một số tổ hợp riêng biệt).

"Chỉ báo máy ảnh" là một thành phần hiển thị trên màn hình mà người dùng luôn nhìn thấy và không thể bị che khuất, giúp người dùng hiểu rằng máy ảnh đang được sử dụng (thông qua văn bản, màu sắc, biểu tượng hoặc một số tổ hợp riêng biệt).

Sau khi hiển thị một giây đầu tiên, chỉ báo có thể thay đổi về mặt hình ảnh, chẳng hạn như nhỏ hơn và không bắt buộc phải hiển thị như ban đầu được trình bày và hiểu.

Bạn có thể hợp nhất chỉ báo micrô với chỉ báo máy ảnh đang hiển thị, miễn là văn bản, biểu tượng hoặc màu sắc cho người dùng biết rằng việc sử dụng micrô đã bắt đầu.

Bạn có thể hợp nhất chỉ báo máy ảnh với chỉ báo micrô đang hiển thị, miễn là văn bản, biểu tượng hoặc màu sắc cho người dùng biết rằng hoạt động sử dụng máy ảnh đã bắt đầu.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các hoạt động đó:

[C-SR-1] Bạn NÊN hiển thị chỉ báo micrô khi một ứng dụng truy cập vào dữ liệu âm thanh từ micrô, nhưng không phải khi micrô chỉ được HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD [C-3-X]. .
[C-SR-2] Bạn NÊN hiển thị danh sách các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng micrô được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.
[C-SR-3] KHÔNG NÊN ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc có hoạt động tương tác trực tiếp với người dùng.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.camera.any, thì các hoạt động đó:

[C-SR-4] Bạn NÊN hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không phải khi(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD [C-3-X] chỉ truy cập vào máy ảnh.
[C-SR-5] Bạn NÊN hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng camera được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.
[C-SR-6] KHUYẾN CÁO KHÔNG nên ẩn chỉ báo máy ảnh cho 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.

9.8.3. Khả năng kết nối

Nếu việc triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, thì các thiết bị đó:

[C-1-1] PHẢI hiển thị giao diện người dùng yêu cầu người dùng đồng ý trước khi cho phép truy cập vào nội dung của bộ nhớ dùng chung qua cổng USB.

9.8.4. Lưu lượng truy cập mạng

Triển khai trên thiết bị:

[C-0-1] PHẢI cài đặt trước cùng một chứng chỉ gốc cho kho Tổ chức phát hành chứng chỉ (CA) đáng tin cậy của hệ thống như được cung cấp trong Dự án nguồn mở Android ngược dòng.
[C-0-2] PHẢI xuất xưởng với kho CA gốc của người dùng trống.
[C-0-3] PHẢI hiển thị cảnh báo cho người dùng cho biết lưu lượng truy cập mạng có thể được theo dõi khi thêm CA gốc của người dùng.

Nếu lưu lượng truy cập của thiết bị được định tuyến qua VPN, thì việc triển khai thiết bị sẽ:

[C-1-1] PHẢI hiển thị cảnh báo cho người dùng cho biết:
- Lưu lượng truy cập mạng đó có thể được giám sát.
- Lưu lượng truy cập mạng đó đang được định tuyến thông qua ứng dụng VPN cụ thể cung cấp VPN.

Nếu việc triển khai thiết bị có một cơ chế, được bật ngay từ đầu theo mặc định, cơ chế đó sẽ định tuyến lưu lượng truy cập dữ liệu mạng thông qua máy chủ proxy hoặc cổng VPN (ví dụ: tải trước dịch vụ VPN với android.permission.CONTROL_VPN được cấp), thì các cơ chế đó:

[C-2-1] PHẢI yêu cầu người dùng đồng ý trước khi bật cơ chế đó, trừ phi Trình điều khiển chính sách thiết bị bật VPN đó thông qua DevicePolicyManager.setAlwaysOnVpnPackage(). Trong trường hợp này, người dùng không cần phải đồng ý riêng, nhưng PHẢI chỉ được thông báo.

Nếu việc triển khai thiết bị triển khai một tính năng hỗ trợ người dùng để bật/tắt chức năng "VPN luôn bật" của ứng dụng VPN bên thứ ba, thì các tính năng đó:

[C-3-1] PHẢI tắt tính năng hỗ trợ người dùng này đối với các ứng dụng không hỗ trợ dịch vụ VPN luôn bật trong tệp AndroidManifest.xml thông qua việc đặt thuộc tính SERVICE_META_DATA_SUPPORTS_ALWAYS_ON thành false.

9.8.5. Thông tin nhận dạng thiết bị

Triển khai trên thiết bị:

[C-0-1] PHẢI ngăn chặn quyền truy cập vào số sê-ri thiết bị và (nếu có) IMEI/MEID, số sê-ri SIM và Mã nhận dạng thuê bao di động quốc tế (IMSI) từ một ứng dụng, trừ phi ứng dụng đó đáp ứng một trong các yêu cầu sau:
- là ứng dụng của nhà mạng đã ký và được nhà sản xuất thiết bị xác minh.
- đã được cấp quyền READ_PRIVILEGED_PHONE_STATE.
- có các đặc quyền của nhà mạng như được xác định trong phần Đặc quyền của nhà mạng đối với UICC.
- là chủ sở hữu thiết bị hoặc chủ sở hữu hồ sơ đã được cấp quyền READ_PHONE_STATE.
- (Chỉ dành cho số sê-ri SIM/ICCID) có quy định của địa phương yêu cầu ứng dụng phát hiện các thay đổi về danh tính của người đăng ký.

9.8.6. Ghi lại nội dung và Tìm kiếm trong ứng dụngDữ liệu môi trường xung quanh và cấp hệ điều hành

Android, thông qua các API hệ thống ~~ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query hoặc bằng các phương tiện độc quyền khác~~, hỗ trợ một cơ chế triển khai thiết bị để ghi lại ~~các hoạt động tương tác dữ liệu ứng dụng giữa các ứng dụng và người dùng~~ dữ liệu nhạy cảm sau đây:

Văn bản và đồ hoạ hiển thị trên màn hình, bao gồm nhưng không giới hạn ở thông báo và dữ liệu hỗ trợ thông qua API AssistStructure.
Dữ liệu nội dung nghe nhìn, chẳng hạn như âm thanh hoặc video, do thiết bị ghi lại hoặc phát.
Sự kiện đầu vào (ví dụ: phím, chuột, cử chỉ, giọng nói, video và hỗ trợ tiếp cận).

Bắt đầu yêu cầu mới

Mọi màn hình hoặc dữ liệu khác được gửi qua AugmentedAutofillService đến hệ thống.
Mọi màn hình hoặc dữ liệu khác có thể truy cập được qua API Content Capture.
Mọi màn hình hoặc dữ liệu khác có thể truy cập được qua API FieldClassificationService
Mọi dữ liệu ứng dụng được truyền đến hệ thống thông qua API AppSearchManager và có thể truy cập được thông qua AppSearchGlobalManager.query.

Kết thúc các yêu cầu mới

Mọi sự kiện khác mà ứng dụng cung cấp cho hệ thống thông qua API Content Capture hoặc API AppSearchManager, một API Android và API độc quyền có khả năng tương tự.

Mọi văn bản hoặc dữ liệu khác được gửi qua TextClassifier API đến System TextClassifier (tức là dịch vụ hệ thống) để hiểu ý nghĩa của văn bản, cũng như tạo các hành động tiếp theo được dự đoán dựa trên văn bản đó.
Dữ liệu được lập chỉ mục bằng cách triển khai AppSearch trên nền tảng, bao gồm nhưng không giới hạn ở văn bản, đồ hoạ, dữ liệu phương tiện hoặc dữ liệu tương tự khác.

Bắt đầu yêu cầu mới

Dữ liệu âm thanh thu được do việc sử dụng SpeechRecognizer#onDeviceSpeechRecognizer() trong quá trình Triển khai tính năng Nhận dạng lời nói.
Dữ liệu âm thanh được lấy ở chế độ nền (liên tục) thông qua AudioRecord, SoundTrigger hoặc các API Âm thanh khác và không dẫn đến chỉ báo mà người dùng có thể nhìn thấy
Dữ liệu máy ảnh được lấy ở chế độ nền (liên tục) thông qua CameraManager hoặc các API Máy ảnh khác và không dẫn đến chỉ báo hiển thị cho người dùng

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị thu thập bất kỳ dữ liệu nào ở trên, thì các dữ liệu đó:

[C-1-1] PHẢI mã hoá tất cả dữ liệu đó khi lưu trữ trong thiết bị. Bạn CÓ THỂ thực hiện quá trình mã hoá này bằng cách sử dụng tính năng Mã hoá dựa trên tệp Android hoặc bất kỳ thuật toán mã hoá nào được liệt kê là API phiên bản 26 trở lên được mô tả trong SDK Cipher.
[C-1-2] KHÔNG ĐƯỢC sao lưu dữ liệu thô hoặc dữ liệu đã mã hoá bằng các phương thức sao lưu của Android hoặc bất kỳ phương thức sao lưu nào khác.
[C-1-3] CHỈ ĐƯỢC gửi tất cả dữ liệu đó ~~và nhật ký~~ ra khỏi thiết bị bằng cơ chế bảo vệ quyền riêng tư, ngoại trừ trường hợp có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được chia sẻ. Cơ chế bảo vệ quyền riêng tư được xác định là "những cơ chế chỉ cho phép phân tích tổng hợp và ngăn việc so khớp các sự kiện đã ghi lại hoặc kết quả phái sinh với từng người dùng", để ngăn chặn việc xem xét bất kỳ dữ liệu nào trên mỗi người dùng (ví dụ: được triển khai bằng công nghệ quyền riêng tư biệt lập như RAPPOR).
[C-1-4] KHÔNG ĐƯỢC liên kết dữ liệu đó với bất kỳ danh tính người dùng nào (chẳng hạn như Account) trên thiết bị, trừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được liên kết.
[C-1-5] KHÔNG ĐƯỢC chia sẻ dữ liệu đó với các thành phần hệ điều hành khác không tuân thủ các yêu cầu nêu trong mục hiện tại (9.8.6 ~~Ghi lại nội dung~~ Dữ liệu cấp hệ điều hành và môi trường xung quanh), ngoại trừ khi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được chia sẻ. Trừ phi chức năng đó được tạo dưới dạng API SDK Android (AmbientContext, HotwordDetectionService).
[C-1-6] PHẢI cung cấp cho người dùng khả năng xoá những dữ liệu mà quá trình triển khai ~~ContentCaptureService~~ hoặc phương tiện độc quyền thu thập ~~nếu~~ khi dữ liệu được lưu trữ ở bất kỳ dạng nào trên thiết bị. Nếu người dùng chọn xoá dữ liệu, PHẢI xoá tất cả dữ liệu trong quá khứ đã thu thập.
[C-1-7] PHẢI cung cấp cho người dùng khả năng chọn không hiển thị dữ liệu được thu thập qua AppSearch hoặc các phương tiện độc quyền trong nền tảng Android, ví dụ: trình chạy.
[C-SR-1] KHÔNG NÊN yêu cầu quyền truy cập INTERNET.
[C-SR-2] Bạn NÊN chỉ truy cập Internet thông qua các API có cấu trúc được hỗ trợ bởi các phương thức triển khai nguồn mở có sẵn công khai.

Bắt đầu yêu cầu mới

[C-SR-4] Bạn NÊN triển khai bằng API SDK Android hoặc một kho lưu trữ nguồn mở tương tự do OEM sở hữu; và / hoặc được thực hiện trong quá trình triển khai Hộp cát (xem phần 9.8.15 Triển khai API Hộp cát).

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị bao gồm một dịch vụ triển khai API Hệ thống ContentCaptureService, AppSearchManager.index hoặc bất kỳ dịch vụ độc quyền nào thu thập dữ liệu như mô tả ở trên, thì các dịch vụ đó:

[C-2-1] KHÔNG ĐƯỢC cho phép người dùng thay thế các dịch vụ bằng một ứng dụng hoặc dịch vụ mà người dùng có thể cài đặt và CHỈ ĐƯỢC cho phép các dịch vụ được cài đặt sẵn thu thập dữ liệu đó.
[C-2-2] KHÔNG ĐƯỢC cho phép bất kỳ ứng dụng nào khác ngoài cơ chế dịch vụ được cài đặt sẵn có thể thu thập dữ liệu đó.
[C-2-3] PHẢI cung cấp cho người dùng khả năng tắt các dịch vụ.
[C-2-4] KHÔNG ĐƯỢC bỏ qua khả năng hỗ trợ người dùng để quản lý các quyền trên Android mà các dịch vụ nắm giữ và tuân theo mô hình quyền trên Android như mô tả trong Mục 9.1. Quyền.
[C-SR-3] Bạn NÊN tách biệt các dịch vụ với các thành phần hệ thống khác(ví dụ: không liên kết dịch vụ hoặc chia sẻ mã nhận dạng quy trình) ngoại trừ những trường hợp sau:
- Điện thoại, Danh bạ, Giao diện người dùng hệ thống và Nội dung nghe nhìn

Android, thông qua SpeechRecognizer#onDeviceSpeechRecognizer(), cung cấp khả năng nhận dạng lời nói trên thiết bị mà không cần đến mạng. Mọi hoạt động triển khai SpeechRecognizer trên thiết bị PHẢI tuân thủ các chính sách nêu trong phần này.

9.8.7. Quyền truy cập vào bảng nhớ tạm

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC trả về dữ liệu đã cắt từ bảng nhớ tạm (ví dụ: thông qua API ClipboardManager) trừ phi ứng dụng bên thứ ba là IME mặc định hoặc là ứng dụng hiện có tiêu điểm.
[C-0-2] PHẢI xoá dữ liệu trên bảng nhớ tạm tối đa 60 phút sau lần gần nhất dữ liệu được đặt vào bảng nhớ tạm hoặc được đọc từ bảng nhớ tạm.

9.8.8. Vị trí

Vị trí bao gồm thông tin trong lớp Vị trí Android( chẳng hạn như Vĩ độ, Kinh độ, Cao độ), cũng như các giá trị nhận dạng có thể chuyển đổi thành Vị trí. Vị trí có thể chính xác như DGPS (Hệ thống định vị toàn cầu vi phân) hoặc thô như vị trí ở cấp quốc gia (chẳng hạn như vị trí mã quốc gia – MCC – Mã quốc gia di động).

Sau đây là danh sách các loại vị trí trực tiếp lấy thông tin vị trí của người dùng hoặc có thể được chuyển đổi thành vị trí của người dùng. Đây không phải là danh sách đầy đủ, nhưng bạn có thể dùng danh sách này làm ví dụ về những thông tin có thể được lấy trực tiếp hoặc gián tiếp từ Thông tin vị trí:

GPS/GNSS/DGPS/PPP
- Giải pháp định vị toàn cầu hoặc Hệ thống vệ tinh điều hướng toàn cầu hoặc Giải pháp định vị toàn cầu vi phân
- Điều này cũng bao gồm các phép đo GNSS thô và Trạng thái GNSS
  - Vị trí chính xác có thể được lấy từ các phép đo GNSS thô
Công nghệ không dây có giá trị nhận dạng duy nhất, chẳng hạn như:
- Điểm truy cập Wi-Fi (MAC, BSSID, Tên hoặc SSID)
- Bluetooth/BLE (MAC, BSSID, Tên hoặc SSID)
- UWB (MAC, BSSID, Tên hoặc SSID)
- Mã tháp di động (3G, 4G, 5G… bao gồm tất cả các công nghệ Modem di động trong tương lai có giá trị nhận dạng duy nhất)

Để tham khảo chính, hãy xem các API Android yêu cầu quyền ACCESS_FINE_Location hoặc ACCESS_COARSE_Location.

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC bật/tắt chế độ cài đặt vị trí của thiết bị và chế độ cài đặt quét Wi-Fi/Bluetooth khi chưa có sự đồng ý rõ ràng của người dùng hoặc khi người dùng chưa bắt đầu.
[C-0-2] PHẢI cung cấp cho người dùng khả năng truy cập thông tin liên quan đến vị trí, bao gồm cả các yêu cầu vị trí gần đây, quyền cấp ứng dụng và việc sử dụng tính năng quét Wi-Fi/Bluetooth để xác định vị trí.
[C-0-3] PHẢI đảm bảo rằng ứng dụng sử dụng API Bỏ qua vị trí khẩn cấp [LocationRequest.setLocationSettingsIgnored()] là một phiên khẩn cấp do người dùng khởi tạo (ví dụ: gọi 911 hoặc nhắn tin đến 911). Tuy nhiên, đối với Ô tô, một xe CÓ THỂ khởi tạo phiên khẩn cấp mà không cần người dùng tương tác trong trường hợp phát hiện sự cố/tai nạn (ví dụ: để đáp ứng các yêu cầu của eCall).
[C-0-4] PHẢI duy trì khả năng của API Bỏ qua vị trí khẩn cấp để bỏ qua chế độ cài đặt vị trí của thiết bị mà không thay đổi chế độ cài đặt.
[C-0-5] PHẢI lên lịch thông báo nhắc người dùng sau khi một ứng dụng ở chế độ nền truy cập thông tin vị trí của họ bằng quyền [ACCESS_BACKGROUND_LOCATION].

9.8.9. Ứng dụng đã cài đặt

Theo mặc định, các ứng dụng Android nhắm đến API cấp 30 trở lên không thể xem thông tin chi tiết về các ứng dụng đã cài đặt khác (xem phần Chế độ hiển thị gói trong tài liệu về SDK Android).

Triển khai trên thiết bị:

[C-0-1] KHÔNG ĐƯỢC tiết lộ cho bất kỳ ứng dụng nào nhắm đến API cấp 30 trở lên thông tin chi tiết về bất kỳ ứng dụng đã cài đặt nào khác, trừ phi ứng dụng đó đã có thể xem thông tin chi tiết về ứng dụng đã cài đặt khác thông qua các API được quản lý. Điều này bao gồm nhưng không giới hạn ở thông tin chi tiết do bất kỳ API tuỳ chỉnh nào do trình triển khai thiết bị thêm vào hoặc có thể truy cập thông qua hệ thống tệp.
[C-0-2] KHÔNG ĐƯỢC cấp cho bất kỳ ứng dụng nào quyền đọc hoặc ghi vào các tệp trong thư mục chuyên dụng, dành riêng cho ứng dụng của bất kỳ ứng dụng nào khác trong bộ nhớ ngoài. Chỉ có các trường hợp ngoại lệ sau đây:
- Quyền của nhà cung cấp bộ nhớ ngoài (ví dụ: các ứng dụng như DocumentsUI).
- Trình cung cấp tệp tải xuống sử dụng quyền của trình cung cấp "tải xuống" để tải tệp xuống bộ nhớ ứng dụng.
- Các ứng dụng giao thức truyền nội dung nghe nhìn (MTP) do nền tảng ký sử dụng quyền đặc quyền ACCESS_MTP để cho phép chuyển tệp sang một thiết bị khác.
- Những ứng dụng cài đặt ứng dụng khác và có quyền INSTALL_PACKAGES chỉ có thể truy cập vào thư mục "obb" cho mục đích quản lý tệp mở rộng APK.

9.8.10. Báo cáo lỗi kết nối

Nếu quá trình triển khai thiết bị khai báo cờ tính năng android.hardware.telephony, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ tạo báo cáo lỗi kết nối thông qua BugreportManager với BUGREPORT_MODE_TELEPHONY.
[C-1-2] PHẢI xin phép người dùng mỗi khi sử dụng BUGREPORT_MODE_TELEPHONY để tạo báo cáo và KHÔNG ĐƯỢC nhắc người dùng đồng ý với tất cả các yêu cầu trong tương lai của ứng dụng.
[C-1-3] KHÔNG ĐƯỢC trả về báo cáo đã tạo cho ứng dụng yêu cầu mà không có sự đồng ý rõ ràng của người dùng.
[C-1-4] Báo cáo được tạo bằng BUGREPORT_MODE_TELEPHONY PHẢI chứa ít nhất những thông tin sau:
- Tệp báo lỗi TelephonyDebugService
- Tệp báo lỗi TelephonyRegistry
- Tệp báo lỗi WifiService
- Tệp báo lỗi ConnectivityService
- Tệp kết xuất của thực thể CarrierService của gói gọi (nếu được liên kết)
- Bộ đệm nhật ký qua đài
- Tệp báo lỗi SubscriptionManagerService
[C-1-5] KHÔNG ĐƯỢC đưa những thông tin sau vào báo cáo được tạo:
- Mọi loại thông tin không liên quan trực tiếp đến việc gỡ lỗi kết nối.
- Mọi loại nhật ký lưu lượng truy cập ứng dụng do người dùng cài đặt hoặc hồ sơ chi tiết về các ứng dụng/gói do người dùng cài đặt (có thể cung cấp UID, không được cung cấp tên gói).
CÓ THỂ bao gồm thông tin bổ sung không liên kết với bất kỳ danh tính người dùng nào. (ví dụ: nhật ký nhà cung cấp).

Nếu quá trình triển khai thiết bị đưa thêm thông tin (ví dụ: nhật ký của nhà cung cấp) vào báo cáo lỗi và thông tin đó có tác động đến quyền riêng tư/mức độ bảo mật/pin/bộ nhớ/dung lượng, thì:

[C-SR-1] NÊN đặt chế độ cài đặt dành cho nhà phát triển thành tắt theo mặc định. Việc triển khai tham chiếu AOSP đáp ứng điều này bằng cách cung cấp tuỳ chọn Enable verbose vendor logging trong phần cài đặt dành cho nhà phát triển để thêm nhật ký bổ sung của nhà cung cấp dành riêng cho thiết bị vào báo cáo lỗi.

9.8.11. Chia sẻ blob dữ liệu

Android, thông qua BlobStoreManager, cho phép các ứng dụng đóng góp blob dữ liệu vào Hệ thống để chia sẻ với một nhóm ứng dụng đã chọn.

Nếu việc triển khai thiết bị hỗ trợ các blob dữ liệu dùng chung như mô tả trong tài liệu SDK, thì các thiết bị đó:

[C-1-1] KHÔNG ĐƯỢC chia sẻ các blob dữ liệu thuộc về ứng dụng ngoài phạm vi mà ứng dụng cho phép (tức là phạm vi truy cập mặc định và các chế độ truy cập khác có thể được chỉ định bằng cách sử dụng BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() hoặc BlobStoreManager.session#allowPublicAccess() KHÔNG ĐƯỢC sửa đổi). Phương thức triển khai tham chiếu AOSP đáp ứng các yêu cầu này.
[C-1-2] KHÔNG ĐƯỢC gửi ra khỏi thiết bị hoặc chia sẻ với các ứng dụng khác hàm băm an toàn của các blob dữ liệu (dùng để kiểm soát quyền truy cập).

9.8.12. Nhận dạng nhạc

Android, thông qua API Hệ thống MusicRecognitionManager, hỗ trợ một cơ chế triển khai thiết bị để yêu cầu nhận dạng nhạc, dựa trên bản ghi âm và uỷ quyền nhận dạng nhạc cho một ứng dụng đặc quyền triển khai API MusicRecognitionService.

Nếu quá trình triển khai thiết bị bao gồm một dịch vụ triển khai MusicRecognitionManager API hệ thống hoặc bất kỳ dịch vụ độc quyền nào truyền trực tuyến dữ liệu âm thanh như mô tả ở trên, thì các dịch vụ đó:

[C-1-1] PHẢI thực thi để phương thức gọi của MusicRecognitionManager có quyền MANAGE_MUSIC_RECOGNITION
[C-1-2] PHẢI thực thi việc một ứng dụng nhận dạng nhạc được cài đặt sẵn duy nhất triển khai MusicRecognitionService.
[C-1-3] KHÔNG ĐƯỢC cho phép người dùng thay thế MusicRecognitionManagerService hoặc MusicRecognitionService bằng một ứng dụng hoặc dịch vụ mà người dùng có thể cài đặt.
[C-1-4] PHẢI đảm bảo rằng khi MusicRecognitionManagerService truy cập vào bản ghi âm và chuyển tiếp bản ghi đó đến ứng dụng triển khai MusicRecognitionService, quyền truy cập vào âm thanh sẽ được theo dõi thông qua các lệnh gọi của AppOpsManager.noteOp / startOp.

Nếu việc triển khai MusicRecognitionManagerService hoặc MusicRecognitionService trên thiết bị lưu trữ bất kỳ dữ liệu âm thanh nào được ghi lại, thì các dịch vụ này:

[C-2-1] KHÔNG ĐƯỢC lưu trữ bất kỳ âm thanh thô hoặc vân tay âm thanh nào trên ổ đĩa hoặc trong bộ nhớ quá 14 ngày.
[C-2-2] KHÔNG ĐƯỢC chia sẻ dữ liệu đó ngoài MusicRecognitionService, ngoại trừ khi có sự đồng ý rõ ràng của người dùng mỗi khi chia sẻ dữ liệu.

9.8.13. SensorPrivacyManager

Nếu việc triển khai thiết bị cung cấp cho người dùng một tính năng phần mềm để tắt đầu vào máy ảnh và/hoặc micrô cho việc triển khai thiết bị, thì họ:

[C-1-1] PHẢI trả về chính xác giá trị "true" cho phương thức API supportsSensorToggle() liên quan.
[C-1-2] PHẢI, khi một ứng dụng cố gắng truy cập vào micrô hoặc máy ảnh bị chặn, hãy hiển thị cho người dùng một chức năng không thể đóng được, cho biết rõ rằng cảm biến bị chặn và yêu cầu người dùng chọn tiếp tục chặn hoặc bỏ chặn theo cách triển khai AOSP đáp ứng yêu cầu này.
[C-1-3] CHỈ ĐƯỢC truyền dữ liệu âm thanh và máy ảnh trống (hoặc giả) đến các ứng dụng và không được báo cáo mã lỗi do người dùng không bật máy ảnh hoặc micrô thông qua khả năng hỗ trợ người dùng được trình bày theo [C-1-2] ở trên.

Bắt đầu yêu cầu mới

9.8.14. Trình quản lý thông tin xác thực

Đã xoá.

9.8.15. Triển khai API trong hộp cát

Android, thông qua một bộ API uỷ quyền, cung cấp cơ chế để xử lý dữ liệu môi trường và dữ liệu cấp hệ điều hành một cách an toàn. Bạn có thể uỷ quyền cho một tệp apk được cài đặt sẵn có quyền truy cập đặc biệt và giảm khả năng giao tiếp, được gọi là Triển khai API trong hộp cát.

Mọi hoạt động triển khai API Hộp cát:

[C-0-1] KHÔNG ĐƯỢC yêu cầu quyền INTERNET.
[C-0-2] CHỈ ĐƯỢC truy cập Internet thông qua các API có cấu trúc được hỗ trợ bằng các phương thức triển khai nguồn mở có sẵn công khai bằng cách sử dụng cơ chế bảo vệ quyền riêng tư hoặc gián tiếp thông qua các API SDK Android. Cơ chế bảo vệ quyền riêng tư được xác định là "những cơ chế chỉ cho phép phân tích tổng hợp và ngăn việc so khớp các sự kiện đã ghi lại hoặc kết quả phái sinh với từng người dùng", để ngăn chặn việc xem xét bất kỳ dữ liệu nào trên mỗi người dùng (ví dụ: được triển khai bằng công nghệ bảo vệ quyền riêng tư biệt lập như RAPPOR).
[C-0-3] PHẢI tách biệt các dịch vụ với các thành phần hệ thống khác (ví dụ: không liên kết dịch vụ hoặc chia sẻ mã nhận dạng quy trình) ngoại trừ các trường hợp sau:
- Điện thoại, Danh bạ, Giao diện người dùng hệ thống và Nội dung nghe nhìn
[C-0-4] KHÔNG ĐƯỢC cho phép người dùng thay thế các dịch vụ bằng một ứng dụng hoặc dịch vụ mà người dùng có thể cài đặt
[C-0-5] PHẢI chỉ cho phép các dịch vụ được cài đặt sẵn thu thập dữ liệu đó. Trừ phi chức năng thay thế được tích hợp vào AOSP (ví dụ: đối với Ứng dụng Trợ lý kỹ thuật số).
[C-0-6] KHÔNG ĐƯỢC cho phép bất kỳ ứng dụng nào khác ngoài cơ chế dịch vụ được cài đặt sẵn có thể thu thập dữ liệu đó. Trừ phi khả năng chụp đó được triển khai bằng API SDK Android.
[C-0-7] PHẢI cung cấp cho người dùng khả năng tắt các dịch vụ.
[C-0-8] KHÔNG ĐƯỢC bỏ qua khả năng hỗ trợ người dùng để quản lý các quyền trên Android mà các dịch vụ nắm giữ và tuân theo mô hình quyền trên Android như mô tả trong Mục 9.1. Quyền.

9.8.16. Dữ liệu liên tục về âm thanh và máy ảnh

Ngoài các yêu cầu nêu trong phần 9.8.2 Ghi, 9.8.6 Dữ liệu môi trường xung quanh và cấp hệ điều hành và 9.8.15 Triển khai API trong hộp cát, các phương thức triển khai sử dụng dữ liệu Âm thanh thu được ở chế độ nền (liên tục) thông qua AudioRecord, SoundTrigger hoặc các API Âm thanh khác HOẶC dữ liệu Máy ảnh thu được ở chế độ nền (liên tục) thông qua CameraManager hoặc các API Máy ảnh khác:

[C-0-1] PHẢI thực thi chỉ báo tương ứng (máy ảnh và/hoặc micrô theo mục 9.8.2 Ghi), trừ phi:
- Quyền truy cập này được thực hiện trong quá trình triển khai Hộp cát (xem phần 9.8.15 Triển khai API Hộp cát), thông qua một gói chứa một hoặc nhiều vai trò sau: Trí tuệ giao diện người dùng hệ thống, Trí tuệ âm thanh môi trường xung quanh hệ thống, Trí tuệ âm thanh hệ thống, Trí tuệ thông báo hệ thống, Trí tuệ văn bản hệ thống hoặc Trí tuệ hình ảnh hệ thống.
- Quyền truy cập được thực hiện thông qua một hộp cát, được triển khai và thực thi thông qua các cơ chế trong AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- Ứng dụng Trợ lý kỹ thuật số thực hiện quyền truy cập vào âm thanh cho mục đích hỗ trợ, cung cấp SOURCE_HOTWORD làm nguồn âm thanh.
- Hệ thống sẽ thực hiện quyền truy cập và triển khai bằng mã nguồn mở.
[C-SR-1] NÊN yêu cầu người dùng đồng ý đối với mọi chức năng sử dụng dữ liệu đó và tắt theo mặc định.
[C-SR-2] NÊN áp dụng cùng một cách xử lý (tức là tuân theo các quy định hạn chế nêu trong phần 9.8.2 Bản ghi, 9.8.6 Dữ liệu môi trường xung quanh và cấp hệ điều hành, 9.8.15 Triển khai API trong hộp cát và 9.8.16 Dữ liệu âm thanh và máy ảnh liên tục) cho dữ liệu Máy ảnh đến từ một thiết bị đeo từ xa.

Nếu dữ liệu Máy ảnh được cung cấp từ một thiết bị đeo từ xa và được truy cập ở dạng chưa mã hoá bên ngoài Android OS, triển khai hộp cát hoặc chức năng hộp cát do WearableSensingManager tạo, thì dữ liệu đó:

[C-1-1] PHẢI cho thiết bị đeo từ xa biết để hiển thị một chỉ báo bổ sung ở đó.

Nếu thiết bị có khả năng tương tác với Ứng dụng trợ lý kỹ thuật số mà không cần từ khoá được chỉ định (xử lý truy vấn chung của người dùng hoặc phân tích sự hiện diện của người dùng thông qua máy ảnh):

[C-2-1] PHẢI đảm bảo việc triển khai như vậy được cung cấp bởi một gói có vai trò android.app.role.ASSISTANT.
[C-2-2] PHẢI đảm bảo việc triển khai đó sử dụng API Android HotwordDetectionService và/hoặc VisualQueryDetectionService.

9.8.17. Telemetry

Android lưu trữ nhật ký hệ thống và ứng dụng bằng API StatsLog. Các nhật ký này được quản lý thông qua API StatsManager mà các ứng dụng hệ thống đặc quyền có thể sử dụng.

StatsManager cũng cung cấp một cách để thu thập dữ liệu được phân loại là nhạy cảm về quyền riêng tư từ các thiết bị có cơ chế bảo vệ quyền riêng tư. Cụ thể, API StatsManager::query cung cấp khả năng truy vấn các danh mục chỉ số bị hạn chế được xác định trong StatsLog.

Mọi hoạt động triển khai truy vấn và thu thập chỉ số bị hạn chế từ StatsManager:

[C-0-1] PHẢI là ứng dụng/phương thức triển khai duy nhất trên thiết bị và có quyền READ_RESTRICTED_STATS.
[C-0-2] PHẢI chỉ gửi dữ liệu đo từ xa và nhật ký của thiết bị bằng cách sử dụng cơ chế bảo vệ quyền riêng tư. Cơ chế bảo đảm quyền riêng tư được xác định là "những cơ chế chỉ cho phép phân tích tổng hợp và ngăn việc so khớp các sự kiện đã ghi lại hoặc kết quả phái sinh với từng người dùng", để ngăn chặn việc xem xét bất kỳ dữ liệu nào trên mỗi người dùng (ví dụ: được triển khai bằng công nghệ bảo vệ quyền riêng tư vi phân như RAPPOR).
[C-0-3] KHÔNG ĐƯỢC liên kết dữ liệu đó với bất kỳ danh tính người dùng nào (chẳng hạn như Tài khoản) trên thiết bị.
[C-0-4] KHÔNG ĐƯỢC chia sẻ dữ liệu đó với các thành phần hệ điều hành khác không tuân thủ các yêu cầu nêu trong mục hiện tại (9.8.17 Dữ liệu đo từ xa bảo vệ quyền riêng tư).
[C-0-5] PHẢI cung cấp cho người dùng khả năng bật/tắt tính năng thu thập, sử dụng và chia sẻ dữ liệu đo từ xa bảo vệ quyền riêng tư.
[C-0-6] PHẢI cung cấp cho người dùng khả năng xoá dữ liệu mà quá trình triển khai thu thập nếu dữ liệu được lưu trữ ở bất kỳ hình thức nào trên thiết bị. Nếu người dùng chọn xoá dữ liệu, PHẢI xoá tất cả dữ liệu hiện được lưu trữ trên thiết bị.
[C-0-7] PHẢI công bố cách triển khai giao thức bảo vệ quyền riêng tư cơ bản trong kho lưu trữ nguồn mở.
[C-0-8 ]PHẢI thực thi các chính sách về việc chuyển dữ liệu trong phần này để kiểm soát việc thu thập dữ liệu trong các danh mục chỉ số bị hạn chế được xác định trong StatsLog.

Kết thúc các yêu cầu mới

9.9. Mã hoá bộ nhớ dữ liệu

Tất cả thiết bị PHẢI đáp ứng các yêu cầu của mục 9.9.1. Các thiết bị ra mắt ở cấp độ API thấp hơn cấp độ API của tài liệu này sẽ được miễn các yêu cầu của mục 9.9.2 và 9.9.3; thay vào đó, các thiết bị này PHẢI đáp ứng các yêu cầu trong mục 9.9 của tài liệu Định nghĩa về khả năng tương thích với Android tương ứng với cấp độ API mà thiết bị ra mắt.

9.9.1. Khởi động trực tiếp

Triển khai trên thiết bị:

[C-0-1] PHẢI triển khai các API chế độ Khởi động trực tiếp ngay cả khi các API đó không hỗ trợ tính năng Mã hoá bộ nhớ.
[C-0-2] Bạn VẪN PHẢI truyền phát Ý định ACTION_LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED để báo hiệu cho các ứng dụng nhận biết tính năng Khởi động trực tiếp rằng người dùng có thể sử dụng các vị trí lưu trữ được mã hoá của thiết bị (DE) và thông tin xác thực được mã hoá (CE).

9.9.2. Yêu cầu về mã hoá

Triển khai trên thiết bị:

[C-0-1] PHẢI mã hoá dữ liệu riêng tư của ứng dụng (phân vùng /data) cũng như phân vùng bộ nhớ dùng chung của ứng dụng (phân vùng /sdcard) nếu đó là một phần vĩnh viễn, không thể tháo rời của thiết bị.
[C-0-2] PHẢI bật tính năng mã hoá bộ nhớ dữ liệu theo mặc định tại thời điểm người dùng hoàn tất trải nghiệm thiết lập ngay khi mua.
[C-0-3] PHẢI đáp ứng yêu cầu mã hoá bộ nhớ dữ liệu nêu trên bằng cách triển khai một trong hai phương thức mã hoá sau:
- Mã hoá dựa trên tệp (FBE) và Mã hoá siêu dữ liệu như mô tả trong phần 9.9.3.1.
- Mã hoá ở cấp khối cho mỗi người dùng như mô tả trong phần 9.9.3.2.

9.9.3. Phương thức mã hoá

Nếu quá trình triển khai thiết bị được mã hoá, thì các thiết bị đó:

[C-1-1] PHẢI khởi động mà không yêu cầu người dùng cung cấp thông tin xác thực và cho phép các ứng dụng nhận biết tính năng Khởi động trực tiếp truy cập vào bộ nhớ được mã hoá của thiết bị (DE) sau khi thông báo ACTION_LOCKED_BOOT_COMPLETED được truyền tin.
[C-1-2] PHẢI chỉ cho phép truy cập vào bộ nhớ được mã hoá dành cho thông tin đăng nhập (CE) sau khi người dùng mở khoá thiết bị bằng cách cung cấp thông tin đăng nhập (ví dụ: mã xác thực, mã PIN, hình mở khoá hoặc vân tay) và thông báo ACTION_USER_UNLOCKED được truyền tin.
[C-1-13] KHÔNG ĐƯỢC cung cấp bất kỳ phương thức nào để mở khoá bộ nhớ được bảo vệ bằng CE mà không có thông tin xác thực do người dùng cung cấp, khoá ký quỹ đã đăng ký hoặc tiếp tục triển khai khi khởi động lại đáp ứng các yêu cầu trong mục 9.9.4.
[C-1-4] PHẢI sử dụng tính năng Xác minh quy trình khởi động.

9.9.3.1. Mã hoá dựa trên tệp bằng tính năng Mã hoá siêu dữ liệu

Nếu việc triển khai thiết bị sử dụng phương thức Mã hoá dựa trên tệp với tính năng Mã hoá siêu dữ liệu, thì các thiết bị đó:

[C-1-5] PHẢI mã hoá nội dung tệp và siêu dữ liệu hệ thống tệp bằng AES-256-XTS hoặc Adiantum. AES-256-XTS là viết tắt của Tiêu chuẩn mã hoá nâng cao (Advanced Encryption Standard) có độ dài khoá mã hoá 256 bit, hoạt động ở chế độ XTS; độ dài đầy đủ của khoá là 512 bit. Adiantum đề cập đến Adiantum-XChaCha12-AES, như được chỉ định tại https://github.com/google/adiantum. Siêu dữ liệu hệ thống tệp là dữ liệu như kích thước tệp, quyền sở hữu, chế độ và thuộc tính mở rộng (xattr).
[C-1-6] PHẢI mã hoá tên tệp bằng AES-256-CBC-CTS, AES-256-HCTR2 hoặc Adiantum.
[C-1-12] Nếu thiết bị có hướng dẫn Tiêu chuẩn mã hoá nâng cao (AES) (chẳng hạn như Tiện ích mã hoá ARMv8 trên thiết bị dựa trên ARM hoặc AES-NI trên thiết bị dựa trên x86), thì BẮT BUỘC phải sử dụng các tuỳ chọn dựa trên AES ở trên cho tên tệp, nội dung tệp và mã hoá siêu dữ liệu hệ thống tệp, chứ không phải Adiantum.
[C-1-13] PHẢI sử dụng hàm phái sinh khoá mạnh và không thể đảo ngược về mặt mã hoá (ví dụ: HKDF-SHA512) để phái sinh mọi khoá con cần thiết (ví dụ: khoá trên mỗi tệp) từ khoá CE và DE. "Mạnh về mặt mã hoá và không thể đảo ngược" có nghĩa là hàm dẫn xuất khoá có độ bảo mật ít nhất là 256 bit và hoạt động như một gia đình hàm ngẫu nhiên giả đối với các dữ liệu đầu vào.
[C-1-14] KHÔNG ĐƯỢC sử dụng cùng một khoá hoặc khoá con Mã hoá dựa trên tệp (FBE) cho nhiều mục đích mật mã (ví dụ: cho cả mã hoá và dẫn xuất khoá hoặc cho hai thuật toán mã hoá khác nhau).
[C-1-15] PHẢI đảm bảo rằng tất cả các khối nội dung tệp đã mã hoá không bị xoá trên bộ nhớ cố định đều được mã hoá bằng cách kết hợp khoá mã hoá và vectơ khởi chạy (IV) phụ thuộc vào cả tệp và độ dời trong tệp. Ngoài ra, tất cả các tổ hợp như vậy PHẢI khác nhau, ngoại trừ trường hợp quá trình mã hoá được thực hiện bằng phần cứng mã hoá nội tuyến chỉ hỗ trợ độ dài IV là 32 bit.
[C-1-16] PHẢI đảm bảo rằng tất cả tên tệp đã mã hoá chưa bị xoá trên bộ nhớ cố định trong các thư mục riêng biệt đều được mã hoá bằng cách sử dụng các tổ hợp riêng biệt của khoá mã hoá và vectơ khởi chạy (IV).
[C-1-17] PHẢI đảm bảo rằng tất cả các khối siêu dữ liệu hệ thống tệp đã mã hoá trên bộ nhớ cố định đều được mã hoá bằng cách sử dụng các tổ hợp riêng biệt của khoá mã hoá và vectơ khởi tạo (IV).
Các khoá bảo vệ vùng lưu trữ CE và DE cũng như siêu dữ liệu hệ thống tệp:
- [C-1-7] PHẢI được liên kết bằng phương thức mã hoá với Kho khoá dựa trên phần cứng. Kho khoá này PHẢI được liên kết với tính năng Xác minh quy trình khởi động và gốc đáng tin cậy của phần cứng thiết bị.
- [C-1-8] Khoá CE PHẢI được liên kết với thông tin xác thực màn hình khoá của người dùng.
- [C-1-9] Khoá CE PHẢI được liên kết với mật mã mặc định khi người dùng chưa chỉ định thông tin xác thực màn hình khoá.
- [C-1-10] PHẢI là duy nhất và khác biệt, nói cách khác, không có khoá CE hoặc khoá DE của người dùng nào khớp với khoá CE hoặc khoá DE của người dùng nào khác.
- [C-1-11] PHẢI sử dụng các thuật toán mã hoá, độ dài khoá và chế độ được hỗ trợ bắt buộc.
- [C-1-12] PHẢI được xoá một cách an toàn trong quá trình mở khoá và khoá trình tải khởi động như mô tả tại đây.
NÊN cho các ứng dụng thiết yếu được cài đặt sẵn (ví dụ: Chuông báo, Điện thoại, Messenger) biết về tính năng Khởi động trực tiếp.

Dự án nguồn mở Android ngược dòng cung cấp phương thức triển khai ưu tiên của tính năng Mã hoá dựa trên tệp dựa trên tính năng mã hoá "fscrypt" của nhân Linux và tính năng Mã hoá siêu dữ liệu dựa trên tính năng "dm-default-key" của nhân Linux.

9.9.3.2. Mã hoá ở cấp khối cho từng người dùng

Nếu việc triển khai thiết bị sử dụng phương thức mã hoá cấp khối cho mỗi người dùng, thì các thiết bị đó:

[C-1-1] PHẢI bật tính năng hỗ trợ nhiều người dùng như mô tả trong phần 9.5.
[C-1-2] PHẢI cung cấp các phân vùng cho mỗi người dùng, sử dụng phân vùng thô hoặc các phương tiện logic.
[C-1-3] PHẢI sử dụng khoá mã hoá riêng biệt và duy nhất cho mỗi người dùng để mã hoá các thiết bị khối cơ bản.
[C-1-4] PHẢI sử dụng AES-256-XTS để mã hoá cấp khối của các phân vùng người dùng.
Các khoá bảo vệ thiết bị được mã hoá ở cấp khối cho mỗi người dùng:
- [C-1-5] PHẢI được liên kết bằng phương thức mã hoá với Kho khoá dựa trên phần cứng. Kho khoá này PHẢI được liên kết với tính năng Xác minh quy trình khởi động và gốc đáng tin cậy của phần cứng thiết bị.
- [C-1-6] PHẢI liên kết với thông tin xác thực màn hình khoá của người dùng tương ứng.

Bạn có thể triển khai tính năng mã hoá ở cấp khối cho từng người dùng bằng cách sử dụng tính năng "dm-crypt" của nhân Linux trên các phân vùng cho từng người dùng.

9.9.4. Tiếp tục khi khởi động lại

Tính năng Tiếp tục khi khởi động lại cho phép mở khoá bộ nhớ CE của tất cả ứng dụng, bao gồm cả những ứng dụng chưa hỗ trợ tính năng Khởi động trực tiếp, sau khi khởi động lại do OTA khởi tạo. Tính năng này cho phép người dùng nhận thông báo từ các ứng dụng đã cài đặt sau khi khởi động lại.

Việc triển khai tính năng Tiếp tục khi khởi động lại phải tiếp tục đảm bảo rằng khi một thiết bị rơi vào tay kẻ tấn công, kẻ tấn công đó sẽ cực kỳ khó khôi phục dữ liệu đã mã hoá bằng CE của người dùng, ngay cả khi thiết bị đang bật, bộ nhớ CE đã mở khoá và người dùng đã mở khoá thiết bị sau khi nhận được OTA. Để chống lại cuộc tấn công nội bộ, chúng ta cũng giả định rằng kẻ tấn công có quyền truy cập để truyền phát các khoá ký mã hoá.

Cụ thể:

[C-0-1] Bộ nhớ CE KHÔNG ĐƯỢC đọc được ngay cả khi kẻ tấn công có thiết bị về mặt vật lý và sau đó có các chức năng và hạn chế sau:
- Có thể sử dụng khoá ký của bất kỳ nhà cung cấp hoặc công ty nào để ký thông báo tuỳ ý.
- Có thể khiến thiết bị nhận được OTA.
- Có thể sửa đổi hoạt động của bất kỳ phần cứng nào (AP, flash, v.v.) ngoại trừ như được nêu chi tiết bên dưới, nhưng việc sửa đổi như vậy sẽ gây ra độ trễ ít nhất là một giờ và một chu kỳ nguồn sẽ huỷ bỏ nội dung RAM.
- Không thể sửa đổi hoạt động của phần cứng chống can thiệp (ví dụ: Titan M).
- Không thể đọc RAM của thiết bị đang hoạt động.
- Không thể lấy thông tin xác thực của người dùng (mã PIN, hình mở khoá, mật khẩu) hoặc buộc người dùng nhập thông tin xác thực.

Ví dụ: một cách triển khai thiết bị triển khai và tuân thủ tất cả nội dung mô tả có tại đây sẽ tuân thủ [C-0-1].

9.10. Tính toàn vẹn của thiết bị

Các yêu cầu sau đây đảm bảo tính minh bạch về trạng thái của tính toàn vẹn của thiết bị. Triển khai trên thiết bị:

[C-0-1] PHẢI báo cáo chính xác thông qua phương thức API hệ thống PersistentDataBlockManager.getFlashLockState() liệu trạng thái trình tải khởi động có cho phép cài đặt ROM hình ảnh hệ thống hay không.
[C-0-2] PHẢI hỗ trợ tính năng Xác minh quy trình khởi động để đảm bảo tính toàn vẹn của thiết bị.

Nếu việc triển khai thiết bị đã bắt đầu mà không hỗ trợ tính năng Khởi động được xác minh trên một phiên bản Android cũ và không thể thêm tính năng hỗ trợ cho tính năng này bằng bản cập nhật phần mềm hệ thống, thì các thiết bị đó CÓ THỂ được miễn yêu cầu này.

Xác minh quy trình khởi động là một tính năng đảm bảo tính toàn vẹn của phần mềm thiết bị. Nếu việc triển khai thiết bị hỗ trợ tính năng này, thì các thiết bị đó:

[C-1-1] PHẢI khai báo cờ tính năng nền tảng android.software.verified_boot.
[C-1-2] PHẢI thực hiện quy trình xác minh trên mọi trình tự khởi động.
[C-1-3] PHẢI bắt đầu xác minh từ một khoá phần cứng không thể thay đổi, là gốc của niềm tin và đi đến phân vùng hệ thống.
[C-1-4] PHẢI triển khai từng giai đoạn xác minh để kiểm tra tính toàn vẹn và tính xác thực của tất cả các byte trong giai đoạn tiếp theo trước khi thực thi mã trong giai đoạn tiếp theo.
[C-1-5] PHẢI sử dụng các thuật toán xác minh mạnh mẽ như các đề xuất hiện tại của NIST đối với các thuật toán băm (SHA-256) và kích thước khoá công khai (RSA-2048).
[C-1-6] KHÔNG ĐƯỢC cho phép khởi động hoàn tất khi xác minh hệ thống không thành công, trừ phi người dùng đồng ý thử khởi động, trong trường hợp này, KHÔNG ĐƯỢC sử dụng dữ liệu từ bất kỳ khối bộ nhớ nào chưa được xác minh.
[C-1-7] KHÔNG ĐƯỢC cho phép sửa đổi các phân vùng đã xác minh trên thiết bị, trừ phi người dùng đã mở khoá trình tải khởi động một cách rõ ràng.
[C-SR-1] Nếu có nhiều khối riêng biệt trong thiết bị (ví dụ: đài phát thanh, bộ xử lý hình ảnh chuyên biệt), thì bạn NÊN xác minh mọi giai đoạn khi khởi động trong quá trình khởi động của từng khối đó.
[C-1-8] PHẢI sử dụng bộ nhớ chống can thiệp: để lưu trữ thông tin về việc trình tải khởi động có được mở khoá hay không. Bộ nhớ chống can thiệp có nghĩa là trình tải khởi động có thể phát hiện xem bộ nhớ có bị can thiệp từ bên trong Android hay không.
[C-1-9] PHẢI nhắc người dùng trong khi sử dụng thiết bị và yêu cầu xác nhận thực tế trước khi cho phép chuyển đổi từ chế độ khoá trình tải khởi động sang chế độ mở khoá trình tải khởi động.
[C-1-10] PHẢI triển khai tính năng bảo vệ tính năng khôi phục cho các phân vùng mà Android sử dụng (ví dụ: khởi động, phân vùng hệ thống) và sử dụng bộ nhớ chống can thiệp để lưu trữ siêu dữ liệu dùng để xác định phiên bản hệ điều hành tối thiểu được phép.
[C-1-11] PHẢI xoá tất cả dữ liệu người dùng một cách an toàn trong quá trình mở khoá và khoá trình tải khởi động, theo "9.12". Xoá dữ liệu" (bao gồm cả phân vùng userdata và mọi không gian NVRAM).
[C-SR-2] Bạn NÊN xác minh tất cả tệp APK của ứng dụng đặc quyền bằng một chuỗi tin cậy bắt nguồn từ các phân vùng được bảo vệ bằng tính năng Xác minh quy trình khởi động.
[C-SR-3] Bạn NÊN xác minh mọi cấu phần phần mềm thực thi do một ứng dụng đặc quyền tải từ bên ngoài tệp APK (chẳng hạn như mã được tải động hoặc mã được biên dịch) trước khi thực thi các cấu phần phần mềm đó hoặc KHÔNG NÊN thực thi các cấu phần phần mềm đó.
NÊN triển khai tính năng bảo vệ tính năng khôi phục cho mọi thành phần có firmware ổn định (ví dụ: modem, máy ảnh) và NÊN sử dụng bộ nhớ chống can thiệp để lưu trữ siêu dữ liệu dùng để xác định phiên bản tối thiểu được phép.

Nếu quá trình triển khai thiết bị đã bắt đầu mà không hỗ trợ C-1-8 đến C-1-11 trên một phiên bản Android cũ và không thể thêm tính năng hỗ trợ cho các yêu cầu này bằng bản cập nhật phần mềm hệ thống, thì các thiết bị đó CÓ THỂ được miễn các yêu cầu này.

Dự án nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên của tính năng này trong kho lưu trữ external/avb/. Kho lưu trữ này có thể được tích hợp vào trình tải khởi động dùng để tải Android.

~~Triển khai trên thiết bị~~

Nếu có khả năng xác minh nội dung tệp trên cơ sở mỗi trang, thì các phương thức triển khai thiết bị sẽ:

[~~C-0-3~~ C-2-1] hỗ trợ xác minh nội dung tệp bằng phương thức mã hoá ~~theo khoá đáng tin cậy~~ mà không cần đọc toàn bộ tệp.
[~~C-0-4~~ C-2-2] KHÔNG ĐƯỢC cho phép các yêu cầu đọc trên một tệp được bảo vệ thành công khi nội dung đọc ~~không xác minh theo khoá đáng tin cậy~~ không được xác minh theo [C-2-1] ở trên.

Bắt đầu yêu cầu mới

[C-2-4] PHẢI trả về tổng kiểm tra tệp trong O(1) đối với các tệp đã bật.

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị đã bắt đầu mà không có khả năng xác minh nội dung tệp dựa trên khoá đáng tin cậy trên phiên bản Android cũ hơn và không thể thêm tính năng hỗ trợ cho tính năng này bằng bản cập nhật phần mềm hệ thống, thì các thiết bị đó CÓ THỂ được miễn trừ khỏi yêu cầu này. Dự án nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên tính năng này dựa trên tính năng fs-verity của hạt nhân Linux.

Triển khai trên thiết bị:

[C-SR-4] Bạn NÊN hỗ trợ API Xác nhận được bảo vệ của Android.

Nếu việc triển khai thiết bị hỗ trợ API Xác nhận được bảo vệ của Android, thì các thiết bị đó:

[C-3-1] PHẢI báo cáo true cho API ConfirmationPrompt.isSupported().
[C-3-2] PHẢI đảm bảo rằng mã chạy trong hệ điều hành Android, bao gồm cả hạt nhân, độc hại hay không, không thể tạo phản hồi tích cực mà không có sự tương tác của người dùng.
[C-3-3] PHẢI đảm bảo rằng người dùng có thể xem lại và phê duyệt thông báo được nhắc ngay cả trong trường hợp hệ điều hành Android, bao gồm cả hạt nhân, bị xâm phạm.

9.11. Khoá và thông tin xác thực

Hệ thống Kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ khoá mã hoá trong một vùng chứa và sử dụng khoá đó trong các hoạt động mã hoá thông qua API KeyChain hoặc API Kho khoá. Triển khai trên thiết bị:

[C-0-1] PHẢI cho phép nhập hoặc tạo ít nhất 8.192 khoá.
[C-0-2] Quy trình xác thực màn hình khoá PHẢI triển khai khoảng thời gian giữa các lần xác thực không thành công. Với n là số lần thử không thành công, khoảng thời gian ĐẢM BẢO phải ít nhất là 30 giây đối với 9 < n < 30. Đối với n > 29, giá trị khoảng thời gian PHẢI từ 30*2^floor((n-30)/10)) giây trở lên hoặc từ 24 giờ trở lên, tuỳ theo giá trị nào nhỏ hơn.
KHÔNG được giới hạn số lượng khoá có thể tạo

Bắt đầu yêu cầu mới

[C-0-3] PHẢI giới hạn số lần xác thực chính không thành công.

[C-SR-2] Bạn NÊN triển khai giới hạn trên là 20 lần xác thực chính không thành công và nếu người dùng đồng ý và chọn sử dụng tính năng này, hãy thực hiện "Đặt lại dữ liệu gốc" sau khi vượt quá giới hạn số lần xác thực chính không thành công.

Nếu việc triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực để mở khoá màn hình khoá nếu dựa trên một bí mật đã biết và sử dụng một phương thức xác thực mới được coi là một cách an toàn để khoá màn hình, thì:

[C-SR-3] Bạn NÊN sử dụng mã PIN có ít nhất 6 chữ số, tương đương với độ hỗn loạn 20 bit.

[C-2-1] Mã PIN có độ dài dưới 6 chữ số KHÔNG ĐƯỢC cho phép nhập tự động mà không cần người dùng tương tác để tránh tiết lộ độ dài mã PIN.

Kết thúc các yêu cầu mới

Khi việc triển khai thiết bị hỗ trợ màn hình khoá bảo mật, thiết bị đó sẽ:

[C-1-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
[C-1-2] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA, ECDH (nếu IKeyMintDevice được hỗ trợ), 3DES và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và trên đó. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) đáp ứng yêu cầu này bằng cách sử dụng phương thức triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc phương thức triển khai bảo mật được bên thứ ba xem xét về việc tách biệt dựa trên trình điều khiển ảo hoá thích hợp là các lựa chọn thay thế.
[C-1-3] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi riêng biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Thông tin xác thực màn hình khoá PHẢI được lưu trữ theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện quy trình xác thực màn hình khoá. Dự án nguồn mở Android cấp trên cung cấp Lớp trừu tượng phần cứng của Gatekeeper (HAL) và Trusty. Bạn có thể sử dụng các lớp này để đáp ứng yêu cầu này.
[C-1-4] PHẢI hỗ trợ chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quá trình ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc sử dụng khoá làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu sản xuất hơn 100.000 đơn vị của một SKU, bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.

[C-1-5] PHẢI cho phép người dùng chọn thời gian chờ Chế độ ngủ để chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, với thời gian chờ tối thiểu cho phép lên đến 15 giây. Các thiết bị ô tô khoá màn hình bất cứ khi nào đầu phát trung tâm tắt hoặc người dùng chuyển đổi, KHÔNG ĐƯỢC có cấu hình Thời gian chờ chế độ Ngủ.
[C-1-6] PHẢI hỗ trợ một trong những tính năng sau:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice phiên bản 1 hoặc
- IKeyMintDevice phiên bản 2.
[C-SR-1] Bạn NÊN hỗ trợ IKeyMintDevice phiên bản 1.

9.11.1. Bảo mật màn hình khoá, xác thực và thiết bị ảo

Việc triển khai AOSP tuân theo mô hình xác thực theo tầng, trong đó xác thực chính dựa trên nhà máy kiến thức có thể được hỗ trợ bằng phương thức xác thực sinh trắc học mạnh phụ hoặc phương thức xác thực phụ yếu hơn.

Triển khai trên thiết bị:

[C-SR-1] Bạn NÊN chỉ đặt một trong những phương thức sau làm phương thức xác thực chính:
- Mã PIN dạng số
- Mật khẩu gồm chữ và số
- Một mẫu vuốt trên lưới gồm đúng 3x3 dấu chấm
  
  Xin lưu ý rằng các phương thức xác thực nêu trên được gọi là phương thức xác thực chính được đề xuất trong tài liệu này.

Bắt đầu yêu cầu mới

[C-0-1] PHẢI giới hạn số lần xác thực chính không thành công.
[C-SR-5] Bạn NÊN triển khai giới hạn trên là 20 lần xác thực chính không thành công và nếu người dùng đồng ý và chọn sử dụng tính năng này, hãy thực hiện "Đặt lại dữ liệu về trạng thái ban đầu" sau khi vượt quá giới hạn số lần xác thực chính không thành công.

Nếu việc triển khai thiết bị đặt mã PIN dạng số làm phương thức xác thực chính được đề xuất, thì:

[C-SR-6] Bạn NÊN sử dụng mã PIN có ít nhất 6 chữ số, tương đương với entropy 20 bit.
[C-SR-7] KHÔNG NÊN cho phép nhập tự động mã PIN có độ dài dưới 6 chữ số mà không cần người dùng tương tác để tránh tiết lộ độ dài mã PIN.

Kết thúc các yêu cầu mới

Nếu quá trình triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực chính được đề xuất và sử dụng một phương thức xác thực mới làm cách an toàn để khoá màn hình, thì phương thức xác thực mới:

[C-2-1] PHẢI là phương thức xác thực người dùng như mô tả trong phần Yêu cầu xác thực người dùng để sử dụng khoá.

Nếu việc triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực để mở khoá màn hình khoá nếu dựa trên một bí mật đã biết và sử dụng một phương thức xác thực mới được coi là cách an toàn để khoá màn hình:

[C-3-1] Độ hỗn loạn của độ dài đầu vào ngắn nhất được phép PHẢI lớn hơn 10 bit.
[C-3-2] Độ hỗn loạn tối đa của tất cả dữ liệu đầu vào có thể phải lớn hơn 18 bit.
[C-3-3] Phương thức xác thực mới KHÔNG ĐƯỢC thay thế bất kỳ phương thức xác thực chính nào được đề xuất (tức là mã PIN, hình mở khoá, mật khẩu) được triển khai và cung cấp trong AOSP.
[C-3-4] BẠN PHẢI tắt phương thức xác thực mới khi ứng dụng Trình điều khiển chính sách thiết bị (DPC) đã đặt chính sách yêu cầu mật khẩu thông qua DevicePolicyManager.setRequiredPasswordComplexity() với hằng số độ phức tạp hạn chế hơn PASSWORD_COMPLEXITY_NONE hoặc thông qua phương thức DevicePolicyManager.setPasswordQuality() với hằng số hạn chế hơn PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] Phương thức xác thực mới PHẢI quay lại các phương thức xác thực chính được đề xuất (tức là mã PIN, hình mở khoá, mật khẩu) mỗi 72 giờ một lần hoặc ít hơn HOẶC tiết lộ rõ ràng cho người dùng rằng một số dữ liệu sẽ không được sao lưu để bảo vệ quyền riêng tư của dữ liệu.

Nếu việc triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực chính được đề xuất để mở khoá màn hình khoá và sử dụng một phương thức xác thực mới dựa trên sinh trắc học để được coi là một cách an toàn để khoá màn hình, thì phương thức mới:

[C-4-1] PHẢI đáp ứng tất cả các yêu cầu được mô tả trong mục 7.3.10 đối với Lớp 1 (trước đây là Tiện lợi).
[C-4-2] PHẢI có cơ chế dự phòng để sử dụng một trong các phương thức xác thực chính được đề xuất dựa trên khoá bí mật đã biết.
[C-4-3] PHẢI tắt và chỉ cho phép phương thức xác thực chính được đề xuất mở khoá màn hình khi ứng dụng Bộ điều khiển chính sách thiết bị (DPC) đã đặt chính sách tính năng khoá phím bằng cách gọi phương thức DevicePolicyManager.setKeyguardDisabledFeatures() với bất kỳ cờ sinh trắc học nào được liên kết (tức là KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE hoặc KEYGUARD_DISABLE_IRIS).

Nếu các phương thức xác thực sinh trắc học không đáp ứng các yêu cầu đối với Lớp 3 (trước đây là Mạnh) như mô tả trong mục 7.3.10:

[C-5-1] BẠN PHẢI tắt các phương thức này nếu ứng dụng Trình điều khiển chính sách thiết bị (DPC) đã đặt chính sách chất lượng yêu cầu mật khẩu thông qua DevicePolicyManager.setRequiredPasswordComplexity() với bộ chứa độ phức tạp hạn chế hơn PASSWORD_COMPLEXITY_LOW hoặc sử dụng phương thức DevicePolicyManager.setPasswordQuality() với hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] Người dùng PHẢI được đưa ra thử thách để xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) như mô tả trong [C-1-7] và [C-1-8] trong mục 7.3.10.
[C-5-3] Các phương thức KHÔNG được coi là màn hình khoá bảo mật và PHẢI đáp ứng các yêu cầu bắt đầu bằng C-8 trong phần bên dưới.

Nếu việc triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực để mở khoá màn hình khoá và một phương thức xác thực mới dựa trên mã thông báo thực hoặc vị trí:

[C-6-1] Các phương thức này PHẢI có cơ chế dự phòng để sử dụng một trong các phương thức xác thực chính được đề xuất dựa trên khoá bí mật đã biết và đáp ứng các yêu cầu để được coi là màn hình khoá bảo mật.
[C-6-2] BẠN PHẢI tắt phương thức mới và chỉ cho phép một trong các phương thức xác thực chính được đề xuất để mở khoá màn hình khi ứng dụng Bộ điều khiển chính sách thiết bị (DPC) đã đặt chính sách bằng:
- Phương thức DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- Phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn so với PASSWORD_QUALITY_NONE.
- Phương thức DevicePolicyManager.setRequiredPasswordComplexity() có bộ chứa độ phức tạp hạn chế hơn so với PASSWORD_COMPLEXITY_NONE.
[C-6-3] Người dùng PHẢI được yêu cầu xác thực bằ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ở khoá, mật khẩu) ít nhất một lần trong vòng 4 giờ. Khi mã thông báo vật lý đáp ứng các yêu cầu để triển khai TrustAgent trong C-X, các quy định hạn chế về thời gian chờ được xác định trong C-9-5 sẽ được áp dụng.
[C-6-4] Phương thức mới KHÔNG ĐƯỢC coi là màn hình khoá bảo mật và PHẢI tuân theo các quy tắc ràng buộc nêu trong C-8 bên dưới.

Nếu quá trình triển khai thiết bị có màn hình khoá bảo mật và bao gồm một hoặc nhiều tác nhân đáng tin cậy triển khai API Hệ thống TrustAgentService, thì các thiết bị đó:

[C-7-1] PHẢI có chỉ báo rõ ràng trong trình đơn cài đặt và trên màn hình khoá khi phương thức khoá thiết bị bị trì hoãn hoặc có thể được(các) tác nhân tin cậy mở khoá. Ví dụ: AOSP đáp ứng yêu cầu này bằng cách hiển thị nội dung mô tả văn bản cho "Chế độ cài đặt tự động khoá" và "Nút nguồn khoá tức thì" trong trình đơn cài đặt và một biểu tượng dễ phân biệt trên màn hình khoá.
[C-7-2] PHẢI tuân thủ và triển khai đầy đủ tất cả API của tác nhân tin cậy trong lớp DevicePolicyManager, chẳng hạn như hằng số KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] KHÔNG ĐƯỢC triển khai đầy đủ hàm TrustAgentService.addEscrowToken() trên thiết bị dùng làm thiết bị cá nhân chính (ví dụ: thiết bị cầm tay), nhưng CÓ THỂ triển khai đầy đủ hàm này trên các phương thức triển khai thiết bị thường được chia sẻ (ví dụ: Android Television hoặc thiết bị ô tô).
[C-7-4] PHẢI mã hoá tất cả mã thông báo đã lưu trữ do TrustAgentService.addEscrowToken() thêm vào.
[C-7-5] KHÔNG ĐƯỢC lưu trữ khoá mã hoá hoặc mã thông báo ký quỹ trên cùng một thiết bị dùng khoá đó. Ví dụ: khoá được lưu trữ trên điện thoại được phép mở khoá tài khoản người dùng trên TV. Đối với thiết bị Automotive, mã thông báo ký gửi không được lưu trữ trên bất kỳ bộ phận nào của xe.
[C-7-6] PHẢI thông báo cho người dùng về các tác động bảo mật trước khi bật mã thông báo ký quỹ để giải mã bộ nhớ dữ liệu.
[C-7-7] PHẢI có cơ chế dự phòng để sử dụng một trong các phương thức xác thực chính được đề xuất.
[C-7-8] Người dùng PHẢI được yêu cầu xác thực bằ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ở khoá, mật khẩu) ít nhất một lần trong vòng 72 giờ, trừ phi cần quan tâm đến sự an toàn của người dùng (ví dụ: người lái xe bị phân tâm).
[C-7-9] Người dùng PHẢI được thử thách bằ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ở khoá, mật khẩu) như mô tả trong [C-1-7] và [C-1-8] trong mục 7.3.10, trừ phi bạn lo ngại về sự an toàn của người dùng (ví dụ: người lái xe bị phân tâm).
[C-7-10] KHÔNG ĐƯỢC coi là màn hình khoá bảo mật và PHẢI tuân theo các quy tắc ràng buộc được liệt kê trong C-8 bên dưới.
[C-7-11] KHÔNG ĐƯỢC cho phép TrustAgent trên các thiết bị cá nhân chính (ví dụ: thiết bị cầm tay) mở khoá thiết bị và chỉ có thể sử dụng các TrustAgent đó để giữ cho thiết bị đã mở khoá ở trạng thái mở khoá trong tối đa 4 giờ. Cách triển khai mặc định của TrustManagerService trong AOSP đáp ứng yêu cầu này.
[C-7-12] PHẢI sử dụng kênh giao tiếp bảo mật bằng mật mã (ví dụ: UKEY2) để truyền mã thông báo ký quỹ từ thiết bị lưu trữ sang thiết bị mục tiêu.

Nếu việc triển khai thiết bị thêm hoặc sửa đổi các phương thức xác thực để mở khoá màn hình khoá không phải là màn hình khoá an toàn như mô tả ở trên và sử dụng một phương thức xác thực mới để mở khoá khoá màn hình:

[C-8-1] BẠN PHẢI tắt phương thức mới khi ứng dụng Trình điều khiển chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_NONE hoặc thông qua DevicePolicyManager.setRequiredPasswordComplexity() có hằng số độ phức tạp hạn chế hơn 'PASSWORD_COMPLEXITY_NONE'.
[C-8-2] Chúng KHÔNG ĐƯỢC đặt lại bộ hẹn giờ hết hạn mật khẩu do DevicePolicyManager.setPasswordExpirationTimeout() đặt.
[C-8-3] Các ứng dụng này KHÔNG ĐƯỢC hiển thị API để các ứng dụng bên thứ ba sử dụng nhằm thay đổi trạng thái khoá.

Nếu việc triển khai thiết bị cho phép ứng dụng tạo màn hình ảo phụ và không hỗ trợ các sự kiện đầu vào liên kết, chẳng hạn như thông qua VirtualDeviceManager, thì các ứng dụng đó:

[C-9-1] PHẢI khoá(các) màn hình ảo phụ này khi màn hình mặc định của thiết bị bị khoá và mở khoá(các) màn hình ảo phụ này khi màn hình mặc định của thiết bị được mở khoá.

Nếu việc triển khai thiết bị cho phép các ứng dụng tạo màn hình ảo phụ và hỗ trợ các sự kiện đầu vào liên quan, chẳng hạn như thông qua VirtualDeviceManager, thì các ứng dụng đó:

[C-10-1] PHẢI hỗ trợ các trạng thái khoá riêng biệt cho mỗi thiết bị ảo
[C-10-2] PHẢI ngắt kết nối tất cả thiết bị ảo khi hết thời gian chờ ở trạng thái rảnh
[C-10-3] PHẢI có thời gian chờ khi rảnh
[C-10-4] PHẢI khoá tất cả màn hình khi người dùng bắt đầu khoá, bao gồm cả thông qua tính năng hỗ trợ người dùng khoá cần thiết cho thiết bị cầm tay (xem Mục 2.2.5[9.11/H-1-2])
[C-10-5] PHẢI có các phiên bản thiết bị ảo riêng biệt cho mỗi người dùng
[C-10-6] PHẢI tắt tính năng tạo sự kiện đầu vào được liên kết thông qua VirtualDeviceManager khi DevicePolicyManager.setNearbyAppStreamingPolicy cho biết
[C-10-7] PHẢI sử dụng một bảng nhớ tạm riêng cho mỗi thiết bị ảo (hoặc tắt bảng nhớ tạm cho các thiết bị ảo)
[C-10-11] PHẢI tắt giao diện người dùng xác thực trên thiết bị ảo, bao gồm cả mục nhập yếu tố tri thức và lời nhắc sinh trắc học
[C-10-12] PHẢI hạn chế các ý định được bắt đầu từ một thiết bị ảo để chỉ hiển thị trên cùng một thiết bị ảo
[C-10-13] KHÔNG được sử dụng trạng thái khoá thiết bị ảo làm trạng thái uỷ quyền xác thực người dùng bằng Hệ thống kho khoá Android. Xem KeyGenParameterSpec.Builder.setUserAuthentication*.

Khi việc triển khai thiết bị cho phép người dùng chuyển yếu tố tri thức xác thực chính từ thiết bị nguồn sang thiết bị mục tiêu, chẳng hạn như để thiết lập ban đầu thiết bị mục tiêu, thì họ:

[C-11-1] PHẢI mã hoá yếu tố nhận dạng bằng các biện pháp bảo đảm tương tự như những biện pháp được mô tả trong tài liệu bảo mật về Dịch vụ Google Cloud Key Vault khi chuyển yếu tố nhận dạng từ thiết bị nguồn sang thiết bị mục tiêu để không thể giải mã yếu tố nhận dạng từ xa hoặc dùng yếu tố nhận dạng để mở khoá từ xa thiết bị nào.
[C-11-2] PHẢI yêu cầu người dùng xác nhận hệ số kiến thức của thiết bị nguồn trên thiết bị nguồn trước khi chuyển hệ số kiến thức sang thiết bị mục tiêu.
[C-11-3] PHẢI, trên thiết bị mục tiêu thiếu bất kỳ yếu tố nhận dạng xác thực chính nào, yêu cầu người dùng xác nhận yếu tố nhận dạng xác thực đã chuyển trên thiết bị mục tiêu trước khi đặt yếu tố nhận dạng xác thực đó làm yếu tố nhận dạng xác thực chính cho thiết bị mục tiêu và trước khi cung cấp bất kỳ dữ liệu nào được chuyển từ thiết bị nguồn.

Nếu quá trình triển khai thiết bị có màn hình khoá bảo mật và bao gồm một hoặc nhiều tác nhân đáng tin cậy gọi API Hệ thống TrustAgentService.grantTrust() bằng cờ FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, thì các tác nhân đó:

[C-12-1] CHỈ ĐƯỢC gọi grantTrust() bằng cờ khi kết nối với một thiết bị thực tế lân cận có màn hình khoá riêng và khi người dùng đã xác thực danh tính của họ trên màn hình khoá đó. Các thiết bị ở gần có thể sử dụng cơ chế phát hiện trên cổ tay hoặc trên cơ thể sau khi người dùng mở khoá một lần để đáp ứng yêu cầu xác thực người dùng.
[C-12-2] PHẢI đặt hoạt động triển khai thiết bị vào trạng thái TrustState.TRUSTABLE khi màn hình tắt (chẳng hạn như thông qua thao tác nhấn nút hoặc hết thời gian chờ hiển thị) và TrustAgent chưa thu hồi trạng thái tin cậy. AOSP đáp ứng yêu cầu này.
[C-12-3] CHỈ được di chuyển thiết bị từ trạng thái TrustState.TRUSTABLE sang trạng thái TrustState.TRUSTED nếu TrustAgent vẫn cấp quyền tin cậy dựa trên các yêu cầu trong C-12-1.
[C-12-4] PHẢI gọi TrustManagerService.revokeTrust()
- Sau tối đa 24 giờ kể từ khi cấp quyền tin cậy, hoặc
- Sau khoảng thời gian rảnh 8 giờ hoặc
- Nếu các phương thức triển khai không sử dụng phạm vi chính xác và bảo mật bằng mật mã như được xác định trong [C-12-5], khi mất kết nối cơ bản với thiết bị thực tế lân cận.
[C-12-5] Các phương thức triển khai dựa vào phạm vi an toàn và chính xác để đáp ứng các yêu cầu của [C-12-4] PHẢI sử dụng một trong các giải pháp sau:
- Các phương thức triển khai sử dụng UWB:
  - PHẢI đáp ứng các yêu cầu về việc tuân thủ, chứng nhận, độ chính xác và yêu cầu về việc hiệu chuẩn đối với UWB được mô tả trong phần 7.4.9.
  - PHẢI sử dụng một trong các chế độ bảo mật P-STS được liệt kê trong phần 7.4.9.
- Các phương thức triển khai sử dụng tính năng Mạng nhận biết thiết bị lân cận Wi-Fi (NAN):
  - PHẢI đáp ứng các yêu cầu về độ chính xác trong 2.2.1 [7.4.2.5/H-SR-1], sử dụng băng thông 160 MHz (hoặc cao hơn) và làm theo các bước thiết lập đo lường được chỉ định trong Đo lường hiện diện.
  - PHẢI sử dụng LTF bảo mật như được xác định trong IEEE 802.11az.

Nếu việc triển khai thiết bị cho phép ứng dụng tạo màn hình ảo phụ và hỗ trợ các sự kiện đầu vào liên quan, chẳng hạn như thông qua VirtualDeviceManager và màn hình không được đánh dấu bằng VIRTUAL_DISPLAY_FLAG_SECURE, thì các màn hình đó:

[C-13-8] PHẢI chặn các hoạt động có thuộc tính android:canDisplayOnRemoteDevices hoặc siêu dữ liệu android.activity.can_display_on_remote_devices được đặt thành false để không khởi động trên thiết bị ảo.
[C-13-9] PHẢI chặn các hoạt động không bật tính năng truyền trực tuyến một cách rõ ràng và cho biết rằng các hoạt động đó hiển thị nội dung nhạy cảm, bao gồm cả thông qua SurfaceView#setSecure, FLAG_SECURE hoặc SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, không được bắt đầu trên thiết bị ảo.
~~[C-13-10] PHẢI tắt tính năng cài đặt ứng dụng được bắt đầu từ thiết bị ảo.~~

Nếu việc triển khai thiết bị hỗ trợ các trạng thái nguồn màn hình riêng biệt thông qua DeviceStateManager VÀ hỗ trợ các trạng thái khoá màn hình riêng biệt thông qua KeyguardDisplayManager, thì các trạng thái đó:

[C-SR-2] Bạn NÊN sử dụng thông tin xác thực đáp ứng các yêu cầu được xác định trong mục 9.11.1 hoặc thông tin sinh trắc học đáp ứng ít nhất các thông số kỹ thuật Lớp 1 được xác định trong mục 7.3.10 để cho phép mở khoá độc lập từ màn hình thiết bị mặc định.
[C-SR-3] Bạn NÊN RẤT GẤP hạn chế việc mở khoá màn hình riêng thông qua thời gian chờ màn hình đã xác định.
[C-SR-4] NÊN cho phép người dùng khoá tất cả màn hình trên toàn hệ thống thông qua tính năng khoá từ thiết bị cầm tay chính.

9.11.2. StrongBox

Hệ thống Kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ khoá mã hoá trong một bộ xử lý bảo mật chuyên dụng cũng như môi trường thực thi riêng biệt như mô tả ở trên. Bộ xử lý bảo mật chuyên dụng như vậy được gọi là "StrongBox". Các yêu cầu C-1-3 đến C-1-11 dưới đây xác định các yêu cầu mà thiết bị phải đáp ứng để đủ điều kiện là StrongBox.

Cách triển khai thiết bị có bộ xử lý bảo mật chuyên dụng:

[C-SR-1] RẤT NÊN hỗ trợ StrongBox. StrongBox có thể trở thành yêu cầu trong một bản phát hành trong tương lai.

Nếu hoạt động triển khai thiết bị hỗ trợ StrongBox, thì các thiết bị đó:

[C-1-1] PHẢI khai báo FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] PHẢI cung cấp phần cứng bảo mật chuyên dụng dùng để sao lưu kho khoá và xác thực người dùng một cách an toàn. Bạn cũng có thể sử dụng phần cứng bảo mật chuyên dụng cho các mục đích khác.
[C-1-3] PHẢI có một CPU riêng biệt không chia sẻ bộ nhớ đệm, DRAM, bộ xử lý đồng thời hoặc các tài nguyên cốt lõi khác với bộ xử lý ứng dụng (AP).
[C-1-4] PHẢI đảm bảo rằng mọi thiết bị ngoại vi được chia sẻ với AP không thể thay đổi quá trình xử lý StrongBox theo bất kỳ cách nào hoặc lấy bất kỳ thông tin nào từ StrongBox. AP CÓ THỂ tắt hoặc chặn quyền truy cập vào StrongBox.
[C-1-5] PHẢI có đồng hồ nội bộ với độ chính xác hợp lý (+-10%) không bị AP can thiệp.
[C-1-6] PHẢI có trình tạo số ngẫu nhiên thực sự tạo ra đầu ra được phân phối đồng đều và không thể đoán trước.
[C-1-7] PHẢI có khả năng chống can thiệp, bao gồm cả khả năng chống xâm nhập vật lý và sự cố.
[C-1-8] PHẢI có khả năng chống kênh bên, bao gồm cả khả năng chống rò rỉ thông tin qua kênh bên nguồn điện, thời gian, bức xạ điện từ và bức xạ nhiệt.
[C-1-9] PHẢI có bộ nhớ an toàn để đảm bảo tính bảo mật, tính toàn vẹn, tính xác thực, tính nhất quán và tính mới của nội dung. Không được phép đọc hoặc thay đổi bộ nhớ, ngoại trừ trường hợp được các API StrongBox cho phép.
Để xác thực việc tuân thủ [C-1-3] thông qua [C-1-9], các hoạt động triển khai thiết bị:
- [C-1-10] PHẢI bao gồm phần cứng được chứng nhận theo Hồ sơ bảo vệ IC bảo mật BSI-CC-PP-0084-2014 hoặc được đánh giá bởi một phòng thí nghiệm kiểm thử được công nhận trên toàn quốc, kết hợp với việc đánh giá lỗ hổng có khả năng tấn công cao theo Common Criteria Application of Attack Potential to Smartcards (Cách áp dụng các tiêu chí chung về khả năng tấn công vào thẻ thông minh).
- [C-1-11] PHẢI bao gồm phần mềm được đánh giá bởi một phòng thí nghiệm kiểm thử được công nhận trên toàn quốc, kết hợp với việc đánh giá lỗ hổng tiềm ẩn có khả năng tấn công cao theo Common Criteria Application of Attack Potential to Smartcards (Cách áp dụng các tiêu chí chung về khả năng tấn công cho thẻ thông minh).
- [C-SR-2] NÊN đưa vào phần cứng được đánh giá bằng Mục tiêu bảo mật, Mức độ đảm bảo đánh giá (EAL) 5, được tăng cường bằng AVA_VAN.5. Chứng chỉ EAL 5 có thể sẽ trở thành yêu cầu trong một bản phát hành trong tương lai.
- [C-SR-3] NÊN cung cấp khả năng chống tấn công nội bộ (IAR). Điều này có nghĩa là người nội bộ có quyền truy cập vào khoá ký firmware không thể tạo firmware khiến StrongBox rò rỉ thông tin bí mật, bỏ qua các yêu cầu bảo mật chức năng hoặc cho phép truy cập vào dữ liệu nhạy cảm của người dùng. Bạn nên triển khai IAR theo cách chỉ cho phép cập nhật chương trình cơ sở khi mật khẩu người dùng chính được cung cấp thông qua HAL IAuthSecret.

9.11.3. Thông tin xác thực danh tính

Hệ thống thông tin xác thực danh tính được xác định và đạt được bằng cách triển khai tất cả API trong gói android.security.identity.*. Các API này cho phép nhà phát triển ứng dụng lưu trữ và truy xuất giấy tờ nhận dạng người dùng. Triển khai trên thiết bị:

[C-SR-1] NÊN triển khai Hệ thống thông tin xác thực danh tính.

Nếu triển khai Hệ thống thông tin xác thực danh tính, thì các thiết bị sẽ:

[C-1-1] PHẢI trả về giá trị khác rỗng cho phương thức IdentityCredentialStore#getInstance().
[C-1-2] PHẢI triển khai Hệ thống thông tin xác thực danh tính (ví dụ: API android.security.identity.*) bằng mã giao tiếp với một ứng dụng đáng tin cậy trong một khu vực được tách biệt an toàn với mã chạy trên nhân và trên. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA.
[C-1-3] Các thao tác mã hoá cần thiết để triển khai Hệ thống thông tin xác thực danh tính (ví dụ: API android.security.identity.*) PHẢI được thực hiện hoàn toàn trong ứng dụng đáng tin cậy và tài liệu khoá riêng tư PHẢI không bao giờ rời khỏi môi trường thực thi biệt lập, trừ phi các API cấp cao hơn yêu cầu cụ thể (ví dụ: phương thức createEphemeralKeyPair()).
[C-1-4] Ứng dụng đáng tin cậy PHẢI được triển khai theo cách mà các thuộc tính bảo mật của ứng dụng đó không bị ảnh hưởng (ví dụ: dữ liệu thông tin xác thực sẽ không được phát hành trừ khi các điều kiện kiểm soát quyền truy cập được đáp ứng, không thể tạo MAC cho dữ liệu tuỳ ý) ngay cả khi Android đang hoạt động không đúng cách hoặc bị xâm phạm.

Dự án nguồn mở Android ngược dòng cung cấp một cách triển khai tham chiếu của một ứng dụng đáng tin cậy (libeic) có thể dùng để triển khai hệ thống Thông tin xác thực danh tính.

9.12. Xóa dữ liệu

Tất cả các cách triển khai trên thiết bị:

[C-0-1] PHẢI cung cấp cho người dùng một cơ chế để thực hiện thao tác "Đặt lại dữ liệu về trạng thái ban đầu".
[C-0-2] PHẢI xoá tất cả dữ liệu trên hệ thống tệp userdata khi thực hiện "Đặt lại dữ liệu về trạng thái ban đầu".
[C-0-3] PHẢI xoá dữ liệu theo cách đáp ứng các tiêu chuẩn ngành liên quan, chẳng hạn như NIST SP800-88 khi thực hiện "Đặt lại dữ liệu ban đầu".
[C-0-4] PHẢI kích hoạt quy trình "Đặt lại dữ liệu gốc" ở trên khi ứng dụng Trình kiểm soát chính sách thiết bị của người dùng chính gọi API DevicePolicyManager.wipeData().
CÓ THỂ cung cấp tuỳ chọn xoá dữ liệu nhanh chỉ thực hiện việc xoá dữ liệu logic.

9.13. Chế độ khởi động an toàn

Android cung cấp Chế độ khởi động an toàn, cho phép người dùng khởi động vào một chế độ chỉ cho phép chạy các ứng dụng hệ thống được cài đặt sẵn và tắt tất cả ứng dụng bên thứ ba. Chế độ này, còn gọi là "Chế độ khởi động an toàn", cho phép người dùng gỡ cài đặt các ứng dụng bên thứ ba có khả năng gây hại.

Các phương thức triển khai thiết bị là:

[C-SR-1] NÊN triển khai Chế độ khởi động an toàn.

Nếu triển khai Chế độ khởi động an toàn, thì các thiết bị sẽ:

[C-1-1] PHẢI cung cấp cho người dùng tuỳ chọn để vào Chế độ khởi động an toàn theo cách không bị gián đoạn bởi các ứng dụng bên thứ ba được cài đặt trên thiết bị, ngoại trừ trường hợp ứng dụng bên thứ ba là Trình điều khiển chính sách thiết bị và đã đặt cờ UserManager.DISALLOW_SAFE_BOOT thành đúng.
[C-1-2] PHẢI cung cấp cho người dùng khả năng gỡ cài đặt mọi ứng dụng bên thứ ba trong Chế độ an toàn.
NÊN cung cấp cho người dùng tuỳ chọn để chuyển sang Chế độ khởi động an toàn từ trình đơn khởi động bằng quy trình làm việc khác với quy trình khởi động thông thường.

9.14. Tách biệt hệ thống trên xe ô tô

Dự kiến, các thiết bị Android Automotive sẽ trao đổi dữ liệu với các hệ thống con quan trọng của xe bằng cách sử dụng HAL của xe để gửi và nhận thông báo qua mạng xe, chẳng hạn như bus CAN.

Bạn có thể bảo mật hoạt động trao đổi dữ liệu bằng cách triển khai các tính năng bảo mật bên dưới các lớp khung Android để ngăn chặn hành vi tương tác độc hại hoặc vô tình với các hệ thống con này.

9.15. Gói thuê bao

"Gói thuê bao" đề cập đến thông tin chi tiết về gói mối quan hệ thanh toán do nhà mạng di động cung cấp thông qua SubscriptionManager.setSubscriptionPlans().

Tất cả các cách triển khai trên thiết bị:

[C-0-1] PHẢI chỉ trả về các gói thuê bao cho ứng dụng của nhà mạng di động ban đầu đã cung cấp các gói đó.
[C-0-2] KHÔNG ĐƯỢC sao lưu hoặc tải gói thuê bao lên từ xa.
[C-0-3] CHỈ được cho phép ghi đè, chẳng hạn như SubscriptionManager.setSubscriptionOverrideCongested(), từ ứng dụng của nhà mạng di động hiện đang cung cấp các gói thuê bao hợp lệ.

9.16. Di chuyển dữ liệu ứng dụng

Nếu việc triển khai thiết bị bao gồm khả năng di chuyển dữ liệu từ một thiết bị sang thiết bị khác và không giới hạn dữ liệu ứng dụng mà ứng dụng sao chép sang nội dung do nhà phát triển ứng dụng định cấu hình trong tệp kê khai thông qua thuộc tính android:fullBackupContent, thì các thiết bị đó:

[C-1-1] KHÔNG ĐƯỢC bắt đầu chuyển dữ liệu ứng dụng từ những thiết bị mà người dùng chưa thiết lập phương thức xác thực chính như mô tả trong phần 9.11.1 Màn hình khoá và xác thực an toàn.
[C-1-2] PHẢI xác nhận một cách an toàn quy trình xác thực chính trên thiết bị nguồn và xác nhận với người dùng về ý định sao chép dữ liệu trên thiết bị nguồn trước khi chuyển bất kỳ dữ liệu nào.
[C-1-3] PHẢI sử dụng tính năng chứng thực khoá bảo mật để đảm bảo rằng cả thiết bị nguồn và thiết bị mục tiêu trong quá trình di chuyển giữa các thiết bị đều là thiết bị Android hợp lệ và có trình tải khởi động bị khoá.
[C-1-4] CHỈ ĐƯỢC di chuyển dữ liệu ứng dụng sang cùng một ứng dụng trên thiết bị đích, có cùng tên gói VÀ chứng chỉ ký.
[C-1-5] PHẢI cho biết rằng thiết bị nguồn đã di chuyển dữ liệu bằng tính năng di chuyển dữ liệu giữa các thiết bị trong trình đơn cài đặt. Người dùng KHÔNG NÊN xoá được chỉ báo này.

9.17. Khung ảo hoá Android

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android (android.system.virtualmachine.*), thì máy chủ Android sẽ:

[C-1-1] PHẢI hỗ trợ tất cả các API do gói android.system.virtualmachine xác định.
[C-1-2] KHÔNG ĐƯỢC sửa đổi Android SELinux và mô hình quyền để quản lý Máy ảo được bảo vệ (pVM).

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

[C-1-4] CHỈ ĐƯỢC cho phép mã đã ký của nền tảng và các ứng dụng đặc quyền~~KHÔNG ĐƯỢC cho phép mã không đáng tin cậy (ví dụ: ứng dụng bên thứ ba)~~ tạo và chạy ~~Máy ảo được bảo vệ~~pVM. Lưu ý: Điều này có thể thay đổi trong các bản phát hành Android trong tương lai.

[C-1-5] KHÔNG ĐƯỢC cho phép ~~Máy ảo được bảo vệ~~ pVM thực thi mã không thuộc hình ảnh gốc hoặc bản cập nhật của hình ảnh gốc. Bạn KHÔNG được phép chạy bất kỳ nội dung nào không thuộc phạm vi của tính năng Xác minh quy trình khởi động của Android (ví dụ: các tệp tải xuống từ Internet hoặc tải không qua cửa hàng) trong Máy ảo được bảo vệ .

Bắt đầu yêu cầu mới

[C-1-5] PHẢI chỉ cho phép pVM không gỡ lỗi thực thi mã từ hình ảnh ban đầu hoặc các bản cập nhật nền tảng của chúng, bao gồm cả mọi bản cập nhật cho ứng dụng có đặc quyền.

Kết thúc các yêu cầu mới

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android (android.system.virtualmachine.*), thì mọi thực thể ~~Máy ảo được bảo vệ~~ pVM :

[C-2-1] PHẢI có thể chạy tất cả hệ điều hành có trong APEX ảo hoá trong ~~Máy ảo được bảo vệ~~ pVM .
[C-2-2] KHÔNG ĐƯỢC cho phép ~~Máy ảo được bảo vệ~~ pVM chạy một hệ điều hành không do người triển khai thiết bị hoặc nhà cung cấp hệ điều hành ký.
[C-2-3] KHÔNG ĐƯỢC cho phép ~~Máy ảo được bảo vệ~~ pVM thực thi dữ liệu dưới dạng mã (ví dụ: SELinux neverallow execmem).

[C-2-4] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc neverallow có trong hệ thống/sepolicy/microdroid được cung cấp trong Dự án nguồn mở Android (AOSP) ngược dòng.

[C-2-5] PHẢI triển khai các cơ chế phòng thủ chuyên sâu ~~Máy ảo được bảo vệ~~ pVM (ví dụ: SELinux cho pVM) ngay cả đối với các hệ điều hành không phải Microdroid.
[C-2-6] PHẢI đảm bảo rằng pVM không thành công ~~firmware từ chối~~ khởi động nếu ~~không thể xác minh hình ảnh ban đầu~~ mà máy ảo sẽ chạy không thể được xác minh. Bạn PHẢI thực hiện quy trình xác minh bên trong máy ảo.
[C-2-7] PHẢI đảm bảo rằng pVM không khởi động được ~~firmware từ chối~~ khởi động nếu tính toàn vẹn của instance.img bị xâm phạm.

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android (android.system.virtualmachine.*), thì trình điều khiển ảo hoá sẽ:

[C-3-1] PHẢI đảm bảo rằng các trang bộ nhớ do một máy ảo (pVM hoặc máy ảo lưu trữ) sở hữu độc quyền chỉ có thể truy cập được bằng chính máy ảo đó hoặc trình điều khiển ảo hoá, chứ không phải bằng các máy ảo khác – được bảo vệ hoặc không được bảo vệ. KHÔNG ĐƯỢC cho phép bất kỳ pVM nào truy cập vào một trang thuộc về một thực thể khác (tức là pVM hoặc trình điều khiển ảo hoá khác), trừ phi chủ sở hữu trang chia sẻ rõ ràng. Bao gồm cả máy ảo lưu trữ. Điều này áp dụng cho cả CPU và DMA truy cập.
[C-3-2] PHẢI xoá sạch một trang sau khi pVM sử dụng trang đó và trước khi trả về trang đó cho máy chủ lưu trữ (ví dụ: pVM bị huỷ).
[C-~~3-3~~SR-1] BẠN CẦN PHẢI đảm bảo ~~PHẢI đảm bảo~~ rằng chương trình cơ sở pVM được tải và thực thi trước mọi mã trong pVM.
[C-3-4] PHẢI đảm bảo rằng mỗi máy ảo lấy một khoá bí mật cho mỗi máy ảo~~{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instance~~ chỉ có thể được lấy từ thực thể máy ảo cụ thể đó và thay đổi khi đặt lại về trạng thái ban đầu và OTA.

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android, thì trên tất cả các khu vực:

[C-4-1] KHÔNG ĐƯỢC cung cấp chức năng cho pVM cho phép bỏ qua Mô hình bảo mật Android.

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android, thì:

[C-5-1] PHẢI có khả năng hỗ trợ tính năng Biên dịch riêng biệt nhưng có thể tắt tính năng Biên dịch riêng biệt trên lô hàng thiết bị ~~của bản cập nhật thời gian chạy ART~~.

Nếu thiết bị triển khai tính năng hỗ trợ cho các API Khung ảo hoá Android, thì đối với tính năng Quản lý khoá:

[C-6-1] PHẢI can thiệp vào chuỗi DICE tại một điểm mà người dùng không thể sửa đổi, ngay cả trên các thiết bị đã mở khoá. (Để đảm bảo không thể giả mạo).

[C-SR-2~~6-2~~] Bạn NÊN sử dụng DICE làm cơ chế dẫn xuất bí mật trên mỗi máy ảo. ~~PHẢI thực hiện DICE đúng cách, tức là cung cấp giá trị chính xác.~~

10. Kiểm thử khả năng tương thích của phần mềm

Việc triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử được mô tả trong phần này. Tuy nhiên, xin lưu ý rằng không có gói kiểm thử phần mềm nào hoàn toàn toàn diện. Vì lý do này, những người triển khai thiết bị NÊN thực hiện ít thay đổi nhất có thể đối với tài liệu tham khảo và cách triển khai Android ưu tiên có trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ phát sinh lỗi gây ra sự không tương thích, yêu cầu phải làm lại và có thể phải cập nhật thiết bị.

10.1. Bộ kiểm thử khả năng tương thích

Triển khai trên thiết bị:

[C-0-1] PHẢI vượt qua Bộ kiểm thử tính tương thích với Android (CTS) có trong Dự án nguồn mở Android, bằng cách sử dụng phần mềm vận chuyển chính thức trên thiết bị.
[C-0-2] PHẢI đảm bảo khả năng tương thích trong trường hợp không rõ ràng trong CTS và đối với mọi trường hợp triển khai lại các phần của mã nguồn tham chiếu.

CTS được thiết kế để chạy trên một thiết bị thực. Giống như mọi phần mềm khác, CTS cũng có thể chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa về khả năng tương thích này và có thể phát hành nhiều bản sửa đổi của CTS cho Android 14.

Triển khai trên thiết bị:

[C-0-3] PHẢI vượt qua phiên bản CTS mới nhất hiện có tại thời điểm hoàn tất phần mềm thiết bị.
NÊN sử dụng phương thức triển khai tham chiếu trong cây Nguồn mở Android nhiều nhất có thể.

10.2. Trình xác minh CTS

Trình xác minh CTS đi kèm với Bộ kiểm thử khả năng tương thích và được người vận hành chạy để kiểm thử chức năng mà hệ thống tự động không thể kiểm thử, chẳng hạn như hoạt động chính xác của máy ảnh và cảm biến.

Triển khai trên thiết bị:

[C-0-1] PHẢI thực thi chính xác tất cả các trường hợp hiện hành trong trình xác minh CTS.

Công cụ xác minh CTS có các bài kiểm thử cho nhiều loại phần cứng, bao gồm cả một số phần cứng không bắt buộc.

Triển khai trên thiết bị:

[C-0-2] PHẢI vượt qua tất cả các bài kiểm thử cho phần cứng mà thiết bị có; ví dụ: nếu một thiết bị có gia tốc kế, thì thiết bị đó PHẢI thực thi chính xác trường hợp kiểm thử Gia tốc kế trong Trình xác minh CTS.

Bạn CÓ THỂ bỏ qua hoặc loại bỏ các trường hợp kiểm thử cho các tính năng được ghi nhận là không bắt buộc theo Tài liệu xác định khả năng tương thích này.

[C-0-2] Mọi thiết bị và mọi bản dựng PHẢI chạy đúng cách Trình xác minh CTS, như đã lưu ý ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên người triển khai thiết bị không cần phải chạy rõ ràng Trình xác minh CTS trên các bản dựng chỉ khác nhau ở những điểm nhỏ. Cụ thể, việc triển khai thiết bị khác với việc triển khai đã vượt qua Trình xác minh CTS chỉ bằng một nhóm ngôn ngữ, thương hiệu, v.v. ĐƯỢC phép bỏ qua quy trình kiểm thử Trình xác minh CTS.

11. Phần mềm có thể cập nhật

[C-0-1] Việc triển khai thiết bị PHẢI bao gồm một cơ chế để thay thế toàn bộ phần mềm hệ thống. Cơ chế này không cần thực hiện các bản nâng cấp "trực tiếp", tức là có thể cần phải khởi động lại thiết bị. Bạn có thể sử dụng bất kỳ phương thức nào, miễn là phương thức đó có thể thay thế toàn bộ phần mềm được cài đặt sẵn trên thiết bị. Ví dụ: bất kỳ phương pháp nào sau đây cũng sẽ đáp ứng yêu cầu này:
- Tải xuống "qua mạng không dây (OTA)" với bản cập nhật ngoại tuyến thông qua việc khởi động lại.
- Cập nhật "Có dây" qua USB từ máy tính lưu trữ.
- Cập nhật "ngoại tuyến" thông qua việc khởi động lại và cập nhật từ một tệp trên bộ nhớ có thể tháo rời.
[C-0-2] Cơ chế cập nhật được sử dụng PHẢI hỗ trợ các bản cập nhật mà không xoá dữ liệu người dùng. Tức là cơ chế cập nhật PHẢI giữ lại dữ liệu riêng tư của ứng dụng và dữ liệu dùng chung của ứng dụng. Xin lưu ý rằng phần mềm Android ngược dòng có một cơ chế cập nhật đáp ứng yêu cầu này.
[C-0-3] Toàn bộ bản cập nhật PHẢI được ký và cơ chế cập nhật trên thiết bị PHẢI xác minh bản cập nhật và chữ ký dựa trên khoá công khai được lưu trữ trên thiết bị.
[C-SR-1] Bạn NÊN sử dụng cơ chế ký để băm bản cập nhật bằng SHA-256 và xác thực hàm băm đó với khoá công khai bằng ECDSA NIST P-256.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ kết nối dữ liệu không đo lượng dữ liệu, chẳng hạn như hồ sơ 802.11 hoặc Bluetooth PAN (Mạng khu vực cá nhân), thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ tính năng tải xuống OTA bằng bản cập nhật ngoại tuyến thông qua việc khởi động lại.

Việc triển khai thiết bị PHẢI xác minh rằng hình ảnh hệ thống là tệp nhị phân giống hệt với kết quả dự kiến sau khi cập nhật qua mạng. Việc triển khai OTA dựa trên khối trong Dự án nguồn mở Android ngược dòng, được thêm vào kể từ Android 5.1, đáp ứng yêu cầu này.

Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ bản cập nhật hệ thống A/B. AOSP triển khai tính năng này bằng cách sử dụng HAL điều khiển khởi động.

Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi phát hành nhưng trong thời gian sử dụng sản phẩm hợp lý được xác định bằng cách tham khảo ý kiến của Nhóm tương thích Android để ảnh hưởng đến khả năng tương thích của các ứng dụng bên thứ ba, thì:

[C-2-1] Bên triển khai thiết bị PHẢI khắc phục lỗi thông qua bản cập nhật phần mềm có sẵn và có thể áp dụng theo cơ chế vừa mô tả.

Android có các tính năng cho phép ứng dụng Chủ sở hữu thiết bị (nếu có) kiểm soát việc cài đặt bản cập nhật hệ thống. Nếu hệ thống con cập nhật hệ thống cho thiết bị báo cáo android.software.device_admin, thì các thiết bị đó:

[C-3-1] PHẢI triển khai hành vi được mô tả trong lớp SystemUpdatePolicy.

12. Nhật ký thay đổi tài liệu

Dưới đây là nội dung tóm tắt về các thay đổi đối với Định nghĩa về khả năng tương thích trong bản phát hành này:

Ghi lại nhật ký thay đổi

13. Liên hệ với chúng tôi

Bạn có thể tham gia diễn đàn về khả năng tương thích với Android để yêu cầu làm rõ hoặc nêu bất kỳ vấn đề nào mà bạn cho rằng tài liệu không đề cập đến.