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

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

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

1. Giới thiệu

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

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

Như được sử dụng trong tài liệu này, "trình triển khai thiết bị" hoặc "người triển khai" là một người hoặc tổ chức phát triển một giải pháp phần cứng/phần mềm chạy Android 15. "Triển khai thiết bị" hoặc "triển khai" là đã phát triển đến nay.

Để được coi là tương thích với Android 15, thiết bị Quá trình triển khai PHẢI đáp ứng các yêu cầu được trình bày trong phần Khả năng tương thích này Định nghĩa, bao gồm mọi giấy tờ được đưa vào thông qua tệp đối chiếu.

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

Vì lý do này, Dự án nguồn mở Android vừa là phương thức tham khảo vừa là cách triển khai ưu tiên của Android. Thiết bị những người triển khai được ĐỀ XUẤT HẰNG NGHỊ để xây dựng cơ sở cho việc triển khai của họ phạm vi lớn nhất có thể ở "phía trước" mã nguồn có sẵn trong Dự án nguồn mở Android. Mặc dù theo giả định, một số thành phần có thể được thay thế bằng các phương pháp triển khai thay thế, thì thành phần này là được linh hoạt "NÊN DÙNG" hãy làm theo phương pháp này, vì việc vượt qua bài kiểm thử phần mềm sẽ giúp khó hơn. Trách nhiệm của người triển khai là đảm bảo khả năng tương thích về hành vi với việc triển khai Android tiêu chuẩn, bao gồm và vượt ra ngoài Bộ kiểm tra tính tương thích. Cuối cùng, xin lưu ý rằng một số thành phần các mục thay thế và sửa đổi bị cấm rõ ràng trong tài liệu này.

Nhiều tài nguyên được liên kết trong tài liệu này được lấy trực tiếp hoặc gián tiếp từ SDK Android và có chức năng giống với trong tài liệu của SDK đó. Trong bất kỳ trường hợp nào mà Khả năng tương thích này Định nghĩa hoặc Bộ kiểm tra tính tương thích không đồng ý với SDK thì tài liệu về SDK được coi là có căn cứ đáng tin. Mọi kỹ thuật thông tin được cung cấp trong các tài nguyên được liên kết trong tài liệu này được xem xét để đưa vào Đị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 loại thiết bị cụ thể. Mỗi tiểu mục của Phần 2 là dành riêng cho một loại thiết bị cụ thể.

Tất cả những yêu cầu khác, áp dụng chung cho mọi thiết bị Android được liệt kê trong các phần sau Phần 2. Những yêu cầu này được gọi là "Yêu cầu chính" trong tài liệu này.

1.1.2. Mã yêu cầu

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

Mã nhận dạng này chỉ được chỉ định cho các yêu cầu PHẢI.
Các yêu cầu được liệt kê là NÊN DÙNG được đánh dấu là [SR] nhưng mã nhận dạng lại không được chỉ định.
Mã nhận dạng 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 định nghĩa như sau:

Mã loại thiết bị (xem thêm trong phần 2. Loại thiết bị)
- C: Lõi (Các yêu cầu áp dụng cho tất cả các hoạt động triển khai thiết bị Android)
- H: Thiết bị cầm tay Android
- T: Thiết bị Android TV
- Đáp: Triển khai Android Automotive
- W: Triển khai Android Watch
- Thẻ: Triển khai Android Tablet
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 có điều kiện, 1 được chỉ định cho URL đầu tiên điều kiện và số tăng lên 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 mục và cùng điều kiện.

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

Mã yêu cầu trong Phần 2 gồm hai phần. Đầu tiên tương ứng với ID mục như được mô tả ở trên. Phần thứ hai xác định kiểu dáng thiết bị và yêu cầu riêng của từng hệ số hình dạng.

Mã mục, theo sau là Mã yêu cầu được 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ể sử dụng được cho nhiều loại thiết bị và kiểu dáng. Để hỗ trợ bảo mật trên thiết bị, bộ phần mềm cơ sở, bao gồm mọi hệ điều hành thay thế hoặc nhân thay thế triển khai, dự kiến sẽ thực thi trong một môi trường an toàn như được mô tả trong mục 9 và những nơi khác trong CDD này. Có một vài loại thiết bị có hệ sinh thái phân phối ứng dụng lâu đời 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 bổ sung và các đề xuất phù hợp với từng loại thiết bị.

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

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

Đối với những khác biệt lớn về cấu hình phần cứng theo thiết bị hãy xem yêu cầu dành riêng cho thiết bị sau trong phần này.

2.2. Yêu cầu khi cầm tay

Thiết bị Android cầm tay đề cập đến cách triển khai thiết bị Android thường được sử dụng bằng cách cầm điện thoại 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.

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

Có nguồn điện giúp đảm bảo khả năng vận động, chẳng hạn như pin.
Có kích thước màn hình theo đường chéo thực tế trong khoảng 4 inch đến 8 inch.
Có giao diện nhập bằng màn hình cảm ứng.

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

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

2.2.1. Phần cứng

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

[7.1.1.1/H-0-1] PHẢI có ít nhất một Màn hình tương thích với Android 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] Are được linh hoạt đề xuất tới cung cấp cho người dùng một thuộc tính tương tác để 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 vùng đệm đồ hoạ tích hợp ít nhất là bằng độ phân giải cao nhất của bất kỳ màn hình.
[7.1.1.1/H-0-3]* PHẢI ánh xạ mỗi UI_MODE_NORMAL màn hình được cung cấp cho các ứng dụng của bên thứ ba trên màn hình không bị che khuất khu vực hiển thị thực tế tối thiểu là 2,2 inch inch trên cạnh ngắn và 3,4 inch inch trên cạnh dài.
[7.1.1.3/H-0-1]* PHẢI đặt giá trị của DENSITY_DEVICE_STABLE phải bằng hoặc lớn hơn 92% mật độ vật lý thực tế của màn hình tương ứng.

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

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

Nếu các phương thức triển khai Thiết bị cầm tay tuyên bố hỗ trợ cho dải động cao hiển thị thông qua Configuration.isScreenHdr() ! chúng:

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

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

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

Nếu phương thức triển khai Thiết bị cầm tay khai báo dịch vụ hỗ trợ qua một thuộc tính hệ thống graphics.gpu.profiler.support, họ:

[7.1.4.6/H-1-1] PHẢI báo cáo là đầu ra a dấu vết protobuf tuân thủ giản đồ bộ đếm GPU và GPU giai đoạn kết xuất được xác định trong tài liệu về 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 sau giao thức gói dấu vết bộ đếm gpu.
[7.1.4.6/H-1-3] PHẢI báo cáo các giá trị tuân thủ cho GPU RenderEpisodes của thiết bị theo giao thức gói dấu vết giai đoạn kết xuất.
[7.1.4.6/H-1-4] PHẢI báo cáo tần suất GPU dấu vết được chỉ định theo định dạng: power/gpu_frequency.

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

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

Nếu phương thức triển khai Thiết bị cầm tay bao gồm gia tốc kế 3 trục, thì các phương thức triển khai đó:

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

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

[7.3.3/H-2-1] PHẢI báo cáo số liệu đo lường GNSS, ngay khi chúng ngay cả khi vị trí tính bằng GPS/GNSS chưa được báo cáo.
[7.3.3/H-2-2] PHẢI báo cáo GNSS pseudoranges và pseudorange giá, trong điều kiện trời mở sau khi xác định vị trí, trong khi đứng yên hoặc đang di chuyển với tốc độ dưới 0,2 m/giây vuông gia tốc, đủ để tính vị trí trong phạm vi 20 mét và vận tốc với tốc độ tối thiểu 0,2 m/giây, tối thiểu 95% thời gian.

Nếu hoạt động triển khai Thiết bị cầm tay bao gồm con quay hồi chuyển 3 trục, thì chúng:

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

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

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

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

[7.3.11/H-SR-1] AreĐể nhà phát triển sử dụng chế độ này nhằm hỗ trợ các cảm biến vị trí với 6 bậc tự do.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

~~[7.4.3/H] NÊN bao gồm tính năng hỗ trợ cho Bluetooth và Bluetooth LE.~~

Các phương pháp triển khai cho thiết bị cầm tay có hỗ trợ Bluetooth LE:

[7.4.3/H-SR-1] Are Internet Đề xuất về hỗ trợ Phần mở rộng thời lượng gói dữ liệu Bluetooth năng lượng thấp.

Lưu ý: Yêu cầu này [7.4.3/H-SR-1] sẽ trở thành PHẢI trong bản phát hành Android sau này.

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

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

[7.4.2.5/H-1-1] PHẢI báo cáo chính xác phạm vi cho trong phạm vi +/-1 mét ở băng thông 160 MHz tại bách phân vị thứ 68 (theo tính toán) với Chức năng phân phối tích lũy), +/-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 bách phân vị thứ 68 ở khoảng cách 10 cm, 1 m, 3 m và 5 m, được quan sát qua WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] AreĐể nhà phát triển đề xuất báo cáo phạm vi chính xác đến trong phạm vi +/- 1 mét ở băng thông 160 MHz ở vị trí 90 phân vị (như được tính 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 ở 40 MHz băng thông tại phân vị thứ 90 và +/-8 mét ở băng thông 20 MHz tại Phân vị thứ 90 ở các khoảng cách 10 cm, được quan sát qua WifiRttManager#startRanging Android API.

NÊN làm theo các bước thiết lập đo lường được chỉ định trong Hiệu chỉnh sự hiện diện.

Nếu các phương thức triển khai Thiết bị cầm tay khai báo FEATURE_BLUETOOTH_LE, thì các phương thức triển khai đó:

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

Nếu quá trình triển khai Thiết bị cầm tay bao gồm một thiết bị camera logic liệt kê các khả năng sử dụng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA! chúng:

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

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ớ bất biến 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/H-0-2] PHẢI trả về "true" với ActivityManager.isLowRamDevice() khi có dưới 1 GB bộ nhớ có sẵn cho kernel và không gian người dùng.

Nếu phương thức triển khai Thiết bị cầm tay khai báo chỉ 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ối thiểu là 416MB nếu màn hình mặc định sử dụng bộ đệm khung độ phân giải 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à 592MB nếu màn hình mặc định sử dụng bộ đệm khung độ phân giải lên tới 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à 896MB nếu màn hình mặc định sử dụng bộ đệm khung độ phân giải 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ối thiểu là 1344MB nếu màn hình mặc định sử dụng độ phân giải vùng đệm khung lên đến QHD (ví dụ: QWXGA).

Nếu quá trình triển khai Thiết bị cầm tay khai báo khả năng hỗ trợ ABI 64 bit bất kỳ (có hoặc không có ABI 32 bit bất kỳ):

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

Lưu ý rằng "bộ nhớ còn trống cho nhân và không gian người dùng" ở trên đề cập đến dung lượng bộ nhớ được cung cấp bên cạnh mọi bộ nhớ đã dành riêng cho phần cứng các thành phần như radio, video, v.v. không nằm trong kernel kiểm soát các triển khai thiết bị.

Trường hợp phương thức triển khai Thiết bị cầm tay có bộ nhớ nhỏ hơn hoặc bằng 1 GB có sẵn cho kernel và không gian người dùng, họ:

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

Nếu phương thức triển khai Thiết bị cầm tay có hơn 1GB bộ nhớ vào nhân hệ điều hành và không gian người dùng, họ:

[7.6.1/H-10-1] PHẢI có ít nhất 4 GB bộ nhớ bất biến có sẵn 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ấu hình triển khai cho Thiết bị cầm tay có dung lượng lớn hơn hoặc bằng 2 GB và dưới 4GB bộ nhớ còn trống cho kernel và không gian người dùng, họ:

[7.6.1/H-SR-1] AreĐể chỉ hỗ trợ 32-bit userspace (cả ứng dụng và mã hệ thống)

Nếu quá trình triển khai Thiết bị cầm tay bao gồm dưới 2 GB bộ nhớ còn trống cho nhân hệ điều hành và không gian người dùng, họ:

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

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

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị cầm tay có bao gồm cổng USB ~~hỗ trợ~~ với bộ điều khiển đang hoạt động chế độ thiết bị ngoại vi, chúng:

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

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

Nếu phương thức triển khai Thiết bị cầm tay bao gồm cả cổng USB hỗ trợ chế độ máy chủ, chúng:

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

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

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

Liệu việc triển khai Thiết bị cầm tay có thể đáp ứng tất cả hiệu suất hay không các yêu cầu để hỗ trợ chế độ Thực tế ảo (VR) và bao gồm dịch vụ hỗ trợ cho chế độ này, chẳng hạn như:

[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 bao gồm một ứng dụng triển khai android.service.vr.VrListenerService có thể được bật bằng VR qua android.app.Activity#setVrModeEnabled.

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

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

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

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

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

[7.8.2.2/H-2-1] PHẢI broadcast Intent ACTION_HEADSET_PLUG với "micrô" có giá trị là 0.

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

[7.8.2.2/H-3-1] PHẢI broadcast Intent ACTION_HEADSET_PLUG với "micrô" tập bổ sung 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:

[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 thiết bị đầu cuối âm thanh USB là 0x0302.
[7.8.2.2/H-4-2] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò isSink() nếu thiết bị đầu cuối âm thanh USB trường loại 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 thiết bị đầu cuối âm thanh USB trường loại 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 thiết bị đầu cuối âm thanh USB là 0x603.
[7.8.2.2/H-4-5] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSource() nếu thiết bị đầu cuối âm thanh USB trường loại 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 loại thiết bị đầu cuối âm thanh USB trường 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 thiết bị đầu cuối âm thanh USB trường loại là 0x400.
[7.8.2.2/H-SR-1] AreĐể các nhà phát triển sử dụng kết nối một Thiết bị ngoại vi âm thanh USB-C, để liệt kê các bộ mô tả USB, hãy xác định loại thiết bị đầu cuối và Ý định truyền tin ACTION_HEADSET_PLUG trong vòng chưa đến 1000 mili giây.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

~~Nếu~~ Dành cho Triển khai thiết bị cầm tay để khai báo android.hardware.audio.output và android.hardware.microphone, ~~họ:~~ xem các yêu cầu về RTL và TTL trong phần 5.6.

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

[5.6/H-1-2] PHẢI có độ trễ Tap-to-tone trung bình 300 mili giây hoặc nhỏ hơn trên loa ít nhất 5 lần đo đến đường dẫn dữ liệu micrô.

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

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

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

[7.10/H] NÊN định vị vị trí của bộ truyền động gần vị trí người dùng thường cầm hoặc chạm vào thiết bị.
[7,10/Giờ] NÊN di chuyển bộ truyền động xúc giác theo trục X (trái-phải) hướng tự nhiên của thiết bị.

Nếu việc triển khai Thiết bị cầm tay có mục đích chung bộ truyền động xúc giác là bộ truyền động cộng hưởng tuyến tính (LRA) trục X, chúng:

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

Nếu các quá trình triển khai thiết bị cầm tay tuân theo quá trình ánh xạ hằng số xúc giác, thì các quá trình đó sẽ:

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

2.2.2. Đa phương tiện

Các phương pháp triển khai cho thiết bị cầm tay PHẢI hỗ trợ phương thức mã hoá âm thanh và giải mã các định dạng này và cung cấp chúng cho các ứng dụng của 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 MPEG-4 AAC (AAC LC)
[5.1/H-0-4] Cấu hình MPEG-4 HE AAC (AAC+)
[5.1/H-0-5] AAC ELD (AAC độ trễ thấp nâng cao)

Các quá trình triển khai thiết bị cầm tay PHẢI hỗ trợ phương thức mã hoá video sau đây và cung cấp chúng cho các ứng dụng của bên thứ ba:

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

Các quá trình triển khai thiết bị cầm tay PHẢI hỗ trợ phương thức giải mã video sau đây và cung cấp chúng cho các ứng dụng của 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

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

[3.2.3.1/H-0-1] PHẢI có xử lý ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE thân mến! và ACTION_CREATE_DOCUMENT ý định như được mô tả trong tài liệu SDK và cung cấp tương tác với người dù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 trước một tệp hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, để tất cả mẫu bộ lọc ý định công khai do ứng dụng sau xác định các ý định nêu tại đây.
[3.2.3.1/H-SR-1] AreSau NÊN tải trước ứng dụng email có thể xử lý ACTION_SENDTO hoặc ACTION_SEND hoặc ACTION_SEND_MULTIPLE ý định gửi email.
[3.4.1/H-0-1] PHẢI cung cấp đầy đủ triển khai API android.webkit.Webview.
[3.4.2/H-0-1] PHẢI bao gồm một Trình duyệt độc lập để duyệt web của người dùng nói chung.
[3.8.1/H-SR-1] Are mã hoá NÊN DÙNG để triển khai một trình chạy mặc định có hỗ trợ tính năng ghim lối tắt trong ứng dụng, widget và WidgetFeatures.
[3.8.1/H-SR-2] Are mã hoá NÊN DÙNG để triển khai một trình chạy mặc định giúp truy cập nhanh vào lối tắt do các ứng dụng bên thứ ba cung cấp thông qua shortcutManager API.
[3.8.1/H-SR-3] Are mã hoá NÊN DÙNG để đưa vào một ứng dụng trình chạy mặc định để hiện huy hiệu cho biểu tượng ứng dụng.
[3.8.2/H-SR-1] Arefaq REVIEW để 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 bên thứ ba ứng dụng thông báo cho người dùng về các sự kiện đáng chú ý thông qua Notification và NotificationManager Các lớp API.
[3.8.3/H-0-2] PHẢI support Rich thông báo.
[3.8.3/H-0-3] PHẢI hỗ trợ head-up thông báo.
[3.8.3/H-0-4] PHẢI bao gồm ngăn thông báo, cung cấp cho người dùng khả năng kiểm soát trực tiếp (ví dụ: trả lời, tạm ẩn, loại bỏ, chặn) các thông báo thông qua tương tác với 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 do RemoteInput.Builder setChoices() cung cấp trong ngăn thông báo.
[3.8.3/H-SR-1] Are trì hoãn tay để hiện 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 phải tương tác thêm.
[3.8.3/H-SR-2] Are trì hoãn lựa chọn thực tế để hiện tất 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 ngăn thông báo.
[3.8.3.1/H-SR-1] AreĐể nhà phát triển sử dụng để hiển thị những hành động mà Notification.Action.Builder.setContextual được đặt thành true phù hợp với câu trả lời được hiển thị bởi Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] Are mã hoá NÊN DÙNG để triển khai một trợ lý trên thiết bị nhằm xử lý thao tác Trợ lý.

Nếu các phương thức triển khai Thiết bị cầm tay hỗ trợ thông báo MediaStyle chúng:

[3.8.3.1/H-SR-2] Are mã hoá PRO để cung cấp khả năng tương tác cho người dùng (ví dụ: trình chuyển đổi đầu ra) được truy cập từ giao diện người dùng hệ thống cho phép người dùng chuyển đổi giữa các nội dung nghe nhìn phù hợp có sẵn các tuyến đường (ví dụ: các thiết bị Bluetooth và tuyến đường được cung cấp cho MediaRouter2Manager) khi một ứng dụng đăng thông báo MediaStyle kèm theo mã thông báo MediaSession.

Nếu các phương thức triển khai thiết bị bao gồm phím điều hướng hàm gần đây dưới dạng chi tiết trong phần 7.2.3 về thay đổi giao diện, chúng:

[3.8.3/H-1-1] PHẢI triển khai màn hình và cung cấp cho người dùng trình đơn cài đặt để bật/tắt của chúng tôi.

Nếu các quá trình triển khai Thiết bị cầm tay hỗ trợ thao tác Hỗ trợ, thì các thiết bị đó:

[3.8.4/H-SR-2] Are Internet PRO sử dụng thao tác nhấn và giữ phím HOME làm tương tác được chỉ định để khởi chạy 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, nói cách khác là ứng dụng triển khai VoiceInteractionService! hoặc một hoạt động xử lý ý định ACTION_ASSIST.

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

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

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

[3.8.10/H-1-1] PHẢI hiển thị Khoá Thông báo trên màn hình, bao gồm cả Mẫu thông báo nội dung nghe nhìn.

Nếu các phương pháp triển khai Thiết bị cầm tay hỗ trợ màn hình khoá bảo mật, thì các phương thức triển khai đó:

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

Nếu phương thức triển khai Thiết bị cầm tay có bao gồm tính năng hỗ trợ cho ControlsProviderService và Control API và cho phép ứng dụng bên thứ ba phát hành chế độ kiểm soát thiết bị, sau đó chúng:

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

Ngược lại, nếu triển khai Thiết bị cầm tay không triển khai các điều khiển đó, chúng:

[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 tính năng này cờ android.software.controls và đặt thành false.

Nếu các phương thức 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, chúng sẽ:

[3.8.17/H-1-1] PHẢI đưa ra xác nhận cho người dùng rằng dữ liệu đã được sao chép vào 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 ở đây là dữ liệu bảng nhớ tạm có được đồng bộ hoá hay không trên nhiều thiết bị.

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

[3.10/H-0-1] PHẢI hỗ trợ tính năng hỗ trợ tiếp cận của bên thứ ba luôn miễn phí.
[3.10/H-SR-1] AreĐể các nhà phát triển sử dụng các tính năng tải trước, các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương hoặc vượt quá chức năng của tính năng Tiếp cận bằng công tắc và TalkBack (đối với các ngôn ngữ được cài đặt trước hỗ trợ công cụ hỗ trợ tiếp cận chuyển văn bản sang lời nói) như được cung cấp trong tính năng TalkBack đang mở dự án nguồn.
[3.11/H-0-1] PHẢI hỗ trợ cài đặt của công cụ TTS của bên thứ ba.
[3.11/H-SR-1] Are Internet ĐỀ XUẤT NÊN include a Công cụ TTS hỗ trợ các ngôn ngữ có sẵn trên thiết bị.
[3.13/H-SR-1] Are Internet ĐỀ XUẤT NÊN include a Thành phần giao diện người dùng trình đơn Cài đặt nhanh.

Nếu quá trình triển khai thiết bị cầm tay Android khai báo FEATURE_BLUETOOTH hoặc FEATURE_WIFI, họ:

[3.16/H-1-1] PHẢI hỗ trợ ghép nối thiết bị đồng hành của chúng tôi.

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:

[7.2.3/H] Vùng nhận dạng cử chỉ cho Màn hình chính hàm KHÔNG ĐƯỢC chiều cao cao hơn 32 dp tính từ cuối giá trị màn hình.

Nếu phương thức 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ừ bất kỳ vị trí nào ở cạnh trái và cạnh phải của màn hình:

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

Nếu các phương pháp triển khai Thiết bị cầm tay hỗ trợ màn hình khoá an toàn và có tối đa 2 GB bộ nhớ có sẵn cho kernel và không gian người dùng, họ:

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

Nếu các phương thức triển khai thiết bị cầm tay Android khai báo tính hỗ trợ cho máy ảnh qua android.hardware.camera.any họ:

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

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

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

Nếu quá trình triển khai thiết bị cho phép người dùng thực hiện cuộc gọi dưới bất kỳ hình thức nào, họ

[7.4.1.2/H-0-1] PHẢI khai báo cờ tính năng android.software.telecom.
[7.4.1.2/H-0-2] PHẢI triển khai 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ễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thêm thường xuyên hơn 5 khung hình trong một giây và PHẢI dưới 1 khung hình trong một giây.
[8.1/H-0-2] Độ trễ giao diện người dùng. Việc triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách gồm 10 nghìn mục trong danh sách do Bộ kiểm tra tính tương thích với Android xác định (CTS) trong vòng chưa đầy 36 giây.
[8.1/H-0-3] Chuyển đổi tác vụ. Thời gian nhiều ứng dụng đã được phát hành, khởi chạy lại một ứng dụng đã chạy ứng dụng sau khi chạy PHẢI mất chưa đến 1 giây.

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

[8.2/H-0-1] PHẢI đảm bảo tuần tự tốc độ ghi tối thiểu là 5 MB/giây.
[8.2/H-0-2] PHẢI đảm bảo 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 đọc tuần tự tối thiểu là 15 MB/giây.
[8.2/H-0-4] PHẢI đảm bảo đọc ngẫu nhiên tối thiểu là 3,5 MB/giây.

Liệu việc triển khai Thiết bị cầm tay có bao gồm các tính năng giúp cải thiện nguồn điện của thiết bị hay không khả năng quản lý được đưa vào AOSP hoặc mở rộng các tính năng được bao gồm trong AOSP, chúng:

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

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

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

Nếu quá trình triển khai Thiết bị cầm tay bao gồm một màn hình hoặc đầu ra video, thì các phương thức triển khai đó:

[8.4/H-1-1] PHẢI tôn trọng android.intent.action.POWER_USAGE_SUMMARY ý định và hiển thị trình đơn cài đặt cho thấy mức sử dụng pin này.

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

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

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

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

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Quá trình triển khai thiết bị PHẢI khai báo khả năng hỗ trợ cho android.software.credentials và:

[9/H-0-2] PHẢI thực hiện ý đị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 tính năng Tự động điền và cũng sẽ là vị trí mặc định để lưu thông tin xác thực 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 nhà cung cấp thông tin xác thực đồng thời và cung cấp khả năng tương tác cho người dùng trong ứng dụng Cài đặt để bật hoặc tắt nhà cung cấp.

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

Nếu các phương thức triển khai thiết bị khai báo hỗ trợ cho android.hardware.telephony, chúng:

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

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

[9.11/H-0-2] PHẢI sao lưu quá trình triển khai kho khoá với môi trường thực thi tách biệt.
[9.11/H-0-3] PHẢI có triển khai RSA, AES, Các thuật toán mật mã hoá ECDSA và HMAC và nhóm MD5, SHA-1 và SHA-2 các hàm băm để hỗ trợ đúng cách các thuật toán mã hóa trong khu vực được tách biệt an toàn với mã chạy trên nhân hệ điều hành trở lên. Cách ly an toàn PHẢI chặn mọi cơ chế tiềm ẩn theo đó nhân hệ điều hành hoặc mã không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Nguồn mở Android ngược dòng Dự án (AOSP) đáp ứng yêu cầu này bằng cách sử dụng phương thức triển khai Trusty, nhưng Giải pháp dựa trên ARM TrustZone hoặc một bên thứ ba đã được đánh giá là có bảo mật việc triển khai cách ly thích hợp dựa trên trình điều khiển ảo hoá là một phương án thay thế .
[9.11/H-0-4] PHẢI perform the khoá màn hình trong môi trường thực thi tách biệt và chỉ khi thành công, hãy cho phép sử dụng khoá giới hạn xác thực. Màn hình khoá thông tin xác thực PHẢI được lưu trữ theo cách chỉ cho phép thực thi riêng biệt để thực hiện xác thực màn hình khoá. Android ngược dòng Dự án nguồn mở cung cấp Lớp trừu tượng phần cứng (HAL) cho người trực điện thoại và Trusty. Các công cụ này có thể được dùng để đáp ứng yêu cầu này.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[9.11/H-0-5] PHẢI hỗ trợ chứng thực khoá trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và tính năng ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI ~~được dùng chung trên số lượng thiết bị đủ lớn để ngăn chặn khoá~~ bị ngăn chặn khỏi việc được sử dụng vĩnh viễn mã nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực trừ phi có ít nhất 100.000 đơn vị của một SKU cụ thể sản xuất. Nếu có hơn 100.000 đơn vị SKU được sản xuất, có thể dùng khoá cho mỗi 100.000 đơn vị.

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 đối với một SKU nhất định trừ phi được sản xuất ít nhất 100.000 đơn vị SKU đó. Nếu có hơn 100.000 đơn vị SKU đó được sản xuất, một khoá khác CÓ THỂ được sử dụng cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, có thể sử dụng giải pháp Cấp phép khoá từ xa để cung cấp khoá chứng thực ngắn hạn cho thiết bị.

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

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

Khi các phương pháp triển khai cho Thiết bị cầm tay hỗ trợ màn hình khoá bảo mật, chúng:

[9.11/H-1-1] PHẢI cho phép người dùng chọn đường liên kết ngắn nhất thời gian chờ ngủ, tức là thời gian chuyển đổi từ trạng thái mở khoá sang trạng thái khoá tối đa 15 giây.
[9.11/H-1-2] PHẢI cung cấp thuộc tính tương tác của người dùng để ẩn 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 Màn hình khoá an toàn. AOSP đáp ứng yêu cầu là chế độ khoá.

Nếu các hoạt động triển khai thiết bị có màn hình khoá bảo mật và có một hoặc nhiều tác nhân tin cậy có chức năng triển khai TrustAgentService System API, thì các tác nhân đó sẽ:

[9.11.1/H-1-1] PHẢI thử thách người dùng bằng một trong những phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) thường xuyên hơn 72 giờ một lần.

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

[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ý thêm người dùng và các chức năng khác của 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 để những người dùng khác làm việc, với khả năng quản lý các hạn chế chi tiết hơn trong các ứng dụng có sẵn trong các môi trường đó.

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

[9.5/H-3-1] KHÔNG ĐƯỢC hỗ trợ bị hạn chế cấu hình nhưng PHẢI phù hợp với cách triển khai các chế độ điều khiển AOSP để cho phép /vô hiệu hoá người dùng khác truy cập cuộc gọi thoại và SMS.

Nếu các phương thức triển khai Thiết bị cầm tay có đặt UserManager.isHeadlessSystemUserMode đến true, họ

[9.5/H-4-1] KHÔNG ĐƯỢC bao gồm tính năng hỗ trợ cho eUICC, cũng như eSIM có tính năng gọi điện.
[9.5/H-4-2] KHÔNG ĐƯỢC khai báo dịch vụ hỗ trợ cho android.hardware.telephony.

Android, thông qua API hệ thống, Voice mạoService hỗ trợ cơ chế phát hiện cụm từ kích hoạt luôn bật an toàn mà không cần chỉ báo truy cập micrô và tính năng phát hiện cụm từ tìm kiếm ở chế độ luôn bật mà không cần micrô hoặc camera chỉ báo quyền truy cập.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

Chế độ cài đặt hạn chế cho người dùng thấy các cảnh báo dễ thấy và xin người dùng xác nhận để cấp quyền cho mỗi ứng dụng, đáp ứng một trong hai điều kiện sau:

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

Đối với mọi Quyền đã thực thi và được liệt kê dưới đây:

Chuông báo và lời nhắc: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
Mọi quyền truy cập vào 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 xác định: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
Quản lý nội dung nghe nhìn: AppOpsManager.OPSTR_MANAGE_MEDIA
Sửa đổi 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
Hỗ trợ tiếp cận: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
Trình nghe 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

Các ứ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 hạn chế như đã nêu ở trên cho như sau:
- Quyền đặc biệt
  - Hỗ trợ tiếp cận (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Trình nghe thông báo (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - Ứng dụng dành cho quản trị viên 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 vào 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)
  - Tin nhắn SMS (RoleManager.ROLE_SMS)
- Quyền khi bắt đầu chạy
  - Thời gian chạy SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] PHẢI bật Chế độ cài đặt hạn chế làm mặc định và ĐỀ XUẤT KHÔNG NÊN có bất kỳ thuộc tính tương tác người dùng nào cho phép người dùng để tắt Chế độ cài đặt hạn chế cho tất cả ứng dụng.
[9.8/H-0-3] PHẢI đảm bảo thu được xác nhận của người dùng cho mỗi Ứng dụng được bảo vệ trước khi có thể cấp bất kỳ Quyền thực thi nào.
[9.8/H-0-4] PHẢI chỉ cho phép người dùng xác nhận bật chế độ cài đặt bị hạn chế lấy từ trang AppInfo của Ứng dụng được bao gồm, bằng cách sử dụng API EnhancedConfirmationManager.
[9.8/H-0-5] Are Để ĐỀ XUẤT NÊN tích hợp với và gọi Tăng cường xác nhận cho tất cả các quyền đặc biệt, để xác định một cách linh động xem đó 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
- Mọi quyền truy cập vào 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 xác định: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Quản lý nội dung nghe nhìn: AppOpsManager.OPSTR_MANAGE_MEDIA
- Sửa đổi 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
- Hỗ trợ tiếp cận: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Trình nghe 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

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

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

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

Liệu quá trình triển khai thiết bị có bao gồm một ứng dụng sử dụng API Hệ thống hay không HotwordDetectionService hoặc cơ chế tương tự để phát hiện cụm từ kích hoạt mà không cần chỉ báo sử dụng micrô, ứ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ề mỗi cụm từ từ nóng được hỗ trợ.
[9.8/H-2-2] KHÔNG ĐƯỢC bảo toàn dữ liệu âm thanh thô hoặc dữ liệu có nguồn gốc từ nó, thông qua dịch vụ phát hiện từ nóng.
[9.8/H-2-3] KHÔNG ĐƯỢC truyền từ dịch vụ phát hiện từ nóng, âm thanh dữ liệu, dữ liệu có thể dùng để xây dựng lại (toàn bộ hoặc một phần) âm thanh, hoặc nội dung âm thanh không liên quan đến chính cụm từ kích hoạt này, ngoại trừ cụm từ ContentCaptureService hoặc lời nói trên thiết bị dịch vụ nhận dạng cá nhân.

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

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

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

[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 dữ liệu âm thanh từ micrô, nhưng không truy cập khi chỉ HotwordDetectionService mới có quyền truy cập vào micrô, SOURCE_HOTWORD,ContentCaptureService hoặc các ứng dụng có vai trò được gọi trong phần 9.1 với giá trị nhận dạng CDD [C-4-X].
[9.8.2/H-4-2] PHẢI hiển thị danh sách gần đây và đang hoạt động ứng dụng sử dụng micrô khi được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với bất kỳ thuộc tính nào tin nhắn liên kết với các nguồn đó.
[9.8.2/H-4-3] KHÔNG ĐƯỢC ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.
[9.8.2/H-4-4] PHẢI hiển thị danh sách gần đây và đang hoạt động ứng dụng sử dụng micrô theo phản hồi từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi công liên quan.

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

[9.8.2/H-5-1] PHẢI hiển thị chỉ báo máy ảnh khi ứng dụng sẽ truy cập vào dữ liệu camera trực tiếp, nhưng không truy cập khi camera chỉ đang được được truy cập bởi(các) ứng dụng có vai trò được nêu trong mục 9.1 có giá trị nhận dạng CDD [C-4-X].
[9.8.2/H-5-2] PHẢI hiển thị các ứng dụng gần đây và đang hoạt động bằng cách sử dụng camera được trả lại từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi công liên quan.
[9.8.2/H-5-3] KHÔNG ĐƯỢC ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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 trên thiết bị. Nếu các quá trình triển khai theo thiết bị có hỗ trợ tính năng này, thì họ:

[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 quá trình 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.

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

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

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

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

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

2.2.7. Lớp học về hiệu suất nội dung nghe nhìn cầm tay

Xem Phần 7.11 để biết định nghĩa của lớp hiệu suất nội dung đa phương tiện.

2.2.7.1. Nội dung nghe nhìn

Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn nêu trong mục 2.2.7.1 của Android 14 CDD.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu hoạt động triển khai Thiết bị cầm tay xuất hiện trở lại android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

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

[5.1/H-1-1] PHẢI quảng cáo số lượng tối đa của bộ giải mã video phần cứng có thể chạy đồng thời trong bất kỳ kết hợp bộ mã hoá và giải mã nào thông qua CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints().

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-2] PHẢI hỗ trợ 6 trường hợp của bộ giải mã video phần cứng 8 bit (SDR) phiên (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào đang chạy đồng thời với 3 phiên ở độ phân giải 1080p ở tốc độ 30 khung hình/giây và 3 phiên ở độ phân giải 4K độ phân giải ở tốc độ 30 khung hình/giây, trừ phi AV1. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung giảm xuống mỗi giây. Bộ mã hoá và giải mã AV1 chỉ bắt buộc phải hỗ trợ độ phân giải 1080p, nhưng vẫn phải hỗ trợ 6 thực thể ở tốc độ 1080p30 khung hình/giây.

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

[5.1/H-1-3] PHẢI quảng cáo số lượng tối đa của bộ mã hoá video phần cứng có thể chạy đồng thời trong bất kỳ kết hợp bộ mã hoá và giải mã nào thông qua CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints().

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-4] PHẢI hỗ trợ 6 trường hợp của 8-bit (SDR) bộ mã hóa video phần cứng phiên (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào đang chạy đồng thời với 4 phiên ở độ phân giải 1080p ở tốc độ 30 khung hình/giây và 2 phiên ở độ phân giải 4K độ phân giải ở tốc độ 30 khung hình/giây, trừ phi AV1. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung giảm xuống mỗi giây. Bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p nhưng vẫn cần hỗ trợ 6 thực thể ở tốc độ 1080p30 khung hình/giây.

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

[5.1/H-1-5] PHẢI quảng cáo số lượng tối đa của bộ mã hoá video phần cứng và có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã nào thông qua CodecCapabilities.getMaxSupportedInstances() và VideoCapabilities.getSupportedPerformancePoints().

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-6] PHẢI hỗ trợ 6 trường hợp của 8-bit (SDR) bộ giải mã video phần cứng và phiên bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ kết hợp bộ mã hoá và giải mã chạy đồng thời với 3 phiên ở tốc độ 4K@30 khung hình/giây độ phân giải (trừ khi AV1), trong đó tối đa 2 là phiên bộ mã hoá và 3 ở độ phân giải 1080p. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung giảm xuống mỗi giây. Bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p nhưng vẫn cần hỗ trợ 6 thực thể ở tốc độ 1080p30 khung hình/giây.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-19] PHẢI hỗ trợ 3 phiên bản của bộ giải mã video phần cứng 10 bit (HDR) và phiên bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã chạy đồng thời ở độ phân giải 4K@30 khung hình/giây (trừ phi AV1) trong đó tối đa 1 là một phiên bộ mã hoá, có thể được định cấu hình trong Định dạng đầu vào RGBA_1010102 thông qua bề mặt GL. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung hình bị bỏ qua mỗi . Bộ mã hoá tạo siêu dữ liệu HDR không cần thiết nếu mã hoá từ nền tảng GL. Các phiên của bộ mã hoá và giải mã AV1 chỉ bắt buộc để hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này gọi cho chất lượng 4K.

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

[5.1/H-1-7] PHẢI có độ trễ khởi động bộ mã hoá và giải mã là 40 mili giây trở xuống cho Phiên mã hoá video 1080p trở xuống đối với tất cả các bộ mã hoá video phần cứng khi đang tải. Tải ở đây được định nghĩa là chỉ video từ 1080p đến 720p đồng thời phiên chuyển mã bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với độ phân giải quá trình khởi tạo bản ghi âm thanh và video. Đối với bộ mã hoá và giải mã Dolby Vision, Độ trễ khởi động PHẢI từ 50 mili giây trở xuống.
[5.1/H-1-8] PHẢI có độ trễ khởi động bộ mã hoá và giải mã là 30 mili giây trở xuống cho Phiên mã hoá âm thanh có tốc độ bit 128 kb/giây trở xuống cho tất cả bộ mã hoá âm thanh khi đang tải. Tải ở đây được định nghĩa là chỉ video từ 1080p đến 720p đồng thời phiên chuyển mã bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với độ phân giải quá trình khởi tạo bản ghi âm thanh và video.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-9] PHẢI hỗ trợ 2 trường hợp của bộ giải mã video phần cứng an toàn phiên (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào đang chạy đồng thời ở độ phân giải 4k@30 khung hình/giây (trừ khi AV1) cho cả 8 bit (SDR) và Nội dung HDR 10-bit. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung giảm xuống mỗi giây. Các phiên bộ mã hoá và giải mã AV1 chỉ được yêu cầu hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này yêu cầu chất lượng 4K.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-10] PHẢI hỗ trợ 3 trường hợp bộ giải mã video phần cứng không an toàn cùng với 1 phiên bản của bộ giải mã video phần cứng bảo mật (Tổng cộng 4 phiên bản) (AVC, HEVC, VP9, AV1 trở lên) trong mọi tổ hợp bộ mã hoá và giải mã chạy đồng thời với 3 phiên ở độ phân giải 4K@30 khung hình/giây (trừ khi AV1) trong đó bao gồm một phiên giải mã an toàn và 1 phiên bảo mật nn ở 1080p độ phân giải@30 khung hình/giây, trong đó tối đa 2 phiên có thể ở chế độ HDR 10 bit. Đối với tất cả các phiên, KHÔNG ĐƯỢC có nhiều hơn 1 khung giảm xuống mỗi giây. Các phiên bộ mã hoá và giải mã AV1 chỉ được yêu cầu hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này yêu cầu chất lượng 4K.

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

[5.1/H-1-11] PHẢI hỗ trợ bộ giải mã an toàn cho mọi phần cứng AVC, HEVC, Bộ giải mã VP9 hoặc AV1 trên thiết bị.
[5.1/H-1-12] PHẢI có độ trễ khởi động bộ mã hoá và giải mã là 40 mili giây trở xuống cho Phiên giải mã video 1080p trở xuống cho tất cả bộ giải mã video phần cứng khi đang tải. Tải ở đây được định nghĩa là độ phân giải đồng thời từ 1080p đến 720p phiên chuyển mã chỉ video bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với Khởi chạy tính năng phát âm thanh và video 1080p. Đối với bộ mã hoá và giải mã Dolby Vision, Độ trễ khởi động PHẢI từ 50 mili giây trở xuống.
[5.1/H-1-13] PHẢI có độ trễ khởi động bộ mã hoá và giải mã là 30 mili giây trở xuống cho Phiên giải mã âm thanh có tốc độ bit 128 kb/giây trở xuống cho tất cả bộ giải mã âm thanh khi đang tải. Tải ở đây được định nghĩa là chỉ video từ 1080p đến 720p đồng thời phiên chuyển mã bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với độ phân giải quá trình khởi chạy phát âm thanh và video.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-14] PHẢI hỗ trợ bộ giải mã phần cứng AV1 Chính 10, Cấp 4.1 ~~và hiệu ứng hạt mỏng~~ với hiệu ứng hạt mỏng trên thành phần GPU.

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

[5.1/H-1-15] PHẢI có ít nhất 1 bộ giải mã video phần cứng hỗ trợ 4K60.
[5.1/H-1-16] PHẢI có ít nhất 1 bộ mã hoá video phần cứng hỗ trợ 4K60.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-21] PHẢI hỗ trợ FEATURE_DynamicColorAspect cho tất cả video phần cứng bộ giải mã (AVC, HEVC, VP9, AV1 trở lên). Lưu ý: Điều này có nghĩa là các ứng dụng có thể cập nhật các khía cạnh màu sắc của nội dung video trong phiên giải mã. Bộ giải mã hỗ trợ nội dung 10 bit và 8 bit PHẢI hỗ trợ động chuyển đổi giữa nội dung 8 và 10 bit ở chế độ Surface. Bộ giải mã hỗ trợ Chức năng chuyển HDR PHẢI hỗ trợ chuyển đổi linh động giữa SDR và HDR nội dung.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-22] PHẢI hỗ trợ mã hoá, giải mã, chỉnh sửa GPU và hiển thị video nội dung ở tỷ lệ khung hình dọc bất kể siêu dữ liệu xoay cho độ phân giải lớn nhất được hỗ trợ trên Máy ảnh hoặc 4K, tuỳ theo mức nào nhỏ hơn. Lưu ý: điều này bao gồm cả cấu hình HDR nếu bộ mã hoá và giải mã hỗ trợ HDR. Bộ mã hoá và giải mã AV1 chỉ được yêu cầu hỗ trợ độ phân giải 1080p. Yêu cầu này chỉ áp dụng cho bộ mã hoá và giải mã phần cứng, GPU và DPU.

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

[5.3/H-1-1] KHÔNG ĐƯỢC thả nhiều hơn 1 khung hình trong 10 giây (tức là ít hơn giảm 0,167% khung hình) cho phiên video 4K 60 khung hình/giây khi tải.
[5.3/H-1-2] KHÔNG ĐƯỢC thả nhiều hơn 1 khung hình trong 10 giây trong một video thay đổi độ phân giải trong phiên video 60 khung hình/giây khi tải trong phiên 4K.
[5.6/H-1-1] PHẢI có độ trễ nhấn-to-tone là 80 mili giây trở xuống sử dụng thử nghiệm nhấn theo tông màu của Trình xác minh CTS.
[5.6/H-1-2] PHẢI có độ trễ âm thanh trọn vòng là 80 mili giây hoặc trên ít nhất một đường dẫn dữ liệu được hỗ trợ.
[5.6/H-1-3] PHẢI hỗ trợ >= âm thanh 24 bit cho đầu ra âm thanh nổi qua âm thanh 3,5 mm nếu có và qua âm thanh USB nếu được hỗ trợ thông qua toàn bộ dữ liệu cho các cấu hình phát trực tuyến và độ trễ thấp. Dành cho độ trễ thấp , nên ứng dụng sử dụng AAudio trong lệnh gọi lại có độ trễ thấp . Đối với cấu hình truyền trực tuyến, Java AudioTrack nên được sử dụng bởi ứng dụng. Trong cả cấu hình phát trực tuyến và độ trễ thấp, HAL bồn lưu trữ dữ liệu đầu ra phải chấp nhận AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT hoặc AUDIO_FORMAT_PCM_FLOAT cho định dạng đầu ra mục tiêu.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.6/H-1-4] PHẢI hỗ trợ >= 4 kênh thiết bị âm thanh USB. ~~(Các tay điều khiển DJ sử dụng tính năng này để xem trước bài hát.)~~

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

[5.6/H-1-5] PHẢI hỗ trợ các thiết bị MIDI tương thích với lớp và khai báo Cờ tính năng MIDI.
[5.6/H-1-9] PHẢI hỗ trợ ít nhất 12 kênh trộn. Điều này ngụ ý rằng khả năng mở AudioTrack với mặt nạ kênh 7.1.4 và chuyển đổi không gian hoặc kết hợp tất cả các kênh thành âm thanh nổi.
[5.6/H-SR] AreRENDERED ĐỀ XUẤT để hỗ trợ trộn kênh 24 với ít nhất là hỗ trợ mặt nạ kênh 9.1.6 và 22.2.
[5.7/H-1-2] PHẢI hỗ trợ MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL bằng dưới đây về khả năng giải mã nội dung.

Kích thước mẫu tối thiểu	4 MiB
Số lượng mẫu phụ tối thiểu – H264 hoặc HEVC	32
Số lượng mẫu con tối thiểu – VP9	9
Số lượng mẫu con tối thiểu – AV1	288
Dung lượng bộ nhớ đệm mẫu phụ tối thiểu	1 MiB
Dung lượng vùng đệm mã hoá chung tối thiểu	500 KiB
Số phiên đồng thời tối thiểu	30
Số lượng khoá tối thiểu mỗi phiên	20
Tổng số khoá tối thiểu (tất cả các phiên)	80
Tổng số khoá DRM tối thiểu (tất cả phiên)	6
Kích thước thư	16 KiB
Khung hình được giải mã mỗi giây	60 khung hình/giây

[5.1/H-1-17] PHẢI có ít nhất 1 bộ giải mã hình ảnh phần cứng hỗ trợ AVIF Hồ sơ cơ sở.
[5.1/H-1-18] PHẢI hỗ trợ bộ mã hoá AV1 có thể mã hoá lên đến 480p với độ phân giải 30 khung hình/giây và 1 Mb/giây.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[5.1/H-1-20] PHẢI hỗ trợ Feature_HdrEditing cho tất cả các bộ mã hoá phần cứng AV1 và HEVC có trên thiết bị ở độ phân giải 4K hoặc độ phân giải lớn nhất mà Máy ảnh hỗ trợ, tuỳ theo mức nào nhỏ hơn.

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

[5.12/H-SR] Rất khuyến khích dùng để hỗ trợ Feature_HdrEditing cho tất cả các bộ mã hoá phần cứng AV1 và HEVC có trên thiết bị.
[5.12/H-1-2] PHẢI hỗ trợ định dạng màu RGBA_1010102 cho tất cả phần cứng AV1 và Bộ mã hoá HEVC có trên thiết bị.
[5.12/H-1-3] PHẢI quảng cáo hỗ trợ cho phần mở rộng EXT_YUV_target cho mẫu từ kết cấu YUV ở cả 8 và 10 bit.
[7.1.4/H-1-1] PHẢI có ít nhất 6 lớp phủ phần cứng trong quá trình xử lý hiển thị (DPU), với ít nhất 2 trong số đó có khả năng hiển thị nội dung video 10 bit.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu hoạt động triển khai Thiết bị cầm tay xuất hiện trở lại android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS và bao gồm hỗ trợ bộ mã hoá AVC hoặc HEVC phần cứng, họ:

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

[5.2/H-2-1] PHẢI đáp ứng mục tiêu chất lượng tối thiểu do video xác định Đường cong độ méo tốc độ bộ mã hoá đối với bộ mã hoá và giải mã AVC và HEVC phần cứng, như được xác định trong Chạy kiểm tra hiệu suất Lớp 14 (PC14) – Chất lượng mã hoá video (VEQ).

2.2.7.2. Camera

Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn nêu trong mục 2.2.7.2 của Android 14 CDD.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu hoạt động triển khai Thiết bị cầm tay xuất hiện trở lại android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.5/H-1-1] PHẢI có camera mặt sau chính kèm theo độ phân giải ít nhất 12 megapixel hỗ trợ quay video ở 4k ở tốc độ 30 khung hình/giây, 1080p ở tốc độ 60 khung hình/giây và 720p ở tốc độ 60 khung hình/giây. Camera chính ở mặt sau là máy ảnh mặt sau có mã nhận dạng máy ảnh thấp nhất.

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

[7.5/H-1-2] PHẢI có camera mặt trước chính với độ phân giải là @ Độ phân giải tối thiểu là 6 megapixel và hỗ trợ quay video 1080p ở tốc độ 30 khung hình/giây. Chính máy ảnh mặt trước là máy ảnh mặt trước có mã nhận dạng máy ảnh thấp nhất.
[7.5/H-1-3] PHẢI hỗ trợ thuộc tính android.info.supportedHardwareLevel dưới dạng FULL hoặc cao hơn cho khu vực chính phía sau và LIMITED trở lên cho khu vực chính phía trước máy ảnh.
[7.5/H-1-4] PHẢI hỗ trợ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME cho cả hai chương trình chính camera.
[7.5/H-1-5] PHẢI have camera2 JPEG Capture latency < 1.000 mili giây đối với độ phân giải 1080p được đo bằng máy ảnh CTS PerformanceTest theo Điều kiện ánh sáng ITS (3000K) cho cả hai máy ảnh chính.
[7.5/H-1-6] PHẢI có độ trễ khởi động camera2 (mở máy ảnh để xem trước đầu tiên) khung) < 500 mili giây theo đo bằng máy ảnh CTS PerformanceTest theo ITS điều kiện ánh sáng (3000K) cho cả hai máy ảnh chính.
[7.5/H-1-8] PHẢI hỗ trợ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW và android.graphics.ImageFormat.RAW_SENSOR cho camera chính sau.
[7.5/H-1-9] PHẢI có camera chính phía sau hỗ trợ 720p hoặc 1080p @ 240 khung hình/giây.
[7.5/H-1-10] PHẢI có tối thiểu ZOOM_RATIO < 1.0 cho các camera chính nếu có là máy ảnh RGB siêu rộng hướng về cùng một hướng.
[7.5/H-1-11] PHẢI triển khai chế độ phát trực tiếp mặt trước đồng thời trên chế độ chính camera.
[7.5/H-1-12] PHẢI hỗ trợ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION cho cả hai chương trình chính camera trước và sau chính.
[7.5/H-1-13] PHẢI hỗ trợ chức năng LOGICAL_MULTI_CAMERA cho camera chính mặt sau nếu có nhiều hơn 1 mặt sau RGB camera.
[7.5/H-1-14] PHẢI hỗ trợ chức năng STREAM_USE_CASE cho cả hai chế độ chính camera trước và sau chính.
[7.5/H-1-15] PHẢI hỗ trợ Các tiện ích chế độ ban đêm thông qua cả tiện ích CameraX và Camera2 cho chính camera.
[7.5/H-1-16] PHẢI hỗ trợ chức năng dynamic_RANGE_TEN_BIT cho chế độ chính camera.
[7.5/H-1-17] PHẢI hỗ trợ CONTROL_SCENE_MODE_FACE_PRIORITY và tính năng phát hiện khuôn mặt (StatISTICS_FACE_ Thiếu_MODE_SIMPLE hoặc StatISTICS_FACE_ chiếu_MODE_FULL) cho camera chính.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.5/H-1-18] PHẢI hỗ trợ JPEG_R cho phía sau chính và camera trước chính.
[7.5/H-1-19] hỗ trợ PHẢI CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION cho HLG10 1080p bản xem trước với định dạng JPEG tỷ lệ khung hình tối đa 16:9 và bản xem trước HLG10 720p với kích thước tối đa 16:9 kết hợp luồng JPEG cho camera sau.
[7.5/H-1-20] PHẢI theo đầu ra mặc định JPEG_R cho đầu ra chính máy ảnh trước chính và sau trong ứng dụng máy ảnh gốc.

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

2.2.7.3. Phần cứng

Nếu các hoạt động triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn nêu trong mục 2.2.7.3 của Android 14 CDD.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu hoạt động triển khai Thiết bị cầm tay xuất hiện trở lại android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

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

[7.1.1.1/H-2-1] PHẢI có độ phân giải màn hình tối thiểu là 1080p.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.1.1.3/H-2-1] PHẢI có mật độ màn hình tối thiểu 400 dpi nếu chiều rộng màn hình của thiết bị là < 600 dp.

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

[7.1.1.3/H-3-1] PHẢI có màn hình HDR hỗ trợ ít nhất 1000 nits trung bình.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.6.1/H-2-1] PHẢI có bộ nhớ thực tối thiểu là 8 GB, có ít nhất 6,64 GB còn trống cho nhân theo báo cáo của android.app.ActivityManager.MemoryInfo.totalMem.

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

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ề android.os.Build.VERSION_CODES.U cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu hoạt động triển khai Thiết bị cầm tay xuất hiện trở lại android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

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

[8.2/H-1-1] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 150 MB/giây.
[8.2/H-1-2] PHẢI đảm bảo tốc độ ghi ngẫu nhiên tối thiểu là 10 MB/giây.
[8.2/H-1-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 250 MB/giây.
[8.2/H-1-4] PHẢI đảm bảo tốc độ đọc ngẫu nhiên tối thiểu là 100 MB/giây.
[8.2/H-1-5] PHẢI đảm bảo hiệu suất đọc và ghi tuần tự song song với hiệu suất đọc gấp 2 lần và ghi gấp 1 lần với tốc độ tối thiểu là 50 MB/s.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

2.2.7.5. Đồ hoạ

Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.V cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

[7.1.4.1/H-1-1]
Yêu cầu này bị rút lại khỏi Android 15 (thử nghiệm AOSP).
[7.1.4.1/H-1-2] PHẢI hỗ trợ EGL_IMG_context_priority và EGL_EXT_protected_content tiện ích.
[7.1.4.1/H-1-3] PHẢI hỗ trợ VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory và VK_KHR_global_priority.

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

2.3. Yêu cầu về truyền hình

Thiết bị TV Android đề cập đến việc triển khai thiết bị Android là giao diện giải trí để xem nội dung nghe nhìn kỹ thuật số, phim ảnh, trò chơi, ứng dụng, và/hoặc truyền hình trực tuyến đối với người dùng ngồi cách khoảng 10 feet ("tựa lưng" hoặc "10 feet" giao diện người dùng").

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

Đã cung cấp một cơ chế để kiểm soát 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 nhúng có chiều dài đường chéo lớn hơn 24 inch HOẶC bao gồm một cổng đầu ra video, chẳng hạn như VGA, HDMI, DisplayPort hoặc cổng không dây để hiển thị.

Những yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho Android Triển khai thiết bị truyền hình.

2.3.1. Phần cứng

Triển khai thiết bị TV:

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

Nếu hoạt động triển khai Thiết bị truyền hình bao gồm con quay hồi chuyển 3 trục, thì chúng:

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

Triển khai thiết bị TV:

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

Nếu quá trình triển khai thiết bị TV bao gồm một cổng USB hỗ trợ chế độ máy chủ, chúng:

[7.5.3/T-1-1] PHẢI bao gồm tính năng hỗ trợ cho máy ảnh 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 quá trình triển khai thiết bị TV là 32 bit:

[7.6.1/T-1-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 sử dụng bất kỳ mật độ nào sau đây:
- 400dpi trở lên đối với màn hình nhỏ/bình thường
- xhdpi trở lên trên màn hình lớn
- tvdpi trở lên trên màn hình cực lớn

Nếu quá trình 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ối thiểu là 1280MB nếu có bất kỳ mật độ nào sau đây đã sử dụng:
- 400dpi trở lên đối với màn hình nhỏ/bình thường
- xhdpi trở lên trên màn hình lớn
- tvdpi trở lên trên màn hình cực lớn

Lưu ý rằng "bộ nhớ còn trống cho nhân và không gian người dùng" ở trên đề cập đến dung lượng bộ nhớ được cung cấp bên cạnh mọi bộ nhớ đã có dành riêng cho các thành phần phần cứng như radio, video, v.v. không được dưới sự kiểm soát của nhân hệ điều hành trên các triển khai thiết bị.

Triển khai thiết bị TV:

[7.8.1/T] PHẢI bao gồm 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

Các quá trình triển khai thiết bị TV PHẢI hỗ trợ phương thức mã hoá âm thanh sau đây và giải mã các định dạng này cũng như cung cấp chúng cho các ứng dụng của bên thứ ba:

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

Các quá trình triển khai thiết bị TV PHẢI hỗ trợ phương thức mã hoá video sau và cung cấp chúng cho các ứng dụng của 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ị TV:

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

Các quá trình triển khai thiết bị TV PHẢI hỗ trợ giải mã video sau đây và cung cấp chúng cho các ứng dụng của 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 quá trình triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã MPEG-2, như được nêu chi tiết trong Mục 5.3.1, ở tốc độ khung hình và độ phân giải video tiêu chuẩn lên đến bao gồm:

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

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

[5.3.4/T-1-1] HD 1080p ở 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 Hồ sơ cao cấp 4.2

Triển khai thiết bị truyền hình bằng bộ giải mã phần cứng H.265 PHẢI hỗ trợ Giải mã H.265, như đã 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 Hồ sơ chính cấp 4.1

Nếu phương thức triển khai Thiết bị TV có hỗ trợ bộ giải mã phần cứng H.265 Giải mã H.265 và hồ sơ giải mã UHD, chúng:

[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 Main10 Cấp 5

Các quá trình triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã VP8, như được nêu chi tiết trong Mục 5.3.6, ở tốc độ khung hình và độ phân giải video tiêu chuẩn lên đến 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

Triển khai thiết bị truyền hình bằng bộ giải mã phần cứng VP9 PHẢI hỗ trợ 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 cấu hình 0 (độ sâu màu 8 bit)

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

[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] Arefaq NÊN support the 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ị TV:

[5.5/T-0-1] PHẢI include support for system Master Mức suy giảm âm lượng đầu ra âm thanh kỹ thuật số và âm lượng trên các đầu ra được hỗ trợ, ngoại trừ đầu ra truyền qua âm thanh nén (khi không giải mã âm thanh nào được thực hiện) trên thiết bị).

Nếu phương thức triển khai thiết bị TV không có màn hình tích hợp, nhưng thay vào đó hỗ trợ màn hình ngoài được kết nối qua HDMI, thiết bị 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 tương thích với 50Hz hoặc 60Hz tốc độ làm mới cho màn hình bên ngoài, tuỳ thuộc vào tốc độ làm mới video cho khu vực bán thiết bị.
[5.8/T-SR-1] Are trì hoãn 1 để cung cấp cho người dùng bộ chọn tốc độ làm mới HDMI có thể định cấu hình.
[5.8] NÊN đặt tốc độ làm mới chế độ đầu ra HDMI 50Hz hoặc 60Hz, tuỳ thuộc vào tốc độ làm mới video cho khu vực mà bán thiết bị.

Nếu phương thức triển khai thiết bị TV không có màn hình tích hợp, nhưng thay vào đó hỗ trợ màn hình ngoài được kết nối qua HDMI, thiết bị này:

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

Nếu quá trình triển khai Thiết bị TV không hỗ trợ giải mã UHD, nhưng hỗ trợ màn hình ngoài được kết nối qua HDMI, các thiết bị 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ị TV:

[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 trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ hơn có trình xử lý ý định, cho tất cả mẫu bộ lọc ý định công khai được xác định theo các ý định của ứng dụng sau đây được liệt kê tại đây.
[3.4.1/T-0-1] PHẢI cung cấp đầy đủ triển khai API android.webkit.Webview.

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

[3.8.10/T-1-1] PHẢI hiển thị Khoá Thông báo trên màn hình, bao gồm cả Mẫu thông báo nội dung nghe nhìn.

Triển khai thiết bị TV:

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

Nếu quá trình triển khai thiết bị TV báo cáo tính năng đó android.hardware.audio.output, họ:

[3.11/T-SR-1] Are trìy REVIEW to include a Công cụ TTS hỗ trợ các ngôn ngữ có sẵn trên thiết bị.
[3.11/T-1-1] PHẢI hỗ trợ cài đặt của công cụ TTS của bên thứ ba.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Triển khai thiết bị TV:

[3.12/T-0-1] PHẢI hỗ trợ TV Input Framework.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Khung đầu vào cho TV Android (TIF) giúp đơn giản hoá phân phối nội dung trực tiếp đến các thiết bị Android TV. TIF cung cấp tiêu chuẩn API để tạo các mô-đun đầu vào điều khiển thiết bị Android TV.

Triển khai thiết bị TV:

[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 để một ứng dụng sử dụng các API này và thông tin đầu vào dựa trên TIF của bên thứ ba dịch vụ có thể được cài đặt và sử dụng trên thiết bị.

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

Nếu quá trình triển khai thiết bị có hỗ trợ Tuner, thì các ứng dụng đó:

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

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

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ễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thêm thường xuyên hơn 5 khung hình trong một giây và PHẢI dưới 1 khung hình trong một giây.
[8.2/T-0-1] PHẢI đảm bảo tuần tự tốc độ ghi tối thiểu là 5 MB/giây.
[8.2/T-0-2] PHẢI đảm bảo 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 tuần tự tốc độ đọc tối thiểu là 15 MB/giây.
[8.2/T-0-4] PHẢI đảm bảo đọc ngẫu nhiên tối thiểu 3,5 MB/giây.

Liệu việc triển khai thiết bị TV có bao gồm các tính năng để cải thiện nguồn điện của thiết bị hay không khả năng quản lý được đưa vào AOSP hoặc mở rộng các tính năng được bao gồm trong AOSP, chúng:

[8.3/T-1-1] PHẢI cung cấp thuộc tính tương tác của người dùng để bật và tắt tính năng trình tiết kiệm pin.

Nếu quá trình triển khai thiết bị TV không có pin, thì thiết bị đó sẽ:

[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 quá trình triển khai thiết bị TV có pin, thì thiết bị đó:

[8.3/T-1-3] PHẢI cung cấp thuộc tính tương tác của người dùng để hiển thị tất cả các ứng dụng được miễn các chế độ tiết kiệm pin ở Chế độ chờ ứng dụng và Nghỉ.

Triển khai thiết bị TV:

[8.4/T-0-1] PHẢI cung cấp hồ sơ công suất trên mỗi thành phần, trong đó 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 ước lượng do theo thời gian như được ghi trong trang web Dự án nguồn mở Android.
[8.4/T-0-2] PHẢI báo cáo tất cả nguồn điện giá trị tiêu thụ tính bằng miliampe giờ (mAh).
[8.4/T-0-3] PHẢI báo cáo nguồn điện của CPU mức tiêu thụ trên mỗi UID của quy trình. Dự án nguồn mở Android đáp ứng thông qua việc triển khai mô-đun nhân uid_cputime.
[8.4/T] PHẢI được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng nguồn điện của thành phần phần cứng đối với một ứng dụng.
[8.4/T-0-4] PHẢI thực hiện việc sử dụng điện này được cung cấp qua adb shell dumpsys batterystats shell 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ị TV:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[9.11/T-0-4] PHẢI hỗ trợ chứng thực khoá trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và tính năng ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI ~~được dùng chung trên số lượng thiết bị đủ lớn để ngăn chặn khoá~~ bị ngăn chặn khỏi việc được sử dụng vĩnh viễn mã nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực trừ phi có ít nhất 100.000 đơn vị của một SKU cụ thể sản xuất. Nếu có hơn 100.000 đơn vị SKU được sản xuất, có thể dùng khoá cho mỗi 100.000 đơn vị.

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 đối với một SKU nhất định trừ phi được sản xuất ít nhất 100.000 đơn vị SKU đó. Nếu có hơn 100.000 đơn vị SKU đó được sản xuất, một khoá khác CÓ THỂ được sử dụng cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, có thể sử dụng giải pháp Cấp phép khoá từ xa để cung cấp khoá chứng thực ngắn hạn cho thiết bị.

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

Nếu các phương pháp triển khai Thiết bị TV hỗ trợ màn hình khoá an toàn, thì các phương pháp triển khai đó:

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

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

[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ý thêm người dùng và các chức năng khác của 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 để những người dùng khác làm việc, với khả năng quản lý các hạn chế chi tiết hơn trong các ứng dụng có sẵn trong các môi trường đó.

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

[9.5/T-3-1] KHÔNG ĐƯỢC hỗ trợ bị hạn chế cấu hình nhưng PHẢI phù hợp với cách triển khai các chế độ điều khiển AOSP để cho phép /vô hiệu hoá người dùng khác truy cập cuộc gọi thoại và SMS.

Nếu quá trình triển khai Thiết bị truyền hình khai báo android.hardware.microphone, thì chúng:

[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 dữ liệu âm thanh từ micrô, nhưng không truy cập khi chỉ truy cập được vào micrô bằng HotwordDetectionService, NGUỒN_AdSize, ContentCaptureService hoặc các ứng dụng có vai trò được nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD C-3-X.
[9.8.2/T-4-2] KHÔNG ĐƯỢC ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.

Nếu quá trình triển khai Thiết bị truyền hình khai báo android.hardware.camera.any, thì chúng:

[9.8.2/T-5-1] PHẢI hiển thị chỉ báo camera khi ứng dụng sẽ truy cập vào dữ liệu camera trực tiếp, nhưng không truy cập khi camera chỉ đang được truy cập bởi(các) ứng dụng có vai trò nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD [C-3-X].
[9.8.2/T-5-2] KHÔNG ĐƯỢC ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.

2.3.6. Khả năng tương thích với công cụ và tuỳ chọn cho nhà phát triển

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Triển khai thiết bị TV:

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

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

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

Thiết bị đồng hồ Android là một cách triển khai thiết bị Android nhằm được đeo trên cơ thể, có thể là trên cổ tay.

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

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

Những yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho Android Triển khai thiết bị đồng hồ.

2.4.1. Phần cứng

Triển khai thiết bị đồng hồ:

[7.1.1.1/W-0-1] PHẢI có một màn hình chứa kích thước đường chéo vật lý từ 1,1 đến 2,5 inch.
[7.2.3/W-0-1] PHẢI have the Home function available (Có sẵn hàm Home) cho người dùng và hàm Quay lại ngoại trừ khi hàm này đang ở UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] PHẢI hỗ trợ đầu vào màn hình cảm ứng.
[7.3.1/W-SR-1] Are trìy REVIEW to include a 3-axis gia tốc kế.

Nếu quá trình triển khai Thiết bị đồng hồ có hỗ trợ Vulkan, thì các quá trình triển khai đó:

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

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

[7.3.3/W-1-1] PHẢI báo cáo số liệu đo lường GNSS, ngay khi chúng ngay cả khi vị trí tính bằng GPS/GNSS chưa được báo cáo.
[7.3.3/W-1-2] PHẢI báo cáo GNSS pseudoranges và pseudorange giá, trong điều kiện trời mở sau khi xác định vị trí, trong khi đứng yên hoặc đang di chuyển với tốc độ dưới 0,2 m/giây vuông gia tốc, đủ để tính vị trí trong phạm vi 20 mét và vận tốc với tốc độ tối thiểu 0,2 m/giây, tối thiểu 95% thời gian.

Nếu quá trình triển khai Thiết bị đồng hồ bao gồm con quay hồi chuyển 3 trục, thì chúng:

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

Triển khai thiết bị đồng hồ:

[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ớ bất biến 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ó bộ nhớ ít nhất 416 MB có sẵn cho kernel và không gian người dùng.
[7.8.1/W-0-1] PHẢI bao gồm 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ị đồng hồ:

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

Triển khai thiết bị đồng hồ:

[3.8.4/W-SR-1] Are Internet REVIEW để triển khai một trợ lý trên thiết bị nhằm xử lý thao tác Trợ lý.

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

[3.10/W-1-1] PHẢI hỗ trợ tính năng hỗ trợ tiếp cận của bên thứ ba luôn miễn phí.
[3.10/W-SR-1] AreĐể các nhà phát triển sử dụng các tính năng tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương hoặc vượt quá chức năng của tính năng Tiếp cận bằng công tắc và TalkBack (đối với các ngôn ngữ được cài đặt trước hỗ trợ công cụ hỗ trợ tiếp cận chuyển văn bản sang lời nói) như được cung cấp trong dự án nguồn mở TalkBack.

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

[3.11/W-SR-1] Are Internet Sử dụng các giải pháp khác để bao gồm Công cụ TTS hỗ trợ các ngôn ngữ có sẵn trên thiết bị.
[3.11/W-0-1] PHẢI hỗ trợ cài đặt của công cụ TTS của bên thứ ba.

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

Liệu việc triển khai thiết bị Đồng hồ có bao gồm các tính năng giúp cải thiện nguồn điện của thiết bị hay không khả năng quản lý được đưa vào AOSP hoặc mở rộng các tính năng được bao gồm trong AOSP, chúng:

[8.3/W-SR-1] AreĐể nhà phát triển đề xuất nội dung cho bạn khả năng tương tác của người dùng để hiển thị tất cả các ứng dụng được miễn trừ khỏi Chế độ chờ ứng dụng và Nghỉ chế độ tiết kiệm điện.
[8.3/W-SR-2] AreĐể các nhà phát triển sử dụng được tương tác với người dùng để bật và tắt tính năng trình tiết kiệm pin.

Triển khai thiết bị đồng hồ:

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

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

Triển khai thiết bị đồng hồ:

[9/W-0-1] PHẢI khai báo android.hardware.security.model.compatible của chúng tôi.

Nếu quá trình triển khai thiết bị Đồng hồ bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, chúng:

[9.5/W-1-1] PHẢI hỗ trợ cấu hình bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý thêm người dùng và các chức năng khác của 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 để những người dùng khác làm việc, với khả năng quản lý các hạn chế chi tiết hơn trong các ứng dụng có sẵn trong các môi trường đó.

Nếu quá trình triển khai thiết bị Đồng hồ bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, chúng:

[9.5/W-2-1] KHÔNG ĐƯỢC hỗ trợ bị hạn chế cấu hình nhưng PHẢI phù hợp với cách triển khai các chế độ điều khiển AOSP để cho phép /vô hiệu hoá người dùng khác truy cập cuộc gọi thoại và SMS.

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

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

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

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

Được nhúng như một phần hoặc có thể cắm vào ô tô.
Đang dùng một màn hình ở hàng ghế của người lái làm màn hình chính.

Những yêu cầu bổ sung trong phần còn lại của phần này dành riêng cho Android Triển khai thiết bị Automotive.

2.5.1. Phần cứng

Triển khai thiết bị Automotive:

[7.1.1.1/A-0-1] PHẢI có màn hình ít nhất là 6 inch theo kích thước đường chéo vật lý.
[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 750 dp x 480 dp.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.1.1.1/A-1-1] PHẢI có màn hình riêng của kích thước đường chéo ít nhất là 6 inch cho mỗi khu vực cư dân trong màn hình chính. Thông tin này phải được gắn thẻ là CarOccupantZoneManager.DISPLAY_TYPE_MAIN cho từng khu vực cư trú.
[7.1.1.1/A-1-2] PHẢI có bố cục kích thước màn hình tối thiểu 750 dp x 480 dp cho mỗi màn hình chính.

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

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

[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 quá trình triển khai thiết bị Automotive có hỗ trợ Vulkan, thì quá trình triển khai thiết bị Automotive sẽ:

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

Triển khai thiết bị Automotive:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.1.7/A-0-1] PHẢI cấu hình màn hình phụ trong tầm nhìn của người lái xe FLAG_PRIVATE.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.2.3/A-0-1] PHẢI cung cấp ~~Trang chủ~~ và các hàm Quay lại, và CÓ THỂ cung cấp ~~Quay lại và~~ Hàm gần đây.

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

[7.2.3/A-0-2] PHẢI gửi cả chế độ thông thường và nhấn và giữ sự kiện của hàm Quay lại (KEYCODE_BACK) cho ứ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 NIGHT_MODE cờ PHẢI nhất quán với chế độ ngày/đêm của trang tổng quan và PHẢI dựa vào đầu vào cảm biến ánh sáng xung quanh. Cảm biến ánh sáng xung quanh bên dưới CÓ THỂ giống nhau dưới dạng Photometer.
[7.3/A-0-3] PHẢI cung cấp trường thông tin bổ sung của cảm biến TYPE_SENSOR_PLACEMENT như một phần của SensorAdditionalInfo cho mọi cảm biến được cung cấp.
[7.3/A-SR1] CÓ THỂ đã thoát Vị trí bằng cách kết hợp GPS/GNSS với các cảm biến bổ sung. Nếu Vị trí đã được cho là không còn tồn tại, bạn đề nghị triển khai và báo cáo lỗi đó Cảm biến tương ứng loại và/hoặc Mã tài sản của xe đã sử dụng.
[7.3/A-0-4] Vị trí được yêu cầu qua LocationManager#requestLocationUpdates() KHÔNG ĐƯỢC phù hợp với bản đồ.
[7.3.1/A-0-4] PHẢI tuân thủ chính sách của Android hệ thống toạ độ cảm biến ô tô.
[7.3/A-SR-1] Are liền_REVIEW to include a 3-axis gia tốc kế và con quay hồi chuyển 3 trục.
[7.3/A-SR-2] AreĐể tôi bật quảng cáo cho bản thân mình, Cảm biến TYPE_HEADING.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

Nếu quá trình triển khai thiết bị Automotive có bao gồm gia tốc kế, thì các ứng dụng đó sẽ:

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

Nếu quá trình triển khai thiết bị bao gồm gia tốc kế 3 trục, thì các phương thức triển khai đó:

[7.3.1/A-SR-1] Are trì hoãn 2 danh sách gốc để triển khai cảm biến phức hợp cho gia tốc kế trục giới hạn.

Nếu quá trình triển khai thiết bị Automotive bao gồm gia tốc kế có kích thước nhỏ hơn 3 trục, chúng:

[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 quá trình triển khai thiết bị Automotive bao gồm con quay hồi chuyển, thì chúng:

[7.3.4/A-2-1] PHẢI có thể báo cáo các sự kiện với một tần suất tối đa tối thiểu 100 Hz.
[7.3.4/A-2-3] PHẢI có khả năng đo các thay đổi về hướng lên đến 250 độ/giây.
[7.3.4/A-SR-1] AreĐể các nhà phát triển sử dụng được phạm vi đo của con quay hồi chuyển là +/-250 dps để tối đa hoá độ phân giải nhất có thể.

Nếu hoạt động triển khai thiết bị Automotive bao gồm con quay hồi chuyển 3 trục, thì chúng:

[7.3.4/A-SR-2] Are trì hoãn 2 danh sách được đề xuất để triển khai cảm biến kết hợp cho con quay hồi chuyển trục giới hạn.

Nếu quá trình triển khai thiết bị Automotive bao gồm một con quay hồi chuyển có ít hơn 3 trục, thì chúng:

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

Nếu quá trình triển khai thiết bị Automotive có bao gồm bộ thu GPS/GNSS, nhưng không có bao gồm kết nối dữ liệu dựa trên mạng di động, chúng:

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

Nếu các mô-đun triển khai thiết bị trên ô tô có cảm biến TYPE_HEADING, thì chúng:

[7.3.4/A-4-3] PHẢI có thể báo cáo các sự kiện với một tần suất tối đa tối thiểu là 1 Hz.
[7.3.4/A-SR-3] RENDERED_Vui lòng chạy báo cáo sự kiện lên đến một tần số tối thiểu là 10 Hz.
PHẢI tham chiếu đến đúng hướng bắc.
NÊN dùng được ngay cả khi xe đứng yên.
PHẢI có độ phân giải ít nhất là 1 độ.

Triển khai thiết bị Automotive:

[7.4.3/A-0-1] PHẢI hỗ trợ Bluetooth và NÊN hỗ trợ Bluetooth LE.
[7.4.3/A-0-2] 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 (A2DP).
- Kiểm soát việc phát nội dung nghe nhìn qua Cấu hình điều khiển từ xa (AVRCP).
- Chia sẻ địa chỉ liên hệ bằng Cấu hình truy cập danh bạ điện thoại (PBAP).

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.4.3/A-SR-1] Are trì hoãn 1 danh sách cho support Cấu hình truy cập tin nhắn (MAP) nếu thiết bị có khu vực của người lái xe.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.4.3/A-1-1] PHẢI độc lập và KHÔNG can thiệp với thông tin của người dùng khác Trải nghiệm BT.

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

Triển khai thiết bị Automotive:

[7.4.5/A] PHẢI bao gồm tính năng hỗ trợ cho thiết bị di động kết nối dữ liệu dựa trên mạng.
[7.4.5/A] CÓ THỂ sử dụng System API Hằng số NetworkCapabilities#NET_CAPABILITY_OEM_PAID cho mạng mà các ứng dụng hệ thống cần có.

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

[7.4/A-1-1] PHẢI khai báo khả năng hỗ trợ cho FEATURE_BROADCAST_RADIO.

Camera mặt sau có nghĩa là camera hướng ra toàn cầu có thể được đặt ở bất kỳ đặt trên xe và hướng ra ngoài cabin của xe; đồng nghĩa với việc nó hình ảnh cảnh ở phía xa của thân xe, chẳng hạn như camera chiếu hậu.

Camera mặt trước có nghĩa là camera mặt trước có thể được đặt ở bất kỳ đặt lên xe và hướng mặt về bên trong cabin xe; vậy thôi hình ảnh mà người dùng sử dụng, chẳng hạn như hội nghị truyền hình và các ứng dụng tương tự.

Triển khai thiết bị Automotive:

[7.5/A-SR-1] Giới thiệu về việc đưa vào một hoặc nhiều hướng dẫn về thế giới camera.
CÓ THỂ bao gồm một hoặc nhiều máy ảnh mặt người dùng.
[7.5/A-SR-2] Are Từ ĐỀ XUẤT NÊN hỗ trợ phát trực tuyến đồng thời của nhiều camera.

Nếu quá trình triển khai thiết bị Automotive bao gồm ít nhất một máy ảnh đối với một chiếc camera như vậy, họ:

[7.5/A-1-1] PHẢI được định hướng để chiều dài của máy ảnh căn chỉnh với mặt phẳng X-Y của các trục cảm biến trên ô tô Android.
[7.5/A-SR-3] Are trì hoãn phát triển để có hoặc cố định-lấy nét hoặc EDOF (Độ sâu trường mở rộng).
[7.5/A-1-2] PHẢI có máy ảnh hướng chính làm hướng mặt về sau máy ảnh có ID máy ảnh thấp nhất.

Nếu quá trình triển khai thiết bị Automotive bao gồm ít nhất một máy ảnh đối với một máy ảnh như vậy:

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

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

[7.5/A-3-1] PHẢI tuân thủ các yêu cầu về camera cốt lõi trong mục 7.5.

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

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

Nếu quá trình triển khai thiết bị Automotive bao gồm một hoặc nhiều máy ảnh có thể truy cập được qua Dịch vụ Chế độ xem mở rộng (Extended View System Service) cho camera như vậy:

[7.5/A-5-1] KHÔNG ĐƯỢC xoay hoặc phản chiếu ngang bản xem trước của máy ảnh.
[7.5/A-SR-4] Are mã hoá NÊN DÙNG để có được độ phân giải ít nhất là 1.3 megapixel.

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

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

Nếu hoạt động triển khai thiết bị Automotive cung cấp một API máy ảnh độc quyền, thì chúng sẽ:

[7.5/A-7-1] PHẢI triển khai API máy ảnh như vậy bằng cách sử dụng android.hardware.camera2 API hoặc Extended View System API.

Triển khai thiết bị Automotive:

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

Nếu quá trình triển khai thiết bị Automotive cung cấp bộ nhớ ngoài dùng chung qua của bộ nhớ trong không thể tháo rời, chúng:

[7.6.1/A-SR-1] Are Từ Sử dụng các chiến dịch khác để giảm Chi phí I/O đối với các thao tác được thực hiện trên bộ nhớ ngoài, ví dụ: đang sử dụng SDCardFS.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[7.6.1/A-1-1] PHẢI have, trên một phiên bản AAOS duy nhất, ít nhất 4 GB cho mỗi người dùng Android đồng thời sử dụng bộ nhớ không biến động có sẵn cho dữ liệu riêng tư của ứng dụng (phân vùng /data).

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

Nếu cấu hình triển khai thiết bị Automotive là 64 bit:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

Triển khai thiết bị Automotive:

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

Triển khai thiết bị Automotive:

[7.8.1/A-0-1] PHẢI bao gồm micrô.

Triển khai thiết bị Automotive:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

2.5.2. Đa phương tiện

Các quá trình triển khai thiết bị trên ô tô PHẢI hỗ trợ phương thức mã hoá âm thanh sau đây và giải mã các định dạng này cũng như cung cấp chúng cho các ứng dụng của bên thứ ba:

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

Các quá trình triển khai thiết bị Automotive PHẢI hỗ trợ phương thức mã hoá video sau đây và cung cấp chúng cho các ứng dụng của bên thứ ba:

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

Các quá trình triển khai thiết bị Automotive PHẢI hỗ trợ phương thức giải mã video sau đây và cung cấp chúng cho các ứng dụng của 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

Các triển khai thiết bị Automotive được ĐỀ XUẤT NÊN hỗ trợ sau đây là cách giải mã video:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[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ư đã xác định trong tệp cấu hình âm thanh ô tô.

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

2.5.3. Phần mềm

Triển khai thiết bị Automotive:

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

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

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

Triển khai thiết bị Automotive:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

Nếu quá trình triển khai thiết bị Automotive có hỗ trợ đồng thời nhiều người dùng hay không (trong đó nhiều người dùng Android có thể tương tác đồng thời với thiết bị, mỗi chiến dịch sử dụng màn hình riêng. config_multiuserVisibleBackgroundUsers đã được bật), đối với người dùng phụ đầy đủ không phải là người dùng nền trước hiện tại nhưng có quyền truy cập giao diện người dùng vào màn hình, chúng:

[3.8/A-1-1] PHẢI triển khai danh sách UserRestrictions được xác định trước sau đây:
[3.8/A-1-2] KHÔNG ĐƯỢC cho phép người dùng đó để thay đổi các cài đặt sau cho bất kỳ người dùng nào khác, thông qua các chế độ cài đặt hoặc API:
- chế độ ngày/đêm
- ngôn ngữ
- date
- giờ
- múi giờ
- các tính năng màu hiển thị (bao gồm Độ sáng, Ánh sáng đêm, Thang màu xám của Digital Wellbeing và Giảm màu sắc tươi sáng)

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

Triển khai thiết bị Automotive:

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

Nếu quá trình triển khai thiết bị Automotive bao gồm nút nhấn để nói, thì các ứng dụng đó sẽ:

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

Triển khai thiết bị Automotive:

[3.8.3.1/A-0-1] PHẢI chính xác hiển thị tài nguyên như mô tả trong Notifications on Automotive OS Tài liệu về SDK.
[3.8.3.1/A-0-2] PHẢI hiển thị PHÁT và TẮT TIẾNG đối với các hành động thông báo thay cho những hành động được cung cấp 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 kênh theo 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 bớt quyền kiểm soát.

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

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

Triển khai thiết bị Automotive:

[3.14/A-0-1] PHẢI bao gồm khung giao diện người dùng để hỗ trợ ứ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 bằng Ứng dụng đa phương tiện trong khi lái xe.
[3.14/A-0-3] PHẢI hỗ trợ CAR_INTENT_ACTION_MEDIA_TEMPLATE thao tác theo ý định ngầm ẩn với CAR_EXTRA_MEDIA_PACKAGE khác.
[3.14/A-0-4] PHẢI cung cấp một thuộc tính tương tác để điều hướng vào của một ứng dụng đa phương tiện lựa chọn ưu tiên hoạt động, nhưng PHẢI chỉ bật khi Các hạn chế về trải nghiệm người dùng trên ô tô không có hiệu lực.
[3.14/A-0-5] PHẢI hiển thị thông báo lỗi do Media Applications đặt và PHẢI hỗ trợ các ứng dụng bổ sung không bắt buộc ERROR_RESOLUTION_ACTION_LABEL và ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] PHẢI hỗ trợ một thuộc tính tương tác tìm kiếm trong ứng dụng cho các ứng dụng hỗ trợ tìm kiếm.
[3.14/A-0-7] PHẢI tôn trọng CONTENT_STYLE_BROWSABLE_HINT và CONTENT_STYLE_PLAYABLE_HINT định nghĩa khi hiển thị MediaBrowser thứ bậc.

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

[3.14/A-1-1] PHẢI bao gồm và mở các dịch vụ nghe nhìn với CAR_INTENT_ACTION_MEDIA_TEMPLATE ý định.

Triển khai thiết bị Automotive:

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

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

Triển khai thiết bị Automotive:

[8.2/A-0-1] PHẢI báo cáo số lượng các byte được đọc và ghi vào bộ nhớ không biến đổi theo UID của mỗi quá trình để số liệu thống kê được cung cấp cho nhà phát triển thông qua API Hệ thống android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Dự án nguồn đáp ứng yêu cầu này thông qua mô-đun nhân uid_sys_stats.
[8.3/A-1-3] PHẢI hỗ trợ Garage Mode.
[8.3/A] PHẢI ở chế độ Garage ít nhất 15 phút sau mỗi lần lái xe, trừ phi:
- Pin đã hết.
- Không có lệnh 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 hồ sơ công suất trên mỗi thành phần, trong đó 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 ước lượng do theo thời gian như được ghi trong trang web Dự án nguồn mở Android.
[8.4/A-0-2] PHẢI báo cáo tất cả nguồn điện giá trị tiêu thụ tính bằng miliampe giờ (mAh).
[8.4/A-0-3] PHẢI báo cáo nguồn điện của CPU mức tiêu thụ trên mỗi UID của quy trình. Dự án nguồn mở Android đáp ứng thông qua việc triển khai mô-đun nhân uid_cputime.
[8.4/A] PHẢI được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng nguồn điện của thành phần phần cứng đối với một ứng dụng.
[8.4/A-0-4] PHẢI thực hiện việc sử dụng điện này được cung cấp qua adb shell dumpsys batterystats shell cho nhà phát triển ứng dụng.

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

Nếu quá trình triển khai thiết bị Automotive hỗ trợ nhiều người dùng, họ sẽ:

[9.5/A-1-1] KHÔNG ĐƯỢC cho phép người dùng tương tác cũng như không chuyển sang Người dùng hệ thống không có giao diện người dùng, ngoại trừ dịch vụ cấp phép thiết bị.
[9.5/A-1-2] PHẢI chuyển thành Người dùng phụ trước ngày 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 thiết bị.

Nếu quá trình triển khai thiết bị Automotive khai báo android.hardware.microphone, chúng:

[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 dữ liệu âm thanh từ micrô, nhưng không truy cập khi chỉ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng giữ vai trò được nêu trong phần 9.1 có giá trị nhận dạng CDD [C-4-X].
[9.8.2/A-1-2] KHÔNG ĐƯỢC ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.
[9.8.2/A-1-3] PHẢI cung cấp khả năng tương tác của người dùng để bật/tắt micrô trong ứng dụng Cài đặt.

Nếu quy trình triển khai thiết bị Automotive khai báo android.hardware.camera.any, thì chúng:

[9.8.2/A-2-1] PHẢI hiển thị chỉ báo camera khi ứng dụng sẽ truy cập vào dữ liệu camera trực tiếp, nhưng không truy cập khi camera chỉ đang được được truy cập bởi(các) ứng dụng có vai trò như được xác định trong Mục 9.1 Quyền có mã nhận dạng CDD [C-4-X].
[9.8.2/A-2-2] KHÔNG ĐƯỢC ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.
[9.8.2/A-2-3] PHẢI cung cấp khả năng tương tác của người dùng để bật/tắt máy ảnh trong ứng dụng Cài đặt.
[9.8.2/A-2-4] PHẢI hiển thị các ứng dụng gần đây và đang hoạt động bằng cách sử dụng máy ảnh như đã trả lại từ PermissionManager.getIndicatorAppOpUsageData(), cùng với bất kỳ liên kết với các thông báo ghi công đó.

Triển khai thiết bị Automotive:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[9.11/A-0-4] PHẢI hỗ trợ chứng thực khoá trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và tính năng ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI ~~được dùng chung trên số lượng thiết bị đủ lớn để ngăn chặn khoá~~ bị ngăn chặn khỏi việc được sử dụng vĩnh viễn mã nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực trừ phi có ít nhất 100.000 đơn vị của một SKU cụ thể sản xuất. Nếu có hơn 100.000 đơn vị SKU được sản xuất, có thể dùng khoá cho mỗi 100.000 đơn vị.

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 đối với một SKU nhất định trừ phi được sản xuất ít nhất 100.000 đơn vị SKU đó. Nếu có hơn 100.000 đơn vị SKU đó được sản xuất, một khoá khác CÓ THỂ được sử dụng cho mỗi nhóm 100.000 đơn vị sau đó. Ngoài ra, có thể sử dụng giải pháp Cấp phép khoá từ xa để cung cấp khoá chứng thực ngắn hạn cho thiết bị.

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

Triển khai thiết bị Automotive:

[9.14/A-0-1] PHẢI gatekeep message trên các hệ thống con của xe khung Android (ví dụ: đưa thông báo được phép vào danh sách cho phép) và nguồn thông báo.
[9.14/A-0-2] PHẢI watchdog Với các cuộc tấn công từ chối dịch vụ từ khung Android hoặc ứng dụng bên thứ ba. Chiến dịch này bảo vệ chống lại phần mềm độc hại làm tràn ngập giao thông trên mạng xe, điều này có thể khiến các hệ thống phụ của xe hoạt động sai cách.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Triển khai thiết bị Automotive:

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

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

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

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

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

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

2.6.1. Phần cứng

Con quay hồi chuyển

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

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

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

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

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

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

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

Hiệu suất thực tế ảo cao (Phần 7.9.2)

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

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

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

Tham khảo Mục [9.11].

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

[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ý thêm người dùng và các chức năng khác của 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 để những người dùng khác làm việc, với khả năng quản lý các hạn chế chi tiết hơn trong các ứng dụng có sẵn trong các môi trường đó.

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

[9.5/T-2-1] KHÔNG ĐƯỢC hỗ trợ bị hạn chế cấu hình nhưng PHẢI phù hợp với cách triển khai các chế độ điều khiển AOSP để cho phép /vô hiệu hoá người dùng khác truy cập cuộc gọi thoại và SMS.

2.6.2. Phần mềm

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

3. Phần mềm

3.1. Khả năng tương thích của 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 để Ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là một tập hợp giao diện trên nền tảng Android hiển thị với 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 đầy đủ các hoạt động triển khai, bao gồm tất cả các nội dung được ghi nhận trong tài liệu của bất kỳ API nào được ghi nhận trong tài liệu do SDK Android hoặc bất kỳ API nào được trang trí bằng "@SystemApi" điểm đánh dấu trong Android ngược dòng mã nguồn.
[C-0-2] PHẢI hỗ trợ/bảo tồn tất cả các lớp, phương thức và phần tử liên quan đượ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, không tuân thủ hành vi được ghi nhận trong tài liệu hoặc bao gồm hoạt động không hoạt động, ngoại trừ trường hợp được định nghĩa về khả năng tương thích này cho phép cụ thể.
[C-0-4] PHẢI vẫn giữ cho các API hiện diện và hoạt động theo cách hợp lý, ngay cả khi một số tính năng phần cứng mà Android bao gồm API đã bị bỏ qua. Xem phần 7 để biết 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, tức là được xác định là các phương thức và trường trong gói ngôn ngữ Java trong đường dẫn lớp khởi động trong AOSP và không tạo thành một phần của công khai SDK. Bao gồm cả các API được trang trí bằng chú thích @hide nhưng không được trang trí bằng @SystemAPI theo mô tả trong tài liệu SDK và các thành viên của lớp riêng tư và riêng tư trong gói.
[C-0-6] PHẢI vận chuyển cùng với mọi giao diện không phải SDK trên cùng một giao diện bị hạn chế như được cung cấp qua cờ tạm thời và cờ danh sách từ chối trong prebuilts/runtime/appcompat/hiddenapi-flags.csv đường dẫn cho nhánh cấp độ API thích hợp trong AOSP.
[C-0-7] PHẢI hỗ trợ Signed config cơ chế cập nhật động để xoá 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 tệp APK bất kỳ, sử dụng các khoá công khai hiện có có trong AOSP.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

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

3.1.1. Tiện ích Android

Android hỗ trợ mở rộng 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 đó. Chiến lược phát hành đĩa đơn API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) trả về phiên bản tiện ích của apiLevel được cung cấp, nếu có các tiện ích dành cho phiên bản đó Cấp độ API.

Triển khai thiết bị Android:

[C-0-1] PHẢI tải trước phương thức triển khai AOSP của cả hai 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 số phiên bản tối thiểu được phép cho mỗi cấp độ API. Ví dụ: Android 7.0 các hoạt động triển khai thiết bị, chạy API cấp 24 PHẢI bao gồm ít nhất phiên bản 1.
[C-0-2] PHẢI chỉ trả về số phiên bản tiện ích hợp lệ đã được do AOSP xác định.
[C-0-3] PHẢI hỗ trợ tất cả API được xác định bởi các phiên bản tiện ích được trả về bởi android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) giống như các API được quản lý khác, tuân theo các yêu cầu trong mục 3.1.

3.1.2. Thư viện Android

Do việc ngừng sử dụng ứng dụng HTTP HTTP, triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC đặt thư viện org.apache.http.legacy vào đường dẫn lớp khởi động.
[C-0-2] PHẢI thêm thư viện org.apache.http.legacy vào ứng dụng classpath 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 bằng cách đặt giá trị Thuộc tính android:name của <uses-library> cho 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 với API mềm

Ngoài các API được quản lý trong phần 3.1, Android cũng bao gồm một phiên bản "mềm" chỉ dành cho thời gian chạy API, ở dạng như vậy chẳng hạn 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 điểm biên dịch ứng dụng.

3.2.1. Quyền

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

3.2.2. Tham số bản dựng

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

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

Thông số	Thông tin chi tiết
VERSION.PHÁT HÀNH	Phiên bản hệ thống Android đang thực thi, ở dạng mà con người có thể đọc được . Trường này PHẢI có một trong các giá trị chuỗi được xác định trong Các chuỗi phiên bản được phép đối với Android 15.
PHIÊN BẢN.SDK	Phiên bản hệ thống Android đang thực thi, ở một định dạng có thể truy cập vào mã xử lý ứng dụng của bên thứ ba. Đối với Android 15, trường này PHẢI có giá trị số nguyên 15_INT.
VERSION.SDK&lowbar;INT	Phiên bản hệ thống Android đang thực thi, ở một định dạng có thể truy cập vào mã xử lý ứng dụng của bên thứ ba. Đối với Android 15, trường này PHẢI có giá trị số nguyên 15&lowbar;INT.
VERSION.INCREMENTAL	Giá trị do trình triển khai thiết bị chọn để chỉ định bản dựng cụ thể của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. Chiến dịch này giá trị KHÔNG ĐƯỢC sử dụng lại cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Đáp thông thường, trường này được sử dụng để cho biết số bản dựng hoặc mã nhận dạng thay đổi kiểm soát nguồn đã được dùng để tạo bản dựng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit có thể in được và khớp với biểu thức chính quy `^[^ :\/~]+$`.
BẢNG	Giá trị do trình triển khai thiết bị chọn để xác định phần cứng bên trong mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Có thể sử dụng trường này là để cho biết bản sửa đổi cụ thể của bảng điện thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9_-]+$`.
THƯƠNG HIỆU	Một giá trị phản ánh tên thương hiệu liên kết với thiết bị được biết đến người dùng cuối. PHẢI ở định dạng con người có thể đọc được và PHẢI thể hiện nhà sản xuất thiết bị hoặc thương hiệu của công ty mà thiết bị sử dụng được tiếp thị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp biểu thức chính quy `^[a-zA-Z0-9_-]+$`.
ĐƯỢC HỖ TRỢ và TRỢ GIÚP	Tên của tập lệnh (loại CPU + quy ước ABI) của gốc . Xem mục 3.3. API gốc Khả năng tương thích.
HỖ TRỢ&lowbar;32&lowbar;BIT&lowbar;ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của gốc . Xem mục 3.3. API gốc Khả năng tương thích.
HỖ TRỢ&lowbar;64&lowbar;BIT&lowbar;ABIS	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Quảng cáo gốc Khả năng tương thích API.
CPU&lowbar;ABI	Tên của tập lệnh (loại CPU + quy ước ABI) của gốc . Xem mục 3.3. API gốc Khả năng tương thích.
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. Quảng cáo gốc Khả năng tương thích API.
THIẾT BỊ	Một giá trị do trình triển khai thiết bị chọn có chứa tên quá trình 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à kiểu dáng công nghiệp của thiết bị. Giá trị của trường này PHẢI là giá trị có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9_-]+$`. Tên thiết bị này KHÔNG ĐƯỢC thay đổi trong vòng đời của sản phẩm.
IN HOA	Một chuỗi xác định duy nhất bản dựng này. PHẢI hợp lý con người có thể đọc được. Ứng dụng PHẢI tuân theo mẫu sau: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/myproduct/ mydevice:15/LMYXX/3359:userdebug/test-keys Vân tay KHÔNG ĐƯỢC bao gồm các ký tự khoảng trắng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit.
PHẦN CỨNG	Tên của phần cứng (từ dòng lệnh kernel hoặc /proc). Nó PHẢI là nội dung 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 là 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_-]+$`.
NGƯỜI DẪN CHƯƠNG TRÌNH	Một chuỗi xác định duy nhất máy chủ lưu trữ bản dựng, trong ở đị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ừ trường KHÔNG ĐƯỢC để trống hoặc là chuỗi trống ("").
ID	Giá trị nhận dạng do trình triển khai thiết bị chọn để tham chiếu đến một mã nhận dạng cụ thể bản phát hành, ở đị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ị vừa đủ có ý 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 có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức `^[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 của Google. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc mã đó KHÔNG PHẢI là giá trị rỗng hoặc là chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt vòng đời của sản phẩm.
Nhà sản xuất	Tên thương mại của nhà sản xuất hệ thống chính trên chip (SOC) được sử dụng trong sản phẩm. Các thiết bị có cùng nhà sản xuất SOC nên sử dụng cùng một giá trị không đổi. Vui lòng hỏi nhà sản xuất SOC hằng số chính xác để sử dụng. Giá trị của trường này PHẢI là giá trị có thể mã hoá dưới dạng ASCII 7 bit, PHẢI khớp với biểu thức chính quy `^([0-9A-Za-z ]+)`, KHÔNG ĐƯỢC bắt đầu hoặc kết thúc bằng khoảng trắng, và KHÔNG ĐƯỢC bằng giá trị "không xác định". Trường này KHÔNG ĐƯỢC thay đổi trong vòng đời của sản phẩm.
MÔ HÌNH SOC&lowbar;	Tên kiểu máy của 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 mô hình SOC nên sử dụng cùng một hằng số giá trị. Vui lòng hỏi nhà sản xuất SOC để sử dụng hằng số chính xác. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^([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 giá trị "không xác định". Trường này KHÔNG ĐƯỢC thay đổi trong suốt vòng đời của sản phẩm.
KIỂU MÁY	Một giá trị do trình triển khai thiết bị chọn có chứa tên của mà người dùng cuối biết. Tên này PHẢI giống với tên mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG ĐƯỢC rỗng hoặc chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong vòng đời của sản phẩm.
SẢN PHẨM	Một giá trị do trình triển khai thiết bị chọn có chứa tên quá trình phát triển hoặc tên mã của sản phẩm (SKU) cụ thể 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 là để xem được theo người dùng cuối. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9_-]+$`. Sản phẩm này tên 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 trình triển khai thiết bị chọn, có chứa SKU (Đơn vị lưu kho) được dùng để theo dõi các cấu hình cụ thể của thiết bị cụ thể, ví dụ: bất kỳ thiết bị ngoại vi nào đi kèm với thiết bị khi bán. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^([0-9A-Za-z.,_-]+)$`.
SÊ-RI	PHẢI trả về giá trị "UNKNOWN" (KHÔNG XÁC ĐỊNH).
THẺ TỪ KHOÁ	Danh sách các thẻ được phân tách bằng dấu phẩy do trình triển khai thiết bị chọn sẽ giúp bản dựng trở nên khác biệt. Các thẻ PHẢI có thể 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._-]+` và PHẢI có một trong các giá trị tương ứng với ba nền tảng Android điển hình cấu hình ký: khoá phát hành, khoá nhà phát triển và khoá kiểm thử.
THỜI GIAN	Một giá trị biểu thị dấu thời gian khi quá trình tạo bản dựng diễn ra.
LOẠI	Giá trị do trình triển khai thiết bị chọn để chỉ định thời gian chạy cấu hình 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 ba cấu hình thời gian chạy Android điển hình: người dùng, 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 ra 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 mã đó KHÔNG PHẢI là giá trị rỗng hoặc là chuỗi trống ("").
BẢO MẬT	Một giá trị cho biết cấp bản vá bảo mật của một bản dựng. Nó PHẢI biểu thị bản dựng không hề dễ gặp phải bất kỳ vấn đề nào đã mô tả thông qua Bản tin về an ninh công cộng Android được chỉ định. Phải ở trong định dạng [YYYY-MM-DD], khớp với một chuỗi được xác định được nêu trong An ninh công cộng Android Bản tin hoặc trong Tư vấn bảo mật Android, ví dụ: "2015-11-01".
Hệ điều hành cơ sở&thấp	Một giá trị đại diện cho tham số FINGERprint của bản dựng khác với bản dựng này, ngoại trừ các bản vá được cung cấp trong Bản tin về an ninh công cộng Android. Giá trị PHẢI báo cáo giá trị chính xác và nếu bản dựng như vậy không tồn tại, hãy báo cáo chuỗi trống ("").
TRÌNH TẢI TĂNG	Giá trị do trình 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 dùng trong thiết bị, ở định dạng mà con người có thể đọc được. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	PHẢI (là hoặc trả về) một giá trị do trình triển khai thiết bị chọn xác định phiên bản radio/modem nội bộ cụ thể được sử dụng trong thiết bị, ở định dạng mà con người có thể đọc được. Nếu thiết bị không có bộ nhớ trong radio/modem nó PHẢI trả về NULL. Giá trị của trường này PHẢI là có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9._-,]+$`.
getSerial()	PHẢI (là hoặc trả về) số sê-ri phần cứng, số này PHẢI khả dụng và duy nhất trên các thiết bị có cùng MÔ HÌNH và NHÀ SẢN XUẤT. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `^[a-zA-Z0-9]+$`.

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

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

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

Triển khai thiết bị:

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

Vui lòng tham khảo Phần 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 cách triển khai thiết bị PHẢI cho phép từng mẫu ý định được tham chiếu trong phần 3.2.3.1, ngoại trừ phần Cài đặt sẽ bị các ứng dụng bên thứ ba ghi đè. Chiến lược phát hành đĩa đơn Việc triển khai nguồn mở Android ngược dòng cho phép điều này theo mặc định.
[C-0-2] Trình triển khai thiết bị KHÔNG ĐƯỢC đính kèm đặc quyền đặc biệt vào hệ thống ứng dụng việc sử dụng các mẫu ý định này hoặc ngăn các ứng dụng của bên thứ ba từ liên kết đến và có quyền kiểm soát các mẫu này. Quy định cấm này cụ thể bao gồm nhưng không giới hạn ở việc tắt "Trình chọn" người dùng cho phép người dùng chọn giữa nhiều ứng dụng mà tất cả xử lý cùng một mẫu ý định.
[C-0-3] Các quá trình triển khai thiết bị PHẢI cung cấp giao diện người dùng cho người dùng sửa đổi hoạt động mặc định cho ý định.
Tuy nhiên, việc triển khai thiết bị CÓ THỂ cung cấp hoạt động mặc định cho Mẫu URI (ví dụ: http://play.google.com) khi hoạt động mặc định cung cấp 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 so với 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 hành vi liên kết ứng dụng mặc định đáng tin cậy cho một số loại ý định URI web. Khi những tuyên bố có căn cứ đáng tin đó được xác định trong các mẫu bộ lọc ý định của ứng dụng, cách triển khai thiết bị:

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

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

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

3.2.3.4. Ý định truyền tin

Các ứng dụng của bên thứ ba dựa vào nền tảng để truyền tải một số ý định nhất định đến thông báo cho họ 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 tin về ý đị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. 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 ứng dụng nền cũng được mô tả trong SDK tài liệu. Ngoài ra, một số ý định truyền tin có điều kiện đối với phần cứng hỗ trợ, nếu thiết bị hỗ trợ phần cứng cần thiết, chúng PHẢI truyền phát ý định và cung cấp hành vi cùng dòng với tài liệu về SDK.

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

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

Khi thích hợp, việc triển khai thiết bị PHẢI cung cấp chế độ 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 quá trình triển khai thiết bị báo cáo android.software.home_screen, họ sẽ:

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

Nếu quá trình triển khai thiết bị báo cáo android.hardware.telephony.calling, họ sẽ:

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

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc.hce, họ sẽ:

[C-3-1] PHẢI tuân thủ android.settings.NFC_PAYMENT_SETTINGS ý định hiển thị trình đơn cài đặt mặc định của ứng dụng cho tính năng Thanh toán không tiếp xúc.
[C-3-2] PHẢI tôn trọng android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT khi thể hiện một hoạt động, hoạt động này sẽ mở ra một 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ư được mô tả trong SDK.

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc, họ sẽ:

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

Nếu quá trình triển khai thiết bị báo cáo android.hardware.bluetooth, họ sẽ:

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

Nếu các quá trình triển khai thiết bị hỗ trợ tính năng DND, thì các thiết bị đó sẽ:

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

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

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

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

[C-8-1] PHẢI tôn trọng android.settings.ACCESSIBILITY_SETTINGS là 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 tính năng hỗ trợ tiếp cận được tải trước luôn miễn phí.

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

[C-9-1] PHẢI triển khai chế độ cài đặt Settings#ACTION_Processes_Wi-Fi_EASY_CONNECT_URI Các API Ý định như mô tả trong tài liệu về SDK.

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

[C-10-1] PHẢI cung cấp giao diện người dùng trong các cài đặt để xử lý Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ý định, cho phép người dùng thêm ứng dụng vào 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ế độ tiết kiệm dữ liệu, chúng sẽ:

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

Nếu quá trình triển khai thiết bị khai báo tính năng hỗ trợ cho máy ảnh qua android.hardware.camera.any, họ:

[C-12-3] PHẢI xử lý và PHẢI chỉ cho phép các ứng dụng Android được cài đặt trước để 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 quá trình triển khai thiết bị báo cáo android.software.device_admin, họ sẽ:

[C-13-1] PHẢI thực hiện ý định android.app.action.ADD_DEVICE_ADMIN để gọi một giao diện người dùng nhằm đưa người dùng đến thông qua việc thêm quản trị viên thiết bị vào hệ thống (hoặc cho phép họ từ chối hệ thống).
[C-13-2] PHẢI thực hiện ý định android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_ MẬT, android.app.action.SET_NEW_Password và android.app.action.START_ENCRYPTION và có một hoạt động để cung cấp phương thức thực hiện cho những ý định này như được mô tả trong SDK tại đây.

Nếu các quá trình triển khai thiết bị, hãy khai báo android.software.autofill cờ tính năng, chúng:

[C-14-1] PHẢI triển khai đầy đủ AutofillService và AutofillManager API và tuân thủ android.settings.REQUEST_SET_autoFILL_SERVICE hiển thị trình đơn cài đặt ứng dụng mặc định để 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.

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

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

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

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

Nếu quá trình triển khai thiết bị hiển thị đường liên kết đến các hoạt động được chỉ định bởi Tự động điền dịch vụ_mật khẩu hoạt động trong phần Cài đặt hoặc đường liên kết đến mật khẩu người dùng thông qua cơ chế tương tự, họ sẽ:

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

Nếu các quá trình triển khai thiết bị có hỗ trợ VoiceInteractionService và có nhiều tính năng khác nhiều ứng dụng sử dụng API này được cài đặt cùng một lúc, chúng:

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

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

[C-SR-3] CÓ ĐỀ XUẤT ĐỀ XUẤT để tôn trọng android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA và Các ý định android.speech.tts.engine.GET_SAMPLE_TEXT có một hoạt động cần cung cấp phương thức thực hiện cho các ý định này như mô tả trong SDK tại đây.

Android có hỗ trợ cho trình bảo vệ màn hình tương tác, trước đây gọi là như Giấc mơ. Trình bảo vệ màn hình cho phép người dùng tương tác với các ứng dụng khi thiết bị kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế để 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 tuỳ chọn cài đặt cho định cấu hình trình bảo vệ màn hình sao cho phù hợp với Ý định android.settings.DREAM_SETTINGS.

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

[C-19-1] PHẢI triển khai NfcAdapter.ACTION_TRANSACTION_ chiếuED Intent API (dưới dạng "EVT_TRANSACTION" theo thông số kỹ thuật của Hiệp hội GSM TS.26 – Yêu cầu về điện thoại di động NFC).

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

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

[C-1-1] PHẢI đặt android.software.activities_on_secondary_displays cờ tính năng.
[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ục tiêu hiển thị qua ActivityOptions.setLaunchDisplayId() API.
[C-1-4] PHẢI huỷ bỏ tất cả các hoạt động, khi màn hình có Display.FLAG_PRIVATE cờ đã bị xoá.
[C-1-5] PHẢI ẩn nội dung trên tất cả màn hình một cách an toàn khi thiết bị đang khoá có màn hình khoá an toàn, trừ phi ứng dụng chọn hiển thị ở trên màn hình khoá màn hình bằng Activity#setShowWhenLocked() API.
NÊN có android.content.res.Configuration tương ứng với màn hình đó để được hiển thị, hãy thao tá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 chạy Hoạt động Android bình thường trên phụ màn hình hiển thị và màn hình phụ có android.view.Display.FLAG_PRIVATE cờ:

[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 đó PHẢI có thể chạy trên màn hình. Mọi người đều có thể chạy để một màn hình có android.view.Display.FLAG_PUBLIC cờ.

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

Khó tương thích với mã gốc. Vì lý do này, những trình triển khai thiết bị đó:

[C-SR-1] ANH NÊN SỬ DỤNG các phương pháp 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 ngược dòng.

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

Mã byte Dalvik được quản lý có thể gọi vào mã gốc được cung cấp trong ứng dụng Tệp .apk dưới dạng tệp ELF .so được biên dịch cho phần cứng thiết bị thích hợp cấu trúc. Vì mã gốc phụ thuộc nhiều vào bộ xử lý cơ bản công nghệ, Android định nghĩa 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 Android NDK đã xác định.
[C-0-2] PHẢI bao gồm tính năng hỗ trợ cho mã chạy trong môi trường được quản lý để gọi vào mã gốc, bằng cách sử dụng Giao diện gốc Java (JNI) chuẩn ngữ nghĩa.
[C-0-3] PHẢI tương thích với nguồn (ví dụ: tương thích với tiêu đề) và tương thích nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách bên dưới.
[C-0-5] PHẢI báo cáo chính xác Giao diện nhị phân của ứng dụng gốc (ABI) được thiết bị hỗ trợ, qua android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS và android.os.Build.SUPPORTED_64_BIT_ABIS tham số, mỗi tham số được phân tách bằng dấu phẩy danh sách ABI được sắp xếp theo thứ tự từ nhiều nhất đến ít được ưa thích nhất.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-0-6] PHẢI báo cáo, thông qua các thông số trên, một tập hợp con của các thông số sau danh sách ABI và KHÔNG ĐƯỢC báo cáo bất kỳ ABI nào không có trong danh sách.
- armeabi (không còn được NDK hỗ trợ làm mục tiêu)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64

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

[C-0-7] PHẢI tạo tất cả các thư viện sau, cung cấp API gốc, có sẵn cho các ứng dụng chứa mã gốc:
- libaaudio.so (Hỗ trợ âm thanh gốc AAudio)
- libamidi.so (hỗ trợ MIDI gốc, nếu có android.software.midi được khiếu nại như mô tả trong Mục 5.9)
- libandroid.so (hỗ trợ hoạt động gốc trên Android)
- libc (thư viện C)
- libcamera2ndk.so
- libdl (trình liên kết động)
- libEGL.so (quản lý nền tảng OpenGL gốc)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (ghi nhật ký Android)
- libmediandk.so (hỗ trợ các API nội dung nghe nhìn gốc)
- libm (thư viện toán học)
- libneuralnetworks.so (API Mạng Neural)
- 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 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 (Dự án nguồn mở Android) bổ sung được tiếp xúc trực tiếp với các ứng dụng bên thứ ba ở /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à được cung cấp trong AOSP dưới dạng thư viện hệ thống đến API nhắm mục tiêu ứng dụng của bên thứ ba cấp 24 trở lên vì chúng đã được đặt trước.
[C-0-11] PHẢI export tất cả OpenGL ES 3.1 và Android Extension Pack các biểu tượng hàm, như xác định trong NDK, thông qua thư viện libGLESv3.so. Lưu ý rằng mặc dù tất cả các ký hiệu PHẢI hiện diện, mục 7.1.4.1 mô tả thông tin chi tiết hơn về các yêu cầu đối với thời điểm triển khai đầy đủ mỗi dự kiến sẽ có các hàm tương ứng.
[C-0-12] PHẢI xuất ký hiệu hàm cho chính Hàm Vulkan 1.1 cũng như VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 và VK_KHR_get_physical_device_properties2 tiện ích thông qua Thư viện libvulkan.so. Lưu ý rằng mặc dù PHẢI có tất cả các biểu tượng, mục 7.1.4.2 mô tả chi tiết hơn các yêu cầu đối với khi cần triển khai từng chức năng tương ứng.
NÊN được tạo bằng cách sử dụng mã nguồn và tệp tiêu đề có sẵn trong Dự án nguồn mở Android ngược dòng.

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

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

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

[C-3-1] cũng PHẢI hỗ trợ armeabi-v7a và báo cáo khả năng hỗ trợ như armeabi chỉ dành cho khả năng tương thích ngược với các ứng dụng cũ.

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

[C-2-1] PHẢI bao gồm 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 ABI khác đọc được.
- Features:, theo sau là danh sách mọi tính năng CPU ARMv7 không bắt buộc được thiết bị hỗ trợ.
- CPU architecture:, theo sau là một số nguyên mô tả thông tin kiến trúc ARM cao nhất được hỗ trợ (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 hỗ trợ CPU gốc hoặc thông qua mô phỏng phần mềm:
- Hướng dẫn về SWP và SWPB.
- Các vận hành rào cản CP15ISB, CP15DSB và CP15DMB.
[C-2-3] PHẢI include hỗ trợ cho SIMD nâng cao (còn gọi là NEON).

3,4. Khả năng tương thích trên web

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

Nếu quá trình triển khai thiết bị cung cấp việc triển khai hoàn chỉnh android.webkit.Webview API, chúng:

[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 Android 15 để triển khai android.webkit.WebView API.
[C-1-3] Chuỗi tác nhân người dùng do WebView báo cáo PHẢI ở định dạng sau:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, như 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ó cùng giá trị với android.os.Build.MODEL.
- "Build/$(XÂY DỰNG)" CÓ THỂ bỏ qua, nhưng nếu có thì $(BUILD) chuỗi PHẢI giống với giá trị cho android.os.Build.ID.
- Giá trị của chuỗi $(CHROMIUM_VER) PHẢI là phiên bản Chromium trong Dự án nguồn mở Android ngược dòng.
- Quá trình triển khai thiết bị 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 PHẢI bao gồm tính năng hỗ trợ cho nhiều tính năng HTML5 nhất có thể có thể và nếu có hỗ trợ tính năng PHẢI tuân thủ Quy cách HTML5.
[C-1-4] PHẢI hiển thị nội dung được cung cấp hoặc nội dung URL từ xa trong một quy trình khác với ứng dụng tạo thực thể WebView. Cụ thể quy trình kết xuất đồ hoạ riêng biệt PHẢI giữ đặ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 mạng trực tiếp và chỉ có quyền truy cập vào mức truy cập tối thiểu bắt buộc qua Binder. Việc triển khai AOSP của WebView đáp ứng yêu cầu này.

Lưu ý rằng nếu quá trình triển khai thiết bị là 32 bit hoặc khai báo cờ tính năng android.hardware.ram.low, họ được miễn tham gia C-1-3.

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

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

[C-1-1] PHẢI hỗ trợ từng API được liên kết với HTML5
[C-1-2] PHẢI hỗ trợ HTML5/W3C webstorage API và NÊN hỗ trợ HTML5/W3C API IndexedDB. Lưu ý rằng, với vai trò web đang chuyển đổi các cơ quan tiêu chuẩn phát triể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 tương lai của Android.
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ợ cho tối đa HTML5 tốt nhất có thể trên phiên bản độc lập Ứng dụng trình duyệt (cho dù dựa trên Trình duyệt WebKit ở trên hoặc ứng dụng thay thế của bên thứ ba).

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

[C-2-1] vẫn PHẢI hỗ trợ các mẫu ý định công khai như được 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 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ế theo 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 API khả năng tương thích hành vi chỉ dành cho các ứng dụng do thiết bị chọn người triển khai.

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 luồng ngược Dự án nguồn mở Android. Một số lĩnh vực 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 ý định chuẩn.
[C-0-2] Thiết bị KHÔNG ĐƯỢC thay đổi vòng đời hoặc ngữ nghĩa vòng đời của một loại thành phần hệ thống cụ thể (chẳng hạn như Service, Activity, ContentProvider, v.v.).
[C-0-3] Các thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của quyền tiêu chuẩn.
Thiết bị KHÔNG ĐƯỢC thay đổi các giới hạn được thực thi trên các ứng dụng nền. Cụ thể hơn, đối với các ứng dụng nền:
- [C-0-4] họ PHẢI ngừng thực thi các lệnh gọi lại được đăng ký bởi ứng dụng nhận dữ liệu đầu ra từ GnssMeasurement và GnssNavigationMessage.
- [C-0-5] họ PHẢI rate-limit giới hạn tần suất cập nhật được cung cấp cho ứng dụng thông qua LocationManager lớp API hoặc lớp WifiManager.startScan() .
- [C-0-6] nếu ứng dụng đang nhắm đến API cấp 25 trở lên, thì ứng dụng KHÔNG ĐƯỢC cho phép đăng ký broadcast receiver cho thông báo truyền phát ngầm của các ý định Android chuẩn trong tệp kê khai của ứng dụng, trừ phi thông báo truyền tin ý định yêu cầu "signature" hoặc "signatureOrSystem" protectionLevel hoặc đang ở trên danh sách miễn trừ.
- [C-0-7] nếu ứng dụng đang nhắm đến API cấp 25 trở lên, thì ứng dụng 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 dịch vụ stopSelf() trừ phi ứng dụng được đưa vào một danh sách cho phép tạm thời để xử lý công việc mà người dùng nhìn thấy.
- [C-0-8] nếu ứng dụng đang nhắm đến API cấp 25 trở lên, thì ứng dụng PHẢI PHẢI nhả khoá ở chế độ thức mà ứng dụng đang lưu giữ.
[C-0-11] Thiết bị PHẢI trả về các nhà cung cấp bảo mật sau làm lựa chọn đầu tiên 7 giá trị mảng từ Security.getProviders() theo thứ tự đã cho và với các tên đã cho (như được trả về bởi Provider.getName()) và lớp, trừ phi ứng dụng đã sửa đổi danh sách thông qua insertProviderAt() hoặc removeProvider(). Thiết bị CÓ THỂ trả về các nhà cung cấp khác sau danh sách nhà cung cấp đã 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. AndroidKeyStoreBCWorkChính – 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 đủ. Các bài kiểm tra Bộ kiểm tra tính tương thích (CTS) các phần quan trọng của nền tảng để tương thích về hành vi, nhưng không phải tất cả. Trách nhiệm của trình triển khai là đả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, trình 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 khi 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ế về ứng dụng

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

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

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

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

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

Nếu quá trình triển khai thiết bị bao gồm Trạng thái ngủ đông của ứng dụng được đưa vào AOSP hoặc mở rộng tính năng có trong AOSP, sau đó chúng:

[C-1-1] PHẢI đáp ứng tất cả các yêu cầu trong mục 3.5.1 ngoại trừ [C-1-6] và [C-1-3].
[C-1-2] PHẢI chỉ áp dụng quy định hạn chế trên ứng dụng đối với 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. Chiến dịch này THỜI GIAN THỰC HIỆN ĐƯỢC ĐỀ XUẤT là một tháng trở lên. Cách sử dụng PHẢI là được xác định theo tương tác rõ ràng của người dùng thông qua UsageStats#getLastTimeImpression() API hoặc bất cứ điều gì khiến ứng dụng rời khỏi trạng thái buộc dừng, bao gồm liên kết dịch vụ, liên kết nhà cung cấp nội dung, thông báo rõ ràng, v.v. sẽ được theo dõi bằng API UsageStats#getLastTimeAnyComponentOnce() mới.
[C-1-3] PHẢI chỉ áp dụng các hạn chế ảnh hưởng đến tất cả người dùng thiết bị khi có là bằng chứng cho thấy gói đã không được BẤT KỲ người dùng nào sử dụng trong một khoảng thời gian bất cứ lúc nào. Khoảng thời gian này KHÔNG ĐƯỢC ĐỀ XUẤT là từ một tháng trở lên.
[C-1-4] KHÔNG ĐƯỢC hiển thị ứng dụng không thể phản hồi ý định hoạt động, liên kết dịch vụ, yêu cầu của trình cung cấp nội dung hoặc thông báo rõ ràng.

Trạng thái ngủ đông của ứng dụng trong AOSP đáp ứng các yêu cầu trên.

3.6. Không gian tên API

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

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

Tức là chúng:

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

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

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

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

[C-0-5] KHÔNG ĐƯỢC nằm trong không gian tên thuộc sở hữu của hoặc tham chiếu đến một không gian tên khác tổ chức. Ví dụ: trì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 các công ty khác không gian tên.
[C-0-6] PHẢI được đóng gói trong thư viện dùng chung Android để chỉ các ứng dụng sử dụng chúng một cách rõ ràng (thông qua cơ chế <uses-library>) được sử dụng bị ảnh hưởng bởi việc sử dụng bộ nhớ tăng lên của các API này.

Trình triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh bằng ngôn ngữ gốc, bên ngoài NDK API, ngoại trừ các API tuỳ chỉnh:

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

Nếu một trì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 API hiện có hoặc thêm một API), trình triển khai NÊN truy cập source.android.com và bắt đầu quá trình đóng góp các thay đổi cũng như mã, theo thông tin trên trang web đó.

Lưu ý rằng các hạn chế ở trên tương ứng với quy ước đặt tên tiêu chuẩn API bằng 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à làm cho chúng có tính ràng buộc thông qua việc đưa vào Khả năng tương thích này Định nghĩa.

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

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

Bố cục màn hình	Mật độ màn hình	Bộ nhớ tối thiểu của ứng dụng
Đồ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 giao diện người dùng

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

Android bao gồm ứng dụng trình chạy (màn hình chính) và hỗ trợ cho 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 quá trình triển khai thiết bị cho phép các ứng dụng bên thứ ba thay thế thiết bị màn hình chính, họ:

[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ề AdaptiveIconDrawable khi ứng dụng bên thứ ba sử dụng thẻ <adaptive-icon> để cung cấp biểu tượng và PackageManager để truy xuất biểu tượng sẽ được gọi.

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

[C-2-1] PHẢI báo cáo true về ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] PHẢI có thuộc tính tương tác của người dùng yêu cầu người dùng trước khi thêm lối tắt được yêu cầu theo ứng dụng qua ShortcutManager.requestPinShortcut() API.
[C-2-3] PHẢI hỗ trợ lối tắt được ghim, động và tĩnh như được nêu trên trang Lối tắt ứng dụng.

Ngược lại, nếu quá trình triển khai thiết bị không hỗ trợ tính năng ghim trong ứng dụng lối tắt, chúng:

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

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

[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ụ: tĩnh và lối tắt động, ghim lối tắt) và triển khai đầy đủ các API của ShortcutManager Lớp API.

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

[C-5-1] PHẢI tuân thủ NotificationChannel.setShowBadge() API. Nói cách khác, hãy cho thấy một thuộc tính tương tác trực quan được liên kết với biểu tượng ứng dụng nếu được đặt thành true và không hiển thị lược đồ huy hiệu biểu tượng ứng dụng nào khi tất cả kênh thông báo của ứng dụng đã đặt giá trị là false.
CÓ THỂ ghi đè huy hiệu biểu tượng ứng dụng bằng lược đồ huy hiệu độc quyền khi các ứng dụng bên thứ ba cho thấy có hỗ trợ lược đồ huy hiệu độc quyền thông qua việc sử dụng các API độc quyền, nhưng PHẢI sử dụng 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à Notification.Builder.setBadgeIconType() API.

Nếu phương thức triển khai thiết bị có hỗ trợ đơn sắc các biểu tượng sau:

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

3.8.2. Tiện ích

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

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

[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 bao gồm tính năng hỗ trợ tích hợp sẵn cho AppWidgets và hiển thị các thành phần trong giao diện người dùng để thêm, định cấu hình, xem và xoá AppWidgets
[C-1-3] PHẢI có khả năng kết xuất tiện ích có kích thước 4 x 4 ở kích thước lưới chuẩn. Vui lòng xem App Widget Design Guidelines (Nguyên tắc thiết kế tiện ích ứng dụng) để biết thông tin chi tiết, hãy xem tài liệu về SDK Android.
CÓ THỂ hỗ trợ các tiện ích ứng dụng trên màn hình khoá.

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

[C-2-1] PHẢI báo cáo true về AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] PHẢI có thuộc tính tương tác của người dùng yêu cầu người dùng trước khi thêm lối tắt được yêu cầu theo ứng dụng qua AppWidgetManager.requestPinAppWidget() API.

3.8.3. Thông báo

Android bao gồm Notification và NotificationManager Các API 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 người dùng chú ý bằng các thành phần phần cứng (ví dụ: âm thanh, rung và ánh sáng) cùng các tính năng phần mềm (ví dụ: ngăn thông báo, thanh hệ thống) của thiết bị.

3.8.3.1. Bản trình bày thông báo

Nếu quá trình triển khai thiết bị 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ú ý, họ:

[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 việc triển khai thiết bị phần cứng. Ví dụ: nếu quá trình triển khai thiết bị bao gồm bộ rung, thì bộ rung đó PHẢI triển khai chính xác các API rung. Nếu thiếu phương thức triển khai thiết bị 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 nêu chi tiết hơn trong phần 7.
[C-1-2] PHẢI kết xuất chính xác tất cả tài nguyên (biểu tượng, tệp hoạt ảnh, v.v.) được cung cấp trong API hoặc trong Hướng dẫn kiểu biểu tượng trên Thanh hệ thống/Trạng thái, mặc dù chúng CÓ THỂ cung cấp trải nghiệm người dùng thay thế cho thông báo so với phạm vi được cung cấp trong trường hợp triển khai Nguồn mở Android tham chiếu.
[C-1-3] PHẢI tuân thủ và triển khai đúng các hành vi được mô tả cho API để cập nhật, xoá và nhóm thông báo.
[C-1-4] PHẢI cung cấp hành vi đầy đủ của NotificationChannel API được ghi nhận trong SDK.
[C-1-5] PHẢI cung cấp một thuộc tính tương tác cho người dùng để chặn và sửa đổi một thông báo của ứng dụng bên thứ ba trên mỗi kênh và cấp gói ứng dụng.
[C-1-6] PHẢI cung cấp một thuộc tính tương tác người dùng để hiển thị thông báo đã xoá các kênh.
[C-1-7] PHẢI hiển thị chính xác tất cả cá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 bên cạnh nội dung thông báo mà không cần người dùng tương tác thêm. Cho Ví dụ: PHẢI hiển thị tất cả tài nguyên, bao gồm cả biểu tượng được cung cấp qua android.app.Person trong một cuộc trò chuyện nhóm được đặt qua setGroupconversation.
[C-SR-1] Giới hạn định dạng giới thiệu để cung cấp một thuộc tính tương tác cho người dùng kiểm soát thông báo hiển thị với các ứng dụng đã được cấp quyền Quyền trình nghe thông báo. Độ chi tiết PHẢI để người dùng có thể kiểm soát loại thông báo nào cho mỗi trình nghe thông báo đã bắc cầu đến trình nghe này. Các loại PHẢI bao gồm "cuộc trò chuyện", "thông báo", "tắt tiếng" và "đang diễn ra quan trọng" thông báo.
[C-SR-2] Giới hạn định dạng cung cấp một thuộc tính cho người dùng để chỉ định các ứng dụng cần loại trừ thông báo cho bất kỳ trình nghe thông báo cụ thể nào.
[C-SR-3] Are trì hoãn phát trên thiết bị để tự động hiển thị một thuộc tính tương tác của người dùng để chặn thông báo của một ứng dụng bên thứ ba trên mỗi kênh và ứng dụng cấp gói sau khi người dùng đóng thông báo đó nhiều lần.
NÊN hỗ trợ các thông báo chi tiết.
NÊN hiển thị một số thông báo có mức độ ưu tiên cao hơn dưới dạng thông báo quan trọng.
NÊN có thuộc tính tương tác với người dùng để tạm ẩn thông báo.
Chỉ có thể quản lý chế độ hiển thị và thời điểm các ứng dụng bên thứ ba có thể thông báo người dùng các sự kiện đáng chú ý nhằm giảm thiểu các vấn đề an toàn như sự mất tập trung của người lái xe.

Android 11 ra mắt tính năng hỗ trợ thông báo về cuộc trò chuyện, tức là thông báo sử dụng MessagingStyle và cung cấp Mã lối tắt People (Mọi người) đã xuất bản.

Triển khai thiết bị:

[C-SR-4] Đang được ĐỀ XUẤT NÊN nhóm và màn hình conversation notifications trước các thông báo không phải là cuộc trò chuyện, ngoại trừ thông báo liên tục về dịch vụ trên nền trước và importance:high thông báo.

Nếu quá trình triển khai thiết bị có hỗ trợ conversation notifications và ứng dụng này cung cấp dữ liệu cần thiết để bubbles, họ:

[C-SR-5] Are trì hoãng động để 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 với Giao diện người dùng hệ thống mặc định, Phần Cài đặt và Trình chạy.

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

[C-2-1] PHẢI sử dụng đúng tài nguyên dưới dạng được cung cấp thông qua Notification.Style Lớp API và lớp con của lớp đó cho các phần tử tài nguyên được trình bày.
NÊN trình bày mọi 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 Notification.Style Lớp API và các lớp con của chúng.

Thông báo quan trọng là các thông báo hiển thị cho người dùng khi họ truy cập một cách độc lập với nền tảng mà người dùng truy cập . Liệu việc triển khai thiết bị có hỗ trợ cảnh báo quan trọng hay không thông báo, thì họ:

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

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

Android bao gồm NotificationListenerService API cho phép các ứng dụng (sau khi người dùng cho phép 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 toàn bộ thông báo một cách chính xác và kịp thời cho tất cả các dịch vụ trình nghe được cài đặt và hỗ trợ người dùng đó, bao gồm bất kỳ và tất cả siêu dữ liệu được đính kèm vào đối tượng Notification.
[C-0-2] PHẢI tuân thủ snoozeNotification() lệnh gọi API, loại bỏ thông báo và thực hiện lệnh gọi lại sau khi tạm ẩn thời lượng được đặt trong lệnh gọi API.

Nếu các hoạt động triển khai trên thiết bị có khả năng tương tác với người dùng để tạm ẩn thông báo, thì các hoạt động triển khai trên thiết bị sẽ:

[C-1-1] PHẢI phản ánh đúng trạng thái thông báo đã tạm ẩn thông qua các API chuẩn như NotificationListenerService.getSnoozedNotifications().
[C-1-2] PHẢI cung cấp thuộc tính tương tác người dùng này để tạm ẩn thông báo của mỗi ứng dụng bên thứ ba đã cài đặt, trừ phi các ứng dụng đó bắt nguồn từ dịch vụ ổn định/trên nền trước.

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

Nếu quá trình triển khai thiết bị có hỗ trợ tính năng DND hay không (còn gọi là Chế độ ưu tiên), chúng:

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

3.8.3.4. Bảo vệ thông báo nhạy cảm

Thông tin nhạy cảm về 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à 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 quá trình triển khai thiết bị 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ú ý, chúng:

[C-1-1] PHẢI che khuất thông tin thông báo nhạy cảm được chuyển cho trình nghe thông báo, trừ phi dịch vụ trình nghe là một trong:
- Ứng dụng do hệ thống ký có uid < 10.000
- Giao diện người dùng hệ thống
- Vỏ
- Ứng dụng thiết bị đồng hành được chỉ định (do CompanionDeviceManager xác định)
- Vai trò SYSTEM_AUTOMOTIVE_PROJECTION
- Vai trò SYSTEM_NOTIFICATION_INTELLIGENCE
- Vai trò NHÀ RIÊNG

Triển khai AOSP của NotificationAssistantServices thể hiện và đáp ứng các yêu cầu này. Xem android.ext.services.notification để xem ví dụ.

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

3.8.4. API hỗ trợ

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

Nếu các quá trình triển khai thiết bị hỗ trợ hành động Hỗ trợ, chúng:

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

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

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

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

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

3.8.6. Giao diện

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

Android bao gồm API "Holo" và "Material" nhóm giao diện dưới dạng một tập hợp các kiểu đã xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn phù hợp với Giao diện chủ đề Holo như được xác định bởi SDK Android.

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

[C-1-1] KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính chủ đề Holo nào được hiển thị cho .
[C-1-2] PHẢI hỗ trợ "Material" họ chủ đề và KHÔNG ĐƯỢC thay đổi bất kỳ các thuộc tính giao diện Material hoặc tài sản của chúng hiển thị với các ứng dụng.
[C-1-3] PHẢI đặt "sans-serif" bộ phông chữ thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ hoặc cung cấp một thuộc tính tương tác cho người dùng để thay đổi phông chữ được sử dụng cho "sans-serif" bộ phông chữ thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ.
[C-1-4] PHẢI tạo bảng sắc độ màu động như đã chỉ định trong AOSP (Dự án nguồn mở Android) tài liệu của Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (xem android.theme.customization.system_palette và android.theme.customization.theme_style).
[C-1-5] PHẢI tạo bảng sắc độ màu động bằng cách sử dụng kiểu giao diện màu được liệt kê trong Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES tài liệu (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 cùng android.theme.customization.system_palette (như được ghi trong tài liệu 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 qua com.android.systemui.monet.ColorScheme#getSeedColors, cung cấp nhiều màu nguồn hợp lệ để chọn một màu.
- NÊN sử dụng giá trị 0xFF1B6EF3, nếu không có màu nào được cung cấp phù hợp yêu cầu màu sắc nguồn ở trên.

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

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

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

Nếu quá trình triển khai thiết bị có thanh trạng thái hệ thống, thì quá trình triển khai thiết bị sẽ:

[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) và thông báo mà hệ thống đưa ra, trừ phi biểu tượng cho biết trạng thái có vấn đề hoặc ứng dụng yêu cầu thanh trạng thái sáng bằng cách sử dụng WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS cờ.
[C-2-2] Các triển khai thiết bị Android PHẢI thay đổi màu sắc của hệ thống biểu tượng trạng thái 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 một thanh trạng thái sáng.

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

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

Phần cứng được coi là có khả năng chạy hình nền động ổn định nếu có thể chạy tất cả hình nền động, không có giới hạn về chức năng, ở một khung hình hợp lý mà không gây ảnh hưởng bất lợi đến các ứng dụng khác. Nếu những hạn chế trong phần phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, trục trặc, tiêu hao công suất CPU hay pin quá mức hoặc chạy ở tốc độ khung hình thấp không thể chấp nhận được, 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 sử dụng hình nền động trong ngữ cảnh OpenGL có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.

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

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

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

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

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

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

Nếu các hoạt động triển khai thiết bị bao gồm phím điều hướng chức năng gần đây như được nêu chi tiết trong phần 7.2.3 thay đổi giao diện, chúng:

[C-1-1] PHẢI hỗ trợ tối đa tối đa 7 hoạt động được hiển thị.
NÊN hiển thị ít nhất tiêu đề của 4 hoạt động cùng lúc.
PHẢI hiển thị màu đánh dấu, biểu tượng, tiêu đề màn hình gần đây.
NÊN hiển thị một thành phần đóng ("x") nhưng CÓ THỂ trì hoãn điều 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 phím tắt để dễ dàng chuyển về hoạt động trước đó.
NÊN kích hoạt hành động chuyển đổi nhanh giữa hai hành động được sử dụng gần đây nhất ứng dụng, khi phím chức năng gần đây được nhấn 2 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 Bạn nhấn và giữ phím gần đây của các hàm gần đây.
CÓ THỂ hiển thị các thành phần 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] Are Để chỉ định người dùng Android ngược dòng, (hoặc giao diện dựa trên hình thu nhỏ tương tự) cho màn hình tổng quan.

3.8.9. Quản lý dữ liệu đầu vào

Android có hỗ trợ cho Quản lý dữ liệu đầ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 quá trình triển khai thiết bị cho phép người dùng sử dụng các phương thức nhập của bên thứ ba trên thiết bị, họ:

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

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

API ứng dụng điều khiển từ xa không còn được dùng từ Android 5.0 và thay vào đó là Mẫu thông báo nội dung nghe nhìn cho phép các ứng dụng đa phương tiện tích hợp với bộ điều khiển chế độ phá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à Giấc mơ)

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

3.8.12. Vị trí

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

[C-1-2] PHẢI hiển thị current status of location (trạng thái hiện tại của vị trí) trong trình đơn Vị trí trong Cài đặt.
[C-1-3] KHÔNG ĐƯỢC hiển thị chế độ vị trí trong trình đơn Vị trí trong 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 quá trình triển khai thiết bị bao gồm một màn hình hoặc đầu ra video, thì chúng:

[C-1-1] PHẢI có khả năng kết xuất các ký tự biểu tượng cảm xúc này bằng ký tự màu.
[C-1-2] PHẢI bao gồm dịch vụ hỗ trợ cho:
- Phông chữ Roboto 2 có các độ đậm khác nhau—sans-serif-thin, Sans-serif-light, Sans Serifs Trung bình, Sans Serif- Đen, Sans Serif Độ đậm nhạt, Sans-serif-condensed-light cho các ngôn ngữ có sẵn trên thiết bị.
- Bản đầy đủ Unicode 7.0 bao gồm tiếng Latinh, tiếng Hy Lạp và chữ Kirin, bao gồm Các phạm vi A, B, C và D của chữ Latinh mở rộng và tất cả ký tự trong đơn vị tiền tệ khối ký hiệu 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. (Có thể thêm phông chữ biểu tượng cảm xúc mới để ghi đè biểu tượng cảm xúc trong NotoColorEmoji.tff)
NÊN hỗ trợ màu da và biểu tượng cảm xúc đa dạng về gia đình như được nêu trong Báo cáo kỹ thuật Unicode #51.

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

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

Android có hỗ trợ hiển thị phông chữ Myanmar. Myanmar có một số Phông chữ không tương thích với Unicode, thường được gọi là "Zawgyi", để kết xuất Myanmar ngôn ngữ.

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

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

3.8.14. Nhiều cửa sổ

Nếu các phương thức triển khai thiết bị có khả năng hiển thị nhiều hoạt động tại cùng một lúc, chú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 SDK Android tài liệu hỗ trợ về chế độ nhiều cửa sổ và đáp ứng các yêu cầu sau:
[C-1-2] PHẢI tôn trọng android:resizeableActivity do một ứng dụng thiết lập trong tệp AndroidManifest.xml như mô tả trong SDK này.
[C-1-3] KHÔNG ĐƯỢC cung cấp chế độ chia đôi màn hình hoặc chế độ dạng tự do nếu chiều cao màn hình thấp 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 220dp chế độ nhiều cửa sổ khác với Hình trong hình.
Các quá trình triển khai thiết bị có kích thước màn hình xlarge NÊN hỗ trợ dạng tự do .

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

[C-2-2] PHẢI cắt hoạt động ở vị trí cố định 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, 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ủ AndroidManifestLayout_minWidth đã khai báo và AndroidManifestLayout_minHeight các giá trị 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 vào đế sạc.

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

[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 mục tiêu API cấp 26 trở lên và khai báo android:supportsPictureInPicture * Nhắm mục tiêu 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 của họ dưới dạng được chỉ định theo hoạt động PIP hiện tại thông qua setActions() API.
[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, được xác định bởi hoạt động PIP qua setAspectRatio() API.
[C-3-4] PHẢI sử dụng KeyEvent.KEYCODE_WINDOW để kiểm soát cửa sổ PIP; nếu chế độ PIP không được triển khai, khoá PHẢI là có sẵn cho hoạt động trên nền trước.
[C-3-5] PHẢI cung cấp thuộc tính tương tác của người dùng để chặn không cho ứng dụng hiển thị trong Chế độ PIP; việc triển khai AOSP đáp ứng yêu cầu này bằng cách có 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 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ông phải là 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.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị bao gồm nhiều hoạt động tương thích với Android khu vực hiển thị và cung cấp các khu vực đó cho ứng dụng, chúng:

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

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

[C-5-1] PHẢI triển khai phiên bản chính xác của Tiện ích Trình quản lý cửa sổ Cấp độ API như được mô tả trong Tiện ích WindowManager.

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

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

Nếu quá trình triển khai thiết bị có chứa(các) vết cắt trên màn hình, thì chúng:

[C-1-5] KHÔNG ĐƯỢC có(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 thực hiện đúng các cờ cắt trên màn hình do ứng dụng đặt thông qua WindowManager.LayoutParams API theo mô tả trong SDK.
[C-1-4] PHẢI báo cáo giá trị chính xác cho tất cả các chỉ số vết cắt được xác định trong DisplayCutout.

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

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

Xem Phần 2_2_3 để biết các yêu cầu dành riêng cho thiết bị.

3.8.17. Bảng nhớ tạm

Triển khai thiết bị:

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

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

[C-1-1] PHẢI loại bỏ bản xem trước có thể nhìn thấy người dùng

Phương thức triển khai tham chiếu AOSP đáp ứng các yêu cầu về bảng nhớ tạm này.

3,9. Quản trị thiết bị

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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

Nếu các triển khai thiết bị triển khai toàn bộ tính năng quản trị thiết bị các chính sách được xác định trong tài liệu về SDK Android, chúng:

[C-1-1] PHẢI khai báo android.software.device_admin.

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

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

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

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

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

[C-1-1] PHẢI hỗ trợ đăng ký Device Policy Client (DPC) làm người dùng Ứng dụng Chủ sở hữu thiết bị như mô tả dưới đây:
- Khi quá trình triển khai thiết bị có cả người dùng lẫn định cấu hình dữ liệu người dùng:
  - [C-1-5] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị hoặc bật ứng dụng DPC để chọn xem hãy 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) qua cờ tính năng android.hardware.nfc và nhận thông báo NFC chứa một bản ghi thuộc loại MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] PHẢI gửi ACTION_GET_PROVISIONING_MODE ý định sau khi cấp phép chủ sở hữu thiết bị được kích hoạt để Ứng dụng DPC có thể chọn trở thành Chủ sở hữu thiết bị hoặc Hồ sơ Chủ sở hữu, tuỳ thuộc vào giá trị của android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, trừ khi có thể xác định được từ trong bối cảnh chỉ có một lựa chọn hợp lệ.
  - [C-1-9] PHẢI gửi ACTION_ADMIN_POLICY_COMPLIANCE ý định đối với ứ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 khi cấp phép, bất kể sử dụng phương thức cấp phép nào. Chiến lược phát hành đĩa đơn người dùng không thể tiếp tục trong Trình hướng dẫn thiết lập cho đến khi Ứng dụng của Chủ sở hữu thiết bị hoàn tất.
- Khi quá trình triển khai thiết bị có hay dữ liệu người dùng, dữ liệu này:
  - [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ị khác.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-2] PHẢI hiển thị thông báo công bố phù hợp (như được tham chiếu trong AOSP (Dự án nguồn mở Android)) và có được sự đồng ý rõ ràng của người dùng cuối trước khi mở ứng dụng được đặt làm Chủ sở hữu thiết bị, trừ phi thiết bị được định cấu hình theo cách lập trình dành cho Chế độ giới thiệu bán lẻ trước khi người dùng cuối tương tác trên màn hình. Nếu quá trình triển khai thiết bị khai báo android.software.device_admin, nhưng cũng có quyền sở hữu riêng giải pháp quản lý thiết bị và cung cấp một cơ chế để quảng bá một ứng dụng được định cấu hình trong giải pháp của họ với vai trò là "Chủ sở hữu thiết bị tương đương" thành "Chủ sở hữu thiết bị" tiêu chuẩn theo tiêu chuẩn Android DevicePolicyManager các API, chúng:

[C-2-1] PHẢI có một quy trình để xác minh rằng ứng dụng cụ thể đang được quảng bá thuộc về một ứng dụng quản lý thiết bị hợp pháp của doanh nghiệp và đã được định cấu hình trong giải pháp độc quyền có các quyền tương đương với vai trò là "Chủ sở hữu thiết bị".

[C-2-2] PHẢI hiển thị cùng một thông tin công bố về sự đồng ý của Chủ sở hữu thiết bị AOSP là luồng do android.app.action.PROVISION_MANAGED_DEVICE khởi tạo trước khi đăng ký ứng dụng DPC làm "Chủ sở hữu thiết bị".

[C-2-3] KHÔNG ĐƯỢC DÙNG cứng mã cho sự đồng ý hoặc ngăn chặn việc sử dụng các ứng dụng khác của chủ sở hữu thiết bị.

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

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

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

[C-1-1] PHẢI triển khai các 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.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-2] Quy trình cấp phép hồ sơ được quản lý (quy trình do DPC khởi tạo bằng cách sử dụng android.app.action.PROVISION_MANAGED_PROFILE) hoặc theo nền tảng), màn hình đồng ý và trải nghiệm người dùng PHẢI phù hợp cách triển khai AOSP.

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

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

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

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

[C-1-1] PHẢI hỗ trợ hồ sơ được quản lý qua android.app.admin.DevicePolicyManager API.
[C-1-2] PHẢI cho phép một và chỉ một hồ sơ được quản lý được tạo.
[C-1-3] PHẢI sử dụng huy hiệu biểu tượng (tương tự như huy hiệu công việc ngược dòng của AOSP) để đại diện cho các ứng dụng và tiện ích được quản lý cũng như các thành phần có huy hiệu khác trên giao diện người dùng như Gần đây và Thông báo.
[C-1-4] PHẢI hiển thị biểu tượng thông báo (tương tự như công việc ngược dòng của AOSP) huy hiệu) để cho biết thời điểm người dùng sử dụng ứng dụng hồ sơ được quản lý.
[C-1-5] PHẢI hiển thị thông báo ngắn cho biết người dùng đang ở trong hồ sơ nếu và khi thiết bị khởi động (ACTION_USER_PRESENT) và ứng dụng trên nền trước nằm trong hồ sơ được quản lý.
[C-1-6] Khi có hồ sơ được quản lý, PHẢI hiển thị một thuộc tính tương tác trực quan trong "Người chọn" ý định để cho phép người dùng chuyển tiếp ý định từ hồ sơ cho người dùng chính hoặc ngược lại, nếu được bật theo Chính sách thiết bị Bộ điều khiển.
[C-1-7] Khi có hồ sơ được quản lý, PHẢI hiển thị người dùng sau thành phần cho cả người dùng chính và hồ sơ được quản lý:
- Xem xét riêng rẽ mức sử dụng pin, vị trí, dữ liệu di động và bộ nhớ cho người dùng chính và hồ sơ được quản lý.
- Quản lý độc lập các Ứng dụng VPN được cài đặt trong chính người dùng hoặc hồ sơ được quản lý.
- Quản lý độc lập các ứng dụng được cài đặt trong người dùng chính hoặc hồ sơ được quản lý.
- Khả năng quản lý độc lập các tài khoản trong phạm vi người dùng chính hoặc người dùng được quản lý hồ sơ.
[C-1-8] PHẢI đảm bảo trình quay số, danh bạ và tính năng nhắn tin được cài đặt trước có thể tìm kiếm và tra cứu thông tin người gọi từ hồ sơ (nếu có) cùng với các hồ sơ từ hồ sơ chính, nếu Trình kiểm soát chính sách thiết bị cho phép việc này.
[C-1-9] PHẢI đảm bảo đáp ứng tất cả các yêu cầu về bảo mật áp dụng cho thiết bị đã bật tính năng nhiều người dùng (xem phần 9.5), mặc dù hồ sơ được quản lý sẽ 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 dữ liệu ảnh chụp màn hình được lưu trong hồ sơ công việc Khi bạn chụp ảnh màn hình bằng topActivity cửa sổ có tiêu điểm (hoạt động mà người dùng tương tác gần đây nhất trong số tất cả các hoạt động) và thuộc về ứng dụng hồ sơ công việc.
[C-1-11] KHÔNG ĐƯỢC chụp bất kỳ nội dung 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 trên hồ sơ cá nhân) ngoại trừ hồ sơ công việc cửa sổ/cửa sổ ứng dụng khi lưu ảnh chụp màn hình vào hồ sơ công việc (để đảm bảo rằng không được lưu trong 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, họ:

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

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

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

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

Nếu quá trình triển khai thiết bị khai báo android.software.device_admin và cung cấp tương tác với người dùng trên thiết bị để thêm Người dùng phụ bổ sung, họ:

[C-SR-1] AreĐể đề xuất cho thấy cùng một sự đồng ý của Chủ sở hữu thiết bị AOSP (Dự án nguồn mở Android) thông tin công bố được hiển thị trong quy trình do android.app.action.PROVISION_MANAGED_DEVICE, trước khi cho phép thêm tài khoản trong Người dùng phụ mới, để người dùng hiểu rằng thiết bị được quản lý.

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

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

[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. Ứng dụng giữ vai trò quản lý chính sách thiết bị CÓ THỂ được xác định bằng cách đặt config_devicePolicyManagement vào tên gói. Tên gói PHẢI đứng trước : và chứng chỉ ký trừ phi tải trước ứng dụng.

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

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

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

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

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

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

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

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

[C-1-1] PHẢI giải quyết xung đột chính sách thiết bị như được ghi trong tài liệu 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 bị khuyết tật thao tác trên thiết bị dễ dàng hơn. Ngoài ra, Android còn cung cấp các API nền tảng cho phép triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho người dùng và các sự kiện hệ thống cũng như 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 bi xoay/d-pad.

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

[C-1-1] PHẢI cung cấp cách triển khai tính năng hỗ trợ tiếp cận của Android như được mô tả trong API hỗ trợ tiếp cận Tài liệu về SDK.
[C-1-2] PHẢI tạo các sự kiện hỗ trợ tiếp cận và gửi những thông tin thích hợp AccessibilityEvent cho tất cả người dùng đã đăng ký AccessibilityService như được nêu trong SDK.
[C-1-4] PHẢI cung cấp khả năng tương tác của người dùng để điều khiển khả năng hỗ trợ tiếp cận các dịch vụ khai báo AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_NÚT. Xin lưu ý rằng đối với việc triển khai thiết bị có thanh điều hướng hệ thống, NÊN 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 để kiểm soát các dịch vụ này.

Nếu quá trình triển khai thiết bị có bao gồm các dịch vụ hỗ trợ tiếp cận được cài đặt trước, thì các dịch vụ đó:

[C-2-1] PHẢI triển khai các dịch vụ hỗ trợ tiếp cận được cài đặt trước này dưới dạng Nhận biết tính năng khởi động trực tiếp khi bộ lưu trữ dữ liệu được mã hóa bằng Mã hóa dựa trên tệp (FBE).
NÊN cung cấp một cơ chế trong quy trình thiết lập bên ngoài để người dùng bật các dịch vụ hỗ trợ tiếp cận phù hợp cũng như các tuỳ chọn để điều chỉnh cỡ chữ, kích thước màn hình và cử chỉ thu phóng.

3,11. Chuyển văn bản thành giọng nói

Android bao gồm các API cho phép ứng dụng sử dụng tính năng chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ cung cấp các triển khai TTS luôn miễn phí.

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

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

Nếu các quá trình triển khai thiết bị có hỗ trợ cài đặt công cụ TTS của bên thứ ba, thì các thiết bị đó sẽ:

[C-2-1] PHẢI cung cấp thuộc tính tương tác của người dùng để cho phép người dùng chọn TTS để sử dụng ở cấp hệ thống.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

3,12. Khung đầu vào TV

Khung đầu vào truyền hình Android (TIF) giúp đơn giản hoá phân phối nội dung trực tiếp đến các thiết bị Android TV. TIF cung cấp tiêu chuẩn API để tạo các mô-đun đầu vào điều khiển thiết bị Android TV.

Nếu quá trình triển khai thiết bị hỗ trợ TIF, thì các quy trình triển khai đó:

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

[C-1-2] PHẢI hỗ trợ tất cả các API TIF sao cho một ứng dụng sử dụng các API này và thông tin đầu vào dựa trên TIF của bên thứ ba dịch vụ có thể được cài đặt và sử dụng trên thiết bị.

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

3,13. Cài đặt nhanh

Android cung cấp thành phần giao diện người dùng Cài đặt nhanh cho phép truy cập nhanh vào những hành động thường dùng hoặc cần thiết.

Nếu quá trình triển khai thiết bị có bao gồm thành phần giao diện người dùng Cài đặt nhanh và có hỗ trợ bên thứ ba Trình đơn Cài đặt nhanh:

[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 quicksettings API từ một ứng dụng bên thứ ba.
[C-1-2] KHÔNG ĐƯỢC tự động thêm trực tiếp thẻ thông tin từ ứng dụng bên thứ ba vào trình đơn Cài đặt nhanh.
[C-1-3] PHẢI hiển thị tất cả ô do người dùng thêm từ ứng dụng của bên thứ ba bên cạnh các ô cài đặt nhanh do hệ thống cung cấp.

3,14. Giao diện người dùng nội dung đa phương tiện

Nếu quá trình triển khai thiết bị bao gồm các ứng dụng không được kích hoạt bằng giọng nói (Ứng dụng) tương tác với ứng dụng của bên thứ ba thông qua MediaBrowser hoặc MediaSession, Ứng dụng:

[C-1-2] PHẢI hiển thị rõ ràng các biểu tượng thu được qua getIconBitmap() hoặc getIconUri() và tiêu đề thu được qua getTitle() như được 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ụ: sự phân tâm của người lái xe).
[C-1-3] PHẢI hiển thị biểu tượng ứng dụng của bên thứ ba bất cứ khi nào hiển thị nội dung được cung cấp bởi ứng dụng bên thứ ba này.
[C-1-4] PHẢI cho phép người dùng tương tác với toàn bộ MediaBrowser thứ bậc. CÓ THỂ hạn chế quyền truy cập vào một phần hệ thống phân cấp để 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), nhưng KHÔNG ĐƯỢC ưu tiên đối xử dựa trên nội dung hoặc nhà cung cấp nội dung của Google.
[C-1-5] PHẢI xem xét nhấn đúp của KEYCODE_HEADSETHOOK hoặc KEYCODE_MEDIA_PLAY_PAUSE dưới tên KEYCODE_MEDIA_NEXT cho MediaSession.Callback#onMediaButtonEvent.

3,15. Ứng dụng tức thì

Nếu quá trình triển khai thiết bị hỗ trợ Ứng dụng tức thì, thì các quá trình triển khai thiết bị đó PHẢI đáp ứng các điều kiện sau các yêu cầu:

[C-1-1] Ứng dụng tức thì PHẢI chỉ được cấp các 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 ứng dụng đã cài đặt thông qua ý định ngầm ẩn trừ khi một trong các điều sau là đúng:
- Bộ lọc mẫu ý định của thành phần bị hiển thị và có CATEGORY_BROWSABLE
- Hành động là một trong các hành động sau: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Mục tiêu được hiển thị rõ ràng bằng android:visibleTo InstantApps
[C-1-3] Ứng dụng tức thì KHÔNG ĐƯỢC tương tác một cách rõ ràng với các ứng dụng đã cài đặt trừ khi thành phần được hiển thị thông qua android:visibleTo InstantApps.
[C-1-4] Ứng dụng đã cài đặt KHÔNG ĐƯỢC xem thông tin chi tiết về Ứng dụng tức thì trên trừ khi Ứng dụng tức thì kết nối rõ ràng với ứng dụng đã cài đặt.
Quá trình triển khai thiết bị PHẢI cung cấp các thành phần tương tác sau đây cho người dùng đối với tương tác với Ứng dụng tức thì. AOSP đáp ứng các yêu cầu với Giao diện người dùng hệ thống, 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 thuộc tính tương tác của người dùng để xem và xoá Ứng dụng tức thì được lưu vào bộ nhớ đệm cục bộ cho từng gói ứng dụng riêng lẻ.
- [C-1-6] PHẢI cung cấp một thông báo liên tục cho người dùng có thể thu gọn trong khi Ứng dụng tức thì đang chạy trên nền trước. Người dùng này thông báo PHẢI bao gồm việc Ứng dụng tức thì không yêu cầu cài đặt và cung cấp một thuộc tính tương tác cho người dùng để hướng người dùng đến ứng dụng màn hình thông tin trong phần Cài đặt. Đối với Ứng dụng tức thì được phát hành thông qua ý định web, như là được xác định bằng cách dùng một ý định với hành động được đặt thành Intent.ACTION_VIEW và bằng lược đồ "http" hoặc "https", một thành phần tương tác bổ sung cho người dùng NÊN cho phép người dùng không chạy Ứng dụng tức thì và khởi chạy liên kết được liên kết với trình duyệt web đã định cấu hình nếu trình duyệt có sẵn trên thiết bị.
- [C-1-7] PHẢI cho phép truy cập vào các Ứng dụng tức thì đang chạy từ mục Gần đây nếu thiết bị có hàm Recents (Gần đây).
[C-1-8] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định cho các ý định được liệt kê trong SDK tại đây và hiển thị ý định đó cho Ứng dụng tức thì.

3,16. Ghép nối thiết bị đồng hành

Android có hỗ trợ tính năng ghép nối thiết bị đồng hành để quản lý hiệu quả hơn liên kết với các thiết bị đồng hành và cung cấp CompanionDeviceManager API dành cho các ứng dụng để truy cập vào tính năng này.

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

[C-1-1] PHẢI khai báo cờ tính năng FEATURE_COMPANION_DEVICE_SETUP của Google.
[C-1-2] PHẢI đảm bảo các API trong android.companion được triển khai đầy đủ.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-3] PHẢI cung cấp thuộc tính tương tác của người dùng để người dùng chọn/xác nhận thiết bị đồng hành đang hoạt động và đang hoạt động, phải sử dụng cùng một thông báo như được triển khai trong AOSP mà không có thêm hoặc sửa đổi.

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

3.17. Ứng dụng nặng

Nếu quá trình triển khai thiết bị khai báo tính năng FEATURE_CANT_SAVE_STATE, thì họ:

[C-1-1] PHẢI chỉ có một ứng dụng được cài đặt chỉ định cantSaveState chạy trong hệ thống cùng một lúc. Nếu người dùng rời khỏi ứng dụng như vậy mà không thoát khỏi ứng dụng đó một cách rõ ràng (ví dụ: bằng cách nhấn Ở nhà khi rời khỏi một hoạt động đang hoạt động, hệ thống thay vì nhấn nút quay lại khi không còn hoạt động nào đang hoạt động trong hệ thống), sau đó quá trình triển khai thiết bị PHẢI ưu tiên ứng dụng đó trong RAM giống như các ứng dụng khác những tính năng dự kiến sẽ vẫn chạy, chẳng hạn như dịch vụ trên nền trước. Khi một ứng dụng như vậy chạy trong nền, hệ thống vẫn có thể cấp nguồn tính năng quản lý, chẳng hạn như giới hạn quyền truy cập CPU và mạng.
[C-1-2] PHẢI cung cấp thuộc tính tương tác trên giao diện người dùng để chọn ứng dụng không được 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 cantSaveState .
[C-1-3] KHÔNG ĐƯỢC áp dụng các thay đổi khác trong chính sách cho những ứng dụng chỉ định cantSaveState! chẳng hạn như thay đổi hiệu suất của CPU hoặc thay đổi mức độ ưu tiên của việc lập lịch biểu.

Nếu quá trình triển khai thiết bị không khai báo tính năng này FEATURE_CANT_SAVE_STATE! thì họ:

[C-1-1] PHẢI bỏ qua cantSaveState do ứng dụng đặt và KHÔNG ĐƯỢC thay đổi hành vi của ứng dụng dựa trên đó .

3,18. Danh bạ

Android bao gồm Contacts Provider Các API 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 người liên hệ được nhập trực tiếp vào thiết bị thường được đồng bộ hóa với dịch vụ web, nhưng dữ liệu CÓ THỂ cũng 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à cục bộ danh bạ.

RAWContact (Danh bạ thô) được "liên kết với" hoặc "lưu trữ trong" một Tài khoản khi ACCOUNT_NAME, và ACCOUNT_TYPE, cho các địa chỉ liên hệ thô khớp với Account.name và Account.type của tài khoản.

Tài khoản cục bộ mặc định: tài khoản cho các danh bạ thô chỉ được lưu trữ trên thiết bị và không được liên kết với một Tài khoản trong AccountManager, được tạo với các giá trị null cho thuộc tính ACCOUNT_NAME, và ACCOUNT_TYPE, .

Tài khoản tuỳ chỉnh trên máy: tài khoản cho các mục liên hệ thô chỉ được lưu trữ trên và không được liên kết với một Tài khoản trong AccountManager, tức là được tạo với ít nhất một giá trị khác rỗng cho thuộc tính ACCOUNT_NAME, và ACCOUNT_TYPE, .

Triển khai thiết bị:

[C-SR-1] AreĐể chỉ định không tạo các tài khoản cục bộ tuỳ chỉnh.

Nếu hoạt động 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ởi ContactsContract.RawContacts.getLocalAccountName
[C-1-2] ACCOUNT_TYPE! của tài khoản cục bộ tuỳ chỉnh PHẢI được trả về bởi ContactsContract.RawContacts.getLocalAccountType
[C-1-3] Danh bạ thô được các ứng dụng bên thứ ba chèn vào tài khoản cục bộ mặc định (tức là bằng cách đặt giá trị rỗng cho ACCOUNT_NAME và ACCOUNT_TYPE) PHẢI được chèn vào dữ liệu cục bộ tuỳ chỉnh tài khoản.
[C-1-4] Các liên hệ thô được chèn vào tài khoản cục bộ tuỳ chỉnh KHÔNG ĐƯỢC bị xóa khi thêm hoặc xóa tài khoản.
[C-1-5] Xoá các thao tác đượ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 địa chỉ liên hệ thô bị xoá ngay lập tức (như thể CALLER_IS_SYNCADAPTER thông số đã được đặt thành true), ngay cả khi thông số CALLER\_IS\_SYNCADAPTER đã được đặt thành false hoặc không được chỉ định.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

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ỳ tương tác người dùng nào để chọn giới tính cụ thể xử lý ngôn ngữ cho các ngôn ngữ không hỗ trợ giới tính cụ thể bản dịch. Xem tài nguyên ngữ pháp để biết thêm thông tin.

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

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

Triển khai thiết bị:

[C-0-1] PHẢI có khả năng cài đặt và chạy Android ".apk" tệp dưới dạng tạo bởi "aapt" có trong SDK Android chính thức.
- Do yêu cầu ở trên có thể gây khó khăn, việc triển khai thiết bị NÊN sử dụng tính năng quản lý gói của hoạt động triển khai tham chiếu AOSP (Dự án nguồn mở Android) hệ thống.
[C-0-2] PHẢI hỗ trợ xác minh ".apk" bằng cách sử dụng Lược đồ chữ ký APK phiên bản 3.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 một trong hai .apk, Tệp kê khai Android, Mã byte Dalvik hoặc Định dạng mã byte RenderScript theo cách có thể ngăn những tệp đó cài đặt và chạy chính xác trên các thiết bị tương thích khác.
[C-0-4] KHÔNG ĐƯỢC cho phép các ứng dụng khác với ứng dụng hiện tại "người cài đặt bản ghi" để gói tự động gỡ cài đặt ứng dụng mà không xác nhận của người dùng, như được ghi trong SDK cho DELETE_PACKAGE quyền. Ngoại lệ duy nhất là việc xử lý ứng dụng trình xác minh gói hệ thống PACKAGE_NEEDS_VERIFICATION ý định và cách xử lý ứng dụng trình quản lý bộ nhớ ACTION_MANAGE_STORAGE ý định.
[C-0-5] PHẢI có một hoạt động xử lý android.settings.MANAGE_UNKNOWN_APP_SOURCES ý định.
[C-0-6] KHÔNG ĐƯỢC cài đặt gói ứng dụng không xác định nguồn, trừ khi ứng dụng yêu cầu cài đặt đáp ứng tất cả các yêu cầu sau:
- Hàm PHẢI khai báo REQUEST_INSTALL_PACKAGES hoặc đặt android:targetSdkVersion ở mức 24 trở xuống.
- Phải được người dùng cấp quyền cài đặt ứng dụng từ nguồn không xác định.
NÊN cung cấp một thuộc tính tương tác cho người dùng để cấp/thu hồi quyền cho cài đặt các ứng dụng không rõ nguồn gốc cho mỗi ứng dụng, nhưng CÓ THỂ chọn triển khai lượt chuyển đổi này là không hoạt động và trả lại 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ọ PHẢI cho người dùng biết lý do không có đưa ra lựa chọn đó.
[C-0-7] PHẢI hiển thị hộp thoại cảnh báo kèm theo 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 một ứng dụng đã được đánh dấu bằng cùng một API hệ thống PackageManager.setHarmfulAppWarning có hại.
NÊN cung cấp thuộc tính tương tác cho người dùng để chọn gỡ cài đặt hoặc khởi chạy trên hộp thoại cảnh báo.
[C-0-8] PHẢI triển khai hỗ trợ cho Hệ thống tệp tăng dần như đã nêu trong tài liệu tại đây.
[C-0-9] PHẢI hỗ trợ xác minh tệp .apk bằng APK Signature Scheme v4 và Lược đồ chữ ký APK v4.1.

5. Khả năng tương thích đa phương tiện

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ các định dạng phương tiện truyền thông, bộ mã hoá, bộ giải mã, loại tệp, và định dạng vùng chứa được xác định trong phần 5.1 cho mỗi và mọi bộ mã hoá và giải mã do MediaCodecList khai báo.
[C-0-2] PHẢI khai báo và báo cáo hỗ trợ của các bộ mã hoá, bộ giải mã có sẵn đến các ứng dụng của bên thứ ba qua MediaCodecList.
[C-0-3] PHẢI có khả năng giải mã đúng cách và cung cấp cho bên thứ ba tất cả các định dạng mà nó có thể mã hoá. Bao gồm tất cả các luồng bit mà và các hồ sơ được báo cáo trong CamcorderProfile.

Triển khai thiết bị:

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

Tất cả bộ mã hoá và giải mã được liệt kê trong phần bên dưới đều được cung cấp dưới dạng phần mềm trong quá trình triển khai Android ưu tiên từ Android Open Dự án nguồn.

Xin lưu ý rằng cả Google và Open Handset Alliance đều không thực hiện bất kỳ tuyên bố rằng các bộ mã hoá và giải mã này không có bằng sáng chế của bên thứ ba. Những có ý đị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 thì nên việc triển khai mã này, bao gồm cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ 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 đa phương tiện

5.1.1. Mã hoá âm thanh

Xem thêm thông tin chi tiết trong 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 android.hardware.microphone, chúng PHẢI hỗ trợ mã hoá và cung cấp các định dạng âm thanh sau cho các ứng dụng bên thứ ba:

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

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

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

5.1.2. Giải mã âm thanh

Xem thêm thông tin chi tiết trong 5.1.3. Thông tin chi tiết về bộ mã hoá và giải mã âm thanh.

Nếu quá trình triển khai thiết bị khai báo hỗ trợ cho android.hardware.audio.output, chúng phải hỗ trợ giải mã các định dạng âm thanh sau:

[C-1-1] Cấu hình MPEG-4 AAC (AAC LC)
[C-1-2] Cấu hình MPEG-4 HE AAC (AAC+)
[C-1-3] Cấu hình MPEG-4 HE AACv2 (AAC nâng cao)
[C-1-4] AAC ELD (AAC độ trễ thấp nâng cao)
[C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, bao gồm Hồ sơ cơ sở của USAC và Dải động ISO/IEC 23003-4 Kiểm soát)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE bao gồm âm thanh độ 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ỉ để giải mã và một thiết bị được phép thu thập mẫu và giảm độ phối cảnh trong giai đoạn phát lại.
[C-1-10] Opus

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

[C-2-1] Giải mã PHẢI được thực hiện mà không cần trộn trộn (ví dụ: 5.0 AAC Luồng phải được giải mã sang năm kênh PCM, luồng 5.1 AAC phải được giải mã 6 kênh PCM).
[C-2-2] Siêu dữ liệu dải động PHẢI được định nghĩa trong "Điều khiển dải động (Cộng hòa dân chủ) 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. Chiến lược phát hành đĩa đơn Khoá AAC DRC được ra mắt trong API 21 và: 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] Nó được tôi đề xuất rằng các yêu cầu C-2-1 và C-2-2 ở trên là tất cả các bộ giải mã âm thanh AAC đều hài lòng.

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 MPEG-D DRC Dynamic Range Control Profile Level 1.
[C-3-2] Bộ giải mã PHẢI hoạt động theo cấu hình được thiết lập bằng các khoá android.media.MediaFormat sau: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL và KEY_AAC_DRC_EFFECT_TYPE.

Bộ giải mã cấu hình MPEG-4 AAC, HE AAC và HE AACv2:

CÓ THỂ hỗ trợ kiểm soát độ ồn và dải động theo ISO/IEC 23003-4 Cấu hình kiểm soát dải động.

Nếu ISO/IEC 23003-4 được hỗ trợ và nếu cả ISO/IEC 23003-4 và Siêu dữ liệu ISO/IEC 14496-3 có trong luồng bit được giải mã, sau đó:

Siêu dữ liệu ISO/IEC 23003-4 SẼ được ưu tiên.

Tất cả bộ giải mã âm thanh PHẢI hỗ trợ đầu ra:

[C-6-1] Các khung âm thanh thứ tự byte gốc 16 bit PCM qua android.media.MediaCodec API.

[C-7-1] PHẢI có thể được ứng dụng định cấu hình bằng cách sử dụng bộ giải mã bằng khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát xem có phối lại nội dung thành âm thanh nổi hay không (khi sử dụng giá trị là 2) hoặc là đầu ra bằng số kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình một bộ giải mã để xuất ra 6 kênh khi cho ăn nội dung 5.1.
[C-7-2] Khi giải mã, bộ giải mã PHẢI quảng cáo mặt nạ kênh đang được sử dụng cho định dạng đầu ra KEY_CHANNEL_MASK khoá, sử dụng các hằng số android.media.AudioFormat (ví dụ: CHANNEL_OUT_5POINT1).

Nếu quá trình triển khai thiết bị có hỗ trợ bộ giải mã âm thanh không phải là AAC mặc định và có khả năng xuất âm thanh đa kênh (tức là 2 kênh) khi được cung cấp nội dung đa kênh dạng nén, thì:

[C-SR-2] Bộ giải mã là tôi liệt kê như vậy để có thể được định cấu hình bởi bằng cách sử dụng bộ giải mã với khoá KEY_MAX_OUTPUT_CHANNEL_COUNT để kiểm soát xem có phối lại nội dung thành âm thanh nổi hay không (khi sử dụng giá trị là 2) hoặc là đầu ra bằng số kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình một bộ giải mã để xuất ra 6 kênh khi cho ăn nội dung 5.1.
[C-SR-3] Khi giải mã, bộ giải mã là tôi liệt kê các thành phần được đề xuất để quảng cáo mặt nạ kênh đang được sử dụng trên định dạng đầu ra với KEY_CHANNEL_MASK khoá, bằng cách sử dụng các hằng số android.media.AudioFormat (ví dụ: CHANNEL_OUT_5POINT1).

5.1.3. Chi tiết về bộ mã hoá và giải mã âm thanh

Định dạng/Codec	Thông tin chi tiết	Loại tệp/Định dạng vùng chứa được hỗ trợ
Cấu hình MPEG-4 AAC (AAC LC)	Hỗ trợ nội dung mono/stereo/5.0/5.1 với tiêu chuẩn tốc độ lấy mẫu từ 8 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS thô AAC (.aac, ADIF không được hỗ trợ) MPEG-TS (.ts, không thể tìm kiếm, chỉ giải mã) Matroska (.mkv, chỉ giải mã)
Cấu hình MPEG-4 HE AAC (AAC+)	Hỗ trợ nội dung mono/stereo/5.0/5.1 với tiêu chuẩn tốc độ lấy mẫu từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Cấu hình (AAC nâng cao+)	Hỗ trợ nội dung mono/stereo/5.0/5.1 với tiêu chuẩn tốc độ lấy mẫu từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC độ trễ thấp nâng cao)	Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC (Hoa Kỳ)	Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu chuẩn từ 7,35 lên 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 đến 12,2 kb/giây được lấy mẫu tại 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ại 16 kHz, như được xác định tại AMR-WB, Thích ứng nhiều giá trị – Bộ mã hoá và giải mã lời nói băng tần rộng	3GPP (.3gp)
FLAC	Đối với cả bộ mã hoá và bộ giải mã: phải có ít nhất chế độ Đơn âm và Âm thanh nổi được hỗ trợ. Tốc độ lấy mẫu lên đến 192 kHz PHẢI được hỗ trợ; 16 bit và 24 bit PHẢI được hỗ trợ. Xử lý dữ liệu âm thanh 24 bit FLAC PHẢI có sẵn với 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	Đơn âm/âm thanh nổi 8-320Kbps hằng số (CBR) hoặc tốc độ bit biến (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, chỉ giải mã) Matroska (.mkv, chỉ giải mã)
MIDI	Loại MIDI 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF trên thiết bị di động. Hỗ trợ cho đị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 mono, stereo, 5.0 và 5.1 có lấy mẫu tốc độ 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/SÓNG	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. SÓNG trình trích xuất phải hỗ trợ PCM 16-bit, 24-bit, 32-bit tuyến tính và 32-bit float (tốc độ tối đa là 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 mono, stereo, 5.0 và 5.1 với tốc độ lấy mẫu 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 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 5.1.6. Thông tin chi tiết về bộ mã hoá và giải mã hình ảnh.

Các quá trình triển khai thiết bị PHẢI hỗ trợ mã hoá phương thức mã hoá hình ảnh sau đây:

[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 quá trình triển khai thiết bị có hỗ trợ mã hoá HEIC qua android.media.MediaCodec cho loại nội dung đa phương tiện MIMETYPE_IMAGE_ANDROID_HEIC, chúng:

[C-1-1] PHẢI cung cấp bộ mã hoá mã hoá HEVC được tăng tốc phần cứng hỗ trợ BITRATE_MODE_CQ chế độ kiểm soát tốc độ bit, 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 5.1.6. Thông tin chi tiết về bộ mã hoá và giải mã hình ảnh.

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

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

Nếu quá trình triển khai cho thiết bị có hỗ trợ giải mã video HEVC thì:

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

Bộ giải mã hình ảnh hỗ trợ định dạng độ sâu bit cao (9+ bit mỗi kênh):

[C-2-1] PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu được yêu cầu bởi ứng dụng, ví dụ: thông qua ARGB_8888 cấu hình của android.graphics.Bitmap.

5.1.6. Chi tiết về bộ mã hoá và giải mã hình ảnh

Định dạng/Codec	Thông tin chi tiết	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		Ảnh 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ình ảnh, Bộ sưu tập hình ảnh, Hồ sơ cơ sở trình tự hình ảnh	Vùng chứa HEIF (.avif)

Bộ mã hoá và bộ giải mã hình ảnh được hiển thị thông qua API MediaCodec

[C-1-1] PHẢI hỗ trợ YUV420 8:8:8 màu linh hoạt (COLOR_FormatYUV420Flexible) đến CodecCapabilities.
[C-SR-1] Internet ĐỀ XUẤT NÊN hỗ trợ định dạng màu RGB888 cho vùng hiển thị đầu vào .
[C-1-3] PHẢI hỗ trợ ít nhất một giá trị của mặt phẳng hoặc bán phẳng Định dạng màu YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (tương đương với COLOR_FormatYUV420Planar) hoặc COLOR_FormatYUV420PackedSemiPlanar (tương đương đến COLOR_FormatYUV420SemiPlanar). Họ ĐƯỢC ĐỀ XUẤT NÊN hỗ trợ cả hai.

5.1.7. Bộ mã hoá và giải mã video

Đảm bảo chất lượng hội nghị truyền hình và truyền trực tuyến video trên web ở mức chấp nhận được các dịch vụ, việc triển khai thiết bị PHẢI sử dụng bộ mã hoá và giải mã VP8 phần cứng đáp ứng yêu cầu.

Nếu quá trình triển khai thiết bị có bao gồm bộ giải mã hoặc bộ mã hoá video:

[C-1-1] Codec video PHẢI hỗ trợ kích thước bytebuffer đầu ra và đầu vào mà điều chỉnh cho phù hợp với khung nén và không nén lớn nhất khả thi theo chỉ dẫn 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ợ YUV420 8:8:8 màu linh hoạt (COLOR_FormatYUV420Flexible) đến CodecCapabilities.
[C-1-3] Bộ mã hoá và giải mã video PHẢI hỗ trợ ít nhất một trong hai bộ mã hoá, hoặc Định dạng màu bán phẳng YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (tương đương với COLOR_FormatYUV420Planar) hoặc COLOR_FormatYUV420PackedSemiPlanar (tương đương với COLOR_FormatYUV420SemiPlanar). Họ ĐƯỢC ĐỀ XUẤT NÊN hỗ trợ cả hai.
[C-SR-1] Bộ mã hoá và bộ giải mã video được tôi liệt kê để hỗ trợ ít nhất một trong những màu YUV420 phẳng hoặc bán phẳng được tối ưu hóa phần cứng 8:8:8 (YV12, NV12, NV21 hoặc định dạng được tối ưu hóa tương đương của nhà cung cấp.)
[C-1-5] Bộ giải mã video hỗ trợ định dạng độ 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 mà ứng dụng yêu cầu. Điều này PHẢI được phản ánh bằng cách hỗ trợ YUV420 định dạng màu 8:8:8 qua android.media.MediaCodecInfo.

Nếu các phương pháp triển khai thiết bị quảng cáo tính năng hỗ trợ hồ sơ HDR thông qua Display.HdrCapabilities! chúng:

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

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

[C-3-1] PHẢI hỗ trợ các giai đoạn làm mới trong phạm vi từ 10 - 60 khung hình và hoạt động chính xác trong vòng 20% thời gian làm mới được định cấu hình.

Trừ phi ứng dụng chỉ định khác bằng cách sử dụng KEY_COLOR_FORMAT khoá định dạ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á để hiển thị phần cứng nếu được định cấu hình bằng dữ liệu đầu ra của Surface.
[C-4-2] PHẢI mặc định là định dạng màu YUV420 8:8:8 tối ưu hóa cho CPU đọc nếu được định cấu hình để không sử dụng đầu ra của Surface.

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

Định dạng/Codec	Thông tin chi tiết	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	Xem phần 5.3 để biết 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 (Danh sách quảng cáo gốc)		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, chỉ giải mã)
Văn bản ảo (VP8)	Xem mục 5.2 và 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv)
Văn bản 9	Xem phần 5.3 để biết chi tiết	WebM (.webm) Matroska (.mkv)
AV1	Xem phần 5.2 và phần 5.3 để biết 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 đa phương tiện

Quá trình 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 đa phương tiện như mô tả bên dưới.

Android hỗ trợ OMX, 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 với mức hao tổn thấp.

Nếu quá trình triển khai thiết bị hỗ trợ nội dung nghe nhìn, thì các ứng dụng đó:

[C-1-1] PHẢI cung cấp hỗ trợ cho các bộ mã hoá và giải mã phương tiện thông qua OMX hoặc Codec 2.0 API (hoặc cả hai) như trong Dự án nguồn mở Android và không tắt hoặc né tránh các biện pháp bảo vệ bảo mật. Cụ thể, không có nghĩa là mỗi bộ mã hoá và giải mã PHẢI sử dụng API OMX hoặc Codec 2.0, chỉ hỗ trợ tối thiểu một trong các API này PHẢI khả dụng và hỗ trợ cho các API có sẵn PHẢI có các biện pháp bảo mật hiện có.
[C-SR-1] Are mã hóa NÊN bao gồm hỗ trợ cho Codec 2.0 API.

Nếu quá trình triển khai thiết bị không hỗ trợ API Codec 2.0, thì các thiết bị đó:

[C-2-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm OMX tương ứng từ thiết bị Android Dự án nguồn mở (nếu có) cho từng định dạng và loại nội dung đa phương tiện (bộ mã hoá hoặc bộ giải mã) mà thiết bị hỗ trợ.
[C-2-2] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google". PHẢI dựa trên trên mã nguồn Dự án nguồn mở Android của họ.
[C-SR-2] Giới thiệu DỄ DÀNG khuyên dùng các bộ mã hoá và giải mã phần mềm OMX chạy trong một bộ mã hoá và giải mã không có quyền truy cập vào trình điều khiển phần cứng ngoài trình liên kết bộ nhớ.

Nếu quá trình triển khai thiết bị hỗ trợ API Codec 2.0, thì các quá trình triển khai thiết bị đó:

[C-3-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm Codec 2.0 tương ứng từ Dự án nguồn mở Android (nếu có) cho từng định dạng và loại nội dung đa phương tiện (bộ mã hoá hoặc bộ giải mã) mà thiết bị hỗ trợ.
[C-3-2] PHẢI chứa bộ mã hoá và giải mã phần mềm Codec 2.0 theo quy trình được cung cấp trong Dự án nguồn mở Android để có thể để cấp quyền truy cập vào bộ mã hoá và giải mã phần mềm trong phạm vi hẹp hơn.
[C-3-3] Bộ mã hoá và giải mã có tên bắt đầu bằng "c2.android". PHẢI dựa trên trên mã nguồn Dự án nguồn mở Android của họ.

5.1.10. Đặc tính bộ mã hoá và giải mã nội dung đa phương tiện

Nếu quá trình triển khai thiết bị có hỗ trợ bộ mã hoá và giải mã nội dung đa phương tiện, thì các quy trình này:

[C-1-1] PHẢI trả về các giá trị chính xác của ký tự bộ mã hoá và giải mã nội dung đa phương tiện qua tham số MediaCodecInfo API.

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 phù hợp với nguyên tắc đặt tên của 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 API Codec 2.0 và có tên tuân theo nguyên tắc đặt tên của Codec 2.0 dành cho Android.
[C-1-4] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google". hoặc "c2.android". PHẢI KHÔNG được mô tả là một nhà cung cấp hay là được tăng tốc phần cứng.
[C-1-5] Những bộ mã hoá và giải mã chạy trong quy trình bộ mã hoá và giải mã (nhà cung cấp hoặc hệ thống) có quyền truy cập vào các trình điều khiển phần cứng ngoài trình phân bổ và lập bản đồ bộ nhớ KHÔNG ĐƯỢC có đặc điểm chỉ có phần mềm.
[C-1-6] Bộ mã hoá và giải mã không có trong Dự án nguồn mở Android hoặc không dựa trên trên mã nguồn trong dự án đó PHẢI được mô tả là nhà cung cấp.
[C-1-7] Bộ mã hoá và giải mã sử dụng tính năng tăng tốc phần cứng PHẢI được mô tả khi phần cứng được tăng tốc.
[C-1-8] Tên bộ mã hoá và giải mã KHÔNG ĐƯỢC gây hiểu lầm. Ví dụ: bộ mã hoá và giải mã có tên "bộ giải mã" PHẢI hỗ trợ giải mã và các giải mã có tên là "bộ mã hoá" PHẢI hỗ trợ mã hoá. Những bộ mã hoá và giải mã có tên chứa định dạng nội dung đa phương tiện PHẢI hỗ trợ các định dạng đó .

Nếu quá trình triển khai thiết bị có 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 xuất bản dữ liệu tốc độ khung hình có thể đạt được cho các kích thước sau nếu được 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 pixel (H263, MPEG2, MPEG4) 352 x 288 pixel (bộ mã hoá MPEG4, H263, MPEG2) 320 x 180 pixel (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 px (khác, AV1)	1408 x 1152 pixel (H263) 1280 x 720 pixel (khác, AV1)	1920 x 1080 pixel (trừ MPEG4, AV1)	3840 x 2160 pixel (HEVC, VP9, AV1)

[C-2-2] Codec video được đặc trưng là được 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 danh sách PHẢI mỗi danh sách đều được hỗ trợ điểm hiệu suất chuẩn (được liệt kê trong PerformancePoint API), trừ phi các giá trị đó thuộc phạm vi của một điểm hiệu suất 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ỗ trợ hiệu suất video ổn định ngoài một trong các video chuẩn được liệt kê.

5.2. Mã hoá video

Nếu quá trình triển khai thiết bị có hỗ trợ bất kỳ bộ mã hoá video nào và cung cấp bộ mã hoá cho ứng dụng bên thứ ba và đặt
MediaFormat.KEY_BITRATE_MODE đến BITRATE_MODE_VBR để bộ mã hoá hoạt động ở chế độ Tốc độ bit biến thiên, sau đó, miễn là không ảnh hưởng đến sàn chất lượng tối thiểu, tốc độ bit được mã hoá :

KHÔNG ĐƯỢC, trên một cửa sổ trượt, lớn hơn 15% trên tốc độ bit giữa khung hình intraframe (khung hình I) ngắt quãng.
KHÔNG ĐƯỢC lớn hơn 100% trên tốc độ bit trong cửa sổ trượt 1 giây.

Nếu quá trình triển khai thiết bị có hỗ trợ bất kỳ bộ mã hoá video nào và cung cấp bộ mã hoá cho ứng dụng bên thứ ba và thiết lập MediaFormat.KEY_BITRATE_MODE đến 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] is liền NÊN DÙNG CHO KHÔNG vượt quá 15% so với tốc độ bit mục tiêu trong cửa sổ trượt 1 giây.

Nếu quá trình triển khai thiết bị bao gồm hiển thị màn hình được nhúng với đường chéo tối thiểu là 2,5 inch hoặc có cổng đầu ra video, hoặc khai báo khả năng hỗ trợ của máy ảnh qua android.hardware.camera.any cờ tính năng, chúng:

[C-1-1] PHẢI bao gồm hỗ trợ của ít nhất một trong số các video VP8 hoặc H.264 bộ mã hoá và cung cấp bộ mã hoá cho các ứng dụng của bên thứ ba.
NÊN hỗ trợ cả bộ mã hoá video VP8 và H.264 và cung cấp bộ mã hoá này cho các ứng dụng của bên thứ ba.

Nếu quá trình triển khai thiết bị hỗ trợ bất kỳ video H.264, VP8, VP9 hoặc HEVC bộ mã hoá và cung cấp cho các ứng dụng của bên thứ ba.

[C-2-1] PHẢI hỗ trợ tốc độ bit có thể định cấu hình động.
NÊN hỗ trợ tốc độ khung hình có thể 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 vùng đệm đầu vào và phân bổ nhóm bit dựa trên thời lượng khung hình đó.

Nếu các quá trình triển khai thiết bị có hỗ trợ bộ mã hoá video MPEG-4 SP và đặt nó có sẵn cho các ứng dụng bên thứ ba, họ:

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

Nếu phương thức 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 máy ảnh phần cứng gắn kèm hoặc có thể cắm được hiển thị qua các API android.camera:

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

Nếu các quá trình triển khai thiết bị có cung cấp phương thức mã hoá HDR thì các kết quả đó:

[C-SR-1] arePhải NÊN cung cấp trình bổ trợ cho 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

Liệu các quá trình triển khai thiết bị có hỗ trợ bộ mã hoá H.263 và cung cấp bộ mã hoá hay không với các ứng dụng bên thứ ba, họ:

[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à tuỳ chọn.

5.2.2. H.264

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

[C-1-1] PHẢI hỗ trợ Hồ sơ cơ sở Cấp 3. Tuy nhiên, có hỗ trợ cho ASO (Sắp xếp lát cắt tuỳ ý), FMO (Linh hoạt) Sắp xếp thứ tự khối macro) và RS (Lát cắt dư thừa) là KHÔNG BẮT BUỘC. Hơn nữa, để duy trì khả năng tương thích với các thiết bị Android khác, NÊN DÙNG rằng Các bộ mã hoá không sử dụng ASO, FMO và RS cho Hồ sơ cơ sở.
[C-1-2] PHẢI hỗ trợ các cấu hình mã hoá video SD (Standard Definition) trong bảng sau.
NÊN hỗ trợ Cấu hình chính cấp 4.
NÊN hỗ trợ các cấu hình mã hoá video HD (Độ nét cao) dưới dạng được nêu trong bảng sau.

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

[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 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel
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. Văn bản ảo (VP8)

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

[C-1-1] PHẢI hỗ trợ các cấu hình mã hoá video SD.
NÊN hỗ trợ các cấu hình mã hoá video HD (Độ nét 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 Yêu cầu mã hóa phần cứng RTC để đảm bảo chất lượng chấp nhận được của dịch vụ phát video trực tuyến và hội nghị truyền hình.

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

[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 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel
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. Văn bản 9

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

[C-1-2] PHẢI hỗ trợ Profile 0 Level 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ư được chỉ ra trong bảng sau.
[C-SR-1] areBạnĐể hỗ trợ các hồ sơ giải mã HD dưới dạng đượ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 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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 quá trình triển khai thiết bị tuyên bố hỗ trợ Hồ sơ 2 hoặc Hồ sơ 3 thông qua API đa phương tiện:

Việc hỗ trợ định dạng 12 bit là KHÔNG BẮT BUỘC.

5.2.5. H.265

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

[C-1-1] PHẢI hỗ trợ Cấu hình chính Cấp 3 lên tới Độ phân giải 512 x 512.
[C-SR-1] areQuá trình quảng cáo được khuyến nghị để hỗ trợ Hồ sơ SD 720 x 480 và Các cấu hình mã hoá 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 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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 quá trình triển khai thiết bị có hỗ trợ bộ mã hoá và giải mã AV1, thì chúng:

[C-1-1] PHẢI hỗ trợ Main Profile bao gồm nội dung 8-bit và 10-bit.
[C-1-2] PHẢI xuất bản dữ liệu hiệu suất, tức là dữ liệu hiệu suất báo cáo qua getSupportedFrameRatesFor() hoặc getSupportedPerformancePoints() API cho các độ phân giải được hỗ trợ trong bảng dưới đây.
[C-1-3] PHẢI chấp nhận siêu dữ liệu HDR và xuất siêu dữ liệu đó sang bitstream

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

[C-2-1] PHẢI hỗ trợ lên đến và bao gồm hồ sơ mã hoá HD1080p từ bảng bên dưới:

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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 quá trình triển khai thiết bị hỗ trợ bộ mã hoá và giải mã VP8, VP9, H.264 hoặc H.265, thì các cấu hình đó:

[C-1-1] PHẢI hỗ trợ độ phân giải video động và chuyển đổi tốc độ khung hình thông qua các API Android tiêu chuẩn trong cùng một luồng cho tất cả VP8, VP9, Bộ mã hoá và giải mã H.264 và H.265 theo thời gian thực và hỗ trợ độ phân giải tối đa theo từng bộ mã hoá và giải mã trên thiết bị.

5.3.1. MPEG-2

Nếu quá trình triển khai thiết bị hỗ trợ bộ giải mã MPEG-2, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ Main Profile High Level.

5.3.2. H.263

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

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

5.3.3. MPEG-4

Nếu triển khai thiết bị với bộ giải mã MPEG-4, chúng:

[C-1-1] PHẢI hỗ trợ Simple Profile Level 3.

5.3.4. H.264

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

[C-1-1] PHẢI hỗ trợ Main Profile Level 3.1 và Baseline Profile. Hỗ trợ cho ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp theo khối macro linh hoạt) và RS (Lát cắt thừa) là KHÔNG BẮT BUỘC.
[C-1-2] PHẢI có khả năng giải mã video bằng SD (Độ nét chuẩn) hồ sơ được liệt kê trong bảng sau và được mã hoá bằng Hồ sơ cơ sở và Main Profile Level 3.1 (bao gồm cả 720p30).
NÊN có khả năng giải mã video bằng cấu hình HD (Độ nét cao) như được trình bày trong bảng sau.

Nếu chiều cao được phương thức Display.getSupportedModes() báo cáo là bằng hoặc lớn hơn độ phân giải video, cách 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.
[C-2-2] PHẢI hỗ trợ các cấu hình giải mã video HD 1080p trong bảng.

	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 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel
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 quá trình triển khai thiết bị có hỗ trợ bộ mã hoá và giải mã H.265, thì chúng:

[C-1-1] PHẢI hỗ trợ cấp chính của Cấu hình chính Cấp 3 và video SD giải mã hồ sơ như được chỉ ra trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD như được chỉ ra 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 phần sau nếu có bộ giải mã phần cứng.

Nếu chiều cao được phương thức Display.getSupportedModes() báo cáo là bằng hoặc lớn hơn độ phân giải của video, thì:

[C-2-1] Quá trình triển khai thiết bị PHẢI hỗ trợ tối thiểu một trong số các giao thức H.265 hoặc VP9 để giải mã các hồ sơ 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	352 x 288 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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ó 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 quá trình triển khai thiết bị tuyên bố hỗ trợ Hồ sơ HDR thông qua Phương tiện API:

[C-3-1] Các quá trình 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 HDR cần thiết siêu dữ liệu từ luồng bit và/hoặc vùng chứa.
[C-3-2] Các quá trình triển khai trên thiết bị PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).

5.3.6. Văn bản ảo (VP8)

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

[C-1-1] PHẢI hỗ trợ các 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 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 theo báo cáo của phương thức Display.getSupportedModes() là bằng hoặc lớn hơn độ phân giải của video, thì:

[C-2-1] Các quá trình triển khai thiết bị PHẢI hỗ trợ hồ sơ 720p trong bảng sau.
[C-2-2] Các triển khai thiết bị PHẢI hỗ trợ hồ sơ 1080p trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 180 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel
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. Văn bản 9

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

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

Nếu quá trình triển khai thiết bị có hỗ trợ bộ mã hoá và giải mã phần cứng (VP9) và bộ giải mã phần cứng:

[C-2-1] PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ ra trong phần sau bảng.

Nếu chiều cao được phương thức Display.getSupportedModes() báo cáo là bằng hoặc lớn hơn độ phân giải của video, thì:

[C-3-1] Các quá trình triển khai thiết bị PHẢI hỗ trợ ít nhất một trong số các cấu hình của VP9 hoặc H.265 để giải mã các hồ sơ 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	320 x 180 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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^{TV có giải mã phần cứng VP9})	60 khung hình/giây
Tốc độ bit của video	600 Kb/giây	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

Nếu các phương pháp triển khai thiết bị tuyên bố là có hỗ trợ VP9Profile2 hoặc VP9Profile3 thông qua 'CodecProfileLevel' API đa phương tiện:

Việc hỗ trợ định dạng 12 bit là KHÔNG BẮT BUỘC.

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

[C-4-1] Quá trình 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ấu hình HDR, cũng như 'KEY_HDR10_PLUS_INFO' cho hồ sơ HDR10Plus) khỏi ứng dụng. Chúng cũng PHẢI hỗ trợ việc trích xuất và xuất cần có siêu dữ liệu HDR từ luồng bit và/hoặc vùng chứa.
[C-4-2] Các quá trình triển khai trên thiết bị PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).

5.3.8. Dolby Vision

Nếu các quá trình triển khai thiết bị khai báo hỗ trợ cho bộ giải mã Dolby Vision thông qua HDR_TYPE_DOLBY_VISION! chúng:

[C-1-1] PHẢI cung cấp bộ trích xuất có khả năng Dolby Vision.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-2] PHẢI hiển thị đúng nội dung Dolby Vision trên thiết bị màn hình hoặc trên màn hình ngoài được kết nối qua cổng đầu ra video chuẩn (ví dụ: HDMI).

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

[C-1-3] PHẢI đặt track ID của(các) lớp cơ sở có khả năng tương thích ngược (nếu có) giống với kết hợp mã theo dõi của lớp Dolby Vision.

5.3.9. AV1

Nếu các quá trình triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1 và cung cấp bộ mã hoá này cho các ứng dụng của bên thứ ba, thì các thiết bị đó sẽ:

[C-1-1] PHẢI hỗ trợ Main Profile bao gồm nội dung 8-bit và 10-bit.

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

[C-2-1] PHẢI có thể giải mã ít nhất là HD 720p video giải mã hồ sơ từ bảng bên dưới khi chiều cao được báo cáo theo Display.getSupportedModes() bằng hoặc lớn hơn 720p.
[C-2-2] PHẢI có thể giải mã ít nhất là hồ sơ giải mã video HD 1080p trong bảng bên dưới khi chiều cao được báo cáo theo Display.getSupportedModes() bằng hoặc lớn hơn 1080p.

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
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 quá trình triển khai thiết bị hỗ trợ Hồ sơ HDR thông qua Media API, thì chúng:

[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 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 nghĩa về khả năng tương thích cho các phiên bản trong tương lai đã được lên kế hoạch để thay đổi các trường này thành PHẢI. Các thiết bị Android mới và hiện có HẤP DẪN ĐƯỢC ĐỀ XUẤT để đáp ứng các yêu cầu này (được liệt kê là NÊN) hoặc sẽ không thể đạt được khả năng tương thích với Android khi được nâng cấp lên trong tương lai .

5.4.1. Thông tin ghi âm và micrô thô

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình triển khai thiết bị đó sẽ:

[C-1-1] PHẢI cho phép ghi lại nội dung âm thanh thô cho bất kỳ luồng VÀO AudioRecord hoặc AAudio nào được mở thành công. Ở mức tối thiểu, các đặc điểm sau PHẢI được hỗ trợ:
- Đị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 thân mến! VOICE_RECOGNITION thân mến! VOICE_COMMUNICATION, UNPROCESSED thân mến! hoặc VOICE_PERFORMANCE. Điều này cũng áp dụng cho Giá trị đặt trước đầu vào tương đương trong AAudio, cho ví dụ: AAUDIO_INPUT_PRESET_CAMCORDER.
NÊN cho phép thu thập nội dung âm thanh thô bằng các đặc điểm:
- Đị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 với số lượng micrô trên thiết bị
[C-1-2] PHẢI chụp ở tốc độ lấy mẫu trên mà không tăng tần số lấy mẫu.
[C-1-3] PHẢI bao gồm bộ lọc khử răng cưa thích hợp khi tốc độ lấy mẫu nêu trên được thu thập bằng phương pháp giảm tần số lấy mẫu.
NÊN cho phép ghi lại nội dung âm thanh thô và chất lượng radio AM. có nghĩa là 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 tôn trọng API MicrophoneInfo và điền đúng cách thông tin về các micrô có trên thiết bị các ứng dụng của bên thứ ba có thể truy cập được thông qua AudioManager.getMicrophones() API cho AudioRecord đang hoạt động sử dụng MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED hoặc VOICE_PERFORMANCE. Nếu các phương pháp triển khai thiết bị cho phép ghi lại chất lượng đài AM và DVD đối với âm thanh thô nội dung, chúng:
[C-2-1] PHẢI chụp mà không cần 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 bao gồm một bộ lọc khử răng cưa thích hợp cho mọi quá trình tăng tần số lấy mẫu hoặc giảm tần số lấy mẫu.

5.4.2. Chụp để nhận dạng giọng nói

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình triển khai thiết bị đó sẽ:

[C-1-1] PHẢI chụp Nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION lúc có tốc độ lấy mẫu 44100 và 48000.
[C-1-2] PHẢI, theo mặc định, tắt mọi tính năng xử lý âm thanh giảm tiếng ồn khi ghi lại luồng âm thanh của âm thanh AudioSource.VOICE_RECOGNITION nguồn.
[C-1-3] PHẢI, theo mặc định, vô hiệu hoá bất kỳ điều khiển khuếch đại tự động nào khi ghi một luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
NÊN thể hiện các đặc điểm biên độ so với tần số gần đúng ở giữa dải tần số: cụ thể là ± 3dB từ 100 Hz đến 4000 Hz cho mỗi và mọi micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
[C-SR-1] areQuá trình phối lại được đề xuất để thể hiện các mức biên độ ở mức thấp dải tần số: đặc biệt là từ ±20 dB từ 30 Hz đến 100 Hz so với phạm vi tần số trung của từng micrô dùng để ghi âm giọng nói nhận dạng nguồn âm thanh.
[C-SR-2] areĐể đề xuất cho biểu diễn các mức biên độ ở mức cao dải tần số: cụ thể là từ ± 30 dB từ 4000 Hz đến 22 KHz so với phạm vi tần số giữa của từng micrô dùng để ghi âm giọng nói nhận dạng nguồn âm thanh.
NÊN đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình sin 1000 Hz phát ở 90 dB Mức áp suất âm thanh (SPL) (đo bên cạnh micrô) mang lại phản ứng lý tưởng của RMS 2500 trong khoảng từ 1770 đến 3530 ở 16 mẫu bit (hoặc -22,35 db ± 3dB Tỷ lệ đầy đủ cho dấu phẩy động/độ chính xác kép mẫu) cho từng micrô dùng để ghi lại tính năng nhận dạng giọng nói nguồn âm thanh.
NÊN ghi lại luồng âm thanh nhận dạng giọng nói để có biên độ PCM Các mức SPL đầu vào theo dõi tuyến tính thay đổi trong ít nhất một phạm vi 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 ở dạng sóng hài toàn phần nhỏ hơn 1% đối với 1 kHz ở mức đầu vào 90 dB SPL tại micrô.

Nếu quá trình triển khai thiết bị khai báo android.hardware.microphone và gây nhiễu công nghệ chặn (giảm) được điều chỉnh để nhận dạng giọng nói, chúng:

[C-2-1] PHẢI cho phép điều khiển được hiệu ứng âm thanh này bằng API android.media.audiofx.NoiseSuppressor.
[C-2-2] PHẢI xác định duy nhất từng công nghệ khử tiếng ồn thông qua trường AudioEffect.Descriptor.uuid.

5.4.3. Chụp để đổi tuyến đường phát lại

Lớp android.media.MediaRecorder.AudioSource bao gồm REMOTE_SUBMIX nguồn âm thanh.

Nếu quá trình triển khai thiết bị khai báo cả android.hardware.audio.output và android.hardware.microphone, họ:

[C-1-1] PHẢI triển khai đúng cách nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng dùng API android.media.AudioRecord để ghi từ nguồn âm thanh, tệp này sẽ thu thập dữ liệu kết hợp của tất cả các luồng âm thanh, ngoại trừ những luồng sau:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Bộ khử tiếng vọng cách âm

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình triển khai thiết bị đó sẽ:

NÊN triển khai Acoustic Echo Canceler (Trình huỷ tiếng vọng âm thanh) Công nghệ (AEC) đã điều chỉnh giao tiếp bằng giọng nói và áp dụng cho đường dẫn thu thập khi chụp bằng AudioSource.VOICE_COMMUNICATION.

Nếu quá trình triển khai thiết bị cung cấp Trình huỷ tiếng vọng âm thanh được chèn vào đường dẫn ghi âm khi AudioSource.VOICE_COMMUNICATION được chọn, chúng:

[C-SR-1] aretắt linh hoạt để khai báo về việc này qua AcousticEchoCanceler Phương thức API AcousticEchoCanceler.isAvailable()
[C-SR-2] are liền_ kẹp để cho phép hiệu ứng âm thanh này có thể điều khiển bằng AcousticEchoCanceler API.
[C-SR-3] are Tín phiếu Liên danh để xác định duy nhất từng công nghệ AEC thông qua tệp AudioEffect.Descriptor.uuid .

5.4.5. Chụp đồng thời

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone,các hoạt động đó PHẢI triển khai 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 tính năng hỗ trợ tiếp cận truy cập đồng thời vào micrô dịch vụ chụp ảnh bằng AudioSource.VOICE_RECOGNITION và ít nhất một chụp ứng dụng bằng AudioSource bất kỳ.
[C-1-2] PHẢI cho phép một ứng dụng cài đặt sẵn truy cập đồng thời vào micrô ứng dụng có vai trò Trợ lý và ít nhất một ứng dụng chụp bằng AudioSource bất kỳ, ngoại trừ AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER.
[C-1-3] PHẢI tắt tiếng thu âm đối với mọi ứng dụng khác, ngoại trừ dịch vụ hỗ trợ tiếp cận trong khi ứng dụng đang chụp ảnh bằng AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER. Tuy nhiên, khi một ứng dụng đang chụp qua AudioSource.VOICE_COMMUNICATION rồi đến 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ó đặc quyền (được cài đặt trước) có quyền CAPTURE_AUDIO_OUTPUT.
[C-1-4] Nếu hai hoặc nhiều ứng dụng đang chụp đồng thời và nếu cả hai ứng dụng đều không có giao diện người dùng ở trên cùng, giao diện người dùng bắt đầu chụp gần đây nhất nhận âm thanh.

5,5. Phát âm thanh

Android hỗ trợ tính năng cho phép các ứng dụng phát âm thanh qua âm thanh thiết bị ngoại vi đầu ra xác định trong mục 7.8.2.

5.5.1. Phát âm thanh thô

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.audio.output, thì các quá trình triển khai thiết bị đó sẽ:

[C-1-1] PHẢI cho phép phát nội dung âm thanh thô bằng các đặc điểm:
- Định dạng nguồn: PCM tuyến tính, 16 bit, 8 bit, float
- 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 ở kênh cấu hình được liệt kê ở trên
  - 96000 ở chế độ đơn âm và âm thanh nổi

5.5.2. Hiệu ứng âm thanh

Android cung cấp API cho hiệu ứng âm thanh cho việc triển khai thiết bị.

Nếu quá trình triển khai thiết bị khai báo tính năng android.hardware.audio.output, chúng:

[C-1-1] PHẢI hỗ trợ EFFECT_TYPE_EQUALIZER và Có thể kiểm soát các quá trình triển khai EFFECT_TYPE_LOUDNESS_ENHANCER thông qua Các lớp con AudioEffect là Equalizer và LoudnessEnhancer.
[C-1-2] PHẢI hỗ trợ việc triển khai API của trình hiển thị hình ảnh, có thể điều khiển thông qua lớp Visualizer.
[C-1-3] PHẢI hỗ trợ việc triển khai EFFECT_TYPE_DYNAMICS_PROCESSING có thể điều khiển thông qua lớp con AudioEffect DynamicsProcessing.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-4] PHẢI hỗ trợ audio Effects with đầu vào và đầu ra dấu phẩy động, khi hiệu ứng kết quả sẽ được trả về quy trình âm thanh khung. Đây là mức giá thông thường chèn hoặc hiệu ứng phụ trợ như bộ cân bằng âm thanh. Hành vi tương đương là rất quan trọng nên dùng khi kết quả hiệu ứng không hiển thị bằng âm thanh khung quy trình (chẳng hạn như hiệu ứng hậu xử lý hoặc hiệu ứng giảm tải).

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-5] PHẢI đảm bảo rằng hiệu ứng âm thanh hỗ trợ nhiều kênh tối đa số lượng kênh bộ trộn còn được gọi là FCC_LIMIT, khi kết quả hiệu ứng được trả về quy trình âm thanh khung. Chiến dịch này đề cập đến các hiệu ứng chèn hoặc hiệu ứng phụ trợ thông thường, nhưng không bao gồm các hiệu ứng đặc biệt như như các hiệu ứng trộn lẫn, tăng phối, không gian hoá và làm thay đổi số lượng kênh. Bạn nên sử dụng hành vi tương đương khi hiệu ứng không hiển thị bằng quy trình âm thanh khung (chẳng hạn như xử lý hậu kỳ hoặc giảm tải hiệu ứng).

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

NÊN hỗ trợ EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Cách triển khai EFFECT_TYPE_PRESET_REVERB và EFFECT_TYPE_VIRTUALIZER có thể kiểm soát thông qua AudioEffect lớp con BassBoost, EnvironmentalReverb, PresetReverb và Virtualizer.
[C-SR-1] Are Internet ĐỀ XUẤT NÊN hỗ trợ các hiệu ứng trong dấu phẩy động và đa kênh.

5.5.3. Âm lượng đầu ra âm thanh

Triển khai thiết bị Automotive:

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 như đã xác định theo AudioAttributes và việc sử dụng âm thanh ô 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 phương pháp triển khai cho thiết bị hỗ trợ tính năng phát giảm tải âm thanh, thì các phương thức đó:

[C-SR-1] Are Để chỉ định nội dung âm thanh không có khoảng cách đã phát giữa hai đoạn video có cùng định dạng khi được chỉ định bởi giá trị API Không có khoảng trống cho AudioTrack và vùng chứa đa phương tiện cho MediaPlayer.

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 loại ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng âm thanh.

Trong phần này, hãy sử dụng các định nghĩa sau:

độ trễ đầu ra. Khoảng thời gian từ khi một ứng dụng ghi một khung của dữ liệu được mã hoá PCM và khi âm thanh tương ứng được trình bày đến môi trường tại bộ chuyển đổi trên thiết bị hoặc tín hiệu rời khỏi thiết bị thông qua cổng và có thể được quan sát từ bên ngoài.
độ trễ đầu ra nguội. Khoảng thời gian từ khi bắt đầu luồng đầu ra đến khi thời gian trình bày của khung hình đầu tiên dựa trên dấu thời gian, khi đầu ra âm thanh hệ thống đã không hoạt động và bị tắt nguồn trước khi 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 trình bày một âm thanh môi trường với thiết bị tại 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à khi ứng dụng đọc khung tương ứng của dữ liệu được mã hoá PCM.
bị mất dữ liệu đầu vào. Phần ban đầu của tín hiệu đầu vào không sử dụng được hoặc không có sẵn.
độ trễ đầu vào nguội. Khoảng thời gian từ khi bắt đầu phát trực tiếp đến khi nhận được khung hợp lệ đầu tiên, khi hệ thống đầu vào âm thanh không hoạt động và tắt nguồn trước khi 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ị ghi âm.
độ trễ trọn vòng liên tục. Tổng độ trễ đầu vào liên tục cộng với độ trễ đầu ra liên tục cộng với một khoảng thời gian đệm. Khoảng thời gian đệm cho phép thời gian để ứng dụng xử lý tín hiệu và thời gian để ứng dụng giảm thiểu giai đoạn sự khác biệt giữa luồng đầu vào và đầu ra.
API hàng đợi bộ đệm PCM OpenSL ES. Nhóm các tính năng liên quan đến PCM OpenSL ES API trong Android NDK.
API âm thanh gốc AAudio. Tập hợp Các API AAudio trong Android NDK.
Dấu thời gian. Một cặp bao gồm vị trí khung tương đối trong một 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 liên kết. Xem thêm AudioTimestamp (Dấu thời gian cho âm thanh).
sự cố. Giá trị mẫu bị 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 do chạy dưới mức vùng đệm đối với đầu ra, vượt quá vùng đệm để có đầu vào hoặc bất kỳ nguồn gây nhiễu kỹ thuật số hay tương tự nào khác.
trung bình độ lệch tuyệt đối (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 của một tập hợp giá trị.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

độ trễ nhấn để âm (TTL) là thời gian do Trình xác minh CTS đo lường từ khi người dùng nhấn vào màn hình cho đến khi một âm báo tạo ra nhờ thao tác đó người dùng nghe thấy tiếng nhấn trên loa. Kết quả này được tính trung bình qua 5 lần đo bằng phương pháp API âm thanh gốc AAudio cho đầu ra.
Độ trễ trọn vòng (RTL) (do Người xác minh CTS đo lường) là giá trị Trung bình Độ trễ liên tục qua 5 phép đo, được đo qua một đường dẫn lặp lại cung cấp dữ liệu đầu ra trở lại đầu vào bằng API âm thanh gốc AAudio. Các đường dẫn lặp lại là:
- Loa/micrô: Loa tích hợp với micrô tích hợp.
- Analog: Giắc cắm analog 3,5 mm và bộ chuyển đổi loopback.
- USB: Bộ chuyển đổi USB sang 3,5 mm và bộ chuyển đổi vòng lặp hoặc âm thanh USB cáp giao diện và cáp loopback.
FEATURE_AUDIO_PRO. Tính năng android.hardware.audio.pro là đã khai báo.
MPC. Lớp hiệu suất nội dung đa phương tiện

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

độ trễ của tính năng theo dõi chuyển động trên đầu trang. Thời gian lấy từ chuyển động của đầu do đơn vị đo lường quán tính (IMU) thu được đến bộ chuyển đổi tai nghe phát hiện sự thay đổi âm thanh do chuyển động này.

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

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.audio.output, thì các hoạt động đó PHẢI đáp ứng hoặc vượt quá các yêu cầu sau:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

~~[C-1-1] Dấu thời gian đầu ra được trả về bởi AudioTrack.getTimestamp và AAudioStream_getTimestamp có độ chính xác đến +/- 2 mili giây.~~

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

[C-1-2] Độ trễ đầu ra nguội 500 mili giây trở xuống.
[C-1-3] Mở luồng đầu ra bằng AAudioStreamBuilder_openStream() PHẢI mất chưa đến 1000 mili giây.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-4] Độ trễ trọn vòng được tính toán dựa trên dữ liệu đầu vào và đầu ra dấu thời gian do AAudioStream_getTimestamp trả về PHẢI trong phạm vi 200 mili giây kể từ độ trễ trọn vòng đo được cho AAUDIO_PERFORMANCE_MODE_NONE và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY cho loa, có dây và không dây tai nghe.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu các quá trình triển khai thiết bị khai báo android.hardware.audio.output, thì chúng sẽ ĐỀ XUẤT NÊN đáp ứng hoặc vượt quá các yêu cầu sau:

[C-SR-1] Độ trễ đầu ra lạnh là 100 mili giây trở xuống qua loa đường dẫn dữ liệu.

[C-SR-2] Độ trễ nhấn theo âm sắc là 80 mili giây trở xuống.

[C-SR-4] Độ trễ trọn vòng được tính toán dựa trên dữ liệu đầu vào và đầu ra dấu thời gian do AAudioStream_getTimestamp trả về KHÔNG ĐƯỢC ĐỀ XUẤT trong phạm vi 30 mili giây của độ trễ trọn vòng đo được cho AAUDIO_PERFORMANCE_MODE_NONE và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY cho loa, tai nghe có dây và không dây.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu việc triển khai thiết bị đáp ứng các yêu cầu trên, sau mọi hoạt động triển khai ban đầu hiệu chỉnh (khi sử dụng API âm thanh gốc AAudio) để đầu ra liên tục và độ trễ đầu ra nguội trên ít nhất một âm thanh được hỗ trợ thiết bị đầu ra, chúng là:

[C-SR-5] bỏ qua Sử dụng để báo cáo âm thanh có độ trễ thấp bằng cách khai báo Cờ tính năng android.hardware.audio.low_latency.

[C-SR-6] Liên quan đến việc đáp ứng các yêu cầu đối với độ trễ thấp qua API AAudio.

[C-SR-7] Để đảm bảo các luồng trả về, AAUDIO_PERFORMANCE_MODE_LOW_LATENCY từ AAudioStream_getPerformanceMode(), giá trị được AAudioStream_getFramesPerBurst() trả về nhỏ hơn hoặc bằng giá trị được android.media.AudioManager.getProperty(String) trả về cho khoá thuộc tính AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị không đáp ứng các yêu cầu về âm thanh có độ trễ thấp thông qua API âm thanh gốc AAudio, họ:

[C-2-1] KHÔNG ĐƯỢC báo cáo tính năng hỗ trợ âm thanh có độ trễ thấp.

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

Nếu quá trình triển khai thiết bị bao gồm android.hardware.microphone, thì PHẢI đáp ứng các yêu cầu về âm thanh đầu vào sau đây:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-3-1] Hạn chế lỗi trong dấu thời gian đầu vào, được trả về bằng AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp, đến +/- 2 mili giây. "Lỗi" ở đây có nghĩa là độ lệch so với giá trị chính xác.

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

[C-3-2] Độ trễ đầu vào nguội 500 mili giây trở xuống.
[C-3-3] Mở luồng đầu vào bằng AAudioStreamBuilder_openStream() PHẢI mất chưa đến 1000 mili giây.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị bao gồm android.hardware.microphone, thì chúng sẽ KHÔNG NÊN DÙNG để đáp ứng các yêu cầu về âm thanh đầu vào sau đây:

[C-SR-8] Độ trễ đầu vào lạnh là 100 mili giây trở xuống qua micrô đường dẫn dữ liệu.

[C-SR-11] Hạn chế lỗi trong dấu thời gian đầu vào, được trả về bằng AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp, đến +/- 1 mili giây.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu các phương thức triển khai thiết bị khai báo android.hardware.audio.output và android.hardware.microphone, họ:

[C-SR-12] AreĐể chỉ có thể có Độ trễ trọn vòng trung bình liên tục, xác định được độ trễ trung bình 50 mili giây hoặc ít hơn trên 5 lần đo, có Độ lệch tuyệt đối trung bình nhỏ hơn 10 mili giây, trên ít nhất một đường dẫn được hỗ trợ.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Bảng sau đây xác định các yêu cầu đối với RTL dành cho 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à nội dung khai báo	RTL (mili giây)	MAD (mili giây)	Đường dẫn Loopback
Cầm tay	250	30	loa/micrô, analog 3,5mm (nếu được hỗ trợ), USB (nếu được hỗ trợ)
>= MPC_T (14)	80	15	ít nhất một đường dẫn
FEATURE_AUDIO_THẤP_DƯỚI	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	đồng hồ kim (nếu được hỗ trợ)
FEATURE_AUDIO_PRO	25	5	USB (nếu hỗ trợ analog không)

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Bảng sau đây xác định các yêu cầu đối với TTL đối với 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à nội dung khai báo	TTL (mili giây)
Cầm tay	250
>= MPC_T (14)	80
MPC_S (13)	100
FEATURE_AUDIO_PRO	80

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị có bao gồm tính năng hỗ trợ cho spatial audio với tính năng theo dõi chuyển động của đầu và khai báo PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY cờ, họ:

[C-4-1] PHẢI thể hiện độ trễ tối đa của hoạt động theo dõi chuyển động của đầu đến cập nhật âm thanh là 300 mili giây.

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

5,7. Giao thức mạng

Quá trình triển khai thiết bị PHẢI hỗ trợ giao thức mạng truyền thông để phát âm thanh và video như quy định trong tài liệu SDK Android.

Đối với mỗi bộ mã hoá và giải mã và định dạng vùng chứa cần triển khai thiết bị hỗ trợ, việc triển khai thiết bị:

[C-1-1] PHẢI hỗ trợ bộ mã hoá và vùng chứa đó qua HTTP và HTTPS.
[C-1-2] PHẢI hỗ trợ các định dạng phân đoạn phương tiện tương ứng như được hiển thị trong bảng định dạng phân khúc truyền thông bên dưới trong Giao thức dự thảo Phát trực tuyế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ư được hiển thị trong Bảng RTSP dưới đây. Đối với các trường hợp ngoại lệ, vui lòng xem chú thích cuối trang 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	Hỗ trợ bộ mã hoá và giải mã bắt buộc
Luồng truyền tải MPEG-2	ISO 13818	Bộ mã hoá và giải mã video: H264 AVC MPEG-4 SP (Danh sách quảng cáo gốc) MPEG-2 Xem phần 5.1.8 để biết chi tiết về H264 AVC, MPEG2-4 SP, và MPEG-2. Bộ mã hoá và giải mã âm thanh: (chuẩn) AAC Xem phần 5.1.3 để biết chi tiết về AAC và các biến thể của AAC.
AAC với tính năng lấy khung hình ADTS và thẻ ID3	ISO 13818-7	Xem mục 5.1.1 để biết chi tiết về AAC và các biến thể của nó
WebVTT	WebVTT

Định dạng phân đoạn

(Các) tệp đối chiếu

Hỗ trợ bộ mã hoá và giải mã bắt buộc

Luồng truyền tải MPEG-2

ISO 13818

Bộ mã hoá và giải mã video:

H264 AVC
MPEG-4 SP (Danh sách quảng cáo gốc)
MPEG-2

Xem phần 5.1.8 để biết chi tiết về H264 AVC, MPEG2-4 SP,
và MPEG-2.

Bộ mã hoá và giải mã âm thanh:

(chuẩn) AAC

Xem phần 5.1.3 để biết chi tiết về AAC và các biến thể của AAC.

AAC với tính năng lấy khung hình ADTS và thẻ ID3

ISO 13818-7

Xem mục 5.1.1 để biết chi tiết về AAC và các biến thể của nó

WebVTT

RTSP (RTP, SDP)

Tên hồ sơ	(Các) tệp đối chiếu	Hỗ trợ bộ mã hoá và giải mã bắt buộc
H264 AVC	RFC 6184	Xem mục 5.1.8 để biết thông tin chi tiết về H264 AVC
MP4A – Mỹ La-tinh	RFC 6416	Xem mục 5.1.3 để biết chi tiết về AAC và các biến thể của nó
H263 – 1998	RFC 3551 RFC 4629 RFC 2190	Xem mục 5.1.8 để biết thông tin chi tiết về H263
H263 – 2000	RFC 4629	Xem mục 5.1.8 để biết thông tin chi tiết về H263
AMR (giờ AMR)	RFC 4867	Xem mục 5.1.3 để biết chi tiết về AMR-NB
AMR-WB	RFC 4867	Xem mục 5.1.3 để biết chi tiết về AMR-WB
MP4V-ES	RFC 6416	Xem mục 5.1.8 để biết chi tiết về MPEG-4 SP
mpeg4 chung	RFC 3640	Xem mục 5.1.3 để biết chi tiết về AAC và các biến thể của nó
MP2T	RFC 2250	Xem Luồng truyền tải MPEG-2 bên dưới Phát trực tiếp HTTP để biết chi tiết

5,8. Nội dung nghe nhìn bảo mật

Nếu quá trình triển khai thiết bị có hỗ trợ đầu ra video an toàn và có thể hỗ trợ các bề mặt bảo mật, chúng:

[C-1-1] PHẢI khai báo khả năng hỗ trợ cho Display.FLAG_SECURE.

Nếu các phương thức triển khai thiết bị có khai báo khả năng hỗ trợ cho Display.FLAG_SECURE hay không giao thức hiển thị không dây, chúng:

[C-2-1] PHẢI bảo mật đường liên kết bằng một cơ chế mạnh được mã hoá như vậy như HDCP 2.x trở lên cho các màn hình kết nối qua giao thức không dây chẳng hạn như Miracast.

Nếu các phương pháp triển khai thiết bị có khai báo tính năng hỗ trợ cho Display.FLAG_SECURE và hỗ trợ màn hình bên ngoài có dây, chúng:

[C-3-1] PHẢI hỗ trợ HDCP 1.2 trở lên cho tất cả các màn hình ngoài được kết nối qua cổng có dây mà người dùng có thể truy cập.

5,9. Giao diện kỹ thuật số nhạc cụ (MIDI)

Nếu quá trình triển khai thiết bị có hỗ trợ tính năng android.software.midi hay không qua android.content.pm.PackageManager lớp, chúng:

[C-1-1] PHẢI hỗ trợ MIDI trên tất cả phương thức truyền tải phần cứng có hỗ trợ MIDI cho chúng cung cấp kết nối chung không phải MIDI, trong đó các kiểu vận chuyển như vậy là:
- Chế độ hỗ trợ USB, phần 7.7
- MIDI trên Bluetooth LE hoạt động ở vai trò trung tâm, mục 7.4.3
[C-1-2] PHẢI hỗ trợ truyền tải phần mềm MIDI giữa các ứng dụng (thiết bị MIDI ảo)
[C-1-3] PHẢI include libamidi.so (hỗ trợ MIDI gốc)
NÊN hỗ trợ MIDI qua chế độ thiết bị ngoại vi USB, mục 7.7

5,10. Âm thanh chuyên nghiệp

Nếu quá trình triển khai thiết bị báo cáo có hỗ trợ tính năng android.hardware.audio.pro qua android.content.pm.PackageManager lớp, chúng:

[C-1-1] PHẢI báo cáo hỗ trợ cho tính năng android.hardware.audio.low_latency.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-2] PHẢI ~~có âm thanh trọn vòng liên tục độ trễ~~, đáp ứng độ trễ các yêu cầu đối với FEATURE_AUDIO_PRO như đã xác định trong phần 5.6 Độ trễ âm thanh ~~của 25 mili giây trở xuống trong ít nhất một lần hỗ trợ path~~.

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

[C-1-3] PHẢI bao gồm(các) cổng USB hỗ trợ chế độ máy chủ USB và USB chế độ thiết bị ngoại vi.
[C-1-4] PHẢI báo cáo hỗ trợ cho tính năng android.software.midi.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-5] PHẢI meet ~~độ trễ và~~ âm thanh USB yêu cầu về độ trễ sử dụng Âm thanh gốc AAudio API và AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

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

[C-1-6] PHẢI có độ trễ đầu ra Lạnh từ 200 mili giây trở xuống.
[C-1-7] PHẢI có độ trễ đầu vào Lạnh từ 200 mili giây trở xuống.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-8] PHẢI có độ trễ Nhấn để âm trung bình là 80 mili giây trở xuống qua ít nhất 5 lần đo đường dẫn dữ liệu từ loa đến micrô.

[C-SR-1] Are mã ĐỀ XUẤT NÊN đáp ứng độ trễ như được xác định trong phần Độ trễ âm thanh 5.6, 20 mili giây hoặc nhỏ hơn, trên 5 phép đo với Độ lệch tuyệt đối trung bình nhỏ hơn 5 mili giây qua đường dẫn từ loa đến micrô.

[C-SR-2] Giới thiệu về danh sách các khuyến mãi được đề xuất nhằm đáp ứng các yêu cầu về Âm thanh chuyên nghiệp cho độ trễ âm thanh trọn vòng liên tục, độ trễ đầu vào nguội và đầu ra nguội độ trễ và yêu cầu về âm thanh USB sử dụng API âm thanh gốc AAudio trên đường dẫn MMAP.

[C-SR-3] Are mã ĐỀ XUẤT NÊN cung cấp mức CPU nhất quán hiệu suất trong khi âm thanh đang hoạt động và tải CPU thay đổi. Bạn cần kiểm tra vấn đề này thông qua ứng dụng SynthMark dành cho Android. SynthMark sử dụng bộ tổng hợp phần mềm chạy trên khung âm thanh mô phỏng để đo lường hiệu suất của hệ thống. Xem Tài liệu SynthMark để xem nội dung giải thích về các điểm chuẩn. SynthMark ứng dụng cần được chạy bằng cách sử dụng "Kiểm thử tự động" và đạt được các kết quả sau:

nhãn hiệu thoại.90 >= 32 giọng nói

latencymark.fixed.little <= 15 mili giây

trễmark.dynamic.little <= 50 mili giây

NÊN giảm thiểu độ không chính xác và độ lệch của đồng hồ âm thanh so với giờ chuẩn.

NÊN giảm thiểu độ lệch xung nhịp âm thanh so với CLOCK_MONOTONIC của CPU khi cả hai đều hoạt động.

NÊN giảm thiểu độ trễ âm thanh trên bộ chuyển đổi trên thiết bị.

NÊN giảm thiểu độ trễ âm thanh đối với âm thanh kỹ thuật số USB.

NÊN ghi lại các phép đo độ trễ âm thanh trên tất cả đường dẫn.

NÊN giảm thiểu dao động trong thời gian nhập lệnh gọi lại hoàn thành vùng đệm âm thanh, vì đây là sẽ ảnh hưởng đến tỷ lệ phần trăm băng thông đầy đủ của CPU có thể sử dụng bằng lệnh gọi lại.

NÊN cung cấp sự cố âm thanh bằng không trong điều kiện sử dụng bình thường với độ trễ được báo cáo.

PHẢI cung cấp mức chênh lệch về độ trễ liên kênh bằng 0.

NÊN giảm thiểu độ trễ trung bình MIDI trên tất cả truyền tải.

NÊN giảm thiểu sự biến đổi độ trễ MIDI trong quá trình tải (dao động) trên tất cả truyền tải.

NÊN cung cấp dấu thời gian MIDI chính xác trên mọi phương thức truyền tải.

NÊN giảm thiểu tiếng ồn tín hiệu âm thanh trên các đầu dò trên thiết bị, bao gồm khoảng thời gian ngay sau khi khởi động nguội.

NÊN cung cấp chênh lệch đồng hồ âm thanh bằng 0 giữa vế đầu vào và đầu ra của điểm cuối tương ứng, khi cả hai đều hoạt động. Ví dụ về thuộc tính tương ứng các điểm cuối bao gồm micrô và loa trên thiết bị hoặc đầu vào giắc âm thanh và đầu ra.

NÊN xử lý lệnh gọi lại hoàn thành vùng đệm âm thanh cho phía đầu vào và đầu ra của điểm cuối tương ứng trên cùng một luồng khi cả hai đều hoạt động và nhập lệnh gọi lại đầu ra ngay sau khi được trả về từ lệnh gọi lại đầu vào. Hoặc nếu không thể xử lý các lệnh gọi lại trên cùng một luồng, thì hãy nhập phương thức gọi lại ngay sau khi nhập lệnh gọi lại đầu vào để cho phép ứng dụng để có thời gian nhất quán cho mặt đầu vào và đầu ra.

NÊN giảm thiểu độ lệch pha giữa bộ đệm âm thanh HAL cho đầu vào và phía đầu ra của các điểm cuối tương ứng.

NÊN giảm thiểu độ trễ cảm ứng.

NÊN giảm thiểu sự biến đổi độ trễ cảm ứng trong quá trình tải (dao động).

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị đáp ứng tất cả yêu cầu trên, thì họ sẽ:

[C-SR-4] mã hoá vạch ra để báo cáo hỗ trợ cho tính năng android.hardware.audio.pro qua android.content.pm.PackageManager .

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

Nếu cách triển khai thiết bị bao gồm giắc cắm âm thanh 3,5 mm 4 dây dẫn, thì chúng:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-2-1] PHẢI có độ trễ âm thanh trọn vòng liên tục trung bình, như được xác định trong mục 5.6 Độ trễ âm thanh, tối đa 20 mili giây, trên 5 lần đo với Độ lệch tuyệt đối trung bình dưới 5 mili giây trong khoảng thời gian bằng cách sử dụng Thiết bị phần cứng lặp lại âm thanh.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-2-2] ~~[C-SR-5]~~ ~~ĐƯỢC ĐỀ XUẤT CHO~~ PHẢI tuân thủ mục Thông số kỹ thuật của thiết bị di động (jack) về Thông số kỹ thuật của tai nghe âm thanh có dây (v1.1).

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

Nếu triển khai thiết bị, bỏ qua giắc âm thanh 4 dây dẫn 3,5 mm và bao gồm(các) cổng USB hỗ trợ chế độ hỗ trợ USB, chúng:

[C-3-1] PHẢI triển khai lớp âm thanh USB.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-3-2] PHẢI có độ trễ âm thanh trọn vòng liên tục trung bình là 25 mili giây trở xuống, trên 5 lần đo có Độ lệch tuyệt đối trung bình dưới 5 mili giây qua cổng chế độ máy chủ USB sử dụng lớp âm thanh USB. (Bạn có thể kiểm tra kết quả này bằng bộ chuyển đổi USB-3.5mm và Audio Loopback Thiết bị phần cứng hoặc sử dụng giao diện âm thanh USB có cáp nối kết nối đầu vào thành đầu ra).

[C-SR-6] Are mã hoá NÊN hỗ trợ đồng thời I/O lên đến 8 kênh mỗi hướng, tốc độ lấy mẫu 96 kHz và độ sâu 24 bit hoặc 32 bit, khi được sử dụng với thiết bị ngoại vi âm thanh USB cũng hỗ trợ các yêu cầu này.

[C-SR-7] Are Internet ĐỀ XUẤT NÊN đáp ứng nhóm yêu cầu này bằng cách sử dụng API âm thanh gốc AAudio qua đường dẫn MMAP.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị có bao gồm cả cổng HDMI, thì các quá trình triển khai thiết bị đó sẽ:

NÊN hỗ trợ đầu ra ở dạng âm thanh nổi và 8 kênh ở độ phân giải 20 bit hoặc Độ sâu 24 bit và 192 kHz mà không mất độ sâu bit hoặc lấy mẫu lại, trong ít nhất một cấu hình.

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

5,11. Ghi lại để xử lý

Android có hỗ trợ ghi âm âm thanh chưa xử lý thông qua Nguồn âm thanh android.media.MediaRecorder.AudioSource.UNPROCESSED. Trong OpenSL ES có thể truy cập được bằng chế độ đặt sẵn bản ghi SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Nếu các hoạt động triển khai thiết bị có ý định hỗ trợ nguồn âm thanh chưa xử lý và thực hiện dành cho các ứng dụng bên thứ ba, họ:

[C-1-1] PHẢI báo cáo dịch vụ hỗ trợ thông qua android.media.AudioManager thuộc tính PROPERTY_UPDATE_AUDIO_SOURCE_UNALERT.
[C-1-2] PHẢI thể hiện biên độ phẳng gần đúng đặc điểm trong dải tần số giữa: cụ thể là ±10 dB từ 100 Hz đến 7000 Hz cho mỗi micrô dùng để ghi lại dữ liệu chưa xử lý nguồn âm thanh.
[C-1-3] PHẢI thể hiện các mức biên độ ở tần số thấp phạm vi: cụ thể là từ ±20 dB từ 5 z đến 100 Hz so với phạm vi tần số giữa của từng micrô dùng để ghi âm nguồn âm thanh chưa xử lý.
[C-1-4] PHẢI thể hiện các mức biên độ ở tần số cao phạm vi: cụ thể là từ ±30 dB từ 7000 Hz đến 22 KHz so với phạm vi tần số giữa của từng micrô dùng để ghi âm nguồn âm thanh chưa xử lý.
[C-1-5] PHẢI đặt độ nhạy đầu vào âm thanh sao cho hình sin 1000 Hz nguồn âm phát ở Mức áp suất âm thanh (SPL) 94 dB tạo ra phản hồi có RMS 520 cho mẫu 16 bit (hoặc -36 dB Tỷ lệ đầy đủ cho dấu phẩy động/kép mẫu có độ chính xác) cho mỗi micrô dùng để ghi lại dữ liệu chưa xử lý nguồn âm thanh.
[C-1-6] PHẢI có tỷ lệ tín hiệu trên nhiễu (SNR) ở mức 60 dB trở lên đối với từng micrô dùng để ghi lại nguồn âm thanh chưa xử lý. (trong khi SNR được đo là mức chênh lệch giữa 94 dB SPL và nhóm kênh tương đương SPL của hiệu ứng tự nhiễu, trọng số A).
[C-1-7] PHẢI có tổng độ méo hài (THD) nhỏ hơn 1% cho 1 kHZ ở mức đầu vào SPL 90 dB ở mỗi và mọi micrô dùng để ghi lại nguồn âm thanh chưa xử lý.
[C-1-8] KHÔNG ĐƯỢC có bất kỳ chức năng xử lý tín hiệu nào khác (ví dụ: Tăng tín hiệu tự động Kiểm soát, Bộ lọc thông minh cao hoặc loại bỏ Tiếng vọng) trong đường dẫn không phải là hệ số cấp để đưa cấp đến phạm vi mong muốn. Hay nói cách khác:
- [C-1-9] Nếu có bất kỳ quá trình xử lý tín hiệu nào trong kiến trúc cho bất kỳ lý do, bạn PHẢI tắt tính năng này và đưa ra độ trễ bằng 0 một cách hiệu quả hoặc độ trễ bổ sung đối với đường dẫn tín hiệu.
- [C-1-10] Số nhân mức, trong khi được phép ở trên đường dẫn, 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 đượ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ô, những yêu cầu này áp dụng cho từng micrô.

Nếu quá trình triển khai thiết bị khai báo android.hardware.microphone nhưng không khai báo hỗ trợ nguồn âm thanh chưa xử lý, chúng:

[C-2-1] PHẢI trả về null cho AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API để chỉ ra một cách thích hợp việc thiếu tính năng hỗ trợ.
[C-SR-1] are Still Sử dụng danh sách các yêu cầu để đáp ứng được nhiều yêu cầu cho đường dẫn tín hiệu cho nguồn ghi chưa được 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 tới.

Định dạng pixel

Nếu bộ giải mã video quảng cáo hỗ trợ COLOR_FormatYUVP010, thì:

[C-1-1] PHẢI hỗ trợ định dạng P010 để đọc bằng CPU (ImageReader, MediaImage, ByteBuffer). Trong Android 13, P010 được nới lỏng để cho phép sải chân tùy ý cho Y và máy bay UV.
[C-1-2] Bộ đệm đầu ra P010 PHẢI có thể được GPU lấy mẫu (khi được phân bổ với mức sử dụng GPU_SAMPLING). Điều này cho phép cấu trúc GPU và tuỳ chỉnh điều chỉnh tông màu theo ứng dụng.

Nếu bộ giải mã video quảng cáo khả năng hỗ trợ COLOR_Format32bitABGR2101010, thì trình đó:

[C-2-1] PHẢI hỗ trợ định dạng RGBA_1010102 cho bề mặt đầu ra và CPU có thể đọc được (đầu ra ByteBuffer).

Nếu một bộ mã hoá video quảng cáo khả năng hỗ trợ COLOR_FormatYUVP010, thì bộ mã hoá đó sẽ:

[C-3-1] PHẢI hỗ trợ định dạng P010 cho bề mặt đầu vào và khả năng ghi bằng CPU Đầu vào (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à CPU-ghi Đầu vào (ImageWriter, ByteBuffer). Lưu ý: Chuyển đổi giữa các phương thức chuyển dữ liệu khác nhau đường cong KHÔNG được yêu cầu cho bộ mã hoá.

Yêu cầu chụp HDR

Đối với tất cả bộ mã hoá video có hỗ trợ hồ sơ HDR, cách triển khai thiết bị:

[C-5-1] KHÔNG ĐƯỢC giả định rằng siêu dữ liệu HDR là chính xác. Ví dụ: khung được mã hoá có thể có các pixel vượt quá độ chói cao nhất hoặc biểu đồ có thể không đại diện cho khung.
NÊN tổng hợp siêu dữ liệu động HDR để tạo hình ảnh HDR tĩnh thích hợp siêu dữ liệu cho các luồng được mã hoá và họ nên xuất siêu dữ liệu này ở cuối mỗi luồng phiên mã hoá.

Nếu các quá trình triển khai thiết bị có hỗ trợ tính năng chụp HDR bằng API CamcorderProfile thì họ:

[C-6-1] cũng PHẢI hỗ trợ chụp HDR thông qua API Camera2.
[C-6-2] PHẢI hỗ trợ ít nhất một bộ mã hoá video được tăng tốc phần cứng cho từng công nghệ HDR được hỗ trợ.
[C-6-3] PHẢI hỗ trợ (ở mức tối thiểu) chụp HLG.
[C-6-4] PHẢI hỗ trợ ghi siêu dữ liệu HDR (nếu áp dụng cho HDR vào tệp video đã quay. Dành cho chuẩn AV1, HEVC và DolbyVision điều này có nghĩa là đưa 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ợ ánh xạ âm HDR sang SDR theo chế độ mặc định bộ giải mã được tăng tốc phần cứng cho hồ sơ đã chụp. Nói cách khác, nếu thiết bị có thể quay video HDR10+ HEVC thì bộ giải mã HEVC mặc định PHẢI dùng được để giải mã luồng đã chụp trong SDR.

Yêu cầu về chỉnh sửa HDR

Nếu phương thức triển khai trên thiết bị bao gồm bộ mã hoá video có hỗ trợ chỉnh sửa HDR, thì chúng:

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ý linh hoạt các tình huống có siêu dữ liệu cho một số một số khung hình khác. Siêu dữ liệu này PHẢI chính xác (ví dụ: biểu thị độ chói cực đại thực tế và biểu đồ của khung).

Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá và giải mã có hỗ trợ FEATURE_HdrEditing, thì những bộ mã hoá và giải mã đó:

[C-7-1] PHẢI hỗ trợ ít nhất một cấu hình HDR.
[C-7-2] PHẢI hỗ trợ FEATURE_HdrEditing cho tất cả cấu hình HDR được quảng cáo bởi bộ mã hoá và giải mã đó. Nói cách khác, các định dạng này PHẢI hỗ trợ tạo siêu dữ liệu HDR khi không có trên một số cấu hình HDR được hỗ trợ và sử dụng siêu dữ liệu HDR.
[C-7-3] PHẢI hỗ trợ các định dạng đầu vào bộ mã hoá video sau đây hoàn toàn giữ nguyên tín hiệu đã giải mã HDR:
- RGBA_1010102 (đã ở trong đường cong chuyển mục tiêu) cho cả đầu vào surface và ByteBuffer và PHẢI quảng cáo hỗ trợ cho COLOR_Định dạng32bitABGR2101010.

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

[C-7-4] PHẢI quảng cáo hỗ trợ cho tiện ích OpenGL EXT_YUV_target.

6. Khả năng tương thích với 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 cung cấp trong Android SDK.
Cầu gỡ lỗi Android (adb)

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-0-2] PHẢI hỗ trợ adb như được ghi lại trong SDK Android và shell các lệnh được cung cấp trong AOSP (Dự án nguồn mở Android) mà nhà phát triển ứng dụng có thể sử dụng, bao gồm dumpsys, cmd statsvà Simpleperf.

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

[C-0-11] PHẢI hỗ trợ lệnh shell cmd testharness. Đang nâng cấp thiết bị nào được triển khai từ phiên bản Android trước đó mà không có khối dữ liệu cố định CÓ THỂ được miễn trừ khỏi C-0-11.
[C-0-3] KHÔNG ĐƯỢC thay đổi định dạng hoặc nội dung của hệ thống thiết bị sự kiện (Batterystats, Disstats, vân tay, Graphicstats, netstats, notification, procstats) được ghi lại qua lệnh dumpsys.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-0-10] PHẢI ghi lại, không bỏ sót và thực hiện các sự kiện sau có thể truy cập và dùng được cho lệnh shell cmd stats và Lớp API Hệ thống StatsManager.
- ActivityForegroundStateChanged
- Đã phát hiện hoạt động bất thường
- Đã báo cáo đường dẫn ứng dụng
- Đã xảy ra sự cố AppCrash
- Bắt đầu xuất hiện ứng dụng
- Đã thay đổi mức pin
- BatterySaverModeStateChanged
- Đã nhận được BlescanResultReceived
- BleScanStateChanged
- ChargeStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- Bàn phím được định cấu hình
- KeyboardSystemsEventReported
- Cắm trạng thái đã thay đổi
- Đã lên lịch JobStateChanged
- ScreenStateChanged
- SyncStateChanged
- Hệ thống đã trôi qua theo thời gian thực
- Sử dụng bàn di chuột
- UidProcessStateChanged
- Trạng thái WakelockĐã thay đổi
- Báo thức
- WifiLockStateChanged
- Wi-FiMulticastLockStateChanged
- WifiQuétStateChanged

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

[C-0-4] PHẢI có trình nền adb phía thiết bị không hoạt động theo mặc định và PHẢI có một cơ chế mà người dùng có thể truy cập để bật Trình gỡ lỗi Android Cầu.
[C-0-5] PHẢI hỗ trợ adb an toàn. Android có hỗ trợ tính năng bảo mật adb. adb bảo mật bật adb trên các máy chủ đã xác thực đã biết.
[C-0-6] PHẢI cung cấp cơ chế cho phép kết nối adb từ một máy chủ. Cụ thể:

Nếu các quá trình triển khai thiết bị không có cổng USB hỗ trợ chế độ ngoại vi, thì các quá trình triển khai thiết bị không hỗ trợ chế độ ngoại vi:

[C-3-1] PHẢI triển khai adb 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 quá trình triển khai thiết bị hỗ trợ kết nối adb với máy chủ lưu trữ qua Wi-Fi hoặc Ethernet, các thiết bị này:

[C-4-1] PHẢI có phương thức AdbManager#isAdbWifiSupported() trả về true.

Nếu quá trình triển khai thiết bị hỗ trợ kết nối adb với máy chủ lưu trữ qua Wi-Fi hoặc Ethernet và bao gồm ít nhất một máy ảnh, chúng:

[C-5-1] PHẢI có phương thức AdbManager#isAdbWifiQrSupported() trả về true.

Dịch vụ theo dõi gỡ lỗi Dalvik (ddms)
- [C-0-7] PHẢI hỗ trợ tất cả các tính năng ddms như được ghi lại trong 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 Cầu gỡ lỗi Android, như trên.
SysTrace
- [C-0-9] PHẢI hỗ trợ công cụ systrace như được ghi trong SDK Android. Theo mặc định, Systrace phải không hoạt động và người dùng PHẢI có thể truy cập bật Systrace.
Perfetto
- [C-SR-1] AreĐể các đối tượng xuất hiện trong danh sách phát /system/bin/perfetto tệp nhị phân cho người dùng shell mà lệnh cmdline tuân thủ tài liệu về perfetto.
- [C-SR-2] Các perfetto binary is Internetuy danh để chấp nhận làm dữ liệu đầu vào a cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-3] Các perfetto binary is Internet được ĐỀ XUẤT để ghi dưới dạng đầu ra a dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-4] Are trì hoãng ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
Giảm dung lượng bộ nhớ thấp
- [C-0-12] PHẢI ghi một Atom LMK_KILL_OCCURRED_FIELD_NUMBER vào nhật ký số liệu thống kê khi một ứng dụng bị chấm dứt bởi Low Memory Killer.
Chế độ khai thác thử nghiệm Nếu các phương thức triển khai thiết bị hỗ trợ lệnh shell cmd testharness và chạy cmd testharness enable, chúng:
- [C-2-1] PHẢI trả về true cho ActivityManager.isRunningInUserTestHarness()
- [C-2-2] PHẢI triển khai Chế độ khai thác kiểm thử như mô tả trong Tài liệu về Chế độ khai thác kiểm thử.
Thông tin 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 công việc GPU tổng hợp do nhân power/gpu_work_period trả về hoặc không hiển thị dữ liệu nếu điểm theo dõi không được hỗ trợ. AOSP (Dự án nguồn mở Android) là frameworks/native/services/gpuservice/gpuwork/.

Nếu quá trình triển khai thiết bị báo cáo có hỗ trợ Vulkan 1.0 trở lên thông qua android.hardware.vulkan.version có tính năng cờ, chúng:

[C-1-1] PHẢI cung cấp thuộc tính tương tác cho nhà phát triển ứng dụng để bật/tắt Các lớp gỡ lỗi GPU.
[C-1-2] PHẢI, khi các lớp gỡ lỗi GPU được bật, liệt kê các lớp trong thư viện do 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 tìm thấy trong các ứng dụng có thể gỡ lỗi' thư mục cơ sở sang hỗ trợ vkEnumerateInstanceLayerProperties() và vkCreateInstance() Phương thức API.

6.2. Tuỳ chọn cho nhà phát triển

Android hỗ trợ các nhà phát triển định cấu hình ứng dụng các chế độ cài đặt liên quan đến quá trình phát triển.

Quá trình triển khai thiết bị PHẢI cung cấp trải nghiệm nhất quán cho Tuỳ chọn dành cho nhà phát triển, họ:

[C-0-1] PHẢI thực hiện android.settings.APPLICATION_DEVELOPMENT_SETTINGS ý định hiển thị các cài đặt liên quan đến việc phát triển ứng dụng. Android ngược dòng Theo mặc định, quá trình triển khai ẩn trình đơn Tuỳ chọn cho nhà phát triển và cho phép người dùng khởi chạy Tuỳ chọn cho nhà phát triển sau khi nhấn bảy (7) lần trên Cài đặt > Giới thiệu về thiết bị > Mục trong trình đơn Build Number (Số bản dựng).
[C-0-2] PHẢI ẩn Tuỳ chọn dành 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 đưa ra ưu tiên đối với ứng dụng bên thứ ba chứ không phải ứng dụng khác để cho phép Nhà phát triển Tuỳ chọn. PHẢI cung cấp tài liệu hoặc trang web hiển thị công khai mô tả cách bật Tùy chọn cho nhà phát triển. Tài liệu hoặc trang web này PHẢI có thể liên kết được tài liệu SDK Android.
PHẢI có thông báo bằng hình ảnh liên tục cho người dùng khi Nhà phát triển Các tuỳ chọn được bật và sự an toàn của người dùng là mối quan tâm.
CÓ THỂ tạm thời giới hạn 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 vô hiệu hoá trình đơn, để tránh bị phân tâm trong các tình huống mà sự an toàn của người dùng là mối quan tâm.

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

Nếu thiết bị bao gồm một thành phần phần cứng cụ thể có API dành cho nhà phát triển bên thứ ba:

[C-0-1] Việc triển khai thiết bị PHẢI triển khai điều đó API theo mô tả trong tài liệu về 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 chỉ định là không bắt buộc và phương thức triển khai thiết bị không sở hữu thành phần đó:

[C-0-2] Định nghĩa đầy đủ về lớp (theo tài liệu của SDK) cho thành phần API PHẢI vẫn hiển thị.
[C-0-3] Hành vi của API PHẢI được triển khai dưới dạng không hoạt động trong một số trường hợp hợp lý thời trang.
[C-0-4] Các phương thức API PHẢI trả về các giá trị rỗng nếu SDK cho phép tài liệu.
[C-0-5] Các phương thức API PHẢI trả về cách triển khai không hoạt động của các lớp nơi có giá trị rỗng mà tài liệu SDK không cho phép.
[C-0-6] Các phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được SDK ghi lại tài liệu.
[C-0-7] Các quá trình triển khai trên thiết bị PHẢI báo cáo phần cứng một cách nhất quán thông tin cấu hình qua getSystemAvailableFeatures() và hasSystemFeature(String) phương thức trên android.content.pm.PackageManager cho cùng một vân tay số của bản dựng.

Ví dụ điển hình về tình huống mà các yêu cầu này áp dụng là số điện thoại API: Ngay cả trên thiết bị không phải là điện thoại, các API này cũng phải được triển khai sao cho hợp lý không hoạt động.

7.1. Màn hình và đồ hoạ

Android có các cơ sở tự động điều chỉnh thành phần và giao diện người dùng của ứng dụng có bố cục 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 cấu hình và màn hình phần cứng. Một Màn hình tương thích với Android là màn hình hiển thị triển khai tất cả hành vi và API được mô tả trong bài viết Nhà phát triển Android – Khả năng tương thích với màn hình tổng quan, đây là (7.1) và các tiểu mục của nó, cũng như bất kỳ loại thiết bị bổ sung nào. các hành vi cụ thể được ghi nhận trong phần 2 của chính sách này CDD.

Triển khai thiết bị:

[C-0-1] PHẢI, theo mặc định, chỉ hiển thị ứng dụng của bên thứ ba lên Màn hình tương thích với Android.

Các đơn vị được tham chiếu theo yêu cầu trong mục này được định nghĩa như sau:

kích thước đường chéo thực tế. Khoảng cách tính theo inch giữa hai đối diện các góc của phần được chiếu sáng trên màn hình.
mật độ. Số pixel được bao quanh bởi đường thẳng ngang hoặc dọc là 1", được biểu thị bằng pixel mỗi inch (ppi hoặc dpi). Nơi các giá trị ppi và dpi được liệt kê, cả dpi ngang và dọc đều phải nằm trong phạm vi đã nêu.
tỷ lệ khung hình. Tỷ lệ các pixel có kích thước dài hơn so với kích thước màn hình ngắn hơn. Ví dụ: màn hình 480x854 pixel sẽ là 854/480 = 1, 779 hoặc 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ố pixel p là số 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 bố cục màn hình logic khác nhau và cho phép các ứng dụng truy vấn màn hình của cấu hình hiện tại kích thước bố cục qua Configuration.screenLayout với SCREENLAYOUT_SIZE_MASK và Configuration.smallestScreenWidthDp.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo kích thước bố cục chính xác cho Configuration.screenLayout theo định nghĩa trong tài liệu SDK Android. Cụ thể, các quá trình triển khai thiết bị PHẢI báo cáo logic chính xác kích thước màn hình pixel không phụ thuộc vào mật độ (dp) như dưới đây:
- Các thiết bị có Configuration.uiMode được đặt dưới dạng 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 thuộc tính 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 nhất 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 nhất 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 nhất là 960 dp x 720 dp.
[C-0-2] PHẢI tuân thủ chính xác các ứng dụng đã nêu hỗ trợ cho kích thước màn hình thông qua <supports-screens> trong AndroidManifest.xml, như được mô tả trong tài liệu SDK Android.
CÓ THỂ có(các) màn hình tương thích với Android với góc bo tròn.

Nếu quá trình triển khai thiết bị hỗ trợ màn hình có khả năng Cấu hình kích thước UI_MODE_TYPE_NORMAL và sử dụng(các) màn hình thực có góc bo tròn để kết xuất những màn hình này, chúng:

[C-1-1] PHẢI đảm bảo rằng ít nhất một trong các yêu cầu sau được đáp ứng cho mỗi màn hình như vậy:
- Bán kính của các góc bo tròn nhỏ hơn hoặc bằng 38 dp.
- Khi hộp 18 dp x 18 dp được neo ở mỗi góc của thuộc tính logic hiển thị, ít nhất một pixel của mỗi hộp hiển thị trên màn hình.
NÊN bao gồm khả năng tương tác của người dùng để chuyển sang chế độ hiển thị bằng góc hình chữ nhật.

Nếu các phương thức triển khai thiết bị chỉ có thể cấu hình bàn phím NO_KEYS, và dự định báo cáo việc hỗ trợ cho chế độ giao diện người dùng UI_MODE_TYPE_NORMAL cấu hình, chúng:

[C-4-1] PHẢI có kích thước bố cục, ngoại trừ mọi vết cắt trên màn hình, tối thiểu là 596 dp x 384 dp trở lên.

Để biết thông tin chi tiết về cách triển khai chính xác API trợ giúp hoặc API tiện ích, hãy tham khảo đối với tài liệu công khai của Window Manager Jetpack (Trình quản lý cửa sổ Jetpack).

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị bao gồm một hoặc nhiều khu vực hiển thị tương thích với Android thiết bị có thể gập lại hoặc có bản lề gập giữa nhiều thiết bị Các khu vực trên bảng điều khiển hiển thị tương thích với Android và cung cấp các khu vực hiển thị đó cho ứng dụng, chúng:

[C-4-1] PHẢI triển khai phiên bản chính xác của Tiện ích Trình quản lý cửa sổ Cấp độ API như mô tả trong Tiện ích WindowManager.

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

7.1.1.2. Tỷ lệ khung hình màn hình

Mục 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 mật độ logic chuẩn để giúp nhà phát triển ứng dụng nhắm đến tài nguyên ứng dụng.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo một trong những mật độ khung Android được liệt kê trên DisplayMetrics thông qua DENSITY_DEVICE_STABLE API và giá trị này phải là một 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 hiển thị do người dùng thực hiện (đối với 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 bằng số gần với mật độ vật lý của màn hình nhất hoặc một giá trị sẽ ánh xạ đến cùng các phép đo trường nhìn góc tương đương của thiết bị cầm tay.

Nếu quá trình triển khai thiết bị cung cấp một thuộc tính tương tác cho thay đổi kích thước hiển thị của thiết bị, chúng:

[C-1-1] KHÔNG ĐƯỢC thay đổi tỷ lệ màn hình 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 có hiệu lực nhỏ hơn 320 dp (tương đương cho 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 thay đổi tỷ lệ màn hình nhỏ hơn 0,85 lần DENSITY_DEVICE_STABLE.
Để đảm bảo khả năng sử dụng tốt và kích thước phông chữ nhất quán, bạn nên sử dụng sau đây là việc điều chỉnh tỷ lệ các tuỳ chọn Hiển thị gốc (trong khi vẫn tuân thủ các giới hạn đã 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,3x
- Lớn nhất 1,45x

7.1.2. Chỉ số hiển thị

Nếu quá trình 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 sang(các) màn hình hiển thị tương thích với Android, chúng:

[C-1-1] PHẢI báo cáo giá trị chính xác cho tất cả màn hình tương thích với Android đã xác định trong android.util.DisplayMetrics.

Nếu quá trình triển khai thiết bị không bao gồm màn hình được nhúng hoặc đầu ra video, chúng:

[C-2-1] PHẢI báo cáo 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 hướng màn hình nào 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 báo cáo được hỗ trợ hướng. Ví dụ: thiết bị có hướng ngang cố định màn hì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 dòng điện của thiết bị bất cứ khi nào được truy vấn qua thuộc tính android.content.res.Configuration.orientation, android.view.Display.getOrientation() hoặc các API khác.

Nếu quá trình triển khai thiết bị hỗ trợ cả hai hướng màn hình, thì các thiết bị đó:

[C-1-1] PHẢI hỗ trợ hướng động của các ứng dụng cho màn hình dọc hoặc ngang hướng. Tức là thiết bị phải tuân thủ yêu cầu của ứng dụng về một màn hình cụ thể hướng.
[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ư qua GLES10.getString()) và API gốc.
[C-0-2] PHẢI bao gồm dịch vụ hỗ trợ cho tất cả các API được quản lý tương ứng và cho mọi phiên bản OpenGL ES mà chúng xác định để hỗ trợ.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-1] PHẢI hỗ trợ ~~cả hai~~ OpenGL ES 1.1, và 2.0, 3.0 và 3.1, được thể hiện chi tiết và chi tiết trong tài liệu về SDK Android.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

~~[C-SR-1] Are mã ĐỀ XUẤT NÊN hỗ trợ OpenGL ES 3.1.~~

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

NÊN hỗ trợ OpenGL ES 3.2.

Các phép 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ó ngày/số phiên bản được liên kết. Các tham số 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 nó có thể vượt qua dEQP trong tất cả các danh sách kiểm thử từ cấp này trở xuống.

Nếu quá trình triển khai thiết bị hỗ trợ bất kỳ phiên bản OpenGL ES nào, thì các thiết bị đó:

[C-2-1] PHẢI báo cáo qua OpenGL ES API được quản lý và API gốc bất kỳ các tiện ích OpenGL ES khác mà họ đã triển khai, và ngược lại PHẢI PHẢI KHÔNG báo cáo chuỗi tiện ích mà các chuỗi này không hỗ trợ.
[C-2-2] PHẢI hỗ trợ 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, Tiện ích 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 phép 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ối thiểu cho phiên bản 132383489 (từ ngày 1 tháng 3 năm 2020) thà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 bài kiểm thử OpenGL ES dEQP trong danh sách kiểm thử giữa phiên bản 132383489 và phiên bản được chỉ định trong android.software.opengles.deqp.level cờ tính năng cho mỗi thành phần được hỗ trợ Phiên bản OpenGL ES.
[C-SR-2] AreĐể hỗ trợ EGL_KHR_partial_update và Tiện ích OES_EGL_image_external.
NÊN báo cáo chính xác thông qua phương thức getString(), mọi kết cấu mà chúng hỗ trợ, thường dành riêng cho từng nhà cung cấp.
NÊN hỗ trợ EGL_IMG_context_priority và Tiện ích EGL_EXT_protected_content.

Nếu các quá trình triển khai thiết bị khai báo tính năng hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2, thì chúng:

[C-3-1] PHẢI xuất các biểu tượng hàm tương ứng cho các phiên bản này trong bổ sung vào các biểu tượng hàm OpenGL ES 2.0 trong thư viện libGLESv2.so.
[C-SR-3] AreĐể hỗ trợ OES_EGL_image_external_essl3 tiện ích.

Nếu các quá trình triển khai thiết bị hỗ trợ OpenGL ES 3.2, thì các quá trình triển khai đó:

[C-4-1] PHẢI hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES.

Nếu quá trình triển khai thiết bị hỗ trợ Gói tiện ích Android OpenGL ES trong toàn bộ, chúng:

[C-5-1] PHẢI xác định dịch vụ hỗ trợ thông qua android.hardware.opengles.aep cờ tính năng.

Nếu quá trình triển khai thiết bị có hỗ trợ EGL_KHR_mutable_render_buffer tiện ích, chúng:

[C-6-1] PHẢI cũng hỗ trợ EGL_ANDROID_front_buffer_auto_refresh tiện ích.

7.1.4.2. Vulkan

Android hỗ trợ Vulkan, một API đa nền tảng, mức hao tổn thấp để tạo đồ 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ác hoạt động triển khai trên thiết bị:

[C-SR-1] Are mã ĐỀ XUẤT NÊN bao gồm dịch vụ 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à biến thể của phiên bản lõi Vulkan PHẢI bằng 0).

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

[C-SR-2] Are mã ĐỀ XUẤT NÊN bao gồm dịch vụ hỗ trợ cho Vulkan 1.3.

Các bài kiểm thử dEQP 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 tham số 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 Vulkan có thể vượt qua dEQP trong tất cả các danh sách kiểm thử từ cấp này trở xuống.

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

[C-1-1] PHẢI báo cáo giá trị số nguyên chính xác bằng android.hardware.vulkan.level và android.hardware.vulkan.version cờ tính năng.
[C-1-2] PHẢI liệt kê, ít nhất một VkPhysicalDevice cho Vulkan API gốc vkEnumeratePhysicalDevices().
[C-1-3] PHẢI triển khai đầy đủ các API Vulkan 1.1 cho mỗi API được liệt kê VkPhysicalDevice.
[C-1-4] PHẢI liệt kê các lớp, được chứa trong thư viện gốc có tên là libVkLayer*.so trong thư mục thư viện gốc của gói ứng dụng, thông qua API gốc Vulkan vkEnumerateInstanceLayerProperties() và vkEnumerateDeviceLayerProperties().
[C-1-5] KHÔNG ĐƯỢC liệt kê các lớp do thư viện bên ngoài cung cấp gói ứng dụng của bạn hoặc cung cấp các cách khác để truy vết hay chặn API Vulkan, trừ phi ứng dụng có thuộc tính android:debuggable đặt thành true hoặc siêu dữ liệu com.android.graphics.injectLayers.enable được đặt thành true.
[C-1-6] PHẢI báo cáo tất cả các chuỗi tiện ích mà chúng hỗ trợ qua API gốc Vulkan và ngược lại KHÔNG ĐƯỢC báo cáo chuỗi tiện ích mà chúng không hỗ trợ đúng cách.
[C-1-7] PHẢI hỗ trợ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, và tiện ích VK_KHR_rise_present.
[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] Tối thiểu phải hỗ trợ phiên bản 132317953 (từ ngày 1 tháng 3 năm 2019) thà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ả Kiểm thử dEQP 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ê hỗ trợ cho hàng đợi VK_KHR_video_queue, Các phần mở rộng VK_KHR_video_decode_queue hoặc VK_KHR_video_encode_queue.
[C-SR-3] AreĐể hỗ trợ VK_KHR_driver_properties và VK_GOOGLE_display_timing tiện ích.
[C-1-12] KHÔNG ĐƯỢC liệt kê hỗ trợ cho phần mở rộng VK_KHR_performance_query.
[C-SR-4] Are phong phú NÊN đáp ứng các yêu cầu được chỉ định bởi hồ sơ Android Baseline 2022.
[C-SR-5] Are mã ĐỀ XUẤT NÊN hỗ trợ VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory và VK_EXT_global_priority.
[C-SR-6] Are Internet ĐỀ XUẤT NÊN sử dụng SkiaVk với HWUI.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu quá trình triển khai thiết bị có hỗ trợ Vulkan, thì quá trình triển khai thiết bị:

[C-SR-8] Are Internet ĐỀ XUẤT 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ừ khi các tiện ích này được bao gồm trong Cờ tính năng android.software.vulkan.deqp.level.

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

Nếu các hoạt động triển khai thiết bị không hỗ trợ Vulkan 1.0, thì các hoạt động triển khai thiết bị đó sẽ:

[C-2-1] KHÔNG ĐƯỢC khai báo bất kỳ cờ tính năng nào trong Vulkan (ví dụ: android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] KHÔNG ĐƯỢC liệt kê bất kỳ VkPhysicalDevice nào cho API gốc Vulkan vkEnumeratePhysicalDevices()

Nếu quá trình triển khai thiết bị có hỗ trợ Vulkan 1.1 và khai báo bất kỳ Cờ tính năng Vulkan được mô tả tại đây, chúng:

[C-3-1] PHẢI hiển thị chế độ hỗ trợ cho semaphore và xử lý bên ngoài SYNC_FD và phần mở rộng VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] Are Internet ĐỀ XUẤT NÊN làm cho VK_KHR_external_fence_fd tiện ích mở rộng áp dụng cho các ứng dụng bên thứ ba và cho phép ứng dụng để xuất tải trọng của hàng rào và nhập tải trọng của hàng rào từ tệp POSIX mã mô tả như được 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ư đã nêu chi tiết trong tài liệu SDK Android.

7.1.4.4. Tăng tốc đồ hoạ 2D

Android có một cơ chế để ứng dụng khai báo rằng ứng dụng muốn bật chế độ tăng tốc phần cứng cho đồ hoạ 2D ở các mục Ứng dụng, Hoạt động, Cấp độ cửa sổ hoặc chế độ xem thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp.

Triển khai 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 bật hãy tắt tính năng tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách cài đặt android:hardwareAccelerated="false" hoặc tắt chế độ tăng tốc phần cứng trực tiếp thông qua Android View API (API Khung hiển thị Android).
[C-0-2] PHẢI thể hiện hành vi nhất quán với Tài liệu SDK Android về tính năng tăng tốc phần cứng.

Android có một đối tượng TextureView cho phép nhà phát triển tích hợp trực tiếp hoạ tiết OpenGL ES được tăng tốc phần cứng dưới dạng mục tiêu kết xuất trong 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ợ TextureView API và PHẢI hỗ trợ biểu mẫu hành vi nhất quán với việc triển khai Android ngược dòng.

7.1.4.5. Màn hình rộng

Nếu các quá trình triển khai thiết bị tuyên bố hỗ trợ hiển thị gam màu rộng thông qua Configuration.isScreenWideColorGamut(), họ:

[C-1-1] PHẢI có màn hình được hiệu chỉnh màu.
[C-1-2] PHẢI có một màn hình có gam màu bao phủ gam màu sRGB hoàn toàn trong không gian xyY năm 1931.
[C-1-3] PHẢI có một màn hình có gam màu có diện tích ít nhất là 90% DCI-P3 trong không gian xyY năm 1931.
[C-1-4] PHẢI hỗ trợ OpenGL ES 3.1 hoặc 3.2 và báo cáo nó một cách chính xác.
[C-1-5] PHẢI quảng cáo hỗ trợ cho 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 tiện ích.
[C-SR-1] Are Internet ĐỀ XUẤT NÊN hỗ trợ GL_EXT_sRGB.

Ngược lại, nếu các quá trình triển khai thiết bị không hỗ trợ màn hình gam màu rộng, thì các thiết bị đó sẽ:

[C-2-1] NÊN che phủ 100% hoặc nhiều hơn sRGB trong không gian CIE 1931 xyY, mặc dù gam màu màn hình chưa đượ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 làm việc theo "normal" (bình thường) chế độ kích thước màn hình tương đương (chiều rộng 320 dp) để hưởng lợi ích của phiên bản cũ ứng dụng không được phát triển cho các phiên bản Android cũ 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 hiển thị nội dung đa dạng thức sang màn hình tương thích với Android. Thiết bị PHẢI hỗ trợ tất cả các thiết bị này Các API do SDK Android xác định, 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 trong quy trình triển khai thiết bị:

[C-0-1] PHẢI có khả năng kết xuất đồ hoạ màu 16 bit.
NÊN hỗ trợ các màn hình có khả năng đồ hoạ màu 24 bit.
[C-0-2] PHẢI có khả năng kết xuất ảnh động.
[C-0-3] PHẢI có tỷ lệ khung hình pixel (PAR) từ 0,9 đến 1,15. Tức là tỷ lệ khung hình của pixel PHẢI gần hình vuông (1.0) với dung sai 10 ~ 15%.

7.1.7. Màn hình phụ

Android có hỗ trợ các màn hình phụ tương thích với Android để cho phép khả năng chia sẻ nội dung nghe nhìn và API của nhà phát triển để truy cập vào màn hình bên ngoài.

Nếu quá trình triển khai thiết bị hỗ trợ màn hình bên ngoài thông qua màn hình có dây, không dây hoặc kết nối hiển thị bổ sung được nhúng, chúng:

[C-1-1] PHẢI triển khai phương thức DisplayManager dịch vụ hệ thống và API theo mô tả trong tài liệu SDK Android.

7.2. Thiết bị Đầu vào

Triển khai thiết bị:

[C-0-1] PHẢI bao gồm cơ chế đầu vào, chẳng hạn như màn hình cảm ứng hoặc thao tác không chạm, để di chuyển giữa các thành phần trên giao diện người dùng.

7.2.1. Bàn phím

Nếu quá trình triển khai thiết bị có bao gồm dịch vụ hỗ trợ cho bên thứ ba Ứng dụng Trình chỉnh sửa phương thức nhập (IME), chúng:

[C-1-1] PHẢI khai báo android.software.input_methods cờ tính năng.
[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 trước.

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC bao gồm bàn phím phần cứng không khớp với một trong đị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 mềm khác.
CÓ THỂ bao gồm bàn phím phần cứng.

7.2.2. Điều hướng không chạm

Android có hỗ trợ d-pad, bi xoay và bánh xe làm cơ chế cho điều hướng không chạm.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo giá trị chính xác cho android.content.res.Configuration.navigation.

Nếu quá trình triển khai thiết bị không có tính năng điều hướng không chạm, thì các quá trình triển khai thiết bị sẽ:

[C-1-1] PHẢI cung cấp một cơ chế giao diện người dùng thay thế hợp lý cho lựa 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. Chiến lược phát hành đĩa đơn việc triển khai nguồn mở Android ngược dòng bao gồm cơ chế lựa chọn phù hợp để sử dụng với các thiết bị không có đầu vào điều hướng không chạm.

7.2.3. Phím điều hướng

Trang chủ, Gần đây, và Quay lại chức năng thường được cung cấp thông qua 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à điều thiết yếu đối với Android mô hình điều hướng và do đó, việc triển khai thiết bị:

[C-0-1] PHẢI cung cấp khả năng tương tác của người dùng để khởi chạy các ứng dụng đã cài đặt có một hoạt động với <intent-filter> được đặt bằng ACTION=MAIN và CATEGORY=LAUNCHER hoặc CATEGORY=LEANBACK_LAUNCHER cho thiết bị TV thực tế. Hàm Home PHẢI là cơ chế cho thuộc tính tương tác của người dùng này.
NÊN cung cấp các nút cho hàm Recents (Gần đây) và Back (Quay lại).

Nếu bạn cung cấp các hàm Home (Trang chủ), Recents (Gần đây) hoặc Back (Quay lại), thì các hàm 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.
[C-1-2] PHẢI cung cấp chỉ báo rõ ràng về hành động đơn lẻ nào sẽ kích hoạt từng hàm. Có một biểu tượng rõ ràng được in trên nút, cho thấy một phần mềm biểu tượng trên phần thanh điều hướng của màn hình hoặc hướng người dùng qua quy trình minh hoạ từng bước có hướng dẫn trong trải nghiệm thiết lập ngay từ đầu ví dụ về dấu hiệu đó.

Triển khai thiết bị:

[C-SR-1] are Still NÊN not cung cấp cơ chế đầu vào cho Hàm trình đơn vì thanh tác vụ này không còn được dùng nữa, thay vào đó là thanh thao tác (action bar) kể từ Android 4.0.
[C-SR-2] Are Để cung cấp tất cả các hàm điều hướng dưới dạng, có thể huỷ được. "Có thể huỷ" được định nghĩa là khả năng của người dùng trong việc ngăn chặn thực thi chức năng điều hướng (ví dụ: quay lại trang chủ, quay lại, v.v.) nếu không được thả ra sau một ngưỡng nhất định.

Nếu các hoạt động triển khai thiết bị cung cấp chức năng Trình đơn, thì chúng:

[C-2-1] PHẢI hiển thị nút tràn hành động bất cứ khi nào hành động cửa sổ bật lên của trình đơn mục bổ sung không trống và thanh tác vụ được hiển thị.
[C-2-2] KHÔNG ĐƯỢC sửa đổi vị trí của cửa sổ bật lên mục bổ sung hành động được hiển thị bằng cách chọn nút mục bổ sung trong thanh tác vụ, nhưng CÓ THỂ hiển thị cửa sổ bật lên mục bổ sung thao tác tại vị trí đã sửa đổi trên màn hình khi được hiển thị bằng cách chọn chức năng Trình đơn.

Nếu quá trình triển khai thiết bị không cung cấp hàm Trình đơn, để quay lại khả năng tương thích, chúng:

[C-3-1] PHẢI đặt hàm Trình đơn ở chế độ có thể sử dụng cho các ứng dụng khi targetSdkVersion nhỏ hơn 10, do nút vật lý hoặc khoá phần mềm, hoặc cử chỉ. Hàm Trình đơn này phải truy cập được trừ phi bị ẩn cùng với các hàm điều hướng khác.

Nếu quá trình triển khai thiết bị cung cấp Chức năng hỗ trợ, chúng:

[C-4-1] PHẢI làm cho chức năng Hỗ trợ có thể truy cập được bằng một hành động duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi người dùng có thể sử dụng các phím điều hướng khác.
[C-SR-3] Để sử dụng chức năng này, hãy nhấn và giữ nút HOME như tương tác được chỉ định.

Nếu quá trình 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ị phím điều hướng, chúng:

[C-5-1] Các phím điều hướng PHẢI sử dụng một phần riêng biệt của màn hình, chứ không phải có sẵn cho các ứng dụng và KHÔNG ĐƯỢC che khuất hay can thiệp vào phần màn hình khả dụng cho ứng dụng.
[C-5-2] PHẢI hiển thị một phần màn hình cho các ứng dụng đáp ứng các yêu cầu nêu trong mục 7.1.1.
[C-5-3] PHẢI tuân thủ cờ do ứng dụng đặt thông qua View.setSystemUiVisibility() API để 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 đi đúng cách như được ghi 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 khu vực nhận dạng cử chỉ Home.
[C-6-2] Các cử chỉ bắt đầu trong phạm vi hình chữ nhật loại trừ được cung cấp bởi của ứng dụng trên nền trước qua View#setSystemGestureExclusionRects()! nhưng bên ngoài WindowInsets#getMandatorySystemGestureInsets(), KHÔNG ĐƯỢC giao với chức năng điều hướng miễn là loại trừ cho phép hình chữ nhật 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 ứng dụng trên nền trước a MotionEvent.ACTION_CANCEL sự kiện sau khi thao tác chạm bắt đầu bị chặn đối với một cử chỉ hệ thống, nếu ứng dụng trên nền trước trước đó đã được gửi MotionEvent.ACTION_DOWN sự kiện.
[C-6-4] PHẢI cung cấp khả năng tương tác của người dùng để chuyển sang màn hình, thao tác bằng nút (ví dụ: trong phần Cài đặt).
NÊN cung cấp chức năng Màn hình chính dưới dạng vuốt lên từ cạnh dưới 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 vuốt lên và giữ trước khi thả ra, từ cùng một khu vực với cử chỉ Màn hình chính.
Cử chỉ bắt đầu trong WindowInsets#getMandatorySystemGestureInsets() KHÔNG ĐƯỢC ảnh hưởng bởi các hình chữ nhật loại trừ được cung cấp bởi nền trước đăng ký qua View#setSystemGestureExclusionRects().

Nếu một hàm điều hướng được cung cấp từ vị trí bất kỳ ở cạnh bên trái và bên phải của hướng hiện tại của màn hình:

[C-7-1] Hàm điều hướng PHẢI là Back và được cung cấp dưới dạng vuốt từ cả cạnh trái và phải theo hướng hiện tại của màn hình.
[C-7-2] Nếu bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh được cung cấp ở bên trái hoặc các cạnh phải, chúng PHẢI được đặt trong khoảng 1/3 trên cùng của màn hình. chỉ báo trực quan rõ ràng, liên tục cho biết việc kéo vào sẽ gọi ra các bảng điều khiển nói trên, chứ không phải biểu tượng Quay lại. Bảng điều khiển hệ thống CÓ THỂ do người dùng định cấu hình sao cho quảng cáo nằm dưới 1/3 phía trên cùng của màn hình (các) cạnh nhưng bảng điều khiển hệ thống KHÔNG ĐƯỢC sử dụng dài hơn 1/3 cạnh.
[C-7-3] Khi ứng dụng trên nền trước có View.SYSTEM_UI_FLAG_IMMERSIVE, Chế độ xem.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, hoặc Đã đặt cờ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, việc vuốt từ các cạnh PHẢI hoạt động như được triển khai trong AOSP, tức là được ghi lại trong SDK.
[C-7-4] Khi ứng dụng trên nền trước có View.SYSTEM_UI_FLAG_IMMERSIVE, Chế độ xem.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, hoặc Đã đặt cờ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh PHẢI được ẩn cho đến khi người dùng đưa vào hoặc hủy giảm độ sáng của thanh hệ thống (còn gọi là thanh điều hướng và thanh trạng thái) như đã triển khai trong AOSP.

Nếu chức năng điều hướng quay lại được cung cấp và người dùng huỷ nút Quay lại cử chỉ, sau đó:

[C-8-1] OnBackInvokedCallback.onBackCancelled() PHẢI được gọi.
[C-8-2] OnBackInvokedCallback.onBackInvoked() KHÔNG ĐƯỢC gọi.
[C-8-3] Sự kiện KEYCODE_BACK KHÔNG ĐƯỢC gửi đi.

Nếu hàm điều hướng quay lại được cung cấp nhưng ứng dụng trên nền trước thì có CHƯA đăng ký OnBackInvokedCallback, thì:

Hệ thống PHẢI cung cấp ảnh động cho ứng dụng trên nền trước cho thấy người dùng sẽ quay lại, như được cung cấp trong AOSP (Dự án nguồn mở Android).

Nếu các quá trình triển khai thiết bị cung cấp hỗ trợ cho API hệ thống setNavBarMode để cho phép mọi ứng dụng hệ thống có quyền android.permission.STATUS_BAR đặt giá trị thanh điều hướng, thì chúng:

[C-9-1] PHẢI cung cấp tính năng hỗ trợ cho các biểu tượng hoặc thành phần dựa trên nút phù hợp với trẻ em điều hướng như được cung cấp trong mã AOSP (Dự án nguồn mở Android).

7.2.4. Nhập vào màn hình cảm ứng

Android hỗ trợ nhiều hệ thống nhập 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 cảm ứng giả. 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 mà người dùng có ấn tượng trực tiếp thao tác với các mục trên màn hình. Vì người dùng chạm trực tiếp vào màn hình, hệ thống không yêu cầu thêm thành phần tương tác nào để chỉ ra các đối tượng đang bị thao túng.

Triển khai thiết bị:

PHẢI có một hệ thống nhập con trỏ ở dạng nào đó (giống như di chuột hoặc chạm).
NÊN hỗ trợ con trỏ được theo dõi hoàn toàn độc lập.

Nếu việc triển khai thiết bị bao gồm màn hình cảm ứng (một lần chạm hoặc cao hơn) trên màn hình chính tương thích với Android, chúng:

[C-1-1] PHẢI báo cáo TOUCHSCREEN_FINGER cho Configuration.touchscreen Trường API.
[C-1-2] PHẢI báo cáo android.hardware.touchscreen và android.hardware.faketouch cờ tính năng.

Nếu bạn triển khai thiết bị bao gồm một màn hình cảm ứng có thể theo dõi nhiều hơn chỉ bằng một lần chạm trên màn hình chính tương thích với Android, họ có thể:

[C-2-1] PHẢI báo cáo cờ tính năng thích hợp android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand tương ứng với loại màn hình cảm ứng cụ thể trên thiết bị.

Nếu việc triển khai thiết bị dựa vào thiết bị đầu vào bên ngoài, chẳng hạn 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 trên Màn hình tương thích với Android và đáp ứng các yêu cầu về cảm ứng giả trong mục 7.2.5, các quy định này:

[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ỉ báo cáo android.hardware.faketouch.
[C-3-3] PHẢI báo cáo TOUCHSCREEN_NOTOUCH cho Configuration.touchscreen Trường API.

7.2.5. Nhập bằng cách chạm giả

Giao diện cảm ứng giả cung cấp một hệ thống nhập của người dùng ước chừng một tập hợp con 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 có khả năng điều khiển con trỏ trên màn hình gần đú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, con quay hồi chuyển chuột cảm ứng, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ giả mạo tương tác chạm. Android có hằng số tính năng android.hardware.fakeTouch, tương ứng với độ chân thực cao thiết bị đầu vào (dựa trên con trỏ) như chuột hoặc bàn di chuột có thể mô phỏng phương thức nhập dựa trên thao tác chạm (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng chức năng màn hình cảm ứng.

Nếu quá trình triển khai thiết bị không bao gồm màn hình cảm ứng nhưng lại bao gồm một màn hình khác mà họ muốn cung cấp, họ:

NÊN khai báo khả năng hỗ trợ cho cờ tính năng android.hardware.faketouch.

Nếu các phương thức triển khai thiết bị khai báo hỗ trợ cho android.hardware.faketouch, chúng:

[C-1-1] PHẢI báo cáo vị trí màn hình X và Y tuyệt đối của vị trí con trỏ và hiển thị con trỏ trực quan trên màn hình.
[C-1-2] PHẢI báo cáo sự kiện chạm có mã hành động chỉ định thay đổi trạng thái xảy ra trên con trỏ di chuyển xuống hoặc di chuyển lên trên màn hình.
[C-1-3] PHẢI hỗ trợ con trỏ xuống và lên trên một đối tượng trên màn hình mà cho phép người dùng mô phỏng thao tác nhấn vào một đối tượng trên màn hình.
[C-1-4] PHẢI hỗ trợ con trỏ xuống, con trỏ hướng lên, con trỏ xuống rồi con trỏ lên ở cùng một vị trí trên màn hình trong một ngưỡng thời gian. Điều này cho phép người dùng mô phỏng thao tác nhấn đúp trên một đối tượng trên màn hình.
[C-1-5] PHẢI hỗ trợ con trỏ xuống tại một điểm tuỳ ý trên màn hình, con trỏ di chuyển đến bất kỳ điểm tuỳ ý nào khác trên màn hình, theo sau là một con trỏ lên trên để 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ợ con trỏ xuống rồi cho phép người dùng nhanh chóng di chuyển đối tượng ở một vị trí khác trên màn hình rồi trỏ lên trên màn hình, cho phép người dùng hất một đối tượng lên màn hình.

Nếu quá trình triển khai thiết bị khai báo hỗ trợ cho android.hardware.faketouch.multitouch.distinct, họ:

[C-2-1] PHẢI khai báo khả năng hỗ trợ cho android.hardware.faketouch.
[C-2-2] PHẢI hỗ trợ tính năng theo dõi riêng biệt của 2 con trỏ độc lập trở lên đầu vào.

Nếu quá trình triển khai thiết bị khai báo hỗ trợ cho android.hardware.faketouch.multitouch.jazzhand, họ:

[C-3-1] PHẢI khai báo khả năng hỗ trợ cho android.hardware.faketouch.
[C-3-2] PHẢI hỗ trợ theo dõi riêng biệt 5 (theo dõi bàn tay của ngón tay) hoặc nhiều đầu vào con trỏ 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 ánh xạ các sự kiện HID đến hằng số InputEvent tương ứng như được liệt kê trong bảng dưới đây. Việc triển khai Android ngược dòng đáp ứng yêu cầu này.

Nếu các quá trình 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 trong hộp nhằm cung cấp phương tiện để nhập tất cả sự kiện được liệt kê trong bảng bên dưới, thì chúng:

[C-2-1] PHẢI khai báo cờ tính năng android.hardware.gamepad

Nút	Sử dụng HID²	Nút Android
Đáp¹	Mã: 0x09	KEYCODE_NÚT_A (96)
T¹	Mã: 0x09	KEYCODE_NÚT_B (97)
X¹	Mã: 0x09	KEYCODE_NÚT_X (99)
N¹	Mã: 0x09	KEYCODE_NÚT_Y (100)
D-pad up¹ D-pad xuống¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad bên trái1 D-pad bên phải¹	0x01 0x0039³	AXIS_HAT_X⁴
Nút vai trái¹	Mã: 0x09	KEYCODE_NÚT_L1 (102)
Nút vai phải¹	Mã: 0x09	KEYCODE_NÚT_R1 (103)
Nhấp chuột trái¹	Mã: 0x09	KEYCODE_NÚT_THUMBL (106)
Nhấp chuột phải¹	0x09 0x000F	KEYCODE_NÚT_THUMBR (107)
Quay lại¹	0x0c 0x0224	KEYCODE_BACK (4)

1 Sự kiện chính

2 Phải khai báo trường hợp sử dụng HID ở trên trong Trò chơi pad CA (0x01 0x0005).

3 Trường hợp sử dụng này phải có Mức logic tối thiểu là 0, Logic Tối đa là 7, Tối thiểu vật lý là 0, Tối đa vật lý là 315, Đơn vị về Độ và Kích thước báo cáo là 4. Giá trị logic được xác định là xoay theo chiều kim đồng hồ ra khỏi trục tung; Ví dụ: giá trị logic của 0 biểu thị không xoay và nút lên được nhấn, trong khi giá trị logic 1 biểu thị góc xoay 45 độ và cả phím mũi tên lên và trái là nhấn.

4 Sự kiện chuyển động

Nút điều khiển analog¹	Sử dụng HID	Nút Android
Trình kích hoạt bên trái	0x02 0x00C5	AXIS_L KÍCH HOẠT
điều kiện kích hoạt bên phải	0x02 0x00C4	AXIS_R KÍCH HOẠT
Cần điều khiển bên trái	0x01 0x0030 Mã: 0x01	AXIS_X AXIS_Y
Cần điều khiển bên phải	0x01 0x0032 Mã: 0x01	AXIS_Z AXIS_RZ

1 Sự kiện chuyển động

7.2.7. Điều khiển từ xa

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

7,3. Cảm biến

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, việc triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu SDK Android và tài liệu Nguồn mở Android về cảm biến.

Triển khai thiết bị:

[C-0-1] PHẢI báo cáo chính xác sự có mặt hay không có cảm biến của android.content.pm.PackageManager .
[C-0-2] PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự.
[C-0-3] PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng trả về true hoặc false nếu phù hợp khi các ứng dụng cố gắng đăng ký không gọi trình nghe cảm biến khi các cảm biến tương ứng không hiện tại; v.v).

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, họ:

[C-1-1] PHẢI report all valuemeasuring (Báo cáo tất cả phép đo cảm biến) bằng cách sử dụng các giá trị Hệ thống đơn vị quốc tế (chỉ số) có liên quan cho mỗi loại cảm biến theo 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 có độ trễ tối đa là 100 mili giây + 2 * sample_time đối với trường hợp luồng cảm biến có độ trễ tối đa được yêu cầu là 0 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 của cảm biến đang được kích hoạt. Mẫu này có thể chấp nhận có độ chính xác bằng 0.
[C-1-4] Trong trường hợp bất kỳ API nào được chỉ định trong tài liệu SDK Android trở thành một cảm biến liên tục, các quá trình triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ PHẢI có độ dao động dưới 3%, trong đó dao động được định nghĩa là độ lệch chuẩn của độ chênh lệch được báo cáo về các giá trị dấu thời gian 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ủa 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 đánh thức từ trạng thái tạm ngưng.
[C-1-6] PHẢI report the event time tính bằng nano giây như được xác định trong tài liệu SDK Android, biểu thị thời điểm sự kiện xảy ra và được đồng bộ hoá với Đồng hồ System Clock.elapsedRealtimeNano().
[C-SR-1] AreĐể chỉ định 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ụ năng lượng KHÔNG ĐƯỢC vượt quá tổng mức tiêu thụ điện năng được báo cáo của từng cảm biến.

Danh sách ở trên chưa đầy đủ; hành vi được ghi nhận trong tài liệu của SDK Android và Tài liệu nguồn mở Android trên cảm biến cần được xem xét đáng tin cậy.

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, họ:

[C-1-6] PHẢI đặt mộ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 Sensor.getResolution() API.

Một số loại cảm biến là loại cảm biến kết hợp, nghĩa là chúng có thể lấy từ dữ liệu được cung cấp bằng một hoặc nhiều cảm biến khác. (Ví dụ như 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 bao gồm các cảm biến vật lý tiên quyết như được mô tả trong các loại cảm biến.

Nếu quá trình triển khai thiết bị bao gồm một cảm biến tổng hợp, thì các cấu hình đó:

[C-2-1] PHẢI triển khai cảm biến như được mô tả trong Nguồn mở Android tài liệu về cảm biến tổng hợp.

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có tương ứng cho các nhà phát triển bên thứ ba và cảm biến chỉ báo cáo một API rồi đến các 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 Sensor.getResolution() API.

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể hỗ trợ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION và cảm biến được tiếp xúc với nhà phát triển bên thứ ba, họ:

[C-4-1] KHÔNG ĐƯỢC bao gồm bất kỳ hiệu chuẩn cố định, do nhà máy xác định trong dữ liệu được cung cấp.

Nếu quá trình triển khai thiết bị bao gồm kết hợp gia tốc kế 3 trục, thì Cảm biến con quay hồi chuyển 3 trục hay cảm biến từ kế, có những đặc điểm sau:

[C-SR-2] Để đả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ụ: thiết bị có thể gập lại), các trục cảm biến vẫn được căn chỉnh và nhất quán với hệ thống toạ độ cảm biến trên mọi thiết bị có thể các trạng thái biến đổi.

7.3.1. Gia tốc kế

Triển khai thiết bị:

[C-SR-1] Giới thiệu về gia tốc kế 3 trục.

Nếu quá trình triển khai thiết bị có bao gồm gia tốc kế, thì ứng dụng sẽ:

[C-1-1] PHẢI có thể báo cáo các sự kiện lên đến tần số tối thiểu là 50 Hz.
[C-1-3] PHẢI tuân thủ Hệ thống toạ độ cảm biến Android như đã nêu chi tiết trong các API của Android.
[C-1-4] PHẢI có khả năng đo từ độ rơi tự do tối đa bốn lần gravity(4g) trở lên trên bất kỳ trục nào.
[C-1-5] PHẢI có độ phân giải ít nhất 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 sẽ được tính toán trên mỗi trục đối với 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.
NÊN báo cáo các sự kiện tối thiểu là 200 Hz.
PHẢI có độ phân giải tối thiểu là 16 bit.
NÊN được hiệu chỉnh trong khi sử dụng nếu đặc tính thay đổi vòng đời và được bù, cũng như duy trì các thông số bù giữa các lần khởi động lại thiết bị.
PHẢI được bù nhiệt.

Nếu quá trình triển khai thiết bị bao gồm gia tốc kế 3 trục, thì các phương thức triển khai đó:

[C-2-1] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER.
[C-SR-4] Are mã ĐỀ XUẤT NÊN triển khai TYPE_SIGNIFICANT_MOTION cảm biến tổng hợp.
[C-SR-5] Are mã ĐỀ XUẤT NÊN triển khai và báo cáo Cảm biến TYPE_ACCELEROMETER_UNCALIBRATED. Các thiết bị Android HẤP DẪN NÊN đáp ứng yêu cầu này để họ có thể nâng cấp lên bản phát hành nền tảng trong tương lai nơi điều này có thể trở thành BẮT BUỘC.
NÊN triển khai TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER cảm biến tổng hợp như được mô tả trong tài liệu SDK Android.

Nếu quá trình triển khai thiết bị bao gồm gia tốc kế có ít hơn 3 trục, thì chúng:

[C-3-1] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] AreĐể chỉ định vị trí cho việc triển khai và báo cáo Cảm biến TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Nếu quá trình triển khai thiết bị bao gồm gia tốc kế 3 trục và bất kỳ TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR Cảm biến tổng hợp TYPE_STEP_COUNTER được triển khai:

[C-4-1] Tổng của mức tiêu thụ điện năng PHẢI luôn nhỏ hơn 4 mW.
Mỗi dải NÊN có giá trị dưới 2 mW và 0,5 mW khi thiết bị ở chế độ động hoặc điều kiện tĩnh.

Nếu phương thức triển khai thiết bị bao gồm gia tốc kế 3 trục và cảm biến con quay hồi chuyển 3 trục, chúng:

[C-5-1] PHẢI triển khai TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION cảm biến tổng hợp.
[C-SR-7] Are Internet ĐỀ XUẤT NÊN triển khai Cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR.

Nếu phương thức triển khai thiết bị bao gồm gia tốc kế 3 trục, cảm biến con quay hồi chuyển 3 trục, và một cảm biến từ kế, chúng sẽ:

[C-6-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

7.3.2. Từ kế

Triển khai thiết bị:

[C-SR-1] Giới hạn định dạng giới thiệu để bao gồm từ kế 3 trục (la bàn).

Nếu cách triển khai thiết bị bao gồm từ kế 3 trục, thì chúng:

[C-1-1] PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD.
[C-1-2] PHẢI có thể báo cáo các sự kiện lên đến tần suất tối thiểu là 10 Hz và PHẢI báo cáo các sự kiện lên đến 50 Hz.
[C-1-3] PHẢI tuân thủ hệ thống toạ độ cảm biến Android như trình bày chi tiết trong API của Android.
[C-1-4] PHẢI có khả năng đo trong khoảng từ -900 μT đến +900 μT trên mỗi thiết bị trước khi bão hoà.
[C-1-5] PHẢI có giá trị bù bằng sắt cứng nhỏ hơn 700 μT và NÊN có giá trị nhỏ hơn 200 μT, bằng cách đặt từ kế cách xa từ trường động (do dòng điện) và từ trường tĩnh (do nam châm gây ra).
[C-1-6] PHẢI có độ phân giải bằng hoặc dày hơn 0,6 μT.
[C-1-7] PHẢI hỗ trợ hiệu chuẩn và bù sắt cứng trực tuyến độ lệch và duy trì 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 bù sắt mềm — việc hiệu chuẩn có thể là thực hiệ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 mẫu được thu thập trong khoảng thời gian ít nhất 3 giây ở thời điểm lấy mẫu nhanh nhất tỷ lệ, không lớn hơn 1, 5 μT; PHẢI có độ lệch chuẩn không lớn hơn 0,5 μT.
[C-1-10] PHẢI triển khai phương thức TYPE_MAGNETIC_FIELD_UNCALIBRATED cảm biến.

Nếu cách triển khai thiết bị bao gồm từ kế 3 trục, thì gia tốc kế và một cảm biến con quay hồi chuyển 3 trục, chúng:

[C-2-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Nếu cách triển khai thiết bị bao gồm từ kế 3 trục, gia tốc kế, thì thiết bị đó sẽ:

CÓ THỂ triển khai cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Nếu cách triển khai thiết bị bao gồm từ kế 3 trục, gia tốc kế và TYPE_GEOMAGNETIC_ROTATION_VECTOR cảm biến, chúng:

[C-3-1] PHẢI tiêu thụ ít hơn 10 mW.
NÊN tiêu thụ dưới 3 mW khi cảm biến được đăng ký cho chế độ hàng loạt ở 10 Hz.

7.3.3. GPS

Triển khai thiết bị:

[C-SR-1] Giới hạn định dạng giới thiệu để bao gồm bộ thu GPS/GNSS.

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

[C-1-1] PHẢI hỗ trợ đầu ra vị trí với tốc độ ít nhất 1 Hz khi được yêu cầu qua LocationManager#requestLocationUpdate.
[C-1-2] PHẢI có thể xác định vị trí trong điều kiện trời mở (tín hiệu mạnh, đa đường dẫn không đáng kể, HDOP < 2) trong vòng 10 giây (nhanh thời gian xử lý lần đầu), khi kết nối với tốc độ dữ liệu 0,5 Mb/giây trở lên kết nối Internet. Yêu cầu này thường được đáp ứng bằng cách sử dụng một số dạng 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à Ephemeris/đồng hồ vệ tinh).
- [C-1-6] Sau khi tính toán vị trí đó, thiết bị Quá trình triển khai PHẢI xác định vị trí của nó, trên bầu trời mở, trong phạm vi 5 giây, khi yêu cầu thông tin vị trí được khởi động lại, tối đa một giờ sau đó phép tính vị trí ban đầu, ngay cả khi yêu cầu tiếp theo là thực hiện khi không có kết nối dữ liệu và/hoặc sau khi bật nguồn.
Trong điều kiện trời mở sau khi xác định vị trí, khi đứng yên hoặc di chuyển với tốc độ bình phương gia tốc dưới 1 mét/giây:
- [C-1-3] PHẢI có thể xác định vị trí trong phạm vi 20 mét và tốc độ trong khoảng 0,5 m/giây, tối thiểu 95% thời gian.
- [C-1-4] PHẢI đồng thời theo dõi và báo cáo qua GnssStatus.Callback ít nhất 8 vệ tinh từ một chòm sao.
- PHẢI có thể theo dõi cùng lúc ít nhất 24 vệ tinh, từ nhiều chòm sao (ví dụ: GPS + ít nhất một chòm sao Glonass, Bắc Đẩu, Galileo).
[C-SR-2] Are trì hoãn để tiếp tục cung cấp GPS/GNSS bình thường kết quả đầu ra vị trí thông qua API Trình cung cấp vị trí GNSS trong điện thoại khẩn cấp .
[C-SR-3] AreĐể báo cáo các chỉ số đo lường 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), với ngoại lệ của SBAS.
[C-SR-4] Are được linh hoạt đề xuất để báo cáo AGC và Tần suất của GNSS đo lường.
[C-SR-5] Are mã ĐỀ XUẤT NÊN báo cáo tất cả thông tin ước tính về độ chính xác (bao gồm Góc phương vị, Tốc độ và Chiều dọc) làm một phần của từng vị trí GPS/GNSS.
[C-SR-6] Giới hạn định dạng giới thiệu để báo cáo số liệu đo lường GNSS, ngay khi chúng được tìm thấy, ngay cả khi chưa có vị trí tính toán bằng GPS/GNSS đã báo cáo.
[C-SR-7] AreRENDERED ĐỀ XUẤT để báo cáo GNSS pseudoranges và tỷ lệ phạm vi giả, trong điều kiện trời mở sau khi xác định vị trí, khi đứng yên hoặc di chuyển với vận tốc dưới 0,2 m/giây gia tốc, đủ để tính vị trí trong phạm vi 20 mét và vận tốc với tốc độ tối thiểu 0,2 m/giây, tối thiểu 95% thời gian.

7.3.4. Con quay hồi chuyển

Triển khai thiết bị:

[C-SR-1] Are trì hoãn việc sử dụng cảm biến con quay hồi chuyển.

Nếu quá trình triển khai thiết bị bao gồm con quay hồi chuyển, thì chúng:

[C-1-1] PHẢI có thể báo cáo các sự kiện lên đến tần số tối thiểu là 50 Hz.
[C-1-4] PHẢI có độ phân giải 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ù đắp khi sử dụng, đồng thời duy trì 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 mỗi Hz (chênh lệch trên mỗi Hz hoặc Rad^2 / s). Phương sai được phép thay đổi theo tốc độ lấy mẫu, nhưng PHẢI bị giá trị này hạn chế. 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, giá trị này KHÔNG ĐƯỢC lớn hơn hơn 1e-7 Rad^2/s^2.
[C-SR-2] Lỗi hiệu chỉnh là tôi liệt kê ra một dòng chữ nhỏ hơn 0,01 rad/s khi thiết bị đứng yên ở nhiệt độ phòng.
[C-SR-3] Are trì hoãn 1 để có độ phân giải từ 16-bit trở lên.
NÊN báo cáo các sự kiện tối thiểu là 200 Hz.

Nếu quá trình triển khai thiết bị bao gồm con quay hồi chuyển 3 trục, thì chúng:

[C-2-1] PHẢI triển khai cảm biến TYPE_GYROSCOPE.
[C-SR-4] Đặc biệt nên triển khai TYPE_GYROSCOPE_UNCALIBRATED cảm biến.

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

[C-3-1] PHẢI triển khai và báo cáo cảm biến TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] Are{/7}ân đề xuất để triển khai và báo cáo Cảm biến TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Nếu phương thức triển khai thiết bị bao gồm con quay hồi chuyển 3 trục, cảm biến gia tốc kế và một cảm biến từ kế, chúng sẽ:

[C-4-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Trường hợp triển khai thiết bị bao gồm gia tốc kế 3 trục và con quay hồi chuyển 3 trục cảm biến, chúng:

[C-5-1] PHẢI triển khai TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION cảm biến tổng hợp.
[C-SR-6] cực kỳ ĐỀ XUẤT để triển khai TYPE_GAME_ROTATION_VECTOR cảm biến tổng hợp.

7.3.5. Khí áp kế

Triển khai thiết bị:

[C-SR-1] Giới hạn định dạng giới thiệu để bao gồm khí áp kế (áp suất không khí ambient cảm biến).

Nếu hoạt động triển khai thiết bị bao gồm khí áp kế, thì chúng:

[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ó thể 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] mã hoá vạch ra mắt để có thể báo cáo các phép đo áp suất trong phạm vi 300hPa đến 1100hPa.
PHẢI có độ chính xác tuyệt đối là 1hPa.
NÊN có độ chính xác tương đối là 0,12hPa trên phạm vi 20hPa (tương đương với độ chính xác ~ 1m trên sự thay đổi ~ 200m ở mực nước biển).

7.3.6. Nhiệt kế

Nếu quá trình triển khai thiết bị có bao gồm nhiệt kế môi trường xung quanh (cảm biến nhiệt độ), chúng:

[C-1-1] PHẢI xác định SENSOR_TYPE_AMBIENT_TEMPERATURE đối với cảm biến nhiệt độ môi trường xung quanh và cảm biến PHẢI đo môi trường xung quanh Nhiệt độ (phòng/cabin trong xe) từ nơi người dùng đang tương tác với thiết bị ở độ C.

Nếu quá trình triển khai thiết bị bao gồm cảm biến nhiệt kế để đo lường nhiệt độ khác với nhiệt độ môi trường xung quanh (chẳng hạn như nhiệt độ CPU):

[C-2-1] KHÔNG ĐƯỢC xác định SENSOR_TYPE_AMBIENT_TEMPERATURE cho cảm biến nhiệt độ.

Nếu quá trình triển khai thiết bị bao gồm cảm biến để theo dõi nhiệt độ trên da, thì họ:

[C-SR-1] Are mã ĐỀ XUẤT NÊN hỗ trợ PowerManager.getThermalHeadroom API.

7.3.7. Quang kế

Quá trình triển khai thiết bị CÓ THỂ bao gồm một quang kế (cảm biến ánh sáng môi trường xung quanh).

7.3.8. Cảm biến độ gần

Quá trình triển khai trên thiết bị CÓ THỂ bao gồm cả cảm biến độ gần.

Nếu quá trình triển khai thiết bị bao gồm cảm biến độ gần và chúng chỉ báo cáo nhị phân "gần" hoặc "xa" đọc, họ:

[C-1-1] PHẢI đo độ gần của một đối tượng theo cùng hướng với màn hình. Tức là cảm biến độ gần PHẢI được định hướng để phát hiện đối tượng ở 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 một điện thoại mà người dùng đang sử dụng. Nếu quá trình triển khai thiết bị bao gồm cảm biến độ gần có bất kỳ hướng nào khác, KHÔNG ĐƯỢC PHÉP truy cập được 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 chỉ số gần và 5 cm làm chỉ số gần đọc xa.
[C-1-4] PHẢI báo cáo phạm vi và độ phân giải tối đa là 5.

7.3.9. Cảm biến có độ chân thực cao

Nếu việc triển khai thiết bị bao gồm một tập hợp cảm biến chất lượng cao hơn như đã xác định trong phần này và cung cấp cho các ứng dụng bên thứ ba, họ:

[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 hoạt động triển khai thiết bị khai báo android.hardware.sensor.hifi_sensors, chúng:

[C-2-1] PHẢI có cảm biến TYPE_ACCELEROMETER:
- PHẢI có phạm vi đo tối thiểu là từ -8 g đến + 8 g, và ĐỀ XUẤT NÊN có phạm vi đo lường tối thiểu là -16g và hơn 16 g.
- PHẢI có độ phân giải đo ít nhất là 2048 LSB/g.
- PHẢI có tần số đo tối thiểu từ 12,5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 400 Hz trở lên; NÊN hỗ trợ SensorDirectChannel RATE_VERY_FAST.
- PHẢI có độ nhiễu khi đo không được trên 400 μg/.
- PHẢI triển khai hình thức không đánh thức của cảm biến này bằng bộ đệm tối thiểu 3.000 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 3 mW.
- [C-SR-1] Is phong thuong Sử dụng để có băng thông đo lường 3dB của at 80% tần số Nyquist và phổ nhiễu trắng trong băng thông.
- NÊN có gia tốc đi bộ ngẫu nhiên nhỏ hơn 30 μg & Hz được thử nghiệm ở nhiệt độ phòng.
- NÊN có sự thay đổi độ lệch so với nhiệt độ ≤ +/- 1 mg/°C.
- NÊN có độ không tuyến tính phù hợp nhất với đường kẻ là ≤ 0,5% và độ thay đổi độ nhạy so với nhiệt độ ≤ 0,03%/C°.
- NÊN có độ nhạy trên trục chéo là < 2,5 % và sự biến động của độ nhạy trên hai trục < 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 với cùng các yêu cầu về chất lượng như TYPE_ACCELEROMETER.
[C-2-3] PHẢI có cảm biến TYPE_GYROSCOPE:
- PHẢI có phạm vi đo lường ít nhất từ -1000 đến +1000 dp.
- PHẢI có độ phân giải đo lường ít nhất là 16 LSB/dp.
- PHẢI có tần số đo tối thiểu từ 12,5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 400 Hz trở lên; NÊN hỗ trợ SensorDirectChannel RATE_VERY_FAST.
- PHẢI có độ nhiễu khi đo không được lớn hơn 0,014°/s/.
- [C-SR-2] Is liền NÊN DÙNG để có băng thông đo lường 3dB của tại 80% tần số Nyquist và phổ nhiễu trắng trong băng thông.
- NÊN thử nghiệm tốc độ đi bộ ngẫu nhiên ở phòng nhiệt độ.
- NÊN có sự thay đổi độ lệch so với nhiệt độ ≤ +/- 0,05 °/ s / °C.
- NÊN có sự thay đổi về độ nhạy so với nhiệt độ ≤ 0,02% / °C.
- Phải có độ không tuyến tính phù hợp nhất với đường kẻ từ ≤ 0,2%.
- NÊN có mật độ tiếng ồn ≤ 0,007 °/s/tài khoản.
- Sai số hiệu chuẩn phải nhỏ hơn 0,002 Rad/s phạm vi nhiệt độ 10 ~ 40 °C khi thiết bị đứng yên.
- Phải có độ nhạy g dưới 0,1°/s/g.
- NÊN có độ nhạy trên trục chéo là < 4 % và độ nhạy trên trục chéo biến thể < 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ùng chất lượng theo TYPE_GYROSCOPE.
[C-2-5] PHẢI có cảm biến TYPE_GEOMAGNETIC_FIELD:
- Phạm vi đo phải có giá trị từ -900 đến +900 μT.
- PHẢI có độ phân giải đo ít nhất là 5 LSB/uT.
- PHẢI có tần số đo tối thiểu từ 5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 50 Hz trở lên.
- PHẢI có độ nhiễu đo không được lớn hơn 0,5 uT.
[C-2-6] PHẢI có TYPE_MAGNETIC_FIELD_UNCALIBRATED có cùng chất lượng theo các yêu cầu sau đây như TYPE_GEOMAGNETIC_FIELD và ngoài ra:
- PHẢI triển khai hình thức không đánh thức của cảm biến này bằng bộ đệm tối thiểu 600 sự kiện cảm biến.
- [C-SR-3] Is mã ĐỀ XUẤT NÊN có phổ nhiễu trắng từ 1 Hz đến ít nhất 10 Hz khi tốc độ báo cáo từ 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 nhất là 80 LSB/hPa.
- PHẢI có tần số đo tối thiểu từ 1 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 10 Hz trở lên.
- PHẢI có độ nhiễu đo không được trên 2 Pa/{4}Hz.
- PHẢI triển khai hình thức không đánh thức của cảm biến này bằng bộ đệm tối thiểu 300 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 2 mW.
[C-2-8] PHẢI có cảm biến TYPE_GAME_ROTATION_VECTOR.
[C-2-9] PHẢI có cảm biến TYPE_SIGNIFICANT_MOTION:
- PHẢI có mức tiêu thụ điện năng không thấp hơn 0,5 mW khi thiết bị là 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 hình thức không đánh thức của cảm biến này bằng bộ đệm khả năng hỗ trợ í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 thấp hơn 0,5 mW khi thiết bị là 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 phân lô không thấp hơn 4 mW.
[C-2-11] PHẢI có cảm biến TYPE_STEP_COUNTER:
- PHẢI có mức tiêu thụ điện năng không thấp hơn 0,5 mW khi thiết bị là 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 thấp hơn 0,5 mW khi thiết bị là tĩnh và 1,5 mW khi thiết bị đang di chuyển.
[C-2-13] Dấu thời gian của sự kiện vật lý tương tự do Gia tốc kế, con quay hồi chuyển và từ kế PHẢI trong vòng 2, 5 mili giây của nhau. Dấu thời gian sự kiện của cùng một sự kiện thực tế được báo cáo bởi gia tốc kế và con quay hồi chuyển PHẢI nằm trong phạm vi 0,25 mili giây của mỗi thiết bị khác.
[C-2-14] PHẢI có dấu thời gian sự kiện cảm biến con quay hồi chuyển trên cùng một thời gian làm hệ thống con máy ảnh và xảy ra lỗi trong vòng 1 mili giây.
[C-2-15] PHẢI gửi mẫu đến các ứng dụng trong vòng 5 mili giây từ thời điểm dữ liệu được cung cấp trên bất kỳ cảm biến vật lý nào nêu trên đối với ứ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ị ở dạng tĩnh và 2 mW khi thiết bị đang di chuyển khi bật bất kỳ tổ hợp nào trong số các cảm biến sau đây:
- 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ùng đệm tối thiểu là 100 sự kiện cảm biến.

Lưu ý rằng tất cả các yêu cầu về mức tiêu thụ điện năng trong phần này không bao gồm mức tiêu thụ điện năng của Bộ xử lý ứng dụng. Giải pháp này bao gồm sức mạnh được vẽ bằng toàn bộ chuỗi cảm biến – cảm biến, mọi mạch hỗ trợ, bất kỳ hệ thống xử lý cảm biến chuyên dụng, v.v.

Nếu quá trình triển khai thiết bị có hỗ trợ cảm biến trực tiếp, thì chúng:

[C-3-1] PHẢI khai báo chính xác việc hỗ trợ các loại kênh trực tiếp và kênh trực tiếp cấp báo cáo thông qua isDirectChannelTypeSupported và getHighestDirectReportRateLevel API.
[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 tuyên bố hỗ trợ kênh trực tiếp 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ảm biến cho các báo cáo chính cảm biến (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ề cách đo lường khả năng 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 về việc đo lường Bảo mật bằng sinh trắc học.

Nếu các hoạt động triển khai thiết bị có bao gồm màn hình khoá bảo mật, thì chúng:

PHẢI có cảm biến sinh trắc học

Cảm biến sinh trắc học có thể được phân loại là Loại 3 (trước đây là Mạnh), Loại 2 (trước đây là Yếu) hoặc Loại 1 (trước đây là Thuận tiện) dựa trên tỷ lệ chấp nhận các hành vi giả mạo và mạo danh cũng như tính bảo mật của đường ống sinh trắc học. Cách phân loại này xác định các khả năng mà cảm biến sinh trắc học phải tương tác với nền tảng và bên thứ ba . Cảm biến cần đáp ứng các yêu cầu bổ sung như trình bày chi tiết dưới đây nếu họ muốn phân loại là Loại 1, Loại 2 hoặc Loại 3. Cả hệ thống nhận dạng sinh trắc học Lớp 2 và Lớp 3 đều có các tính năng bổ sung như được nêu chi tiết bên dưới.

Nếu việc triển khai thiết bị cung cấp cảm biến sinh trắc học cho bên thứ ba thông qua android.hardware.biometric.BiometricManager, android.hardware.biometric.BiometricPrompt, và android.provider.Settings.ACTION_BIOMETRIC_ENROLL, chúng:

[C-4-1] PHẢI đáp ứng các yêu cầu đối với hệ thống nhận dạng sinh trắc học Class 3 hoặc Class 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 thông số được định nghĩa là hằng số trong Authenticators và bất kỳ tổ hợp nào của các lớp đó. Ngược lại, KHÔNG ĐƯỢC tuân thủ hoặc nhận ra các hằng số nguyên được chuyển đến canVerify(int) và setAllowedAuthenticators(int) khác với những phương thức được ghi nhận dưới dạng hằng số công khai trong Máy xác thực và mọi cách kết hợp các yếu tố đó.
[C-4-3] PHẢI triển khai ACTION_BIOMETRIC_ENROLL thao tác trên các thiết bị có hệ thống nhận dạng sinh trắc học Lớp 3 hoặc Lớp 2. Thao tác này PHẢI chỉ hiển thị điểm truy cập đăng ký cho Lớp 3 hoặc hệ thống nhận dạng sinh trắc học Lớp 2.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[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. Phần hiển thị nội dung định dạng KHÔNG ĐƯỢC mở rộng để 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 BiometricPrompt API. Điều chỉnh kiểu cách không thay đổi, che khuất hoặc cắt ngắn khoảng thời gian này nội dung có thể được tạo (chẳng hạn như thay đổi vị trí, khoảng đệm, lề và kiểu chữ).

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

Nếu quá trình triển khai thiết bị hỗ trợ tính năng nhận dạng sinh trắc học thụ động, thì các thiết bị đó sẽ:

[C-5-1] Theo mặc định, PHẢI yêu cầu một bước xác nhận bổ sung (ví dụ: nhấn nút).
[C-SR-1] AreĐể chỉ định có chế độ cài đặt cho phép người dùng ghi đè lựa chọn ưu tiên của ứng dụng và luôn yêu cầu đi kèm bước xác nhận.
[C-SR-2] Are trì hoãn phát hành để xác nhận hành động được bảo mật sao cho một hệ điều hành hoặc hạt nhân bị xâm phạm không thể giả mạo nó. 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 chân cắm đầu vào/đầu ra đa năng (GPIO) chỉ dành cho đầu vào của một phần tử bảo mật (SE) không thể điều khiển bằng bất kỳ phương tiện nào khác ngoài nhấn nút vật lý.
[C-5-2] PHẢI triển khai thêm một luồng xác thực ngầm ẩn (không có bước xác nhận) tương ứng với setConfirmationAvailable(boolean), mà ứng dụng có thể đặt để sử dụng cho quy trình đăng nhập.

Nếu quá trình triển khai thiết bị có nhiều cảm biến sinh trắc học, thì các cảm biến đó:

[C-7-1] PHẢI, khi hệ thống nhận dạng sinh trắc học bị khoá (tức là hệ thống nhận dạng sinh trắc học bị tắt) 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 (ví dụ: hệ thống nhận dạng sinh trắc học tạm thời bị tắt cho đến khi người dùng chờ một chút khoảng thời gian) do quá nhiều lần thử không thành công, đồng thời khoá tất cả hệ thống nhận dạng sinh trắc học thuộc một lớp sinh trắc học thấp hơn. Trong trường hợp bị khoá có giới hạn thời gian, thời gian đợi để xác minh bằng sinh trắc học PHẢI là thời gian đợi tối đa của tất cả hệ thống nhận dạng sinh trắc học trong tính năng khoá có giới hạn thời gian.
[C-SR-12] Giới hạn định dạng, khi hệ thống nhận dạng sinh trắc học đang ở trạng thái khoá (ví dụ: hệ thống nhận dạng sinh trắc học bị tắt cho đến khi người dùng mở khoá bằng phương thức xác thực chính) hoặc có thời hạn (ví dụ: hệ thống nhận dạng sinh trắc học tạm thời bị vô hiệu hoá cho đến khi người dùng phải đợi trong một khoảng thời gian) do có quá nhiều lần thử không thành công, để cũng khoá tất cả các hệ thống nhận dạng 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, thời gian đợi để xác minh bằng sinh trắc học là CÓ NÊN DÙNG là thời gian đợi tối đa của tất cả dữ liệu sinh trắc học có giới hạn về thời gian khoá.
[C-7-2] PHẢI thử thách người dùng bằng phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) để đặt lại bộ đếm khoá để lấy dữ liệu sinh trắc học bị khoá. Dữ liệu sinh trắc học Lớp 3 CÓ THỂ được phép đặt lại khoá bộ đếm cho một hệ thống nhận dạng sinh trắc học bị khoá thuộc cùng loại hoặc hạng thấp hơn. Lớp 2 hoặc Không được phép sử dụng dữ liệu sinh trắc học Lớp 1 để hoàn tất quá trình khoá khi đặt lại cho bất kỳ dữ liệu sinh trắc học nào.
[C-SR-3] AreĐể chỉ yêu cầu một hệ thống nhận dạng sinh trắc học được xác nhận mỗi lần xác thực (ví dụ: nếu có cả cảm biến vân tay và khuôn mặt trên thiết bị, onAuthenticationSucceeded phải được gửi sau khi bất kỳ email nào trong số đó được xác nhận).

Để việc triển khai thiết bị cho phép truy cập vào khoá kho khoá để ứng dụng của bên thứ ba, họ:

[C-6-1] PHẢI đáp ứng các yêu cầu đối với Lớp 3 theo định nghĩa trong tài liệu này phần dưới đây.
[C-6-2] Chỉ được trình bày dữ liệu sinh trắc học Lớp 3 khi xác thực yêu cầu BIOMETRIC_STRONG, hoặc quá trình xác thực được gọi bằng CryptoObject.

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à Lớp 1 (trước đây là Tiện lợi), họ:

[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 mã PIN mạnh, hoặc mật khẩu hoặc mô tả rõ ràng các rủi ro khi bật mẫu, nếu tỷ lệ chấp nhận giả mạo và mạo danh cao hơn 7% do Giao thức kiểm tra sinh trắc học của Android.
[C-1-9] PHẢI thử thách người dùng bằng phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) sau không quá 20 lần thử sai và không thời gian đợi chưa đến 90 giây để xác minh sinh trắc học - trong đó thử nghiệm giả là thử nghiệm có chất lượng chụp phù hợp (BIOMETRIC_ACQUIRED_GOOD) không khớp với hệ thống nhận dạng sinh trắc học đã đăng ký.
[C-SR-4] AreĐể chỉ định giảm tổng số lượt thử nghiệm sai để xác minh bằng sinh trắc học được quy định trong [C-1-9] nếu kẻ giả mạo và mạo danh tỷ lệ chấp nhận cao hơn 7% theo đo lường của Hệ thống nhận dạng sinh trắc học của Android Kiểm thử Giao thức.
[C-1-3] PHẢI rate giới hạn số lần thử xác minh sinh trắc học – trong đó a thử nghiệm giả là thử nghiệm có chất lượng chụp phù hợp (BIOMETRIC_ACQUIRED_GOOD) không khớp với thông tin sinh trắc học đã đăng ký.
[C-SR-5] AreĐể chỉ định giới hạn số lần yêu cầu tối thiểu, 30 giây sau 5 lần thử sai để xác minh bằng sinh trắc học đối với số lần thử sai tối đa mỗi [C-1-9] – trong đó một thử nghiệm sai là một thử nghiệm có chất lượng chụp phù hợp (BIOMETRIC_ACQUIRED_GOOD) không phù hợp với thông tin sinh trắc học đã đăng ký.
[C-SR-6] Are mã hóa NÊN DÙNG để có tất cả logic giới hạn tốc độ trong TEE.
[C-1-10] PHẢI tắt tính năng nhận dạng sinh trắc học khi thời gian đợi xác thực chính có được kích hoạt lần đầu tiên 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 giả mạo và mạo danh không được cao hơn 30%, kèm theo (1) tỷ lệ chấp nhận nội dung giả mạo và mạo danh đối với bản trình bày Cấp A công cụ tấn công (PAI) không được cao hơn 30%, và (2) giả mạo và tỷ lệ chấp nhận kẻ mạo danh các loài PAI Cấp B không cao hơn 40%, vì được đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-1-4] PHẢI ngăn chặn việc thêm hệ thống nhận dạng 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 hiện có hoặc thêm một thiết bị mới thông tin đăng nhập (mã PIN/hình mở khoá/mật khẩu) được bảo mật bằng TEE; Android Open Việc triển khai Dự án nguồn cung cấp cơ chế trong khung để thực hiện vì vậy.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-5] PHẢI xoá hoàn toàn tất cả dữ liệu sinh trắc học có thể nhận dạng của người dùng khi tài khoản của người dùng bị xoá (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 (ví dụ: mã PIN, hình mở khoá, mật khẩu) đã bị xoá.

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

[C-1-6] PHẢI tôn trọng cờ cá nhân cho hệ thống nhận dạng sinh trắc học đó (ví dụ: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT! DevicePolicymanager.KEYGUARD_DISABLE_FACE, hoặc DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-7] PHẢI thử thách người dùng bằng 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) mỗi 24 giờ một lần trở xuống. Lưu ý: Nâng cấp thiết bị phát hành trên Android phiên bản 9 trở xuống PHẢI yêu cầu người dùng nhập 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) một lần mỗi 72 giờ trở xuống.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-8] PHẢI thử thách người dùng tham gia quy trình chính được đề xuất phương thức xác thực (chẳng hạn như mã PIN, hình mở khoá, mật khẩu) hoặc hệ thống nhận dạng sinh trắc học Loại 3 (STRONG) sau một trong các lệnh sau:
- khoảng thời gian chờ 4 giờ ở trạng thái không hoạt động, HOẶC
- 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ờ ở trạng thái 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ị. ~~Lưu ý: Nâng cấp thiết bị chạy trên Android phiên bản 9 hoặc sớm hơn CÓ THỂ được miễn C-1-8.~~

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

[C-SR-7] Are Internet ĐỀ XUẤT NÊN sử dụng logic trong khung được cung cấp bởi Dự án nguồn mở Android để thực thi các quy tắc ràng buộc được chỉ định trong [C-1-7] và [C-1-8] cho các thiết bị mới.
[C-SR-8] Are phong phú NÊN có tỷ lệ từ chối false nhỏ hơn 10%, giá trị đo được trên thiết bị.
[C-SR-9] Giới hạn định dạng giới thiệu để có độ trễ dưới 1 giây, được đo từ khi hệ thống phát hiện hệ thống nhận dạng sinh trắc học cho đến khi màn hình được mở khoá, thông tin sinh trắc học đã đăng ký.
[C-1-12] PHẢI có tỷ lệ chấp nhận giả mạo và mạo danh không được cao hơn 40% các loại công cụ tấn công cho mỗi lần trình bày (PAI), được đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-SR-13] Giới hạn định dạng sử dụng để có một spoof và tỷ lệ chấp nhận người mạo danh không cao hơn 30% các loại công cụ tấn công cho mỗi lần trình bày (PAI), được đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-SR-8] Are phong phú NÊN có tỷ lệ từ chối false nhỏ hơn 10%, giá trị đo được trên thiết bị.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-15] PHẢI cho phép người dùng xoá một hoặc nhiều dữ liệu sinh trắc học đăng ký.

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

[C-SR-14] AreĐể chỉ định thông tin về lớp sinh trắc học của cảm biến sinh trắc học và những rủi ro tương ứng khi bật cảm biến này.
[C-SR-17] Giới hạn định dạng giới thiệu để triển khai 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à Lớp 2 (trước đây là Yếu), họ:

[C-2-1] PHẢI đáp ứng tất cả các yêu cầu đối với Loại 1 ở trên.
[C-2-2] PHẢI có tỷ lệ chấp nhận giả mạo và mạo danh không được cao hơn 20%, với (1) tỷ lệ chấp nhận giả mạo và mạo danh đối với Các loại công cụ tấn công trình bày (PAI) cấp độ A không cao hơn 20%, và (2) tỷ lệ chấp nhận các loại PAI cấp B không được chấp nhận lừa đảo và mạo danh cao hơn 30%, đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-SR-15] AreĐể chỉ định dùng một spoof và imposter tỷ lệ chấp nhận không cao hơn 20% các loại công cụ tấn công cho mỗi lần trình bày (PAI), được đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-2-3] PHẢI thực hiện so khớp sinh trắc học trong môi trường thực thi tách biệt bên ngoài Android người dùng hoặc không gian nhân, 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 dẫn đến môi trường thực thi tách biệt hoặc trên Máy ảo được bảo vệ đáp ứng các yêu cầu ở Mục 9.17.
[C-2-4] PHẢI có tất cả dữ liệu nhận dạng được mã hoá và mã hoá được xác thực sao cho không thể thu thập, đọc hoặc thay đổi chúng bên ngoài môi trường thực thi tách biệt hoặc một khối có kênh bảo mật đến môi trường thực thi tách biệt như được ghi trong tài liệu triển khai các nguyên tắc trên trang web Dự án nguồn mở Android hoặc Máy ảo được bảo vệ được kiểm soát bởi trình điều khiển ảo hoá đáp ứng các yêu cầu trong Mục 9.17.
[C-2-5] Dành cho dữ liệu sinh trắc học dựa trên máy ảnh, trong khi xác thực dựa trên sinh trắc học hoặc quá trình đăng ký đang diễn ra:
- PHẢI vận hành máy ảnh ở chế độ ngăn khung hình của máy ảnh được đọc hoặc thay đổi bên ngoài môi trường thực thi tách biệt hoặc khối có một kênh bảo mật đến môi trường thực thi tách biệt hoặc một Protected Máy ảo được điều khiển bằng trình điều khiển ảo hoá và đáp ứng các yêu cầu trong Mục 9,17.
- Đối với các giải pháp camera đơn RGB, khung máy ảnh CÓ THỂ là đọc được bên ngoài môi trường thực thi tách biệt để hỗ trợ các thao tác chẳng hạn như bản xem trước để đăng ký, nhưng vẫn KHÔNG ĐƯỢC thay đổi được.
[C-2-6] KHÔNG ĐƯỢC cho phép các ứng dụng của bên thứ ba phân biệt giữa đăng ký sinh trắc học cá nhân.
[C-2-7] KHÔNG ĐƯỢC cho phép truy cập chưa mã hoá vào dữ liệu sinh trắc học có thể nhận dạng hoặc mọi dữ liệu bắt nguồn từ nó (chẳng hạn như các mục nhúng) đến Bộ xử lý ứng dụng bên ngoài bối cảnh của TEE hoặc được bảo vệ mà Máy ảo được bảo vệ kiểm soát bằng trình điều khiển ảo hoá đáp ứng các yêu cầu trong Mục 9.17. Việc nâng cấp các thiết bị chạy Android phiên bản 9 trở xuống không được miễn trừ từ C-2-7.
[C-2-8] PHẢI có một quy trình xử lý an toàn để việc xâm phạm hệ thống hoặc nhân hệ điều hành không thể cho phép đưa dữ liệu trực tiếp vào xác thực sai là người dùng. Lưu ý: Nếu các hoạt động triển khai thiết bị đã được triển khai trên Android phiên bản 9 hoặc cũ hơn và không thể đáp ứng yêu cầu C-2-8 thông qua phần mềm hệ thống bản cập nhật chính xác, họ CÓ THỂ được miễn trách nhiệm đáp ứng yêu cầu này.
[C-SR-10] AreĐể các nhà phát triển biết được rằng họ có thể sử dụng tính năng phát hiện sống động cho tất cả. các phương thức sinh trắc học và phát hiện sự chú ý cho hệ thống nhận dạng sinh trắc học khuôn mặt.
[C-2-9] PHẢI cung cấp cảm biến sinh trắc học cho bên thứ ba .

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à Lớp 3 (trước đây là Mạnh), họ:

[C-3-1] PHẢI đáp ứng tất cả các yêu cầu của Loại 2 ở trên, ngoại trừ [C-1-7] và [C-1-8].
[C-3-2] PHẢI triển khai kho khoá dựa trên phần cứng.
[C-3-3] PHẢI có tỷ lệ chấp nhận giả mạo và mạo danh không được cao hơn 7%, với (1) tỷ lệ chấp nhận giả mạo và mạo danh đối với Các loại công cụ tấn công trình bày (PAI) cấp độ A không cao hơn 7% và (2) tỷ lệ chấp nhận các loài PAI cấp B theo cách giả mạo và mạo danh không cao hơn hơn 20%, đo lường bằng Giao thức kiểm tra sinh trắc học của Android.
[C-3-4] PHẢI thử thách người dùng tham gia quy trình chính được đề xuất xác thực (chẳng hạn như mã PIN, hình mở khoá, mật khẩu) 72 giờ một lần trở xuống.
[C-3-5] PHẢI re-generate Authenticator ID cho tất cả hệ thống nhận dạng sinh trắc học Loại 3 được hỗ trợ trên thiết bị, nếu có đã đăng ký lại.
[C-3-6] Phải cho phép bên thứ ba sử dụng khoá kho khoá dựa trên sinh trắc học .
[C-SR-16] Are trì hoãn việc sử dụng các thành phần spoof và imposter tỷ lệ chấp nhận không cao hơn 7% mỗi loại công cụ tấn công trình bày (PAI), được đo bằng Giao thức kiểm tra sinh trắc học của Android. Nếu các phương thức triển khai thiết bị có chứa cảm biến vân tay dưới màn hình (UDFPS), chúng:
[C-SR-11] AreĐể ngăn chặn vùng có thể chạm của UDFPS không can thiệp vào hoạt động thao tác bằng 3 nút( điều mà một số người dùng có thể yêu cầu 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ạo dáng với 6 mức tự do.

Nếu quá trình triển khai thiết bị hỗ trợ cảm biến tư thế với 6 mức tự do, thì thiết bị đó:

[C-1-1] PHẢI triển khai và báo cáo TYPE_POSE_6DOF cảm biến.
[C-1-2] PHẢI chính xác hơn riêng vectơ xoay.

7.3.12. Cảm biến góc bản lề

Nếu quá trình triển khai thiết bị hỗ trợ cảm biến góc bản lề, thì chúng:

[C-1-1] PHẢI triển khai và báo cáo TYPE_HINGLE_ANGLE.
[C-1-2] PHẢI hỗ trợ ít nhất hai giá trị đo trong khoảng từ 0 đến 360 độ (bao gồm cả 0 và 360 độ).
[C-1-3] PHẢI trả về wakeup cảm biến cho getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Nếu triển khai thiết bị bao gồm hỗ trợ cho 802.1.15.4 và hiển thị cho một ứng dụng bên thứ ba, chúng:

[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 tập hợp cấu hình sau (được xác định trước tổ hợp thông số FIRA UCI) được xác định trong triển khai AOSP.
- CONFIG_ID_1: phạm vi STATIC STS DS-TWR đơn hướng do FiRa xác định, chế độ trì hoãn, khoảng thời gian 240 mili giây.
- CONFIG_ID_2: trong phạm vi STATIC STS DS-TWR một với nhiều do FiRa xác định, chế độ trì hoãn, khoảng thời gian 200 mili giây. Trường hợp sử dụng thông thường: điện thoại thông minh tương tác với nhiều thiết bị thông minh.
- CONFIG_ID_3: Giống như CONFIG_ID_1, ngoại trừ Góc đến (AoA) không được báo cáo.
- CONFIG_ID_4: Giống như CONFIG_ID_1, ngoại trừ chế độ bảo mật P-STS là bật.
- CONFIG_ID_5: Giống như CONFIG_ID_2, ngoại trừ chế độ bảo mật P-STS là bật.
- CONFIG_ID_6: Giống như CONFIG_ID_3, ngoại trừ chế độ bảo mật P-STS là bật.
- CONFIG_ID_7: Giống như CONFIG_ID_2, ngoại trừ người được kiểm soát cá nhân P-STS chế độ chính được bật.
[C-1-4] PHẢI cung cấp thuộc tính tương tác của người dùng để cho phép người dùng bật/tắt UWB trạng thái bật/tắt của đài.
[C-1-5] PHẢI thực thi những ứng dụng đó bằng cách sử dụng UWB radio giữ UWB_RANGING quyền (trong nhóm quyền NEARBY_DEVICES).

Vượt qua các bài kiểm tra về sự tuân thủ và chứng nhận có liên quan do 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 chính xác.

7,4. Khả năng kết nối dữ liệu

7.4.1. Điện thoại

"Điện thoại" như được sử dụng bởi API Android và tài liệu này đề cập cụ thể đến phần cứng liên quan đến việc gọi thoại và gửi tin nhắn SMS, hoặc thiết lập dữ liệu di động qua điện thoại di động (ví dụ: GSM, CDMA, LTE, NR)GSM hoặc CDMA mạng. Một thiết bị hỗ trợ dịch vụ "Điện thoại" có thể chọn cung cấp một số hoặc tất cả cuộc gọi, tin nhắn và dữ liệu phù hợp với sản phẩm.

Android CÓ THỂ được sử dụng trên các thiết bị không có phần cứng điện thoại. Đó tức là Android tương thích với các thiết bị không phải là điện thoại.

Nếu quá trình triển khai thiết bị bao gồm cả điện thoại GSM hoặc CDMA, thì các quá trình triển khai đó:

[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 hỗ trợ đầy đủ cho API cho công nghệ đó.
NÊN cho phép tất cả các loại dịch vụ di động hiện có (2G, 3G, 4G, 5G, v.v.) trong khi thực hiện cuộc gọi khẩn cấp (bất kể loại mạng được thiết lập bởi SetAllowedNetworkTypeBitmap()).

Nếu quá trình triển khai thiết bị không bao gồm phần cứng điện thoại, thì các quá trình này sẽ:

[C-2-1] PHẢI triển khai các API đầy đủ dưới dạng không hoạt động.

Nếu quá trình triển khai thiết bị có hỗ trợ eUICC hoặc eSIM/SIM được nhúng hay không và bao gồm một cơ chế độc quyền để cung cấp chức năng eSIM cho bên thứ ba nhà phát triển, họ:

[C-3-1] PHẢI khai báo android.hardware.telephony.euicc cờ tính năng.

Nếu quá trình triển khai thiết bị không đặt thuộc tính hệ thống ro.telephony.iwlan\_operation\_mode thành "cũ", thì các hoạt động triển khai thiết bị sẽ:

[C-4-1] KHÔNG ĐƯỢC báo cáo "NETWORK_TYPE_IWLAN" thông qua NetworkRegistrationInfo#getAccessNetworkCreation() khi NetworkRegistrationInfo#getTransportType() được báo cáo là "TRANSPORT_TYPE_WWAN" cho cùng một đối tượng NetworkRegistrationInfo.

Trường hợp quá trình triển khai thiết bị có hỗ trợ một Hệ thống con đa phương tiện IP (IMS) duy nhất hay không cho cả dịch vụ điện thoại đa phương tiện (MMTEL) và các tính năng của dịch vụ giao tiếp đa dạng (RCS) và dự kiến sẽ tuân thủ với các yêu cầu của nhà mạng di động liên quan đến việc sử dụng Đăng ký IMS cho tất cả lưu lượng truyền tín hiệu IMS, họ:

[C-5-1] PHẢI khai báo android.hardware.telephony.ims cờ tính năng và cung cấp cách triển khai hoàn chỉnh ImsService API cho cả API Trao đổi khả năng người dùng MMTEL và RCS RCS.
[C-5-2] PHẢI khai báo android.hardware.telephony.ims.singlereg cờ tính năng và cung cấp hoạt động triển khai đầy đủ SipTransport API, API GbaService, các chỉ báo mang chuyên dụng bằng cách sử dụng IRadio 1.6 HAL và việc cung cấp qua Máy chủ cấu hình tự động (ACS) hoặc cấp phép thuộc quyền sở hữu riêng khác bằng cách sử dụng API Cấu hình IMS.

Nếu các hoạt động 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 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 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 được chỉ định bởi android.provider.Telephony.Sms#getDefaultSmsPackage PHẢI sử dụng SmsManager API khi gửi và nhận tin nhắn SMS và MMS. Tài liệu tham khảo về AOSP (Dự án nguồn mở Android) phương thức triển khai trong gói/ứng dụng/Nhắn tin đáp ứng yêu cầu này.
[C-6-3] Ứng dụng phản hồi với Intent#ACTION_DIAL PHẢI hỗ trợ nhập mã trình quay số tuỳ ý có định dạng là *#*#CODE#*#* và kích hoạt một TelephonyManager#ACTION_SECRET_CODE truyền tin.
[C-6-4] Ứng dụng phản hồi với Intent#ACTION_DIAL PHẢI sử dụng VoicemailContract.Voicemails#TRANSCRIPTION để hiển thị bản chép lời thư thoại kèm theo hình ảnh cho người dùng nếu tính năng này hỗ trợ hình ảnh ghi âm thư thoại.
[C-6-5] PHẢI đại diện cho tất cả SubscriptionInfo có bằng thông tin tương đương mã nhận dạng duy nhất (UUID) nhóm dưới dạng một gói thuê bao trong tất cả các thành phần tương tác hiển thị cho người dùng hiển thị và kiểm soát thông tin thẻ SIM. Ví dụ về các thành phần tương tác này bao gồm phần cài đặt giao diện phù hợp 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ó mã nhận dạng duy nhất của nhóm không rỗng và bit cơ hội trong mọi thành phần hiển thị cho người dùng cho phép định cấu hình hoặc kiểm soát chế độ cài đặt thẻ SIM.

Nếu các hoạt động triển khai thiết bị báo cáo tính năng android.hardware.telephony và cung cấp thanh trạng thái hệ thống, sau đó:

[C-7-1] PHẢI chọn một gói thuê bao đại diện đang hoạt động cho một gói thuê bao cụ thể mã nhận dạng duy nhất (UUID) nhóm để hiển thị cho người dùng trong mọi thành phần cung cấp trạng thái SIM của bạn. Ví dụ về các thành phần này bao gồm thanh trạng thái di động biểu tượng tín hiệu hoặc ô cài đặt nhanh.
[C-SR-1] Bạn giới thiệu về gói thuê bao đại diện. đã được chọn là gói thuê bao dữ liệu đang hoạt động trừ khi thiết bị hỗ trợ tính năng thoại cuộc gọi mà trong thời gian đó, người đại diện KHÔNG ĐƯỢC ĐỀ XUẤT là gói thuê bao Voice đang hoạt động.

Nếu các hoạt động 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 tối đa số kênh logic (tổng cộng 20 kênh) cho mỗi UICC theo ETSI TS 102 221.
[C-6-8] KHÔNG ĐƯỢC áp dụng bất kỳ hành vi nào sau đây cho các ứng dụng của nhà mạng đang hoạt động (như được chỉ định bởi TelephonyManager#getCarrierServicePackageName) tự động hoặc không có 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ế thực thi ứng dụng ở nền trước hoặc ở nền sau ngoài các tính năng quản lý nguồn hiện có trong AOSP (Dự án nguồn mở Android)
- Tắt hoặc gỡ cài đặt ứng dụng

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony và đều đang hoạt động, gói thuê bao không có cơ hội có chia sẻ mã nhận dạng duy nhất (UUID) của nhóm bị tắt, bị loại bỏ khỏi thiết bị hoặc đánh dấu là cơ hội, thì thiết bị:

[C-8-1] PHẢI tự động tắt tất cả các hoạt động còn lại cơ hội các gói thuê bao trong cùng nhóm.

Nếu các quá trình triển khai thiết bị bao gồm điện thoại GSM nhưng không bao gồm điện thoại CDMA, thì các quá trình triển khai đó:

[C-9-1] KHÔNG ĐƯỢC khai báo PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] PHẢI gửi IllegalArgumentException khi cố gắng đặt bất kỳ Các loại mạng 3GPP2 trong mặt nạ bit loại mạng được ưu tiên hoặc được cho phép.
[C-9-3] PHẢI trả về một chuỗi trống từ TelephonyManager#getMeid.

Nếu các phương thức triển khai thiết bị hỗ trợ eUICC bằng nhiều cổng và cấu hình, thì các thiết bị đó:

[C-10-1] PHẢI khai báo android.hardware.telephony.euicc.mep cờ tính năng.

7.4.1.1. Khả năng tương thích với tính năng chặn số

Nếu quá trình triển khai thiết bị báo cáo tính năng android.hardware.telephony.calling, thì các quy trình triển khai trên thiết bị sẽ:

[C-1-1] PHẢI bao gồm tính năng hỗ trợ chặn số
[C-1-2] PHẢI triển khai đầy đủ BlockedNumberContract và API tương ứng theo 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 "Bị chặnNumberProvider" 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 được gỡ bỏ như mô tả trong SDK tài liệu.
[C-1-4] PHẢI ghi vào nhà cung cấp nhật ký cuộc gọi trên nền tảng cho cuộc gọi bị chặn và PHẢI lọc cuộc gọi có BLOCKED_TYPE trong số chế độ xem nhật ký cuộc gọi mặc định trong ứng dụng gọi điện đượ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 đối với thư 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 được mở với ý định được TelecomManager.createManageBlockedNumbersIntent() trả về .
[C-1-7] KHÔNG ĐƯỢC cho phép người dùng phụ xem hoặc chỉnh sửa các số bị chặn trên thiết bị dưới dạng nền tảng Android giả định người dùng chính có đầy đủ quyền kiểm soát các dịch vụ điện thoại (một đối tượng duy nhất) trên thiết bị. Tất cả giao diện người dùng có liên quan đến tính năng chặn PHẢI được ẩn đối với người dùng phụ và danh sách bị chặn PHẢI vẫn được tôn trọng.
NÊN di chuyển các số bị chặn sang nhà cung cấp khi thiết bị cập nhật lên Android 7.0.
NÊN cung cấp thành phần tương tác cho người dùng để hiển thị các lệnh gọi bị chặn trong tệp cài đặt sẵn trình quay số.

7.4.1.2. API viễn thông

Nếu quá trình triển khai thiết bị báo cáo android.hardware.telephony.calling, họ sẽ:

[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 tương tác cho người dùng chấp nhận hoặc từ chối cuộc gọi đến khi người dùng đang tham gia cuộc gọi đang diễn ra do một ứng dụng bên thứ ba tạo ra không hỗ trợ tính năng lưu giữ dữ liệu được chỉ định qua CAPABILITY_SUPPORT_HOLD.
[C-1-3] PHẢI có ứng dụng triển khai InCallService.
[C-SR-1] Are mã ĐỀ XUẤT để thông báo cho người dùng biết rằng họ đang trả lời một câu hỏi cuộc gọi đến sẽ bị ngắt một cuộc gọi đang diễn ra.

Việc triển khai AOSP đáp ứng các yêu cầu này thông qua một thông báo quan trọng cho người dùng biết rằng việc trả lời cuộc gọi đến sẽ khiến cuộc gọi khác cần bị ngắt.
[C-SR-2] Are Từ ĐỀ XUẤT NÊN tải trước ứng dụng trình quay số mặc định hiển thị mục nhập nhật ký cuộc gọi và tên của một ứng dụng bên thứ ba trong nhật ký cuộc gọi khi ứng dụng bên thứ ba đặt EXTRA_LOG_SELF_MANAGED_CALLS khoá bổ sung trên PhoneAccount đến true.
[C-SR-3] Are trì hoãn phát hành để xử lý tai nghe âm thanh Sự kiện KEYCODE_MEDIA_PLAY_PAUSE và KEYCODE_HEADSETHOOK cho android.telecom như dưới đây:
- Gọi Connection.onDisconnect() khi hệ thống phát hiện thấy thao tác nhấn nhanh sự kiện chính trong một cuộc gọi đang diễn ra.
- Gọi Connection.onAnswer() khi phát hiện thấy thao tác nhấn nhanh sự kiện chính trong cuộc gọi đến.
- Gọi Connection.onReject() khi phát hiện thấy người dùng nhấn và giữ sự kiện chính 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 dữ liệu di động NAT-T

Triển khai thiết bị:

NÊN bao gồm tính năng hỗ trợ giảm tải duy trì kết nối mạng di động.

Liệu các phương pháp triển khai cho thiết bị có bao gồm tính năng hỗ trợ giảm tải dữ liệu di động duy trì hoạt động và hiển thị chức năng cho các ứng dụng bên thứ ba, họ:

[C-1-1] PHẢI hỗ trợ SocketKeepAlive API.
[C-1-2] PHẢI hỗ trợ ít nhất một khe giữ kết nối đồng thời qua mạng di động.
[C-1-3] PHẢI hỗ trợ đồng thời nhiều khe cắm giữ mạng di động đồng thời được hỗ trợ bởi Lớp trừu tượng phần cứng di động (Cellular Radio HAL).
[C-SR-1] Are trì hoãn việc hỗ trợ ít nhất ba thiết bị di động keepalive vị trí cho mỗi thực thể vô tuyến.

Nếu quá trình triển khai thiết bị không bao gồm tính năng hỗ trợ giảm tải trong khi duy trì kết nối mạng di động, chúng:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Triển khai thiết bị:

NÊN bao gồm tính năng hỗ trợ cho một hoặc nhiều biểu mẫu 802.11.

Nếu việc triển khai thiết bị bao gồm tính năng hỗ trợ cho 802.11 và hiển thị cho một ứng dụng bên thứ ba, chúng:

[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 multicast API như được mô tả trong tài liệu SDK.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-4] PHẢI hỗ trợ DNS đa hướng (mDNS) và KHÔNG ĐƯỢC lọc các gói mDNS (224.0.0.251 hoặc ff02::fb) bất kỳ lúc nào hoạt động, kể cả khi màn hình không ở trạng thái đang hoạt động, trừ phi loại bỏ hoặc lọc các gói này mức cần thiết để nằm trong phạm vi tiêu thụ điện năng theo quy định các yêu cầu bắt buộc áp dụng cho thị trường mục tiêu.

[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) tại bất kỳ thời điểm hoạt động nào, kể cả khi màn hình không ở trạng thái hoạt động trừ phi khoá đa hướng không được giữ và các gói được lọc bằng APF. Các gói không bắt buộc phải đáp ứng bất kỳ Hoạt động mDNS hiện được các ứng dụng yêu cầu qua NsdManager API. Tuy nhiên, thiết bị CÓ THỂ lọc các gói mDNS nếu cần làm như vậy để nằm trong phạm vi tiêu thụ điện năng bắt buộc theo các yêu cầu theo quy định có thể áp dụng cho thị trường mục tiêu.

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

[C-1-5] KHÔNG ĐƯỢC xử lý WifiManager.enableNetwork() Lệnh gọi phương thức API là một chỉ báo đầy đủ để chuyển đổi lệnh gọi phương thức đang hoạt động Network được dùng theo mặc định cho lưu lượng truy cập ứng dụng và được trả về của ConnectivityManager Các phương thức API như getActiveNetwork và registerDefaultNetworkCallback. Nói cách khác, các thiết bị này CÓ THỂ chỉ vô hiệu hoá quyền truy cập Internet do nhà cung cấp dịch vụ mạng khác (ví dụ: dữ liệu di động) nếu họ xác thực thành công mạng Wi-Fi đang cung cấp quyền truy cập Internet.
[C-1-6] Are trì hoãn tới, khi ConnectivityManager.reportNetworkConnectivity() Phương thức API được gọi, đánh giá lại quyền truy cập Internet trên Network và sau khi quá trình đánh giá xác định rằng Network hiện tại không còn cung cấp Truy cập Internet, chuyển sang bất kỳ mạng nào khác có sẵn (ví dụ: mạng di động dữ liệu) cung cấp quyền truy cập Internet.
[C-1-7] PHẢI sắp xếp ngẫu nhiên địa chỉ MAC nguồn và số thứ tự của đầu dò yêu cầu khung hình, một lần vào đầu mỗi lần quét, trong khi STA đã ngắt kết nối.
[C-1-8] PHẢI sử dụng một địa chỉ MAC nhất quán (KHÔNG ĐƯỢC sắp xếp ngẫu nhiên địa chỉ MAC trong một nửa quá trình quét).
[C-1-9] PHẢI lặp lại số thứ tự yêu cầu thăm dò như bình thường (tuần tự) giữa các lần yêu cầu đầu dò trong một lần quét.
[C-1-10] PHẢI ngẫu nhiên hoá số trình tự yêu cầu đầu dò giữa đầu dò cuối cùng yêu cầu 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] AreĐể chỉ định ngẫu nhiên địa chỉ MAC nguồn được dùng cho tất cả giao tiếp STA với một Điểm truy cập (AP) khi đang liên kết và liên kết.
- Thiết bị PHẢI sử dụng một địa chỉ MAC ngẫu nhiên khác nhau cho từng SSID (FQDN cho Passpoint) mà nó giao tiếp.
- Thiết bị PHẢI cung cấp cho người dùng tuỳ chọn kiểm soát sắp xếp ngẫu nhiên theo SSID (FQDN cho Passpoint) với phương pháp không ngẫu nhiên và các tuỳ chọn ngẫu nhiên và PHẢI đặt chế độ mặc định cho Wi-Fi mới cấu hình ngẫu nhiên.
[C-SR-2] Giới hạn định dạng dùng để sử dụng BSSID ngẫu nhiên cho mọi AP mà họ tạo.
- Địa chỉ MAC PHẢI được chọn ngẫu nhiên và duy trì theo SSID mà Điểm truy cập
- THIẾT BỊ CÓ THỂ cung cấp cho người dùng tuỳ chọn tắt tính năng này. Nếu bạn cung cấp một tuỳ chọn như vậy, thì tính năng sắp xếp ngẫu nhiên PHẢI được bật theo mặc định.

Nếu quá trình triển khai thiết bị có hỗ trợ chế độ tiết kiệm điện Wi-Fi như đã xác định theo tiêu chuẩn IEEE 802.11, chúng:

NÊN tắt chế độ tiết kiệm điện Wi-Fi bất cứ khi nào ứng dụng có được Khoá WIFI_MODE_FULL_HIGH_PERF hoặc WIFI_MODE_FULL_LOW_LATENCY khoá qua WifiManager.createWifiLock() vàWifiManager.WifiLock.acquire() API và khoá đang hoạt động.
[C-3-2] Độ trễ trung bình trọn vòng giữa thiết bị và một điểm truy cập khi thiết bị đang ở chế độ Khoá độ trễ thấp của Wi-Fi Chế độ (WIFI_MODE_FULL_LOW_LATENCY) PHẢI nhỏ hơn độ trễ khi ở chế độ Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] AreĐể giảm thiểu độ trễ trọn vòng 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 quá trình triển khai thiết bị có hỗ trợ Wi-Fi và sử dụng Wi-Fi để quét vị trí, chúng:

[C-2-1] PHẢI cung cấp thuộc tính tương tác của người dùng để bật/tắt việc đọc giá trị thông qua WifiManager.isScanAlwaysAvailable API.

7.4.2.1. Wi-Fi Direct

Triển khai thiết bị:

PHẢI bao gồm tính năng hỗ trợ Wi-Fi Direct (Wi-Fi ngang hàng).

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

[C-1-1] PHẢI triển khai tương ứng Android API như được mô tả trong tài liệu SDK.
[C-1-2] PHẢI báo cáo tính năng phần cứng android.hardware.wifi.direct.
[C-1-3] PHẢI hỗ trợ hoạt động Wi-Fi thông thường.
[C-1-4] PHẢI hỗ trợ đồng thời các hoạt động Wi-Fi và Wi-Fi Direct.
[C-SR-1] Are được linh hoạt đề nghị để ngẫu nhiên hoá địa chỉ MAC nguồn cho tất 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 qua đường hầm Wi-Fi

Triển khai thiết bị:

NÊN bao gồm nội dung hỗ trợ cho Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS) như được mô tả trong Tài liệu SDK Android.

Nếu quá trình triển khai thiết bị bao gồm hỗ trợ cho TDLS và TDLS được bật bởi WiFiManager API, chúng:

[C-1-1] PHẢI khai báo khả năng hỗ trợ TDLS đến WifiManager.isTdlsSupported.
NÊN sử dụng TDLS chỉ khi có thể VÀ có lợi.
NÊN có một số suy nghiệm và KHÔNG sử dụng TDLS khi hiệu suất của nó có thể tệ hơn là đi qua điểm truy cập Wi-Fi.

7.4.2.3. Nhận biết Wi-Fi

Triển khai thiết bị:

NÊN bao gồm tính năng hỗ trợ Nhận biết Wi-Fi.

Nếu quá trình triển khai thiết bị có hỗ trợ tính năng Nhận biết Wi-Fi và hiển thị cho các ứng dụng bên thứ ba, thì chúng:

[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ợ đồng thời các hoạt động nhận biết Wi-Fi và Wi-Fi.
[C-1-4] PHẢI sắp xếp ngẫu nhiên địa chỉ giao diện quản lý nhận biết Wi-Fi theo khoảng thời gian không quá 30 phút và bất cứ khi nào bật tính năng Nhận biết Wi-Fi, trừ trường hợp thao tác khác nhau đang diễn ra hoặc đường dẫn dữ liệu Aware đang hoạt động (không tạo ngẫu nhiên dự kiến miễn là đường dẫn dữ liệu đang hoạt động).

Nếu quá trình triển khai thiết bị có bao gồm tính năng hỗ trợ Nhận biết Wi-Fi và Vị trí Wi-Fi như mô tả trong Mục 7.4.2.5 và hiển thị các chức năng này cho các ứng dụng bên thứ ba, thì chúng:

[C-2-1] PHẢI triển khai các API khám phá nhận biết vị trí: setRangingEnabled, setMinDistanceMm! setMaxDistanceMm, và onServiceđược phát hiện trong phạm vi.

7.4.2.4. Điểm truy cập Wi-Fi

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

[C-1-1] PHẢI include hỗ trợ cho Wi-Fi Passpoint.
[C-1-2] PHẢI triển khai các API WifiManager liên quan đến Passpoint dưới dạng được mô tả trong tài liệu về SDK.
[C-1-3] PHẢI hỗ trợ IEEE 802.11u tiêu chuẩn, cụ thể có liên quan vào Khám phá và lựa chọn mạng, chẳng hạn như Quảng cáo chung Dịch vụ (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 cho mạng Passpoint.
[C-1-6] PHẢI hỗ trợ ít nhất là tập hợp con của hoạt động cấp phép thiết bị sau đây các giao thức như được xác định trong Wi-Fi Alliance Passpoint R2: EAP-TTLS và SOAP-XML.
[C-1-7] PHẢI xử lý chứng chỉ máy chủ AAA như mô tả trong Thông số kỹ thuật Điểm phát sóng 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 giữ cho cấu hình Passpoint luôn ổn định qua các lần khởi động lại.
[C-SR-1] Are Internet ĐỀ XUẤT NÊN hỗ trợ các điều khoản và điều kiện chấp nhận.
[C-SR-2] Giới hạn định dạng khuyến nghị để hỗ trợ tính năng Thông tin về địa điểm.

Nếu bạn cung cấp nút chuyển chế độ kiểm soát người dùng để tắt Passpoint chung, thì các cách triển khai:

[C-3-1] PHẢI bật Passpoint theo mặc định.

7.4.2.5. Vị trí Wi-Fi (Thời gian trọn vòng sử dụng Wi-Fi - RTT)

Triển khai thiết bị:

NÊN bao gồm tính năng hỗ trợ Vị trí Wi-Fi.

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

[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 sắp xếp ngẫu nhiên địa chỉ MAC nguồn cho mỗi gói RTT lệnh này được thực thi trong khi giao diện Wi-Fi mà RTT là đang được thực thi sẽ không được liên kết với một Điểm truy cập.
[C-1-4] PHẢI chính xác trong phạm vi 2 mét tại băng thông 80 MHz tại điểm thứ 68 phân vị (như được tính bằng Hàm phân phối tích luỹ).
[C-SR-1] Giới hạn định dạng giới thiệu để báo cáo chính xác trong phạm vi 1,5 mét ở băng thông 80 MHz ở bách phân vị thứ 68 (theo tính toán của Hàm phân phối tích lũy).

7.4.2.6. Giảm tải tính năng duy trì kết nối Wi-Fi

Triển khai thiết bị:

NÊN bao gồm tính năng hỗ trợ giảm tải cho duy trì kết nối Wi-Fi.

Nếu các phương thức triển khai thiết bị có bao gồm tính năng hỗ trợ giảm tải Wi-Fi duy trì hoạt động và tiết lộ chức năng này cho các ứng dụng bên thứ ba, họ sẽ:

[C-1-1] PHẢI hỗ trợ API SocketKeepAlive.
[C-1-2] PHẢI hỗ trợ ít nhất ba khe giữ kết nối đồng thời qua Wi-Fi

Nếu quá trình triển khai thiết bị không bao gồm tính năng hỗ trợ giảm tải Wi-Fi duy trì hoạt động, chúng:

[C-2-1] PHẢI trả về ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (Giao thức cấp phép thiết bị)

Triển khai thiết bị:

PHẢI bao gồm tính năng hỗ trợ Wi-Fi Easy Connect (DPP).

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

[C-1-1] PHẢI có WifiManager#isEasyConnectSupported() trả về phương thức true.

7.4.2.8. Xác thực chứng chỉ máy chủ Wi-Fi doanh nghiệp

Nếu chứng chỉ máy chủ Wi-Fi chưa được xác thực hoặc máy chủ Wi-Fi chưa đặt tên miền, các cách triển khai thiết bị:

[C-SR-1] Giới hạn định dạng đề nghị không cung cấp cho người dùng một 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 khi sử dụng lần đầu (TOFU)

Nếu quá trình triển khai thiết bị hỗ trợ tính năng Tin cậy lần sử dụng đầu tiên (TOFU) và cho phép người dùng xác định các cấu hình WPA/WPA2/WPA3-Enterprise, thì họ:

[C-4-1] PHẢI cung cấp cho người dùng một tuỳ chọn để chọn sử dụng TOFU.

7.4.3. Bluetooth

Nếu quá trình triển khai thiết bị hỗ trợ cấu hình Âm thanh Bluetooth, thì các quá trình triển khai thiết bị đó sẽ:

NÊN hỗ trợ Codec âm thanh nâng cao và Codec âm thanh Bluetooth (ví dụ: LDAC)

Nếu quá trình triển khai thiết bị hỗ trợ HFP, A2DP và AVRCP, thì các thiết bị đó:

PHẢI hỗ trợ tổng cộng ít nhất 5 thiết bị.

Nếu quá trình triển khai thiết bị khai báo android.hardware.vr.high_performance tính năng, chúng:

[C-1-1] PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data dài mở rộng.

Android có hỗ trợ Bluetooth và Bluetooth năng lượng thấp.

Nếu quá trình triển khai thiết bị có bao gồm tính năng hỗ trợ Bluetooth và Bluetooth Năng lượng thấp, các chủ đề này:

[C-2-1] PHẢI khai báo các tính năng có liên quan của nền tảng (android.hardware.bluetooth và android.hardware.bluetooth_le) tương ứng) 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 như A2DP, AVRCP, OBEX, HFP, v.v. phù hợp với thiết bị.

Nếu quá trình triển khai thiết bị có hỗ trợ Bluetooth năng lượng thấp (BLE), thì các thiết bị đó sẽ:

[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 Bluetooth dựa trên GATT (generic thuộc tính hồ sơ) API theo mô tả trong tài liệu SDK và android.bluetooth.
[C-3-3] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isOffloadedFilteringSupported() để cho biết liệu logic lọc cho ScanFilter Các lớp API đã được triển khai.
[C-3-4] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isMultipleAdvertisementSupported() để cho biết Quảng cáo năng lượng thấp có được hỗ trợ hay không.
[C-3-5] PHẢI triển khai thời gian chờ Địa chỉ riêng có thể phân giải (RPA) không còn nữa hơn 15 phút và xoay địa chỉ khi hết thời gian chờ để bảo vệ quyền riêng tư của người dùng khi thiết bị đang sử dụng BLE để quét hoặc quảng cáo. Để ngăn các cuộc tấn công định thời gian, khoảng thời gian chờ cũng PHẢI được chọn ngẫu nhiên từ 5 đến 15 phút.
NÊN hỗ trợ giảm tải logic lọc cho chipset bluetooth khi triển khai Quét API.
NÊN hỗ trợ giảm tải quá trình quét theo lô sang chipset Bluetooth.
NÊN hỗ trợ nhiều quảng cáo có ít nhất 4 vị trí.

Nếu quá trình triển khai thiết bị có hỗ trợ Bluetooth LE và sử dụng Bluetooth LE cho quét vị trí, họ:

[C-4-1] PHẢI cung cấp thuộc tính tương tác của người dùng để bật/tắt tính năng đọc giá trị thông qua API Hệ thống BluetoothAdapter.isBleScanAlwaysAvailable().

Nếu quá trình triển khai thiết bị có bao gồm tính năng hỗ trợ Bluetooth LE và Thiết bị trợ thính Cấu hình, như được mô tả trong Hỗ trợ âm thanh trợ thính bằng Bluetooth LE, họ:

[C-5-1] PHẢI trả về true cho BluetoothAdapter.getProfileProxy(bối cảnh, trình nghe, BluetoothProfile.HEARING_AID).

Nếu quá trình triển khai thiết bị có hỗ trợ Bluetooth hoặc Bluetooth năng lượng thấp, chúng:

[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ư quét kết quả) có thể được dùng để lấy thông tin vị trí của thiết bị, trừ phi ứng dụng yêu cầu chuyển thành công android.permission.ACCESS_FINE_LOCATION kiểm tra quyền dựa trên trạng thái nền trước/nền trước hiện tại.

Nếu quá trình triển khai thiết bị có bao gồm tính năng hỗ trợ Bluetooth hoặc Bluetooth năng lượng thấp và tệp kê khai ứng dụng không chứa nội dung khai báo của nhà phát triển nêu rõ chúng không lấy thông tin vị trí qua Bluetooth, thì họ:

[C-6-2] PHẢI cổng truy cập Bluetooth phía sau android.permission.ACCESS_FINE_LOCATION.

Nếu quá trình triển khai thiết bị trả về true cho phần BluetoothAdapter.isLeAudioSupported() API, thì chúng:

[C-7-1] PHẢI hỗ trợ máy khách unicast.
[C-7-2] PHẢI hỗ trợ 2M PHY.
[C-7-3] PHẢI hỗ trợ Quảng cáo mở rộng LE.
[C-7-4] PHẢI hỗ trợ ít nhất 2 kết nối CIS trong một CIG.
[C-7-5] PHẢI bật BAP unicast client, CSIP set coordinator, MCP server, Bộ điều khiển VCP, máy chủ CCP cùng lúc.
[C-SR-1] Are Để bật chế độ máy khách HAP unicast, bạn phải bật chế độ này.

Nếu quá trình triển khai thiết bị trả về true cho phần BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, thì chúng:

[C-8-1] PHẢI hỗ trợ ít nhất 2 liên kết BIS trong một BIG.
[C-8-2] PHẢI bật nguồn phát sóng BAP, trợ lý truyền tin BAP đồng thời.
[C-8-3] PHẢI hỗ trợ Quảng cáo định kỳ LE.

Nếu quá trình triển khai thiết bị trả về true cho phần BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, thì chúng:

[C-9-1] PHẢI hỗ trợ PAST (Định kỳ chuyển dữ liệu đồng bộ hoá quảng cáo).
[C-9-2] PHẢI hỗ trợ Quảng cáo định kỳ LE.

Nếu các hoạt động triển khai thiết bị khai báo FEATURE_BLUETOOTH_LE, thì các quá trình triển khai thiết bị đó sẽ:

[C-10-1] PHẢI có các phép đo RSSI nằm trong khoảng +/-9dB cho 95% của các phép đo ở khoảng cách 1m từ thiết bị tham chiếu truyền tại ADVERTISE_TX_POWER_HIGH trong môi trường tầm nhìn.
[C-10-2] PHẢI bao gồm các chỉnh sửa Rx/Tx để giảm độ lệch theo từng kênh để số đo trên mỗi kênh trong số 3 kênh, trên mỗi ăng-ten (nếu sử dụng nhiều cột), nằm trong phạm vi +/-3dB của nhau trong 95% của thiết bị đo lường.
[C-SR-2] AreĐể chỉ định và bù trừ cho Rx, Đảm bảo trung vị của BLE RSSI là -60dBm +/-10 dB ở khoảng cách 1m thiết bị tham chiếu đang truyền tại ADVERTISE_TX_POWER_HIGH, trong đó các thiết bị đang được định hướng sao cho chúng nằm trên mặt phẳng song song có màn hình hướng về nhau .
[C-SR-3] AreEmailAddress NÊN đo lường và bù đắp cho giá trị bù trừ Tx thành Đảm bảo trung vị của BLE RSSI là -60dBm +/-10 dB khi quét từ một tham chiếu thiết bị được đặt ở khoảng cách 1m và truyền với tốc độ ADVERTISE_TX_POWER_HIGH, nơi các thiết bị được định hướng để bật "Parallel Planes" có màn hình hướng về cùng một hướng.

NÊN làm theo các bước thiết lập đo lường được chỉ định trong Các yêu cầu về việc hiệu chỉnh sự có mặt.

7.4.4. Giao tiếp phạm vi gần

Triển khai thiết bị:

NÊN bao gồm bộ thu phát và phần cứng có liên quan cho trường gần Giao tiếp (NFC).
[C-0-1] PHẢI triển khai android.nfc.NdefMessage và android.nfc.NdefRecord ngay cả khi chúng không hỗ trợ NFC hoặc Hãy khai báo tính năng android.hardware.nfc vì các lớp đại diện cho định dạng biểu diễn dữ liệu độc lập với giao thức.

Nếu việc triển khai thiết bị bao gồm phần cứng NFC và lên kế hoạch cung cấp công cụ này cho ứng dụng bên thứ ba, họ:

[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 qua NFC sau đây như sau:
[C-1-2] PHẢI có khả năng hoạt động như một người đọc/người viết của Diễn đàn NFC (như được xác định theo thông số kỹ thuật của Diễn đàn NFC NFCDiễn đàn-TS-DigitalProtocol-1.0) thông qua các tiêu chuẩn NFC sau đây:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Các loại thẻ diễn đàn NFC 1, 2, 3, 4, 5 (được định nghĩa bởi Diễn đàn NFC)
[C-SR-1] Liên minh khuyến khích nhà phát triển có khả năng đọc và ghi NDEF tin nhắn cũng như dữ liệu thô thông qua các tiêu chuẩn NFC sau đây. Lưu ý rằng trong khi các tiêu chuẩn NFC được nêu rõ là DỄ DÀNG NÊN DÙNG, thì Định nghĩa về khả năng tương thích cho một phiên bản trong tương lai được lên kế hoạch sẽ thay đổi những thông tin này thành PHẢI. Các tiêu chuẩn này là không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Thiết bị mới và hiện có chạy phiên bản này của Android rất được khuyến khích đáp ứng những yêu cầu này để họ 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 cuộc thăm dò ý kiến cho tất cả các công nghệ được hỗ trợ khi khám phá NFC .
PHẢI ở chế độ phát hiện NFC trong khi thiết bị đang bật bằng tính năng màn hình đang hoạt động và màn hình khoá đã mở khoá.
PHẢI có thể đọc được mã vạch và URL (nếu được mã hoá) của Mã vạch NFC xử lý phim Thinfilm của Google dành cho doanh nghiệp.

Lưu ý rằng các đường liên kết được cung cấp công khai không có sẵn cho JIS, ISO và NFC Thông số của diễn đàn được trích dẫn ở trên.

Android có hỗ trợ chế độ Giả lập thẻ máy chủ NFC (HCE).

Nếu quá trình triển khai thiết bị có bao gồm bộ vi mạch đ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), họ:

[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ợ NFC HCE APIs dưới dạng xác định trong SDK Android.

Nếu quá trình triển khai thiết bị có bao gồm một bộ chip điều khiển NFC có khả năng hỗ trợ HCE cho NfcF và triển khai tính năng này cho các ứng dụng của bên thứ ba, họ:

[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 NfcF Card Emulation API như được xác định trong SDK Android.

Nếu quá trình triển khai thiết bị có hỗ trợ NFC chung như mô tả trong và hỗ trợ các công nghệ MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF trên MIFARE Classic) ở vai trò độc giả/người viết, họ:

[C-4-1] PHẢI triển khai các API Android tương ứng như được ghi lại bởi SDK Android.
[C-4-2] PHẢI báo cáo đối tượng com.nxp.mifare từ android.content.pm.PackageManager.hasSystemFeature() . Lưu ý rằng đây không phải là tính năng tiêu chuẩn của Android nên sẽ không xuất hiện dưới dạng một hằng số trong lớp android.content.pm.PackageManager.

7.4.5. Giao thức và API kết nối 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 bao gồm hỗ trợ cho một hoặc nhiều biểu mẫu mạng dữ liệu. Cụ thể, các quá trình triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ cho ít nhất một chuẩn dữ liệu có tốc độ 200 Kbit/giây trở lên. Ví dụ về đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet và Bluetooth PAN.
Ngoài ra, NÊN hỗ trợ ít nhất một dữ liệu không dây phổ biến chẳng hạn như 802.11 (Wi-Fi), khi một 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 bao gồm ngăn xếp mạng IPv6 và hỗ trợ IPv6 giao tiếp bằng 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ư AF_INET6 ổ cắm.
[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ế độ doze.
  - [C-0-5] Giới hạn tốc độ KHÔNG ĐƯỢC khiến thiết bị mất IPv6 khả năng kết nối trên bất kỳ mạng nào tuân thủ IPv6 sử dụng vòng đời RA là ít nhất 180 giây.
[C-0-6] PHẢI cung cấp cho các ứng dụng của bên thứ ba khả năng kết nối IPv6 trực tiếp vào mạng khi được kết nối với mạng IPv6 mà không có bất kỳ dạng địa chỉ nào hoặc quá trình dịch cổng đang diễn ra trên thiết bị. Cả hai API được quản lý như Socket#getLocalAddress hoặc Socket#getLocalPort) và các API NDK như getsockname() hoặc IPV6_PKTINFO PHẢI trả về IP địa chỉ và cổng thực sự dùng để gửi và nhận gói trên mạng và được hiển thị dưới dạng ip nguồn và cổng tới máy chủ Internet (web).

Mức độ hỗ trợ IPv6 cần thiết phụ thuộc vào loại mạng, như minh hoạ trong các yêu cầu sau.

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

[C-1-1] PHẢI hỗ trợ thao tác Dual-stack và IPv6-only trên Wi-Fi.

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

[C-2-1] PHẢI hỗ trợ thao tác ngăn xếp kép và chỉ IPv6 bật Ethernet.

Nếu quá trình triển khai thiết bị có hỗ trợ Dữ liệu di động, thì các thiết bị đó:

[C-3-1] PHẢI hỗ trợ thao tác IPv6 (chỉ IPv6 và có thể ngăn xếp kép) bật di động.

Nếu quá trình triển khai thiết bị hỗ trợ nhiều loại mạng (ví dụ: Wi-Fi và dữ liệu di động), chúng:

[C-4-1] PHẢI đáp ứng đồng thời các yêu cầu trên cho từng 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. Cổng cố định

Cổng cố định là một mạng yêu cầu đăng nhập để truy cập Internet.

Nếu quá trình triển khai thiết bị cung cấp việc triển khai hoàn chỉnh android.webkit.Webview API! chúng:

[C-1-1] PHẢI cung cấp ứng dụng cổng cố định để xử lý ý định ACTION_CAPTIVE_PORTAL_SIGN_IN và hiển thị trang đăng nhập cổng cố định, bằng cách gửi ý định đó, trên lệnh gọi đến System API (API Hệ thống) ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] PHẢI thực hiện phát hiện cổng bị khóa và đăng nhập hỗ trợ thông qua ứng dụng cổng cố định khi thiết bị được kết nối vào 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ác cổng bị khóa bằng cách sử dụng DNS văn bản rõ ràng khi thiết bị được định cấu hình để sử dụng chế độ nghiêm ngặt DNS riêng tư.
[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 trang xác thực.
[C-1-5] PHẢI đảm bảo rằng trong khi người dùng đang đăng nhập vào tài khoản bị bắt giữ cổng, mạng mặc định được các ứng dụng sử dụng (như được trả về bởi ConnectivityManager.getActiveNetwork! ConnectivityManager.registerDefaultNetworkCallback, và được các API mạng Java (chẳng hạn như java.net.Socket) sử dụng theo mặc định và API gốc như connect()) là bất kỳ mạng nào khác có sẵn cung cấp quyền truy cập Internet (nếu có).

7.4.6. Cài đặt đồng bộ hóa

Triển khai thiết bị:

[C-0-1] PHẢI bật chế độ tự động đồng bộ hoá chính theo mặc định để phương thức getMasterSyncAutomatically() sẽ trả về "true".

7.4.7. Trình tiết kiệm dữ liệu

Nếu quá trình triển khai thiết bị có bao gồm kết nối có đo lượng dữ liệu, thì các quá trình đó sẽ:

[C-SR-1] Để cung cấp chế độ tiết kiệm dữ liệu, nhà phát triển được đề xuất DUY NHẤT.

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

[C-1-1] PHẢI hỗ trợ tất cả API trong ConnectivityManager theo mô tả trong tài liệu SDK

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

[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. Phần tử bảo mật

Nếu các quy trình triển khai thiết bị hỗ trợ khả năng Open Mobile API (Mở API dành cho thiết bị di động) và cung cấp các phần tử bảo mật đó cho ứng dụng bên thứ ba, chúng:

[C-1-1] PHẢI liệt kê các phần tử an toàn có sẵn mà người đọc qua android.se.omapi.SEService.getReaders().
[C-1-2] PHẢI khai báo cờ tính năng chính xác 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ó 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 quá trình triển khai thiết bị có bao gồm dịch vụ hỗ trợ cho 802.1.15.4 và hiển thị chức năng cho ứng dụng của bên thứ ba, thì họ:

[C-1-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 Android trong quá trình triển khai.
[C-1-4] PHẢI cung cấp thuộc tính tương tác của người dùng để cho phép người dùng bật/tắt UWB trạng thái bật/tắt của đài.
[C-1-5] PHẢI thực thi những ứng dụng đó bằng quyền UWB radio giữ UWB_RANGING (trong nhóm quyền LAN_DEVICES).
[C-SR-1] Giới hạn định dạng khuyến nghị để vượt qua quy tắc tuân thủ có liên quan và do các tổ chức tiêu chuẩn xác định, bao gồm FIRA, CCC và Quảng cáo tìm kiếm tuỳ chỉnh.
[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% giá trị đo trong môi trường quan sát ở khoảng cách 1m trong buồng không phản chiếu.
[C-1-7] PHẢI đảm bảo rằng trung vị của các phép đo khoảng cách ở 1m cách thiết bị tham chiếu trong phạm vi [0,75m, 1,25m], nơi giá trị mặt đất khoảng cách được đo từ cạnh trên của DUT.
[C-SR-2] Giới hạn định dạng giới thiệu để làm theo các bước thiết lập tính năng đo lường được chỉ định trong Các yêu cầu về việc hiệu chỉnh sự có mặt.

7,5. Camera

Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh, thì chúng:

[C-1-1] PHẢI khai báo cờ tính năng android.hardware.camera.any.
[C-1-2] PHẢI có thể để ứng dụng phân bổ đồng thời 3 bitmap RGBA_8888 bằng với kích thước hình ảnh do cảm biến máy ảnh có độ phân giải lớn nhất trên thiết bị, trong khi máy ảnh đang mở cho 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 máy ảnh mặc định được cài đặt trước xử lý ý định MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, hoặc MediaStore.ACTION_VIDEO_CAPTURE, chịu trách nhiệm xoá thông tin vị trí của người dùng trong siêu dữ liệu hình ảnh trước khi gửi bản nháp đến ứng dụng nhận khi ứng dụng nhận không có ACCESS_FINE_LOCATION.

Nếu quá trình triển khai thiết bị có hỗ trợ tính năng đầu ra HDR 10-bit, thì các quá trình triển khai thiết bị đó:

[C-2-1] PHẢI hỗ trợ ít nhất cấu hình HLG HDR cho mọi thiết bị máy ảnh hỗ trợ đầu ra 10 bit.
[C-2-2] PHẢI hỗ trợ đầu ra 10 bit cho mặt sau chính hoặc mặt trước camera chính ở mặt trước.
[C-SR-1] Are Để hỗ trợ đầu ra 10-bit cho cả hai nền tảng chính camera.
[C-2-3] PHẢI hỗ trợ cùng một cấu hình HDR cho tất cả Camera phụ vật lý 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ị camera logic hỗ trợ HDR 10 bit triển khai chế độ cài đặt android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, chúng:

[C-3-1] PHẢI hỗ trợ chuyển đổi giữa tất cả các thiết bị vật lý có khả năng tương thích ngược camera qua nút điều khiển CONTROL_ZOOM_RATIO trên camera logic.

7.5.1. Camera mặt sau

Máy ảnh mặt sau là máy ảnh hướng ra thế giới chụp những cảnh ở phía xa của thiết bị, chẳng hạn như camera truyền thống; trên thiết bị cầm tay, tức là một máy ảnh nằm ở cạnh của thiết bị, đối diện với màn hình.

Triển khai thiết bị:

NÊN có máy ảnh mặt sau.

Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh mặt sau, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera và android.hardware.camera.any
[C-1-2] PHẢI có độ phân giải ít nhất là 2 megapixel.
NÊN triển khai tính năng tự động lấy nét phần cứng hoặc tự động lấy nét bằng phần mềm trong trình điều khiển máy ảnh (trong suốt đối với phần mềm ứng dụng).
CÓ THỂ dùng phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh mở rộng).
CÓ THỂ bao gồm cả đèn flash.

Nếu máy ảnh có đèn flash:

[C-2-1] đèn flash KHÔNG ĐƯỢC sáng trong khi Phiên bản android.hardware.Camera.PreviewCallback đã được đăng ký trên bề mặt xem trước của máy ảnh, trừ phi ứng dụng đã bật một cách rõ ràng flash bằng cách bật thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON của đối tượng Camera.Parameters. Lưu ý rằng hạn chế này không áp dụng cho ứng dụng máy ảnh hệ thống tích hợp của thiết bị mà chỉ được cung cấp cho bên thứ ba bằng Camera.PreviewCallback.

7.5.2. Máy ảnh mặt trước

Máy ảnh mặt trước là máy ảnh dành cho người dùng thường được dùng để chụp ảnh người dùng, chẳng hạn như hội nghị truyền hình và các ứng dụng tương tự; trên thiết bị cầm tay thiết bị, tức là một máy ảnh nằm ở cùng một phía của thiết bị với màn hình.

Triển khai thiết bị:

CÓ THỂ bao gồm cả máy ảnh mặt trước.

Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh mặt trước, thì các thiết bị đó:

[C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera.any và android.hardware.camera.front
[C-1-2] PHẢI có độ phân giải tối thiểu là VGA (640x480 pixel).
[C-1-3] KHÔNG ĐƯỢC sử dụng camera mặt trước làm mặc định cho API Máy ảnh và KHÔNG ĐƯỢC định cấu hình API để coi máy ảnh mặt trước là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị.
[C-1-4] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng được ứng dụng chỉ định khi ứng dụng hiện tại có đã yêu cầu rõ ràng rằng Camera được xoay thông qua một lệnh gọi đến android.hardware.Camera.setDisplayOrientation() . Ngược lại, bản xem trước PHẢI được phản chiếu dọc theo giá trị mặc định của thiết bị trục hoành khi ứng dụng hiện tại không yêu cầu rõ ràng bạn có thể xoay màn hình Camera thông qua một lệnh gọi đến android.hardware.Camera.setDisplayOrientation() .
[C-1-5] KHÔNG ĐƯỢC phản chiếu hình ảnh tĩnh hoặc luồng video được chụp cuối cùng quay lại lệnh gọi lại ứng dụng hoặc cam kết lưu trữ nội dung nghe nhìn.
[C-1-6] PHẢI phản chiếu hình ảnh được chế độ xem hậu kỳ hiển thị theo cùng cách làm luồng hình ảnh xem trước của camera.
CÓ THỂ bao gồm các tính năng (như tự động lấy nét, đèn flash, v.v.) dành cho các camera mặt sau như mô tả trong phần 7.5.1.

Liệu các quá trình triển khai thiết bị có thể được người dùng xoay vòng hay không (chẳng hạn như tự động thông qua gia tốc kế hoặc 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 máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng hiện tại của thiết bị.

7.5.3. Camera bên ngoài

Camera bên ngoài là camera có thể gắn hoặc tách rời việc triển khai thiết bị bất cứ lúc nào và có thể đối mặt với bất kỳ hướng nào; chẳng hạn như USB camera.

Triển khai thiết bị:

CÓ THỂ hỗ trợ máy ảnh bên ngoài mà không nhất thiết luôn kết nối.

Nếu quá trình triển khai thiết bị có hỗ trợ máy ảnh bên ngoài, thì các quá trình triển khai đó:

[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 thiết bị bên ngoài camera 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 tra CTS của máy ảnh bằng thiết bị máy ảnh bên ngoài đã kết nối. Bạn có thể xem thông tin chi tiết về quy trình kiểm thử CTS của máy ảnh tại source.android.com.
NÊN hỗ trợ nén video như MJPEG để cho phép chuyển luồng không mã hóa chất lượng cao (ví dụ: ảnh thô hoặc ảnh được nén độc lập luồng).
CÓ THỂ hỗ trợ nhiều máy ảnh.
CÓ thể hỗ trợ phương thức mã hoá video dựa trên máy ảnh.

Nếu phương thức mã hoá video dựa trên camera được hỗ trợ:

[C-2-1] Một đồng thời không được mã hoá / luồng MJPEG (QVGA hoặc độ phân giải cao hơn) PHẢI truy cập được việc triển khai thiết bị.

7.5.4. Hành vi của API máy ảnh

Android bao gồm hai gói API để truy cập vào máy ảnh, gói mới hơn API android.hardware.camera2 hiển thị tính năng điều khiển camera ở cấp thấp hơn cho ứng dụng, bao gồm các luồng phát trực tuyến/loạt bản không có bản sao hiệu quả và khả năng kiểm soát theo từng khung hình phơi sáng, tăng độ sáng, tăng cân bằng trắng, chuyển đổi màu, khử nhiễu, làm sắc nét, và nhiều lợi ích khác.

Gói API cũ android.hardware.Camera được đánh dấu là không dùng nữa trong Android 5.0 nhưng vẫn có sẵn để các ứng dụng sử dụng. Thiết bị Android Hoạt động triển khai PHẢI đảm bảo việc 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 được dùng nữa và gói android.hardware.camera2 mới hơn PHẢI có hiệu suất tương đương và chất lượng trong cả hai API. Ví dụ: với chế độ cài đặt tương đương, tốc độ và độ chính xác tự động lấy nét phải giống hệt nhau, cũng như chất lượng ảnh chụp phải giống nhau. Các tính năng phụ thuộc vào ngữ nghĩa khác nhau của 2 API không bắt buộc phải có tốc độ hoặc chất lượng phù hợp, nhưng PHẢI khớp gần như nhất có thể.

Quá trình triển khai thiết bị PHẢI triển khai các hành vi sau cho các API liên quan đến camera, dành cho tất cả các camera có sẵn. Triển khai thiết bị:

[C-0-1] PHẢI sử dụng android.hardware.PixelFormat.YCbCr_420_SP để xem trước dữ liệu được cung cấp cho các lệnh gọi lại ứng dụng khi ứng dụng chưa từng gọi android.hardware.Camera.Parameters.setPreviewFormat(int)
[C-0-2] PHẢI ở định dạng mã hoá NV21 hơn nữa khi một ứng dụng sẽ đăng ký một android.hardware.Camera.PreviewCallback thực thể và hệ thống sẽ gọi phương thức onPreviewFrame() và bản 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 máy ảnh cho cả hai máy ảnh trước và sau cho android.hardware.Camera. (Phần cứng bộ mã hoá video và máy ảnh có thể sử dụng bất kỳ định dạng pixel gốc nào, ngoại trừ thiết bị phương thức triển khai PHẢI hỗ trợ chuyển đổi sang YV12.)
[C-0-4] PHẢI hỗ trợ android.hardware.ImageFormat.YUV_420_888 và android.hardware.ImageFormat.JPEG định dạng đầu ra thông qua API android.media.ImageReader dành cho android.hardware.camera2 thiết bị quảng cáo REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE trong android.request.availableCapabilities.
[C-0-5] PHẢI vẫn triển khai Camera API đầy đủ có trong tài liệu SDK Android, bất kể thiết bị bao gồm tự động lấy nét phần cứng hoặc các tính năng khác. Ví dụ: các camera thiếu tính năng tự động lấy nét PHẢI vẫn gọi bất kỳ cuộc gọi nào đã đăng ký android.hardware.Camera.AutoFocusCallback thực thể (mặc dù thực thể này không liên quan đến máy ảnh không tự động lấy nét.) Lưu ý rằng nguyên tắc này áp dụng cho cả mặt trước camera; chẳng hạn, ngay cả khi hầu hết các máy ảnh mặt trước không hỗ trợ tự động lấy nét, thì các lệnh gọi lại API vẫn phải là "giả" như được mô tả.
[C-0-6] PHẢI nhận dạng và tuân thủ từng tên thông số được định nghĩa là hằng số android.hardware.Camera.Parameters và lớp android.hardware.camera2.CaptureRequest. Ngược lại, các hoạt động triển khai thiết bị KHÔNG ĐƯỢC sử dụng hoặc nhận dạng hằng số chuỗi được chuyển vào phương thức android.hardware.Camera.setParameters() ngoại trừ các phương thức được ghi lại dưới dạng hằng số trên android.hardware.Camera.Parameters. Tức là các quá trình triển khai thiết bị PHẢI hỗ trợ tất cả các thông 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ụ: các phương pháp triển khai trên thiết bị có hỗ trợ tính năng chụp ảnh sử dụng kỹ thuật chụp ảnh dải động cao (HDR) PHẢI hỗ trợ thông số máy ảnh Camera.SCENE_MODE_HDR.
[C-0-7] PHẢI báo cáo mức độ hỗ trợ phù hợp bằng android.info.supportedHardwareLevel theo mô tả trong SDK Android và báo cáo cờ tính năng khung.
[C-0-8] PHẢI cũng khai báo chức năng riêng lẻ của máy ảnh là android.hardware.camera2 qua Tài sản 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ị máy ảnh đi kèm nào hỗ trợ tính năng này.
[C-0-9] PHẢI phát sóng Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một bức ảnh mới và khi ảnh đã được thêm vào kho phương tiện.
[C-0-10] PHẢI phát sóng Camera.ACTION_NEW_VIDEO bất cứ khi nào máy ảnh ghi lại một video mới và lối vào của ảnh đã được thêm vào kho phương tiện.
[C-0-11] PHẢI có tất cả các máy ảnh có thể truy cập qua android.hardware.Camera API cũng có thể truy cập được qua android.hardware.camera2 API.
[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, màu da hoặc khuôn mặt làm mịn da cho mọi android.hardware.camera2 hoặc android.hardware.Camera API.
[C-SR-1] Đối với các thiết bị có nhiều máy ảnh RGB ở lại gần và quay mặt về cùng một hướng, nó được ĐỀ XUẤT ĐỂ hỗ trợ một thiết bị máy ảnh logic liệt kê chức năng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA! bao gồm tất cả các camera RGB hướng về phía đó như là thiết bị phụ thực.

Nếu quá trình triển khai thiết bị cung cấp API máy ảnh độc quyền cho các ứng dụng của bên thứ ba, chúng:

[C-1-1] PHẢI triển khai API máy ảnh như vậy bằng android.hardware.camera2 API.
CÓ THỂ cung cấp thẻ và/hoặc tiện ích của nhà cung cấp cho android.hardware.camera2 API.

7.5.5. Hướng máy ảnh

Nếu quá trình triển khai thiết bị có máy ảnh mặt trước hoặc mặt sau, thì(các) máy ảnh đó:

[C-1-1] PHẢI được định hướng để chiều dài của máy ảnh phù hợp với chiều dài của màn hình. Tức là khi thiết bị được cầm ở chế độ ngang thì máy ảnh PHẢI chụp ảnh theo hướng ngang. Chiến dịch này áp dụng bất kể hướng tự nhiên của thiết bị; tức là quy tắc này áp dụng cho thiết bị chính ở chế độ ngang cũng như thiết bị chính ở chế độ dọc.

Những thiết bị đáp ứng tất cả những tiêu chí sau đây sẽ được miễn tuân theo yêu cầu nêu trên:

Thiết bị triển khai màn hình có nhiều biến thể, chẳng hạn như màn hình có thể gập lại hoặc màn hình có bản lề màn hình.
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 giữa hướng dọc-chính thành hướng ngang-chính (hoặc ngược lại).
Các quá trình triển khai thiết bị mà người dùng không thể xoay vòng, chẳng hạn như làm 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 include a Trình quản lý tải xuống mà các ứng dụng CÓ THỂ sử dụng để tải xuống các tệp dữ liệu và chúng PHẢI có khả năng tải xuống từng tệp riêng lẻ có kích thước tối thiểu 100MB về chế độ mặc định "bộ nhớ đệm" vị trí.

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 dung lượng lưu trữ được các ứng dụng dùng chung, cũng thường được gọi dưới dạng "bộ nhớ ngoài dùng chung", "bộ nhớ dùng chung của ứng dụng" hoặc bằng Linux đường dẫn "/sdcard" thiết bị đượ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, trong các thiết bị khác "có sẵn", bất kể bộ nhớ có được triển khai trên một thành phần bộ nhớ trong hoặc phương tiện bộ nhớ di động (ví dụ: Bảo mật Khe cắm thẻ kỹ thuật số).
[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 bao gồm một đường liên kết tượng trưng của Linux từ sdcard đến giá đỡ thực tế điểm.
[C-0-4] PHẢI bật bộ nhớ có giới hạn theo mặc định cho tất cả ứng dụng nhắm đến API cấp 29 trở lên, ngoại trừ trường hợp sau:
- Khi ứng dụng yêu cầu android:requestLegacyExternalStorage="true" trong tệp kê khai.
[C-0-5] PHẢI loại bỏ siêu dữ liệu vị trí, chẳng hạn như thẻ GPS Exif, được lưu trữ trong các tệp nội dung nghe nhìn khi các tệp đó được truy cập thông qua MediaStore, trừ phi ứng dụng gọi có quyền ACCESS_MEDIA_LOCATION.

Việc triển khai thiết bị CÓ THỂ đáp ứng các yêu cầu ở trên bằng cách sử dụng một trong sau:

Bộ nhớ di động mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ Kỹ thuật số bảo mật (SD).
Một phần của bộ nhớ trong (không thể tháo rời) như được triển khai trong Dự án nguồn mở Android (AOSP).

Trường hợp quá trình triển khai thiết bị có sử dụng bộ nhớ di động để đáp ứng các điều kiện nêu trên yêu cầu, chúng:

[C-1-1] PHẢI triển khai thông báo ngắn hoặc giao diện người dùng bật lên để cảnh báo người dùng khi không có phương tiện lưu trữ nào được chèn vào khe.
[C-1-2] PHẢI bao gồm phương tiện lưu trữ theo định dạng FAT (ví dụ: thẻ SD) hoặc chương trình trên hộp và các tài liệu khác có sẵn tại thời điểm mua mà bộ nhớ bạn phải mua riêng phương tiện.

Nếu quá trình triển khai thiết bị có sử dụng một phần bộ nhớ không thể tháo rời để đáp ứng các yêu cầu trên, họ:

NÊN sử dụng phương thức triển khai AOSP của ứng dụng nội bộ được chia sẻ bộ nhớ.
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 quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, chúng:

[C-3-1] PHẢI cung cấp cơ chế truy cập dữ liệu trên ứng dụng bộ nhớ dùng chung từ máy tính lưu trữ.
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ụ quét nội dung đa phương tiện của Android và android.provider.MediaStore.
CÓ THỂ sử dụng bộ nhớ dung lượng lớn USB, nhưng NÊN sử dụng Media Transfer Protocol để đáp ứng yêu cầu này.

Trường hợp quá trình triển khai thiết bị có cổng USB có hỗ trợ và chế độ thiết bị ngoại vi USB Giao thức truyền nội dung nghe nhìn, các tính năng này:

PHẢI tương thích với máy chủ Android MTP tham chiếu, Truyền tệp của Android.
NÊN báo cáo 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ớ tích hợp

Nếu thiết bị dự kiến sẽ là thiết bị di động, không giống như Truyền hình, các cách triển khai thiết bị là:

[C-SR-1] Để triển khai bộ nhớ có thể áp dụng trong một vị trí ổn định lâu dài vì vô tình ngắt kết nối các thiết bị này có thể khiến dữ liệu bị mất/bị hỏng.

Nếu cổng của thiết bị lưu trữ có thể tháo rời nằm ở một vị trí ổn định trong thời gian dài, chẳng hạn như trong ngăn chứa pin hoặc nắp bảo vệ khác, các cách triển khai thiết bị là:

[C-SR-2] Để triển khai bộ nhớ tối đa.

7,7. USB

Nếu các quá trình triển khai thiết bị có cổng USB, thì các quá trình triển khai thiết bị đó sẽ:

NÊN hỗ trợ chế độ thiết bị ngoại vi USB và PHẢI hỗ trợ chế độ máy chủ USB.
NÊN hỗ trợ tắt tín hiệu dữ liệu qua USB.

7.7.1. Chế độ thiết bị ngoại vi USB

Nếu quá trình triển khai thiết bị có một cổng USB hỗ trợ chế độ thiết bị ngoại vi:

[C-1-1] Cổng PHẢI có thể kết nối với máy chủ USB có tiêu chuẩn cổng USB loại A hoặc loại C.
[C-1-2] PHẢI báo cáo giá trị chính xác của iSerialNumber theo chuẩn USB mã mô tả thiết bị thông qua android.os.Build.SERIAL.
[C-1-3] PHẢI phát hiện bộ sạc 1.5A và 3.0A trên mỗi điện trở Type-C chuẩn và PHẢI phát hiện các thay đổi trong quảng cáo nếu chúng hỗ trợ USB Type-C.
[C-SR-1] Cổng PHẢI sử dụng hệ số hình dạng USB micro-B, micro-AB hoặc Type-C. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những điều này để họ có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-SR-2] Cổng PHẢI nằm ở phần đáy thiết bị (theo hướng tự nhiên) hoặc bật chế độ xoay màn hình của phần mềm cho tất cả ứng dụng (bao gồm cả màn hình chính) để màn hình hiển thị chính xác khi thiết bị được hướng bằng cổng ở dưới cùng. Thiết bị Android mới và hiện có các thiết bị ĐƯỢC NÊN DÙNG để đáp ứng những yêu cầu này để chúng sẽ có thể nâng cấp lên bản phát hành nền tảng trong tương lai.
[C-SR-3] NÊN triển khai hỗ trợ để vẽ 1,5 A hiện tại trong khi HS kêu và lưu lượng truy cập theo quy định trong thông số kỹ thuật về tính năng Sạc pin qua USB, bản sửa đổi 1.2. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những điều này để họ 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] Từ bỏ/không hỗ trợ quyền sở hữu phương pháp sạc làm thay đổi điện áp Vbus vượt quá mức mặc định hoặc làm thay đổi bồn lưu trữ dữ liệu/nguồn như vậy có thể dẫn đến vấn đề về khả năng tương tác với bộ sạc hoặc thiết bị hỗ trợ phương thức Phân phối điện USB tiêu chuẩn. Trong khi điều này được gọi là "ĐƯỢC ĐỀ XUẤT", trong các phiên bản Android trong tương lai, chúng tôi có thể YÊU CẦU tất cả thiết bị loại C để hỗ trợ khả năng tương tác đầy đủ với bộ sạc type-C.
[C-SR-5] Để hỗ trợ tính năng Power Delivery cho dữ liệu và hoán đổi vai trò khi thiết bị hỗ trợ chế độ hỗ trợ USB Type-C và chế độ hỗ trợ USB.
NÊN hỗ trợ Power Delivery để sạc và hỗ trợ điện áp cao cho Các chế độ thay thế, chẳng hạn như hiển thị.
NÊN triển khai API phụ kiện mở Android (AOA) và thông số kỹ thuật như như được nêu trong tài liệu SDK Android.

Trường hợp quá trình triển khai thiết bị có bao gồm cổng USB và triển khai AOA đặc điểm kỹ thuật, chúng:

[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ớ dung lượng USB PHẢI bao gồm chuỗi "android" ở phần kết thúc phần mô tả giao diện iInterface chuỗi của bộ nhớ dung lượng lớn USB

7.7.2. Chế độ hỗ trợ USB

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

[C-1-1] PHẢI triển khai API máy chủ USB của Android như được ghi trong Android SDK và PHẢI khai báo khả năng hỗ trợ tính năng phần cứng android.hardware.usb.host.
[C-1-2] PHẢI triển khai hỗ trợ để kết nối các thiết bị ngoại vi USB tiêu chuẩn, nói cách khác, chúng PHẢI:
- Có cổng loại C trên thiết bị hoặc gửi kèm(các) cáp tương thích với thiết bị cổng độc quyền sang cổng USB loại C tiêu chuẩn (thiết bị USB Type-C).
- Có sẵn loại A trên thiết bị hoặc có kèm theo(các) cáp điều chỉnh thiết bị trên thiết bị cổng độc quyền sang cổng USB loại A tiêu chuẩn.
- Có cổng micro-AB trên thiết bị. Cổng này NÊN vận chuyển cùng với cáp điều chỉnh sang cổng loại A tiêu chuẩn.
[C-1-3] KHÔNG ĐƯỢC gửi kèm bộ chuyển đổi chuyển đổi từ USB loại A hoặc cổng micro-AB sang một cổng loại C (ổ cắm).
[C-SR-1] Are mã ĐỀ XUẤT NÊN triển khai Lớp âm thanh USB như được nêu trong tài liệu SDK Android.
NÊN hỗ trợ sạc thiết bị ngoại vi USB được kết nối khi đang ở máy chủ chế độ; quảng cáo có dòng điện tối thiểu là 1,5A như được chỉ định trong Mục Thông số chấm dứt trong phần Bản sửa đổi 1.2 về thông số kỹ thuật bộ kết nối và cáp USB Type-C cho USB Type-C hoặc sử dụng phạm vi dòng điện đầu ra của Cổng sạc hạ nguồn (CDP) như được chỉ định trong Thông số kỹ thuật của tính năng sạc pin qua USB, bản sửa đổi 1.2 cho trình kết nối Micro-AB.
NÊN triển khai và hỗ trợ các tiêu chuẩn USB Type-C.

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và USB âm thanh, chúng:

[C-2-1] PHẢI hỗ trợ lớp USB HID.
[C-2-2] PHẢI hỗ trợ phát hiện và ánh xạ dữ liệu HID sau đây các trường được chỉ định trong Bảng sử dụng USB HID và Yêu cầu sử dụng lệnh thoại vào KeyEvent như sau:
- Mã nhận dạng sử dụng (0x0CD) của trang sử dụng (0xC): KEYCODE_MEDIA_PLAY_PAUSE
- Mã nhận dạng sử dụng của trang sử dụng (0xC) (0x0E9): KEYCODE_VOLUME_UP
- Mã nhận dạng sử dụng của trang sử dụng (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
- Mã nhận dạng sử dụng (0x0CF) của trang sử dụng (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và Khung truy cập bộ nhớ (SAF), họ:

[C-3-1] PHẢI nhận dạng mọi MTP (Giao thức truyền nội dung nghe nhìn) được kết nối từ xa thiết bị và giúp người dùng có thể truy cập vào nội dung trên đó thông qua ACTION_GET_CONTENT, Ý định ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT. .

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và USB Loại C, chúng:

[C-4-1] PHẢI triển khai chức năng của Cổng vai trò kép do USB xác định Quy cách Type-C (mục 4.5.1.3.3). Dành cho thiết bị kép Cổng vai trò, Trên các thiết bị có giắc cắm âm thanh 3,5 mm, bồn lưu trữ USB phát hiện (chế độ máy chủ) CÓ THỂ bị tắt theo mặc định nhưng PHẢI là để bật tính năng đó.
[C-SR-2] Để hỗ trợ DisplayPort, NÊN hỗ trợ USB Tốc độ dữ liệu SuperSpeed và ĐƯỢC ĐỀ XUẤT ĐỂ hỗ trợ Power Delivery để hoán đổi vai trò dữ liệu và nguồn.
[C-SR-3] Để đề xuất KHÔNG hỗ trợ Chế độ phụ kiện bộ chuyển đổi âm thanh dưới dạng được mô tả trong Phụ lục A của Bản sửa đổi thông số kỹ thuật giắc cắm và cáp USB Type-C 1.2.
NÊN triển khai mô hình try.* phù hợp nhất cho kiểu dáng thiết bị cụ thể. Ví dụ: thiết bị cầm tay NÊN triển khai Mô hình thử nghiệm.SNK.

7,8. Âm thanh

7.8.1. Micrô

Nếu quá trình triển khai thiết bị có micrô, thì họ:

[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] Are Để hỗ trợ tính năng ghi âm gần-ultrasound như được mô tả, trong mục 7.8.3.

Nếu quá trình triển khai thiết bị không có micrô, thì các quá trình triển khai thiết bị sẽ:

[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à không hoạt động, mỗi phần 7.

7.8.2. Đầu ra âm thanh

Trường hợp triển khai thiết bị bao gồm loa hoặc đầu ra âm thanh/đa phương tiện cổng cho thiết bị ngoại vi đầu ra âm thanh như giắc cắm âm thanh 3,5 mm 4 dây dẫn hoặc Cổng chế độ hỗ trợ lưu trữ USB sử dụng lớp âm thanh USB, chúng:

[C-1-1] PHẢI báo cáo hằng số tính năng android.hardware.audio.output.
[C-1-2] PHẢI đáp ứng các yêu cầu về phát âm thanh trong mục 5.5.
[C-1-3] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
[C-SR-1] Để hỗ trợ phát lại gần-ultrasound như được mô tả, trong mục 7.8.3.

Nếu quá trình triển khai thiết bị không bao gồm loa hoặc cổng đầu ra âm thanh, thì các quá trình triển khai đó:

[C-2-1] KHÔNG ĐƯỢC báo cáo tính năng android.hardware.audio.output.
[C-2-2] PHẢI triển khai các API liên quan đến Đầu ra âm thanh ở mức tối thiểu là không hoạt động.

Trong mục này, "cổng đầu ra" là giao diện thực chẳng hạn như giắc cắm âm thanh 3, 5 mm, cổng HDMI hoặc chế độ hỗ trợ USB với lớp âm thanh USB. Hỗ trợ đầu ra âm thanh qua các giao thức dựa trên vô tuyến như Bluetooth, Wi-Fi hoặc mạng di động không đủ điều kiện thêm "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 trong hệ sinh thái Android nếu thiết bị bao gồm một hoặc nhiều cổng âm thanh analog, chúng:

[C-SR-1] AreĐể chỉ định bao gồm ít nhất một trong số các cổng âm thanh là giắc cắm âm thanh 3,5 mm 4 dây dẫn.

Nếu thiết bị có giắc cắm âm thanh 3,5 mm 4 dây dẫn, thì chúng:

[C-1-1] PHẢI hỗ trợ phát âm thanh cho tai nghe âm thanh nổi và tai nghe âm thanh nổi bằng 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à ánh xạ tới các mã phím cho sau 3 phạm vi trở kháng tương đương giữa micrô và mặt đất dây dẫn 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 chèn phích cắm, nhưng chỉ sau khi tất cả những người liên hệ trên nguồn điện chạm vào các phân đoạn có liên quan của họ trên giắc cắm.
[C-1-5] PHẢI có khả năng điều khiển ít nhất 150mV ± 10% điện áp đầu ra bật một trở kháng 32 ohm của loa.
[C-1-6] PHẢI có điện áp thiên vị micrô trong khoảng 1,8V ~ 2,9V.
[C-1-7] PHẢI phát hiện và ánh xạ tới mã phím cho phạm vi trở kháng tương đương giữa micrô và dây dẫn mặt đất trên giắc cắm âm thanh:
- 110 – 180 ohm: KEYCODE_VOICE_ASSIST
[C-SR-2] AreĐể hỗ trợ các phích cắm âm thanh với OMTP lệnh pin đầu ra.
[C-SR-3] Are trì hoãn việc hỗ trợ ghi âm từ hệ thống âm thanh nổi có micrô.

Nếu thiết bị có giắc cắm âm thanh 3,5 mm 4 dây dẫn và hỗ trợ micrô và truyền android.intent.action.HEADSET_PLUG bằng micrô có giá trị bổ sung được đặt thành 1, họ:

[C-2-1] PHẢI hỗ trợ phát hiện micrô trên âm thanh cắm vào phụ kiện.

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 dành riêng cho thiết bị.

7.8.3. Siêu âm gần

Âm thanh siêu âm gần là băng tần 18,5 kHz đến 20 kHz.

Triển khai thiết bị:

PHẢI báo cáo chính xác sự hỗ trợ của chức năng âm thanh gần siêu âm thông qua AudioManager.getProperty API như sau:

Nếu PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND là "true", thì các yêu cầu sau PHẢI được đáp ứng bởi Nguồn âm thanh VOICE_RECOGNITION và UNPROCESSED:

[C-1-1] Phản hồi công suất trung bình của micrô ở băng tần 18,5 kHz đến 20 kHz Không được nhỏ hơn 15 dB so với đáp ứng tại 2 kHz.
[C-1-2] Tỷ lệ tín hiệu không có trọng số so với tiếng ồn của micrô trên 18,5 kHz đến 20 kHz cho âm 19 kHz ở -26 dBFS PHẢI không được 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 18,5 kHz - 20 kHz KHÔNG được thấp hơn 40 dB dưới phản hồi tại 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 đường dẫn tín hiệu âm thanh không bị lỗi cho cả đầu vào và luồng đầu ra trên thiết bị cầm tay, như được xác định bằng không có sự cố nào được đo lường trong quá trình thử nghiệm một phút cho mỗi đường dẫn. Kiểm thử bằng OboeTester "Kiểm tra sự cố tự động".

Kiểm thử yêu cầu một thiết bị phần cứng vòng lặp âm thanh, được sử dụng trực tiếp trong giắc cắm 3,5 mm và/hoặc kết hợp với bộ chuyển đổi USB-C sang 3,5 mm. Tất cả các cổng đầu ra âm thanh đều PHẢI được kiểm tra.

OboeTester hiện hỗ trợ đường dẫn AAudio, vì vậy các tổ hợp sau PHẢI được kiểm tra xem có sự cố hay không bằng AAudio:

Chế độ hoàn thành	Chia sẻ	Tốc độ lấy mẫu tín hiệu ra	Tiếng Chans	Âm thanh ngoài
THẤP_THẤP	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	1	2
THẤP_THẤP	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	2	1
THẤP_THẤP	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	1	2
THẤP_THẤP	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	2	1

Một luồng đáng tin cậy PHẢI đáp ứng các tiêu chí sau đây về Tín hiệu gây nhiễu Tỷ lệ (SNR) và méo hài tổng (THD) cho 2000 Hz sin.

Bộ chuyển đổi	THD	SNR
loa chính, tích hợp, được đo bằng micrô tham chiếu bên ngoài	< 3%	>= 50 dB
micrô chính, tích hợp sẵn, đượ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, kiểm tra bằng bộ chuyển đổi loopback	Chưa đến 1%	>= 60 dB
Bộ sạc USB đi kèm với điện thoại, được kiểm tra bằng bộ chuyển đổi loopback	< 1%	>= 60 dB

7,9. Thực tế ảo

Android bao gồm các API và cơ sở vật chất để xây dựng "Thực tế ảo" (thực tế ảo) bao gồm trải nghiệm thực tế ảo chất lượng cao trên thiết bị di động. Thiết bị triển khai PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

7.9.1. Chế độ thực tế ảo

Android có hỗ trợ cho Chế độ thực tế ảo, một tính năng xử lý kết xuất hình nổi của các thông báo và tắt thành phần giao diện người dùng hệ thống một mắt trong khi ứng dụng VR được tập trung vào người dùng.

7.9.2. Chế độ thực tế ảo – Hiệu suất cao

Nếu quá trình triển khai thiết bị hỗ trợ chế độ thực tế ảo, thì các thiết bị đó:

[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 bền vững.
[C-1-4] PHẢI hỗ trợ OpenGL ES 3.2.
[C-1-5] PHẢI hỗ trợ android.hardware.vulkan.level 0.
PHẢI hỗ trợ android.hardware.vulkan.level 1 trở lên.
[C-1-6] PHẢI triển khai EGL_KHR_mutable_render_buffer! EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync thân mến! EGL_IMG_context_priority thân mến! EGL_EXT_protected_content thân mến! EGL_EXT_image_gl_colorspace thân mến! và hiển thị các tiện ích trong danh sách các tiện ích EGL hiện có.
[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 các tiện ích GL hiện có.
[C-SR-1] Are Internet ĐỀ XUẤT 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 các tiện ích GL hiện có.
[C-SR-2] AreĐể hỗ trợ Vulkan 1.1.
[C-SR-3] Are mã ĐỀ XUẤ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ị tiện ích đó trong danh sách tiện ích Vulkan hiện có.
[C-SR-4] Are trì hoãn đề xuất hiển thị ít nhất một nhóm hàng đợi Vulkan trong đó flags chứa cả VK_QUEUE_GRAPHICS_BIT và VK_QUEUE_COMPUTE_BIT, và queueCount ít nhất là 2.
[C-1-7] GPU và màn hình PHẢI có thể đồng bộ hoá quyền truy cập vào bộ đệm trước sao cho kết xuất mắt xen kẽ nội dung thực tế ảo ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất sẽ được hiển thị mà không có cấu phần phần mềm xé hình nào đó.
[C-1-9] PHẢI triển khai tính năng hỗ trợ cho AHardwareBuffer cờ AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA và AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT như mô tả trong NDK.
[C-1-10] PHẢI triển khai tính năng hỗ trợ cho các AHardwareBuffer bằng 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] Are trì hoãn 1 để hỗ trợ việc phân bổ các AHardwareBuffer có nhiều hơn một lớp và cờ và định dạng được chỉ định trong C-1-10.
[C-1-11] PHẢI hỗ trợ H.264 giải mã ít nhất 3840 x 2160 ở tốc độ 30 khung hình/giây, được nén xuống trung bình 40Mbps (tương đương 4 phiên bản 1920 x1080 ở tốc độ 30 khung hình/giây-10 Mb/giây hoặc 2 phiên bản 1920 x 1080 ở tốc độ 60 khung hình/giây-20 Mb/giây).
[C-1-12] PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã ít nhất 1920 x 1080 ở tốc độ 30 khung hình/giây được nén xuống trung bình 10 Mb/giây và PHẢI là có khả năng giải mã 3840 x 2160 ở 30 fps-20 Mbps (tương đương với 4 phiên bản 1920 x 1080 ở tốc độ 30 fps-5 Mbps).
[C-1-13] PHẢI hỗ trợ HardwarePropertiesManager.getDeviceTemperatures API và trả về giá trị chính xác về nhiệt độ trên da.
[C-1-14] PHẢI có màn hình được nhúng và độ phân giải của màn hình PHẢI tối thiểu 1920 x 1080.
[C-SR-6] AreĐể chỉ định độ phân giải màn hình tối thiểu là 2560 x 1440.
[C-1-15] Màn hình PHẢI cập nhật ít nhất 60 Hz khi ở Chế độ thực tế ảo.
[C-1-17] Màn hình PHẢI hỗ trợ chế độ bền bỉ thấp với ≤ 5 mili giây bền vững, sự bền vững được định nghĩa là khoảng thời gian để một pixel phát ra ánh sáng.
[C-1-18] PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data dài Extension mục 7.4.3.
[C-1-19] PHẢI hỗ trợ và báo cáo đúng cách Loại kênh trực tiếp cho tất cả các loại cảm biến mặc định sau đây:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] Are mã ĐỀ XUẤT NÊN hỗ trợ TYPE_HARDWARE_BUFFER loại kênh trực tiếp cho tất cả các Loại kênh trực tiếp nêu trên.
[C-1-21] PHẢI đáp ứng các thông tin liên quan đến con quay hồi chuyển, gia tốc kế và từ kế các yêu cầu đối với android.hardware.hifi_sensors, như được nêu trong mục 7.3.9.
[C-SR-8] AreĐể hỗ trợ các Tính năng android.hardware.sensor.hifi_sensors.
[C-1-22] PHẢI có chuyển động hai đầu đến độ trễ photon không cao hơn 28 mili giây.
[C-SR-9] Are Để chỉ định chuyển động từ đầu đến cuối đến độ trễ photon không quá 20 mili giây.
[C-1-23] PHẢI có tỷ lệ khung hình đầu tiên, là tỷ lệ giữa độ sáng của các pixel trên khung hình đầu tiên sau khi chuyển từ màu đen sang trắng và độ sáng của các điểm ảnh màu trắng ở trạng thái ổn định, ít nhất là 85%.
[C-SR-10] CÓ THỰC HIỆN ĐỀ XUẤT để có tỷ lệ khung hình đầu tiên tối thiểu là 90%.
CÓ THỂ cung cấp một lõi độc quyền cho nền trước ứng dụng và CÓ THỂ hỗ trợ API Process.getExclusiveCores để trả về số lượng lõi CPU chỉ dành cho 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 cho phép bất kỳ quy trình không gian người dùng nào khác chạy trên 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ố nhân hệ điều hành để chạy khi cần thiết.

7,10. Xúc giác

Thiết bị dùng để cầm hoặc đeo có thể có chức năng xúc giác cho mục đích chung bộ truyền động, có sẵn cho các ứng dụng cho các mục đích bao gồm 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 chạm chung.

Nếu quá trình triển khai thiết bị KHÔNG bao gồm bộ truyền động xúc giác có mục đích chung như vậy, chúng:

[7.10/C] PHẢI trả về giá trị false cho Vibrator.hasVibrator().

Nếu quá trình triển khai thiết bị DO bao gồm ít nhất một xúc giác cho mục đích chung như vậy bộ truyền động, chúng:

[C-1-1] PHẢI trả về true cho Vibrator.hasVibrator().
KHÔNG NÊN sử dụng bộ truyền động xúc giác (bộ rung) có khối lượng xoay lệch tâm (ERM).
NÊN triển khai tất cả hằng số công khai cho 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ả 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ả hằng số PRIMITIVE_* công khai khả thi cho xúc giác phong phú trong android.os.VibrationEffect.Composition cụ thể là (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Một số thuộc tính nguyên gốc này, chẳng hạn như LOW_TICK và SPIN chỉ có thể khả thi nếu bộ rung có thể hỗ trợ tương đối thấp tần số.
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 android.os.VibrationEffect được đề xuất hằng số, với các mối quan hệ biên độ tương ứng.
NÊN sử dụng các ánh xạ hằng số xúc giác được liên kết này.
NÊN thực hiện đánh giá chất lượng trong createOneShot() và createWaveform() API.
NÊN xác minh rằng kết quả của android.os.Vibrator.hasAmplitudeControl() công khai API phản ánh chính xác khả năng của bộ rung.
NÊN xác minh khả năng mở rộng biên độ bằng cách chạy android.os.Vibrator.hasAmplitudeControl().

Nếu các quá trình triển khai thiết bị tuân theo ánh xạ hằng số xúc giác, chúng sẽ:

NÊN xác minh trạng thái triển khai bằng cách chạy android.os.Vibrator.areAllEffectsSupported() và android.os.Vibrator.arePrimitivesSupported() API.
NÊN thực hiện đánh giá chất lượng cho 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 dữ liệu gốc không được hỗ trợ theo mô tả trong hướng dẫn triển khai cho hằng số.
NÊN cung cấp tính năng hỗ trợ dự phòng để giảm thiểu nguy cơ không thực hiện được như mô tả tại đây.

7,11. Lớp hiệu suất nội dung đa phương tiện

Lớp hiệu suất nội dung đa phương tiện của việc triển khai thiết bị có thể được lấy từ API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Yêu cầu cho lớp hiệu suất nội dung đa phương tiện được xác định cho từng phiên bản Android bắt đầu bằng R (phiên bản 30). Giá trị đặc biệt bằng 0 chỉ định rằng thiết bị không phải là một lớp hiệu suất nội dung đa phương tiện.

Nếu quá trình triển khai thiết bị trả về giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, họ:

[C-1-1] PHẢI trả về ít nhất một giá trị của android.os.Build.VERSION_CODES.R.
[C-1-2] PHẢI là cách triển khai thiết bị cầm tay.
[C-1-3] PHẢI đáp ứng tất cả các yêu cầu đối với "Media Performance Class" (Lớp hiệu suất nội dung đa phương tiện) đã mô tả trong phần 2.2.7.

Nói cách khác, lớp hiệu suất nội dung đa phương tiện trong Android T chỉ được xác định cho thiết bị cầm tay phiên bản T, S hoặc R.

Xem phần 2.2.7 để biết thiết bị cụ thể các yêu cầu liên quan.

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

Một số tiêu chí về hiệu suất và sức mạnh tối thiểu rất quan trọng đối với trải nghiệm người dùng và tác động đến các giả định cơ sở mà nhà phát triển sẽ đặt ra khi phát triển .

8.1. Tính nhất quán trong trải nghiệm người dùng

Một giao diện người dùng mượt mà có thể được cung cấp cho người dùng cuối nếu có các yêu cầu tối thiểu để đảm bảo tốc độ khung hình và thời gian phản hồi nhất quán cho ứng dụng và trò chơi. Triển khai thiết bị, tuỳ thuộc vào loại thiết bị, CÓ THỂ có các yêu cầu đo lường được về tác vụ và độ trễ giao diện người dùng chuyển đổi như mô tả trong phần 2.

8.2. Hiệu suất truy cập tệp I/O

Cung cấp đường cơ sở chung để đạt hiệu suất truy cập nhất quán vào tệp trên lưu trữ dữ liệu riêng tư của ứng dụng (phân vùng /data) cho phép các nhà phát triển ứng dụng đặt ra kỳ vọng đúng mức để hỗ trợ thiết kế phần mềm của họ. Thiết bị Tuỳ thuộc vào loại thiết bị, CÓ THỂ có một số yêu cầu nhất định được mô tả trong phần 2 để đọc các nội dung sau đây và ghi:

Hiệu suất ghi tuần tự. Được đo bằng cách ghi một tệp 256 MB sử dụng Bộ đệm ghi 10 MB.
Hiệu suất ghi ngẫu nhiên. Được đo bằng cách viết một tệp 256MB sử dụng 4KB vùng đệm ghi.
Hiệu suất đọc tuần tự. Được đo bằng cách đọc tệp 256 MB bằng Bộ đệm ghi 10 MB.
Hiệu suất đọc ngẫu nhiên. Được đo bằng cách đọc tệp 256 MB sử dụng 4KB vùng đệm ghi.

8.3. Chế độ tiết kiệm điện

Liệu quá trình triển khai thiết bị có bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị hay không được đưa vào AOSP (ví dụ: Bộ chứa chế độ chờ ứng dụng, Nghỉ) hoặc mở rộng các tính năng để áp dụng các hạn chế nghiêm ngặt hơn Nhóm chế độ chờ ứng dụng BỊ HẠN CHẾ, chúng:

[C-1-1] KHÔNG ĐƯỢC lệch với phương thức triển khai AOSP (Dự án nguồn mở Android) để kích hoạt, bảo trì, thuật toán đánh thức và việc sử dụng cài đặt hệ thống chung hoặc Cấu hình thiết bị chế độ tiết kiệm điện năng ở chế độ Chờ ứng dụng và Nghỉ.
[C-1-2] KHÔNG ĐƯỢC lệch khỏi phương thức triển khai AOSP để sử dụng toàn cục hoặc DeviceConfig để quản lý việc điều tiết công việc, chuông báo và mạng cho các ứng dụng trong mỗi bộ chứa cho Chế độ chờ ứng dụng.
[C-1-3] KHÔNG ĐƯỢC di chuyển khỏi phương thức triển khai AOSP cho 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 Bộ chứa chế độ chờ ứng dụng và 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ị đang bật chế độ tiết kiệm điện.
[C-1-6] PHẢI cung cấp thuộc tính tương tác của người dùng để hiển thị tất cả các ứng dụng được miễn trừ từ các chế độ tiết kiệm pin ở Chế độ chờ ứng dụng và Nghỉ hoặc bất kỳ hoạt động tối ưu hoá pin nào và PHẢI triển khai ACTION_REQUEST_húc tắt_BATTERY_OPTIMIZATIONS ý định yêu cầu người dùng cho phép một ứng dụng bỏ qua pin tối ưu hoá.
[C-SR-1] Giới hạn định dạng đề nghị cung cấp thuộc tính tương tác của người dùng để bật và tắt tính năng trình tiết kiệm pin.
[C-SR-2] Giới hạn định dạng giới thiệu để cung cấp thuộc tính tương tác của người dùng để hiển thị tất cả là các ứng dụng được miễn các chế độ tiết kiệm pin và Chế độ chờ ứng dụng.

Nếu quá trình triển khai thiết bị mở rộng các tính năng quản lý nguồn điện có sẵn trong AOSP và tiện ích đó áp dụng các hạn chế nghiêm ngặt hơn so với nhóm chế độ chờ ứng dụng hiếm tham khảo mục 3.5.1.

Ngoài các chế độ tiết kiệm điện, các hoạt động triển khai thiết bị Android CÓ THỂ triển khai bất kỳ hoặc cả 4 trạng thái nguồn ngủ như được xác định trong Giao diện cấu hình và nguồn (ACPI).

Nếu việc triển khai thiết bị triển khai trạng thái nguồn S4 như được xác định bởi ACPI, họ:

[C-1-1] PHẢI nhập trạng thái này chỉ sau khi người dùng đã thực hiện hành động rõ ràng để đặt thiết bị ở trạng thái không hoạt động (ví dụ: bằng cách đóng nắp thực tế một phần của thiết bị hoặc tắt xe hay TV) và trước khi người dùng kích hoạt lại thiết bị (ví dụ: bằng cách mở nắp hoặc xoay xe hoặc TV bật lại).

Nếu việc triển khai thiết bị triển khai trạng thái năng lượng S3 như được xác định bởi ACPI, họ:

[C-2-1] PHẢI đáp ứng C-1-1 ở trên, hoặc PHẢI nhập trạng thái S3 chỉ khi bên thứ ba các ứng dụng không cần tài nguyên hệ thống (ví dụ: màn hình, CPU).

Ngược lại, PHẢI thoát khỏi trạng thái S3 khi các ứng dụng của bên thứ ba cần tài nguyên hệ thống, như được 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 tiếp tục chạy CPU PARTIAL_WAKE_LOCK, thiết bị KHÔNG ĐƯỢC chuyển sang trạng thái S3 trừ phi theo mô tả trong C-1-1, người dùng đã thực hiện hành động rõ ràng để đặt thiết bị trong trạng thái không hoạt động. Ngược lại, tại thời điểm khi một tác vụ mà các ứng dụng bên thứ ba triển khai thông qua JobScheduler được kích hoạt hoặc Giải pháp gửi thông báo qua đám mây của Firebase được phân phối tới các ứng dụng của bên thứ ba, thiết bị PHẢI thoát khỏi trạng thái S3 trừ khi người dùng đặt thiết bị ở trạng thái không hoạt động. Đây chưa phải là danh sách đầy đủ các ví dụ và AOSP triển khai các tín hiệu đánh thức mở rộng kích hoạt đánh thức khỏi trạng thái này.

8.4. Kế toán tiêu thụ điện năng

Việc tính toán và báo cáo mức tiêu thụ điện năng chính xác hơn cung cấp cho nhà phát triển ứng dụng cả về chương trình khuyến khích lẫn công cụ để tối ưu hoá mức sử dụng điện năng mẫu của ứng dụng.

Triển khai thiết bị:

[C-SR-1] Để cung cấp hồ sơ nguồn điện cho mỗi thành phần, nhà xuất bản này có thể: 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 ước lượng do theo thời gian như được ghi trong trang web Dự án nguồn mở Android.
[C-SR-2] Nói Mạnh để báo cáo tất cả các giá trị tiêu thụ điện năng tính bằng milliampere giờ (mAh).
[C-SR-3] "{ĐỀ XUẤT" để báo cáo mức tiêu thụ điện năng của CPU trên 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 Triển khai mô-đun nhân uid_cputime.
[C-SR-4] Liên minh Dẫn hướng để cung cấp mức sử dụng năng lượng này thông qua adb shell dumpsys batterystats shell cho nhà phát triển ứng dụng.
PHẢI được gán cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng năng lượng của thành phần phần cứng cho một ứng dụng.

8,5. Hiệu suất nhất quán

Hiệu suất có thể biến động đáng kể đối với các ứng dụng chạy trong thời gian dài có hiệu suất cao, do các ứng dụng khác đang chạy trong nền hoặc do tình trạng điều tiết CPU do 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 đó thì ứng dụng trên nền trước trên cùng có thể yêu cầu tối ưu hoá việc phân bổ nguồn lực để 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ợ của Chế độ hiệu suất bền vững thông qua PowerManager.isSustainedPerformanceModeSupported() API.
NÊN hỗ trợ Chế độ hiệu suất bền vững.

Nếu quá trình triển khai thiết bị báo cáo khả năng hỗ trợ Chế độ hiệu suất bền vững, thì họ:

[C-1-1] PHẢI cung cấp cho ứng dụng trên nền trước một mức độ nhất quán trong ít nhất 30 phút khi ứng dụng yêu cầu.
[C-1-2] PHẢI thực hiện Window.setSustainedPerformanceMode() API và các API liên quan khác.

Nếu quá trình triển khai thiết bị bao gồm 2 lõi CPU trở lên, thì các lõi CPU đó:

NÊN cung cấp ít nhất một lõi độc quyền mà cấp cao nhất có thể dành riêng của ứng dụng trên nền trước.

Nếu quá trình triển khai thiết bị hỗ trợ dành riêng một lõi độc quyền cho cấp trên của ứng dụng trên nền trước, chúng:

[C-2-1] PHẢI báo cáo thông qua Process.getExclusiveCores() Phương pháp API đối với số nhận dạng của các lõi độc quyền có thể đặt trước theo ứng dụng trên nền trước.
[C-2-2] PHẢI không cho phép bất kỳ quy trình không gian người dùng nào ngoại trừ trình điều khiển thiết bị được ứng dụng dùng để chạy trên các lõi độc quyền, nhưng CÓ THỂ cho phép một số để các quy trình nhân hệ điều hành chạy khi cần thiết.

Nếu quá trình triển khai thiết bị không hỗ trợ lõi độc quyền, thì các quá trình triển khai trên thiết bị sẽ:

[C-3-1] PHẢI trả về một danh sách trống thông qua hàm Process.getExclusiveCores() API.

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ô hình bảo mật nhất quán với mô hình bảo mật 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 truy cập trong API ở tài liệu dành cho nhà phát triển Android.
[C-0-2] PHẢI hỗ trợ cài đặt của tự ký ứng dụng của bạn mà không yêu cầu bất kỳ quyền/chứng chỉ bổ sung nào từ bất kỳ các bên thứ ba/cơ quan hữu quan.

Nếu các quá trình triển khai thiết bị khai báo android.hardware.security.model.compatible tính năng, chúng:

[C-1-1] PHẢI hỗ trợ các yêu cầu được liệt kê trong các tiểu mục sau.

9.1. Quyền

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ mô hình quản lý quyền của Android và Mô hình vai trò của 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 về SDK; quyền và không thể bỏ qua, thay đổi vai trò, hoặc bị bỏ qua.
CÓ THỂ thêm các quyền khác, 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 với protectionLevel của PROTECTION_FLAG_PRIVILEGED Chỉ được cấp cho các ứng dụng được cài đặt trước trong(các) đường dẫn đặc quyền của hình ảnh hệ thống (cũng như tệp APEX) và được trong tập hợp con các quyền rõ ràng được thêm vào danh sách cho phép cho mỗi ứ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ủ quyền truy cập vào danh sách cho phép đối với từng ứng dụng bằng các tệp trong etc/permissions/ và sử dụng đường dẫn system/priv-app làm đường dẫn đặc quyền.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-SR-1] Quyền với protectionLevel của PROTECTION_SIGNATURE ĐƯỢC ĐỀ XUẤT NÊN chỉ cấp cho:
- Các ứng dụng đã được cài đặt trước trên hình ảnh hệ thống (cũng như Tệp APEX).
- Những ứng dụng có các quyền được cho phép trong danh sách cho phép (nếu những ứng dụng đó không nằm trong danh sách này) hình ảnh hệ thống.
Lưu ý: Yêu cầu này sẽ trở thành PHẢI trong bản phát hành Quý 2 năm 2025. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách đọc và tuân thủ quyền truy cập vào danh sách cho phép đối với từng ứng dụng bằng các tệp trong Đường dẫn etc/permissions/.

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

Quyền có mức độ bảo vệ nguy hiểm là quyền khi bắt đầu chạy. Ứng dụng có targetSdkVersion > 22 và yêu cầu mã trong thời gian chạy.

Triển khai thiết bị:

[C-0-3] PHẢI hiển thị giao diện chuyên dụng để 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ý quyền khi bắt đầu chạy.
[C-0-5] KHÔNG ĐƯỢC cấp bất kỳ quyền khi bắt đầu chạy nào cho các ứng dụng trừ phi:
- Các thiết bị này được cài đặt tại thời điểm vận chuyển thiết bị VÀ
- Có thể có được sự đồng ý của người dùng trước khi đăng ký sẽ sử dụng quyền này,
  
  HOẶC
- Đã cấp các quyền khi bắt đầu chạy theo chính sách cấp quyền mặc định hoặc để nắm giữ vai trò trên nền tảng.
[C-0-6] PHẢI cấp quyền android.permission.RECOVER_KEYSTORE chỉ dành cho những ứng dụng hệ thống đã đăng ký Tác nhân khôi phục được bảo mật đúng cách. Đáp Tác nhân khôi phục được bảo mật đúng cách được định nghĩa là tác nhân phần mềm trên thiết bị đồng bộ hoá với bộ nhớ từ xa bên ngoài thiết bị, được trang bị phần cứng bảo mật với khả năng bảo vệ tương đương hoặc mạnh hơn mức độ bảo vệ được mô tả trong Dịch vụ Google Cloud Key Vault để ngăn chặn các cuộc tấn công brute force đố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 hoạt động thể chất thông qua API Android tiêu chuẩn hoặc cơ chế độc quyền. 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ể dùng để xác định hoặc ước tính vị trí (ví dụ: SSID, BSSID, Cell ID hoặc vị trí của mạng mà thiết bị được kết nối với).
- Hoạt động thể chất của người dùng hoặc cách phân loại hoạt động thể chất.

Cụ thể hơn là 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 hoạt động thể chất.
[C-0-9] PHẢI cấp quyền khi bắt đầu chạy cho ứng dụng chứa như được mô tả trên SDK. Ví dụ: TelephonyManager#getServiceState yêu cầu android.permission.ACCESS_FINE_LOCATION).

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í của Android ở trên là đối với ứng dụng không truy cập vào 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 định cấu hình và thiết lập thiết bị, trong trường hợp ứng dụng hệ thống giữ Quyền NETWORK_SETTINGS hoặc NETWORK_SETUP_WIZARD.

Các quyền có thể được đánh dấu là bị hạn chế làm thay đổi hành vi của các quyền đó.

[C-0-10] Các quyền được đánh dấu bằng cờ hardRestricted KHÔNG ĐƯỢC được cấp cho ứng dụng trừ phi:
- Tệp APK ứng dụng nằm trong phân vùng hệ thống.
- Người dùng chỉ định vai trò liên kết với hardRestricted vào một ứng dụng.
- Trình cài đặt này sẽ cấp hardRestricted cho một ứng dụng.
- Một ứng dụng được cấp hardRestricted trên phiên bản Android cũ.
[C-0-11] Ứng dụng có quyền softRestricted PHẢI chỉ nhận được giới hạn và KHÔNG được có quyền truy cập đầy đủ cho đến khi được cho phép theo mô tả trong SDK, trong đó quyền truy cập đầy đủ và giới hạn được xác định cho mỗi softRestricted quyền (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 setPermissionPolicy và setPermission GrantsState API.
[C-0-13] PHẢI sử dụng AppOpsManager API để ghi lại và theo dõi từng và mọi hoạt động truy cập có lập trình vào dữ liệu được bảo vệ bởi các quyền nguy hiểm từ Hoạt động và dịch vụ trên Android.
[C-0-14] Chỉ được gán vai trò cho các ứng dụng có chức năng đáp ứng các yêu cầu về vai trò.
[C-0-15] KHÔNG ĐƯỢC xác định vai trò trùng lặp hoặc chức năng tập mẹ vai trò do nền tảng xác định.

Nếu thiết bị báo cáo android.software.managed_users, thì các thiết bị đó sẽ:

[C-1-1] KHÔNG ĐƯỢC có các quyền sau đây do quản trị viên:
- Vị trí (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Máy ảnh (CAMERA)
- Micrô (RECORD_AUDIO)
- Cảm biến cơ thể (BODY_SENSORS)
- Hoạt động thể chất (ACTIVITY_RECOGNITION)

Nếu quá trình triển khai thiết bị cung cấp một thuộc tính tương tác cho người dùng để chọn những ứng dụng có thể vẽ lên các ứng dụng khác bằng một hoạt động xử lý ACTION_MANAGE_OVERLAY_PERMISSION ý định của bạn, họ:

[C-2-1] PHẢI đảm bảo rằng tất cả các hoạt động có bộ lọc ý định cho ACTION_MANAGE_OVERLAY_PERMISSION ý định có cùng màn hình giao diện người dùng, bất kể ứng dụng khởi tạo hay bất kỳ thông tin mà nó cung cấp.

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

[C-3-1] PHẢI hiển thị tuyên bố từ chối trách nhiệm trong quá trình thiết lập thiết bị được quản lý hoàn toàn (thiết lập của chủ sở hữu thiết bị) cho biết rằng quản trị viên CNTT sẽ có thể cho phép các ứng dụng kiểm soát cài đặt trên điện thoại, bao gồm micrô, máy ảnh và cùng các tuỳ 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Ừ quản trị viên đã chọn không kiểm soát các quyền trên thiết bị.

Nếu quá trình triển khai thiết bị cài đặt trước bất kỳ gói nào có vai trò 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:

[C-4-1] PHẢI đáp ứng tất cả các yêu cầu được nêu đối với việc triển khai thiết bị trong các phần "9.8.6 cấp hệ điều hành và dữ liệu môi trường xung quanh và 9.8.15 Triển khai API Hộp cát".

Nếu quá trình triển khai thiết bị bao gồm một ứng dụng mặc định để hỗ trợ VoiceInteractionService họ:

[C-5-1] KHÔNG ĐƯỢC cấp ACCESS_FINE_LOCATION làm chế độ mặc định cho yêu cầu đó .

9.2. UID và tách biệt quy trình

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ ứng dụng Android mô hình hộp cát, trong đó mỗi ứng dụng chạy dưới dạng một UID Unixstyle duy nhất và trong một quy trình riêng.
[C-0-2] PHẢI hỗ trợ chạy nhiều ứng dụng giống với ID người dùng Linux, miễn là các ứng dụng được ký hợp lệ và được tạo, như được xác định trong Tài liệu tham khảo về Bảo mật và quyền truy cập.

9.3. Quyền đối với hệ thống tệp

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ quyền truy cập vào tệp của Android mô hình quản lý quyền như đã xác định trong Tài liệu tham khảo về Bảo mật và quyền truy cập.

9.4. Môi trường thực thi thay thế

Quá trình triển khai thiết bị PHẢI duy trì tính nhất quán của tính bảo mật của Android và mô hình quyền, ngay cả khi chúng bao gồm môi trường thời gian chạy thực thi bằng cách sử dụng một số phần mềm hoặc công nghệ khác ngoài Dalvik thực thi Định dạng hoặc mã gốc. Hay nói cách khác:

[C-0-1] Môi trường thời gian chạy thay thế PHẢI là các ứng dụng Android, và tuân thủ mô hình bảo mật tiêu chuẩn của Android (như mô tả ở nơi khác) trong phần 9.
[C-0-2] 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 AndroidManifest.xml của thời gian chạy qua tệp <uses-permission> cơ chế.
[C-0-3] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cho phép các ứng dụng dùng các tính năng được bảo vệ bằng các quyền của Android chỉ dành cho các ứng dụng hệ thống.
[C-0-4] 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 thời gian chạy thay thế KHÔNG ĐƯỢC sử dụng lại hộp cát của bất kỳ ứng dụng nào khác được cài đặt trên thiết bị, ngoại trừ thông qua các cơ chế Android tiêu chuẩn về mã nhận dạng người dùng chung và chứng chỉ ký.
[C-0-5] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC chạy cùng, cấp hoặc được cấp quyền truy cập vào hộp cát tương ứng với các ứng dụng Android khác.
[C-0-6] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC chạy cùng, đượ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 người dùng cấp cao (gốc) hoặc của bất kỳ mã nhận dạng người dùng.
[C-0-7] Khi các tệp .apk của thời gian chạy thay thế được đưa vào trong hình ảnh hệ thống về các quá trình triển khai thiết bị, PHẢI được ký bằng một khoá riêng biệt từ khoá dùng để ký các ứng dụng khác đi kèm với thiết bị thực tế.
[C-0-8] Khi cài đặt ứng dụng, thời gian chạy thay thế PHẢI thu được sự đồng ý của người dùng đối với các quyền của Android mà ứng dụng sử dụng.
[C-0-9] Khi một ứng dụng cần sử dụng tài nguyên thiết bị cho có quyền tương ứng trên Android (chẳng hạn như Máy ảnh, GPS, v.v.), môi trường thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng 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 ứng dụng khả nă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 do môi trường thời gian chạy lưu giữ khi cài đặt bất kỳ ứng dụng nào bằng thời gian chạy đó.
Môi trường thời gian chạy thay thế PHẢI cài đặt các ứng dụng qua PackageManager vào hộp cát Android riêng biệt (mã nhận dạng người dùng Linux, v.v.).
Môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android duy nhất mà tất cả mọi người dùng chung bằ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 đồng thời hỗ trợ tách biệt người dùng hoàn toàn cũng như sao chép hồ sơ người dùng bằng tách biệt một phần(ví dụ: loại hồ sơ người dùng bổ sung duy nhất android.os.usertype.profile.CLONE).

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 quá trình triển khai thiết bị có hỗ trợ nhiều người dùng, thì họ:

[C-1-2] PHẢI, đối với mỗi người dùng, triển khai một bảo mật nhất quán với mô hình bảo mật 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 truy cập trong các API.
[C-1-3] PHẢI có bộ nhớ ứng dụng dùng chung riêng biệt và tách biệt (còn gọi là /sdcard) cho mỗi phiên bản người dùng.
[C-1-4] PHẢI đảm bảo rằng các ứng dụng thuộc quyền sở hữu và đang chạy thay mặt người dùng cụ thể 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 hệ thống tệp hoặc ổ đĩa.
[C-1-5] PHẢI mã hoá nội dung của thẻ SD khi chế độ nhiều người dùng được bật sử dụng khoá chỉ được lưu trữ trên phương tiện không thể tháo rời mà hệ thống chỉ truy cập được nếu quá trình triển khai thiết bị sử dụng phương tiện di động cho các API bộ nhớ ngoài. Vì việc này sẽ khiến máy tính lưu trữ không đọc được nội dung nghe nhìn, nên việc triển khai thiết bị sẽ được yêu cầu chuyển sang MTP hoặc một hệ thống tương tự để cung cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại.

Nếu quá trình triển khai thiết bị bao gồm tính năng hỗ trợ cho 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 phiên bản kép của cùng một ứng dụng, chúng:

[C-2-1] PHẢI có bộ nhớ ứng dụng dùng chung riêng biệt và tách biệt (còn gọi là /sdcard) cho mỗi phiên bản người dùng.
[C-2-2] PHẢI đảm bảo rằng các ứng dụng thuộc quyền sở hữu và đang chạy trên thay mặt cho một người dùng cụ thể không thể liệt kê, đọc hoặc ghi vào các tệp được sở hữu bởi 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 âm lượng hoặc hệ thống tệp.

Quá trình triển khai thiết bị CÓ THỂ tạo thêm một loại hồ sơ người dùng android.os.usertype.profile.CLONE so với người dùng chính (và chỉ đấu với người dùng chính 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. Các thực thể kép này dùng chung bộ nhớ tách biệt một phần, được hiển thị trong người dùng cuối trong trình chạy cùng lúc và xuất hiện trong cùng chế độ xem gần đây. Ví dụ: mã này có thể được sử dụng để hỗ trợ người dùng cài đặt hai các phiên bản của một ứng dụng trên thiết bị hai SIM.

Nếu việc triển khai thiết bị tạo hồ sơ người dùng bổ sung được thảo luận ở trên, thì họ:

[C-3-1] PHẢI chỉ cung cấp quyền truy cập vào bộ nhớ hoặc dữ liệu đã được có thể truy cập vào hồ sơ người dùng chính hoặc thuộc quyền sở hữu trực tiếp của hồ sơ người dùng bổ sung.
[C-3-2] KHÔNG ĐƯỢC coi đây là hồ sơ công việc.
[C-3-3] PHẢI có thư mục dữ liệu ứng dụng riêng tư tách biệt khỏi thư mục mẹ tài khoản người dùng.
[C-3-4] KHÔNG ĐƯỢC cho phép tạo hồ sơ người dùng bổ sung nếu có là Chủ sở hữu thiết bị được cấp phép (xem phần 3.9.1) hoặc cho phép Chủ sở hữu thiết bị được cấp phép mà không phải xoá hồ sơ người dùng bổ sung trước đó.

Nếu việc triển khai thiết bị tạo hồ sơ người dùng bổ sung được thảo luận ở trên, thì họ:

[C-4-1] PHẢI cho phép các ý định dưới đây bắt nguồn từ được xử lý bởi các ứng dụng của người dùng chính trên thiết bị:
- 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 hạn chế và chọn đối với chính sách thiết bị dành cho người dùng người dùng không phải người dùng restrictions(list below) được áp dụng cho người dùng chính của thiết bị đối với hồ sơ người dùng bổ sung này.
[C-4-3] PHẢI chỉ cho phép ghi địa chỉ liên hệ từ hồ sơ bổ sung này qua các ý định sau:
[C-4-4] KHÔNG ĐƯỢC chạy đồ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] PHẢI chỉ cho 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 danh bạ mà hồ sơ người dùng là cấp độ gốc.

9.6. Cảnh báo qua tin nhắn dịch vụ

Android hỗ trợ tính năng cảnh báo người dùng về mọi cuộc gọi đi tin nhắn SMS dịch vụ. Tin nhắn dịch vụ tin nhắn là tin nhắn văn bản được gửi tới một dịch vụ đã đăng ký với nhà cung cấp dịch vụ mà có thể người dùng phải chịu phí.

Nếu các phương thức triển khai thiết bị khai báo hỗ trợ cho android.hardware.telephony, chúng:

[C-1-1] PHẢI cảnh báo người dùng trước khi gửi tin nhắn SMS đến các số được xác định bằng biểu thức chính quy được xác định trong /data/misc/sms/codes.xml trong thiết bị. Dự án nguồn mở Android ngược dòng cung cấp cách triển khai đáp ứng yêu cầu này.

9,7. Tính năng bảo mật

Việc triển khai thiết bị PHẢI đảm bảo tuân thủ các tính năng bảo mật trong cả nhân hệ điều hành và nền tảng như được mô tả dưới đây.

Android Sandbox có các tính năng sử dụng Linux tăng cường bảo mật (SELinux) hệ thống kiểm soát truy cập bắt buộc (MAC), hộp cát seccomp và trong nhân 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 Android khung.
[C-0-2] KHÔNG ĐƯỢC hiển thị giao diện người dùng khi bảo mật tính năng bảo mật này phát hiện thấy lỗi vi phạm và chặn thành công được triển khai bên dưới khung Android, nhưng CÓ THỂ có giao diện người dùng rõ ràng khi xảy ra lỗi vi phạm bảo mật được bỏ chặn dẫn đến việc khai thác thành công.
[C-0-3] KHÔNG ĐƯỢC triển khai SELinux hoặc bất kỳ tính năng bảo mật nào khác bên dưới khung Android có thể định cấu hình cho người dùng hoặc nhà phát triển ứng dụng.
[C-0-4] KHÔNG ĐƯỢC cho phép ứng dụng có thể ảnh hưởng đến một ứng dụng khác thông qua một API (chẳng hạn như API Quản trị thiết bị) để định cấu hình một chính sách làm hỏng khả năng tương thích.
[C-0-5] PHẢI phân tách khung phương tiện thành nhiều quy trình để nó có thể cấp quyền truy cập cho từng quy trình trong phạm vi hẹp hơn như mô tả trên trang web Dự án nguồn mở Android.
[C-0-6] PHẢI triển khai cơ chế hộp cát ứng dụng hạt nhân cho phép lọc các lệnh gọi hệ thống bằng cách sử dụng một chính sách có thể định cấu hình từ chương trình đa luồng. Dự án nguồn mở Android ngược dòng đáp ứng được điều này thông qua việc bật seccomp-BPF với nhóm luồng đồng bộ hoá (TSYNC) như được mô tả trong mục Cấu hình hạt nhân của source.android.com.

Các tính năng tự bảo vệ và tính toàn vẹn của kernel là những phần không thể thiếu trong Android bảo mật. Triển khai thiết bị:

[C-0-7] PHẢI triển khai cơ chế bảo vệ tràn vùng đệm ngăn xếp hạt nhân. Ví dụ về các cơ chế đó là CC_STACKPROTECTOR_REGULAR và CONFIG_CC_STACKPROTECTOR_STRONG
[C-0-8] PHẢI triển khai các biện pháp bảo vệ bộ nhớ nhân hệ điều hành nghiêm ngặt ở nơi có thể thực thi mã có dạng chỉ đọc, dữ liệu chỉ đọc không thể thực thi và không thể ghi, và dữ liệu có thể ghi là không thể thực thi (ví dụ: CONFIG_DEBUG_RODATA hoặc CONFIG_STRICT_KERNEL_RWX).
[C-0-9] PHẢI triển khai kích thước đối tượng tĩnh và động giới hạn kiểm tra bản sao giữa không gian người dùng và không gian nhân (ví dụ: CONFIG_HARDENED_USERCOPY) trên những thiết bị ban đầu vận chuyển có 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 (ví dụ: PXN phần cứng hoặc được mô phỏng qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị vận chuyển ban đầu bằng API cấp 28 trở lên.
[C-0-11] KHÔNG ĐƯỢC đọc hoặc ghi bộ nhớ không gian người dùng trong nhân bên ngoài các API truy cập bản sao người dùng thông thường (ví dụ: PAN phần cứng, hoặc được mô phỏng qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị ban đầu vận chuyển bằng API cấp 28 trở lên.
[C-0-12] PHẢI triển khai cách ly bảng trang hạt nhân nếu phần cứng là dễ gặp vấn đề về lỗ hổng CVE-2017-5754 trên tất cả các thiết bị ban đầu được vận chuyển có 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 tăng cường dự đoán nhánh nếu phần cứng là dễ gặp vấn đề về lỗ hổng CVE-2017-5715 trên tất cả các thiết bị ban đầu được vận chuyển có cấp độ API 28 trở lên (ví dụ: CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] Liên minh Dẫn đầu để giữ dữ liệu nhân hệ điều hành chỉ được viết trong quá trình khởi chạy, được đánh dấu là chỉ đọc sau khởi tạo (ví dụ: __ro_after_init).
[C-SR-2] AreĐể chỉ định ngẫu nhiên bố cục của mã nhân hệ điều hành và bộ nhớ cũng như để tránh tình trạng rò rỉ dữ liệu có thể ảnh hưởng đến quá trình sắp xếp ngẫu nhiên (ví dụ: CONFIG_RANDOMIZE_BASE với entropy trình tải khởi động thông qua /chosen/kaslr-seed Device Tree node hoặc EFI_RNG_PROTOCOL).
[C-SR-3] AreĐể bật tính toàn vẹn của luồng điều khiển (CFI) trong nhân hệ điều hành để cung cấp thêm biện pháp 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] Are trì hoãn không cho phép vô hiệu hoá Control-Flow Integrity (CFI), Ngăn xếp lệnh gọi bóng (SCS) hoặc Dọn dẹp tràn số nguyên (IntSan) trên đã bật tính năng này.
[C-SR-5] Are chóng NÊN bật tính năng CFI, SCS và IntSan cho bất kỳ các thành phần khác của không gian người dùng nhạy cảm với tính bảo mật như được giải thích trong CFI và IntSan.
[C-SR-6] Are phong phú NÊN bật tính năng khởi tạo ngăn xếp trong nhân hệ điều hành để ngăn việc sử dụng các biến cục bộ chưa khởi tạo (CONFIG_INIT_STACK_ALL hoặc CONFIG_INIT_STACK_ALL_ZERO). Ngoài ra, quá trình triển khai thiết bị KHÔNG ĐƯỢC giả định giá trị mà trình biên dịch sử dụng để khởi tạo các tập dữ liệu cục bộ.
[C-SR-7] Are mã ĐỀ XUẤT NÊN bật tính năng khởi chạy vùng nhớ khối xếp trong nhân để ngăn việc sử dụng phương thức phân bổ vùng nhớ khối xếp chưa khởi tạo (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) và họ KHÔNG ĐƯỢC giả định giá trị được sử dụng bởi nhân hệ điều hành để khởi tạo các lượt phân bổ đó.

Nếu quá trình triển khai thiết bị sử dụng một nhân hệ điều hành Linux có thể hỗ trợ SELinux, họ:

[C-1-1] PHẢI triển khai SELinux.
[C-1-2] PHẢI đặt SELinux thành chế độ thực thi toàn cục.
[C-1-3] PHẢI định cấu hình tất cả các miền ở chế độ thực thi. Không có chế độ cho phép được phép, bao gồm các miền cụ thể 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 hiện có trong thư mục system/sepolicy được cung cấp trong Nguồn mở Android ngược dòng Dự án (AOSP) và chính sách PHẢI biên dịch với tất cả các quy tắc bao giờ có mặt, cho cả miền AOSP SELinux cũng như miền cụ thể của thiết bị/nhà cung cấp.
[C-1-5] PHẢI chạy các ứng dụng của bên thứ ba nhắm đến API cấp 28 trở lên trong hộp cát SELinux cho mỗi ứng dụng với các hạn chế SELinux cho mỗi ứng dụng thư mục dữ liệu cá nhân của ứng dụng.
NÊN giữ lại chính sách SELinux mặc định được cung cấp trong hệ thống/sepolicy của Dự án nguồn mở Android ngược dòng và chỉ thêm vào thư mục này chính sách cho cấu hình dành riêng cho thiết bị của họ.

Nếu quá trình triển khai thiết bị sử dụng nhân hệ điều hành không phải là Linux hoặc Linux mà không có SELinux, chúng:

[C-2-1] PHẢI sử dụng hệ thống kiểm soát truy cập bắt buộc tương đương với SELinux.

Nếu quá trình triển khai thiết bị sử dụng thiết bị I/O có khả năng DMA, thì các hoạt động đó:

[C-SR-9] Are mã hoá thư mục đích để cách ly từng thiết bị I/O có khả năng DMA, sử dụng IOMMU (ví dụ: ARM SMMU).

Android chứa nhiều tính năng phòng thủ theo chiều sâu không thể thiếu trong thiết bị bảo mật. 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 cách triển khai thiết bị:

[C-SR-10] AreĐể chỉ định được kiểm tra bằng cách sử dụng lỗi bộ nhớ không gian người dùng các công cụ phát hiện 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] AreĐể các bạn được kiểm tra bằng cách sử dụng lỗi bộ nhớ nhân hệ điều hành các công cụ phát hiện như KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS cho Thiết bị ARMv9, CONFIG_KASAN_SW_TAGS cho các thiết bị ARMv8 hoặc CONFIG_KASAN_GENERIC cho các loại thiết bị khác).
[C-SR-12] Are trì hoãn việc sử dụng các công cụ phát hiện lỗi bộ nhớ trong 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ác hoạt động triển khai thiết bị đó sẽ:

[C-SR-13] Are Để chỉ định sử dụng một giao thức chuẩn cho bộ nhớ, chia sẻ giữa Android và TEE, chẳng hạn như Khung chương trình cơ sở Arm cho Armv8-A (FF-A).
[C-SR-14] Are Để chỉ cho phép các ứng dụng đáng tin cậy, bạn chỉ nên giới hạn các ứng dụng này truy cập bộ nhớ đã được chia sẻ rõ ràng với họ qua giao thức. Nếu thiết bị có hỗ trợ cấp ngoại lệ Arm S-EL2, thì giá trị này phải được thực thi bởi trình quản lý phân vùng bảo mật. Nếu không, mã này sẽ là được thực thi bởi hệ điều hành TEE.

Công nghệ An toàn bộ nhớ là công nghệ giúp giảm thiểu các vấn đề sau: loại lỗi có xác suất cao (> 90%) trong các ứng dụng sử dụng android:memtagMode tuỳ chọn tệp kê khai:

tràn vùng đệm của vùng nhớ khối xếp
sử dụng sau khi miễn phí
miễn phí hai lần
tự do (không có con trỏ không Malloc)

Triển khai thiết bị:

[C-SR-15] Are mã ĐỀ XUẤT NÊN đặt ro.arm64.memtag.bootctl_supported.

Nếu quá trình triển khai thiết bị có đặt thuộc tính hệ thống ro.arm64.memtag.bootctl_supported thành đúng, họ:

[C-3-1] PHẢI cho phép thuộc tính hệ thống arm64.memtag.bootctl chấp nhận danh sách các giá trị sau đây được phân tách bằng dấu phẩy, với hiệu quả mong muốn sẽ áp dụng vào lần khởi động lại tiếp theo:
- memtag: công nghệ An toàn bộ nhớ như định nghĩa ở trên đã được bật
- memtag-once: công nghệ An toàn bộ nhớ như định nghĩa ở trên là được bật tạm thời và tự động bị tắt khi bật, tiếp theo khởi động lại
- memtag-off: công nghệ An toàn bộ nhớ như định nghĩa ở 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, thiết bị cũng PHẢI cập nhật thuộc tính nếu việc triển khai thiết bị cho phép sửa đổi trạng thái mà không cần thay đổi thuộc tính hệ thống.
[C-SR-16] Are Để ĐỀ XUẤT NÊN hiển thị Chế độ cài đặt dành cho nhà phát triển, bạn có thể đặt memtag-một lần và khởi động lại thiết bị. Với trình tải khởi động tương thích, Dự án nguồn mở Android đáp ứng các yêu cầu trên thông qua Giao thức trình tải khởi động MTE.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu một thiết bị khai báo android.hardware.telephony, thiết bị đó sẽ hỗ trợ đài chức năng CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK và bao gồm modem di động hỗ trợ kết nối 2G, thiết bị triển khai:

[C-SR-17] Giới hạn định dạng đề nghị cung cấp thuộc tính tương tác của người dùng để vô hiệu hoá và bật 2G.
[C-SR-18] Are Từ ĐỀ XUẤT NÊN không ghi đè thuộc tính tương tác của người dùng tắt và bật 2G thông qua bất kỳ thiết bị nào khác, ngoại trừ thiết bị đó quản trị viên sử dụng UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] Are mã ĐỀ XUẤT NÊN gọi TelephonyManager.setAllowedNetworkTypesForReason cùng với lý do ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G để đạt được điều này .
[C-SR-20] Are trì hoãn phát trên thiết bị di động để xác định hỗ trợ modem di động cho 2G bằng cách gọi TelephonyManager.getSupportedRadioAccessFamily. Xem Tắt 2G với chi tiết.

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

9,8. Quyền riêng tư

9.8.1. Nhật ký sử dụng

Android lưu trữ nhật ký lựa chọn của người dùng và quản lý nhật ký đó bằng UsageStatsManager.

Triển khai thiết bị:

[C-0-1] PHẢI duy trì khoảng thời gian lưu giữ hợp lý lịch sử người dùng đó.
[C-SR-1] Are được linh hoạt hóa để giữ khoảng thời gian lưu giữ 14 ngày dưới dạng được định cấu hình theo mặc định trong quá trình triển khai AOSP (Dự án nguồn mở Android).

Android lưu trữ các sự kiện hệ thống bằng StatsLog mã nhận dạng và quản lý lịch sử đó qua StatsManager và API Hệ thống IncidentManager.

Triển khai thiết bị:

[C-0-2] PHẢI chỉ bao gồm các trường được đánh dấu bằng DEST_AUTOMATIC trong báo cáo sự cố do lớp API Hệ thống IncidentManager tạo.
[C-0-3] KHÔNG ĐƯỢC sử dụng giá trị nhận dạng sự kiện của hệ thống để ghi lại bất kỳ sự kiện nào khác so với thông tin được mô tả trong StatsLog Tài liệu SDK. Nếu các sự kiện hệ thống bổ sung được ghi lại, chúng CÓ THỂ sử dụng định danh nguyên tử khác nhau trong khoảng từ 100.000 đến 200.000.

9.8.2. Đang ghi

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC tải trước hoặc phân phối các thành phần phần mềm ngay từ đầu 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 xoá thông báo hiển thị liên tục.
[C-0-2] PHẢI hiển thị cảnh báo người dùng và nhận được sự đồng ý rõ ràng của người dùng cho phép mọi thông tin nhạy cảm được hiển thị trên màn hình của người dùng được ghi lại mỗi lần một phiên hoạt động để thu thập màn hình sẽ bắt đầu qua MediaProjection.createVirtualDisplay()! VirtualDeviceManager.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 trong khi truyền màn hình hoặc tính năng ghi màn hình đã được bật. AOSP đáp ứng yêu cầu này bằng cách hiển thị một 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] AreĐể thực hiện việc hiển thị cảnh báo người dùng, đó là thông tin chính xác cùng một thông báo như được triển khai trong AOSP (Dự án nguồn mở Android) nhưng CÓ THỂ thay đổi được miễn là 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 chụp.
[C-0-4] KHÔNG ĐƯỢC cung cấp cho người dùng một thuộc tính tương tác để tắt các lời nhắc trong tương lai của người dùng đồng ý chụp màn hình, trừ phi phiên bắt đầu bằng ứng dụng hệ thống mà người dùng đã cho phép associate() với android.app.role.COMPANION_DEVICE_APP_STREAMING hoặc android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING hồ sơ thiết bị của bạn.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Triển khai thiết bị:

[C-0-7] KHÔNG ĐƯỢC ghi lại, dự án hoặc truyền các thông tin nhạy cảm 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 trong ứ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

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

Nếu quá trình triển khai thiết bị bao gồm chức năng trong hệ thống mà: ghi lại nội dung hiển thị trên màn hình và/hoặc ghi lại luồng âm thanh được phát trên thiết bị không phải qua API hệ thống ContentCaptureService hoặc các phương thức 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 xung quanh, các quyền này:

[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 việc này được bật và chủ động chụp/ghi.

Nếu quá trình triển khai thiết bị bao gồm một thành phần được bật sẵn, có 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, họ:

[C-2-1] KHÔNG ĐƯỢC lưu trữ liên tục trên bộ nhớ trên thiết bị hoặc truyền ra khỏi ghi lại âm thanh thô được ghi lại hoặc bất kỳ định dạng nào có thể chuyển đổi lại thành âm thanh gốc hoặc bản fax, trừ phi có sự đồng ý rõ ràng của người dùng.

Một "chỉ báo micrô" đề cập đến một lượt xem trên màn hình thường xuyên hiển thị cho người dùng và không thể bị che khuất. Người dùng hiểu điều này là micrô được sử dụng(thông qua văn bản, màu sắc, biểu tượng độc đáo hoặc kết hợp nhiều hơn).

"Chỉ báo camera" đề cập đến một lượt xem trên màn hình thường xuyên hiển thị với người dùng và không thể bị che khuất. Người dùng hiểu điều này là máy ảnh đang được sử dụng (thông qua văn bản, màu sắc, biểu tượng độc đáo hoặc kết hợp với nhau).

Sau khi hiển thị giây đầu tiên, chỉ báo có thể thay đổi trực quan, chẳng hạn như nhỏ hơn và không bắt buộc phải hiển thị như cách trình bày ban đầu và đã hiểu.

Chỉ báo micrô có thể được hợp nhất với một camera đang hiển thị chỉ báo, miễn là văn bản, biểu tượng hoặc màu sắc cho người dùng biết đã bắt đầu sử dụng micrô.

Chỉ báo camera có thể được hợp nhất với một micrô đang hiển thị chỉ báo, 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 đã bắt đầu sử dụng máy ảnh.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình triển khai thiết bị đó sẽ:

[C-SR-1] Are được linh hoạt đề xuất để hiển thị chỉ báo micrô khi một ứng dụng truy cập dữ liệu âm thanh từ micrô, nhưng không truy cập khi micrô đang bật 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] AreĐể hiển thị danh sách các thông tin gần đây và đang hoạt động, ứng dụng sử dụng micrô khi được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với bất kỳ thuộc tính nào tin nhắn liên kết với các nguồn đó.
[C-SR-3] Are Internet ĐỀ XUẤT NÊN không ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng dễ thấy hoặc có sự tương tác trực tiếp của người dùng.

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

[C-SR-4] AreĐể chỉ hiển thị chỉ báo của máy ảnh khi một ứng dụng là truy cập vào dữ liệu camera trực tiếp, nhưng không truy cập khi chỉ truy cập vào camera bởi(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền với CDD mã nhận dạng [C-3-X].
[C-SR-5] AreĐể hiển thị các ứng dụng gần đây và đang hoạt động bằng cách sử dụng camera được trả về từ PermissionManager.getIndicatorAppOpUsageData(), cùng với mọi thông báo ghi công liên quan.
[C-SR-6] Are Internet ĐỀ XUẤT NÊN không ẩn chỉ báo máy ảnh cho hệ thống các ứng dụng có giao diện người dùng dễ thấy hoặc có sự 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 quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, chúng:

[C-1-1] PHẢI trình bày giao diện người dùng để yêu cầu sự đồng ý của người dù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 trước cùng một chứng chỉ gốc cho các hệ thống đáng tin cậy Kho lưu trữ Tổ chức phát hành chứng chỉ (CA) như được cung cấp trong Dự án nguồn mở Android ngược dòng.
[C-0-2] PHẢI gửi cùng một kho lưu trữ 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 một CA gốc của người dùng được thêm.

Nếu lưu lượng truy cập thiết bị được định tuyến thông qua VPN, việc triển khai thiết bị:

[C-1-1] PHẢI hiển thị cảnh báo cho người dùng cho biết:
- Lưu lượng truy cập mạng đó có thể được giám sát.
- Lưu lượng truy cập mạng đó đang được định tuyến thông qua VPN cụ thể ứng dụng cung cấp VPN.

Nếu quá trình triển khai thiết bị có một cơ chế, được bật ngay từ đầu theo mặc định, định tuyến lưu lượng truy cập dữ liệu mạng qua máy chủ proxy hoặc cổng VPN (ví dụ: tải trước dịch vụ VPN đã cấp android.permission.CONTROL_VPN), chúng:

[C-2-1] PHẢI yêu cầu sự đồng ý của người dùng trước khi bật cơ chế đó, trừ khi 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 đó, người dùng không cần đưa ra sự đồng ý riêng, nhưng Chỉ được thông báo.

Nếu các quá trình triển khai thiết bị triển khai một thuộc tính tương tác của người dùng để bật "VPN luôn bật" của ứng dụng VPN của bên thứ ba, chúng:

[C-3-1] PHẢI tắt thuộc tính tương tác người dùng này cho các ứ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 giá trị SERVICE_META_DATA_SUPPORTS_ALWAYS_ON cho 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 quyền truy cập vào số sê-ri của thiết bị và, trong đó áp dụng, IMEI/MEID, số sê-ri của SIM và Số điện thoại di động quốc tế Danh tính người đăng ký (IMSI) của một ứng dụng, trừ phi ứng dụng đó đáp ứng một trong các điều kiện sau các yêu cầu:
- là một ứng dụng của nhà mạng đã ký mà nhà sản xuất thiết bị đã xác minh.
- đã được cấp quyền READ_PRIVILEGED_PHONE_STATE.
- có đặc quyền của nhà mạng như xác định trong phần UICC nhà cung cấp đặc quyền.
- là chủ sở hữu thiết bị hoặc chủ sở hữu hồ sơ đã được cấp quyền Quyền READ_PHONE_STATE.
- (Chỉ dành cho số sê-ri của SIM/ICCID) có yêu cầu theo quy định của địa phương để ứng dụng phát hiện có sự thay đổi trong danh tính của người đăng ký.

9.8.6. Dữ liệu cấp hệ điều hành và dữ liệu môi trường xung quanh

Android, thông qua API hệ thống, hỗ trợ cơ chế cho thiết bị để thu thập những dữ liệu nhạy cảm sau:

Văn bản và hình ảnh 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ợ qua AssistStructure API.
Dữ liệu nội dung nghe nhìn, chẳng hạn như âm thanh hoặc video, mà thiết bị ghi lại hoặc phát.
Sự kiện nhập (ví dụ: phím, chuột, cử chỉ, giọng nói, video và hỗ trợ tiếp cận).
Bất kỳ màn hình hoặc dữ liệu nào 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 qua Content Capture API.
Mọi dữ liệu ứng dụng được truyền vào hệ thống qua API AppSearchManager và có thể truy cập qua AppSearchGlobalManager.query.
Mọi văn bản hoặc dữ liệu khác được gửi qua TextClassifier API đối với System TextClassifier, 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 ra hành động được dự đoán tiếp theo dựa trên văn bản.
Dữ liệu được lập chỉ mục bởi hoạt động triển khai nền tảng AppSearch, bao gồm nhưng không bao gồm chỉ có thể sử dụng văn bản, đồ hoạ, dữ liệu đa phương tiện hoặc các dữ liệu tương tự khác.
Dữ liệu âm thanh có được nhờ sử dụng SpeechRecognizer#onDeviceSpeechRecognizer() của Trình nhận dạng lời nói Triển khai.
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 khiến người dùng nhìn thấy chỉ báo
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 mà không dẫn đến chỉ báo dễ thấy cho người dùng

Nếu các hoạt động triển khai thiết bị thu thập được bất kỳ dữ liệu nào ở trên, chúng:

[C-1-1] PHẢI mã hoá tất cả những dữ liệu đó khi được lưu trữ trong thiết bị. Chiến dịch này CÓ THỂ thực hiện quá trình mã hoá bằng tính năng Mã hoá dựa trên tệp Android hoặc bất kỳ của thuật toán mật mã liệt kê dưới dạng API phiên bản 26 trở lên được mô tả trong SDK thuật toán mật mã.
[C-1-2] KHÔNG ĐƯỢC sao lưu dữ liệu thô hoặc dữ liệu đã mã hoá bằng Các phương thức sao lưu trên Android hoặc bất kỳ phương thức sao lưu nào khác .
[C-1-3] PHẢI chỉ gửi tất cả dữ liệu như vậy ra khỏi thiết bị sử dụng cơ chế bảo đảm quyền riêng tư, ngoại trừ với sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được đã chia sẻ. Cơ chế bảo đảm quyền riêng tư được định nghĩa là "những chỉ số chỉ cho phép phân tích ở dạng dữ liệu tổng hợp và ngăn chặn so khớp các sự kiện đã ghi lại hoặc kết quả phát sinh với người dùng cá nhân" với ngăn việc dữ liệu của mỗi người dùng là nội bộ (ví dụ: được triển khai bằng một công nghệ sự riêng tư biệt lập như RAPPOR).
[C-1-4] KHÔNG ĐƯỢC liên kết dữ liệu như vậy với bất kỳ danh tính người dùng nào (như dưới tên Account) trên thiết bị, trừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được liên kết.
[C-1-5] KHÔNG ĐƯỢC chia sẻ dữ liệu đó với các thành phần hệ điều hành khác không được hãy tuân theo các yêu cầu được nêu trong phần hiện tại (9.8.6 Cấp độ hệ điều hành và dữ liệu môi trường xung quanh), ngoại trừ khi có sự đồng ý rõ ràng của người dùng mỗi thời gian được chia sẻ. Trừ phi chức năng đó được tạo dưới dạng API SDK Android (AmbientContext, HotwordDetectionService).
[C-1-6] PHẢI cung cấp thuộc tính tương tác của người dùng để xoá dữ liệu đó Việc triển khai hoặc phương thức thuộc quyền sở hữu riêng thu thập khi dữ liệu được lưu trữ dưới bất kỳ dạng nào trên thiết bị. Nếu người dùng chọn xoá dữ liệu, PHẢI xoá tất cả dữ liệu trong quá khứ đã thu thập .
[C-1-7] PHẢI cung cấp lựa chọn không tham gia dữ liệu được thu thập cho người dùng thông qua AppSearch hoặc các phương tiện thuộc quyền sở hữu riêng để hiển thị trong nền tảng Android (ví dụ: trình chạy).
[C-SR-1] Are trì hoãn việc đề xuất NOT để yêu cầu quyền INTERNET.
[C-SR-2] Giới hạn định dạng chỉ để truy cập Internet thông qua 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.
[C-SR-4] Are Internet ĐỀ XUẤT NÊN được triển khai với API SDK Android hoặc kho lưu trữ nguồn mở tương tự do OEM (Nhà sản xuất thiết bị gốc) sở hữu; và / hoặc được thực hiện trong một Triển khai hộp cát (xem 9.8.15 Triển khai API hộp cát).

Liệu quá trình triển khai thiết bị có bao gồm một dịch vụ triển khai API hệ thống hay không ContentCaptureService, AppSearchManager.index 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ư được mô tả ở trên, chúng:

[C-2-1] KHÔNG ĐƯỢC cho phép người dùng thay thế các dịch vụ bằng ứng dụng hoặc dịch vụ mà người dùng có thể cài đặt và PHẢI chỉ cho phép cài đặt trước để thu thập dữ liệu đó.
[C-2-2] KHÔNG ĐƯỢC cho phép bất kỳ ứng dụng nào khác ngoài dịch vụ được cài đặt trước để có thể thu thập dữ liệu đó.
[C-2-3] PHẢI cung cấp thuộc tính tương tác của người dùng để tắt các dịch vụ.
[C-2-4] KHÔNG ĐƯỢC bỏ qua tương tác của người dùng để quản lý các quyền của Android mà do các dịch vụ nắm giữ và tuân theo các quyền của Android theo mô hình được mô tả trong Phần 9.1. Quyền.
[C-SR-3] Are Internet ĐỀ XUẤT NÊN tách biệt các dịch vụ với nhau các thành phần hệ thống (ví dụ: không liên kết mã nhận dạng quá trình chia sẻ hoặc dịch vụ) ngoại trừ 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. 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 đã cắt từ bảng nhớ tạm (ví dụ: qua ClipboardManager API) trừ phi bên thứ ba là IME mặc định hoặc là ứng dụng hiện có tiêu điểm.
[C-0-2] PHẢI xoá dữ liệu bảng nhớ tạm tối đa sau 60 phút kể từ lần gần đây nhất được đặt vào một bảng nhớ tạm hoặc đọc từ một bảng nhớ tạm.

9.8.8. Vị trí

Vị trí bao gồm thông tin trong loại Vị trí trên Android( chẳng hạn như Latitude, Kinh độ, Độ cao), cũng như các giá trị nhận dạng có thể chuyển đổi thành Vị trí. Vị trí có thể chính xác như DGPS (Hệ thống định vị toàn cầu vi phân) hoặc tương đối như vị trí cấp quốc gia (như vị trí mã quốc gia - MCC - Điện thoại di động Mã quốc gia).

Sau đây là danh sách các loại vị trí trực tiếp lấy cảm hứng từ người dùng vị trí hoặc có thể được chuyển đổi thành vị trí của người dùng. Đây chưa phải là bài đánh giá đầy đủ mà nên dùng làm ví dụ về việc Vị trí có thể trực tiếp hoặc gián tiếp có nguồn gốc từ:

GPS/GNSS/DGPS/PSA
- Giải pháp định vị toàn cầu, Hệ thống vệ tinh điều hướng toàn cầu hoặc Giải pháp định vị toàn cầu biệt lập
- Dữ liệu này cũng bao gồm các chỉ số Đo lường GNSS thô và Trạng thái GNSS
  - Vị trí chính xác có thể lấy từ các phép đo GNSS thô
Các công nghệ không dây có giá trị nhận dạng riêng biệt như:
- Điểm truy cập Wi-Fi (MAC, BSSID, Name hoặc SSID)
- Bluetooth/BLE (MAC, BSSID, Tên hoặc SSID)
- UWB (MAC, BSSID, Tên hoặc SSID)
- ID tháp di động (3G, 4G, 5G... bao gồm tất cả các Modem di động trong tương lai công nghệ có giá trị nhận dạng duy nhất)

Để tham khảo chính, hãy xem những 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í thiết bị và Wi-Fi/Bluetooth quét cài đặt mà không có sự đồng ý rõ ràng của người dùng hoặc không khởi tạo người dùng.
[C-0-2] PHẢI cung cấp thuộc tính tương tác của người dùng để truy cập liên quan đến vị trí thông tin, bao gồm các yêu cầu về thông tin vị trí gần đây, quyền và mức sử dụng ở cấp ứng dụng quét tìm Wi-Fi/Bluetooth để xác định vị trí.
[C-0-3] PHẢI đảm bảo rằng ứng dụng sử dụng API Bỏ qua vị trí khẩn cấp [LocationRequest.setLocationSettingsIgnored()] là trường hợp khẩn cấp do người dùng khởi tạo phiên (ví dụ: quay số 911 hoặc nhắn tin tới 911). Tuy nhiên, đối với Ô tô, phương tiện CÓ THỂ bắt đầu phiên khẩn cấp mà không có sự tương tác của người dùng đang hoạt động trong trường hợp này phát hiện thấy sự cố/tai nạn (ví dụ: để đáp ứng các yêu cầu về cuộc gọi điện tử).
[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í trên thiết bị mà không thay đổi chế độ cài đặt.
[C-0-5] PHẢI lên lịch thông báo nhắc người dùng sau một ứng dụng trong đã truy cập vào thông tin vị trí của họ ở chế độ nền Quyền [ACCESS_BACKGROUND_LOCATION].

9.8.9. Ứng dụng đã cài đặt

Ứ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ề lựa chọn khác ứng dụng đã cài đặt theo mặc định (xem phần Chế độ hiển thị gói trong Android Tài liệu SDK).

Triển khai thiết bị:

[C-0-1] KHÔNG ĐƯỢC hiển thị với bất kỳ ứng dụng nào nhắm mục tiêu API cấp 30 trở lên 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 API được quản lý. Điều này bao gồm nhưng không giới hạn ở thông tin chi tiết do bất kỳ API tuỳ chỉnh nào hiển thị do thiết bị thêm vào trình triển khai hoặc có thể truy cập qua hệ thống tệp.
[C-0-2] KHÔNG ĐƯỢC cấp cho bất kỳ ứng dụng nào, quyền đọc hoặc ghi vào các tệp trong bất kỳ ứng dụng nào khác thư mục dành riêng cho ứng dụng của ứng dụng trong bộ nhớ ngoài. Sau đây là các trường hợp ngoại lệ duy nhất:
- Quyền của nhà cung cấp bộ nhớ ngoài (ví dụ: các ứng dụng như DocumentsUI).
- Nhà cung cấp dịch vụ tải xuống sử dụng cụm từ "tải xuống" thẩm quyền của nhà cung cấp cho đang tải tệp xuống bộ nhớ ứng dụng.
- Ứng dụng giao thức truyền đa phương tiện do nền tảng ký (MTP) sử dụng quyền đặc quyền ACCESS_MTP để cho phép truyền tệp đến thiết bị khác.
- Những ứng dụng cài đặt các ứng dụng khác và có quyền này INSTALL_PACKAGES chỉ có thể truy cập "obb" các thư mục để 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 quá trình triển khai thiết bị khai báo cờ tính năng android.hardware.telephony, chúng:

[C-1-1] PHẢI hỗ trợ tạo báo cáo lỗi kết nối 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 đượ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 sau này từ ứng dụng.
[C-1-3] KHÔNG ĐƯỢC trả về báo cáo đã tạo cho ứng dụng yêu cầu mà không có sự đồng ý rõ ràng của người dùng.
[C-1-4] Báo cáo được tạo bằng BUGREPORT_MODE_TELEPHONY PHẢI chứa ít nhất các thông tin sau:
- Tệp kết xuất TelephonyDebugService
- Tệp kết xuất TelephonyRegistry
- Tệp kết xuất WifiService
- Tệp kết xuất ConnectivityService
- Tệp kết xuất của thực thể CarrierService của gói gọi (nếu được ràng buộc)
- Vùng đệm nhật ký vô tuyến
- Tệp kết xuất SubscriptionManagerService
[C-1-5] KHÔNG ĐƯỢC bao gồm thông tin sau đây trong các báo cáo đã tạo:
- Bất kỳ loại thông tin nào không liên quan trực tiếp đến khả năng kết nối gỡ lỗi.
- Mọi loại nhật ký lưu lượng truy cập ứng dụng do người dùng cài đặt hoặc hồ sơ chi tiết ứng dụng/gói do người dùng cài đặt (UID được chấp nhận, tên gói là không).
CÓ THỂ bao gồm cả thông tin bổ sung không liên quan đến bất kỳ người dùng nào nhận dạng. (ví dụ: nhật ký của nhà cung cấp).

Nếu việc triển khai thiết bị bao gồm thông tin bổ sung (ví dụ: nhật ký của nhà cung cấp) trong và thông tin đó có quyền riêng tư/bảo mật/pin/bộ nhớ/bộ nhớ tác động, chúng:

[C-SR-1] AreĐể chỉ định chế độ cài đặt của nhà phát triển được mặc định là tắt. Quy trình triển khai tham chiếu AOSP đáp ứng điều này bằng cách cung cấp Enable verbose vendor logging tuỳ chọn trong phần cài đặt dành cho nhà phát triển để thêm nhật ký bổ sung của nhà cung cấp theo thiết bị cụ thể trong báo cáo lỗi.

9.8.11. Chia sẻ blob dữ liệu

Android, thông qua BlobStoreManager cho phép ứng dụng đóng góp blob dữ liệu cho Hệ thống để chia sẻ với bộ ứng dụng.

Nếu quá trình triển khai thiết bị có hỗ trợ blob dữ liệu dùng chung như mô tả trong Tài liệu về SDK, chúng:

[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 nhằm mục đích cho phép (ví dụ: phạm vi của quyền truy cập mặc định và quyền 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). Việc triển khai tham chiếu AOSP đáp ứng các các yêu cầu liên quan.
[C-1-2] KHÔNG ĐƯỢC gửi dữ liệu băm an toàn ra khỏi thiết bị hoặc chia sẻ với các ứng dụng khác của blob dữ liệu (dùng để kiểm soát quyền truy cập).

9.8.12. Nhận dạng nhạc

Android, thông qua API hệ thống MusicRecognitionManager, hỗ trợ cơ chế để yêu cầu nhận dạng nhạc, dựa trên một bản ghi âm, và uỷ quyền nhận dạng âm nhạc cho một ứng dụng đặc quyền triển khai API MusicRecognitionService.

Liệu quá trình triển khai thiết bị có bao gồm một dịch vụ triển khai API hệ thống hay không MusicRecognitionManager hoặc bất kỳ dịch vụ thuộc quyền sở hữu riêng nào có truyền dữ liệu âm thanh dưới dạng được mô tả như trên, chúng:

[C-1-1] PHẢI thực thi rằng phương thức gọi của MusicRecognitionManager giữ Quyền MANAGE_MUSIC_RECOGNITION
[C-1-2] PHẢI thực thi một công cụ nhận dạng nhạc được cài đặt sẵn ứng dụng triển khai MusicRecognitionService.
[C-1-3] KHÔNG ĐƯỢC cho phép người dùng thay thế MusicRecognitionManagerService hoặc MusicRecognitionService với ứng dụng hoặc dịch vụ có thể cài đặt.
[C-1-4] PHẢI đảm bảo rằng khi MusicRecognitionManagerService truy cập vào bản ghi âm và chuyển tiếp bản ghi đó đến ứng dụng đang triển khai MusicRecognitionService, việc truy cập âm thanh được theo dõi thông qua lệnh gọi AppOpsManager.noteOp / startOp.

Nếu việc triển khai MusicRecognitionManagerService trên thiết bị hoặc MusicRecognitionService lưu trữ mọi dữ liệu âm thanh thu được, chúng:

[C-2-1] KHÔNG ĐƯỢC lưu trữ bất kỳ vân tay âm thanh hoặc âm thanh thô nào trên ổ đĩa, hoặc trong bộ nhớ lâu hơn 14 ngày.
[C-2-2] KHÔNG ĐƯỢC chia sẻ dữ liệu đó ra ngoài MusicRecognitionService, ngoại trừ với sự đồng ý rõ ràng của người dùng mỗi khi thông tin được chia sẻ.

9.8.13. Trình quản lý quyền riêng tư cảm biến

Nếu các phương thức triển khai thiết bị cung cấp cho người dùng một thuộc tính tương tác cho phần mềm để tắt đầu vào máy ảnh và/hoặc micrô để triển khai thiết bị, họ:

[C-1-1] PHẢI trả về chính xác 'true' cho supportsSensorToggle() API.
[C-1-2] PHẢI, khi một ứng dụng cố gắng truy cập vào micrô hoặc máy ảnh bị chặn, hiển thị cho người dùng một thuộc tính tương tác không thể đóng, thể hiện rõ ràng cho biết cảm biến bị chặn và cần đưa ra lựa chọn để tiếp tục chặn hoặc bỏ chặn theo phương thức triển khai AOSP đáp ứng điều này .
[C-1-3] PHẢI chỉ truyền dữ liệu âm thanh và máy ảnh trống (hoặc giả) cho 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 khả năng tương tác của người dùng được trình bày theo [C-1-2] ở trên.

9.8.14. Không áp dụng

9.8.15. Triển khai API Hộp cát

Android, thông qua một tập hợp các API uỷ quyền, cung cấp một cơ chế xử lý bảo mật Dữ liệu cấp hệ điều hành và dữ liệu môi trường xung quanh. Việc xử lý như vậy có thể được ủy quyền cho ứng dụng cài đặt trước apk có quyền truy cập đặc quyền và khả năng giao tiếp giảm, còn gọi là Triển khai Sandboxed API (API Hộp cát).

Mọi cách triển khai API Hộp cát:

[C-0-1] KHÔNG ĐƯỢC yêu cầu quyền INTERNET.
[C-0-2] PHẢI chỉ truy cập Internet thông qua các API có cấu trúc được hỗ trợ bởi các phương pháp triển khai nguồn mở có sẵn công khai bằng cách sử dụng cơ chế bảo đảm quyền riêng tư cơ chế hoặc gián tiếp thông qua API SDK Android. Chế độ bảo đảm quyền riêng tư được định nghĩa là "các cơ chế chỉ cho phép phân tích ở dạng dữ liệu tổng hợp và ngăn việc so khớp các sự kiện đã ghi lại hoặc kết quả phát sinh với từng người dùng", để ngăn việc dữ liệu của mỗi người dùng là nội bộ (ví dụ: được triển khai bằng một công nghệ sự riêng tư biệt lập như Hàm RAPPOR).
[C-0-3] PHẢI tách biệt các dịch vụ với các thành phần hệ thống khác (ví dụ: không ràng buộc mã dịch vụ hoặc mã tiến trình chia sẻ) ngoại trừ sau:
- Điện thoại, Danh bạ, Giao diện người dùng hệ thống và Nội dung nghe nhìn
[C-0-4] KHÔNG ĐƯỢC cho phép người dùng thay thế các dịch vụ bằng ứng dụng hoặc dịch vụ mà người dùng có thể cài đặt
[C-0-5] PHẢI chỉ cho phép các dịch vụ được cài đặt trước thu thập dữ liệu như vậy. Trừ phi khả năng thay thế được tích hợp vào AOSP (ví dụ: cho Kỹ thuật số Ứng dụng Trợ lý).
[C-0-6] KHÔNG ĐƯỢC cho phép bất kỳ ứng dụng nào khác ngoài dịch vụ được cài đặt trước để có thể thu thập dữ liệu đó. Trừ phi khả năng chụp ảnh đó sẽ được triển khai bằng API SDK Android.
[C-0-7] PHẢI cung cấp thuộc tính tương tác của người dùng để tắt các dịch vụ.
[C-0-8] KHÔNG ĐƯỢC bỏ qua tương tác của người dùng để quản lý các quyền của Android mà do các dịch vụ nắm giữ và tuân theo mô hình quản lý quyền của Android được mô tả trong Mục 9.1. Quyền.

9.8.16. Dữ liệu Camera và Âm thanh liên tục

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Ngoài các yêu cầu nêu trong 9.8.2 Ghi âm, 9.8.6 cấp hệ điều hành và dữ liệu môi trường xung quanh và triển khai Sandboxed API 9.8.15, các triển khai sử dụng dữ liệu Âm thanh thu được ở chế độ nền (liên tục) qua AudioRecord, SoundTrigger hoặc các API Audio khác HOẶC dữ liệu Camera thu được trong chạy ở chế độ nền (liên tục) thông qua CameraManager hoặc các API Máy ảnh khác:

Nếu các quá trình triển khai thiết bị thu thập bất kỳ dữ liệu nào như mô tả trong 9.8.2 hoặc phần 9.8.6, và nếu những triển khai đó sử dụng dữ liệu Âm thanh thu được trong chạy ở chế độ nền (liên tục) thông qua AudioRecord, SoundTrigger hoặc các API Audio 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 Máy ảnh khác, chúng:

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

[C-0-1] PHẢI thực thi chỉ báo tương ứng (máy ảnh và/hoặc micrô như theo mục 9.8.2 Ghi lại), trừ trường hợp:
- Quyền truy cập này được thực hiện trong quá trình triển khai Hộp cát (xem 9.8.15 Triển khai Sandboxed API), thông qua một gói chứa một hoặc các vai trò khác sau đây: System UI Intelligence (Giao diện người dùng hệ thống), Hệ thống âm thanh thông minh xung quanh, Hệ thống Audio Intelligence Thông báo thông minh của hệ thống, System Text Intelligence (Thông tin cập nhật về văn bản của hệ thống) hoặc Hệ thống trí tuệ trực quan.
- Hoạt động truy cập được thực hiện thông qua một hộp cát, được triển khai và được thực thi thông qua các cơ chế trong AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- Quyền truy cập âm thanh được thực hiện nhằm mục đích hỗ trợ bởi Digital Ứng dụng Trợ lý, cung cấp SOURCE_HOTWORD dưới dạng nguồn âm thanh.
- Quyền truy cập do hệ thống thực hiện và được triển khai bằng mã nguồn mở.
[C-SR-1] IsĐể ĐỀ XUẤT KHÔNG NÊN yêu cầu sự đồng ý của người dùng cho mỗi chức năng có sử dụng dữ liệu đó và bị tắt theo mặc định.
[C-SR-2] Để áp dụng cùng một cách xử lý, các hạn chế nêu trong 9.8.2 Ghi âm, 9.8.6 Cấp độ hệ điều hành và dữ liệu môi trường xung quanh, 9.8.15 Triển khai Sandboxed API và 9.8.16 Âm thanh và Camera liên tục sang dữ liệu Camera đến từ một thiết bị đeo từ xa.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu dữ liệu Camera được cung cấp từ một thiết bị đeo từ xa và được truy cập trong một biểu mẫu chưa mã hoá bên ngoài hệ điều hành Android, triển khai hộp cát hoặc hộp cát do WearableSensingManager tạo, thì chúng:

Trường hợp quá trình triển khai thiết bị nhận dữ liệu Máy ảnh hoặc Micrô từ điều khiển từ xa thiết bị đeo của bạn và dữ liệu được truy cập ở dạng chưa mã hoá bên ngoài Hệ điều hành Android, mô hình triển khai hộp cát hoặc chức năng hộp cát được xây dựng bởi WearableSensingManager, họ:

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

[C-1-1] PHẢI chỉ báo cho thiết bị đeo từ xa để hãy hiển thị chỉ báo bổ sung tại đó.

Nếu thiết bị cho phép tương tác với một Ứng dụng Trợ lý kỹ thuật số không có từ khóa được chỉ định (xử lý truy vấn chung của người dùng hoặc phân tích sự hiện diện của người dùng qua máy ảnh), họ:

[C-2-1] PHẢI đảm bảo việc triển khai đó được cung cấp bởi một gói chứa Vai trò android.app.role.ASSISTANT.
[C-2-2] PHẢI đảm bảo phương thức triển khai đó sử dụng HotwordDetectionService và/hoặc API Android 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ác API Thống kê. Các nhật ký này được quản lý thông qua các API Thống kê mà có thể được sử dụng bởi các ứng dụng hệ thống đặc quyền.

Thống kê cũng cung cấp một cách để thu thập dữ liệu được phân loại là quyền riêng tư nhận dạng dữ liệu nhạy cảm trên các thiết bị có cơ chế bảo đảm quyền riêng tư. Cụ thể, API StatsManager::query cho phép truy vấn chỉ số bị hạn chế các danh mục đượ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ừ Trình quản lý số liệu thống kê:

[C-0-1] PHẢI là ứng dụng/triển khai duy nhất trên thiết bị và giữ quyền READ_RESTRICTED_STATS.
[C-0-2] PHẢI chỉ gửi dữ liệu đo từ xa và nhật ký của thiết bị bằng cơ chế 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 chỉ số chỉ cho phép phân tích ở dạng tổng hợp và ngăn chặn việc so khớp sự kiện được ghi lại hoặc kết quả phát sinh cho người dùng cá nhân" để ngăn chặn dữ liệu cho mỗi người dùng là dữ liệu có thể truy vấn (ví dụ: được triển khai bằng cách sử dụng vi phân công nghệ bảo vệ quyền riêng tư như RAPPOR).
[C-0-3] KHÔNG ĐƯỢC liên kết dữ liệu đó với bất kỳ danh tính người dùng nào (chẳng hạn như Tài khoản) trên thiết bị.
[C-0-4] KHÔNG ĐƯỢC chia sẻ dữ liệu đó với các thành phần hệ điều hành khác không tuân theo các yêu cầu được nêu trong phần hiện tại (9.8.17 Bảo đảm quyền riêng tư) Dữ liệu đo từ xa).
[C-0-5] PHẢI cung cấp một thuộc tính tương tác cho người dùng để bật/tắt tính năng bảo đảm quyền riêng tư thu thập, sử dụng và chia sẻ dữ liệu đo từ xa.
[C-0-6] PHẢI cung cấp thuộc tính tương tác của người dùng để xoá dữ liệu mà sẽ được thu thập nếu dữ liệu được lưu trữ ở bất kỳ dạng nào trên thiết bị. Nếu người dùng đã chọn xoá dữ liệu PHẢI xoá tất cả dữ liệu hiện được lưu trữ trên thiết bị.
[C-0-7] PHẢI công bố cách triển khai giao thức bảo đảm quyền riêng tư cơ bản trong kho lưu trữ nguồn mở.
[C-0-8 ]PHẢI thực thi các chính sách về đầu ra dữ liệu trong phần này để kiểm soát việc thu thập dữ liệu dữ liệu trong các danh mục chỉ số bị hạn chế được xác định trongStatsLog.

9,9. Mã hoá bộ nhớ dữ liệu

Mọi thiết bị PHẢI đáp ứng các yêu cầu của mục 9.9.1. Những thiết bị đã khởi chạy ở một cấp độ API sớm hơn cấp độ của tài liệu này được được miễn các yêu cầu của các mục 9.9.2 và 9.9.3; thay vào đó, PHẢI đáp ứng các yêu cầu trong mục 9.9 của phần Khả năng tương thích với Android Tài liệu định nghĩa tương ứng với cấp độ API mà thiết bị khởi chạy.

9.9.1. Khởi động trực tiếp

Triển khai thiết bị:

[C-0-1] PHẢI triển khai các API Direct Boot mode ngay cả khi chúng không hỗ trợ Mã hoá bộ nhớ.
[C-0-2] ACTION_LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED Ý định vẫn PHẢI được truyền đi để báo hiệu cho các ứng dụng nhận biết Khởi động trực tiếp Vị trí lưu trữ Được mã hoá thiết bị (DE) và Mã hoá thông tin xác thực (CE) là có sẵn cho người dùng.

9.9.2. Yêu cầu về mã hoá

Triển khai thiết bị:

[C-0-1] PHẢI mã hoá ứng dụng ở chế độ riêng tư dữ liệu (phân vùng /data), cũng như phân vùng bộ nhớ dùng chung của ứng dụng (/sdcard phân vùng) nếu đó là một bộ phận cố định, không thể tháo rời của thiết bị.
[C-0-2] PHẢI bật chế độ mã hoá lưu trữ dữ liệu theo mặc định tại thời điểm này người dùng đã hoàn tất quy trình thiết lập ngay lập tức.
[C-0-3] PHẢI đáp ứng quy trình mã hoá lưu trữ 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 mục 9.9.3.1.
- Mã hoá mức khối mỗi người dùng theo mô tả trong phần 9.9.3.2.

9.9.3. Phương thức mã hoá

Nếu quá trình triển khai thiết bị được mã hoá, thì các quá trình này sẽ:

[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 tính năng Khởi động trực tiếp truy cập vào bộ nhớ được mã hoá của thiết bị (DE) sau khi thông báo ACTION_LOCKED_BOOT_COMPLETED được phát đi.
[C-1-2] PHẢI chỉ cho phép truy cập vào bộ nhớ được mã hoá thông tin xác thực (CE) sau người dùng mở khoá thiết bị bằng cách cung cấp thông tin đăng nhập (ví dụ: mật mã, mã PIN, hình mở khoá hoặc vân tay) và ACTION_USER_UNLOCKED đã phát đi thông báo.
[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ệ theo tiêu chuẩn CE không có thông tin đăng nhập do người dùng cung cấp, khoá ký quỹ đã đăng ký hoặc tiếp tục khi triển khai khởi động lại, đáp ứng các yêu cầu trong mục 9.9.4.
[C-1-4] PHẢI sử dụng tính năng Xác minh quy trình khởi động.

9.9.3.1. Mã hoá dựa trên tệp bằng tính năng mã hoá siêu dữ liệu

Nếu các hoạt động triển khai thiết bị sử dụng Mã hoá dựa trên tệp với Mã hoá siêu dữ liệu, chúng:

[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 cách sử dụng AES-256-XTS hoặc Adiantum. AES-256-XTS là tiêu chuẩn mã hoá tiên tiến có độ dài khoá mật mã 256 bit, hoạt động ở chế độ XTS; toàn bộ thời lượng 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 của hệ thống tệp là các dữ liệu như tệp kích thước, quyền sở hữu, chế độ và thuộc tính mở rộng (xattr).
[C-1-6] PHẢI mã hoá tên tệp bằng AES-256-CBC-CTS, AES-256-HCTR2, hoặc Adiantum.
[C-1-12] Nếu thiết bị có Tiêu chuẩn mã hoá nâng cao (AES) (chẳng hạn như Tiện ích mật mã ARMv8 trên thiết bị dựa trên ARM, hoặc AES-NI trên thiết bị dựa trên x86) thì các tuỳ chọn dựa trên AES ở trên cho tên tệp, nội dung tệp và mã hoá siêu dữ liệu của hệ thống tệp PHẢI được sử dụng, không phải Adiantum.
[C-1-13] PHẢI sử dụng một khoá mạnh được mã hoá và không thể đảo ngược hàm dẫn xuất (ví dụ: HKDF-SHA512) để lấy bất kỳ khoá con nào cần thiết (ví dụ: khoá cho mỗi tệp) từ khoá CE và DE. "Mạnh mẽ về mặt mã hoá và không thể hoàn nguyên" có nghĩa là hàm dẫn xuất khoá có độ mạnh bảo mật tối thiểu 256 bit và hoạt động như một hàm giả ngẫu nhiên gia đình cho dữ liệu đầu vào.
[C-1-14] KHÔNG ĐƯỢC sử dụng cùng một khoá hoặc khoá con Mã hoá dựa trên tệp (FBE) cho nhiều mục đích mã hoá (ví dụ: cho cả mã hoá lẫn khoá phái sinh hoặc cho hai thuật toán mã hoá khác nhau).
[C-1-15] PHẢI đảm bảo rằng tất cả các khối nội dung tệp đã mã hoá chưa bị xoá trên bộ nhớ lưu trữ cố định đã được mã hoá bằng 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 kết hợp đó PHẢI khác biệt, ngoại trừ trường hợp quá trình mã hoá được thực hiện bằng phần cứng mã hoá cùng dòng 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á không bị xoá trên các giá trị cố định trong các thư mục riêng biệt được mã hoá bằng cách kết hợp riêng biệt khoá mã hoá và vectơ khởi tạo (IV).
[C-1-17] PHẢI đảm bảo rằng tất cả các khối siêu dữ liệu của hệ thống tệp đã mã hoá đang bật bộ nhớ liên tục được mã hoá bằng các tổ hợp khoá mã hoá riêng biệt và vectơ khởi tạo (IV).
Các khoá bảo vệ khu vực lưu trữ CE và DE cũng như siêu dữ liệu của hệ thống tệp:
- [C-1-7] PHẢI được liên kết bằng mật mã với Kho khoá dựa trên phần cứng. Kho khoá này PHẢI được liên kết với tính năng Xác minh quy trình khởi động và phần cứng của thiết bị gốc của niềm tin.
- [C-1-8] Các khoá CE PHẢI được liên kết với thông tin đăng nhập 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 mã mặc định khi người dùng có 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à khác biệt, nói cách khác là không có CE hoặc DE của người dù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 thuật toán mật mã được hỗ trợ, độ dài khoá và chế độ.
- [C-1-12] PHẢI được xoá một cách an toàn trong quá trình khoá và mở khoá trình tải khởi động như mô tả tại đây.
NÊN cài đặt sẵn các ứng dụng thiết yếu (ví dụ: Alarm, Phone, Messenger) Nhận biết chế độ Khởi động trực tiếp.

Dự án Nguồn mở Android ngược dòng cung cấp phương thức triển khai ưu tiên của Mã hoá dựa trên tệp dựa trên nhân hệ điều hành Linux "fscrypt" tính năng mã hoá, và Mã hoá siêu dữ liệu dựa trên nhân hệ điều hành Linux "dm-default-key" của chúng tôi.

9.9.3.2. Tính năng mã hoá cấp khối cho mỗi người dùng

Nếu quá trình triển khai thiết bị sử dụng phương thức mã hoá cấp khối cho mỗi người dùng, thì chúng:

[C-1-1] PHẢI bật chế độ hỗ trợ nhiều người dùng như mô tả trong mục 9.5.
[C-1-2] PHẢI cung cấp 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 khoá mã hoá duy nhất và riêng biệ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 người dùng phân vùng.
Các khoá bảo vệ thiết bị được mã hoá cấp khối cho mỗi người dùng:
- [C-1-5] PHẢI được liên kết bằng mật mã với Kho khoá dựa trên phần cứng. Kho khoá này PHẢI được liên kết với tính năng Xác minh quy trình khởi động và phần cứng của thiết bị gốc của niềm tin.
- [C-1-6] PHẢI được ràng buộc với màn hình khoá của người dùng tương ứng thông tin xác thực.

Có thể triển khai tính năng mã hoá cấp khối cho mỗi người dùng bằng nhân Linux "dm-crypt" trên phân vùng mỗi người dùng.

9.9.4. Tiếp tục khi khởi động lại

Tính năng Tiếp tục khi khởi động lại cho phép mở khoá bộ nhớ CE của tất cả ứng dụng, bao gồm cả những ứng dụng chưa hỗ trợ Direct Boot, sau khi khởi động lại do OTA thực hiện. Chiến dịch này cho phép người dùng nhận thông báo từ các ứng dụng đã cài đặt sau khi khởi động lại.

Việc triển khai tính năng Tiếp tục khi khởi động lại phải tiếp tục nhằm đảm bảo rằng khi một thiết bị rơi vào tay kẻ tấn công, điều đó vô cùng khó khăn để khôi phục dữ liệu đã mã hoá CE của người dùng, ngay cả khi thiết bị được cấp nguồn bộ nhớ CE được mở khoá và người dùng đã mở khoá thiết bị sau khi nhận được OTA. Đối với khả năng chống tấn công nội bộ, chúng ta cũng giả định rằng kẻ tấn công có được quyền truy cập để truyền các khoá ký mật mã.

Cụ thể:

[C-0-1] Bộ nhớ CE KHÔNG ĐƯỢC đọc được ngay cả đối với kẻ tấn công thực tế có thiết bị, sau đó có các khả năng và giới hạn sau:
- Có thể dùng khoá ký của bất kỳ nhà cung cấp hoặc công ty nào để ký tuỳ ý tin nhắn.
- Có thể khiến thiết bị nhận được OTA.
- Có thể sửa đổi hoạt động của bất kỳ phần cứng nào (AP, flash, v.v.), ngoại trừ nêu chi tiết bên dưới, nhưng việc sửa đổi đó đòi hỏi độ trễ ít nhất giờ và chu kỳ nguồn phá huỷ nội dung trong RAM.
- Không thể sửa đổi hoạt động của phần cứng chống can thiệp (ví dụ: Titan M).
- Không thể đọc RAM của thiết bị đang hoạt động.
- Không lấy được thông tin đăng nhập của người dùng (mã PIN, hình mở khoá, mật khẩu) hoặc nếu không hãy nhập mã.

Ví dụ: việc triển khai thiết bị sẽ triển khai và tuân thủ tất cả trong số 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 giúp đảm bảo tính minh bạch của trạng thái của 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 pháp API Hệ thống PersistentDataBlockManager.getFlashLockState() liệu trình tải khởi động của thiết bị có thể trạng thái cho phép cài đặt ROM hình ảnh hệ thống.
[C-0-2] PHẢI hỗ trợ Xác minh quy trình khởi động cho tính toàn vẹn của thiết bị.

Nếu đã khởi chạy các quá trình triển khai thiết bị mà không hỗ trợ tính năng Xác minh quy trình khởi động trên một phiên bản Android cũ hơn và không thể thêm hỗ trợ cho tính năng này có bản cập nhật phần mềm hệ thống, họ CÓ THỂ được miễn trừ khỏi .

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 thiết bị phần mềm. Nếu các quá trình triển khai theo thiết bị có hỗ trợ tính năng này, thì họ:

[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 xác minh trên 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á phần cứng không thể thay đổi là niềm tin và đi đến tậ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ã trong giai đoạn tiếp theo.
[C-1-5] PHẢI sử dụng các thuật toán xác minh mạnh như hiện tại các đề xuất của NIST về thuật toán băm (SHA-256) và khoá công khai kích thước (RSA-2048).
[C-1-6] KHÔNG ĐƯỢC cho phép hoàn tất quá trình khởi động khi xác minh hệ thống không thành công, trừ khi người dùng đồng ý vẫn thử khởi động. Trong trường hợp này, dữ liệu từ KHÔNG được sử dụng bất kỳ khối bộ nhớ chưa được xác minh nào.
[C-1-7] KHÔNG ĐƯỢC cho phép sửa đổi các phân vùng đã xác minh trên thiết bị trừ phi người dùng đã mở khoá trình tải khởi động một cách rõ ràng.
[C-1-8] PHẢI sử dụng bộ nhớ bằng chứng can thiệp: để lưu trữ xem trình tải khởi động đã được mở khoá. Bộ nhớ bằng chứng chống can thiệp có nghĩa là trình tải khởi động có thể phát hiện xem bộ nhớ có bị can thiệp từ bên trong Android hay không.
[C-1-9] PHẢI nhắc người dùng trong khi sử dụng thiết bị, và yêu cầu xác nhận vật lý trước khi cho phép chuyển đổi từ trình tải khởi động từ chế độ khoá sang chế độ mở khoá trình tải khởi động.
[C-1-10] PHẢI triển khai chức năng bảo vệ khôi phục cho các phân vùng do Android sử dụng (ví dụ: khởi động, phân vùng hệ thống) và sử dụng bộ nhớ phát hiện 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á trình tải khởi động và khóa, theo '9.12. Xoá dữ liệu (bao gồm cả phân vùng dữ liệu người dùng và bất kỳ không gian NVRAM nào).

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-SR-1] Nếu có nhiều chip rời rạc trong thiết bị (ví dụ: sóng vô tuyến, xử lý hình ảnh chuyên biệt), quá trình khởi động của mỗi chip đó là NÊN xác minh mọi giai đoạn sau khi khởi động.

[C-1-14] PHẢI xác minh chữ ký ít nhất một lần cho mỗi lần khởi động đối với danh sách cho phép các gói được liệt kê là require-strict-signature trong cấu hình hệ thống.

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

[C-SR-2] AreĐể xác minh tất cả các tệp APK ứng dụng có đặc quyền với một chuỗi tin cậy đã bị can thiệp vào hệ thống trong những 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] AreĐể xác minh mọi cấu phần phần mềm thực thi được tải bởi một ứng dụng có đặc quyền 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 biên dịch) trước khi thực thi chúng hoặc tôi ĐỀ XUẤT NÊN KHÔNG thực thi các mã đó nào.
NÊN triển khai tính năng bảo vệ khôi phục cho mọi thành phần có tính liên tục chương trình cơ sở (ví dụ: modem, máy ảnh) và NÊN sử dụng bộ nhớ bằng chứng can thiệp cho lưu trữ siêu dữ liệu dùng để xác định phiên bản tối thiểu được phép.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Nếu việc triển khai thiết bị đã được khởi chạy mà không hỗ trợ C-1-8 đến C-1-11 trên phiên bản Android cũ hơn và không thể thêm hỗ trợ cho những yêu cầu này với bản cập nhật phần mềm hệ thống, thì chúng CÓ THỂ được miễn trừ khỏi các yêu cầu liên quan.

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

Dự án nguồn mở Android ngược dòng cung cấp phương thức triển khai ưu tiên của tính năng này trong external/avb/ kho lưu trữ này có thể được tích hợp vào trình tải khởi động dùng để tải Android.

Liệu các quá trình triển khai thiết bị có thể xác minh tệp hay không nội dung trên cơ sở mỗi trang, thì chúng:

[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 cho phép đọc yêu cầu trên tệp được bảo vệ thành công khi nội dung không được đọc đượ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 quá trình triển khai thiết bị đã được khởi chạy mà không thể xác minh tệp nội dung dựa vào một khoá đáng tin cậy trên phiên bản Android cũ và không thể thêm hỗ trợ cho tính năng này bằng bản cập nhật phần mềm hệ thống, nên chúng CÓ THỂ được miễn trừ khỏi yêu cầu. Dự án nguồn mở Android ngược dòng cung cấp ưu tiên triển khai tính năng này dựa trên tính năng fs-verity của nhân hệ điều hành Linux.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

Triển khai thiết bị:

[C-SR-4] AreĐể hỗ trợ API Xác nhận bảo vệ của Android.

Nếu các phương thức triển khai thiết bị có hỗ trợ Xác nhận bảo vệ của Android API mà họ:

[C-3-1] PHẢI báo cáo true cho ConfirmationPrompt.isSupported() API.

[C-3-2] PHẢI đảm bảo rằng mã chạy trong hệ điều hành Android bao gồm nhân hệ điều hành, độc hại hay cách khác, không thể tạo phản hồi tích cực nếu không có tương tác của người dùng.

[C-3-3] PHẢI đảm bảo rằng người dùng có thể xem xét và phê duyệt ngay cả trong trường hợp hệ điều hành Android, bao gồm cả nhân hệ điều hành, bị xâm nhập.

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

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ữ khoá mã hoá trong một vùng chứa và sử dụng chúng trong các hoạt động mã hoá thông qua KeyChain API hoặc API Kho khoá. 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] Xác thực màn hình khoá PHẢI triển khai khoảng thời gian giữa các lần thử 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 cho 9 < không < 30. Đối với n > 29, giá trị khoảng thời gian PHẢI tối thiểu là 30*2^floor((n-30)/10)) giây hoặc ít nhất là 24 giờ, tuỳ theo mức nào nhỏ hơn.
Không được giới hạn số lượng khoá có thể tạo.

Khi quá trình triển khai thiết bị hỗ trợ màn hình khoá bảo mật, quá trình triển khai sẽ:

[C-1-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một thuộc tính tách biệt môi trường thực thi.
[C-1-2] PHẢI triển khai RSA, AES, ECDSA, ECDH (nếu IKeyMintDevice được hỗ trợ), 3DES, và các thuật toán mật mã HMAC và hàm băm họ MD5, SHA-1 và SHA-2 có chức năng hỗ trợ đúng cách hệ thống Kho khoá Android được hỗ trợ các thuật toán mã hóa trong khu vực được tách biệt an toàn với mã chạy trên nhân hệ điều hành trở lên. Cách ly an toàn PHẢI chặn mọi cơ chế tiềm ẩn theo đó nhân hệ điều hành hoặc mã không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Nguồn mở Android ngược dòng Dự án (AOSP) đáp ứng yêu cầu này bằng cách sử dụng Việc triển khai Đáng tin cậy, nhưng một giải pháp dựa trên ARM TrustZone khác hoặc một giải pháp của bên thứ ba đã được đánh giá là có bảo mật việc triển khai cách ly thích hợp dựa trên trình điều khiển ảo hoá là một phương án thay thế .
[C-1-3] PHẢI thực hiện xác thực màn hình khoá trong môi trường thực thi và chỉ khi thành công mới cho phép ràng buộc xác thực các khoá sẽ sử dụng. Thông tin đăng nhập màn hình khoá PHẢI được lưu trữ trong phương thức chỉ cho phép môi trường thực thi tách biệt mới thực hiện màn hình khoá xác thực. Dự án nguồn mở Android ngược dòng cung cấp Lớp trừu tượng phần cứng (HAL) cho người trực điện thoại và Trusty. Các công cụ này có thể được dùng để đáp ứng yêu cầu này.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-4] PHẢI hỗ trợ chứng thực khoá trong đó khoá ký chứng thực là được bảo vệ bằng phần cứng bảo mật và việc ký được thực hiện trong phần cứng bảo mật. Khoá ký chứng thực PHẢI ~~được dùng chung trên số lượng thiết bị đủ lớn để ngăn chặn khoá~~ bị ngăn chặn khỏi việc được sử dụng vĩnh viễn mã nhận dạng thiết bị.

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 cụ thể trừ khi tại tối thiểu 100.000 đơn vị ~~một~~ mà SKU được tạo. Nếu có hơn 100.000 đơn vị trên an đó SKU được tạo ra, CÓ THỂ sử dụng khoá khác cho từng nhóm 100.000 đơn vị sau đó. Ngoài ra, giải pháp Cấp phép khoá từ xa có thể được dùng để cung cấp các dịch vụ khoá chứng thực cho thiết bị.

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

[C-1-5] PHẢI cho phép người dùng chọn thời gian chờ Chế độ ngủ để chuyển đổi từ đã mở khoá sang trạng thái khoá, với thời gian chờ tối thiểu cho phép lên tới 15 giây. Thiết bị Automotive giúp khoá màn hình bất cứ khi nào đầu phát trung tâm bị tắt hoặc người dùng bị chuyển đổi, CÓ THỂ KHÔNG có thời gian chờ Ngủ .
[C-1-6] PHẢI hỗ trợ một trong các chức năng sau:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice phiên bản 1, hoặc
- IKeyMintDevice phiên bản 2.
[C-SR-1] Is mã ĐỀ XUẤT NÊN hỗ trợ IKeyMintDevice phiên bản 1.

9.11.1. Màn hình khoá bảo mật, hoạt động xác thực và thiết bị ảo

Việc triển khai AOSP tuân theo một mô hình xác thực theo cấp trong đó phương pháp xác thực chính dựa trên cơ sở kiến thức có thể được hỗ trợ bởi sinh trắc học mạnh thứ hai hoặc theo phương thức bậc ba yếu hơn.

Triển khai thiết bị:

[C-SR-1] Are Để chỉ định một trong các thông tin sau làm phương thức xác thực chính phương thức:
- Mã PIN dạng số
- Mật khẩu gồm chữ và số
- Hình mở khoá trên một lưới gồm 3x3 chấm
  
  Lưu ý rằng các phương pháp xác thực ở trên được gọi là phương pháp xác thực chính 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] Giới hạn trên không được đề xuất để triển khai giới hạn trên là 20 lần thử xác thực chính và liệu người dùng có đồng ý và chọn sử dụng tính năng nà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 kết quả chính không thành công lần thử xác thực.

Nếu quá trình triển khai thiết bị có đặt mã PIN dạng số làm mã PIN chính được đề xuất xác thực, thì:

[C-SR-6] A PIN is phong phú NÊN DÙNG có ít nhất 6 chữ số, hoặc tương đương với một entropy 20 bit.
[C-SR-7] Mã PIN có độ dài nhỏ hơn 6 chữ số là tôi đưa ra mã khuyến nghị NOT để cho phép nhập tự động mà không cần người dùng phải tương tác để tránh tiết lộ mã PIN thời lượng.

Liệu các phương pháp triển khai thiết bị có thêm hoặc sửa đổi phương thức xác thực chính được đề xuất hay không và sử dụng một phương pháp xác thực mới như một cách an toàn để khoá màn hình, phương pháp xác thực mới:

[C-2-1] PHẢI là phương thức xác thực người dùng như được mô tả trong Yêu cầu xác thực người dùng để sử dụng khoá.

Nếu quá trình triển khai thiết bị có thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khoá (nếu dựa trên khoá bí mật đã biết) và dùng một phương thức xác thực mới để được coi là cách an toàn để khoá màn hình:

[C-3-1] Entropy của độ dài ngắn nhất được phép của đầu vào PHẢI là lớn hơn 10 bit.
[C-3-2] Entropy tối đa của tất cả đầu vào có thể có PHẢI lớn hơn 18 bit.
[C-3-3] Phương pháp xác thực mới KHÔNG ĐƯỢC thay thế bất kỳ phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) được triển khai và cung cấp trong AOSP (Dự án nguồn mở Android).
[C-3-4] Phương pháp xác thực mới PHẢI được tắt khi Ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt mật khẩu thông qua DevicePolicyManager.setrequiredPasswordComplexity() có hằng số phức tạp hạn chế hơn Mật_đa_phép_hiển_thị_PHPITY_NONE hoặc thông qua DevicePolicyManager.setPasswordQuality() có hằng số hạn chế hơn Password_ trùng_bioMETRIC_WEAK.
[C-3-5] Các phương thức xác thực mới PHẢI hoặc là thuộc về phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, một lần) mỗi 72 giờ trở xuống HOẶC tiết lộ rõ ràng cho cho người dùng rằng một số dữ liệu sẽ không được sao lưu để bảo vệ tính riêng tư cho dữ liệu của họ.

Liệu các phương pháp triển khai thiết bị có thêm hoặc sửa đổi phương thức xác thực chính được đề xuất hay không để mở khóa màn hình khóa và sử dụng một phương pháp xác thực mới dựa trên sinh trắc học để được coi là một cách an toàn để khoá màn hình, phương thức:

[C-4-1] PHẢI đáp ứng tất cả các yêu cầu được mô tả trong section 7.3.10 cho Loại 1 (trước đây là Thuận tiện).
[C-4-2] PHẢI có cơ chế dự phòng để sử dụng một trong các cơ chế được đề xuất phương thức xác thực chính dựa trên một khoá bí mật đã biết.
[C-4-3] PHẢI được tắt và chỉ cho phép thành phần chính được đề xuất xác thực để mở khoá màn hình khi Trình kiểm soát chính sách thiết bị (DPC) ứng dụng đã đặt chính sách về tính năng bảo vệ bàn phím bằng cách gọi phương thức DevicePolicyManager.setKeyguardDisabledFeatures()! với bất kỳ cờ sinh trắc học nào có liên quan (ví dụ: KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE hoặc KEYGUARD_DISABLE_IRIS).

Nếu phương pháp xác thực bằng sinh trắc học không đáp ứng yêu cầu đối với Loại 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 được tắt nếu Trình điều khiển chính sách thiết bị (DPC) ứng dụng đã đặt chính sách chất lượng đối với yêu cầu về mật khẩu qua phương thức DevicePolicyManager.setrequiredPasswordComplexity() có bộ chứa độ phức tạp hạn chế hơn PASSWORD_COMPLEXITY_LOW hoặc dùng DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn so với PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] Người dùng PHẢI được thử thách là lựa chọn chính xác thực (ví dụ: mã PIN, hình mở khoá, mật khẩu) như được mô tả trong [C-1-7] và [C-1-8] trong mục 7.3.10.
[C-5-3] Các phương thức KHÔNG ĐƯỢC coi là màn hình khoá an toàn, và PHẢI đáp ứng các yêu cầu bắt đầu bằng C-8 trong phần dưới đây.

Nếu quá trình triển khai thiết bị có thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khoá và một phương pháp xác thực mới dựa trên mã thông báo vật lý hoặc vị trí:

[C-6-1] Họ PHẢI có cơ chế dự phòng để sử dụng một trong các phương pháp được khuyến nghị phương pháp xác thực chính dựa trên một bí mật đã biết và đáp ứng các yêu cầu để được coi là màn hình khoá an toàn.
[C-6-2] Phương thức mới PHẢI được tắt và chỉ cho phép một trong phương pháp xác thực chính được đề xuất để mở khóa 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 là:
- Chiến lược phát hành đĩa đơn DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) phương thức
- Chiến lược phát hành đĩa đơn DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn so với PASSWORD_QUALITY_NONE.
- DevicePolicyManager.setRequiredPasswordComplexity() có bộ chứa độ phức tạp hạn chế hơn so với PASSWORD_COMPLEXITY_NONE.
[C-6-3] Người dùng PHẢI được thử thách là một trong các địa điểm chính được đề xuất phương pháp xác thực (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất một lần mỗi Tối đa 4 giờ. Khi mã thông báo thực đáp ứng yêu cầu đối với việc triển khai TrustAgent trong C-X, các hạn chế về thời gian chờ được xác định trong C-9-5 áp dụng thay thế.
[C-6-4] Phương thức mới KHÔNG ĐƯỢC coi là màn hình khoá an toàn và PHẢI tuân theo những ràng buộc được liệt kê trong C-8 dưới đây.

Nếu quá trình triển khai thiết bị có màn hình khoá bảo mật và có một hoặc nhiều tác nhân tin cậy triển khai API hệ thống TrustAgentService, chúng:

[C-7-1] PHẢI có chỉ báo rõ ràng trong trình đơn cài đặt và trên khoá màn hình khi phương thức khoá thiết bị bị trì hoãn hoặc có thể được mở khoá bởi(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ả dạng văn bản cho "chế độ cài đặt Tự động khoá" và "Nút nguồn khoá tức thì" trong trình đơn cài đặt và một biểu tượng dễ phân biệt trên màn hình khoá.
[C-7-2] PHẢI tôn trọng và triển khai đầy đủ tất cả các API tác nhân tin cậy trong DevicePolicyManager, chẳng hạn như KEYGUARD_DISABLE_TRUST_AGENTS hằng số.
[C-7-3] KHÔNG ĐƯỢC triển khai đầy đủ TrustAgentService.addEscrowToken() hoạt động trên một thiết bị dùng làm thiết bị cá nhân chính (ví dụ: thiết bị cầm tay) nhưng CÓ THỂ triển khai đầy đủ chức năng này trên thiết bị những cách triển khai thường được chia sẻ (ví dụ: Android TV hoặc Thiết bị trên Automotive).
[C-7-4] PHẢI mã hoá tất cả các mã thông báo được lưu trữ được thêm bởi TrustAgentService.addEscrowToken().
[C-7-5] KHÔNG ĐƯỢC lưu trữ khoá mã hoá hoặc mã thông báo uỷ thác trên trên cùng một thiết bị mà khoá được sử dụng. Ví dụ: trường hợp này được phép một khoá được lưu trữ trên điện thoại để mở khoá một tài khoản người dùng trên TV. Đối với các thiết bị Automotive, không cho phép lưu trữ mã thông báo ký quỹ 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 hệ quả bảo mật trước khi bật 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 cơ chế được khuyến nghị phương thức xác thực chính.
[C-7-9] Người dùng PHẢI được thử thách là một trong các địa điểm chính được đề xuất các phương pháp xác thực (ví dụ: mã PIN, hình mở khoá, mật khẩu) như được mô tả trong [C-1-7] và [C-1-8] trong mục 7.3.10, trừ phi có sự an toàn của người dùng (ví dụ: sự mất tập trung của người lái xe) là mối quan tâm.
[C-7-10] KHÔNG ĐƯỢC coi là màn hình khoá an toàn và PHẢI tuân theo các điều kiện ràng buộc được liệt kê trong C-8 bên dưới.
[C-7-11] KHÔNG ĐƯỢC cho phép TrustAgents trên các thiết bị cá nhân chính (ví dụ: thiết bị cầm tay) để mở khoá thiết bị và chỉ có thể sử dụng thiết bị để giữ thiết bị đã mở khoá ở trạng thái đã mở khoá trong tối đa 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 mã hoá bảo mật (ví dụ: UKEY2) kênh liên lạc để chuyển mã thông báo uỷ thác từ bộ nhớ lưu trữ đến thiết bị mục tiêu.

Nếu quá trình triển khai thiết bị có thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khóa không phải là màn hình khóa an toàn như được mô tả ở trên và sử dụng một phương pháp xác thực mới để mở khoá tính năng bảo vệ bàn phím:

[C-8-1] Phương thức mới PHẢI được tắt khi 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 DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn so với PASSWORD_QUALITY_NONE hoặc qua DevicePolicyManager.setRequiredPasswordComplexity() có hằng số phức tạp hạn chế hơn "passwords_CONTAINERITY_NONE".
[C-8-2] Họ KHÔNG ĐƯỢC đặt lại các đồng hồ hẹn giờ hết hạn mật khẩu do họ thiết lập DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Họ KHÔNG ĐƯỢC hiển thị API để các ứng dụng bên thứ ba sử dụng thay đổi trạng thái khoá.

Nếu quá trình triển khai thiết bị cho phép các ứng dụng tạo màn hình ảo và không hỗ trợ các sự kiện đầu vào được liên kết, chẳng hạn như qua VirtualDeviceManager! chúng:

[C-9-1] PHẢI khoá(các) màn hình ảo phụ này khi thiết bị màn hình mặc định được 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 quá trình triển khai thiết bị cho phép ứng dụng tạo màn hình ảo phụ và hỗ trợ đầu vào được liên kết các sự kiện, chẳng hạn như qua VirtualDeviceManager, họ:

[C-10-1] PHẢI hỗ trợ trạng thái khoá riêng biệt cho mỗi thiết bị ảo
[C-10-2] PHẢI ngắt kết nối tất cả các thiết bị ảo khi hết thời gian chờ ở trạng thái rảnh
[C-10-3] PHẢI có thời gian chờ ở trạng thái rảnh
[C-10-4] PHẢI khoá tất cả màn hình khi người dùng bắt đầu chặn, bao gồm thông qua khả năng tương tác khoá người dùng cần thiết đố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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-10-6] PHẢI vô hiệu hoá ~~việc tạo đầu vào được liên kết sự kiện qua VirtualDeviceManager khi được chỉ định bằng cách~~ phát trực tuyến ứng dụng dưới dạng biểu thị bằng DevicePolicyManager.setNearbyAppStreamingPolicy.

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

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-10-7] PHẢI hoặc:
- Tắt chế độ sử dụng bảng nhớ tạm
- Bật bảng nhớ tạm riêng cho từng thiết bị hỗ trợ bảng nhớ tạm

~~[C-10-7] PHẢI sử dụng một bảng nhớ tạm riêng chỉ cho từng thiết bị ảo (hoặc tắt bảng nhớ tạm cho các thiết bị ảo)~~

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

[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 nhập hệ số kiến thức và lời nhắc sinh trắc học

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

~~[C-10-12] PHẢI hạn chế các ý định được khởi tạo từ một thiết bị ảo để hiển thị chỉ trên cùng một thiết bị ảo~~

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

[C-10-13] KHÔNG ĐƯỢC sử dụng trạng thái khoá thiết bị ảo khi xác thực người dùng uỷ quyền với Hệ thống kho khoá Android. Xem KeyGenParameterSpec.Builder.setUserAuthentication*.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-10-14] PHẢI cung cấp thuộc tính tương tác cho người dùng để bật tính năng chia sẻ bảng nhớ tạm giữa thiết bị trước khi chia sẻ dữ liệu trong bảng nhớ tạm giữa 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 truy cập vào dữ liệu bảng nhớ tạm trên thiết bị nào khác và PHẢI khiến nội dung không thể truy cập được sau một phút được đo từ thời gian chia sẻ ban đầu.

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

Khi quá trình triển khai thiết bị cho phép người dùng chuyển yếu tố tri thức xác thực từ một thiết bị nguồn đến một thiết bị mục tiêu, chẳng hạn như trong quá trình thiết lập ban đầu cho thiết bị mục tiêu, chúng:

[C-11-1] PHẢI mã hoá yếu tố kiến thức có đảm bảo bảo vệ tương tự như những gì được mô tả trong Dịch vụ Google Cloud Key Vault sách trắng về bảo mật khi chuyển hệ số tri thức từ thiết bị nguồn đến thiết bị mục tiêu sao cho không thể giải mã hoặc dùng yếu tố tri thức từ xa để mở khoá từ xa cả 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ố tri thức của thiết bị nguồn trước khi chuyển hệ số tri thức với thiết bị mục tiêu.
[C-11-3] PHẢI, trên thiết bị mục tiêu thiếu bất kỳ phương thức xác thực chính nào đã đặt yếu tố tri thức, hãy yêu cầu người dùng xác nhận một yếu tố kiến thức được chuyển giao thiết bị mục tiêu trước khi đặt hệ số tri thức đó làm yếu tố chính yếu tố kiến thức xác thực cho thiết bị mục tiêu và trước khi thực hiện truy cập được mọi dữ liệu được chuyển từ thiết bị nguồn.

Nếu quá trình triển khai thiết bị có màn hình khoá bảo mật và có một hoặc nhiều tác nhân tin cậy, gọi API Hệ thống TrustAgentService.grantTrust() bằng FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE sẽ gắn cờ họ:

[C-12-1] Chỉ được gọi grantTrust() bằng cờ khi được kết nối với 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ọ dựa trên màn hình khoá đó. Các thiết bị proxy có thể sử dụng cơ chế phát hiện trên đồng hồ hoặc trên cơ thể sau khi người dùng mở khoá một lần để đáp ứng yêu cầu xác thực người dùng.
[C-12-2] PHẢI đưa phương thức triển khai thiết bị vào TrustState.TRUSTABLE trạng thái khi màn hình tắt (chẳng hạn như qua thao tác nhấn nút hoặc hiển thị) hết thời gian chờ) và TrustAgent chưa thu hồi độ tin cậy. AOSP đáp ứng yêu cầu này.
[C-12-3] Chỉ được di chuyển thiết bị từ TrustState.TRUSTABLE sang Trạng thái của TrustState.TRUSTED nếu TrustAgent vẫn đang cấp độ tin cậy dựa trên các yêu cầu trong C-12-1.
[C-12-4] PHẢI gọi TrustManagerService.revokeTrust()
- Sau tối đa 24 giờ kể từ khi cấp tin cậy, hoặc
- Sau 8 giờ ở trạng thái không hoạt động, hoặc
- Nếu các hoạt động triển khai không sử dụng phương thức bảo mật được mã hoá và chính xác trong phạm vi được định nghĩa trong [C-12-5], khi kết nối cơ bản với thiết bị thực gần nhất bị mất.
[C-12-5] Việc triển khai dựa trên phạm vi bảo mật và chính xác để đáp ứng các yêu cầu của [C-12-4] PHẢI sử dụng một trong các giải pháp sau:
- Triển khai bằng UWB:
  - PHẢI đáp ứng các yêu cầu về tuân thủ, chứng nhận, chính xác và yêu cầu 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ó trong 7.4.9.
- Triển khai bằng mạng Wi-Fi vùng lân cận (NAN):
  - PHẢI đáp ứng các yêu cầu về độ chính xác trong 2.2.1 [7.4.2.5/H-SR-1], sử dụng băng thông 160 MHz (hoặc cao hơn) và làm theo các bước thiết lập tính năng đo lường được chỉ định trong Hiệu chỉnh sự có mặt.
  - PHẢI sử dụng Secure LTF như định nghĩa trong IEEE 802.11az.

Nếu quá trình triển khai thiết bị cho phép ứng dụng tạo màn hình ảo phụ và hỗ trợ đầu vào được liên kết các sự kiện như qua VirtualDeviceManager và các màn hình không được đánh dấu bằng VIRTUAL_DISPLAY_FLAG_SECURE, chúng:

[C-13-8] PHẢI chặn hoạt động bằng 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 để bắt đầu trên máy ảo thiết bị.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-13-9] PHẢI block Hoạt động không cho phép phát trực tuyến và cho biết các quảng cáo này cho thấy nội dung nhạy cảm, bao gồm cả thông qua SurfaceView#setSecure, và FLAG_SECURE~~hoặc HỆ THỐNG_FLAG_STORE_NON_SYSTEM_OVERLAY_WINDOWS,~~ bắt đầu trên thiết bị ảo.

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

Nếu quá trình triển khai thiết bị hỗ trợ trạng thái nguồn cho 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, họ:

[C-SR-2] Giới hạn định dùng để sử dụng cuộc họp thông tin xác thực các yêu cầu được xác định trong mục 9.11.1 hoặc yêu cầu về Sinh trắc học ít nhất Các thông số kỹ thuật Loại 1 được định nghĩa trong mục 7.3.10 để cho phép các thông số kỹ thuật độc lập. đang mở khoá từ màn hình mặc định của thiết bị.
[C-SR-3] AreĐể giới thiệu về 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] Are trì hoãn phát hành để cho phép người dùng khoá toàn bộ tất cả các màn hình thông qua tính năng khoá từ thiết bị cầm tay chính.

9.11.2. StrongBox

Hệ thống kho khoá Android cho phép lưu trữ khoá mã hoá trong một bộ xử lý bảo mật chuyên dụng dưới dạng cũng như môi trường thực thi tách biệt được mô tả ở trên. Đúng là bộ xử lý bảo mật chuyên dụng có tên là "StrongBox". Các yêu cầu C-1-3 thông qua C-1-11 dưới đây 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.

Triển khai thiết bị có bộ xử lý bảo mật chuyên dụng:

[C-SR-1] Are Internet ĐỀ XUẤT NÊN hỗ trợ StrongBox. StrongBox sẽ có thể trở thành một yêu cầu đối với bản phát hành sau này.

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

[C-1-1] PHẢI khai báo FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] PHẢI cung cấp phần cứng bảo mật chuyên dụng dùng để quay lại kho khoá và phương thức xác thực người dùng an toàn. Dịch vụ bảo mật chuyên dụng phần cứng cũng có thể được sử dụng cho các mục đích khác.
[C-1-3] PHẢI có một CPU rời không dùng chung bộ nhớ đệm, DRAM, bộ đồng xử lý hoặc các tài nguyên cốt lõi khác với bộ xử lý ứng dụng (AP).
[C-1-4] PHẢI đảm bảo rằng mọi thiết bị ngoại vi được chia sẻ với AP đều không thể thay đổi StrongBox xử lý theo bất kỳ cách nào hoặc lấy thông tin bất kỳ 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ồ bên trong với độ chính xác hợp lý (+-10%) mà 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 được phân phối đồng đều và khó đoán.
[C-1-7] PHẢI có khả năng chống can thiệp, bao gồm cả khả năng chống lại thâm nhập vật lý và trục trặc.
[C-1-8] PHẢI có điện trở kênh bên, bao gồm cả điện trở chống lại rò rỉ thông tin qua nguồn điện, thời gian, bức xạ điện từ và nhiệt kênh phía bức xạ.
[C-1-9] PHẢI có bộ nhớ an toàn để đảm bảo tính bí mật, tính toàn vẹn, chân thực, nhất quán và mới mẻ . KHÔNG ĐƯỢC PHÉP đọc hay thay đổi bộ nhớ, ngoại trừ khi được API StrongBox cho phép.
Để xác thực việc tuân thủ [C-1-3] đến [C-1-9], thiết bị cách triển khai:

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

[C-1-10] PHẢI bao gồm phần cứng được chứng nhận theo Cấu hình bảo vệ IC bảo mật BSI-CC-PP-0084-2014 hoặc BSI-CC-PP-0117-2022, hoặc là đánh giá bởi một phòng thí nghiệm xét nghiệm được quốc gia công nhận, có tích hợp Đánh giá lỗ hổng bảo mật có nguy cơ bị tấn công ở mức cao theo Tiêu chí chung áp dụng tiềm năng tấn công để Thẻ thông minh.

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

[C-1-11] PHẢI bao gồm chương trình cơ sở được đánh giá bởi phòng thí nghiệm được công nhận quốc gia kết hợp mức độ tấn công cao theo Tiêu chí chung áp dụng khả năng tấn công cho thẻ thông minh.
[C-SR-2] Giới hạn định dạng khuyến khích dùng để bao gồm phần cứng đánh giá theo Mục tiêu bảo mật, Mức độ đảm bảo đánh giá (EAL) 5, được tăng cường bởi AVA_VAN.5. Chứng chỉ EAL 5 sẽ có thể trở thành yêu cầu bắt buộc trong bản phát hành sau này.
[C-SR-3] Are Internet ĐỀU ĐƯỢC ĐỀ XUẤT để cung cấp khả năng chống tấn công nội bộ (IAR), nghĩa là người nội bộ có quyền truy cập vào tính năng ký chương trình cơ sở các phím không thể tạo chương trình cơ sở khiến StrongBox bị rò rỉ để né tránh các yêu cầu về 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. Phương pháp đề xuất để triển khai IAR chỉ cho phép các bản 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. Chứng chỉ danh tính

Hệ thống thông tin xác thực danh tính được xác định và đạt được bằng cách triển khai tất cả API trong 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 danh tính người dùng tài liệu. Triển khai thiết bị:

[C-SR-1] are Still NÊN triển khai thông tin xác thực danh tính Hệ thống.

Nếu các hoạt động triển khai thiết bị có triển khai Hệ thống thông tin xác thực danh tính, thì các hoạt động này sẽ:

[C-1-1] PHẢI trả về giá trị không rỗng cho IdentityCredentialStore#getInstance() .
[C-1-2] PHẢI triển khai Hệ thống thông tin xác thực danh tính (ví dụ: android.security.identity.* API) có mã giao tiếp với ứng dụng trong một khu vực được tách biệt an toàn với mã chạy trên nhân hệ điều hành trở lên. Cách ly an toàn PHẢI chặn mọi cơ chế tiềm ẩn theo đó nhân hệ điều hành hoặc mã không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA.
[C-1-3] Các thao tác mã hoá cần thiết để triển khai Mã nhận dạng Hệ thống thông tin xác thực (ví dụ: API android.security.identity.*) PHẢI là được thực hiện hoàn toàn trong ứng dụng đáng tin cậy và tài liệu khoá riêng tư PHẢI không bao giờ rời khỏi môi trường thực thi tách biệt trừ phi có yêu cầu cụ thể bằng API cấp cao hơn (ví dụ: createEphemeralKeyPair() ).
[C-1-4] Ứng dụng đáng tin cậy PHẢI được triển khai sao cho nó thuộc tính bảo mật không bị ảnh hưởng (ví dụ: dữ liệu thông tin xác thực không được phát hành Nếu các điều kiện kiểm soát truy cập không được thoả mãn, thì không thể tạo MAC cho dữ liệu tuỳ ý) ngay cả khi Android đang hoạt động không đúng cách hoặc bị xâm phạm.

Dự án nguồn mở Android ngược dòng cung cấp một tệp tham chiếu triển khai một ứng dụng đáng tin cậy (libeic) có thể dùng để triển khai hệ thống Chứng chỉ danh tính.

9,12. Xóa dữ liệu

Tất cả cách triển khai thiết bị:

[C-0-1] PHẢI cung cấp cho người dùng cơ chế để thực hiện "Đặ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 "Đặ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 phù hợp để đáp ứng yêu cầu theo các tiêu chuẩn ngành như NIST SP800-88 khi biểu diễn "Dữ liệu nhà máy". Đặt lại".
[C-0-4] PHẢI kích hoạt lệnh "Thiết lập lại dữ liệu gốc" ở trên khi DevicePolicyManager.wipeData() API được gọi bởi ứng dụng Trình kiểm soát chính sách thiết bị của người dùng chính.
CÓ THỂ cung cấp tuỳ chọn xoá sạch dữ liệu nhanh chóng, chỉ tiến hành xoá dữ liệu logic.

9,13. Chế độ khởi động an toàn

Android cung cấp Chế độ khởi động an toàn, cho phép người dùng khởi động vào một chế độ trong đó chỉ cho phép chạy các ứng dụng hệ thống được cài đặt trước và tất cả các ứng dụng bên thứ ba ứng dụng bị tắt. Chế độ này còn được gọi là "Chế độ khởi động an toàn", cung cấp cho người dùng khả năng gỡ cài đặt các ứng dụng bên thứ ba có khả năng gây hại.

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

[C-SR-1] tôi ĐỀ XUẤT 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ác quá trình này sẽ:

[C-1-1] PHẢI cung cấp cho người dùng một tuỳ chọn để truy cập Chế độ khởi động an toàn theo cách không bị gián đoạn từ bên thứ ba các ứng dụng đã 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 UserManager.DISALLOW_SAFE_BOOT gắn cờ là 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 của bên thứ ba trong Chế độ an toàn.
NÊN cung cấp cho người dùng tuỳ chọn để vào Chế độ khởi động an toàn từ khởi động bằng cách sử dụ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 được dự kiến sẽ trao đổi dữ liệu với xe quan trọng hệ thống phụ bằng cách sử dụng HAL xe để gửi và nhận thông báo qua mạng xe, chẳng hạn như xe buýt CAN.

Việc trao đổi dữ liệu có thể được bảo mật bằng cách triển khai các tính năng bảo mật dưới đây Các lớp khung Android để ngăn chặn hoạt động tương tác độc hại hoặc không chủ ý với các hệ thống phụ này.

9,15. Gói thuê bao

"Gói thuê bao" tham khảo thông tin chi tiết về gói quan hệ thanh toán được cung cấp của một nhà mạng di động thông qua SubscriptionManager.setSubscriptionPlans().

Tất cả cách triển khai thiết bị:

[C-0-1] Chỉ trả về các gói thuê bao cho ứng dụng của nhà mạng di động đã cung cấp chúng ban đầu.
[C-0-2] KHÔNG ĐƯỢC sao lưu hoặc tải gói thuê bao từ xa lên.
[C-0-3] PHẢI chỉ cho phép ghi đè, chẳng hạn như SubscriptionManager.setSubscriptionOverrideCongested()! từ ứng dụng của nhà mạng di động hiện đang cung cấp các gói thuê bao hợp lệ.

9,16. Di chuyển dữ liệu ứng dụng

Nếu quá trình triển khai thiết bị có bao gồm 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 thành dữ liệu được định cấu hình bởi nhà phát triển ứng dụng trong tệp kê khai qua android:fullBackupContent , chúng:

[C-1-1] KHÔNG ĐƯỢC khởi tạo quá trình chuyển dữ liệu ứng dụng từ các thiết bị mà người dùng chưa thiết lập phương thức xác thực chính được mô tả trong 9.11.1 Màn hình khoá bảo mật và Xác thực.
[C-1-2] PHẢI xác nhận phương thức xác thực chính trên nguồn một cách an toàn thiết bị và xác nhận với ý định của người dùng để sao chép dữ liệu trên nguồn thiết bị của bạ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 cả hai nguồn và thiết bị mục tiêu trong quá trình di chuyển từ thiết bị này sang thiết bị khác là trên các thiết bị Android hợp lệ và có trình tải khởi động bị khoá.
[C-1-4] PHẢI chỉ 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 hiển thị chỉ báo rằng thiết bị nguồn có dữ liệu do quá trình di chuyển dữ liệu giữa các thiết bị trong trình đơn cài đặt di chuyển. Một người dùng KHÔNG ĐƯỢC PHÉP xoá chỉ báo này.

Bắt đầu các yêu cầu mới cho 15 (thử nghiệm AOSP)

9,17. Khung ảo hoá Android

API Khung ảo hoá Android (AVF) (android.system.virtualmachine.*) hỗ trợ cả Máy ảo được bảo vệ (pVM) và Máy ảo không được bảo vệ (không phải pVM) tuân theo các thuộc tính hệ thống sau:

Nếu bạn đặt ro.boot.hypervisor.vm.supported thành true thì các trình duyệt không phải pVM sẽ được hỗ trợ.

Nếu bạn đặt ro.boot.hypervisor.protected_vm.supported thành true thì pVM sẽ được được hỗ trợ.

Triển khai thiết bị:

[C-0-1] PHẢI hỗ trợ Android Virtualization Framework API (API Khung ảo hoá Android) (android.system.virtualmachine.*) đối với pVM, không phải pVM và sự tồn tại của cả hai.

~~Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android API Khung ảo hoá (android.system.virtualmachine.*),~~ Máy chủ Android:

~~[C-1-1] PHẢI hỗ trợ tất cả API được xác định bởi Gói android.system.virtualmachine.~~

[C-0-2] ~~[C-1-2]~~ KHÔNG ĐƯỢC sửa đổi Android SELinux và mô hình cấp quyền cho quản lý ~~Protected~~ Máy ảo(~~pVM~~) cả pVM và không phải pVM).
[C-0-4] ~~[C-1-4]~~ PHẢI chỉ cho phép mã đã ký trên nền tảng & ~~đặc quyền~~ các ứng dụng được cài đặt trước trong phân vùng chỉ đọc để tạo và chạy ~~pVM~~ máy ảo. Lưu ý: Điều này có thể thay đổi trong các bản phát hành Android sau này.
[C-0-5] ~~[C-1-5]~~ PHẢI chỉ cho phép pVM không thể gỡ lỗi thực thi mã từ nhà máy hoặc các cập nhật nền tảng của họ, bao gồm cả thông tin cập nhật về ~~đặc quyền~~ được cài đặt trước của chúng tôi.

~~Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android Virtualization Framework API (android.system.virtualmachine.*), sau đó là~~ Mọi phiên bản pVM:

[C-0-6] ~~[C-2-1]~~ PHẢI chạy được mọi hệ điều hành có trong quy trình ảo hoá APEX trong pVM.
[C-0-7] ~~[C-2-2]~~ KHÔNG ĐƯỢC cho phép pVM chạy hệ điều hành không được ký bởi trình triển khai thiết bị hoặc nhà cung cấp hệ điều hành.
[C-0-8] ~~[C-2-3]~~ KHÔNG ĐƯỢC cho phép pVM thực thi dữ liệu dưới dạng mã (ví dụ: SELinux Neverallow execmem).
[C-0-9] ~~[C-2-5]~~ PHẢI triển khai cơ chế bảo vệ theo chiều sâu pVM (ví dụ: SELinux cho pVM) ngay cả dành cho hệ điều hành không phải Microdroid.
[C-0-10] ~~[C-2-6]~~ PHẢI đảm bảo rằng pVM không khởi động được nếu hình ảnh mà máy ảo sẽ không chạy được được xác minh. Quá trình xác minh PHẢI được thực hiện bên trong máy ảo.
[C-0-11] ~~[C-2-7]~~ PHẢI đảm bảo rằng pVM không khởi động được nếu tính toàn vẹn củaInstance.img bị xâm nhập.

~~Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android Virtualization Framework API (android.system.virtualmachine.*), sau đó là~~ Trình điều khiển ảo hoá:

[C-0-12] ~~[C-3-1]~~ PHẢI đảm bảo rằng các trang bộ nhớ thuộc sở hữu độc quyền của máy ảo (pVM của máy chủ hoặc ~~pVM/máy chủ lưu trữ)~~khách hoặc máy chủ lưu trữ) hoặc trình điều khiển ảo hoá chỉ truy cập được vào chính máy ảo hoặc trình điều khiển ảo hoá, không phải do các máy ảo khác – được bảo vệ hoặc không được bảo vệ.
[C-0-13] ~~[C-3-2]~~ PHẢI xoá sạch một trang sau khi trang đó được pVM sử dụng và trước khi trang đó được trả về đến máy chủ (ví dụ: pVM bị huỷ bỏ).
[C-0-14] ~~[C-SR-1]~~ ~~MỞ RỘNG NÊN DÙNG~~ PHẢI đảm bảo rằng Chương trình cơ sở pVM được tải và thực thi trước bất kỳ mã nào trong pVM.
[C-0-15] ~~[C-3-4]~~ PHẢI đảm bảo rằng từng VM pVM lấy dữ liệu cho mỗi máy ảo bí mật, có nghĩa là (Chuỗi chứng chỉ khởi động) (BCC) và Giá trị nhận dạng thiết bị phức hợp (CDI) được cung cấp cho một phiên bản pVM chỉ có thể lấy bằng ~~máy ảo~~ cụ thể đó Phiên bản pVM và các thay đổi khi đặt lại về trạng thái ban đầu và qua mạng không dây.

API Khung ảo hoá Android (AVF) (android.system.virtualmachine.*) cho phép các ứng dụng tạo máy ảo (VM) trên thiết bị có thể tải và chạy tệp nhị phân gốc làm tải trọng.

Nếu quá trình triển khai thiết bị đặt FEATURE_VIRTUALIZATION_FRAMEWORK thành true, chúng sẽ:

[C-1-6] PHẢI đảm bảo rằng android.system.virtualmachine.VirtualMachineManager.getCapabilities() trả về ít nhất một trong số:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM

Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android Virtualization API (API Khung ảo hoá Android), thì trên tất cả các lĩnh vực:

[C-4-1] KHÔNG ĐƯỢC cung cấp chức năng cho pVM cho phép bỏ qua Mô hình bảo mật Android.

Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android Virtualization API (API Khung ảo hoá Android), thì:

[C-5-1] PHẢI có khả năng hỗ trợ Isolated Compilation nhưng có thể tắt Tính năng Biên dịch tách biệt khi vận chuyển thiết bị.

~~Nếu thiết bị triển khai dịch vụ hỗ trợ cho Android API Khung ảo hoá, sau đó là dành cho~~ Quản lý khoá:

[C-SR-2] Is mã ĐỀ XUẤT NÊN sử dụng DICE dưới dạng dẫn xuất bí mật per-VM cơ chế.

[C-0-16] PHẢI triển khai chức năng bảo vệ khôi phục cho các phân vùng được máy ảo được bảo vệ sử dụng (ví dụ: khởi động, chương trình cơ sở pVM), bằng cách sử dụng bộ nhớ phát hiện giả mạo để lưu trữ siêu dữ liệu dùng để xác định phiên bản phân vùng tối thiểu được phép hoặc bao gồm cả phiên bản bảo mật của phân vùng trong DICE hoặc chứng chỉ tương đương.

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

10. Kiểm tra tính tương thích của phần mềm

Quá trình triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử được mô tả trong phần này. Tuy nhiên, 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 trình triển khai thiết bị NÊN ĐƯỢC ĐỀ XUẤT để làm cho số lượng thay đổi tối thiểu có thể đối với tham chiếu và được ưu tiên phương thức triển khai Android có sẵn trong Dự án nguồn mở Android. Việc này sẽ giúp giảm thiểu nguy cơ gây ra lỗi gây ra sự cố không tương thích cần 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 Android Compatibility Test Suite (CTS) (Bộ kiểm tra tính tương thích của Android (CTS)) có sẵn từ Dự án nguồn mở Android, sử dụng thông tin vận chuyển cuối cùng phần mềm trên thiết bị.
[C-0-2] PHẢI đảm bảo tính tương thích trong các trường hợp không rõ ràng trong CTS và cho bất kỳ việc 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 thiết bị thực tế. Giống như bất kỳ phần mềm nào, CTS có thể chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa về khả năng tương thích và nhiều bản sửa đổi của CTS có thể được phát hành cho Android 15.

Triển khai thiết bị:

[C-0-3] PHẢI vượt qua phiên bản CTS mới nhất hiện có tại thời điểm thiết bị phần mềm hoàn tất.
NÊN sử dụng phương thức triển khai tham chiếu trong cây Nguồn mở Android nhiều nhất có thể.

10,2. Người xác minh CTS

Trình xác minh CTS được bao gồm trong Bộ kiểm tra tính tương thích và nhằm mục đích kiểm tra chức năng không thể do hệ thống tự động kiểm tra, chẳng hạn như máy ảnh hoạt động chính xác 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 có thể áp dụng trong trình xác minh CTS.

Trình xác minh CTS có các bài kiểm tra 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 tra về phần cứng mà họ sở hữu; Ví dụ: nếu thiết bị có gia tốc kế, thiết bị PHẢI thực thi chính xác Trường hợp kiểm tra gia tốc kế trong Trình xác minh CTS.

Trường hợp kiểm tra các tính năng được ghi chú là không bắt buộc theo Định nghĩa về khả năng tương thích Có thể bỏ qua hoặc bỏ qua tài liệu.

[C-0-2] Mọi thiết bị và bản dựng PHẢI chạy đúng CTS Verifier, như đã lưu ý ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên thiết bị người triển khai sẽ không chạy Trình xác minh CTS một cách rõ ràng trên các bản dựng mà chỉ khác nhau ở những khía cạnh không đáng kể. Cụ thể, các phương pháp triển khai thiết bị khác với triển khai chỉ vượt qua Trình xác minh CTS bởi nhóm ngôn ngữ, thương hiệu đi kèm, v.v. CÓ THỂ bỏ qua bài kiểm tra Trình xác minh CTS.

11. Phần mềm có thể cập nhật

[C-0-1] Quá trình triển khai thiết bị PHẢI bao gồm 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 "trực tiếp" nâng cấp—tức là bạn CÓ THỂ khởi động lại thiết bị. Có thể sử dụng bất kỳ phương pháp nào, miễn là phương pháp đó có thể thay thế toàn bộ đã cài đặt trước trên thiết bị. Ví dụ: bất kỳ giá trị nào sau đây sẽ đáp ứng được yêu cầu này:
- " qua mạng không dây (OTA)" tải xuống bằng bản cập nhật ngoại tuyến thông qua khởi động lại.
- "Đã ngắt kết nối" các bản cập nhật qua USB từ máy tính lưu trữ.
- "Ngoại tuyến" cập nhật bằng cách 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 sử dụng PHẢI hỗ trợ cập nhật mà không cần xoá sạch người dùng . Tức là cơ chế cập nhật PHẢI bảo toàn dữ liệu riêng tư của ứng dụng và dữ liệu được chia sẻ của ứng dụng. Lưu ý rằng phần mềm Android ngược dòng bao gồm 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 thông tin 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] Cơ chế ký là tôi tôi ĐỀ XUẤT NÊN băm bản cập nhật với SHA-256 và xác thực hàm băm theo khoá công khai bằng ECDSA NIST P-256.

Nếu quá trình triển khai thiết bị có hỗ trợ dữ liệu không đo lượng dữ liệu kết nối như 802.11 hoặc Bluetooth PAN (Mạng khu vực cá nhân), thì họ:

[C-1-1] PHẢI hỗ trợ tải xuống OTA với cập nhật ngoại tuyến thông qua khởi động lại.

Quá trình triển khai thiết bị PHẢI xác minh rằng hình ảnh hệ thống giống hệt với tệp nhị phân cho kết quả mong đợi sau OTA. OTA dựa trên khối hoạt động triển khai trong Dự án nguồn mở Android ngược dòng, được thêm vào kể từ khi Android 5.1, thoả mãn yêu cầu này.

Ngoài ra, các hoạt động triển khai thiết bị NÊN 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 HAL điều khiển khởi động.

Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi thiết bị ra mắt, nhưng trong vòng đời sản phẩm hợp lý được xác định sau khi tham khảo ý kiến của Nhóm tương thích với Android để ảnh hưởng đến khả năng tương thích của bên thứ ba ứng dụng, sau đó:

[C-2-1] Trình triển khai thiết bị PHẢI sửa lỗi thông qua một phần mềm bản cập nhật có sẵn có thể được áp dụng cho cơ chế vừa được mô tả.

Android có các tính năng cho phép ứng dụng Chủ sở hữu thiết bị (nếu có) kiểm soát việc cài đặt bản cập nhật hệ thống. Nếu hệ thống cập nhật hệ thống con cho thiết bị báo cáo android.software.device_admin, sau đó, chúng:

[C-3-1] PHẢI triển khai hành vi được mô tả trong SystemUpdatePolicy .

12. Nhật ký thay đổi tài liệu

Để xem bản tóm tắt các thay đổi đối với Định nghĩa về khả năng tương thích trong bản phát hành này, hãy làm như sau:

Nhật ký thay đổi tài liệu

13. Liên hệ với chúng tôi

Bạn có thể tham gia diễn đàn về khả năng tương thích với android và yêu cầu bạn làm rõ hoặc đề cập đến những vấn đề mà bạn cho rằng giấy tờ đó không bản hát lại.