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

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

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

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

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

Nhiều tài nguyên được liên kết trong tài liệu này được lấy trực tiếp hoặc gián tiếp từ SDK Android và có chức năng giống với thông tin trong tài liệu của SDK đó. Trong mọi trường hợp mà Định nghĩa về khả năng tương thích này hoặc Bộ kiểm tra tính tương thích không đồng ý với tài liệu về SDK, thì tài liệu về SDK sẽ được coi là có căn cứ đáng tin. Mọi chi tiết kỹ thuật được cung cấp trong các tài nguyên được liên kết thông qua tài liệu này đều được xem xét bằng cách đưa vào Định nghĩa về khả năng tương thích này.

2. Loại thiết bị

Mặc dù Dự án nguồn mở Android đã được sử dụng để triển khai nhiều loại thiết bị và kiểu dáng khác nhau, nhưng nhiều khía cạnh của các yêu cầu về cấu trúc và khả năng tương thích đã được tối ưu hoá cho thiết bị cầm tay. Kể từ Android 5.0, Dự án nguồn mở Android hướng đến việc hỗ trợ nhiều loại thiết bị hơn như được mô tả trong phần này.

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

PHẢI nhúng màn hình cảm ứng trong thiết bị.
PHẢI có nguồn điện giúp đảm bảo khả năng vận động, chẳng hạn như pin.

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

PHẢI có màn hình được nhúng HOẶC có cổng đầu ra video, chẳng hạn như VGA, HDMI hoặc cổng không dây để hiển thị.
PHẢI khai báo các tính năng android.software.leanback và android.hardware.type.television.

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

Phải có một màn hình có chiều dài đường chéo vật lý trong khoảng từ 1,1 đến 2,5 inch.
PHẢI khai báo tính năng android.hardware.type.watch.
PHẢI hỗ trợ uiMode = UI_MODE_TYPE_WATCH.

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

PHẢI có một màn hình có chiều dài đường chéo vật lý bằng hoặc lớn hơn 6 inch.
PHẢI khai báo tính năng android.hardware.type.automotive.
PHẢI hỗ trợ uiMode = UI_MODE_TYPE_CAR.
Quá trình triển khai Android Automotive PHẢI hỗ trợ tất cả API công khai trong không gian tên android.car.*.

Mọi cách triển khai thiết bị Android không phù hợp với bất kỳ loại thiết bị nào nêu trên vẫn PHẢI đáp ứng tất cả yêu cầu trong tài liệu này để tương thích với Android 7.0, trừ phi yêu cầu đó được mô tả rõ ràng là chỉ áp dụng cho một loại thiết bị Android cụ thể từ trên.

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

Đây là bản tóm tắ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ị. (Các ô trống biểu thị "MAY"). Không phải tất cả các cấu hình đều được đề cập trong bảng này; hãy xem các phần cứng có liên quan để biết thêm chi tiết.

Danh mục	Tính năng	Khu	Cầm tay	Truyền hình	Xem	Automotive	Khác
Đầu vào	Bàn phím D-pad	7.2.2. Điều hướng không chạm		PHẢI
	Màn hình cảm ứng	7.2.4. Phương thức nhập qua màn hình cảm ứng	PHẢI		PHẢI		NÊN
	Micrô	7.8.1. Micrô	PHẢI	NÊN	PHẢI	PHẢI	NÊN
Cảm biến	Gia tốc kế	7.3.1 Gia tốc kế	NÊN		NÊN		NÊN
Cảm biến	GPS	7.3.3. Hệ thống định vị toàn cầu (GPS)	NÊN			NÊN
Khả năng kết nối	Wi-Fi	7.4.2. IEEE 802.11	NÊN	NÊN		NÊN	NÊN
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	NÊN	NÊN			NÊN
	Bluetooth	7.4.3. Bluetooth	NÊN	PHẢI	PHẢI	PHẢI	NÊN
	Bluetooth năng lượng thấp	7.4.3. Bluetooth	NÊN	PHẢI	NÊN	NÊN	NÊN
	Radio di động	7.4.5. Khả năng mạng tối thiểu				NÊN
	Chế độ máy chủ/thiết bị ngoại vi USB	7.7. USB	NÊN			NÊN	NÊN
Đầu ra	Cổng đầu ra loa và/hoặc âm thanh	7.8.2. Đầu ra âm thanh	PHẢI	PHẢI		PHẢI	PHẢI

3. Phần mềm

3.1. Khả năng tương thích của API được quản lý

Môi trường thực thi mã byte Dalvik được quản lý là phương tiện chính cho các ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là tập hợp các giao diện nền tảng Android hiển thị với các ứng dụng chạy trong môi trường thời gian chạy được quản lý. Quá trình triển khai thiết bị PHẢI cung cấp quá trình triển khai hoàn chỉnh, bao gồm tất cả hành vi được ghi nhận, của mọi API được ghi nhận do SDK Android hiển thị hoặc mọi API được trang trí bằng điểm đánh dấu “@SystemApi” trong mã nguồn Android ngược dòng.

Các quá trình triển khai thiết bị PHẢI hỗ trợ/duy trì tất cả các lớp, phương thức và phần tử liên kết được đánh dấu bằng chú thích TestApi (@TestApi).

Quá trình triển khai thiết bị KHÔNG ĐƯỢC bỏ qua bất kỳ API được quản lý nào, thay đổi giao diện hoặc chữ ký API, đi chệch khỏi hành vi trong tài liệu hoặc bao gồm hoạt động không hoạt động, trừ trường hợp được Định nghĩa tương thích này cho phép cụ thể.

Định nghĩa về khả năng tương thích này cho phép loại bỏ một số loại phần cứng mà Android có API được bỏ qua khi triển khai thiết bị. Trong những trường hợp như vậy, các API vẫn PHẢI hiện diện và hoạt động hợp lý. Hãy xem phần 7 để biết các yêu cầu cụ thể cho trường hợp này.

3.1.1. Tiện ích Android

Android có hỗ trợ mở rộng các API được quản lý trong khi vẫn giữ nguyên phiên bản cấp độ API. Quá trình triển khai thiết bị Android PHẢI tải trước phương thức triển khai AOSP của cả thư viện chia sẻ ExtShared và dịch vụ ExtServices có các phiên bản cao hơn hoặc bằng số phiên bản tối thiểu được phép theo từng cấp độ API. Ví dụ: triển khai thiết bị Android 7.0, chạy API cấp 24 PHẢI bao gồm ít nhất phiên bản 1.

3.2. Khả năng tương thích với API mềm

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

3.2.1. Quyền

Trình triển khai thiết bị PHẢI hỗ trợ và thực thi tất cả hằng số quyền như được nêu trong Trang tham khảo về quyền. Xin lưu ý rằng phần 9 liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật Android.

3.2.2. Tham số bản dựng

API Android bao gồm một số hằng số trên lớp android.os.Build dùng để mô tả thiết bị hiện tại. Để cung cấp các giá trị nhất quán, có ý nghĩa giữa các lần triển khai thiết bị, bảng bên dưới bao gồm các hạn chế bổ sung về định dạng của các giá trị này mà các 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.PHÁT HÀNH	Phiên bản hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. Trường này PHẢI có một trong các giá trị chuỗi đã xác định trong 7.0.
PHIÊN BẢN.SDK	Phiên bản hệ thống Android đang thực thi, ở một định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập được. Đối với Android 7.0, trường này PHẢI có giá trị số nguyên 7.0_INT.
VERSION.SDK_INT	Phiên bản hệ thống Android đang thực thi, ở một định dạng mà mã xử lý ứng dụng của bên thứ ba có thể truy cập được. Đối với Android 7.0, trường này PHẢI có giá trị số nguyên 7.0_INT.
VERSION.INCREMENTAL	Giá trị do trình triển khai thiết bị chọn để chỉ định bản dựng cụ thể của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. Giá trị này KHÔNG ĐƯỢC sử dụng lại cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Trường này được dùng để cho biết số bản dựng hoặc giá trị nhận dạng thay đổi về quyền kiểm soát nguồn được dùng để tạo bản dựng. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc là chuỗi trống ("").
BẢNG	Giá trị do trình triển khai thiết bị chọn để xác định phần cứng bên trong cụ thể mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Trường này có thể dùng để chỉ ra bản sửa đổi cụ thể của bảng cấp nguồn cho thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
THƯƠNG HIỆU	Một giá trị phản ánh tên thương hiệu liên kết với thiết bị mà người dùng cuối biết. PHẢI ở định dạng mà con người có thể đọc được và PHẢI đại diện cho nhà sản xuất thiết bị hoặc thương hiệu của công ty nơi tiếp thị thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
HỖ TRỢ_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
HỖ TRỢ_32_BIT_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
HỖ TRỢ_64_BIT_ABIS	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
CPU_ABI2	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc.
THIẾT BỊ	Giá trị do người triển khai thiết bị chọn, có chứa tên phát triển hoặc tên mã xác định cấu hình của các tính năng phần cứng và kiểu dáng công nghiệp của thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”. Tên thiết bị này KHÔNG ĐƯỢC thay đổi trong suốt thời gian hoạt động của sản phẩm.
IN HOA	Một chuỗi xác định duy nhất bản dựng này. Mã này PHẢI dễ đọc. Ứng dụng PHẢI tuân theo mẫu sau: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/myproduct/ mydevice:7.0/LMYXX/3359:userdebug/test-keys Vân tay KHÔNG ĐƯỢC bao gồm các ký tự khoảng trắng. Nếu các trường khác có trong mẫu ở trên có ký tự khoảng trắng, thì các trường đó PHẢI được thay thế bằng một ký tự khác trong dấu vân tay bản dựng, chẳng hạn như ký tự dấu gạch dưới ("_"). Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit.
PHẦN CỨNG	Tên của phần cứng (từ dòng lệnh kernel hoặc /proc). Mã này PHẢI dễ đọc. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
NGƯỜI DẪN CHƯƠNG TRÌNH	Một chuỗi xác định duy nhất máy chủ lưu trữ mà bản dựng được xây dựng, ở định dạng mà con người có thể đọc được. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc là chuỗi trống ("").
ID	Giá trị nhận dạng do trình triển khai thiết bị chọn để tham chiếu đến một bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống như android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị có ý nghĩa đủ để người dùng cuối phân biệt giữa các bản dựng phần mềm. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+$”.
NHÀ SẢN XUẤT	Tên thương mại của Nhà sản xuất thiết bị gốc (OEM) của sản phẩm. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc là chuỗi trống ("").
KIỂU MÁY	Một giá trị do trình triển khai thiết bị chọn, có chứa tên của thiết bị mà người dùng cuối biết. Tên này PHẢI giống với tên được dùng để tiếp thị và bán thiết bị cho người dùng cuối. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc là chuỗi trống ("").
SẢN PHẨM	Giá trị do trình triển khai thiết bị chọn. Giá trị này PHẢI là duy nhất trong cùng một thương hiệu, trong đó có tên phát triển hoặc tên mã của sản phẩm (SKU) cụ thể. PHẢI là nội dung mà con người có thể đọc được, nhưng không nhất thiết là để người dùng cuối có thể xem được. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”. Tên sản phẩm này KHÔNG ĐƯỢC thay đổi trong suốt vòng đời của sản phẩm.
SÊ-RI	Số sê-ri phần cứng PHẢI có sẵn và là duy nhất trên các thiết bị có cùng MÔ HÌNH và NHÀ SẢN XUẤT. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^([a-zA-Z0-9]{6,20})$”.
THẺ TỪ KHOÁ	Danh sách các thẻ được phân tách bằng dấu phẩy do trình triển khai thiết bị chọn để phân biệt rõ hơn bản dựng. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình ký của nền tảng Android điển hình: release-keys, dev-keys, test-keys.
THỜI GIAN	Một giá trị biểu thị dấu thời gian khi quá trình tạo bản dựng diễn ra.
LOẠI	Giá trị do trình triển khai thiết bị chọn để chỉ định cấu hình thời gian chạy của bản dựng. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình Android Runtime điển hình: user, userdebug hoặc eng.
NGƯỜI DÙNG	Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) đã tạo bản dựng. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc là chuỗi trống ("").
BẢO MẬT_PATCH	Một giá trị cho biết cấp bản vá bảo mật của một bản dựng. Nó PHẢI biểu thị rằng bản dựng không dễ gặp phải bất kỳ vấn đề nào được mô tả thông qua Bản tin về an ninh công cộng Android được chỉ định. Thông báo PHẢI có định dạng [YYYY-MM-DD], khớp với một chuỗi đã xác định được nêu trong Bản tin về an ninh công cộng Android hoặc trong Thông báo tư vấn về bảo mật Android, chẳng hạn như "2015-11-01".
BASE_OS (Hệ điều hành cơ sở)	Một giá trị biểu thị tham số FINGERprint của bản dựng hoàn toàn giống với bản dựng này, ngoại trừ các bản vá được cung cấp trong Bản tin về an ninh công cộng Android. Hàm PHẢI báo cáo giá trị chính xác và nếu bản dựng đó không tồn tại, hãy báo cáo một chuỗi trống ("").

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

3.2.3.1. Ý định cốt lõi của ứng dụng

Ý định trên Android cho phép các thành phần ứng dụng yêu cầu chức năng từ các thành phần Android khác. Dự án Android phiên bản cũ bao gồm một danh sách ứng dụng được xem là ứng dụng Android cốt lõi, triển khai một số mẫu ý định để thực hiện các thao tác phổ biến. Các ứng dụng Android cốt lõi là:

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

Quá trình triển khai thiết bị PHẢI bao gồm các ứng dụng Android cốt lõi (nếu phù hợp) hoặc một thành phần triển khai các mẫu ý định giống nhau được xác định bởi tất cả thành phần Hoạt động hoặc Dịch vụ của các ứng dụng Android cốt lõi này hiển thị với các ứng dụng khác, theo cách ngầm ẩn hoặc rõ ràng, thông qua thuộc tính android:exported.

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

Vì Android là một nền tảng có thể mở rộng, nên việ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 phần 3.2.3.1. Việc triển khai nguồn mở Android ngược dòng cho phép điều này theo mặc định; trình triển khai thiết bị KHÔNG ĐƯỢC đính kèm đặc quyền đặc biệt vào ứng dụng hệ thống việc sử dụng các mẫu ý định này hoặc ngăn ứng dụng của bên thứ ba liên kết và giả định kiểm soát các mẫu ý định này. Quy định cấm này cụ thể bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng “Chooser” (Bộ chọn), cho phép người dùng chọn giữa nhiều ứng dụng mà tất cả đều xử lý cùng một mẫu ý định.

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

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

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

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

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

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

3.2.3.4. Ý định truyền tin

Các ứng dụng bên thứ ba dựa vào nền tảng này để truyền đi một số ý định nhất định nhằm thông báo cho chúng về những thay đổi trong môi trường phần cứng hoặc phần mềm. Các thiết bị tương thích với Android PHẢI truyền phát ý định truyền tin công khai để phản hồi các sự kiện hệ thống thích hợp. Ý định truyền tin được mô tả trong tài liệu về SDK.

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

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

Triển khai thiết bị:

PHẢI tuân thủ ý định android.settings.HOME_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho Màn hình chính, nếu quá trình triển khai thiết bị báo cáo android.software.home_screen.
PHẢI cung cấp trình đơn cài đặt sẽ gọi ý định android.provider.Telephony.ACTION_CHANGE_DEFAULT nhằm hiển thị hộp thoại nhằm thay đổi ứng dụng SMS mặc định nếu quá trình triển khai thiết bị báo cáo android.hardware.telephony.
PHẢI thực hiện đúng ý định android.settings.NFC_PAYMENT_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho Chạm và thanh toán, nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc.hce.
PHẢI tuân thủ ý định android.telecom.action.CHANGE_DEFAULT_DIALER để hiện hộp thoại cho phép người dùng thay đổi ứng dụng Điện thoại mặc định, nếu hoạt động triển khai thiết bị báo cáo android.hardware.telephony .

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

Khó tương thích với mã gốc. Vì lý do này, các trình triển khai thiết bị NÊN DÙNG để sử dụng các phương thức triển khai thư viện được liệt kê bên dưới trong Dự án nguồn mở Android ngược dòng (upstream).

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

Mã byte Dalvik được quản lý có thể gọi vào mã gốc được cung cấp trong tệp .apk của ứng dụng dưới dạng tệp ELF .so được biên dịch cho kiến trúc phần cứng thích hợp của thiết bị. Vì mã gốc phụ thuộc nhiều vào công nghệ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân của ứng dụng (ABI) trong Android NDK. Các quá trình triển khai thiết bị PHẢI tương thích với một hoặc nhiều ABI đã xác định và PHẢI triển khai khả năng tương thích với Android NDK, như bên dưới.

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

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) chuẩn.
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 nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách dưới đây.
PHẢI hỗ trợ ABI 32 bit tương đương nếu có ABI 64 bit được hỗ trợ.
PHẢI báo cáo chính xác các tham số Giao diện nhị phân của ứng dụng (ABI) gốc mà thiết bị hỗ trợ, thông qua các tham số android.os.Build.supported_ABIS, android.os.Build.manifest_32_BIT_ABIS và android.os.Build.kín_64_BIT_ABIS, mỗi tham số được phân tách bằng dấu phẩy gồm các ABI được sắp xếp theo thứ tự từ thứ tự được ưa thích nhất đến thứ tự ít được ưa thích nhất.
Thông qua các thông số trên, PHẢI báo cáo chỉ những ABI được ghi lại và mô tả trong phiên bản mới nhất của tài liệu Quản lý ABI Android NDK, đồng thời PHẢI bao gồm tính năng hỗ trợ cho tiện ích Advanced SIMD (còn gọi là NEON).
NÊN được tạo bằng cách sử dụng mã nguồn và tệp tiêu đề có sẵn trong Dự án nguồn mở Android ngược dòng (upstream)

Xin lưu ý rằng các bản phát hành trong tương lai của Android NDK có thể hỗ trợ các ABI khác. Nếu quá trình triển khai thiết bị không tương thích với ABI được xác định trước hiện có, thì thiết bị KHÔNG ĐƯỢC báo cáo khả năng hỗ trợ cho bất kỳ ABI nào.

Các API mã gốc sau PHẢI khả dụng cho các ứng dụng chứa mã gốc:

libandroid.so (hỗ trợ hoạt động gốc trên Android)
libc (thư viện C)
libcamera2ndk.so
libdl (trình liên kết động)
libEGL.so (quản lý nền tảng OpenGL gốc)
libGLESv1_CM.so (OpenGL ES 1.x)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.x)
libicui18n.so
libicuuc.so
libjnigraphics.so
liblog (ghi nhật ký Android)
libmediandk.so (hỗ trợ các API nội dung nghe nhìn gốc)
libm (thư viện toán học)
libOpenMAXAL.so (Hỗ trợ OpenMAX AL 1.0.1)
libOpenSLES.so (Hỗ trợ âm thanh OpenSL ES 1.0.1)
libRS.so
libstdc++ (Hỗ trợ tối thiểu cho C++)
libvulkan.so (Vulkan)
libz (nén Zlib)
Giao diện JNI
Hỗ trợ OpenGL, như mô tả dưới đây

Đối với các thư viện gốc được liệt kê ở trên, việc triển khai thiết bị KHÔNG ĐƯỢC thêm hoặc xoá các hàm công khai.

Thư viện gốc không được liệt kê ở trên nhưng được triển khai và cung cấp trong AOSP (Dự án nguồn mở Android) vì thư viện hệ thống được dành riêng và KHÔNG ĐƯỢC hiển thị với các ứng dụng bên thứ ba nhắm đến API cấp 24 trở lên.

Các hoạt động triển khai trên thiết bị CÓ THỂ thêm các thư viện không phải AOSP (Dự án nguồn mở Android) và hiển thị trực tiếp các thư viện đó dưới dạng API cho các ứng dụng bên thứ ba. Tuy nhiên, các thư viện bổ sung PHẢI nằm trong /vendor/lib hoặc /vendor/lib64 và PHẢI được liệt kê trong /vendor/etc/public.libraries.txt.

Lưu ý rằng các quá trình triển khai thiết bị PHẢI bao gồm libGLESv3.so và lần lượt, PHẢI xuất tất cả biểu tượng hàm OpenGL ES 3.1 và Android Extension Pack như đã xác định trong bản phát hành NDK android-24. Mặc dù phải có tất cả các ký hiệu, nhưng chỉ các chức năng tương ứng cho các phiên bản OpenGL ES và tiện ích thực sự được thiết bị hỗ trợ mới phải được triển khai đầy đủ.

3.3.1.1. Thư viện đồ hoạ

Vulkan là API nhiều nền tảng, có mức hao tổn thấp dành cho đồ hoạ 3D hiệu suất cao. Các quá trình triển khai cho thiết bị, ngay cả khi không hỗ trợ API Vulkan, PHẢI đáp ứng các yêu cầu sau:

Lớp này PHẢI luôn cung cấp một thư viện gốc có tên là libvulkan.so. Thư viện này xuất các biểu tượng hàm cho API Vulkan 1.0 cốt lõi cũng như các tiện ích VK_KHR_surface, VK_KHR_android_surface và VK_KHR_swapchain.

Triển khai thiết bị, nếu có hỗ trợ API Vulkan:

PHẢI báo cáo, một hoặc nhiều VkPhysicalDevices thông qua lệnh gọi vkEnumeratePhysicalDevices.
Mỗi VkPhysicalDevices được liệt kê PHẢI triển khai đầy đủ API Vulkan 1.0.
PHẢI báo cáo đúng cờ tính năng PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL và PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
PHẢI liệt kê các lớp có trong thư viện gốc có tên là libVkLayer*.so trong thư mục thư viện gốc của gói ứng dụng, thông qua các hàm vkEnumerateInstanceLayerProperties và vkEnumerateDeviceLayerProperties trong libvulkan.so
KHÔNG ĐƯỢC liệt kê các lớp do 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=”true”.

Triển khai thiết bị, nếu không bao gồm khả năng hỗ trợ các API Vulkan:

PHẢI báo cáo 0 VkPhysicalDevices thông qua lệnh gọi vkEnumeratePhysicalDevices.
KHÔNG ĐƯỢC khai báo bất kỳ cờ tính năng nào trong Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL và PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

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

Kiến trúc ARMv8 ngừng sử dụng một số hoạt động của CPU, bao gồm cả một số thao tác được sử dụng trong mã gốc hiện có. Trên thiết bị ARM 64 bit, các thao tác không dùng nữa sau PHẢI vẫn áp dụng được cho mã ARM gốc 32 bit, thông qua hỗ trợ CPU gốc hoặc thông qua quy trình mô phỏng phần mềm:

Hướng dẫn về SWP và SWPB
ĐẶT lệnh
Vận hành rào chắn CP15ISB, CP15DSB và CP15DMB

Các phiên bản cũ của Android NDK đã sử dụng /proc/cpuinfo để khám phá các tính năng của CPU từ mã gốc ARM 32 bit. Để tương thích với các ứng dụng được tạo bằng NDK này, thiết bị PHẢI bao gồm các dòng sau trong /proc/cpuinfo khi được ứng dụng ARM 32 bit đọc:

"Features: ", theo sau là danh sách các tính năng CPU ARMv7 tùy chọn mà thiết bị hỗ trợ.
"Cấu trúc CPU: ", theo sau là một số nguyên mô tả kiến trúc ARM được hỗ trợ cao nhất của thiết bị (ví dụ: "8" cho thiết bị ARMv8).

Những yêu cầu này chỉ áp dụng khi /proc/cpuinfo được các ứng dụng ARM 32 bit đọc. Thiết bị KHÔNG ĐƯỢC thay đổi /proc/cpuinfo khi được đọc bằng các ứng dụng ARM 64 bit hoặc không phải ARM.

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

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

Thiết bị Android Watch CÓ THỂ, nhưng tất cả cách triển khai khác trên thiết bị PHẢI cung cấp cách triển khai đầy đủ của API android.webkit.Webview.

Tính năng nền tảng android.software.webview PHẢI được báo cáo trên mọi thiết bị cung cấp cách triển khai đầy đủ của API android.webkit.WebView và KHÔNG ĐƯỢC báo cáo trên các thiết bị không triển khai API hoàn chỉnh. Quá trình triển khai Nguồn mở Android dùng mã của Dự án Chromium để triển khai android.webkit.WebView. Vì không thể phát triển bộ kiểm thử toàn diện cho hệ thống kết xuất web, các trình triển khai thiết bị PHẢI sử dụng bản dựng ngược dòng cụ thể của Chromium trong quá trình triển khai WebView. Cụ thể:

Hoạt động triển khai android.webkit.WebView của thiết bị PHẢI dựa trên bản dựng Chromium từ Dự án nguồn mở Android ngược dòng dành cho Android 7.0. Bản dựng này bao gồm một loạt chức năng và bản sửa lỗi bảo mật cụ thể cho WebView.
Chuỗi tác nhân người dùng do WebView báo cáo PHẢI ở định dạng sau:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, như Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của android.os.Build.VERSION.Release.
- Giá trị của chuỗi $(MODEL) PHẢI giống với giá trị của android.os.Build.MODEL.
- Giá trị của chuỗi $(BUILD) PHẢI giống với giá trị của android.os.Build.ID.
- Giá trị của chuỗi $(CHROMIUM_VER) PHẢI là phiên bản Chromium trong Dự án nguồn mở Android ngược dòng.
- Quá trình triển khai thiết bị CÓ THỂ bỏ qua Thiết bị di động trong chuỗi tác nhân người dùng.

Thành phần WebView PHẢI bao gồm khả năng hỗ trợ cho nhiều tính năng HTML5 nhất có thể và nếu thành phần hỗ trợ tính năng này PHẢI tuân thủ thông số kỹ thuật HTML5.

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

Quá trình triển khai Android TV, Watch và Android Automotive CÓ THỂ bỏ qua ứng dụng trình duyệt, nhưng PHẢI hỗ trợ các mẫu ý định công khai như mô tả trong phần 3.2.3.1. Tất cả các kiểu triển khai thiết bị khác PHẢI bao gồm một ứng dụng Trình duyệt độc lập cho hoạt động duyệt web của người dùng nói chung.

Trình duyệt độc lập CÓ THỂ dựa trên một công nghệ trình duyệt không phải WebKit. Tuy nhiên, ngay cả khi ứng dụng Trình duyệt thay thế được sử dụng, thành phần android.webkit.WebView được cung cấp cho các ứng dụng bên thứ ba PHẢI dựa trên WebKit, như mô tả trong phần 3.4.1.

Quá trình triển khai CÓ THỂ gửi một chuỗi tác nhân người dùng tuỳ chỉnh trong ứng dụng Trình duyệt độc lập.

Ứng dụng Trình duyệt độc lập (cho dù dựa trên ứng dụng Trình duyệt WebKit ở trên hay một ứng dụng thay thế của bên thứ ba) NÊN hỗ trợ nhiều HTML5 nhất có thể. Ở mức tối thiểu, các quá trình triển khai thiết bị PHẢI hỗ trợ từng API được liên kết với HTML5:

Ngoài ra, các hoạt động triển khai thiết bị PHẢI hỗ trợ webstorage API HTML5/W3C và PHẢI hỗ trợ IndexedDB API của HTML5/W3C. Xin lưu ý rằng khi các cơ quan tiêu chuẩn phát triển web đang chuyển đổi để ưu tiên IndexedDB thay vì lưu trữ web, IndexedDB dự kiến sẽ trở thành thành phần bắt buộc trong phiên bản Android trong tương lai.

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

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 ở cấp trên. Một số lĩnh vực tương thích cụ thể là:

Thiết bị KHÔNG ĐƯỢC thay đổi hành vi hoặc ngữ nghĩa của một ý định chuẩn.
Thiết bị KHÔNG ĐƯỢC thay đổi vòng đời hoặc ngữ nghĩa của vòng đời của một loại thành phần hệ thống cụ thể (chẳng hạn như Service, Activity, ContentProvider, v.v.).
Thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của một quyền tiêu chuẩn.

Danh sách bên trên chưa đầy đủ. Bộ kiểm tra tính tương thích (CTS) kiểm tra khả năng tương thích hành vi của các phần quan trọng của nền tảng, nhưng không phải tất cả. Trình triển khai có trách nhiệm đảm bảo khả năng tương thích về hành vi với Dự án nguồn mở Android. Vì lý do này, người triển khai thiết bị NÊN sử dụng mã nguồn có sẵn thông qua Dự án nguồn mở Android nếu có thể, thay vì triển khai lại các phần quan trọng của hệ thống.

3.6. Không gian tên API

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

java.*
javax.*
mặt trời.*
Android.*
com.android.*

Các nội dung sửa đổi bị cấm bao gồm :

Quá trình triển khai thiết bị KHÔNG ĐƯỢC sửa đổi API hiển thị công khai trên nền tảng Android bằng cách thay đổi bất kỳ chữ ký lớp hoặc phương thức nào, hoặc bằng cách xoá lớp hoặc trường lớp.
Trình triển khai thiết bị CÓ THỂ sửa đổi cách triển khai cơ bản của các API, nhưng những sửa đổi đó 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 được hiển thị công khai nào.
Trình triển khai thiết bị KHÔNG ĐƯỢC thêm bất kỳ phần tử được hiển thị công khai nào (chẳng hạn như lớp hoặc giao diện hay các trường hay phương thức vào các lớp hay giao diện hiện có) vào các API ở trên.

"Phần tử được hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng điểm đánh dấu "@ẩn" như được sử dụng trong mã nguồn Android ngược dòng. Nói cách khác, trình triển khai thiết bị KHÔNG ĐƯỢC hiển thị API mới hoặc thay đổi API hiện có trong không gian tên nêu trên. Trình triển khai thiết bị CÓ THỂ thực hiện sửa đổi chỉ dành cho nội bộ, nhưng những sửa đổi đó KHÔNG ĐƯỢC quảng cáo hoặc hiển thị với nhà phát triển.

Trình triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh, nhưng mọi API như vậy KHÔNG ĐƯỢC nằm trong không gian tên do một tổ chức khác sở hữu hoặc tham chiếu đến một tổ chức khác. Ví dụ: trình triển khai thiết bị KHÔNG ĐƯỢC thêm API vào com.google.* hoặc không gian tên tương tự: chỉ Google mới có thể làm như vậy. Tương tự, Google KHÔNG ĐƯỢC thêm API vào các công ty khác không gian tên. Ngoài ra, nếu quá trình triển khai thiết bị bao gồm các API tuỳ chỉnh bên ngoài không gian tên tiêu chuẩn của Android, thì các API đó PHẢI được đóng gói trong một thư viện dùng chung Android để chỉ những ứng dụng có sử dụng chúng một cách rõ ràng (thông qua cơ chế <uses-library>) bị ảnh hưởng bởi việc tăng mức sử dụng bộ nhớ của các API đó.

Nếu trình triển khai thiết bị đề xuất cải thiện một trong các không gian tên gói ở trên (chẳng hạn như bằng cách thêm chức năng mới hữu ích vào API hiện có hoặc thêm API mới), thì trình triển khai NÊN truy cập source.android.com và bắt đầu quy trình đóng góp các thay đổi và mã, theo thông tin trên trang web đó.

Lưu ý rằng các hạn chế ở trên tương ứng với các quy ước tiêu chuẩn để đặt tên cho API bằng ngôn ngữ lập trình Java; phần này chỉ nhằm mục đích củng cố các quy ước đó và làm cho chúng có tính ràng buộc thông qua việc đưa vào Định nghĩa về khả năng tương thích.

3,7. Khả năng tương thích trong thời gian chạy

Việc triển khai thiết bị PHẢI hỗ trợ định dạng Dalvik thực thi (DEX) đầy đủ cũng như thông số kỹ thuật và ngữ nghĩa mã byte Dalvik. Người triển khai thiết bị NÊN sử dụng ART, phương thức triển khai tham chiếu ngược dòng của Định dạng có thể 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.

Quá trình triển khai thiết bị PHẢI định cấu hình thời gian chạy Dalvik để phân bổ bộ nhớ phù hợp với nền tảng Android ngược dòng và theo 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.) Lưu ý rằng các giá trị bộ nhớ được chỉ định bên dưới được coi là giá trị tối thiểu và các quá trình triển khai thiết bị CÓ THỂ phân bổ thêm bộ nhớ cho mỗi ứng dụng.

Bố cục màn hình	Mật độ màn hình	Bộ nhớ tối thiểu của ứng dụng
Đồng hồ Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)	36MB
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
nhỏ/bình thường	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
lớn	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)	80MB
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)	96MB
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3,8. Khả năng tương thích giao diện người dùng

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

Android bao gồm ứng dụng trình chạy (màn hình chính) và tính năng hỗ trợ các ứng dụng bên thứ ba để thay thế trình chạy thiết bị (màn hình chính). Những cách triển khai thiết bị cho phép các ứng dụng bên thứ ba thay thế màn hình chính của thiết bị PHẢI khai báo tính năng nền tảng android.software.home_screen.

3.8.2. Tiện ích

Tiện ích là không bắt buộc cho mọi hoạt động triển khai trên thiết bị Android, nhưng PHẢI được hỗ trợ trên các thiết bị Android cầm tay.

Android xác định loại thành phần cũng như API cũng như 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, một tính năng được ĐỀ XUẤT NÊN được hỗ trợ khi triển khai Thiết bị cầm tay. Các quá trình triển khai thiết bị có hỗ trợ tiện ích nhúng trên màn hình chính PHẢI đáp ứng các yêu cầu sau và khai báo rằng có hỗ trợ cho tính năng nền tảng android.software.app_Widget.

Trình chạy thiết bị PHẢI bao gồm tính năng hỗ trợ tích hợp sẵn cho AppWidgets và hiển thị các thành phần tương tác trên giao diện người dùng để thêm, định cấu hình, xem và xoá AppWidgets ngay trong Trình chạy.
Các quá trình triển khai thiết bị PHẢI có khả năng kết xuất các tiện ích có kích thước 4 x 4 ở kích thước lưới chuẩn. Xem Nguyên tắc thiết kế tiện ích ứng dụng trong tài liệu SDK Android để biết thông tin chi tiết.
Các quá trình triển khai thiết bị bao gồm tính năng hỗ trợ màn hình khoá CÓ THỂ hỗ trợ các tiện ích ứng dụng trên màn hình khoá.

3.8.3. Thông báo

Android có các API cho phép nhà phát triển thông báo cho người dùng về các sự kiện đáng chú ý bằng cách sử dụng các tính năng phần cứng và phần mềm của thiết bị.

Một số API cho phép ứng dụng thực hiện thông báo hoặc thu hút sự chú ý bằng cách sử dụng phần cứng – cụ thể là âm thanh, chế độ rung và ánh sáng. Quá trình triển khai thiết bị PHẢI hỗ trợ các thông báo sử dụng các tính năng phần cứng, như mô tả trong tài liệu SDK và trong phạm vi có thể với phần cứng triển khai thiết bị. Ví dụ: nếu quá trình triển khai thiết bị bao gồm bộ rung, thì bộ rung PHẢI triển khai chính xác các API rung. Nếu quá trình triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7.

Ngoài ra, quá trình triển khai PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp ảnh động, v.v.) được cung cấp trong API hoặc trong hướng dẫn kiểu biểu tượng của Thanh hệ thống/Trạng thái. Trong trường hợp thiết bị Android TV, thiết bị có khả năng không hiển thị thông báo. Trình triển khai thiết bị CÓ THỂ cung cấp trải nghiệm người dùng thay thế cho các thông báo so với trải nghiệm được cung cấp trong quá trình triển khai Nguồn mở Android tham chiếu; tuy nhiên, các hệ thống thông báo thay thế đó PHẢI hỗ trợ các tài nguyên thông báo hiện có như nêu trên.

Quá trình triển khai Android Automotive CÓ THỂ quản lý chế độ hiển thị và thời gian thông báo để giảm thiểu sự phân tâm của người lái xe, nhưng PHẢI hiển thị thông báo sử dụng CarExpander khi được ứng dụng yêu cầu.

Android hỗ trợ nhiều loại thông báo, chẳng hạn như:

Thông báo đa dạng thức . Chế độ xem tương tác cho các thông báo hiển thị liên tục.
Thông báo quan trọng . Người dùng Chế độ xem tương tác có thể thao tác hoặc đóng mà không cần rời khỏi ứng dụng hiện tại.
Thông báo trên màn hình khoá . Thông báo hiển thị trên màn hình khoá với chế độ kiểm soát chi tiết về chế độ hiển thị.

Các hoạt động triển khai trên thiết bị Android, khi các thông báo đó được hiển thị, PHẢI thực thi đúng cách các Thông báo nhiều định dạng và thông báo quan trọng, đồng thời bao gồm tiêu đề/tên, biểu tượng, văn bản như được ghi lại trong API Android.

Android bao gồm các API Dịch vụ trình nghe thông báo cho phép các ứng dụng (khi người dùng cho phép rõ ràng) nhận bản sao của tất cả thông báo khi các thông báo đó được đăng hoặc cập nhật. Quá trình triển khai thiết bị PHẢI gửi toàn bộ thông báo một cách chính xác và kịp thời cho tất cả dịch vụ trình nghe mà người dùng đã cài đặt và bật, bao gồm cả mọi siêu dữ liệu đi kèm đối tượng Notification.

Các quá trình triển khai trên thiết bị hỗ trợ tính năng DND (Không làm phiền) PHẢI đáp ứng các yêu cầu sau:

PHẢI triển khai một hoạt động sẽ phản hồi ý định ACTION_RATIO_POLICY_ACCESS_SETTINGS. Đối với các hoạt động triển khai với UI_MODE_TYPE_NORMAL, thì hoạt động này PHẢI là hoạt động mà người dùng có thể cấp hoặc từ chối quyền truy cập của ứng dụng vào cấu hình chính sách DND.
NÊN, khi quá trình triển khai thiết bị đã cung cấp phương tiện để người dùng cấp hoặc từ chối ứng dụng bên thứ ba truy cập vào cấu hình chính sách DND, hiển thị Quy tắc DND tự động do ứng dụng tạo cùng với các quy tắc do người dùng tạo và xác định trước.
PHẢI tuân thủ các giá trị suppressedVisualEffects được truyền dọc theo NotificationManager.Policy và nếu ứng dụng đặt bất kỳ cờ nào trong số các cờ supPRESSED_Effect_SCREEN_OFF hoặc supPRESSED_APP_SCREEN_ON, thì ứng dụng PHẢI cho người dùng biết rằng hiệu ứng hình ảnh bị tắt trong trình đơn cài đặt DND.

3.8.4. Tìm kiếm

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

Các quá trình triển khai thiết bị Android PHẢI bao gồm chức năng tìm kiếm chung, một giao diện người dùng tìm kiếm chung duy nhất trên toàn hệ thống, có khả năng đưa ra các đề xuất theo thời gian thực để phản hồi hoạt động đầu vào của người dùng. Quá trình triển khai thiết bị PHẢI triển khai các API cho phép nhà phát triển sử dụng lại giao diện người dùng này để cung cấp tính năng tìm kiếm trong ứng dụng của riêng họ. Các hoạt động triển khai thiết bị triển khai giao diện tìm kiếm chung PHẢI triển khai các API cho phép các ứng dụng của bên thứ ba thêm đề xuất vào hộp tìm kiếm khi hộp tìm kiếm chạy ở chế độ tìm kiếm chung. Nếu không có ứng dụng bên thứ ba nào được cài đặt để sử dụng chức năng này, chế độ mặc định PHẢI là hiển thị kết quả và đề xuất của công cụ tìm kiếm trên web.

Các triển khai thiết bị Android NÊN và triển khai Android Automotive PHẢI, triển khai trợ lý trên thiết bị để xử lý thao tác hỗ trợ.

Android cũng bao gồm API Hỗ trợ để cho phép các ứng dụng chọn lượng thông tin về ngữ cảnh hiện tại được chia sẻ với trợ lý trên thiết bị. Các quá trình triển khai thiết bị hỗ trợ thao tác Hỗ trợ PHẢI chỉ báo rõ ràng cho người dùng cuối biết khi nào ngữ cảnh được chia sẻ bằng cách hiển thị ánh sáng trắng xung quanh các cạnh của màn hình. Để đảm bảo người dùng cuối có thể nhìn thấy rõ ràng, chỉ báo PHẢI đá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.

3.8.5. Bánh mì nướng

Các ứng dụng có thể dùng API "Thông báo ngắn" để cho người dùng cuối thấy các chuỗi ngắn không theo phương thức. Các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn. Quá trình triển khai thiết bị PHẢI hiển thị Thông báo ngắn từ ứng dụng cho người dùng cuối ở mức độ hiển thị cao.

3.8.6. Giao diện

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

Android bao gồm nhóm chủ đề “Holo” dưới dạng một tập hợp các kiểu xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn phù hợp với Giao diện chủ đề Holo do SDK Android xác định. Các quá trình triển khai thiết bị KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính chủ đề Holo nào hiển thị với ứng dụng.

Android bao gồm nhóm giao diện "Material" dưới dạng một nhóm các kiểu được xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn phù hợp với giao diện của chủ đề thiết kế trên nhiều loại thiết bị Android. Các quá trình triển khai thiết bị PHẢI hỗ trợ nhóm giao diện "Material" và KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính nào của giao diện Material hoặc các thành phần hiển thị với ứng dụng.

Android cũng bao gồm nhóm giao diện "Mặc định của thiết bị" dưới dạng một nhóm các kiểu xác định để nhà phát triển ứng dụng sử dụng nếu họ muốn phù hợp với giao diện của giao diện thiết bị do người triển khai thiết bị xác định. Quá trình triển khai thiết bị CÓ THỂ sửa đổi thuộc tính giao diện mặc định của thiết bị hiển thị với ứng dụng.

Android hỗ trợ giao diện biến thể có các thanh hệ thống trong suốt, cho phép nhà phát triển ứng dụng lấp đầy khu vực phía sau thanh trạng thái và điều hướng bằng nội dung ứng dụng của họ. Để mang lại trải nghiệm nhất quán cho nhà phát triển trong cấu hình này, kiểu biểu tượng thanh trạng thái cần được duy trì trên các thiết bị triển khai khác nhau. Do đó, các quá trình triển khai trên thiết bị Android PHẢI sử dụng màu trắng cho các biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) và thông báo do hệ thống đưa ra, trừ phi biểu tượng đó cho biết trạng thái có vấn đề hoặc ứng dụng yêu cầu thanh trạng thái sáng bằng cờ SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Khi một ứng dụng yêu cầu thanh trạng thái sáng, các quy trình triển khai trên thiết bị Android PHẢI thay đổi màu của biểu tượng trạng thái hệ thống thành màu đen (để biết thông tin chi tiết, hãy tham khảo R.style).

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

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

Phần cứng được coi là có khả năng chạy hình nền động ổn định nếu có thể chạy tất cả hình nền động mà không bị hạn chế về chức năng, ở tốc độ khung hình hợp lý và không gây ảnh hưởng xấu đến các ứng dụng khác. Nếu các hạn chế trong phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, hỏng hóc, ngốn pin hoặc CPU quá mức hoặc chạy ở tốc độ khung hình thấp không thể chấp nhận, thì phần cứng được coi là không thể chạy hình nền động. Ví dụ: một số hình nền động có thể sử dụng bối cảnh OpenGL 2.0 hoặc 3.x để kết xuất nội dung. Hình nền động sẽ không chạy ổn định trên phần cứng không hỗ trợ nhiều ngữ cảnh OpenGL vì việc sử dụng hình nền động trong ngữ cảnh OpenGL có thể xung đột với các ứng dụng khác cũng sử dụng bối cảnh OpenGL.

Các quá trình triển khai thiết bị có khả năng chạy hình nền động một cách ổn định như mô tả ở trên NÊN triển khai hình nền động. Đồng thời, khi triển khai PHẢI báo cáo cờ tính năng nền tảng android.software.live_wallpaper.

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

Vì phím điều hướng chức năng gần đây là KHÔNG BẮT BUỘC, nên yêu cầu triển khai màn hình tổng quan là KHÔNG BẮT BUỘC đối với quá trình triển khai Android Watch và Android Automotive, đồng thời NÊN DÙNG đối với thiết bị Android TV. Vẫn NÊN là một phương thức để chuyển đổi giữa các hoạt động trên các phương thức triển khai Android Automotive.

Mã nguồn Android ngược dòng bao gồm màn hình tổng quan, một giao diện người dùng cấp hệ thống để chuyển đổi tác vụ và hiển thị các hoạt động cũng như tác vụ đã truy cập gần đây bằng cách sử dụng hình thu nhỏ về trạng thái đồ hoạ của ứng dụng tại thời điểm người dùng rời khỏi ứng dụng lần cuối. Các hoạt động triển khai trên thiết bị, bao gồm cả phím điều hướng chức năng gần đây như đã nêu chi tiết trong mục 7.2.3 CÓ THỂ thay đổi giao diện nhưng PHẢI đáp ứng các yêu cầu sau:

PHẢI hỗ trợ tối đa 6 hoạt động được hiển thị.
NÊN hiển thị ít nhất tiêu đề của 4 hoạt động cùng lúc.
PHẢI 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.
PHẢI hiển thị màu đánh dấu, biểu tượng, tiêu đề màn hình gần đây.
NÊN hiển thị một thành phần đóng ("x") nhưng CÓ THỂ trì hoãn điều này cho đến khi người dùng tương tác với màn hình.
NÊN triển khai một phím tắt để dễ dàng chuyển về hoạt động trước đó
CÓ THỂ hiển thị các thành phần gần đây được liên kết dưới dạng một nhóm di chuyển cùng nhau.
NÊN kích hoạt hành động chuyển đổi nhanh giữa 2 ứng dụng được sử dụng gần đây nhất khi nhấn phím chức năng gần đây 2 lần.
NÊN kích hoạt chế độ nhiều cửa sổ chia đôi màn hình (nếu được hỗ trợ) khi nhấn và giữ phím hàm gần đây.

Các phương thức triển khai thiết bị được liệt kê là MỞ RỘNG để sử dụng giao diện người dùng Android ngược dòng (hoặc một giao diện tương tự dựa trên hình thu nhỏ) cho màn hình tổng quan.

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

Android có hỗ trợ chức năng Quản lý dữ liệu đầu vào và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba. Những cách triển khai thiết bị cho phép người dùng sử dụng các phương thức nhập của bên thứ ba trên thiết bị 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ư đã xác định trong tài liệu SDK Android.

Những cách triển khai thiết bị nhằm khai báo tính năng android.software.input_methods 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. Các quá trình triển khai thiết bị PHẢI hiển thị giao diện cài đặt theo ý định android.settings.INPUT_METHOD_SETTINGS.

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

API ứng dụng điều khiển từ xa không còn được dùng từ Android 5.0 và thay vào đó là Mẫu thông báo nội dung nghe nhìn. Mẫu này cho phép các ứng dụng đa phương tiện tích hợp với bộ điều khiển chế độ phát hiện trên màn hình khoá. Các quá trình triển khai thiết bị có hỗ trợ màn hình khoá, trừ phi bạn triển khai Android Automotive hoặc Watch, PHẢI hiển thị Thông báo trên màn hình khoá, bao gồm cả Mẫu thông báo nội dung nghe nhìn.

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

Android có hỗ trợ trình bảo vệ màn hình tương tác, trước đây được gọi là Giấc mơ. Trình bảo vệ màn hình cho phép người dùng tương tác với các ứng dụng khi thiết bị kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế để bàn. Các thiết bị Android Watch CÓ THỂ triển khai trình bảo vệ màn hình, nhưng các kiểu triển khai thiết bị khác NÊN hỗ trợ trình bảo vệ màn hình và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình trình bảo vệ màn hình theo ý định android.settings.DREAM_SETTINGS.

3.8.12. Vị trí

Khi thiết bị có cảm biến phần cứng (ví dụ: GPS) có khả năng cung cấp toạ độ vị trí, chế độ vị trí PHẢI hiển thị trong trình đơn Vị trí trong phần Cài đặt.

3.8.13. Unicode và phông chữ

Android có hỗ trợ các ký tự biểu tượng cảm xúc được xác định trong Unicode 9.0. Tất cả quá trình triển khai thiết bị PHẢI có khả năng hiển thị các ký tự biểu tượng cảm xúc này bằng ký tự màu. Đồng thời, khi các phương thức triển khai thiết bị Android có IME, thì thiết bị PHẢI cung cấp phương thức nhập cho người dùng đối với những ký tự biểu tượng cảm xúc này.

Thiết bị cầm tay Android NÊN hỗ trợ màu da và nhiều biểu tượng cảm xúc dành cho gia đình theo quy định trong Báo cáo kỹ thuật của Unicode #51.

Android bao gồm tính năng hỗ trợ phông chữ Roboto 2 với các trọng số khác nhau như Sans-serif-thin, Sans-serif-light,

3.8.14. Nhiều cửa sổ

Quá trình triển khai thiết bị CÓ THỂ chọn không triển khai bất kỳ chế độ nhiều cửa sổ nào. Tuy nhiên, nếu có khả năng hiển thị nhiều hoạt động cùng lúc thì PHẢI triển khai(các) chế độ nhiều cửa sổ đó theo API và hành vi 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 những yêu cầu sau:

Các ứng dụng có thể cho biết liệu chúng có thể hoạt động ở chế độ nhiều cửa sổ trong tệp AndroidManifest.xml hay không, được thể hiện rõ ràng thông qua thuộc tính android:resizeableActivity hoặc ngầm ẩn bằng cách đặt targetSdkVersion > 24. Không được khởi chạy những ứng dụng đã đặt rõ ràng thuộc tính này thành false trong tệp kê khai ở chế độ nhiều cửa sổ. Những ứng dụng không đặt thuộc tính trong tệp kê khai (targetSdkVersion < 24) có thể được chạy ở chế độ nhiều cửa sổ, nhưng hệ thống PHẢI đưa ra cảnh báo rằng ứng dụng có thể không hoạt động như mong đợi ở chế độ nhiều cửa sổ.
Quá trình triển khai thiết bị KHÔNG ĐƯỢC cung cấp chế độ chia đôi màn hình hoặc chế độ hình dạng tự do nếu cả chiều cao và chiều rộng màn hình đều nhỏ hơn 440 dp.
Các quá trình triển khai thiết bị có kích thước màn hình xlarge PHẢI hỗ trợ chế độ dạng tự do.
Các quá trình triển khai thiết bị TV Android PHẢI hỗ trợ chế độ hình trong hình (PIP) cho nhiều cửa sổ và đặt chế độ nhiều cửa sổ PIP ở góc trên cùng bên phải khi tính năng PIP đang BẬT.
Quá trình triển khai thiết bị có hỗ trợ nhiều cửa sổ ở chế độ PIP PHẢI phân bổ ít nhất 240x135 dp cho cửa sổ PIP.
Nếu chế độ nhiều cửa sổ PIP được hỗ trợ, bạn PHẢI dùng phím KeyEvent.KEYCODE_WINDOW để điều khiển cửa sổ PIP; nếu không, khoá PHẢI có sẵn cho hoạt động trên nền trước.

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

Android có các tính năng cho phép các ứng dụng nhận biết bảo mật thực hiện các chức năng quản trị thiết bị ở cấp hệ thống, chẳng hạn như thực thi chính sách mật khẩu hoặc xóa từ xa, thông qua API Quản trị thiết bị Android. Quá trình triển khai thiết bị PHẢI cung cấp phương thức triển khai lớp DevicePolicyManager. Các phương pháp triển khai thiết bị hỗ trợ màn hình khoá bảo mật 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 và báo cáo tính năng nền tảng android.software.device_admin.

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

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

Nếu một hoạt động triển khai thiết bị khai báo tính năng android.software.device_admin thì hoạt động đó PHẢI triển khai việc cấp phép ứng dụng Chủ sở hữu thiết bị của ứng dụng Device Policy (DPC) như được chỉ ra dưới đây:

Khi quá trình triển khai thiết bị chưa được định cấu hình dữ liệu người dùng, quá trình triển khai sẽ:
- PHẢI báo cáo true cho DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị để phản hồi thao tác theo ý định android.app.action.PROVISION_MANAGED_DEVICE.
- PHẢI đăng ký ứng dụng DPC làm ứng dụng Chủ sở hữu thiết bị nếu thiết bị khai báo hỗ trợ Giao tiếp phạm vi gần (NFC) qua cờ tính năng android.hardware.nfc và nhận được thông báo NFC chứa bản ghi có loại MIME MIME_TYPE_PROVISIONING_NFC.
Khi quá trình triển khai thiết bị có dữ liệu người dùng, quá trình triển khai:
- PHẢI báo cáo false cho DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- Không được đăng ký bất kỳ ứng dụng DPC nào làm Ứng dụng chủ sở hữu thiết bị nữa.

Các quá trình triển khai thiết bị CÓ THỂ có một ứng dụng được cài đặt trước thực hiện các chức năng quản trị thiết bị nhưng KHÔNG ĐƯỢC đặt ứng dụng này làm ứng dụng Chủ sở hữu thiết bị khi chưa có sự đồng ý hoặc hành động rõ ràng của người dùng hoặc quản trị viên thiết bị.

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

Nếu quá trình triển khai thiết bị khai báo android.software.managed_users, thì bạn PHẢI có thể đăng ký ứng dụng Trình kiểm soát chính sách thiết bị (DPC) làm chủ sở hữu của Hồ sơ được quản lý mới.

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

Quá trình triển khai thiết bị PHẢI cung cấp các thành phần tương tác sau đây cho người dùng trong giao diện người dùng Cài đặt để cho người dùng biết khi một chức năng hệ thống cụ thể đã bị Trình kiểm soát chính sách thiết bị (DPC) tắt:

Một biểu tượng nhất quán hoặc thuộc tính tương tác khác của người dùng (ví dụ: biểu tượng thông tin AOSP ngược dòng) để thể hiện thời điểm một chế độ cài đặt cụ thể bị Quản trị viên thiết bị hạn chế.
Một thông báo giải thích ngắn gọn do Quản trị viên thiết bị cung cấp qua setShortSupportMessage.
Biểu tượng của ứng dụng DPC.

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

Thiết bị có hỗ trợ hồ sơ được quản lý là các thiết bị:

Khai báo android.software.device_admin (xem phần 3.9 Quản trị thiết bị).
Không phải là thiết bị có RAM thấp (xem phần 7.6.1).
Phân bổ bộ nhớ nội bộ (không thể tháo rời) làm bộ nhớ dùng chung (xem phần 7.6.2).

Các thiết bị có hỗ trợ hồ sơ được quản lý PHẢI:

Khai báo cờ tính năng nền tảng android.software.managed_users .
Hỗ trợ hồ sơ được quản lý thông qua API android.app.admin.DevicePolicyManager.
Chỉ cho phép tạo một và chỉ tạo một hồ sơ được quản lý.
Sử dụng huy hiệu biểu tượng (tương tự như huy hiệu công việc nâng cấp của AOSP) để đại diện cho các ứng dụng và tiện ích được quản lý cũng như các thành phần có huy hiệu khác trên giao diện người dùng như Gần đây và Thông báo.
Hiển thị biểu tượng thông báo (tương tự như huy hiệu công việc nâng cấp của AOSP (Dự án nguồn mở Android)) để cho biết khi nào người dùng đang sử dụng một ứng dụng hồ sơ được quản lý.
Hiện một thông báo ngắn cho biết người dùng đang ở trong hồ sơ được quản lý nếu và khi thiết bị khởi động (ACTION_USER_PRESENT) và ứng dụng trên nền trước nằm trong hồ sơ được quản lý.
Khi có hồ sơ được quản lý, hãy hiện một thuộc tính tương tác trực quan trong Ý định "Chooser" để cho phép người dùng chuyển tiếp ý định từ hồ sơ được quản lý đến người dùng chính hoặc ngược lại, nếu được Trình kiểm soát chính sách thiết bị bật.
Khi có hồ sơ được quản lý, hãy hiển thị các thuộc tính tương tác sau đây cho người dùng cho cả người dùng chính và hồ sơ được quản lý:
- Tính riêng pin, vị trí, dữ liệu di động và mức sử dụng bộ nhớ cho người dùng chính và hồ sơ được quản lý.
- Quản lý độc lập các ứng dụng VPN được cài đặt trong người dùng chính hoặc hồ sơ được quản lý.
- Quản lý độc lập các ứng dụng được cài đặt trong người dùng chính hoặc hồ sơ được quản lý.
- Quản lý độc lập các tài khoản trong người dùng chính hoặc hồ sơ được quản lý.
Đảm bảo trình quay số cài đặt trước, ứng dụng danh bạ và ứng dụng nhắn tin có thể tìm kiếm và tra cứu thông tin người gọi từ hồ sơ được quản lý (nếu có) cùng với các thông tin từ hồ sơ chính, nếu Trình kiểm soát chính sách thiết bị cho phép. Khi danh bạ từ hồ sơ được quản lý hiển thị trong nhật ký cuộc gọi cài đặt trước, giao diện người dùng trong cuộc gọi, thông báo cuộc gọi đang diễn ra và cuộc gọi nhỡ, danh bạ và ứng dụng nhắn tin PHẢI được gắn huy hiệu bằng cùng một huy hiệu dùng để biểu thị các ứng dụng hồ sơ được quản lý.
PHẢI đảm bảo rằng hồ sơ được quản lý đáp ứng tất cả các yêu cầu về bảo mật áp dụng cho thiết bị có bật nhiều người dùng (xem phần 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.
Hỗ trợ khả năng chỉ định một màn hình khoá riêng, đáp ứng các yêu cầu sau để cấp quyền truy cập cho các ứng dụng chạy trong hồ sơ được quản lý.
- Quá trình triển khai thiết bị PHẢI tuân thủ ý định DevicePolicyManager.ACTION_SET_NEW_PASSWORD và hiển thị giao diện để định cấu hình thông tin đăng nhập màn hình khoá riêng biệt cho hồ sơ được quản lý.
- Thông tin đăng nhập màn hình khoá của hồ sơ được quản lý PHẢI sử dụng cùng một cơ chế lưu trữ và quản lý thông tin xác thực như hồ sơ gốc, như được nêu trên Trang web dự án nguồn mở Android
- Chính sách mật khẩu DPC chỉ ĐƯỢC áp dụng cho thông tin đăng nhập màn hình khoá của hồ sơ được quản lý, trừ phi được gọi trên thực thể DevicePolicyManager do getParentProfileInstance trả về.

3,10. Hỗ trợ tiếp cận

Android cung cấp một lớp hỗ trợ tiếp cận giúp người dùng bị khuyết tật sử dụng thiết bị dễ dàng hơn. Ngoài ra, Android cung cấp các API nền tảng cho phép triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho các sự kiện của người dùng và hệ thống, đồng thời tạo các cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng bi xoay/d-pad.

Quá trình triển khai thiết bị bao gồm các yêu cầu sau:

Hoạt động triển khai Android Automotive PHẢI cung cấp phương thức triển khai khung hỗ trợ tiếp cận của Android nhất quán với cách triển khai Android mặc định.
Các phương thức triển khai thiết bị (không bao gồm Android Automotive) PHẢI cung cấp phương thức triển khai khung hỗ trợ tiếp cận của Android nhất quán với phương thức triển khai mặc định của Android.
Triển khai thiết bị (không bao gồm Android Automotive) PHẢI hỗ trợ dịch vụ hỗ trợ tiếp cận của bên thứ ba thông qua android.accessibilityservice API.
Hoạt động triển khai thiết bị (không bao gồm Android Automotive) PHẢI tạo AccessibilityEvents và phân phối các sự kiện này cho tất cả hoạt động triển khai AccessibilityService đã đăng ký theo cách nhất quán với cách triển khai Android mặc định
Triển khai thiết bị (thiết bị Android Automotive và thiết bị Android Watch không loại trừ đầu ra âm thanh), PHẢI cung cấp một cơ chế mà người dùng có thể truy cập để bật và tắt các dịch vụ hỗ trợ tiếp cận, đồng thời PHẢI hiển thị giao diện này theo ý định android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Các hoạt động triển khai thiết bị Android với đầu ra âm thanh được ĐỀ XUẤT NÊN cung cấp cách triển khai các dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương hoặc vượt quá chức năng của các dịch vụ hỗ trợ tiếp cận TalkBack** và Tiếp cận bằng công tắc (https://github.com/google/Talkback).
Các thiết bị Android Watch có đầu ra âm thanh NÊN cung cấp những cách triển khai dịch vụ hỗ trợ tiếp cận trên thiết bị tương đương hoặc vượt quá chức năng của dịch vụ hỗ trợ tiếp cận TalkBack (https://github.com/google/Talkback).
Quá trình triển khai thiết bị PHẢI cung cấp một cơ chế trong quy trình thiết lập có sẵn để người dùng bật các dịch vụ hỗ trợ tiếp cận có liên quan, cũng như các tuỳ chọn để điều chỉnh kích thước phông chữ, kích thước hiển thị và cử chỉ thu phóng.

** Dành cho các ngôn ngữ được tính năng Chuyển văn bản sang lời nói hỗ trợ.

Ngoài ra, xin lưu ý rằng nếu có một dịch vụ hỗ trợ tiếp cận được tải trước, thì dịch vụ đó PHẢI là ứng dụng nhận biết được Khởi động trực tiếp {directBootAware} nếu thiết bị có bộ nhớ được mã hoá bằng tính năng Mã hoá dựa trên tệp (FBE).

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

Android có những API cho phép ứng dụng dùng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ triển khai dịch vụ TTS. Các quá trình triển khai thiết bị để báo cáo tính năng android.hardware.audio.output PHẢI đáp ứng các yêu cầu sau đây liên quan đến khung TTS của Android.

Triển khai Android Automotive:

PHẢI hỗ trợ API khung TTS của Android.
CÓ THỂ hỗ trợ cài đặt công cụ TTS của bên thứ ba. Nếu được hỗ trợ, các đối tác PHẢI cung cấp giao diện mà người dùng có thể truy cập, cho phép người dùng chọn một công cụ TTS để sử dụng ở cấp hệ thống.

Tất cả cách triển khai thiết bị khác:

PHẢI hỗ trợ API khung TTS của Android và PHẢI bao gồm công cụ TTS hỗ trợ các ngôn ngữ có sẵn trên thiết bị. Lưu ý rằng phần mềm nguồn mở Android thượng nguồn bao gồm triển khai công cụ TTS với đầy đủ tính năng.
PHẢI hỗ trợ cài đặt công cụ TTS của bên thứ ba.
PHẢI cung cấp giao diện mà người dùng có thể truy cập để cho phép người dùng chọn một công cụ TTS để sử dụng ở cấp hệ thống.

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

Khung đầu vào cho TV Android (TIF) đơn giản hoá việc phân phối nội dung trực tiếp tới các thiết bị Android TV. TIF cung cấp một API tiêu chuẩn để tạo các mô-đun đầu vào điều khiển thiết bị Android TV. Các quá trình triển khai thiết bị Android TV PHẢI hỗ trợ Khung đầu vào TV.

Các hoạt động triển khai trên thiết bị hỗ trợ TIF PHẢI khai báo tính năng nền tảng android.software.live_tv.

3.12.1. Ứng dụng truyền hình

Mọi phương thức triển khai thiết bị khai báo dịch vụ hỗ trợ Truyền hình trực tuyến PHẢI có một ứng dụng truyền hình (Ứng dụng truyền hình) được cài đặt. Dự án nguồn mở Android cung cấp cách triển khai Ứng dụng truyền hình.

Ứng dụng truyền hình PHẢI cung cấp cơ sở vật chất để cài đặt và sử dụng Kênh truyền hình, đồng thời đáp ứng những yêu cầu sau:

Quá trình triển khai thiết bị PHẢI cho phép cài đặt và quản lý dữ liệu đầu vào dựa trên TIF của bên thứ ba ( dữ liệu đầu vào của bên thứ ba).
Quá trình triển khai thiết bị CÓ THỂ phân tách trực quan giữa đầu vào dựa trên TIF được cài đặt sẵn (dữ liệu đầu vào đã cài đặt) và dữ liệu đầu vào của bên thứ ba.
Quá trình triển khai thiết bị KHÔNG ĐƯỢC hiển thị dữ liệu đầu vào của bên thứ ba nhiều hơn một thao tác điều hướng đơn lẻ ra khỏi Ứng dụng truyền hình (tức là mở rộng danh sách đầu vào của bên thứ ba từ Ứng dụng truyền hình).

3.12.1.1. Hướng dẫn chương trình điện tử

Quá trình triển khai thiết bị Android TV PHẢI hiển thị lớp phủ thông tin và tương tác, PHẢI bao gồm hướng dẫn chương trình điện tử (EPG) được tạo từ các giá trị trong các trường TvContract.Programs. EPG PHẢI đáp ứng các yêu cầu sau:

EPG PHẢI hiển thị thông tin từ tất cả đầu vào đã cài đặt và đầu vào của bên thứ ba.
EPG CÓ THỂ phân tách trực quan giữa dữ liệu đầu vào đã cài đặt và dữ liệu đầu vào của bên thứ ba.
EPG được MÔ HÌNH NÊN DÙNG để hiển thị đầu vào đã cài đặt và đầu vào của bên thứ ba với mức độ nổi bật như nhau. EPG KHÔNG ĐƯỢC hiển thị dữ liệu đầu vào của bên thứ ba nhiều hơn một thao tác điều hướng cách xa các đầu vào đã cài đặt trên EPG.
Khi thay đổi kênh, các quá trình triển khai thiết bị PHẢI hiển thị dữ liệu EPG cho chương trình đang phát.

3.12.1.2. Di chuyển

Ứng dụng TV PHẢI cho phép điều hướng cho các chức năng sau qua phím D-pad, phím Quay lại và phím Home trên(các) thiết bị đầu vào của thiết bị TV Android (ví dụ: điều khiển từ xa, ứng dụng điều khiển từ xa hoặc tay điều khiển trò chơi):

Thay đổi kênh truyền hình
Đang mở EPG
Định cấu hình và điều chỉnh đầu vào dựa trên TIF của bên thứ ba
Đang mở trình đơn Cài đặt

Ứng dụng TV NÊN truyền các sự kiện chính tới đầu vào HDMI thông qua CEC.

3.12.1.3. Liên kết ứng dụng đầu vào TV

Các phương thức triển khai thiết bị Android TV PHẢI hỗ trợ liên kết ứng dụng đầu vào TV, cho phép mọi đầu vào cung cấp đường liên kết hoạt động từ hoạt động hiện tại đến hoạt động khác (tức là một đường liên kết từ chương trình trực tiếp đến nội dung có liên quan). Ứng dụng truyền hình PHẢI hiển thị liên kết ứng dụng đầu vào TV khi được cung cấp.

3.12.1.4. Dịch chuyển thời gian

Các quá trình triển khai thiết bị Android TV PHẢI hỗ trợ dịch chuyển thời gian, cho phép người dùng tạm dừng và tiếp tục nội dung trực tiếp. Quá trình triển khai thiết bị PHẢI cung cấp cho người dùng cách tạm dừng và tiếp tục chương trình đang phát, nếu có cơ chế chuyển đổi thời gian cho chương trình đó.

3.12.1.5. Bản ghi chương trình truyền hình

Các hoạt động triển khai thiết bị Android TV được THÔI NÊN DÙNG để hỗ trợ tính năng ghi TV. Nếu đầu vào TV hỗ trợ tính năng ghi, EPG CÓ THỂ cung cấp một cách ghi lại một chương trình nếu việc ghi lại chương trình đó không bị cấm. Các quá trình triển khai thiết bị PHẢI cung cấp giao diện người dùng để phát các chương trình đã ghi.

3,13. Cài đặt nhanh

Quá trình triển khai thiết bị Android PHẢI bao gồm một thành phần giao diện người dùng Cài đặt nhanh cho phép truy cập nhanh vào các thao tác thường dùng hoặc cần thiết.

Android bao gồm API quicksettings cho phép các ứng dụng bên thứ ba triển khai thẻ thông tin mà người dùng có thể thêm vào cùng với các thẻ thông tin do hệ thống cung cấp trong thành phần giao diện người dùng Cài đặt nhanh. Nếu quá trình triển khai thiết bị có thành phần giao diện người dùng Cài đặt nhanh, thì quá trình triển khai thiết bị đó:

PHẢI cho phép người dùng thêm hoặc xoá thẻ thông tin từ một ứng dụng bên thứ ba vào trình đơn Cài đặt nhanh.
KHÔNG ĐƯỢC tự động thêm trực tiếp ô từ một ứng dụng bên thứ ba vào trình đơn Cài đặt nhanh.
PHẢI hiển thị tất cả các ô do người dùng thêm từ ứng dụng bên thứ ba cùng với các ô cài đặt nhanh do hệ thống cung cấp.

3,14. API giao diện người dùng xe

3.14.1. Giao diện người dùng nội dung nghe nhìn trên xe

Mọi hoạt động triển khai cho thiết bị khai báo tính năng hỗ trợ ô tô PHẢI bao gồm khung giao diện người dùng để hỗ trợ các ứng dụng bên thứ ba sử dụng API MediaBrowser và MediaSession.

Khung giao diện người dùng hỗ trợ các ứng dụng bên thứ ba phụ thuộc vào MediaBrowser và MediaSession có các yêu cầu về hình ảnh như sau:

PHẢI hiển thị biểu tượng MediaItem và biểu tượng thông báo mà không bị thay đổi.
PHẢI hiển thị các mục đó theo mô tả bằng MediaSession, ví dụ: siêu dữ liệu, biểu tượng, hình ảnh.
PHẢI cho thấy tên ứng dụng.
PHẢI có ngăn để trình bày hệ phân cấp MediaBrowser.

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

Quá trình triển khai thiết bị PHẢI cài đặt và chạy các tệp “.apk” của Android do công cụ “aapt” tạo ra trong SDK Android chính thức. Vì lý do này, các hoạt động triển khai thiết bị NÊN sử dụng hệ thống quản lý gói của hoạt động triển khai tham chiếu.

Trình quản lý gói PHẢI hỗ trợ xác minh tệp “.apk” bằng Lược đồ chữ ký APK v2 và ký JAR.

Việc triển khai thiết bị KHÔNG ĐƯỢC mở rộng định dạng .apk, Tệp kê khai Android, mã byte Dalvik hoặc mã byte RenderScript sao cho các tệp đó không được cài đặt và chạy đúng cách trên các thiết bị tương thích khác.

5. Khả năng tương thích đa phương tiện

5.1. Bộ mã hoá và giải mã nội dung đa phương tiện

Triển khai thiết bị—

PHẢI hỗ trợ các định dạng nội dung nghe nhìn cốt lõi được chỉ định trong tài liệu SDK Android, ngoại trừ trường hợp được cho phép rõ ràng trong tài liệu này.
PHẢI hỗ trợ các định dạng nội dung nghe nhìn, bộ mã hoá, bộ giải mã, loại tệp và định dạng vùng chứa được xác định trong các bảng bên dưới và được báo cáo qua MediaCodecList.
PHẢI cũng có thể giải mã tất cả hồ sơ được báo cáo trong CamcorderProfile
PHẢI có khả năng giải mã tất cả định dạng mà mã đó có thể mã hoá. Số liệu này bao gồm tất cả các bit mà bộ mã hoá tạo ra.

Codec NÊN hướng đến độ trễ tối thiểu của bộ mã hoá và giải mã, nói cách khác là bộ mã hoá và giải mã—

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

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

Xin lưu ý rằng cả Google và Open Handset Alliance không tuyên bố rằng các bộ mã hoá và giải mã này không có bằng sáng chế của bên thứ ba. Những người có ý định sử dụng mã nguồn này trong các sản phẩm phần cứng hoặc phần mềm được khuyên rằng việc triển khai mã này, kể cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ chủ bằng sáng chế có liên quan.

5.1.1. Bộ mã hoá và giải mã âm thanh

Định dạng/Codec	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Loại tệp/định dạng vùng chứa được hỗ trợ
Cấu hình MPEG-4 AAC (AAC LC)	BẮT BUỘC ¹	BẮT BUỘC	Hỗ trợ nội dung mono/stereo/5.0/5.1 ² với tốc độ lấy mẫu chuẩn từ 8 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS thô AAC (.aac, giải mã trong Android 3.1 trở lên, mã hoá trong Android 4.0 trở lên, không hỗ trợ ADIF) MPEG-TS (.ts, không tìm kiếm được, Android 3.0 trở lên)
Cấu hình MPEG-4 HE AAC (AAC+)	BẮT BUỘC ¹ (Android 4.1 trở lên)	BẮT BUỘC	Hỗ trợ nội dung mono/stereo/5.0/5.1 ² với tốc độ lấy mẫu chuẩn từ 16 đến 48 kHz.
MPEG-4 HE AACv2 Cấu hình (AAC nâng cao+)		BẮT BUỘC	Hỗ trợ nội dung mono/stereo/5.0/5.1 ² với tốc độ lấy mẫu chuẩn từ 16 đến 48 kHz.
AAC ELD (AAC độ trễ thấp nâng cao)	BẮT BUỘC ¹ (Android 4.1 trở lên)	BẮT BUỘC (Android 4.1 trở lên)	Hỗ trợ nội dung mono/stereo với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
AMR-NB	BẮT BUỘC ³	BẮT BUỘC ³	4,75 đến 12,2 kb/giây được lấy mẫu tại 8 kHz	3GPP (.3gp)
AMR-WB	BẮT BUỘC ³	BẮT BUỘC ³	9 tốc độ từ 6,60 kbit/s đến 23,85 kbit/s được lấy mẫu tại 16 kHz
FLAC		BẮT BUỘC (Android 3.1 trở lên)	Đơn âm/âm thanh nổi (không có đa kênh). Tốc độ lấy mẫu lên đến 48 kHz (nhưng tối đa 44,1 kHz được NÊN sử dụng trên các thiết bị có đầu ra 44,1 kHz, vì bộ lấy mẫu giảm xuống 48 đến 44,1 kHz không bao gồm bộ lọc thông thấp). NÊN DÙNG 16 bit; không áp dụng màu nào cho 24 bit.	Chỉ FLAC (.flac)
MP3		BẮT BUỘC	Đơn âm/âm thanh nổi 8-320Kbps hằng số (CBR) hoặc tốc độ bit biến (VBR)	MP3 (.mp3)
MIDI		BẮT BUỘC	Loại MIDI 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF trên thiết bị di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody	Loại 0 và 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		BẮT BUỘC		Ogg (.ogg) Matroska (.mkv, Android 4.0 trở lên)
PCM/SÓNG	BẮT BUỘC ⁴ (Android 4.1 trở lên)	BẮT BUỘC	PCM tuyến tính 16 bit (tốc độ lên đến giới hạn phần cứng). Các thiết bị PHẢI hỗ trợ tốc độ lấy mẫu cho bản ghi PCM thô ở các tần số 8000, 11025, 16000 và 44100 Hz.	WAVE (.wav)
Opus		BẮT BUỘC (Android 5.0 trở lên)		Tiếng Matroska (.mkv), Ogg(.ogg)

1 Bắt buộc đối với các quá trình triển khai thiết bị xác định android.hardware.Micrô nhưng không bắt buộc khi triển khai thiết bị Android Watch.

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

Giải mã được thực hiện mà không cần trộn giảm (ví dụ: một luồng 5.0 AAC phải được giải mã thành 5 kênh PCM, một luồng 5.1 AAC phải được giải mã thành 6 kênh PCM),
siêu dữ liệu dải động, như định nghĩa trong phần "Điều khiển dải động (DRC)" trong ISO/IEC 14496-3 và các phím DRC android.media.MediaFormat để định cấu hình các hành vi liên quan đến dải động của bộ giải mã âm thanh. Khoá AAC DRC được giới thiệu trong API 21 và là: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL và KEY_AAC_ENCODED_TARGET_LEVEL

3 Bắt buộc đối với việc triển khai thiết bị Android cầm tay.

4 Bắt buộc đối với các hoạt động triển khai thiết bị xác định android.hardware.Microphone, bao gồm cả việc triển khai thiết bị Android Watch.

5.1.2. Bộ mã hoá và giải mã hình ảnh

Định dạng/Codec	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Loại tệp/định dạng vùng chứa được hỗ trợ
JPEG	BẮT BUỘC	BẮT BUỘC	Cơ bản+lũy tiến	JPEG (.jpg)
GIF		BẮT BUỘC		Ảnh GIF (.gif)
PNG	BẮT BUỘC	BẮT BUỘC		PNG (.png)
BMP		BẮT BUỘC		BMP (.bmp)
WebP	BẮT BUỘC	BẮT BUỘC		WebP (.webp)
Thô		BẮT BUỘC		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

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

Bộ mã hoá và giải mã quảng cáo hỗ trợ cấu hình HDR PHẢI hỗ trợ tính năng phân tích cú pháp và xử lý siêu dữ liệu tĩnh HDR.
Nếu một bộ mã hoá và giải mã đa phương tiện quảng cáo tính năng hỗ trợ làm mới nội bộ, thì bộ mã hoá và giải mã đó PHẢI hỗ trợ các khoảng thời gian làm mới trong phạm vi từ 10 – 60 khung hình và hoạt động chính xác trong vòng 20% thời gian làm mới được định cấu hình.
Bộ mã hoá và giải mã video PHẢI hỗ trợ kích thước bộ đệm byte đầu ra và đầu vào sao cho phù hợp với khung nén và không nén có khả năng thực hiện lớn nhất như quy định của tiêu chuẩn và cấu hình, nhưng cũng không được phân bổ quá mức.
Bộ mã hoá và bộ giải mã video PHẢI hỗ trợ định dạng màu linh hoạt YUV420 (COLOR_FormatYUV420 nhịp).

Định dạng/Codec	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Loại tệp được hỗ trợ/ Định dạng vùng chứa
H.263	THÁNG 5	THÁNG 5		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	BẮT BUỘC ²	BẮT BUỘC ²	Xem phần 5.2 và 5.3 để biết chi tiết	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, chỉ âm thanh AAC, không tìm kiếm được, Android 3.0 trở lên)
H.265 HEVC		BẮT BUỘC ⁵	Xem phần 5.3 để biết chi tiết	MPEG-4 (.mp4)
MPEG-2		KHÔNG NÊN DÙNG ⁶	Cấu hình chính	MPEG2–TS
MPEG-4 SP (Danh sách quảng cáo gốc)		BẮT BUỘC ²		3GPP (.3gp)
VP8 ³	BẮT BUỘC ² (Android 4.3 trở lên)	BẮT BUỘC ² (Android 2.3.3 trở lên)	Xem phần 5.2 và 5.3 để biết chi tiết	WebM (.webm) Matroska (.mkv, Android 4.0 trở lên) ⁴
Văn bản 9		BẮT BUỘC ² (Android 4.4 trở lên)	Xem phần 5.3 để biết chi tiết	WebM (.webm) Matroska (.mkv, Android 4.0 trở lên) ⁴

1 Bắt buộc đối với những triển khai thiết bị bao gồm phần cứng máy ảnh và xác định android.hardware.camera hoặc android.hardware.camera.front.

2 Bắt buộc đối với quá trình triển khai thiết bị, ngoại trừ các thiết bị Android Watch.

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

4 quá trình triển khai thiết bị NÊN hỗ trợ ghi tệp Matroska WebM.

5 ĐỀ XUẤT NÊN DÙNG cho Android Automotive, không bắt buộc đối với Android Watch và bắt buộc đối với mọi loại thiết bị khác.

6 Chỉ áp dụng cho hoạt động triển khai thiết bị Android TV.

5.2. Mã hoá video

Bộ mã hoá và giải mã video là không bắt buộc khi triển khai thiết bị Android Watch.

Bộ mã hoá video H.264, VP8, VP9 và HEVC—

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

Bộ mã hoá video H.263 và MPEG-4 NÊN hỗ trợ tốc độ bit có thể định cấu hình động.

Tất cả bộ mã hoá video PHẢI đáp ứng các mục tiêu tốc độ bit sau đây qua hai cửa sổ trượt:

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

5.2.1. H.263

Hoạt động triển khai thiết bị Android bằng bộ mã hoá H.263 PHẢI hỗ trợ Hồ sơ cơ sở cấp 45.

5.2.2. H-264

Triển khai thiết bị Android có hỗ trợ bộ mã hoá và giải mã H.264:

PHẢI hỗ trợ Hồ sơ cơ sở cấp 3.
Tuy nhiên, việc hỗ trợ cho ASO (Sắp xếp Lát cắt tuỳ ý), FMO (Sắp xếp Lát cắt Linh hoạt) và RS (Lát cắt thừa) là KHÔNG BẮT BUỘC. Ngoài ra, để duy trì khả năng tương thích với các thiết bị Android khác, bạn NÊN không sử dụng ASO, FMO và RS cho Hồ sơ cơ sở bằng bộ mã hoá.
PHẢI hỗ trợ các cấu hình mã hoá video SD (Standard Definition — Độ nét chuẩn) trong bảng sau.
NÊN hỗ trợ Cấu hình chính cấp 4.
NÊN hỗ trợ các cấu hình mã hoá video HD (Độ nét cao) như được chỉ ra trong bảng sau.
Ngoài ra, các thiết bị Android TV được liệt kê là tôi muốn mã hoá video HD 1080p ở tốc độ 30 khung hình/giây.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p ¹	HD 1080p ¹
Độ phân giải video	320 x 240 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel
Tốc độ khung hình của video	20 khung hình/giây	30 fps	30 fps	30 fps
Tốc độ bit của video	384 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

1 Khi phần cứng được phần cứng hỗ trợ, nhưng ĐỀ XUẤT NÊN DÙNG đối với các thiết bị Android TV.

5.2.3. Văn bản ảo (VP8)

Quá trình triển khai thiết bị Android có hỗ trợ bộ mã hoá và giải mã VP8 PHẢI hỗ trợ cấu hình mã hoá video SD và PHẢI hỗ trợ các cấu hình mã hoá video HD (Độ nét cao) sau đây.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p ¹	HD 1080p ¹
Độ phân giải video	320 x 180 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel
Tốc độ khung hình của video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

1 Khi được phần cứng hỗ trợ.

5.3. Giải mã video

Bộ mã hoá và giải mã video là không bắt buộc khi triển khai thiết bị Android Watch.

Triển khai thiết bị—

PHẢI hỗ trợ độ phân giải video động và chuyển đổi tốc độ khung hình thông qua các API Android tiêu chuẩn trong cùng một luồng cho tất cả các bộ mã hoá và giải mã VP8, VP9, H.264 và H.265 theo thời gian thực và lên đến độ phân giải tối đa được hỗ trợ bởi mỗi bộ mã hoá và giải mã trên thiết bị.
Triển khai hỗ trợ bộ giải mã Dolby Vision—
PHẢI cung cấp một trình trích xuất có khả năng hỗ trợ Dolby Vision.
PHẢI hiển thị đúng cách nội dung Dolby Vision trên màn hình thiết bị hoặc trên cổng đầu ra video chuẩn (ví dụ: HDMI).
Các phương thức triển khai cung cấp trình trích xuất có khả năng Dolby Vision PHẢI đặt chỉ mục theo dõi của(các) lớp cơ sở tương thích ngược (nếu có) giống với chỉ mục theo dõi của lớp Dolby Vision kết hợp.

5.3.1. MPEG-2

Quá trình triển khai thiết bị Android có bộ giải mã MPEG-2 phải hỗ trợ Main Profile High Level.

5.3.2. H.263

Quá trình triển khai thiết bị Android có bộ giải mã H.263 PHẢI hỗ trợ Hồ sơ cơ sở Cấp 30 và Cấp 45.

5.3.3. MPEG-4

Các quá trình triển khai thiết bị Android với bộ giải mã MPEG-4 PHẢI hỗ trợ Hồ sơ đơn giản cấp 3.

5.3.4. H.264

Triển khai thiết bị Android bằng bộ giải mã H.264:

PHẢI hỗ trợ Hồ sơ chính cấp 3.1 và Hồ sơ cơ sở.
Không bắt buộc phải hỗ trợ ASO (Sắp xếp lát cắt tuỳ ý), FMO (Sắp xếp lát cắt macro linh hoạt) và RS (Lát cắt dư thừa).
PHẢI có khả năng giải mã video có các cấu hình SD (Standard Definition — Độ nét chuẩn) được liệt kê trong bảng sau và được mã hoá bằng các cấu hình Cơ sở và Cấu hình chính Cấp 3.1 (bao gồm cả 720p30).
NÊN có khả năng giải mã video có cấu hình HD (Độ nét cao) như được chỉ ra trong bảng sau.
Ngoài ra, các thiết bị Android TV:
- PHẢI hỗ trợ High Profile Cấp 4.2 và HD 1080p60 giải mã hồ sơ.
- PHẢI có khả năng giải mã video có cả cấu hình HD như nêu trong bảng sau và được mã hoá bằng Cấu hình cơ sở, Cấu hình chính hoặc Cấu hình cao Cấp 4.2

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p ¹	HD 1080p ¹
Độ phân giải video	320 x 240 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel
Tốc độ khung hình của video	30 fps	30 fps	60 khung hình/giây	30 khung hình/giây (60 khung hình/giây ²)
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	8 Mb/giây	20 Mb/giây

BẮT BUỘC đối với trường hợp chiều cao theo báo cáo của phương thức Display.getSupportedModes() bằng hoặc lớn hơn độ phân giải của video.

2 BẮT BUỘC đối với việc triển khai thiết bị Android TV.

5.3.5. H.265 (HEVC)

Các cách triển khai thiết bị Android, khi hỗ trợ bộ mã hoá và giải mã H.265 như mô tả trong mục 5.1.3:

PHẢI hỗ trợ cấp Chính của Hồ sơ chính cấp 3 và các cấu hình giải mã video SD như nêu trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau nếu có một bộ giải mã phần cứng.
Ngoài ra, các thiết bị Android TV:
PHẢI hỗ trợ cấu hình giải mã HD 720p.
ĐỀ XUẤT NÊN hỗ trợ cấu hình giải mã HD 1080p. Nếu cấu hình giải mã HD 1080p được hỗ trợ, nó PHẢI hỗ trợ cấu hình chính cấp 4.1.
NÊN hỗ trợ cấu hình giải mã UHD. Nếu cấu hình giải mã UHD được hỗ trợ, thì bộ mã hoá và giải mã PHẢI hỗ trợ cấu hình Cấp chính Main10 cấp 5.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	352 x 288 pixel	720 x 480 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
Tốc độ khung hình của video	30 fps	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây ¹)	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

1 BẮT BUỘC đối với việc triển khai thiết bị Android TV có giải mã phần cứng H.265.

5.3.6. Văn bản ảo (VP8)

Các cách triển khai thiết bị Android, khi hỗ trợ bộ mã hoá và giải mã VP8 như mô tả trong phần 5.1.3:

PHẢI hỗ trợ các cấu hình giải mã SD trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD trong bảng sau.
Các thiết bị Android TV PHẢI hỗ trợ cấu hình giải mã HD 1080p60.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p ¹	HD 1080p ¹
Độ phân giải video	320 x 180 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel
Tốc độ khung hình của video	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây ²)	30 (60 khung hình/giây ²)
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	8 Mb/giây	20 Mb/giây

BẮT BUỘC đối với trường hợp chiều cao theo báo cáo của phương thức Display.getSupportedModes() bằng hoặc lớn hơn độ phân giải của video.

2 BẮT BUỘC đối với việc triển khai thiết bị Android TV.

5.3.7. Văn bản 9

Các cách triển khai thiết bị Android, khi hỗ trợ bộ mã hoá và giải mã VP9 như mô tả trong phần 5.1.3:

PHẢI hỗ trợ các cấu hình giải mã video SD như được chỉ ra trong bảng sau.
NÊN hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ ra trong bảng sau, nếu có một bộ giải mã phần cứng.
Ngoài ra, các thiết bị Android TV:
- PHẢI hỗ trợ cấu hình giải mã HD 720p.
- KHÔNG NÊN hỗ trợ cấu hình giải mã HD 1080p.
- NÊN hỗ trợ cấu hình giải mã UHD. Nếu cấu hình giải mã video UHD được hỗ trợ, nó PHẢI hỗ trợ độ sâu màu 8 bit và PHẢI hỗ trợ Cấu hình 2 (10 bit).

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p	HD 1080p	UHD
Độ phân giải video	320 x 180 pixel	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel	3840 x 2160 pixel
Tốc độ khung hình của video	30 fps	30 fps	30 fps	30 khung hình/giây (60 khung hình/giây ¹)	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

1 BẮT BUỘC đối với việc triển khai thiết bị Android TV có giải mã phần cứng VP9.

5,4. Ghi âm

Mặc dù một số yêu cầu được nêu trong phần này được nêu là NÊN kể từ Android 4.3, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai được lên kế hoạch thay đổi các yêu cầu này thành PHẢI. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những yêu cầu được nêu là NÊN làm, nếu không, các thiết bị đó sẽ không thể đạt được khả năng tương thích với Android khi được nâng cấp lên phiên bản trong tương lai.

5.4.1. Thu âm thanh thô

Các quá trình triển khai trên thiết bị để khai báo android.hardware.Micrô PHẢI cho phép thu thập nội dung âm thanh thô có các đặc điểm sau:

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

Việc chụp các tốc độ lấy mẫu ở trên PHẢI được thực hiện mà không cần tăng tần số lấy mẫu và mọi quá trình giảm tần số lấy mẫu PHẢI bao gồm bộ lọc khử răng cưa thích hợp.

Các quá trình triển khai thiết bị để khai báo android.hardware.Microphone NÊN cho phép thu thập nội dung âm thanh thô có các đặc điểm sau:

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

Nếu chụp cho các tốc độ lấy mẫu ở trên được hỗ trợ, thì việc chụp PHẢI được thực hiện mà không lấy mẫu tăng ở bất kỳ tỷ lệ nào cao hơn 16000:22050 hoặc 44100:48000. Mọi việc tăng tần số lấy mẫu hoặc giảm tần số lấy mẫu PHẢI bao gồm bộ lọc khử răng cưa thích hợp.

5.4.2. Chụp để nhận dạng giọng nói

Nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION PHẢI hỗ trợ chụp ở một trong các tốc độ lấy mẫu, 44100 và 48000.

Ngoài các thông số kỹ thuật ghi âm nêu trên, khi một ứng dụng bắt đầu ghi luồng âm thanh bằng nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

Thiết bị PHẢI thể hiện các đặc điểm biên độ phẳng so với tần số gần đúng: cụ thể là ± 3 dB, từ 100 Hz đến 4000 Hz.
Độ nhạy đầu vào âm thanh PHẢI được đặt sao cho nguồn mức công suất âm thanh (SPL) 90 dB ở 1000 Hz mang lại RMS 2500 cho mẫu 16 bit.
Mức biên độ PCM NÊN theo dõi tuyến tính SPL đầu vào thay đổi trên ít nhất một phạm vi 30 dB từ -18 dB đến +12 dB và 90 dB SPL tại micrô.
Tổng méo hài tất cả PHẢI nhỏ hơn 1% đối với 1 kHz ở mức đầu vào SPL 90 dB tại micrô.
Xử lý giảm tiếng ồn, nếu có, PHẢI tắt.
Điều khiển khuếch đại tự động, nếu có, PHẢI được tắt.

Nếu nền tảng hỗ trợ các công nghệ khử tiếng ồn được điều chỉnh để nhận dạng lời nói, thì hiệu ứng này PHẢI có thể điều khiển được qua android.media.audiofx.NoiseSuppressor API. Ngoài ra, trường UUID cho bộ mô tả hiệu ứng của bộ khử tiếng ồn PHẢI xác định duy nhất từng cách triển khai công nghệ khử tiếng ồn.

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

Lớp android.media.MediaRecorder.AudioSource bao gồm nguồn âm thanh REMOTE_SUBMIX. Các thiết bị khai báo android.hardware.audio.output PHẢI triển khai đúng nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng sử dụng API android.media.AudioRecord để ghi từ nguồn âm thanh này, ứng dụng đó có thể thu thập kết hợp tất cả các luồng âm thanh ngoại trừ những điều sau:

LUÔN_BIỂU NGỮ
STREAM_ALARM
STREAM_INFORMATION

5,5. Phát âm thanh

Những cách triển khai thiết bị có khai báo android.hardware.audio.output PHẢI tuân thủ các yêu cầu trong mục này.

5.5.1. Phát âm thanh thô

Thiết bị PHẢI cho phép phát nội dung âm thanh thô có các đặc điểm sau:

Định dạng : PCM tuyến tính, 16 bit
Tốc độ lấy mẫu : 8000, 11025, 16000, 22050, 32000, 44100
Kênh : Đơn âm, Âm thanh nổi

Thiết bị PHẢI cho phép phát nội dung âm thanh thô có các đặc điểm sau:

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

5.5.2. Hiệu ứng âm thanh

Android cung cấp một API cho hiệu ứng âm thanh để triển khai thiết bị. Các quá trình triển khai thiết bị khai báo tính năng android.hardware.audio.output:

PHẢI hỗ trợ các hoạt động triển khai Effect_TYPE_EQUALIZER và Effect_TYPE_LOUDNESS_ENHANCER có thể điều khiển thông qua các lớp con AudioEffect Equalizer, LoudnessNâng cao.
PHẢI hỗ trợ việc triển khai API của trình hiển thị hình ảnh, có thể kiểm soát thông qua lớp Visualr.
NÊN hỗ trợ các hoạt động triển khai Effect_TYPE_BASS_BOOST, Effect_TYPE_ENV_REVERB, Effect_TYPE_Preset_REVERB và BRAND_TYPE_VIRTUALIZER có thể điều khiển được thông qua các lớp con AudioEffect như Bass Boost, EnvironmentalReverb, PresetReverb và Virtualizer.

5.5.3. Âm lượng đầu ra âm thanh

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

Quá trình triển khai thiết bị Android Automotive NÊN cho phép điều chỉnh âm lượng âm thanh riêng biệt theo từng luồng âm thanh bằng cách sử dụng loại nội dung hoặc cách sử dụng như xác định trong AudioAttributes và mức sử dụng âm thanh trên ô tô như được xác định công khai trong android.car.CarAudioManager .

5,6. Độ trễ âm thanh

Độ trễ âm thanh là độ trễ thời gian khi tín hiệu âm thanh truyền qua một hệ thống. Nhiều loại ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng âm thanh theo thời gian thực.

Trong phần này, hãy sử dụng các định nghĩa sau:

độ trễ đầu ra . Khoảng thời gian từ khi một ứng dụng ghi một khung dữ liệu được mã hoá bằng PCM cho đến khi âm thanh tương ứng hiện ra với môi trường thông qua bộ chuyển đổi trên thiết bị hoặc tín hiệu rời khỏi thiết bị qua một cổng và có thể quan sát được từ bên ngoài.
độ trễ đầu ra nguội . Độ trễ đầu ra cho khung hình đầu tiên, khi hệ thống đầu ra âm thanh ở trạng thái rảnh và tắt nguồn trước khi yêu cầu.
độ trễ đầu ra liên tục . Độ trễ đầu ra cho các khung hình tiếp theo, sau khi thiết bị phát âm thanh.
độ trễ đầu vào . Khoảng thời gian giữa thời điểm môi trường truyền âm thanh đến thiết bị tại bộ chuyển đổi hoặc tín hiệu trên thiết bị đi vào thiết bị qua cổng và thời điểm ứng dụng đọc khung dữ liệu mã PCM tương ứng.
bị mất dữ liệu đầu vào . Phần ban đầu của tín hiệu đầu vào không sử dụng được hoặc không sử dụng được.
độ trễ đầu vào nguội . Tổng thời gian đầu vào bị mất và độ trễ đầu vào cho khung hình đầu tiên, khi hệ thống đầu vào âm thanh không hoạt động và bị tắt nguồn trước khi yêu cầu.
độ trễ đầu vào liên tục . Độ trễ đầu vào cho các khung hình tiếp theo trong khi thiết bị đang ghi âm.
biến động đầu ra nguội . Sự thay đổi giữa các phép đo riêng biệt về giá trị độ trễ đầu ra nguội.
biến động đầu vào nguội . Sự thay đổi giữa các phép đo riêng biệt về giá trị độ trễ đầu vào nguội.
độ trễ trọn vòng liên tục . Tổng độ trễ đầu vào liên tục cộng với độ trễ đầu ra liên tục cộng với 1 khoảng thời gian đệm. Khoảng thời gian đệm cho phép ứng dụng có thời gian xử lý tín hiệu và có thời gian để ứng dụng giảm thiểu tình trạng chênh lệch pha giữa luồng đầu vào và đầu ra.
API hàng đợi bộ đệm PCM OpenSL ES . Bộ API OpenSL ES liên quan đến PCM trong Android NDK.

Các quá trình triển khai thiết bị khai báo android.hardware.audio.output are lá chắn được đề xuất để đáp ứng hoặc vượt quá những yêu cầu này về đầu ra âm thanh:

độ trễ đầu ra nguội từ 100 mili giây trở xuống
độ trễ đầu ra liên tục từ 45 mili giây trở xuống
giảm thiểu sự biến động đầu ra nguội

Nếu quá trình triển khai thiết bị đáp ứng các yêu cầu của phần này sau bất kỳ quá trình hiệu chỉnh ban đầu nào khi sử dụng API hàng đợi bộ đệm OpenSL ES PCM, để độ trễ đầu ra liên tục và độ trễ đầu ra nguội trên ít nhất một thiết bị đầu ra âm thanh được hỗ trợ, bạn NÊN báo cáo tính năng hỗ trợ âm thanh có độ trễ thấp bằng cách báo cáo tính năng android.hardware.audio.low_Latency qua lớp android.content.pm.PackageManager. Ngược lại, nếu quá trình triển khai thiết bị không đáp ứng các yêu cầu này thì KHÔNG ĐƯỢC báo cáo việc hỗ trợ âm thanh có độ trễ thấp.

Các phương thức triển khai thiết bị bao gồm android.hardware.receive

độ trễ đầu vào nguội từ 100 mili giây trở xuống
độ trễ đầu vào liên tục từ 30 mili giây trở xuống
độ trễ trọn vòng liên tục từ 50 mili giây trở xuống
giảm thiểu biến động đầu vào nguội

5,7. Giao thức mạng

Thiết bị PHẢI hỗ trợ giao thức mạng truyền thông để phát âm thanh và video như đã chỉ định trong tài liệu về SDK Android. Cụ thể, các thiết bị PHẢI hỗ trợ các giao thức mạng truyền thông sau đây:

Truyền phát liên tục HTTP(S)
Tất cả các định dạng vùng chứa và bộ mã hoá và giải mã bắt buộc trong mục 5.1 PHẢI được hỗ trợ qua HTTP(S)
Giao thức dự thảo Phát trực tuyến HTTP, Phiên bản 7
Các định dạng phân đoạn phương tiện sau PHẢI được hỗ trợ:

Định dạng phân đoạn	(Các) tệp đối chiếu	Hỗ trợ bộ mã hoá và giải mã bắt buộc
Luồng truyền tải MPEG-2	ISO 13818	Bộ mã hoá và giải mã video: H264 AVC MPEG-4 SP (Danh sách quảng cáo gốc) MPEG-2 Xem phần 5.1.3 để biết chi tiết về H264 AVC, MPEG2-4 SP, và MPEG-2. Bộ mã hoá và giải mã âm thanh: (chuẩn) AAC Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC.
AAC với tính năng lấy khung hình ADTS và thẻ ID3	ISO 13818-7	Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
WebVTT	WebVTT

Định dạng phân đoạn

(Các) tệp đối chiếu

Hỗ trợ bộ mã hoá và giải mã bắt buộc

Luồng truyền tải MPEG-2

ISO 13818

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

H264 AVC
MPEG-4 SP (Danh sách quảng cáo gốc)
MPEG-2

Xem phần 5.1.3 để biết chi tiết về H264 AVC, MPEG2-4 SP,
và MPEG-2.

Bộ mã hoá và giải mã âm thanh:

(chuẩn) AAC

Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC.

AAC với tính năng lấy khung hình ADTS và thẻ ID3

ISO 13818-7

Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC

WebVTT

RTSP (RTP, SDP)

Cấu hình video âm thanh RTP và các bộ mã hoá và giải mã có liên quan PHẢI được hỗ trợ. Để biết các trường hợp ngoại lệ, vui lòng xem chú thích cuối trang trong phần 5.1.

Tên hồ sơ	(Các) tệp đối chiếu	Hỗ trợ bộ mã hoá và giải mã bắt buộc
H264 AVC	RFC 6184	Xem phần 5.1.3 để biết chi tiết về H264 AVC
MP4A – Mỹ La-tinh	RFC 6416	Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
H263 – 1998	RFC 3551 RFC 4629 RFC 2190	Xem phần 5.1.3 để biết thông tin chi tiết về H263
H263 – 2000	RFC 4629	Xem phần 5.1.3 để biết thông tin chi tiết về H263
AMR (giờ AMR)	RFC 4867	Xem phần 5.1.1 để biết chi tiết về AMR-NB
AMR-WB	RFC 4867	Xem phần 5.1.1 để biết chi tiết về AMR-WB
MP4V-ES	RFC 6416	Xem phần 5.1.3 để biết chi tiết về MPEG-4 SP
mpeg4 chung	RFC 3640	Xem phần 5.1.1 để biết chi tiết về AAC và các biến thể của AAC
MP2T	RFC 2250	Xem Luồng truyền tải MPEG-2 bên dưới Phát trực tiếp HTTP để biết chi tiết

5,8. Nội dung nghe nhìn bảo mật

Các quá trình triển khai thiết bị hỗ trợ đầu ra video an toàn và có khả năng hỗ trợ các nền tảng bảo mật PHẢI khai báo khả năng hỗ trợ Display.FLAG_SECURE. Các quá trình triển khai thiết bị tuyên bố có hỗ trợ Display.FLAG_SECURE, nếu chúng hỗ trợ giao thức hiển thị không dây, PHẢI bảo mật đường liên kết bằng cơ chế được mã hoá mạnh như HDCP 2.x trở lên cho màn hình không dây Miracast. Tương tự, nếu các thiết bị này hỗ trợ màn hình bên ngoài có dây, thì các cách triển khai thiết bị PHẢI hỗ trợ HDCP 1.2 trở lên. Các thiết bị TV Android PHẢI hỗ trợ HDCP 2.2 cho các thiết bị hỗ trợ độ phân giải 4K và HDCP 1.4 trở lên cho độ phân giải thấp hơn. Việc triển khai nguồn mở Android ngược dòng bao gồm việc hỗ trợ màn hình không dây (Miracast) và màn hình có dây (HDMI) đáp ứng yêu cầu này.

5,9. Giao diện kỹ thuật số nhạc cụ (MIDI)

Nếu quá trình triển khai thiết bị hỗ trợ việc truyền tải phần mềm MIDI giữa các ứng dụng (thiết bị MIDI ảo) đồng thời hỗ trợ MIDI trên tất cả các phương thức truyền tải phần cứng có khả năng MIDI sau đây (cung cấp khả năng kết nối chung không phải MIDI), thì bạn nên báo cáo việc hỗ trợ cho tính năng android.software.midi thông qua lớp android.content.pm.PackageManager.

Các công cụ truyền tải phần cứng có hỗ trợ MIDI là:

Chế độ hỗ trợ USB (phần 7.7 USB)
Chế độ thiết bị ngoại vi USB (mục 7.7 USB)
MIDI trên Bluetooth LE hoạt động với vai trò trung tâm (phần 7.4.3 Bluetooth)

Ngược lại, nếu quá trình triển khai thiết bị cung cấp kết nối chung không phải MIDI qua một phương thức truyền tải phần cứng cụ thể có khả năng MIDI được nêu ở trên nhưng không hỗ trợ MIDI qua phương thức truyền phần cứng đó, thì tính năng này KHÔNG ĐƯỢC hỗ trợ cho tính năng android.software.midi.

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

Nếu một phương thức triển khai thiết bị đáp ứng tất cả các yêu cầu sau, thì phương thức triển khai đó là tôi tôi ĐỀ XUẤT DÙNG ĐỂ báo cáo hỗ trợ cho tính năng android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager.

Việc triển khai thiết bị PHẢI báo cáo hỗ trợ cho tính năng android.hardware.audio.low_Latency.
Độ trễ âm thanh trọn vòng liên tục, như được định nghĩa trong phần 5.6 Độ trễ âm thanh, PHẢI là 20 mili giây trở xuống và PHẢI là 10 mili giây trở xuống trên ít nhất một đường dẫn được hỗ trợ.
Nếu thiết bị có giắc cắm âm thanh 4 dây dẫn 3, 5 mm, độ trễ âm thanh trọn vòng liên tục PHẢI là 20 mili giây trở xuống trên đường dẫn giắc âm thanh và PHẢI là 10 mili giây trở xuống tại đường dẫn giắc âm thanh.
Quá trình triển khai thiết bị PHẢI bao gồm(các) cổng USB hỗ trợ chế độ máy chủ USB và chế độ thiết bị ngoại vi USB.
Chế độ máy chủ USB PHẢI triển khai lớp âm thanh USB.
Nếu thiết bị có cổng HDMI, việc triển khai thiết bị PHẢI hỗ trợ đầu ra ở dạng âm thanh nổi và tám kênh ở độ sâu 20 bit hoặc 24 bit và 192 kHz mà không mất độ sâu bit hoặc lấy mẫu lại.
Việc triển khai thiết bị PHẢI hỗ trợ báo cáo cho tính năng android.software.midi.
Nếu thiết bị có giắc cắm âm thanh 4 dây dẫn 3,5 mm, việc triển khai thiết bị là được liệt kê để tuân thủ phần Thông số kỹ thuật của thiết bị di động (jack) của Thông số kỹ thuật của tai nghe có dây (v1.1).

Các yêu cầu về độ trễ và âm thanh USB PHẢI được đáp ứng bằng API hàng đợi bộ đệm PCM OpenSL ES.

Ngoài ra, một quá trình triển khai thiết bị báo cáo có hỗ trợ tính năng này PHẢI:

Cung cấp hiệu suất CPU ổn định trong khi âm thanh vẫn hoạt động.
Giảm thiểu độ không chính xác và độ trôi của đồng hồ âm thanh so với giờ chuẩn.
Giảm thiểu độ trôi xung nhịp âm thanh tương ứng với CLOCK_MONOTONIC của CPU khi cả hai đều đang hoạt động.
Giảm thiểu độ trễ âm thanh trên bộ chuyển đổi trên thiết bị.
Giảm thiểu độ trễ âm thanh qua âm thanh kỹ thuật số USB.
Ghi lại dữ liệu đo độ trễ âm thanh trên tất cả đường dẫn.
Giảm thiểu dao động trong thời gian nhập lệnh gọi lại hoàn thành vùng đệm âm thanh, vì điều này ảnh hưởng đến tỷ lệ phần trăm băng thông CPU đầy đủ có thể sử dụng bằng lệnh gọi lại.
Cung cấp âm thanh vượt quá mức (đầu ra) hoặc tình trạng vượt quá âm thanh (đầu vào) trong mức sử dụng bình thường với độ trễ được báo cáo.
Cung cấp mức chênh lệch về độ trễ liên kênh bằng 0.
Giảm thiểu độ trễ trung bình MIDI trên tất cả phương thức truyền tải.
Giảm thiểu sự biến đổi độ trễ MIDI trong quá trình tải (dao động) trên tất cả các phương thức truyền tải.
Cung cấp dấu thời gian MIDI chính xác trên mọi phương thức truyền tải.
Giảm thiểu tiếng ồn tín hiệu âm thanh trên các bộ chuyển đổi trên thiết bị, bao gồm cả khoảng thời gian ngay sau khi khởi động nguội.
Cung cấp chênh lệch xung nhịp âm thanh bằng 0 giữa phía đầu vào và đầu ra của các điểm cuối tương ứng, khi cả hai đều đang hoạt động. Ví dụ về các thiết bị đầu cuối tương ứng bao gồm micrô và loa trên thiết bị hoặc giắc cắm âm thanh đầu vào và đầu ra.
Xử lý lệnh gọi lại hoàn thành vùng đệm âm thanh cho đầu vào và đầu ra của các điểm cuối tương ứng trên cùng một luồng khi cả hai đều hoạt động, đồng thời nhập lệnh gọi lại đầu ra ngay sau khi trả về từ lệnh gọi lại đầu vào. Hoặc nếu không thể xử lý các lệnh gọi lại trên cùng một luồng, hãy nhập lệnh gọi lại đầu ra ngay sau khi nhập lệnh gọi lại đầu vào để cho phép ứng dụng có thời gian nhất quán cho phía đầu vào và đầu ra.
Giảm thiểu sự chênh lệch pha giữa bộ đệm âm thanh HAL cho phía đầu vào và đầu ra của các điểm cuối tương ứng.
Giảm thiểu độ trễ chạm.
Giảm thiểu sự thay đổi độ trễ chạm trong quá trình tải (dao động).

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

Kể từ Android 7.0, một nguồn ghi âm mới đã được thêm vào. Bạn có thể truy cập vào tệp này bằng nguồn âm thanh android.media.MediaRecorder.AudioSource.UNPROCESSED. Trong OpenSL ES, bạn có thể truy cập vào trình ghi này bằng giá trị đặt trước bản ghi SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Một thiết bị PHẢI đáp ứng tất cả các yêu cầu sau đây để báo cáo khả năng hỗ trợ nguồn âm thanh chưa xử lý thông qua thuộc tính android.media.AudioManager PROPERTY_UPDATE_AUDIO_SOURCE_UNỠ Hình thức:

Thiết bị PHẢI thể hiện các đặc tính biên độ-so với tần số phẳng gần như ở dải tần giữa: cụ thể là ±10dB từ 100 Hz đến 7000 Hz.
Thiết bị PHẢI thể hiện các mức biên độ trong dải tần số thấp: cụ thể là từ ±20 dB từ 5 Hz đến 100 Hz so với dải tần giữa.
Thiết bị PHẢI thể hiện các mức biên độ trong dải tần cao: cụ thể là từ ±30 dB từ 7000 Hz đến 22 KHz so với dải tần số trung.
Độ nhạy đầu vào âm thanh PHẢI được đặt sao cho nguồn âm hình sin 1000 Hz phát ở Mức áp suất âm thanh (SPL) 94 dB tạo ra phản hồi có RMS 520 cho 16 mẫu bit (hoặc -36 dB Tỷ lệ đầy đủ cho mẫu dấu phẩy động/độ chính xác kép).
SNR > 60 dB (khác biệt giữa 94 dB SPL và SPL tương đương của nhiễu tự, trọng số A).
Tổng độ méo hài PHẢI nhỏ hơn 1% đối với 1 kHZ ở mức đầu vào SPL 90 dB tại micrô.
Hoạt động xử lý tín hiệu duy nhất được phép trong đường dẫn là hệ số cấp để đưa mức đó đến phạm vi mong muốn. Hệ số mức này KHÔNG ĐƯỢC gây ra độ trễ hoặc độ trễ cho đường dẫn tín hiệu.
Không cho phép xử lý tín hiệu nào khác trong đường dẫn, chẳng hạn như Kiểm soát khuếch đại tự động, Bộ lọc thông cao hoặc Khử tiếng vọng. Nếu hoạt động xử lý tín hiệu có trong cấu trúc vì bất kỳ lý do gì, thì bạn PHẢI tắt tính năng này và tạo độ trễ bằng 0 hoặc độ trễ bổ sung cho đường dẫn tín hiệu một cách hiệu quả.

Tất cả các phép đo SPL được thực hiện ngay bên cạnh micrô đang được kiểm tra.

Đối với nhiều cấu hình micrô, những yêu cầu này áp dụng cho từng micrô.

NÊN DÙNG một thiết bị đáp ứng nhiều yêu cầu đối với đường dẫn tín hiệu cho nguồn ghi chưa được xử lý; tuy nhiên, thiết bị phải đáp ứng tất cả các yêu cầu nêu trên nếu tuyên bố hỗ trợ nguồn âm thanh chưa xử lý.

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

6.1. Công cụ dành cho nhà phát triển

Quá trình triển khai thiết bị PHẢI hỗ trợ Công cụ cho nhà phát triển Android được cung cấp trong SDK Android. Các thiết bị tương thích với Android PHẢI tương thích với:

Cầu gỡ lỗi Android (adb)
- Quá trình triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được nêu trong SDK Android, bao gồm cả dumpsys.
- Trình nền adb phía thiết bị PHẢI không hoạt động theo mặc định và PHẢI có một cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android. Nếu quá trình triển khai thiết bị bỏ qua chế độ thiết bị ngoại vi USB, thì quá trình triển khai PHẢI triển khai Cầu gỡ lỗi Android thông qua mạng cục bộ (chẳng hạn như Ethernet hoặc 802.11).
- Android có hỗ trợ adb bảo mật. adb bảo mật bật adb trên các máy chủ đã xác thực đã biết. Các quá trình triển khai thiết bị PHẢI hỗ trợ adb bảo mật.
Dịch vụ theo dõi gỡ lỗi Dalvik (ddms)
- Quá trình triển khai thiết bị PHẢI hỗ trợ tất cả các tính năng ddms như được ghi trong SDK Android.
- Vì ddms sử dụng adb, nên theo mặc định, hỗ trợ cho ddms PHẢI không hoạt động nhưng PHẢI được hỗ trợ bất cứ khi nào người dùng kích hoạt Cầu gỡ lỗi Android, như ở trên.
Monkey Quá trình triển khai thiết bị PHẢI bao gồm khung Monkey và cung cấp khung cho các ứng dụng sử dụng.
SysTrace
- Quá trình triển khai thiết bị PHẢI hỗ trợ công cụ systrace như được ghi trong SDK Android. Theo mặc định, Systrace phải không hoạt động và PHẢI có cơ chế mà người dùng có thể truy cập để bật Systrace.
- Hầu hết các hệ thống dựa trên Linux và hệ thống Apple Macintosh đều nhận dạng thiết bị Android bằng bộ công cụ SDK Android tiêu chuẩn mà không cần hỗ trợ thêm; tuy nhiên, các hệ thống của Microsoft Windows thường yêu cầu trình điều khiển cho các thiết bị Android mới. (Ví dụ: mã nhà cung cấp mới và đôi khi mã thiết bị mới yêu cầu phải có trình điều khiển USB tuỳ chỉnh cho hệ thống Windows.)
- Nếu công cụ adb không nhận dạng được quá trình triển khai thiết bị như được cung cấp trong SDK Android tiêu chuẩn, thì trình triển khai thiết bị PHẢI cung cấp trình điều khiển Windows cho phép nhà phát triển kết nối với thiết bị bằng giao thức adb. Các trình điều khiển này PHẢI được cung cấp cho Windows XP, Windows Vista, Windows 7, Windows 8 và Windows 10 ở cả hai phiên bản 32 bit và 64 bit.

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

Android có tính năng hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Quá trình triển khai thiết bị PHẢI tuân thủ ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiển thị các cài đặt liên quan đến việc phát triển ứng dụng. Quá trình triển khai Android ngược dòng sẽ ẩn trình đơn Tuỳ chọn cho nhà phát triển theo mặc định và cho phép người dùng chạy Tuỳ chọn cho nhà phát triển sau khi nhấn bảy (7) lần trên phần Cài đặt > Giới thiệu về thiết bị > Mục trong trình đơn Build Number (Số bản dựng). Quá trình triển khai thiết bị PHẢI mang lại trải nghiệm nhất quán cho Tuỳ chọn cho nhà phát triển. Cụ thể, các quá trình triển khai thiết bị PHẢI ẩn Tuỳ chọn cho nhà phát triển theo mặc định và PHẢI cung cấp cơ chế bật Tuỳ chọn cho nhà phát triển nhất quán với quá trình triển khai Android ngược dòng.

Quá trình triển khai Android Automotive CÓ THỂ giới hạn quyền truy cập vào trình đơn Tuỳ chọn cho nhà phát triển bằng cách ẩn hoặc tắt trình đơn khi xe đang chuyển động.

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

Nếu thiết bị bao gồm một thành phần phần cứng cụ thể có API tương ứng cho các nhà phát triển bên thứ ba, thì việc triển khai thiết bị PHẢI triển khai API đó theo mô tả trong tài liệu SDK Android. Nếu một API trong SDK tương tác với một thành phần phần cứng được cho là không bắt buộc và quá trình triển khai thiết bị không sở hữu thành phần đó:

Định nghĩa lớp đầy đủ (như trong tài liệu của SDK) cho các API thành phần vẫn PHẢI được trình bày.
Các hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo một cách nào đó hợp lý.
Các phương thức API PHẢI trả về giá trị rỗng nếu tài liệu SDK cho phép.
Phương thức API PHẢI trả về hoạt động triển khai không hoạt động của các lớp mà tài liệu về SDK không cho phép sử dụng giá trị rỗng.
Các phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được ghi nhận trong tài liệu SDK.

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

Quá trình triển khai thiết bị PHẢI báo cáo nhất quán thông tin cấu hình phần cứng chính xác thông qua phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager cho cùng một vân tay số của bản dựng.

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

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

Các đơn vị được tham chiếu theo yêu cầu trong mục này được định nghĩa như sau:

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

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

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

Thiết bị Android Watch (chi tiết trong phần 2) CÓ THỂ có kích thước màn hình nhỏ hơn như mô tả trong phần này.

Khung giao diện người dùng Android hỗ trợ nhiều kích thước màn hình và cho phép các ứng dụng truy vấn kích thước màn hình của thiết bị (còn gọi là “bố cục màn hình”) thông qua android.content.res.Configuration.screenLayout với SCREENLAYOUT_SIZE_MASK. Quá trình triển khai thiết bị PHẢI báo cáo kích thước màn hình chính xác như đã xác định trong tài liệu SDK Android và được xác định theo nền tảng Android ngược dòng. Cụ thể, các quá trình triển khai thiết bị PHẢI báo cáo kích thước màn hình chính xác theo kích thước màn hình pixel không phụ thuộc vào mật độ logic (dp) sau đây.

Thiết bị PHẢI có kích thước màn hình tối thiểu là 426 dp x 320 dp ("nhỏ"), trừ phi đó là thiết bị Android Watch.
Các thiết bị báo cáo kích thước màn hình "bình thường" PHẢI có kích thước màn hình ít nhất là 480 dp x 320 dp.
Các thiết bị báo cáo kích thước màn hình "lớn" PHẢI có kích thước màn hình ít nhất là 640 dp x 480 dp.
Các thiết bị báo cáo kích thước màn hình "xlarge" PHẢI có kích thước màn hình ít nhất là 960 dp x 720 dp.

Ngoài ra:

Các thiết bị Android Watch PHẢI có màn hình với kích thước đường chéo vật lý trong khoảng từ 1,1 đến 2,5 inch.
Thiết bị Android Automotive PHẢI có màn hình có kích thước đường chéo thực lớn hơn hoặc bằng 6 inch.
Thiết bị Android Automotive PHẢI có kích thước màn hình tối thiểu là 750 dp x 480 dp.
Các kiểu triển khai thiết bị Android khác, có màn hình tích hợp vật lý, PHẢI có màn hình có kích thước đường chéo thực tối thiểu là 2,5 inch.

Thiết bị KHÔNG ĐƯỢC thay đổi kích thước màn hình được báo cáo bất cứ lúc nào.

Các ứng dụng có thể tuỳ ý cho biết chúng hỗ trợ những kích thước màn hình nào thông qua <supports-screens> trong tệp AndroidManifest.xml. Quá trình triển khai thiết bị PHẢI tôn trọng chính xác các ứng dụng đã nêu rõ khả năng hỗ trợ cho các màn hình nhỏ, bình thường, lớn và cực lớn, như mô tả trong tài liệu về SDK Android.

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

Mặc dù không có quy định hạn chế nào đối với giá trị tỷ lệ khung hình của màn hình thực tế, nhưng tỷ lệ khung hình của bề mặt hiển thị các ứng dụng bên thứ ba và có thể lấy từ các giá trị được báo cáo qua DisplayMetrics PHẢI đáp ứng các yêu cầu sau:

Nếu uiMode được định cấu hình là UI_MODE_TYPE_WATCH, thì giá trị tỷ lệ khung hình CÓ THỂ được đặt là 1,0 (1:1).
Nếu ứng dụng bên thứ ba cho biết ứng dụng có thể đổi kích thước thông qua thuộc tính android:resizeableActivity, thì sẽ không có quy định hạn chế nào đối với giá trị tỷ lệ khung hình.
Đối với tất cả các trường hợp khác, tỷ lệ khung hình PHẢI là một giá trị từ 1.3333 (4:3) đến 1.86 (khoảng 16:9), trừ phi ứng dụng đã chỉ ra rõ ràng rằng ứng dụng hỗ trợ tỷ lệ khung hình màn hình cao hơn thông qua giá trị siêu dữ liệu maxAspectRatio.

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

Khung giao diện người dùng Android xác định một tập hợp mật độ logic chuẩn để giúp nhà phát triển ứng dụng nhắm mục tiêu đến các tài nguyên ứng dụng. Quá trình triển khai thiết bị PHẢI chỉ báo cáo một trong các mật độ khung Android logic sau đây thông qua API android.util.DisplayMetrics, đồng thời PHẢI thực thi các ứng dụng ở mật độ chuẩn này và KHÔNG ĐƯỢC thay đổi giá trị bất cứ lúc nào đối với màn hình mặc định.

120 dpi (ldpi)
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi)
360 dpi (360dpi)
400 dpi (400dpi)
420 dpi (420dpi)
480 dpi (xxhdpi)
560 dpi (560dpi)
640 dpi (xxxhdpi)

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

Các quá trình triển khai thiết bị được HÔM NÊN DÙNG để cung cấp cho người dùng chế độ cài đặt giúp thay đổi kích thước màn hình. Nếu có một phương thức triển khai để thay đổi kích thước hiển thị của thiết bị, thì phương thức đó PHẢI phù hợp với phương thức triển khai AOSP (Dự án nguồn mở Android) như được chỉ ra bên dưới:

Kích thước màn hình KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ lớn hơn 1,5 lần mật độ gốc hoặc tạo ra kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320dp (tương đương với bộ hạn định tài nguyên sw320dp), tuỳ theo điều kiện nào đến trước.
Kích thước hiển thị KHÔNG ĐƯỢC điều chỉnh theo tỷ lệ nhỏ hơn 0,85 lần mật độ gốc.
Để đảm bảo khả năng hữu dụng và kích thước phông chữ nhất quán, bạn nên cung cấp tỷ lệ sau của các tuỳ chọn Hiển thị gốc (đồng thời tuân thủ các giới hạn nêu trên)
Nhỏ: 0,85x
Mặc định: 1x (Tỷ lệ hiển thị gốc)
Lớn: 1,15x
Lớn hơn: 1,3x
Lớn nhất 1,45x

7.1.2. Chỉ số hiển thị

Các quá trình triển khai thiết bị PHẢI báo cáo giá trị chính xác cho mọi chỉ số hiển thị được xác định trong android.util.DisplayMetrics và PHẢI báo cáo cùng một giá trị, bất kể màn hình được nhúng hay màn hình bên ngoài có được dùng làm màn hình mặc định hay không.

7.1.3. Hướng màn hình

Các thiết bị PHẢI báo cáo hướng màn hình mà thiết bị hỗ trợ (android.hardware.screen.portrait và/hoặc android.hardware.screen.landscape) và PHẢI báo cáo ít nhất một hướng được hỗ trợ. Ví dụ: Một thiết bị có màn hình ngang theo hướng cố định, chẳng hạn như TV hoặc máy tính xách tay, NÊN chỉ báo cáo android.hardware.screen.landscape.

Các thiết bị báo cáo cả hai hướng màn hình 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ể. Quá trình triển khai thiết bị CÓ THỂ chọn hướng dọc hoặc ngang làm hướng mặc định.

Thiết bị PHẢI báo cáo giá trị chính xác cho hướng hiện tại của thiết bị mỗi khi được truy vấn qua android.content.res.Configuration.Orientation, android.view.Display.getOrientation() hoặc các API khác.

Các thiết bị 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.

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

Các quá trình triển khai thiết bị PHẢI hỗ trợ cả OpenGL ES 1.0 và 2.0, như được thể hiện và chi tiết trong tài liệu về SDK Android. Các quá trình triển khai thiết bị NÊN hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2 trên các thiết bị có khả năng hỗ trợ. Quá trình triển khai thiết bị cũng PHẢI hỗ trợ Android RenderScript, như đã nêu chi tiết trong tài liệu SDK Android.

Việc triển khai thiết bị cũng PHẢI tự xác định chính xác là hỗ trợ OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 hoặc OpenGL 3.2. Tức là:

Các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) PHẢI hỗ trợ báo cáo cho OpenGL ES 1.0 và OpenGL ES 2.0.
Các API OpenGL C/C++ gốc (API có sẵn cho các ứng dụng thông qua libGLES_v1CM.so, libGLES_v2.so, hoặc libEGL.so) PHẢI hỗ trợ báo cáo cho OpenGL ES 1.0 và OpenGL ES 2.0.
Các triển khai thiết bị tuyên bố hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2 PHẢI hỗ trợ các API được quản lý tương ứng và bao gồm hỗ trợ cho API C/C++ gốc. Trên các triển khai thiết bị có khai báo hỗ trợ cho OpenGL ES 3.0, 3.1 hoặc 3.2 libGLESv2.Vì vậy, PHẢI xuất các biểu tượng hàm tương ứng ngoài các biểu tượng hàm OpenGL ES 2.0.

Android cung cấp gói tiện ích OpenGL ES với các giao diện Java và dịch vụ hỗ trợ riêng cho chức năng đồ hoạ nâng cao như tessellation và định dạng nén kết cấu ASTC. Các quá trình triển khai cho thiết bị Android PHẢI hỗ trợ gói tiện ích nếu thiết bị đó hỗ trợ OpenGL ES 3.2 và CÓ THỂ hỗ trợ gói này nếu không. Nếu gói tiện ích được hỗ trợ toàn bộ, thiết bị PHẢI xác định khả năng hỗ trợ thông qua cờ tính năng android.hardware.opengles.aep.

Ngoài ra, việc triển khai thiết bị CÓ THỂ triển khai mọi tiện ích OpenGL ES mong muốn. Tuy nhiên, các hoạt động triển khai thiết bị PHẢI báo cáo qua API gốc và API do OpenGL ES quản lý, tất cả các chuỗi tiện ích mà chúng hỗ trợ, và ngược lại KHÔNG ĐƯỢC báo cáo các chuỗi tiện ích không được hỗ trợ.

Lưu ý rằng Android có hỗ trợ các ứng dụng tuỳ ý chỉ định rằng các ứng dụng đó yêu cầu định dạng nén hoạ tiết OpenGL cụ thể. Những định dạng này thường dành riêng cho từng nhà cung cấp. Android không yêu cầu triển khai thiết bị để triển khai bất kỳ định dạng nén kết cấu cụ thể nào. Tuy nhiên, các API này PHẢI báo cáo chính xác mọi định dạng nén kết cấu mà chúng hỗ trợ, thông qua phương thức getString() trong API OpenGL.

Android có một cơ chế để các ứng dụng khai báo rằng ứng dụng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp Ứng dụng, Hoạt động, Cửa sổ hoặc Chế độ xem thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp.

Các quá trình triển khai trên thiết bị 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 Android View API (API Khung hiển thị của Android).

Ngoài ra, các quá trình triển khai thiết bị PHẢI thể hiện hành vi phù hợp với tài liệu SDK Android về tính năng tăng tốc phần cứng.

Android chứa một đối tượng TextureView cho phép nhà phát triển tích hợp trực tiếp các kết cấu OpenGL ES được tăng tốc phần cứng dưới dạng mục tiêu kết xuất trong hệ phân cấp giao diện người dùng. Các quá trình triển khai thiết bị PHẢI hỗ trợ API TextureView và PHẢI thể hiện hành vi nhất quán với phương thức triển khai Android ngược dòng.

Android có hỗ trợ EGL_ANDROID_RECORDABLE, một thuộc tính EGLConfig cho biết liệu EGLConfig có hỗ trợ kết xuất sang ANativeWindow có ghi hình ảnh vào video hay không. Quá trình triển khai thiết bị PHẢI hỗ trợ tiện ích EGL_ANDROID_RECORDABLE.

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

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

Android Automotive không hỗ trợ chế độ tương thích cũ.
Tất cả cách triển khai thiết bị khác PHẢI bao gồm khả năng hỗ trợ chế độ tương thích của ứng dụng cũ như được triển khai bằng mã nguồn mở Android ngược dòng. Tức là các hoạt động triển khai thiết bị KHÔNG ĐƯỢC thay đổi điều kiện kích hoạt hoặc ngưỡng mà chế độ tương thích được kích hoạt và KHÔNG ĐƯỢC thay đổi hành vi của chính chế độ tương thích.

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

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

Thiết bị PHẢI hỗ trợ màn hình có khả năng kết xuất đồ hoạ màu 16 bit và hỗ trợ màn hình có khả năng kết xuất đồ hoạ màu 24 bit.
Các thiết bị PHẢI hỗ trợ màn hình có khả năng kết xuất ảnh động.
Công nghệ hiển thị PHẢI có tỷ lệ khung hình điểm ảnh (PAR) nằm trong khoảng từ 0,9 đến 1,15. Tức là, tỷ lệ khung hình pixel PHẢI gần hình vuông (1.0) với dung sai 10 ~ 15%.

7.1.7. Màn hình phụ

Android hỗ trợ màn hình phụ để cho phép khả 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 bên ngoài. Nếu thiết bị hỗ trợ màn hình bên ngoài qua kết nối màn hình bổ sung có dây, không dây hoặc nhúng, thì việc triển khai thiết bị PHẢI triển khai API trình quản lý màn hình theo mô tả trong tài liệu SDK Android.

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

Thiết bị PHẢI hỗ trợ màn hình cảm ứng hoặc đáp ứng các yêu cầu nêu trong 7.2.2 về điều hướng không chạm.

7.2.1. Bàn phím

Các quá trình triển khai Android Watch và Android Automotive CÓ THỂ triển khai bàn phím mềm. Tất cả cách triển khai khác cho thiết bị PHẢI triển khai bàn phím mềm và:

Triển khai thiết bị:

PHẢI bao gồm tính năng hỗ trợ cho Khung quản lý đầu vào (cho phép nhà phát triển bên thứ ba tạo Trình chỉnh sửa phương thức nhập – tức là bàn phím mềm) như thông tin chi tiết tại http://developer.android.com.
PHẢI cung cấp ít nhất một cách triển khai bàn phím mềm (bất kể có bàn phím cứng hay không) ngoại trừ các thiết bị Android Watch có kích thước màn hình khiến việc sử dụng bàn phím mềm trở nên kém hợp lý hơn.
CÓ THỂ bao gồm cả những cách triển khai bàn phím mềm khác.
CÓ THỂ bao gồm bàn phím phần cứng.
KHÔNG ĐƯỢC bao gồm bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard (QWERTY hoặc phím 12 phím).

7.2.2. Điều hướng không chạm

Thiết bị Android TV PHẢI hỗ trợ D-pad.

Triển khai thiết bị:

CÓ THỂ bỏ qua tuỳ chọn điều hướng không cảm ứng (bi xoay, d-pad hoặc bánh xe) nếu thiết bị triển khai không phải là thiết bị Android TV.
PHẢI báo cáo giá trị chính xác cho android.content.res.Configuration.navigation.
PHẢI cung cấp cơ chế giao diện người dùng thay thế hợp lý để lựa chọn và chỉnh sửa văn bản, tương thích với Công cụ quản lý đầu vào. Việc triển khai nguồn mở Android ngược dòng bao gồm một cơ chế lựa chọn phù hợp để sử dụng với các thiết bị thiếu đầu vào điều hướng không chạm.

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

Yêu cầu về khả năng sử dụng và chế độ hiển thị của các hàm Home (Trang chủ), Recents (Gần đây) và Back (Quay lại) sẽ khác nhau giữa các loại thiết bị như mô tả trong phần này.

Các hàm Home, Recents (Gần đây) và Back (Quay lại) (được ánh xạ tới các sự kiện chính KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK tương ứng) rất cần thiết đối với mô hình điều hướng trong Android và do đó:

Hoạt động triển khai Thiết bị Android cầm tay PHẢI cung cấp các hàm Home (Trang chủ), Recents (Gần đây) và Back (Quay lại).
Các quá trình triển khai thiết bị Android TV PHẢI cung cấp chức năng Home (Màn hình chính) và Back (Quay lại).
Triển khai thiết bị Android Watch PHẢI có hàm Home (Trang chủ) cho người dùng và hàm Back (Quay lại) trừ phi người dùng có thể sử dụng hàm này trong UI_MODE_TYPE_WATCH .
Việc triển khai thiết bị Android Watch và không có loại thiết bị Android nào khác, CÓ THỂ sử dụng sự kiện nhấn và giữ đối với sự kiện chính KEYCODE_BACK, đồng thời loại bỏ sự kiện đó để không gửi đến ứng dụng trên nền trước.
Hoạt động triển khai Android Automotive PHẢI cung cấp hàm Home (Trang chủ) và CÓ THỂ cung cấp các hàm Back (Quay lại) và hàm Recent (Gần đây).
Mọi kiểu triển khai thiết bị khác PHẢI cung cấp hàm Home (Trang chủ) và hàm Back (Quay lại).

Các chức năng này CÓ THỂ được triển khai thông qua các nút vật lý chuyên dụng (chẳng hạn như nút cảm ứng cơ học hoặc điện dung) hoặc CÓ THỂ được triển khai bằng các phím phần mềm chuyên dụng trên một phần riêng biệt của màn hình, cử chỉ, bảng điều khiển cảm ứng, v.v. Android hỗ trợ cả hai cách triển khai. Tất cả các hàm này 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 hiển thị.

Hàm Gần đây, nếu được cung cấp, PHẢI có một nút hoặc biểu tượng hiển thị, trừ phi hàm điều hướng này bị ẩn cùng với các hàm điều hướng khác ở chế độ toàn màn hình. Điều này không áp dụng cho những thiết bị nâng cấp từ các phiên bản Android cũ có các nút vật lý để điều hướng và không có phím gần đây.

Các hàm Màn hình chính và Quay lại, nếu được cung cấp, mỗi hàm PHẢI có một nút hoặc biểu tượng hiển thị trừ phi bị ẩn cùng với các chức năng điều hướng khác ở chế độ toàn màn hình hoặc khi giao diện uiMode UI_MODE_TYPE_MASK được đặt thành UI_MODE_TYPE_WATCH.

Kể từ Android 4.0, chức năng Trình đơn không còn được dùng nữa và thay vào đó là thanh thao tác. Do đó, các hoạt động triển khai thiết bị mới vận chuyển với Android 7.0 trở lên KHÔNG ĐƯỢC triển khai nút vật lý chuyên dụng cho chức năng Trình đơn. Các cách triển khai thiết bị cũ KHÔNG ĐƯỢC triển khai nút vật lý chuyên dụng cho chức năng Trình đơn, nhưng nếu nút Trình đơn thực được triển khai và thiết bị đang chạy các ứng dụng có targetSdkVersion > 10, việc triển khai thiết bị:

PHẢI hiển thị nút mục bổ sung thao tác trên thanh thao tác khi nút này xuất hiện và cửa sổ bật lên trình đơn mục bổ sung thao tác kết quả không được để trống. Đối với quá trình triển khai thiết bị ra mắt trước Android 4.4 nhưng nâng cấp lên Android 7.0, mục này được NÊN DÙNG.
KHÔNG ĐƯỢC sửa đổi vị trí của cửa sổ bật lê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.
CÓ THỂ hiển thị cửa sổ bật lên mục bổ sung thao tác tại vị trí đã sửa đổi trên màn hình khi cửa sổ này hiển thị bằng cách chọn nút trình đơn thực.

Để có khả năng tương thích ngược, việc triển khai thiết bị PHẢI cung cấp chức năng Trình đơn cho các ứng dụng khi targetSdkVersion nhỏ hơn 10, bằng nút vật lý, phím phần mềm hoặc cử chỉ. Hàm Trình đơn này sẽ xuất hiện trừ phi bị ẩn cùng với các hàm điều hướng khác.

Các quá trình triển khai thiết bị Android hỗ trợ Thao tác hỗ trợ và/hoặc VoiceInteractionService PHẢI có thể chạy ứng dụng trợ lý bằng một thao tác tương tác (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi các phím điều hướng khác hiển thị. Bạn KHÔNG NÊN sử dụng thao tác nhấn và giữ trên màn hình chính dưới dạng tương tác này. Hoạt động tương tác đã chỉ định PHẢI khởi chạy ứng dụng trợ lý do người dùng chọn, nói cách khác là ứng dụng triển khai Voicetương tácService, hoặc hoạt động xử lý ý định ACTION_ASSIST.

Quá trình triển khai thiết bị CÓ THỂ sử dụng một phần riêng biệt của màn hình để hiển thị các phím điều hướng. Tuy nhiên, nếu có thì PHẢI đáp ứng các yêu cầu sau:

Các phím điều hướng triển khai thiết bị PHẢI sử dụng một phần riêng biệt của màn hình, không dành cho các ứng dụng và KHÔNG ĐƯỢC che khuất hay can thiệp vào phần màn hình có sẵn cho các ứng dụng.
Quá trình triển khai thiết bị PHẢI cung cấp một phần màn hình cho các ứng dụng đáp ứng các yêu cầu nêu trong mục 7.1.1.
Quá trình triển khai thiết bị PHẢI hiển thị các phím điều hướng khi ứng dụng không chỉ định chế độ giao diện người dùng hệ thống hoặc chỉ định SYSTEM_UI_FLAG_VISIBLE.
Quá trình triển khai thiết bị PHẢI hiển thị các phím điều hướng ở chế độ "cấu hình thấp" (ví dụ: bị làm mờ) không phô trương khi các ứng dụng chỉ định SYSTEM_UI_FLAG_LOW_PROFILE.
Các quá trình triển khai thiết bị PHẢI ẩn các phím điều hướng khi các ứng dụng chỉ định SYSTEM_UI_FLAG_HIDDEN_NAVIGATION.

7.2.4. Nhập vào màn hình cảm ứng

Thiết bị cầm tay và đồng hồ Android PHẢI hỗ trợ nhập bằng màn hình cảm ứng.

Quá trình triển khai thiết bị PHẢI có một hệ thống nhập con trỏ ở dạng nào đó (giống như chuột hoặc cảm ứng). Tuy nhiên, nếu quá trình triển khai thiết bị không hỗ trợ hệ thống nhập con trỏ, thì thiết bị KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.Touchscreen hoặc android.hardware.fakeTouch. Triển khai thiết bị có bao gồm hệ thống nhập con trỏ:

NÊN hỗ trợ con trỏ được theo dõi hoàn toàn độc lập, nếu hệ thống đầu vào của thiết bị hỗ trợ nhiều con trỏ.
PHẢI báo cáo giá trị của android.content.res.Configuration.Touchscreen tương ứng với loại màn hình cảm ứng cụ thể trên thiết bị.

Android hỗ trợ nhiều loại màn hình cảm ứng, bàn di chuột và thiết bị nhập cảm ứng giả. Các phương pháp triển khai thiết bị dựa trên màn hình cảm ứng được liên kết với một màn hình mà người dùng có cảm giác như đang thao tác trực tiếp với các mục trên màn hình. Vì người dùng đang trực tiếp chạm vào màn hình nên hệ thống không yêu cầu bất kỳ thành phần tương tác nào khác để cho biết các đối tượng đang được thao tác. Ngược lại, giao diện cảm ứng giả cung cấp hệ thống nhập cho người dùng mà ước chừng một tập hợp con các tính năng của màn hình cảm ứng. Ví dụ: chuột hoặc điều khiển từ xa điều khiển con trỏ trên màn hình gần đúng với thao tác chạm, nhưng yêu cầu người dùng trỏ hoặc lấy nét trước rồi nhấp. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột không khí dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các tương tác cảm ứng giả. Android có hằng số tính năng android.hardware.fakeTouch, tương ứng với một thiết bị đầu vào không cảm ứng (dựa trên con trỏ) có độ chân thực cao, chẳng hạn như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ phương thức nhập dựa trên cảm ứng (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng chức năng màn hình cảm ứng. Các quá trình triển khai thiết bị để khai báo tính năng cảm ứng giả PHẢI đáp ứng các yêu cầu về cảm ứng giả trong mục 7.2.5.

Quá trình triển khai thiết bị PHẢI báo cáo tính năng chính xác tương ứng với loại dữ liệu đầu vào được sử dụng. Các quá trình triển khai thiết bị có màn hình cảm ứng (một lần chạm hoặc cao hơn) PHẢI báo cáo hằng số tính năng nền tảng android.hardware.Touchscreen. Các quá trình triển khai thiết bị nhằm báo cáo hằng số tính năng nền tảng android.hardware.Touchscreen PHẢI cũng báo cáo hằng số tính năng nền tảng android.hardware.fakeTouch. Các phương pháp triển khai thiết bị không có màn hình cảm ứng (và chỉ dựa vào thiết bị con trỏ) KHÔNG ĐƯỢC báo cáo bất kỳ tính năng màn hình cảm ứng nào và KHÔNG ĐƯỢC báo cáo chỉ android.hardware.fakeTouch nếu đáp ứng các yêu cầu về cảm ứng giả trong mục 7.2.5.

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

Các quá trình triển khai thiết bị khai báo tính năng hỗ trợ android.hardware.fakeTouch:

PHẢI báo cáo vị trí màn hình X và Y tuyệt đối của vị trí con trỏ và hiển thị con trỏ trực quan trên màn hình.
PHẢI báo cáo sự kiện chạm có mã thao tác chỉ định thay đổi trạng thái xảy ra trên con trỏ di chuyển xuống hoặc đi lên trên màn hình.
PHẢI hỗ trợ con trỏ xuống và lên trên một đối tượng trên màn hình để người dùng có thể mô phỏng thao tác nhấn vào một đối tượng trên màn hình.
PHẢI hỗ trợ con trỏ xuống, con trỏ lên, con trỏ xuống rồi con trỏ lên ở cùng một vị trí trên một đối tượng trên màn hình trong một ngưỡng thời gian. Điều này cho phép người dùng mô phỏng thao tác nhấn đúp vào một đối tượng trên màn hình.
PHẢI hỗ trợ con trỏ xuống tại một điểm tuỳ ý trên màn hình, con trỏ di chuyển đến bất kỳ điểm tuỳ ý nào khác trên màn hình, tiếp theo là con trỏ lên để cho phép người dùng mô phỏng thao tác kéo bằng cách chạm.
PHẢI hỗ trợ con trỏ xuống rồi cho phép người dùng nhanh chóng di chuyển đối tượng đến một vị trí khác trên màn hình rồi trỏ lên trên màn hình để người dùng có thể hất một đối tượng trên màn hình.

Các thiết bị khai báo tính năng hỗ trợ android.hardware.fakecontact.multicontact.distinct PHẢI đáp ứng các yêu cầu đối với giả mạo ở trên và PHẢI hỗ trợ theo dõi riêng biệt hai hoặc nhiều đầu vào con trỏ độc lập.

7.2.6. Hỗ trợ tay điều khiển trò chơi

Các quá trình triển khai thiết bị Android TV PHẢI hỗ trợ ánh xạ nút cho tay điều khiển trò chơi như liệt kê dưới đây. Quy trình triển khai Android ngược dòng bao gồm cả phương thức triển khai cho tay điều khiển trò chơi đáp ứng yêu cầu này.

7.2.6.1. Ánh xạ nút

Các hoạt động triển khai thiết bị Android TV PHẢI hỗ trợ các sơ đồ phím sau:

Nút	Sử dụng HID ²	Nút Android
Đáp ¹	Mã: 0x09	KEYCODE_NÚT_A (96)
T ¹	Mã: 0x09	KEYCODE_NÚT_B (97)
X ¹	Mã: 0x09	KEYCODE_NÚT_X (99)
Có ¹	Mã: 0x09	KEYCODE_NÚT_Y (100)
D-pad ngược ¹ D-pad xuống ¹	0x01 0x0039 ³	AXIS_HAT_Y ⁴
D-pad bên trái 1 D-pad phải ¹	0x01 0x0039 ³	AXIS_HAT_X ⁴
Nút vai trái ¹	Mã: 0x09	KEYCODE_NÚT_L1 (102)
Nút vai phải ¹	Mã: 0x09	KEYCODE_NÚT_R1 (103)
Nhấp chuột trái ¹	Mã: 0x09	KEYCODE_NÚT_THUMBL (106)
Nhấp chuột phải ¹	0x09 0x000F	KEYCODE_NÚT_THUMBR (107)
Trang chủ ¹	0x0c 0x0223	KEYCODE_HOME (3)
Quay lại ¹	0x0c 0x0224	KEYCODE_BACK (4)

1 Sự kiện chính

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

3 Việc sử dụng này phải có Tối thiểu logic là 0, Tối đa logic là 7, Tối thiểu vật lý là 0, Tối đa vật lý là 315, Đơn vị tính bằng độ và Kích thước báo cáo là 4. Giá trị logic được xác định là xoay theo chiều kim đồng hồ tính từ trục tung; ví dụ: giá trị logic 0 biểu thị việc không xoay và nút lên được nhấn, trong khi giá trị logic 1 biểu thị góc xoay 45 độ và cả phím lên và trái được nhấn.

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

Nút điều khiển analog ¹	Sử dụng HID	Nút Android
Trình kích hoạt bên trái	0x02 0x00C5	AXIS_L KÍCH HOẠT
điều kiện kích hoạt bên phải	0x02 0x00C4	AXIS_R KÍCH HOẠT
Cần điều khiển bên trái	0x01 0x0030 Mã: 0x01	AXIS_X AXIS_Y
Cần điều khiển bên phải	0x01 0x0032 Mã: 0x01	AXIS_Z AXIS_RZ

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

7.2.7. Điều khiển từ xa

Các quá trình triển khai thiết bị Android TV PHẢI cung cấp điều khiển từ xa để cho phép người dùng truy cập vào giao diện TV. Điều khiển từ xa CÓ THỂ là điều khiển từ xa vật lý hoặc có thể là điều khiển từ xa dựa trên phần mềm có thể truy cập được từ điện thoại di động hoặc máy tính bảng. Điều khiển từ xa PHẢI đáp ứng các yêu cầu được xác định bên dưới.

Khả năng tương tác tìm kiếm . Các quá trình triển khai thiết bị PHẢI kích hoạt KEYCODE_SEARCH khi người dùng gọi tính năng tìm kiếm bằng giọng nói trên điều khiển từ xa thực hoặc phần mềm.
Điều hướng . Tất cả điều khiển từ xa cho TV Android PHẢI bao gồm các nút Quay lại, Trang chủ và Chọn cũng như tính năng hỗ trợ các sự kiện D-pad.

7,3. Cảm biến

Android bao gồm API để truy cập vào nhiều loại cảm biến. Thường thì quá trình triển khai thiết bị CÓ THỂ bỏ qua các cảm biến này, như được nêu trong các tiểu mục sau. Nếu một thiết bị có một loại cảm biến cụ thể có API tương ứng cho các nhà phát triển bên thứ ba, thì việc triển khai thiết bị PHẢI triển khai API đó theo mô tả trong tài liệu SDK Android và tài liệu Nguồn mở Android về cảm biến. Ví dụ: các phương pháp triển khai thiết bị:

PHẢI báo cáo chính xác sự hiện diện hay không có của cảm biến cho mỗi lớp android.content.pm.PackageManager.
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ự.
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ề giá trị true hoặc false khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.).
PHẢI báo cáo tất cả các phép đo cảm biến bằng cách sử dụng các giá trị Hệ thống đơn vị (chỉ số) quốc tế có liên quan cho từng loại cảm biến như quy định trong tài liệu SDK Android.
NÊN báo cáo thời gian sự kiện tính bằng nano giây như xác định trong tài liệu SDK Android, thể hiện thời gian sự kiện đã xảy ra và được đồng bộ hóa với đồng hồ SystemWatch.elapsedRealtimeNano(). Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai. Đây là nơi có thể trở thành thành phần BẮT BUỘC. Lỗi đồng bộ hoá PHẢI dưới 100 mili giây.
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 cảm biến được truyền trực tuyến với độ trễ bắt buộc tối thiểu là 5 ms + 2 * sample_time khi bộ xử lý ứng dụng đang hoạt động. Độ trễ này không bao gồm bất kỳ độ trễ lọc nào.
PHẢI báo cáo mẫu cảm biến đầu tiên trong vòng 400 mili giây + 2 * sample_time kể từ khi cảm biến được kích hoạt. Mẫu này có thể có độ chính xác bằng 0.

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

Một số loại cảm biến là loại cảm biến kết hợp, nghĩa là chúng có thể lấy từ dữ liệu do một hoặc nhiều cảm biến khác cung cấp. (Ví dụ như cảm biến hướng và cảm biến gia tốc tuyến tính.) Quá trình triển khai thiết bị NÊN triển khai các loại cảm biến này khi chúng bao gồm các cảm biến vật lý tiên quyết như mô tả trong các loại cảm biến. Nếu trong quá trình triển khai thiết bị có một cảm biến kết hợp, thì bạn PHẢI triển khai cảm biến theo mô tả trong tài liệu Nguồn mở Android về cảm biến tổng hợp.

Một số cảm biến Android hỗ trợ chế độ kích hoạt "liên tục". Chế độ này sẽ trả về dữ liệu liên tục. Để bất kỳ API nào được nêu trong tài liệu về SDK Android là cảm biến liên tục, các quá trình triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ PHẢI có dao động dưới 3%, trong đó dao động được định nghĩa là độ lệch chuẩn của sự chênh lệch của các giá trị dấu thời gian được báo cáo giữa các sự kiện liên tiếp.

Lưu ý rằng các quá trình triển khai thiết bị PHẢI đảm bảo luồng sự kiện cảm biến KHÔNG ĐƯỢC ngăn CPU của thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức từ trạng thái tạm ngưng.

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

7.3.1. Gia tốc kế

Quá trình triển khai thiết bị PHẢI bao gồm gia tốc kế 3 trục. Thiết bị cầm tay Android, thiết bị triển khai Android Automotive và thiết bị Android Watch ĐƯỢC ĐỀ XUẤT NÊN DÙNG để bao gồm cảm biến này. Nếu quá trình triển khai thiết bị bao gồm gia tốc kế 3 trục, thì quá trình triển khai thiết bị đó:

PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER.
PHẢI có khả năng báo cáo các sự kiện lên đến tần số tối thiểu là 50 Hz đối với các thiết bị Android Watch, vì các thiết bị này có điều kiện ràng buộc về nguồn điện nghiêm ngặt hơn và tần số 100 Hz đối với mọi loại thiết bị khác.
NÊN báo cáo các sự kiện tối thiểu là 200 Hz.
PHẢI tuân thủ hệ thống toạ độ cảm biến Android như được nêu chi tiết trong API Android. Các hoạt động triển khai trên Android Automotive PHẢI tuân thủ hệ thống toạ độ cảm biến ô tô của Android.
PHẢI có khả năng đo từ độ rơi tự do tối đa 4 lần trọng lực (4g) trở lên trên bất kỳ trục nào.
PHẢI có độ phân giải tối thiểu 12 bit và PHẢI có độ phân giải tối thiểu 16 bit.
NÊN được hiệu chỉnh trong khi sử dụng nếu các đặc điểm thay đổi trong vòng đời và được bù trừ, đồng thời duy trì thông số bù giữa các lần khởi động lại thiết bị.
PHẢI được bù nhiệt.
PHẢI có độ lệch chuẩn không lớn hơn 0,05 m/s, trong đó độ lệch chuẩn phải được tính toán trên mỗi trục đối với các mẫu được thu thập trong khoảng thời gian ít nhất là 3 giây ở tốc độ lấy mẫu nhanh nhất.
NÊN triển khai các cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_ bởi chúng tôi, TYPE_STEP_phát hiện, TYPE_STEP_HOWMANY như được mô tả trong tài liệu SDK Android. Các thiết bị Android mới và hiện có NÊN DÙNG để triển khai cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION. Nếu bất kỳ cảm biến nào trong số này được triển khai, tổng mức tiêu thụ năng lượng của chúng PHẢI luôn nhỏ hơn 4 mW và PHẢI nhỏ hơn 2 mW và 0,5 mW khi thiết bị ở điều kiện động hoặc tĩnh.
Nếu bạn có một cảm biến con quay hồi chuyển, PHẢI triển khai cảm biến kết hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION và NÊN triển khai cảm biến kết hợp TYPE_GAME_ROTATION_ chờ). Các thiết bị Android mới và hiện có KHÔNG ĐƯỢC ĐỀ XUẤT để triển khai cảm biến TYPE_GAME_ROTATION_ chờ.
PHẢI triển khai một cảm biến kết hợp TYPE_ROTATION_hdpi, nếu cảm biến con quay hồi chuyển và cảm biến từ kế cũng được bao gồm.

7.3.2. Từ kế

Quá trình triển khai thiết bị PHẢI bao gồm từ kế 3 trục (la bàn). Nếu thiết bị có từ kế 3 trục, thì thiết bị đó:

PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD và cũng NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED. Các thiết bị Android mới và hiện có KHÔNG ĐƯỢC ĐỀ XUẤT để triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED.
PHẢI có khả năng báo cáo các sự kiện ở tần số tối thiểu là 10 Hz và PHẢI báo cáo được các sự kiện lên đến tần số tối thiểu là 50 Hz.
PHẢI tuân thủ hệ thống toạ độ cảm biến Android như được nêu chi tiết trong API Android.
PHẢI có khả năng đo trong khoảng từ -900 μT đến +900 μT trên mỗi trục trước khi bão hoà.
PHẢI có giá trị bù sắt cứng nhỏ hơn 700 μT và NÊN có giá trị dưới 200 μT, bằng cách đặt từ kế cách xa từ trường động (do dòng điện gây ra) và từ trường tĩnh (do nam châm gây ra).
PHẢI có độ phân giải bằng hoặc dày hơn 0,6 μT và NÊN có độ phân giải bằng hoặc dày hơn 0,2 μT.
PHẢI được bù nhiệt.
PHẢI hỗ trợ hiệu chỉnh trực tuyến và bù trừ độ chệch hướng cứng, đồng thời duy trì các thông số bù giữa các lần khởi động lại thiết bị.
PHẢI áp dụng lớp bù sắt mềm. Bạn có thể hiệu chuẩn trong khi sử dụng hoặc trong quá trình sản xuất thiết bị.
NÊN có độ lệch chuẩn, được tính toán trên mỗi trục đối với các mẫu được thu thập trong khoảng thời gian ít nhất 3 giây với tốc độ lấy mẫu nhanh nhất, không lớn hơn 0,5 μT.
PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_INDEX, nếu cảm biến gia tốc kế và cảm biến con quay hồi chuyển cũng được bao gồm.
CÓ THỂ triển khai cảm biến TYPE_GEOMAGNETIC_ROTATION_Bạn chỉ cần triển khai cảm biến gia tốc kế. Tuy nhiên, nếu được triển khai, nó PHẢI tiêu thụ ít hơn 10 mW và NÊN tiêu thụ dưới 3 mW khi cảm biến được đăng ký cho chế độ hàng loạt ở 10 Hz.

7.3.3. GPS

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

NÊN DÙNG thiết bị sẽ tiếp tục phân phối đầu ra GPS/GNSS bình thường cho các ứng dụng trong cuộc gọi điện thoại khẩn cấp và đầu ra vị trí đó không bị chặn trong cuộc gọi điện thoại khẩn cấp.
Nó PHẢI hỗ trợ đầu ra vị trí với tốc độ ít nhất là 1 Hz khi được yêu cầu qua LocationManager#requestLocationUpdate .
Nó PHẢI có thể xác định vị trí trong điều kiện bầu trời mở (tín hiệu mạnh, đa đường không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian nhanh để sửa lần đầu), khi được kết nối với kết nối Internet 0,5 Mbps hoặc tốc độ dữ liệu nhanh hơn. Yêu cầu này thường được đáp ứng bằng cách sử dụng một số dạng kỹ thuật GPS/GNSS được hỗ trợ hoặc dự đoán để giảm thiểu thời gian khoá GPS/GNSS (Dữ liệu hỗ trợ bao gồm Thời gian tham chiếu, Vị trí tham chiếu và Vệ tinh/Đồng hồ vệ tinh).
- Sau khi thực hiện phép tính vị trí như vậy, thiết bị được liệt kê là tôi muốn đề xuất rằng thiết bị có thể xác định vị trí của nó, trên bầu trời mở, trong vòng 10 giây, khi yêu cầu vị trí được khởi động lại, tối đa một giờ sau khi tính toán vị trí ban đầu, ngay cả khi yêu cầu tiếp theo được thực hiện mà không có kết nối dữ liệu và/hoặc sau một chu kỳ nguồn.
Trong điều kiện bầu trời mở sau khi xác định vị trí, khi đứng yên hoặc đang di chuyển với gia tốc dưới 1 mét/giây:
- Nó PHẢI có thể xác định vị trí trong vòng 20 mét và tốc độ trong vòng 0, 5 mét mỗi giây, ít nhất 95% thời gian.
- Nó PHẢI đồng thời theo dõi và báo cáo qua GnssStatus.Callback ít nhất 8 vệ tinh từ một chòm sao.
- Nó PHẢI có thể theo dõi cùng lúc ít nhất 24 vệ tinh, từ nhiều chòm sao (ví dụ: GPS + ít nhất một trong Glonass, Beidou, Galileo).
Lớp này PHẢI báo cáo việc tạo công nghệ GNSS thông qua API kiểm thử "getGnssYearOfHardware".
NÊN đáp ứng và PHẢI đáp ứng tất cả yêu cầu bên dưới nếu quy trình tạo công nghệ GNSS được báo cáo là năm "2016" hoặc phiên bản mới hơn.
- Hệ thống PHẢI báo cáo các phép đo GPS ngay khi tìm thấy, ngay cả khi vị trí được tính bằng GPS/GNSS chưa được báo cáo.
- Nó PHẢI báo cáo tốc độ pseudorange và pseudorange GPS, rằng, trong điều kiện trời mở sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với tốc độ gia tốc dưới 0,2 mét mỗi giây, đủ để tính vị trí trong phạm vi 20 mét và tốc độ trong vòng 0,2 mét mỗi giây, ít nhất là 95% thời gian.

Lưu ý rằng mặc dù một số yêu cầu về GPS ở trên được tuyên bố là tôi ĐỀ XUẤT, nhưng Định nghĩa về khả năng tương thích cho phiên bản lớn tiếp theo dự kiến sẽ thay đổi các yêu cầu này thành PHẢI.

7.3.4. Con quay hồi chuyển

Quá trình triển khai thiết bị PHẢI bao gồm một con quay hồi chuyển (cảm biến thay đổi góc). Các thiết bị KHÔNG NÊN có cảm biến con quay hồi chuyển trừ khi gia tốc kế 3 trục cũng được bao gồm. Nếu quá trình triển khai thiết bị bao gồm con quay hồi chuyển, thì quá trình triển khai đó:

PHẢI triển khai cảm biến TYPE_GYROSCOPE và cũng NÊN triển khai cảm biến TYPE_GYROSCOPE_UNCALIBRATED. Các thiết bị Android mới và hiện có KHÔNG ĐƯỢC ĐỀ XUẤT để triển khai cảm biến SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
PHẢI có khả năng đo các thay đổi về hướng lên đến 1.000 độ mỗi giây.
PHẢI có khả năng báo cáo các sự kiện lên đến tần số tối thiểu là 50 Hz đối với các thiết bị Android Watch, vì các thiết bị này có điều kiện ràng buộc về nguồn điện nghiêm ngặt hơn và tần số 100 Hz đối với mọi loại thiết bị khác.
NÊN báo cáo các sự kiện tối thiểu là 200 Hz.
PHẢI có độ phân giải 12 bit trở lên và PHẢI có độ phân giải từ 16 bit trở lên.
PHẢI được bù nhiệt.
PHẢI được hiệu chỉnh và bù trừ trong khi sử dụng, đồng thời duy trì thông số bù giữa các lần khởi động lại thiết bị.
PHẢI có phương sai không lớn hơn 1e-7 Rad^2 / s^2 mỗi Hz (phương sai mỗi Hz hoặc Rad^2 / s). Phương sai được phép thay đổi theo tốc độ lấy mẫu, nhưng phải bị hạn chế bởi giá trị này. Nói cách khác, nếu bạn đo phương sai của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì nó không nên lớn hơn 1e-7 Rad^2/s^2.
PHẢI triển khai một cảm biến kết hợp TYPE_ROTATION_INDEX, nếu cảm biến gia tốc kế và cảm biến từ kế cũng được bao gồm.
Nếu có cảm biến gia tốc kế, PHẢI triển khai cảm biến kết hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION và NÊN triển khai cảm biến kết hợp TYPE_GAME_ROTATION_MIGRATION. Các thiết bị Android mới và hiện có KHÔNG ĐƯỢC ĐỀ XUẤT để triển khai cảm biến TYPE_GAME_ROTATION_ chờ.

7.3.5. Khí áp kế

Quá trình triển khai thiết bị PHẢI bao gồm khí áp kế (cảm biến áp suất không khí xung quanh). Nếu quá trình triển khai thiết bị bao gồm khí áp kế, thì quá trình triển khai đó:

PHẢI triển khai và báo cáo cảm biến TYPE_PRESSURE.
PHẢI có khả năng phân phối các sự kiện ở tốc độ 5 Hz trở lên.
PHẢI có độ chính xác đủ để cho phép ước tính độ cao.
PHẢI được bù nhiệt.

7.3.6. Nhiệt kế

Quá trình triển khai thiết bị CÓ THỂ bao gồm cả nhiệt kế môi trường xung quanh (cảm biến nhiệt độ). Nếu có, giá trị này PHẢI được xác định là SENSOR_TYPE_AMBIENT_ họat (SENSOR_TYPE_AMBIENT_ họat ) và nó PHẢI đo nhiệt độ môi trường xung quanh (phòng) theo độ C.

Triển khai thiết bị CÓ THỂ nhưng KHÔNG ĐƯỢC bao gồm cảm biến nhiệt độ CPU. Nếu có, thiết bị PHẢI được xác định là SENSOR_TYPE_ Core, đồng thời PHẢI đo nhiệt độ của CPU thiết bị và KHÔNG được đo bất kỳ nhiệt độ nào khác. Lưu ý rằng loại cảm biến SENSOR_TYPE_ Core trong Android 4.0 không còn được dùng nữa.

Đối với các hoạt động triển khai dành cho Android Automotive, SENSOR_TYPE_AMBIENT_ Core PHẢI đo nhiệt độ bên trong cabin xe.

7.3.7. Quang kế

Quá trình triển khai thiết bị CÓ THỂ bao gồm một quang kế (cảm biến ánh sáng môi trường xung quanh).

7.3.8. Cảm biến độ gần

Quá trình triển khai trên thiết bị CÓ THỂ bao gồm cả cảm biến độ gần. Các thiết bị 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 với PHONE_TYPE_NONE trong getPhoneType PHẢI bao gồm cảm biến độ gần. Nếu quá trình triển khai thiết bị có bao gồm cảm biến độ gần, thì cảm biến độ gần sẽ:

PHẢI đo độ gần của một đối tượng theo cùng hướng với màn hình. Tức là cảm biến độ gần PHẢI được định hướng để phát hiện các đối tượng ở gần màn hình, vì mục đích chính của loại cảm biến này là phát hiện một điện thoại mà người dùng đang sử dụng. Nếu trong quá trình triển khai thiết bị bao gồm cảm biến độ gần theo bất kỳ hướng nào khác, thì bạn KHÔNG ĐƯỢC truy cập vào cảm biến đó thông qua API này.
PHẢI có độ chính xác từ 1 bit trở lên.

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

Các quá trình triển khai thiết bị để hỗ trợ một bộ cảm biến chất lượng cao hơn có thể đáp ứng tất cả yêu cầu nêu trong mục này PHẢI xác định khả năng hỗ trợ thông qua cờ tính năng android.hardware.sensor.hifi_sensors.

Một thiết bị khai báo android.hardware.sensor.hifi_sensors PHẢI hỗ trợ tất cả các loại cảm biến sau đây, đáp ứng các yêu cầu về chất lượng như dưới đây:

CẢM BIẾN_TYPE_ACCELEROMETER
- PHẢI có phạm vi đo tối thiểu từ -8 g đến + 8 g.
- PHẢI có độ phân giải đo lường tối thiểu là 1024 LSB/G.
- PHẢI có tần số đo tối thiểu từ 12,5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 400 Hz trở lên.
- PHẢI có độ nhiễu khi đo không được trên 400 uG/.
- PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 3.000 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 3 mW.
- NÊN có độ ổn định thiên vị nhiễu tĩnh <15 μg & Hz từ tập dữ liệu tĩnh 24 giờ.
- NÊN có sự thay đổi độ lệch so với nhiệt độ ≤ +/- 1mg / °C.
- NÊN có độ không tuyến tính phù hợp nhất là ≤ 0,5% và độ thay đổi độ nhạy so với nhiệt độ ≤ 0,03%/C°.
CẢM BIẾN_TYPE_GYROSCOPE
- PHẢI có phạm vi đo lường ít nhất từ -1000 đến +1000 dp.
- PHẢI có độ phân giải đo lường ít nhất là 16 LSB/dp.
- PHẢI có tần số đo tối thiểu từ 12,5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 400 Hz trở lên.
- PHẢI có độ nhiễu khi đo không được lớn hơn 0,014°/s/.
- PHẢI có độ ổn định sai lệch cố định < 0,0002 °/s −Hz từ tập dữ liệu tĩnh 24 giờ.
- NÊN có sự thay đổi độ lệch so với nhiệt độ ≤ +/- 0,05 °/ s / °C.
- NÊN có sự thay đổi về độ nhạy so với nhiệt độ ≤ 0,02% / °C.
- Phải có độ không tuyến tính phù hợp nhất với đường kẻ từ ≤ 0,2%.
- NÊN có mật độ tiếng ồn ≤ 0,007 °/s/tài khoản.
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED với cùng yêu cầu về chất lượng như SENSOR_TYPE_GYROSCOPE.
SENSOR_TYPE_GEOMAGNETIC_FIELD
- Phải có phạm vi đo tối thiểu từ -900 đến +900 uT.
- PHẢI có độ phân giải đo ít nhất là 5 LSB/uT.
- PHẢI có tần số đo tối thiểu từ 5 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 50 Hz trở lên.
- PHẢI có độ nhiễu đo không được lớn hơn 0,5 uT.
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED có cùng yêu cầu về chất lượng như SENSOR_TYPE_GEOMAGNETIC_FIELD và ngoài ra:
- PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 600 sự kiện cảm biến.
SENSOR_TYPE_PRESSURE
- Phải có phạm vi đo ít nhất từ 300 đến 1100 hPa.
- PHẢI có độ phân giải đo ít nhất là 80 LSB/hPa.
- PHẢI có tần số đo tối thiểu từ 1 Hz trở xuống.
- PHẢI có tần số đo tối đa từ 10 Hz trở lên.
- PHẢI có độ nhiễu đo không được trên 2 Pa/{4}Hz.
- PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 300 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 2 mW.
SENSOR_TYPE_GAME_ROTATION_Bạn
- PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 300 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 4 mW.
CẢM BIẾN_TYPE_SIGNIFICANT_MOTION
- Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang chuyển động.
CẢM BIẾN_TYPE_STEP_SCOREOR
- PHẢI triển khai hình thức không đánh thức của cảm biến này với khả năng lưu vào bộ đệm ít nhất 100 sự kiện cảm biến.
- Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang chuyển động.
- PHẢI có mức tiêu thụ điện năng phân lô không thấp hơn 4 mW.
CẢM BIẾN_TYPE_STEP_ tán
- Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị tĩnh và 1,5 mW khi thiết bị đang chuyển động.
CẢM BIẾN_TILT_PHÁT HIỆN
- Công suất tiêu thụ không được nhỏ hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang chuyển động.

Ngoài ra, một thiết bị như vậy PHẢI đáp ứng các yêu cầu sau đây về hệ thống cảm biến phụ:

Dấu thời gian sự kiện của cùng một sự kiện vật lý do Gia tốc kế, cảm biến Con quay hồi chuyển và Từ kế báo cáo PHẢI cách nhau 2,5 mili giây.
Dấu thời gian của sự kiện cảm biến con quay hồi chuyển PHẢI nằm trên cùng cơ sở thời gian với hệ thống con camera và xảy ra lỗi trong phạm vi 1 mili giây.
Các cảm biến có Độ trung thực cao PHẢI gửi mẫu cho các ứ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 cảm biến vật lý.
Mức tiêu thụ điện năng KHÔNG ĐƯỢC cao hơn 0,5 mW khi thiết bị tĩnh và 2,0 mW khi thiết bị đang di chuyển khi bật bất kỳ tổ hợp cảm biến nào sau đây:
- CẢM BIẾN_TYPE_SIGNIFICANT_MOTION
- CẢM BIẾN_TYPE_STEP_SCOREOR
- CẢM BIẾN_TYPE_STEP_ tán
- CẢM BIẾN_TILT_PHÁT BIẾN

Lưu ý rằng tất cả các yêu cầu về mức tiêu thụ điện năng trong phần này không bao gồm mức tiêu thụ điện năng của Bộ xử lý ứng dụng. Nguồn này bao gồm năng lượng do toàn bộ chuỗi cảm biến rút ra – cảm biến, mọi mạch hỗ trợ, bất kỳ hệ thống xử lý cảm biến chuyên dụng nào, v.v.

Các loại cảm biến sau đây cũng CÓ THỂ được hỗ trợ trên quá trình triển khai thiết bị khai báo android.hardware.sensor.hifi_sensors. Tuy nhiên, nếu có các loại cảm biến này thì chúng PHẢI đáp ứng yêu cầu về khả năng lưu vào bộ đệm tối thiểu sau đây:

SENSOR_TYPE_PROXIMITY: 100 sự kiện cảm biến

7.3.10. Cảm biến vân tay

Quá trình triển khai thiết bị có màn hình khoá an toàn PHẢI bao gồm cảm biến vân tay. Nếu quá trình triển khai thiết bị có cảm biến vân tay và có API tương ứng cho nhà phát triển bên thứ ba, thì quá trình triển khai đó:

PHẢI khai báo khả năng hỗ trợ tính năng android.hardware.fingerprint.
PHẢI triển khai đầy đủ API tương ứng như mô tả trong tài liệu SDK Android.
PHẢI có tỷ lệ chấp nhận sai không cao hơn 0,002%.
ĐƯỢC ĐỀ XUẤT NÊN có tỷ lệ từ chối sai dưới 10% theo giá trị được đo trên thiết bị
NÊN DÙNG là có độ trễ dưới 1 giây, được đo từ khi bạn chạm vào cảm biến vân tay cho đến khi màn hình được mở khoá bằng một ngón tay đã đăng ký.
PHẢI thử giới hạn số lần yêu cầu trong ít nhất 30 giây sau 5 lần thử sai để xác minh bằng vân tay.
PHẢI triển khai kho khoá dựa trên phần cứng và thực hiện việc so khớp vân tay trong Môi trường thực thi đáng tin cậy (TEE) hoặc trên chip có kênh bảo mật đến TEE.
Tất cả dữ liệu vân tay nhận dạng phải được mã hoá và xác thực theo mã hoá sao cho không thể thu nạp, đọc hoặc thay đổi chúng bên ngoài Môi trường thực thi đáng tin cậy (TEE) như được nêu trong nguyên tắc triển khai trên trang web Dự án nguồn mở Android.
PHẢI ngăn việc thêm vân tay mà trước đó không thiết lập chuỗi tin cậy bằng cách yêu cầu người dùng xác nhận hiện có hoặc thêm thông tin đăng nhập thiết bị mới (mã PIN/hình mở khoá/mật khẩu) được bảo mật bằng TEE; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện điều đó.
KHÔNG ĐƯỢC cho phép các ứng dụng của bên thứ ba phân biệt giữa các vân tay riêng lẻ.
PHẢI tuân thủ cờ DevicePolicyManager.KEYGbạn_DISABLE_FINGERPrint.
Khi nâng cấp lên từ phiên bản cũ hơn Android 6.0, PHẢI di chuyển dữ liệu vân tay một cách an toàn để đáp ứng các yêu cầu nêu trên hoặc bạn phải xoá dữ liệu này.
NÊN sử dụng biểu tượng Vân tay số Android được cung cấp trong Dự án nguồn mở Android.

7.3.11. Cảm biến chỉ dành cho Android Automotive

Các cảm biến dành riêng cho ô tô được xác định trong android.car.CarSensorManager API .

7.3.11.1. Thiết bị hiện tại

Các nội dung triển khai Android Automotive NÊN cung cấp bánh răng hiện tại dưới dạng SENSOR_TYPE_GEAR.

7.3.11.2. Chế độ ngày đêm

Các quá trình triển khai Android Automotive PHẢI hỗ trợ chế độ ban ngày/ban đêm được xác định là SENSOR_TYPE_NIGHT. Giá trị của cờ này PHẢI nhất quán với chế độ ngày/đêm trên bảng điều khiển và PHẢI dựa trên đầu vào của cảm biến ánh sáng xung quanh. Cảm biến ánh sáng xung quanh bên dưới CÓ THỂ giống với Photometer.

7.3.11.3. Trạng thái lái xe

Các phương thức triển khai Android Automotive PHẢI hỗ trợ trạng thái lái xe được xác định là SENSOR_TYPE_DRIVING_STATUS, với giá trị mặc định là DRIVE_STATUS_UNTIMEOUTED khi xe đã dừng và đỗ hoàn toàn. Nhà sản xuất thiết bị có trách nhiệm định cấu hình SENSOR_TYPE_DRIVING_STATUS theo tất cả luật và quy định áp dụng cho các thị trường nơi sản phẩm được vận chuyển.

7.3.11.4. Tốc độ bánh xe

Các quá trình triển khai Android Automotive PHẢI cung cấp tốc độ của xe được xác định là SENSOR_TYPE_CAR_speed.

7.3.12. Cảm biến tư thế

Quá trình triển khai thiết bị CÓ THỂ hỗ trợ cảm biến tư thế với 6 mức tự do. Các thiết bị Android cầm tay được NÊN hỗ trợ cảm biến này. Nếu cách triển khai thiết bị hỗ trợ cảm biến tư thế với 6 mức tự do, thì thiết bị đó:

PHẢI triển khai và báo cáo cảm biến TYPE_POSE_6DOF.
PHẢI chính xác hơn riêng vectơ xoay.

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

7.4.1. Điện thoại

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

Android CÓ THỂ được sử dụng trên các thiết bị không có phần cứng điện thoại. Điều đó có nghĩa là Android tương thích với các thiết bị không phải là điện thoại. Tuy nhiên, nếu quá trình triển khai thiết bị không bao gồm điện thoại GSM hoặc CDMA, thì PHẢI triển khai hỗ trợ đầy đủ cho API cho công nghệ đó. Các quá trình triển khai thiết bị không bao gồm phần cứng điện thoại PHẢI triển khai API đầy đủ dưới dạng không hoạt động.

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

Quá trình triển khai thiết bị Điện thoại Android PHẢI bao gồm tính năng hỗ trợ chặn số và:

PHẢI triển khai đầy đủ BlockingNumberContract và API tương ứng như mô tả trong tài liệu SDK.
PHẢI chặn tất cả cuộc gọi và tin nhắn từ một số điện thoại trong 'BlockingNumberProvider' mà không cần tương tác với ứng dụng. Trường hợp ngoại lệ duy nhất là khi tính năng chặn số điện thoại tạm thời được gỡ bỏ như mô tả trong tài liệu SDK.
KHÔNG ĐƯỢC ghi vào nhà cung cấp nhật ký cuộc gọi trên nền tảng đối với một cuộc gọi bị chặn.
KHÔNG ĐƯỢC ghi vào Nhà cung cấp dịch vụ điện thoại đối với tin nhắn bị chặn.
PHẢI triển khai giao diện người dùng quản lý các số bị chặn. Giao diện này được mở bằng ý định do phương thức TelecomManager.createManageBlockedNumbersIntent() trả về.
KHÔNG ĐƯỢC cho phép người dùng phụ xem hoặc chỉnh sửa các số bị chặn trên thiết bị 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 tính năng chặn PHẢI được ẩn đối với người dùng phụ và danh sách bị chặn vẫn PHẢI được tuân thủ.
NÊN di chuyển các số bị chặn vào ứng dụng nhà cung cấp khi thiết bị cập nhật lên Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Mọi cách triển khai thiết bị Android PHẢI bao gồm tính năng hỗ trợ một hoặc nhiều dạng 802.11. Nếu quá trình triển khai thiết bị có hỗ trợ 802.11 và hiển thị chức năng cho ứng dụng bên thứ ba, thì thiết bị PHẢI triển khai API Android tương ứng và:

PHẢI báo cáo cờ tính năng phần cứng android.hardware.wifi.
PHẢI triển khai API phát đa hướng như mô tả trong tài liệu SDK.
PHẢI hỗ trợ DNS đa hướng (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) tại bất kỳ thời điểm hoạt động nào bao gồm:
- Ngay cả khi màn hình không ở trạng thái hoạt động.
- Đối với các hoạt động triển khai thiết bị Android TV, ngay cả khi ở trạng thái nguồn ở chế độ chờ.

7.4.2.1. Wi-Fi Direct

Quá trình triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ Wi-Fi Direct (Wi-Fi ngang hàng). Nếu quá trình triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì thiết bị PHẢI triển khai API Android tương ứng như mô tả trong tài liệu SDK. Nếu quá trình triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì quá trình triển khai đó:

PHẢI báo cáo tính năng phần cứng android.hardware.wifi.direct.
PHẢI hỗ trợ hoạt động Wi-Fi thông thường.
NÊN hỗ trợ hoạt động đồng thời Wi-Fi và Wi-Fi Direct.

7.4.2.2. Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi

Quá trình triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS) như mô tả trong Tài liệu về SDK Android. Nếu quá trình triển khai thiết bị có hỗ trợ TDLS và TDLS bằng WiFiManager API, thì thiết bị sẽ:

NÊN sử dụng TDLS chỉ khi có thể VÀ có lợi.
NÊN có một số suy nghiệm và KHÔNG sử dụng TDLS khi hiệu suất của nó có thể kém hơn so với khi đi qua điểm truy cập Wi-Fi.

7.4.3. Bluetooth

Quá trình triển khai Android Watch PHẢI hỗ trợ Bluetooth. Các phương thức triển khai Android TV PHẢI hỗ trợ Bluetooth và Bluetooth LE. Các quá trình triển khai Android Automotive PHẢI hỗ trợ Bluetooth và PHẢI hỗ trợ Bluetooth LE.

Các quá trình triển khai trên thiết bị có hỗ trợ tính năng android.hardware.vr.high_performance PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth Mở rộng độ dài dữ liệu năng lượng thấp.

Android có hỗ trợ Bluetooth và Bluetooth năng lượng thấp. Các phương pháp triển khai thiết bị có hỗ trợ Bluetooth và Bluetooth năng lượng thấp 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. Quá trình triển khai thiết bị PHẢI triển khai các cấu hình Bluetooth có liên quan, chẳng hạn như A2DP, AVCP, OBEX, v.v. nếu phù hợp với thiết bị.

Các hoạt động triển khai Android Automotive NÊN hỗ trợ Cấu hình truy cập tin nhắn (MAP). Quá trình triển khai Android Automotive PHẢI hỗ trợ các cấu hình Bluetooth sau đây:

Gọi điện thoại qua Cấu hình rảnh tay (HFP).
Phát nội dung nghe nhìn qua Cấu hình phân phối âm thanh (A2DP).
Kiểm soát việc phát nội dung nghe nhìn qua Cấu hình điều khiển từ xa (AVRCP).
Chia sẻ địa chỉ liên hệ bằng Cấu hình truy cập danh bạ điện thoại (PBAP).

Các cách triển khai thiết bị, bao gồm cả tính năng hỗ trợ Bluetooth năng lượng thấp:

PHẢI khai báo tính năng phần cứng android.hardware.bluetooth_le.
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.
KHÔNG NÊN triển khai thời gian chờ dành cho Địa chỉ riêng có thể phân giải (RPA) quá 15 phút và xoay vòng địa chỉ khi hết thời gian chờ để bảo vệ quyền riêng tư của người dùng.
NÊN hỗ trợ giảm tải logic lọc cho bộ vi mạch bluetooth khi triển khai Quét bộ API và PHẢI báo cáo giá trị chính xác của vị trí triển khai logic lọc mỗi khi được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isOFFloadedFilteringSupported().
NÊN hỗ trợ giảm tải cho quá trình quét theo lô đối với chipset Bluetooth, nhưng nếu không được hỗ trợ, PHẢI báo cáo "false" mỗi khi được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
NÊN hỗ trợ nhiều quảng cáo với ít nhất 4 vị trí, nhưng nếu không được hỗ trợ, PHẢI báo cáo "false" mỗi khi được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isMultipleAdvertisingSupported().

7.4.4. Giao tiếp phạm vi gần

Quá trình triển khai thiết bị PHẢI bao gồm một bộ thu phát và phần cứng có liên quan cho tính năng Giao tiếp phạm vi gần (NFC). Nếu quá trình triển khai thiết bị có bao gồm phần cứng NFC và kế hoạch cung cấp thiết bị này cho các ứng dụng của bên thứ ba, thì thiết bị đó:

PHẢI báo cáo tính năng android.hardware.nfc qua phương thức android.content.pm.PackageManager.hasSystemFeature().
PHẢI có khả năng đọc và ghi thông báo NDEF qua các tiêu chuẩn NFC sau đây:
- PHẢI có khả năng hoạt động như người đọc/ghi Diễn đàn NFC (như được xác định trong thông số kỹ thuật của Diễn đàn NFC NFCnhư-TS-DigitalProtocol-1.0) thông qua các tiêu chuẩn NFC sau:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS X 6319-4)
  - IsoDep (ISO 14443-4)
  - Các loại thẻ diễn đàn NFC 1, 2, 3, 4 (được định nghĩa bởi Diễn đàn NFC)
- MẠNG NÊN DÙNG là có khả năng đọc và ghi tin nhắn NDEF cũng như dữ liệu thô thông qua các tiêu chuẩn NFC sau đây. Lưu ý rằng mặc dù các tiêu chuẩn NFC bên dưới được nêu rõ là DỄ DÀNG NÊN DÙNG, thì Định nghĩa về khả năng tương thích cho phiên bản trong tương lai dự kiến sẽ thay đổi những tiêu chuẩn này thành PHẢI. Các tiêu chuẩn này là không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị mới và hiện có chạy phiên bản Android này rất cần đáp ứng những yêu cầu này ngay bây giờ để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
  - NfcV (ISO 15693)
- PHẢI có khả năng đọc mã vạch và URL (nếu được mã hoá) của sản phẩm Mã vạch NFC của Thinfilm.
- PHẢI có khả năng truyền và nhận dữ liệu qua các tiêu chuẩn và giao thức ngang hàng sau đây:
  - ISO 18092
  - LLCP 1.2 (theo định nghĩa của Diễn đàn NFC)
  - SDP 1.0 (do Diễn đàn NFC định nghĩa)
  - Giao thức đẩy NDEF
  - SNEP 1.0 (được định nghĩa bởi Diễn đàn NFC)
- PHẢI bao gồm tính năng hỗ trợ Truyền tia Android.
- PHẢI triển khai máy chủ mặc định SNEP. Thông báo NDEF hợp lệ mà máy chủ SNEP mặc định nhận được PHẢI được gửi đến các ứng dụng bằng cách sử dụng ý định android.nfc.ACTION_NDEF_DISCOVERED. Việc tắt tính năng Truyền tia Android trong phần cài đặt KHÔNG ĐƯỢC tắt tính năng gửi tin nhắn NDEF đến.
- PHẢI thực hiện theo ý định android.settings.NFCân_SETTINGS để hiển thị chế độ cài đặt cách chia sẻ NFC.
- PHẢI triển khai máy chủ NPP. Thông báo mà máy chủ NPP nhận được PHẢI được xử lý giống như máy chủ mặc định SNEP.
- PHẢI triển khai ứng dụng SNEP và cố gắng gửi NDEF P2P đi tới máy chủ SNEP mặc định khi tính năng Truyền tia Android được bật. Nếu không tìm thấy máy chủ SNEP mặc định thì ứng dụng PHẢI cố gắng gửi đến máy chủ NPP.
- PHẢI cho phép các hoạt động trên nền trước đặt thông báo NDEF P2P đi bằng cách sử dụng android.nfc.NfcAdapter.setNdefPushMessage và android.nfc.NfcAdapter.setNdefPushMessageCallback và android.nfc.NfcAdapter.enableForegroundNdefPush.
- NÊN sử dụng cử chỉ hoặc xác nhận trên màn hình, chẳng hạn như "Chạm để chiếu" trước khi gửi thư NDEF P2P đi.
- PHẢI bật tính năng Truyền tia Android theo mặc định và PHẢI có thể gửi và nhận bằng tính năng Truyền tia Android, ngay cả khi một chế độ P2p NFC độc quyền khác được bật.
- PHẢI hỗ trợ chuyển giao kết nối NFC sang Bluetooth khi thiết bị hỗ trợ cấu hình đẩy đối tượng qua Bluetooth. Quá trình triển khai thiết bị PHẢI hỗ trợ chuyển giao kết nối sang Bluetooth khi sử dụng android.nfc.NfcAdapter.setBeamPushUris, bằng cách triển khai thông số kỹ thuật “Connection Handover version 1.2” (Giao thức kết nối) và “Bluetooth Secure SimplePair Using NFC version 1.0” (Ghép nối đơn giản qua kết nối Bluetooth bằng NFC phiên bản 1.0) trên Diễn đàn NFC. Cách triển khai như vậy PHẢI triển khai dịch vụ LLCP chuyển giao với tên dịch vụ “urn:nfc:sn:handover” để trao đổi yêu cầu chuyển giao/chọn bản ghi qua NFC, đồng thời PHẢI sử dụng Cấu hình đẩy đối tượng Bluetooth để chuyển dữ liệu Bluetooth thực tế. Vì các lý do cũ (để duy trì khả năng tương thích với các thiết bị Android 4.1), việc triển khai vẫn PHẢI chấp nhận các yêu cầu SNEP GET để trao đổi yêu cầu chuyển giao/chọn bản ghi qua NFC. Tuy nhiên, bản triển khai KHÔNG ĐƯỢC gửi các yêu cầu SNEP GET để thực hiện chuyển giao kết nối.
- PHẢI thăm dò tất cả công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
- PHẢI ở chế độ phát hiện NFC khi thiết bị đang bật với màn hình đang hoạt động và màn hình khóa đã mở khóa.

(Lưu ý rằng các đường liên kết công khai sẽ không có sẵn cho các thông số kỹ thuật của Diễn đàn JIS, ISO và NFC được trích dẫn ở trên.)

Android có hỗ trợ chế độ Giả lập thẻ máy chủ NFC (HCE). Nếu quá trình triển khai thiết bị có bao gồm bộ vi mạch điều khiển NFC có khả năng HCE (dành cho NfcA và/hoặc NfcB) và hỗ trợ định tuyến ID ứng dụng (AID), thì ứng dụng đó:

PHẢI báo cáo hằng số tính năng android.hardware.nfc.hce.
PHẢI hỗ trợ API HCE NFC như đã xác định trong SDK Android.

Nếu quá trình triển khai thiết bị bao gồm bộ vi mạch điều khiển NFC có khả năng HCE cho NfcF và triển khai tính năng này cho các ứng dụng của bên thứ ba, thì nó:

PHẢI báo cáo hằng số tính năng android.hardware.nfc.hcef.
PHẢI triển khai API Mô phỏng thẻ NfcF như đã xác định trong SDK Android.

Ngoài ra, quá trình triển khai thiết bị CÓ THỂ bao gồm tính năng hỗ trợ trình đọc/ghi cho các công nghệ MIFARE sau đây.

MIFARE cổ điển
MIFARE Siêu nhẹ
NDEF trên MIFARE Classic

Lưu ý rằng Android bao gồm API cho các loại MIFARE này. Nếu quá trình triển khai thiết bị hỗ trợ MIFARE trong vai trò người đọc/người ghi, thì quá trình triển khai đó:

PHẢI triển khai các API Android tương ứng như được SDK Android ghi nhận.
PHẢI báo cáo tính năng com.nxp.mifare từ phương thức android.content.pm.PackageManager.hasSystemFeature(). Lưu ý rằng đây không phải là một tính năng tiêu chuẩn của Android và do đó không xuất hiện dưới dạng hằng số trong lớp android.content.pm.PackageManager.
KHÔNG ĐƯỢC triển khai các API Android tương ứng và cũng không báo cáo tính năng com.nxp.mifare trừ phi tính năng này cũng triển khai dịch vụ hỗ trợ chung NFC như mô tả trong phần này.

Nếu quá trình triển khai thiết bị không bao gồm phần cứng NFC, thì tính năng này KHÔNG ĐƯỢC khai báo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature() và PHẢI triển khai API NFC của Android ở trạng thái không hoạt động.

Vì các lớp android.nfc.NdefMessage và android.nfc.NdefRecord đại diện cho một định dạng biểu diễn dữ liệu độc lập với giao thức, các hoạt động triển khai thiết bị PHẢI triển khai các API này ngay cả khi chúng không hỗ trợ NFC hoặc khai báo tính năng android.hardware.nfc.

7.4.5. Khả năng mạng tối thiểu

Quá trình triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ cho một hoặc nhiều hình thức nối mạng dữ liệu. Cụ thể, quá trình triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ ít nhất một chuẩn dữ liệu có khả năng ở tốc độ 200Kbit/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, Bluetooth PAN, v.v.

Những thiết bị mà một tiêu chuẩn mạng vật lý (chẳng hạn như Ethernet) là kết nối dữ liệu chính PHẢI cũng bao gồm tính năng hỗ trợ cho ít nhất một chuẩn dữ liệu không dây phổ biến, chẳng hạn như 802.11 (Wi-Fi).

Các thiết bị CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu.

Thiết bị PHẢI có ngăn xếp mạng IPv6 và hỗ trợ giao tiếp IPv6 bằng cách sử dụng các API được quản lý, chẳng hạn như java.net.Socket và java.net.URLConnection , cũng như các API gốc, chẳng hạn như ổ cắm AF_INET6. Mức độ hỗ trợ IPv6 yêu cầu phụ thuộc vào loại mạng, cụ thể như sau:

Những thiết bị hỗ trợ mạng Wi-Fi PHẢI hỗ trợ hoạt động ngăn xếp kép và chỉ IPv6 trên Wi-Fi.
Các thiết bị hỗ trợ mạng Ethernet PHẢI hỗ trợ thao tác ngăn xếp kép trên Ethernet.
Các thiết bị hỗ trợ dữ liệu di động NÊN hỗ trợ hoạt động IPv6 (chỉ IPv6 và có thể là ngăn xếp kép) trên dữ liệu di động.
Khi một thiết bị được kết nối đồng thời với nhiều mạng (ví dụ: Wi-Fi và dữ liệu di động), thiết bị PHẢI đáp ứng đồng thời các yêu cầu này trên từng mạng kết nối.

IPv6 PHẢI được bật theo mặc định.

Để đảm bảo rằng giao tiếp IPv6 đáng tin cậy như IPv4, unicast gói IPv6 gửi đến thiết bị KHÔNG ĐƯỢC thả, ngay cả khi màn hình không ở trạng thái hoạt động. Các gói IPv6 đa hướng dự phòng, chẳng hạn như Quảng cáo lặp đi lặp lại cùng một bộ định tuyến, CÓ THỂ bị giới hạn tốc độ trong phần cứng hoặc chương trình cơ sở nếu làm như vậy là cần thiết để tiết kiệm pin. Trong những trường hợp như vậy, giới hạn tốc độ KHÔNG ĐƯỢC khiến thiết bị mất kết nối IPv6 trên bất kỳ mạng nào tuân thủ IPv6 và sử dụng vòng đời RA ít nhất là 180 giây.

PHẢI duy trì kết nối IPv6 ở chế độ nghỉ.

7.4.6. Cài đặt đồng bộ hóa

Quá trình triển khai thiết bị PHẢI bật chế độ cài đặt tự động đồng bộ hoá chính theo mặc định để phương thức getMasterSync Automatically() trả về “true”.

7.4.7. Trình tiết kiệm dữ liệu

Các hoạt động triển khai thiết bị có kết nối có đo lượng dữ liệu được ĐỀ XUẤT DÙNG để cung cấp chế độ tiết kiệm dữ liệu.

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

PHẢI hỗ trợ tất cả API trong lớp ConnectivityManager như mô tả trong tài liệu về SDK
PHẢI cung cấp giao diện người dùng trong phần cài đặt để cho phép người dùng thêm ứng dụng vào hoặc xoá ứng dụng khỏi danh sách cho phép.

Ngược lại, nếu quá trình triển khai thiết bị không cung cấp chế độ tiết kiệm dữ liệu, thì chế độ này:

PHẢI trả về giá trị RESTRICT_BACKGROUND_STATUS_DISABLED cho ConnectivityManager.getRestrictBackgroundStatus()
KHÔNG ĐƯỢC truyền phát ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
PHẢI có một hoạt động xử lý ý định Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS nhưng CÓ THỂ triển khai hoạt động này ở dạng không hoạt động.

7,5. Camera

Quá trình triển khai thiết bị PHẢI bao gồm máy ảnh mặt sau và CÓ THỂ bao gồm máy ảnh mặt trước. Camera mặt sau là camera nằm ở cạnh của thiết bị đối diện với màn hình; tức là hệ thống này chụp ảnh các cảnh ở phía xa của thiết bị, giống như một camera truyền thống. Camera mặt trước là camera nằm ở cùng một phía của thiết bị với màn hình; tức là camera thường được dùng để chụp ảnh người dùng, chẳng hạn như cho hội nghị truyền hình và các ứng dụng tương tự.

Nếu quá trình triển khai thiết bị bao gồm ít nhất một máy ảnh, thì ứng dụng PHẢI có thể phân bổ đồng thời 3 bitmap RGBA_8888 bằng với kích thước hình ảnh do cảm biến máy ảnh có độ phân giải lớn nhất tạo ra trên thiết bị, trong khi máy ảnh đang mở để xem trước cơ bản và vẫn chụp.

7.5.1. Camera mặt sau

Quá trình triển khai thiết bị PHẢI bao gồm máy ảnh mặt sau. Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh mặt sau, thì quá trình triển khai đó:

PHẢI báo cáo cờ tính năng android.hardware.camera và android.hardware.camera.any.
PHẢI có độ phân giải ít nhất là 2 megapixel.
NÊN triển khai tính năng tự động lấy nét phần cứng hoặc tự động lấy nét bằng phần mềm trong trình điều khiển máy ảnh (trong suốt đối với phần mềm ứng dụng).
CÓ THỂ dùng phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh mở rộng).
CÓ THỂ bao gồm cả đèn flash. Nếu Máy ảnh có đèn flash, đèn flash KHÔNG ĐƯỢC sáng khi bản sao android.hardware.Camera.PreviewCallback được đăng ký trên bề mặt xem trước của Máy ảnh, trừ phi ứng dụng đã bật đèn flash một cách rõ ràng bằng cách bật thuộc tính FLASH_MODE_auto hoặc FLASH_MODE_ON của đối tượng Camera.Parameters. Xin lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng máy ảnh tích hợp sẵn trong hệ thống của thiết bị, mà chỉ áp dụng cho các ứng dụng của bên thứ ba sử dụng Camera.PreviewCallback.

7.5.2. Máy ảnh mặt trước

Quá trình triển khai trên thiết bị CÓ THỂ bao gồm cả máy ảnh mặt trước. Nếu quá trình triển khai thiết bị có ít nhất một máy ảnh mặt trước, thì quá trình triển khai đó:

PHẢI báo cáo cờ tính năng android.hardware.camera.any và android.hardware.camera.front.
PHẢI có độ phân giải tối thiểu là VGA (640x480 pixel).
KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm máy ảnh mặc định cho API Máy ảnh. API máy ảnh trong Android có hỗ trợ cụ thể cho máy ảnh mặt trước và quá trình triển khai thiết bị 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Ó THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, đèn flash, v.v.) dành cho máy ảnh mặt sau như mô tả trong phần 7.5.1.
PHẢI phản ánh theo chiều ngang (tức là phản chiếu) luồng do một ứng dụng hiển thị trong CameraPreview, như sau:
- Nếu người dùng có thể xoay quá trình triển khai thiết bị (chẳng hạn như tự động qua gia tốc kế hoặc thông qua hoạt động đầu vào của người dùng theo cách thủ công), bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng hiện tại của thiết bị.
- Nếu ứng dụng hiện tại đã yêu cầu xoay màn hình Máy ảnh một cách rõ ràng thông qua lệnh gọi tới phương thức android.hardware.Camera.setDisplayOrientation(), thì bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang tương ứng với hướng mà ứng dụng chỉ định.
- Nếu không, 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ị.
PHẢI phản chiếu hình ảnh mà chế độ xem hậu kỳ hiển thị theo cách tương tự như luồng hình ảnh của bản xem trước của máy ảnh. Nếu việc triển khai thiết bị không hỗ trợ chế độ hậu kỳ, thì rõ ràng yêu cầu này sẽ không áp dụng.
KHÔNG ĐƯỢC phản chiếu luồng video hoặc hình ảnh tĩnh được chụp cuối cùng được trả về cho lệnh gọi lại ứng dụng hoặc đã cam kết lưu trữ nội dung nghe nhìn.

7.5.3. Camera bên ngoài

Quá trình triển khai thiết bị CÓ THỂ bao gồm tính năng hỗ trợ một máy ảnh bên ngoài không nhất thiết phải luôn kết nối. Nếu thiết bị có hỗ trợ máy ảnh bên ngoài, thì thiết bị đó:

PHẢI khai báo cờ tính năng nền tảng android.hardware.camera.external và android.hardware camera.any .
CÓ THỂ hỗ trợ nhiều máy ảnh.
PHẢI hỗ trợ USB Video Class (UVC 1.0 trở lên) nếu camera bên ngoài kết nối thông qua cổng USB.
NÊN hỗ trợ các hoạt động nén video như MJPEG để cho phép truyền các luồng hình ảnh chất lượng cao chưa được mã hóa (ví dụ: luồng hình ảnh thô hoặc được nén độc lập).
CÓ thể hỗ trợ phương thức mã hoá video dựa trên máy ảnh. Nếu được hỗ trợ, luồng MJPEG / không được mã hoá đồng thời (QVGA hoặc độ phân giải cao hơn) PHẢI truy cập được vào quá trình triển khai thiết bị.

7.5.4. Hành vi của API máy ảnh

Android bao gồm hai gói API để truy cập vào máy ảnh, API android.hardware.camera2 mới hiển thị chức năng điều khiển máy ảnh ở cấp độ thấp hơn cho ứng dụng, bao gồm các luồng phát trực tuyến/loạt bản không có bản sao hiệu quả và kiểm soát độ phơi sáng, độ tăng, mức tăng cân bằng trắng, chuyển đổi màu sắc, khử nhiễu, làm sắc nét, v.v.

Gói API cũ, android.hardware.Camera, được đánh dấu là không dùng nữa trong Android 5.0 nhưng vẫn có sẵn cho các ứng dụng để sử dụng phương thức triển khai thiết bị Android PHẢI đảm bảo sự hỗ trợ liên tục của API như mô tả trong phần này và trong SDK Android.

Quá trình triển khai thiết bị PHẢI triển khai các hành vi sau đây cho các API liên quan đến máy ảnh đối với tất cả máy ảnh hiện có:

Nếu ứng dụng chưa từng gọi android.hardware.Camera.Parameters.setPreviewFormat(int), thì thiết bị 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.
Nếu một ứng dụng đăng ký phiên bản android.hardware.Camera.PreviewCallback và hệ thống gọi phương thức onPreviewFrame() khi định dạng xem trước là YCbCr_420_SP, thì dữ liệu trong byte[] được truyền vào onPreviewFrame() phải hơn nữa ở định dạng mã hoá NV21. Tức là NV21 PHẢI là giá trị mặc định.
Đối với android.hardware.Camera, các quá trình triển khai thiết bị PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số android.graphics.ImageFormat.YV12) để xem trước máy ảnh cho cả máy ảnh mặt trước và mặt sau. (Máy ảnh và bộ mã hoá video phần cứng có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng việc triển khai thiết bị PHẢI hỗ trợ chuyển đổi sang YV12.)
Đối với android.hardware.camera2, quá trình triển khai thiết bị phải hỗ trợ các định dạng android.hardware.ImageFormat.YUV_420_888 và android.hardware.ImageFormat.JPEG dưới dạng dữ liệu đầu ra thông qua API android.media.ImageReader.

Các quá trình triển khai thiết bị vẫn PHẢI triển khai Camera API đầy đủ có trong tài liệu SDK Android, bất kể thiết bị có tự động lấy nét phần cứng hoặc các tính năng khác hay không. Ví dụ: các máy ảnh thiếu tính năng tự động lấy nét PHẢI vẫn gọi mọi phiên bản android.hardware.Camera.AutoFocusCallback đã đăng ký (mặc dù điều này không liên quan đến máy ảnh không tự động lấy nét). Lưu ý rằng điều này áp dụng cho máy ảnh mặt trước; ví dụ: mặc dù hầu hết các máy ảnh mặt trước không hỗ trợ tính năng tự động lấy nét, nhưng các lệnh gọi lại API vẫn phải được "giả mạo" như mô tả.

Các quá trình triển khai thiết bị PHẢI nhận dạng và tuân thủ từng tên thông số được xác định là hằng số trên lớp android.hardware.Camera.Parameters, nếu phần cứng cơ bản hỗ trợ tính năng này. Nếu phần cứng của thiết bị không hỗ trợ một tính năng, thì API phải hoạt động như trong tài liệu. Ngược lại, các quá trình triển khai thiết bị KHÔNG ĐƯỢC chấp nhận hoặc nhận dạng các hằng số chuỗi được chuyển đến phương thức android.hardware.Camera.setParameters() ngoài các phương thức được ghi lại dưới dạng hằng số trên android.hardware.Camera.Parameters. Tức là các quá trình triển khai thiết bị PHẢI hỗ trợ tất cả các tham số Camera tiêu chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại thông số Camera tuỳ chỉnh. Ví dụ: các phương pháp triển khai trên thiết bị hỗ trợ chụp ảnh bằng kỹ thuật chụp ảnh dải động cao (HDR) PHẢI hỗ trợ tham số camera.SCENE_MODE_HDR.

Vì không phải phương thức triển khai thiết bị nào cũng có thể hỗ trợ đầy đủ tất cả tính năng của API android.hardware.camera2, nên các quá trình triển khai thiết bị PHẢI báo cáo mức độ hỗ trợ phù hợp bằng thuộc tính android.info.supportedHardwarelevel như mô tả trong SDK Android và báo cáo cờ tính năng khung thích hợp.

Các quá trình triển khai thiết bị cũng PHẢI khai báo các chức năng của máy ảnh riêng lẻ của android.hardware.camera2 thông qua thuộc tính android.request.availableCapabilities và khai báo cờ tính năng thích hợp; một thiết bị phải xác định cờ tính năng nếu có bất kỳ thiết bị máy ảnh đi kèm nào của thiết bị đó hỗ trợ tính năng này.

Các quá trình triển khai trên thiết bị PHẢI truyền phát ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một ảnh mới và mục nhập của hình ảnh đó đã được thêm vào kho nội dung nghe nhìn.

Các quá trình triển khai trên thiết bị PHẢI truyền phát ý định Camera.ACTION_NEW_VIDEO bất cứ khi nào máy ảnh ghi lại video mới và mục nhập hình ảnh đã được thêm vào kho nội dung nghe nhìn.

7.5.5. Hướng máy ảnh

Cả máy ảnh mặt trước và mặt sau (nếu có) PHẢI được định hướng sao cho chiều dài của máy ảnh phù hợp với chiều dài của màn hình. Tức là khi thiết bị được giữ theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang. Điều này áp dụng bất kể hướng tự nhiên của thiết bị là gì; tức là chế độ này áp dụng cho các thiết bị chính ở chế độ ngang cũng như các thiết bị chính ở chế độ dọc.

7,6. Bộ nhớ và dung lượng lưu trữ

7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu

Thiết bị Android TV PHẢI có ít nhất 4 GB bộ nhớ không biến động dành cho dữ liệu riêng tư của ứng dụng.

Bộ nhớ có sẵn cho nhân và không gian người dùng trên các quá trình triển khai thiết bị PHẢI ít nhất bằng hoặc lớn hơn giá trị tối thiểu đượ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ật độ và kích thước màn hình	Thiết bị 32 bit	Thiết bị 64 bit
Thiết bị Android Watch (do màn hình nhỏ hơn)	416MB	Không có
280dpi trở xuống đối với màn hình nhỏ/bình thường mdpi hoặc thấp hơn trên màn hình lớn ldpi hoặc thấp hơn trên màn hình cực lớn	512 MB	816MB
xhdpi trở lên trên màn hình nhỏ/bình thường hdpi trở lên trên màn hình lớn mdpi trở lên trên màn hình cực lớn	608MB	944MB
400dpi trở lên đối với màn hình nhỏ/bình thường xhdpi trở lên trên màn hình lớn tvdpi trở lên trên màn hình cực lớn	896MB	1280MB
560dpi trở lên đối với màn hình nhỏ/bình thường 400dpi trở lên đối với màn hình lớn xhdpi trở lên trên màn hình cực lớn	1344MB	1824MB

Các giá trị bộ nhớ tối thiểu PHẢI bổ sung vào mọi dung lượng bộ nhớ đã dành riêng cho các thành phần phần cứng như radio, video, v.v. không thuộc phạm vi kiểm soát của nhân.

Các quá trình triển khai thiết bị có bộ nhớ dưới 512 MB cho nhân và không gian người dùng, trừ phi một Đồng hồ Android, PHẢI trả về giá trị "true" cho ActivityManager.isLowRamDevice().

Thiết bị Android TV PHẢI có ít nhất 4 GB và các thiết bị triển khai khác PHẢI có ít nhất 3 GB bộ nhớ không biến động dành cho dữ liệu riêng tư của ứng dụng. Tức là phân vùng /data PHẢI có dung lượng ít nhất là 4 GB đối với các thiết bị Android TV và ít nhất là 3 GB đối với các thiết bị triển khai khác. Các hoạt động triển khai thiết bị chạy Android NÊN DÙNG để có ít nhất 4 GB bộ nhớ không biến động cho dữ liệu riêng tư của ứng dụng để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.

API Android có một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ dùng để tải tệp dữ liệu xuống. Việc triển khai Trình quản lý tải xuống trên thiết bị PHẢI có khả năng tải từng 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

Quá trình triển khai thiết bị PHẢI cung cấp bộ nhớ dùng chung cho các ứng dụng, cũng thường được gọi là “bộ nhớ ngoài dùng chung”.

Các quá trình triển khai thiết bị PHẢI được định cấu hình với bộ nhớ dùng chung được kết nối theo mặc định, "ngay từ đầu". Nếu bộ nhớ dùng chung không được gắn kết trên Linuxpath /sdcard, thì thiết bị PHẢI bao gồm một đường liên kết tượng trưng của Linux từ /sdcard đến điểm gắn thực tế.

Quá trình triển khai thiết bị CÓ THỂ có phần cứng cho bộ nhớ di động mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ Kỹ thuật số bảo mật (SD). Nếu khe cắm này được dùng để đáp ứng yêu cầu về bộ nhớ dùng chung, thì việc triển khai thiết bị:

PHẢI triển khai thông báo ngắn hoặc giao diện người dùng bật lên để cảnh báo người dùng khi không có thẻ SD.
PHẢI cung cấp một thẻ SD có định dạng FAT có kích thước từ 1GB trở lên HOẶC hiển thị trên hộp và các chất liệu khác có sẵn tại thời điểm mua hàng để cho biết thẻ SD phải được mua riêng.
PHẢI lắp thẻ SD theo mặc định.

Ngoài ra, các quá trình triển khai thiết bị CÓ THỂ phân bổ bộ nhớ trong (không thể tháo rời) làm bộ nhớ dùng chung cho các ứng dụng như có trong Dự án nguồn mở Android ở cấp trên; quá trình triển khai thiết bị PHẢI sử dụng cấu hình và cách triển khai phần mềm này. Nếu quá trình triển khai thiết bị sử dụng bộ nhớ trong (không thể tháo rời) để đáp ứng yêu cầu về bộ nhớ dùng chung, trong khi bộ nhớ đó CÓ THỂ chia sẻ dung lượng với dữ liệu riêng tư của ứng dụng, bộ nhớ PHẢI có kích thước tối thiểu là 1GB và được gắn trên /sdcard (hoặc /sdcard PHẢI là một đường liên kết tượng trưng đến vị trí thực nếu được gắn ở nơi khác).

Các hoạt động triển khai thiết bị PHẢI thực thi như đã ghi nhận quyền android.permission.permission_EXTERNAL_STORAGE trên bộ nhớ dùng chung này. Nếu không, bộ nhớ dùng chung PHẢI có thể ghi bởi bất kỳ ứng dụng nào có được quyền đó.

Việc triển khai thiết bị bao gồm nhiều đường dẫn bộ nhớ dùng chung (chẳng hạn như cả khe thẻ SD và bộ nhớ trong dùng chung) PHẢI chỉ cho phép cài đặt sẵn & các ứng dụng Android có đặc quyền dành riêng cho ứng dụng Android có quyền ENABLE_EXTERNAL_STORAGE để ghi vào bộ nhớ ngoài phụ, trừ phi ứng dụng ghi vào thư mục dành riêng cho gói hoặc trong URI được trả về bằng cách kích hoạt ý định ACTION_OPEN_DOCUMENT_TREE.

Tuy nhiên, các quá trình triển khai thiết bị PHẢI hiển thị rõ ràng nội dung từ cả hai đường dẫn lưu trữ thông qua dịch vụ trình quét nội dung nghe nhìn của Android và android.provider.MediaStore.

Bất kể được sử dụng ở hình thức bộ nhớ dùng chung nào, nếu quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ ngoại vi USB, thì phương thức triển khai đó PHẢI cung cấp một số cơ chế để truy cập vào nội dung của bộ nhớ dùng chung từ máy tính lưu trữ. Quá trình triển khai thiết bị CÓ THỂ sử dụng bộ nhớ dung lượng lớn USB, nhưng NÊN sử dụng Giao thức truyền nội dung đa phương tiện để đáp ứng yêu cầu này. Nếu quá trình triển khai thiết bị có hỗ trợ Giao thức truyền nội dung nghe nhìn, thì quá trình triển khai thiết bị sẽ:

PHẢI tương thích với máy chủ Android MTP tham chiếu, Truyền tệp của Android.
NÊN báo cáo lớp thiết bị USB là 0x00.
NÊN báo cáo tên giao diện USB là 'MTP'.

7.6.3. Bộ nhớ tích hợp

Các phương thức triển khai trên thiết bị là tôi được nhà phát triển cho rằng cần triển khai adoptable storage (bộ nhớ có thể tháo rời) nếu cổng của thiết bị lưu trữ có thể tháo rời nằm ở một vị trí ổn định trong thời gian dài, chẳng hạn như trong ngăn chứa pin hoặc nắp bảo vệ khác.

Các quá trình triển khai thiết bị như TV, CÓ THỂ cho phép sử dụng qua cổng USB vì thiết bị dự kiến sẽ ở dạng tĩnh và không phải thiết bị di động. Tuy nhiên, đối với các hoạt động triển khai thiết bị khác có tính chất thiết bị di động, bạn nên triển khai bộ nhớ có thể sử dụng ở một vị trí ổn định lâu dài, vì việc vô tình ngắt kết nối chúng có thể gây mất dữ liệu/bị hỏng dữ liệu.

7,7. USB

Các quá trình triển khai thiết bị PHẢI hỗ trợ chế độ thiết bị ngoại vi USB và PHẢI hỗ trợ chế độ máy chủ USB.

7.7.1. Chế độ thiết bị ngoại vi USB

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

Cổng 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 chuẩn.
Cổng PHẢI sử dụng hệ số hình dạng USB micro-B, micro-AB hoặc Type-C. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những 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.
Cổng PHẢI được đặt ở cuối thiết bị (theo hướng tự nhiên) hoặc bật tính năng xoay màn hình phần mềm cho tất cả các ứng dụng (bao gồm cả màn hình chính), để màn hình hiển thị chính xác khi thiết bị được định hướng bằng cổng ở dưới cùng. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những yêu cầu này để có thể nâng cấp lên bản phát hành nền tảng trong tương lai.
Phương thức này PHẢI cho phép máy chủ USB được kết nối với thiết bị Android truy cập vào nội dung của phương tiện bộ nhớ dùng chung bằng bộ nhớ dung lượng lớn USB hoặc Giao thức truyền phương tiện.
NÊN triển khai API và thông số kỹ thuật của Android Open Accessory (AOA) như được nêu trong tài liệu SDK Android. Ngoài ra, nếu là thiết bị Android cầm tay thì PHẢI triển khai API AOA. Triển khai thiết bị triển khai quy cách AOA:
- PHẢI khai báo khả năng hỗ trợ tính năng phần cứng android.hardware.usb.accessory.
- PHẢI triển khai lớp âm thanh USB như được nêu trong tài liệu SDK Android.
- Lớp bộ nhớ dung lượng lớn USB PHẢI bao gồm chuỗi "android" ở cuối phần mô tả giao diện, chuỗi iInterface của bộ lưu trữ USB
NÊN triển khai tính năng hỗ trợ để vẽ dòng điện 1.5 A trong khi truyền âm thanh và lưu lượng truy cập HS như quy định trong thông số kỹ thuật Sạc pin USB, bản sửa đổi 1.2. Các thiết bị Android mới và hiện có NÊN DÙNG để đáp ứng những yêu cầu này để có thể nâng cấp lên bản phát hành nền tảng trong tương lai.
Thiết bị Type-C 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.
Các thiết bị Type-C cũng hỗ trợ chế độ máy chủ USB được ĐỀ XUẤT NÊN hỗ trợ Power Delivery cho việc hoán đổi vai trò nguồn và dữ liệu.
Thiết bị Type-C NÊN hỗ trợ Power Delivery để sạc điện cao áp và hỗ trợ các Chế độ thay thế như hiển thị đầu ra.
Giá trị của iSerialNumber trong bộ mô tả thiết bị chuẩn USB PHẢI bằng giá trị của android.os.Build.SERIAL.
Các thiết bị Type-C NÊN không hỗ trợ các phương thức sạc thuộc quyền sở hữu riêng giúp sửa đổi điện áp Vbus vượt quá mức mặc định hoặc thay đổi vai trò của bồn lưu trữ dữ liệu/nguồn, chẳng hạn như có thể dẫn đến vấn đề về khả năng tương tác với bộ sạc hoặc thiết bị hỗ trợ phương thức Phân phối điện qua USB tiêu chuẩn. Mặc dù điều này được gọi là "NÊN DÙNG", nhưng trong các phiên bản Android trong tương lai, chúng tôi có thể YÊU CẦU tất cả thiết bị loại C để hỗ trợ khả năng tương tác đầy đủ với bộ sạc loại C tiêu chuẩn.

7.7.2. Chế độ hỗ trợ USB

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

NÊN sử dụng cổng USB loại C, nếu quá trình triển khai thiết bị hỗ trợ USB 3.1.
CÓ THỂ sử dụng kiểu dáng cổng không theo chuẩn, nhưng nếu phải đi kèm với cáp hoặc các dây cáp để điều chỉnh cổng thành một cổng USB loại A hoặc loại C tiêu chuẩn.
CÓ THỂ sử dụng cổng USB micro-AB, nhưng nếu có, NÊN gửi kèm cáp hoặc cáp điều chỉnh cổng thành cổng USB loại A hoặc loại C tiêu chuẩn.
NÊN DÙNG để triển khai lớp âm thanh USB như nêu trong tài liệu về SDK Android.
PHẢI triển khai API máy chủ USB trên Android như được nêu trong SDK Android và PHẢI khai báo khả năng hỗ trợ cho tính năng phần cứng android.hardware.usb.host.
NÊN hỗ trợ sạc thiết bị khi ở chế độ máy chủ; quảng cáo dòng điện tối thiểu là 1,5A như quy định trong phần Thông số kết thúc của [Bản sửa đổi thông số kỹ thuật đầu ra và cáp USB Type-C 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) cho đầu nối USB Type-C hoặc sử dụng dải dòng điện đầu ra Charge USB Type-C(CDP2),
Các thiết bị USB Type-C ĐƯỢC ĐỀ XUẤT NÊN hỗ trợ DisplayPort, NÊN hỗ trợ USB SuperSpeed DataRate, và ĐỀ XUẤT NÊN hỗ trợ Power Delivery cho việc hoán đổi vai trò dữ liệu và nguồn.
Các thiết bị có cổng loại A hoặc loại AB KHÔNG ĐƯỢC mang theo bộ chuyển đổi chuyển đổi từ cổng này sang ổ cắm loại C.
PHẢI nhận dạng mọi thiết bị MTP (Giao thức truyền nội dung nghe nhìn) được kết nối từ xa và cho phép truy cập vào nội dung của các thiết bị đó thông qua ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT nếu hỗ trợ Khung truy cập bộ nhớ (SAF).
PHẢI, nếu sử dụng cổng USB Type-C và có hỗ trợ chế độ ngoại vi, phải triển khai chức năng Cổng vai trò kép như được xác định trong thông số kỹ thuật USB Type-C (mục 4.5.1.3.3).
NÊN, nếu chức năng Cổng vai trò kép được hỗ trợ, hãy triển khai mô hình Thử.* phù hợp nhất với kiểu dáng thiết bị. Ví dụ: thiết bị cầm tay NÊN triển khai mô hình Thử.SNK.

7,8. Âm thanh

7.8.1. Micrô

Các cách triển khai Android Cầm tay, Đồng hồ và Automotive PHẢI bao gồm micrô.

Quá trình triển khai thiết bị CÓ THỂ bỏ qua micrô. Tuy nhiên, nếu quá trình triển khai thiết bị bỏ qua micrô, thì quá trình triển khai thiết bị KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.micrô và PHẢI triển khai API ghi âm ít nhất là không hoạt động theo mục 7. Ngược lại, những cách triển khai thiết bị sở hữu micrô:

PHẢI báo cáo hằng số tính năng android.hardware.threshold.
PHẢI đáp ứng các yêu cầu ghi âm trong mục 5.4.
PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
tôi đề xuất các giải pháp hỗ trợ tính năng ghi gần-ultrasound như mô tả trong section 7.8.3.

7.8.2. Đầu ra âm thanh

Thiết bị Android Watch CÓ THỂ có đầu ra âm thanh.

Cách triển khai thiết bị bao gồm loa hoặc có cổng đầu ra âm thanh/đa phương tiện cho thiết bị ngoại vi đầu ra âm thanh dưới dạng tai nghe hoặc loa ngoài:

PHẢI báo cáo hằng số của tính năng android.hardware.audio.output.
PHẢI đáp ứng các yêu cầu về việc phát âm thanh trong mục 5.5.
PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong mục 5.6.
Tôi đề xuất mã khuyến nghị để hỗ trợ tính năng phát gần-ultrasound như mô tả trong section 7.8.3.

Ngược lại, nếu quá trình triển khai thiết bị không bao gồm cổng loa hoặc cổng đầu ra âm thanh, thì KHÔNG ĐƯỢC báo cáo tính năng đầu ra android.hardware.audio và 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.

Triển khai thiết bị Android Watch CÓ THỂ nhưng KHÔNG NÊN có đầu ra âm thanh. Tuy nhiên, các hình thức triển khai thiết bị Android khác PHẢI có đầu ra âm thanh và khai báo android.hardware.audio.output.

7.8.2.1. Cổng âm thanh analog

Để tương thích với tai nghe và các phụ kiện âm thanh khác bằng giắc cắm âm thanh 3,5 mm trong hệ sinh thái Android, nếu cách triển khai thiết bị có một hoặc nhiều cổng âm thanh analog, thì ít nhất một trong các cổng âm thanh PHẢI là giắc cắm âm thanh 3,5 mm 4 dây. Nếu quá trình triển khai thiết bị có giắc cắm âm thanh 3,5 mm 4 dây dẫn, thì thiết bị đó:

PHẢI hỗ trợ phát âm thanh cho tai nghe âm thanh nổi và tai nghe âm thanh nổi có micrô và PHẢI hỗ trợ ghi âm từ tai nghe âm thanh nổi có micrô.
PHẢI hỗ trợ giắc cắm âm thanh TRRS theo thứ tự chân cắm CTIA, và PHẢI hỗ trợ giắc cắm âm thanh theo thứ tự chân OMTP.
PHẢI hỗ trợ tính năng phát hiện micrô trên phụ kiện âm thanh đã cắm, nếu quá trình triển khai thiết bị có hỗ trợ micrô, đồng thời truyền phát android.intent.action.HEADSET_PLUG với giá trị bổ sung micrô được đặt là 1.
PHẢI hỗ trợ phát hiện và ánh xạ tới mã phím cho 3 phạm vi trở kháng tương đương sau đây giữa micrô và dây dẫn mặt đất trên giắc cắm âm thanh:
- 70 ohm trở xuống : KEYCODE_HEADSETHOOK
- 210-290 Ohm : KEYCODE_VOLUME_UP
- 360-680 Ohm : KEYCODE_VOLUME_DOWN
NÊN DÙNG để phát hiện và ánh xạ đến mã phím cho phạm vi trở kháng tương đương sau đây giữa micrô và dây dẫn mặt đất trên giắc cắm âm thanh:
- 110 – 180 Ohm: KEYCODE_VOICE_ASSIST
PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm giắc cắm, nhưng chỉ sau khi tất cả các điểm tiếp xúc trên giắc cắm chạm vào các phần có liên quan trên giắc cắm.
PHẢI có khả năng truyền động ít nhất 150mV ± 10% điện áp đầu ra trên trở kháng loa 32 Ohm.
PHẢI có điện áp thiên vị micrô trong khoảng 1,8V ~ 2,9V.

7.8.3. Siêu âm gần

Âm thanh siêu âm gần là băng tần 18,5 kHz đến 20 kHz. Các quá trình triển khai thiết bị PHẢI báo cáo chính xác việc hỗ trợ tính năng âm thanh gần như siêu âm qua API AudioManager.getProperty như sau:

Nếu PROPERTY_ HỖ_MIC_NEAR_ULTRA thính là "true", thì nguồn âm thanh VOICE_RECOGNITION và UNProcessing phải đáp ứng các yêu cầu sau đây:
- Phản hồi công suất trung bình của micrô ở băng tần từ 18,5 kHz đến 20 kHz PHẢI không được lớn hơn 15 dB dưới phản hồi tại 2 kHz.
- Tỷ lệ tín hiệu không có trọng số so với tiếng ồn của micrô trên 18,5 kHz đến 20 kHz đối với âm 19 kHz ở -26 dBFS PHẢI không được thấp hơn 50 dB.
Nếu PROPERTY_ HỖ_Loa_NEAR_ULTRAÂM là "true" thì phản hồi trung bình của loa trong khoảng 18,5 kHz – 20 kHz PHẢI không được nhỏ hơn 40 dB thấp hơn phản hồi tại 2 kHz.

7,9. Thực tế ảo

Android bao gồm các API và cơ sở vật chất để xây dựng "Thực tế ảo" (VR) bao gồm trải nghiệm thực tế ảo chất lượng cao trên thiết bị di động. Quá trình triển khai thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

7.9.1. Chế độ thực tế ảo

Các quá trình triển khai thiết bị cầm tay Android hỗ trợ chế độ cho các ứng dụng VR xử lý kết xuất hình nổi của thông báo và vô hiệu hoá các thành phần giao diện người dùng của hệ thống bằng một mắt, trong khi ứng dụng VR có tâm điểm của người dùng PHẢI khai báo tính năng android.software.vr.mode. Các thiết bị khai báo tính năng này PHẢI bao gồm một ứng dụng triển khai android.service.vr.VrListenerService mà các ứng dụng Thực tế ảo có thể bật qua android.app.Activity#setVrModeEnabled .

7.9.2. Thực tế ảo hiệu suất cao

Các quá trình triển khai thiết bị cầm tay Android PHẢI xác định khả năng hỗ trợ thực tế ảo hiệu suất cao trong thời gian dài hơn cho người dùng thông qua cờ tính năng android.hardware.vr.high_performance và đáp ứng các yêu cầu sau.

Quá trình triển khai thiết bị PHẢI có ít nhất 2 lõi vật lý.
Các quá trình triển khai thiết bị PHẢI khai báo tính năng android.software.vr.mode.
Quá trình triển khai thiết bị CÓ THỂ cung cấp một lõi độc quyền cho ứng dụng trên nền trước và CÓ THỂ hỗ trợ Process.getExclusiveCores API để trả về số lượng lõi CPU dành riêng cho ứng dụng trên nền trước. Nếu lõi độc quyền được hỗ trợ thì lõi 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 lõi đó (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.
Các quá trình triển khai thiết bị PHẢI hỗ trợ chế độ duy trì hiệu suất bền vững.
Các quá trình triển khai thiết bị PHẢI hỗ trợ OpenGL ES 3.2.
Các quá trình triển khai thiết bị PHẢI hỗ trợ Vulkan Hardware Level 0 và PHẢI hỗ trợ Vulkan Hardware Level 1.
Hoạt động triển khai thiết bị PHẢI triển khai EGL_KHR_mutable_render_buffer và EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync và EGL_KHR_wait_sync để có thể dùng cho Chế độ vùng đệm dùng chung, đồng thời hiển thị các tiện ích trong danh sách tiện ích EGL hiện có.
GPU và màn hình PHẢI có khả năng đồng bộ hoá quyền truy cập vào vùng đệm trước dùng chung sao cho kết xuất mắt xen kẽ nội dung Thực tế ảo ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất sẽ được hiển thị mà không có hiện tượng xé hình.
Quá trình triển khai thiết bị PHẢI triển khai EGL_IMG_context_ Priority và hiển thị tiện ích này trong danh sách các tiện ích EGL hiện có.
Hoạt động triển khai thiết bị PHẢI triển khai GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 và GL_OVR_multiview_multisampled_render_to_texture, đồng thời hiển thị các tiện ích trong danh sách tiện ích GL hiện có.
Các quá trình triển khai thiết bị PHẢI triển khai EGL_EXT_protect_content và GL_EXT_protected_textures để có thể dùng cho việc Phát video kết cấu an toàn, đồng thời hiển thị các tiện ích trong danh sách các tiện ích EGL và GL hiện có.
Thiết bị triển khai PHẢI hỗ trợ giải mã H.264 ít nhất 3840x2160@30fps-40Mbps (tương đương với 4 phiên bản 1920x1080@30fps-10Mbps hoặc 2 phiên bản 1920x1080@60fps-20Mbps).
Thiết bị triển khai PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã tối thiểu 1920x1080@30fps-10Mbps và PHẢI có khả năng giải mã 3840x2160@30fps-20Mbps (tương đương 4 phiên bản 1920x1080@30fps-5Mbps).
Các cách triển khai thiết bị được ĐỀ XUẤT NÊN hỗ trợ tính năng android.hardware.sensor.hifi_sensors và PHẢI đáp ứng các yêu cầu liên quan đến con quay hồi chuyển, gia tốc kế và từ kế cho android.hardware.hifi_sensors.
Các quá trình triển khai thiết bị PHẢI hỗ trợ HardwarePropertiesManager.getDevicetemperatures API và trả về các giá trị chính xác cho nhiệt độ trên da.
Việc triển khai thiết bị PHẢI có một màn hình được nhúng, và độ phân giải của thiết bị tối thiểu PHẢI là FullHD(1080p) và
Màn hình PHẢI đo trong khoảng 4,7 inch và 6 inch đường chéo.
Màn hình PHẢI cập nhật ít nhất 60 Hz khi ở Chế độ thực tế ảo.
Độ trễ hiển thị trên thời gian chuyển đổi từ màu xám sang màu xám, màu trắng sang màu đen và màu đen sang màu trắng PHẢI là ≤ 3 mili giây.
Màn hình PHẢI hỗ trợ chế độ độ bền thấp với khả năng lưu trữ cố định ≤5 ms,độ bền vững được định nghĩa là khoảng thời gian mà một điểm ảnh phát ra ánh sáng.
Triển khai thiết bị PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data dài Extension section 7.4.3.

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

Một số tiêu chí về hiệu suất và hiệu suất tối thiểu rất quan trọng đối với trải nghiệm người dùng và có tác động đến các giả định cơ sở mà nhà phát triển sẽ đưa ra khi phát triển một ứng dụng. Các thiết bị Android Watch NÊN và các loại triển khai thiết bị khác PHẢI đáp ứng những tiêu chí sau.

8.1. Tính nhất quán trong trải nghiệm người dùng

Quá trình triển khai thiết bị PHẢI mang lại giao diện người dùng mượt mà bằng cách đảm bảo tốc độ khung hình và thời gian phản hồi nhất quán cho các ứng dụng và trò chơi. Quá trình triển khai thiết bị PHẢI đáp ứng các yêu cầu sau:

Độ trễ khung hình nhất quán . Độ trễ khung hình không nhất quán hoặc độ trễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình trong một giây và PHẢI dưới 1 khung hình trong một giây.
Độ trễ giao diện người dùng . Hoạt động triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách gồm 10.000 mục trong danh sách do Bộ kiểm tra tính tương thích (CTS) xác định trong chưa đầy 36 giây.
Chuyển đổi tác vụ . Khi chạy nhiều ứng dụng, việc chạy lại một ứng dụng đang chạy sau khi khởi chạy PHẢI mất chưa đến 1 giây.

8.2. Hiệu suất truy cập tệp I/O

Việc triển khai thiết bị PHẢI đảm bảo tính nhất quán về hiệu suất truy cập tệp bộ nhớ trong cho các thao tác đọc và ghi.

Ghi tuần tự . Việc triển khai thiết bị PHẢI đảm bảo hiệu suất ghi tuần tự tối thiểu 5MB/giây cho tệp 256MB sử dụng bộ đệm ghi 10MB.
Ghi ngẫu nhiên . Việc triển khai thiết bị PHẢI đảm bảo hiệu năng ghi ngẫu nhiên ít nhất 0,5 MB/s cho tệp 256 MB sử dụng bộ đệm ghi 4KB.
Đọc tuần tự . Việc triển khai thiết bị PHẢI đảm bảo hiệu suất đọc tuần tự tối thiểu 15 MB/giây cho tệp có kích thước 256 MB sử dụng bộ đệm ghi 10 MB.
Đọc ngẫu nhiên . Việc triển khai thiết bị PHẢI đảm bảo hiệu suất đọc ngẫu nhiên tối thiểu 3,5 MB/s cho tệp 256 MB sử dụng bộ đệm ghi 4KB.

8.3. Chế độ tiết kiệm điện

Android 6.0 giới thiệu chế độ tiết kiệm năng lượng ở chế độ Chờ ứng dụng và Nghỉ để tối ưu hoá mức sử dụng pin. Tất cả ứng dụng được miễn trừ khỏi các chế độ này PHẢI được hiển thị cho người dùng cuối. Ngoài ra, các thuật toán kích hoạt, bảo trì, đánh thức và việc sử dụng các chế độ cài đặt hệ thống chung của các chế độ tiết kiệm điện này KHÔNG được đi chệch khỏi Dự án nguồn mở Android.

Ngoài các chế độ tiết kiệm điện, các triển khai thiết bị Android CÓ THỂ triển khai bất kỳ hoặc cả 4 trạng thái ngủ như được xác định bởi Giao diện nguồn và cấu hình nâng cao (ACPI), nhưng nếu nó thực hiện trạng thái năng lượng S3 và S4, nó chỉ có thể nhập các trạng thái này khi đóng nắp là một phần của thiết bị.

8.4. Kế toán tiêu thụ điện năng

Việc tính toán và báo cáo mức tiêu thụ điện năng chính xác hơn mang lại cho nhà phát triển ứng dụng cả các ưu đãi lẫn công cụ để tối ưu hoá mẫu sử dụng điện năng của ứng dụng. Do đó, việc triển khai thiết bị:

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

8,5. Hiệu suất nhất quán

Hiệu suất có thể biến động đáng kể đối với các ứng dụng chạy trong thời gian dài có hiệu suất cao, do các ứng dụng khác chạy trong nền hoặc điều tiết CPU do giới hạn nhiệt độ. Android có các giao diện có lập trình để khi thiết bị có thể hoạt động, ứng dụng trên nền trước có thể yêu cầu hệ thống tối ưu hoá việc phân bổ tài nguyên nhằm giải quyết những biến động như vậy.

Các quá trình triển khai thiết bị PHẢI hỗ trợ Chế độ hiệu suất bền vững, chế độ này có thể mang lại hiệu suất nhất quán cho ứng dụng trên nền trước trong một khoảng thời gian dài khi được yêu cầu thông qua phương thức API Window.setSustainedPerformanceMode(). Quá trình triển khai Thiết bị PHẢI báo cáo chính xác khả năng hỗ trợ Chế độ hiệu suất bền vững thông qua phương thức API PowerManager.isSustainedPerformanceModeSupported().

Quá trình triển khai thiết bị có 2 lõi CPU trở lên PHẢI cung cấp ít nhất một lõi độc quyền mà ứng dụng trên nền trước có thể dành riêng. Nếu được cung cấp, việc triển khai PHẢI đáp ứng các yêu cầu sau:

Các phương thức triển khai PHẢI báo cáo thông qua phương thức API Process.getExclusiveCores(), số nhận dạng của các lõi độc quyền mà ứng dụng trên nền trước có thể đặt trước.
Quá trình triển khai thiết bị KHÔNG ĐƯỢC cho phép bất kỳ quy trình không gian người dùng nào ngoại trừ trình điều khiển thiết bị mà ứng dụng sử dụng để chạy trên các lõi độc quyền, nhưng CÓ THỂ cho phép một số quy trình nhân chạy khi cần.

Nếu quá trình triển khai thiết bị không hỗ trợ lõi độc quyền, thì lượt triển khai đó PHẢI trả về danh sách trống thông qua phương thức API Process.getExclusiveCores().

9. Khả năng tương thích của mô hình bảo mật

Việc triển khai thiết bị PHẢI triển khai một mô hình bảo mật phù hợp với mô hình bảo mật của nền tảng Android như nêu trong tài liệu tham khảo về Bảo mật và quyền truy cập trong các API ở tài liệu dành cho nhà phát triển Android. Quá trình triển khai thiết bị PHẢI hỗ trợ cài đặt ứng dụng tự ký mà không yêu cầu bất kỳ quyền/chứng chỉ bổ sung nào từ bất kỳ bên thứ ba/cơ quan nào. Cụ thể, các thiết bị tương thích PHẢI hỗ trợ cơ chế bảo mật được mô tả trong các tiểu mục sau.

9.1. Quyền

Quá trình triển khai thiết bị PHẢI hỗ trợ mô hình quản lý quyền của Android như nêu trong tài liệu dành cho nhà phát triển Android. Cụ thể, quá trình triển khai PHẢI thực thi từng quyền được xác định như mô tả trong tài liệu SDK; không có quyền nào bị lược bỏ, thay đổi hoặc bỏ qua. Quá trình triển khai CÓ THỂ bổ sung thêm các quyền, miễn là chuỗi mã nhận dạng quyền mới không nằm trong không gian tên android.*.

Chỉ được cấp các quyền có protectionLevel 'PROTECTION_FLAG_PRIVILEGED' cho những ứng dụng được tải trước trong (các) đường dẫn đặc quyền trong danh sách cho phép của hình ảnh hệ thống, chẳng hạn như đường dẫn system/priv-app trong quá trình triển khai AOSP (Dự án nguồn mở Android).

Quyền có mức độ bảo vệ nguy hiểm là quyền khi bắt đầu chạy. Ứng dụng có targetSdkVersion > 22 và yêu cầu mã trong thời gian chạy. Triển khai thiết bị:

PHẢI hiển thị một giao diện chuyên dụng để người dùng quyết định xem có cấp các quyền khi bắt đầu chạy được yêu cầu hay không, đồng thời cung cấp giao diện để người dùng quản lý các quyền khi bắt đầu chạy.
PHẢI có một và chỉ một cách triển khai cho cả hai giao diện người dùng.
KHÔNG ĐƯỢC cấp bất kỳ quyền khi bắt đầu chạy nào cho các ứng dụng được cài đặt trước trừ phi:
- có thể có được sự đồng ý của người dùng trước khi ứng dụng sử dụng
- quyền khi bắt đầu chạy được liên kết với mẫu ý định mà ứng dụng cài đặt trước được đặt làm trình xử lý mặc định

9.2. UID và tách biệt quy trình

Quá trình triển khai thiết bị PHẢI hỗ trợ mô hình hộp cát của ứng dụng Android, trong đó mỗi ứng dụng chạy dưới dạng một UID Unixstyle duy nhất và trong một quy trình riêng. Quá trình triển khai thiết bị PHẢI hỗ trợ chạy nhiều ứng dụng giống như 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ư nêu trong tài liệu tham khảo về Bảo mật và quyền.

9.3. Quyền đối với hệ thống tệp

Các quá trình triển khai thiết bị PHẢI hỗ trợ mô hình quản lý quyền truy cập vào tệp Android như 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ế

Quá trình triển khai thiết bị CÓ THỂ bao gồm các môi trường thời gian chạy thực thi ứng dụng bằng một số phần mềm hoặc công nghệ khác ngoài Định dạng có thể thực thi Dalvik hoặc mã gốc. Tuy nhiên, các môi trường thực thi thay thế như vậy KHÔNG ĐƯỢC ảnh hưởng đến mô hình bảo mật của Android hoặc tính bảo mật của các ứng dụng Android đã cài đặt, như mô tả trong phần này.

Môi trường thời gian chạy thay thế PHẢI là các ứng dụng Android và tuân thủ mô hình bảo mật Android tiêu chuẩn, như được mô tả ở nơi khác trong phần 9.

Môi trường thời gian chạy thay thế KHÔNG được cấp quyền truy cập vào những 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 <uses-permission> cơ chế.

Môi trường thời gian chạy thay thế KHÔNG được cho phép ứng dụng sử dụng những tính năng được bảo vệ bằng các quyền của Android bị hạn chế cho các ứng dụng hệ thống.

Môi trường thời gian chạy thay thế PHẢI tuân thủ mô hình hộp cát Android. Cụ thể là các môi trường thời gian chạy thay thế:

NÊN cài đặt ứng dụng qua PackageManager vào các hộp cát Android riêng biệt (mã nhận dạng người dùng Linux, v.v.).
CÓ THỂ cung cấp một hộp cát Android duy nhất được tất cả ứng dụng dùng chung môi trường thời gian chạy thay thế.
Các ứng dụng đã cài đặt sử dụng môi trường thời gian chạy thay thế KHÔNG ĐƯỢC sử dụng lại hộp cát của bất kỳ ứng dụng nào khác được cài đặt trên thiết bị, trừ phi thông qua cơ chế Android tiêu chuẩn về mã nhận dạng người dùng chung và chứng chỉ ký.
KHÔNG ĐƯỢC khởi chạy bằng, cấp hoặc được cấp quyền truy cập vào hộp cát tương ứng với các ứng dụng Android khác.
KHÔNG ĐƯỢC chạy cùng, được cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của người dùng cấp cao (gốc) hoặc của bất kỳ mã nhận dạng người dùng nào khác.

Tệp .apk của thời gian chạy thay thế CÓ THỂ được đưa vào hình ảnh hệ thống triển khai thiết bị, nhưng PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng khác đi kèm với quá trình triển khai thiết bị.

Khi cài đặt ứng dụng, môi trường thời gian chạy thay thế PHẢI lấy sự đồng ý của người dùng đối với các quyền của Android mà ứng dụng sử dụng. Nếu 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.), thì thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng có thể truy cập vào tài nguyên đó. Nếu 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, thì môi trường thời gian chạy PHẢI liệt kê tất cả các quyền do chính môi trường thời gian chạy đó giữ khi cài đặt bất kỳ ứng dụng nào sử dụng môi trường thời gian chạy đó.

9,5. Hỗ trợ nhiều người dùng

Tính năng này là không bắt buộc đối với tất cả các loại thiết bị.

Android hỗ trợ nhiều người dùng và cung cấp khả năng tách biệt người dùng hoàn toàn. Quá trình triển khai thiết bị CÓ THỂ cho phép nhiều người dùng, nhưng khi được bật PHẢI đáp ứng các yêu cầu sau liên quan đến tính năng hỗ trợ nhiều người dùng:

Các quá trình triển khai thiết bị Android Automotive có bật tính năng hỗ trợ nhiều người dùng PHẢI bao gồm một tài khoản khách cho phép tất cả chức năng do hệ thống xe cung cấp mà không yêu cầu người dùng đăng nhập.
Những quá trình triển khai thiết bị không khai báo cờ tính năng android.hardware.telephony PHẢI hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng bổ sung và khả năng của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để những người dùng khác làm việc cùng với khả năng quản lý các hạn chế chi tiết hơn trong các ứng dụng có sẵn trong các môi trường đó.
Ngược lại, các phương pháp triển khai thiết bị khai báo cờ tính năng android.hardware.telephony KHÔNG hỗ trợ các hồ sơ bị hạn chế mà PHẢI phù hợp với phương thức 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à SMS.
Đối với từng người dùng, việc triển khai thiết bị PHẢI triển khai một mô hình bảo mật nhất quán với mô hình bảo mật của nền tảng Android như nêu trong tài liệu tham khảo về Bảo mật và quyền truy cập trong các API.
Mỗi phiên bản người dùng trên thiết bị Android PHẢI có các thư mục bộ nhớ ngoài riêng biệt và tách biệt. Quá trình triển khai thiết bị CÓ THỂ lưu trữ thông tin của nhiều người dùng trên cùng một ổ đĩa hoặc hệ thống tệp. Tuy nhiên, việc triển khai thiết bị PHẢI đảm bảo rằng các ứng dụng thuộc sở hữu và đang chạy thay mặt cho một người dùng cụ thể không thể liệt kê, đọc hoặc ghi vào dữ liệu thuộc sở hữu của bất kỳ người dùng nào khác. Xin lưu ý rằng phương tiện di động, chẳng hạn như khe cắm thẻ SD, có thể cho phép một người dùng truy cập vào dữ liệu của người khác thông qua máy tính lưu trữ. Vì lý do này, các quá trình triển khai thiết bị sử dụng phương tiện di động cho API bộ nhớ ngoài PHẢI mã hoá nội dung của thẻ SD nếu chế độ nhiều người dùng được bật bằng cách sử dụng khoá chỉ được lưu trữ trên phương tiện không thể tháo rời mà chỉ hệ thống mới có thể truy cập. Vì việc này sẽ làm cho máy tính lưu trữ không đọc được nội dung nghe nhìn, nên cần phải triển khai thiết bị để chuyển sang MTP hoặc một hệ thống tương tự để cung cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại. Theo đó, các quá trình triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN bật chế độ nhiều người dùng nếu chúng sử dụng phương tiện di động cho bộ nhớ ngoài chính.

9.6. Cảnh báo qua tin nhắn dịch vụ

Android hỗ trợ tính năng cảnh báo cho người dùng về mọi tin nhắn SMS đặc biệt gửi đi. Tin nhắn dịch vụ là những tin nhắn văn bản được gửi đến một dịch vụ đã đăng ký với nhà mạng và người dùng có thể bị tính phí. Các quá trình triển khai thiết bị tuyên bố khả năng hỗ trợ android.hardware.telephony PHẢI cảnh báo người dùng trước khi gửi tin nhắn SMS đến các số được xác định bằng biểu thức chính quy được xác định trong tệp /data/vi tính/sms/codes.xml trong thiết bị. Dự án nguồn mở Android ngược dòng cung cấp một phương thức triển khai đáp ứng yêu cầu này.

9,7. Các tính năng bảo mật kernel

Android Sandbox bao gồm những tính năng sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) của Linux tăng cường bảo mật (SELinux), hộp cát bảo mật và các tính năng bảo mật khác trong nhân Linux. 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:

PHẢI duy trì khả năng tương thích với các ứng dụng hiện có.
KHÔNG ĐƯỢC hiển thị giao diện người dùng khi phát hiện và chặn thành công lỗi vi phạm bảo mật, nhưng CÓ THỂ hiển thị giao diện người dùng khi xảy ra lỗi vi phạm bảo mật được bỏ chặn dẫn đến việc khai thác thành công.
KHÔNG được là người dùng hoặc nhà phát triển có thể định cấu hình.

Nếu bất kỳ API nào dùng cho cấu hình của chính sách tiếp xúc với một ứng dụng có thể ảnh hưởng đến một ứng dụng khác (chẳng hạn như API Quản trị thiết bị), thì API KHÔNG ĐƯỢC cho phép các cấu hình phá vỡ khả năng tương thích.

Thiết bị PHẢI triển khai SELinux hoặc nếu sử dụng một nhân hệ điều hành không phải Linux, thì phải triển khai một hệ thống kiểm soát truy cập bắt buộc tương đương. Thiết bị cũng PHẢI đáp ứng các yêu cầu sau đây. Việc triển khai tham chiếu trong Dự án nguồn mở Android ở trên (upstream).

Triển khai thiết bị:

PHẢI đặt SELinux thành chế độ thực thi toàn cục.
PHẢI định cấu hình tất cả các miền ở chế độ thực thi. Không có miền nào ở chế độ được phép, bao gồm cả miền dành riêng cho một thiết bị/nhà cung cấp.
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) ngược dòng 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 AOSP SELinux cũng như miền cụ thể của thiết bị/nhà cung cấp.
PHẢI chia khung phương tiện thành nhiều quy trình để có thể cấp quyền truy cập cho từng quy trình trong phạm vi hẹp hơn như mô tả trên trang web Dự án nguồn mở Android.

Quá trình triển khai thiết bị NÊN giữ lại chính sách SELinux mặc định được cung cấp trong thư mục system/sepolicy của Dự án nguồn mở Android ngược dòng và chỉ thêm vào chính sách này cho cấu hình dành riêng cho thiết bị của riêng chúng. Các quá trình triển khai thiết bị PHẢI tương thích với Dự án nguồn mở Android ở thượng nguồn.

Thiết bị PHẢI triển khai cơ chế hộp cát của ứng dụng hạt nhân cho phép lọc lệnh gọi hệ thống bằng chính sách có thể định cấu hình từ các chương trình đa luồng. Dự án nguồn mở Android ngược dòng đáp ứng yêu cầu này thông qua việc bật seccomp-BPF với tính năng đồng bộ hoá nhóm luồng (TSYNC) như mô tả trong phần Cấu hình hạt nhân của source.android.com.

9,8. Quyền riêng tư

Nếu thiết bị triển khai chức năng trong hệ thống để ghi lại nội dung hiển thị trên màn hình và/hoặc ghi lại luồng âm thanh được phát trên thiết bị, thì thiết bị PHẢI liên tục thông báo cho người dùng mỗi khi chức năng này được bật và chủ động chụp/ghi.

Nếu quá trình triển khai thiết bị có cơ chế định tuyến lưu lượng truy cập dữ liệu mạng qua máy chủ proxy hoặc cổng VPN theo mặc định (ví dụ: tải trước dịch vụ VPN khi đã cấp android.permission.CONTROL_VPN), thì quá trình triển khai thiết bị PHẢI yêu cầu người dùng đồng ý trước khi bật cơ chế đó, trừ phi VPN đó được Trình kiểm soát chính sách thiết bị bật qua DevicePolicyManager.setAlwaysOnVpnPackage(). Trong trường hợp đó, người dùng không cần đưa ra sự đồng ý riêng mà PHẢI chỉ nhận được thông báo.

Các quá trình triển khai thiết bị PHẢI đi kèm với một kho lưu trữ Tổ chức phát hành chứng chỉ (CA) do người dùng thêm trống và PHẢI cài đặt trước cùng một chứng chỉ gốc cho kho lưu trữ CA được hệ thống tin cậy như được cung cấp trong Dự án nguồn mở Android ở cấp trên.

Khi thiết bị được định tuyến thông qua VPN hoặc CA gốc của người dùng được cài đặt, quá trình triển khai PHẢI hiển thị cảnh báo cho biết lưu lượng truy cập mạng có thể được giám sát người dùng.

Nếu quá trình triển khai thiết bị có cổng USB hỗ trợ chế độ ngoại vi USB, thì quá trình triển khai thiết bị PHẢI hiển thị giao diện người dùng để xin phép người dùng trước khi cho phép truy cập vào nội dung của bộ nhớ dùng chung qua cổng USB.

9,9. Mã hoá bộ nhớ dữ liệu

Không bắt buộc đối với việc triển khai thiết bị Android không có màn hình khoá an toàn.

Nếu quá trình triển khai thiết bị hỗ trợ màn hình khoá an toàn như được mô tả trong mục 9.11.1, thì thiết bị PHẢI hỗ trợ mã hoá lưu trữ dữ liệu của dữ liệu riêng tư của ứng dụng (/phân vùng dữ liệu), cũng như phân vùng bộ nhớ dùng chung của ứng dụng (/phân vùng sdcard) nếu đó là một bộ phận vĩnh viễn, không thể tháo rời của thiết bị.

Đối với những thiết bị triển khai hỗ trợ mã hoá lưu trữ dữ liệu và có hiệu suất mã hoá theo Tiêu chuẩn mã hoá nâng cao (AES) trên 50MiB/giây, chế độ mã hoá lưu trữ dữ liệu PHẢI được bật theo mặc định tại thời điểm người dùng hoàn tất quy trình thiết lập ngay. Nếu quá trình triển khai thiết bị đã triển khai trên một phiên bản Android cũ hơn với chế độ mã hoá bị tắt theo mặc định, thì thiết bị đó không thể đáp ứng yêu cầu thông qua bản cập nhật phần mềm hệ thống, do đó có thể được miễn trừ.

Các quá trình triển khai thiết bị PHẢI đáp ứng yêu cầu mã hoá bộ nhớ dữ liệu nêu trên thông qua việc triển khai File dựa trên Mã hoá (FBE).

9.9.1. Khởi động trực tiếp

Tất cả thiết bị PHẢI triển khai các API chế độ Khởi động trực tiếp ngay cả khi các thiết bị đó không hỗ trợ Mã hoá bộ nhớ. Cụ thể, các Ý định LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED vẫn phải được truyền đi để báo hiệu cho các ứng dụng có thể nhận biết Khởi động trực tiếp rằng người dùng có thể sử dụng vị trí lưu trữ Được mã hoá thiết bị (DE) và Thông tin xác thực được mã hoá (CE).

9.9.2. Mã hoá dựa trên tệp

Triển khai thiết bị hỗ trợ FBE:

PHẢI khởi động mà không yêu cầu người dùng cung cấp thông tin đăng nhập và cho phép các ứng dụng nhận biết tính năng Khởi động trực tiếp truy cập vào bộ nhớ được mã hoá của thiết bị (DE) sau khi thông báo LOCKED_BOOT_COMPLETED được phát đi.
Chỉ được truy cập vào bộ nhớ Mã hoá thông tin xác thực (CE) sau khi người dùng mở khoá thiết bị bằng cách cung cấp thông tin đăng nhập (ví dụ: mật mã, mã PIN, hình mở khoá hoặc vân tay) và phát đi thông báo ACTION_USER_UNLOCKED. Quá trình triển khai thiết bị KHÔNG ĐƯỢC cung cấp bất kỳ phương thức nào để mở khoá bộ nhớ được bảo vệ theo tiêu chuẩn CE khi không có thông tin đăng nhập do người dùng cung cấp.
PHẢI hỗ trợ Xác minh quy trình khởi động và đảm bảo rằng các khoá DE được liên kết theo mã hoá với gốc tin cậy phần cứng của thiết bị.
PHẢI hỗ trợ mã hoá nội dung tệp bằng AES với độ dài khoá là 256 bit ở chế độ XTS.
PHẢI hỗ trợ mã hoá tên tệp bằng AES với độ dài khoá là 256 bit ở chế độ CBC-CTS.
CÓ THỂ hỗ trợ các thuật toán mật mã thay thế, độ dài khoá và chế độ để mã hoá nội dung tệp và tên tệp. Tuy nhiên, theo mặc định, PHẢI sử dụng các thuật toán mật mã, độ dài khoá và chế độ bắt buộc được hỗ trợ.
NÊN làm cho các ứng dụng thiết yếu được tải trước (ví dụ: Alarm, Phone, Messenger) nhận biết được tính năng Khởi động trực tiếp.

Các khoá bảo vệ khu vực lưu trữ CE và DE:

PHẢI được liên kết bằng mã hoá với một Kho khoá dựa trên phần cứng. Khoá CE phải được liên kết với thông tin đăng nhập màn hình khoá của người dùng. Nếu người dùng chưa chỉ định thông tin đăng nhập màn hình khoá, thì khoá CE PHẢI được liên kết với một mật mã mặc định.
PHẢI là duy nhất và khác biệt, nói cách khác, không có khoá CE hoặc DE của người dùng nào có thể khớp với bất kỳ khoá CE hoặc DE nào của người dùng khác.

Dự án Nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên của tính năng này dựa trên tính năng mã hoá trong hệ điều hành Linux kernel ext4.

9.9.3. Mã hoá toàn bộ đĩa

Các phương pháp triển khai thiết bị hỗ trợ mã hoá toàn bộ đĩa (FDE). PHẢI sử dụng AES với khoá 128 bit (trở lên) và chế độ được thiết kế để lưu trữ (ví dụ: AES-XTS, AES-CBC-ESSIV). Bạn KHÔNG ĐƯỢC ghi khoá mã hoá vào bộ nhớ khi chưa mã hoá. Ngoại trừ khi đang được sử dụng, khoá mã hoá PHẢI được mã hoá AES với thông tin xác thực màn hình khoá được kéo dài bằng thuật toán kéo giãn chậm (ví dụ: PBKDF2 hoặc scrypt). Nếu người dùng chưa chỉ định thông tin xác thực màn hình khóa hoặc đã tắt việc sử dụng mật mã để mã hóa, hệ thống NÊN sử dụng mật mã mặc định để gói khóa mã hóa. Nếu thiết bị cung cấp kho khoá dựa trên phần cứng, thì thuật toán mở rộng mật khẩu PHẢI được liên kết bằng mật mã với kho khoá đó. Khoá mã hoá KHÔNG ĐƯỢC gửi ra khỏi thiết bị (ngay cả khi được gói bằng mật mã của người dùng và/hoặc khoá ràng buộc phần cứng). Dự án Nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên của tính năng này dựa trên tính năng dm-crypt của nhân hệ điều hành Linux.

9,10. Tính toàn vẹn của thiết bị

Các yêu cầu sau đây đảm bảo trạng thái về tính toàn vẹn của thiết bị được thể hiện rõ ràng.

Quá trình triển khai thiết bị PHẢI báo cáo chính xác thông qua phương thức API Hệ thống PersistentDataBlockManager.getFlashLockState() xem trạng thái trình tải khởi động có cho phép cài đặt ROM hình ảnh hệ thống hay không. Trạng thái FLASH_LOCK_UNKNOWN dành riêng cho các quá trình triển khai thiết bị nâng cấp từ phiên bản Android cũ khi không có phương thức API hệ thống mới này.

Xác minh quy trình khởi động là một tính năng đảm bảo tính toàn vẹn của phần mềm thiết bị. Nếu hoạt động triển khai thiết bị hỗ trợ tính năng này, thì hoạt động triển khai đó PHẢI:

Khai báo cờ tính năng nền tảng android.software.verified_boot.
Thực hiện quy trình xác minh trên mọi trình tự khởi động.
Bắt đầu xác minh từ một khoá phần cứng bất biến là gốc của sự tin cậy và lên đến phân vùng hệ thống.
Triển khai từng giai đoạn xác minh để kiểm tra tính toàn vẹn và xác thực của tất cả các byte trong giai đoạn tiếp theo trước khi thực thi mã ở giai đoạn tiếp theo.
Sử dụng các thuật toán xác minh mạnh mẽ như những đề xuất hiện tại của NIST cho thuật toán băm (SHA-256) và kích thước khoá công khai (RSA-2048).
KHÔNG ĐƯỢC cho phép hoàn tất quá trình khởi động khi xác minh hệ thống không thành công, trừ khi người dùng đồng ý thử khởi động. Trong trường hợp đó, bạn KHÔNG ĐƯỢC sử dụng dữ liệu từ bất kỳ khối bộ nhớ chưa được xác minh nào.
KHÔNG ĐƯỢC cho phép sửa đổi các phân vùng đã xác minh trên thiết bị trừ phi người dùng đã mở khoá trình tải khởi động một cách rõ ràng.

Dự án nguồn mở Android ngược dòng cung cấp phương thức triển khai ưu tiên của tính năng này dựa trên tính năng dm-verity của nhân hệ điều hành Linux.

Kể từ Android 6.0, các quá trình triển khai thiết bị có hiệu suất mã hoá theo Tiêu chuẩn mã hoá nâng cao (AES) trên 50 MiB/giây PHẢI hỗ trợ quy trình khởi động được xác minh để đảm bảo tính toàn vẹn của thiết bị.

Nếu đã triển khai thiết bị mà không hỗ trợ tính năng khởi động được xác minh trên một phiên bản Android cũ hơn, thì thiết bị đó không thể hỗ trợ tính năng này bằng bản cập nhật phần mềm hệ thống, do đó, thiết bị đó sẽ được miễn trách nhiệm đáp ứng yêu cầu này.

9,11. Khoá và thông tin đăng nhập

Hệ thống kho khoá Android cho phép nhà phát triển ứng dụng lưu trữ các khoá mã hoá trong một vùng chứa và sử dụng các khoá đó trong các hoạt động mã hoá thông qua KeyChain API hoặc API Kho khoá.

Tất cả cách triển khai thiết bị Android PHẢI đáp ứng các yêu cầu sau:

KHÔNG NÊN giới hạn số lượng khoá có thể tạo và tối thiểu PHẢI cho phép nhập hơn 8.192 khoá.
Quá trình xác thực màn hình khoá PHẢI có số lần thử giới hạn số lần yêu cầu và PHẢI có thuật toán thời gian đợi luỹ thừa. Sau hơn 150 lần thử không thành công, thời gian chờ PHẢI tối thiểu là 24 giờ cho mỗi lần thử.
Khi quá trình triển khai thiết bị hỗ trợ màn hình khoá an toàn, ứng dụng PHẢI sao lưu quá trình triển khai kho khoá bằng phần cứng bảo mật và đáp ứng các yêu cầu sau:
- PHẢI triển khai các thuật toán mật mã hoá RSA, AES, ECDSA và HMAC dựa trên phần cứng cũng như các hàm băm gia đình MD5, SHA1, SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android.
- PHẢI thực hiện xác thực màn hình khoá trong phần cứng bảo mật và chỉ khi thành công mới cho phép sử dụng các khoá ràng buộc xác thực. Dự án nguồn mở Android ngược dòng cung cấp Lớp trừu tượng phần cứng (HAL) cho người trực điện thoại có thể dùng để đáp ứng yêu cầu này.

Lưu ý rằng nếu đã triển khai thiết bị trên một phiên bản Android cũ, thì thiết bị đó sẽ được miễn trách nhiệm có kho khoá dựa trên phần cứng, trừ phi thiết bị đó khai báo tính năng android.hardware.fingerprint yêu cầu kho khoá dựa trên phần cứng.

9.11.1. Màn hình khoá an toàn

Quá trình triển khai thiết bị CÓ THỂ thêm hoặc sửa đổi phương thức xác thực để mở khoá màn hình khoá, nhưng vẫn PHẢI đáp ứng các yêu cầu sau:

Phương pháp xác thực, nếu dựa trên bí mật đã biết, KHÔNG ĐƯỢC xem là màn hình khóa bảo mật trừ khi đáp ứng tất cả các yêu cầu sau:
- Entropy của độ dài ngắn nhất được phép của đầu vào PHẢI lớn hơn 10 bit.
- Entropy tối đa của tất cả đầu vào có thể có PHẢI lớn hơn 18 bit.
- KHÔNG ĐƯỢC thay thế bất kỳ phương thức xác thực hiện có nào (mã PIN, hình mở khoá, mật khẩu) được triển khai và cung cấp trong AOSP.
- PHẢI tắt khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() với hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_SOMETHING .
Nếu dựa trên mã thông báo vật lý hoặc vị trí, thì phương pháp xác thực KHÔNG ĐƯỢC xem là màn hình khoá bảo mật trừ phi phương thức đó đáp ứng tất cả các yêu cầu sau:
- Lớp này PHẢI có cơ chế dự phòng để sử dụng một trong các phương thức xác thực chính, dựa trên bí mật đã biết và đáp ứng các yêu cầu để được coi là màn hình khoá bảo mật.
- Tính năng này PHẢI được tắt và chỉ cho phép phương thức xác thực chính mở khoá màn hình khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách bằng phương thức DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) hoặc phương thức DevicePolicyManager.setPasswordQuality() có hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_UNSPECIFIED .
Phương pháp xác thực, nếu dựa trên sinh trắc học, KHÔNG ĐƯỢC xem là màn hình khóa an toàn trừ khi đáp ứng tất cả các yêu cầu sau:
- Lớp này PHẢI có cơ chế dự phòng để sử dụng một trong các phương thức xác thực chính, dựa trên bí mật đã biết và đáp ứng các yêu cầu để được coi là màn hình khoá bảo mật.
- Tính năng này PHẢI được tắt và chỉ cho phép phương thức xác thực chính mở khoá màn hình khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách tính năng keguard bằng cách gọi phương thức DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
- Nó PHẢI có tỷ lệ chấp nhận sai bằng hoặc mạnh hơn yêu cầu đối với cảm biến vân tay như mô tả trong mục 7.3.10 hoặc PHẢI tắt và chỉ cho phép phương thức xác thực chính mở khoá màn hình khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã thiết lập chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() với hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_BIOMETRIC_WEAK .
Nếu phương pháp xác thực không thể được coi là một màn hình khoá bảo mật, thì phương pháp đó:
- PHẢI trả về false cho cả phương thức KeyguardManager.isKeyguardSecure() và KeyguardManager.isDeviceSecure().
- PHẢI tắt khi ứng dụng Trình kiểm soát chính sách thiết bị (DPC) đã đặt chính sách chất lượng mật khẩu thông qua phương thức DevicePolicyManager.setPasswordQuality() với hằng số chất lượng hạn chế hơn PASSWORD_QUALITY_UNSPECIFIED .
- KHÔNG ĐƯỢC đặt lại đồng hồ hẹn giờ hết hạn mật khẩu do DevicePolicyManager.setPasswordExpirationTimeout() đặt.
- KHÔNG ĐƯỢC xác thực quyền truy cập vào kho khoá nếu ứng dụng đã gọi KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)).
Nếu phương pháp xác thực dựa trên một thiết bị vật lý, vị trí hoặc dữ liệu sinh trắc học có tỷ lệ chấp nhận sai cao hơn yêu cầu đối với cảm biến vân tay như mô tả trong 7.3.10 thì phương pháp đó:
- KHÔNG ĐƯỢC đặt lại đồng hồ hẹn giờ hết hạn mật khẩu do DevicePolicyManager.setPasswordExpirationTimeout() đặt.
- KHÔNG ĐƯỢC xác thực quyền truy cập vào kho khoá nếu ứng dụng đã gọi KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9,12. Xóa dữ liệu

Thiết bị PHẢI cung cấp cho người dùng cơ chế để thực hiện "Đặt lại dữ liệu về trạng thái ban đầu" cho phép xoá tất cả dữ liệu theo logic và thực tế, ngoại trừ những trường hợp sau:

Hình ảnh hệ thống
Mọi tệp hệ điều hành mà hình ảnh hệ thống yêu cầu

PHẢI xoá tất cả dữ liệu do người dùng tạo. Điều này PHẢI đáp ứng các tiêu chuẩn ngành có liên quan về việc xoá dữ liệu như NIST SP800-88. Bạn PHẢI được sử dụng cách này để triển khai API XóaData() (một phần của API Quản trị thiết bị Android) được mô tả trong phần 3.9 Quản trị thiết bị.

Thiết bị CÓ THỂ cung cấp tính năng xoá sạch dữ liệu nhanh chóng để tiến hành xoá dữ liệu theo logic.

9,13. Chế độ khởi động an toàn

Android cung cấp chế độ cho phép người dùng khởi động ở chế độ chỉ cho phép chạy các ứng dụng hệ thống được cài đặt trước và tắt tất cả ứng dụng bên thứ ba. Chế độ này còn được gọi là "Chế độ khởi động an toàn", mang lại cho người dùng khả năng gỡ cài đặt các ứng dụng bên thứ ba có khả năng gây hại.

Các hoạt động triển khai trên thiết bị Android HẤP DẪN ĐƯỢC ĐỀ XUẤT để triển khai Chế độ khởi động an toàn và đáp ứng các yêu cầu sau:

Các quá trình triển khai thiết bị PHẢI cung cấp cho người dùng tuỳ chọn để vào Chế độ khởi động an toàn qua trình đơn khởi động. Quy trình này có thể truy cập được thông qua quy trình làm việc khác với quy trình khởi động thông thường.
Quá trình triển khai thiết bị PHẢI cung cấp cho người dùng lựa chọn chuyển sang Chế độ khởi động an toàn sao cho không bị gián đoạn từ các ứng dụng bên thứ ba được cài đặt trên thiết bị, trừ trường hợp ứng dụng bên thứ ba là Trình kiểm soát chính sách thiết bị và đã đặt cờ UserManager.DISALLOW_SAFE_BOOT thành true.
Quá trình triển khai thiết bị PHẢI cung cấp cho người dùng khả năng gỡ cài đặt mọi ứng dụng bên thứ ba trong Chế độ an toàn.

9,14. Cách ly hệ thống xe ô tô

Các thiết bị Android Automotive được dự kiến sẽ trao đổi dữ liệu với các hệ thống phụ quan trọng trên xe, chẳng hạn như bằng cách sử dụng HAL xe để gửi và nhận thông báo qua mạng xe như xe buýt CAN. Quá trình triển khai thiết bị Android Automotive PHẢI triển khai các tính năng bảo mật bên dưới các lớp khung Android để ngăn chặn hoạt động tương tác độc hại hoặc vô tình giữa khung Android hoặc ứng dụng bên thứ ba và hệ thống phụ của xe. Sau đây là các tính năng bảo mật:

Thông báo kiểm soát từ các hệ thống con trên xe khung Android, ví dụ: đưa các loại thông báo và nguồn thông báo được phép vào danh sách cho phép.
Bộ kiểm soát chống lại các cuộc tấn công từ chối dịch vụ từ khung Android hoặc ứng dụng bên thứ ba. Tính năng này giúp tránh phần mềm độc hại làm ngập lưu lượng truy cập trên mạng của xe, từ đó có thể làm hỏng các hệ thống phụ của xe.

10. Kiểm tra tính tương thích của phần mềm

Quá trình triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử được mô tả trong phần này.

Tuy nhiên, lưu ý rằng không có gói kiểm thử phần mềm nào là hoàn toàn toàn diện. Vì lý do này, các trình triển khai thiết bị NÊN DÙNG để thực hiện số lượng thay đổi tối thiểu nhất có thể đối với tham chiếu và phương thức triển khai ưu tiên của Android trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ gây ra lỗi tạo ra sự cố không tương thích cần phải sửa lại cũng như có thể cập nhật thiết bị.

10.1. Bộ kiểm tra tính tương thích

Quá trình triển khai thiết bị PHẢI vượt qua Bộ kiểm tra tính tương thích (CTS) với Android có trong Dự án nguồn mở Android bằng phần mềm vận chuyển hoàn chỉnh trên thiết bị. Ngoài ra, người triển khai thiết bị NÊN sử dụng hoạt động triển khai tham chiếu trong cây Nguồn mở Android nhiều nhất có thể và PHẢI đảm bảo khả năng tương thích trong trường hợp có sự không rõ ràng trong CTS và trong mọi trường hợp triển khai lại các phần của mã nguồn tham chiếu.

CTS được thiết kế để chạy trên thiết bị thực tế. Giống như bất kỳ phần mềm nào, CTS có thể bản thân nó chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa tương thích này và nhiều bản sửa đổi của CTS có thể được phát hành cho Android 7.0. Quá trình triển khai thiết bị PHẢI vượt qua phiên bản CTS mới nhất hiện có tại thời điểm hoàn tất phần mềm thiết bị.

10,2. Người xác minh CTS

Quá trình triển khai thiết bị PHẢI thực thi chính xác tất cả các trường hợp có thể áp dụng trong Trình xác minh CTS. Trình xác minh CTS đi kèm với Bộ kiểm tra tính tương thích và dành cho nhân viên vận hành để kiểm tra chức năng mà hệ thống tự động không thể kiểm tra, chẳng hạn như máy ảnh và cảm biến có hoạt động chính xác hay không.

Trình xác minh CTS có các bài kiểm tra cho nhiều loại phần cứng, bao gồm cả một số phần cứng là tùy chọn. Quá trình triển khai thiết bị PHẢI vượt qua mọi bài kiểm thử về phần cứng mà thiết bị đó sở hữu; ví dụ: nếu thiết bị có gia tốc kế, thiết bị PHẢI thực thi chính xác trường hợp kiểm tra Gia tốc kế trong Trình xác minh CTS. Trường hợp kiểm tra các tính năng được ghi chú là không bắt buộc trong Tài liệu định nghĩa về khả năng tương thích này CÓ THỂ bị bỏ qua hoặc bỏ qua.

Mọi thiết bị và bản dựng đều PHẢI chạy Trình xác minh CTS đúng cách, như đã nêu ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên trình triển khai thiết bị dự kiến sẽ không chạy Trình xác minh CTS một cách rõ ràng trên các bản dựng chỉ khác nhau ở những khía cạnh không quan trọng. Cụ thể, các quá trình triển khai thiết bị khác với triển khai đã vượt qua Trình xác minh CTS chỉ bằng tập hợp các ngôn ngữ, thương hiệu đi kèm, v.v. CÓ THỂ bỏ qua thử nghiệm Trình xác minh CTS.

11. Phần mềm có thể cập nhật

Quá trình triển khai thiết bị PHẢI bao gồm một cơ chế thay thế toàn bộ phần mềm hệ thống. Cơ chế này không cần thực hiện nâng cấp "trực tiếp" – tức là bạn CÓ THỂ khởi động lại thiết bị.

Có thể sử dụng bất kỳ phương pháp nào, miễn là phương pháp đó có thể thay thế toàn bộ phần mềm đã cài đặt trước trên thiết bị. Ví dụ: bất kỳ phương pháp nào sau đây sẽ đáp ứng yêu cầu này:

Tải xuống “ qua mạng không dây (OTA)” bằng cách cập nhật ngoại tuyến thông qua việc khởi động lại.
"Chia sẻ Internet" có bản cập nhật qua USB từ máy tính lưu trữ.
Cập nhật ở chế độ “Ngoại tuyến” bằng cách khởi động lại và cập nhật từ một tệp trên bộ nhớ di động.

Tuy nhiên, nếu quá trình triển khai thiết bị có hỗ trợ kết nối dữ liệu không đo lượng dữ liệu (chẳng hạn như 802.11 hoặc cấu hình Bluetooth PAN (Mạng khu vực cá nhân), thì thiết bị PHẢI hỗ trợ tải xuống qua mạng không dây với tính năng cập nhật ngoại tuyến thông qua việc khởi động lại.

Cơ chế cập nhật được sử dụng PHẢI hỗ trợ các bản cập nhật mà không cần xoá dữ liệu người dùng. Tức là cơ chế cập nhật PHẢI bảo toàn dữ liệu riêng tư của ứng dụng và dữ liệu được chia sẻ của ứng dụng. Lưu ý rằng phần mềm Android ngược dòng có một cơ chế cập nhật đáp ứng yêu cầu này.

Đối với các hoạt động triển khai thiết bị chạy Android 7.0 trở lên, cơ chế cập nhật PHẢI hỗ trợ xác minh rằng hình ảnh hệ thống là tệp nhị phân giống hệt với kết quả dự kiến sau OTA. Việc triển khai OTA dựa trên khối trong Dự án nguồn mở Android ngược dòng (được thêm vào kể từ Android 5.1) đáp ứng yêu cầu này.

Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi phát hành nhưng vẫn nằm trong vòng đời sản phẩm hợp lý (được xác định theo sự tham khảo ý kiến của Nhóm tương thích Android) để ảnh hưởng đến khả năng tương thích của các ứng dụng bên thứ ba, người triển khai thiết bị PHẢI sửa lỗi thông qua một bản cập nhật phần mềm có sẵn có thể áp dụng cho cơ chế vừa mô tả.

Android có các tính năng cho phép ứng dụng Chủ sở hữu thiết bị (nếu có) kiểm soát việc cài đặt bản cập nhật hệ thống. Để tạo điều kiện cho việc này, hệ thống con cập nhật hệ thống cho các thiết bị báo cáo android.software.device_admin PHẢI triển khai hành vi được mô tả trong lớp SystemUpdatePolicy.

12. Nhật ký thay đổi tài liệu

Để xem bản tóm tắt các thay đổi đối với Định nghĩa về khả năng tương thích trong bản phát hành này, hãy làm như sau:

Nhật ký thay đổi tài liệu

Để xem tóm tắt nội dung thay đổi đối với các mục riêng lẻ:

12.1. Mẹo xem nhật ký thay đổi

Các thay đổi được đánh dấu như sau:

CDD
Thay đổi đáng kể đối với các yêu cầu về khả năng tương thích.
Tài liệu
Các thay đổi liên quan đến hình thức trình bày hoặc bản dựng.

Để xem nội dung chính xác nhất, hãy thêm các tham số URL pretty=full và no-merges vào URL nhật ký thay đổi của bạn.

13. Liên hệ với chúng tôi

Bạn có thể tham gia diễn đàn về khả năng tương thích với android và yêu cầu giải thích cụ thể hoặc nêu ra bất kỳ vấn đề nào mà bạn cho rằng tài liệu này không đề cập đến.