1. Giới thiệu
Tài liệu này liệt kê các yêu cầu mà thiết bị phải đáp ứng để tương thích với Android 14.
Việc sử dụng các từ khoá "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "KHÔNG SẼ", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" là theo tiêu chuẩn IETF được xác định trong RFC2119.
Như được sử dụng trong tài liệu này, "người triển khai thiết bị" hoặc "người triển khai" là một người hoặc tổ chức phát triển giải pháp phần cứng/phần mềm chạy Android 14. "Thực thi thiết bị" hoặc "thực thi" là giải pháp phần cứng/phần mềm được phát triển.
Để được xem là tương thích với Android 14, việc triển khai thiết bị PHẢI đáp ứng các yêu cầu nêu trong Định nghĩa về khả năng tương thích này, bao gồm mọi tài liệu được đưa vào thông qua tham chiếu.
Where this definition or the software tests described in section 10 is silent, ambiguous, or incomplete, it is the responsibility of the device implementer to ensure compatibility with existing implementations.
Vì lý do này, Dự án nguồn mở Android vừa là tài liệu tham khảo vừa là phương thức triển khai Android được ưu tiên. Device implementers are STRONGLY RECOMMENDED to base their implementations to the greatest extent possible on the "upstream" source code available from Android Open Source Project. Mặc dù có thể giả định rằng một số thành phần có thể được thay thế bằng các phương thức triển khai thay thế, nhưng bạn KHÔNG NÊN làm theo phương pháp này vì việc vượt qua các bài kiểm thử phần mềm sẽ trở nên khó khăn hơn đáng kể. It is the implementer's responsibility to ensure behavioral compatibility with the standard Android implementation, including and beyond the Compatibility Test Suite. Cuối cùng, xin lưu ý rằng tài liệu này nghiêm cấm một số hoạt động thay thế và sửa đổi thành phần.
Nhiều tài nguyên được liên kết trong tài liệu này được lấy trực tiếp hoặc gián tiếp từ SDK Android và sẽ có chức năng giống với thông tin trong tài liệu của SDK đó. Trong mọi trường hợp mà Định nghĩa về khả năng tương thích hoặc Bộ kiểm thử khả năng tương thích không đồng ý với tài liệu SDK, tài liệu SDK sẽ được coi là tài liệu chính thức. Mọi chi tiết kỹ thuật được cung cấp trong các tài nguyên được liên kết trong tài liệu này đều được coi là một phần của Định nghĩa về khả năng tương thích này.
1.1 Cấu trúc tài liệu
1.1.1. Yêu cầu theo loại thiết bị
Mục 2 chứa tất cả các yêu cầu áp dụng cho một loại thiết bị cụ thể. Mỗi tiểu mục của Mục 2 dành riêng cho một loại thiết bị cụ thể.
Tất cả các yêu cầu khác áp dụng chung cho mọi cách triển khai thiết bị Android được liệt kê trong các phần sau Mục 2. Các yêu cầu này được gọi là "Yêu cầu cốt lõi" trong tài liệu này.
1.1.2. Mã yêu cầu
Requirement ID is assigned for MUST requirements.
- Mã này chỉ được chỉ định cho các yêu cầu BẮT BUỘC.
- STRONGLY RECOMMENDED requirements are marked as [SR] but ID is not assigned.
- Mã này bao gồm: Mã loại thiết bị – Mã điều kiện – Mã yêu cầu (ví dụ: C-0-1).
Mỗi mã nhận dạng được xác định như sau:
- Device Type ID (xem thêm trong phần 2. Loại thiết bị)
- C: Core (Yêu cầu áp dụng cho mọi hoạt động triển khai thiết bị Android)
- H: Thiết bị cầm tay Android
- T: Thiết bị Android Television
- A: Cách triển khai Android Automotive
- W: Triển khai Android Watch
- Thẻ: Triển khai trên máy tính bảng Android
- Mã điều kiện
- Khi yêu cầu không có điều kiện, mã nhận dạng này được đặt thành 0.
- Khi yêu cầu có điều kiện, hệ thống sẽ chỉ định 1 cho điều kiện thứ nhất và số này sẽ tăng thêm 1 trong cùng một mục và cùng một loại thiết bị.
- Mã yêu cầu
- Mã này bắt đầu từ 1 và tăng thêm 1 trong cùng một mục và cùng một điều kiện.
1.1.3. Requirement ID in Section 2
Mã yêu cầu trong Mục 2 có hai phần. Giá trị đầu tiên tương ứng với mã phần như mô tả ở trên. Phần thứ hai xác định kiểu dáng và yêu cầu cụ thể về kiểu dáng.
theo sau là Mã yêu cầu được mô tả ở trên.
- The ID in Section 2 consists of : Section ID / Device Type ID - Condition ID - Requirement ID (e.g. 7.4.3/A-0-1).
2. Loại thiết bị
Dự án nguồn mở Android cung cấp một ngăn xếp phần mềm có thể được sử dụng cho nhiều loại thiết bị và kiểu dáng. Để hỗ trợ bảo mật trên thiết bị, ngăn xếp phần mềm, bao gồm mọi hệ điều hành thay thế hoặc phương thức triển khai nhân thay thế, dự kiến sẽ thực thi trong môi trường bảo mật như mô tả trong phần 9 và các phần khác trong CDD này. Có một số loại thiết bị có hệ sinh thái phân phối ứng dụng tương đối tốt hơn.
Phần này mô tả các loại thiết bị đó, cũng như các yêu cầu và đề xuất bổ sung áp dụng cho từng loại thiết bị.
Tất cả các phương thức triển khai thiết bị Android không thuộc bất kỳ loại thiết bị nào được mô tả VẪN PHẢI đáp ứng tất cả các yêu cầu trong các phần khác của Định nghĩa về khả năng tương thích này.
2.1 Cấu hình thiết bị
Để biết những điểm khác biệt chính về cấu hình phần cứng theo loại thiết bị, hãy xem các yêu cầu dành riêng cho thiết bị trong phần sau.
2.2. Yêu cầu đối với thiết bị cầm tay
An Android Handheld device refers to an Android device implementation that is typically used by holding it in the hand, such as an mp3 player, phone, or tablet.
Android device implementations are classified as a Handheld if they meet all the following criteria:
- Có nguồn điện di động, chẳng hạn như pin.
- Có kích thước màn hình đường chéo thực tế trong khoảng từ 4 inch
3,3 inch (hoặc 2,5 inch đối với các thiết bị triển khai được vận chuyển trên API cấp 29 trở xuống)đến 8 inch. - Có giao diện nhập bằng màn hình cảm ứng.
The additional requirements in the rest of this section are specific to Android Handheld device implementations.
2.2.1. Phần cứng
Handheld device implementations:
- [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 đáp ứng tất cả các yêu cầu được mô tả trong tài liệu này.Màn hình có kích thước ít nhất 2,2" ở cạnh ngắn và 3,4" ở cạnh dài. [7.1.1.3/H-SR-1] NÊN cung cấp cho người dùng khả năng thay đổi kích thước màn hình (mật độ điểm ảnh).
[7.1.1.1/H-0-2] PHẢI hỗ trợ thành phần GPU của vùng đệm đồ hoạ ít nhất bằng độ phân giải cao nhất của mọi màn hình tích hợp.
Bắt đầu yêu cầu mới
[7.1.1.1/H-0-3]* PHẢI liên kết từng màn hình
UI_MODE_NORMAL
được cung cấp cho các ứng dụng bên thứ ba với một khu vực hiển thị thực tế không bị che khuất, có kích thước cạnh ngắn ít nhất là 2,2 inch và cạnh dài ít nhất là 3,4 inch.[7.1.1.3/H-0-1]* PHẢI đặt giá trị của
DENSITY_DEVICE_STABLE
lớn hơn hoặc bằng 92% mật độ thực tế của màn hình tương ứng.
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị cầm tay hỗ trợ tính năng xoay màn hình bằng phần mềm, thì các phương thức đó:
- [7.1.1.1/H-1-1]* PHẢI đảm bảo màn hình logic được cung cấp cho các ứng dụng bên thứ ba có kích thước tối thiểu là 2 inch ở(các) cạnh ngắn và 2,7 inch ở(các) cạnh dài. Các thiết bị được vận chuyển trên Android API cấp 29 trở xuống CÓ THỂ được miễn yêu cầu này.
Nếu các phương thức triển khai thiết bị cầm tay không hỗ trợ tính năng xoay màn hình bằng phần mềm, thì các phương thức đó:
- [7.1.1.1/H-2-1]* PHẢI đảm bảo màn hình logic được cung cấp cho các ứng dụng bên thứ ba có kích thước tối thiểu là 2,7 inch ở(các) cạnh ngắn. Các thiết bị được vận chuyển trên Android API cấp 29 trở xuống CÓ THỂ được miễn yêu cầu này.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị cầm tay hỗ trợ Vulkan, thì:
- [7.1.4.2/H-1-1] PHẢI đáp ứng các yêu cầu do hồ sơ Android Baseline 2021 chỉ định.
Kết thúc các yêu cầu mới
If Handheld device implementations claim support for high dynamic range
displays through Configuration.isScreenHdr()
, they:
- [7.1.4.5/H-1-1] PHẢI quảng cáo tính 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
.
Handheld device implementations:
- [7.1.4.6/H-0-1] PHẢI báo cáo xem thiết bị có hỗ trợ tính năng phân tích tài nguyên GPU thông qua thuộc tính hệ thống
graphics.gpu.profiler.support
hay không.
Nếu các phương thức triển khai thiết bị cầm tay khai báo hỗ trợ thông qua một thuộc tính hệ thống graphics.gpu.profiler.support
, thì các phương thức đó:
- [7.1.4.6/H-1-1] PHẢI báo cáo dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ cho bộ đếm GPU và giai đoạn kết xuất GPU được xác định trong tài liệu Perfetto.
- [7.1.4.6/H-1-2] PHẢI báo cáo các giá trị tuân thủ cho bộ đếm GPU của thiết bị theo proto gói theo dõi bộ đếm GPU.
- [7.1.4.6/H-1-3] PHẢI báo cáo các giá trị tuân thủ cho GPU RenderStages của thiết bị theo proto gói theo dõi giai đoạn kết xuất.
- [7.1.4.6/H-1-4] PHẢI báo cáo điểm theo dõi Tần số GPU theo định dạng được chỉ định: power/gpu_frequency.
Handheld device implementations:
- [7.1.5/H-0-1] PHẢI hỗ trợ chế độ tương thích với ứng dụng cũ như được triển khai bằng mã nguồn mở Android ngược dòng. Tức là các hoạt động triển khai thiết bị KHÔNG ĐƯỢC thay đổi các điều kiện kích hoạt hoặc ngưỡng kích hoạt chế độ tương thích và KHÔNG ĐƯỢC thay đổi hành vi của chính chế độ tương thích.
- [7.2.1/H-0-1] PHẢI hỗ trợ các ứng dụng Trình chỉnh sửa phương thức nhập (IME) của bên thứ ba.
- [7.2.3/H-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của chức năng Quay lại (
KEYCODE_BACK
) đến ứng dụng trên nền trước. These events MUST NOT be consumed by the system and CAN be triggered by outside of the Android device (e.g. external hardware keyboard connected to the Android device). - [7.2.3/H-0-3] PHẢI cung cấp chức năng Home (Trang chủ) trên tất cả màn hình tương thích với Android có cung cấp màn hình chính.
- [7.2.3/H-0-4] PHẢI cung cấp chức năng Quay lại trên tất cả màn hình tương thích với Android và chức năng Gần đây trên ít nhất một màn hình tương thích với Android.
- [7.2.4/H-0-1] MUST support touchscreen input.
- [7.2.4/H-SR-1] Are STRONGLY RECOMMENDED to launch the
user-selected assist app, in other words the app that implements
VoiceInteractionService, or an activity handling the
ACTION_ASSIST
on long-press ofKEYCODE_MEDIA_PLAY_PAUSE
orKEYCODE_HEADSETHOOK
if the foreground activity does not handle those long-press events. - [7.3.1/H-SR-1] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
If Handheld device implementations include a 3-axis accelerometer, they:
- [7.3.1/H-1-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
If Handheld device implementations include a GPS/GNSS receiver and report the
capability to applications through the android.hardware.location.gps
feature
flag, they:
- [7.3.3/H-2-1] PHẢI báo cáo các phép đo GNSS ngay khi phát hiện được, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
- [7.3.3/H-2-2] PHẢI báo cáo khoảng thời gian và tốc độ giả lập GNSS, trong điều kiện bầu trời quang đãng sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét trên giây vuông, đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0, 2 mét trên giây, ít nhất là 95% thời gian.
If Handheld device implementations include a 3-axis gyroscope, they:
- [7.3.4/H-3-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
- [7.3.4/H-3-2] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1.000 độ mỗi giây.
Các phương thức triển khai thiết bị cầm tay có thể thực hiện cuộc gọi thoại và cho biết bất kỳ giá trị nào khác ngoài PHONE_TYPE_NONE
trong getPhoneType
:
- [7.3.8/H] SHOULD include a proximity sensor.
Handheld device implementations:
- [7.3.11/H-SR-1] Bạn NÊN hỗ trợ cảm biến tư thế với 6 mức độ tự do.
- [7.4.3/H] SHOULD include support for Bluetooth and Bluetooth LE.
Nếu các thiết bị hỗ trợ giao thức WiFi Neighbor Awareness Networking (NAN) bằng cách khai báo PackageManager.FEATURE_WIFI_AWARE
và Wi-Fi Location (Thời gian truyền dữ liệu qua Wi-Fi — RTT) bằng cách khai báo PackageManager.FEATURE_WIFI_RTT
, thì các thiết bị đó:
[7.4.2.5/H-1-1] PHẢI báo cáo chính xác phạm vi trong phạm vi +/-1 mét ở băng thông 160 MHz ở phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ), +/-2 mét ở băng thông 80 MHz ở phân vị thứ 68, +/-4 mét ở băng thông 40 MHz ở phân vị thứ 68 và +/-8 mét ở băng thông 20 MHz ở phân vị thứ 68 ở khoảng cách 10 cm, 1 m, 3 m và 5 m, như được quan sát qua WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] Bạn NÊN báo cáo phạm vi chính xác trong phạm vi +/-1 mét ở băng thông 160 MHz ở phân vị thứ 90 (như được tính bằng Hàm phân phối tích luỹ), +/-2 mét ở băng thông 80 MHz ở phân vị thứ 90, +/-4 mét ở băng thông 40 MHz ở phân vị thứ 90 và +/-8 mét ở băng thông 20 MHz ở phân vị thứ 90 ở khoảng cách 10 cm, như được quan sát qua WifiRttManager#startRanging Android API.
Bạn NÊN làm theo các bước thiết lập tính năng đo lường được chỉ định trong phần Điều chỉnh hiện diện.
Bắt đầu yêu cầu mới
If Handheld device implementations declare FEATURE_BLUETOOTH_LE
, they:
- [7.4.3/H-1-3] PHẢI đo lường và bù cho độ lệch Rx để đảm bảo RSSI BLE trung bình là -50dBm +/-15 dB ở khoảng cách 1m từ thiết bị tham chiếu truyền ở
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] PHẢI đo lường và bù cho độ lệch Tx để đảm bảo RSSI BLE trung bình là -50dBm +/-15 dB khi quét từ một thiết bị tham chiếu ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH
.
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị cầm tay bao gồm một thiết bị máy ảnh logic liệt kê các tính năng bằng cách sử dụng CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, thì các phương thức đó:
- [7.5.4/H-1-1] PHẢI có trường nhìn (FOV) thông thường theo mặc định và PHẢI nằm trong khoảng từ 50 đến 90 độ.
Handheld device implementations:
- [7.6.1/H-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").
- [7.6.1/H-0-2] PHẢI trả về "true" cho
ActivityManager.isLowRamDevice()
khi có ít hơn 1 GB bộ nhớ cho kernel và không gian người dùng.
If Handheld device implementations declare support of only a 32-bit ABI:
[7.6.1/H-1-1] The memory available to the kernel and userspace MUST be at least 416MB if the default display uses framebuffer resolutions up to qHD (e.g. FWVGA).
[7.6.1/H-2-1] The memory available to the kernel and userspace MUST be at least 592MB if the default display uses framebuffer resolutions up to HD+ (e.g. HD, WSVGA).
[7.6.1/H-3-1] The memory available to the kernel and userspace MUST be at least 896MB if the default display uses framebuffer resolutions up to FHD (e.g. WSXGA+).
[7.6.1/H-4-1] The memory available to the kernel and userspace MUST be at least 1344MB if the default display uses framebuffer resolutions up to QHD (e.g. QWXGA).
If Handheld device implementations declare support of any 64-bit ABI (with or without any 32-bit ABI):
[7.6.1/H-5-1] The memory available to the kernel and userspace MUST be at least 816MB if the default display uses framebuffer resolutions up to qHD (e.g. FWVGA).
[7.6.1/H-6-1] The memory available to the kernel and userspace MUST be at least 944MB if the default display uses framebuffer resolutions up to HD+ (e.g. HD, WSVGA).
[7.6.1/H-7-1] The memory available to the kernel and userspace MUST be at least 1280MB if the default display uses framebuffer resolutions up to FHD (e.g. WSXGA+).
[7.6.1/H-8-1] The memory available to the kernel and userspace MUST be at least 1824MB if the default display uses framebuffer resolutions up to QHD (e.g. QWXGA).
Lưu ý rằng "bộ nhớ có sẵn cho hạt 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ư đài, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với việc triển khai thiết bị.
If Handheld device implementations include less than or equal to 1GB of memory available to the kernel and userspace, they:
- [7.6.1/H-9-1] MUST declare the feature flag
android.hardware.ram.low
. - [7.6.1/H-9-2] PHẢI có ít nhất 1,1 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").
If Handheld device implementations include more than 1GB of memory available to the kernel and userspace, they:
- [7.6.1/H-10-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").
- SHOULD declare the feature flag
android.hardware.ram.normal
.
If Handheld device implementations include greater than or equal to 2GB and less than 4GB of memory available to the kernel and userspace, they:
- [7.6.1/H-SR-1] Are STRONGLY RECOMMENDED to only support 32-bit userspace (both apps and system code)
If Handheld device implementations include less than 2GB of memory available to the kernel and userspace, they:
- [7.6.1/H-1-1] CHỈ ĐƯỢC hỗ trợ một ABI (chỉ 64 bit hoặc chỉ 32 bit).
Handheld device implementations:
- [7.6.2/H-0-1] KHÔNG ĐƯỢC cung cấp bộ nhớ dùng chung của ứng dụng nhỏ hơn 1 GiB.
- [7.7.1/H] SHOULD include a USB port supporting peripheral mode.
If handheld device implementations include a USB port supporting peripheral mode, they:
- [7.7.1/H-1-1] PHẢI triển khai API Android Open Accessory (AOA).
If Handheld device implementations include a USB port supporting host mode, they:
- [7.7.2/H-1-1] PHẢI triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android.
Handheld device implementations:
- [7.8.1/H-0-1] MUST include a microphone.
- [7.8.2/H-0-1] PHẢI có đầu ra âm thanh và khai báo
android.hardware.audio.output
.
If Handheld device implementations are capable of meeting all the performance requirements for supporting VR mode and include support for it, they:
- [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] MUST include an application
implementing
android.service.vr.VrListenerService
that can be enabled by VR applications viaandroid.app.Activity#setVrModeEnabled
.
Nếu các phương thức triển khai thiết bị cầm tay bao gồm một hoặc nhiều cổng USB-C ở chế độ máy chủ và triển khai (lớp âm thanh USB), ngoài các yêu cầu trong mục 7.7.2, thì các phương thức đó:
- [7.8.2.2/H-1-1] PHẢI cung cấp bản đồ ánh xạ phần mềm sau đây của các mã HID:
Chức năng | Ánh xạ | Ngữ cảnh | Hành vi |
---|---|---|---|
A | Trang sử dụng HID: 0x0C Sử dụng HID: 0x0CD Khoá hạt nhân: KEY_PLAYPAUSE Khoá Android: KEYCODE_MEDIA_PLAY_PAUSE |
Phát lại phương tiện | Đầu vào: Nhấn ngắn Đầu ra: Phát hoặc tạm dừng |
Đầu vào: Nhấn và giữ Đầu ra: Chạy lệnh thoại Gửi: android.speech.action.VOICE_SEARCH_HANDS_FREE nếu thiết bị
đang khoá hoặc màn hình đang tắt. Gửi
android.speech.RecognizerIntent.ACTION_WEB_SEARCH nếu không |
|||
Cuộc gọi đến | Đầu vào: Nhấn ngắn Đầu ra: Chấp nhận cuộc gọi |
||
Đầu vào: Nhấn và giữ Kết quả: Từ chối cuộc gọi |
|||
Cuộc gọi đang diễn ra | Đầu vào: Nhấn ngắn Đầu ra: Kết thúc cuộc gọi |
||
Đầu vào: Nhấn và giữ Đầu ra: Tắt hoặc bật micrô |
|||
B | Trang sử dụng HID: 0x0C Sử dụng HID: 0x0E9 Khoá hạt nhân: KEY_VOLUMEUP Khoá Android: VOLUME_UP |
Phát nội dung nghe nhìn, Cuộc gọi đang diễn ra | Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Tăng âm lượng của hệ thống hoặc tai nghe |
C | Trang sử dụng HID: 0x0C Sử dụng HID: 0x0EA Khoá hạt nhân: KEY_VOLUMEDOWN Khoá Android: VOLUME_DOWN |
Phát nội dung nghe nhìn, Cuộc gọi đang diễn ra | Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Giảm âm lượng của hệ thống hoặc tai nghe |
D | Trang sử dụng HID: 0x0C Sử dụng HID: 0x0CF Khoá hạt nhân: KEY_VOICECOMMAND Khoá Android: KEYCODE_VOICE_ASSIST |
Tất cả. Có thể được kích hoạt trong bất kỳ thực thể nào. | Đầu vào: Nhấn ngắn hoặc nhấn và giữ Đầu ra: Chạy lệnh thoại |
- [7.8.2.2/H-1-2] PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm phích cắm, nhưng chỉ sau khi các giao diện âm thanh USB và điểm cuối đã được liệt kê đúng cách để xác định loại thiết bị đầu cuối được kết nối.
Khi phát hiện loại thiết bị đầu cuối âm thanh USB 0x0302, các thiết bị này sẽ:
- [7.8.2.2/H-2-1] PHẢI truyền Intent ACTION_HEADSET_PLUG với "microphone" bổ sung được đặt thành 0.
Khi phát hiện loại thiết bị đầu cuối âm thanh USB 0x0402, các thiết bị này sẽ:
- [7.8.2.2/H-3-1] PHẢI truyền Intent ACTION_HEADSET_PLUG với "microphone" bổ sung được đặt thành 1.
Khi API AudioManager.getDevices() được gọi trong khi thiết bị ngoại vi USB được kết nối, các API này sẽ:
[7.8.2.2/H-4-1] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò là isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0302.
[7.8.2.2/H-4-2] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.
[7.8.2.2/H-4-3] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_HEADSET và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x0402.
[7.8.2.2/H-4-4] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò là isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x603.
[7.8.2.2/H-4-5] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x604.
[7.8.2.2/H-4-6] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSink() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.
[7.8.2.2/H-4-7] PHẢI liệt kê một thiết bị thuộc loại AudioDeviceInfo.TYPE_USB_DEVICE và vai trò isSource() nếu trường loại thiết bị đầu cuối âm thanh USB là 0x400.
[7.8.2.2/H-SR-1] Bạn NÊN thực hiện việc liệt kê các mô tả USB, xác định loại thiết bị đầu cuối và truyền tin về Ý định ACTION_HEADSET_PLUG trong vòng chưa đến 1000 mili giây sau khi kết nối thiết bị ngoại vi âm thanh USB-C.
Nếu các phương thức triển khai thiết bị cầm tay khai báo android.hardware.audio.output
và
android.hardware.microphone
, thì các phương thức đó:
[5.6/H-1-1] PHẢI có độ trễ trung bình liên tục theo vòng tròn là 300 mili giây trở xuống trong 5 lần đo, với độ lệch tuyệt đối trung bình nhỏ hơn 30 mili giây trên các đường dẫn dữ liệu sau: "loa đến micrô", bộ chuyển đổi vòng lặp 3,5 mm (nếu được hỗ trợ), USB vòng lặp (nếu được hỗ trợ).
[5.6/H-1-2] PHẢI có độ trễ trung bình của tính năng Nhấn để phát âm thanh là 300 mili giây trở xuống trong ít nhất 5 lần đo lường trên đường dẫn dữ liệu từ loa đến micrô.
If Handheld device implementations include at least one haptic actuator, they:
- [7.10/H]* KHÔNG ĐƯỢC sử dụng bộ truyền động xúc giác (máy rung) khối lượng xoay lệch tâm (ERM).
- [7.10/H]* NÊN triển khai tất cả hằng số công khai cho cảm ứng rõ ràng trong android.view.HapticFeedbackConstants cụ thể là (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START và GESTURE_END).
- [7.10/H]* NÊN triển khai tất cả hằng số công khai cho
cảm ứng rõ ràng
trong android.os.VibrationEffect
cụ thể là (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK và
EFFECT_DOUBLE_CLICK) và tất cả hằng số
PRIMITIVE_*
công khai khả thi cho cảm ứng phong phú trong android.os.VibrationEffect.Composition cụ thể là (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Một số loại dữ liệu gốc này, chẳng hạn như LOW_TICK và SPIN, có thể chỉ khả thi nếu bộ rung có thể hỗ trợ tần số tương đối thấp. - [7.10/H]* NÊN làm theo hướng dẫn liên kết các hằng số công khai trong android.view.HapticFeedbackConstants với các hằng số android.os.VibrationEffect được đề xuất, với các mối quan hệ biên độ tương ứng.
- [7.10/H]* NÊN tuân theo quy trình đánh giá chất lượng cho các API createOneShot() và createWaveform().
- [7.10/H]* NÊN xác minh rằng kết quả của API android.os.Vibrator.hasAmplitudeControl() công khai phản ánh chính xác chức năng của bộ rung.
- [7.10/H]* NÊN đặt vị trí của bộ truyền động gần vị trí mà người dùng thường cầm hoặc chạm vào thiết bị.
Bộ truyền động cộng hưởng tuyến tính (LRA) là một hệ thống lò xo khối lượng đơn có tần số cộng hưởng chính, trong đó khối lượng dịch chuyển theo hướng chuyển động mong muốn.
If Handheld device implementations include at least one general purpose 7.10 linear resonant actuator, they:
Bắt đầu yêu cầu mới
- [7.10/H] NÊN đặt vị trí của bộ truyền động gần vị trí mà người dùng thường cầm hoặc chạm vào thiết bị.
Kết thúc các yêu cầu mới
- [7.10/H] NÊN di chuyển bộ truyền động xúc giác theo trục X (trái-phải) của hướng dọc
tự nhiêncủa thiết bị.
If Handheld device implementations have a general purpose haptic actuator which is X-axis linear resonant actuator (LRA), they:
- [7.10/H] BAN PHÉP tần số cộng hưởng của LRA trục X dưới 200 Hz.
Nếu việc triển khai thiết bị cầm tay tuân theo ánh xạ hằng số xúc giác, thì:
- [7.10/H]* NÊN xác minh trạng thái triển khai bằng cách chạy API android.os.Vibrator.areAllEffectsSupported() và android.os.Vibrator.arePrimitivesSupported().
[7.10/H]* NÊN thực hiện đánh giá chất lượng cho các hằng số xúc giác.
[7.10/H]* NÊN xác minh và cập nhật nếu cần cấu hình dự phòng cho các nguyên hàm không được hỗ trợ như mô tả trong hướng dẫn triển khai cho các hằng số.
2.2.2. Đa phương tiện
Handheld device implementations MUST support the following audio encoding and decoding formats and make them available to third-party applications:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
- [5.1/H-0-5] AAC ELD (enhanced low delay AAC)
Các phương thức triển khai thiết bị cầm tay PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
Handheld device implementations MUST support the following video decoding formats and make them available to third-party applications:
2.2.3. Phần mềm
Handheld device implementations:
- [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 APIDocumentsProvider
. - [3.2.3.1/H-0-2]* PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
- [3.2.3.1/H-SR-1] Bạn NÊN tải trước một ứng dụng email có thể xử lý ý định ACTION_SENDTO hoặc ACTION_SEND hoặc ACTION_SEND_MULTIPLE để gửi email.
- [3.4.1/H-0-1] PHẢI cung cấp cách triển khai đầy đủ API
android.webkit.Webview
. - [3.4.2/H-0-1] PHẢI có một ứng dụng Trình duyệt độc lập để người dùng duyệt web thông thường.
- [3.8.1/H-SR-1] Are STRONGLY RECOMMENDED to implement a default launcher that supports in-app pinning of shortcuts, widgets and widgetFeatures.
- [3.8.1/H-SR-2] Are STRONGLY RECOMMENDED to implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API.
- [3.8.1/H-SR-3] Are STRONGLY RECOMMENDED to include a default launcher app that shows badges for the app icons.
- [3.8.2/H-SR-1] Are STRONGLY RECOMMENDED to support third-party app widgets.
- [3.8.3/H-0-1] PHẢI cho phép ứng dụng bên thứ ba thông báo cho người dùng về các sự kiện đáng chú ý thô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] MUST support heads-up notifications.
- [3.8.3/H-0-4] MUST include a notification shade, providing the user the ability to directly control (e.g. reply, snooze, dismiss, block) the notifications through user affordance such as action buttons or the control panel as implemented in the AOSP.
- [3.8.3/H-0-5] PHẢI hiển thị các lựa chọn được cung cấp thông qua
RemoteInput.Builder setChoices()
trong ngăn thông báo. - [3.8.3/H-SR-1] Are STRONGLY RECOMMENDED
to display the first choice provided through
RemoteInput.Builder setChoices()
in the notification shade without additional user interaction. - [3.8.3/H-SR-2] Are STRONGLY RECOMMENDED
to display all the choices provided through
RemoteInput.Builder setChoices()
in the notification shade when the user expands all notifications in the notification shade. - [3.8.3.1/H-SR-1] Bạn NÊN hiển thị các hành động mà
Notification.Action.Builder.setContextual
được đặt thànhtrue
cùng dòng với các câu trả lời doNotification.Remoteinput.Builder.setChoices
hiển thị. - [3.8.4/H-SR-1] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.
Nếu các phương thức triển khai thiết bị cầm tay hỗ trợ thông báo MediaStyle, thì các phương thức đó:
- [3.8.3.1/H-SR-2] Bạn NÊN cung cấp một chức năng cho người dùng (ví dụ: trình chuyển đổi đầu ra) truy cập được từ giao diện người dùng hệ thống, cho phép người dùng chuyển đổi giữa các tuyến nội dung nghe nhìn có sẵn phù hợp (ví dụ: thiết bị Bluetooth và tuyến được cung cấp cho
MediaRouter2Manager
) khi một ứng dụng đăng thông báoMediaStyle
có mã thông báoMediaSession
.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị bao gồm cả phím điều hướng chức năng gần đây như được nêu chi tiết trong mục 7.2.3 làm thay đổi giao diện, thì:
- [3.8.3/H-1-1] PHẢI triển khai hành vi ghim màn hình và cung cấp cho người dùng một trình đơn cài đặt để bật/tắt tính năng này.
Kết thúc các yêu cầu mới
If Handheld device implementations support Assist action, they:
- [3.8.4/H-SR-2] Are STRONGLY RECOMMENDED
to use long press on
HOME
key as the designated interaction to launch the assist app as described in section 7.2.3. PHẢI chạy ứng dụng hỗ trợ do người dùng chọn, tức là ứng dụng triển khaiVoiceInteractionService
hoặc một hoạt động xử lý ý địnhACTION_ASSIST
.
Nếu các phương thức triển khai thiết bị cầm tay hỗ trợ conversation notifications
và nhóm các thông báo đó vào một phần riêng biệt với thông báo cảnh báo và thông báo không phải cuộc trò chuyện ở chế độ im lặng, thì các phương thức triển khai đó:
- [3.8.4/H-1-1]* PHẢI hiển thị thông báo cuộc trò chuyện trước thông báo không phải cuộc trò chuyện, ngoại trừ thông báo dịch vụ trên nền trước đang diễn ra và thông báo importance:high.
If Android Handheld device implementations support a lock screen, they:
- [3.8.10/H-1-1] MUST display the Lock screen Notifications including the Media Notification Template.
If Handheld device implementations support a secure lock screen, they:
- [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 SDK Android.
Nếu các phương thức triển khai thiết bị cầm tay hỗ trợ các API ControlsProviderService
và Control
, đồng thời cho phép các ứng dụng bên thứ ba phát hành các chế độ điều khiển thiết bị, thì các phương thức đó:
- [3.8.16/H-1-1] PHẢI khai báo cờ tính năng
android.software.controls
và đặt thànhtrue
. - [3.8.16/H-1-2] PHẢI cung cấp cho người dùng khả năng thêm, chỉnh sửa, chọn và vận hành các chế độ điều khiển thiết bị yêu thích của người dùng từ các chế độ điều khiển do ứng dụng bên thứ ba đăng ký thông qua
ControlsProviderService
vàControl
API. - [3.8.16/H-1-3] PHẢI cung cấp quyền truy cập vào tính năng này cho người dùng trong vòng 3 lượt tương tác từ Trình chạy mặc định.
[3.8.16/H-1-4] PHẢI hiển thị chính xác tên và biểu tượng của từng ứng dụng bên thứ ba cung cấp các chế độ điều khiển thông qua API
ControlsProviderService
cũng như mọi trường được chỉ định do các APIControl
cung cấp trong chức năng hỗ trợ người dùng này.[3.8.16/H-1-5] PHẢI cung cấp cho người dùng khả năng chọn không sử dụng các chế độ điều khiển thiết bị không quan trọng về xác thực do ứng dụng chỉ định từ các chế độ điều khiển do ứng dụng bên thứ ba đăng ký thông qua API
ControlsProviderService
vàControl
Control.isAuthRequired
.
Bắt đầu yêu cầu mới
- [3.8.16/H-1-6] Việc triển khai thiết bị
PHẢI hiển thị chính xác chức năng của người dùng như sau:
- Nếu thiết bị đã đặt
config_supportsMultiWindow=true
và ứng dụng khai báo siêu dữ liệuMETA_DATA_PANEL_ACTIVITY
trong phần khai báoControlsProviderService
, bao gồm cả ComponentName của một hoạt động hợp lệ (do API xác định), thì ứng dụng PHẢI nhúng hoạt động nói trên vào khả năng hỗ trợ người dùng này. - Nếu không khai báo siêu dữ liệu
META_DATA_PANEL_ACTIVITY
, thì ứng dụng PHẢI hiển thị các trường được chỉ định do APIControlsProviderService
cung cấp cũng như mọi trường được chỉ định do API Control cung cấp.
- Nếu thiết bị đã đặt
- [3.8.16/H-1-7] Nếu ứng dụng khai báo siêu dữ liệu
META_DATA_PANEL_ACTIVITY
, thì ứng dụng đó PHẢI truyền giá trị của chế độ cài đặt được xác định trong [3.8.16/H-1-5] bằng cách sử dụngEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
khi khởi chạy hoạt động được nhúng.
Kết thúc các yêu cầu mới
Ngược lại, nếu các phương thức triển khai Thiết bị cầm tay không triển khai các chế độ kiểm soát như vậy, thì:
- [3.8.16/H-2-1] PHẢI báo cáo
null
cho các APIControlsProviderService
vàControl
. - [3.8.16/H-2-2] PHẢI khai báo cờ tính năng
android.software.controls
và đặt thànhfalse
.
Nếu các phương thức triển khai thiết bị cầm tay không chạy ở chế độ khoá tác vụ, thì khi nội dung được sao chép vào bảng nhớ tạm, các phương thức đó sẽ:
- [3.8.17/H-1-1] PHẢI hiển thị thông báo xác nhận cho người dùng rằng dữ liệu đã được sao chép vào bảng nhớ tạm (ví dụ: hình thu nhỏ hoặc cảnh báo "Nội dung đã sao chép"). Ngoài ra, hãy thêm thông tin cho biết liệu dữ liệu bảng nhớ tạm có được đồng bộ hoá trên các thiết bị hay không.
Handheld device implementations:
- [3.10/H-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
- [3.10/H-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của Switch Access và TalkBack (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.
- [3.11/H-0-1] MUST support installation of third-party TTS engines.
- [3.11/H-SR-1] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.
- [3.13/H-SR-1] Are STRONGLY RECOMMENDED to include a Quick Settings UI component.
If Android handheld device implementations declare FEATURE_BLUETOOTH
or
FEATURE_WIFI
support, they:
- [3.16/H-1-1] PHẢI hỗ trợ tính năng ghép nối thiết bị đồng hành.
Nếu hàm điều hướng được cung cấp dưới dạng thao tác trên màn hình dựa trên cử chỉ:
- [7.2.3/H] Vùng nhận dạng cử chỉ cho chức năng Trang chủ KHÔNG ĐƯỢC cao hơn 32 dp so với đáy màn hình.
Nếu các phương thức triển khai thiết bị cầm tay cung cấp một chức năng điều hướng dưới dạng cử chỉ từ bất kỳ vị trí nào trên cạnh trái và phải của màn hình:
- [7.2.3/H-0-1] Chiều rộng của khu vực cử chỉ của chức năng điều hướng PHẢI 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.
If Handheld device implementations support a secure lock screen and have greater than or equal to 2GB of memory available to the kernel and userspace, they:
- [3.9/H-1-2] PHẢI khai báo tính năng hỗ trợ hồ sơ được quản lý thông qua cờ tính năng
android.software.managed_users
.
Nếu các phương thức triển khai thiết bị cầm tay Android khai báo tính năng hỗ trợ máy ảnh thông qua android.hardware.camera.any
, thì các phương thức đó:
- [7.5.4/H-1-1] PHẢI tuân thủ ý định
android.media.action.STILL_IMAGE_CAMERA
vàandroid.media.action.STILL_IMAGE_CAMERA_SECURE
và khởi chạy máy ảnh ở chế độ ảnh tĩnh như mô tả trong SDK. - [7.5.4/H-1-2] PHẢI tuân thủ ý định
android.media.action.VIDEO_CAMERA
để khởi chạy máy ảnh ở chế độ video như mô tả trong SDK.
Nếu ứng dụng cài đặt của quá trình triển khai thiết bị triển khai một chức năng phân tách bằng cách nhúng hoạt động, thì các ứng dụng đó:
- [3.2.3.1/ H-1-1] PHẢI có một hoạt động xử lý ý định Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY khi chức năng phân tách đang bật. Hoạt động PHẢI được bảo vệ bằng
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
và PHẢI bắt đầu hoạt động của Ý định được phân tích cú pháp từ Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị cho phép người dùng thực hiện cuộc gọi bất kỳ, thì
- [7.4.1.2/H-0-1] PHẢI khai báo cờ tính năng
android.software.telecom
. - [7.4.1.2/H-0-2] PHẢI triển khai khung viễn thông.
Kết thúc các yêu cầu mới
2.2.4. Hiệu suất và nguồn điện
- [8.1/H-0-1] Độ trễ khung hình nhất quán. Độ trễ khung hình không nhất quán hoặc độ trễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình/giây và PHẢI dưới 1 khung hình/giây.
- [8.1/H-0-2] Độ trễ giao diện người dùng. Việc triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách 10.000 mục danh sách theo định nghĩa của Bộ kiểm thử tính tương thích với Android (CTS) trong vòng chưa đến 36 giây.
- [8.1/H-0-3] Task switching. Khi nhiều ứng dụng đã được khởi chạy, việc khởi chạy lại một ứng dụng đang chạy sau khi khởi chạy PHAI PHẢI mất chưa đến 1 giây.
Handheld device implementations:
- [8.2/H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.
- [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.
If Handheld device implementations include features to improve device power management that are included in AOSP or extend the features that are included in AOSP, they:
- [8.3/H-1-1] PHẢI cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.
- [8.3/H-1-2] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ tiết kiệm pin App Standby và Doze.
Handheld device implementations:
- [8.4/H-0-1] PHẢI cung cấp hồ sơ năng lượng theo thành phần xác định giá trị tiêu thụ hiện tại cho từng thành phần phần cứng và mức hao pin gần đúng do các thành phần này gây ra theo thời gian như được ghi nhận trên trang web của Dự án nguồn mở Android.
- [8.4/H-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng bằng miliampe giờ (mAh).
- [8.4/H-0-3] MUST report CPU power
consumption per each process's UID. The Android Open Source Project meets the
requirement through the
uid_cputime
kernel module implementation. - [8.4/H-0-4] PHẢI cung cấp mức sử dụng pin này cho nhà phát triển ứng dụng thông qua lệnh shell
adb shell dumpsys batterystats
. - [8.4/H] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
If Handheld device implementations include a screen or video output, they:
- [8.4/H-1-1] PHẢI tuân thủ ý định
android.intent.action.POWER_USAGE_SUMMARY
và hiển thị trình đơn cài đặt cho biết mức sử dụng pin này.
Handheld device implementations:
- [8.5/H-0-1] PHẢI cung cấp một tính năng hỗ trợ người dùng
trong trình đơn Cài đặtđể xem tất cả ứng dụng có dịch vụ trên nền trước đang hoạt động hoặc công việc do người dùng khởi tạo, bao gồm cả thời lượng của từng dịch vụ này kể từ khi bắt đầu như mô tả trong tài liệu SDK.và khả năng dừng một ứng dụng đang chạy dịch vụ trên nền trước hoặc công việc do người dùng khởi tạo.với khả năng dừng một ứng dụng đang chạy dịch vụ trên nền trước và hiển thị tất cả ứng dụng có dịch vụ trên nền trước đang hoạt động và thời lượng của từng dịch vụ này kể từ khi bắt đầu như mô tả trong tài liệu SDK.- Một số ứng dụng CÓ THỂ được miễn bị dừng hoặc được liệt kê trong một tính năng hỗ trợ người dùng như vậy như mô tả trong tài liệu SDK.
Bắt đầu yêu cầu mới
- [8.5/H-0-2]PHẢI cung cấp cho người dùng khả năng dừng một ứng dụng đang chạy dịch vụ trên nền trước hoặc công việc do người dùng khởi tạo.
Kết thúc các yêu cầu mới
2.2.5. Mô hình bảo mật
Handheld device implementations:
- [9/H-0-1] PHẢI khai báo tính năng
android.hardware.security.model.compatible
. - [9.1/H-0-1] PHẢI cho phép ứng dụng bên thứ ba truy cập vào số liệu thống kê về mức sử dụng thông qua quyền
android.permission.PACKAGE_USAGE_STATS
và cung cấp cơ chế mà người dùng có thể truy cập để cấp hoặc thu hồi quyền truy cập vào các ứng dụng đó theo ý địnhandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
Bắt đầu yêu cầu mới
If device implementations declare support for android.hardware.telephony
,
they:
- [9.5/H-1-1] KHÔNG ĐƯỢC đặt
UserManager.isHeadlessSystemUserMode
thànhtrue
.
Kết thúc các yêu cầu mới
Handheld device implementations:
- [9.11/H-0-2] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
- [9.11/H-0-3] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên hạt nhân trở lên. Tính năng cô lập an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường được cô lập, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một giải pháp triển khai bảo mật được bên thứ ba xem xét dựa trên một máy ảo thích hợp là các lựa chọn thay thế.
- [9.11/H-0-4] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi tách biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Thông tin xác thực trên màn hình khoá PHẢI được lưu trữ theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện quy trình xác thực trên màn hình khoá. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can be used to satisfy this requirement.
- [9.11/H-0-5] PHẢI hỗ trợ quy trình chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quy trình ký được thực hiện trong phần cứng bảo mật. Các khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc các khoá này được dùng làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu bạn sản xuất hơn 100.000 đơn vị của một SKU, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.
Xin lưu ý rằng nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ, thì thiết bị đó sẽ được miễn yêu cầu phải có kho khoá được môi trường thực thi tách biệt hỗ trợ và hỗ trợ chứng thực khoá, trừ phi thiết bị đó khai báo tính năng android.hardware.fingerprint
yêu cầu kho khoá được môi trường thực thi tách biệt hỗ trợ.
Khi triển khai thiết bị cầm tay hỗ trợ màn hình khoá bảo mật, thiết bị đó:
- [9.11/H-1-1] MUST allow the user to choose the shortest sleep timeout, that is a transition time from the unlocked to the locked state, as 15 seconds or less.
- [9.11/H-1-2] PHẢI cung cấp cho người dùng khả năng ẩn thông báo và tắt tất cả các hình thức xác thực, ngoại trừ hình thức xác thực chính được mô tả trong 9.11.1 Màn hình khoá bảo mật. The AOSP meets the requirement as lockdown mode.
Bắt đầu yêu cầu mới
If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService
System API, they:
- [9.11.1/H-1-1] PHẢI yêu cầu người dùng xác thực bằng một trong các phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) thường xuyên hơn một lần mỗi 72 giờ.
Kết thúc các yêu cầu mới
If Handheld device implementations include multiple users and
do not declare the android.hardware.telephony
feature flag, they:
- [9.5/H-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.
If Handheld device implementations include multiple users and
declare the android.hardware.telephony
feature flag, they:
- [9.5/H-3-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để bật /tắt quyền truy cập của người dùng khác vào cuộc gọi thoại và tin nhắn SMS.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị cầm tay đặt UserManager.isHeadlessSystemUserMode
thành true
, thì các phương thức đó
- [9.5/H-4-1] KHÔNG ĐƯỢC hỗ trợ eUICC hoặc eSIM có chức năng gọi điện.
- [9.5/H-4-2] KHÔNG ĐƯỢC khai báo hỗ trợ cho
android.hardware.telephony
.
Kết thúc các yêu cầu mới
Android, thông qua API Hệ thống VoiceInteractionService, hỗ trợ một cơ chế phát hiện từ khoá kích hoạt luôn bật một cách an toàn mà không cần chỉ báo truy cập micrô và phát hiện truy vấn luôn bật mà không cần chỉ báo truy cập micrô hoặc máy ảnh.
Nếu các phương thức triển khai Thiết bị cầm tay hỗ trợ API hệ thống HotwordDetectionService
hoặc một cơ chế khác để phát hiện cụm từ kích hoạt mà không có chỉ báo quyền truy cập vào micrô, thì các phương thức đó:
- [9.8/H-1-1] PHẢI đảm bảo dịch vụ phát hiện cụm từ kích hoạt chỉ có thể truyền dữ liệu đến Hệ thống,
ContentCaptureService
, hoặc dịch vụ nhận dạng lời nói trên thiết bị doSpeechRecognizer#createOnDeviceSpeechRecognizer()
tạo. - [9.8/H-1-2] PHẢI đảm bảo dịch vụ phát hiện cụm từ kích hoạt chỉ có thể truyền dữ liệu âm thanh của micrô hoặc dữ liệu bắt nguồn từ micrô đó đến máy chủ hệ thống thông qua API
HotwordDetectionService
hoặc đếnContentCaptureService
thông qua APIContentCaptureManager
. - [9.8/H-1-3] KHÔNG ĐƯỢC cung cấp âm thanh micrô dài hơn 30 giây cho một yêu cầu kích hoạt bằng phần cứng riêng lẻ đến dịch vụ phát hiện cụm từ kích hoạt.
- [9.8/H-1-4] KHÔNG ĐƯỢC cung cấp âm thanh micrô được lưu vào bộ đệm cũ hơn 8 giây cho một yêu cầu riêng lẻ đến dịch vụ phát hiện từ khoá kích hoạt.
- [9.8/H-1-5] KHÔNG ĐƯỢC cung cấp âm thanh micrô được lưu vào bộ đệm lâu hơn 30 giây cho dịch vụ tương tác bằng giọng nói hoặc thực thể tương tự.
- [9.8/H-1-6] KHÔNG ĐƯỢC cho phép truyền nhiều hơn 100 byte dữ liệu qua dịch vụ phát hiện cụm từ kích hoạt trên mỗi kết quả cụm từ kích hoạt thành công ngoại trừ dữ liệu âm thanh được truyền qua HotwordAudioStream.
- [9.8/H-1-7] KHÔNG ĐƯỢC cho phép truyền nhiều hơn 5 bit dữ liệu ra khỏi dịch vụ phát hiện cụm từ kích hoạt trên mỗi kết quả cụm từ kích hoạt âm tính.
- [9.8/H-1-8] PHẢI chỉ cho phép truyền dữ liệu ra khỏi dịch vụ phát hiện cụm từ kích hoạt theo yêu cầu xác thực cụm từ kích hoạt từ máy chủ hệ thống.
- [9.8/H-1-9] KHÔNG ĐƯỢC cho phép ứng dụng mà người dùng có thể cài đặt cung cấp dịch vụ phát hiện cụm từ kích hoạt.
- [9.8/H-1-10] KHÔNG ĐƯỢC hiển thị trong dữ liệu định lượng trên giao diện người dùng về việc sử dụng micrô của dịch vụ phát hiện từ khoá kích hoạt.
- [9.8/H-1-11] PHẢI ghi lại số byte có trong mỗi lần truyền từ dịch vụ phát hiện cụm từ kích hoạt để cho phép các nhà nghiên cứu bảo mật kiểm tra.
- [9.8/H-1-12] PHẢI hỗ trợ chế độ gỡ lỗi ghi lại nội dung thô của mọi lượt truyền từ dịch vụ phát hiện cụm từ kích hoạt để cho phép các nhà nghiên cứu bảo mật kiểm tra.
- [9.8/H-1-14] PHẢI hiển thị chỉ báo micrô, như mô tả trong phần 9.8.2, khi kết quả cụm từ kích hoạt thành công được truyền đến dịch vụ tương tác bằng giọng nói hoặc thực thể tương tự.
Bắt đầu yêu cầu mới
- [9.8/H-1-15] PHẢI đảm bảo rằng các luồng âm thanh được cung cấp trên kết quả cụm từ kích hoạt thành công được truyền một chiều từ dịch vụ phát hiện cụm từ kích hoạt đến dịch vụ tương tác bằng giọng nói.
Kết thúc các yêu cầu mới
- [9.8/H-SR-1] Bạn NÊN thông báo cho người dùng trước khi đặt một ứng dụng làm nhà cung cấp dịch vụ phát hiện cụm từ kích hoạt.
- [9.8/H-SR-2] Bạn NÊN KHÔNG cho phép truyền dữ liệu không có cấu trúc ra khỏi dịch vụ phát hiện cụm từ kích hoạt.
- [9.8/H-SR-3] Bạn NÊN khởi động lại quy trình lưu trữ dịch vụ phát hiện cụm từ kích hoạt ít nhất một lần mỗi giờ hoặc mỗi 30 sự kiện kích hoạt phần cứng, tuỳ theo điều kiện nào đến trước.
Nếu quá trình triển khai thiết bị bao gồm một ứng dụng sử dụng API hệ thống HotwordDetectionService
hoặc cơ chế tương tự để phát hiện cụm từ kích hoạt mà không có chỉ báo sử dụng micrô, thì ứng dụng đó:
- [9.8/H-2-1] PHẢI thông báo rõ ràng cho người dùng về từng cụm từ kích hoạt được hỗ trợ.
- [9.8/H-2-2] KHÔNG ĐƯỢC lưu giữ dữ liệu âm thanh thô hoặc dữ liệu bắt nguồn từ dữ liệu âm thanh thô đó thông qua dịch vụ phát hiện cụm từ kích hoạt.
- [9.8/H-2-3] KHÔNG ĐƯỢC truyền từ dịch vụ phát hiện cụm từ kích hoạt, dữ liệu âm thanh, dữ liệu có thể dùng để tái tạo (một phần hoặc toàn bộ) âm thanh hoặc nội dung âm thanh không liên quan đến cụm từ kích hoạt, ngoại trừ
ContentCaptureService
hoặc dịch vụ nhận dạng lời nói trên thiết bị.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai Thiết bị cầm tay hỗ trợ API Hệ thống VisualQueryDetectionService
hoặc một cơ chế khác để phát hiện truy vấn mà không có chỉ báo truy cập micrô và/hoặc máy ảnh, thì các phương thức đó:
- [9.8/H-3-1] PHẢI đảm bảo rằng dịch vụ phát hiện truy vấn chỉ có thể truyền dữ liệu đến Hệ thống,
ContentCaptureService
hoặc dịch vụ nhận dạng lời nói trên thiết bị (doSpeechRecognizer#createOnDeviceSpeechRecognizer()
tạo). - [9.8/H-3-2] KHÔNG ĐƯỢC cho phép truyền bất kỳ thông tin âm thanh hoặc video nào ra khỏi
VisualQueryDetectionService
, ngoại trừContentCaptureService
hoặc dịch vụ nhận dạng lời nói trên thiết bị. - [9.8/H-3-3] PHẢI hiển thị thông báo cho người dùng trong giao diện người dùng hệ thống khi thiết bị phát hiện ý định của người dùng tương tác với Ứng dụng trợ lý kỹ thuật số (ví dụ: bằng cách phát hiện sự hiện diện của người dùng thông qua máy ảnh).
- [9.8/H-3-4] PHẢI hiển thị chỉ báo micrô và hiển thị truy vấn người dùng đã phát hiện trong giao diện người dùng ngay sau khi phát hiện truy vấn người dùng.
- [9.8/H-3-5] KHÔNG ĐƯỢC cho phép ứng dụng mà người dùng có thể cài đặt cung cấp dịch vụ phát hiện truy vấn hình ảnh.
Kết thúc các yêu cầu mới
If Handheld device implementations declare android.hardware.microphone
, they:
- [9.8.2/H-4-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
hoặc các ứng dụng giữ vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X]. - [9.8.2/H-4-2] PHẢI hiển thị danh sách các ứng dụng Gần đây và Đang hoạt động sử dụng micrô như được trả về từ
PermissionManager.getIndicatorAppOpUsageData()
, cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó.
If Handheld device implementations declare android.hardware.camera.any
, they:
- [9.8.2/H-5-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không phải khi máy ảnh chỉ được(các) ứng dụng có vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X].
- [9.8.2/H-5-2] PHẢI hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng camera được trả về từ
PermissionManager.getIndicatorAppOpUsageData()
, cùng với mọi thông báo phân bổ liên quan đến các ứng dụng đó.
2.2.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển
Cách triển khai trên thiết bị cầm tay (* Không áp dụng cho máy tính bảng):
- [6.1/H-0-1]* PHẢI hỗ trợ lệnh shell
cmd testharness
.
Cách triển khai trên thiết bị cầm tay (* Không áp dụng cho máy tính bảng):
- Perfetto
- [6.1/H-0-2]* PHẢI hiển thị tệp nhị phân
/system/bin/perfetto
cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto. - [6.1/H-0-3]* Tệp nhị phân perfetto PHẢI chấp nhận một cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/H-0-4]* Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/H-0-5]* PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [6.1/H-0-6]* Theo mặc định, bạn PHẢI bật trình nền theo dõi perfetto (thuộc tính hệ thống
persist.traced.enable
).
- [6.1/H-0-2]* PHẢI hiển thị tệp nhị phân
2.2.7. Lớp học về hiệu suất nội dung nghe nhìn trên thiết bị cầm tay
Xem Mục 7.11 để biết định nghĩa về lớp hiệu suất nội dung nghe nhìn.
2.2.7.1. Nội dung nghe nhìn
Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T
cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn được liệt kê trong mục 2.2.7.1 của CDD Android 13.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai Thiết bị cầm tay trả vềandroid.os.Build.VERSION_CODES.U
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- [5.1/H-1-1] PHẢI quảng cáo số lượng phiên giải mã video phần cứng tối đa có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã nào thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()
vàVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] PHẢI hỗ trợ 6 phiên giải mã video phần cứng 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên ở độ phân giải 1080p@30 khung hình/giây và 3 phiên ở độ phân giải 4K@30 khung hình/giây. Bạn chỉ cần hỗ trợ bộ mã hoá và giải mã AV1 cho độ phân giải 1080p, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 1080p30fps.
- [5.1/H-1-3] PHẢI quảng cáo số lượng tối đa phiên mã hoá video phần cứng có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã nào thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()
vàVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] PHẢI hỗ trợ 6 phiên mã hoá video phần cứng 8 bit (SDR) (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 4 phiên ở độ phân giải 1080p@30 khung hình/giây và 2 phiên ở độ phân giải 4K@30 khung hình/giây. Bạn chỉ cần hỗ trợ bộ mã hoá và giải mã AV1 cho độ phân giải 1080p, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 1080p30fps.
- [5.1/H-1-5] PHẢI quảng cáo số lượng tối đa phiên mã hoá và giải mã video phần cứng có thể chạy đồng thời trong bất kỳ tổ hợp bộ mã hoá và giải mã nào thông qua các phương thức
CodecCapabilities.getMaxSupportedInstances()
vàVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] PHẢI hỗ trợ 6 phiên bản bộ giải mã video phần cứng 8 bit (SDR) và phiên bản bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên bản ở độ phân giải 4K@30fps, trong đó tối đa 2 phiên bản là phiên bản bộ mã hoá và 3 phiên bản ở độ phân giải 1080p. Bạn chỉ cần hỗ trợ bộ mã hoá và giải mã AV1 cho độ phân giải 1080p, nhưng vẫn phải hỗ trợ 6 phiên bản ở tốc độ 1080p30fps.
- [5.1/H-1-19] PHẢI hỗ trợ 3 phiên bản bộ giải mã video phần cứng 10 bit (HDR) và phiên bản bộ mã hoá video phần cứng (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời ở độ phân giải 4K@30fps, trong đó tối đa 1 phiên bản là phiên bản bộ mã hoá, có thể được định cấu hình ở định dạng đầu vào RGBA_1010102 thông qua một bề mặt GL. Bạn không bắt buộc phải tạo siêu dữ liệu HDR bằng bộ mã hoá nếu mã hoá từ nền tảng GL. Các phiên bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này là 4K.
- [5.1/H-1-7] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 40 mili giây trở xuống đối với phiên mã hoá video 1080p trở xuống cho tất cả bộ mã hoá video phần cứng khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy tính năng quay video và âm thanh 1080p. Đối với bộ mã hoá và giải mã Dolby Vision, độ trễ khởi chạy bộ mã hoá và giải mã PHẢI là 50 mili giây trở xuống.
- [5.1/H-1-8] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 30 mili giây trở xuống cho phiên mã hoá âm thanh có tốc độ bit từ 128 kb/giây trở xuống cho tất cả bộ mã hoá âm thanh khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy tính năng quay video và âm thanh 1080p.
- [5.1/H-1-9] PHẢI hỗ trợ 2 phiên giải mã video phần cứng bảo mật (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời ở độ phân giải 1080p@30 khung hình/giây cho cả nội dung 8 bit (SDR) và 10 bit HDR.
- [5.1/H-1-10] PHẢI hỗ trợ 3 phiên bản bộ giải mã video phần cứng không bảo mật cùng với 1 phiên bản bộ giải mã video phần cứng bảo mật (tổng cộng 4 phiên bản) (AVC, HEVC, VP9, AV1 trở lên) trong bất kỳ tổ hợp bộ mã hoá và giải mã nào chạy đồng thời với 3 phiên bản ở độ phân giải 4K@30 khung hình/giây, bao gồm một phiên bản bộ giải mã bảo mật và 1 phiên bản không bảo mật ở độ phân giải 1080p@30 khung hình/giây, trong đó tối đa 2 phiên bản có thể ở định dạng HDR 10 bit. Các phiên bộ mã hoá và giải mã AV1 chỉ cần hỗ trợ độ phân giải 1080p ngay cả khi yêu cầu này là 4K.
- [5.1/H-1-11] PHẢI hỗ trợ bộ giải mã bảo mật cho mọi bộ giải mã AVC, HEVC, VP9 hoặc AV1 phần cứng trên thiết bị.
- [5.1/H-1-12] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 40 mili giây trở xuống đối với phiên giải mã video 1080p trở xuống cho tất cả bộ giải mã video phần cứng khi đang tải. Tải ở đây được xác định là một phiên chuyển mã chỉ video 1080p sang 720p đồng thời sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy phát âm thanh và video 1080p. Đối với bộ mã hoá và giải mã Dolby Vision, độ trễ khởi chạy bộ mã hoá và giải mã PHẢI là 50 mili giây trở xuống.
- [5.1/H-1-13] PHẢI có độ trễ khởi chạy bộ mã hoá và giải mã là 30 mili giây trở xuống cho phiên giải mã âm thanh có tốc độ bit từ 128 kb/giây trở xuống cho tất cả bộ giải mã âm thanh khi có tải. Tải ở đây được xác định là một phiên chuyển mã đồng thời chỉ video 1080p sang 720p bằng cách sử dụng bộ mã hoá và giải mã video phần cứng cùng với quá trình khởi chạy phát âm thanh và video 1080p.
- [5.1/H-1-14] PHẢI hỗ trợ bộ giải mã phần cứng AV1 Main 10, Level 4.1 và hạt phim.
- [5.1/H-1-15] PHẢI có ít nhất 1 bộ giải mã video phần cứng hỗ trợ 4K60.
- [5.1/H-1-16] PHẢI có ít nhất 1 bộ mã hoá video phần cứng hỗ trợ 4K60.
- [5.3/H-1-1] KHÔNG ĐƯỢC bỏ lỡ nhiều hơn 1 khung hình trong 10 giây (tức là tỷ lệ bỏ lỡ khung hình dưới 0,167%) đối với phiên phát video 4K 60 khung hình/giây khi tải.
- [5.3/H-1-2] KHÔNG ĐƯỢC bỏ lỡ nhiều hơn 1 khung hình trong 10 giây khi thay đổi độ phân giải video trong một phiên video 60 khung hình/giây khi tải cho một phiên 4K.
- [5.6/H-1-1] PHẢI có độ trễ nhấn để phát âm thanh là 80 mili giây trở xuống bằng cách sử dụng quy trình kiểm thử nhấn để phát âm thanh của Trình xác minh CTS.
- [5.6/H-1-2] PHẢI có độ trễ âm thanh trọn vòng là 80 mili giây trở xuống trên ít nhất một đường dẫn dữ liệu được hỗ trợ.
- [5.6/H-1-3] PHẢI hỗ trợ âm thanh >=24 bit cho đầu ra âm thanh nổi qua giắc cắm âm thanh 3,5 mm nếu có và qua âm thanh USB nếu được hỗ trợ thông qua toàn bộ đường dẫn dữ liệu cho độ trễ thấp và cấu hình truyền trực tuyến. Đối với cấu hình độ trễ thấp, ứng dụng phải sử dụng AAudio ở chế độ gọi lại độ trễ thấp. Đối với cấu hình truyền trực tuyến, ứng dụng phải sử dụng AudioTrack Java. Trong cả cấu hình truyền trực tuyến và độ trễ thấp, bồn lưu trữ đầu ra HAL phải chấp nhận
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
hoặcAUDIO_FORMAT_PCM_FLOAT
cho định dạng đầu ra mục tiêu. - [5.6/H-1-4] PHẢI hỗ trợ thiết bị âm thanh USB có >=4 kênh (Thiết bị này được bộ điều khiển DJ sử dụng để xem trước bài hát).
- [5.6/H-1-5] PHẢI hỗ trợ các thiết bị MIDI tuân thủ lớp và khai báo cờ tính năng MIDI.
- [5.6/H-1-9] PHẢI hỗ trợ ít nhất 12 kênh trộn. Điều này ngụ ý khả năng mở một AudioTrack có mặt nạ kênh 7.1.4 và tạo âm thanh không gian hoặc kết hợp tất cả các kênh thành âm thanh nổi một cách chính xác.
- [5.6/H-SR] NÊN hỗ trợ tính năng trộn 24 kênh với ít nhất là hỗ trợ mặt nạ kênh 9.1.6 và 22.2.
- [5.7/H-1-2] PHẢI hỗ trợ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
bằng các tính năng giải mã nội dung dưới đây.
Kích thước mẫu tối thiểu | 4 MiB |
Số lượng mẫu con tối thiểu – H264 hoặc HEVC | 32 |
Số lượng mẫu con tối thiểu – VP9 | 9 |
Số lượng mẫu con tối thiểu – AV1 | 288 |
Kích thước vùng đệm lấy mẫu con tối thiểu | 1 MiB |
Kích thước vùng đệm mã hoá chung tối thiểu | 500 KiB |
Số phiên đồng thời tối thiểu | 30 |
Số lượng khoá tối thiểu trên mỗi phiên | 20 |
Tổng số khoá tối thiểu (tất cả phiên) | 80 |
Tổng số khoá DRM tối thiểu (tất cả phiên) | 6 |
Kích thước thư | 16 KiB |
Số khung hình đã giải mã/giây | 60 khung hình/giây |
- [5.1/H-1-17] PHẢI có ít nhất 1 bộ giải mã hình ảnh phần cứng hỗ trợ Cấu hình cơ sở của AVIF.
- [5.1/H-1-18] PHẢI hỗ trợ bộ mã hoá AV1 có thể mã hoá lên đến độ phân giải 480p ở tốc độ 30 khung hình/giây và 1 Mb/giây.
[5.12/H-1-1] PHẢI[5.12/H-SR] Bạn nên hỗ trợ tính năngFeature_HdrEditing
cho tất cả bộ mã hoá AV1 và HEVC phần cứng có trên thiết bị.- [5.12/H-1-2] PHẢI hỗ trợ định dạng màu RGBA_1010102 cho tất cả bộ mã hoá AV1 và HEVC phần cứng có trên thiết bị.
- [5.12/H-1-3] PHẢI quảng cáo tính năng hỗ trợ tiện ích EXT_YUV_target để lấy mẫu từ hoạ tiết YUV ở cả 8 và 10 bit.
- [7.1.4/H-1-1] PHẢI có ít nhất 6 lớp phủ phần cứng trong Bộ xử lý màn hình (DPU), trong đó ít nhất 2 lớp phủ có thể hiển thị nội dung video 10 bit.
Nếu các phương thức triển khai thiết bị cầm tay trả về android.os.Build.VERSION_CODES.U
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
và bao gồm cả
tính năng hỗ trợ bộ mã hoá AVC hoặc HEVC phần cứng, thì các phương thức đó:
- [5.2/H-2-1] PHẢI đáp ứng mục tiêu chất lượng tối thiểu do các đường cong độ méo tỷ lệ của bộ mã hoá video xác định cho bộ mã hoá và giải mã AVC và HEVC phần cứng, như được xác định trong bài kiểm thử Run Performance Class 14 (PC14)-Video encoding quality (VEQ) (Chạy thử nghiệm hiệu suất cấp 14 – Chất lượng mã hoá video).
Kết thúc các yêu cầu mới
2.2.7.2. Camera
Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T
cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn được liệt kê trong mục 2.2.7.2 của CDD Android 13.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai Thiết bị cầm tay trả vềandroid.os.Build.VERSION_CODES.U
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- [7.5/H-1-1] PHẢI có camera chính ở mặt sau với độ phân giải tối thiểu là 12 megapixel, hỗ trợ quay video ở độ phân giải 4K@30fps. Máy ảnh chính mặt sau là máy ảnh mặt sau có mã máy ảnh thấp nhất.
- [7.5/H-1-2] PHẢI có camera chính ở mặt trước với độ phân giải tối thiểu là 6 megapixel và hỗ trợ quay video ở độ phân giải 1080p@30fps. Máy ảnh mặt trước chính là máy ảnh mặt trước có mã máy ảnh thấp nhất.
- [7.5/H-1-3] PHẢI hỗ trợ thuộc tính
android.info.supportedHardwareLevel
làFULL
trở lên đối với camera chính sau vàLIMITED
trở lên đối với camera chính trước. - [7.5/H-1-4] PHẢI hỗ trợ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
cho cả hai camera chính. - [7.5/H-1-5] PHẢI có độ trễ chụp ảnh JPEG camera2 < 1000
900ms cho độ phân giải 1080p theo đo lường của PerformanceTest camera CTS trong các điều kiện chiếu sáng ITS (3000K) cho cả hai camera chính. - [7.5/H-1-6] PHẢI có độ trễ khởi động camera2 (mở camera đến khung hình xem trước đầu tiên) < 500 mili giây theo đo lường của PerformanceTest camera CTS trong điều kiện chiếu sáng ITS (3000K) cho cả hai camera chính.
- [7.5/H-1-8] PHẢI hỗ trợ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
vàandroid.graphics.ImageFormat.RAW_SENSOR
cho camera sau chính. - [7.5/H-1-9] PHẢI có camera chính ở mặt sau hỗ trợ độ phân giải 720p hoặc 1080p @ 240 khung hình/giây.
- [7.5/H-1-10] PHẢI có ZOOM_RATIO tối thiểu < 1.0 cho camera chính nếu có camera RGB góc siêu rộng hướng về cùng một hướng.
- [7.5/H-1-11] PHẢI triển khai tính năng truyền trực tuyến đồng thời trước và sau trên camera chính.
- [7.5/H-1-12] PHẢI hỗ trợ
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
cho cả camera trước chính và camera sau chính. - [7.5/H-1-13] PHẢI hỗ trợ tính năng
LOGICAL_MULTI_CAMERA
cho máy ảnh chính ở mặt sau nếu có nhiều hơn 1 máy ảnh RGB ở mặt sau. - [7.5/H-1-14] PHẢI hỗ trợ chức năng
STREAM_USE_CASE
cho cả camera trước chính và camera sau chính. - [7.5/H-1-15] PHẢI hỗ trợ
Bokeh vàcác tiện ích Chế độ ban đêm thông qua cả tiện ích CameraX và Camera2 cho camera chính. - [7.5/H-1-16] PHẢI hỗ trợ tính năng DYNAMIC_RANGE_TEN_BIT cho camera chính.
- [7.5/H-1-17] PHẢI hỗ trợ CONTROL_SCENE_MODE_FACE_PRIORITY và tính năng phát hiện khuôn mặt (STATISTICS_FACE_DETECT_MODE_SIMPLE hoặc STATISTICS_FACE_DETECT_MODE_FULL) cho máy ảnh chính.
Kết thúc các yêu cầu mới
2.2.7.3. Phần cứng
Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- PHẢI đáp ứng các yêu cầu về nội dung nghe nhìn được liệt kê trong mục 2.2.7.3 của CDD Android 13.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai Thiết bị cầm tay trả vềandroid.os.Build.VERSION_CODES.U
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- [7.1.1.1/H-2-1] PHẢI có độ phân giải màn hình tối thiểu là 1080p.
- [7.1.1.3/H-2-1] PHẢI có mật độ điểm ảnh trên màn hình ít nhất là 400 dpi.
- [7.1.1.3/H-3-1] PHẢI có màn hình HDR hỗ trợ độ sáng trung bình tối thiểu là 1.000 nit.
- [7.6.1/H-2-1] PHẢI có ít nhất 8 GB bộ nhớ vật lý.
Kết thúc các yêu cầu mới
2.2.7.4. Hiệu suất
Nếu các phương thức triển khai Thiết bị cầm tay trả về android.os.Build.VERSION_CODES.T
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- PHẢI đáp ứng các yêu cầu về hiệu suất được liệt kê trong mục 2.2.7.4 của CDD Android 13.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai Thiết bị cầm tay trả vềandroid.os.Build.VERSION_CODES.U
cho
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
- [8.2/H-1-1] PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu là 150 MB/giây.
- [8.2/H-1-2] PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 10 MB/giây.
- [8.2/H-1-3] PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu là 250 MB/giây.
- [8.2/H-1-4] PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu là 100 MB/giây.
- [8.2/H-1-5] PHẢI đảm bảo hiệu suất đọc và ghi tuần tự song song với hiệu suất đọc 2 lần và hiệu suất ghi 1 lần ít nhất là 50 MB/giây.
Kết thúc các yêu cầu mới
2.3. Yêu cầu đối với chương trình truyền hình
Thiết bị Android Television là một cách triển khai thiết bị Android, là giao diện giải trí để người dùng ngồi cách khoảng 3 mét có thể thưởng thức 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 tiếp (gọi là "giao diện người dùng thư giãn" hoặc "giao diện người dùng 3 mét").
Android device implementations are classified as a Television if they meet all the following criteria:
- Đã 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 3 mét.
- Có màn hình tích hợp có đường chéo lớn hơn 24 inch HOẶC có cổng đầu ra video, chẳng hạn như VGA, HDMI, DisplayPort hoặc cổng không dây để hiển thị.
The additional requirements in the rest of this section are specific to Android Television device implementations.
2.3.1. Phần cứng
Television device implementations:
- [7.2.2/T-0-1] MUST support D-pad.
- [7.2.3/T-0-1] PHẢI cung cấp các chức năng Trang chủ và Quay lại.
- [7.2.3/T-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của chức năng Quay lại (
KEYCODE_BACK
) đến ứng dụng trên nền trước. - [7.2.6.1/T-0-1] PHẢI hỗ trợ tay điều khiển trò chơi và khai báo cờ tính năng
android.hardware.gamepad
. - [7.2.7/T] SHOULD provide a remote control from which users can access non-touch navigation and core navigation keys inputs.
If Television device implementations include a 3-axis gyroscope, they:
- [7.3.4/T-1-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
- [7.3.4/T-1-2] MUST be capable of measuring orientation changes up to 1000 degrees per second.
Television device implementations:
- [7.4.3/T-0-1] PHẢI hỗ trợ Bluetooth và Bluetooth LE.
- [7.6.1/T-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").
If Television device implementations include a USB port that supports host mode, they:
- [7.5.3/T-1-1] MUST include support for an external camera that connects through this USB port but is not necessarily always connected.
If TV device implementations are 32-bit:
[7.6.1/T-1-1] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used:
- 400dpi or higher on small/normal screens
- xhdpi trở lên trên màn hình lớn
- tvdpi or higher on extra large screens
If TV device implementations are 64-bit:
[7.6.1/T-2-1] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used:
- 400dpi or higher on small/normal screens
- xhdpi trở lên trên màn hình lớn
- tvdpi or higher on extra large screens
Lưu ý rằng "bộ nhớ có sẵn cho hạt 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ớ đã được dành riêng cho các thành phần phần cứng như đài, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với việc triển khai thiết bị.
Television device implementations:
- [7.8.1/T] SHOULD include a microphone.
- [7.8.2/T-0-1] PHẢI có đầu ra âm thanh và khai báo
android.hardware.audio.output
.
2.3.2. Đa phương tiện
Các phương thức triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (enhanced low delay AAC)
Television device implementations MUST support the following video encoding formats and make them available to third-party applications:
Television device implementations:
- [5.2.2/T-SR-1] Are STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p resolution videos at 30 frames per second.
Các phương thức triển khai thiết bị truyền hình PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
Các phương thứ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 tiêu chuẩn lên đến và bao gồm:
- [5.3.1/T-1-1] HD 1080p at 29.97 frames per second with Main Profile High Level.
- [5.3.1/T-1-2] HD 1080i ở tốc độ 59,94 khung hình/giây với Cấp cao của Hồ sơ chính. Các ứng dụng này PHẢI tách khung hình video MPEG-2 nội suy và cung cấp video đó cho các ứng dụng bên thứ ba.
Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4, at standard video frame rates and resolutions up to and including:
- [5.3.4/T-1-1] HD 1080p at 60 frames per second with Profile cơ sở
- [5.3.4/T-1-2] HD 1080p at 60 frames per second with Profile chính
- [5.3.4/T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
Television device implementations with H.265 hardware decoders MUST support H.265 decoding, as detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
- [5.3.5/T-1-1] HD 1080p at 60 frames per second with Profile Level 4.1
If Television device implementations with H.265 hardware decoders support H.265 decoding and the UHD decoding profile, they:
- [5.3.5/T-2-1] PHẢI hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ Main10 cấp 5, cấp chính
Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6, at standard video frame rates and resolutions up to and including:
- [5.3.6/T-1-1] HD 1080p at 60 frames per second decoding profile
Television device implementations with VP9 hardware decoders MUST support VP9 decoding, as detailed in Section 5.3.7, at standard video frame rates and resolutions up to and including:
- [5.3.7/T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit colour depth)
If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD decoding profile, they:
- [5.3.7/T-2-1] PHẢI hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ 0 (độ sâu màu 8 bit).
- [5.3.7/T-SR1] NÊN hỗ trợ hồ sơ giải mã UHD ở tốc độ 60 khung hình/giây với hồ sơ 2 (độ sâu màu 10 bit).
Television device implementations:
- [5.5/T-0-1] PHẢI hỗ trợ âm lượng chính của hệ thống và giảm âm lượng đầu ra âm thanh kỹ thuật số trên các đầu ra được hỗ trợ, ngoại trừ đầu ra truyền âm thanh nén (không có quá trình giải mã âm thanh nào diễn ra trên thiết bị).
Nếu các phương thức triển khai thiết bị truyền hình không có màn hình tích hợp, nhưng hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các phương thức đó:
- [5.8/T-0-1] MUST set the HDMI
output mode to the highest resolution for the chosen pixel format that works
with 50Hz or 60Hz refresh rate for the external display, depending on the video
refresh rate for the region the device is sold in.
PHẢI đặt chế độ đầu ra HDMI để chọn độ phân giải tối đa có thể hỗ trợ với tốc độ làm mới 50Hz hoặc 60Hz. - [5.8/T-SR-1] Are STRONGLY RECOMMENDED to provide a user selectable HDMI refresh rate selector.
- [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 ở khu vực bán thiết bị.
Nếu các phương thức triển khai thiết bị truyền hình không có màn hình tích hợp, nhưng hỗ trợ màn hình ngoài được kết nối qua HDMI, thì các phương thức đó:
- [5.8/T-1-1] MUST support HDCP 2.2.
If Television device implementations do not support UHD decoding, but instead support an external display connected via HDMI, they:
- [5.8/T-2-1] PHẢI hỗ trợ HDCP 1.4
2.3.3. Phần mềm
Television device implementations:
- [3/T-0-1] PHẢI khai báo các tính năng
android.software.leanback
vàandroid.hardware.type.television
. - [3.2.3.1/T-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
- [3.4.1/T-0-1] PHẢI cung cấp cách triển khai đầy đủ API
android.webkit.Webview
.
If Android Television device implementations support a lock screen,they:
- [3.8.10/T-1-1] PHẢI hiển thị Thông báo trên màn hình khoá, bao gồm cả Mẫu thông báo đa phương tiện.
Television device implementations:
- [3.8.14/T-SR-1] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode multi-window.
- [3.10/T-0-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
- [3.10/T-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của tính năng Truy cập bằng công tắc và TalkBack (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.
If Television device implementations report the feature
android.hardware.audio.output
, they:
- [3.11/T-SR-1] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.
- [3.11/T-1-1] MUST support installation of third-party TTS engines.
Television device implementations:
- [3.12/T-0-1] MUST support TV Input Framework.
2.3.4. Hiệu suất và nguồn điện
- [8.1/T-0-1] Độ trễ khung hình nhất quán. Độ trễ khung hình không nhất quán hoặc độ trễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình/giây và PHẢI dưới 1 khung hình/giây.
- [8.2/T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
- [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] MUST ensure a random read performance of at least 3.5MB/s.
If Television device implementations include features to improve device power management that are included in AOSP or extend the features that are included in AOSP, they:
- [8.3/T-1-1] PHẢI cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.
Nếu các phương thức triển khai thiết bị truyền hình không có pin, thì:
- [8.3/T-1-2] PHẢI đăng ký thiết bị dưới dạng thiết bị không dùng pin như mô tả trong phần Hỗ trợ thiết bị không dùng pin.
If Television device implementations have a battery they:
- [8.3/T-1-3] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ tiết kiệm pin App Standby và Doze.
Television device implementations:
- [8.4/T-0-1] PHẢI cung cấp hồ sơ năng lượng theo thành phần xác định giá trị tiêu thụ hiện tại cho từng thành phần phần cứng và mức hao pin gần đúng do các thành phần này gây ra theo thời gian như được ghi nhận trên trang web của Dự án nguồn mở Android.
- [8.4/T-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng bằng miliampe giờ (mAh).
- [8.4/T-0-3] MUST report CPU power
consumption per each process's UID. The Android Open Source Project meets the
requirement through the
uid_cputime
kernel module implementation. - [8.4/T] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
- [8.4/T-0-4] PHẢI cung cấp mức sử dụng pin này cho nhà phát triển ứng dụng thông qua lệnh shell
adb shell dumpsys batterystats
.
2.3.5. Mô hình bảo mật
Television device implementations:
- [9/T-0-1] MUST declare the
android.hardware.security.model.compatible
feature. - [9.11/T-0-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
- [9.11/T-0-2] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và các cấp cao hơn. Tính năng cô lập an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường được cô lập, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một giải pháp triển khai bảo mật được bên thứ ba xem xét dựa trên một máy ảo thích hợp là các lựa chọn thay thế.
- [9.11/T-0-3] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi riêng biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Thông tin xác thực trên màn hình khoá PHẢI được lưu trữ theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện quy trình xác thực trên màn hình khoá. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can be used to satisfy this requirement.
- [9.11/T-0-4] PHẢI hỗ trợ quy trình chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quy trình ký được thực hiện trong phần cứng bảo mật. Các khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc các khoá này được dùng làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu bạn sản xuất hơn 100.000 đơn vị của một SKU, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.
Xin lưu ý rằng nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ, thì thiết bị đó sẽ được miễn yêu cầu phải có kho khoá được môi trường thực thi tách biệt hỗ trợ và hỗ trợ chứng thực khoá, trừ phi thiết bị đó khai báo tính năng android.hardware.fingerprint
yêu cầu kho khoá được môi trường thực thi tách biệt hỗ trợ.
If Television device implementations support a secure lock screen, they:
- [9.11/T-1-1] MUST allow the user to choose the Sleep timeout for transition from the unlocked to the locked state, with a minimum allowable timeout up to 15 seconds or less.
If Television device implementations include multiple users and
do not declare the android.hardware.telephony
feature flag, they:
- [9.5/T-2-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.
If Television device implementations include multiple users and
declare the android.hardware.telephony
feature flag, they:
- [9.5/T-3-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để cho phép /vô hiệu hoá người dùng khác truy cập vào cuộc gọi thoại và tin nhắn SMS.
If Television device implementations declare android.hardware.microphone
, they:
- [9.8.2/T-4-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được truy cập bởi HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService hoặc các ứng dụng giữ vai trò được nêu trong Mục 9.1 về Quyền có giá trị nhận dạng CDD C-3-X].
- [9.8.2/T-4-2] KHÔNG ĐƯỢC ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc có hoạt động tương tác trực tiếp với người dùng.
If Television device implementations declare android.hardware.camera.any
, they:
- [9.8.2/T-5-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không được hiển thị khi(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền truy cập vào máy ảnh có giá trị nhận dạng CDD [C-3-X] chỉ truy cập vào máy ảnh.
- [9.8.2/T-5-2] KHÔNG được ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc tương tác trực tiếp với người dùng.
2.3.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển
Television device implementations:
- Perfetto
- [6.1/T-0-1] PHẢI hiển thị tệp nhị phân
/system/bin/perfetto
cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto. - [6.1/T-0-2] Tệp nhị phân perfetto PHẢI chấp nhận một cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/T-0-3] Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/T-0-4] PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [6.1/T-0-1] PHẢI hiển thị tệp nhị phân
2.4. Yêu cầu đối với đồng hồ
Thiết bị Android Watch là một cách triển khai thiết bị Android để đeo trên cơ thể, chẳng hạn như trên cổ tay.
Android device implementations are classified as a Watch if they meet all the following criteria:
- Have a screen with the physical diagonal length in the range from 1.1 to 2.5 inches.
- Có cơ chế để đeo trên cơ thể.
The additional requirements in the rest of this section are specific to Android Watch device implementations.
2.4.1. Phần cứng
Watch device implementations:
[7.1.1.1/W-0-1] PHẢI có màn hình với kích thước đường chéo thực tế trong khoảng từ 1,1 đến 2,5 inch.
[7.2.3/W-0-1] PHẢI cung cấp chức năng Trang chủ và chức năng Quay lại cho người dùng, ngoại trừ khi ở
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] MUST support touchscreen input.
[7.3.1/W-SR-1] Bạn NÊN sử dụng gia tốc kế 3 trục.
If Watch device implementations include a GPS/GNSS receiver and report the
capability to applications through the android.hardware.location.gps
feature
flag, they:
- [7.3.3/W-1-1] MUST report GNSS measurements, as soon as they are found, even if a location calculated from GPS/GNSS is not yet reported.
- [7.3.3/W-1-2] PHẢI báo cáo khoảng thời gian và tốc độ giả lập GNSS, trong điều kiện bầu trời quang đãng sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét trên giây vuông, đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0, 2 mét trên giây, ít nhất là 95% thời gian.
If Watch device implementations include a 3-axis gyroscope, they:
- [7.3.4/W-2-1] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1.000 độ mỗi giây.
Watch device implementations:
[7.4.3/W-0-1] MUST support Bluetooth.
[7.6.1/W-0-1] PHẢI có ít nhất 1 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng (còn gọi là phân vùng "/data").
[7.6.1/W-0-2] PHẢI có ít nhất 416 MB bộ nhớ cho nhân và không gian người dùng.
[7.8.1/W-0-1] MUST include a microphone.
[7.8.2/W] CÓ THỂ có đầu ra âm thanh.
2.4.2. Đa phương tiện
Không có yêu cầu bổ sung.
2.4.3. Phần mềm
Watch device implementations:
- [3/W-0-1] PHẢI khai báo tính năng
android.hardware.type.watch
. - [3/W-0-2] MUST support uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ có trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
Watch device implementations:
- [3.8.4/W-SR-1] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.
Watch device implementations that declare the android.hardware.audio.output
feature flag:
- [3.10/W-1-1] PHẢI hỗ trợ các dịch vụ hỗ trợ tiếp cận của bên thứ ba.
- [3.10/W-SR-1] Bạn NÊN tải trước các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận của tính năng Tiếp cận bằng công tắc và TalkBack (đối với các ngôn ngữ được công cụ Chuyển văn bản sang lời nói được cài đặt sẵn hỗ trợ) như được cung cấp trong dự án nguồn mở talkback.
If Watch device implementations report the feature android.hardware.audio.output, they:
[3.11/W-SR-1] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.
[3.11/W-0-1] PHẢI hỗ trợ cài đặt các công cụ TTS của bên thứ ba.
2.4.4. Hiệu suất và nguồn điện
If Watch device implementations include features to improve device power management that are included in AOSP or extend the features that are included in AOSP, they:
- [8.3/W-SR-1] Bạn NÊN cung cấp chức năng cho phép người dùng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ Tiết kiệm pin khi ở chế độ Nghỉ và chế độ Tiết kiệm pin khi ở chế độ Nghỉ.
- [8.3/W-SR-2] Bạn NÊN cung cấp chức năng cho phép người dùng bật và tắt tính năng tiết kiệm pin.
Watch device implementations:
- [8.4/W-0-1] PHẢI cung cấp hồ sơ năng lượng theo thành phần xác định giá trị tiêu thụ hiện tại cho từng thành phần phần cứng và mức hao pin gần đúng do các thành phần này gây ra theo thời gian như được ghi nhận trên trang web của Dự án nguồn mở Android.
- [8.4/W-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng bằng miliampe giờ (mAh).
- [8.4/W-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. The Android Open Source Project meets the
requirement through the
uid_cputime
kernel module implementation. - [8.4/W-0-4] PHẢI cung cấp mức sử dụng pin này cho nhà phát triển ứng dụng thông qua lệnh shell
adb shell dumpsys batterystats
. - [8.4/W] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
2.4.5. Mô hình bảo mật
Watch device implementations:
- [9/W-0-1] PHẢI khai báo tính năng
android.hardware.security.model.compatible
.
If Watch device implementations include multiple users and
do not declare the android.hardware.telephony
feature flag, they:
- [9.5/W-1-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.
If Watch device implementations include multiple users and
declare the android.hardware.telephony
feature flag, they:
- [9.5/W-2-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để bật /tắt quyền truy cập của người dùng khác vào cuộc gọi thoại và tin nhắn SMS.
Bắt đầu yêu cầu mới
If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService
System API, they:
- [9.11.1/W-1-1] PHẢI yêu cầu người dùng xác thực bằng một trong các phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) thường xuyên hơn một lần mỗi 72 giờ.
Kết thúc các yêu cầu mới
2.5. Yêu cầu về ô tô
Android Automotive implementation (Triển khai Android Automotive) đề cập đến một đầu phát trung tâm trên ô tô chạy Android làm hệ điều hành cho một phần hoặc toàn bộ hệ thống và/hoặc chức năng thông tin giải trí.
Android device implementations are classified as an Automotive if they declare
the feature android.hardware.type.automotive
or meet all the following
criteria.
- Được nhúng vào hoặc có thể cắm vào một xe ô tô.
- Are using a screen in the driver's seat row as the primary display.
The additional requirements in the rest of this section are specific to Android Automotive device implementations.
2.5.1. Phần cứng
Automotive device implementations:
- [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ế tối thiểu là 6 inch.
- [7.1.1.1/A-0-2] PHẢI có bố cục kích thước màn hình tối thiểu là 750 dp x 480 dp.
- [7.2.3/A-0-1] PHẢI cung cấp chức năng Home (Trang chủ) và CÓ THỂ cung cấp chức năng Back (Quay lại) và Recent (Gần đây).
- [7.2.3/A-0-2] PHẢI gửi cả sự kiện nhấn thông thường và nhấn và giữ của chức năng Quay lại (
KEYCODE_BACK
) đến ứng dụng trên nền trước. - [7.3/A-0-1] PHẢI triển khai và báo cáo
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
vàPARKING_BRAKE_ON
. - [7.3/A-0-2] Giá trị của cờ
NIGHT_MODE
PHẢI nhất quán với chế độ ngày/đêm của trang tổng quan và NÊN dựa trên dữ liệu đầu vào của cảm biến ánh sáng xung quanh. Cảm biến ánh sáng xung quanh cơ bản CÓ THỂ giống với Photometer. - [7.3/A-0-3] PHẢI cung cấp trường thông tin bổ sung của cảm biến
TYPE_SENSOR_PLACEMENT
là một phần của SensorAdditionalInfo cho mọi cảm biến được cung cấp. - [7.3/A-SR1] CÓ THỂ dự đoán vị trí Vị trí bằng cách kết hợp GPS/GNSS với các cảm biến bổ sung. Nếu Vị trí là vị trí dự đoán, bạn NÊN triển khai và báo cáo các loại Cảm biến tương ứng và/hoặc Mã nhận dạng tài sản của xe được sử dụng.
[7.3/A-0-4] Vị trí được yêu cầu thông qua LocationManager#requestLocationUpdates() KHÔNG ĐƯỢC so khớp với bản đồ.
[7.3.1/A-0-4] PHẢI tuân thủ hệ toạ độ cảm biến ô tô của Android.
[7.3/A-SR-1] Bạn NÊN_THỰC_HIỆN việc đưa vào một con quay hồi chuyển 3 trục và một gia tốc kế 3 trục.
[7.3/A-SR-2] Bạn NÊN triển khai và báo cáo cảm biến
TYPE_HEADING
.
If device implementations support OpenGL ES 3.1, they:
- [7.1.4.1/A-0-1] PHẢI khai báo OpenGL ES 3.1 trở lên.
- [7.1.4.1/A-0-2] PHẢI hỗ trợ Vulkan 1.1.
- [7.1.4.1/A-0-3] PHẢI bao gồm trình tải Vulkan và xuất tất cả các biểu tượng.
If Automotive device implementations include an accelerometer, they:
- [7.3.1/A-1-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
If device implementations include a 3-axis accelerometer, they:
- [7.3.1/A-SR-1] Bạn NÊN triển khai cảm biến tổng hợp cho gia tốc kế trục hạn chế.
If Automotive device implementations include an accelerometer with less than 3 axes, they:
- [7.3.1/A-1-3] PHẢI triển khai và báo cáo cảm biến
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] PHẢI triển khai và báo cáo cảm biến
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
If Automotive device implementations include a gyroscope, they:
- [7.3.4/A-2-1] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 100 Hz.
- [7.3.4/A-2-3] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 250 độ mỗi giây.
- [7.3.4/A-SR-1] Bạn NÊN định cấu hình phạm vi đo lường của con quay hồi chuyển thành +/-250dps để tăng tối đa độ phân giải có thể.
If Automotive device implementations include a 3-axis gyroscope, they:
- [7.3.4/A-SR-2] Bạn NÊN triển khai cảm biến tổng hợp cho con quay hồi chuyển trục giới hạn.
If Automotive device implementations include a gyroscope with less than 3-axes, they:
- [7.3.4/A-4-1] PHẢI triển khai và báo cáo cảm biến
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] PHẢI triển khai và báo cáo cảm biến
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Nếu các phương thức triển khai thiết bị Automotive có bộ thu GPS/GNSS nhưng không có khả năng kết nối dữ liệu dựa trên mạng di động, thì các phương thức đó:
- [7.3.3/A-3-1] PHẢI xác định vị trí trong lần đầu tiên bật bộ thu GPS/GNSS hoặc sau 4 ngày trở lên trong vòng 60 giây.
- [7.3.3/A-3-2] PHẢI đáp ứng các tiêu chí về thời gian để xác định vị trí lần đầu như mô tả trong 7.3.3/C-1-2 và 7.3.3/C-1-6 đối với tất cả các yêu cầu vị trí khác (tức là các yêu cầu không phải là lần đầu tiên hoặc sau 4 ngày trở lên). Yêu cầu 7.3.3/C-1-2 thường được đáp ứng trong các xe không có kết nối dữ liệu dựa trên mạng di động, bằng cách sử dụng thông tin dự đoán quỹ đạo GNSS được tính toán trên bộ thu hoặc sử dụng vị trí xe đã biết gần đây nhất cùng với khả năng dự đoán vị trí trong ít nhất 60 giây với độ chính xác vị trí đáp ứng 7.3.3/C-1-3 hoặc kết hợp cả hai.
Nếu các phương thức triển khai thiết bị ô tô bao gồm cảm biến TYPE_HEADING
, thì các phương thức đó:
- [7.3.4/A-4-3] PHẢI có khả năng báo cáo các sự kiện với tần suất tối thiểu là 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED to report events up to a frequency of at least 10 Hz.
- PHẢI tham chiếu đến hướng bắc thực.
- PHẢI có sẵn ngay cả khi xe đang đứng yên.
- NÊN có độ phân giải tối thiểu là 1 độ.
Automotive device implementations:
- [7.4.3/A-0-1] PHẢI hỗ trợ Bluetooth và NÊN hỗ trợ Bluetooth LE.
- [7.4.3/A-0-2] Các phương thức triển khai Android Automotive
PHẢI hỗ trợ các hồ sơ Bluetooth sau:
- Gọi điện thoại qua Cấu hình rảnh tay (HFP).
- Phát nội dung nghe nhìn qua Cấu hình phân phối âm thanh (A2DP).
- Điều khiển chế độ phát nội dung nghe nhìn qua Cấu hình điều khiển từ xa (AVRCP).
- Chia sẻ danh bạ bằng Cấu hình truy cập danh bạ (PBAP).
[7.4.3/A-SR-1] Are STRONGLY RECOMMENDED to support Message Access Profile (MAP).
[7.4.5/A] SHOULD include support for cellular data connectivity.
[7.4.5/A] MAY use the System API
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
constant for networks that should be available to system apps.
Bắt đầu yêu cầu mới
If device implementations include support for AM/FM broadcast radio and expose the functionality to any application, they:
- [7.4
.10/A-0-1] MUST declare support forFEATURE_BROADCAST_RADIO
.
Kết thúc các yêu cầu mới
Camera quan sát bên ngoài là camera chụp hình các cảnh bên ngoài phạm vi triển khai thiết bị, chẳng hạn như camera lùi.
Automotive device implementations:
- PHẢI có một hoặc nhiều camera quan sát bên ngoài.
If Automotive device implementations include an exterior view camera, for such a camera, they:
- [7.5/A-1-1] KHÔNG ĐƯỢC có camera quan sát bên ngoài truy cập được qua API Máy ảnh Android, trừ phi camera đó tuân thủ các yêu cầu cốt lõi của máy ảnh.
[7.5/A-SR-1] Bạn KHÔNG NÊN xoay hoặc phản chiếu ngang bản xem trước của máy ảnh.
[7.5/A-SR-2] NÊN có độ phân giải tối thiểu là 1,3 megapixel.
SHOULD have fixed-focus or EDOF (extended depth of field) hardware.
MAY have either hardware auto-focus or software auto-focus implemented in the camera driver.
Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều camera quan sát bên ngoài và tải dịch vụ Hệ thống quan sát bên ngoài (EVS), thì đối với camera như vậy, chúng:
- [7.5/A-2-1] KHÔNG ĐƯỢC xoay hoặc phản chiếu ngang bản xem trước của máy ảnh.
Automotive device implementations:
- CÓ THỂ bao gồm một hoặc nhiều máy ảnh có sẵn cho các ứng dụng bên thứ ba.
Nếu các phương thức triển khai thiết bị ô tô bao gồm ít nhất một camera và cung cấp camera đó cho các ứng dụng bên thứ ba, thì các phương thức đó:
- [7.5/A-3-1] PHẢI báo cáo cờ tính năng
android.hardware.camera.any
. - [7.5/A-3-2] KHÔNG được khai báo máy ảnh là máy ảnh hệ thống.
- MAY support external cameras described in section 7.5.3.
- MAY include features (such as auto-focus, etc.) available to rear-facing cameras as described in section 7.5.1.
Bắt đầu yêu cầu mới
Máy ảnh mặt sau là máy ảnh quay ra ngoài, có thể được đặt ở bất kỳ vị trí nào trên xe và hướng ra bên ngoài khoang xe; tức là máy ảnh này chụp lại cảnh ở phía xa của thân xe, chẳng hạn như camera lùi.
Máy ảnh trước là máy ảnh hướng về phía người dùng, có thể được đặt ở bất kỳ vị trí nào trên xe và hướng vào bên trong khoang xe; tức là máy ảnh này chụp hình người dùng, chẳng hạn như cho ứng dụng hội nghị truyền hình và các ứng dụng tương tự.
Automotive device implementations:
- [7.5/A-SR-1] Bạn NÊN dùng một hoặc nhiều camera quay ra ngoài.
- CÓ THỂ có một hoặc nhiều máy ảnh quay về phía người dùng.
- [7.5/A-SR-2] Are STRONGLY RECOMMENDED to support concurrent streaming of multiple cameras.
If device implementations for Automotive include at least one camera facing the world, then, for such a camera, they:
- [7.5/A-1-1] PHẢI được định hướng để kích thước dài của máy ảnh phù hợp với mặt phẳng X-Y của trục cảm biến ô tô Android.
- [7.5/A-SR-3] Are STRONGLY RECOMMENDED to have either fixed-focus or EDOF (Extended Depth of Field) hardware.
- [7.5/A-1-2] PHẢI có máy ảnh chính quay ra ngoài làm máy ảnh quay ra ngoài có mã máy ảnh thấp nhất.
Nếu các phương thức triển khai thiết bị ô tô bao gồm ít nhất một camera hướng về người dùng, thì đối với camera đó:
- [7.5/A-2-1] Máy ảnh chính quay về phía người dùng PHẢI là máy ảnh quay về phía người dùng có mã máy ảnh thấp nhất.
- CÓ THỂ được định hướng để kích thước dài của máy ảnh phù hợp với mặt phẳng X-Y của trục cảm biến ô tô Android.
Nếu các phương thức triển khai thiết bị ô tô bao gồm một máy ảnh có thể truy cập được thông qua API android.hardware.Camera
hoặc android.hardware.camera2
, thì các phương thức đó:
- [7.5/A-3-1] PHẢI tuân thủ các yêu cầu chính về máy ảnh trong mục 7.5.
Nếu các phương thức triển khai thiết bị ô tô bao gồm một máy ảnh không thể truy cập được thông qua API android.hardware.Camera
hoặc android.hardware.camera2
, thì các phương thức đó:
- [7.5/A-4-1] PHẢI truy cập được thông qua dịch vụ Hệ thống chế độ xem mở rộng.
Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều camera có thể truy cập được thông qua Dịch vụ hệ thống chế độ xem mở rộng, thì đối với camera đó, các camera đó:
- [7.5/A-5-1] KHÔNG ĐƯỢC xoay hoặc phản chiếu theo chiều ngang bản xem trước của máy ảnh.
- [7.5/A-SR-4] NÊN có độ phân giải tối thiểu là 1,3 megapixel.
Nếu việc triển khai thiết bị ô tô bao gồm một hoặc nhiều máy ảnh có thể truy cập được thông qua cả Dịch vụ hệ thống chế độ xem mở rộng và API android.hardware.Camera
hoặc android.hardware.Camera2
, thì đối với máy ảnh đó, chúng:
- [7.5/A-6-1] PHẢI báo cáo cùng một Mã máy ảnh.
If device implementations provide a proprietary camera API, they:
- [7.5/A-7-1] PHẢI triển khai API máy ảnh như vậy bằng API
android.hardware.camera2
hoặc API Hệ thống chế độ xem mở rộng.
Kết thúc các yêu cầu mới
Các phương thức triển khai thiết bị ô tô:
[7.6.1/A-0-1] PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng của ứng dụng (còn gọi là phân vùng "/data").
[7.6.1/A] NÊN định dạng phân vùng dữ liệu để cải thiện hiệu suất và thời gian sử dụng trên bộ nhớ flash, ví dụ: sử dụng hệ thống tệp
f2fs
.
If Automotive device implementations provide shared external storage via a portion of the internal non-removable storage, they:
- [7.6.1/A-SR-1] Bạn NÊN giảm mức hao tổn I/O trên các thao tác được thực hiện trên bộ nhớ ngoài, chẳng hạn như bằng cách sử dụng
SDCardFS
.
If Automotive device implementations are 64-bit:
[7.6.1/A-2-1] The memory available to the kernel and userspace MUST be at least 816MB if any of the following densities are used:
- 280dpi or lower on small/normal screens
- ldpi or lower on extra large screens
- mdpi or lower on large screens
[7.6.1/A-2-2] The memory available to the kernel and userspace MUST be at least 944MB if any of the following densities are used:
- xhdpi or higher on small/normal screens
- hdpi or higher on large screens
- mdpi or higher on extra large screens
[7.6.1/A-2-3] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used:
- 400dpi or higher on small/normal screens
- xhdpi trở lên trên màn hình lớn
- tvdpi or higher on extra large screens
[7.6.1/A-2-4] The memory available to the kernel and userspace MUST be at least 1824MB if any of the following densities are used:
- 560dpi or higher on small/normal screens
- 400dpi trở lên trên màn hình lớn
- xhdpi trở lên trên màn hình cực lớn
Lưu ý rằng "bộ nhớ có sẵn cho hạt 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ư đài, video, v.v. không thuộc quyền kiểm soát của hạt nhân đối với việc triển khai thiết bị.
Automotive device implementations:
- [7.7.1/A] SHOULD include a USB port supporting peripheral mode.
Automotive device implementations:
- [7.8.1/A-0-1] MUST include a microphone.
Automotive device implementations:
- [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
Các phương thức triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng mã hoá và giải mã âm thanh sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/A-0-3] AAC ELD (enhanced low delay AAC)
Các phương thức triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng mã hoá video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
Các phương thức triển khai thiết bị ô tô PHẢI hỗ trợ các định dạng giải mã video sau đây và cung cấp các định dạng đó cho các ứng dụng bên thứ ba:
Automotive device implementations are STRONGLY RECOMMENDED to support the following video decoding:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. Phần mềm
Các phương thức triển khai thiết bị ô tô:
[3/A-0-1] PHẢI khai báo tính năng
android.hardware.type.automotive
.[3/A-0-2] PHẢI hỗ trợ uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] PHẢI hỗ trợ tất cả API công khai trong không gian tên
android.car.*
.
Nếu các phương thức triển khai thiết bị ô tô cung cấp một API độc quyền bằng cách sử dụng android.car.CarPropertyManager
với android.car.VehiclePropertyIds
, thì các phương thức đó:
- [3/A-1-1] KHÔNG ĐƯỢC đính kèm các đặc quyền đặc biệt vào việc sử dụng các thuộc tính này của ứng dụng hệ thống hoặc ngăn ứng dụng bên thứ ba sử dụng các thuộc tính này.
- [3/A-1-2] KHÔNG ĐƯỢC sao chép thuộc tính xe đã tồn tại trong SDK.
Các phương thức triển khai thiết bị ô tô:
[3.2.1/A-0-1] PHẢI hỗ trợ và thực thi tất cả các hằng số quyền như được ghi nhận trong trang tham khảo về Quyền trong Android Automotive.
[3.2.3.1/A-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
[3.4.1/A-0-1] PHẢI cung cấp một cách triển khai đầy đủ API
android.webkit.Webview
.
Bắt đầu yêu cầu mới
- [3.8/A-0-1] KHÔNG ĐƯỢC cho phép người dùng phụ toàn quyền không phải là người dùng trên nền trước hiện tại khởi chạy các hoạt động và có quyền truy cập vào giao diện người dùng trên bất kỳ màn hình nào.
Kết thúc các yêu cầu mới
[3.8.3/A-0-1] PHẢI hiển thị thông báo sử dụng API
Notification.CarExtender
khi ứng dụng bên thứ ba yêu cầu.[3.8.4/A-SR-1] Bạn nên triển khai một trợ lý trên thiết bị để xử lý Thao tác hỗ trợ.
If Automotive device implementations include a push-to-talk button, they:
- [3.8.4/A-1-1] PHẢI sử dụng thao tác nhấn ngắn vào nút nhấn để nói làm thao tác tương tác được chỉ định để chạy ứng dụng hỗ trợ do người dùng chọn, tức là ứng dụng triển khai
VoiceInteractionService
.
Automotive device implementations:
- [3.8.3.1/A-0-1] PHẢI hiển thị chính xác các tài nguyên như mô tả trong tài liệu SDK
Notifications on Automotive OS
. - [3.8.3.1/A-0-2] PHẢI hiển thị các nút PHÁT và TẮT TIẾNG cho các thao tác thông báo thay vì các thao tác được cung cấp thông qua
Notification.Builder.addAction()
- [3.8.3.1/A] NÊN hạn chế việc sử dụng các tác vụ quản lý đa dạng như các chế độ điều khiển theo kênh thông báo. CÓ THỂ sử dụng tính năng hỗ trợ giao diện người dùng cho mỗi ứng dụng để giảm các chế độ điều khiển.
If Automotive device implementations support User HAL properties, they:
- [3.9.3/A-1-1] PHẢI triển khai tất cả
Thuộc tính vòng đời người dùng
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Các phương thức triển khai thiết bị ô tô:
- [3.14/A-0-1] PHẢI bao gồm một khung giao diện người dùng để hỗ trợ các ứng dụng bên thứ ba sử dụng API đa phương tiện như mô tả trong phần 3.14.
- [3.14/A-0-2] PHẢI cho phép người dùng tương tác một cách an toàn với Ứng dụng đa phương tiện khi đang lái xe.
- [3.14/A-0-3] PHẢI hỗ trợ thao tác Ý định ngầm
CAR_INTENT_ACTION_MEDIA_TEMPLATE
bằng phần bổ sungCAR_EXTRA_MEDIA_PACKAGE
. - [3.14/A-0-4] PHẢI cung cấp một tính năng để điều hướng đến hoạt động ưu tiên của Ứng dụng đa phương tiện, nhưng PHẢI chỉ bật tính năng này khi Các hạn chế về trải nghiệm người dùng trên ô tô không có hiệu lực.
- [3.14/A-0-5] PHẢI hiển thị thông báo lỗi do Ứng dụng đa phương tiện đặt ra và PHẢI hỗ trợ các tính năng bổ sung không bắt buộc
ERROR_RESOLUTION_ACTION_LABEL
vàERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] PHẢI hỗ trợ tính năng tìm kiếm trong ứng dụng cho những ứng dụng hỗ trợ tính năng tìm kiếm.
- [3.14/A-0-7] PHẢI tuân thủ định nghĩa của
CONTENT_STYLE_BROWSABLE_HINT
vàCONTENT_STYLE_PLAYABLE_HINT
khi hiển thị hệ phân cấp MediaBrowser.
If Automotive device implementations include a default launcher app, they:
- [3.14/A-1-1] PHẢI bao gồm các dịch vụ đa phương tiện và mở các dịch vụ đó bằng ý định
CAR_INTENT_ACTION_MEDIA_TEMPLATE
.
Automotive device implementations:
- [3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để chuyển sang chế độ toàn màn hình như mô tả trong
immersive documentation
. - [3.8/A] CÓ THỂ luôn hiển thị thanh trạng thái và thanh điều hướng.
- [3.8/A] CÓ THỂ hạn chế các yêu cầu của ứng dụng để thay đổi màu sắc đằng sau các thành phần trên giao diện người dùng của hệ thống, để đảm bảo các thành phần đó luôn hiển thị rõ ràng.
2.5.4. Hiệu suất và nguồn điện
Automotive device implementations:
- [8.2/A-0-1] PHẢI báo cáo số lượng
byte được đọc và ghi vào bộ nhớ không bay hơi cho mỗi UID của quy trình để
các nhà phát triển có thể xem số liệu thống kê thông qua API hệ thống
android.car.storagemonitoring.CarStorageMonitoringManager
. The Android Open Source Project meets the requirement through theuid_sys_stats
kernel module. - [8.3/A-1-3] PHẢI hỗ trợ Chế độ gara.
- [8.3/A] NÊN ở Chế độ gara ít nhất 15 phút sau mỗi lần lái xe, trừ phi:
- Pin đã hết.
- Không có công việc nào ở trạng thái rảnh được lên lịch.
- Trình điều khiển thoát khỏi Chế độ nhà để xe.
- [8.4/A-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
- [8.4/A-0-2] PHẢI báo cáo tất cả các giá trị tiêu thụ điện năng bằng miliampe giờ (mAh).
- [8.4/A-0-3] PHẢI báo cáo mức tiêu thụ điện năng của CPU theo UID của từng quy trình. The Android Open Source Project meets the
requirement through the
uid_cputime
kernel module implementation. - [8.4/A] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
- [8.4/A-0-4] PHẢI cung cấp mức sử dụng pin này cho nhà phát triển ứng dụng thông qua lệnh shell
adb shell dumpsys batterystats
.
2.5.5. Mô hình bảo mật
If Automotive device implementations support multiple users, they:
- [9.5/A-1-1] KHÔNG ĐƯỢC cho phép người dùng tương tác với hoặc chuyển sang Người dùng hệ thống không có giao diện người dùng, ngoại trừ cung cấp thiết bị.
- [9.5/A-1-2] PHẢI chuyển sang Người dùng phụ trước
BOOT_COMPLETED
. - [9.5/A-1-3] PHẢI hỗ trợ khả năng tạo Người dùng khách ngay cả khi đã đạt đến số lượng Người dùng tối đa trên một thiết bị.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị Automotive khai báo android.hardware.microphone
, thì các phương thức đó:
- [9.8.2/A-1-1] PHẢI hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không được hiển thị khi micrô chỉ được
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
hoặc các ứng dụng giữ vai trò được nêu trong mục 9.1 truy cập bằng giá trị nhận dạng CDD [C-4-X]. - [9.8.2/A-1-2] KHÔNG được ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc có hoạt động tương tác trực tiếp với người dùng.
- [9.8.2/A-1-3] PHẢI cung cấp cho người dùng khả năng bật/tắt micrô trong ứng dụng Cài đặt.
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị Automotive khai báo android.hardware.camera.any
, thì
các phương thức đó:
- [9.8.2/A-2-1] PHẢI hiển thị chỉ báo máy ảnh khi một ứng dụng đang truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không phải khi(các) ứng dụng có vai trò như đã xác định
được gọi ratrong Mục 9.1 Quyền với giá trị nhận dạng CDD [C-4-X][C-3-X]. - [9.8.2/A-2-2] KHÔNG ĐƯỢC ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc tương tác trực tiếp với người dùng.
Bắt đầu yêu cầu mới
- [9.8.2/A-2-3] PHẢI cung cấp cho người dùng khả năng bật/tắt máy ảnh trong ứng dụng Cài đặt.
- [9.8.2/A-2-4] PHẢI hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng máy ảnh được trả về từ
PermissionManager.getIndicatorAppOpUsageData()
, cùng với mọi thông báo phân bổ liên quan đến các ứng dụng đó.
Kết thúc các yêu cầu mới
Automotive device implementations:
- [9/A-0-1] PHẢI khai báo tính năng
android.hardware.security.model.compatible
. - [9.11/A-0-1] PHẢI sao lưu quá trình triển khai kho khoá bằng một môi trường thực thi riêng biệt.
- [9.11/A-0-2] PHẢI triển khai các thuật toán mã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên nhân và các cấp cao hơn. Tính năng cô lập an toàn PHẢI chặn tất cả các cơ chế tiềm ẩn mà qua đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường được cô lập, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một giải pháp triển khai bảo mật được bên thứ ba xem xét dựa trên một máy ảo thích hợp là các lựa chọn thay thế.
- [9.11/A-0-3] PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi tách biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Thông tin xác thực trên màn hình khoá PHẢI được lưu trữ theo cách chỉ cho phép môi trường thực thi riêng biệt thực hiện quy trình xác thực trên màn hình khoá. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can be used to satisfy this requirement.
- [9.11/A-0-4] PHẢI hỗ trợ quy trình chứng thực khoá, trong đó khoá ký chứng thực được bảo vệ bằng phần cứng bảo mật và quy trình ký được thực hiện trong phần cứng bảo mật. Các khoá ký chứng thực PHẢI được chia sẻ trên một số lượng thiết bị đủ lớn để ngăn việc các khoá này được dùng làm giá trị nhận dạng thiết bị. Một cách để đáp ứng yêu cầu này là chia sẻ cùng một khoá chứng thực,trừ phi bạn sản xuất ít nhất 100.000 đơn vị của một SKU nhất định. Nếu bạn sản xuất hơn 100.000 đơn vị của một SKU, thì bạn CÓ THỂ sử dụng một khoá khác cho mỗi 100.000 đơn vị.
Xin lưu ý rằng nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ, thì thiết bị đó sẽ được miễn yêu cầu phải có kho khoá được môi trường thực thi tách biệt hỗ trợ và hỗ trợ chứng thực khoá, trừ phi thiết bị đó khai báo tính năng android.hardware.fingerprint
yêu cầu kho khoá được môi trường thực thi tách biệt hỗ trợ.
Automotive device implementations:
- [9.14/A-0-1] PHẢI kiểm soát thông báo từ các hệ thống con của xe trong khung Android, ví dụ: đưa vào danh sách cho phép các loại thông báo và nguồn thông báo được phép.
- [9.14/A-0-2] PHẢI giám sát các cuộc tấn công từ chối dịch vụ từ khung Android hoặc ứng dụng bên thứ ba. Điều này giúp bảo vệ khỏi phần mềm độc hại làm ngập mạng xe bằng lưu lượng truy cập, từ đó có thể dẫn đến các hệ thống con của xe hoạt động không đúng cách.
2.5.6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển
Các phương thức triển khai thiết bị ô tô:
- Perfetto
- [6.1/A-0-1] PHẢI hiển thị tệp nhị phân
/system/bin/perfetto
cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto. - [6.1/A-0-2] Tệp nhị phân perfetto PHẢI chấp nhận cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto làm dữ liệu đầu vào.
- [6.1/A-0-3] Tệp nhị phân perfetto PHẢI ghi dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [6.1/A-0-4] PHẢI cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [6.1/A-0-1] PHẢI hiển thị tệp nhị phân
2.6. Yêu cầu đối với máy tính bảng
Thiết bị Android Tablet là một cách triển khai thiết bị Android thường đáp ứng tất cả các tiêu chí sau:
- Sử dụng bằng cách cầm bằng cả hai tay.
- Không có cấu hình dạng vỏ sò hoặc có thể chuyển đổi.
- Các phương thức triển khai bàn phím thực tế được sử dụng với thiết bị kết nối bằng phương thức kết nối tiêu chuẩn (ví dụ: USB, Bluetooth).
Có nguồn điện để di chuyển, chẳng hạn như pin.
Có kích thước màn hình lớn hơn 7 inch và nhỏ hơn 18 inch, đo theo đường chéo.
Việc triển khai thiết bị máy tính bảng có các yêu cầu tương tự như việc triển khai thiết bị cầm tay. Các trường hợp ngoại lệ được biểu thị bằng dấu * trong phần đó và được ghi chú để tham khảo trong phần này.
2.6.1. Phần cứng
Con quay hồi chuyển
If Tablet device implementations include a 3-axis gyroscope, they:
- [7.3.4/Tab-1-1] PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1.000 độ mỗi giây.
Minimum Memory and Storage (Section 7.6.1)
The screen densities listed for small/normal screens in the handheld requirements are not applicable to tablets.
USB peripheral mode (Section 7.7.1)
If tablet device implementations include a USB port supporting peripheral mode, they:
- [7.7.1/Tab] MAY implement the Android Open Accessory (AOA) API.
Virtual Reality Mode (Section 7.9.1)
Virtual Reality High Performance (Section 7.9.2)
Virtual reality requirements are not applicable to tablets.
2.6.2. Mô hình bảo mật
Khoá và thông tin xác thực (Mục 9.11)
Hãy tham khảo Mục [9.11].
If Tablet device implementations include multiple users and
do not declare the android.hardware.telephony
feature flag, they:
- [9.5/T-1-1] PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.
If Tablet device implementations include multiple users and
declare the android.hardware.telephony
feature flag, they:
- [9.5/T-2-1] KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ kiểm soát của AOSP để bật /tắt quyền truy cập của người dùng khác vào cuộc gọi thoại và tin nhắn SMS.
2.6.2. Phần mềm
- [3.2.3.1/Tab-0-1] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây.
3. Phần mềm
3.1. Khả năng tương thích với API được quản lý
Môi trường thực thi mã byte Dalvik được quản lý là phương tiện chính cho các ứng dụng Android. Giao diện lập trình ứng dụng Android (API) là tập hợp các giao diện nền tảng Android hiển thị cho các ứng dụng chạy trong môi trường thời gian chạy được quản lý.
Device implementations:
[C-0-1] MUST provide complete implementations, including all documented behaviors, of any API documented and exposed by the Android SDK or any API decorated with the “@SystemApi” marker in the upstream Android source code.
[C-0-2] MUST support/preserve all classes, methods, and associated elements marked by the TestApi annotation (@TestApi).
[C-0-3] KHÔNG ĐƯỢC bỏ qua bất kỳ API nào được quản lý, thay đổi giao diện hoặc chữ ký API, bỏ qua hành vi được ghi nhận hoặc bao gồm các thao tác không hoạt động, ngoại trừ trường hợp được Định nghĩa về khả năng tương thích này cho phép.
[C-0-4] VẪN PHẢI duy trì các API và hoạt động một cách hợp lý, ngay cả khi một số tính năng phần cứng mà Android bao gồm các API bị bỏ qua. See section 7 for specific requirements for this scenario.
[C-0-5] KHÔNG ĐƯỢC cho phép ứng dụng bên thứ ba sử dụng các giao diện không phải SDK. Các giao diện này được xác định là các phương thức và trường trong các gói ngôn ngữ Java nằm trong đường dẫn lớp khởi động trong AOSP và không thuộc SDK công khai. Điều này bao gồm các API được trang trí bằng chú thích
@hide
nhưng không phải bằng@SystemAPI
, như mô tả trong tài liệu SDK và các thành viên lớp riêng tư và gói riêng tư.[C-0-6] PHẢI đi kèm với mọi giao diện không phải SDK trong cùng một danh sách bị hạn chế như được cung cấp thông qua cờ danh sách tạm thời và danh sách từ chối trong đường dẫn
prebuilts/runtime/appcompat/hiddenapi-flags.csv
cho nhánh cấp độ API thích hợp trong AOSP.[C-0-7] PHẢI hỗ trợ cơ chế cập nhật động cấu hình đã ký để xoá các giao diện không phải SDK khỏi danh sách bị hạn chế bằng cách nhúng cấu hình đã ký vào bất kỳ tệp APK nào, sử dụng các khoá công khai hiện có trong AOSP.
Tuy nhiên, các chiến dịch này:
- MAY, if a hidden API is absent or implemented differently on the device implementation, move the hidden API into the denylist or omit it from all restricted lists.
- MAY, if a hidden API is absent or implemented differently on the device implementation, move the hidden API into the blacklist or omit it from all restricted lists (i.e. light-grey, dark-grey, black).
Bắt đầu yêu cầu mới
- [C-0-8] KHÔNG ĐƯỢC hỗ trợ cài đặt các ứng dụng nhắm đến cấp độ API thấp hơn 23.
Kết thúc các yêu cầu mới
3.1.1. Tiện ích Android
Android hỗ trợ mở rộng giao diện API được quản lý của một cấp độ API cụ thể bằng cách cập nhật phiên bản tiện ích cho cấp độ API đó. API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
trả về phiên bản tiện ích của apiLevel
được cung cấp, nếu có tiện ích cho cấp độ API đó.
Cách triển khai trên thiết bị Android:
[C-0-1] PHẢI tải trước cách triển khai AOSP của cả thư viện dùng chung
ExtShared
và dịch vụExtServices
có phiên bản cao hơn hoặc bằng phiên bản tối thiểu được phép cho mỗi cấp độ API. Ví dụ: các hoạt động triển khai thiết bị Android 7.0, chạy API cấp 24 PHẢI bao gồm ít nhất phiên bản 1.[C-0-2] CHỈ ĐƯỢC trả về số phiên bản tiện ích hợp lệ do AOSP xác định.
[C-0-3] PHẢI hỗ trợ tất cả các API do các phiên bản tiện ích xác định do
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
trả về theo cách tương tự như các API được quản lý khác được hỗ trợ, tuân theo các yêu cầu trong mục 3.1.
3.1.2. Thư viện Android
Do ngừng sử dụng ứng dụng Apache HTTP, các hoạt động triển khai thiết bị:
- [C-0-1] KHÔNG ĐƯỢC đặt thư viện
org.apache.http.legacy
vào bootclasspath. - [C-0-2] MUST add the
org.apache.http.legacy
library to the classpath của ứng dụng chỉ khi ứng dụng đáp ứng một trong các điều kiện sau:- Nhắm đến API cấp 28 trở xuống.
- Khai báo trong tệp kê khai rằng ứng dụng cần thư viện bằng cách đặt thuộc tính
android:name
của<uses-library>
thànhorg.apache.http.legacy
.
The AOSP implementation meets these requirements.
3.2. Khả năng tương thích mềm của API
Ngoài các API được quản lý trong mục 3.1, Android cũng bao gồm một API "mềm" quan trọng chỉ có trong thời gian chạy, dưới dạng các ý định, quyền và các 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ả các hằng số quyền như được ghi nhận trong Trang tham khảo về quyền. Lưu ý rằng mục 9 liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật của Android.
3.2.2. Tham số bản dựng
Các API Android bao gồm một số hằng số trên lớp android.os.Build dùng để mô tả thiết bị hiện tại.
- [C-0-1] Để cung cấp các giá trị nhất quán và có ý nghĩa trên các phương thức triển khai thiết bị, bảng bên dưới bao gồm các quy định hạn chế bổ sung về định dạng của các giá trị này mà phương thức triển khai thiết bị PHẢI tuân thủ.
Thông số | Thông tin chi tiết |
---|---|
VERSION.RELEASE | Phiên bản của hệ thống Android đang chạy, ở định dạng mà con người có thể đọc được. Trường này PHẢI có một trong các giá trị chuỗi được xác định trong phần Chuỗi phiên bản được phép cho Android 14. |
VERSION.SDK | Phiên bản của hệ thống Android đang chạy, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 14, trường này PHẢI có giá trị số nguyên 14_INT. |
VERSION.SDK_INT | Phiên bản của hệ thống Android đang chạy, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 14, trường này PHẢI có giá trị số nguyên 14_INT. |
VERSION.INCREMENTAL | A value chosen by the device implementer designating the specific build of the currently-executing Android system, in human-readable format. Bạn KHÔNG ĐƯỢC sử dụng lại giá trị này cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Một cách sử dụng phổ biến của trường này là cho biết số bản dựng hoặc giá trị nhận dạng thay đổi trong hệ thống quản lý nguồn đã được dùng để tạo bản dựng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit có thể in và khớp với biểu thức chính quy “^[^ :\/~]+$”. |
BẢNG | A value chosen by the device implementer identifying the specific internal hardware used by the device, in human-readable format. Bạn có thể sử dụng trường này để cho biết bản sửa đổi cụ thể của bảng điều khiển cung 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 | A value reflecting the brand name associated with the device as known to the end users. PHẢI ở định dạng mà con người có thể đọc được và NÊN đại diện cho nhà sản xuất thiết bị hoặc thương hiệu công ty mà thiết bị được tiếp thị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9_-]+$". |
SUPPORTED_ABIS | Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem phần 3.3. Khả năng tương thích với API gốc. |
SUPPORTED_32_BIT_ABIS | Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem phần 3.3. Khả năng tương thích với API gốc. |
SUPPORTED_64_BIT_ABIS | Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem phần 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 phần 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 phần 3.3. Khả năng tương thích với API gốc. |
THIẾT BỊ | A value chosen by the device implementer containing the development name or code name identifying the configuration of the hardware features and industrial design of the device. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”. Tên thiết bị này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm. |
VÂN TAY | Một chuỗi nhận dạng duy nhất bản dựng này. Tên này PHẢI dễ đọc. Tên phải tuân theo mẫu sau:
$(BRAND)/$(PRODUCT)/ Ví dụ: acme/myproduct/ Vân tay KHÔNG ĐƯỢC chứa ký tự khoảng trắng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit. |
PHẦN CỨNG | Tên của phần cứng (từ dòng lệnh hạt nhân hoặc /proc). Tên này ĐƯỢC PHÉP 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_-]+$”. |
MÁY CHỦ | Một chuỗi nhận dạng duy nhất máy chủ lưu trữ mà bản dựng được tạo, ở định dạng mà con người đọc được. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC để trống hoặc chứa chuỗi trống (""). |
ID | Giá trị nhận dạng do người triển khai thiết bị chọn để tham chiếu đến một bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống với android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị đủ ý nghĩa để người dùng cuối có thể phân biệt giữa các bản dựng phần mềm. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+$”. |
NHÀ SẢN XUẤT | Tên thương mại của Nhà sản xuất thiết bị gốc (OEM) của sản phẩm. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chứa chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm. |
SOC_MANUFACTURER | Tên thương mại của nhà sản xuất hệ thống trên chip (SOC) chính được sử dụng trong sản phẩm. Các thiết bị có cùng nhà sản xuất SOC phải sử dụng cùng một giá trị không đổi. Vui lòng hỏi nhà sản xuất SOC về hằng số chính xác cần sử dụng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit, PHẢI khớp với biểu thức chính quy “^([0-9A-Za-z ]+)”, KHÔNG ĐƯỢC bắt đầu hoặc kết thúc bằng dấu cách và KHÔNG ĐƯỢC bằng “unknown”. Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm. |
SOC_MODEL | Tên mô hình của hệ thống chính trên chip (SOC) dùng trong sản phẩm. Các thiết bị có cùng mô hình SOC phải sử dụng cùng một giá trị không đổi. Vui lòng hỏi nhà sản xuất SOC về hằng số chính xác cần sử dụng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^([0-9A-Za-z ._/+-]+)$”, KHÔNG ĐƯỢC bắt đầu hoặc kết thúc bằng dấu cách và KHÔNG ĐƯỢC bằng "unknown". Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm. |
KIỂU MÁY | A value chosen by the device implementer containing the name of the device as known to the end user. Đây PHẢI là tên mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chứa chuỗi trống (""). Trường này KHÔNG ĐƯỢC thay đổi trong suốt thời gian tồn tại của sản phẩm. |
SẢN PHẨM | A value chosen by the device implementer containing the development name or code name of the specific product (SKU) that MUST be unique within the same brand. PHẢI là văn bản mà con người có thể đọc được, nhưng không nhất thiết là để người dùng cuối xem. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”. This product name MUST NOT change during the lifetime of the product. |
ODM_SKU | Giá trị không bắt buộc do người triển khai thiết bị chọn, chứa SKU (Mã đơn vị lưu kho) dùng để theo dõi các cấu hình cụ thể của thiết bị, ví dụ: mọi thiết bị ngoại vi đi kèm với thiết bị khi bán.
Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | PHẢI trả về "UNKNOWN". |
THẺ TỪ KHOÁ | Danh sách các thẻ được phân tách bằng dấu phẩy do người triển khai thiết bị chọn để phân biệt rõ hơn bản dựng. Các thẻ PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+” và PHẢI có một trong các giá trị tương ứng với 3 cấu hình ký tên nền tảng Android thông thường: khoá phát hành, khoá nhà phát triển và khoá kiểm thử. |
THỜI GIAN | A value representing the timestamp of when the build occurred. |
LOẠI | A value chosen by the device implementer specifying the runtime configuration of the build. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình thời gian chạy Android thông thường: user, userdebug hoặc eng. |
NGƯỜI DÙNG | Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) đã tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC để trống hoặc chứa chuỗi trống (""). |
SECURITY_PATCH | A value indicating the security patch level of a build. Tệp này PHẢI cho biết rằng bản dựng không gặp phải bất kỳ vấn đề nào được mô tả trong Bản tin công khai về bảo mật Android được chỉ định. Ngày phát hành PHẢI ở định dạng [YYYY-MM-DD], khớp với một chuỗi đã xác định được ghi lại trong Bản tin bảo mật công khai của Android hoặc trong Thông báo bảo mật của Android, ví dụ: "2015-11-01". |
BASE_OS | Một giá trị đại diện cho tham số FINGERPRINT của bản dựng giống hệt bản dựng này ngoại trừ các bản vá được cung cấp trong Bản tin bảo mật công khai của Android. Phương thức này PHẢI báo cáo giá trị chính xác và nếu không có bản dựng nào như vậy, hãy báo cáo một chuỗi trống (""). |
BOOTLOADER | A value chosen by the device implementer identifying the specific internal bootloader version used in the device, in human-readable format. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”. |
getRadioVersion() | PHẢI (là hoặc trả về) một giá trị do nhà triển khai thiết bị chọn để xác định phiên bản radio/mô-đun nội bộ cụ thể được sử dụng trong thiết bị, ở định dạng mà con người có thể đọc được. Nếu thiết bị không có đài/mô-đun nội bộ, 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() | MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9]+$”. |
3.2.3. Khả năng tương thích với ý định
3.2.3.1. Ý định phổ biến của ứng dụng
Ý định Android cho phép các thành phần ứng dụng yêu cầu chức năng từ các thành phần Android khác. Dự án Android ngược dòng bao gồm danh sách các ứng dụng triển khai một số mẫu ý định để thực hiện các thao tác phổ biến.
Device implementations:
- [C-SR-1] Bạn NÊN tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định, cho tất cả các mẫu bộ lọc ý định công khai do các ý định ứng dụng sau đây xác định được liệt kê tại đây và cung cấp phương thức thực hiện, tức là đáp ứng kỳ vọng của nhà phát triển đối với các ý định ứng dụng phổ biến này như mô tả trong SDK.
Vui lòng tham khảo Mục 2 để biết ý định bắt buộc của ứng dụng cho từng loại thiết bị.
3.2.3.2. Độ phân giải ý định
[C-0-1] Vì Android là một nền tảng có thể mở rộng, nên các phương thức triển khai thiết bị PHẢI cho phép các ứng dụng bên thứ ba ghi đè từng mẫu ý định được tham chiếu trong mục 3.2.3.1, ngoại trừ phần Cài đặt. Theo mặc định, việc triển khai nguồn mở Android ngược dòng cho phép điều này.
[C-0-2] Nhà triển khai thiết bị KHÔNG ĐƯỢC đính kèm các đặc quyền đặc biệt vào việc sử dụng các mẫu ý định này của ứng dụng hệ thống, hoặc ngăn ứng dụng bên thứ ba liên kết và giả định quyền kiểm soát các mẫu này. Quy định cấm này bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng "Công cụ chọn" cho phép người dùng chọn giữa nhiều ứng dụng đều xử lý cùng một mẫu ý định.
[C-0-3] Device implementations MUST provide a user interface for users to modify the default activity for intents.
Tuy nhiên, việc triển khai thiết bị CÓ THỂ cung cấp các hoạt động mặc định cho các mẫu URI cụ thể (ví dụ: http://play.google.com) khi hoạt động mặc định cung cấp một thuộc tính cụ thể hơn cho URI dữ liệu. Ví dụ: mẫu bộ lọc ý định chỉ định URI dữ liệu "http://www.android.com" sẽ cụ thể hơn mẫu ý định cốt lõi của trình duyệt cho "http://".
Android cũng bao gồm một cơ chế để các ứng dụng bên thứ ba khai báo hành vi liên kết ứng dụng mặc định có thẩm quyền cho một số loại ý định URI web. Khi các nội dung khai báo có thẩm quyền như vậy được xác định trong mẫu bộ lọc ý định của ứng dụng, quá trình triển khai thiết bị sẽ:
- [C-0-4] MUST attempt to validate any intent filters by performing the validation steps defined in the Digital Asset Links specification as implemented by the Package Manager in the upstream Android Open Source Project.
- [C-0-5] PHẢI thử xác thực các bộ lọc ý định trong quá trình cài đặt ứng dụng và đặt tất cả bộ lọc ý định URI đã xác thực thành công làm trình xử lý ứng dụng mặc định cho URI của chúng.
- MAY set specific URI intent filters as default app handlers for their URIs, if they are successfully verified but other candidate URI filters fail verification. Nếu một phương thức triển khai thiết bị thực hiện việc này, thì phương thức đó PHẢI cung cấp cho người dùng các cơ chế ghi đè mẫu URI phù hợp trong trình đơn cài đặt.
- MUST provide the user with per-app App Links controls in Settings as
follows:
- [C-0-6] Người dùng PHẢI có thể ghi đè toàn diện hành vi liên kết ứng dụng mặc định để ứng dụng: luôn mở, luôn hỏi hoặc không bao giờ mở, đồng thời phải áp dụng như nhau cho tất cả bộ lọc ý định URI đề xuất.
- [C-0-7] Người dùng PHẢI xem được danh sách bộ lọc ý định URI đề xuất.
- Việc triển khai thiết bị CÓ THỂ cho phép người dùng ghi đè các bộ lọc ý định URI đề xuất cụ thể đã được xác minh thành công, trên cơ sở mỗi bộ lọc ý định.
- [C-0-8] The device implementation MUST provide users with the ability to view and override specific candidate URI intent filters if the device implementation lets some candidate URI intent filters succeed verification while some others can fail.
3.2.3.3. Không gian tên ý định
- [C-0-1] Device implementations MUST NOT include any Android component that honors any new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key string in the android.* or com.android.* namespace.
- [C-0-2] Device implementers MUST NOT include any Android components that honor any new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key string in a package space belonging to another organization.
- [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 liệt kê trong mục 3.2.3.1.
- Việc triển khai thiết bị CÓ THỂ bao gồm các mẫu ý định sử dụng không gian tên được liên kết rõ ràng và rõ ràng với tổ chức của riêng thiết bị. Quy định cấm này tương tự như quy định cấm đối với các lớp ngôn ngữ Java trong mục 3.6.
3.2.3.4. Ý định truyền tin
Các ứng dụng bên thứ ba dựa vào nền tảng để truyền tin một số ý định nhất định nhằm thông báo cho chúng về những thay đổi trong môi trường phần cứng hoặc phần mềm.
Device implementations:
- [C-0-1] PHẢI truyền tin các ý định truyền tin công khai được liệt kê tại đây để phản hồi các sự kiện hệ thống thích hợp như mô tả trong tài liệu SDK. Lưu ý rằng yêu cầu này không xung đột với mục 3.5 vì giới hạn đối với ứng dụng chạy nền cũng được mô tả trong tài liệu SDK. Ngoài ra, một số ý định truyền tin nhất định còn phụ thuộc vào khả năng hỗ trợ phần cứng. Nếu thiết bị hỗ trợ phần cứng cần thiết, thì các ý định đó PHẢI truyền tin và cung cấp hành vi phù hợp với tài liệu SDK.
3.2.3.5. Ý định của ứng dụng có điều kiện
Android bao gồm các chế độ cài đặt giúp người dùng dễ dàng chọn ứng dụng mặc định, chẳng hạn như cho Màn hình chính hoặc SMS.
Where it makes sense, device implementations MUST provide a similar settings menu and be compatible with the intent filter pattern and API methods described in the SDK documentation as below.
If device implementations report android.software.home_screen
, they:
- [C-1-1] MUST honor the
android.settings.HOME_SETTINGS
intent to show a default app settings menu for Home Screen.
If device implementations report android.hardware.telephony.calling
, they:
[C-2-1] MUST provide a settings menu that will call the
android.provider.Telephony.ACTION_CHANGE_DEFAULT
intent to show a dialog to change the default SMS application.[C-2-2] MUST honor the
android.telecom.action.CHANGE_DEFAULT_DIALER
intent to show a dialog to allow the user to change the default application Phone.- MUST use the user-selected default Phone app's UI for incoming and outgoing calls except for emergency calls, which would use the preinstalled Phone app.
[C-2-3] PHẢI tuân thủ ý định android.telecom.action.CHANGE_PHONE_ACCOUNTS để cung cấp cho người dùng khả năng định cấu hình
ConnectionServices
liên kết vớiPhoneAccounts
, cũng như một PhoneAccount mặc định mà nhà cung cấp dịch vụ viễn thông sẽ sử dụng để thực hiện cuộc gọi đi. Cách triển khai AOSP đáp ứng yêu cầu này bằng cách đưa trình đơn "Calling Accounts option" (Tuỳ chọn tài khoản gọi điện) vào trình đơn cài đặt "Calls" (Cuộc gọi).[C-2-4] PHẢI cho phép
android.telecom.CallRedirectionService
đối với một ứng dụng có vai tròandroid.app.role.CALL_REDIRECTION
.[C-2-5] PHẢI cung cấp cho người dùng khả năng chọn một ứng dụng có vai trò
android.app.role.CALL_REDIRECTION
.[C-2-6] PHẢI tuân thủ ý định android.intent.action.SENDTO và android.intent.action.VIEW, đồng thời cung cấp một hoạt động để gửi/hiển thị tin nhắn SMS.
[C-SR-1] Bạn NÊN tuân thủ các ý định android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL bằng một ứng dụng quay số được tải trước có thể xử lý các ý định này và cung cấp phương thức thực hiện như mô tả trong SDK.
If device implementations report android.hardware.nfc.hce
, they:
- [C-3-1] MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default app settings menu for Contactless payment.
- [C-3-2] PHẢI tuân thủ ý định android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT để hiển thị một hoạt động mở hộp thoại yêu cầu người dùng thay đổi dịch vụ mô phỏng thẻ mặc định cho một danh mục nhất định như mô tả trong SDK.
If device implementations report android.hardware.nfc
, they:
- [C-4-1] PHẢI tuân thủ các ý định này android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, để hiển thị một hoạt động đáp ứng kỳ vọng của nhà phát triển đối với các ý định này như mô tả trong SDK.
If device implementations report android.hardware.bluetooth
, they:
- [C-5-1] PHẢI tuân thủ ý định "android.bluetooth.adapter.action.REQUEST_ENABLE" và hiển thị một hoạt động hệ thống để cho phép người dùng bật Bluetooth.
- [C-5-2] PHẢI tuân thủ ý định "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" và hiển thị một hoạt động hệ thống yêu cầu chế độ có thể phát hiện.
If device implementations support the DND feature, they:
- [C-6-1] PHẢI triển khai một hoạt động phản hồi ý định
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
. Đối với các hoạt động triển khai có UI_MODE_TYPE_NORMAL, PHẢI là một hoạt động mà người dùng có thể cấp hoặc từ chối quyền truy cập của ứng dụng vào cấu hình chính sách DND.
If device implementations allow users to use third-party input methods on the device, they:
- [C-7-1] PHẢI cung cấp một cơ chế mà người dùng có thể truy cập để thêm và định cấu hình các phương thức nhập của bên thứ ba theo ý định
android.settings.INPUT_METHOD_SETTINGS
.
If device implementations support third-party accessibility services, they:
- [C-8-1] PHẢI tuân thủ ý định
android.settings.ACCESSIBILITY_SETTINGS
để cung cấp cơ chế mà người dùng có thể truy cập nhằm bật và tắt các dịch vụ hỗ trợ tiếp cận của bên thứ ba cùng với các dịch vụ hỗ trợ tiếp cận được tải trước.
If device implementations include support for Wi-Fi Easy Connect and expose the functionality to third-party apps, they:
- [C-9-1] PHẢI triển khai các API Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent như mô tả trong tài liệu SDK.
If device implementations provide the data saver mode, they:
- [C-10-1] PHẢI cung cấp giao diện người dùng trong phần cài đặt để xử lý ý định
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, cho phép người dùng thêm hoặc xoá ứng dụng khỏi danh sách cho phép.
If device implementations do not provide the data saver mode, they:
- [C-11-1] PHẢI có một hoạt động xử lý ý định
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
nhưng CÓ THỂ triển khai hoạt động đó dưới dạng không hoạt động.
Nếu các phương thức triển khai thiết bị khai báo hỗ trợ máy ảnh thông qua android.hardware.camera.any
, thì các phương thức đó:
- [C-12-3] PHẢI xử lý và PHẢI chỉ cho phép các ứng dụng Android được cài đặt sẵn xử lý các ý định sau đây
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
vàMediaStore.ACTION_VIDEO_CAPTURE
như mô tả trong tài liệu SDK.
If device implementations report android.software.device_admin
, they:
[C-13-1] PHẢI tuân thủ ý định
android.app.action.ADD_DEVICE_ADMIN
để gọi giao diện người dùng hướng dẫn người dùng thêm quản trị viên thiết bị vào hệ thống (hoặc cho phép họ từ chối).[C-13-2] PHẢI tuân thủ các ý định android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD và android.app.action.START_ENCRYPTION, đồng thời có một hoạt động để thực hiện các ý định này như mô tả trong SDK tại đây.
If device implementations declare the android.software.autofill
feature flag, they:
- [C-14-1] MUST fully implement the
AutofillService
andAutofillManager
APIs and honor the android.settings.REQUEST_SET_AUTOFILL_SERVICE intent to show a default app settings menu to enable and disable autofill and change the default autofill service for the user.
If device implementations include a pre-installed app or wish to allow third-party apps to access the usage statistics, they:
- [C-SR-2] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant
or revoke access to the usage stats in response to the
android.settings.ACTION_USAGE_ACCESS_SETTINGS
intent for apps that declare the
android.permission.PACKAGE_USAGE_STATS
permission.
If device implementations intend to disallow any apps, including pre-installed apps, from accessing the usage statistics, they:
- [C-15-1] VẪN PHẢI có một hoạt động xử lý mẫu ý định android.settings.ACTION_USAGE_ACCESS_SETTINGS nhưng PHẢI triển khai hoạt động đó dưới dạng không hoạt động, tức là có hành vi tương đương như khi người dùng từ chối quyền truy cập.
Nếu hoạt động triển khai thiết bị hiển thị các đường liên kết đến các hoạt động do AutofillService_passwordsActivity chỉ định trong phần Cài đặt hoặc các đường liên kết đến mật khẩu người dùng thông qua một cơ chế tương tự, thì các hoạt động đó:
- [C-16-1] PHẢI hiển thị các đường liên kết đó cho tất cả các dịch vụ tự động điền đã cài đặt.
If device implementations support the VoiceInteractionService
and have more than một ứng dụng sử dụng API này được cài đặt cùng một lúc, thì:
- [C-18-1] MUST honor the
android.settings.ACTION_VOICE_INPUT_SETTINGS
intent to show a default app settings menu for voice input and assist.
If device implementations report the feature android.hardware.audio.output
,
they:
- [C-SR-3] Bạn NÊN tuân thủ các ý định android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT có một hoạt động để cung cấp thực hiện cho các ý định này như mô tả trong SDK tại đây.
Android hỗ trợ trình bảo vệ màn hình tương tác, trước đây gọi là Dreams. Trình bảo vệ màn hình cho phép người dùng tương tác với các ứng dụng khi thiết bị được kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế sạc trên bàn. Triển khai thiết bị:
- NÊN hỗ trợ trình bảo vệ màn hình và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình trình bảo vệ màn hình theo ý định
android.settings.DREAM_SETTINGS
.
Bắt đầu yêu cầu mới
If device implementations report android.hardware.nfc.uicc
or android.hardware.nfc.ese
,
they:
- [C-19-1] PHẢI triển khai API NfcAdapter.ACTION_TRANSACTION_DETECTED (dưới dạng "EVT_TRANSACTION" do quy cách kỹ thuật TS.26 của Hiệp hội GSM – Yêu cầu đối với thiết bị cầm tay NFC).
Kết thúc các yêu cầu mới
3.2.4. Hoạt động trên màn hình phụ/nhiều màn hình
If device implementations allow launching normal Android Activities on more than one display, they:
- [C-1-1] MUST set the
android.software.activities_on_secondary_displays
feature flag. - [C-1-2] PHẢI đảm bảo khả năng tương thích của API tương tự như một hoạt động chạy trên màn hình chính.
- [C-1-3] PHẢI đưa hoạt động mới vào cùng một màn hình với hoạt động đã khởi chạy hoạt động đó, khi hoạt động mới được khởi chạy mà không chỉ định màn hình mục tiêu thông qua API
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] PHẢI huỷ bỏ tất cả hoạt động khi một màn hình có cờ
Display.FLAG_PRIVATE
bị xoá. - [C-1-5] PHẢI ẩn nội dung một cách an toàn trên tất cả màn hình khi thiết bị được khoá bằng màn hình khoá bảo mật, trừ phi ứng dụng chọn hiển thị trên đầu màn hình khoá bằng API
Activity#setShowWhenLocked()
. - SHOULD have
android.content.res.Configuration
which corresponds to that display in order to be displayed, operate correctly, and maintain compatibility if an activity is launched on secondary display.
If device implementations allow launching normal Android Activities on secondary displays and a secondary display has the android.view.Display.FLAG_PRIVATE flag:
- [C-3-1] Chỉ chủ sở hữu của màn hình, hệ thống và các hoạt động đã có trên màn hình đó mới có thể khởi chạy màn hình đó. Mọi người đều có thể khởi chạy trên màn hình có cờ android.view.Display.FLAG_PUBLIC.
3.3. Khả năng tương thích với API gốc
Khả năng tương thích của mã gốc là một thách thức. Vì lý do này, người triển khai thiết bị là:
- [C-SR-1] STRONGLY RECOMMENDED to use the implementations of the libraries listed below from the upstream Android Open Source Project.
3.3.1. Giao diện nhị phân của ứng dụng
Mã byte Dalvik được quản lý có thể gọi vào mã gốc được cung cấp trong tệp .apk
của ứng dụng dưới dạng tệp .so
ELF được biên dịch cho cấu trúc phần cứng thiết bị thích hợp. Vì mã gốc phụ thuộc nhiều vào công nghệ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân ứng dụng (ABI) trong Android NDK.
Device implementations:
- [C-0-1] PHẢI tương thích với một hoặc nhiều ABI Android NDK đã xác định.
- [C-0-2] PHẢI hỗ trợ mã chạy trong môi trường được quản lý để gọi vào mã gốc, sử dụng ngữ nghĩa Giao diện gốc Java (JNI) tiêu chuẩn.
- [C-0-3] PHẢI tương thích với nguồn (tức là tương thích với tiêu đề) và tương thích với tệp nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách bên dưới.
- [C-0-5] MUST accurately report the native Application Binary Interface
(ABI) supported by the device, via the
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
, andandroid.os.Build.SUPPORTED_64_BIT_ABIS
parameters, each a comma separated list of ABIs ordered from the most to the least preferred one. [C-0-6] MUST report, via the above parameters, a subset of the list of ABIs following and MUST NOT report any ABI not on the list.
armeabi
(không còn được NDK hỗ trợ dưới dạng mục tiêu)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] PHẢI cung cấp tất cả các thư viện sau đây, cung cấp API gốc, cho các ứng dụng có 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 như mô tả trong Mục 5.9) - libandroid.so (hỗ trợ hoạt động Android gốc)
- libc (thư viện C)
- libcamera2ndk.so
- libdl (trình liên kết động)
- libEGL.so (native OpenGL surface management)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Ghi nhật ký Android)
- libmediandk.so (hỗ trợ API nội dung nghe nhìn gốc)
- libm (thư viện toán học)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
- libOpenSLES.so (OpenSL ES 1.0.1 audio support)
- 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] MUST NOT add or remove the public functions for the native libraries listed above.
[C-0-9] PHẢI liệt kê các thư viện không phải AOSP khác được hiển thị trực tiếp cho các ứng dụng bên thứ ba trong
/vendor/etc/public.libraries.txt
.[C-0-10] KHÔNG ĐƯỢC hiển thị bất kỳ thư viện gốc nào khác, được triển khai và cung cấp trong AOSP dưới dạng thư viện hệ thống, cho các ứng dụng bên thứ ba nhắm đến API cấp 24 trở lên vì các thư viện này được đặt trước.
[C-0-11] MUST export all the OpenGL ES 3.1 and Android Extension Pack function symbols, as defined in the NDK, through the
libGLESv3.so
library. Lưu ý rằng mặc dù tất cả các ký hiệu PHẢI có, nhưng phần 7.1.4.1 mô tả chi tiết hơn về các yêu cầu đối với thời điểm triển khai đầy đủ từng hàm tương ứng.[C-0-12] PHẢI xuất các biểu tượng hàm cho các biểu tượng hàm
Vulkan 1.0Vulkan 1.1 cốt lõi, cũng như các tiện íchVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
vàVK_KHR_get_physical_device_properties2
thông qua thư việnlibvulkan.so
. Lưu ý rằng mặc dù tất cả các ký hiệu PHẢI có, nhưng mục 7.1.4.2 mô tả chi tiết hơn các yêu cầu về thời điểm triển khai đầy đủ từng hàm tương ứng.NÊN được tạo bằng mã nguồn và tệp tiêu đề có trong Dự án nguồn mở Android ngược dòng.
Lưu ý rằng các bản phát hành Android trong tương lai có thể hỗ trợ thêm các ABI.
3.3.2. Khả năng tương thích với mã gốc ARM 32 bit
If device implementations report the support of the armeabi
ABI, they:
- [C-3-1] MUST also support
armeabi-v7a
and report its support, asarmeabi
is only for backwards compatibility with older apps.
If device implementations report the support of the armeabi-v7a
ABI, for apps
using this ABI, they:
[C-2-1] PHẢI đưa các dòng sau vào
/proc/cpuinfo
và KHÔNG được thay đổi các giá trị trên cùng một thiết bị, ngay cả khi các ABI khác đọc các giá trị đó.Features:
, theo sau là danh sách các tính năng CPU ARMv7 không bắt buộc mà thiết bị hỗ trợ.CPU architecture:
, theo sau là một số nguyên mô tả cấu trúc ARM được hỗ trợ cao nhất của thiết bị (ví dụ: "8" for ARMv8 devices).
[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 tính năng hỗ trợ CPU gốc hoặc thông qua tính năng mô phỏng phần mềm:
- SWP and SWPB instructions.
- CP15ISB, CP15DSB và CP15DMB barrier operations.
[C-2-3] PHẢI hỗ trợ tiện ích Advanced SIMD (còn gọi là NEON).
3.4. Khả năng tương thích với web
3.4.1. Khả năng tương thích với WebView
Nếu các phương thức triển khai thiết bị cung cấp cách triển khai đầy đủ API android.webkit.Webview
, thì các phương thức đó:
- [C-1-1] MUST report
android.software.webview
. - [C-1-2] PHẢI sử dụng bản dựng Dự án Chromium từ Dự án nguồn mở Android ngược dòng trên nhánh Android 14 để triển khai API
android.webkit.WebView
. [C-1-3] The user agent string reported by the WebView MUST be in this format:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của android.os.Build.VERSION.RELEASE.
- Chuỗi $(MODEL) CÓ THỂ trống, nhưng nếu không trống thì CHẮC CHẮN phải có cùng giá trị với android.os.Build.MODEL.
- Bạn CÓ THỂ bỏ qua "Build/$(BUILD)", nhưng nếu có, chuỗi $(BUILD) PHẢI giống với giá trị của android.os.Build.ID.
- The value of the $(CHROMIUM_VER) string MUST be the version of Chromium in the upstream Android Open Source Project.
- Device implementations MAY omit Mobile in the user agent string.
Thành phần WebView PHẢI hỗ trợ nhiều tính năng HTML5 nhất có thể và nếu hỗ trợ tính năng này thì PHẢI tuân thủ quy cách HTML5.
[C-1-4] PHẢI hiển thị nội dung được cung cấp hoặc nội dung URL từ xa trong một quy trình khác với ứng dụng tạo bản sao WebView. Cụ thể, quy trình kết xuất riêng biệt PHẢI có đặc quyền thấp hơn, chạy dưới dạng mã nhận dạng người dùng riêng biệt, không có quyền truy cập vào thư mục dữ liệu của ứng dụng, không có quyền truy cập trực tiếp vào mạng và chỉ có quyền truy cập vào các dịch vụ hệ thống bắt buộc tối thiểu qua Binder. Cách triển khai WebView của AOSP đáp ứng yêu cầu này.
Xin lưu ý rằng nếu các phương thức triển khai thiết bị là 32 bit hoặc khai báo cờ tính năng android.hardware.ram.low
, thì các phương thức đó sẽ được miễn C-1-3.
3.4.2. Khả năng tương thích với trình duyệt
If device implementations include a standalone Browser application for general web browsing, they:
- [C-1-1] MUST support each of these APIs associated with HTML5:
- [C-1-2] PHẢI hỗ trợ API webstorage của HTML5/W3C và NÊN hỗ trợ API IndexedDB của HTML5/W3C. Lưu ý rằng các tổ chức tiêu chuẩn phát triển web đang chuyển sang ưu tiên IndexedDB hơn là webstorage, IndexedDB dự kiến sẽ trở thành một thành phần bắt buộc trong phiên bản Android sau này.
- MAY ship a custom user agent string in the standalone Browser application.
- NÊN triển khai tính năng hỗ trợ nhiều tính năng nhất có thể của HTML5 trên ứng dụng Trình duyệt độc lập (dù dựa trên ứng dụng Trình duyệt WebKit cấp trên hay ứng dụng thay thế của bên thứ ba).
Tuy nhiên, If device implementations do not include a standalone Browser application, they:
- [C-2-1] VẪN PHẢI hỗ trợ các mẫu ý định công khai như mô tả trong mục 3.2.3.1.
3.5. Khả năng tương thích về hành vi của API
Device implementations:
- [C-0-9] PHẢI đảm bảo rằng khả năng tương thích hành vi của API được áp dụng cho tất cả các ứng dụng đã cài đặt, trừ phi các ứng dụng đó bị hạn chế như mô tả trong Mục 3.5.1.
- [C-0-10] KHÔNG ĐƯỢC triển khai phương pháp danh sách cho phép chỉ đảm bảo khả năng tương thích về hành vi của API đối với các ứng dụng do nhà triển khai thiết bị chọn.
Hành vi của từng loại API (được quản lý, mềm, gốc và web) phải nhất quán với cách triển khai ưu tiên của Dự án nguồn mở Android ở thượng nguồn. Một số khía cạnh cụ thể về khả năng tương thích là:
- [C-0-1] Devices MUST NOT change the behavior or semantics of a standard intent.
- [C-0-2] Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type of system component (such as Service, Activity, ContentProvider, etc.).
- [C-0-3] 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 đối với ứng dụng chạy nền.
Cụ thể hơn, đối với các ứng dụng chạy nền:
- [C-0-4] các ứng dụng này PHẢI ngừng thực thi các lệnh gọi lại do ứng dụng đăng ký để nhận đầu ra từ
GnssMeasurement
vàGnssNavigationMessage
. - [C-0-5] các ứng dụng này PHẢI giới hạn tốc độ cập nhật được cung cấp cho ứng dụng thông qua lớp API
LocationManager
hoặc phương thứcWifiManager.startScan()
. - [C-0-6] if the app is targeting API level 25 or higher, they MUST NOT
allow to register broadcast receivers for the implicit broadcasts of
standard Android intents in the app's manifest, unless the broadcast
intent requires a
"signature"
or"signatureOrSystem"
protectionLevel
permission or are on the exemption list. - [C-0-7] if the app is targeting API level 25 or higher, they MUST stop
the app's background services, just as if the app had called the
services'
stopSelf()
method, unless the app is placed on a temporary allowlist to handle a task that's visible to the user. - [C-0-8] if the app is targeting API level 25 or higher, they MUST release the wakelocks the app holds.
- [C-0-4] các ứng dụng này PHẢI ngừng thực thi các lệnh gọi lại do ứng dụng đăng ký để nhận đầu ra từ
- [C-0-11] Các thiết bị PHẢI trả về các trình cung cấp dịch vụ bảo mật sau đây dưới dạng 7 giá trị mảng đầu tiên từ phương thức
Security.getProviders()
, theo thứ tự đã cho và với tên đã cho (doProvider.getName()
trả về) và các lớp, trừ phi ứng dụng đã sửa đổi danh sách thông quainsertProviderAt()
hoặcremoveProvider()
. Thiết bị có thể trả về các nhà cung cấp bổ sung sau danh sách nhà cung cấp được chỉ định bên dưới.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround –
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE –
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore –
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP –
Danh sách bên trên chưa đầy đủ. Bộ kiểm tra tính tương thích (CTS) kiểm tra một số phần quan trọng của nền tảng để đảm bảo khả năng tương thích về hành vi, nhưng không phải tất cả. It is the responsibility of the implementer to ensure behavioral compatibility with the Android Open Source Project. Vì lý do này, nhà triển khai thiết bị NÊN sử dụng mã nguồn có sẵn thông qua Dự án nguồn mở Android khi có thể, thay vì triển khai lại các phần quan trọng của hệ thống.
3.5.1. Hạn chế ứng dụng
Nếu các phương thức triển khai thiết bị triển khai một cơ chế độc quyền để hạn chế ứng dụng (ví dụ: thay đổi hoặc hạn chế hành vi API được mô tả trong SDK) và cơ chế đó hạn chế hơn Bộ chứa chế độ chờ ứng dụng bị hạn chế, thì các phương thức triển khai đó:
- [C-1-1] PHẢI cho phép người dùng xem danh sách ứng dụng bị hạn chế.
- [C-1-2] MUST provide user affordance to turn on / off all of these proprietary restrictions on each app.
[C-1-3] KHÔNG ĐƯỢC tự động áp dụng các quy định hạn chế độc quyền này khi không có bằng chứng về hành vi ảnh hưởng xấu đến tình trạng hệ thống, nhưng CÓ THỂ áp dụng các quy định hạn chế này đối với ứng dụng khi phát hiện hành vi ảnh hưởng xấu đến tình trạng hệ thống như bị 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í này CÓ THỂ do bên 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. Các tiêu chí khác không liên quan hoàn toàn đến tình trạng hệ thống, chẳng hạn như mức độ phổ biến của ứng dụng trên thị trường, KHÔNG ĐƯỢC dùng làm tiêu chí.
[C-1-4] KHÔNG được tự động áp dụng các quy định hạn chế độc quyền này cho ứng dụng khi người dùng đã tắt các quy định hạn chế ứng dụng theo cách thủ công và CÓ THỂ đề xuất người dùng áp dụng các quy định hạn chế độc quyền này.
[C-1-5] PHẢI thông báo cho người dùng nếu các quy định hạn chế độc quyền này được áp dụng tự động cho một ứng dụng. Bạn PHẢI cung cấp thông tin đó trong khoảng thời gian 24 giờ trước khi áp dụng các quy định hạn chế độc quyền này.
[C-1-6] PHẢI trả về true cho phương thức ActivityManager.isBackgroundRestricted() đối với mọi lệnh gọi API từ một ứng dụng.
[C-1-7] KHÔNG ĐƯỢC hạn chế ứng dụng trên nền trước hàng đầu mà người dùng sử dụng một cách rõ ràng.
[C-1-8] PHẢI tạm ngưng các quy định hạn chế độc quyền này đối với một ứng dụng bất cứ khi nào người dùng bắt đầu sử dụng ứng dụng đó một cách rõ ràng, biến ứng dụng đó thành ứng dụng trên nền trước hàng đầu.
[C-1-10] PHẢI cung cấp tài liệu hoặc trang web công khai và rõ ràng mô tả cách áp dụng các quy định hạn chế về quyền sở hữu. Tài liệu hoặc trang web này PHẢI có thể liên kết với tài liệu SDK Android và PHẢI bao gồm:
- Điều kiện kích hoạt các quy định hạn chế về quyền sở hữu.
- Nội dung và cách thức hạn chế một ứng dụng.
- Cách một ứng dụng có thể được miễn trừ khỏi các quy định hạn chế đó.
- Cách một ứng dụng có thể yêu cầu miễn trừ các quy định hạn chế về quyền sở hữu, nếu các quy định đó hỗ trợ việc miễn trừ cho các ứng dụng mà người dùng có thể cài đặt.
Nếu một ứng dụng được cài đặt sẵn trên thiết bị và người dùng chưa bao giờ sử dụng ứng dụng đó trong hơn 30 ngày, thì [C-1-3] [C-1-5] sẽ được miễn trừ.
Nếu các phương thức triển khai thiết bị mở rộng các quy định hạn chế đối với ứng dụng được triển khai trong AOSP, thì các phương thức đó:
- [C-2-1]PHẢI tuân theo cách triển khai được mô tả trong tài liệu này.
3.5.2. Trạng thái ngủ đông của ứng dụng
Nếu các phương thức triển khai thiết bị bao gồm tính năng Hibernate ứng dụng có trong AOSP hoặc mở rộng tính năng có trong AOSP, thì các phương thức đó:
- [C-1-1] PHẢI đáp ứng tất cả các yêu cầu trong mục 3.5.1, ngoại trừ [C-1-6] và [C-1-3].
- [C-1-2] CHỈ ĐƯỢC áp dụng quy định hạn chế đối với ứng dụng cho người dùng khi có bằng chứng cho thấy người dùng không sử dụng ứng dụng trong một khoảng thời gian. Bạn NÊN chọn khoảng thời gian từ một tháng trở lên. LƯỢNG DÙNG PHẢI được xác định bằng một hành động tương tác rõ ràng của người dùng thông qua API UsageStats#getLastTimeVisible() hoặc bất kỳ điều gì khiến ứng dụng thoát khỏi trạng thái buộc dừng, bao gồm cả liên kết dịch vụ, liên kết nhà cung cấp nội dung, thông báo truyền tin rõ ràng, v.v., sẽ được theo dõi bằng API mới UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] CHỈ được áp dụng các quy định hạn chế ảnh hưởng đến tất cả người dùng thiết bị khi có bằng chứng cho thấy KHÔNG CÓ người dùng nào sử dụng gói đó trong một khoảng thời gian nào đó. Bạn NÊN chọn khoảng thời gian từ một tháng trở lên.
- [C-1-4] KHÔNG ĐƯỢC khiến ứng dụng không thể phản hồi ý định hoạt động, liên kết dịch vụ, yêu cầu của nhà cung cấp nội dung hoặc thông báo truyền tin rõ ràng.
Chế độ ngủ đông ứng dụng trong AOSP đáp ứng các yêu cầu trên.
3.6. Không gian tên API
Android tuân theo các quy ước về không gian tên gói và lớp do ngôn ngữ lập trình Java xác định. Để đảm bảo khả năng tương thích với các ứng dụng bên thứ ba, người triển khai thiết bị KHÔNG ĐƯỢC thực hiện bất kỳ sửa đổi bị cấm nào (xem bên dưới) đối với các không gian tên gói sau:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Tức là:
- [C-0-1] KHÔNG ĐƯỢC sửa đổi các API công khai trên nền tảng Android bằng cách thay đổi bất kỳ phương thức hoặc chữ ký lớp nào, hoặc xoá các lớp hoặc trường lớp.
- [C-0-2] MUST NOT add any publicly exposed elements (such as classes or interfaces, or fields or methods to classes or interfaces existing) or Test or System APIs to the APIs in the above namespaces. "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 dấu "@hide" 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 các sửa đổi đó:
- [C-0-3] KHÔNG ĐƯỢC ảnh hưởng đến hành vi đã nêu và chữ ký bằng ngôn ngữ Java của bất kỳ API nào được công khai.
- [C-0-4] KHÔNG ĐƯỢC quảng cáo hoặc hiển thị cho nhà phát triển.
Tuy nhiên, các nhà triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh bên ngoài không gian tên Android tiêu chuẩn, nhưng API tuỳ chỉnh:
- [C-0-5] KHÔNG ĐƯỢC nằm trong không gian tên thuộc sở hữu hoặc tham chiếu đến một tổ chức khác. For instance, device implementers MUST NOT add APIs to the
com.google.*
or similar namespace: only Google may do so. Similarly, Google MUST NOT add APIs to other companies' namespaces. - [C-0-6] PHẢI được đóng gói trong thư viện dùng chung của Android để chỉ những ứng dụng sử dụng các API đó một cách rõ ràng (thông qua cơ chế <uses-library>) mới bị ảnh hưởng bởi mức sử dụng bộ nhớ tăng lên của các API đó.
Trình triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh bằng ngôn ngữ gốc, bên ngoài API NDK, nhưng API tuỳ chỉnh:
- [C-1-1] KHÔNG ĐƯỢC nằm trong thư viện NDK hoặc thư viện do một tổ chức khác sở hữu như mô tả tại đây.
Nếu người triển khai thiết bị đề xuất cải thiện một trong các không gian tên gói ở trên (chẳng hạn như bằng cách thêm chức năng mới hữu ích vào một API hiện có hoặc thêm một API mới), thì người triển khai PHẢI truy cập vào source.android.com và bắt đầu quy trình đóng góp thay đổi và mã, theo thông tin trên trang web đó.
Lưu ý rằng các quy định hạn chế ở trên tương ứng với các quy ước tiêu chuẩn để đặt tên cho API trong ngôn ngữ lập trình Java; mục này chỉ nhằm củng cố các quy ước đó và giúp các quy ước đó trở nên ràng buộc thông qua việc đưa vào Định nghĩa về khả năng tương thích này.
3.7. Khả năng tương thích với thời gian chạy
Device implementations:
[C-0-1] MUST support the full Dalvik Executable (DEX) format and Dalvik bytecode specification and semantics.
[C-0-2] PHẢI định cấu hình môi trường thời gian chạy Dalvik để phân bổ bộ nhớ theo nền tảng Android thượng nguồn 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), phương thức triển khai tham chiếu ngược dòng của Định dạng thực thi Dalvik và hệ thống quản lý gói của phương thức triển khai tham chiếu.
NÊN chạy kiểm thử tìm lỗi mã nguồn trong nhiều chế độ thực thi và cấu trúc mục tiêu để đảm bảo thời gian chạy ổn định. Tham khảo JFuzz và DexFuzz trên trang web Dự án nguồn mở Android.
Lưu ý rằng các giá trị bộ nhớ được chỉ định bên dưới được coi là giá trị tối thiểu và việc triển khai thiết bị CÓ THỂ phân bổ nhiều bộ nhớ hơn cho mỗi ứng dụng.
Bố cục màn hình | Mật độ màn hình | Bộ nhớ tối thiểu của ứng dụng |
---|---|---|
Đồng hồ Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88 MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
small/normal | 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) | 96 MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192 MB | |
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) | 96 MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192 MB | |
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) | 96 MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192 MB | |
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 với giao diện người dùng
3.8.1. Trình chạy (Màn hình chính)
Android bao gồm một ứng dụng trình chạy (màn hình chính) và hỗ trợ các ứng dụng bên thứ ba thay thế trình chạy của thiết bị (màn hình chính).
If device implementations allow third-party applications to replace the device home screen, they:
- [C-1-1] MUST declare the platform feature
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ứcPackageManager
để truy xuất biểu tượng được gọi.
If device implementations include a default launcher that supports in-app pinning of shortcuts, they:
- [C-2-1] MUST report
true
forShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] MUST have user affordance asking the user before adding a shortcut requested
by apps via the
ShortcutManager.requestPinShortcut()
API method. - [C-2-3] MUST support pinned shortcuts and dynamic and static shortcuts as documented on the App Shortcuts page.
Conversely, if device implementations do not support in-app pinning of shortcuts, they:
- [C-3-1] MUST report
false
forShortcutManager.isRequestPinShortcutSupported()
.
If device implementations implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API, they:
- [C-4-1] MUST support all documented shortcut features (e.g. static and
dynamic shortcuts, pinning shortcuts) and fully implement the APIs of the
ShortcutManager
API class.
If device implementations include a default launcher app that shows badges for the app icons, they:
- [C-5-1] PHẢI tuân thủ phương thức API
NotificationChannel.setShowBadge()
. Nói cách khác, hãy hiển thị một tính năng trực quan liên kết với biểu tượng ứng dụng nếu giá trị được đặt thànhtrue
và không hiển thị bất kỳ chương trình gắn huy hiệu biểu tượng ứng dụng nào khi tất cả các kênh thông báo của ứng dụng đã đặt giá trị thànhfalse
. - CÓ THỂ ghi đè huy hiệu biểu tượng ứng dụng bằng giao thức huy hiệu độc quyền khi các ứng dụng bên thứ ba cho biết hỗ trợ giao thức huy hiệu độc quyền thông qua việc sử dụng các API độc quyền, nhưng PHẢI sử dụng tài nguyên và giá trị được cung cấp thông qua API huy hiệu thông báo được mô tả trong SDK, chẳng hạn như
Notification.Builder.setNumber()
và APINotification.Builder.setBadgeIconType()
.
Nếu các phương thức triển khai thiết bị hỗ trợ biểu tượng đen trắng, thì các biểu tượng này:
- [C-6-1] CHỈ được sử dụng khi người dùng bật chúng một cách rõ ràng (ví dụ: thông qua trình đơn Cài đặt hoặc trình chọn hình nền).
3.8.2. Tiện ích
Android hỗ trợ các tiện ích ứng dụng của bên thứ ba bằng cách xác định loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị "AppWidget" cho người dùng cuối.
If device implementations support third-party app widgets, they:
- [C-1-1] PHẢI khai báo hỗ trợ tính năng nền tảng
android.software.app_widgets
. [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets
[C-1-3] PHẢI có khả năng hiển thị các tiện ích có kích thước 4 x 4 trong lưới tiêu chuẩn. Xem App Widget DesignGuidelines trong tài liệu SDK Android để biết thông tin chi tiết.
CÓ THỂ hỗ trợ tiện ích ứng dụng trên màn hình khoá.
If device implementations support third-party app widgets and in-app pinning of shortcuts, they:
- [C-2-1] MUST report
true
forAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] MUST have user affordance asking the user before adding a shortcut requested
by apps via the
AppWidgetManager.requestPinAppWidget()
API method.
3.8.3. Thông báo
Android includes Notification
and
NotificationManager
APIs that allow third-party app developers to notify users of notable events and
attract users' attention using the hardware components (e.g. sound, vibration
and light) and software features (e.g. notification shade, system bar) of the
device.
3.8.3.1. Trình bày thông báo
If device implementations allow third-party apps to notify users of notable events, they:
- [C-1-1] PHẢI hỗ trợ các thông báo sử dụng tính năng phần cứng, như mô tả trong tài liệu SDK và trong phạm vi có thể với phần cứng triển khai thiết bị. Ví dụ: nếu một phương thức triển khai thiết bị có bao gồm bộ rung, thì phương thức đó PHẢI triển khai chính xác các API rung. Nếu một phương thức triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7.
- [C-1-2] PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp ảnh động, v.v.) được cung cấp trong API hoặc trong hướng dẫn về kiểu biểu tượng của Thanh trạng thái/Thanh hệ thống, mặc dù các tài nguyên này CÓ THỂ mang lại trải nghiệm người dùng thay thế cho thông báo so với trải nghiệm do cách triển khai Android Open Source tham chiếu cung cấp.
- [C-1-3] PHẢI tuân thủ và triển khai đúng cách các hành vi được mô tả cho các API để cập nhật, xoá và nhóm thông báo.
- [C-1-4] PHẢI cung cấp toàn bộ hành vi của API NotificationChannel được ghi nhận trong SDK.
- [C-1-5] MUST provide a user affordance to block and modify a certain third-party app's notification per each channel and app package level.
- [C-1-6] MUST also provide a user affordance to display deleted notification channels.
[C-1-7] MUST correctly render all resources (images, stickers, icons, etc.) provided through Notification.MessagingStyle alongside the text of the notification without additional user interaction. Ví dụ: BẮT BUỘC hiển thị tất cả tài nguyên, bao gồm cả biểu tượng được cung cấp thông qua android.app.Person trong cuộc trò chuyện nhóm được thiết lập thông qua setGroupConversation.
[C-SR-1] Bạn NÊN cung cấp một tính năng để người dùng kiểm soát các thông báo hiển thị cho những ứng dụng đã được cấp quyền Trình nghe thông báo. Độ chi tiết PHẢI như vậy để người dùng có thể kiểm soát cho từng trình nghe thông báo như vậy những loại thông báo nào được kết nối với trình nghe này. Các loại này PHẢI bao gồm thông báo "cuộc trò chuyện", "cảnh báo", "không âm thanh" và "liên tục quan trọng".
[C-SR-2] Bạn NÊN cung cấp một tính năng để người dùng chỉ định các ứng dụng cần loại trừ khỏi việc thông báo cho bất kỳ trình nghe thông báo cụ thể nào.
[C-SR-3] Bạn NÊN tự động hiển thị một hành động mà người dùng có thể thực hiện để chặn thông báo của một ứng dụng bên thứ ba nhất định theo từng cấp độ kênh và gói ứng dụng sau khi người dùng đóng thông báo đó nhiều lần.
SHOULD support rich notifications.
SHOULD present some higher priority notifications as heads-up notifications.
SHOULD have a user affordance to snooze notifications.
MAY only manage the visibility and timing of when third-party apps can notify users of notable events to mitigate safety issues such as driver distraction.
Android 11 ra mắt tính năng hỗ trợ thông báo cuộc trò chuyện. Đây là các thông báo sử dụng MessagingStyle và cung cấp mã lối tắt Người dùng đã xuất bản.
Device implementations:
- [C-SR-4] NÊN nhóm và hiển thị
conversation notifications
trước các thông báo không phải cuộc trò chuyện, ngoại trừ thông báo dịch vụ trên nền trước đang diễn ra và thông báoimportance:high
.
Nếu các phương thức triển khai thiết bị hỗ trợ conversation notifications
và ứng dụng cung cấp dữ liệu bắt buộc cho bubbles
, thì:
- [C-SR-5] Bạn NÊN hiển thị cuộc trò chuyện này dưới dạng bong bóng trò chuyện. Việc triển khai AOSP đáp ứng các yêu cầu này bằng giao diện người dùng hệ thống, cài đặt và trình chạy mặc định.
If device implementations support rich notifications, they:
- [C-2-1] PHẢI sử dụng chính xác các tài nguyên được cung cấp thông qua lớp API
Notification.Style
và các lớp con của lớp đó cho các phần tử tài nguyên được trình bày. - SHOULD present each and every resource element (e.g.
icon, title and summary text) defined in the
Notification.Style
API class and its subclasses.
Thông báo quan trọng là thông báo được trình bày cho người dùng khi thông báo đó đến độc lập với giao diện mà người dùng đang sử dụng. Nếu các phương thức triển khai thiết bị hỗ trợ thông báo quan trọng, thì các phương thức đó:
- [C-3-1] PHẢI sử dụng thành phần hiển thị thông báo quan trọng và tài nguyên như mô tả trong lớp API
Notification.Builder
khi thông báo quan trọng xuất hiện. - [C-3-2] PHẢI hiển thị các thao tác được cung cấp thông qua
Notification.Builder.addAction()
cùng với nội dung thông báo mà không cần người dùng tương tác thêm như mô tả trong SDK.
3.8.3.2. Dịch vụ trình nghe thông báo
Android includes the NotificationListenerService
API that allows apps (once explicitly enabled by the user) to receive a copy of all notifications as they are posted or updated.
Device implementations:
- [C-0-1] MUST correctly and promptly update notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object.
- [C-0-2] MUST respect the
snoozeNotification()
API call, and dismiss the notification and make a callback after the snooze duration that is set in the API call.
If device implementations have a user affordance to snooze notifications, they:
- [C-1-1] MUST reflect the snoozed notification status properly
through the standard APIs such as
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] MUST make this user affordance available to snooze notifications from each installed third-party app's, unless they are from persistent/foreground services.
3.8.3.3. Chế độ Không làm phiền/Chế độ ưu tiên
Nếu các phương thức triển khai thiết bị hỗ trợ tính năng DND (còn gọi là Chế độ ưu tiên), thì các phương thức đó:
- [C-1-1] MUST, for when the implementation of the device has provided a means for the user to grant or deny third-party apps to access the DND policy configuration, display Automatic DND rules created by applications alongside the user-created and pre-defined rules.
- [C-1-3] PHẢI tuân thủ các giá trị
suppressedVisualEffects
được truyền quaNotificationManager.Policy
và nếu một ứng dụng đã đặt bất kỳ cờ nào trong số SUPPRESSED_EFFECT_SCREEN_OFF hoặc SUPPRESSED_EFFECT_SCREEN_ON, thì ứng dụng đó PHẢI cho người dùng biết rằng các hiệu ứng hình ảnh bị tắt trong trình đơn cài đặt chế độ Không làm phiền.
3.8.4. API Trợ lý
Android bao gồm Assist API để 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ị.
If device implementations support the Assist action, they:
- [C-2-1] PHẢI cho người dùng cuối biết rõ thời điểm chia sẻ ngữ cảnh, bằng cách:
- Mỗi khi ứng dụng trợ lý truy cập vào ngữ cảnh, một ánh sáng trắng sẽ xuất hiện xung quanh các cạnh của màn hình, đáp ứng hoặc vượt quá thời lượng và độ sáng của quá trình triển khai Dự án nguồn mở Android.
- Đối với ứng dụng trợ lý được cài đặt sẵn, hãy cung cấp cho người dùng một thao tác có thể thực hiện trong vòng chưa đến 2 thao tác từ trình đơn cài đặt ứng dụng trợ lý và phương thức nhập bằng giọng nói mặc định, đồng thời chỉ chia sẻ ngữ cảnh khi người dùng gọi ứng dụng trợ lý một cách rõ ràng thông qua cụm từ kích hoạt hoặc thao tác nhập bằng phím điều hướng trợ lý.
- [C-2-2] The designated interaction to launch the assist app as described
in section 7.2.3 MUST launch the
assist app the user selected, in other words the app that implements
VoiceInteractionService
, or an activity handling theACTION_ASSIST
intent.
3.8.5. Cảnh báo và thông báo ngắn
Các ứng dụng có thể sử dụng API Toast
để hiển thị các chuỗi ngắn không theo phương thức phương thức (non-modal) cho người dùng cuối. Các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn và sử dụng API loại cửa sổ TYPE_APPLICATION_OVERLAY
để hiển thị cửa sổ cảnh báo dưới dạng lớp phủ trên các ứng dụng khác.
If device implementations include a screen or video output, they:
[C-1-1] PHẢI cung cấp cho người dùng khả năng chặn một ứng dụng hiển thị cửa sổ cảnh báo sử dụng
TYPE_APPLICATION_OVERLAY
. The AOSP implementation meets this requirement by having controls in the notification shade.[C-1-2] MUST honor the Toast API and display Toasts from applications to end users in some highly visible manner.
3.8.6. Giao diện
Android cung cấp "giao diện" dưới dạng một cơ chế để các ứng dụng áp dụng kiểu trên toàn bộ Hoạt động hoặc ứng dụng.
Android bao gồm một gia đình giao diện "Holo" và "Material" dưới dạng một tập hợp các kiểu được xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn khớp với giao diện của giao diện Holo theo định nghĩa của SDK Android.
If device implementations include a screen or video output, they:
- [C-1-1] KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Holo nào hiển thị với ứng dụng.
- [C-1-2] PHẢI hỗ trợ gia đình giao diện "Material" và KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Material nào hoặc tài sản của các thuộc tính đó được hiển thị cho ứng dụng.
[C-1-3] PHẢI đặt bộ phông chữ "sans-serif" thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ hoặc cung cấp cho người dùng khả năng thay đổi phông chữ dùng cho bộ phông chữ "sans-serif" thành Roboto phiên bản 2.x cho các ngôn ngữ mà Roboto hỗ trợ.
[C-1-4] PHẢI tạo bảng sắc độ màu động như được chỉ định trong tài liệu AOSP về
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(xemandroid.theme.customization.system_palette
vàandroid.theme.customization.theme_style
).[C-1-5] PHẢI tạo bảng sắc độ màu động bằng cách sử dụng các kiểu giao diện màu được liệt kê trong tài liệu
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(xemandroid.theme.customization.theme_styles
), cụ thể làTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, vàMONOCHROMATIC
."Màu nguồn" dùng để tạo bảng sắc độ màu động khi được gửi bằng
android.theme.customization.system_palette
(như được ghi lại trongSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] PHẢI có giá trị sắc độ
CAM16
từ 5 trở lên.NÊN được lấy từ hình nền thông qua
com.android.systemui.monet.ColorScheme#getSeedColors
, cung cấp nhiều màu nguồn hợp lệ để chọn một màu.NÊN sử dụng giá trị
0xFF1B6EF3
nếu không có màu nào được cung cấp đáp ứng yêu cầu về màu nguồn ở trên.
Android also includes a “Device Default” theme family as a set of defined styles for application developers to use if they want to match the look and feel of the device theme as defined by the device implementer.
- Device implementations MAY modify the Device Default theme attributes exposed to applications.
Android hỗ trợ giao diện biến thể có các thanh hệ thống mờ, cho phép nhà phát triển ứng dụng điền nội dung ứng dụng vào khu vực phía sau thanh trạng thái và thanh điều hướng. Để mang lại trải nghiệm nhất quán cho nhà phát triển trong cấu hình này, điều quan trọng là bạn phải duy trì kiểu biểu tượng thanh trạng thái trên các phương thức triển khai thiết bị khác nhau.
If device implementations include a system status bar, they:
- [C-2-1] PHẢI sử dụng màu trắng cho các biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) cũng như 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ờ WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
- [C-2-2] Android device implementations MUST change the color of the system status icons to black (for details, refer to R.style) when an app requests a light status bar.
3.8.7. Hình nền động (Live Wallpaper)
Android xác định một loại thành phần, API và vòng đời tương ứng cho phép ứng dụng hiển thị một hoặc nhiều “Live Wallpapers” cho người dùng cuối. Hình nền động là ảnh động, mẫu hoặc hình ảnh tương tự có chức năng nhập hạn chế, hiển thị dưới dạng hình nền, phía sau các ứng dụng khác.
Hardware is considered capable of reliably running live wallpapers if it can run all live wallpapers, with no limitations on functionality, at a reasonable frame rate with no adverse effects on other applications. Nếu các giới hạn về phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, hoạt động không đúng cách, tiêu thụ quá nhiều CPU hoặc pin hoặc chạy ở tốc độ khung hình thấp không chấp nhận được, thì phần cứng đó được coi là không thể chạy hình nền động. Ví dụ: một số hình nền động có thể sử dụng ngữ cảnh OpenGL 2.0 hoặc 3.x để hiển thị nội dung. Hình nền động sẽ không chạy ổn định trên phần cứng không hỗ trợ nhiều ngữ cảnh OpenGL vì việc sử dụng ngữ cảnh OpenGL cho hình nền động có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.
- Device implementations capable of running live wallpapers reliably as described above SHOULD implement live wallpapers.
If device implementations implement live wallpapers, they:
- [C-1-1] MUST report the platform feature flag android.software.live_wallpaper.
3.8.8. Chuyển đổi hoạt động
Mã nguồn Android ngược dòng bao gồm màn hình tổng quan, một giao diện người dùng cấp hệ thống để chuyển đổi tác vụ và hiển thị các hoạt động và tác vụ đã truy cập gần đây bằng hình thu nhỏ của trạng thái đồ hoạ của ứng dụng tại thời điểm người dùng rời khỏi ứng dụng lần gần nhất.
Device implementations including the recents function navigation key as detailed in section 7.2.3 MAY alter the interface.
Nếu các phương thức triển khai thiết bị bao gồm cả phím điều hướng chức năng gần đây như mô tả trong mục 7.2.3 làm thay đổi giao diện, thì:
- [C-1-1] MUST support at least up to 7 activities displayed.
- SHOULD at least display the title of 4 activities at a time.
- [C-1-2] PHẢI triển khai hành vi ghim màn hình và cung cấp cho người dùng một trình đơn cài đặt để bật/tắt tính năng này.
- SHOULD display highlight color, icon, screen title in recents.
- NÊN hiển thị một tính năng đóng ("x") nhưng CÓ THỂ trì hoãn việc này cho đến khi người dùng tương tác với màn hình.
- NÊN triển khai lối tắt để dễ dàng chuyển sang hoạt động trước đó.
- SHOULD trigger the fast-switch action between the two most recently used apps, when the recents function key is tapped twice.
- NÊN kích hoạt chế độ nhiều cửa sổ chia đôi màn hình (nếu được hỗ trợ) khi nhấn và giữ phím chức năng gần đây.
- MAY display affiliated recents as a group that moves together.
- [C-SR-1] Are STRONGLY RECOMMENDED to use the upstream Android user interface (or a similar thumbnail-based interface) for the overview screen.
3.8.9. Quản lý đầu vào
Android hỗ trợ tính năng Quản lý phương thức nhập và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba.
If device implementations allow users to use third-party input methods on the device, they:
- [C-1-1] PHẢI khai báo tính năng nền tảng android.software.input_methods và hỗ trợ các API IME như được xác định trong tài liệu SDK Android.
3.8.10. Lock Screen Media Control
The Remote Control Client API is deprecated from Android 5.0 in favor of the Media Notification Template that allows media applications to integrate with playback controls that are displayed on the lock screen.
3.8.11. Trình bảo vệ màn hình (trước đây là Dreams)
Xem phần 3.2.3.5 để biết ý định cài đặt nhằm định cấu hình trình bảo vệ màn hình.
3.8.12. Vị trí
If device implementations include a hardware sensor (e.g. GPS) that is capable of providing the location coordinates, they
- [C-1-2] PHẢI hiển thị trạng thái hiện tại của thông tin vị trí trong trình đơn Vị trí trong phần Cài đặt.
- [C-1-3] KHÔNG ĐƯỢC hiển thị chế độ vị trí trong trình đơn Vị trí trong phần Cài đặt.
3.8.13. Unicode và phông chữ
Android hỗ trợ các ký tự biểu tượng cảm xúc được xác định trong Unicode 10.0.
If device implementations include a screen or video output, they:
- [C-1-1] MUST be capable of rendering these emoji characters in color glyph.
- [C-1-2] MUST include support for:
- Phông chữ Roboto 2 với nhiều độ đậm – sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light cho các ngôn ngữ có trên thiết bị.
- Full Unicode 7.0 coverage of Latin, Greek, and Cyrillic, including the Latin Extended A, B, C, and D ranges, and all glyphs in the currency symbols block of Unicode 7.0.
- [C-1-3] KHÔNG ĐƯỢC xoá hoặc sửa đổi NotoColorEmoji.tff trong hình ảnh hệ thống. (Bạn có thể thêm phông chữ biểu tượng cảm xúc mới để ghi đè biểu tượng cảm xúc trong NotoColorEmoji.tff)
- SHOULD support the skin tone and diverse family emojis as specified in the Unicode Technical Report #51.
If device implementations include an IME, they:
- SHOULD provide an input method to the user for these emoji characters.
Android hỗ trợ hiển thị phông chữ Myanmar. Tiếng Myanmar có một số phông chữ không tuân thủ Unicode, thường được gọi là "Zawgyi" để hiển thị các ngôn ngữ Myanmar.
If device implementations include support for Burmese, they:
- [C-2-1] PHẢI hiển thị văn bản bằng phông chữ tuân thủ Unicode làm mặc định; KHÔNG ĐƯỢC đặt phông chữ không tuân thủ Unicode làm phông chữ mặc định trừ khi người dùng chọn phông chữ đó trong bộ chọn ngôn ngữ.
- [C-2-2] PHẢI hỗ trợ phông chữ Unicode và phông chữ tuân thủ Unicode nếu phông chữ tuân thủ Unicode được hỗ trợ trên thiết bị. Phông chữ không tuân thủ Unicode KHÔNG ĐƯỢC xoá hoặc ghi đè phông chữ Unicode.
- [C-2-3] PHẢI hiển thị văn bản bằng phông chữ không tuân thủ Unicode CHỈ KHI mã ngôn ngữ có mã tập lệnh Qaag được chỉ định (ví dụ: my-Qaag). Không có mã ngôn ngữ hoặc mã khu vực ISO nào khác (dù đã chỉ định, chưa chỉ định hay được đặt trước) có thể được dùng để tham chiếu đến phông chữ không tuân thủ Unicode cho Myanmar. Nhà phát triển ứng dụng và tác giả trang web có thể chỉ định my-Qaag làm mã ngôn ngữ được chỉ định như đối với mọi ngôn ngữ khác.
3.8.14. Nhiều cửa sổ
Nếu các phương thức 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 phương thức đó:
- [C-1-1] PHẢI triển khai(các) chế độ nhiều cửa sổ như vậy theo các 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 tuân thủ
android:resizeableActivity
do ứng dụng đặt trong tệpAndroidManifest.xml
như mô tả trong SDK này. - [C-1-3] KHÔNG ĐƯỢC cung cấp chế độ chia đôi màn hình hoặc chế độ hình dạng tuỳ ý nếu chiều cao màn hình nhỏ hơn 440 dp và chiều rộng màn hình nhỏ hơn 440 dp.
- [C-1-4] KHÔNG ĐƯỢC đổi kích thước hoạt động thành kích thước nhỏ hơn 220 dp ở các chế độ nhiều cửa sổ khác với Hình trong hình.
- Device implementations with screen size
xlarge
SHOULD support freeform mode.
If device implementations support multi-window mode(s), and the split screen mode, they:
- [C-2-2] PHẢI cắt bớt hoạt động được kết nối của chế độ nhiều cửa sổ chia đôi màn hình nhưng NÊN hiển thị một số nội dung của hoạt động đó, nếu ứng dụng Trình chạy là cửa sổ được lấy 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 được ghi đè các giá trị này trong quá trình hiển thị một số nội dung của hoạt động được kêt nối.
If device implementations support multi-window mode(s) and Picture-in-Picture multi-window mode, they:
- [C-3-1] PHẢI chạy các hoạt động ở chế độ nhiều cửa sổ hình trong hình khi ứng dụng:
* Nhắm đến API cấp 26 trở lên và khai báo
android:supportsPictureInPicture
* Nhắm đến API cấp 25 trở xuống và khai báo cảandroid:resizeableActivity
vàandroid:supportsPictureInPicture
. - [C-3-2] PHẢI hiển thị các thao tác trong SystemUI như được hoạt động PIP hiện tại chỉ định thông qua API
setActions()
. - [C-3-3] MUST support aspect ratios greater than or equal to
1:2.39 and less than or equal to 2.39:1, as specified by the PIP activity through
the
setAspectRatio()
API. - [C-3-4] PHẢI sử dụng
KeyEvent.KEYCODE_WINDOW
để kiểm soát cửa sổ PIP; nếu không triển khai chế độ PIP, thì khoá PHẢI có sẵn cho hoạt động trên nền trước. - [C-3-5] PHẢI cung cấp cho người dùng khả năng chặn một ứng dụng hiển thị ở chế độ PIP; cách triển khai AOSP đáp ứng yêu cầu này bằng cách có các chế độ điều khiển trong ngăn thông báo.
[C-3-6] PHẢI phân bổ chiều rộng và chiều cao tối thiểu sau đây cho cửa sổ PIP khi ứng dụng không khai báo giá trị nào cho
AndroidManifestLayout_minWidth
vàAndroidManifestLayout_minHeight
:- Các thiết bị có Configuration.uiMode được đặt khác với
UI_MODE_TYPE_TELEVISION
PHẢI phân bổ chiều rộng và chiều cao tối thiểu là 108 dp. - Các thiết bị có Configuration.uiMode được đặt thành
UI_MODE_TYPE_TELEVISION
PHẢI phân bổ chiều rộng tối thiểu là 240 dp và chiều cao tối thiểu là 135 dp.
- Các thiết bị có Configuration.uiMode được đặt khác với
3.8.15. Vết cắt trên màn hình
Android hỗ trợ tính năng Lỗ khoét màn hình như mô tả trong tài liệu SDK. API DisplayCutout
xác định một khu vực ở cạnh màn hình có thể không hoạt động cho một ứng dụng do màn hình cắt hoặc màn hình cong ở(các) cạnh.
If device implementations include display cutout(s), they:
- [C-1-5] KHÔNG ĐƯỢC có(các) phần cắt nếu tỷ lệ khung hình của thiết bị là 1.0(1:1).
- [C-1-2] KHÔNG ĐƯỢC có nhiều phần cắt trên mỗi cạnh.
- [C-1-3] PHẢI tuân thủ các cờ cắt màn hình do ứng dụng đặt thông qua API
WindowManager.LayoutParams
như mô tả trong SDK. - [C-1-4] MUST report correct values for all cutout metrics defined in the
DisplayCutout
API.
3.8.16. Điều khiển thiết bị
Android bao gồm các API ControlsProviderService
và Control
để cho phép các ứng dụng bên thứ ba phát hành các chế độ điều khiển thiết bị cho trạng thái và thao tác nhanh cho người dùng.
Xem Mục 2_2_3 để biết các yêu cầu dành riêng cho thiết bị.
3.8.17. Bảng nhớ tạm
Device implementations:
- [C-0-1] KHÔNG ĐƯỢC gửi dữ liệu bảng nhớ tạm đến bất kỳ thành phần, hoạt động, dịch vụ nào hoặc trên bất kỳ kết nối mạng nào mà không có hành động rõ ràng của người dùng (ví dụ: nhấn nút trên lớp phủ) hoặc chỉ báo về nội dung đang được gửi, ngoại trừ các dịch vụ được đề cập trong phần 9.8.6 Tính năng chụp nội dung và Tìm kiếm ứng dụng.
Nếu các phương thức triển khai trên thiết bị tạo bản xem trước hiển thị cho người dùng khi nội dung được sao chép vào bảng nhớ tạm cho bất kỳ mục ClipData
nào mà ClipData.getDescription().getExtras()
chứa android.content.extra.IS_SENSITIVE
, thì các phương thức đó:
- [C-1-1] PHẢI loại bỏ bản xem trước mà người dùng nhìn thấy
Phương thức triển khai tham chiếu AOSP đáp ứng các yêu cầu này đối với bảng nhớ tạm.
3.9. Quản trị thiết bị
Android bao gồm các tính năng cho phép các ứng dụng có tính năng bảo mật thực hiện các chức năng quản trị thiết bị ở cấp hệ thống, chẳng hạn như thực thi chính sách mật khẩu hoặc xoá từ xa thông qua Android Device Administration API.
If device implementations implement the full range of device administration policies defined in the Android SDK documentation, they:
- [C-1-1] PHẢI khai báo
android.software.device_admin
. - [C-1-2] PHẢI hỗ trợ việc cấp quyền cho chủ sở hữu thiết bị như mô tả trong mục 3.9.1 và mục 3.9.1.1.
3.9.1 Cấp phép thiết bị
3.9.1.1 Cấp phép cho chủ sở hữu thiết bị
If device implementations declare android.software.device_admin
, they:
- [C-1-1] PHẢI hỗ trợ việc đăng ký ứng dụng Trình quản lý chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị như mô tả dưới đây:
- Khi quá trình triển khai thiết bị không có người dùng cũng như dữ liệu người dùng được định cấu hình, thì quá trình này:
- [C-1-5] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị hoặc cho phép ứng dụng DPC chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, nếu thiết bị khai báo hỗ trợ Giao tiếp phạm vi gần (NFC) thông qua cờ tính năng
android.hardware.nfc
và nhận được thông báo NFC chứa bản ghi có loại MIME làMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] PHẢI gửi ý định ACTION_GET_PROVISIONING_MODE sau khi quá trình cấp phép cho chủ sở hữu thiết bị được kích hoạt để ứng dụng DPC có thể chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, tuỳ thuộc vào các giá trị của
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, trừ phi có thể xác định được từ ngữ cảnh rằng chỉ có một tuỳ chọn hợp lệ. - [C-1-9] PHẢI gửi ý định ACTION_ADMIN_POLICY_COMPLIANCE đến ứng dụng Chủ sở hữu thiết bị nếu Chủ sở hữu thiết bị được thiết lập trong quá trình cấp phép, bất kể phương thức cấp phép được sử dụng. Người dùng không được phép tiếp tục trong Trình hướng dẫn thiết lập cho đến khi ứng dụng Chủ sở hữu thiết bị hoàn tất.
- [C-1-5] PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị hoặc cho phép ứng dụng DPC chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, nếu thiết bị khai báo hỗ trợ Giao tiếp phạm vi gần (NFC) thông qua cờ tính năng
- Khi quá trình triển khai thiết bị có người dùng hoặc dữ liệu người dùng, thì quá trình triển khai đó:
- [C-1-7] KHÔNG ĐƯỢC đăng ký bất kỳ ứng dụng DPC nào làm Ứng dụng của chủ sở hữu thiết bị nữa.
- Khi quá trình triển khai thiết bị không có người dùng cũng như dữ liệu người dùng được định cấu hình, thì quá trình này:
[C-1-2] PHẢI hiển thị thông báo công bố thích hợp (chẳng hạn như được tham chiếu trong AOSP) và nhận được sự đồng ý rõ ràng của người dùng cuối trước khi thiết lập ứng dụng làm Chủ sở hữu thiết bị, trừ phi thiết bị được định cấu hình bằng cách lập trình cho Chế độ minh hoạ tại cửa hàng bán lẻ trước khi người dùng cuối tương tác trên màn hình. Nếu các phương thức triển khai thiết bị khai báo
android.software.device_admin
, nhưng cũng bao gồm một giải pháp quản lý thiết bị độc quyền và cung cấp cơ chế để quảng bá một ứng dụng được định cấu hình trong giải pháp của họ dưới dạng "Tương đương với Chủ sở hữu thiết bị" với "Chủ sở hữu thiết bị" tiêu chuẩn do các API DevicePolicyManager Android tiêu chuẩn công nhận, thì các phương thức triển khai thiết bị đó:[C-2-1] PHẢI có quy trình để xác minh rằng ứng dụng cụ thể đang được quảng bá thuộc về một giải pháp quản lý thiết bị doanh nghiệp hợp pháp và đã được định cấu hình trong giải pháp độc quyền để có các quyền tương đương với "Chủ sở hữu thiết bị".
[C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by
android.app.action.PROVISION_MANAGED_DEVICE
prior to enrolling the DPC application as "Device Owner".[C-2-3] KHÔNG ĐƯỢC mã hoá cứng trạng thái đồ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ị.
3.9.1.2 Managed profile provisioning
If device implementations declare android.software.managed_users
, they:
[C-1-1] MUST implement the APIs allowing a Device Policy Controller (DPC) application to become the owner of a new Managed Profile.
[C-1-2] Quy trình cấp hồ sơ được quản lý (quy trình do DPC khởi tạo bằng cách sử dụng android.app.action.PROVISION_MANAGED_PROFILE) hoặc do nền tảng khởi tạo), màn hình đồng ý và trải nghiệm người dùng PHẢI phù hợp với cách triển khai AOSP.
[C-1-3] MUST provide the following user affordances within the Settings to indicate to the user when a particular system function has been disabled by the Device Policy Controller (DPC):
- A consistent icon or other user affordance (for example the upstream AOSP info icon) to represent when a particular setting is restricted by a Device Admin.
- A short explanation message, as provided by the Device Admin via the
setShortSupportMessage
. - Biểu tượng của ứng dụng DPC.
[C-1-4] PHẢI chạy trình xử lý cho ý định ACTION_PROVISIONING_SUCCESSFUL trong hồ sơ công việc nếu Chủ sở hữu hồ sơ được thiết lập khi quá trình cấp phép được bắt đầu bằng ý định android.app.action.PROVISION_MANAGED_PROFILE và DPC đã triển khai trình xử lý.
[C-1-5] PHẢI gửi thông báo ACTION_PROFILE_PROVISIONING_COMPLETE tới DPC hồ sơ công việc khi quá trình cấp phép được bắt đầu bằng ý định android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] PHẢI gửi ý định ACTION_GET_PROVISIONING_MODE sau khi quá trình cấp quyền cho chủ sở hữu hồ sơ được kích hoạt để ứng dụng DPC có thể chọn trở thành Chủ sở hữu thiết bị hay Chủ sở hữu hồ sơ, ngoại trừ trường hợp quá trình cấp quyền được kích hoạt bằng ý định android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] PHẢI gửi ý định ACTION_ADMIN_POLICY_COMPLIANCE đến hồ sơ công việc khi Chủ sở hữu hồ sơ được thiết lập trong quá trình cấp phép, bất kể phương thức cấp phép nào được sử dụng, ngoại trừ khi quá trình cấp phép được kích hoạt bằng ý định android.app.action.PROVISION_MANAGED_PROFILE. Người dùng không được phép tiếp tục trong Trình hướng dẫn thiết lập cho đến khi ứng dụng Chủ sở hữu hồ sơ hoàn tất.
[C-1-8] PHẢI gửi thông báo truyền tin ACTION_MANAGED_PROFILE_PROVISIONED đến DPC hồ sơ cá nhân khi Chủ sở hữu hồ sơ được thiết lập, bất kể phương thức cấp phép được sử dụng.
3.9.2 Hỗ trợ hồ sơ được quản lý
If device implementations declare android.software.managed_users
, they:
- [C-1-1] MUST support managed profiles via the
android.app.admin.DevicePolicyManager
APIs. - [C-1-2] PHẢI cho phép tạo một và chỉ một hồ sơ được quản lý.
- [C-1-3] PHẢI sử dụng huy hiệu biểu tượng (tương tự như huy hiệu công việc ngược dòng AOSP) để đại diện cho các ứng dụng và tiện ích được quản lý cũng như các thành phần giao diện người dùng có huy hiệu khác như Gần đây và Thông báo.
- [C-1-4] MUST display a notification icon (similar to the AOSP upstream work badge) to indicate when user is within a managed profile application.
- [C-1-5] PHẢI hiển thị thông báo ngắn cho biết người dùng đang ở trong hồ sơ được quản lý nếu và khi thiết bị thức dậy (ACTION_USER_PRESENT) và ứng dụng trên nền trước nằm trong hồ sơ được quản lý.
- [C-1-6] Where a managed profile exists, MUST show a visual affordance in the Intent 'Chooser' to allow the user to forward the intent from the managed profile to the primary user or vice versa, if enabled by the Device Policy Controller.
- [C-1-7] Where a managed profile exists, MUST expose the following user
affordances for both the primary user and the managed profile:
- Separate accounting for battery, location, mobile data and storage usage for the primary user and managed profile.
- Independent management of VPN Applications installed within the primary user or managed profile.
- Independent management of applications installed within the primary user or managed profile.
- Independent management of accounts within the primary user or managed profile.
- [C-1-8] PHẢI đảm bảo rằng ứng dụng trình quay số, danh bạ và nhắn tin được cài đặt sẵn có thể tìm kiếm và tra cứu thông tin người gọi từ hồ sơ được quản lý (nếu có) cùng với thông tin từ hồ sơ chính, nếu Trình điều khiển chính sách thiết bị cho phép.
- [C-1-9] PHẢI đảm bảo rằng thiết bị đó đáp ứng tất cả các yêu cầu bảo mật áp dụng cho thiết bị có nhiều người dùng (xem mục 9.5), mặc dù hồ sơ được quản lý không được tính là một người dùng khác ngoài người dùng chính.
Bắt đầu yêu cầu mới
- [C-1-10] PHẢI đảm bảo rằng dữ liệu ảnh chụp màn hình được lưu trong bộ nhớ hồ sơ công việc khi ảnh chụp màn hình được chụp bằng cửa sổ
topActivity
có tâm điểm (tâm điểm mà người dùng tương tác gần đây nhất trong số tất cả các hoạt động) và thuộc về một ứng dụng hồ sơ công việc. - [C-1-11] KHÔNG ĐƯỢC chụp bất kỳ nội dung màn hình nào khác (thanh hệ thống, thông báo hoặc bất kỳ nội dung hồ sơ cá nhân nào) ngoại trừ cửa sổ/cửa sổ của ứng dụng hồ sơ công việc khi lưu ảnh chụp màn hình vào hồ sơ công việc (để đảm bảo rằng dữ liệu hồ sơ cá nhân không được lưu trong hồ sơ công việc).
Kết thúc các yêu cầu mới
If device implementations declare android.software.managed_users
and
android.software.secure_lock_screen
, they:
- [C-2-1] PHẢI hỗ trợ khả năng chỉ định một màn hình khoá riêng biệt đáp ứng các yêu cầu sau để chỉ cấp quyền truy cập cho các ứng dụng chạy trong hồ sơ được quản lý.
- Việc triển khai thiết bị PHẢI tuân thủ ý định
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
và hiển thị giao diện để định cấu hình thông tin xác thực màn hình khoá riêng biệt cho hồ sơ được quản lý. - The lock screen credentials of the managed profile MUST use the same credential storage and management mechanisms as the parent profile, as documented on the Android Open Source Project Site.
- Chính sách mật khẩu của DPC CHỈ được áp dụng cho thông tin xác thực màn hình khoá của hồ sơ được quản lý, trừ phi được gọi trên thực thể
DevicePolicyManager
do getParentProfileInstance trả về.
- Việc triển khai thiết bị PHẢI tuân thủ ý định
- Khi danh bạ trong hồ sơ được quản lý xuất hiện trong nhật ký cuộc gọi được cài đặt sẵn, giao diện người dùng trong cuộc gọi, thông báo về cuộc gọi đang diễn ra và cuộc gọi nhỡ, danh bạ và ứng dụng nhắn tin, các ứng dụng đó PHẢI được gắn huy hiệu giống với huy hiệu dùng để chỉ các ứng dụng trong hồ sơ được quản lý.
3.9.3 Managed User Support
If device implementations declare android.software.managed_users
, they:
- [C-1-1] MUST provide a user affordance to logout from the current user and
switch back to the primary user in multiple-user session when
isLogoutEnabled
returnstrue
. Người dùng PHẢI truy cập được vào chức năng của mình từ màn hình khoá mà không cần mở khoá thiết bị.
Nếu các phương thức triển khai thiết bị khai báo android.software.device_admin
và cung cấp một tính năng hỗ trợ người dùng trên thiết bị để thêm Người dùng phụ, thì các phương thức đó:
- [C-SR-1] NÊN hiển thị cùng một thông tin công bố về sự đồng ý của Chủ sở hữu thiết bị AOSP đã hiển thị trong quy trình do android.app.action.PROVISION_MANAGED_DEVICE khởi tạo, trước khi cho phép thêm tài khoản trong Người dùng phụ mới, để người dùng hiểu rằng thiết bị được quản lý.
3.9.4 Yêu cầu về vai trò Quản lý chính sách thiết bị
If device implementations report android.software.device_admin
or
android.software.managed_users
, then they:
- [C-1-1] PHẢI hỗ trợ vai trò quản lý chính sách thiết bị như được xác định trong mục 9.1. Bạn CÓ THỂ xác định ứng dụng giữ vai trò quản lý chính sách thiết bị bằng cách đặt
config_devicePolicyManagement
thành tên gói. Tên gói PHẢI theo sau là:
và chứng chỉ ký, trừ phi ứng dụng được tải sẵn.
Nếu bạn không xác định tên gói cho config_devicePolicyManagement
như mô tả ở trên:
- [C-2-1] Các phương thức triển khai thiết bị PHẢI hỗ trợ việc cấp phép mà không cần ứng dụng của chủ sở hữu vai trò quản lý chính sách thiết bị (AOSP cung cấp phương thức triển khai tham khảo).
Nếu tên gói được xác định cho config_devicePolicyManagement
như mô tả ở trên:
- [C-3-1] Ứng dụng PHẢI được cài đặt trên tất cả hồ sơ cho một người dùng.
- [C-3-2] Việc triển khai thiết bị CÓ THỂ xác định một ứng dụng cập nhật chủ sở hữu vai trò quản lý chính sách thiết bị trước khi cấp phép bằng cách đặt
config_devicePolicyManagementUpdater
.
Nếu tên gói được xác định cho config_devicePolicyManagementUpdater
như mô tả ở trên:
- [C-4-1] Ứng dụng PHẢI được cài đặt trước trên thiết bị.
- [C-4-2] Ứng dụng PHẢI triển khai một bộ lọc ý định giúp phân giải
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
Bắt đầu yêu cầu mới
3.9.5 Khung giải quyết chính sách thiết bị
If device implementations report android.software.device_admin
or
android.software.managed_users
, then they:
- [C-1-1] PHẢI giải quyết xung đột chính sách thiết bị như được ghi nhận trong Khung giải quyết chính sách thiết bị.
Kết thúc các yêu cầu mới
3.10. Hỗ trợ tiếp cận
Android cung cấp một lớp hỗ trợ tiếp cận giúp người dùng khuyết tật dễ dàng thao tác trên thiết bị của họ hơn. Ngoài ra, Android cung cấp các API nền tảng cho phép triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho các sự kiện của người dùng và hệ thống, đồng thời tạo các cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng bằng bi xoay/d-pad.
If device implementations support third-party accessibility services, they:
- [C-1-1] PHẢI triển khai khung hỗ trợ tiếp cận Android như mô tả trong tài liệu SDK về API hỗ trợ tiếp cận.
- [C-1-2] PHẢI tạo các sự kiện hỗ trợ tiếp cận và phân phối
AccessibilityEvent
thích hợp cho tất cả các phương thức triển khaiAccessibilityService
đã đăng ký như được ghi nhận trong SDK. - [C-1-4] PHẢI cung cấp cho người dùng khả năng kiểm soát các dịch vụ hỗ trợ tiếp cận khai báo AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Lưu ý rằng đối với các phương thức triển khai thiết bị có thanh điều hướng hệ thống, các phương thức này PHẢI cho phép người dùng có lựa chọn về nút trong thanh điều hướng của hệ thống để điều khiển các dịch vụ này.
If device implementations include preinstalled accessibility services, they:
- [C-2-1] PHẢI triển khai các dịch vụ hỗ trợ tiếp cận được cài đặt sẵn này dưới dạng ứng dụng Nhận biết chế độ khởi động trực tiếp khi bộ nhớ dữ liệu được mã hoá bằng phương thức Mã hoá dựa trên tệp (FBE).
- SHOULD provide a mechanism in the out-of-box setup flow for users to enable relevant accessibility services, as well as options to adjust the font size, display size and magnification gestures.
3.11. Chuyển văn bản sang lời nói
Android bao gồm các API cho phép ứng dụng sử dụng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ cung cấp các phương thức triển khai dịch vụ TTS.
If device implementations reporting the feature android.hardware.audio.output, they:
- [C-1-1] PHẢI hỗ trợ các API của khung Android TTS.
If device implementations support installation of third-party TTS engines, they:
- [C-2-1] MUST provide user affordance to allow the user to select a TTS engine for use at system level.
3.12. Khung đầu vào TV
Android Television Input Framework (TIF) đơn giản hoá việc phân phối nội dung trực tiếp đến các thiết bị Android Television. TIF cung cấp một API tiêu chuẩn để tạo các mô-đun đầu vào điều khiển thiết bị Android Television.
If device implementations support TIF, they:
- [C-1-1] MUST declare the platform feature
android.software.live_tv
. - [C-1-2] PHẢI hỗ trợ tất cả API TIF để ứng dụng sử dụng các API này và dịch vụ dữ liệu đầu vào dựa trên TIF của bên thứ ba có thể được cài đặt và sử dụng 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 Quick Settings (Cài đặt nhanh) cho phép truy cập nhanh vào các thao tác thường dùng hoặc cần thiết khẩn cấp.
If device implementations include a Quick Settings UI component and support third-party Quick Settings, they:
- [C-1-1] PHẢI cho phép người dùng thêm hoặc xoá các thẻ thông tin được cung cấp thông qua API
quicksettings
của một ứng dụng bên thứ ba. - [C-1-2] KHÔNG ĐƯỢC tự động thêm thẻ thông tin từ ứng dụng bên thứ ba trực tiếp vào phần Cài đặt nhanh.
- [C-1-3] MUST display all the user-added tiles from third-party apps alongside the system-provided quick setting tiles.
3.14. Giao diện người dùng đa phương tiện
Nếu các phương thức triển khai thiết bị bao gồm các ứng dụng không kích hoạt bằng giọng nói (Ứng dụng) tương tác với các ứng dụng bên thứ ba thông qua MediaBrowser
hoặc MediaSession
, thì các Ứng dụng đó:
[C-1-2] PHẢI hiển thị rõ các biểu tượng thu được qua
getIconBitmap()
hoặcgetIconUri()
và tiêu đề thu được quagetTitle()
như mô tả trongMediaDescription
. Có thể rút ngắn tiêu đề để tuân thủ các quy định về an toàn (ví dụ: gây mất tập trung cho người lái xe).[C-1-3] PHẢI hiển thị biểu tượng ứng dụng bên thứ ba bất cứ khi nào hiển thị nội dung do ứng dụng bên thứ ba này cung cấp.
[C-1-4] PHẢI cho phép người dùng tương tác với toàn bộ hệ thống phân cấp
MediaBrowser
. CÓ THỂ hạn chế quyền truy cập vào một phần của hệ phân cấp để tuân thủ các quy định về an toàn (ví dụ: làm người lái xe mất tập trung), nhưng KHÔNG ĐƯỢC ưu tiên xử lý dựa trên nội dung hoặc nhà cung cấp nội dung.[C-1-5] PHẢI xem xét thao tác nhấn đúp vào
KEYCODE_HEADSETHOOK
hoặcKEYCODE_MEDIA_PLAY_PAUSE
dưới dạngKEYCODE_MEDIA_NEXT
choMediaSession.Callback#onMediaButtonEvent
.
3.15. Ứng dụng tức thì
Nếu triển khai trên thiết bị hỗ trợ Ứng dụng tức thì, thì thiết bị đó PHẢI đáp ứng các yêu cầu sau:
- [C-1-1] Ứng dụng tức thì CHỈ ĐƯỢC cấp các quyền có
android:protectionLevel
được đặt thành"instant"
. - [C-1-2] Instant Apps MUST NOT tương tác với các ứng dụng đã cài đặt thông qua ý định ngầm ẩn, trừ phi một trong những điều sau đây là đúng:
- Bộ lọc mẫu ý định của thành phần được hiển thị và có CATEGORY_BROWSABLE
- The action is one of ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- The target is explicitly exposed with android:visibleToInstantApps
- [C-1-3] Ứng dụng tức thì KHÔNG ĐƯỢC tương tác rõ ràng với các ứng dụng đã cài đặt, trừ phi thành phần được hiển thị thông qua android:visibleToInstantApps.
- [C-1-4] Ứng dụng đã cài đặt KHÔNG ĐƯỢC xem thông tin chi tiết về Ứng dụng tức thì trên thiết bị, trừ phi Ứng dụng tức thì kết nối rõ ràng với ứng dụng đã cài đặt.
Việc triển khai thiết bị PHẢI cung cấp các tính năng hỗ trợ người dùng sau đây để tương tác với Ứng dụng tức thì. AOSP đáp ứng các yêu cầu với giao diện người dùng hệ thống, phần Cài đặt và Trình chạy mặc định. Device implementations:
- [C-1-5] PHẢI cung cấp cho người dùng khả năng xem và xoá Ứng dụng tức thì được lưu vào bộ nhớ đệm cục bộ cho từng gói ứng dụng riêng lẻ.
- [C-1-6] PHẢI cung cấp thông báo liên tục cho người dùng mà có thể thu gọn trong khi Ứng dụng tức thì đang chạy trên nền trước. Thông báo cho người dùng này PHẢI cho biết rằng Ứng dụng tức thì không yêu cầu cài đặt và cung cấp cho người dùng một tính năng giúp họ chuyển đến màn hình thông tin ứng dụng trong phần Cài đặt. Đối với Ứng dụng tức thì được khởi chạy thông qua ý định web, như được xác định bằng cách sử dụng ý định có hành động được đặt thành
Intent.ACTION_VIEW
và có giao thức "http" hoặc "https", một khả năng khác của người dùng PHẢI cho phép người dùng không khởi chạy Ứng dụng tức thì và khởi chạy đường liên kết được liên kết bằng trình duyệt web đã định cấu hình, nếu có trình duyệt trên thiết bị. - [C-1-7] PHẢI cho phép truy cập vào các Ứng dụng tức thì đang chạy từ chức năng Recents (Gần đây) nếu chức năng Recents có trên thiết bị.
[C-1-8] PHẢI tải trước một hoặc nhiều ứng dụng hoặc thành phần dịch vụ bằng trình xử lý ý định cho các ý định được liệt kê trong SDK tại đây và hiển thị các ý định đó cho Ứng dụng tức thì.
3.16. Ghép nối thiết bị đồng hành
Android hỗ trợ tính năng ghép nối thiết bị đồng hành để quản lý hiệu quả hơn mối liên kết với thiết bị đồng hành và cung cấp API CompanionDeviceManager
cho các ứng dụng để truy cập tính năng này.
If device implementations support the companion device pairing feature, they:
- [C-1-1] MUST declare the feature flag
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 các chức năng hỗ trợ người dùng để người dùng có thể chọn/xác nhận rằng thiết bị đồng hành có mặt và hoạt động.
3.17. Ứng dụng nặng
If device implementations declare the feature FEATURE_CANT_SAVE_STATE
,
then they:
- [C-1-1] CHỈ ĐƯỢC có một ứng dụng đã cài đặt chỉ định
cantSaveState
đang chạy trong hệ thống tại một thời điểm. Nếu người dùng rời khỏi một ứng dụng như vậy mà không thoát ứng dụng một cách rõ ràng (ví dụ: nhấn vào nút màn hình chính trong khi rời khỏi một hoạt động đang hoạt động trong hệ thống, thay vì nhấn nút quay lại khi không còn hoạt động nào đang hoạt động trong hệ thống), thì việc triển khai thiết bị PHẢI ưu tiên ứng dụng đó trong RAM như đối với các ứng dụng khác dự kiến sẽ tiếp tục chạy, chẳng hạn như dịch vụ trên nền trước. Khi ứng dụng đó chạy ở chế độ nền, hệ thống vẫn có thể áp dụng các tính năng quản lý nguồn điện cho ứng dụng, chẳng hạn như giới hạn quyền truy cập vào CPU và mạng. - [C-1-2] PHẢI cung cấp một chức năng trên giao diện người dùng để chọn ứng dụng sẽ không tham gia vào cơ chế lưu/khôi phục trạng thái thông thường sau khi người dùng chạy một ứng dụng thứ hai được khai báo bằng thuộc tính
cantSaveState
. - [C-1-3] KHÔNG ĐƯỢC áp dụng các thay đổi khác trong chính sách cho các ứng dụng chỉ định
cantSaveState
, chẳng hạn như thay đổi hiệu suất CPU hoặc thay đổi mức độ ưu tiên lên lịch.
If device implementations don't declare the feature
FEATURE_CANT_SAVE_STATE
,
then they:
- [C-1-1] PHẢI bỏ qua thuộc tính
cantSaveState
do ứng dụng đặt và KHÔNG ĐƯỢC thay đổi hành vi của ứng dụng dựa trên thuộc tính đó.
3.18. Danh bạ
Android bao gồm các API Contacts Provider
để cho phép các ứng dụng quản lý thông tin liên hệ được lưu trữ trên thiết bị.
Dữ liệu liên hệ được nhập trực tiếp vào thiết bị thường được đồng bộ hoá với một dịch vụ web, nhưng dữ liệu này cũng CÓ THỂ chỉ nằm trên thiết bị.
Những người liên hệ chỉ được lưu trữ trên thiết bị được gọi là người liên hệ cục bộ.
RawContacts được "liên kết với" hoặc "lưu trữ trong" một Tài khoản khi các cột ACCOUNT_NAME
và ACCOUNT_TYPE
cho các liên hệ thô khớp với các trường Account.name và Account.type tương ứng của tài khoản.
Tài khoản cục bộ mặc định: tài khoản cho các liên hệ thô chỉ được lưu trữ trên thiết bị và không liên kết với Tài khoản trong AccountManager. Tài khoản này được tạo bằng các giá trị rỗng cho cột ACCOUNT_NAME
và ACCOUNT_TYPE
.
Tài khoản cục bộ tuỳ chỉnh: tài khoản cho các liên hệ thô chỉ được lưu trữ trên thiết bị và không liên kết với Tài khoản trong AccountManager. Tài khoản này được tạo bằng ít nhất một giá trị khác rỗng cho các cột ACCOUNT_NAME
và ACCOUNT_TYPE
.
Device implementations:
- [C-SR-1] Bạn KHÔNG NÊN tạo tài khoản cục bộ tuỳ chỉnh.
Nếu quá trình triển khai thiết bị sử dụng tài khoản cục bộ tuỳ chỉnh:
- [C-1-1]
ContactsContract.RawContacts.getLocalAccountName
PHẢI trả vềACCOUNT_NAME
của tài khoản cục bộ tuỳ chỉnh - [C-1-2]
ContactsContract.RawContacts.getLocalAccountType
PHẢI trả vềACCOUNT_TYPE
của tài khoản cục bộ tuỳ chỉnh - [C-1-3] Bạn PHẢI chèn các thông tin liên hệ thô do các ứng dụng bên thứ ba chèn bằng tài khoản cục bộ mặc định (tức là bằng cách đặt giá trị rỗng cho
ACCOUNT_NAME
vàACCOUNT_TYPE
) vào tài khoản cục bộ tuỳ chỉnh. - [C-1-4] KHÔNG được xoá các thông tin liên hệ thô được chèn vào tài khoản cục bộ tuỳ chỉnh khi thêm hoặc xoá tài khoản.
- [C-1-5] Các thao tác xoá được thực hiện đối với tài khoản cục bộ tuỳ chỉnh
PHẢI dẫn đến việc xoá ngay các địa chỉ liên hệ thô (như thể
tham số
CALLER_IS_SYNCADAPTER
được đặt thành true), ngay cả khi tham sốCALLER\_IS\_SYNCADAPTER
được đặt thành false hoặc không được chỉ định.
4. Khả năng tương thích của tính năng đóng gói ứng dụng
Devices implementations:
[C-0-1] MUST be capable of installing and running Android ".apk" files as generated by the "aapt" tool included in the official Android SDK.
- As the above requirement may be challenging, device implementations are RECOMMENDED to use the AOSP reference implementation's package management system.
[C-0-2] PHẢI hỗ trợ xác minh tệp ".apk" bằng Lược đồ chữ ký APK phiên bản 3.1, Lược đồ chữ ký APK phiên bản 3, Lược đồ chữ ký APK phiên bản 2 và kỹ thuật 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 RenderScript theo cách khiến các tệp đó không cài đặt và chạy chính xác trên các thiết bị tương thích khác.
[C-0-4] KHÔNG ĐƯỢC cho phép các ứng dụng khác ngoài "trình cài đặt bản ghi" hiện tại của gói gỡ cài đặt ứng dụng mà không cần người dùng xác nhận, như được ghi nhận trong SDK cho quyền
DELETE_PACKAGE
. The only exceptions are the system package verifier app handling PACKAGE_NEEDS_VERIFICATION intent and the storage manager app handling ACTION_MANAGE_STORAGE intent.[C-0-5] PHẢI có một hoạt động xử lý ý định
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] KHÔNG ĐƯỢC cài đặt gói ứng dụng từ các nguồn không xác định, trừ phi ứng dụng yêu cầu cài đặt đáp ứng tất cả các yêu cầu sau:
- Ứng dụng PHẢI khai báo quyền
REQUEST_INSTALL_PACKAGES
hoặc đặtandroid:targetSdkVersion
ở cấp 24 trở xuống. - Người dùng PHẢI cấp quyền cài đặt ứng dụng từ các nguồn không xác định.
- Ứng dụng PHẢI khai báo quyền
NÊN cung cấp cho người dùng khả năng cấp/thu hồi quyền cài đặt ứng dụng từ các nguồn không xác định cho mỗi ứng dụng, nhưng CÓ THỂ chọn triển khai quyền này dưới dạng không hoạt động và trả về
RESULT_CANCELED
chostartActivityForResult()
nếu việc triển khai thiết bị không muốn cho phép người dùng có lựa chọn này. Tuy nhiên, ngay cả trong những trường hợp như vậy, ứng dụng CẦN phải cho người dùng biết lý do không có lựa chọn như vậy.[C-0-7] PHẢI hiển thị hộp thoại cảnh báo với chuỗi cảnh báo được cung cấp thông qua API hệ thống
PackageManager.setHarmfulAppWarning
cho người dùng trước khi khởi chạy một hoạt động trong ứng dụng đã được đánh dấu là có thể gây hại bởi cùng một API hệ thốngPackageManager.setHarmfulAppWarning
.SHOULD provide a user affordance to choose to uninstall or launch an application on the warning dialog.
[C-0-8] PHẢI triển khai tính năng hỗ trợ Hệ thống tệp tăng dần như được ghi nhận tại đây.
[C-0-9] PHẢI hỗ trợ việc xác minh tệp .apk bằng Lược đồ chữ ký APK v4 và Lược đồ chữ ký APK v4.1.
5. Khả năng tương thích đa phương tiện
Device implementations:
- [C-0-1] MUST support the media formats, encoders, decoders, file types,
and container formats defined in section 5.1
for each and every codec declared by
MediaCodecList
. - [C-0-2] PHẢI khai báo và báo cáo việc hỗ trợ bộ mã hoá, bộ giải mã có sẵn cho các ứng dụng bên thứ ba thông qua
MediaCodecList
. - [C-0-3] MUST be able to properly decode and make available to third-party
apps all the formats it can encode. Điều này bao gồm tất cả các luồng bit mà bộ mã hoá tạo ra và các hồ sơ được báo cáo trong
CamcorderProfile
.
Device implementations:
- SHOULD aim for minimum codec latency, in others words, they
- SHOULD NOT consume and store input buffers and return input buffers only once processed.
- SHOULD NOT hold onto decoded buffers for longer than as specified by the standard (e.g. SPS).
- SHOULD NOT hold onto encoded buffers longer than required by the GOP structure.
Tất cả bộ mã hoá và giải mã được liệt kê trong phần bên dưới đều được cung cấp dưới dạng phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên của Dự án nguồn mở Android.
Xin lưu ý rằng cả Google và Open Handset Alliance đều không đưa ra bất kỳ tuyên bố nào rằng các bộ mã hoá và giải mã này không bị ràng buộc bởi bằng sáng chế của bên thứ ba. Những người dự định sử dụng mã nguồn này trong các sản phẩm phần cứng hoặc phần mềm nên lưu ý rằng việc triển khai mã này, bao gồm cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép phát minh của các chủ sở hữu bằng phát minh có liên quan.
5.1. Bộ mã hoá và giải mã nội dung nghe nhìn
5.1.1. Mã hoá âm thanh
Xem thêm chi tiết trong phần 5.1.3. Audio Codecs Details.
Nếu các phương thức triển khai thiết bị khai báo android.hardware.microphone
, thì các phương thức đó PHẢI hỗ trợ việc mã hoá các định dạng âm thanh sau và cung cấp các định dạng đó cho 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] Khung âm thanh theo thứ tự byte gốc PCM 16 bit thông qua API
android.media.MediaCodec
.
5.1.2. Giải mã âm thanh
Xem thêm chi tiết trong phần 5.1.3. Audio Codecs Details.
Nếu các phương thức triển khai thiết bị khai báo hỗ trợ tính năng android.hardware.audio.output
, thì các phương thức đó phải hỗ trợ giải mã các định dạng âm thanh sau:
- [C-1-1] MPEG-4 AAC Profile (AAC LC)
- [C-1-2] MPEG-4 HE AAC Profile (AAC+)
- [C-1-3] MPEG-4 HE AACv2 Profile (enhanced AAC+)
- [C-1-4] AAC ELD (enhanced low delay AAC)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes USAC Baseline Profile and ISO/IEC 23003-4 Dynamic Range Control Profile)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE bao gồm các định dạng âm thanh có độ phân giải cao lên đến 24 bit, tốc độ lấy mẫu 192 kHz và 8 kênh. Xin lưu ý rằng yêu cầu này chỉ dành cho việc giải mã và thiết bị được phép giảm mẫu và giảm âm trong giai đoạn phát.
- [C-1-10] Opus
Nếu các phương thức triển khai thiết bị hỗ trợ giải mã vùng đệm đầu vào AAC của các luồng đa kênh (tức là nhiều hơn 2 kênh) thành PCM thông qua bộ giải mã âm thanh AAC mặc định trong API android.media.MediaCodec
, thì các tính năng sau đây PHẢI được hỗ trợ:
- [C-2-1] Decoding MUST be performed without downmixing (e.g. a 5.0 AAC stream must be decoded to five channels of PCM, a 5.1 AAC stream must be decoded to six channels of PCM).
- [C-2-2] Siêu dữ liệu về dải động PHẢI tuân theo định nghĩa trong "Chế độ điều khiển dải động (DRC)" theo tiêu chuẩn ISO/IEC 14496-3 và các khoá DRC
android.media.MediaFormat
để định cấu hình các hành vi liên quan đến dải động của bộ giải mã âm thanh. Các khoá DRC AAC được giới thiệu trong API 21, bao gồm:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
vàKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] Tất cả bộ giải mã âm thanh AAC đều NÊN đáp ứng các yêu cầu C-2-1 và C-2-2 ở trên.
Khi giải mã âm thanh USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Thông tin siêu dữ liệu về độ lớn và DRC PHẢI được diễn giải và áp dụng theo Cấu hình điều khiển phạm vi động MPEG-D DRC cấp 1.
- [C-3-2] The decoder MUST behave according to the configuration
set with the following
android.media.MediaFormat
keys:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
andKEY_AAC_DRC_EFFECT_TYPE
.
MPEG-4 AAC, HE AAC và HE AACv2 profile decoders:
- MAY support loudness and dynamic range control using ISO/IEC 23003-4 Dynamic Range Control Profile.
If ISO/IEC 23003-4 is supported and if both ISO/IEC 23003-4 and ISO/IEC 14496-3 metadata are present in a decoded bitstream, then:
- 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] Khung âm thanh theo thứ tự byte gốc PCM 16 bit thông qua API
android.media.MediaCodec
.
Nếu các phương thức triển khai thiết bị hỗ trợ giải mã vùng đệm đầu vào AAC của các luồng đa kênh (tức là nhiều hơn 2 kênh) thành PCM thông qua bộ giải mã âm thanh AAC mặc định trong API android.media.MediaCodec
, thì các tính năng sau đây PHẢI được hỗ trợ:
- [C-7-1] PHẢI có thể được ứng dụng định cấu hình bằng cách sử dụng tính năng giải mã bằng khoá
KEY_MAX_OUTPUT_CHANNEL_COUNT
để kiểm soát việc nội dung có được kết hợp xuống âm thanh nổi (khi sử dụng giá trị 2) hay không hoặc được xuất bằng số lượng kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình bộ giải mã để xuất 6 kênh khi được cung cấp nội dung 5.1. - [C-7-2] Khi giải mã, bộ giải mã PHẢI quảng cáo mặt nạ kênh đang được sử dụng trên định dạng đầu ra bằng khoá
KEY_CHANNEL_MASK
, sử dụng các hằng sốandroid.media.AudioFormat
(ví dụ:CHANNEL_OUT_5POINT1
).
Nếu các phương thức triển khai thiết bị hỗ trợ bộ giải mã âm thanh khác với bộ giải mã âm thanh AAC mặc định và có thể xuất âm thanh đa kênh (tức là nhiều hơn 2 kênh) khi được cung cấp nội dung đa kênh nén, thì:
- [C-SR-2] NÊN cho phép ứng dụng định cấu hình bộ giải mã bằng cách sử dụng tính năng giải mã bằng khoá
KEY_MAX_OUTPUT_CHANNEL_COUNT
để kiểm soát việc nội dung có được kết hợp xuống âm thanh nổi (khi sử dụng giá trị 2) hay không hoặc được xuất bằng số lượng kênh gốc (khi sử dụng giá trị bằng hoặc lớn hơn số đó). Ví dụ: giá trị từ 6 trở lên sẽ định cấu hình bộ giải mã để xuất 6 kênh khi được cung cấp nội dung 5.1. - [C-SR-3] Khi giải mã, bộ giải mã NÊN quảng cáo mặt nạ kênh đang được sử dụng trên định dạng đầu ra bằng khoá
KEY_CHANNEL_MASK
, sử dụng hằng số android.media.AudioFormat (ví dụ:CHANNEL_OUT_5POINT1
).
5.1.3. Audio Codecs Details
Định dạng/Bộ mã hoá và giải mã | Thông tin chi tiết | Các loại tệp/Định dạng vùng chứa được hỗ trợ |
---|---|---|
MPEG-4 AAC Profile (AAC LC) |
Support for mono/stereo/5.0/5.1 content with standard sampling rates from 8 to 48 kHz. |
|
MPEG-4 HE AAC Profile (AAC+) | Support for mono/stereo/5.0/5.1 content with standard sampling rates from 16 to 48 kHz. |
|
MPEG-4 HE AACv2 Profile (AAC+ nâng cao) |
Support for mono/stereo/5.0/5.1 content with standard sampling rates from 16 to 48 kHz. |
|
AAC ELD (AAC độ trễ thấp nâng cao) | Support for mono/stereo content with standard sampling rates from 16 to 48 kHz. |
|
USAC | Support for mono/stereo content with standard sampling rates from 7.35 to 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75 đến 12,2 kbit/giây, lấy mẫu ở 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây, lấy mẫu ở 16 kHz, như được xác định tại AMR-WB, Đa tỷ lệ thích ứng – Bộ mã hoá và giải mã giọng nói băng tần rộng | 3GPP (.3gp) |
FLAC | Đối với cả bộ mã hoá và bộ giải mã: PHẢI hỗ trợ ít nhất chế độ Mono và Stereo. PHẢI hỗ trợ tốc độ lấy mẫu lên đến 192 kHz; PHẢI hỗ trợ độ phân giải 16 bit và 24 bit. CẦN có chức năng xử lý dữ liệu âm thanh FLAC 24 bit với cấu hình âm thanh dấu phẩy động. |
|
MP3 | Mono/Stereo 8-320Kbps constant (CBR) or variable bitrate (VBR) |
|
MIDI | MIDI Loại 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF dành cho thiết bị di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody |
|
Vorbis | Giải mã: Hỗ trợ nội dung đơn âm, âm thanh nổi, 5.0 và 5.1 với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. Ghi mã: Hỗ trợ nội dung đơn âm và âm thanh nổi với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. |
|
PCM/WAVE | Bộ mã hoá và giải mã PCM PHẢI hỗ trợ PCM tuyến tính 16 bit và dấu phẩy động 16 bit. Trình trích xuất WAVE phải hỗ trợ PCM tuyến tính 16 bit, 24 bit, 32 bit và dấu phẩy động 32 bit (tốc độ lên đến giới hạn của phần cứng). TỐI THIỂU phải hỗ trợ tốc độ lấy mẫu từ 8 kHz đến 192 kHz. | WAVE (.wav) |
Opus | Giải mã: Hỗ trợ nội dung đơn âm, âm thanh nổi, 5.0 và 5.1 với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. Mã hoá: Hỗ trợ nội dung đơn âm và âm thanh nổi với tốc độ lấy mẫu là 8000, 12000, 16000, 24000 và 48000 Hz. |
|
5.1.4. Mã hoá hình ảnh
Xem thêm chi tiết trong phần 5.1.6. Image Codecs Details.
Device implementations MUST support encoding the following image encoding:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Bắt đầu yêu cầu mới
- [C-0-4] AVIF
- Thiết bị phải hỗ trợ
BITRATE_MODE_CQ
và Hồ sơ cơ sở.
- Thiết bị phải hỗ trợ
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị hỗ trợ tính năng mã hoá HEIC thông qua android.media.MediaCodec
cho loại nội dung nghe nhìn MIMETYPE_IMAGE_ANDROID_HEIC
,
thì các phương thức đó:
- [C-1-1] PHẢI cung cấp bộ mã hoá và giải mã HEVC tăng tốc phần cứng hỗ trợ chế độ kiểm soát tốc độ bit
BITRATE_MODE_CQ
, hồ sơHEVCProfileMainStill
và kích thước khung hình 512 x 512 pixel.
5.1.5. Giải mã hình ảnh
Xem thêm chi tiết trong phần 5.1.6. Image Codecs Details.
Device implementations MUST support decoding the following image encoding:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Raw
- [C-0-7] AVIF (Hồ sơ cơ sở)
Nếu các phương thức triển khai thiết bị hỗ trợ giải mã video HEVC, thì các phương thức đó: * [C-1-1] PHẢI hỗ trợ giải mã hình ảnh HEIF (HEIC).
Bộ giải mã hình ảnh hỗ trợ định dạng độ sâu bit cao (9 bit trở lên trên mỗi kênh):
- [C-2-1] PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu ứng dụng yêu cầu, ví dụ: thông qua cấu hình
ARGB_8888
củaandroid.graphics.Bitmap
.
5.1.6. Image Codecs Details
Định dạng/Bộ mã hoá và giải mã | Thông tin chi tiết | Supported File Types/Container Formats |
---|---|---|
JPEG | Base+progressive | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
Thô | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Hình ảnh, Bộ sưu tập hình ảnh, Chuỗi hình ảnh | HEIF (.heif), HEIC (.heic) |
AVIF (Hồ sơ cơ sở) | Hồ sơ cơ sở về Hình ảnh, Tập hợp hình ảnh, Trình tự hình ảnh | Vùng chứa HEIF (.avif) |
Bộ mã hoá và giải mã hình ảnh được hiển thị thông qua API MediaCodec
[C-1-1] PHẢI hỗ trợ định dạng màu linh hoạt YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) thông quaCodecCapabilities
.[C-SR-1] STRONGLY RECOMMENDED to support RGB888 color format for input Surface mode.
[C-1-3] PHẢI hỗ trợ ít nhất một trong các định dạng màu YUV420 8:8:8 phẳng hoặc bán phẳng:
COLOR_FormatYUV420PackedPlanar
(tương đương vớiCOLOR_FormatYUV420Planar
) hoặcCOLOR_FormatYUV420PackedSemiPlanar
(tương đương vớiCOLOR_FormatYUV420SemiPlanar
). Bạn NÊN hỗ trợ cả hai.
5.1.7. Bộ mã hoá và giải mã video
- Để đảm bảo chất lượng chấp nhận được của các dịch vụ phát trực tuyến video trên web và hội nghị truyền hình, quá trình triển khai thiết bị PHẢI sử dụng bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu.
If device implementations include a video decoder or encoder:
[C-1-1] Video codecs MUST support output and input bytebuffer sizes that accommodate the largest feasible compressed and uncompressed frame as dictated by the standard and configuration but also not overallocate.
[C-1-2] Bộ mã hoá và giải mã video PHẢI hỗ trợ các định dạng màu linh hoạt YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) thông quaCodecCapabilities
.[C-1-3] Bộ mã hoá và giải mã video PHẢI hỗ trợ ít nhất một trong các định dạng màu phẳng hoặc bán phẳng YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(tương đương vớiCOLOR_FormatYUV420Planar
) hoặcCOLOR_FormatYUV420PackedSemiPlanar
(tương đương vớiCOLOR_FormatYUV420SemiPlanar
). Bạn NÊN hỗ trợ cả hai.[C-SR-1] Các bộ mã hoá và giải mã video ĐƯỢC KHUYẾN KHÍCH mạnh mẽ hỗ trợ ít nhất một trong các định dạng màu YUV420 8:8:8 phẳng hoặc bán phẳng được tối ưu hoá phần cứng (YV12, NV12, NV21 hoặc định dạng được tối ưu hoá tương đương của nhà cung cấp.)
[C-1-5] Bộ giải mã video hỗ trợ định dạng độ sâu bit cao (9 bit trở lên trên mỗi kênh) PHẢI hỗ trợ xuất định dạng tương đương 8 bit nếu ứng dụng yêu cầu. Điều này PHẢI được thể hiện bằng cách hỗ trợ định dạng màu YUV420 8:8:8 thông qua
android.media.MediaCodecInfo
.
If device implementations advertise HDR profile support through
Display.HdrCapabilities
,
they:
- [C-2-1] MUST support HDR static metadata parsing and handling.
If device implementations advertise intra refresh support through
FEATURE_IntraRefresh
in the MediaCodecInfo.CodecCapabilities
class, they:
- [C-3-1] MUST support the refresh periods in the range of 10 – 60 frames and accurately operate within 20% of the configured refresh period.
Trừ phi ứng dụng chỉ định cách khác bằng cách sử dụng khoá định dạng KEY_COLOR_FORMAT
, các hoạt động triển khai bộ giải mã video:
- [C-4-1] PHẢI sử dụng định dạng màu được tối ưu hoá cho màn hình phần cứng theo mặc định nếu được định cấu hình bằng đầu ra Surface.
- [C-4-2] PHẢI mặc định là định dạng màu YUV420 8:8:8 được tối ưu hoá để đọc CPU nếu được định cấu hình để không sử dụng đầu ra Surface.
5.1.8. Danh sách bộ mã hoá và giải mã video
Định dạng/Bộ mã hoá và giải mã | Thông tin chi tiết | Các loại tệp/Định dạng vùng chứa được hỗ trợ |
---|---|---|
H.263 |
|
|
H.264 AVC | See section 5.2 and 5.3 for details |
|
H.265 HEVC | See section 5.3 for details |
|
MPEG-2 | Cấu hình chính |
|
MPEG-4 SP |
|
|
VP8 | See section 5.2 and 5.3 for details |
|
VP9 | See section 5.3 for details |
|
AV1 | Xem mục 5.2 và mục 5.3 để biết thông tin chi tiết |
|
5.1.9. Bảo mật bộ mã hoá và giải mã nội dung nghe nhìn
Device implementations MUST ensure compliance with media codec security features as described below.
Android hỗ trợ OMX, một API tăng tốc đa phương tiện trên nhiều nền tảng, cũng như Codec 2.0, một API tăng tốc đa phương tiện có mức hao tổn thấp.
If device implementations support multimedia, they:
- [C-1-1] PHẢI hỗ trợ bộ mã hoá và giải mã nội dung đa phương tiện thông qua API OMX hoặc Codec 2.0 (hoặc cả hai) như trong Dự án nguồn mở Android và không tắt hoặc lách các biện pháp bảo vệ bảo mật. Điều này không có nghĩa là mọi bộ mã hoá và giải mã PHẢI sử dụng API OMX hoặc Codec 2.0, mà chỉ có nghĩa là PHẢI có khả năng hỗ trợ ít nhất một trong các API này và khả năng hỗ trợ cho các API có sẵn PHẢI bao gồm các biện pháp bảo vệ bảo mật.
- [C-SR-1] Are STRONGLY RECOMMENDED to include support for Codec 2.0 API.
If device implementations do not support the Codec 2.0 API, they:
- [C-2-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm OMX tương ứng từ Dự án nguồn mở Android (nếu có) cho từng định dạng và loại nội dung nghe nhìn (trình mã hoá hoặc 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 của Dự án nguồn mở Android.
- [C-SR-2] Bạn NÊN chạy bộ mã hoá và giải mã phần mềm OMX trong một quy trình bộ mã hoá và giải mã không có quyền truy cập vào trình điều khiển phần cứng ngoài trình ánh xạ bộ nhớ.
If device implementations support Codec 2.0 API, they:
- [C-3-1] PHẢI bao gồm bộ mã hoá và giải mã phần mềm Codec 2.0 tương ứng từ Dự án nguồn mở Android (nếu có) cho từng định dạng và loại nội dung nghe nhìn (bộ mã hoá hoặc bộ giải mã) mà thiết bị hỗ trợ.
- [C-3-2] PHẢI lưu trữ bộ mã hoá và giải mã phần mềm Codec 2.0 trong quy trình bộ mã hoá và giải mã phần mềm như được cung cấp trong Dự án nguồn mở Android để có thể cấp quyền truy cập vào bộ mã hoá và giải mã phần mềm một cách chặt chẽ hơn.
- [C-3-3] Bộ mã hoá và giải mã có tên bắt đầu bằng "c2.android". PHẢI dựa trên mã nguồn của Dự án nguồn mở Android.
5.1.10. Phân tích bộ mã hoá và giải mã nội dung nghe nhìn
Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã nội dung đa phương tiện, thì các phương thức đó:
- [C-1-1] PHẢI trả về các giá trị chính xác của thông tin mô tả bộ mã hoá và giải mã nội dung đa phương tiện thông qua API
MediaCodecInfo
.
Cụ thể:
- [C-1-2] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX". PHẢI sử dụng các API OMX và có tên tuân thủ nguyên tắc đặt tên OMX IL.
- [C-1-3] Bộ mã hoá và giải mã có tên bắt đầu bằng "c2". PHẢI sử dụng API Codec 2.0 và có tên tuân thủ nguyên tắc đặt tên Codec 2.0 cho Android.
- [C-1-4] Bộ mã hoá và giải mã có tên bắt đầu bằng "OMX.google" hoặc "c2.android". KHÔNG được mô tả là nhà cung cấp hoặc tăng tốc phần cứng.
- [C-1-5] Bộ mã hoá và giải mã chạy trong một quy trình bộ mã hoá và giải mã (nhà cung cấp hoặc hệ thống) có quyền truy cập vào trình điều khiển phần cứng (ngoài trình phân bổ và ánh xạ bộ nhớ) KHÔNG ĐƯỢC coi là chỉ phần mềm.
- [C-1-6] Các bộ mã hoá và giải mã không có trong Dự án nguồn mở Android hoặc không dựa trên mã nguồn trong dự án đó PHẢI được mô tả là của nhà cung cấp.
- [C-1-7] Bộ mã hoá và giải mã sử dụng tính năng tăng tốc phần cứng PHẢI được mô tả là tăng tốc phần cứng.
- [C-1-8] Tên bộ mã hoá và giải mã KHÔNG ĐƯỢC gây hiểu lầm. Ví dụ: bộ mã hoá và giải mã có tên "decoder" (bộ giải mã) PHẢI hỗ trợ giải mã và những bộ mã hoá và giải mã có tên "encoder" (bộ mã hoá) PHẢI hỗ trợ mã hoá. Bộ mã hoá và giải mã có tên chứa định dạng nội dung đa phương tiện PHẢI hỗ trợ các định dạng đó.
Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã video:
- [C-2-1] Tất cả bộ mã hoá và giải mã video PHẢI phát hành dữ liệu tốc độ khung hình có thể đạt được cho các kích thước sau đây nếu bộ mã hoá và giải mã hỗ trợ:
SD (chất lượng thấp) | SD (chất lượng cao) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Độ phân giải video |
|
|
|
1920 x 1080 px (ngoài MPEG4, AV1) | 3840 x 2160 px (HEVC, VP9, AV1) |
- [C-2-2] Bộ mã hoá và giải mã video được mô tả là tăng tốc phần cứng PHẢI phát hành thông tin về điểm hiệu suất. Mỗi điểm hiệu suất tiêu chuẩn PHẢI liệt kê tất cả điểm hiệu suất tiêu chuẩn được hỗ trợ (liệt kê trong API
PerformancePoint
), trừ phi các điểm hiệu suất tiêu chuẩn đó được một điểm hiệu suất tiêu chuẩn khác được hỗ trợ bao gồm. - Ngoài ra, nhà sản xuất NÊN phát hành điểm hiệu suất mở rộng nếu họ hỗ trợ hiệu suất video ổn định ngoài một trong những điểm hiệu suất tiêu chuẩn được liệt kê.
5.2. Mã hoá video
- SHOULD NOT be, over two sliding windows, more than 15% over the bitrate between intraframe (I-frame) intervals.
- SHOULD NOT be more than 100% over the bitrate over a sliding window of 1 second.
Bắt đầu yêu cầu mới
Nếu việc triển khai thiết bị hỗ trợ mọi bộ mã hoá video và cung cấp bộ mã hoá đó cho các ứng dụng bên thứ ba, đồng thời đặtMediaFormat.KEY_BITRATE_MODE
thành BITRATE_MODE_VBR
để bộ mã hoá hoạt động ở chế độ Tốc độ bit thay đổi, thì miễn là tốc độ bit đó không ảnh hưởng đến chất lượng tối thiểu, tốc độ bit được mã hoá sẽ :
[C-5-1] PHẢIKHÔNG được vượt quá 15% tốc độ bit giữa các khoảng thời gian khung hình nội bộ (khung hình I) trong một cửa sổ trượt.[C-5-2] MUSTSHOULD NOT be more than 100% over the bitrate over a sliding window of 1 second.
Nếu các phương thức triển khai thiết bị hỗ trợ mọi bộ mã hoá video và cung cấp cho các ứng dụng bên thứ ba, đồng thời đặt MediaFormat.KEY_BITRATE_MODE
thành BITRATE_MODE_CBR
để bộ mã hoá hoạt động ở chế độ tốc độ bit không đổi, thì tốc độ bit được mã hoá:
[C-6-1] PHẢI[C-SR-2] NÊN KHÔNG vượt quá 15% so với tốc độ bit mục tiêu trong một khoảng thời gian trượt là 1 giây.
Kết thúc các yêu cầu mới
If device implementations include an embedded screen display with the
diagonal length of at least 2.5 inches or include a video output port or
declare the support of a camera via the android.hardware.camera.any
feature flag, they:
- [C-1-1] MUST include the support of at least one of the VP8 or H.264 video encoders, and make it available for third-party applications.
- SHOULD support both VP8 and H.264 video encoders, and make it available for third-party applications.
If device implementations support any of the H.264, VP8, VP9 or HEVC video encoders and make it available to third-party applications, they:
- [C-2-1] MUST support dynamically configurable bitrates.
- SHOULD support variable frame rates, where video encoder SHOULD determine instantaneous frame duration based on the timestamps of input buffers, and allocate its bit bucket based on that frame duration.
If device implementations support the MPEG-4 SP video encoder and make it available to third-party apps, they:
- SHOULD support dynamically configurable bitrates for the supported encoder.
Nếu các phương thức triển khai thiết bị cung cấp bộ mã hoá hình ảnh hoặc video tăng tốc phần cứng, đồng thời hỗ trợ một hoặc nhiều(các) máy ảnh phần cứng được đính kèm hoặc có thể cắm được hiển thị thông qua các API android.camera
:
- [C-4-1] tất cả bộ mã hoá hình ảnh và video tăng tốc phần cứng PHẢI hỗ trợ việc mã hoá khung hình từ(các) máy ảnh phần cứng.
- NÊN hỗ trợ việc mã hoá khung hình từ(các) máy ảnh phần cứng thông qua tất cả trình mã hoá video hoặc hình ảnh.
Nếu các phương thức triển khai thiết bị cung cấp tính năng mã hoá HDR, thì các phương thức đó:
- [C-SR-1] NÊN cung cấp trình bổ trợ cho API chuyển mã liền mạch để chuyển đổi từ định dạng HDR sang định dạng SDR.
5.2.1. H.263
If device implementations support H.263 encoders and make it available to third-party apps, they:
- [C-1-1] PHẢI hỗ trợ độ phân giải QCIF (176 x 144) bằng cách sử dụng Hồ sơ cơ sở cấp 45. Không bắt buộc phải có độ phân giải SQCIF.
NÊN hỗ trợ tốc độ bit có thể định cấu hình linh động cho bộ mã hoá được hỗ trợ.
5.2.2. H.264
If device implementations support H.264 codec, they:
- [C-1-1] MUST support Baseline Profile Level 3. Tuy nhiên, việc hỗ trợ ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp khối xếp linh hoạt) và RS (Lát cắt dư thừa) là KHÔNG BẮT BUỘC. Hơn nữa, để duy trì khả năng tương thích với các thiết bị Android khác, bạn NÊN tránh sử dụng ASO, FMO và RS cho Hồ sơ cơ sở bằng bộ mã hoá.
- [C-1-2] MUST support the SD (Standard Definition) video encoding profiles in the following table.
- SHOULD support Main Profile Level 4.
- SHOULD support the HD (High Definition) video encoding profiles as indicated in the following table.
If device implementations report support of H.264 encoding for 720p or 1080p resolution videos through the media APIs, they:
- [C-2-1] MUST support the encoding profiles in the following table.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | |
---|---|---|---|---|
Độ phân giải video | 320 x 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Tốc độ khung hình video | 20 khung hình/giây | 30 fps | 30 fps | 30 fps |
Tốc độ bit của video | 384 Kb/giây | 2 Mb/giây | 4 Mb/giây | 10 Mb/giây |
5.2.3. VP8
If device implementations support VP8 codec, they:
- [C-1-1] MUST support the SD video encoding profiles.
- SHOULD support the following HD (High Definition) video encoding profiles.
- [C-1-2] MUST support writing Matroska WebM files.
- NÊN cung cấp bộ mã hoá và giải mã VP8 phần cứng đáp ứng các yêu cầu về mã hoá phần cứng RTC của dự án WebM để đảm bảo chất lượng chấp nhận được của dịch vụ phát trực tuyến video trên web và hội nghị truyền hình.
If device implementations report support of VP8 encoding for 720p or 1080p resolution videos through the media APIs, they:
- [C-2-1] MUST support the encoding profiles in the following table.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | |
---|---|---|---|---|
Độ phân giải video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30 fps |
Tốc độ bit của video | 800 Kb/giây | 2 Mb/giây | 4 Mb/giây | 10 Mb/giây |
5.2.4. VP9
If device implementations support VP9 codec, they:
- [C-1-2] MUST support Profile 0 Level 3.
- [C-1-1] MUST support writing Matroska WebM files.
- [C-1-3] PHẢI tạo dữ liệu CodecPrivate.
- SHOULD support the HD decoding profiles as indicated in the following table.
- [C-SR-1] NÊN hỗ trợ các cấu hình giải mã HD như được nêu trong bảng sau nếu có bộ mã hoá phần cứng.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Độ phân giải video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình 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 phương thức triển khai thiết bị tuyên bố hỗ trợ Hồ sơ 2 hoặc Hồ sơ 3 thông qua Media API:
- Không bắt buộc phải hỗ trợ định dạng 12 bit.
5.2.5. H.265
If device implementations support H.265 codec, they:
- [C-1-1] PHẢI hỗ trợ Cấu hình chính cấp 3 với độ phân giải tối đa là 512 x 512.
NÊN hỗ trợ các hồ sơ mã hoá HD như được chỉ định trong bảng sau.- [C-SR-1] NÊN hỗ trợ hồ sơ SD 720 x 480 và các hồ sơ mã hoá HD như được chỉ định trong bảng sau nếu có bộ mã hoá phần cứng.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Độ phân giải video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30 fps |
Tốc độ bit của video | 1,6 Mb/giây | 4 Mb/giây | 5 Mb/giây | 20 Mb/giây |
Bắt đầu yêu cầu mới
5.2.6. AV1
Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1, thì các phương thức đó:
- [C-1-1] MUST support Main Profile including 8-bit and 10-bit content.
[C-1-2] PHẢI phát hành dữ liệu hiệu suất, tức là báo cáo dữ liệu hiệu suất thông qua API
getSupportedFrameRatesFor()
hoặcgetSupportedPerformancePoints()
cho các độ phân giải được hỗ trợ trong bảng bên dưới.[C-1-3] PHẢI chấp nhận siêu dữ liệu HDR và xuất siêu dữ liệu đó sang luồng bit
Nếu bộ mã hoá AV1 được tăng tốc phần cứng, thì bộ mã hoá đó:
- [C-2-1] MUST support up to and including HD1080p encoding profile from the table below:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Độ phân giải video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30 fps |
Tốc độ bit của video | 5 Mb/giây | 8 Mb/giây | 16 Mb/giây | 50 Mb/giây |
Kết thúc các yêu cầu mới
5.3. Giải mã video
If device implementations support VP8, VP9, H.264, or H.265 codecs, they:
- [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 mà mỗi bộ mã hoá và giải mã hỗ trợ trên thiết bị.
5.3.1. MPEG-2
If device implementations support MPEG-2 decoders, they:
- [C-1-1] MUST support the Main Profile High Level.
5.3.2. H.263
If device implementations support H.263 decoders, they:
- [C-1-1] PHẢI hỗ trợ Hồ sơ cơ sở cấp 30 (độ phân giải CIF, QCIF và SQCIF ở tốc độ 30 khung hình/giây 384 kbit/giây) và cấp 45 (độ phân giải QCIF và SQCIF ở tốc độ 30 khung hình/giây 128 kbit/giây).
5.3.3. MPEG-4
If device implementations with MPEG-4 decoders, they:
- [C-1-1] MUST support Simple Profile Level 3.
5.3.4. H.264
If device implementations support H.264 decoders, they:
- [C-1-1] MUST support Main Profile Level 3.1 and Baseline Profile. Hỗ trợ ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp khối xếp linh hoạt) và RS (Lát cắt dư thừa) là KHÔNG BẮT BUỘC.
- [C-1-2] MUST be capable of decoding videos with the SD (Standard Definition) profiles listed in the following table and encoded with the Baseline Profile and Main Profile Level 3.1 (including 720p30).
- SHOULD be capable of decoding videos with the HD (High Definition) profiles as indicated in the following table.
Nếu chiều cao do phương thức Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn độ phân giải video, thì các phương thức triển khai thiết bị:
- [C-2-1] MUST support the HD 720p video decoding profiles in the following table.
- [C-2-2] MUST support the HD 1080p video decoding profiles in the following table.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | |
---|---|---|---|---|
Độ phân giải video | 320 x 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Tốc độ khung hình video | 30 fps | 30 fps | 60 khung hình/giây | 30 fps (60 fpsTelevision) |
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)
If device implementations support H.265 codec, they:
- [C-1-1] MUST support the Main Profile Level 3 Main tier and the SD video decoding profiles as indicated in the following table.
- SHOULD support the HD decoding profiles as indicated in the following table.
- [C-1-2] MUST support the HD decoding profiles as indicated in the following table if there is a hardware decoder.
Nếu chiều cao do phương thức Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn độ phân giải video, thì:
- [C-2-1] Device implementations MUST support at least one of H.265 or VP9 decoding of 720, 1080 and UHD profiles.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Độ phân giải video | 352 x 288 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30/60 fps (60 fpsTelevision with H.265 hardware decoding) | 60 khung hình/giây |
Tốc độ bit của video | 600 Kb/giây | 1,6 Mb/giây | 4 Mb/giây | 5 Mb/giây | 20 Mb/giây |
Nếu các phương thức triển khai thiết bị tuyên bố hỗ trợ Hồ sơ HDR thông qua Media API:
- [C-3-1] Việc triển khai thiết bị PHẢI chấp nhận siêu dữ liệu HDR bắt buộc từ ứng dụng, cũng như hỗ trợ trích xuất và xuất siêu dữ liệu HDR bắt buộc từ luồng bit và/hoặc vùng chứa.
- [C-3-2] Việc triển khai thiết bị PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).
5.3.6. VP8
If device implementations support VP8 codec, they:
- [C-1-1] MUST support the SD decoding profiles in the following table.
- SHOULD use a hardware VP8 codec that meets the requirements.
- SHOULD support the HD decoding profiles in the following table.
Nếu chiều cao do phương thức Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn độ phân giải video, thì:
- [C-2-1] Device implementations MUST support 720p profiles in the following table.
- [C-2-2] Device implementations MUST support 1080p profiles in the following table.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | |
---|---|---|---|---|
Độ phân giải video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps (60 fpsTelevision) | 30 (60 fpsTelevision) |
Tốc độ bit của video | 800 Kb/giây | 2 Mb/giây | 8 Mb/giây | 20 Mb/giây |
5.3.7. VP9
If device implementations support VP9 codec, they:
- [C-1-1] MUST support the SD video decoding profiles as indicated in the following table.
- SHOULD support the HD decoding profiles as indicated in the following table.
If device implementations support VP9 codec and a hardware decoder:
- [C-2-1] MUST support the HD decoding profiles as indicated in the following table.
Nếu chiều cao do phương thức Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn độ phân giải video, thì:
- [C-3-1] Device implementations MUST support at least one of VP9 or H.265 decoding of the 720, 1080 and UHD profiles.
SD (Low quality) | SD (Chất lượng cao) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Độ phân giải video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30 fps (60 fpsTelevision with VP9 hardware decoding) | 60 khung hình/giây |
Tốc độ bit của video | 600 Kb/giây | 1,6 Mb/giây | 4 Mb/giây | 5 Mb/giây | 20 Mb/giây |
Nếu các phương thức triển khai thiết bị tuyên bố hỗ trợ VP9Profile2
hoặc VP9Profile3
thông qua API nội dung nghe nhìn "CodecProfileLevel":
- Không bắt buộc phải hỗ trợ định dạng 12 bit.
Nếu việc triển khai thiết bị tuyên bố hỗ trợ Hồ sơ HDR (VP9Profile2HDR
, VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) thông qua API đa phương tiện:
- [C-4-1] Việc triển khai thiết bị PHẢI chấp nhận siêu dữ liệu HDR bắt buộc (
KEY_HDR_STATIC_INFO
cho tất cả hồ sơ HDR, cũng như 'KEY_HDR10_PLUS_INFO' cho hồ sơ HDR10Plus) từ ứng dụng. Các bộ mã hoá và giải mã này cũng PHẢI hỗ trợ việc trích xuất và xuất siêu dữ liệu HDR bắt buộc từ luồng bit và/hoặc vùng chứa. - [C-4-2] Việc triển khai thiết bị PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video chuẩn (ví dụ: HDMI).
5.3.8. Dolby Vision
If device implementations declare support for the Dolby Vision decoder through
HDR_TYPE_DOLBY_VISION
, they:
- [C-1-1] MUST provide a Dolby Vision-capable extractor.
- [C-1-2] MUST properly display Dolby Vision content on the device screen or on a standard video output port (e.g., HDMI).
- [C-1-3] PHẢI đặt mã bản nhạc của(các) lớp cơ sở tương thích ngược (nếu có) giống với mã bản nhạc của lớp Dolby Vision kết hợp.
5.3.9. AV1
- [C-1-1] PHẢI hỗ trợ Hồ sơ 0, bao gồm cả nội dung 10 bit.
Bắt đầu yêu cầu mới
If device implementations support AV1 codec and make it available to third-party applications, they:- [C-1-1] MUST support Main Profile including 8-bit and 10-bit content.
Nếu các phương thức triển khai thiết bị hỗ trợ bộ mã hoá và giải mã AV1 bằng bộ giải mã tăng tốc phần cứng, thì các phương thức đó:
- [C-2-1] PHẢI có thể giải mã ít nhất là các hồ sơ giải mã video HD 720p trong bảng bên dưới khi chiều cao do phương thức
Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn 720p. - [C-2-2] PHẢI có thể giải mã ít nhất là các hồ sơ giải mã video HD 1080p trong bảng bên dưới khi chiều cao do phương thức
Display.getSupportedModes()
báo cáo bằng hoặc lớn hơn 1080p.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Độ phân giải video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 px |
Tốc độ khung hình video | 30 fps | 30 fps | 30 fps | 30 fps |
Tốc độ bit của video | 5 Mb/giây | 8 Mb/giây | 16 Mb/giây | 50 Mb/giây |
Nếu các phương thức triển khai thiết bị hỗ trợ Hồ sơ HDR thông qua Media API, thì các phương thức đó:
- [C-3-1] PHẢI hỗ trợ trích xuất và xuất siêu dữ liệu HDR từ luồng bit và/hoặc vùng chứa.
- [C-3-2] PHẢI hiển thị đúng nội dung HDR trên màn hình thiết bị hoặc trên cổng đầu ra video tiêu chuẩn (ví dụ: HDMI).
Kết thúc các yêu cầu mới
5.4. Ghi âm
Mặc dù một số yêu cầu được nêu trong phần này được liệt kê là NÊN kể từ Android 4.3, nhưng Định nghĩa về khả năng tương thích cho các phiên bản trong tương lai dự kiến sẽ thay đổi các yêu cầu này thành PHẢI. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này được liệt kê là NÊN, nếu không, các thiết bị này sẽ không thể đạt được khả năng tương thích với Android khi được nâng cấp lên phiên bản trong tương lai.
5.4.1. Tính năng Quay âm thanh thô và thông tin về micrô
If device implementations declare android.hardware.microphone
, they:
[C-1-1] PHẢI cho phép ghi lại nội dung âm thanh thô cho mọi luồng INPUT
AudioRecord
hoặcAAudio
được mở thành công. Ở mức tối thiểu, bạn PHẢI hỗ trợ các đặc điểm sau:- Định dạng: PCM tuyến tính, 16 bit
- Tốc độ lấy mẫu: 8000, 11025, 16000, 44100, 48000 Hz
- Channels (Kênh): Mono
- Nguồn âm thanh:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, hoặcVOICE_PERFORMANCE
. Điều này cũng áp dụng cho các giá trị đặt trước đầu vào tương đương trongAAudio
, ví dụ:AAUDIO_INPUT_PRESET_CAMCORDER
.
SHOULD allow capture of raw audio content with the following characteristics:
- Đị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] MUST capture at above sample rates without up-sampling.
[C-1-3] MUST include an appropriate anti-aliasing filter when the sample rates given above are captured with down-sampling.
SHOULD allow AM radio and DVD quality capture of raw audio content, which means the following characteristics:
- Format: Linear PCM, 16-bit
- Tốc độ lấy mẫu: 22050, 48000 Hz
- Channels (Số kênh): Âm thanh nổi
[C-1-4] PHẢI tuân thủ API
MicrophoneInfo
và điền chính xác thông tin cho các micrô có sẵn trên thiết bị mà các ứng dụng bên thứ ba có thể truy cập thông qua APIAudioManager.getMicrophones()
, đối với AudioRecord đang hoạt động bằng cách sử dụngMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
hoặcVOICE_PERFORMANCE
. If device implementations allow AM radio and DVD quality capture of raw audio content, they:[C-2-1] MUST capture without up-sampling at any ratio higher than 16000:22050 or 44100:48000.
[C-2-2] PHẢI có bộ lọc khử răng cưa thích hợp cho mọi hoạt động lấy mẫu lên hoặc lấy mẫu xuống.
5.4.2. Capture for Voice Recognition
If device implementations declare android.hardware.microphone
, they:
- [C-1-1] MUST capture
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
audio source at one of the sampling rates, 44100 and 48000. - [C-1-2] Theo mặc định, PHẢI tắt mọi quá trình xử lý âm thanh giảm tiếng ồn khi ghi luồng âm thanh từ nguồn âm thanh
AudioSource.VOICE_RECOGNITION
. [C-1-3] MUST, by default, disable any automatic gain control when recording an audio stream from the
AudioSource.VOICE_RECOGNITION
audio source.SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
[C-SR-1] NÊN có mức độ biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 30 Hz đến 100 Hz so với dải tần số trung bình cho từng micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.
[C-SR-2] NÊN có mức độ biên độ trong dải tần số cao: cụ thể là từ ±30 dB từ 4000 Hz đến 22 KHz so với dải tần số trung bình cho từng micrô dùng để ghi âm nguồn âm thanh nhận dạng giọng nói.
NÊN đặt độ nhạy đầu vào âm thanh sao cho nguồn âm thanh dạng sóng sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 90 dB (được đo
ở khoảng cách 30 cm từbên cạnh micrô) cho ra phản hồi lý tưởng là 2500 RMS trong phạm vi từ 1770 đến 3530 đối với các mẫu 16 bit (hoặc -22,35 db ±3dB Full Scale đối với các mẫu dấu phẩy động/độ chính xác kép) cho từng micrô dùng để ghi nguồn âm thanh nhận dạng giọng nói.SHOULD record the voice recognition audio stream so that the PCM amplitude levels linearly track input SPL changes over at least a 30 dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.
SHOULD record the voice recognition audio stream with total harmonic distortion (THD) less than 1% for 1 kHz at 90 dB SPL input level at the microphone.
If device implementations declare android.hardware.microphone
and noise
suppression (reduction) technologies tuned for speech recognition, they:
- [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ệ giảm tiếng ồn thông qua trường
AudioEffect.Descriptor.uuid
.
5.4.3. Capture for Rerouting of Playback
Lớp android.media.MediaRecorder.AudioSource
bao gồm nguồn âm thanh REMOTE_SUBMIX
.
If device implementations declare both android.hardware.audio.output
and
android.hardware.microphone
, they:
[C-1-1] MUST properly implement the
REMOTE_SUBMIX
audio source so that when an application uses theandroid.media.AudioRecord
API to record from this audio source, it captures a mix of all audio streams except for the following:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Trình khử tiếng vọng âm thanh
If device implementations declare android.hardware.microphone
, they:
- NÊN triển khai công nghệ Loại bỏ tiếng vọng âm thanh (AEC) được điều chỉnh để giao tiếp bằng giọng nói và áp dụng cho đường dẫn ghi khi ghi bằng
AudioSource.VOICE_COMMUNICATION
.
Nếu các phương thức triển khai thiết bị cung cấp một Trình huỷ tiếng vọng âm thanh được chèn vào đường dẫn âm thanh ghi lại khi chọn AudioSource.VOICE_COMMUNICATION
, thì các phương thức đó:
- [C-SR-1] STRONGLY_RECOMMENDED khai báo thông tin này thông qua phương thức API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
- [C-SR-2] STRONGLY_RECOMMENDED để cho phép điều khiển hiệu ứng âm thanh này bằng API AcousticEchoCanceler.
- [C-SR-3] STRONGLY_RECOMMENDED để 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 phương thức triển khai thiết bị khai báo android.hardware.microphone
,thì các phương thức đó PHẢI triển khai tính năng chụp đồng thời như mô tả trong tài liệu này. Cụ thể:
- [C-1-1] PHẢI cho phép truy cập đồng thời vào micrô bằng một dịch vụ hỗ trợ tiếp cận ghi lại bằng
AudioSource.VOICE_RECOGNITION
và ít nhất một ứng dụng ghi lại bằng bất kỳAudioSource
nào. - [C-1-2] PHẢI cho phép truy cập đồng thời vào micrô bằng một ứng dụng được cài đặt sẵn có vai trò Trợ lý và ít nhất một ứng dụng ghi lại bằng bất kỳ
AudioSource
nào ngoại trừAudioSource.VOICE_COMMUNICATION
hoặcAudioSource.CAMCORDER
. - [C-1-3] PHẢI tắt âm thanh ghi âm cho mọi ứng dụng khác, ngoại trừ
dịch vụ hỗ trợ tiếp cận, trong khi một ứng dụng đang ghi âm bằng
AudioSource.VOICE_COMMUNICATION
hoặcAudioSource.CAMCORDER
. Tuy nhiên, khi một ứng dụng đang ghi lại thông quaAudioSource.VOICE_COMMUNICATION
, thì một ứng dụng khác có thể ghi lại cuộc gọi thoại nếu đó là ứng dụng đặc quyền (được cài đặt sẵn) có quyềnCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Nếu hai hoặc nhiều ứng dụng đang ghi lại đồng thời và nếu không có ứng dụng nào có giao diện người dùng ở trên cùng, thì ứng dụng bắt đầu ghi lại gần đây nhất sẽ nhận được âm thanh.
5.5. Phát âm thanh
Android hỗ trợ cho phép các ứng dụng phát âm thanh thông qua thiết bị ngoại vi đầu ra âm thanh như được xác định trong mục 7.8.2.
5.5.1. Phát âm thanh thô
If device implementations declare android.hardware.audio.output
, they:
[C-1-1] MUST allow playback of raw audio content with the following characteristics:
- Định dạng nguồn: PCM tuyến tính, 16 bit, 8 bit, dấu phẩy động
- Channels: Mono, Stereo, cấu hình đa kênh hợp lệ với tối đa 8 kênh
- Sampling rates (in Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 tại các cấu hình kênh nêu trên
- 96000 in mono and stereo
5.5.2. Hiệu ứng âm thanh
Android provides an API for audio effects for device implementations.
If device implementations declare the feature android.hardware.audio.output
,
they:
- [C-1-1] MUST support the
EFFECT_TYPE_EQUALIZER
andEFFECT_TYPE_LOUDNESS_ENHANCER
implementations controllable through the AudioEffect subclassesEqualizer
andLoudnessEnhancer
. - [C-1-2] MUST support the visualizer API implementation, controllable through
the
Visualizer
class. - [C-1-3] MUST support the
EFFECT_TYPE_DYNAMICS_PROCESSING
implementation controllable through the AudioEffect subclassDynamicsProcessing
.
Bắt đầu yêu cầu mới
- [C-1-4] PHẢI hỗ trợ hiệu ứng âm thanh với đầu vào và đầu ra dấu phẩy động.
- [C-1-5] PHẢI đảm bảo rằng các hiệu ứng âm thanh hỗ trợ nhiều kênh lên đến số lượng kênh bộ trộn còn gọi là FCC_LIMIT.
Kết thúc các yêu cầu mới
- SHOULD support the
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
, andEFFECT_TYPE_VIRTUALIZER
implementations controllable through theAudioEffect
sub-classesBassBoost
,EnvironmentalReverb
,PresetReverb
, andVirtualizer
. - [C-SR-1] Bạn NÊN hỗ trợ các hiệu ứng ở dấu phẩy động và nhiều kênh.
5.5.3. Âm lượng đầu ra âm thanh
Automotive device implementations:
- SHOULD allow adjusting audio volume
separately per each audio stream using the content type or usage as defined
by AudioAttributes
and car audio usage as publicly defined in
android.car.CarAudioManager
.
5.5.4. Giảm tải âm thanh
Nếu các phương thức triển khai thiết bị hỗ trợ phát âm thanh khi giảm tải, thì các phương thức đó:
- [C-SR-1] Bạn NÊN cắt nội dung âm thanh phát không gián đoạn giữa hai đoạn với cùng một định dạng khi được API AudioTrack không gián đoạn và vùng chứa nội dung nghe nhìn cho MediaPlayer chỉ định.
5.6. Độ trễ âm thanh
Độ trễ âm thanh là độ trễ thời gian khi tín hiệu âm thanh đi qua một hệ thống. Nhiều lớp ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng âm thanh theo thời gian thực.
For the purposes of this section, use the following definitions:
- output latency. Khoảng thời gian giữa thời điểm một ứng dụng ghi một khung dữ liệu được mã hoá PCM và thời điểm âm thanh tương ứng được trình chuyển đổi trên thiết bị hiển thị cho môi trường hoặc tín hiệu rời khỏi thiết bị thông qua cổng và có thể được quan sát bên ngoài.
- cold output latency. Khoảng thời gian từ khi bắt đầu luồng đầu ra đến thời gian hiển thị khung hình đầu tiên dựa trên dấu thời gian, khi hệ thống đầu ra âm thanh ở trạng thái rảnh và tắt trước khi có yêu cầu.
- continuous output latency. Độ trễ đầu ra cho các khung hình tiếp theo, sau khi thiết bị phát âm thanh.
- input latency. Khoảng thời gian giữa thời điểm âm thanh được môi trường trình bày cho thiết bị tại một bộ chuyển đổi trên thiết bị hoặc tín hiệu đi vào thiết bị thông qua một cổng và thời điểm ứng dụng đọc khung dữ liệu được mã hoá PCM tương ứng.
- lost input. Phần đầu của tín hiệu đầu vào không dùng được hoặc không có.
- cold input latency. Khoảng thời gian giữa lúc bắt đầu truyền trực tuyến và lúc nhận được khung hình hợp lệ đầu tiên, khi hệ thống đầu vào âm thanh ở trạng thái rảnh và tắt trước khi có yêu cầu.
continuous input latency. Độ trễ đầu vào cho các khung hình tiếp theo, trong khi thiết bị đang ghi âm.
continuous round-trip latency. Tổng độ trễ đầu vào liên tục cộng với độ trễ đầu ra liên tục cộng với một khoảng thời gian đệm. The buffer period allows time for the app to process the signal and time for the app to mitigate phase difference between input and output streams.
OpenSL ES PCM buffer queue API. Tập hợp các API OpenSL ES liên quan đến PCM trong Android NDK.
API âm thanh gốc AAudio. Tập hợp các API AAudio trong Android NDK.
Dấu thời gian. Một cặp bao gồm vị trí khung hình tương đối trong một luồng và thời gian ước tính khi khung hình đó vào hoặc rời khỏi quy trình xử lý âm thanh trên điểm cuối được liên kết. Xem thêm về AudioTimestamp.
lỗi. Sự gián đoạn tạm thời hoặc giá trị mẫu không chính xác trong tín hiệu âm thanh, thường là do vùng đệm bị thiếu đối với đầu ra, vùng đệm bị tràn đối với đầu vào hoặc bất kỳ nguồn tạp âm kỹ thuật số hoặc tương tự nào khác.
độ lệch tuyệt đối trung bình. Giá trị trung bình của giá trị tuyệt đối của độ lệch so với giá trị trung bình cho một tập hợp giá trị.
Độ trễ nhấn để phát âm thanh. Khoảng thời gian từ khi màn hình được nhấn đến khi âm thanh được tạo ra do thao tác nhấn đó phát ra trên loa.
Nếu các phương thức triển khai thiết bị khai báo android.hardware.audio.output
, thì các phương thức đó
PHẢI đáp ứng hoặc vượt quá các yêu cầu sau:
- [C-1-1] Dấu thời gian đầu ra do AudioTrack.getTimestamp và
AAudioStream_getTimestamp
trả về có độ chính xác +/- 2 mili giây. [C-1-2] Độ trễ đầu ra nguội là 500 mili giây trở xuống.
[C-1-3] Việc mở luồng đầu ra bằng
AAudioStreamBuilder_openStream()
PHẢI mất ít hơn 1000 mili giây.
Nếu các phương thức triển khai thiết bị khai báo android.hardware.audio.output
, thì bạn KHÔNG NÊN không đáp ứng hoặc vượt quá các yêu cầu sau:
- [C-SR-1] Độ trễ đầu ra nguội từ 100 mili giây trở xuống qua đường dẫn dữ liệu của loa.
- [C-SR-2] Tap-to-tone latency of 80 milliseconds or less.
- [C-SR-4] The output timestamp returned by
AudioTrack.getTimestamp
and
AAudioStream_getTimestamp
is accurate to +/- 1 ms.
Bắt đầu yêu cầu mới
- [C-SR-4] Độ trễ trọn vòng được tính toán dựa trên dấu thời gian đầu vào và đầu ra do
AAudioStream_getTimestamp
trả về KHÔNG NÊN vượt quá 30 mili giây so với độ trễ trọn vòng được đo lường choAAUDIO_PERFORMANCE_MODE_NONE
vàAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
đối với loa, tai nghe có dây và không dây.
Kết thúc các yêu cầu mới
If device implementations meet the above requirements, after any initial calibration, when using the AAudio native audio API, for continuous output latency and cold output latency over at least one supported audio output device, they are:
- [C-SR-5] STRONGLY RECOMMENDED to report low-latency audio by declaring
android.hardware.audio.low_latency
feature flag. - [C-SR-6] STRONGLY RECOMMENDED to meet the requirements for low-latency audio via the AAudio API.
- [C-SR-7] STRONGLY RECOMMENDED to ensure that for streams that return
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
fromAAudioStream_getPerformanceMode()
, the value returned byAAudioStream_getFramesPerBurst()
is less than or equal to the value returned byandroid.media.AudioManager.getProperty(String)
for property keyAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Nếu các phương thức triển khai thiết bị không đáp ứng các yêu cầu về âm thanh có độ trễ thấp thông qua API âm thanh gốc AAudio, thì:
- [C-2-1] MUST NOT report support for low-latency audio.
Nếu các phương thức triển khai thiết bị bao gồm android.hardware.microphone
, thì các phương thức đó KHÔNG ĐƯỢC vi phạm các yêu cầu sau đây đối với âm thanh đầu vào:
- [C-3-1] Giới hạn lỗi trong dấu thời gian đầu vào do AudioRecord.getTimestamp hoặc
AAudioStream_getTimestamp
trả về ở mức +/- 2 mili giây. "Lỗi" ở đây có nghĩa là độ lệch so với giá trị chính xác. - [C-3-2] Độ trễ đầu vào nguội là 500 mili giây trở xuống.
- [C-3-3] Việc mở luồng đầu vào bằng
AAudioStreamBuilder_openStream()
PHẢI mất ít hơn 1000 mili giây.
Nếu triển khai thiết bị bao gồm android.hardware.microphone
, thì bạn KHÔNG NÊN không đáp ứng các yêu cầu sau đây đối với âm thanh đầu vào:
[C-SR-8] Độ trễ đầu vào nguội từ 100 mili giây trở xuống qua đường dẫn dữ liệu micrô.
[C-SR-11] Giới hạn lỗi trong dấu thời gian đầu vào do AudioRecord.getTimestamp hoặc
AAudioStream_getTimestamp
trả về ở mức +/- 1 mili giây.
If device implementations declare android.hardware.audio.output
and
android.hardware.microphone
, they:
- [C-SR-12] Bạn NÊN có Độ trễ trung bình liên tục của vòng lặp từ 50 mili giây trở xuống trong 5 lần đo lường, với Độ lệch tuyệt đối trung bình từ 10 mili giây trở xuống trên ít nhất một đường dẫn được hỗ trợ.
5.7. Giao thức mạng
Device implementations MUST support the media network protocols for audio and video playback as specified in the Android SDK documentation.
Đối với mỗi bộ mã hoá và giải mã và định dạng vùng chứa mà quá trình triển khai thiết bị bắt buộc phải hỗ trợ, quá trình triển khai thiết bị:
[C-1-1] PHẢI hỗ trợ bộ mã hoá và giải mã hoặc vùng chứa đó qua HTTP và HTTPS.
[C-1-2] MUST support the corresponding media segment formats as shown in the media segment formats table below over HTTP Live Streaming draft protocol, Version 7.
[C-1-3] MUST support the corresponding RTSP payload formats as shown in the RTSP table below. Đối với các trường hợp ngoại lệ, vui lòng xem chú thích trong bảng ở mục 5.1.
Định dạng phân đoạn nội dung nghe nhìn
Định dạng phân đoạn | Tài liệu tham khảo | Hỗ trợ bộ mã hoá và giải mã bắt buộc |
---|---|---|
Luồng truyền tải MPEG-2 | ISO 13818 |
Bộ mã hoá và giải mã video:
và MPEG-2. Bộ mã hoá và giải mã âm thanh:
|
AAC với khung ADTS và thẻ ID3 | ISO 13818-7 | See section 5.1.1 for details on AAC and its variants |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Tên hồ sơ | Tài liệu tham khảo | Hỗ trợ bộ mã hoá và giải mã bắt buộc |
---|---|---|
H264 AVC | RFC 6184 | See section 5.1.8 for details on H264 AVC |
MP4A-LATM | RFC 6416 | See section 5.1.3 for details on AAC and its variants |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
See section 5.1.8 for details on H263 |
H263-2000 | RFC 4629 | See section 5.1.8 for details on H263 |
AMR | RFC 4867 | See section 5.1.3 for details on AMR-NB |
AMR-WB | RFC 4867 | See section 5.1.3 for details on AMR-WB |
MP4V-ES | RFC 6416 | See section 5.1.8 for details on MPEG-4 SP |
mpeg4-generic | RFC 3640 | See section 5.1.3 for details on AAC and its variants |
MP2T | RFC 2250 | Xem MPEG-2 Transport Stream bên dưới phần Phát trực tuyến qua HTTP để biết thông tin chi tiết |
5.8. Secure Media
If device implementations support secure video output and are capable of supporting secure surfaces, they:
- [C-1-1] MUST declare support for
Display.FLAG_SECURE
.
If device implementations declare support for Display.FLAG_SECURE
and support
wireless display protocol, they:
- [C-2-1] PHẢI bảo mật đường liên kết bằng một cơ chế mã hoá mạnh như HDCP 2.x trở lên đối với các màn hình được kết nối thông qua các giao thức không dây như Miracast.
If device implementations declare support for Display.FLAG_SECURE
and
support wired external display, they:
- [C-3-1] MUST support HDCP 1.2 or higher for all external displays connected via a user-accessible wired port.
5.9. Giao diện kỹ thuật số cho nhạc cụ (MIDI)
If device implementations report support for feature android.software.midi
via the
android.content.pm.PackageManager
class, they:
[C-1-1] MUST support MIDI over all MIDI-capable hardware transports for which they provide generic non-MIDI connectivity, where such transports are:
- USB host mode, section 7.7
- MIDI over Bluetooth LE acting in central role, section 7.4.3
[C-1-2] MUST support the inter-app MIDI software transport (virtual MIDI devices)
[C-1-3] MUST include libamidi.so (native MIDI support)
NÊN hỗ trợ MIDI qua chế độ thiết bị ngoại vi USB, mục 7.7
5.10. Professional Audio
If device implementations report support for feature
android.hardware.audio.pro
via the
android.content.pm.PackageManager
class, they:
- [C-1-1] MUST report support for feature
android.hardware.audio.low_latency
. - [C-1-2] PHẢI có độ trễ âm thanh liên tục theo vòng, như được xác định trong phần 5.6 Độ trễ âm thanh, là 25 mili giây trở xuống trên ít nhất một đường dẫn được hỗ trợ.
- [C-1-3] MUST include a USB port(s) supporting USB host mode and USB peripheral mode.
- [C-1-4] MUST report support for feature
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ách sử dụng API âm thanh gốc AAudio và
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] PHẢI có độ trễ đầu ra nguội là 200 mili giây trở xuống.
- [C-1-7] PHẢI có độ trễ đầu vào nguội là 200 mili giây trở xuống.
[C-1-8] PHẢI có độ trễ trung bình của tính năng nhấn để phát âm thanh là 80 mili giây trở xuống trong ít nhất 5 lần đo lường trên đường dẫn dữ liệu từ loa đến micrô.
[C-SR-1] Bạn NÊN đáp ứng độ trễ như được xác định trong phần 5.6 Độ trễ âm thanh, từ 20 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây trên đường dẫn từ loa đến micrô.
[C-SR-2] Bạn NÊN đáp ứng các yêu cầu của Pro Audio về độ trễ âm thanh liên tục, độ trễ đầu vào nguội và độ trễ đầu ra nguội cũng như các yêu cầu về âm thanh USB bằng cách sử dụng API AAudio native audio (Âm thanh gốc AAudio) qua đường dẫn MMAP.
[C-SR-3] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. Bạn nên kiểm thử điều này bằng ứng dụng Android SynthMark. SynthMark sử dụng một trình tổng hợp phần mềm chạy trên khung âm thanh mô phỏng để đo lường hiệu suất hệ thống. Hãy xem tài liệu về SynthMark để biết nội dung giải thích về các điểm chuẩn. Bạn cần chạy ứng dụng SynthMark bằng tuỳ chọn "Kiểm thử tự động" và đạt được các kết quả sau:
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 mili giây
- latencymark.dynamic.little <= 50 mili giây
SHOULD minimize audio clock inaccuracy and drift relative to standard time.
SHOULD minimize audio clock drift relative to the CPU
CLOCK_MONOTONIC
when both are active.SHOULD minimize audio latency over on-device transducers.
SHOULD minimize audio latency over USB digital audio.
SHOULD document audio latency measurements over all paths.
SHOULD minimize jitter in audio buffer completion callback entry times, as this affects usable percentage of full CPU bandwidth by the callback.
SHOULD provide zero audio glitches under normal use at reported latency.
SHOULD provide zero inter-channel latency difference.
SHOULD minimize MIDI mean latency over all transports.
SHOULD minimize MIDI latency variability under load (jitter) over all transports.
SHOULD provide accurate MIDI timestamps over all transports.
SHOULD minimize audio signal noise over on-device transducers, including the period immediately after cold start.
SHOULD provide zero audio clock difference between the input and output sides of corresponding end-points, when both are active. Ví dụ về các điểm cuối tương ứng bao gồm micrô và loa trên thiết bị hoặc đầu vào và đầu ra của giắc cắm âm thanh.
SHOULD handle audio buffer completion callbacks for the input and output sides of corresponding end-points on the same thread when both are active, and enter the output callback immediately after the return from the input callback. Hoặc nếu không thể xử lý các lệnh gọi lại trên cùng một luồng, hãy nhập lệnh gọi lại đầu ra ngay sau khi nhập lệnh gọi lại đầu vào để cho phép ứng dụng có thời gian nhất quán cho các bên đầu vào và đầu ra.
SHOULD minimize the phase difference between HAL audio buffering for the input and output sides of corresponding end-points.
SHOULD minimize touch latency.
SHOULD minimize touch latency variability under load (jitter).
Nếu các phương thức triển khai thiết bị đáp ứng tất cả các yêu cầu trên, thì:
- [C-SR-4] STRONGLY RECOMMENDED to report support for feature
android.hardware.audio.pro
via theandroid.content.pm.PackageManager
class.
If device implementations include a 4 conductor 3.5mm audio jack, they:
[C-2-1] PHẢI có Độ trễ âm thanh liên tục trung bình (như được xác định trong phần 5.6 Độ trễ âm thanh) là 20 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây trên đường dẫn giắc cắm âm thanh bằng Audio Loopback Dongle.
[C-SR-5] STRONGLY RECOMMENDED to comply with section Mobile device (jack) specifications of the Wired Audio Headset Specification (v1.1).
If device implementations omit a 4 conductor 3.5mm audio jack and include a USB port(s) supporting USB host mode, they:
- [C-3-1] MUST implement the USB audio class.
- [C-3-2] PHẢI có Độ trễ âm thanh liên tục trung bình là 25 mili giây trở xuống, trên 5 lần đo lường với Độ lệch tuyệt đối trung bình dưới 5 mili giây qua cổng USB ở chế độ máy chủ bằng cách sử dụng lớp âm thanh USB. (Bạn có thể đo lường bằng cách sử dụng bộ chuyển đổi USB-3, 5 mm và USB Loopback Dongle hoặc sử dụng giao diện âm thanh USB với cáp nối kết nối đầu vào với đầu ra).
- [C-SR-6] Bạn NÊN hỗ trợ I/O đồng thời lên đến 8 kênh cho mỗi hướng, tốc độ lấy mẫu 96 kHz và độ sâu 24 bit hoặc 32 bit khi sử dụng với các thiết bị ngoại vi âm thanh USB cũng hỗ trợ các yêu cầu này.
- [C-SR-7] Bạn NÊN đáp ứng nhóm yêu cầu này bằng cách sử dụng API âm thanh gốc AAudio qua đường dẫn MMAP.
If device implementations include an HDMI port, they:
- NÊN hỗ trợ đầu ra âm thanh nổi và 8 kênh ở độ sâu 20 bit hoặc 24 bit và 192 kHz mà không làm mất độ sâu bit hoặc lấy mẫu lại, trong ít nhất một cấu hình.
5.11. Capture for Unprocessed
Android hỗ trợ tính năng ghi âm thanh chưa xử lý thông qua nguồn âm thanh android.media.MediaRecorder.AudioSource.UNPROCESSED
. Trong OpenSL ES, bạn có thể truy cập vào tệp này bằng chế độ cài đặt trước bản ghi SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
If device implementations intent to support unprocessed audio source and make it available to third-party apps, they:
[C-1-1] MUST report the support through the
android.media.AudioManager
property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] MUST exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±10 dB from 100 Hz to 7000 Hz for each and every microphone used to record the unprocessed audio source.
[C-1-3] MUST exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 z to 100 Hz compared to the mid-frequency range for each and every microphone used to record the unprocessed audio source.
[C-1-4] MUST exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 7000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the unprocessed audio source.
[C-1-5] PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn âm thanh dạng sóng sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 94 dB sẽ tạo ra phản hồi có RMS là 520 đối với các mẫu 16 bit (hoặc -36 dB Toàn thang cho các mẫu dấu phẩy động/độ chính xác gấp đôi) cho từng micrô dùng để ghi nguồn âm thanh chưa qua xử lý.
[C-1-6] MUST have a signal-to-noise ratio (SNR) at 60 dB or higher for each and every microphone used to record the unprocessed audio source. (whereas the SNR is measured as the difference between 94 dB SPL and equivalent SPL of self noise, A-weighted).
[C-1-7] MUST have a total harmonic distortion (THD) less than be less than 1% for 1 kHZ at 90 dB SPL input level at each and every microphone used to record the unprocessed audio source.
[C-1-8] MUST not have any other signal processing (e.g. Automatic Gain Control, High Pass Filter, or Echo cancellation) in the path other than a level multiplier to bring the level to desired range. Hay nói cách khác:
- [C-1-9] Nếu có bất kỳ hoạt động xử lý tín hiệu nào trong cấu trúc vì bất kỳ lý do nào, thì hoạt động đó PHẢI bị vô hiệu hoá và phải mang lại độ trễ bằng 0 hoặc độ trễ bổ sung hiệu quả cho đường dẫn tín hiệu.
- [C-1-10] The level multiplier, while allowed to be on the path, MUST NOT introduce delay or latency to the signal path.
Tất cả phép đo SPL đều được thực hiện ngay bên cạnh micrô đang được kiểm thử. Đối với nhiều cấu hình micrô, các yêu cầu này áp dụng cho từng micrô.
If device implementations declare android.hardware.microphone
but do not
support unprocessed audio source, they:
- [C-2-1] PHẢI trả về
null
cho phương thức APIAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
để cho biết rõ việc không hỗ trợ. - [C-SR-1] are still STRONGLY RECOMMENDED to satisfy as many of the requirements for the signal path for the unprocessed recording source.
5.12. HDR Video
Android 13 hỗ trợ các công nghệ HDR như mô tả trong một tài liệu sắp ra mắt.
Định dạng pixel
Nếu bộ giải mã video quảng cáo hỗ trợ COLOR_FormatYUVP010, thì:
[C-1-1] PHẢI hỗ trợ định dạng P010 để đọc CPU (ImageReader, MediaImage, ByteBuffer). Trong Android 13, P010 được nới lỏng để cho phép bước tuỳ ý cho các mặt phẳng Y và UV.
[C-1-2] GPU PHẢI có thể lấy mẫu vùng đệm đầu ra P010 (khi được phân bổ với mức sử dụng GPU_SAMPLING). Điều này cho phép các ứng dụng kết hợp GPU và ánh xạ tông màu tuỳ chỉnh.
Nếu bộ giải mã video quảng cáo hỗ trợ COLOR_Format32bitABGR2101010, thì bộ giải mã đó:
- [C-2-1] PHẢI hỗ trợ định dạng RGBA_1010102 cho nền tảng đầu ra và có thể đọc được bằng CPU (đầu ra ByteBuffer).
Nếu một bộ mã hoá video quảng cáo hỗ trợ COLOR_FormatYUVP010, thì bộ mã hoá đó:
- [C-3-1] PHẢI hỗ trợ định dạng P010 cho nền tảng đầu vào và đầu vào có thể ghi bằng CPU (ImageWriter, MediaImage, ByteBuffer).
Nếu một bộ mã hoá video quảng cáo hỗ trợ COLOR_Format32bitABGR2101010, thì bộ mã hoá đó:
- [C-4-1] PHẢI hỗ trợ định dạng RGBA_1010102 cho nền tảng đầu vào và đầu vào có thể ghi bằng CPU (ImageWriter, ByteBuffer). Lưu ý: Bộ mã hoá KHÔNG cần chuyển đổi giữa các đường cong chuyển đổi.
Yêu cầu đối với tính năng quay video HDR
Đối với tất cả bộ mã hoá video hỗ trợ hồ sơ HDR, việc triển khai thiết bị:
[C-5-1] KHÔNG ĐƯỢC giả định rằng siêu dữ liệu HDR là chính xác. Ví dụ: khung được mã hoá có thể có các pixel vượt quá mức độ chói đỉnh hoặc biểu đồ có thể không đại diện cho khung.
NÊN tổng hợp siêu dữ liệu động HDR để tạo siêu dữ liệu tĩnh HDR thích hợp cho các luồng đã mã hoá và xuất siêu dữ liệu đó vào cuối mỗi phiên mã hoá.
Nếu các phương thức triển khai thiết bị hỗ trợ tính năng chụp HDR bằng API CamcorderProfile, thì các phương thức đó:
[C-6-1] CŨNG PHẢI hỗ trợ tính năng chụp HDR thông qua API Camera2.
[C-6-2] PHẢI hỗ trợ ít nhất một bộ mã hoá video tăng tốc phần cứng cho mỗi công nghệ HDR được hỗ trợ.
[C-6-3] PHẢI hỗ trợ (tối thiểu) tính năng quay video HLG.
[C-6-4] PHẢI hỗ trợ ghi siêu dữ liệu HDR (nếu áp dụng cho công nghệ HDR) vào tệp video đã quay. Đối với AV1, HEVC và DolbyVision, điều này có nghĩa là đưa siêu dữ liệu vào luồng bit đã mã hoá.
[C-6-5] PHẢI hỗ trợ P010 và COLOR_FormatYUVP010.
[C-6-6] PHẢI hỗ trợ ánh xạ tông màu HDR sang SDR trong bộ giải mã tăng tốc phần cứng mặc định cho hồ sơ đã chụp. Nói cách khác, nếu một thiết bị có thể quay video HDR10+ HEVC, thì trình giải mã HEVC mặc định PHẢI có thể giải mã luồng đã quay ở SDR.
Yêu cầu đối với việc chỉnh sửa video HDR
Nếu các phương thức triển khai thiết bị bao gồm bộ mã hoá video hỗ trợ chỉnh sửa HDR, thì các phương thức đó:
- NÊN sử dụng độ trễ tối thiểu để tạo siêu dữ liệu HDR khi không có siêu dữ liệu, đồng thời NÊN xử lý linh hoạt các trường hợp siêu dữ liệu xuất hiện ở một số khung hình và không xuất hiện ở một số khung hình khác. Siêu dữ liệu này PHẢI chính xác (ví dụ: đại diện cho độ chói cực đại thực tế và biểu đồ của khung hình).
Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá và giải mã hỗ trợ FEATURE_HdrEditing
, thì các bộ mã hoá và giải mã đó:
[C-7-1] PHẢI hỗ trợ ít nhất một hồ sơ HDR.
[C-7-2] PHẢI hỗ trợ
FEATURE_HdrEditing
cho tất cả các hồ sơ HDR do bộ mã hoá và giải mã đó quảng cáo. Nói cách khác, bộ mã hoá và giải mã PHẢI hỗ trợ việc tạo siêu dữ liệu HDR khi không có siêu dữ liệu HDR cho tất cả các hồ sơ HDR được hỗ trợ sử dụng siêu dữ liệu HDR.[C-7-3] PHẢI hỗ trợ các định dạng đầu vào bộ mã hoá video sau đây giúp bảo toàn hoàn toàn tín hiệu được giải mã HDR:
- RGBA_1010102 (đã có trong đường cong chuyển mục tiêu) cho cả bề mặt đầu vào và ByteBuffer và PHẢI quảng cáo tính năng hỗ trợ COLOR_Format32bitABGR2101010.
Nếu quá trình triển khai thiết bị bao gồm các bộ mã hoá và giải mã hỗ trợ FEATURE_HdrEditing, thì thiết bị:
- [C-7-4] PHẢI quảng cáo tính năng hỗ trợ tiện ích OpenGL EXT_YUV_target.
6. Khả năng tương thích của các công cụ và tuỳ chọn dành cho nhà phát triển
6.1. Công cụ dành cho nhà phát triển
Device implementations:
- [C-0-1] MUST support the Android Developer Tools provided in the Android SDK.
-
- [C-0-2] PHẢI hỗ trợ adb như được ghi nhận trong SDK Android và các lệnh shell được cung cấp trong AOSP. Các lệnh này có thể được nhà phát triển ứng dụng sử dụng, bao gồm cả
dumpsys
vàcmd stats
- [C-0-11] PHẢI hỗ trợ lệnh shell
cmd testharness
. Việc nâng cấp các phương thức triển khai thiết bị từ một phiên bản Android cũ hơn mà không có khối dữ liệu ổn định CÓ THỂ được miễn C-0-11. - [C-0-3] KHÔNG ĐƯỢC thay đổi định dạng hoặc nội dung của các sự kiện hệ thống thiết bị (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) được ghi lại thông qua lệnh dumpsys.
- [C-0-10] PHẢI ghi lại, không được bỏ qua và cho phép truy cập vào các sự kiện sau đây cho lệnh shell
cmd stats
và lớp API hệ thốngStatsManager
.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] PHẢI có trình nền adb phía thiết bị không hoạt động theo mặc định và PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
- [C-0-5] PHẢI hỗ trợ adb bảo mật. Android hỗ trợ adb bảo mật. Secure adb enables adb on known authenticated hosts.
- [C-0-6] MUST provide a mechanism allowing adb to be connected from a host machine. Cụ thể:
If device implementations without a USB port support peripheral mode, they:
- [C-3-1] MUST implement adb via local-area network (such as Ethernet or Wi-Fi).
- [C-3-2] MUST provide drivers for Windows 7, 8 and 10, allowing developers to connect to the device using the adb protocol.
Nếu các phương thức triển khai thiết bị hỗ trợ kết nối adb với máy chủ lưu trữ qua Wi-Fi hoặc Ethernet, thì các phương thức đó:
- [C-4-1] PHẢI có phương thức
AdbManager#isAdbWifiSupported()
trả vềtrue
.
Nếu các phương thức triển khai thiết bị hỗ trợ kết nối adb với máy chủ qua Wi-Fi hoặc Ethernet và bao gồm ít nhất một máy ảnh, thì các phương thức đó:
- [C-5-1] PHẢI có phương thức
AdbManager#isAdbWifiQrSupported()
trả vềtrue
.
- [C-0-2] PHẢI hỗ trợ adb như được ghi nhận trong SDK Android và các lệnh shell được cung cấp trong AOSP. Các lệnh này có thể được nhà phát triển ứng dụng sử dụng, bao gồm cả
Dalvik Debug Monitor Service (ddms)
- [C-0-7] MUST support all ddms features as documented in the Android SDK. Vì ddms sử dụng adb, nên tính năng hỗ trợ ddms theo mặc định KHÔNG được kích hoạt, nhưng KHÔNG đượ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.
-
- [C-0-9] MUST support the systrace tool as documented in the Android SDK. Systrace phải ở trạng thái 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 Systrace.
-
- [C-SR-1] Bạn NÊN hiển thị tệp nhị phân
/system/bin/perfetto
cho người dùng shell, trong đó cmdline tuân thủ tài liệu về perfetto. - [C-SR-2] Bạn NÊN chấp nhận tệp nhị phân perfetto làm dữ liệu đầu vào cho cấu hình protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-3] Bạn NÊN ghi tệp nhị phân perfetto dưới dạng đầu ra một dấu vết protobuf tuân thủ giản đồ được xác định trong tài liệu về perfetto.
- [C-SR-4] Bạn NÊN cung cấp, thông qua tệp nhị phân perfetto, ít nhất là các nguồn dữ liệu được mô tả trong tài liệu về perfetto.
- [C-SR-1] Bạn NÊN hiển thị tệp nhị phân
Trình tắt ứng dụng khi bộ nhớ thấp
- [C-0-12] PHẢI ghi một Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
vào nhật ký statsd khi một ứng dụng bị Trình loại bỏ bộ nhớ thấp chấm dứt.
- [C-0-12] PHẢI ghi một Atom
Test Harness ModeNếu các phương thức triển khai thiết bị hỗ trợ lệnh shell
cmd testharness
và chạycmd testharness enable
, thì các phương thức đó:- [C-2-1] PHẢI trả về
true
choActivityManager.isRunningInUserTestHarness()
- [C-2-2] PHẢI triển khai Chế độ khai thác kiểm thử như mô tả trong tài liệu về Chế độ khai thác kiểm thử.
- [C-2-1] PHẢI trả về
Thông tin công việc của GPU
Device implementations:
- [C-0-13] PHẢI triển khai lệnh shell
dumpsys gpu --gpuwork
để hiển thị dữ liệu công việc GPU tổng hợp do điểm theo dõi hạt nhânpower/gpu_work_period
trả về hoặc không hiển thị dữ liệu nếu điểm theo dõi không được hỗ trợ. Cách triển khai AOSP làframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] PHẢI triển khai lệnh shell
Nếu các phương thức 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ác cờ tính năng android.hardware.vulkan.version
, thì các phương thức đó:
- [C-1-1] MUST provide an affordance for the app developer to enable/disable GPU debug layers.
- [C-1-2] PHẢI 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 thuộc nền tảng hoặc gói ứng dụng) trong thư mục cơ sở của các ứng dụng có thể gỡ lỗi khi bật các lớp gỡ lỗi GPU để hỗ trợ các phương thức API vkEnumerateInstanceLayerProperties() và vkCreateInstance().
6.2. Tuỳ chọn cho nhà phát triển
Android hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng.
Device implementations MUST provide a consistent experience for Developer Options, they:
- [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, cách triển khai Android thượng nguồn sẽ ẩn trình đơn Tuỳ chọn cho nhà phát triển và cho phép người dùng chạy Tuỳ chọn cho nhà phát triển sau khi nhấn 7 lần vào mục Cài đặt > Giới thiệu về thiết bị > Số bản dựng.
- [C-0-2] MUST hide Developer Options by default.
- [C-0-3] PHẢI cung cấp một cơ chế rõ ràng không ưu tiên một ứng dụng bên thứ ba so với ứng dụng khác để bật Tuỳ chọn cho nhà phát triển. MUST provide a public visible document or website that describes how to enable Developer Options. Tài liệu hoặc trang web này PHẢI có thể liên kết với tài liệu SDK Android.
- SHOULD have an ongoing visual notification to the user when Developer Options is enabled and the safety of the user is of concern.
- MAY temporarily limit access to the Developer Options menu, by visually hiding or disabling the menu, to prevent distraction for scenarios where the safety of the user is of concern.
7. Khả năng tương thích với phần cứng
If a device includes a particular hardware component that has a corresponding API for third-party developers:
- [C-0-1] Việc triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu SDK Android.
If an API in the SDK interacts with a hardware component that is stated to be optional and the device implementation does not possess that component:
- [C-0-2] Vẫn PHẢI trình bày định nghĩa lớp đầy đủ (như được ghi lại trong SDK) cho các API thành phần.
- [C-0-3] The API's behaviors MUST be implemented as no-ops in some reasonable fashion.
- [C-0-4] API methods MUST return null values where permitted by the SDK documentation.
- [C-0-5] Phương thức API PHẢI trả về các phương thức triển khai không hoạt động của các lớp mà tài liệu SDK không cho phép giá trị rỗng.
- [C-0-6] API methods MUST NOT throw exceptions not documented by the SDK documentation.
- [C-0-7] Device implementations MUST consistently report accurate hardware
configuration information via the
getSystemAvailableFeatures()
andhasSystemFeature(String)
methods on the android.content.pm.PackageManager class for the same build fingerprint.
A typical example of a scenario where these requirements apply is the telephony API: Even on non-phone devices, these APIs must be implemented as reasonable no-ops.
7.1. Màn hình và đồ hoạ
Android bao gồm các cơ sở để tự động điều chỉnh tài sản ứng dụng và bố cục giao diện người dùng cho phù hợp với thiết bị nhằm đảm bảo rằng các ứng dụng bên thứ ba chạy tốt trên nhiều cấu hình phần cứng.
nhiều màn hình và cấu hình phần cứng. Màn hình tương thích với Android là màn hình hiển thị triển khai tất cả các hành vi và API được mô tả trong phần Nhà phát triển Android – Tổng quan về khả năng tương thích của màn hình, phần này (7.1) và các tiểu mục của phần này, cũng như mọi hành vi cụ thể theo loại thiết bị khác được ghi nhận trong phần 2 của CDD này.
Trên(các) màn hình tương thích với Android mà tất cả ứng dụng tương thích với Android của bên thứ ba có thể chạy, việc triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.
Bắt đầu yêu cầu mới
Device implementations:
- [C-0-1] Theo mặc định, CHỈ được hiển thị các ứng dụng bên thứ ba trên màn hình tương thích với Android.
Kết thúc các yêu cầu mới
Các đơn vị được tham chiếu theo yêu cầu trong phần này được xác định như sau:
- physical diagonal size. Khoảng cách tính bằng inch giữa hai góc đối diện của phần được chiếu sáng trên màn hình.
số điểm trên mỗi inch (dpi)mật độ. Số pixel trong một khoảng cách 1 inch theo chiều dọc hoặc chiều ngang tuyến tính, được biểu thị bằng pixel trên mỗi inch (ppi hoặc dpi). Khi liệt kê các giá trịdpippi và dpi, cả dpi theo chiều ngang và chiều dọc phải nằm trong phạm vi đã liệt kê.- tỷ lệ khung hình. Tỷ lệ pixel của kích thước dài hơn so với kích thước ngắn hơn của màn hình. Ví dụ: màn hình 480x854 pixel sẽ là 854/480 = 1, 779, hay gần bằng "16:9".
- pixel không phụ thuộc vào mật độ (dp).
Đơn vị pixel ảo được chuẩn hoá thànhĐối với một số mật độ d và số pixel p, số pixel không phụ thuộc vào mật độ dp được tính theo công thức:mật độ màn hình 160 dpi.pixels = dps * (density/160)dp = (160 / d) * p .
7.1.1. Cấu hình màn hình
7.1.1.1. Kích thước và hình dạng màn hình
Khung giao diện người dùng Android hỗ trợ nhiều kích thước bố cục màn hình logic và cho phép các ứng dụng truy vấn kích thước bố cục màn hình của cấu hình hiện tại thông qua Configuration.screenLayout
với SCREENLAYOUT_SIZE_MASK
và Configuration.smallestScreenWidthDp
.
Device implementations:
[C-0-1] MUST report the correct layout size for the
Configuration.screenLayout
as defined in the Android SDK documentation. Cụ thể, các phương thức triển khai thiết bị PHẢI báo cáo kích thước màn hình pixel (dp) không phụ thuộc vào mật độ logic chính xác như bên dưới:- Các thiết bị có
Configuration.uiMode
được đặt thành bất kỳ giá trị nào khác ngoài UI_MODE_TYPE_WATCH và báo cáo kích thướcsmall
choConfiguration.screenLayout
, PHẢI có kích thước tối thiểu là 426 dp x 320 dp. - Devices reporting a
normal
size for theConfiguration.screenLayout
, MUST have at least 480 dp x 320 dp. - Devices reporting a
large
size for theConfiguration.screenLayout
, MUST have at least 640 dp x 480 dp. - Devices reporting a
xlarge
size for theConfiguration.screenLayout
, MUST have at least 960 dp x 720 dp.
- Các thiết bị có
[C-0-2] PHẢI tuân thủ đúng thông tin hỗ trợ kích thước màn hình mà ứng dụng đã nêu thông qua thuộc tính <
supports-screens
> trong AndroidManifest.xml, như mô tả trong tài liệu SDK Android.CÓ THỂ có(các) màn hình tương thích với Android có góc bo tròn.
Nếu các phương thức triển khai thiết bị hỗ trợ màn hình có thể sử dụng
cấu hình kích thước UI_MODE_TYPE_NORMAL
và bao gồm màn hình tương thích với Android
sử dụng màn hình thực có góc bo tròn để hiển thị các màn hình này,
thì:
[C-1-1] PHẢI đảm bảo rằng ít nhất một trong các yêu cầu sau đây được đáp ứng cho mỗi màn hình như vậy:
- Bán kính của các góc bo tròn nhỏ hơn hoặc bằng 38 dp.
- Khi
hộp 1518 dp theo1518 dp được neo ở mỗi góc của màn hình logic, ít nhất một pixel của mỗi hộp sẽ hiển thị trên màn hình.
SHOULD include user affordance to switch to the display mode with the rectangular corners.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị chỉ có thể định cấu hình bàn phím NO_KEYS
và dự định báo cáo khả năng hỗ trợ cấu hình chế độ giao diện người dùng UI_MODE_TYPE_NORMAL
, thì các phương thức đó:
- [C-4-1] PHẢI có kích thước bố cục, không bao gồm bất kỳ phần cắt màn hình nào, ít nhất là 596 dp x 384 dp trở lên.
Kết thúc các yêu cầu mới
Nếu quá trình triển khai thiết bị bao gồm(các) màn hình tương thích với Android có thể gập lại hoặc có bản lề gập giữa nhiều bảng hiển thị và cung cấp(các) màn hình đó để hiển thị ứng dụng của bên thứ ba, thì:
- [C-2-1] PHẢI triển khai phiên bản ổn định mới nhất hiện có của API tiện ích hoặc phiên bản ổn định của API phụ xe để thư viện Window Manager Jetpack sử dụng.
Nếu quá trình triển khai thiết bị bao gồm(các) màn hình tương thích với Android có thể gập lại hoặc bao gồm bản lề gập giữa nhiều bảng hiển thị và nếu bản lề hoặc đường gập cắt ngang cửa sổ ứng dụng toàn màn hình, thì:
- [C-3-1] PHẢI báo cáo vị trí, giới hạn và trạng thái của bản lề hoặc màn hình gập thông qua các tiện ích hoặc API phụ cho ứng dụng.
Để biết thông tin chi tiết về cách triển khai chính xác API phụ hoặc API tiện ích, hãy tham khảo tài liệu công khai về Trình quản lý cửa sổ Jetpack.
Bắt đầu yêu cầu mới
Nếu việc triển khai thiết bị bao gồm một hoặc nhiều khu vực hiển thị tương thích với Android có thể gập lại hoặc bao gồm bản lề gập giữa nhiều khu vực bảng điều khiển hiển thị tương thích với Android và cung cấp các khu vực hiển thị đó cho các ứng dụng, thì:
- [C-4-1] PHẢI triển khai phiên bản chính xác của cấp độ API Tiện ích Trình quản lý cửa sổ như mô tả trong Tiện ích Trình quản lý cửa sổ.
Kết thúc các yêu cầu mới
7.1.1.2. Tỷ lệ khung hình màn hình
Mặc dù không có quy định hạn chế về tỷ lệ khung hình của màn hình thực cho (các) màn hình tương thích với Android, nhưng tỷ lệ khung hình của màn hình logic nơi các ứng dụng bên thứ ba được kết xuất (có thể lấy từ các giá trị chiều cao và chiều rộng được báo cáo thông qua API view.Display
và API Cấu hình) PHẢI đáp ứng các yêu cầu sau:
[C-0-1] Device implementations with
Configuration.uiMode
set toUI_MODE_TYPE_NORMAL
MUST have an aspect ratio value less than or equal to 1.86 (roughly 16:9), unless the app meets one of the following conditions:- The app has declared that it supports a larger screen aspect ratio
through the
android.max_aspect
metadata value. - Ứng dụng khai báo rằng có thể đổi kích thước thông qua thuộc tính android:resizeableActivity.
- Ứng dụng nhắm đến API cấp 24 trở lên và không khai báo
android:maxAspectRatio
sẽ hạn chế tỷ lệ khung hình được phép.
- The app has declared that it supports a larger screen aspect ratio
through the
[C-0-3] Device implementations with the
Configuration.uiMode
set asUI_MODE_TYPE_WATCH
MUST have an aspect ratio value set as 1.0 (1:1).
7.1.1.3. Mật độ màn hình
Khung giao diện người dùng Android xác định một tập hợp mật độ logic tiêu chuẩn để giúp nhà phát triển ứng dụng nhắm đến tài nguyên ứng dụng.
Triển khai trên thiết bị:
- [C-0-1]
Theo mặc định, các phương thức triển khai thiết bịPHẢI báo cáochỉmột trong các mật độ khung Android được liệt kê trênDisplayMetrics
thông quaDENSITY_DEVICE_STABLE
API và giá trị này phải là giá trị tĩnh cho mỗi màn hình thực.KHÔNG ĐƯỢC thay đổi bất cứ lúc nào; tuy nhiên,Tuy nhiên thiết bị CÓ THỂ báo cáo mộtmật độ tuỳ ýDisplayMetrics.density
khác theo các thay đổi về cấu hình hiển thị do người dùng thực hiện (ví dụ: kích thước màn hình) được đặt sau khi khởi động ban đầu.
- Device implementations SHOULD define the standard Android framework density that is numerically closest to the physical density of the screen, unless that logical density pushes the reported screen size below the minimum supported. Nếu mật độ khung Android tiêu chuẩn gần với mật độ thực tế nhất về mặt số học 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ì việc triển khai thiết bị PHẢI báo cáo mật độ khung Android tiêu chuẩn thấp nhất tiếp theo.
Bắt đầu yêu cầu mới
- NÊN xác định mật độ khung Android tiêu chuẩn gần nhất về mặt số học với mật độ vật lý của màn hình hoặc một giá trị sẽ liên kết với cùng một phép đo trường nhìn góc tương đương của thiết bị cầm tay.
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị cung cấp
có khả năng thay đổi kích thước màn hình của thiết bị , thì:
- [C-1-1]
Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh theo tỷ lệKHÔNG ĐƯỢC điều chỉnh theo tỷ lệ màn hình lớn hơn 1,5 lầnDENSITY_DEVICE_STABLE
mật độ gốchoặc tạo kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320 dp (tương đương với bộ hạn định tài nguyên sw320dp), tuỳ theo điều kiện nào đến trước. - [C-1-2]
Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh theo tỷ lệKHÔNG ĐƯỢC điều chỉnh theo tỷ lệ màn hình nhỏ hơn 0,85 lầnDENSITY_DEVICE_STABLE
mật độ gốc. - Để đảm bảo khả năng hữu dụng và kích thước phông chữ nhất quán, bạn NÊN cung cấp các tuỳ chọn hiển thị gốc theo tỷ lệ sau (trong khi 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,3 lần
- Lớn nhất 1,45x
7.1.2. Chỉ số về Mạng Hiển thị
Nếu các phương thức triển khai thiết bị bao gồm(các) màn hình tương thích với Android hoặc đầu ra video đến(các) màn hình tương thích với Android, thì các phương thức đó:
- [C-1-1] MUST report correct values for all Android-compatible display
metrics defined in the
android.util.DisplayMetrics
API.
If device implementations does not include an embedded screen or video output, they:
- [C-2-1] MUST report correct values of the Android-compatible display
as defined in the
android.util.DisplayMetrics
API for the emulated defaultview.Display
.
7.1.3. Hướng màn hình
Device implementations:
- [C-0-1] MUST report which screen orientations they support
(
android.hardware.screen.portrait
and/orandroid.hardware.screen.landscape
) and MUST report at least one supported orientation. 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áoandroid.hardware.screen.landscape
. - [C-0-2] MUST report the correct value for the orientation
hiện tại của thiết bị, bất cứ khi nào được truy vấn thông qua
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
hoặc các API khác.
If device implementations support both screen orientations, they:
- [C-1-1] PHẢI hỗ trợ hướng động của các ứng dụng theo hướng màn hình dọc hoặc ngang. Tức là thiết bị phải tuân theo yêu cầu của ứng dụng về hướng màn hình cụ thể.
- [C-1-2] KHÔNG ĐƯỢC thay đổi kích thước hoặc mật độ màn hình được báo cáo khi thay đổi hướng.
- MAY select either portrait or landscape orientation as the default.
7.1.4. Tăng tốc đồ hoạ 2D và 3D
7.1.4.1 OpenGL ES
Device implementations:
- [C-0-1] MUST correctly identify the supported OpenGL ES versions (1.1, 2.0,
3.0, 3.1, 3.2) through the managed APIs (such as via the
GLES10.getString()
method) and the native APIs. - [C-0-2] MUST include the support for all the corresponding managed APIs and native APIs for every OpenGL ES versions they identified to support.
If device implementations include a screen or video output, they:
- [C-1-1] PHẢI hỗ trợ cả OpenGL ES 1.1 và 2.0, như được nêu và nêu chi tiết trong tài liệu SDK Android.
- [C-SR-1] Are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
- SHOULD support OpenGL ES 3.2.
Các thử nghiệm dEQP OpenGL ES được phân chia thành một số danh sách thử nghiệm, mỗi danh sách có một số phiên bản/ngày liên kết. Các tệp này nằm trong cây nguồn Android tại external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
. Thiết bị hỗ trợ OpenGL ES ở cấp độ tự báo cáo cho biết rằng thiết bị đó có thể vượt qua các bài kiểm thử dEQP trong tất cả danh sách kiểm thử từ cấp độ này trở xuống.
If device implementations support any of the OpenGL ES versions, they:
- [C-2-1] PHẢI báo cáo qua API được quản lý và API gốc của OpenGL ES về mọi phần mở rộng OpenGL ES khác mà họ đã triển khai, và ngược lại, PHẢI KHÔNG báo cáo các chuỗi mở rộng mà họ không hỗ trợ.
- [C-2-2] PHẢI hỗ trợ các tiện ích
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
vàEGL_ANDROID_GLES_layers
. - [C-2-3] PHẢI báo cáo phiên bản tối đa của các thử nghiệm dEQP OpenGL ES được hỗ trợ thông qua cờ tính năng
android.software.opengles.deqp.level
. - [C-2-4] PHẢI hỗ trợ ít nhất phiên bản 132383489 (kể từ ngày 1 tháng 3 năm 2020) như đã báo cáo trong cờ tính năng
android.software.opengles.deqp.level
. - [C-2-5] PHẢI vượt qua tất cả các bài kiểm thử dEQP OpenGL ES trong danh sách kiểm thử giữa phiên bản 132383489 và phiên bản được chỉ định trong cờ tính năng
android.software.opengles.deqp.level
, cho mỗi phiên bản OpenGL ES được hỗ trợ. - [C-SR-2] Are STRONGLY RECOMMENDED to support the
EGL_KHR_partial_update
andOES_EGL_image_external
extensions. SHOULD accurately report via the
getString()
method, any texture compression format that they support, which is typically vendor-specific.NÊN hỗ trợ các tiện ích
EGL_IMG_context_priority
vàEGL_EXT_protected_content
.
If device implementations declare support for OpenGL ES 3.0, 3.1, or 3.2, they:
- [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.
- [C-SR-3] Are STRONGLY RECOMMENDED to support the
OES_EGL_image_external_essl3
extension.
If device implementations support OpenGL ES 3.2, they:
- [C-4-1] MUST support the OpenGL ES Android Extension Pack in its entirety.
If device implementations support the OpenGL ES Android Extension Pack in its entirety, they:
- [C-5-1] MUST identify the support through the
android.hardware.opengles.aep
feature flag.
If device implementations expose support for the EGL_KHR_mutable_render_buffer
extension, they:
- [C-6-1] MUST also support the
EGL_ANDROID_front_buffer_auto_refresh
extension.
7.1.4.2 Vulkan
Android hỗ trợ Vulkan, một API nhiều nền tảng, mức hao tổn thấp dành cho đồ hoạ 3D hiệu suất cao.
If device implementations support OpenGL ES 3.1, they:
- [C-SR-1] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3.
- [C-4-1] KHÔNG ĐƯỢC hỗ trợ phiên bản biến thể Vulkan (tức là phần biến thể của phiên bản lõi Vulkan PHẢI bằng 0).
If device implementations include a screen or video output, they:
- [C-SR-2] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3.
Các kiểm thử dEQP Vulkan được phân chia thành một số danh sách kiểm thử, mỗi danh sách có một ngày/phiên bản liên kết. Các tệp này nằm trong cây nguồn Android tại external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
. Một thiết bị hỗ trợ Vulkan ở cấp tự báo cho biết rằng thiết bị đó có thể vượt qua các bài kiểm thử dEQP trong tất cả danh sách kiểm thử từ cấp này trở xuống.
Nếu các phương thức triển khai thiết bị hỗ trợ Vulkan 1.0 trở lên, thì các phương thức đó:
- [C-1-1] MUST report the correct integer value with the
android.hardware.vulkan.level
andandroid.hardware.vulkan.version
feature flags. - [C-1-2] PHẢI liệt kê ít nhất một
VkPhysicalDevice
cho API gốc VulkanvkEnumeratePhysicalDevices()
. - [C-1-3] PHẢI triển khai đầy đủ các API
Vulkan 1.0Vulkan 1.1 cho mỗiVkPhysicalDevice
được liệt kê. - [C-1-4] PHẢI liệt kê các lớp, chứa trong thư viện gốc có tên là
libVkLayer*.so
trong thư mục thư viện gốc của gói ứng dụng, thông qua API gốc VulkanvkEnumerateInstanceLayerProperties()
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 có thuộc tính
android:debuggable
được đặt thànhtrue
hoặc siêu dữ liệucom.android.graphics.injectLayers.enable
được đặt thànhtrue
. - [C-1-6] MUST report all extension strings that they do support via the Vulkan native APIs , and conversely MUST NOT report extension strings that they do not correctly support.
- [C-1-7] PHẢI hỗ trợ các tiện ích VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain và VK_KHR_incremental_present.
- [C-1-8] PHẢI báo cáo phiên bản tối đa của Vulkan dEQP Tests được hỗ trợ thông qua cờ tính năng
android.software.vulkan.deqp.level
. - [C-1-9] PHẢI hỗ trợ ít nhất phiên bản
132317953
(kể từ ngày 1 tháng 3 năm 2019) như đã báo cáo trong cờ tính năngandroid.software.vulkan.deqp.level
. - [C-1-10] PHẢI vượt qua tất cả các bài kiểm thử dEQP Vulkan trong danh sách kiểm thử giữa phiên bản
132317953
và phiên bản được chỉ định trong cờ tính năngandroid.software.vulkan.deqp.level
. - [C-1-11] KHÔNG ĐƯỢC liệt kê tính năng hỗ trợ cho các tiện ích VK_KHR_video_queue, VK_KHR_video_decode_queue hoặc VK_KHR_video_encode_queue.
- [C-SR-3] Are STRONGLY RECOMMENDED to support the
VK_KHR_driver_properties
andVK_GOOGLE_display_timing
extensions.
- NÊN hỗ trợ
VkPhysicalDeviceProtectedMemoryFeatures
vàVK_EXT_global_priority
.
- [C-1-12] KHÔNG ĐƯỢC liệt kê tính năng hỗ trợ cho tiện ích VK_KHR_performance_query.
- [C-1-13] PHẢI đáp ứng các yêu cầu do hồ sơ Android Baseline 2021 chỉ định.
- [C-SR-4] Bạn NÊN đáp ứng các yêu cầu do Hồ sơ cơ sở Android 2022 chỉ định.
Bắt đầu yêu cầu mới
[C-SR-5] Are STRONGLY RECOMMENDED to support
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
andVK_EXT_global_priority
.[C-SR-6] Bạn NÊN sử dụng
SkiaVk
với HWUI.
Kết thúc các yêu cầu mới
If device implementations do not include support for Vulkan 1.0, they:
- [C-2-1] KHÔNG ĐƯỢC khai báo bất kỳ cờ tính năng nào của Vulkan (ví dụ:
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] KHÔNG ĐƯỢC liệt kê bất kỳ
VkPhysicalDevice
nào cho API gốc VulkanvkEnumeratePhysicalDevices()
.
Nếu các phương thức triển khai thiết bị hỗ trợ Vulkan 1.1 và khai báo bất kỳ cờ tính năng Vulkan nào được mô tả tại đây , thì các phương thức đó:
- [C-3-1] PHẢI hiển thị tính năng hỗ trợ cho loại semaphore và handle bên ngoài
SYNC_FD
cũng như tiện íchVK_ANDROID_external_memory_android_hardware_buffer
.
Bắt đầu yêu cầu mới
- [C-SR-7] Bạn NÊN cung cấp tiện ích
VK_KHR_external_fence_fd
cho các ứng dụng bên thứ ba và cho phép ứng dụng xuất tải trọng hàng rào sang và nhập tải trọng hàng rào từ các chỉ số mô tả tệp POSIX như mô tả tại đây.
Kết thúc các yêu cầu mới
7.1.4.3 RenderScript
- [C-0-1] Device implementations MUST support Android RenderScript, as detailed in the Android SDK documentation.
7.1.4.4 2D Graphics Acceleration
Android bao gồm một cơ chế để các ứng dụng khai báo rằng chúng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp độ Ứng dụng, Hoạt động, Cửa sổ hoặc Khung hiển thị thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp.
Device implementations:
- [C-0-1] PHẢI bật tính năng tăng tốc phần cứng theo mặc định và PHẢI tắt tính năng tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách đặt android:hardwareAccelerated="false” hoặc tắt tính năng tăng tốc phần cứng trực tiếp thông qua API Khung hiển thị Android.
- [C-0-2] PHẢI thể hiện hành vi nhất quán với tài liệu về tính năng tăng tốc phần cứng của SDK Android.
Android bao gồm một đối tượng TextureView cho phép nhà phát triển trực tiếp tích hợp các kết cấu OpenGL ES được tăng tốc phần cứng làm mục tiêu kết xuất trong hệ phân cấp giao diện người dùng.
Device implementations:
- [C-0-3] PHẢI hỗ trợ API TextureView và PHẢI thể hiện hành vi nhất quán với cách triển khai Android ngược dòng.
7.1.4.5 Màn hình gam màu rộng
If device implementations claim support for wide-gamut displays through
Configuration.isScreenWideColorGamut()
, they:
- [C-1-1] MUST have a color-calibrated display.
- [C-1-2] MUST have a display whose gamut covers the sRGB color gamut entirely in CIE 1931 xyY space.
- [C-1-3] MUST have a display whose gamut has an area of at least 90% of DCI-P3 in CIE 1931 xyY space.
- [C-1-4] MUST support OpenGL ES 3.1 or 3.2 and report it properly.
- [C-1-5] MUST advertise support for the
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
, andEGL_EXT_gl_colorspace_display_p3_passthrough
extensions. - [C-SR-1] Are STRONGLY RECOMMENDED to support
GL_EXT_sRGB
.
Conversely, if device implementations do not support wide-gamut displays, they:
- [C-2-1] SHOULD cover 100% or more of sRGB in CIE 1931 xyY space, although the screen color gamut is undefined.
7.1.5. Chế độ tương thích với ứng dụng cũ
Android chỉ định một "chế độ tương thích" trong đó khung hoạt động ở chế độ tương đương với kích thước màn hình "bình thường" (chiều rộng 320 dp) để mang lại lợi ích cho các ứng dụng cũ không được phát triển cho các phiên bản Android cũ trước khi có tính năng độc lập với kích thước màn hình.
7.1.6. Công nghệ màn hình
Nền tảng Android bao gồm các API cho phép ứng dụng kết xuất đồ hoạ đa dạng thức cho màn hình tương thích với Android. Các thiết bị PHẢI hỗ trợ tất cả các API này như được xác định bởi SDK Android, trừ phi được cho phép cụ thể trong tài liệu này.
Tất cả màn hình tương thích với Android của một phương thức triển khai thiết bị:
- [C-0-1] MUST be capable of rendering 16-bit color graphics.
- SHOULD support displays capable of 24-bit color graphics.
- [C-0-2] MUST be capable of rendering animations.
- [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 từ 10 đến 15%.
7.1.7. Màn hình phụ
Android hỗ trợ màn hình phụ tương thích với Android để bật các tính năng chia sẻ nội dung nghe nhìn và API dành cho nhà phát triển để truy cập vào màn hình ngoài.
If device implementations support an external display either via a wired, wireless, or an embedded additional display connection, they:
- [C-1-1] PHẢI triển khai API và dịch vụ hệ thống
DisplayManager
như mô tả trong tài liệu SDK Android.
7.2. Thiết bị Đầu vào
Device implementations:
- [C-0-1] PHẢI có cơ chế nhập, chẳng hạn như màn hình cảm ứng hoặc chế độ điều hướng không chạm để di chuyển giữa các thành phần trên giao diện người dùng.
7.2.1. Bàn phím
If device implementations include support for third-party Input Method Editor (IME) applications, they:
- [C-1-1] MUST declare the
android.software.input_methods
feature flag. - [C-1-2] MUST implement fully
Input Management Framework
- [C-1-3] MUST have a preinstalled software keyboard.
Device implementations:
- [C-0-1] KHÔNG ĐƯỢC đưa bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard (QWERTY hoặc 12 phím).
- NÊN bao gồm các phương thức triển khai bàn phím mềm bổ sung.
- MAY include a hardware keyboard.
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.
Device implementations:
- [C-0-1] MUST report the correct value for android.content.res.Configuration.navigation.
If device implementations lack non-touch navigations, they:
- [C-1-1] MUST provide a reasonable alternative user interface mechanism for the selection and editing of text, compatible with Input Management Engines. Việc triển khai nguồn mở Android ngược dòng bao gồm một cơ chế lựa chọn phù hợp để sử dụng với các thiết bị thiếu phương thức nhập thao tác điều hướng không chạm.
7.2.3. Phím điều hướng
Các chức năng Home (Màn hình chính), Recents (Gần đây) và Back (Quay lại) thường được cung cấp thông qua hoạt động tương tác với một nút vật lý chuyên dụng hoặc một phần riêng biệt của màn hình cảm ứng. Đây là những chức năng thiết yếu đối với mô hình điều hướng của Android và do đó, cũng là những chức năng cần thiết để triển khai thiết bị:
- [C-0-1] PHẢI cung cấp cho người dùng khả năng khởi chạy các ứng dụng đã cài đặt có hoạt động với
<intent-filter>
được đặt bằngACTION=MAIN
vàCATEGORY=LAUNCHER
hoặcCATEGORY=LEANBACK_LAUNCHER
để triển khai thiết bị truyền hình. Hàm Home (Trang chủ) PHẢI là cơ chế cho hành vi này của người dùng. - SHOULD provide buttons for the Recents and Back function.
Nếu có các chức năng Home (Trang chủ), Recents (Gần đây) hoặc Back (Quay lại), thì các chức năng đó:
- [C-1-1] PHẢI truy cập được bằng một thao tác duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi có thể truy cập được bất kỳ thao tác nào trong số này.
- [C-1-2] PHẢI cho biết rõ hành động nào sẽ kích hoạt từng hàm. Ví dụ về các chỉ báo như vậy bao gồm việc in một biểu tượng rõ ràng trên nút, hiển thị biểu tượng phần mềm trên phần thanh điều hướng của màn hình hoặc hướng dẫn người dùng thực hiện quy trình minh hoạ từng bước trong quá trình thiết lập ngay khi lấy thiết bị ra khỏi hộp.
Device implementations:
[C-SR-1] are STRONGLY RECOMMENDED to not provide the input mechanism for the Menu function as it is deprecated in favor of action bar since Android 4.0.
[C-SR-2] Bạn NÊN cung cấp tất cả các chức năng điều hướng có thể huỷ. "Có thể huỷ" được xác định là khả năng của người dùng để ngăn chặn việc thực thi hàm điều hướng (ví dụ: quay lại màn hình chính, quay lại, v.v.) nếu thao tác vuốt không được nhả sau một ngưỡng nhất định.
If device implementations provide the Menu function, they:
- [C-2-1] PHẢI hiển thị nút trình đơn mục bổ sung thao tác bất cứ khi nào trình đơn mục bổ sung thao tác không trống và thanh thao tác hiển thị.
- [C-2-2] KHÔNG ĐƯỢC sửa đổi vị trí của trình đơn mục bổ sung thao tác được hiển thị bằng cách chọn nút mục bổ sung trong thanh thao tác, nhưng CÓ THỂ hiển thị trình đơn mục bổ sung thao tác ở một vị trí đã sửa đổi trên màn hình khi trình đơn này được hiển thị bằng cách chọn chức năng Trình đơn.
If device implementations do not provide the Menu function, for backwards compatibility, they:
- [C-3-1] PHẢI cung cấp chức năng Trình đơn cho các ứng dụng khi
targetSdkVersion
nhỏ hơn 10, thông qua nút vật lý, khoá phần mềm hoặc cử chỉ. Bạn phải có thể truy cập vào hàm Trình đơn này trừ phi hàm này bị ẩn cùng với các hàm điều hướng khác.
Nếu các phương thức triển khai thiết bị cung cấp chức năng Hỗ trợ, thì các phương thức đó:
- [C-4-1] PHẢI cho phép người dùng truy cập vào chức năng Trợ lý bằng một thao tác duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi có thể truy cập vào các phím điều hướng khác.
- [C-SR-3] STRONGLY RECOMMENDED to use long press on HOME function as this designated interaction.
If device implementations use a distinct portion of the screen to display the navigation keys, they:
- [C-5-1] Các phím điều hướng PHẢI sử dụng một phần màn hình riêng biệt, không dành cho ứng dụng và KHÔNG ĐƯỢC che khuất hoặc can thiệp vào phần màn hình dành cho ứng dụng.
- [C-5-2] MUST make available a portion of the display to applications that meet the requirements defined in section 7.1.1.
- [C-5-3] PHẢI tuân thủ các cờ do ứng dụng đặt thông qua phương thức API
View.setSystemUiVisibility()
, để phần riêng biệt này của màn hình (còn gọi là thanh điều hướng) được ẩn đúng cách như được ghi nhận trong SDK.
Nếu hàm điều hướng được cung cấp dưới dạng thao tác trên màn hình dựa trên cử chỉ:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
CHỈ được dùng để báo cáo khu vực nhận dạng cử chỉ trên màn hình chính. - [C-6-2] Các cử chỉ bắt đầu trong một hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp thông qua
View#setSystemGestureExclusionRects()
, nhưng nằm ngoàiWindowInsets#getMandatorySystemGestureInsets()
, KHÔNG ĐƯỢC chặn cho chức năng điều hướng, miễn là hình chữ nhật loại trừ được cho phép trong giới hạn loại trừ tối đa như được chỉ định trong tài liệu vềView#setSystemGestureExclusionRects()
. - [C-6-3] PHẢI gửi cho ứng dụng trên nền trước một sự kiện
MotionEvent.ACTION_CANCEL
sau khi các thao tác chạm bắt đầu bị chặn cho một cử chỉ hệ thống, nếu trước đó ứng dụng trên nền trước đã được gửi một sự kiệnMotionEvent.ACTION_DOWN
. - [C-6-4] PHẢI cung cấp cho người dùng khả năng chuyển sang thao tác điều hướng dựa trên nút trên màn hình (ví dụ: trong phần Cài đặt).
- NÊN cung cấp chức năng Màn hình chính bằng cách vuốt lên từ cạnh dưới cùng của hướng hiện tại của màn hình.
- NÊN cung cấp chức năng Gần đây bằng cách vuốt lên và giữ trước khi thả, từ cùng một khu vực với cử chỉ Trang chủ.
- Các cử chỉ bắt đầu trong
WindowInsets#getMandatorySystemGestureInsets()
KHÔNG được ảnh hưởng bởi các hình chữ nhật loại trừ do ứng dụng trên nền trước cung cấp thông quaView#setSystemGestureExclusionRects()
.
Nếu một hàm điều hướng được cung cấp từ bất kỳ vị trí nào trên cạnh trái và phải của hướng hiện tại của màn hình:
- [C-7-1] Hàm điều hướng PHẢI là Quay lại và được cung cấp dưới dạng thao tác vuốt từ cả cạnh trái và phải theo hướng hiện tại của màn hình.
- [C-7-2] Nếu các bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh được cung cấp ở cạnh trái hoặc bên phải, thì các bảng điều khiển đó PHẢI được đặt trong 1/3 trên cùng của màn hình với một chỉ báo hình ảnh rõ ràng, liên tục cho biết việc kéo vào sẽ gọi các bảng điều khiển đã đề cập, do đó không phải là Quay lại. Người dùng CÓ THỂ định cấu hình bảng điều khiển hệ thống sao cho bảng điều khiển nằm dưới 1/3 trên cùng của(các) cạnh màn hình, nhưng bảng điều khiển hệ thống KHÔNG ĐƯỢC sử dụng lâu hơn 1/3 của(các) cạnh.
- [C-7-3] Khi ứng dụng trên nền trước đặt cờ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT hoặc WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, thì thao tác vuốt từ các cạnh PHẢI hoạt động như được triển khai trong AOSP, được ghi nhận trong SDK.
- [C-7-4] Khi ứng dụng trên nền trước đặt cờ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT hoặc WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, các bảng điều khiển hệ thống có thể vuốt tuỳ chỉnh PHẢI được ẩn cho đến khi người dùng đưa vào hoặc bật thanh hệ thống (còn gọi là thanh điều hướng và thanh trạng thái) như được triển khai trong AOSP.
Nếu bạn cung cấp chức năng điều hướng quay lại và người dùng huỷ cử chỉ Quay lại, thì:
- [C-8-1] PHẢI gọi
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] KHÔNG ĐƯỢC gọi
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] KHÔNG ĐƯỢC gửi sự kiện KEYCODE_BACK.
Nếu bạn cung cấp hàm điều hướng quay lại nhưng ứng dụng trên nền trước KHÔNG đăng ký OnBackInvokedCallback
, thì:
- Hệ thống PHẢI cung cấp ảnh động cho ứng dụng trên nền trước cho biết người dùng đang quay lại, như được cung cấp trong AOSP.
Nếu các phương thức triển khai thiết bị hỗ trợ API hệ thống setNavBarMode
để cho phép mọi ứng dụng hệ thống có quyền android.permission.STATUS_BAR
đặt chế độ thanh điều hướng, thì các phương thức đó:
- [C-9-1] PHẢI hỗ trợ các biểu tượng phù hợp với trẻ em hoặc thao tác điều hướng dựa trên nút như được cung cấp trong mã AOSP.
7.2.4. Nhập bằng màn hình cảm ứng
Android hỗ trợ nhiều hệ thống nhập bằng con trỏ, chẳng hạn như màn hình cảm ứng, bàn di chuột và thiết bị nhập bằng thao tác chạm giả. Các phương thức triển khai thiết bị dựa trên màn hình cảm ứng được liên kết với một màn hình để người dùng có cảm giác trực tiếp thao tác với các mục trên màn hình. Since the user is directly touching the screen, the system does not require any additional affordances to indicate the objects being manipulated.
Device implementations:
- SHOULD have a pointer input system of some kind (either mouse-like or touch).
- SHOULD support fully independently tracked pointers.
If device implementations include a touchscreen (single-touch or better) on a primary Android-compatible display, they:
- [C-1-1] MUST report
TOUCHSCREEN_FINGER
for theConfiguration.touchscreen
API. - [C-1-2] MUST report the
android.hardware.touchscreen
andandroid.hardware.faketouch
feature flags.
If device implementations include a touchscreen that can track more than a single touch on a primary Android-compatible display, they:
- [C-2-1] MUST report the appropriate feature flags
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
corresponding to the type of the specific touchscreen on the device.
Nếu việc triển khai thiết bị dựa vào thiết bị đầu vào bên ngoài như chuột hoặc con lăn (tức là không trực tiếp chạm vào màn hình) để nhập trên màn hình chính tương thích với Android và đáp ứng các yêu cầu về thao tác chạm giả trong mục 7.2.5, thì:
- [C-3-1] KHÔNG ĐƯỢC báo cáo bất kỳ cờ tính năng nào bắt đầu bằng
android.hardware.touchscreen
. - [C-3-2] CHỈ ĐƯỢC báo cáo
android.hardware.faketouch
. - [C-3-3] PHẢI báo cáo
TOUCHSCREEN_NOTOUCH
cho trường APIConfiguration.touchscreen
.
7.2.5. Nhập bằng cách chạm giả
Giao diện cảm ứng giả cung cấp hệ thống hoạt động đầu vào của người dùng mà mô phỏng một số tính năng của màn hình cảm ứng. Ví dụ: con chuột hoặc điều khiển từ xa di chuyển con trỏ trên màn hình gần giống như thao tác chạm, nhưng yêu cầu người dùng phải trỏ hoặc lấy tiêu điểm trước rồi mới nhấp. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột không dây dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các hoạt động tương tác giả mạo bằng thao tác chạm. Android bao gồm hằng số tính năng android.hardware.faketouch, tương ứng với một thiết bị đầu vào không cảm ứng (dựa trên con trỏ) có độ trung thực cao, chẳng hạn như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ phương thức nhập dựa trên cảm ứng (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng của chức năng màn hình cảm ứng.
If device implementations do not include a touchscreen but include another pointer input system which they want to make available, they:
- SHOULD declare support for the
android.hardware.faketouch
feature flag.
If device implementations declare support for android.hardware.faketouch
,
they:
- [C-1-1] PHẢI báo cáo vị trí màn hình X và Y tuyệt đối của vị trí con trỏ và hiển thị con trỏ hình ảnh trên màn hình.
- [C-1-2] PHẢI báo cáo sự kiện chạm bằng mã hành động chỉ định sự 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] MUST support pointer down and up on an object on the screen, which allows users to emulate tap on an object on the screen.
- [C-1-4] MUST support pointer down, pointer up, pointer down then pointer up in the same place on an object on the screen within a threshold time, which allows users to emulate double tap on an object on the screen.
- [C-1-5] MUST support pointer down on an arbitrary point on the screen, pointer move to any other arbitrary point on the screen, followed by a pointer up, which allows users to emulate a touch drag.
- [C-1-6] MUST support pointer down then allow users to quickly move the object to a different position on the screen and then pointer up on the screen, which allows users to fling an object on the screen.
If device implementations declare support for
android.hardware.faketouch.multitouch.distinct
, they:
- [C-2-1] MUST declare support for
android.hardware.faketouch
. - [C-2-2] MUST support distinct tracking of two or more independent pointer input.
If device implementations declare support for
android.hardware.faketouch.multitouch.jazzhand
, they:
- [C-3-1] PHẢI khai báo hỗ trợ
android.hardware.faketouch
. - [C-3-2] MUST support distinct tracking of 5 (tracking a hand of fingers) or more pointer inputs fully independently.
7.2.6. Hỗ trợ tay điều khiển trò chơi
7.2.6.1. Ánh xạ nút
Device implementations:
- [C-1-1] MUST be capable to map HID events to the corresponding
InputEvent
constants as listed in the below tables. Cách triển khai Android ngược dòng đáp ứng yêu cầu này.
Nếu các phương thức triển khai thiết bị nhúng một tay điều khiển hoặc đi kèm với một tay điều khiển riêng biệt trong hộp để cung cấp phương tiện nhập tất cả các sự kiện được liệt kê trong các bảng bên dưới, thì các phương thức đó:
- [C-2-1] MUST declare the feature flag
android.hardware.gamepad
Nút | HID Usage2 | Nút Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Có1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad up1 D-pad down1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad left1 D-pad right1 |
0x01 0x00393 | AXIS_HAT_X4 |
Left shoulder button1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Right shoulder button1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Left stick click1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Right stick click1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Quay lại1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).
3 This usage must have a Logical Minimum of 0, a Logical Maximum of 7, a Physical Minimum of 0, a Physical Maximum of 315, Units in Degrees, and a Report Size of 4. Giá trị logic được xác định là xoay theo chiều kim đồng hồ ra khỏi trục dọc; ví dụ: giá trị logic 0 thể hiện không xoay và nút mũi tên lên đang được nhấn, trong khi giá trị logic 1 thể hiện xoay 45 độ và cả nút mũi tên lên và trái đang được nhấn.
Analog Controls1 | Mức sử dụng HID | Nút Android |
---|---|---|
Left Trigger | 0x02 0x00C5 | AXIS_LTRIGGER |
Right Trigger | 0x02 0x00C4 | AXIS_RTRIGGER |
Left Joystick | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
Right Joystick | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7. Điều khiển từ xa
See Section 2.3.1 for device-specific requirements.
7.3. Cảm biến
If device implementations include a particular sensor type that has a corresponding API for third-party developers, the device implementation MUST implement that API as described in the Android SDK documentation and the Android Open Source documentation on sensors.
Device implementations:
- [C-0-1] PHẢI báo cáo chính xác sự hiện diện hoặc vắng mặt của cảm biến theo lớp
android.content.pm.PackageManager
. - [C-0-2] PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua
SensorManager.getSensorList()
và các phương thức tương tự. - [C-0-3] PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về
true
hoặcfalse
khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.).
If device implementations include a particular sensor type that has a corresponding API for third-party developers, they:
- [C-1-1] PHẢI báo cáo tất cả kết quả đo lường của cảm biến bằng cách sử dụng các giá trị tương ứng của Hệ thống đo lường quốc tế (theo hệ mét) cho từng loại cảm biến như được xác định trong tài liệu SDK Android.
- [C-1-2] PHẢI báo cáo dữ liệu cảm biến có độ trễ tối đa là 100 mili giây + 2 * sample_time đối với trường hợp luồng cảm biến có độ trễ tối đa được yêu cầu là 0 mili giây khi bộ xử lý ứng dụng đang hoạt động. Độ trễ này không bao gồm độ trễ lọc.
- [C-1-3] PHẢI báo cáo mẫu cảm biến đầu tiên trong vòng 400 mili giây + 2 * thời gian lấy mẫu của cảm biến đang được kích hoạt. Mẫu này có thể có độ chính xác là 0.
- [C-1-4] Đối với mọi API mà tài liệu SDK Android cho biết là một cảm biến liên tục, việc triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ, trong đó độ trễ PHẢI dưới 3%, trong đó độ trễ được xác định là độ lệch chuẩn của chênh lệch giữa các giá trị dấu thời gian được báo cáo giữa các sự kiện liên tiếp.
- [C-1-5] PHẢI đảm bảo rằng luồng sự kiện cảm biến KHÔNG được ngăn CPU thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức thiết bị từ trạng thái tạm ngưng.
- [C-1-6] PHẢI báo cáo thời gian xảy ra sự kiện bằng nano giây như được xác định trong tài liệu SDK Android, đại diện cho thời gian xảy ra sự kiện và được đồng bộ hoá với đồng hồ SystemClock.elapsedRealtimeNano().
- [C-SR-1] Bạn NÊN có lỗi đồng bộ hoá dấu thời gian dưới 100 mili giây và PHẢI có lỗi đồng bộ hoá dấu thời gian dưới 1 mili giây.
- Khi nhiều cảm biến được kích hoạt, mức tiêu thụ điện năng KHÔNG ĐƯỢC vượt quá tổng mức tiêu thụ điện năng được báo cáo của từng cảm biến.
Danh sách trên chưa đầy đủ; hành vi được ghi nhận của SDK Android và Tài liệu nguồn mở Android về cảm biến được coi là có thẩm quyền.
If device implementations include a particular sensor type that has a corresponding API for third-party developers, they:
- [C-1-6] PHẢI đặt độ phân giải khác 0 cho tất cả cảm biến và báo cáo giá trị thông qua phương thức API
Sensor.getResolution()
.
Một số loại cảm biến là tổng hợp, nghĩa là chúng có thể được lấy từ dữ liệu do một hoặc nhiều cảm biến khác cung cấp. (Ví dụ: cảm biến hướng và cảm biến gia tốc tuyến tính.)
Device implementations:
- NÊN triển khai các loại cảm biến này, khi các loại cảm biến này bao gồm các cảm biến vật lý cần thiết như mô tả trong các loại cảm biến.
If device implementations include a composite sensor, they:
- [C-2-1] PHẢI triển khai cảm biến như mô tả trong tài liệu về cảm biến tổng hợp của Android Open Source.
Nếu các phương thứ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 và cảm biến chỉ báo cáo một giá trị, thì các phương thức triển khai thiết bị:
- [C-3-1] PHẢI đặt độ phân giải thành 1 cho cảm biến và báo cáo giá trị thông qua phương thức API
Sensor.getResolution()
.
Nếu các phương thức triển khai thiết bị bao gồm một loại cảm biến cụ thể hỗ trợ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION và cảm biến được hiển thị cho các nhà phát triển bên thứ ba, thì họ:
- [C-4-1] KHÔNG ĐƯỢC đưa bất kỳ thông số hiệu chuẩn cố định nào do nhà máy xác định vào dữ liệu được cung cấp.
If device implementations include a combination of 3-axis accelerometer, a 3-axis gyroscope sensor, or a magnetometer sensor, they are:
- [C-SR-2] NÊN đảm bảo rằng gia tốc kế, con quay hồi chuyển và cảm biến từ trường có vị trí tương đối cố định, chẳng hạn như nếu thiết bị có thể biến đổi (ví dụ: có thể gập lại), các trục cảm biến vẫn được căn chỉnh và nhất quán với hệ toạ độ cảm biến trong tất cả các trạng thái biến đổi thiết bị có thể có.
7.3.1. Gia tốc kế
Device implementations:
- [C-SR-1] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
If device implementations include an accelerometer, they:
- [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
- [C-1-3] PHẢI tuân thủ hệ toạ độ cảm biến Android như mô tả chi tiết trong API Android.
- [C-1-4] MUST be capable of measuring from freefall up to four times the gravity(4g) or more on any axis.
- [C-1-5] MUST have a resolution of at least 12-bits.
- [C-1-6] MUST have a standard deviation no greater than 0.05 m/s^, where the standard deviation should be calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate.
- SHOULD report events up to at least 200 Hz.
- SHOULD have a resolution of at least 16-bits.
- SHOULD be calibrated while in use if the characteristics changes over the life cycle and compensated, and preserve the compensation parameters between device reboots.
- SHOULD be temperature compensated.
If device implementations include a 3-axis accelerometer, they:
- [C-2-1] MUST implement and report
TYPE_ACCELEROMETER
sensor. - [C-SR-4] Bạn NÊN triển khai cảm biến tổng hợp
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] Bạn NÊN triển khai và báo cáo cảm biến
TYPE_ACCELEROMETER_UNCALIBRATED
. Các thiết bị Android NÊN đá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, trong đó yêu cầu này có thể trở thành BẮT BUỘC. - NÊN triển khai các cảm biến tổng hợp
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
như mô tả trong tài liệu SDK Android.
If device implementations include an accelerometer with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES
sensor. - [C-SR-6] Bạn NÊN triển khai và báo cáo cảm biến
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
If device implementations include a 3-axis accelerometer and any of the
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
,
TYPE_STEP_COUNTER
composite sensors are implemented:
- [C-4-1] The sum of their power consumption MUST always be less than 4 mW.
- SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or static condition.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors. - [C-SR-7] Bạn NÊN triển khai cảm biến tổng hợp
TYPE_GAME_ROTATION_VECTOR
.
If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:
- [C-6-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
7.3.2. Từ kế
Device implementations:
- [C-SR-1] Bạn NÊN sử dụng con quay hồi chuyển 3 trục (la bàn).
If device implementations include a 3-axis magnetometer, they:
- [C-1-1] PHẢI triển khai cảm biến
TYPE_MAGNETIC_FIELD
. - [C-1-2] MUST be able to report events up to a frequency of at least 10 Hz and SHOULD report events up to at least 50 Hz.
- [C-1-3] PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android.
- [C-1-4] MUST be capable of measuring between -900 µT and +900 µT on each axis before saturating.
- [C-1-5] PHẢI có giá trị chênh lệch từ sắt cứng nhỏ hơn 700 µT và NÊN có giá trị dưới 200 µT, bằng cách đặt máy đo từ trường cách xa các trường từ động (do dòng điện tạo ra) và trường từ tĩnh (do nam châm tạo ra).
- [C-1-6] PHẢI có độ phân giải bằng hoặc cao hơn 0,6 µT.
- [C-1-7] MUST support online calibration and compensation of the hard iron bias, and preserve the compensation parameters between device reboots.
- [C-1-8] BẮT BUỘC phải áp dụng tính năng bù sắt mềm – bạn có thể thực hiện việc hiệu chuẩn trong khi sử dụng hoặc trong quá trình sản xuất thiết bị.
- [C-1-9] MUST have a standard deviation, calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate, no greater than 1.5 µT; SHOULD have a standard deviation no greater than 0.5 µT.
- [C-1-10] PHẢI triển khai cảm biến
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
If device implementations include a 3-axis magnetometer, an accelerometer sensor, and a 3-axis gyroscope sensor, they:
- [C-2-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
If device implementations include a 3-axis magnetometer, an accelerometer, they:
- MAY implement the
TYPE_GEOMAGNETIC_ROTATION_VECTOR
sensor.
If device implementations include a 3-axis magnetometer, an accelerometer and
TYPE_GEOMAGNETIC_ROTATION_VECTOR
sensor, they:
- [C-3-1] PHẢI tiêu thụ ít hơn 10 mW.
- SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz.
7.3.3. GPS
Device implementations:
- [C-SR-1] Are STRONGLY RECOMMENDED to include a GPS/GNSS receiver.
If device implementations include a GPS/GNSS receiver and report the capability
to applications through the android.hardware.location.gps
feature flag, they:
- [C-1-1] PHẢI hỗ trợ đầu ra vị trí với tốc độ tối thiểu là 1 Hz khi được yêu cầu thông qua
LocationManager#requestLocationUpdate
. - [C-1-2] PHẢI xác định được vị trí trong điều kiện bầu trời quang đãng (tín hiệu mạnh, đa đường truyền không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian nhanh để xác định vị trí lần đầu tiên), khi kết nối với kết nối Internet có tốc độ dữ liệu từ 0,5 Mb/giây trở lên. Yêu cầu này thường được đáp ứng bằng cách sử dụng một số kỹ thuật GPS/GNSS được hỗ trợ hoặc dự đoán để giảm thiểu thời gian khoá GPS/GNSS (Dữ liệu hỗ trợ bao gồm Thời gian tham chiếu, Vị trí tham chiếu và Bảng thông tin về vệ tinh/Đồng hồ).
- [C-1-6] Sau khi thực hiện phép tính vị trí như vậy, việc triển khai thiết bị PHẢI xác định vị trí của thiết bị, ở ngoài trời, trong vòng 5 giây, khi các yêu cầu vị trí được khởi động lại, tối đa một giờ sau khi thực hiện phép tính vị trí ban đầu, ngay cả khi yêu cầu tiếp theo được thực hiện mà không có kết nối dữ liệu và/hoặc sau một chu kỳ nguồn.
Trong điều kiện ngoài trời sau khi xác định vị trí, khi đứng yên hoặc di chuyển với gia tốc dưới 1 mét trên giây bình phương:
- [C-1-3] MUST be able to determine location within 20 meters, and speed within 0.5 meters per second, at least 95% of the time.
- [C-1-4] MUST simultaneously track and report via
GnssStatus.Callback
at least 8 satellites from one constellation. - SHOULD be able to simultaneously track at least 24 satellites, from multiple constellations (e.g. GPS + at least one of Glonass, Beidou, Galileo).
[C-SR-2] NÊN tiếp tục phân phối các kết quả vị trí GPS/GNSS thông thường thông qua API Nhà cung cấp vị trí GNSS trong khi gọi điện khẩn cấp.
[C-SR-3] NÊN báo cáo kết quả đo lường GNSS từ tất cả các hệ thống vệ tinh được theo dõi (như được báo cáo trong thông báo GnssStatus), ngoại trừ SBAS.
[C-SR-4] Bạn NÊN báo cáo AGC và Tần suất đo lường GNSS.
[C-SR-5] Bạn NÊN báo cáo tất cả các thông tin ước tính về độ chính xác (bao gồm cả Độ dốc, Tốc độ và Độ cao) trong mỗi vị trí GPS/GNSS.
[C-SR-6] Bạn NÊN báo cáo các phép đo GNSS ngay khi phát hiện được, ngay cả khi vị trí được tính toán từ GPS/GNSS chưa được báo cáo.
[C-SR-7] Bạn NÊN báo cáo khoảng thời gian giả và tốc độ khoảng thời gian giả của GNSS. Trong điều kiện bầu trời quang đãng sau khi xác định vị trí, khi đứng yên hoặc di chuyển với gia tốc dưới 0,2 mét trên giây vuông, các thông tin này đủ để tính toán vị trí trong phạm vi 20 mét và tốc độ trong phạm vi 0,2 mét trên giây, ít nhất là 95% thời gian.
7.3.4. Con quay hồi chuyển
Device implementations:
- [C-SR-1] Are STRONGLY RECOMMENDED to include a gyroscope sensor.
If device implementations include a gyroscope, they:
- [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
- [C-1-4] MUST have a resolution of 12-bits or more.
- [C-1-5] MUST be temperature compensated.
- [C-1-6] PHẢI được hiệu chỉnh và bù khi đang sử dụng, đồng thời duy trì các tham số bù giữa các lần khởi động lại thiết bị.
- [C-1-7] PHẢI có độ lệch không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (độ lệch trên mỗi Hz hoặc rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. Nói cách khác, nếu bạn đo lường độ lệch chuẩn của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì độ lệch chuẩn này KHÔNG được lớn hơn 1e-7 rad^2/s^2.
- [C-SR-2] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
- [C-SR-3] NÊN có độ phân giải từ 16 bit trở lên.
- SHOULD report events up to at least 200 Hz.
If device implementations include a 3-axis gyroscope, they:
- [C-2-1] PHẢI triển khai cảm biến
TYPE_GYROSCOPE
. - [C-SR-4] Bạn nên triển khai cảm biến
TYPE_GYROSCOPE_UNCALIBRATED
.
If device implementations include a gyroscope with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES
sensor. - [C-SR-5] Bạn NÊN triển khai và báo cáo cảm biến
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:
- [C-4-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors. - [C-SR-6] Bạn NÊN triển khai cảm biến tổng hợp
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. Khí áp kế
Device implementations:
- [C-SR-1] Bạn NÊN sử dụng một áp kế (cảm biến áp suất không khí xung quanh).
If device implementations include a barometer, they:
- [C-1-1] MUST implement and report
TYPE_PRESSURE
sensor. - [C-1-2] PHẢI có khả năng phân phối sự kiện ở tần suất 5 Hz trở lên.
- [C-1-3] MUST be temperature compensated.
- [C-SR-2] STRONGLY RECOMMENDED to be able to report pressure measurements in the range 300hPa to 1100hPa.
- SHOULD have an absolute accuracy of 1hPa.
- SHOULD have a relative accuracy of 0.12hPa over 20hPa range (tương đương với độ chính xác ~1m trên khoảng thay đổi ~200m ở mực nước biển).
7.3.6. Nhiệt kế
If device implementations include an ambient thermometer (temperature sensor), they:
- [C-1-1] PHẢI xác định
SENSOR_TYPE_AMBIENT_TEMPERATURE
cho cảm biến nhiệt độ môi trường xung quanh và cảm biến PHẢI đo nhiệt độ môi trường xung quanh (phòng/cabin xe) tại vị trí người dùng đang tương tác với thiết bị theo độ C.
If device implementations include a thermometer sensor that measures a nhiệt độ khác với nhiệt độ môi trường xung quanh, chẳng hạn như nhiệt độ CPU, thì:
- [C-2-1] KHÔNG ĐƯỢC xác định
SENSOR_TYPE_AMBIENT_TEMPERATURE
cho cảm biến nhiệt độ.
Nếu các phương thức triển khai thiết bị bao gồm một cảm biến để theo dõi nhiệt độ da, thì các phương thức đó:
- [C-SR-1] Bạn NÊN hỗ trợ API PowerManager.getThermalHeadroom.
7.3.7. Photometer
- Device implementations MAY include a photometer (ambient light sensor).
7.3.8. Cảm biến độ gần
- Device implementations MAY include a proximity sensor.
Nếu các phương thức triển khai thiết bị bao gồm cảm biến khoảng cách và chỉ báo cáo giá trị đọc nhị phân "gần" hoặc "xa", thì các phương thức đó:
- [C-1-1] MUST measure the proximity of an object in the same direction as the screen. Tức là cảm biến khoảng cách PHẢI được định hướng để phát hiện các đối tượng gần màn hình, vì ý định chính của loại cảm biến này là phát hiện điện thoại mà người dùng đang sử dụng. Nếu các phương thức triển khai thiết bị bao gồm cảm biến khoảng cách với hướng bất kỳ khác, thì bạn KHÔNG ĐƯỢC truy cập vào cảm biến đó thông qua API này.
- [C-1-2] PHẢI có độ chính xác từ 1 bit trở lên.
- [C-1-3] PHẢI sử dụng 0 cm làm giá trị đọc gần và 5 cm làm giá trị đọc xa.
- [C-1-4] PHẢI báo cáo phạm vi và độ phân giải tối đa là 5.
7.3.9. Cảm biến có độ chân thực cao
If device implementations include a set of higher quality sensors as defined in this section, and make available them to third-party apps, they:
- [C-1-1] MUST identify the capability through the
android.hardware.sensor.hifi_sensors
feature flag.
If device implementations declare android.hardware.sensor.hifi_sensors
,
they:
[C-2-1] MUST have a
TYPE_ACCELEROMETER
sensor which:- MUST have a measurement range between at least -8g and +8g, and is STRONGLY RECOMMENDED to have a measurement range between at least -16g and +16g.
- MUST have a measurement resolution of at least 2048 LSB/g.
- MUST have a minimum measurement frequency of 12.5 Hz or lower.
- MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD
support the SensorDirectChannel
RATE_VERY_FAST
. - MUST have a measurement noise not above 400 μg/√Hz.
- MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events.
- MUST have a batching power consumption not worse than 3 mW.
- [C-SR-1] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at least 80% of Nyquist frequency, and white noise spectrum within this bandwidth.
- SHOULD have an acceleration random walk less than 30 μg √Hz tested at room temperature.
- SHOULD have a bias change vs. temperature of ≤ +/- 1 mg/°C.
- SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤ 0.03%/C°.
- SHOULD have cross-axis sensitivity of < 2.5 % and variation of cross-axis sensitivity < 0.2% in device operation temperature range.
[C-2-2] MUST have a
TYPE_ACCELEROMETER_UNCALIBRATED
with the same requirements về chất lượng asTYPE_ACCELEROMETER
.[C-2-3] MUST have a
TYPE_GYROSCOPE
sensor which:- MUST have a measurement range between at least -1000 and +1000 dps.
- MUST have a measurement resolution of at least 16 LSB/dps.
- MUST have a minimum measurement frequency of 12.5 Hz or lower.
- MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD
support the SensorDirectChannel
RATE_VERY_FAST
. - MUST have a measurement noise not above 0.014°/s/√Hz.
- [C-SR-2] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at least 80% of Nyquist frequency, and white noise spectrum within this bandwidth.
- SHOULD have a rate random walk less than 0.001 °/s √Hz tested at room temperature.
- SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C.
- SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C.
- SHOULD have a best-fit line non-linearity of ≤ 0.2%.
- SHOULD have a noise density of ≤ 0.007 °/s/√Hz.
- SHOULD have calibration error less than 0.002 rad/s in temperature range 10 ~ 40 ℃ when device is stationary.
- SHOULD have g-sensitivity less than 0.1°/s/g.
- SHOULD have cross-axis sensitivity of < 4.0 % and cross-axis sensitivity variation < 0.3% in device operation temperature range.
[C-2-4] PHẢI có
TYPE_GYROSCOPE_UNCALIBRATED
với các yêu cầu về chất lượng giống nhưTYPE_GYROSCOPE
.[C-2-5] MUST have a
TYPE_GEOMAGNETIC_FIELD
sensor which:- MUST have a measurement range between at least -900 and +900 μT.
- MUST have a measurement resolution of at least 5 LSB/uT.
- MUST have a minimum measurement frequency of 5 Hz or lower.
- MUST have a maximum measurement frequency of 50 Hz or higher.
- MUST have a measurement noise not above 0.5 uT.
[C-2-6] PHẢI có
TYPE_MAGNETIC_FIELD_UNCALIBRATED
với các yêu cầu về chất lượng giống nhưTYPE_GEOMAGNETIC_FIELD
và ngoài ra:- MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events.
- [C-SR-3] Is STRONGLY RECOMMENDED to have white noise spectrum from 1 Hz to at least 10 Hz when the report rate is 50 Hz or higher.
[C-2-7] MUST have a
TYPE_PRESSURE
sensor which:- MUST have a measurement range between at least 300 and 1100 hPa.
- MUST have a measurement resolution of at least 80 LSB/hPa.
- MUST have a minimum measurement frequency of 1 Hz or lower.
- MUST have a maximum measurement frequency of 10 Hz or higher.
- MUST have a measurement noise not above 2 Pa/√Hz.
- MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events.
- MUST have a batching power consumption not worse than 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
:- MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving.
[C-2-10] PHẢI có cảm biến
TYPE_STEP_DETECTOR
:- MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events.
- MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving.
- MUST have a batching power consumption not worse than 4 mW.
[C-2-11] PHẢI có cảm biến
TYPE_STEP_COUNTER
:- MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving.
[C-2-12] PHẢI có cảm biến
TILT_DETECTOR
:- MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving.
[C-2-13] The event timestamp of the same physical event reported by the Accelerometer, Gyroscope, and Magnetometer MUST be within 2.5 milliseconds of each other. Dấu thời gian của sự kiện về cùng một sự kiện vật lý do Con quay hồi chuyển và Gia tốc kế báo cáo PHẢI nằm trong khoảng 0,25 mili giây so với nhau.
[C-2-14] PHẢI có dấu thời gian sự kiện của cảm biến Con quay hồi chuyển trên cùng một cơ sở thời gian với hệ thống con máy ảnh và sai số trong phạm vi 1 mili giây.
[C-2-15] PHẢI phân phối mẫu cho ứng dụng trong vòng 5 mili giây kể từ thời điểm ứng dụng có dữ liệu trên bất kỳ cảm biến vật lý nào nêu trên.
[C-2-16] KHÔNG ĐƯỢC tiêu thụ nhiều hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 2,0 mW khi thiết bị đang di chuyển khi bất kỳ tổ hợp cảm biến nào sau đây được bật:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] CÓ THỂ có cảm biến
TYPE_PROXIMITY
, nhưng nếu có, PHẢI có dung lượng bộ đệm tối thiểu là 100 sự kiện cảm biến.
Lưu ý rằng tất cả các yêu cầu về mức tiêu thụ điện năng trong phần này đều không bao gồm mức tiêu thụ điện năng của Bộ xử lý ứng dụng. Mức tiêu thụ này bao gồm cả nguồn điện mà toàn bộ chuỗi cảm biến tiêu thụ – cảm biến, mọi mạch điện hỗ trợ, mọi hệ thống xử lý cảm biến chuyên dụng, v.v.
If device implementations include direct sensor support, they:
- [C-3-1] MUST correctly declare support of direct channel types and direct
report rates level through the
isDirectChannelTypeSupported
andgetHighestDirectReportRateLevel
API. - [C-3-2] PHẢI hỗ trợ ít nhất một trong hai loại kênh trực tiếp của cảm biến cho tất cả các cảm biến khai báo hỗ trợ kênh trực tiếp của cảm biến.
- SHOULD support event reporting through sensor direct channel for primary
sensor (non-wakeup variant) of the following types:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Cảm biến sinh trắc học
Để biết thêm thông tin cơ bản về tính năng Đo lường bảo mật khi mở khoá bằng sinh trắc học, vui lòng xem tài liệu về tính năng Đo lường bảo mật bằng sinh trắc học.
If device implementations include a secure lock screen, they:
- NÊN có cảm biến sinh trắc học
Cảm biến sinh trắc học có thể được phân loại là Lớp 3 (trước đây là Mạnh), Lớp 2 (trước đây là Yếu) hoặc Lớp 1 (trước đây là Tiện lợi) dựa trên tỷ lệ chấp nhận giả mạo và tỷ lệ chấp nhận người dùng giả mạo, cũng như dựa trên độ bảo mật của quy trình sinh trắc học. Việc phân loại này xác định các chức năng mà cảm biến sinh trắc học cần có để giao tiếp với nền tảng và với các ứng dụng của bên thứ ba. Cảm biến cần đáp ứng các yêu cầu bổ sung như được nêu chi tiết bên dưới nếu muốn được phân loại là Lớp 1, Lớp 2 hoặc Lớp 3. Cả thông tin sinh trắc học Lớp 2 và Lớp 3 đều có các chức năng bổ sung như được nêu chi tiết bên dưới.
Nếu các phương thức triển khai thiết bị cung cấp cảm biến sinh trắc học cho các ứng dụng bên thứ ba thông qua android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt và android.provider.Settings.ACTION_BIOMETRIC_ENROLL, thì:
- [C-4-1] PHẢI đáp ứng các yêu cầu đối với thông tin sinh trắc học Lớp 3 hoặc Lớp 2 như được xác định trong tài liệu này.
- [C-4-2] PHẢI nhận dạng và tuân thủ từng tên tham số được xác định là hằng số trong lớp Authenticator (Trình xác thực) và mọi tổ hợp của các tên đó. Ngược lại, KHÔNG được tuân thủ hoặc nhận dạng các hằng số số nguyên được truyền đến các phương thức canAuthenticate(int) và setAllowedAuthenticators(int), ngoại trừ các hằng số được ghi nhận là hằng số công khai trong Authenticators và mọi tổ hợp của các hằng số đó.
- [C-4-3] PHẢI triển khai thao tác ACTION_BIOMETRIC_ENROLL trên các thiết bị có thông tin sinh trắc học Lớp 3 hoặc Lớp 2. Thao tác này PHẢI chỉ hiển thị các điểm truy cập đăng ký cho dữ liệu sinh trắc học Lớp 3 hoặc Lớp 2.
Nếu các phương thức triển khai thiết bị hỗ trợ sinh trắc học thụ động, thì các phương thức đó:
- [C-5-1] Theo mặc định, BẮT BUỘC phải yêu cầu thêm một bước xác nhận (ví dụ: nhấn nút).
- [C-SR-1] NÊN có chế độ cài đặt cho phép người dùng ghi đè lựa chọn ưu tiên của ứng dụng và luôn yêu cầu bước xác nhận đi kèm.
- [C-SR-2] Are STRONGLY RECOMMENDED to have the confirm action be secured such that an operating system or kernel compromise cannot spoof it. Ví dụ: điều này có nghĩa là thao tác xác nhận dựa trên nút vật lý được định tuyến thông qua một chân đầu vào/đầu ra (GPIO) đa năng chỉ có đầu vào của một phần tử bảo mật (SE) mà không thể được điều khiển bằng bất kỳ phương tiện nào khác ngoài thao tác nhấn nút vật lý.
- [C-5-2] PHẢI triển khai thêm quy trình xác thực ngầm ẩn (không có bước xác nhận) tương ứng với setConfirmationRequired(boolean) mà các ứng dụng có thể thiết lập để sử dụng cho quy trình đăng nhập.
If device implementations have multiple biometric sensors, they:
Bắt đầu yêu cầu mới
[C-7-1] PHẢI, khi một phương thức nhận dạng sinh trắc học bị khoá (tức là phương thức nhận dạng sinh trắc học bị vô hiệu hoá cho đến khi người dùng mở khoá bằng phương thức xác thực chính) hoặc bị khoá theo thời gian (tức là phương thức nhận dạng sinh trắc học bị tạm thời vô hiệu hoá cho đến khi người dùng chờ một khoảng thời gian) do quá nhiều lần thử không thành công, cũng khoá tất cả các phương thức nhận dạng sinh trắc học khác thuộc lớp sinh trắc học thấp hơn. Trong trường hợp khoá có giới hạn thời gian, thời gian đợi để xác minh bằng sinh trắc học PHẢI là thời gian đợi tối đa của tất cả phương thức sinh trắc học trong trường hợp khoá có giới hạn thời gian.
[C-SR-12] NÊN, khi một phương thức sinh trắc học bị khoá (tức là phương thức sinh trắc học bị vô hiệu hoá cho đến khi người dùng mở khoá bằng phương thức xác thực chính) hoặc bị khoá theo thời gian (tức là phương thức sinh trắc học bị tạm thời vô hiệu hoá cho đến khi người dùng chờ một khoảng thời gian) do quá nhiều lần thử không thành công, thì cũng nên khoá tất cả phương thức sinh trắc học khác thuộc cùng một loại sinh trắc học. Trong trường hợp khoá có giới hạn thời gian, bạn NÊN đặt thời gian đợi để xác minh bằng sinh trắc học là thời gian đợi tối đa của tất cả phương thức sinh trắc học trong trường hợp khoá có giới hạn thời gian.
[C-7-2] PHẢI yêu cầu người dùng xác thực bằng phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) để đặt lại bộ đếm khoá khi phương thức xác thực sinh trắc học bị khoá. Phương thức xác thực sinh trắc học Loại 3 CÓ THỂ được phép đặt lại bộ đếm khoá cho phương thức xác thực sinh trắc học bị khoá thuộc cùng loại hoặc loại thấp hơn. KHÔNG ĐƯỢC cho phép phương thức xác thực sinh trắc học Loại 2 hoặc Loại 1 hoàn tất thao tác khoá đặt lại cho bất kỳ phương thức xác thực sinh trắc học nào.
Kết thúc các yêu cầu mới
- [C-SR-3] Bạn NÊN chỉ yêu cầu xác nhận một thông tin sinh trắc học cho mỗi lần xác thực (ví dụ: nếu cả cảm biến vân tay và cảm biến khuôn mặt đều có trên thiết bị, thì bạn nên gửi onAuthenticationSucceeded sau khi xác nhận bất kỳ thông tin sinh trắc học nào).
Để cho phép các phương thức triển khai thiết bị cấp quyền truy cập vào khoá kho khoá cho các ứng dụng bên thứ ba, các phương thức triển khai thiết bị phải:
- [C-6-1] PHẢI đáp ứng các yêu cầu đối với Lớp 3 như được xác định trong phần này bên dưới.
- [C-6-2] CHỈ được hiển thị thông tin sinh trắc học Lớp 3 khi quy trình xác thực yêu cầu BIOMETRIC_STRONG hoặc quy trình xác thực được gọi bằng CryptoObject.
Nếu các phương thức triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 1 (trước đây là Tiện lợi), thì các phương thức đó:
- [C-1-1] PHẢI có tỷ lệ chấp nhận sai dưới 0,002%.
- [C-1-2] PHẢI công bố rằng chế độ này có thể kém an toàn hơn so với mã PIN, hình mở khoá hoặc mật khẩu khó đoán và nêu rõ các rủi ro khi bật chế độ này, nếu tỷ lệ chấp nhận hành vi giả mạo và mạo danh cao hơn 7% theo Giao thức kiểm thử sinh trắc học của Android.
- [C-1-9] PHẢI thách thức người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) sau không quá 20 lần thử không thành công và thời gian chờ không dưới 90 giây để xác minh sinh trắc học – trong đó lần thử không thành công là lần thử có chất lượng thu thập đủ (BIOMETRIC_ACQUIRED_GOOD) nhưng không khớp với thông tin sinh trắc học đã đăng ký.
- [C-SR-4] Bạn NÊN giảm tổng số lượt thử nghiệm sai cho quy trình xác minh sinh trắc học được chỉ định trong [C-1-9] nếu tỷ lệ chấp nhận giả mạo và giả mạo cao hơn 7% theo đo lường của Giao thức kiểm thử sinh trắc học của Android.
- [C-1-3] PHẢI giới hạn số lần xác minh sinh trắc học – trong đó một lần thử nghiệm không thành công là một lần thử nghiệm có chất lượng chụp đủ (
BIOMETRIC_ACQUIRED_GOOD
) không khớp với dữ liệu sinh trắc học đã đăng ký. - [C-SR-5] Bạn NÊN đặt giới hạn số lần thử trong ít nhất 30 giây sau 5 lần thử không thành công để xác minh sinh trắc học cho số lần thử không thành công tối đa theo [C-1-9] – trong đó một lần thử không thành công là một lần thử có chất lượng thu thập đủ (BIOMETRIC_ACQUIRED_GOOD) nhưng không khớp với thông tin sinh trắc học đã đăng ký.
- [C-SR-6] Bạn NÊN có tất cả logic giới hạn tốc độ trong TEE.
[C-1-10] PHẢI tắt tính năng sinh trắc học sau khi thời gian chờ xác thực chính được kích hoạt lần đầu như mô tả trong [C-0-2] của mục 9.11.
[C-1-11] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 30%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 30% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh của các loại PAI cấp B không cao hơn 40%, theo đo lường của Giao thức kiểm thử sinh trắc học Android.
[C-1-4] PHẢI ngăn việc thêm thông tin sinh trắc học mới mà không thiết lập trước một chuỗi tin cậy bằng cách yêu cầu người dùng xác nhận thông tin xác thực thiết bị hiện có hoặc thêm thông tin xác thực thiết bị mới (mã PIN/hình mở khoá/mật khẩu) do TEE bảo mật; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện việc này.
[C-1-5] PHẢI xoá hoàn toàn tất cả dữ liệu sinh trắc học có thể nhận dạng của người dùng khi tài khoản của người dùng đó bị xoá (bao gồm cả việc đặt lại về trạng thái ban đầu).
[C-1-6] MUST honor the individual flag for that biometric (i.e.
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
, orDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).[C-1-7] PHẢI yêu cầu người dùng xác thực bằng phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất một lần trong vòng 24 giờ. Lưu ý: Khi nâng cấp các thiết bị chạy Android phiên bản 9 trở xuống, bạn PHẢI yêu cầu người dùng xác thực bằng phương thức xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất một lần trong vòng 72 giờ.
[C-1-8] PHẢI yêu cầu người dùng xác thực 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) hoặc thông tin sinh trắc học Lớp 3 (MẠNH) sau một trong những trường hợp sau:
- thời gian chờ khi không hoạt động là 4 giờ, HOẶC
- 3 lần xác thực bằng sinh trắc học không thành công.
- Thời gian chờ khi không hoạt động và số lần xác thực không thành công sẽ được đặt lại sau khi xác nhận thành công thông tin xác thực của thiết bị. Lưu ý: Các thiết bị nâng cấp được phát hành trên Android phiên bản 9 trở xuống CÓ THỂ được miễn C-1-8.
[C-SR-7] NÊN sử dụng logic trong khung do Dự án nguồn mở Android cung cấp để thực thi các quy tắc ràng buộc được chỉ định trong [C-1-7] và [C-1-8] cho các thiết bị mới.
[C-SR-8] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%, as measured on the device.
[C-SR-9] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from when the biometric is detected, until the screen is unlocked, for each enrolled biometric.
Bắt đầu yêu cầu mới
[C-1-12] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 40% theo từng loại công cụ tấn công bằng nội dung trình bày (PAI), được đo lường theo Giao thức kiểm thử sinh trắc học của Android.
[C-SR-13] Bạn NÊN có tỷ lệ chấp nhận giả mạo và giả mạo không cao hơn 30% cho mỗi loại công cụ tấn công bằng nội dung trình bày (PAI), được đo lường theo Giao thức kiểm thử sinh trắc học của Android.
[C-SR-14] Bạn NÊN công bố lớp sinh trắc học của cảm biến sinh trắc học và các rủi ro tương ứng khi bật cảm biến đó.
[C-SR-17] Bạn NÊN triển khai các giao diện AIDL mới (chẳng hạn như
IFace.aidl
vàIFingerprint.aidl
).
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 2 (trước đây là Yếu), thì các phương thức đó:
[C-2-1] PHẢI đáp ứng tất cả các yêu cầu đối với Lớp 1 ở trên.
[C-2-2] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 20%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 20% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp B không cao hơn 30%, theo đo lường của Nghị định về thử nghiệm sinh trắc học của Android.
Bắt đầu yêu cầu mới
- [C-SR-15] Bạn NÊN có tỷ lệ chấp nhận giả mạo và giả mạo không cao hơn 20% cho mỗi loại công cụ tấn công bằng bản trình bày (PAI), theo đo lường của Nghị định kiểm thử sinh trắc học của Android.
Kết thúc các yêu cầu mới
- [C-2-3] PHẢI thực hiện việc so khớp sinh trắc học trong một môi trường thực thi biệt lập bên ngoài không gian người dùng hoặc hạt nhân Android, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE),
hoặctrên một khối có kênh bảo mật đến môi trường thực thi biệt lập hoặc trên Máy ảo được bảo vệ đáp ứng các yêu cầu trong Mục 9.17. - [C-2-4] PHẢI mã hoá và xác thực bằng mật mã tất cả dữ liệu nhận dạng để không thể thu thập, đọc hoặc sửa đổi dữ liệu đó bên ngoài môi trường thực thi tách biệt hoặc một khối có kênh bảo mật đến môi trường thực thi tách biệt như được ghi nhận trong nguyên tắc triển khai trên trang web của Dự án nguồn mở Android hoặc một Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát đáp ứng các yêu cầu trong Mục 9.17.
- [C-2-5] Đối với dữ liệu sinh trắc học dựa trên máy ảnh, trong khi quá trình xác thực hoặc đăng ký dựa trên sinh trắc học đang diễn ra:
- PHẢI vận hành camera ở chế độ ngăn không cho đọc hoặc thay đổi khung hình camera bên ngoài môi trường thực thi tách biệt hoặc một khối có kênh bảo mật đến môi trường thực thi tách biệt hoặc một Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát đáp ứng các yêu cầu trong Mục 9.17.
- Đối với các giải pháp máy ảnh đơn RGB, bạn CÓ THỂ đọc được các khung hình máy ảnh bên ngoài môi trường thực thi riêng biệt để hỗ trợ các thao tác như xem trước để đăng ký, nhưng KHÔNG ĐƯỢC thay đổi.
- [C-2-6] KHÔNG ĐƯỢC cho phép ứng dụng bên thứ ba phân biệt giữa các lần đăng ký sinh trắc học riêng lẻ.
- [C-2-7] KHÔNG ĐƯỢC cho phép truy cập không mã hoá vào dữ liệu sinh trắc học có thể nhận dạng hoặc bất kỳ dữ liệu nào bắt nguồn từ dữ liệu đó (chẳng hạn như dữ liệu nhúng) cho Bộ xử lý ứng dụng bên ngoài ngữ cảnh của TEE hoặc Máy ảo được bảo vệ do trình điều khiển ảo hoá kiểm soát và đáp ứng các yêu cầu trong Mục 9.17. Các thiết bị nâng cấp được phát hành trên Android phiên bản 9 trở xuống không được miễn trừ khỏi C-2-7.
[C-2-8] PHẢI có quy trình xử lý bảo mật để hệ điều hành hoặc nhân hệ điều hành bị xâm phạm không thể chèn dữ liệu trực tiếp để xác thực sai là người dùng. Lưu ý: Nếu các phương thức triển khai thiết bị đã được ra mắt trên Android phiên bản 9 trở xuống và không thể đáp ứng yêu cầu C-2-8 thông qua bản cập nhật phần mềm hệ thống, thì các phương thức đó CÓ THỂ được miễn trừ yêu cầu này.
[C-SR-10] Bạn NÊN sử dụng tính năng phát hiện sống động cho tất cả các phương thức sinh trắc học và tính năng phát hiện sự chú ý cho sinh trắc học khuôn mặt.
[C-2-9] PHẢI cung cấp cảm biến sinh trắc học cho các ứng dụng bên thứ ba.
Nếu các phương thức triển khai thiết bị muốn coi cảm biến sinh trắc học là Lớp 3 (trước đây là Mạnh), thì các phương thức đó:
- [C-3-1] PHẢI đáp ứng tất cả các yêu cầu của Lớp 2 ở trên, ngoại trừ [C-1-7] và [C-1-8].
- [C-3-2] PHẢI triển khai kho khoá được hỗ trợ phần cứng.
- [C-3-3] PHẢI có tỷ lệ chấp nhận hành vi giả mạo và mạo danh không cao hơn 7%, trong đó (1) tỷ lệ chấp nhận hành vi giả mạo và mạo danh đối với các loại công cụ tấn công bằng bản trình bày (PAI) cấp A không cao hơn 7% và (2) tỷ lệ chấp nhận hành vi giả mạo và mạo danh của các loại PAI cấp B không cao hơn 20%, theo đo lường của Giao thức kiểm thử sinh trắc học của Android.
- [C-3-4] PHẢI yêu cầu người dùng xác thực chính được đề xuất (ví dụ: mã PIN, hình mở khoá, mật khẩu) ít nhất một lần trong vòng 72 giờ.
- [C-3-5] PHẢI tạo lại Mã nhận dạng trình xác thực cho tất cả các phương thức sinh trắc học Lớp 3 được hỗ trợ trên thiết bị nếu có phương thức nào đó được đăng ký lại.
- [C-3-6] Phải bật khoá kho khoá được hỗ trợ bằng sinh trắc học cho các ứng dụng bên thứ ba.
Bắt đầu yêu cầu mới
- [C-SR-16] Bạn NÊN có tỷ lệ chấp nhận giả mạo và người mạo danh không cao hơn 7% theo từng loại công cụ tấn công bằng hình ảnh (PAI), được đo lường theo Nghị định kiểm thử sinh trắc học của Android.
Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị chứa cảm biến vân tay dưới màn hình (UDFPS), thì các phương thức đó:
- [C-SR-11] Bạn NÊN ngăn khu vực có thể chạm của UDFPS can thiệp vào thao tác điều hướng bằng 3 nút (một số người dùng có thể yêu cầu thao tác này cho mục đích hỗ trợ tiếp cận).
7.3.11. Cảm biến tư thế
Device implementations:
- MAY support pose sensor with 6 degrees of freedom.
If device implementations support pose sensor with 6 degrees of freedom, they:
- [C-1-1] MUST implement and report
TYPE_POSE_6DOF
sensor. - [C-1-2] PHẢI chính xác hơn so với chỉ vectơ xoay.
7.3.12. Cảm biến góc bản lề
If device implementations support a hinge angle sensor, they:
- [C-1-1] MUST implement and report
TYPE_HINGLE_ANGLE
. - [C-1-2] PHẢI hỗ trợ ít nhất hai lần đọc trong khoảng từ 0 đến 360 độ (bao gồm cả 0 và 360 độ).
- [C-1-3] PHẢI trả về cảm biến đánh thức cho
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:
Bắt đầu yêu cầu mới
- [C-1-2] MUST report the hardware feature flag
android.hardware.uwb
. - [C-1-3] PHẢI hỗ trợ tất cả các nhóm cấu hình sau (các tổ hợp được xác định trước của tham số FIRA UCI) được xác định trong quá trình triển khai AOSP.
CONFIG_ID_1
: Đo khoảng cáchSTATIC STS DS-TWR
một địa chỉ do FiRa xác định, chế độ trì hoãn, khoảng thời gian đo khoảng cách 240 mili giây.CONFIG_ID_2
: Phạm viSTATIC STS DS-TWR
một với nhiều do FiRa xác định, chế độ trì hoãn, khoảng thời gian đo từ 200 mili giây. Trường hợp sử dụng thông thường: điện thoại thông minh tương tác với nhiều thiết bị thông minh.CONFIG_ID_3
: Tương tự nhưCONFIG_ID_1
, ngoại trừ dữ liệu Góc tới (AoA) không được báo cáo.CONFIG_ID_4
: Tương tự nhưCONFIG_ID_1
, ngoại trừ chế độ bảo mật P-STS được bật.CONFIG_ID_5
: Tương tự nhưCONFIG_ID_2
, ngoại trừ chế độ bảo mật P-STS được bật.CONFIG_ID_6
: Tương tự nhưCONFIG_ID_3
, ngoại trừ chế độ bảo mật P-STS được bật.CONFIG_ID_7
: Tương tự nhưCONFIG_ID_2
, ngoại trừ chế độ khoá điều khiển riêng lẻ P-STS được bật.
- [C-1-4] PHẢI cung cấp một chức năng cho phép người dùng bật/tắt trạng thái đài UWB.
- [C-1-5] PHẢI thực thi việc các ứng dụng sử dụng đài UWB phải có quyền
UWB_RANGING
(trong nhóm quyềnNEARBY_DEVICES
).
Việc vượt qua các bài kiểm thử chứng nhận và tuân thủ liên quan do các tổ chức tiêu chuẩn (bao gồm cả FIRA, CCC và CSA) xác định giúp đảm bảo 802.1.15.4 hoạt động chính xác.
Kết thúc các yêu cầu mới
7.4. Khả năng kết nối dữ liệu
7.4.1. Điện thoại
“Telephony” as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages , or establishing mobile data via a mobile (e.g. GSM, CDMA, LTE, NR)GSM or CDMA network. Một thiết bị hỗ trợ "Điện thoại" có thể chọn cung cấp một số hoặc tất cả các dịch vụ gọi, nhắn tin và dữ liệu phù hợp với sản phẩm.
thông qua mạng GSM hoặc CDMA. Mặc dù các cuộc gọi thoại này có thể được chuyển đổi gói hoặc không, nhưng đối với Android, các cuộc gọi này được coi là độc lập với mọi kết nối dữ liệu có thể được triển khai bằng cùng một mạng. Nói cách khác,chức năng và API "thoại" của Android đề cập cụ thể đến cuộc gọi thoại và SMS. Ví dụ: các phương thức triển khai thiết bị không thể thực hiện cuộc gọi hoặc gửi/nhận tin nhắn SMS không được coi là thiết bị điện thoại, bất kể thiết bị có sử dụng mạng di động để kết nối dữ liệu hay không.
- Android MAY be used on devices that do not include telephony hardware. Nghĩa là Android tương thích với các thiết bị không phải điện thoại.
If device implementations include GSM or CDMA telephony, they:
- [C-1-1] MUST declare the
android.hardware.telephony
feature flag and other sub-feature flags according to the technology. - [C-1-2] PHẢI triển khai đầy đủ tính năng hỗ trợ cho API của công nghệ đó.
- NÊN cho phép tất cả các loại dịch vụ di động hiện có (2G, 3G, 4G, 5G, v.v.) trong cuộc gọi khẩn cấp (bất kể loại mạng do
SetAllowedNetworkTypeBitmap()
đặt).
If device implementations do not include telephony hardware, they:
- [C-2-1] MUST implement the full APIs as no-ops.
Nếu các phương thức triển khai thiết bị hỗ trợ eUICC hoặc eSIM/SIM nhúng và bao gồm một cơ chế độc quyền để cung cấp chức năng eSIM cho các nhà phát triển bên thứ ba, thì các phương thức đó:
- [C-3-1] PHẢI khai báo cờ tính năng
android.hardware.telephony.euicc
.
Nếu các phương thức triển khai thiết bị không đặt thuộc tính hệ thống ro.telephony.iwlan\_operation\_mode
thành "cũ", thì các phương thức đó:
- [C-4-1] KHÔNG ĐƯỢC báo cáo "NETWORK_TYPE_IWLAN" thông qua NetworkRegistrationInfo#getAccessNetworkTechnology() khi NetworkRegistrationInfo#getTransportType() được báo cáo là "TRANSPORT_TYPE_WWAN" cho cùng một thực thể NetworkRegistrationInfo.
Nếu việc triển khai thiết bị hỗ trợ một lượt đăng ký Hệ thống con đa phương tiện qua IP (IMS) cho cả tính năng dịch vụ điện thoại đa phương tiện (MMTEL) và dịch vụ giao tiếp đa dạng (RCS) và dự kiến tuân thủ các yêu cầu của nhà mạng di động về việc sử dụng một lượt đăng ký IMS cho tất cả lưu lượng tín hiệu IMS, thì các thiết bị đó:
- [C-5-1] PHẢI khai báo cờ tính năng
android.hardware.telephony.ims
và cung cấp cách triển khai đầy đủ API ImsService cho cả MMTEL và API trao đổi chức năng của người dùng RCS. - [C-5-2] BẮT BUỘC phải khai báo cờ tính năng
android.hardware.telephony.ims.singlereg
và cung cấp cách triển khai đầy đủ API SipTransport, API GbaService, chỉ báo chuyên dụng của phương thức truyền tải bằng cách sử dụng IRadio 1.6 HAL và cấp phép qua Máy chủ cấu hình tự động (ACS) hoặc cơ chế cấp phép độc quyền khác bằng cách sử dụng API Cấu hình IMS.
Nếu các phương thức triển khai thiết bị báo cáo tính năng android.hardware.telephony
, thì:
- [C-6-1]
SmsManager#sendTextMessage
vàSmsManager#sendMultipartTextMessage
PHẢI dẫn đến các lệnh gọi tương ứng đếnCarrierMessagingService
để cung cấp chức năng nhắn tin văn bản.SmsManager#sendMultimediaMessage
vàSmsManager#downloadMultimediaMessage
PHẢI dẫn đến các lệnh gọi tương ứng đếnCarrierMessagingService
để cung cấp chức năng nhắn tin đa phương tiện. - [C-6-2] Ứng dụng do
android.provider.Telephony.Sms#getDefaultSmsPackage
chỉ định PHẢI sử dụng các API SmsManager khi gửi và nhận tin nhắn SMS và MMS. Việc triển khai tài liệu tham khảo AOSP trong các gói/ứng dụng/Messaging đáp ứng yêu cầu này. - [C-6-3] Ứng dụng phản hồi
Intent#ACTION_DIAL
PHẢI hỗ trợ nhập mã quay số tuỳ ý được định dạng là*#*#CODE#*#*
và kích hoạt thông báo truyền tinTelephonyManager#ACTION_SECRET_CODE
tương ứng. - [C-6-4] Ứng dụng phản hồi
Intent#ACTION_DIAL
PHẢI sử dụngVoicemailContract.Voicemails#TRANSCRIPTION
để hiển thị bản chép lời thư thoại kèm theo hình ảnh cho người dùng nếu ứng dụng đó hỗ trợ bản chép lời thư thoại kèm theo hình ảnh. - [C-6-5] PHẢI biểu thị tất cả SubscriptionInfo bằng UUID nhóm tương đương dưới dạng một gói thuê bao duy nhất trong tất cả các tính năng hiển thị cho người dùng, cho thấy và kiểm soát thông tin thẻ SIM. Ví dụ về các đặc điểm hữu dụng như vậy bao gồm giao diện cài đặt khớp với
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
hoặcEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] KHÔNG ĐƯỢC hiển thị hoặc cho phép kiểm soát bất kỳ SubscriptionInfo nào có UUID nhóm khác rỗng và bit cơ hội trong bất kỳ chức năng nào mà người dùng nhìn thấy cho phép định cấu hình hoặc kiểm soát các chế độ cài đặt thẻ SIM.
Nếu các phương thức triển khai thiết bị báo cáo tính năng android.hardware.telephony
và cung cấp thanh trạng thái hệ thống, thì:
- [C-7-1] PHẢI chọn một gói thuê bao đang hoạt động đại diện cho một UUID nhóm nhất định để hiển thị cho người dùng trong mọi chức năng cung cấp thông tin về trạng thái SIM. Ví dụ về các tính năng hỗ trợ đó bao gồm biểu tượng tín hiệu di động trên thanh trạng thái hoặc thẻ cài đặt nhanh.
- [C-SR-1] Bạn NÊN chọn gói thuê bao đại diện là gói thuê bao dữ liệu đang hoạt động, trừ phi thiết bị đang thực hiện cuộc gọi thoại, trong trường hợp này, bạn NÊN chọn gói thuê bao đại diện là gói thuê bao thoại đang hoạt động.
Nếu các phương thức triển khai thiết bị báo cáo tính năng android.hardware.telephony
, thì:
- [C-6-7] PHẢI có khả năng mở và đồng thời sử dụng số lượng kênh logic tối đa (tổng cộng 20) cho mỗi UICC theo ETSI TS 102 221.
- [C-6-8] KHÔNG ĐƯỢC tự động áp dụng bất kỳ hành vi nào sau đây cho các ứng dụng của nhà mạng đang hoạt động (do
TelephonyManager#getCarrierServicePackageName
chỉ định) hoặc áp dụng mà không có sự xác nhận rõ ràng của người dùng:- Thu hồi hoặc giới hạn quyền truy cập mạng
- Thu hồi quyền
- Hạn chế việc thực thi ứng dụng ở chế độ nền hoặc nền trước ngoài các tính năng quản lý nguồn hiện có trong AOSP
- Tắt hoặc gỡ cài đặt ứng dụng
Nếu các phương thức triển khai thiết bị báo cáo tính năng android.hardware.telephony
và tất cả các gói thuê bao không cơ hội đang hoạt động và dùng chung một UUID nhóm bị tắt, bị xoá khỏi thiết bị hoặc được đánh dấu là cơ hội, thì thiết bị đó:
- [C-8-1] PHẢI tự động tắt tất cả các gói thuê bao tiện lợi còn lại đang hoạt động trong cùng một nhóm.
If device implementations include GSM telephony but not CDMA telephony, they:
- [C-9-1] KHÔNG ĐƯỢC khai báo
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] PHẢI gửi một
IllegalArgumentException
khi cố gắng đặt bất kỳ loại mạng 3GPP2 nào trong mặt nạ bit loại mạng ưu tiên hoặc được cho phép. - [C-9-3] PHẢI trả về một chuỗi trống từ
TelephonyManager#getMeid
.
Nếu các phương thức triển khai thiết bị hỗ trợ eUICC có nhiều cổng và hồ sơ, thì các phương thức đó:
- [C-10-1] PHẢI khai báo cờ tính năng
android.hardware.telephony.euicc.mep
.
7.4.1.1. Khả năng tương thích với tính năng Chặn số
If device implementations report the android.hardware.telephony.calling
feature, they:
- [C-1-1] MUST include number blocking support
- [C-1-2] PHẢI triển khai đầy đủ
BlockedNumberContract
và API tương ứng như mô tả trong tài liệu SDK. [C-1-3] PHẢI chặn tất cả cuộc gọi và tin nhắn từ một số điện thoại trong "BlockedNumberProvider" mà không có bất kỳ hoạt động tương tác nào với ứng dụng. Trường hợp ngoại lệ duy nhất là khi việc chặn số tạm thời được gỡ bỏ như mô tả trong tài liệu SDK.
[C-1-4] PHẢI ghi vào nhà cung cấp nhật ký cuộc gọi của nền tảng cho cuộc gọi bị chặn và PHẢI lọc các cuộc gọi có
BLOCKED_TYPE
ra khỏi chế độ xem nhật ký cuộc gọi mặc định trong ứng dụng quay số được cài đặt sẵn.[C-1-5] MUST NOT write to the Telephony provider for a blocked message.
[C-1-6] PHẢI triển khai giao diện người dùng quản lý số điện thoại bị chặn. Giao diện này được mở bằng ý định do phương thức
TelecomManager.createManageBlockedNumbersIntent()
trả về.[C-1-7] KHÔNG ĐƯỢC cho phép người dùng phụ xem hoặc chỉnh sửa số điện thoại bị chặn trên thiết bị vì nền tảng Android giả định rằng người dùng chính có toàn quyền kiểm soát các dịch vụ điện thoại, một phiên bản duy nhất trên thiết bị. Tất cả giao diện người dùng liên quan đến việc chặn PHẢI được ẩn đối với người dùng phụ và danh sách chặn PHẢI được tuân thủ.
SHOULD migrate the blocked numbers into the provider when a device updates to Android 7.0.
NÊN cung cấp cho người dùng khả năng hiển thị các cuộc gọi bị chặn trong ứng dụng quay số được cài đặt sẵn.
7.4.1.2. Telecom API
If device implementations report android.hardware.telephony.calling
, they:
- [C-1-1] PHẢI hỗ trợ các API
ConnectionService
được mô tả trong SDK. - [C-1-2] PHẢI hiển thị cuộc gọi đến mới và cung cấp cho người dùng khả năng chấp nhận hoặc từ chối cuộc gọi đến khi người dùng đang thực hiện cuộc gọi do một ứng dụng bên thứ ba thực hiện và ứng dụng đó không hỗ trợ tính năng giữ cuộc gọi được chỉ định thông qua
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] PHẢI có một ứng dụng triển khai InCallService.
[C-SR-1] Bạn NÊN thông báo cho người dùng rằng việc trả lời cuộc gọi đến sẽ làm gián đoạn cuộc gọi đang diễn ra.
Việc triển khai AOSP đáp ứng các yêu cầu này bằng một thông báo quan trọng cho người dùng biết rằng việc trả lời cuộc gọi đến sẽ khiến cuộc gọi khác bị ngắt.
[C-SR-2] Are STRONGLY RECOMMENDED to preload the default dialer app that shows a call log entry and the name of a third-party app in its call log when the third-party app sets the
EXTRA_LOG_SELF_MANAGED_CALLS
extras key on itsPhoneAccount
totrue
.[C-SR-3] Bạn NÊN xử lý các sự kiện
KEYCODE_MEDIA_PLAY_PAUSE
vàKEYCODE_HEADSETHOOK
của tai nghe âm thanh cho các APIandroid.telecom
như sau:- Call
Connection.onDisconnect()
when a short press of the key event is detected during an ongoing call. - Call
Connection.onAnswer()
when a short press of the key event is detected during an incoming call. - Call
Connection.onReject()
when a long press of the key event is detected during an incoming call. - Bật/tắt trạng thái tắt tiếng của
CallAudioState
.
- Call
7.4.1.3. Chuyển tải tính năng duy trì hoạt động NAT-T trên mạng di động
Device implementations:
- SHOULD include support for Cellular keepalive offload.
If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:
- [C-1-1] PHẢI hỗ trợ API SocketKeepAlive.
- [C-1-2] PHẢI hỗ trợ ít nhất một khe keepalive đồng thời qua mạng di động.
- [C-1-3] PHẢI hỗ trợ nhiều khe giữ kết nối đồng thời qua mạng di động như được hỗ trợ bởi HAL của đài phát thanh di động.
- [C-SR-1] Bạn NÊN hỗ trợ ít nhất 3 khe giữ kết nối di động cho mỗi phiên bản radio.
If device implementations do not include support for cellular keepalive offload, they:
- [C-2-1] PHẢI trả về ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Device implementations:
- SHOULD include support for one or more forms of 802.11.
If device implementations include support for 802.11 and expose the functionality to a third-party application, they:
- [C-1-1] PHẢI triển khai API Android tương ứng.
- [C-1-2] MUST report the hardware feature flag
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 địa chỉ (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251 hoặc ff02::fb) bất cứ lúc nào hoạt động, bao gồm cả khi màn hình không ở trạng thái hoạt động, trừ phi việc loại bỏ hoặc lọc các gói này là cần thiết để duy trì trong phạm vi tiêu thụ điện năng theo yêu cầu của quy định áp dụng cho thị trường mục tiêu.
Đố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 điện 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 đổiNetwork
đang hoạt động được sử dụng theo mặc định cho lưu lượng truy cập ứng dụng và được các phương thức APIConnectivityManager
trả về, chẳng hạn nhưgetActiveNetwork
vàregisterDefaultNetworkCallback
. Nói cách khác, họ CHỈ CÓ THỂ tắt quyền truy cập Internet do bất kỳ nhà cung cấp mạng nào khác (ví dụ: dữ liệu di động) cung cấp 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] Bạn NÊN, khi phương thức API
ConnectivityManager.reportNetworkConnectivity()
được gọi, hãy đánh giá lại quyền truy cập Internet trênNetwork
và sau khi đánh giá xác định rằngNetwork
hiện tại không còn cung cấp quyền truy cập Internet, hãy chuyển sang bất kỳ mạng nào khác có sẵn (ví dụ: dữ liệu di động) cung cấp quyền truy cập Internet. - [C-1-7] PHẢI tạo ngẫu nhiên địa chỉ MAC nguồn và số thứ tự của các khung yêu cầu thăm dò, một lần ở đầu mỗi lần quét, trong khi STA bị ngắt kết nối.
- [C-1-8] PHẢI sử dụng một địa chỉ MAC nhất quán (KHÔNG ĐƯỢC tạo địa chỉ MAC ngẫu nhiên giữa chừng trong quá trình quét).
- [C-1-9] PHẢI lặp lại số thứ tự yêu cầu thăm dò như bình thường (tuần tự) giữa các yêu cầu thăm dò trong một lần quét.
- [C-1-10] PHẢI tạo số thứ tự yêu cầu thăm dò ngẫu nhiên giữa yêu cầu thăm dò cuối cùng của một lần quét và yêu cầu thăm dò đầu tiên của lần quét tiếp theo.
- [C-SR-1] Bạn NÊN tạo địa chỉ MAC nguồn ngẫu nhiên dùng cho mọi hoạt động giao tiếp của STA với một Điểm truy cập (AP) trong khi liên kết và liên kết.
- Thiết bị PHẢI sử dụng một địa chỉ MAC ngẫu nhiên khác nhau cho mỗi SSID (FQDN cho Passpoint) mà thiết bị giao tiếp.
- Thiết bị PHẢI cung cấp cho người dùng một tuỳ chọn để kiểm soát việc tạo ngẫu nhiên cho mỗi SSID (FQDN cho Passpoint) bằng các tuỳ chọn tạo ngẫu nhiên và không tạo ngẫu nhiên, đồng thời PHẢI đặt chế độ mặc định để các cấu hình Wi-Fi mới được tạo ngẫu nhiên.
- [C-SR-2] Bạn NÊN sử dụng BSSID ngẫu nhiên cho mọi AP mà bạn tạo.
- Địa chỉ MAC PHẢI được tạo ngẫu nhiên và duy trì cho mỗi SSID mà AP sử dụng.
- THIẾT BỊ CÓ THỂ cung cấp cho người dùng lựa chọn tắt tính năng này. Nếu cung cấp tuỳ chọn như vậy, bạn PHẢI bật tính năng ngẫu nhiên theo mặc định.
Nếu các phương thức triển khai thiết bị hỗ trợ chế độ tiết kiệm pin Wi-Fi như được xác định trong tiêu chuẩn IEEE 802.11, thì các phương thức đó:
- NÊN tắt chế độ tiết kiệm pin Wi-Fi bất cứ khi nào một ứng dụng mua khoá
WIFI_MODE_FULL_HIGH_PERF
hoặc khoáWIFI_MODE_FULL_LOW_LATENCY
thông qua APIWifiManager.createWifiLock()
vàWifiManager.WifiLock.acquire()
và khoá đang hoạt động. - [C-3-2] Độ trễ trung bình của một vòng kết nối giữa thiết bị và điểm truy cập khi thiết bị ở chế độ Khoá Wi-Fi có độ trễ thấp (
WIFI_MODE_FULL_LOW_LATENCY
) PHẢI nhỏ hơn độ trễ trong chế độ Khoá Wi-Fi có hiệu suất cao (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] Bạn NÊN giảm thiểu độ trễ trọn vòng Wi-Fi
bất cứ khi nào Khoá độ trễ thấp (
WIFI_MODE_FULL_LOW_LATENCY
) được thu nạp và có hiệu lực.
If device implementations support Wi-Fi and use Wi-Fi for location scanning, they:
- [C-2-1] MUST provide a user affordance to enable/disable the value read
thông qua phương thức API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi Direct
Device implementations:
- SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer).
If device implementations include support for Wi-Fi Direct, they:
- [C-1-1] PHẢI triển khai API Android tương ứng như mô tả trong tài liệu SDK.
- [C-1-2] MUST report the hardware feature
android.hardware.wifi.direct
. - [C-1-3] MUST support regular Wi-Fi operation.
- [C-1-4] MUST support Wi-Fi and Wi-Fi Direct operations concurrently.
- [C-SR-1] Bạn NÊN tạo địa chỉ MAC nguồn ngẫu nhiên cho tất cả các kết nối Wi-Fi Direct mới tạo.
7.4.2.2. Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi
Device implementations:
- SHOULD include support for Wi-Fi Tunneled Direct Link Setup (TDLS) as described in the Android SDK Documentation.
If device implementations include support for TDLS and TDLS is enabled by the WiFiManager API, they:
- [C-1-1] PHẢI khai báo hỗ trợ TDLS thông qua
WifiManager.isTdlsSupported
. - SHOULD use TDLS only when it is possible AND beneficial.
- SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point.
7.4.2.3. Wi-Fi Aware
Device implementations:
- SHOULD include support for Wi-Fi Aware.
If device implementations include support for Wi-Fi Aware and expose the functionality to third-party apps, then they:
- [C-1-1] PHẢI triển khai các API
WifiAwareManager
như mô tả trong tài liệu SDK. - [C-1-2] MUST declare the
android.hardware.wifi.aware
feature flag. - [C-1-3] MUST support Wi-Fi and Wi-Fi Aware operations concurrently.
- [C-1-4] PHẢI tạo địa chỉ giao diện quản lý Wi-Fi Aware ngẫu nhiên theo khoảng thời gian không quá 30 phút và bất cứ khi nào Wi-Fi Aware được bật, trừ phi một thao tác đo khoảng cách Aware đang diễn ra hoặc một đường dẫn dữ liệu Aware đang hoạt động (không dự kiến tạo ngẫu nhiên trong khi đường dẫn dữ liệu đang hoạt động).
If device implementations include support for Wi-Fi Aware and Wi-Fi Location as described in Section 7.4.2.5 and exposes these functionalities to third-party apps, then they:
- [C-2-1] MUST implement the location-aware discovery APIs: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , and onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
If device implementations include support for 802.11 (Wi-Fi) they:
- [C-1-1] MUST include support for Wi-Fi Passpoint.
- [C-1-2] PHẢI triển khai các API
WifiManager
liên quan đến Passpoint như mô tả trong tài liệu SDK. - [C-1-3] MUST support IEEE 802.11u standard, specifically related to Network Discovery and Selection, such as Generic Advertisement Service (GAS) and Access Network Query Protocol (ANQP).
- [C-1-4] MUST declare
android.hardware.wifi.passpoint
feature flag. - [C-1-5] PHẢI tuân theo cách triển khai AOSP để khám phá, so khớp và liên kết với các mạng Passpoint.
- [C-1-6] PHẢI hỗ trợ ít nhất một số giao thức cấp phép thiết bị sau đây như được xác định trong Wi-Fi Alliance Passpoint R2: xác thực EAP-TTLS và SOAP-XML.
- [C-1-7] PHẢI xử lý chứng chỉ máy chủ AAA như mô tả trong quy cách Hotspot 2.0 R3.
- [C-1-8] PHẢI hỗ trợ người dùng kiểm soát việc cấp phép thông qua bộ chọn Wi-Fi.
- [C-1-9] PHẢI duy trì cấu hình Passpoint sau khi khởi động lại.
- [C-SR-1] Bạn NÊN hỗ trợ tính năng chấp nhận điều khoản và điều kiện.
- [C-SR-2] Are STRONGLY RECOMMENDED to support the Venue information feature.
Nếu bạn cung cấp nút chuyển chế độ kiểm soát của người dùng để tắt Passpoint trên toàn cầu, hãy triển khai:
- [C-3-1] PHẢI bật Passpoint theo mặc định.
7.4.2.5. Wi-Fi Location (Wi-Fi Round Trip Time – RTT)
Device implementations:
- SHOULD include support for Wi-Fi Location.
If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:
- [C-1-1] PHẢI triển khai các API
WifiRttManager
như mô tả trong tài liệu SDK. - [C-1-2] MUST declare the
android.hardware.wifi.rtt
feature flag. - [C-1-3] PHẢI tạo địa chỉ MAC nguồn ngẫu nhiên cho mỗi luồng RTT được thực thi trong khi giao diện Wi-Fi mà RTT đang được thực thi không liên kết với một Điểm truy cập.
- [C-1-4] PHẢI chính xác trong vòng 2 mét ở băng thông 80 MHz tại phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ).
- [C-SR-1] Bạn NÊN báo cáo chính xác phạm vi này trong vòng 1,5 mét ở băng thông 80 MHz tại phân vị thứ 68 (như được tính bằng Hàm phân phối tích luỹ).
7.4.2.6. Chuyển Wi-Fi Keepalive sang chế độ tải xuống
Device implementations:
- SHOULD include support for Wi-Fi keepalive offload.
If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:
- [C-1-1] PHẢI hỗ trợ API SocketKeepAlive.
- [C-1-2] PHẢI hỗ trợ ít nhất 3 khe keepalive đồng thời qua Wi-Fi
Nếu các phương thức triển khai thiết bị không hỗ trợ tính năng giảm tải Wi-Fi keepalive, thì các phương thức đó:
- [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ị)
Device implementations:
- SHOULD include support for Wi-Fi Easy Connect (DPP).
If device implementations include support for Wi-Fi Easy Connect and expose the functionality to third-party apps, they:
- [C-1-1] PHẢI có phương thức WifiManager#isEasyConnectSupported() trả về
true
.
7.4.2.8. Xác thực chứng chỉ máy chủ Wi-Fi doanh nghiệp
Nếu chứng chỉ máy chủ Wi-Fi không được xác thực hoặc tên miền của máy chủ Wi-Fi không được đặt, thì việc triển khai thiết bị sẽ:
- [C-SR-1] Bạn KHÔNG NÊN cung cấp cho người dùng tuỳ chọn thêm Mạng Wi-Fi doanh nghiệp theo cách thủ công trong ứng dụng Cài đặt.
7.4.2.9. Tin cậy vào lần sử dụng đầu tiên (TOFU)
Nếu các phương thức triển khai thiết bị hỗ trợ tính năng Tin cậy khi sử dụng lần đầu (TOFU) và cho phép người dùng xác định cấu hình WPA/WPA2/WPA3-Enterprise, thì các phương thức đó:
- [C-4-1] PHẢI cung cấp cho người dùng lựa chọn sử dụng TOFU.
7.4.3. Bluetooth
If device implementations support Bluetooth Audio profile, they:
- SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (e.g. LDAC)
If device implementations support HFP, A2DP and AVRCP, they:
- SHOULD support at least 5 total connected devices.
If device implementations declare android.hardware.vr.high_performance
feature, they:
- [C-1-1] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension.
Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp.
If device implementations include support for Bluetooth and Bluetooth Low Energy, they:
- [C-2-1] PHẢI khai báo các tính năng nền tảng có liên quan (
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 hồ sơ Bluetooth có liên quan như A2DP, AVRCP, OBEX, HFP, v.v. sao cho phù hợp với thiết bị.
If device implementations include support for Bluetooth Low Energy (BLE), they:
- [C-3-1] MUST declare the hardware feature
android.hardware.bluetooth_le
. - [C-3-2] PHẢI bật các API Bluetooth dựa trên GATT (hồ sơ thuộc tính chung) như mô tả trong tài liệu SDK và android.bluetooth.
- [C-3-3] MUST report the correct value for
BluetoothAdapter.isOffloadedFilteringSupported()
to indicate whether the filtering logic for the ScanFilter API classes is implemented. - [C-3-4] PHẢI báo cáo giá trị chính xác cho
BluetoothAdapter.isMultipleAdvertisementSupported()
để cho biết liệu có hỗ trợ tính năng Quảng cáo tiết kiệm năng lượng hay không. [C-3-5] PHẢI triển khai thời gian chờ cho Địa chỉ riêng có thể phân giải (RPA) không quá 15 phút và xoay vòng địa chỉ tại thời điểm hết thời gian chờ để bảo vệ quyền riêng tư của người dùng khi thiết bị đang chủ động sử dụng BLE để quét hoặc quảng cáo. Để ngăn chặn các cuộc tấn công theo thời gian, khoảng thời gian chờ cũng PHẢI được tạo ngẫu nhiên trong khoảng từ 5 đến 15 phút.
SHOULD support offloading of the filtering logic to the bluetooth chipset when implementing the ScanFilter API.
SHOULD support offloading of the batched scanning to the bluetooth chipset.
SHOULD support multi advertisement with at least 4 slots.
If device implementations support Bluetooth LE and use Bluetooth LE for location scanning, they:
- [C-4-1] MUST provide a user affordance to enable/disable the value read
thông qua API hệ thống
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Nếu việc triển khai thiết bị bao gồm hỗ trợ Bluetooth LE và Hồ sơ thiết bị trợ thính, như mô tả trong phần Hỗ trợ âm thanh của thiết bị trợ thính bằng Bluetooth LE, thì thiết bị đó:
- [C-5-1] PHẢI trả về
true
cho BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
Nếu các phương thức triển khai thiết bị hỗ trợ Bluetooth hoặc Bluetooth Low Energy, thì:
- [C-6-1] PHẢI hạn chế quyền truy cập vào mọi siêu dữ liệu Bluetooth (chẳng hạn như kết quả quét) có thể dùng để xác định vị trí của thiết bị, trừ phi ứng dụng yêu cầu đã vượt qua thành công quy trình kiểm tra quyền
android.permission.ACCESS_FINE_LOCATION
dựa trên trạng thái nền trước/nền hiện tại của ứng dụng.
Nếu các phương thức triển khai thiết bị hỗ trợ Bluetooth hoặc Bluetooth Low Energy và tệp kê khai ứng dụng không có nội dung khai báo của nhà phát triển cho biết rằng họ không lấy thông tin vị trí từ Bluetooth, thì:
- [C-6-2] PHẢI kiểm soát quyền truy cập Bluetooth thông qua
android.permission.ACCESS_FINE_LOCATION
.
Nếu các phương thức triển khai thiết bị trả về true
cho API BluetoothAdapter.isLeAudioSupported()
, thì các phương thức đó:
- [C-7-1] PHẢI hỗ trợ ứng dụng unicast.
- [C-7-2] PHẢI hỗ trợ PHY 2M.
- [C-7-3] PHẢI hỗ trợ tính năng Quảng cáo mở rộng LE.
- [C-7-4] PHẢI hỗ trợ ít nhất 2 kết nối CIS trong một CIG.
- [C-7-5] PHẢI bật đồng thời ứng dụng truyền tin một địa chỉ BAP, bộ điều phối nhóm CSIP, máy chủ MCP, trình điều khiển VCP, máy chủ CCP.
- [C-SR-1] Bạn NÊN bật ứng dụng unicast HAP.
Nếu các phương thức triển khai thiết bị trả về true
cho API BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, thì các phương thức đó:
- [C-8-1] PHẢI hỗ trợ ít nhất 2 đường liên kết BIS trong một BIG.
- [C-8-2] PHẢI bật nguồn phát sóng BAP, trợ lý phát sóng BAP đồng thời.
- [C-8-3] PHẢI hỗ trợ tính năng Quảng cáo định kỳ LE.
Nếu các phương thức triển khai thiết bị trả về true
cho API BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, thì các phương thức đó:
- [C-9-1] PHẢI hỗ trợ PAST (Chuyển đồng bộ hoá quảng cáo định kỳ).
- [C-9-2] PHẢI hỗ trợ tính năng Quảng cáo định kỳ LE.
If device implementations declare FEATURE_BLUETOOTH_LE
, they:
- [C-10-1] PHẢI có kết quả đo RSSI nằm trong khoảng +/-9dB đối với 95% số lần đo ở khoảng cách 1m từ thiết bị tham chiếu truyền ở
ADVERTISE_TX_POWER_HIGH
trong môi trường có tầm nhìn trực tiếp. [C-10-2] PHẢI bao gồm các phép sửa lỗi Rx/Tx để giảm độ lệch trên mỗi kênh để các phép đo trên mỗi trong số 3 kênh, trên mỗi ăng-ten (nếu sử dụng nhiều ăng-ten) nằm trong phạm vi +/-3dB so với nhau đối với 95% số phép đo.
[C-SR-2] Bạn NÊN đo lường và bù cho độ lệch Rx để đảm bảo RSSI BLE trung bình là -60dBm +/-10 dB ở khoảng cách 1m từ thiết bị tham chiếu truyền ở
ADVERTISE_TX_POWER_HIGH
, trong đó các thiết bị được định hướng sao cho chúng nằm trên "các mặt phẳng song song" với màn hình hướng về cùng một hướng.[C-SR-3] Bạn NÊN đo lường và bù cho độ lệch Tx để đảm bảo RSSI BLE trung bình là -60dBm +/-10 dB khi quét từ một thiết bị tham chiếu ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH
, trong đó các thiết bị được định hướng sao cho chúng nằm trên "các mặt phẳng song song" với màn hình hướng về cùng một hướng.Chuyển các yêu cầu [C-10-3] và [C-10-4] sang 2.2.1. Phần cứng.
- [C-10-3] PHẢI đo lường và bù cho độ lệch Rx để đảm bảo RSSI BLE trung bình là -55dBm +/-10 dB ở khoảng cách 1m từ thiết bị tham chiếu truyền ở
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] PHẢI đo lường và bù trừ độ lệch Tx để đảm bảo RSSI BLE trung bình là -55dBm +/-10 dB khi quét từ một thiết bị tham chiếu ở khoảng cách 1m và truyền ở
ADVERTISE_TX_POWER_HIGH
.
Bạn NÊN làm theo các bước thiết lập tính năng đo lường được chỉ định trong phần Yêu cầu về việc hiệu chuẩn sự hiện diện.
Nếu các phương thức triển khai thiết bị hỗ trợ Bluetooth phiên bản 5.0, thì các phương thức đó:
- [C-SR-4] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- PHY bộ mã hoá và giải mã LE
- Phần mở rộng quảng cáo LE
- Quảng cáo định kỳ
- Ít nhất 10 nhóm quảng cáo
- Ít nhất 8 kết nối đồng thời LE. Mỗi kết nối có thể ở một trong hai vai trò liên kết cấu trúc liên kết.
- Quyền riêng tư của lớp liên kết LE
- Kích thước "danh sách phân giải" tối thiểu là 8 mục
7.4.4. Giao tiếp trường gần
Device implementations:
- SHOULD include a transceiver and related hardware for Near-Field Communications (NFC).
- [C-0-1] PHẢI triển khai API
android.nfc.NdefMessage
vàandroid.nfc.NdefRecord
ngay cả khi các API này không hỗ trợ NFC hoặc khai báo tính năngandroid.hardware.nfc
vì các lớp này đại diện cho một định dạng trình bày dữ liệu độc lập với giao thức.
If device implementations include NFC hardware and plan to make it available to third-party apps, they:
- [C-1-1] MUST report the
android.hardware.nfc
feature from theandroid.content.pm.PackageManager.hasSystemFeature()
method. - MUST be capable of reading and writing NDEF messages via the following NFC standards as below:
- [C-1-2] MUST be capable of acting as an NFC Forum reader/writer
(as defined by the NFC Forum technical specification
NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC Forum Tag Types 1, 2, 3, 4, 5 (defined by the NFC Forum)
[C-SR-1] STRONGLY RECOMMENDED to be capable of reading and writing NDEF messages as well as raw data via the following NFC standards. Lưu ý rằng mặc dù các tiêu chuẩn NFC được nêu là NÊN, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai sẽ thay đổi các tiêu chuẩn này thành PHẢI. Các tiêu chuẩn này không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị hiện có và mới chạy phiên bản Android này nên đáp ứng các yêu cầu này ngay từ bây giờ để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
[C-1-13] PHẢI thăm dò tất cả công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.
SHOULD be capable of reading the barcode and URL (if encoded) of Thinfilm NFC Barcode products.
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 JIS, ISO và NFC Forum nêu trên.
Android có hỗ trợ chế độ Giả lập thẻ dựa trên máy chủ (HCE) NFC.
If device implementations include an NFC controller chipset capable of HCE (for NfcA and/or NfcB) and support Application ID (AID) routing, they:
- [C-2-1] PHẢI báo cáo hằng số tính năng
android.hardware.nfc.hce
. - [C-2-2] PHẢI hỗ trợ NFC HCE API như được định nghĩa trong SDK Android.
If device implementations include an NFC controller chipset capable of HCE for NfcF, and implement the feature for third-party applications, they:
- [C-3-1] PHẢI báo cáo hằng số tính năng
android.hardware.nfc.hcef
. - [C-3-2] MUST implement the NfcF Card Emulation APIs as defined in the Android SDK.
If device implementations include general NFC support as described in this section and support MIFARE technologies (MIFARE Classic, MIFARE Ultralight, NDEF on MIFARE Classic) in the reader/writer role, they:
- [C-4-1] MUST implement the corresponding Android API as documented by the Android SDK.
- [C-4-2] MUST report the feature
com.nxp.mifare
from theandroid.content.pm.PackageManager.hasSystemFeature
() method. Lưu ý rằng đây không phải là tính năng Android tiêu chuẩn và do đó không xuất hiện dưới dạng hằng số trong lớpandroid.content.pm.PackageManager
.
7.4.5. Giao thức và API mạng
7.4.5.1. Khả năng mạng tối thiểu
Device implementations:
- [C-0-1] MUST include support for one or more forms of data networking. Cụ thể, việc triển khai thiết bị PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu có tốc độ 200 Kbit/giây trở lên. Ví dụ về các công nghệ đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet và Bluetooth PAN.
- SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi), when a physical networking standard (such as Ethernet) is the primary data connection.
- MAY implement more than one form of data connectivity.
7.4.5.2. IPv6
Device implementations:
- [C-0-2] MUST include an IPv6 networking stack and support IPv6
communication using the managed APIs, such as
java.net.Socket
andjava.net.URLConnection
, as well as the native APIs, such asAF_INET6
sockets. - [C-0-3] MUST enable IPv6 by default.
- MUST ensure that IPv6 communication is as reliable as IPv4, for example:
- [C-0-4] MUST maintain IPv6 connectivity in doze mode.
- [C-0-5] Việc giới hạn tốc độ KHÔNG ĐƯỢC làm thiết bị mất kết nối IPv6 trên bất kỳ mạng nào tuân thủ IPv6 sử dụng thời gian hoạt động của RA ít nhất là 180 giây.
- MUST ensure that IPv6 communication is as reliable as IPv4, for example:
- [C-0-6] PHẢI cung cấp cho các ứng dụng bên thứ ba khả năng kết nối IPv6 trực tiếp với mạng khi kết nối với mạng IPv6, mà không có bất kỳ hình thức dịch địa chỉ hoặc cổng nào diễn ra cục bộ trên thiết bị. Cả API được quản lý như
Socket#getLocalAddress
hoặcSocket#getLocalPort
và API NDK nhưgetsockname()
hoặcIPV6_PKTINFO
đều PHẢI trả về địa chỉ IP và cổng thực sự dùng để gửi và nhận gói trên mạng, đồng thời hiển thị dưới dạng địa chỉ IP nguồn và cổng đến máy chủ Internet (web).
The required level of IPv6 support depends on the network type, as shown in the following requirements.
If device implementations support Wi-Fi, they:
- [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
If device implementations support Ethernet, they:
- [C-2-1] MUST support dual-stack and IPv6-only operation on Ethernet.
If device implementations support Cellular data, they:
- [C-3-1] MUST support IPv6 operation (IPv6-only and possibly dual-stack) on cellular.
If device implementations support more than one network type (e.g., Wi-Fi và dữ liệu di động), họ:
- [C-4-1] PHẢI đồng thời đáp ứng các yêu cầu trên trên mỗi mạng khi thiết bị đồng thời kết nối với nhiều loại mạng.
7.4.5.3. Trang xác thực
Trang xác thực là một mạng yêu cầu đăng nhập để truy cập Internet.
Nếu các phương thức triển khai thiết bị cung cấp cách triển khai đầy đủ android.webkit.Webview API
, thì các phương thức đó:
- [C-1-1] PHẢI cung cấp một ứng dụng cổng truy cập nội bộ để xử lý ý định
ACTION_CAPTIVE_PORTAL_SIGN_IN
và hiển thị trang đăng nhập cổng truy cập nội bộ bằng cách gửi ý định đó khi gọi đến API hệ thốngConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] PHẢI phát hiện cổng truy cập nội bộ và hỗ trợ đăng nhập thông qua ứng dụng cổng truy cập nội bộ khi thiết bị kết nối với bất kỳ loại mạng nào, bao gồm cả mạng di động/mạng di động, Wi-Fi, Ethernet hoặc Bluetooth.
- [C-1-3] PHẢI hỗ trợ đăng nhập vào cổng truy cập bằng DNS văn bản thô khi thiết bị được định cấu hình để sử dụng chế độ nghiêm ngặt của DNS riêng.
- [C-1-4] PHẢI sử dụng DNS đã mã hoá theo tài liệu SDK cho
android.net.LinkProperties.getPrivateDnsServerName
vàandroid.net.LinkProperties.isPrivateDnsActive
đối với tất cả lưu lượng truy cập mạng không giao tiếp rõ ràng với cổng truy cập. - [C-1-5] PHẢI đảm bảo rằng trong khi người dùng đăng nhập vào cổng truy cập nội bộ, mạng mặc định mà các ứng dụng sử dụng (do
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
trả về và được các API kết nối mạng Java như java.net.Socket và các API gốc như connect()) là bất kỳ mạng nào khác có sẵn cung cấp quyền truy cập Internet, nếu có.
7.4.6. Cài đặt đồng bộ hóa
Device implementations:
- [C-0-1] MUST have the master auto-sync setting on by default so that
the method
getMasterSyncAutomatically()
returns “true”.
7.4.7. Trình tiết kiệm dữ liệu
If device implementations include a metered connection, they are:
- [C-SR-1] STRONGLY RECOMMENDED to provide the data saver mode.
If device implementations provide the data saver mode, they:
- [C-1-1] PHẢI hỗ trợ tất cả các API trong lớp
ConnectivityManager
như mô tả trong tài liệu SDK
If device implementations do not provide the data saver mode, they:
- [C-2-1] MUST return the value
RESTRICT_BACKGROUND_STATUS_DISABLED
forConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] KHÔNG ĐƯỢC truyền
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. Phần tử bảo mật
If device implementations support Open Mobile API-capable secure elements and make them available to third-party apps, they:
[C-1-1] PHẢI liệt kê các trình đọc phần tử bảo mật hiện có thông qua API
android.se.omapi.SEService.getReaders()
.[C-1-2] PHẢI khai báo đúng cờ tính năng thông qua
android.hardware.se.omapi.uicc
cho thiết bị có phần tử bảo mật dựa trên UICC,android.hardware.se.omapi.ese
cho thiết bị có phần tử bảo mật dựa trên eSE vàandroid.hardware.se.omapi.sd
cho thiết bị có phần tử bảo mật dựa trên SD.
7.4.9. UWB (băng tần siêu rộng)
If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, then they:
- [C-1-1] PHẢI triển khai API Android tương ứng trong android.uwb.
- [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
- [C-1-3] PHẢI hỗ trợ tất cả các hồ sơ UWB có liên quan được xác định trong quá trình triển khai Android.
- [C-1-4] PHẢI cung cấp một chức năng cho phép người dùng bật/tắt trạng thái đài UWB.
- [C-1-5] PHẢI thực thi việc các ứng dụng sử dụng đài UWB phải có quyền UWB_RANGING (trong nhóm quyền NEARBY_DEVICES).
- [C-SR-1] Bạn NÊN vượt qua các bài kiểm thử chứng nhận và tuân thủ liên quan do các tổ chức tiêu chuẩn xác định, bao gồm cả FIRA, CCC và CSA.
- [C-1-6] PHẢI đảm bảo kết quả đo khoảng cách nằm trong khoảng +/-15 cm đối với 95% số lần đo trong môi trường đường ngắm ở khoảng cách 1 m trong buồng không phản chiếu.
- [C-1-7] PHẢI đảm bảo rằng trung vị của các phép đo khoảng cách ở 1m từ thiết bị tham chiếu nằm trong khoảng [0,75m, 1,25m], trong đó khoảng cách thực tế được đo từ cạnh trên của DUT.
được giữ ở mặt trên và nghiêng 45 độ. - [C-SR-2] Bạn NÊN làm theo các bước thiết lập đo lường được chỉ định trong Các yêu cầu về việc hiệu chỉnh sự hiện diện.
7.5. Camera
If device implementations include at least one camera, they:
- [C-1-1] MUST declare the
android.hardware.camera.any
feature flag. - [C-1-2] Ứng dụng PHẢI có thể đồng thời phân bổ 3 bitmap RGBA_8888 bằng kích thước của hình ảnh do cảm biến máy ảnh có độ phân giải lớn nhất trên thiết bị tạo ra, trong khi máy ảnh đang mở để xem trước cơ bản và chụp ảnh tĩnh.
- [C-1-3] PHẢI đảm bảo rằng ứng dụng camera mặc định được cài đặt sẵn xử lý các ý định
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
hoặcMediaStore.ACTION_VIDEO_CAPTURE
chịu trách nhiệm xoá vị trí của người dùng trong siêu dữ liệu hình ảnh trước khi gửi đến ứng dụng nhận khi ứng dụng nhận không cóACCESS_FINE_LOCATION
.
Nếu các phương thức triển khai thiết bị hỗ trợ khả năng đầu ra HDR 10 bit, thì các phương thức đó:
- [C-2-1] PHẢI hỗ trợ ít nhất hồ sơ HDR HLG cho mọi thiết bị máy ảnh hỗ trợ đầu ra 10 bit.
- [C-2-2] PHẢI hỗ trợ đầu ra 10 bit cho camera sau chính hoặc camera trước chính.
- [C-SR-1] Bạn NÊN hỗ trợ đầu ra 10 bit cho cả hai camera chính.
- [C-2-3] PHẢI hỗ trợ cùng một hồ sơ HDR cho tất cả máy ảnh phụ thực có khả năng BACKWARD_COMPATIBLE của một máy ảnh logic và chính máy ảnh logic đó.
Đối với các thiết bị máy ảnh logic hỗ trợ HDR 10 bit triển khai API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
, các thiết bị này:
- [C-3-1] PHẢI hỗ trợ việc chuyển đổi giữa tất cả các máy ảnh thực có khả năng tương thích ngược thông qua chế độ điều khiển
CONTROL_ZOOM_RATIO
trên máy ảnh logic.
7.5.1. Máy ảnh mặt sau
A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera.
Bắt đầu yêu cầu mới
Máy ảnh sau là máy ảnh quay ra ngoài, chụp ảnh các cảnh ở phía xa của thiết bị, giống như máy ảnh truyền thống; trên các thiết bị cầm tay, đó là máy ảnh nằm ở phía bên kia của màn hình.
Kết thúc các yêu cầu mới
Device implementations:
- SHOULD include a rear-facing camera.
If device implementations include at least one rear-facing camera, they:
- [C-1-1] MUST report the feature flag
android.hardware.camera
andandroid.hardware.camera.any
. - [C-1-2] MUST have a resolution of at least 2 megapixels.
- SHOULD have either hardware auto-focus or software auto-focus implemented trong trình điều khiển máy ảnh (trong suốt với phần mềm ứng dụng).
- MAY have fixed-focus or EDOF (extended depth of field) hardware.
- MAY include a flash.
If the camera includes a flash:
- [C-2-1] the flash lamp MUST NOT be lit while an
android.hardware.Camera.PreviewCallback
instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling theFLASH_MODE_AUTO
orFLASH_MODE_ON
attributes of aCamera.Parameters
object. Lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng máy ảnh hệ thống tích hợp sẵn của thiết bị, mà chỉ áp dụng cho các ứng dụng bên thứ ba sử dụngCamera.PreviewCallback
.
7.5.2. Máy ảnh mặt trước
A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.
Bắt đầu yêu cầu mới
Máy ảnh mặt trước là máy ảnh hướng về phía người dùng, thường dùng để chụp hình người dùng, chẳng hạn như cho ứng dụng hội nghị truyền hình và các ứng dụng tương tự; trên thiết bị cầm tay, đó là máy ảnh nằm ở cùng một bên của thiết bị với màn hình.
Kết thúc các yêu cầu mới
Device implementations:
- MAY include a front-facing camera.
If device implementations include at least one front-facing camera, they:
- [C-1-1] MUST report the feature flag
android.hardware.camera.any
andandroid.hardware.camera.front
. - [C-1-2] MUST have a resolution of at least VGA (640x480 pixels).
- [C-1-3] KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm mặc định cho Camera API và KHÔNG ĐƯỢC định cấu hình API để coi máy ảnh mặt trước là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị.
- [C-1-4] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng do ứng dụng chỉ định khi ứng dụng hiện tại đã yêu cầu rõ ràng rằng màn hình Máy ảnh phải được xoay thông qua lệnh gọi phương thức
android.hardware.Camera.setDisplayOrientation()
. Ngược lại, bản xem trước PHẢI được phản chiếu dọc theo trục ngang mặc định của thiết bị khi ứng dụng hiện tại không yêu cầu rõ ràng việc xoay màn hình Máy ảnh thông qua lệnh gọi phương thứcandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] KHÔNG ĐƯỢC phản chiếu luồng hình ảnh tĩnh hoặc video đã chụp cuối cùng được trả về lệnh gọi lại ứng dụng hoặc được cam kết lưu vào bộ nhớ phương tiện.
- [C-1-6] PHẢI phản chiếu hình ảnh hiển thị trong chế độ xem sau theo cách tương tự như luồng hình ảnh xem trước của máy ảnh.
- MAY include features (such as auto-focus, flash, etc.) available to camera sau như mô tả trong mục 7.5.1.
If device implementations are capable of being rotated by user (such as automatically via an accelerometer or manually via user input):
- [C-2-1] Bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng hiện tại của thiết bị.
7.5.3. Máy ảnh gắn ngoài
Bắt đầu yêu cầu mới
Máy ảnh bên ngoài là máy ảnh có thể được gắn hoặc tháo rời khỏi quá trình triển khai thiết bị bất cứ lúc nào và có thể hướng về bất kỳ hướng nào; chẳng hạn như máy ảnh USB.
Kết thúc các yêu cầu mới
Device implementations:
- MAY include support for an external camera that is not necessarily always connected.
If device implementations include support for an external camera, they:
- [C-1-1] MUST declare the platform feature flag
android.hardware.camera.external
andandroid.hardware camera.any
. - [C-1-2] MUST support USB Video Class (UVC 1.0 or higher) if the external camera connects through the USB host port.
- [C-1-3] PHẢI vượt qua các bài kiểm thử CTS của máy ảnh khi kết nối với một thiết bị máy ảnh bên ngoài thực tế. Bạn có thể xem thông tin chi tiết về quy trình kiểm thử CTS cho máy ảnh tại source.android.com.
- SHOULD support video compressions such as MJPEG to enable transfer of high-quality unencoded streams (i.e. raw or independently compressed picture streams).
- MAY support multiple cameras.
- MAY support camera-based video encoding.
Nếu tính năng mã hoá video dựa trên máy ảnh được hỗ trợ:
- [C-2-1] Hệ thống triển khai thiết bị PHẢI truy cập được luồng MJPEG / không mã hoá đồng thời (độ phân giải QVGA trở lên).
7.5.4. Hành vi của Camera API
Android bao gồm hai gói API để truy cập vào máy ảnh, API android.hardware.camera2 mới hơn hiển thị chế độ điều khiển máy ảnh cấp thấp cho ứng dụng, bao gồm cả luồng chụp/truyền trực tuyến không sao chép hiệu quả và các chế độ điều khiển theo khung hình của độ phơi sáng, độ lợi, độ lợi cân bằng trắng, chuyển đổi màu, loại bỏ nhiễu, làm sắc nét, v.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 các ứng dụng vẫn có thể sử dụng gói này. Các hoạt động triển khai thiết bị Android
PHẢI đảm bảo việc tiếp tục hỗ trợ API như mô tả trong
phần này và trong SDK Android.
Tất cả các tính năng phổ biến giữa lớp android.hardware.Camera không dùng nữa và gói android.hardware.camera2 mới hơn PHẢI có hiệu suất và chất lượng tương đương trong cả hai API. Ví dụ: với các chế độ cài đặt tương đương, tốc độ và độ chính xác của tính năng tự động lấy nét phải giống nhau và chất lượng của hình ảnh được chụp phải giống nhau. Các tính năng phụ thuộc vào ngữ nghĩa khác nhau của hai API không bắt buộc phải có tốc độ hoặc chất lượng phù hợp, nhưng PHẢI khớp gần nhất có thể.
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:
- [C-0-1] PHẢI sử dụng
android.hardware.PixelFormat.YCbCr_420_SP
cho dữ liệu xem trước được cung cấp cho các lệnh gọi lại ứng dụng khi ứng dụng chưa bao giờ gọiandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] PHẢI ở định dạng mã hoá NV21 khi một ứng dụng đăng ký một thực thể
android.hardware.Camera.PreviewCallback
và hệ thống gọi phương thứconPreviewFrame()
và định dạng xem trước là YCbCr_420_SP, dữ liệu trong byte[] được truyền vàoonPreviewFrame()
. Tức là NV21 PHẢI là giá trị mặc định. - [C-0-3] PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số
android.graphics.ImageFormat.YV12
) cho bản xem trước của máy ảnh cho cả máy ảnh trước và sau đối vớiandroid.hardware.Camera
. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.) - [C-0-4] PHẢI hỗ trợ các định dạng
android.hardware.ImageFormat.YUV_420_888
vàandroid.hardware.ImageFormat.JPEG
dưới dạng đầu ra thông qua APIandroid.media.ImageReader
cho các thiết bịandroid.hardware.camera2
quảng cáo chức năngREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
trongandroid.request.availableCapabilities
. - [C-0-5] VẪN PHẢI triển khai đầy đủ Camera API có trong tài liệu SDK Android, bất kể thiết bị có tính năng tự động lấy nét bằng phần cứng hay các tính năng khác. Ví dụ: các máy ảnh không có tính năng tự động lấy nét VẪN PHẢI gọi mọi thực thể
android.hardware.Camera.AutoFocusCallback
đã đăng ký (mặc dù điều này không liên quan đến máy ảnh không có tính năng tự động lấy nét). Lưu ý rằng điều này áp dụng cho máy ảnh mặt trước; ví dụ: mặc dù hầu hết máy ảnh mặt trước không hỗ trợ tự động lấy nét, nhưng các lệnh gọi lại API vẫn phải được "giả mạo" như mô tả. - [C-0-6] PHẢI nhận dạng và tuân thủ từng tên tham số được xác định là hằng số trong lớp
android.hardware.Camera.Parameters
và lớpandroid.hardware.camera2.CaptureRequest
. Ngược lại, việc triển khai thiết bị KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số chuỗi được truyền đến phương thứcandroid.hardware.Camera.setParameters()
, ngoại trừ các hằng số được ghi nhận là hằng số trênandroid.hardware.Camera.Parameters
. Tức là, việc triển khai thiết bị PHẢI hỗ trợ tất cả các thông số Máy ảnh 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ố Máy ảnh tuỳ chỉnh. Ví dụ: các phương thức triển khai thiết bị hỗ trợ chụp ảnh bằng kỹ thuật chụp ảnh có dải động cao (HDR) PHẢI hỗ trợ thông số máy ảnhCamera.SCENE_MODE_HDR
. - [C-0-7] MUST report the proper level of support with the
android.info.supportedHardwareLevel
property as described in the Android SDK and report the appropriate framework feature flags. - [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ínhandroid.request.availableCapabilities
và khai báo cờ tính năng thích hợp; PHẢI xác định cờ tính năng nếu bất kỳ thiết bị máy ảnh nào được đính kèm hỗ trợ tính năng đó. - [C-0-9] PHẢI truyền phát ý định
Camera.ACTION_NEW_PICTURE
mỗi khi máy ảnh chụp một bức ảnh mới và mục nhập của bức ảnh đó đã được thêm vào kho phương tiện. - [C-0-10] MUST broadcast the
Camera.ACTION_NEW_VIDEO
intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store. - [C-0-11] PHẢI có tất cả các máy ảnh có thể truy cập được thông qua API
android.hardware.Camera
không dùng nữa cũng có thể truy cập được thông qua APIandroid.hardware.camera2
. - [C-0-12] PHẢI đảm bảo rằng diện mạo khuôn mặt KHÔNG bị thay đổi, bao gồm nhưng không giới hạn ở việc thay đổi hình dạng khuôn mặt, màu da khuôn mặt hoặc làm mịn da mặt cho bất kỳ API
android.hardware.camera2
hoặcandroid.hardware.Camera
nào. - [C-SR-1] Đối với các thiết bị có nhiều máy ảnh RGB ở gần nhau và hướng về cùng một hướng, bạn NÊN hỗ trợ thiết bị máy ảnh logic liệt kê chức năng
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, bao gồm tất cả các máy ảnh RGB hướng về hướng đó dưới dạng thiết bị phụ thực.
If device implementations provide a proprietary camera API to 3rd-party apps, they:
- [C-1-1] PHẢI triển khai API máy ảnh như vậy bằng API
android.hardware.camera2
. - CÓ THỂ cung cấp thẻ nhà cung cấp và/hoặc tiện ích cho API
android.hardware.camera2
.
7.5.5. Hướng máy ảnh
If device implementations have a front- or a rear-facing camera, such camera(s):
- [C-1-1] PHẢI được định hướng để kích thước dài của máy ảnh phù hợp với kích thước dài của màn hình. Tức là khi thiết bị được cầm theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang. Điều này áp dụng bất kể hướng tự nhiên của thiết bị; tức là áp dụng cho thiết bị chính là hướng ngang cũng như thiết bị chính là hướng dọc.
Những thiết bị đáp ứng tất cả các tiêu chí sau đây sẽ được miễn tuân thủ yêu cầu trên:
- Thiết bị triển khai màn hình hình học biến đổi, chẳng hạn như màn hình có thể gập lại hoặc có bản lề.
- Khi trạng thái gập hoặc bản lề của thiết bị thay đổi, thiết bị sẽ chuyển đổi giữa hướng dọc chính sang hướng ngang chính (hoặc ngược lại).
Bắt đầu yêu cầu mới
- Các phương thức triển khai thiết bị mà người dùng không thể xoay, chẳng hạn như thiết bị ô tô.
Kết thúc các yêu cầu mới
7.6. Bộ nhớ và dung lượng lưu trữ
7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu
Device implementations:
- [C-0-1] PHẢI có một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ sử dụng để tải tệp dữ liệu xuống và các ứng dụng này PHẢI có khả năng tải các tệp riêng lẻ có kích thước tối thiểu 100 MB xuống vị trí "bộ nhớ đệm" mặc định.
7.6.2. Bộ nhớ dùng chung của ứng dụng
Device implementations:
- [C-0-1] PHẢI cung cấp bộ nhớ để các ứng dụng dùng chung, còn gọi là "bộ nhớ ngoài dùng chung", "bộ nhớ dùng chung của ứng dụng" hoặc theo đường dẫn Linux "/sdcard" mà bộ nhớ đó được gắn vào.
- [C-0-2] PHẢI được định cấu hình với bộ nhớ dùng chung được gắn theo mặc định, nói cách khác là "trực tiếp", bất kể bộ nhớ được triển khai trên thành phần bộ nhớ trong hay phương tiện bộ nhớ có thể tháo rời (ví dụ: khe cắm thẻ Secure Digital).
- [C-0-3] PHẢI gắn bộ nhớ dùng chung của ứng dụng trực tiếp trên đường dẫn Linux
sdcard
hoặc đưa đường liên kết tượng trưng Linux từsdcard
đến điểm gắn thực tế. - [C-0-4] PHẢI bật bộ nhớ có giới hạn theo mặc định cho tất cả ứng dụng nhắm đến API cấp 29 trở lên, ngoại trừ trường hợp sau:
- Khi ứng dụng đã yêu cầu
android:requestLegacyExternalStorage="true"
trong tệp kê khai.
- Khi ứng dụng đã yêu cầu
- [C-0-5] PHẢI loại bỏ siêu dữ liệu vị trí, chẳng hạn như thẻ Exif GPS, được lưu trữ trong các tệp phương tiện khi các tệp đó được truy cập thông qua
MediaStore
, ngoại trừ trường hợp ứng dụng gọi có quyềnACCESS_MEDIA_LOCATION
.
Device implementations MAY meet the above requirements using either of the following:
- Bộ nhớ có thể tháo rời mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ Secure Digital (SD).
- Một phần bộ nhớ trong (không thể tháo rời) được triển khai trong Dự án nguồn mở Android (AOSP).
If device implementations use removable storage to satisfy the above requirements, they:
- [C-1-1] PHẢI triển khai một thông báo ngắn hoặc giao diện người dùng bật lên để cảnh báo người dùng khi không có phương tiện lưu trữ nào được lắp vào khe cắm.
- [C-1-2] PHẢI có phương tiện lưu trữ được định dạng FAT (ví dụ: thẻ SD) hoặc cho biết trên hộp và tài liệu khác tại thời điểm mua rằng phương tiện lưu trữ phải được mua riêng.
If device implementations use a portion of the non-removable storage to satisfy the above requirements, they:
- NÊN sử dụng cách triển khai AOSP của bộ nhớ dùng chung của ứng dụng nội bộ.
- MAY share the storage space with the application private data.
If device implementations have a USB port with USB peripheral mode support, they:
- [C-3-1] PHẢI cung cấp cơ chế để truy cập vào dữ liệu trên bộ nhớ dùng chung của ứng dụng từ máy tính lưu trữ.
- NÊN hiển thị nội dung từ cả hai đường dẫn bộ nhớ một cách minh bạch thông qua dịch vụ quét nội dung đa phương tiện của Android và
android.provider.MediaStore
. - MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement.
If device implementations have a USB port with USB peripheral mode and support Media Transfer Protocol, they:
- SHOULD be compatible with the reference Android MTP host, Android File Transfer.
- SHOULD report a USB device class of 0x00.
- SHOULD report a USB interface name of 'MTP'.
7.6.3. Bộ nhớ thích ứng
Nếu thiết bị dự kiến là thiết bị di động (không giống như TV), thì cách triển khai thiết bị sẽ là:
- [C-SR-1] STRONGLY RECOMMENDED to implement the adoptable storage in a long-term stable location, since accidentally disconnecting them can cause data loss/corruption.
Nếu cổng thiết bị lưu trữ có thể tháo rời nằm ở vị trí ổn định lâu dài, chẳng hạn như trong ngăn pin hoặc nắp bảo vệ khác, thì cách triển khai thiết bị sẽ là:
- [C-SR-2] STRONGLY RECOMMENDED to implement adoptable storage.
7.7. USB
If device implementations have a USB port, they:
- SHOULD support USB peripheral mode and SHOULD support USB host mode.
- NÊN hỗ trợ tính năng tắt tính năng báo hiệu dữ liệu qua USB.
7.7.1. Chế độ thiết bị ngoại vi USB
If device implementations include a USB port supporting peripheral mode:
- [C-1-1] Cổng này PHẢI kết nối được với máy chủ USB có cổng USB loại A hoặc loại C tiêu chuẩn.
- [C-1-2] MUST report the correct value of
iSerialNumber
in USB standard device descriptor throughandroid.os.Build.SERIAL
. - [C-1-3] PHẢI phát hiện bộ sạc 1,5A và 3,0A theo tiêu chuẩn điện trở Type-C và PHẢI phát hiện các thay đổi trong quảng cáo nếu bộ sạc đó hỗ trợ USB Type-C.
- [C-SR-1] The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
- [C-SR-2] Cổng NÊN nằm ở đáy thiết bị (theo hướng tự nhiên) hoặc bật tính năng xoay màn hình bằng phần mềm cho tất cả ứng dụng (bao gồm cả màn hình chính) để màn hình vẽ chính xác khi thiết bị được định hướng với cổng ở đáy. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
- [C-SR-3] SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging specification, revision 1.2. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
- [C-SR-4] STRONGLY RECOMMENDED to not support charging methods that modify Vbus voltage beyond default levels, or alter sink/source roles as such may result in interoperability issues with the chargers or devices that support the standard USB Power Delivery methods. Mặc dù điều này được gọi là "RẤT NÊN", nhưng trong các phiên bản Android trong tương lai, chúng tôi có thể YÊU CẦU tất cả thiết bị loại C hỗ trợ khả năng tương tác đầy đủ với bộ sạc loại C tiêu chuẩn.
- [C-SR-5] STRONGLY RECOMMENDED to support Power Delivery for data and power role swapping when they support Type-C USB and USB host mode.
- SHOULD support Power Delivery for high-voltage charging and support for Alternate Modes such as display out.
- SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation.
If device implementations include a USB port and implement the AOA specification, they:
- [C-2-1] MUST declare support for the hardware feature
android.hardware.usb.accessory
. - [C-2-2] The USB mass storage class MUST include the string "android" at the
end of the interface description
iInterface
string of the USB mass storage
7.7.2. Chế độ máy chủ USB
If device implementations include a USB port supporting host mode, they:
- [C-1-1] PHẢI triển khai API máy chủ USB Android như được ghi nhận trong SDK Android và PHẢI khai báo hỗ trợ tính năng phần cứng
android.hardware.usb.host
. - [C-1-2] PHẢI triển khai tính năng hỗ trợ để kết nối các thiết bị ngoại vi USB tiêu chuẩn, nói cách khác, thiết bị PHẢI:
- Có cổng loại C trên thiết bị hoặc được vận chuyển kèm theo(các) cáp chuyển đổi cổng độc quyền trên thiết bị sang cổng USB loại C tiêu chuẩn (thiết bị USB loại C).
- Có cổng loại A trên thiết bị hoặc đi kèm(các) cáp chuyển đổi cổng độc quyền trên thiết bị sang cổng USB loại A tiêu chuẩn.
- Có cổng micro-AB trên thiết bị, CẦN phải đi kèm với cáp chuyển đổi sang cổng loại A tiêu chuẩn.
- [C-1-3] KHÔNG ĐƯỢC vận chuyển kèm theo bộ chuyển đổi từ cổng USB loại A hoặc cổng micro-AB sang cổng loại C (ổ cắm).
- [C-SR-1] Bạn NÊN triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android.
- NÊN hỗ trợ sạc thiết bị ngoại vi USB đã kết nối khi ở chế độ máy chủ; quảng cáo dòng nguồn ít nhất là 1,5A như được chỉ định trong phần Thông số kết thúc của USB Type-C Cable and Connector Specification Revision 1.2 (Thông số kỹ thuật về cáp và đầu nối USB Type-C, bản sửa đổi 1.2) đối với các đầu nối USB Type-C hoặc sử dụng phạm vi dòng đầu ra của Cổng truyền tải xuống (CDP) như được chỉ định trong USB Battery Charging specifications, revision 1.2 (Thông số kỹ thuật về sạc pin USB, bản sửa đổi 1.2) đối với các đầu nối Micro-AB.
- SHOULD implement and support USB Type-C standards.
If device implementations include a USB port supporting host mode and the USB audio class, they:
- [C-2-1] MUST support the USB HID class.
- [C-2-2] PHẢI hỗ trợ việc phát hiện và liên kết các trường dữ liệu HID sau đây được chỉ định trong Bảng sử dụng USB HID và Yêu cầu sử dụng lệnh thoại với các hằng số
KeyEvent
như bên dưới:- Usage Page (0xC) Usage ID (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Usage Page (0xC) Usage ID (0x0E9):
KEYCODE_VOLUME_UP
- Usage Page (0xC) Usage ID (0x0EA):
KEYCODE_VOLUME_DOWN
- Usage Page (0xC) Usage ID (0x0CF):
KEYCODE_VOICE_ASSIST
- Usage Page (0xC) Usage ID (0x0CD):
If device implementations include a USB port supporting host mode and the Storage Access Framework (SAF), they:
- [C-3-1] PHẢI nhận dạng mọi thiết bị MTP (Giao thức truyền phương tiện) được kết nối từ xa và cho phép truy cập vào nội dung của các thiết bị đó thông qua ý định
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
vàACTION_CREATE_DOCUMENT
. .
If device implementations include a USB port supporting host mode and USB Type-C, they:
- [C-4-1] PHẢI triển khai chức năng Cổng hai vai trò như được xác định trong quy cách USB Type-C (mục 4.5.1.3.3). Đối với Cổng có vai trò kép, trên các thiết bị có giắc cắm âm thanh 3,5 mm, tính năng phát hiện bồn lưu trữ USB (chế độ máy chủ) CÓ THỂ tắt theo mặc định nhưng người dùng PHẢI có thể bật tính năng này.
- [C-SR-2] STRONGLY RECOMMENDED to support DisplayPort, SHOULD support USB SuperSpeed Data Rates, and are STRONGLY RECOMMENDED to support Power Delivery for data and power role swapping.
- [C-SR-3] STRONGLY RECOMMENDED to NOT support Audio Adapter Accessory Mode as described in the Appendix A of USB Type-C Cable and Connector Specification Revision 1.2.
- NÊN triển khai mô hình Try.* phù hợp nhất với kiểu dáng thiết bị. Ví dụ: thiết bị cầm tay NÊN triển khai mô hình Try.SNK.
7.8. Âm thanh
7.8.1. Micrô
If device implementations include a microphone, they:
- [C-1-1] PHẢI báo cáo hằng số tính năng
android.hardware.microphone
. - [C-1-2] MUST meet the audio recording requirements in section 5.4.
- [C-1-3] MUST meet the audio latency requirements in section 5.6.
- [C-SR-1] Are STRONGLY RECOMMENDED to support near-ultrasound recording as described in section 7.8.3.
If device implementations omit a microphone, they:
- [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 âm thanh ở chế độ không hoạt động theo mục 7.
7.8.2. Đầu ra âm thanh
If device implementations include a speaker or an audio/multimedia output port for an audio output peripheral such as a 4 conductor 3.5mm audio jack or USB host mode port using USB audio class, they:
- [C-1-1] PHẢI báo cáo hằng số tính năng
android.hardware.audio.output
. - [C-1-2] MUST meet the audio playback requirements in section 5.5.
- [C-1-3] MUST meet the audio latency requirements in section 5.6.
- [C-SR-1] STRONGLY RECOMMENDED to support near-ultrasound playback as described in section 7.8.3.
If device implementations do not include a speaker or audio output port, they:
- [C-2-1] MUST NOT report the
android.hardware.audio.output
feature. - [C-2-2] PHẢI triển khai các API liên quan đến Đầu ra âm thanh ở trạng thái không hoạt động.
For the purposes of this section, an "output port" is a physical interface such as a 3.5mm audio jack, HDMI, or USB host mode port with USB audio class. Tính năng hỗ trợ đầu ra âm thanh qua các giao thức dựa trên sóng vô tuyến như Bluetooth, Wi-Fi hoặc mạng di động không đủ điều kiện để được coi là "cổng đầu ra".
7.8.2.1. Cổng âm thanh tương tự
In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem, if implementations of the device include one or more analog audio ports, they:
- [C-SR-1] Bạn NÊN dùng ít nhất một cổng âm thanh là giắc cắm âm thanh 3,5 mm 4 dây.
If device implementations have a 4 conductor 3.5mm audio jack, they:
- [C-1-1] MUST support audio playback to stereo headphones and stereo headsets with a microphone.
- [C-1-2] MUST support TRRS audio plugs with the CTIA pin-out order.
- [C-1-3] MUST support the detection and mapping to the keycodes for the 3 ranges of equivalent impedance sau đây giữa micrô và dây dẫn nối đất trên giắc cắm âm thanh:
- 70 ohm or less:
KEYCODE_HEADSETHOOK
- 210-290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 ohm or less:
- [C-1-4] PHẢI kích hoạt
ACTION_HEADSET_PLUG
khi cắm phích cắm, nhưng chỉ sau khi tất cả các tiếp điểm trên phích cắm chạm vào các phân đoạn liên quan trên giắc cắm. - [C-1-5] PHẢI có khả năng điều khiển ít nhất 150mV ± 10% điện áp đầu ra trên một trở kháng loa 32 ohm.
- [C-1-6] MUST have a microphone bias voltage between 1.8V ~ 2.9V.
- [C-1-7] MUST detect and map to the keycode for the following
range of equivalent impedance between the microphone and ground conductors
on the audio plug:
- 110-180 ohm:
KEYCODE_VOICE_ASSIST
- 110-180 ohm:
- [C-SR-2] Are STRONGLY RECOMMENDED to support audio plugs with the OMTP pin-out order.
- [C-SR-3] Are STRONGLY RECOMMENDED to support audio recording from stereo headsets with a microphone.
If device implementations have a 4 conductor 3.5mm audio jack and support a
microphone, and broadcast the android.intent.action.HEADSET_PLUG
with the
extra value microphone set as 1, they:
- [C-2-1] MUST support the detection of microphone on the plugged in audio accessory.
7.8.2.2. Cổng âm thanh kỹ thuật số
Xem Mục 2.2.1 để biết các yêu cầu dành riêng cho thiết bị.
7.8.3. Near-Ultrasound
Near-Ultrasound audio is the 18.5 kHz to 20 kHz band.
Device implementations:
- MUST correctly report the support of near-ultrasound audio capability via the AudioManager.getProperty API as follows:
Nếu PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
là "true", thì nguồn âm thanh VOICE_RECOGNITION
và UNPROCESSED
PHẢI đáp ứng các yêu cầu sau:
- [C-1-1] The microphone's mean power response in the 18.5 kHz to 20 kHz band MUST be no more than 15 dB below the response at 2 kHz.
- [C-1-2] The microphone's unweighted signal to noise ratio over 18.5 kHz to 20 kHz for a 19 kHz tone at -26 dBFS MUST be no lower than 50 dB.
Nếu PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
là "true":
- [C-2-1] The speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB below the response at 2 kHz.
7.8.4. Tính toàn vẹn của tín hiệu
Device implementations:
- NÊN cung cấp đường dẫn tín hiệu âm thanh không bị lỗi cho cả luồng đầu vào và đầu ra trên thiết bị cầm tay, được xác định bằng việc không có lỗi nào được đo lường trong quá trình kiểm thử một phút cho mỗi đường dẫn. Kiểm thử bằng OboeTester "Kiểm thử lỗi tự động".
Quy trình kiểm thử này yêu cầu một đầu nối âm thanh vòng lặp, được sử dụng trực tiếp trong giắc cắm 3,5 mm và/hoặc kết hợp với bộ chuyển đổi USB-C sang 3,5 mm. Tất cả cổng đầu ra âm thanh PHẢI được kiểm thử.
OboeTester hiện hỗ trợ các đường dẫn AAudio, vì vậy, bạn NÊN kiểm thử các tổ hợp sau để tìm lỗi bằng AAudio:
Chế độ Perf | Chia sẻ | Tốc độ lấy mẫu đầu ra | Trong Chans | Out Chans |
---|---|---|---|---|
LOW_LATENCY | ĐỘC QUYỀN | KHÔNG XÁC ĐỊNH | 1 | 2 |
LOW_LATENCY | ĐỘC QUYỀN | KHÔNG XÁC ĐỊNH | 2 | 1 |
LOW_LATENCY | ĐÃ CHIA SẺ | KHÔNG XÁC ĐỊNH | 1 | 2 |
LOW_LATENCY | ĐÃ CHIA SẺ | KHÔNG XÁC ĐỊNH | 2 | 1 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 48000 | 1 | 2 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 48000 | 2 | 1 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 44100 | 1 | 2 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 44100 | 2 | 1 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 16000 | 1 | 2 |
KHÔNG CÓ | ĐÃ CHIA SẺ | 16000 | 2 | 1 |
Một luồng đáng tin cậy PHẢI đáp ứng các tiêu chí sau đây về Tỷ lệ tín hiệu trên tạp âm (SNR) và Tổng độ méo hài (THD) đối với tín hiệu sin 2000 Hz.
Bộ chuyển đổi | THD | SNR |
---|---|---|
loa tích hợp chính, được đo bằng micrô tham chiếu bên ngoài | < 3% | >= 50 dB |
micrô tích hợp chính, được đo bằng loa tham chiếu bên ngoài | < 3% | >= 50 dB |
giắc cắm 3,5 mm tương tự tích hợp, được kiểm thử bằng bộ chuyển đổi vòng lặp | Chưa đến 1% | >= 60 dB |
Bộ chuyển đổi USB đi kèm với điện thoại, được kiểm thử bằng bộ chuyển đổi vòng lặp | < 1% | >= 60 dB |
7.9. Thực tế ảo
Android bao gồm các API và cơ sở để xây dựng ứng dụng "Thực tế ảo" (VR), bao gồm cả trải nghiệm VR chất lượng cao trên thiết bị di động. 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.
7.9.1. Chế độ thực tế ảo
Android hỗ trợ Chế độ VR, một tính năng xử lý chế độ kết xuất hình ảnh ba chiều của thông báo và tắt các thành phần giao diện người dùng hệ thống đơn sắc khi ứng dụng VR có tiêu điểm người dùng.
7.9.2. Virtual Reality Mode – High Performance
If device implementations support VR mode, they:
- [C-1-1] MUST have at least 2 physical cores.
- [C-1-2] MUST declare the
android.hardware.vr.high_performance
feature. - [C-1-3] MUST support sustained performance mode.
- [C-1-4] MUST support OpenGL ES 3.2.
- [C-1-5] MUST support
android.hardware.vulkan.level
0. - SHOULD support
android.hardware.vulkan.level
1 or higher. - [C-1-6] MUST implement
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
, and expose the extensions in the list of available EGL extensions. - [C-1-8] MUST implement
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, and expose the extensions in the list of available GL extensions. - [C-SR-1] Bạn NÊN triển khai
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
và hiển thị các tiện ích trong danh sách tiện ích GL hiện có. - [C-SR-2] Are STRONGLY RECOMMENDED to support Vulkan 1.1.
- [C-SR-3] Are STRONGLY RECOMMENDED to implement
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, and expose it in the list of available Vulkan extensions. - [C-SR-4] Bạn NÊN hiển thị ít nhất một nhóm hàng đợi Vulkan trong đó
flags
chứa cảVK_QUEUE_GRAPHICS_BIT
vàVK_QUEUE_COMPUTE_BIT
, vàqueueCount
là ít nhất 2. - [C-1-7] GPU và màn hình PHẢI có thể đồng bộ hoá quyền truy cập vào vùng đệm trước dùng chung để hiển thị chế độ kết xuất xen kẽ mắt của nội dung VR ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất mà không có hiện tượng xé hình.
- [C-1-9] MUST implement support for
AHardwareBuffer
flagsAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
andAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
as described in the NDK. - [C-1-10] MUST implement support for
AHardwareBuffer
s with any combination of the usage flagsAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
for at least the following formats:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] Are STRONGLY RECOMMENDED to support the allocation of
AHardwareBuffer
s with more than one layer and flags and formats specified in C-1-10. - [C-1-11] PHẢI hỗ trợ giải mã H.264 ở độ phân giải tối thiểu 3840 x 2160 với tốc độ 30 khung hình/giây, được nén ở tốc độ trung bình 40 Mb/giây (tương đương với 4 phiên bản 1920 x 1080 ở tốc độ 30 khung hình/giây – 10 Mb/giây hoặc 2 phiên bản 1920 x 1080 ở tốc độ 60 khung hình/giây – 20 Mb/giây).
- [C-1-12] PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã ít nhất là 1920 x 1080 ở tốc độ 30 khung hình/giây, được nén ở tốc độ trung bình là 10 Mb/giây và NÊN có khả năng giải mã 3840 x 2160 ở tốc độ 30 khung hình/giây-20 Mb/giây (tương đương với 4 phiên bản 1920 x 1080 ở tốc độ 30 khung hình/giây-5 Mb/giây).
- [C-1-13] PHẢI hỗ trợ API
HardwarePropertiesManager.getDeviceTemperatures
và trả về các giá trị chính xác cho nhiệt độ da. - [C-1-14] PHẢI có màn hình tích hợp và độ phân giải PHẢI tối thiểu là 1920 x 1080.
- [C-SR-6] Are STRONGLY RECOMMENDED to have a display resolution of at least 2560 x 1440.
- [C-1-15] Màn hình PHẢI cập nhật ít nhất 60 Hz khi ở Chế độ thực tế ảo.
- [C-1-17] Màn hình PHẢI hỗ trợ chế độ độ bền thấp với độ bền ≤ 5 mili giây, độ bền được xác định là khoảng thời gian mà một pixel phát ra ánh sáng.
- [C-1-18] MUST support Bluetooth 4.2 and Bluetooth LE Data Length 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:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] Are STRONGLY RECOMMENDED to support the
TYPE_HARDWARE_BUFFER
direct channel type for all Direct Channel Types listed above. - [C-1-21] MUST meet the gyroscope, accelerometer, and magnetometer related
requirements for
android.hardware.hifi_sensors
, as specified in section 7.3.9. - [C-SR-8] Are STRONGLY RECOMMENDED to support the
android.hardware.sensor.hifi_sensors
feature. - [C-1-22] PHẢI có độ trễ từ đầu đến cuối của chuyển động đến photon không cao hơn 28 mili giây.
- [C-SR-9] Are STRONGLY RECOMMENDED to have end-to-end motion to photon latency not higher than 20 milliseconds.
- [C-1-23] PHẢI có tỷ lệ khung hình đầu tiên, tức là tỷ lệ giữa độ sáng của các pixel trên khung hình đầu tiên sau khi chuyển đổi từ màu đen sang màu trắng và độ sáng của các pixel trắng ở trạng thái ổn định, ít nhất là 85%.
- [C-SR-10] Are STRONGLY RECOMMENDED to have first-frame ratio of at least 90%.
- MAY provide an exclusive core to the foreground
application and MAY support the
Process.getExclusiveCores
API to return the numbers of the cpu cores that are exclusive to the top foreground application.
If exclusive core is supported, then the core:
- [C-2-1] KHÔNG ĐƯỢC cho phép bất kỳ quy trình không gian người dùng nào khác chạy trên đó (ngoại trừ trình điều khiển thiết bị mà ứng dụng sử dụng), nhưng CÓ THỂ cho phép một số quy trình hạt nhân chạy khi cần.
7.10. Xúc giác
Bắt đầu yêu cầu mới
Các thiết bị cầm tay hoặc đeo có thể bao gồm một bộ truyền động xúc giác dùng cho nhiều mục đích, có sẵn cho các ứng dụng cho các mục đích bao gồm cả việc thu hút sự chú ý thông qua chuông nhạc, chuông báo, thông báo cũng như phản hồi chung về thao tác chạm.
Nếu các phương thức triển khai thiết bị KHÔNG bao gồm một bộ truyền động xúc giác dùng cho nhiều mục đích như vậy, thì các phương thức đó:
- [7.10/C] PHẢI trả về false cho
Vibrator.hasVibrator()
.
Nếu các phương thức triển khai thiết bị CÓ bao gồm ít nhất một bộ truyền động xúc giác đa năng như vậy, thì các phương thức đó:
- [C-1-1] PHẢI trả về true cho
Vibrator.hasVibrator()
. - KHÔNG NÊN sử dụng bộ truyền động xúc giác (máy rung) có khối lượng xoay lệch tâm (ERM).
- NÊN triển khai tất cả hằng số công khai cho cảm ứng rõ ràng trong
android.view.HapticFeedbackConstants
, cụ thể là (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
vàGESTURE_END
). - NÊN triển khai tất cả hằng số công khai cho cảm ứng rõ ràng trong
android.os.VibrationEffect
, cụ thể là (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
vàEFFECT_DOUBLE_CLICK
) và tất cả hằng sốPRIMITIVE_*
công khai khả thi cho cảm ứng phong phú trongandroid.os.VibrationEffect.Composition
, cụ thể là (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Một số trong số các nguyên hàm này, chẳng hạn nhưLOW_TICK
vàSPIN
, có thể chỉ khả thi nếu bộ rung có thể hỗ trợ tần số tương đối thấp. - NÊN làm theo hướng dẫn liên kết hằng số công khai trong
android.view.HapticFeedbackConstants
với hằng sốandroid.os.VibrationEffect
được đề xuất, với các mối quan hệ biên độ tương ứng. - NÊN sử dụng các bản đồ hằng số xúc giác được liên kết này.
- NÊN làm theo quy trình đánh giá chất lượng
cho API
createOneShot()
vàcreateWaveform()
. - NÊN xác minh rằng kết quả của API
android.os.Vibrator.hasAmplitudeControl()
công khai phản ánh chính xác khả năng của bộ rung. - NÊN xác minh các chức năng để mở rộng quy mô độ lớn bằng cách chạy
android.os.Vibrator.hasAmplitudeControl()
.
Nếu việc triển khai thiết bị tuân theo ánh xạ hằng số xúc giác, thì:
- NÊN xác minh trạng thái triển khai bằng cách chạy các API
android.os.Vibrator.areAllEffectsSupported()
vàandroid.os.Vibrator.arePrimitivesSupported()
. - NÊN thực hiện đánh giá chất lượng cho các hằng số xúc giác.
- NÊN xác minh và cập nhật cấu hình dự phòng cho các loại dữ liệu gốc không được hỗ trợ nếu cần, như mô tả trong hướng dẫn triển khai cho các hằng số.
- NÊN cung cấp tính năng hỗ trợ dự phòng để giảm nguy cơ thất bại như mô tả tại đây.
Kết thúc các yêu cầu mới
Xem Mục 2.2.1 để biết các yêu cầu dành riêng cho thiết bị.
7.11. Lớp hiệu suất nội dung nghe nhìn
Bạn có thể lấy lớp hiệu suất nội dung nghe nhìn của quá trình triển khai thiết bị từ API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. Các yêu cầu đối với lớp hiệu suất nội dung nghe nhìn được xác định cho từng phiên bản Android, bắt đầu từ phiên bản R (phiên bản 30). Giá trị đặc biệt là 0 cho biết thiết bị không thuộc lớp hiệu suất nội dung nghe nhìn.
Nếu các phương thức triển khai thiết bị trả về giá trị khác 0 cho android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, thì các phương thức đó:
[C-1-1] PHẢI trả về ít nhất một giá trị là
android.os.Build.VERSION_CODES.R
.[C-1-2] PHẢI là cách triển khai thiết bị cầm tay.
[C-1-3] PHẢI đáp ứng tất cả các yêu cầu đối với "Lớp hiệu suất nội dung nghe nhìn" được mô tả trong mục 2.2.7.
Nói cách khác, lớp hiệu suất nội dung nghe nhìn trong Android T chỉ được xác định cho các thiết bị cầm tay ở phiên bản T, S hoặc R.
Xem mục 2.2.7 để biết các yêu cầu cụ thể về thiết bị.
8. Hiệu suất và nguồn điện
Một số tiêu chí về hiệu suất và công suất tối thiểu rất quan trọng đối với trải nghiệm người dùng và ảnh hưởng đến các giả định cơ sở mà nhà phát triển sẽ có khi phát triển ứng dụng.
8.1. Tính nhất quán trong trải nghiệm người dùng
A smooth user interface can be provided to the end user if there are certain minimum requirements to ensure a consistent frame rate and response times for applications and games. Device implementations, depending on the device type, MAY have measurable requirements for the user interface latency and switching tasks as described in section 2.
8.2. Hiệu suất truy cập I/O tệp
Việc cung cấp một đường cơ sở chung cho hiệu suất truy cập tệp nhất quán trên bộ nhớ dữ liệu riêng của ứng dụng (phân vùng /data
) cho phép nhà phát triển ứng dụng đặt ra kỳ vọng phù hợp để giúp thiết kế phần mềm của họ. Device
implementations, depending on the device type, MAY have certain requirements
described in section 2 for the following
and write operations:
- Sequential write performance. Measured by writing a 256MB file using 10MB write buffer.
- Random write performance. Đo lường bằng cách ghi tệp 256 MB bằng vùng đệm ghi 4 KB.
- Sequential read performance. Measured by reading a 256MB file using 10MB write buffer.
- Random read performance. Measured by reading a 256MB file using 4KB write buffer.
8.3. Chế độ tiết kiệm pin
Nếu các phương thức triển khai thiết bị bao gồm các tính năng để cải thiện khả năng quản lý nguồn điện của thiết bị có trong AOSP (ví dụ: Vùng chờ ứng dụng, Chế độ nghỉ) hoặc mở rộng các tính năng để áp dụng các quy định hạn chế nghiêm ngặt hơn so với Vùng chờ ứng dụng BỊ HẠN CHẾ, thì các phương thức đó:
- [C-1-1] KHÔNG ĐƯỢC khác với cách triển khai AOSP đối với các thuật toán kích hoạt, duy trì, đánh thức và sử dụng chế độ cài đặt hệ thống chung hoặc DeviceConfig của chế độ tiết kiệm pin App Standby và Doze.
- [C-1-2] KHÔNG ĐƯỢC khác với cách triển khai AOSP để sử dụng chế độ cài đặt chung hoặc DeviceConfig nhằm quản lý việc điều tiết công việc, chuông báo và mạng cho các ứng dụng trong mỗi bộ chứa cho chế độ Chờ ứng dụng.
- [C-1-3] KHÔNG ĐƯỢC khác với cách triển khai AOSP về số lượng Bộ chứa chế độ chờ ứng dụng dùng cho Chế độ chờ ứng dụng.
- [C-1-4] MUST implement App Standby Buckets and Doze as described in Power Management.
- [C-1-5] PHẢI trả về
true
choPowerManager.isPowerSaveMode()
khi thiết bị ở chế độ tiết kiệm pin. - [C-1-6] PHẢI cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn khỏi chế độ tiết kiệm pin Chế độ chờ ứng dụng và Chế độ nghỉ hoặc bất kỳ tính năng tối ưu hoá pin nào và PHẢI triển khai ý định ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS để yêu cầu người dùng cho phép một ứng dụng bỏ qua tính năng tối ưu hoá pin.
- [C-SR-1] Bạn NÊN cung cấp cho người dùng khả năng bật và tắt tính năng tiết kiệm pin.
- [C-SR-2] Bạn NÊN cung cấp cho người dùng khả năng hiển thị tất cả ứng dụng được miễn trừ khỏi chế độ tiết kiệm pin App Standby và Doze.
Nếu việc triển khai thiết bị mở rộng các tính năng quản lý nguồn điện có trong AOSP và tiện ích đó áp dụng các hạn chế nghiêm ngặt hơn so với Bộ chứa chế độ chờ ứng dụng hiếm, hãy tham khảo phần 3.5.1.
In addition to the power-saving modes, Android device implementations MAY implement any or all of the 4 sleeping power states as defined by the Advanced Configuration and Power Interface (ACPI).
If device implementations implement S4 power states as defined by the ACPI, they:
- [C-1-1] CHỈ ĐƯỢC chuyển sang trạng thái này sau khi người dùng thực hiện một hành động rõ ràng để đưa thiết bị vào trạng thái không hoạt động (ví dụ: bằng cách đóng nắp vốn là một phần của thiết bị hoặc tắt xe hoặc tivi) và trước khi người dùng kích hoạt lại thiết bị (ví dụ: bằng cách mở nắp hoặc bật lại xe hoặc tivi).
If device implementations implement S3 power states as defined by the ACPI, they:
[C-2-1] PHẢI đáp ứng C-1-1 ở trên, hoặc PHẢI chỉ chuyển sang trạng thái S3 khi các ứng dụng bên thứ ba không cần tài nguyên hệ thống (ví dụ: màn hình, CPU).
Ngược lại, PHẢI thoát khỏi trạng thái S3 khi các ứng dụng bên thứ ba cần tài nguyên hệ thống, như mô tả trong SDK này.
Ví dụ: trong khi các ứng dụng bên thứ ba yêu cầu giữ màn hình bật thông qua
FLAG_KEEP_SCREEN_ON
hoặc giữ CPU chạy thông quaPARTIAL_WAKE_LOCK
, thiết bị KHÔNG ĐƯỢC chuyển sang trạng thái S3, trừ phi như mô tả trong C-1-1, người dùng đã thực hiện hành động rõ ràng để đưa thiết bị vào trạng thái không hoạt động. Ngược lại, tại thời điểm một tác vụ mà các ứng dụng bên thứ ba triển khai thông qua JobScheduler được kích hoạt hoặc Firebase Cloud Messaging được phân phối đến các ứng dụng bên thứ ba, thiết bị PHẢI thoát khỏi trạng thái S3 trừ phi người dùng đã đặt thiết bị ở trạng thái không hoạt động. Đây không phải là các ví dụ toàn diện và AOSP triển khai các tín hiệu đánh thức rộng rãi để kích hoạt chế độ đánh thức từ trạng thái này.
8.4. Tính năng Power Consumption Accounting
A more accurate accounting and reporting of the power consumption provides the app developer both the incentives and the tools to optimize the power usage pattern of the application.
Device implementations:
- [C-SR-1] STRONGLY RECOMMENDED to provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
- [C-SR-2] STRONGLY RECOMMENDED to report all power consumption values in milliampere hours (mAh).
- [C-SR-3] STRONGLY RECOMMENDED to report CPU power consumption per each process's UID.
The Android Open Source Project meets the requirement through the
uid_cputime
kernel module implementation. - [C-SR-4] STRONGLY RECOMMENDED to make this power usage available via the
adb shell dumpsys batterystats
shell command to the app developer. - SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
8.5. Hiệu suất nhất quán
Hiệu suất có thể biến động mạnh đối với các ứng dụng chạy trong thời gian dài và có hiệu suất cao, do các ứng dụng khác chạy ở chế độ nền hoặc do CPU điều tiết do giới hạn nhiệt độ. Android bao gồm các giao diện lập trình để khi thiết bị có khả năng, ứng dụng trên nền trước hàng đầu có thể yêu cầu hệ thống tối ưu hoá việc phân bổ tài nguyên để giải quyết những biến động như vậy.
Device implementations:
[C-0-1] MUST report the support of Sustained Performance Mode accurately through the
PowerManager.isSustainedPerformanceModeSupported()
API method.SHOULD support Sustained Performance Mode.
If device implementations report support of Sustained Performance Mode, they:
- [C-1-1] PHẢI cung cấp cho ứng dụng trên nền trước hàng đầu 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] MUST honor the
Window.setSustainedPerformanceMode()
API and other related APIs.
If device implementations include two or more CPU cores, they:
- SHOULD provide at least one exclusive core that can be reserved by the top foreground application.
If device implementations support reserving one exclusive core for the top foreground application, they:
- [C-2-1] MUST report through the
Process.getExclusiveCores()
API method the ID numbers of the exclusive cores that can be reserved by the top foreground application. - [C-2-2] KHÔNG được cho phép bất kỳ quy trình nào trong không gian người dùng (ngoại trừ trình điều khiển thiết bị mà ứng dụng sử dụng) chạy trên các lõi độc quyền, nhưng CÓ THỂ cho phép một số quy trình hạt nhân chạy khi cần.
If device implementations do not support an exclusive core, they:
- [C-3-1] PHẢI trả về một danh sách trống thông qua phương thức API
Process.getExclusiveCores()
.
9. Khả năng tương thích với mô hình bảo mật
Device implementations:
[C-0-1] MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs in the Android developer documentation.
[C-0-2] PHẢI hỗ trợ cài đặt ứng dụng tự ký mà không yêu cầu thêm quyền/giấy chứng nhận nào từ bên thứ ba/cơ quan.
If device implementations declare the android.hardware.security.model.compatible
feature, they:
- [C-1-1] PHẢI hỗ trợ các yêu cầu được liệt kê trong các tiểu mục sau.
9.1. Quyền
Device implementations:
[C-0-1] MUST support the Android permissions model and Android Roles Model as defined in the Android developer documentation. Cụ thể, các ứng dụng này KHÔNG ĐƯỢC bỏ qua, thay đổi hoặc bỏ qua bất kỳ quyền và vai trò nào được xác định như mô tả trong tài liệu SDK.
MAY add additional permissions, provided the new permission ID strings are not in the
android.\*
namespace.[C-0-2] Quyền có
protectionLevel
làPROTECTION_FLAG_PRIVILEGED
CHỈ được cấp cho các ứng dụng được cài đặt sẵn trong(các) đường dẫn đặc quyền của hình ảnh hệ thống (cũng như tệp APEX) và nằm trong nhóm nhỏ các quyền được liệt kê trong danh sách cho phép rõ ràng cho mỗi ứng dụng. Việc triển khai AOSP đáp ứng yêu cầu này bằng cách đọc và tuân thủ các quyền được liệt kê trong danh sách cho phép cho mỗi ứng dụng từ các tệp trong đường dẫnetc/permissions/
và sử dụng đường dẫnsystem/priv-app
làm đường dẫn đặc quyền.
Các quyền có mức độ bảo vệ nguy hiểm là quyền khi bắt đầu chạy.
Các ứng dụng có targetSdkVersion
> 22 sẽ yêu cầu các quyền này trong thời gian chạy.
Device implementations:
- [C-0-3] PHẢI hiển thị một giao diện chuyên dụng để người dùng quyết định có cấp các quyền khi bắt đầu chạy được yêu cầu hay không, đồng thời cung cấp một giao diện để người dùng quản lý các quyền khi bắt đầu chạy.
- [C-0-4] PHẢI có một và chỉ một cách triển khai cả hai giao diện người dùng.
[C-0-5] KHÔNG ĐƯỢC cấp bất kỳ quyền khi bắt đầu chạy nào cho ứng dụng trừ phi:
- Các ứng dụng này được cài đặt tại thời điểm vận chuyển thiết bị VÀ
Bạn có thể lấy sự đồng ý của người dùng trước khi ứng dụng sử dụng quyền này,
HOẶC
Quyền khi bắt đầu chạy được cấp theo chính sách cấp quyền mặc định hoặc để giữ một vai trò trên nền tảng.
[C-0-6] PHẢI cấp quyền
android.permission.RECOVER_KEYSTORE
chỉ cho các ứng dụng hệ thống đăng ký một Recovery Agent được bảo mật đúng cách. Một Agent khôi phục được bảo mật đúng cách được xác định là một agent phần mềm trên thiết bị đồng bộ hoá với một bộ nhớ từ xa ngoài thiết bị, được trang bị phần cứng bảo mật có khả năng bảo vệ tương đương hoặc mạnh hơn so với nội dung mô tả trong Dịch vụ Google Cloud Key Vault để ngăn chặn các cuộc tấn công bằng phương thức brute-force vào yếu tố tri thức trên màn hình khoá.
Device implementations:
[C-0-7] PHẢI tuân thủ các thuộc tính quyền truy cập thông tin vị trí của Android khi một ứng dụng yêu cầu dữ liệu vị trí hoặc hoạt động thể chất thông qua API Android tiêu chuẩn hoặc cơ chế độc quyền. Dữ liệu đó bao gồm nhưng không giới hạn ở:
- Vị trí của thiết bị (ví dụ: vĩ độ và kinh độ) như mô tả trong phần 9.8.8.
- Thông tin có thể dùng để xác định hoặc ước tính vị trí của thiết bị (ví dụ: SSID, BSSID, Mã nhận dạng ô hoặc vị trí của mạng mà thiết bị kết nối).
- Hoạt động thể chất của người dùng hoặc cách phân loại hoạt động thể chất.
Cụ thể hơn, việc triển khai thiết bị:
- [C-0-8] PHẢI có sự đồng ý của người dùng để cho phép ứng dụng truy cập vào dữ liệu vị trí hoặc hoạt động thể chất.
- [C-0-9] CHỈ được cấp quyền khi bắt đầu chạy cho ứng dụng có quyền đầy đủ như mô tả trên SDK.
Ví dụ: TelephonyManager#getServiceState yêu cầu
android.permission.ACCESS_FINE_LOCATION
).
Các trường hợp ngoại lệ duy nhất đối với các thuộc tính quyền truy cập thông tin vị trí trên Android là dành cho các ứng dụng không truy cập vào Thông tin vị trí để lấy hoặc xác định vị trí của người dùng; cụ thể:
- Khi ứng dụng có quyền
RADIO_SCAN_WITHOUT_LOCATION
. - Đối với mục đích thiết lập và định cấu hình thiết bị, trong đó các ứng dụng hệ thống giữ quyền
NETWORK_SETTINGS
hoặcNETWORK_SETUP_WIZARD
.
Bạn có thể đánh dấu quyền là bị hạn chế để thay đổi hành vi của quyền đó.
[C-0-10] KHÔNG ĐƯỢC cấp quyền được đánh dấu bằng cờ
hardRestricted
cho một ứng dụng, trừ phi:- Tệp APK của ứng dụng nằm trong phân vùng hệ thống.
- Người dùng chỉ định một vai trò liên kết với các quyền
hardRestricted
cho một ứng dụng. - Trình cài đặt cấp
hardRestricted
cho một ứng dụng. - Ứng dụng được cấp
hardRestricted
trên một phiên bản Android cũ.
[C-0-11] Ứng dụng có quyền
softRestricted
CHỈ ĐƯỢC quyền truy cập hạn chế và KHÔNG ĐƯỢC quyền truy cập đầy đủ cho đến khi được đưa vào danh sách cho phép như mô tả trong SDK, trong đó quyền truy cập đầy đủ và hạn chế được xác định cho từng quyềnsoftRestricted
(ví dụ:READ_EXTERNAL_STORAGE
).[C-0-12] KHÔNG ĐƯỢC cung cấp bất kỳ hàm hoặc API tuỳ chỉnh nào để bỏ qua các hạn chế về quyền được xác định trong API setPermissionPolicy và setPermissionGrantState.
[C-0-13] PHẢI sử dụng các API AppOpsManager để ghi lại và theo dõi mọi hoạt động truy cập có lập trình vào dữ liệu được bảo vệ bằng các quyền nguy hiểm từ các hoạt động và dịch vụ Android.
[C-0-14] CHỈ ĐƯỢC chỉ định vai trò cho các ứng dụng có chức năng đáp ứng các yêu cầu về vai trò.
[C-0-15] KHÔNG được xác định các vai trò trùng lặp hoặc chức năng tập hợp con của các vai trò do nền tảng xác định.
If devices report android.software.managed_users
, they:
- [C-1-1] KHÔNG ĐƯỢC để quản trị viên cấp các quyền sau đây một cách thầm lặng:
- Vị trí (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Máy ảnh (CAMERA)
- Micrô (RECORD_AUDIO)
- Cảm biến cơ thể (BODY_SENSORS)
- Hoạt động thể chất (ACTIVITY_RECOGNITION)
Nếu việc triển khai thiết bị cung cấp cho người dùng khả năng chọn ứng dụng nào có thể vẽ lên các ứng dụng khác bằng một hoạt động xử lý ý định ACTION_MANAGE_OVERLAY_PERMISSION
, thì các ứng dụng đó:
- [C-2-1] PHẢI đảm bảo rằng tất cả hoạt động có bộ lọc ý định cho ý định
ACTION_MANAGE_OVERLAY_PERMISSION
đều có cùng một màn hình giao diện người dùng, bất kể ứng dụng khởi tạo hoặc bất kỳ thông tin nào mà ứng dụng đó cung cấp.
If device implementations report android.software.device_admin, they:
- [C-3-1] PHẢI hiển thị tuyên bố từ chối trách nhiệm trong quá trình thiết lập thiết bị được quản lý toàn diện (thiết lập chủ sở hữu thiết bị) cho biết rằng quản trị viên CNTT sẽ có thể cho phép ứng dụng kiểm soát các chế độ cài đặt trên điện thoại, bao gồm cả micrô, máy ảnh và vị trí, với các lựa chọn để người dùng tiếp tục thiết lập hoặc thoát khỏi quy trình thiết lập, TRỪ phi quản trị viên đã chọn không kiểm soát các quyền trên thiết bị.
Nếu quá trình triển khai thiết bị cài đặt trước bất kỳ gói nào chứa vai trò Trí tuệ giao diện người dùng hệ thống, Trí tuệ âm thanh môi trường xung quanh hệ thống, Trí tuệ âm thanh hệ thống, Trí tuệ thông báo hệ thống, Trí tuệ văn bản hệ thống hoặc Trí tuệ hình ảnh hệ thống, thì các gói đó:
- [C-4-1] PHẢI đáp ứng tất cả các yêu cầu được nêu cho việc triển khai thiết bị trong các phần
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] KHÔNG ĐƯỢC có quyền android.permission.INTERNET. Điều này nghiêm ngặt hơn mức ĐỀ XUẤT MẠNH nêu trong mục 9.8.6.
- [C-4-3] KHÔNG ĐƯỢC liên kết với các ứng dụng khác, ngoại trừ các ứng dụng hệ thống sau: Bluetooth, Danh bạ, Nội dung nghe nhìn, Điện thoại, SystemUI và các thành phần cung cấp API Internet. Yêu cầu này nghiêm ngặt hơn mức KHUYẾN KHÍCH MẠNH nêu trong phần 9.8.6.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị bao gồm một ứng dụng mặc định để hỗ trợ VoiceInteractionService
, thì các phương thức đó:
- [C-5-1] KHÔNG ĐƯỢC cấp
ACCESS_FINE_LOCATION
làm mặc định cho ứng dụng đó.
Kết thúc các yêu cầu mới
9.2. UID và cách ly quy trình
Device implementations:
- [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 kiểu Unix duy nhất và trong một quy trình riêng biệt.
- [C-0-2] PHẢI hỗ trợ chạy nhiều ứng dụng với cùng một mã nhận dạng người dùng Linux, miễn là các ứng dụng đó được ký và tạo đúng cách, như được xác định trong Tài liệu tham khảo về quyền và bảo mật.
9.3. Quyền đối với hệ thống tệp
Device implementations:
- [C-0-1] PHẢI hỗ trợ mô hình quyền truy cập vào tệp Android như được xác định trong tài liệu tham khảo về Bảo mật và quyền.
9.4. Môi trường thực thi thay thế
Device implementations MUST keep consistency of the Android security and permission model, even if they include runtime environments that execute applications using some other software or technology than the Dalvik Executable Format or native code. Hay nói cách khác:
[C-0-1] Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in section 9.
[C-0-2] Không được cấp cho môi trường thời gian chạy thay thế quyền truy cập vào các tài nguyên được bảo vệ bằng các quyền không được yêu cầu trong tệp
AndroidManifest.xml
của môi trường thời gian chạy thông qua cơ chế <uses-permission
>.[C-0-3] Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.
[C-0-4] Alternate runtimes MUST abide by the Android sandbox model and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate.
[C-0-5] Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.
[C-0-6] Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.
[C-0-7] Khi các tệp
.apk
của môi trường thời gian chạy thay thế được đưa vào hình ảnh hệ thống của các hoạt động triển khai thiết bị, tệp đó PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng khác đi kèm với các hoạt động triển khai thiết bị.[C-0-8] Khi cài đặt ứng dụng, môi trường thời gian chạy thay thế PHẢI thu thập sự đồng ý của người dùng đối với các quyền trên Android mà ứng dụng sử dụng.
[C-0-9] Khi một ứng dụng cần sử dụng tài nguyên thiết bị có quyền tương ứng trên Android (chẳng hạn như Máy ảnh, GPS, v.v.), môi trường thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng sẽ có thể truy cập vào tài nguyên đó.
[C-0-10] Khi môi trường thời gian chạy không ghi lại các chức năng của ứng dụng theo cách này, môi trường thời gian chạy PHẢI liệt kê tất cả các quyền mà chính môi trường thời gian chạy nắm giữ khi cài đặt bất kỳ ứng dụng nào sử dụng môi trường thời gian chạy đó.
Alternate runtimes SHOULD install apps via the
PackageManager
into separate Android sandboxes (Linux user IDs, etc.).Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
9.5. Hỗ trợ nhiều người dùng
Android bao gồm hỗ trợ nhiều người dùng và hỗ trợ tính năng tách biệt người dùng hoàn toàn cũng như nhân bản hồ sơ người dùng với tính năng tách biệt một phần(tức là một hồ sơ người dùng bổ sung thuộc loại android.os.usertype.profile.CLONE
).
- Device implementations MAY but SHOULD NOT enable multi-user if they use removable media for primary external storage.
If device implementations include support for multiple users, they:
- [C-1-2] MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs.
- [C-1-3] PHẢI có các thư mục bộ nhớ ứng dụng dùng chung riêng biệt và tách biệt (còn gọi là
/sdcard
) cho mỗi phiên bản người dùng. - [C-1-4] PHẢI đảm bảo rằng các ứng dụng thuộc sở hữu và chạy thay mặt cho một người dùng nhất định không thể liệt kê, đọc hoặc ghi vào các tệp thuộc sở hữu của người dùng 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 phương tiện hoặc hệ thống tệp.
- [C-1-5] PHẢI mã hoá nội dung của thẻ SD khi 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 thể tháo rời mà chỉ hệ thống mới truy cập được nếu các phương thức triển khai thiết bị sử dụng phương tiện có thể tháo rời cho API bộ nhớ ngoài. Vì điều này sẽ khiến máy tính lưu trữ không đọc được nội dung nghe nhìn, nên các hoạt động triển khai thiết bị sẽ phải chuyển sang MTP hoặc một hệ thống tương tự để cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại.
Nếu quá trình triển khai thiết bị hỗ trợ nhiều người dùng, thì đối với tất cả người dùng ngoại trừ người dùng được tạo riêng để chạy các phiên bản song song của cùng một ứng dụng, họ sẽ:
- [C-2-1] PHẢI có các thư mục bộ nhớ ứng dụng dùng chung riêng biệt và tách biệt (còn gọi là /sdcard) cho mỗi phiên bản người dùng.
- [C-2-2] PHẢI đảm bảo rằng các ứng dụng thuộc quyền sở hữu và chạy thay mặt cho một người dùng nhất định không thể liệt kê, đọc hoặc ghi vào các tệp thuộc quyền 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 phương tiện hoặc hệ thống tệp.
Việc triển khai thiết bị CÓ THỂ tạo một hồ sơ người dùng bổ sung duy nhất thuộc loại android.os.usertype.profile.CLONE
đối với người dùng chính (và chỉ đối với người dùng chính) nhằm mục đích chạy các phiên bản song song của cùng một ứng dụng. Các phiên bản song song này chia sẻ bộ nhớ được tách biệt một phần, được trình chạy hiển thị cho người dùng cuối cùng cùng một lúc và xuất hiện trong cùng một chế độ xem gần đây.
Ví dụ: bạn có thể dùng tính năng này để hỗ trợ người dùng cài đặt hai phiên bản riêng biệt của một ứng dụng trên thiết bị có hai SIM.
Nếu các phương thức triển khai thiết bị tạo hồ sơ người dùng bổ sung như đã thảo luận ở trên, thì các phương thức đó:
- [C-3-1] CHỈ được cung cấp quyền truy cập vào bộ nhớ hoặc dữ liệu mà hồ sơ người dùng gốc đã có thể truy cập hoặc do hồ sơ người dùng bổ sung này trực tiếp sở hữu.
- [C-3-2] KHÔNG ĐƯỢC đặt làm hồ sơ công việc.
- [C-3-3] PHẢI tách riêng các thư mục dữ liệu ứng dụng riêng tư khỏi tài khoản người dùng gốc.
- [C-3-4] KHÔNG ĐƯỢC cho phép tạo hồ sơ người dùng bổ sung nếu có Chủ sở hữu thiết bị được cấp phép (xem phần 3.9.1) hoặc cho phép cấp phép Chủ sở hữu thiết bị mà không xoá hồ sơ người dùng bổ sung trước.
Bắt đầu yêu cầu mới
Nếu các phương thức triển khai thiết bị tạo hồ sơ người dùng bổ sung như đã thảo luận ở trên, thì các phương thức đó:
- [C-4-5] PHẢI phân biệt rõ ràng các biểu tượng ứng dụng phiên bản kép khi biểu tượng được hiển thị cho người dùng.
- [C-4-6] PHẢI cung cấp cho người dùng khả năng xoá toàn bộ dữ liệu hồ sơ của bản sao.
- [C-4-7] PHẢI gỡ cài đặt tất cả ứng dụng Clone, xoá thư mục dữ liệu ứng dụng riêng tư và nội dung của các thư mục đó, đồng thời xoá dữ liệu hồ sơ Clone khi người dùng chọn xoá toàn bộ dữ liệu hồ sơ Clone.
- NÊN nhắc người dùng xoá toàn bộ dữ liệu Hồ sơ sao chép khi ứng dụng sao chép cuối cùng bị xoá.
- [C-4-8] PHẢI thông báo cho người dùng rằng dữ liệu ứng dụng sẽ bị xoá khi ứng dụng bản sao bị gỡ cài đặt, hoặc cung cấp cho người dùng lựa chọn giữ lại dữ liệu ứng dụng khi ứng dụng bị gỡ cài đặt khỏi thiết bị.
- [C-4-9] PHẢI xoá các thư mục dữ liệu ứng dụng riêng tư và nội dung của các thư mục đó khi người dùng chọn xoá dữ liệu trong quá trình gỡ cài đặt.
[C-4-1] PHẢI cho phép các ứng dụng của người dùng chính trên thiết bị xử lý các ý định dưới đây bắt nguồn từ hồ sơ bổ sung:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] PHẢI kế thừa tất cả các quy định hạn chế đối với người dùng trong chính sách thiết bị và các quy định hạn chế không phải đối với người dùng(danh sách bên dưới) được áp dụng cho người dùng chính của thiết bị đối với hồ sơ người dùng bổ sung này.
[C-4-3] CHỈ ĐƯỢC cho phép ghi danh bạ từ hồ sơ bổ sung này thông qua các ý định sau:
[C-4-4] KHÔNG ĐƯỢC chạy tính năng đồng bộ hoá danh bạ cho các ứng dụng chạy trong hồ sơ người dùng bổ sung này.
- [C-4-14] PHẢI có quyền và chế độ quản lý bộ nhớ riêng biệt cho các ứng dụng chạy trong hồ sơ bổ sung này
- [C-4-5] CHỈ được cho phép các ứng dụng trong hồ sơ bổ sung có hoạt động trình chạy truy cập vào những người liên hệ mà hồ sơ người dùng chính có thể truy cập.
Kết thúc các yêu cầu mới
9.6. Cảnh báo về tin nhắn dịch vụ
Android hỗ trợ cảnh báo người dùng về mọi tin nhắn SMS trả phí gửi đi. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user.
If device implementations declare support for android.hardware.telephony
,
they:
- [C-1-1] PHẢI cảnh báo người dùng trước khi gửi tin nhắn SMS đến các số điện thoại được xác định bằng biểu thức chính quy được xác định trong tệp
/data/misc/sms/codes.xml
trên thiết bị. The upstream Android Open Source Project provides an implementation that satisfies this requirement.
9.7. Các tính năng bảo mật
Device implementations MUST ensure compliance with security features in both the kernel and platform as described below.
Hộp cát Android bao gồm các tính năng sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) của Security-Enhanced Linux (SELinux), hộp cát seccomp và các tính năng bảo mật khác trong hạt nhân Linux. Device implementations:
- [C-0-1] MUST maintain compatibility with existing applications, even when SELinux or any other security features are implemented below the Android framework.
- [C-0-2] KHÔNG ĐƯỢC có giao diện người dùng hiển thị khi một lỗi vi phạm bảo mật được phát hiện và bị tính năng bảo mật được triển khai bên dưới khung Android chặn thành công, nhưng CÓ THỂ có giao diện người dùng hiển thị khi một lỗi vi phạm bảo mật không bị chặn xảy ra và dẫn đến việc khai thác thành công.
- [C-0-3] KHÔNG ĐƯỢC cho phép người dùng hoặc nhà phát triển ứng dụng định cấu hình SELinux hoặc bất kỳ tính năng bảo mật nào khác được triển khai bên dưới khung Android.
- [C-0-4] KHÔNG ĐƯỢC cho phép một ứng dụng có thể ảnh hưởng đến một ứng dụng khác thông qua một API (chẳng hạn như API Quản trị thiết bị) để định cấu hình một chính sách làm mất khả năng tương thích.
- [C-0-5] MUST split the media framework into multiple processes so that it is possible to more narrowly grant access for each process as described in the Android Open Source Project site.
- [C-0-6] PHẢI triển khai cơ chế hộp cát cho ứng dụng hạt nhân cho phép lọc các lệnh gọi hệ thống bằng chính sách có thể định cấu hình từ các chương trình nhiều luồng. The upstream Android Open Source Project meets this requirement through enabling the seccomp-BPF with threadgroup synchronization (TSYNC) as described in the Kernel Configuration section of source.android.com.
Kernel integrity and self-protection features are integral to Android security. Device implementations:
- [C-0-7] PHẢI triển khai các cơ chế bảo vệ tình trạng tràn bộ đệm ngăn xếp nhân.
Ví dụ về các cơ chế như vậy là
CC_STACKPROTECTOR_REGULAR
vàCONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] PHẢI triển khai các biện pháp bảo vệ nghiêm ngặt đối với bộ nhớ nhân trong đó mã thực thi chỉ có thể đọc, dữ liệu chỉ có thể đọc không thể thực thi và không thể ghi, còn dữ liệu có thể ghi không thể thực thi (ví dụ:
CONFIG_DEBUG_RODATA
hoặcCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] PHẢI triển khai tính năng kiểm tra giới hạn kích thước đối tượng tĩnh và động của các bản sao giữa không gian người dùng và không gian hạt nhân (ví dụ:
CONFIG_HARDENED_USERCOPY
) trên các thiết bị ban đầu được vận chuyển với API cấp 28 trở lên. - [C-0-10] KHÔNG ĐƯỢC thực thi bộ nhớ không gian người dùng khi thực thi ở chế độ hạt nhân (ví dụ: PXN phần cứng hoặc được mô phỏng qua
CONFIG_CPU_SW_DOMAIN_PAN
hoặcCONFIG_ARM64_SW_TTBR0_PAN
) trên các thiết bị ban đầu được vận chuyển với API cấp 28 trở lên. - [C-0-11] KHÔNG ĐƯỢC đọc hoặc ghi bộ nhớ không gian người dùng trong hạt nhân ngoài các API truy cập usercopy thông thường (ví dụ: PAN phần cứng hoặc được mô phỏng qua
CONFIG_CPU_SW_DOMAIN_PAN
hoặcCONFIG_ARM64_SW_TTBR0_PAN
) trên các thiết bị ban đầu được vận chuyển với API cấp 28 trở lên. - [C-0-12] PHẢI triển khai tính năng tách biệt bảng trang kernel nếu phần cứng dễ bị CVE-2017-5754 tấn công trên tất cả thiết bị ban đầu được vận chuyển với API cấp 28 trở lên (ví dụ:
CONFIG_PAGE_TABLE_ISOLATION
hoặcCONFIG_UNMAP_KERNEL_AT_EL0
). [C-0-13] PHẢI triển khai tính năng tăng cường dự đoán nhánh nếu phần cứng dễ bị CVE-2017-5715 trên tất cả thiết bị ban đầu được vận chuyển với API cấp 28 trở lên (ví dụ:
CONFIG_HARDEN_BRANCH_PREDICTOR
).[C-SR-1] STRONGLY RECOMMENDED to keep kernel data which is written only during initialization marked read-only after initialization (e.g.
__ro_after_init
).[C-SR-2] Bạn STRONGLY RECOMMENDED phải tạo bố cục ngẫu nhiên cho mã hạt nhân và bộ nhớ, đồng thời tránh các trường hợp rò rỉ có thể làm hỏng tính năng tạo bố cục ngẫu nhiên (ví dụ:
CONFIG_RANDOMIZE_BASE
có entropy của trình tải khởi động thông qua/chosen/kaslr-seed Device Tree node
hoặcEFI_RNG_PROTOCOL
).[C-SR-3] Bạn NÊN bật tính năng tính toàn vẹn của luồng điều khiển (CFI) trong hạt nhân để tăng cường bảo vệ chống lại các cuộc tấn công tái sử dụng mã (ví dụ:
CONFIG_CFI_CLANG
vàCONFIG_SHADOW_CALL_STACK
).[C-SR-4] Bạn KHÔNG NÊN tắt tính năng Tính toàn vẹn của luồng điều khiển (CFI), Ngăn xếp lệnh gọi bóng (SCS) hoặc Tẩy lỗi tràn số nguyên (IntSan) trên các thành phần đã bật tính năng này.
[C-SR-5] Bạn NÊN bật CFI, SCS và IntSan cho mọi thành phần không gian người dùng nhạy cảm với bảo mật khác như đã giải thích trong CFI và IntSan.
[C-SR-6] Bạn NÊN bật tính năng khởi chạy ngăn xếp trong nhân để ngăn việc sử dụng các biến cục bộ chưa khởi chạy (
CONFIG_INIT_STACK_ALL
hoặcCONFIG_INIT_STACK_ALL_ZERO
). Ngoài ra, việc triển khai thiết bị KHÔNG NÊN giả định giá trị mà trình biên dịch sử dụng để khởi chạy các biến cục bộ.[C-SR-7] Bạn NÊN bật tính năng khởi tạo vùng nhớ khối xếp trong nhân để ngăn việc sử dụng các vùng nhớ khối xếp chưa được khởi tạo (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) và KHÔNG NÊN giả định giá trị mà nhân sử dụng để khởi tạo các vùng nhớ khối xếp đó.
If device implementations use a Linux kernel that is capable of supporting SELinux, they:
- [C-1-1] MUST implement SELinux.
- [C-1-2] MUST set SELinux to global enforcing mode.
- [C-1-3] MUST configure all domains in enforcing mode. Không được phép sử dụng miền ở chế độ cho phép, bao gồm cả miền dành riêng cho một thiết bị/nhà cung cấp.
- [C-1-4] KHÔNG ĐƯỢC sửa đổi, bỏ qua hoặc thay thế các quy tắc neverallow có trong thư mục system/sepolicy được cung cấp trong Dự án nguồn mở Android (AOSP) và chính sách PHẢI biên dịch với tất cả các quy tắc neverallow hiện có, cho cả miền SELinux AOSP cũng như miền dành riêng cho thiết bị/nhà cung cấp.
- [C-1-5] PHẢI chạy các ứng dụng 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 quy định hạn chế SELinux cho mỗi ứng dụng trên thư mục dữ liệu riêng tư của ứng dụng.
- SHOULD retain the default SELinux policy provided in the system/sepolicy folder of the upstream Android Open Source Project and only further add to this policy for their own device-specific configuration.
If device implementations use kernel other than Linux or Linux without SELinux, they:
- [C-2-1] PHẢI sử dụng hệ thống kiểm soát quyền truy cập bắt buộc tương đương với SELinux.
If device implementations use I/O devices capable of DMA, they:
- [C-SR-9] Bạn NÊN tách riêng từng thiết bị I/O có thể thực hiện DMA bằng cách sử dụng IOMMU (ví dụ: ARM SMMU).
Android chứa nhiều tính năng phòng thủ chuyên sâu, là yếu tố không thể thiếu đối với tính bảo mật của thiết bị. Ngoài ra, Android tập trung vào việc giảm các lớp lỗi phổ biến chính góp phần làm giảm chất lượng và độ bảo mật.
Để giảm lỗi bộ nhớ, các phương thức triển khai thiết bị:
- [C-SR-10] Bạn NÊN kiểm thử bằng các công cụ phát hiện lỗi bộ nhớ không gian người dùng như MTE cho thiết bị ARMv9, HWASan cho thiết bị ARMv8 trở lên hoặc ASan cho các loại thiết bị khác.
- [C-SR-11] Bạn NÊN kiểm thử bằng các công cụ phát hiện lỗi bộ nhớ nhân như KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS cho thiết bị ARMv9, CONFIG_KASAN_SW_TAGS cho thiết bị ARMv8 hoặc CONFIG_KASAN_GENERIC cho các loại thiết bị khác).
- [C-SR-12] Bạn NÊN sử dụng các công cụ phát hiện lỗi bộ nhớ trong bản phát hành công khai như MTE, GWP-ASan và KFENCE.
Nếu các phương thức triển khai thiết bị sử dụng TEE dựa trên Arm TrustZone, thì các phương thức đó:
- [C-SR-13] Bạn NÊN sử dụng giao thức tiêu chuẩn để chia sẻ bộ nhớ giữa Android và TEE, chẳng hạn như Khung phần mềm Arm cho Armv8-A (FF-A).
- [C-SR-14] Bạn NÊN hạn chế các ứng dụng đáng tin cậy chỉ truy cập vào bộ nhớ đã được chia sẻ rõ ràng với các ứng dụng đó thông qua giao thức nêu trên. Nếu thiết bị hỗ trợ cấp độ ngoại lệ Arm S-EL2, thì trình quản lý phân vùng bảo mật sẽ thực thi cấp độ này. Nếu không, hệ điều hành TEE sẽ thực thi điều này.
Bắt đầu yêu cầu mới
Công nghệ An toàn bộ nhớ là công nghệ giúp giảm thiểu ít nhất các loại lỗi sau đây với xác suất cao (> 90%) trong các ứng dụng sử dụng tuỳ chọn tệp kê khai android:memtagMode
:
- tràn vùng đệm vùng nhớ khối xếp
- sử dụng sau khi giải phóng
- giải phóng hai lần
- giải phóng không hợp lệ (không có con trỏ không phải malloc)
Device implementations:
- [C-SR-15] Bạn NÊN đặt
ro.arm64.memtag.bootctl_supported
.
Nếu các phương thức triển khai thiết bị đặt thuộc tính hệ thống ro.arm64.memtag.bootctl_supported
thành true, thì các phương thức đó:
[C-3-1] PHẢI cho phép thuộc tính hệ thống
arm64.memtag.bootctl
chấp nhận một danh sách được phân tách bằng dấu phẩy gồm các giá trị sau, với hiệu ứng mong muốn được áp dụng trong lần khởi động lại tiếp theo:memtag
: công nghệ An toàn bộ nhớ như đã xác định ở trên được bậtmemtag-once
: một công nghệ An toàn bộ nhớ như đã xác định ở trên sẽ được bật tạm thời và tự động tắt sau lần khởi động lại tiếp theomemtag-off
: một công nghệ An toàn bộ nhớ như đã xác định ở trên bị tắt
[C-3-2] PHẢI cho phép người dùng shell đặt
arm64.memtag.bootctl
.[C-3-3] PHẢI cho phép mọi quy trình đọc
arm64.memtag.bootctl
.[C-3-4] PHẢI đặt
arm64.memtag.bootctl
thành trạng thái hiện được yêu cầu khi khởi động, đồng thời PHẢI cập nhật thuộc tính này nếu việc triển khai thiết bị cho phép sửa đổi trạng thái mà không thay đổi thuộc tính hệ thống.[C-SR-16] Bạn NÊN hiển thị một phần Cài đặt cho nhà phát triển để đặt memtag-once và khởi động lại thiết bị. Với trình tải khởi động tương thích, Dự án nguồn mở Android đáp ứng các yêu cầu nêu trên thông qua giao thức trình tải khởi động MTE.
- [C-SR-17] Bạn NÊN hiển thị một chế độ cài đặt trong trình đơn Cài đặt bảo mật cho phép người dùng bật
memtag
.
Kết thúc các yêu cầu mới
9.8. Quyền riêng tư
9.8.1. Nhật ký sử dụng
Android stores the history of the user's choices and manages such history by UsageStatsManager.
Device implementations:
- [C-0-1] MUST keep a reasonable retention period of such user history.
- [C-SR-1] Are STRONGLY RECOMMENDED to keep the 14 days retention period as configured by default in the AOSP implementation.
Android lưu trữ các sự kiện hệ thống bằng giá trị nhận dạng StatsLog
và quản lý nhật ký đó thông qua StatsManager
và API Hệ thống IncidentManager
.
Device implementations:
- [C-0-2] MUST only include the fields marked with
DEST_AUTOMATIC
in the incident report created by the System API classIncidentManager
. - [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 khác được ghi lại, thì các sự kiện đó CÓ THỂ sử dụng một giá trị nhận dạng nguyên tử khác trong khoảng từ 100.000 đến 200.000.
9.8.2. Đang ghi
Device implementations:
- [C-0-1] KHÔNG ĐƯỢC tải trước hoặc phân phối các thành phần phần mềm ngay từ đầu có chức năng gửi thông tin riêng tư của người dùng (ví dụ: thao tác nhấn phím, văn bản hiển thị trên màn hình, báo cáo lỗi) ra khỏi thiết bị mà không có sự đồng ý của người dùng hoặc thông báo rõ ràng liên tục.
- [C-0-2] PHẢI hiển thị cảnh báo cho người dùng và có được sự đồng ý rõ ràng của người dùng cho phép ghi lại mọi thông tin nhạy cảm xuất hiện trên màn hình của người dùng
, bao gồm chính xác thông báo giống như AOSPbất cứ khi nàomỗi khi một phiên để ghi lại màn hìnhtruyền hoặc quay màn hìnhđược bậtbắt đầu thông quaMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
hoặc các API độc quyền.KHÔNG ĐƯỢC cung cấp cho người dùng cơ hội tắt chế độ hiển thị sự đồng ý của người dùng trong tương lai. - [C-0-3] PHẢI có thông báo liên tục cho người dùng trong khi tính năng truyền màn hình hoặc quay màn hình đang bật. AOSP đáp ứng yêu cầu này bằng cách hiển thị biểu tượng thông báo đang diễn ra trong thanh trạng thái.
Bắt đầu yêu cầu mới
[C-SR-1] Bạn NÊN hiển thị cảnh báo cho người dùng. Đây chính xác là thông báo được triển khai trong AOSP nhưng CÓ THỂ được thay đổi miễn là thông báo cảnh báo rõ ràng cho người dùng rằng mọi thông tin nhạy cảm trên màn hình của người dùng đều được ghi lại.
[C-0-4] KHÔNG ĐƯỢC cung cấp cho người dùng cơ hội tắt các lời nhắc trong tương lai về việc người dùng đồng ý chụp ảnh màn hình, trừ phi phiên được bắt đầu bằng một ứng dụng hệ thống mà người dùng đã cho phép
associate()
bằng hồ sơ thiết bịandroid.app.role.COMPANION_DEVICE_APP_STREAMING
hoặcandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
.Kết thúc các yêu cầu mới
Nếu các phương thức triển khai thiết bị bao gồm chức năng trong hệ thống giúp 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 phát trên thiết bị không phải thông qua ContentCaptureService
API hệ thống hoặc các phương tiện độc quyền khác được mô tả trong Mục 9.8.6 Dữ liệu môi trường xung quanh và cấp hệ điều hành, thì các phương thức đó:
- [C-1-1] PHẢI có thông báo liên tục cho người dùng bất cứ khi nào chức năng này được bật và đang chụp/ghi.
If device implementations include a component enabled out-of-box, capable of recording ambient audio and/or record the audio played on the device to infer useful information about user’s context, they:
- [C-2-1] KHÔNG ĐƯỢC lưu trữ trong bộ nhớ cố định trên thiết bị hoặc truyền ra ngoài thiết bị âm thanh thô đã ghi hoặc bất kỳ định dạng nào có thể chuyển đổi trở lại âm thanh gốc hoặc bản sao gần giống, trừ khi có sự đồng ý rõ ràng của người dùng.
"Chỉ báo micrô" là một thành phần hiển thị trên màn hình, luôn hiển thị với người dùng và không thể bị che khuất, người dùng hiểu là micrô đang được sử dụng(thông qua văn bản, màu sắc, biểu tượng hoặc một số tổ hợp riêng biệt).
"Chỉ báo máy ảnh" là một thành phần hiển thị trên màn hình mà người dùng luôn nhìn thấy và không thể bị che khuất, giúp người dùng hiểu rằng máy ảnh đang được sử dụng (thông qua văn bản, màu sắc, biểu tượng hoặc một số tổ hợp riêng biệt).
Sau khi hiển thị một giây đầu tiên, chỉ báo có thể thay đổi về mặt hình ảnh, chẳng hạn như nhỏ hơn và không bắt buộc phải hiển thị như ban đầu được trình bày và hiểu.
Bạn có thể hợp nhất chỉ báo micrô với chỉ báo máy ảnh đang hiển thị, miễn là văn bản, biểu tượng hoặc màu sắc cho người dùng biết rằng việc sử dụng micrô đã bắt đầu.
Bạn có thể hợp nhất chỉ báo máy ảnh với chỉ báo micrô đang hiển thị, miễn là văn bản, biểu tượng hoặc màu sắc cho người dùng biết rằng việc sử dụng máy ảnh đã bắt đầu.
If device implementations declare android.hardware.microphone
, they:
- [C-SR-1] Bạn NÊN hiển thị chỉ báo micrô khi một ứng dụng đang truy cập vào dữ liệu âm thanh từ micrô, nhưng không phải khi micrô chỉ được
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
hoặc(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD [C-3-X]. . - [C-SR-2] Bạn NÊN hiển thị danh sách các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng micrô được trả về từ
PermissionManager.getIndicatorAppOpUsageData()
, cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó. - [C-SR-3] Bạn KHÔNG NÊN ẩn chỉ báo micrô cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc tương tác trực tiếp với người dùng.
If device implementations declare android.hardware.camera.any
, they:
- [C-SR-4] Bạn NÊN hiển thị chỉ báo máy ảnh khi một ứng dụng truy cập vào dữ liệu máy ảnh trực tiếp, nhưng không phải khi máy ảnh chỉ được(các) ứng dụng có vai trò được nêu trong Mục 9.1 Quyền có giá trị nhận dạng CDD truy cập [C-3-X].
- [C-SR-5] Bạn NÊN hiển thị các ứng dụng Gần đây và Đang hoạt động bằng cách sử dụng camera được trả về từ
PermissionManager.getIndicatorAppOpUsageData()
, cùng với mọi thông báo phân bổ liên kết với các ứng dụng đó. - [C-SR-6] Bạn KHÔNG NÊN ẩn chỉ báo máy ảnh cho các ứng dụng hệ thống có giao diện người dùng hiển thị hoặc có hoạt động tương tác trực tiếp với người dùng.
9.8.3. Khả năng kết nối
If device implementations have a USB port with USB peripheral mode support, they:
- [C-1-1] PHẢI hiển thị giao diện người dùng yêu cầu người dùng đồng ý trước khi cho phép truy cập vào nội dung của bộ nhớ dùng chung qua cổng USB.
9.8.4. Lưu lượng truy cập mạng
Device implementations:
- [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 ngược dòng.
- [C-0-2] MUST ship wi