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

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.

Bản quyền © 2010, Google Inc. Tất cả các quyền được bảo hộ.
compatibility@android.com

Mục lục

1. Giới thiệu

Tài liệu này liệt kê các yêu cầu phải được đáp ứng để điện thoại di động tương thích với Android 2.3.

Việc sử dụng các từ "phải", "không được", "bắt buộc", "sẽ", "sẽ không", "nên", "không nên", "nên dùng", "có thể" và "không bắt buộc" là theo tiêu chuẩn IETF được xác định trong RFC2119 [Tài nguyên, 1].

Trong tài liệu này, "người triển khai thiết bị" hoặc "người triển khai" là một người hoặc tổ chức phát triển giải pháp phần cứng/phần mềm chạy Android 2.3. "Triển khai thiết bị" hoặc "triển khai" là giải pháp phần cứng/phần mềm được phát triển.

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

Nếu định nghĩa này hoặc các thử nghiệm phần mềm được mô tả trong Mục 10 không rõ ràng, mơ hồ hoặc chưa đầy đủ, thì người triển khai thiết bị có trách nhiệm đảm bảo khả năng tương thích với các phương thức triển khai hiện có. Vì lý do này, Dự án nguồn mở Android [Tài nguyên, 3] vừa là tài liệu tham khảo vừa là phương thức triển khai ưu tiên của Android. Những người triển khai thiết bị nên triển khai dựa trên mã nguồn "nguồn cấp trên" có sẵn trong Dự án nguồn mở Android ở mức độ lớn nhất có thể. Mặc dù một số thành phần có thể được thay thế bằng cách triển khai thay thế, nhưng bạn không nên thực hiện phương pháp này vì việc vượt qua các bài kiểm thử phần mềm sẽ trở nên khó khăn hơn đáng kể. Người triển khai có trách nhiệm đảm bảo khả năng tương thích đầy đủ về hành vi với cách triển khai Android tiêu chuẩn, bao gồm cả Bộ kiểm thử khả năng tương thích. Cuối cùng, xin lưu ý rằng tài liệu này nghiêm cấm một số hoạt động thay thế và sửa đổi thành phần.

Xin lưu ý rằng Định nghĩa về khả năng tương thích này được phát hành để tương ứng với bản cập nhật 2.3.3 cho Android, tức là API cấp 10. Định nghĩa này không còn được dùng nữa và thay thế Định nghĩa về khả năng tương thích cho các phiên bản Android 2.3 trước phiên bản 2.3.3. (Tức là các phiên bản 2.3.1 và 2.3.2 đã lỗi thời.) Các thiết bị tương thích với Android trong tương lai chạy Android 2.3 PHẢI đi kèm với phiên bản 2.3.3 trở lên.

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/docs/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. Chuỗi phiên bản được phép của Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
8. Lớp android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Các tính năng ngoại tuyến của HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
11. Thẻ video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. API vị trí địa lý HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. API cơ sở dữ liệu web HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
15. Thông số kỹ thuật của Máy ảo Dalvik: có trong mã nguồn Android, tại dalvik/docs
16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Thông báo: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Tài nguyên ứng dụng: http://code.google.com/android/reference/available-resources.html
19. Hướng dẫn về kiểu biểu tượng Thanh trạng thái: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Trình quản lý tìm kiếm: http://developer.android.com/reference/android/app/SearchManager.html
21. Thông báo ngắn: http://developer.android.com/reference/android/widget/Toast.html
22. Hình nền động: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Tài liệu tham khảo về công cụ (dành cho adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. Nội dung mô tả tệp apk Android: http://developer.android.com/guide/topics/fundamentals.html
25. Tệp kê khai: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Công cụ kiểm thử Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Danh sách tính năng phần cứng Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Hỗ trợ nhiều màn hình: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. Không gian toạ độ cảm biến: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. Giao thức đẩy NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. API hướng máy ảnh: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. 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
43. Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android

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

3. Phần mềm

Nền tảng Android bao gồm một nhóm API được quản lý, một nhóm API gốc và một nhóm API được gọi là "mềm", chẳng hạn như hệ thống Ý định và API ứng dụng web. Phần này trình bày chi tiết về các API cứng và mềm không thể thiếu đối với khả năng tương thích, cũng như một số hành vi kỹ thuật và giao diện người dùng có liên quan khác. Việc triển khai thiết bị PHẢI tuân thủ tất cả các yêu cầu trong phần này.

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

Môi trường thực thi được quản lý (dựa trên Dalvik) là phương tiện chính cho các ứng dụng Android. Giao diện lập trình ứng dụng (API) Android là tập hợp các giao diện nền tảng Android hiển thị cho các ứng dụng chạy trong môi trường máy ảo được quản lý. Việc triển khai thiết bị PHẢI cung cấp các phương thức triển khai đầy đủ, bao gồm tất cả hành vi được ghi nhận, của mọi API được ghi nhận mà SDK Android 2.3 hiển thị [Tài nguyên, 4].

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

Định nghĩa về khả năng tương thích này cho phép một số loại phần cứng mà Android bao gồm các API bị bỏ qua khi triển khai thiết bị. Trong những trường hợp như vậy, API VẪN PHẢI xuất hiện và hoạt động một cách hợp lý. Hãy xem 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 mềm của API

Ngoài các API được quản lý trong Phần 3.1, Android cũng bao gồm một API "mềm" chỉ có trong thời gian chạy, dưới dạng các yếu tố như Ý định, quyền và các khía cạnh tương tự của ứng dụng Android không thể được thực thi tại thời điểm biên dịch ứng dụng. Phần này trình bày chi tiết các API "mềm" và hành vi hệ thống cần thiết để tương thích với Android 2.3. Việc triển khai thiết bị PHẢI đáp ứng tất cả các yêu cầu được nêu trong phần này.

3.2.1. Quyền

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

3.2.2. Tham số bản dựng

API Android bao gồm một số hằng số trên lớp android.os.Build [Tài nguyên, 6] dùng để mô tả thiết bị hiện tại. Để cung cấp các giá trị nhất quán và có ý nghĩa trên các phương thức triển khai thiết bị, bảng dưới đây bao gồm các quy định hạn chế bổ sung về định dạng của các giá trị này mà phương thức triển khai thiết bị PHẢI tuân thủ.

Tham số	Nhận xét
android.os.Build.VERSION.RELEASE	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. Trường này PHẢI có một trong các giá trị chuỗi được xác định trong [Tài nguyên, 7].
android.os.Build.VERSION.SDK	Phiên bản của hệ thống Android đang thực thi, ở định dạng mà mã ứng dụng bên thứ ba có thể truy cập. Đối với Android 2.3, trường này PHẢI có giá trị số nguyên là 9.
android.os.Build.VERSION.INCREMENTAL	Giá trị do người triển khai thiết bị chọn, chỉ định bản dựng cụ thể của hệ thống Android đang thực thi, ở định dạng mà con người có thể đọc được. KHÔNG ĐƯỢC sử dụng lại giá trị này cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Trường này thường được dùng để cho biết số bản dựng hoặc giá trị nhận dạng thay đổi của công cụ quản lý nguồn đã được dùng để tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.BOARD	Giá trị do người triển khai thiết bị chọn để xác định phần cứng nội bộ cụ thể mà thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Bạn có thể sử dụng trường này để cho biết bản sửa đổi cụ thể của bo mạch cấp nguồn cho thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.BRAND	Giá trị do người triển khai thiết bị chọn để xác định tên của công ty, tổ chức, cá nhân, v.v. đã sản xuất thiết bị, ở định dạng mà con người có thể đọc được. Bạn có thể sử dụng trường này để cho biết nhà sản xuất thiết bị gốc (OEM) và/hoặc nhà mạng đã bán thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.DEVICE	Giá trị do người triển khai thiết bị chọn để xác định cấu hình hoặc bản sửa đổi cụ thể của thân máy (đôi khi được gọi là "thiết kế công nghiệp") của thiết bị. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	Một chuỗi nhận dạng duy nhất bản dựng này. Tên này PHẢI là tên mà con người có thể đọc được một cách hợp lý. Mã này PHẢI tuân theo mẫu sau: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ví dụ: acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys Mã vân tay KHÔNG ĐƯỢC chứa ký tự khoảng trắng. Nếu các trường khác có trong mẫu ở trên có ký tự khoảng trắng, thì bạn PHẢI thay thế các trường đó trong vân tay bản dựng bằng một ký tự khác, chẳng hạn như ký tự dấu gạch dưới ("_"). Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit.
android.os.Build.HOST	Một chuỗi xác định duy nhất máy chủ lưu trữ mà bản dựng được tạo, ở định dạng mà con người có thể đọc được. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.ID	Giá trị nhận dạng do người triển khai thiết bị chọn để tham chiếu đến một bản phát hành cụ thể, ở định dạng mà con người có thể đọc được. Trường này có thể giống với android.os.Build.VERSION.INCREMENTAL, nhưng PHẢI là một giá trị đủ ý nghĩa để người dùng cuối có thể phân biệt giữa các bản dựng phần mềm. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.MODEL	Giá trị do người triển khai thiết bị chọn, chứa tên của thiết bị mà người dùng cuối biết. Tên này PHẢI giống với tên mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.PRODUCT	Giá trị do người triển khai thiết bị chọn, chứa tên phát triển hoặc tên mã của thiết bị. PHẢI là văn bản mà con người có thể đọc được, nhưng không nhất thiết phải là văn bản mà người dùng cuối xem được. Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TAGS	Danh sách các thẻ được phân tách bằng dấu phẩy do người triển khai thiết bị chọn để phân biệt thêm bản dựng. Ví dụ: "unsigned,debug". Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME	Giá trị đại diện cho dấu thời gian của thời điểm bản dựng xảy ra.
android.os.Build.TYPE	Giá trị do người triển khai thiết bị chọn, chỉ định cấu hình thời gian chạy của bản dựng. Trường này PHẢI có một trong các giá trị tương ứng với 3 cấu hình thời gian chạy Android thông thường: "user", "userdebug" hoặc "eng". Giá trị của trường này PHẢI có thể mã hoá dưới dạng ASCII 7 bit và khớp với biểu thức chính quy "^[a-zA-Z0-9.,_-]+$".
android.os.Build.USER	Tên hoặc mã nhận dạng người dùng của người dùng (hoặc người dùng tự động) đã tạo bản dựng. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").

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

Android sử dụng Ý định để tích hợp một cách lỏng lẻo giữa các ứng dụng. Phần này mô tả các yêu cầu liên quan đến mẫu Ý định mà các hoạt động triển khai thiết bị PHẢI tuân thủ. "Được tôn trọng" có nghĩa là người triển khai thiết bị PHẢI cung cấp một Hoạt động hoặc Dịch vụ Android chỉ định một bộ lọc Ý định phù hợp, đồng thời liên kết và triển khai hành vi chính xác cho từng mẫu Ý định đã chỉ định.

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

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

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

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

• Đồng hồ để bàn
• Trình duyệt
• Lịch
• Máy tính
• Danh bạ
• Email
• Thư viện
• GlobalSearch
• Trình chạy
• Âm nhạc
• Cài đặt

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

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

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

3.2.3.2. Ghi đè ý định

Vì Android là một nền tảng có thể mở rộng, nên các trình triển khai thiết bị PHẢI cho phép các ứng dụng bên thứ ba ghi đè từng mẫu Ý định được tham chiếu trong Phần 3.2.3.1. Theo mặc định, dự án nguồn mở Android ngược dòng cho phép việc này; người triển khai thiết bị KHÔNG ĐƯỢC đính kèm các đặc quyền đặc biệt vào việc sử dụng các mẫu Ý định này của ứng dụng hệ thống hoặc ngăn ứng dụng bên thứ ba liên kết và giả định quyền kiểm soát các mẫu này. Quy định cấm này bao gồm nhưng không giới hạn ở việc tắt giao diện người dùng "Công cụ chọn" cho phép người dùng chọn giữa nhiều ứng dụng đều xử lý cùng một mẫu Ý định.

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

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

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

3.2.3.4. Ý định truyền tin

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

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

Mã được quản lý chạy trong Dalvik có thể gọi vào mã gốc được cung cấp trong tệp .apk của ứng dụng dưới dạng tệp .so ELF được biên dịch cho cấu trúc phần cứng thiết bị thích hợp. Vì mã gốc phụ thuộc nhiều vào công nghệ xử lý cơ bản, nên Android xác định một số Giao diện nhị phân của ứng dụng (ABI) trong Android NDK, trong tệp docs/CPU-ARCH-ABIS.txt. Nếu việc triển khai thiết bị tương thích với một hoặc nhiều ABI đã xác định, thì việc triển khai đó PHẢI tương thích với Android NDK, như bên dưới.

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

• PHẢI hỗ trợ mã chạy trong môi trường được quản lý để gọi vào mã gốc, sử dụng ngữ nghĩa Giao diện gốc Java (JNI) chuẩn.
• PHẢI tương thích với nguồn (tức là tương thích với tiêu đề) và tương thích với tệp nhị phân (đối với ABI) với từng thư viện bắt buộc trong danh sách bên dưới
• PHẢI báo cáo chính xác Giao diện nhị phân của ứng dụng (ABI) gốc mà thiết bị hỗ trợ thông qua API android.os.Build.CPU_ABI
• PHẢI chỉ báo cáo những ABI được ghi nhận trong phiên bản mới nhất của Android NDK, trong tệp docs/CPU-ARCH-ABIS.txt
• NÊN được tạo bằng mã nguồn và tệp tiêu đề có trong dự án nguồn mở Android ngược dòng

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

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

Xin lưu ý rằng các bản phát hành Android NDK trong tương lai có thể hỗ trợ thêm các ABI. Nếu việc triển khai thiết bị không tương thích với ABI được xác định trước hiện có, thì việc triển khai đó KHÔNG ĐƯỢC báo cáo hỗ trợ cho bất kỳ ABI nào.

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

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

Nhiều nhà phát triển và ứng dụng dựa vào hành vi của lớp android.webkit.WebView [Tài nguyên, 8] cho giao diện người dùng của họ, vì vậy, việc triển khai WebView phải tương thích với các phương thức triển khai Android. Tương tự, trình duyệt web hiện đại, đầy đủ là yếu tố trung tâm trong trải nghiệm người dùng Android. Việc triển khai thiết bị PHẢI bao gồm một phiên bản android.webkit.WebView nhất quán với phần mềm Android ngược dòng và PHẢI bao gồm một trình duyệt hiện đại có khả năng hỗ trợ HTML5, như mô tả bên dưới.

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

Việc triển khai Android Open Source sử dụng công cụ kết xuất WebKit để triển khai android.webkit.WebView. Vì không thể phát triển một bộ kiểm thử toàn diện cho hệ thống hiển thị web, nên người triển khai thiết bị PHẢI sử dụng bản dựng thượng nguồn cụ thể của WebKit trong quá trình triển khai WebView. Cụ thể:

• Việc triển khai android.webkit.WebView của các hoạt động triển khai thiết bị PHẢI dựa trên bản dựng WebKit 533.1 từ cây nguồn mở Android ngược dòng cho Android 2.3. Bản dựng này bao gồm một bộ sửa lỗi bảo mật và chức năng cụ thể cho WebView. Trình triển khai thiết bị CÓ THỂ đưa các tuỳ chỉnh vào quá trình triển khai WebKit; tuy nhiên, mọi tuỳ chỉnh như vậy KHÔNG ĐƯỢC thay đổi hành vi của WebView, bao gồm cả hành vi kết xuất.
• Chuỗi tác nhân người dùng do WebView báo cáo PHẢI có định dạng sau:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • Giá trị của chuỗi $(VERSION) PHẢI giống với giá trị của android.os.Build.VERSION.RELEASE
  • Giá trị của chuỗi $(LOCALE) PHẢI tuân theo các quy ước ISO về mã quốc gia và ngôn ngữ, đồng thời PHẢI tham chiếu đến ngôn ngữ đã định cấu hình hiện tại của thiết bị
  • Giá trị của chuỗi $(MODEL) PHẢI giống với giá trị của android.os.Build.MODEL
  • Giá trị của chuỗi $(BUILD) PHẢI giống với giá trị của android.os.Build.ID

Thành phần WebView PHẢI hỗ trợ nhiều HTML5 [Tài nguyên, 9] nhất có thể. Ở mức tối thiểu, việc triển khai thiết bị PHẢI hỗ trợ từng API liên kết với HTML5 trong WebView:

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

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

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

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

Quá trình triển khai thiết bị PHẢI bao gồm một ứng dụng Trình duyệt độc lập để người dùng duyệt web thông thường. Trình duyệt độc lập CÓ THỂ dựa trên một công nghệ trình duyệt khác với WebKit. Tuy nhiên, ngay cả khi bạn sử dụng một ứng dụng Trình duyệt thay thế, thành phần android.webkit.WebView được cung cấp cho các ứng dụng bên thứ ba PHẢI dựa trên WebKit, như mô tả trong Mục 3.4.1.

Các hoạt động triển khai CÓ THỂ gửi một chuỗi tác nhân người dùng tuỳ chỉnh trong ứng dụng Trình duyệt độc lập.

Ứng dụng Trình duyệt độc lập (dù dựa trên ứng dụng Trình duyệt WebKit thượng nguồn hay ứng dụng thay thế của bên thứ ba) PHẢI hỗ trợ nhiều HTML5 nhất có thể [Tài nguyên, 9]. Ở mức tối thiểu, việc triển khai thiết bị PHẢI hỗ trợ từng API sau đây liên kết với HTML5:

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

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

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

Hành vi của từng loại API (được quản lý, mềm, gốc và web) phải nhất quán với cách triển khai ưu tiên của dự án nguồn mở Android thượng nguồn [Tài nguyên, 3]. Một số khía cạnh cụ thể về khả năng tương thích là:

• Thiết bị KHÔNG ĐƯỢC thay đổi hành vi hoặc ngữ nghĩa của một Ý định chuẩn
• Thiết bị KHÔNG ĐƯỢC thay đổi vòng đời hoặc ngữ nghĩa vòng đời của một loại thành phần hệ thống cụ thể (chẳng hạn như Dịch vụ, Hoạt động, ContentProvider, v.v.)
• Thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của quyền tiêu chuẩn

Danh sách bên trên chưa đầy đủ. Bộ kiểm thử tính tương thích (CTS) kiểm thử các phần quan trọng của nền tảng để đảm bảo khả năng tương thích về hành vi, nhưng không phải tất cả. Bên triển khai có trách nhiệm đảm bảo khả năng tương thích về hành vi với Dự án nguồn mở Android. Vì lý do này, người triển khai thiết bị NÊN sử dụng mã nguồn có sẵn thông qua Dự án nguồn mở Android (nếu có thể), thay vì triển khai lại các phần quan trọng của hệ thống.

3.6. Không gian tên API

Android tuân theo các quy ước về không gian tên gói và lớp do ngôn ngữ lập trình Java xác định. Để đảm bảo khả năng tương thích với các ứng dụng bên thứ ba, người triển khai thiết bị KHÔNG ĐƯỢC thực hiện bất kỳ sửa đổi bị cấm nào (xem bên dưới) đối với các không gian tên gói sau:

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

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

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

"Thành phần hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng dấu "@hide" như được sử dụng trong mã nguồn Android ngược dòng. Nói cách khác, người triển khai thiết bị KHÔNG ĐƯỢC hiển thị API mới hoặc thay đổi API hiện có trong các không gian tên nêu trên. Bên triển khai thiết bị CÓ THỂ thực hiện các sửa đổi chỉ dành cho nội bộ, nhưng KHÔNG ĐƯỢC quảng cáo hoặc hiển thị các sửa đổi đó cho nhà phát triển.

Người triển khai thiết bị CÓ THỂ thêm API tuỳ chỉnh, nhưng mọi API như vậy KHÔNG ĐƯỢC nằm trong một không gian tên thuộc sở hữu hoặc tham chiếu đến một tổ chức khác. Ví dụ: người triển khai thiết bị KHÔNG ĐƯỢC thêm API vào com.google.* hoặc không gian tên tương tự; chỉ Google mới có thể làm như vậy. Tương tự, Google KHÔNG ĐƯỢC thêm API vào không gian tên của các công ty khác. Ngoài ra, nếu quá trình triển khai thiết bị bao gồm các API tuỳ chỉnh bên ngoài không gian tên Android tiêu chuẩn, thì các API đó PHẢI được đóng gói trong thư viện dùng chung Android để chỉ những ứng dụng sử dụng rõ ràng các API đó (thông qua cơ chế <uses-library>) mới bị ảnh hưởng bởi mức sử dụng bộ nhớ tăng lên của các API đó.

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

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

3.7. Khả năng tương thích với máy ảo

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

Việc triển khai thiết bị có màn hình được phân loại là mật độ trung bình hoặc thấp PHẢI định cấu hình Dalvik để phân bổ ít nhất 16 MB bộ nhớ cho mỗi ứng dụng. Việc triển khai thiết bị có màn hình được phân loại là mật độ điểm ảnh cao hoặc mật độ điểm ảnh cực cao PHẢI định cấu hình Dalvik để phân bổ ít nhất 24 MB bộ nhớ cho mỗi ứng dụng. Xin lưu ý rằng việc triển khai thiết bị CÓ THỂ phân bổ nhiều bộ nhớ hơn những con số này.

3.8. Khả năng tương thích của giao diện người dùng

Nền tảng Android bao gồm một số API dành cho nhà phát triển cho phép nhà phát triển gắn vào giao diện người dùng của hệ thống. Việc triển khai thiết bị PHẢI kết hợp các API giao diện người dùng chuẩn này vào giao diện người dùng tuỳ chỉnh mà họ phát triển, như giải thích bên dưới.

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ị "AppWidget" cho người dùng cuối [Tài nguyên, 16]. Bản phát hành tham khảo nguồn mở Android bao gồm một ứng dụng Trình chạy có các thành phần 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.

Người 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 thành phần giao diện người dùng để thêm, định cấu hình, xem và xoá AppWidgets ngay trong Trình chạy. 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, thì người triển khai thiết bị PHẢI cung cấp một ứng dụng riêng 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.

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, 17]. Người triển khai thiết bị PHẢI hỗ trợ từng lớp thông báo được xác định; cụ thể: âm thanh, rung, ánh sáng và thanh trạng thái.

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, 18] hoặc trong hướng dẫn về kiểu biểu tượng Thanh trạng thái [Tài nguyên, 19]. Nhà triển khai thiết bị CÓ THỂ cung cấp trải nghiệm người dùng thay thế cho thông báo so với trải nghiệm do cách triển khai tham chiếu Android Open Source cung cấp; tuy nhiên, các hệ thống thông báo thay thế đó PHẢI hỗ trợ các tài nguyên thông báo hiện có, như nêu trên.

3.8.3. Tìm kiếm

Android bao gồm các API [Tài nguyên, 20] cho phép nhà phát triển tích hợp tính năng tìm kiếm vào ứng dụng và hiển thị dữ liệu của ứng dụng vào tính năng tìm kiếm hệ thống toàn cầu. Nói chung, chức năng này bao gồm một giao diện người dùng duy nhất trên toàn hệ thống, cho phép người dùng nhập truy vấn, hiển thị nội dung đề xuất khi người dùng nhập và hiển thị kết quả. API Android cho phép nhà phát triển sử dụng lại giao diện này để cung cấp tính năng tìm kiếm trong ứng dụng của riêng họ, đồng thời cho phép nhà phát triển cung cấp kết quả cho giao diện người dùng tìm kiếm chung trên toàn cầu.

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

Việc triển khai thiết bị CÓ THỂ cung cấp giao diện người dùng tìm kiếm thay thế, nhưng PHẢI bao gồm một nút tìm kiếm chuyên dụng cứng hoặc mềm, có thể được sử dụng bất cứ lúc nào trong bất kỳ ứng dụng nào để gọi khung tìm kiếm, với hành vi được cung cấp trong tài liệu API.

3.8.4. Thông báo ngắn

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

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

Android xác định một loại thành phần và API và vòng đời tương ứng cho phép các ứng dụng hiển thị một hoặc nhiều "Hình nền động" cho người dùng cuối [Tài nguyên, 22]. Hình nền động là ảnh động, mẫu hoặc hình ảnh tương tự có khả năng nhập hạn chế hiển thị dưới dạng hình nền, phía sau các ứng dụng khác.

Phần cứng được coi là có khả năng chạy hình nền động một cách đáng tin cậy nếu có thể chạy tất cả hình nền động, không có giới hạn về chức năng, ở tốc độ khung hình hợp lý mà không ảnh hưởng bất lợi đến các ứng dụng khác. Nếu các giới hạn về phần cứng khiến hình nền và/hoặc ứng dụng gặp sự cố, hoạt động không đúng cách, tiêu thụ quá nhiều CPU hoặc pin hoặc chạy ở tốc độ khung hình thấp không chấp nhận được, thì phần cứng đó được coi là không thể chạy hình nền động. Ví dụ: một số hình nền động có thể sử dụng ngữ cảnh Open GL 1.0 hoặc 2.0 để hiển thị nội dung của chúng. Hình nền động sẽ không chạy ổn định trên phần cứng không hỗ trợ nhiều ngữ cảnh OpenGL vì việc sử dụng hình nền động của ngữ cảnh OpenGL có thể xung đột với các ứng dụng khác cũng sử dụng ngữ cảnh OpenGL.

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

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

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

Việc triển khai thiết bị KHÔNG ĐƯỢC mở rộng định dạng .apk [Tài nguyên, 24], Tệp kê khai Android [Tài nguyên, 25] hoặc mã byte Dalvik [Tài nguyên, 15] theo cách ngăn các tệp đó cài đặt và chạy chính xác trên các thiết bị tương thích khác. Trình triển khai thiết bị NÊN sử dụng phương thức triển khai ngược dòng tham chiếu của Dalvik và hệ thống quản lý gói của phương thức triển khai tham chiếu.

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

Việc triển khai thiết bị PHẢI triển khai đầy đủ tất cả API đa phương tiện. Việc triển khai thiết bị PHẢI hỗ trợ tất cả bộ mã hoá và giải mã nội dung đa phương tiện được mô tả bên dưới và PHẢI đáp ứng các nguyên tắc xử lý âm thanh được mô tả bên dưới. Việc triển khai thiết bị PHẢI bao gồm ít nhất một dạng đầu ra âm thanh, chẳng hạn như loa, giắc cắm tai nghe, kết nối loa ngoài, v.v.

5.1. Bộ mã hoá và giải mã nội dung nghe nhìn

Việc triển khai thiết bị PHẢI hỗ trợ bộ mã hoá và giải mã nội dung đa phương tiện như được nêu chi tiết trong các phần sau. Tất cả bộ mã hoá và giải mã này được cung cấp dưới dạng các phương thức triển khai phần mềm trong phương thức triển khai Android ưu tiên từ Dự án nguồn mở Android.

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

Các bảng dưới đây không liệt kê các yêu cầu cụ thể về tốc độ bit đối với hầu hết bộ mã hoá và giải mã video. Lý do là trong thực tế, 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 có liên quan chỉ định. Thay vào đó, việc triển khai thiết bị PHẢI hỗ trợ tốc độ bit thực tế cao nhất trên phần cứng, lên đến giới hạn do thông số kỹ thuật xác định.

5.1.1. Bộ giải mã nội dung nghe nhìn

Quá trình triển khai thiết bị PHẢI bao gồm việc triển khai bộ giải mã cho từng bộ mã hoá và giải mã cũng như định dạng được mô tả trong bảng dưới đây. Xin lưu ý rằng trình giải mã cho từng loại nội dung đa phương tiện này do Dự án nguồn mở Android cấp trên cung cấp.

Âm thanh
	Tên	Chi tiết	Định dạng tệp/vùng chứa
	AAC LC/LTP	Nội dung đơn âm/nổi ở bất kỳ tổ hợp tốc độ bit chuẩn nào lên đến 160 kbps và tốc độ lấy mẫu từ 8 đến 48 kHz	3GPP (.3gp) và MPEG-4 (.mp4, .m4a). Không hỗ trợ AAC thô (.aac)
	HE-AACv1 (AAC+)
	HE-AACv2 (AAC+ nâng cao)
	AMR-NB	4,75 đến 12,2 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)
	AMR-WB	9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 16 kHz	3GPP (.3gp)
	MP3	Âm thanh đơn kênh/âm thanh nổi, tốc độ bit không đổi 8-320 Kb/giây (CBR) hoặc tốc độ bit thay đổi (VBR)	MP3 (.mp3)
	MIDI	MIDI Loại 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF dành cho thiết bị di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody	Loại 0 và 1 (.mid, .xmf, .mxmf). Ngoài ra còn có RTTTL/RTX (.rtttl, .rtx), OTA (.ota) và iMelody (.imy)
	Ogg Vorbis		Ogg (.ogg)
	Trình quản lý kết nối đối tác	PCM tuyến tính 8 và 16 bit (tốc độ lên đến giới hạn của phần cứng)	WAVE (.wav)
Hình ảnh
	JPEG	cơ sở+tiến bộ
	GIF
	PNG
	BMP
Video
	H.263		Tệp 3GPP (.3gp)
	H.264		Tệp 3GPP (.3gp) và MPEG-4 (.mp4)
	Cấu hình đơn giản MPEG4		Tệp 3GPP (.3gp)

5.1.2. Bộ mã hoá nội dung nghe nhìn

Việc triển khai thiết bị PHẢI bao gồm bộ mã hoá cho nhiều định dạng nội dung đa phương tiện nhất có thể được liệt kê trong Mục 5.1.1. Tuy nhiên, một số bộ mã hoá không phù hợp với các thiết bị thiếu một số phần cứng không bắt buộc; ví dụ: bộ mã hoá cho video H.263 không phù hợp nếu thiết bị không có máy ảnh. Do đó, việc triển khai thiết bị PHẢI triển khai bộ mã hoá nội dung nghe nhìn theo các điều kiện được mô tả trong bảng dưới đây.

Hãy xem Phần 7 để biết thông tin chi tiết về các điều kiện mà việc triển khai thiết bị có thể bỏ qua phần cứng.

Âm thanh
	Tên	Chi tiết	Định dạng tệp/vùng chứa	Điều kiện
	AMR-NB	4,75 đến 12,2 kbps lấy mẫu ở 8 kHz	3GPP (.3gp)	Các hoạt động triển khai thiết bị bao gồm phần cứng micrô và xác định android.hardware.microphone PHẢI bao gồm bộ mã hoá cho các định dạng âm thanh này.
	AMR-WB	9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 16 kHz	3GPP (.3gp)
	AAC LC/LTP	Nội dung đơn âm/nổi ở bất kỳ tổ hợp tốc độ bit chuẩn nào lên đến 160 kbps và tốc độ lấy mẫu từ 8 đến 48 kHz	3GPP (.3gp) và MPEG-4 (.mp4, .m4a).
Hình ảnh	JPEG	cơ sở+tiến bộ		Tất cả hoạt động triển khai thiết bị PHẢI bao gồm bộ mã hoá cho các định dạng hình ảnh này, vì Android 2.3 bao gồm các API mà ứng dụng có thể sử dụng để tạo tệp theo phương thức lập trình của các loại này.
	PNG
Video	H.263		Tệp 3GPP (.3gp)	Việc triển khai thiết bị bao gồm phần cứng máy ảnh và xác định android.hardware.camera hoặc android.hardware.camera.front PHẢI bao gồm bộ mã hoá cho các định dạng video này.

Ngoài các bộ mã hoá được liệt kê ở trên, quá trình triển khai thiết bị PHẢI bao gồm bộ mã hoá H.264. Xin lưu ý rằ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 yêu cầu này thành "PHẢI". Tức là, bạn không bắt buộc phải sử dụng tính năng mã hoá H.264 trong Android 2.3 nhưng bắt buộc phải sử dụng tính năng này 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 2.3 nên đáp ứng yêu cầu này trong Android 2.3, nếu không, chúng sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

5.2. Ghi âm

Khi một ứng dụng đã sử dụng API android.media.AudioRecord để bắt đầu ghi luồng âm thanh, thì việc triển khai thiết bị PHẢI lấy mẫu và ghi âm thanh bằng từng hành vi sau:

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

Lưu ý: mặc dù các yêu cầu nêu trên được nêu là "NÊN" đối với Android 2.3, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai dự kiến sẽ thay đổi các yêu cầu này thành "PHẢI". Tức là các yêu cầu này không bắt buộc trong Android 2.3 nhưng sẽ bắt buộc trong một phiên bản sau này. Các thiết bị hiện có và mới chạy Android 2.3 nên đáp ứng các yêu cầu này trong Android 2.3, nếu không, chúng sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

5.3. Độ 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 thao tác phát hoặc ghi âm thanh và thời điểm triển khai thiết bị thực sự bắt đầu thao tác đó. Nhiều lớp ứng dụng dựa vào độ trễ ngắn để đạt được hiệu ứng theo thời gian thực, chẳng hạn như hiệu ứng âm thanh hoặc giao tiếp VOIP. Việc triển khai thiết bị bao gồm phần cứng micrô và khai báo android.hardware.microphone PHẢI đáp ứng tất cả yêu cầu về độ trễ âm thanh được nêu trong phần này. Hãy xem Mục 7 để biết thông tin chi tiết về các điều kiện mà việc triển khai thiết bị có thể bỏ qua phần cứng micrô.

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

• "Độ trễ đầu ra nguội" được xác định là khoảng thời gian giữa thời điểm một ứng dụng yêu cầu phát âm thanh và thời điểm âm thanh bắt đầu phát, khi hệ thống âm thanh ở trạng thái rảnh và tắt nguồn trước khi có yêu cầu
• "độ trễ đầu ra ấm" được xác định là khoảng thời gian giữa thời điểm một ứng dụng yêu cầu phát âm thanh và thời điểm âm thanh bắt đầu phát, khi hệ thống âm thanh đã được sử dụng gần đây nhưng hiện đang ở trạng thái rảnh (tức là im lặng)
• "độ trễ đầu ra liên tục" được xác định là khoảng thời gian giữa thời điểm một ứng dụng phát hành một mẫu để phát và thời điểm loa phát âm thanh tương ứng, trong khi thiết bị đang phát âm thanh
• "Độ trễ đầu vào nguội" được xác định là khoảng thời gian giữa thời điểm một ứng dụng yêu cầu ghi âm và thời điểm mẫu đầu tiên được phân phối đến ứng dụng thông qua lệnh gọi lại, khi hệ thống âm thanh và micrô ở trạng thái rảnh và tắt nguồn trước khi 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 phân phối đến ứng dụng ghi âm thông qua lệnh gọi lại, trong khi thiết bị đang ở chế độ ghi âm

Khi sử dụng các định nghĩa trên, việc triển khai thiết bị PHẢI hiển thị từng thuộc tính sau:

• độ trễ đầu ra nguội từ 100 mili giây trở xuống
• độ trễ đầu ra ấm từ 10 mili giây trở xuống
• độ trễ đầu ra liên tục là 45 mili giây trở xuống
• độ trễ đầu vào nguội từ 100 mili giây trở xuống
• độ trễ đầu vào liên tục từ 50 mili giây trở xuống

Lưu ý: mặc dù các yêu cầu nêu trên được nêu là "NÊN" đối với Android 2.3, nhưng Định nghĩa về khả năng tương thích cho phiên bản trong tương lai dự kiến sẽ thay đổi các yêu cầu này thành "PHẢI". Tức là các yêu cầu này không bắt buộc trong Android 2.3 nhưng sẽ bắt buộc trong một phiên bản sau này. Các thiết bị hiện có và mới chạy Android 2.3 nên đáp ứng các yêu cầu này trong Android 2.3, nếu không, chúng sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

Nếu việc 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 tính năng hỗ trợ âm thanh có độ trễ thấp bằng cách báo cáo tính năng "android.hardware.audio.low-latency" thông qua lớp android.content.pm.PackageManager. [Tài nguyên, 27] Ngược lại, nếu việc triển khai thiết bị không đáp ứng các yêu cầu này, thì thiết bị KHÔNG ĐƯỢC báo cáo hỗ trợ âm thanh có độ trễ thấp.

6. Khả năng tương thích của công cụ dành cho nhà phát triển

Việc triển khai thiết bị PHẢI hỗ trợ Bộ công cụ dành cho nhà phát triển Android được cung cấp trong SDK Android. Cụ thể, 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, 23]
  Việc triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được ghi lại trong SDK Android. Theo mặc định, trình nền adb phía thiết bị PHẢI ở trạng thái không hoạt động, nhưng PHẢI có một cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
• Dịch vụ theo dõi gỡ lỗi Dalvik (còn gọi là ddms) [Tài nguyên, 23]
  Việc triển khai thiết bị PHẢI hỗ trợ tất cả tính năng ddms như được ghi nhận trong SDK Android. Vì ddms sử dụng adb, nên tính năng hỗ trợ cho ddms PHẢI ở trạng thái không hoạt động theo mặc định, nhưng PHẢI được hỗ trợ bất cứ khi nào người dùng đã kích hoạt Cầu gỡ lỗi Android, như trên.
• Monkey [Tài nguyên, 26]
  Việc triển khai thiết bị PHẢI bao gồm khung Monkey và cung cấp khung này cho các ứng dụng sử dụng.

Hầu hết các hệ thống dựa trên Linux và hệ thống Apple Macintosh đều nhận ra các thiết bị Android bằng các công cụ SDK Android tiêu chuẩn mà không cần hỗ trợ bổ sung; tuy nhiên, các hệ thống Microsoft Windows thường yêu cầu trình điều khiển cho các thiết bị Android mới. (Ví dụ: mã nhà cung cấp mới và đôi khi mã thiết bị mới yêu cầu trình điều khiển USB tuỳ chỉnh cho hệ thống Windows.) Nếu công cụ adb không nhận dạng được cách triển khai thiết bị như được cung cấp trong SDK Android tiêu chuẩn, thì người triển khai thiết bị PHẢI cung cấp trình điều khiển Windows cho phép nhà phát triển kết nối với thiết bị bằng giao thức adb. BẠN PHẢI cung cấp các trình điều khiển này cho Windows XP, Windows Vista 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

Android nhằm mục đích cho phép những người triển khai thiết bị tạo ra các kiểu dáng và cấu hình đổi mới. Đồng thời, nhà phát triển Android viết các ứng dụng sáng tạo dựa trên nhiều phần cứng và tính năng có sẵn thông qua API Android. Các yêu cầu trong phần này tạo ra sự cân bằng giữa các tính năng cải tiến dành cho người triển khai thiết bị và nhu cầu của nhà phát triển để đảm bảo ứng dụng của họ chỉ được cung cấp cho các thiết bị có thể chạy ứng dụng đúng cách.

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

• PHẢI vẫn có định nghĩa lớp đầy đủ (theo tài liệu của SDK) cho các API của thành phần
• hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo một cách hợp lý
• Các phương thức API PHẢI trả về giá trị rỗng nếu tài liệu SDK cho phép
• Các phương thức API PHẢI trả về các phương thức triển khai không hoạt động của các lớp mà tài liệu SDK không cho phép giá trị rỗng
• Phương thức API KHÔNG ĐƯỢC gửi ngoại lệ không được tài liệu SDK ghi lại

Một ví dụ điển hình về trường hợp áp dụng các yêu cầu này là API điện thoại: ngay cả trên các thiết bị không phải điện thoại, các API này phải được triển khai dưới dạng không hoạt động hợp lý.

Việc triển khai thiết bị PHẢI báo cáo chính xác thông tin cấu hình phần cứng thông qua các phương thức getSystemAvailableFeatures() và hasSystemFeature(String) trên lớp android.content.pm.PackageManager. [Tài nguyên, 27]

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

Android 2.3 bao gồm các cơ sở tự động điều chỉnh tài sản ứng dụng và bố cục giao diện người dùng cho phù hợp với thiết bị, để đảm bảo rằng các ứng dụng bên thứ ba chạy tốt trên nhiều cấu hình phần cứng [Tài nguyên, 28]. Thiết bị PHẢI triển khai đúng cách các API và hành vi này, như được nêu chi tiết trong phần này.

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

Việc triển khai thiết bị CÓ THỂ sử dụng màn hình có kích thước pixel bất kỳ, miễn là màn hình đó đáp ứng các yêu cầu sau:

• màn hình PHẢI có kích thước đường chéo vật lý tối thiểu là 2,5 inch
• mật độ PHẢI có ít nhất 100 dpi
• tỷ lệ khung hình PHẢI nằm trong khoảng từ 1,333 (4:3) đến 1,779 (16:9)
• công nghệ hiển thị được sử dụng bao gồm các pixel hình vuông

Các thiết bị triển khai có màn hình đáp ứng các yêu cầu ở trên được coi là tương thích và bạn không cần làm gì thêm. Việc triển khai khung Android sẽ tự động tính toán các đặc điểm hiển thị như nhóm kích thước màn hình và nhóm mật độ. Trong hầu hết các trường hợp, quyết định của khung là chính xác. Nếu sử dụng các phép tính khung mặc định, bạn không cần làm gì thêm. Những người triển khai thiết bị muốn thay đổi chế độ mặc định hoặc sử dụng màn hình không đáp ứng các yêu cầu ở trên PHẢI liên hệ với Nhóm tương thích Android để được hướng dẫn, như được nêu trong Mục 12.

Các đơn vị được sử dụng theo yêu cầu ở trên được xác định như sau:

• "Kích thước đường chéo thực tế" là khoảng cách tính bằng inch giữa hai góc đối diện của phần được chiếu sáng trên màn hình.
• "dpi" (nghĩa là "điểm trên mỗi inch") là số pixel được bao phủ bởi một khoảng không gian tuyến tính theo chiều ngang hoặc chiều dọc là 1". Khi liệt kê các giá trị dpi, cả dpi theo chiều ngang và chiều dọc đều phải nằm trong phạm vi.
• "Tỷ lệ khung hình" là tỷ lệ giữa kích thước dài hơn của màn hình với kích thước ngắn hơn. Ví dụ: màn hình 480x854 pixel sẽ là 854 / 480 = 1,779 hoặc gần bằng "16:9".

Việc triển khai thiết bị PHẢI chỉ sử dụng màn hình có một cấu hình tĩnh. Tức là việc triển khai thiết bị KHÔNG ĐƯỢC bật nhiều cấu hình màn hình. Ví dụ: vì một chiếc TV thông thường hỗ trợ nhiều độ phân giải như 1080p, 720p, v.v. nên cấu hình này không tương thích với Android 2.3. (Tuy nhiên, chúng tôi đang điều tra và lên kế hoạch hỗ trợ các cấu hình như vậy cho phiên bản Android trong tương lai.)

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

Quá trình triển khai thiết bị PHẢI báo cáo giá trị chính xác cho tất cả các chỉ số hiển thị được xác định trong android.util.DisplayMetrics [Tài nguyên, 29].

7.1.3. Hỗ trợ màn hình đã khai báo

Các ứng dụng có thể cho biết kích thước màn hình mà ứng dụng hỗ trợ thông qua thuộc tính <supports-screens> trong tệp AndroidManifest.xml. Việc triển khai thiết bị PHẢI tuân thủ chính xác tính năng hỗ trợ đã nêu của ứng dụng cho màn hình nhỏ, trung bình và lớn, như mô tả trong tài liệu về SDK Android.

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

Các thiết bị tương thích PHẢI hỗ trợ hướng động của ứng dụng theo hướng màn hình dọc hoặc ngang. Tức là thiết bị phải tuân thủ yêu cầu của ứng dụng về hướng màn hình cụ thể. Việc triển khai thiết bị CÓ THỂ chọn hướng dọc hoặc ngang làm mặc định. Những thiết bị không thể xoay theo cách thủ công CÓ THỂ đáp ứng yêu cầu này bằng cách "đóng hòm thư" các ứng dụng yêu cầu chế độ dọc, chỉ sử dụng một phần màn hình hiện có.

Thiết bị PHẢI báo cáo giá trị chính xác cho hướng hiện tại của thiết bị, bất cứ khi nào được truy vấn thông qua android.content.res.Configuration.orientation, android.view.Display.getOrientation() hoặc các API khác.

7.1.5. Tăng tốc đồ hoạ 3D

Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 1.0, như API Android 2.3 yêu cầu. Đối với các thiết bị thiếu phần cứng tăng tốc 3D, Dự án nguồn mở Android cấp trên sẽ cung cấp phương thức triển khai phần mềm OpenGL ES 1.0. Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 2.0.

Các hoạt động triển khai CÓ THỂ bỏ qua tính năng hỗ trợ Open GL ES 2.0; tuy nhiên, nếu tính năng hỗ trợ bị bỏ qua, thì hoạt động triển khai thiết bị KHÔNG ĐƯỢC báo cáo là hỗ trợ OpenGL ES 2.0. Cụ thể, nếu việc triển khai thiết bị thiếu tính năng hỗ trợ OpenGL ES 2.0:

• các API được quản lý (chẳng hạn như thông qua phương thức GLES10.getString()) KHÔNG ĐƯỢC báo cáo hỗ trợ OpenGL ES 2.0
• API OpenGL C/C++ gốc (tức là các API có sẵn cho ứng dụng thông qua libGLES_v1CM.so, libGLES_v2.so hoặc libEGL.so) KHÔNG ĐƯỢC báo cáo hỗ trợ cho OpenGL ES 2.0.

Ngược lại, nếu việc triển khai thiết bị có hỗ trợ OpenGL ES 2.0, thì thiết bị đó PHẢI báo cáo chính xác khả năng hỗ trợ đó thông qua các tuyến đường vừa nêu.

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

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

Android 2.3 hỗ trợ một số phương thức nhập dữ liệu của người dùng. Việc triển khai thiết bị PHẢI hỗ trợ các thiết bị nhập liệu của người dùng như được cung cấp trong phần này.

7.2.1. Bàn phím

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

• PHẢI hỗ trợ Khung quản lý đầu vào (cho phép nhà phát triển bên thứ ba tạo Công cụ quản lý đầu vào – tức là bàn phím mềm) như được nêu chi tiết tại developer.android.com
• PHẢI cung cấp ít nhất một phương thức triển khai bàn phím mềm (bất kể có bàn phím cứng hay không)
• CÓ THỂ bao gồm các phương thức triển khai bàn phím mềm khác
• CÓ THỂ bao gồm bàn phím phần cứng
• KHÔNG ĐƯỢC đưa bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard [Tài nguyên, 30] (tức là QWERTY hoặc 12 phím)

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

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

• CÓ THỂ bỏ qua một tuỳ chọn điều hướng không chạm (tức là có thể bỏ qua bi xoay, d-pad hoặc bánh xe)
• PHẢI báo cáo đúng giá trị cho android.content.res.Configuration.navigation [Tài nguyên, 30]
• PHẢI cung cấp một cơ chế giao diện người dùng thay thế hợp lý để chọn và chỉnh sửa văn bản, tương thích với Công cụ quản lý đầu vào. 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 thao tác đ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à thiết yếu đối với mô hình điều hướng của Android. Việc triển khai thiết bị PHẢI cung cấp các chức năng này cho người dùng mọi lúc, bất kể trạng thái ứng dụng. Bạn NÊN triển khai các hàm này thông qua các nút chuyên dụng. Bạn CÓ THỂ triển khai các nút này bằng phần mềm, cử chỉ, bảng cảm ứng, v.v., nhưng nếu có, các nút này PHẢI luôn truy cập được và không che khuất hoặc can thiệp vào khu vực hiển thị ứng dụng hiện có.

Bên triển khai thiết bị cũng NÊN cung cấp một khoá tìm kiếm chuyên dụng. Trình triển khai thiết bị cũng CÓ THỂ cung cấp khoá gửi và kết thúc cho cuộc gọi điện thoại.

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

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

• PHẢI có màn hình cảm ứng
• CÓ THỂ có màn hình cảm ứng điện dung hoặc điện trở
• PHẢI báo cáo giá trị của android.content.res.Configuration [Tài nguyên, 30] phản ánh tương ứng với loại màn hình cảm ứng cụ thể trên thiết bị
• NÊN hỗ trợ các con trỏ được theo dõi hoàn toàn độc lập, nếu màn hình cảm ứng hỗ trợ nhiều con trỏ

7.3. Cảm biến

Android 2.3 bao gồm các API để truy cập vào nhiều loại cảm biến. Việc triển khai thiết bị thường CÓ THỂ bỏ qua các cảm biến này, như được cung cấp trong các tiểu mục sau. Nếu một thiết bị có một loại cảm biến cụ thể có API tương ứng cho nhà phát triển bên thứ ba, thì việc triển khai thiết bị PHẢI triển khai API đó như mô tả trong tài liệu SDK Android. Ví dụ: triển khai thiết bị:

• PHẢI báo cáo chính xác sự hiện diện hoặc vắng mặt của cảm biến theo lớp android.content.pm.PackageManager. [Tài nguyên, 27]
• PHẢI trả về danh sách chính xác các cảm biến được hỗ trợ thông qua SensorManager.getSensorList() và các phương thức tương tự
• PHẢI hoạt động hợp lý đối với tất cả các API cảm biến khác (ví dụ: bằng cách trả về true hoặc false khi thích hợp khi các ứng dụng cố gắng đăng ký trình nghe, không gọi trình nghe cảm biến khi không có cảm biến tương ứng; v.v.)

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

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

API Android 2.3 giới thiệu khái niệm cảm biến "trực tuyến", là cảm biến trả về dữ liệu liên tục thay vì chỉ khi dữ liệu thay đổi. Việc triển khai thiết bị PHẢI liên tục cung cấp các mẫu dữ liệu định kỳ cho mọi API mà tài liệu SDK Android 2.3 chỉ định là cảm biến truyền trực tuyến.

7.3.1. Gia tốc kế

Việc triển khai thiết bị PHẢI bao gồm gia tốc kế 3 trục. Nếu quá trình triển khai thiết bị có bao gồm gia tốc kế 3 trục, thì thiết bị đó:

• PHẢI có khả năng phân phối sự kiện ở tần số 50 Hz trở lên
• PHẢI tuân thủ hệ toạ độ cảm biến Android như được nêu chi tiết trong API Android (xem [Tài nguyên, 31])
• PHẢI có khả năng đo lường từ trạng thái rơi tự do lên đến gấp đôi trọng lực (2g) trở lên trên mọi vectơ ba chiều
• PHẢI có độ chính xác 8 bit trở lên
• PHẢI có độ lệch chuẩn không lớn hơn 0,05 m/s^2

7.3.2. Từ kế

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

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

7.3.3. GPS

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

7.3.4. Con quay hồi chuyển

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

• PHẢI có khả năng đo lường các thay đổi về hướng lên đến 5,5*Pi radian/giây (tức là khoảng 1.000 độ/giây)
• PHẢI có khả năng phân phối sự kiện ở tốc độ 100 Hz trở lên
• PHẢI có độ chính xác 8 bit trở lên

7.3.5. Khí áp kế

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

• PHẢI có thể phân phối sự kiện ở tốc độ 5 Hz trở lên
• PHẢI có độ chính xác đầy đủ để có thể ước tính độ cao

7.3.7. Nhiệt kế

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

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

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

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

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

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

Khả năng kết nối mạng và truy cập Internet là những tính năng quan trọng của Android. Trong khi đó, tính năng tương tác giữa các thiết bị sẽ mang lại giá trị đáng kể cho các thiết bị và ứng dụng Android. Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu về khả năng kết nối dữ liệu trong phần này.

7.4.1. Điện thoại

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

Android 2.3 CÓ THỂ được sử dụng trên các thiết bị không có phần cứng điện thoại. Tức là Android 2.3 tương thích với các thiết bị không phải điện thoại. Tuy nhiên, nếu việc triển khai thiết bị bao gồm cả điện thoại GSM hoặc CDMA, thì thiết bị đó PHẢI triển khai hỗ trợ đầy đủ cho API cho công nghệ đó. Các hoạt động triển khai thiết bị không bao gồm phần cứng điện thoại PHẢI triển khai đầy đủ các API dưới dạng không hoạt động.

7.4.2. IEEE 802.11 (Wi-Fi)

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

7.4.3. Bluetooth

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

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 Android. Tuy nhiên, vì Bluetooth là một giao thức giao tiếp giữa các thiết bị, nên bạ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 đó, việc triển khai thiết bị cũng PHẢI vượt qua quy trình kiểm thử Bluetooth do con người thực hiện được mô tả trong Phụ lục A.

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

Việc triển khai thiết bị PHẢI bao gồm bộ thu phát và phần cứng liên quan cho tính năng Giao tiếp phạm vi gần (NFC). Nếu quá trình triển khai thiết bị có bao gồm phần cứng NFC, thì thiết bị đó:

• PHẢI báo cáo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature(). [Tài nguyên, 27]
• PHẢI có khả năng đọc và ghi thông báo NDEF thông qua các tiêu chuẩn NFC sau:
  • PHẢI có khả năng hoạt động như một trình đọc/ghi của NFC Forum (theo định nghĩa của thông số kỹ thuật NFC Forum NFCForum-TS-DigitalProtocol-1.0) thông qua các tiêu chuẩn NFC sau:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • NfcV (ISO 15693)
    • IsoDep (ISO 14443-4)
    • Loại thẻ NFC Forum 1, 2, 3, 4 (do NFC Forum xác định)
  • PHẢI có khả năng truyền và nhận dữ liệu qua các giao thức và tiêu chuẩn ngang hàng sau:
    • ISO 18092
    • LLCP 1.0 (do NFC Forum xác định)
    • SDP 1.0 (do NFC Forum xác định)
    • Giao thức đẩy NDEF [Tài nguyên, 33]
  • PHẢI quét tất cả công nghệ được hỗ trợ khi ở chế độ khám phá NFC.
  • PHẢI ở chế độ khám phá NFC khi thiết bị ở trạng thái thức và màn hình đang hoạt động.

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

  Ngoài ra, việc triển khai thiết bị PHẢI hỗ trợ các công nghệ MIFARE sau đây được triển khai rộng rãi.

  • MIFARE Classic (NXP MF1S503x [Tài nguyên, 34], MF1S703x [Tài nguyên, 35])
  • MIFARE Ultralight (NXP MF0ICU1 [Tài nguyên, 36], MF0ICU2 [Tài nguyên, 37])
  • NDEF trên MIFARE Classic (NXP AN130511 [Tài nguyên, 38], AN130411 [Tài nguyên, 39])

  Xin lưu ý rằng Android 2.3.3 bao gồm các API cho các loại MIFARE này. Nếu quá trình triển khai thiết bị hỗ trợ MIFARE, thì thiết bị đó:

  • PHẢI triển khai các API Android tương ứng theo tài liệu của SDK Android
  • PHẢI báo cáo tính năng com.nxp.mifare từ phương thức android.content.pm.PackageManager.hasSystemFeature(). [Tài nguyên, 27] Xin lưu ý rằng đây không phải là tính năng Android tiêu chuẩn và do đó không xuất hiện dưới dạng hằng số trên lớp PackageManager.
  • KHÔNG ĐƯỢC triển khai các API Android tương ứng cũng như báo cáo tính năng com.nxp.mifare, trừ phi tính năng này cũng triển khai tính năng hỗ trợ NFC chung như mô tả trong phần này

  Nếu quá trình triển khai thiết bị không bao gồm phần cứng NFC, thì thiết bị KHÔNG ĐƯỢC khai báo tính năng android.hardware.nfc từ phương thức android.content.pm.PackageManager.hasSystemFeature() [Tài nguyên, 27] và PHẢI triển khai API NFC Android 2.3 dưới dạng không hoạt động.

  Vì các lớp android.nfc.NdefMessage và android.nfc.NdefRecord đại diện cho một định dạng trình bày dữ liệu độc lập với giao thức, nên việc triển khai thiết bị PHẢI triển khai các API này ngay cả khi các API đó không hỗ trợ NFC hoặc khai báo tính năng android.hardware.nfc.

  7.4.5. Khả năng mạng tối thiểu

  Việc triển khai thiết bị PHẢI hỗ trợ một hoặc nhiều hình thức kết nối mạng dữ liệu. Cụ thể, việc triển khai thiết bị PHẢI hỗ trợ ít nhất một tiêu chuẩn dữ liệu có tốc độ 200Kbit/giây trở lên. Ví dụ về các công nghệ đáp ứng yêu cầu này bao gồm EDGE, HSPA, EV-DO, 802.11g, Ethernet, v.v.

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

  Thiết bị CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu.

  7.5. Camera

  Việc triển khai thiết bị PHẢI bao gồm máy ảnh mặt sau và CÓ THỂ bao gồm máy ảnh mặt trước. Máy ảnh mặt sau là máy ảnh nằm ở cạnh của thiết bị đối diện với màn hình; tức là máy ảnh này chụp hình các cảnh ở phía xa của thiết bị, giống như máy ảnh truyền thống. Máy ảnh mặt trước là máy ảnh nằm ở cùng một bên của thiết bị với màn hình; tức là máy ảnh thường dùng để chụp hình người dùng, chẳng hạn như cho hội nghị truyền hình và các ứng dụng tương tự.

  7.5.1. Máy ảnh mặt sau

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

  • PHẢI có độ phân giải tối thiểu là 2 megapixel
  • PHẢI có tính năng tự động lấy nét phần cứng hoặc tự động lấy nét phần mềm được triển khai trong trình điều khiển máy ảnh (trong suốt đối với phần mềm ứng dụng)
  • CÓ THỂ có phần cứng lấy nét cố định hoặc EDOF (độ sâu trường ảnh mở rộng)
  • CÓ THỂ có đèn flash. Nếu Máy ảnh có đèn flash, thì đèn flash KHÔNG được sáng trong khi thực thể android.hardware.Camera.PreviewCallback đã được đăng ký trên nền tảng xem trước của Máy ảnh, trừ phi ứng dụng đã bật đèn flash một cách rõ ràng bằng cách bật các thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON của đối tượng Camera.Parameters. Xin lưu ý rằng quy tắc ràng buộc này không áp dụng cho ứng dụng camera hệ thống tích hợp sẵn của thiết bị, mà chỉ áp dụng cho các ứng dụng của bên thứ ba sử dụng Camera.PreviewCallback.

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

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

  • PHẢI có độ phân giải tối thiểu là VGA (tức là 640x480 pixel)
  • KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước làm mặc định cho Camera API. Tức là API máy ảnh trong Android 2.3 có hỗ trợ cụ thể cho máy ảnh mặt trước và việc triển khai thiết bị KHÔNG ĐƯỢC định cấu hình API để coi máy ảnh mặt trước là máy ảnh mặt sau mặc định, ngay cả khi đó là máy ảnh duy nhất trên thiết bị.
  • CÓ THỂ bao gồm các tính năng (chẳng hạn như tự động lấy nét, đèn flash, v.v.) dành cho máy ảnh mặt sau như mô tả trong Mục 7.5.1.
  • PHẢI phản chiếu theo chiều ngang (tức là phản chiếu) luồng do ứng dụng hiển thị trong CameraPreview, như sau:
  • Nếu người dùng có thể xoay chế độ triển khai thiết bị (chẳng hạn như tự động thông qua gia tốc kế hoặc theo cách thủ công thông qua dữ liệu đầu vào của người dùng), thì bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng hiện tại của thiết bị.
  • Nếu ứng dụng hiện tại đã yêu cầu rõ ràng việc xoay màn hình Camera thông qua lệnh gọi đến phương thức android.hardware.Camera.setDisplayOrientation() [Tài nguyên, 40], thì bản xem trước của máy ảnh PHẢI được phản chiếu theo chiều ngang so với hướng do ứng dụng chỉ định.
  • Nếu không, bản xem trước PHẢI được phản chiếu dọc theo trục ngang mặc định của thiết bị.
  • PHẢI phản ánh dữ liệu hình ảnh được trả về cho bất kỳ trình xử lý gọi lại máy ảnh "postview" nào, theo cách tương tự như luồng hình ảnh xem trước của máy ảnh. (Nếu việc triển khai thiết bị không hỗ trợ lệnh gọi lại sau khi xem, thì rõ ràng yêu cầu này sẽ không áp dụng.)
  • KHÔNG ĐƯỢC phản ánh luồng video hoặc hình ảnh tĩnh đã chụp cuối cùng được trả về cho lệnh gọi lại ứng dụng hoặc được cam kết lưu vào bộ nhớ phương tiện

  7.5.3. Hành vi của Camera API

  Việc triển khai thiết bị PHẢI triển khai các hành vi sau đây cho các API liên quan đến máy ảnh, cho cả máy ảnh mặt trước và mặt sau:

  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 truyền vào onPreviewFrame() phải ở định dạng mã hoá NV21. Tức là NV21 PHẢI là giá trị mặc định.
  3. Việc triển khai thiết bị PHẢI hỗ trợ định dạng YV12 (như được biểu thị bằng hằng số android.graphics.ImageFormat.YV12) cho bản xem trước của máy ảnh cho cả máy ảnh mặt trước và mặt sau. Xin lưu ý rằ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 yêu cầu này thành "PHẢI". Tức là bạn không bắt buộc phải hỗ trợ YV12 trong Android 2.3 nhưng bắt buộc phải hỗ trợ 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 2.3 nên đáp ứng yêu cầu này trong Android 2.3, nếu không, chúng sẽ không thể đạt được khả năng tương thích với Android khi nâng cấp lên phiên bản trong tương lai.

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

  Các hoạt động triển khai thiết bị PHẢI nhận dạng và tuân thủ từng tên tham số được xác định là hằng số trên lớp android.hardware.Camera.Parameters, nếu phần cứng cơ bản hỗ trợ tính năng này. Nếu phần cứng thiết bị không hỗ trợ một tính năng, thì API phải hoạt động như đã ghi nhận. Ngược lại, việc triển khai Thiết bị KHÔNG ĐƯỢC tuân thủ hoặc nhận dạng các hằng số chuỗi được truyền đến phương thức android.hardware.Camera.setParameters(), ngoại trừ các hằng số được ghi nhận là hằng số trên android.hardware.Camera.Parameters. Tức là, việc triển khai thiết bị PHẢI hỗ trợ tất cả các thông số Máy ảnh tiêu chuẩn nếu phần cứng cho phép và KHÔNG ĐƯỢC hỗ trợ các loại thông số Máy ảnh tuỳ chỉnh.

  7.5.4. Hướng máy ảnh

  Cả máy ảnh mặt trước và máy ảnh mặt sau (nếu có) PHẢI được định hướng để chiều dài của máy ảnh phù hợp với chiều dài của màn hình. Nghĩa là khi thiết bị được giữ theo hướng ngang, máy ảnh PHẢI chụp ảnh theo hướng ngang. Điều này áp dụng bất kể hướng tự nhiên của thiết bị; tức là áp dụng cho cả thiết bị chính theo hướng ngang và thiết bị chính theo hướng dọc.

  7.6. Bộ nhớ và dung lượng lưu trữ

  Chức năng cơ bản của Android 2.3 là chạy các ứng dụng. Việc triển khai thiết bị PHẢI đáp ứng các yêu cầu của phần này để đảm bảo có đủ bộ nhớ và dung lượng lưu trữ cho các ứng dụng chạy đúng cách.

  7.6.1. Bộ nhớ và dung lượng lưu trữ tối thiểu

  Việc triển khai thiết bị PHẢI có ít nhất 128 MB bộ nhớ cho hạt nhân và không gian người dùng. 128 MB PHẢI là bộ nhớ bổ sung cho mọi bộ nhớ dành riêng cho các thành phần phần cứng như đài, bộ nhớ, v.v. không thuộc quyền kiểm soát của nhân.

  Việc triển khai thiết bị PHẢI có ít nhất 150 MB bộ nhớ không bay hơi cho dữ liệu người dùng. Tức là phân vùng /data PHẢI có dung lượng tối thiểu là 150 MB.

  Ngoài các yêu cầu ở trên, việc triển khai thiết bị PHẢI có ít nhất 1 GB bộ nhớ không bay hơi cho dữ liệu người dùng. Xin lưu ý rằng yêu cầu cao hơn này dự kiến sẽ trở thành yêu cầu tối thiểu bắt buộc trong một phiên bản Android sau này. Bạn nên triển khai thiết bị để đáp ứng các yêu cầu này ngay từ bây giờ, nếu không, thiết bị có thể không đủ điều kiện để tương thích với phiên bản Android trong tương lai.

  API Android bao gồm một Trình quản lý tải xuống mà các ứng dụng có thể sử dụng để tải tệp dữ liệu xuống. Việc triển khai Trình quản lý tải xuống PHẢI có khả năng tải từng tệp có kích thước từ 55 MB trở lên. Việc triển khai Trình quản lý tải xuống PHẢI có khả năng tải các tệp có kích thước từ 100 MB trở lên.

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

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

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

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

  Việc triển khai thiết bị CÓ THỂ có phần cứng cho bộ nhớ có thể tháo rời mà người dùng có thể truy cập, chẳng hạn như thẻ Secure Digital. Ngoài ra, quá trình triển khai thiết bị CÓ THỂ phân bổ bộ nhớ trong (không thể tháo rời) làm bộ nhớ dùng chung cho các ứng dụng.

  Bất kể hình thức bộ nhớ dùng chung được sử dụng, việc triển khai thiết bị PHẢI cung cấp một số cơ chế để truy cập vào nội dung của bộ nhớ dùng chung từ máy tính lưu trữ, chẳng hạn như bộ nhớ khối lượng lớn USB hoặc Giao thức truyền nội dung nghe nhìn.

  Hãy xem xét hai ví dụ phổ biến để minh hoạ điều này. Nếu việc triển khai thiết bị bao gồm khe cắm thẻ SD để đáp ứng yêu cầu về bộ nhớ dùng chung, thì thiết bị bán cho người dùng PHẢI có thẻ SD có định dạng FAT có dung lượng từ 1 GB trở lên và PHẢI được gắn theo mặc định. Ngoài ra, nếu việc triển khai thiết bị sử dụng bộ nhớ cố định trong để đáp ứng yêu cầu này, thì bộ nhớ đó PHẢI có dung lượng từ 1 GB trở lên và được gắn trên /sdcard (hoặc /sdcard PHẢI là đường liên kết tượng trưng đến vị trí thực tế nếu được gắn ở nơi khác).

  Việc triển khai thiết bị có nhiều đường dẫn bộ nhớ dùng chung (chẳng hạn như cả khe cắm thẻ SD và bộ nhớ trong dùng chung) PHẢI sửa đổi các ứng dụng cốt lõi như trình quét nội dung nghe nhìn và ContentProvider để hỗ trợ minh bạch các tệp được đặt ở cả hai vị trí.

  7.7. USB

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

  • PHẢI triển khai ứng dụng USB, có thể kết nối với máy chủ USB bằng cổng USB-A tiêu chuẩn
  • PHẢI triển khai Cầu gỡ lỗi Android qua USB (như mô tả trong Phần 7)
  • PHẢI triển khai quy cách bộ nhớ khối lớn USB để 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 /sdcard
  • NÊN sử dụng kiểu dáng USB loại nhỏ ở phía thiết bị
  • CÓ THỂ bao gồm một cổng không theo tiêu chuẩn ở phía thiết bị, nhưng nếu có, PHẢI vận chuyển kèm theo một cáp có thể kết nối chân cắm tuỳ chỉnh với cổng USB-A tiêu chuẩn

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

  Việc triển khai tương thích không chỉ đảm bảo rằng các ứng dụng chạy chính xác trên thiết bị mà còn đảm bảo rằng các ứng dụng đó chạy với hiệu suất hợp lý và mang lại trải nghiệm tốt cho người dùng. Việc triển khai thiết bị PHẢI đáp ứng các chỉ số hiệu suất chính của một thiết bị tương thích với Android 2.3 được xác định trong bảng bên dưới:

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

  9. Khả năng tương thích của mô hình bảo mật

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

  9.1. Quyền

  Việc triển khai thiết bị PHẢI hỗ trợ mô hình quyền của Android như được xác định trong tài liệu dành cho nhà phát triển Android [Tài nguyên, 42]. Cụ thể, quá trình triển khai PHẢI thực thi từng quyền được xác định như mô tả trong tài liệu SDK; không được bỏ qua, thay đổi hoặc bỏ qua bất kỳ quyền nào. Quá trình triển khai CÓ THỂ thêm các quyền khác, miễn là chuỗi mã nhận dạng quyền mới không nằm trong không gian tên android.*.

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

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

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

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

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

  Việc triển khai thiết bị CÓ THỂ bao gồm các môi trường thời gian chạy thực thi ứng dụng bằng một số phần mềm hoặc công nghệ khác ngoài máy ảo Dalvik hoặc mã gốc. Tuy nhiên, các môi trường thực thi thay thế như vậy KHÔNG được làm tổn hại đến mô hình bảo mật Android hoặc tính bảo mật của các ứng dụng Android đã cài đặt, như mô tả trong phần này.

  Môi trường thời gian chạy thay thế PHẢI là ứng dụng Android và tuân thủ mô hình bảo mật Android tiêu chuẩn, như mô tả ở phần khác trong Mục 9.

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

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

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

  • Thời gian chạy thay thế PHẢI cài đặt ứng dụng thông qua PackageManager vào các hộp cát Android riêng biệt (tức là mã nhận dạng người dùng Linux, v.v.)
  • Môi trường thời gian chạy thay thế CÓ THỂ cung cấp một hộp cát Android duy nhất do tất cả ứng dụng sử dụng môi trường thời gian chạy thay thế chia sẻ.
  • Môi trường thời gian chạy thay thế và các ứng dụng đã cài đặt sử dụng môi trường thời gian chạy thay thế KHÔNG ĐƯỢC sử dụng lại hộp cát của bất kỳ ứng dụng nào khác đã cài đặt trên thiết bị, ngoại trừ thông qua các cơ chế Android tiêu chuẩn về mã nhận dạng người dùng dùng chung và chứng chỉ ký
  • Môi trường thời gian chạy thay thế KHÔNG ĐƯỢC chạy bằng, cấp hoặc được cấp quyền truy cập vào các hộp cát tương ứng với các ứng dụng Android khác.

  KHÔNG được chạy, cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của người dùng cấp cao (gốc) hoặc của bất kỳ mã nhận dạng người dùng nào khác trong môi trường thời gian chạy thay thế.

  Các tệp .apk của môi trường thời gian chạy thay thế CÓ THỂ được đưa vào hình ảnh hệ thống của quá trình triển khai thiết bị, nhưng PHẢI được ký bằng một khoá khác với khoá dùng để ký các ứng dụng khác đi kèm với quá trình triển khai thiết bị.

  Khi cài đặt ứng dụng, môi trường thời gian chạy thay thế PHẢI có được sự đồng ý của người dùng đối với các quyền trên Android mà ứng dụng sử dụng. Tức là nếu một ứng dụng cần sử dụng tài nguyên thiết bị có quyền tương ứng trên Android (chẳng hạn như Máy ảnh, GPS, v.v.), thì môi trường thời gian chạy thay thế PHẢI thông báo cho người dùng rằng ứng dụng sẽ có thể truy cập vào tài nguyên đó. Nếu môi trường thời gian chạy không ghi lại các chức năng của ứng dụng theo cách này, thì môi trường thời gian chạy PHẢI liệt kê tất cả các quyền mà chính môi trường thời gian chạy nắm giữ khi cài đặt bất kỳ ứng dụng nào sử dụng môi trường thời gian chạy đó.

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

  Dự án nguồn mở Android bao gồm nhiều công cụ kiểm thử để xác minh rằng việc triển khai thiết bị có tương thích hay không. Việc triển khai thiết bị PHẢI vượt qua tất cả các bài kiểm thử được mô tả trong phần này.

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

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

  Việc triển khai thiết bị PHẢI vượt qua Bộ kiểm thử tính tương thích với Android (CTS) [Tài nguyên, 2] có trong Dự án nguồn mở Android, bằng cách sử dụng phần mềm vận chuyển chính thức trên thiết bị. Ngoài ra, người triển khai thiết bị NÊN sử dụng phương thức triển khai tham chiếu trong cây Nguồn mở Android càng nhiều càng tốt và PHẢI đảm bảo khả năng tương thích trong trường hợp không rõ ràng trong CTS và cho mọi lần triển khai lại các phần của mã nguồn tham chiếu.

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

  PHẢI vượt qua phiên bản mới nhất của Bộ kiểm thử khả năng tương thích với Android (CTS) có sẵn tại thời điểm hoàn tất việc triển khai phần mềm của thiết bị. (CTS có trong Dự án nguồn mở Android [Tài nguyên, 2].) CTS kiểm thử nhiều (nhưng không phải tất cả) thành phần được nêu trong tài liệu này.

  10.2. Trình xác minh CTS

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

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

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

  10.3. Ứng dụng tham khảo

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

  • Ứng dụng "Apps for Android" (Ứng dụng cho Android) [Tài nguyên, 43].
  • Đảo sao chép (có trong Android Market; chỉ bắt buộc đối với các phương thức triển khai thiết bị hỗ trợ OpenGL ES 2.0)

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

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

  Quá trình triển khai thiết bị PHẢI bao gồm một cơ chế để thay thế toàn bộ phần mềm hệ thống. Cơ chế này không cần thực hiện các bản nâng cấp "trực tiếp" – nghĩa là bạn CÓ THỂ phải khởi động lại thiết bị.

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

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

  Cơ chế cập nhật được sử dụng PHẢI hỗ trợ các bản cập nhật mà không xoá dữ liệu người dùng. Xin lưu ý rằng phần mềm Android ngược dòng có một cơ chế cập nhật đáp ứng yêu cầu này.

  Nếu phát hiện lỗi trong quá trình triển khai thiết bị sau khi thiết bị đó được phát hành nhưng trong thời gian sử dụng sản phẩm hợp lý được xác định khi tham khảo ý kiến của Nhóm tương thích Android để ảnh hưởng đến khả năng tương thích của ứng dụng bên thứ ba, thì bên triển khai thiết bị PHẢI khắc phục lỗi thông qua bản cập nhật phần mềm hiện có có thể áp dụng theo cơ chế vừa mô tả.

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

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

  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 Android. Tuy nhiên, vì Bluetooth là một giao thức giao tiếp giữa các thiết bị, nên bạ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 đó, việc triển khai thiết bị cũng PHẢI vượt qua quy trình kiểm thử Bluetooth do con người thực hiện như mô tả bên dưới.

  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 này yêu cầu hai thiết bị:

  • một thiết bị đề xuất triển khai chạy bản dựng phần mềm cần được kiểm thử
  • một phương thức 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ừ phương thức triển khai thiết bị đang được kiểm thử – tức là một phương thức triển khai thiết bị "đã biết là tốt"

  Quy trình kiểm thử bên dưới 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à hoạt động tốt.
  3. Cài đặt BluetoothChat.apk trên thiết bị đề xuất.

  Kiểm thử tính năng Điều khiển Bluetooth bằng ứng dụng

  1. Chạy BluetoothChat trên thiết bị đề xuất, trong khi Bluetooth đang tắt.
  2. Xác minh rằng thiết bị đề xuất bật Bluetooth hoặc nhắc người dùng bật Bluetooth bằng một hộp thoại.

  Kiểm thử tính năng 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 là tốt trong BluetoothChat (bằng Trình đơn).
  3. Trên thiết bị đề xuất, hãy quét tìm thiết bị Bluetooth trong BluetoothChat (sử dụng Trình đơn) và ghép nối với thiết bị đã biết là tốt.
  4. Gửi 10 tin nhắn trở lên từ mỗi thiết bị và xác minh rằng thiết bị còn lại nhận đượ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 nút Home (Trang chủ).
  6. Huỷ ghép nối từng thiết bị với thiết bị còn lại bằng ứng dụng Cài đặt của thiết bị.

  Kiểm thử tính năng ghép nối và giao tiếp theo hướng ngược lại

  1. Chạy ứng dụng Bluetooth Chat trên cả hai thiết bị.
  2. Đặt thiết bị đề xuất ở chế độ phát hiện được trong BluetoothChat (bằng Trình đơn).
  3. Trên thiết bị đã biết là tốt, hãy quét tìm thiết bị Bluetooth 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ị còn lại nhận được tin nhắn đúng cách.
  5. Đóng ứng dụng Bluetooth Chat trên cả hai thiết bị bằng cách nhấn liên tục vào nút Quay lại để chuyển đến Trình chạy.

  Kiểm thử việc 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ị còn lại nhận được tin nhắn đúng cách.

  Lưu ý: các kiểm thử ở trên có một số trường hợp kết thúc phần kiểm thử bằng cách sử dụng Màn hình chính và một số trường hợp sử dụng Quay lại. Các kiểm thử này không thừa và không bắt buộc: mục tiêu là xác minh rằng API và ngăn xếp Bluetooth hoạt động chính xác cả khi Hoạt động bị chấm dứt rõ ràng (thông qua người dùng nhấn nút Quay lại, gọi finish()) và được gửi ngầm vào nền (thông qua người dùng nhấn nút Home). BẠN PHẢI thực hiện từng trình tự kiểm thử như mô tả.