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

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

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

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

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

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

Vì lý do này, Dự án nguồn mở Android vừa là tài liệu tham khảo vừa là cách triển khai ưu tiên của Android. Trình triển khai thiết bị ĐƯỢC ĐỀ XUẤT NÊN làm cơ sở cho việc triển khai ở mức tối đa có thể trên mã nguồn “upstream” có sẵn từ Dự án nguồn mở Android. Mặc dù theo giả thuyết, 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ế, nhưng bạn KHÔNG NÊN làm theo phương pháp này, vì việc vượt qua các bài kiểm thử phần mềm sẽ trở nên khó khăn hơn đáng kể. Người triển khai có trách nhiệm đảm bảo khả năng tương thích hành vi đầy đủ với triển khai Android tiêu chuẩn, bao gồm và ngoài Bộ kiểm tra tính tương thích. Cuối cùng, xin lưu ý rằng tài liệu này nghiêm cấm rõ ràng một số thay thế và sửa đổi thành phần.

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

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

Mã yêu cầu trong Mục 2 bắt đầu bằng mã mục tương ứng, 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ị

Mặc dù Dự án nguồn mở Android cung cấp một ngăn xếp phần mềm có thể dùng cho nhiều loại thiết bị và kiểu dáng, nhưng vẫn có một vài loại thiết bị có hệ sinh thái phân phối ứng dụng được thiết lập tương đối tốt hơn.

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

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

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

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

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

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

Các quá trình triển khai trên 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 đường chéo màn hình vật lý trong khoảng từ 2,5 đến 8 inch.

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

2.2.1. Phần cứng

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

• [7.1.1.1/H-0-1] PHẢI có ít nhất một màn hình tương thích với Android với kích thước đường chéo vật lý tối thiểu là 2,5 inch và mỗi màn hình tương thích với Android PHẢI đáp ứng tất cả các yêu cầu được mô tả trong tài liệu này.
• [7.1.1.3/H-SR] AreRENDERED REVIEW to cung cấp users anCách thay đổi kích thước hiển thị (mật độ màn hình).

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

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

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

• [7.1.5/H-0-1] PHẢI bao gồm tính năng hỗ trợ cho chế độ tương thích ứng dụng cũ như được triển khai bằng mã nguồn mở Android ngược dòng. Tức là các hoạt động triển khai thiết bị KHÔNG ĐƯỢC thay đổi điều kiện kích hoạt hoặ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 tính năng hỗ trợ cho các ứng dụng Trình chỉnh sửa phương thức nhập (IME) của bên thứ ba.
• [7.2.3/H-0-3] PHẢI cung cấp chức năng Trang chủ trên tất cả các màn hình tương thích với Android cung cấp màn hình chính.
• [7.2.3/H-0-4] PHẢI cung cấp chức năng Quay lại trên tất cả cá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 các màn hình tương thích với Android.
• [7.2.3/H-0-2] PHẢI gửi cả sự kiện nhấn bình thường lẫn nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước. Hệ thống KHÔNG ĐƯỢC sử dụng những sự kiện này và CÓ THỂ kích hoạt từ bên ngoài thiết bị Android (ví dụ: bàn phím phần cứng bên ngoài kết nối với thiết bị Android).
• [7.2.4/H-0-1] PHẢI hỗ trợ đầu vào màn hình cảm ứng.
• [7.2.4/H-SR] Đề nghị 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 VoiceShareService, 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] Are trìy REVIEW to include a 3-axis accelerometer.

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 lên đến tần suất tối thiểu là 100 Hz.

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

• [7.3.3/H-2-1] PHẢI báo cáo các phép đo GNSS ngay khi chúng được tìm thấy, ngay cả khi vị trí được tính toán bằng GPS/GNSS chưa được báo cáo.
• [7.3.3/H-2-2] PHẢI báo cáo tốc độ khoảng giả và tầm giả GNSS, tức là 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 gia tốc dưới 0, 2 mét/giây, đủ để tính vị trí trong phạm vi 20 mét và tốc độ trong phạm vi 0, 2 mét/giây, ít nhất là 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 lên đến tần suất tối thiểu là 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 cách triển khai thiết bị cầm tay có thể thực hiện cuộc gọi thoại và cho biết bất kỳ giá trị nào khác ngoài PHONE_TYPE_NONE trong getPhoneType:

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

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

• [7.3.11/H-SR] NÊN hỗ trợ cảm biến tư thế với 6 mức tự do.
• [7.4.3/H] PHẢI bao gồm tính năng hỗ trợ Bluetooth và Bluetooth LE.

Nếu phương thức triển khai Thiết bị cầm tay có bao gồm kết nối có đo lượng dữ liệu, thì các phương thức triển khai đó:

• [7.4.7/H-1-1] PHẢI cung cấp chế độ tiết kiệm dữ liệu.

Nếu phương thức triển khai Thiết bị cầm tay bao gồm một thiết bị camera logic liệt kê các chức năng sử dụng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, thì các thiết bị đó:

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

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

• [7.6.1/H-0-1] PHẢI có ít nhất 4 GB bộ nhớ không biến đổi 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/H-0-2] PHẢI trả về “true” cho ActivityManager.isLowRamDevice() khi có dưới 1GB bộ nhớ còn trống 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à 416 MB nếu màn hình mặc định sử dụng độ phân giải bộ đệm khung lên tới qHD (ví dụ: FWVGA).

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

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

• [7.6.1/H-8-1] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI tối thiểu là 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 ngoài mọi bộ nhớ đã dành riêng cho các thành phần phần cứng như radio, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với quá trình triển khai thiết bị.

Nếu phương thức triển khai cho Thiết bị cầm tay có dung lượng bộ nhớ trống ít hơn hoặc bằng 1 GB cho nhân và không gian người dùng, thì chúng:

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

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

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

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

• [7.6.2/H-0-1] KHÔNG ĐƯỢC cung cấp bộ nhớ dùng chung cho ứng dụng có dung lượng 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.

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

• [7.7.1/H-1-1] PHẢI triển khai Android Open Accessory (AOA) API.

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

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

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

• [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 các ứng dụng Thực tế ảo bật qua android.app.Activity#setVrModeEnabled.

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

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

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ươ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ị đang khoá hoặc màn hình đang tắt. Gửi android.speech.RecognizerIntent.ACTION_WEB_SEARCH theo cách khác
		Cuộc gọi đến	Phương thức nhập: Nhấn nhanh Kết quả: Chấp nhận cuộc gọi
			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
			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 phích cắm, nhưng chỉ sau khi giao diện âm thanh và điểm cuối của USB đã được liệt kê đúng cách để xác định loại thiết bị đầu cuối được kết nối.

Khi phát hiện 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 bằng "Microphone" (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 truyền ý định ACTION_HEADSET_PLUG bằng "Microphone" (micrô) tập bổ sung thành 1.

Khi API AudioManager.getDevices() được gọi trong khi thiết bị ngoại vi USB được 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à role isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.

• [7.8.2.2/H-4-3] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và role isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.

• [7.8.2.2/H-4-4] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò 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à role isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x604.

• [7.8.2.2/H-4-6] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.

• [7.8.2.2/H-4-7] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và role isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.

• [7.8.2.2/H-SR] Are Nếu như được kết nối với một thiết bị ngoại vi âm thanh USB-C, để thực hiện liệt kê các bộ mô tả USB, xác định các loại thiết bị đầu cuối và truyền tin Ý định ACTION_HEADSET_PLUG trong thời gian chưa đến 1.000 mili giây.

2.2.2. Đa phương tiện

Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây, đồng thời cung cấp các định dạng đó 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)

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

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

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

2.2.3. Phần mềm

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

• [3.2.3.1/H-0-1] PHẢI có một ứng dụng xử lý các ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE và ACTION_CREATE_DOCUMENT như mô tả trong tài liệu SDK, đồng thời cung cấp cho người dùng khả năng truy cập vào dữ liệu của trình cung cấp tài liệu bằng cách sử dụng API DocumentsProvider.
• [3.4.1/H-0-1] PHẢI cung cấp cách triển khai hoàn chỉnh của API android.webkit.Webview.
• [3.4.2/H-0-1] PHẢI bao gồm một ứng dụng Trình duyệt độc lập để người dùng chung duyệt web.
• [3.8.1/H-SR] Are Internet ĐỀ XUẤT NÊN triển khai trình chạy mặc định hỗ trợ tính năng ghim trong ứng dụng cho các lối tắt, tiện ích và WidgetFeatures.
• [3.8.1/H-SR] Are Internet ĐỀ XUẤT NÊN triển khai một trình chạy mặc định giúp truy cập nhanh vào các lối tắt bổ sung do các ứng dụng bên thứ ba cung cấp thông qua API shortcutManager.
• [3.8.1/H-SR] Are Từ chối hỗ trợ để bao gồm một ứng dụng trình chạy mặc định hiển thị các huy hiệu cho các biểu tượng ứng dụng.
• [3.8.2/H-SR] Are Internet ĐỀ XUẤT NÊN hỗ trợ tiện ích ứng dụng của bên thứ ba.
• [3.8.3/H-0-1] PHẢI cho phép các ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý thông qua các lớp API Notification và NotificationManager.
• [3.8.3/H-0-2] PHẢI hỗ trợ thông báo đa dạng thức.
• [3.8.3/H-0-3] PHẢI hỗ trợ thông báo quan trọng.
• [3.8.3/H-0-4] PHẢI bao gồm ngăn thông báo, giúp người dùng có thể điều khiển 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 thành phần tương tác của người dùng, chẳng hạn như các nút hành động hoặc bảng điều khiển như được triển khai trong AOSP.
• [3.8.3/H-0-5] PHẢI hiển thị các lựa chọn được cung cấp thông qua RemoteInput.Builder setChoices() trong ngăn thông báo.
• [3.8.3/H-SR] AreĐể chỉ định vị trí hiển thị lựa chọn đầu tiên được cung cấp thông qua RemoteInput.Builder setChoices(), trong ngăn thông báo, người dùng không cần phải tương tác thêm.
• [3.8.3/H-SR] AreĐể chỉ định vị trí hiển thị tất cả các lựa chọn được cung cấp thông qua RemoteInput.Builder setChoices() trong ngăn thông báo, người dùng sẽ mở rộng tất cả thông báo trong ngăn thông báo.
• [3.8.3.1/H-SR] Are Internet ĐỀ XUẤT NÊN hiển thị các thao tác cho trong đó Notification.Action.Builder.setContextual được đặt thành true cùng dòng với các câu trả lời được hiển thị bằng Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] Are trì hoãn đề xuất triển khai một trợ lý trên thiết bị để xử lý Hành động hỗ trợ.

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] Are trì hoãn việc sử dụng nhấn và giữ phím HOME làm tương tác được chỉ định để chạy ứng dụng trợ lý như mô tả trong phần 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 hoạt động xử lý ý định ACTION_ASSIST.

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ị Thông báo trên màn hình khoá, 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ộ các chính sách quản trị thiết bị được xác định trong tài liệu về SDK Android.
• [3.9/H-1-2] PHẢI khai báo khả năng hỗ trợ hồ sơ được quản lý qua cờ tính năng android.software.managed_users, trừ phi thiết bị được định cấu hình để chính thiết bị báo cáo là thiết bị có RAM thấp hoặc để phân bổ bộ nhớ trong (không thể tháo rời) làm bộ nhớ dùng chung.

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

• [3.10/H-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
• [3.10/H-SR] Are trì hoãn việc tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương với 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 những ngôn ngữ được công cụ chuyển văn bản sang lời nói cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở TalkBack.
• [3.11/H-0-1] PHẢI hỗ trợ cài đặt công cụ TTS của bên thứ ba.
• [3.11/H-SR] Are trì hoãn phát triển để bao gồm công cụ TTS hỗ trợ các ngôn ngữ có sẵn trên thiết bị.
• [3.13/H-SR] Are Internet ĐỀ XUẤT NÊN bao gồm thành phần giao diện người dùng Quick Settings (Cài đặt nhanh).

Nếu quá trình triển khai thiết bị cầm tay Android khai báo khả năng hỗ trợ FEATURE_BLUETOOTH hoặc FEATURE_WIFI, thì các quy trình đó sẽ:

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

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

• [7.2.3/H] Vùng nhận dạng cử chỉ cho chức năng Màn hình chính PHẢI có chiều cao không quá 32 dp tính từ cuối 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 một cử chỉ từ bất kỳ vị trí nào ở cạnh trái và phải của màn hình:

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

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ườ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. Hoạt động triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách gồm 10.000 mục trong danh sách do Bộ kiểm tra tính tương thích (CTS) xác định trong chưa đầy 36 giây.
• [8.1/H-0-3] Chuyển đổi tác vụ. Khi chạy nhiều ứng dụng, việc chạy lại một ứng dụng đang chạy sau khi khởi 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 hiệu suất ghi tuần tự tối thiểu là 5 MB/giây.
• [8.2/H-0-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 0,5 MB/giây.
• [8.2/H-0-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 15 MB/giây.
• [8.2/H-0-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu là 3,5 MB/giây.

Nếu phương thức triển khai Thiết bị cầm tay có các tính năng giúp cải thiện khả năng quản lý nguồn điện thiết bị được đưa vào AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

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

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

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

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

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

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

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

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

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

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 thời gian chờ ngắn nhất, tức là thời gian chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, tối đa là 15 giây.
• [9.11/H-1-2] PHẢI cung cấp khả năng tương tác của người dùng để ẩn thông báo và tắt tất 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á bảo mật. AOSP đáp ứng yêu cầu đối với chế độ khoá.

Nếu quá trình triển khai Thiết bị cầm tay bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì họ sẽ:

• [9.5/H-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng bổ sung và khả năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để những người dùng khác làm việc cùng 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ị cầm tay bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì họ:

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

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.

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

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

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

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

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

• Cung cấp cơ chế điều khiển từ xa giao diện người dùng được kết xuất trên màn hình có thể cách người dùng 10 feet (1,8 mét).
• Có màn hình nhúng có chiều dài đường chéo lớn hơn 24 inch HOẶC có một cổng đầu ra video 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 này dành riêng cho việc triển khai thiết bị Android TV.

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] PHẢI cung cấp các hàm Home và Back.
• [7.2.3/T-0-2] PHẢI gửi cả sự kiện nhấn bình thường và nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước.
• [7.2.6.1/T-0-1] PHẢI bao gồm tính năng hỗ trợ tay điều khiển trò chơi và khai báo cờ tính năng android.hardware.gamepad.
• [7.2.7/T] PHẢI cung cấp điều khiển từ xa mà từ đó người dùng có thể truy cập vào phương thức nhập điều hướng không cảm ứng và 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 lên đến tần suất tối thiểu là 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ớ không biến đổi dành cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").

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

• [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 thông qua cổng USB này nhưng không nhất thiết phải luôn kết nối.

Nếu 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à 1280 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

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 ngoài mọi bộ nhớ đã dành riêng cho các thành phần phần cứng như radio, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với quá trình 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

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây, đồng thời cung cấp các định dạng đó cho ứ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)

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

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

Triển khai thiết bị TV:

• [5.2.2/T-SR] Are trì hoãn phát triển để hỗ trợ H.264 encryption of 720p and 1080p issue at 30 khung hình/giây.

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp các định dạng đó cho các ứng dụng 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

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

• [5.3.1/T-1-1] HD 1080p ở tốc độ 29,97 khung hình/giây với 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 video cho các ứng dụng của bên thứ ba.

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã H.264, như đã nêu chi tiết trong Mục 5.3.4, ở tốc độ khung hình và độ phân giải video 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 cấu hình cao cấp 4.2

Việc triển khai thiết bị truyền hình với 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 và độ phân giải video tiêu chuẩn lên đến và bao gồm:

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

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

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

Việc triển khai thiết bị truyền hình PHẢI hỗ trợ giải mã VP8, như đã 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 và bao gồm:

• [5.3.6/T-1-1] Cấu hình giải mã HD 1080p ở tốc độ 60 khung hình/giây

Việc triển khai thiết bị truyền hình với bộ giải mã phần cứng VP9 PHẢI hỗ trợ giải mã VP9, như đã nêu chi tiết trong Mục 5.3.7, ở tốc độ khung hình và độ phân giải video tiêu chuẩn 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 với bộ giải mã phần cứng VP9 hỗ trợ giải mã VP9 và cấu hình giải mã UHD, thì các quy trình đó:

• [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-2-1] Are trì hoãn phát triển để hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ 2 (độ sâu màu 10 bit).

Triển khai thiết bị TV:

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

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

• [5.8/T-0-1] PHẢI đặt chế độ đầu ra HDMI để chọn độ phân giải tối đa có thể được hỗ trợ với tốc độ làm mới 50Hz hoặc 60Hz.
• [5.8/T-SR] Are trì hoãn phát hành để cung cấp một bộ chọn tốc độ làm mới HDMI có thể định cấu hình cho người dùng.
• [5.8] NÊN đặt tốc độ làm mới ở chế độ đầu ra HDMI thành 50Hz hoặc 60Hz, tuỳ thuộc vào tốc độ làm mới video cho khu vực bán thiết bị.

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

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

Nếu các phương pháp triển khai Thiết bị TV không hỗ trợ giải mã UHD mà có hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các thiết bị đó:

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

2.3.3. Phần mềm

Triển khai thiết bị 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.4.1/T-0-1] PHẢI cung cấp cách triển khai hoàn chỉnh của 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ị Thông báo trên màn hình khoá, 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] Are mã ĐỀ XUẤT NÊN hỗ trợ chế độ image-in-picture (PIP) nhiều cửa sổ.
• [3.10/T-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
• [3.10/T-SR] Are trì hoãn việc tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương với 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ông cụ chuyển văn bản sang lời nói cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở TalkBack.

Nếu các hoạt động triển khai Thiết bị TV báo cáo tính năng android.hardware.audio.output, thì tính năng này sẽ:

• [3.11/T-SR] Are trì hoãn lựa chọn để bao gồm một 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ông cụ TTS của bên thứ ba.

Triển khai thiết bị TV:

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

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

Nếu quá trình triển khai thiết bị TV có các tính năng giúp cải thiện khả năng quản lý nguồn điện thiết bị được đưa vào AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

• [8.3/T-1-1] PHẢI cung cấp thuộc tính tương tác của người dùng để bật và tắt tính năng 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 trừ khỏi các chế độ tiết kiệm pin và Chế độ chờ ứng dụng.

Triển khai thiết bị TV:

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

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

Triển khai thiết bị TV:

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

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

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 thời gian chờ Ngủ để chuyển đổi từ trạng thái mở khoá sang trạng thái khoá, với thời gian chờ tối thiểu cho phép tối đa là 15 giây trở xuống.

Nếu quá trình 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, thì họ sẽ:

• [9.5/T-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng bổ sung và khả năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để những người dùng khác làm việc cùng 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ị TV bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì họ:

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

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

Triển khai thiết bị TV:

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

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

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

Các quá trình triển khai trên 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 chiều 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ể.

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

2.4.1. Phần cứng

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

• [7.1.1.1/W-0-1] PHẢI có một màn hình có kích thước đường chéo vật lý trong khoảng từ 1,1 đến 2,5 inch.

• [7.2.3/W-0-1] PHẢI có hàm Home (Trang chủ) cho người dùng và hàm Back (Quay lại) ngoại trừ trường hợp hàm này nằm trong 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] AreRENDERED DOWNLOAD to include a 3-axis accelerometer.

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

• [7.3.3/W-1-1] PHẢI báo cáo số liệu đo lường GNSS ngay khi tìm thấy, ngay cả khi chưa báo cáo vị trí tính bằng GPS/GNSS.
• [7.3.3/W-1-2] PHẢI báo cáo tốc độ phạm vi giả và tầm giả GNSS, trong điều kiện trời mở sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét/giây, đủ để tính vị trí trong phạm vi 20 mét và tốc độ trong phạm vi 0, 2 mét/giây, ít nhất là 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ớ không biến đổi dành cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").

• [7.6.1/W-0-2] PHẢI có ít nhất 416 MB bộ nhớ còn trống cho nhân 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Ể nhưng KHÔNG NÊN 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 android.hardware.type.watch.
• [3/W-0-2] PHẢI hỗ trợ uiMode = UI_MODE_TYPE_WATCH.

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

• [3.8.4/W-SR] Are trì hoãn lựa chọn để triển khai một trợ lý trên thiết bị để xử lý Hành động hỗ trợ.

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

• [3.10/W-1-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.

• [3.10/W-SR] Are trì hoãn việc tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương với 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 những ngôn ngữ được công cụ chuyển văn bản sang lời nói cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở TalkBack.

• [3.11/W-SR] AreĐể chỉ định công cụ TTS hỗ trợ các ngôn ngữ hiện có trên thiết bị.

• [3.11/W-0-1] PHẢI hỗ trợ cài đặt công cụ TTS của bên thứ ba.

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

Nếu quá trình triển khai thiết bị Đồng hồ có các tính năng cải thiện khả năng quản lý nguồn điện thiết bị được đưa vào AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

• [8.3/W-SR] AreĐể chỉ định chế độ tiết kiệm pin cho người dùng, hãy hiển thị tất cả các ứng dụng được miễn trừ khỏi Chế độ chờ ứng dụng và chế độ tiết kiệm điện Doze.
• [8.3/W-SR] Are Để cung cấp lựa chọn tương tác cho người dùng và tắt tính năng tiết kiệm pin, bạn có thể sử dụng tính năng này.

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

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

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

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, thì họ sẽ:

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

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

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

Quy trình triển khai Android Automotive tức là một đầu phát trung tâm của xe chạy Android dưới dạng một 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 các hoạt động đó khai báo tính năng android.hardware.type.automotive hoặc đáp ứng tất cả tiêu chí sau.

• Đượ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 này dành riêng cho việc triển khai thiết bị Android Automotive.

2.5.1. Phần cứng

Triển khai thiết bị Automotive:

• [7.1.1.1/A-0-1] PHẢI có màn hình có kích thước đường chéo thực ít nhất 6 inch.

• [7.1.1.1/A-0-2] PHẢI có bố cục kích thước màn hình tối thiểu là 750 dp x 480 dp.

• [7.2.3/A-0-1] PHẢI cung cấp hàm Home và CÓ THỂ cung cấp các hàm Back và Recent.

• [7.2.3/A-0-2] PHẢI gửi cả sự kiện nhấn bình thường và nhấn và giữ của hàm Quay lại (KEYCODE_BACK) đến ứng dụng trên nền trước.
• [7.3/A-0-1] PHẢI triển khai và báo cáo GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED và PARKING_BRAKE_ON.
• [7.3/A-0-2] Giá trị của cờ NIGHT_MODE PHẢI nhất quán với chế độ ngày/đêm trên bảng điều khiển và PHẢI dựa trên đầu vào của 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 với Photometer.
• [7.3/A-0-3] PHẢI cung cấp trường thông tin bổ sung cho 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-0-1] CÓ THỂ xác định được Vị trí bằng cách hợp nhất GPS/GNSS với các cảm biến bổ sung. Nếu Vị trí đã được xác định là không thể xác định, thì bạn nên triển khai và báo cáo các loại Cảm biến và/hoặc Mã thuộc tính xe tương ứng được sử dụng.
• [7.3/A-0-2] Vị trí được yêu cầu qua LocationManager#requestLocationUpdates() KHÔNG ĐƯỢC trùng khớp trên bản đồ.

Nếu hoạt động triển khai thiết bị Automotive bao gồm gia tốc kế 3 trục, thì các cấu hình đó sẽ:

• [7.3.1/A-1-1] 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à 100 Hz.
• [7.3.1/A-1-2] PHẢI tuân thủ hệ thống toạ độ cảm biến ô tô của Android.

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-2-1] 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à 100 Hz.
• [7.3.4/A-2-2] PHẢI cũng triển khai cảm biến TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] PHẢI có khả năng đo các thay đổi về hướng lên đến 250 độ mỗi giây.
• [7.3.4/A-SR] Are Internet ĐỀ XUẤT NÊN định cấu hình phạm vi đo lường của gyroscope thành +/-250dps để tối đa hoá độ phân giải có thể

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] Android Automotiveđược triển khai PHẢI hỗ trợ các cấu hình Bluetooth sau đây:

  • 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).

• [7.4.3/A-SR] Are Từ phút hạng sang, DƯỚI ĐÂY.

• [7.4.5/A] PHẢI bao gồm tính năng hỗ trợ kết nối dữ liệu dựa trên mạng di động.

• [7.4.5/A] CÓ THỂ sử dụng hằng số API hệ thống NetworkCapabilities#NET_CAPABILITY_OEM_PAID cho các mạng dùng được cho ứng dụng hệ thống.

Camera quan sát bên ngoài là một camera ghi lại những cảnh bên ngoài thiết bị, chẳng hạn như camera hành trình.

Triển khai thiết bị Automotive:

• NÊN bao gồm một hoặc nhiều camera quan sát bên ngoài.

Nếu quá trình triển khai thiết bị Automotive có bao gồm máy ảnh quan sát bên ngoài, thì đối với một máy ảnh như vậy, chúng sẽ:

• [7.5/A-1-1] KHÔNG ĐƯỢC cho phép truy cập vào camera xem bên ngoài qua Android Camera API, trừ phi những camera này tuân thủ các yêu cầu cốt lõi về camera.
• [7.5/A-SR] Are trì hoãn lựa chọn không xoay hoặc phản chiếu ngang hàng bản xem trước của máy ảnh.
• [7.5.5/A-SR] AreĐể chỉ định hướng theo đường chân trời, chiều dài của máy ảnh được căn chỉnh sao cho phù hợp với đường chân trời.
• [7.5/A-SR] AreĐể các bạn có được độ phân giải tối thiểu là 1,3 megapixel.
• PHẢI có phần cứng có tiêu điểm cố định hoặc EDOF (độ sâu trường mở rộng).
• CÓ THỂ triển khai tính năng tự động lấy nét phần cứng hoặc tự động lấy nét bằng phần mềm trong trình điều khiển máy ảnh.

Triển khai thiết bị Automotive:

• [7.6.1/A-0-1] PHẢI có ít nhất 4 GB bộ nhớ không biến đổi 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/A] NÊN định dạng phân vùng dữ liệu để cải thiện hiệu suất và tuổi thọ cho bộ nhớ flash, ví dụ: sử dụ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 thông qua một phần của bộ nhớ trong không thể tháo rời, thì chúng sẽ:

• [7.6.1/A-SR] AreĐể chỉ định giảm mức hao tổn I/O cho các thao tác được thực hiện trên bộ nhớ ngoài, chẳng hạn như bằng cách sử dụng SDCardFS.

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

• [7.6.1/A-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à 512 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • 280dpi 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-1-2] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI tối thiểu là 608 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • xhdpi trở lên trên màn hình nhỏ/bình thường
  • hdpi trở lên trên màn hình lớn
  • mdpi trở lên trên màn hình cực lớn

• [7.6.1/A-1-3] 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

• [7.6.1/A-1-4] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI tối thiểu là 1344 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • 560dpi trở lên đối với màn hình nhỏ/bình thường
  • 400dpi trở lên đối với màn hình lớn
  • xhdpi trở lên trên màn hình cực lớn

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

• [7.6.1/A-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à 816 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • 280dpi 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à không gian người dùng PHẢI tối thiểu là 944 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • xhdpi trở lên trên màn hình nhỏ/bình thường
  • hdpi trở lên trên màn hình lớn
  • mdpi trở lên trên màn hình cực lớn

• [7.6.1/A-2-3] Bộ nhớ có sẵn cho nhân và không gian người dùng PHẢI tối thiểu là 1280 MB nếu 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

• [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à 1824 MB nếu sử dụng bất kỳ mật độ nào sau đây:

  • 560dpi trở lên đối với màn hình nhỏ/bình thường
  • 400dpi trở lên đối với màn hình lớn
  • xhdpi 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 ngoài mọi bộ nhớ đã dành riêng cho các thành phần phần cứng như radio, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với quá trình triển khai thiết bị.

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.

2.5.2. Đa phương tiện

Quá trình triển khai thiết bị trên ô tô PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây, đồng thời cung cấp các định dạng đó cho ứ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)

Quá trình triển khai thiết bị Automotive PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp 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

Quá trình triển khai thiết bị trên ô tô PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp 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 hoạt động triển khai thiết bị Automotive được ĐỀ XUẤT NÊN hỗ trợ giải mã video sau đây:

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

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 android.hardware.type.automotive.

• [3/A-0-2] PHẢI hỗ trợ uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] PHẢI hỗ trợ tất cả API công khai trong không gian tên android.car.*.

• [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 đối với ô tô.

• [3.4.1/A-0-1] PHẢI cung cấp cách triển khai hoàn chỉnh của API android.webkit.Webview.

• [3.8.3/A-0-1] PHẢI hiển thị các thông báo sử dụng API Notification.CarExtender khi các ứng dụng bên thứ ba yêu cầu.

• [3.8.4/A-SR] Are trì hoãn lựa chọn để triển khai một trợ lý trên thiết bị để xử lý Hành động hỗ trợ.

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 nhanh nút nhấn để nói làm tương tác được chỉ định để 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.

Triển khai thiết bị Automotive:

• [3.8.3.1/A-0-1] PHẢI kết xuất chính xác các tài nguyên như mô tả trong tài liệu về SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] PHẢI hiển thị PLAY và MUTE cho các hành động thông báo thay cho các hành động được cung cấp thông qua Notification.Builder.addAction()
• [3.8.3.1/A] NÊN hạn chế việc sử dụng các tác vụ quản lý đa dạng thức, chẳng hạn như chế độ kiểm soát theo kênh thông báo. CÓ THỂ sử dụng thành phần tương tác trên giao diện người dùng cho mỗi ứng dụng để giảm bớt quyền kiểm soát.

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 nội dung nghe nhìn như mô tả trong mục 3.14.
• [3.14/A-0-2] PHẢI cho phép người dùng tương tác an toàn với Ứng dụng đa phương tiện khi đang lái xe.
• [3.14/A-0-3] PHẢI hỗ trợ thao tác theo ý định ngầm ẩn CAR_INTENT_ACTION_MEDIA_TEMPLATE kèm theo dữ liệu bổ sung CAR_EXTRA_MEDIA_PACKAGE.
• [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 hoạt động ưu tiên của ứng dụng đa phương tiện nhưng PHẢI chỉ bật khi các Quy định hạn chế về trải nghiệm người dùng trên ô tô không có hiệu lực.
• [3.14/A-0-5] PHẢI hiển thị thông báo lỗi do Ứng dụng đa phương tiện đặt và PHẢI hỗ trợ các tiện ích 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ính năng tìm kiếm.
• [3.14/A-0-7] PHẢI tuân thủ các định nghĩa CONTENT_STYLE_BROWSABLE_HINT và CONTENT_STYLE_PLAYABLE_HINT khi hiển thị hệ phân cấp MediaBrowser.

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 các dịch vụ nghe nhìn và mở các dịch vụ đó bằng ý định CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Triển khai thiết bị Automotive:

• [3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để giới hạn khả năng chuyển sang chế độ toàn màn hình như mô tả trong immersive documentation.
• [3.8/A] CÓ THỂ hiển thị thanh trạng thái và thanh điều hướng mọi lúc.
• [3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để giới hạn khả năng 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 những thành phần đó luôn hiển thị rõ ràng, như mô tả trong WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS và WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

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

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ư chuyển sang Người dùng hệ thống không có giao diện người dùng, trừ trường hợp 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 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ố Người dùng tối đa trên thiết bị.

Triển khai thiết bị Automotive:

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

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

Nếu các hoạt động triển khai thiết bị Automotive hỗ trợ màn hình khoá an toàn, thì chúng sẽ:

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

Triển khai thiết bị Automotive:

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

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

Triển khai thiết bị Automotive:

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

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

Thiết bị máy tính bảng Android tức là phương thức triển khai thiết bị Android đáp ứng tất cả các tiêu chí sau:

• Thường dùng bằng cách cầm bằng cả hai tay.
• Không có cấu hình vỏ sò hoặc có thể chuyển đổi.
• Mọi cách triển khai bàn phím thực dùng với thiết bị PHẢI kết nối bằng kết nối tiêu chuẩn.
• 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 đường chéo màn hình vật lý trong khoảng từ 7 đến 18 inch.

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

2.6.1. Phần cứng

Kích thước màn hình

• [7.1.1.1/Tab-0-1] PHẢI có màn hình trong phạm vi từ 7 đến 18 inch.

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 các thay đổi về hướng lên đến 1000 độ mỗi giây.

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

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

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

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

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

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

Hiệu suất 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 quá trình triển khai thiết bị Máy tính bảng bao gồm nhiều người dùng và không khai báo cờ tính năng android.hardware.telephony, thì họ sẽ:

• [9.5/T-1-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng bổ sung và khả năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để những người dùng khác làm việc cùng 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ị Máy tính bảng bao gồm nhiều người dùng và khai báo cờ tính năng android.hardware.telephony, thì họ:

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

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 cho các ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là tập hợp các giao diện nền tảng Android hiển thị 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 quá trình triển khai hoàn chỉnh, bao gồm tất cả hành vi được ghi nhận, của mọi API được ghi nhận do SDK Android hiển thị hoặc bất kỳ API nào được trang trí bằng điểm đánh dấu “@SystemApi” trong mã nguồn Android ngược dòng.

• [C-0-2] PHẢI hỗ trợ/duy trì tất cả các lớp, phương thức, và các yếu tố liên kết được đánh dấu bởi chú thích TestApi (@TestApi).

• [C-0-3] KHÔNG ĐƯỢC bỏ qua bất kỳ API được quản lý nào, thay đổi giao diện hoặc chữ ký API, đi chệch khỏi hành vi được ghi chép hoặc bao gồm không hoạt động, ngoại trừ trường hợp được Định nghĩa 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 hợp lý, ngay cả khi một số tính năng phần cứng mà Android bao gồm API bị bỏ qua. Hãy xem phần 7 để biết các yêu cầu cụ thể cho trường hợp này.

• [C-0-5] KHÔNG ĐƯỢC cho phép các ứng dụng bên thứ ba sử dụng giao diện không phải SDK, được định nghĩa là phương thức và trường trong gói ngôn ngữ Java nằm trong đường dẫn lớp khởi động trong AOSP và là một phần của SDK công khai. Trong đó có các API được trang trí bằng chú thích @hide nhưng không được trang trí bằng @SystemAPI, như mô tả trong tài liệu SDK cũng như các thành phần của lớp riêng tư và riêng tư trong gói.

• [C-0-6] PHẢI gửi cùng mọi giao diện không phải SDK trên cùng một danh sách bị hạn chế như được cung cấp qua danh sách tạm thời và cờ danh sách từ chối trong đường dẫn prebuilts/runtime/appcompat/hiddenapi-flags.csv cho nhánh cấp độ API thích hợp trong AOSP.

  Tuy nhiên, chúng:

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

• [C-0-7] PHẢI hỗ trợ cơ chế cập nhật động Signed config để 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ó trong AOSP.

3.1.1. Tiện ích Android

Android có hỗ trợ mở rộng các API được quản lý trong khi vẫn giữ nguyên phiên bản cấp độ API.

• [C-0-1] Hoạt động triển khai thiết bị Android PHẢI tải trước phương thức triển khai AOSP của cả thư viện dùng chung ExtShared và dịch vụ ExtServices với các phiên bản cao hơn hoặc bằng số phiên bản tối thiểu được phép theo từng cấp độ API. Ví dụ: triển khai thiết bị Android 7.0, chạy API cấp 24 PHẢI bao gồm ít nhất phiên bản 1.

3.1.2. Thư viện Android

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

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

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

3.2. Khả năng tương thích 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 API "mềm" chỉ dành cho thời gian chạy, dưới dạng những ý định, quyền và những khía cạnh tương tự của ứng dụng Android mà 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ả hằng số quyền như được nêu trong Trang tham khảo về quyền. Xin lưu ý rằng phần 9 liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật Android.

3.2.2. Tham số bản dựng

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

• [C-0-1] Để cung cấp các giá trị nhất quán, có ý nghĩa giữa các quá trình triển khai thiết bị, bảng bên dưới bao gồm các hạn chế bổ sung về định dạng của các giá trị này mà các cách 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, ở định dạng mà con người có thể đọc được. Trường này PHẢI có một trong các giá trị chuỗi đã xác định trong 10.
PHIÊN BẢN.SDK	Phiên bản hệ thống Android đang thực thi, ở một định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập được. Đối với Android 10, trường này PHẢI có giá trị số nguyên 10_INT.
VERSION.SDK_INT	Phiên bản hệ thống Android đang thực thi, ở một định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập được. Đối với Android 10, trường này PHẢI có giá trị số nguyên 10_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. Giá trị này 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. Trường này được dùng để cho biết số bản dựng hoặc giá trị nhận dạng thay đổi về quyền 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 cụ thể mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Trường này có thể dùng để chỉ ra bản sửa đổi cụ thể của bảng cấp nguồn cho thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
THƯƠNG HIỆU	Một giá trị phản ánh tên thương hiệu liên kết với thiết bị mà người dùng cuối biết. PHẢI ở định dạng mà con người có thể đọc được và PHẢI đại diện cho nhà sản xuất thiết bị hoặc thương hiệu của công ty nơi tiếp thị 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_-]+$”.
HỖ TRỢ_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
HỖ TRỢ_32_BIT_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
HỖ TRỢ_64_BIT_ABIS	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI2	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
THIẾT BỊ	Giá trị do người triển khai thiết bị chọn, có chứa tên phát triển hoặc tên mã xác định cấu hình của các tính năng phần cứng và kiểu dáng công nghiệp của thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”. Tên thiết bị này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
IN HOA	Một chuỗi xác định duy nhất bản dựng này. Mã này PHẢI dễ đọ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:10/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). Mã này PHẢI dễ đọ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_-]+$”.
NGƯỜI DẪN CHƯƠNG TRÌNH	Một chuỗi xác định duy nhất máy chủ lưu trữ mà bản dựng được xây dựng, ở định dạng mà con người có thể đọc được. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗ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 bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống như android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị 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 chính quy “^[a-zA-Z0-9._-]+$”.
NHÀ SẢN XUẤT	Tên thương mại của Nhà sản xuất thiết bị gốc (OEM) của sản phẩm. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC 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.
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 thiết bị mà người dùng cuối biết. Tên này PHẢI giống với tên được dùng để tiếp thị và bán thiết bị cho người dùng cuối. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC 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.
SẢN PHẨM	Giá trị do trình triển khai thiết bị chọn. Giá trị này PHẢI là duy nhất trong cùng một thương hiệu, trong đó có tên phát triển hoặc tên mã của sản phẩm (SKU) cụ thể. PHẢI là nội dung mà con người có thể đọc được, nhưng không nhất thiết là để người dùng cuối có thể xem đượ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_-]+$”. Tên sản phẩm này KHÔNG ĐƯỢC thay đổi trong suốt vòng đời của sản phẩm.
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 để phân biệt rõ hơn bản dựng. Các thẻ PHẢI được mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+” và PHẢI có một trong các giá trị tương ứng với ba cấu hình ký của nền tảng Android điển hình: khoá phát hành, khoá dev và khoá kiểm tra.
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 cấu hình thời gian chạy của bản dựng. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình Android Runtime điển hình: user, userdebug hoặc eng.
NGƯỜI DÙNG	Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) tạo ra bản dựng. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC 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ị rằng bản dựng không dễ gặp phải bất kỳ vấn đề nào được mô tả thông qua Bản tin về an ninh công cộng Android được chỉ định. Thông báo PHẢI có định dạng [YYYY-MM-DD], khớp với một chuỗi đã xác định được nêu trong Bản tin về an ninh công cộng Android hoặc trong Thông báo tư vấn về bảo mật Android, chẳng hạn như "2015-11-01".
BASE_OS (Hệ điều hành cơ sở)	Một giá trị biểu thị tham số FINGERprint của bản dựng hoàn toàn giống 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. Hàm PHẢI báo cáo giá trị chính xác và nếu bản dựng đó không tồn tại, hãy báo cáo một chuỗi trống ("").
TRÌNH TẢI TĂNG	Một 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ụ thể 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ó radio/modem nội bộ nào thì thiết bị PHẢI trả về giá trị NULL. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-,]+$”.
getSerial()	PHẢI (là hoặc trả về) số sê-ri phần cứng. Số này PHẢI 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 cốt lõi 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 phiên bản cũ bao gồm một danh sách ứng dụng được xem là ứng dụng Android cốt lõi, triển khai một số mẫu ý định để thực hiện các thao tác phổ biến.

• [C-0-1] Hoạt động triển khai thiết bị PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, đối với tất cả các mẫu bộ lọc ý định công cộng được các ứng dụng Android cốt lõi sau đây xác định trong AOSP:

  • Đồng hồ để bàn
  • Trình duyệt
  • Lịch
  • Danh bạ
  • Thư viện
  • Tìm kiếm toàn cầu
  • Súng phóng lựu
  • Âm nhạc
  • Cài đặt

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

• [C-0-1] Vì Android là nền tảng có thể mở rộng, nên việc triển khai thiết bị PHẢI cho phép từng mẫu ý định được tham chiếu trong section 3.2.3.1 , ngoại trừ Chế độ cài đặt, để các ứng dụng bên thứ ba ghi đè. 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] Người triển khai thiết bị KHÔNG ĐƯỢC đính kèm đặc quyền đặc biệt vào ứng dụng hệ thống việc sử dụng các mẫu ý định này hoặc ngăn ứng dụng của bên thứ ba liên kết và giả định kiểm soát các mẫu ý định 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 giao diện người dùng “Chooser” (Bộ chọn), cho phép người dùng chọn giữa nhiều ứng dụng mà tất cả đều xử lý cùng một mẫu ý định.

• [C-0-3] Quá trình triển khai thiết bị PHẢI cung cấp giao diện người dùng để người dùng sửa đổi hoạt động mặc định cho ý định.

• Tuy nhiên, việc triển khai thiết bị CÓ THỂ cung cấp hoạt động mặc định cho các mẫu URI cụ thể (ví dụ: http://play.google.com) khi hoạt động mặc định cung cấp một thuộc tính cụ thể hơn cho URI dữ liệu. Ví dụ: mẫu bộ lọc ý định chỉ định URI dữ liệu “http://www.android.com” cụ thể hơn mẫu ý định cốt lõi của trình duyệt cho “http://”.

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

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

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

• [C-0-1] Quá 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 ý định hoặc mẫu ý định truyền tin mới bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khoá khác trong 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 ý định hoặc mẫu ý đị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ỳ mẫu ý định nào được các ứng dụng cốt lõi liệt kê trong mục 3.2.3.1 sử dụng.
• 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 có liên quan một cách rõ ràng và rõ ràng với tổ chức của riêng chúng. Quy định cấm này tương tự như quy định cấm được chỉ định cho các lớp ngôn ngữ Java trong mục 3.6.

3.2.3.4. Ý định truyền tin

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

Triển khai thiết bị:

• [C-0-1] PHẢI truyền phát ý định truyền tin công khai để 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 tài liệu về SDK.

3.2.3.5. Cài đặt ứng dụng mặc định

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, chẳng hạn như Màn hình chính hoặc SMS.

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

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 thực hiện ý định android.settings.HOME_SETTINGS để hiện trình đơn cài đặt ứng dụng mặc định cho Màn hình chính.

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

• [C-2-1] PHẢI cung cấp trình đơn cài đặt sẽ gọi ý định RoleManager.createRequestRoleIntent(String) bằng RoleManager.ROLE_SMS để hiện hộp thoại thay đổi ứng dụng SMS mặc định.

• [C-2-2] PHẢI thực hiện ý định android.telecom.action.CHANGE_DEFAULT_DIALER để hiện hộp thoại cho phép người dùng thay đổi ứng dụng Điện thoại mặc định.

  • PHẢI sử dụng giao diện người dùng mặc định của ứng dụng Điện thoại cho các cuộc gọi đến và đi, ngoại trừ các cuộc gọi khẩn cấp. Giao diện này sẽ dùng ứng dụng Điện thoại được cài đặt trước.

• [C-2-3] PHẢI thực hiện ý định android.telecom.action.CHANGE_PHONE_ACCOUNTS để cung cấp khả năng tương tác cho người dùng nhằm định cấu hình ConnectionServices liên kết với PhoneAccounts, cũng như PhoneAccount mặc định mà nhà cung cấp dịch vụ viễn thông sẽ sử dụng để thực hiện các cuộc gọi đi. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách thêm một "Tuỳ chọn tài khoản gọi" 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 đối với ứng dụng có vai trò android.app.role.CALL_REDIRECTION.

• [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 có vai trò android.app.role.CALL_REDIRECTION.

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ủ ý định android.settings.NFC_PAYMENT_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho tính năng Chạm là thanh toán.

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

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

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 nhiều màn hình, thì các hoạt động đó sẽ:

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

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

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

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

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

• [SR] linh hoạt NÊN sử dụng các phương thức triển khai thư viện được liệt kê bên dưới trong Dự án nguồn mở Android ngược dòng (upstream).

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

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

• [C-0-6] PHẢI báo cáo, thông qua các tham số trên, một tập hợp con của danh sách ABI sau đây và KHÔNG ĐƯỢC báo cáo bất kỳ ABI nào không có trong danh sách.

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

  • [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 tính năng android.software.midi được xác nhận quyền sở hữu theo 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 các thư viện gốc được liệt kê ở trên.

• [C-0-9] PHẢI liệt kê các thư viện không phải AOSP (Dự án nguồn mở Android) bổ sung được hiển thị trực tiếp với các ứng dụng bên thứ ba trong /vendor/etc/public.libraries.txt.
• [C-0-10] KHÔNG ĐƯỢC hiển thị bất kỳ thư viện gốc nào khác, được triển khai và cung cấp trong AOSP dưới dạng thư viện hệ thống, cho các ứng dụng của bên thứ ba nhắm mục tiêu API cấp 24 trở lên vì chúng được dành riêng.
• [C-0-11] PHẢI xuất tất cả biểu tượng hàm OpenGL ES 3.1 và Android Extension Pack (Gói tiện ích Android), như định nghĩa 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 đều PHẢI được hiện diện, mục 7.1.4.1 mô tả chi tiết hơn các yêu cầu khi cần thực hiện đầy đủ từng chức năng tương ứng.
• [C-0-12] PHẢI xuất biểu tượng hàm cho các biểu tượng hàm Vulkan 1.0 chính, cũng như các tiện ích VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 và VK_KHR_get_physical_device_properties2 thông qua thư viện libvulkan.so. Lưu ý rằng mặc dù tất cả các ký hiệu PHẢI được hiện diện, mục 7.1.4.2 mô tả chi tiết hơn các yêu cầu khi cần thực hiện đầy đủ 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 (upstream)

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

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ợ, vì armeabi chỉ dành cho khả năng tương thích ngược với các ứng dụng cũ.

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

• [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 mà thiết bị hỗ trợ.
  • CPU architecture:, theo sau là một số nguyên mô tả kiến trúc ARM được hỗ trợ cao nhất của thiết bị (ví dụ: "8" cho thiết bị ARMv8).

• [C-2-2] PHẢI luôn cung cấp 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.
  • ĐẶT lệnh.
  • Các vận hành rào cản CP15ISB, CP15DSB và CP15DMB.

• [C-2-3] PHẢI bao gồm tính năng hỗ trợ cho tiện ích Advanced SIMD (a.k.a. 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 các hoạt động triển khai thiết bị cung cấp quá trình triển khai API android.webkit.Webview hoàn chỉnh, thì 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 nhánh Android 10 để triển khai API android.webkit.WebView.

• [C-1-3] Chuỗi tác nhân người dùng do WebView báo cáo PHẢI ở đị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ùng giá trị như android.os.Build.MODEL.
  • "Build/$(XÂY DỰNG)" CÓ THỂ bỏ qua, nhưng nếu có, thì chuỗi $(BUILD) 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 khả năng hỗ trợ cho nhiều tính năng HTML5 nhất có thể và nếu thành phần hỗ trợ tính năng này PHẢI tuân thủ thông số kỹ thuật 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 các dịch vụ hệ thống cần thiết ở mức tối thiểu qua Binder. Việc triển khai AOSP của WebView đáp ứng yêu cầu này.

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

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

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

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

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

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

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

Triển khai thiết bị:

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

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

3.5.1. Hạn chế trong nền

Nếu các quy trình triển khai thiết bị triển khai các hạn chế ứng dụng có trong AOSP hoặc mở rộng các hạn chế ứng dụng, thì các hạn chế đó:

• [C-1-1] PHẢI cung cấp thuộc tính tương tác của người dùng, trong đó người dùng có thể 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 các hạn chế trên từng ứng dụng.
• [C-1-3] KHÔNG được tự động áp dụng các hạn chế 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 hiệu quả của hệ thống, chẳng hạn như lỗi khoá ở chế độ thức, dịch vụ chạy trong thời gian dài và các tiêu chí khác. Các tiêu chí CÓ THỂ do những người triển khai thiết bị xác định nhưng PHẢI liên quan đến tác động của ứng dụng đối với tình trạng hệ thống. Những tiêu chí khác không hoàn toàn liên quan đến tình trạng hệ thống (chẳng hạn như ứng dụng không phổ biến trên thị trường) KHÔNG ĐƯỢC dùng làm tiêu chí.
• [C-1-4] KHÔNG ĐƯỢC tự động áp dụng các hạn chế ứng dụng cho các ứng dụng khi người dùng đã tắt các 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ế ứng dụng.
• [C-1-5] PHẢI thông báo cho người dùng về việc các hạn chế ứng dụng có được tự động áp dụng cho một ứng dụng hay không.
• [C-1-6] PHẢI trả về true cho ActivityManager.isBackgroundRestricted() khi ứng dụng bị hạn chế gọi API này.
• [C-1-7] KHÔNG ĐƯỢC hạn chế ứng dụng trên nền trước mà người dùng sử dụng một cách rõ ràng.
• [C-1-8] PHẢI tạm ngưng các hạn chế trên một ứng dụng trở thành ứng dụng trên nền trước khi người dùng rõ ràng bắt đầu sử dụng ứng dụng từng bị hạn chế.

3.6. Không gian tên API

Android tuân theo các quy ước không gian tên của gói và lớp do ngôn ngữ lập trình Java xác định. Để đảm bảo khả năng tương thích với các ứng dụng của 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) đối vớ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 các API hiển thị công khai trên nền tảng Android bằng cách thay đổi bất kỳ chữ ký lớp hoặc phương thức nào hoặc bằng cách xoá các lớp hoặc trường lớp.
• [C-0-2] KHÔNG ĐƯỢC thêm bất kỳ phần tử được hiển thị công khai nào (như lớp hoặc giao diện, hoặc các trường hoặc phương thức vào các lớp hoặc giao diện hiện có) hoặc API Kiểm tra hoặc Hệ thống vào các API trong không gian tên trên. "Phần tử được hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng điểm đánh dấu "@ẩn" như được sử 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 những 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 không gian tên chuẩn của Android, ngoại trừ các API tuỳ chỉnh:

• [C-0-5] KHÔNG ĐƯỢC nằm trong không gian tên do một tổ chức khác sở hữu hoặc tham chiếu đến một tổ chức khá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>) bị ảnh hưởng bởi việc sử dụng bộ nhớ tăng lên của các API đó.

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

Lưu ý rằng các hạn chế ở trên tương ứng với các quy ước tiêu chuẩn để đặt tên cho 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 Định nghĩa về khả năng tương thích.

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à đặc tả mã byte Dalvik và ngữ nghĩa.

• [C-0-2] PHẢI định cấu hình thời gian chạy Dalvik để phân bổ bộ nhớ phù hợp với nền tảng Android ngược dòng và như được chỉ định trong bảng sau. (Xem phần 7.1.1 để biết định nghĩa về kích thước màn hình và mật độ màn hình.)

• NÊN sử dụng Android RunTime (ART), triển khai ngược dòng tham chiếu của Định dạng có thể thực thi Dalvik và hệ thống quản lý gói của hoạt động triển khai tham chiếu.

• NÊN chạy kiểm thử mờ trong nhiều chế độ thực thi và cấu trúc mục tiêu để đảm bảo tính ổn định của thời gian chạy. Hã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à các quá trình triển khai thiết bị CÓ THỂ phân bổ thêm bộ nhớ cho mỗi ứng dụng.

Bố cục màn hình	Mật độ màn hình	Bộ nhớ tối thiểu của ứng dụng
Đồng hồ Android	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	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)
	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)
	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)
	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à tính năng hỗ trợ các ứng dụng bên thứ ba để thay thế trình chạy thiết bị (màn hình chính).

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

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

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

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

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

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

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

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

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

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

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 cũng như 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 khả năng 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 tương tác trên giao diện người dùng để thêm, định cấu hình, xem và xoá AppWidgets ngay trong Trình chạy.
• [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) trong tài liệu về SDK Android để biết thông tin chi tiết.
• 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ợ tiện ích ứng dụng bên thứ ba và tính năng ghim lối tắt trong ứng dụng, thì các thiết bị đó sẽ:

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

3.8.3. Thông báo

Android bao gồm các API Notification và NotificationManager cho phép nhà phát triển ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý và thu hút người dùng chú ý bằng cách sử dụng các thành phần phần cứng (ví dụ: âm thanh, rung và ánh sáng) cũng như 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 phần cứng triển khai thiết bị. 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 quá trình triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7.
• [C-1-2] PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp ảnh động, v.v.) được cung cấp trong API hoặc trong hướng dẫn kiểu biểu tượng của Thanh hệ thống/Thanh 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 các thông báo so với trải nghiệm được cung cấp trong quá trình 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à thông báo theo nhóm.
• [C-1-4] PHẢI cung cấp hành vi đầy đủ của API NotificationChannel được ghi lại 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 nhất định của ứng dụng bên thứ ba trên mỗi cấp độ kênh và 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ị các kênh thông báo đã xoá.
• [C-1-7] PHẢI hiển thị chính xác tất cả tài nguyên (hình ảnh, hình dán, biểu tượng, v.v.) được cung cấp thông qua Notification.MessagingStyle cùng với văn bản thông báo mà không cần phải tương tác thêm với người dùng. Ví dụ: PHẢI hiển thị tất cả tài nguyên, bao gồm cả các biểu tượng được cung cấp thông qua android.app.Person trong cuộc trò chuyện nhóm được đặt thông qua setGroupconversation.
• [C-SR] Giới hạn được đề xuất tự động hiển thị một thuộc tính tương tác của người dùng để chặn một thông báo nhất định của ứng dụng bên thứ ba trên mỗi kênh và cấp gói ứng dụng sau khi người dùng đóng thông báo đó nhiều lần.
• 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.
• CÓ THỂ chỉ quản lý chế độ hiển thị và thời điểm mà các ứng dụng bên thứ ba có thể thông báo cho người dùng về các sự kiện đáng chú ý để giảm thiểu các vấn đề an toàn, chẳng hạn như sự phân tâm của người lái xe.

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 các tài nguyên chính xác như được cung cấp thông qua lớp API Notification.Style và lớp con của chúng 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 lớp API Notification.Style và các lớp con của lớp đó.

Nếu quá trình triển khai thiết bị có hỗ trợ thông báo quan trọng: họ:

• [C-3-1] PHẢI sử dụng tài nguyên và chế độ xem thông báo quan trọng như mô tả trong lớp API Notification.Builder khi hiển thị thông báo quan trọng.
• [C-3-2] PHẢI hiển thị các thao tác được cung cấp thông qua Notification.Builder.addAction() cùng với nội dung thông báo mà không cần sự 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 các API NotificationListenerService cho phép ứng dụng (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.

Nếu hoạt động triển khai thiết bị báo cáo cờ tính năng android.hardware.ram.normal, thì chúng:

• [C-1-1] PHẢI cập nhật toàn bộ các 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ụ nghe được cài đặt và hỗ trợ người dùng, bao gồm mọi siêu dữ liệu đi kèm đối tượng Notification.
• [C-1-2] PHẢI tuân thủ lệnh gọi API snoozeNotification(), loại bỏ thông báo, rồi thực hiện lệnh gọi lại sau khoảng thời gian tạm ẩn đã đặ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-2-1] PHẢI phản ánh chính xác trạng thái thông báo tạm ẩn thông qua các API tiêu chuẩn như NotificationListenerService.getSnoozedNotifications().
• [C-2-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 từ từng ứng dụng bên thứ ba đã cài đặt, trừ phi các thông báo đó đến từ dịch vụ liên tục/trên nền trước.

3.8.3.3. Không làm phiền (Không làm phiề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-1-1] PHẢI triển khai một hoạt động sẽ phản hồi ý định ACTION_ Thông báo_POLICY_ACCESS_SETTINGS. Đối với các hoạt động triển khai với UI_MODE_TYPE_NORMAL, hoạt động này PHẢI là hoạt động mà người dùng có thể cấp hoặc từ chối quyền truy cập của ứng dụng vào cấu hình chính sách DND.
• [C-1-2] PHẢI, đối với trường hợp quá trình triển khai thiết bị đã cung cấp phương tiện để 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ị Các quy tắc DND tự động do ứng dụng tạo cùng với các quy tắc do người dùng tạo và xác định trước.
• [C-1-3] PHẢI tuân thủ các giá trị suppressedVisualEffects được truyền dọc NotificationManager.Policy và nếu ứng dụng đã đặt bất kỳ cờ nào trong trình đơn cài đặt DND hoặc supPRESSED_SCREEN_OFF hoặc UPPRESSED_ ứng dụng_SCREEN_ON.

3.8.4. Tìm kiếm

Android bao gồm các API cho phép nhà phát triển tích hợp tìm kiếm vào ứng dụng của họ và hiển thị dữ liệu của ứng dụng vào tìm kiếm hệ thống chung. Nói chung, chức năng này bao gồm một giao diện người dùng duy nhất trên toàn hệ thống cho phép người dùng nhập truy vấn, hiển thị đề xuất khi người dùng nhập và hiển thị kết quả. API Android cho phép nhà phát triển sử dụng lại giao diện này để cung cấp tính năng tìm kiếm trong ứng dụng của riêng họ và cho phép nhà phát triển cung cấp kết quả cho giao diện người dùng tìm kiếm toàn cầu chung.

• Các quá trình triển khai thiết bị Android PHẢI bao gồm chức năng tìm kiếm chung, một giao diện người dùng tìm kiếm chung duy nhất trên toàn hệ thống, có khả năng đưa ra các đề xuất theo thời gian thực để phản hồi hoạt động đầu vào của người dùng.

Nếu quá trình triển khai thiết bị có triển khai giao diện tìm kiếm chung, thì các thiết bị đó sẽ:

• [C-1-1] PHẢI triển khai các API cho phép các ứng dụng của bên thứ ba thêm đề xuất vào hộp tìm kiếm khi hộp tìm kiếm được chạy ở chế độ tìm kiếm toàn cục.

Nếu không có ứng dụng bên thứ ba nào được cài đặt sử dụng tìm kiếm chung:

• Hành vi mặc định PHẢI là hiển thị kết quả và đề xuất của công cụ tìm kiếm web.

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

Nếu 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 một trong hai cách sau:
  • Mỗi khi ứng dụng trợ lý truy cập vào ngữ cảnh, hiển thị một ánh sáng trắng xung quanh các cạnh của màn hình bằng hoặc vượt quá thời lượng và độ sáng của quá trình triển khai Dự án nguồn mở Android.
  • Đối với ứng dụng trợ lý được cài đặt trước, việc cung cấp thuộc tính tương tác cho người dùng trong phạm vi cách trình đơn cài đặt ứng dụng trợ lý và nhập bằng giọng nói mặc định, đồng thời chỉ chia sẻ ngữ cảnh khi người dùng gọi ứng dụng trợ lý một cách rõ ràng thông qua cụm từ kích hoạt hoặc nhập phím điều hướng hỗ trợ.
• [C-2-2] Hoạt động tương tác được chỉ định để chạy ứng dụng trợ lý như mô tả trong mục 7.2.3 PHẢI khởi chạy ứng dụng trợ lý do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService hoặc 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 API Toast để cho người dùng cuối thấy các chuỗi ngắn không theo phương thức. Các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn, đồng thời sử dụng API loại cửa sổ TYPE_APPLICATION_OVERLAY để hiện 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 với người dùng để chặn không cho một ứng dụng hiển thị cửa sổ cảnh báo 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 ngắn từ ứng dụng cho người dùng cuối theo cách dễ thấy.

3.8.6. Giao diện

Android cung cấp "giao diện" làm 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 "Holo" và "Material" nhóm chủ đề dưới dạng một tập hợp các kiểu được xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn phù hợp với Giao diện chủ đề Holo do SDK Android xác định.

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ác ứng dụng.
• [C-1-2] PHẢI hỗ trợ bộ giao diện “Material” và KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Material nào hoặc các thành phần của những thành phần đó hiển thị với ứng dụng.

Android cũng bao gồm nhóm giao diện "Mặc định của thiết bị" dưới dạng một nhóm 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 giao diện thiết bị do người triển khai thiết bị xác định.

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

Android hỗ trợ 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 lấp đầy khu vực phía sau thanh trạng thái và điều hướng bằng nội dung ứng dụng của họ. Để mang lại trải nghiệm nhất quán cho nhà phát triển trong cấu hình này, kiểu biểu tượng thanh trạng thái cần đượ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 biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) và thông báo do hệ thống đưa ra, trừ phi biểu tượng đó cho biết trạng thái có vấn đề hoặc ứng dụng yêu cầu thanh trạng thái sáng bằng cờ SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] Các quá trình triển khai thiết bị Android PHẢI thay đổi màu của các biểu tượng trạng thái hệ thống thành màu đen (để biết thông tin chi tiết, vui lòng tham khảo R.style) khi một ứng dụng yêu cầu thanh trạng thái sáng.

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

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

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

• Các quá trình triển khai thiết bị có khả năng chạy hình nền động một cách ổn định như mô tả ở trên NÊN 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, một giao diện người dùng cấp hệ thống để chuyển đổi tác vụ và hiển thị các hoạt động cũng như tác vụ đã truy cập gần đây bằng cách sử dụng hình thu nhỏ về trạng thái đồ hoạ của ứng dụng tại thời điểm người dùng rời khỏi ứng dụng lần cuối.

Quá trình triển khai thiết bị, bao gồm cả phím điều hướng chức năng gần đây như đã nêu chi tiết trong phần 7.2.3 CÓ THỂ làm 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 làm thay đổi giao diện, thì 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.
• [C-1-2] PHẢI triển khai hành vi ghim màn hình và cung cấp cho người dùng trình đơn cài đặt để bật/tắt tính năng này.
• 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 2 ứng dụng được sử dụng gần đây nhất khi nhấn phím chức năng gần đây 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 nhấn và giữ phím 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.
• [SR] Are Always REVIEW để sử dụng giao diện người dùng Android ngược dòng (hoặc một giao diện tương tự dựa trên hình thu nhỏ) cho màn hình tổng quan.

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

Android có hỗ trợ chức năng 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ọ sẽ:

• [C-1-1] PHẢI khai báo tính năng nền tảng android.software.input_methods và hỗ trợ API IME như xác định trong tài liệu SDK Android.
• [C-1-2] PHẢI cung cấp một cơ chế mà người dùng có thể truy cập để thêm và định cấu hình các phương thức nhập của bên thứ ba nhằm phản hồi ý định android.settings.INPUT_METHOD_SETTINGS.

Nếu các hoạt động triển khai thiết bị khai báo cờ tính năng android.software.autofill, thì chúng:

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

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. Mẫu này 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ơ)

Android có hỗ trợ trình bảo vệ màn hình tương tác, trước đây được gọi là Dreams (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. Thiết bị Android Watch CÓ THỂ triển khai trình bảo vệ màn hình, nhưng các kiểu triển khai thiết bị khác NÊN hỗ trợ trình bảo vệ màn hình và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình trình bảo vệ màn hình theo ý định android.settings.DREAM_SETTINGS.

3.8.12. Vị trí

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

• [C-1-2] PHẢI hiển thị current status of location (trạng thái hiện tại của vị trí) trên trình đơn Location (Vị trí) trong phần Settings (Cài đặt).
• [C-1-3] KHÔNG ĐƯỢC hiển thị chế độ vị trí trên trình đơn Vị trí trong phần Cài đặt.

3.8.13. Unicode và phông chữ

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

Nếu 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,
  • Phạm vi toàn bộ Unicode 7.0 của tiếng Latinh, Hy Lạp và chữ Kirin, bao gồm các phạm vi A, B, C và D mở rộng Latinh và tất cả các ký tự trong khối ký hiệu tiền tệ của Unicode 7.0.
• NÊN hỗ trợ màu da và các biểu tượng cảm xúc gia đình đa dạng theo quy định trong Báo cáo kỹ thuật của 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 tuân thủ Unicode, thường được gọi là “Zawgyi” để hiển thị tiếng Myanmar.

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] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Nhiều cửa sổ

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

• [C-1-1] PHẢI triển khai(các) chế độ nhiều cửa sổ như vậy theo hành vi và API của ứng dụng được mô tả trong tài liệu hỗ trợ chế độ nhiều cửa sổ của SDK Android và đáp ứng các yêu cầu sau:
• [C-1-2] PHẢI tôn trọng android:resizeableActivity do một ứng dụng thiết lập trong tệp AndroidManifest.xml theo 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 nhỏ hơn 440 dp và chiều rộng màn hình nhỏ hơn 440 dp.
• [C-1-4] Một hoạt động KHÔNG ĐƯỢC đổi kích thước thành kích thước nhỏ hơn 220dp trong chế độ nhiều cửa sổ khác với chế độ 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 PHẢI hỗ trợ chế độ dạng tự do.

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

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

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

• [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 mình theo chỉ định của hoạt động PIP hiện tại thông qua API setActions().
• [C-3-3] PHẢI hỗ trợ tỷ lệ khung hình lớn hơn hoặc bằng 1:2,39 và nhỏ hơn hoặc bằng 2,39:1 theo chỉ định của hoạt động PIP thông qua API setAspectRatio().
• [C-3-4] PHẢI sử dụng KeyEvent.KEYCODE_WINDOW để điều khiển cửa sổ PIP; nếu không triển khai chế độ PIP, khoá PHẢI 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ị ở chế độ PIP; việ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-3-6] PHẢI phân bổ chiều rộng và chiều cao tối thiểu là 108 dp cho cửa sổ PIP và chiều rộng tối thiểu là 240 dp và chiều cao 135 dp cho cửa sổ PIP khi Configuration.uiMode được định cấu hình là UI_MODE_TYPE_TELEVISION.

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

Android hỗ trợ vết cắt trên màn hình như mô tả trong tài liệu SDK. API DisplayCutout xác định một vùng ở cạnh màn hình không hoạt động để hiển thị nội dung.

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

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

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

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

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

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ý Ứng dụng chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị như mô tả bên dưới:
  • Khi quá trình triển khai thiết bị chưa được định cấu hình dữ liệu người dùng, quá trình triển khai sẽ:
    • [C-1-3] PHẢI báo cáo true cho DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị để phản hồi thao tác theo ý định android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị 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 được thông báo NFC chứa bản ghi thuộc loại MIME MIME_TYPE_PROVISIONING_NFC.
  • Khi quá trình triển khai thiết bị có dữ liệu người dùng, quá trình triển khai:
    • [C-1-6] PHẢI báo cáo false cho DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] KHÔNG ĐƯỢC đăng ký bất kỳ ứng dụng DPC nào làm Ứng dụng chủ sở hữu thiết bị nữa.
• [C-1-2] PHẢI yêu cầu một số hành động rõ ràng trong quy trình cấp phép để đồng ý với việc ứng dụng được đặt làm Chủ sở hữu thiết bị. Sự đồng ý có thể được thể hiện thông qua hành động của người dùng hoặc bằng một số phương thức có lập trình trong quá trình cấp phép, nhưng KHÔNG được mã hoá cứ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ị.

Nếu quá trình triển khai thiết bị khai báo android.software.device_admin, nhưng cũng bao gồm giải pháp quản lý Chủ sở hữu thiết bị độc quyền và cung cấp cơ chế quảng bá một ứng dụng được định cấu hình trong giải pháp của họ dưới dạng "Chủ sở hữu thiết bị tương đương" thành "Chủ sở hữu thiết bị" tiêu chuẩn được các API DevicePolicyManager tiêu chuẩn của Android công nhận, 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 giải pháp 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ò "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à quy trình do android.app.action.PROVISION_MANAGED_DEVICE khởi tạo trước khi đăng ký ứng dụng DPC làm "Chủ sở hữu thiết bị".
• CÓ THỂ có dữ liệu người dùng trên thiết bị trước khi đăng ký ứng dụng DPC làm "Chủ sở hữu thiết bị".

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

Nếu các hoạt động triển khai thiết bị khai báo android.software.managed_users, thì các 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 Hồ sơ được quản lý mới.

• [C-1-2] Trải nghiệm người dùng của quy trình cấp phép hồ sơ được quản lý (quy trình do android.app.action.PROVISION_MANAGED_PROFILE) khởi tạo PHẢI phù hợp với cách triển khai AOSP.

• [C-1-3] PHẢI cung cấp các tương tác người dùng sau đây trong phần Cài đặt để cho người dùng biết khi một chức năng hệ thống cụ thể đã bị Trình điều khiển chính sách thiết bị (DPC) tắt:

  • Một biểu tượng nhất quán hoặc thuộc tính tương tác khác của người dùng (ví dụ: biểu tượng thông tin AOSP ngược dòng) để thể hiện thời điểm một chế độ cài đặt cụ thể bị Quản trị viên thiết bị hạn chế.
  • 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 qua setShortSupportMessage.
  • Biểu tượng của ứng dụng DPC.

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 API android.app.admin.DevicePolicyManager.
• [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ư Recents (Gần đây) và Thông báo.
• [C-1-4] PHẢI hiển thị biểu tượng thông báo (tương tự như huy hiệu công việc ngược dòng của AOSP) để cho biết khi nào người dùng đang ở trong ứng dụng hồ sơ được quản lý.
• [C-1-5] PHẢI hiển thị thông báo ngắn cho biết người dùng đang ở trong hồ sơ được quản lý nếu và khi thiết bị 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 Intent "Chooser" (Bộ chọn) để cho phép người dùng chuyển tiếp ý định từ hồ sơ được quản lý đến người dùng chính hoặc ngược lại, nếu được Trình kiểm soát chính sách thiết bị bật.
• [C-1-7] Khi có hồ sơ được quản lý, PHẢI hiển thị các thuộc tính tương tác sau đây cho người dùng cho cả người dùng chính và hồ sơ được quản lý:
  • Tính riêng pin, vị trí, dữ liệu di động và mức sử dụng 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 người dùng chính hoặc hồ sơ được quản lý.
  • Quản lý độc lập các ứng dụng được cài đặt trong người dùng chính hoặc hồ sơ được quản lý.
  • Quản lý độc lập các tài khoản trong người dùng chính hoặc hồ sơ được quản lý.
• [C-1-8] PHẢI đảm bảo trình quay số được cài đặt sẵn, danh bạ và ứng dụng nhắn tin có thể tìm kiếm và tra cứu thông tin người gọi trong hồ sơ được quản lý (nếu có) cùng với thông tin từ hồ sơ chính, nếu Trình kiểm soát chính sách thiết bị cho phép.
• [C-1-9] PHẢI đảm bảo đáp ứng tất cả các yêu cầu về bảo mật áp dụng cho một thiết bị có bật nhiều người dùng (xem mục 9.5), ngay cả khi hồ sơ được quản lý không được tính là một người dùng khác ngoài người dùng chính.
• [C-1-10] PHẢI hỗ trợ khả năng chỉ định một màn hình khoá riêng đáp ứng 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ơ được quản lý.
  • Quá trình triển khai thiết bị PHẢI tuân thủ ý định DevicePolicyManager.ACTION_SET_NEW_PASSWORD và hiển thị giao diện để định cấu hình thông tin đăng nhập màn hình khoá riêng biệt cho hồ sơ được quản lý.
  • Thông tin đăng nhập màn hình khoá của hồ sơ được quản lý PHẢI sử dụng cùng một cơ chế lưu trữ và quản lý thông tin xác thực như hồ sơ gốc, như được nêu trên Trang web dự án nguồn mở Android.
  • Chính sách mật khẩu DPC chỉ ĐƯỢC á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 được gọi trên thực thể DevicePolicyManager do getParentProfileInstance trả về.
• Khi danh bạ từ hồ sơ được quản lý hiển thị trong nhật ký cuộc gọi cài đặt trước, giao diện người dùng trong cuộc gọi, thông báo cuộc gọi đang diễn ra và cuộc gọi nhỡ, danh bạ và ứng dụng nhắn tin PHẢI được gắn huy hiệu bằng cùng một huy hiệu dùng để biểu thị các ứ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 thuộc tính tương tác với người dùng để đăng xuất khỏi người dùng hiện tại và chuyển về người dùng chính trong phiên nhiều người dùng khi isLogoutEnabled trả về true. Bạn PHẢI cho phép người dùng truy cập vào thuộc tính tương tác trên màn hình khoá mà không cần mở khoá 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 sử dụng thiết bị dễ dàng hơn. Ngoài ra, Android cung cấp các API nền tảng cho phép triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho các sự kiện của người dùng và hệ thống, đồng thời tạo các cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng 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 khung hỗ trợ tiếp cận của Android như mô tả trong tài liệu SDK về accessibility API.
• [C-1-2] PHẢI tạo các sự kiện hỗ trợ tiếp cận và phân phối AccessibilityEvent thích hợp cho tất cả các phương thức triển khai AccessibilityService đã đăng ký như được nêu trong SDK.
• [C-1-3] PHẢI thực hiện ý định android.settings.ACCESSIBILITY_SETTINGS để cung cấp một cơ chế mà người dùng có thể tiếp cận nhằm bật và tắt các dịch vụ hỗ trợ tiếp cận của bên thứ ba cùng với các dịch vụ hỗ trợ tiếp cận được cài đặt trước.
• [C-1-4] PHẢI thêm một nút vào thanh điều hướng của hệ thống để cho phép người dùng điều khiển dịch vụ hỗ trợ tiếp cận khi các dịch vụ hỗ trợ tiếp cận đã bật khai báo AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Lưu ý: Đối với các hoạt động triển khai thiết bị không có thanh điều hướng hệ thống, yêu cầu này không được áp dụng, nhưng các quá trình triển khai thiết bị PHẢI cung cấp khả năng tương tác cho người dùng để kiểm soát các dịch vụ hỗ trợ tiếp cận 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 sẵn này dưới dạng ứng dụng Direct Boot Aware (Nhận biết khởi động trực tiếp) khi bộ nhớ dữ liệu được mã hoá bằng tính năng Mã hoá dựa trên tệp (FBE).
• NÊN cung cấp một cơ chế trong quy trình thiết lập có sẵn để người dùng bật các dịch vụ hỗ trợ tiếp cận có liên quan, cũng như các tuỳ chọn để điều chỉnh cỡ chữ, kích thước hiển thị và cử chỉ thu phóng.

3,11. Chuyển văn bản thành giọng nói

Android có những API cho phép ứng dụng dùng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ triển khai dịch vụ TTS.

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

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

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 công cụ TTS để sử dụng ở cấp hệ thống.

3,12. Khung đầu vào TV

Khung đầu vào cho TV Android (TIF) đơn giản hoá việc phân phối nội dung trực tiếp tới các thiết bị Android TV. TIF cung cấp một API tiêu chuẩn để tạo các mô-đun đầu vào điều khiển thiết bị Android 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 có thể cài đặt và sử dụng một ứng dụng dùng những API này và dịch vụ đầu vào dựa trên TIF của bên thứ ba trên thiết bị.

3,13. Cài đặt nhanh

Android cung cấp một thành phần giao diện người dùng trong phần Cài đặt nhanh cho phép truy cập nhanh vào các thao tác thường dùng hoặc cần thiết.

Nếu quá trình triển khai thiết bị có thành phần giao diện người dùng Cài đặt nhanh, thì các quá trình này sẽ:

• [C-1-1] PHẢI cho phép người dùng thêm hoặc xoá thẻ thông tin được cung cấp thông qua API quicksettings từ ứng dụng bên thứ ba.
• [C-1-2] KHÔNG ĐƯỢC tự động thêm trực tiếp ô từ mộ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ả các ô do người dùng thêm từ ứng dụng bên thứ ba cùng với các ô cài đặt nhanh do hệ thống cung cấp.

3,14. Giao diện người dùng 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 các ứng dụng của bên thứ ba thông qua MediaBrowser hoặc MediaSession, thì Ứng dụng:

• [C-1-2] PHẢI hiển thị rõ ràng các biểu tượng thu được qua getIconBitmap() hoặc getIconUri() và tiêu đề thu được qua getTitle() như mô tả trong MediaDescription. Có thể rút ngắn tiêu đề để tuân thủ các quy định về an toàn (ví dụ: 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 do ứng dụng bên thứ ba này cung cấp.

• [C-1-4] PHẢI cho phép người dùng tương tác với toàn bộ hệ phân cấp MediaBrowser. 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ụ: sự mất tập trung của người lái xe), nhưng KHÔNG ĐƯỢC ưu tiên xử lý dựa trên nội dung hoặc nhà cung cấp nội dung.

• [C-1-5] PHẢI xem xét thao tác nhấn đúp vào KEYCODE_HEADSETHOOK hoặc KEYCODE_MEDIA_PLAY_PAUSE là KEYCODE_MEDIA_NEXT cho MediaSession.Callback#onMediaButtonEvent.

3,15. Ứng dụng tức thì

Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu sau:

• [C-0-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-0-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ừ phi 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-0-3] Ứng dụng tức thì KHÔNG ĐƯỢC tương tác rõ ràng với các ứng dụng đã cài đặt trừ khi thành phần này hiển thị qua android:visibleTo InstantApps.
• [C-0-4] Ứng dụng đã cài đặt KHÔNG ĐƯỢC xem thông tin chi tiết về Ứng dụng tức thì trên thiết bị trừ 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 sau đây cho người dùng để 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-0-5] PHẢI cung cấp một thuộc tính tương tác cho người dùng để xem và xoá các Ứng dụng tức thì được lưu vào bộ nhớ đệm cục bộ cho từng gói ứng dụng.
  • [C-0-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 được trong khi Ứng dụng tức thì đang chạy trên nền trước. Thông báo này cho người dùng PHẢI cho biết rằng Ứng dụng tức thì không yêu cầu cài đặt và cung cấp một thuộc tính tương tác với người dùng để hướng người dùng đến màn hình thông tin ứng dụng trong phần Cài đặt. Đối với Ứng dụng tức thì được chạy thông qua ý định web, như được xác định bằng cách sử dụng một ý định với hành động được đặt thành Intent.ACTION_VIEW và với lược đồ "http" hoặc "https", một thuộc tính tương tác khác dành cho người dùng PHẢI cho phép người dùng không chạy Ứng dụng tức thì và chạy đường liên kết được liên kết với trình duyệt web đã định cấu hình nếu có trình duyệt trên thiết bị.
  • [C-0-7] PHẢI cho phép truy cập vào các Ứng dụng tức thì chạy qua hàm Recents (Gần đây) nếu thiết bị có hàm Recents (Gần đây).

3,16. Ghép nối thiết bị đồng hành

Android hỗ trợ tính năng ghép nối thiết bị đồng hành để quản lý việc liên kết với các thiết bị đồng hành một cách hiệu quả hơn, đồng thời cung cấp API CompanionDeviceManager cho các ứng dụng dùng 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-1-2] PHẢI đảm bảo các API trong gói android.companion được triển khai đầy đủ.
• [C-1-3] PHẢI cung cấp thuộc tính tương tác cho người dùng để người dùng chọn/xác nhận một thiết bị đồng hành hiện diện và hoạt động được.

3.17. Ứng dụng nặng

Nếu các quá trình triển khai thiết bị khai báo tính năng FEATURE_CANT_SAVE_STATE, thì chúng:

• [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 tại một thời điểm. 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 vào màn hình chính trong khi rời khỏi một hoạt động đang hoạt động của hệ thống, thay vì nhấn nút quay lại mà không còn hoạt động nào đang hoạt động trong hệ thống), thì các quá trình triển khai thiết bị PHẢI ưu tiên ứng dụng đó trong RAM giống như đối với những hoạt động khác dự kiến vẫn sẽ chạy (chẳng hạn như dịch vụ trên nền trước). Khi một ứng dụng như vậy chạy ở chế độ nền, hệ thống vẫn có thể áp dụng các tính năng quản lý nguồn điện cho ứng dụng đó, chẳng hạn như hạn chế quyền truy cập vào CPU và mạng.
• [C-1-2] PHẢI cung cấp một thuộc tính tương tác trên giao diện người dùng để chọn ứng dụng sẽ không tham gia vào cơ chế lưu/khôi phục trạng thái thông thường sau khi người dùng chạy ứng dụng thứ hai được khai báo bằng thuộc tính cantSaveState.
• [C-1-3] KHÔNG ĐƯỢC áp dụng các thay đổi khác trong chính sách cho các ứng dụng chỉ định cantSaveState, chẳng hạn như thay đổi hiệu suất của CPU hoặc thay đổi mức độ ưu tiên của việc lập lịch.

Nếu quá trình triển khai thiết bị không khai báo tính năng FEATURE_CANT_SAVE_STATE, thì chúng sẽ:

• [C-1-1] PHẢI bỏ qua thuộc tính cantSaveState do các ứng dụng đặt và KHÔNG ĐƯỢC thay đổi hành vi của ứng dụng dựa trên thuộc tính đó.

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 các tệp “.apk” của Android do công cụ “aapt” tạo ra trong SDK Android chính thức.
• Vì yêu cầu trên có thể gây khó khăn cho việc triển khai thiết bị, bạn NÊN sử dụng hệ thống quản lý gói của phương thức triển khai tham chiếu AOSP (Dự án nguồn mở Android) các hoạt động triển khai thiết bị.

Triển khai thiết bị:

• [C-0-2] PHẢI hỗ trợ xác minh tệp “.apk” bằng Lược đồ chữ ký APK v3 , Lược đồ chữ ký APK v2 và ký JAR.
• [C-0-3] KHÔNG ĐƯỢC mở rộng định dạng .apk, Tệp kê khai Android, mã byte Dalvik hoặc mã byte RenderScript sao cho các tệp đó không được cài đặt và chạy đúng cách trên các thiết bị tương thích khác.

• [C-0-4] KHÔNG ĐƯỢC cho phép các ứng dụng khác với "người cài đặt bản ghi" hiện tại để gói tự động gỡ cài đặt ứng dụng mà không có bất kỳ xác nhận nào của người dùng, như được nêu trong SDK về quyền DELETE_PACKAGE. Trường hợp ngoại lệ duy nhất là ứng dụng xác minh gói hệ thống xử lý ý định PACKAGE_NEEDS_VERIFICATION và ứng dụng trình quản lý bộ nhớ xử lý ý định ACTION_MANAGE_STORAGE.

• [C-0-5] PHẢI có một hoạt động xử lý ý định android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] KHÔNG ĐƯỢC cài đặt gói ứng dụng không rõ nguồn gốc, trừ khi ứng dụng yêu cầu cài đặt đáp ứng tất cả các yêu cầu sau:

  • Ứng dụng PHẢI khai báo quyền REQUEST_INSTALL_PACKAGES hoặc đặt android:targetSdkVersion ở mức 24 trở xuống.
  • Ứng dụng PHẢI được người dùng cấp quyền để cài đặt ứng dụng không rõ nguồn gốc.

• 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 cài đặt ứ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 dưới dạng không hoạt động và trả về RESULT_CANCELED cho startActivityForResult(), nếu quá trình triển khai thiết bị không muốn cho phép người dùng có lựa chọn này. Tuy nhiên, ngay cả trong những trường hợp như vậy, họ PHẢI cho người dùng biết tại sao không có lựa chọn nào như vậy.

• [C-0-7] PHẢI hiển thị hộp thoại cảnh báo có chuỗi cảnh báo được cung cấp qua API hệ thống PackageManager.setHarmfulAppWarning cho người dùng trước khi khởi chạy hoạt động trong ứng dụng đã được cùng một API hệ thống PackageManager.setHarmfulAppWarning đánh dấu là có thể gây 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 chạy ứng dụng trên hộp thoại cảnh báo.

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 nội dung đa phương tiện, bộ mã hoá, bộ giải mã, loại tệp và định dạng vùng chứa được định nghĩa trong mục 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 khả năng hỗ trợ của bộ mã hoá, bộ giải mã có sẵn cho ứ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 các ứng dụng bên thứ ba tất cả các định dạng mà nó có thể mã hoá. Dữ liệu này bao gồm tất cả các bit mà bộ mã hoá tạo ra và các cấu hình đượ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 NÊN sử dụng và lưu trữ vùng đệm đầu vào và chỉ trả về vùng đệm đầu vào sau khi xử lý.
  • KHÔNG ĐƯỢC giữ lại bộ đệm đã giải mã lâu hơn thời gian quy định của tiêu chuẩn (ví dụ: SPS).
  • KHÔNG ĐƯỢC giữ lại vùng đệm mã hoá lâu hơn thời gian mà cấu trúc GOP yêu cầu.

Tất cả các bộ mã hoá và giải mã được liệt kê trong phần dưới đây đều được cung cấp dưới dạng phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên từ Dự án nguồn mở Android.

Xin lưu ý rằng cả Google và Open Handset Alliance không 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 người 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 được khuyên rằng việc triển khai mã này, kể cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ chủ 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 quá trình triển khai thiết bị khai báo android.hardware.microphone, thì các quá trình đó PHẢI hỗ trợ mã hoá các định dạng âm thanh sau đây và cung cấp 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 API android.media.MediaCodec.

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 các quá trình triển khai thiết bị khai báo có hỗ trợ tính năng android.hardware.audio.output, thì các quá trình triển khai thiết bị PHẢI hỗ trợ giải mã các định dạng âm thanh sau đây:

• [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 (Cấu hình HE AAC mở rộng ISO/IEC 23003-3, bao gồm Cấu hình cơ sở USAC và Cấu hình kiểm soát dải động ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE bao gồm độ phân giải cao định dạng âm thanh lên đến 24 bit, 192 kHz tốc độ lấy mẫu, và 8 kênh. Xin lưu ý rằng yêu cầu này chỉ nhằm mục đích giải mã và thiết bị được phép lấy mẫu và giảm độ phân giải trong giai đoạn phát.
• [C-1-10] Opus

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

• [C-2-1] Giải mã PHẢI được thực hiện mà không cần trộn giảm (ví dụ: luồng 5.0 AAC PHẢI được giải mã thành năm kênh PCM, luồng 5.1 AAC PHẢI được giải mã thành sáu kênh PCM).
• [C-2-2] Siêu dữ liệu dải động PHẢI được xác định trong "Dynamic Range Control (DRC)" trong ISO/IEC 14496-3 và các khoá DRC android.media.MediaFormat để định cấu hình các hành vi liên quan đến dải động của bộ giải mã âm thanh. Khoá AAC DRC được ra mắt trong API 21 và có các khoá sau: 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.
• [SR] Nó được liệt kê ra rằng các yêu cầu C-2-1 và C-2-2 ở trên được đáp ứng bởi tất cả các bộ giải mã âm thanh AAC.

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

• [C-3-1] Độ to và siêu dữ liệu 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 đã đặt bằng các khoá android.media.MediaFormat sau: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL và KEY_AAC_DRC_EFFECT_TYPE.

Bộ giải mã 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 bằng Cấu hình kiểm soát dải động ISO/IEC 23003-4.

Nếu ISO/IEC 23003-4 được hỗ trợ và nếu cả siêu dữ liệu ISO/IEC 23003-4 và ISO/IEC 14496-3 đều có trong luồng bit được giải mã, thì:

• 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 theo thứ tự byte gốc 16 bit PCM qua API android.media.MediaCodec.

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 tốc độ lấy mẫu tiêu chuẩn 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 tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Cấu hình (AAC nâng cao+)	Hỗ trợ nội dung mono/stereo/5.0/5.1 với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC độ trễ thấp nâng cao)	Hỗ trợ nội dung mono/stereo với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC (Hoa Kỳ)	Hỗ trợ nội dung mono/stereo với tốc độ lấy mẫu tiêu chuẩn từ 7,35 đế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/giây đến 23,85 kbit/giây được lấy mẫu tại 16 kHz, như xác định tại AMR-WB, Đa tốc độ thích ứng – 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 hỗ trợ ít nhất chế độ Đơn âm và Âm thanh nổi. Tốc độ lấy mẫu lên đến 192 kHz PHẢI được hỗ trợ; PHẢI hỗ trợ độ phân giải 16 bit và 24 bit. Xử lý dữ liệu âm thanh 24 bit FLAC PHẢI khả dụng 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ợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody	Loại 0 và 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		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. Trình trích xuất SÓNG PHẢI hỗ trợ PCM tuyến tính 16, 24, 32 bit và nổi 32 bit (tốc độ lên đến giới hạn phần cứng). Tốc độ lấy mẫu PHẢI được hỗ trợ từ 8 kHz đến 192 kHz.	WAVE (.wav)
Opus		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

Nếu các quá trình triển khai thiết bị hỗ trợ phương thức mã hoá HEIC qua android.media.MediaCodec cho loại nội dung đa phương tiện MIMETYPE_IMAGE_ANDROID_HEIC, thì các quá trình đó:

• [C-1-1] PHẢI cung cấp bộ mã hoá HEVC bộ mã hoá HEVC có tăng tốc phần cứng để hỗ trợ chế độ kiểm soát tốc độ bit BITRATE_MODE_CQ, cấu hình 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] 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-1-1] PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu ứng dụng yêu cầu, chẳng hạn như qua cấu hình ARGB_8888 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)

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ợ định dạng màu linh hoạt YUV420 8:8:8 (COLOR_FormatYUV420Flexible) cho đến CodecCapabilities.

• [SR] "{NÊN DÙNG" để hỗ trợ định dạng màu RGB888 cho chế độ Bề mặt đầu vào.

• [C-1-3] PHẢI hỗ trợ ít nhất một trong các định dạng màu YUV420 phẳng hoặc bán phẳng 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.

5.1.7. Bộ mã hoá và giải mã video

• Để có chất lượng chấp nhận được của các dịch vụ hội nghị truyền hình và phát video trực tuyến, việc triển khai thiết bị NÊN sử dụng bộ mã hoá và giải mã phần cứng (codec) VP8 đáp ứng các yêu cầu này.

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] Bộ mã hoá và giải mã video PHẢI hỗ trợ kích thước bộ đệm byte đầu ra và đầu vào sao cho phù hợp với khung nén và không nén lớn nhất có thể thực hiện được theo quy định của tiêu chuẩn và cấu hình, nhưng cũng không được phân bổ quá mức.

• [C-1-2] Bộ mã hoá và giải mã video PHẢI hỗ trợ các định dạng màu linh hoạt YUV420 8:8:8 (COLOR_FormatYUV420Flexible) đến CodecCapabilities.

• [C-1-3] Bộ mã hoá và bộ giải mã video PHẢI hỗ trợ ít nhất một trong hai định dạng màu YUV420 phẳng hoặc bán phẳng 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.

• [SR] Bộ mã hoá và bộ giải mã video được MẠNG NÊN hỗ trợ ít nhất một trong những phần cứng được tối ưu hóa phẳng hoặc bán phẳng định dạng màu YUV420 8:8:8 (YV12, NV12, NV21 hoặc định dạng tối ưu hóa nhà cung cấp tương đương.)

• [C-1-5] Bộ giải mã video hỗ trợ định dạng độ sâu bit cao (9+ bit mỗi kênh) PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu ứng dụng yêu cầu. Điều này PHẢI được phản ánh bằng cách hỗ trợ định dạng màu YUV420 8:8:8 qua android.media.MediaCodecInfo.

Nếu các quá trình triển khai thiết bị quảng cáo tính năng hỗ trợ hồ sơ HDR thông qua Display.HdrCapabilities, thì họ:

• [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 hoạt động triển khai thiết bị quảng cáo tính năng hỗ trợ làm mới nội bộ thông qua FEATURE_IntraRefresh trong lớp MediaCodecInfo.CodecCapabilities, thì các hoạt động đó:

• [C-3-1] PHẢI hỗ trợ khoảng thời gian làm mới trong phạm vi từ 10 - 60 khung hình và hoạt động chính xác trong vòng 20% của khoảng thời gian làm mới đã định cấu hình.

Trừ phi ứng dụng chỉ định khác bằng cách sử dụng khoá định dạng KEY_COLOR_FORMAT, việc 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 đầu ra Surface.
• [C-4-2] PHẢI mặc định là định dạng màu YUV420 8:8:8 được tối ưu hóa để đọc CPU nếu được định cấu hình để không sử dụng đầu ra Surface.

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

Định dạng/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 phần 5.2 và 5.3 để biết 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 phần 5.2 và 5.3 để biết 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)

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ả dưới đây.

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, 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 bộ mã hoá và giải mã phương tiện thông qua các API OMX hoặc Codec 2.0 (hoặc cả hai) như trong Dự án nguồn mở Android và không vô hiệu hóa hoặc tránh né các biện pháp bảo vệ bảo mật. Điều này 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, mà chỉ hỗ trợ cho ít nhất một trong các API này.
• [C-SR] AreRENDERED ĐỀ XUẤT to include support for 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ừ 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-2-2] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google". PHẢI dựa trên mã nguồn Dự án nguồn mở Android.
• [C-SR] Are được linh hoạt đề xuất rằng các bộ mã hoá và giải mã phần mềm OMX chạy trong quy trình bộ mã hoá và giải mã không có quyền truy cập vào các trình điều khiển phần cứng không phải là trình lập bản đồ 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 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 trong quy trình giải mã phần mềm như được cung cấp trong Dự án nguồn mở Android để có thể cấp quyền truy cập vào bộ mã hoá và giải mã phần mềm 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 mã nguồn Dự án nguồn mở Android.

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 đặc điểm bộ mã hoá và giải mã nội dung đa phương tiện qua API MediaCodecInfo.

Cụ thể:

• [C-1-2] Các bộ mã hoá và giải mã có tên bắt đầu bằng "OMX". PHẢI sử dụng các API OMX và có tên tuân thủ nguyên tắc đặt tên 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 phù hợp với nguyên tắc đặt tên của Codec 2.0 cho Android.
• [C-1-4] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google". hoặc "c2.android". KHÔNG ĐƯỢC mô tả là nhà cung cấp hoặc 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 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 mô tả là chỉ có phần mềm.
• [C-1-6] Codec không có trong Dự án nguồn mở Android hoặc không dựa trên mã nguồn trong dự án đó PHẢI được mô tả là nhà cung cấp.
• [C-1-7] Những bộ mã hoá và giải mã sử dụng tính năng tăng tốc phần cứng PHẢI được mô tả là được tăng tốc phần cứng.
• [C-1-8] Tên bộ mã hoá và giải mã KHÔNG ĐƯỢC gây hiểu lầm. Ví dụ: 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ợ phương thức 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ợ những đị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ả 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 pixel (khác)	1408 x 1152 pixel (H263) 1280 x 720 pixel (khác)	1920 x 1080 pixel (trừ MPEG4)	3840 x 2160 pixel (HEVC, VP9)

• [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 chỉ số PHẢI liệt kê tất cả các điểm hiệu suất chuẩn được hỗ trợ (được liệt kê trong API PerformancePoint), trừ phi các điểm đó 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, các kênh NÊN công bố các điểm hiệu suất mở rộng nếu hỗ trợ hiệu suất bền vững cho video ngoài một trong các điểm hiệu suất chuẩn được liệt kê.

5.2. Mã hoá video

Nếu quá trình triển khai trên thiết bị có hỗ trợ bất kỳ bộ mã hoá video nào và được cung cấp cho các ứng dụng bên thứ ba, thì các quy trình đó:

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

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

• [C-1-1] PHẢI bao gồm sự hỗ trợ của ít nhất một trong các bộ mã hoá video VP8 hoặc H.264, và làm cho nó có sẵn 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 cho các ứng dụng của bên thứ ba.

Nếu các quá trình triển khai thiết bị hỗ trợ bộ mã hoá video H.264, VP8, VP9 hoặc HEVC và cung cấp bộ mã hoá này cho các ứng dụng của bên thứ ba, thì chúng:

• [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 PHẢI 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 quá trình triển khai thiết bị hỗ trợ bộ mã hoá video MPEG-4 SP và cung cấp bộ mã hoá cho các ứng dụng bên thứ ba, thì các thiết bị đó:

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

Nếu các phương pháp 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, đồng thời 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ị thông qua các API android.camera:

• [C-4-1] tất cả bộ mã hoá video và hình ảnh đượ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ả các bộ mã hoá video hoặc hình ảnh.

5.2.1. H.263

Nếu quá trình triển khai thiết bị có hỗ trợ bộ mã hoá H.263 và cung cấp bộ mã hoá cho các ứng dụng bên thứ ba, thì các quy trình đó sẽ:

• [C-1-1] PHẢI hỗ trợ Hồ sơ cơ sở Cấp 45.
• NÊN hỗ trợ tốc độ bit có thể định cấu hình động cho bộ mã hoá được hỗ trợ.

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, việc hỗ trợ cho ASO (Sắp xếp Lát cắt tuỳ ý), FMO (Sắp xếp Lát cắt Linh hoạt) và RS (Lát cắt thừa) là KHÔNG BẮT BUỘC. Ngoài ra, để duy trì khả năng tương thích với các thiết bị Android khác, bạn NÊN không sử dụng ASO, FMO và RS cho Hồ sơ cơ sở bằng bộ mã hoá.
• [C-1-2] PHẢI hỗ trợ các 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) như được chỉ ra 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 các video có độ phân giải 720p hoặc 1080p thông qua API nội dung nghe nhìn, thì các API đó sẽ:

• [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 các yêu cầu về mã hoá phần cứng RTC dự án WebM để đảm bảo chất lượng chấp nhận được của dịch vụ hội nghị truyền hình và truyền video trực tuyến trên web.

Nếu quá trình triển khai thiết bị báo cáo việc hỗ trợ mã hoá VP8 cho video có độ phân giải 720p hoặc 1080p thông qua API nội dung đa phương tiện, thì 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.
• [SR] được ĐỀ XUẤT ĐỂ hỗ trợ các hồ sơ giải mã HD như được chỉ ra trong bảng sau nếu có bộ mã hoá phần cứng.

	SD	HD 720p	HD 1080p	UHD
Độ phân giải video	720 x 480 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 các hoạt động triển khai thiết bị tuyên bố hỗ trợ Hồ sơ 2 hoặc Hồ sơ 3 thông qua Media API:

• 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ợ Main Profile Level 3.
• NÊN hỗ trợ các cấu hình mã hoá HD như được chỉ ra trong bảng sau.
• [SR] được liệt kê dưới đây để hỗ trợ các hồ sơ mã hoá HD như được chỉ ra trong bảng sau nếu có một 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.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ả các bộ mã hoá và giải mã VP8, VP9, H.264 và H.265 theo thời gian thực và lên đến độ phân giải tối đa được hỗ trợ bởi mỗi 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 và Cấp 45.

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

Nếu chiều cao mà phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải của video, thì các phương thức triển khai thiết bị:

• [C-2-1] PHẢI hỗ trợ các cấu hình giải mã video HD 720p trong bảng sau đây.
• [C-2-2] PHẢI hỗ trợ các cấu hình giải mã video HD 1080p trong bảng sau.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p
Độ phân giải video	320 x 240 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âyTruyề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à 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.
• [C-1-2] PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau nếu có một bộ giải mã phần cứng.

Nếu chiều cao mà phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải của video, thì:

• [C-2-1] Các quá trình triển khai thiết bị PHẢI hỗ trợ ít nhất một trong các giải mã H.265 hoặc VP9 của các cấu hình 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	352 x 288 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âyTV 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ợ Cấu hình HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) thông qua Media 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 (MediaFormat#KEY_HDR_StatIC_INFO cho tất cả các cấu hình HDR) từ ứng dụng bằng cách sử dụng MediaCodec API, cũng như hỗ trợ trích xuất các siêu dữ liệu HDR cần thiết (MediaFormat#KEY_HDR_StatIC_INFO cho tất cả các cấu hình HDR, cũng như MediaFormat#KEY_HDR10_PLUS_INFO hoặc các thông số kỹ thuật được xác định cho bit HDR10Plus. Các API này cũng PHẢI hỗ trợ xuất siêu dữ liệu HDR bắt buộc (MediaFormat#KEY_HDR_STATUSIC_INFO cho tất cả các cấu hình HDR) từ luồng bit và/hoặc vùng chứa như được xác định trong các thông số kỹ thuật có liên quan.

• [C-SR] Các phương pháp triển khai thiết bị được tôi siêu đề xuất để hỗ trợ việc xuất siêu dữ liệu MediaFormat#KEY_HDR10_PLUS_INFO cho các hồ sơ HDR10Plus thông qua MediaCodec#getOutputFormat(int).

• [C-3-2] Các quá trình triển khai trên thiết bị PHẢI hiển thị đúng cách nội dung HDR cho cấu hình HEVCProfileMain10HDR10 trên màn hình thiết bị hoặc trên cổng đầu ra video chuẩn (ví dụ: HDMI).

• [C-SR] Các phương thức triển khai thiết bị được được nhà cung cấp (BỀN THỨC ĐỀ XUẤT) để hiển thị chính xác nội dung HDR cho cấu hình HEVCProfileMain10HDR10Plus trên màn hình thiết bị hoặc trên cổng đầu ra video 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 các yêu cầu này.
• NÊN hỗ trợ các cấu hình giải mã HD trong bảng sau.

Nếu chiều cao mà 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] Các quá trình triển khai thiết bị PHẢI hỗ trợ cấu hình 720p trong bảng sau.
• [C-2-2] Các quá trình 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âyTruyền hình)	30 (60 khung hình/giâyTruyề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 bảng sau.

Nếu chiều cao mà phương thức Display.getSupportedModes() báo cáo bằng hoặc lớn hơn độ phân giải 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 các bộ giải mã VP9 hoặc H.265 của các cấu hình 720, 1080 và UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	320 x 180 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âyTV 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 hoạt động triển khai thiết bị tuyên bố hỗ trợ VP9Profile2 hoặc VP9Profile3 thông qua API nội dung đa phương tiện 'CodecProfilelevel':

• 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 các API nội dung đ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 (MediaFormat#KEY_HDR_STATIC_INFO cho tất cả cấu hình HDR, cũng như tham số MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO cho cấu hình HDR10Plus) từ ứng dụng bằng MediaCodec API, cũng như hỗ trợ trích xuất siêu dữ liệu HDR cần thiết (MediaFormat#KEY_HDR_STATIC_INFO cho tất cả cấu hình HDR, cũng như MediaFormat#KEY_HDR10_PLUS_INFO cho cấu hình HDR10Plus) từ luồng bit và/hoặc vùng chứa được xác định theo thông số kỹ thuật có liên quan. Các API này cũng PHẢI hỗ trợ xuất siêu dữ liệu HDR bắt buộc (MediaFormat#KEY_HDR_STATIC_INFO cho tất cả cấu hình HDR) từ luồng bit và/hoặc vùng chứa như được xác định trong các thông số kỹ thuật có liên quan.

• [C-4-2] Các quá trình triển khai trên thiết bị PHẢI hiển thị đúng cách nội dung HDR cho cấu hình VP9Profile2HDR và VP9Profile3HDR trên màn hình thiết bị hoặc trên cổng đầu ra video chuẩn (ví dụ: HDMI).

• [C-SR] Các phương thức triển khai thiết bị là tôi linh hoạt chạy danh sách được đề xuất để hỗ trợ việc xuất siêu dữ liệu MediaFormat#KEY_HDR10_PLUS_INFO cho các hồ sơ HDR10Plus qua MediaCodec#getOutputFormat(int).

• [C-SR] Các cách triển khai thiết bị được tôi ĐỀ XUẤT để hiển thị chính xác nội dung HDR cho các cấu hình VP9Profile2HDR10Plus và VP9Profile3HDR10Plus trên màn hình thiết bị hoặc trên một cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).

5.3.8. Dolby Vision

Nếu các quá trình triển khai thiết bị khai báo tính năng hỗ trợ cho bộ giải mã Dolby Vision thông qua HDR_TYPE_DOLBY_VISION , thì các thiết bị đó:

• [C-1-1] PHẢI cung cấp bộ trích xuất có khả năng Dolby Vision.
• [C-1-2] PHẢI hiển thị đúng nội dung Dolby Vision trên màn hình thiết bị hoặc trên cổng đầu ra video chuẩn (ví dụ: HDMI).
• [C-1-3] PHẢI đặt chỉ mục theo dõi của(các) lớp cơ sở tương thích ngược (nếu có) giống với chỉ mục theo dõi của lớp Dolby Vision kết hợp.

5.3.9. 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ợ Profile 0 bao gồm cả nội dung 10-bit.

5,4. Ghi âm

Mặc dù một số yêu cầu được nêu trong phần này được liệt kê là NÊN kể từ Android 4.3, nhưng Định nghĩa về khả năng tương thích cho các phiên bản trong tương lai được lên kế hoạch thay đổi các yêu cầu này thành PHẢI. Các thiết bị Android mới và hiện có đều ĐƯỢC ĐỀ XUẤT ĐỂ đáp ứng những yêu cầu này (được liệt kê là NÊN LÀM), nếu không, các thiết bị đó sẽ không thể đạt được khả năng tương thích với Android khi được nâng cấp lên phiên bả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 thu thập nội dung âm thanh thô có các đặc điểm sau:

  • Định dạng: PCM tuyến tính, 16 bit
  • Tốc độ lấy mẫu: 8000, 11025, 16000, 44100, 48000 Hz
  • Kênh: Đơn âm

• NÊN cho phép thu thập nội dung âm thanh thô có các đặc điểm sau:

  • Định dạng: PCM tuyến tính, 16 bit và 24 bit
  • Tốc độ lấy mẫu: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Kênh: Số lượng kênh bằng số lượng micrô trên thiết bị

• [C-1-2] PHẢI 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 một bộ lọc khử răng cưa thích hợp khi tốc độ lấy mẫu đã cho ở trên được chụp bằng phương pháp giảm tần số lấy mẫu.

• NÊN cho phép thu nội dung âm thanh thô và chất lượng radio AM, điều này có nghĩa là có các đặc điểm sau:

  • Định dạng: PCM tuyến tính, 16 bit
  • Tốc độ lấy mẫu: 22050, 48000 Hz
  • Kênh: Âm thanh nổi

• [C-1-4] PHẢI tuân thủ API MicrophoneInfo và điền đúng thông tin cho các micrô hiện có trên thiết bị mà ứng dụng bên thứ ba có thể truy cập qua API AudioManager.getMicrophones() cũng như các micrô đang hoạt động mà ứng dụng bên thứ ba có thể truy cập qua API AudioRecord.getActiveMicrophones() và MediaRecorder.getActiveMicrophones(). Nếu các phương pháp triển khai thiết bị cho phép ghi lại nội dung âm thanh thô và thiết bị có chất lượng AM, thì các thiết bị đó sẽ:

• [C-2-1] PHẢI chụp mà không cần 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 thu thập nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ở một trong các tốc độ lấy mẫu, 44100 và 48000.
• [C-1-2] Theo mặc định, PHẢI 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 từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
• [C-1-3] Theo mặc định, PHẢI tắt mọi chế độ điều khiển khuếch đại tự động khi ghi lại luồng âm thanh từ nguồn âm thanh AudioSource.VOICE_RECOGNITION.
• NÊN ghi lại luồng âm thanh nhận dạng giọng nói với các đặc điểm biên độ phẳng so với tần số gần như: cụ thể, ± 3 dB, từ 100 Hz đến 4000 Hz.
• NÊN ghi lại luồng âm thanh nhận dạng giọng nói với thiết lập độ nhạy đầu vào sao cho nguồn mức công suất âm thanh (SPL) 90 dB (SPL) ở 1000 Hz mang lại RMS 2500 cho mẫu 16 bit.
• NÊN ghi lại luồng âm thanh nhận dạng giọng nói để các mức biên độ PCM theo dõi tuyến tính đầu vào SPL thay đổi trên ít nhất một phạm vi 30 dB từ -18 dB đến +12 dB và 90 dB SPL tại micrô.
• NÊN ghi lại luồng âm thanh nhận dạng giọng nói với tổng méo hài (THD) dưới 1% cho 1 kHz ở mức đầu vào SPL 90 dB tại micrô.

Nếu các quá trình triển khai thiết bị khai báo android.hardware.microphone và công nghệ khử tiếng ồn (giảm) được điều chỉnh để nhận dạng lời nói, thì các công nghệ đó sẽ:

• [C-2-1] PHẢI cho phép điều khiển hiệu ứng âm thanh này bằng API android.media.audiofx.NoiseSuppressor.
• [C-2-2] PHẢI xác định riêng từng cách triển khai công nghệ khử tiếng ồn thông qua trường AudioEffect.Descriptor.uuid.

5.4.3. Chụp để đổi tuyến đường phát lại

Lớp android.media.MediaRecorder.AudioSource bao gồm nguồn âm thanh REMOTE_SUBMIX.

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

• [C-1-1] PHẢI triển khai đúng cách nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng sử dụng API android.media.AudioRecord để ghi từ nguồn âm thanh này, ứng dụng đó sẽ ghi lại tất cả các luồng âm thanh ngoại trừ những luồng âm thanh 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 công nghệ Acoustic Echo Canceler (AEC) được điều chỉnh để giao tiếp bằng giọng nói và áp dụng cho đường dẫn chụp khi chụp bằng AudioSource.VOICE_COMMUNICATION

Nếu các 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 thu âm khi chọn AudioSource.VOICE_COMMUNICATION, thì chúng:

• [C-SR] arePhải_DOWNLOAD để khai báo điều này qua phương thức API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR] arePhải_REVIEW để cho phép hiệu ứng âm thanh này có thể điều khiển được với AcousticEchoCanceler API.
• [C-SR] arePhải_DOWNLOAD để xác định duy nhất từng cách triển khai công nghệ AEC thông qua trường AudioEffect.Descriptor.uuid.

5.4.5. Chụp đồng thời

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.microphone,thì các hoạt động đó 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 dịch vụ hỗ trợ tiếp cận chụp ảnh đồng thời vào micrô bằng AudioSource.VOICE_RECOGNITION và ít nhất một ứng dụng chụp ảnh bằng AudioSource bất kỳ.
• [C-1-2] PHẢI cho phép một ứng dụng cài đặt sẵn có vai trò Trợ lý và ít nhất một ứng dụng chụp ảnh 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 tính năng ghi â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 ghi âm bằng AudioSource.VOICE_COMMUNICATION hoặc AudioSource.CAMCORDER. Tuy nhiên, khi một ứng dụng đang thu âm qua AudioSource.VOICE_COMMUNICATION, thì một ứng dụng khác có thể ghi âm cuộc gọi thoại nếu đó là một ứng dụng có đặc quyền (được cài đặt sẵn) có quyền CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Nếu hai hoặc nhiều ứng dụng đang thu âm đồng thời và nếu không có ứng dụng nào có giao diện người dùng ở trên cùng thì ứng dụng bắt đầu thu âm gần đây nhất sẽ nhận được âm thanh.

5.4.6. Mức tăng âm lượng của micrô

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 thể hiện các đặc điểm tần số so với biên độ phẳng trong dải tần giữa: cụ thể là ± 3dB từ 100 Hz đến 4000 Hz cho mỗi và mọi micrô được sử dụng để ghi nguồn âm thanh nhận dạng giọng nói.
• NÊN đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 90 dB tạo ra phản hồi với RMS 2500 cho mẫu 16 bit (hoặc -22,35 dB cho mẫu có dấu phẩy động/độ chính xác kép) cho mỗi và mọi micrô được sử dụng để ghi lại nguồn âm thanh nhận dạng giọng nói.
• [C-SR] đượcPhải đề xuất để thể hiện các mức biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 5 Hz đến 100 Hz so với dải tần số trung bình cho mỗi và mọi micrô được sử dụng để ghi lại nguồn âm thanh nhận dạng giọng nói.
• [C-SR] được liệt kê như vậy để thể hiện các mức biên độ trong dải tần số cao: đặc biệt là từ 30 dB từ 4000 Hz đến 22 KHz so với dải tần số giữa cho mỗi và mọi micrô được sử dụng để ghi lại nguồn âm thanh nhận dạng giọng nói.

5,5. Phát âm thanh

Android có hỗ trợ cho phép các ứng dụng phát âm thanh thông qua thiết bị ngoại vi đầu ra âm thanh theo quy đị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ô có các đặc điểm sau:

  • Định dạng nguồn: PCM tuyến tính, 16 bit, 8 bit, float
  • Kênh: Cấu hình đơn âm, âm thanh nổi, đ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, 32000, 44100, 48000 tại các cấu hình kênh nêu trên
    • 96000 ở chế độ đơn âm và âm thanh nổi

• NÊN cho phép phát nội dung âm thanh thô có các đặc điểm sau:

  • Tốc độ lấy mẫu: 24000

5.5.2. Hiệu ứng âm thanh

Android cung cấp một API cho hiệu ứng âm thanh để 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, thì các quá trình triển khai thiết bị sẽ:

• [C-1-1] PHẢI hỗ trợ hoạt động triển khai EFFECT_TYPE_EQUALIZER và EFFECT_TYPE_LOUDNESS_ENHANCER có thể kiểm soát thông qua các lớp con AudioEffect Equalizer và LoudnessEnhancer.
• [C-1-2] PHẢI hỗ trợ hoạt động triển khai API của trình hiển thị hình ảnh, có thể kiểm soát thông qua lớp Visualizer.
• [C-1-3] PHẢI hỗ trợ hoạt động triển khai EFFECT_TYPE_DYNAMICS_PROCESSING có thể điều khiển thông qua lớp con AudioEffect DynamicsProcessing.
• NÊN hỗ trợ hoạt động triển khai EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB và EFFECT_TYPE_VIRTUALIZER có thể kiểm soát thông qua các lớp con AudioEffect BassBoost, EnvironmentalReverb, PresetReverb và Virtualizer.
• [C-SR] AreĐể 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 âm thanh riêng biệt theo 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 trong AudioAttributes và mức sử dụng âm thanh trên ô tô như được xác định công khai trong android.car.CarAudioManager.

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 theo thời gian thực.

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 dữ liệu được mã hoá bằng PCM cho đến khi âm thanh tương ứng hiện ra với môi trường thông qua bộ chuyển đổi trên thiết bị hoặc tín hiệu rời khỏi thiết bị qua một cổng và có thể quan sát được từ bên ngoài.
• độ trễ đầu ra nguội. Độ trễ đầu ra cho khung hình đầu tiên, khi hệ thống đầu ra âm thanh ở trạng thái rảnh và 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 môi trường truyền âm thanh đến thiết bị tại bộ chuyển đổi hoặc tín hiệu trên thiết bị đi vào thiết bị qua cổng và thời điểm ứng dụng đọc khung dữ liệu mã PCM tương ứng.
• 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 sử dụng được.
• độ trễ đầu vào nguội. Tổng thời gian đầu vào bị mất và độ trễ đầu vào cho khung hình đầu tiên, khi hệ thống đầu vào âm thanh không hoạt động và bị 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ị đang ghi âm.
• biến động đầu ra nguội. Sự thay đổi giữa các phép đo riêng biệt về giá trị độ trễ đầu ra nguội.
• biến động đầu vào nguội. Sự thay đổi giữa các phép đo riêng biệt về giá trị độ trễ đầu vào nguội.
• độ 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 1 khoảng thời gian đệm. Khoảng thời gian đệm cho phép ứng dụng có thời gian xử lý tín hiệu và có thời gian để ứng dụng giảm thiểu tình trạng chênh lệch pha giữa luồng đầu vào và đầu ra.
• API hàng đợi bộ đệm PCM OpenSL ES. Bộ các API OpenSL ES liên quan đến PCM trong Android NDK.
• API âm thanh gốc AAudio. Tập hợp các API AAudio trong Android NDK.
• timestamp. Một cặp bao gồm vị trí khung tương đối trong một luồng và thời gian ước tính khi khung đó đ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. Hãy xem thêm mục AudioTimestamp (Dấu thời gian âm thanh).
• sự cố. Tình trạng gián đoạn tạm thời hoặc giá trị mẫu không chính xác trong tín hiệu âm thanh, thường là do trận vùng đệm đối với đầu ra, vượt quá vùng đệm đối với đầ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.

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:

• [C-1-1] Dấu thời gian đầu ra do AudioTrack.getTimestamp và AAudioStream_getTimestamp trả về chính xác đến +/- 2 mili giây.
• [C-1-2] Độ trễ đầu ra nguội từ 500 mili giây trở xuống.

Nếu các hoạt động triển khai thiết bị khai báo android.hardware.audio.output, thì chúng tôi ĐỀ XUẤT KHÔNG NÊN đáp ứng hoặc vượt quá các yêu cầu sau:

• [C-SR] Độ trễ đầu ra nguội từ 100 mili giây trở xuống. Các thiết bị mới và hiện có chạy phiên bản Android này RẤT NÊN DÙNG để đáp ứng các yêu cầu này ngay bây giờ. Trong một bản phát hành nền tảng sau này vào năm 2021, chúng tôi sẽ yêu cầu độ trễ đầu ra Cold từ 200 mili giây trở xuống là PHẢI.
• [C-SR] Độ trễ đầu ra liên tục từ 45 mili giây trở xuống.
• [C-SR] Giảm thiểu biến động đầu ra nguội.
• [C-SR] Dấu thời gian đầu ra do AudioTrack.getTimestamp và AAudioStream_getTimestamp trả về chính xác đến +/- 1 mili giây.

Nếu quá trình triển khai thiết bị đáp ứng các yêu cầu nêu trên, thì sau mọi quá trình hiệu chỉnh ban đầu, khi sử dụng cả hàng đợi bộ đệm OpenSL ES PCM và API âm thanh gốc AAudio, để độ trễ đầu ra liên tục và độ trễ đầu ra nguội trên ít nhất một thiết bị đầu ra âm thanh được hỗ trợ, thì:

• [C-SR] Internet ĐỀ XUẤT NÊN báo cáo âm thanh có độ trễ thấp bằng cách khai báo cờ tính năng android.hardware.audio.low_latency.
• [C-SR] bỏ qua Sử dụng AAudio để đáp ứng các yêu cầu đối với âm thanh có độ trễ thấp thông qua API AAudio.
• [C-SR] BẠN NÊN DÙNG ĐỂ đảm bảo rằng đối với các luồng trả về AAUDIO_PERFORMANCE_MODE_LOW_LATENCY từ AAudioStream_getPerformanceMode(), giá trị mà AAudioStream_getFramesPerBurst() trả về sẽ nhỏ hơn hoặc bằng giá trị do android.media.AudioManager.getProperty(String) trả về cho khoá thuộc tính AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Nếu quá trình triển khai thiết bị không đáp ứng yêu cầu về âm thanh có độ trễ thấp thông qua cả hàng đợi bộ đệm OpenSL ES PCM và API âm thanh gốc AAudio, thì:

• [C-2-1] KHÔNG ĐƯỢC báo cáo tính năng hỗ trợ âm thanh có độ trễ thấp.

Nếu quá trình triển khai thiết bị có bao gồm android.hardware.microphone, thì các quá trình đó PHẢI đáp ứng các yêu cầu về âm thanh đầu vào sau đây:

• [C-3-1] Giới hạn lỗi trong dấu thời gian đầu vào do AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp trả về, thành +/- 2 mili giây. "Lỗi" ở đây có nghĩa là độ lệch so với giá trị chính xác.
• [C-3-2] Độ trễ đầu vào nguội từ 500 mili giây trở xuống.

Nếu các hoạt động triển khai thiết bị bao gồm android.hardware.microphone, thì các phương thức này sẽ được ĐỀ XUẤT để đáp ứng các yêu cầu về âm thanh đầu vào sau đây:

• [C-SR] Độ trễ đầu vào nguội từ 100 mili giây trở xuống. Các thiết bị mới và hiện có chạy phiên bản Android này RẤT NÊN DÙNG để đáp ứng các yêu cầu này ngay bây giờ. Trong một bản phát hành nền tảng tương lai vào năm 2021, chúng tôi sẽ yêu cầu độ trễ đầu vào Lạnh từ 200 mili giây trở xuống là PHẢI.
• [C-SR] Độ trễ đầu vào liên tục từ 30 mili giây trở xuống.
• [C-SR] Độ trễ trọn vòng liên tục từ 50 mili giây trở xuống.
• [C-SR] Giảm thiểu biến động đầu vào nguội.
• [C-SR] Giới hạn lỗi trong dấu thời gian đầu vào, được trả về bằng AudioRecord.getTimestamp hoặc AAudioStream_getTimestamp, xuống còn +/- 1 mili giây.

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ư đã chỉ định trong tài liệu về SDK Android.

Nếu quá trình triển khai thiết bị bao gồm bộ giải mã âm thanh hoặc video, thì các quá trình triển khai đó:

• [C-1-1] PHẢI hỗ trợ tất cả các định dạng vùng chứa và bộ mã hoá và giải mã bắt buộc trong mục 5.1 qua HTTP(S).

• [C-1-2] PHẢI hỗ trợ các định dạng phân đoạn nội dung đa phương tiện hiển thị trong bảng Định dạng phân đoạn nội dung nghe nhìn bên dưới trên HTTP Live Streaming draft Protocol, Version 7 (Giao thức bản nháp phát trực tiếp HTTP).

• [C-1-3] PHẢI hỗ trợ cấu hình video âm thanh RTP sau đây và các bộ mã hoá và giải mã có liên quan trong bảng RTSP dưới đây. Để biết các trường hợp ngoại lệ, vui lòng xem chú thích cuối trang trong phần 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.3 để 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.1 để 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 phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
WebVTT	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 phần 5.1.3 để biết chi tiết về H264 AVC
MP4A – Mỹ La-tinh	RFC 6416	Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
H263 – 1998	RFC 3551 RFC 4629 RFC 2190	Xem phần 5.1.3 để biết thông tin chi tiết về H263
H263 – 2000	RFC 4629	Xem phần 5.1.3 để biết thông tin chi tiết về H263
AMR (giờ AMR)	RFC 4867	Xem phần 5.1.1 để biết chi tiết về AMR-NB
AMR-WB	RFC 4867	Xem phần 5.1.1 để biết chi tiết về AMR-WB
MP4V-ES	RFC 6416	Xem phần 5.1.3 để biết chi tiết về MPEG-4 SP
mpeg4 chung	RFC 3640	Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
MP2T	RFC 2250	Xem Luồng truyền tải MPEG-2 bên dưới Phá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 nền tảng an toàn, thì các quy trình đó:

• [C-1-1] PHẢI khai báo khả năng hỗ trợ cho Display.FLAG_SECURE.

Nếu các phương pháp triển khai thiết bị khai báo khả năng hỗ trợ Display.FLAG_SECURE và hỗ trợ giao thức hiển thị không dây, thì các thiết bị đó:

• [C-2-1] PHẢI bảo mật đường liên kết bằng cơ chế mạnh được mã hoá như HDCP 2.x hoặc cao hơn cho các màn hình được kết nối qua các giao thức không dây như Miracast.

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

• [C-3-1] PHẢI hỗ trợ HDCP 1.2 trở lên cho tất cả các màn hình bên 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ị báo cáo khả năng hỗ trợ cho tính năng android.software.midi thông qua lớp android.content.pm.PackageManager, thì chúng:

• [C-1-1] PHẢI hỗ trợ MIDI trên tất cả các phương thức truyền tải phần cứng có hỗ trợ MIDI mà chúng cung cấp kết nối chung không phải MIDI, trong đó các phương thức truyền tải đó là:

  • Chế độ hỗ trợ USB, phần 7.7
  • Chế độ thiết bị ngoại vi 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 liên ứng dụng (thiết bị MIDI ảo)

• [C-1-3] PHẢI include libamidi.so (hỗ trợ MIDI gốc)

5,10. Âm thanh chuyên nghiệp

Nếu quá trình triển khai thiết bị hỗ trợ tính năng android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager, thì các tuỳ chọn đó sẽ:

• [C-1-1] PHẢI báo cáo hỗ trợ cho tính năng android.hardware.audio.low_latency.
• [C-1-2] PHẢI có độ trễ âm thanh trọn vòng liên tục, như xác định trong section 5.6 Audio Latency (Độ trễ âm thanh 5.6), từ 20 mili giây trở xuống và PHẢI là 10 mili giây trở xuống trên ít nhất một đường dẫn được hỗ trợ.
• [C-1-3] PHẢI bao gồm(các) cổng USB hỗ trợ chế độ máy chủ USB và chế độ thiết bị ngoại vi USB.
• [C-1-4] PHẢI báo cáo hỗ trợ cho tính năng android.software.midi.
• [C-1-5] PHẢI đáp ứng các yêu cầu về độ trễ và âm thanh USB bằng cả API hàng đợi bộ đệm PCM OpenSL ES và ít nhất một đường dẫn của API âm thanh gốc AAudio.
• [SR] Are Always PRO để đáp ứng các yêu cầu về độ trễ và âm thanh USB bằng cách sử dụng API AAudio native audio thay vì đường dẫn MMAP.
• [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.
• [SR] Đang được ĐỀ XUẤT về việc cung cấp mức hiệu suất CPU nhất quán trong khi âm thanh đang hoạt động và mức tải CPU thay đổi. Điều này NÊN được kiểm tra bằng phiên bản ứng dụng Android của SynthMark mã cam kết 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. 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. Ứng dụng SynthMark cần được chạy bằng cách sử dụng tuỳ chọn “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

Xem tài liệu SynthMark để biết nội dung giải thích về các điểm chuẩn.

• 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 độ trôi xung nhịp âm thanh so với CLOCK_MONOTONIC của CPU khi cả hai đều đang hoạt động.
• NÊN giảm thiểu độ trễ âm thanh 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ì điều này ảnh hưởng đến tỷ lệ phần trăm băng thông CPU đầy đủ có thể sử dụng 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 cả khoảng thời gian ngay sau khi khởi động nguội.
• NÊN cung cấp chênh lệch xung nhịp âm thanh bằng 0 giữa phía đầu vào và đầu ra của các điểm cuối tương ứng, khi cả hai đều đang hoạt động. Ví dụ về các thiết bị đầu cuối tương ứng bao gồm micrô và loa trên thiết bị hoặc giắc cắm âm thanh đầu vào 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 các đ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 trả về từ lệnh gọi lại đầu vào. Hoặc nếu không thể xử lý các lệnh gọi lại trên cùng một luồng, hãy nhập lệnh gọi lại đầu ra ngay sau khi nhập lệnh gọi lại đầu vào để cho phép ứng dụng có thời gian nhất quán cho phía đầu vào và đầu ra.
• NÊN giảm thiểu độ chênh lệch pha giữa bộ đệm âm thanh HAL cho phía đầu vào và đầ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).
• NÊN có độ trễ từ đầu vào cảm ứng đến đầu ra âm thanh nhỏ hơn hoặc bằng 40 mili giây.

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ẽ:

• [SR] linh hoạt đề xuất để báo cáo khả năng hỗ trợ cho tính năng android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager.

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:

• [C-2-1] PHẢI có độ trễ âm thanh trọn vòng liên tục là 20 mili giây trở xuống trên đường dẫn giắc âm thanh.
• [SR] Internet ĐỀ XUẤT NÊN tuân thủ mục Mobile device (jack) specifications (Thông số kỹ thuật của thiết bị di động (jack)) trong Wired Audio Headset Specification (v1.1).
• Độ trễ âm thanh trọn vòng liên tục PHẢI là 10 mili giây trở xuống trên đường dẫn của giắc âm thanh.

Nếu quá trình triển khai thiết bị bỏ qua giắc cắm âm thanh 4 dây dẫn 3,5 mm và có(các) cổng USB hỗ trợ chế độ hỗ trợ USB, thì:

• [C-3-1] PHẢI triển khai lớp âm thanh USB.
• [C-3-2] PHẢI có độ trễ âm thanh trọn vòng liên tục từ 20 mili giây trở xuống qua cổng chế độ máy chủ USB sử dụng lớp âm thanh USB.
• Độ trễ âm thanh trọn vòng liên tục PHẢI là 10 mili giây trở xuống qua cổng chế độ máy chủ USB sử dụng lớp âm thanh USB.
• [C-SR] Đang được ĐỀ XUẤT để 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 sử dụng với các thiết bị ngoại vi âm thanh USB cũng hỗ trợ các yêu cầu này.

Nếu quá trình triển khai thiết bị có bao gồm cả cổng HDMI, thì các yêu cầu này:

• NÊN hỗ trợ đầu ra ở dạng âm thanh nổi và tám kênh ở độ sâu 20 bit hoặc 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.

5,11. Ghi lại để xử lý

Android có hỗ trợ tính năng ghi âm chưa xử lý thông qua nguồn âm thanh android.media.MediaRecorder.AudioSource.UNPROCESSED. Trong OpenSL ES, bạn có thể truy cập vào trình ghi này bằng giá trị đặt trước 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à cung cấp nguồn âm thanh đó cho các ứng dụng bên thứ ba, thì họ sẽ:

• [C-1-1] PHẢI báo cáo dịch vụ hỗ trợ thông qua thuộc tính android.media.AudioManager PROPERTY_DISPLAY_AUDIO_SOURCE_UNALERT.

• [C-1-2] PHẢI thể hiện các đặc điểm tần số biên độ so với tần số phẳng trong khoảng tần số trung bình: cụ thể là ±10dB từ 100 Hz đến 7000 Hz cho mỗi và mọi micrô được sử dụng để ghi lại nguồn âm thanh chưa xử lý.

• [C-1-3] PHẢI thể hiện các mức biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 5 Hz đến 100 Hz so với dải tần số giữa cho mỗi và mọi micrô được sử dụng để ghi nguồn âm thanh chưa xử lý.

• [C-1-4] PHẢI thể hiện các mức biên độ trong dải tần cao: cụ thể là từ ±30 dB từ 7000 Hz đến 22 KHz so với dải tần số trung cho mỗi và mọi micrô được sử dụng để ghi lại nguồn âm thanh chưa xử lý.

• [C-1-5] PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn âm hình sin 1000 Hz phát ở 94 dB Mức áp suất âm thanh (SPL) mang lại phản hồi với RMS 520 cho 16 mẫu bit (hoặc -36 dB Tỷ lệ đầy đủ cho mẫu dấu phẩy động/mẫu chính xác kép) cho mỗi và mọi micrô nguồn được sử dụng để ghi lại âm thanh chưa xử lý.

• [C-1-6] PHẢI có tỷ số tín hiệu trên nhiễu (SNR) ở mức 60 dB trở lên cho mỗi micrô được dùng để ghi nguồn âm thanh chưa được xử lý. (trong khi SNR được đo là sự chênh lệch giữa 94 dB SPL và SPL tương đương của nhiễu tự, có trọng số A).

• [C-1-7] PHẢI có tổng méo hài tổng (THD) nhỏ hơn 1% đối với 1 kHZ ở mức đầu vào SPL 90 dB tại mỗi và mọi micrô được sử dụng để ghi nguồn âm thanh chưa xử lý.

• KHÔNG ĐƯỢC có bất kỳ quá trình xử lý tín hiệu nào khác (ví dụ: Kiểm soát khuếch đại tự động, Bộ lọc thông cao hoặc loại bỏ tiếng vọng) trong đường dẫn ngoài hệ số mức để đưa mức đến phạm vi mong muốn. Hay nói cách khác:

• [C-1-8] Nếu bất kỳ quá trình xử lý tín hiệu nào hiện diện trong cấu trúc vì bất kỳ lý do gì, thì PHẢI được tắt và đưa độ trễ bằng 0 hoặc độ trễ thêm vào đường dẫn tín hiệu một cách hiệu quả.
• [C-1-9] Số nhân mức, khi được phép xuất hiện trên đường dẫn, KHÔNG ĐƯỢC đưa 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 các quá trình triển khai thiết bị khai báo android.hardware.microphone nhưng không hỗ trợ nguồn âm thanh chưa xử lý, thì các quá trình đó sẽ:

• [C-2-1] PHẢI trả về null cho phương thức API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) để cho biết chính xác việc thiếu tính năng hỗ trợ.
• [SR] vẫn KHÔNG ĐƯỢC ĐỀ XUẤT ĐỂ đáp ứng nhiều yêu cầu đối với đường dẫn tín hiệu cho nguồn bản ghi chưa được xử lý.

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ụ cho nhà phát triển Android được cung cấp trong SDK Android.

• Cầu gỡ lỗi Android (adb)

  • [C-0-2] PHẢI hỗ trợ adb như được nêu trong SDK Android và các lệnh shell được cung cấp trong AOSP (Dự án nguồn mở Android) mà các nhà phát triển ứng dụng có thể sử dụng, bao gồm cả dumpsys cmd stats
  • [C-SR] AreĐể hỗ trợ lệnh shell cmd testharness.
  • [C-0-3] KHÔNG ĐƯỢC thay đổi định dạng hoặc nội dung của các sự kiện hệ thống của thiết bị (batterystats , Disstats, ValueTrack, graphicsstats, netstats, notification, procstats) được ghi lại thông qua lệnh dumpsys.
  • [C-0-10] PHẢI ghi lại mà không bỏ sót, đồng thời làm cho các sự kiện sau có thể truy cập và sẵn 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
    • JobStateChanged
    • 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
    • UidProcessStateChanged
    • Trạng thái WakelockĐã thay đổi
    • Báo thức
    • WifiLockStateChanged
    • Wi-FiMulticastLockStateChanged
    • WifiQuétStateChanged
  • [C-0-4] PHẢI có trình nền adb phía thiết bị không hoạt động theo mặc định và PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
  • [C-0-5] PHẢI hỗ trợ adb an toàn. Android có hỗ trợ adb bảo mật. 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áy chủ. Ví dụ:

    • Các quá trình triển khai thiết bị không có cổng USB hỗ trợ chế độ thiết bị ngoại vi PHẢI triển khai adb qua mạng khu vực cục bộ (chẳng hạn như Ethernet hoặc Wi-Fi).
    • PHẢI cung cấp trình điều khiển cho Windows 7, 9 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.

• 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.
• Khỉ
  • [C-0-8] PHẢI bao gồm khung Monkey và cung cấp cho các ứng dụng sử dụng.
• 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ó cơ chế mà người dùng có thể tiếp cận để bật Systrace.

• Perfetto

  • [C-SR] AreRENDERED ĐỀ XUẤT để hiển thị tệp nhị phân /system/bin/perfetto cho người dùng shell, lệnh cmdline này tuân thủ tài liệu về perfetto.
  • [C-SR] the perfetto binary is Internet Ưu đãi để chấp nhận dữ liệu đầu vào cho một cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
  • [C-SR] The perfetto binary is Internet recommended to write as output a protobuf trace with the schema is specified in (Tài liệu về perfetto).
  • [C-SR] Are Internet ĐỀ XUẤT NÊN cung cấp, thông qua nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu perfetto.

• Chế độ khai thác thử nghiệm

  Nếu các hoạt động triển khai thiết bị hỗ trợ lệnh shell cmd testharness và chạy cmd testharness enable, thì 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ế độ harness.

Nếu các hoạt động triển khai thiết bị báo cáo khả năng hỗ trợ Vulkan 1.0 trở lên thông qua cờ tính năng android.hardware.vulkan.version, thì chúng:

• [C-1-1] PHẢI cung cấp một 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ác công cụ bên ngoài cung cấp (tức là không phải là một phần của nền tảng hoặc gói ứng dụng) được tìm thấy trong các ứng dụng có thể gỡ lỗi thư mục cơ sở để hỗ trợ phương thức API vkEnumerateInstanceLayerProperties() và vkCreateInstance().

6.2. Tuỳ chọn cho nhà phát triển

Android có tính năng hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng.

Quá trình triển khai thiết bị PHẢI mang lại trải nghiệm nhất quán cho Tuỳ chọn cho nhà phát triển. Các hoạt động này:

• [C-0-1] PHẢI tuân thủ ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiển thị các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Theo mặc định, quá trình triển khai Android ngược dòng sẽ ẩn trình đơn Tuỳ chọn cho nhà phát triển và cho phép người dùng chạy Tuỳ chọn cho nhà phát triển sau khi nhấn bảy (7) lần trên phầ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 biện pháp ưu tiên cho một ứng dụng bên thứ ba chứ không phải ứng dụng bên thứ ba khác để bật Tuỳ chọn cho nhà phát triể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ừ các tài liệu SDK Android.
• NÊN có thông báo bằng hình ảnh liên tục cho người dùng khi Tuỳ chọn cho nhà phát triển được bật và sự an toàn của người dùng là mối 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 tắt trình đơn theo cách trực quan để tránh bị phân tâm trong các trường hợp liên quan đến sự an toàn của người dùng.

7. Khả năng tương thích với phần cứng

Nếu thiết bị có một thành phần phần cứng cụ thể có API tương ứng cho nhà phát triển bên thứ ba:

• [C-0-1] Việc triển khai thiết bị PHẢI triển khai API đó theo mô tả trong tài liệu SDK Android.

Nếu một API trong SDK tương tác với một thành phần phần cứng được cho là không bắt buộc và quá trình triển khai thiết bị không sở hữu thành phần đó:

• [C-0-2] Định nghĩa lớp đầy đủ (như được SDK ghi lại) cho các API thành phần PHẢI vẫn được trình bày.
• [C-0-3] Các hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo một cách nào đó hợp lý.
• [C-0-4] Các phương thức API PHẢI trả về các giá trị rỗng nếu tài liệu SDK cho phép.
• [C-0-5] Các phương thức API PHẢI trả về các cách triển khai không hoạt động của các lớp trong đó tài liệu SDK không cho phép giá trị rỗng.
• [C-0-6] Các phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được ghi nhận trong tài liệu về SDK.
• [C-0-7] Các quá trình triển khai thiết bị PHẢI báo cáo một cách nhất quán thông tin cấu hình phần cứng chính xác thông qua phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager cho cùng một vân tay số của bản dựng.

Ví dụ điển hình về tình huống trong đó các yêu cầu này được áp dụng là API điện thoại: Ngay cả trên các thiết bị không phải điện thoại, các API này PHẢI được triển khai dưới dạng không hoạt động hợp lý.

7.1. Màn hình và đồ hoạ

Android có các tiện nghi tự động điều chỉnh thành phần ứng dụng và bố cục giao diện người dùng phù hợp với thiết bị nhằm đảm bảo các ứng dụng của bên thứ ba chạy tốt trên nhiều cấu hình phần cứng. Trên(các) màn hình tương thích với Android nơi tất cả các ứng dụng tương thích với Android của bên thứ ba đều có thể chạy, các hoạt động triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

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 bằng inch giữa hai góc đối diện của phần được chiếu sáng của màn hình.
• số điểm trên mỗi inch (dpi). Số pixel được bao quanh bởi khoảng dọc hoặc chiều ngang tuyến tính là 1". Khi các giá trị dpi được liệt kê, cả dpi ngang và dọc đều PHẢI nằm trong phạm vi.
• tỷ lệ khung hình. Tỷ lệ pixel có chiều dài so với chiều rộng của màn hình. Ví dụ: màn hình có kích thước 480x854 pixel sẽ là 854/480 = 1,779 hoặc xấp xỉ “16:9”.
• pixel không phụ thuộc vào mật độ (dp). Đơn vị pixel ảo được chuẩn hoá thành màn hình 160 dpi, được tính như sau: pixel = dps * (mật độ/160).

7.1.1. Cấu hình màn hình

7.1.1.1. Kích thước và hình dạng màn hình

Khung giao diện người dùng Android hỗ trợ nhiều kích thước bố cục màn hình logic, đồng thời cho phép các ứng dụng truy vấn kích thước bố cục màn hình của cấu hình hiện tại qua Configuration.screenLayout bằng SCREENLAYOUT_SIZE_MASK và Configuration.smallestScreenWidthDp.

Triển khai thiết bị:

• [C-0-1] PHẢI báo cáo kích thước bố cục chính xác cho Configuration.screenLayout như xác định trong tài liệu về SDK Android. Cụ thể, các hoạt động triển khai thiết bị PHẢI báo cáo đúng kích thước màn hình pixel không phụ thuộc vào mật độ logic (dp) như dưới đây:

  • Các thiết bị có Configuration.uiMode được đặt thành bất kỳ giá trị nào khác ngoài UI_MODE_TYPE_WATCH và báo cáo kích thước small cho Configuration.screenLayout phải có kích thước tối thiểu là 426 dp x 320 dp.
  • Các thiết bị báo cáo có 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 có kích thước large cho Configuration.screenLayout phải có kích thước tối thiểu là 640 dp x 480 dp.
  • Các thiết bị báo cáo có 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 rõ khả năng hỗ trợ đối với kích thước màn hình thông qua thuộc tính <supports-screens> trong AndroidManifest.xml, như mô tả trong tài liệu SDK Android.

• CÓ THỂ có(các) màn hình tương thích với Android với góc bo tròn.

Nếu các hoạt động triển khai thiết bị hỗ trợ UI_MODE_TYPE_NORMAL và bao gồm(các) màn hình có góc bo tròn tương thích với Android, thì chúng:

• [C-1-1] PHẢI đảm bảo rằng bán kính của các góc bo tròn nhỏ hơn hoặc bằng 38 dp.
• 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ị với các góc hình chữ nhật.

7.1.1.2. Tỷ lệ khung hình màn hình

Mặc dù không có hạn chế nào đối với tỷ lệ khung hình của màn hình vật lý cho (các) màn hình tương thích với Android, nhưng tỷ lệ khung hình của màn hình logic nơi ứng dụng bên thứ ba được hiển thị (có thể lấy từ giá trị chiều cao và chiều rộng được báo cáo thông qua API view.Display và API Cấu hình), PHẢI đáp ứng các yêu cầu sau:

• [C-0-1] Quá trình triển khai thiết bị có Configuration.uiMode được đặt thành UI_MODE_TYPE_NORMAL PHẢI có giá trị tỷ lệ khung hình nhỏ hơn hoặc bằng 1,86 (khoảng 16:9), trừ phi ứng dụng đáp ứng một trong các điều kiện sau:

  • Ứng dụng đã khai báo rằng hỗ trợ tỷ lệ khung hình của màn hình lớn hơn thông qua giá trị siêu dữ liệu android.max_aspect.
  • Ứng dụng khai báo rằng ứng dụng có thể đổi kích thước thông qua thuộc tính android:resizeableActivity.
  • Ứng dụng nhắm đến API cấp 24 trở lên và không khai báo android:maxAspectRatio sẽ hạn chế tỷ lệ khung hình được phép.

• [C-0-2] Quá trình triển khai thiết bị có Configuration.uiMode được đặt thành UI_MODE_TYPE_NORMAL PHẢI có giá trị tỷ lệ khung hình bằng hoặc lớn hơn 1.3333 (4:3), trừ trường hợp ứng dụng có thể được kéo dài hơn bằng cách đáp ứng một trong các điều kiện sau:

  • Ứng dụng khai báo rằng ứng dụng có thể đổi kích thước thông qua thuộc tính android:resizeableActivity.
  • Ứng dụng khai báo một android:minAspectRatio sẽ hạn chế tỷ lệ khung hình được phép.

• [C-0-3] Quá trình triển khai thiết bị có Configuration.uiMode được đặt là UI_MODE_TYPE_WATCH PHẢI có giá trị tỷ lệ khung hình được đặt là 1.0 (1:1).

7.1.1.3. Mật độ màn hình

Khung giao diện người dùng Android xác định một tập hợp mật độ logic chuẩn để giúp nhà phát triển ứng dụng nhắm mục tiêu đến các tài nguyên ứng dụng.

• [C-0-1] Theo mặc định, các quá trình triển khai thiết bị PHẢI chỉ báo cáo một trong các mật độ khung Android được liệt kê trên DisplayMetrics thông qua DENSITY_DEVICE_STABLE API và giá trị này KHÔNG ĐƯỢC thay đổi bất cứ lúc nào; tuy nhiên, thiết bị CÓ THỂ báo cáo mật độ tuỳ ý khác theo các thay đổi về cấu hình hiển thị do người dùng thực hiện (ví dụ: kích thước màn hình) đặt sau lần khởi động đầu tiên.

• Quá trình triển khai thiết bị PHẢI xác định mật độ khung Android chuẩn gần nhất về mặt số với mật độ vật lý của màn hình, trừ phi mật độ logic đó đẩy kích thước màn hình được báo cáo xuống dưới mức tối thiểu được hỗ trợ. Nếu mật độ khung Android tiêu chuẩn gần nhất về mặt số với mật độ vật lý dẫn đến kích thước màn hình nhỏ hơn kích thước màn hình tương thích nhỏ nhất được hỗ trợ (chiều rộng 320 dp), thì quá trình triển khai thiết bị PHẢI báo cáo mật độ khung Android chuẩn thấp nhất tiếp theo.

Nếu có một thuộc tính tương tác để thay đổi kích thước hiển thị của thiết bị:

• [C-1-1] Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh tỷ lệ lớn hơn 1,5 lần mật độ gốc hoặc tạo ra kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320dp (tương đương với bộ hạn định tài nguyên sw320dp), tùy theo điều kiện nào đến trước.
• [C-1-2] Kích thước hiển thị KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ bất kỳ nhỏ hơn 0,85 lần mật độ gốc.
• Để đảm bảo khả năng hữu dụng và kích thước phông chữ nhất quán, bạn nên cung cấp tỷ lệ sau của các tuỳ chọn Hiển thị gốc (đồng thời tuân thủ các giới hạn nêu 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 hoặc video đầu ra tương thích với Android, thì(các) màn hình hiển thị tương thích với Android, thì chúng:

• [C-1-1] PHẢI báo cáo giá trị chính xác cho tất cả chỉ số hiển thị tương thích với Android được xác định trong API android.util.DisplayMetrics.

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

• [C-2-1] PHẢI báo cáo các giá trị chính xác của màn hình tương thích với Android như định nghĩa 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 mà thiết bị hỗ trợ (android.hardware.screen.portrait và/hoặc android.hardware.screen.landscape) và PHẢI báo cáo ít nhất một hướng được hỗ trợ. Ví dụ: một thiết bị có màn hình ngang theo hướng cố định, chẳng hạn như TV hoặc máy tính xách tay, chỉ NÊN báo cáo android.hardware.screen.landscape.
• [C-0-2] PHẢI báo cáo giá trị chính xác cho hướng hiện tại của thiết bị mỗi khi được truy vấn qua 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 hướng dọc hoặc ngang. Tức là thiết bị PHẢI tuân theo yêu cầu của ứng dụng về hướng màn hình cụ thể.
• [C-1-2] KHÔNG ĐƯỢC thay đổi kích thước hoặc mật độ màn hình được báo cáo khi thay đổi hướng.
• CÓ THỂ chọn hướng dọc hoặc ngang làm hướng mặc định.

7.1.4. Tăng tốc đồ hoạ 2D và 3D

7.1.4.1 OpenGL ES

Triển khai 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 phương thức GLES10.getString()) và các API gốc.
• [C-0-2] PHẢI bao gồm hỗ trợ cho tất cả API được quản lý tương ứng và API gốc cho mọi phiên bản OpenGL ES mà họ đã 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:

• [C-1-1] PHẢI hỗ trợ cả OpenGL ES 1.1 và 2.0, như được nêu và chi tiết trong tài liệu về SDK Android.
• [C-SR] Are Để hỗ trợ OpenGL ES 3.1.
• NÊN hỗ trợ OpenGL ES 3.2.

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 API được quản lý OpenGL ES và API gốc bất kỳ tiện ích OpenGL ES nào khác mà chúng đã triển khai, và ngược lại KHÔNG được báo cáo chuỗi tiện ích mà chúng không hỗ trợ.
• [C-2-2] PHẢI hỗ trợ tiện ích EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable và EGL_ANDROID_GLES_layers.
• [C-SR] AreĐể hỗ trợ các tiện ích EGL_KHR_partial_update và OES_EGL_image_external.
• NÊN báo cáo chính xác thông qua phương thức getString(), mọi định dạng nén kết cấu mà phương thức này hỗ trợ (thường dành riêng cho từng nhà cung cấp).

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 ngoài các biểu tượng hàm OpenGL ES 2.0 trong thư viện libGLESv2.so.
• [SR] AreNhà cung cấp được đề xuất cho mục đích hỗ trợ tiện ích OES_EGL_image_external_essl3.

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 các quá trình triển khai thiết bị hỗ trợ toàn bộ Gói tiện ích Android OpenGL ES, thì chúng:

• [C-5-1] PHẢI xác định khả năng hỗ trợ thông qua cờ tính năng android.hardware.opengles.aep.

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

• [C-6-1] PHẢI cũng hỗ trợ tiện ích EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android hỗ trợ Vulkan, một API đa nền tảng và có mức hao tổn thấp dành cho đồ hoạ 3D hiệu suất cao.

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

• [SR] Are được linh hoạt đề xuất để bao gồm hỗ trợ cho Vulkan 1.1.

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:

• PHẢI bao gồm tính năng hỗ trợ Vulkan 1.1.

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

• [C-1-1] PHẢI báo cáo giá trị số nguyên chính xác bằng cờ tính năng android.hardware.vulkan.level và android.hardware.vulkan.version.
• [C-1-2] PHẢI liệt kê, ít nhất một VkPhysicalDevice đối với API gốc Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] PHẢI triển khai đầy đủ các API Vulkan 1.0 cho từng VkPhysicalDevice được liệt kê.
• [C-1-4] PHẢI liệt kê các lớp, có trong thư viện gốc có tên là libVkLayer*.so trong thư mục thư viện gốc của gói ứng dụng, thông qua các API gốc Vulkan vkEnumerateInstanceLayerProperties() và vkEnumerateDeviceLayerProperties() .
• [C-1-5] KHÔNG ĐƯỢC liệt kê các lớp do các thư viện bên ngoài gói ứng dụng cung cấp, hoặc cung cấp các cách khác để theo dõi hoặc chặn API Vulkan, trừ phi ứng dụng đã đặt thuộc tính android:debuggable là 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ợ thông qua API gốc của Vulkan và ngược lại KHÔNG ĐƯỢC báo cáo các chuỗi tiện ích mà chúng không hỗ trợ chính xác.
• [C-1-7] PHẢI hỗ trợ phần mở rộng VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain và VK_KHR_rise_present.
• [C-SR] Đang được ĐỀ XUẤT NÊN hỗ trợ các tiện ích VK_KHR_driver_properties và VK_GOOGLE_display_timing.

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 các hoạt động triển khai thiết bị bao gồm tính năng hỗ trợ Vulkan 1.1 và khai báo bất kỳ cờ tính năng Vulkan nào, thì các cờ đó:

• [C-3-1] PHẢI hiển thị khả năng hỗ trợ cho các loại semaphore và xử lý bên ngoài SYNC_FD cũng như tiện ích VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Hoạt động triển khai thiết bị PHẢI hỗ trợ Android RenderScript, như đã nêu chi tiết trong tài liệu về SDK Android.

7.1.4.4 Tăng tốc đồ hoạ 2D

Android có một cơ chế để các ứng dụng khai báo rằng ứng dụng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp Ứng dụng, Hoạt động, Cửa sổ hoặc 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 tăng tốc phần cứng theo mặc định và PHẢI tắt chế độ tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách đặt android:hardwareAccelerated="false" hoặc tắt chế độ tăng tốc phần cứng trực tiếp thông qua 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 của SDK Android về tính năng tăng tốc phần cứng.

Android chứa một đối tượng TextureView cho phép nhà phát triển tích hợp trực tiếp các kết cấu OpenGL ES được tăng tốc phần cứng 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 thể hiện hành vi nhất quán với triển khai Android ngược dòng.

7.1.4.5 Màn hình gam màu rộng

Nếu các quá trình triển khai thiết bị tuyên bố hỗ trợ màn hình gam rộng thông qua Configuration.isScreenWideColorGamut() , thì các thiết bị đó sẽ:

• [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 CIE 1931 xyY.
• [C-1-3] PHẢI có một màn hình có gam màu có diện tích ít nhất 90% DCI-P3 trong không gian CIE 1931 xyY.
• [C-1-4] PHẢI hỗ trợ OpenGL ES 3.1 hoặc 3.2 và báo cáo nó một cách chính xác.
• [C-1-5] PHẢI quảng cáo việc hỗ trợ các tiện ích EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear và EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] 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 bao 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 không xác định.

7.1.5. Chế độ tương thích với ứng dụng cũ

Android chỉ định một "chế độ tương thích", trong đó khung hoạt động "bình thường" chế độ kích thước màn hình tương đương (chiều rộng 320 dp) vì lợi ích của các ứng dụng cũ không được phát triển cho các phiên bản Android cũ có sẵn tính năng độc lập với kích thước màn hình.

7.1.6. Công nghệ màn hình

Nền tảng Android có các API cho phép ứng dụng kết xuất đồ hoạ phong phú lên màn hình tương thích với Android. Thiết bị PHẢI hỗ trợ tất cả các API này theo quy định của SDK Android, trừ phi được cho phép cụ thể trong tài liệu này.

Tất cả màn hình tương thích với Android 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) nằm trong khoảng từ 0,9 đến 1,15. Tức là, tỷ lệ khung hình 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 hỗ trợ 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 cũng như API dành cho 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 qua kết nối có dây, không dây hoặc kết nối màn hình bổ sung được nhúng, thì các quá trình triển khai đó:

• [C-1-1] PHẢI triển khai dịch vụ hệ thống và API DisplayManager theo mô tả trong tài liệu về SDK Android.

7.2. Thiết bị Đầu vào

Triển khai thiết bị:

• [C-0-1] PHẢI bao gồm một cơ chế nhập, chẳng hạn như màn hình cảm ứng hoặc điều hướng không cảm ứng, để điều hướng 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 các quá trình triển khai thiết bị có hỗ trợ ứng dụng Trình chỉnh sửa phương thức nhập (IME) của bên thứ ba, thì các thiết bị đó:

• [C-1-1] PHẢI khai báo cờ tính năng android.software.input_methods.
• [C-1-2] PHẢI triển khai đầy đủ Input Management Framework
• [C-1-3] PHẢI có bàn phím phần mềm được cài đặt 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 các định dạng được chỉ định trong android.content.res.Configuration.keyboard (QWERTY hoặc 12 phím). * NÊN bao gồm các cách triển khai bàn phím 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 hỗ trợ d-pad, bi xoay và con lăn làm cơ chế đ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 việc 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. Việc triển khai nguồn mở Android ngược dòng bao gồm một cơ chế lựa chọn phù hợp để sử dụng với các thiết bị thiếu đầu vào điều hướng không chạm.

7.2.3. Phím điều hướng

Các hàm Home (Màn hình chính), Recents (Gần đây) và Back (Quay lại) thường được cung cấp thông qua hoạt động tương tác với một nút vật lý chuyên dụng hoặc một phần riêng biệt của màn hình cảm ứng. Các hàm này đóng vai trò thiết yếu đối với mô hình điều hướng của Android, từ đó giúp triển khai thiết bị:

• [C-0-1] PHẢI cung cấp một thuộc tính tương tác cho người dùng để khởi chạy các ứng dụng đã cài đặt có hoạt động với <intent-filter> được đặt bằng ACTION=MAIN và CATEGORY=LAUNCHER hoặc CATEGORY=LEANBACK_LAUNCHER để triển khai Thiết bị TV. 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ề tác vụ duy nhất sẽ kích hoạt từng hàm. Ví dụ về dấu hiệu này có thể là biểu tượng rõ ràng được in trên nút, biểu tượng phần mềm trên phần thanh điều hướng của màn hình hoặc hướng dẫn người dùng thực hiện quy trình minh hoạ từng bước có hướng dẫn trong quá trình thiết lập.

Triển khai thiết bị:

• [SR] are Still recommended to not cung cấp cơ chế nhập cho Trình đơn hàm vì nó không được dùng nữa, thay vào đó là thanh hành động kể từ Android 4.0.

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 mục bổ sung hành động bất cứ khi nào cửa sổ bật lên trình đơn mục bổ sung hành động không trống và thanh hành động 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 tràn trong thanh tác vụ, nhưng CÓ THỂ hiển thị cửa sổ bật lên mục bổ sung hành động tại vị trí được sửa đổi trên màn hình khi nó được hiển thị bằng cách chọn hàm Trình đơn.

Nếu các hoạt động triển khai thiết bị không cung cấp chức năng Trình đơn, thì để đảm bảo khả năng tương thích ngược, các phương thức này sẽ: * [C-SR] Are Internet ĐỀ XUẤT NÊN cung cấp chức năng Trình đơn cho các ứng dụng khi targetSdkVersion nhỏ hơn 10, có thể là bằng nút vật lý, phím 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 các quá trình triển khai thiết bị cung cấp Chức năng hỗ trợ, chúng sẽ:

• [C-4-1] PHẢI làm cho chức năng Hỗ trợ có thể truy cập được bằng một tác vụ duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi có thể truy cập các phím điều hướng khác.
• [SR] "{NÊN DÙNG" để sử dụng chức năng nhấn và giữ hàm HOME dưới dạng tương tác được chỉ định này.

Nếu các hoạt động triển khai thiết bị sử dụng một phần riêng biệt của màn hình để hiển thị các phím điều hướng, thì 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, không dành cho các ứng dụng và KHÔNG ĐƯỢC che khuất hoặc can thiệp vào một phần màn hình có sẵn cho các ứ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ác cờ do ứng dụng đặt thông qua phương thức API View.setSystemUiVisibility() để phần riêng biệt này của màn hình (còn gọi là thanh điều hướng) được ẩn đ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 một khuôn hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp qua View#setSystemGestureExclusionRects(), nhưng ở bên ngoài WindowInsets#getMandatorySystemGestureInsets(), KHÔNG ĐƯỢC giao cắt với chức năng điều hướng, miễn là hình chữ nhật loại trừ được cho phép trong giới hạn loại trừ tối đa được chỉ định trong tài liệu cho View#setSystemGestureExclusionRects().
• [C-6-3] PHẢI gửi cho ứng dụng trên nền trước một sự kiện MotionEvent.ACTION_CANCEL sau khi thao tác chạm bắt đầu bị chặn vì một cử chỉ hệ thống, nếu trước đó ứng dụng trên nền trước đã được gửi một sự kiện MotionEvent.ACTION_DOWN.
• [C-6-4] PHẢI cung cấp một thuộc tính tương tác cho người dùng để chuyển sang điều hướng dựa trên nút trên màn hình (ví dụ: trong phần Cài đặt).
• NÊN cung cấp chức năng Màn hình chính 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.
• Những cử chỉ bắt đầu trong WindowInsets#getMandatorySystemGestureInsets() KHÔNG ĐƯỢC ảnh hưởng bởi các khuôn hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp qua View#setSystemGestureExclusionRects().

Nếu bạn cung cấp một hàm điều hướng từ vị trí bất kỳ ở cạnh trái và cạnh phải của hướng hiện tại của màn hình:

• [C-7-1] Chức năng điều hướng PHẢI là Back (Quay lại) và được cung cấp dưới dạng thao tác vuốt từ cả hai cạnh trái và phải của hướng hiện tại của màn hình.
• [C-7-2] Nếu các bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh được cung cấp ở cạnh trái hoặc phải, chúng PHẢI được đặt trong 1/3 phía trên của màn hình với chỉ báo trực quan rõ ràng, liên tục rằng việc kéo vào sẽ gọi ra các bảng đã nói trên, và do đó không phải Quay lại. Người dùng CÓ THỂ định cấu hình bảng điều khiển hệ thống sao cho bảng điều khiển nằm dưới 1/3 trên cùng của (các) cạnh màn hình nhưng bảng điều khiển hệ thống KHÔNG ĐƯỢC sử dụng dài hơn 1/3 cạnh.
• [C-7-3] Khi ứng dụng trên nền trước đã thiết lập cờ View.SYSTEM_UI_FLAG_IMMERSIVE hoặc View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, vuốt từ các cạnh PHẢI hoạt động như được triển khai trong AOSP, được nêu trong SDK.
• [C-7-4] Khi ứng dụng trên nền trước đã thiết lập cờ View.SYSTEM_UI_FLAG_IMMERSIVE hoặc View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, 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 thanh hệ thống (còn gọi là thanh điều hướng và trạng thái) như được triển khai trong AOSP.

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 bằng cách chạm giả. Các phương pháp 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ó cảm giác như đang thao tác trực tiếp với các mục trên màn hình. Vì người dùng đang trực tiếp chạm vào màn hình nên hệ thống không yêu cầu bất kỳ thành phần tương tác nào khác để cho biết các đối tượng đang được thao tác.

Triển khai thiết bị:

• PHẢI có một hệ thống nhập con trỏ kiểu nào đó (giống chuột hoặc cảm ứng).
• NÊN hỗ trợ con trỏ được theo dõi hoàn toàn độc lập.

Nếu thiết bị được triển khai có màn hình cảm ứng (một lần chạm hoặc tốt hơn), thì thiết bị sẽ:

• [C-1-1] PHẢI báo cáo TOUCHSCREEN_FINGER cho trường API Configuration.touchscreen.
• [C-1-2] PHẢI báo cáo cờ tính năng android.hardware.touchscreen và android.hardware.faketouch.

Nếu các phương pháp triển khai thiết bị bao gồm màn hình cảm ứng có thể theo dõi nhiều lần chạm, thì họ:

• [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 các quá trình triển khai thiết bị không bao gồm màn hình cảm ứng (và chỉ dựa vào thiết bị con trỏ) và đáp ứng các yêu cầu về cảm ứng giả trong mục 7.2.5, thì các thiết bị đó:

• [C-3-1] KHÔNG ĐƯỢC báo cáo bất kỳ cờ tính năng nào bắt đầu bằng android.hardware.touchscreen và chỉ được báo cáo android.hardware.faketouch.

7.2.5. Nhập bằng cách chạm giả

Giao diện cảm ứng giả cung cấp hệ thống nhập cho người dùng mà ước tính một nhóm nhỏ chức năng của màn hình cảm ứng. Ví dụ: chuột hoặc điều khiển từ xa điều khiển con trỏ trên màn hình gần đúng với thao tác chạm, nhưng yêu cầu người dùng trỏ hoặc lấy nét trước rồi nhấp. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột không khí dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các tương tác cảm ứng giả. Android có hằng số tính năng android.hardware.fakeTouch, tương ứng với một thiết bị đầu vào không cảm ứng (dựa trên con trỏ) có độ chân thực cao, chẳng hạn như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ phương thức nhập dựa trên cảm ứng (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng 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 có thêm một hệ thống nhập con trỏ khác mà họ muốn cung cấp, thì họ:

• NÊN khai báo khả năng hỗ trợ cho cờ tính năng android.hardware.faketouch.

Nếu các quá trình triển khai thiết bị khai báo dịch vụ hỗ trợ android.hardware.faketouch, thì các quá trình triển khai thiết bị đó sẽ:

• [C-1-1] PHẢI báo cáo vị trí X và Y tuyệt đối trên màn hình của vị trí con trỏ và hiển thị con trỏ trực quan trên màn hình.
• [C-1-2] PHẢI báo cáo sự kiện chạm có mã thao tác chỉ định thay đổi trạng thái xảy ra trên con trỏ di chuyển xuống hoặc lên trên màn hình.
• [C-1-3] PHẢI hỗ trợ con trỏ xuống và lên trên một đối tượng trên màn hình, cho phép người dùng mô phỏng thao tác nhấn vào một đối tượng trên màn hình.
• [C-1-4] PHẢI hỗ trợ con trỏ xuống, con trỏ lên, con trỏ xuống rồi con trỏ lên ở cùng một vị trí trên một đối tượng trên màn hình trong một ngưỡng thời gian. Điều này cho phép người dùng mô phỏng thao tác nhấn đúp vào một đối tượng trên màn hình.
• [C-1-5] PHẢI hỗ trợ con trỏ xuống 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, tiếp theo là con trỏ hướng lê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 để cho phép người dùng nhanh chóng di chuyển đối tượng đến một vị trí khác trên màn hình và sau đó con trỏ lên trên màn hình, điều này cho phép người dùng hất một đối tượng trên màn hình.
• [C-1-7] PHẢI báo cáo TOUCHSCREEN_NOTOUCH cho trường API Configuration.touchscreen.

Nếu các quá trình triển khai thiết bị khai báo dịch vụ hỗ trợ android.hardware.faketouch.multitouch.distinct, thì các quá trình triển khai thiết bị đó sẽ:

• [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 hoặc nhiều đầu vào con trỏ độc lập.

Nếu các quá trình triển khai thiết bị khai báo dịch vụ hỗ trợ android.hardware.faketouch.multitouch.jazzhand, thì các quá trình triển khai thiết bị đó sẽ:

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

Nếu các hoạt động triển khai thiết bị khai báo cờ tính năng android.hardware.gamepad, thì các hoạt động triển khai đó:

• [C-1-1] PHẢI nhúng một bộ điều khiển hoặc tàu cùng với một bộ điều khiển riêng trong hộp, điều đó sẽ cung cấp phương tiện để nhập tất cả các sự kiện được liệt kê trong các bảng bên dưới.
• [C-1-2] PHẢI có khả năng ánh xạ các sự kiện HID đến hằng số view.InputEvent Android liên kết như liệt kê trong bảng dưới đây. Quá trình triển khai Android ngược dòng bao gồm cả việc triển khai cho tay điều khiển trò chơi đáp ứng yêu cầu này.

Nút	Sử dụng HID2	Nút Android
Đáp1	Mã: 0x09	KEYCODE_NÚT_A (96)
T1	Mã: 0x09	KEYCODE_NÚT_B (97)
X1	Mã: 0x09	KEYCODE_NÚT_X (99)
N1	Mã: 0x09	KEYCODE_NÚT_Y (100)
D-pad up1 D-pad xuống1	0x01 0x00393	AXIS_HAT_Y4
D-pad bên trái1 D-pad bên phải1	0x01 0x00393	AXIS_HAT_X4
Nút vai trái1	Mã: 0x09	KEYCODE_NÚT_L1 (102)
Nút vai phải1	Mã: 0x09	KEYCODE_NÚT_R1 (103)
Nhấp chuột trái1	Mã: 0x09	KEYCODE_NÚT_THUMBL (106)
Nhấp chuột phải1	0x09 0x000F	KEYCODE_NÚT_THUMBR (107)
Trang chủ1	0x0c 0x0223	KEYCODE_HOME (3)
Quay lại1	0x0c 0x0224	KEYCODE_BACK (4)

1 Sự kiện chính

2 Việc sử dụng HID ở trên PHẢI được khai báo trong một CA trên Game pad (0x01 0x0005).

3 Việc sử dụng này PHẢI có Giá trị logic tối thiểu là 0, Giá trị logic tối đa là 7, giá trị tối thiểu vật lý tối thiểu là 0, giá trị tối đa vật lý tối đa là 315, đơn vị tính theo độ 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ồ tính từ trục tung; ví dụ: giá trị logic 0 biểu thị việc 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 lên và trái được nhấn.

4 Sự kiện chuyển động

Nút điều khiển analog1	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 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 việc triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho các nhà phát triển bên thứ ba, thì 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 cho mỗi lớp android.content.pm.PackageManager.
• [C-0-2] PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự.
• [C-0-3] PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về true hoặc false phù hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.).

Nếu quá trình triển khai thiết bị bao gồm một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, thì họ:

• [C-1-1] PHẢI 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ị (metric) quốc tế có liên quan cho từng loại cảm biến như quy định trong tài liệu SDK Android.
• [C-1-2] PHẢI báo cáo dữ liệu cảm biến với độ trễ tối đa là 100 mili giây + 2 * sample_time đối với trường hợp luồng cảm biến với độ trễ tối đa được yêu cầu là 0 ms khi bộ xử lý ứng dụng đang hoạt động. Độ trễ này không bao gồm bất kỳ độ trễ lọc nào.
• [C-1-3] PHẢI báo cáo mẫu cảm biến đầu tiên trong vòng 400 mili giây + 2 * sample_time của cảm biến được kích hoạt. Mẫu này có thể có độ chính xác bằng 0.

• [SR] NÊN báo cáo thời gian sự kiện tính bằng nano giây theo định nghĩa trong tài liệu SDK Android, thể hiện thời gian sự kiện đã xảy ra và được đồng bộ hoá với đồng hồ SystemWatch.elapsedRealtimeNano(). Các thiết bị Android mới và hiện có KHÔNG ĐƯỢC ĐỀ XUẤT để đáp ứng các yêu cầu này, vì vậy, chúng sẽ có thể nâng cấp lên các bản phát hành nền tảng trong tương lai. Đây là nơi có thể trở thành thành phần BẮT BUỘC. Lỗi đồng bộ hoá PHẢI dưới 100 mili giây.

• [C-1-4] Đối với mọi API được chỉ định trong tài liệu SDK Android là cảm biến liên tục, các hoạt động triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ PHẢI có dao động dưới 3%, trong đó dao động được định nghĩa là độ lệch chuẩn của sự chênh lệch của các giá trị dấu thời gian được báo cáo giữa các sự kiện liên tiếp.

• [C-1-5] PHẢI đảm bảo luồng sự kiện cảm biến KHÔNG ĐƯỢC ngăn CPU của thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức từ trạng thái tạm ngưng.

• Khi một số cảm biến được kích hoạt, mức tiêu thụ điện năng KHÔNG ĐƯỢC vượt quá tổng mức tiêu thụ điện năng được báo cáo của từng cảm biến.

Danh sách ở trên chưa đầy đủ; hành vi được ghi nhận của SDK Android và Tài liệu nguồn mở Android trên cảm biến sẽ được coi là có căn cứ đáng tin.

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 do một hoặc nhiều cảm biến khác cung cấp. (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 chúng bao gồm các cảm biến vật lý tiên quyết như mô tả trong các loại cảm biến.

Nếu quá trình triển khai thiết bị bao gồm 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ư mô tả trong tài liệu Nguồn mở Android về cảm biến tổng hợp.

7.3.1. Gia tốc kế

Triển khai thiết bị:

• [C-SR] Are mã hóa NÊN DÙNG để bao gồm gia tốc kế 3 trục.

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-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-2] PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER.
• [C-1-3] PHẢI tuân thủ hệ thống toạ độ cảm biến Android như được nêu chi tiết trong API Android.
• [C-1-4] PHẢI có khả năng đo từ độ rơi tự do tối đa bốn lần trọng lực(4g) trở lên trên bất kỳ trục nào.
• [C-1-5] PHẢI có độ phân giải ít 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 PHẢI đượ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.
• [SR] đang đượcPhải ĐỀ XUẤT để triển khai cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION.
• [SR] are NOT NÊN triển khai và báo cáo cảm biến TYPE_ACCELEROMETER_UNCALIBRATED. Các thiết bị Android ĐƯỢC ĐỀ XUẤT ĐỂ đáp ứng yêu cầu này để có thể nâng cấp lên bản phát hành nền tảng trong tương lai, nơi điều này có thể trở thành BẮT BUỘC.
• NÊN triển khai các cảm biến kết hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER như mô tả trong tài liệu SDK Android.
• NÊ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ác đặc điểm thay đổi trong vòng đời và được bù trừ, đồng thời duy trì 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 bạn triển khai thiết bị bao gồm gia tốc kế 3 trục và bất kỳ cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER nào cũng được triển khai:

• [C-2-1] Tổng công suất tiêu thụ của các thiết bị PHẢI luôn nhỏ hơn 4 mW.
• Mỗi công suất PHẢI nhỏ hơn 2 mW và 0,5 mW khi thiết bị ở điều kiện động hoặc tĩnh.

Nếu bạn triển khai thiết bị bao gồm gia tốc kế 3 trục và cảm biến con quay hồi chuyển 3 trục, thì chúng:

• [C-3-1] PHẢI triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
• [C-SR] AreRENDERED ĐỀ XUẤT để triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR.

Nếu các phương pháp triển khai thiết bị bao gồm gia tốc kế 3 trục, cảm biến con quay hồi chuyển 3 trục và cảm biến từ kế, thì chúng:

• [C-4-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] Are mã hóa NÊN DÙNG để bao gồm từ kế (la bàn) 3 trục.

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ó khả năng báo cáo các sự kiện lên đến tần số tối thiểu là 10 Hz và PHẢI báo cáo các sự kiện lên đến ít nhất 50 Hz.
• [C-1-3] PHẢI tuân thủ hệ thống toạ độ cảm biến Android như được nêu chi tiết trong API Android.
• [C-1-4] PHẢI có khả năng đo trong khoảng từ -900 μT đến +900 μT trên mỗi trục trước khi bão hoà.
• [C-1-5] PHẢI có giá trị bù bằng sắt cứng nhỏ hơn 700 μT và NÊN có giá trị dưới 200 μT, bằng cách đặt từ kế cách xa từ trường động (cảm ứng 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 chỉnh trực tuyến và bù trừ độ lệch cứng, đồng thời duy trì các thông số bù giữa các lần khởi động lại thiết bị.
• [C-1-8] PHẢI áp dụng bù sắt mềm — có thể hiệu chuẩn trong khi sử dụng hoặc trong khi sản xuất thiết bị.
• [C-1-9] PHẢI có độ lệch chuẩn, đượ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 3 giây với tốc độ lấy mẫu nhanh nhất, không lớn hơn 1,5 μT; Độ lệch chuẩn phải không lớn hơn 0,5 μT.
• NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Các thiết bị Android hiện có và mới được ĐỀ XUẤT NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Nếu các phương pháp triển khai thiết bị bao gồm từ kế 3 trục, cảm biến gia tốc kế và cảm biến con quay hồi chuyển 3 trục, thì 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ác cách triển khai thiết bị bao gồm từ kế 3 trục, gia tốc kế và cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR, thì chúng:

• [C-3-1] PHẢI tiêu thụ ít hơn 10 mW.
• NÊN tiêu thụ ít hơn 3 mW khi cảm biến được đăng ký cho chế độ hàng loạt ở 10 Hz.

7.3.3. GPS

Triển khai thiết bị:

• [C-SR] Are được linh hoạt đề xuất để bao gồm một bộ thu GPS/GNSS.

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

• [C-1-1] PHẢI hỗ trợ các đầu ra vị trí ở tốc độ ít nhất là 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 ngoài trời (tín hiệu mạnh, đa đường dẫn không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian nhanh để sửa lần đầu), khi được kết nối với kết nối Internet 0,5 Mb/giây hoặc tốc độ dữ liệu nhanh hơn. 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à Vệ tinh/Đồng hồ vệ tinh).
  • [C-1-6] Sau khi thực hiện tính toán vị trí như vậy, các quá trình triển khai thiết bị PHẢI xác định vị trí của nó, trên bầu trời mở, trong vòng 5 giây, khi yêu cầu vị trí được khởi động lại, tối đa một giờ sau khi tính toán vị trí ban đầu, ngay cả khi yêu cầu tiếp theo được thực hiện mà không có kết nối dữ liệu, và/hoặc sau chu kỳ nguồn.

• Trong điều kiện bầu trời mở sau khi xác định vị trí, khi đứng yên hoặc đang di chuyển với gia tốc dưới 1 mét/giây:

  • [C-1-3] PHẢI có khả năng xác định vị trí trong phạm vi 20 mét và tốc độ trong vòng 0, 5 mét mỗi giây, ít nhất 95% thời gian.
  • [C-1-4] PHẢI đồng thời theo dõi và báo cáo qua GnssStatus.Callback ít nhất 8 vệ tinh từ một chòm sao.
  • NÊN có khả năng 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 trong các Glonass, Beidou, Galileo).
  • [C-SR] Are được Để tiếp tục cung cấp dữ liệu đầu ra vị trí GPS/GNSS bình thường thông qua GNSS Location Provider API (API Trình cung cấp vị trí GNSS) trong cuộc gọi điện thoại khẩn cấp.
  • [C-SR] Are Internet ĐỀ XUẤT NÊN báo cáo các phép đo GNSS từ tất cả các chòm sao được theo dõi (như đã báo cáo trong thông báo GnssStatus), ngoại trừ SBAS.
  • [C-SR] Are được linh hoạt đề xuất để báo cáo AGC và Tần suất đo lường GNSS.
  • [C-SR] Are Để báo cáo tất cả các số liệu ước tính về độ chính xác (bao gồm cả góc phương vị, tốc độ và chiều dọc) trong từng vị trí GPS/GNSS.
  • [C-SR] Are được linh hoạt đề xuất để báo cáo các phép đo GNSS ngay khi chúng được tìm thấy, ngay cả khi một vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
  • [C-SR] Đang được ĐỀ XUẤT để báo cáo tỷ lệ pseudoranges và pseudorange GNSS, rằng, trong điều kiện mở-sky sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với ít hơn 0,2 mét mỗi giây bình phương của gia tốc, là đủ để tính toán vị trí trong vòng 20 mét, và tốc độ trong vòng 0,2 mét mỗi giây, ít nhất 95% thời gian.

7.3.4. Con quay hồi chuyển

Triển khai thiết bị:

• [C-SR] Are Internet ĐỀ XUẤT KHÔNG NÊN sử dụng cảm biến con quay hồi chuyển trừ khi gia tốc kế 3 trục cũng được bao gồm.

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-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-2] PHẢI triển khai cảm biến TYPE_GYROSCOPE và KHÔNG PHẢI ĐỀ XUẤT cũng như triển khai cảm biến TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] PHẢI có độ phân giải 12 bit trở lên và NÊN có độ phân giải từ 16 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ù trừ trong 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 (phương sai 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ị hạn chế bởi giá trị này. Nói cách khác, nếu bạn đo phương sai của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì NÊN không lớn hơn 1e-7 Rad^2/s^2.
• [SR] Lỗi hiệu chuẩn là được liệt kê là nhỏ hơn 0,01 rad/s khi thiết bị đứng yên ở nhiệt độ phòng.
• NÊN báo cáo các sự kiện tối thiểu là 200 Hz.

Nếu các phương pháp triển khai thiết bị bao gồm con quay hồi chuyển 3 trục, cảm biến gia tốc kế và cảm biến từ kế, thì chúng:

• [C-2-1] PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR.

Nếu bạn triển khai thiết bị bao gồm gia tốc kế 3 trục và cảm biến con quay hồi chuyển 3 trục, thì chúng:

• [C-3-1] PHẢI triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION.
• [C-SR] AreRENDERED ĐỀ XUẤT để triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR.

7.3.5. Khí áp kế

Triển khai thiết bị:

• [C-SR] Are được linh hoạt đề xuất để bao gồm một khí áp kế (cảm biến áp suất không khí xung quanh).

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 độ.
• [SR] "{NÊN DÙNG" để có thể báo cáo các phép đo áp suất trong khoảng từ 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 khi thay đổi ~ 200m ở mực nước biển).

7.3.6. Nhiệt kế

Triển khai thiết bị:

• CÓ THỂ bao gồm cả nhiệt kế môi trường xung quanh (cảm biến nhiệt độ).
• CÓ THỂ, nhưng KHÔNG NÊN đi kèm cảm biến nhiệt độ CPU.

Nếu quá trình triển khai thiết bị có sử dụng nhiệt kế môi trường xung quanh (cảm biến nhiệt độ), thì bạn phải:

• [C-1-1] PHẢI được xác định là SENSOR_TYPE_AMBIENT_TEMPERATURE và PHẢI đo nhiệt độ môi trường xung quanh (phòng/cabin xe) từ vị trí người dùng đang tương tác với thiết bị theo độ C.
• [C-1-2] PHẢI được xác định là SENSOR_TYPE_TEMPERATURE.
• [C-1-3] PHẢI đo nhiệt độ của CPU của thiết bị.
• [C-1-4] KHÔNG ĐƯỢC đo nhiệt độ nào khác.

Lưu ý rằng loại cảm biến SENSOR_TYPE_TEMPERATURE không còn được dùng trong Android 4.0.

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, thì thiết bị đó sẽ:

• [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 các đố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 với bất kỳ hướng nào khác, thì bạn KHÔNG ĐƯỢC quyền truy cập vào cảm biến đó thông qua API này.
• [C-1-2] PHẢI có độ chính xác từ 1 bit trở lên.

7.3.9. Cảm biến có độ chân thực cao

Nếu quá trình triển khai thiết bị bao gồm một bộ cảm biến chất lượng cao hơn như được định nghĩa trong phần này và cung cấp cho các ứng dụng bên thứ ba, thì các cảm biến đó:

• [C-1-1] PHẢI xác định chức năng thông qua cờ tính năng android.hardware.sensor.hifi_sensors.

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

• [C-2-1] PHẢI có cảm biến TYPE_ACCELEROMETER:

  • PHẢI có phạm vi đo từ -8g đến + 8g, NÊN có phạm vi đo từ -16g đến +16g.
  • 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; PHẢI 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 với khả năng lưu vào bộ đệm ít nhất 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] Is phong phú NÊN DÙNG để có băng thông đo lường 3dB tối thiểu là 80% tần số Nyquist và phổ nhiễu trắng trong băng thông này.
  • NÊN có gia tốc đi bộ ngẫu nhiên dưới 30 μg & Hz khi 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 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ự thay đổi của độ nhạy trên trục chéo < 0,2% trong phạm vi nhiệt độ hoạt động của thiết bị.

• [C-2-2] PHẢI có TYPE_ACCELEROMETER_UNCALIBRATED với cùng yêu cầu về chất lượng như TYPE_ACCELEROMETER.

• [C-2-3] PHẢI có cảm biến TYPE_GYROSCOPE:

  • PHẢI có phạm vi đo lường ít 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; PHẢI hỗ trợ SensorDirectChannel RATE_VERY_FAST.
  • PHẢI có độ nhiễu khi đo không được vượt quá 0,014°/s/πHz.
  • [C-SR] Is phong phú NÊN DÙNG để có băng thông đo lường 3dB tối thiểu là 80% tần số Nyquist và phổ nhiễu trắng trong băng thông này.
  • NÊN thử tốc độ đi bộ ngẫu nhiên dưới 0,001 °/s × Hz ở nhiệt độ phòng.
  • 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.
  • NÊN có sai số hiệu chuẩn nhỏ hơn 0,002 Rad/s trong khoảng 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à mức thay đổi độ nhạy trên trục chéo < 0,3% trong phạm vi nhiệt độ hoạt động của thiết bị.

• [C-2-4] PHẢI có TYPE_GYROSCOPE_UNCALIBRATED với cùng yêu cầu về chất lượng như 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 với cùng yêu cầu về chất lượng như TYPE_GEOMAGNETIC_FIELD và ngoài ra còn có:

  • PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 600 sự kiện cảm biến.
  • [C-SR] 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 là 50 Hz trở lên.

• [C-2-7] PHẢI có cảm biến TYPE_PRESSURE:

  • Phải có phạm vi đo ít nhất từ 300 đến 1100 hPa.
  • PHẢI có độ phân giải đo ít 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 với khả năng lưu vào bộ đệm ít nhất 300 sự kiện cảm biến.
  • PHẢI có mức tiêu thụ điện năng 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:
  • Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang chuyển động.
• [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 với khả năng lưu vào bộ đệm ít nhất 100 sự kiện cảm biến.
  • Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang chuyển động.
  • 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:
  • Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang chuyển động.
• [C-2-12] PHẢI có cảm biến TILT_DETECTOR:
  • Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang chuyển động.
• [C-2-13] Dấu thời gian sự kiện của cùng một sự kiện vật lý được báo cáo bởi Gia tốc kế, Con quay hồi chuyển và Từ kế PHẢI nằm trong phạm vi 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 vật lý do Gia tốc kế và Con quay hồi chuyển báo cáo PHẢI nằm trong phạm vi cách nhau 0,25 mili giây.
• [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 cơ sở thời gian với hệ thống con máy ảnh và lỗi trong vòng 1 mili giây.
• [C-2-15] PHẢI phân phối mẫu đến các ứng dụng trong vòng 5 mili giây kể từ thời điểm dữ liệu có sẵn trên bất kỳ cảm biến vật lý nào nêu trên đến ứng dụng.
• [C-2-16] KHÔNG ĐƯỢC có mức tiêu thụ điện cao hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 2,0 mW khi thiết bị đang di chuyển khi bật bất kỳ tổ hợp cảm biến nào 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ó PHẢI có khả nă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. Nguồn này bao gồm năng lượng do toàn bộ chuỗi cảm biến rút ra – 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 nào, 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à mức tỷ lệ báo cáo trực tiếp thông qua API isDirectChannelTypeSupported và getHighestDirectReportRateLevel.
• [C-3-2] PHẢI hỗ trợ ít nhất một trong hai loại kênh trực tiếp cảm biến cho tất cả các cảm biến khai báo hỗ trợ cho kênh trực tiếp cảm biến.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• NÊN hỗ trợ tính năng báo cáo sự kiện thông qua kênh trực tiếp của cảm biến cho cảm biến chính (biến thể không đánh thức) thuộc các loại sau:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Cảm biến sinh trắc học

Để biết thêm thông tin về cách đo mức độ bảo mật của tính năng Mở khoá bằng sinh trắc học, vui lòng xem tài liệu về Đo lường bảo mật bằng sinh trắc học.

Nếu các quá trình 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à Mạnh, Yếu hoặc Thuận tiện dựa trên tỷ lệ chấp nhận 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 khả năng của cảm biến sinh trắc học để tương tác với nền tảng và các ứng dụng của bên thứ ba. Theo mặc định, các cảm biến được phân loại là Thuận tiện và cần đáp ứng các yêu cầu bổ sung như nêu chi tiết bên dưới nếu muốn phân loại là Yếu hoặc Mạnh. Cả hệ thống nhận dạng sinh trắc học Yếu và Mạnh đều có các tính năng bổ sung như trình bày chi tiết dưới đây.

Để cung cấp cảm biến sinh trắc học cho ứng dụng bên thứ ba, các cách triển khai thiết bị:

• [C-0-1] PHẢI đáp ứng các yêu cầu về dữ liệu sinh trắc học ở mức Mạnh hoặc Yếu theo định nghĩa trong tài liệu này.

Để cho phép các ứng dụng bên thứ ba truy cập vào khoá kho khoá, hãy triển khai thiết bị:

• [C-0-2] PHẢI đáp ứng các yêu cầu về mức Strong theo quy định trong tài liệu này.

Ngoài ra:

• [C-0-3] PHẢI được ghép nối với một hành động xác nhận rõ ràng (ví dụ: nhấn nút) nếu hệ thống nhận dạng sinh trắc học Strong đó mang tính thụ động (ví dụ: khuôn mặt hoặc mống mắt khi không có tín hiệu rõ ràng về ý định của người dùng).
  • [C-SR] Hành động xác nhận cho hệ thống nhận dạng sinh trắc học thụ động là được liệt kê là tôi khuyến khích bạn bảo mật để một hệ điều hành hoặc nhân hệ điều hành không thể giả mạo thông tin đó. Ví dụ: điều này có nghĩa là thao tác xác nhận dựa trên nút vật lý được định tuyến thông qua 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) mà không thể điều khiển bằng bất kỳ phương tiện nào khác ngoài thao tác nhấn nút vật lý.

Nếu các phương pháp triển khai thiết bị muốn coi cảm biến sinh trắc học là Sự tiện lợi, thì họ sẽ:

• [C-1-1] PHẢI có tỷ lệ chấp nhận sai nhỏ hơn 0,002%.
• [C-1-2] PHẢI tiết lộ rằng chế độ này có thể kém an toàn hơn mã PIN, hình mở khoá, hoặc mật khẩu mạnh và liệt kê rõ ràng các rủi ro khi bật chế độ này, nếu tỷ lệ chấp nhận giả mạo và mạo danh cao hơn 7%.
• [C-1-3] PHẢI thử giới hạn số lần yêu cầu trong ít nhất 30 giây sau 5 lần thử sai để xác minh bằng sinh trắc học. Trong đó lần thử sai là thử nghiệm có chất lượng thu thập phù hợp (BIOMETRIC_ACQUIRED_GOOD) không khớp với thông tin sinh trắc học đã đăng ký.
• [C-1-4] PHẢI ngăn chặn việc thêm sinh trắc học mới mà không cần thiết lập chuỗi tin cậy trước bằng cách yêu cầu người dùng xác nhận hiện có hoặc thêm thông tin đăng nhập thiết bị mới (PIN/hình mở khoá/mật khẩu) được bảo mật bằng TEE; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện điều đó.
• [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 người dùng khi tài khoản của người dùng bị xoá (kể cả qua thao tác đặt lại về trạng thái ban đầu).
• [C-1-6] PHẢI tuân thủ cờ riêng cho dữ liệu nhận dạng sinh trắc học đó (tức là DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE hoặc DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] PHẢI thử thách người dùng thực hiện 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) mỗi 24 giờ một lần trở xuống đối với các thiết bị mới khởi chạy với phiên bản Android 10, mỗi 72 giờ một lần trở xuống đối với các thiết bị nâng cấp từ phiên bản Android trước đó.

• [C-1-8] 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 một trong các bước sau:

  • Khoảng thời gian chờ 4 giờ ở trạng thái rảnh, 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 thông tin xác thực thiết bị được xác nhận thành công.

  Việc nâng cấp các thiết bị từ một phiên bản Android cũ có thể được miễn tham gia C-1-8.

• [C-SR] AreĐể chỉ được đề xuất có tỷ lệ từ chối sai dưới 10%, giá trị này được đo trên thiết bị.

• [C-SR] Are Internet ĐỀ XUẤT NÊN có độ trễ dưới 1 giây, được đo từ khi phát hiện dữ liệu sinh trắc học, cho đến khi màn hình được mở khóa, đối với mỗi thông tin sinh trắc học đã đăng ký.

Nếu các quá trình triển khai thiết bị muốn coi cảm biến sinh trắc học là Yếu, thì thiết bị đó sẽ:

• [C-2-1] PHẢI đáp ứng tất cả yêu cầu cho Tiện lợi ở trên, ngoại trừ [C-1-2].
• [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%.
• [C-2-3] PHẢI triển khai kho khoá dựa trên phần cứng và thực hiện việc so khớp sinh trắc học trong môi trường thực thi tách biệt bên ngoài không gian nhân hoặc người dùng Android, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE) hoặc trên chip có kênh bảo mật dẫn đến môi trường thực thi tách biệt.
• [C-2-4] PHẢI có tất cả dữ liệu nhận dạng được mã hoá và xác thực bằng mật mã sao cho không thể thu nạ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 chip có kênh bảo mật cho môi trường thực thi tách biệt như được nêu trong nguyên tắc triển khai trên trang web Dự án nguồn mở Android.
• [C-2-5] Đối với hệ thống nhận dạng sinh trắc học dùng máy ảnh, trong khi quá trình xác thực hoặc đăng ký dựa trên sinh trắc học đang diễn ra:
  • PHẢI vận hành máy ảnh ở chế độ ngăn đọc hoặc thay đổi khung máy ảnh bên ngoài môi trường thực thi tách biệt hoặc ngăn khối có kênh bảo mật dẫn đến môi trường thực thi tách biệt.
  • Đối với các giải pháp camera đơn RGB, khung hình camera CÓ THỂ đọc được bên ngoài môi trường thực thi tách biệt để hỗ trợ các thao tác như 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 các lượt đă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 bất kỳ dữ liệu nào bắt nguồn từ dữ liệu đó (chẳng hạn như dữ liệu nhúng) cho Đơn vị xử lý ứng dụng bên ngoài ngữ cảnh của TEE.

• [C-2-8] PHẢI có quy trình xử lý bảo mật sao cho hệ điều hành hoặc hạt nhân bị xâm phạm không thể cho phép truyền dữ liệu trực tiếp vào để xác thực sai là người dùng.

  Nếu các hoạt động triển khai thiết bị đã được triển khai trên một phiên bản Android cũ hơn và không thể đáp ứng yêu cầu C-2-8 thông qua một bản cập nhật phần mềm hệ thống, thì các hoạt động này có thể được miễn trách nhiệm đáp ứng yêu cầu này.

Nếu các phương pháp triển khai thiết bị muốn coi cảm biến sinh trắc học là Mạnh, thì thiết bị đó sẽ:

• [C-3-1] PHẢI đáp ứng tất cả các yêu cầu của Weak ở trên. Việc nâng cấp thiết bị từ một phiên bản Android cũ sẽ không được miễn trừ C-2-7.
• [C-3-2] PHẢI có tỷ lệ chấp nhận giả mạo và mạo danh không được cao hơn 7%.
• [C-3-3] 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) mỗi 72 giờ một lần trở xuống.

7.3.12. 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 cảm biến TYPE_POSE_6DOF.
• [C-1-2] PHẢI chính xác hơn riêng vectơ xoay.

7,4. Khả năng kết nối dữ liệu

7.4.1. Điện thoại

“Điện thoại” được sử dụng bởi các API Android và tài liệu này đề cập cụ thể đến phần cứng liên quan đến việc thực hiện cuộc gọi thoại và gửi tin nhắn SMS qua mạng GSM hoặc CDMA. Tuy các cuộc gọi thoại này có thể hoặc không thể chuyển đổi gói, nhưng các cuộc gọi này đều phục vụ mục đích được Android coi là độc lập với mọi kết nối dữ liệu có thể triển khai bằng cùng một mạng. Nói cách khác, chức năng và API của "điện thoại" Android chỉ dành riêng cho cuộc gọi thoại và SMS. Ví dụ: các quá trình triển khai thiết bị không thể thực hiện cuộc gọi hoặc gửi/nhận tin nhắn SMS không được xem là thiết bị điện thoại, bất kể các thiết bị này có sử dụng mạng di động để kết nối dữ liệu hay không.

• Android CÓ THỂ được sử dụng trên các thiết bị không có phần cứng điện thoại. Điều đó có nghĩa 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ờ 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ế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ị hỗ trợ eUICC hoặc eSIM/SIM được nhúng và có kèm theo một cơ chế độc quyền để cung cấp chức năng eSIM cho nhà phát triển bên thứ ba, thì nhà phát triển bên thứ ba sẽ phải đáp ứng những yêu cầu sau:

• [C-3-1] PHẢI cung cấp bản triển khai EuiccManager API đầy đủ.

7.4.1.1. Khả năng tương thích với tính năng chặn số

Nếu các hoạt động triển khai thiết bị báo cáo android.hardware.telephony feature, chúng 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 về SDK.
• [C-1-3] PHẢI chặn tất cả cuộc gọi và tin nhắn từ một số điện thoại trong 'BlockedNumberProvider' mà không cần tương tác với ứng dụng. Trường hợp 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 tài liệu SDK.
• [C-1-4] KHÔNG ĐƯỢC ghi vào nhà cung cấp nhật ký cuộc gọi trên nền tảng đối với cuộc gọi bị chặn.
• [C-1-5] KHÔNG ĐƯỢC ghi vào Nhà cung cấp dịch vụ điện thoại đối với tin nhắn bị chặn.
• [C-1-6] PHẢI triển khai một giao diện người dùng quản lý số bị chặn, được mở bằng ý định do phương thức TelecomManager.createManageBlockedNumbersIntent() trả về.
• [C-1-7] KHÔNG ĐƯỢC cho phép người dùng thứ cấp xem hoặc chỉnh sửa các số bị chặn trên thiết bị vì nền tảng Android giả định người dùng chính có toàn quyền kiểm soát các dịch vụ điện thoại, một phiên bản duy nhất, trên thiết bị. Tất cả giao diện người dùng liên quan đến 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 vẫn PHẢI được tuân thủ.
• NÊN di chuyển các số bị chặn vào ứng dụng nhà cung cấp khi thiết bị cập nhật lên Android 7.0.

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, 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 khả năng 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 không hỗ trợ tính năng giữ được chỉ định qua CAPABILITY_SUPPORT_HOLD.
• [C-1-3] PHẢI có một ứng dụng triển khai InCallService.

• [C-SR] Are được linh hoạt đề xuất để thông báo cho người dùng rằng việc trả lời một cuộc gọi đến sẽ làm gián đoạn 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 bằng một thông báo quan trọng cho người dùng biết rằng việc trả lời một cuộc gọi đến sẽ khiến cuộc gọi kia bị ngắt.

• [C-SR] AreĐể đề xuất tải trước ứng dụng trình quay số mặc định, ứng dụng này hiển thị mục nhập nhật ký cuộc gọi và tên của ứng dụng bên thứ ba trong nhật ký cuộc gọi khi ứng dụng bên thứ ba đó đặt khoá bổ sung EXTRA_LOG_SELF_MANAGED_CALLS trên PhoneAccount thành true.

• [C-SR] Are trì hoãn việc xử lý các sự kiện KEYCODE_MEDIA_PLAY_PAUSE và KEYCODE_HEADSETHOOK của tai nghe âm thanh cho các API android.telecom như dưới đây:
  • Gọi Connection.onDisconnect() khi phát hiện thấy thao tác nhấn nhanh của 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 thao tác 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.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 các quá trình triển khai thiết bị có hỗ trợ 802.11 và hiển thị chức năng này cho một ứng dụng bên thứ ba, thì các quá trình triển khai đó:

• [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ư mô tả trong tài liệu SDK.
• [C-1-4] PHẢI hỗ trợ DNS đa hướng (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) tại bất kỳ thời điểm hoạt động nào bao gồm:
  • Ngay cả khi màn hình không ở trạng thái hoạt động.
  • Đối với các hoạt động triển khai thiết bị Android TV, ngay cả khi ở trạng thái nguồn ở chế độ chờ.
• [C-1-5] KHÔNG ĐƯỢC coi lệnh gọi phương thức API WifiManager.enableNetwork() là chỉ báo đầy đủ để chuyển đổi Network đang hoạt động được dùng theo mặc định cho lưu lượng truy cập ứng dụng và được trả về bằng các phương thức API ConnectivityManager như getActiveNetwork và registerDefaultNetworkCallback. Nói cách khác, họ có thể chỉ vô hiệu hoá quyền truy cập Internet do bất kỳ nhà cung cấp mạng nào khác cung cấp (ví dụ: dữ liệu di động) nếu họ xác thực thành công rằng mạng Wi-Fi đang cung cấp quyền truy cập Internet.
• [C-1-6] Are Always recommended to, khi phương thức API ConnectivityManager.reportNetworkConnectivity() đượ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 cho phép truy cập Internet nữa, hãy chuyển sang bất kỳ mạng nào khác hiện có (ví dụ: dữ liệu di động) cung cấp quyền truy cập Internet.
• [C-SR] Are được linh hoạt đề xuất để sắp xếp ngẫu nhiên địa chỉ MAC nguồn và số thứ tự của khung yêu cầu thăm dò, một lần vào đầu mỗi lần quét, trong khi STA bị ngắt kết nối.
  • Mỗi nhóm khung yêu cầu thăm dò bao gồm một lần quét NÊN sử dụng một địa chỉ MAC nhất quán (KHÔNG NÊN sắp xếp ngẫu nhiên địa chỉ MAC giữa quá trình quét).
  • Số thứ tự yêu cầu đầu dò NÊN lặp lại như bình thường (tuần tự) giữa các yêu cầu đầu dò trong một lần quét.
  • Số thứ tự yêu cầu thăm dò NÊN sắp xếp ngẫu nhiên giữa lần yêu cầu thăm dò cuối cùng của lần quét và yêu cầu thăm dò đầu tiên của lần quét tiếp theo.
• [C-SR] Are trìy REVIEW, trong khi STA bị ngắt kết nối, để chỉ cho phép các phần tử sau trong khung yêu cầu thăm dò:
  • Bộ thông số SSID (0)
  • Bộ thông số DS (3)

Nếu các quá trình triển khai thiết bị bao gồm tính năng hỗ trợ chế độ tiết kiệm điện Wi-Fi như định nghĩa trong tiêu chuẩn IEEE 802.11, thì các thiết bị đó phải đáp ứng những yêu cầu sau:

• [C-3-1] PHẢI tắt chế độ tiết kiệm điện Wi-Fi bất cứ khi nào một ứng dụng sử dụng khoá WIFI_MODE_FULL_HIGH_PERF hoặc khoá WIFI_MODE_FULL_LOW_LATENCY qua các API WifiManager.createWifiLock() và WifiManager.WifiLock.acquire(), đồng thời khoá đang hoạt động.
• [C-3-2] Độ trễ trung bình khứ hồi giữa thiết bị và một điểm truy cập khi thiết bị đang ở chế độ Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) PHẢI nhỏ hơn độ trễ khi dùng chế độ Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] Are Để giảm thiểu độ trễ trọn vòng của Wi-Fi, bất cứ khi nào một Khoá độ trễ thấp (WIFI_MODE_FULL_LOW_LATENCY) được thu nạp và có hiệu lực.

Nếu quá trình triển khai thiết bị hỗ trợ Wi-Fi và sử dụng Wi-Fi để quét vị trí, thì các quá trình triển khai đó:

• [C-2-1] PHẢI cung cấp một thuộc tính tương tác với người dùng để bật/tắt giá trị được đọc thông qua phương thức API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Triển khai 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ư 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.

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 cung cấp tính năng hỗ trợ Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS) như mô tả trong Tài liệu về SDK Android.

Nếu các hoạt động triển khai thiết bị bao gồm tính năng hỗ trợ TDLS và TDLS do WiFiManager API bật, thì các hoạt động triển khai đó:

• [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ể kém hơn so với khi đ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ị bao gồm tính năng hỗ trợ tính năng Nhận biết Wi-Fi và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các quá trình đó sẽ:

• [C-1-1] PHẢI triển khai các API WifiAwareManager theo 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 với khoảng thời gian không quá 30 phút và bất cứ khi nào tính năng Nhận biết Wi-Fi được bật.

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à Vị trí Wi-Fi như mô tả trong Mục 7.4.2.5 và hiển thị những chức năng này cho các ứng dụng bên thứ ba, thì các chức năng này sẽ:

• [C-2-1] PHẢI triển khai các API khám phá nhận biết vị trí: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm và onServiceDiscoveredAssetsedAssets.

7.4.2.4. Điểm truy cập Wi-Fi

Triển khai thiết bị:

• NÊN bao gồm tính năng hỗ trợ Wi-Fi Passpoint.

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

• [C-1-1] PHẢI triển khai các API WifiManager liên quan đến Passpoint như mô tả trong tài liệu về SDK.
• [C-1-2] PHẢI hỗ trợ tiêu chuẩn IEEE 802.11u, cụ thể có liên quan đến việc Khám phá và lựa chọn mạng, chẳng hạn như Dịch vụ quảng cáo chung (GAS) và Giao thức truy vấn mạng truy cập (ANQP).

Ngược lại, nếu quá trình triển khai thiết bị không hỗ trợ Wi-Fi Passpoint:

• [C-2-1] Việc triển khai các API WifiManager liên quan đến Passpoint PHẢI gửi một UnsupportedOperationException.

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ị có hỗ trợ Vị trí Wi-Fi và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì họ sẽ:

• [C-1-1] PHẢI triển khai các API WifiRttManager theo 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 được thực thi trong khi giao diện Wi-Fi mà RTT đang được thực thi không được liên kết với một Điểm truy cập.

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 quá trình triển khai thiết bị bao gồm tính năng hỗ trợ giảm tải Wi-Fi duy trì hoạt động và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các quy trình đó 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 và ít nhất một khe giữ kết nối qua mạng di động.

Nếu các quá trình triển khai thiết bị không bao gồm tính năng hỗ trợ giảm tải cho tính năng duy trì hoạt động Wi-Fi, các thiết bị đó sẽ:

• [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ó hỗ trợ Wi-Fi Easy Connect và hiển thị chức năng này cho các ứng dụng bên thứ ba, thì các ứng dụng đó sẽ:

• [C-1-1] PHẢI triển khai API Ý định Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI theo mô tả trong tài liệu về SDK.
• [C-1-2] PHẢI có phương thức WifiManager#isEasyConnectSupported() trả về true.

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 các quá trình triển khai thiết bị khai báo tính năng android.hardware.vr.high_performance, thì các quá trình triển khai thiết bị đó sẽ:

• [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ó hỗ trợ Bluetooth và Bluetooth năng lượng thấp, thì các cách triển khai đó:

• [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. cho 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, thì các quá trình triển khai 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 các API Bluetooth dựa trên GATT (generic thuộc tính hồ sơ) như mô tả trong tài liệu SDK và android.bluetooth.
• [C-3-3] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isOffloadedFilteringSupported() để cho biết liệu logic lọc cho các lớp API ScanFilter có được triển khai hay không.
• [C-3-4] PHẢI báo cáo giá trị chính xác cho BluetoothAdapter.isMultipleAdvertisementSupported() để cho biết liệu Quảng cáo năng lượng thấp có được hỗ trợ hay không.
• NÊN hỗ trợ giảm tải logic lọc cho chipset bluetooth khi triển khai ScanFilter API.
• NÊN hỗ trợ giảm tải quá trình quét theo lô sang chipset Bluetooth.

• NÊN hỗ trợ nhiều quảng cáo có ít nhất 4 vị trí.

• [SR] GameActivity NÊN triển khai thời gian chờ dành cho Địa chỉ riêng có thể phân giải (RPA) không quá 15 phút và xoay địa chỉ khi hết thời gian chờ để bảo vệ quyền riêng tư của người dùng.

Nếu các quá trình triển khai thiết bị có hỗ trợ Bluetooth LE và sử dụng Bluetooth LE để quét vị trí, thì các thiết bị đó:

• [C-4-1] PHẢI cung cấp một thuộc tính tương tác cho người dùng để bật/tắt giá trị được đọc qua API hệ thống BluetoothAdapter.isBleScanAlwaysAvailable().

Nếu các phương thức triển khai thiết bị có hỗ trợ Bluetooth LE và Cấu hình thiết bị trợ thính, như mô tả trong bài viết Hỗ trợ thiết bị trợ thính bằng Bluetooth LE, thì các thiết bị đó:

• [C-5-1] PHẢI trả về true cho BluetoothAdapter.getProfileProxy(context, Listen, BluetoothProfile.HEARING_AID).

7.4.4. Giao tiếp phạm vi gần

Triển khai thiết bị:

• PHẢI có một bộ thu phát và phần cứng có liên quan cho tính năng Giao tiếp phạm vi gần (NFC).
• [C-0-1] PHẢI triển khai các API android.nfc.NdefMessage và android.nfc.NdefRecord ngay cả khi chúng không hỗ trợ NFC hoặc khai báo tính năng android.hardware.nfc vì các lớp đại diện cho định dạng biểu diễn dữ liệu không phụ thuộc vào giao thức.

Nếu việc triển khai thiết bị có bao gồm phần cứng NFC và dự định cung cấp phần cứng này cho các ứng dụng bên thứ ba, thì họ:

• [C-1-1] PHẢI báo cáo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature().
• PHẢI có khả năng đọc và ghi thông báo NDEF qua các tiêu chuẩn NFC sau đây:
• [C-1-2] PHẢI có khả năng hoạt động như một người đọc/người ghi Diễn đàn NFC (như được xác định trong thông số kỹ thuật của Diễn đàn NFC NFCDiễn đàn-TS-DigitalProtocol-1.0) thông qua các tiêu chuẩn NFC sau:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Các loại thẻ diễn đàn NFC 1, 2, 3, 4, 5 (được định nghĩa bởi Diễn đàn NFC)

• [SR] ôi DƯỢC ĐỀ XUẤT có khả năng đọc và ghi tin nhắn NDEF cũng như dữ liệu thô thông qua các tiêu chuẩn NFC sau. Lưu ý rằng mặc dù các tiêu chuẩn NFC được nêu là CÓ DỄ DÀNG YÊU CẦU, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai được lên kế hoạch thay đổi những tiêu chuẩn này thành PHẢI. Các tiêu chuẩn này là không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị mới và hiện có chạy phiên bản Android này được VERY{7} ENCOURAGED đáp ứng các yêu cầu này ngay bây giờ để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.

• [C-1-13] PHẢI cuộc thăm dò ý kiến cho tất cả các công nghệ được hỗ trợ khi ở chế độ phát hiện NFC.

• PHẢI ở chế độ phát hiện NFC khi thiết bị đang bật với màn hình đang hoạt động và màn hình khóa đã mở khóa.
• PHẢI có khả năng đọc mã vạch và URL (nếu được mã hoá) của sản phẩm Mã vạch NFC của Thinfilm.

Lưu ý rằng các đường liên kết công khai không có sẵn cho các thông số kỹ thuật của Diễn đàn JIS, ISO và NFC được trích dẫn ở trên.

Android có hỗ trợ chế độ Giả lập thẻ máy chủ NFC (HCE).

Nếu thiết bị được triển khai bao gồm bộ vi mạch điều khiển NFC có khả năng HCE (dành cho NfcA và/hoặc NfcB) và hỗ trợ định tuyến ID ứng dụng (AID), thì chúng:

• [C-2-1] PHẢI báo cáo hằng số tính năng android.hardware.nfc.hce.
• [C-2-2] PHẢI hỗ trợ API HCE NFC như đã xác định trong SDK Android.

Nếu thiết bị được triển khai bao gồm bộ vi mạch điều khiển NFC có khả năng HCE cho NfcF và triển khai tính năng này cho các ứng dụng bên thứ ba, thì các thiết bị đó:

• [C-3-1] PHẢI báo cáo hằng số tính năng android.hardware.nfc.hcef.
• [C-3-2] PHẢI triển khai NfcF Card Emulation API như đã xác định trong SDK Android.

Nếu quá trình triển khai thiết bị có hỗ trợ NFC chung như mô tả trong phần này và hỗ trợ các công nghệ MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF trên MIFARE Classic) trong vai trò người đọc/người ghi, thì họ:

• [C-4-1] PHẢI triển khai các API Android tương ứng như được ghi lại trong SDK Android.
• [C-4-2] PHẢI báo cáo đối tượng com.nxp.mifare từ phương thức android.content.pm.PackageManager.hasSystemFeature(). Lưu ý đây không phải là một tính năng tiêu chuẩn của Android. Do đó, tính năng này không xuất hiện dưới dạng hằng số trong lớp android.content.pm.PackageManager.

7.4.5. Khả năng mạng tối thiểu

Triển khai thiết bị:

• [C-0-1] PHẢI bao gồm tính năng hỗ trợ cho một hoặc nhiều hình thức nối mạng dữ liệu. Cụ thể, quá trình triển khai thiết bị PHẢI bao gồm khả năng hỗ trợ ít nhất một chuẩn dữ liệu có khả năng ở tốc độ 200 Kbit/giây trở lên. Ví dụ về các công nghệ đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet và Bluetooth PAN.
• NÊN bao gồm hỗ trợ cho ít nhất một chuẩn dữ liệu không dây phổ biến, chẳng hạn như 802.11 (Wi-Fi), khi một tiêu chuẩn mạng vật lý (chẳng hạn như Ethernet) là kết nối dữ liệu chính.
• CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu.
• [C-0-2] PHẢI bao gồm ngăn xếp mạng IPv6 và hỗ trợ giao tiếp IPv6 bằng cách sử dụng các API được quản lý, chẳng hạn như java.net.Socket và java.net.URLConnection, cũng như các API gốc, chẳng hạn như ổ cắm AF_INET6.
• [C-0-3] PHẢI bật IPv6 theo mặc định.
• PHẢI đảm bảo rằng giao tiếp IPv6 đáng tin cậy như IPv4, ví dụ:
  • [C-0-4] PHẢI duy trì kết nối IPv6 ở chế độ doze.
  • [C-0-5] Giới hạn tốc độ KHÔNG ĐƯỢC khiến thiết bị mất kết nối IPv6 trên bất kỳ mạng nào tuân thủ IPv6 mà sử dụng vòng đời RA ít nhất là 180 giây.
• [C-0-6] PHẢI cung cấp cho các ứng dụng của bên thứ ba kết nối IPv6 trực tiếp với mạng khi được kết nối với mạng IPv6, mà không có bất kỳ hình thức địa chỉ hoặc dịch cổng nào diễn ra cục bộ trên thiết bị. Cả API được quản lý như Socket#getLocalAddress hoặc Socket#getLocalPort) và API NDK (chẳng hạn như getsockname() hoặc IPV6_PKTINFO PHẢI trả về địa chỉ IP và cổng trên thực tế được dùng để gửi và nhận các gói dữ liệu trên mạng).

Mức độ hỗ trợ IPv6 cần thiết phụ thuộc vào loại mạng, như trình bày trong các yêu cầu sau.

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

• [C-1-1] PHẢI hỗ trợ thao tác Dual-stack và IPv6-only trên Wi-Fi.

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

• [C-2-1] PHẢI hỗ trợ thao tác ngăn xếp kép trên Ethernet.

Nếu quá trình triển khai thiết bị có hỗ trợ Dữ liệu di động, thì các thiết bị đó:

• NÊN hỗ trợ hoạt động IPv6 (chỉ IPv6 và có thể ngăn xếp kép) trên mạng di động.

Nếu quá trình triển khai thiết bị hỗ trợ nhiều loại mạng (ví dụ: Wi-Fi và dữ liệu di động), chúng:

• [C-3-1] PHẢI đáp ứng đồng thời các yêu cầu nêu trên đối với mỗi mạng khi thiết bị được kết nối đồng thời với nhiều loại mạng.

7.4.6. Cài đặt đồng bộ hóa

Triển khai thiết bị:

• [C-0-1] PHẢI bật chế độ cài đặt tự động đồng bộ hoá chính theo mặc định để phương thức getMasterSyncAutomatically() trả về “true”.

7.4.7. Trình tiết kiệm dữ liệu

Nếu quá trình triển khai thiết bị có bao gồm kết nối có đo lượng dữ liệu, thì các quá trình đó sẽ:

• [SR] "{NÊN DÙNG" để cung cấp chế độ tiết kiệm dữ liệu.

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

• [C-1-1] PHẢI hỗ trợ tất cả API trong lớp ConnectivityManager như mô tả trong tài liệu về SDK
• [C-1-2] PHẢI cung cấp giao diện người dùng trong phần cài đặt, xử lý ý định Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, cho phép người dùng thêm ứ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-2-1] PHẢI trả về giá trị RESTRICT_BACKGROUND_STATUS_DISABLED cho ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] KHÔNG ĐƯỢC truyền phát ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] PHẢI có một hoạt động xử lý ý định Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS nhưng CÓ THỂ triển khai hoạt động này ở dạng không hoạt động.

7.4.8. Phần tử bảo mật

Nếu các quá trình triển khai thiết bị hỗ trợ các phần tử bảo mật có khả năng Open Mobile API và cung cấp các phần tử đó cho ứng dụng của bên thứ ba, thì chúng:

• [C-1-1] PHẢI liệt kê các trình đọc của Phần tử bảo mật hiện có khi phương thức android.se.omapi.SEService.getReaders() được gọi.

7,5. Camera

Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh, thì chúng:

• [C-1-1] PHẢI khai báo cờ tính năng android.hardware.camera.any.
• [C-1-2] PHẢI có thể cho một ứng dụng phân bổ đồng thời 3 bitmap RGBA_8888 bằng với kích thước hình ảnh được tạo bởi cảm biến máy ảnh có độ phân giải lớn nhất trên thiết bị, trong khi máy ảnh được mở với mục đích xem trước cơ bản và vẫn chụp.
• [C-1-3] PHẢI đảm bảo rằng ứng dụng máy ảnh mặc định được cài đặt sẵn xử lý các ý định MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE hoặc MediaStore.ACTION_VIDEO_CAPTURE, có trách nhiệm xoá thông tin vị trí của người dùng trong siêu dữ liệu hình ảnh trước khi gửi đến ứng dụng nhận khi ứng dụng nhận không có ACCESS_FINE_LOCATION.

7.5.1. Camera mặt sau

Camera mặt sau là camera nằm ở cạnh của thiết bị đối diện với màn hình; tức là hệ thống này chụp ảnh các cảnh ở phía xa của thiết bị, giống như một camera truyền thống.

Triển khai thiết bị:

• NÊN có máy ảnh mặt sau.

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

• [C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera và android.hardware.camera.any.
• [C-1-2] PHẢI có độ phân giải ít nhất là 2 megapixel.
• NÊN triển khai tính năng tự động lấy nét phần cứng hoặc tự động lấy nét bằng phần mềm trong trình điều khiển máy ảnh (trong suốt đối với phần mềm ứng dụng).
• CÓ THỂ dùng phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh mở rộng).
• CÓ THỂ bao gồm cả đèn flash.

Nếu máy ảnh có đèn flash:

• [C-2-1] đèn flash KHÔNG ĐƯỢC sáng khi phiên bản android.hardware.Camera.PreviewCallback đã được đăng ký trên bề mặt xem trước của máy ảnh, trừ khi ứng dụng đã bật đèn flash một cách rõ ràng bằng cách bật thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON của đối tượng Camera.Parameters. Xin lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng máy ảnh tích hợp sẵn trong hệ thống của thiết bị, mà chỉ áp dụng cho các ứng dụng của bên thứ ba sử dụng Camera.PreviewCallback.

7.5.2. Máy ảnh mặt trước

Camera mặt trước là camera nằm ở cùng một phía của thiết bị với màn hình; tức là camera thường được dùng để chụp ảnh người dùng, chẳng hạn như cho hội nghị truyền hình và các ứng dụng tương tự.

Triển khai thiết bị:

• CÓ THỂ bao gồm cả máy ảnh mặt trước.

Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh mặt trước, thì các thiết bị đó:

• [C-1-1] PHẢI báo cáo cờ tính năng android.hardware.camera.any và android.hardware.camera.front.
• [C-1-2] PHẢI có độ phân giải tối thiểu là VGA (640x480 pixel).
• [C-1-3] KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm mặc định cho API Máy ảnh và KHÔNG ĐƯỢC định cấu hình API để coi máy ảnh mặt trước là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị.
• [C-1-4] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng mà ứng dụng chỉ định khi ứng dụng hiện tại đã yêu cầu rõ ràng xoay màn hình của Máy ảnh thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation(). Ngược lại, bản xem trước PHẢI được phản chiếu dọc theo trục ngang mặc định của thiết bị khi ứng dụng hiện tại không yêu cầu rõ ràng xoay màn hình Máy ảnh thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation().
• [C-1-5] KHÔNG ĐƯỢC phản chiếu luồng hình ảnh tĩnh hoặc video cuối cùng được trả về cho các lệnh gọi lại ứng dụng hoặc đã cam kết lưu trữ nội dung nghe nhìn.
• [C-1-6] PHẢI phản chiếu hình ảnh được chế độ xem hậu kỳ hiển thị theo cùng cách như luồng hình ảnh xem trước của máy ảnh.
• CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, đèn flash, v.v.) dành cho máy ảnh mặt sau như mô tả trong phần 7.5.1.

Nếu người dùng có thể xoay quá trình triển khai thiết bị (chẳng hạn như tự động qua gia tốc kế hoặc theo cách thủ công thông qua hoạt động đầu vào của người dùng):

• [C-2-1] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng hiện tại của thiết bị.

7.5.3. Camera bên ngoài

Triển khai thiết bị:

• CÓ THỂ hỗ trợ một máy ảnh bên ngoài 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ị có hỗ trợ máy ảnh bên ngoài, thì các quá trình triển khai đó:

• [C-1-1] PHẢI khai báo cờ tính năng nền tảng android.hardware.camera.external và android.hardware camera.any.
• [C-1-2] PHẢI hỗ trợ USB Video Class (UVC 1.0 trở lên) nếu camera bên ngoài kết nối thông qua cổng máy chủ USB.
• [C-1-3] PHẢI vượt qua các bài kiểm tra CTS của máy ảnh với một thiết bị máy ảnh bên ngoài được kết nối. Bạn có thể xem thông tin chi tiết về quy trình kiểm thử CTS của máy ảnh tại source.android.com.
• NÊN hỗ trợ các hoạt động nén video như MJPEG để cho phép truyền các luồng hình ảnh chất lượng cao chưa được mã hóa (ví dụ: luồng hình ảnh thô hoặc được nén độc lập).
• CÓ THỂ hỗ trợ nhiều máy ảnh.
• CÓ thể hỗ trợ phương thức mã hoá video dựa trên máy ảnh.

Nếu phương thức mã hoá video dựa trên camera được hỗ trợ:

• [C-2-1] Luồng không mã hoá / MJPEG đồng thời (QVGA hoặc độ phân giải cao hơn) PHẢI có thể truy cập được vào quá trình triển khai thiết bị.

7.5.4. Hành vi của API máy ảnh

Android bao gồm hai gói API để truy cập vào máy ảnh, API android.hardware.camera2 mới hiển thị chức năng điều khiển máy ảnh ở cấp độ thấp hơn cho ứng dụng, bao gồm các luồng phát trực tuyến/loạt bản không có bản sao hiệu quả và kiểm soát độ phơi sáng, độ tăng, mức tăng cân bằng trắng, chuyển đổi màu sắc, khử nhiễu, làm sắc nét, v.v.

Gói API cũ android.hardware.Camera được đánh dấu là không dùng nữa trong Android 5.0 nhưng vẫn PHẢI cho phép các ứng dụng dùng. Việc triển khai thiết bị Android PHẢI đảm bảo khả năng hỗ trợ liên tục của API như mô tả trong phần này và trong SDK Android.

Tất cả các tính năng phổ biến giữa lớp android.hardware.Camera không dùng nữa và gói android.hardware.camera2 mới hơn PHẢI có hiệu suất và chất lượng tương đương trong cả hai API. Ví dụ: với các chế độ cài đặt tương đương, tốc độ và độ chính xác tự động lấy nét PHẢI giống hệt nhau và chất lượng ảnh chụp PHẢI giống nhau. Các tính năng phụ thuộc vào ngữ nghĩa khác nhau của 2 API không bắt buộc phải có tốc độ hoặc chất lượng trùng khớp, nhưng PHẢI khớp chặt chẽ nhất có thể.

Quá trình triển khai thiết bị PHẢI triển khai các hành vi sau đây cho các API liên quan đến camera đối với tất cả camera hiện có. Triển khai thiết bị:

• [C-0-1] PHẢI sử dụng android.hardware.PixelFormat.YCbCr_420_SP cho dữ liệu xem trước được cung cấp cho các lệnh gọi lại ứng dụng khi một ứng dụng chưa từng gọi android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] PHẢI ở định dạng mã hoá NV21 khi ứng dụng đăng ký phiên bản android.hardware.Camera.PreviewCallback và hệ thống gọi phương thức onPreviewFrame() và định dạng xem trước là YCbCr_420_SP, dữ liệu trong byte[] được truyền vào onPreviewFrame(). Tức là NV21 PHẢI là giá trị mặc định.
• [C-0-3] PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số android.graphics.ImageFormat.YV12) cho bản xem trước của máy ảnh đối với cả máy ảnh trước và sau đối với android.hardware.Camera. (Máy ảnh và bộ mã hoá video phần cứng có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng việc triển khai thiết bị PHẢI hỗ trợ chuyển đổi sang YV12.)
• [C-0-4] PHẢI hỗ trợ các định dạng android.hardware.ImageFormat.YUV_420_888 và android.hardware.ImageFormat.JPEG dưới dạng kết quả đầu ra thông qua API android.media.ImageReader cho các thiết bị android.hardware.camera2 quảng cáo chức năng REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE trong android.request.availableCapabilities.
• [C-0-5] vẫn PHẢI triển khai Camera API đầy đủ có trong tài liệu Android SDK, bất kể thiết bị có tự động lấy nét phần cứng hoặc các tính năng khác hay không. Ví dụ: máy ảnh thiếu tính năng tự động lấy nét PHẢI vẫn gọi mọi thực thể android.hardware.Camera.AutoFocusCallback đã đăng ký (mặc dù phiên bản này không liên quan đến máy ảnh không tự động lấy nét.) Lưu ý rằng điều này áp dụng cho máy ảnh mặt trước; chẳng hạn như mặc dù hầu hết các máy ảnh mặt trước không hỗ trợ tính năng tự động lấy nét, nhưng các lệnh gọi lại API vẫn PHẢI được "làm giả" như mô tả.
• [C-0-6] PHẢI nhận dạng và tuân thủ từng tên thông số được định nghĩa là một hằng số trong lớp android.hardware.Camera.Parameters và lớp android.hardware.camera2.CaptureRequest. Ngược lại, các hoạt động triển khai thiết bị KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số chuỗi được truyền đến phương thức android.hardware.Camera.setParameters() ngoài những phương thức được ghi nhận dưới dạng hằng số trên android.hardware.Camera.Parameters. Tức là các quá trình triển khai thiết bị PHẢI hỗ trợ tất cả các tham số Camera tiêu chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại thông số Camera tuỳ chỉnh. Ví dụ: các phương pháp triển khai trên thiết bị hỗ trợ chụp ảnh bằng kỹ thuật chụp ảnh dải động cao (HDR) PHẢI hỗ trợ tham số Camera.SCENE_MODE_HDR của máy ảnh.
• [C-0-7] PHẢI báo cáo mức độ hỗ trợ phù hợp bằng thuộc tính android.info.supportedHardwareLevel như mô tả trong SDK Android và báo cáo cờ tính năng khung thích hợp.
• [C-0-8] cũng PHẢI khai báo các chức năng của máy ảnh riêng lẻ của android.hardware.camera2 thông qua thuộc tính android.request.availableCapabilities và khai báo cờ tính năng thích hợp; PHẢI xác định cờ tính năng nếu có bất kỳ thiết bị máy ảnh đi kèm nào hỗ trợ tính năng này.
• [C-0-9] PHẢI truyền phát ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một ảnh mới và mục nhập của hình ảnh đó đã được thêm vào kho nội dung nghe nhìn.
• [C-0-10] PHẢI truyền phát ý định Camera.ACTION_NEW_VIDEO bất cứ khi nào máy ảnh ghi lại video mới và mục nhập của hình ảnh đã được thêm vào kho nội dung nghe nhìn.
• [C-0-11] PHẢI có tất cả máy ảnh có thể truy cập được qua API android.hardware.Camera không dùng nữa. API này cũng có thể truy cập được qua android.hardware.camera2.
• [C-SR] Đối với các thiết bị có nhiều máy ảnh RGB hướng về cùng một hướng, [2] ĐỀ XUẤT NÊN hỗ trợ thiết bị máy ảnh logic liệt kê chức năng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, bao gồm tất cả các máy ảnh RGB hướng về phía đó như thiết bị phụ thực.

Nếu hoạt động triển khai thiết bị cung cấp API máy ảnh độc quyền cho các ứng dụng bên thứ ba, thì họ:

• [C-1-1] PHẢI triển khai API máy ảnh như vậy bằng API android.hardware.camera2.
• CÓ THỂ cung cấp thẻ và/hoặc tiện ích của nhà cung cấp cho API android.hardware.camera2.

7.5.5. Hướng máy ảnh

Nếu quá trình triển khai thiết bị có máy ảnh mặt trước hoặc mặt sau, thì(các) máy ảnh đó:

• [C-1-1] PHẢI được định hướng sao cho chiều dài của máy ảnh phù hợp với chiều dài của màn hình. Tức là khi thiết bị được giữ theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang. Điều này áp dụng bất kể hướng tự nhiên của thiết bị là gì; tức là chế độ này áp dụng cho các thiết bị chính ở chế độ ngang cũng như các thiết bị chính ở chế độ dọc.

7,6. Bộ nhớ và dung lượng lưu trữ

7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu

Triển khai thiết bị:

• [C-0-1] PHẢI bao gồm một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ sử dụng để tải các tệp dữ liệu xuống và các ứng dụng này PHẢI có khả năng tải từng tệp có kích thước tối thiểu 100 MB xuống vị trí "bộ nhớ đệm" mặc định.

7.6.2. Bộ nhớ dùng chung của ứng dụng

Triển khai thiết bị:

• [C-0-1] PHẢI cung cấp bộ nhớ dùng chung cho các ứng dụng, còn thường được gọi là “bộ nhớ ngoài dùng chung”, "bộ nhớ dùng chung của ứng dụng" hoặc theo đường dẫn Linux "/sdcard" thiết bị được gắn vào.
• [C-0-2] PHẢI được định cấu hình với bộ nhớ dùng chung được gắn theo mặc định, nói cách khác là "ngoài hộp", bất kể bộ nhớ được triển khai trên thành phần bộ nhớ trong hay phương tiện lưu trữ di động (ví dụ: Khe cắm thẻ kỹ thuật số bảo mật).
• [C-0-3] PHẢI kết nối bộ nhớ dùng chung của ứng dụng trực tiếp trên đường dẫn Linux sdcard hoặc bao gồm một đường liên kết tượng trưng của Linux từ sdcard đến điểm gắn thực tế.
• [C-0-4] PHẢI thực thi quyền android.permission.WRITE_EXTERNAL_STORAGE trên bộ nhớ dùng chung này như được nêu trong SDK.
• [C-0-5] PHẢI bật bộ nhớ có giới hạn theo mặc định cho tất cả ứng dụng nhắm đến API cấp 29 trở lên, ngoại trừ các trường hợp sau:
  • thời điểm người dùng cài đặt ứng dụng trước khi thiết bị nâng cấp lên API cấp 29, bất kể API mục tiêu của ứng dụng là gì.
  • khi ứng dụng yêu cầu android:requestLegacyExternalStorage="true" trong tệp kê khai.
  • khi ứng dụng được cấp quyền android.permission.WRITE_MEDIA_STORAGE.
• [C-0-6] PHẢI thực thi việc các ứng dụng đã bật bộ nhớ có giới hạn không có quyền truy cập trực tiếp vào hệ thống tệp vào các tệp bên ngoài thư mục dành riêng cho ứng dụng, như được trả về bằng các phương thức API Context như Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() và Context.getObbDirs().
• [C-0-7] PHẢI loại bỏ siêu dữ liệu vị trí, chẳng hạn như thẻ GPS Exif, được lưu trữ trong các tệp đa phương tiện khi những tệp đó được truy cập thông qua MediaStore, trừ phi ứng dụng gọi có quyền ACCESS_MEDIA_LOCATION.

Quá trình triển khai thiết bị CÓ THỂ đáp ứng các yêu cầu nêu trên bằng một trong những cách sau:

• Bộ nhớ di động mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ Kỹ thuật số bảo mật (SD).
• Một phần của bộ nhớ trong (không thể tháo rời) như được triển khai trong Dự án nguồn mở Android (AOSP).

Nếu quá trình triển khai thiết bị sử dụng bộ nhớ có thể tháo rời để đáp ứng các yêu cầu trên, thì chúng:

• [C-1-1] PHẢI triển khai thông báo ngắn hoặc cửa sổ bật lên giao diện người dùng để cảnh báo người dùng khi không có phương tiện lưu trữ nào được chèn vào khe.
• [C-1-2] PHẢI bao gồm phương tiện lưu trữ có định dạng FAT (ví dụ: thẻ SD) hoặc hiện trên hộp và các tài liệu khác có sẵn tại thời điểm mua hàng cho biết phương tiện lưu trữ phải được mua riêng.

Nếu quá trình triển khai thiết bị sử dụng một phần bộ nhớ không thể tháo rời để đáp ứng các yêu cầu trên, thì họ:

• NÊN sử dụng phương thức triển khai AOSP của bộ nhớ dùng chung ứng dụng nội bộ.
• CÓ THỂ chia sẻ không gian lưu trữ với dữ liệu riêng tư của ứng dụng.

Nếu quá trình triển khai thiết bị bao gồm nhiều đường dẫn bộ nhớ dùng chung (chẳng hạn như cả khe cắm thẻ SD và bộ nhớ trong dùng chung), thì các quá trình triển khai thiết bị đó:

• [C-2-1] PHẢI cho phép các ứng dụng Android cài đặt sẵn và có đặc quyền có quyền WRITE_MEDIA_STORAGE ghi vào bộ nhớ ngoài phụ, trừ phi ghi vào các thư mục dành riêng cho gói hoặc trong URI được trả về bằng cách kích hoạt ý định ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] PHẢI yêu cầu quyền truy cập trực tiếp liên kết với quyền android.permission.WRITE_MEDIA_STORAGE chỉ được cấp cho các ứng dụng hiển thị cho người dùng khi quyền android.permission.WRITE_EXTERNAL_STORAGE cũng được cấp.
• [SR] "{khuyên dùng để đề xuất" rằng các ứng dụng Android được cài đặt sẵn và có đặc quyền sẽ sử dụng API công khai như MediaStore để tương tác với các thiết bị lưu trữ, thay vì dựa vào quyền truy cập trực tiếp do android.permission.WRITE_MEDIA_STORAGE cấp.

Nếu quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, thì quá trình triển khai thiết bị sẽ:

• [C-3-1] PHẢI cung cấp cơ chế truy cập dữ liệu trên bộ nhớ dùng chung của ứng dụng từ máy tính lưu trữ.
• NÊN hiển thị nội dung từ cả hai đường dẫn lưu trữ một cách minh bạch thông qua dịch vụ trình quét nội dung đa phương tiện của Android và android.provider.MediaStore.
• CÓ THỂ sử dụng bộ nhớ dung lượng lớn qua USB, nhưng NÊN sử dụng Giao thức truyền nội dung nghe nhìn để đáp ứng yêu cầu này.

Nếu các quá trình triển khai thiết bị có cổng USB có chế độ thiết bị ngoại vi USB và hỗ trợ Giao thức truyền nội dung nghe nhìn, thì các quá trình triển khai thiết bị đó sẽ:

• PHẢI tương thích với máy chủ Android MTP tham chiếu, Truyền tệp của Android.
• NÊN báo cáo lớp thiết bị USB là 0x00.
• NÊN báo cáo tên giao diện USB là 'MTP'.

7.6.3. Bộ nhớ tích hợp

Nếu thiết bị dự kiến sẽ là thiết bị di động, không giống như Truyền hình, thì cách triển khai thiết bị sẽ:

• [SR] linh hoạt NÊN triển khai bộ nhớ có thể áp dụng ở một vị trí ổn định lâu dài, vì việc vô tình ngắt kết nối các thiết bị này có thể gây mất dữ liệu/bị hỏng dữ liệu.

Nếu cổng của thiết bị lưu trữ có thể tháo rời nằm ở vị trí ổn định lâu dài, chẳng hạn như trong ngăn chứa pin hoặc nắp bảo vệ khác, thì cách triển khai thiết bị:

• [SR] Để lựa chọn mã khuyến mãi, bạn nên triển khai adoptable storage.

7,7. USB

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

• NÊN hỗ trợ chế độ thiết bị ngoại vi USB và PHẢI hỗ trợ chế độ máy chủ USB.

7.7.1. Chế độ thiết bị ngoại vi USB

Nếu quá trình triển khai thiết bị có một cổng USB hỗ trợ chế độ thiết bị ngoại vi:

• [C-1-1] Cổng PHẢI có thể kết nối được với máy chủ USB có cổng USB loại A hoặc loại C chuẩn.
• [C-1-2] PHẢI báo cáo giá trị chính xác của iSerialNumber trong mã mô tả thiết bị tiêu chuẩn USB thông qua android.os.Build.SERIAL.
• [C-1-3] PHẢI phát hiện bộ sạc 1.5A và 3.0A theo tiêu chuẩn điện trở Type-C và PHẢI phát hiện các thay đổi trong quảng cáo nếu chúng hỗ trợ USB Type-C.
• [SR] Cổng PHẢI sử dụng hệ số hình dạng USB micro-B, micro-AB hoặc Type-C. Các thiết bị Android mới và hiện có đều ĐƯỢC ĐỀ XUẤT ĐỂ đáp ứng những yêu cầu này để có thể nâng cấp lên bản phát hành nền tảng trong tương lai.
• [SR] Cổng PHẢI được đặt ở đáy thiết bị (theo hướng tự nhiên) hoặc bật tính năng xoay màn hình phần mềm cho tất cả các ứng dụng (bao gồm cả màn hình chính), để màn hình hiển thị chính xác khi thiết bị được định hướng với cổng ở dưới cùng. Các thiết bị Android mới và hiện có được ĐỀ XUẤT ĐỂ đáp ứng những yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
• [SR] NÊN triển khai tính năng hỗ trợ để vẽ dòng điện 1,5 A trong luồng HS và lưu lượng truy cập như quy định trong thông số kỹ thuật Sạc pin USB, bản sửa đổi 1.2. Các thiết bị Android mới và hiện có đều ĐƯỢC ĐỀ XUẤT ĐỂ đáp ứng những yêu cầu này để có thể nâng cấp lên bản phát hành nền tảng trong tương lai.
• [SR] ĐỀ XUẤT KHÔNG NÊN hỗ trợ các phương thức sạc thuộc quyền sở hữu riêng giúp sửa đổi điện áp Vbus vượt quá mức mặc định hoặc thay đổi vai trò của bồn rửa/nguồn, chẳng hạn như có thể dẫn đến vấn đề về khả năng tương tác với bộ sạc hoặc thiết bị hỗ trợ các phương thức Phân phối điện qua USB tiêu chuẩn. Mặc dù điều này được gọi là "NÊN DÙNG", nhưng trong các phiên bản Android trong tương lai, chúng tôi có thể YÊU CẦU tất cả thiết bị loại C để hỗ trợ khả năng tương tác đầy đủ với bộ sạc loại C tiêu chuẩn.
• [SR] "{NÊN DÙNG" để hỗ trợ tính năng Power Delivery cho việc hoán đổi vai trò dữ liệu và cấp nguồn khi những thiết bị này hỗ trợ chế độ máy chủ USB và USB Type-C.
• NÊN hỗ trợ Power Delivery để sạc điện cao áp và hỗ trợ các Chế độ thay thế, chẳng hạn như hiển thị.
• NÊN triển khai API và thông số của phụ kiện mở Android (AOA) như được nêu trong tài liệu về SDK Android.

Nếu quá trình triển khai thiết bị bao gồm cả cổng USB và triển khai thông số kỹ thuật AOA, thì các quá trình triển khai đó:

• [C-2-1] PHẢI khai báo khả năng hỗ trợ cho tính năng phần cứng android.hardware.usb.accessory.
• [C-2-2] Lớp bộ nhớ dung lượng USB PHẢI bao gồm chuỗi "android" ở cuối phần mô tả giao diện, chuỗi iInterface của bộ lưu trữ USB

7.7.2. Chế độ hỗ trợ USB

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

• [C-1-1] PHẢI triển khai API máy chủ lưu trữ USB của Android như được nêu trong SDK Android và PHẢI khai báo khả năng hỗ trợ cho tính năng phần cứng android.hardware.usb.host.
• [C-1-2] PHẢI triển khai hỗ trợ để kết nối các thiết bị ngoại vi USB tiêu chuẩn, nói cách khác, chúng PHẢI hoặc:
  • Có cổng loại C trên thiết bị hoặc đi kèm(các) cáp có thể điều chỉnh cổng độc quyền trên thiết bị thành cổng USB loại C tiêu chuẩn (thiết bị USB Type-C).
  • Có loại A trên thiết bị hoặc đi kèm với(các) cáp điều chỉnh cổng độc quyền trên thiết bị thành cổng USB loại A tiêu chuẩn.
  • Có cổng micro-AB trên thiết bị. Cổng này PHẢI mang theo một dây cáp tương thích với cổng loại A tiêu chuẩn.
• [C-1-3] KHÔNG ĐƯỢC gửi kèm bộ chuyển đổi chuyển đổi từ cổng USB loại A hoặc cổng micro-AB sang cổng loại C (ổ cắm).
• [C-SR] AreĐể chỉ định vị trí triển khai lớp âm thanh USB như được nêu trong tài liệu về SDK Android.
• NÊN hỗ trợ sạc thiết bị ngoại vi USB được kết nối khi ở chế độ máy chủ; quảng cáo dòng điện nguồn ít nhất là 1,5A như quy định trong phần Thông số kết thúc của Bản sửa đổi 1.2 về thông số kỹ thuật của cáp và đầu nối USB Type-C cho đầu nối USB Type-C hoặc sử dụng phạm vi dòng điện đầu ra của cổng sạc hạ nguồn(CDP) như được chỉ định trong Thông số kỹ thuật của tính năng Sạc pin USB, bản sửa đổi 1.2 cho giắc cắm Micro-AB.
• NÊN triển khai và hỗ trợ các tiêu chuẩn USB Type-C.

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và lớp âm thanh USB, thì các cách triển khai thiết bị đó:

• [C-2-1] PHẢI hỗ trợ lớp USB HID.
• [C-2-2] PHẢI hỗ trợ phát hiện và ánh xạ các trường dữ liệu HID sau đây được chỉ định trong USB HID Usage Tables và Yêu cầu sử dụng lệnh thoại tới các hằng số KeyEvent như dưới đây:
  • Mã nhận dạng sử dụng (0x0CD) của trang sử dụng (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • Mã nhận dạng sử dụng của trang sử dụng (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • Mã nhận dạng sử dụng của trang sử dụng (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Mã nhận dạng sử dụng (0x0CF) của trang sử dụng (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và Khung truy cập bộ nhớ (SAF), thì các phương thức triển khai đó:

• [C-3-1] PHẢI nhận dạng mọi thiết bị MTP (Giao thức truyền nội dung nghe nhìn) được kết nối từ xa và cho phép người dùng truy cập vào nội dung của các thiết bị đó thông qua ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT.

Nếu quá trình triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ máy chủ và USB Type-C, thì các cách triển khai đó:

• [C-4-1] PHẢI triển khai chức năng Cổng vai trò kép như được xác định trong thông số kỹ thuật USB Type-C (phần 4.5.1.3.3).
• [SR] "{khuyên dùng để hỗ trợ DisplayPort, NÊN hỗ trợ USB SuperSpeed Data Values" (Giá trị dữ liệu siêu tốc độ USB) và
• [SR] EmailAddress PENDING to NOT support Audio Adapter Accessory Mode as mô tả trong phụ lục A của USB Type-C Cable and Connector Specification violation 1.2.
• NÊN triển khai mô hình Thử.* sao cho phù hợp nhất với kiểu dáng thiết bị. Ví dụ: thiết bị cầm tay NÊN triển khai mô hình Thử.SNK.

7,8. Âm thanh

7.8.1. Micrô

Nếu quá trình triển khai thiết bị có micrô, thì họ:

• [C-1-1] PHẢI báo cáo hằng số tính năng android.hardware.microphone.
• [C-1-2] PHẢI đáp ứng các yêu cầu về bản ghi âm thanh trong mục 5.4.
• [C-1-3] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
• [SR] AreĐể nhà phát triển khuyến khích dùng tính năng ghi âm gần-ultrasound như mô tả trong section 7.8.3.

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

• [C-2-1] KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.microphone.
• [C-2-2] PHẢI triển khai API ghi âm ít nhất là không hoạt động, theo phần 7.

7.8.2. Đầu ra âm thanh

Nếu cách triển khai thiết bị bao gồm một loa hoặc một cổng đầu ra âm thanh/đa phương tiện cho một thiết bị ngoại vi đầu ra âm thanh, chẳng hạn như giắc cắm âm thanh 3,5 mm 4 dây dẫn hoặc cổng chế độ máy chủ USB sử dụng lớp âm thanh USB, thì các thiết bị đó phải:

• [C-1-1] PHẢI báo cáo hằng số tính năng android.hardware.audio.output.
• [C-1-2] PHẢI đáp ứng các yêu cầu về phát âm thanh trong phần 5.5.
• [C-1-3] PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
• [SR] Quy định đính kèm để hỗ trợ phát lại gần-ultrasound như mô tả trong section 7.8.3.

Nếu quá trình triển khai thiết bị không bao gồm loa hoặc cổng đầu ra âm thanh, thì các quá trình triển khai đó:

• [C-2-1] KHÔNG ĐƯỢC báo cáo tính năng android.hardware.audio.output.
• [C-2-2] PHẢI triển khai các API liên quan đến Đầu ra âm thanh ở mức tối thiểu là không hoạt động.

Trong mục này, "cổng đầu ra" là giao diện thực, chẳng hạn như giắc âm thanh 3,5 mm, cổng HDMI hoặc cổng chế độ hỗ trợ qua USB có lớp âm thanh USB. Tính năng hỗ trợ đầu ra âm thanh qua các giao thức dựa trên sóng vô tuyến như Bluetooth, Wi-Fi hoặc mạng di động không đủ điều kiện để bao gồm "cổng đầu ra".

7.8.2.1. Cổng âm thanh analog

Để tương thích với tai nghe và các phụ kiện âm thanh khác bằng giắc cắm âm thanh 3,5 mm trong hệ sinh thái Android, nếu cách triển khai thiết bị có một hoặc nhiều cổng âm thanh analog, thì các cổng đó:

• [C-SR] Are được linh hoạt đề nghị bao gồm ít nhất một trong số các cổng âm thanh để là một 4 Conductor 3.5mm audio jack.

Nếu thiết bị có giắc cắm âm thanh 3,5 mm 4 dây, thì chúng:

• [C-1-1] PHẢI hỗ trợ phát âm thanh cho tai nghe âm thanh nổi và tai nghe âm thanh nổi có micrô.
• [C-1-2] PHẢI hỗ trợ giắc cắm âm thanh TRRS theo thứ tự chân cắm CTIA.
• [C-1-3] PHẢI hỗ trợ phát hiện và ánh xạ đến mã phím cho 3 phạm vi trở kháng tương đương sau đây giữa micrô và dây dẫn mặt đất trên giắc cắm âm thanh:
  • 70 ohm trở xuống: KEYCODE_HEADSETHOOK
  • 210 – 290 ohm: KEYCODE_VOLUME_UP
  • 360 – 680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm giắc cắm, nhưng chỉ sau khi tất cả các điểm tiếp xúc trên giắc cắm chạm vào các đoạn có liên quan trên giắc cắm.
• [C-1-5] PHẢI có khả năng điều khiển ít nhất 150mV ± 10% điện áp đầu ra trên trở kháng loa 32 ohm.
• [C-1-6] PHẢI có điện áp thiên vị micrô trong khoảng 1,8V ~ 2,9V.
• [C-1-7] PHẢI phát hiện và ánh xạ đến mã phím cho phạm vi trở kháng tương đương sau đây giữa micrô và dây dẫn mặt đất trên giắc cắm âm thanh:
  • 110 – 180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR] Are Để hỗ trợ các giắc cắm âm thanh kèm theo thứ tự pin-out OMTP.
• [C-SR] AreRENDERED ĐỀ XUẤT để hỗ trợ tính năng ghi âm qua tai nghe âm thanh nổi có micrô.

Nếu các quá trình triển khai thiết bị có giắc âm thanh 4 dây dẫn 3,5 mm và hỗ trợ micrô, đồng thời truyền phát android.intent.action.HEADSET_PLUG với micrô có giá trị bổ sung được đặt là 1, thì các thiết bị đó sẽ:

• [C-2-1] PHẢI hỗ trợ phát hiện micrô trên phụ kiện âm thanh được cắm.

7.8.2.2. Cổng âm thanh kỹ thuật số

Để tương thích với tai nghe và các phụ kiện âm thanh khác bằng đầu nối USB-C và triển khai (lớp âm thanh USB) trên hệ sinh thái Android như nêu trong thông số kỹ thuật của tai nghe USB cho Android.

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

7.8.3. Siêu âm gần

Âm thanh siêu âm gần là băng tần 18,5 kHz đến 20 kHz.

Triển khai thiết bị:

• PHẢI báo cáo chính xác khả năng hỗ trợ tính năng âm thanh gần như siêu âm qua API AudioManager.getProperty như sau:

Nếu PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND là "true", thì các nguồn âm thanh VOICE_RECOGNITION và UNPROCESSED PHẢI đáp ứng các yêu cầu sau:

• [C-1-1] Phản hồi công suất trung bình của micrô trong băng tần từ 18,5 kHz đến 20 kHz KHÔNG được lớn hơn 15 dB dưới phản hồi tại 2 kHz.
• [C-1-2] Tỷ lệ tín hiệu không có trọng số so với nhiễu của micrô trên 18,5 kHz đến 20 kHz đối với âm 19 kHz ở -26 dBFS PHẢI không được thấp hơn 50 dB.

Nếu PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND là "true":

• [C-2-1] Phản hồi trung bình của loa trong 18,5 kHz - 20 kHz KHÔNG được thấp hơn 40 dB dưới phản hồi tại 2 kHz.

7.8.4. Tính toàn vẹn của tín hiệu

Triển khai thiết bị:

• NÊN cung cấp đường dẫn tín hiệu âm thanh không bị sự cố cho cả luồng đầu vào và đầu ra trên thiết bị cầm tay, như được xác định bằng 0 sự cố được đo trong quá trình kiểm tra một phút trên mỗi đường dẫn. Kiểm thử bằng [OboeTester] (https://github.com/google/bone/tree/master/apps/OboeTester) “Kiểm tra sự cố tự động”.

Bài kiểm tra cần có một thiết bị phần cứng vòng lặp âm thanh dùng trực tiếp với giắc 3, 5 mm và/hoặc kết hợp với bộ chuyển đổi USB-C sang giắc 3, 5 mm. Tất cả các cổng đầu ra âm thanh đều PHẢI được kiểm tra.

OboeTester hiện hỗ trợ đường dẫn AAudio, vì vậy, các tổ hợp sau NÊN được kiểm thử sự cố bằng AAudio:

Chế độ hoàn thành	Chia sẻ	Tốc độ lấy mẫu tín hiệu ra	Tiếng Chans	Âm thanh ngoài
THẤP_MỪNG	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	1	2
THẤP_MỪNG	ĐỘC QUYỀN	KHÔNG XÁC ĐỊNH	2	1
THẤP_MỪNG	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	1	2
THẤP_MỪNG	ĐÃ CHIA SẺ	KHÔNG XÁC ĐỊNH	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	48000	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	44100	2	1
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	1	2
KHÔNG CÓ	ĐÃ CHIA SẺ	16000	2	1

Một luồng đáng tin cậy PHẢI đáp ứng các tiêu chí sau cho Tỷ lệ tín hiệu trên nhiễu (SNR) và Độ méo hài tổng (THD) đối với hình sin 2000 Hz.

Bộ chuyển đổi	THD	SNR
loa chính, tích hợp, được đo bằng micrô tham chiếu bên ngoài	< 3%	>= 50 dB
micrô chính, tích hợp sẵn, được đo bằng loa tham chiếu bên ngoài	< 3%	>= 50 dB
giắc cắm 3,5 mm tương tự tích hợp, kiểm tra bằng bộ chuyển đổi loopback	Chưa đến 1%	>= 60 dB
Bộ sạc USB đi kèm với điện thoại, được kiểm tra bằng bộ chuyển đổi loopback	< 1%	>= 60 dB

7,9. Thực tế ảo

Android bao gồm các API và cơ sở vật chất để xây dựng "Thực tế ảo" (VR) bao gồm trải nghiệm thực tế ảo chất lượng cao trên thiết bị di động. Quá trình triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

7.9.1. Chế độ thực tế ảo

Android có hỗ trợ Chế độ thực tế ảo, một tính năng xử lý kết xuất hình nổi của thông báo và vô hiệu hoá các thành phần giao diện người dùng hệ thống bằng một mắt trong khi ứng dụng thực tế ảo chỉ tập trung vào người dùng.

7.9.2. Chế độ thực tế ảo – Hiệu suất cao

Nếu quá trình triển khai thiết bị hỗ trợ chế độ thực tế ảo, thì các thiết bị đó:

• [C-1-1] PHẢI có ít nhất 2 lõi vật lý.
• [C-1-2] PHẢI khai báo tính năng android.hardware.vr.high_performance.
• [C-1-3] PHẢI hỗ trợ chế độ hiệu suất bền vững.
• [C-1-4] PHẢI hỗ trợ OpenGL ES 3.2.
• [C-1-5] PHẢI hỗ trợ android.hardware.vulkan.level 0.
• PHẢI hỗ trợ android.hardware.vulkan.level 1 trở lên.
• [C-1-6] PHẢI triển khai EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace và hiển thị các tiện ích trong danh sách tiện ích EGL có sẵn.
• [C-1-8] PHẢI triển khai GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures và hiển thị các tiện ích trong danh sách tiện ích GL hiện có.
• [C-SR] AreRENDERED ĐỀ XUẤT để triển khai GL_EXT_external_buffer, GL_EXT_EGL_image_array và hiển thị các tiện ích trong danh sách tiện ích GL hiện có.
• [C-SR] AreĐể hỗ trợ Vulkan 1.1.
• [C-SR] Are Internet ĐỀ XUẤT NÊN triển khai VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image và hiển thị tiện ích này trong danh sách các tiện ích Vulkan hiện có.
• [C-SR] AreRENDERED ĐỀ XUẤT để hiển thị ít nhất một nhóm hàng đợi Vulkan, trong đó flags chứa cả VK_QUEUE_GRAPHICS_BIT và VK_QUEUE_COMPUTE_BIT, còn queueCount ít nhất là 2.
• [C-1-7] GPU và màn hình PHẢI có thể đồng bộ hoá quyền truy cập vào vùng đệm trước dùng chung sao cho kết xuất mắt xen kẽ của nội dung VR ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất sẽ được hiển thị mà không có hiện tượng xé hình.
• [C-1-9] PHẢI triển khai tính năng hỗ trợ cho AHardwareBuffer cờ AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA và AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT như mô tả trong NDK.
• [C-1-10] PHẢI triển khai tính năng hỗ trợ cho các AHardwareBuffer với mọi tổ hợp cờ sử dụng AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT cho ít nhất là các định dạng sau: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] AreĐể hỗ trợ việc phân bổ các AHardwareBuffer với nhiều hơn một lớp, cũng như cờ và định dạng được chỉ định trong C-1-10.
• [C-1-11] PHẢI hỗ trợ giải mã H.264 ít nhất 3840 x 2160 ở tốc độ 30 khung hình / giây, được nén ở mức trung bình 40 Mb/giây (tương đương với 4 phiên bản của 1920 x1080 ở tốc độ 30 fps-10 Mb/giây hoặc 2 phiên bản 1920 x 1080 Mbps-20 Mbps).
• [C-1-12] PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã ít nhất 1920 x 1080 ở tốc độ 30 khung hình/giây được nén ở mức trung bình 10 Mb/giây và PHẢI có khả năng giải mã 3840 x 2160 ở tốc độ 30 khung hình / giây-20 Mb/giây (tương đương với 4 phiên bản 1820 x 1 Mbps).
• [C-1-13] PHẢI hỗ trợ API HardwarePropertiesManager.getDeviceTemperatures và trả về các giá trị chính xác cho nhiệt độ trên da.
• [C-1-14] PHẢI có một màn hình được nhúng và độ phân giải của màn hình tối thiểu PHẢI là 1920 x 1080.
• [C-SR] AreNhà "NÊN DÙNG" có độ phân giải màn hình tối thiểu là 2560 x 1440.
• [C-1-15] Màn hình PHẢI cập nhật ít nhất 60 Hz khi ở Chế độ thực tế ảo.
• [C-1-17] Màn hình PHẢI hỗ trợ chế độ độ bền thấp với thời lượng ổn định ≤ 5 mili giây, sự bền vững được định nghĩa là khoảng thời gian mà một điểm ảnh phát ra ánh sáng.
• [C-1-18] PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data dài Extension section 7.4.3.
• [C-1-19] PHẢI hỗ trợ và báo cáo đúng cách Direct Channel Type (Loại kênh trực tiếp) cho tất cả các loại cảm biến mặc định sau đây:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Are mã ĐỀ XUẤT NÊN hỗ trợ loại kênh trực tiếp TYPE_HARDWARE_BUFFER cho tất cả các Loại kênh trực tiếp nêu trên.
• [C-1-21] PHẢI đáp ứng các yêu cầu liên quan đến con quay hồi chuyển, gia tốc kế và từ kế cho android.hardware.hifi_sensors, như quy định trong mục 7.3.9.
• [C-SR] AreĐể hỗ trợ tính năng android.hardware.sensor.hifi_sensors.
• [C-1-22] PHẢI có chuyển động hai đầu đến độ trễ photon không cao hơn 28 mili giây.
• [C-SR] Are được linh hoạt đề xuất sử dụng để có chuyển động hai đầu đến photon latency không quá 20 mili giây.
• [C-1-23] PHẢI có tỷ lệ khung hình đầu tiên, là tỷ lệ giữa độ sáng của các điểm ảnh trên khung hình đầu tiên sau khi chuyển từ màu đen sang trắng và độ sáng của các điểm ảnh trắng ở trạng thái ổn định, ít nhất là 85%.
• [C-SR] Are mã hóa NÊN DÙNG để có tỷ lệ khung hình đầu tiên tối thiểu là 90%.
• CÓ THỂ cung cấp một lõi độc quyền cho ứng dụng trên nền trước và CÓ THỂ hỗ trợ API Process.getExclusiveCores để trả về số lượng lõi CPU dành riêng cho ứng dụng trên nền trước.

Nếu có hỗ trợ lõi độc quyền, thì lõi:

• [C-2-1] KHÔNG ĐƯỢC cho phép bất kỳ quy trình userspace nào khác chạy trên đó (ngoại trừ trình điều khiển thiết bị được ứng dụng sử dụng), nhưng CÓ THỂ cho phép một số quy trình nhân chạy khi cần.

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

Một số tiêu chí về hiệu suất và hiệu suất tối thiểu rất quan trọng đối với trải nghiệm người dùng và có tác động đến các giả định cơ sở mà nhà phát triển sẽ đưa ra khi phát triển một ứng dụng.

8.1. Tính nhất quán trong trải nghiệm người dùng

Một giao diện người dùng mượt mà có thể được cung cấp cho người dùng cuối nếu có một số yêu cầu tối thiểu nhất định nhằm đảm bảo tốc độ khung hình và thời gian phản hồi nhất quán cho các ứng dụng và trò chơi. Quá trình triển khai thiết bị, tuỳ thuộc vào loại thiết bị, CÓ THỂ có các yêu cầu đo lường được về độ trễ giao diện người dùng và việc chuyển đổi tác vụ như mô tả trong phần 2.

8.2. Hiệu suất truy cập tệp I/O

Việc cung cấp đường cơ sở chung để đảm bảo hiệu suất truy cập tệp nhất quán trong bộ nhớ dữ liệu riêng tư của ứng dụng (phân vùng /data) cho phép các nhà phát triển ứng dụng đặt ra một kỳ vọng đúng mức để giúp họ thiết kế phần mềm. Tuỳ thuộc vào loại thiết bị, quá trình triển khai thiết bị có thể phải đáp ứng một số yêu cầu như mô tả trong phần 2 đối với các thao tác đọc và ghi sau đây:

• Hiệu suất ghi tuần tự. Được đo bằng cách ghi một tệp 256 MB sử dụng bộ đệm ghi 10 MB.
• Hiệu suất ghi ngẫu nhiên. Được đo bằng cách ghi một tệp 256 MB sử dụng bộ đệm ghi 4KB.
• Hiệu suất đọc tuần tự. Được đo bằng cách đọc tệp 256 MB sử dụng bộ đệm ghi 10 MB.
• Hiệu suất đọc ngẫu nhiên. Được đo bằng cách đọc tệp 256 MB sử dụng bộ đệm ghi 4KB.

8.3. Chế độ tiết kiệm điện

Nếu quá trình triển khai thiết bị có các tính năng cải thiện khả năng quản lý nguồn điện thiết bị được đưa vào AOSP hoặc mở rộng các tính năng có trong AOSP, thì các tính năng đó:

• [C-1-1] KHÔNG ĐƯỢC đi chệch khỏi hoạt động triển khai AOSP cho các thuật toán kích hoạt, bảo trì, đánh thức và sử dụng cài đặt hệ thống chung của chế độ Chế độ chờ ứng dụng và chế độ tiết kiệm năng lượng Nghỉ.
• [C-1-2] KHÔNG ĐƯỢC đi chệch khỏi quy trình triển khai AOSP (Dự án nguồn mở Android) đối với việc sử dụng các chế độ cài đặt chung nhằm quản lý việc điều tiết công việc, cảnh báo và mạng cho các ứng dụng trong từng bộ chứa dành cho Chế độ chờ ứng dụng.
• [C-1-3] KHÔNG ĐƯỢC lệch khỏi quy trình triển khai AOSP đối với số Bộ chứa chế độ chờ ứng dụng được dùng cho Chế độ chờ ứng dụng.
• [C-1-4] PHẢI triển khai Bộ chứa chế độ chờ ứng dụng và Chế độ nghỉ như mô tả trong Quản lý nguồn.
• [C-1-5] PHẢI trả về true cho PowerManager.isPowerSaveMode() khi thiết bị đang ở chế độ tiết kiệm điện.
• [C-SR] Are Để cung cấp lựa chọn tương tác cho người dùng nhằm bật và tắt tính năng tiết kiệm pin.
• [C-SR] Are Để cung cấp thuộc tính tương tác cho người dùng, thì mục này hiển thị tất cả các ứng dụng được miễn trừ khỏi các chế độ tiết kiệm năng lượng ở chế độ Nghỉ và Chế độ chờ ứng dụng.

Ngoài các chế độ tiết kiệm điện, các quy trình triển khai trên thiết bị Android CÓ THỂ triển khai bất kỳ hoặc cả 4 trạng thái nguồn ngủ như được xác định trong Giao diện nguồn và cấu hình nâng cao (ACPI).

Nếu các hoạt động triển khai thiết bị triển khai các trạng thái nguồn S4 như được xác định bởi ACPI, thì các trạng thái đó:

• [C-1-1] PHẢI chuyển sang trạng thái này chỉ sau khi người dùng thực hiện một hành động rõ ràng là đặt thiết bị ở trạng thái không hoạt động (ví dụ: bằng cách đóng nắp là bộ phận thực tế của thiết bị hoặc tắt xe hoặc TV) và trước khi người dùng kích hoạt lại thiết bị (ví dụ: bằng cách mở nắp hoặc bật lại xe hoặc TV).

Nếu các hoạt động triển khai thiết bị triển khai các trạng thái nguồn S3 do ACPI xác định, thì các trạng thái đó:

• [C-2-1] PHẢI đáp ứng C-1-1 ở trên, hoặc, PHẢI nhập trạng thái S3 chỉ khi các ứng dụng của bên thứ ba không cần tài nguyên hệ thống (ví dụ: màn hình, CPU).

  Ngược lại, PHẢI thoát khỏi trạng thái S3 khi các ứng dụng của bên thứ ba cần tài nguyên hệ thống, như mô tả trên SDK này.

  Ví dụ: mặc dù các ứng dụng bên thứ ba yêu cầu luôn bật màn hình qua FLAG_KEEP_SCREEN_ON hoặc tiếp tục chạy CPU qua PARTIAL_WAKE_LOCK, nhưng thiết bị KHÔNG ĐƯỢC chuyển sang trạng thái S3 trừ phi, như được mô tả trong C-1-1, người dùng đã thực hiện hành động rõ ràng để đặt thiết bị ở trạng thái không hoạt động. Ngược lại, tại thời điểm khi một tác vụ mà các ứng dụng bên thứ ba triển khai thông qua JobScheduler được kích hoạt hoặc Firebase Cloud Messaging được gửi đến ứng dụng của bên thứ ba, thiết bị PHẢI thoát khỏi trạng thái S3 trừ phi người dùng đặt thiết bị ở trạng thái không hoạt động. Đây chưa phải là ví dụ toàn diện và AOSP triển khai các tín hiệu đánh thức rộng rãi để kích hoạt đánh thức từ trạng thái này.

8.4. Kế toán tiêu thụ điện năng

Việc tính toán và báo cáo mức tiêu thụ điện năng chính xác hơn mang lại cho nhà phát triển ứng dụng cả các ưu đãi lẫn công cụ để tối ưu hoá mẫu sử dụng điện năng của ứng dụng.

Triển khai thiết bị:

• [SR] Internet ĐỀ XUẤT NÊN cung cấp cấu hình nguồn trên mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức tiêu hao pin gần đúng do các thành phần gây ra theo thời gian như được nêu trên trang web Dự án nguồn mở Android.
• [SR] Để báo cáo tất cả các giá trị mức tiêu thụ điện năng tính bằng milliampere (mAh),
• [SR] "{NÊN DÙNG" để báo cáo mức tiêu thụ điện năng của CPU trên mỗi UID của quy trình. Dự án nguồn mở Android đáp ứng yêu cầu này thông qua việc triển khai mô-đun nhân uid_cputime.
• [SR] RENDERED NÊN DÙNG để cung cấp mức sử dụng nguồn điện này qua lệnh shell adb shell dumpsys batterystats cho nhà phát triển ứng dụng.
• NÊN được phân bổ cho chính thành phần phần cứng nếu không thể phân bổ mức sử dụng nguồn của thành phần phần cứng cho một ứng dụng.

8,5. Hiệu suất nhất quán

Hiệu suất có thể biến động đáng kể đối với các ứng dụng chạy trong thời gian dài có hiệu suất cao, do các ứng dụng khác chạy trong nền hoặc điều tiết CPU do giới hạn nhiệt độ. Android có các giao diện có lập trình để khi thiết bị có thể hoạt động, ứng dụng trên nền trước có thể yêu cầu hệ thống tối ưu hoá việc phân bổ tài nguyên nhằm giải quyết những biến động như vậy.

Triển khai thiết bị:

• [C-0-1] PHẢI báo cáo chính xác khả năng hỗ trợ Chế độ hiệu suất bền vững thông qua phương thức API PowerManager.isSustainedPerformanceModeSupported().

• NÊN hỗ trợ Chế độ hiệu suất bền vững.

Nếu quá trình triển khai thiết bị báo cáo khả năng hỗ trợ Chế độ hiệu suất bền vững, thì họ:

• [C-1-1] PHẢI cung cấp cho ứng dụng trên nền trước một mức hiệu suất nhất quán trong ít nhất 30 phút, khi ứng dụng yêu cầu.
• [C-1-2] PHẢI tuân thủ API Window.setSustainedPerformanceMode() và các API liên quan khác.

Nếu quá trình triển khai thiết bị bao gồm 2 lõi CPU trở lên, thì các lõi CPU đó:

• NÊN cung cấp ít nhất một lõi độc quyền mà ứng dụng trên nền trước trên cùng có thể dành riêng.

Nếu quá trình triển khai thiết bị hỗ trợ dành riêng một lõi độc quyền cho ứng dụng trên nền trước, thì các quá trình đó:

• [C-2-1] PHẢI báo cáo thông qua phương thức API Process.getExclusiveCores(), số nhận dạng của các lõi độc quyền có thể được ứng dụng trên nền trước đặt trước.
• [C-2-2] KHÔNG ĐƯỢC cho phép bất kỳ quy trình không gian người dùng nào ngoại trừ trình điều khiển thiết bị được ứng dụng sử dụng để chạy trên các lõi độc quyền, nhưng CÓ THỂ cho phép một số quy trình nhân chạy khi cần.

Nếu quá trình triển khai thiết bị không hỗ trợ lõi độc quyền, thì các quá trình triển khai trên thiết bị sẽ:

• [C-3-1] PHẢI trả về danh sách trống thông qua phương thức API Process.getExclusiveCores().

9. Khả năng tương thích của mô hình bảo mật

Triển khai thiết bị:

• [C-0-1] PHẢI triển khai một mô hình bảo mật nhất quán với mô hình bảo mật của nền tảng Android như định nghĩa trong tài liệu tham khảo về Bảo mật và quyền truy cập trong các API trong tài liệu dành cho nhà phát triển Android.

• [C-0-2] PHẢI hỗ trợ cài đặt ứng dụng tự ký mà không yêu cầu bất kỳ quyền/chứng chỉ bổ sung nào từ bất kỳ bên thứ ba/cơ quan nào. Cụ thể, các thiết bị tương thích PHẢI hỗ trợ cơ chế bảo mật được mô tả trong các tiểu mục sau.

9.1. Quyền

Triển khai thiết bị:

• [C-0-1] PHẢI hỗ trợ mô hình quản lý quyền của Android như nêu trong tài liệu dành cho nhà phát triển Android. Cụ thể, họ PHẢI thực thi từng quyền được xác định như mô tả trong tài liệu SDK; không có quyền nào bị bỏ qua, thay đổi hoặc bỏ qua.

• CÓ THỂ thêm các quyền khác, miễn là các chuỗi mã nhận dạng quyền mới không nằm trong không gian tên android.\*.

• [C-0-2] Các quyền có protectionLevel là PROTECTION_FLAG_PRIVILEGED PHẢI chỉ được cấp cho những ứng dụng được cài đặt trước trong(các) đường dẫn đặc quyền của hình ảnh hệ thống và trong tập hợp con các quyền rõ ràng được cho phép đối với mỗi ứng dụng. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách đọc và tuân thủ các quyền trong danh sách cho phép đối với từng ứng dụng từ các tệp trong đường dẫn etc/permissions/ và sử dụng đường dẫn system/priv-app làm đường dẫn đặc quyền.

Quyền có mức độ bảo vệ nguy hiểm là quyền khi bắt đầu chạy. Ứng dụng có targetSdkVersion > 22 và yêu cầu mã trong thời gian chạy.

Triển khai thiết bị:

• [C-0-3] PHẢI hiển thị một giao diện chuyên dụng để người dùng quyết định xem có cấp các quyền khi bắt đầu chạy được yêu cầu hay không, đồng thời cung cấp giao diện để người dùng quản lý các quyền khi bắt đầu chạy.
• [C-0-4] PHẢI có một và chỉ một cách triển khai cho cả hai giao diện người dùng.
• [C-0-5] KHÔNG ĐƯỢC cấp bất kỳ quyền khi bắt đầu chạy nào cho các ứng dụng được cài đặt trước trừ phi:
  • Ứng dụng có thể nhận được sự đồng ý của người dùng trước khi sử dụng.
  • Các quyền khi bắt đầu chạy được liên kết với mẫu ý định mà ứng dụng cài đặt trước được đặt làm trình xử lý mặc định.
• [C-0-6] Chỉ được cấp quyền android.permission.RECOVER_KEYSTORE cho những ứng dụng hệ thống đã đăng ký Tác nhân khôi phục được bảo mật đúng cách. Tác nhân khôi phục được bảo mật đúng cách được định nghĩa là một tác nhân phần mềm trên thiết bị đồng bộ hoá với bộ nhớ từ xa bên ngoài thiết bị, được trang bị phần cứng bảo mật với khả năng bảo vệ tương đương hoặc mạnh hơn những gì được mô tả trong Dịch vụ lưu trữ khoá Google Cloud nhằm ngăn chặn các cuộc tấn công brute force đối với yếu tố kiến thức màn hình khoá.

Triển khai thiết bị:

• [C-0-7] PHẢI tuân thủ các thuộc tính Quyền truy cập thông tin vị trí trên Android khi ứng dụng yêu cầu dữ liệu vị trí hoặc hoạt động thể chất thông qua API Android tiêu chuẩn hoặc cơ chế độc quyền. Những dữ liệu này bao gồm nhưng không giới hạn ở:

  • Vị trí của thiết bị (ví dụ: vĩ độ và kinh độ).
  • Thông tin có thể dùng để xác định hoặc ước tính vị trí của thiết bị (ví dụ: SSID, BSSID, Cell ID, Quét Bluetooth hoặc vị trí mạng mà thiết bị được kết nối).
  • Hoạt động thể chất của người dùng hoặc cách phân loại hoạt động thể chất.

Cụ thể hơn là việc triển khai thiết bị:

• [C-0-8] PHẢI có được sự đồng ý của người dùng để cho phép một ứng dụng truy cập vào dữ liệu vị trí hoặc hoạt động thể chất.
• [C-0-9] PHẢI cấp quyền khi bắt đầu chạy cho ứng dụng có đủ quyền như mô tả trên SDK. Ví dụ: TelephonyManager#getServiceState cần có android.permission.ACCESS_FINE_LOCATION).

Các quyền có thể được đánh dấu là bị hạn chế làm thay đổi hành vi của các quyền đó.

• [C-0-10] Các quyền được đánh dấu bằng cờ hardRestricted KHÔNG ĐƯỢC cấp cho ứng dụng trừ phi:

  • Tệp APK ứng dụng nằm trong phân vùng hệ thống.
  • Người dùng chỉ định vai trò liên kết với các quyền hardRestricted cho một ứng dụng.
  • Trình cài đặt này sẽ cấp hardRestricted cho một ứng dụng.
  • Một ứng dụng được cấp hardRestricted trên phiên bản Android cũ.

• [C-0-11] Các ứng dụng có quyền softRestricted PHẢI chỉ có quyền truy cập giới hạn và KHÔNG được có toàn quyền truy cập cho đến khi được thêm vào danh sách cho phép theo mô tả trong SDK, trong đó quyền truy cập đầy đủ và giới hạn được xác định cho từng quyền softRestricted (ví dụ: WRITE_EXTERNAL_STORAGE và READ_EXTERNAL_STORAGE).

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

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

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

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

9.2. UID và tách biệt quy trình

Triển khai thiết bị:

• [C-0-1] PHẢI hỗ trợ mô hình hộp cát của ứng dụng Android, trong đó mỗi ứng dụng chạy dưới dạng một UID Unixstyle duy nhất và trong một quy trình riêng.
• [C-0-2] PHẢI hỗ trợ chạy nhiều ứng dụng giống như cùng một mã nhận dạng người dùng Linux, miễn là các ứng dụng được ký và thiết lập đúng cách, như nêu trong tài liệu tham khảo về Bảo mật và quyền truy cập.

9.3. Quyền đối với hệ thống tệp

Triển khai thiết bị:

• [C-0-1] PHẢI hỗ trợ mô hình quản lý quyền truy cập vào tệp Android như định nghĩa trong tài liệu tham khảo về Bảo mật và quyền truy cập.

9.4. Môi trường thực thi thay thế

Quá trình triển khai thiết bị PHẢI duy trì tính nhất quán của mô hình bảo mật và quyền của Android, ngay cả khi chúng bao gồm môi trường thời gian chạy thực thi ứng dụng bằng một số phần mềm hoặc công nghệ khác ngoài Định dạng có thể thực thi Dalvik hoặc mã gốc. Hay nói cách khác:

• [C-0-1] Môi trường thời gian chạy thay thế PHẢI là các ứng dụng Android và tuân thủ mô hình bảo mật tiêu chuẩn của Android, như được mô tả ở nơi khác trong phần 9.

• [C-0-2] Môi trường thời gian chạy thay thế KHÔNG được cấp quyền truy cập vào các tài nguyên được bảo vệ bằng các quyền không được yêu cầu trong tệp AndroidManifest.xml của thời gian chạy thông qua <uses-permission> cơ chế.

• [C-0-3] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cho phép các ứng dụng sử dụng các tính năng được bảo vệ bằng các quyền của Android bị hạn chế đối với các ứng dụng hệ thống.

• [C-0-4] Môi trường thời gian chạy thay thế PHẢI tuân theo mô hình hộp cát của Android và các ứng dụng đã cài đặt bằng môi trường thời gian chạy thay thế KHÔNG ĐƯỢC sử dụng lại hộp cát của bất kỳ ứng dụng nào khác được cài đặt trên thiết bị, trừ phi thông qua cơ chế Android tiêu chuẩn của Mã nhận dạng người dùng chung và chứng chỉ ký.

• [C-0-5] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC chạy cùng, cấp hoặc được cấp quyền truy cập vào hộp cát tương ứng với các ứng dụng Android khác.

• [C-0-6] Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC chạy cùng, được cấp, hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của siêu người dùng (gốc) hoặc của bất kỳ ID người dùng nào khác.

• [C-0-7] Khi các tệp .apk của thời gian chạy thay thế được đưa vào ảnh hệ thống các cách triển khai thiết bị, PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng khác đi kèm với quá trình triển khai thiết bị.

• [C-0-8] Khi cài đặt ứng dụng, thời gian chạy thay thế PHẢI lấy sự đồng ý của người dùng đối với các quyền của Android mà ứng dụng sử dụng.

• [C-0-9] Khi một ứng dụng cần sử dụng tài nguyên thiết bị có quyền tương ứng của Android (như Camera, GPS, v.v.), thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng có thể truy cập tài nguyên đó.

• [C-0-10] Khi môi trường thời gian chạy không ghi lại các chức năng của ứng dụng theo cách này, môi trường thời gian chạy PHẢI liệt kê tất cả các quyền do chính môi trường thời gian chạy đó giữ khi cài đặt bất kỳ ứng dụng nào bằng thời gian chạy đó.

• Môi trường thời gian chạy thay thế NÊN cài đặt ứng dụng qua PackageManager vào các hộp cát Android riêng biệt (mã nhận dạng người dùng Linux, v.v.).

• Môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android duy nhất được tất cả ứng dụng dùng chung với môi trường thời gian chạy thay thế.

9,5. Hỗ trợ nhiều người dùng

Android hỗ trợ nhiều người dùng và hỗ trợ tách biệt người dùng hoàn toàn.

• Quá trình triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN bật chế độ nhiều người dùng nếu chúng sử dụng phương tiện di động cho bộ nhớ ngoài chính.

Nếu quá trình triển khai thiết bị bao gồm nhiều người dùng, họ:

• [C-1-1] PHẢI đáp ứng các yêu cầu sau liên quan đến tính năng hỗ trợ nhiều người dùng.
• [C-1-2] PHẢI, đối với từng người dùng, triển khai một mô hình bảo mật nhất quán với mô hình bảo mật nền tảng Android như xác định trong Tài liệu tham khảo về bảo mật và quyền trong các API.
• [C-1-3] PHẢI có các thư mục lưu trữ ứng dụng dùng chung (còn gọi là /sdcard) riêng biệt và tách biệt cho từng phiên bản người dùng.
• [C-1-4] PHẢI đảm bảo rằng các ứng dụng thuộc sở hữu và đang chạy thay mặt một người dùng cụ thể không thể liệt kê, đọc, hoặc ghi vào các tệp thuộc sở hữu của bất kỳ người dùng nào khác, ngay cả khi dữ liệu của cả hai người dùng được lưu trữ trên cùng một ổ đĩa hoặc hệ thống tệp.
• [C-1-5] PHẢI mã hoá nội dung của thẻ SD khi chế độ nhiều người dùng được bật bằng một khoá chỉ được lưu trữ trên phương tiện không di động chỉ có thể truy cập được vào hệ thống nếu quá trình triển khai thiết bị sử dụng phương tiện di động cho API bộ nhớ ngoài. Vì việc này sẽ làm cho máy tính lưu trữ không đọc được nội dung nghe nhìn, nên cần phải triển khai thiết bị để chuyển sang MTP hoặc một hệ thống tương tự để cung cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại.

9.6. Cảnh báo qua tin nhắn dịch vụ

Android hỗ trợ tính năng cảnh báo cho người dùng về mọi tin nhắn SMS đặc biệt gửi đi. Tin nhắn dịch vụ là những tin nhắn văn bản được gửi đến một dịch vụ đã đăng ký với nhà mạng và người dùng có thể bị tính phí.

Nếu các quá trình triển khai thiết bị khai báo dịch vụ hỗ trợ android.hardware.telephony, thì các quá trình triển khai thiết bị đó sẽ:

• [C-1-1] PHẢI cảnh báo người dùng trước khi gửi tin nhắn SMS đến các số được xác định bằng biểu thức chính quy được xác định trong tệp /data/misc/sms/codes.xml trong thiết bị. Dự án nguồn mở Android ngược dòng cung cấp một phương thức triển khai đáp ứng yêu cầu này.

9,7. Tính năng bảo mật

Việc triển khai thiết bị PHẢI đảm bảo tuân thủ các tính năng bảo mật trong cả nhân hệ điều hành lẫn nền tảng như mô tả dưới đây.

Android Sandbox bao gồm những tính năng sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) của Linux tăng cường bảo mật (SELinux), hộp cát bảo mật và các tính năng bảo mật khác trong nhân Linux. Triển khai thiết bị:

• [C-0-1] PHẢI duy trì khả năng tương thích với các ứng dụng hiện có, ngay cả khi SELinux hoặc bất kỳ tính năng bảo mật nào khác được triển khai bên dưới khung Android.
• [C-0-2] KHÔNG ĐƯỢC có giao diện người dùng hiển thị khi phát hiện vi phạm bảo mật và chặn thành công bằng tính năng bảo mật được triển khai bên dưới khung Android, nhưng CÓ THỂ có giao diện người dùng hiển thị khi xảy ra vi phạm bảo mật được bỏ chặn dẫn đến việc khai thác thành công.
• [C-0-3] KHÔNG ĐƯỢC đặt SELinux hoặc bất kỳ tính năng bảo mật nào khác được triển khai bên dưới khung Android có thể định cấu hình cho người dùng hoặc nhà phát triển ứng dụng.
• [C-0-4] KHÔNG ĐƯỢC cho phép ứng dụng có thể ảnh hưởng đến ứng dụng khác thông qua API (chẳng hạn như API Quản trị thiết bị) định cấu hình chính sách phá vỡ khả năng tương thích.
• [C-0-5] PHẢI chia khung phương tiện thành nhiều quy trình để có thể cấp quyền truy cập cho từng quy trình trong phạm vi hẹp hơn như mô tả trên trang web Dự án nguồn mở Android.
• [C-0-6] PHẢI triển khai cơ chế hộp cát ứng dụng hạt nhân cho phép lọc lệnh gọi hệ thống bằng chính sách có thể định cấu hình từ các chương trình đa luồng. Dự án nguồn mở Android ngược dòng đáp ứng yêu cầu này thông qua việc bật seccomp-BPF với tính năng đồng bộ hoá nhóm luồng (TSYNC) như mô tả trong phần Cấu hình hạt nhân của source.android.com.

Các tính năng tự bảo vệ và tính toàn vẹn của kernel là phần không thể thiếu trong hoạt động bảo mật của Android. Triển khai thiết bị:

• [C-0-7] PHẢI triển khai cơ chế bảo vệ tràn vùng đệm ngăn xếp hạt nhân. Ví dụ về những cơ chế như vậy là CC_STACKPROTECTOR_REGULAR và CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] PHẢI triển khai các biện pháp bảo vệ bộ nhớ nhân hệ điều hành nghiêm ngặt trong đó mã thực thi là chỉ đọc, dữ liệu chỉ đọc là dữ liệu không thể thực thi và không thể ghi, đồng thời dữ liệu có thể ghi là không thể thực thi (ví dụ: CONFIG_DEBUG_RODATA hoặc CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] PHẢI triển khai việc kiểm tra giới hạn kích thước đối tượng tĩnh và động đối với việc kiểm tra bản sao giữa user-space và kernel-space (ví dụ: CONFIG_HARDENED_USERCOPY) trên các thiết bị ban đầu được vận chuyển có API cấp 28 trở lên.
• [C-0-10] KHÔNG ĐƯỢC thực thi bộ nhớ không gian của người dùng khi thực thi ở chế độ nhân (ví dụ: PXN phần cứng, hoặc được mô phỏng qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị ban đầu được vận chuyển bằng API cấp 28 trở lên.
• [C-0-11] KHÔNG ĐƯỢC đọc hoặc ghi bộ nhớ không gian người dùng trong nhân bên ngoài các API truy cập người dùng thông thường (ví dụ: PAN phần cứng hoặc được mô phỏng qua CONFIG_CPU_SW_DOMAIN_PAN hoặc CONFIG_ARM64_SW_TTBR0_PAN) trên các thiết bị ban đầu được vận chuyển có API cấp 28 trở lên.
• [C-0-12] PHẢI triển khai cách ly bảng trang nhân hệ điều hành nếu phần cứng dễ gặp vấn đề về lỗ hổng CVE-2017-5754 trên mọi thiết bị ban đầu có API cấp 28 trở lên (ví dụ: CONFIG_PAGE_TABLE_ISOLATION hoặc CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] PHẢI triển khai tăng cường dự đoán nhánh nếu phần cứng dễ gặp vấn đề về CVE-2017-5715 trên tất cả các thiết bị ban đầu được vận chuyển có API cấp 28 trở lên (ví dụ: CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] linh hoạt NÊN giữ lại dữ liệu nhân chỉ được ghi trong quá trình khởi chạy được đánh dấu là chỉ đọc sau khi khởi chạy (ví dụ: __ro_after_init).

• [C-SR] Are được linh hoạt đề xuất để sắp xếp ngẫu nhiên bố cục của mã hạt nhân và bộ nhớ, đồng thời tránh để lộ thông tin có thể ảnh hưởng đến việc ngẫu nhiên (ví dụ: CONFIG_RANDOMIZE_BASE với entropy trình tải khởi động thông qua /chosen/kaslr-seed Device Tree node hoặc EFI_RNG_PROTOCOL).

• [C-SR] Are Internet ĐỀ XUẤT NÊN bật tính toàn vẹn của luồng điều khiển (CFI) trong nhân hệ điều hành để cung cấp khả năng bảo vệ bổ sung chống lại các cuộc tấn công sử dụng lại mã (ví dụ: CONFIG_CFI_CLANG và CONFIG_SHADOW_CALL_STACK).

• [C-SR] Are được linh hoạt đề xuất không để vô hiệu hoá Control-Flow Integrity (CFI), Shadow Call Stack (SCS) hoặc Integer Overflow Sanitization (IntSan) trên các thành phần đã bật tính năng này.
• [C-SR] Are Internet ĐỀ XUẤT DÙNG để bật CFI, SCS và IntSan cho mọi thành phần không gian người dùng nhạy cảm về bảo mật bổ sung như được giải thích trong CFI và IntSan.

Nếu quá trình triển khai thiết bị sử dụng nhân hệ điều hành Linux, thì các quá trình này sẽ:

• [C-1-1] PHẢI triển khai SELinux.
• [C-1-2] PHẢI đặt SELinux thành chế độ thực thi toàn cục.
• [C-1-3] PHẢI định cấu hình tất cả các miền ở chế độ thực thi. Không có miền nào ở chế độ được phép, bao gồm cả miền dành riêng cho một thiết bị/nhà cung cấp.
• [C-1-4] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc Neverallow hiện có trong thư mục system/sepolicy được cung cấp trong Dự án nguồn mở Android ngược dòng (AOSP) và chính sách PHẢI biên dịch với tất cả các quy tắc bao giờ có mặt, cho cả miền AOSP SELinux cũng như miền cụ thể của thiết bị/nhà cung cấp.
• [C-1-5] PHẢI chạy các ứng dụng của bên thứ ba nhắm đến API cấp 28 trở lên trong hộp cát SELinux cho mỗi ứng dụng với các hạn chế SELinux cho mỗi ứng dụng trên thư mục dữ liệu riêng tư của từng ứng dụng.
• NÊN giữ lại chính sách SELinux mặc định được cung cấp trong thư mục system/sepolicy của Dự án nguồn mở Android ngược dòng và chỉ thêm vào chính sách này cho cấu hình dành riêng cho thiết bị của riêng họ.

Nếu các hoạt động triển khai thiết bị đã được triển khai trên một phiên bản Android cũ hơn và không thể đáp ứng được các yêu cầu [C-1-1] và [C-1-5] thông qua bản cập nhật phần mềm hệ thống, thì các hoạt động này có thể được miễn trách nhiệm đáp ứng những yêu cầu này.

Nếu quá trình triển khai thiết bị sử dụng nhân hệ điều hành không phải Linux, thì chúng:

• [C-2-1] PHẢI sử dụng hệ thống kiểm soát truy cập bắt buộc tương đương với SELinux.

Android chứa nhiều tính năng bảo vệ chuyên sâu không thể thiếu cho hoạt động bảo mật thiết bị.

9,8. Quyền riêng tư

9.8.1. Nhật ký sử dụng

Android lưu trữ nhật ký lựa chọn của người dùng và quản lý nhật ký đó bằng UsageStatsManager.

Triển khai thiết bị:

• [C-0-1] PHẢI duy trì khoảng thời gian lưu giữ hợp lý lịch sử người dùng đó.
• [SR] Are được linh hoạt đề xuất để duy trì khoảng thời gian lưu giữ 14 ngày như được định cấu hình theo mặc định trong quá trình triển khai AOSP.

Android lưu trữ các sự kiện hệ thống bằng cách sử dụng giá trị nhận dạng StatsLog, đồng thời quản lý nhật ký đó qua StatsManager và API hệ thống IncidentManager.

Triển khai thiết bị:

• [C-0-2] PHẢI chỉ bao gồm các trường được đánh dấu bằng DEST_AUTOMATIC trong báo cáo sự cố do lớp System API IncidentManager tạo.
• [C-0-3] KHÔNG ĐƯỢC sử dụng giá trị nhận dạng sự kiện hệ thống để ghi lại bất kỳ sự kiện nào khác ngoài những gì được mô tả trong tài liệu SDK StatsLog. Nếu các sự kiện hệ thống bổ sung được ghi lại, chúng CÓ THỂ sử dụng định danh nguyên tử khác trong phạm vi từ 100.000 đến 200.000.

9.8.2. Đang ghi

Triển khai thiết bị:

• [C-0-1] KHÔNG ĐƯỢC tải trước hoặc phân phối các thành phần phần mềm có sẵn để gửi thông tin riêng tư của người dùng (ví dụ: thao tác nhấn phím, văn bản hiện trên màn hình, báo cáo lỗi) ra khỏi thiết bị khi chưa có sự đồng ý của người dùng hoặc xoá thông báo hiển thị liên tục.

• [C-0-2] PHẢI hiển thị và có được sự đồng ý rõ ràng của người dùng, bao gồm thông điệp về cơ bản giống như AOSP bất cứ khi nào tính năng truyền màn hình hoặc ghi màn hình được bật thông qua MediaProjection hoặc các API độc quyền. KHÔNG ĐƯỢC cung cấp cho người dùng một thuộc tính tương tác để tắt tính năng hiển thị sự đồng ý của người dùng trong tương lai.

• [C-0-3] PHẢI có một thông báo hiển thị liên tục cho người dùng trong khi bật tính năng truyền màn hình hoặc ghi màn hình. AOSP đáp ứng yêu cầu này bằng cách hiển thị biểu tượng thông báo liên tục trên thanh trạng thái.

Nếu việc triển khai thiết bị bao gồm chức năng trong hệ thống ghi lại nội dung hiển thị trên màn hình và/hoặc ghi lại luồng âm thanh được phát trên thiết bị không phải qua API hệ thống ContentCaptureService hoặc các phương tiện thuộc quyền sở hữu riêng khác được mô tả trong Mục 9.8.6 Thu thập nội dung, thiết bị đó phải:

• [C-1-1] PHẢI có thông báo liên tục cho người dùng bất cứ khi nào chức năng này được bật và chủ động chụp/ghi.

Nếu quá trình triển khai thiết bị bao gồm một thành phần được bật sẵn, có khả năng ghi lại âm thanh xung quanh và/hoặc ghi lại âm thanh phát trên thiết bị để suy ra thông tin hữu ích về bối cảnh của người dùng, thì các thành phần đó:

• [C-2-1] KHÔNG ĐƯỢC lưu trữ trong bộ nhớ lâu dài trên thiết bị hoặc truyền ra khỏi thiết bị âm thanh thô đã ghi hoặc bất kỳ định dạng nào có thể chuyển đổi trở lại thành âm thanh gốc hoặc gần fax, trừ phi có sự đồng ý rõ ràng của người dùng.

9.8.3. Khả năng kết nối

Nếu quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ thiết bị ngoại vi USB, thì quá trình triển khai thiết bị sẽ:

• [C-1-1] PHẢI trình bày giao diện người dùng yêu cầu sự đồng ý của người dùng trước khi cho phép truy cập vào nội dung của bộ nhớ dùng chung qua cổng USB.

9.8.4. Lưu lượng truy cập mạng

Triển khai thiết bị:

• [C-0-1] PHẢI cài đặt trước cùng một chứng chỉ gốc cho kho lưu trữ Tổ chức phát hành chứng chỉ (CA) đáng tin cậy của hệ thống như được cung cấp trong Dự án nguồn mở Android ở cấp trên.
• [C-0-2] PHẢI gửi cùng một kho lưu trữ CA gốc của người dùng trống.
• [C-0-3] PHẢI hiển thị cảnh báo cho người dùng cho biết lưu lượng truy cập mạng có thể được giám sát khi CA gốc của người dùng được thêm vào.

Nếu lưu lượng truy cập thiết bị được định tuyến thông qua VPN, việc triển khai thiết bị:

• [C-1-1] PHẢI hiển thị cảnh báo cho người dùng cho biết:
  • Lưu lượng truy cập mạng đó có thể được giám sát.
  • Lưu lượng truy cập mạng đó đang được định tuyến thông qua ứng dụng VPN cụ thể cung cấp VPN.

Nếu quá trình triển khai thiết bị có cơ chế được bật sẵn theo mặc định, sẽ định tuyến lưu lượng truy cập dữ liệu mạng thông qua máy chủ proxy hoặc cổng VPN (ví dụ: tải trước dịch vụ VPN bằng android.permission.CONTROL_VPN đã được cấp), thì chúng:

• [C-2-1] PHẢI yêu cầu người dùng đồng ý trước khi bật cơ chế đó, trừ phi VPN được Trình kiểm soát chính sách thiết bị bật thông qua DevicePolicyManager.setAlwaysOnVpnPackage(). Trong trường hợp đó, người dùng không cần đưa ra sự đồng ý riêng mà chỉ ĐƯỢC thông báo.

Nếu các hoạt động triển khai thiết bị triển khai một thuộc tính tương tác của người dùng để bật/tắt "VPN luôn bật" của ứng dụng VPN của bên thứ ba, chúng:

• [C-3-1] PHẢI tắt thuộc tính tương tác người dùng này cho các ứng dụng không hỗ trợ dịch vụ VPN luôn bật trong tệp AndroidManifest.xml thông qua việc đặt thuộc tính SERVICE_META_DATA_SUPPORTS_ALWAYS_ON thành false.

9.8.5. Thông tin nhận dạng thiết bị

Triển khai thiết bị:

• [C-0-1] PHẢI ngăn chặn quyền truy cập vào số sê-ri của thiết bị và IMEI/MEID, số sê-ri của SIM và Mã nhận dạng người đăng ký di động quốc tế (IMSI) (nếu có), trừ phi ứng dụng đó đáp ứng một trong những yêu cầu sau:
  • là một ứng dụng của nhà mạng đã ký mà nhà sản xuất thiết bị đã xác minh.
  • đã được cấp quyền READ_PRIVILEGED_PHONE_STATE.
  • có đặc quyền của nhà mạng như xác định trong phần UICC nhà cung cấp đặc quyền.
  • là chủ sở hữu thiết bị hoặc chủ sở hữu hồ sơ đã được cấp quyền READ_PHONE_STATE.
  • (Chỉ đối với số sê-ri của SIM/ICCID) có yêu cầu theo quy định của địa phương về việc ứng dụng phát hiện thay đổi trong danh tính của người đăng ký.

9.8.6. Ghi nội dung

Android, thông qua API hệ thống ContentCaptureService hoặc bằng các phương thức độc quyền khác, hỗ trợ cơ chế triển khai thiết bị để thu thập các hoạt động tương tác sau đây giữa ứng dụng và người dùng.

• Văn bản và hình ảnh hiển thị trên màn hình, bao gồm nhưng không giới hạn ở thông báo và dữ liệu hỗ trợ qua API AssistStructure.
• Dữ liệu nội dung nghe nhìn, chẳng hạn như âm thanh hoặc video, mà thiết bị ghi lại hoặc phát.
• Sự kiện nhập (ví dụ: phím, chuột, cử chỉ, giọng nói, video và hỗ trợ tiếp cận).
• Mọi sự kiện khác mà ứng dụng cung cấp cho hệ thống thông qua API Content Capture hoặc một API độc quyền có khả năng tương tự.

Nếu các hoạt động triển khai thiết bị thu thập được dữ liệu ở trên, chúng:

• [C-1-1] PHẢI mã hoá tất cả những dữ liệu đó khi được lưu trữ trong thiết bị. Bạn CÓ THỂ thực hiện quá trình mã hoá này bằng tính năng Mã hoá dựa trên tệp của Android hoặc bất kỳ thuật toán mật mã nào được liệt kê dưới dạng API phiên bản 26 trở lên theo mô tả trong SDK mật mã.
• [C-1-2] KHÔNG ĐƯỢC sao lưu dữ liệu thô hoặc đã mã hoá bằng phương thức sao lưu của Android hoặc bất kỳ phương thức sao lưu nào khác.
• [C-1-3] KHÔNG ĐƯỢC gửi tất cả những dữ liệu này và nhật ký của thiết bị bằng cơ chế bảo đảm quyền riêng tư. Cơ chế bảo đảm quyền riêng tư được định nghĩa là "cơ chế chỉ cho phép phân tích ở dạng tổng hợp và ngăn chặn việc so khớp các sự kiện đã ghi lại hoặc kết quả phát sinh với người dùng cá nhân", để ngăn việc dữ liệu của mỗi người dùng bị xâm nhập (ví dụ: được triển khai bằng một công nghệ sự riêng tư biệt lập như RAPPOR).
• [C-1-4] KHÔNG ĐƯỢC liên kết dữ liệu đó với bất kỳ danh tính nào của người dùng (chẳng hạn như Account) trên thiết bị, trừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được liên kết.
• [C-1-5] KHÔNG ĐƯỢC chia sẻ những dữ liệu đó với các ứng dụng khác, trừ phi có sự đồng ý rõ ràng của người dùng mỗi khi dữ liệu được chia sẻ.
• [C-1-6] PHẢI cung cấp cho người dùng thuộc tính tương tác để xoá dữ liệu mà ContentCaptureService hoặc phương tiện thuộc quyền sở hữu riêng thu thập nếu dữ liệu được lưu trữ dưới bất kỳ dạng nào trên thiết bị.

Nếu hoạt động triển khai thiết bị bao gồm một dịch vụ triển khai API hệ thống ContentCaptureService hoặc bất kỳ dịch vụ độc quyền nào thu thập dữ liệu như mô tả ở trên, thì các dịch vụ đó:

• [C-2-1] KHÔNG ĐƯỢC cho phép người dùng thay thế dịch vụ chụp nội dung bằng một ứng dụng hoặc dịch vụ có thể cài đặt do người dùng cài đặt và PHẢI chỉ cho phép dịch vụ được cài đặt trước thu thập dữ liệu đó.
• [C-2-2] KHÔNG ĐƯỢC cho phép bất kỳ ứng dụng nào khác ngoài cơ chế dịch vụ thu thập nội dung được cài đặt trước có thể thu thập dữ liệu như vậy.
• [C-2-3] PHẢI cung cấp thuộc tính tương tác của người dùng để tắt dịch vụ ghi lại nội dung.
• [C-2-4] KHÔNG ĐƯỢC bỏ qua thuộc tính tương tác của người dùng để quản lý các quyền của Android do dịch vụ ghi lại nội dung nắm giữ và tuân theo mô hình quản lý quyền của Android như mô tả trong Phần 9.1. Quyền.

• [C-SR] Are Always NÊN làm riêng biệt các thành phần dịch vụ ghi lại nội dung, ví dụ: không ràng buộc mã nhận dạng quá trình chia sẻ hoặc dịch vụ, với các thành phần hệ thống khác, ngoại trừ những trường hợp sau:

  • Điện thoại, Danh bạ, Giao diện người dùng hệ thống và Nội dung nghe nhìn

9.8.7. Truy cập vào bảng nhớ tạm

Triển khai thiết bị:

• [C-0-1] KHÔNG ĐƯỢC trả về dữ liệu đã cắt trên bảng nhớ tạm (ví dụ: qua API ClipboardManager) trừ phi ứng dụng là IME mặc định hoặc là ứng dụng hiện có tiêu điểm.

9.8.8. Vị trí

Triển khai thiết bị:

• [C-0-1] KHÔNG ĐƯỢC bật/tắt chế độ cài đặt vị trí thiết bị và chế độ quét tìm Wi-Fi/Bluetooth khi chưa có sự đồng ý rõ ràng của người dùng hoặc thông tin của người dùng.
• [C-0-2] PHẢI cung cấp cho người dùng khả năng truy cập thông tin liên quan đến vị trí, bao gồm cả các yêu cầu vị trí gần đây, quyền ở cấp ứng dụng và việc sử dụng tính năng quét tìm Wi-Fi/Bluetooth để xác định vị trí.
• [C-0-3] PHẢI đảm bảo rằng ứng dụng sử dụng API Bỏ qua vị trí khẩn cấp [LocationRequest.setLocationSettingsIgnored()] là phiên khẩn cấp do người dùng khởi tạo (ví dụ: quay số 911 hoặc nhắn tin đến 911).
• [C-0-4] PHẢI duy trì khả năng bỏ qua chế độ cài đặt vị trí của thiết bị mà không cần thay đổi chế độ cài đặt của API Bỏ qua vị trí khẩn cấp.
• [C-0-5] PHẢI lên lịch cho một thông báo nhắc người dùng sau khi một ứng dụng ở chế độ nền truy cập vào thông tin vị trí của họ bằng quyền [ACCESS_BACKGROUND_LOCATION].

9,9. Mã hoá bộ nhớ dữ liệu

Mọi thiết bị PHẢI đáp ứng các yêu cầu của mục 9.9.1. Các thiết bị khởi chạy ở một cấp độ API sớm hơn cấp độ của tài liệu này được miễn tuân theo các yêu cầu của mục 9.9.2 và 9.9.3; thay vào đó, thiết bị PHẢI đáp ứng các yêu cầu trong mục 9.9 của tài liệu Định nghĩa về khả năng tương thích với Android tương ứng với cấp độ API mà thiết bị được khởi chạy.

9.9.1. Khởi động trực tiếp

Triển khai thiết bị:

• [C-0-1] PHẢI triển khai các API Direct Boot mode (Chế độ khởi động trực tiếp) ngay cả khi chúng không hỗ trợ Storage encryption (Mã hoá bộ nhớ).

• [C-0-2] Các Ý định ACTION_LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED vẫn PHẢI được truyền đi để báo hiệu cho các ứng dụng nhận biết Khởi động trực tiếp rằng vị trí lưu trữ Đã mã hoá thiết bị (DE) và Thông tin xác thực được mã hoá (CE) có sẵn cho người dùng.

9.9.2. Yêu cầu về mã hoá

Triển khai thiết bị:

• [C-0-1] PHẢI mã hoá dữ liệu riêng tư của ứng dụng (phân vùng /data) cũng như phân vùng bộ nhớ dùng chung của ứng dụng (phân vùng /sdcard) nếu đó là phần cố định, không thể tháo rời của thiết bị.
• [C-0-2] PHẢI bật chế độ mã hoá dung lượng lưu trữ dữ liệu theo mặc định tại thời điểm người dùng hoàn tất quá trình thiết lập.
• [C-0-3] PHẢI đáp ứng yêu cầu mã hoá lưu trữ dữ liệu nêu trên thông qua việc triển khai công cụ Mã hoá dựa trên tệp (FBE).

9.9.3. Mã hoá dựa trên tệp

Thiết bị đã mã hoá:

• [C-1-1] PHẢI khởi động mà không yêu cầu người dùng cung cấp thông tin đăng nhập và cho phép các ứng dụng nhận biết Khởi động trực tiếp truy cập vào bộ nhớ được mã hoá của thiết bị (DE) sau khi thông báo ACTION_LOCKED_BOOT_COMPLETED được phát đi.
• [C-1-2] PHẢI chỉ cho phép truy cập vào bộ nhớ Đã mã hoá thông tin xác thực (CE) sau khi người dùng mở khoá thiết bị bằng cách cung cấp thông tin đăng nhập (ví dụ: mật mã, mã PIN, hình mở khoá hoặc vân tay) và thông báo ACTION_USER_UNLOCKED được phát đi.
• [C-1-3] KHÔNG ĐƯỢC cung cấp bất kỳ phương thức nào để mở khoá bộ nhớ được bảo vệ theo tiêu chuẩn CE mà không có thông tin xác thực do người dùng cung cấp hoặc khoá ký quỹ đã đăng ký.
• [C-1-4] PHẢI sử dụng tính năng Xác minh quy trình khởi động và đảm bảo rằng các khoá DE được liên kết theo cách mã hoá với gốc tin cậy phần cứng của thiết bị.
• [C-1-5] PHẢI mã hoá nội dung tệp bằng AES-256-XTS hoặc Adiantum. AES-256-XTS là Tiêu chuẩn mã hóa tiên tiến với độ dài khoá mật mã 256 bit, vận hành ở chế độ XTS; có độ dài toàn khoá là 512 bit. Adiantum đề cập đến Adiantum-XChaCha12-AES, như được nêu tại https://github.com/google/adiantum.
• [C-1-6] PHẢI mã hoá tên tệp bằng AES-256-CBC-CTS hoặc Adiantum.

• [C-1-12] PHẢI sử dụng AES-256-XTS cho nội dung tệp và AES-256-CBC-CTS cho tên tệp (thay vì Adiantum) nếu thiết bị có hướng dẫn Tiêu chuẩn mã hóa nâng cao (AES). Hướng dẫn AES là Tiện ích mã hoá ARMv8 trên thiết bị dựa trên ARM hoặc AES-NI trên các thiết bị dựa trên x86. Nếu không có hướng dẫn AES, thì thiết bị CÓ THỂ sử dụng Adiantum.

• Các khoá bảo vệ khu vực lưu trữ CE và DE:

• [C-1-7] PHẢI được liên kết bằng mật mã với Kho khoá dựa trên phần cứng.

• [C-1-8] Các khoá CE PHẢI được liên kết với thông tin đăng nhập màn hình khoá của người dùng.
• [C-1-9] Các khoá CE PHẢI được liên kết với một mật mã mặc định khi người dùng chưa chỉ định thông tin đăng nhập màn hình khoá.
• [C-1-10] PHẢI là duy nhất và khác biệt, nói cách khác, không có khoá CE hoặc DE của người dùng nào khớp với bất kỳ khoá CE hoặc DE nào của người dùng khác.
• [C-1-11] PHẢI sử dụng các thuật toán mật mã, độ dài khoá và chế độ được hỗ trợ bắt buộc.

• [C-SR] Are được linh hoạt đề xuất để mã hoá siêu dữ liệu của hệ thống tệp, chẳng hạn như các kích thước tệp, quyền sở hữu, chế độ và các thuộc tính mở rộng (xattrs), với một khoá được liên kết theo cách mã hoá với gốc phần cứng của thiết bị trong độ tin cậy.

• NÊN làm cho các ứng dụng thiết yếu được cài đặt trước (ví dụ: Alarm, Phone, Messenger) có thể nhận biết tính năng Khởi động trực tiếp.

Dự án Nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên của tính năng này dựa trên nhân hệ điều hành Linux "fscrypt" tính năng mã hoá.

9,10. Tính toàn vẹn của thiết bị

Các yêu cầu sau đây giúp đảm bảo tính minh bạch của trạng thái về tính toàn vẹn của thiết bị. Triển khai thiết bị:

• [C-0-1] PHẢI báo cáo chính xác thông qua phương thức API hệ thống PersistentDataBlockManager.getFlashLockState() xem trạng thái trình tải khởi động của họ có cho phép cài đặt ROM hình ảnh hệ thống hay không. Trạng thái FLASH_LOCK_UNKNOWN dành riêng cho các quá trình triển khai thiết bị nâng cấp từ phiên bản Android cũ khi không có phương thức API hệ thống mới này.

• [C-0-2] PHẢI hỗ trợ Xác minh quy trình khởi động cho tính toàn vẹn của thiết bị.

Nếu đã khởi chạy các quá trình triển khai thiết bị mà không hỗ trợ tính năng Xác minh quy trình khởi động trên một phiên bản Android cũ, đồng thời không thể thêm tính năng hỗ trợ cho tính năng này bằng một bản cập nhật phần mềm hệ thống, thì các hoạt động này CÓ thể được miễn trách nhiệm đáp ứng yêu cầu này.

Xác minh quy trình khởi động là một tính năng đảm bảo tính toàn vẹn của phần mềm thiết bị. Nếu các quá trình triển khai theo thiết bị có hỗ trợ tính năng này, thì họ:

• [C-1-1] PHẢI khai báo cờ tính năng nền tảng android.software.verified_boot.
• [C-1-2] PHẢI thực hiện xác minh trên mọi trình tự khởi động.
• [C-1-3] PHẢI bắt đầu xác minh từ một khóa phần cứng không thể thay đổi là gốc của sự tin cậy và đi lên đến phân vùng hệ thống.
• [C-1-4] PHẢI triển khai từng giai đoạn xác minh để kiểm tra tính toàn vẹn và tính xác thực của tất cả các byte trong giai đoạn tiếp theo trước khi thực thi mã trong giai đoạn tiếp theo.
• [C-1-5] PHẢI sử dụng thuật toán xác minh mạnh như khuyến nghị hiện tại của NIST cho thuật toán băm (SHA-256) và kích thước khoá công khai (RSA-2048).
• [C-1-6] KHÔNG ĐƯỢC cho phép hoàn tất quá trình khởi động khi xác minh hệ thống không thành công, trừ khi người dùng đồng ý thử khởi động lại. Trong trường hợp đó, bạn KHÔNG ĐƯỢC sử dụng dữ liệu từ bất kỳ khối bộ nhớ chưa được xác minh nào.
• [C-1-7] KHÔNG ĐƯỢC cho phép sửa đổi các phân vùng đã xác minh trên thiết bị trừ khi người dùng đã mở khoá trình tải khởi động một cách rõ ràng.
• [C-SR] Nếu có nhiều chip rời rạc trong thiết bị (ví dụ: radio, bộ xử lý hình ảnh chuyên dụng), thì quá trình khởi động của từng chip đó sẽ được liệt kê rộng rãi để xác minh mọi giai đoạn khi khởi động.
• [C-1-8] PHẢI sử dụng bộ nhớ bằng chứng giả mạo: để lưu trữ xem trình tải khởi động đã được mở khóa hay chưa. Bộ nhớ phát hiện giả mạo có nghĩa là trình tải khởi động có thể phát hiện xem bộ nhớ có bị can thiệp từ bên trong Android hay không.
• [C-1-9] PHẢI nhắc người dùng trong khi sử dụng thiết bị và yêu cầu xác nhận vật lý trước khi cho phép chuyển đổi từ chế độ khoá của trình tải khởi động sang chế độ mở khoá của trình tải khởi động.
• [C-1-10] PHẢI triển khai chức năng bảo vệ khôi phục cho các phân vùng được Android sử dụng (ví dụ: khởi động, phân vùng hệ thống) và sử dụng bộ nhớ phát hiện giả mạo để lưu trữ siêu dữ liệu dùng để xác định phiên bản hệ điều hành tối thiểu được phép.
• [C-SR] Are{/7} ĐỀ XUẤT để xác minh tất cả các tệp APK ứng dụng đặc quyền với một chuỗi tin cậy đã bắt nguồn từ các phân vùng được bảo vệ bằng tính năng Xác minh quy trình khởi động.
• [C-SR] AreĐể xác minh mọi cấu phần phần mềm có thể thực thi được tải bởi một ứng dụng đặc quyền từ bên ngoài tệp APK của ứng dụng đó (chẳng hạn như mã được tải động hoặc mã đã biên dịch) trước khi thực thi các cấu phần phần mềm đó hoặc tôi KHÔNG NÊN thực thi các cấu phần phần mềm đó.
• NÊN triển khai chức năng bảo vệ khôi phục cho mọi thành phần có chương trình cơ sở ổn định (ví dụ: modem, máy ảnh) và NÊN sử dụng bộ nhớ phát hiện can thiệp để lưu trữ siêu dữ liệu dùng để xác định phiên bản tối thiểu được phép.

Nếu đã triển khai thiết bị mà không hỗ trợ C-1-8 đến C-1-10 trên phiên bản Android cũ hơn và không thể thêm hỗ trợ cho các yêu cầu này bằng bản cập nhật phần mềm hệ thống, chúng CÓ THỂ được miễn yêu cầu.

Dự án nguồn mở Android ngược dòng cung cấp phương thức triển khai ưu tiên của tính năng này trong kho lưu trữ external/avb/. Kho lưu trữ này có thể tích hợp vào trình tải khởi động dùng để tải Android.

Triển khai thiết bị:

• [C-R] NÊN hỗ trợ API Xác nhận bảo vệ của Android.

Nếu các hoạt động triển khai thiết bị hỗ trợ API Xác nhận bảo vệ của Android, thì các hoạt động triển khai đó:

• [C-3-1] PHẢI báo cáo true cho API ConfirmationPrompt.isSupported().

• [C-3-2] PHẢI đảm bảo rằng mã đang chạy trong hệ điều hành Android, bao gồm cả kernel, độc hại hoặc cách khác, không thể tạo ra phản hồi tích cực nếu không có sự tương tác của người dùng.

• [C-3-3] PHẢI đảm bảo rằng người dùng có thể xem xét và phê duyệt thông báo được nhắc ngay cả trong trường hợp hệ điều hành Android, bao gồm cả nhân hệ điều hành, bị xâm phạm.

9,11. Khoá và thông tin đăng nhập

Hệ thống kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ các khoá mã hoá trong một vùng chứa và sử dụng các khoá đó trong các hoạt động mã hoá thông qua KeyChain API hoặc API Kho khoá. Triển khai thiết bị:

• [C-0-1] PHẢI cho phép nhập hoặc tạo ít nhất 8.192 khoá.
• [C-0-2] Xác thực màn hình khóa PHẢI nỗ lực giới hạn tỷ lệ và PHẢI có thuật toán thời gian đợi luỹ thừa. Sau hơn 150 lần thử không thành công, thời gian chờ PHẢI tối thiểu là 24 giờ cho mỗi lần thử.
• Không được giới hạn số lượng khoá có thể tạo

Khi quá trình triển khai thiết bị hỗ trợ màn hình khoá bảo mật, quá trình triển khai sẽ:

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

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

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

9.11.1. Màn hình khoá bảo mật và quy trình xác thực

Việc triển khai AOSP tuân theo mô hình xác thực theo cấp độ, trong đó phương thức xác thực chính dựa trên kho tri thức có thể được hỗ trợ bằng phương thức sinh trắc học thứ cấp mạnh hoặc bằng phương thức cấp ba yếu hơn.

Triển khai thiết bị:

• [C-SR] Are Để chỉ định một trong các phương thức xác thực chính, bạn chỉ nên đặt một trong các phương thức sau:
  • Mã PIN dạng số
  • Mật khẩu bao gồm chữ và số
  • Mẫu vuốt trên một lưới gồm chính xác 3x3 chấm

Xin lưu ý rằng các phương thức xác thực ở trên được gọi là phương thức xác thực chính được đề xuất trong tài liệu này.

Nếu các hoạt động triển khai thiết bị thêm hoặc sửa đổi phương thức xác thực chính được đề xuất và sử dụng một phương thức xác thực mới làm cách an toàn để khoá màn hình, thì phương thức xác thực mới:

• [C-2-1] PHẢI là phương thức xác thực người dùng như mô tả trong Requiring User Authentication For Key Use (Yêu cầu xác thực người dùng để sử dụng khoá).
• [C-2-2] PHẢI mở khoá tất cả các khoá để ứng dụng của nhà phát triển bên thứ ba sử dụng khi người dùng mở khoá màn hình khoá an toàn. Ví dụ: tất cả khoá PHẢI có sẵn cho ứng dụng của nhà phát triển bên thứ ba thông qua các API có liên quan, chẳng hạn như createConfirmDeviceCredentialIntent và setUserAuthenticationRequired.

Nếu các quá trình triển khai thiết bị thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khoá (dựa trên khoá bí mật đã biết) và sử dụng một phương thức xác thực mới để khoá màn hình, hãy làm như sau:

• [C-3-1] Entropy của độ dài ngắn nhất được phép của đầu vào PHẢI lớn hơn 10 bit.
• [C-3-2] Entropy tối đa của tất cả đầu vào có thể PHẢI lớn hơn 18 bit.
• [C-3-3] Phương thức xác thực mới KHÔNG ĐƯỢC thay thế bất kỳ phương thức xác thực chính nào được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) được triển khai và cung cấp trong AOSP.
• [C-3-4] Phương thức xác thực mới PHẢI được tắt khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_SOMETHING.
• [C-3-5] Các phương pháp xác thực mới PHẢI quay lại 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) mỗi 72 giờ một lần hoặc ít hơn HOẶC thông báo rõ ràng cho người dùng rằng một số dữ liệu sẽ không được sao lưu để bảo vệ tính riêng tư cho dữ liệu của họ.

Nếu các quá trình triển khai thiết bị thêm hoặc sửa đổi phương thức xác thực chính được đề xuất để mở khoá màn hình khoá và sử dụng một phương thức xác thực mới dựa trên hệ thống nhận dạng sinh trắc học được coi là một cách an toàn để khoá màn hình, thì phương thức mới:

• [C-4-1] PHẢI đáp ứng tất cả các yêu cầu được mô tả trong mục 7.3.10 để Tiện lợi.
• [C-4-2] PHẢI có cơ chế dự phòng để sử dụng một trong những phương thức xác thực chính được đề xuất dựa trên một bí mật đã biết.
• [C-4-3] PHẢI tắt và chỉ cho phép phương thức xác thực chính được đề xuất để mở khoá màn hình khi ứng dụng Trình điều khiển chính sách thiết bị (DPC) đã thiết lập chính sách về tính năng bảo vệ bàn phím bằng cách gọi phương thức DevicePolicyManager.setKeyguardDisabledFeatures(), với bất kỳ cờ sinh trắc học nào đi kèm (ví dụ: KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE hoặc KEYGUARD_DISABLE_IRIS).

Nếu các phương pháp xác thực bằng sinh trắc học không đáp ứng yêu cầu về mức Mạnh như mô tả trong mục 7.3.10:

• [C-5-1] Các phương thức PHẢI bị tắt nếu ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Người dùng PHẢI được kiểm tra 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 khoảng thời gian chờ 4 giờ bất kỳ ở trạng thái rảnh. Khoảng thời gian chờ ở trạng thái không hoạt động sẽ được đặt lại sau khi xác nhận thành công thông tin đăng nhập thiết bị.
• [C-5-3] Các phương thức KHÔNG ĐƯỢC coi là màn hình khoá an toàn, và PHẢI đáp ứng các yêu cầu bắt đầu bằng C-8 trong phần dưới đây.

Nếu các hoạt động triển khai thiết bị thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khoá và phương pháp xác thực mới dựa trên mã thông báo vật lý hoặc vị trí:

• [C-6-1] Chúng PHẢI có cơ chế dự phòng để sử dụng một trong những phương thức xác thực chính được khuyến nghị, dựa trên bí mật đã biết và đáp ứng các yêu cầu để được coi là màn hình khoá an toàn.
• [C-6-2] Phương thức mới PHẢI được tắt và chỉ cho phép một trong các phương thức xác thực chính được đề xuất để mở khoá màn hình khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách bằng phương thức DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) hoặc phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] Người dùng PHẢI được kiểm tra 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) ít nhất 4 giờ một lần.
• [C-6-4] Phương thức mới KHÔNG ĐƯỢC coi là màn hình khoá an toàn và PHẢI tuân theo những ràng buộc được liệt kê trong C-8 dưới đây.

Nếu 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ẽ:

• [C-7-1] PHẢI có chỉ báo rõ ràng trong trình đơn cài đặt và trên màn hình khóa khi việc khóa thiết bị bị trì hoãn hoặc có thể được mở khóa bởi(các) tác nhân tin cậy. Ví dụ: AOSP đáp ứng yêu cầu này bằng cách hiển thị nội dung mô tả bằng văn bản cho "Chế độ cài đặt tự động khoá" và "Nút nguồn khoá tức thì" trong trình đơn cài đặt và một biểu tượng dễ phân biệt trên màn hình khoá.
• [C-7-2] PHẢI tôn trọng và triển khai đầy đủ tất cả API tác nhân tin cậy trong lớp DevicePolicyManager, chẳng hạn như hằng số KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] KHÔNG ĐƯỢC triển khai đầy đủ chức năng TrustAgentService.addEscrowToken() trên thiết bị dùng làm thiết bị cá nhân chính (ví dụ: thiết bị cầm tay) nhưng CÓ THỂ triển khai đầy đủ chức năng này trên các phương thức triển khai thiết bị thường được dùng chung (ví dụ: Android TV hoặc thiết bị Automotive).
• [C-7-4] PHẢI mã hoá tất cả mã thông báo đã lưu trữ do TrustAgentService.addEscrowToken() thêm vào.
• [C-7-5] KHÔNG ĐƯỢC lưu trữ khoá mã hoá hoặc mã thông báo uỷ thác trên cùng một thiết bị sử dụng khoá. Ví dụ: Google chấp nhận khoá được lưu trữ trên điện thoại để mở khoá tài khoản người dùng trên TV.
• [C-7-6] PHẢI thông báo cho người dùng về các hệ quả bảo mật trước khi bật mã thông báo uỷ thác để giải mã bộ nhớ dữ liệu.
• [C-7-7] PHẢI có cơ chế dự phòng để sử dụng một trong những phương thức xác thực chính được đề xuất.
• [C-7-8] Người dùng PHẢI được kiểm tra bằng một trong những phương pháp xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất 72 giờ một lần hoặc ít hơn trừ phi họ quan tâm đến sự an toàn của người dùng (ví dụ như sự mất tập trung của người lái xe).
• [C-7-9] Người dùng PHẢI được kiểm tra bằng một trong những phương pháp xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) sau khoảng thời gian chờ 4 giờ bất kỳ ở trạng thái rảnh, trừ phi họ quan tâm đến sự an toàn của người dùng (ví dụ như mất tập trung của người lái xe). Khoảng thời gian chờ ở trạng thái không hoạt động sẽ được đặt lại sau khi xác nhận thành công thông tin đăng nhập thiết bị.
• [C-7-10] KHÔNG ĐƯỢC coi là màn hình khoá an toàn và PHẢI tuân theo những ràng buộc được liệt kê trong C-8 dưới đây.
• [C-7-11] KHÔNG ĐƯỢC cho phép TrustAgents trên các thiết bị cá nhân chính (ví dụ: thiết bị cầm tay) mở khoá thiết bị và chỉ có thể sử dụng các thiết bị này để giữ thiết bị đã mở khoá ở trạng thái đã mở khoá trong tối đa 4 giờ. Phương thức triển khai mặc định của TrustManagerService trong AOSP đáp ứng yêu cầu này.
• [C-7-12] PHẢI sử dụng một kênh truyền thông bảo mật bằng mật mã (ví dụ UKEY2) để truyền mã ủy thác từ thiết bị lưu trữ đến thiết bị đích.

Nếu quá trình triển khai thiết bị sẽ thêm hoặc sửa đổi phương thức xác thực để mở khóa màn hình khóa không phải là màn hình khóa an toàn như mô tả ở trên và sử dụng phương pháp xác thực mới để mở khóa tính năng bảo vệ bàn phím:

• [C-8-1] Phương thức mới PHẢI được tắt khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] Họ KHÔNG ĐƯỢC đặt lại đồng hồ hẹn giờ hết hạn mật khẩu do DevicePolicyManager.setPasswordExpirationTimeout() đặt.
• [C-8-3] Các ứng dụng KHÔNG ĐƯỢC hiển thị API cho các ứng dụng bên thứ ba để thay đổi trạng thái khoá.

9.11.2. StrongBox

Hệ thống kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ các khoá mã hoá trong một bộ xử lý bảo mật chuyên dụng cũng như môi trường thực thi riêng biệt được mô tả ở trên. Một bộ xử lý bảo mật chuyên dụng như vậy được gọi là "StrongBox". Các yêu cầu từ C-1-3 đến C-1-11 dưới đây xác định các yêu cầu mà một thiết bị PHẢI đáp ứng để đủ điều kiện là StrongBox.

Triển khai thiết bị có bộ xử lý bảo mật chuyên dụng:

• [C-SR] Đang được ĐỀ XUẤT NÊN hỗ trợ StrongBox. StrongBox có thể sẽ trở thành một yêu cầu đối với bản phát hành sau này.

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

• [C-1-1] PHẢI khai báo FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] PHẢI cung cấp phần cứng bảo mật chuyên dụng dùng để quay lại kho khoá và bảo mật quy trình xác thực người dùng. Phần cứng bảo mật chuyên dụng cũng có thể dùng cho các mục đích khác.

• [C-1-3] PHẢI có một CPU rời không dùng chung bộ nhớ đệm, DRAM, bộ đồng xử lý hoặc các tài nguyên lõi khác với bộ xử lý ứng dụng (AP).

• [C-1-4] PHẢI đảm bảo rằng bất kỳ thiết bị ngoại vi nào được chia sẻ với AP không thể thay đổi quá trình xử lý StrongBox theo bất kỳ cách nào hoặc lấy bất kỳ thông tin nào từ StrongBox. AP CÓ THỂ vô hiệu hoá hoặc chặn quyền truy cập vào StrongBox.

• [C-1-5] PHẢI có đồng hồ bên trong với độ chính xác hợp lý (+-10%) miễn nhiễm với thao tác của AP.

• [C-1-6] PHẢI có một trình tạo số ngẫu nhiên thực sự tạo ra đầu ra được phân phối đồng nhất và khó đoán.

• [C-1-7] PHẢI có khả năng chống can thiệp, bao gồm khả năng chống xâm nhập vật lý và nhiễu.

• [C-1-8] PHẢI có điện trở kênh phụ, bao gồm điện trở chống rò rỉ thông tin qua nguồn, thời gian, bức xạ điện từ và các kênh bên bức xạ nhiệt.

• [C-1-9] PHẢI có bộ nhớ an toàn để đảm bảo tính bí mật, tính toàn vẹn, tính xác thực, tính nhất quán và độ mới của nội dung. Không được đọc hoặc thay đổi bộ nhớ, trừ phi được các API StrongBox cho phép.

• Để xác thực việc tuân thủ [C-1-3] đến [C-1-9], việc triển khai thiết bị:

  • [C-1-10] PHẢI bao gồm phần cứng được chứng nhận theo Hồ sơ bảo vệ IC bảo mật BSI-CC-PP-0084-2014 hoặc được đánh giá bởi một phòng thử nghiệm được công nhận quốc gia kết hợp với việc đánh giá lỗ hổng bảo mật có khả năng tấn công cao theo Tiêu chí chung áp dụng tiềm năng tấn công vào thẻ thông minh.
  • [C-1-11] PHẢI bao gồm chương trình cơ sở được đánh giá bởi một phòng thử nghiệm được công nhận quốc gia, kết hợp với việc đánh giá lỗ hổng bảo mật có khả năng tấn công ở mức cao theo Tiêu chí chung áp dụng của tiềm năng tấn công vào thẻ thông minh.
  • [C-SR] Are được linh hoạt đề xuất để bao gồm phần cứng được đánh giá bằng cách sử dụng một mục tiêu bảo mật, đánh giá Assurance Level (EAL) 5, tăng cường bởi AVA_VAN.5. Chứng chỉ EAL 5 có thể sẽ trở thành một yêu cầu bắt buộc trong bản phát hành sau này.

• [C-SR] đượcPhải NÊN cung cấp khả năng chống tấn công nội bộ (IAR), nghĩa là người trong cuộc có quyền truy cập vào khoá ký chương trình cơ sở không được tạo chương trình cơ sở khiến StrongBox bị rò rỉ bí mật, để né tránh các yêu cầu về bảo mật chức năng hoặc cho phép truy cập vào dữ liệu nhạy cảm của người dùng. Bạn nên triển khai IAR theo cách chỉ cho phép cập nhật chương trình cơ sở khi mật khẩu chính của người dùng được cung cấp qua Lớp trừu tượng phần cứng (HAL) IAuthSecret.

9,12. Xóa dữ liệu

Tất cả cách triển khai thiết bị:

• [C-0-1] PHẢI cung cấp cho người dùng cơ chế để thực hiện "Đặt lại dữ liệu về trạng thái ban đầu".
• [C-0-2] PHẢI xoá tất cả dữ liệu trên hệ thống tệp dữ liệu người dùng.
• [C-0-3] PHẢI xoá dữ liệu theo cách đáp ứng các tiêu chuẩn ngành có liên quan như NIST SP800-88.
• [C-0-4] PHẢI kích hoạt lệnh "Thiết lập lại dữ liệu gốc" ở trên khi API DevicePolicyManager.wipeData() được gọi bởi ứng dụng Trình kiểm soát chính sách thiết bị của người dùng chính.
• CÓ THỂ cung cấp tuỳ chọn xoá sạch dữ liệu nhanh chóng, chỉ tiến hành xoá dữ liệu logic.

9,13. Chế độ khởi động an toàn

Android cung cấp Chế độ khởi động an toàn, cho phép người dùng khởi động vào chế độ chỉ cho phép chạy các ứng dụng hệ thống được cài đặt trước và tắt tất cả ứng dụng bên thứ ba. Chế độ này còn được gọi là "Chế độ khởi động an toàn", mang lại cho người dùng khả năng gỡ cài đặt các ứng dụng bên thứ ba có khả năng gây hại.

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

• [SR] GameActivity NÊN triển khai Chế độ khởi động an toàn.

Nếu các hoạt động triển khai thiết bị triển khai Chế độ khởi động an toàn, thì các quá trình này sẽ:

• [C-1-1] PHẢI cung cấp cho người dùng lựa chọn chuyển sang Chế độ khởi động an toàn sao cho không bị gián đoạn từ các ứng dụng bên thứ ba được cài đặt trên thiết bị, trừ khi ứng dụng bên thứ ba là Trình kiểm soát chính sách thiết bị và đã đặt cờ UserManager.DISALLOW_SAFE_BOOT là true.

• [C-1-2] PHẢI cung cấp cho người dùng khả năng gỡ cài đặt mọi ứng dụng của bên thứ ba trong Chế độ an toàn.

• NÊN cung cấp cho người dùng tuỳ chọn để vào Chế độ khởi động an toàn từ trình đơn khởi động bằng cách sử dụng quy trình làm việc khác với quy trình khởi động thông thường.

9,14. Cách ly hệ thống xe ô tô

Các thiết bị Android Automotive được dự kiến sẽ trao đổi dữ liệu với các hệ thống con quan trọng trên xe bằng cách sử dụng HAL xe để gửi và nhận thông báo qua mạng xe, chẳng hạn như CAN bus.

Hoạt động trao đổi dữ liệu có thể được bảo mật bằng cách triển khai các tính năng bảo mật bên dưới các lớp khung Android để ngăn chặn hoạt động tương tác độc hại hoặc không cố ý với những hệ thống phụ này.

9,15. Gói thuê bao

"Gói thuê bao" tham khảo thông tin chi tiết về gói quan hệ thanh toán do nhà mạng di động cung cấp qua SubscriptionManager.setSubscriptionPlans().

Tất cả cách triển khai thiết bị:

• [C-0-1] Chỉ trả về các gói thuê bao cho ứng dụng của nhà mạng di động đã cung cấp các gói đó ban đầu.
• [C-0-2] KHÔNG ĐƯỢC sao lưu hoặc tải gói thuê bao từ xa lên.
• [C-0-3] PHẢI chỉ cho phép các cơ chế ghi đè, chẳng hạn như SubscriptionManager.setSubscriptionOverrideCongested(), từ ứng dụng của nhà mạng di động hiện đang cung cấp các gói thuê bao hợp lệ.

10. Kiểm tra tính tương thích của phần mềm

Quá trình triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử được mô tả trong phần này. Tuy nhiên, lưu ý rằng không có gói kiểm thử phần mềm nào là hoàn toàn toàn diện. Vì lý do này, các trình triển khai của thiết bị là được linh hoạt NÊN DÙNG để thực hiện số lượng thay đổi tối thiểu nhất có thể đối với tham chiếu và phương thức triển khai ưu tiên của Android có sẵn trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ gây ra lỗi tạo ra sự cố không tương thích cần phải sửa lại cũng như có thể cập nhật thiết bị.

10.1. Bộ kiểm tra tính tương thích

Triển khai thiết bị:

• [C-0-1] PHẢI vượt qua Bộ kiểm tra tính tương thích (CTS) với Android có trong Dự án nguồn mở Android bằng phần mềm vận chuyển cuối cùng trên thiết bị.

• [C-0-2] PHẢI đảm bảo tính tương thích trong các trường hợp không rõ ràng trong CTS và cho bất kỳ việc triển khai lại nào của các phần của mã nguồn tham chiếu.

CTS được thiết kế để chạy trên thiết bị thực tế. Giống như bất kỳ phần mềm nào, CTS có thể bản thân nó chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa về khả năng tương thích này và nhiều bản sửa đổi của CTS có thể được phát hành cho Android 10.

Triển khai thiết bị:

• [C-0-3] PHẢI vượt qua phiên bản CTS mới nhất có tại thời điểm hoàn tất phần mềm thiết bị.

• NÊN sử dụng hoạt động triển khai tham chiếu trong cây Nguồn mở Android nhiều nhất có thể.

10,2. Người xác minh CTS

Trình xác minh CTS đi kèm với Bộ kiểm tra tính tương thích và dành cho nhân viên vận hành để kiểm tra chức năng mà hệ thống tự động không thể kiểm tra, chẳng hạn như máy ảnh và cảm biến có hoạt động chính xác hay không.

Triển khai thiết bị:

• [C-0-1] PHẢI thực thi chính xác tất cả các trường hợp có thể áp dụng trong trình xác minh CTS.

Trình xác minh CTS có các bài kiểm tra cho nhiều loại phần cứng, bao gồm cả một số phần cứng là tùy chọn.

Triển khai thiết bị:

• [C-0-2] PHẢI vượt qua tất cả các bài kiểm tra về phần cứng mà họ sở hữu; ví dụ: nếu thiết bị có gia tốc kế, thiết bị PHẢI thực thi chính xác trường hợp kiểm tra Gia tốc kế trong Trình xác minh CTS.

Trường hợp kiểm tra các tính năng được ghi chú là không bắt buộc trong Tài liệu định nghĩa về khả năng tương thích này CÓ THỂ bị bỏ qua hoặc bỏ qua.

• [C-0-2] Mọi thiết bị và bản dựng PHẢI chạy đúng CTS Verifier, như đã nêu ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên trình triển khai thiết bị dự kiến sẽ không chạy Trình xác minh CTS một cách rõ ràng trên các bản dựng chỉ khác nhau ở những khía cạnh không quan trọng. Cụ thể, các quá trình triển khai thiết bị khác với triển khai đã vượt qua Trình xác minh CTS chỉ bằng tập hợp các ngôn ngữ, thương hiệu đi kèm, v.v. CÓ THỂ bỏ qua thử nghiệm Trình xác minh CTS.

11. Phần mềm có thể cập nhật

• [C-0-1] Các quá trình triển khai thiết bị PHẢI bao gồm một cơ chế thay thế toàn bộ phần mềm hệ thống. Cơ chế này không cần thực hiện nâng cấp "trực tiếp" – tức là bạn CÓ THỂ khởi động lại thiết bị. Có thể sử dụng bất kỳ phương pháp nào, miễn là phương pháp đó có thể thay thế toàn bộ phần mềm đã cài đặt trước trên thiết bị. Ví dụ: bất kỳ phương pháp nào sau đây sẽ đáp ứng yêu cầu này:

  • Tải xuống “ qua mạng không dây (OTA)” bằng cách cập nhật ngoại tuyến thông qua việc khởi động lại.
  • "Chia sẻ Internet" có bản cập nhật qua USB từ máy tính lưu trữ.
  • Cập nhật ở chế độ “Ngoại tuyến” bằng cách khởi động lại và cập nhật từ một tệp trên bộ nhớ di động.

• [C-0-2] Cơ chế cập nhật được sử dụng PHẢI hỗ trợ cập nhật mà không cần xoá sạch dữ liệu người dùng. Tức là cơ chế cập nhật PHẢI bảo toàn dữ liệu riêng tư của ứng dụng và dữ liệu được chia sẻ của ứng dụng. Lưu ý rằng phần mềm Android ngược dòng có một cơ chế cập nhật đáp ứng yêu cầu này.

• [C-0-3] Toàn bộ bản cập nhật PHẢI được ký và cơ chế cập nhật trên thiết bị PHẢI xác minh bản cập nhật và chữ ký dựa trên khoá công khai được lưu trữ trên thiết bị.

• [C-SR] Cơ chế ký là tôiPhải NÊN băm bản cập nhật bằng SHA-256 và xác thực băm dựa trên khóa công khai bằng cách sử dụng ECDSA NIST P-256.

Nếu quá trình triển khai thiết bị có hỗ trợ kết nối dữ liệu không đo lượng dữ liệu, chẳng hạn như 802.11 hoặc cấu hình Bluetooth PAN (Mạng khu vực cá nhân), thì các thiết bị đó:

• [C-1-1] PHẢI hỗ trợ tải xuống OTA với cập nhật ngoại tuyến thông qua khởi động lại.

Đối với các hoạt động triển khai thiết bị đang chạy Android 6.0 trở lên, cơ chế cập nhật PHẢI hỗ trợ xác minh rằng hình ảnh hệ thống là tệp nhị phân giống hệt với kết quả dự kiến sau OTA. Việc triển khai OTA dựa trên khối trong Dự án nguồn mở Android ngược dòng (được thêm vào kể từ Android 5.1) đáp ứng yêu cầu này.

Ngoài ra, các hoạt động triển khai thiết bị NÊN hỗ trợ bản cập nhật hệ thống A/B. AOSP triển khai tính năng này bằng HAL điều khiển khởi động.

Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi lỗi đó được phát hành nhưng trong vòng đời sản phẩm hợp lý được xác định theo sự tham khảo ý kiến của Nhóm tương thích với Android để ảnh hưởng đến khả năng tương thích của các ứng dụng bên thứ ba thì:

• [C-2-1] Trình triển khai thiết bị PHẢI sửa lỗi thông qua bản cập nhật phần mềm sẵn có có thể áp dụng theo cơ chế vừa được mô tả.

Android có các tính năng cho phép ứng dụng Chủ sở hữu thiết bị (nếu có) kiểm soát việc cài đặt bản cập nhật hệ thống. Nếu hệ thống cập nhật con cho thiết bị báo cáo android.software.device_admin, thì hệ thống đó sẽ:

• [C-3-1] PHẢI triển khai hành vi được mô tả trong lớp SystemUpdatePolicy.

12. Nhật ký thay đổi tài liệu

Để xem bản tóm tắt các thay đổi đối với Định nghĩa về khả năng tương thích trong bản phát hành này, hãy làm như sau:

• Nhật ký thay đổi tài liệu

Để xem tóm tắt nội dung thay đổi đối với các mục riêng lẻ:

1. Giới thiệu
2. Loại thiết bị
3. Phần mềm
4. Đóng gói ứng dụng
5. Nội dung đa phương tiện
6. Các công cụ và tuỳ chọn cho nhà phát triển
7. Khả năng tương thích với phần cứng
8. Hiệu suất và nguồn
9. Mô hình bảo mật
10. Kiểm tra khả năng tương thích với phần mềm
11. Phần mềm có thể cập nhật
12. Nhật ký thay đổi tài liệu
13. Liên hệ với chúng tôi

12.1. Mẹo xem nhật ký thay đổi

Các thay đổi được đánh dấu như sau:

• CDD
  Thay đổi đáng kể đối với các yêu cầu về khả năng tương thích.

• Tài liệu
  Các thay đổi liên quan đến hình thức trình bày hoặc bản dựng.

Để xem nội dung chính xác nhất, hãy thêm các tham số URL pretty=full và no-merges vào URL nhật ký thay đổi của bạn.

13. Liên hệ với chúng tôi

Bạn có thể tham gia diễn đàn về khả năng tương thích với android và yêu cầu giải thích cụ thể hoặc nêu ra bất kỳ vấn đề nào mà bạn cho rằng tài liệu này không đề cập đến.