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 [Tài nguyên, 1].

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 6.0. "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 6.0, 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 rõ ràng, mơ hồ hoặc không đầy đủ, thì người triển khai thiết bị phải chịu 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 [Tài nguyên, 2] 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 phương thức triển khai thiết bị theo mức độ lớn nhất có thể dựa trên mã nguồn "nguồn cấp trên" có trong Dự án nguồn mở Android. Mặc dù có thể giả định một số thành phần có thể được thay thế bằng các phương thức triển khai thay thế, nhưng bạn KHÔNG NÊN làm theo phương pháp này, vì việc vượt qua các bài kiểm thử phần mềm sẽ trở nên khó khăn hơn đáng kể. 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 tiêu 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ệt kê trong phần 14 đượ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 hệt 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 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à tài liệu chính thức. Mọi thông tin kỹ thuật được cung cấp trong tài liệu tham khảo có trong phần 14 đề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ác 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"). Các 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 [Tài nguyên, 3].

Thiết bị đồng hồ Android đề cập đến việc 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 [Tài nguyên, 4].

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

PHẢI khai báo tính năng android.hardware.type.automotive.
PHẢI hỗ trợ uiMode = UI_MODE_TYPE_CAR [Tài nguyên, 5].

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 6.0, trừ phi yêu cầu được mô tả rõ ràng là chỉ áp dụng cho một loại thiết bị Android cụ thể ở trên.

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

Đây là phầ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ị "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	PHẢI		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
	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 do SDK Android hiển thị [Tài nguyên, 6] hoặc mọi API được trang trí bằng điểm đánh dấu "@SystemApi" trong mã nguồn Android thượng nguồn.

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.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 trên trang Tham khảo về quyền [Tài nguyên, 7]. 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 [Tài nguyên, 8] dùng để mô tả thiết bị hiện tại. Để cung cấp các giá trị nhất quán, có ý nghĩa 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 [Tài nguyên, 9].
VERSION.SDK	Phiên bản của hệ thống Android đang thực thi, ở định dạng có thể truy cập được vào mã ứng dụng bên thứ ba. Đối với Android 6.0, trường này PHẢI có giá trị số nguyên là 23.
VERSION.SDK_INT	Phiên bản của hệ thống Android đang thực thi, ở định dạng có thể truy cập được vào mã ứng dụng bên thứ ba. Đối với Android 6.0, trường này PHẢI có giá trị số nguyên là 23.
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 của công cụ 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 đến. 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_-]+$”.
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 là tên mà con người có thể đọc được một cách hợp lý. 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:6.0/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 là tên mà con người có thể đọc được một cách hợp lý. Giá trị của trường này PHẢI 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 xác định 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ó thể đọc được. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ 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 là 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) 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 được, nhưng không nhất thiết là để người dùng cuối 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_-]+$".
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ý nền tảng Android thông thường: 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. Tiêu đề này PHẢI cho biết rằng bản dựng bao gồm tất cả các bản vá bảo mật được phát hành thông qua Bản tin bảo mật công khai của Android được chỉ định. Ngày phát hành PHẢI ở định dạng [YYYY-MM-DD], khớp với một trong các chuỗi Cấp bản vá bảo mật của Android trong Bản tin bảo mật công khai, ví dụ: "2015-11-01".
BASE_OS	Một giá trị đại diện cho tham số FINGERPRINT của bản dựng giống hệt bản dựng này ngoại trừ các bản vá được cung cấp trong Bản tin bảo mật công khai của Android. Phương thức này PHẢI báo cáo giá trị chính xác và nếu không có bản dựng 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

Việc triển khai thiết bị PHẢI tuân thủ hệ thống ý định kết hợp lỏng của Android, như mô tả trong các phần bên dưới. "Được tôn trọng" có nghĩa là trình triển khai thiết bị PHẢI cung cấp một Hoạt động hoặc Dịch vụ Android chỉ định một bộ lọc ý định phù hợp liên kết với và triển khai hành vi chính xác cho từng mẫu ý định được chỉ đị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 Android ngược dòng 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ị NÊN bao gồm các ứng dụng Android cốt lõi khi thích hợp, nhưng PHẢI bao gồm 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ông khai" của các ứng dụng Android cốt lõi này xác định. Xin lưu ý rằng các thành phần Hoạt động hoặc Dịch vụ được coi là "công khai" khi thuộc tính android:exported không có hoặc có giá trị true.

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

Vì Android là một nền tảng có thể mở rộng, nên việc triển khai thiết bị PHẢI cho phép các ứng dụng bên thứ ba ghi đè từng mẫu ý định được tham chiếu trong phần 3.2.3.1. Theo mặc định, việc triển khai nguồn mở Android ngược dòng cho phép điều 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 cụ thể bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng "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 một thuộc tính cụ thể hơn cho URI dữ liệu. Ví dụ: mẫu bộ lọc ý định chỉ định URI dữ liệu "http://www.android.com" cụ thể hơn mẫu ý định cốt lõi của trình duyệt cho "http://".

Android cũng 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 [Tài nguyên, 140]. 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 quy cách Đường liên kết đến tài sản kỹ thuật số [Tài nguyên, 141] do Trình quản lý gói triển khai trong Dự án nguồn mở Android ngược dòng.
PHẢI thử xác thực các bộ lọc ý định trong quá trình cài đặt ứng dụng và đặt tất cả bộ lọc ý định UIR đã xác thực thành công làm trình xử lý ứng dụng mặc định cho các 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 quá trình 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 cung cấp cho người dùng khả nă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

Việc 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 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 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 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 quá trình triển khai thiết bị báo cáo android.software.home_screen [Tài nguyên, 10]
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 quá trình triển khai thiết bị báo cáo android.hardware.telephony [Tài nguyên, 11]
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 [Tài nguyên, 10]

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

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

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 được phân tách bằng dấu phẩy của các ABI được sắp xếp từ ưu tiên nhất đến ít ưu tiên nhất
BẮT BUỘC 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 [Tài nguyên, 12] và BẮT BUỘC hỗ trợ tiện ích SIMD nâng cao (còn gọi là NEON) [Tài nguyên, 13]
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

Các API mã gốc sau đây PHẢI có sẵn cho các ứng dụng có mã gốc:

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

Xin lưu ý rằng các bản phát hành Android NDK trong tương lai 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 một 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.

Xin lưu ý rằng việc triển khai thiết bị PHẢI bao gồm libGLESv3.so và PHẢI liên kết tượng trưng (symbolic link) với libGLESv2.so. Đổi lại, 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 [Tài nguyên, 14] như được xác định trong bản phát hành NDK android-21. 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 đủ.

Các hoạt động triển khai thiết bị, nếu bao gồm một thư viện gốc có tên libvulkan.so, KHÔNG ĐƯỢC xuất các biểu tượng hàm và cung cấp hoạt động triển khai API Vulkan 1.0 cũng như các tiện ích VK_KHR_surface, VK_KHR_swapchain và VK_KHR_android_surface do Khronos Group xác định và vượt qua các bài kiểm thử tuân thủ Khronos.

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 của các thư viện nêu trên từ Dự án nguồn mở Android ngược dòng.

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 phương thức triển khai đầy đủ của API android.webkit.WebView và KHÔNG được báo cáo trên các thiết bị không triển khai đầy đủ API này. Quá trình triển khai Android Open Source sử dụng mã từ Dự án Chromium để triển khai android.webkit.WebView [Tài nguyên, 15]. 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 6.0. 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 [Tài nguyên, 16].
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 [Tài nguyên, 17].

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 thượng nguồn hay ứng dụng thay thế của bên thứ ba) PHẢI hỗ trợ nhiều HTML5 [Tài nguyên, 17] 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:

bộ nhớ đệm của ứng dụng/hoạt động ngoại tuyến [Tài nguyên, 18]
thẻ <video> [Tài nguyên, 19]
thông tin vị trí [Tài nguyên, 20]

Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ API webstorage HTML5/W3C [Tài nguyên, 21] và NÊN hỗ trợ API IndexedDB HTML5/W3C [Tài nguyên, 22]. 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 một 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 [Tài nguyên, 2]. 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 tra tính tương thích (CTS) kiểm tra một số phần quan trọng của nền tảng để biết 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ý bằng 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 các 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 hiển thị 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 một 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ó thể 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 Android để chỉ những ứng dụng sử dụng rõ ràng các API đó (thông qua cơ chế lt;uses-librarygt;) 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 tiêu chuẩn để đặt tên cho API trong ngôn ngữ lập trình Java; mục này chỉ nhằm củng cố các quy ước đó và 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 có thể thực thi Dalvik (DEX) đầy đủ cũng như thông số kỹ thuật và ngữ nghĩa của mã byte Dalvik [Tài nguyên, 23]. 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 môi trường thời gian chạy Dalvik để phân bổ bộ nhớ theo nền tảng Android thượng nguồn và theo 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 bên thứ ba để thay thế trình chạy thiết bị (màn hình chính). Các hoạt động triển khai thiết bị cho phép ứng dụng bên thứ ba thay thế màn hình chính của thiết bị PHẢI khai báo tính năng nền tảng android.software.home_screen.

3.8.2. Tiện ích

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

Android xác định một loại thành phần và API và vòng đời tương ứng cho phép các ứng dụng hiển thị "AppWidget" cho người dùng cuối [Tài nguyên, 24] một tính năng mà bạn NÊN HỖ TRỢ trên các hoạt động triển khai 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 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 trong 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 SDK Android [Tài nguyên, 24] để 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 bao gồm 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ú ý [Tài nguyên, 25], 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ợ thông báo sử dụng các tính năng phần cứng, như mô tả trong tài liệu SDK và trong phạm vi có thể với phần cứng triển khai thiết bị. Ví dụ: nếu 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 quá trình triển khai thiết bị thiếu phần cứng, thì các API tương ứng PHẢI được triển khai dưới dạng không hoạt động. Hành vi này được mô tả chi tiết hơn trong phần 7.

Ngoài ra, quá trình triển khai PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp ảnh động, v.v.) được cung cấp trong API [Tài nguyên, 26] hoặc trong hướng dẫn về kiểu biểu tượng Thanh trạng thái/Thanh hệ thống [Tài nguyên, 27]. Trong trường hợp thiết bị Android TV, 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.

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 đa dạng thức 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 [Tài nguyên, 28].

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.

3.8.4. Tìm kiếm

Android bao gồm các API [Tài nguyên, 29] 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 vào 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 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ọ, đồng thời 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. Các hoạt động 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 các ứ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.

Việc triển khai thiết bị Android PHẢI triển khai một trợ lý trên thiết bị để xử lý thao tác Hỗ trợ [Tài nguyên, 30].

Android cũng bao gồm các 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ị [Tài nguyên, 31]. 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.

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, các chuỗi này sẽ biến mất sau một khoảng thời gian ngắn [Tài nguyên, 32]. 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 giao diện và cảm giác của giao diện Holo như được xác định bởi SDK Android [Tài nguyên, 33]. 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 được hiển thị cho các ứng dụng [Tài nguyên, 34].

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 và cảm nhậ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 [Tài nguyên, 35].

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 [Tài nguyên, 34].

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 cách triển khai thiết bị. Do đó, việc triển khai thiết bị Android KHÔNG ĐƯỢC sử dụng màu trắng cho biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) và thông báo do hệ thống đưa ra, trừ phi biểu tượng đ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ách sử dụ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 các biểu tượng trạng thái hệ thống thành màu đen [Tài nguyên, 34].

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

Android xác định một loại thành phần và API và vòng đời tương ứng cho phép các ứng dụng hiển thị một hoặc nhiều "Hình nền động" cho người dùng cuối [Tài nguyên, 36]. 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 hoạt động 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 hàm Gần đây là KHÔNG BẮT BUỘC, nên các yêu cầu để triển khai màn hình tổng quan là KHÔNG BẮT BUỘC đối với thiết bị Android Television và thiết bị Android Watch.

Mã nguồn Android ngược dòng bao gồm màn hình tổng quan [Tài nguyên, 37], 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 hiển thị các video gần đây được liên kết dưới dạng một nhóm di chuyển cùng nhau.
PHẢI hỗ trợ tối thiểu 6 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.
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.
PHẢI triển khai hành vi ghim màn hình [Tài nguyên, 38] 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ộ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.

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ợ tính năng Quản lý phương thức nhập và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba [Tài nguyên, 39]. 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 mà thay vào đó là Mẫu thông báo nội dung nghe nhìn cho phép các ứng dụng nội dung nghe nhìn tích hợp với các chế độ điều khiển phát hiển thị trên màn hình khoá [Tài nguyên, 40] dưới dạng thông báo Màn hình khoá. Việc triển khai thiết bị PHẢI hiển thị đúng Mẫu thông báo đa phương tiện trong thông báo trên màn hình khoá như mô tả trong phần 3.8.3.

3.8.11. Giấc mơ

Android hỗ trợ trình bảo vệ màn hình tương tác có tên là Dreams [Tài nguyên, 41]. Dreams cho phép người dùng tương tác với các ứng dụng khi thiết bị được kết nối với nguồn điện ở trạng thái rảnh hoặc được gắn vào đế sạc trên bàn. Các thiết bị Android Watch CÓ THỂ triển khai Dreams, nhưng các loại triển khai thiết bị khác PHẢI hỗ trợ Dreams và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình Dreams nhằm phản hồi ý đị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 tọa độ vị trí, các chế độ vị trí PHẢI hiển thị trong trình đơn Vị trí trong phần Cài đặt [Tài nguyên, 42].

3.8.13. Unicode và phông chữ

Android hỗ trợ các ký tự biểu tượng cảm xúc có màu. Khi quá trình triển khai thiết bị Android bao gồm một 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 được xác định trong Unicode 6.1 [Tài nguyên, 43]. Tất cả 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.

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.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 API Quản trị thiết bị Android [Tài nguyên, 44]. Việc triển khai thiết bị PHẢI cung cấp cách triển khai lớp DevicePolicyManager [Tài nguyên, 45]. Các phương thức triển khai thiết bị hỗ trợ màn hình khoá dựa trên PIN (số) hoặc MẬT KHẨU (chữ và số) PHẢI hỗ trợ 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 [Tài nguyên, 44] 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ì quy trình thiết lập ngay từ đầu PHẢI cho phép đăng ký ứng dụng Trình kiểm soát chính sách thiết bị (DPC) làm ứng dụng Chủ sở hữu thiết bị [ Tài nguyên, 46]. 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ị.

Trải nghiệm người dùng trong quy trình cấp phép của chủ sở hữu thiết bị (quy trình do android.app.action.PROVISION_MANAGED_DEVICE [ Tài nguyên, 47] khởi tạo) PHẢI phù hợp với cách triển khai AOSP

Nếu quá trình triển khai thiết bị báo cáo android.hardware.nfc, thì thiết bị PHẢI bật NFC, ngay cả trong quy trình thiết lập ngay khi xuất xưởng, để cho phép cấp phát NFC cho Chủ sở hữu thiết bị [Tài nguyên, 48].

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 [ Tài nguyên, 49]

Trải nghiệm người dùng trong quy trình cấp phát hồ sơ được quản lý (luồng do android.app.action.PROVISION_MANAGED_PROFILE [ Tài nguyên, 50]) bắt đầu) PHẢI phù hợp với cách triển khai AOSP

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 mục 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 các API android.app.admin.DevicePolicyManager
Cho phép tạo một và chỉ một hồ sơ được quản lý [Tài nguyên, 50]
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 gắn 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 chức năng sau đây cho người dùng đối với 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 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 hồ sơ người dùng chính hoặc hồ sơ được quản lý.
- Quản lý độc lập các tài khoản trong người dùng chính hoặc hồ sơ được quản lý.
Đảm bảo trình quay số mặc định có thể tra cứu thông tin về người gọi từ hồ sơ được quản lý (nếu có) cùng với thông tin từ hồ sơ chính, nếu Trình điều khiển chính sách thiết bị cho phép.
PHẢI đảm bảo rằng hồ sơ này đá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 được bật (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.

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 người dùng và sự kiện hệ thống, đồng thời tạo 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 [Tài nguyên, 51].

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.
Việc triển khai thiết bị (ngoại trừ Android Automotive) PHẢI cung cấp cách triển khai khung hỗ trợ tiếp cận Android nhất quán với cách 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 các API android.accessibilityservice [Tài nguyên, 52]
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 đến 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 một cơ chế mà người dùng có thể truy cập để bật và tắt các dịch vụ hỗ trợ tiếp cận, đồng thời PHẢI hiển thị giao diện này để phản hồi ý định android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Ngoài ra, quá trình triển khai thiết bị PHẢI cung cấp việc triển khai dịch vụ hỗ trợ tiếp cận trên thiết bị và PHẢI cung cấp cơ chế để người dùng bật dịch vụ hỗ trợ tiếp cận trong quá trình thiết lập thiết bị. Bạn có thể tham khảo cách triển khai dịch vụ hỗ trợ tiếp cận nguồn mở trong dự án Eyes Free [Tài nguyên, 53].

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

Android bao gồm các API cho phép ứng dụng sử dụng dịch vụ chuyển văn bản sang lời nói (TTS) và cho phép nhà cung cấp dịch vụ cung cấp các phương thức triển khai dịch vụ TTS [Tài nguyên, 54]. Các hoạt động triển khai thiết bị báo cáo tính năng android.hardware.audio.output ĐẢM BẢO đá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 để cho phép người dùng 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 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ợ việc 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 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 [Tài nguyên, 55].

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 PHẢI có ứng dụng TV (Ứng dụng TV) được cài đặt. Dự án nguồn mở Android cung cấp cách triển khai Ứng dụng TV.

Ứng dụng TV mặc định phải cung cấp quyền truy cập vào các kênh từ các đầu vào đã cài đặt và đầu vào của bên thứ ba. Xin lưu ý rằng các dữ liệu đầu vào đã cài đặt bao gồm tất cả dữ liệu đầu vào được cung cấp theo mặc định, cho dù dữ liệu đầu vào đó có dựa trên TIF hay không.

Ứng dụng TV PHẢI cung cấp các cơ sở để cài đặt và sử dụng Kênh TV [Tài nguyên, 56] và đá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ý dữ liệu đầu vào dựa trên TIF của bên thứ ba (dữ liệu đầu vào của bên thứ ba) [Tài nguyên, 57] .
Việc triển khai thiết bị CÓ THỂ phân tách trực quan giữa dữ liệu đầu vào dựa trên TIF được cài đặt sẵn (dữ liệu đầu vào đã cài đặt) [Tài nguyên, 58] và dữ liệu đầu vào 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 rời khỏi Ứ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 [Tài nguyên, 59]. 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 đầu vào của bên thứ ba cách các đầu vào đã cài đặt trên EPG nhiều hơn một thao tác điều hướng.
Khi thay đổi kênh, việc 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

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) PHẢI cho phép điều hướng đến tất cả các phần có thể thao tác trên màn hình thông qua D-pad. BẮT BUỘC phải sử dụng D-pad lên và xuống để thay đổi các kênh truyền hình trực tiếp khi không có phần có thể thao tác trên màn hình.

Ứ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) [Tài nguyên, 60]. Ứ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.

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 [Tài nguyên, 61].

Việc triển khai thiết bị KHÔNG ĐƯỢC mở rộng tệp .apk [Tài nguyên, 62], Tệp kê khai Android [Tài nguyên, 49], mã byte Dalvik [Tài nguyên, 23] hoặc định dạng 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.

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

Việc triển khai thiết bị PHẢI hỗ trợ các định dạng nội dung nghe nhìn cốt lõi được chỉ định trong tài liệu SDK Android [Tài nguyên, 64] ngoại trừ những trường hợp được phép rõ ràng trong tài liệu này. Cụ thể, việc triển khai thiết bị 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 [Tài nguyên, 65]. Việc triển khai thiết bị cũng PHẢI có thể giải mã tất cả hồ sơ được báo cáo trong CamcorderProfile [Tài nguyên, 66] và PHẢI có thể giải mã tất cả định dạng mà thiết bị có thể mã hoá. Tất cả các bộ mã hoá và giải mã này đều được cung cấp dưới dạng phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên từ Dự án nguồn mở Android.

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

5.1.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.
Cấu hình 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)

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 Chỉ cần hỗ trợ nội dung 5.0/5.1 xuống âm thanh nổi; không bắt buộc phải ghi hoặc kết xuất nhiều hơn 2 kênh.

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)

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

Đị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	BẮT BUỘC¹	BẮT BUỘC²		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) [Tài nguyên, 67 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) [Tài nguyên, 67] 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 trong [Tài nguyên, 68].

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.

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

Việc 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 và các hồ sơ mã hoá video SD (Độ phân giải chuẩn) sau đây, đồng thời NÊN hỗ trợ Hồ sơ chính cấp 4 và các hồ sơ mã hoá video HD (Độ phân giải cao) sau đây. 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.

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.

Việc triển khai thiết bị PHẢI hỗ trợ độ phân giải video động và chuyển đổi tốc độ khung hình thông qua các API Android tiêu chuẩn trong cùng một luồng cho tất cả 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ị.

Việc triển khai thiết bị Android bằng bộ giải mã H.263 PHẢI hỗ trợ Cấu hình cơ sở cấp 30.

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

Việc 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à các hồ sơ giải mã video SD sau đây, đồng thời NÊN hỗ trợ các hồ sơ giải mã HD. Thiết bị Android Television PHẢI hỗ trợ Cấu hình cao cấp cấp 4.2 và cấu hình giải mã HD 1080p.

	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.

Việc triển khai 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 sau đây và NÊN hỗ trợ các hồ sơ giải mã HD. Thiết bị Android Television PHẢI hỗ trợ hồ sơ giải mã HD 1080p.

	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.

Khi triển khai thiết bị Android, nếu hỗ trợ bộ mã hoá và giải mã VP9 như mô tả trong mục 5.1.3, thì PHẢI hỗ trợ các hồ sơ giải mã video SD sau đây và NÊN hỗ trợ các hồ sơ giải mã HD. Các thiết bị Android Television KHUYẾN KHÍCH mạnh mẽ hỗ trợ hồ sơ giải mã HD 1080p và PHẢI hỗ trợ hồ sơ giải mã UHD. Khi hồ sơ giải mã video UHD được hỗ trợ, hồ sơ này 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	60 khung hình/giây	60 khung hình/giây
Tốc độ bit của video	600 Kb/giây	1,6 Mb/giây	4 Mb/giây	5 Mb/giây	20 Mb/giây

1 Bắt buộc đối với việc triển khai thiết bị Android TV, nhưng chỉ đối với các loại thiết bị khác khi phần cứng hỗ trợ.

2 NÊN DÙNG cho các phương thức triển khai thiết bị Android TV hiện có khi phần cứng hỗ trợ.

Khi triển khai thiết bị Android, nếu hỗ trợ bộ mã hoá và giải mã H.265 như mô tả trong mục 5.1.3, THÌ PHẢI hỗ trợ cấp Main Profile cấp 3 và các cấu hình giải mã video SD sau đây, đồng thời NÊN hỗ trợ các cấu hình giải mã HD. Bạn NÊN hỗ trợ hồ sơ giải mã UHD và hồ sơ giải mã HD 1080p cho các thiết bị Android Television. 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. Nếu hỗ trợ giải mã UHD, thì tính năng này 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	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	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	10 Mb/giây	20 Mb/giây

1 Bắt buộc đối với việc triển khai thiết bị Android TV, nhưng chỉ đối với các loại thiết bị khác khi phần cứng hỗ trợ.

2 NÊN triển khai cho các thiết bị Android Television hiện có khi phần cứng hỗ trợ.

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 cho 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
Số 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

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 NÊN đặt độ nhạy đầu vào âm thanh sao cho nguồn 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ô.
Tổng độ méo hài NÊN nhỏ hơn 1% đối với 1 kHz ở mức đầu vào 90 dB SPL tại micrô.
BẠN PHẢI tắt tính năng xử lý giảm tiếng ồn (nếu có).
BẮT BUỘC 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 giọng nói, thì bạn PHẢI có thể kiểm soát hiệu ứng này từ API android.media.audiofx.NoiseSuppressor. Hơn nữa, trường UUID cho mô tả hiệu ứng của trình giảm nhiễu PHẢI xác định duy nhất từng phương thức triển khai của công nghệ giảm nhiễu.

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
Số kênh: Đơn âm, Âm thanh nổi

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

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

5.5.2. Hiệu ứng âm thanh

Android cung cấp một API cho các hiệu ứng âm thanh để triển khai thiết bị [Tài nguyên, 69]. 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ợ các hoạt động triển khai EFFECT_TYPE_EQUALIZER và EFFECT_TYPE_LOUDNESS_ENHANCER có thể kiểm soát thông qua các lớp con AudioEffect Equalizer, 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 Visualizer.
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 bao gồm tính năng 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 giải mã âm thanh trên thiết bị).

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 trình nghe bên ngoài có thể nghe thấy âm thanh tương ứng hoặc khi bộ chuyển đổi quan sát thấy âm thanh tương ứng.
Độ trễ đầu ra nguội. Độ trễ đầu ra cho khung hình đầu tiên, khi hệ thống đầu ra âm thanh ở trạng thái rảnh và tắt nguồn trước khi 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 bên ngoài được hiển thị cho thiết bị và thời điểm ứng dụng đọc khung tương ứng của dữ liệu được mã hoá PCM.
Độ trễ đầu vào nguội. Tổng thời gian nhập bị mất và độ trễ đầu vào cho khung đầu tiên, khi hệ thống nhập âm thanh ở trạng thái rảnh và tắt nguồn trước khi 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. Độ lệch 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. Độ lệch 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 chu kỳ bộ đệm. Khoảng thời gian của vùng đệm cho phép thời gian xử lý cho ứng dụng và để ứ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; xem NDK_root/docs/opensles/index.html.

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

độ trễ đầu ra nguội từ 100 mili giây trở xuống
độ trễ đầu ra liên tục 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ợ, 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 [Tài nguyên, 70]. 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 đa phương tiện để phát âm thanh và video như được chỉ định trong tài liệu SDK Android [Tài nguyên, 64]. Cụ thể, thiết bị PHẢI hỗ trợ các giao thức mạng đa phương tiện sau:

RTSP (RTP, SDP)
Truyền phát tiến bộ qua HTTP(S)
Giao thức dự thảo Phát trực tuyến HTTP(S), Phiên bản 3 [Tài nguyên, 71]

5.8. Secure Media

Các hoạt động 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 các phương thức đó 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 cho 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 việc hỗ trợ màn hình không dây (Miracast) và màn hình có dây (HDMI) đáp ứng yêu cầu này.

5.9. Giao diện kỹ thuật số 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 [Tài nguyên, 70].

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)

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.

MIDI qua Bluetooth LE đóng vai trò trung tâm (mục 7.4.3 Bluetooth) đang ở trạng thái sử dụng thử. Việc triển khai thiết bị báo cáo tính năng android.software.midi và cung cấp khả năng kết nối chung không phải MIDI qua Bluetooth LE, PHẢI hỗ trợ MIDI qua Bluetooth LE.

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 tính năng hỗ trợ android.hardware.audio.pro thông qua lớp android.content.pm.PackageManager [Tài nguyên, 70].

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 chiều đi và về PHẢI là 20 mili giây trở xuống trên đường dẫn giắc cắm âm thanh và NÊN là 10 mili giây trở xuống 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ị KHÔNG ĐƯỢC làm mất độ sâu bit hoặc lấy mẫu lại mà 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.
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 triển khai thiết bị theo phần Quy cách của thiết bị di động (giắc) trong Quy cách của tai nghe âm thanh có dây (phiên bản 1.1).

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) [Tài nguyên, 72]

Việc triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được ghi lại trong SDK Android, bao gồm cả dumpsys [Tài nguyên, 73]. Theo mặc định, trình nền adb phía thiết bị PHẢI ở trạng thá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 bật 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) [Tài nguyên, 74]

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 theo mặc định sẽ KHÔNG hoạt động, nhưng PHẢI được hỗ trợ bất cứ khi nào người dùng kích hoạt Cầu gỡ lỗi Android, như trên.

Monkey [Tài nguyên, 75]

Việc 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 [Tài nguyên, 76]

Việc triển khai thiết bị PHẢI hỗ trợ công cụ systrace như được ghi lại trong SDK Android. Theo mặc định, Systrace phải ở trạng thá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 tùy chỉnh cho hệ thống Windows.) Nếu công cụ adb không nhận dạng được cách 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 [Tài nguyên, 77]. 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.

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 lớp đầy đủ (như được ghi lại trong SDK) 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.
Các 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. [Tài nguyên, 70]

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

Android bao gồm các cơ sở tự động điều chỉnh các thành phần ứng dụng và bố cục giao diện người dùng sao 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 [Tài nguyên, 78]. 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: pixel = dp * (mật độ/160).

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

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

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

Khung giao diện người dùng Android hỗ trợ nhiều kích thước màn hình và cho phép các ứng dụng truy vấn kích thước màn hình thiết bị (còn gọi là "bố cục màn hình") thông qua android.content.res.Configuration.screenLayout với SCREENLAYOUT_SIZE_MASK. Việc triển khai thiết bị PHẢI báo cáo kích thước màn hình chính xác như được xác định trong tài liệu SDK Android [Tài nguyên, 78] 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 kích thước màn hình chính xác theo các kích thước màn hình pixel không phụ thuộc vào mật độ logic (dp) sau đây.

Thiết bị PHẢI có kích thước màn hình tối thiểu là 426 dp x 320 dp ("nhỏ"), trừ khi đó 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.
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ối thiểu là 2,5 inch.

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

Các ứng dụng có thể 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 tính năng hỗ trợ đã nêu của ứng dụng 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 SDK Android.

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

Thiết bị Android Watch CÓ THỂ có tỷ lệ khung hình là 1.0 (1:1).

Tỷ lệ khung hình màn hình PHẢI là một giá trị từ 1,3333 (4:3) đến 1,86 (khoảng 16:9), nhưng các thiết bị Android Watch CÓ THỂ có tỷ lệ khung hình là 1,0 (1:1) vì việc triển khai thiết bị như vậy sẽ sử dụng UI_MODE_TYPE_WATCH làm android.content.res.Configuration.uiMode.

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. Việc triển khai thiết bị KHÔNG ĐƯỢC báo cáo nhiều hơn một trong các mật độ khung Android logic sau đây thông qua API android.util.DisplayMetrics, đồng thời KHÔNG ĐƯỢC thực thi ứng dụng ở mật độ chuẩn này và KHÔNG ĐƯỢC thay đổi giá trị bất cứ lúc nào cho màn hình mặc định.

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

Việc triển khai thiết bị PHẢI xác định mật độ khung Android tiêu chuẩn gần nhất về mặt số học với mật độ 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.

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ố hiển thị được xác định trong android.util.DisplayMetrics [Tài nguyên, 79] 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 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, 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 của ứng dụng theo hướng màn hình dọc hoặc ngang. Tức là thiết bị phải tuân theo yêu cầu của ứng dụng về hướng màn hình cụ thể. 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à trình bày chi tiết trong tài liệu về SDK Android. Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 3.0 hoặc 3.1 trên các thiết bị có thể hỗ trợ. Các hoạt động 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 về SDK Android [Tài nguyên, 80].

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 hoặc OpenGL 3.1. Đó 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ợ cho 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 hoặc 3.1 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 hoạt động triển khai thiết bị khai báo hỗ trợ OpenGL ES 3.0 hoặc 3.1, 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.

Ngoài OpenGL ES 3.1, Android còn cung cấp một gói mở rộng có giao diện Java [Tài nguyên, 81] và hỗ trợ gốc cho chức năng đồ hoạ nâng cao như tạo hình tam giác và định dạng nén kết cấu ASTC. Việc triển khai thiết bị Android CÓ THỂ hỗ trợ gói tiện ích này và – chỉ khi triển khai đầy đủ – PHẢI xác định tính 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 các 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 ứng dụ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 dành riêng cho 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 bao gồm một cơ chế để các ứng dụng khai báo rằng chúng muốn bật tính năng tăng tốc phần cứng cho đồ hoạ 2D ở cấp Ứng dụng, Hoạt động, Cửa sổ hoặc Chế độ xem thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp [Tài nguyên, 82].

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, việc 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 [Tài nguyên, 82].

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 cách 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ợ phần mở rộng EGL_ANDROID_RECORDABLE [Tài nguyên, 83].

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ệ hiển thị đượ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 pixel PHẢI gần vuông (1, 0) với dung sai từ 10 đến 15%.

7.1.7. Màn hình phụ

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

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

Thiết bị PHẢI hỗ trợ màn hình cảm ứng hoặc đáp ứng các yêu cầu nêu trong 7.2.2 đố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ư mô tả 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 [Tài nguyên, 85] (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 phương thức triển khai thiết bị 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 [Tài nguyên, 85].
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 thao tác đ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 (liên kết với các sự kiện chính KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK tương ứng) 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 Màn hình chính và chức năng Quay lại, ngoại trừ khi ở chế độ UI_MODE_TYPE_WATCH.
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ách sử dụ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 hàm này PHẢI truy cập được bằng một thao tác duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi hiển thị.

Hàm Gần đây (nếu có) 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 Trang chủ 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 đi kèm với Android 6.0 trở lên KHÔNG ĐƯỢC triển khai nút vật lý chuyên dụng cho hàm Trình đơn. Các phương thứ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 hàm 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ì phương thức triển khai thiết bị sẽ:

PHẢI hiển thị nút trình đơn mục bổ sung hành động trên thanh hành động khi nút này hiển thị và trình đơn mục bổ sung hành động bật lên không để trống. Đối với việc triển khai thiết bị được phát hành trước Android 4.4 nhưng nâng cấp lên Android 6.0, bạn NÊN làm như vậy.
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Ể hiển thị cửa sổ bật lên cho thao tác bổ sung ở 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ừ khi 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 có hỗ trợ thao tác Hỗ trợ [Tài nguyên, 30] PHẢI cho phép truy cập bằng một thao tác duy nhất (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ị và ĐỀ XUẤT NÊN sử dụng thao tác nhấn và giữ nút Màn hình chính hoặc phím phần mềm làm thao tác duy nhất.

Việc 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.
Việc 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ồ sơ thấp" (ví dụ: chế độ 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 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ó bao gồm hệ thống nhập con trỏ:

NÊN hỗ trợ con trỏ được theo dõi hoàn toàn độc lập, nếu hệ thống 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ài nguyên, 85] 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ả. Việc triển khai thiết bị dựa trên màn hình cảm ứng được liên kết với màn hình [Tài nguyên, 86] để 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 hỗ trợ 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 mà 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 trỏ hoặc lấy nét trước rồi mới nhấp. Nhiều thiết bị đầu vào như chuột, bàn di chuột, chuột không dây dựa trên con quay hồi chuyển, con trỏ con quay hồi chuyển, cần điều khiển và bàn di chuột cảm ứng đa điểm có thể hỗ trợ các hoạt động tương tác giả mạo bằng thao tác chạm. Android bao gồm hằng số tính năng android.hardware.faketouch, tương ứng với một thiết bị đầu vào không 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 chạm giả PHẢI đáp ứng các yêu cầu về tính năng chạm 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 phương thức 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 [Tài nguyên, 87].
PHẢI báo cáo sự kiện chạm bằng mã thao tác chỉ định thay đổi trạng thái xảy ra khi con trỏ di chuyển xuống hoặc lên trên màn hình [Tài nguyên, 87].
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 vào một đối tượng trên màn hình [Tài nguyên, 87].
PHẢI hỗ trợ con trỏ xuống tại một điểm tuỳ ý trên màn hình, con trỏ di chuyển đến bất kỳ điểm tuỳ ý nào khác trên màn hình, theo sau là con trỏ 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 sang 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 KHÔNG ĐƯỢC đáp ứng các yêu cầu đối với faketouch ở trên và cũng KHÔNG ĐƯỢC hỗ trợ tính năng theo dõi riêng biệt của hai hoặc nhiều đầu vào con trỏ độc lập.

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

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

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)
Bàn phím di chuyển lên¹ Bàn phím di chuyển xuống¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad trái1 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 [Tài nguyên, 88]

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ồ, đi 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 [Tài nguyên, 87]

Đ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 [Tài nguyên, 87]

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 có thể truy cập được từ điện thoại di động hoặc máy tính bảng. Điều khiển từ xa PHẢI đáp ứng các yêu cầu được xác định bên dưới.

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 [Tài nguyên, 88].

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ảm biến [Tài nguyên, 89]. 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 [Tài nguyên, 70].
PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự.
PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về giá trị true hoặc false khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.).
PHẢI báo cáo tất cả các phép đo cảm biến bằng cách sử dụng các giá trị Hệ thống đơn vị quốc tế (tiêu chuẩn) liên quan cho từng loại cảm biến như được xác định trong tài liệu SDK Android [Tài nguyên, 90].
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, đại diện cho thời gian xảy ra sự kiện và được đồng bộ hoá với đồng hồ SystemClock.elapsedRealtimeNano(). Cá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ể trở thành một thành phần BẮT BUỘC. Lỗi đồng bộ hoá PHẢI dưới 100 mili giây [Tài nguyên, 91].
PHẢI báo cáo dữ liệu cảm biến với độ trễ tối đa là 100 mili giây + 2 * sample_time đối với trường hợp 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ảm biến [Tài nguyên, 89] được coi là có thẩm quyền.

Một số loại cảm biến là tổng hợp, nghĩa là chúng có thể được lấy từ dữ liệu do một hoặc nhiều cảm biến khác cung cấp. (Ví dụ: cảm biến hướng và cảm biến gia tốc tuyến tính.) Việc triển khai thiết bị PHẢI 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 [Tài nguyên, 92]. Nếu quá trình triển khai thiết bị bao gồm một cảm biến tổng hợp, thì thiết bị đó PHẢI triển khai cảm biến như mô tả trong tài liệu nguồn mở Android về cảm biến tổng hợp [Tài nguyên, 92].

Một số cảm biến Android hỗ trợ chế độ kích hoạt "liên tục", chế độ này sẽ liên tục trả về dữ liệu [Tài nguyên, 93]. Đố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ỳ, MÀ PHẢI 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 thức dậy 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 RẤT NÊN đưa cảm biến này vào thiết bị cầm tay Android và thiết bị đồng hồ Android. 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 [Tài nguyên, 94].
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 các thiết bị Android Watch vì các thiết bị đó 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 [Tài nguyên, 90].
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 chỉnh 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 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ất kỳ cảm biến nào trong số này được triển khai, tổng mức tiêu thụ điện năng của chúng 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 một thiết bị có chứa con quay hồi chuyển 3 trục, thì thiết bị đó:

PHẢI triển khai cảm biến TYPE_MAGNETIC_FIELD và CŨNG NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED. Bạn NÊN triển khai cảm biến TYPE_MAGNETIC_FIELD_UNCALIBRATED trên 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 với tần suất tối thiểu là 10 Hz và NÊN báo cáo các sự kiện với 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 [Tài nguyên, 90].
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 tạo ra) và trường từ tĩnh (do nam châm tạo ra).
PHẢI có độ phân giải bằng hoặc lớn hơn 0,6 µT và NÊN có độ phân giải bằng hoặc lớn hơn 0,2 µ.
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 tham 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 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, 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ảm biến được đăng ký cho chế độ hàng loạt ở tần số 10 Hz.

7.3.3. GPS

Việc triển khai thiết bị PHẢI bao gồm một bộ thu GPS. Nếu việc triển khai thiết bị có bao gồm bộ thu GPS, thì thiết bị đó PHẢI bao gồm một số hình thức kỹ thuật "GPS hỗ trợ" để giảm thiểu thời gian khoá GPS.

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ó độ lệch không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (độ lệch trên mỗi Hz, hoặc rad^2 / s). Độ 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 này 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.

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. Các thiết bị có thể thực hiện cuộc gọi thoại và cho biết bất kỳ giá trị nào khác 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 đang được người dùng 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ì 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ả 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à 200 Hz trở lên
- PHẢI có độ nhiễu đo lường không vượt quá 400uG/√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ụ năng lượng theo lô không tệ hơn 3 mW
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 nhất 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à 200 Hz trở lên
- PHẢI có độ nhiễu đo lường không vượt quá 0,014°/giây/√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ùng các yêu cầu về chất lượng với 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 1.100 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 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ụ năng lượng theo lô không tệ hơn 2 mW
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ị ở trạng thái tĩnh 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 cao hơn 0,5 mW khi thiết bị ở trạng thái tĩnh và 1,5 mW khi thiết bị đang di chuyển
- PHẢI có mức tiêu thụ năng lượ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ị ở trạng thái tĩnh 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ị ở trạng thái tĩnh 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 của máy ảnh và nằm trong phạm vi sai số 1 mili giây.
Độ trễ của việc phân phối mẫu đến HAL PHẢI dưới 5 mili giây kể từ thời điểm dữ liệu có sẵn trên phần cứng cảm biến thực.
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ả nguồn điện do toàn bộ chuỗi cảm biến tiêu thụ – cảm biến, mọi mạch 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 quá trình 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 đây:

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 [Tài nguyên, 95].
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%, theo đ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 việc so khớp vân tay trong Môi trường thực thi đáng tin cậy (TEE) hoặc trên 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 để 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 [Tài nguyên, 96].
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/hình mở khoá/mật khẩu) do TEE bảo mật; việc triển khai Dự án nguồn mở Android cung cấp cơ chế trong khung để thực hiện việc này.
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.4. Kết nối dữ liệu

7.4.1. Điện thoại

"Điện thoại" mà các API Android và tài liệu này sử dụng đề 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 các cuộc gọi thoại và SMS. Ví dụ: các phương thức triển khai thiết bị không thể thực hiện cuộc gọi hoặc gửi/nhận tin nhắn SMS KHÔNG ĐƯỢC 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ị có bao gồm đ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ệ đó. Các hoạt động 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.2. IEEE 802.11 (Wi-Fi)

Việc triển khai thiết bị Android Television PHẢI hỗ trợ Wi-Fi.

Việc triển khai thiết bị Android Television PHẢI hỗ trợ một hoặc nhiều dạng 802.11 (b/g/a/n, v.v.) và các loại triển khai thiết bị Android khác PHẢI hỗ trợ một hoặc nhiều dạng 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 API đa điểm như mô tả trong tài liệu SDK [Tài nguyên, 97].
PHẢI hỗ trợ DNS đa địa chỉ (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) tại bất kỳ thời điểm hoạt động nào, bao gồm:
- Ngay cả khi màn hình không ở trạng thái đ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 việc triển khai thiết bị có hỗ trợ Wi-Fi Direct, thì thiết bị đó PHẢI triển khai API Android tương ứng như mô tả trong tài liệu SDK [Tài nguyên, 98]. 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ị Android Television PHẢI hỗ trợ tính năng Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS).

Việc triển khai thiết bị Android Television PHẢI hỗ trợ tính năng Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi (TDLS) và các loại triển khai thiết bị Android khác PHẢI hỗ trợ tính năng TDLS Wi-Fi như mô tả trong Tài liệu SDK Android [Tài nguyên, 99]. Nếu việc triển khai thiết bị có hỗ trợ TDLS và TDLS được WiFiManager API bật, 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 khi đi qua điểm truy cập Wi-Fi.

7.4.3. Bluetooth

Việc triển khai Android Watch và Automotive PHẢI hỗ trợ Bluetooth. Các phương thức triển khai Android Television PHẢI hỗ trợ Bluetooth và Bluetooth LE.

Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp [Tài nguyên, 100]. 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 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. sao cho phù hợp với thiết bị. Việc triển khai thiết bị Android Television PHẢI hỗ trợ Bluetooth và Bluetooth LE.

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à [Tài nguyên, 100].
NÊN triển khai thời gian chờ Đị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 chuyển logic lọc sang chipset Bluetooth khi triển khai API ScanFilter [Tài nguyên, 101] và PHẢI báo cáo chính xác giá trị của vị trí triển khai logic lọc 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 quá trình 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.BluetoothAdapater.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ợ, KHÔNG ĐƯỢC báo cáo "false" 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 tính năng 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() [Tài nguyên, 70].
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 báo 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 bên dưới được nêu là ĐỀ XUẤT MẠNH, 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 Thinfilm [Tài nguyên, 102].
- 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 [Tài nguyên, 103]
  - SNEP 1.0 (do NFC Forum xác định)
- PHẢI hỗ trợ Android Beam [Tài nguyên, 104]:
  - 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. Khi tắt tính năng Android Beam trong phần cài đặt, bạn 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 [Tài nguyên, 105].
  - PHẢI triển khai máy chủ NPP. Các 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, và android.nfc.NfcAdapter.setNdefPushMessageCallback, và android.nfc.NfcAdapter.enableForegroundNdefPush.
  - NÊN sử dụng cử chỉ hoặc xác nhận trên màn hình, chẳng hạn như "Chạm để 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" [Tài nguyên, 106] và "Ghép nối đơn giản và an toàn qua Bluetooth bằng NFC phiên bản 1.0" [Tài nguyên, 107] của NFC Forum. Việc triển khai như vậy PHẢI triển khai dịch vụ LLCP chuyển đổi với 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 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 với màn hình 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 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 định tuyến HCE và 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ợ các API NFC HCE như được xác định trong SDK Android [Tài nguyên, 108].

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

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() [Tài nguyên, 70]. 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() [Tài nguyên, 70] và PHẢI triển khai API NFC của Android 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ị trong đó 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 bao gồm một ngăn xếp mạng IPv6 và hỗ trợ giao tiếp IPv6 bằng cách sử dụng các API được quản lý, chẳng hạn như java.net.Socket và java.net.URLConnection, cũng như các API gốc, chẳng hạn như ổ cắm AF_INET6. Mức độ hỗ trợ IPv6 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 trên Wi-Fi bằng ngăn xếp kép và chỉ IPv6.
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.
Các 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 đa điểm dư thừa, chẳng hạn như Thông báo đị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 phần mềm 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 tồn tại 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" [Tài nguyên, 109].

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 các cả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 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.

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ị có í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 phần cứng hoặc tự động lấy nét 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()[Resources, 110], 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 do chế độ xem sau 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 chiếu 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ị ở chế độ máy chủ USB CÓ THỂ bao gồm tính năng hỗ trợ máy ảnh bên ngoài kết nối với cổng USB. Nếu hỗ trợ máy ảnh ngoài, thiết bị sẽ:

PHẢI khai báo tính năng nền tảng android.hardware.camera.external và android.hardware camera.any.
PHẢI hỗ trợ USB Video Class (UVC 1.0 trở lên).
CÓ THỂ hỗ trợ nhiều máy ảnh.

Bạn NÊN hỗ trợ tính năng nén video (chẳng hạn như MJPEG) để cho phép chuyển các luồng chưa mã hoá chất lượng cao (tức là luồng hình ảnh thô hoặc được nén độc lập). Hoạt động mã hoá video dựa trên máy ảnh CÓ THỂ được hỗ trợ. Nếu có, luồng MJPEG/ không mã hoá đồng thời (độ phân giải QVGA trở lên) PHẢI truy cập được để 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 của phơi sáng, độ lợi, độ lợi cân bằng trắng, chuyển đổi màu, loại bỏ nhiễu, làm sắc nét và nhiều tính năng 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 lệnh gọi lại ứ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 ảnh và bộ mã hoá video phần cứng có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng việc triển khai thiết bị PHẢI hỗ trợ chuyển đổi sang YV12.)
Đối với android.hardware.camera2, 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 toàn bộ API Máy ảnh có trong tài liệu SDK Android [Tài nguyên, 111], bất kể thiết bị có tính năng tự động lấy nét bằng phần cứng hay các tính năng khác. Ví dụ: các máy ảnh không có tính năng tự động lấy nét VẪN PHẢI gọi mọi thực thể android.hardware.Camera.AutoFocusCallback đã đăng ký (mặc dù điều này không liên quan đến máy ảnh không có tính năng tự động lấy nét). 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 tham số Máy ảnh tiêu chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại tham 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ợ tham số máy ảnh Camera.SCENE_MODE_HDR [Tài nguyên, 112].

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 [Tài nguyên, 113] và báo cáo cờ tính năng khung phù hợp [Tài nguyên, 114].

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ác cờ tính năng thích hợp [Tài nguyên, 114]; 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 đều hỗ trợ tính năng đó.

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

Việc triển khai thiết bị PHẢI truyền tin ý định Camera.ACTION_NEW_VIDEO mỗi khi 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 5 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 trên các hoạt động triển khai thiết bị PHẢI 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	424MB	704MB
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	512 MB	832MB
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 được thêm vào mọi không gian bộ nhớ đã được dành riêng cho các thành phần phần cứng như đài, video, v.v. không nằm trong 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ó ít nhất 5 GB và các phương thức triển khai thiết bị khác PHẢI có ít nhất 1,5 GB bộ nhớ không bay hơi 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à 5GB đối với các thiết bị Android Television và tối thiểu là 1, 5GB đối với các thiết bị triển khai khác. Các thiết bị triển khai chạy Android NÊN có ít nhất 3 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.

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 [Tài nguyên, 115]. 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 đường dẫn Linux /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ì quá trình 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 có sẵn 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 này và triển khai phần mềm. 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ó quyền đó đều 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 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 chú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ì quá trình triển khai đó PHẢI cung cấp một số cơ chế để truy cập vào nội dung của bộ nhớ dùng chung từ máy tính lưu trữ. 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 [Tài nguyên, 116].
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ể thích ứng cho các thiết bị 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 [Tài nguyên, 117].

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ẽ 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 mang tính chất di động, bạn NÊN triển khai bộ nhớ có thể sử dụng ở một vị trí ổn định lâu dài, vì việc vô tình ngắt kết nối 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.

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 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 ở dưới cùng. 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.
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 [Tài nguyên, 118].
- PHẢI hỗ trợ việc thiết lập giao tiếp dựa trên giao thức AOA trong lần kết nối đầu tiên với máy chủ USB đóng vai trò là phụ kiện mà người dùng không cần thay đổi chế độ USB mặc định.
- PHẢI triển khai lớp âm thanh USB như được ghi nhận trong tài liệu về SDK Android [Tài nguyên, 119].
- Ngoài ra, 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ợ để vẽ dòng điện 1,5 A trong tiếng chirp và lưu lượng truy cập HS như được chỉ định trong Thông số kỹ thuật sạc pin USB, Bản sửa đổi 1.2 [Tài nguyên, 120]. 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.
Giá trị của iSerialNumber trong mô tả thiết bị tiêu chuẩn USB PHẢI bằng với giá trị của android.os.Build.SERIAL.

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 vận chuyển kèm theo 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 [Tài nguyên, 119].
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 [Tài nguyên, 121].
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 Thông số kỹ thuật về cáp và đầu nối USB Type-C, Bản sửa đổi 1.2 [] cho đầ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 Thông số kỹ thuật về sạc pin USB, Bản sửa đổi 1.2 [Tài nguyên, 120] cho đầu nối Micro-AB.

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.

Việ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.
NÊN hỗ trợ chế độ phát gần siêu âm như mô tả trong phần 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à KHÔNG ĐƯỢC triển khai các API liên quan đến Đầu ra âm thanh dưới dạng 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 [Tài nguyên, 122], 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 cắm â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ô có 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 phạm vi điện trở tương đương sau đây giữa micrô và dây dẫn nối đất trên giắc cắm âm thanh:
- 70 ohm trở xuống: KEYCODE_HEADSETHOOK
- 210-290 Ohm: KEYCODE_VOLUME_UP
- 360-680 Ohm: KEYCODE_VOLUME_DOWN
PHẢI hỗ trợ tính năng phát hiện và liên kết với mã phím cho phạm vi điện trở tương đương sau đây giữa micrô và dây dẫn nối đất trên giắc cắm âm thanh:
- 110-180 Ohm: KEYCODE_VOICE_ASSIST
PHẢI kích hoạt ACTION_HEADSET_PLUG khi cắm 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ì
- Độ 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 trên tạp âm (SNR) 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 không thấp hơn 40 dB so với độ nhạy ở 2 kHz.

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 hình nhất quán. Độ trễ khung hình không nhất quán hoặc độ trễ kết xuất khung hình KHÔNG ĐƯỢC xảy ra thường xuyên hơn 5 khung hình/giây và PHẢI dưới 1 khung hình/giây.
Độ 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 với 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 đối với 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

Tất cả ứng dụng được miễn chế độ Chờ ứng dụng và/hoặc chế độ Ngủ đều PHẢI hiển thị với người dùng cuối. Ngoài ra, các thuật toán kích hoạt, bảo trì, đánh thức và việc sử dụng 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.

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á mức 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 hao pin gần đúng do các thành phần gây ra theo thời gian như được ghi nhận trong trang web Dự án nguồn mở Android [Tài nguyên, 123].
- 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 năng lượng này cho nhà phát triển ứng dụng thông qua lệnh shell adb shell dumpsys batterystats [Tài nguyên, 124].
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 [Tài nguyên, 125].

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 API [Tài nguyên, 126] 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 của Android như được xác định trong tài liệu dành cho nhà phát triển Android [Tài nguyên, 126]. 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.*.

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 dạng 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 [Tài nguyên, 126].

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ề Quyền và bảo mật [Tài nguyên, 126].

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 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ả ở nơi 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 ứng dụng sử dụng các tính năng được bảo vệ bằng các quyền của Android 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ế.
và 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 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 đi kèm với quá trình triển khai thiết bị.

Khi cài đặt ứng dụng, môi trường thời gian chạy thay thế PHẢI 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 hỗ trợ nhiều người dùng và hỗ trợ cách ly người dùng hoàn toàn [Tài nguyên, 127]. 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, PHẢI đáp ứng các yêu cầu sau liên quan đến việc hỗ trợ nhiều người dùng [Tài nguyên, 128]:

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 các 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 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ế độ kiểm soát 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 API [Tài nguyên, 126].
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 do một người dùng cụ thể sở hữu và chạy thay mặt cho người dùng đó không thể liệt kê, đọc hoặc ghi vào dữ liệu do người dùng nào khác sở hữu. 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, các phương thức triển khai thiết bị sử dụng phương tiện có thể tháo rời cho các API bộ nhớ ngoài chính 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 truy cập được. 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 [Tài nguyên, 129] 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ó tính phí gửi đi [Tài nguyên, 130]. 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 Linux tăng cường bảo mật (SELinux) và các tính năng bảo mật khác trong nhân Linux. SELinux hoặc bất kỳ tính năng bảo mật nào khác được triển khai bên dưới khung Android:

PHẢI duy trì khả năng tương thích với các ứng dụng hiện có.
KHÔNG ĐƯỢC 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 mất 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 cho phép 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 external/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.

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 external/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.

9.8. Quyền riêng tư

Nếu thiết bị triển khai chức năng trong hệ thống để ghi lại nội dung hiển thị trên màn hình và/hoặc ghi lại luồng âm thanh 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 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ế đó.

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á toàn bộ ổ đĩa

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

Nếu việc triển khai thiết bị hỗ trợ màn hình khoá bảo mật báo cáo "true" cho KeyguardManager.isDeviceSecure() [Tài nguyên, 131] và không phải là thiết bị có bộ nhớ bị hạn chế như được báo cáo thông qua phương thức ActivityManager.isLowRamDevice(), thì thiết bị PHẢI hỗ trợ tính năng mã hoá toàn bộ ổ đĩa [Tài nguyên, 132] 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 phương thức triển khai thiết bị hỗ trợ tính năng mã hoá toàn bộ ổ đĩa 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á toàn bộ ổ đĩa 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á toàn bộ ổ đĩa 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ừ.

Phương thức mã hoá 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). Khoá mã hoá KHÔNG ĐƯỢC ghi vào bộ nhớ bất cứ lúc nào mà không được mã hoá. Ngoài trường hợp đang sử dụng, khoá mã hoá PHẢI được mã hoá bằng AES với mật mã 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 mật mã 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 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 hạt nhân Linux dm-crypt.

9.10. Xác minh quy trình khởi động

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, rồi chuyển đến phân vùng hệ thống
Triển khai từng giai đoạn xác minh để kiểm tra tính toàn vẹn và 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)

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 đã xác minh trên 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 đó đượ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 [Tài nguyên, 133] 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 thao tác mã hoá thông qua API KeyChain [Tài nguyên, 134] hoặc API Kho khoá [Tài nguyên, 135].

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à NÊN có thuật toán thời gian đợi luỹ thừa như được triển khai trong Dự án nguồn mở Android.
Khi việc triển khai thiết bị hỗ trợ màn hình khoá bảo mật và có phần cứng bảo mật (chẳng hạn như Secure Element (SE) nơi có thể triển khai Môi trường thực thi đáng tin cậy (TEE)), thì thiết bị đó:
- Bạn NÊN sao lưu quá trình triển khai kho khoá bằng phần cứng bảo mật. Dự án nguồn mở Android cấp trên cung cấp phương thức triển khai Lớp trừu tượng phần cứng (HAL) của Keymaster có thể được dùng để đáp ứng yêu cầu này.
- PHẢI thực hiện quy trình xác thực màn hình khoá trong phần cứng bảo mật nếu thiết bị triển khai kho khoá dựa trên phần cứng 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 ngược dòng cung cấp Lớp trừu tượng phần cứng (HAL) của Gatekeeper có thể được dùng để đáp ứng yêu cầu này [Tài nguyên, 136].

Xin lưu ý rằng mặc dù các yêu cầu liên quan đến TEE nêu trên được nêu là ĐỀ XUẤT MẠNH, nhưng Định nghĩa về khả năng tương thích cho phiên bản API tiếp theo dự kiến sẽ thay đổi các yêu cầu này thành BẮT BUỘC. Nếu việc triển khai thiết bị đã được khởi chạy trên một phiên bản Android cũ hơn và chưa triển khai hệ điều hành đáng tin cậy trên phần cứng bảo mật, thì thiết bị như vậy có thể không đáp ứng được các yêu cầu thông qua bản cập nhật phần mềm hệ thống. Do đó, bạn NÊN triển khai TEE.

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 theo phương thức logic và vật lý, ngoại trừ hình ảnh hệ thống và dữ liệu trong các phân vùng khác có thể được coi là một phần của hình ảnh hệ thống. 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 API Quản trị thiết bị Android) được mô tả trong phần 3.9 Quản trị thiết bị.

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

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) [Tài nguyên, 137] 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, 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à nhiều bản sửa đổi của CTS có thể được phát hành cho Android 6.0. 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 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 tập hợp 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

Quá trình triển khai thiết bị PHẢI bao gồm một cơ chế để thay thế toàn bộ phần mềm hệ thống. Cơ chế này không cần thực hiện nâng cấp "trực tiếp", tức là 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 cũng sẽ đáp ứng yêu cầu này:

Tải xuống "qua mạng không dây (OTA)" bằng 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, chẳng hạn như hồ sơ 802.11 hoặc Bluetooth PAN (Mạng khu vực cá nhân):

Việc triển khai Android Automotive 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.
Tất cả các phương thức triển khai thiết bị khác 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.

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 có sẵn 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 [ Tài nguyên, 138].

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

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

Phần	Tóm tắt các thay đổi
Nhiều thời điểm	Thay thế các thực thể của cụm từ "nên" bằng "NÊN"
2. Loại thiết bị	Cập nhật để triển khai Android Automotive
3.2.2. Tham số bản dựng	Thông tin bổ sung về số sê-ri phần cứng và cấp bản vá bảo mật của một bản dựng
3.2.3.2. Giải quyết ý định	Đổi tên mục từ "Intent Overrides" (Ghi đè ý định) thành "Intent Resolution" (Giải quyết ý định), với các yêu cầu mới liên quan đến việc liên kết ứng dụng mặc định có thẩm quyền
3.3.1. Giao diện nhị phân của ứng dụng	Nội dung bổ sung để hỗ trợ ABI Android; thay đổi liên quan đến tên thư viện Vulkan
3.4.1. Khả năng tương thích với WebView	Thay đổi đối với chuỗi tác nhân người dùng do WebView báo cáo
3.7. Khả năng tương thích với thời gian chạy	Nội dung cập nhật về bảng phân bổ bộ nhớ
3.8.4. Tìm kiếm	Thông tin cập nhật về các yêu cầu đối với Trợ lý
3.8.6. Giao diện	Thêm yêu cầu hỗ trợ biểu tượng hệ thống màu đen khi được cờ SYSTEM_UI_FLAG_LIGHT_STATUS_BAR yêu cầu
3.8.8. Chuyển đổi hoạt động	Nới lỏng yêu cầu về số lượng tiêu đề trong phần Tổng quan.
3.8.10. Điều khiển nội dung nghe nhìn trên màn hình khoá	Điều khiển nội dung nghe nhìn trên màn hình khoá để tham khảo chi tiết về phần 3.8.3.
3.9.1. Cấp phép thiết bị	Chứa các mục mới để cấp phép cho chủ sở hữu thiết bị và cấp phép hồ sơ được quản lý
3.9.2. Nhóm hỗ trợ về hồ sơ được quản lý	Mục mới có các yêu cầu về việc hỗ trợ chức năng hồ sơ được quản lý trên thiết bị
3.12.1. Ứng dụng truyền hình	Thêm phần để làm rõ các yêu cầu đối với Ứng dụng TV cho thiết bị Android Television
3.12.1.1. Hướng dẫn chương trình điện tử	Thêm phần để làm rõ các yêu cầu về EPG đối với thiết bị Android Television
3.12.1.2. Di chuyển	Thêm phần để làm rõ các yêu cầu về điều hướng trong Ứng dụng TV cho thiết bị Android Television
3.12.1.3. Liên kết ứng dụng đầu vào TV	Thêm phần để làm rõ các yêu cầu hỗ trợ liên kết ứng dụng đầu vào TV cho thiết bị Android Television
5.1. Bộ mã hoá và giải mã nội dung nghe nhìn	Thông tin cập nhật về việc hỗ trợ các định dạng nội dung đa phương tiện và giải mã chính.
5.1.3. Bộ mã hoá và giải mã video	Các thay đổi và nội dung bổ sung liên quan đến Android TV
5.2. Mã hoá video	Các thay đổi đối với bộ mã hoá
5.3. Giải mã video	Các thay đổi đối với bộ giải mã, bao gồm cả việc hỗ trợ độ phân giải video động, chuyển đổi tốc độ khung hình và nhiều tính năng khác
5.4. Ghi âm	Nội dung bổ sung liên quan đến tính năng quay âm thanh
5.6. Độ trễ âm thanh	Thông tin cập nhật về việc báo cáo tính năng hỗ trợ âm thanh có độ trễ thấp
5.10. Âm thanh chuyên nghiệp	Thông tin cập nhật chung về tính năng hỗ trợ âm thanh chuyên nghiệp; thông tin cập nhật về thông số kỹ thuật của thiết bị di động (giắc cắm), chế độ máy chủ âm thanh USB và các thông tin cập nhật khác
5.9. Giao diện kỹ thuật số cho nhạc cụ (MIDI)	Thêm mục mới về tính năng hỗ trợ Giao diện kỹ thuật số cho nhạc cụ (MIDI) không bắt buộc
6.1. Công cụ dành cho nhà phát triển	Cập nhật cho trình điều khiển hỗ trợ Windows 10
7.1.1.3. Mật độ màn hình	Thông tin cập nhật về mật độ màn hình, ví dụ: liên quan đến đồng hồ Android
7.2.3. Phím điều hướng	Yêu cầu mới cập nhật để triển khai thiết bị có hành động Hỗ trợ
7.3. Cảm biến (và các tiểu mục)	Yêu cầu mới đối với một số loại cảm biến
7.3.9. Cảm biến có độ trung thực cao	Mục mới có các yêu cầu đối với thiết bị hỗ trợ cảm biến có độ chân thực cao
7.3.10. Cảm biến vân tay	Mục mới về các yêu cầu liên quan đến cảm biến vân tay
7.4.2. IEEE 802.11 (Wi-Fi)	Thông tin cập nhật về việc hỗ trợ DNS đa địa chỉ (mDNS)
7.4.3. Bluetooth	Nội dung bổ sung liên quan đến Địa chỉ riêng có thể phân giải (RPA) cho Bluetooth năng lượng thấp (BLE)
7.4.4. Giao tiếp trường gần	Yêu cầu bổ sung đối với tính năng Giao tiếp phạm vi gần (NFC)
7.4.5. Khả năng mạng tối thiểu	Thêm các yêu cầu để hỗ trợ IPv6
7.6.3. Bộ nhớ thích ứng	Mục mới để triển khai bộ nhớ thích ứng
7.7. USB	Yêu cầu liên quan đến việc triển khai thông số kỹ thuật AOA
7.8.3. Sóng siêu âm gần	Nội dung bổ sung liên quan đến tính năng ghi âm, phát và âm thanh gần siêu âm	Nới lỏng yêu cầu về Tỷ lệ tín hiệu trên tạp âm (SNR) của micrô siêu âm gần.
8.3. Chế độ tiết kiệm pin	Mục mới có các yêu cầu liên quan đến chế độ Chờ ứng dụng và chế độ Nghỉ
8.4. Kế toán mức tiêu thụ điện năng	Mục mới có các yêu cầu về việc 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ể
9.1. Quyền	Ngoài các yêu cầu về Quyền
9.7. Các tính năng bảo mật của nhân	Bản cập nhật SE Linux
9.8. Quyền riêng tư	Nội dung bổ sung liên quan đến sự đồng ý của người dùng về việc truy cập vào bộ nhớ dùng chung qua cổng USB
9.9. Mã hoá toàn bộ ổ đĩa	Yêu cầu liên quan đến tính năng mã hoá toàn bộ ổ đĩa
9.10. Xác minh quy trình khởi động	Yêu cầu bổ sung đối với tính năng khởi động đã xác minh
9.11. Khoá và thông tin xác thực	Mục mới về các yêu cầu liên quan đến khoá và thông tin xác thực
9.12. Xóa dữ liệu	Mục mới cho tính năng "Đặt lại dữ liệu về trạng thái ban đầu"
11. Phần mềm có thể cập nhật	Yêu cầu liên quan đến chính sách cập nhật hệ thống do chủ sở hữu thiết bị đặt ra

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 [Tài nguyên, 139] và yêu cầu giải thích hoặc nêu bất kỳ vấn đề nào mà bạn cho rằng tài liệu này không đề cập đến.

14. Tài nguyên

1. Các cấp độ yêu cầu của IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

2. Dự án nguồn mở Android: http://source.android.com/

3. Các tính năng của Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Tính năng Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API Android UI_MODE_TYPE_CAR: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

6. Định nghĩa và tài liệu về API: http://developer.android.com/reference/packages.html

7. Tài liệu tham khảo về Quyền trên Android: http://developer.android.com/reference/android/Manifest.permission.html

8. Tài liệu tham khảo android.os.Build: http://developer.android.com/reference/android/os/Build.html

9. Chuỗi phiên bản được phép của Android 6.0: http://source.android.com/docs/compatibility/6.0/versions.html

10. Cài đặt dành cho nhà phát triển Android: http://developer.android.com/reference/android/provider/Settings.html

11. Nhà cung cấp dịch vụ điện thoại: http://developer.android.com/reference/android/provider/Telephony.html

12. Quản lý ABI Android NDK: https://developer.android.com/ndk/guides/abis.html

13. Kiến trúc SIMD nâng cao: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

14. Gói mở rộng Android: http://developer.android.com/guide/topics/graphics/opengl.html#aep

15. Lớp android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

16. Khả năng tương thích với WebView: http://www.chromium.org/

17. HTML5: http://html.spec.whatwg.org/multipage/

18. Các tính năng ngoại tuyến của HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

19. Thẻ video HTML5: http://dev.w3.org/html5/spec/Overview.html#video

20. API vị trí địa lý HTML5/W3C: http://www.w3.org/TR/geolocation-API/

21. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/

22. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/

23. Định dạng tệp thực thi Dalvik và thông số kỹ thuật mã byte: có trong mã nguồn Android, tại dalvik/docs

24. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

25. Thông báo: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

26. Tài nguyên ứng dụng: https://developer.android.com/guide/topics/resources/available-resources.html

27. Hướng dẫn về kiểu biểu tượng Thanh trạng thái: http://developer.android.com/design/style/iconography.html

28. Tài nguyên về thông báo: https://developer.android.com/design/patterns/notifications.html

29. Trình quản lý tìm kiếm: http://developer.android.com/reference/android/app/SearchManager.html

30. Hỗ trợ hành động: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

31. API Android Assist: https://developer.android.com/reference/android/app/assist/package-summary.html

32. Thông báo ngắn: http://developer.android.com/reference/android/widget/Toast.html

33. Giao diện: http://developer.android.com/guide/topics/ui/themes.html

34. Lớp R.style: http://developer.android.com/reference/android/R.style.html

35. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

36. Hình nền động: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

37. Tài nguyên màn hình tổng quan: http://developer.android.com/guide/components/recents.html

38. Ghim màn hình: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

39. Phương thức nhập: http://developer.android.com/guide/topics/text/creating-input-method.html

40. Thông báo đa phương tiện: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

41. Ước mơ: http://developer.android.com/reference/android/service/dreams/DreamService.html

42. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

44. Quản trị thiết bị Android: http://developer.android.com/guide/topics/admin/device-admin.html

45. Tài liệu tham khảo về DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

46. Ứng dụng của chủ sở hữu thiết bị: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Quy trình cấp phép cho Chủ sở hữu thiết bị Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Cấp phép cho chủ sở hữu thiết bị qua NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Ứng dụng của chủ sở hữu hồ sơ Android:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Quy trình Cấp phép hồ sơ do Android quản lý: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

51. API Dịch vụ hỗ trợ tiếp cận của Android: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

52. API Hỗ trợ tiếp cận của Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

53. Dự án Eyes Free: http://code.google.com/p/eyes-free

54. API chuyển văn bản sang lời nói: http://developer.android.com/reference/android/speech/tts/package-summary.html

55. Khung đầu vào truyền hình: /devices/tv/index.html

56. Kênh ứng dụng truyền hình: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. Đầu vào TV của bên thứ ba: /devices/tv/index.html#third-party_input_example

58. Đầu vào TV: /devices/tv/index.html#tv_inputs

59. Các trường EPG của kênh truyền hình: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Liên kết ứng dụng đầu vào TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

61. Tài liệu tham khảo về công cụ (dành cho adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

62. Nội dung mô tả tệp apk Android: http://developer.android.com/guide/components/fundamentals.html

63. Tệp kê khai: http://developer.android.com/guide/topics/manifest/manifest-intro.html

64. Định dạng nội dung nghe nhìn trên Android: http://developer.android.com/guide/appendix/media-formats.html

65. API MediaCodecList của Android: http://developer.android.com/reference/android/media/MediaCodecList.html

66. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

67. Dự án WebM: http://www.webmproject.org/

68. Yêu cầu về lập trình phần cứng RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

69. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

70. Lớp android.content.pm.PackageManager của Android và Danh sách tính năng phần cứng: http://developer.android.com/reference/android/content/pm/PackageManager.html

71. Giao thức dự thảo Phát trực tuyến dựa trên HTTP: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

72. ADB: http://developer.android.com/tools/help/adb.html

73. Dumpsys: /devices/input/diagnostics.html

74. DDMS: http://developer.android.com/tools/debugging/ddms.html

75. Công cụ kiểm thử Monkey: http://developer.android.com/tools/help/monkey.html

76. Công cụ SysyTrace: http://developer.android.com/tools/help/systrace.html

77. Chế độ cài đặt liên quan đến hoạt động phát triển ứng dụng Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

78. Hỗ trợ nhiều màn hình: http://developer.android.com/guide/practices/screens_support.html

79. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

80. RenderScript: http://developer.android.com/guide/topics/renderscript/

81. Gói tiện ích Android cho OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

82. Tăng tốc phần cứng: http://developer.android.com/guide/topics/graphics/hardware-accel.html

83. Tiện ích EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

84. Trình quản lý hiển thị: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

85. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

86. Cấu hình đầu vào cảm ứng: http://source.android.com/docs/core/interaction/input/touch-devices

87. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

88. API sự kiện nhấn phím: http://developer.android.com/reference/android/view/KeyEvent.html

89. Cảm biến nguồn mở Android: http://source.android.com/docs/core/interaction/sensors

90. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

91. Sự kiện cảm biến dấu thời gian: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

92. Cảm biến tổng hợp nguồn mở Android: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Chế độ kích hoạt liên tục: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. API vân tay Android: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. HAL vân tay Android: /devices/tech/security/authentication/fingerprint-hal.html

97. API truyền đa hướng Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

98. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

99. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

100. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

101. API Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

102. Mã vạch NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. Giao thức đẩy NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

104. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

105. Cài đặt tính năng chia sẻ NFC trên Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

106. Chuyển đổi kết nối NFC: http://members.nfc-forum.org/specs/spec_list/#conn_handover

107. Ghép nối đơn giản và bảo mật qua Bluetooth bằng NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

108. Mô phỏng thẻ dựa trên máy chủ: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

109. Trình phân giải nội dung: http://developer.android.com/reference/android/content/ContentResolver.html

110. API hướng máy ảnh: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

111. Máy ảnh: http://developer.android.com/reference/android/hardware/Camera.html

112. Máy ảnh: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

113. Cấp phần cứng máy ảnh: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

114. Hỗ trợ phiên bản máy ảnh: http://source.android.com/docs/core/camera/versioning

115. DownloadManager của Android: http://developer.android.com/reference/android/app/DownloadManager.html

116. Android File Transfer: http://www.android.com/filetransfer

117. Bộ nhớ có thể chuyển đổi: http://source.android.com/docs/core/storage/adoptable

118. Phụ kiện mở của Android: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

119. Âm thanh USB trên Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

120. Thông số kỹ thuật sạc pin qua USB, Bản sửa đổi 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

121. USB Host API: http://developer.android.com/guide/topics/connectivity/usb/host.html

122. Tai nghe âm thanh có dây: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

123. Thành phần hồ sơ năng lượng: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Tóm tắt mức sử dụng pin: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

126. Tài liệu tham khảo về Quyền và bảo mật trên Android: http://developer.android.com/guide/topics/security/permissions.html

127. Tài liệu tham khảo về UserManager: http://developer.android.com/reference/android/os/UserManager.html

128. Tài liệu tham khảo về Bộ nhớ ngoài: http://source.android.com/docs/core/storage/traditional

129. API Bộ nhớ ngoài: http://developer.android.com/reference/android/os/Environment.html

130. Mã ngắn SMS: http://en.wikipedia.org/wiki/Short_code

131. Báo cáo màn hình khoá an toàn: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Mã hoá nguồn mở Android: http://source.android.com/docs/security/features/encryption

133. Hệ thống Kho khoá Android: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: http://source.android.com/docs/security/features/authentication/gatekeeper

137. Tổng quan về Chương trình tương thích của Android: http://source.android.com/docs/compatibility

138. Lớp SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

139. Diễn đàn về khả năng tương thích với Android: https://groups.google.com/forum/#!forum/android-compatibility

140. Xử lý đường liên kết trong ứng dụng: https://developer.android.com/training/app-links/index.html

141. Đường liên kết đến tài sản kỹ thuật số của Google: https://developers.google.com/digital-asset-links

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

Định nghĩa về khả năng tương thích với Android 6.0 Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Mục lục

1. Giới thiệu

2. Loại thiết bị

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

3. Phần mềm

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

3.2. Khả năng tương thích mềm của API

3.2.1. Quyền

3.2.2. Tham số bản dự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

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

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

3.2.3.4. Ý định truyền tin

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

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

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

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

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

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

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

3.6. Không gian tên API

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

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)

3.8.2. Tiện ích

3.8.3. Thông báo

3.8.4. Tìm kiếm

3.8.5. Thông báo ngắn

3.8.6. Giao diện

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

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

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

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

3.8.11. Giấc mơ

3.8.12. Vị trí

3.8.13. Unicode và phông chữ

3.9. Quản trị thiết bị

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ị

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

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

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

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

3.12. Khung đầu vào TV

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

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

3.12.1.2. Di chuyển

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

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

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

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

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

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

5.2. Mã hoá video

5.3. Giải mã video

5.4. Ghi âm

5.4.1. Quay âm thanh thô

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

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

5.5. Phát âm thanh

5.5.1. Phát âm thanh thô

5.5.2. Hiệu ứng âm thanh

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

5.6. Độ trễ âm thanh

5.7. Giao thức mạng

5.8. Secure Media

5.9. Giao diện kỹ thuật số cho nhạc cụ (MIDI)

5.10. Âm thanh chuyên nghiệp

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

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

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

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

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

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

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

Định nghĩa về khả năng tương thích với Android 6.0
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.