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.1
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

7.3.1. Accelerometer
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. Thermometer
7.3.7. Photometer
7.3.8. Cảm biến độ gần
7.4. Khả năng kết nối dữ liệu
7.4.1. Dịch vụ đ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 phạm vi gần
7.4.5. Khả năng mạng tối thiểu
7.5. Máy ảnh
7.5.1. Máy ảnh sau
7.5.2. Máy ảnh mặt trước
7.5.3. 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ới hiệu suất
9. Khả năng tương thích với mô hình bảo mật
9.1. Quyền
9.2. UID và Quy trình phân ly
9.3. Quyền trên hệ thống tệp
9.4. Môi trường thực thi thay thế
10. Kiểm thử khả năng tương thích của phần mềm
10.1. Bộ kiểm thử tính tương thích
10.2. Trình xác minh CTS
10.3. Ứng dụng tham khảo
11. Uphần mềm có thể cập nhật
12. Liên hệ với chúng tôi
Phụ lục A - Quy trình kiểm tra Bluetooth

1. Giới thiệu
Tài liệu này liệt kê các yêu cầu phải đáp ứng để các thiết bị
tương thích với Android 4.1.
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.1. "Triển khai
thiết bị" hoặc "triển khai" là giải pháp phần cứng/phần mềm được phát triển.
Để được coi là tương thích với Android 4.1, việc triển khai thiết bị PHẢI đáp ứng
các yêu cầu được nêu trong Định nghĩa về khả năng tương thích này, bao gồm mọi tài liệu
được đưa vào thông qua tham chiếu.
Trường hợp định nghĩa này hoặc các kiểm thử phần mềm được mô tả trong Mục 10 không có nội dung,
mơ hồ hoặc chưa hoàn tất, thì nhà phát triểntriển khai thiết bị phải chịu trách nhiệm đảm bảo
khả năng tương thích với các biện pháp triển khai hiện có.
Vì lý do này, Dự án nguồn mở Android [Tài nguyên, 3] là cả tài liệu tham khảo
và phương thức triển khai ưu tiên của Android. Nhà triển khai thiết bị nên
tích cực
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 dù một số thành phần
có thể được thay thế bằng các cách triển khai thay thế, nhưng bạn không nên làm điều này, vì việc đạt được các kiểm thử phần mềm sẽ trở nên
khó khăn hơn rất nhiều.
Người triển khai có trách nhiệm đảm bảo khả năng tương thích đầy đủ của
hành vi với cách triển khai Android chuẩn, bao gồm cả Bộ kiểm thử khả năng tương thích
. Cuối cùng, hãy lưu ý rằng một số thay thế thành phần và các sửa đổi
được tài liệu này cấm rõ ràng.
2. Tài nguyên
1.  Các cấp độ yêu cầu của IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2.  Tổng quan về Chương trình tương thích của Android:
http://source.android.com/compatibility/index.html
3.  Dự án nguồn mở Android: http://source.android.com/
4.  Định nghĩa và tài liệu về API:
http://developer.android.com/reference/packages.html
5.  Tài liệu tham khảo về Quyền trên Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Tài liệu tham khảo android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Android 4.1 cho phép các chuỗi phiên bản:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Tăng tốc phần cứng:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Lớp android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Các tính năng ngoại tuyến của HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Thẻ video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  HTML5/API định vị trên mặt đất của W3C: http://www.w3.org/TR/geolocation-API/
15.  Cơ sở dữ liệu web API HTML5/W3C: http://www.w3.org/TR/webdatabase/
16.  HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.  Thông số kỹ thuật của Máy ảo Dalvik: có trong mã nguồn Android, tại
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Thông báo:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Tài nguyên ứng dụng: http://code.google.com/android/reference/available-
resources.html
21.  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
22.  Trình quản lý tìm kiếm:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Thông báo ngắn: http://developer.android.com/reference/android/widget/Toast.html
24.  Giao diện: http://developer.android.com/guide/topics/ui/themes.html

25.  Lớp R.style: http://developer.android.com/reference/android/R.style.html
26.  Hình nền trực tiếp: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Quản trị thiết bị Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  Lớp android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  API Dịch vụ hỗ trợ tính năng hỗ trợ trên Android:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  API Hỗ trợ tiếp cận của Android:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Dự án Eyes Free: http://code.google.com/p/eyes-free
32.  API Chuyển văn bản sang lời nói:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Tài liệu tham khảo về công cụ (dành cho adb, aapt, dms):
http://developer.android.com/guide/developing/tools/index.html
34.  Nội dung mô tả tệp apk Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  Tệp kê khai: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Công cụ kiểm thử Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Lớp Android android.content.pm.PackageManager và các tính năng của Phần cứng
Danh sách:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  Hỗ trợ nhiều màn hình:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  Bluetooth API:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Giao thức đẩy NDEF: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API hướng máy ảnh:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53.  USB Host API: http://developer.android.com/guide/topics/usb/host.html
54.  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
55.  Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android
56.  Lớp android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  Các định dạng đa phương tiện Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  Draft Protocol của HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  Chuyển kết nối NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Ghép nối Bluetooth an toàn và đơn giản bằng NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  Wifi Multicast API:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Hỗ trợ hành động:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Thông số kỹ thuật sạc qua USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Âm thanh USB Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Cài đặt chia sẻ NFC trên Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Ứng dụng điều khiển từ xa cho nội dung đa phương tiện:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Cấu hình đầu vào cảm ứng: http://source.android.com/tech/input/touch-
devices.html
Nhiều tài nguyên trong đó được trích dẫn trực tiếp hoặc gián tiếp từ SDK Android 4.1,
và sẽ có chức năng giống hệt với thông tin trong tài liệu của SDK đó. Trong mọi
trường hợp mà Định nghĩa 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 được xem là tài liệu chính thống. Mọi
chi tiết kỹ thuật được cung cấp trong tài liệu tham khảo có trong phần trên đều được xem là một phần của Định nghĩa khả năng tương thích này theo
.
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
được hiển thị cho các ứng dụng chạy trong môi trường máy ảo
được quản lý. Các hoạt động triển khai thiết bị PHẢI cung cấp hoạt động triển khai đầy đủ,
bao gồm tất cả hành vi đã được ghi nhận của bất kỳ API đã được ghi nhận nào do SDK Android
4.1 hiển thị [Tài nguyên, 4].
Các hoạt động triển khai thiết bị MPHẢI KHÔNG bỏ qua bất kỳ API được quản lý nào, thay đổi giao diện API hoặc
chữ ký, bỏ qua hành vi đã ghi nhận, hoặc bao gồm không có thao tác nào, ngoại trừ trường hợp
cụ thể y al do Định nghĩa khả năng tương thích này.
Đị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, các API PHẢI
vẫn  có mặt và hoạt động theo cách hợp lý. Xem Phần 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 với API mềm
Ngoài các API được quản lý trong Phần 3.1, Android cũng bao gồm một API "mềm" quan trọng
chỉ 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 mà không thể thực thi tại thời điểm biên dịch ứng dụng
.
3.2.1. Quyền
Trình triển khai thiết bị PHẢI hỗ trợ và thực thi tất cả các hằng số quyền dưới dạng
được ghi nhận trên trang tài liệu Quyền [Tài nguyên, 5]. Xin lưu ý rằng Phần 10
liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật Android.
3.2.2. Thông số bản dựng
Các 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ị
ý nghĩa,nhất quán trên các phương thức triển khai thiết bị, bảng bên dưới 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à các phương thức triển khai thiết bị PHẢI
tuân thủ.
Thông số
Nhận xét
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
android.os.Build.VERSION.RELEASE
trong các giá trị chuỗi được xác định trong [Tài nguyên, 7].
Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng của bên thứ ba có thể truy cập.
android.os.Build.VERSION.SDK
Đối với Android 4.1, trường này PHẢI có giá trị số nguyên là 16.

Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng của bên thứ ba có thể truy cập.
android.os.Build.VERSION.SDK_INT
Đối với Android 4.1, trường này PHẢI có giá trị số nguyên là 16.
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 giới hạn được cung cấp cho người dùng cuối
android.os.Build.VERSION.INCREMENTAL
. Cách sử dụng thông thường của trường này là để cho biết số bản ghép hoặc mã nhận dạng thay đổi kiểm soát nguồn đã
dùng để tạo bản ghép. 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 PHẢI
KHÔNG là giá trị rỗng hoặc chuỗi rỗng ("").
Giá trị do người triển khai thiết bị chọn để xác định phần cứng nội bộ cụ thể mà thiết bị sử dụng, ở
định dạng mà con người có thể đọc. Bạn có thể sử dụng trường này để cho biết bản sửa đổi cụ thể của bảng điều khiển cung cấp năng lượng
android.os.Build.BOARD
cho thiết bị. Giá trị của trường này PHẢI mã hoá được dưới dạng ASCI 7 bit và khớp với biểu thức chính quy
"^[a-zA-Z0-9.,_-]+$".
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 OEM
android.os.Build.BRAND
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 ASCI 7 bit và khớp với biểu thức chính quy
"^[a-zA-Z0-9.,_-]+$".
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 của API gốc
android.os.Build.CPU_ABI
.
Tên của bộ hướng dẫn 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 của API
android.os.Build.CPU_ABI2
gốc.
Một giá trị do trình triển khai thiết bị chọn để xác định cấu hình hoặc bản sửa chữa cụ thể của thiết bị
android.os.Build.DEVICE
(đôi khi 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 mã hoá được dưới dạng 7 bit
ASCI và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
Một chuỗi nhận dạng duy nhất bản dựng này. Tên PHẢI dễ đọc một cách hợp lý. Phải tuân theo mẫu
này:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Ví dụ:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/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 ghép bằng một ký tự khác, chẳng hạn như ký tự dấu dưới
("_"). Giá trị của trường này PHẢI mã hoá được dưới dạng ASCI 7 bit.
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 có thể đọc được một cách hợp lý theo cách
android.os.Build.HARDWARE
. Giá trị của trường này PHẢI mã hoá được dưới dạng ASCI 7 bit và khớp với biểu thức chính quy "^[a-
zA-Z0-9.,_-]+$".
Một chuỗi nhận dạng duy nhất máy chủ lưu trữ mà bản dựng được tạo, ở định dạng mà con người có thể đọc được. Không có yêu cầu
android.os.Build.HOST
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 ("").
Mã 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 như android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị đủ
android.os.Build.ID
ý nghĩa cho người dùng cuối để phân biệt giữa các bản giới hạn phần mềm. Giá trị của trường này PHẢI mã hoá được
dưới dạng ASCI 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
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ề
android.os.Build.MANUFACTURER
đị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 ("").
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.
android.os.Build.MODEL
NÊN là tên tiếp thị và bán thiết bị cho người dùng cuối. Không có yêu cầu
đối với đị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 ("").
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
android.os.Build.PRODUCT
(SKU). PHẢI là thông tin mà con người có thể đọc được, nhưng không nhất thiết phải dành cho người dùng cuối. Giá trị của trường
này PHẢI mã hoá được dưới dạng ASCI 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
Số sê-ri phần cứng, nếu có. Giá trị của trường này PHẢI được mã hoá dưới dạng ASCI 7 bit và khớp với
android.os.Build.SERIAL
biểu thức chính quy "^([a-zA-Z0-9]{0,20})$".
Danh sách 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ụ về
android.os.Build.TAGS
: "unsigned,debug". Giá trị của trường này PHẢI mã hoá được dưới dạng ASCI 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.
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",
android.os.Build.TYPE
"userdebug", hoặc "eng". Giá trị của trường này PHẢI mã hoá được dưới dạng ASCI 7 bit và khớp với biểu thức chính quy
"^[a-zA-Z0-9.,_-]+$".
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ề
android.os.Build.USER
đị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 ("").
3.2.3. Khả năng tương thích với ý định
Các hoạt động 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 dưới đây. "Đượ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 và triển khai hành vi chính xác cho từng mẫu Ý định được chỉ định.
3.2.3.1. Ý định ứng dụng lõi
Dự án Android upstream xác định một số ứng dụng lõi, chẳng hạn như danh bạ,
lịch, thư viện ảnh, trình phát nhạc, v.v. Người 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, bất kỳ phiên bản thay thế nào cũng PHẢI tuân thủ cùng mẫu Ý định do dự án trước cung cấp
. Ví dụ: nếu một thiết bị chứa một trình phát nhạc thay thế,
thì thiết bị đó vẫn phải tuân theo 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 xem là các ứng dụng hệ thống Android chính:
Đồng hồ bàn
Trình duyệt web
Lịch
Danh bạ
Thư viện
Tìm kiếm toàn cầu
Trình chạy
Âm nhạc
Cài đặt
Các ứng dụng hệ thống Android chính bao gồm nhiều thành phần Hoạt động hoặc Dịch vụ
được xem là "công khai". Tức là thuộc tính "android:exported" có thể không có hoặc
có thể 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", hoạt động 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ẫu bộ lọc Ý định với ứng dụng hệ thống Android cốt lõi.
Nói cách khác, hoạt động 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ó, hoạt động triển khai thiết bị PHẢI hỗ trợ tất cả cá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, các hoạt động triển khai thiết bị PHẢI cho phép mỗi mẫu Ý định
được tham chiếu trong Mục 3.2.3.2 được các ứng dụng bên thứ ba ghi đè. Quy trình triển khai nguồn mở Android ngược dòng cho phép việc này theo mặc định; trình 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ới 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
xử lý cùng một mẫu Ý định.
Tuy nhiên, hoạt động 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://". Các hoạt động triển khai
trên 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
Quá trình triển khai thiết bị KHÔNG ĐƯỢC bao gồm bất kỳ thành phần Android nào tuân thủ bất kỳ mẫu Ý định hoặc Ý định truyền tin
mới nào bằng cách sử dụng chuỗi ACTION, CATEGORY hoặc chuỗi khoá
khác trong không gian tên android.* hoặc com.android.*. Người triển khai thiết bị KHÔNG ĐƯỢC
thêm bất kỳ thành phần Android nào tuân thủ mẫu Ý định mới hoặc Ý định truyền tin
bằng cách sử dụng một 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. Các hoạt động triển khai trên thiết bị CÓ THỂ
bao gồm các mẫu Ý định sử dụng không gian tên rõ ràng và rõ ràng liên kết với tổ chức
riêng của chúng.
Nghiêm cấm tương tự như quy định dành cho các lớp ngôn ngữ Java trong Mục
3.6.
3.2.3.4. Truyền ý định
Các ứng dụng bên thứ ba sẽ dựa vào nền tảng để truyền một số Ý định cụ thể để thông báo cho các ứng dụng đó

về những thay đổi trong môi trường phần cứng hoặc phần mềm. Các thiết bị tương thích với Android
PHẢI truyền các Ý định truyền thông công khai để phản hồi các sự kiện
hệ thống phù hợp. Ý định truyền tin được mô tả trong tài liệu SDK.
3.3. Khả năng tương thích 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 ứng dụng
.apk dưới dạng tệp ELF .so được biên dịch cho kiến 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 một hoạt động triển khai thiết bị tương thích với một hoặc nhiều
đã xác định ABI, thì hoạt động triển khai nÀY PHẢI triển khai khả năng tương thích với Android NDK, như dưới đây.
Nếu quy trình triển khai thiết bị bao gồm hỗ trợ cho một ABI Android, thì:
PHẢI bao gồm hỗ trợ cho 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 của Java (JNI) chuẩn.
PHẢI tương thích với nguồn (tức là tương thích với tiêu đề) và tương thích với tệp nhị phân (đối với
ABI) với mỗi thư viện bắt buộc trong danh sách dưới đây
PHẢI báo cáo chính xác Giao diện nhị phân của ứng dụng (ABI) gốc do 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 NDK
Android, trong tệp docs/CPU-ARCH-ABIS.txt
NÊN được xây dựng bằng mã nguồn và tệp tiêu đề có trong
dự án nguồn mở Android thượng nguồn
Các API mã gốc sau đây PHẢI có trong các ứng dụng bao gồm mã gốc:
libc (thư viện C)
libm (thư viện toán)
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)
libEGL.so (quản lý bề mặt 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 Android gốc)
Hỗ trợ OpenGL, như mô tả dưới đây
Lưu ý rằng các bản phát hành trong tương lai của NDK Android có thể hỗ trợ các ABI
khác. Nếu cách triển khai thiết bị không tương thích với một ABI đã xác định trước hiện có, thì
KHÔNG ĐƯỢC báo cáo hỗ trợ cho bất kỳ ABI nào .
Khả năng tương thích của mã gốc là một thách thức. Vì lý do này, các nhà triển khai thiết bị
RẤT nên sử dụng các biện pháp triển khai
trên trước của các thư viện được liệt kê ở trên để giúp đả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
Quy trình triển khai nguồn mở Android sử dụng công cụ kết xuất WebKit để
triển khai android.webkit.WebView. Vì không thực hiện được việc phát triển một
bộ kiểm thử comprehensive cho một hệ thống hiển thị web, nhà triển khai thiết bị PHẢI sử dụng
bản giới hạn trước cụ thể của WebKit trong quá trình triển khai WebView. Cụ thể:
Các hoạt động triển khai android.webkit.WebView của hoạt động triển khai thiết bị PHẢI
dựa trên bản ghép WebKit 534.30 từ cây Nguồn mở Android thượng nguồn
cho Android 4.1. Bản bản giới hạn này bao gồm một bộ sửa chữa
cụ thể về chức năng và bảo mật cho WebView. Người triển khai thiết bị CÓ THỂ thêm các tuỳ chỉnh vào quá trình triển khai
WebKit; tuy nhiên, bất kỳ tuỳ chỉnh nào 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 ở định dạng này:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của

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) NÊN tuân theo các quy ước ISO cho
mã quốc gia và ngôn ngữ, và NÊN 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
Quá trình 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 NÊN hỗ trợ nhiều HTML5
[Tài nguyên, 11] càng tốt. Tối t thiểu, các hoạt động triển khai thiết bị PHẢI hỗ trợ từng
API này liên kết với HTML5 trong WebView:
bộ nhớ đệm ứng dụng/hoạt động ngoại tuyến [Tài nguyên, 12]
thẻ <video> [Tài nguyên, 13]
thông tin vị trí [Resources, 14]
Ngoài ra, các hoạt động triển khai thiết bị PHẢI hỗ trợ API lưu trữ web 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 các tổ chức chuẩn phát triển web đang chuyển sang ưu tiên
IndexedDB thay vì webstorage, IndexedDB dự kiến sẽ trở thành một thành phần
bắt buộc trong một phiên bản Android sau này.
API HTML5, giống như tất cả API JavaScript, PHẢI bị tắt theo mặc định trong WebView,
trừ trường hợp nhà phát triển bật chúng 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 nói chung. Trình duyệt độc lập CÓ THỂ dựa trên một công nghệ trình duyệt
khác với WebKit. Tuy nhiên, ngay cả khi ứng dụng Trình duyệt thay thế được sử dụng, thành phần
android.webkit.WebView 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 phương thức 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 nhất có thể
HTML5 [Tài nguyên, 11]. Tối thiểu, các hoạt động triển khai thiết bị PHẢI hỗ trợ
từng API này liên kết với HTML5:
bộ nhớ đệm ứng dụng/hoạt động ngoại tuyến [Tài nguyên, 12]
thẻ <video> [Tài nguyên, 13]
vị trí địa lý [Tài nguyên, 14]
Ngoài ra, các hoạt động triển khai thiết bị PHẢI hỗ trợ API bộ lưu trữ trên web 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 thay vì webstorage, IndexedDB dự kiến sẽ trở thành một thành phần
bắt buộc trong một phiên bản Android trong tương lai.
3.5. Khả năng tương thích 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ố phạm vi cụ thể về tính 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 cụ thể
của thành phần hệ thống (chẳng hạn như Dịch vụ, Hoạt động, ContentProvider, v.v.)
Thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của một quyền chuẩn
Danh sách trên không đầy đủ. Bộ kiểm tra tính tương thích (CTS) kiểm tra
các phần quan trọng của nền tảng để biết khả năng tương thích về hành vi, nhưng không phải tất cả . Người 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ở
của Android. Vì lý do này, những 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 đặt tên 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
này:
java.*
javax.*
sun.*
android.*
com.android.*
Các thay đổi bị cấm bao gồm:
Các hoạt động triển khai thiết bị KHÔNG ĐƯỢC thay đổi các API được hiển thị 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Ể thay đổi cách triển khai cơ sở của các API, nhưng
những thay đổi như vậy KHÔNG ĐƯỢC ảnh hưởng đến hành vi đã nêu và chữ ký
ngôn ngữ Java của bất kỳ API được hiển thị công khai nào.
Người triển khai thiết bị KHÔNG ĐƯỢC thêm bất kỳ thành phần được hiển thị công khai nào (chẳng hạn như
các lớp hoặc giao diện, hoặc trường hoặc phương thức cho các lớp hoặc giao diện hiện có) vào
các API ở trên.
"Thành phần hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng điểm đánh dấu
"@hide" dùng trong mã nguồn Android ngược dòng. Nói cách khác, nhà triển khai
thiết bị KHÔNG ĐƯỢC hiển thị các API mới hoặc thay đổi các API hiện có trong không gian tên
đã lưu ý ở trên. Người triển khai thiết bị CÓ THỂ thay đổi chỉ dành cho nội bộ, nhưng những thay đổi
đó KHÔNG ĐƯỢC quảng cáo hoặc cho nhà phát triển biết.
Nhà triển khai thiết bị CÓ THỂ thêm các API tuỳ chỉnh, nhưng bất kỳ API nào như vậy KHÔNG ĐƯỢC ở trong không gian tên
do một tổ chức khác sở hữu hoặc tham chiếu. Ví dụ: những người triển khai
thiết bị KHÔNG ĐƯỢC thêm API vào com.google.* hoặc vùng tên tương tự; chỉ
Google mới có quyền làm vậy. Tương tự, Google KHÔNG ĐƯỢC thêm API vào các vùng tên
của các công ty khác. Ngoài ra, nếu một hoạt động triển khai thiết bị bao gồm các API tuỳ chỉnh bên ngoài
không gian tên Android chuẩn, thì các API đó PHẢI được đóng gói trong một thư viện dùng chung
của Android để chỉ những ứng dụng sử dụng rõ ràng các API đó (thông qua cơ chế <uses-library>
) mới bị ảnh hưởng về mức tiêu thụ bộ nhớ của các API như vậy.
Nếu người triển khai thiết bị đề xuất cải thiện một trong các không gian tên gói ở trên
(chẳng hạn như bằng cách thêm chức năng mới hữu ích vào một API hiện có, hoặc thêm một API mới), thì người triển khai
NÊN truy cập source.android.com và bắt đầu quy trình đóng góp các thay đổi và mã
, theo thông tin trên trang web đó.
Xin lưu ý rằng các quy định hạn chế ở trên tương ứng với các quy ước đặt tên API tiêu chuẩn trong
ngôn ngữ lập trình Java; mục này chỉ nhằm củng cố các quy ước
đó và ràng buộc các quy ước đó thông qua việc đưa vào định nghĩa về khả năng tương thích này.
3.7. Khả năng tương thích với máy ảo
Các hoạt động triển khai thiết bị PHẢI hỗ trợ quy cách mã byte có thể thực thi Dalvik (DEX)
và ngữ nghĩa của Máy ảo Dalvik [Tài nguyên, 17].
Các hoạt động 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 quy định của bảng sau. (Xem
Mục 7.1.1 để xem định nghĩa về kích thước màn hình và mật độ màn hình.)
Lưu ý rằng các giá trị bộ nhớ được chỉ định bên dưới được coi là giá trị tối thiểu và 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 độ màn hì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
lớn
mdpi
32MB
lớn
tvdpi / hdpi
64MB
lớn
xhdpi
128MB
3.8. Khả năng tương thích với giao diện người dùng
3.8.1. Tiện ích
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 "AppWidget" cho người dùng cuối [Tàinguyên, 18]. Bản phát hành tham chiếu nguồn mở
Android bao gồm một ứng dụng Trình chạy có các tính năng giao diện người dùng
cho phép người dùng thêm, xem và xoá AppWidgets khỏi màn hình chính
.
Hoạt động triển khai thiết bị CÓ THỂ thay thế một phương án thay thế cho Trình chạy tham chiếu (tức là màn hình chính
). Trình chạy thay thế PHẢI có tính năng hỗ trợ tích hợp cho AppWidgets,
và hiển thị các tính năng trên giao diện người dùng để thêm, định cấu hình, xem và xoá
AppWidgets trực tiếp trong Trình chạy. Trình chạy thay thế CÓ THỂ bỏ qua các thành phần giao diện người dùng
này; tuy nhiên, nếu bỏ qua, quy trình triển khai thiết bị PHẢI
cung cấp một ứng dụng riêng biệt có thể truy cập được từ Trình chạy cho phép người dùng thêm,
định cấu hình, xem và xoá AppWidgets.
Quy trình 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 Hướng dẫn 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.
3.8.2. 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 các ứ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, cảm biến rung và ánh sáng. Quá trình triển khai thiết bị PHẢI
hỗ trợ các thông báo sử dụng các tính năng phần cứng, như mô tả trong tài liệu
SDK, và trong phạm vi có thể với phần cứng triển khai thiết bị.
Ví dụ: nếu một quá trình triển khai thiết bị bao gồm một máy rung, thì quá trình triển khai đó PHẢI
triển khai các API rung một cách chính xác. 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
trình bày chi tiết hơn trong Phần 7.
Ngoài ra, quá trình triển khai PHẢI hiển thị chính xác tất cả tài nguyên (biểu tượng, tệp âm thanh
, v.v.) được cung cấp trong API [Tài nguyên, 20] hoặc trong hướng dẫn về kiểu biểu tượng
của Thanh trạng thái/Hệ thống [Tài nguyên, 21]. Trì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 hoạt động triển khai
nguồn mở Android tham chiếu; tuy nhiên, những hệ thống thông báo thay thế như vậy PHẢI hỗ trợ các tài nguyên thông báo
hiện có, như trên.
Android 4.1 hỗ trợ các thông báo phong phú, chẳng hạn như Khung hiển thị tương tác cho
thông báo đang diễn ra. Các hoạt động triển khai trên thiết bị PHẢI hiển thị và thực thi các thông báo
đa dạng thức một cách chính xác, như đã ghi trong các API Android.
3.8.3. 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 của họ và hiển thị dữ liệu của ứng dụng vào tìm kiếm hệ thống toàn cầu.
Nhìn chung, fchức năng này bao gồm một giao diện người dùng duy nhất, trên toàn hệ thống
cho phép người dùng nhập cụm từ tìm kiếm, hiển thị các đề xuất khi người dùng nhập và hiển thị kết quả
. Các 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.
Hoạt động triển khai thiết bị PHẢI bao gồm một giao diện người dùng
tìm kiếm riêng, chung, trên toàn hệ thống có khả năng đề xuất theo thời gian thực để phản hồi vào dữ liệu đầu vào của người dùng. Các hoạt động triển khai
trên thiết bị PHẢI triển khai các API cho phép nhà phát triển sử dụng lại giao diện
người dùng này để cung cấp tính năng tìm kiếm trong các ứng dụng của riêng họ. Các hoạt động triển khai trên thiết bị
PHẢI triển khai các API cho phép các ứng dụng bên thứ ba thêm đề xuất vào
hộp tìm kiếm khi hộp tìm kiếm chạy ở chế độ tìm kiếm chung. Nếu không có ứng dụng của bên thứ ba đượ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.4. Thông báo ngắn
Các ứng dụng có thể sử dụng API "Thông báo ngắn" (được xác định trong [Tài nguyên, 23]) để hiển thị các chuỗi không phải
cửa sổ đơn ngắn 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. Các hoạt động triển khai
trên 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 số cách hiển thị
rõ ràng.
3.8.5. 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 3.0 đã giới thiệu một giao diện
"Holo" hoặc "holographic" mới dưới dạng một bộ các kiểu đã xác định cho các nhà phát triển ứng dụng sử dụng nếu họ muốn kết hợp
giao diện Holo về vẻ ngoại hình như đã xác định theo SDK Android [Tài nguyên, 24]. Các hoạt động triển khai
của thiết bị KHÔNG ĐƯỢC thay đổi bất kỳ thuộc tính giao diện Holo nào hiển thị cho các ứng dụng

[Tài nguyên, 25].
Android 4.0 đã ra mắt giao diện mới "Mặc định của thiết bị" dưới dạng một bộ các kiểu đã xác định cho
các nhà phát triển ứng dụng sử dụng nếu họ muốn khớp với giao diện của giao diện
thiết bị do người triển khai thiết bị xác định. Các hoạt động 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.6. Hình nền động
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ó các chức năng đầu vào
giới hạn 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ý và không
ảnh hưởng bất lợi đến các ứng dụng khác. Nếu các hạn chế trong phần cứng khiến giao diện đáy
và/hoặc ứng dụng bị sập, 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 quá thấp không chấp nhận được, thì phần cứng được xem là không có khả năng chạy
giao diện đáy động. Ví dụ: một số nội dung trực tiếp có thể sử dụng một ngữ ngữ Open GL 1.0 hoặc 2.0
để hiển thị nội dung. Hình nền động sẽ không chạy một cách đáng tin cậy trên phần cứng
không hỗ trợ nhiều ngữ cảnh OpenGL vì hình nền động sử dụng ngữ cảnh
OpenGL có thể xung đụng 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 nền trực tiếp một cách đáng tin cậy như mô tả ở trên KHÔNG ĐƯỢC triển khai nền trực tiếp.
3.8.7. Màn hình hiển thị ứng dụng gần đây
Mã nguồn Android 4.1 trên lưu luồ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 tắt ứng dụng 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, một phiên bản Android trong tương lai dự kiến sẽ
sử dụng chức năng này một cách rộng rãi hơn. Các phương thức triển khai thiết bị nên
khuyến khích sử dụng giao diện người dùng Android 4.1 trên nguồn (hoặc giao diện tương tự dựa trên
thẻ thu nhỏ) 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 tương lai của Android.
3.8.8. Cài đặt quản lý dữ liệu đầu vào
Android 4.1 có hỗ trợ cho các Công cụ quản lý dữ liệu đầu vào. API Android 4.1
cho phép IME ứng dụng tuỳ chỉnh chỉ định các chế độ cài đặt mà người dùng có thể điều chỉnh. Các hoạt động triển khai thiết bị
PHẢI bao gồm cách để người dùng truy cập vào các chế độ cài đặt IME mọi lúc khi một IME
cung cấp các chế độ cài đặt người dùng như vậy được hiển thị.
3.8.9. Điều khiển từ xa trên màn hình khoá
Android 4.0 đã ra mắt tính năng hỗ trợ cho 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 chế độ điều khiển phát được hiển thị trong chế độ xem từ xa như màn hình khoá
của thiết bị [Tài nguyên, 69]. Hoạt động triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ
nhúng các nút điều khiển từ xa vào màn hình khoá của thiết bị.
3.9 Quản lý thiết bị
Android 4.1 bao gồm các tính năng cho phép các ứng dụng nhận biết mã truy cập thực hiện các chức năng quản lý
thiết bị ở cấp hệ thống, chẳng hạn như thực thi các chính sách mã truy cập hoặc
thực hiện xoá từ xa, thông qua API Quản lý thiết bị Android [Tài nguyên,
27]. Các hoạt động triển khai thiết bị PHẢI cung cấp hoạt động triển khai của lớp DevicePolicyManager
[Tài nguyên, 28] và PHẢI hỗ trợ toàn bộ 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].
Lưu ý: mặc dù một số yêu cầu được nêu ở trên được nêu là "NÊN" đối với
Android 4.1, 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
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.1 nhưng sẽ
bắt buộc trong một phiên bản trong tương lai. Các thiết bị hiện có và mới chạy Android 4.1 rất
nên đáp ứng các yêu cầu này trong Android 4.1, nếu khô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.
3.10 Hỗ trợ tiếp cận
Android 4.1 cung cấp một lớp hỗ trợ tiếp cận giúp người dùng khuyết tật dễ dàng hơn trong việc di chuyển
thiết bị của họ. Ngoài ra, Android 4.1 cung cấp các API nền tảng cho phép

triển khai dịch vụ hỗ trợ tiếp cận để nhận lệnh gọi lại cho các sự kiện của người dùng và hệ thống
và 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 [Resources, 29]. Hoạt độngtriển khai thiết bị
PHẢI cung cấp hoạt động triển khai khung hỗ trợ tiếp cận của Android tương đồng
với hoạt động triển khai Android mặc định. Cụ thể, các hoạt động triển khai thiết bị PHẢI
đáp ứng các yêu cầu sau.
Các phương thức triển khai thiết bị PHẢI hỗ trợ các phương thứ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 phương thức triển khai thiết bị PHẢI tạo AccessibilityEvents và cung cấp
các sự kiện này cho tất cả các phương thức triển khai AccessibilityService đã đăng ký theo
cách phù hợp với phương thức triển khai Android mặc định.
Các phương thức triển khai thiết bị PHẢI cung cấp cơ chế mà người dùng có thể truy cập để bật
và tắt các dịch vụ hỗ trợ tiếp cận, và 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.1 bao gồm các API cho phép các ứ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 các nhà cung cấp dịch vụ cung cấp các biện pháp triển khai dịch vụ TTS
[Tài nguyên, 32]. Các phương thứ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:
Các phương thứ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
.
Các hoạt động 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.
Các hoạt động triển khai thiết bị PHẢI cung cấp giao diện mà người dùng có thể truy cập để cho phép
người dùng chọn công cụ TTS để sử dụng ở cấp hệ thống.
4. Khả năng tương thích đóng gói ứng dụng
Các hoạt động 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 có trong SDK Android chính thức [Tài nguyên, 33].
Hoạt động triển khai thiết bị KHÔNG ĐƯỢC mở rộngtệp .apk [Tàing, 34], Tệp kê khai
Android [Tài nguyên, 35], mã byte Dalvik [Tài nguyên, 17] hoặc mã byte renderscript
theo cách ngăn các tệp đó cài đặtvà chạy chính xác
trên các thiết bịtương thích khác. Các trình triển khai thiết bị NÊN sử dụng phương thức triển khai tham chiếu
ngược dòng 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
Hoạt động triển khai thiết bị PHẢI bao gồm ít nhất một hình thức đầ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 về
SDK Android [Tài nguyên, 58] trừ trường hợp được cho phép rõ ràng trong tài liệu
này. Cụ thể, các hoạt động 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ã, các loại tệp và định dạng vùng chứa được xác định trong các bảng dưới đây. Tất cả
các bộ mã và giải mã này đều được cung cấp dưới dạng triển khai phần mềm trong phương thức triển khai
Android ưu tiên từ Dự án nguồn mở Android.
Xin lưu ý rằng cả Google và Open Handset Alliance đều không có bất kỳ
đại diện nào cho rằng các bộ mã này không bị giới hạn 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 mềm hoặc phần cứng được
tư vấn rằng việc triển khai mã này, bao gồm trong phần mềm nguồn mở
hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ các chủ sở hữu bằng sáng chế liên quan.
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 các 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 đó, các hoạt động triển khai
của thiết bị PHẢI hỗ trợ băng thông cao nhất có thể thực hiện trên phần cứng, tối đa

giới hạn do quy chế xác định.

(Các) Loại tệp /
Định dạng /
Loại
Bộ mã hoá
Bộ giải mã
Thông tin chi tiết
Vùng đựng
Bộ mã hoá và giải mã
Định dạng
Hỗ trợ
BẮT BUỘC
mono/stereo/5.0/5.1*
MPEG-4
BẮT BUỘC cho các hoạt động triển khai thiết bị
nội dung có
Hồ sơ AAC
bao gồm phần cứng micrô
BẮT BUỘC
lấy mẫu tiêu chuẩn
(AAC LC)
và xác định
3GPP
tốc độ từ 8 đến 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Hỗ trợ
(.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
nội dung HE AAC
với
ADTS thô

BẮT BUỘC
Hồ sơ
tần số lấy mẫu chuẩn
AAC (.aac,
(AAC+)
từ 16 đến 48
giải mã ở
kHz.
Android
3.1 trở lên,
Hỗ trợ cho
MPEG-4
BẮT BUỘC cho thiết bị
mã hoá ở
mono/stereo/5.0/5.1*
triển khai HE AAC v2
bao gồm
nội dung
Android với
Profile
phần cứng micrô và

4.0 trở lên, ADIF
lấy mẫu tiêu chuẩn
(tăng cường
xác định
không
tốc độ từ 16 đến 48
AAC+)
android.hardware.microphone
được hỗ trợ)
kHz.
MPEG-TS
MPEG-4
(.ts, not
Âm thanh
BẮT BUỘC cho thiết bị
Hỗ trợ cho
có thể tua lại,
Loại đối tượng
các phương thức triển khai bao gồm
nội dung đơn âm/âm thanh nổi
Android
ER AAC
phần cứng micrô và
BẮT BUỘC
với tiêu chuẩn
3.0 trở lên
ELD
xác định
tốc độ lấy mẫu từ
(Nâng cao
android.hardware.microphone
16 đến 48 kHz.
Độ trễ thấp
AAC)
BẮT BUỘC
Bắt buộc để triển khai thiết bị
4,75 đến 12,2 kbps
AMR-NB
bao gồm phần cứng micrô
BẮT BUỘC
3GPP (.3gp)
được lấy mẫu ở 8 kHz
và xác định
android.hardware.microphone.
BẮT BUỘC
Bắt buộc đối với các hoạt động triển khai thiết bị
9 tốc độ từ 6,60
AMR-WB
bao gồm phần cứng micrô
BẮT BUỘC
kbit/giây đến 23,85 kbit/giây
3GPP (.3gp)
và xác định
đã lấy mẫu ở 16 kHz
android.hardware.microphone.
Đơn âm/Âm thanh nổi (không
đa kênh).
Âm thanh
Tốc độ lấy mẫu lên đến
48 kHz (nhưng
nên dùng
tốc độ lấy mẫu

kHz trên
các thiết bị có
YÊU CẦU
FLAC

đầu ra, vì chỉ có tốc độ lấy mẫu
FLAC (.flac) 48

(Android 3.1 trở lên)
xuống 44,1 kHz
không
có bộ lọc
băng thông thấp). Nên dùng
16 bit; không
áp dụng dither cho 24-
bit.
Âm thanh đơn kênh/Âm thanh nổi 8-
320Kbps biến
MP3

BẮT BUỘC
MP3 (.mp3)
(CBR) hoặc biến
tốc độ
bit (VBR)
Loại 0 và
MIDI Loại 0 và 1.
1 (.mid,
DLS Phiên bản 1 và
.xmf, .mxmf)
2. XMF và Điện thoại
RTTTL/RTX
MIDI

BẮT BUỘC
XMF. Hỗ trợ
(.rtttl, .rtx)
các định dạng nhạc chuông
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
và iMelody
(.imy)

Ogg (.ogg)
Vorbis

BẮT BUỘC

Matroska
(.mkv)
8-bit và 16-bit
linear PCM** (rates
up to limit of
hardware).Devices
MUST support
PCM/WAVE
BẮT BUỘC
BẮT BUỘC
WAVE (.wav)
sampling rates for
raw PCM recording
at 8000,16000 and
44100 Hz
frequencies
JPEG
BẮT BUỘC
BẮT BUỘC
Base+progressive
JPEG (.jpg)
GIF

BẮT BUỘC

GIF (.gif)
Image
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)
BẮT BUỘC
Bắt buộc đối với các hoạt động triển khai thiết bị
3GPP
bao gồm phần cứng máy chụp hình và
(.3gp)
H.263
BẮT BUỘC

xác định android.hardware.camera
MPEG-4
hoặc
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
BẮT BUỘC
MPEG-4
(.mp4)
BẮT BUỘC cho các hoạt động triển khai thiết bị
MPEG-TS
bao gồm phần cứng máy ảnh và
Hồ sơ cơ sở
Video
H.264 AVC
BẮT BUỘC
(.ts, AAC
xác định android.hardware.camera
(BP)
chỉ âm thanh,
hoặc
không
android.hardware.camera.front.
có thể tìm kiếm,
Android
3.0+)
MPEG-4

BẮT BUỘC

3GPP (.3gp)
SP
WebM (.webm)
BẮT BUỘC
và Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Lưu ý: Chỉ yêu cầu kết hợp nội dung 5.0/5.1; bạn không bắt buộc phải ghi hoặc hiển thị hơn 2 kênh
. **Lưu ý: Bạn bắt buộc phải ghi âm PCM tuyến tính 16 bit. Không bắt buộc phải ghi âm PCM
tuyến tính 8 bit.
5.2 Mã hoá video
Các hoạt động triển khai thiết bị Android bao gồm máy ảnh sau và khai báo
android.hardware.camera NÊN hỗ trợ các hồ sơ mã hoá video sau.
HD (Khi được hỗ trợ bởi

SD (Chất lượng thấp) SD (Chất lượng cao)
phần cứng)
H.264 Baseline
H.264 Baseline
Bộ mã hoá và giải mã video
H.264 Baseline Profile
Profile
Profile
Video
176 x 144 px
480 x 360 px
1280 x 720 px
độ phân giải
Khung video 12 khung/giây
30 khung/giây
30 khung/giây
tốc độ
500 Kbps hoặc
Bitrate video 56 Kbps
2 Mbps trở lên
trở lên
Bộ mã hoá và giải mã âm thanh AAC-LC
AAC-LC
AAC-LC

Âm thanh
1 (đơn âm)
2 (âm thanh kèm)
2 (âm thanh kèm)
kênh
Bitrate âm thanh 24 Kbps
128 Kbps
192 Kbps
5.3. Ghi âm âm thanh
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 âm thanh với từng
hành vi này:
Thiết bị NÊN hiển thị các đặc điểm độ dải tần so với độ dải tần phẳng
; cụ thể là, ±3 dB, từ 100 Hz đến 4000 Hz
Độ nhạy đầu vào âm thanh NÊN được đặt như vậy để nguồn cấp điện cho âm thanh 90 dB
(SPL) ở 1000 Hz cho ra RMS là 2500 đối với các mẫu 16 bit.
Cấp độ dải tần PCM NÊN theo dõi tuyến tính các thay đổi cấp độ SPL đầu vào trên ít nhất
dải 30 dB từ -18 dB đến +12 dB so với 90 dB SPL tại micrô.
Tổng số sự biến đổi hình ảnh hòa âm NÊN dưới 1% đối với 1Khz ở cấp độ đầu vào 90 dB SPL
.
Ngoài các thông số kỹ thuật ghi âm ở trên, khi một ứng dụng bắt đầu
ghi lưu 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 kiểm soát độ khuếch đại tự động (nếu có).
Lưu ý: mặc dù một số yêu cầu được nêu ở trên được nêu là "NÊN" đối với
Android 4.1, 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
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.1 nhưng sẽ
bắt buộc trong một phiên bản trong tương lai. Các thiết bị hiện có và mới chạy Android 4.1 rất
nên đáp ứng các yêu cầu này trong Android 4.1, nếu không sẽ
không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.
5.4. Độ trễ âm thanh
Độ trễ âm thanh được xác định rộng rãi là khoảng thời gian giữa thời điểm một ứng dụng yêu cầu
một thao tác phát hoặc ghi âm thanh và thời điểm triển khai thiết bị thực tế
bắt đầu thao tác. Nhiều lớp ứng dụng dựa vào độ trễ ngắn để đạt được
các hiệu ứng thời gian thực chẳng hạn như hiệu ứng âm thanh hoặc giao tiếp qua VOIP. Các phương thứ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 tất cả các yêu cầu về độ trễ âm thanh được nêu trong phần này. Xem Phần 7
để biết chi tiết về các điều kiện mà thiết bị
có thể bỏ qua phần cứng mặt tính âm thanh.
Đối với mục đích của phần này:
"độ trễ đầu ra lạnh" được xác định là khoảng thời gian giữa khi một ứng dụng
yêu cầu phát âm thanh và khi âm thanh bắt đầu phát, khi hệ thống âm thanh
đang rảnh và đã tắt trước yêu cầu
"độ trễ đầu ra nóng" được xác định là khoảng thời gian giữa khi một ứng dụng
yêu cầu phát âm thanh và khi âm thanh bắt đầu phát, khi hệ thống âm thanh
đã được sử dụng gần đây nhưng đang rảnh (tức là yên tĩnh)
"độ trễ đầu ra liên tục" được xác định là khoảng thời gian giữa khi một
ứng dụng phát một mẫu để phát và khi loa phát
âm thanh tương ứng, trong khi thiết bị đang phát âm thanh
"độ trễ đầu vào lạnh" được xác định là khoảng thời gian giữa khi một ứng dụng
yêu cầu ghi âm và khi mẫu đầu tiên được cung cấp cho
ứng dụng thông qua lệnh gọi lại, khi hệ thống âm thanh và micrô đang rảnh và đã tắt trước yêu cầu
"độ trễ đầu vào liên tục" được xác định là khi âm thanh môi trường xung quanh xảy ra và
khi mẫu tương ứng với âm thanh đó được cung cấp cho một ứng dụng
ghi âm thông qua lệnh gọi lại, trong khi thiết bị đang ở chế độ ghi
Sử dụng các định nghĩa trên, hoạt động triển khai thiết bị NÊN hiển thị từng thuộc tính
này:
độ trễ đầu ra lạnh là 100 triệu i giây trở xuống
độ trễ đầu ra nóng là 10 triệu i giây trở xuống
độ trễ đầu ra liên tục là 45 triệu i giây trở xuống
độ trễ đầu vào lạnh là 100 triệu i giây trở xuống
độ trễ đầu vào liên tục là 50 triệu i giây trở xuống
Lưu ý:

Các thiết bị hiện tại và mới chạy Android 4.1 rất nên
đáp ứng các yêu cầu này trong Android 4.1, nếu không các thiết bị này sẽ không thể
đạt được khả năng tương thích với Android khi cập nhật lên phiên bản trong tương lai.
Nếu cách triển khai thiết bị đáp ứng các yêu cầu của phần này, thì thiết bị CÓ THỂ báo cáo
hỗ trợ cho â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àiliệu, 37]
Ngược lại, nếu cách 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.
5.5. Giao thức mạng
Thiết bị PHẢI hỗ trợ các giao thức mạng nội dung đ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 đa phương tiện sau:
RTSP (RTP, SDP)
HTTP(S) truyền trực tuyến tiến trình
Giao thức dự thảo của giao thức truyền 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ông cụ dành cho nhà phát triển
Hoạt động 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ể, các thiết bị tương thích với Android PHẢI tương thích với:
Cầu gỡ lỗi Android (còn gọi là adb) [Tài nguyên, 33]
Các hoạt động triển khai thiết bị PHẢI hỗ trợ tất cả hàm adb dưới dạng tài liệu trong
SDK Android. Trình nền adb phía thiết bị PHẢI ở trạng thái không hoạt động theo mặc định và
PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi
Android.
Dịch vụ giám sát gỡ lỗi Dalvik (còn gọi là dms) [Tài nguyên, 33]
Các hoạt động triển khai thiết bị PHẢI hỗ trợ tất cả các tính năng dms như được ghi nhận trong
SDK Android.Vì ddms sử dụng adb, nên hỗ trợ cho ddms NÊN ở 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]
Các hoạt động triển khai thiết bị PHẢI bao gồm khung Monkey và cung cấp khung đó
cho các ứng dụng để sử dụng.
Hầu hết các hệ thống dựa trên Linux và các hệ thống Apple Macintosh đều nhận dạng các thiết bị Android
bằng các công cụ SDK Android chuẩn, mà không cần hỗ trợ bổ sung; tuy nhiên các hệ thống Windows
của Microsoft thường yêu cầu một 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 diện một hoạt động triển khai thiết bị dưới dạng
được cung cấp trong SDK Android chuẩn, thì nhà triển khai thiết bị PHẢI cung cấp trình điều khiển Windows
để cho phép nhà phát triển kết nối với thiết bị bằng giao thức adb. Bạn PHẢI cung cấp các trình điều khiển
cho Windows XP, Windows Vista và Windows 7, ở cả phiên bản
32 bit và 64 bit.
7. Khả năng tương thích với phần cứng
Nếu một thiết bị bao gồm một thành phần phần cứng cụ thể có một 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 tuyên bố là không bắt buộc và quy trình triển khai thiết bị không
sở hữu thành phần đó:
các định nghĩa lớp hoàn toàn (như được ghi nhận trong SDK) cho
API của thành phần PHẢI vẫn có mặt
hành vi của API PHẢI được triển khai dưới dạng không có hoạt động theo một cách
hợp lý
Một ví dụ tiêu biểu về trường hợp áp dụng các yêu cầu này là API viễn thông:
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 có hoạt động theo một cách hợp lý.

Các hoạt động 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. [Resources, 37]
7.1. Hiển thị và Đồ hoạ
Android 4.1 bao gồm các cơ sở thao tác tự động điều chỉnh các thành phần ứng dụng và bố lục
giao diện người dùng cho phù hợp với thiết bị, để đảm bảo các ứng dụng của bên thứ ba chạy tốt trên
nhiều cấu hình phần cứng [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ư 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 của màn hình.
"dpi" (tức là "điểm trên inch") là số pixel được bao phủ bởi một khoảng cách
theo chiều ngang hoặc chiều dọc là 1". Khi các giá trị dpi được liệt kê, cả dpi ngang và
dpi dọc phải nằm trong phạm vi.
"Tỷ lệ khung hình" là tỷ lệ giữa phương diện dài hơn của màn hình với phương diện
dài 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 theo công thức: pixel = dps * (mật độ / 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 ứng dụng
truy vấn kích thước màn hình thiết bị (còn gọi là "bố cục màn hình") thông qua
android.content.res.Configuration.screenLayout với
SCREENLAYOUT_SIZE_MASK. Các hoạt động 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 cấp trên xác định. Cụ thể, quá trình triển khai thiết bị phải báo cáo
kích thước màn hình chính xác theo các kích thước màn hình
pixel (dp)không phụ thuộc vào mật độ logic sau đây.
Thiết bị PHẢI có kích thước màn hình tối t thiểu là 426 dp x 320 dp ('nhỏ ')
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 t thiểu là 480
dp x 320 dp
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 t 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 t 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 t thiểu là 2,5 inch theo chiều chéo vật lý
.
Thiết bị KHÔNG ĐƯỢC thay đổi kích thước màn hình đã báo cáo bất cứ lúc nào.
Các ứng dụng không bắt buộc phải 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 hỗ trợ đã nêu của ứng dụng cho màn hình nhỏ, bình thường, lớn và rất lớn
, như mô tả trong tài liệu SDK Android.
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 các mật độ logic tiêu chuẩn để giúp
nhà phát triển ứng dụng nhắm mục tiêu các tài nguyên ứng dụng. Các hoạt động 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 các 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'
Hoạt động triển khai thiết bị NÊN xác định mật độ khung Android tiêu chuẩn mà
là số y gần như đúng với mật độ vật lý của màn hình, trừ trường hợp mật độ logic
pushing the reported screen size below the minimum supported.

Nếu mật độ khung
Android tiêu chuẩn có giá trị số gần như 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 nhỏ nhất được hỗ trợ (chiều rộng 320 dp),thì hoạt động triển khai thiết bị NÊN báo cáo mật độ khung
Android tiêu chuẩn thấp nhất tiếp theo.

7.1.2. Chỉ số hiển thị
Quy trình triển khai thiết bị PHẢI báo cáo giá trị chính xác cho tất 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 theo các ứng dụng cho hướng màn hình dọc hoặc
ngang. Tức là thiết bị phải tuân theo yêu cầu
của ứng dụng về hướng màn hình cụ thể. Các hoạt động triển khai thiết bị CÓ THỂ chọn hướng dọc hoặc ngang
là 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
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 những hướng màn hình mà thiết bị hỗ trợ (
android.hardware.screen.portrait và/hoặc android.hardware.screen.landscape)
và PHẢI báo cáo ít nhất một hướng được hỗ trợ. Ví dụ: một thiết bị có
màn hình ngang theo hướng cố định, chẳng hạn như TV hoặc máy tính xách tay, 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 thể hiện
và nêu chi tiết trong tài liệu SDK Android. Các hoạt động triển khai thiết bị CŨNG PHẢI
hỗ trợ Android Renderscript, như đã chi tiết trong tài liệu SDK Android
[Tài nguyên, 8].
Các phương thức triển khai thiết bị CŨNG PHẢI xác định chính xác rằng các phương thức đó hỗ trợ
OpenGL ES 1.0 và 2.0. Tức là:
Các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) PHẢI báo cáo
hỗ trợ cho OpenGL ES 1.0 và 2.0
Các API OpenGL C/C++ gốc (tức là những 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 hỗ trợ cho
OpenGL ES 1.0 và 2.0.
Hoạt động triển khai thiết bị CÓ THỂ triển khai bất kỳ tiện ích OpenGL ES mà muốn.
Tuy nhiên, hoạt động triển khai thiết bị PHẢI báo cáo thông qua OpenGL ES được quản lý và
API gốc tất cả các chuỗi tiện ích mà các API đó hỗ trợ, và ngược lại KHÔNG ĐƯỢC báo cáo
chuỗi tiện ích mà các API đó không hỗ trợ.
Xin lưu ý rằng Android 4.1 hỗ trợ các ứng dụng không bắt buộc phải chỉ định rằng chúng
yêu cầu các định dạng nén hoạ tiết OpenGL cụ thể. Các định dạng này là định dạng thông thường của nhà cung cấp
. Android 4.1 không yêu cầu bạn phải triển khai
bất kỳ định dạng nén kết cấu cụ thể nào trên thiết bị. Tuy nhiên, các thiết bị NÊN báo cáo chính xác mọi
định dạng nén kết cấu mà các thiết bị đó hỗ trợ, thông qua phương thức getString() trong
OpenGL API.
Android 4.1 bao gồm một cơ chế cho các ứng dụng để khai báo rằng các ứng dụng muốn
bật tính năng tăng tốc phần cứng cho hình ảnh 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 tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp tệp t

Trong Android 4.1, các hoạt động 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 Thành phần hiển thị Android.
Ngoài ra, quá trình triển khai thiết bị PHẢI thể hiện hành vi nhất quán với tài liệu về SDK
Android về tính năng tăng tốc phần cứng [Tài nguyên, 9].
Android 4.1 bao gồm một đối tượng TextureView cho phép nhà phát triển trực tiếp tích hợp
các kết cấu OpenGL ES được tăng tốc bằng phần cứng dưới dạng các mục tiêu kết xuất trong một hệ phân cấp giao diện người dùng.
Các hoạt động triển khai thiết bị PHẢI hỗ trợ TextureView API và PHẢI hiển thị

hành vi nhất quán với hoạt động triển khai Android trước.
7.1.5. Chế độ tương thích với ứng dụng cũ
Android 4.1 chỉ định một "chế độ tương thích" trong đó khung hoạt động ở chế độ
kích thước màn hình "bình thường" tương đươ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
. Quá trình triển khai thiết bị PHẢI hỗ trợ chế độ tương thích
của ứng dụng cũ do mã nguồn mở Android cấp trên triển khai. Tức là
hoạt động 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
, cũng như KHÔNG ĐƯỢC thay đổi hành vi của chính chế độ tương thích
.
7.1.6. Các 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ó pixel cố định: màn hình là một bảng đơn chỉ hỗ trợ
một chiều rộng và chiều cao pixel duy nhất. Thông thường, màn hình là thực và được tích hợp
với thiết bị. Ví dụ: điện thoại di động, máy tính bảng và các thiết bị khác.
Triển khai màn hình pixel biến đổi: triển khai thiết bị không có
màn hình nhúng và bao gồm cổng đầu ra video chẳng hạn như VGA, HDMI hoặc cổng
không dây dành cho màn hình, hoặc có màn hình nhúng có thể thay đổi kích thước pixel
. Ví dụ: tivi, hộp giải mã tín hiệu số TV, v.v.
Cách triển khai thiết bị có pixel cố định
Cách 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à các 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.
Các phương thứ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 đó được dùng để chạy ứng dụng, 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ố màn hình, như
đã chi tiết trong Mục 7.1.1 và 7.1.2, như màn hình pixel cố định.
Thiết bị PHẢI báo cáo cùng một mật độ logic như màn hình pixel cố định.
Thiết bị PHẢI báo cáo kích thước màn hình giống như hoặc rất gần
với màn hình pixel cố định.
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à triển khai màn hình mdpi lớn cố định pixel.
Nếu thiết bị có cổng đầu ra
video hiển thị ở 720p hoặc 1080p, thì việc triển khai thiết bị PHẢI điều chính đầu ra
để các ứng dụng chỉ được thực thi trong cửa sổ mdpi lớn, bất lệ
màn hình pixel cố định hay cổng đầu ra video có đang sử dụng hay không.
Cách triển khai thiết bị có pixel biến đổi
Cách 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 đổi 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 pixel biến ĐƯỢC thay đổi cấu hình màn hình hoặc chế độ
trong thời gian chạy hoặc thời gian khởi động. Ví dụ: người dùng của một bộ đầu tiên 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, các phương thức triển khai thiết bị có kích thước pixel biến đổi PHẢI báo cáo các nhóm cấu hình
sau đây 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, các phương thức triển khai thiết bị có kích thước pixel biến đổi bị hạn chế ở
720p hoặc 1080p trong Android 4.1 và PHẢI được định cấu hình để báo cáo kích thước màn hình và các nhóm mật độ
như đã lư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 hiển thị đồ hoạ đa dạng trên
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ừ trường hợp được cụ thể nêu trong tài liệu này. Cụ thể:
Thiết bị PHẢI hỗ trợ màn hình có khả năng hiển thị hình ảnh màu 16 bit và
NÊN hỗ trợ màn hình có khả năng hiển thị hình ảnh màu 24 bit.
Thiết bị PHẢI hỗ trợ màn hình có khả năng hiển thị ảnh động.
Công nghệ màn hình được sử dụng PHẢI có tỷ lệ khuôn ả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
là 10%.
7.2. Thiết bị đầu vào
7.2.1. Bàn phím
Triển khai thiết bị:
PHẢI bao gồm hỗ trợ cho Khung quản lý dữ liệu đầu vào (cho phép nhà phát triển bên thứ ba
tạo Công cụ quản lý dữ liệu đầu vào – tức là bàn phím mềm) như
đã trình bày chi tiết tại http://developer.android.com
PHẢI cung cấp ít nhất một biện pháp triển khai bàn phím mềm (bất lệ
có bàn phím cứng hay không)
CÓ THỂ bao gồm các biện pháp triển khai bàn phím mềm khác
CÓ THỂ bao gồm bàn phím phần cứng
KHÔNG ĐƯỢC bao gồm bàn phím phần cứng không khớp với một trong các định dạng
được chỉ định trong android.content.res.Configuration.keyboard [Tài nguyên, 40]
(tức là QWERTY hoặc 12 phím)
7.2.2. Điều hướng không chạm
Triển khai thiết bị:
CÓ THỂ bỏ qua 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 giá trị chính xác 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ý mcho việc
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.
Phần mềm nguồn mở Android ngược dòng bao gồm một cơ chế lựa chọn
phù hợp để sử dụng với các thiết bị thiếu phương thức nhập điều hướng không chạm.
7.2.3. Phím điều hướng
Các hàm Màn hình chính, Trình đơn và Quay lại là quan trọng đối với mô hình điều hướng
của Android. Các hoạt động triển khai thiết bị PHẢI cung cấp các hàm này cho người dùng
mọi lúc khi chạy ứng dụng. Các hàm này CÓ THỂ được triển khai thông qua
các nút vật lý dành riêng (chẳng hạn như các nút chạm cơ hoặc điện dung), hoặc CÓ THỂ
được triển khai bằng các phím phần mềm dành riêng, cử chỉ, bảng chạm, v.v. Android
4.1 hỗ trợ cả hai cách triển khai.
Android 4.1 giới thiệu hỗ trợ cho hành động 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 hành động hỗ trợ mọi lúc khi
chạy ứng dụng. Hàm này CÓ THỂ được triển khaithông qua phím phần cứng hoặc phần mềm
.
Các hoạt động 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 riêng biệt của màn hình
, không có trong ứng dụng và KHÔNG ĐƯỢC che khuất hoặc
can thiệp vào phần màn hình có trong ứng dụng.
Các hoạt động 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.
Các hoạt động triển khai thiết bị PHẢI hiển thị các phím điều hướng khi các ứ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.
Các hoạt động triển khai thiết bị PHẢI hiển thị các phím điều hướng theo chế độ"hình thức thấp" (ví dụ: màn hình mờ) không gâyphiền toái
khi các ứng dụng chỉ định
SYSTEM_UI_FLAG_LOW_PROFILE.
Hoạt động 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.
Hoạt động triển khai thiết bị PHẢI hiển thị một phím Trình đơn cho ứng dụng khi
targetSdkVersion <= 10 và KHÔNG ĐƯỢC hiển thị một phím Trình đơn khi
targetSdkVersion > 10.
Hoạt động 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.
7.2.4. Đầu vào màn hình cảm ứng
Hoạt động triển khai thiết bị PHẢI có một hệ thống đầu vào con trỏm của một loại nào đó (
giống chuột hoặc chạm). Tuy nhiên, nếu cách triển khai thiết bị không hỗ trợ hệ thống đầu vào con trỏ
, thì thiết bị KHÔNG ĐƯỢC báo cáo hằng số tính năng android.hardware.touchscreen hoặc
android.hardware.faketouch. Các phương thức triển khai thiết bị

có hệ thống nhập con trỏ:
NÊN hỗ trợ đầy đủ các con trỏ được theo dõi độ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] ctương ứng với loại màn hình cảm ứng cụ thể trên thiết bị

Android 4.0 hỗ trợ nhiều màn hình cảm ứng, bàn di chuột và thiết bị nhập
cảm ứng giả. Các hoạt động triển khai thiết bị dựa trên màn hình cảm ứng được liên kết với màn hình
[Tài nguyên, 71] để 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 trực tiếp chạm vào màn hình, nên hệ thống không
yêu cầu bổ sung bất kỳ chức 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ả cung cấp hệ thống hoạt động đầu vào của người dùng gần đúng với một số tính năng của màn hình cảm ứng.

Ví dụ: một con chuột hoặc điều khiển từ xa điều khiển
một con trỏ trên màn hình gần giống với việc chạm, nhưng yêu cầu người dùng trước hết phải trỏ hoặc đặt tiêu điểm
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ùng đầu chỏ dựa trên con quay và con trỏ
, tay điều khiển và bàn di chuột nhiều điểm chạm có thể hỗ trợ các tương 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 dùng đầu chỏ có độ trung thực cao (tức là dựa trên con trỏ) chẳng hạn như chuột
hoặc bàn di chuột có thể mô phỏng đầy đủ dữ liệu đầu vào dựa trên việc chạm (bao gồm việc hỗ trợ cử dụ
cơ bản) và cho biết rằng thiết bị hỗ trợ một nhóm nhỏ được mô phỏng của chức năng màn hình chạm
. Các hoạt động triển khai thiết bị khai báo tính năng chạm giả
PHẢI đáp ứng các yêu cầu về tính năng chạm giả trong Mục 7.2.5.
Các hoạt động 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. Các phương thứ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 phương thức 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 bao gồm 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ề thao tác chạm giả
trong Mục 7.2.5.
7.2.5. Đầu vào chạm giả
Các biện pháp triển khai thiết bị khai báo hỗ trợ android.hardware.faketouch
PHẢI báo cáo các vị trí màn hình X và Y tuyệt đối của vị trí con trỏ và
hiển thị một con trỏ hình ảnh trên màn hình[Tài nguyên, 70]
PHẢI báo cáo sự kiện chạm bằng mã thao tác [Tài nguyên, 70] chỉ định
thay đổi trạng thái xảy ra trên con trỏ go xuống hoặc lên trên màn hình
[Tài nguyên, 70]
PHẢI hỗ trợ con trỏ xuống và lên trên một đối tượng trên màn hình, cho phép
users to emulate tap on an object on the screen
PHẢI hỗ trợ con trỏ xuống, con trỏ lên, con trỏ xuống rồi con trỏ lên ở cùng
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
emulate double tap on an object on the screen [Tài nguyên, 70]
PHẢI hỗ trợ con trỏ xuống 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ỳ ý khác trên màn hình, theo sau là một con trỏ lên, cho phép
users to emulate a touch drag
PHẢI hỗ trợ con trỏ xuống rồi cho phép người dùng di chuyển nhanh đối tượng đến một
vị trí khác trên màn hình rồi con trỏ lên trên màn hình, cho phép
users to fling an object on the screen
Các thiết bị khai báo hỗ trợ android.hardware.faketouch.multitouch.distinct
PHẢI đáp ứng các yêu cầu đối với faketouch ở trên, và cũng PHẢI hỗ trợ theo dõi
khác biệt của hai hoặc nhiều đầu vào con trỏ độc lập.
7.2.6. Micrô
Hoạt động triển khai thiết bị CÓ THỂ bỏ qua micrô. Tuy nhiên, nếu quy trình triển khai thiết bị
bỏ qua micrô, thì quy trình triển khai 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 quy trình triển khai thiết bị có micrô:
PHẢI báo cáo hằng số tính năng android.hardware.microphone
NÊN đáp ứng các yêu cầu về chất lượng âm thanh trong Mục 5.4
NÊN đá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.1 bao gồm các API để truy cập vào nhiều loại cảm biến. Nhìn chung, việc triển khai
thiết bị 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ị bao gồm một loại cảm biến cụ thể có một API tương ứng
dành 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ụ: các hoạt động triển khai thiết bị:
PHẢI báo cáo chính xác về việc có hay không có các cảm biến theo lớp
android.content.pm.PackageManager. [Tàinguyê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ý cho tất cả các API cảm biến khác (ví dụ: bằng cách trả về true
hoặc false như phù 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á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 Hệ thống đơn vị quốc tế liên quan
(tức là hệ mét) cho mỗi 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 không comprehensive; hành vi được ghi nhận của SDK Android là
được coi là có thẩm quyền.
Một số loại cảm biến là dữ liệu tổng hợp, tức là các loại này 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.) Hoạt động triển khai thiết bị NÊN triển khai các loại cảm biến
này khi chúng bao gồm các cảm biến vật lý điều kiện tiên quyết.
Các API Android 4.1 giới thiệu khái niệm về cảm biến "truyền trực tuyến", đây là cảm biến
trả về dữ liệu liên tục, thay vì chỉ khi dữ liệu thay đổi. Các hoạt động triển khai
thiết bị PHẢI liên tục cung cấp mẫu dữ liệu theo chu kỳ cho mọi API
mà tài liệu SDK Android 4.1 cho biết là một cảm biến trực tuyến.
7.3.1. Gia tốc kế
Hoạt động triển khai thiết bị PHẢI bao gồm gia tốc kế 3 trục. Nếu quy trình triển khai
của thiết bị bao gồm một cảm biến gia tốc 3 trục, thì thiết bị đÓ:
PHẢI có khả năng cung cấp các sự kiện ở tốc độ 120 Hz trở lên. Lưu ý rằng mặc dù tần số của cảm biến gia tốc
ở trên được nêu là "NÊN" cho Android 4.1, 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 không bắt buộc trong Android 4.1 nhưng sẽ
bắt buộc trong các phiên bản sau này. Các thiết bị hiện có và mới chạy Android 4.1
nên đáp ứng các yêu cầu này trong Android 4.1 để
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ệ thống 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
bất kỳ vectơ ba chiềunào
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ế
Quá trình triển khai thiết bị PHẢI bao gồm một từ kế 3 trục (tức là la bàn). Nếu thiết bị
có bao gồm máy đo từ trường 3 trục, thì thiết bị đó:
PHẢI có khả năng cung cấp các sự kiện ở tốc độ 10 Hz trở lên
PHẢI tuân thủ hệ thống toạ đính của cảm biến Android như 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 mạnh từ trường đủ để bao phủ
từ trường địa chỉ
PHẢI có 8 bit độ chính xác hoặc trên
PHẢI có độ biến định tiêu không quá 0,5 µT
7.3.3. GPS
Hoạt động triển khai thiết bị PHẢI bao gồm một bộ thu GPS. Nếu quy trình triển khai thiết bị
có bao gồm máy thu GPS, thì quy trình đÓ PHẢI bao gồm một số hình thức của công nghệ "GPS hỗ trợ"
để giảm tối thiểu thời gian kết nối GPS.
7.3.4. Con quay hồi chuyển
Hoạt động 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 bao gồm cảm biến con quay hồi chuyển trừ phi cũng có gia tốc kế 3 trục
. Nếu quy trình triển khai thiết bị bao gồm con quay định hướng, thì thiết bị đó:

PHẢI bù nhiệt độ
PHẢI có khả năng đo lường các thay đổi về hướng tối đa là 5,5*Pi
radian/giây (tức là khoảng 1.000 độ/giây)
NÊN có khả năng cung cấp các sự kiện ở tốc độ 200 Hz trở lên. Lưu ý rằng mặc dù tần số con quay hồi chuyển
ở trên được nêu là "NÊN" cho Android 4.1, 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 không bắt buộc trong Android 4.1 nhưng sẽ
bắt buộc trong các phiên bản sau này. Các thiết bị hiện có và mới chạy Android 4.1
rất nên đáp ứng các yêu cầu này trong Android 4.1 để
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ó độ phân biệt không quá 1e-7 rad^2 / s^2 trên Hz (độ phân biệt trên Hz,
hoặc rad^2 / s). Bạn có thể cho phép hệ số phương sai thay đổi theo tốc độ lấy mẫu, nhưng phải
bị giới hạn theo giá trị này. Nói cách khác, nếu bạn đo độ biến động của con quay
ở tốc độ lấy mẫu 1 Hz, thì giá trị đo được không được lớn hơn 1e-7 rad^2/s^2.
PHẢI có dấu thời gian gần như thời điểm sự kiện phần cứng xảy ra
nhất có thể. Phải xoá độ trễ không thay đổi.
7.3.5. Khí áp kế
Hoạt động 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
hoạt động triển khai thiết bị bao gồm một báo áp, thì thiết bị đó:
PHẢI có khả năng cung cấp các sự kiện ở tốc độ 5 Hz trở lên
PHẢI có độ chính xác đủ để cho phép ước định độ cao
PHẢI được bù nhiệt độ
7.3.7. Nhiệt kế
Hoạt động 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 quy trình triển khai thiết bị có bao gồm nhiệt kế, thì quy trình đÓ PHẢI
đo nhiệt độ của CPU thiết bị. Thiết bị KHÔNG ĐƯỢC đo lường bất kỳ nhiệt độ
nào khác. (Lưu ý loại cảm biến này không được dùng nữa trong API Android 4.1.)
7.3.7. Photometer
Các hoạt động triển khai thiết bị CÓ THỂ bao gồm một photometer (tức là cảm biến ánh sáng xung quanh.)
7.3.8. Cảm biến độ gần
Hoạt động triển khai thiết bị CÓ THỂ bao gồm cảm biến độ gần. Nếu quy trình triển khai thiết bị
có bao gồm cảm biến độ gần, thì quy trình đó PHẢI đo độ gần của một vật thể theo
cùng hướng với màn hình. Tức là cảm biến khoảng cách PHẢI được định hướng để phát hiện
các đối tượng ở gần màn hình, vì ý định chính của loại cảm biến này là phát hiện
điện thoại mà người dùng đang sử dụng. Nếu hoạt động triển khai thiết bị bao gồm cảm biến khoảng gần có
bất kỳ hướng nào khác, thì KHÔNG ĐƯỢC truy cập vào cảm biến này thông qua API này. Nếu một hoạt động triển khai
có cảm biến độ gần, thì cảm biến đó PHẢI có độ chính xác từ 1 bit trở lên.
7.4. Khả năng kết nối dữ liệu
7.4.1. Dịch vụ điện thoại
"Dịch vụ điện thoại" theo cách API Android 4.1 sử dụng và tài liệu này cụ thể nhắc đến
phần cứng liên quan đến việc thực hiện lệnh gọi thoại và gửi tin nhắn SMS qua mạng GSM hoặc
CDMA. Mặc dù các lệnh gọi giọng nói này có thể hoặc không thể được chuyển gói, nhưng các lệnh gọi này
dành cho các mục đích của Android 4.1 được xem là độc lập với bất kỳ kết nối dữ liệu nào
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
"telephony" của Android chỉ dùng cho các loại cuộc gọi giọng nói và tin nhắn SMS; ví dụ: các hoạt động 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 lệ
chúng có sử dụng mạng di động để kết nối dữ liệu hay không.
Android 4.1 CÓ THỂ được sử dụng trên các thiết bị không có phần cứng viễn thông. Tức là
Android 4.1 tương thích với các thiết bị không phải điện thoại. Tuy nhiên, nếu quy trình triển khai
thiết bị bao gồm dịch vụ điện thoại GSM hoặc CDMA, thì quy trình đó PHẢI triển khai hỗ trợ đầy đủ
cho API dành cho công nghệ đó. Các phương thức triển khai thiết bị không bao gồm phần cứng
viễn thông PHẢI triển khai toàn bộ API dưới dạng không hoạt động.
7.4.2. IEEE 802.11 (WiFi)
Hoạt động triển khai thiết bị Android 4.1 PHẢI bao gồm hỗ trợ cho một hoặc nhiều hình thức
của 802.11 (b/g/a/n, v.v.) Nếu hoạt động triển khai thiết bị có hỗ trợ 802.11, thì hoạt động đó
PHẢI triển khai API Android tương ứng.

Các hoạt động triển khai thiết bị PHẢI triển khai API multicast như mô tả trong tài liệu
của 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 multicast (mDNS). Các hoạt động triển khai thiết bị KHÔNG ĐƯỢC lọc các gói mDNS
(224.0.0.251) bất cứ lúc nào hoạt động, kể cả khi màn hình không ở trạng thái
hoạt động.
7.4.2.1. Wi-Fi Direct
Hoạt động triển khai thiết bị PHẢI bao gồm hỗ trợ cho Wi-Fi direct (Wi-Fi giữa các thiết bị). Nếu
quy trình triển khai thiết bị có hỗ trợ Wifi trực tiếp, thì quy trình đó 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
quy trình triển khai thiết bị có hỗ trợ Wifi trực tiếp, thì quy trình đó:
PHẢI hỗ trợ hoạt động Wifi thông thường
NÊN hỗ trợ hoạt động đồng thời của wifi và wifi Trực tiếp
7.4.3. Bluetooth
Hoạt động 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ị bao gồm 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 [Tài nguyên, 42]. Các hoạt động triển khai
thiết bị PHẢI triển khai các hồ sơ Bluetooth liên quan, chẳng hạn như A2DP,
AVRCP, OBEX, v.v. cho phù hợp với thiết bị.
Bộ kiểm thử khả năng tương thích bao gồm các trường hợp bao gồm hoạt động cơ bản của API Bluetooth Android
RFCOMM. Tuy nhiên, vì Bluetooth là một giao thức giao tiếp
giữa các thiết bị, nên không thể kiểm thử đầy đủ bằng các kiểm thử đơn vị chạy trên một thiết bị.
Do đó, các hoạt động triển khai thiết bị CŨNG PHẢI đạt được quy trình kiểm thử Bluetooth
do con người thực hiện như mô tả trong Phụ lục A.
7.4.4. Giao tiếp phạm vi gần
Hoạt động triển khai thiết bị PHẢI bao gồm một bộ thu phát và phần cứng liên quan cho
Giao tiếp phạm vi gần (NFC). Nếu quy trình triển khai thiết bị 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 điệp NDEF thông qua các tiêu chuẩn
NFC sau:
PHẢI có khả năng đóng vai làm máy đọc/ghi NFC Forum (như được xác định bởi
quy cách kỹ thuật NFC Forum NFCForum-TS-DigitalProtocol-1.0)
thông qua các tiêu chuẩn NFC sau:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (do NFC Forum xác định)
NÊN có khả năng đọc và ghi thông điệp NDEF thông qua các tiêu chuẩn NFC
sau. Lưu ý rằng mặc dù các tiêu chuẩn NFC bên dưới được nêu là
"NÊN" cho Android 4.1, 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.1 nhưng sẽ bắt buộc trong các phiên bản sau này. Các thiết bị hiện tại và mới
chạy Android 4.1 nên đáp ứng các yêu cầu này
trong Android 4.1 để 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 thông qua các tiêu chuẩn và giao thức giữa
các thiết bị nhau:
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 tính NEP mặc định. Bạn PHẢI gửi các thông điệp NDEF hợp lệ
mà máy chính SNEP mặc định nhận được đến các ứng dụng
bằng ý định android.nfc.ACTION_NDEF_DISCOVERED. Khi tắt
Android Beam trong chế độ cài đặt, BẠN KHÔNG ĐƯỢC tắt việc gửi thông báo
NDEF đến.
Khi triển khai thiết bị, BẠN PHẢI tuân thủ ý định
android.settings.NFCSHARING_SETTINGS để hiển thị chế độ cài đặt chia sẻ NFC

[Resources, 67].
BẠN PHẢI triển khai máy chạy NPP. Các thông điệp mà máy chính NPP nhận được
PHẢI được xử lý theo cách tương tự như máy chính mặc định của SNEP.
PHẢI triển khai một ứng dụng SNEP và cố gắng gửi NDEF P2P đến máy chính mặc định của SNEP khi Android Beam được bật.
Nếu không tìm thấy máy chính
SNEP mặc định, thì máy khách PHẢI cố gắng gửi cho máy chính
NPP.
PHẢI cho phép các hoạt động trên nền đầu tiên để đặt tin nhắn NDEF P2P đến cùng
sử dụng android.nfc.NfcAdapter.setNdefPushMessage, và
android.nfc.NfcAdapter.setNdefPushMessageCal quay lại, và
android.nfc.NfcAdapter.enableForegroundNdefPush.
NÊN sử dụng một cử chỉ hoặc xác nhận trên màn hình, chẳng hạn như "Chạm để
chiếu", trước khi gửi tin nhắn NDEF P2P đến cùng.
NÊN bật Android Beam theo mặc định
PHẢI hỗ trợ chuyển nhượng Kết nối NFC sang Bluetooth khi thiết bị
hỗ trợ Hồ sơ đẩy đối tượng Bluetooth. Các hoạt động 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
"Chuyển đổi kết nối phiên bản 1.2" [Tài nguyên, 60] và "Bluetooth bảo mật
Ghép nối đơn giản bằng NFC phiên bản 1.0" [Tài nguyên, 61] thông số kỹ thuật từ
NFC Forum. Một cách triển khai SHOULD sử dụng các yêu cầu GET của SNEP
để trao đổi yêu cầu chuyển nhượng / chọn bản ghi qua NFC, và cách triển khai này
PHẢI sử dụng Hồ sơ đẩy đối tượng Bluetooth để chuyển dữ liệu Bluetooth thực tế
.
PHẢI tìm kiếm tất cả các công nghệ được hỗ trợ trong chế độ tìm kiếm NFC.
NÊN ở chế độ tìm kiếm NFC khi thiết bị ở trạng thái bật với màn hình
đang hoạt động và màn hình khoá đã mở.
(Xin lưu ý rằng các đường liên kết công khai không có sẵn cho các thông số kỹ thuật JIS, ISO và NFC Forum
đượ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 đây.
MIFARE Classic (NXP MF1S503x [Tài nguyên, 44], MF1S703x [Tài nguyên, 44])
MIFARE Ultralight (NXP MF0ICU1 [Tài nguyên, 46], MF0ICU2 [Tài nguyên, 46])
NDEF trên MIFARE Classic (NXP AN130511 [Tài nguyên, 48], AN130411
[Tài nguyên, 49])
Lưu ý that Android 4.1 includes APIs for these types MIFARE. Nếu hoạt động triển khai
thiết bị hỗ trợ MIFARE trong vai trò trình đọc/ghi, thì hoạt động đó:
PHẢI triển khai các API Android tương ứng như được ghi dưới dạng tài liệu của
Android SDK
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] Lưu ý rằng đây không phải là một tính năng Android chuẩn, và do đó
không xuất hiện dưới dạng một hằng số trên lớp PackageManager.
KHÔNG ĐƯỢC triển khai API Android tương ứng hoặc báo cáo tính năng
com.nxp.mifare trừ trường hợp cũng triển khai hỗ trợ NFC chung như
mô tả trong phần này
Nếu hoạt động triển khai thiết bị không bao gồm phần cứng NFC, thì 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à KHÔNG ĐƯỢC triển khai API NFC Android 4.1 dưới dạng không hoạt động.
Vì các lớp android.nfc.NdefMessage và android.nfc.NdefRecord r đại diện cho
định dạng biểu thị dữ liệu độc lập với giao tiếp, hoạt động triển khai thiết bị KHÔNG ĐƯỢC triển khai các API này ngay cả khi không bao gồm hỗ trợ cho NFC hoặc khai báo tính năng
android.hardware.nfc.

7.4.5. Chức năng mạng tối thiểu
Hoạt động 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ể, các hoạt động triển khai thiết bị PHẢI bao gồm hỗ trợ cho í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.
Các phương thức triển khai thiết bị trong đó một 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 PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu không dây
phổ biến, chẳng hạn như 802.11 (WiFi).
Thiết bị CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu.

7.5. Máy ảnh
Hoạt động triển khai thiết bị PHẢI bao gồm máy ảnh sau và CÓ THỂ bao gồm máy ảnh trước
. Máy ảnh mặt sau là máy ảnh nằm ở cạnh của thiết bị
đối diện với màn hình; tức là máy ảnh này chụp hình ảnh ở phía xa của thiết bị, giống như
máy ảnh truyền thống. Máy ảnh mặt trước là máy ảnh nằm ở cùng một phía của
thiết bị với màn hình; tức là máy ảnh thường được dùng để chụp ảnh người dùng, chẳng hạn như cho
hội nghị truyền hình và các ứng dụng tương tự.
7.5.1. Máy ảnh mặt sau
Hoạt động triển khai thiết bị PHẢI bao gồm máy ảnh mặt sau. Nếu hoạt động triển khai
của thiết bị bao gồm camera sau, thì thiết bị đó:
PHẢI có độ phân giải ít nhất là 2 megapixel
NÊN có tính năng tự động lấy tiêu điểm bằng phần cứng hoặc tự động lấy tiêu điểm bằng phần mềm được triển khai
trong trình điều khiển camera (trong sáng cho phần mềm ứng dụng)
CÓ THỂ có phần cứng lấy tiêu điểm cố định hoặc EDOF (độ sâu của hình ảnh mở rộng)
CÓ THỂ có đèn flash. Nếu Máy ảnh có đèn flash, thì đèn flash KHÔNG ĐƯỢC
nháy trong khi một phiên bản android.hardware.Camera.PreviewCal đã được
đăng ký trên một mặt bằng xem trước của Máy ảnh, trừ trường hợp ứng dụng đã
bật đèn flash một cách rõ ràng bằng cách bật các thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON
của đối tượng Camera.Parameters. Xin lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng máy ảnh hệ thống tích hợp sẵn của thiết bị
, mà chỉ áp dụng cho các ứng dụng bên thứ ba
sử dụng Camera.PreviewCallback.
7.5.2. Máy ảnh mặt trước
Hoạt động triển khai thiết bị CÓ THỂ bao gồm máy ảnh mặt trước. Nếu quy trình triển khai thiết bị
bao gồm máy ảnh mặt trước, thì:
PHẢI có độ phân giải tối thấp là VGA (tức là 640x480 pixel)
KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước là mặc định cho Camera API. Tức là
API máy ảnh trong Android 4.1 có hỗ trợ cụ thể cho máy ảnh mặt trước, và
hoạt động triển khai thiết bị KHÔNG ĐƯỢC định cấu hình API để xem máy ảnh mặt trước
là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị
.
CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động làm nét, đèn flash, v.v.) có sẵn cho máy ảnh mặt sau
như mô tả trong Mục 7.5.1.
PHẢI phản chiếu theo ngang (tức là phản chiếu) luồng do ứng dụng hiển thị trong
CameraPreview, như sau:
Nếu hoạt động triển khai thiết bị có khả năng được người dùng xoay (chẳng hạn như
tự động qua một cảm biến tốc độ hoặc thủ cụ qua dữ liệu đầu vào của người dùng), thì bản xem trước
máy ảnh KHÔNG ĐƯỢC phản chiếu theo 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 rằng màn hình Camera
phải được xoay qua một lệnh gọi đến phương thức
android.hardware.Camera.setDisplayOrientation() [Tài nguyên, 50]
, thì bản xem trước máy ảnh KHÔNG ĐƯỢC phản chiếu theo ngang so với hướng
do ứng dụng chỉ định.
Nếu không, bản xem trước KHÔNG ĐƯỢC phản chiếu dọc theo trục ngang
mặc định của thiết bị.
PHẢI phản ánh hình ảnh do postview hiển thị theo cách tương tự như luồng hình ảnh xem trước của
máy ảnh. (Nếu cách triển khai thiết bị không hỗ trợ
postview, thì yêu cầu này rõ ràng là không áp dụng.)
KHÔNG ĐƯỢC phản ánh luồng ảnh hoặc video đã chụp cuối cùng được trả về
lệnh gọi lại ứng dụng hoặc được cam kết với bộ lưu trữ nội dung đa phương tiện
7.5.3. Hành vi API máy ảnh
Các hoạt động triển khai thiết bị PHẢI triển khai các hành vi sau cho các API liên quan đến máy ảnh-
, cho cả máy ảnh mặt trước và máy ảnh mặt sau:
1.  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.
2.  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 chuyển vào onPreviewFrame()
phải ở định dạng mã hoá NV21. Tức là NV21 PHẢI là mặc định.
3.  Các hoạt động triển khai thiết bị PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số

android.graphics.ImageFormat.YV12) cho bản xem trước của máy ảnh cho cả máy ảnh
mặt trước và mặt sau. (Bộ giải mã video phần cứng và máy ảnh 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.)
Các hoạt động triển khai thiết bị PHẢI triển khai API Camera đầy đủ có trong tài liệu SDK Android
4.1 [Resources, 51]), rbất kể thiết bị có tính năng tự động lấy nét
phần cứng hay các tính năng khác. Ví dụ: các máy ảnh thiếu tính năng tự động lấy tiêu điểm
PHẢI vẫn gọi bất kỳ phiên bản android.hardware.Camera.AutoFocusCallback
đã đăng ký nào (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 tiêu điểm.) Xin lưu ý rằng
điều này có á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 API quay lại vẫn phải bị "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à
một 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 dưới đây. Ngược lại, các hoạt động 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 vào phương thức
android.hardware.Camera.setParameters() ngoài những hằng số được ghi nhận là
hằng số trên android.hardware.Camera.Parameters. Tức là, các hoạt động triển khai
thiết bị PHẢI hỗ trợ tất cả các tham số Máy ảnh chuẩn nếu phần cứng
cho phép, và KHÔNG ĐƯỢC hỗ trợ các loại tham số Máy ảnh tuỳ chỉnh.
Hoạt động triển khai thiết bị PHẢI truyền tin ý định Camera.ACTION_NEW_PICTURE
bất cứ khi nào máy ảnh chụp một ảnh mới và mục của ảnh đã được
thêm vào kho nội dung đa phương tiện.
Hoạt động triển khai thiết bị PHẢI truyền ý định Camera.ACTION_NEW_VIDEO
bất cứ khi nào camera ghi video mới và mục ảnh đã được
thêm vào kho nội dung đa 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. Tức là khi thiết bị
được cầm theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang
. Điều này áp dụng bất kể hướng tự nhiên của thiết bị; nghĩa là
áp dụng cho cả thiết bị chính là hướng ngang và thiết bị chính là hướng dọc.
7.6. Bộ nhớ và dung lượng lưu trữ
7.6.1. Dung lượng bộ nhớ và bộ lưu trữ tối thiểu
Các hoạt động triển khai thiết bị PHẢI có ít nhất 340 MB bộ nhớ dành cho hạt nhân
và không gian người dùng. 340 MB PHẢI là bổ sung cho bất kỳ bộ nhớ dành riêng cho các thành phần phần cứng
chẳng hạn như radio, video, v.v. không dưới quyền kiểm soát
của hạt nhân.
Các hoạt động triển khai trên thiết bị PHẢI có ít nhất 350 MB bộ nhớ không volatility
cho dữ liệu riêng tư của ứng dụng. Tức là phân bộ /data PHẢI có dung lượng ít nhất 350 MB.
Các 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 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
Các hoạt động triển khai thiết bị PHẢI cung cấp bộ nhớ dùng chung cho ứng dụng. Dung lượng
lưu trữ chung được cung cấp PHẢI có kích thước tối t thiểu là 1 GB.
Các hoạt động 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 biểu tượng Linux từ /sdcard đến điểm gắn thực tế.
Hoạt động triển khai thiết bị PHẢI thực thi như đã ghi quyền
android.permission.WRITE_EXTERNAL_STORAGE trên bộ nhớ dùng chung này.
Nếu không, mọi ứng dụng có quyền
đó PHẢI ghi được vào bộ nhớ dùng chung.
Hoạt động triển khai thiết bị CÓ THỂ có phần cứng dành 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, các hoạt động triển khai thiết bị CÓ THỂ phân bổ bộ nhớ trong (không thể tháo rời)
dưới dạng bộ nhớ dùng chung cho các ứng dụng.

Bất kể hình thức lưu trữ dùng chung nào, hoạt động triển khai thiết bị PHẢI
cung cấp một số cơ chế để truy cập nội dung của bộ lưu trữ dùng chung từ máy tính
máy chủ, chẳng hạn như bộ lưu trữ dùng chung USB (UMS) hoặc Giao thức truyền nội dung đa phương tiện (MTP).
Hoạt động triển khai thiết bị CÓ THỂ sử dụng bộ lưu trữ dùng chung USB, nhưng NÊN sử dụng Giao thức truyền nội dung đa phương tiện
. Nếu cách triển khai thiết bị hỗ trợ Giao thức chuyển tệp đa phương tiện:
Cách triển khai thiết bị PHẢI tương thích với máy chủ Android
MTP, Chuyển tệp Android [Resources, 57].
Cách triển khai thiết bị PHẢI báo cáo lớp thiết bị USB là 0x00.
Cách triển khai thiết bị PHẢI báo cáo tên giao diện USB là "MTP".
Nếu quy trình 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
.
Để minh hoạ, hãy xem xét hai ví dụ phổ biến. Nếu quy trình triển khai thiết bị bao gồm
khe thẻ SD để đáp ứng yêu cầu về bộ nhớ chia sẻ, thẻ SD định dạng FAT
có dung lượng 1 GB trở lên PHẢI được bao gồm trong thiết bị khi bán cho người dùng và PHẢI
được gắn theo mặc định. Ngoài ra, nếu một hoạt động 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à một đường liên kết biểu tượng đến vị trí vật lý nếu
được gắn ở nơi khác.)
Các phương thức triển khai thiết bị bao gồm nhiều đường dẫn bộ nhớ dùng chung (chẳng hạn như cả khe 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
Hoạt động triển khai thiết bị PHẢI bao gồm cổng máy khách USB và PHẢI bao gồm cổng máy chủ USB
.
Nếu quy trình triển khai thiết bị bao gồm cổng máy khách 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 NÊN sử dụng hệ số hình dạng USB vi mô ở bên thiết bị.
Các thiết bị hiện có và thiết bị mới chạy Android 4.1 nên đáp ứng
các yêu cầu này trong Android 4.1 để 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 đặt ở giữa cạnh. Các hoạt động triển khai thiết bị
NÊN đặt cổng ở dưới cùng của thiết bị (theo hướng
tự nhiên) hoặc bật chế độ xoay màn hình phần mềm cho tất cả các ứng dụng (bao gồm màn hình
chính), để màn hình vẽ chính xác khi thiết bị được định hướng với cổng
ở dưới cùng. Các thiết bị hiện có và mới chạy Android 4.1 rất cần
phải đáp ứng các yêu cầu này trong Android 4.1 để 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ổng đó PHẢI
nằm trên cùng một cạnh với cổng micro-USB
. Thiết bị 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
phương tiện lưu trữ 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
. Thiết bị PHẢI triển khai API và thông số kỹ thuật của Android Open Accessory như
được ghi lại 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]
. Thiết bị PHẢI triển khai lớp âm thanh USB như
được ghi lại trong tài liệu SDK Android [Tài nguyên, 66]
. Thiết bị PHẢI triển khai tính năng hỗ trợ cho thông số kỹ thuật sạc pin USB
[Tài nguyên, 64]. Các thiết bị hiện có và mới chạy Android 4.1 rất cần
phải đáp ứng các yêu cầu này trong Android 4.1 để 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 quá trình triển khai thiết bị bao gồm cổng máy chủ USB:
thì thiết bị CÓ THỂ sử dụng hệ số hình dạng cổng không chuẩn, nhưng nếu có thì PHẢI đi kèm với cáp hoặc
cáp điều chỉnh cổng thành USB-A tiêu chuẩn
. Thiết bị PHẢI triển khai API máy chủ USB Android như
được ghi lại trong SDK Android, đồng thời PHẢI khai báo hỗ trợ cho tính năng phần cứng
android.hardware.usb.host [Tài nguyên, 53]
. Quá trình 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 máy khách USB, thì quá trình đó PHẢI triển khai Cầu gỡ lỗi Android
qua mạng khu vực 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
Các phương thứ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.1
được xác định trong bảng bên dưới:
Chỉ số
Ngưỡng hiệu suất
Ghi chú
Các ứng dụng sau
phải khởi chạy trong
thời gian đã chỉ định.
Thời gian khởi chạy được đo lường bằng
tổng thời gian để hoàn tất việc tải
Trình duyệt: dưới
hoạt động mặc định cho ứng dụng,
Ứng dụng
1300 mili giây
bao gồm cả thời gian cần thiết để bắt đầu
Thời gian khởi chạy
Danh bạ: dưới
quá trình Linux, tải gói Android
700 mili giây
vào máy ảo Dalvik và cal
Cài đặt: dưới
onCreate.
700 mili giây
Khi nhiều ứng dụng
đã được khởi chạy, hãy
khởi chạy lại một ứng dụng đã
Đồng thời
đang chạy sau khi ứng dụng đó

Ứng dụng
đã được khởi chạy phải
mất ít thời gian khởi chạy
ban đầu.
9. Khả năng tương thích với mô hình bảo mật
Các hoạt động 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
các API [Tài nguyên, 54] trong tài liệu dành cho nhà phát triển Android. Các hoạt động 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 bất kỳ quyền/giấy tờ bổ sung nào từ bất kỳ bên thứ ba/cơ quan nào.
Cụ thể, các thiết bị tương thích PHẢI hỗ trợ các cơ chế bảo mật được mô tả trong
các phần nhỏ 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ể, các biện pháp 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ỏ lỡ quyền
. Các phương thức 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 có trong không gian tên android.*
.
9.2. UID và Phân tách quy trình
Các biện pháp 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 mã nhận dạng theo kiểu Unix riêng biệt và trong một quy trình riêng.
Các biện pháp triển khai thiết bị PHẢI hỗ trợ việc 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à xây dựng đúng cách, như
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 trên hệ tệp
Quá trình triển khai thiết bị PHẢI hỗ trợ mô hình quyền truy cập tệp của Android như
được xác định trong 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.4. Môi trường thực thi thay thế
Hoạt động 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 các ứng dụng
bằng một số phần mềm hoặc công nghệ khác bên ngoài máy ảo Dalvik hoặc mã gốc
. Tuy nhiên, những môi trường thực thi thay thế NHẤT THIẾT KHÔNG được làm mất an toàn của
mô hình bảo mật Android hoặc an toàn của các ứng dụng Android đã cài đặt, như mô tả
trong phần này.
Các 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 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>.

Các môi trường thời gian chạy thay thế KHÔNG ĐƯỢC cho phép ứng dụng sử dụng các tính năng được bảo vệ
bằng các quyền Android chỉ dành cho ứng dụng hệ thống.
Các 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ể:
Các môi trường thời gian chạy thay thế PHẢI cài đặt các ứ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.)
Các môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android riêng biệt được chia sẻ bởi tất cả các ứng dụng
sử dụng môi trường thời gian chạy thay thế
Các môi trường thời gian chạy thay thế và các ứng dụng đã cài đặt sử dụng một 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 chuẩn của mã nhận dạng người dùng chung và chứng chỉ ký
Các 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
Các 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 ứ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 mã nhận dạng người dùng khác.

Các tệp .apk của các thời gian chạy thay thế CÓ THỂ được đưa vào hình ảnh hệ thống của quy trình triển khai
trên thiết bị, nhưng PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng
khác được đưa vào quy trình triển khai thiết bị.
Khi cài đặt ứng dụng, các thời gian chạy thay thế PHẢI có sự đồng ý của người dùng đối với các quyền
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ưu các chức năng ứ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ả quyền
do 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 đó.
10. Kiểm thử khả năng tương thích của phần mềm
Các hoạt động triển khai thiết bị PHẢI đạt được tất cả các kiểm thử được mô tả trong phần này.
Tuy nhiên, hãy lưu ý rằng không có gói kiểm thử phần mềm nào đầy đủ. Vì lý do này,
những người triển khai thiết bị nên rất nhiều khuyến khích để tạo số lượng thay đổi
tối thiểu có thể cho tài liệu tham khảo và cách triển khai ưu tiên của Android 4.1
có trong Dự án nguồn mở Android. Điều này sẽ giảm thiểu nguy cơ
gây ra lỗi khiến xảy ra sự không tương thích yêu cầu làm lại và các bản cập nhật
thiết bị có thể xảy ra.
10.1. Bộ kiểm tra tính tương thích
Hoạt động triển khai thiết bị PHẢI đạt được Bộ kiểm tra tính tương thích với Android (CTS)
[Tài nguyên, 2] có trong Dự án nguồn mở của Android, bằng cách sử dụng phần mềm phát hành
chính thức trên thiết bị. Ngoài ra, nhà triển khai thiết bị NÊN sử dụng
cách triển khai tham chiếu trong cây Nguồn mở Android nhiều nhất có thể và
PHẢI đảm bảo khả năng tương thích trong trường hợp không rõ ràng trong CTS và cho mọi
triển khai lại các phần của mã nguồn tham chiếu.
CTS được thiết kế để chạy trên một thiết bị thực. Giống như mọi phần mềm khác, CTS có thể
tự chứa lỗi. CTS sẽ được phân phiên bản một cách độ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 chữa của CTS cho Android 4.1. Các hoạt động triển khai
của thiết bị PHẢI đạt được phiên bản CTS mới nhất có sẵn tại thời điểm phần mềm
của thiết bị được hoàn tất.
10.2. Trình xác minh CTS
Các hoạt động triển khai thiết bị PHẢI thực thi chính xác tất cả các trường hợp áp dụng trong Trình xác minh CTS
. Trình xác minh CTS được đưa vào Bộ kiểm thử khả năng tương thích và dành cho
người sử dụng để kiểm thử chức năng mà
hệ thống tự động không kiểm thử được, chẳng hạn như chức năng hoạt động đúng cách của máy ảnh và các cảm biến.
Trình xác mạng CTS có các quy trình kiểm thử cho nhiều loại phần cứng, bao gồm một số phần cứng
không bắt buộc. Các hoạt động triển khai thiết bị PHẢI đạt tất cả các kiểm thử đối với 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 như
không bắt buộc theo Tài liệu xác định khả năng tương thích này.
Mọi thiết bị và mọi bản xây DÙNG được phải chạy chính xác Trình xác minh CTS, như đã lưu ý ở trên.
Tuy nhiên, vì nhiều bản xây rất tương tự, nhà triển khai thiết bị không phải
chạy rõ ràng Trình xác minh CTS trên các bản xây chỉ khác nhau theo cách không quan trọng. Cụ thể,
các phương thức triển khai thiết bị khác với phương thức triển khai đã vượt qua Trình xác minh CTS
chỉ bằng bộ ngôn ngữ, thương hiệu, v.v. ĐƯỢC phép bỏ qua kiểm thử Trình xác minh CTS

.
10.3. Ứng dụng tham chiếu
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" [Tàinguyên, 55]
Replica Island (có trong Android Market)
Mỗi ứng dụng ở trên PHẢI chạy và hoạt động chính xác trên quá trình triển khai, để quá trình triển khai
được xem là tương thích.
11. Phần mềm có thể cập nhật
Hoạt động 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" – tức là có thể cần phải khởi động lại thiết bị
.
Bạn có thể sử dụng bất kỳ phương thức nào, miễn là phương thức đó có thể thay thế toàn bộ phần mềm
được cài đặt trước 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 không dây (OTA) với cập nhật ngoại tuyến thông qua quá trình khởi động lại
Cập nhật"Kết nối di động" qua USB từ máy tính máy chủ
Cập nhật"Ngoại tuyến" thông qua quá trình khởi động lại và cập nhật từ tệp trên bộ nhớ có thể rút ra
Cơ chế cập nhật được sử dụng PHẢI hỗ trợ 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 duy trì dữ liệu riêng tư của ứng dụng và dữ liệu chia sẻ
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 phát hành nhưng trong
thời gian sản phẩm hợp lý được xác định khi tham khảo với Nhóm khả năng tương thích
của Android để ảnh hưởng đến khả năng tương thích của ứng dụng bên thứ ba, thì người triển khai
thiết bị PHẢI sửa lỗi thông qua bản cập nhật phần mềm có sẵn mà có thể
áp dụng theo cơ chế mới miêu tả.
12. Liên hệ với chúng tôi
Bạn có thể liên hệ với các tác giả tài liệu tại compatibility@android.com để làm sáng tỏ
và để đưa ra bất kỳ vấn đề nào mà bạn nghĩ tài liệu chưa đề cập.

Phụ lục A - Quy trình kiểm thử Bluetooth
Bộ kiểm thử khả năng tương thích bao gồm các trường hợp bao gồm hoạt động cơ bản của API Bluetooth
RFCOMM của Android. Tuy nhiên, vì Bluetooth là một giao thức giao tiếp
giữa các thiết bị, nên không thể kiểm thử đầy đủ bằng các kiểm thử đơn vị chạy trên một thiết bị.
Do đó, các hoạt động triển khai thiết bị CŨNG PHẢI đạt được quy trình kiểm thử Bluetooth
do con người thực hiện như mô tả dưới đây.
Quy trình kiểm thử dựa trên ứng dụng mẫu BluetoothChat có trong cây dự án nguồn mở Android
. Quy trình yêu cầu 2 thiết bị:
quy trình triển khai thiết bị đề xuất chạy bản xây dựng phần mềm sẽ được kiểm thử
quy trình triển khai thiết bị riêng biệt đã biết là tương thích và của một
mô hình từ quy trình triển khai thiết bị đang được kiểm thử – tức là quy trình triển khai thiết bị
"đã biết là tốt"
Quy trình kiểm thử dưới đây gọi các thiết bị này lần lượt là thiết bị "đề xuất" và thiết bị "đã biết là tốt
".
Thiết lập và cài đặt
1.  Tạo BluetoothChat.apk thông qua "tạo mẫu" từ cây mã nguồn Android
2.  Cài đặt  BluetoothChat.apk trên thiết bị đã biết là tốt
3.  Cài đặt  BluetoothChat.apk trên thiết bị đề xuất
Kiểm thử Chế độ kiểm soát Bluetooth bằng ứng dụng
1.  Chạy BluetoothChat trên thiết bị đề nghị, trong khi Bluetooth đang tắt
2.  Xác minh rằng thiết bị đề nghị bật Bluetooth hoặc nhắc người dùng
bằng một hộp thoại để bật Bluetooth
Kiểm tra việc ghép nối và giao tiếp
1.  Chạy ứng dụng Bluetooth Chat trên cả hai thiết bị
2.  Cho phép phát hiện thiết bị đã biết và đáng tin cậy từ trong BluetoothChat (sử dụng Trình đơn
)
3.  Trên thiết bị đề nghị, quét tìm các thiết bị Bluetooth từ trong BluetoothChat
(sử dụng Trình đơn) và ghép nối với thiết bị đã biết là chạy được
4.  Gửi 10 hoặc nhiều tin nhắn từ mỗi thiết bị và xác minh rằng thiết bị khác
nhận được các tin nhắn đúng cách
5.  Đóng ứng dụng BluetoothChat trên cả hai thiết bị bằng cách nhấn vào nút Home
6.  Huỷ ghép nối mỗi thiết bị với thiết bị khác, bằng ứng dụng Cài đặt thiết bị
Kiểm thử Ghép nối và giao tiếp theo chiều Ngược

1.  Chạy ứng dụng Bluetooth Chat trên cả hai thiết bị.
2.  Để thiết bị đề nghị có thể khám phá từ trong BluetoothChat (sử dụng Trình đơn
).
3.  Trên thiết bị đã biết là chạy được, quét tìm các thiết bị Bluetooth từ trong BluetoothChat
(sử dụng Trình đơn) và ghép nối với thiết bị đề xuất.
4.  Gửi 10 tin nhắn từ mỗi thiết bị và xác minh rằng thiết bị khác
nhận được tin nhắn một cách chính xác.
5.  Đóng ứng dụng Bluetooth Chat trên cả hai thiết bị bằng cách nhấn vào nút Quay lại nhiều lần để
chuyển đến Trình chạy.
Kiểm thử lần chạy lại
1.  Khởi động lại ứng dụng Bluetooth Chat trên cả hai thiết bị.
2.  Gửi 10 tin nhắn từ mỗi thiết bị và xác minh rằng thiết bị khác
nhận được tin nhắn một cách chính xác.
Lưu ý: các bài kiểm thử ở trên có một số trường hợp kết thúc một phần kiểm thử bằng cách sử dụng Trang chính và
một số trường hợp sử dụng phím Quay lại. Các kiểm thử này không là không cần thiết và không phải là không bắt buộc: mục tiêu là
xác minh rằng API và ngăn Bluetooth hoạt động chính xác cả khi Hoạt động được
kết thúc rõ ràng (thông qua việc người dùng nhấn nút Quay lại, điều này sẽ kết thúc lệnh()), và được gửi
sang chế độ nền một cách ngầm ẩn (thông qua việc người dùng nhấn nút Màn hình chính.) BẠN PHẢI thực hiện từng trình tự kiểm thử
như mô tả.

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

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