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ờ đ