Kể từ năm 2026, để phù hợp với mô hình phát triển ổn định của nhánh chính và đảm bảo tính ổn định của nền tảng cho hệ sinh thái, chúng tôi sẽ xuất bản mã nguồn lên AOSP vào quý 2 và quý 4. Để tạo và đóng góp cho AOSP, bạn nên sử dụng android-latest-release thay vì aosp-main. Nhánh tệp kê khai android-latest-release sẽ luôn tham chiếu đến bản phát hành gần đây nhất được chuyển đến AOSP. Để biết thêm thông tin, hãy xem bài viết Các thay đổi đối với AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Định nghĩa về khả năng tương thích của Android 17 [XEM TRƯỚC]

1. Giới thiệu

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

Việc sử dụng "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" và "OPTIONAL" tuân theo tiêu chuẩn IETF được xác định trong RFC2119.

Theo định nghĩa trong tài liệu này, "nhà triển khai thiết bị" là một cá nhân hoặc tổ chức phát triển giải pháp phần cứng/phần mềm chạy Android 17. "Giải pháp triển khai thiết bị" hoặc "giải pháp triển khai" là giải pháp phần cứng/phần mềm được phát triển.

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

Trong trường hợp định nghĩa này hoặc các kiểm thử phần mềm được mô tả trong mục 10 không rõ ràng, mơ hồ hoặc không đầy đủ, thì nhà 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 hoạt động 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à cách triển khai ưu tiên của Android. Các đơn vị triển khai thiết bị RẤT NÊN dựa vào các hoạt động triển khai của mình ở mức cao nhất có thể trên mã nguồn "thượng nguồn" có trong Dự án nguồn mở Android. Mặc dù về lý thuyết, bạn có thể thay thế một số thành phần bằng các cách triển khai thay thế, nhưng BẠN KHÔNG NÊN làm theo cách này vì việc vượt qua các 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 việc triển khai Android tiêu chuẩn, bao gồm cả Bộ kiểm tra tính tương thích và các yêu cầu khác. Cuối cùng, xin lưu ý rằng một số thay thế và sửa đổi thành phần nhất định bị tài liệu này nghiêm cấm một cách rõ ràng.

Nhiều tài nguyên được liên kết trong tài liệu này có nguồn gốc trực tiếp hoặc gián tiếp từ SDK Android và sẽ có chức năng giống hệt thông tin trong tài liệu của SDK đó. Trong mọi trường hợp mà Định nghĩa về khả năng tương thích này hoặc Bộ kiểm tra tính tương thích không thống nhất với tài liệu SDK, thì tài liệu SDK sẽ được coi là có thẩm quyền. Mọi thông tin kỹ thuật được cung cấp trong các tài nguyên được liên kết trong 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 trong Mục 2 đều 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 đều được liệt kê trong các phần sau Mục 2. Những 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 BẮT BUỘC.

Mã nhận dạng chỉ được chỉ định cho các yêu cầu BẮT BUỘC.
Các yêu cầu ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ đượ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ã nhận dạng được xác định như sau:

Mã nhận dạng loại thiết bị (xem thêm trong phần 2. Loại thiết bị)
- C: Core (Các yêu cầu áp dụng cho mọi hoạt động triển khai thiết bị Android)
- H: Thiết bị Android cầm tay
- 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 là vô điều kiện, mã nhận dạng này được đặt là 0.
- Khi yêu cầu là có điều kiện, 1 sẽ được chỉ định cho điều kiện thứ nhất và số này sẽ tăng thêm 1 trong cùng một phần 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 phần 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 Mục 2 có hai phần. Mã đầu tiên tương ứng với một mã nhận dạng phần như mô tả ở trên. Phần thứ hai xác định hệ số hình dạng và yêu cầu cụ thể về hệ số hình dạng.

mã nhận dạng phần, theo sau là Mã yêu cầu như mô tả ở trên.

Mã nhận dạng 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ể dùng cho nhiều loại thiết bị và kiểu dáng. Để hỗ trợ bảo mật trên các 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 một cách triển khai hạt nhân thay thế) dự kiến sẽ thực thi trong một môi trường bảo mật như mô tả trong phần 9 và những nơi 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 hoạt động 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 mọi 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 trong 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 đây.

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

Thiết bị cầm tay Android là một cách triển khai thiết bị Android thường được dùng bằng cách cầm trên 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 di động, 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 đến 8 inch.
Có giao diện nhập liệu 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ị Android cầm tay.

2.2.1. Phần cứng

Cách 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 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-SR-1] RẤT NÊN cung cấp cho người dùng một thành phần để thay đổi kích thước hiển thị (mật độ màn hình).
[7.1.1.1/H-0-2] PHẢI hỗ trợ thành phần GPU của các vùng đệm đồ hoạ có kích thước ít nhất bằng độ phân giải cao nhất của mọi màn hình tích hợp.
[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 vùng màn hình thực tế không bị cản trở, có kích thước ít nhất là 2,2 inch ở cạnh ngắn và 3,4 inch ở cạnh dài.
[7.1.1.3/H-0-1]^* PHẢI đặt DENSITY_DEVICE_STABLE thành 92% hoặc lớn hơn mật độ thực tế của màn hình tương ứng.

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

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

Nếu các phương thức triển khai thiết bị Cầm tay khai báo hỗ trợ mọi ABI 64 bit (có hoặc không có ABI 32 bit) và trả về false cho ActivityManager.isLowRamDevice(), thì:

[7.1.4.2/H-2-1] PHẢI hỗ trợ Vulkan 1.1 trở lên.

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

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

Cách 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ợ khả năng lập hồ sơ GPU hay không thông qua một thuộc tính hệ thống graphics.gpu.profiler.support.

Nếu các chế độ triển khai Thiết bị cầm tay khai báo sự hỗ trợ thông qua một thuộc tính hệ thống graphics.gpu.profiler.support, thì chú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à 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 giao thức gói gpu counter trace.
[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 render stage trace packet proto.
[7.1.4.6/H-1-4] PHẢI báo cáo một điểm theo dõi Tần số GPU theo quy định của định dạng: power/gpu_frequency.

Cách triển khai thiết bị cầm tay:

[7.1.5/H-0-1] PHẢI hỗ trợ chế độ tương thích ứng dụng cũ như được triển khai bằng mã nguồn mở Android ngược dòng. Tức là các hoạt động 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, đồng thời 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 bình thường và nhấn lâu của chức năng Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước. Hệ thống KHÔNG ĐƯỢC phép 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 bên ngoài 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 Trang chủ trên tất cả các màn hình tương thích với Android có 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ợ thao tác nhập bằng màn hình cảm ứng.
[7.2.4/H-SR-1] RẤT NÊN dùng để chạy ứng dụng trợ lý do người dùng chọn; nói cách khác, ứng dụng triển khai VoiceInteractionService hoặc một Hoạt động xử lý ACTION_ASSIST khi người dùng 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] RẤT NÊN trang bị gia tốc kế 3 trục.

Nếu các thiết bị Cầm tay có gia tốc kế 3 trục, thì:

[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 nhất là 100 Hz.

Nếu các hoạt động triển khai thiết bị Cầm tay có một bộ thu GPS/GNSS và báo cáo khả 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 hoạt động triển khai này:

[7.3.3/H-2-1] PHẢI báo cáo các phép đo GNSS ngay khi tìm thấy, ngay cả khi chưa báo cáo vị trí được tính toán từ GPS/GNSS.
[7.3.3/H-2-2] PHẢI báo cáo tốc độ giả và khoảng cách giả của GNSS, trong điều kiện không gian thoáng đã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 bình phươ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 95% thời gian.

Nếu các thiết bị Cầm tay có tích hợp con quay hồi chuyển 3 trục, thì:

[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 nhất 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 1.000 độ mỗi giây.

Các hoạt động 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 mọi giá trị khác ngoài PHONE_TYPE_NONE trong getPhoneType:

[7.3.8/H] PHẢI có cảm biến độ gần.

Cách triển khai thiết bị cầm tay:

[7.3.11/H-SR-1] RẤT NÊN hỗ trợ cảm biến tư thế với 6 bậc tự do.

Nếu các thiết bị cầm tay triển khai hỗ trợ kết nối dữ liệu di động, thì:

[7.4.1/H-1-1] PHẢI khai báo cờ tính năng android.hardware.telephony.data.

Các cách triển khai thiết bị cầm tay có hỗ trợ Bluetooth LE:

[7.4.3/H-SR-1] RẤT NÊN hỗ trợ Tiện ích chiều dài gói dữ liệu Bluetooth LE.

Lưu ý: Yêu cầu này [7.4.3/H-SR-1] sẽ trở thành BẮT BUỘC trong một bản phát hành Android sau này.

Nếu quá trình triển khai thiết bị có hỗ trợ 802.11 (Wi-Fi), thì:

[7.4.2.4/H-1-1] PHẢI hỗ trợ Wi-Fi Passpoint.

Nếu các thiết bị hỗ trợ giao thức Mạng nhận biết thiết bị lân cận (NAN) qua việc khai báo PackageManager.FEATURE_WIFI_AWARE và Vị trí Wi-Fi (Thời gian trọn vòng Wi-Fi – RTT) qua việc khai báo PackageManager.FEATURE_WIFI_RTT, thì:

[7.4.2.5/H-1-1] PHẢI báo cáo chính xác phạm vi trong vòng +/-1 mét ở băng thông 160 MHz tại phân vị thứ 68 (theo tính toán bằng Hàm phân phối tích luỹ), +/-2 mét ở băng thông 80 MHz tại phân vị thứ 68, +/-4 mét ở băng thông 40 MHz tại phân vị thứ 68 và +/-8 mét ở băng thông 20 MHz tại phân vị thứ 68 ở khoảng cách 10 cm, 1 m, 3 m và 5 m, như quan sát được thông qua API Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] CẦN BÁO CÁO PHẠM VI CHÍNH XÁC trong vòng +/-1 mét ở băng thông 160 MHz tại phân vị thứ 90 (theo tính toán bằng Hàm phân phối tích luỹ), +/-2 mét ở băng thông 80 MHz tại phân vị thứ 90, +/-4 mét ở băng thông 40 MHz tại phân vị thứ 90 và +/-8 mét ở băng thông 20 MHz tại phân vị thứ 90 ở khoảng cách 10 cm, như quan sát được thông qua API WifiRttManager#startRanging của Android.

Bạn NÊN LÀM THEO các bước thiết lập đo lường được chỉ định trong phần Hiệu chỉnh sự hiện diện.

Nếu các thiết bị cầm tay hỗ trợ giao thức Phát hiện thiết bị gần đây (PD) qua Wi-Fi bằng cách khai báo PackageManager.FEATURE_WIFI_PD và Vị trí Wi-Fi (Thời gian trọn vòng qua Wi-Fi – RTT) bằng cách khai báo PackageManager.FEATURE_WIFI_RTT, thì các thiết bị đó:

[7.4.2.10/H-1-1] PHẢI sử dụng băng thông tối thiểu là 160 MHz.
[7.4.2.10/H-1-2] PHẢI báo cáo chính xác phạm vi trong vòng +/-0,25 mét ở băng thông 160 MHz tại phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ), như quan sát được thông qua WifiRttManager#startRanging Android API.

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 Hiệu chỉnh sự hiện diện.

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

[7.4.3/H-1-3] PHẢI đo lường và bù trừ độ lệch Rx để đảm bảo RSSI BLE trung vị là -50 dBm +/-15 dB ở khoảng cách 1 m so với mộ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ù đắp độ lệch Tx để đảm bảo RSSI BLE trung vị là -50 dBm +/-15 dB khi quét từ một thiết bị tham chiếu được đặt ở khoảng cách 1 m và truyền ở ADVERTISE_TX_POWER_HIGH.

Nếu các thiết bị Cầm tay có ít nhất một camera sau, thì:

[7.5.1/H-1-1] PHẢI có độ phân giải tối thiểu là 2 megapixel.

Nếu các hoạt động triển khai thiết bị Cầm tay bao gồm một thiết bị camera logic liệt kê các chức năng bằng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, thì:

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

Cách 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 biến động để lưu trữ dữ liệu riêng tư 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ớ có sẵn cho hạt nhân và không gian người dùng.

Nếu các hoạt động 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 ít nhất là 416 MB nếu màn hình mặc định sử dụng độ phân giải bộ đệm khung lên đến qHD (ví dụ: FWVGA).
[7.6.1/H-2-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI tối thiểu là 592 MB nếu màn hình mặc định sử dụng độ phân giải bộ đệ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 tối thiểu là 896 MB nếu màn hình mặc định sử dụng độ phân giải bộ đệm khung hình lên đến FHD (ví dụ: WSXGA+).
[7.6.1/H-4-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI ít nhất là 1344 MB nếu màn hình mặc định sử dụng độ phân giải bộ đệm khung hình lên đến QHD (ví dụ: QWXGA).

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

Xin lưu ý rằng "bộ nhớ có sẵn cho nhân hệ điều hành 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 hệ điều hành trên các hoạt động triển khai thiết bị.

Nếu các hoạt động triển khai Thiết bị cầm tay có bộ nhớ 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 hoạt động triển khai này:

[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 biến động cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").

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

[7.6.1/H-10-1] PHẢI có ít nhất 4 GB bộ nhớ không biến động dành 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 các thiết bị Cầm tay có bộ nhớ từ 2 GB trở lên và dưới 4 GB dành cho nhân và không gian người dùng, thì các thiết bị đó:

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

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

[7.6.1/H-1-1] CHỈ ĐƯỢC hỗ trợ một ABI duy nhất (chỉ 64 bit hoặc chỉ 32 bit).

Cách 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ó một cổng USB hỗ trợ chế độ thiết bị ngoại vi.

Nếu các thiết bị cầm tay triển khai cổng USB có bộ điều khiển hoạt động ở 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 các thiết bị cầm tay có cổng USB hỗ trợ chế độ máy chủ, thì:

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

Cách 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 các hoạt động triển khai Thiết bị cầm tay có thể đáp ứng mọi yêu cầu về hiệu suất để hỗ trợ chế độ thực tế ảo và có hỗ trợ chế độ này, thì:

[7.9.1/H-1-1] PHẢI khai báo cờ tính năng android.hardware.vr.high_performance.
[7.9.1/H-1-2] PHẢI có một ứng dụng triển khai android.service.vr.VrListenerService mà các ứng dụng thực tế ảo có thể bật thông qua android.app.Activity#setVrModeEnabled.

Nếu các chế độ triển khai Thiết bị cầm tay có 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 chế độ triển khai này:

[7.8.2.2/H-1-1] PHẢI cung cấp thông tin ánh xạ phần mềm sau đây về mã HID:

Chức năng	Ánh xạ	Bối cảnh	Hành vi
A	Trang sử dụng HID: 0x0C Mục đích sử dụng HID: 0x0CD Khoá nhân: `KEY_PLAYPAUSE` Khoá Android: `KEYCODE_MEDIA_PLAY_PAUSE`	Phát nội dung nghe nhìn	Đầu vào: Nhấn nhanh Đầu ra: Phát hoặc tạm dừng
		Phát nội dung nghe nhìn	Đầu vào: Nhấn và giữ Đầu ra: Khởi 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 nhanh Đầu ra: Chấp nhận cuộc gọi
		Cuộc gọi đến	Đầu vào: Nhấn và giữ Đầu ra: Từ chối cuộc gọi
		Cuộc gọi đang diễn ra	Thao tác đầu vào: Nhấn nhanh Thao tác đầ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 tiếng micrô
B	Trang sử dụng HID: 0x0C Mục đích sử dụng HID: 0x0E9 Khoá 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 nhanh hoặc nhấn và giữ Đầu ra: Tăng âm lượng hệ thống hoặc âm lượng tai nghe
C	Trang sử dụng HID: 0x0C Mục đích sử dụng HID: 0x0EA Khoá 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 nhanh hoặc nhấn và giữ Đầu ra: Giảm âm lượng hệ thống hoặc âm lượng tai nghe
D	Trang sử dụng HID: 0x0C Mục đích sử dụng HID: 0x0CF Khoá nhân: `KEY_VOICECOMMAND` Khoá Android: `KEYCODE_VOICE_ASSIST`	Tất cả. Có thể được kích hoạt trong mọi trường hợp.	Thao tác đầu vào: Nhấn nhanh hoặc nhấn và giữ Thao tác đầ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 giắc cắm, nhưng chỉ sau khi các giao diện và điểm cuối âm thanh USB được liệt kê đúng cách để xác định loại đầu nối đã kết nối.

Khi phát hiện thấy các loại đầu cắm âm thanh USB 0x0302, chúng sẽ:

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

Khi phát hiện thấy các loại đầu cắm âm thanh USB 0x0402, chúng sẽ:

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

Khi API AudioManager.getDevices() được gọi trong khi thiết bị ngoại vi USB đang kết nối, chúng 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ò isSink() nếu trường loại đầ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 đầ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 đầ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ò isSink() nếu trường loại đầ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 đầ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 đầ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 đầu cuối âm thanh USB là 0x400.
[7.8.2.2/H-SR-1] RẤT NÊN thực hiện khi kết nối thiết bị ngoại vi âm thanh USB-C, để thực hiện việc liệt kê các thông tin mô tả USB, xác định các loại đầu cuối và truyền Intent ACTION_HEADSET_PLUG trong vòng chưa đến 1000 mili giây.

Đối với các cách triển khai thiết bị Cầm tay khai báo android.hardware.audio.output và android.hardware.microphone, hãy xem các yêu cầu về RTL và TTL trong phần 5.6.

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

Nếu các hoạt động triển khai Thiết bị cầm tay có ít nhất một bộ truyền động cộng hưởng tuyến tính 7.10 cho mục đích chung, thì:

[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ị.
[7.10/H]SHOULD di chuyển bộ truyền động xúc giác theo trục X (trái-phải) theo hướng 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ó bộ truyền động xúc giác đa năng là bộ truyền động cộng hưởng tuyến tính (LRA) trên trục X, thì:

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

Nếu các hoạt động triển khai thiết bị cầm tay tuân theo quy trình liên kết hằng số xúc giác, thì:

[7.10/H]^* CẦ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().
[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 nguyên tắ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, đồng thời cung cấp các định dạng này 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] Cấu hình AAC MPEG-4 (AAC LC)
[5.1/H-0-4] Cấu hình HE AAC MPEG-4 (AAC+)
[5.1/H-0-5] AAC ELD (AAC có độ trễ thấp nâng cao)

[5.1/H-0-6] MPEG-D USAC có MPEG-D DRC (AAC hiệu suất cao mở rộng)

2.2.3. Phần mềm

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 này cho các ứng dụng bên thứ ba:

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

Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp các định dạng này 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
[5.3/H-0-6] AV1

2.2.3. Phần mềm

Cách 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 trì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 sẵn một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng một 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 tại đây. Lưu ý: Trang "Ý định chung của ứng dụng" sẽ có ý định bắt buộc mới "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[3.2.3.1/H-SR-1] 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 một chế độ triển khai hoàn chỉnh của 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 nói chung.

[3.8.1/H-0-1] PHẢI triển khai một trình chạy mặc định hỗ trợ tính năng ghim tiện ích trong ứng dụng.

[3.8.1/H-SR-1] RẤT NÊN triển khai một trình chạy mặc định hỗ trợ tính năng ghim lối tắt, tiện ích và widgetFeatures trong ứng dụng.
[3.8.1/H-SR-2] RẤT NÊN triển khai một trình chạy mặc định giúp truy cập nhanh vào các lối tắt bổ sung do ứng dụng bên thứ ba cung cấp thông qua API ShortcutManager.
[3.8.1/H-SR-3] RẤT NÊN có 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.

[3.8.2/H-SR-1] RẤT NÊN hỗ trợ các tiện ích ứng dụng bên thứ ba.

[3.8.2/H-0-1] PHẢI hỗ trợ các tiện ích ứng dụng 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 hiển thị.
[3.8.3/H-0-4] PHẢI có một bảng 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 ẩn, loại bỏ, chặn) các thông báo thông qua khả năng tương tác của người dùng, chẳng hạn như các nút hành động hoặc bảng điều khiển như đượ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] RẤT 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] RẤT 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] NÊN hiển thị các hành động mà Notification.Action.Builder.setContextual được đặt làm true cùng dòng với các câu trả lời mà Notification.Remoteinput.Builder.setChoices hiển thị.
[3.8.4/H-SR-1] RẤT NÊN triển khai một trợ lý trên thiết bị để xử lý thao tác Trợ lý.

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

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

Thông báo cập nhật trực tiếp của ứng dụng có thể được quảng bá khi ứng dụng đáp ứng tất cả đặc điểm quảng bá. Thông báo như vậy được mô tả là Thông báo được đề xuất về Thông tin cập nhật trực tiếp trong tài liệu này. Các chế độ triển khai thiết bị cầm tay PHẢI hiển thị nổi bật Thông báo cập nhật trực tiếp được quảng bá theo các yêu cầu sau.

Nếu các chế độ triển khai thiết bị Cầm tay khai báo cấp độ API 36.1 trở lên, thì:

[3.8.3.1/H-0-1] PHẢI hiển thị Thông báo cập nhật trực tiếp được quảng bá ở một vị trí nổi bật trên màn hình khoá.
[3.8.3.1/H-0-12] PHẢI hiển thị ở đầu ngăn xếp thông báo Thông báo quan trọng và phía trên các thông báo có màu (trong đó setColorized là true) khi Thông báo được đề xuất về Thông tin cập nhật trực tiếp xuất hiện cùng với các thông báo khác.
- CÓ THỂ xác định thứ tự hiển thị của Thông báo được đề xuất về Thông tin cập nhật trực tiếp trong ngăn thông báo và màn hình khoá khi có nhiều ứng dụng đủ điều kiện nhận Thông báo được đề xuất về Thông tin cập nhật trực tiếp.
[3.8.3.1/H-0-2] PHẢI hiển thị Thông báo cập nhật trực tiếp được quảng bá ở trạng thái mở rộng.
[3.8.3.1/H-0-3] KHÔNG ĐƯỢC cung cấp cho người dùng một phương thức tương tác để thu gọn thông báo đã mở rộng ở trên.
[3.8.3.1/H-0-4] PHẢI hiển thị các kiểu cơ bản (đậm, nghiêng và gạch chân) của nội dung văn bản trong một Thông báo cập nhật trực tiếp được quảng bá, do StyleSpan hoặc UnderlineSpan cung cấp.
[3.8.3.1/H-0-5] CHỈ được hiển thị các đối tượng hành động chuẩn (thông qua Notification.Action) và PHẢI ẩn các đối tượng hành động không chuẩn như hộp nhập, nút trả lời và hành động theo bối cảnh (thông qua addRemoteInput() và setContextual()) trong Thông báo cập nhật trực tiếp được quảng bá, ngay cả khi thông báo có chứa các đối tượng này.
[3.8.3.1/H-0-6] PHẢI hiển thị một Bản trình bày thu gọn (còn gọi là Status Chip) trong tài liệu SDK cho một Thông báo cập nhật trực tiếp được quảng bá PHẢI bao gồm Notification.getSmallIcon().
- [3.8.3.1/H-0-7] Các trường khác là không bắt buộc đối với Biểu diễn thu gọn, nhưng bất cứ khi nào biểu diễn thu gọn có thể mở rộng, BẮT BUỘC phải hiển thị Notification.getShortCriticalText() nếu có hoặc Notification.when nếu không có Notification.getShortCriticalText.
- [3.8.3.1/H-0-8] Khi có nhiều thông báo Thông tin cập nhật trực tiếp được quảng bá, bạn PHẢI hiển thị ít nhất một thông báo trong số đó ở thanh trạng thái dưới dạng một Biểu diễn thu gọn.
- [3.8.3.1/H-0-9] BẮT BUỘC phải hiển thị thông báo liên kết (nên dùng) hoặc mở ứng dụng liên kết (thông qua Notification.contentIntent) khi người dùng nhấn vào Bản trình bày thu gọn.
- [3.8.3.1/H-0-13] PHẢI hiển thị tất cả nội dung tương tự trong thông báo liên kết như nội dung có trong bảng thông báo.
[3.8.3.1/H-0-10] Bạn PHẢI cung cấp cho người dùng một thành phần để tắt và bật chế độ hiển thị được quảng bá của thông báo riêng lẻ của ứng dụng.
[3.8.3.1/H-0-11] PHẢI hiển thị chính xác tất cả Thông báo cập nhật trực tiếp, bao gồm nhưng không giới hạn ở Thông báo cập nhật trực tiếp không được quảng bá, không đáp ứng hoặc chỉ đáp ứng một phần đặc điểm quảng bá. Những thông báo không được quảng bá như vậy PHẢI được hiển thị ở trạng thái không được quảng bá.

Nếu các phương thức triển khai thiết bị (bao gồm cả khoá đ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 phương thức này:

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

Nếu các hoạt động triển khai Thiết bị cầm tay hỗ trợ thao tác Trợ lý, thì:

[3.8.4/H-SR-2] 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 để khởi chạy ứng dụng trợ lý như mô tả trong mục 7.2.3. PHẢI khởi chạy ứng dụng trợ lý do người dùng chọn; nói cách khác, ứng dụng triển khai VoiceInteractionService hoặc một hoạt động xử lý ý định ACTION_ASSIST.

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

[3.8.4/H-1-1]^* PHẢI hiển thị thông báo trò chuyện trước các thông báo không phải là thông báo trò chuyện, ngoại trừ các thông báo dịch vụ đang chạy trên nền trước và thông báo có mức độ quan trọng:cao.

Nếu các thiết bị Android cầm tay hỗ trợ màn hình khoá, thì:

[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 về nội dung nghe nhìn.

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

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

Nếu các hoạt động triển khai Thiết bị cầm tay có hỗ trợ các API ControlsProviderService và Control, đồng thời cho phép các ứng dụng bên thứ ba xuất bản các chế độ kiểm soát thiết bị, thì:

[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 một phương thức tương tác có 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ị mà người dùng yêu thích trong số các chế độ điều khiển do các ứng dụng bên thứ ba đăng ký thông qua ControlsProviderService và Control API.
[3.8.16/H-1-3] PHẢI cung cấp quyền truy cập vào thành phần hỗ trợ người dùng này trong vòng 3 lượt tương tác từ mộ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ế độ kiểm soát thông qua API ControlsProviderService cũng như mọi trường được chỉ định do API Control cung cấp trong khả năng tương tác này của người dùng.
[3.8.16/H-1-5] PHẢI cung cấp cho người dùng một lựa chọn để chọn không sử dụng các chế độ kiểm soát thiết bị được xác thực đơn giản 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à Control Control.isAuthRequired API.
[3.8.16/H-1-6] Các chế độ 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 nội dung khai báo ControlsProviderService, bao gồm cả ComponentName của một Hoạt động hợp lệ (theo định nghĩa của API), thì ứng dụng PHẢI nhúng Hoạt động nói trên vào thành phần này của người dùng.
- Nếu ứng dụng không khai báo siêu dữ liệu META_DATA_PANEL_ACTIVITY, thì ứng dụng ĐƯỢC YÊU CẦU 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 khai báo siêu dữ liệu META_DATA_PANEL_ACTIVITY, thì ứng dụng PHẢI truyền chế độ cài đặt được xác định trong [3.8.16/H-1-5] bằng EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS khi khởi chạy hoạt động được nhúng.

Ngược lại, nếu các chế độ 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 ControlsProviderService và Control API.
[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 các hoạt động triển khai thiết bị cầm tay không chạy ở chế độ khoá tác vụ, thì khi nội dung được sao chép vào bảng nhớ tạm, các hoạt động triển khai này sẽ:

[3.8.17/H-1-1] PHẢI trình bày 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 "Đã sao chép nội dung"). Ngoài ra, hãy cho biết liệu dữ liệu trên bảng nhớ tạm có được đồng bộ hoá trên các thiết bị hay không.

Cách 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] NÊN CÀI ĐẶT 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 quá chức năng của các dịch vụ hỗ trợ tiếp cận Tiếp cận bằng công tắc và TalkBack (đối với những ngôn ngữ mà 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] RẤT NÊN có một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị.
[3.13/H-SR-1] RẤT NÊN có một thành phần giao diện người dùng Cài đặt nhanh.

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

[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 chức năng điều hướng được cung cấp dưới dạng một thao tác dựa trên cử chỉ trên màn hình:

Cách triển khai thiết bị cầm tay:

[3.20.1/H-0-1] PHẢI triển khai tất cả các yêu cầu về Luồng âm thanh của Trợ lý.

[7.2.3/H] Vùng nhận dạng cử chỉ cho chức năng Trang chủ KHÔNG ĐƯỢC cao hơn 32 dp so với cuối màn hình.

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

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

Nếu các chế độ triển khai Thiết bị cầm tay hỗ trợ màn hình khoá bảo mật và có bộ nhớ từ 2 GB trở lên cho nhân và không gian người dùng, thì:

[3.9/H-1-2] PHẢI khai báo việc 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 việc hỗ trợ camera thông qua android.hardware.camera.any, thì:

[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, đồng thời khởi chạy camera ở 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 khởi chạy camera ở 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 chức năng chia tách, bằng cách sử dụng tính năng nhúng hoạt động, thì ứng dụng đó sẽ:

[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 bật chức năng chia tách. Hoạt động này 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.

Nếu các hoạt động triển khai thiết bị cho phép người dùng thực hiện mọi loại cuộc gọi, thì

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

2.2.4. Hiệu suất và sức mạnh

[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 trong một giây và NÊN dưới 1 khung hình trong một giây.
[8.1/H-0-2] Độ trễ giao diện người dùng. Các hoạt động 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 quy định của Bộ kiểm tra tính tương thích (CTS) của Android trong vòng chưa đầy 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.

Cách 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 nhất 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 các hoạt động triển khai Thiết bị cầm tay có 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 hoạt động triển khai đó:

[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ả các ứng dụng được miễn trừ khỏi chế độ chờ ứng dụng và chế độ tiết kiệm pin Nghỉ.

Cách triển khai thiết bị cầm tay:

[8.4/H-0-1] PHẢI cung cấp một hồ sơ năng lượng cho từng thành phần, xác định giá trị mức tiêu thụ hiện tại cho từng thành phần phần cứng và mức tiêu hao pin ước tính do các thành phần gây ra theo thời gian như được ghi lại trong trang web Dự án nguồn mở Android.
[8.4/H-0-2] PHẢI báo cáo tất cả các giá trị mức tiêu thụ điện năng theo đơn vị 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 này 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 tiêu thụ điện này thông qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.
[8.4/H] NÊN được quy cho chính thành phần phần cứng nếu không thể quy mức sử dụng điện của thành phần phần cứng cho một ứng dụng.

Nếu các hoạt động triển khai Thiết bị cầm tay có màn hình hoặc đầu ra video, thì:

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

Cách triển khai thiết bị cầm tay:

[8.5/H-0-1] PHẢI cung cấp cho người dùng một thành phần để xem tất cả ứng dụng có dịch vụ trên nền trước hoạt động hoặc các tác vụ do người dùng bắt đầu, bao gồm cả thời lượng của từng dịch vụ này kể từ khi bắt đầu như mô tả trong tài liệu SDK.
[8.5/H-0-2]PHẢI cung cấp cho người dùng một thành phần để dừng ứng dụng đang chạy một dịch vụ trên nền trước hoặc một công việc do người dùng khởi chạy.

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

Cách triển khai thiết bị cầm tay:

[9/H-0-1] PHẢI khai báo tính năng android.hardware.security.model.compatible.
[9.1/H-0-1] PHẢI cho phép các ứng dụng bên thứ ba truy cập vào số liệu thống kê về việc sử dụng thông qua quyền android.permission.PACKAGE_USAGE_STATS và cung cấp một 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 đó để phản hồi ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Nếu các hoạt động triển khai Thiết bị cầm tay có một ứng dụng mặc định để hỗ trợ VoiceInteractionService, thì:

[9.1/H-0-2] KHÔNG ĐƯỢC cấp ACCESS_FINE_LOCATION làm mặc định cho ứng dụng đó.

Các hoạt động triển khai thiết bị PHẢI khai báo hỗ trợ cho android.software.credentials và:

[9/H-0-2] PHẢI tuân thủ ý định android.settings.CREDENTIAL_PROVIDER để cho phép chọn nhà cung cấp ưu tiên cho Trình quản lý thông tin xác thực. Nhà cung cấp này sẽ được bật cho tính năng Tự động điền và cũng sẽ là vị trí mặc định để lưu thông tin đăng nhập mới được nhập thông qua Trình quản lý thông tin xác thực.
[9/H-0-3] PHẢI hỗ trợ ít nhất 2 trình cung cấp thông tin đăng nhập đồng thời và cung cấp cho người dùng một lựa chọn trong ứng dụng Cài đặt để bật hoặc tắt trình cung cấp.
[9.5/H-1-1] Yêu cầu này đã bị xoá trong Android 16.

Cách triển khai thiết bị cầm tay:

[9.11/H-0-2] PHẢI sao lưu việc 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 có các phương thức triển khai thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm MD5, SHA-1 và SHA-2 để hỗ trợ đúng các thuật toán được hệ thống Kho khoá Android hỗ trợ trong một khu vực được cách ly an toàn với mã đang chạy trên nhân và các phiên bản cao hơn. Tính năng cách ly an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà mã nhân hệ điều hành 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 biệt lập, 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 sử dụng chế độ triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc chế độ triển khai bảo mật đã được bên thứ ba xem xét về khả năng cách ly 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 trên màn hình khoá trong môi trường thực thi biệt lập và chỉ khi 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. Thông tin đăng nhập trên 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 biệt lập thực hiện quy trình xác thực trên 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 Gatekeeper (HAL) và Trusty. Bạn có thể dùng các lớp này để đáp ứng yêu cầu này.
[9.11/H-0-5] PHẢI hỗ trợ quy trình 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à quy trình ký được thực hiện trong phần cứng bảo mật. Bạn KHÔNG ĐƯỢC phép sử dụng khoá ký chứng thực làm giá trị nhận dạng thiết bị vĩnh viễn.

Lưu ý: Để đáp ứng yêu cầu này, bạn phải chia sẻ cùng một khoá chứng thực cho một SKU nhất định,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của SKU đó. Nếu có hơn 100.000 đơn vị của SKU đó được sản xuất, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, bạn có thể sử dụng giải pháp Cung cấp khoá từ xa để cung cấp các khoá chứng thực có thời hạn ngắn cho thiết bị.

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

Khi các thiết bị Cầm tay triển khai hỗ trợ màn hình khoá bảo mật, chúng sẽ:

[9.11/H-1-1] PHẢI cho phép người dùng chọn thời gian chờ chuyển sang trạng thái ngủ ngắn nhất, tức là thời gian chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, là 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ừ phương thức xác thực chính được mô tả trong 9.11.1 Khoá bảo mật an toàn. AOSP đáp ứng yêu cầu này ở chế độ khoá.

Nếu các phương thức triển khai thiết bị có màn hình khoá an toàn và bao gồm một hoặc nhiều tác nhân tin cậy triển khai TrustAgentService System API, thì các phương thức triển khai đó:

[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 (chẳng hạn như mã PIN, hình mở khoá hoặc mật khẩu) thường xuyên hơn 72 giờ một lần.

Nếu các hoạt động triển khai thiết bị cầm tay 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 gọi API Hệ thống TrustAgentService.grantTrust() bằng cờ FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, thì các hoạt động triển khai này:

[9.11.1/H-1-1] PHẢI gọi TrustManagerService.revokeTrust() sau một trong hai trường hợp sau:
- Tối đa 24 giờ kể từ khi cấp quyền tin cậy.
- Khoảng thời gian không hoạt động là 8 giờ.

Nếu các hoạt động triển khai Thiết bị cầm tay có nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các hoạt động này sẽ:

[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 bổ sung 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 hạn chế chi tiết hơn trong những ứng dụng có sẵn trong các môi trường đó.

Nếu các hoạt động triển khai Thiết bị cầm tay có nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các hoạt động đó sẽ:

[9.5/H-3-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI phù hợp với cách triển khai các chế độ kiểm soát của AOSP để cho phép /không cho phép người dùng khác truy cập vào cuộc gọi thoại và tin nhắn SMS.
[9.5/H-4-1] Yêu cầu này đã bị xoá trong Android 16.
[9.5/H-4-2] Yêu cầu đã bị xoá trong Android 16.

Chế độ cài đặt bị hạn chế

Chế độ Cài đặt bị hạn chế cung cấp cho người dùng cảnh báo hiển thị và yêu cầu người dùng xác nhận để cấp quyền cho từng ứng dụng thuộc một trong hai trường hợp sau:

Được cài đặt sau khi tải xuống thông qua một ứng dụng (ví dụ: ứng dụng nhắn tin hoặc trình duyệt) không phải là ứng dụng "cửa hàng ứng dụng" do PackageManager xác định là PACKAGE_DOWNLOADED_FILE.
Được cài đặt từ một tệp cục bộ (ví dụ: ứng dụng được tải lên thiết bị mà không qua Cửa hàng Play) do PackageManager xác định là PACKAGE_SOURCE_LOCAL_FILE.

Đối với bất kỳ Quyền bắt buộc nào và giá trị nhận dạng được liên kết của quyền đó được liệt kê trong [9.8/H-0-5] bên dưới.

Những ứng dụng như vậy được gắn nhãn "Ứng dụng được bảo vệ" cho các yêu cầu được liệt kê trong phần này.

Triển khai thiết bị:

[9.8/H-0-1] PHẢI triển khai Chế độ cài đặt bị hạn chế như mô tả ở trên cho những trường hợp sau:
- Quyền đặc biệt
  - Hỗ trợ tiếp cận (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Trình xử lý thông báo (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - Ứng dụng quản trị thiết bị (Manifest.permission.BIND_DEVICE_ADMIN)
  - Hiển thị trên các ứng dụng khác (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Quyền truy cập dữ liệu sử dụng (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Vai trò (Ứng dụng mặc định)
  - Trình quay số (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Quyền khi bắt đầu chạy
  - Thời lượng SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] PHẢI bật Chế độ cài đặt hạn chế theo mặc định và CỰC KỲ NÊN không có bất kỳ thành phần nào cho phép người dùng tắt Chế độ cài đặt hạn chế cho tất cả các ứng dụng.
[9.8/H-0-3] PHẢI đảm bảo người dùng xác nhận cho từng Ứng dụng thuộc phạm vi điều chỉnh trước khi cấp bất kỳ Quyền bắt buộc nào.
[9.8/H-0-4] CHỈ ĐƯỢC phép người dùng xác nhận để bật chế độ cài đặt bị hạn chế được lấy từ trang AppInfo của Ứng dụng thuộc phạm vi điều chỉnh, bằng cách sử dụng API EnhancedConfirmationManager.
[9.8/H-0-5] NÊN TÍCH HỢP và gọi EnhancedConfirmationManager cho tất cả các quyền đặc biệt để xác định một cách linh động xem các quyền đó có phải là chế độ cài đặt bị hạn chế hay không.
- Chuông báo và lời nhắc: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Quyền truy cập vào mọi tệp: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Hiển thị trên các ứng dụng khác: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Cài đặt ứng dụng không rõ nguồn gốc: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Quản lý nội dung nghe nhìn: AppOpsManager.OPSTR_MANAGE_MEDIA
- Sửa đổi các chế độ cài đặt hệ thống: AppOpsManager.OPSTR_WRITE_SETTINGS
- Hình trong hình: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Bật màn hình: AppOpsManager.OPSTR_TURN_SCREEN_ON
- Thông báo toàn màn hình: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Kiểm soát Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Khả năng hỗ trợ tiếp cận: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Trình tiếp nhận thông báo: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Quyền truy cập dữ liệu sử dụng: AppOpsManager.OPSTR_GET_USAGE_STATS
- Quản trị viên thiết bị: Manifest.permission.BIND_DEVICE_ADMIN
- Không làm phiền: Manifest.permission.MANAGE_NOTIFICATIONS

Thông qua System API VoiceInteractionService, Android hỗ trợ một cơ chế phát hiện từ khoá nóng luôn bật một cách an toàn mà không có chỉ báo truy cập micrô và phát hiện cụm từ tìm kiếm luôn bật mà không có chỉ báo truy cập micrô hoặc camera.

Nếu các hoạt động 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 từ khoá kích hoạt mà không có chỉ báo truy cập micrô, thì các hoạt động triển khai này sẽ:

[9.8/H-1-1] PHẢI đảm bảo rằng dịch vụ phát hiện từ khoá chỉ có thể truyền dữ liệu đến Hệ thống, ContentCaptureService hoặc dịch vụ nhận dạng giọng nói trên thiết bị do SpeechRecognizer#createOnDeviceSpeechRecognizer() tạo.
[9.8/H-1-2] PHẢI đảm bảo dịch vụ phát hiện từ khoá chỉ có thể truyền dữ liệu âm thanh từ micrô hoặc dữ liệu bắt nguồn từ đó đế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 từ micrô dài hơn 30 giây cho một yêu cầu riêng lẻ do phần cứng kích hoạt đến 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ộ nhớ đệm cũ hơn 8 giây cho một yêu cầu riêng lẻ đối với dịch vụ phát hiện từ khoá kích hoạt.
[9.8/H-1-5] KHÔNG ĐƯỢC cung cấp âm thanh micrô được lưu vào bộ nhớ đệm quá 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 phép truyền quá 100 byte dữ liệu (không bao gồm luồng âm thanh) ra khỏi dịch vụ phát hiện từ khoá kích hoạt trên mỗi kết quả từ khoá kích hoạt thành công.
[9.8/H-1-7] KHÔNG ĐƯỢC phép truyền quá 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 phủ định.
[9.8/H-1-8] CHỈ ĐƯỢC 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 của máy chủ hệ thống.
[9.8/H-1-9] KHÔNG ĐƯỢC 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 từ khoá kích hoạt.
[9.8/H-1-10] KHÔNG ĐƯỢC hiển thị dữ liệu định lượng về việc sử dụng micrô của dịch vụ phát hiện từ khoá trong giao diện người dùng.
[9.8/H-1-11] PHẢI ghi nhật ký số lượng 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 hoạt động truyền dữ liệu từ dịch vụ phát hiện từ khoá 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 một kết quả từ khoá 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ự.
[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ả thành công của cụm từ kích hoạt đượ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.
[9.8/H-SR-1] 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 từ khoá kích hoạt.
[9.8/H-SR-2] RẤT NÊN ngăn chặn việ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] RẤT NÊN khởi động lại quy trình lưu trữ dịch vụ phát hiện từ khoá 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 bằng phần cứng, tuỳ theo điều kiện nào đến trước.

Nếu các hoạt động 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 từ khoá 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 cung cấp thông báo rõ ràng cho người dùng về từng cụm từ khoá 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 đó thông qua dịch vụ phát hiện từ khoá kích hoạt.
[9.8/H-2-3] KHÔNG ĐƯỢC truyền dữ liệu từ dịch vụ phát hiện từ khoá kích hoạt, dữ liệu âm thanh, dữ liệu có thể dùng để khôi phục (toàn bộ hoặc một phần) âm thanh hoặc nội dung âm thanh không liên quan đến chính từ khoá 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ị.

Nếu các hoạt động triển khai thiết bị Cầm tay hỗ trợ System API VisualQueryDetectionService hoặc một cơ chế khác để phát hiện truy vấn mà không có chỉ báo về quyền truy cập vào micrô và/hoặc camera, thì:

[9.8/H-3-1] PHẢI đảm bảo rằng dịch vụ phát hiện cụm từ tìm kiếm chỉ có thể truyền dữ liệu đến Hệ thống, hoặc ContentCaptureService, hoặc dịch vụ nhận dạng giọng nói trên thiết bị (do SpeechRecognizer#createOnDeviceSpeechRecognizer() tạo).
[9.8/H-3-2] KHÔNG ĐƯỢC 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 thấy ý định tương tác của người dùng với Ứng dụng trợ lý kỹ thuật số (ví dụ: bằng cách phát hiện sự hiện diện của người dùng thông qua camera).
[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 đã phát hiện của người dùng trong giao diện người dùng ngay sau khi phát hiện thấy cụm từ tìm kiếm của người dùng.
[9.8/H-3-5] KHÔNG ĐƯỢC 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 trực quan.

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

[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 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 đề cập trong mục 9.1 có 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 quan đến các ứng dụng đó.
[9.8.2/H-4-3] KHÔNG ĐƯỢC ẩn chỉ báo micrô đố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.
[9.8.2/H-4-4] 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 ghi nhận quyền sở hữu liên quan đến 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ì:

[9.8.2/H-5-1] PHẢI hiển thị chỉ báo camera khi một ứng dụng đang truy cập vào dữ liệu trực tiếp của camera, nhưng không hiển thị khi camera chỉ được(các) ứng dụng có vai trò được đề cập 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 sử dụng camera như được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi nhận quyền sở hữu liên quan đến các ứng dụng đó.
[9.8.2/H-5-3] KHÔNG ĐƯỢC ẩn chỉ báo camera đối với các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc hoạt động tương tác trực tiếp của người dùng.

Khi một ứng dụng không phải ứng dụng hệ thống ở chế độ nền trước truy cập vào thông tin vị trí chính xác của thiết bị, thì thiết bị sẽ:

[9.8.8/H-6-1] PHẢI hiển thị một chỉ báo mà người dùng có thể thấ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 các hoạt động triển khai thiết bị hỗ trợ tính năng này, thì:

[9.10/H-1-1] PHẢI xác minh tất cả các phân vùng chỉ đọc được gắn trong trình tự khởi động Android và chuỗi đại diện VBMeta phải bao gồm tất cả các phân vùng đã xác minh này trong quá trình tính toán.

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

Các cách 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.

Cách triển khai thiết bị cầm tay:

Perfetto
- [6.1/H-0-2] PHẢI hiển thị một tệp nhị phân /system/bin/perfetto cho người dùng shell mà cmdline tuân thủ tài liệu perfetto.
- [6.1/H-0-3] Tệp nhị phân perfetto PHẢI chấp nhận một 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 Perfetto.
- [6.1/H-0-5] PHẢI cung cấp (thông qua tệp nhị phân perfetto) ít nhất các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [6.1/H-0-6] Trình nền được theo dõi perfetto PHẢI được bật theo mặc định (thuộc tính hệ thống persist.traced.enable).

Chúng tôi đã thực hiện những thay đổi đáng kể đối với cấu trúc yêu cầu của lớp Hiệu suất nội dung nghe nhìn. Kể từ API 37, chúng tôi đã thêm các cấp độ mới 1, 10, 20 và 37. Chúng tôi cũng giảm độ phức tạp của yêu cầu bằng cách tham khảo trang Đo lường cấp hiệu suất của nội dung nghe nhìn. Trang này trình bày chi tiết từng yêu cầu được đo lường theo cấp MPC.

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

Hãy xem mục 7.11 để biết định nghĩa về lớp hiệu suất nội dung nghe nhìn và Định nghĩa về lớp hiệu suất nội dung nghe nhìn cho tất cả các chỉ số.

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ề một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các phương thức này:

PHẢI đáp ứng tất cả các yêu cầu về nội dung nghe nhìn được nêu trong mục 2.2.7.1 của CDD Android 17 tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[5.1/H-1-1] PHẢI quảng cáo số lượng tối đa các phiên bản bộ giải mã video phần cứng có thể chạy đồng thời trong mọi tổ hợp codec thông qua các phương thức CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints() tương ứng với Cấp hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-2] PHẢI hỗ trợ các phiên bộ giải mã video phần cứng (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn), các phiên bản đồng thời và tình trạng giảm khung hình tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-3] PHẢI quảng cáo số lượng phiên bộ mã hoá video phần cứng tối đa có thể chạy đồng thời trong mọi tổ hợp bộ mã hoá và giải mã thông qua các phương thức CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints() tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-4] PHẢI hỗ trợ các phiên bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn), các phiên bản đồng thời và hiện tượng giảm khung hình tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-5] PHẢI quảng cáo số lượng tối đa các phiên bản bộ mã hoá và giải mã video phần cứng đồng thời trong mọi tổ hợp codec thông qua các phương thức CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints() tương ứng với Cấp hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-6] PHẢI hỗ trợ bộ giải mã video phần cứng và bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn), các phiên đồng thời và hiện tượng giảm khung hình tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-7] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã cho phiên mã hoá video 1080p hoặc nhỏ hơn đối với tất cả bộ mã hoá video phần cứng khi chịu tải tương ứng với Cấp hiệu suất đa phương tiện mà thiết bị đã khai báo.
[5.1/H-1-8] PHẢI có độ trễ khởi động bộ mã hoá cho phiên mã hoá âm thanh có tốc độ bit từ 128 Kb/giây trở xuống đối với tất cả bộ mã hoá âm thanh khi chịu tải tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-9] PHẢI hỗ trợ 2 phiên bộ giải mã video phần cứng bảo mật (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn) và số khung hình bị giảm tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-10] PHẢI hỗ trợ 3 phiên giải mã video phần cứng không bảo mật cùng với 1 phiên giải mã video phần cứng bảo mật (tổng cộng 4 phiên) (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn), độ phân giải và số khung hình bị rớt tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-11] PHẢI hỗ trợ một bộ giải mã bảo mật cho mọi bộ giải mã AVC, HEVC, VP9 hoặc AV1 phần cứng tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-12] PHẢI có độ trễ khởi tạo bộ mã hoá và giải mã cho phiên giải mã video 1080p hoặc nhỏ hơn đối với tất cả bộ giải mã video phần cứng khi chịu tải tương ứng với Cấp hiệu suất đa phương tiện đã khai báo của thiết bị.
[5.1/H-1-13] PHẢI có độ trễ khởi tạo bộ mã hoá và giải mã cho phiên giải mã âm thanh có tốc độ bit từ 128 Kb/giây trở xuống cho tất cả bộ giải mã âm thanh khi chịu tải tương ứng với Cấp hiệu suất đa phương tiện đã khai báo của thiết bị.
[5.1/H-1-14] PHẢI hỗ trợ hồ sơ bộ giải mã phần cứng AV1, tính năng và phương thức hiển thị tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-15] PHẢI có ít nhất 1 bộ giải mã video phần cứng hỗ trợ 4K60 tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-16] PHẢI có ít nhất 1 bộ mã hoá video phần cứng hỗ trợ 4K60 tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[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ở AVIF tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-18] PHẢI hỗ trợ bộ mã hoá AV1 đáp ứng các yêu cầu về tốc độ bit, khung hình/giây và độ phân giải tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[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à các phiên mã hoá video phần cứng (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn), độ phân giải và số khung hình bị giảm tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-20] PHẢI 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ị tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-21] PHẢI hỗ trợ FEATURE_DynamicColorAspect cho tất cả bộ giải mã video phần cứng (AVC, HEVC, VP9, AV1 hoặc phiên bản mới hơn) tương ứng với Cấp độ hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.
[5.1/H-1-22] PHẢI hỗ trợ mã hoá, giải mã, chỉnh sửa bằng GPU và hiển thị nội dung video ở tỷ lệ khung hình dọc tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.2/H-2-1] Nếu quá trình triển khai thiết bị hỗ trợ bộ mã hoá AVC hoặc HEVC dựa trên phần cứng, thì quá trình đó PHẢI đáp ứng mục tiêu chất lượng tối thiểu do đường cong tốc độ-độ biến dạng của bộ mã hoá video xác định cho các bộ mã hoá và giải mã đó, tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

[5.2/H-2-2] PHẢI hỗ trợ MMAP trên đường dẫn loa tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

[5.3/H-1-1] PHẢI đáp ứng các yêu cầu về hiệu suất phiên video và hiện tượng rớt khung hình tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.3/H-1-2] PHẢI đáp ứng các yêu cầu về hiệu suất thay đổi độ phân giải video tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.6/H-1-1] PHẢI đáp ứng các yêu cầu về độ trễ khi nhấn để phát âm thanh tương ứng với Cấp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[5.6/H-1-2] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh khứ hồi tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.6/H-1-3] PHẢI đáp ứng các yêu cầu về âm thanh 24 bit tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.6/H-1-4] PHẢI hỗ trợ >= 4 thiết bị âm thanh USB kênh tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.6/H-1-5] PHẢI hỗ trợ các thiết bị MIDI tuân thủ tiêu chuẩn và khai báo cờ tính năng MIDI tương ứng với Cấp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[5.6/H-1-9] PHẢI hỗ trợ ít nhất 12 kênh trộn tương ứng với Cấp hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.

[5.6/H-3-1] PHẢI có thể xử lý việc chuyển đổi giữa các sóng hình sin đang phát mà không bị tràn vùng đệm âm thanh tương ứng với Cấp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[5.6/H-3-2] PHẢI đáp ứng các yêu cầu về kênh đầu ra của thiết bị âm thanh USB tương ứng với Cấp lớp hiệu suất nội dung đa phương tiện mà thiết bị đã khai báo.
[5.6/H-3-3] PHẢI đáp ứng các yêu cầu về kênh đầu vào của thiết bị âm thanh USB tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

[5.6/H-SR-1] RẤT NÊN hỗ trợ tính năng trộn kênh âm thanh tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.7/H-1-2] PHẢI hỗ trợ MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL với khả năng giải mã tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[5.12/H-1-2] PHẢI đáp ứng các yêu cầu về định dạng màu đối với bộ mã hoá AV1 và HEVC phần cứng tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[5.12/H-1-3] PHẢI quảng cáo khả năng hỗ trợ tiện ích EXT_YUV_target tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.1.4/H-1-1] PHẢI đáp ứng các yêu cầu về bộ xử lý hiển thị (DPU) tương ứng với Cấp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.

2.2.7.2. Máy ảnh

Nếu các hoạt động triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì:

PHẢI đáp ứng các yêu cầu về camera được nêu trong mục 2.2.7.2 của CDD Android 17 tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

Nếu các hoạt động triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì:

[7.5/H-1-1] PHẢI đáp ứng các yêu cầu về độ phân giải của camera sau chính và khả năng quay video tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-2] PHẢI đáp ứng các yêu cầu về độ phân giải của camera trước chính và khả năng quay video tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã công bố.
[7.5/H-1-3] PHẢI hỗ trợ các yêu cầu về thuộc tính android.info.supportedHardwareLevel tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[7.5/H-1-4] PHẢI hỗ trợ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME cho cả camera chính tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-5] PHẢI đáp ứng các yêu cầu về độ trễ chụp JPEG của Camera2 tương ứng với Cấp độ hiệu suất nội dung đa phương tiện mà thiết bị đã khai báo.
[7.5/H-1-6] PHẢI đáp ứng các yêu cầu về độ trễ khi khởi động Camera2 tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-8] PHẢI đáp ứng các yêu cầu về tính năng chụp ảnh RAW của camera tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-9] PHẢI đáp ứng các yêu cầu về tốc độ cao khi quay video bằng camera chính phía sau tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-10] PHẢI đáp ứng các yêu cầu tối thiểu về tỷ lệ thu phóng tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-11] PHẢI triển khai tính năng phát trực tiếp đồng thời từ camera trước và sau trên các camera chính tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-12] PHẢI hỗ trợ tính năng ổn định video cho camera sau chính tương ứng với Cấp hiệu suất đa phương tiện mà thiết bị đã khai báo.
[7.5/H-1-13] PHẢI hỗ trợ khả năng LOGICAL_MULTI_CAMERA cho camera sau chính tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-14] PHẢI hỗ trợ khả năng STREAM_USE_CASE cho cả camera trước chính và camera sau chính tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-15] PHẢI hỗ trợ các tiện ích mở rộng Chế độ ban đêm thông qua cả tiện ích mở rộng CameraX và tiện ích mở rộng Camera2 cho các camera chính tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-16] PHẢI hỗ trợ khả năng DYNAMIC_RANGE_TEN_BIT cho các camera chính tương ứng với Cấp độ hiệu suất nội dung đa phương tiện mà thiết bị đã khai báo.
[7.5/H-1-17] PHẢI hỗ trợ các tính năng phát hiện khuôn mặt cho camera chính tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-18] PHẢI hỗ trợ JPEG_R cho camera sau chính và camera trước chính tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.5/H-1-19] PHẢI hỗ trợ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION cho camera sau chính tương ứng với Cấp độ hiệu suất nội dung đa phương tiện mà thiết bị đã khai báo.
[7.5/H-1-20] Theo mặc định, PHẢI xuất JPEG_R cho camera sau chính và camera trước chính trong ứng dụng camera gốc tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

[7.5/H-1-21] PHẢI có ít nhất một camera trước hoặc camera sau tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

2.2.7.3. Phần cứng

Nếu các phương thức triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các phương thức này:

PHẢI đáp ứng các yêu cầu về phần cứng được liệt kê trong mục 2.2.7.3 của CDD Android 17 tương ứng với Cấp lớp hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.

Nếu các phương thức triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các phương thức này:

[7.1.1.1/H-1-1] Mục này bị bỏ qua một cách có chủ ý.
[7.1.1.1/H-2-1] PHẢI có độ phân giải màn hình tương ứng với Cấp độ hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[7.1.1.3/H-1-1] Mục này bị bỏ qua một cách có chủ ý.
[7.1.1.3/H-2-1] PHẢI có mật độ màn hình tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.1.1.3/H-3-1] PHẢI hỗ trợ các yêu cầu về màn hình HDR tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.6.1/H-1-1] Mục này bị bỏ qua một cách có chủ ý.
[7.6.1/H-2-1] PHẢI đáp ứng các yêu cầu về bộ nhớ tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.

2.2.7.4. Hiệu suất

Nếu các hoạt động triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì:

PHẢI đáp ứng các yêu cầu về hiệu suất được nêu trong mục 2.2.7.4 của CDD Android 17 tương ứng với Cấp lớp hiệu suất của nội dung nghe nhìn mà thiết bị đã khai báo.

Nếu các hoạt động triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì:

[8.2/H-1-1] PHẢI đảm bảo hiệu suất ghi tuần tự tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn đã khai báo của thiết bị.
[8.2/H-1-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[8.2/H-1-3] PHẢI đảm bảo hiệu suất đọc tuần tự tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[8.2/H-1-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tương ứng với Cấp độ hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[8.2/H-1-5] PHẢI đảm bảo hiệu suất đọc và ghi tuần tự song song tương ứng với Cấp lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

2.2.7.5. Đồ hoạ

Nếu các phương thức triển khai thiết bị Cầm tay trả về một giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các phương thức này:

[7.1.4.1/H-1-2] PHẢI hỗ trợ các tiện ích EGL bắt buộc tương ứng với Cấp độ lớp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.
[7.1.4.1/H-1-3] PHẢI hỗ trợ các tính năng bắt buộc của Vulkan tương ứng với Cấp hiệu suất nội dung nghe nhìn mà thiết bị đã khai báo.

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 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 tuyến khi ngồi cách xa khoảng 10 feet ("giao diện người dùng ngồi tựa lưng" hoặc "giao diện người dùng 10 feet").

Việc triển khai thiết bị Android được phân loại là Truyền hình 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 10 feet.
Có màn hình hiển thị nhúng với đường chéo dài 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 chức năng Trang chủ và Quay lại.
[7.2.3/T-0-2] PHẢI gửi cả sự kiện nhấn bình thường và nhấn lâu của chức năng Quay lại (KEYCODE_BACK) đến ứng dụng ở nền trước.
[7.2.6.1/T-0-1] PHẢI hỗ trợ bộ điều khiển trò chơi và khai báo cờ tính năng android.hardware.gamepad.
[7.2.7/T] PHẢI cung cấp một điều khiển từ xa để người dùng có thể truy cập vào chế độ thao tác không chạm và nhập các phím điều hướng chính.

Nếu các thiết bị triển khai TV có con quay hồi chuyển 3 trục, thì:

[7.3.4/T-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.
[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 1.000 độ 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 biến động để lưu trữ dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").

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

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

Nếu các hoạt động triển khai thiết bị TV là 32 bit:

[7.6.1/T-1-1] Bộ nhớ mà nhân và không gian người dùng có thể truy cập PHẢI có dung lượng ít nhất là 896 MB nếu dùng bất kỳ mật độ nào sau đây:
- 400 dpi trở lên trên màn hình nhỏ/màn hì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 các hoạt động triển khai thiết bị TV là 64 bit:

[7.6.1/T-2-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI ít nhất là 1280 MB nếu dùng bất kỳ mật độ nào sau đây:
- 400 dpi trở lên trên màn hình nhỏ/màn hì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

Xin lưu ý rằng "bộ nhớ có sẵn cho nhân hệ điều hành 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ớ đã được 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 hệ điều hành trên các hoạt động triển khai thiết bị.

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

[5.1/T-0-1] Cấu hình AAC MPEG-4 (AAC LC)
[5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
[5.1/T-0-3] AAC ELD (AAC có độ trễ thấp nâng cao)

[5.1/T-0-4] MPEG-D USAC có MPEG-D DRC (AAC hiệu suất cao mở rộng)

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 này cho các ứng dụng bên thứ ba:

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

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

[5.2.2/T-SR-1] NÊN HỖ TRỢ MẠNH MẼ việc 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 này 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
[5.3.2/T-0-7] AV1

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

[5.3.1/T-1-1] HD 1080p ở tốc độ 29,97 khung hình/giây với Cấu hình chính cấp cao.
[5.3.1/T-1-2] HD 1080i ở tốc độ 59,94 khung hình/giây với Cấu hình chính cấp cao. Chúng PHẢI khử xen kẽ video MPEG-2 xen kẽ và cung cấp video đó cho các ứng dụng bên thứ ba.

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

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

Các thiết bị truyền hình có bộ giải mã phần cứng H.265 PHẢI hỗ trợ việc 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 ở tốc độ 60 khung hình/giây với Cấu hình chính cấp 4.1

Nếu các thiết bị triển khai TV có bộ giải mã phần cứng H.265 hỗ trợ giải mã H.265 và cấu hình giải mã UHD, thì:

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

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

[5.3.6/T-1-1] Cấu hình giải mã HD 1080p ở 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ợ hoạt động giải mã VP9, như được trình bày 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 ở tốc độ 60 khung hình/giây với hồ sơ 0 (độ sâu màu 8 bit)

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

[5.3.7/T-2-1] PHẢI hỗ trợ cấu hình giải mã UHD ở tốc độ 60 khung hình/giây với cấu hình 0 (độ sâu màu 8 bit).
[5.3.7/T-SR1] NÊN hỗ trợ cấu hình giải mã UHD ở tốc độ 60 khung hình/giây với cấu hình 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à mức 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 qua âm thanh nén (trong đó không có quá trình giải mã âm thanh nào được thực hiện trên thiết bị).

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

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

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

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

Nếu các chế độ triển khai thiết bị truyền hình không hỗ trợ việc 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 chế độ này:

[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] 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 sẵn một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng một 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 một cách triển khai hoàn chỉnh của API android.webkit.Webview.

Nếu các chế độ triển khai thiết bị Android Television hỗ trợ màn hình khoá, thì:

[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 về nội dung nghe nhìn.

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

[3.8.14/T-SR-1] RẤT NÊN hỗ trợ chế độ nhiều cửa sổ trong chế độ xem 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] CỰC KỲ 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 quá chức năng của dịch vụ hỗ trợ tiếp cận 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ài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở TalkBack.

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

[3.11/T-SR-1] RẤT NÊN đưa vào một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị.
[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.

Khuôn khổ đầu vào của Android Television (TIF) giúp đơn giản hoá việc phân phối nội dung phát 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 kiểm soát các thiết bị Android TV.

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

[3/T-0-2] PHẢI khai báo tính năng nền tảng android.software.live_tv.
[3/T-0-3] PHẢI hỗ trợ tất cả các API TIF để có thể cài đặt và sử dụng trên thiết bị một ứng dụng dùng các API này và dịch vụ đầu vào dựa trên TIF của bên thứ ba.

Android Television Tuner Framework (TF) hợp nhất việc xử lý nội dung phát sóng trực tiếp từ Tuner với nội dung phát trực tuyến từ IP trên các thiết bị Android Television. Tuner Framework cung cấp một API tiêu chuẩn để tạo các dịch vụ đầu vào sử dụng Android Television Tuner.

Nếu các hoạt động triển khai thiết bị hỗ trợ Bộ chỉnh kênh, thì:

[3/T-1-1] PHẢI hỗ trợ tất cả các API Tuner Framework để có thể cài đặt và sử dụng ứng dụng dùng các API này trên thiết bị.

2.3.4. Hiệu suất và sức mạnh

[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 trong một giây và NÊN dưới 1 khung hình trong một 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 nhất 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 các chế độ triển khai thiết bị truyền hình có 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 chế độ triển khai đó:

[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 các chế độ 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ị là 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 các thiết bị triển khai TV 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 Chế độ chờ ứng dụng và chế độ Nghỉ tiết kiệm pin.

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

[8.4/T-0-1] PHẢI cung cấp một hồ sơ năng lượng cho từng thành phần, xác định giá trị mức tiêu thụ hiện tại cho từng 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 lại trong trang web Dự án nguồn mở Android.
[8.4/T-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng bằng miliampe giờ (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 này thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/T] PHẢI được gán cho chính thành phần phần cứng nếu không thể gán mức tiêu thụ điện 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 thông tin về mức tiêu thụ điện này thông qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.

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.

Nếu các chế độ triển khai thiết bị truyền hình có một ứng dụng mặc định để hỗ trợ VoiceInteractionService, thì:

[9.1/T-0-1] KHÔNG ĐƯỢC cấp ACCESS_FINE_LOCATION làm mặc định cho ứng dụng đó.

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

[9.11/T-0-1] PHẢI sao lưu việc 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 có các phương thức triển khai thuật toán mật mã RSA, AES, ECDSA và HMAC cũng như các hàm băm MD5, SHA-1 và SHA-2 để hỗ trợ đúng các thuật toán được hệ thống Kho khoá Android hỗ trợ trong một khu vực được cách ly an toàn với mã đang chạy trên nhân trở lên. Tính năng cách ly an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà mã nhân hệ điều hành 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 biệt lập, 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 sử dụng việc triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một giải pháp triển khai bảo mật đã được bên thứ ba xem xét về khả năng cô lập 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 biệt lập và chỉ khi 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. Thông tin đăng nhập trên 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 biệt lập thực hiện quy trình xác thực trên 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 (HAL) Gatekeeper và Trusty. Bạn có thể dùng các lớp này để đáp ứng yêu cầu này.
[9.11/T-0-4] PHẢI hỗ trợ quy trình 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à quy trình ký được thực hiện trong phần cứng bảo mật. Bạn KHÔNG ĐƯỢC phép sử dụng khoá ký chứng thực làm giá trị nhận dạng thiết bị vĩnh viễn.

Lưu ý: Để đáp ứng yêu cầu này, bạn phải chia sẻ cùng một khoá chứng thực cho một SKU nhất định,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của SKU đó. Nếu có hơn 100.000 đơn vị của SKU đó được sản xuất, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, bạn có thể sử dụng giải pháp Cung cấp khoá từ xa để cung cấp các khoá chứng thực có thời hạn ngắn cho thiết bị.

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

[9.11/T-1-1] PHẢI cho phép người dùng chọn thời gian chờ Chế độ ngủ để chuyển 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à 15 giây trở xuống.

Nếu các hoạt động triển khai thiết bị truyền hình có nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các hoạt động này sẽ:

[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 bổ sung 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 hạn chế chi tiết hơn trong những ứng dụng có sẵn trong các môi trường đó.

Nếu các hoạt động triển khai thiết bị truyền hình có nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các hoạt động này sẽ:

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

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

[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 hiển thị khi micrô chỉ được HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng giữ vai trò được đề cập trong Phần 9.1 Quyền có giá trị nhận dạng CDD C-3-X truy cập.
[9.8.2/T-4-2] KHÔNG ĐƯỢC ẩn chỉ báo micrô đố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.

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

[9.8.2/T-5-1] PHẢI hiển thị chỉ báo camera khi một ứng dụng đang truy cập vào dữ liệu trực tiếp của camera, nhưng không cần hiển thị khi camera chỉ được(các) ứng dụng có vai trò được nêu trong Phần 9.1 Quyền có 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 camera đố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ông cụ và Tuỳ chọn 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ị một tệp nhị phân /system/bin/perfetto cho người dùng shell mà cmdline tuân thủ tài liệu perfetto.
- [6.1/T-0-2] Tệp nhị phân perfetto PHẢI chấp nhận một cấu hình protobuf làm dữ liệu đầu vào tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [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.
- [6.1/T-0-5] Trình nền được theo dõi perfetto PHẢI được bật theo mặc định (thuộc tính hệ thống persist.traced.enable).

2.4. Yêu cầu đối với đồng hồ

Thiết bị Android Watch là một cách triển khai thiết bị Android được thiết kế để đeo trên cơ thể, chẳng hạn như 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

Triển khai thiết bị xem:

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

Nếu các hoạt động triển khai thiết bị Watch có bộ nhận GPS/GNSS và báo cáo khả năng cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps, thì các hoạt động này:

[7.3.3/W-1-1] PHẢI báo cáo các phép đo GNSS ngay khi tìm thấy, ngay cả khi một 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 tốc độ giả và phạm vi giả của GNSS. Trong điều kiện không gian thoáng đã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 bình phương, các thông tin 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 95% thời gian.

Nếu các thiết bị Watch có con quay hồi chuyển 3 trục, thì:

[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 1.000 độ mỗi giây.

Nếu các hoạt động triển khai thiết bị Watch hỗ trợ kết nối dữ liệu di động, thì:

[7.4.1/W-1-1] PHẢI khai báo tính năng android.hardware.telephony.data.

Triển khai thiết bị xem:

[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 biến động dành 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ớ dà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

Triển khai thiết bị xem:

[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 sẵn một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng một 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.

Triển khai thiết bị xem:

[3.8.4/W-SR-1] RẤT NÊN triển khai một trợ lý trên thiết bị để xử lý thao tác Trợ lý.

Xem các hoạt động 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] 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 quá chức năng của dịch vụ hỗ trợ tiếp cận 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ài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở TalkBack.

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

[3.11/W-SR-1] RẤT NÊN đưa vào một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị.
[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à sức mạnh

Nếu các hoạt động triển khai thiết bị Watch có 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 hoạt động triển khai đó:

[8.3/W-SR-1] RẤT 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 Chế độ chờ ứng dụng và chế độ tiết kiệm pin Nghỉ.
[8.3/W-SR-2] NÊN CUNG CẤP cho người dùng thành phần để bật và tắt tính năng Trình tiết kiệm pin.

Triển khai thiết bị xem:

[8.4/W-0-1] PHẢI cung cấp một hồ sơ năng lượng cho từng thành phần, xác định giá trị tiêu thụ hiện tại cho từng 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 lại trong trang web Dự án nguồn mở Android.
[8.4/W-0-2] PHẢI báo cáo tất cả cá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 cho mỗi UID của 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.
[8.4/W-0-4] PHẢI cung cấp thông tin về mức tiêu thụ điện này thông qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.
[8.4/W] PHẢI được quy cho chính thành phần phần cứng nếu không thể quy mức sử dụng điện 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

Triển khai thiết bị xem:

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

Nếu các hoạt động triển khai thiết bị Watch có một ứng dụng mặc định để hỗ trợ VoiceInteractionService, thì:

[9.1/W-0-1] KHÔNG ĐƯỢC cấp ACCESS_FINE_LOCATION làm giá trị mặc định cho ứng dụng đó.

Nếu các hoạt động triển khai thiết bị Watch có nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì các hoạt động này sẽ:

[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 bổ sung 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 hạn chế chi tiết hơn trong những ứng dụng có sẵn trong các môi trường đó.

Nếu các hoạt động triển khai thiết bị Watch có nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì các hoạt động đó sẽ:

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

Nếu các quy 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 tin cậy triển khai TrustAgentServiceSystem API, thì các quy trình này:

[9.11.1/W-1-1] PHẢI yêu cầu người dùng xác thực bằng một trong các phương thức xác thực chính được đề xuất (chẳng hạn như mã PIN, hình mở khoá hoặc mật khẩu) thường xuyên hơn một lần mỗi 72 giờ ít nhất mỗi 336 giờ (14 ngày) .

Nếu các quy 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 tin cậy, gọi API hệ thống TrustAgentService.grantTrust() bằng cờ FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, thì các quy trình này sẽ:

[9.11.1/W-2-1] PHẢI đáp ứng các điều kiện sau để gọi grantTrust() bằng cờ đó:
- Thiết bị được kết nối với một thiết bị cầm tay chính thực ở gần có màn hình khoá riêng, và
- Người dùng đã xác thực danh tính của mình bằng màn hình khoá hoặc dữ liệu sinh trắc học Loại 3 đó trong vòng 30 giây gần nhất.
[9.11.1/W-2-2] PHẢI đặt trạng thái của thiết bị thành TrustState.TRUSTABLE khi thiết bị đeo rời khỏi cổ tay hoặc cơ thể và TrustAgent chưa thu hồi trạng thái tin cậy.

2.5. Yêu cầu đối với ô tô

Việc triển khai Android Automotive đề cập đến đầu phát trung tâm của ô tô chạy Android dưới dạng 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à Ô tô nếu chú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ắm vào một phương tiện ô tô.
Đang 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ị trên ô 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 nhất 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.1.1.1/A-0-3] PHẢI hỗ trợ kết hợp GPU của bộ đệm đồ hoạ có kích thước ít nhất bằng độ phân giải cao nhất của mọi màn hình tích hợp.

Nếu các chế độ triển khai thiết bị trên ô tô hỗ trợ chế độ Nhiều người dùng đồng thời (nhiều người dùng Android có thể tương tác đồng thời với thiết bị, mỗi người dùng màn hình riêng khi bật config_multiuserVisibleBackgroundUsers), thì:

[7.1.1.1/A-1-1] PHẢI có một màn hình riêng biệt có kích thước đường chéo vật lý ít nhất là 6 inch cho mỗi vùng người ngồi đối với màn hình chính. Bạn nên gắn thẻ này là CarOccupantZoneManager.DISPLAY_TYPE_MAIN cho từng vùng cư trú.
[7.1.1.1/A-1-2] PHẢI có bố cục kích thước màn hình ít nhất là 750 dp x 480 dp cho mỗi màn hình chính.

Nếu các hoạt động triển khai thiết bị ô tô hỗ trợ OpenGL ES 3.1, thì:

[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 biểu tượng.

Nếu các chế độ triển khai thiết bị Ô tô có hỗ trợ Vulkan, thì:

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

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

[7.1.4.5/A-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ị trên ô tô:

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

Nếu các chế độ triển khai thiết bị Automotive khai báo việc hỗ trợ thông qua một thuộc tính hệ thống graphics.gpu.profiler.support, thì:

[7.1.4.6/A-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à GPU RenderStage được xác định trong tài liệu Perfetto.
[7.1.4.6/A-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 giao thức gói gpu counter trace.
[7.1.4.6/A-1-3] PHẢI báo cáo các giá trị tuân thủ cho GPU RenderStages của thiết bị theo render stage trace packet proto.
[7.1.4.6/A-1-4] PHẢI báo cáo một điểm theo dõi Tần suất GPU theo quy định của định dạng: power/gpu_frequency.

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

[7.1.5/A-0-1] PHẢI hỗ trợ chế độ tương thích ứng dụng cũ như được triển khai bằng mã nguồn mở Android nguồn trên. Tức là các hoạt động 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, đồng thời KHÔNG ĐƯỢC thay đổi hành vi của chính chế độ tương thích.

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

[7.1.7/A-0-1] PHẢI định cấu hình màn hình phụ trong tầm nhìn của người lái xe dưới dạng FLAG_PRIVATE.
[7.2.3/A-0-1] PHẢI cung cấp chức năng Trang chủ và CÓ THỂ cung cấp chức năng Quay lại và Gần đây.
[7.2.3/A-0-2] PHẢI gửi cả sự kiện nhấn bình thường và nhấn lâu của chức năng 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ế độ ngày/đêm của trang tổng quan và NÊN 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 Máy đo quang.
[7.3/A-0-3] PHẢI cung cấp trường thông tin bổ sung về 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Ể ước tính vị trí bằng cách kết hợp GPS/GNSS với các cảm biến khác. Nếu Vị trí được tính toán theo phương pháp ước tính vị trí, thì 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 thuộc tính của xe đã dùng.
[7.3/A-0-4] Vị trí được yêu cầu thông qua LocationManager#requestLocationUpdates() KHÔNG ĐƯỢC khớp với bản đồ.
[7.3.1/A-0-4] PHẢI tuân thủ hệ toạ độ cảm biến trên ô tô của Android.
[7.3/A-SR-1] RẤT NÊN có gia tốc kế 3 trục và con quay hồi chuyển 3 trục.
[7.3/A-SR-2] RẤT NÊN triển khai và báo cáo cảm biến TYPE_HEADING.

[7.3/A-1-1] PHẢI đặt giá trị cờ NIGHT_MODE nhất quán với chế độ ngày/đêm của trang tổng quan trên tất cả các màn hình, kể cả màn hình ở ghế sau.

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

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

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

[7.3.1/A-SR-1] BẠN NÊN TRIỂN KHAI cảm biến kết hợp cho gia tốc kế có số trục hạn chế.

Nếu các chế độ triển khai thiết bị ô tô có gia tốc kế dưới 3 trục, thì:

[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 các thiết bị triển khai Automotive có con quay hồi chuyển, thì:

[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 nhất 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] RẤT NÊN định cấu hình phạm vi đo của con quay hồi chuyển thành +/-250 dps để tối đa hoá độ phân giải có thể.

Nếu các chế độ triển khai thiết bị ô tô có con quay hồi chuyển 3 trục, thì:

[7.3.4/A-SR-2] RẤT NÊN triển khai cảm biến kết hợp cho con quay hồi chuyển có số trục hạn chế.

Nếu các chế độ triển khai thiết bị trên ô tô có con quay hồi chuyển dưới 3 trục, thì:

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

[7.3.3/A-3-1] PHẢI xác định vị trí vào lần đầu tiên bộ nhận GPS/GNSS được bật 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 tiêu chí về thời gian xác định vị trí lần đầu tiên như mô tả trong 7.3.3/C-1-2 và 7.3.3/C-1-6 cho tất cả các yêu cầu khác về vị trí (tức là những 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ó khả năng kết nối dữ liệu dựa trên mạng di động, bằng cách sử dụng các dự đoán quỹ đạo GNSS được tính toán trên máy thu hoặc sử dụng vị trí đã biết gần đây nhất của xe cùng với khả năng ước tính vị trí trong ít nhất 60 giây với độ chính xác về 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ị trên ô tô có cảm biến TYPE_HEADING, thì:

[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 nhất là 1 Hz.
[7.3.4/A-SR-3] RẤT NÊN báo cáo các sự kiện với tần suất ít nhất là 10 Hz.
SHOULD be in reference to true north.
PHẢI có sẵn ngay cả khi xe đang đứng yên.
NÊN có độ phân giải ít nhất là 1 độ.

Triển khai thiết bị trên ô 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] Các hoạt động triển khai Android Automotive PHẢI hỗ trợ các cấu hình 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 (A2 DP).
- Điều khiển chế độ phát nội dung nghe nhìn thông 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] NÊN HỖ TRỢ Cấu hình truy cập tin nhắn (MAP) nếu thiết bị có vùng người lái.

[7.4.3/A-1-1] PHẢI độc lập và KHÔNG được gây trở ngại cho trải nghiệm BT của người dùng khác.

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

[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ố System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID cho những mạng mà các ứng dụng hệ thống cần có.

Nếu các phương thức triển khai thiết bị có hỗ trợ đài phát AM/FM và cung cấp chức năng này cho mọi ứng dụng, thì các phương thức triển khai đó sẽ:

[7.4/A-1-1] PHẢI khai báo việc hỗ trợ FEATURE_BROADCAST_RADIO.

Camera sau là camera 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 cabin xe; tức là camera này chụp ảnh các cảnh ở phía xa của thân xe, chẳng hạn như camera chiếu hậu.

Camera trước là camera hướng về phía người dùng, có thể được đặt ở bất kỳ vị trí nào trên xe và hướng vào bên trong cabin xe; tức là camera này 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ự.

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

[7.5/A-SR-1] BẠN NÊN CÓ MỘT HOẶC NHIỀU camera hướng ra thế giới bên ngoài.
CÓ THỂ bao gồm một hoặc nhiều camera quay về phía người dùng.
[7.5/A-SR-2] RẤT NÊN hỗ trợ phát trực tiếp đồng thời từ nhiều camera.

Nếu các hoạt động triển khai thiết bị trên ô tô có ít nhất một camera hướng ra thế giới bên ngoài, thì đối với camera đó, các hoạt động triển khai này sẽ:

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

Nếu các chế độ triển khai thiết bị trên ô tô có ít nhất một camera hướng về người dùng, thì đối với camera đó:

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

Nếu các chế độ triển khai thiết bị ô tô có một camera có thể truy cập thông qua API android.hardware.Camera hoặc android.hardware.camera2, thì các chế độ triển khai đó:

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

Nếu các hoạt động triển khai thiết bị Automotive có một camera không thể truy cập thông qua API android.hardware.Camera hoặc android.hardware.camera2, thì các hoạt động triển khai đó:

[7.5/A-4-1] PHẢI có thể truy cập thông qua dịch vụ Extended View System.

Nếu các chế độ triển khai thiết bị ô tô có một hoặc nhiều camera có thể truy cập thông qua Dịch vụ hệ thống chế độ xem mở rộng, thì đối với camera đó, các chế độ triển khai này sẽ:

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

Nếu các chế độ triển khai thiết bị trên ô tô có một hoặc nhiều camera có thể truy cập thông qua cả Extended View System Service và API android.hardware.Camera hoặc android.hardware.Camera2, thì đối với camera như vậy, các chế độ triển khai này sẽ:

[7.5/A-6-1] PHẢI báo cáo cùng một Mã nhận dạng camera.

Nếu các hoạt động triển khai thiết bị Automotive cung cấp một API camera độc quyền, thì:

[7.5/A-7-1] PHẢI triển khai API camera như vậy bằng API android.hardware.camera2 hoặc Extended View System API.

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

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

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

[7.6.1/A-SR-1] RẤT NÊN dùng để giảm mức hao tổn I/O đối với 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.

[7.6.1/A-1-1] PHẢI có ít nhất 4 GB bộ nhớ không biến động cho mỗi người dùng Android đồng thời trên một phiên bản AAOS (phân vùng /data).

Nếu các phương thức triển khai thiết bị ô tô là 64 bit:

[7.6.1/A-2-1] Bộ nhớ mà nhân và không gian người dùng có thể truy cập PHẢI có dung lượng tối thiểu là 816 MB cho mỗi màn hình chính nếu dùng bất kỳ mật độ nào sau đây:
- 280 dpi trở xuống trên màn hình nhỏ/bình thường
- ldpi hoặc thấp hơn trên màn hình cực lớn
- mdpi hoặc thấp hơn trên màn hình lớn
[7.6.1/A-2-2] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI ít nhất là 944 MB cho mỗi màn hình chính 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ỏ/màn hì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] Bộ nhớ mà nhân và không gian người dùng có thể truy cập PHẢI có dung lượng tối thiểu là 1280 MB cho mỗi màn hình chính nếu dùng bất kỳ mật độ nào sau đây:
- 400 dpi trở lên trên màn hình nhỏ/màn hì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] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI ít nhất là 1824 MB cho mỗi màn hình chính nếu bạn sử dụng bất kỳ mật độ nào sau đây:
- 560 dpi trở lên trên màn hình nhỏ/màn hình thường
- 400 dpi 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ị trên ô tô:

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

Nếu các chế độ triển khai thiết bị Ô tô có một cổng USB với bộ điều khiển hoạt động ở chế độ thiết bị ngoại vi, thì các chế độ triển khai đó:

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

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

[7.7.2/A-1-1] PHẢI triển khai lớp âm thanh USB như mô tả trong tài liệu SDK Android.

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

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

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

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

[7.8.2/A-1-1] PHẢI có thiết bị đầu ra âm thanh cho mỗi màn hình chính đối với các hệ thống nhiều người dùng đồng thời.
[7.8.2/A-1-2] PHẢI có một vùng âm thanh của Người lái xe bao gồm loa cabin toàn cầu. Khu vực dành cho hành khách phía trước có thể dùng chung khu vực âm thanh với người lái xe hoặc có đầu ra âm thanh riêng.

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

[7.8.2.2/A-1-1] 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 đầu cuối âm thanh USB là 0x0302.
[7.8.2.2/A-1-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 đầu cuối âm thanh USB là 0x0402.
[7.8.2.2/A-1-3] 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 đầu cuối âm thanh USB là 0x0603.
[7.8.2.2/A-1-4] 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 đầu cuối âm thanh USB là 0x0400.

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

[5.1/A-0-1] Cấu hình AAC MPEG-4 (AAC LC)
[5.1/A-0-2] Cấu hình HE AAC MPEG-4 (AAC+)
[5.1/A-0-3] AAC ELD (AAC có độ trễ thấp nâng cao)

[5.1/A-0-4] MPEG-D USAC có MPEG-D DRC (AAC có hiệu suất cao mở rộng)

Việc 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 này 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ị trên ô 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 này 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 hỗ trợ quá trình giải mã video sau đây khi triển khai thiết bị ô tô:

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

[5.5.3/A-1-1] PHẢI xác định các đường cong âm lượng giống hệt nhau cho tất cả các luồng đầu ra âm thanh ánh xạ đến cùng một nhóm âm lượng như được xác định trong tệp cấu hình âm thanh trên ô tô.

2.5.3. Phần mềm

Triển khai thiết bị trên ô 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ả các API công khai trong không gian tên android.car.*.

Nếu các hoạt động 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ì:

[3/A-1-1] KHÔNG ĐƯỢC gắn các đặc quyền đặc biệt cho 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 các ứ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 một thuộc tính của xe đã có trong SDK.

Triển khai thiết bị trên ô 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 theo tài liệu của trang tham chiếu Quyền cho ô tô.
[3.2.3.1/A-0-1] PHẢI tải sẵn một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng một 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.2.3.1/A-0-2] Ứng dụng PHẢI 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 trình cung cấp tài liệu bằng cách sử dụng API DocumentsProvider.

Nếu ứng dụng cài đặt của quá trình triển khai thiết bị ô tô triển khai chức năng chia tách, bằng cách sử dụng tính năng nhúng hoạt động, thì ứng dụng này sẽ:

[3.2.3.1/A-1-1] PHẢI có một hoạt động xử lý ý định Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY khi bật chức năng chia đôi. Hoạt động này 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.
[3.4.1/A-0-1] PHẢI cung cấp một chế độ triển khai hoàn chỉnh của API android.webkit.Webview.

[3.8/A-1-1] PHẢI triển khai danh sách UserRestrictions được xác định trước sau đây cho người dùng phụ đầy đủ không phải là người dùng hiện tại ở nền trước, nhưng có quyền truy cập vào giao diện người dùng của màn hình được chỉ định cho họ. Danh sách UserRestrictions là DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE và DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] KHÔNG ĐƯỢC cho phép người dùng phụ có đầy đủ quyền truy cập (không phải là người dùng hiện tại ở nền trước nhưng có quyền truy cập vào giao diện người dùng của màn hình được chỉ định cho họ) thay đổi chế độ ngày/đêm, ngôn ngữ, ngày, giờ, múi giờ hoặc các tính năng màu sắc hiển thị (bao gồm cả Độ sáng, Ánh sáng đêm, thang độ xám của Digital Wellbeing và Giảm màu sáng) cho bất kỳ người dùng nào khác thông qua phần Cài đặt hoặc từ một API.

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

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

Nếu các thiết bị triển khai trên ô tô có nút nhấn để nói, thì:

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

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

[3.8.3.1/A-0-1] PHẢI hiển thị chính xác các tài nguyên như mô tả trong tài liệu về SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] PHẢI hiển thị nút PHÁT và TẮT TIẾNG cho các thao tác trên thông báo thay vì các thao tác đượ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ư chế độ kiểm soát theo từng kênh thông báo. CÓ THỂ sử dụng thành phần tương tác trên giao diện người dùng cho mỗi ứng dụng để giảm số lượng chế độ kiểm soát.

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

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

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

[3.14/A-0-1] PHẢI có 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 an toàn với các Ứng dụng đa phương tiện khi lái xe.
[3.14/A-0-3] PHẢI hỗ trợ thao tác theo ý định ngầm CAR_INTENT_ACTION_MEDIA_TEMPLATE bằng phần bổ sung CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] PHẢI cung cấp một cơ chế để chuyển đến hoạt động về lựa chọn ưu tiên của Ứng dụng đa phương tiện, nhưng CHỈ ĐƯỢC PHÉP bật cơ chế này khi các quy định hạn chế về Giao diện 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 Các ứng dụng đa phương tiện đặt và PHẢI hỗ trợ các phần 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ợ một thành phần tìm kiếm trong ứng dụng cho những ứng dụng hỗ trợ tính năng tìm kiếm.
[3.14/A-0-7] PHẢI tuân thủ các định nghĩa CONTENT_STYLE_BROWSABLE_HINT và CONTENT_STYLE_PLAYABLE_HINT khi hiển thị hệ phân cấp MediaBrowser.

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

[3.14/A-0-8] PHẢI khai báo cờ tính năng android.software.car.templates_host.
[3.14/A-0-9] PHẢI khai báo cờ tính năng com.android.car.background_audio_while_driving.
[3.14/A-0-10] PHẢI khai báo cờ tính năng android.software.car.templates_host.media.

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

[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ị trên ô 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 phía sau các phần tử giao diện người dùng hệ thống để đảm bảo các phần tử đó luôn hiển thị rõ ràng.

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

[7.1.1/A-0-1] PHẢI khai báo cờ tính năng android.software.car.display_compatibility.

Trong khi chạy các ứng dụng ở nền trước bằng tính năng android.software.car.display_compatibility hoặc các ứng dụng không có tính năng android.hardware.type.automotive, các thiết bị ô tô:

[7.1.1/A-1-1] PHẢI cung cấp chức năng Quay lại.

Nếu các hoạt động triển khai thiết bị Automotive cho phép người dùng thực hiện cuộc gọi thuộc mọi loại, thì:

[7.4.1.2/A-1-1] PHẢI khai báo cờ tính năng android.software.telecom.

[7.4.1.2/A-1-2] PHẢI triển khai khung viễn thông.

2.5.4. Hiệu suất và sức mạnh

[8.1/A-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 trong một giây và NÊN dưới 1 khung hình trong một giây.
[8.1/A-0-2] Độ trễ giao diện người dùng. Các hoạt động 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 quy định của Bộ kiểm tra tính tương thích (CTS) của Android trong vòng chưa đầy 36 giây.
[8.1/A-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ị trên ô 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 biến động theo UID của mỗi quy trình để nhà phát triển có thể truy cập vào 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.2/A-0-2] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 5 MB/giây.
[8.2/A-0-3] 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/A-0-4] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 15 MB/giây.
[8.2/A-0-5] 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 các phương thức triển khai thiết bị trên ô tô trả về android.os.Build.VERSION_CODES.U trở lên cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, thì các phương thức này:

[8.2/A-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/A-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/A-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/A-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/A-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.
[8.3/A-1-3] PHẢI hỗ trợ Chế độ nhà để xe.
[8.3/A] PHẢI ở Chế độ nhà để xe í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.
- Người lái xe thoát khỏi Chế độ nhà để xe.
[8.4/A-0-1] PHẢI cung cấp một hồ sơ năng lượng cho từng thành phần, xác định giá trị mức tiêu thụ hiện tại cho từng thành phần phần cứng và mức tiêu hao pin ước tính do các thành phần gây ra theo thời gian như được ghi lại trong trang web Dự án nguồn mở Android.
[8.4/A-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng theo đơn vị miliampe giờ (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 này thông qua việc triển khai mô-đun hạt nhân uid_cputime.
[8.4/A] PHẢI được quy cho chính thành phần phần cứng nếu không thể quy mức tiêu thụ điện 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 tiêu thụ điện này thông qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.

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

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

[9.5/A-1-1] KHÔNG ĐƯỢC 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, ngoại trừ cấp phé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ợ khả 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ị.

Nếu các hoạt động triển khai thiết bị ô tô hỗ trợ System API 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 micrô và/hoặc camera, thì:

[9.8/A-1-1] PHẢI đảm bảo dịch vụ phát hiện cụm từ tìm kiếm chỉ có thể truyền dữ liệu đến Hệ thống, ContentCaptureService hoặc dịch vụ nhận dạng giọng nói trên thiết bị (do SpeechRecognizer#createOnDeviceSpeechRecognizer() tạo).
[9.8/A-1-2] KHÔNG ĐƯỢC 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 giọng nói trên thiết bị.
[9.8/A-1-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 thấy ý định của người dùng tương tác với Ứng dụng Trợ lý kỹ thuật số (chẳng hạn như bằng cách phát hiện sự hiện diện của người dùng thông qua camera).
[9.8/A-1-4] PHẢI hiển thị chỉ báo micrô và hiển thị cụm từ tìm kiếm đã phát hiện của người dùng trong giao diện người dùng ngay sau khi phát hiện được cụm từ tìm kiếm của người dùng.
[9.8/A-1-5] KHÔNG ĐƯỢC phép ứng dụng có thể cài đặt do người dùng cung cấp dịch vụ phát hiện truy vấn trực quan.

Nếu các chế độ triển khai thiết bị Ô tô khai báo android.hardware.microphone, thì:

[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 hiển thị khi micrô chỉ được truy cập bởi HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng có vai trò được nêu trong mục 9.1 có mã nhận dạng CDD [C-4-X].
[9.8.2/A-1-2] KHÔNG ĐƯỢC ẩn chỉ báo micrô đố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.
[9.8.2/A-1-3] PHẢI cung cấp cho người dùng một cách thức để bật/tắt micrô trong ứng dụng Cài đặt.

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

[9.8.2/A-2-1] PHẢI hiển thị chỉ báo camera khi một ứng dụng đang truy cập vào dữ liệu trực tiếp của camera, nhưng không hiển thị khi camera chỉ được(các) ứng dụng giữ vai trò như được xác định trong Mục 9.1 Quyền truy cập bằng mã nhận dạng CDD [C-4-X].
[9.8.2/A-2-2] KHÔNG ĐƯỢC ẩn chỉ báo camera đố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.
[9.8.2/A-2-3] PHẢI cung cấp cho người dùng một cách thức để bật/tắt camera 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 camera như được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi nhận quyền sở hữu liên quan đến các ứng dụng đó.

Triển khai thiết bị trên ô 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 việc 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 có các phương thức triển khai thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm MD5, SHA-1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hệ thống Kho khoá Android hỗ trợ trong một khu vực được cách ly an toàn với mã đang chạy trên nhân và các phiên bản cao hơn. Tính năng cách ly an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà mã nhân hệ điều hành 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 biệt lập, 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 sử dụng chế độ triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc chế độ triển khai bảo mật đã được bên thứ ba xem xét về khả năng cách ly 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 biệt lập và chỉ khi 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. Thông tin đăng nhập trên 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 biệt lập thực hiện quy trình xác thực trên 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 Gatekeeper (HAL) và Trusty. Bạn có thể dùng các lớp này để đáp ứng yêu cầu này.
[9.11/A-0-4] PHẢI hỗ trợ quy trình 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à quy trình ký được thực hiện trong phần cứng bảo mật. Bạn KHÔNG ĐƯỢC phép sử dụng khoá ký chứng thực làm giá trị nhận dạng thiết bị vĩnh viễn.

Lưu ý: Để đáp ứng yêu cầu này, bạn phải chia sẻ cùng một khoá chứng thực cho một SKU nhất định,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của SKU đó. Nếu có hơn 100.000 đơn vị của SKU đó được sản xuất, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, bạn có thể sử dụng giải pháp Cung cấp khoá từ xa để cung cấp các khoá chứng thực có thời hạn ngắn cho thiết bị.

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

[9.14/A-0-1] PHẢI kiểm soát các thông báo từ các hệ thống con của khung Android trên xe (ví dụ: 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 để chống lại các cuộc tấn công từ chối dịch vụ từ khung Android hoặc các ứng dụng bên thứ ba. Điều này giúp ngăn chặn phần mềm độc hại làm ngập mạng lưới xe bằng lưu lượng truy cập, có thể dẫn đến các hệ thống con của xe bị trục trặc.

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

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

Perfetto
- [6.1/A-0-1] PHẢI hiển thị một tệp nhị phân /system/bin/perfetto cho người dùng shell mà dòng lệnh tuân thủ tài liệu perfetto.
- [6.1/A-0-2] Tệp nhị phân perfetto PHẢI chấp nhận một cấu hình protobuf làm dữ liệu đầu vào tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [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.
- [6.1/A-0-5] Trình nền được theo dõi của Perfetto PHẢI được bật theo mặc định (thuộc tính hệ thống persist.traced.enable).

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 là một cách triển khai thiết bị Android thường đáp ứng tất cả các tiêu chí sau:

Được sử dụng bằng cách cầm bằng cả hai tay.
Không có cấu hình vỏ sò hoặc có thể chuyển đổi.
Các chế độ triển khai bàn phím thực được dùng với thiết bị kết nối bằng một phương thức kết nối tiêu chuẩn (ví dụ: USB, Bluetooth).
Có nguồn điện giúp di chuyển, chẳng hạn như pin.
Có kích thước màn hình hiển thị 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 trường hợp 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 các hoạt động triển khai thiết bị Máy tính bảng có con quay hồi chuyển 3 trục, thì:

[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 1.000 độ 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 đối với thiết bị cầm tay không áp dụng cho máy tính bảng.

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

Thực tế ảo hiệu suất cao (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 đăng nhập (Mục 9.11)

Tham khảo Mục [9.11].

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

[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 bổ sung 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 hạn chế chi tiết hơn trong những ứng dụng có sẵn trong các môi trường đó.

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

[9.5/T-2-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI phù hợp với cách triển khai các chế độ kiểm soát của AOSP để cho phép /không cho phép người dùng khác truy cập vào cuộc gọi thoại và tin nhắn 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ụ bằng một 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 được cung cấp 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 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 lại, của mọi API được ghi lại do SDK Android hoặc mọi API được trang trí bằng dấu "@SystemApi" trong mã nguồn Android thượng nguồn cung cấp.
[C-0-2] PHẢI hỗ trợ/giữ lại tất cả các lớp, phương thức và phần tử được 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 được quản lý nào, thay đổi giao diện hoặc chữ ký API, đi lệch khỏi hành vi đã ghi lại hoặc không bao gồm các thao tác không hoạt động, trừ phi được phép cụ thể theo Định nghĩa về khả năng tương thích này.
[C-0-4] VẪN PHẢI giữ các API hiện có 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 có 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 các ứ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 các 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ú giải @hide nhưng không có @SystemAPI, như mô tả trong tài liệu SDK và các thành phần lớp riêng tư và chỉ dành cho gói.
[C-0-6] PHẢI đi kèm với từng giao diện không phải SDK trong cùng danh sách bị hạn chế như được cung cấp thông qua các cờ danh sách chặn và tạm thờ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 mọi APK, sử dụng các khoá công khai hiện có trong AOSP.

Tuy nhiên, họ:
- CÓ THỂ, nếu một API ẩn không có hoặc được triển khai 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 bỏ qua API đó khỏi tất cả các danh sách bị hạn chế.
- CÓ THỂ, nếu một API ẩn chưa có trong AOSP, hãy thêm API ẩn đó vào bất kỳ danh sách bị hạn chế nào.

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

3.1.1. Tiện ích Android

Android hỗ trợ việc mở rộng nền tảng 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) sẽ trả về phiên bản tiện ích của apiLevel đã cho, nếu có tiện ích cho cấp độ API đó.

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

[C-0-1] PHẢI tải trước chế độ triển khai AOSP của cả thư viện dùng chung ExtShared và các 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 thiết bị triển khai Android 7.0, chạy cấp độ API 24 PHẢI có í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 trả về theo android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 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 mục 3.1.

3.1.2. Thư viện Android

Do Apache HTTP client không được dùng nữa, nên 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 trong bootclasspath.
[C-0-2] PHẢI thêm thư viện org.apache.http.legacy vào đường dẫn lớp ứng dụng chỉ 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 này 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 API linh hoạt

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

3.2.1. Quyền

[C-0-1] Nhà triển khai thiết bị PHẢI hỗ trợ và thực thi tất cả hằng số quyền theo tài liệu của trang Tham chiếu 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

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

[C-0-1] Để cung cấp các giá trị nhất quán, 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 hạn chế bổ sung về định dạng của những giá trị mà hoạt động triển khai thiết bị PHẢI tuân thủ.

Tham số	Chi tiết
VERSION.RELEASE	Phiên bản của hệ thống Android hiện đang thực thi, ở định dạng dễ đọ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 17.
VERSION.SDK	Phiên bản của hệ thống Android hiện đang thực thi, ở định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập. Đối với Android 17, trường này PHẢI có giá trị số nguyên là 17_INT.
VERSION.SDK&lowbar;INT	Phiên bản của hệ thống Android hiện đang thực thi, ở định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập. Đối với Android 17, trường này PHẢI có giá trị số nguyên 17&lowbar;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 hiện đang thực thi, ở định dạng mà con người có thể đọc được. Bạn KHÔNG ĐƯỢC 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. Một trường hợp sử dụng điển hình của trường này là cho biết số bản dựng hoặc giá trị nhận dạng thay đổi kiểm soát nguồn nào được dùng để tạo bản dựng. Giá trị của trường này PHẢI mã hoá được 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. Một trường hợp có thể sử dụng trường này là để cho biết phiên bản cụ thể của bảng mạch cung cấp năng lượng cho thiết bị. Giá trị của trường này PHẢI mã hoá được 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 đến. 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 mã hoá được dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9_-]+$`.
ABI&lowbar;ĐƯỢC&lowbar;HỖ&lowbar;TRỢ	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 của API gốc.
ABI&lowbar;32&lowbar;BIT&lowbar;ĐƯỢC&lowbar;HỖ&lowbar;TRỢ	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 của API gốc.
ABI&lowbar;64&lowbar;BIT&lowbar;ĐƯỢC&lowbar;HỖ&lowbar;TRỢ	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 của API gốc.
CPU&lowbar;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 của API gốc.
CPU&lowbar;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 của API gốc.
THIẾT BỊ	Giá trị do nhà 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 mã hoá được 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 vòng đời của sản phẩm.
FINGERPRINT	Một chuỗi xác định duy nhất bản dựng này. Nội dung này PHẢI ở dạng mà con người có thể đọc được một cách hợp lý. Bạn PHẢI tuân theo mẫu này: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys Dấu vân tay KHÔNG ĐƯỢC chứa ký tự khoảng trắng. Giá trị của trường này PHẢI mã hoá được dưới dạng ASCII 7 bit.
PHẦN CỨNG	Tên của phần cứng (từ dòng lệnh của nhân hoặc /proc). Nội dung này PHẢI ở dạng mà con người có thể đọc được một cách hợp lý. 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_-]+$`.
HOST	Một chuỗi nhận dạng duy nhất cho máy chủ mà bản dựng được tạo trên đó, ở định dạng mà con người có thể đọ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 có giá trị rỗng hoặc chuỗi trống ("").
ID	Giá trị nhận dạng do nhà 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 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 mã hoá được 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 nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC là giá trị rỗng hoặc chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại của sản phẩm.
SOC&lowbar;MANUFACTURER	Tên thương mại của nhà sản xuất hệ thống chính trên chip (SOC) được 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ị hằng số. Vui lòng yêu cầu nhà sản xuất SOC cung cấp hằng số chính xác để sử dụng. Giá trị của trường này PHẢI mã hoá được 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 khoảng trắng và KHÔNG ĐƯỢC bằng "unknown". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại của sản phẩm.
SOC&lowbar;MODEL	Tên kiểu máy của hệ thống chính trên một chip (SOC) được 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ị hằng số. Vui lòng hỏi nhà sản xuất SOC để biết hằng số chính xác cần sử dụng. Giá trị của trường này PHẢI mã hoá được 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 khoảng trắng và KHÔNG ĐƯỢC bằng "unknown". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại 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. Đây PHẢI là tên 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 nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC là giá trị rỗng hoặc chuỗi trống (""). Bạn KHÔNG NÊN thay đổi trường này trong suốt thời gian tồn tại của sản phẩm.
SẢN PHẨM	Giá trị do nhà 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à nội dung mà con người có thể đọc được, nhưng không nhất thiết phải dành cho người dùng cuối xem. Giá trị của trường này PHẢI mã hoá được 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 vòng đời của sản phẩm.
ODM&lowbar;SKU	Giá trị không bắt buộc do người triển khai thiết bị chọn, chứa SKU (Đơ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 mã hoá được dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^([0-9A-Za-z.,_-]+)$`.
SERIAL	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 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: release-keys, dev-keys và test-keys.
THỜI GIAN	Giá trị biểu thị dấu thời gian của thời điểm bản dựng xảy ra.
LOẠ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 điển hình: 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 là giá trị rỗng hoặc chuỗi trống ("").
SECURITY&lowbar;PATCH	Giá trị cho biết cấp bản vá bảo mật của bản dựng. Bạn 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 cho thiết bị Android được chỉ định. Giá trị này PHẢI ở định dạng [YYYY-MM-DD], khớp với một chuỗi được xác định trong Bản tin công khai về bảo mật Android hoặc trong Thông báo về bảo mật Android, ví dụ: "2015-11-01".
BASE&lowbar;OS	Một giá trị đại diện cho tham số FINGERPRINT của bản dựng. Bản dựng này giống hệt bản dựng khác, 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. Nó PHẢI báo cáo giá trị chính xác và nếu bản dựng đó không tồn tại, 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 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 mã hoá được 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 đài/modem nội bộ cụ thể được dùng trong thiết bị, ở định dạng đọc được. Nếu thiết bị không có đài/modem nội bộ, thì thiết bị ĐƯỢC PHÉP 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ề) một số sê-ri phần cứng, PHẢI có sẵn và là duy nhất trên các thiết bị có cùng MODEL và MANUFACTURER. Giá trị của trường này PHẢI mã hoá được dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9]+$`.
STRONGBOX&lowbar;MANUFACTURER	Tên thương mại của nhà sản xuất chip StrongBox được dùng trong sản phẩm. Nhà cung cấp StrongBox cung cấp hằng số chính xác. Các thiết bị có cùng nhà cung cấp StrongBox phải sử dụng cùng một giá trị hằng số. Giá trị của trường này PHẢI khớp với biểu thức chính quy `^([0-9A-Za-z ]+)` và KHÔNG ĐƯỢC bằng "unsupported". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại của sản phẩm.
STRONGBOX&lowbar;MODEL	Tên mẫu của chip StrongBox được dùng trong sản phẩm. Nhà cung cấp StrongBox cung cấp hằng số chính xác. Các thiết bị có cùng nhà cung cấp StrongBox PHẢI sử dụng cùng một giá trị hằng số. Giá trị của trường này PHẢI khớp với biểu thức chính quy `^([0-9A-Za-z ._/+-]+)$` và KHÔNG ĐƯỢC bằng "unsupported". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại của sản phẩm.

3.2.3. Khả năng tương thích về ý định

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

Ý định của 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 khác của Android. Dự án nguồn mở Android có một 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 thiết bị:

[C-SR-1] NÊN RẤT MẠNH MẼ 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 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 những ý đị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 bắt buộc của ứng dụng 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 các hoạt động 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, chế độ triển khai nguồn mở Android ngược dòng cho phép điều này.
[C-0-2] Nhà triển khai thiết bị KHÔNG ĐƯỢC gắn các đặc quyền đặc biệt cho 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à kiểm soát các mẫu này. Quy định cấm này đặc biệt bao gồm nhưng không giới hạn ở việc vô hiệu hoá giao diện người dùng "Chooser" (Trình chọn) cho phép người dùng chọn giữa nhiều ứng dụng xử lý cùng một mẫu ý định.
[C-0-3] Các hoạt động 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 các ý định.
Tuy nhiên, các hoạt động 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 có một cơ chế để các ứng dụng bên thứ ba khai báo một 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 trên web. Khi các khai báo có thẩm quyền như vậy được xác định trong các 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 quy cách Digital Asset Links (Đườ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 thượng nguồn.
[C-0-5] PHẢI cố gắng xác thực các bộ lọc ý định trong quá trình cài đặt ứng dụng và đặt tất cả cá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 chúng đượ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 một quy trình triển khai thiết bị thực hiện việc này, thì quy trình đó PHẢI cung cấp cho người dùng các chế độ ghi đè mẫu thích hợp cho mỗi URI trong trình đơn cài đặt.
PHẢI cung cấp cho người dùng chế độ kiểm soát Đường liên kết ứng dụng cho mỗi ứ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 bộ hành vi mặc định của đường liên kết đến ứng dụng để ứng dụng có thể: luôn mở, luôn hỏi hoặc không bao giờ mở, hành vi này phải áp dụng cho tất cả các bộ lọc ý định URI đề xuất một cách bình đẳng.
- [C-0-7] Người dùng PHẢI có thể xem 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 ứng cử viên cụ thể đã được xác minh thành công, trên cơ sở từng bộ lọc ý định.
- [C-0-8] Việc triển khai thiết bị PHẢI cho phép người dùng xem và ghi đè các bộ lọc ý định URI ứng cử viên cụ thể nếu việc triển khai thiết bị cho phép một số bộ lọc ý định URI ứng cử viên vượt qua quy trình xác minh trong khi một số bộ lọc khác có thể không vượt qua được.

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

[C-0-1] Các hoạt động triển khai thiết bị KHÔNG ĐƯỢC chứa bất kỳ thành phần Android nào tuân theo bất kỳ mẫu ý đị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 tên android.* hoặc com.android.*.
[C-0-2] Nhà triển khai thiết bị KHÔNG ĐƯỢC đưa bất kỳ thành phần Android nào tuân theo ý đị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 một không gian gói thuộc về một tổ chức khác.
[C-0-3] Nhà triển khai thiết bị KHÔNG ĐƯỢC sửa đổ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.
Các hoạt động triển khai thiết bị CÓ THỂ bao gồm các mẫu ý định bằng cách sử dụng không gian tên được liên kết rõ ràng và hiển nhiên với tổ chức của riêng chúng. Lệnh cấm này tương tự như lệnh cấm đượ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 này để truyền 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 thiết bị:

[C-0-1] PHẢI truyền 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 mâu thuẫn 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 phụ thuộc vào sự hỗ trợ của phần cứng. Nếu thiết bị hỗ trợ phần cứng cần thiết, thì thiết bị 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ó điều kiện của ứng dụng

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.

Nếu có thể, các hoạt động 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 cũng như các phương thức API được mô tả trong tài liệu SDK như bên dưới.

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

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

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

[C-2-1] PHẢI cung cấp một trình đơn cài đặt sẽ gọi ý định android.provider.Telephony.ACTION_CHANGE_DEFAULT để hiện một hộp thoại thay đổi ứng dụng SMS mặc định.
[C-2-2] PHẢI tuân theo ý định android.telecom.action.CHANGE_DEFAULT_DIALER để hiện một 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à gọi đi, ngoại trừ cuộc gọi khẩn cấp. Cuộc gọi khẩn cấp sẽ sử dụng ứng dụng Điện thoại được cài đặt 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 thành phần để định cấu hình ConnectionServices được 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ẽ 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 đối với ứ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ủ các ý định android.intent.action.SENDTO và android.intent.action.VIEW, đồng thời cung cấp một hoạt động để gửi/hiển thị tin nhắn SMS.
[C-SR-1] RẤT NÊN tuân thủ android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW và android.intent.action.DIAL với một ứng dụng quay số được tải sẵn có thể xử lý các ý định này và cung cấp dịch vụ như mô tả trong SDK.

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

[C-3-1] PHẢI tuân theo ý định android.settings.NFC_PAYMENT_SETTINGS để hiện một 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 theo ý định android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT để hiện 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 các hoạt động triển khai thiết bị báo cáo android.hardware.nfc, thì:

[C-4-1] PHẢI tuân thủ các ý định này android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED và android.nfc.action.TECH_DISCOVERED, để hiện 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 các hoạt động triển khai thiết bị báo cáo android.hardware.bluetooth, thì:

[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 các hoạt động triển khai thiết bị hỗ trợ tính năng DND, thì:

[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 có UI_MODE_TYPE_NORMAL, đây 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ác cấu hình chính sách DND.

Nếu các chế độ 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ì:

[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 phương thức nhập của bên thứ ba để phản hồi ý định android.settings.INPUT_METHOD_SETTINGS.

Nếu các hoạt động triển khai thiết bị hỗ trợ dịch vụ trợ năng của bên thứ ba, thì các hoạt động này sẽ:

[C-8-1] PHẢI tuân thủ ý định android.settings.ACCESSIBILITY_SETTINGS để cung cấp một cơ chế mà người dùng có thể truy cập để 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 sẵn.

Nếu các hoạt động triển khai thiết bị có hỗ trợ Wi-Fi Easy Connect và cung cấp chức năng cho các ứng dụng bên thứ ba, thì các hoạt động này:

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

Nếu triển khai chế độ trình tiết kiệm dữ liệu, thì các thiết bị sẽ:

[C-10-1] PHẢI cung cấp một giao diện người dùng trong phần cài đặt, giao diện này 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 các hoạt động triển khai thiết bị không cung cấp chế độ trình tiết kiệm dữ liệu, thì:

[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 ý định này dưới dạng một thao tác không có hiệu lực.

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

[C-12-3] PHẢI xử lý và CHỈ CHO PHÉP các ứng dụng Android được cài đặt sẵn xử lý các ý định sau 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 các hoạt động triển khai thiết bị báo cáo android.software.device_admin, thì:

[C-13-1] PHẢI tuân thủ ý định android.app.action.ADD_DEVICE_ADMIN để gọi một giao diện người dùng nhằm hướng dẫn người dùng 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 các hoạt động triển khai thiết bị khai báo cờ tính năng android.software.autofill, thì các hoạt động này sẽ:

[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 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 các hoạt động 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 hoạt động triển khai đó:

[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 dữ liệu sử dụng nhằm phản hồi ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS cho những ứng dụng khai báo quyền android.permission.PACKAGE_USAGE_STATS.

Nếu các hoạt động triển khai thiết bị dự định không cho phép bất kỳ ứng dụng nào (kể cả ứng dụng được cài đặt sẵn) truy cập vào số liệu thống kê về mức sử dụng, thì:

[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 một thao tác không có hiệu lực, 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 các 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 người dùng thông qua một cơ chế tương tự, thì các hoạt động triển khai đó:

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

Nếu các hoạt động 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-18-1] PHẢI tuân thủ ý định android.settings.ACTION_VOICE_INPUT_SETTINGS để hiện trình đơn cài đặt ứng dụng mặc định cho tính năng nhập bằng giọng nói và trợ lý.

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

[C-SR-3] RẤT NÊN tuân thủ android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA và android.speech.tts.engine.GET_SAMPLE_TEXT. Các ý định này có một hoạt động để cung cấp thông tin 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 được gọi là Chế độ hiển thị. 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 một 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 thiết bị:

NÊN hỗ trợ trình bảo vệ màn hình và cung cấp một lựa chọn cài đặt để người dùng định cấu hình trình bảo vệ màn hình để phản hồi ý định android.settings.DREAM_SETTINGS.

Nếu các hoạt động triển khai thiết bị báo cáo android.hardware.nfc.uicc hoặc android.hardware.nfc.ese, thì:

[C-19-1] PHẢI triển khai API Intent NfcAdapter.ACTION_TRANSACTION_DETECTED (dưới dạng "EVT_TRANSACTION" do GSM Association technical specification TS.26 – NFC Handset Requirements (Yêu cầu 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 có NFC) xác định).

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

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

[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 API tương tự như một hoạt động đang chạy trên màn hình chính.
[C-1-3] PHẢI đặt hoạt động mới trê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ỷ tất cả các hoạt động khi một màn hình có cờ Display.FLAG_PRIVATE bị xoá.
[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ị bị khoá bằng màn hình khoá bảo mật, trừ phi ứng dụng chọn hiển thị trên màn hình khoá bằng cách sử dụng API Activity#setShowWhenLocked().
PHẢI 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 các phương thứ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ể khởi chạy màn hình đó. Mọi người đều có thể khởi chạy trên một màn hình có cờ android.view.Display.FLAG_PUBLIC.

3.3. Khả năng tương thích của API gốc

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

[C-SR-1] BẠN NÊN SỬ DỤNG các phương thức triển khai của các thư viện được liệt kê bên dưới từ Dự án nguồn mở Android thượng nguồn.

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ó trong tệp .apk của ứng dụng dưới dạng tệp ELF .so đượ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 rất nhiều vào công nghệ bộ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân của ứng dụng (ABI) trong Android NDK.

Triển khai thiết bị:

[C-0-1] PHẢI tương thích với một hoặc nhiều ABI (Giao diện nhị phân ứng dụng) 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 tiêu chuẩn của Giao diện gốc Java (JNI).
[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 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 (ABI) gốc 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, sắp xếp từ ABI được ưu tiên nhất đến ít được ưu tiên nhất.
[C-0-6] PHẢI báo cáo (thông qua các tham số nêu trên) một nhóm nhỏ 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 (NDK không còn hỗ trợ làm mục tiêu)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[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 những ứng dụng có chứa 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 quyền sở hữu 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ý trên Android)
- libmediandk.so (hỗ trợ API đa phương tiệ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 cung cấp trực tiếp cho các ứ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 dành riêng.
[C-0-11] PHẢI xuất tất cả các biểu tượng hàm OpenGL ES 3.1 và Android Extension Pack (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 biểu tượng này ĐỀU PHẢI xuất hiện, nhưng phần 7.1.4.1 mô tả chi tiết hơn các yêu cầu về thời điểm dự kiến triển khai đầy đủ từng chức năng tương ứng.
[C-0-12] PHẢI xuất các ký hiệu hàm cho các ký hiệu hàm 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 biểu tượng PHẢI xuất hiện, mục 7.1.4.2 mô tả chi tiết hơn các yêu cầu về thời điểm dự kiến triển khai đầy đủ từng chức năng tương ứng.
CẦN được tạo bằng mã nguồn và tệp tiêu đề có trong Dự án nguồn mở Android ở nguồn trên.

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 của 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-3-1] CŨNG PHẢI hỗ trợ armeabi-v7a và báo cáo khả năng hỗ trợ của armeabi-v7a, vì armeabi chỉ dành cho khả năng tương thích ngược với các ứng dụng cũ.

Nếu các hoạt động 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 có các dòng sau trong /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 giá trị đó được đọc bởi các ABI khác.
- Features:, theo sau là danh sách mọi 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ả kiến trúc ARM được hỗ trợ cao nhất của thiết bị (ví dụ: "8" cho 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 hoạt động mô phỏng phần mềm:
- Các chỉ thị SWP và SWPB.
- Các hoạt động của 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 của WebView

Nếu các hoạt động triển khai thiết bị cung cấp một hoạt động triển khai hoàn chỉnh của API android.webkit.Webview, thì các hoạt động này sẽ:

[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 17 để 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 cho các ứng dụng nhắm đến SDK cấp 35 trở xuống PHẢI có định dạng 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ì PHẢI có cùng giá trị với android.os.Build.MODEL.
- Bạn CÓ THỂ bỏ qua "Build/$(BUILD)", nhưng nếu có thì 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 ở nguồn trên.
- Các thiết bị triển khai CÓ THỂ bỏ qua Thiết bị di động trong chuỗi tác nhân người dùng.
Thành phần WebView CẦN 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ì CẦN 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 riêng biệt với ứng dụng tạo thực thể 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 tối thiểu cần thiết thông qua Binder. Việc triển khai WebView trên AOSP đáp ứng yêu cầu này.

[C-1-5] Chuỗi tác nhân người dùng mặc định của hệ thống do WebView báo cáo cho các ứng dụng nhắm đến SDK cấp 36 trở lên PHẢI có định dạng sau:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) PHẢI là giá trị tĩnh 10.
- $(MODEL) PHẢI là chữ cái tĩnh K.
- $(CHROMIUM_MAJOR_VER) PHẢI là phiên bản lớn của Chromium trong Dự án nguồn mở Android ở nguồn trên.
- Các thiết bị triển khai CÓ THỂ bỏ qua Thiết bị di động trong chuỗi tác nhân người dùng.

Xin lưu ý rằng nếu các hoạt động 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 hoạt động này sẽ được miễn trừ C-1-3.

3.4.2. Khả năng tương thích của trình duyệt

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

[C-1-1] PHẢI hỗ trợ từng API trong số này được 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 đang chuyển sang ưu tiên IndexedDB hơn 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 sau này.
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 hỗ trợ càng nhiều HTML5 càng tốt trên ứng dụng Trình duyệt độc lập (cho dù dựa trên ứng dụng Trình duyệt WebKit nguồn hay một ứng dụng thay thế của bên thứ ba).

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

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

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

Triển khai 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 đưa vào danh sách cho phép để đảm bảo khả năng tương thích về hành vi của API chỉ dành cho những ứng dụng do 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 ở nguồn trên. Một số khía cạnh cụ thể về khả năng tương thích là:

[C-0-1] Các thiết bị KHÔNG ĐƯỢC thay đổi hành vi hoặc ngữ nghĩa của một ý định tiêu 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.
Các thiết bị KHÔNG ĐƯỢC PHÉP thay đổi các giới hạn được thực thi trên các ứng dụng chạy ở chế độ nền. Cụ thể hơn, đối với các ứng dụng chạy ở chế độ nền:
- [C-0-4] chúng PHẢI dừ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] họ PHẢI giới hạn tần suất 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 cấp độ API mục tiêu 25 trở lên, thì ứng dụng KHÔNG ĐƯỢC phép đăng ký bộ nhận tín hiệu truyền tin cho các thông báo truyền phát ngầm của ý định Android tiêu chuẩn trong tệp kê khai của ứng dụng, trừ phi ý định truyền phát yêu cầu quyền "signature" hoặc "signatureOrSystem" protectionLevel hoặc nằm trong danh sách miễn trừ.
- [C-0-7] nếu ứng dụng nhắm đến cấp độ API mục tiêu 25 trở lên, thì ứng dụng ĐƯỢC YÊU CẦU phải dừng các dịch vụ nền của ứng dụng, giống như thể ứng dụng đã gọi phương thức stopSelf() của 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 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 ĐƯỢC PHÉP giải phóng các wakelock mà ứng dụng giữ.
[C-0-11] Thiết bị PHẢI trả về 7 giá trị mảng đầu tiên sau đây từ phương thức Security.getProviders(), theo thứ tự và 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(). Các 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 các phần quan trọng của nền tảng để đảm bảo khả năng tương thích về hành vi, nhưng không phải tất cả. Người 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, các đơn vị 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 các hoạt động triển khai thiết bị triển khai một cơ chế thuộc quyền sở hữu riêng để 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 hoạt động triển khai đó:

[C-1-1] PHẢI cho phép người dùng xem danh sách các ứng dụng bị hạn chế.
[C-1-2] PHẢI cung cấp cho người dùng khả năng bật / tắt tất cả các hạn chế thuộc quyền sở hữu riêng này trên mỗi ứng dụng.
[C-1-3] KHÔNG ĐƯỢC tự động áp dụng những hạn chế độc quyền này mà không có bằng chứng về hành vi ảnh hưởng đến tình trạng hệ thống, 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 ảnh hưởng đến tình trạng hệ thống, chẳng hạn như wakelock bị kẹt, dịch vụ chạy trong thời gian dài và các tiêu chí khác. Các tiêu chí CÓ THỂ do nhà 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. Bạn 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ư việc ứng dụng không phổ biến trên thị trường.
[C-1-4] KHÔNG ĐƯỢC tự động áp dụng các hạn chế độc quyền này cho ứng dụng khi người dùng đã tắt các hạn chế đối với ứng dụng theo cách thủ công và CÓ THỂ đề xuất người dùng áp dụng các hạn chế độc quyền này.
[C-1-5] PHẢI thông báo cho người dùng nếu những hạn chế độc quyền này được tự động áp dụng cho một ứ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() cho mọi lệnh gọi API từ một ứng dụng.
[C-1-7] KHÔNG ĐƯỢC hạn chế ứng dụng trên nền trước hàng đầu 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 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, khiến ứng dụng đó trở thành ứng dụng hàng đầu ở nền trước.
[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 hạn chế độc quyền. Bạn PHẢI liên kết được tài liệu hoặc trang web này 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.
- Những gì 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 những hạn chế như vậy.
- Cách ứng dụng có thể yêu cầu miễn trừ các hạn chế độc quyền, nếu ứng dụng hỗ trợ việc miễn trừ này 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à chưa bao giờ được người dùng sử dụng rõ ràng trong hơn 30 ngày, thì [C-1-3] và [C-1-5] sẽ được miễn áp dụng.

Nếu các quy trình triển khai thiết bị mở rộng các quy tắc hạn chế đối với ứng dụng được triển khai trong AOSP, thì các quy trình này sẽ:

[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 các hoạt động triển khai thiết bị có 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 hoạt động triển khai đó:

[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] CHỈ ĐƯỢC áp dụng 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 đặt thời hạn này là một tháng hoặc lâu hơn. Cách sử dụng PHẢI được xác định bằng lượt tương tác rõ ràng của người dùng thông qua API UsageStats#getLastTimeVisible() hoặc bất kỳ hoạt động nào khiến ứng dụng rời khỏi trạng thái bị buộc dừng, bao gồm cả các liên kết dịch vụ, liên kết trình cung cấp nội dung, thông báo truyền tin rõ ràng, v.v. API này sẽ được theo dõi bằng một API mới là 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 KHÔNG CÓ người dùng nào sử dụng gói trong một khoảng thời gian nhất định. Bạn NÊN ĐẶC BIỆT cân nhắc thời hạn này là một tháng hoặc lâu hơn.
[C-1-4] KHÔNG ĐƯỢC khiến ứng dụng không thể phản hồi các ý định hoạt động, các liên kết dịch vụ, các yêu cầu của nhà cung cấp nội dung hoặc các thông báo truyền tin rõ ràng.

Tính năng Ngủ đông ứng dụng trong AOSP đáp ứng các yêu cầu nê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, nhà triển khai thiết bị KHÔNG ĐƯỢC phép 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 này:

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

Tức là:

[C-0-1] KHÔNG ĐƯỢC sửa đổi các API được công khai trên nền tảng Android bằng cách thay đổi chữ ký của bất kỳ phương thức hoặc 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 công khai (chẳng hạn như các lớp hoặc giao diện, hoặc cá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. "Phần tử công khai" là bất kỳ cấu trúc nào không được trang trí bằng dấu "@hide" như được dùng trong mã nguồn Android ngược dòng.

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

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

Tuy nhiên, nhà 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 này:

[C-0-5] KHÔNG ĐƯỢC nằm trong một không gian tên thuộc sở hữu của hoặc đề cập đến một tổ chức khác. Ví dụ: nhà 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 rõ ràng các thư viện này (thông qua cơ chế <uses-library>) mới chịu ảnh hưởng của việc tăng mức sử dụng bộ nhớ của các API như vậy.

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

[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 nhà 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ì nhà triển khai NÊN 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ế nêu trên tương ứng với các quy ước tiêu chuẩn để đặt tên API trong ngôn ngữ lập trình Java; phần này chỉ nhằm mục đích củng cố các quy ước đó và ràng buộc chúng 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 trong thời gian chạy

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ đầy đủ định dạng có thể thực thi Dalvik (DEX) và quy cách cũng như 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 nguồn và theo quy định của bảng sau. (Xem mục 7.1.1 để biết định nghĩa về kích thước và mật độ màn hình.)
NÊN sử dụng Android RunTime (ART), quá trình triển khai tham chiếu ở thượng nguồn của Định dạng thực thi Dalvik và hệ thống quản lý gói của quá trình triển khai tham chiếu.
NÊN chạy kiểm thử fuzz trong nhiều chế độ thực thi và kiến 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 trong 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à các hoạt động triển khai thiết bị CÓ THỂ phân bổ thêm bộ nhớ 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
Đồng hồ Android	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)	96MB
	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)	96MB
	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)	96MB
	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)	288MB
	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 có một ứng dụng trình chạy (màn hình chính) và hỗ trợ các ứng dụng của bên thứ ba thay thế trình chạy thiết bị (màn hình chính).

Nếu các hoạt động 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] PHẢI 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 các phương thức triển khai thiết bị có trình chạy mặc định hỗ trợ tính năng ghim lối tắt trong ứng dụng, thì:

[C-2-1] PHẢI báo cáo true cho ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] PHẢI có khả năng tương tác với người dùng để hỏi 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 cũng như lối tắt động và tĩnh như được ghi lại trên trang Lối tắt ứng dụng.

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

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

Nếu các hoạt động 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 ứng dụng bên thứ ba cung cấp thông qua API ShortcutManager, thì các hoạt động triển khai đó:

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

Nếu các hoạt động triển khai thiết bị có 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-5-1] PHẢI tuân thủ phương thức API NotificationChannel.setShowBadge(). Nói cách khác, hãy hiện một dấu hiệu trực quan liên kết với biểu tượng ứng dụng nếu giá trị được đặt là true và không hiện bất kỳ lược đồ 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 đều đặt giá trị là false.
CÓ THỂ ghi đè huy hiệu biểu tượng ứng dụng bằng lược đồ gắn huy hiệu độc quyền của riêng họ khi các ứng dụng bên thứ ba cho biết có hỗ trợ lược đồ gắn huy hiệu độc quyền thông qua việc sử dụng các API độc quyền, nhưng NÊN sử dụng các tài nguyên và giá trị được cung cấp thông qua các 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 các chế độ triển khai thiết bị hỗ trợ biểu tượng đơn sắc, thì những biểu tượng này:

[C-6-1] CHỈ được dùng khi người dùng cho phép một cách rõ ràng (ví dụ: thông qua phầ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 một loại thành phần và API cũng như vòng đời tương ứng cho phép các ứng dụng hiển thị một "AppWidget" cho người dùng cuối.

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

[C-1-1] PHẢI khai báo hỗ trợ cho tính năng nền tảng android.software.app_widgets.
[C-1-2] PHẢI có hỗ trợ tích hợp cho AppWidget và cung cấp các thành phần giao diện người dùng để thêm, định cấu hình, xem trước, xoá, xem và đổi kích thước AppWidget trừ phi có vấn đề về sự an toàn của người dùng (chẳng hạn như Sự phân tâm của người lái xe).

[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 theo kích thước 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 về SDK Android để biết thông tin chi tiết.

[C-1-4] PHẢI hỗ trợ bản xem trước tiện ích được tạo linh động.
[C-1-5] PHẢI có khả năng tương tác với người dùng bằng bản xem trước yêu cầu người dùng trước khi thêm một tiện ích do ứng dụng yêu cầu thông qua AppWidgetManager.requestPinAppWidget().
[C-1-6] PHẢI hỗ trợ tính năng ghim tiện ích trong ứng dụng.
[C-1-7] PHẢI báo cáo true đối với AppWidgetManager.html.isRequestPinAppWidgetSupported().

CÓ THỂ hỗ trợ các tiện ích ứng dụng trên màn hình khoá.

Nếu các hoạt động 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-2-1] PHẢI báo cáo true cho AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] PHẢI có khả năng tương tác với người dùng để hỏi 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 có 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ác thành phần phần cứng (ví dụ: âm thanh, chế độ rung và ánh sáng) và các tính năng phần mềm (ví dụ: bảng thông báo, thanh hệ thống) của thiết bị.

3.8.3.1. Cách trình bày thông báo

Nếu các hoạt động 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-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 một phương thức triển khai thiết bị có bộ rung, thì phương thức đó PHẢI triển khai chính xác các API rung. Nếu một thiết bị triển khai 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 trình bày chi tiết hơn trong mục 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 ả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/Thanh hệ thống, mặc dù CÓ THỂ cung cấp trải nghiệm người dùng thay thế cho thông báo so với trải nghiệm do quá trình triển khai Nguồn mở Android tham chiếu 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 các API để cập nhật, xoá và nhóm thông báo.
[C-1-4] PHẢI cung cấp đầy đủ 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 một cách để hiển thị các kênh thông báo đã bị 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 lượt tương tác của người dùng thêm. Ví dụ: BẮT BUỘC 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 thiết lập thông qua setGroupConversation.
[C-SR-1] RẤT NÊN cung cấp một cơ chế để người dùng kiểm soát những thông báo được hiển thị cho các ứng dụng đã được cấp quyền Notification Listener. Mức độ chi tiết PHẢI ở mức mà người dùng có thể kiểm soát cho từng trình nghe thông báo như vậy về những loại thông báo được chuyển đến 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", "im lặng" và "liên tục quan trọng".
[C-SR-2] RẤT NÊN cung cấp một phương thức để 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ị cho người dùng một lựa chọn để 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 nhiều lần loại bỏ thông báo đó.
NÊN hỗ trợ thông báo chi tiết.
NÊN trình bày 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ó một cơ chế tương tác để người dùng tạm ẩn thông báo.
MAY chỉ quản lý khả năng hiển thị và thời gian mà các ứ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ư tình trạng lái xe mất tập trung.

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

Triển khai thiết bị:

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

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

[C-SR-5] RẤT 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 các chế độ triển khai thiết bị hỗ trợ thông báo đa dạng, thì:

[C-2-1] PHẢI sử dụng chính xác các tài nguyên như được cung cấp thông qua lớp API Notification.Style và các lớp con của lớp này 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 này.

Thông báo quan trọng là những thông báo được gửi đến người dùng khi chúng xuất hiện, bất kể người dùng đang ở trên bề mặt nào. Nếu các chế độ triển khai thiết bị hỗ trợ thông báo quan trọng, thì:

[C-3-1] PHẢI sử dụng khung hiển thị thông báo quan trọng và các tài nguyên như mô tả trong lớp API Notification.Builder khi thông báo quan trọng xuất hiện.
[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 có các API NotificationListenerService cho phép các ứng dụng (sau khi người dùng bật một cách rõ ràng) nhận bản sao của tất cả thông báo khi chúng được đăng hoặc cập nhật.

Triển khai thiết bị:

[C-0-1] PHẢI cập nhật chính xác và kịp thời toàn bộ thông báo 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 loại bỏ thông báo và thực hiện lệnh gọi lại sau khoảng thời gian tạm ngưng được đặt trong lệnh gọi API.

Nếu các hoạt động triển khai thiết bị có một cơ chế cho phép người dùng tạm ẩn thông báo, thì:

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

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

Nếu các chế độ 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-1-1] PHẢI, khi quá trình triển khai thiết bị đã cung cấp cho người dùng phương tiện cấp hoặc từ chối quyền truy cập của ứng dụng bên thứ ba vào cấu hình chính sách Không làm phiền, hãy hiển thị Quy tắc tự động của chế độ Không làm phiền 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à quy tắc được xác định trước.
[C-1-3] PHẢI tuân thủ các giá trị suppressedVisualEffects được truyền cùng với NotificationManager.Policy và nếu ứng dụng đã đặt bất kỳ cờ SUPPRESSED_EFFECT_SCREEN_OFF hoặc SUPPRESSED_EFFECT_SCREEN_ON nào, thì ứng dụng ĐƯỢC PHÉP cho người dùng biết rằng 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.3.4. Bảo vệ thông báo nhạy cảm

Thông tin nhạy cảm trong thông báo bao gồm nội dung như mật khẩu một lần, mã xác nhận một lần và các mã xác thực hoặc mã đặt lại tương tự có thể xuất hiện trong thông báo cho người dùng.

Nếu các hoạt động 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-1-1] PHẢI chỉnh sửa thông tin nhạy cảm trong thông báo để không chuyển thông tin đó đến trình nghe thông báo, trừ phi dịch vụ trình nghe là một trong những dịch vụ sau:
- Các ứng dụng do hệ thống ký có uid < 10000
- Giao diện người dùng hệ thống
- Vỏ
- Ứng dụng đồng hành được chỉ định (do CompanionDeviceManager xác định)
- SYSTEM_AUTOMOTIVE_PROJECTION vai trò
- SYSTEM_NOTIFICATION_INTELLIGENCE vai trò
- Vai trò HOME

Việc triển khai AOSP của NotificationAssistantServices minh hoạ và đáp ứng các yêu cầu này. Hãy xem android.ext.services.notification để biết ví dụ.

3.8.4. Assist APIs

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

Nếu các hoạt động triển khai thiết bị hỗ trợ thao tác Trợ lý, thì:

[C-2-1] PHẢI cho người dùng cuối biết rõ khi bối cảnh được chia sẻ, bằng cách:
- Mỗi khi ứng dụng trợ lý truy cập vào bối cảnh, ứng dụng sẽ hiển thị á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 trợ lý được cài đặt sẵn, hãy cung cấp cho người dùng một lựa chọn cách trình đơn cài đặt ứng dụng trợ lý và chế độ nhập bằng giọng nói mặc định chưa đến 2 thao tác điều hướng, đồng thời chỉ chia sẻ ngữ cảnh khi người dùng gọi ứng dụng trợ lý một cách rõ ràng thông qua một từ khoá kích hoạt hoặc thao tác nhập bằng phím điều hướng trợ lý.

[C-2-1] CHỈ được chia sẻ bối cảnh với ứng dụng trợ lý khi người dùng gọi ứng dụng một cách rõ ràng thông qua thao tác nhập bằng phím điều hướng hỗ trợ, một cụm từ kích hoạt hoặc điểm truy cập được chỉ định khác.

[C-2-2] Tương tác được chỉ định để chạy ứng dụng trợ lý như mô tả trong mục 7.2.3 PHẢI chạy ứng dụng trợ lý do người dùng chọn, tức là ứng dụng triển khai VoiceInteractionService hoặc một Hoạt động xử lý ý định ACTION_ASSIST.

3.8.5. Cảnh báo và thông báo dạng nổi

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 và biến mất sau một khoảng thời gian ngắn cho người dùng cuối, đồ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 các hoạt động triển khai thiết bị có màn hình hoặc đầu ra video, thì:

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

3.8.6. Chủ đề

Android cung cấp "giao diện" như một cơ chế để các ứng dụng áp dụng kiểu cho toàn bộ Activity hoặc ứng dụng.

Android có một nhóm 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 và cảm quan của giao diện Holo do SDK Android xác định.

Nếu các hoạt động triển khai thiết bị có màn hình hoặc đầu ra video, thì:

[C-1-1] KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính nào của giao diện Holo được hiển thị cho các ứng dụng.
[C-1-2] PHẢI hỗ trợ họ giao diện "Material" và KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính nào của giao diện Material hoặc các thành phần của giao diện này được hiển thị cho các ứ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 những ngôn ngữ mà Roboto hỗ trợ, hoặc cung cấp cho người dùng một thành phần để thay đổi phông chữ được dùng cho bộ phông chữ "sans-serif" thành Roboto phiên bản 2.x cho những 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 màu sắc thái động bằng cách sử dụng các kiểu chủ đề màu sắc đượ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.
- PHẢI được lấy từ hình nền thông qua com.android.systemui.monet.ColorScheme#getSeedColors. Thao tác này sẽ cung cấp nhiều màu nguồn hợp lệ để bạn 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 có một họ 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 giao diện và cảm quan của giao diện thiết bị khớp với giao diện do nhà triển khai thiết bị xác định.

Các hoạt động triển khai thiết bị CÓ THỂ sửa đổi thuộc tính giao diện Mặc định của thiết bị được hiển thị cho các ứng dụng.

Android hỗ trợ một biến thể của giao diện có các thanh hệ thống mờ, cho phép nhà phát triển ứng dụng điền nội dung ứng dụng vào khu vực phía sau thanh trạng thái và thanh điều hướng. Để 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 trên thanh trạng thái trên nhiều cách triển khai thiết bị.

Nếu các hoạt động triển khai thiết bị có thanh trạng thái hệ thống, thì:

[C-2-1] PHẢI sử dụng màu trắng cho các 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) cũng như các thông báo do hệ thống phát hành, 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ờ WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] Các hoạt động triển khai thiết bị Android PHẢI thay đổi màu của 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

Android xác định một loại thành phần và API cũng như vòng đời tương ứng cho phép các ứ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ự có khả năng nhập liệu hạn chế, hiển thị dưới dạng hình nền, đằng 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 mà không có bất kỳ hạn chế nào về chức năng, ở tốc độ khung hình hợp lý mà không ảnh hưởng tiêu cực đến các ứng dụng khác. Nếu những hạn chế 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 đến mức 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 để kết xuất nội dung. 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 hình nền động sử dụng một ngữ cảnh OpenGL có thể xung đột với các ứng dụng khác cũng sử dụng một ngữ cảnh OpenGL.

Các chế độ triển khai thiết bị có khả năng chạy hình nền động một cách đáng tin cậy như mô tả ở trên NÊN 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 của nền tảng android.software.live_wallpaper.

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

Mã nguồn Android ở nguồn trên 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ỏ về 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 gần đây nhất.

Các hoạt động triển khai thiết bị, bao gồm cả khoá đ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Ể thay đổi giao diện.

Nếu các chế độ triển khai thiết bị (bao gồm cả khoá điều hướng chức năng gần đây) như được nêu chi tiết trong mục 7.2.3 thay đổi giao diện, thì các chế độ triển khai đó:

[C-1-1] PHẢI hỗ trợ ít nhất 7 hoạt động hiển thị.
NÊN hiển thị tiêu đề của ít nhất 4 hoạt động cùng một lúc.
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 thành phần cho phép đó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 dùng gần đây nhất khi người dùng nhấn phím chức năng gần đây hai lần.
NÊN kích hoạt chế độ nhiều cửa sổ chia đôi màn hình (nếu được hỗ trợ) khi người dùng nhấn và giữ phím chức năng gần đây.
CÓ THỂ hiển thị các mục 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] NÊN SỬ DỤNG giao diện người dùng Android nguồn (hoặc giao diện tương tự dựa trên hình thu nhỏ) cho màn hình tổng quan.

3.8.9. Quản lý thiết bị đầu vào

Android hỗ trợ Quản lý thiết bị đầu vào và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba.

Nếu các chế độ 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ì:

[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 về SDK Android.

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

Remote Control Client API (API ứng dụng điều khiển từ xa) không được dùng nữa kể từ Android 5.0 để chuyển sang Media Notification Template (Mẫu thông báo về nội dung nghe nhìn) cho phép các ứng dụng nội dung nghe nhìn tích hợp với các nút điều khiển phát xuất hiện trên màn hình khoá.

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

Xem mục 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 các hoạt động triển khai thiết bị có một cảm biến phần cứng (ví dụ: GPS) có khả năng cung cấp toạ độ vị trí, thì các hoạt động triển khai đó:

[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 có hỗ trợ các ký tự biểu tượng cảm xúc được xác định trong Unicode 10.0.

Nếu các hoạt động triển khai thiết bị có màn hình hoặc đầu ra video, thì:

[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ưới dạng glyph màu.
[C-1-2] PHẢI hỗ trợ:
- Phông chữ Roboto 2 với nhiều độ đậm khác nhau – 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ị.
- Hỗ trợ đầy đủ Unicode 7.0 cho các bảng chữ cái Latinh, Hy Lạp và Kirin, bao gồm cả các dải Latinh mở rộng A, B, C và D, cũng như tất cả các glyph 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 một 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)
NÊN hỗ trợ biểu tượng cảm xúc về màu da và gia đình đa dạng như được chỉ định trong Báo cáo kỹ thuật số 51 của Unicode.

Nếu các hoạt động triển khai thiết bị có một IME, thì chúng sẽ:

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

Android có hỗ trợ hiển thị phông chữ tiếng 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ị ngôn ngữ Myanmar.

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

[C-2-1] PHẢI hiển thị văn bản bằng phông chữ tuân thủ Unicode theo 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ợ một phông chữ Unicode và một phông chữ không tuân thủ Unicode nếu thiết bị hỗ trợ phông chữ không 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] CHỈ được hiển thị văn bản bằng phông chữ không tuân thủ Unicode NẾU bạn chỉ định mã ngôn ngữ có mã kịch bản Qaag (ví dụ: my-Qaag). Bạn không thể sử dụng bất kỳ mã ngôn ngữ hoặc mã khu vực ISO nào khác (dù đã được chỉ định, chưa được chỉ định hay được dành riêng) để đề cập đến phông chữ không tuân thủ Unicode cho tiếng Miến Điện. 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 bất kỳ ngôn ngữ nào khác.

3.8.14. Nhiều cửa sổ

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

[C-1-1] PHẢI triển khai(các) chế độ nhiều cửa sổ như vậy theo hành vi và API của ứng dụng đượ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] Yêu cầu này đã bị xoá trong Android 16.
[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] Một hoạt động KHÔNG ĐƯỢC đổi kích thước 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.

[C-1-5] PHẢI hiển thị các tác vụ có thuộc tính selfMovable ở độ mờ tối đa, có một thành phần trang trí liên tục dễ phân biệt (ví dụ: thanh chú thích) và một phương thức để đóng các tác vụ đó ngoài thành phần trang trí liên tục.

Các thiết bị có kích thước màn hình xlarge PHẢI hỗ trợ chế độ cửa sổ tuỳ ý.

Nếu các hoạt động 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-2-2] PHẢI cắt hoạt động được gắn 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 tiêu đ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 gắn.

Nếu các chế độ 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ế độ này:

[C-3-1] PHẢI khở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 quy định của 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, theo quy định của 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 ở nền trước.
[C-3-5] PHẢI cung cấp cho người dùng một thành phần để chặn ứ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ế độ kiểm soát 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 bất kỳ 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.

Nếu các chế độ triển khai thiết bị có nhiều vùng hiển thị tương thích với Android và cung cấp các vùng đó cho ứng dụng, thì các vùng đó:

[C-4-1] PHẢI hỗ trợ chế độ nhiều cửa sổ.

Nếu các hoạt động triển khai thiết bị hỗ trợ(các) chế độ nhiều cửa sổ, thì:

[C-5-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 WindowManager.

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 mà ứng dụng có thể không hoạt động được do vết cắt trên màn hình hoặc màn hình cong ở(các) cạnh.

Nếu các hoạt động triển khai thiết bị có(các) vết cắt trên màn hình, thì:

[C-1-5] KHÔNG ĐƯỢC có vết 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 vết cắt trên mỗi cạnh.
[C-1-3] PHẢI tuân thủ các cờ vết cắt trên 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 các giá trị chính xác cho tất cả chỉ số về vết cắt được xác định trong API DisplayCutout.

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

Android có các API ControlsProviderService và Control để cho phép các ứng dụng bên thứ ba xuất bản chế độ điều khiển thiết bị nhằm giúp người dùng xem nhanh trạng thái và thực hiện hành động.

Hãy xem phần 2_2_3 để biết các yêu cầu cụ thể theo từng thiết bị.

3.8.17. Bảng nhớ tạm

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC gửi dữ liệu trên 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ó thao tác 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 9.8.6 Chụp nội dung và tìm kiếm ứng dụng.

Nếu các hoạt động 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-1-1] PHẢI che thông tin trong bản xem trước mà người dùng nhìn thấy

Quy trình 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.8.18. Nút vị trí

Nút Vị trí là một phần tử trên giao diện người dùng Android mà nhà phát triển ứng dụng có thể nhúng vào ứng dụng của họ để được cấp quyền truy cập thông tin vị trí chính xác cho phiên của ứng dụng đó.

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC thêm, sửa đổi hoặc xoá các lựa chọn tuỳ chỉnh được cung cấp cho nhà phát triển ứng dụng đối với nút vị trí.

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

Android có các tính năng cho phép các ứng dụng trình kiểm soát chính sách thiết bị 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 thực hiện thao tác xóa từ xa, thông qua Device Policy Manager API.

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 quy trình triển khai thiết bị khai báo android.software.device_admin, thì chúng sẽ:

[C-1-1] PHẢI hỗ trợ đăng ký một Trình kiểm soát chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị như mô tả bên dưới:
- Khi quá trình triển khai thiết bị không có người dùng cũng như dữ liệu người dùng nào đượ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ị hoặc 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 một thông báo NFC chứa một 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 quá trình cấp phép của chủ sở hữu thiết bị được kích hoạt để ứng dụng trình kiểm soát chính sách thiết bị (DPC) có thể chọn trở thành Chủ sở hữu thiết bị hoặc 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 từ ngữ cảnh rằng chỉ có một lựa 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 cung cấp, bất kể phương thức cung cấp được 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ì:
  - [C-1-7] KHÔNG ĐƯỢC đăng ký bất kỳ ứng dụng DPC nào làm Ứng dụng chủ sở hữu thiết bị nữa.
[C-1-2] Yêu cầu này đã bị xoá trong Android 15.
[C-2-1] Yêu cầu này đã bị xoá trong Android 15.
[C-2-2] Yêu cầu này đã bị xoá trong Android 15.
[C-2-3] Yêu cầu này đã bị xoá trong Android 15.

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

Nếu các quy trình triển khai thiết bị khai báo android.software.managed_users, thì chúng sẽ:

[C-1-1] PHẢI khai báo android.software.device_admin và triển khai API cho phép ứng dụng Trình kiểm soát chính sách thiết bị (DPC) trở thành chủ sở hữu của một Hồ sơ được quản lý mới.
[C-1-2] Yêu cầu này đã bị xoá trong Android 16.
[C-1-3] PHẢI cung cấp các thông tin sau 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 kiểm soát chính sách thiết bị (DPC) vô hiệu hoá:
- Một biểu tượng nhất quán hoặc thành phần tương tác khác của người dùng (ví dụ: biểu tượng thông tin AOSP ngược dòng) để biểu thị thời điểm một chế độ cài đặt cụ thể bị Quản trị viên thiết bị hạn chế.
- Một 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 khở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 cung cấ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 ACTION_PROFILE_PROVISIONING_COMPLETE đến trình kiểm soát chính sách thiết bị (DPC) của hồ sơ công việc khi quá trình cung cấp được bắt đầu bằng ý định android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] PHẢI gửi ý định ACTION_GET_PROVISIONING_MODE sau khi quá trình cấp phép 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ị hoặc Chủ sở hữu hồ sơ, trừ trường hợp quá trình cấp phép được kích hoạt bằng ý đị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 cung cấp, bất kể phương thức cung cấp nào được sử dụng, ngoại trừ khi quá trình cung cấp được kích hoạt bằng ý định android.app.action.PROVISION_MANAGED_PROFILE. 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 của hồ sơ cá nhân khi một Chủ sở hữu hồ sơ được thiết lập, bất kể phương thức cung cấp nào được sử dụng.

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

Nếu các quy trình triển khai thiết bị khai báo android.software.managed_users, thì chúng sẽ:

[C-1-1] PHẢI hỗ trợ hồ sơ được quản lý thông qua 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 nguồn mở AOSP) để biểu thị các ứng dụng và tiện ích được quản lý cũng như các phần tử khác trên giao diện người dùng có huy hiệu, chẳng hạn như "Gần đây và Thông báo".
[C-1-4] PHẢI hiển thị một 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 ở trong một ứ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ị đánh thức (ACTION_USER_PRESENT) và ứng dụng nền trước nằm trong hồ sơ được quản lý.
[C-1-6] Khi có hồ sơ được quản lý, bạn PHẢI hiển thị một chỉ dẫn trực quan trong "Bộ chọn" Intent để 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 Bộ điều khiển chính sách thiết bị bật tính năng này.
[C-1-7] Nếu có hồ sơ được quản lý, BẮT BUỘC phải hiển thị các thành phần sau cho người dùng đối với cả người dùng chính và hồ sơ được quản lý:
- Lưu giữ hồ sơ riêng cho mức sử dụng pin, vị trí, dữ liệu di động và bộ nhớ của 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 hồ sơ đượ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 thiết bị đáp ứng tất cả các yêu cầu bảo mật áp dụng cho thiết bị có nhiều người dùng (xem mục 9.5), ngay cả khi 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.
[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 một cửa sổ topActivity có tiêu điểm (cửa sổ 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ề một ứng dụng hồ sơ công việc.
[C-1-11] KHÔNG ĐƯỢC chụp bất kỳ nội dung nào khác trên màn hình (thanh hệ thống, thông báo hoặc bất kỳ nội dung nào trong hồ sơ cá nhân) ngoại trừ cửa sổ/các cửa sổ ứ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 vào hồ sơ công việc).

Nếu các phương thức triển khai thiết bị khai báo android.software.managed_users và android.software.secure_lock_screen, thì chúng sẽ:

[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 để chỉ cấp quyền truy cập cho các ứng dụng chạy trong một hồ sơ được quản lý.
- Các hoạt động triển khai thiết bị PHẢI tuân theo ý định DevicePolicyManager.ACTION_SET_NEW_PASSWORD và hiển thị một giao diện để định cấu hình thông tin đăng nhập riêng cho màn hình khoá đối với hồ sơ được quản lý.
- Thông tin đăng nhập 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à vùng lưu trữ thông tin xác thực như hồ sơ chính, theo tài liệu 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 đăng nhập trên màn hình khoá của hồ sơ được quản lý, trừ phi được gọi trên phiên bản DevicePolicyManager do getParentProfileInstance trả về.
Khi danh bạ trong hồ sơ được quản lý xuất hiện 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 cuộc gọi đang diễn ra và cuộc gọi nhỡ, danh bạ và ứng dụng nhắn tin, các ứng dụng này PHẢI được gắn huy hiệu bằng chính huy hiệu dùng để cho biết 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 quy trình triển khai thiết bị khai báo android.software.managed_users, thì chúng sẽ:

[C-1-1] PHẢI cung cấp cho người dùng một phương thức để đă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 có thể truy cập vào thành phần tương tác này 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 cho người dùng một thành phần trên thiết bị để thêm người dùng phụ, thì:

[C-SR-1] RẤT NÊN hiển thị nội dung công bố tương tự về sự đồng ý của Chủ sở hữu thiết bị AOSP như nội dung đã xuất hiện 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 vào Người dùng phụ mới, để người dùng hiểu rằng thiết bị đang đượ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 các quy trình triển khai thiết bị khai báo android.software.device_admin, thì chúng sẽ:

[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 có dấu hai chấm (:) 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] Các phương thức triển khai thiết bị PHẢI hỗ trợ việc cung cấp mà không cần ứng dụng giữ vai trò quản lý chính sách thiết bị (AOSP cung cấp một phương thức triển khai tham chiếu).

Nếu bạn xác định tên gói 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] Các hoạt động triển khai thiết bị CÓ THỂ xác định một ứng dụng cập nhật người nắm giữ vai trò quản lý chính sách thiết bị trước khi cung cấp bằng cách đặt config_devicePolicyManagementUpdater.

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

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

3.9.5. Khung giải pháp chính sách thiết bị

Nếu các quy trình triển khai thiết bị khai báo android.software.device_admin, thì chúng sẽ:

[C-1-1] PHẢI giải quyết các xung đột về chính sách thiết bị như được ghi trong Khung giải quyết chính sách thiết bị.

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 các hoạt động triển khai dịch vụ hỗ trợ tiếp cận nhận lệnh gọi lại cho các sự kiện của người dùng và hệ thống, đồng thời tạo 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 các hoạt động triển khai thiết bị hỗ trợ dịch vụ trợ năng của bên thứ ba, thì các hoạt động này sẽ:

[C-1-1] PHẢI triển khai khung hỗ trợ tiếp cận Android như mô tả trong tài liệu SDK API hỗ trợ tiếp cận.
[C-1-2] PHẢI tạo các 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 một thành phần cho người dùng để kiểm soát các dịch vụ hỗ trợ tiếp cận khai báo AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Xin lưu ý rằng đối với các chế độ triển khai thiết bị có thanh điều hướng hệ thống, các chế độ này PHẢI cho phép người dùng có lựa chọn sử dụng một 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 các dịch vụ hỗ trợ tiếp cận được cài đặt sẵn trong quá trình triển khai thiết bị, thì các dịch vụ đó sẽ:

[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 Hỗ trợ chế độ 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 lựa chọn điều chỉnh cỡ chữ, kích thước hiển thị và cử chỉ phóng to.

3.11. Chuyển văn bản sang lời nói

Android có 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 các phương thức triển khai thiết bị báo cáo tính năng android.hardware.audio.output, thì:

[C-1-1] PHẢI hỗ trợ các API khung TTS của Android.

Nếu các hoạt động 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-2-1] PHẢI cung cấp cho người dùng thành phần để cho phép người dùng chọn một công cụ Chuyển văn bản sang lời nói (TTS) để sử dụng ở cấp hệ thống.

3.12. Không áp dụng

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 ngay lập tức.

Nếu các chế độ triển khai thiết bị có thành phần giao diện người dùng Cài đặt nhanh và hỗ trợ chế độ Cài đặt nhanh của bên thứ ba, thì:

[C-1-1] PHẢI cho phép người dùng thêm hoặc xoá các ô được cung cấp thông qua API quicksettings khỏi một ứng dụng bên thứ ba.
[C-1-2] KHÔNG ĐƯỢC tự động thêm ô từ ứng dụng bên thứ ba trực tiếp vào trình đơn Cài đặt nhanh.
[C-1-3] PHẢI hiển thị tất cả các ô do người dùng thêm từ ứng dụng bên thứ ba cùng với các ô 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 các hoạt động triển khai thiết bị bao gồm những ứng dụng không kích hoạt bằng giọng nói (Các ứ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ì Các ứng dụng:

[C-1-2] PHẢI hiển thị rõ ràng các biểu tượng nhận được thông qua getIconBitmap() hoặc getIconUri() và tiêu đề nhận được thông 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ệ thống phân cấp để tuân thủ các quy định an toàn (ví dụ: Sự phân tâm của người lái xe), nhưng KHÔNG ĐƯỢC phép ưu tiên dựa trên nội dung hoặc nhà cung cấp nội dung.
[C-1-5] PHẢI coi thao tác nhấn đúp vào KEYCODE_HEADSETHOOK hoặc KEYCODE_MEDIA_PLAY_PAUSE là KEYCODE_MEDIA_NEXT đối với MediaSession.Callback#onMediaButtonEvent.

3.15. Ứng dụng tức thì

Nếu hỗ trợ Ứng dụng tức thì, thì các hoạt động triển khai thiết bị PHẢI đáp ứng các yêu cầu sau:

[C-1-1] Ứng dụng tức thì CHỈ ĐƯỢC cấp những quyền 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 intent ngầm, trừ phi một trong các trường hợp sau đây xảy ra:
- Bộ lọc mẫu ý định của thành phần được hiển thị và có CATEGORY_BROWSABLE
- Thao tác này 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ừ phi thành phần đó được hiển thị thông qua android:visibleToInstantApps.
[C-1-4] Các ứ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.
Các hoạt động triển khai thiết bị PHẢI cung cấp cho người dùng những lựa chọn sau đây để tương tác với Ứng dụng tức thì. AOSP đáp ứng các yêu cầu bằng Giao diện người dùng hệ thống, Cài đặt và Trình chạy mặc định. Triển khai thiết bị:
- [C-1-5] PHẢI cung cấp cho người dùng một thành phần để xem và xoá các Ứ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 này cho người dùng 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 một thành phần tương tác hướng người dùng đế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 trên web, như được xác định bằng cách sử dụng một ý định có thao tác được đặt thành Intent.ACTION_VIEW và có một lược đồ "http" hoặc "https", một thành phần bổ sung cho 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 thông qua chức năng Gần đây nếu chức năng này có trên thiết bị.
[C-1-8] PHẢI tải sẵn một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng một 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ý hiệu quả hơn mối liên kết với các thiết bị đồng hành và cung cấp API CompanionDeviceManager để các ứng dụng truy cập vào tính năng này.

Nếu các hoạt động triển khai thiết bị hỗ trợ tính năng ghép nối thiết bị đồng hành, thì:

[C-1-1] 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 khả năng chọn/xác nhận rằng thiết bị đồng hành đang hoạt động và có mặt. Khả năng này PHẢI sử dụng cùng một thông báo như được triển khai trong AOSP mà không có nội dung bổ sung hoặc sửa đổi.

3.17. Ứng dụng có kích thước lớn

Nếu các phương thức triển khai thiết bị khai báo tính năng FEATURE_CANT_SAVE_STATE, thì các phương thức triển khai đó:

[C-1-1] CHỈ ĐƯỢC có một ứng dụng cần 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 rõ ràng (ví dụ: bằng cách nhấn vào nút trang chủ trong khi rời khỏi một hoạt động đang hoạt động, thay vì nhấn vào nút quay lại khi không còn hoạt động nào đang hoạt động trong hệ thống), thì các hoạt động triển khai thiết bị PHẢI ưu tiên ứng dụng đó trong RAM như đối với những thứ khác dự kiến vẫn đang chạy, chẳng hạn như các dịch vụ trên nền trước. Khi ứ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ư hạn chế quyền truy cập vào CPU và mạng.
[C-1-2] PHẢI cung cấp một thành phầ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 ứ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 đối với những ứ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ập lịch.

Nếu các chế độ triển khai thiết bị không khai báo tính năng FEATURE_CANT_SAVE_STATE, thì các chế độ triển khai đó sẽ:

[C-1-1] PHẢI bỏ qua thuộc tính cantSaveState do các ứ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 có 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 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 Account khi các cột ACCOUNT_NAME và ACCOUNT_TYPE cho các số điện thoại 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: Tài khoản dành cho các số liên hệ thô chỉ được lưu trữ trên thiết bị và không được liên kết với Tài khoản trong AccountManager, được tạo bằng các giá trị null cho các cột ACCOUNT_NAME và ACCOUNT_TYPE.

Tài khoản cục bộ tuỳ chỉnh: Tài khoản dành cho các số liên lạc thô chỉ được lưu trữ trên thiết bị và không được liên kết với Tài khoản trong AccountManager, được tạo bằng các giá trị khác rỗng cho cả cột ACCOUNT_NAME và ACCOUNT_TYPE.

Triển khai thiết bị:

[C-SR-1] KHÔNG NÊN tạo tài khoản cục bộ tuỳ chỉnh.

Nếu các chế độ triển khai thiết bị sử dụng tài khoản cục bộ tuỳ chỉnh:

[C-1-1] ACCOUNT_NAME của tài khoản cục bộ tuỳ chỉnh PHẢI được trả về bằng ContactsContract.RawContacts.getLocalAccountName
[C-1-2] ACCOUNT_TYPE của tài khoản cục bộ tuỳ chỉnh PHẢI được ContactsContract.RawContacts.getLocalAccountType trả về
[C-1-3] Các ứng dụng bên thứ ba chèn danh bạ thô mà không chỉ định tài khoản PHẢI được chèn vào tài khoản danh bạ mặc định của thiết bị. Nếu tài khoản danh bạ mặc định là DEFAULT_ACCOUNT_STATE_LOCAL hoặc DEFAULT_ACCOUNT_STATE_NOT_SET, thì các danh bạ thô này PHẢI được lưu trữ trong tài khoản tuỳ chỉnh trên thiết bị.
[C-1-4] Bạn KHÔNG ĐƯỢC xoá các số liên lạc thô được chèn vào tài khoản tuỳ chỉnh trên thiết bị 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 các số điện thoại liên hệ thô bị xoá ngay lập tức (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.

(Các) tài khoản SIM: (Các) tài khoản cho các số liên hệ thô được sao chép từ một hoặc nhiều thẻ SIM thực được lắp vào thiết bị và không được liên kết với Tài khoản trong AccountManager.

Triển khai thiết bị:

Nếu các hoạt động triển khai thiết bị sử dụng(các) tài khoản SIM:

[C-1-6] ContactsContract.SimContacts.getSimAccounts PHẢI trả lại(các) tài khoản SIM.

3.18.2. Trình chọn người liên hệ của hệ thống

Android hỗ trợ một Trình chọn người liên hệ của hệ thống, cho phép các ứng dụng truy cập vào thông tin liên hệ có giới hạn mà không cần có quyền truy cập rộng rãi.

Nếu các hoạt động triển khai thiết bị hỗ trợ danh bạ Android, thì:

[C-1-1] PHẢI triển khai Trình chọn người liên hệ của hệ thống (com.android.contactspicker) cho các ứng dụng nhắm đến API cấp 37 trở lên.
[C-1-2] PHẢI triển khai ý định Intent.ACTION_PICK_CONTACTS.

3.19. Cài đặt ngôn ngữ

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC cung cấp bất kỳ thành phần nào để người dùng chọn cách xử lý ngôn ngữ theo giới tính cho những ngôn ngữ không hỗ trợ bản dịch theo giới tính. Hãy tham khảo tài nguyên ngữ pháp để biết thêm thông tin.

3.20. Trải nghiệm dựa trên Trợ lý

Khung phát triển trợ lý Android giúp người dùng điều khiển ứng dụng Android bằng giọng nói. Với Trợ lý, người dùng có thể dùng giọng nói để khởi chạy ứng dụng, thực hiện thao tác, truy cập vào nội dung, v.v.

Đối với phần này, hãy tham khảo các phân loại sau đây để biết cách triển khai thiết bị chuyên dụng:

Âm lượng cố định: Thiết bị có âm lượng cố định là thiết bị có các nút điều khiển âm lượng nhưng không cho phép ứng dụng thay đổi mức luồng âm thanh bằng các phương thức AudioManager tiêu chuẩn (ví dụ: ô tô chạy Android Automotive OS).
Âm lượng tối đa: Thiết bị có âm lượng tối đa là thiết bị có âm lượng được đặt ở mức tối đa, không bị suy giảm và không cho phép kiểm soát bằng phần mềm (ví dụ: TV có loa ngoài).
Một âm lượng: Thiết bị có một âm lượng là thiết bị ánh xạ tất cả luồng âm thanh đến một luồng âm lượng duy nhất, dẫn đến việc điều chỉnh âm lượng ảnh hưởng đến tất cả luồng âm thanh một cách đồng nhất (ví dụ: TV).

3.20.1. Yêu cầu đối với luồng âm thanh của Trợ lý

Một ứng dụng có quyền MANAGE_ASSISTANT_AUDIO:

[C-0-1] PHẢI được phép thay đổi âm lượng STREAM_ASSISTANT theo phương thức lập trình.

Nếu các chế độ triển khai thiết bị không khai báo android.hardware.type.watch và không phải là âm lượng cố định, âm lượng đơn hoặc âm lượng tối đa, thì các chế độ triển khai này sẽ:

[C-1-1] PHẢI triển khai STREAM_ASSISTANT dưới dạng luồng âm thanh tách biệt và KHÔNG ĐƯỢC liên kết với bất kỳ luồng nào khác.
[C-1-2] PHẢI đảm bảo rằng âm lượng phát của chế độ phát âm thanh bằng AudioAttributes có USAGE_ASSISTANT được điều khiển bằng STREAM_ASSISTANT.
[C-1-3] PHẢI đảm bảo rằng đối với một tai nghe Bluetooth nhất định, chỉ mục âm lượng STREAM_ASSISTANT vẫn giữ nguyên khi tai nghe chuyển đổi giữa các cấu hình âm thanh A2DP và HFP.
[C-1-4] PHẢI ngăn mọi luồng khác ngoài STREAM_ASSISTANT có thể thay đổi âm lượng của STREAM_ASSISTANT hoặc độ suy giảm được áp dụng cho quá trình phát USAGE_ASSISTANT, trong khi MODE_ASSISTANT_CONVERSATION đang hoạt động.
[C-1-5] PHẢI thay đổi âm lượng của luồng STREAM_ASSISTANT và không thay đổi âm lượng của các luồng khác, khi âm lượng được điều chỉnh thông qua các phím âm lượng của thiết bị hoặc thiết bị ngoại vi (chẳng hạn như tai nghe Bluetooth) và khi:
- MODE_ASSISTANT_CONVERSATION đang hoạt động và
- Không có chế độ tuỳ chỉnh dành riêng cho ứng dụng hoặc chế độ phát từ xa đang hoạt động.
[C-1-6] PHẢI phản ánh mọi thay đổi về âm lượng của Trợ lý trong giao diện người dùng.

3.21. Hỗ trợ các tính năng đồng bộ hoá thiết bị đồng hành

Android hỗ trợ các tính năng đồng bộ hoá dữ liệu trên các thiết bị đồng hành.

Nếu các chế độ triển khai thiết bị hỗ trợ tính năng đồng bộ hoá chế độ Không làm phiền, thì:

[C-1-1] PHẢI triển khai API ContextualModeManager#isModeSyncSupported.
[C-1-2] PHẢI đồng bộ hoá chế độ cài đặt cho biết chế độ Không làm phiền được bật thông qua kênh bảo mật CompanionDeviceManager bằng cách sử dụng định dạng dữ liệu tương thích với chế độ triển khai CompanionDeviceManagerService mặc định.
[C-1-3] PHẢI bật chế độ đồng bộ hoá này nếu ContextualModeManager#isModeSyncEnabled trả về true.

Nếu các hoạt động triển khai thiết bị hỗ trợ tính năng đồng bộ hoá Chế độ trên máy bay, thì:

[C-1-4] PHẢI đồng bộ hoá chế độ cài đặt cho biết Chế độ trên máy bay được bật thông qua kênh bảo mật CompanionDeviceManager bằng cách sử dụng định dạng dữ liệu tương thích với chế độ triển khai CompanionDeviceManagerService mặc định.
[C-1-5] PHẢI bật tính năng đồng bộ hoá này nếu bạn bật Settings.Global.AIRPLANE_MODE_SYNC.

3.22. ComputerControls API

ComputerControls API cho phép các tác nhân được hỗ trợ thực hiện các hành động tự động và không theo kịch bản thay cho người dùng để hoàn thành các tác vụ trên thiết bị Android.

[C-1-1] Nếu các chế độ triển khai thiết bị tải trước thư viện tiện ích com.android.extensions.computercontrol để hỗ trợ ComputerControl, thì các chế độ triển khai đó:

BẠN PHẢI bật android.software.activities_on_secondary_display.
PHẢI cho thấy tính năng hệ thống com.android.extensions.computercontrol ở trạng thái có sẵn.
BẠN PHẢI bật VirtualDeviceManager.
PHẢI thêm com.android.extensions.computercontrol vào danh sách do PackageManager#getSharedLibraries() trả về.
PHẢI tải trước ứng dụng nền tảng com.android.virtualdevicemanager (mục tiêu bản dựng VirtualDeviceManager).

4. Khả năng tương thích của việc đóng gói ứng dụng

Các cách 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 có trong SDK Android chính thức.
- Vì yêu cầu nêu trên có thể gây khó khăn, nên các hoạt động triển khai thiết bị NÊN sử dụng hệ thống quản lý gói của hoạt động triển khai tham chiếu AOSP.

[C-0-2] PHẢI hỗ trợ xác minh các tệp ".apk" bằng Lược đồ chữ ký APK v3.2, Lược đồ chữ ký APK v3.1, Lược đồ chữ ký APK v3, Lược đồ chữ ký APK v2 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 đúng cách trên các thiết bị tương thích khác.
[C-0-4] KHÔNG ĐƯỢC phép các ứng dụng khác ngoài "trình cài đặt mặc định" hiện tại của gói tự động gỡ cài đặt ứng dụng mà không cần người dùng xác nhận, như được ghi lại trong SDK cho quyền DELETE_PACKAGE. 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 các gói ứng dụng từ 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:
- Bạn 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.
CẦN cung cấp cho người dùng một thành phần để 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 phương thức này dưới dạng một thao tác không có hiệu lực và trả về RESULT_CANCELED cho startActivityForResult(), nếu quá trình 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, họ 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ị một hộp thoại cảnh báo có 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 API hệ thống PackageManager.setHarmfulAppWarning đánh dấu là có khả năng gây hại.
NÊN cung cấp cho người dùng một lựa chọn để chọn gỡ cài đặt hoặc khởi chạy một ứ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 gia tăng như được ghi lại tại đây.
[C-0-9] PHẢI hỗ trợ xác minh các 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 với nội dung đa phương tiện

Triển khai 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 mục 5.1 cho từng bộ mã hoá và giải mã mà MediaCodecList khai báo.
[C-0-2] PHẢI khai báo và báo cáo việc hỗ trợ các 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ả các định dạng mà ứng dụng này có thể mã hoá. Điều này bao gồm tất cả các luồng bit mà bộ mã hoá của nó tạo ra và các hồ sơ được báo cáo trong CamcorderProfile.

Triển khai thiết bị:

NÊN hướng đến độ trễ tối thiểu của bộ mã hoá và giải mã, nói cách khác, chúng
- KHÔNG ĐƯỢC sử dụng và lưu trữ các vùng đệm đầu vào, đồng thời chỉ trả về các vùng đệm đầu vào sau khi xử lý.
- KHÔNG NÊN giữ lại các vùng đệm đã giải mã lâu hơn thời gian được chỉ định theo tiêu chuẩn (ví dụ: SPS).
- KHÔNG NÊN giữ các vùng đệm được mã hoá lâu hơn thời gian cần thiết theo cấu trúc GOP.

Tất cả cá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 hoạt động triển khai phần mềm trong hoạt động triển khai Android ưu tiên từ Dự án nguồn mở Android.

Xin lưu ý rằng cả Google lẫn Open Handset Alliance đều không tuyên bố rằng các bộ mã hoá và giải mã này không vi phạm 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 (kể 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 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. Thông tin chi tiết về bộ mã hoá và giải mã âm thanh.

Nếu các chế độ triển khai thiết bị khai báo android.hardware.microphone, thì các chế độ này PHẢI hỗ trợ mã hoá các định dạng âm thanh sau và cung cấp các định dạng này cho các ứng dụng bên thứ ba:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

[C-1-4] MPEG-D USAC có MPEG-D DRC (AAC hiệu suất cao mở rộng)

Tất cả bộ mã hoá âm thanh PHẢI hỗ trợ:

[C-3-1] Khung âm thanh theo thứ tự byte gốc PCM 16 bit thông qua API android.media.MediaCodec.

Khi mã hoá MPEG-D USAC bằng âm thanh MPEG-D DRC (AAC hiệu suất cao mở rộng):

[C-3-2] Tất cả các luồng bit PHẢI chứa các bộ siêu dữ liệu tuân thủ hồ sơ kiểm soát độ lớn MPEG-D hoặc hồ sơ kiểm soát dải động MPEG-D, cấp 1 trở lên, theo tiêu chuẩn ISO/IEC 23003-4.

5.1.2. Giải mã âm thanh

Xem thêm thông tin chi tiết trong phần 5.1.3. Thông tin 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 này phải hỗ trợ việc giải mã các định dạng âm thanh sau:

[C-1-1] Cấu hình AAC MPEG-4 (AAC LC)
[C-1-2] Cấu hình HE AAC MPEG-4 (AAC+)
[C-1-3] Cấu hình MPEG-4 HE AACv2 (AAC+ nâng cao)
[C-1-4] AAC ELD (AAC có độ trễ thấp nâng cao)
[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á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 số kênh trong giai đoạn phát.
[C-1-10] Opus
[C-1-11] xHE-AAC (Hồ sơ HE AAC mở rộng theo tiêu chuẩn ISO/IEC 23003-3, bao gồm Hồ sơ cơ sở USAC và Hồ sơ kiểm soát dải động theo tiêu chuẩn ISO/IEC 23003-4)

Nếu các phương thức triển khai thiết bị hỗ trợ việc giải mã các vùng đệm đầu vào AAC của luồng đa kênh (tức là có nhiều hơn 2 kênh) thành PCM thông qua bộ giải mã âm thanh AAC mặc định trong API android.media.MediaCodec, thì các phương thức triển khai sau ĐỀU PHẢI được hỗ trợ:

[C-2-1] Bạn PHẢI giải mã mà không cần trộn âm thanh (ví dụ: luồng AAC 5.0 phải được giải mã thành 5 kênh PCM, luồng AAC 5.1 phải được giải mã thành 6 kênh PCM).
[C-2-2] Siêu dữ liệu dải động PHẢI được xác định trong "Kiểm soát dải động (DRC)" trong 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á AAC DRC được giới thiệu trong API 21 và là: 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 nêu trên.

Khi giải mã âm thanh USAC, MPEG-D (ISO/IEC 23003-4):

[C-3-1] Siêu dữ liệu về độ lớn và DRC PHẢI được diễn giải và áp dụng theo Cấp 1 của Cấu hình kiểm soát dải động DRC MPEG-D.
[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 đây: 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:

MAY support loudness and dynamic range control using ISO/IEC 23003-4 Dynamic Range Control Profile.

Nếu ISO/IEC 23003-4 được hỗ trợ và nếu cả siêu dữ liệu ISO/IEC 23003-4 và ISO/IEC 14496-3 đều có trong một 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 16 bit PCM thông qua API android.media.MediaCodec.

[C-7-1] Ứng dụng PHẢI có thể định cấu hình bằng cách sử dụng quá trình giải mã bằng khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát việc nội dung có được trộn xuống thành âm thanh nổi (khi sử dụng giá trị 2) hay đượ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ố lượng đó). 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 thông báo mặt nạ kênh đang được 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).

Tất cả thiết bị Cầm tay hoặc Máy tính bảng có hiệu ứng Bộ mở rộng không gian và tất cả thiết bị Ô tô và truyền hình:

[C-8-1] PHẢI hỗ trợ việc giải mã IAMF phiên bản 1.0 có chứa các luồng âm thanh được mã hoá bằng AAC, FLAC, Opus hoặc PCM, đồng thời PHẢI trình bày một bộ giải mã IAMF thông qua API android.media.MediaCodec.
[C-8-2] PHẢI đảm bảo bộ giải mã IAMF tuân thủ mặt nạ kênh đang được dùng để định cấu hình thông qua khoá KEY_CHANNEL_MASK, bằng cách dùng các hằng số android.media.AudioFormat như CHANNEL_OUT_5POINT1.
[C-8-3] PHẢI đảm bảo bộ giải mã IAMF quảng cáo mặt nạ kênh đang hoạt động trên định dạng đầu ra thông qua khoá KEY_CHANNEL_MASK, sử dụng các hằng số android.media.AudioFormat như CHANNEL_OUT_5POINT1.

Nếu các hoạt động 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ó khả năng xuất âm thanh đa kênh (tức là 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 quy trình giải mã bằng khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát việc nội dung có được trộn xuống thành âm thanh nổi (khi dùng giá trị 2) hay được xuất bằng số kênh gốc (khi dùng giá trị bằng hoặc lớn hơn số kênh đó). 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ã, TRÌNH GIẢI MÃ NÊN quảng cáo mặt nạ kênh đang được dùng trên định dạng đầu ra bằng khoá KEY_CHANNEL_MASK, 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ã	Chi tiết	Các loại tệp/định dạng vùng chứa được hỗ trợ
G.711 μ-law và A-law	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.1 được lấy mẫu ở tốc độ 8 kHz	WAVE (.wav)
Hồ sơ AAC MPEG-4 (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) ADTS AAC thô (.aac, không được hỗ trợ ADIF) MPEG-TS (.ts, không tìm kiếm được, 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)
MPEG-4 HE AACv2 Hồ sơ (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 có độ 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 MPEG-D USAC có MPEG-D DRC (AAC hiệu suất cao mở rộng)	Giải mã: Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu tiêu chuẩn từ 7,35 đến 48 kHz. Mã hoá: Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu là 44,1 và 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 đến 12,2 kb/giây được lấy mẫu ở tần số 8 kHz	3GPP (.3gp)
AMR-WB	9 tốc độ từ 6,60 kbit/s đến 23,85 kbit/s được lấy mẫu ở tốc độ 16 kHz, như được xác định tại AMR-WB, Bộ mã hoá và giải mã lời nói băng tần rộng đa tốc độ thích ứng	3GPP (.3gp)
FLAC	Đối với cả bộ mã hoá và bộ giải mã: hệ thống 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. Bạn PHẢI xử lý dữ liệu âm thanh FLAC 24 bit bằng cấu hình âm thanh dấu phẩy động.	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 có tốc độ bit không đổi (CBR) hoặc tốc độ bit thay đổi (VBR) từ 8 đến 320 Kb/giây	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à Mobile XMF. 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à độ chính xác đơn 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à số thực 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.

Các chế độ triển khai thiết bị PHẢI hỗ trợ mã hoá chế độ mã hoá hình ảnh sau:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- Thiết bị phải hỗ trợ BITRATE_MODE_CQ và Hồ sơ cơ sở.

Nếu các chế độ 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-1-1] PHẢI cung cấp một bộ mã hoá và giải mã HEVC được tăng tốc bằng 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.

Các hoạt động triển khai thiết bị PHẢI hỗ trợ việc giải mã phương thức mã hoá hình ảnh sau:

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Raw
[C-0-7] AVIF (Hồ sơ cơ sở)

Nếu các hoạt động triển khai thiết bị hỗ trợ tính năng giải mã video HEVC, thì:

[C-1-1] PHẢI hỗ trợ tính năng giải mã hình ảnh HEIF (HEIC).

Bộ giải mã hình ảnh hỗ trợ định dạng có độ sâu bit cao (9+ bit cho 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ề codec hình ảnh

Định dạng/Bộ mã hoá và giải mã	Chi tiết	Các loại tệp/định dạng vùng chứa được hỗ trợ
JPEG	Cơ bản + lũy 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, chuỗi hình ảnh	Vùng chứa HEIF (.avif)

Trình 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] RẤT 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.

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, các hoạt động triển khai thiết bị NÊN sử dụng một bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu.

Nếu các hoạt động triển khai thiết bị có bộ mã hoá hoặc giải mã video:

[C-1-1] Bộ mã hoá và giải mã video PHẢI hỗ trợ kích thước bytebuffer đầ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 tiêu chuẩn và cấu hình, nhưng cũng không 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 đị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.
[C-SR-1] BỘ MÃ HOÁ VÀ GIẢI MÃ VIDEO ĐƯỢC RẤT KHUYẾN KHÍCH hỗ trợ ít nhất một đị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 tương đương được nhà cung cấp tối ưu hoá).
[C-1-5] Bộ giải mã video hỗ trợ định dạng có độ sâu bit cao (9+ bit trên mỗi kênh) PHẢI hỗ trợ xuất đị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 các chế độ triển khai thiết bị quảng cáo hỗ trợ hồ sơ HDR thông qua Display.HdrCapabilities, thì:

[C-2-1] PHẢI hỗ trợ việc phân tích cú pháp và xử lý siêu dữ liệu tĩnh HDR.

Nếu các phương thức triển khai thiết bị quảng cáo hỗ trợ làm mới nội bộ thông qua FEATURE_IntraRefresh trong lớp MediaCodecInfo.CodecCapabilities, thì các phương thức này:

[C-3-1] PHẢI hỗ trợ các khoảng thời gian làm mới trong phạm vi 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 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 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á để CPU đọc nếu được định cấu hình để không sử dụng đầu ra Surface.

Đối với những thiết bị triển khai có bộ mã hoá hoặc bộ giải mã video:

[C-5-1] Bộ giải mã video sử dụng công nghệ mã hoá từ năm 2003 trở đi (chẳng hạn như AV1, AVC, HEVC, VP8, VP9 hoặc VVC) PHẢI:
- Hỗ trợ kích thước tối thiểu là 144 x 144 px và
- Quảng cáo chế độ hỗ trợ này thông qua VideoCapabilities API, chẳng hạn như các phương thức getSupportedWidths() và getSupportedHeightsFor().
[C-5-2] Bộ mã hoá video sử dụng công nghệ mã hoá từ năm 2003 trở đi (chẳng hạn như AV1, AVC, HEVC, VP8, VP9 hoặc VVC) PHẢI:
- Hỗ trợ đầu vào Surface ở kích thước tối thiểu sau đây cho mỗi bộ mã hoá:
  - AVC: 160x160 px
  - VP8, HEVC, VP9 (nếu bộ mã hoá được cung cấp): 160x160 px
  - AV1 (nếu bộ mã hoá được cung cấp): 256 x 256 pixel
- CÓ THỂ tạo ra một luồng bit có kích thước khung hình lớn hơn kích thước tối thiểu, miễn là họ mã hoá kích thước phù hợp bằng cách sử dụng thông tin về hình chữ nhật cắt.

5.1.8. Danh sách bộ mã hoá và giải mã video

Định dạng/Bộ mã hoá và giải mã	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 mục 5.2 và 5.3 để biết thông tin chi tiết	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, không tìm kiếm được) Matroska (.mkv, chỉ giải mã)
H.265 HEVC	Hãy 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 tìm kiếm được) 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	Hãy xem mục 5.2 và 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv)
VP9	Hãy xem mục 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv)
AV1	Hãy 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 của 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 đa phương tiện đa nền tảng, cũng như Codec 2.0, một API tăng tốc đa phương tiện có mức hao tổn thấp.

Nếu các hoạt động triển khai thiết bị hỗ trợ nội dung đa phương tiện, thì:

[C-1-1] PHẢI hỗ trợ các 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 phá vỡ các biện pháp bảo vệ an ninh. Điều này không có nghĩa là mọi codec ĐỀU PHẢI sử dụng API OMX hoặc Codec 2.0, mà chỉ có nghĩa là bạn PHẢI hỗ trợ ít nhất một trong các API này và việc hỗ trợ các API có sẵn PHẢI bao gồm các biện pháp bảo vệ bảo mật hiện có.
[C-SR-1] RẤT NÊN hỗ trợ API Codec 2.0.

Nếu các phương thức triển khai thiết bị không hỗ trợ API Codec 2.0, thì:

[C-2-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm OMX tương ứng trong 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] Các 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ủa họ.
[C-SR-2] RẤT NÊN sử dụng các bộ mã hoá và giải mã phần mềm OMX trong một quy trình 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 các phương thức triển khai thiết bị hỗ trợ Codec 2.0 API, thì:

[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 trong 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ữ các 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 hẹp hơn vào các bộ mã hoá và giải mã phần mềm.
[C-3-3] Các 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 của họ.

5.1.10. Đặc điểm của bộ mã hoá và giải mã nội dung nghe nhìn

Nếu các hoạt động triển khai thiết bị hỗ trợ các bộ mã hoá và giải mã nội dung nghe nhìn, thì:

[C-1-1] PHẢI trả về các giá trị chính xác về đặc điểm của bộ mã hoá và giải mã nội dung nghe nhìn thông qua API MediaCodecInfo.

Cụ thể:

[C-1-2] Các 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] Các bộ mã hoá và giải mã có tên bắt đầu bằng "c2." PHẢI sử dụng Codec 2.0 API và có tên tuân thủ nguyên tắc đặt tên Codec 2.0 cho Android.
[C-1-4] Các 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 được tăng tốc bằng phần cứng.
[C-1-5] Các bộ mã hoá và giải mã chạy trong một 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à trình ánh xạ bộ nhớ) KHÔNG ĐƯỢC coi là chỉ có phần mềm.
[C-1-6] Các 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] Các bộ mã hoá và giải mã sử dụng chế độ tăng tốc phần cứng PHẢI được mô tả là được 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ụ: các bộ mã hoá và giải mã có tên "decoders" PHẢI hỗ trợ giải mã và các bộ mã hoá và giải mã có tên "encoders" PHẢI hỗ trợ mã hoá. Các 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ợ những định dạng đó.

Nếu các 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ả các bộ mã hoá và giải mã video PHẢI công bố dữ liệu về 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 pixel (Bộ mã hoá MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 pixel (khác)	704 x 576 pixel (H263) 640 x 360 pixel (VP8, VP9) 640 x 480 pixel (bộ mã hoá MPEG4) 720 x 480 pixel (khác, AV1)	1408 x 1152 pixel (H263) 1280 x 720 pixel (khác, AV1)	1920 x 1080 pixel (ngoài MPEG4, AV1)	3840 x 2160 pixel (HEVC, VP9, AV1)

[C-2-2] Các bộ mã hoá và giải mã video được đặc trưng là tăng tốc phần cứng PHẢI xuất bản thông tin về điểm hiệu suất. Mỗi điểm MUST đều liệt kê tất cả các điểm hiệu suất tiêu chuẩn được hỗ trợ (được liệt kê trong API PerformancePoint), trừ phi các điểm đó được bao gồm trong một điểm hiệu suất tiêu chuẩn được hỗ trợ khác.
Ngoài ra, họ NÊN xuất bản các điểm hiệu suất mở rộng nếu họ hỗ trợ hiệu suất video duy trì ngoài một trong những hiệu suất tiêu chuẩn được liệt kê.

5.2. Mã hoá video

Nếu các phương thứ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à không ảnh hưởng đến mức chất lượng tối thiểu, tốc độ bit được mã hoá :

KHÔNG ĐƯỢC vượt quá 15% tốc độ bit giữa các khoảng thời gian nội khung (I-frame) trong một cửa sổ trượt.
KHÔNG ĐƯỢC vượt quá 100% tốc độ bit trong khoảng thời gian 1 giây.

Nếu các phương thứ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-SR-2] KHÔNG NÊN có tốc độ bit cao hơn 15% so với tốc độ bit mục tiêu trong khoảng thời gian 1 giây.

Nếu các hoạt động triển khai thiết bị bao gồm một màn hình hiển thị nhúng có chiều dài đường chéo ít nhất là 2,5 inch hoặc bao gồm một cổng đầu ra video hoặc khai báo việc hỗ trợ camera thông qua cờ tính năng android.hardware.camera.any, thì các hoạt động triển khai đó:

[C-1-1] PHẢI hỗ trợ ít nhất một 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.
NÊN hỗ trợ cả bộ mã hoá video VP8 và H.264, đồng thời cung cấp cho các ứng dụng bên thứ ba.

Nếu các hoạt động 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 cho các ứng dụng bên thứ ba, thì các hoạt động triển khai đó:

[C-2-1] PHẢI hỗ trợ tốc độ bit có thể định cấu hình linh hoạt.
NÊN hỗ trợ tốc độ khung hình thay đổi, trong đó bộ mã hoá video NÊN xác định thời lượng khung hình tức thời dựa trên dấu thời gian của các vùng đệm đầu vào và phân bổ vùng chứa bit dựa trên thời lượng khung hình đó.

Nếu các hoạt động 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 hoạt động triển khai đó sẽ:

NÊN hỗ trợ tốc độ bit có thể định cấu hình linh hoạt cho bộ mã hoá được hỗ trợ.

Nếu các quy trình triển khai thiết bị cung cấp bộ mã hoá hình ảnh hoặc video được tăng tốc phần cứng và hỗ trợ một hoặc nhiều camera phần cứng có thể cắm hoặc được gắn, được hiển thị thông qua các API android.camera:

[C-4-1] tất cả các bộ mã hoá hình ảnh và video tăng tốc phần cứng ĐỀU PHẢI hỗ trợ mã hoá khung hình từ(các) camera phần cứng.
NÊN hỗ trợ mã hoá khung hình từ(các) camera phần cứng thông qua tất cả bộ mã hoá video hoặc hình ảnh.

Nếu các hoạt động triển khai thiết bị cung cấp tính năng mã hoá HDR, thì:

[C-SR-1] RẤT NÊN cung cấp một 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 các ứng dụng trên 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 đó sẽ:

[C-1-1] PHẢI hỗ trợ độ phân giải QCIF (176 x 144) bằng Hồ sơ cơ sở cấp 45. Độ phân giải SQCIF là không bắt buộc.

5.2.2. H.264

Nếu các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.264, thì:

[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 (Arbitrary Slice Ordering – Sắp xếp lát tuỳ ý), FMO (Flexible Macroblock Ordering – Sắp xếp khối lớn linh hoạt) và RS (Redundant Slices – Lát dư thừa). Ngoài ra, để duy trì khả năng tương thích với các thiết bị Android khác, các bộ mã hoá KHÔNG NÊN sử dụng ASO, FMO và RS cho Hồ sơ cơ sở.
[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.
NÊN hỗ trợ Cấp 4 của Hồ sơ chính.
NÊN hỗ trợ các hồ sơ mã hoá video HD (Độ phân giải cao) như được nêu trong bảng sau.

Nếu các hoạt động triển khai thiết bị báo cáo việc hỗ trợ mã hoá H.264 cho video có độ phân giải 720p hoặc 1080p thông qua các API đa phương tiện, thì các hoạt động triển khai đó:

[C-2-1] PHẢI hỗ trợ các cấu hình 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 của 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 các hoạt động triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, thì:

[C-1-1] PHẢI hỗ trợ các cấu hình mã hoá video SD.
NÊN hỗ trợ các cấu hình 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 các dịch vụ truyền trực tuyến video trên web và hội nghị truyền hình.

Nếu các hoạt động triển khai thiết bị báo cáo khả năng hỗ trợ mã hoá VP8 cho video có độ phân giải 720p hoặc 1080p thông qua các API đa phương tiện, thì:

[C-2-1] PHẢI hỗ trợ các cấu hình 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 của 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 các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9, thì:

[C-1-2] PHẢI hỗ trợ Cấu hình 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.
NÊN hỗ trợ các cấu hình giải mã HD như trong bảng sau.
[C-SR-1] RẤT NÊN hỗ trợ các cấu hình giải mã HD như được chỉ ra 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 của 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 các hoạt động triển khai thiết bị tuyên bố hỗ trợ Cấu hình 2 hoặc Cấu hình 3 thông qua API Đa phương tiện:

Bạn KHÔNG BẮT BUỘC phải hỗ trợ định dạng 12 bit.

5.2.5. H.265

Nếu các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.265, thì:

[C-1-1] PHẢI hỗ trợ Cấu hình chính cấp 3 với độ phân giải lên đến 512 x 512.
[C-SR-1] RẤT NÊN hỗ trợ hồ sơ SD 720 x 480 và hồ sơ mã hoá HD như nêu 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 của 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

5.2.6. AV1

Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1, thì:

[C-1-1] PHẢI hỗ trợ Cấu hình chính, bao gồm cả nội dung 8 bit và 10 bit.
[C-1-2] PHẢI công bố dữ liệu hiệu suất, tức là báo cáo dữ liệu hiệu suất thông qua getSupportedFrameRatesFor() hoặc getSupportedPerformancePoints() API 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 đó vào luồng bit

Nếu bộ mã hoá AV1 được tăng tốc phần cứng, thì bộ mã hoá đó sẽ:

[C-2-1] PHẢI hỗ trợ tối đa và bao gồm cả cấu hình mã hoá HD1080p trong bảng bên dưới:

	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 của 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

5.3. Giải mã video

Nếu các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, VP9, H.264, H.265 hoặc AV1, thì:

[C-1-1] PHẢI hỗ trợ chuyển đổi tốc độ khung hình và độ phân giải video linh hoạt 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, H.265 và AV1 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 các chế độ triển khai thiết bị hỗ trợ bộ giải mã MPEG-2, thì:

[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 hoạt động triển khai thiết bị hỗ trợ bộ giải mã H.263, thì:

[C-1-1] PHẢI hỗ trợ Hồ sơ cơ sở cấp 30 (độ phân giải CIF, QCIF và SQCIF ở tốc độ 30 khung hình/giây 384 kb/giây) và cấp 45 (độ phân giải QCIF và SQCIF ở tốc độ 30 khung hình/giây 128 kb/giây).

5.3.3. MPEG-4

Nếu các thiết bị triển khai có bộ giải mã MPEG-4, thì:

[C-1-1] PHẢI hỗ trợ Cấp 3 của Hồ sơ đơn giản.

5.3.4. H.264

Nếu các chế độ triển khai thiết bị hỗ trợ bộ giải mã H.264, thì:

[C-1-1] PHẢI hỗ trợ Cấu hình chính cấp 3.1 và Hồ sơ cơ sở. Hỗ trợ ASO (Sắp xếp lát tuỳ ý), FMO (Sắp xếp linh hoạt khối lớn) và RS (Lá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ó cấu hình SD (Độ phân giải chuẩn) được liệt kê trong bảng sau và được mã hoá bằng Hồ sơ cơ sở và Cấu hình chính cấp 3.1 (bao gồm cả 720p30).
PHẢI có khả năng giải mã video có hồ sơ HD (Độ phân giải cao) như được nêu trong bảng sau.

Nếu chiều cao mà 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ác phương thức triển khai thiết bị:

[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 cấu hình 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 của video	30 fps	30 fps	60 khung hình/giây	30 khung hình/giây (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.5. H.265 (HEVC)

Nếu các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã H.265, thì:

[C-1-1] PHẢI hỗ trợ Cấp chính của Cấu hình chính cấp 3 và cấu hình giải mã video SD như được chỉ ra trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD như trong bảng sau.
[C-1-2] PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau đây 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] Các thiết bị triển khai PHẢI hỗ trợ ít nhất một trong các chế độ giải mã H.265 hoặc VP9 của các cấu hình 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 của video	30 fps	30 fps	30 fps	30/60 khung hình/giây (60 khung hình/giây^{TV có tính năng 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 các hoạt động triển khai thiết bị tuyên bố hỗ trợ một Cấu hình HDR thông qua Media API:

[C-3-1] Các hoạt động 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] Các thiết bị triển khai PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên một cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).

5.3.6. VP8

Nếu các hoạt động triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, thì:

[C-1-1] PHẢI hỗ trợ các cấu hình 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 cấu hình 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] Các chế độ triển khai thiết bị PHẢI hỗ trợ các cấu hình 720p trong bảng sau.
[C-2-2] Các thiết bị triển khai PHẢI hỗ trợ các cấu hình 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 của video	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây^{Truyền hình})	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 các chế độ triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9, thì:

[C-1-1] PHẢI hỗ trợ các cấu hình giải mã video SD như trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD như trong bảng sau.

Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP9 và một 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ư 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] Các thiết bị triển khai PHẢI hỗ trợ ít nhất một trong các chế độ giải mã VP9 hoặc H.265 của các cấu hình 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 của video	30 fps	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây^{Truyền hình có tính năng 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 các phương thức triển khai thiết bị tuyên bố hỗ trợ VP9Profile2 hoặc VP9Profile3 thông qua API đa phương tiện "CodecProfileLevel":

Bạn KHÔNG BẮT BUỘC phải hỗ trợ định dạng 12 bit.

Nếu các phương thức triển khai thiết bị tuyên bố hỗ trợ một Cấu hình HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) thông qua các API đa phương tiện:

[C-4-1] Các chế độ 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ả các hồ sơ HDR, cũng như "KEY_HDR10_PLUS_INFO" cho các hồ sơ HDR10Plus) từ ứng dụng. Các thiết bị 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] Các thiết bị triển khai PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên một cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).

5.3.8. Dolby Vision

Nếu các cách 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-1-1] PHẢI cung cấp một bộ trích xuất có khả năng 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 màn hình ngoài được kết nối thông qua một cổng đầu ra video tiêu chuẩn (chẳng hạn như 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 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ã này cho các ứng dụng bên thứ ba, thì các phương thức triển khai đó sẽ:

[C-1-1] PHẢI hỗ trợ Cấu hình chính, bao gồm cả nội dung 8 bit và 10 bit.

Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1 bằng bộ giải mã được tăng tốc phần cứng, thì các phương thức triển khai đó:

[C-2-1] PHẢI có khả năng giải mã ít nhất các cấu hình 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ó khả năng giải mã ít nhất các cấu hình 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 của 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 các hoạt động triển khai thiết bị hỗ trợ Cấu hình HDR thông qua API Đa phương tiện, thì các hoạt động này:

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

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 chúng tôi dự kiến sẽ thay đổi những yêu cầu này thành PHẢI trong Định nghĩa về khả năng tương thích cho các phiên bản trong tương lai. RẤT NÊN để các thiết bị Android hiện có và thiết bị Android mới đáp ứng những yêu cầu này (được liệt kê là NÊN), nếu không, các thiết bị đó sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

5.4.1. Thông tin về micrô và tính năng ghi âm thanh thô

Nếu các quy trình triển khai thiết bị khai báo android.hardware.microphone, thì chúng sẽ:

[C-1-1] PHẢI cho phép ghi lại nội dung âm thanh thô cho mọi luồng ĐẦU VÀO 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 Chế độ đặt sẵn đầ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ô với 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 ghi lại ở tốc độ lấy mẫu nêu trên mà không cần lấy mẫu lên.
[C-1-3] PHẢI có bộ lọc khử răng cưa thích hợp khi tốc độ lấy mẫu nêu trên được ghi lại bằng cách giảm tần số lấy mẫu.
NÊN cho phép ghi lại nội dung âm thanh thô ở chất lượng đài AM và DVD, tức 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
- Kênh: Âm thanh nổi
[C-1-4] PHẢI tuân thủ API MicrophoneInfo và điền thông tin chính xác 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 các hoạt động triển khai thiết bị cho phép bắt sóng đài AM và ghi lại nội dung âm thanh thô có chất lượng DVD, thì:
[C-2-1] PHẢI ghi lại mà không tăng tần số lấy mẫu ở bất kỳ tỷ lệ nào cao hơn 16000:22050 hoặc 44100:48000.
[C-2-2] PHẢI có bộ lọc khử răng cưa thích hợp cho mọi hoạt động lấy mẫu tăng hoặc lấy mẫu giảm.

5.4.2. Ghi âm để nhận dạng giọng nói

Nếu các quy trình triển khai thiết bị khai báo android.hardware.microphone, thì chúng sẽ:

[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, PHẢI tắt mọi quy trình xử lý âm thanh giảm tiếng ồn khi ghi lại luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
[C-1-3] Theo mặc định, PHẢI tắt mọi chế độ kiểm soát độ khuếch đại tự động khi ghi một luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
CẦN có đặc điểm biên độ so với tần số tương đối bằng phẳng trong dải tần số trung bình: cụ thể là ±3 dB từ 100 Hz đến 4000 Hz cho từng micrô được dùng để ghi nguồn âm thanh nhận dạng giọng nói.
[C-SR-1] NÊN THỂ HIỆN các mức biên độ trong dải tần số thấp: cụ thể là ±20 dB từ 30 Hz đến 100 Hz so với dải tần số trung bình cho từng micrô được dùng để ghi lại nguồn âm thanh nhận dạng giọng nói.
[C-SR-2] NÊN THỂ HIỆN 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ô được 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 hình sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 90 dB (đo bên cạnh micrô) mang lại phản hồi lý tưởng là RMS 2500 trong phạm vi từ 1770 đến 3530 cho 16 mẫu bit (hoặc -22,35 db ±3dB Full Scale cho các mẫu có độ chính xác kép/dấu phẩy động) cho từng micrô được dùng để ghi nguồn âm thanh nhận dạng giọng nói.
CẦN ghi lại 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 re 90 dB SPL tại micrô.
NÊN ghi lại luồng âm thanh nhận dạng giọng nói với tổng độ méo hài (THD) dưới 1% cho 1 kHz ở mức đầu vào 90 dB SPL tại micrô.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone và công nghệ khử (giảm) tiếng ồn được điều chỉnh để nhận dạng lời nói, thì các hoạt động triển khai đó sẽ:

[C-2-1] PHẢI cho phép điều khiển 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ệ khử tiếng ồn thông qua trường AudioEffect.Descriptor.uuid.

5.4.3. Ghi lại để chuyển hướng chế độ phát

Lớp android.media.MediaRecorder.AudioSource bao gồm nguồn âm thanh REMOTE_SUBMIX.

Nếu các phương thức triển khai thiết bị khai báo cả android.hardware.audio.output và android.hardware.microphone, thì các phương thức này:

[C-1-1] PHẢI triển khai đúng nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng dùng API android.media.AudioRecord để ghi từ nguồn âm thanh này, ứng dụng sẽ ghi lại hỗn hợp của tất 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. Thiết bị khử tiếng vọng âm thanh

Nếu các quy trình triển khai thiết bị khai báo android.hardware.microphone, thì chúng sẽ:

NÊN triển khai công nghệ Bộ khử tiếng vọng âm thanh (AEC) được điều chỉnh cho giao tiếp bằng giọng nói và áp dụng cho đường dẫn ghi khi ghi bằng AudioSource.VOICE_COMMUNICATION.

Nếu các chế độ triển khai thiết bị cung cấp một Bộ khử tiếng vọng âm thanh được chèn vào đường dẫn âm thanh ghi hình khi AudioSource.VOICE_COMMUNICATION được chọn, thì các chế độ triển khai đó:

[C-SR-1] [C-1-1] ĐƯỢC RẤT KHUYẾN KHÍCH PHẢI khai báo điều này thông qua phương thức API AcousticEchoCanceler AcousticEchoCanceler.isAvailable() trả về true.

[C-1-2] PHẢI phản ánh trạng thái bật của AEC trên đường dẫn âm thanh thông qua phương thức AcousticEchoCanceler API AcousticEchoCanceler.getEnabled(). Phương thức này phải trả về true khi hoạt động và false khi không hoạt động.

[C-SR-2] [C-SR-1] được RẤT KHUYẾN KHÍCH để cho phép kiểm soát hiệu ứng âm thanh này bằng API AcousticEchoCanceler.
[C-SR-3] [C-SR-2] được RẤT KHUYẾN KHÍCH để xác định duy nhất từng cách triển khai công nghệ AEC thông qua trường AudioEffect.Descriptor.uuid.

5.4.5. Quay video đồng thời

Nếu triển khai thiết bị khai báo android.hardware.microphone, thì các thiết bị ĐỀU 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 một dịch vụ hỗ trợ tiếp cận đang ghi hình bằng AudioSource.VOICE_RECOGNITION và ít nhất một ứng dụng đang ghi hình bằng AudioSource truy cập đồng thời vào micrô.
[C-1-2] PHẢI cho phép 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 hình bằng AudioSource (ngoại trừ AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER) truy cập đồng thời vào micrô.
[C-1-3] PHẢI tắt tiếng khi 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 bằng AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER. Tuy nhiên, khi một ứng dụng đang ghi hình 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à một ứng dụng đặc quyền (cài sẵn) có quyền CAPTURE_AUDIO_OUTPUT.
[C-1-4] Nếu có từ 2 ứng dụng trở lên đang ghi hình đồng thời và 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 hình gần đây nhất sẽ nhận được âm thanh.

5.5. Phát âm thanh

Android có 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 quy trình triển khai thiết bị khai báo android.hardware.audio.output, thì chúng sẽ:

[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: Đơn âm, â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 tại các 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 một API cho các hiệu ứng âm thanh để triển khai thiết bị.

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

[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 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, 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 thông qua lớp con AudioEffect DynamicsProcessing.
[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, khi kết quả hiệu ứng được trả về cho quy trình âm thanh của khung. Đây là hiệu ứng chèn hoặc hiệu ứng phụ điển hình, chẳng hạn như bộ cân bằng. Bạn nên sử dụng hành vi tương đương khi kết quả của hiệu ứng không xuất hiện trong quy trình âm thanh của khung, chẳng hạn như hiệu ứng hậu xử lý hoặc hiệu ứng được chuyển bớt.
[C-1-5] PHẢI đảm bảo rằng các hiệu ứng âm thanh hỗ trợ nhiều kênh (tối đa bằng số kênh của bộ trộn, còn gọi là FCC_LIMIT) khi kết quả hiệu ứng được trả về cho quy trình âm thanh của khung. Đây là hiệu ứng chèn hoặc hiệu ứng phụ điển hình, nhưng không bao gồm các hiệu ứng đặc biệt như hiệu ứng trộn kênh, tăng số kênh hoặc hiệu ứng không gian làm thay đổi số lượng kênh. Bạn nên dùng hành vi tương đương khi các hiệu ứng không xuất hiện trong quy trình âm thanh của khung, chẳng hạn như hiệu ứng hậu xử lý hoặc hiệu ứng được chuyển bớt.
NÊN hỗ trợ các phương thức 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] RẤT NÊN hỗ trợ các hiệu ứng ở dạ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ị trên ô tô:

NÊN cho phép điều chỉnh âm lượng riêng 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 các chế độ triển khai thiết bị hỗ trợ tính năng phát được chuyển tải âm thanh, thì các chế độ này:

[C-SR-1] NÊN CẮT nội dung âm thanh phát liền mạch giữa hai đoạn có cùng định dạng khi được chỉ định bằng API phát liền mạch AudioTrack và vùng chứa nội dung nghe nhìn cho MediaPlayer.
[C-SR-2] RẤT NÊN triển khai tính năng phát lại giảm tải cho các định dạng AAC, MP3, OPUS và PCM.

Nếu các phương thức triển khai thiết bị khai báo hỗ trợ giảm tải PCM MMAP (do cổng kết hợp có các cờ chứa AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD và AUDIO_OUTPUT_FLAG_MMAP_NOIRQ khai báo), thì các phương thức này:

[C-1-1] PHẢI hỗ trợ ít nhất AUDIO_FORMAT_PCM_16_BIT, ở tốc độ 44,1 kHz và 48 kHz đối với âm thanh nổi và âm thanh đơn âm.
[C-1-2] PHẢI có dung lượng bộ nhớ đệm có khả năng lưu trữ tối thiểu 5 giây âm thanh ở tốc độ 48 kHz, âm thanh nổi PCM 16 bit cho mỗi mẫu.

5.5.5. Thông số phát

Nếu các phương thức triển khai thiết bị hỗ trợ PlaybackParams API, các tham số phát:

[C-1-1] PHẢI hỗ trợ tốc độ từ 0,5 đến 2,0 với cao độ là 1,0.

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.

Để phục vụ mục đích của phần 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 truyền đến 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ị qua một cổng và có thể được quan sát từ bên ngoài.
độ trễ đầu ra lạnh. Thời gian giữa thời điểm bắt đầu một luồng đầu ra và thời gian trình chiếu của 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 không hoạt động và đã tắt nguồn trước khi 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ôi trường phát ra âm thanh 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ị qua một cổng và thời điểm ứng dụng đọc khung dữ liệu được mã hoá PCM tương ứng.
mất dữ liệu đầu vào. Phần đầu của tín hiệu đầu vào không dùng được hoặc không có sẵn.
độ trễ đầu vào nguội. Thời gian giữa lúc bắt đầu luồng 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 nguồn trước khi 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 của độ 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 có thời gian xử lý tín hiệu và thời gian 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.
AAudio native audio API. 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 hình tương đối trong một luồng và thời gian ước tính khi khung hình đó đi 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 AudioTimestamp.
glitch. 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 thiếu dữ liệu trong bộ nhớ đệm cho đầu ra, tràn bộ nhớ đệm cho đầu vào hoặc bất kỳ nguồn nào khác gây ra tạp âm kỹ thuật số hoặc tương tự.
độ lệch tuyệt đối trung bình (MAD). 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ễ từ lúc nhấn đến lúc phát ra âm thanh (TTL), được đo bằng CTS Verifier, là khoảng thời gian tính từ khi màn hình được nhấn đến khi âm thanh được tạo ra do thao tác nhấn đó được phát trên loa. Đây là giá trị trung bình của 5 phép đo bằng API âm thanh gốc AAudio cho đầu ra.
độ trễ khứ hồi (RTL), theo đo lường của CTS Verifier, là Độ trễ trung bình liên tục trong 5 lần đo, được đo trên đường dẫn vòng lặp truyền đầu ra trở lại đầu vào, bằng cách sử dụng API âm thanh gốc AAudio.

Các đường dẫn vòng lặp là:
- Loa/micrô: Loa tích hợp đến micrô tích hợp.
- Đầu vào tương tự: Giắc cắm tương tự 3,5 mm và bộ chuyển đổi vòng lặp.
- USB: Bộ chuyển đổi USB sang giắc cắm 3,5 mm và bộ chuyển đổi truyền dữ liệu hoặc giao diện âm thanh USB và cáp truyền dữ liệu.
FEATURE_AUDIO_LOW_LATENCY. Tính năng android.hardware.audio.low_latency được khai báo.
FEATURE_AUDIO_PRO. Tính năng android.hardware.audio.pro được khai báo.
MPC. Lớp hiệu suất của nội dung nghe nhìn.
độ trễ theo dõi đầu. Thời gian từ khi thiết bị đo lường quán tính (IMU) ghi lại chuyển động của đầu cho đến khi bộ chuyển đổi tai nghe phát hiện thấy sự thay đổi về âm thanh do chuyển động này gây ra.

Triển khai thiết bị:

[C-0-1] PHẢI đảm bảo rằng khi một ứng dụng gọi android.media.AudioManager.setCommunicationDevice() bằng device được hỗ trợ (chẳng hạn như tai nghe có dây, loa hoặc tai nghe tích hợp hoặc tai nghe USB), lệnh gọi lại android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() sẽ được gọi bằng thiết bị âm thanh đó trong vòng 1500 mili giây kể từ khi lệnh gọi setCommunicationDevice() trả về true.

Nếu các phương thức triển khai thiết bị khai báo android.hardware.audio.output, thì chúng PHẢI đáp ứng hoặc vượt quá các yêu cầu sau:

[C-1-1] Yêu cầu này đã bị xoá trong Android 15.
[C-1-2] Độ trễ đầu ra nguội từ 500 mili giây trở xuống.
[C-1-3] Việc mở một luồng đầu ra bằng AAudioStreamBuilder_openStream() PHẢI mất ít hơn 1000 mili giây.
[C-1-4] Độ trễ khứ hồi được tính dựa trên dấu thời gian đầu vào và đầu ra do AAudioStream_getTimestamp trả về PHẢI nằm trong khoảng 200 mili giây so với độ trễ khứ hồi đo được cho AAUDIO_PERFORMANCE_MODE_NONE và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY đối với loa, tai nghe có dây và tai nghe không dây.
[C-SR-1] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-2] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-4] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-5] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-6] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-7] Yêu cầu này đã bị xoá trong Android 15.
[C-2-1] Yêu cầu này đã bị xoá trong Android 15.

Nếu các chế độ triển khai thiết bị có android.hardware.microphone, thì các chế độ này PHẢI đáp ứng những yêu cầu sau về âm thanh đầu vào:

[C-3-1] Yêu cầu này đã bị xoá trong Android 15.
[C-3-2] Độ trễ đầu vào nguội từ 500 mili giây trở xuống.
[C-3-3] Việc mở một luồng đầu vào bằng AAudioStreamBuilder_openStream() PHẢI mất ít hơn 1000 mili giây.
[C-SR-8] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-11] Yêu cầu này đã bị xoá trong Android 15.
[C-SR-12] Yêu cầu này đã bị xoá trong Android 15.

Bảng sau đây xác định các yêu cầu đối với RTL cho việc triển khai thiết bị Cầm tay như được xác định trong 2.2.1 khai báo android.hardware.audio.output và android.hardware.microphone.

Thiết bị và Tuyên bố	RTL (mili giây)	MAD (mili giây)	Đường dẫn Loopback
Cầm tay	200	25	loa/micrô, giắc cắm 3,5 mm (nếu được hỗ trợ), USB (nếu được hỗ trợ)
MPC_C (17) trở lên	65	10	tất cả các đường dẫn dữ liệu được hỗ trợ
>= MPC_T (13) đến MPC_B (16)	80	15	ít nhất một đường dẫn
FEATURE_AUDIO_LOW_LATENCY	50	10	ít nhất một đường dẫn
FEATURE_AUDIO_PRO	25	5	ít nhất một đường dẫn
FEATURE_AUDIO_PRO	20	5	tương tự (nếu được hỗ trợ)
FEATURE_AUDIO_PRO	25	5	USB (nếu không hỗ trợ đầu ra tương tự)

Bảng sau đây xác định các yêu cầu đối với TTL cho việc triển khai thiết bị Cầm tay như được xác định trong 2.2.1 khai báo android.hardware.audio.output và android.hardware.microphone.

Thiết bị và Tuyên bố	TTL (mili giây)
Cầm tay	250
MPC_C (17) trở lên	65
>= MPC_T (13) đến MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

Nếu các hoạt động triển khai thiết bị có hỗ trợ spatial audio bằng tính năng theo dõi cử động đầu và khai báo cờ PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, thì:

[C-4-1] PHẢI có độ trễ tối đa từ tính năng theo dõi đầu đến bản cập nhật âm thanh là 300 mili giây.

5.7. Giao thức mạng

Các thiết bị triển khai 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 định dạng codec và vùng chứa mà một phương thức triển khai thiết bị bắt buộc phải hỗ trợ, phương thức triển khai thiết bị:

[C-1-1] PHẢI hỗ trợ codec 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 nghe nhìn tương ứng như trong bảng định dạng phân đoạn nội dung nghe nhìn bên dưới qua giao thức nháp Phát trực tuyến dựa trên 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. Để biết 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ệp đối chiếu	Yêu cầu về hỗ trợ codec
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 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 AAC.
AAC có khung ADTS và thẻ ID3	ISO 13818-7	Hãy 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ệp đối chiếu

Yêu cầu về hỗ trợ codec

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

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

AAC có khung ADTS và thẻ ID3

ISO 13818-7

Hãy 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ệp đối chiếu	Yêu cầu về hỗ trợ codec
H264 AVC	RFC 6184	Hãy 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	Hãy xem mục 5.1.8 để biết thông tin chi tiết về H263
H263-2000	RFC 4629	Hãy xem mục 5.1.8 để biết thông tin chi tiết về H263
AMR	RFC 4867	Hãy xem mục 5.1.3 để biết thông tin chi tiết về AMR-NB
AMR-WB	RFC 4867	Hãy xem mục 5.1.3 để biết thông tin chi tiết về AMR-WB
MP4V-ES	RFC 6416	Hãy xem mục 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	Hãy xem Luồng truyền tải MPEG-2 trong 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 các hoạt động triển khai thiết bị hỗ trợ đầu ra video an toàn và có khả năng hỗ trợ các bề mặt an toàn, thì:

[C-1-1] PHẢI khai báo việc hỗ trợ 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-2-1] PHẢI bảo mật đường liên kết bằng một cơ chế mã hoá mạnh, chẳng hạn như HDCP 2.x trở lên cho 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 triển khai đó sẽ:

[C-3-1] PHẢI hỗ trợ HDCP 1.2 trở lên cho tất cả màn hình bên ngoài được kết nối thông qua một 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 các hoạt động triển khai thiết bị báo cáo việc hỗ trợ tính năng android.software.midi thông qua lớp android.content.pm.PackageManager, thì các hoạt động này sẽ:

[C-1-1] PHẢI hỗ trợ MIDI qua tất cả các phương thức truyền tải phần cứng có khả năng MIDI mà chúng 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ợ phần mềm truyền MIDI giữa các ứng dụng (thiết bị MIDI ảo)
[C-1-3] PHẢI có libamidi.so (hỗ trợ MIDI gốc)
NÊN hỗ trợ chế độ thiết bị ngoại vi MIDI qua USB, mục 7.7

5.10. Âm thanh chuyên nghiệp

Nếu các hoạt động triển khai thiết bị báo cáo việc hỗ trợ tính năng android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager, thì các hoạt động triển khai đó:

[C-1-1] PHẢI báo cáo việc hỗ trợ tính năng android.hardware.audio.low_latency.
[C-1-2] PHẢI đáp ứng các yêu cầu về độ trễ đối với FEATURE_AUDIO_PRO như được xác định trong phần 5.6 Độ trễ âm thanh .
[C-1-3] PHẢI có(các) cổng USB hỗ trợ chế độ máy chủ USB và chế độ thiết bị 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 các yêu cầu về độ trễ âm thanh qua 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 khi khởi động nguội là 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.

Nếu các thiết bị triển khai có giắc cắm âm thanh 3,5 mm 4 cực, thì:

[C-2-2] PHẢI tuân thủ phần Quy cách thiết bị di động (giắc cắm) trong Quy cách tai nghe có dây (phiên bản 1.1).

Nếu các thiết bị triển khai bỏ qua giắc cắm âm thanh 3,5 mm có 4 đầu cắm và có(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.

5.11. Chụp ảnh cho phần Chưa xử lý

Android hỗ trợ 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 chế độ cài đặt sẵn để ghi SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Nếu các phương thức triển khai thiết bị dự định hỗ trợ nguồn âm thanh chưa qua xử lý và cung cấp nguồn này cho các ứng dụng bên thứ ba, thì:

[C-1-1] PHẢI báo cáo khả năng hỗ trợ thông qua thuộc tính android.media.AudioManagerPROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] PHẢI 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à ±10 dB từ 100 Hz đến 7000 Hz cho từng micrô được dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-3] PHẢI thể hiện mức biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 5 Hz đến 100 Hz so với dải tần số trung bình cho từng micrô được dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-4] PHẢI thể hiện mức biên độ trong dải tần số cao: cụ thể là từ ±30 dB từ 7.000 Hz đến 22 KHz so với dải tần số trung bình cho từng micrô được dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-5] PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 94 dB tạo ra phản hồi có RMS là 520 cho 16 mẫu bit (hoặc -36 dB Full Scale cho các mẫu có độ chính xác kép/dấu phẩy động) cho từng micrô được dùng để ghi nguồn âm thanh chưa xử lý.
[C-1-6] PHẢI có tỷ lệ tín hiệu trên tạp âm (SNR) từ 60 dB trở lên cho từng micrô được dùng để ghi nguồn âm thanh chưa qua xử lý. (trong khi SNR được đo bằng mức chênh lệch giữa 94 dB SPL và SPL tương đương của tạp âm, được điều chỉnh 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 90 dB SPL tại từng micrô được 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 điều chỉnh độ khuếch đại, Bộ lọc thông cao hoặc loại bỏ tiếng vọng) trong đường dẫn ngoài hệ số nhân mức để đưa mức về phạm vi mong muốn. 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ị vô hiệu hoá và thực sự không gây ra độ 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ố nhân 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 tra. Đố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 các hoạt động triển khai thiết bị khai báo android.hardware.microphone nhưng không hỗ trợ nguồn âm thanh chưa qua xử lý, thì:

[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 rằng không có sự hỗ trợ.
[C-SR-1] VẪN RẤT NÊN ĐƯỢC SỬ DỤNG để đáp ứng càng nhiều yêu cầu càng tốt đối với đường dẫn tín hiệu cho nguồn ghi âm chưa qua xử lý.

5.12. HDR Video

Android 13 hỗ trợ các công nghệ HDR như mô tả trong một tài liệu sắp ra mắt.

Định dạng pixel

Nếu một 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 để CPU đọc (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 có thể lấy mẫu 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 một 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 bề mặt đầu ra và có thể đọc được bằng CPU (đầu ra ByteBuffer).

Nếu một 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 bề mặt đầu vào và đầu vào có thể ghi bằng CPU (ImageWriter, MediaImage, ByteBuffer).

Nếu một 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 bề mặt đầ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 khác nhau.

Yêu cầu đối với tính năng chụp ảnh HDR

Đối với tất cả các bộ mã hoá video hỗ trợ các cấu hình HDR, việc 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 hình được mã hoá có thể có các pixel vượt quá mức độ chói cao nhất hoặc biểu đồ có thể không đại diện cho khung hình.
NÊN tổng hợp siêu dữ liệu động HDR để tạo siêu dữ liệu tĩnh HDR phù hợp cho các luồng được mã hoá và xuất siêu dữ liệu đó vào cuối mỗi phiên mã hoá.

Nếu các phương thức triển khai thiết bị hỗ trợ tính năng chụp HDR bằng API CamcorderProfile, thì:

[C-6-1] CŨNG 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 bằng 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à bạn phải thêm siêu dữ liệu vào luồng bit được mã hoá.
[C-6-5] PHẢI hỗ trợ P010 và COLOR_FormatYUVP010.
[C-6-6] PHẢI hỗ trợ tính năng ánh xạ tông màu từ HDR sang SDR trong bộ giải mã tăng tốc phần cứng mặc định cho hồ sơ đã ghi. Nói cách khác, nếu một thiết bị có thể ghi hình ở định dạng HDR10+ HEVC, thì bộ giải mã HEVC mặc định PHẢI có khả năng giải mã luồng đã ghi ở định dạng SDR.

Yêu cầu về việc chỉnh sửa HDR

Nếu các hoạt động triển khai thiết bị có bộ mã hoá video hỗ trợ chỉnh sửa HDR, thì:

NÊN sử dụng độ trễ tối thiểu để tạo siêu dữ liệu HDR khi không có và NÊN xử lý một cách linh hoạt các trường hợp siêu dữ liệu xuất hiện ở một số khung hình nhưng không xuất hiện ở những khung hình khác. Siêu dữ liệu này PHẢI chính xác (ví dụ: thể hiện độ chói cực đại và biểu đồ thực tế 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ả các hồ sơ HDR mà bộ mã hoá và giải mã đó quảng cáo. Nói cách khác, chúng PHẢI hỗ trợ việc tạo siêu dữ liệu HDR khi không có cho tất cả các hồ sơ HDR được hỗ trợ sử dụng siêu dữ liệu HDR.
[C-7-3] PHẢI hỗ trợ các định dạng đầu vào của bộ mã hoá video sau đây để bảo toàn hoàn toàn tín hiệu đã giải mã HDR:
- RGBA_1010102 (đã có trong đường cong truyền mục tiêu) cho cả bề mặt đầu vào và ByteBuffer và PHẢI quảng cáo hỗ trợ cho 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 khả năng hỗ trợ tiện ích OpenGL EXT_YUV_target.

Yêu cầu đối với màn hình HDR

Nếu các phương thức triển khai thiết bị nhận được nội dung vùng đệm được mã hoá bằng ADATASPACE_TRANSFER_HLG và nội dung đó được gửi đến màn hình thông qua SurfaceControl.Transaction#setBuffer, thì:

[C-8-1] PHẢI tuân theo khuyến nghị về màu trắng đồ hoạ trong BT. 2408-7 và chỉ hiển thị nội dung đó tối đa gấp 4,926 lần nội dung SDR.

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

6.1. Công cụ dành cho nhà phát triển

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ Công cụ dành cho nhà phát triển Android có trong Android SDK.
Cầu gỡ lỗi Android (adb)
[C-0-2] PHẢI hỗ trợ adb như được ghi lại trong SDK Android và các lệnh shell có trong AOSP. Nhà phát triển ứng dụng có thể dùng các lệnh này, bao gồm cả dumpsys, cmd stats và Simpleperf.
[C-0-11] PHẢI hỗ trợ lệnh shell cmd testharness. Việc nâng cấp các chế độ 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 liên tục 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 đầy đủ và cung cấp 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
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] PHẢI có trình nền adb phía thiết bị ở trạng thái không hoạt động theo mặc định và PHẢI có một 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 an toàn cho phép adb trên các máy chủ đã xác thực được biết.
[C-0-6] PHẢI cung cấp một cơ chế cho phép kết nối adb từ một máy chủ. Cụ thể:

Nếu các thiết bị triển khai không có cổng USB hỗ trợ chế độ thiết bị ngoại vi, thì:

[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 các phương thức triển khai thiết bị hỗ trợ kết nối adb với máy chủ thông qua Wi-Fi hoặc Ethernet, thì:

[C-4-1] PHẢI có phương thức AdbManager#isAdbWifiSupported() trả về true.

Nếu các phương thức triển khai thiết bị hỗ trợ kết nối adb với máy chủ thông qua Wi-Fi hoặc Ethernet và có ít nhất một camera, thì:

[C-5-1] PHẢI có phương thức AdbManager#isAdbWifiQrSupported() trả về true.
Dịch vụ Dalvik Debug Monitor (ddms)
- [C-0-7] PHẢI hỗ trợ tất cả các tính năng ddms như được ghi trong tài liệu của SDK Android. Vì ddms sử dụng adb, nên theo mặc định, hỗ trợ cho ddms PHẢI không hoạt động, nhưng PHẢI được hỗ trợ bất cứ khi nào người dùng đã kích hoạt Android Debug Bridge, như trên.
SysTrace
- [C-0-9] PHẢI hỗ trợ công cụ systrace như được ghi lại 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] NÊN CUNG CẤP một tệp nhị phân /system/bin/perfetto cho người dùng shell mà dòng lệnh tuân thủ tài liệu 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 SỬ DỤNG tệp nhị phân perfetto để ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ lược đồ được xác định trong tài liệu perfetto.
- [C-SR-4] RẤT 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.
Mô đun 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 ứng dụng bị Low Memory Killer (Trình huỷ ứng dụng khi bộ nhớ thấp) chấm dứt.
Chế độ khai thác kiểm thử

Nếu các chế độ triển khai thiết bị hỗ trợ lệnh shell cmd testharness và chạy cmd testharness enable, thì:
- [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 về hoạt động của GPU

Triển khai thiết bị:
- [C-0-13] PHẢI triển khai lệnh shell dumpsys gpu --gpuwork để hiển thị dữ liệu tổng hợp về hoạt động của GPU do điểm theo dõi power/gpu_work_period của nhân trả về hoặc không hiển thị dữ liệu nếu điểm theo dõi không được hỗ trợ. Phương thức triển khai AOSP là frameworks/native/services/gpuservice/gpuwork/.

Nếu các hoạt động 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 hoạt động triển khai đó:

[C-1-1] PHẢI cung cấp một cơ chế để 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 liệt kê các lớp trong những thư viện do các công cụ bên ngoài cung cấp (tức là không thuộc 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() khi các lớp gỡ lỗi GPU được bật.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_frequency thành true, thì các hoạt động này:

[C-6-1] PHẢI báo cáo một điểm theo dõi Tần suất GPU theo quy định của định dạng power/gpu_frequency, như được xác định trong power.proto.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_counters thành true, thì các hoạt động này:

[C-7-1] PHẢI cung cấp một trình tạo dữ liệu Perfetto cho một nguồn dữ liệu có tên là gpu.counters, có thể truy vấn bằng cách sử dụng: perfetto --query.
[C-7-2] PHẢI báo cáo nội dung mô tả về bộ đếm GPU theo proto gói dấu vết bộ đếm GPU.
[C-7-3] PHẢI báo cáo các giá trị phù hợp cho bộ đếm GPU của thiết bị theo giao thức gói dấu vết bộ đếm GPU.
[C-7-4] PHẢI ghi lại nội dung mô tả văn bản cho tất cả các Bộ đếm GPU đã bật mà không có dấu thời gian vào dấu vết perfetto.
[C-7-6] PHẢI cung cấp một nhóm bộ đếm hiệu suất GPU mặc định có dữ liệu để lập hồ sơ, như được chỉ định trong GpuCounterSpec#select_by_default.
- Bạn CẦN có thể bật tất cả các bộ đếm mặc định này cùng một lúc.
- Tất cả các giá trị này ĐỀU PHẢI phát ra giá trị cho Perfetto khi được bật.
[C-7-7] PHẢI phản ánh mức sử dụng GPU cho ít nhất một bộ đếm được chọn theo mặc định, bằng cách sử dụng GpuCounterSpec#select_by_default.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_counters.period thành true, thì các hoạt động này:

[C-8-1] PHẢI tuân thủ counter_period_ns đối với tốc độ lấy mẫu bộ đếm GPU. Tốc độ lấy mẫu được hỗ trợ PHẢI là 1 mili giây hoặc nhanh hơn.
[C-SR-1] RẤT NÊN hỗ trợ tốc độ lấy mẫu từ 0,2 mili giây trở lên.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_counters.groups thành true, thì các hoạt động này sẽ:

[C-9-1] PHẢI có ít nhất một bộ đếm trong mỗi nhóm bộ đếm GPU sau đây, như được chỉ định bởi GpuCounterSpec: COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES và VERTICES.

Nếu các phương thức triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_counters.groups thành true, đồng thời thiết bị hỗ trợ tính năng dò tia, thì:

[C-10-1] PHẢI có một bộ đếm trong nhóm RAY_TRACING.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.gpu_counters.zeroes_optimization thành true, thì các hoạt động này:
[C-11-1] Trong cùng một phiên theo dõi Perfetto, các bộ đếm GPU CHỈ ĐƯỢC báo cáo các giá trị bằng 0 nếu giá trị được báo cáo trước đó hoặc sau đó khác 0.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.render_stages thành true, thì các hoạt động này:

[C-12-1] PHẢI cung cấp một trình tạo dữ liệu Perfetto cho một nguồn dữ liệu có tên là gpu.renderstages, có thể truy vấn bằng perfetto --query.
[C-12-2] PHẢI báo cáo các giá trị tuân thủ cho các giai đoạn kết xuất GPU theo GPU render stage event proto.

Nếu các hoạt động triển khai thiết bị đặt cả hai thuộc tính hệ thống graphics.gpu.profiler.support và graphics.gpu.profiler.support.render_stages.queue_submit thành true, thì các hoạt động này:

[C-13-1] Đối với mỗi lệnh gọi gửi hàng đợi Vulkan, TRÌNH ĐIỀU KHIỂN Vulkan PHẢI phát ra một sự kiện theo dõi Perfetto theo quy cách thông báo sự kiện API Vulkan.
- Sự kiện này PHẢI chứa một submission_id riêng biệt, tăng đơn điệu và khớp với submission_id trong sự kiện giai đoạn kết xuất GPU tương ứng.

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 quá trình phát triển ứng dụng.

Các hoạt động triển khai thiết bị PHẢI mang đến trải nghiệm nhất quán cho phần Tuỳ chọn cho nhà phát triển, cụ thể:

[C-0-1] PHẢI tuân theo ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiện các chế độ cài đặt liên quan đến hoạt động phát triển ứng dụng. Theo mặc định, chế độ triển khai Android nguồn mở sẽ ẩn trình đơn Tùy chọn cho nhà phát triển và cho phép người dùng chạy trình đơn này sau khi nhấn 7 lần vào mục trong 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 một ứng dụng khác để bật Tùy chọn cho nhà phát triển. PHẢI cung cấp một tài liệu hoặc trang web công khai mô tả cách bật Chế độ nhà phát triển. Bạn PHẢI có thể liên kết tài liệu hoặc trang web này 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 Chế độ 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.
MAY 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 này để tránh gây xao nhãng trong các trường hợp mà sự an toàn của người dùng là mối lo ngại.

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] Quá trình 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] Bạn VẪN PHẢI trình bày đầy đủ các định nghĩa lớp (theo tài liệu của SDK) 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 các thao tác không có hiệu lực theo một cách hợp lý nào đó.
[C-0-4] Các phương thức API PHẢI trả về giá trị rỗng khi được phép theo tài liệu SDK.
[C-0-5] Các phương thức API PHẢI trả về các cách 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] Các phương thức API KHÔNG ĐƯỢC gửi ra các ngoại lệ không được ghi lại trong tài liệu SDK.
[C-0-7] Các hoạt động triển khai thiết bị PHẢI báo cáo nhất quán thông tin chính xác về cấu hình phần cứng 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 số của phiên bản.

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, bạn phải triển khai các API này dưới dạng các thao tác không hoạt động hợp lý.

7.1. Màn hình và đồ hoạ

Android có các cơ chế tự động điều chỉnh tài sản ứng dụng và bố cục giao diện người dùng một cách phù hợp cho 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 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 triển khai tất cả các hành vi và API được mô tả trong Nhà phát triển Android – Tổng quan về khả năng tương thích với 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 bổ sung dành riêng cho loại thiết bị được ghi lại trong mục 2 của CDD này.

Triển khai thiết bị:

[C-0-1] Theo mặc định, CHẮC CHẮN chỉ kết xuất các ứng dụng bên thứ ba trên những màn hình tương thích với Android.

Các đơn vị được tham chiếu theo các 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.
mật độ. Số lượng pixel được bao gồm trong một khoảng tuyến tính theo chiều ngang hoặc chiều dọc là 1", được biểu thị bằng số pixel trên mỗi inch (ppi hoặc dpi). Khi các giá trị ppi và dpi được liệt kê, cả dpi theo chiều ngang và chiều dọc đều phải nằm trong phạm vi được liệt kê.
tỷ lệ khung hình. Tỷ lệ giữa số pixel của chiều dài và chiều rộng của màn hình. Ví dụ: màn hình có kích thước 480 x 854 pixel sẽ có tỷ lệ khung hình là 854 / 480 = 1, 779, tức là khoảng "16:9".
pixel không phụ thuộc vào mật độ (dp). Một đơn vị pixel ảo được chuẩn hoá thành mật độ màn hình là 160. Đối với một số mật độ d và số lượng pixel p, số lượng pixel không phụ thuộc vào mật độ dp được tính như sau: 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 bằng SCREENLAYOUT_SIZE_MASK và Configuration.smallestScreenWidthDp.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo đúng kích thước bố cục cho Configuration.screenLayout như được xác định trong tài liệu SDK Android. Cụ thể, các phương thức triển khai thiết bị PHẢI báo cáo đúng kích thước màn hình pixel không phụ thuộc vào mật độ (dp) logic như sau:
- 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ủ chính xác thông tin hỗ trợ đã nêu của ứng dụng đối với kích thước màn hình 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 có các góc bo tròn.

Nếu các chế độ triển khai thiết bị hỗ trợ màn hình có thể có cấu hình kích thước UI_MODE_TYPE_NORMAL và sử dụng(các) màn hình thực có góc bo tròn để kết xuất các màn hình này, thì các chế độ triển khai đó:

[C-1-1] PHẢI đảm bảo rằng mỗi màn hình như vậy đáp ứng ít nhất một trong các yêu cầu sau:
- Bán kính của các góc bo tròn nhỏ hơn hoặc bằng 38 dp.
- Khi một hộp có kích thước 18 dp x 18 dp được cố định ở mỗi góc của màn hình hiển thị logic, ít nhất một pixel của mỗi hộp sẽ xuất hiện trên màn hình.
NÊN có khả năng tương tác của người dùng để chuyển sang chế độ hiển thị có các góc hình chữ nhật.

Nếu các hoạt động triển khai thiết bị chỉ có thể sử dụng cấu hình bàn phím NO_KEYS và dự định báo cáo việc hỗ trợ cấu hình chế độ giao diện người dùng UI_MODE_TYPE_NORMAL, thì các hoạt động triển khai đó:

[C-4-1] PHẢI có kích thước bố cục (không bao gồm mọi vết cắt trên màn hình) tối thiểu là 596 dp x 384 dp hoặc lớn hơn.

Để biết thông tin chi tiết về cách triển khai chính xác các API tiện ích hoặc sidecar, hãy tham khảo tài liệu công khai của Jetpack Trình quản lý cửa sổ.

[C-4-1] Yêu cầu này đã bị xoá trong Android 15.

7.1.1.2. Tỷ lệ khung hình màn hình

Phần này đã bị xoá trong Android 14.

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 các mật độ logic tiêu chuẩn để giúp nhà phát triển ứng dụng nhắm đến các tài nguyên ứng dụng.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo một trong các mật độ khung hình Android có trong DisplayMetrics thông qua API DENSITY_DEVICE_STABLE và giá trị này phải là giá trị tĩnh cho mỗi màn hình thực. Tuy nhiên, thiết bị CÓ THỂ báo cáo một 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 hiển thị) được đặt sau lần khởi động ban đầu.
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ẽ ánh xạ đến các phép đo trường nhìn góc tương đương của thiết bị cầm tay.

Nếu các hoạt động triển khai thiết bị cung cấp một thành phần để thay đổi kích thước hiển thị của thiết bị, thì:

[C-1-1] KHÔNG ĐƯỢC tăng tỷ lệ hiển thị lên hơn 1,5 lần DENSITY_DEVICE_STABLE hoặc tạo ra kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320 dp (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] KHÔNG ĐƯỢC thu nhỏ màn hình xuống dưới 0,85 lần DENSITY_DEVICE_STABLE.
Để đảm bảo khả năng sử dụng tốt và cỡ chữ nhất quán, bạn NÊN cung cấp các lựa chọn điều chỉnh tỷ lệ sau cho 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ố hiển thị

Nếu các chế độ 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 chế độ triển khai đó:

[C-1-1] PHẢI báo cáo các giá trị chính xác cho tất cả chỉ số hiển thị tương thích với Android được xác định trong API android.util.DisplayMetrics.

Nếu các chế độ triển khai thiết bị không có màn hình nhúng hoặc đầu ra video, thì:

[C-2-1] PHẢI báo cáo các giá trị chính xác 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 thiết bị:

[C-0-1] PHẢI báo cáo những hướng màn hình mà họ 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 với hướng 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 giá trị chính xác 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ác chế độ triển khai thiết bị hỗ trợ cả hai hướng màn hình, thì:

[C-1-1] Yêu cầu này đã bị xoá trong Android 16.
[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 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ả cá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 các hoạt động triển khai thiết bị có màn hình hoặc đầu ra video, thì:

[C-1-1] PHẢI hỗ trợ OpenGL ES 1.1, 2.0, 3.0 và 3.1, như được thể hiện và trình bày chi tiết trong tài liệu SDK Android.
[C-SR-1] Yêu cầu này đã bị xoá trong Android 15.
NÊN hỗ trợ OpenGL ES 3.2.

Các kiểm thử dEQP OpenGL ES được phân vùng thành một số danh sách kiểm thử, mỗi danh sách có một ngày/số phiên bản được 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-master-YYYY-MM-DD.txt. Một 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ở về trước.

Nếu các hoạt động triển khai thiết bị hỗ trợ bất kỳ phiên bản OpenGL ES nào, thì:

[C-2-1] PHẢI báo cáo thông qua API được quản lý OpenGL ES và API gốc 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 các 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 kiểm thử 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 (từ ngày 1 tháng 3 năm 2020) như được 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 Kiểm thử dEQP OpenGL ES trong danh sách kiểm thử từ phiên bản 132383489 đến phiên bản được chỉ định trong cờ tính năng android.software.opengles.deqp.level, cho từng phiên bản OpenGL ES được hỗ trợ.
[C-SR-2] BẠN NÊN hỗ trợ các tiện ích EGL_KHR_partial_update và OES_EGL_image_external.
NÊN 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.
NÊN hỗ trợ các tiện ích EGL_IMG_context_priority và EGL_EXT_protected_content.

Nếu các hoạt động triển khai thiết bị khai báo hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2, thì:

[C-3-1] PHẢI xuất các biểu tượng hàm tương ứng cho những phiên bản này ngoài các biểu tượng hàm OpenGL ES 2.0 trong thư viện libGLESv2.so.
[C-SR-3] RẤT NÊN hỗ trợ tiện ích OES_EGL_image_external_essl3.

Nếu các hoạt động triển khai thiết bị hỗ trợ OpenGL ES 3.2, thì:

[C-4-1] PHẢI hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES.

Nếu các phương thức triển khai thiết bị hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES, thì các phương thức triển khai đó sẽ:

[C-5-1] PHẢI xác định hoạt động hỗ trợ thông qua cờ tính năng android.hardware.opengles.aep.

Nếu các quy trình triển khai thiết bị hỗ trợ tiện ích EGL_KHR_mutable_render_buffer, thì các quy trình này sẽ:

[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 đa nền tảng có mức hao tổn thấp dành cho đồ hoạ 3D hiệu suất cao.

Nếu các hoạt động triển khai thiết bị hỗ trợ OpenGL ES 3.1, thì:

[C-SR-1] RẤT NÊN CÓ hỗ trợ cho 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 các hoạt động triển khai thiết bị có màn hình hoặc đầu ra video, thì:

[C-SR-2] RẤT NÊN CÓ hỗ trợ cho Vulkan 1.3.

Các kiểm thử dEQP của Vulkan được phân vùng 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 được 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-master-YYYY-MM-DD.txt. Một thiết bị hỗ trợ Vulkan ở 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 tra dEQP trong tất cả danh sách kiểm thử từ cấp độ này trở xuống.

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

[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 đủ API Vulkan 1.1 cho từng VkPhysicalDevice được liệt kê.
[C-1-4] PHẢI liệt kê các lớp, có trong các 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 các 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 , ngoại trừ các lớp OEM và Nền tảng theo tài liệu Triển khai Vulkan.

[C-1-6] PHẢI báo cáo tất cả các chuỗi tiện ích mà chúng hỗ trợ thông qua API gốc Vulkan và ngược lại , KHÔNG ĐƯỢC báo cáo các chuỗi tiện ích mà chúng không hỗ trợ đúng cách.

[C-1-7] PHẢI hỗ trợ các tiện ích sau:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] PHẢI báo cáo phiên bản tối đa của Kiểm thử dEQP Vulkan đượ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 (từ ngày 1 tháng 3 năm 2019) như được 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ử dEQP của Vulkan 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ê sự 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] RẤT NÊN hỗ trợ các phần mở rộng sau:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] KHÔNG ĐƯỢC liệt kê sự hỗ trợ cho tiện ích VK_KHR_performance_query.
[C-SR-4] RẤT NÊN đáp ứng các yêu cầu do Hồ sơ cơ sở Android 2022 quy định.
[C-SR-5] RẤT 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.

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

[C-SR-8] KHÔNG NÊN sửa đổi trình tải Vulkan.
[C-1-14] KHÔNG ĐƯỢC liệt kê các tiện ích Thiết bị Vulkan thuộc loại "KHR", "GOOGLE" hoặc "ANDROID" trừ phi các tiện ích này có trong cờ tính năng android.software.vulkan.deqp.level.

Nếu các hoạt động triển khai thiết bị không hỗ trợ Vulkan 1.0, thì:

[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 các phương thức triển khai thiết bị có 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 trở lên, thì:

[C-3-1] PHẢI cung cấp khả năng hỗ trợ cho các loại semaphore và xử lý bên ngoài SYNC_FD và tiện ích VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] NÊN CẬP NHẬT VK_KHR_external_fence_fd để các ứng dụng bên thứ ba có thể sử dụng tiện ích này và cho phép ứng dụng xuất tải trọng hàng rào sang cũng như nhập tải trọng hàng rào từ các bộ mô tả tệp POSIX như mô tả tại đây.

7.1.4.3. RenderScript

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ Android RenderScript, như được nêu chi tiết trong tài liệu về 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ẻ kê khai android:hardwareAccelerated hoặc các lệnh gọi API trực tiếp.

Triển khai thiết bị:

[C-0-1] PHẢI bật chế độ tăng tốc phần cứng theo mặc định và PHẢI tắt chế độ 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 chế độ tăng tốc phần cứng trực tiếp thông qua API Android View.
[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 có một đối tượng TextureView cho phép nhà phát triển tích hợp trực tiế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 một hệ phân cấp giao diện người dùng.

Triển khai 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 việc triển khai Android nguồn.

7.1.4.5. Màn hình có 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 có gam màu rộng thông qua Configuration.isScreenWideColorGamut(), thì:

[C-1-1] PHẢI có màn hình được hiệu chỉnh màu sắc.
[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 CIE 1931 xyY.
[C-1-3] PHẢI có màn hình có gam màu chiếm ít nhất 90% DCI-P3 trong không gian CIE 1931 xyY.
[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 việc hỗ trợ các 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] RẤT NÊN HỖ TRỢ GL_EXT_sRGB.

Ngược lại, nếu các hoạt động triển khai thiết bị không hỗ trợ màn hình có gam màu rộng, thì:

[C-2-1] PHẢI bao phủ từ 100% trở lên sRGB trong không gian CIE 1931 xyY, mặc dù gam 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) vì lợi ích của 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 độc lập về 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ạ phong phú cho màn hình tương thích với Android. Các 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 một thiết bị triển khai:

[C-0-1] PHẢI có khả năng kết xuất đồ hoạ 16 bit.
NÊN hỗ trợ màn hình có khả năng hiển thị đồ hoạ 24 bit.
[C-0-2] PHẢI có khả năng hiển thị ảnh động.
[C-0-3] PHẢI có tỷ lệ khung hình (PAR) từ 0,9 đến 1,15. Tức là tỷ lệ khung hình bằng pixel PHẢI gần với tỷ lệ khung hình vuông (1.0) với dung sai từ 10 đến 15%.

7.1.7. Màn hình phụ

Android hỗ trợ màn hình phụ tương thích với Android để cho phép các chức năng chia sẻ nội dung nghe nhìn và API nhà phát triển để truy cập vào màn hình ngoài.

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

[C-1-1] PHẢI triển khai dịch vụ hệ thống DisplayManager và API như mô tả trong tài liệu về SDK Android.

7.2. Thiết bị Đầu vào

Triển khai thiết bị:

[C-0-1] PHẢI có một cơ chế nhập, chẳng hạn như màn hình cảm ứng hoặc thao tác điều hướng không cảm ứng, để di chuyển giữa các phần tử trên giao diện người dùng.

7.2.1. Bàn phím

Nếu các hoạt động triển khai thiết bị 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 ứng dụng này phải:

[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 thiết bị:

[C-0-1] KHÔNG ĐƯỢC có 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 cách triển khai bàn phím phần 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ợ d-pad, bi xoay và bánh xe dưới dạng cơ chế điều hướng không cảm ứng.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo đúng giá trị cho android.content.res.Configuration.navigation.

Nếu các chế độ triển khai thiết bị thiếu chế độ thao tác không chạm, thì:

[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 ở thượng nguồn bao gồm một cơ chế lựa chọn phù hợp để sử dụng với những thiết bị không có các phương thức nhập không cảm ứng.

7.2.3. Các phím điều hướng

Các chức năng Màn hình chính, Gần đây và 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, là những chức năng thiết yếu đối với mô hình điều hướng của Android và do đó, việc triển khai thiết bị:

[C-0-1] PHẢI cung cấp cho người dùng một phương thức để chạy các ứng dụng đã cài đặt có hoạt động được đặt bằng <intent-filter> với ACTION=MAIN và CATEGORY=LAUNCHER hoặc CATEGORY=LEANBACK_LAUNCHER cho các hoạt động triển khai trên thiết bị truyền hình. Chức năng Trang chủ PHẢI là cơ chế cho sự hỗ trợ này của người dùng.
NÊN cung cấp các nút cho chức năng Gần đây và Quay lại.

Nếu cung cấp các chức năng Màn hình chính, Gần đây hoặc Quay lại, thì các chức năng này:

[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ố đó.
[C-1-2] PHẢI cho biết rõ hành động duy nhất nào sẽ kích hoạt từng chức năng. Ví dụ về chỉ báo như vậy là có biểu tượng hữu hình được in 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 từng bước trong quy trình minh hoạ có hướng dẫn trong trải nghiệm thiết lập ban đầu.

Triển khai thiết bị:

[C-SR-1] KHÔNG NÊN cung cấp cơ chế nhập cho chức năng Trình đơn vì chức năng này đã ngừng hoạt động để chuyển sang thanh thao tác kể từ Android 4.0.
[C-SR-2] RẤT NÊN cung cấp tất cả các chức năng điều hướng dưới dạng có thể huỷ. "Có thể huỷ" được định nghĩa là khả năng ngăn người dùng thực thi chức năng điều hướng (ví dụ: chuyển đến màn hình chính, quay lại, v.v.) nếu thao tác vuốt không được thả qua một ngưỡng nhất định.

Nếu triển khai chức năng Trình đơn, thì các thiết bị sẽ:

[C-2-1] PHẢI hiển thị nút trình đơn mục bổ sung bất cứ khi nào cửa sổ bật lên của trình đơn mục bổ sung 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 chứa các thao tác bổ sung do người dùng chọn nút trình đơn trong thanh thao tác, nhưng CÓ THỂ hiển thị cửa sổ bật lên chứa các thao tác bổ sung ở một vị trí đã sửa đổi trên màn hình khi người dùng chọn chức năng Trình đơn.

Nếu các hoạt động triển khai thiết bị không cung cấp chức năng Trình đơn, thì để tương thích ngược, các hoạt động triển khai này 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, bằng nút vật lý, khoá phần mềm hoặc cử chỉ. Người dùng 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 các hoạt động triển khai thiết bị cung cấp chức năng Trợ lý, thì:

[C-4-1] PHẢI cho phép truy cập vào chức năng Trợ lý bằng một thao tác (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] RẤT NÊN dùng chức năng nhấn và giữ trên nút HOME làm thao tác tương tác được chỉ định này.

Nếu các chế độ 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-5-1] Các phím điều hướng PHẢI sử dụng một phần riêng biệt trên màn hình, không dành cho các ứ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 các ứng dụng.
[C-5-2] PHẢI cung cấp một phần màn hình cho những ứ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 lại trong SDK.

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() CHỈ được dùng để báo cáo vùng nhận dạng cử chỉ 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 ở nền trước cung cấp thông qua View#setSystemGestureExclusionRects(), nhưng nằm ngoài WindowInsets#getMandatorySystemGestureInsets(), KHÔNG ĐƯỢC phép chặn chức năng điều hướng miễn là hình chữ nhật loại trừ được phép nằm trong giới hạn loại trừ tối đa như được chỉ định trong tài liệu cho 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 khi các thao tác chạm bắt đầu bị chặn đối với 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 một phương thức để chuyển sang chế độ thao tác bằng 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ừ mép 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 dưới dạng thao tác 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 chịu ảnh hưởng của các hình chữ nhật loại trừ do ứng dụng nền trước cung cấp thông qua View#setSystemGestureExclusionRects().

Nếu một chức năng điều hướng được cung cấp từ bất kỳ vị trí nào ở cạnh trái và cạnh phải của hướng hiện tại của màn hình:

[C-7-1] Chức năng đ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à cạnh phải của 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 tuỳ chỉnh có thể vuốt được nằm ở cạnh trái hoặc cạnh phải, thì các bảng điều khiển này PHẢI được đặt trong 1/3 trên cùng của màn hình, đồng thời có một chỉ báo trực quan rõ ràng và liên tục cho biết rằng thao tác kéo vào sẽ gọi các bảng điều khiển nêu trên, do đó không phải là thao tác Quay lại. Người dùng CÓ THỂ định cấu hình một bảng điều khiển hệ thống sao cho bảng điều khiển đó nằm bên 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 quá 1/3(các) cạnh.
[C-7-3] Khi ứng dụng trên nền trước có một trong 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 được đặt, 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ó một trong 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 được đặt, các bảng hệ thống có thể vuốt tuỳ chỉnh PHẢI bị ẩn cho đến khi người dùng đưa vào hoặc bỏ làm mờ các thanh hệ thống (còn gọi là thanh điều hướng và thanh trạng thái) như được triển khai trong AOSP.

Nếu chức năng điều hướng quay lại được cung cấp 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] Bạn KHÔNG ĐƯỢC gửi sự kiện KEYCODE_BACK.

Nếu chức năng điều hướng quay lại được cung cấp nhưng ứng dụng trên nền trước KHÔNG có OnBackInvokedCallback đã đăng ký, thì:

Hệ thống PHẢI cung cấp một ảnh động cho ứng dụng ở nền trước để cho thấy rằng người dùng đang quay lại, như được cung cấp trong AOSP.

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

[C-9-1] PHẢI hỗ trợ các biểu tượng phù hợp với trẻ em hoặc chế độ thao tác 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 giả lập thao tác chạm. Việc 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ột màn hình sao cho người dùng có cảm giác như đang 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 chạm trực tiếp vào màn hình, hệ thống không yêu cầu bất kỳ thành phần bổ sung nào để cho biết các đối tượng đang được thao tác.

Triển khai thiết bị:

NÊN có một hệ thống nhập bằng con trỏ nào đó (tương tự như chuột hoặc cảm ứng).
NÊN hỗ trợ các con trỏ được theo dõi hoàn toàn độc lập.

Nếu các hoạt động triển khai thiết bị có màn hình cảm ứng (một điểm chạm trở lên) trên màn hình chính tương thích với Android, thì các hoạt động này:

[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ác cờ tính năng android.hardware.touchscreen và android.hardware.faketouch.

Nếu các hoạt động triển khai thiết bị có màn hình cảm ứng có thể theo dõi nhiều thao tác chạm trên một màn hình chính tương thích với Android, thì các hoạt động đó:

[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 các hoạt động 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 bi xoay (tức là không chạm trực tiếp vào màn hình) để nhập dữ liệu 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-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] CHỈ ĐƯỢC 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. Thao tác nhập bằng cách chạm giả

Giao diện cảm ứng giả cung cấp một hệ thống hoạt động đầu vào của người dùng mô phỏng 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 di chuyển con trỏ trên màn hình gần giống với thao tác chạm, nhưng yêu cầu người dùng phải trỏ hoặc lấy tiêu điểm rồi nhấp vào. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột trên không 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 đa điểm có thể hỗ trợ các hoạt động tương tác cảm ứng giả. Android có hằng số tính năng android.hardware.faketouch, tương ứng với một thiết bị đầu vào có độ trung thực cao không cảm ứng (dựa trên con trỏ) như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ hoạt động đầu vào dựa trên thao tác chạm (bao gồm cả chế độ 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 các chế độ triển khai thiết bị không có màn hình cảm ứng nhưng có một hệ thống đầu vào bằng con trỏ khác mà họ muốn cung cấp, thì họ:

NÊN khai báo hỗ trợ cho 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-1-1] PHẢI báo cáo vị trí X và Y tuyệt đối trên màn hình của vị trí con trỏ và hiển thị con trỏ trực quan trên màn hình.
[C-1-2] PHẢI báo cáo sự kiện chạm bằng mã thao tác 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ợ thao tác nhấn và nhấc con trỏ 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ợ thao tác 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ợ thao tác nhấn con trỏ vào một điểm bất kỳ trên màn hình, di chuyển con trỏ đến một điểm bất kỳ khác trên màn hình, sau đó nhấc con trỏ lên. Thao tác này cho phép người dùng mô phỏng thao tác kéo bằng cách chạm.
[C-1-6] PHẢI hỗ trợ thao tác nhấn con trỏ xuống, sau đó cho phép người dùng nhanh chóng di chuyển đối tượng đến một vị trí khác trên màn hình rồi nhả con trỏ lên màn hình, thao tác này 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-2-1] PHẢI khai báo việc hỗ trợ android.hardware.faketouch.
[C-2-2] PHẢI hỗ trợ việc theo dõi riêng biệt từ 2 hoặc nhiều thiết bị đầ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-3-1] PHẢI khai báo hỗ trợ cho android.hardware.faketouch.
[C-3-2] PHẢI hỗ trợ việc theo dõi riêng biệt 5 (theo dõi một bàn tay có các ngón tay) hoặc nhiều con trỏ đầu vào 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 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 bên dưới. Việc triển khai Android ở nguồn trên đáp ứng yêu cầu này.

Nếu các hoạt động triển khai thiết bị nhúng một bộ điều khiển hoặc đi kèm với một bộ điều khiển riêng biệt trong hộp, thì bộ điều khiển đó sẽ cung cấp phương tiện để nhập tất cả các sự kiện được liệt kê trong các bảng bên dưới:

[C-2-1] PHẢI khai báo cờ tính năng android.hardware.gamepad

Nút	HID Usage²	Nút Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Nút chuyển lên trên trên D-pad¹ Nút chuyển xuống dưới trên D-pad¹	0x01 0x0039³	AXIS_HAT_Y⁴
Nút chuyển sang trái trên D-pad1 Nút chuyển sang phải trên D-pad¹	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ấn cần điều khiển trái¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Nhấn cần điều khiển phải¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Quay lại¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Các cách sử dụng HID nêu trên phải được khai báo trong CA Gamepad (0x01 0x0005).

3 Mức sử dụng này phải có Giá trị tối thiểu logic là 0, Giá trị tối đa logic 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ị tính bằng độ và Kích thước báo cáo là 4. Giá trị logic được xác định là hướng xoay theo chiều kim đồng hồ ra khỏi trục dọc; ví dụ: giá trị logic 0 biểu thị không xoay và nút lên đang được nhấn, trong khi giá trị logic 1 biểu thị hướng xoay 45 độ và cả phím lên và phím trái đều đang được nhấn.

4 MotionEvent

Nút điều khiển tương tự¹	Mức sử dụng HID	Nút Android
Nút kích hoạt bên trái	0x02 0x00C5	AXIS_LTRIGGER
Nút cò 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 cụ thể đối với từng thiết bị.

7.3. Cảm biến

Nếu các quy trình triển khai thiết bị có 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ì quy 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ề Android mã nguồn mở liên quan đến cảm biến.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo chính xác sự hiện diện hoặc không hiện diện của các 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ý cho 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 các 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, thì:

[C-1-1] PHẢI báo cáo tất cả các phép đo của cảm biến bằng cách sử dụng các giá trị thích hợp theo Hệ đo lường quốc tế (hệ mét) cho từng loại cảm biến như được xác định trong tài liệu SDK Android.
[C-1-2] PHẢI báo cáo dữ liệu cảm biến với độ trễ tối đa là 100 mili giây + 2 * sample_time trong trường hợp luồng cảm biến có độ trễ tối đa được yêu cầu là 0 mili giây 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 * sample_time kể từ khi cảm biến được kích hoạt. Mẫu này có thể có độ chính xác là 0.
[C-1-4] Đối với mọi API được tài liệu SDK Android chỉ định là cảm biến liên tục, các hoạt động triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ CÓ ĐỘ DAO ĐỘNG DƯỚI 3%, trong đó độ dao động được xác định là độ lệch chuẩn của sự khác biệt về 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 của thiết bị chuyển sang trạng thái tạm ngưng hoặc thức dậy từ trạng thái tạm ngưng.
[C-1-6] PHẢI báo cáo thời gian của sự kiện tính bằng nano giây như được xác định trong tài liệu về SDK Android, thể hiện thời gian xảy ra sự kiện 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 một số cảm biến được kích hoạt, mức tiêu thụ điện KHÔNG ĐƯỢC vượt quá tổng mức tiêu thụ điện mà từng cảm biến riêng lẻ báo cáo.

Danh sách trên chưa đầy đủ; hành vi được ghi lại 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 các 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, thì:

[C-1-6] PHẢI đặt độ phân giải khác 0 cho tất cả cá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à cảm biến tổng hợp, tức là 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 thiết bị:

NÊN triển khai các loại cảm biến này khi chúng bao gồm các cảm biến thực tế tiên quyết như mô tả trong các loại cảm biến.

Nếu các hoạt động triển khai thiết bị có một cảm biến tổng hợp, thì:

[C-2-1] PHẢI triển khai cảm biến như mô tả trong tài liệu Nguồn mở Android về cảm biến tổng hợp.

Nếu các 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ì các 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 các hoạt động 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 được cung cấp cho 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 các hoạt động triển khai thiết bị bao gồm sự kết hợp giữ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] RẤT NÊN dùng để đảm bảo gia tốc kế, con quay hồi chuyển và từ kế có vị trí tương đối cố định, sao cho nếu thiết bị có thể biến đổi (ví dụ: có thể gập lại), thì 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 có thể có của thiết bị.

7.3.1. Gia tốc kế

Triển khai thiết bị:

[C-SR-1] RẤT NÊN có gia tốc kế 3 trục.

Nếu các hoạt động triển khai thiết bị có gia tốc kế, thì:

[C-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à 50 Hz.
[C-1-3] PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android.
[C-1-4] PHẢI có khả năng đo từ trạng thái rơi tự do lên đến gấp 4 lần gravity(4g) trở lên trên mọi trục.
[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 theo từng 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 với tần suất ít nhất là 200 Hz.
NÊN có độ phân giải tối thiểu là 16 bit.
CẦ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 duy trì các tham số bù giữa các lần khởi động lại thiết bị.
CẦN được bù nhiệt độ.

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

[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 kết 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 SỬ DỤNG các thiết bị Android để đáp ứng yêu cầu này, nhờ đó, các thiết bị này có thể nâng cấp lên bản phát hành nền tảng trong tương lai (nơi 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 kết 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 các hoạt động triển khai thiết bị có gia tốc kế dưới 3 trục, thì:

[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 các hoạt động triển khai thiết bị bao gồm một gia tốc kế 3 trục và bất kỳ cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER nào được triển khai:

[C-4-1] Tổng mức tiêu thụ điện của các cảm biến này PHẢI luôn nhỏ hơn 4 mW.
Mỗi thiết bị PHẢI có công suất dưới 2 mW và 0,5 mW khi ở trạng thái động hoặc tĩnh.

Nếu các hoạt động triển khai thiết bị bao gồm một gia tốc kế 3 trục và một cảm biến con quay hồi chuyển 3 trục, thì:

[C-5-1] PHẢI triển khai các cảm biến kết hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
[C-SR-7] BẠN NÊN TRIỂN KHAI cảm biến kết hợp TYPE_GAME_ROTATION_VECTOR.

Nếu các hoạt động triển khai thiết bị bao gồm một gia tốc kế 3 trục, một cảm biến con quay hồi chuyển 3 trục và một cảm biến từ kế, thì các hoạt động triển khai đó:

[C-6-1] PHẢI triển khai một cảm biến tổng hợp TYPE_ROTATION_VECTOR.

7.3.2. Từ kế

Triển khai thiết bị:

[C-SR-1] NÊN CÓ từ kế (la bàn) 3 trục.

Nếu các chế độ triển khai thiết bị có một từ kế 3 trục, thì các chế độ này:

[C-1-1] PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD.
[C-1-2] 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à 10 Hz và NÊN báo cáo các sự kiện với 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ư được nêu 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ù độ lệch của sắt từ nhỏ hơn 700 µT và NÊN có giá trị dưới 200 µT bằng cách đặt từ kế cách xa các từ trường động (do dòng điện tạo ra) và 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 đặc hơn 0,6 µT.
[C-1-7] PHẢI hỗ trợ việc hiệu chỉnh và bù trực tuyến độ lệch từ tính cố định, đồng thời duy trì các thông số bù giữa các lần khởi động lại thiết bị.
[C-1-8] PHẢI áp dụng biện pháp bù sắt non – bạn có thể thực hiện quy trình 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 là 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 các hoạt động 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 hoạt động triển khai đó:

[C-2-1] PHẢI triển khai một cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Nếu các hoạt động triển khai thiết bị bao gồm một từ kế 3 trục, một gia tốc kế, thì:

CÓ THỂ triển khai cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Nếu các hoạt động triển khai thiết bị bao gồm một từ kế 3 trục, một gia tốc kế và cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR, thì:

[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 thiết bị:

[C-SR-1] NÊN CÓ một bộ thu GPS/GNSS.

Nếu các hoạt động triển khai thiết bị có bộ nhận GPS/GNSS và báo cáo khả năng cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps, thì các hoạt động triển khai đó:

[C-1-1] PHẢI hỗ trợ đầu ra vị trí với tốc độ ít nhất là 1 Hz khi được yêu cầu thông qua LocationManager#requestLocationUpdate.
[C-1-2] PHẢI có thể xác định vị trí trong điều kiện không bị che khuất (tín hiệu mạnh, đường truyền đa hướng không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian xác định vị trí lần đầu nhanh), khi kết nối vớ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 của 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à Nhật ký vị trí/Đồng hồ vệ tinh).
- [C-1-6] Sau khi thực hiện phép tính vị trí như vậy, các hoạt động triển khai thiết bị PHẢI xác định vị trí của thiết bị trong không gian mở trong vòng 5 giây, khi các yêu cầu về vị trí được khởi động lại, tối đa một giờ sau khi tính toán 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 khi tắt nguồn rồi bật lại.
Trong điều kiện 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 1 mét trên giây bình phương:
- [C-1-3] PHẢI có khả năng xác định vị trí trong vòng 20 mét và tốc độ trong vòng 0, 5 mét/giây, ít nhất 95% thời gian.
- [C-1-4] PHẢI đồng thời theo dõi và báo cáo thông qua GnssStatus.Callback ít nhất 8 vệ tinh của một chòm sao.
- CÓ THỂ 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] RẤT NÊN tiếp tục cung cấp đầu ra vị trí GPS/GNSS bình thường thông qua API Trình cung cấp vị trí GNSS trong cuộc gọi điện thoại khẩn cấp.
[C-SR-3] RẤT 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] RẤT 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ả các thông tin ước tính về độ chính xác (bao gồm cả Hướng, Tốc độ và Độ cao) trong mỗi vị trí GPS/GNSS.
[C-SR-6] RẤT NÊN báo cáo các phép đo GNSS ngay khi tìm thấy, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
[C-SR-7] RẤT NÊN báo cáo tốc độ giả và phạm vi giả của GNSS. Trong điều kiện không gian thoáng đã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 bình phương, các thông tin 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 thiết bị:

[C-SR-1] RẤT NÊN có cảm biến con quay hồi chuyển.

Nếu các chế độ triển khai thiết bị có con quay hồi chuyển, thì:

[C-1-1] PHẢI có khả năng báo cáo các sự kiện với tần suất ít nhất 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ù nhiệt độ.
[C-1-6] PHẢI được hiệu chỉnh và bù trong khi sử dụng, đồng thời giữ lại các thông số bù giữa các lần khởi động lại thiết bị.
[C-1-7] PHẢI có phương sai không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (phương sai trên mỗi Hz hoặc rad^2 / s). Phương sai được phép thay đổi theo tỷ lệ lấy mẫu, nhưng PHẢI bị giới hạn bởi giá trị này. Nói cách khác, nếu bạn đo phương sai của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì phương sai đó KHÔNG ĐƯỢC lớn hơn 1e-7 rad^2/s^2.
[C-SR-2] Bạn NÊN GIẢM lỗi hiệu chuẩn xuống dưới 0,01 rad/s 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 với tần suất ít nhất là 200 Hz.

Nếu các thiết bị triển khai có con quay hồi chuyển 3 trục, thì:

[C-2-1] PHẢI triển khai cảm biến TYPE_GYROSCOPE.
[C-SR-4] Bạn nên triển khai TYPE_GYROSCOPE_UNCALIBRATED cảm biến.

Nếu các chế độ triển khai thiết bị có con quay hồi chuyển dưới 3 trục, thì:

[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 các hoạt động triển khai thiết bị có con quay hồi chuyển 3 trục, cảm biến gia tốc và cảm biến từ kế, thì:

[C-4-1] PHẢI triển khai một cảm biến kết hợp TYPE_ROTATION_VECTOR.

Nếu các hoạt động triển khai thiết bị bao gồm một gia tốc kế 3 trục và một cảm biến con quay hồi chuyển 3 trục, thì:

[C-5-1] PHẢI triển khai các cảm biến kết hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
[C-SR-6] BẠN NÊN TRIỂN KHAI cảm biến kết hợp TYPE_GAME_ROTATION_VECTOR.

7.3.5. Khí áp kế

Triển khai thiết bị:

[C-SR-1] RẤT NÊN có một khí áp kế (cảm biến áp suất không khí xung quanh).

Nếu các hoạt động triển khai thiết bị có một khí áp kế, thì:

[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 các sự kiện ở tần số 5 Hz trở lên.
[C-1-3] PHẢI được bù nhiệt độ.
[C-SR-2] RẤT NÊN có khả năng báo cáo các phép đo áp suất trong khoảng từ 300 hPa đến 1100 hPa.
NÊN có độ chính xác tuyệt đối là 1 hPa.
NÊN có độ chính xác tương đối là 0,12 hPa trong phạm vi 20 hPa (tương đương với độ chính xác ~1 m trong phạm vi thay đổi ~200 m ở mực nước biển).

Các phương thức triển khai thiết bị khai báo thuộc tính hệ thống sensor.barometer.high_quality.implemented:

[C-2-1] PHẢI báo cáo các kết quả đo áp suất trong phạm vi từ 300 hPa đến 1100 hPa, với độ chính xác tuyệt đối là +/- 1 hPa.
[C-2-2] PHẢI có độ chính xác tương đối là 0,15 hPa trong phạm vi 100 hPa, tương đương với độ chính xác ~1 m trong phạm vi thay đổi ~1000 m ở mực nước biển.
[C-2-3] PHẢI ổn định trong khoảng +/- 0, 5 hPa khi người dùng nhấn, bấm hoặc bóp thiết bị.
[C-2-4] PHẢI ổn định trong khoảng +/- 0,15 hPa khi người dùng cầm thiết bị trên tay hoặc bỏ túi.
[C-2-5] KHÔNG ĐƯỢC làm mịn với hằng số thời gian lớn hơn 300 ms cho các lần kích hoạt trên 5 Hz và quá trình làm mịn KHÔNG ĐƯỢC rò rỉ trên các lần kích hoạt cảm biến.
[C-2-6] PHẢI ổn định trong khoảng +/- 0,15 hPa khi tiếp xúc với ánh sáng và tần số vô tuyến hằng ngày do các nguồn phổ biến tạo ra, chẳng hạn như Bluetooth, kết nối di động hoặc Wi-Fi.

7.3.6. Nhiệt kế

Nếu các hoạt động triển khai thiết bị có nhiệt kế môi trường (cảm biến nhiệt độ), thì:

[C-1-1] PHẢI xác định SENSOR_TYPE_AMBIENT_TEMPERATURE cho cảm biến nhiệt độ môi trường và cảm biến PHẢI đo nhiệt độ môi trường (phòng/cabin xe) tại nơi người dùng đang tương tác với thiết bị theo độ C.

Nếu các hoạt động triển khai thiết bị có cảm biến nhiệt kế đo nhiệt độ khác với nhiệt độ môi trường, chẳng hạn như nhiệt độ CPU, thì:

[C-2-1] KHÔNG ĐƯỢC xác định SENSOR_TYPE_AMBIENT_TEMPERATURE cho cảm biến nhiệt độ.

Nếu các hoạt động triển khai thiết bị có cảm biến để theo dõi nhiệt độ trên da, thì:

[C-SR-1] RẤT NÊN hỗ trợ API PowerManager.getThermalHeadroom.

7.3.7. Máy đo quang

Các thiết bị triển khai CÓ THỂ bao gồm một máy đo quang (cảm biến ánh sáng xung quanh).

7.3.8. Cảm biến độ gần

Các hoạt động triển khai thiết bị CÓ THỂ bao gồm một cảm biến độ gần.

Nếu các hoạt động triển khai thiết bị có cảm biến độ gần và chỉ báo cáo kết quả đọc nhị phân "gần" hoặc "xa", thì các hoạt động triển khai đó:

[C-1-1] PHẢI đo khoảng cách gần của một vật thể theo cùng hướng với màn hình. Tức là cảm biến độ gần PHẢI được định hướng để phát hiện các vật thể ở gần màn hình, vì mục đích 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 các phương thức triển khai thiết bị có cảm biến độ gần với bất kỳ hướng nào khác, thì bạn KHÔNG ĐƯỢC phép truy cập 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 khoảng cách đọc gần và 5 cm làm khoảng cách đọc xa.
[C-1-4] PHẢI báo cáo độ phân giải và phạm vi tối đa là 5.

7.3.9. Cảm biến có độ trung thực cao

Nếu các hoạt động 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 các ứng dụng bên thứ ba, thì các hoạt động triển khai đó:

[C-1-1] PHẢI xác định khả năng thông qua cờ tính năng android.hardware.sensor.hifi_sensors.

Nếu các quy trình triển khai thiết bị khai báo android.hardware.sensor.hifi_sensors, thì:

[C-2-1] PHẢI có cảm biến TYPE_ACCELEROMETER:
- PHẢI có phạm vi đo ít nhất từ -8 g đến +8 g và NÊN có phạm vi đo ít nhất từ -16 g đến +16 g.
- PHẢI có độ phân giải đo lường tối thiểu là 2048 LSB/g.
- PHẢI có tần suất đo 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 không 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 đệ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 3 dB ít nhất bằng 80% tần số Nyquist và phổ tiếng ồn trắng trong băng thông này.
- NÊN có một bước đi ngẫu nhiên gia tốc nhỏ hơn 30 μg √Hz được kiểm tra ở nhiệt độ phòng.
- NÊN có độ lệch thay đổi so với nhiệt độ là ≤ +/- 1 mg/°C.
- NÊN có độ không tuyến tính của đường phù hợp nhất là ≤ 0,5% và độ nhạy thay đổi so với nhiệt độ là ≤ 0,03%/°C.
- PHẢI có độ nhạy theo trục ngang < 2,5 % và độ biến thiên của độ nhạy theo trục ngang < 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 đáp ứng các yêu cầu về chất lượng tương tự như TYPE_ACCELEROMETER.
[C-2-3] PHẢI có cảm biến TYPE_GYROSCOPE:
- PHẢI có phạm vi đo ít nhất 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 suất đo 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 không quá 0,014&°/s/√Hz.
- [C-SR-2] BẠN NÊN CÓ băng thông đo lường 3 dB ít nhất bằng 80% tần số Nyquist và phổ tiếng ồn trắng trong băng thông này.
- NÊN có tốc độ biến thiên ngẫu nhiên dưới 0,001&°/s √Hz được kiểm tra ở nhiệt độ phòng.
- NÊN có độ lệch thay đổi so với nhiệt độ ≤ +/- 0,05&°/ s / °C.
- NÊN có độ nhạy thay đổi so với nhiệt độ ≤ 0,02% / °C.
- NÊN có độ không tuyến tính của đường thẳng vừa khít nhất là ≤ 0,2%.
- NÊN có mật độ nhiễu ≤ 0,007&°/s/√Hz.
- NÊN có sai số 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ị ở trạng thái tĩnh.
- NÊN có độ nhạy g nhỏ hơn 0,1&°/s/g.
- PHẢI có độ nhạy theo trục ngang < 4,0 % và độ nhạy theo trục ngang thay đổi < 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 có các yêu cầu về chất lượng giống như TYPE_GYROSCOPE.
[C-2-5] PHẢI có một cảm biến TYPE_GEOMAGNETIC_FIELD:
- PHẢI có phạm vi đo ít nhất từ -900 đến +900 μT.
- PHẢI có độ phân giải đo lường tối thiểu là 5 LSB/uT.
- PHẢI có tần suất đo tối thiểu là 5 Hz hoặc thấp hơn.
- PHẢI có tần suất đo tối đa là 50 Hz trở lên.
- PHẢI có độ nhiễu đo không 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 đệm ít nhất 600 sự kiện cảm biến.
- [C-SR-3] BẠN NÊN CÓ PHỔ TIẾNG ỒN 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 ít nhất từ 300 đến 1100 hPa.
- PHẢI có độ phân giải đo tối thiểu là 80 LSB/hPa.
- PHẢI có tần suất đo tối thiểu là 1 Hz hoặc thấp hơn.
- PHẢI có tần suất đo tối đa là 10 Hz trở lên.
- PHẢI có độ nhiễu đo không 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 đệ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 quá 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ụ điện năng không quá 0,5 mW khi thiết bị ở trạng thái 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 đệm ít nhất 100 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng không quá 0,5 mW khi thiết bị ở trạng thái 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 quá 4 mW.
[C-2-11] PHẢI có cảm biến TYPE_STEP_COUNTER:
- PHẢI có mức tiêu thụ điện năng không quá 0,5 mW khi thiết bị ở trạng thái 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ụ điện năng không quá 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang di chuyển.
[C-2-13] Dấu thời gian sự kiện của cùng một sự kiện thực tế do Gia tốc kế, Con quay hồi chuyển và Từ kế báo cáo PHẢI nằm trong khoảng 2, 5 mili giây của nhau. Dấu thời gian của sự kiện thực tế giống nhau do Gia tốc kế và Con quay hồi chuyển báo cáo PHẢI nằm trong khoảng 0,25 mili giây của nhau.
[C-2-14] PHẢI có dấu thời gian sự kiện của 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 camera và trong vòng 1 mili giây lỗi.
[C-2-15] PHẢI gửi các mẫu đến ứng dụng trong vòng 5 mili giây kể từ thời điểm dữ liệu có sẵn trên bất kỳ cảm biến vật lý nào ở trên cho ứng dụng.
[C-2-16] KHÔNG ĐƯỢC có mức tiêu thụ điện năng cao 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ạn bật bất kỳ tổ hợp nào của các cảm biến sau:
- 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ó thì PHẢI có khả năng lưu vào bộ nhớ đệ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 đều 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ụ điện này bao gồm toàn bộ chuỗi cảm biến – 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 các hoạt động triển khai thiết bị có hỗ trợ cảm biến trực tiếp, thì:

[C-3-1] PHẢI khai báo chính xác mức hỗ trợ của các loại kênh trực tiếp và mức tốc độ 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á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
NÊN 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ề việc Đo lường mức độ bảo mật của tính năng Mở khoá bằng sinh trắc học, vui lòng xem tài liệu Đo lường mức độ bảo mật của dữ liệu sinh trắc học.

Nếu các hoạt động triển khai thiết bị có màn hình khoá bảo mật, thì:

NÊN 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 hành vi giả mạo và mạo danh, cũng như mức độ bảo mật của quy trình sinh trắc họ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 phải giao tiếp với nền tảng và với các ứng dụng của bên thứ ba. Các 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à Loại 1, Loại 2 hoặc Loại 3. Cả thông tin sinh trắc học Lớp 2 và Lớp 3 đều có thêm các chức năng như được trình bày chi tiết bên dưới.

Nếu các phương thứ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-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à một hằng số trong lớp Authenticators và mọi tổ hợp của tên tham số đó. Ngược lại, KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số nguyên được truyền đến các phương thức canAuthenticate(int) và setAllowedAuthenticators(int) ngoài những hằng số được ghi lại dưới dạng hằng số công khai trong Authenticators và mọi tổ hợp của các hằng số đó.
[C-4-3] PHẢI triển khai thao tác ACTION_BIOMETRIC_ENROLL trên những thiết bị có dữ liệu sinh trắc học Loại 3 hoặc Loại 2. Hành động này CHỈ ĐƯỢC PHÉP trình bày các điểm truy cập đăng ký cho dữ liệu sinh trắc học Loại 3 hoặc Loại 2.
[C-4-4] PHẢI cho phép các ứng dụng thêm nội dung tuỳ chỉnh vào BiometricPrompt bằng cách sử dụng các định dạng hiển thị nội dung PromptContentView. Bạn KHÔNG ĐƯỢC mở rộng các định dạng hiển thị nội dung để cho phép hình ảnh, đường liên kết, nội dung tương tác hoặc các dạng nội dung nghe nhìn khác chưa có trong API BiometricPrompt. Bạn có thể điều chỉnh kiểu cách nhưng không được làm thay đổi, che khuất hoặc cắt bớt nội dung này (chẳng hạn như thay đổi vị trí, khoảng đệm, lề và kiểu chữ).

Nếu các hoạt động triển khai thiết bị hỗ trợ dữ liệu sinh trắc học thụ động, thì:

[C-5-1] Theo mặc định, 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Ó một 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] NÊN CỰC KỲ CAO để đảm bảo hành động xác nhận được bảo mật sao cho hệ điều hành hoặc việc xâm nhập vào nhân không thể giả mạo hành động này. Ví dụ: điều này có nghĩa là thao tác xác nhận dựa trên một 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 Secure Element (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] NGOÀI RA, ứng dụng CẦN triển khai một quy trình xác thực ngầm (không có bước xác nhận) tương ứng với setConfirmationRequired(boolean). Các ứng dụng có thể đặt quy trình này để sử dụng cho quy trình đăng nhập.

Nếu các quy trình triển khai thiết bị có nhiều cảm biến sinh trắc học, thì:

[C-7-1] PHẢI, khi một dữ liệu sinh trắc học ở trạng thái khoá (tức là dữ liệu 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 khoá có giới hạn thời gian (tức là dữ liệu sinh trắc học tạm thời bị vô hiệu hoá cho đến khi người dùng đợi một khoảng thời gian) do có quá nhiều lần thử không thành công, cũng phải khoá tất cả dữ liệu 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 tạm ngưng xác minh bằng sinh trắc học PHẢI là thời gian tạm ngưng tối đa của tất cả dữ liệu sinh trắc học trong chế độ khoá có giới hạn thời gian.
[C-SR-12] NÊN TUÂN THỦ khi một dữ liệu sinh trắc học đang ở trạng thái khoá (tức là dữ liệu 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 khoá có giới hạn thời gian (tức là dữ liệu sinh trắc học tạm thời bị vô hiệu hoá cho đến khi người dùng đợi một khoảng thời gian) do có quá nhiều lần thử không thành công, cũng như khoá tất cả dữ liệu 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 tạm ngưng xác minh bằng sinh trắc học là thời gian tạm ngưng tối đa của tất cả dữ liệu sinh trắc học trong chế độ khoá có giới hạn thời gian.
[C-7-2] PHẢI yêu cầu người dùng xác thực chính được đề xuất (chẳng hạn như mã PIN, hình mở khoá hoặc mật khẩu) để đặt lại bộ đếm khoá đối với một dữ liệu sinh trắc học đang bị khoá. Có THỂ cho phép thông tin sinh trắc học Loại 3 đặt lại bộ đếm khoá đối với thông tin sinh trắc học bị khoá thuộc cùng loại hoặc loại thấp hơn. Bạn KHÔNG ĐƯỢC PHÉP sử dụng dữ liệu sinh trắc học Loại 2 hoặc Loại 1 để hoàn tất thao tác đặt lại trạng thái khoá do quên.
[C-SR-3] RẤT NÊN chỉ yêu cầu xác nhận một dữ liệu 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à khuôn mặt đều có trên thiết bị, thì onAuthenticationSucceeded sẽ được gửi sau khi xác nhận một trong hai dữ liệu đó).

Để các hoạt động triển khai thiết bị cho phép các ứng dụng bên thứ ba truy cập vào các kho khoá, các hoạt động này 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 dưới đây.
[C-6-2] CHỈ được trình bày dữ liệu sinh trắc học Loại 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 một CryptoObject.

Nếu các hoạt động triển khai thiết bị muốn coi cảm biến sinh trắc học là Loại 1 (trước đây là Thuận tiện), thì:

[C-1-1] PHẢI có tỷ lệ chấp nhận sai nhỏ hơn 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 đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-1-9] 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) sau không quá 20 lần thử không thành công và thời gian chờ không dưới 90 giây để xác minh bằng sinh trắc học – trong đó, một lần thử không thành công là một lần 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-4] NÊN GIẢM tổng số lần thử không thành công đối với 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 hành vi 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 trên Android.
[C-1-3] PHẢI giới hạn số lần thử xác minh bằng sinh trắc học – trong đó một lần thử không thành công là một lần thử có chất lượng chụp đủ (BIOMETRIC_ACQUIRED_GOOD) không khớp với dữ liệu sinh trắc học đã đăng ký.
[C-SR-5] NÊN GIỚI HẠN TỐC ĐỘ các lần thử trong ít nhất 30 giây sau 5 lần thử sai để xác minh bằng sinh trắc học cho số lần thử sai tối đa cho mỗi [C-1-9] – trong đó lần thử sai là lần 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-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 dữ liệu sinh trắc học sau khi lần đầu tiên kích hoạt cơ chế dự phòng xác thực chính 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 quá 30%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với loại công cụ tấn công khi trình bày (PAI) Cấp A không quá 30% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với loại PAI Cấp B không quá 40%, theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-1-4] PHẢI ngăn việc thêm dữ liệu sinh trắc học mới mà không thiết lập trước chuỗi tin cậy bằng cách yêu cầu người dùng xác nhận thông tin đăng nhập hiện có hoặc thêm thông tin đăng nhập mới cho thiết bị (mã PIN/mẫu hình/mật khẩu) được bảo mật bằng TEE; 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 mọi dữ liệu sinh trắc học nhận dạng của người dùng khi tài khoản của người dùng bị xoá (kể cả khi đặt lại về trạng thái ban đầu) hoặc khi phương thức xác thực chính được đề xuất (chẳng hạn như mã PIN, hình mở khoá, mật khẩu) bị xoá.
[C-1-6] PHẢI tuân thủ từng 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 (chẳng hạn như mã PIN, hình mở khoá, mật khẩu) ít nhất 24 giờ một lần.
[C-1-8] PHẢI yêu cầu người dùng xác thực chính được đề xuất (chẳng hạn như 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 khi xảy ra bất kỳ trường hợp nào sau đây:
- Khoảng thời gian chờ không hoạt động là 4 giờ.
- 3 lần xác thực bằng sinh trắc học không thành công.
- Khoảng thời gian chờ 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 thiết bị.
[C-SR-7] RẤT NÊN sử dụng logic trong khung hình do Dự án nguồn mở Android cung cấp để thực thi cá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, tính từ thời điểm phát hiện dữ liệu sinh trắc học cho đến khi màn hình được mở khoá, đối với mỗi dữ liệu sinh trắc học đã đăng ký.
[C-1-12] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không quá 40% cho mỗi loại công cụ tấn công giả mạo (PAI), theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-SR-13] NÊN CÓ tỷ lệ chấp nhận hành vi giả mạo và mạo danh không quá 30% cho mỗi loại công cụ tấn công giả mạo (PAI), theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[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-1-15] PHẢI cho phép người dùng xoá một hoặc nhiều lượt đăng ký dữ liệu sinh trắc học.
[C-SR-14] NÊN CÔNG BỐ MỘT CÁCH RÕ RÀNG loại dữ liệu 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 này.
[C-SR-17] RẤT NÊN triển khai các giao diện AIDL mới (chẳng hạn như IFace.aidl và IFingerprint.aidl).

Nếu các phương thức triển khai thiết bị muốn coi cảm biến sinh trắc học là Loại 2 (trước đây là Yếu), thì:

[C-2-1] PHẢI đáp ứng tất cả các yêu cầu đối với Lớp 1 nêu 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 quá 20%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với loài công cụ tấn công giả mạo (PAI) Cấp A không quá 20% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với loài PAI Cấp B không quá 30%, theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-SR-15] 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 giả mạo (PAI), theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-2-3] PHẢI thực hiện quy trình 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 không gian nhân Android, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE), trên một chip 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 biệt lập hoặc một vi mạch có kênh bảo mật đến môi trường thực thi biệt lập như được ghi lại trong hướng dẫn triển khai trên trang Dự án nguồn mở Android 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.
[C-2-5] Đối với hệ thống nhận dạng sinh trắc học dựa trên camera, 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 Camera ở chế độ ngăn khung hình Camera bị đọc hoặc thay đổi bên ngoài môi trường thực thi biệt lập hoặc một vi mạch có kênh bảo mật đến môi trường thực thi biệt lập 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ột camera RGB, các khung hình camera CÓ THỂ đọc được bên ngoài môi trường thực thi biệt lập để hỗ trợ các hoạt động như xem trước để đăng ký, nhưng VẪN KHÔNG ĐƯỢC phép thay đổi.
[C-2-6] KHÔNG ĐƯỢC 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 phép truy cập chưa mã hoá vào dữ liệu sinh trắc học 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ư embeddings) vào Bộ xử lý ứng dụng bên ngoài bối cảnh của TEE (Môi trường thực thi đáng tin cậy) 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ị được nâng cấp lên Android phiên bản 9 trở xuống không được miễn [C-2-7].
[C-2-8] PHẢI có quy trình xử lý an toàn để việc xâm phạm hệ điều hành hoặc nhân không thể cho phép dữ liệu được chèn trực tiếp để xác thực sai danh tính người dùng.

Lưu ý: Nếu các hoạt động triển khai thiết bị đã được phát hành trên Android phiên bản 9 trở xuống và không đáp ứng được 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 hoạt động triển khai đó CÓ THỂ được miễn yêu cầu.
[C-SR-10] NÊN CÓ tính năng phát hiện sự sống cho 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ú ý cho phương thức 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 các hoạt động triển khai thiết bị muốn coi cảm biến sinh trắc học là Loại 3 (trước đây là Mạnh), thì:

[C-3-1] PHẢI đáp ứng tất cả các yêu cầu của Loại 2 nêu trên, ngoại trừ [C-1-7] và [C-1-8].
[C-3-2] PHẢI có một quy trình 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 quá 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 giả mạo (PAI) Cấp A không quá 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 PAI Cấp B không quá 20%, theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.
[C-3-4] PHẢI yêu cầu người dùng xác thực chính được đề xuất (chẳng hạn như mã PIN, hình mở khoá, mật khẩu) sau mỗi 72 giờ hoặc ít hơ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ả dữ liệu sinh trắc học Loại 3 được hỗ trợ trên thiết bị nếu có bất kỳ dữ liệu nào trong số đó được đăng ký lại.
[C-3-6] Phải cho phép các ứng dụng bên thứ ba sử dụng các kho khoá được hỗ trợ bằng dữ liệu sinh trắc học.
[C-SR-16] CẦN THIẾT 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% cho mỗi loại công cụ tấn công giả mạo (PAI), theo đo lường của Giao thức kiểm thử sinh trắc học trên Android.

Nếu các hoạt động triển khai thiết bị có cảm biến vân tay dưới màn hình (UDFPS), thì:

[C-SR-11] RẤT NÊN dùng để ngăn vùng có thể chạm của UDFPS can thiệp vào chế độ thao tác bằng 3 nút (một số người dùng có thể cần chế độ này cho mục đích hỗ trợ tiếp cận).

7.3.11. Cảm biến tư thế

Triển khai thiết bị:

CÓ THỂ hỗ trợ cảm biến tư thế với 6 bậc tự do.

Nếu các chế độ triển khai thiết bị hỗ trợ cảm biến tư thế với 6 bậc tự do, thì:

[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 chỉ vectơ xoay.

7.3.12. Cảm biến góc bản lề

Nếu các chế độ triển khai thiết bị hỗ trợ cảm biến góc bản lề, thì:

[C-1-1] PHẢI triển khai và báo cáo TYPE_HINGE_ANGLE.
[C-1-2] PHẢI hỗ trợ ít nhất 2 chỉ số trong khoảng từ 0 đến 360 độ (bao gồm cả 0 và 360 độ).
[C-1-3] PHẢI trả về một cảm biến đánh thức cho getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Nếu các hoạt động triển khai thiết bị có hỗ trợ 802.1.15.4 và cung cấp chức năng cho ứng dụng bên thứ ba, thì các hoạt động triển khai đó:

[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 bộ cấu hình sau (các tổ hợp được xác định trước của các tham số FIRA UCI) được xác định trong quá trình triển khai AOSP.
- CONFIG_ID_1: Phạm vi truyền đơn hướng STATIC STS DS-TWR do FiRa xác định, chế độ hoãn lại, khoảng thời gian đo khoảng cách là 240 mili giây.
- CONFIG_ID_2: Chế độ STATIC STS DS-TWR đo khoảng cách một-đến-nhiều do FiRa xác định, chế độ hoãn, khoảng đo khoảng cách là 200 mili giây. Trường hợp sử dụng điển hình: điện thoại thông minh tương tác với nhiều thiết bị thông minh.
- CONFIG_ID_3: Tương tự như CONFIG_ID_1, ngoại trừ dữ liệu Góc đến (AoA) không được báo cáo.
- CONFIG_ID_4: Tương tự như CONFIG_ID_1, ngoại trừ việc chế độ bảo mật P-STS được bật.
- CONFIG_ID_5: Tương tự như CONFIG_ID_2, ngoại trừ việc chế độ bảo mật P-STS được bật.
- CONFIG_ID_6: Tương tự như CONFIG_ID_3, ngoại trừ việc 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á người được kiểm soát riêng lẻ P-STS được bật.
[C-1-4] PHẢI cung cấp một thành phần để cho phép người dùng bật/tắt trạng thái của đài UWB.
[C-1-5] PHẢI thực thi việc các ứng dụng sử dụng đài UWB giữ 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ủ có liên quan do các tổ chức tiêu chuẩn xác định, bao gồm FIRA, CCC và CSA giúp đảm bảo 802.1.15.4 hoạt động đúng cách.

7.3.14. Cảm biến tuỳ chỉnh

Để mang lại trải nghiệm khác biệt, các hoạt động triển khai thiết bị CÓ THỂ bao gồm các cảm biến bổ sung không thuộc phạm vi của Android hoặc Wear OS. Các ứng dụng được tải sẵn có thể truy cập vào các cảm biến này.

Đối với những cảm biến như vậy, mã nhận dạng cảm biến:

[C-0-1] PHẢI lớn hơn 65536.

Nếu cảm biến tuỳ chỉnh được dùng cho các mục đích liên quan đến sức khoẻ hoặc thể dục, thì cảm biến đó:

[C-0-2] PHẢI được bảo vệ bằng quyền của nền tảng hoặc quyền của hệ thống.

7.4. Kết nối dữ liệu

7.4.1. Điện thoại

"Điện thoại" như được dùng bởi các API Android và tài liệu này đề cập cụ thể đến phần cứng liên quan đến việc thực hiện 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ụ cuộc gọi, nhắn tin và dữ liệu cho phù hợp với sản phẩm.

Android CÓ THỂ được 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 là điện thoại.

Nếu các hoạt động triển khai thiết bị bao gồm chức năng điện thoại GSM hoặc CDMA, thì các hoạt động này:

[C-1-1] PHẢI 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 chế độ hỗ trợ đầy đủ cho API của công nghệ đó.
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 các cuộc gọi khẩn cấp (bất kể loại mạng do SetAllowedNetworkTypeBitmap() đặt).

Nếu các hoạt động triển khai thiết bị không bao gồm phần cứng điện thoại, thì:

[C-2-1] PHẢI triển khai toàn bộ API dưới dạng không hoạt động.

Nếu các hoạt động triển khai thiết bị hỗ trợ eUICC hoặc eSIM/SIM gắn sẵn và có một cơ chế độc quyền để cung cấp chức năng eSIM cho nhà phát triển bên thứ ba, thì:

[C-3-1] PHẢI khai báo cờ tính năng android.hardware.telephony.euicc.

Nếu các hoạt động triển khai thiết bị không đặt thuộc tính hệ thống ro.telephony.iwlan_operation_mode thành legacy, thì:

[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 phiên bản NetworkRegistrationInfo.

Nếu các hoạt động triển khai thiết bị hỗ trợ một lần đăng ký Hệ thống con đa phương tiện IP (IMS) cho cả dịch vụ điện thoại đa phương tiện (MMTEL) và các 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ần đăng ký IMS cho tất cả lưu lượng báo hiệu IMS, thì:

[C-5-1] PHẢI khai báo cờ tính năng android.hardware.telephony.ims và cung cấp một quy trình triển khai hoàn chỉnh của API ImsService cho cả MMTEL và RCS User Capability Exchange API.
[C-5-2] PHẢI khai báo cờ tính năng android.hardware.telephony.ims.singlereg và cung cấp một quy trình triển khai hoàn chỉnh của SipTransport API, GbaService API, các chỉ báo sóng mang chuyên dụng bằng IRadio 1.6 HAL (Lớp trừu tượng phần cứng) và việc cung cấp thông qua Máy chủ định cấu hình tự động (ACS) hoặc cơ chế cung cấp độc quyền khác bằng IMS Configuration API.

Nếu các quy 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 tham chiếu AOSP trong packages/apps/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ợ việc nhập mã quay số tuỳ ý có định dạng *#*#CODE#*#* và kích hoạt thông báo 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 trực quan cho người dùng nếu ứng dụng đó hỗ trợ bản chép lời thư thoại trực quan.
[C-6-5] PHẢI biểu thị tất cả SubscriptionInfo có 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 tiện ích mà người dùng có thể thấy để hiển thị và kiểm soát thông tin thẻ SIM. Ví dụ về những khả năng này bao gồm các giao diện cài đặt phù hợ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ỳ thành phần nào mà người dùng có thể thấy cho phép định cấu hình hoặc kiểm soát chế độ cài đặt thẻ SIM.

Nếu các chế độ triển khai thiết bị báo cáo tính năng android.hardware.telephony và cung cấp một 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 tiện ích cung cấp thông tin về trạng thái SIM. Ví dụ về những điểm tương tác 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 ô 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 đó, 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 các quy 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 kênh logic tối đa (tổng cộng 20 kênh) 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 đang hoạt động của nhà mạ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 ứng dụng trên nền trước ngoài các tính năng quản lý nguồn hiện có có trong AOSP
- Tắt hoặc gỡ cài đặt ứng dụng

Nếu các quy 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 đăng ký không có cơ hội đang hoạt động dùng chung một UUID nhóm đều bị vô hiệu hoá, bị xoá khỏi thiết bị hoặc được đánh dấu là có cơ hội, thì thiết bị sẽ:

[C-8-1] PHẢI tự động tắt tất cả các gói thuê bao cơ hội đang hoạt động còn lại trong cùng một nhóm.

Nếu các hoạt động triển khai thiết bị bao gồm chức năng điện thoại GSM nhưng không bao gồm chức năng điện thoại CDMA, thì:

[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 phép.
[C-9-3] PHẢI trả về một chuỗi trống từ TelephonyManager#getMeid.

Nếu các hoạt động triển khai thiết bị hỗ trợ eUICC có nhiều cổng và hồ sơ, thì:

[C-10-1] PHẢI khai báo cờ tính năng android.hardware.telephony.euicc.mep.

Nếu các hoạt động triển khai thiết bị hỗ trợ kết nối dữ liệu di động, thì:

[C-SR-11] BẠN NÊN khai báo tính năng android.hardware.telephony.data.

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

[C-12-1] PHẢI hỗ trợ ít nhất 2 kết nối mạng dữ liệu di động đồng thời, chẳng hạn như ngữ cảnh PDP, kết nối PDN và kết nối DN.

7.4.1.1. Khả năng tương thích của tính năng chặn số

Nếu các hoạt động triển khai thiết bị báo cáo tính năng android.hardware.telephony.calling, thì:

[C-1-1] PHẢI có 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ần tương tác với ứng dụng. Ngoại lệ duy nhất là khi tính năng chặn số điện thoại tạm thời bị vô hiệu hoá như mô tả trong tài liệu về SDK.
[C-1-4] PHẢI ghi vào trì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 có 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ố bị chặn. Giao diện này sẽ mở ra bằng ý định do phương thức TelecomManager.createManageBlockedNumbersIntent() trả về.
[C-1-7] KHÔNG ĐƯỢC phép người dùng phụ xem hoặc chỉnh sửa các số 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 ĐỀU PHẢI bị ẩn đối với người dùng phụ và danh sách bị chặn VẪN PHẢI được tuân thủ.
NÊN di chuyển các số điện thoại bị chặn vào trì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 một cách để xem 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 các phương thức triển khai thiết bị khai báo android.hardware.microphone và android.hardware.audio.output nhưng không khai báo android.hardware.type.television, thì các phương thức này:

[7.4.1.2/C-0-1] PHẢI khai báo cờ tính năng android.software.telecom.
[7.4.1.2/C-0-2] PHẢI triển khai khung viễn thông.

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

[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 một ứng dụng bên thứ ba 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 một cuộc gọi đến sẽ khiến cuộc gọi khác bị ngắt.
[C-SR-2] NÊN CỰC KỲ tải sẵn ứng dụng quay số mặc định hiển thị một 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] RẤT 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ư sau:
- Gọi Connection.onDisconnect() khi phát hiện thấy sự kiện quan trọng nhấn phím trong thời gian ngắn trong một cuộc gọi đang diễn ra.
- Gọi Connection.onAnswer() khi phát hiện thấy sự kiện nhấn phím trong thời gian 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. Giảm tải duy trì hoạt động NAT-T trên mạng di động

Triển khai thiết bị:

NÊN hỗ trợ tính năng giảm tải tín hiệu duy trì hoạt động của mạng di động.

Nếu các hoạt động triển khai thiết bị có hỗ trợ tính năng giảm tải tính năng duy trì hoạt động của mạng di động và cung cấp chức năng này cho các ứng dụng bên thứ ba, thì:

[C-1-1] PHẢI hỗ trợ SocketKeepAlive API.
[C-1-2] PHẢI hỗ trợ ít nhất một khe cắm duy trì hoạt động đồng thời qua mạng di động.
[C-1-3] PHẢI hỗ trợ nhiều khe cắm duy trì hoạt động đồng thời trên mạng di động như được Cellular Radio HAL hỗ trợ.
[C-SR-1] RẤT NÊN hỗ trợ ít nhất 3 khe cắm duy trì hoạt động của mạng di động cho mỗi phiên bản đài.

Nếu các chế độ triển khai thiết bị không hỗ trợ tính năng giảm tải tín hiệu duy trì hoạt động của mạng di động, thì:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Triển khai thiết bị:

PHẢI hỗ trợ một hoặc nhiều dạng thức của 802.11.

Nếu các hoạt động triển khai thiết bị có hỗ trợ 802.11 và cung cấp chức năng cho ứng dụng bên thứ ba, thì các hoạt động này:

[C-1-1] 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 API truyền tin đa hướng như mô tả trong tài liệu SDK.
[C-1-4] PHẢI hỗ trợ mDNS và KHÔNG ĐƯỢC lọc các gói mDNS (224.0.0.251 hoặc ff02::fb) bất cứ lúc nào trong quá trình hoạt động, kể cả khi màn hình không ở trạng thái hoạt động, trừ phi khoá truyền tin đa hướng 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 mọi hoạt động mDNS 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 mức tiêu thụ điện năng theo yêu cầu của các quy định hiện hành đối với thị trường mục tiêu.
[C-1-5] KHÔNG ĐƯỢC coi lệnh gọi phương thức API WifiManager.enableNetwork() là dấu hiệu đủ để chuyển Network hiện đang hoạt động (được dùng theo mặc định cho lưu lượng truy cập ứng dụng và do các phương thức API ConnectivityManager trả về) chẳng hạn như getActiveNetwork và registerDefaultNetworkCallback. Nói cách khác, họ CHỈ CÓ THỂ 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] NÊN khi phương thức API ConnectivityManager.reportNetworkConnectivity() được gọi, hãy đánh giá lại quyền truy cập Internet trên Network và, sau khi đá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 ngẫu nhiên hoá địa chỉ MAC nguồn và số thứ tự của các khung yêu cầu dò tìm, 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 NÊN ngẫu nhiên hoá địa chỉ MAC trong quá trình quét).
[C-1-9] PHẢI lặp lại số thứ tự yêu cầu dò tìm như bình thường (lần lượt) giữa các yêu cầu dò tìm trong một lần quét.
[C-1-10] PHẢI tạo số thứ tự ngẫu nhiên cho yêu cầu thăm dò 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] BẠN NÊN TUYỆT ĐỐI ngẫu nhiên hoá địa chỉ MAC nguồn được dùng cho mọi hoạt động giao tiếp STA với Điểm truy cập (AP) trong khi liên kết và được liên kết.
- Thiết bị PHẢI sử dụng một địa chỉ MAC ngẫu nhiên khác 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 lựa chọn kiểm soát việc ngẫu nhiên hoá theo SSID (FQDN cho Passpoint) bằng các lựa chọn không ngẫu nhiên hoá và ngẫu nhiên hoá, đồng thời PHẢI đặt chế độ mặc định cho các cấu hình Wi-Fi mới thành ngẫu nhiên hoá.
[C-SR-2] NÊN SỬ DỤNG BSSID ngẫu nhiên cho mọi AP mà họ tạo.
- Địa chỉ MAC PHẢI được sắp xếp ngẫu nhiên và duy trì theo SSID mà AP sử dụng.
- THIẾT BỊ CÓ THỂ cho phép người dùng tắt tính năng này. Nếu có lựa chọn như vậy, thì theo mặc định, bạn PHẢI bật tính năng ngẫu nhiên hoá.

Nếu các hoạt động triển khai thiết bị có 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 hoạt động này:

NÊN tắt chế độ tiết kiệm pin Wi-Fi bất cứ khi nào một ứng dụng nhận được khoá WIFI_MODE_FULL_HIGH_PERF hoặc khoá WIFI_MODE_FULL_LOW_LATENCY thông qua các API WifiManager.createWifiLock() và WifiManager.WifiLock.acquire() và khoá đang hoạt động.
[C-3-2] Độ trễ trung bình của chuyến khứ hồi giữa thiết bị và một điểm truy cập khi thiết bị ở chế độ Khoá độ trễ thấp của Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PHẢI nhỏ hơn độ trễ trong chế độ Khoá hiệu suất cao của Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] NÊN SỬ DỤNG để giảm thiểu độ trễ khứ hồi của Wi-Fi bất cứ khi nào có được Khoá độ trễ thấp (WIFI_MODE_FULL_LOW_LATENCY) và có hiệu lực.

Nếu các hoạt động triển khai thiết bị hỗ trợ Wi-Fi và sử dụng Wi-Fi để quét vị trí, thì:

[C-2-1] PHẢI cung cấp cho người dùng một thành phần để bật/tắt giá trị đọc thông qua phương thức API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Triển khai thiết bị:

PHẢI hỗ trợ Wi-Fi Direct (Wi-Fi ngang hàng).

Nếu quá trình triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì:

[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 thao tác Wi-Fi và Wi-Fi Direct.
[C-SR-1] RẤT 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 được tạo.

7.4.2.2. Thiết lập đường liên kết trực tiếp được chuyển hướng qua Wi-Fi

Triển khai thiết bị:

NÊN hỗ trợ Thiết lập đường liên kết trực tiếp được chuyển hướng qua Wi-Fi (TDLS) như mô tả trong Tài liệu SDK Android.

Nếu các hoạt động triển khai thiết bị có hỗ trợ TDLS và TDLS được bật bằng API WiFiManager, thì các hoạt động triển khai đó sẽ:

[C-1-1] PHẢI khai báo dịch vụ hỗ trợ cho 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ó thể kém hơn so với việc đi qua điểm truy cập Wi-Fi.

7.4.2.3. Wi-Fi Aware

Triển khai thiết bị:

PHẢI hỗ trợ Wi-Fi Aware.

Nếu các hoạt động triển khai thiết bị có hỗ trợ Wi-Fi Aware và cung cấp chức năng này cho các ứng dụng bên thứ ba, thì:

[C-1-1] PHẢI triển khai các API WifiAwareManager như mô tả trong tài liệu về 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ợ các hoạt động Wi-Fi và Nhận biết Wi-Fi cùng lúc.
[C-1-4] PHẢI ngẫu nhiên hoá địa chỉ giao diện quản lý Wi-Fi Aware trong 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 đang diễn ra một hoạt động đo khoảng cách Aware hoặc đường dẫn dữ liệu Aware đang hoạt động (không cần ngẫu nhiên hoá miễn là đường dẫn dữ liệu đang hoạt động).

Nếu các hoạt động triển khai thiết bị có hỗ trợ Wi-Fi Aware và Wi-Fi Location như mô tả trong Mục 7.4.2.5 và cung cấp các chức năng này cho ứng dụng bên thứ ba, thì các hoạt động triển khai đó:

[C-2-1] PHẢI triển khai các API khám phá nhận biết vị trí: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm và onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Nếu quá trình triển khai thiết bị có hỗ trợ 802.11 (Wi-Fi), thì:

NÊN hỗ trợ Wi-Fi Passpoint.

Nếu quá trình triển khai thiết bị có hỗ trợ Passpoint Wi-Fi, thì:

[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, cụ thể là liên quan đến tính năng 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] 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 tập hợp con sau đây của các giao thức cấp phép thiết bị 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ác cấu hình Passpoint sau khi khởi động lại.
[C-SR-1] RẤT NÊN hỗ trợ tính năng chấp nhận điều khoản và điều kiện.
[C-SR-2] RẤT NÊN hỗ trợ tính năng thông tin về Địa điểm.

Nếu có một công tắc kiểm soát người dùng để tắt Passpoint trên toàn cầu, thì các hoạt động triển khai sẽ:

[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 thiết bị:

NÊN có tính năng hỗ trợ Vị trí Wi-Fi.

Nếu các hoạt động triển khai thiết bị có hỗ trợ Dịch vụ vị trí qua Wi-Fi và cung cấp chức năng này cho các ứng dụng bên thứ ba, thì các hoạt động triển khai đó:

[C-1-1] PHẢI triển khai các API WifiRttManager như mô tả trong tài liệu về 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 chuỗi 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 Điểm truy cập.
[C-1-4] PHẢI có độ chính xác trong vòng 2 mét ở băng thông 80 MHz tại phân vị thứ 68 (theo tính toán bằng Hàm phân phối tích luỹ).
[C-SR-1] ĐƯỢC RẤT KHUYẾN KHÍCH báo cáo chính xác trong phạm vi 1,5 mét ở băng thông 80 MHz tại phân vị thứ 68 (theo tính toán bằng Hàm phân phối tích luỹ).

7.4.2.6. Giảm tải tính năng duy trì hoạt động của Wi-Fi

Triển khai thiết bị:

NÊN hỗ trợ tính năng chuyển tải Wi-Fi keepalive.

Nếu các hoạt động triển khai thiết bị có hỗ trợ tính năng giảm tải duy trì hoạt động Wi-Fi và cung cấp chức năng này cho các ứng dụng bên thứ ba, thì:

[C-1-1] PHẢI hỗ trợ API SocketKeepAlive.
[C-1-2] PHẢI hỗ trợ ít nhất 3 khe cắm duy trì hoạt động đồng thời qua Wi-Fi

Nếu các chế độ triển khai thiết bị không hỗ trợ tính năng giảm tải chế độ duy trì hoạt động của Wi-Fi, thì:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2.7. Kết nối Wi-Fi dễ dàng (Giao thức thiết lập thiết bị)

Triển khai thiết bị:

NÊN hỗ trợ Wi-Fi Easy Connect (DPP).

Nếu các hoạt động triển khai thiết bị có hỗ trợ Wi-Fi Easy Connect và cung cấp chức năng cho các ứng dụng bên thứ ba, thì các hoạt động này:

[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 của 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 máy chủ Wi-Fi chưa được đặt, thì các hoạt động triển khai thiết bị sẽ:

[C-SR-1] KHÔNG NÊN cung cấp cho người dùng lựa 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 các hoạt động 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ì:

[C-4-1] PHẢI cung cấp cho người dùng một lựa chọn để chọn sử dụng TOFU.

7.4.2.10. Phát hiện thiết bị gần đây bằng Wi-Fi

Nếu quá trình triển khai thiết bị có hỗ trợ tính năng Phát hiện thiết bị ở gần qua Wi-Fi, thì:

[C-1-1] PHẢI hỗ trợ tính năng Phát hiện thiết bị gần đây.
[C-1-2] PHẢI khai báo cờ tính năng android.hardware.wifi.rtt.
[C-1-3] PHẢI có phương thức WifiRttManager#getProximityDetectionCharacteristics() trả về giá trị khác rỗng.
[C-1-4] PHẢI triển khai các API đo khoảng cách liên tục WifiRttManager.
[C-1-5] PHẢI hỗ trợ đồng thời các hoạt động Phát hiện thiết bị ở gần bằng Wi-Fi và Wi-Fi.
[C-1-6] PHẢI có độ chính xác trong vòng 2 mét ở băng thông 80 MHz tại phân vị thứ 68 (theo tính toán bằng Hàm phân phối tích luỹ).
[C-1-7] PHẢI thực hiện hoạt động đo khoảng cách Phát hiện lân cận (PD) ở băng tần cao nhất hiện có (6 GHz, 5 GHz hoặc 2,4 GHz) bằng băng thông được hỗ trợ tối đa theo thứ tự ưu tiên sau: 160 MHz, 80 MHz, 40 MHz và 20 MHz.
[C-SR-1] CẦN BÁO CÁO chính xác trong phạm vi 1,5 mét ở băng thông 80 MHz tại phân vị thứ 68 (theo tính toán bằng Hàm phân phối tích luỹ).
[C-SR-2] RẤT NÊN HỖ TRỢ tính năng đo khoảng cách NTB 802.11az.

7.4.3. Bluetooth

Nếu các hoạt động triển khai thiết bị hỗ trợ cấu hình Âm thanh Bluetooth, thì:

NÊN hỗ trợ Bộ mã hoá và giải mã âm thanh nâng cao và Bộ mã hoá và giải mã âm thanh qua Bluetooth (ví dụ: LDAC).

Nếu các thiết bị triển khai hỗ trợ HFP, A2DP và AVRCP, thì:

NÊN hỗ trợ ít nhất 5 thiết bị được kết nối.

Nếu các phương thức triển khai thiết bị khai báo tính năng android.hardware.vr.high_performance, thì chúng:

[C-1-1] PHẢI hỗ trợ Bluetooth 4.2 và tiện ích mở rộng độ dài dữ liệu Bluetooth LE.

Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp.

Nếu các hoạt động triển khai thiết bị có hỗ trợ Bluetooth và Bluetooth năng lượng thấp, thì:

[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 cấu hình Bluetooth có liên quan, chẳng hạn như A2DP, AVRCP, OBEX, HFP, v.v. cho phù hợp với thiết bị.

Nếu các hoạt động triển khai thiết bị có hỗ trợ Bluetooth năng lượng thấp (BLE), thì:

[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 đúng giá trị cho BluetoothAdapter.isOffloadedFilteringSupported() để cho biết liệu bạn đã triển khai logic lọc cho các lớp API ScanFilter hay chưa.
[C-3-4] PHẢI báo cáo đúng giá trị cho BluetoothAdapter.isMultipleAdvertisementSupported() để cho biết liệu có hỗ trợ Quảng cáo tiêu thụ ít năng lượng hay không.
[C-3-5] PHẢI triển khai thời gian chờ Địa chỉ riêng tư có thể phân giải (RPA) không quá 15 phút và xoay vòng địa chỉ khi hết thời gian chờ để bảo vệ quyền riêng tư của người dùng khi thiết bị đang tích cực sử dụng BLE để quét hoặc quảng cáo. Để ngăn chặn các cuộc tấn công dựa trên thời gian, các khoảng thời gian chờ CŨNG PHẢI được chọn ngẫu nhiên trong khoảng từ 5 đến 15 phút.
NÊN hỗ trợ việc chuyển logic lọc sang chipset bluetooth khi triển khai ScanFilter API.
NÊN hỗ trợ việc chuyển quy trình quét theo lô sang chipset Bluetooth.
NÊN hỗ trợ nhiều quảng cáo với ít nhất 4 vị trí.

Nếu các hoạt động triển khai thiết bị hỗ trợ Bluetooth LE và sử dụng Bluetooth LE để quét vị trí, thì các hoạt động này sẽ:

[C-4-1] PHẢI cung cấp cho người dùng một thành phần để bật/tắt giá trị đọc thông qua API hệ thống BluetoothAdapter.isBleScanAlwaysAvailable().

Nếu các hoạt động triển khai thiết bị có hỗ trợ Bluetooth LE và Cấu hình thiết bị trợ thính, như mô tả trong Hỗ trợ âm thanh cho thiết bị trợ thính bằng Bluetooth LE, thì:

[C-5-1] PHẢI trả về true cho BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Nếu các hoạt động triển khai thiết bị có hỗ trợ Bluetooth hoặc Bluetooth năng lượng thấp, thì:

[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ể được 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 một quy trình kiểm tra quyền android.permission.ACCESS_FINE_LOCATION dựa trên trạng thái hiện tại ở nền trước/nền sau.

Nếu các hoạt động triển khai thiết bị có 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ì:

[C-6-2] PHẢI kiểm soát quyền truy cập Bluetooth bằng android.permission.ACCESS_FINE_LOCATION.

Nếu các phương thức triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioSupported(), thì:

[C-7-1] PHẢI hỗ trợ ứng dụng truyền đơn hướng.
[C-7-2] PHẢI hỗ trợ PHY 2M.
[C-7-3] PHẢI hỗ trợ tính năng 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 đồng thời bật ứng dụng BAP truyền đơn phương, bộ điều phối tập hợp CSIP, máy chủ MCP, bộ điều khiển VCP, máy chủ CCP.
[C-SR-1] BẠN NÊN BẬT ứng dụng khách truyền đơn hướng HAP.

Nếu các phương thức triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), thì:

[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 đồng thời nguồn truyền tin BAP và trợ lý truyền tin BAP.
[C-8-3] PHẢI hỗ trợ quảng cáo định kỳ LE.

Nếu các phương thức triển khai thiết bị trả về true cho API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), thì:

[C-9-1] PHẢI hỗ trợ PAST (Periodic Advertising Sync Transfer – Truyền đồng bộ quảng cáo định kỳ).
[C-9-2] PHẢI hỗ trợ quảng cáo định kỳ LE.

Nếu các quy trình triển khai thiết bị khai báo FEATURE_BLUETOOTH_LE, thì chúng sẽ:

[C-10-1] PHẢI có các phép đo RSSI nằm trong khoảng +/-9 dB đối với 95% các phép đo ở khoảng cách 1 m so với một thiết bị tham chiếu truyền ở ADVERTISE_TX_POWER_HIGH trong môi trường tầm nhìn thẳng.
[C-10-2] PHẢI bao gồm các điểm điều chỉnh Rx/Tx để giảm độ lệch trên mỗi kênh sao cho các phép đo trên mỗi kênh trong số 3 kênh, trên mỗi ăng-ten (nếu dùng nhiều ăng-ten) nằm trong khoảng +/-3 dB so với nhau đối với 95% các phép đo.

Nếu các quy trình triển khai thiết bị khai báo FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, thì chúng sẽ:

[C-11-1] PHẢI báo cáo cờ tính năng phần cứng android.hardware.bluetooth_le.channel_sounding.
[C-11-2] PHẢI báo cáo chính xác phạm vi trong vòng +/- 0,5 m ở phân vị thứ 90, được tính bằng Hàm phân phối tích luỹ, ở khoảng cách 1 m.

Nếu các quy trình triển khai thiết bị khai báo FEATURE_BLUETOOTH_LE, thì chúng sẽ:

[C-SR-2] RẤT NÊN đo lường và bù đắp độ lệch Rx để đảm bảo RSSI BLE trung vị là -60 dBm +/-10 dB ở khoảng cách 1 m so với một thiết bị tham chiếu truyền ở ADVERTISE_TX_POWER_HIGH, trong đó các thiết bị được định hướng sao cho chúng nằm trên "các mặt phẳng song song" với màn hình hướng về cùng một hướng.
[C-SR-3] ĐƯỢC RẤT KHUYẾN KHÍCH đo lường và bù trừ độ lệch Tx để đảm bảo RSSI BLE trung vị là -60 dBm +/-10 dB khi quét từ một thiết bị tham chiếu được đặt ở khoảng cách 1 m 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.

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ề hiệu chuẩn sự hiện diện.

7.4.4. Giao tiếp trường gần

Triển khai thiết bị:

PHẢI có một bộ thu phát và phần cứng liên quan cho 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 chúng 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 biểu diễn dữ liệu độc lập với giao thức.

Nếu các hoạt động triển khai thiết bị có phần cứng NFC và dự định cung cấp phần cứng này cho các ứng dụng bên thứ ba, thì các hoạt động triển khai đó phải:

[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 thông báo 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 (theo định nghĩa của quy cách kỹ thuật 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)
- Các loại thẻ NFC Forum 2, 3, 4, 5 (do NFC Forum xác định)
[C-SR-1] RẤT 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. Xin lưu ý rằng mặc dù các tiêu chuẩn NFC được nêu là RẤT NÊN DÙNG, nhưng Định nghĩa về khả năng tương thích cho một 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 DÙNG. Các tiêu chuẩn này không bắt buộc trong phiên bản này nhưng sẽ là yêu cầu bắt buộc trong các phiên bản sau. Các thiết bị hiện có và thiết bị mới chạy phiên bản Android này nên đáp ứng những yêu cầu này ngay 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ò tất cả các công nghệ được hỗ trợ trong khi ở chế độ phát hiện NFC.
PHẢI ở chế độ khám phá NFC trong khi thiết bị đang hoạt động với màn hình đang bật và màn hình khoá ở trạng thái mở khoá.
CÓ THỂ đọc mã vạch và URL (nếu được mã hoá) của các sản phẩm Mã vạch NFC Thinfilm.

Xin lưu ý rằng các đường liên kết được cung cấp công khai không có sẵn cho các quy cách JIS, ISO và NFC Forum được trích dẫn ở trên.

Android có hỗ trợ chế độ Giả lập thẻ dựa trên máy chủ (HCE) của NFC.

Nếu các hoạt động triển khai thiết bị bao gồm một bộ vi mạch bộ điều khiển NFC có khả năng HCE (đối với NfcA và/hoặc NfcB) và hỗ trợ định tuyến mã ứng dụng (AID), thì các hoạt động này:

[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 các hoạt động triển khai thiết bị bao gồm một chipset bộ điều khiển NFC có khả năng 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-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 các hoạt động triển khai thiết bị bao gồm khả 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) trong vai trò đầu đọc/ghi, thì các hoạt động triển khai đó sẽ:

[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à một tính năng chuẩn của Android 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 thiết bị:

[C-0-1] PHẢI hỗ trợ một hoặc nhiều hình thức kết nối mạng dữ liệu. Cụ thể, các hoạt động triển khai thiết bị PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu có khả năng đạt tốc độ 200 Kbit/giây trở lên. Các ví dụ về công nghệ đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet và PAN Bluetooth.
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 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 thiết bị:

[C-0-2] PHẢI có một 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ác ổ 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 đáng tin cậy như IPv4, ví dụ:
[C-0-4] PHẢI duy trì kết nối IPv6 ở chế độ chờ.
[C-0-5] Việc giới hạn tốc độ KHÔNG ĐƯỢC khiến thiết bị mất khả năng kết nối IPv6 trên bất kỳ mạng nào tuân thủ IPv6 sử dụng thời gian tồn tại RA ít nhất 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 trực tiếp IPv6 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ý (chẳng hạn như Socket#getLocalAddress hoặc Socket#getLocalPort) và API NDK (chẳng hạn 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 các gói trên mạng, đồng thời hiển thị dưới dạng ip và cổng nguồn cho các 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 các hoạt động triển khai thiết bị hỗ trợ Wi-Fi, thì:

[C-1-1] PHẢI hỗ trợ hoạt động chỉ dùng IPv6 và ngăn xếp kép trên Wi-Fi.

Nếu các thiết bị triển khai hỗ trợ Ethernet, thì:

[C-2-1] PHẢI hỗ trợ hoạt động chỉ dành cho IPv6 và ngăn xếp kép trên Ethernet.

Nếu các hoạt động triển khai thiết bị hỗ trợ Dữ liệu di động, thì:

[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 các hoạt động 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 nêu trên trên mỗi mạng khi thiết bị được kết nối đồng thờ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ười dùng đăng nhập để truy cập Internet.

Nếu các phương thức triển khai thiết bị cung cấp một phương thức triển khai hoàn chỉnh của android.webkit.Webview API, thì các phương thức triển khai đó sẽ:

[C-1-1] PHẢI cung cấp một ứng dụng trang xác thực để xử lý ý định ACTION_CAPTIVE_PORTAL_SIGN_IN và hiển thị trang đăng nhập của 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 giam giữ và hỗ trợ đăng nhập thông qua ứng dụng cổng giam giữ khi thiết bị kết nối với bất kỳ loại mạng nào, bao gồm 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 giam giữ bằng DNS văn bản thuần tuý 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 được mã hoá theo tài liệu SDK cho android.net.LinkProperties.getPrivateDnsServerName và android.net.LinkProperties.isPrivateDnsActive cho tất cả lưu lượng truy cập mạng không giao tiếp rõ ràng với cổng giam giữ.
[C-1-5] PHẢI đảm bảo rằng trong khi người dùng đăng nhập vào một cổng giam giữ, mạng mặc định mà các ứng dụng sử dụng (do ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback trả về và được Java networking API (chẳng hạn như java.net.Socket) và native API (chẳng hạn như connect()) sử dụng theo mặc định) là bất kỳ mạng nào khác có sẵn cung cấp quyền truy cập vào Internet (nếu có).

7.4.6. Cài đặt đồng bộ hoá

Triển khai 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 các phương thức triển khai thiết bị có kết nối có đo lượng dữ liệu, thì đó là:

[C-SR-1] RẤT NÊN cung cấp chế độ tiết kiệm dữ liệu.

Nếu triển khai chế độ trình tiết kiệm dữ liệu, thì các thiết bị sẽ:

[C-1-1] PHẢI hỗ trợ tất cả các API trong lớp ConnectivityManager theo mô tả trong tài liệu về SDK

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

[C-2-1] PHẢI trả về giá trị RESTRICT_BACKGROUND_STATUS_DISABLED cho ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] KHÔNG ĐƯỢC phát sóng ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Element

Nếu các phương thứ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ử này cho ứng dụng bên thứ ba, thì các phương thức triển khai đó sẽ:

[C-1-1] PHẢI liệt kê các trình đọc phần tử bảo mật có sẵn thông qua API android.se.omapi.SEService.getReaders().
[C-1-2] PHẢI khai báo đúng cờ tính năng thông qua android.hardware.se.omapi.uicc cho thiết bị có các phần tử bảo mật dựa trên UICC, android.hardware.se.omapi.ese cho thiết bị có các phần tử bảo mật dựa trên eSE và android.hardware.se.omapi.sd cho thiết bị có cá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 các hoạt động triển khai thiết bị có hỗ trợ 802.1.15.4 và cung cấp chức năng cho ứng dụng bên thứ ba, thì:

[C-1-1] 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ả các cấu hình 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 một thành phần để cho phép người dùng bật/tắt trạng thái của đài UWB.
[C-1-5] PHẢI thực thi việc các ứng dụng dùng đài UWB phải có quyền UWB_RANGING (trong nhóm quyền NEARBY_DEVICES).
[C-SR-1] NÊN TUÂN THỦ các bài kiểm tra chứng nhận và sự phù hợp có liên quan do các tổ chức tiêu chuẩn xác định, bao gồm FIRA, CCC và CSA.
[C-1-6] PHẢI đảm bảo các phép đo khoảng cách nằm trong khoảng +/-15 cm đối với 95% các phép đo trong môi trường tầm nhìn thẳng ở khoảng cách 1 m trong một buồng không phản xạ.
[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 ở khoảng cách 1 m so với thiết bị tham chiếu nằm trong khoảng [0,75 m, 1,25 m], trong đó khoảng cách thực tế được đo từ cạnh trên của DUT.
[C-SR-2] BẠN NÊN TUÂN THỦ các bước thiết lập tính năng đo lường được chỉ định trong Yêu cầu về hiệu chỉnh sự hiện diện.

7.5. Camera

Nếu các hoạt động triển khai thiết bị có ít nhất một camera, thì:

[C-1-1] PHẢI khai báo cờ tính năng android.hardware.camera.any.
[C-1-2] Ứng dụng PHẢI có thể phân bổ đồng thời 3 bitmap RGBA_8888 có kích thước bằng kích thước của hình ảnh do cảm biến camera có độ phân giải lớn nhất trên thiết bị tạo ra, trong khi camera đang mở cho mục đích 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 camera 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 các phương thức triển khai thiết bị có ít nhất một camera và ứng dụng camera được cài đặt sẵn xử lý các ý định MediaStore.ACTION_MOTION_PHOTO_CAPTURE hoặc MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, thì:

[C-1-4] PHẢI đảm bảo rằng khi xử lý các ý định này, ứng dụng camera được cài đặt sẵn sẽ xoá vị trí của người dùng trong siêu dữ liệu hình ảnh trước khi gửi đến các ứng dụng nhận không có ACCESS_FINE_LOCATION.
[C-1-5] PHẢI đảm bảo rằng ảnh chuyển động được trả về sử dụng quy cách định dạng Ảnh chuyển động 1.0.

[C-1-6] PHẢI gắn nhãn cho từng loại thiết bị camera bằng trường CameraCharacteristics.INFO_DEVICE_TYPE dưới dạng BUILT_IN, EXTERNAL hoặc VIRTUAL. Cũng PHẢI gắn nhãn cho từng khung hình đầu ra của camera bằng trường CaptureResult.INFO_DEVICE_TYPE.
Việc đảm bảo CaptureResult.INFO_DEVICE_TYPE được gắn nhãn chính xác là đặc biệt quan trọng trong những trường hợp mã nhận dạng camera được ánh xạ lại một cách linh động sang một nguồn camera khác.

Nếu các thiết bị triển khai hỗ trợ khả năng xuất hình ảnh HDR 10 bit, thì:

[C-2-1] PHẢI hỗ trợ ít nhất hồ sơ HDR HLG cho mọi thiết bị camera hỗ trợ đầu ra 10 bit.
[C-2-2] PHẢI hỗ trợ đầu ra 10 bit cho camera sau chính hoặc camera trước chính.
[C-SR-1] RẤT NÊN HỖ TRỢ đầu ra 10 bit cho cả camera chính.
[C-2-3] PHẢI hỗ trợ cùng một hồ sơ HDR cho tất cả cá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ợ chuyển đổi giữa tất cả các camera thực tương thích ngược thông qua chế độ điều khiển CONTROL_ZOOM_RATIO trên camera logic.

7.5.1. Camera sau

Camera sau là camera quay ra ngoài, chụp ảnh các cảnh ở phía xa của thiết bị, giống như một camera truyền thống; trên các thiết bị cầm tay, đó là camera nằm ở mặt đối diện với màn hình của thiết bị.

Triển khai thiết bị:

NÊN có camera sau.

Nếu các hoạt động triển khai thiết bị có ít nhất một camera sau, thì:

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

NÊN triển khai tính năng tự động lấy nét bằng phần cứng hoặc phần mềm trong trình điều khiển camera (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 ảnh mở rộng).
CÓ THỂ có đèn flash.

Nếu camera có đèn flash:

[C-2-1] đèn flash KHÔNG ĐƯỢC bật trong khi một thực thể android.hardware.Camera.PreviewCallback đã được đăng ký trên một bề mặt xem trước của Camera, 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 một đối tượng Camera.Parameters. Xin lưu ý rằng hạn chế này không áp dụng cho ứng dụng camera hệ thống tích hợp 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 trước

Camera trước là camera hướng về phía người dùng, thường được 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à camera nằm ở cùng phía với màn hình của thiết bị.

Triển khai thiết bị:

CÓ THỂ có camera trước.

Nếu các hoạt động triển khai thiết bị có ít nhất một camera trước, thì:

[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 dùng camera trước làm mặc định cho Camera API và KHÔNG ĐƯỢC định cấu hình API để coi camera trước là camera sau mặc định, ngay cả khi đó là camera duy nhất trên thiết bị.
[C-1-4] Bản xem trước của camera 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 camera đượ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 rằng màn hình Camera được xoay thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation().
[C-1-5] KHÔNG ĐƯỢC phản chiếu hình ảnh tĩnh hoặc luồng video đã chụp cuối cùng được trả về cho các lệnh gọi lại ứng dụng hoặc được cam kết với bộ nhớ nội dung nghe nhìn.
[C-1-6] PHẢI phản chiếu hình ảnh do chế độ xem sau hiển thị theo cách tương tự như luồng hình ảnh xem trước của camera.
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 camera sau như mô tả trong mục 7.5.1.

Nếu các chế độ triển khai thiết bị có khả năng được người dùng xoay (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 hoạt động đầu vào của người dùng):

[C-2-1] Bản xem trước của camera 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. Camera gắn ngoài

Camera bên ngoài là camera 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ư camera USB.

Triển khai thiết bị:

CÓ THỂ bao gồm hỗ trợ cho camera bên ngoài không nhất thiết phải luôn kết nối.

Nếu các hoạt động triển khai thiết bị có hỗ trợ camera ngoài, thì:

[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 camera bên ngoài kết nối qua cổng máy chủ USB.
[C-1-3] PHẢI vượt qua các bài kiểm thử CTS camera khi đã kết nối một thiết bị camera ngoài thực tế. Thông tin chi tiết về kiểm thử CTS của camera có tại source.android.com.
NÊN hỗ trợ các phương thức nén video như MJPEG để cho phép truyền các luồng chưa mã hoá chất lượng cao (tức là các luồng hình ảnh thô hoặc được nén độc lập).
CÓ THỂ hỗ trợ nhiều camera.
CÓ THỂ hỗ trợ tính năng mã hoá video dựa trên camera.

Nếu thiết bị hỗ trợ tính năng mã hoá video dựa trên camera:

[C-2-1] Thiết bị triển khai PHẢI truy cập được vào luồng MJPEG / luồng không được mã hoá đồng thời (độ phân giải QVGA trở lên).

7.5.4. Hành vi của Camera API

Android có 2 gói API để truy cập vào camera, API android.hardware.camera2 mới hơn sẽ hiển thị chế độ điều khiển camera ở cấp thấp cho ứng dụng, bao gồm cả các luồng truyền phát/chụp liên tục hiệu quả không sao chép và chế độ điều khiển theo từng khung hình về độ phơi sáng, độ khuếch đại, độ khuếch đại cân bằng trắng, chuyển đổi màu, khử nhiễu, làm sắc nét và nhiều chế độ khác.

Gói API cũ hơn, 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. Các hoạt động 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, đồng thời chất lượng của hình ảnh chụp được cũng 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 phù hợp, nhưng NÊN phù hợp càng nhiều càng tốt.

Các phương thứ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 camera, đối với tất cả các camera hiện có. Triển khai 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 các 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(), đồng thời định dạng xem trước là YCbCr_420_SP, dữ liệu trong byte[] được truyề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 camera đối với cả camera trước và camera sau của android.hardware.Camera. (Bộ mã hoá video phần cứng và camera có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng quá trình 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 làm đầu ra thông qua API android.media.ImageReader cho các thiết bị android.hardware.camera2 quảng cáo khả năng REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE trong android.request.availableCapabilities.
[C-0-5] VẪN PHẢI triển khai toàn bộ 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 khả năng khác. Ví dụ: những camera 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 camera 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 camera trước; chẳng hạn: mặc dù hầu hết camera trước không hỗ trợ tính năng tự động lấy nét, nhưng các lệnh gọi lại API vẫn phải được "giả lập" 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à một hằng số trong lớp android.hardware.Camera.Parameters và lớp android.hardware.camera2.CaptureRequest. Ngược lại, các cách triển khai thiết bị KHÔNG ĐƯỢC chấp nhận 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 những hằng số được ghi lại trên android.hardware.Camera.Parameters. Tức là các hoạt động triển khai thiết bị PHẢI hỗ trợ tất cả các tham số Camera tiêu chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại tham số Camera tuỳ chỉnh. Ví dụ: những chế độ triển khai thiết bị hỗ trợ chụp ảnh bằng kỹ thuật chụp ảnh dải động cao (HDR) PHẢI hỗ trợ tham số camera Camera.SCENE_MODE_HDR.
[C-0-7] PHẢI báo cáo mức độ 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 từng chức năng camera 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 có bất kỳ thiết bị camera nào được đính kèm hỗ trợ tính năng này.
[C-0-9] PHẢI truyền ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào camera chụp ảnh mới và mục nhập của ảnh đã được thêm vào kho lưu trữ đa phương tiện.
[C-0-10] PHẢI truyền ý định Camera.ACTION_NEW_VIDEO bất cứ khi nào camera quay một video mới và mục nhập của bức ảnh đã được thêm vào kho lưu trữ nội dung nghe nhìn.
[C-0-11] PHẢI có thể truy cập vào tất cả các camera thông qua API android.hardware.Camera không dùng nữa và cũng có thể truy cập thông qua API android.hardware.camera2.
[C-0-12] PHẢI đảm bảo rằng diện mạo 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, tông màu da mặt hoặc làm mịn da mặt cho bất kỳ android.hardware.camera2 hoặc API android.hardware.Camera nào.
[C-SR-1] Đối với các thiết bị có nhiều camera RGB ở gần và hướng về cùng một hướng, BẠN NÊN hỗ trợ một thiết bị camera logic liệt kê khả năng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, bao gồm tất cả các camera RGB hướng về hướng đó dưới dạng các thiết bị phụ vật lý.

Nếu các hoạt động triển khai thiết bị cung cấp một API camera độc quyền cho các ứng dụng bên thứ ba, thì:

[C-1-1] PHẢI triển khai API camera như vậy bằng API android.hardware.camera2.
CÓ THỂ cung cấp thẻ và/hoặc tiện ích của nhà cung cấp cho API android.hardware.camera2.

Nếu các hoạt động triển khai thiết bị điều chỉnh quy trình camera của bên thứ ba để ngang bằng với quy trình camera tích hợp cho camera trước chính và camera sau chính, thì:

[C-2-1] PHẢI khai báo thuộc tính hệ thống ro.camera.default_app_social_media_parity_enabled.

7.5.5. Hướng của camera

Nếu các chế độ triển khai thiết bị có camera trước hoặc camera sau, (các) camera đó phải:

[C-1-1] PHẢI được định hướng để chiều dài của camera phù hợp với chiều dài của màn hình. Tức là khi thiết bị được giữ ở hướng ngang, camera PHẢI chụp ảnh ở 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ả thiết bị có hướng ngang là hướng chính cũng như thiết bị có hướng dọc là hướng chính.

Những thiết bị đáp ứng một trong các tiêu chí sau sẽ được miễn tuân thủ yêu cầu này:
- Thiết bị triển khai màn hình có hình dạng thay đổi, chẳng hạn như màn hình có thể gập lại hoặc có bản lề VÀ 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).
- Những thiết bị mà người dùng không thể xoay, chẳng hạn như thiết bị trên ô tô.

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 thiết bị:

[C-0-1] PHẢI có một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ 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 từng tệp có kích thước ít nhất 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 thiết bị:

[C-0-1] PHẢI cung cấp bộ nhớ để các ứng dụng dùng chung, còn thường được 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ớ này đượ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à "ngay khi xuất xưởng", bất kể bộ nhớ được triển khai trên thành phần bộ nhớ trong hay phương tiện lưu trữ di động (ví dụ: khe cắm thẻ Secure Digital).
[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 thêm 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ừ trong 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 che khuất siêu dữ liệu vị trí (chẳng hạn như thẻ Exif GPS) được lưu trữ trong tệp nội dung nghe nhìn khi những tệp đó được truy cập thông qua MediaStore, trừ phi ứng dụng gọi điện có quyền ACCESS_MEDIA_LOCATION.

Các hoạt động triển khai thiết bị CÓ THỂ đáp ứng các yêu cầu nêu trên bằng cách sử dụng một trong những cách sau:

Bộ nhớ di động 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áo rời được) như được triển khai trong Dự án nguồn mở Android (AOSP).

Nếu các hoạt động triển khai thiết bị sử dụng bộ nhớ di động để đáp ứng các yêu cầu nêu trên, thì:

[C-1-1] PHẢI triển khai một giao diện người dùng dạng thông báo ngắn hoặc cửa sổ 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 cắm vào khe cắm.
[C-1-2] PHẢI có một phương tiện lưu trữ được định dạng FAT (ví dụ: thẻ SD) hoặc cho biết trên hộp và các 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 các phương thức triển khai thiết bị sử dụng một phần bộ nhớ không tháo rời được để đáp ứng các yêu cầu nêu trên, thì:

NÊN sử dụng chế độ triển khai AOSP của bộ nhớ dùng chung cho ứng dụng nội bộ.
CÓ THỂ chia sẻ không gian lưu trữ với dữ liệu riêng tư của ứng dụng.

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

[C-3-1] PHẢI cung cấp một 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 chủ.
NÊN hiển thị nội dung từ cả hai đường dẫn lưu trữ một cách minh bạch thông qua dịch vụ trình quét nội dung đa phương tiện của Android và android.provider.MediaStore.
CÓ THỂ sử dụng bộ nhớ lưu trữ lớn qua USB, nhưng NÊN sử dụng Giao thức truyền dữ liệu đa phương tiện để đáp ứng yêu cầu này.

Nếu các thiết bị triển khai có cổng USB ở chế độ thiết bị ngoại vi USB và hỗ trợ Giao thức truyền dữ liệu đa phương tiện, thì:

PHẢI tương thích với máy chủ MTP tham chiếu của Android, Truyền tệp của Android.
NÊN báo cáo một lớp 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 có tính di động (không giống như TV), thì các cách triển khai thiết bị là:

[C-SR-1] RẤT NÊN triển khai bộ nhớ thích ứng ở một vị trí ổn định lâu dài, vì việc vô tình ngắt kết nối bộ nhớ này có thể gây mất dữ liệu/hỏng dữ liệu.

Nếu cổng thiết bị lưu trữ di động ở một vị trí ổn định lâu dài, chẳng hạn như trong ngăn chứa pin hoặc nắp bảo vệ khác, thì các hoạt động triển khai thiết bị sẽ là:

[C-SR-2] RẤT NÊN triển khai bộ nhớ thích ứng.

7.7. USB

Định nghĩa

Chế độ USB host là khi một chế độ triển khai thiết bị hoạt động như USB host, cung cấp nguồn điện trên bus và giao tiếp với các thiết bị ngoại vi.
Chế độ thiết bị USB (còn gọi là chế độ thiết bị ngoại vi USB) là khi một chế độ triển khai thiết bị hoạt động như một thiết bị ngoại vi USB, kết nối với một máy chủ thông qua một cổng truyền dữ liệu và phản hồi các yêu cầu từ máy chủ.
Cổng USB được xác định là một cơ chế cung cấp khả năng kết nối USB, có thể là một ổ cắm USB thực hoặc một giao diện không theo tiêu chuẩn (ví dụ: chân pogo).

Nếu có cổng USB, các thiết bị triển khai sẽ:

NÊN hỗ trợ chế độ thiết bị USB.
NÊN hỗ trợ chế độ máy chủ USB.
NÊN hỗ trợ việc tắt tín hiệu dữ liệu qua USB.

7.7.1. Chế độ thiết bị USB

Nếu các hoạt động triển khai thiết bị có một cổng USB hỗ trợ chế độ thiết bị ngoại vi thiết bị:

[C-1-1] Cổng NÀY PHẢI kết nối được với một 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 đúng giá trị của iSerialNumber trong nội dung mô tả thiết bị theo 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,5 A và 3 A theo tiêu chuẩn điện trở Type-C và PHẢI phát hiện các thay đổi trong thông báo nếu bộ sạc hỗ trợ USB Type-C.

[C-SR-1] Cổng NÊN sử dụng kiểu dáng USB micro-B, micro-AB hoặc Type-C. Các thiết bị Android hiện có và thiết bị Android mới NÊN TUÂN THỦ 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 này PHẢI nằm ở dưới cùng của thiết bị (theo hướng tự nhiên) hoặc cho phép xoay màn hình phần mềm cho tất cả các ứng dụng (kể cả màn hình chính), để màn hình hiển thị chính xác khi thiết bị được định hướng với cổng ở dưới cùng. Bạn NÊN TUÂN THỦ các yêu cầu này đối với cả thiết bị Android hiện có và thiết bị 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] PHẢI triển khai chế độ hỗ trợ để rút dòng điện 1,5 A trong quá trình truyền dữ liệu và tiếng bíp HS như được chỉ định trong Quy cách sạc pin qua USB, bản sửa đổi 1.2. Các thiết bị Android hiện có và thiết bị Android 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 thuộc quyền sở hữu riêng sửa đổi điện áp Vbus vượt quá mức mặc định hoặc thay đổi vai trò của nguồn/bồn lưu trữ dữ liệu vì điều này có thể dẫn đến các vấn đề về khả năng tương tác với bộ sạc hoặc Thiết bị hỗ trợ các phương thức USB Power Delivery Standard. Mặc dù được gọi là "RẤT NÊN DÙNG", nhưng trong các phiên bản Android sau này, chúng tôi có thể YÊU CẦU tất cả cá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Ợ Power Delivery cho việc trao đổi vai trò dữ liệu và nguồn khi hỗ trợ USB Type-C và chế độ máy chủ USB.
NÊN hỗ trợ giao thức Power Delivery để sạc điện áp cao và hỗ trợ các Chế độ thay thế như xuất hình ảnh.
NÊN triển khai API và quy cách Phụ kiện mở Android (AOA) như được ghi trong tài liệu SDK Android.

Nếu các bản triển khai thiết bị có cổng USB và triển khai quy cách AOA, thì:

[C-2-1] PHẢI khai báo hỗ trợ cho tính năng phần cứng android.hardware.usb.accessory.
[C-2-2] Lớp bộ nhớ lưu trữ lớn USB PHẢI có chuỗi "android" ở cuối chuỗi iInterface mô tả giao diện của bộ nhớ lưu trữ lớn USB

7.7.2. Chế độ USB Host

Nếu các thiết bị triển khai có cổng USB hỗ trợ chế độ máy chủ lưu trữ, thì:

[C-1-1] PHẢI triển khai API máy chủ USB Android như được ghi trong SDK Android và PHẢI khai báo khả năng hỗ trợ cho 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. Họ PHẢI có một trong những điều kiện sau:
- Một cổng USB Type-C trên thiết bị hoặc đi kèm(các) cáp chuyển đổi một cổng độc quyền trên thiết bị thành một cổng USB Type-C tiêu chuẩn (thiết bị USB Type-C).
- Một cổng USB Type-A trên thiết bị hoặc đi kèm(các) cáp chuyển đổi một cổng độc quyền trên thiết bị thành cổng USB Type-A tiêu chuẩn.
- Một cổng USB micro-AB trên thiết bị, CẦN có cáp chuyển đổi sang cổng USB Type-A tiêu chuẩn.
[C-1-3] KHÔNG ĐƯỢC phép vận chuyển kèm theo một bộ chuyển đổi chuyển đổi từ cổng USB Type-A hoặc micro-AB sang cổng USB Type-C (ổ cắm).
[C-SR-1] RẤT NÊN triển khai lớp âm thanh USB như được ghi trong tài liệu về SDK Android.
NÊN hỗ trợ sạc thiết bị ngoại vi USB được kết nối ở chế độ máy chủ; quảng cáo dòng điện nguồn ít nhất là 1,5 A như được chỉ định trong phần Termination Parameters (Thông số chấm dứt) của USB Type-C Cable and Connector Specification Revision 1.2 (Thông số kỹ thuật về cáp và giắc cắm USB Type-C phiên bản 1.2) cho giắc cắm USB Type-C hoặc sử dụng phạm vi dòng điện đầu ra của Cổng sạc xuôi dòng (CDP) như được chỉ định trong USB Battery Charging specifications, revision 1.2 (Thông số kỹ thuật về sạc pin qua USB, phiên bản 1.2) cho giắc cắm Micro-AB.
NÊN triển khai và hỗ trợ các tiêu chuẩn USB Type-C.

Nếu các hoạt động triển khai thiết bị có cổng USB hỗ trợ chế độ máy chủ và lớp âm thanh USB, thì các hoạt động này:

[C-2-1] PHẢI hỗ trợ lớp USB HID.
[C-2-2] PHẢI hỗ trợ việc 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 HID qua USB và Yêu cầu sử dụng lệnh thoại với các hằng số KeyEvent như sau:
- Trang sử dụng (0xC) Mã nhận dạng mức sử dụng (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Trang sử dụng (0xC) Mã nhận dạng sử dụng (0x0E9): KEYCODE_VOLUME_UP
- Trang sử dụng (0xC) Mã nhận dạng 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 các hoạt động triển khai thiết bị có cổng USB hỗ trợ chế độ máy chủ và Khung truy cập bộ nhớ (SAF), thì các hoạt động này:

[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 các ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT.

Nếu các hoạt động triển khai thiết bị có cổng USB hỗ trợ chế độ máy chủ và USB Type-C, thì:

[C-4-1] PHẢI triển khai chức năng Nguồn điện có vai trò kép (DRP) theo quy định của thông số kỹ thuật USB Type-C (mục 4.5.1.3.3). Đối với các cổng DRP, trên những thiết bị có giắc cắm âm thanh 3,5 mm, tính năng phát hiện nguồn điện 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] RẤT NÊN hỗ trợ DisplayPort.
- NÊN hỗ trợ tốc độ truyền dữ liệu USB SuperSpeed.
- Bạn NÊN HỖ TRỢ Power Delivery để trao đổi vai trò dữ liệu và nguồn.
[C-SR-3] KHÔNG NÊN hỗ trợ Chế độ Phụ kiện Đầu nối âm thanh như mô tả trong Phụ lục A của Quy cách Cáp và Đầu nối USB Type-C phiên bản 1.2.
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.7.3. USB Power Delivery

Nếu các thiết bị triển khai có cổng USB Type-C, thì:

[C-SR-1] RẤT NÊN triển khai Lớp giắc cắm USB Type-C của nhân và triển khai các nút cần thiết để mô tả các vai trò kết nối, nguồn và dữ liệu của USB Type-C. Hãy tham khảo Tài liệu về USB Type-C trên Android để biết thông tin chi tiết về cách triển khai.

Nếu các hoạt động triển khai thiết bị có cổng USB Type-C và hỗ trợ cấp nguồn, thì:

[C-SR-2] RẤT NÊN triển khai tất cả các nút mô tả tính năng USB Power Delivery. Hãy tham khảo Tài liệu về USB PD trên Android để biết thông tin chi tiết về cách triển khai.

Nếu các thiết bị triển khai có cổng USB Type-C và hỗ trợ các chế độ thay thế, thì:

[C-SR-3] NÊN TRIỂN KHAI Chế độ thay thế và các thuộc tính liên quan đến danh tính của Lớp đầu nối USB Type-C của hạt nhân. Hãy tham khảo Tài liệu về USB Type-C trên Android để biết thông tin chi tiết về cách triển khai.

Nếu các thiết bị triển khai có cổng USB Type-C và hỗ trợ chế độ thay thế Thunderbolt 3, thì:

[C-SR-4] BẠN NÊN TRIỂN KHAI khả năng ghi đè chế độ thay thế hiện tại thông qua lớp trình kết nối loại C.

7.8. Âm thanh

7.8.1. Micrô

Nếu các hoạt động triển khai thiết bị có micrô, thì:

[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] RẤT NÊN hỗ trợ ghi âm gần siêu âm như mô tả trong mục 7.8.3.

Nếu các hoạt động triển khai thiết bị bỏ qua micrô, thì:

[C-2-1] KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.microphone.
[C-2-2] PHẢI triển khai API ghi âm ít nhất là dưới dạng không có thao tác, theo mục 7.

7.8.2. Đầu ra âm thanh

Nếu các chế độ triển khai thiết bị có 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 cắm âm thanh 3,5 mm 4 đầu cắm hoặc cổng chế độ máy chủ USB bằng lớp âm thanh USB, thì:

[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ề chế độ 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] RẤT NÊN hỗ trợ chế độ phát gần siêu âm như mô tả trong mục 7.8.3.

Nếu các hoạt động triển khai thiết bị không có loa hoặc cổng đầu ra âm thanh, thì:

[C-2-1] KHÔNG ĐƯỢC báo cáo tính năng android.hardware.audio.output.
[C-2-2] Ít nhất PHẢI triển khai các API liên quan đến Đầu ra âm thanh dưới dạng các thao tác không có tác dụng.

Trong 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. Việc 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ó "cổng đầu ra".

7.8.2.1. Cổng âm thanh analog

Để tương thích với tai nghe và các phụ kiện âm thanh khác sử dụng giắc cắm âm thanh 3,5 mm trên hệ sinh thái Android, nếu các thiết bị triển khai có một hoặc nhiều cổng âm thanh tương tự, thì các cổng này phải:

[C-SR-1] BẠN NÊN CÂN NHẮC để có ít nhất một(các) cổng âm thanh là giắc cắm âm thanh 3,5 mm có 4 đầu cắm.

Nếu các thiết bị triển khai có giắc cắm âm thanh 3,5 mm 4 cực, thì:

[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ợ việc phát hiện và liên kết với mã khoá 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 giắc cắm, nhưng chỉ sau khi tất cả các chân trên giắc cắm chạm vào các đoạn liên quan trên giắc cắm.
[C-1-5] PHẢI có khả năng truyền ít nhất 150 mV ± 10% điện áp đầu ra trên trở kháng loa 32 ohm.
[C-1-6] PHẢI có điện áp thiên vị của micrô trong khoảng từ 1,8 V đến 2,9 V.
[C-1-7] PHẢI phát hiện và liên kết với mã khoá cho 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:
- 110 – 180 ohm: KEYCODE_VOICE_ASSIST
[C-SR-2] RẤT NÊN hỗ trợ giắc cắm âm thanh có thứ tự chân cắm OMTP.
[C-SR-3] RẤT NÊN hỗ trợ ghi âm từ tai nghe âm thanh nổi có micrô.

Nếu các chế độ triển khai thiết bị có giắc cắm âm thanh 3,5 mm 4 cực và hỗ trợ micrô, đồng thời truyền android.intent.action.HEADSET_PLUG với giá trị bổ sung micrô được đặt thành 1, thì:

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

Hãy xem Mục 2.2.1 để biết các yêu cầu cụ thể đối với từng thiết bị.

7.8.3. Gần với sóng siêu âm

Âm thanh cận siêu âm nằm trong dải tần từ 18,5 kHz đến 20 kHz.

Triển khai 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] Phản hồi công suất trung bình của micrô trong dải tần từ 18,5 kHz đến 20 kHz KHÔNG ĐƯỢC thấp hơn 15 dB so với phản hồi ở tần số 2 kHz.
[C-1-2] Tỷ lệ tín hiệu trên tạp âm không trọng số của micrô trong khoảng 18,5 kHz đến 20 kHz đối với âm 19 kHz ở mức -26 dBFS PHẢI không thấp hơn 50 dB.

Nếu PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND là "true":

[C-2-1] Phản hồi trung bình của loa trong dải tần từ 18,5 kHz đến 20 kHz KHÔNG ĐƯỢC thấp hơn 40 dB so với phản hồi ở tần số 2 kHz.

7.8.4. Tính toàn vẹn của tín hiệu

Triển khai thiết bị:

NÊN cung cấp một đường dẫn tín hiệu âm thanh không bị gián đoạn cho cả luồng đầu vào và đầu ra trên thiết bị cầm tay, như được xác định bằng 0 lần gián đoạn đo được trong một lần 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".

Bài kiểm thử này yêu cầu phải có một thiết bị phần cứng vòng lặp âm thanh, được dùng trực tiếp trong giắc cắm 3,5 mm và/hoặc kết hợp với một bộ chuyển đổi USB-C sang giắc cắm 3,5 mm. Bạn NÊN kiểm thử tất cả cá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ế độ hiệu suất	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	ĐÃ CHIA SẺ	48000	1	2
KHÔNG	ĐÃ CHIA SẺ	48000	2	1
KHÔNG	ĐÃ CHIA SẺ	44100	1	2
KHÔNG	ĐÃ CHIA SẺ	44100	2	1
KHÔNG	ĐÃ CHIA SẺ	16000	1	2
KHÔNG	ĐÃ CHIA SẺ	16000	2	1

Một luồng đáng tin cậy PHẢI đáp ứng các tiêu chí sau về Tỷ lệ tín hiệu trên nhiễu (SNR) và Tổng độ méo hài (THD) cho sóng hình 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 3,5 mm tương tự tích hợp sẵn, đượ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 có các API và cơ sở vật chất để tạo các ứ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. Các hoạt động triển khai trên thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được trình bày chi tiết trong phần này.

7.9.1. Chế độ thực tế ảo

Android có hỗ trợ Chế độ thực tế ảo, một tính năng xử lý việc kết xuất hình ảnh lập thể của thông báo và vô hiệu hoá các thành phần Giao diện người dùng hệ thống đơn nhãn trong 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 hoạt động triển khai thiết bị hỗ trợ chế độ thực tế ảo, thì:

[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.
NÊN 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 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 có sẵn.
[C-SR-1] 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 có sẵn.
[C-SR-2] RẤT NÊN hỗ trợ Vulkan 1.1.
[C-SR-3] RẤT 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] RẤT NÊN sử dụng ít nhất một họ hàng đợi Vulkan, trong đó flags chứa cả VK_QUEUE_GRAPHICS_BIT và VK_QUEUE_COMPUTE_BIT, đồng thời queueCount ít nhất là 2.
[C-1-7] GPU và màn hình PHẢI có khả năng đồng bộ hoá quyền truy cập vào bộ đệm trước dùng chung để quá trình kết xuất nội dung thực tế ảo bằng mắt xen kẽ ở tốc độ 60 khung hình/giây với 2 ngữ cảnh kết xuất sẽ hiển thị mà không có hiện tượng xé hình.
[C-1-9] PHẢI triển khai tính năng hỗ trợ cho các 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 hỗ trợ cho AHardwareBuffer với mọi tổ hợp 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] RẤT NÊN hỗ trợ việc phân bổ AHardwareBuffer có 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 ít nhất là 3840 x 2160 ở tốc độ 30 khung hình/giây, được nén xuống mức trung bình 40 Mb/giây (tương đương với 4 trường hợp 1920 x 1080 ở tốc độ 30 khung hình/giây – 10 Mb/giây hoặc 2 trường hợp 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 1920 x 1080 ở tốc độ 30 khung hình/giây được nén xuống mứ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 trường hợp 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ề các giá trị chính xác cho nhiệt độ trên da.
[C-1-14] PHẢI có màn hình nhúng và độ phân giải của màn hình đó PHẢI tối thiểu là 1920 x 1080.
[C-SR-6] RẤT 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ế độ duy trì thấp với thời gian duy trì ≤ 5 mili giây, trong đó thời gian duy trì được xác định là khoảng thời gian mà một pixel phát ra ánh sáng.
[C-1-18] PHẢI hỗ trợ Bluetooth 4.2 và 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 chính xác Loại kênh trực tiếp cho tất cả các loại cảm biến mặc định sau đây:
- 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ế đối với android.hardware.hifi_sensors, như được chỉ định trong mục 7.3.9.
[C-SR-8] RẤT NÊN hỗ trợ tính năng android.hardware.sensor.hifi_sensors.
[C-1-22] PHẢI có độ trễ từ chuyển động đến photon không quá 28 mili giây.
[C-SR-9] RẤT NÊN có độ trễ chuyển động đến photon từ đầu đến cuối không quá 20 mili giây.
[C-1-23] PHẢI có tỷ lệ khung hình đầu tiên (tỷ lệ giữa độ sáng của các pixel trên khung hình đầu tiên sau khi chuyển từ màu đen sang màu trắng và độ sáng của các pixel màu trắng ở trạng thái ổn định) ít nhất là 85%.
[C-SR-10] BẠN 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 riêng cho ứng dụng ở 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 ở nền trước trên cùng.

Nếu được hỗ trợ lõi độc quyền, thì lõi:

[C-2-1] KHÔNG ĐƯỢC 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 thiết.

7.10. Xúc giác

Các thiết bị cầm tay hoặc thiết bị đeo có thể bao gồm một bộ truyền động xúc giác đa năng, được cung cấp cho các ứng dụng nhằm mục đích thu hút sự chú ý thông qua nhạc chuông, chuông báo, thông báo, cũng như phản hồi xúc giác chung.

Nếu các hoạt động triển khai thiết bị KHÔNG bao gồm bộ truyền động xúc giác đa năng như vậy, thì:

[7.10/C] PHẢI trả về giá trị false cho Vibrator.hasVibrator().

Nếu các quy trình triển khai thiết bị CÓ ít nhất một bộ truyền động xúc giác đa năng như vậy, thì:

[C-1-1] PHẢI trả về giá trị true cho Vibrator.hasVibrator().
KHÔNG NÊN sử dụng bộ truyền động xúc giác (bộ rung) có khối lượng quay lệch tâm (ERM).
NÊN triển khai tất cả các hằng số công khai cho phản hồi xúc giác rõ ràng trong android.view.HapticFeedbackConstants, cụ thể là (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START và GESTURE_END).
NÊN triển khai tất cả các hằng số công khai cho phản hồi xúc giác rõ ràng trong android.os.VibrationEffect, cụ thể là (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK và EFFECT_DOUBLE_CLICK) và tất cả các hằng số PRIMITIVE_* công khai khả thi cho phản hồi xúc giác phong phú trong android.os.VibrationEffect.Composition, cụ thể là (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Một số thành phần cơ bản trong số này, chẳng hạn như LOW_TICK và SPIN, chỉ có thể khả thi nếu bộ rung hỗ trợ tần số tương đối thấp.
NÊN tuân theo hướng dẫn về cách 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, cùng với các mối quan hệ biên độ tương ứng.
NÊN sử dụng các mối liên kết hằng số xúc giác được liên kết này.
NÊN tuân theo đánh giá chất lượng cho API createOneShot() và createWaveform().
NÊN xác minh rằng kết quả của API android.os.Vibrator.hasAmplitudeControl() công khai phản ánh chính xác các chức năng của thiết bị rung.
NÊN xác minh các chức năng về khả năng mở rộng biên độ bằng cách chạy android.os.Vibrator.hasAmplitudeControl().

Nếu các hoạt động triển khai thiết bị tuân theo quy trình liên kết hằng số xúc giác, thì:

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 (nếu cần) cấu hình dự phòng cho các nguyên tắc không được hỗ trợ như mô tả trong hướng dẫn triển khai cho các hằng số.
NÊN cung cấp chế độ hỗ trợ dự phòng để giảm thiểu nguy cơ thất bại như mô tả tại đây.

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ừ R (phiên bản 30). Giá trị đặc biệt 0 chỉ định rằng thiết bị không thuộc lớp hiệu suất đa phương tiện.

Nếu các phương thứ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-1-1] PHẢI trả về ít nhất một giá trị android.os.Build.VERSION_CODES.R.
[C-1-2] PHẢI là một 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ể đối với thiết bị.

8. Hiệu suất và sức mạnh

Một số tiêu chí tối thiểu về hiệu suất và mức tiêu thụ điện năng là 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ơ bản mà nhà phát triển sẽ có khi phát triển một ứng dụng.

8.1. Tính nhất quán trong trải nghiệm người dùng

Bạn có thể cung cấp giao diện người dùng mượt mà cho người dùng cuối 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. Tuỳ thuộc vào loại thiết bị, các hoạt động triển khai thiết bị CÓ THỂ có các yêu cầu có thể đo lường về độ 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 đối với tệp

Việc cung cấp một đường cơ sở chung để có hiệu suất truy cập tệp nhất quán trên bộ nhớ dữ liệu riêng tư 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 họ thiết kế phần mềm. Các hoạt động 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 mục 2 cho các hoạt động đọc và ghi sau đây:

Hiệu suất ghi tuần tự. Được đo bằng cách ghi tệp 256 MB bằng bộ đệm ghi 10 MB.
Hiệu suất ghi ngẫu nhiên. Được đo bằng cách ghi một tệp 256 MB bằng bộ đệm ghi 4 KB.
Hiệu suất đọc tuần tự. Được đo bằng cách đọc một tệp 256 MB bằng bộ đệm ghi 10 MB.
Hiệu suất đọc ngẫu nhiên. Được đo bằng cách đọc một tệp 256 MB bằng bộ đệm ghi 4 KB.

8.3. Chế độ tiết kiệm pin

Nếu các hoạt động triển khai thiết bị có các tính năng cải thiện khả năng quản lý nguồn của thiết bị có trong AOSP (ví dụ: Nhóm chế độ chờ ứng dụng, Chế độ Doze) 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 Nhóm chế độ chờ ứng dụng BỊ HẠN CHẾ, thì các hoạt động triển khai đó:

[C-1-1] KHÔNG ĐƯỢC đi lệch khỏi việc triển khai AOSP cho các thuật toán kích hoạt, duy trì, đánh thức và việc sử dụng chế độ cài đặt hệ thống chung hoặc DeviceConfig của chế độ chờ ứng dụng và chế độ tiết kiệm pin Doze.
[C-1-2] KHÔNG ĐƯỢC đi lệch khỏi việc 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ác công việc, chuông báo và mạng cho các ứng dụng trong mỗi nhóm cho chế độ Chờ của ứng dụng.
[C-1-3] KHÔNG ĐƯỢC đi lệch khỏi cách triển khai AOSP về số lượng Nhóm chế độ chờ ứng dụng được dùng cho Chế độ chờ ứng dụng.
[C-1-4] PHẢI triển khai Chế độ chờ ứng dụng theo nhóm 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 chế độ Chờ của ứng dụng và chế độ Nghỉ hoặc mọi chế độ tối ưu hoá pin và PHẢI triển khai ý định ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS để yêu cầu người dùng cho phép một ứng dụng bỏ qua các chế độ tối ưu hoá pin.
[C-SR-1] RẤT 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] RẤT 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 chế độ chờ ứng dụng và chế độ Nghỉ tiết kiệm pin.

Nếu các hoạt động 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 Bộ chứa chế độ chờ ứng dụng hiếm, hãy tham khảo mục 3.5.1.

Ngoài các chế độ tiết kiệm pin, các hoạt động 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 ở chế độ ngủ như được xác định bởi Giao diện nguồn và cấu hình nâng cao (ACPI).

Nếu các hoạt động triển khai thiết bị triển khai trạng thái nguồn S4 theo định nghĩa của ACPI, thì:

[C-1-1] CHỈ ĐƯỢC phép 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 bộ phận vật lý của thiết bị hoặc tắt xe hoặc tivi) 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 tivi).

Nếu các hoạt động triển khai thiết bị triển khai trạng thái nguồn S3 theo định nghĩa của ACPI, thì:

[C-2-1] PHẢI đáp ứng yêu cầu 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, bạn 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ữ cho 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, vào 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 gử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 nhiều tín hiệu đánh thức để kích hoạt quá trình đá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 ghi nhậ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ả động lực và công cụ để tối ưu hoá mẫu sử dụng điện của ứng dụng.

Triển khai thiết bị:

[C-SR-1] RẤT NÊN cung cấp một hồ sơ sử dụng điện cho từng thành phần, xác định giá trị mức tiêu thụ hiện tại cho từng thành phần phần cứng và mức tiêu hao pin ước tính do các thành phần gây ra theo thời gian như được ghi lại trong trang web Dự án nguồn mở Android.
[C-SR-2] RẤT NÊN báo cáo tất cả các giá trị tiêu thụ điện năng theo đơn vị miliampe giờ (mAh).
[C-SR-3] RẤT NÊN báo cáo mức tiêu thụ điện năng của CPU cho mỗi UID của 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] RẤT NÊN cung cấp mức sử dụng điện này thông qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.
NÊN được quy cho chính thành phần phần cứng nếu không thể quy mức sử dụng điện của thành phần phần cứng cho một ứng dụng.

8.5. Hiệu suất ổn định

Hiệu suất có thể dao động đáng kể đối với các ứng dụng hiệu suất cao chạy trong thời gian dài, có thể là do các ứng dụng khác chạy ở chế độ nền hoặc do CPU bị điều tiết vì giới hạn nhiệt độ. Android có các giao diện có lập trình để khi thiết bị có khả năng, ứng dụng hàng đầu ở 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 thiết bị:

[C-0-1] PHẢI báo cáo chính xác khả năng hỗ trợ Chế độ hiệu suất cao bền vững thông qua phương thức API PowerManager.isSustainedPerformanceModeSupported().
NÊN hỗ trợ Chế độ hiệu suất cao bền vững.

Nếu các hoạt động triển khai thiết bị báo cáo việc hỗ trợ Chế độ hiệu suất cao bền vững, thì:

[C-1-1] PHẢI cung cấp cho ứng dụng hàng đầu ở 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 khác có liên quan.

Nếu các hoạt động triển khai thiết bị có từ 2 lõi CPU trở lên, thì:

NÊN cung cấp ít nhất một lõi dành riêng mà ứng dụng nền trước hàng đầu có thể đặt trước.

Nếu các hoạt động triển khai thiết bị hỗ trợ việc dành riêng một lõi độc quyền cho ứng dụng hàng đầu ở nền trước, thì các hoạt động triển khai đó sẽ:

[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 lõi dành riêng mà ứng dụng trên nền trước hàng đầu có thể đặt trước.
[C-2-2] KHÔNG ĐƯỢC 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 dùng để chạy trên các lõi riêng biệt, nhưng CÓ THỂ cho phép một số quy trình hạt nhân chạy khi cần thiết.

Nếu các hoạt động triển khai thiết bị không hỗ trợ một lõi riêng biệt, thì:

[C-3-1] PHẢI trả về một danh sách trống thông qua phương thức API Process.getExclusiveCores().

8.6. Giới hạn bộ nhớ của ứng dụng

MemoryLimiter (một thành phần mới của ActivityManagerService) và giới hạn bộ nhớ mặc định của ứng dụng (xuất phát từ bộ nhớ thực có sẵn) sẽ áp đặt giới hạn về lượng DRAM được dùng cho mỗi quy trình ứng dụng riêng lẻ. Hạn chế này áp dụng cho tất cả bộ nhớ được phân bổ trong quy trình ứng dụng, đảm bảo rằng các giới hạn hoạt động như hành vi theo hợp đồng quan trọng với nhà phát triển ứng dụng.

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC sử dụng bất kỳ phương thức, danh sách cho phép hoặc chính sách nào để bỏ qua giới hạn bộ nhớ thời gian chạy được đặt cho các ứng dụng.

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

Triển khai thiết bị:

[C-0-1] PHẢI 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ề bảo mật và quyền 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ợ việc cài đặt các ứng dụng tự ký mà không yêu cầu bất kỳ quyền/chứng chỉ bổ sung nào từ bất kỳ bên thứ ba/cơ quan nào.

Nếu các hoạt động triển khai thiết bị khai báo tính năng android.hardware.security.model.compatible, thì:

[C-1-1] PHẢI hỗ trợ các yêu cầu được nêu trong các mục con sau.

9.1. Quyền

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình quản lý quyền Android và Mô hình vai trò Android như được xác định trong tài liệu dành cho nhà phát triển Android. Cụ thể, họ PHẢI thực thi từng quyền và vai trò được xác định như mô tả trong tài liệu SDK; không được bỏ qua, sửa đổi hoặc bỏ qua quyền và vai trò nào.
CÓ THỂ thêm các quyền bổ sung, miễn là các 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 của 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 hình ả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 đưa vào danh sách cho phép một cách 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 đưa vào 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.
[C-SR-1] Bạn NÊN CHỈ cấp những quyền có protectionLevel là PROTECTION_SIGNATURE cho một trong hai đối tượng sau:
- Các ứng dụng được cài đặt sẵn trên hình ảnh hệ thống (cũng như tệp APEX).
- Các ứng dụng được đưa vào danh sách cho phép cùng với các quyền được phép nếu chúng không có trong hình ảnh hệ thống.
Lưu ý: 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 đưa vào danh sách cho phép đối với từng ứng dụng từ các tệp trong đường dẫn etc/permissions/.

Các quyền có mức độ bảo vệ nguy hiểm là các quyền khi bắt đầu chạy. Các ứng dụng có targetSdkVersion > 22 yêu cầu các quyền này trong thời gian chạy.

Triển khai thiết bị:

[C-0-3] PHẢI hiển thị một giao diện chuyên biệt để người dùng quyết định có cấp 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-5] KHÔNG ĐƯỢC cấp bất kỳ quyền nào khi bắt đầu chạy cho ứng dụng, trừ phi:
- Chúng được cài đặt tại thời điểm thiết bị được vận chuyển, VÀ
- Bạn có thể nhận được sự đồng ý của người dùng trước khi ứng dụng sử dụng quyền này,
HOẶC
- Quyền trong thời gian 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 những ứng dụng hệ thống đăng ký một Recovery Agent được bảo mật đúng cách. Tác nhân khôi phục được bảo mật đúng cách được định nghĩa là một tác nhân phần mềm trên thiết bị, đồng bộ hoá với 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 những gì được mô tả trong Dịch vụ kho khoá trên Google Cloud để ngăn chặn các cuộc tấn công dò tìm mật khẩu đối với yếu tố kiến thức trên màn hình khoá.

Triển khai 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í trên Android khi ứng dụng yêu cầu dữ liệu vị trí hoặc dữ liệu hoạt động thể chất thông qua API Android tiêu chuẩn hoặc cơ chế thuộc quyền sở hữu riêng. Những dữ liệu này 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ể được dùng để xác định hoặc ước tính vị trí của thiết bị (ví dụ: SSID, BSSID, Cell ID 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 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ó đượ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 dữ liệu 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 nêu trên là đối với những ứng dụng không truy cập vào Dịch vụ vị trí để lấy hoặc xác định vị trí của người dùng; cụ thể:

Khi các ứ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 có quyền NETWORK_SETTINGS hoặc NETWORK_SETUP_WIZARD.

Bạn có thể đánh dấu các quyền là bị hạn chế để thay đổi hành vi của chúng.

[C-0-10] Bạn KHÔNG ĐƯỢC cấp cho ứng dụng những quyền được đánh dấu bằng cờ hardRestricted, 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ò được 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.
- Một ứng dụng được cấp quyền hardRestricted trên một phiên bản Android cũ.
[C-0-11] Các ứng dụng có quyền softRestricted CHỈ ĐƯỢC PHÉP có quyền truy cập hạn chế và KHÔNG ĐƯỢC PHÉP có toàn quyền truy cập cho đến khi được đưa vào danh sách cho phép như mô tả trong SDK, trong đó toàn quyền truy cập và quyền truy cập 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 các API AppOpsManager để ghi lại và theo dõi từng quyền truy cập theo chương 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ụ của Android.
[C-0-14] CHỈ ĐƯỢC phép chỉ định vai trò cho những ứ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 là tập hợp con của các vai trò do nền tảng xác định.

Nếu thiết bị có các cảm biến dữ liệu cung cấp thông tin sinh trắc học liên quan đến sức khoẻ, chẳng hạn như tần số tim hoặc nhiệt độ trên da, thì những thông tin sinh trắc học đó:

[C-0-16] PHẢI được bảo vệ bằng các quyền của nền tảng từ android.permission-group.HEALTH, nếu có quyền tương ứng trong HealthPermissions.
[C-0-17] PHẢI được bảo vệ bằng một quyền tuỳ chỉnh của hệ thống nếu không có quyền nào trên nền tảng khớp với kiểu dữ liệu mong muốn. (Ví dụ: ELECTROCARDIOGRAM.)

Nếu thiết bị báo cáo android.software.managed_users, thì:

[C-1-1] KHÔNG ĐƯỢC có các quyền sau đây do quản trị viên cấp ngầm:
- Vị trí (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Camera (CAMERA)
- Micrô (RECORD_AUDIO)
- Cảm biến cơ thể (BODY_SENSORS)
- Sức khoẻ (HealthPermissions)
- Hoạt động thể chất (ACTIVITY_RECOGNITION)

Nếu thiết bị báo cáo android.software.managed_users, thì:

[C-1-1] KHÔNG ĐƯỢC có các quyền sau đây do quản trị viên cấp ngầm:
- Vị trí (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Camera (CAMERA)
- Micrô (RECORD_AUDIO)
- Cảm biến cơ thể (BODY_SENSORS)
- Hoạt động thể chất (ACTIVITY_RECOGNITION)

Nếu các phương thức triển khai thiết bị cung cấp cho người dùng một thành phần để chọn ứng dụng có thể vẽ lên trên các ứng dụng khác bằng một Hoạt động xử lý ý định ACTION_MANAGE_OVERLAY_PERMISSION, thì:

[C-2-1] PHẢI đảm bảo rằng tất cả các hoạt động có bộ lọc ý định cho ý định ACTION_MANAGE_OVERLAY_PERMISSION đều có cùng 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-3-1] PHẢI hiện một 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ý hoàn toàn (thiết lập của chủ sở hữu thiết bị) nêu rõ rằng quản trị viên CNTT sẽ có khả năng cho phép các ứng dụng kiểm soát chế độ cài đặt trên điện thoại, bao gồm cả micrô, camera 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 quá trình thiết lập TRỪ KHI quản trị viên đã chọn không kiểm soát các quyền trên thiết bị.

Nếu các hoạt động triển khai thiết bị cài đặt trước bất kỳ gói nào có bất kỳ vai trò nào sau đây: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence hoặc System Visual Intelligence, thì các gói đó phải:

[C-4-1] PHẢI đáp ứng tất cả các yêu cầu được nêu cho việc triển khai thiết bị trong các phần 9.8.6. Dữ liệu ở cấp hệ điều hành và dữ liệu môi trường và 9.8.15. Triển khai API Hộp cát.

9.2. UID và tính năng Tách biệt quy trình

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình hộp cát ứng dụng Android, trong đó mỗi ứng dụng chạy dưới dạng một UID theo 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 dướ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ề Bảo mật và quyền.

9.3. Quyền truy cập hệ thống tệp

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình quản lý 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ế

Các hoạt động 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 chúng bao gồm các môi trường thời gian chạy thực thi các ứng dụng bằng một số phần mềm hoặc công nghệ khác ngoài Định dạng tệp thực thi Dalvik hoặc mã gốc. Nói cách khác:

[C-0-1] Bản thay thế của các môi trường thời gian chạy PHẢI là các ứ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] Các môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cấp quyền truy cập vào các tài nguyên được bảo vệ bằng những 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] Các môi trường thời gian chạy thay thế KHÔNG ĐƯỢC phép các ứng dụng sử dụng những tính năng được Android bảo vệ bằng các quyền Android chỉ dành cho ứng dụng hệ thống.
[C-0-4] Các môi trường thời gian chạy thay thế PHẢI tuân thủ mô hình hộp cát của Android và các ứng dụng đã cài đặt bằng môi trường thời gian chạy thay thế KHÔNG ĐƯỢC 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ế tiêu chuẩn của Android về mã nhận dạng người dùng dùng chung và chứng chỉ ký.
[C-0-5] Các môi trường thời gian chạy thay thế KHÔNG ĐƯỢC khởi chạy, cấp hoặc được cấp quyền truy cập vào các hộp cát tương ứng với các ứng dụng Android khác.
[C-0-6] Các môi trường thời gian chạy thay thế KHÔNG ĐƯỢC khởi chạy, được cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của siêu người dùng (root) hoặc của bất kỳ mã nhận dạng người dùng nào khác.
[C-0-7] Khi các tệp .apk của thời gian chạy thay thế được đưa vào hình ảnh hệ thống của các chế độ triển khai thiết bị, thì TỆP này PHẢI được ký bằng một khoá riêng biệt với khoá dùng để ký các ứng dụng khác có trong các chế độ triển khai thiết bị.
[C-0-8] Khi cài đặt ứng dụng, các môi trường thời gian chạy thay thế PHẢI nhận được sự đồng ý của người dùng đối với các quyền Android mà ứng dụng sử dụng.
[C-0-9] Khi một ứng dụng cần sử dụng một tài nguyên trên thiết bị mà có quyền tương ứng trên Android (chẳng hạn như Camera, GPS, v.v.), thì 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 thời gian chạy nắm giữ khi cài đặt bất kỳ ứng dụng nào bằng thời gian chạy đó.
Các 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.).
Các 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 được chia sẻ bởi tất cả các ứng dụng sử dụng môi trường thời gian chạy thay thế.

9.5. Hỗ trợ nhiều người dùng

Android có hỗ trợ nhiều người dùng và hỗ trợ tính năng phân lập hoàn toàn người dùng cũng như sao chép hồ sơ người dùng với khả năng phân lập một phần (tức là hồ sơ người dùng bổ sung duy nhất thuộc loại android.os.usertype.profile.CLONE).

Các chế độ triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN bật chế độ nhiều người dùng nếu chúng sử dụng phương tiện di động cho bộ nhớ ngoài chính.

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

[C-1-2] PHẢI 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 cho từng người dùng như được xác định trong Tài liệu tham khảo về bảo mật và quyền trong API.
[C-1-3] PHẢI có các thư mục lưu trữ ứng dụng dùng chung riêng biệt và biệt lập (còn gọi là /sdcard) cho từng phiên bản người dùng.
[C-1-4] PHẢI đảm bảo rằng các ứng dụng thuộc sở hữu của một người dùng nhất định và chạy thay cho người dùng đó không thể liệt kê, đọc hoặc ghi vào các tệp thuộc sở hữu của bất kỳ người dùng nào khác, ngay cả khi dữ liệu của cả hai người dùng được lưu trữ trên cùng một ổ đĩa 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 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 truy cập được nếu các hoạt động 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 chủ không đọc được nội dung nghe nhìn, nên các hoạt động triển khai thiết bị sẽ phải chuyển sang MTP hoặc một hệ thống tương tự để cung cấp cho máy tính chủ quyền truy cập vào dữ liệu của người dùng hiện tại.

Nếu các hoạt động triển khai thiết bị 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 hai phiên bản của cùng một ứng dụng), họ sẽ:

[C-2-1] PHẢI có các thư mục lưu trữ ứng dụng dùng chung riêng biệt và biệt lập (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 thuộc sở hữu và chạy thay cho một người dùng nhất định không thể liệt kê, đọc hoặc ghi vào các tệp thuộc sở hữu của bất kỳ người dùng nào khác, ngay cả khi dữ liệu của cả hai người dùng được lưu trữ trên cùng một ổ đĩa hoặc hệ thống tệp.

Các hoạt động 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 hai phiên bản của cùng một ứng dụng. Hai phiên bản này dùng chung bộ nhớ bị cô lập một phần, được trình bày cho người dùng cuối trong trình chạy 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 API này để hỗ trợ người dùng cài đặt 2 phiên bản riêng biệt của một ứng dụng trên thiết bị có 2 SIM.

Nếu các hoạt động 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-3-1] CHỈ ĐƯỢC PHÉP cung cấp quyền truy cập vào bộ nhớ hoặc dữ liệu mà hồ sơ người dùng chính đã có thể truy cập hoặc thuộc 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 có hồ sơ công việc này.
[C-3-3] PHẢI có các thư mục dữ liệu ứng dụng riêng tư riêng biệt với tài khoản người dùng chính.
[C-3-4] KHÔNG ĐƯỢC phép tạo hồ sơ người dùng bổ sung nếu có một Chủ sở hữu thiết bị được cung cấp (xem phần 3.9.1) hoặc cho phép cung cấp một Chủ sở hữu thiết bị mà không xoá hồ sơ người dùng bổ sung trước.

Nếu các hoạt động 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-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 theo chính sách thiết bị và restrictions(list below) không phải người dùng đã chọn được áp dụng cho người dùng chính của thiết bị vào hồ sơ người dùng bổ sung này.
[C-4-3] CHỈ ĐƯỢC 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 đang chạy trong hồ sơ người dùng bổ sung này.
[C-4-5] CHỈ ĐƯỢC PHÉP các ứng dụng trong hồ sơ bổ sung có hoạt động của trình chạy truy cập vào danh bạ mà hồ sơ người dùng chính đã có thể truy cập.

Nếu các hoạt động 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 hoạt động này phải có ít nhất một camera và ứng dụng camera được cài đặt sẵn sẽ xử lý các ý định MediaStore.ACTION_MOTION_PHOTO_CAPTURE hoặc MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, cụ thể:

[C-5-1] PHẢI cho phép các ứng dụng của người dùng chính xử lý những ý định này bắt nguồn từ hồ sơ người dùng bổ sung đó.

9.6. Cảnh báo về tin nhắn dịch vụ

Android hỗ trợ cảnh báo cho người dùng về mọi tin nhắn SMS dịch vụ cao cấp gửi đi. Tin nhắn dịch vụ là tin nhắn văn bản được gửi đến một dịch vụ đã đăng ký với một 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-1-1] PHẢI cảnh báo cho người dùng trước khi gửi tin nhắn SMS đến những 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 thượng nguồn cung cấp một phương thức triển khai đáp ứng yêu cầu này.

9.7. Security Features

Các hoạt động 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ả 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) Security-Enhanced Linux (SELinux), hộp cát seccomp và các tính năng bảo mật khác trong kernel Linux. Triển khai 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 phát hiện thấy hành vi vi phạm bảo mật và tính năng bảo mật được triển khai bên dưới khung Android đã chặn thành công hành vi đó, nhưng CÓ THỂ có giao diện người dùng hiển thị khi xảy ra hành vi vi phạm bảo mật chưa bị chặn dẫn đến việc khai thác thành công.
[C-0-3] KHÔNG ĐƯỢC cho phép người dùng hoặc nhà phát triển ứng dụng định cấu hình 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-4] KHÔNG ĐƯỢC phép một ứng dụng có thể ảnh hưởng đến một ứng dụng khác thông qua API (chẳng hạn như Device Administration API) để đị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 đa phương tiện thành nhiều quy trình để có thể cấp quyền truy cập hẹp hơn cho từng quy trình như đã mô tả trong trang web Dự án nguồn mở Android.
[C-0-6] PHẢI triển khai cơ chế hộp cát ứng dụng nhân cho phép lọc các lệnh gọi hệ thống bằng cách sử dụ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 (thượng nguồn) đáp ứng yêu cầu này bằng cách 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 năng bảo vệ và tính toàn vẹn của nhân là những yếu tố không thể thiếu đối với tính bảo mật của Android. Triển khai thiết bị:

[C-0-7] PHẢI triển khai các cơ chế bảo vệ chống tràn bộ đệm ngăn xếp kernel. 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ệ nghiêm ngặt đối với bộ nhớ kernel, trong đó mã thực thi là chỉ đọc, dữ liệu chỉ đọc không thực thi và không ghi được, còn dữ liệu có thể ghi thì không thực thi được (ví dụ: cả rodata và CONFIG_STRICT_KERNEL_RWX đều được bật).
[C-0-9] PHẢI triển khai quy trình 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 của người dùng và nhân hệ điều hành (ví dụ: CONFIG_HARDENED_USERCOPY) trên các thiết bị ban đầu được vận chuyển với cấp độ API 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ế độ nhân hệ điều hành (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 cấp độ API 28 trở lên.
[C-0-11] KHÔNG ĐƯỢC đọc hoặc ghi bộ nhớ không gian người dùng trong 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 với cấp độ API 28 trở lên.
[C-0-12] PHẢI triển khai tính năng cách ly bảng trang nhân nếu phần cứng dễ bị ảnh hưởng bởi CVE-2017-5754 trên tất cả các thiết bị ban đầu đi kèm với cấp độ API 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 biện pháp tăng cường dự đoán nhánh nếu phần cứng dễ bị ảnh hưởng bởi CVE-2017-5715 trên tất cả các thiết bị ban đầu đi kèm với cấp độ API 28 trở lên (ví dụ: CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] RẤT NÊN giữ dữ liệu nhân chỉ được ghi trong quá trình khởi tạo ở trạng thái chỉ đọc sau khi khởi tạo (ví dụ: __ro_after_init).
[C-SR-2] RẤT NÊN ngẫu nhiên hoá bố cục của mã và bộ nhớ kernel, đồng thời tránh những trường hợp có thể ảnh hưởng đến quá trình ngẫu nhiên hoá (ví dụ: CONFIG_RANDOMIZE_BASE có 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] RẤT NÊN bật tính năng kiểm soát tính toàn vẹn của luồng (CFI) trong nhân hệ điều hành để tăng cường bảo vệ chống lại các cuộc tấn công sử dụng lại mã (ví dụ: CONFIG_CFI_CLANG và CONFIG_SHADOW_CALL_STACK).
[C-SR-4] KHÔNG NÊN tắt 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ính năng dọn dẹp 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] RẤT NÊN BẬT CFI, SCS và IntSan cho mọi thành phần bổ sung ở không gian người dùng nhạy cảm với bảo mật như giải thích trong CFI và IntSan.
[C-SR-6] RẤT NÊN bật tính năng khởi tạo ngăn xếp trong nhân để ngăn chặn việc sử dụng các biến cục bộ chưa được khởi tạo (CONFIG_INIT_STACK_ALL hoặc CONFIG_INIT_STACK_ALL_ZERO). Ngoài ra, các phương thức triển khai thiết bị KHÔNG NÊN giả định giá trị mà trình biên dịch dùng để khởi tạo các biến cục bộ.
[C-SR-7] RẤT NÊN bật chế độ khởi tạo vùng nhớ khối xếp trong nhân để ngăn chặn việc sử dụng các hoạt động phân bổ 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 dùng để khởi tạo các hoạt động phân bổ đó.

Nếu các hoạt động triển khai thiết bị sử dụng nhân Linux có khả năng hỗ trợ SELinux, thì:

[C-1-1] PHẢI triển khai SELinux.
[C-1-2] PHẢI đặt SELinux thành chế độ thực thi trên toàn cầu.
[C-1-3] PHẢI định cấu hình tất cả các miền ở chế độ thực thi. Không được phép sử dụng miền ở chế độ cho phép, kể 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) nguồn trên
- Nối nhãn SELinux của AOSP không đúng cách vào các thành phần không thuộc AOSP
Chính sách này PHẢI biên dịch bằng tất cả các quy tắc neverallow hiện có, cho cả miền SELinux AOSP cũng như các 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 các 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ó trong thư mục system/sepolicy của Dự án nguồn mở Android ở thượng nguồn 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 các hoạt động 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-2-1] PHẢI sử dụng một hệ thống kiểm soát quyền truy cập bắt buộc tương đương với SELinux.

Nếu các hoạt động triển khai thiết bị sử dụng thiết bị đầu vào/đầu ra có khả năng DMA, thì:

[C-SR-9] NÊN CÁCH LY MẠNH MẼ từng thiết bị đầu vào/đầu ra có khả năng DMA, bằng cách sử dụng IOMMU (ví dụ: ARM SMMU).

Android có nhiều tính năng bảo mật chuyên sâu, đóng vai trò không thể thiếu trong việc bảo mật thiết bị. Ngoài ra, Android tập trung vào việc giảm các lớp chính của lỗi thường gặp góp phần làm giảm chất lượng và tính bảo mật.

Để giảm lỗi bộ nhớ, các hoạt động triển khai thiết bị:

[C-SR-10] RẤT 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] RẤT 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] RẤT 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 các hoạt động triển khai thiết bị sử dụng TEE dựa trên Arm TrustZone, thì:

[C-SR-13] RẤT NÊN sử dụng một giao thức tiêu chuẩn để chia sẻ bộ nhớ giữa Android và TEE, chẳng hạn như Arm Firmware Framework cho Armv8-A (FF-A).
[C-SR-14] 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 nêu 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 phải thực thi cấp độ này. Nếu không, TEE OS sẽ thực thi điều này.

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 với xác suất cao (> 90%) trong các ứng dụng sử dụng lựa chọn tệp kê khai android:memtagMode:

tràn bộ đệm heap
sử dụng sau khi giải phóng
giải phóng hai lần
wild free (giải phóng một con trỏ không phải malloc)

Triển khai thiết bị:

[C-SR-15] Bạn NÊN ĐẶT ro.arm64.memtag.bootctl_supported.

Nếu các hoạt động 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 hoạt động này sẽ:

[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 phân tách bằng dấu phẩy các giá trị sau đâ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: đã bật một công nghệ An toàn bộ nhớ như được xác định ở trên
- memtag-once: một công nghệ An toàn bộ nhớ như được xác định ở trên sẽ được bật tạm thời và tự động tắt khi khởi động lại lần tiếp theo
- memtag-off: một công nghệ An toàn bộ nhớ như được 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 quá trình 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] RẤT NÊN hiển thị một Chế độ cài đặt cho nhà phát triển để đặt memtag-once và khởi động lại thiết bị. Với một 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.

Nếu một thiết bị khai báo android.hardware.telephony, hỗ trợ khả năng radio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK và có modem di động hỗ trợ kết nối 2G, thì việc triển khai thiết bị sẽ:

[C-SR-17] RẤT NÊN cung cấp cho người dùng khả năng tắt và bật 2G.
[C-SR-18] KHÔNG NÊN ghi đè khả năng của người dùng trong việc tắt và bật 2G thông qua bất kỳ thực thể thiết bị nào khác, trừ phi quản trị viên thiết bị sử dụng UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] BẠN NÊN GỌI TelephonyManager.setAllowedNetworkTypesForReason với lý do ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G để đáp ứng yêu cầu này.
[C-SR-20] BẠN NÊN xác định khả năng hỗ trợ modem di động cho 2G bằng cách gọi TelephonyManager.getSupportedRadioAccessFamily. Hãy xem phần Tắt mạng 2G để biết thông tin chi tiết.

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 thiết bị:

[C-0-1] PHẢI duy trì khoảng thời gian lưu giữ hợp lý đối với nhật ký người dùng đó.
[C-SR-1] RẤT NÊN giữ nguyên khoảng thời gian lưu giữ 14 ngày như được đị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à IncidentManager System API.

Triển khai thiết bị:

[C-0-2] CHỈ ĐƯỢC PHÉP 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 System API 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 StatsLog SDK. Nếu các sự kiện hệ thống khác đượ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. Ghi âm

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC phép tải sẵn hoặc phân phối các thành phần phần mềm ngay khi xuất xưởng để gửi thông tin riêng tư 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ị mà không có sự đồng ý của người dùng hoặc thông báo hiển thị liên tục.
[C-0-2] PHẢI hiển thị cảnh báo cho người dùng và nhận đượ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 xuất hiện trên màn hình của người dùng mỗi khi một phiên ghi lại nội dung truyền màn hình hoặc ghi màn hình được bật thông qua MediaProjection.createVirtualDisplay() hoặc các API độc quyền.
[C-0-3] PHẢI có một thông báo hiển thị liên tục cho người dùng khi bật tính năng truyền màn hình hoặc ghi màn hình. AOSP đáp ứng yêu cầu này bằng cách hiện biểu tượng thông báo hiển thị liên tục trên thanh trạng thái.
[C-SR-1] RẤT NÊN hiển thị cho người dùng một cảnh báo có nội dung giống hệt như thông báo được triển khai trong AOSP (Dự án nguồn mở Android) nhưng CÓ THỂ 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 bị ghi lại.
[C-0-4] Yêu cầu này đã bị xoá trong Android 16.

Triển khai thiết bị:

[C-0-7] KHÔNG ĐƯỢC ghi lại, chiếu hoặc truyền thông tin nhạy cảm, chẳng hạn như:
- Nội dung thông báo nhạy cảm được liệt kê trong Mục 3.8.3.4 Bảo vệ thông báo nhạy cảm
- Cửa sổ hoạt động của ứng dụng chứa mật khẩu một lần
- Nội dung nhạy cảm như tên người dùng, mật khẩu và thông tin thẻ tín dụng

Nếu các hoạt động triển khai thiết bị bao gồm chức năng trong hệ thống, chức năng này có thể chụp nội dung hiển thị trên màn hình và/hoặc ghi lại luồng âm thanh phát trên thiết bị không thông qua ContentCaptureService API hệ thống hoặc các phương tiện thuộc quyền sở hữu riêng 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, thì:

[C-1-1] PHẢI có một thông báo hiển thị 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 ghi lại/ghi hình.

Nếu các hoạt động triển khai thiết bị bao gồm một thành phần được bật ngay khi xuất xưởng, có khả năng ghi lại âm thanh xung quanh và/hoặc ghi lại âm thanh phát trên thiết bị để suy luận thông tin hữu ích về bối cảnh của người dùng, thì:

[C-2-1] KHÔNG ĐƯỢC lưu trữ trong bộ nhớ cố định trên thiết bị hoặc truyền ra ngoài thiết bị bản ghi âm thô hoặc bất kỳ định dạng nào có thể chuyển đổi ngược lại thành âm thanh gốc hoặc bản sao gần giống, trừ phi có sự đồng ý rõ ràng của người dùng.

"Chỉ báo micrô" là một chế độ xem trên màn hình, luôn hiển thị cho người dùng và không thể bị che khuất. Người dùng hiểu rằng micrô đang được sử dụng(thông qua văn bản, màu sắc, biểu tượng riêng biệt hoặc một số tổ hợp).

"Chỉ báo camera" là một chế độ xem trên màn hình, luôn hiển thị cho người dùng và không thể bị che khuất. Người dùng hiểu rằng camera đang được sử dụng (thông qua văn bản, màu sắc, biểu tượng riêng biệt hoặc một số tổ hợp).

Sau khi hiển thị trong 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ư trở nên nhỏ hơn và không bắt buộc phải hiển thị như ban đầu.

Đèn chỉ báo micrô có thể được hợp nhất với đèn chỉ báo camera đ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 micrô đã bắt đầu hoạt động.

Chỉ báo camera có thể được hợp nhất 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 camera đã bắt đầu sử dụng.

Nếu các quy trình triển khai thiết bị khai báo android.hardware.microphone, thì chúng sẽ:

[C-SR-1] RẤT NÊN 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 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 Phần 9.1 Quyền có giá trị nhận dạng CDD [C-3-X].
[C-SR-2] RẤT NÊN 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 ghi nhận quyền sở hữu liên quan đến các ứng dụng đó.
[C-SR-3] KHÔNG NÊN ẩn chỉ báo micrô đố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.

Nếu các quy trình triển khai thiết bị khai báo android.hardware.camera.any, thì chúng sẽ:

[C-SR-4] RẤT NÊN hiển thị chỉ báo camera khi một ứng dụng đang truy cập vào dữ liệu camera trực tiếp, nhưng không hiển thị khi camera chỉ được(các) ứng dụng có vai trò được nêu trong Phần 9.1 Quyền có giá trị nhận dạng CDD [C-3-X] truy cập.
[C-SR-5] RẤT NÊN hiển thị các ứng dụng Gần đây và Đang hoạt động đang dùng camera như được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi nhận quyền sở hữu liên quan đến các ứng dụng đó.
[C-SR-6] KHÔNG NÊN ẩn chỉ báo camera đối với các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc hoạt động tương tác trực tiếp của người dùng.

9.8.3. Khả năng kết nối

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

[C-1-1] PHẢI trình bày một 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 thiết bị:

[C-0-1] PHẢI cài đặt sẵn các chứng chỉ gốc tương tự cho kho Tổ chức phát hành chứng chỉ (CA) mà hệ thống tin cậy như được cung cấp trong Dự án nguồn mở Android ở thượng nguồn.
[C-0-2] PHẢI được vận chuyển cùng với một kho 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 giám sát khi người dùng thêm một CA gốc.

Nếu lưu lượng truy cập của thiết bị được định tuyến qua VPN, thì các hoạt động 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 một trong hai trường hợp sau:
- 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 các hoạt động triển khai thiết bị có một cơ chế (được bật sẵn theo mặc định) định tuyến lưu lượng truy cập dữ liệu mạng thông qua một máy chủ proxy hoặc cổng VPN (ví dụ: tải trước một dịch vụ VPN có android.permission.CONTROL_VPN được cấp), thì các hoạt động triển khai đó:

[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 kiểm soát 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 mà CHỈ cần được thông báo.

Nếu các hoạt động triển khai thiết bị triển khai một thành phần hỗ trợ người dùng để bật/tắt chức năng "VPN luôn bật" của một ứng dụng VPN bên thứ ba, thì các hoạt động triển khai đó:

[C-3-1] PHẢI tắt thành phần này cho người dùng đối với những ứng dụng không hỗ trợ dịch vụ VPN luôn bật trong tệp AndroidManifest.xml bằng cách đặ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 thiết bị:

[C-0-1] PHẢI ngăn chặn ứng dụng truy cập vào số sê-ri của thiết bị và, nếu có thể, IMEI/MEID, số sê-ri SIM và Mã nhận dạng thuê bao di động quốc tế (IMSI), trừ phi ứng dụng đáp ứng một trong các yêu cầu sau:
- là một ứng dụng 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 theo định nghĩa trong Đặc quyền của nhà mạng trên 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ó yêu cầu theo quy định của địa phương rằng ứng dụng phải phát hiện những thay đổi về danh tính của người đăng ký.

9.8.6. Công cụ bảo vệ dữ liệu ở cấp hệ điều hành và dữ liệu môi trường

Thông qua các API Hệ thống, Android hỗ trợ một cơ chế để các hoạt động triển khai thiết bị thu thập những dữ liệu nhạy cảm sau:

Văn bản và đồ hoạ được 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 AssistStructure API, các hoạt động ghi lại vùng đệm màn hình và ghi lại nội dung màn hình của thiết bị.

Dữ liệu 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).
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 thông qua API Content Capture.
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 thông qua AppSearchGlobalManager.query.
Mọi văn bản hoặc dữ liệu khác được gửi qua TextClassifier API đến TextClassifier của hệ thống, tức là đến 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 quá trình triển khai AppSearch của nền tảng, bao gồm nhưng không giới hạn ở văn bản, đồ hoạ, dữ liệu đa phương tiện hoặc dữ liệu tương tự khác.
Dữ liệu âm thanh thu được do sử dụng SpeechRecognizer#onDeviceSpeechRecognizer() bằng Speech Recognizer Implementation.
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 và không dẫn đến chỉ báo mà người dùng có thể thấy
Dữ liệu camera thu được ở chế độ nền (liên tục) thông qua CameraManager hoặc các API Camera khác và không dẫn đến chỉ báo mà người dùng nhìn thấy

Mọi dữ liệu do DynamicInstrumentationEventService thu thập

Nếu các hoạt động triển khai thiết bị thu thập hoặc chia sẻ bất kỳ dữ liệu nhạy cảm nào ở trên, thì: nếu không có ý định rõ ràng, riêng biệt của người dùng hoặc chỉ báo về quyền riêng tư mà người dùng có thể thấy, thì dữ liệu PHẢI được xử lý trong một môi trường thực thi được bảo vệ. Môi trường này:

[C-1-1] PHẢI mã hoá tất cả dữ liệu đó khi được lưu trữ trong thiết bị hoặc trong quá trình truyền. Bạn CÓ THỂ thực hiện quy trình mã hoá này bằng cách sử dụng phương thức Mã hoá dựa trên tệp của Android hoặc bất kỳ mật mã nào được liệt kê là API phiên bản 26 trở lên như mô tả trong Cipher SDK.
[C-1-2] KHÔNG ĐƯỢC sao lưu dữ liệu thô hoặc dữ liệu đã mã hoá bằng các dịch vụ sao lưu của Android hoặc bất kỳ phương thức sao lưu nào khác dữ liệu nhạy cảm, như mô tả ở trên.

[C-1-3] KHÔNG ĐƯỢC gửi dữ liệu như vậy ra khỏi thiết bị, trừ phi thuộc một trong các trường hợp sau:
- Khi người dùng chủ động bắt đầu ^* cho hoạt động tính toán cụ thể mỗi khi dữ liệu được chia sẻ.
- Khi sử dụng một cơ chế đảm bảo quyền riêng tư, chẳng hạn như các công nghệ đảm bảo sự riêng tư biệt lập như RAPPOR hoặc các phép tính liên kết bí mật.
- Khi dữ liệu được xử lý trong một môi trường thực thi được bảo vệ, môi trường này sẽ bảo vệ dữ liệu khỏi nhà cung cấp dịch vụ và cơ sở hạ tầng, chẳng hạn như không có quyền truy cập của quản trị viên, máy ảo bảo mật, chứng thực từ xa, không có dữ liệu riêng tư thoát ra, nhật ký bị vô hiệu hoá, che giấu địa chỉ IP và mã hoá.
  - Mọi hoạt động triển khai sử dụng phương thức này đều phải cung cấp một lựa chọn để người dùng chọn không tham gia.

[C-1-3] CÓ THỂ xử lý dữ liệu thông qua một môi trường đám mây cơ sở điện toán đáng tin cậy giúp bảo vệ dữ liệu khỏi nhà cung cấp dịch vụ và cơ sở hạ tầng (ví dụ: không có quyền truy cập của quản trị viên, VM bí mật, chứng thực từ xa, không có dữ liệu riêng tư thoát ra, nhật ký bị vô hiệu hoá, che giấu IP và mã hoá). Mọi hoạt động triển khai bằng phương thức này:
- PHẢI cung cấp một cơ chế để người dùng chọn không nhận thông báo, và
- PHẢI cung cấp cho người dùng một phương thức để tạo nhật ký toàn diện và dễ truy cập, nêu chi tiết dữ liệu đầu vào và đầu ra từ môi trường.

[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-4] CÓ THỂ hiển thị dữ liệu này trên các nền tảng giao diện người dùng thuộc sở hữu của hệ thống.

[C-1-5] KHÔNG ĐƯỢC chia sẻ 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ừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được chia sẻ. mỗi khi dữ liệu được liên kết hoặc mối liên kết sẽ không chuyển sang các thành phần hệ điều hành khác không tuân theo các yêu cầu nêu trong phần hiện tại (9.8.6 Dữ liệu ở cấp hệ điều hành và dữ liệu môi trường), mỗi khi dữ liệu được chia sẻ. Trừ phi chức năng đó được tạo dưới dạng một API SDK Android (AmbientContext, HotwordDetectionService).
[C-1-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 hoặc phương tiện độc quyền thu thập khi dữ liệu được lưu trữ dưới mọi hình thức trên thiết bị hoặc trong môi trường đám mây cơ sở điện toán đáng tin cậy. Nếu người dùng chọn xoá dữ liệu, thì TẤT CẢ dữ liệu đã thu thập trong quá khứ PHẢI được xoá.

[C-1-7] PHẢI cung cấp cho người dùng một lựa chọn để chọn không hiển thị dữ liệu được thu thập thông qua AppSearch hoặc các phương tiện độc quyền trên nền tảng Android (ví dụ: trình chạy).

[C-1-8] PHẢI cung cấp một phương thức để tạo nhật ký toàn diện và dễ truy cập, nêu chi tiết dữ liệu đầu vào và đầu ra từ môi trường.
[C-1-9] KHÔNG ĐƯỢC có quyền truy cập trực tiếp vào Internet.
[C-1-10] CÓ THỂ hiển thị giao diện người dùng từ xa miễn là không có dữ liệu nào xuất hiện trong apk lưu trữ hiển thị giao diện người dùng.
[C-1-11] PHẢI tách các dịch vụ này khỏi các thành phần khác của hệ thống (ví dụ: không liên kết dịch vụ hoặc chia sẻ mã nhận dạng quy trình với những hoạt động triển khai không nằm trong môi trường thực thi được bảo vệ).
[C-1-12] CHỈ ĐƯỢC PHÉP dữ liệu nhạy cảm thoát ra khi:
- Do người dùng chủ động kích hoạt* cho hoạt động tính toán cụ thể mỗi khi dữ liệu được chia sẻ; HOẶC
- Sử dụng cơ chế đảm bảo quyền riêng tư (ví dụ: các công nghệ đảm bảo sự riêng tư biệt lập như RAPPOR / các phép tính liên kết bí mật).
[C-1-13] CHỈ ĐƯỢC PHÉP trích xuất dữ liệu nhạy cảm thông qua:
- Một dịch vụ hệ thống được đưa vào danh sách cho phép trong dịch vụ hệ thống PCCSandbox VÀ tuân thủ các yêu cầu đối với một môi trường thực thi được bảo vệ (9.8.6), HOẶC
- Một tệp APK Cổng Lõi điện toán riêng tư (PCC) được chỉ định (được xác định trong mục 9.8.15).
[C-1-14] KHÔNG ĐƯỢC sao lưu dữ liệu suy luận từ dữ liệu nhạy cảm lên đám mây, trừ phi được mã hoá hai đầu (ví dụ: sử dụng Android Backup Service).

[C-SR-1] KHÔNG NÊN yêu cầu quyền INTERNET.
[C-SR-2] NÊN truy cập Internet thông qua các API có cấu trúc được hỗ trợ bằng các cách triển khai nguồn mở có sẵn công khai.
[C-SR-4] NÊN TRIỂN KHAI bằng API SDK Android hoặc một kho lưu trữ mã nguồn mở tương tự do OEM sở hữu; và / hoặc được thực hiện trong một hoạt động triển khai Hộp cát (xem phần 9.8.15 Triển khai API Hộp cát).

Nếu các hoạt động triển khai thiết bị bao gồm một dịch vụ triển khai System API ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService, hoặc bất kỳ dịch vụ thuộc quyền sở hữu riêng nào thu thập dữ liệu như mô tả ở trên, thì các hoạt động triển khai đó:

[C-2-1] KHÔNG ĐƯỢC 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ụ do người dùng cài đặt và CHỈ ĐƯỢC 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 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 như vậy.
[C-2-3] PHẢI cung cấp khả năng tương tác rõ ràng và dễ tiếp cận cho người dùng để tắt các dịch vụ.
[C-2-4] KHÔNG ĐƯỢC bỏ qua khả năng tương tác của người dùng để quản lý các quyền trên Android do dịch vụ nắm giữ và tuân theo mô hình quản lý quyền trên Android như mô tả trong Mục 9.1. Quyền.
[C-SR-3] NÊN TUYỆT ĐỐI giữ các dịch vụ tách biệt với các thành phần khác của hệ thống (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

9.8.7. Quyền truy cập vào bảng nhớ tạm

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC trả về dữ liệu bị 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 đang có tiêu điểm.
[C-0-2] PHẢI xoá dữ liệu trên bảng nhớ tạm muộn nhất là 60 phút sau khi dữ liệu đó được đặt vào bảng nhớ tạm hoặc đọc từ bảng nhớ tạm lần gần đây nhất.

9.8.8. Vị trí

Vị trí bao gồm thông tin trong lớp Vị trí của Android( chẳng hạn như Vĩ độ, Kinh độ, Độ cao), cũng như các giá trị nhận dạng có thể được chuyển đổi thành Vị trí. Vị trí có thể chính xác đến mức DGPS (Hệ thống định vị toàn cầu vi sai) hoặc không chính xác đến mức vị trí cấp quốc gia (chẳng hạn như vị trí mã quốc gia – MCC – Mã quốc gia của thiết bị di động).

Sau đây là danh sách các loại vị trí trực tiếp lấy được vị trí của người dùng hoặc có thể 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 nên dùng danh sách này làm ví dụ về những thông tin có thể được suy ra trực tiếp hoặc gián tiếp từ Vị trí:

GPS/GNSS/DGPS/PPP
- Giải pháp định vị toàn cầu hoặc Hệ thống vệ tinh định vị toàn cầu hoặc Giải pháp định vị toàn cầu vi sai
- Điều này cũng bao gồm các phép đo GNSS thô và Trạng thái GNSS
  - Bạn có thể lấy Vị trí chính xác từ các phép đo GNSS thô
Công nghệ không dây có giá trị nhận dạng riêng biệ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ã nhận dạng trạm phát sóng (3G, 4G, 5G, v.v., bao gồm tất cả các công nghệ Modem di động trong tương lai có mã nhận dạng duy nhất)

Để tham khảo thông tin 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 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 mà không có sự đồng ý rõ ràng của người dùng hoặc do người dùng chủ động thực hiện.
[C-0-2] PHẢI cung cấp cho người dùng khả năng truy cập vào thông tin liên quan đến vị trí, bao gồm cả các yêu cầu gần đây về vị trí, quyền ở cấp ứng dụng và việc sử dụng tính năng quét Wi-Fi/quét tìm thiết bị Bluetooth để xác định vị trí.
[C-0-3] PHẢI đảm bảo rằng ứng dụng sử dụng Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() là một phiên khẩn cấp do người dùng bắt đầu (ví dụ: gọi 911 hoặc nhắn tin đến 911). Tuy nhiên, đối với Automotive, xe CÓ THỂ bắt đầu một phiên khẩn cấp mà không cần lượt tương tác của người dùng trong trường hợp phát hiện thấy tai nạn (chẳng hạn như để đá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 gửi 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.

Khi một ứng dụng không phải ứng dụng hệ thống và đang chạy trên nền trước truy cập vào thông tin vị trí chính xác của thiết bị, thiết bị sẽ:

[C-SR-1] RẤT NÊN hiển thị một chỉ báo mà người dùng có thể nhìn thấy

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 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 ở những thông tin chi tiết do mọi API tuỳ chỉnh mà 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 đối với các tệp trong thư mục 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. Các trường hợp ngoại lệ duy nhất là:
- Quyền của trình cung cấp bộ nhớ ngoài (ví dụ: các ứng dụng như DocumentsUI).
- Download Provider sử dụng quyền của trình cung cấp "downloads" để tải tệp xuống bộ nhớ ứng dụng.
- Các ứng dụng giao thức truyền tệp đa phương tiện (MTP) được nền tảng ký sử dụng quyền đặc biệt 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 các ứng dụng khác và có quyền INSTALL_PACKAGES chỉ có thể truy cập vào các 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 các phương thức triển khai thiết bị khai báo cờ tính năng android.hardware.telephony, thì:

[C-1-1] PHẢI hỗ trợ tạo báo cáo lỗi về kết nối thông qua BUGREPORT_MODE_TELEPHONY bằng BugreportManager.
[C-1-2] PHẢI lấy sự đồng ý của người dùng mỗi khi BUGREPORT_MODE_TELEPHONY được dùng để 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 từ ứng dụng.
[C-1-3] KHÔNG ĐƯỢC trả lại báo cáo đã tạo cho ứng dụng yêu cầu khi chưa 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:
- TelephonyDebugService kết xuất
- TelephonyRegistry kết xuất
- WifiService kết xuất
- ConnectivityService kết xuất
- Một bản kết xuất của phiên bản CarrierService của gói gọi (nếu được liên kết)
- Vùng đệm nhật ký radio
- SubscriptionManagerService kết xuất
[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 của ứ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 (UID được chấp nhận, tên gói thì không).
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ý của nhà cung cấp).

Nếu các hoạt động triển khai thiết bị có thêm thông tin (ví dụ: nhật ký của nhà cung cấp) trong báo cáo lỗi và thông tin đó ảnh hưởng đến quyền riêng tư/bảo mật/pin/bộ nhớ/dung lượng lưu trữ, thì các hoạt động triển khai đó:

[C-SR-1] RẤT NÊN có một chế độ cài đặt dành cho nhà phát triển được đặt mặc định là tắt. Việc triển khai tham chiếu AOSP đáp ứng yêu cầu này bằng cách cung cấp lựa chọn Enable verbose vendor logging trong phần cài đặt cho nhà phát triển để đưa nhật ký bổ sung dành riêng cho thiết bị của nhà cung cấp vào báo cáo lỗi.

9.8.11. Chia sẻ blob dữ liệu

Thông qua BlobStoreManager, Android cho phép các ứng dụng đóng góp blob dữ liệu cho Hệ thống để chia sẻ với một nhóm ứng dụng đã chọn.

Nếu các hoạt động triển khai thiết bị hỗ trợ blob dữ liệu được chia sẻ như mô tả trong tài liệu về SDK, thì:

[C-1-1] KHÔNG ĐƯỢC chia sẻ các blob dữ liệu thuộc về các ứng dụng vượt quá những gì chúng dự định 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 bảo mật của các blob dữ liệu (được dùng để kiểm soát quyền truy cập).

9.8.12. Nhận dạng nhạc

Thông qua System API MusicRecognitionManager, Android hỗ trợ một cơ chế để các hoạt động 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 các hoạt động triển khai thiết bị bao gồm một dịch vụ triển khai System API MusicRecognitionManager 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 hoạt động triển khai đó:

[C-1-1] PHẢI thực thi rằng phương thức gọi MusicRecognitionManager giữ quyền MANAGE_MUSIC_RECOGNITION
[C-1-2] PHẢI đảm bảo rằng một ứng dụng nhận dạng nhạc duy nhất, được cài đặt sẵn sẽ triển khai MusicRecognitionService.
[C-1-3] KHÔNG ĐƯỢC 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 âm đó đế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 AppOpsManager.noteOp / startOp.

Nếu các phương thứ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 đã ghi lại, thì các phương thức này sẽ:

[C-2-1] TUYỆT ĐỐI KHÔNG được lưu trữ bất kỳ âm thanh thô hoặc dấu 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 đó ra ngoài MusicRecognitionService, trừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được chia sẻ.

9.8.13. SensorPrivacyManager

Nếu các hoạt động triển khai thiết bị cung cấp cho người dùng một phương thức tương tác phần mềm để tắt đầu vào camera và/hoặc micrô cho hoạt động triển khai thiết bị, thì các hoạt động triển khai đó:

[C-1-1] PHẢI trả về chính xác giá trị "true" cho phương thức API supportsSensorToggle() có 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 Camera bị chặn, hãy trình bày cho người dùng một thành phần tương tác không thể đóng, 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 bỏ chặn theo cách triển khai AOSP (Dự án nguồn mở Android) đáp ứng yêu cầu này.
[C-1-3] CHỈ ĐƯỢC PHÉP truyền dữ liệu âm thanh và camera trống (hoặc giả) đến các ứng dụng và không báo cáo mã lỗi do người dùng không bật camera cũng như micrô thông qua phương thức tương tác mà người dùng thấy theo [C-1-2] ở trên.

9.8.14. Không áp dụng

9.8.15. Triển khai Lõi điện toán riêng tư và Ứng dụng cổng

Thông qua một bộ API uỷ quyền, Android cung cấp một cơ chế để xử lý dữ liệu an toàn ở cấp hệ điều hành và dữ liệu môi trường. Bạn có thể uỷ quyền xử lý như vậy cho một apk được cài đặt sẵn có quyền truy cập đặc quyền và khả năng giao tiếp bị hạn chế, được gọi là một Triển khai API trong hộp cát.

RẤT NÊN dùng các chế độ triển khai thiết bị có các ứng dụng thực hiện quy trình xử lý dữ liệu nhạy cảm trên thiết bị như mô tả trong phần 9.8.6 (dữ liệu ở cấp hệ điều hành và dữ liệu môi trường) bằng khung Lõi điện toán riêng tư (PCC) như mô tả bên dưới.

Mọi thành phần triển khai Sandboxed API trong môi trường PCC:

[C-0-1] KHÔNG ĐƯỢC yêu cầu quyền INTERNET.

[C-0-1] PHẢI được khai báo bằng một thuộc tính android:isPrivateComputeCoreProcess="true" trong phần khai báo tệp kê khai.

[C-0-2] CHỈ ĐƯỢC truy cập vào 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ằng cách sử dụng các 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 đả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 chặn việc so khớp các sự kiện đã ghi nhật ký hoặc kết quả phái sinh với từng người dùng", để ngăn chặn mọi dữ liệu trên mỗi người dùng có thể được kiểm tra (ví dụ: được triển khai bằng công nghệ sự riêng tư biệt lập như RAPPOR).

[C-0-2] PHẢI được tải trước trên hình ảnh hệ thống của thiết bị.

[C-0-3] PHẢI tách các dịch vụ này khỏi các thành phần khác của hệ thống (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 với các hoạt động triển khai không chạy dưới dạng một UID PCC).
[C-0-4] KHÔNG ĐƯỢC 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] CHỈ ĐƯỢC PHÉP các dịch vụ cài đặt sẵn do OEM chỉ định (giữ một vai trò hệ thống thích hợp được xác định trong Dịch vụ hệ thống Trình quản lý PCC) và có các quyền thích hợp để thu thập dữ liệu đó. Trừ phi khả 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ố) dữ liệu môi trường nhạy cảm như mô tả trong phần 9.8.6.
[C-0-6] KHÔNG ĐƯỢC 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 như vậy. Trừ phi bạn triển khai chức năng chụp như vậy bằng một 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 tương tác của người dùng để quản lý các quyền Android do dịch vụ nắm giữ và tuân theo mô hình quản lý quyền Android như mô tả trong Mục 9.1. Quyền.

[C-0-9] PHẢI chạy trong một quy trình chuyên biệt có UID riêng biệt do khung chỉ định, tách biệt với quy trình ứng dụng chính và các thành phần hộp cát khác.

Mọi quyền truy cập mạng mà các thành phần môi trường PCC yêu cầu ĐỀU PHẢI được uỷ quyền thông qua một APK được chỉ định đóng vai trò là Ứng dụng cổng PCC. (Các) thành phần được chỉ định:

[C-1-1] PHẢI được cấp quyền đặc biệt android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. Quyền này chỉ định ứng dụng là Ứng dụng cổng PCC.
[C-1-2] PHẢI cung cấp mã nguồn để công chúng có thể xác minh.
[C-1-3] PHẢI sử dụng cơ chế bảo đảm quyền riêng tư cho mọi dữ liệu truyền ra, như được xác định trong mục 9.8.6
[C-1-4] PHẢI hỗ trợ chế độ kiểm tra của khung PCC, bao gồm cả việc ghi nhật ký các yêu cầu mạng, điểm cuối của máy chủ và các dữ liệu khác có liên quan để xác minh hành vi đảm bảo quyền riêng tư khi được bật

9.8.16. Dữ liệu âm thanh và camera liên tục

Nếu các phương thức triển khai thiết bị thu thập bất kỳ dữ liệu nào như mô tả trong mục 9.8.2 hoặc mục 9.8.6, và nếu 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 camera thu được ở chế độ nền (liên tục) thông qua CameraManager hoặc các API Camera khác, thì các phương thức triển khai đó:

[C-0-1] PHẢI thực thi chỉ báo tương ứng (camera và/hoặc micrô theo phần 9.8.2 Ghi hình), trừ phi:
- Quyền truy cập này được thực hiện trong một quy trình triển khai dạng hộp cát (xem phần 9.8.15 Triển khai API dạng hộp cát), thông qua một gói có một hoặc nhiều vai trò sau: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence hoặc System Visual Intelligence.
- 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ố 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] BẠN NÊN YÊU CẦU sự đồng ý của người dùng cho mọi chức năng sử dụng dữ liệu như vậy và tắt theo mặc định.
[C-SR-2] RẤT NÊN áp dụng cách xử lý tương tự (tức là tuân thủ các quy định hạn chế nêu trong phần 9.8.2 Ghi âm, 9.8.6 Dữ liệu ở cấp hệ điều hành và dữ liệu môi trường, 9.8.15 Triển khai API hộp cát và 9.8.16 Dữ liệu âm thanh và camera liên tục) đối với dữ liệu Camera đến từ một thiết bị đeo từ xa.

Nếu các hoạt động triển khai thiết bị nhận dữ liệu Camera hoặc Micrô từ một thiết bị đeo từ xa và dữ liệu được truy cập ở dạng chưa mã hoá bên ngoài Hệ điều hành Android, hoạt động triển khai hộp cát hoặc chức năng hộp cát do WearableSensingManager tạo, thì:

[C-1-1] PHẢI chỉ thị cho thiết bị đeo từ xa 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 một Ứng dụng Trợ lý kỹ thuật số mà không cần từ khoá được chỉ định (xử lý các 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 camera), thì thiết bị đó:

[C-2-1] PHẢI đảm bảo rằng quá trình 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 rằng 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à nhật ký ứng dụng bằng cách sử dụng StatsLog API. 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ế đảm bảo 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 các chỉ số bị hạn chế từ StatsManager:

[C-0-1] PHẢI là ứng dụng/triển khai duy nhất trên thiết bị và có quyền READ_RESTRICTED_STATS.
[C-0-2] CHỈ ĐƯỢC PHÉP gửi dữ liệu đo từ xa và nhật ký của thiết bị bằng cơ chế bảo đảm 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 chặn việc so khớp các sự kiện đã ghi nhật ký hoặc kết quả phái sinh với từng người dùng", để ngăn chặn mọi dữ liệu trên mỗi người dùng có thể được kiểm tra (ví dụ: được triển khai bằng công nghệ sự riêng tư biệt lập 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 khác của hệ điều hành không tuân thủ các yêu cầu nêu trong phần hiện tại (9.8.17. Dữ liệu đo từ xa).
[C-0-5] PHẢI cung cấp cho người dùng một phương thức để 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 đảm 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à hoạt động triển khai thu thập nếu dữ liệu đó được lưu trữ dưới 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, thì bạn 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ố việc triển khai giao thức cơ bản bảo đảm quyền riêng tư trong một kho lưu trữ nguồn mở.
[C-0-8] PHẢI thực thi các chính sách truyền dữ liệu ra ngoài 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.

9.8.18. Quyền riêng tư đối với các hàm của trợ lý AI

Triển khai thiết bị:

[C-0-1] PHẢI đảm bảo rằng mọi thành phần thực thi AppFunctions đều có quyền EXECUTE_APP_FUNCTIONS hoặc EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] CHỈ ĐƯỢC gọi một lệnh gọi AppFunction khi có kết quả trực tiếp từ một hành động rõ ràng của người dùng, đồng thời phải cho người dùng biết rõ ứng dụng nào được gọi và hành động chính cần thực hiện trong ứng dụng đó.
[C-0-3] KHÔNG ĐƯỢC phép uỷ quyền hoặc sửa đổi yêu cầu của ứng dụng bên thứ ba để khám phá hoặc thực thi AppFunctions, trừ phi đáp ứng được [C-0-1] và [C-0-2].
[C-0-4] KHÔNG ĐƯỢC phép các thành phần hệ thống sử dụng dữ liệu nhạy cảm ở cấp hệ điều hành hoặc dữ liệu môi trường xung quanh (như được xác định trong phần 9.8.6 Bảo vệ dữ liệu ở cấp hệ điều hành và dữ liệu môi trường xung quanh) hoặc các dữ liệu phái sinh của dữ liệu đó để tạo hoặc tham số hoá thông báo nhắc nhở, trừ phi các thành phần hệ thống hoạt động trong Môi trường thực thi được bảo vệ như được xác định trong phần 9.8.6.

Thuật ngữ chính: "Nhắc nhở" được định nghĩa là một điểm truy cập được tạo chủ động vào một ứng dụng từ một giao diện hệ thống được khởi tạo mà không có hành động trực tiếp trước đó của người dùng. Nudge (nhắc nhở) là một gợi ý hoặc hướng dẫn người dùng thực hiện một hành động mà không hạn chế quyền tự do lựa chọn.

9.9. Mã hoá bộ nhớ dữ liệu

Tất cả thiết bị ĐỀU 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 trong tài liệu này đượ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ị 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 của Android tương ứng với cấp độ API mà thiết bị ra mắt.

9.9.1. Direct Boot

Triển khai 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 này không hỗ trợ tính năng Mã hoá bộ nhớ.
[C-0-2] Các Intent ACTION_LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED VẪN PHẢI được truyền đi để báo hiệu cho các ứng dụng có nhận biết chế độ Khởi động trực tiếp rằng vị trí lưu trữ được Mã hoá thiết bị (DE) và Mã hoá thông tin đăng nhập (CE) có sẵn cho người dùng.

9.9.2. Yêu cầu về việc mã hoá

Triển khai 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 cố định, 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 quá trình thiết lập ban đầu.
[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 pháp mã hoá

Nếu các chế độ triển khai thiết bị được mã hoá, thì:

[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 đăng nhập và cho phép các ứng dụng nhận biết chế độ 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 đi.
[C-1-2] KHÔNG ĐƯỢC phép truy cập vào bộ nhớ Thông tin đăng nhập đã mã hoá (CE) cho đến khi cả hai điều kiện sau đây được đáp ứng:
- Người dùng mở khoá thiết bị bằng phương thức xác thực chính (chẳng hạn như mật khẩu, hình mở khoá hoặc mã PIN).
- Thông báo ACTION_USER_UNLOCKED được phát đi.
[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ệ CE mà không có thông tin đăng nhập do người dùng cung cấp, khoá ký quỹ đã đăng ký hoặc việc triển khai tiếp tục 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 có mã hoá siêu dữ liệu

Nếu các phương thức triển khai thiết bị sử dụng phương thức Mã hoá dựa trên tệp có Mã hoá siêu dữ liệu, thì:

[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 đề cập đến Tiêu chuẩn mã hoá tiên tiến với độ 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 (xattrs).
[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ở rộng mật mã ARMv8 trên các thiết bị dựa trên ARM hoặc AES-NI trên các thiết bị dựa trên x86), thì bạn PHẢI sử dụng các lựa chọn dựa trên AES ở trên cho tên tệp, nội dung tệp và hoạt động mã hoá siêu dữ liệu hệ thống tệp, chứ không được dùng Adiantum.
[C-1-13] PHẢI sử dụng một hàm phái sinh khoá không thể đảo ngược và mã hoá mạnh (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ã và không thể đảo ngược" có nghĩa là hàm phái sinh khoá có độ bảo mật ít nhất là 256 bit và hoạt động như một họ hàm giả ngẫu nhiên trên các thông tin đầu vào của hàm.
[C-1-14] KHÔNG ĐƯỢC dùng cùng một khoá hoặc khoá con Mã hoá dựa trên tệp (FBE) cho các mục đích mã hoá khác nhau (ví dụ: cho cả mã hoá và phái sinh khoá, hoặc cho 2 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ớ liên tục đều được mã hoá bằng cách kết hợp khoá mã hoá và vectơ khởi tạo (IV) phụ thuộc vào cả tệp và độ lệch trong tệp. Ngoài ra, tất cả các tổ hợp như vậy PHẢI khác biệt, trừ trường hợp 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 được mã hoá chưa bị xoá trên bộ nhớ liên tục trong các thư mục riêng biệt đều được mã hoá bằng các tổ hợp riêng biệt của khoá mã hoá và vectơ khởi động (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 được mã hoá trên bộ nhớ liên tục đều được mã hoá bằng các tổ hợp riêng biệt của khoá mã hoá và vectơ khởi tạo (IV).
Khoá bảo vệ các 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 Xác minh quy trình khởi động và gốc tin cậy phần cứng của thiết bị.
- [C-1-8] Các 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] Các khoá CE PHẢI được liên kết với một mật khẩu mặc định khi người dùng chưa chỉ định thông tin đăng nhập màn hình khoá.
- [C-1-10] PHẢI là duy nhất và riêng biệt, tức là không có khoá CE hoặc DE của người dùng nào trùng khớp với khoá CE hoặc DE của người dùng 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á 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 làm cho các ứng dụng thiết yếu được cài đặt sẵn (ví dụ: Báo thức, Điện thoại, Messenger) nhận biết được chế độ Khởi động trực tiếp.

Dự án Android nguồn mở thượng nguồn cung cấp một cách triển khai ưu tiên cho 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 các hoạt động triển khai thiết bị sử dụng tính năng mã hoá ở cấp khối cho mỗi người dùng, thì các hoạt động này sẽ:

[C-1-1] PHẢI bật chế độ 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, bằng cách sử dụng phân vùng thô hoặc ổ đĩa logic.
[C-1-3] PHẢI sử dụng các 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 cho 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 ràng buộc 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 Xác minh quy trình khởi động và gốc tin cậy phần cứng của thiết bị.
- [C-1-6] PHẢI được liên kết với thông tin đăng nhập màn hình khoá tương ứng của người dù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 sau khi khởi động lại

Tính năng Tiếp tục sau khi khởi động lại cho phép mở kho lưu trữ CE của tất cả ứng dụng, kể 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 sau 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 được mã hoá bằng CE của người dùng, ngay cả khi thiết bị đang bật, bộ nhớ CE đã được mở khoá và người dùng đã mở khoá thiết bị sau khi nhận được bản cập nhật qua mạng (OTA). Để chống lại các cuộc tấn công nội bộ, chúng tôi cũng giả định rằng kẻ tấn công có quyền truy cập vào các khoá ký mã hoá truyền tin.

Cụ thể:

[C-0-1] Ngay cả khi kẻ tấn công có thiết bị trong tay và có những khả năng cũng như hạn chế sau, thì họ CŨNG KHÔNG ĐƯỢC phép đọc bộ nhớ CE:
- Có thể dùng khoá ký của bất kỳ nhà cung cấp hoặc công ty nào để ký các thông báo tuỳ ý.
- Có thể khiến thiết bị nhận được bản cập nhật qua mạng (OTA).
- Có thể sửa đổi hoạt động của mọi phần cứng (AP, bộ nhớ flash, v.v.) ngoại trừ những trường hợp được nêu chi tiết bên dưới, nhưng việc sửa đổi như vậy sẽ mất ít nhất một giờ và một chu kỳ nguồn sẽ phá huỷ nội dung RAM.
- Không thể sửa đổi hoạt động của phần cứng chống giả mạo (ví dụ: Titan M).
- Không đọc đượ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 khiến người dùng nhập thông tin đó.

Ví dụ: một quy trình triển khai thiết bị triển khai và tuân thủ tất cả nội dung mô tả 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 tính toàn vẹn của thiết bị. Triển khai thiết bị:

[C-0-1] PHẢI báo cáo chính xác thông qua phương thức System API PersistentDataBlockManager.getFlashLockState() xem trạng thái trình tải khởi động của họ có cho phép cài đặt ROM hình ảnh hệ thống hay không.
[C-0-2] PHẢI hỗ trợ 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 các hoạt động triển khai thiết bị đã được ra mắt mà không hỗ trợ tính năng Xác minh quy trình khởi động trên phiên bản Android cũ và không thể thêm tính năng này bằng bản cập nhật phần mềm hệ thống, thì các hoạt động triển khai đó CÓ THỂ được miễn yêu cầu.

[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 trong mỗi trình tự khởi động.
[C-1-3] PHẢI bắt đầu quy trình xác minh từ một khoá vật lý bất biến là gốc tin cậy và đi lên đế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 ở giai đoạn tiếp theo trước khi thực thi mã ở 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 cho 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 phép hoàn tất quá trình khởi động khi quá trình xác minh hệ thống không thành công, trừ phi người dùng đồng ý thử khởi động dù sao đi nữa. Trong trường hợp đó, KHÔNG ĐƯỢC sử dụng dữ liệu từ bất kỳ khối lưu trữ nào chưa được xác minh.
[C-1-7] KHÔNG ĐƯỢC 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-1-8] PHẢI sử dụng bộ nhớ chống giả mạo: để 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 giả mạo có nghĩa là trình tải khởi động có thể phát hiện xem bộ nhớ có bị giả mạo 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ế độ trình tải khởi động bị khoá sang chế độ trình tải khởi động đã mở khoá.
[C-1-10] PHẢI triển khai tính năng bảo vệ chống quay về phiên bản cũ cho các phân vùng mà Android dùng (ví dụ: phân vùng khởi động, hệ thống) và dùng bộ nhớ chống giả mạo để 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 dữ liệu người dùng và mọi không gian NVRAM).
[C-1-14] PHẢI xác minh chữ ký ít nhất một lần mỗi khi khởi động đối với các gói nằm trong danh sách cho phép được liệt kê là require-strict-signature trong cấu hình hệ thống.
[C-SR-2] NÊN XÁC MINH tất cả cá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] 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ó đặc quyền tải từ bên ngoài tệp APK của ứng dụng (chẳng hạn như mã được tải động hoặc mã đã biên dịch) trước khi thực thi hoặc NÊN TUYỆT ĐỐI KHÔNG thực thi các cấu phần phần mềm đó.
NÊN triển khai biện pháp bảo vệ chống quay về phiên bản cũ cho mọi thành phần có chương trình cơ sở cố định liên tục (ví dụ: modem, Camera) và NÊN sử dụng bộ nhớ chống giả mạo để lưu trữ siêu dữ liệu dùng để xác định phiên bản tối thiểu được phép.

Dự án nguồn mở Android (AOSP) thượng nguồn cung cấp một cách triển khai ưu tiên cho tính năng này trong kho lưu trữ external/avb/. Bạn có thể tích hợp kho lưu trữ này vào trình tải khởi động dùng để tải Android.

Nếu các phương thức triển khai thiết bị có thể xác minh nội dung tệp trên cơ sở từng trang, thì:

[C-2-1] hỗ trợ xác minh nội dung tệp bằng mật mã mà không cần đọc toàn bộ tệp.
[C-2-2] KHÔNG ĐƯỢC 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 được xác minh theo [C-2-1] ở trên.
[C-2-4] PHẢI trả về tổng kiểm tra tệp trong O(1) cho các tệp đã bật.

Nếu các hoạt động triển khai thiết bị đã được ra mắt mà không có khả năng xác minh nội dung tệp dựa trên một 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 này bằng bản cập nhật phần mềm hệ thống, thì các hoạt động triển khai đó CÓ THỂ được miễn yêu cầu. Dự án nguồn mở Android thượng nguồn cung cấp một cách triển khai ưu tiên cho tính năng này dựa trên tính năng fs-verity của nhân Linux.

9.11. Khoá và thông tin đăng nhập

Hệ thống Kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ các khoá mã hoá trong một vùng chứa và sử dụng các khoá đó trong các hoạt động mã hoá thông qua KeyChain API hoặc Keystore API. Triển khai 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] Cơ chế xác thực trên màn hình khoá PHẢI triển khai một 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 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 nhất là 30*2^floor((n-30)/10) giây hoặc ít nhất là 24 giờ, tuỳ theo giá trị nào nhỏ hơn.
KHÔNG ĐƯỢC giới hạn số lượng khoá có thể được tạo.

Khi quá trình triển khai thiết bị hỗ trợ màn hình khoá bảo mật, thì:

[C-1-1] PHẢI sao lưu việc 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 có các phương thức triển khai 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 MD5, SHA-1 và SHA-2 các thuật toán mã hoá và hàm băm do phiên bản IKeyMintDevice hoặc IKeymasterDevice được hỗ trợ yêu cầu để 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 cách ly an toàn với mã đang chạy trên nhân trở lên. Tính năng cách ly an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà mã không gian người dùng hoặc mã nhân hệ điều hành có thể truy cập vào trạng thái nội bộ của môi trường biệt lập, 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 chế độ triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc chế độ triển khai bảo mật đã được bên thứ ba xem xét của một giải pháp cách ly 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 biệt lập và chỉ khi 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. Thông tin đăng nhập trên 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 biệt lập 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 (HAL) Gatekeeper và Trusty. Bạn có thể dùng các lớp này để đáp ứng yêu cầu này.
[C-1-4] PHẢI hỗ trợ quy trình 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à quy trình ký được thực hiện trong phần cứng bảo mật. Bạn KHÔNG ĐƯỢC phép sử dụng khoá ký chứng thực làm giá trị nhận dạng thiết bị vĩnh viễn.

Lưu ý: Để đáp ứng yêu cầu này, bạn phải chia sẻ cùng một khoá chứng thực cho một SKU nhất định,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của SKU đó. Nếu có hơn 100.000 đơn vị của SKU đó được sản xuất, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, bạn có thể sử dụng giải pháp Cung cấp khoá từ xa để cung cấp các khoá chứng thực có thời hạn ngắn cho thiết bị.

[C-1-5] PHẢI cho phép người dùng chọn thời gian chờ chuyển sang chế độ ngủ để chuyển 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à 15 giây. Các thiết bị ô tô sẽ 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ờ chuyển sang chế độ ngủ.
[C-1-6] PHẢI hỗ trợ IKeymasterDevice 3.0 trở lên hoặc IKeyMintDevice phiên bản 1 trở lên.

[C-SR-1] NÊN THỰC HIỆN để thực thi khoảng thời gian tối thiểu giữa các lần thử không thành công riêng biệt cho các phương pháp xác thực chính (chẳng hạn như mã PIN, hình mở khoá hoặc mật khẩu), dựa trên những điều sau:

Số lần thử không thành công riêng biệt	Thời gian chờ tối thiểu
0-4	0
5	1 phút
6	5 phút
7	15 phút
8	30 phút
9	90 phút
10	4 giờ
11	12 giờ
12	24 giờ
13	4 ngày
14	13 ngày
15	41 ngày
16	123 ngày
17	1 năm
18	3 năm
19	9 năm

9.11.1. Màn hình khoá bảo mật, 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 cấp, trong đó phương thức xác thực chính dựa trên yếu tố kiến thức có thể được hỗ trợ bằng phương thức sinh trắc học mạnh thứ cấp hoặc bằng các phương thức yếu hơn ở cấp độ thứ ba.

Triển khai thiết bị:

[C-SR-1] BẠN NÊN THIẾT LẬP MỘT TRONG CÁC PHƯƠNG THỨC SAU LÀM phương thức xác thực chính:
- Mã PIN bằng số
- Mật khẩu dạng chữ và số
- 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 coi là phương thức xác thực chính được đề xuất trong tài liệu này.
[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] RẤT 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 các hoạt động triển khai thiết bị đặt mã PIN bằ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 DÙNG mã PIN có ít nhất 6 chữ số hoặc tương đương với entropy 20 bit.
[C-SR-7] KHÔNG NÊN cho phép tự động nhập 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.

Nếu các phương thứ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 và sử dụng một phương thức xác thực mới làm cách thức bảo mật để khoá màn hình, thì phương thức xác thực mới sẽ:

[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 các phương thức triển khai thiết bị thêm hoặc sửa đổi các phương pháp xác thực để mở khoá màn hình khoá dựa trên một bí mật đã biết và sử dụng một phương pháp xác thực mới được coi là một cách bảo mật để khoá màn hình:

[C-3-1] Entropy 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] Entropy tối đa của tất cả các đầu vào có thể có 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] Phương thức xác thực mới PHẢI bị vô hiệu hoá khi ứng dụng trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách yêu cầu về 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] Các 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, mẫu hình, mật khẩu) sau mỗi 72 giờ hoặc ít hơn HOẶC công khai 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ư cho dữ liệu của họ.

Nếu các quy 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 để 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 dữ liệu sinh trắc học để được coi là một cách bảo mật để khoá màn hình, thì phương thức mới này:

[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 một 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 trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách tính năng khoá màn hình 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 bằng 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] Các phương thức PHẢI bị vô hiệu hoá 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 theo yêu cầu về mật khẩu thông qua DevicePolicyManager.setRequiredPasswordComplexity() với một nhóm độ 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 một 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 yêu cầu xác thực chính theo đề xuất (chẳng hạn như mã PIN, hình mở khoá hoặc 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 này KHÔNG ĐƯỢC coi là màn hình khoá an toàn 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 các phương thứ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à 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] Họ PHẢI có một 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 một bí mật đã biết và đáp ứng các yêu cầu để được coi là một màn hình khoá an toàn.
[C-6-2] Phương thức mới PHẢI bị vô hiệu hoá 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 Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách bằng một trong hai cách:
- 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 PASSWORD_QUALITY_NONE.
- Phương thức DevicePolicyManager.setRequiredPasswordComplexity() có nhóm độ 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 sử dụng một trong các phương pháp xác thực chính được đề xuất (chẳng hạn như mã PIN, hình mở khoá hoặc mật khẩu) ít nhất một lần sau mỗi 4 giờ hoặc ít hơn. Khi một mã thông báo thực đáp ứng các yêu cầu đối với việc 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 ràng buộc được liệt kê trong C-8 bên dưới.

[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ị hoãn lại hoặc có thể được mở khoá bằng(các) tác nhân tin cậy. Ví dụ: AOSP đáp ứng yêu cầu này bằng cách hiển thị nội dung mô tả bằng văn bản cho "Chế độ cài đặt tự động khoá" và "Khoá ngay bằng nút nguồn" trong trình đơn cài đặt, cũng như 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ả các API 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 đủ chức năng TrustAgentService.addEscrowToken() trên thiết bị được 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 đủ chức năng này trên các thiết bị thường được dùng chung (ví dụ: Android Television hoặc thiết bị trên ô tô).
[C-7-4] PHẢI mã hoá tất cả các mã thông báo đã lưu trữ do TrustAgentService.addEscrowToken() thêm.
[C-7-5] KHÔNG ĐƯỢC lưu trữ khoá mã hoá hoặc mã thông báo uỷ thác trên cùng một thiết bị nơi khoá được dùng. 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 các thiết bị Automotive, bạn không được phép lưu trữ mã thông báo uỷ thác 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 cho phép mã thông báo uỷ thác 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-9] 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 (chẳng hạn như mã PIN, mẫu hình hoặc mật khẩu) như mô tả trong [C-1-7] và [C-1-8] trong mục 7.3.10, trừ phi có lo ngại về sự an toàn của người dùng (ví dụ: người lái xe bị mất tập trung).
[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 ràng buộc được liệt kê trong C-8 bên dưới.
[C-7-11] KHÔNG ĐƯỢC phép TrustAgents trên 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 chúng để giữ thiết bị đã mở khoá ở trạng thái mở khoá trong tối đa 4 giờ. Phương thức 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 một kênh giao tiếp được bảo mật theo cách mã hoá (ví dụ: UKEY2) để truyền mã thông báo uỷ thác từ thiết bị lưu trữ đến thiết bị mục tiêu.

Nếu các hoạt động 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á bảo mật như mô tả ở trên và sử dụng một phương thức xác thực mới để mở khoá khoá bảo vệ:

[C-8-1] Phương thức mới PHẢI bị vô hiệu hoá khi ứng dụng Trình kiểm soát 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() với hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_NONE hoặc thông qua DevicePolicyManager.setRequiredPasswordComplexity() với hằng số độ phức tạp hạn chế hơn PASSWORD_COMPLEXITY_NONE.
[C-8-2] Họ KHÔNG ĐƯỢC phép đặ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 phép cung cấp một API để các ứng dụng bên thứ ba sử dụng nhằm thay đổi trạng thái khoá.

Nếu các phương thứ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 quan (chẳng hạn như thông qua VirtualDeviceManager), thì:

[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 các phương thức triển khai thiết bị cho phép ứng dụng tạo màn hình ảo thứ cấp 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-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] Yêu cầu này đã bị xoá trong Android 16.
[C-10-3] Yêu cầu này đã bị xoá trong Android 16.
[C-10-4] PHẢI khoá tất cả màn hình khi người dùng bắt đầu chế độ khoá, kể cả thông qua chế độ khoá mà người dùng có thể truy cập theo yêu cầu đối với 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 phát trực tuyến ứng dụng như được chỉ ra bằng DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] Yêu cầu này đã bị xoá trong Android 16.
[C-10-11] PHẢI tắt giao diện người dùng xác thực trên các thiết bị ảo, bao gồm cả mục nhập hệ số kiến thức và lời nhắc sinh trắc học
[C-10-12] Yêu cầu này đã bị xoá trong Android 16.
[C-10-13] KHÔNG ĐƯỢC sử dụng trạng thái phương thức khoá thiết bị ảo làm uỷ quyền xác thực người dùng bằng Hệ thống kho khoá Android. Xem KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] PHẢI cung cấp cho người dùng một phương thức để bật tính năng chia sẻ bảng nhớ tạm giữa các thiết bị trước khi chia sẻ dữ liệu trên bảng nhớ tạm giữa các thiết bị thực và thiết bị ảo nếu thiết bị đang triển khai bảng nhớ tạm dùng chung.
[C-10-15] PHẢI hiển thị thông báo khi dữ liệu trên bảng nhớ tạm được truy cập trên cả thiết bị mà dữ liệu được truy cập và trên thiết bị mà bảng nhớ tạm bắt nguồn.

Khi các quy trình triển khai thiết bị cho phép người dùng chuyển yếu tố kiến 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 cho thiết bị mục tiêu, thì các quy trình này sẽ:

[C-11-1] PHẢI mã hoá yếu tố kiến thức bằng các biện pháp bảo vệ tương tự như những biện pháp được mô tả trong sách trắng về bảo mật Dịch vụ kho khoá trên Google Cloud khi chuyển yếu tố kiến thức từ thiết bị nguồn sang thiết bị mục tiêu sao cho yếu tố kiến thức không thể được giải mã từ xa hoặc dùng để mở khoá từ xa một trong hai thiết bị.
[C-11-2] PHẢI, trên thiết bị nguồn , 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ước khi chuyển hệ số kiến thức sang thiết bị mục tiêu.
[C-11-3] PHẢI yêu cầu người dùng xác nhận một hệ số kiến thức đã chuyển trên thiết bị mục tiêu trước khi đặt hệ số kiến thức đó làm hệ số kiến thức xác thực chính cho thiết bị mục tiêu và trước khi cung cấp mọi dữ liệu được chuyển từ thiết bị nguồn trên thiết bị mục tiêu không có bất kỳ hệ số kiến thức xác thực chính nào đã đặt.

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, gọi API hệ thống TrustAgentService.grantTrust() bằng cờ FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, thì các phương thức triển khai đó:

[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 ở gầ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 phát hiện 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 chế độ 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 chuyển thiết bị từ trạng thái TrustState.TRUSTABLE sang 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() nếu các quy trình triển khai không sử dụng tính năng đo khoảng cách chính xác và bảo mật bằng mật mã như được xác định trong [C-12-5]:
- Sau tối đa 24 giờ kể từ khi cấp quyền tin cậy, hoặc
- Sau 8 giờ không hoạt động hoặc
- Nếu các quy trình triển khai không sử dụng phạm vi chính xác và an toàn về mặt 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 ở gần.

[C-12-5] Các hoạt động triển khai dựa trên tính năng đo khoảng cách chính xác và an toàn để đá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 cách triển khai bằng UWB:
  - PHẢI đáp ứng các yêu cầu về sự phù hợp, chứng nhận, độ chính xác và hiệu chuẩn đối với UWB được mô tả trong 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 7.4.9.
- Các hoạt động triển khai sử dụng mạng nhận biết thiết bị lân cận (NAN) qua Wi-Fi:
  - 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 chế độ thiết lập tính năng đo lường được chỉ định trong phần Hiệu chỉnh sự 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 các hoạt động 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-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ỏi việc 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 rõ ràng tính năng phát trực tuyến và cho biết rằng các hoạt động đó hiển thị nội dung nhạy cảm, kể cả thông qua SurfaceView#setSecure và FLAG_SECURE, không được bắt đầu trên thiết bị ảo.

Nếu các chế độ 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-SR-2] RẤT NÊN sử dụng thông tin đăng nhập đáp ứng các yêu cầu được xác định trong phần 9.11.1 hoặc dữ liệu sinh trắc học đáp ứng ít nhất các quy cách Lớp 1 được xác định trong phần 7.3.10 để cho phép mở khoá độc lập khỏi màn hình thiết bị mặc định.
[C-SR-3] NÊN HẠN CHẾ MẠNH MẼ việc mở khoá màn hình riêng biệt thông qua thời gian chờ hiển thị đã xác định.
[C-SR-4] RẤT NÊN cho phép người dùng khoá toàn bộ màn hình thông qua chế độ khoá trên 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ữ các 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 biệt lập 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 từ C-1-3 đến C-1-11 bên dưới xác định những yêu cầu mà một thiết bị phải đáp ứng để đủ điều kiện là StrongBox.

Các thiết bị có bộ xử lý bảo mật chuyên dụng:

[C-SR-1] RẤT NÊN DÙNG để hỗ trợ StrongBox. StrongBox có thể sẽ trở thành một yêu cầu bắt buộc trong bản phát hành sắp tới.

Nếu các hoạt động triển khai thiết bị hỗ trợ StrongBox, thì:

[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 được dùng để sao lưu kho khoá và xác thực người dùng bảo mật. Phần cứng bảo mật chuyên dụng này cũng có thể được 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 dùng chung bộ nhớ đệm, DRAM, bộ đồng xử lý hoặc các tài nguyên 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 dùng chung với AP không được làm thay đổi quá trình xử lý StrongBox theo bất kỳ cách nào hoặc thu thập bất kỳ thông tin nào từ StrongBox. AP CÓ THỂ vô hiệu hoá 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 thao túng.
[C-1-6] PHẢI có một trình tạo số ngẫu nhiên thực sự tạo ra đầu ra 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 giả mạo, bao gồm cả khả năng chống xâm nhập vật lý và chống lỗi.
[C-1-8] PHẢI có khả năng chống lại kênh phụ, bao gồm cả khả năng chống lại việc rò rỉ thông tin qua nguồn điện, thời gian, bức xạ điện từ và các kênh phụ 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à độ mới của nội dung. Bộ nhớ KHÔNG ĐƯỢC phép đọc hoặc thay đổi, trừ phi được phép theo các API StrongBox.

Để xác thực việc tuân thủ [C-1-3] đến [C-1-9], việc triển khai thiết bị:

[C-1-10] PHẢI có phần cứng được chứng nhận theo Hồ sơ bảo vệ IC an toàn BSI-CC-PP-0084-2014 hoặc BSI-CC-PP-0117-2022, hoặc được phòng thí nghiệm kiểm thử được quốc gia công nhận đánh giá, kết hợp Đánh giá lỗ hổng bảo mật có khả năng tấn công cao theo Ứng dụng Tiêu chí chung về khả năng tấn công đối với thẻ thông minh.
[C-1-11] PHẢI bao gồm chương trình cơ sở được phòng thử nghiệm được công nhận trên toàn quốc đánh giá, kết hợp với Đánh giá lỗ hổng bảo mật có khả năng tấn công cao theo Ứng dụng tiêu chí chung về khả năng tấn công đối với thẻ thông minh.
[C-SR-2] RẤT NÊN BAO GỒM phần cứng được đánh giá bằng Mục tiêu bảo mật, Cấp độ đảm bảo đánh giá (EAL) 5, được tăng cường bằng AVA_VAN.5. Chứng nhận EAL 5 có thể sẽ trở thành một yêu cầu trong bản phát hành sau này.
[C-SR-3] NÊN CÓ khả năng chống tấn công nội bộ (IAR), tức là nhân viên nội bộ có quyền truy cập vào khoá ký chương trình cơ sở không thể tạo ra chương trình cơ sở khiến StrongBox làm lộ 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. Cách triển khai IAR được đề xuất là 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 IAuthSecret HAL.

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ả cá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 tài liệu nhận dạng người dùng. Triển khai thiết bị:

[C-SR-1] ĐƯỢC KHUYẾN NGHỊ MẠNH MẼ triển khai Hệ thống thông tin xác thực danh tính.

Nếu các hoạt động triển khai thiết bị triển khai Hệ thống thông tin xác thực danh tính, thì:

[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 đăng nhập 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 cách ly an toàn với mã đang chạy trên nhân và ở trên. Tính năng cách ly an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà mã nhân hệ điều hành 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 biệt lập, 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à nội dung khoá riêng tư KHÔNG BAO GIỜ được rời khỏi môi trường thực thi biệt lập, trừ phi được 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 sao cho 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 đăng nhập không được phát hành trừ phi 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 hoạt động sai hoặc bị xâm nhập.

Dự án nguồn mở Android ở thượng nguồn 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 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 dữ liệu người dùng khi thực hiện thao tác "Đặ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 có liên quan, chẳng hạn như NIST SP800-88 khi thực hiện thao tác "Đặt lại dữ liệu về trạng thái ban đầu".
[C-0-4] PHẢI kích hoạt quy trình "đặt lại dữ liệu về trạng thái ban đầu" nêu 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 một lựa chọn xoá dữ liệu nhanh, chỉ thực hiện 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 ở chế độ chỉ cho phép các ứng dụng hệ thống được cài đặt sẵn chạy và vô hiệu hoá tất cả cá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 có khả năng gây hại của bên thứ ba.

Các cách triển khai thiết bị là:

[C-SR-1] BẠN NÊN TRIỂN KHAI Chế độ khởi động an toàn.

Nếu các hoạt động triển khai thiết bị triển khai Chế độ khởi động an toàn, thì:

[C-1-1] PHẢI cung cấp cho người dùng một lựa chọn để chuyển sang 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ị, trừ phi ứng dụng bên thứ ba đó là Trình kiểm soát chính sách thiết bị và đã đặt cờ UserManager.DISALLOW_SAFE_BOOT thành true.
[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 lựa chọn truy cập Chế độ khởi động an toàn từ trình đơn khởi động bằng một quy trình khác với quy trình khởi động thông thường.

9.14. Cách ly hệ thống xe ô tô

Các thiết bị Android Automotive dự kiến 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 các mạng của xe, chẳng hạn như bus CAN.

Bạn có thể bảo mật việc 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 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" là thông tin chi tiết về kế hoạch 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 thiết bị:

[C-0-1] CHỈ ĐƯỢC PHÉP trả về các gói thuê bao cho ứng dụng của nhà mạng di động đã cung cấp các gói đó ban đầu.
[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 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 các phương thức triển khai thiết bị có khả năng di chuyển dữ liệu từ một thiết bị sang một thiết bị khác và không giới hạn dữ liệu ứng dụng mà thiết bị sao chép theo những gì được 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 phương thức triển khai đó:

[C-1-1] KHÔNG ĐƯỢC bắt đầu chuyển dữ liệu ứng dụng từ các thiết bị mà người dùng chưa đặt phương thức xác thực chính như mô tả trong phần 9.11.1 Khoá bảo mật và xác thực an toàn.
[C-1-2] PHẢI xác nhận một cách an toàn phương thức xác thực chính trên thiết bị nguồn và xác nhận ý định của người dùng muốn 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 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 dữ liệu 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 đã khoá.
[C-1-4] CHỈ ĐƯỢC PHÉP di chuyển dữ liệu ứng dụng sang cùng một ứng dụng trên thiết bị mục tiêu, 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 ĐƯỢC phép xoá chỉ báo này.

9.17. Khung ảo hoá cho Android

Các API Khung ảo hoá cho Android (AVF) (android.system.virtualmachine.*) cho phép các ứng dụng tạo máy ảo (VM), máy ảo được bảo vệ (pVM) và máy ảo không được bảo vệ (non-pVM) trên thiết bị. Các máy ảo này tải và chạy các tệp nhị phân gốc dưới dạng tải trọng.

Nếu các hoạt động triển khai thiết bị đặt FEATURE_VIRTUALIZATION_FRAMEWORK thành true, thì:

[C-1-1] PHẢI đảm bảo rằng android.system.virtualmachine.VirtualMachineManager.getCapabilities() trả về một trong những giá trị sau:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Xác minh nhà phát triển

Các phương thức triển khai thiết bị khai báo cấp độ API 36.1 trở lên:

CÓ THỂ bao gồm hỗ trợ cho dịch vụ xác minh của nhà phát triển để chứng nhận rằng các ứng dụng đến từ một nhà phát triển đã biết.

Các phương thức triển khai thiết bị khai báo cấp độ API 36.1 trở lên và định cấu hình trình xác minh dành cho nhà phát triển bằng cách xác định config_developerVerificationServiceProviderPackageName trong config.xml:

[9.18/C-1-1] PHẢI gọi android.content.pm.verify.developer.DeveloperVerifierService đã định cấu hình cho mỗi lần cài đặt gói ứng dụng, bao gồm cả lượt cài đặt mới và lượt cập nhật cho các ứng dụng hiện có.

Các phương thức triển khai thiết bị khai báo cấp độ API 36.1 trở lên:

MAY cũng có thể định cấu hình một uỷ quyền để đặt chính sách đang hoạt động bằng cách xác định config_developerVerificationPolicyDelegatePackageName trong config.xml.

Nếu một trình xác minh của nhà phát triển được định cấu hình, thì các hoạt động triển khai thiết bị sẽ:

[9.18/C-2-1] CHỈ ĐƯỢC PHÉP trình xác minh của nhà phát triển hoặc đại biểu được định cấu hình của trình xác minh đó đặt chính sách cài đặt như được xác định trong android.content.pm.PackageInstaller.

Nếu trình xác minh được gọi trong một phiên cài đặt gói, thì các hoạt động triển khai thiết bị:

[9.18/C-3-1] PHẢI ngăn việc cài đặt một gói ứng dụng nếu:
- Quá trình cài đặt không xác minh được danh tính của nhà phát triển.
- Chính sách xác minh nhà phát triển cho phiên cài đặt được đặt thành bất kỳ giá trị nào khác DEVELOPER_VERIFICATION_POLICY_NONE.
- Trừ phi áp dụng một trong hai quy tắc 9.18/C-3-2 hoặc 9.18/C-3-3.

[9.18/C-3-2] KHÔNG ĐƯỢC ngăn chặn việc cài đặt một gói ứng dụng bất kể chính sách hoặc trạng thái xác minh khi:
- Gói được cài đặt thông qua Cầu gỡ lỗi Android (ADB).
- Gói này là trình xác minh nhà phát triển đã định cấu hình hoặc trình cài đặt của trình xác minh đó.

[9.18/C-3-3] KHÔNG ĐƯỢC ngăn chặn việc cài đặt một gói ứng dụng khi đáp ứng tất cả các điều kiện sau:
- Chính sách được đặt thành DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN hoặc DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- Quá trình xác minh được báo cáo là chưa hoàn tất.
- Trình cài đặt cho biết người dùng đã yêu cầu rõ ràng quá trình cài đặt tiếp tục bằng cách báo cáo DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

CÓ THỂ cho phép cài đặt một gói ứng dụng bất kể chính sách hoặc trạng thái xác minh đối với các lượt cài đặt do chủ sở hữu thiết bị trên thiết bị được quản lý hoặc chủ sở hữu hồ sơ trên hồ sơ được quản lý khởi tạo, nhưng BẠN NÊN NGĂN CHẶN các lượt cài đặt như mô tả trong 9.18/C-3-1.

10. Kiểm thử khả năng tương thích của phần mềm

Các hoạt động triển khai thiết bị PHẢI vượt qua tất cả các 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 là hoàn toàn toàn diện. Vì lý do này, các nhà triển khai thiết bị RẤT NÊN thực hiện số lượng thay đổi tối thiểu có thể đối với quá trình triển khai tham chiếu và ưu tiên của Android có trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ xuất hiện các lỗi gây ra sự không tương thích, đòi hỏi phải làm lại và có thể phải cập nhật thiết bị.

10.1. Bộ kiểm tra tính tương thích

Triển khai thiết bị:

[C-0-1] PHẢI vượt qua Bộ kiểm tra tính tương thích (CTS) với Android có trong Dự án nguồn mở Android, bằng cách sử dụng phần mềm vận chuyển cuối cùng 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 có sự mơ hồ trong CTS và đối với mọi lần 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, CTS có thể chứa lỗi. CTS sẽ được phân phiên bản độc lập với Định nghĩa về khả năng tương thích này và nhiều bản sửa đổi của CTS có thể được phát hành cho Android 17.

Triển khai thiết bị:

[C-0-3] PHẢI vượt qua phiên bản CTS mới nhất có tại thời điểm hoàn tất phần mềm thiết bị.
NÊN sử dụng cách 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

CTS Verifier có trong Bộ kiểm tra tính tương thích và được thiết kế để do một nhân viên vận hành chạy nhằm kiểm thử chức năng mà hệ thống tự động không kiểm thử được, chẳng hạn như chức năng hoạt động chính xác của camera và các cảm biến.

Triển khai thiết bị:

[C-0-1] PHẢI thực thi chính xác tất cả các trường hợp áp dụng trong trình xác minh CTS.

Trình xác minh CTS có các quy trình 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 thiết bị:

[C-0-2] PHẢI vượt qua tất cả các bài kiểm thử đối với 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 bỏ sót các trường hợp kiểm thử cho những tính năng được ghi nhận là không bắt buộc theo Tài liệu Định nghĩa về khả năng tương thích này.

[C-0-2] Mọi thiết bị và mọi bản dựng ĐỀU PHẢI chạy CTS Verifier một cách chính xác, như đã lưu ý ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên các đơn vị triển khai thiết bị không cần chạy CTS Verifier một cách rõ ràng trên những bản dựng chỉ khác nhau theo những cách không đáng kể. Cụ thể, những chế độ triển khai thiết bị khác với chế độ triển khai đã vượt qua Trình xác minh CTS chỉ bằng bộ ngôn ngữ, thương hiệu, v.v. được đưa vào CÓ THỂ bỏ qua kiểm thử Trình xác minh CTS.

11. Phần mềm có thể cập nhật

[C-0-1] Các hoạt động 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à bạn CÓ THỂ 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ụ: mọi phương pháp sau đây đều đáp ứng yêu cầu này:
- Tải xuống "qua mạng không dây (OTA)" bằng cách cập nhật ngoại tuyến thông qua khởi động lại.
- Bản cập nhật "chia sẻ Internet" qua USB từ máy tính lưu trữ.
- Bản 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ớ di động.
[C-0-2] Cơ chế cập nhật được 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ữ nguyên 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 nguồn mở 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 dựa trên khoá công khai bằng ECDSA NIST P-256.

Nếu các hoạt động triển khai thiết bị có hỗ trợ kết nối dữ liệu không đo lượng dữ liệu như 802.11 hoặc cấu hình PAN (Mạng cá nhân) Bluetooth, thì:

[C-1-1] PHẢI hỗ trợ tải OTA xuống bằng cách cập nhật ngoại tuyến thông qua khởi động lại.

Các hoạt động triển khai thiết bị PHẢI xác minh rằng hình ảnh hệ thống giống hệt nhau về mặt nhị phân 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 ở nguồn trên, được thêm vào từ Android 5.1, đáp ứng yêu cầu này.

Ngoài ra, các hoạt động 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 thấy lỗi trong quá trình triển khai thiết bị sau khi thiết bị được phát hành nhưng vẫn trong thời gian sử dụng hợp lý của sản phẩm (được xác định sau khi tham khảo ý kiến của Nhóm tương thích Android) và lỗi đó ả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] Nhà triển khai thiết bị PHẢI sửa lỗi thông qua bản cập nhật phần mềm 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 các bản cập nhật hệ thống. Nếu hệ thống con cập nhật bản cập nhật hệ thống cho các 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 của tài liệu

Kể từ Android 16, nhật ký thay đổi sẽ không được duy trì riêng. Tất cả thay đổi so với phiên bản trước đều được đánh dấu trong tài liệu này.

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 của Android và yêu cầu làm rõ hoặc nêu ra mọi vấn đề mà bạn cho rằng tài liệu này chưa đề cập đến.

Định nghĩa về khả năng tương thích của Android 17 [XEM TRƯỚC] Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

1. Giới thiệu

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

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

1.1.2. Mã yêu cầu

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

2. Loại thiết bị

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

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

2.2.1. Phần cứng

2.2.2. Đa phương tiện

2.2.3. Phần mềm

2.2.3. Phần mềm

2.2.4. Hiệu suất và sức mạnh

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

Chế độ cài đặt bị hạn chế

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

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

2.2.7.1. Nội dung nghe nhìn

2.2.7.2. Máy ảnh

2.2.7.3. Phần cứng

2.2.7.4. Hiệu suất

2.2.7.5. Đồ hoạ

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

2.3.1. Phần cứng

2.3.2. Đa phương tiện

2.3.3. Phần mềm

2.3.4. Hiệu suất và sức mạnh

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

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

2.4. Yêu cầu đối với đồng hồ

2.4.1. Phần cứng

2.4.2. Đa phương tiện

2.4.3. Phần mềm

2.4.4. Hiệu suất và sức mạnh

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

2.5. Yêu cầu đối với ô tô

2.5.1. Phần cứng

2.5.2. Đa phương tiện

2.5.3. Phần mềm

2.5.4. Hiệu suất và sức mạnh

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

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

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

2.6.1. Phần cứng

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

2.6.2. Phần mềm

3. Phần mềm

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

3.1.1. Tiện ích Android

3.1.2. Thư viện Android

3.2. Khả năng tương thích API linh hoạt

3.2.1. Quyền

3.2.2. Tham số bản dựng

3.2.3. Khả năng tương thích về ý định

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

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

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

3.2.3.4. Ý định truyền tin

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

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

3.3. Khả năng tương thích của API gốc

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

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

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

3.4.1. Khả năng tương thích của WebView

3.4.2. Khả năng tương thích của trình duyệt

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

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

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

3.6. Không gian tên API

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

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)

3.8.2. Tiện ích

3.8.3. Thông báo

3.8.3.1. Cách trình bày thông báo

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

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

3.8.3.4. Bảo vệ thông báo nhạy cảm

Định nghĩa về khả năng tương thích của Android 17 [XEM TRƯỚC]