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

Bản sửa đổi 1
Lần cập nhật gần đây nhất: Ngày 12 tháng 1 năm 2015

Bản quyền © 2015, Google Inc. Mọi quyền được bảo lưu.
[e-mail]

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. Ghi đè ý định 3.2.3.3. Không gian tên ý định 3.2.3.4. Truyền tin ý định 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.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 với 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 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.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 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 với nội dung đ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. Bản ghi âm 5.4.1. Ghi âm thô 5.4.2. Ghi âm để nhận dạng giọng nói 5.4.3. Ghi lại để chuyển hướng 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 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 7.1.1.3. Mật độ màn hình 7.1.2. Chỉ số hiển thị

7.1.3. Hướng màn hình 7.1.4. Tăng tốc đồ hoạ 2D và 3D 7.1.5. Chế độ tương thích với ứng dụng cũ 7.1.6. Công nghệ màn hình 7.1.7. Màn hình ngoài 7.2. Thiết bị đầu vào 7.2.1. Bàn phím 7.2.2. Điều hướng không chạm 7.2.3. Phím điều hướng 7.2.4. Nhập bằng màn hình cảm ứng 7.2.5. Nhập bằng cách chạm giả 7.2.6. Hỗ trợ tay điều khiển trò chơi 7.2.6.1. Ánh xạ nút 7.2.7. Điều khiển từ xa 7.3. Cảm biến 7.3.1. Gia tốc kế 7.3.2. Từ kế 7.3.3. GPS 7.3.4. Con quay hồi chuyển 7.3.5. Khí áp kế 7.3.6. Nhiệt kế 7.3.7. Máy đo ánh sáng 7.3.8. Cảm biến tiệm cận 7.4. Khả năng kết nối dữ liệu 7.4.1. Điện thoại 7.4.2. IEEE 802.11 (Wi-Fi) 7.4.2.1. Wi-Fi Direct 7.4.2.2. Thiết lập đường liên kết trực tiếp qua đường hầm Wi-Fi 7.4.3. Bluetooth 7.4.4. Giao tiếp trường gần 7.4.5. Chức năng mạng tối thiểu 7.4.6. Cài đặt đồng bộ hoá 7.5. Máy ảnh 7.5.1. Máy ảnh sau 7.5.2. Máy ảnh mặt trước 7.5.3. Máy ảnh gắn ngoài 7.5.4. Hành vi của Camera API 7.5.5. Hướng máy ảnh 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 7.6.2. Bộ nhớ dùng chung của ứng dụng 7.7. USB 7.8. Âm thanh 7.8.1. Micrô 7.8.2. Đầu ra âm thanh 7.8.2.1. Cổng âm thanh tương tự 8. Khả năng tương thích về hiệu suất 8.1. Tính nhất quán của trải nghiệm người dùng 8.2. Hiệu suất bộ nhớ 9. Khả năng tương thích của mô hình bảo mật 9.1. Quyền 9.2. UID và tính năng cô lập quy trình 9.3. Quyền đối với hệ thống tệp 9.4. Môi trường thực thi thay thế 9.5. Hỗ trợ nhiều người dùng 9.6. Cảnh báo về tin nhắn dịch vụ 9.7. Các tính năng bảo mật của hạt nhân 9.8. Quyền riêng tư 9.9. Mã hoá toàn bộ ổ đĩa 9.10. Xác minh quy trình khởi động 10. Kiểm thử khả năng tương thích của phần mềm 10.1. Bộ kiểm thử khả năng tương thích 10.2. Trình xác minh CTS 11. Phần mềm có thể cập nhật 12. Nhật ký thay đổi tài liệu 13. Liên hệ với chúng tôi 14. Tài nguyên

1. Giới thiệu

Tài liệu này liệt kê các yêu cầu phải đáp ứng để thiết bị tương thích với Android 5.0.

Việc sử dụng các từ "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "KHÔNG SẼ", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" là theo tiêu chuẩn IETF được xác định trong RFC2119 [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 5.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 5.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. Những người triển khai thiết bị nên triển khai dựa trên mã nguồn "nguồn cấp trên" có sẵn trong Dự án nguồn mở Android ở mức độ lớn nhất có thể. 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 thực hiện 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]

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 5.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ể.

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	Section	Thiết bị cầm tay	Truyền hình	Xem	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	NÊN
Cảm biến	Gia tốc kế	7.3.1 Gia tốc kế	NÊN		NÊN	NÊN
	GPS	7.3.3. GPS	NÊN
Khả năng kết nối	Wi-Fi	7.4.2. IEEE 802.11	NÊN	PHẢI		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	NÊN
	Bluetooth năng lượng thấp	7.4.3. Bluetooth	NÊN	PHẢI	NÊN	NÊN
	Chế độ thiết bị ngoại vi/ máy chủ USB	7.7. USB	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

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 đầy đủ, bao gồm tất cả hành vi được ghi lại, của mọi API được ghi lại do SDK Android hiển thị [Tài nguyên, 5] 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ỉ 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, 6]. 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, 7] 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ủ.

Tham số	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, 8].
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 5.0, trường này PHẢI có giá trị số nguyên là 21.
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 5.0, trường này PHẢI có giá trị số nguyên là 21.
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:5.0/LRWXX/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	BẮT BUỘC phải có số sê-ri phần cứng. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^([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 ("").

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. Ghi đè ý đị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 bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng "Công cụ chọn" cho phép người dùng chọn giữa nhiều ứng dụng đều xử lý cùng một mẫu ý định.

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) nếu hoạt động mặc định cung cấp bộ lọc cụ thể hơn cho URI dữ liệu. Ví dụ: một bộ lọc ý định chỉ định URI dữ liệu "http://www.android.com" cụ thể hơn bộ lọc trình duyệt cho "http://". 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.

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, 9]
• 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
• PHẢI báo cáo, thông qua các tham số trên, chỉ những ABI được ghi nhận trong phiên bản mới nhất của Android NDK, "Hướng dẫn lập trình viên NDK | Quản lý ABI" trong thư mục docs/
• 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, 11] 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 đủ.

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 cách triển khai thư viện được liệt kê ở trên từ Dự án nguồn mở Android ở thượng nguồn.

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

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

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, 12]. 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 5.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, 13].
• 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)) 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, 14].

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

Thiết bị Android TV và đồng hồ 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 mục 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, 14] 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, 15]
• thẻ
• thông tin vị trí địa lý [Tài nguyên, 17]

Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ API webstorage HTML5/W3C [Tài nguyên, 18] và NÊN hỗ trợ API IndexedDB HTML5/W3C [Tài nguyên, 19]. 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 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 tiêu chuẩn, thì các API đó PHẢI được đóng gói trong 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ế ) 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, 20]. Người triển khai thiết bị NÊN 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 độ điểm ảnh	Bộ nhớ tối thiểu của ứng dụng
nhỏ / bình thường	120 dpi (ldpi)	16MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	32MB
	240 dpi (hdpi)
	320 dpi (xhdpi)	64MB
	400 dpi (400dpi)	96MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
lớn	120 dpi (ldpi)	16MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	64MB
	240 dpi (hdpi)
	320 dpi (xhdpi)	128MB
	400 dpi (400dpi)	192MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
xlarge	160 dpi (mdpi)	64MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	320 dpi (xhdpi)	192MB
	400 dpi (400dpi)	288MB
	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 tương ứng cũng như vòng đời cho phép các ứng dụng hiển thị "AppWidget" cho người dùng cuối [Tài nguyên, 21]. Đây là một tính năng mà bạn NÊN hỗ trợ khi triển khai trên Thiết bị cầm tay. Các phương thức triển khai thiết bị hỗ trợ nhúng tiện ích trên màn hình chính PHẢI đáp ứng các yêu cầu sau và khai báo hỗ trợ tính năng nền tảng android.software.app_widgets.

• Trình chạy thiết bị PHẢI có tính năng hỗ trợ tích hợp cho AppWidgets và hiển thị các tính năng 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, 21] để 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, 22], 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 âm thanh, v.v.) được cung cấp trong API [Tài nguyên, 23] 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, 24]. 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 hiển thị liên tục.
• Thông báo quan trọng – Chế độ xem tương tác mà người dùng có thể thao tác hoặc đóng mà không cần rời khỏi ứng dụng hiện tại.
• Thông báo trên màn hình khoá – Thông báo hiển thị trên màn hình khoá với chế độ kiểm soát chi tiết về chế độ hiển thị.

Việc triển khai thiết bị PHẢI hiển thị và thực thi đúng cách các thông báo này, bao gồm cả tiêu đề/tên, biểu tượng, văn bản như được ghi lại trong API Android [Tài nguyên, 25].

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, 26] 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 hệ thống toàn cầu. 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.

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, 27]. 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, 28]. 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, 29].

Android 5.0 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 của giao diện đó hiển thị với ứng dụng [Tài nguyên, 30].

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, 29].

Android hỗ trợ một giao diện biến thể mới 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. Để 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 PHẢI sử dụng màu trắng cho các biểu tượng trạng thái hệ thống (chẳng hạn như cường độ tín hiệu và mức pin) và thông báo do hệ thống đưa ra, trừ phi biểu tượng đó cho biết trạng thái có vấn đề [Tài nguyên, 29].

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

Android xác định một loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị một hoặc nhiều "Hình nền động" cho người dùng cuối [Tài nguyên, 31]. 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, 32], 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 lần 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 20 hoạt động hiển thị
• PHẢI hiển thị ít nhất tiêu đề của 4 hoạt động cùng một lúc
• 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, 33] 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

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

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

Android hỗ trợ Quản lý phương thức nhập và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba [Tài nguyên, 34]. Các phương thức triển khai thiết bị cho phép người dùng sử dụng phương thức nhập của bên thứ ba trên thiết bị PHẢI khai báo tính năng nền tảng android.software.input_methods và hỗ trợ các API IME như được xác định trong tài liệu SDK Android.

Các hoạt động triển khai thiết bị khai báo tính năng android.software.input_methods PHẢI cung cấp cơ chế mà người dùng có thể truy cập để thêm và định cấu hình các phương thức nhập của bên thứ ba. Việc triển khai thiết bị PHẢI hiển thị giao diện cài đặt để phản hồi ý định android.settings.INPUT_METHOD_SETTINGS.

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

API ứng dụng điều khiển từ xa không còn được dùng nữa từ Android 5.0, thay vào đó là Mẫu thông báo nội dung nghe nhìn cho phép các ứng dụng nội dung nghe nhìn tích hợp với các nút điều khiển phát hiển thị trên màn hình khoá [Tài nguyên, 35]. Các phương thức triển khai thiết bị hỗ trợ màn hình khoá trong thiết bị PHẢI hỗ trợ Mẫu thông báo đa phương tiện cùng với các thông báo khác.

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, 36]. 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, 37].

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 một 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, 38]. 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 5.0 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ả đều PHẢI được đưa vào cho các ngôn ngữ có trên thiết bị và phạm vi Unicode 7.0 đầy đủ của 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, 39]. 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, 40]. Việc triển khai thiết bị bao gồm hỗ trợ màn hình khoá 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, 39] và báo cáo tính năng nền tảng android.software.device_admin.

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 ứng dụng này KHÔNG ĐƯỢC đặt sẵn làm ứng dụng Chủ sở hữu thiết bị mặc định [Tài nguyên, 41].

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ác cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng bằng bi xoay/d-pad [Tài nguyên, 42]. Việc triển khai thiết bị 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ị PHẢI đáp ứng các yêu cầu sau:

• 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, 43]
• PHẢI tạo AccessibilityEvents và phân phối các sự kiện này cho tất cả các hoạt động triển khai AccessibilityService đã đăng ký theo cách nhất quán với hoạt động triển khai Android mặc định
• Trừ khi thiết bị Android Watch không có đầu ra âm thanh, việc triển khai thiết bị KHÔNG ĐƯỢC cung cấp cơ chế mà người dùng có thể truy cập để bật và tắt các dịch vụ hỗ trợ tiếp cận, đồng thời KHÔNG ĐƯỢC 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, 44].

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, 45]. 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.

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

• 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 truyền hình [Tài nguyên, 46].

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.

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 trong SDK Android chính thức [Tài nguyên, 47].

Việc triển khai thiết bị KHÔNG ĐƯỢC mở rộng tệp .apk [Tài nguyên, 48], Tệp kê khai Android [Tài nguyên, 49], mã byte Dalvik [Tài nguyên, 20] 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, 50], ngoại trừ trường hợp được cho 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. 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á	Trình giải mã	Chi tiết	(Các) loại tệp/định dạng vùng chứa được hỗ trợ
Cấu hình MPEG-4 AAC (AAC LC)	REQUIRED1	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.12 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+)	REQUIRED1 (Android 4.1 trở lên)	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.12 với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
MPEG-4 HE AACv2 Cấu hình (AAC+ nâng cao)		BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.12 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)	REQUIRED1 (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	REQUIRED3	REQUIRED3	4,75 đến 12,2 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)
AMR-WB	REQUIRED3	REQUIRED3	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ốc 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	REQUIRED4 (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á	Trình giải mã	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

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.

Định dạng / Bộ mã hoá và giải mã	Bộ mã hoá	Trình giải mã	Chi tiết	(Các) loại tệp/định dạng vùng chứa được hỗ trợ
H.263	REQUIRED1	REQUIRED2		• 3GPP (.3gp) • MPEG-4 (.mp4)
H.264 AVC	REQUIRED2	REQUIRED2	Xem phần 5.2 và 5.3 để biết thông tin chi tiết	• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, chỉ âm thanh AAC, không thể tua, Android 3.0 trở lên)
H.265 HEVC		REQUIRED2	Xem mục 5.3 để biết thông tin chi tiết	MPEG-4 (.mp4)
MPEG-4 SP		REQUIRED2		3GPP (.3gp)
VP83	REQUIRED2 (Android 4.3 trở lên)	REQUIRED2 (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, 110] • Matroska (.mkv, Android 4.0 trở lên)4
VP9		REQUIRED2 (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, 110] • Matroska (.mkv, Android 4.0 trở lên)4

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, 51].

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

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 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 720p1	HD 1080p1
Độ 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 720p1	HD 1080p1
Độ 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ợ tính năng chuyển đổi độ phân giải video động trong cùng một luồng cho các bộ mã hoá và giải mã VP8, VP9, H.264 và H.265.

Việc triển khai thiết bị Android bằng bộ giải mã H.264 PHẢI hỗ trợ Hồ sơ cơ sở cấp 3 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 720p1	HD 1080p1
Độ 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	30 khung hình/giây/60 khung hình/giây2	30 khung hình/giây/60 khung hình/giây2
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 việc triển khai thiết bị Android Television, nhưng chỉ đối với các loại thiết bị khác khi phần cứng hỗ trợ.

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 720p1	HD 1080p1
Độ 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ây2	30/60 khung hình/giây2
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 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 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ơ đó PHẢI hỗ trợ độ sâu màu 8 bit.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p 1	HD 1080p 2	UHD 2
Độ phân giải video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Tốc độ khung hình video	30 fps	30 fps	30 fps	30 fps	30 fps
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 DÙNG cho việc triển khai thiết bị Android Television khi phần cứng hỗ trợ.

Khi hỗ trợ bộ mã hoá và giải mã H.265 như mô tả trong mục 5.1.3, việc triển khai thiết bị Android PHẢI hỗ trợ cấp Main Profile Level 3 Main 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. Thiết bị Android Television PHẢI hỗ trợ hồ sơ Main Profile cấp 4.1 và hồ sơ giải mã HD 1080p, đồng thời NÊN hỗ trợ hồ sơ Main10 cấp 5 và hồ sơ giải mã UHD.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p 1	HD 1080p 1	UHD 2
Độ 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	30 fps	30 fps
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 Television, nhưng chỉ đối với các loại thiết bị khác khi phần cứng hỗ trợ.

2 Bắt buộc đối với việc triển khai thiết bị Android Television 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

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

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ô.
• Độ méo hài tổng cộng PHẢI nhỏ hơn 1% đối với 1Khz ở mức đầu vào SPL 90 dB tại micrô.
• BẠN PHẢI tắt tính năng xử lý giảm tiếng ồn (nếu có).
• BẮ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, 52]. 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 đó.
• độ 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 từ khi âm thanh bên ngoài được hiển thị cho thiết bị cho đến khi ứ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 đầu vào bị mất và độ trễ đầu vào cho khung đầu tiên, khi hệ thống đầu vào â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 của độ trễ đầu vào liên tục cộng với độ trễ đầu ra liên tục cộng với 5 mili giây.
• API hàng đợi bộ đệm PCM OpenSL ES – Bộ API OpenSL ES liên quan đến PCM trong Android NDK; xem NDK_root/docs/opensles/index.html.

Việc triển khai thiết bị khai báo android.hardware.audio.output PHẢI đá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ợ, thì thiết bị đó CÓ THỂ báo cáo khả 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, 53]. 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.

Việc triển khai thiết bị có android.hardware.microphone PHẢI đá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, 50]. 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, 54]

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.

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, 55]

Việc triển khai thiết bị PHẢI hỗ trợ tất cả các chức năng adb như được ghi lại trong SDK Android, bao gồm cả dumpsys [Tài nguyên, 56]. 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, 57]

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, 58]

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, 59]

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 9 ở 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, 60]. 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 SDK ghi lại) cho các API của 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, 53]

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, 61]. 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 của màn hình.
• số điểm trên mỗi inch (dpi) – Số pixel trong một khoảng không gian tuyến tính theo chiều ngang hoặc chiều dọc là 1". 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ệ giữa kích thước dài hơn của màn hình với kích thước ngắn hơn. 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 bằng 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, 61] 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 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)
• 320 dpi (xhdpi)
• 400 dpi (400dpi)
• 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, 62] 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, 63].

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, 64] 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 Khung hiển thị thông qua việc sử dụng thẻ tệp kê khai android:hardwareAccelerated hoặc lệnh gọi API trực tiếp [Tài nguyên, 65].

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, 65].

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, 66].

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

Android chỉ định "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. Việc triển khai thiết bị 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 bên ngoài

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, 67].

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

7.2.1. Bàn phím

Các thiết bị Android Watch CÓ THỂ nhưng các loại thiết bị triển khai khác PHẢI triển khai bàn phím mềm.

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

• PHẢI hỗ trợ Khung quản lý đầu vào (cho phép nhà phát triển bên thứ ba tạo Trình chỉnh sửa phương thức nhập – tức là bàn phím mềm) như 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 khác
• CÓ THỂ bao gồm 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, 68] (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 cảm ứng (bi xoay, d-pad hoặc bánh xe) 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, 68]
• 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.
• 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 5.0 KHÔNG ĐƯỢC triển khai nút vật lý chuyên dụng cho chức năng Trình đơn. Các 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 5.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 hành động bổ sung hiển thị bằng cách chọn nút bổ sung trong thanh thao tác
• CÓ THỂ hiển thị trình đơn bật lên cho thao tác bổ sung ở một vị trí đã sửa đổi trên màn hình khi trình đơn này hiển thị bằng cách chọn nút trình đơn thực

Để 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 <= 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.

Android hỗ trợ thao tác Hỗ trợ [Tài nguyên, 69]. Việc triển khai thiết bị Android, ngoại trừ thiết bị Android Watch, PHẢI cung cấp cho người dùng thao tác Hỗ trợ mọi lúc khi chạy ứng dụng. Bạn NÊN triển khai thao tác Hỗ trợ dưới dạng thao tác nhấn và giữ nút Màn hình chính hoặc vuốt lên trên phím Màn hình chính trong phần mềm. Hàm này CÓ THỂ được triển khai thông qua một nút vật lý, phím phần mềm hoặc cử chỉ khác, nhưng PHẢI truy cập được bằng một thao tác duy nhất (ví dụ: nhấn, nhấp đúp hoặc cử chỉ) khi các phím điều hướng khác hiển thị.

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, 68] 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, 70] để 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 5.0 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, 71]
• 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, 71]
• 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, 71]
• 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ách chạm
• 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:

Button	Mức sử dụng HID2	Android Button
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Có1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad lên1 Nút chuyển xuống trên bàn phím định hướng1	0x01 0x00393	AXIS_HAT_Y4
Nút di chuyển sang trái1 Bàn phím di chuyển sang phải1	0x01 0x00393	AXIS_HAT_X4
Nút vai trái1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Nút vai phải1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Nhấp vào cần điều khiển bên trái1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Nhấp vào cần điều khiển bên phải1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Trang chủ1	0x0c 0x0223	KEYCODE_HOME (3)
Quay lại1	0x0c 0x0224	KEYCODE_BACK (4)

1 [Tài nguyên, 72]

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, 71]

Chế độ điều khiển tương tự1	Việc sử dụng HID	Android Button
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, 71]

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 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, 72].

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, 73]. 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, 53]
• 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, 74]
• 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, 75].

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, 73] đượ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.) Các hoạt động triển khai thiết bị PHẢI triển khai các loại cảm biến này khi chúng bao gồm các cảm biến vật lý cần thiết như mô tả trong [Tài nguyên, 76]. 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, 76].

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, 77]. Đố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 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, 78]
• PHẢI có thể báo cáo các sự kiện có tần suất tối thiểu là 100 Hz và NÊN báo cáo các sự kiện có tần suất tối thiểu là 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, 74]
• 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à 8 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 toán trên cơ sở mỗi trục trên các mẫu được thu thập trong khoảng thời gian ít nhất 3 giây ở tốc độ lấy mẫu nhanh nhất
• NÊN triển khai các cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER như mô tả trong tài liệu SDK Android. Các thiết bị Android hiện tại và mới nên triển khai cảm biến tổng hợp TYPE_SIGNIFICANT_MOTION. Nếu bất kỳ cảm biến nào trong số này được triển khai, tổng mức tiêu thụ đ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 trên các thiết bị Android hiện có và mới.
• NÊN 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, 74]
• PHẢI có khả năng đo lường trong khoảng từ -900 μT đến +900 μT trên mỗi trục trước khi bão hoà
• PHẢI có giá trị bù sắt cứng nhỏ hơn 700 μT và NÊN có giá trị dưới 200 μT, bằng cách đặt 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 μT
• PHẢI được bù trừ nhiệt độ
• PHẢI hỗ trợ hiệu chuẩn và bù trực tuyến độ lệch từ tính cứng, đồng thời bảo toàn 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ể tiến hành 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
• NÊN 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 cho 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 có tần suất tối thiểu là 100 Hz và NÊN báo cáo các sự kiện có tần suất tối thiểu là 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 chuẩn 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.
• NÊN 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 trên 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ó thể 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 1 bit trở lên

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

7.4.1. Điện thoại

"Điện thoại" như được các API Android sử dụng và tài liệu này đề cập cụ thể đến phần cứng liên quan đến việc thực hiện cuộc gọi thoại và gửi tin nhắn SMS qua mạng GSM hoặc CDMA. Mặc dù các cuộc gọi thoại này có thể được chuyển đổi gói hoặc không, nhưng đối với Android, các cuộc gọi này được coi là độc lập với mọi kết nối dữ liệu có thể được triển khai bằng cùng một mạng. Nói cách khác, chức năng "thoại" và API 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, 79]
• PHẢI hỗ trợ DNS đa địa chỉ (mDNS) và KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) bất cứ lúc nào hoạt động, kể cả khi màn hình không ở trạng thái hoạt động

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, 80]. 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, 81]. 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ị:

• 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 thiết bị Android Television PHẢI hỗ trợ Bluetooth và Bluetooth LE, còn việc triển khai thiết bị Android Watch PHẢI hỗ trợ Bluetooth.

Android hỗ trợ Bluetooth và Bluetooth năng lượng thấp [Tài nguyên, 82]. 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, 82]
• NÊN hỗ trợ việc giảm tải logic lọc cho chipset bluetooth khi triển khai API ScanFilter [Tài nguyên, 83] và PHẢI báo cáo chính xác giá trị nơi logic lọc được triển khai bất cứ khi nào được truy vấn thông qua phương thức android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
• NÊN hỗ trợ tính năng giảm tải 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, 53]
• 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 6319-4)
    • IsoDep (ISO 14443-4)
    • Loại thẻ NFC Forum 1, 2, 3, 4 (do NFC Forum xác định)
  • 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. Xin lưu ý rằng mặc dù các tiêu chuẩn NFC dưới đây được nêu là NÊN, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai 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 tại 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 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.0 (do NFC Forum xác định)
    • SDP 1.0 (do NFC Forum xác định)
    • Giao thức đẩy NDEF [Tài nguyên, 84]
    • SNEP 1.0 (do NFC Forum xác định)
  • PHẢI hỗ trợ Android Beam [Tài nguyên, 85]:
    • 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, 86]
    • 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, 87] và "Ghép nối đơn giản bảo mật qua Bluetooth bằng NFC phiên bản 1.0" [Tài nguyên, 88] 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ụ "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ị đang ở trạng thái thức, màn hình đang hoạt động và màn hình khoá đã mở khoá

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

Android 5.0 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 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, 10]

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, 53]. 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ố trên lớp 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, 53] 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.

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ề "true" [Tài nguyên, 89].

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 bằng phần cứng hoặc tự động lấy nét bằng phần mềm trong trình điều khiển máy ảnh (trong suốt đối với phần mềm ứng dụng)
• CÓ THỂ có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh 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, 90], 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 camera

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, 91], 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 có dải động cao (HDR) PHẢI hỗ trợ tham số máy ảnh Camera.SCENE_MODE_HDR [Tài nguyên, 92].

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

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

Việc triển khai thiết bị PHẢI truyền 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
xhdpi trở xuống trên màn hình nhỏ/bình thường hdpi trở xuống trên màn hình lớn mdpi trở xuống 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 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 thuộc quyền kiểm soát của hạt nhân.

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 rất nên có ít nhất 3GB bộ nhớ không thể thay đổ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, 95]. 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, thì bộ nhớ đó PHẢI có dung lượng từ 1 GB trở lên 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ừ các thư mục dành riêng cho gói trên bộ nhớ ngoài phụ, nhưng 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 nghe nhìn của Android và android.provider.MediaStore.

Bất kể hình thức bộ nhớ dùng chung được sử dụng, việc triển khai thiết bị PHẢI cung cấp một số cơ chế để truy cập vào nội dung của bộ nhớ dùng chung từ máy tính lưu trữ, chẳng hạn như bộ nhớ khối lượng lớn USB (UMS) hoặc Giao thức truyền nội dung đa phương tiện (MTP). 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 chuyển nội dung nghe nhìn. 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, 96]
• 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"

Nếu việc triển khai thiết bị thiếu cổng USB, thì thiết bị PHẢI cung cấp cho máy tính lưu trữ quyền truy cập vào nội dung của bộ nhớ dùng chung bằng một số phương tiện khác, chẳng hạn như hệ thống tệp mạng.

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, 97]
  • PHẢI triển khai lớp âm thanh USB như được ghi nhận trong tài liệu SDK Android [Tài nguyên, 98]
• Thiết bị này PHẢI triển khai tính năng hỗ trợ để lấy dòng điện 1,5 A trong quá trình giao thông và tiếng chirp 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, 99]. 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 thành cổng USB loại A hoặc loại C tiêu chuẩn
• RẤT 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, 98]
• 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, 100]
• PHẢI hỗ trợ phạm vi dòng điện đầu ra của Cổng sạc hạ nguồn từ 1,5 A đến 5 A 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, 99].

7.8. Âm thanh

7.8.1. Micrô

Thiết bị cầm tay và đồng hồ Android PHẢI có 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

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

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, 101], nếu việc triển khai thiết bị bao gồm một hoặc nhiều cổng âm thanh tương tự, thì ít nhất một trong các cổng âm thanh PHẢI là giắc âm thanh 3,5 mm 4 dây. Nếu việc triển khai thiết bị có giắc âm thanh 3,5 mm 4 dây, thì thiết bị đó:

• PHẢI hỗ trợ phát âm thanh qua tai nghe nổi và tai nghe nổi có micrô, đồng thời NÊN hỗ trợ ghi âm qua tai nghe nổi có micrô
• PHẢI hỗ trợ giắc cắm âm thanh TRRS theo thứ tự chân cắm CTIA và NÊN hỗ trợ giắc cắm âm thanh theo thứ tự chân cắm OMTP
• PHẢI hỗ trợ tính năng phát hiện micrô trên phụ kiện âm thanh đã cắm, nếu việc triển khai thiết bị hỗ trợ micrô và truyền thông báo 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

8. Khả năng tương thích về hiệu suất

Một số tiêu chí hiệu suất tối thiểu rất quan trọng đối với trải nghiệm người dùng và ả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ùngViệc triển khai thiết bị PHẢI đảm bảo trải nghiệm người dùng có độ trễ thấp bằng cách cuộn danh sách gồm 10.000 mục danh sách theo định nghĩa của Bộ kiểm thử khả năng tương thích Android (CTS) trong vòng chưa đến 36 giây.
• Chuyển đổi tác vụKhi nhiều ứng dụng đã được khởi chạy, việc khởi chạy lại một ứng dụng đang chạy sau khi ứng dụng đó đã được khởi chạy PHẢI mất ít hơ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 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ự là 5 MB/giây cho tệp 256 MB bằng cách sử dụng vùng đệm ghi 10 MB.
• Ghi ngẫu nhiênViệc triển khai thiết bị PHẢI đảm bảo hiệu suất ghi ngẫu nhiên là 0,5 MB/giây cho một tệp 256 MB bằng cách sử dụng vùng đệm ghi 4 KB.
• Đọc tuần tựHoạt động triển khai thiết bị PHẢI đảm bảo hiệu suất đọc tuần tự 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ênViệc triển khai thiết bị PHẢI đảm bảo hiệu suất đọc ngẫu nhiên 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.

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, 102] 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, 102]. 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.*.

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, 102].

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 vào 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, 102].

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 thời gian chạy thông qua cơ chế cho các thời gian chạy thay thế.

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 dùng chung cho 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ỳ quyền đặc biệt 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 tách biệt hoàn toàn người dùng [Tài nguyên, 103]. 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, 104]:

• 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, 102]
• Việc triển khai thiết bị CÓ THỂ hỗ trợ việc tạo người dùng và hồ sơ được quản lý thông qua các API android.app.admin.DevicePolicyManager và PHẢI khai báo cờ tính năng nền tảng android.software.managed_users nếu được hỗ trợ.
• Các hoạt động triển khai thiết bị khai báo cờ tính năng android.software.managed_users PHẢI sử dụng huy hiệu biểu tượng AOSP ngược dòng để đại diện cho các ứng dụng được quản lý và các thành phần giao diện người dùng huy hiệu khác như Gần đây và Thông báo.
• 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 các hoạt động triển khai thiết bị sẽ phải chuyển sang MTP hoặc một hệ thống tương tự để cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại. 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, 105] 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, 106] . 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 ngược dòng.

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

• PHẢI đặt SELinux thành chế độ thực thi toàn cục,
• PHẢI định cấu hình tất cả miền ở chế độ thực thi. Không cho phép các miền ở chế độ cho phép, bao gồm cả cá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ị NÊN 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.

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 quá trình triển khai thiết bị có màn hình khoá, thì thiết bị PHẢI hỗ trợ tính năng mã hoá toàn bộ ổ đĩa 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 thẻ SD nếu đó là một phần vĩnh viễn, không thể tháo rời của thiết bị [Tài nguyên, 107]. Đối với các thiết bị hỗ trợ tính năng mã hoá toàn bộ ổ đĩa, bạn PHẢI luôn bật tính năng mã hoá toàn bộ ổ đĩa sau khi người dùng hoàn tất trải nghiệm ban đầu. Mặc dù yêu cầu này được nêu là NÊN áp dụng cho phiên bản nền tảng Android này, nhưng bạn RẤT NÊN tuân thủ vì chúng tôi dự kiến yêu cầu này sẽ thay đổi thành PHẢI áp dụng cho các phiên bản Android trong tương lai. 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 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

Việc triển khai thiết bị PHẢI hỗ trợ tính năng xác minh quy trình khởi động để đảm bảo tính toàn vẹn của thiết bị. Nếu tính năng này được hỗ trợ, thì bạn PHẢI khai báo cờ tính năng nền tảng android.software.verified_boot. Mặc dù yêu cầu này được nêu là NÊN áp dụng cho phiên bản nền tảng Android này, nhưng bạn RẤT NÊN tuân thủ vì chúng tôi dự kiến yêu cầu này sẽ thay đổi thành PHẢI áp dụng cho các phiên bản Android trong tương lai. Dự án nguồn mở Android ngược dòng cung cấp cách triển khai ưu tiên của tính năng này dựa trên tính năng dm-verity của nhân hệ điều hành Linux.

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, 108] 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 5.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 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) với bản cập nhật ngoại tuyến thông qua việc khởi động lại
• Cập nhật "Có dây" qua USB từ máy tính lưu trữ
• Cập nhật "ngoại tuyến" thông qua việc khởi động lại và cập nhật từ một tệp trên bộ nhớ có thể tháo rời

Tuy nhiên, nếu việc triển khai thiết bị bao gồm cả việc hỗ trợ kết nối dữ liệu không đo lượng dữ liệu như hồ sơ 802.11 hoặc Bluetooth PAN (Mạng cá nhân), thì thiết bị PHẢI hỗ trợ tính năng tải xuống qua mạng không dây với 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 5.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 ở thượng nguồn, được thêm vào kể từ Android 5.0, đá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ả.

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.

(Các) phần	Tóm tắt nội dung thay đổi
1. Giới thiệu	Cập nhật các yêu cầu để tham khảo tài liệu SDK làm nguồn đáng tin cậy.
2. Loại thiết bị	Đã đưa vào các định nghĩa về loại thiết bị cho thiết bị cầm tay, TV và đồng hồ.
2.1 Cấu hình thiết bị	Thêm danh sách không đầy đủ để minh hoạ sự khác biệt về cấu hình phần cứng trên các thiết bị.
3.1. Khả năng tương thích với API được quản lý	CŨNG PHẢI cung cấp các phương thức triển khai đầy đủ của API có điểm đánh dấu "@SystemApi" trong mã nguồn Android ngược dòng.
3.2.2. Tham số bản dựng	Đã thêm các tham số SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS và SUPPORTED_64_BIT_ABIS vào danh sách, cập nhật PRODUCT để yêu cầu SKU sản phẩm duy nhất và cập nhật TAGS.
3.2.3.1. Ý định cốt lõi của ứng dụng	Làm rõ ngôn ngữ rằng yêu cầu về khả năng tương thích chủ yếu là dành cho mẫu ý định
3.2.3.5. Cài đặt ứng dụng mặc định	Bao gồm các yêu cầu mới đối với màn hình chính, NFC và ứng dụng SMS mặc định.
3.3.1 Giao diện nhị phân của ứng dụng	Thêm các yêu cầu để hỗ trợ ABI 32 bit tương đương nếu có bất kỳ ABI 64 bit nào được hỗ trợ. Cập nhật các thông số để phản ánh thay đổi này.
3.4.1. Khả năng tương thích với WebView	Tất cả thiết bị đều phải có khả năng tương thích với Webview, ngoại trừ thiết bị Android Watch. Xoá yêu cầu về chuỗi Ngôn ngữ.
3.4.2. Khả năng tương thích với trình duyệt	Thiết bị Android TV và đồng hồ CÓ THỂ bỏ qua ứng dụng trình duyệt, nhưng 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.
3.7. Khả năng tương thích với thời gian chạy	Cập nhật yêu cầu về bộ nhớ tối thiểu của ứng dụng
3.8.2. Tiện ích	Không bắt buộc phải hỗ trợ tiện ích cho tất cả các loại thiết bị, nhưng nên hỗ trợ cho Thiết bị cầm tay.
3.8.3. Thông báo	Mở rộng định nghĩa cho các loại thông báo được hỗ trợ.
3.8.4. Tìm kiếm	Thiết bị Android Television PHẢI có tính năng tìm kiếm toàn cầu. Tất cả các loại thiết bị khác ĐƯỢC.
3.8.6. Giao diện	Thiết bị PHẢI hỗ trợ giao diện Material.
3.8.7. Hình nền động (Live Wallpaper)	Các thiết bị có hình nền động 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	Yêu cầu được đề xuất để hỗ trợ Giao diện người dùng mới gần đây. PHẢI hiển thị ít nhất tiêu đề của 4 hoạt động cùng một lúc.
3.8.10. Điều khiển từ xa nội dung nghe nhìn trên màn hình khoá	Ngừng sử dụng API ứng dụng điều khiển từ xa và thay vào đó là Mẫu thông báo nội dung nghe nhìn
3.8.11. Giấc mơ	Không bắt buộc đối với thiết bị Android Watch. Bắt buộc đối với tất cả các loại thiết bị khác.
3.8.13 Unicode và phông chữ	PHẢI hỗ trợ Roboto 2 ngoài các yêu cầu hiện tại.
3.12. Khung đầu vào TV	Việc triển khai thiết bị Android Television PHẢI hỗ trợ Khung đầu vào truyền hình.
5.1. Bộ mã hoá và giải mã nội dung nghe nhìn	Thêm 3 mục cho bộ mã hoá và giải mã Âm thanh, Hình ảnh và Video.
5.4 Bản ghi âm	Được chia thành các tiểu mục
5.4.1. Quay âm thanh thô	Xác định các đặc điểm để ghi âm thanh thô trên các thiết bị khai báo android.hardware.microphone
5.5. Phát âm thanh	Thêm mục 5.5. Phát âm thanh với 2 tiểu mục: 5.5.1 Hiệu ứng âm thanh và 5.5.2. Âm lượng đầu ra âm thanh
5.6 Độ trễ âm thanh	Thêm các định nghĩa và yêu cầu về độ trễ đầu ra nguội, độ trễ đầu vào nguội và độ trễ liên tục của lượt truy cập.
5.8 Nội dung nghe nhìn bảo mật	Đã thêm các yêu cầu về nội dung nghe nhìn bảo mật từ phiên bản 7.1.8. Màn hình bên ngoài và các yêu cầu bổ sung đối với Android Television.
6.1. Công cụ dành cho nhà phát triển	Tài nguyên đã cập nhật.
6.2.1. Thử nghiệm	Đã xoá phần
7. Khả năng tương thích với phần cứng	Cập nhật để phản ánh việc triển khai thiết bị PHẢI báo cáo nhất quán cấu hình phần cứng chính xác cho cùng một vân tay bản dựng.
7.1.1.1. Kích thước màn hình	Cập nhật để phản ánh kích thước màn hình của thiết bị Android Watch và giá trị này không thể thay đổi
7.1.1.2. Tỷ lệ khung hình màn hình	Cập nhật để phản ánh tỷ lệ khung hình màn hình của thiết bị Android Watch (1:1).
7.1.3. Hướng màn hình	Cập nhật để phản ánh rằng các thiết bị có màn hình ngang theo hướng cố định CHỈ NÊN báo cáo hướng đó.
7.1.4. Tăng tốc đồ hoạ 2D và 3D	Thêm thông tin rằng các thiết bị Android CÓ THỂ hỗ trợ gói tiện ích Android.
(cũ) 7.1.6. Loại màn hình	Đã xoá phần
7.1.6. Công nghệ màn hình	Cập nhật tỷ lệ khung hình bằng pixel (PAR) thành từ 0,9 đến 1,15. (~15% dung sai)
7.1.7. Màn hình bên ngoài	Di chuyển một phần của mục này sang mục 5.8. Secure Media.
7.2.2. Điều hướng không chạm	Thiết bị Android Television PHẢI hỗ trợ D-pad.
7.2.3. Phím điều hướng	Bao gồm ngôn ngữ để hỗ trợ trên nhiều loại thiết bị.
7.2.4. Phương thức nhập bằng màn hình cảm ứng	Thiết bị Android Watch PHẢI hỗ trợ phương thức nhập bằng màn hình cảm ứng.
7.2.6. Hỗ trợ tay điều khiển trò chơi	Thêm phần về các yêu cầu đối với Android Television.
7.2.7. Điều khiển từ xa	Thêm phần về các yêu cầu đối với Android Television.
7.3. Cảm biến	Xác định lại cảm biến tổng hợp là cảm biến tổng hợp và cảm biến truyền trực tuyến là cảm biến liên tục. Cảm biến phải báo cáo thời gian sự kiện tính bằng nano giây.
7.3.1. Gia tốc kế	Làm rõ các loại cảm biến bắt buộc và sửa đổi ngưỡng yêu cầu.
7.3.2. Từ kế	Làm rõ các loại cảm biến bắt buộc và sửa đổi ngưỡng yêu cầu.
7.3.4. Con quay hồi chuyển	Làm rõ các loại cảm biến bắt buộc và sửa đổi ngưỡng yêu cầu.
7.3.5. Khí áp kế	Thay đổi từ CÓ THỂ thành NÊN triển khai áp kế. PHẢI triển khai và báo cáo cảm biến TYPE_PRESSURE.
7.3.6. Nhiệt kế	Thiết bị CÓ THỂ bao gồm nhiệt kế môi trường xung quanh. CÓ THỂ nhưng KHÔNG NÊN bao gồm nhiệt kế CPU.
7.3.8. 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.
7.4.2. IEEE 802.11 (Wi-Fi)	Thiết bị Android Television PHẢI hỗ trợ Wi-Fi. Các thiết bị CÓ hỗ trợ wifi phải báo cáo android.hardware.wifi.
7.4.2.1. Wi-Fi Direct	PHẢI báo cáo tính năng phần cứng android.hardware.wifi.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	Thiết bị Android Television PHẢI hỗ trợ Wi-Fi TDLS.
7.5. Camera	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.3. Máy ảnh gắn ngoài	Thêm các yêu cầu về việc triển khai thiết bị ở chế độ máy chủ USB CÓ THỂ bao gồm cả tính năng hỗ trợ máy ảnh bên ngoài.
7.5.5. Tính năng của hệ thống máy ảnh	Thêm danh sách các tính năng của máy ảnh và thời điểm xác định các tính năng đó.
7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu	Cập nhật các yêu cầu đối với thiết bị 32 và 64 bit. Xoá yêu cầu về bộ nhớ SVELTE. Thiết bị PHẢI có ít nhất 1,5 GB bộ nhớ không bay hơi
7.6.2. Bộ nhớ dùng chung của ứng dụng	Cập nhật yêu cầu đối với bộ nhớ di động mà người dùng có thể truy cập
7.6.2. Bộ nhớ dùng chung của ứng dụng	Cập nhật các yêu cầu về việc ứng dụng hệ thống cài đặt sẵn có thể ghi vào bộ nhớ ngoài phụ.
7.7. USB	Xoá các yêu cầu về cổng không sạc nằm trên cùng một cạnh với cổng sạc micro-USB. Cập nhật các yêu cầu đối với chế độ Máy chủ và Thiết bị ngoại vi.
7.7. USB	Sửa lỗi chính tả trong phần USB.
7.8.1. Âm thanh	Di chuyển phần micrô đến đây. Thêm các yêu cầu đối với cổng Đầu ra âm thanh và cổng Analog âm thanh.
8. Khả năng tương thích về hiệu suất	Thêm các yêu cầu về tính nhất quán của giao diện người dùng.
9.5. Hỗ trợ nhiều người dùng	Tính năng hỗ trợ nhiều người dùng là không bắt buộc đối với tất cả các loại thiết bị. Yêu cầu chi tiết theo loại thiết bị trong phần này.
9.5. Hỗ trợ nhiều người dùng	Yêu cầu mã hoá thẻ SD cho bộ nhớ ngoài chính.
9.7. Các tính năng bảo mật của nhân	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 cho phép miền ở chế độ nới lỏng.
9.9. Mã hoá toàn bộ ổ đĩa	Thiết bị có màn hình khoá PHẢI hỗ trợ tính năng mã hoá toàn bộ ổ đĩa. Đối với thiết bị mới, bạn phải bật tính năng mã hoá toàn bộ ổ đĩa ngay từ đầu.
9.10 Xác minh quy trình khởi động	Thêm mục để đề xuất rằng việc triển khai Thiết bị hỗ trợ tính năng khởi động được xác minh cho tính toàn vẹn của thiết bị.
10.3. Ứng dụng tham khảo	Xoá mục này khỏi CDD.
11. Phần mềm có thể cập nhật	Nếu hỗ trợ hồ sơ 802.11 hoặc Bluetooth PAN (Mạng cá nhân), thì thiết bị PHẢI hỗ trợ tính năng tải xuống qua mạng không dây với bản cập nhật ngoại tuyến thông qua việc khởi động lại.
14. Tài nguyên	Tài nguyên được di chuyển từ mục 2 sang mục 14

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, 109] 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. Định nghĩa và tài liệu về API: http://developer.android.com/reference/packages.html

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

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

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

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

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

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

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

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

14. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

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

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

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

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

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

20. Đị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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37. Settings.Secure LOCATION_MODE:

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

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

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

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

41. Ứng dụng của chủ sở hữu thiết bị Android:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html

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

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

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

60. Các chế độ cài đặt liên quan đến việc phát triển ứng dụng Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

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

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

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

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

66. Tiện ích EGL-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

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

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

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

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

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

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

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

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

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

76. Cảm biến tổng hợp nguồn mở Android: http://source.android.com/devices/sensors/composite_sensors.html

77. Chế độ kích hoạt liên tục: http://source.android.com/devices/sensors/base_triggers.html#continuous

78. Cảm biến gia tốc kế: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

107. Mã hoá nguồn mở Android: http://source.android.com/devices/tech/encryption/index.html

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

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

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

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.