Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

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

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

Mục lục

1. Giới thiệu
2. Tài nguyên
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 ứng dụng cốt lõi
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.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 máy ảo
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. Màn hình ứng dụng gần đây
3.8.9. Quản lý đầu vào
3.8.10. Lock Screen Media Remote Control
3.8.11. Dreams

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

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.2. Mã hoá video
5.3. Giải mã video
5.4. Bản ghi âm
5.5. Độ trễ âm thanh
5.6. Giao thức mạng

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.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. Loại màn hình
7.1.7. Công nghệ màn hình
7.1.8. 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. Phương thức nhập bằng màn hình cảm ứng
7.2.5. Nhập dữ liệu cảm ứng giả
7.2.6. Micrô

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. Barometer
7.3.6. Nhiệt kế
7.3.7. Máy đo quang
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.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.5. Máy ảnh

7.5.1. Máy ảnh mặt sau
7.5.2. Máy ảnh mặt trước
7.5.3. Hành vi của Camera API
7.5.4. 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

8. Khả năng tương thích về hiệu suất
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 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

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
10.3. Ứng dụng tham chiếu

11. Phần mềm có thể cập nhật
12. Liên hệ với chúng tôi

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

Việc sử dụng các từ "phải", "không được", "bắt buộc", "sẽ", "sẽ không", "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 4.3. "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 4.3, 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 Mục 10 không rõ ràng, mơ hồ hoặc chưa đầy đủ, thì người triển khai thiết bị có trách nhiệm đảm bảo khả năng tương thích với các phương thức triển khai hiện có.

Vì lý do này, Dự án nguồn mở Android [Tài nguyên, 3] 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ù một số thành phần có thể được thay thế bằng cách 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.

2. Tài nguyên

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

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

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

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

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

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

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

Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html

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

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

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

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

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

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

API cơ sở dữ liệu web HTML5/W3C: http://www.w3.org/TR/webdatabase/

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

Thông số kỹ thuật của Máy ảo Dalvik: có trong mã nguồn Android, tại dalvik/docs

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

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

Tài nguyên ứng dụng: http://code.google.com/android/reference/available-resources.html

Hướng dẫn về kiểu biểu tượng Thanh trạng thái: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

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

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

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

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

Hình nền động: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

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

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

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

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

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

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

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

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

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

Công cụ kiểm thử Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

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

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

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

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

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

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

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

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

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

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

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

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

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/security.html

Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android

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

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

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

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

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

Ghép nối đơn giản và bảo mật qua Bluetooth bằng NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Wifi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

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

Thông số kỹ thuật sạc qua USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

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

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

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

Wifi Direct (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Tiện ích màn hình khoá và màn hình chính: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

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

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

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

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

Ứng dụng điều khiển từ xa nội dung đa phương tiện: http://developer.android.com/reference/android/media/RemoteControlClient.html

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

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

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

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

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

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

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

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

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 được quản lý (dựa trên Dalvik) 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 máy ảo đượ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 nhận, của mọi API được ghi nhận mà SDK Android 4.3 hiển thị [Tài nguyên, 4].

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, sai lệch 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" chỉ có trong thời gian chạy, dưới dạng các yếu tố như Ý đị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ả các hằng số quyền như được ghi nhận trên trang Tham khảo về quyền [Tài nguyên, 5]. 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, 6] dùng để mô tả thiết bị hiện tại. Để cung cấp các giá trị nhất quán và có ý nghĩa trên các phương thức 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à phương thức triển khai thiết bị PHẢI tuân thủ.

Tham số	Nhận xét
android.os.Build.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, 7].
android.os.Build.VERSION.SDK	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 4.3, trường này PHẢI có giá trị số nguyên là 18.
android.os.Build.VERSION.SDK_INT	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 4.3, trường này PHẢI có giá trị số nguyên là 18.
android.os.Build.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 ("").
android.os.Build.BOARD	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.,_-]+$"`.
android.os.Build.BRAND	Giá trị do người triển khai thiết bị chọn để xác định tên của công ty, tổ chức, cá nhân, v.v. đã sản xuất thiết bị, ở đị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 nhà sản xuất thiết bị gốc (OEM) và/hoặc nhà mạng đã bán 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.,_-]+$"`.
android.os.Build.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.
android.os.Build.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.
android.os.Build.DEVICE	Giá trị do người triển khai thiết bị chọn để xác định cấu hình hoặc bản sửa đổi cụ thể của thân máy (đôi khi được gọi là "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.,_-]+$"`.
android.os.Build.FINGERPRINT	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ý. Mã này PHẢI tuân theo mẫu sau: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Ví dụ: `acme/mydevice/generic:4.3/JRN53/3359:userdebug/test-keys` Mã 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 trường đó 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.
android.os.Build.HARDWARE	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.,_-]+$"`.
android.os.Build.HOST	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 ("").
android.os.Build.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.,_-]+$"`.
android.os.Build.MANUFACTURER	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 ("").
android.os.Build.MODEL	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ừ trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.PRODUCT	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 (SKU). PHẢI là văn bản mà con người có thể đọc được, nhưng không nhất thiết phải là văn bản mà người dùng cuối xem được. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.SERIAL	Số sê-ri phần cứng, nếu có. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy `"^([a-zA-Z0-9]{0,20})$"`.
android.os.Build.TAGS	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. Ví dụ: "unsigned,debug". 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.,_-]+$"`.
android.os.Build.TIME	Giá trị đại diện cho dấu thời gian của thời điểm bản dựng xảy ra.
android.os.Build.TYPE	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". 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.,_-]+$"`.
android.os.Build.USER	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 khớp và liên kết với cũng như 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

Dự án ngược dòng Android xác định một số ứng dụng cốt lõi, chẳng hạn như danh bạ, lịch, thư viện ảnh, trình phát nhạc, v.v. Nhà triển khai thiết bị CÓ THỂ thay thế các ứng dụng này bằng các phiên bản thay thế.

Tuy nhiên, mọi phiên bản thay thế như vậy PHẢI tuân thủ cùng một mẫu Ý định do dự án cấp trên cung cấp. Ví dụ: nếu một thiết bị chứa trình phát nhạc thay thế, thì thiết bị đó vẫn phải tuân thủ mẫu Ý định do các ứng dụng bên thứ ba phát hành để chọn một bài hát.

Các ứng dụng sau đây được coi là ứng dụng hệ thống Android cốt lõi:

Đồ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

Các ứng dụng hệ thống Android cốt lõi bao gồm nhiều thành phần Hoạt động hoặc Dịch vụ được coi là "công khai". Tức là thuộc tính "android:exported" có thể không có hoặc có giá trị "true".

Đối với mọi Hoạt động hoặc Dịch vụ được xác định trong một trong các ứng dụng hệ thống Android cốt lõi không được đánh dấu là không công khai thông qua thuộc tính android:exported có giá trị "false", thì việc triển khai thiết bị PHẢI bao gồm một thành phần thuộc cùng loại triển khai cùng một mẫu bộ lọc Ý định như ứng dụng hệ thống Android cốt lõi.

Nói cách khác, việc triển khai thiết bị CÓ THỂ thay thế các ứng dụng hệ thống Android cốt lõi; tuy nhiên, nếu có, việc triển khai thiết bị PHẢI hỗ trợ tất cả mẫu Ý định do mỗi ứng dụng hệ thống Android cốt lõi được thay thế xác định.

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.2. 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 một 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.*. Trình triển khai thiết bị KHÔNG ĐƯỢC đưa bất kỳ thành phần Android nào tuân theo bất kỳ mẫu Ý định mới hoặc Ý định truyền tin nào bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khoá khác trong không gian gói thuộc về một tổ chức khác. Người triển khai thiết bị KHÔNG ĐƯỢC thay đổi hoặc mở rộng bất kỳ mẫu Ý định nào mà các ứng dụng cốt lõi sử dụng được liệt kê trong Phần 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 các 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 chúng.

Quy định cấm này tương tự như quy định cấm đối với các lớp ngôn ngữ Java trong Mục 3.6.

3.2.3.4. Ý định truyền tin

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

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ã được quản lý chạy trong Dalvik 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, trong tệp docs/CPU-ARCH-ABIS.html. Nếu việc triển khai thiết bị tương thích với một hoặc nhiều ABI đã xác định, thì việc triển khai đó PHẢI tương thích với Android NDK, như bên dưới.

Nếu việc triển khai thiết bị bao gồm việc hỗ trợ ABI Android, thì thiết bị đó:

PHẢI hỗ trợ mã chạy trong môi trường được quản lý để gọi vào mã gốc, sử dụng ngữ nghĩa Giao diện gốc Java (JNI) tiêu 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 báo cáo chính xác Giao diện nhị phân của ứng dụng (ABI) gốc mà thiết bị hỗ trợ thông qua API android.os.Build.CPU_ABI
PHẢI chỉ báo cáo những ABI được ghi nhận trong phiên bản mới nhất của Android NDK, trong tệp docs/CPU-ARCH-ABIS.txt
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ó chứa 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.0)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.0)
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)
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 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 các hoạt động 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) với libGLESv2.so. Trên các hoạt động triển khai thiết bị khai báo hỗ trợ OpenGL ES 3.0, libGLESv2.so PHẢI xuất các biểu tượng hàm OpenGL ES 3.0 ngoài các biểu tượng hàm OpenGL ES 2.0.

Khả năng tương thích của mã gốc là một thách thức. Vì lý do này, chúng tôi xin nhắc lại rằng các nhà triển khai thiết bị NÊN sử dụng phương thức triển khai thượng nguồn của các thư viện nêu trên để đảm bảo khả năng tương thích.

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

Việc triển khai nguồn mở Android sử dụng công cụ kết xuất WebKit để triển khai android.webkit.WebView [Tài nguyên, 10] . 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 WebKit trong quá trình triển khai WebView. Cụ thể:

Việc triển khai android.webkit.WebView của các hoạt động triển khai thiết bị PHẢI dựa trên bản dựng WebKit 534.30 từ cây nguồn mở Android ngược dòng cho Android 4.3. 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. Trình triển khai thiết bị CÓ THỂ đưa các tuỳ chỉnh vào quá trình triển khai WebKit; tuy nhiên, mọi tuỳ chỉnh như vậy KHÔNG ĐƯỢC thay đổi hành vi của WebView, bao gồm cả hành vi kết xuất.
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; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
- 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 $(LOCALE) PHẢI tuân theo các quy ước ISO về mã quốc gia và ngôn ngữ, đồng thời PHẢI tham chiếu đến ngôn ngữ đã định cấu hình hiện tại của thiết bị
- 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
- Việc triển khai thiết bị CÓ THỂ bỏ qua Mobile trong chuỗi tác nhân người dùng

Thành phần WebView PHẢI hỗ trợ nhiều HTML5 [Tài nguyên, 11] 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 liên kết với HTML5 trong WebView:

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

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

Theo mặc định, các API HTML5, giống như tất cả các API JavaScript, PHẢI bị tắt trong WebView, trừ phi nhà phát triển bật các API đó một cách rõ ràng thông qua các API Android thông thường.

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

Quá trình triển khai thiết bị 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 vớ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, 11] 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, 12]
thẻ <video> [Tài nguyên, 13]
định vị vị trí [Tài nguyên, 14]

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, 3]. 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 quyền tiêu chuẩn

Danh sách bên trên chưa đầy đủ. Bộ kiểm thử tính tương thích (CTS) kiểm thử các phần quan trọng của nền tảng để đảm bảo 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.*

Sau đây là một số nội dung sửa đổi bị cấm:

Quá trình 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ế <uses-library>) mới bị ảnh hưởng bởi mức sử dụng bộ nhớ tăng lên của các API đó.

Nếu người triển khai thiết bị đề xuất cải thiện một trong các không gian tên gói nêu 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 máy ảo

Việc triển khai thiết bị PHẢI hỗ trợ đầy đủ thông số kỹ thuật mã byte của Tệp thực thi Dalvik (DEX) và ngữ nghĩa của Máy ảo Dalvik [Tài nguyên, 17].

Việc triển khai thiết bị PHẢI định cấu hình Dalvik để phân bổ bộ nhớ theo nền tảng Android thượng nguồn và theo bảng sau. (Xem Mục 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.

Kích thước màn hình	Mật độ điểm ảnh	Bộ nhớ ứng dụng
nhỏ / bình thường / lớn	ldpi / mdpi	16MB
nhỏ / bình thường / lớn	tvdpi / hdpi	32MB
nhỏ / bình thường / lớn	xhdpi	64MB
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB

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 4.3 bao gồm một ứng dụng trình chạy (màn hình chính) và hỗ trợ các ứng dụng của bên thứ ba để thay thế trình chạy thiết bị (màn hình chính). Việc triển khai thiết bị cho phép các ứng dụng bên thứ ba thay thế màn hình chính của thiết bị PHẢI khai báo tính năng nền tảng android.software.home_screen.

3.8.2. Tiện ích

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, 18]. 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 theo kích thước lưới tiêu chuẩn. (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, 18] để biết thông tin chi tiết.
Việc triển khai thiết bị có hỗ trợ màn hình khoá PHẢI hỗ trợ 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, 19], 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. Xin lưu ý rằng hành vi này được mô tả chi tiết hơn trong Mục 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, 20] hoặc trong hướng dẫn về kiểu biểu tượng Thanh trạng thái/Hệ thống [Tài nguyên, 21]. 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 4.3 hỗ trợ thông báo đa dạng thức, chẳng hạn như Khung hiển thị tương tác cho thông báo đang diễn ra. Việc triển khai thiết bị PHẢI hiển thị và thực thi thông báo đa dạng thức đúng cách, như được ghi nhận trong API Android.

3.8.4. Tìm kiếm

Android bao gồm các API [Tài nguyên, 22] cho phép nhà phát triển tích hợp tính năng tìm kiếm vào ứng dụng và hiển thị dữ liệu của ứng dụng vào tính năng tìm kiếm trên 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 cụm từ tìm kiếm, 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ị PHẢI bao gồm một giao diện người dùng tìm kiếm chung, trên toàn hệ thống, có thể đưa ra đề xuất theo thời gian thực để phản hồi nội dung người dùng nhập. Việc triển khai thiết bị PHẢI triển khai các API cho phép nhà phát triển sử dụng lại giao diện người dùng này để cung cấp tính năng tìm kiếm trong các ứng dụng của riêng họ. Việc triển khai thiết bị 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" (được xác định trong [Tài nguyên, 23]) để 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. 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 4.3 bao gồm giao diện "Holo" hoặc "holographic" (3D) 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 giao diện Holo theo định nghĩa của SDK Android [Tài nguyên, 24]. Việc triển khai thiết bị KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Holo nào hiển thị với ứng dụng [Tài nguyên, 25].

Android 4.3 bao gồm một giao diện "Mặc định của thiết bị" mới 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 DeviceDefault hiển thị cho các ứng dụng [Tài nguyên, 25].

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

Android xác định một loại thành phần và API và vòng đời tương ứng cho phép các ứng dụng hiển thị một hoặc nhiều "Hình nền động" cho người dùng cuối [Tài nguyên, 26]. 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 Open GL 1.0 hoặc 2.0 để 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 hình nền động của ngữ cảnh OpenGL có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.

Các phương thức triển khai thiết bị có thể chạy hình nền động một cách đáng tin cậy như mô tả ở trên PHẢI triển khai hình nền động. Các phương thức triển khai thiết bị được xác định là không chạy hình nền động một cách đáng tin cậy như mô tả ở trên KHÔNG ĐƯỢC triển khai hình nền động.

3.8.8. Màn hình ứng dụng gần đây

Mã nguồn Android 4.3 ngược dòng bao gồm một giao diện người dùng để hiển thị các ứng dụng 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ị CÓ THỂ thay đổi hoặc loại bỏ giao diện người dùng này; tuy nhiên, phiên bản Android trong tương lai dự kiến sẽ sử dụng rộng rãi hơn chức năng này. Bạn nên sử dụng giao diện người dùng Android 4.3 ngược dòng (hoặc giao diện dựa trên hình thu nhỏ tương tự) cho các ứng dụng gần đây, nếu không, các ứng dụng đó có thể không tương thích với phiên bản Android trong tương lai.

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

Android 4.3 hỗ trợ tính năng Quản lý phương thức nhập và hỗ trợ trình chỉnh sửa phương thức nhập của bên thứ ba. Các hoạt động 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 từ xa nội dung nghe nhìn trên màn hình khoá

Android 4.3 hỗ trợ Remote Control API (API điều khiển từ xa) cho phép các ứng dụng đa phương tiện tích hợp với các nút điều khiển phát được hiển thị trong chế độ xem từ xa như màn hình khoá thiết bị [Tài nguyên, 74]. Các hoạt động triển khai thiết bị hỗ trợ màn hình khoá trong thiết bị và cho phép người dùng thêm tiện ích trên màn hình chính PHẢI hỗ trợ tính năng nhúng các nút điều khiển từ xa vào màn hình khoá của thiết bị [Tài nguyên, 69].

3.8.11. Giấc mơ

Android 4.3 hỗ trợ trình bảo vệ màn hình tương tác có tên là Dreams [Tài nguyên, 76]. Dreams cho phép người dùng tương tác với các ứng dụng khi thiết bị sạc ở trạng thái rảnh hoặc được gắn vào đế sạc trên bàn. Việc triển khai thiết bị KHÔNG ĐƯỢC thiếu tính năng hỗ trợ Dreams và cung cấp tuỳ chọn cài đặt để người dùng định cấu hình Dreams.

3.9 Quản trị thiết bị

Android 4.3 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, 27]. Việc triển khai thiết bị PHẢI cung cấp phương thức triển khai lớp DevicePolicyManager [Tài nguyên, 28]. Các hoạt động triển khai thiết bị có 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, 27].

3.10 Hỗ trợ tiếp cận

Android 4.3 cung cấp một lớp hỗ trợ tiếp cận giúp người dùng khuyết tật thao tác trên thiết bị dễ dàng hơn. Ngoài ra, Android 4.3 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 các lệnh gọi lại cho sự kiện người dùng và hệ thống, đồng thời tạo các cơ chế phản hồi thay thế, chẳng hạn như chuyển văn bản sang lời nói, phản hồi xúc giác và điều hướng bằng bi xoay/d-pad [Tài nguyên, 29]. 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. Cụ thể, việc triển khai thiết bị PHẢI đáp ứng các yêu cầu sau.

Việc triển khai thiết bị 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, 30].
Các hoạt động triển khai thiết bị PHẢI tạo AccessibilityEvents và phân phối các sự kiện này cho tất cả các hoạt động triển khai AccessibilityService đã đăng ký theo cách nhất quán với hoạt động triển khai Android mặc định.
Việc triển khai thiết bị PHẢI cung cấp một cơ chế mà người dùng có thể truy cập để bật và tắt các dịch vụ hỗ trợ tiếp cận, đồng thời PHẢI hiển thị giao diện này để phản hồi ý định android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Ngoài ra, quá trình triển khai thiết bị PHẢI cung cấp cách 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, 31].

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

Android 4.3 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, 32]. Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu sau liên quan đến khung TTS của Android:

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

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

Việc triển khai thiết bị PHẢI cài đặt và chạy các tệp ".apk" của Android do công cụ "aapt" tạo ra trong SDK Android chính thức [Tài nguyên, 33].

Việc triển khai thiết bị KHÔNG ĐƯỢC mở rộng tệp .apk [Tài nguyên, 34], Tệp kê khai Android [Tài nguyên, 35], mã byte Dalvik [Tài nguyên, 17] 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. Trình triển khai thiết bị PHẢI sử dụng phương thức triển khai ngược dòng tham chiếu của Dalvik và hệ thống quản lý gói của phương thức triển khai tham chiếu.

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

Việc triển khai thiết bị PHẢI bao gồm ít nhất một dạng đầu ra âm thanh, chẳng hạn như loa, giắc cắm tai nghe, kết nối loa ngoài, v.v.

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, 58], 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ả bộ mã hoá và giải mã này được cung cấp dưới dạng triển khai phần mềm trong cách 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 bị ràng buộc bởi các bằng sáng chế của bên thứ ba. Những người có ý định sử dụng mã nguồn này trong các sản phẩm phần cứng hoặc phần mềm nên lưu ý rằng việc triển khai mã này, bao gồm cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế của các chủ sở hữu bằng sáng chế có liên quan.

Xin lưu ý rằng các bảng này không liệt kê các yêu cầu cụ thể về tốc độ bit đối với hầu hết bộ mã hoá và giải mã video vì phần cứng thiết bị hiện tại không nhất thiết phải hỗ trợ tốc độ bit ánh xạ chính xác đến tốc độ bit bắt buộc do các tiêu chuẩn liên quan chỉ định. Thay vào đó, việc triển khai thiết bị PHẢI hỗ trợ tốc độ bit cao nhất có thể trên phần cứng, lên đến giới hạn do thông số kỹ thuật xác định.

Loại	Định dạng / Bộ mã hoá và giải mã	Bộ mã hoá	Bộ giải mã	Thông tin chi tiết	(Các) loại tệp/Định dạng vùng chứa
Âm thanh	Hồ sơ MPEG-4 AAC (AAC LC)	BẮT BUỘC đối với các hoạt động triển khai thiết bị bao gồm phần cứng micrô và xác định `android.hardware.microphone`.	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1* với tốc độ lấy mẫu tiêu chuẩn từ 8 đến 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC thô ADTS (.aac, giải mã trong Android 3.1 trở lên, mã hoá trong Android 4.0 trở lên, không hỗ trợ ADIF) MPEG-TS (.ts, không thể tua, Android 3.0 trở lên)
	Hồ sơ MPEG-4 HE AAC (AAC+)	BẮT BUỘC đối với việc triển khai thiết bị có phần cứng micrô và xác định android.hardware.microphone	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1* với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
	Hồ sơ MPEG-4 HE AAC v2 (AAC+ nâng cao)		BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi/5.0/5.1* với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
	Loại đối tượng âm thanh MPEG-4 ER AAC ELD (AAC độ trễ thấp nâng cao)	BẮT BUỘC đối với việc triển khai thiết bị có phần cứng micrô và xác định android.hardware.microphone	BẮT BUỘC	Hỗ trợ nội dung đơn âm/âm thanh nổi với tốc độ lấy mẫu tiêu chuẩn từ 16 đến 48 kHz.
	AMR-NB	BẮT BUỘC đối với các hoạt động triển khai thiết bị bao gồm phần cứng micrô và xác định `android.hardware.microphone`.	BẮT BUỘC	4,75 đến 12,2 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)
	AMR-WB	BẮT BUỘC đối với các hoạt động triển khai thiết bị bao gồm phần cứng micrô và xác định `android.hardware.microphone`.	BẮT BUỘC	9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 16 kHz	3GPP (.3gp)
	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 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, tốc độ bit không đổi 8-320 Kb/giây (CBR) hoặc tốc độ bit thay đổi (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)
	PCM/WAVE	BẮT BUỘC	BẮT BUỘC	PCM tuyến tính 8 bit và 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 PCM thô ở tần số 8000,16000 và 44100 Hz	WAVE (.wav)
Hình ảnh	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)
Video	H.263	BẮT BUỘC đối với việc 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`.	BẮT BUỘC		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	BẮT BUỘC đối với việc 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`.	BẮT BUỘC	Hồ sơ cơ sở (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, chỉ âm thanh AAC, không thể tua, Android 3.0 trở lên)
	MPEG-4 SP		BẮT BUỘC		3GPP (.3gp)
	VP8	BẮT BUỘC (Android 4.3 trở lên)	BẮT BUỘC (Android 2.3.3 trở lên)		WebM (.webm) và Matroska (.mkv, Android 4.0 trở lên)***

*Lưu ý: Chỉ cần giảm âm lượng nội dung 5.0/5.1; không bắt buộc phải ghi hoặc kết xuất nhiều hơn 2 kênh.
**Lưu ý: Bắt buộc phải có tính năng ghi PCM tuyến tính 16 bit. Không bắt buộc phải ghi âm PCM tuyến tính 8 bit.
***Lưu ý: Việc triển khai thiết bị PHẢI hỗ trợ ghi tệp Matroska WebM.

5.2 Mã hoá video

Việc triển khai thiết bị Android có máy ảnh mặt sau và khai báo android.hardware.camera PHẢI hỗ trợ các hồ sơ mã hoá video H.264 sau đây.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD (Khi phần cứng hỗ trợ)
Độ phân giải video	176 x 144 px	480 x 360 px	1280 x 720 px
Tốc độ khung hình video	12 khung hình/giây	30 fps	30 fps
Tốc độ bit của video	56 Kb/giây	500 Kb/giây trở lên	2 Mb/giây trở lên
Bộ giải mã audio	AAC-LC	AAC-LC	AAC-LC
Kênh âm thanh	1 (đơn âm)	2 (âm thanh nổi)	2 (âm thanh nổi)
Tốc độ bit của âm thanh	24 Kb/giây	128 Kb/giây	192 Kb/giây

Việc triển khai thiết bị Android có máy ảnh mặt sau và khai báo android.hardware.camera PHẢI hỗ trợ các hồ sơ mã hoá video VP8 sau đây

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

5.3 Giải mã video

Việc triển khai thiết bị Android PHẢI hỗ trợ các hồ sơ giải mã video VP8 và H.264 sau đây.

	SD (Chất lượng thấp)	SD (Chất lượng cao)	HD 720p (Khi phần cứng hỗ trợ)	HD 1080p (Khi phần cứng hỗ trợ)
Độ 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	8 Mb/giây	20 Mb/giây

5.4. Ghi âm

Khi một ứng dụng đã sử dụng API android.media.AudioRecord để bắt đầu ghi luồng âm thanh, các hoạt động triển khai thiết bị bao gồm phần cứng micrô và khai báo android.hardware.microphone PHẢI lấy mẫu và ghi âm bằng từng hành vi sau:

Thiết bị PHẢI thể hiện đặc điểm biên độ gần như bằng phẳng so với tần số; cụ thể là ±3 dB, từ 100 Hz đến 4000 Hz
Bạn PHẢI đặt độ nhạy đầu vào âm thanh sao cho nguồn công suất âm thanh (SPL) 90 dB ở tần số 1000 Hz tạo ra RMS là 2500 đối với các mẫu 16 bit.
Cấp độ biên độ PCM PHẢI theo dõi tuyến tính các thay đổi về SPL đầu vào trong phạm vi ít nhất là 30 dB từ -18 dB đến +12 dB so với 90 dB SPL tại micrô.
Tổng độ méo hài PHẢI nhỏ hơn 1% đối với 1Khz ở mức đầu vào SPL 90 dB.

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:

BẠN PHẢI tắt tính năng xử lý giảm tiếng ồn (nếu có).
BẠN PHẢI tắt tính năng tự động điều khiển độ lợi (nếu có).

Lưu ý: mặc dù một số yêu cầu nêu trên được nêu là "NÊN" đối với 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". Tức là các yêu cầu này không bắt buộc trong Android 4.3 nhưng sẽ bắt buộc trong một phiên bản sau này. Các thiết bị hiện có và mới chạy Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3, 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.5. Độ 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.

Theo mục đích của phần này:

"độ trễ đầu ra" được xác định là 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" được xác định là độ 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" được xác định là độ 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" là khoảng thời gian tính từ khi âm thanh bên ngoài được trình bày 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" được xác định là tổng thời gian đầu vào bị mất và độ trễ đầu vào cho khung hình đầu tiên, khi hệ thống đầu vào âm thanh ở 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" được xác định là độ trễ đầu vào cho các khung hình tiếp theo, trong khi thiết bị đang ghi âm
"OpenSL ES PCM buffer queue API" (API hàng đợi bộ đệm PCM OpenSL ES) là tập hợp các API OpenSL ES liên quan đến PCM trong Android NDK; xem NDK_root/docs/opensles/index.html

Theo Mục 5, mọi phương thức triển khai thiết bị tương thích PHẢI bao gồm ít nhất một dạng đầu ra âm thanh. Việc triển khai thiết bị PHẢI đáp ứng hoặc vượt quá các yêu cầu sau về độ trễ đầu ra:

độ 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

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

Theo Mục 7.2.5, phần cứng micrô có thể bị bỏ qua khi triển khai thiết bị.

Việc triển khai thiết bị bao gồm phần cứng micrô và khai báo android.hardware.microphone PHẢI đáp ứng các yêu cầu sau về độ trễ â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 từ 50 mili giây trở xuống

5.6. 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, 58]. Cụ thể, thiết bị PHẢI hỗ trợ các giao thức mạng nội dung đ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, 59]

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ụ thể, thiết bị tương thích với Android PHẢI tương thích với:

Cầu gỡ lỗi Android (còn gọi là adb) [Tài nguyên, 33]
Việc triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được ghi nhận trong SDK Android. Theo mặc định, trình nền adb phía thiết bị PHẢI không hoạt động và PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
Android 4.3 hỗ trợ adb bảo mật. adb bảo mật cho phép adb trên các máy chủ đã xác thực đã biết. Việc triển khai thiết bị PHẢI hỗ trợ adb bảo mật.
Dịch vụ theo dõi gỡ lỗi Dalvik (còn gọi là ddms) [Tài nguyên, 33]
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ợ cho ddms PHẢI ở trạng thái không hoạt động theo mặc định, nhưng PHẢI được hỗ trợ bất cứ khi nào người dùng đã kích hoạt Cầu gỡ lỗi Android, như trên.
Monkey [Tài nguyên, 36]
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, 33]
Việc triển khai thiết bị PHẢI hỗ trợ công cụ systrace như được ghi nhận trong SDK Android. Theo mặc định, Systrace phải ở 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 tuỳ 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 và Windows 8, ở cả phiên bản 32 bit và 64 bit.

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

Android 4.3 hỗ trợ nhà phát triển định cấu hình các chế độ cài đặt liên quan đến việc phát triển ứng dụng. Việc triển khai thiết bị PHẢI tuân thủ ý định android.settings.APPLICATION_DEVELOPMENT_SETTINGS để hiển thị các chế độ cài đặt liên quan đến việc phát triển ứng dụng [Tài nguyên, 77]. Theo mặc định, quá trình triển khai Android thượng nguồn sẽ ẩn trình đơn Tuỳ chọn cho nhà phát triển và cho phép người dùng chạy Tuỳ chọn cho nhà phát triển sau khi nhấn 7 lần vào mục 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 đó:

PHẢI vẫn có định nghĩa lớp đầy đủ (như được ghi lại trong SDK) cho 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 nếu 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 ghi lại trong tài liệu SDK

Một ví dụ điển hình về trường hợp áp dụng các yêu cầu này là API điện thoại: ngay cả trên các thiết bị không phải điện thoại, các API này 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 chính xác thông tin cấu hình phần cứng thông qua các phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager. [Tài nguyên, 37]

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

Android 4.3 bao gồm các cơ sở tự động điều chỉnh tài sản ứng dụng và bố cục giao diện người dùng cho phù hợp với thiết bị, để đả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, 38]. 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ế" là khoảng cách tính bằng inch giữa hai góc đối diện của phần được chiếu sáng trên màn hình.
"dpi" (nghĩa là "điểm trên mỗi inch") là số pixel được bao phủ bởi một khoảng không gian tuyến tính theo chiều ngang hoặc chiều dọc là 1". 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" là 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 độ" hoặc ("dp") là đơn vị pixel ảo được chuẩn hoá cho màn hình 160 dpi, được tính như sau: pixels = dps * (density / 160).

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

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

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, 38] và do nền tảng Android thượng nguồ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ỏ")
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
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ị PHẢI có kích thước màn hình tối thiểu là 2,5 inch theo đường chéo thực tế.

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

Các ứng dụng có thể cho biết kích thước màn hình mà ứng dụng hỗ trợ thông qua thuộc tính <supports-screens> trong tệp AndroidManifest.xml. Việc triển khai thiết bị PHẢI tuân thủ chính xác khả 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 về SDK Android.

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

Tỷ lệ khung hình PHẢI nằm trong khoảng từ 1,3333 (4:3) đến 1,85 (16:9).

Mật độ màn hình

Khung giao diện người dùng Android xác định một tập hợp mật độ logic chuẩn để giúp nhà phát triển ứng dụng nhắm đến tài nguyên ứng dụng. Việc triển khai thiết bị PHẢI báo cáo một trong các mật độ khung Android logic sau đây thông qua API android.util.DisplayMetrics và PHẢI thực thi các ứng dụng ở mật độ chuẩn này.

120 dpi, còn gọi là "ldpi"
160 dpi, còn gọi là "mdpi"
213 dpi, còn gọi là "tvdpi"
240 dpi, còn gọi là "hdpi"
320 dpi, còn gọi là "xhdpi"
480 dpi, còn gọi là "xxhdpi"
640 dpi, còn gọi là "xxxhdpi"

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

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

Thiết bị PHẢI hỗ trợ hướng động của các ứng dụng đối với hướng màn hình dọc hoặc ngang. Tức là thiết bị phải tuân thủ 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 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.

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Ỉ ĐƯỢC báo cáo android.hardware.screen.landscape.

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 SDK Android. Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 3.0 trên các thiết bị có khả năng hỗ trợ OpenGL ES 3.0. Việc triển khai thiết bị cũng PHẢI hỗ trợ Android Renderscript, như được nêu chi tiết trong tài liệu SDK Android [Tài nguyên, 8].

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 hoặc OpenGL ES 3.0. Đó là:

Các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) PHẢI báo cáo khả năng hỗ trợ OpenGL ES 1.0 và OpenGL ES 2.0
API OpenGL C/C++ gốc (tức là cá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 tính năng hỗ trợ cho 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 PHẢI hỗ trợ các API do OpenGL ES 3.0 quản lý 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, libGLESv2.so PHẢI xuất các biểu tượng hàm OpenGL ES 3.0 ngoài các biểu tượng hàm OpenGL ES 2.0.

Các 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, PHẢI KHÔNG báo cáo các chuỗi tiện ích mà chúng không hỗ trợ.

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

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

Trong Android 4.3, việc triển khai thiết bị PHẢI bật tính năng tăng tốc phần cứng theo mặc định và PHẢI tắt tính năng tăng tốc phần cứng nếu nhà phát triển yêu cầu bằng cách đặt android:hardwareAccelerated="false" hoặc tắt tính năng tăng tốc phần cứng trực tiếp thông qua 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, 9].

Android 4.3 bao gồm một đối tượng TextureView cho phép nhà phát triển tích hợp trực tiếp các kết cấu OpenGL ES được tăng tốc phần cứng 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 thượng nguồn.

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

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

Android 4.3 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. Loại màn hình

Màn hình triển khai thiết bị được phân loại thành một trong hai loại:

Triển khai màn hình cố định pixel: màn hình là một bảng điều khiển duy nhất chỉ hỗ trợ chiều rộng và chiều cao pixel duy nhất. Thông thường, màn hình được tích hợp vật lý với thiết bị. Ví dụ: điện thoại di động, máy tính bảng, v.v.
Triển khai màn hình có pixel biến đổi: phương thức triển khai thiết bị không có màn hình được nhúng và bao gồm cổng đầu ra video như VGA, HDMI hoặc cổng không dây để hiển thị, hoặc có màn hình được nhúng có thể thay đổi kích thước pixel. Ví dụ: TV, hộp giải mã tín hiệu số, v.v.

Triển khai thiết bị có pixel cố định

Việc triển khai thiết bị có pixel cố định CÓ THỂ sử dụng màn hình có kích thước pixel bất kỳ, miễn là màn hình đó đáp ứng các yêu cầu được xác định trong Định nghĩa về khả năng tương thích này.

Việc triển khai pixel cố định CÓ THỂ bao gồm cổng đầu ra video để sử dụng với màn hình bên ngoài. Tuy nhiên, nếu màn hình đó từng được dùng để chạy ứng dụng, thì thiết bị PHẢI đáp ứng các yêu cầu sau:

Thiết bị PHẢI báo cáo cùng một cấu hình màn hình và các chỉ số hiển thị, như được nêu chi tiết trong Mục 7.1.1 và 7.1.2, như màn hình cố định pixel.
Thiết bị PHẢI báo cáo mật độ logic giống với màn hình cố định pixel.
Thiết bị PHẢI báo cáo kích thước màn hình giống hoặc rất gần với màn hình cố định pixel.

Ví dụ: máy tính bảng có kích thước đường chéo 7 inch với độ phân giải 1024x600 pixel được coi là phương thức triển khai màn hình mdpi lớn có pixel cố định. Nếu chứa cổng đầu ra video hiển thị ở độ phân giải 720p hoặc 1080p, thì việc triển khai thiết bị PHẢI điều chỉnh tỷ lệ đầu ra để các ứng dụng chỉ được thực thi trong cửa sổ mdpi lớn, bất kể màn hình điểm ảnh cố định hay cổng đầu ra video có đang được sử dụng hay không.

Triển khai thiết bị có pixel biến đổi

Việc triển khai thiết bị có pixel biến đổi PHẢI hỗ trợ một hoặc cả hai độ phân giải 1280x720 hoặc 1920x1080 (tức là 720p hoặc 1080p). Việc triển khai thiết bị có màn hình pixel biến thiên KHÔNG ĐƯỢC hỗ trợ bất kỳ chế độ hoặc cấu hình màn hình nào khác. Việc triển khai thiết bị có màn hình có thể thay đổi pixel CÓ THỂ thay đổi cấu hình hoặc chế độ màn hình trong thời gian chạy hoặc thời gian khởi động. Ví dụ: người dùng hộp set-top có thể thay thế màn hình 720p bằng màn hình 1080p và việc triển khai thiết bị có thể điều chỉnh cho phù hợp.

Ngoài ra, việc triển khai thiết bị có pixel biến đổi PHẢI báo cáo các nhóm cấu hình sau cho các kích thước pixel này:

1280x720 (còn gọi là 720p): kích thước màn hình "lớn", mật độ "tvdpi" (213 dpi)
1920x1080 (còn gọi là 1080p): kích thước màn hình "lớn", mật độ "xhdpi" (320 dpi)

Để rõ ràng, việc triển khai thiết bị có kích thước pixel biến đổi sẽ bị hạn chế ở 720p hoặc 1080p trong Android 4.3 và PHẢI được định cấu hình để báo cáo kích thước màn hình và nhóm mật độ như đã nêu ở trên.

7.1.7. 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. Cụ thể:

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,1. Tức là tỷ lệ khung hình pixel PHẢI gần vuông (1, 0) với dung sai 10%.

7.1.8. Màn hình bên ngoài

Android 4.3 hỗ trợ màn hình phụ để bật các tính năng chia sẻ nội dung nghe nhìn và API dành cho nhà phát triển để truy cập vào màn hình ngoài. Nếu một thiết bị hỗ trợ màn hình ngoài thông qua kết nối có dây, không dây hoặc kết nối màn hình bổ sung được nhúng, thì việc triển khai thiết bị PHẢI triển khai API trình quản lý màn hình như mô tả trong tài liệu SDK Android [Tài nguyên, 75]. Các phương thức triển khai thiết bị hỗ trợ đầu ra video an toàn và có khả năng hỗ trợ các nền tảng an toàn PHẢI khai báo hỗ trợ Display.FLAG_SECURE. Cụ thể, các hoạt động triển khai thiết bị khai báo hỗ trợ Display.FLAG_SECURE, PHẢI hỗ trợ HDCP 2.x trở lên đối với màn hình không dây Miracast hoặc HDCP 1.2 trở lên đối với màn hình có dây. Việc triển khai nguồn mở Android ngược dòng bao gồm cả 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.

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

7.2.1. Bàn phí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 Công cụ quản lý đầu vào – 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)
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, 40] (tức là QWERTY hoặc 12 phím)

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

CÓ THỂ bỏ qua một tuỳ chọn điều hướng không chạm (tức là có thể bỏ qua bi xoay, d-pad hoặc bánh xe)
PHẢI báo cáo đúng giá trị cho android.content.res.Configuration.navigation [Tài nguyên, 40]
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 không chạm.

Các hàm Màn hình chính, Trình đơn và Quay lại là thiết yếu đối với mô hình điều hướng của Android. Việc triển khai thiết bị PHẢI cung cấp các chức năng này cho người dùng mọi lúc khi chạy ứng dụng. Các chức năng này CÓ THỂ được triển khai thông qua các nút vật lý chuyên dụng (chẳng hạn như nút cảm ứng cơ học hoặc điện dung) hoặc CÓ THỂ được triển khai bằng các phím phần mềm, cử chỉ, bảng cảm ứng chuyên dụng, v.v. Android 4.3 hỗ trợ cả hai phương thức triển khai.

Android 4.3 hỗ trợ thao tác hỗ trợ [Tài nguyên, 63]. Việc triển khai thiết bị 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. Hàm này CÓ THỂ được triển khai thông qua khoá phần cứng hoặc phần mềm.

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.
Quá trình triển khai thiết bị PHẢI cung cấp một phần màn hình cho các ứng dụng đáp ứng các yêu cầu được xác định trong Mục 7.1.1.
Việc triển khai thiết bị PHẢI hiển thị các phím điều hướng khi ứng dụng không chỉ định chế độ giao diện người dùng hệ thống hoặc chỉ định SYSTEM_UI_FLAG_VISIBLE.
Việc triển khai thiết bị PHẢI hiển thị các phím điều hướng ở chế độ "hình thức thấp" (ví dụ: 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.
Việc triển khai thiết bị PHẢI hiển thị khoá Trình đơn cho các ứng dụng khi targetSdkVersion <= 10 và KHÔNG ĐƯỢC hiển thị khoá Trình đơn khi targetSdkVersion > 10.

7.2.4. Phương thức nhập bằng màn hình cảm ứng

Việc triển khai thiết bị PHẢI có một hệ thống nhập con trỏ (giống như chuột hoặc cảm ứng). Tuy nhiên, nếu việc triển khai thiết bị không hỗ trợ hệ thống nhập con trỏ, thì thiết bị KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.touchscreen hoặc android.hardware.faketouch. Các phương thức triển khai thiết bị có hệ thống nhập con trỏ:

PHẢI 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, 40] tương ứng với loại màn hình cảm ứng cụ thể trên thiết bị

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

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

Các thiết bị khai báo hỗ trợ android.hardware.faketouch.multitouch.distinct PHẢI đáp ứng các yêu cầu về tính năng chạm giả ở trên và cũng PHẢI 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. 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 dưới dạng 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ề chất lượng âm thanh trong Mục 5.4
PHẢI đáp ứng các yêu cầu về độ trễ âm thanh trong Mục 5.5

7.3. Cảm biến

Android 4.3 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í dụ: 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, 37]
PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự
PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về true hoặc false khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.)
PHẢI báo cáo tất cả các phép đo cảm biến bằng cách sử dụng các giá trị Hệ thống đo lường quốc tế (tức là hệ mét) 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, 41]

Danh sách trên chưa đầy đủ; hành vi được ghi nhận của SDK Android sẽ được coi là có thẩm quyền.

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

Android 4.3 bao gồm khái niệm về cảm biến "truyền trực tuyến", là cảm biến trả về dữ liệu liên tục thay vì chỉ khi dữ liệu thay đổi. 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ỳ cho mọi API mà tài liệu SDK Android 4.3 chỉ định là cảm biến truyền trực tuyến. Xin lưu ý rằng việc triển khai thiết bị PHẢI đảm bảo rằng luồng cảm biến không được ngăn CPU thiết bị chuyển sang trạng thái tạm ngưng hoặc đánh thức từ trạng thái tạm ngưng.

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. Nếu quá trình triển khai thiết bị có bao gồm gia tốc kế 3 trục, thì thiết bị đó:

PHẢI có thể phân phối sự kiện ở tốc độ 120 Hz trở lên. Xin lưu ý rằng mặc dù tần số của gia tốc kế ở trên được nêu là "NÊN" đối với Android 4.3, nhưng Định nghĩa về khả năng tương thích cho một phiên bản trong tương lai dự kiến sẽ thay đổi các tần số này thành "PHẢI". Tức là các tiêu chuẩn này là không bắt buộc trong Android 4.3 nhưng 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 Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai
PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android (xem [Tài nguyên, 41])
PHẢI có khả năng đo lường từ trạng thái rơi tự do lên đến gấp đôi trọng lực (2g) trở lên trên mọi vectơ ba chiều
PHẢI có độ chính xác 8 bit trở lên
PHẢI có độ lệch chuẩn không lớn hơn 0,05 m/s^2

7.3.2. Từ kế

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

PHẢI có khả năng phân phối sự kiện ở tốc độ 10 Hz trở lên
PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android (xem [Tài nguyên, 41]).
PHẢI có khả năng lấy mẫu một dải cường độ trường đủ để bao phủ từ trường địa cầu
PHẢI có độ chính xác 8 bit trở lên
PHẢI có độ lệch chuẩn không lớn hơn 0,5 µT

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 (tức là 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 được bù trừ nhiệt độ
PHẢI có khả năng đo lường các thay đổi về hướng lên đến 5,5*Pi radian/giây (tức là khoảng 1.000 độ/giây)
PHẢI có thể phân phối sự kiện ở tốc độ 200 Hz trở lên. Xin lưu ý rằng mặc dù tần số con quay hồi chuyển ở trên được nêu là "NÊN" đối với 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 tần số này thành "PHẢI". Tức là các tiêu chuẩn này là không bắt buộc trong Android 4.3 nhưng 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 Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai
PHẢI có độ chính xác 12 bit trở lên
PHẢI có độ biến thiên không lớn hơn 1e-7 rad^2 / s^2 trên mỗi Hz (độ biến thiên trên mỗi Hz hoặc rad^2 / s). Độ lệch được phép thay đổi theo tốc độ lấy mẫu, nhưng phải bị ràng buộc bởi giá trị này. Nói cách khác, nếu bạn đo phương sai của con quay hồi chuyển ở tốc độ lấy mẫu 1 Hz, thì phương sai đó không được lớn hơn 1e-7 rad^2/s^2.
PHẢI có dấu thời gian gần với thời điểm xảy ra sự kiện phần cứng nhất có thể. Bạn phải xoá độ trễ không đổi.

7.3.5. Khí áp kế

Việc triển khai thiết bị CÓ THỂ bao gồm một khí áp kế (tức là 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 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Ể nhưng KHÔNG NÊN bao gồm nhiệt kế (tức là cảm biến nhiệt độ). Nếu việc triển khai thiết bị có bao gồm nhiệt kế, thì thiết bị đó PHẢI đo nhiệt độ của CPU thiết bị. Thiết bị này KHÔNG ĐƯỢC đo lường bất kỳ nhiệt độ nào khác. (Xin lưu ý rằng loại cảm biến này không còn được dùng trong API Android 4.3.)

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

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

7.4.1. Điện thoại

"Telephony" (Dịch vụ điện thoại) được các API Android 4.3 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ể hoặc không thể chuyển đổi gói, nhưng đối với Android 4.3, các cuộc gọi này được coi là độc lập với mọi kết nối dữ liệu có thể được triển khai bằng cùng một mạng. Nói cách khác, chức năng và API "điện thoại" của Android đề cập cụ thể đến cuộc gọi thoại và SMS; ví dụ: các phương thức triển khai thiết bị không thể thực hiện cuộc gọi hoặc gửi/nhận tin nhắn SMS KHÔNG ĐƯỢC báo cáo tính năng "android.hardware.telephony" hoặc bất kỳ tính năng phụ nào, bất kể các tính năng đó có sử dụng mạng di động để kết nối dữ liệu hay không.

Android 4.3 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 4.3 tương thích với các thiết bị không phải điện thoại. Tuy nhiên, nếu việc triển khai thiết bị bao gồm cả điện thoại GSM hoặc CDMA, thì thiết bị đó PHẢI triển khai hỗ trợ đầy đủ cho API cho công nghệ đó. 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 đầy đủ các API dưới dạng không hoạt động.

7.4.2. IEEE 802.11 (Wi-Fi)

Việc triển khai thiết bị Android 4.3 PHẢI hỗ trợ một hoặc nhiều dạng 802.11 (b/g/a/n, v.v.) Nếu việc triển khai thiết bị có hỗ trợ 802.11, thì thiết bị đó PHẢI triển khai API Android tương ứng.

Việc triển khai thiết bị PHẢI triển khai API đa truy cập như mô tả trong tài liệu SDK [Tài nguyên, 62]. Các hoạt động triển khai thiết bị có hỗ trợ Wifi PHẢI hỗ trợ DNS đa địa chỉ (mDNS). Việc triển khai thiết bị KHÔNG ĐƯỢC lọc gói mDNS (224.0.0.251) tại bất kỳ thời điểm hoạt động nào, 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ợ Wifi trực tiếp (Wifi ngang hàng). Nếu việc triển khai thiết bị có hỗ trợ Wifi trực tiếp, 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, 68]. Nếu việc triển khai thiết bị có hỗ trợ Wi-Fi trực tiếp, thì thiết bị đó:

PHẢI hỗ trợ hoạt động Wi-Fi thông thường
NÊN hỗ trợ hoạt động đồng thời của wifi và wifi Direct

7.4.3. Bluetooth

Việc triển khai thiết bị PHẢI bao gồm một bộ thu phát Bluetooth. Các hoạt động triển khai thiết bị có bộ thu phát Bluetooth PHẢI bật API Bluetooth dựa trên RFCOMM như mô tả trong tài liệu SDK và khai báo tính năng phần cứng android.hardware.bluetooth [Tài nguyên, 42]. Việc triển khai thiết bị PHẢI triển khai các hồ sơ Bluetooth có liên quan, chẳng hạn như A2DP, AVRCP, OBEX, v.v. sao cho phù hợp với thiết bị.

Các hoạt động triển khai thiết bị có hỗ trợ Bluetooth GATT (hồ sơ thuộc tính chung) để cho phép giao tiếp với các thiết bị Bluetooth Smart hoặc Smart Ready PHẢI bật API Bluetooth dựa trên GATT như mô tả trong tài liệu SDK và khai báo tính năng phần cứng android.hardware.bluetooth_le [Tài nguyên, 42].

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 quá trình triển khai thiết bị có bao gồm phần cứng NFC, 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, 37]
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 (như được xác định trong quy cách kỹ thuật của 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" đối với Android 4.3, nhưng Định nghĩa về khả năng tương thích cho một 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". Tức là các tiêu chuẩn này không bắt buộc trong Android 4.3 nhưng bắt buộc trong các phiên bản sau này. Các thiết bị hiện có và mới chạy Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để 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 tiêu chuẩn và giao thức 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, 43]
- SNEP 1.0 (do NFC Forum xác định)
PHẢI hỗ trợ Android Beam [Tài nguyên, 65]:
- PHẢI triển khai máy chủ mặc định SNEP. Các thông báo NDEF hợp lệ mà máy chủ SNEP mặc định nhận được PHẢI được gửi đến các ứng dụng bằng cách sử dụng ý định android.nfc.ACTION_NDEF_DISCOVERED. Việc tắt tính năng Android Beam trong phần cài đặt KHÔNG ĐƯỢC tắt tính năng gửi thông báo NDEF đến.
- Việc triển khai thiết bị PHẢI tuân thủ ý định android.settings.NFCSHARING_SETTINGS để hiển thị chế độ cài đặt chia sẻ NFC [Tài nguyên, 67].
- PHẢI triển khai máy chủ NPP. Thông báo mà máy chủ NPP nhận được PHẢI được xử lý giống như máy chủ mặc định SNEP.
- PHẢI triển khai ứng dụng SNEP và cố gắng gửi NDEF P2P đi đến máy chủ SNEP mặc định khi bật Android Beam. Nếu không tìm thấy máy chủ SNEP mặc định, thì ứng dụng PHẢI cố gắng gửi đến máy chủ NPP.
- PHẢI cho phép các hoạt động trên nền trước đặt thông báo NDEF P2P đi bằng cách sử dụng android.nfc.NfcAdapter.setNdefPushMessage, 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.
- NÊN bật Android Beam theo mặc định
- 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, 60] và "Ghép nối đơn giản và an toàn qua Bluetooth bằng NFC phiên bản 1.0" [Tài nguyên, 61] của NFC Forum. Việc triển khai như vậy PHẢI sử dụng các yêu cầu SNEP GET để trao đổi yêu cầu chuyển giao / 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ế.
PHẢI thăm dò ý kiến về tất cả các công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
PHẢI ở chế độ khám phá NFC khi thiết bị ở trạng thái thức, màn hình đang hoạt động và màn hình khoá đã mở khoá.

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

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 (NXP MF1S503x [Tài nguyên, 44], MF1S703x [Tài nguyên, 45])
MIFARE Ultralight (NXP MF0ICU1 [Tài nguyên, 46], MF0ICU2 [Tài nguyên, 47])
NDEF trên MIFARE Classic (NXP AN130511 [Tài nguyên, 48], AN130411 [Tài nguyên, 49])

Xin lưu ý rằng Android 4.3 bao gồm 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, 37] 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, 37] và PHẢI triển khai API NFC Android 4.3 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, v.v.

Việc triển khai thiết bị mà tiêu chuẩn kết nối mạng vật lý (chẳng hạn như Ethernet) là kết nối dữ liệu chính CŨNG NÊN 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.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ự.

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 quá trình triển khai thiết bị có máy ảnh mặt sau, thì thiết bị đó:

PHẢI có độ phân giải tối thiểu là 2 megapixel
PHẢI có tính năng tự động lấy nét phần cứng hoặc tự động lấy nét phần mềm được triển khai 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 camera 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 của 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 quá trình triển khai thiết bị có máy ảnh mặt trước, thì thiết bị đó:

PHẢI có độ phân giải tối thiểu là VGA (tức là 640x480 pixel)
KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm mặc định cho Camera API. Tức là API máy ảnh trong Android 4.3 có hỗ trợ cụ thể cho camera trước và việc triển khai thiết bị KHÔNG ĐƯỢC định cấu hình API để coi camera trước là camera sau mặc định, ngay cả khi đó là camera duy nhất trên thiết bị.
CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, đèn flash, v.v.) dành cho máy ảnh mặt sau như mô tả trong 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 Camera thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation() [Tài nguyên, 50], 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 ánh luồng video hoặc hình ảnh tĩnh đã chụp cuối cùng được trả về cho lệnh gọi lại ứng dụng hoặc được cam kết lưu vào bộ nhớ phương tiện

7.5.3. Hành vi của Camera API

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 cả máy ảnh mặt trước và mặt sau:

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.
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 đối với cả máy ảnh mặt trước và mặt sau. (Máy quay và bộ mã hoá video phần cứng có thể sử dụng bất kỳ định dạng pixel gốc nào, nhưng việc triển khai thiết bị PHẢI hỗ trợ chuyển đổi sang YV12.)

Việc triển khai thiết bị PHẢI triển khai toàn bộ API Máy ảnh có trong tài liệu SDK Android 4.3 [Tài nguyên, 51]), 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ả.

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

Việc triển khai thiết bị PHẢI truyền phát ý định Camera.ACTION_NEW_PICTURE bất cứ khi nào máy ảnh chụp một 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 phát ý định Camera.ACTION_NEW_VIDEO mỗi khi máy ảnh ghi lại một video mới và mục nhập của ảnh đã được thêm vào kho phương tiện.

7.5.4. 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. Nghĩa là khi thiết bị được giữ ở hướng ngang, máy ảnh PHẢI chụp ảnh ở 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

Việc triển khai thiết bị PHẢI có ít nhất 340 MB bộ nhớ cho hạt nhân và không gian người dùng. 340 MB PHẢI là bộ nhớ bổ sung cho mọi bộ nhớ chuyên dụ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 nhân.

Việc triển khai thiết bị PHẢI có ít nhất 512 MB 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à 512 MB. Các thiết bị triển khai chạy Android 4.3 nên có ít nhất 1GB bộ nhớ không bay hơi cho dữ liệu riêng tư của ứng dụng để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.

API Android bao gồm một Trình quản lý tải xuống mà các ứng dụng có thể sử dụng để tải tệp dữ liệu xuống [Tài nguyên, 56]. 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 là 100 MB xuống vị trí "bộ nhớ đệm" mặc định.

7.6.2. Bộ nhớ dùng chung của ứng dụng

Quá trình triển khai thiết bị PHẢI cung cấp bộ nhớ dùng chung cho các ứng dụng. Dung lượng lưu trữ dùng chung được cung cấp PHẢI có kích thước tối thiểu là 1 GB.

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ị PHẢI thực thi quyền android.permission.WRITE_EXTERNAL_STORAGE trên bộ nhớ dùng chung này như đã ghi nhận. Nếu không, mọi ứng dụng có quyền đó PHẢI ghi được vào bộ nhớ dùng chung.

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ư thẻ Secure Digital. Ngoài ra, quá trình triển khai thiết bị CÓ THỂ phân bổ bộ nhớ trong (không thể tháo rời) làm bộ nhớ dùng chung cho các ứng dụng.

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 NÊN sử dụng Giao thức chuyển phương tiện. Nếu cách triển khai thiết bị hỗ trợ Giao thức truyền nội dung nghe nhìn:

Việc triển khai 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, 57].
Việc triển khai thiết bị PHẢI báo cáo lớp thiết bị USB là 0x00.
Quá trình triển khai thiết bị PHẢI 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.

Hãy xem xét hai ví dụ phổ biến để minh hoạ điều này. Nếu việc triển khai thiết bị bao gồm khe cắm thẻ SD để đáp ứng yêu cầu về bộ nhớ dùng chung, thì thiết bị bán cho người dùng PHẢI có thẻ SD có định dạng FAT có dung lượng từ 1 GB trở lên và PHẢI được gắn theo mặc định. Ngoài ra, nếu việc triển khai thiết bị sử dụng bộ nhớ cố định trong để đáp ứng yêu cầu này, 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ị 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 sửa đổi các ứng dụng cốt lõi như trình quét nội dung nghe nhìn và ContentProvider để hỗ trợ minh bạch các tệp được đặt ở cả hai vị trí.

7.7. USB

Quá trình triển khai thiết bị PHẢI bao gồm cổng ứng dụng USB và PHẢI bao gồm cổng máy chủ USB.

Nếu quá trình triển khai thiết bị bao gồm cổng ứng dụng USB:

cổng PHẢI kết nối được với máy chủ USB có cổng USB-A tiêu chuẩn
cổng PHẢI sử dụng kiểu dáng USB vi mô ở phía thiết bị. Các thiết bị hiện tại và mới chạy Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để 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 ở giữa cạnh. Việc triển khai thiết bị PHẢI đặt cổng ở cuối thiết bị (theo hướng tự nhiên) hoặc bật tính năng xoay màn hình phần mềm cho tất cả ứ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ị hướng cổng ở dưới cùng. Các thiết bị hiện có và mới chạy Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai.
nếu thiết bị có các cổng khác (chẳng hạn như cổng sạc không phải USB), thì các cổng đó PHẢI nằm trên cùng một cạnh với cổng sạc micro-USB
ứng dụng PHẢI cho phép máy chủ được kết nối với thiết bị truy cập vào nội dung của bộ nhớ dùng chung bằng cách sử dụng bộ nhớ khối lượng lớn USB hoặc Giao thức truyền nội dung đa phương tiện
PHẢI triển khai API và thông số kỹ thuật của Phụ kiện mở Android như được ghi nhận trong tài liệu SDK Android, đồng thời PHẢI khai báo hỗ trợ tính năng phần cứng android.hardware.usb.accessory [Tài nguyên, 52]
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, 66]
NÊN triển khai tính năng hỗ trợ thông số kỹ thuật sạc pin qua USB [Tài nguyên, 64] Các thiết bị hiện có và mới chạy Android 4.3 nên đáp ứng các yêu cầu này trong Android 4.3 để có thể nâng cấp lên các bản phát hành nền tảng trong tương lai

Nếu việc triển khai thiết bị bao gồm cổng máy chủ USB:

thiết bị ĐƯỢC PHÉP sử dụng hệ số hình dạng cổng không chuẩn, nhưng nếu có, PHẢI đi kèm với cáp hoặc cáp chuyển đổi cổng sang USB-A tiêu chuẩn
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, 53]

Việc triển khai thiết bị PHẢI triển khai Cầu gỡ lỗi Android. Nếu quá trình triển khai thiết bị bỏ qua cổng ứng dụng 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)

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

Việc triển khai thiết bị PHẢI đáp ứng các chỉ số hiệu suất chính của một thiết bị tương thích với Android 4.3 được xác định trong bảng dưới đây:

Chỉ số	Ngưỡng hiệu suất	Nhận xét
Thời gian chạy ứng dụng	Các ứng dụng sau đây sẽ khởi chạy trong thời gian đã chỉ định. Trình duyệt: dưới 1300 mili giây Danh bạ: dưới 700 mili giây Cài đặt: dưới 700 mili giây	Thời gian khởi chạy được đo bằng tổng thời gian để hoàn tất việc tải hoạt động mặc định cho ứng dụng, bao gồm cả thời gian cần thiết để bắt đầu quy trình Linux, tải gói Android vào máy ảo Dalvik và gọi onCreate.
Ứng dụng đồng thời	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 thời gian hơn thời gian khởi chạy ban đầu.

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

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

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 máy ảo 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ả ở phần khác trong Mục 9.

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

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

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

Thời gian chạy thay thế PHẢI cài đặt ứng dụng thông qua PackageManager vào các hộp cát Android riêng biệt (tức là mã nhận dạng người dùng Linux, v.v.)
Môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android duy nhất do tất cả ứng dụng sử dụng môi trường thời gian chạy thay thế chia sẻ
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ý
Môi trường thời gian chạy thay thế 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, cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của người dùng cấp cao (gốc) hoặc của bất kỳ mã nhận dạng người dùng nào khác trong môi trường thời gian chạy thay thế.

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ó đượ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. Tức là 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

Android 4.3 hỗ trợ nhiều người dùng và hỗ trợ tách biệt hoàn toàn người dùng [Tài nguyên, 70].

Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu sau đây liên quan đến việc hỗ trợ nhiều người dùng [Tài nguyên, 71]:

Vì hành vi của các API điện thoại trên thiết bị có nhiều người dùng hiện chưa được xác định, nên các phương thức triển khai thiết bị khai báo android.hardware.telephony KHÔNG ĐƯỢC bật tính năng hỗ trợ nhiều người dùng.
Đối với mỗi người dùng, việc triển khai thiết bị PHẢI triển khai 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, 54]
Android 4.3 hỗ trợ hồ sơ bị hạn chế, một tính năng cho phép chủ sở hữu thiết bị quản lý người dùng khác và các quyền của họ trên thiết bị. Với hồ sơ bị hạn chế, chủ sở hữu thiết bị có thể nhanh chóng thiết lập các môi trường riêng biệt để người dùng khác làm việc, đồng thời có thể quản lý các quy định hạn chế chi tiết hơn trong các ứng dụng có trong những môi trường đó. Việc triển khai thiết bị hỗ trợ nhiều người dùng PHẢI hỗ trợ các hồ sơ bị hạn chế. Dự án nguồn mở Android cấp trên có một cách triển khai đáp ứng yêu cầu này.

Mỗi phiên bản người dùng trên thiết bị Android PHẢI có các thư mục bộ nhớ ngoài riêng biệt và tách biệt. Việc triển khai thiết bị CÓ THỂ lưu trữ dữ liệu của nhiều người dùng trên cùng một phương tiện hoặc hệ thống tệp. Tuy nhiên, việc triển khai thiết bị PHẢI đảm bảo rằng các ứng dụng thuộc sở hữu và chạy thay mặt cho một người dùng nhất định không thể liệt kê, đọc hoặc ghi vào dữ liệu thuộc sở hữu của bất kỳ người dùng nào khác. Xin lưu ý rằng phương tiện có thể tháo rời, chẳng hạn như khe cắm thẻ SD, có thể cho phép một người dùng truy cập vào dữ liệu của người dùng khác thông qua máy tính lưu trữ. Vì lý do này, việc triển khai thiết bị sử dụng phương tiện có thể tháo rời cho các API bộ nhớ ngoài PHẢI mã hoá nội dung của thẻ SD nếu chế độ nhiều người dùng được bật bằng cách sử dụng khoá chỉ được lưu trữ trên phương tiện không thể tháo rời mà chỉ hệ thống mới truy cập được. Vì điều này sẽ khiến máy tính lưu trữ không đọc được nội dung nghe nhìn, nên việc triển khai thiết bị sẽ yêu cầu chuyển sang MTP hoặc một hệ thống tương tự để cấp cho máy tính lưu trữ quyền truy cập vào dữ liệu của người dùng hiện tại. Do đó, việc triển khai thiết bị CÓ THỂ nhưng KHÔNG NÊN cho phép nhiều người dùng nếu họ sử dụng phương tiện có thể tháo rời [Tài nguyên, 72] cho bộ nhớ ngoài chính. Dự án nguồn mở Android ngược dòng bao gồm một phương thức triển khai sử dụng bộ nhớ trong của thiết bị cho các API bộ nhớ ngoài của ứng dụng; các phương thức triển khai thiết bị PHẢI sử dụng cấu hình và phương thức triển khai phần mềm này. Việc triển khai thiết bị có nhiều đường dẫn bộ nhớ ngoài KHÔNG ĐƯỢC cho phép các ứng dụng Android ghi vào bộ nhớ ngoài phụ.

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

Android 4.3 hỗ trợ cảnh báo người dùng về mọi tin nhắn SMS dịch vụ gửi đi [Tài nguyên, 73] . 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 trên 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

Android Sandbox trong Android 4.3 bao gồm các tính năng có thể sử dụng hệ thống kiểm soát quyền truy cập bắt buộc (MAC) của SELinux và các tính năng bảo mật khác trong hạt nhân Linux. Việc triển khai thiết bị PHẢI hỗ trợ MAC SELinux. Xin lưu ý rằng Dự án nguồn mở Android cấp trên cung cấp một phương thức triển khai đáp ứng yêu cầu này.

SELinux hoặc bất kỳ tính năng bảo mật nào đượ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ó. Người dùng và nhà phát triển KHÔNG được thấy các tính năng này. Người dùng hoặc nhà phát triển KHÔNG ĐƯỢC định cấu hình các tính năng này. Nếu bất kỳ API nào để định cấu hình chính sách được hiển thị cho một ứng dụng có thể ảnh hưởng đến một ứng dụng khác (chẳng hạn như API Quản trị thiết bị), thì API KHÔNG ĐƯỢC cho phép các cấu hình làm hỏng khả năng tương thích. Để đảm bảo khả năng tương thích liên tục, việc triển khai tham chiếu cho phép sử dụng SELinux ở chế độ cho phép và hỗ trợ cập nhật chính sách động mà không yêu cầu cập nhật hình ảnh hệ thống. Việc triển khai thiết bị bằng SELinux PHẢI hỗ trợ chế độ cho phép này, hỗ trợ cập nhật chính sách động và ghi lại mọi lỗi vi phạm chính sách mà không làm hỏng ứng dụng hoặc ảnh hưởng đến hành vi của hệ thống. Các phương thức triển khai sử dụng SELinux PHẢI tải chính sách từ tệp /sepolicy trên 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. Việc triển khai thiết bị PHẢI sử dụng phương thức triển khai tham chiếu trong Dự án nguồn mở Android và phương thứ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.

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 ưu tiên của Android 4.3 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, yêu cầu 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, 2] 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à cho mọi lần triển khai lại các phần của mã nguồn tham chiếu.

CTS được thiết kế để chạy trên một thiết bị thực. Giống như mọi phần mềm khác, chính CTS cũng có thể chứa lỗi. CTS sẽ được tạo phiên bản độc lập với Định nghĩa về khả năng tương thích này và có thể phát hành nhiều bản sửa đổi của CTS cho Android 4.3. Việc triển khai thiết bị PHẢI vượt qua phiên bản CTS mới nhất có sẵn 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

Quá trình triển khai thiết bị PHẢI thực thi chính xác tất cả các trường hợp 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 theo 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.

10.3. Ứng dụng tham khảo

Người triển khai thiết bị PHẢI kiểm thử khả năng tương thích của quá trình triển khai bằng các ứng dụng nguồn mở sau:

Ứng dụng "Apps for Android" (Ứng dụng cho Android) [Tài nguyên, 55]
Replica Island (có trong Cửa hàng Google Play)

Mỗi ứng dụng ở trên PHẢI khởi chạy và hoạt động chính xác trong quá trình triển khai để quá trình triển khai được coi là tương thích.

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 các bản nâng cấp "trực tiếp" – nghĩa là bạn CÓ THỂ phải khởi động lại thiết bị.

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

Tải xuống qua mạng không dây (OTA) 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

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 bao gồm một cơ chế cập nhật đá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 thiết bị đó được phát hành nhưng trong thời gian sử dụng sản phẩm hợp lý được xác định khi 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 ứng dụng bên thứ ba, thì bên triển khai thiết bị PHẢI khắc phục lỗi thông qua bản cập nhật phần mềm hiện có có thể áp dụng theo cơ chế vừa mô tả.

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

Bạn có thể liên hệ với tác giả tài liệu theo địa chỉ compatibility@android.com để làm rõ và nêu bất kỳ vấn đề nào mà bạn cho rằng tài liệu chưa đề cập.