Việc sử dụng các từ khoá "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "KHÔNG SẼ", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" 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ị" hoặc "người triển khai" là một người hoặc tổ chức phát triển giải pháp phần cứng/phần mềm chạy Android 7.1. "Triển khai thiết bị" hoặc "triển khai là giải pháp phần cứng/phần mềm được phát triển.

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

Nếu định nghĩa này hoặc các thử nghiệm phần mềm được mô tả trong phần 10 không đề cập, không rõ ràng hoặc không đầy đủ, thì người 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 phương thức 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à phương thức triển khai ưu tiên của Android. NÊN triển khai mã nguồn "nguồn cấp trên" có sẵn trong Dự án nguồn mở Android ở mức độ tối đa có thể. Mặc dù có thể thay thế một số thành phần bằng cách triển khai thay thế, nhưng bạn KHÔNG NÊN làm như vậ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 đầy đủ về hành vi với cách triển khai Android chuẩn, bao gồm cả Bộ kiểm thử khả năng tương thích. Cuối cùng, xin lưu ý rằng tài liệu này nghiêm cấm một số hoạt động thay thế và sửa đổi thành phần.

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

2. Loại thiết bị

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

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

PHẢI có màn hình cảm ứng được nhúng trong thiết bị.
PHẢI có nguồn điện có thể di chuyển, chẳng hạn như pin.

Thiết bị Android Television là một thiết bị Android được triển khai dưới dạng giao diện giải trí để người dùng ngồi cách khoảng 3 mét có thể thưởng thức nội dung đa phương tiện kỹ thuật số, phim, trò chơi, ứng dụng và/hoặc truyền hình trực tiếp (gọi là "giao diện người dùng thư giãn" hoặc "giao diện người dùng 3 mét"). Thiết bị Android Television:

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ị đồng hồ Android là 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àn hình có chiều dài đường chéo thực tế 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 .

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

PHẢI có 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.*.

Tất cả các phương thức triển khai thiết bị Android không thuộc bất kỳ loại thiết bị nào nêu trên VẪN PHẢI đáp ứng tất cả các yêu cầu trong tài liệu này để tương thích với Android 7.1, 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ể nêu trên.

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

Đây là bản tóm tắt về những điểm khác biệt chính trong cấu hình phần cứng theo loại thiết bị. (Các ô trống biểu thị là "CÓ THỂ"). Không phải cấu hình nào cũng được đề cập trong bảng này; hãy xem các phần phần cứng có liên quan để biết thêm chi tiết.

Danh mục	Tính năng	Phần	Cầm tay	Truyền hình	Xem	Automotive	Khác
Đầu vào	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. Nhập bằng 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. 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
	Đài phát thanh di động	7.4.5. Chức năng mạng tối thiểu				NÊN
	Chế độ thiết bị ngoại vi/máy chủ USB	7.7. USB	NÊN			NÊN	NÊN
Đầu ra	Loa và/hoặc Cổng đầu ra â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 với API được quản lý

Môi trường thực thi mã byte Dalvik được quản lý là phương tiện chính cho các ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là tập hợp các giao diện nền tảng Android hiển thị cho các ứng dụng chạy trong môi trường thời gian chạy được quản lý. Việc triển khai thiết bị PHẢI cung cấp các phương thức 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 mà 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.

Việc 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).

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

Định nghĩa về khả năng tương thích này cho phép một số loại phần cứng mà Android bao gồm các API bị bỏ qua khi triển khai thiết bị. Trong những trường hợp như vậy, API VẪN PHẢI xuất hiện và hoạt động một cách hợp lý. Hãy xem mục 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 hỗ trợ việc mở rộng các API được quản lý trong khi vẫn giữ nguyên phiên bản cấp độ API. Việc triển khai thiết bị Android PHẢI tải trước quá trình triển khai AOSP của cả thư viện dùng chung ExtShared và dịch vụ ExtServices với các phiên bản cao hơn hoặc bằng phiên bản tối thiểu được phép cho mỗi cấp độ API. Ví dụ: việc 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 mềm của API

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" quan trọng chỉ có trong thời gian chạy, dưới dạng các ý định, quyền và các khía cạnh tương tự của ứng dụng Android không thể được thực thi tại thời điểm biên dịch ứng dụng.

3.2.1. Quyền

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

3.2.2. Tham số bản dựng

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 và có ý nghĩa trên các hoạt động triển khai thiết bị, bảng dưới đây bao gồm các quy định hạn chế bổ sung về định dạng của các giá trị này mà hoạt động triển khai thiết bị PHẢI tuân thủ.

Thông số	Thông tin chi tiết
VERSION.RELEASE	Phiên bản của hệ thống Android đang 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 được xác định trong 7.1 .
VERSION.SDK	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 7.1, trường này PHẢI có giá trị số nguyên 7.1_INT.
VERSION.SDK_INT	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 7.1, trường này PHẢI có giá trị số nguyên 7.1_INT.
VERSION.INCREMENTAL	Giá trị do người 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. KHÔNG ĐƯỢC sử dụng lại giá trị này cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Trường này thường được dùng để cho biết số bản dựng hoặc giá trị nhận dạng thay đổi trong hệ thống quản lý nguồn đã được dùng để tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
BẢNG	Giá trị do người triển khai thiết bị chọn để xác định phần cứng nội bộ cụ thể mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Bạn có thể sử dụng trường này để cho biết bản sửa đổi cụ thể của bo mạch 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	Giá trị phản ánh tên thương hiệu được 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à NÊN đại diện cho nhà sản xuất thiết bị hoặc thương hiệu công ty mà thiết bị được tiếp thị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc .
SUPPORTED_32_BIT_ABIS	Tên của tập lệnh (loại CPU + quy ước ABI) của mã gốc. Xem mục 3.3. Khả năng tương thích với API gốc .
SUPPORTED_64_BIT_ABIS	Tên của tập lệnh thứ hai (loại CPU + quy ước ABI) của mã gốc. Xem 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, 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à thiết kế 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.
VÂN TAY	Một chuỗi nhận dạng duy nhất bản dựng này. Tên này PHẢI dễ đọc đối với con người. Tiêu đề phải tuân theo mẫu sau: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/myproduct/ mydevice:7.1/LMYXX/3359:userdebug/test-keys Vân tay KHÔNG ĐƯỢC chứa 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ì bạn PHẢI thay thế các ký tự đó trong vân tay bản dựng bằng một ký tự khác, 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 hạt nhân hoặc /proc). Tên này PHẢI dễ đọc đối với con người. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9_-]+$”.
MÁY CHỦ	Một chuỗi nhận dạng duy nhất máy chủ lưu trữ mà bản dựng được tạo, ở định dạng mà con người đọc được. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
ID	Giá trị nhận dạng do người triển khai thiết bị chọn để tham chiếu đến một bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống với android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị đủ ý nghĩa để người dùng cuối có thể phân biệt giữa các bản dựng phần mềm. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy “^[a-zA-Z0-9._-]+$”.
NHÀ SẢN XUẤT	Tên thương mại của Nhà sản xuất thiết bị gốc (OEM) của sản phẩm. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
KIỂU MÁY	Giá trị do người triển khai thiết bị chọn, 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 mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
SẢN PHẨM	Giá trị do người triển khai thiết bị chọn, chứa tên phát triển hoặc tên mã của sản phẩm cụ thể (SKU) và PHẢI là duy nhất trong cùng một thương hiệu. PHẢI là văn bản mà con người có thể đọc được, nhưng không nhất thiết phải là văn bản mà người dùng cuối có thể xem. 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 thời gian hoạt động của sản phẩm.
SỐ SÊ-RI	Số sê-ri phần cứng, PHẢI có và duy nhất trên các thiết bị có cùng MẪU 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 người triển khai thiết bị chọn để phân biệt thêm 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ý điển hình của nền tảng Android: khoá phát hành, khoá nhà phát triển, khoá kiểm thử.
THỜI GIAN	Giá trị đại diện cho dấu thời gian của thời điểm bản dựng xảy ra.
LOẠI	Giá trị do người 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 thời gian chạy Android thông thường: user, userdebug hoặc eng.
NGƯỜI DÙNG	Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) đã tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
SECURITY_PATCH	Giá trị cho biết cấp bản vá bảo mật của một bản dựng. Chứng chỉ này PHẢI cho biết rằng bản dựng không gặp phải bất kỳ vấn đề nào được mô tả trong Bản tin công khai về bảo mật Android được chỉ định. Ngày phát hành PHẢI ở định dạng [YYYY-MM-DD], khớp với một chuỗi đã xác định được nêu trong Bản tin công khai về bảo mật Android hoặc trong Thông báo bảo mật của Android , ví dụ: "2015-11-01".
BASE_OS	Một giá trị đại diện cho tham số FINGERPRINT của bản dựng giống hệt với bản dựng này, ngoại trừ các bản vá được cung cấp trong Bản tin bảo mật công khai của Android. Phương thức này PHẢI báo cáo giá trị chính xác và nếu không có bản dựng nào như vậy, hãy báo cáo một chuỗi trống ("").

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

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

Ý định Android cho phép các thành phần ứng dụng yêu cầu chức năng từ các thành phần Android khác. Dự án ngược dòng Android bao gồm danh sách các ứng dụng được coi 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
GlobalSearch
Trình chạy
Âm nhạc
Cài đặt

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

Việc 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 các hoạt động mặc định cho các mẫu URI cụ thể (ví dụ: http://play.google.com) khi hoạt động mặc định cung cấp 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 bao gồm một cơ chế để các ứng dụng bên thứ ba khai báo hành vi liên kết ứng dụng mặc định có thẩm quyền cho một số loại ý định URI web nhất định. Khi các nội dung khai báo có thẩm quyền như vậy được xác định trong mẫu bộ lọc ý định của ứng dụng, các hoạt động triển khai thiết bị sẽ:

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

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ủ bất kỳ mẫu ý định mới hoặc ý định truyền tin nào bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khoá khác trong không gian tên android. hoặc com.android.. Người triển khai thiết bị KHÔNG ĐƯỢC đưa bất kỳ thành phần Android nào tuân theo bất kỳ mẫu ý định mới hoặc ý định truyền tin nào 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. Người 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 sử dụng được liệt kê trong mục 3.2.3.1 . Việc triển khai thiết bị CÓ THỂ bao gồm các mẫu ý định sử dụng không gian tên được liên kết rõ ràng và rõ ràng với tổ chức của riêng thiết bị. Quy định cấm này tương tự như quy định được 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 để truyền tin một số ý định nhất định nhằm thông báo cho ứng dụ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 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 ứng dụng mặc định, chẳng hạn như cho Màn hình chính hoặc SMS. Khi thích hợp, việc triển khai thiết bị PHẢI cung cấp một trình đơn cài đặt tương tự và tương thích với mẫu bộ lọc ý định và các phương thức API được mô tả trong tài liệu SDK như bên dưới.

Triển khai trên 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 việc 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 để hiển thị hộp thoại thay đổi ứng dụng SMS mặc định, nếu việc triển khai thiết bị báo cáo android.hardware.telephony.
PHẢI tuân thủ ý định android.settings.NFC_PAYMENT_SETTINGS để hiển thị trình đơn cài đặt ứng dụng mặc định cho tính năng Thanh toán không tiếp xúc, nếu việc 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 thị 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 việc triển khai thiết bị báo cáo android.hardware.telephony .
PHẢI tuân thủ ý định android.settings.ACTION_VOICE_INPUT_SETTINGS khi thiết bị hỗ trợ VoiceInteractionService và hiển thị trình đơn cài đặt ứng dụng mặc định để nhập và hỗ trợ bằng giọng nói.

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

Khả năng tương thích của mã gốc là một thách thức. Vì lý do này, những người triển khai thiết bị NÊN sử dụng các phương thức triển khai thư viện được liệt kê bên dưới từ Dự án nguồn mở Android cấp trên.

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

Mã byte Dalvik được quản lý có thể gọi vào mã gốc được cung cấp trong tệp .apk của ứng dụng dưới dạng tệp .so ELF được biên dịch cho cấu trúc phần cứng thiết bị thích hợp. Vì mã gốc phụ thuộc nhiều vào công nghệ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân của ứng dụng (ABI) trong Android NDK. Việc 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 việc triển khai thiết bị bao gồm việc hỗ trợ ABI Android, thì 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 với tệp nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách bên dưới.
PHẢI hỗ trợ ABI 32 bit tương đương nếu có bất kỳ ABI 64 bit nào được hỗ trợ.
PHẢI báo cáo chính xác Giao diện nhị phân ứng dụng (ABI) gốc mà thiết bị hỗ trợ, thông qua các tham số android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS và android.os.Build.SUPPORTED_64_BIT_ABIS, mỗi tham số là một danh sách ABI được phân tách bằng dấu phẩy, sắp xếp theo thứ tự từ ưu tiên nhất đến ít ưu tiên nhất.
BẮT BUỘC phải báo cáo (thông qua các tham số trên) chỉ những ABI được ghi nhận 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 BẮT BUỘC phải hỗ trợ tiện ích Advanced SIMD (còn gọi là NEON).
NÊN được tạo bằng mã nguồn và tệp tiêu đề có trong Dự án nguồn mở Android ngược dòng

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ợ thêm các ABI. Nếu việc 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ì việc triển khai đó KHÔNG ĐƯỢC báo cáo hỗ trợ cho bất kỳ ABI nào.

Các API mã gốc sau đây PHẢI có sẵn cho các ứng dụng có 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ợ 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.

Các thư viện gốc không có trong danh sách trên nhưng được triển khai và cung cấp trong AOSP dưới dạng thư viện hệ thống được đặt trước và KHÔNG ĐƯỢC hiển thị cho các ứng dụng bên thứ ba nhắm đến API cấp 24 trở lên.

Việc triển khai thiết bị CÓ THỂ thêm các thư viện không phải AOSP 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, nhưng 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 .

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

3.3.1.1. Thư viện đồ hoạ

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

Thư viện này PHẢI luôn cung cấp một thư viện gốc có tên là libvulkan.so để 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.

Cách 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 chính xác các 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 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 cung cấp bên ngoài gói ứng dụng hoặc cung cấp các cách khác để theo dõi hoặc chặn API Vulkan, trừ khi ứng dụng có thuộc tính android:debuggable=”true”.

Việc triển khai thiết bị, nếu không bao gồm tính năng hỗ trợ 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 Vulkan nào 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 không dùng một số thao tác CPU, bao gồm cả một số thao tác được dùng trong mã gốc hiện có. Trên các thiết bị ARM 64 bit, các thao tác không dùng nữa sau đây PHẢI vẫn hoạt động được với mã ARM gốc 32 bit, thông qua tính năng hỗ trợ CPU gốc hoặc thông qua tính năng mô phỏng phần mềm:

Hướng dẫn SWP và SWPB
Lệnh SETEND
Thao tác 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 đưa các dòng sau vào /proc/cpuinfo khi ứng dụng ARM 32 bit đọc:

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

Các 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 ứng dụng ARM 64 bit hoặc không phải ARM đọc.

3.4. Khả năng tương thích với web

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

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

Bạn PHẢI báo cáo tính năng nền tảng android.software.webview trên mọi thiết bị cung cấp cách triển khai đầy đủ API android.webkit.WebView và KHÔNG được báo cáo trên các thiết bị không triển khai đầy đủ API này. Việc triển khai Android Open Source sử dụng mã từ Dự án Chromium để triển khai android.webkit.WebView . Vì không thể phát triển một bộ kiểm thử toàn diện cho hệ thống hiển thị web, nên người triển khai thiết bị PHẢI sử dụng bản dựng thượng nguồn cụ thể của Chromium trong quá trình triển khai WebView. Cụ thể:

Việc 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 cho Android 7.1. Bản dựng này bao gồm một bộ sửa lỗi bảo mật và chức năng cụ thể cho WebView.
Chuỗi tác nhân người dùng do WebView báo cáo PHẢI có định dạng sau:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của android.os.Build.VERSION.RELEASE.
- 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.
- Việc triển khai thiết bị CÓ THỂ bỏ qua Di động trong chuỗi tác nhân người dùng.

Thành phần WebView PHẢI hỗ trợ nhiều tính năng HTML5 nhất có thể và nếu hỗ trợ tính năng thì PHẢI tuân thủ quy cách HTML5 .

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

Việc triển khai Android Television, 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 loại 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 để người dùng duyệt web thông thường.

Trình duyệt độc lập CÓ THỂ dựa trên một công nghệ trình duyệt khác ngoài WebKit. Tuy nhiên, ngay cả khi bạn sử dụng một ứng dụng Trình duyệt thay thế, 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 mục 3.4.1 .

Các hoạt động 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 (dù dựa trên ứng dụng Trình duyệt WebKit cấp trên hay ứng dụng thay thế của bên thứ ba) PHẢI hỗ trợ nhiều HTML5 nhất có thể. Ở mức tối thiểu, việc triển khai thiết bị PHẢI hỗ trợ từng API sau đây liên kết với HTML5:

Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ API webstorage HTML5/W3C và NÊN hỗ trợ API IndexedDB HTML5/W3C . Xin lưu ý rằng khi các tổ chức tiêu chuẩn phát triển web chuyển sang ưu tiên IndexedDB hơn là webstorage, IndexedDB dự kiến sẽ trở thành một thành phần bắt buộc trong phiên bản Android sau này.

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 ở thượng nguồn . Một số khía cạnh cụ thể về khả năng tương thích 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 vòng đời của một loại thành phần hệ thống cụ thể (chẳng hạn như Dịch vụ, Hoạt động, 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 thử tính tương thích (CTS) kiểm thử các phần quan trọng của nền tảng để xác định khả năng tương thích về hành vi, nhưng không phải tất cả. Bên 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 về không gian tên gói và lớp do ngôn ngữ lập trình Java xác định. Để đảm bảo khả năng tương thích với các ứng dụng bên thứ ba, người triển khai thiết bị KHÔNG ĐƯỢC thực hiện bất kỳ sửa đổi bị cấm nào (xem bên dưới) đối với các không gian tên gói sau:

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

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

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

"Thành phần 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 "@hide" như được sử dụng trong mã nguồn Android ngược dòng. Nói cách khác, người 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. Bên triển khai thiết bị CÓ THỂ thực hiện các sửa đổi chỉ dành cho nội bộ, nhưng KHÔNG ĐƯỢC quảng cáo hoặc tiết lộ các sửa đổi đó cho nhà phát triển.

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

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

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

3.7. Khả năng tương thích với thời gian chạy

Việc triển khai thiết bị PHẢI hỗ trợ định dạng Tệp thực thi Dalvik (DEX) đầy đủ và quy cách và ngữ nghĩa mã byte Dalvik . Người triển khai thiết bị PHẢI sử dụng ART, phương thức triển khai thượng nguồn tham chiếu của Định dạng thực thi Dalvik và hệ thống quản lý gói của phương thức triển khai tham chiếu.

Việc triển khai thiết bị PHẢI định cấu hình thời gian chạy Dalvik để phân bổ bộ nhớ theo nền tảng Android thượng nguồn và như được chỉ định trong bảng sau. (Xem phần 7.1.1 để biết định nghĩa về kích thước màn hình và mật độ màn hình.) Xin lưu ý rằng các giá trị bộ nhớ được chỉ định bên dưới được coi là giá trị tối thiểu và việc triển khai thiết bị CÓ THỂ phân bổ nhiều bộ nhớ hơn cho mỗi ứng dụng.

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

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

Android bao gồm một ứng dụng trình chạy (màn hình chính) và hỗ trợ các ứng dụng của bên thứ ba để thay thế trình chạy thiết bị (màn hình chính). Việc 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

Bạn không bắt buộc phải triển khai tiện ích cho tất cả các thiết bị Android, nhưng CHẮC CHẮN phải hỗ trợ tiện ích trên các thiết bị cầm tay Android.

Android xác định một loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị “AppWidget” cho người dùng cuối. Đây là một tính năng mà bạn NÊN hỗ trợ khi triển khai trên Thiết bị cầm tay. Các phương thức triển khai thiết bị hỗ trợ nhúng tiện ích trên màn hình chính PHẢI đáp ứng các yêu cầu sau và khai báo hỗ trợ tính năng nền tảng android.software.app_widgets.

Trình chạy thiết bị PHẢI có tính năng hỗ trợ tích hợp cho AppWidgets và hiển thị các tính năng 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.
Việc triển khai thiết bị PHẢI có khả năng hiển thị các tiện ích có kích thước 4 x 4 theo kích thước lưới tiêu chuẩn. Hãy xem Nguyên tắc thiết kế tiện ích ứng dụng trong tài liệu về SDK Android để biết thông tin chi tiết.
Việc triển khai thiết bị có 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 phần cứng, cụ thể là âm thanh, độ rung và ánh sáng. Việc triển khai thiết bị PHẢI hỗ trợ các thông báo sử dụng tính năng phần cứng, như mô tả trong tài liệu SDK và trong phạm vi có thể với phần cứng triển khai thiết bị. Ví dụ: nếu việc triển khai thiết bị bao gồm một bộ rung, thì thiết bị đó PHẢI triển khai chính xác các API rung. Nếu việc triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7 .

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 về kiểu biểu tượng của Thanh trạng thái/Thanh hệ thống. Trong trường hợp thiết bị Android Television , có thể không hiển thị thông báo. Nhà triển khai thiết bị CÓ THỂ cung cấp trải nghiệm người dùng thay thế cho thông báo so với trải nghiệm do cách triển khai Android Open Source tham chiếu cung cấp; 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ư trên.

Việc triển khai Android Automotive CÓ THỂ quản lý chế độ hiển thị và thời gian của 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 CarExtender khi ứ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 . Khung hiển thị tương tác cho thông báo liên tục.
Thông báo quan trọng . Chế độ xem tương tác mà người dùng có thể thực hiện hành động 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ị.

Khi hiển thị các thông báo như vậy, việc triển khai thiết bị Android PHẢI thực thi đúng cách thông báo Phong phú 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 (sau khi người dùng bật một cách rõ ràng) nhận bản sao của tất cả thông báo khi thông báo được đăng hoặc cập nhật. Việc 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à nhanh chóng đến tất cả các dịch vụ trình nghe đã cài đặt và do người dùng bật, bao gồm mọi siêu dữ liệu được đính kèm vào đối tượng Thông báo.

Việc triển khai thiết bị cầm tay PHẢI hỗ trợ các hành vi cập nhật, xoá, trả lời và gộp thông báo như mô tả trong phần này .

Ngoài ra, việc triển khai thiết bị cầm tay PHẢI cung cấp:

Khả năng điều khiển thông báo ngay trong ngăn thông báo.
Tính năng hỗ trợ hình ảnh để kích hoạt bảng điều khiển trong ngăn thông báo.
Khả năng CHẶN, TẮT TIẾNG và ĐẶT LẠI lựa chọn ưu tiên về thông báo từ một gói, cả trong bảng điều khiển nội tuyến cũng như trong ứng dụng cài đặt.

Tất cả 6 lớp con trực tiếp của Notification.Style class PHẢI được hỗ trợ như mô tả trong tài liệu SDK .

Các phương thức triển khai 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 phản hồi ý định ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Đối với các hoạt động triển khai với UI_MODE_TYPE_NORMAL , PHẢI là một hoạt động mà người dùng có thể cấp hoặc từ chối quyền truy cập của ứng dụng vào cấu hình chính sách DND.
BẮT BUỘC, khi việc triển khai thiết bị đã cung cấp cho người dùng một phương tiện để cấp hoặc từ chối quyền truy cập vào cấu hình chính sách Không làm phiền cho các ứng dụng bên thứ ba, hãy hiển thị Quy tắc DND tự động do các ứng dụng tạo cùng với các quy tắc do người dùng tạo và quy tắc được 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 một ứng dụng đã đặt bất kỳ cờ nào trong số SUPPRESSED_EFFECT_SCREEN_OFF hoặc SUPPRESSED_EFFECT_SCREEN_ON, thì ứng dụng đó PHẢI cho người dùng biết rằng các hiệu ứng hình ảnh bị tắt trong trình đơn cài đặt chế độ Không làm phiền.

3.8.4. Tìm kiếm

Android bao gồm các API cho phép nhà phát triển tích hợp tính năng tìm kiếm vào ứng dụng và hiển thị dữ liệu của ứng dụng trong tính năng tìm kiếm trên toàn hệ thống. Nhìn 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ị nội dung đề 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 chung trên toàn cầu.

Việc triển khai thiết bị Android PHẢI bao gồm tính năng tìm kiếm toàn cầu, một giao diện người dùng tìm kiếm duy nhất, dùng chung trên toàn hệ thống, có thể đưa ra đề xuất theo thời gian thực để phản hồi nội dung người dùng nhập. Việc 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 toàn cầu PHẢI triển khai các API cho phép ứng dụng bên thứ ba thêm nội dung đề xuất vào hộp tìm kiếm khi hộp tìm kiếm chạy ở chế độ tìm kiếm toàn cầu. 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, thì hành vi mặc định PHẢI là hiển thị kết quả và đề xuất của công cụ tìm kiếm trên web.

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

Android cũng bao gồm API Trợ lý để 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ị. Việc triển khai thiết bị hỗ trợ hành động Hỗ trợ PHẢI cho người dùng cuối biết rõ thời điểm chia sẻ ngữ cảnh bằng cách 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õ, 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.

Theo mặc định, chỉ báo này CÓ THỂ bị tắt đối với các ứng dụng được cài đặt sẵn sử dụng API Assist và VoiceInteractionService nếu đáp ứng tất cả các yêu cầu sau:

Ứng dụng được cài đặt sẵn PHẢI yêu cầu chỉ chia sẻ ngữ cảnh khi người dùng gọi ứng dụng bằng một trong những phương thức sau và ứng dụng đang chạy ở nền trước:
- lệnh gọi cụm từ kích hoạt
- nhập phím/nút/cử chỉ điều hướng ASSIST
Việc triển khai thiết bị PHẢI cung cấp một khả năng để bật chỉ báo, cách (trình đơn cài đặt ứng dụng trợ lý và phương thức nhập bằng giọng nói mặc định) mục 3.2.3.5 ít hơn hai thao tác điều hướng .

3.8.5. Thông báo ngắn

Các ứng dụng có thể sử dụng API "Toast" để hiển thị các chuỗi ngắn không phải phương thức cho người dùng cuối và các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn. Việc triển khai thiết bị PHẢI hiển thị thông báo ngắn từ các ứng dụng cho người dùng cuối theo một cách dễ thấy.

3.8.6. Giao diện

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

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

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

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

Android hỗ trợ giao diện biến thể với các thanh hệ thống mờ, 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à thanh đ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, điều quan trọng là bạn phải duy trì kiểu biểu tượng thanh trạng thái trên nhiều thiết bị triển khai. Do đó, việc triển khai 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 đang 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, việc triển khai 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 một loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị 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, mẫu hoặc hình ảnh tương tự có khả năng nhập hạn chế, hiển thị dưới dạng hình nền, phía sau 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 một cách đáng tin cậy nếu có thể chạy tất cả hình nền động, không có giới hạn về chức năng, ở tốc độ khung hình hợp lý mà không ảnh hưởng bất lợi đến các ứng dụng khác. Nếu các giới hạn về phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, hoạt động không đúng cách, tiêu thụ quá nhiều CPU hoặc pin hoặc chạy ở tốc độ khung hình thấp không chấp nhận được, thì phần cứng đó được coi là không thể chạy hình nền động. Ví dụ: một số hình nền động có thể sử dụng ngữ cảnh OpenGL 2.0 hoặc 3.x để hiển thị nội dung của chúng. Hình nền động sẽ không chạy ổn định trên phần cứng không hỗ trợ nhiều ngữ cảnh OpenGL vì việc sử dụng ngữ cảnh OpenGL của hình nền động có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.

Các phương thức triển khai thiết bị có thể chạy hình nền động một cách đáng tin cậy như mô tả ở trên PHẢI triển khai hình nền động và 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ì khoá đ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 việc triển khai Android Watch và Android Automotive, đồng thời NÊN triển khai đối với các thiết bị Android Television. Vẫn NÊN có một phương thức để chuyển đổi giữa các hoạt động trên các hoạt động 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 và tác vụ được truy cập gần đây bằng hình thu nhỏ của trạng thái đồ hoạ của ứng dụng tại thời điểm người dùng rời khỏi ứng dụng gần đây nhất. Việc triển khai thiết bị bao gồm cả phím điều hướng chức năng gần đây như được nêu chi tiết trong phần 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 thiểu 20 hoạt động hiển thị.
PHẢI hiển thị ít nhất tiêu đề của 4 hoạt động cùng một 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.
NÊN hiển thị màu làm nổi bật, biểu tượng, tiêu đề màn hình trong phần gần đây.
NÊN hiển thị một đối tượng đóng ("x") nhưng CÓ THỂ trì hoãn việc này cho đến khi người dùng tương tác với màn hình.
NÊN triển khai một lối tắt để dễ dàng chuyển sang hoạt động trước đó
CÓ THỂ hiển thị các nội dung 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 thao tác chuyển đổi nhanh giữa hai ứng dụng được sử dụng gần đây nhất, khi nhấn đúp vào phím chức năng gần đây.
NÊN kích hoạt chế độ nhiều cửa sổ chia đôi màn hình (nếu được hỗ trợ) khi nhấn và giữ phím chức năng gần đây.

Bạn NÊN sử dụng giao diện người dùng Android ngược dòng (hoặc giao diện tương tự dựa trên hình thu nhỏ) cho màn hình tổng quan khi triển khai thiết bị.

3.8.9. Quản lý đầu vào

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

Các hoạt động triển khai thiết bị khai báo tính năng android.software.input_methods PHẢI cung cấp 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. Việc triển khai thiết bị PHẢI hiển thị giao diện cài đặt để phản hồi ý đị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 nữa từ Android 5.0, thay vào đó là Mẫu thông báo nội dung nghe nhìn cho phép các ứng dụng đa phương tiện tích hợp với các nút điều khiển phát hiển thị trên màn hình khoá. Các hoạt động triển khai thiết bị hỗ trợ màn hình khoá (trừ khi 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 đa phương tiện.

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

Android hỗ trợ trình bảo vệ màn hình tương tác , trước đây gọi là Dreams. Trình bảo vệ màn hình cho phép người dùng tương tác với các ứng dụng khi thiết bị được kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế cắm trên bàn. Thiết bị Android Watch CÓ THỂ triển khai trình bảo vệ màn hình, nhưng các loại triển khai thiết bị khác PHẢI 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 một thiết bị có cảm biến phần cứng (ví dụ: GPS) có thể cung cấp toạ độ, các chế độ vị trí PHẢI xuất hiện trong trình đơn Vị trí trong phần Cài đặt.

3.8.13. Unicode và phông chữ

Android hỗ trợ các ký tự biểu tượng cảm xúc được xác định trong Unicode 9.0 . Tất cả các phương thức 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 ở dạng ký tự màu và khi triển khai thiết bị Android có IME, thiết bị đó PHẢI cung cấp phương thức nhập cho người dùng đối với các ký tự biểu tượng cảm xúc này.

Các thiết bị cầm tay Android PHẢI hỗ trợ màu da và nhiều biểu tượng cảm xúc theo gia đình như được chỉ định trong Báo cáo kỹ thuật Unicode số 51 .

Android hỗ trợ phông chữ Roboto 2 với nhiều độ đậm – sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light – tất cả các phông chữ này PHẢI được đưa vào cho các ngôn ngữ có trên thiết bị và bao gồm đầy đủ Unicode 7.0 cho tiếng Latinh, tiếng Hy Lạp và tiếng Cyrillic, bao gồm cả các phạm vi Latinh mở rộng A, B, C và D, cũng như tất cả các ký tự trong khối ký hiệu tiền tệ của Unicode 7.0.

3.8.14. Nhiều cửa sổ

Việc 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, nhưng nếu có khả năng hiển thị nhiều hoạt động cùng lúc, thì thiết bị PHẢI triển khai(các) chế độ nhiều cửa sổ đó theo hành vi của ứng dụng và API được mô tả trong tài liệu hỗ trợ chế độ nhiều cửa sổ của SDK Android và đáp ứng các yêu cầu sau:

Ứ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, một cách rõ ràng thông qua thuộc tính android:resizeableActivity hoặc ngầm ẩn bằng cách có targetSdkVersion > 24. Ứng dụng đặt thuộc tính này thành false một cách rõ ràng trong tệp kê khai KHÔNG được chạy ở chế độ nhiều cửa sổ. Bạn có thể chạy các ứng dụng không đặt thuộc tính trong tệp kê khai (targetSdkVersion < 24) ở 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ổ.
Việc 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 tuỳ ý nếu cả chiều cao và chiều rộng màn hình đều nhỏ hơn 440 dp.
Việc triển khai thiết bị có kích thước màn hình xlarge PHẢI hỗ trợ chế độ hình dạng tuỳ ý.
Việc triển khai thiết bị Android Television PHẢI hỗ trợ chế độ nhiều cửa sổ hình trong hình (PIP) và đặt chế độ nhiều cửa sổ PIP ở góc trên cùng bên phải khi PIP đang BẬT.
Việc triển khai thiết bị có hỗ trợ chế độ nhiều cửa sổ 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 sử dụng phím KeyEvent.KEYCODE_WINDOW để điều khiển cửa sổ PIP; nếu không, phím này 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 xoá từ xa thông qua Android Device Administration API ]. Việc triển khai thiết bị PHẢI cung cấp cách triển khai lớp DevicePolicyManager. Các hoạt động 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 quá trình triển khai thiết bị khai báo tính năng android.software.device_admin, thì quá trình đó 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 Ứng dụng chính sách thiết bị (DPC) như được chỉ định dưới đây:

Khi quá trình triển khai thiết bị chưa định cấu hình dữ liệu người dùng, quá trình này 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) thông qua cờ tính năng android.hardware.nfc và nhận được thông báo NFC chứa bản ghi có loại MIME 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 này sẽ:
- 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 của chủ sở hữu thiết bị nữa.

Việc triển khai thiết bị CÓ THỂ có một ứng dụng được cài đặt sẵn 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ị nếu không 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ẮT BUỘC 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 .

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

Việc triển khai thiết bị PHẢI cung cấp các chức năng 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 nào Trình điều khiển chính sách thiết bị (DPC) đã tắt một chức năng hệ thống cụ thể:

Một biểu tượng nhất quán hoặc các tính năng hỗ trợ người dùng khác (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ế.
Thông báo giải thích ngắn gọn do Quản trị viên thiết bị cung cấp thông qua setShortSupportMessage .
Biểu tượng của ứng dụng DPC.

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

Thiết bị có thể sử dụng hồ sơ được quản lý là những 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 mục 7.6.1 ).
Phân bổ bộ nhớ trong (không thể tháo rời) làm bộ nhớ dùng chung (xem mục 7.6.2 ).

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

3.10. Hỗ trợ tiếp cận

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

Việc triển khai thiết bị bao gồm các yêu cầu sau:

Việc triển khai Android Automotive PHẢI cung cấp cách 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 hoạt động triển khai thiết bị (ngoại trừ Android Automotive) PHẢI triển khai khung hỗ trợ tiếp cận của Android nhất quán với hoạt động triển khai Android mặc định.
Việc triển khai thiết bị (ngoại trừ Android Automotive) PHẢI hỗ trợ việc triển khai dịch vụ hỗ trợ tiếp cận của bên thứ ba thông qua API android.accessibilityservice .
Các hoạt động triển khai thiết bị (ngoại trừ Android Automotive) PHẢI tạo AccessibilityEvents và phân phối các sự kiện này cho tất cả các hoạt động triển khai AccessibilityService đã đăng ký theo cách nhất quán với hoạt động triển khai Android mặc định
Việc triển khai thiết bị (ngoại trừ các thiết bị Android Automotive và Android Watch không có đầu ra âm thanh) PHẢI cung cấp 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 để phản hồi ý định android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Bạn NÊN triển khai các dịch vụ hỗ trợ tiếp cận trên thiết bị Android có đầu ra âm thanh để cung cấp các dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với các dịch vụ hỗ trợ tiếp cận 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 PHẢI cung cấp việc triển khai dịch vụ hỗ trợ tiếp cận trên thiết bị có chức năng tương đương hoặc vượt trội so với 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 ban đầu để người dùng bật các dịch vụ hỗ trợ tiếp cận có liên quan, cũng như các tuỳ chọn để điều chỉnh cỡ chữ, kích thước màn hình và cử chỉ phóng to.

** Đối với 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ó dịch vụ hỗ trợ tiếp cận được tải trước, thì dịch vụ đó PHẢI là ứng dụng {directBootAware} nhận biết được chế độ Khởi động trực tiếp nếu thiết bị có bộ nhớ được mã hoá bằng phương thức Mã hoá dựa trên tệp (FBE).

3.11. Chuyển văn bản sang lời nói

Android bao gồm các API cho phép ứng dụng sử dụng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ triển khai các dịch vụ TTS. Các hoạt động 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 này liên quan đến khung TTS của Android .

Cách triển khai Android Automotive:

PHẢI hỗ trợ các 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ợ, đối tác PHẢI cung cấp giao diện mà người dùng có thể truy cập để chọn công cụ TTS để sử dụng ở cấp hệ thống.

Tất cả các phương thức triển khai thiết bị khác:

PHẢI hỗ trợ các API khung TTS của Android và NÊN bao gồm một công cụ TTS hỗ trợ các ngôn ngữ có trên thiết bị. Xin lưu ý rằng phần mềm nguồn mở Android thượng nguồn bao gồm việc triển khai công cụ TTS đầ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 công cụ TTS để sử dụng ở cấp hệ thống.

3.12. Khung đầu vào TV

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

Các phương thức triển khai 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 hoạt động triển khai thiết bị khai báo hỗ trợ Truyền hình trực tuyến đều PHẢI cài đặt ứng dụng TV (Ứng dụng TV). Dự án nguồn mở Android cung cấp cách triển khai Ứng dụng TV.

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

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

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

Việc triển khai thiết bị Android Television PHẢI hiển thị một lớp phủ tương tác và cung cấp thông tin, trong đó PHẢI có 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ả các đầu vào đã cài đặt và đầu vào của bên thứ ba.
EPG CÓ THỂ phân tách hình ảnh giữa các đầu vào đã cài đặt và đầu vào của bên thứ ba.
BạN NÊN hiển thị các đầ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 trên EPG. EPG KHÔNG ĐƯỢC hiển thị các phương thức nhập của bên thứ ba cách các phương thức nhập đã cài đặt trên EPG nhiều hơn một thao tác điều hướng.
Khi thay đổi kênh, hoạt động 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 đây thông qua các phím D-pad, Quay lại và Trang chủ trên(các) thiết bị đầu vào của thiết bị Android Television (tức là đ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
Mở EPG
Định cấu hình và điều chỉnh cho phù hợp với dữ liệu đầu vào dựa trên TIF của bên thứ ba
Mở trình đơn Cài đặt

Ứng dụng TV PHẢI truyền các sự kiện chính đến đầu vào HDMI thông qua CEC.

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

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

3.12.1.4. Chuyển đổi thời gian

Việc triển khai thiết bị Android Television PHẢI hỗ trợ tính năng tua lại, cho phép người dùng tạm dừng và tiếp tục nội dung phát trực tiếp. Việc 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ó tính năng chuyển đổi thời gian cho chương trình đó .

3.12.1.5. Ghi lại chương trình truyền hình

Bạn NÊN triển khai tính năng ghi hình TV trên thiết bị Android Television. Nếu đầu vào TV hỗ trợ tính năng ghi, thì EPG CÓ THỂ cung cấp cách ghi một chương trình nếu việc ghi chương trình đó không bị cấm . Việc 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

Việc 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 khẩn cấp.

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 cùng với 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ì thành phần đó:

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 phần Cài đặt nhanh.
KHÔNG ĐƯỢC tự động thêm thẻ thông tin từ ứng dụng bên thứ ba trực tiếp vào phần Cài đặt nhanh.
PHẢI hiển thị tất cả thẻ thông tin do người dùng thêm từ các ứng dụng bên thứ ba cùng với thẻ thông tin cài đặt nhanh do hệ thống cung cấp.

3.14. API giao diện người dùng của xe

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

Mọi hoạt động triển khai thiết bị khai báo hỗ trợ ô tô đều PHẢI bao gồm một khung giao diện người dùng để hỗ trợ các ứng dụng bên thứ ba sử dụng API 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 sau:

PHẢI hiển thị biểu tượng MediaItem và biểu tượng thông báo không bị thay đổi.
PHẢI hiển thị các mục đó như mô tả của MediaSession, ví dụ: siêu dữ liệu, biểu tượng, hình ảnh.
PHẢI hiển thị tiêu đề ứ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 của tính năng đóng gói ứng dụng

Việc 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ị PHẢI 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ợ việc xác minh tệp ".apk" bằng Lược đồ chữ ký APK phiên bản 2 và kỹ thuật 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 theo cách ngăn các tệp đó cài đặt và chạy chính xác trên các thiết bị tương thích khác.

Việc triển khai thiết bị KHÔNG ĐƯỢC cho phép các ứng dụng khác ngoài "trình cài đặt bản ghi" hiện tại của gói gỡ cài đặt ứng dụng một cách thầm lặng mà không có bất kỳ lời nhắc nào, như được ghi lại trong SDK cho quyền DELETE_PACKAGE. Các trường hợp ngoại lệ duy nhất là ứng dụng trình xác minh gói hệ thống xử lý ý định PACKAGE_NEEDS_VERIFICATION và ứng dụng trình quản lý bộ nhớ xử lý ý định ACTION_MANAGE_STORAGE.

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 nghe nhì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 về SDK Android, ngoại trừ những 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 dưới đây và được báo cáo thông qua MediaCodecList .
CŨNG PHẢI có thể giải mã tất cả hồ sơ được báo cáo trong CamcorderProfile
PHẢI có thể giải mã tất cả định dạng mà nó có thể mã hoá. Điều này bao gồm tất cả các luồng bit mà bộ mã hoá tạo ra.

Bộ mã hoá và giải mã PHẢI hướng đến độ trễ bộ mã hoá và giải mã tối thiểu, nói cách khác, bộ mã hoá và giải mã –

KHÔNG ĐƯỢC sử dụng và lưu trữ vùng đệm đầu vào, chỉ trả về vùng đệm đầu vào sau khi xử lý
KHÔNG ĐƯỢC giữ lại vùng đệm đã giải mã lâu hơn thời gian quy định theo tiêu chuẩn (ví dụ: SPS).
KHÔNG NÊN 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ả bộ mã hoá và giải mã được liệt kê trong bảng bên dưới đều được cung cấp dưới dạng phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên của Dự án nguồn mở Android.

Xin lưu ý rằng cả Google và Liên minh điện thoại mở đều không đưa ra tuyên bố nào 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 nên lưu ý rằng việc triển khai mã này, bao gồm cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế của các chủ sở hữu bằng sáng chế có liên quan.

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

Định dạng/Bộ mã hoá và giải mã	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Các loại tệp/Định dạng vùng chứa được hỗ trợ
Hồ sơ MPEG-4 AAC (AAC LC)	BẮT BUỘC ¹	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 ² với tốc độ lấy mẫu tiêu chuẩn từ 8 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC thô ADTS (.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 thể tua, Android 3.0 trở lên)
Hồ sơ MPEG-4 HE AAC (AAC+)	BẮT BUỘC ¹ (Android 4.1 trở lên)	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 ² với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
Hồ sơ MPEG-4 HE AACv2 (AAC+ nâng cao)		BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1 ² với tốc độ lấy mẫu tiê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 đơn âm/âm thanh nổi 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 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)
AMR-WB	BẮT BUỘC ³	BẮT BUỘC ³	9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 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 NÊN dùng tốc độ lấy mẫu lên đến 44,1 kHz trên các thiết bị có đầu ra 44,1 kHz, vì bộ lấy mẫu giảm từ 48 xuống 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 kỹ thuật tạo nhiễu cho 24 bit.	Chỉ FLAC (.flac)
MP3		BẮT BUỘC	Âm thanh đơn kênh/âm thanh nổi 8-320 Kb/giây không đổi (CBR) hoặc tốc độ bit biến thiên (VBR)	MP3 (.mp3)
MIDI		BẮT BUỘC	MIDI Loại 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF dành cho thiết bị di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody	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/WAVE	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 của phần cứng). Thiết bị PHẢI hỗ trợ tốc độ lấy mẫu để ghi âm PCM thô ở tần số 8000, 11025, 16000 và 44100 Hz.	WAVE (.wav)
Opus		BẮT BUỘC (Android 5.0 trở lên)		Matroska (.mkv), Ogg(.ogg)

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

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

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

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

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ả các hoạt động triển khai thiết bị Android Watch.

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

Định dạng/Bộ mã hoá và giải mã	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Các loại tệp/Định dạng vùng chứa được hỗ trợ
JPEG	BẮT BUỘC	BẮT BUỘC	Cơ sở + lũy tiến	JPEG (.jpg)
GIF		BẮT BUỘC		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ợ hồ sơ HDR PHẢI hỗ trợ việc phân tích cú pháp và xử lý siêu dữ liệu tĩnh HDR.
Nếu bộ mã hoá và giải mã nội dung nghe nhì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 đến 60 khung hình và hoạt động chính xác trong vòng 20% khoảng thời gian làm mới đã định cấu hình.
Bộ mã hoá và giải mã video PHẢI hỗ trợ kích thước vùng đệm byte đầu ra và đầu vào phù hợp với khung hình nén và không nén lớn nhất có thể theo 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à giải mã video PHẢI hỗ trợ định dạng màu linh hoạt YUV420 (COLOR_FormatYUV420Flexible).

Định dạng/Bộ mã hoá và giải mã	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	Các 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 thông tin chi tiết	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, chỉ âm thanh AAC, không thể tua, Android 3.0 trở lên)
H.265 HEVC		BẮT BUỘC ⁵	Xem mục 5.3 để biết thông tin chi tiết	MPEG-4 (.mp4)
MPEG-2		RẤT NÊN DÙNG ⁶	Cấu hình chính	MPEG2-TS
MPEG-4 SP		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 thông tin chi tiết	WebM (.webm) Matroska (.mkv, Android 4.0 trở lên) ⁴
VP9		BẮT BUỘC ² (Android 4.4 trở lên)	Xem mục 5.3 để biết thông tin chi tiết	WebM (.webm) Matroska (.mkv, Android 4.0 trở lên) ⁴

1 Bắt buộc đối với các hoạt động triển khai thiết bị có 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 việc triển khai thiết bị, ngoại trừ thiết bị Android Watch.

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

4 Việc triển khai thiết bị PHẢI hỗ trợ ghi tệp Matroska WebM.

5 RẤT NÊN DÙNG đối với Android Automotive, không bắt buộc đối với Android Watch và bắt buộc đối với tất cả các loại thiết bị khác.

6 Chỉ áp dụng cho việc triển khai thiết bị Android Television.

5.2. Mã hoá video

Bạn không bắt buộc phải sử dụng bộ mã hoá và giải mã video để triển khai trên 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 linh động.
NÊN hỗ trợ tốc độ khung hình biến thiên, trong đó bộ mã hoá video NÊN xác định thời lượng khung hình tức thì dựa trên dấu thời gian của vùng đệm đầu vào và phân bổ bộ chứa bit dựa trên thời lượng khung hình đó.

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

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

Tốc độ bit này KHÔNG được vượt quá khoảng 15% tốc độ bit giữa các khoảng thời gian khung hình nội bộ (I-frame).
Tỷ lệ này KHÔNG được vượt quá ~100% so với tốc độ bit trong khoảng thời gian trượt là 1 giây.

5.2.1. H.263

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

5.2.2. H-264

Các cách 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, bạn 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 khối xếp lớn linh hoạt) và RS (Lát cắt dư thừa). Hơn nữa, để duy trì khả năng tương thích với các thiết bị Android khác, bạn KHÔNG NÊN sử dụng ASO, FMO và RS cho Hồ sơ cơ sở bằng bộ mã hoá.
PHẢI hỗ trợ các hồ sơ mã hoá video SD (Độ phân giải chuẩn) trong bảng sau.
PHẢI hỗ trợ Hồ sơ chính cấp 4.
PHẢI hỗ trợ các hồ sơ mã hoá video HD (Độ phân giải cao) như được chỉ định trong bảng sau.
Ngoài ra, bạn NÊN mã hoá video HD 1080p ở tốc độ 30 khung hình/giây cho các thiết bị Android TV.

	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 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	20 khung hình/giây	30 fps	30 fps	30 fps
Tốc độ bit của video	384 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

1 Khi phần cứng hỗ trợ, nhưng RẤT NÊN dùng cho các thiết bị Android Television.

5.2.3. VP8

Việc triển khai thiết bị Android có hỗ trợ bộ mã hoá và giải mã VP8 PHẢI hỗ trợ hồ sơ mã hoá video SD và NÊN hỗ trợ các hồ sơ mã hoá video HD (Độ phân giải 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 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps
Tốc độ bit của video	800 Kb/giây	2 Mb/giây	4 Mb/giây	10 Mb/giây

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

5.3. Giải mã video

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

5.3.1. MPEG-2

Việc triển khai thiết bị Android có bộ giải mã MPEG-2 phải hỗ trợ Cấp cao của hồ sơ chính.

5.3.2. H.263

Việc 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

Việc triển khai thiết bị Android có bộ giải mã MPEG-4 PHẢI hỗ trợ Hồ sơ đơn giản cấp 3.

5.3.4. H.264

Cách 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 khối xếp linh hoạt) và RS (Lát cắt dư thừa).
PHẢI có khả năng giải mã video có hồ sơ SD (Độ phân giải chuẩn) được liệt kê trong bảng sau và được mã hoá bằng Hồ sơ cơ sở và Hồ sơ chính cấp 3.1 (bao gồm cả 720p30).
PHẢI có khả năng giải mã video theo hồ sơ HD (Độ phân giải cao) như được chỉ định trong bảng sau.
Ngoài ra, các thiết bị Android Television –
- PHẢI hỗ trợ Hồ sơ cấp cao 4.2 và hồ sơ giải mã HD 1080p60.
- PHẢI có khả năng giải mã video bằng cả hai hồ sơ HD như được chỉ định trong bảng sau và được mã hoá bằng Hồ sơ cơ sở, Hồ sơ chính hoặc Hồ sơ cao cấp 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 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình video	30 fps	30 fps	60 khung hình/giây	30 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

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

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

5.3.5. H.265 (HEVC)

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ấu hình chính cấp 3 cấp chính và cấu hình giải mã video SD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các hồ sơ giải mã HD như được chỉ định trong bảng sau nếu có bộ giải mã phần cứng.
Ngoài ra, các thiết bị Android Television:
PHẢI hỗ trợ hồ sơ giải mã HD 720p.
BẠN NÊN HỖ TRỢ hồ sơ giải mã HD 1080p. Nếu hồ sơ giải mã HD 1080p được hỗ trợ, thì hồ sơ đó PHẢI hỗ trợ Cấp chính của Hồ sơ chính cấp 4.1.
PHẢI hỗ trợ hồ sơ giải mã UHD. Nếu hồ sơ giải mã UHD được hỗ trợ, thì bộ mã hoá và giải mã PHẢI hỗ trợ hồ sơ 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 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 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 Television có giải mã phần cứng H.265.

5.3.6. VP8

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

PHẢI hỗ trợ các hồ sơ giải mã SD trong bảng sau.
NÊN hỗ trợ các hồ sơ giải mã HD trong bảng sau.
Thiết bị Android Television PHẢI hỗ trợ hồ sơ 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 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Tốc độ khung hình 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

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

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

5.3.7. VP9

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

PHẢI hỗ trợ các hồ sơ giải mã video SD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các cấu hình giải mã HD như được chỉ định trong bảng sau.
PHẢI hỗ trợ các hồ sơ giải mã HD như được chỉ định trong bảng sau, nếu có bộ giải mã phần cứng.
Ngoài ra, các thiết bị Android Television:
- PHẢI hỗ trợ hồ sơ giải mã HD 720p.
- BẠN NÊN HỖ TRỢ hồ sơ giải mã HD 1080p.
- PHẢI hỗ trợ hồ sơ giải mã UHD. Nếu hồ sơ giải mã video UHD được hỗ trợ, thì hồ sơ đó PHẢI hỗ trợ độ sâu màu 8 bit và NÊN hỗ trợ Hồ sơ VP9 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 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 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 Television 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 dự kiến sẽ thay đổi các yêu cầu này thành PHẢI. Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này, nếu không, chúng sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

5.4.1. Quay âm thanh thô

Các hoạt động triển khai thiết bị khai báo android.hardware.microphone PHẢI cho phép ghi lại 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 lấy mẫu lên, và mọi hoạt động lấy mẫu xuống PHẢI bao gồm một bộ lọc khử răng cưa thích hợp.

Các hoạt động triển khai thiết bị khai báo android.hardware.microphone PHẢI cho phép ghi lại 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 hỗ trợ tính năng quay video ở các tốc độ lấy mẫu trên, thì bạn PHẢI quay video mà không cần lấy mẫu lên ở tỷ lệ cao hơn 16000:22050 hoặc 44100:48000. Mọi hoạt động lấy mẫu lên hoặc lấy mẫu xuống đều PHẢI có bộ lọc khử răng cưa thích hợp.

5.4.2. Ghi âm để nhận dạng giọng nói

Nguồn âm thanh android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION PHẢI hỗ trợ tính năng quay video ở một trong các tốc độ lấy mẫu là 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 điểm biên độ gần như bằng phẳng so với tần số: cụ thể là ±3 dB, từ 100 Hz đến 4000 Hz.
Bạn PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn có mức công suất âm thanh (SPL) 90 dB ở tần số 1000 Hz tạo ra RMS là 2500 đối với các mẫu 16 bit.
Cấp độ biên độ PCM PHẢI theo dõi tuyến tính các thay đổi về SPL đầu vào trong phạm vi ít nhất là 30 dB từ -18 dB đến +12 dB so với 90 dB SPL tại micrô.
Độ méo hài tổng cộng PHẢI nhỏ hơn 1% đối với tần số 1 kHz ở mức đầu vào SPL 90 dB tại micrô.
BẠN PHẢI tắt tính năng xử lý giảm tiếng ồn (nếu có).
BẠN PHẢI tắt tính năng tự động điều khiển độ lợi (nếu có).

Nếu nền tảng hỗ trợ các công nghệ loại bỏ tạp âm được điều chỉnh để nhận dạng lời nói, thì hiệu ứng PHẢI được kiểm soát từ API android.media.audiofx.NoiseSuppressor. Hơn nữa, trường UUID cho nội dung mô tả hiệu ứng của bộ khử tiếng ồn PHẢI xác định duy nhất từng phương thức triển khai công nghệ khử tiếng ồn.

5.4.3. Ghi lại để định tuyến lại quá trình phát

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 cách nguồn âm thanh REMOTE_SUBMIX để khi một ứng dụng sử dụng API android.media.AudioRecord để ghi âm từ nguồn âm thanh này, ứng dụng đó có thể ghi lại âm thanh kết hợp của tất cả các luồng âm thanh ngoại trừ những luồng sau:

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

5.5. Phát âm thanh

Các hoạt động triển khai thiết bị khai báo android.hardware.audio.output PHẢI tuân thủ các yêu cầu trong phần 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 API cho hiệu ứng âm thanh để triển khai trên thiết bị. Các phương thức triển khai thiết bị khai báo tính năng android.hardware.audio.output:

PHẢI hỗ trợ việc triển khai EFFECT_TYPE_EQUALIZER và EFFECT_TYPE_LOUDNESS_ENHANCER có thể kiểm soát được thông qua các lớp con AudioEffect Equalizer, LoudnessEnhancer.
PHẢI hỗ trợ việc triển khai API trình trực quan hoá, có thể kiểm soát thông qua lớp Trình trực quan hoá.
NÊN hỗ trợ các phương thức triển khai EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB và EFFECT_TYPE_VIRTUALIZER có thể kiểm soát thông qua các lớp con AudioEffect BassBoost, EnvironmentalReverb, PresetReverb và Virtualizer.

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

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

Việc triển khai thiết bị Android Automotive PHẢI cho phép điều chỉnh âm lượng riêng cho từng luồng âm thanh bằng cách sử dụng loại nội dung hoặc mức sử dụng do AudioAttributes xác định và mức sử dụng âm thanh trên ô tô đượ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 lớp ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng âm thanh theo thời gian thực.

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

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

Bạn NÊN đáp ứng hoặc vượt quá các yêu cầu sau đây về đầu ra âm thanh đối với các phương thức triển khai thiết bị khai báo android.hardware.audio.output:

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

Nếu việc triển khai thiết bị đáp ứng các yêu cầu của phần này sau khi hiệu chuẩn ban đầu khi sử dụng API hàng đợi bộ đệm PCM OpenSL ES, đối với độ trễ đầu ra liên tục và độ trễ đầu ra nguội trên ít nhất một thiết bị đầu ra âm thanh được hỗ trợ, thì 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 thông qua lớp android.content.pm.PackageManager. Ngược lại, nếu việc triển khai thiết bị không đáp ứng các yêu cầu này, thì thiết bị KHÔNG ĐƯỢC báo cáo hỗ trợ âm thanh có độ trễ thấp.

Bạn NÊN triển khai các thiết bị có android.hardware.microphone để đáp ứng các yêu cầu sau đây về âm thanh đầu vào:

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

5.7. Giao thức mạng

Thiết bị PHẢI hỗ trợ các giao thức mạng nội dung nghe nhìn để phát âm thanh và video như được chỉ định trong tài liệu SDK Android. Cụ thể, thiết bị PHẢI hỗ trợ các giao thức mạng đa phương tiện sau:

Phát trực tuyến tăng dần qua HTTP(S)
Tất cả các bộ mã hoá và giải mã và định dạng vùng chứa 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 qua HTTP, Phiên bản 7
PHẢI hỗ trợ các định dạng phân đoạn nội dung đa phương tiện sau:

Định dạng phân đoạn	(Các) tài liệu tham khảo	Hỗ trợ bộ mã hoá và giải mã bắt buộc
Luồng truyền tải MPEG-2	ISO 13818	Bộ mã hoá và giải mã video: H264 AVC MPEG-4 SP MPEG-2 Xem mục 5.1.3 để biết thông tin 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 mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC.
AAC với khung ADTS và thẻ ID3	ISO 13818-7	Xem mục 5.1.1 để biết thông tin 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ài liệu tham khảo

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

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

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

Xem mục 5.1.3 để biết thông tin 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 mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC.

AAC với khung ADTS và thẻ ID3

ISO 13818-7

Xem mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC

WebVTT

RTSP (RTP, SDP)

HÀNG ĐẦU phải hỗ trợ hồ sơ video âm thanh RTP và các bộ mã hoá và giải mã liên quan sau. Đối với các trường hợp ngoại lệ, vui lòng xem chú thích cuối bảng trong mục 5.1 .

Tên hồ sơ	(Các) tài liệu tham khảo	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 thông tin chi tiết về H264 AVC
MP4A-LATM	RFC 6416	Xem mục 5.1.1 để biết thông tin chi tiết về AAC và các biến thể của AAC
H263-1998	RFC 3551 RFC 4629 RFC 2190	Xem mục 5.1.3 để biết thông tin chi tiết về H263
H263-2000	RFC 4629	Xem mục 5.1.3 để biết thông tin chi tiết về H263
AMR	RFC 4867	Xem phần 5.1.1 để biết thông tin chi tiết về AMR-NB
AMR-WB	RFC 4867	Xem phần 5.1.1 để biết thông tin chi tiết về AMR-WB
MP4V-ES	RFC 6416	Xem phần 5.1.3 để biết thông tin chi tiết về MPEG-4 SP
mpeg4-generic	RFC 3640	Xem mục 5.1.1 để biết thông tin 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ần Phát trực tuyến dựa trên HTTP để biết thông tin chi tiết

5.8. Secure Media

Các phương thức triển khai thiết bị hỗ trợ đầu ra video bảo mật và có khả năng hỗ trợ các nền tảng bảo mật PHẢI khai báo hỗ trợ Display.FLAG_SECURE. Các phương thức triển khai thiết bị khai báo hỗ trợ Display.FLAG_SECURE, nếu 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 một cơ chế mã hoá mạnh như HDCP 2.x trở lên đối với màn hình không dây Miracast. Tương tự, nếu hỗ trợ màn hình ngoài có dây, thì việc triển khai thiết bị PHẢI hỗ trợ HDCP 1.2 trở lên. Việc triển khai thiết bị Android Television PHẢI hỗ trợ HDCP 2.2 đối với các thiết bị hỗ trợ độ phân giải 4K và HDCP 1.4 trở lên đối với các độ phân giải thấp hơn. Việc triển khai nguồn mở Android ngược dòng bao gồm hỗ trợ cho 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ố cho nhạc cụ (MIDI)

Nếu việc triển khai thiết bị hỗ trợ việc truyền phần mềm MIDI giữa các ứng dụng (thiết bị MIDI ảo) và hỗ trợ MIDI qua tất cả các phương thức truyền phần cứng có khả năng MIDI sau đây mà thiết bị đó 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 tính năng hỗ trợ android.software.midi thông qua lớp android.content.pm.PackageManager.

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

Chế độ máy chủ USB (mục 7.7 USB)
Chế độ thiết bị ngoại vi USB (mục 7.7 USB)
MIDI qua Bluetooth LE đóng vai trò trung tâm (mục 7.4.3 Bluetooth)

Ngược lại, nếu việc triển khai thiết bị cung cấp khả năng 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ó khả năng MIDI cụ thể được liệt kê ở trên, nhưng không hỗ trợ MIDI qua phương thức truyền tải phần cứng đó, thì thiết bị KHÔNG ĐƯỢC báo cáo hỗ trợ tính năng android.software.midi.

5.10. Âm thanh chuyên nghiệp

Nếu việc triển khai thiết bị đáp ứng tất cả các yêu cầu sau, bạn NÊN báo cáo việc hỗ trợ 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 khả năng hỗ trợ tính năng android.hardware.audio.low_latency.
Độ trễ âm thanh trọn vòng liên tục, như được xác định trong mục 5.6 Độ trễ âm thanh, PHẢI là 20 mili giây trở xuống và NÊN 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 3, 5 mm 4 dây, thì độ trễ âm thanh liên tục theo cả hai chiều PHẢI dưới 20 mili giây trên đường dẫn giắc cắm âm thanh và NÊN dưới 10 mili giây trên đường dẫn giắc cắm âm thanh.
Việc 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, thì việc triển khai thiết bị PHẢI hỗ trợ đầu ra âm thanh nổi và 8 kênh ở độ sâu 20 bit hoặc 24 bit và 192 kHz mà không làm mất độ sâu bit hoặc lấy mẫu lại.
Việc triển khai thiết bị PHẢI báo cáo khả năng hỗ trợ tính năng android.software.midi.
Nếu thiết bị có giắc âm thanh 3,5 mm 4 dây, bạn NÊN tuân thủ phần Thông số kỹ thuật của thiết bị di động (giắc) trong Thông số kỹ thuật của tai nghe có dây (phiên bản 1.1).

BẠN PHẢI đáp ứng độ trễ và các yêu cầu về âm thanh USB bằng cách sử dụng API hàng đợi bộ đệm PCM OpenSL ES.

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

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

5.11. Chụp cho chưa 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 nguồn âm thanh 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 tệp này bằng SL_ANDROID_RECORDING_PRESET_UNPROCESSED cài đặt trước bản ghi .

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

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

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

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

Bạn NÊN đáp ứng nhiều yêu cầu nhất có thể đối với đường dẫn tín hiệu cho nguồn ghi âm chưa xử lý; tuy nhiên, thiết bị phải đáp ứng tất cả các yêu cầu này (như 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 của các công cụ và tuỳ chọn dành cho nhà phát triển

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

Việc triển khai thiết bị PHẢI hỗ trợ Bộ công cụ dành 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)
- Việc triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được ghi nhận trong SDK Android, bao gồm cả dumpsys .
- Theo mặc định, trình nền adb phía thiết bị 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 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ì thiết bị đó 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 hỗ trợ adb bảo mật. adb bảo mật cho phép adb trên các máy chủ đã xác thực đã biết. Việc triển khai thiết bị PHẢI hỗ trợ adb bảo mật.
Dalvik Debug Monitor Service (ddms)
- Việc triển khai thiết bị PHẢI hỗ trợ tất cả tính năng ddms như được ghi nhận trong SDK Android.
- Vì ddms sử dụng adb, nên tính năng hỗ trợ ddms PHẢI ở trạng thái không hoạt động theo mặc định, 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 Các hoạt động triển khai thiết bị PHẢI bao gồm khung Monkey và cung cấp khung này cho các ứng dụng sử dụng.
SysTrace
- Việc triển khai thiết bị PHẢI hỗ trợ công cụ systrace như được ghi nhận trong SDK Android. Theo mặc định, Systrace phải không hoạt động và PHẢI có một 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 ra các thiết bị Android bằng các công cụ SDK Android tiêu chuẩn mà không cần hỗ trợ bổ sung; tuy nhiên, các hệ thống 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 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 hoạt động triển khai thiết bị như được cung cấp trong SDK Android tiêu chuẩn, thì người 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. BẠN PHẢI cung cấp các trình điều khiển này cho Windows XP, Windows Vista, Windows 7, Windows 8 và Windows 10 ở cả phiên bản 32 bit và 64 bit.

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

Android hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Việc triển khai thiết bị PHẢI tuân thủ ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiển thị các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Việc 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 7 lần vào mục trình đơn Cài đặt > Giới thiệu về thiết bị > Số bản dựng. Việc 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 hoạt động 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 một cơ chế để bật Tuỳ chọn cho nhà phát triển nhất quán với hoạt động triển khai Android ngược dòng.

Việc triển khai Android Automotive CÓ THỂ hạn chế 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 di chuyển.

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

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

Vẫn PHẢI trình bày định nghĩa đầy đủ về lớp (như được SDK ghi lại) cho các API thành phần.
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 hợp lý.
Các phương thức API PHẢI trả về giá trị rỗng khi tài liệu SDK cho phép.
Phương thức API PHẢI trả về các phương thức triển khai không hoạt động của các lớp mà tài liệu SDK không cho phép giá trị rỗng.
Phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được tài liệu SDK ghi lại.

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 phải được triển khai dưới dạng không hoạt động hợp lý.

Việc 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 các phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager cho cùng một vân tay bản dựng.

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

Android có các cơ sở tự động điều chỉnh thành phần ứng dụng và bố cục giao diện người dùng cho phù hợp với thiết bị để đảm bảo rằng các ứng dụng bên thứ ba chạy tốt trên nhiều cấu hình 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 phần này được xác định 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 trên màn hình.
số điểm trên mỗi inch (dpi) . Số pixel được bao phủ bởi một khoảng không gian tuyến tính theo chiều ngang hoặc chiều dọc là 1 inch. Khi liệt kê các giá trị dpi, cả dpi theo chiều ngang và chiều dọc đều phải nằm trong phạm vi.
tỷ lệ khung hình . Tỷ lệ pixel của kích thước dài hơn so với kích thước ngắn hơn của màn hình. Ví dụ: màn hình 480x854 pixel sẽ là 854/480 = 1,779 hoặc gần bằng "16:9".
pixel không phụ thuộc vào mật độ (dp) . Đơn vị pixel ảo được chuẩn hoá cho màn hình 160 dpi, được tính như sau: pixels = dps * (density/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 (được mô tả 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 thiết bị (còn gọi là "bố cục màn hình") thông qua android.content.res.Configuration.screenLayout bằng SCREENLAYOUT_SIZE_MASK. Việc triển khai thiết bị PHẢI báo cáo đúng kích thước màn hình như được xác định trong tài liệu SDK Android và do nền tảng Android cấp trên xác định. Cụ thể, việc triển khai thiết bị PHẢI báo cáo chính xác kích thước màn hình theo các kích thước màn hình pixel không phụ thuộc vào mật độ (dp) logic 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ối thiểu 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ối thiểu là 640 dp x 480 dp.
Các thiết bị báo cáo kích thước màn hình "rất lớn" PHẢI có kích thước màn hình tối thiểu là 960 dp x 720 dp.

Ngoài ra:

Thiết bị Android Watch PHẢI có màn hình có kích thước đường chéo thực tế 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 tế 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 loại triển khai thiết bị Android khác, có màn hình tích hợp thực tế, PHẢI có màn hình có kích thước đường chéo vật lý ít nhất 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.

Ứng dụng có thể cho biết kích thước màn hình mà ứng dụng hỗ trợ thông qua thuộc tính <supports-screens> trong tệp AndroidManifest.xml. Việc triển khai thiết bị PHẢI tuân thủ chính xác khả năng hỗ trợ mà ứng dụng đã nêu cho màn hình nhỏ, bình thường, lớn và rất 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ó hạn chế đối với giá trị tỷ lệ khung hình màn hình của màn hình thực, nhưng tỷ lệ khung hình màn hình của nền tảng mà các ứng dụng bên thứ ba hiển thị và có thể bắt nguồn từ các giá trị được báo cáo thông 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 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ị nằm trong khoảng 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 tiêu chuẩn để giúp nhà phát triển ứng dụng nhắm đến tài nguyên ứng dụng. Theo mặc định, việc triển khai thiết bị CHỈ ĐƯỢC báo cáo một trong các mật độ khung Android logic sau đây thông qua API DENSITY_DEVICE_STABLE và giá trị này KHÔNG ĐƯỢC thay đổi bất cứ lúc nào; tuy nhiên, thiết bị CÓ THỂ báo cáo một mật độ tuỳ ý khác theo các thay đổi về cấu hình hiển thị do người dùng thực hiện (ví dụ: kích thước màn hình) được đặt sau khi khởi động ban đầu.

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

Việc 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ố học với mật độ thực tế 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 chuẩn gần nhất về mặt số học với mật độ thực tế 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 được hỗ trợ nhỏ nhất (chiều rộng 320 dp), thì việc triển khai thiết bị PHẢI báo cáo mật độ khung Android chuẩn thấp nhất tiếp theo.

Bạn NÊN cung cấp cho người dùng chế độ cài đặt để thay đổi kích thước màn hình khi triển khai thiết bị. Nếu có phương thức triển khai để thay đổi kích thước màn hình 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 như được chỉ định dưới đây:

Kích thước màn hình KHÔNG ĐƯỢC lớn hơn 1,5 lần mật độ gốc hoặc tạo kích thước màn hình tối thiểu hiệu quả nhỏ hơn 320 dp (tương đương với bộ hạn định tài nguyên sw320dp), tuỳ theo điều kiện nào đến trước.
Kích thước hiển thị KHÔNG ĐƯỢC 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 đây cho các tuỳ chọn Màn hình gốc (trong khi tuân thủ các giới hạn nêu trên)
Nhỏ: 0,85x
Mặc định: 1x (Tỷ lệ hiển thị gốc)
Lớn: 1,15x
Lớn hơn: 1,3 lần
Lớn nhất 1,45x

7.1.2. Chỉ số về Mạng Hiển thị

Việc triển khai thiết bị PHẢI báo cáo giá trị chính xác cho tất cả các chỉ số màn hình đượ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 nhúng hay màn hình bên ngoài được dùng làm màn hình mặc định.

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

Thiết bị PHẢI báo cáo hướng màn hình mà chúng 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 cố định theo hướng, chẳng hạn như TV hoặc máy tính xách tay, CHỈ NÊN báo cáo android.hardware.screen.landscape.

Các thiết bị báo cáo cả hai hướng màn hình PHẢI hỗ trợ hướng động theo ứng dụng cho 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ể. Việc 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ị, bất cứ khi nào được truy vấn thông qua android.content.res.Configuration.orientation, android.view.Display.getOrientation() hoặc các API khác.

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

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

Quá trình 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. Đó là:

Các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) PHẢI báo cáo khả năng hỗ trợ OpenGL ES 1.0 và OpenGL ES 2.0.
API OpenGL C/C++ gốc (API có sẵn cho ứng dụng thông qua libGLES_v1CM.so, libGLES_v2.so hoặc libEGL.so) PHẢI báo cáo khả năng hỗ trợ OpenGL ES 1.0 và OpenGL ES 2.0.
Các hoạt động triển khai thiết bị khai báo 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à hỗ trợ các API C/C++ gốc. Trên các phương thức triển khai thiết bị khai báo hỗ trợ OpenGL ES 3.0, 3.1 hoặc 3.2, libGLESv2.so 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 mở rộng OpenGL ES với các giao diện Java và hỗ trợ gốc cho chức năng đồ hoạ nâng cao như tạo hình đa giác và định dạng nén hoạ tiết ASTC. Việc triển khai 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ợ nếu không. Nếu toàn bộ gói tiện ích được hỗ trợ, thì 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, hoạt động triển khai thiết bị CÓ THỂ triển khai bất kỳ tiện ích OpenGL ES nào mong muốn. Tuy nhiên, việc triển khai thiết bị PHẢI báo cáo thông qua API gốc và được quản lý của OpenGL ES tất cả chuỗi tiện ích mà chúng hỗ trợ và ngược lại, KHÔNG ĐƯỢC báo cáo chuỗi tiện ích mà chúng không hỗ trợ.

Xin lưu ý rằng Android hỗ trợ các ứng dụng có thể tuỳ ý chỉ định rằng chúng yêu cầu các định dạng nén hoạ tiết OpenGL cụ thể. Các định dạng này thường tuỳ theo nhà cung cấp. Android không yêu cầu việc triển khai thiết bị phải triển khai bất kỳ định dạng nén kết cấu cụ thể nào. Tuy nhiên, các ứng dụng 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 chúng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp Ứng dụng, Hoạt động, Cửa sổ hoặc Khung hiển thị thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp.

Theo mặc định, việc triển khai thiết bị PHẢI bật tính năng tăng tốc phần cứng và PHẢI tắt tính năng tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách đặt android:hardwareAccelerated="false" hoặc tắt tính năng tăng tốc phần cứng trực tiếp thông qua API Khung hiển thị Android.

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

Android bao gồm một đối tượng TextureView cho phép nhà phát triển trực tiếp tích hợp các kết cấu OpenGL ES được tăng tốc phần cứng làm mục tiêu kết xuất trong hệ phân cấp giao diện người dùng. Việc 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 việc triển khai Android ngược dòng.

Android 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 để ghi hình ảnh vào video hay không. Việc 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 ở chế độ tương đương với kích thước màn hình "bình thường" (chiều rộng 320 dp) để mang lại lợi ích cho các ứng dụng cũ không được phát triển cho các phiên bản Android cũ trước khi có tính năng độc lập với kích thước màn hình.

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

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

Nền tảng Android bao gồm các API cho phép ứng dụng kết xuất đồ hoạ đa dạng thức cho màn hình. Thiết bị PHẢI hỗ trợ tất cả các API này theo định nghĩa 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ó thể kết xuất đồ hoạ màu 16 bit và NÊN hỗ trợ màn hình có thể kết xuất đồ hoạ màu 24 bit.
Thiết bị PHẢI hỗ trợ màn hình có khả năng kết xuất ảnh động.
Công nghệ màn hình được sử dụng PHẢI có tỷ lệ khung hình pixel (PAR) từ 0,9 đến 1,15. Tức là tỷ lệ khung hình bằng pixel PHẢI gần vuông (1, 0) với dung sai 10 đến 15%.

7.1.7. Màn hình phụ

Android hỗ trợ màn hình phụ để bật các tính năng chia sẻ nội dung nghe nhìn và API dành cho nhà phát triển để truy cập vào màn hình ngoài. Nếu một thiết bị hỗ trợ màn hình ngoài thông qua kết nối có dây, không dây hoặc kết nối màn hình bổ sung được nhúng, thì việc triển khai thiết bị PHẢI triển khai API trình quản lý hiển thị như 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 phần 7.2.2 đối với thao tác điều hướng không dùng thao tác chạm.

7.2.1. Bàn phím

Việc triển khai Android Watch và Android Automotive CÓ THỂ triển khai bàn phím mềm. Tất cả các phương thức triển khai thiết bị khác PHẢI triển khai bàn phím mềm và:

Triển khai trên thiết bị:

PHẢI hỗ trợ Khung quản lý phương thức nhập (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ư được nêu chi tiết tại http://developer.android.com .
PHẢI cung cấp ít nhất một phương thức 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 không hợp lý.
CÓ THỂ bao gồm các phương thức triển khai bàn phím mềm bổ sung.
CÓ THỂ có bàn phím phần cứng.
KHÔNG ĐƯỢC đưa bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard (QWERTY hoặc 12 phím).

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

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

Triển khai trên thiết bị:

CÓ THỂ bỏ qua tuỳ chọn điều hướng không chạm (bi xoay, d-pad hoặc con lăn) nếu thiết bị triển khai không phải là thiết bị Android Television.
PHẢI báo cáo giá trị chính xác cho android.content.res.Configuration.navigation .
PHẢI cung cấp một cơ chế giao diện người dùng thay thế hợp lý để 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 phương thức nhập điều hướng không chạm.

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

Yêu cầu về phạm vi cung cấp và chế độ hiển thị của các chức năng Trang chủ, Gần đây và 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 Trang chủ, Gần đây và Quay lại (tương ứng được liên kết với các sự kiện chính KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK) là thiết yếu đối với mô hình điều hướng Android và do đó:

Việc triển khai thiết bị cầm tay Android PHẢI cung cấp các chức năng Màn hình chính, Gần đây và Quay lại.
Việc triển khai thiết bị Android Television PHẢI cung cấp các chức năng Màn hình chính và Quay lại.
Việc triển khai thiết bị Android Watch PHẢI cung cấp cho người dùng chức năng Trang chủ và chức năng Quay lại, ngoại trừ khi ở 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ữ trên sự kiện phím KEYCODE_BACK và bỏ qua sự kiện này khi gửi đến ứng dụng trên nền trước.
Việc triển khai Android Automotive PHẢI cung cấp chức năng Trang chủ và CÓ THỂ cung cấp chức năng Quay lại và Gần đây.
Tất cả các loại triển khai thiết bị khác PHẢI cung cấp các chức năng Trang chủ và Quay lại.

Bạn CÓ THỂ triển khai các chức năng này 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Ể 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 cảm ứng, v.v. Android hỗ trợ cả hai phương thức triển khai. Tất cả các chức năng 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ó) 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 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 các 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ó) 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 hàm điều hướng khác ở chế độ toàn màn hình hoặc khi uiMode UI_MODE_TYPE_MASK được đặt thành UI_MODE_TYPE_WATCH.

Hàm Trình đơn không còn được dùng nữa mà thay vào đó là thanh thao tác kể từ Android 4.0. Do đó, việc triển khai thiết bị mới vận chuyển bằng Android 7.1 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. Việc triển khai thiết bị cũ KHÔNG NÊN 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 vật lý được triển khai và thiết bị đang chạy các ứng dụng có targetSdkVersion > 10, thì việc triển khai thiết bị sẽ:

PHẢI hiển thị nút trình đơn mục bổ sung thao tác trên thanh thao tác khi nút này hiển thị và trình đơn mục bổ sung thao tác bật lên không trống. Bạn NÊN thực hiện việc này đối với một thiết bị được triển khai trước Android 4.4 nhưng nâng cấp lên Android 7.1.
KHÔNG ĐƯỢC sửa đổi vị trí của cửa sổ bật lên mục bổ sung thao tác hiển thị bằng cách chọn nút mục bổ sung trong thanh thao tác.
CÓ THỂ kết xuất cửa sổ bật lên cho thao tác tràn ở một 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, thông qua nút vật lý, khoá phần mềm hoặc cử chỉ. Hàm Trình đơn này phải được hiển thị trừ phi bị ẩn cùng với các hàm điều hướng khác.

Việc triển khai thiết bị Android hỗ trợ Thao tác hỗ trợ và/hoặc VoiceInteractionService PHẢI có thể chạy một ứng dụng hỗ trợ 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 NÊN sử dụng thao tác nhấn và giữ trên màn hình chính làm phương thức tương tác này. Hoạt động tương tác được chỉ định PHẢI chạy ứng dụng hỗ trợ do người dùng chọn, nói cách khác là ứng dụng triển khai VoiceInteractionService hoặc một hoạt động xử lý ý định ACTION_ASSIST.

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, nhưng nếu có, 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 màn hình riêng biệt, không dành cho ứng dụng và KHÔNG ĐƯỢC che khuất hoặc can thiệp vào phần màn hình dành cho ứng dụng.
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 được xác định trong phần 7.1.1 .
Việc 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.
Việc triển khai thiết bị PHẢI hiển thị các phím điều hướng ở chế độ "hình thức thấp" (ví dụ: mờ) không gây khó chịu khi các ứng dụng chỉ định SYSTEM_UI_FLAG_LOW_PROFILE.
Việc triển khai thiết bị PHẢI ẩn các phím điều hướng khi ứng dụng chỉ định SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Nhập bằng màn hình cảm ứng

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

Việc triển khai thiết bị PHẢI có một hệ thống nhập con trỏ (giống như chuột hoặc cảm ứng). Tuy nhiên, nếu việc 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. Các phương thức triển khai thiết bị có 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 nhập 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 bằng thao tác chạm giả. Các hoạt động 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àn hình để người dùng có cảm giác trực tiếp thao tác với các mục trên màn hình. 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 thêm bất kỳ tính năng nào để cho biết các đối tượng đang được thao tác. Ngược lại, giao diện cảm ứng giả sẽ cung cấp hệ thống hoạt động đầu vào của người dùng gần giống với một số 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 giống như thao tác chạm, nhưng yêu cầu người dùng phải trỏ hoặc lấy 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 dây dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các hoạt động tương tác bằng thao tác chạm giả. Android bao gồm hằng số tính năng android.hardware.faketouch, tương ứng với một thiết bị đầu vào không chạm (dựa trên con trỏ) có độ trung thực cao, chẳng hạn như chuột hoặc bàn di chuột có thể mô phỏng đầy đủ phương thức nhập dựa trên cảm ứng (bao gồm cả hỗ trợ cử chỉ cơ bản) và cho biết rằng thiết bị hỗ trợ một tập hợp con được mô phỏng của chức năng màn hình cảm ứng. Việc 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 .

Việc triển khai thiết bị PHẢI báo cáo đúng tính năng tương ứng với loại dữ liệu đầu vào được sử dụng. Việc triển khai thiết bị có màn hình cảm ứng (một lần chạm trở lên) PHẢI báo cáo hằng số tính năng nền tảng android.hardware.touchscreen. Các hoạt động triển khai thiết bị báo cáo hằng số tính năng nền tảng android.hardware.touchscreen CŨNG PHẢI báo cáo hằng số tính năng nền tảng android.hardware.faketouch. Các hoạt động 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à CHỈ ĐƯỢC báo cáo 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 cách triển khai thiết bị khai báo 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ỏ hình ảnh trên màn hình.
PHẢI báo cáo sự kiện chạm bằng mã hành động chỉ định thay đổi trạng thái xảy ra trên con trỏ di xuống hoặc 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, cho phép người dùng mô phỏng thao tác nhấn vào một đối tượng trên màn hình.
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, cho phép người dùng mô phỏng thao tác nhấn đúp trên một đối tượng trên màn hình.
PHẢI hỗ trợ con trỏ nhấn xuống một điểm tuỳ ý trên màn hình, con trỏ di chuyển đến bất kỳ điểm tuỳ ý nào khác trên màn hình, theo sau là con trỏ di chuyển lên, cho phép người dùng mô phỏng thao tác kéo bằng cảm ứng.
PHẢI hỗ trợ con trỏ xuống, sau đó 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 con trỏ lên trên màn hình, cho phép người dùng hất một đối tượng trên màn hình.

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

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

Việc triển khai thiết bị Android Television PHẢI hỗ trợ các mối liên kết nút cho tay điều khiển trò chơi như được liệt kê bên dưới. Việc triển khai Android ngược dòng bao gồm cả việc triển khai cho tay điều khiển trò chơi đáp ứng yêu cầu này.

7.2.6.1. Ánh xạ nút

Việc triển khai thiết bị Android Television PHẢI hỗ trợ các ánh xạ phím sau:

Nút	Mức sử dụng HID ²	Nút Android
A ¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B ¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X ¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Có ¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad lên ¹ D-pad xuống ¹	0x01 0x0039 ³	AXIS_HAT_Y ⁴
D-pad trái 1 D-pad phải ¹	0x01 0x0039 ³	AXIS_HAT_X ⁴
Nút vai trái ¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Nút vai phải ¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Nhấp vào cần điều khiển bên trái ¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Nhấp vào cần điều khiển bên phải ¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Trang chủ ¹	0x0c 0x0223	KEYCODE_HOME (3)
Quay lại ¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Bạn phải khai báo các trường hợp sử dụng HID nêu trên trong một CA của tay điều khiển trò chơi (0x01 0x0005).

3 Mức sử dụng này phải có Giá trị tối thiểu hợp lý là 0, Giá trị tối đa hợp lý là 7, Giá trị tối thiểu thực tế là 0, Giá trị tối đa thực tế là 315, Đơn vị tính là Độ và Kích thước báo cáo là 4. Giá trị logic được xác định là xoay theo chiều kim đồng hồ ra khỏi trục dọc; ví dụ: giá trị logic 0 thể hiện không xoay và nút lên đang được nhấn, trong khi giá trị logic 1 thể hiện xoay 45 độ và cả nút lên và nút trái đang được nhấn.

4 MotionEvent

Điều khiển tương tự ¹	Mức sử dụng HID	Nút Android
Bộ kích hoạt bên trái	0x02 0x00C5	AXIS_LTRIGGER
Bộ kích hoạt bên phải	0x02 0x00C4	AXIS_RTRIGGER
Cần điều khiển bên trái	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Cần điều khiển bên phải	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

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

Việc triển khai thiết bị Android Television PHẢI cung cấp một đ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 thực tế hoặc có thể là điều khiển từ xa dựa trên phần mềm mà bạn có thể truy cập 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.

Cơ hội tìm kiếm . Việc triển khai thiết bị PHẢI kích hoạt KEYCODE_SEARCH (hoặc KEYCODE_ASSIST nếu thiết bị hỗ trợ trợ lý) 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 dựa trên phần mềm.
Điều hướng . Tất cả điều khiển từ xa của Android Television PHẢI có các nút Quay lại, Màn hình chính và Chọn, đồng thời hỗ trợ các sự kiện D-pad .

7.3. Cảm biến

Android bao gồm các API để truy cập vào nhiều loại cảm biến. Việc triển khai thiết bị thường CÓ THỂ bỏ qua các cảm biến này, như được cung cấp 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 nhà phát triển bên thứ ba, thì việc triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu SDK Android và tài liệu nguồn mở Android về các cảm biến . Ví dụ: cách triển khai thiết bị:

PHẢI báo cáo chính xác sự hiện diện hoặc vắng mặt của cảm biến theo lớp android.content.pm.PackageManager.
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ề 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ả kết quả đo lường của cảm biến bằng cách sử dụng các giá trị thích hợp của Hệ thống đo lường quốc tế (theo hệ mét) cho từng loại cảm biến như được xác định trong tài liệu về SDK Android.
NÊN báo cáo thời gian sự kiện tính bằng nano giây như được xác định trong tài liệu SDK Android, thể hiện thời gian xảy ra sự kiện và đồng bộ hoá với đồng hồ SystemClock.elapsedRealtimeNano(). Các thiết bị Android hiện tại và mới NÊN đáp ứng các yêu cầu này để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai, trong đó đây có thể là một 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ễ tối thiểu bắt buộc là 5 mili giây + 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 của cảm biến đang được kích hoạt. Mẫu này có thể có độ chính xác là 0.

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

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

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

Xin lưu ý rằng việc triển khai thiết bị PHẢI đảm bảo rằng luồng sự kiện cảm biến KHÔNG được ngăn CPU thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức từ trạng thái tạm ngưng.

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

7.3.1. Gia tốc kế

Việc triển khai thiết bị PHẢI bao gồm gia tốc kế 3 trục. Bạn NÊN đưa cảm biến này vào các thiết bị cầm tay Android, các bản triển khai Android Automotive và thiết bị Android Watch. Nếu việc triển khai thiết bị có bao gồm gia tốc kế 3 trục, thì thiết bị đó:

PHẢI triển khai và báo cáo cảm biến TYPE_ACCELEROMETER .
PHẢI có thể báo cáo các sự kiện với tần suất tối thiểu là 50 Hz đối với thiết bị Android Watch vì các thiết bị như vậy có hạn chế về nguồn điện nghiêm ngặt hơn và 100 Hz đối với tất cả các loại thiết bị khác.
NÊN báo cáo các sự kiện lên đến ít nhất 200 Hz.
PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android. Việc triển khai 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 lường từ trạng thái rơi tự do lên đến 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 là 12 bit và NÊN có độ phân giải tối thiểu là 16 bit.
NÊN được hiệu chuẩn trong khi sử dụng nếu các đặc điểm thay đổi trong vòng đời và được bù, đồ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 được bù trừ 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 cơ sở mỗi trục trên các mẫu được thu thập trong khoảng thời gian ít nhất 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_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER như mô tả trong tài liệu SDK Android. Bạn NÊN triển khai cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION trên các thiết bị Android hiện có và mới. Nếu bạn triển khai bất kỳ cảm biến nào trong số này, tổng mức tiêu thụ điện năng của các cảm biến đó PHẢI luôn nhỏ hơn 4 mW và MỖI cảm biến PHẢI nhỏ hơn 2 mW và 0,5 mW khi thiết bị ở trạng thái động hoặc tĩnh.
Nếu có cảm biến con quay hồi chuyển, BẮT BUỘC phải triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION và NÊN triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR. Bạn NÊN triển khai cảm biến TYPE_GAME_ROTATION_VECTOR cho các thiết bị Android hiện có và mới.
PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR, nếu cảm biến con quay hồi chuyển và cảm biến từ kế cũng được đưa vào.

7.3.2. Từ kế

Việc triển khai thiết bị PHẢI bao gồm từ kế (la bàn) 3 trục. Nếu có cảm biến từ trường 3 trục, thiết bị sẽ:

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. Bạn NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED cho các thiết bị Android hiện có và mới.
PHẢI có thể báo cáo các sự kiện có tần suất tối thiểu là 10 Hz và NÊN báo cáo các sự kiện có tần suất tối thiểu là 50 Hz.
PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android.
PHẢI có khả năng đo 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 máy đo từ trường cách xa trường từ động (do dòng điện gây ra) và trường từ 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ù trừ nhiệt độ.
PHẢI hỗ trợ việc hiệu chỉnh và bù độ lệch từ tính cứng trực tuyến, đồ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 tính năng bù sắt mềm – bạn có thể thực hiện việc hiệu chuẩn trong khi sử dụng hoặc trong quá trình sản xuất thiết bị.
PHẢI có độ lệch chuẩn, được tính trên mỗi trục dựa trên các mẫu được thu thập trong khoảng thời gian ít nhất 3 giây ở 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_VECTOR, nếu cảm biến gia tốc kế và cảm biến con quay hồi chuyển cũng được đưa vào.
CÓ THỂ triển khai cảm biến TYPE_GEOMAGNETIC_ROTATION_VECTOR nếu cũng triển khai cảm biến gia tốc kế. Tuy nhiên, nếu được triển khai, cảm biến PHẢI tiêu thụ ít hơn 10 mW và NÊN tiêu thụ ít hơn 3 mW khi được đăng ký cho chế độ hàng loạt ở tần số 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 việc triển khai thiết bị có bao gồm bộ thu GPS/GNSS và báo cáo khả năng này cho các ứng dụng thông qua cờ tính năng android.hardware.location.gps:

BạN NÊN tiếp tục phân phối đầu ra GPS/GNSS thông thường cho các ứng dụng trong khi gọi điện khẩn cấp và không chặn đầu ra vị trí trong khi gọi điện khẩn cấp.
API này PHẢI hỗ trợ đầu ra vị trí với tốc độ ít nhất là 1 Hz khi được yêu cầu thông qua LocationManager#requestLocationUpdate .
Thiết bị PHẢI xác định được vị trí trong điều kiện ngoài trời (tín hiệu mạnh, đa đường truyền không đáng kể, HDOP < 2) trong vòng 10 giây (thời gian nhanh để xác định vị trí lần đầu tiên), khi kết nối với kết nối Internet có tốc độ dữ liệu từ 0,5 Mb/giây trở lên. Yêu cầu này thường được đáp ứng bằng cách sử dụng một số hình thức kỹ thuật GPS/GNSS được hỗ trợ hoặc dự đoán để giảm thiểu thời gian khoá GPS/GNSS (Dữ liệu hỗ trợ bao gồm Thời gian tham chiếu, Vị trí tham chiếu và Bảng thông tin thiên văn/Đồng hồ vệ tinh).
- Sau khi thực hiện phép tính vị trí như vậy, thiết bị PHẢI có thể xác định vị trí của mình, ở ngoài trời, trong vòng 10 giây, khi các yêu cầu vị trí được khởi động lại, tối đa một giờ sau khi 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 quang đãng sau khi xác định vị trí, khi đứng yên hoặc di chuyển với gia tốc dưới 1 mét trên giây bình phương:
- Thiết bị PHẢI có thể xác định vị trí trong phạm vi 20 mét và tốc độ trong phạm vi 0, 5 mét/giây, ít nhất là 95% thời gian.
- Tính năng này 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.
- Thiết bị PHẢI có thể đồng thời theo dõi ít nhất 24 vệ tinh, từ nhiều chòm sao (ví dụ: GPS + ít nhất một trong các vệ tinh Glonass, Beidou, Galileo).
API này PHẢI báo cáo thế hệ công nghệ GNSS thông qua API kiểm thử "getGnssYearOfHardware".
Bạn NÊN và PHẢI đáp ứng tất cả các yêu cầu dưới đây nếu thế hệ công nghệ GNSS được báo cáo là năm "2016" trở lên.
- Ứng dụ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 toán từ GPS/GNSS chưa được báo cáo.
- Thiết bị này PHẢI báo cáo khoảng cách giả và tốc độ khoảng cách giả của GPS, trong điều kiện bầu trời quang đãng sau khi xác định vị trí, trong khi đứng yên hoặc di chuyển với gia tốc dưới 0, 2 mét trên giây vuông, đủ để tính toán vị trí trong vòng 20 mét và tốc độ trong vòng 0, 2 mét trên giây, ít nhất là 95% thời gian.

Xin lưu ý rằng mặc dù một số yêu cầu về GPS nêu trên được nêu là RẤT KHUYÊN DÙNG, nhưng Định nghĩa về khả năng tương thích cho phiên bản chính tiếp theo dự kiến sẽ thay đổi các yêu cầu này thành BẮT BUỘC.

7.3.4. Con quay hồi chuyển

Việc triển khai thiết bị PHẢI bao gồm con quay hồi chuyển (cảm biến thay đổi góc). Thiết bị KHÔNG NÊN có cảm biến con quay hồi chuyển trừ phi cũng có gia tốc kế 3 trục. Nếu việc triển khai thiết bị bao gồm con quay hồi chuyển, thì thiết bị đó:

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. Bạn NÊN triển khai cảm biến SENSOR_TYPE_GYROSCOPE_UNCALIBRATED trên các thiết bị Android hiện có và mới.
PHẢI có khả năng đo lường các thay đổi về hướng lên đến 1.000 độ mỗi giây.
PHẢI có thể báo cáo các sự kiện với tần suất tối thiểu là 50 Hz đối với thiết bị Android Watch vì các thiết bị như vậy có hạn chế về nguồn điện nghiêm ngặt hơn và 100 Hz đối với tất cả các loại thiết bị khác.
NÊN báo cáo các sự kiện lên đến ít nhất 200 Hz.
PHẢI có độ phân giải từ 12 bit trở lên và NÊN có độ phân giải từ 16 bit trở lên.
PHẢI được bù trừ nhiệt độ.
PHẢI được hiệu chỉnh và bù trong khi sử dụng, đồng thời duy trì các tham số bù giữa các lần khởi động lại thiết bị.
PHẢI có độ biến thiên không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (độ biến thiên trên mỗi Hz hoặc rad^2 / s). Độ lệch được phép thay đổi theo tốc độ lấy mẫu, nhưng phải bị ràng buộc bởi giá trị này. Nói cách khác, nếu bạn đo độ biến thiên của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì độ biến thiên đó không được lớn hơn 1e-7 rad^2/s^2.
PHẢI triển khai cảm biến tổng hợp TYPE_ROTATION_VECTOR, nếu cảm biến gia tốc kế và cảm biến từ kế cũng được đưa vào.
Nếu có cảm biến gia tốc kế, BẮT BUỘC phải triển khai cảm biến tổng hợp TYPE_GRAVITY và TYPE_LINEAR_ACCELERATION và NÊN triển khai cảm biến tổng hợp TYPE_GAME_ROTATION_VECTOR. Bạn NÊN triển khai cảm biến TYPE_GAME_ROTATION_VECTOR cho các thiết bị Android hiện có và mới.

7.3.5. Khí áp kế

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

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 sự kiện ở tốc độ 5 Hz trở lên.
PHẢI có độ chính xác đầy đủ để có thể ước tính độ cao.
PHẢI được bù trừ nhiệt độ.

7.3.6. Nhiệt kế

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

Việc triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN bao gồm cảm biến nhiệt độ CPU. Nếu có, bạn PHẢI xác định cảm biến này là SENSOR_TYPE_TEMPERATURE, 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 ý loại cảm biến SENSOR_TYPE_TEMPERATURE không còn được dùng trong Android 4.0.

Đối với các hoạt động triển khai Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE PHẢI đo nhiệt độ bên trong khoang xe.

7.3.7. Máy đo ánh sáng

Việc triển khai thiết bị CÓ THỂ bao gồm máy đo quang phổ (cảm biến ánh sáng xung quanh).

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

Việc triển khai thiết bị CÓ THỂ bao gồm cảm biến độ gần. Những 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 ngoài PHONE_TYPE_NONE trong getPhoneType PHẢI có cảm biến khoảng cách. Nếu quá trình triển khai thiết bị có sử dụng cảm biến độ gần, thì thiết bị đó:

PHẢI đo độ gần của một vật thể theo cùng hướng với màn hình. Tức là cảm biến khoảng cách PHẢI được định hướng để phát hiện các đối tượng ở gần màn hình, vì ý định chính của loại cảm biến này là phát hiện điện thoại mà người dùng đang sử dụng. Nếu việc triển khai thiết bị bao gồm cảm biến khoảng cách với 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ó độ trung thực cao

Việc 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ả các yêu cầu được liệt kê trong phần 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.

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:

SENSOR_TYPE_ACCELEROMETER
- PHẢI có phạm vi đo lường ít nhất là từ -8g đến +8g.
- 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 lường tối thiểu là 12,5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 400 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 400 uG/√Hz.
- PHẢI triển khai một dạng 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 3000 sự kiện cảm biến.
- PHẢI có mức tiêu thụ điện năng theo lô không tệ hơn 3 mW.
- NÊN có độ ổn định của độ lệch 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.
- PHẢI có độ phi tuyến tính của đường phù hợp nhất ≤ 0,5% và độ thay đổi độ nhạy so với nhiệt độ ≤ 0,03%/C°.
SENSOR_TYPE_GYROSCOPE
- PHẢI có phạm vi đo lường từ -1000 đến +1000 dps.
- PHẢI có độ phân giải đo lường tối thiểu là 16 LSB/dps.
- PHẢI có tần số đo lường tối thiểu là 12,5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 400 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 0,014°/giây/√Hz.
- PHẢI có độ ổn định của độ lệch tĩ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.
- PHẢI có mức thay đổi độ nhạy so với nhiệt độ ≤ 0,02% / °C.
- PHẢI có độ phi tuyến tính của đường phù hợp nhất ≤ 0,2%.
- PHẢI có mật độ nhiễu ≤ 0,007 °/s/√Hz.
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED có các yêu cầu về chất lượng giống như SENSOR_TYPE_GYROSCOPE.
SENSOR_TYPE_GEOMAGNETIC_FIELD
- PHẢI có phạm vi đo lường ít nhất từ -900 đến +900 uT.
- PHẢI có độ phân giải đo lường ít nhất là 5 LSB/uT.
- PHẢI có tần số đo lường tối thiểu là 5 Hz trở xuống.
- PHẢI có tần suất đo tối đa là 50 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 0,5 uT.
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED có các yêu cầu về chất lượng giống như SENSOR_TYPE_GEOMAGNETIC_FIELD và ngoài ra:
- PHẢI triển khai một dạng 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 lường từ 300 đến 1100 hPa.
- PHẢI có độ phân giải đo lường tối thiểu là 80 LSB/hPa.
- PHẢI có tần suất đo lường tối thiểu là 1 Hz trở xuống.
- PHẢI có tần suất đo tối đa từ 10 Hz trở lên.
- PHẢI có độ nhiễu đo lường không vượt quá 2 Pa/√Hz.
- PHẢI triển khai một dạng 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 theo lô không tệ hơn 2 mW.
SENSOR_TYPE_GAME_ROTATION_VECTOR
- PHẢI triển khai một dạng 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 theo lô không tệ hơn 4 mW.
SENSOR_TYPE_SIGNIFICANT_MOTION
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị đứng yên và 1,5 mW khi thiết bị đang di chuyển.
SENSOR_TYPE_STEP_DETECTOR
- PHẢI triển khai một dạng 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.
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị đứng yên và 1,5 mW khi thiết bị đang di chuyển.
- PHẢI có mức tiêu thụ điện năng theo lô không tệ hơn 4 mW.
SENSOR_TYPE_STEP_COUNTER
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị đứng yên và 1,5 mW khi thiết bị đang di chuyển.
SENSOR_TILT_DETECTOR
- PHẢI có mức tiêu thụ năng lượng không tệ hơn 0,5 mW khi thiết bị đứng yên và 1,5 mW khi thiết bị đang di chuyển.

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

Dấu thời gian của sự kiện về cùng một sự kiện vật lý do cảm biến Gia tốc kế, Con quay hồi chuyển và Máy đo từ trường báo cáo PHẢI nằm trong khoảng 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 dựa trên cùng một cơ sở thời gian với hệ thống con máy ảnh và nằm trong phạm vi sai số 1 mili giây.
Cảm biến có độ chân thực cao PHẢI phân phối các mẫu cho ứng dụng trong vòng 5 mili giây kể từ thời điểm dữ liệu có sẵn trên cảm biến thực tế cho ứng dụng.
Mức tiêu thụ điện năng KHÔNG ĐƯỢC cao hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 2,0 mW khi thiết bị đang di chuyển khi bất kỳ tổ hợp nào của các cảm biến sau được bật:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS

Xin 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. Mức tiêu thụ này bao gồm cả năng lượng mà toàn bộ chuỗi cảm biến tiêu thụ – cảm biến, mọi mạch điện hỗ trợ, mọi hệ thống xử lý cảm biến chuyên dụng, v.v.

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

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

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

Khi triển khai thiết bị có màn hình khoá bảo mật, bạn PHẢI dùng cảm biến vân tay. Nếu việc triển khai thiết bị bao gồm cảm biến vân tay và có API tương ứng cho nhà phát triển bên thứ ba, thì thiết bị đó:

PHẢI khai báo tính năng hỗ trợ 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%.
NÊN có tỷ lệ từ chối sai dưới 10%, được đo lường trên thiết bị
NÊN có độ trễ dưới 1 giây, được đo từ khi chạm vào cảm biến vân tay cho đến khi mở khoá màn hình, đối với một ngón tay đã đăng ký.
PHẢI giới hạn số lần thử trong ít nhất 30 giây sau 5 lần thử xác minh vân tay không thành công.
PHẢI triển khai kho khoá dựa trên phần cứng và thực hiện so khớp vân tay trong Môi trường thực thi đáng tin cậy (TEE) hoặc trên một khối có kênh bảo mật đến TEE.
PHẢI mã hoá và xác thực bằng mật mã tất cả dữ liệu vân tay nhận dạng được để không thể thu thập, đọc hoặc thay đổi dữ liệu đó bên ngoài Môi trường thực thi đáng tin cậy (TEE) như được ghi nhận 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à không thiết lập chuỗi tin cậy trước bằng cách yêu cầu người dùng xác nhận thông tin xác thực hiện có hoặc thêm thông tin xác thực thiết bị mới (Mã PIN/mẫu/mật khẩu) do TEE bảo mật; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện việc này.
KHÔNG ĐƯỢC cho phép ứng dụng 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.KEYGUARD_DISABLE_FINGERPRINT.
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 trên hoặc xoá dữ liệu vân tay khi nâng cấp từ phiên bản thấp hơn Android 6.0.
NÊN sử dụng biểu tượng Vân tay 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. Bánh răng hiện tại

Các hoạt động triển khai Android Automotive PHẢI 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

Việc 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 của trang tổng quan và NÊN dựa trên dữ liệu đầu vào của cảm biến ánh sáng xung quanh. Cảm biến ánh sáng xung quanh cơ bản CÓ THỂ giống với Photometer (Đồng hồ đo ánh sáng).

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

Việ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_UNRESTRICTED khi xe đã dừng hẳn và đỗ. Nhà sản xuất thiết bị có trách nhiệm định cấu hình SENSOR_TYPE_DRIVING_STATUS tuân thủ tất cả luật và quy định áp dụng cho 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 hoạt động triển khai Android Automotive PHẢI cung cấp tốc độ xe được xác định là SENSOR_TYPE_CAR_SPEED.

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

Việc triển khai thiết bị CÓ THỂ hỗ trợ cảm biến tư thế với 6 bậc tự do. NÊN hỗ trợ cảm biến này trên thiết bị cầm tay Android. Nếu việc triển khai thiết bị hỗ trợ cảm biến tư thế với 6 bậ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 so với chỉ vectơ xoay.

7.4. Kết nối dữ liệu

7.4.1. Điện thoại

"Điện thoại" như được sử dụng bởi 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. Mặc dù các cuộc gọi thoại này có thể được chuyển đổi gói hoặc không, nhưng đối với Android, các cuộc gọi này được coi là độc lập với mọi kết nối dữ liệu có thể được triển khai bằng cùng một mạng. Nói cách khác, chức năng và API "thoại" của Android đề cập cụ thể đến cuộc gọi thoại và tin nhắn SMS. Ví dụ: các phương thức triển khai thiết bị không thể thực hiện cuộc gọi hoặc gửi/nhận tin nhắn SMS KHÔNG ĐƯỢC 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ể chú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. Tức là Android tương thích với các thiết bị không phải điện thoại. Tuy nhiên, nếu việc triển khai thiết bị bao gồm cả điện thoại GSM hoặc CDMA, thì thiết bị đó PHẢI triển khai hỗ trợ đầy đủ cho API cho công nghệ đó. Việc triển khai thiết bị không bao gồm phần cứng điện thoại PHẢI triển khai toàn bộ API ở chế độ 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ố

Việc triển khai thiết bị Android Telephony PHẢI bao gồm tính năng hỗ trợ chặn số và:

PHẢI triển khai đầy đủ BlockedNumberContract 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 "BlockedNumberProvider" mà không có bất kỳ hoạt động tương tác nào với ứng dụng. Ngoại lệ duy nhất là khi việc chặn số tạm thời được gỡ bỏ như mô tả trong tài liệu SDK.
KHÔNG ĐƯỢC ghi vào nhà cung cấp nhật ký cuộc gọi của nền tảng cho cuộc gọi bị chặn.
KHÔNG ĐƯỢC ghi vào Nhà cung cấp dịch vụ điện thoại cho một tin nhắn bị chặn.
PHẢI triển khai giao diện người dùng quản lý số điện thoại bị chặn. Giao diện này được mở bằng ý định do phương thức TelecomManager.createManageBlockedNumbersIntent() trả về.
KHÔNG ĐƯỢC cho phép người dùng phụ xem hoặc chỉnh sửa các số điện thoại bị chặn trên thiết bị vì nền tảng Android giả định rằng người dùng chính có toàn quyền kiểm soát các dịch vụ điện thoại, một phiên bản duy nhất, trên thiết bị. Tất cả giao diện người dùng liên quan đến việc chặn PHẢI được ẩn đối với người dùng phụ và danh sách chặn PHẢI được tuân thủ.
NÊN di chuyển các số bị chặn vào 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)

Tất cả các hoạt động triển khai thiết bị Android đều PHẢI hỗ trợ một hoặc nhiều hình thức 802.11. Nếu việc 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 multicast API như mô tả trong tài liệu SDK.
PHẢI hỗ trợ DNS đa địa chỉ (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) bất cứ lúc nào hoạt động, bao gồm:
- Ngay cả khi màn hình không ở trạng thái đang hoạt động.
- Đối với việc triển khai thiết bị Android Television, ngay cả khi ở trạng thái nguồn điện chờ.

7.4.2.1. Wi-Fi Direct

Việc triển khai thiết bị PHẢI hỗ trợ Wi-Fi Direct (Wi-Fi ngang hàng). Nếu triển khai 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 việc triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì thiết bị đó:

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.
PHẢI hỗ trợ hoạt động đồng thời của Wi-Fi và Wi-Fi Direct.

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

Việc triển khai thiết bị PHẢI 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 SDK Android. Nếu quá trình triển khai thiết bị có hỗ trợ TDLS và TDLS được bật bằng API WiFiManager, thì thiết bị đó:

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

7.4.3. Bluetooth

Các cách triển khai Android Watch PHẢI hỗ trợ Bluetooth. Việc triển khai Android Television PHẢI hỗ trợ Bluetooth và Bluetooth LE. Các hoạt động triển khai Android Automotive PHẢI hỗ trợ Bluetooth và NÊN hỗ trợ Bluetooth LE.

Các phương thức triển khai thiết bị hỗ trợ tính năng android.hardware.vr.high_performance PHẢI hỗ trợ Bluetooth 4.2 và Tiện ích mở rộng độ dài dữ liệu Bluetooth LE.

Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp . Việc triển khai thiết bị bao gồm 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 (tương ứng là android.hardware.bluetooth và android.hardware.bluetooth_le) và triển khai các API nền tảng. Việc triển khai thiết bị PHẢI triển khai các hồ sơ Bluetooth có liên quan như A2DP, AVCP, OBEX, v.v. cho phù hợp với thiết bị.

Việc triển khai Android Automotive PHẢI 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 hồ sơ Bluetooth sau:

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

Các hoạt động triển khai thiết bị bao gồm cả việc 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 .
NÊN triển khai thời gian chờ cho Địa chỉ riêng tư có thể phân giải (RPA) không 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ợ việc giảm tải logic lọc cho chipset Bluetooth khi triển khai ScanFilter API và PHẢI báo cáo chính xác giá trị nơi logic lọc được triển khai bất cứ khi nào được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
NÊN hỗ trợ tính năng giảm tải hoạt động quét theo lô cho bộ vi mạch Bluetooth, nhưng nếu không được hỗ trợ, PHẢI báo cáo "false" (sai) bất cứ khi nào đượ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" (sai) bất cứ khi nào được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Giao tiếp trường gần

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

PHẢI báo cáo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature() .
PHẢI có khả năng đọc và ghi thông báo NDEF thông qua các tiêu chuẩn NFC sau:
- PHẢI có khả năng hoạt động như một trình đọc/ghi của NFC Forum (theo định nghĩa của thông số kỹ thuật NFC Forum NFCForum-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)
  - Loại thẻ NFC Forum 1, 2, 3, 4 (do NFC Forum xác định)
- NÊN có khả năng đọc và ghi thông điệp NDEF cũng như dữ liệu thô thông qua các tiêu chuẩn NFC sau đây. Xin lưu ý rằng mặc dù các tiêu chuẩn NFC dưới đây được nêu là RẤT NÊN, nhưng Đị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 các tiêu chuẩn này thành PHẢI. Các tiêu chuẩn này không bắt buộc trong phiên bản này nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị hiện có và mới chạy phiên bản Android này nên đáp ứng các yêu cầu này ngay từ bây giờ để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
  - NfcV (ISO 15693)
- PHẢI có khả năng đọc mã vạch và URL (nếu được mã hoá) của các sản phẩm Mã vạch NFC mỏng.
- PHẢI có khả năng truyền và nhận dữ liệu qua các giao thức và tiêu chuẩn ngang hàng sau:
  - ISO 18092
  - LLCP 1.2 (do NFC Forum xác định)
  - SDP 1.0 (do NFC Forum xác định)
  - Giao thức đẩy NDEF
  - SNEP 1.0 (do NFC Forum xác định)
- PHẢI hỗ trợ Android Beam .
- PHẢI triển khai máy chủ mặc định SNEP. Các 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 Android Beam trong phần cài đặt KHÔNG ĐƯỢC tắt tính năng gửi thông báo NDEF đến.
- PHẢI tuân thủ ý định android.settings.NFCSHARING_SETTINGS để hiển thị chế độ cài đặt 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 đến máy chủ SNEP mặc định khi bật Android Beam. 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, 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 để truyền", trước khi gửi thông báo NDEF P2P đi.
- PHẢI bật Android Beam theo mặc định và PHẢI có thể gửi và nhận bằng Android Beam, ngay cả khi chế độ P2p NFC độc quyền khác đang bật.
- PHẢI hỗ trợ tính năng chuyển giao Kết nối NFC sang Bluetooth khi thiết bị hỗ trợ Cấu hình đẩy đối tượng Bluetooth. Việc triển khai thiết bị PHẢI hỗ trợ tính năng chuyển đổi 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 " Chuyển đổi kết nối phiên bản 1.2 " và " Ghép nối đơn giản bảo mật qua Bluetooth bằng NFC phiên bản 1.0 " của NFC Forum. Việc triển khai như vậy PHẢI triển khai dịch vụ LLCP chuyển đổi có tên dịch vụ là "urn:nfc:sn:handover" để trao đổi yêu cầu chuyển đổi/chọn bản ghi qua NFC và PHẢI sử dụng Hồ sơ đẩy đối tượng Bluetooth để chuyển dữ liệu Bluetooth thực tế. Vì lý do cũ (để vẫn tương thích với các thiết bị Android 4.1), quá trình triển khai VẪN NÊN chấp nhận các yêu cầu GET SNEP để trao đổi yêu cầu chuyển giao/chọn bản ghi qua NFC. Tuy nhiên, bản thân quá trình triển khai KHÔNG NÊN gửi các yêu cầu GET SNEP để thực hiện việc chuyển đổi kết nối.
- PHẢI thăm dò ý kiến về tất cả các công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
- PHẢI ở chế độ khám phá NFC khi thiết bị ở trạng thái thức, màn hình đang hoạt động và màn hình khoá đã mở khoá.

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

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

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

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

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ư được 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ợ đầu đọc/ghi cho các công nghệ MIFARE sau.

MIFARE Classic
MIFARE Ultralight
NDEF trên MIFARE Classic

Xin lưu ý rằng Android có các API cho các loại MIFARE này. Nếu việc triển khai thiết bị hỗ trợ MIFARE ở vai trò trình đọc/ghi, thì thiết bị đó:

PHẢI triển khai các API Android tương ứng theo tài liệu của SDK Android.
PHẢI báo cáo tính năng com.nxp.mifare từ phương thức android.content.pm.PackageManager.hasSystemFeature(). Xin lưu ý rằng đây không phải là tính năng Android tiêu chuẩn và do đó không xuất hiện dưới dạng hằng số trong lớp android.content.pm.PackageManager.
KHÔNG ĐƯỢC triển khai các API Android tương ứng cũng như báo cáo tính năng com.nxp.mifare, trừ phi tính năng này cũng triển khai tính năng hỗ trợ NFC chung 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ì thiết bị 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 Android NFC API dưới dạng 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 trình bày dữ liệu độc lập với giao thức, nên việc triển khai thiết bị PHẢI triển khai các API này ngay cả khi các API đó 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

Việc triển khai thiết bị PHẢI hỗ trợ một hoặc nhiều hình thức kết nối mạng dữ liệu. Cụ thể, việc triển khai thiết bị PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu có tốc độ 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.

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

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á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 bắt buộc phụ thuộc vào loại mạng, như sau:

Các thiết bị hỗ trợ mạng Wi-Fi PHẢI hỗ trợ hoạt động chỉ IPv6 và ngăn xếp kép trên Wi-Fi.
Các thiết bị hỗ trợ mạng Ethernet PHẢI hỗ trợ hoạt động của ngăn xếp kép trên Ethernet.
Thiết bị hỗ trợ dữ liệu di động PHẢI 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ị đồng thời kết nối với nhiều mạng (ví dụ: Wi-Fi và dữ liệu di động), thì ứng dụng PHẢI đồng thời đáp ứng các yêu cầu này trên từng mạng mà ứng dụng kết nối.

Theo mặc định, BẠN PHẢI bật IPv6.

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

KHÔNG được ngắt kết nối IPv6 ở chế độ nghỉ.

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

Theo mặc định, các hoạt động triển khai thiết bị PHẢI bật chế độ cài đặt tự động đồng bộ hoá chính để phương thức getMasterSyncAutomatically() trả về giá trị "true".

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

Bạn NÊN triển khai chế độ tiết kiệm dữ liệu cho các thiết bị có kết nối có đo lượng dữ liệu.

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

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 hoặc xoá ứng dụng khỏi danh sách cho phép.

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

PHẢI trả về giá trị RESTRICT_BACKGROUND_STATUS_DISABLED cho ConnectivityManager.getRestrictBackgroundStatus()
KHÔNG ĐƯỢC truyền 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 đó dưới dạng không hoạt động.

7.5. Camera

Việc 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. Máy ảnh mặt sau là máy ảnh nằm ở cạnh của thiết bị đối diện với màn hình; tức là máy ảnh này chụp hình ảnh ở phía xa của thiết bị, giống như máy ảnh truyền thống. Máy ảnh mặt trước là máy ảnh nằm ở cùng một bên của thiết bị với màn hình; tức là máy ảnh thường dùng để chụp hì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 việc 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ể đồng thời phân bổ 3 bitmap RGBA_8888 bằng kích thước của hình ảnh do cảm biến máy ảnh có độ phân giải lớn nhất trên thiết bị tạo ra, trong khi máy ảnh đang mở để mục đích xem trước cơ bản và chụp ảnh tĩnh.

7.5.1. Máy ảnh mặt sau

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

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ối thiểu là 2 megapixel.
PHẢI triển khai tính năng tự động lấy nét bằng 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Ể có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường mở rộng).
CÓ THỂ có đèn flash. Nếu Máy ảnh có đèn flash, thì đèn flash KHÔNG ĐƯỢC sáng trong khi thực thể android.hardware.Camera.PreviewCallback đã được đăng ký trên nền tảng 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 các 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 hệ thống tích hợp sẵn của thiết bị, mà chỉ áp dụng cho các ứng dụng bên thứ ba sử dụng Camera.PreviewCallback.

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

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

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ặc định cho Camera API. API máy ảnh trong Android có hỗ trợ cụ thể cho máy ảnh mặt trước và việc 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.) có sẵn cho máy ảnh mặt sau như mô tả trong mục 7.5.1 .
PHẢI phản chiếu theo chiều ngang (tức là phản chiếu) luồng do ứng dụng hiển thị trong CameraPreview, như sau:
- Nếu người dùng có thể xoay chế độ triển khai thiết bị (chẳng hạn như tự động thông qua gia tốc kế hoặc theo cách thủ công thông qua dữ liệu đầu vào của người dùng), thì bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng hiện tại của thiết bị.
- Nếu ứng dụng hiện tại đã yêu cầu rõ ràng việc xoay màn hình Máy ảnh thông qua lệnh gọi đến 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 so với hướng do ứ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à postview hiển thị theo cách tương tự như luồng hình ảnh xem trước của máy ảnh. Nếu cách triển khai thiết bị không hỗ trợ chế độ xem sau, thì rõ ràng yêu cầu này sẽ không áp dụng.
KHÔNG ĐƯỢC phản ánh luồng video hoặc hình ảnh tĩnh đã chụp cuối cùng được trả về lệnh gọi lại của ứng dụng hoặc được cam kết lưu vào bộ nhớ phương tiện.

7.5.3. Máy ảnh gắn ngoài

Việc triển khai thiết bị CÓ THỂ bao gồm việc hỗ trợ máy ảnh bên ngoài không nhất thiết phải luôn được kết nối. Nếu hỗ trợ máy ảnh bên ngoài, thiết bị sẽ:

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 máy ảnh bên ngoài kết nối thông qua cổng USB.
PHẢI hỗ trợ các phương thức nén video như MJPEG để cho phép chuyển các luồng không được mã hoá chất lượng cao (tức là luồng hình ảnh thô hoặc được nén độc lập).
CÓ THỂ hỗ trợ mã hoá video dựa trên máy ảnh. Nếu được hỗ trợ, luồng không mã hoá / MJPEG đồng thời (độ phân giải QVGA trở lê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 Camera API

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

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

Việc 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, cho tất cả máy ảnh có sẵn:

Nếu một ứng dụng chưa bao giờ 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 của ứng dụng.
Nếu một ứng dụng đăng ký một thực thể android.hardware.Camera.PreviewCallback và hệ thống gọi phương thứ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 ở định dạng mã hoá NV21. Tức là NV21 PHẢI là giá trị mặc định.
Đối với android.hardware.Camera, việc 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) cho bản xem trước của máy ảnh cho cả máy ảnh mặt trước và mặt sau. (Máy quay 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, việc 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 đầu ra thông qua API android.media.ImageReader.

Việc triển khai thiết bị VẪN PHẢI triển khai đầy đủ Camera API có trong tài liệu SDK Android, bất kể thiết bị có tính năng tự động lấy nét bằng phần cứng hay các tính năng khác hay không. Ví dụ: các máy ảnh không có tính năng tự động lấy nét VẪN PHẢI gọi mọi thực thể android.hardware.Camera.AutoFocusCallback đã đăng ký (mặc dù điều này không liên quan đến máy ảnh không có tính năng tự động lấy nét). Xin lưu ý rằng điều này áp dụng cho máy ảnh mặt trước; ví dụ: mặc dù hầu hết máy ảnh mặt trước không hỗ trợ tí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ả.

Việc triển khai thiết bị PHẢI nhận dạng và tuân thủ từng tên tham 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 thiết bị không hỗ trợ một tính năng, thì API phải hoạt động như đã ghi nhận. Ngược lại, việc triển khai thiết bị KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số chuỗi được truyền đến phương thức android.hardware.Camera.setParameters() ngoài những hằng số được ghi nhận là hằng số trên android.hardware.Camera.Parameters. Tức là, việc triển khai thiết bị PHẢI hỗ trợ tất cả các thông số Máy ảnh chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại thông số Máy ảnh tuỳ chỉnh. Ví dụ: các hoạt động triển khai thiết bị hỗ trợ chụp ảnh bằng kỹ thuật hình ảnh dải động cao (HDR) PHẢI hỗ trợ thông số máy ảnh Camera.SCENE_MODE_HDR.

Vì không phải tất cả các phương thức triển khai thiết bị đều có thể hỗ trợ đầy đủ tất cả các tính năng của API android.hardware.camera2, nên các phương thức triển khai thiết bị PHẢI báo cáo cấp độ hỗ trợ thích 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 .

Việc 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; thiết bị phải xác định cờ tính năng nếu bất kỳ thiết bị máy ảnh nào được đính kèm hỗ trợ tính năng đó.

Việc triển khai thiết bị PHẢI truyền tin ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một bức ảnh mới và mục nhập của bức ảnh đó đã được thêm vào kho phương tiện.

Việc triển khai thiết bị PHẢI truyền tin ý định Camera.ACTION_NEW_VIDEO bất cứ khi nào máy ảnh quay video mới và mục nhập của ảnh đã được thêm vào kho phương tiện.

7.5.5. Hướng máy ảnh

Cả máy ảnh mặt trước và máy ảnh mặt sau (nếu có) PHẢI được định hướng để chiều dài của máy ảnh phù hợp với chiều dài của màn hình. Tức là khi thiết bị được 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ị; tức là áp dụng cho cả thiết bị chính theo hướng ngang và thiết bị chính theo hướng 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 Television PHẢI có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng.

Bộ nhớ có sẵn cho nhân và không gian người dùng khi triển khai thiết bị PHẢI ít nhất bằng hoặc lớn hơn các giá trị tối thiểu do bảng sau chỉ định. (Xem phần 7.1.1 để biết định nghĩa về kích thước và mật độ màn hình.)

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 áp dụng
280dpi trở xuống trên màn hình nhỏ/bình thường mdpi trở xuống trên màn hình lớn ldpi trở xuống 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 trên màn hình nhỏ/bình thường xhdpi trở lên trên màn hình lớn tvdpi trở lên trên màn hình cực lớn	896MB	1280MB
560dpi trở lên trên màn hình nhỏ/bình thường 400dpi trở lên trên màn hình lớn xhdpi trở lên trên màn hình cực lớn	1344MB	1824MB

Giá trị bộ nhớ tối thiểu PHẢI thêm vào mọi không gian bộ nhớ đã dành riêng cho các thành phần phần cứng như đài, video, v.v. không thuộc quyền kiểm soát của hạt nhân.

Việc triển khai thiết bị có bộ nhớ dưới 512 MB cho hạt nhân và không gian người dùng, trừ khi là Android Watch, PHẢI trả về giá trị "true" cho ActivityManager.isLowRamDevice().

Thiết bị Android Television PHẢI có dung lượng lưu trữ không bay hơi tối thiểu là 4GB và các thiết bị triển khai khác PHẢI có dung lượng lưu trữ không bay hơi tối thiểu là 3GB 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ối thiểu là 4GB đối với các thiết bị Android Television và tối thiểu là 3GB đối với các thiết bị triển khai khác. BẠN NÊN có ít nhất 4 GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai khi triển khai thiết bị chạy Android.

API Android bao gồm một Trình quản lý tải xuống mà các ứng dụng CÓ THỂ sử dụng để tải 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 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

Việc triển khai thiết bị PHẢI cung cấp bộ nhớ dùng chung cho các ứng dụng, còn gọi là "bộ nhớ ngoài dùng chung".

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

Việc triển khai thiết bị CÓ THỂ có phần cứng cho bộ nhớ có thể tháo rời mà người dùng có thể truy cập, chẳng hạn như khe cắm thẻ kỹ thuật số bảo mật (SD). Nếu khe 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ị sẽ:

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

Ngoài ra, các hoạt động 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 có trong Dự án nguồn mở Android cấp trên; các hoạt động triển khai thiết bị NÊN sử dụng cấu hình và cách triển khai phần mềm này. Nếu việc 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ẻ không gian với dữ liệu riêng tư của ứng dụng, thì bộ nhớ đó PHẢI có dung lượng tối thiểu là 1 GB và được gắn trên /sdcard (hoặc /sdcard PHẢI là đường liên kết tượng trưng đến vị trí thực tế nếu được gắn ở nơi khác).

Việc triển khai thiết bị PHẢI thực thi quyền android.permission.WRITE_EXTERNAL_STORAGE như đã ghi nhận trên bộ nhớ dùng chung này. Nếu không, mọi ứng dụng có được quyền đó PHẢI ghi được vào bộ nhớ dùng chung.

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

Tuy nhiên, việc triển khai thiết bị PHẢI hiển thị nội dung từ cả hai đường dẫn bộ nhớ một cách minh bạch thông qua dịch vụ quét nội dung đa phương tiện của Android và android.provider.MediaStore.

Bất kể hình thức bộ nhớ dùng chung được sử 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ì thiết bị đó 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ữ. Việc triển khai thiết bị CÓ THỂ sử dụng bộ nhớ khối lượng lớn USB, nhưng PHẢI sử dụng Giao thức truyền nội dung nghe nhìn để đáp ứng yêu cầu này. Nếu việc triển khai thiết bị hỗ trợ Giao thức truyền nội dung đa phương tiện, thì thiết bị đó:

PHẢI tương thích với máy chủ MTP Android tham chiếu, Android File Transfer .
NÊN báo cáo loại 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ớ thích ứng

Bạn NÊN triển khai bộ nhớ có thể chuyển đổi nếu cổng thiết bị bộ nhớ có thể tháo rời nằm ở vị trí ổn định lâu dài, chẳng hạn như trong ngăn pin hoặc nắp bảo vệ khác.

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

7.7. USB

Việc 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 việc triển khai thiết bị bao gồm một cổng USB hỗ trợ chế độ ngoại vi:

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

7.7.2. Chế độ máy chủ USB

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

NÊN sử dụng cổng USB loại C nếu việc triển khai thiết bị hỗ trợ USB 3.1.
CÓ THỂ sử dụng hệ số hình dạng cổng không chuẩn, nhưng nếu có, PHẢI đi kèm với cáp hoặc cáp chuyển đổi cổng thành 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ó, PHẢI đi kèm với cáp hoặc cáp chuyển đổi cổng này thành cổng USB loại A hoặc loại C tiêu chuẩn.
NÊN triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android.
PHẢI triển khai API máy chủ USB Android như được ghi nhận trong SDK Android và PHẢI khai báo hỗ trợ tính năng phần cứng android.hardware.usb.host .
PHẢI hỗ trợ sạc thiết bị khi ở chế độ máy chủ; quảng cáo dòng nguồn ít nhất là 1,5A như được chỉ định trong phần Thông số kết thúc của [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) cho các đầu nối USB Type-C hoặc sử dụng phạm vi dòng đầu ra của Cổng hạ nguồn sạc (CDP) như được chỉ định trong USB Battery Charging specifications, revision 1.2 (Thông số kỹ thuật sạc pin USB, bản sửa đổi 1.2) cho các đầu nối Micro-AB.
Bạn NÊN hỗ trợ DisplayPort cho thiết bị USB Type-C, PHẢI hỗ trợ Tốc độ dữ liệu USB SuperSpeed và NÊN hỗ trợ tính năng Cấp nguồn để hoán đổi vai trò dữ liệu và nguồn.
Thiết bị có bất kỳ cổng loại A hoặc loại AB nào KHÔNG ĐƯỢC vận chuyển kèm 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 phương tiện) được kết nối từ xa và cho phép truy cập vào nội dung của các thiết bị đó thông qua ý định ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT và ACTION_CREATE_DOCUMENT, nếu Khung truy cập bộ nhớ (SAF) được hỗ trợ.
PHẢI triển khai chức năng Cổng hai vai trò theo định nghĩa của thông số kỹ thuật USB Type-C (mục 4.5.1.3.3) nếu sử dụng cổng USB Type-C và hỗ trợ chế độ ngoại vi.
NÊN triển khai mô hình Try.* phù hợp nhất với kiểu dáng thiết bị nếu chức năng Cổng hai vai trò được hỗ trợ. Ví dụ: thiết bị cầm tay PHẢI triển khai mô hình Try.SNK.

7.8. Âm thanh

7.8.1. Micrô

Việc triển khai Android cho thiết bị cầm tay, đồng hồ và ô tô PHẢI bao gồm micrô.

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

PHẢI báo cáo hằng số tính năng android.hardware.microphone.
PHẢI đáp ứng các yêu cầu về bản 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 .
BẠN NÊN hỗ trợ tính năng ghi âm gần siêu âm như mô tả trong phần 7.8.3 .

7.8.2. Đầu ra âm thanh

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

Các phương thức 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 như tai nghe hoặc loa ngoài:

PHẢI báo cáo hằng số tính năng android.hardware.audio.output.
PHẢI đáp ứng các yêu cầu về 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 .
BẠN NÊN hỗ trợ chế độ phát gần siêu âm như mô tả trong mục 7.8.3 .

Ngược lại, nếu việc triển khai thiết bị không bao gồm loa hoặc cổng đầu ra âm thanh, thì thiết bị đó 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 ở chế độ không hoạt động.

Việc triển khai thiết bị Android Watch CÓ THỂ nhưng KHÔNG NÊN có đầu ra âm thanh, nhưng các loại 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 tương tự

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

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

7.8.3. Sóng siêu âm gần

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

Nếu PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND là "true", thì nguồn âm thanh VOICE_RECOGNITION và UNPROCESSED phải đáp ứng các yêu cầu sau:
- Độ nhạy trung bình của micrô trong băng tần từ 18,5 kHz đến 20 kHz PHẢI thấp hơn độ nhạy ở 2 kHz không quá 15 dB.
- Tỷ lệ tín hiệu/nhiễu không cân bằng của micrô trên 18,5 kHz đến 20 kHz đối với âm tần 19 kHz ở -26 dBFS PHẢI không thấp hơn 50 dB.
Nếu PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND là "true", thì độ nhạy trung bình của loa trong khoảng 18,5 kHz – 20 kHz PHẢI thấp hơn độ nhạy ở 2 kHz ít nhất 40 dB.

7.9. Thực tế ảo

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

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

Việc triển khai thiết bị cầm tay Android hỗ trợ chế độ cho các ứng dụng VR xử lý chế độ kết xuất 3D của thông báo và tắt các thành phần giao diện người dùng hệ thống đơn sắc trong khi ứng dụng VR có tiêu điểm 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 VR có thể bật thông qua android.app.Activity#setVrModeEnabled .

7.9.2. Hiệu suất cao trong thực tế ảo

Việc 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.

Việc triển khai thiết bị PHẢI có ít nhất 2 lõi vật lý.
Việc triển khai thiết bị PHẢI khai báo tính năng android.software.vr.mode.
Việc triển khai thiết bị CÓ THỂ cung cấp một lõi dành riêng cho ứng dụng trên nền trước và CÓ THỂ hỗ trợ API Process.getExclusiveCores để trả về số lượng lõi CPU dành riêng cho ứng dụng trên nền trước hàng đầu. Nếu hỗ trợ lõi độc quyền, 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 đó (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.
Việc triển khai thiết bị PHẢI hỗ trợ chế độ hiệu suất cao bền vững.
Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 3.2.
Việc triển khai thiết bị PHẢI hỗ trợ Phần cứng Vulkan cấp 0 và NÊN hỗ trợ Phần cứng Vulkan cấp 1.
Việc 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ể sử dụng cho Chế độ vùng đệm dùng chung và 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ó thể đồng bộ hoá quyền truy cập vào vùng đệm trước dùng chung để hiển thị nội dung VR ở tốc độ 60 khung hình/giây với hai ngữ cảnh kết xuất mà không có hiện tượng rách hình ảnh.
Việc triển khai thiết bị PHẢI triển khai EGL_IMG_context_priority và hiển thị tiện ích trong danh sách các tiện ích EGL hiện có.
Việc 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ó.
Việc triển khai thiết bị PHẢI triển khai EGL_EXT_protected_content và GL_EXT_protected_textures để có thể dùng cho tính năng Phát video kết cấu bảo mật và hiển thị các tiện ích trong danh sách tiện ích EGL và GL hiện có.
Việc triển khai thiết bị PHẢI hỗ trợ giải mã H.264 ở độ phân giải tối thiểu 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).
Việc triển khai thiết bị PHẢI hỗ trợ HEVC và VP9, PHẢI có khả năng giải mã ít nhất 1920x1080@30fps-10Mbps và NÊN có khả năng giải mã 3840x2160@30fps-20Mbps (tương đương với 4 phiên bản 1920x1080@30fps-5Mbps).
Bạn NÊN triển khai thiết bị để 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à la bàn cho android.hardware.hifi_sensors.
Việc triển khai thiết bị PHẢI hỗ trợ API HardwarePropertiesManager.getDeviceTemperatures và trả về giá trị chính xác cho nhiệt độ da.
Việc triển khai thiết bị PHẢI có màn hình được nhúng và độ phân giải PHẢI tối thiểu là FullHD(1080p) và NÊN là QuadHD (1440p) trở lên.
Màn hình PHẢI có kích thước đường chéo từ 4,7" đến 6".
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 Xám sang Xám, Trắng sang Đen và Đen sang Trắng PHẢI ≤ 3 mili giây.
Màn hình PHẢI hỗ trợ chế độ độ bền thấp với độ bền ≤5 mili giây,độ bền được xác định là khoảng thời gian một pixel phát ra ánh sáng.
Việc triển khai thiết bị PHẢI hỗ trợ Bluetooth 4.2 và Bluetooth LE Data Length Extension (Mở rộng độ dài dữ liệu Bluetooth LE) mục 7.4.3 .

8. Hiệu suất và nguồn điện

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

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

Việc triển khai thiết bị PHẢI cung cấp 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. Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu sau:

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

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

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 là 5MB/giây cho tệp 256MB bằng cách sử dụng vùng đệm ghi 10MB.
Ghi ngẫu nhiên . Việc triển khai thiết bị PHẢI đảm bảo hiệu suất ghi ngẫu nhiên tối thiểu là 0,5 MB/giây cho tệp 256 MB bằng cách sử dụng vùng đệm ghi 4 KB.
Đọ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 là 15 MB/giây cho tệp 256 MB bằng cách sử dụng vùng đệ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 là 3,5 MB/giây đối với tệp 256 MB bằng cách sử dụng vùng đệm ghi 4 KB.

8.3. Chế độ tiết kiệm pin

Android 6.0 đã ra mắt chế độ tiết kiệm pin Chế độ chờ ứng dụng và Nghỉ để tối ưu hoá mức sử dụng pin. Người dùng cuối PHẢI thấy được tất cả ứng dụng được miễn trừ khỏi các chế độ này. Ngoài ra, các thuật toán kích hoạt, bảo trì, đánh thức và sử dụng chế độ cài đặt hệ thống chung của các chế độ tiết kiệm pin này PHẢI tuân theo Dự án nguồn mở Android.

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

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

Việc tính toán và báo cáo chính xác hơn về mức tiêu thụ điện năng sẽ cung cấp cho nhà phát triển ứng dụng cả các biện pháp khuyến khích và công cụ để tối ưu hoá kiể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 năng lượng của thành phần phần cứng và phân bổ mức sử dụng năng lượng đó cho các ứng dụng cụ thể. Cụ thể, các phương thức triển khai:
- PHẢI cung cấp hồ sơ năng lượng cho mỗi thành phần xác định giá trị tiêu thụ hiện tại cho mỗi thành phần phần cứng và mức tiêu hao pin ước tính do các thành phần gây ra theo thời gian như được ghi nhận trên trang web Dự án nguồn mở Android.
- PHẢI báo cáo tất cả giá trị tiêu thụ điện năng theo đơn vị miliampe giờ (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 năng lượng 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 theo 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 hạt nhân uid_cputime.
PHẢI cung cấp mức sử dụng pin này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats.
PHẢI tuân thủ ý định android.intent.action.POWER_USAGE_SUMMARY và hiển thị trình đơn cài đặt cho biết mức sử dụng pin này.

8.5. Hiệu suất nhất quán

Hiệu suất có thể biến động mạnh đối với các ứng dụng chạy trong thời gian dài và có hiệu suất cao, do các ứng dụng khác chạy ở chế độ nền hoặc do CPU điều tiết do giới hạn nhiệt độ. Android bao gồm các giao diện lập trình để khi thiết bị có khả năng, ứng dụng trên cùng ở chế độ 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 để giải quyết những biến động như vậy.

Việc triển khai thiết bị PHẢI hỗ trợ Chế độ hiệu suất ổn định, có thể cung cấp cho ứng dụng trên nền trước hàng đầu một mức hiệu suất nhất quán trong 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(). Việc 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 cao bền vững thông qua phương thức API PowerManager.isSustainedPerformanceModeSupported().

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

Quá trình 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 nhân độc quyền mà ứng dụng trên cùng ở nền trước có thể đặt trước.
Việc 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 nhân độc quyền, nhưng CÓ THỂ cho phép một số quy trình hạt nhân chạy khi cần.

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

9. Khả năng tương thích 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 nhất quán với mô hình bảo mật của nền tảng Android như được xác định trong tài liệu tham khảo về Quyền và bảo mật trong các API trong tài liệu dành cho nhà phát triển Android. Việc triển khai thiết bị PHẢI hỗ trợ việc cài đặt các ứng dụng tự ký mà không yêu cầu thêm bất kỳ quyền/chứng chỉ nào từ bên thứ ba/cơ quan nào. Cụ thể, các thiết bị tương thích PHẢI hỗ trợ các cơ chế bảo mật được mô tả trong các tiểu mục sau.

9.1. Quyền

Việc triển khai thiết bị PHẢI hỗ trợ mô hình quyền trên Android như được xác định 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 bỏ qua, thay đổi hoặc bỏ qua bất kỳ quyền nào. Quá trình triển khai CÓ THỂ thêm các quyền khác, 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 quyền có protectionLevel là 'PROTECTION_FLAG_PRIVILEGED' cho các ứng dụng được tải trước trong(các) đường dẫn đặc quyền có 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.

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

PHẢI hiển thị một giao diện chuyên dụng để người dùng quyết định có cấp các quyền khi bắt đầu chạy được yêu cầu hay không, đồng thời cung cấp một giao diện để người dùng quản lý các quyền khi bắt đầu chạy.
PHẢI có một và chỉ một cách triển khai 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 sẵn, trừ phi:
- có thể lấy được sự đồng ý của người dùng trước khi ứng dụng sử dụng dữ liệu đó
- các quyền khi bắt đầu chạy được liên kết với một mẫu ý định mà ứng dụng được cài đặt sẵn được đặt làm trình xử lý mặc định

9.2. UID và cách ly quy trình

Việc triển khai thiết bị PHẢI hỗ trợ mô hình hộp cát ứng dụng Android, trong đó mỗi ứng dụng chạy dưới dạng một UID kiểu Unix duy nhất và trong một quy trình riêng biệt. Việc triển khai thiết bị PHẢI hỗ trợ chạy nhiều ứng dụng dưới cùng một mã nhận dạng người dùng Linux, miễn là các ứng dụng đó được ký và tạo đúng cách, như được xác định trong Tài liệu tham khảo về quyền và bảo mật .

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

Việc triển khai thiết bị PHẢI hỗ trợ mô hình quyền truy cập tệp Android như được xác định trong Tài liệu tham khảo về bảo mật và quyền .

9.4. Môi trường thực thi thay thế

Việc 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 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 làm tổn hại đế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à ứng dụng Android và tuân thủ mô hình bảo mật Android tiêu chuẩn, như mô tả ở phần khác trong phần 9 .

KHÔNG ĐƯỢC cấp quyền truy cập vào các tài nguyên được bảo vệ bằng các quyền không được yêu cầu trong tệp AndroidManifest.xml của môi trường thời gian chạy thông qua cơ chế <uses-permission>.

Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cho phép các ứng dụng sử dụng các tính năng được bảo vệ bằng các quyền Android chỉ dành cho ứ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ể, môi trường thời gian chạy thay thế:

NÊN cài đặt ứng dụng thô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 do tất cả ứng dụng sử dụng 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ài đặt trên thiết bị, ngoại trừ thông qua các cơ chế Android tiêu chuẩn về mã nhận dạng người dùng dùng chung và chứng chỉ ký.
KHÔNG ĐƯỢC chạy bằng, cấp hoặc được cấp quyền truy cập vào các hộp cát tương ứng với các ứng dụng Android khác.
KHÔNG ĐƯỢC chạy bằng, 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.

Các tệp .apk của môi trường thời gian chạy thay thế CÓ THỂ được đưa vào hình ảnh hệ thống của quá trình 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 có trong 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 có được sự đồng ý của người dùng đối với các quyền trên Android mà ứng dụng sử dụng. 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ì môi trường thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng sẽ có thể truy cập vào tài nguyên đó. 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 mà chính môi trường thời gian chạy nắm giữ khi cài đặt bất kỳ ứng dụng nào sử dụng môi trường thời gian chạy đó.

9.5. Hỗ trợ nhiều người dùng

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

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

Việc 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ả cá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.
Các hoạt động 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à các chức 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 để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó.
Ngược lại, việc triển khai thiết bị khai báo cờ tính năng android.hardware.telephony KHÔNG ĐƯỢC hỗ trợ hồ sơ bị hạn chế nhưng PHẢI tuân thủ cách triển khai các chế độ điều khiển của AOSP để cho phép /tắt người dùng khác truy cập vào cuộc gọi thoại và tin nhắn SMS.
Đối với mỗi 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ư được xác định trong tài liệu tham khảo về Quyền và bảo mật 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. Việc triển khai thiết bị CÓ THỂ lưu trữ dữ liệu của nhiều người dùng trên cùng một phương tiện 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à chạy thay mặt cho một người dùng nhất định không thể liệt kê, đọc hoặc ghi vào 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 có thể tháo rời, 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 dùng khác thông qua máy tính lưu trữ. Vì lý do này, việc triển khai thiết bị sử dụng phương tiện có thể tháo rời cho các 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ì điều này sẽ khiến máy tính lưu trữ không đọc được nội dung nghe nhìn, nên việc triển khai thiết bị sẽ yêu cầu chuyển sang MTP hoặc một hệ thống tương tự để cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại. Do đó, việc triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN cho phép nhiều người dùng nếu họ sử dụng phương tiện có thể tháo rời cho bộ nhớ ngoài chính.

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

Android hỗ trợ cảnh báo người dùng về mọi tin nhắn SMS đặc biệt gửi đi . Tin nhắn SMS cao cấp là tin nhắn văn bản được gửi đến một dịch vụ đã đăng ký với nhà mạng và có thể tính phí người dùng. Các hoạt động triển khai thiết bị khai báo 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/misc/sms/codes.xml trong thiết bị. Dự án nguồn mở Android cấp trên cung cấp 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 của nhân

Hộp cát Android bao gồm các tính năng sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) của Security-Enhanced Linux (SELinux), hộp cát seccomp và các tính năng bảo mật khác trong hạt nhân Linux. 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 có giao diện người dùng hiển thị khi phát hiện và chặn thành công một lỗi vi phạm bảo mật, nhưng CÓ THỂ có giao diện người dùng hiển thị khi xảy ra lỗi vi phạm bảo mật chưa bị chặn dẫn đến việc khai thác thành công.
KHÔNG được người dùng hoặc nhà phát triển định cấu hình.

Nếu bất kỳ API nào để định cấu hình chính sách được hiển thị cho 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 làm hỏng 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 hạt nhân không phải Linux, thì phải triển khai một hệ thống kiểm soát quyền 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, được đáp ứng bằng cách triển khai tham chiếu trong Dự án nguồn mở Android cấp trên.

Triển khai trên thiết bị:

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

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

Thiết bị PHẢI triển khai cơ chế hộp cát cho ứng dụng hạt nhân cho phép lọc các lệnh gọi hệ thống bằng chính sách có thể định cấu hình từ các chương trình đ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 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 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 ghi lại/ghi âm.

Nếu việc triển khai thiết bị có cơ chế định tuyến lưu lượng dữ liệu mạng thô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 có cấp quyền android.permission.CONTROL_VPN), thì việc 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 thông qua DevicePolicyManager.setAlwaysOnVpnPackage(). Trong trường hợp này, người dùng không cần phải đồng ý riêng, nhưng PHẢI được thông báo.

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

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 người dùng biết rằng lưu lượng truy cập mạng có thể được giám sát.

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

9.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á bảo mật.

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

Đối với các hoạt động triển khai thiết bị hỗ trợ tính năng mã hoá bộ nhớ dữ liệu và có hiệu suất mã hoá theo tiêu chuẩn mã hoá nâng cao (AES) trên 50 MiB/giây, tính năng mã hoá bộ nhớ 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 trải nghiệm thiết lập ngay khi lấy thiết bị ra khỏi hộp. Nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ hơn và tính năng 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 và do đó CÓ THỂ được miễn trừ.

Việc 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 Mã hoá dựa trên tệp (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 không hỗ trợ tính năng Mã hoá bộ nhớ. Cụ thể, bạn vẫn phải truyền phát Ý định LOCKED_BOOT_COMPLETED và ACTION_USER_UNLOCKED để báo hiệu cho các ứng dụng nhận biết chế độ Khởi động trực tiếp rằng người dùng có thể sử dụng các vị trí lưu trữ được mã hoá của thiết bị (DE) và được mã hoá thông tin xác thực (CE).

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

Các cách 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 xác thực và cho phép các ứng dụng nhận biết chế độ 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 truyền tin.
PHẢI chỉ cho phép truy cập vào bộ nhớ được mã hoá dành cho thông tin đăng nhập (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 khẩu, mã PIN, hình mở khoá hoặc vân tay) và thông báo ACTION_USER_UNLOCKED được truyền tin. Việc 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 CE mà không có thông tin xác thực do người dùng cung cấp.
PHẢI hỗ trợ tính năng Xác minh quy trình khởi động và đảm bảo rằng các khoá DE được liên kết bằng phương thức mã hoá với gốc đáng tin cậy của phần cứng trên 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ã, độ dài khoá và chế độ thay thế để mã hoá nội dung tệp và tên tệp, nhưng PHẢI sử dụng các thuật toán mật mã, độ dài khoá và chế độ được hỗ trợ bắt buộc theo mặc định.
NÊN cho phép các ứng dụng thiết yếu được tải trước (ví dụ: Chuông báo, Điện thoại, Messenger) nhận biết được tính năng Khởi động trực tiếp.

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

PHẢI được liên kết bằng phương thức mã hoá với Kho khoá được hỗ trợ phần cứng. Khoá CE phải được liên kết với thông tin đăng nhập của người dùng trên màn hình khoá. Nếu người dùng chưa chỉ định thông tin xác thực màn hình khoá, thì khoá CE PHẢI được liên kết với mã xác thực 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 khớp với khoá CE hoặc DE của người dùng nào khác.

Dự án nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên cho tính năng này dựa trên tính năng mã hoá ext4 của nhân Linux.

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

Các phương thức triển khai thiết bị hỗ trợ tính năng 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). KHÔNG được ghi khoá mã hoá vào bộ nhớ bất cứ lúc nào mà không được mã hoá. Người dùng PHẢI có thể mã hoá khoá mã hoá bằng AES, ngoại trừ khi khoá đang được sử dụng, với thông tin đăng nhập màn hình khoá được kéo giãn 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 khoá hoặc đã tắt tính năng sử dụng mật mã để mã hoá, thì hệ thống PHẢI sử dụng mật mã mặc định để gói khoá mã hoá. Nếu thiết bị cung cấp kho khoá dựa trên phần cứng, thì thuật toán kéo giãn mật khẩu PHẢI được liên kết bằng mật mã với kho khoá đó. KHÔNG ĐƯỢC gửi khoá mã hoá ra khỏi thiết bị (ngay cả khi khoá được gói bằng mật khẩu người dùng và/hoặc khoá liên kết với 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 cho tính năng này dựa trên tính năng dm-crypt của nhân 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 tính minh bạch về trạng thái tính toàn vẹn của thiết bị.

Việc 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() cho biết 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 được dành riêng cho các hoạt động triển khai thiết bị nâng cấp từ một phiên bản Android cũ hơn, trong đó phương thức API hệ thống mới này không tồn tại.

Xác minh quy trình khởi động là một tính năng đảm bảo tính toàn vẹn của phần mềm thiết bị. Nếu triển khai tính năng này trên thiết bị, thì thiết bị đó 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ừ khoá phần cứng không thể thay đổi, là gốc của sự tin cậy và đi đế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à tính xác thực của tất cả các byte trong giai đoạn tiếp theo trước khi thực thi mã trong giai đoạn tiếp theo.
Sử dụng các thuật toán xác minh mạnh mẽ như các đề xuất hiện tại của NIST đối với 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 khởi động hoàn tất khi xác minh hệ thống không thành công, trừ phi người dùng đồng ý thử khởi động, trong trường hợp này, KHÔNG ĐƯỢC sử dụng dữ liệu từ bất kỳ khối bộ nhớ nào chưa được xác minh.
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 hoạt động 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ợ tính năng khởi động được xác minh để đảm bảo tính toàn vẹn của thiết bị.

Nếu quá trình triển khai thiết bị đã bắt đầu 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ũ, thì thiết bị đó không thể thêm tính năng hỗ trợ cho tính năng này bằng bản cập nhật phần mềm hệ thống và do đó sẽ được miễn trừ yêu cầu này.

9.11. Khoá và thông tin xác thực

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

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

KHÔNG được giới hạn số lượng khoá có thể tạo và PHẢI cho phép nhập ít nhất 8.192 khoá.
Quy trình xác thực màn hình khoá PHẢI giới hạn số lần thử và PHẢI có thuật toán thời gian đợi luỹ thừa. Sau 150 lần thử không thành công, thời gian trễ PHẢI là ít nhất 24 giờ cho mỗi lần thử.
Khi triển khai thiết bị hỗ trợ màn hình khoá bảo mật, thiết bị PHẢI sao lưu việc 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ã hoá RSA, AES, ECDSA và HMAC cũng như các hàm băm thuộc nhóm MD5, SHA1 và SHA-2 để hỗ trợ đúng cách các thuật toán được hỗ trợ của hệ thống Kho khoá Android trong một khu vực được tách biệt an toàn với mã chạy trên hạt nhân trở lên. Tính năng tách biệt an toàn PHẢI chặn tất cả cơ chế tiềm ẩn mà theo đó mã nhân hoặc không gian người dùng có thể truy cập vào trạng thái nội bộ của môi trường tách biệt, bao gồm cả DMA. Dự án nguồn mở Android (AOSP) thượng nguồn đáp ứng yêu cầu này bằng cách triển khai Trusty, nhưng một giải pháp khác dựa trên ARM TrustZone hoặc một phương thức triển khai bảo mật đã được bên thứ ba xem xét về việc tách biệt dựa trên trình điều khiển ảo hoá thích hợp là các lựa chọn thay thế.
- PHẢI thực hiện quy trình xác thực màn hình khoá trong môi trường thực thi riêng biệt và chỉ cho phép sử dụng các khoá liên kết với quy trình xác thực khi quy trình này thành công. Dự án nguồn mở Android cấp trên cung cấp Lớp trừu tượng phần cứng (HAL) của Gatekeeper và Trusty. Bạn có thể sử dụng các lớp này để đáp ứng yêu cầu này.

Xin lưu ý rằng nếu quá trình triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ hơn, thì thiết bị đó sẽ được miễn yêu cầu phải 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á bảo mật

Việc triển khai thiết bị CÓ THỂ thêm hoặc sửa đổi các 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 thức xác thực, nếu dựa trên một bí mật đã biết, KHÔNG ĐƯỢC coi 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:
- Độ hỗn loạn của độ dài đầu vào ngắn nhất được phép PHẢI lớn hơn 10 bit.
- Độ hỗn loạn tối đa của tất cả dữ liệu đầu vào có thể 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 Bộ điều khiển 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 .
Phương thức xác thực, nếu dựa trên mã thông báo thực hoặc vị trí, KHÔNG ĐƯỢC coi là màn hình khoá bảo mật trừ khi phương thức đó đáp ứng tất cả các yêu cầu sau:
- Phương thức 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 khoá 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.
- Bạn PHẢI tắt tính năng này 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 Bộ điều khiển 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 thức xác thực (nếu dựa trên sinh trắc học) KHÔNG ĐƯỢC coi 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:
- Phương thức 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 khoá 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.
- Bạn PHẢI tắt tính năng này 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 Bộ điều khiển 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) .
- Phương thức này PHẢI có tỷ lệ chấp nhận sai bằng hoặc cao hơn tỷ lệ yêu cầu đối với cảm biến vân tay như mô tả trong phần 7.3.10, nếu không 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 điều khiển 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_BIOMETRIC_WEAK .
Nếu không thể coi phương thức xác thực là màn hình khoá bảo mật, thì phương thức đó:
- PHẢI trả về false cho cả phương thức KeyguardManager.isKeyguardSecure() và KeyguardManager.isDeviceSecure().
- PHẢI tắt khi ứng dụng Bộ điều khiển 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 bộ 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 thức xác thực dựa trên mã thông báo 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 mức yêu cầu đối với cảm biến vân tay như mô tả trong phần 7.3.10, thì phương thức đó:
- KHÔNG ĐƯỢC đặt lại bộ 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 một cơ chế để thực hiện tính năng "Đặt lại dữ liệu về trạng thái ban đầu", cho phép xoá tất cả dữ liệu cả về mặt logic và vật lý, ngoại trừ những dữ liệu 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

BẠN PHẢI xoá tất cả dữ liệu do người dùng tạo. Phương thức này PHẢI đáp ứng các tiêu chuẩn ngành liên quan về việc xoá dữ liệu, chẳng hạn như NIST SP800-88. Bạn PHẢI sử dụng API này để triển khai API wipeData() (một phần của Android Device Administration API) đượ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á dữ liệu nhanh để xoá dữ liệu theo logic.

9.13. Chế độ khởi động an toàn

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

Bạn NÊN triển khai Chế độ khởi động an toàn và đáp ứng các yêu cầu sau đây khi triển khai thiết bị Android:

Việc triển khai thiết bị PHẢI cung cấp cho người dùng một tuỳ chọn để chuyển sang Chế độ khởi động an toàn từ trình đơn khởi động. Người dùng có thể truy cập vào trình đơn này thông qua một quy trình làm việc khác với quy trình khởi động thông thường.
Việc 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 theo cách không bị gián đoạn bởi các ứng dụng bên thứ ba được cài đặt trên thiết bị, ngoại trừ trường hợp ứng dụng bên thứ ba là Trình điều khiển chính sách thiết bị và đã đặt cờ UserManager.DISALLOW_SAFE_BOOT thành true.
Việc 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. Tách biệt hệ thống trên xe ô tô

Dự kiến, các thiết bị Android Automotive sẽ trao đổi dữ liệu với các hệ thống con quan trọng của xe, chẳng hạn như bằng cách sử dụng HAL của xe để gửi và nhận thông báo qua mạng xe như bus CAN. Việc 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 ngoài ý muốn giữa khung Android hoặc ứng dụng bên thứ ba và các hệ thống con 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 của khung xe Android, ví dụ: danh sách cho phép các loại thông báo và nguồn thông báo được phép.
Watchdog 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. Điều này giúp ngăn chặn phần mềm độc hại làm ngập mạng xe bằng lưu lượng truy cập, từ đó có thể dẫn đến các hệ thống phụ của xe hoạt động không đúng cách.

10. Kiểm thử khả năng tương thích của phần mềm

Việc 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, xin lưu ý rằng không có gói kiểm thử phần mềm nào hoàn toàn toàn diện. Vì lý do này, những người triển khai thiết bị NÊN thực hiện ít thay đổi nhất có thể đối với tài liệu tham khảo và cách triển khai Android ưu tiên có trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ phát sinh lỗi gây ra sự không tương thích, đòi hỏi phải làm lại và có thể phải cập nhật thiết bị.

10.1. Bộ kiểm thử khả năng tương thích

Việc triển khai thiết bị PHẢI vượt qua Bộ kiểm thử tính tương thích với Android (CTS) có trong Dự án nguồn mở Android, bằng cách sử dụng phần mềm vận chuyển chính thức trên thiết bị. Ngoài ra, người triển khai thiết bị NÊN sử dụng phương thức triển khai tham chiếu trong cây Nguồn mở Android càng nhiều càng tốt và PHẢI đảm bảo khả năng tương thích trong trường hợp không rõ ràng trong CTS và đối với mọi hoạt động 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 một thiết bị thực. Giống như mọi phần mềm khác, chính CTS cũng có thể chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa về khả năng tương thích này và có thể phát hành nhiều bản sửa đổi của CTS cho Android 7.1. Việc 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. Trình xác minh CTS

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

Công cụ xác minh CTS có các bài kiểm thử cho nhiều loại phần cứng, bao gồm cả một số phần cứng không bắt buộc. Việc triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử cho phần cứng mà thiết bị đó có; ví dụ: nếu một thiết bị có gia tốc kế, thì thiết bị đó PHẢI thực thi chính xác trường hợp kiểm thử Gia tốc kế trong Trình xác minh CTS. Bạn CÓ THỂ bỏ qua hoặc loại bỏ các trường hợp kiểm thử cho 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.

Mọi thiết bị và mọi bản dựng PHẢI chạy đúng cách Trình xác minh CTS, như đã lưu ý ở trên. Tuy nhiên, vì nhiều bản dựng rất giống nhau, nên người triển khai thiết bị không cần phải chạy rõ ràng Trình xác minh CTS trên các bản dựng chỉ khác nhau ở những điểm nhỏ. Cụ thể, việc triển khai thiết bị khác với việc triển khai đã vượt qua Trình xác minh CTS chỉ bằng bộ ngôn ngữ, thương hiệu, v.v. ĐƯỢC phép bỏ qua quy trình kiểm thử Trình xác minh CTS.

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

Việc 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à có thể cần phải khởi động lại thiết bị.

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

Tải xuống "qua mạng không dây (OTA)" với bản cập nhật ngoại tuyến thông qua việc khởi động lại.
Cập nhật "Có dây" qua USB từ máy tính lưu trữ.
Cập nhật "ngoại tuyến" thông qua việc khởi động lại và cập nhật từ một tệp trên bộ nhớ có thể tháo rời.

Tuy nhiên, nếu việc triển khai thiết bị bao gồm cả việc hỗ trợ kết nối dữ liệu không đo lượng dữ liệu như hồ sơ 802.11 hoặc Bluetooth PAN (Mạng cá nhân), thì thiết bị PHẢI hỗ trợ tính năng tải xuống OTA bằng bản 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 xoá dữ liệu người dùng. Tức là cơ chế cập nhật PHẢI giữ lại dữ liệu riêng tư của ứng dụng và dữ liệu dùng chung của ứng dụng. Xin 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ị đang chạy Android 6.0 trở lên, cơ chế cập nhật PHẢI hỗ trợ việc xác minh rằng hình ảnh hệ thống là tệp nhị phân giống với kết quả dự kiến sau khi cập nhật qua OTA. Việc triển khai OTA dựa trên khối trong Dự án nguồn mở Android ngược dòng, được thêm vào kể từ Android 5.1, đáp ứng yêu cầu này.

Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ bản cập nhật hệ thống A/B . AOSP triển khai tính năng này bằng cách sử dụng HAL điều khiển khởi động.

Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi phát hành nhưng trong thời gian sử dụng sản phẩm hợp lý (được xác định bằng cách 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, thì bên triển khai thiết bị PHẢI khắc phục lỗi thông qua bản cập nhật phần mềm hiện có và có thể áp dụng theo 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. Để hỗ trợ 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

Dưới đây là nội dung tóm tắt về 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:

Ghi lại nhật ký thay đổi

Dưới đây là nội dung tóm tắt về các thay đổi đối với từng phần:

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

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

CDD
Các thay đổi quan trọng đố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 giao diện hoặc bản dựng.

Để xem hiệu quả nhất, hãy thêm các tham số URL pretty=full và no-merges vào URL nhật ký thay đổi.

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 để yêu cầu làm rõ hoặc nêu bất kỳ vấn đề nào mà bạn cho rằng tài liệu không đề cập đến.