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

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
2. Tài nguyên
3. Phần mềm
3.1. Khả năng tương thích với API được quản lý
3.2. Khả năng tương thích mềm của API
3.3. Khả năng tương thích với API gốc
3.4. Khả năng tương thích với web
3.5. Khả năng tương thích về hành vi của API
3.6. Không gian tên API
3.7. Khả năng tương thích với máy ảo
3.8. Khả năng tương thích với giao diện người dùng
4. Khả năng tương thích với phần mềm tham chiếu
5. Khả năng tương thích của tính năng đóng gói ứng dụng
6. Khả năng tương thích với nội dung đa phương tiện
7. Khả năng tương thích với công cụ dành cho nhà phát triển
8. Khả năng tương thích với phần cứng
9. Khả năng tương thích về hiệu suất
10. Khả năng tương thích của mô hình bảo mật
11. Bộ kiểm thử khả năng tương thích
12. Phần mềm có thể cập nhật
13. Liên hệ với chúng tôi
Phụ lục A – Quy trình kiểm thử 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 để điện thoại di động tương thích với Android 2.2.

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.2. "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.2, việc triển khai thiết bị phải:

  • PHẢI đáp ứng các yêu cầu 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.
  • 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.

Trong trường hợp định nghĩa này hoặc CTS không đề cập, không rõ ràng 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ó trong Dự án nguồn mở Android. Mặc dù có thể thay thế một số thành phần bằng cách triển khai thay thế, nhưng bạn không nên làm như vậy vì việc vượt qua các bài kiểm thử CTS 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ố thay thế và sửa đổi thành phần nhất định.

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.2: http://source.android.com/docs/compatibility/2.2/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. Thông số kỹ thuật của Máy ảo Dalvik: có trong mã nguồn Android, tại dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Thông báo: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Tài nguyên ứng dụng: http://code.google.com/android/reference/available-resources.html
  14. 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
  15. Trình quản lý tìm kiếm: http://developer.android.com/reference/android/app/SearchManager.html
  16. Thông báo ngắn: http://developer.android.com/reference/android/widget/Toast.html
  17. Hình nền động: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android
  19. 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
  20. Nội dung mô tả tệp apk Android: http://developer.android.com/guide/topics/fundamentals.html
  21. Tệp kê khai: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Công cụ kiểm thử Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Danh sách tính năng phần cứng Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. Hỗ trợ nhiều màn hình: http://developer.android.com/guide/practices/screens_support.html
  25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  28. Không gian toạ độ cảm biến: http://developer.android.com/reference/android/hardware/SensorEvent.html
  29. 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
  30. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Nhiều tài nguyên trong số này được lấy trực tiếp hoặc gián tiếp từ SDK Android 2.2 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.2 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ể.

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.2. 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.2, trường này PHẢI có giá trị số nguyên là 8.
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ị. 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.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ị. 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.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ị. 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.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)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Ví dụ:
acme/mydevice/generic/generic:2.2/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 ("_").
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. Không có yêu cầu nào về định dạng cụ thể của trường này, ngoại trừ việc trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.MODEL Giá trị do người triển khai thiết bị chọn, chứa tên của thiết bị mà người dùng cuối biết. Tên này PHẢI giống với tên mà thiết bị được tiếp thị và bán cho người dùng cuối. Không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ trường này KHÔNG ĐƯỢC rỗng hoặc chuỗi trống ("").
android.os.Build.PRODUCT Giá trị do người triển khai thiết bị chọn, chứa tên phát triển hoặc tên mã của 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. 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.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". Trường này KHÔNG được rỗng hoặc là chuỗi trống (""), nhưng một thẻ duy nhất (chẳng hạn như "bản phát hành") là được.
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".
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
  • Camera
  • Danh bạ
  • Email
  • Thư viện
  • GlobalSearch
  • Trình chạy
  • LivePicker (tức là ứng dụng bộ chọn Hình nền động; CÓ THỂ bị bỏ qua nếu thiết bị không hỗ trợ Hình nền động, theo Mục 3.8.5.)
  • Nhắn tin (còn gọi là "Mms")
  • Âm nhạc
  • Điện thoại
  • Cài đặt
  • SoundRecorder

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. Việc triển khai thiết bị PHẢI bao gồm tính năng 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. Mã gốc PHẢI có các API sau:

  • libc (thư viện C)
  • libm (thư viện toán học)
  • Giao diện JNI
  • libz (nén Zlib)
  • liblog (Ghi nhật ký Android)
  • Hỗ trợ tối thiểu cho C++
  • Hỗ trợ OpenGL, như mô tả dưới đây

Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 1.0. Các thiết bị thiếu tính năng tăng tốc phần cứng PHẢI triển khai OpenGL ES 1.0 bằng trình kết xuất phần mềm. Việc triển khai thiết bị PHẢI triển khai nhiều OpenGL ES 1.1 nhất có thể trong phạm vi phần cứng thiết bị hỗ trợ. Phương thức triển khai thiết bị PHẢI cung cấp phương thức triển khai cho OpenGL ES 2.0, nếu phần cứng có thể đạt được hiệu suất hợp lý trên các API đó.

Các thư viện này 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 một cấu trúc bộ xử lý nhất định) với các phiên bản do dự án Nguồn mở Android cung cấp trong Bionic. Vì các phương thức triển khai Bionic không tương thích hoàn toàn với các phương thức triển khai khác như thư viện GNU C, nên người triển khai thiết bị PHẢI sử dụng phương thức triển khai Android. Nếu người triển khai thiết bị sử dụng cách triển khai khác cho các thư viện này, thì họ PHẢI đảm bảo khả năng tương thích của tiêu đề, tệp nhị phân và hành vi.

Việc triển khai thiết bị PHẢI báo cáo chính xác Giao diện nhị phân ứng dụng (ABI) gốc mà thiết bị hỗ trợ thông qua API android.os.Build.CPU_ABI. ABI PHẢI là một trong các mục được ghi lại trong phiên bản mới nhất của Android NDK, trong tệp docs/CPU-ARCH-ABIS.txt. Xin lưu ý rằng các bản phát hành bổ sung của Android NDK có thể hỗ trợ thêm các ABI.

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ải nghiệm web đầy đủ là yếu tố trung tâm của trải nghiệm người dùng Android. Việc triển khai thiết bị PHẢI bao gồm phiên bản android.webkit.WebView nhất quán với phần mềm Android thượng nguồn và PHẢI bao gồm một trình duyệt hiện đại có 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ể:

  • 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 dựng WebKit 533.1 từ cây nguồn mở Android ngược dòng cho Android 2.2. 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

Cấu hình WebView PHẢI hỗ trợ cơ sở dữ liệu HTML5, bộ nhớ đệm của ứng dụng và API vị trí địa lý [Tài nguyên, 9]. WebView PHẢI hỗ trợ thẻ <video> HTML5. Các API HTML5, giống như tất cả API JavaScript, PHẢI bị tắt theo mặc định trong WebView, trừ phi nhà phát triển bật rõ ràng các API đó 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 ứng dụng Trình duyệt thay thế được vận chuyển, 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 Phần 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ợ API cơ sở dữ liệu, bộ nhớ đệm ứng dụng và vị trí địa lý HTML5 cũng như thẻ <video> trong ứng dụng Trình duyệt độc lập.

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

Danh sách trên chưa đầy đủ và trách nhiệm thuộc về những người triển khai thiết bị để đảm bảo khả năng tương thích về hành vi. 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.

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 để xác định 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.

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.

"Phần tử 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" trong mã nguồn Android ngược dòng. Nói cách khác, trình triển khai thiết bị KHÔNG ĐƯỢC hiển thị API mới hoặc thay đổi API hiện có trong không gian tên nêu trên. Người 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.

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

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 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, 11]. 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, 12]. 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, 13] hoặc trong hướng dẫn về kiểu biểu tượng Thanh trạng thái [Tài nguyên, 14]. 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.

Android bao gồm các API [Tài nguyên, 15] cho phép nhà phát triển tích hợp tính năng tìm kiếm vào ứng dụng và hiển thị dữ liệu của ứng dụng vào tính năng tìm kiếm trên hệ thống toàn cầu. 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, 16]) để 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, 17]. 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 phần mềm 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:

  • Máy tính (có trong SDK)
  • Lunar Lander (có trong SDK)
  • Ứng dụng "Apps for Android" (Ứng dụng cho Android) [Tài nguyên, 18].
  • Đả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.

Ngoài ra, việc triển khai thiết bị PHẢI kiểm thử từng mục trong trình đơn (bao gồm cả tất cả trình đơn con) của từng ứng dụng kiểm thử nhanh sau đây:

  • ApiDemos (có trong SDK)
  • ManualSmokeTests (có trong CTS)

Mỗi trường hợp kiểm thử trong các ứng dụng ở trên PHẢI chạy chính xác trên quá trình triển khai thiết bị.

5. 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, 19].

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

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

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

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

Xin lưu ý rằng cả Google và Liên minh điện thoại mở đều không đưa ra bất kỳ tuyên bố nào rằng các bộ mã hoá và giải mã này không 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.

Âm thanh
Tên Bộ mã hoá Trình giải mã Chi tiết Định dạng tệp/vùng chứa
AAC LC/LTP   X 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+)   X
HE-AACv2 (AAC+ nâng cao)   X
AMR-NB X X 4,75 đến 12,2 kbps lấy mẫu ở 8 kHz 3GPP (.3gp)
AMR-WB   X 9 tốc độ từ 6,60 kbit/giây đến 23,85 kbit/giây lấy mẫu ở 16 kHz 3GPP (.3gp)
MP3   X Â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   X 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   X   Ogg (.ogg)
Trình quản lý kết nối đối tác   X 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 X X cơ sở+tiến bộ  
GIF   X    
PNG X X    
BMP   X    
Video
H.263 X X   Tệp 3GPP (.3gp)
H.264   X   Tệp 3GPP (.3gp) và MPEG-4 (.mp4)
Cấu hình đơn giản MPEG4   X   Tệp 3GPP (.3gp)

Xin lưu ý rằng bảng trên 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.

6.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.2, 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.2 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.2 nên đáp ứng các yêu cầu này trong Android 2.2, 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.

6.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ị 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.

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.2, 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.2 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.2 nên đáp ứng các yêu cầu này trong Android 2.2, 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.

7. 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, 19]
    Việc triển khai thiết bị PHẢI hỗ trợ tất cả các hàm adb như được ghi nhận trong SDK Android. Theo mặc định, trình nền adb phía thiết bị PHẢI ở 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, 19]
    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, 22]
    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.

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

Android được thiết kế để hỗ trợ những người triển khai thiết bị tạo ra các kiểu dáng và cấu hình mới. Đồng thời, nhà phát triển Android mong đợi một số phần cứng, cảm biến và API nhất định trên tất cả thiết bị Android. Phần này liệt kê các tính năng phần cứng mà tất cả thiết bị tương thích với Android 2.2 phải hỗ trợ.

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ư được xác định 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 có định nghĩa lớp cho API của thành phần
  • hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo một cách hợp lý
  • Các phương thức API PHẢI trả về giá trị rỗng nếu tài liệu SDK cho phép
  • Các phương thức API PHẢI trả về các phương thức triển khai không hoạt động của các lớp mà tài liệu SDK không cho phép giá trị rỗng

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

8.1. Màn hình

Android 2.2 bao gồm các cơ sở thực hiện một số thao tác tự động chuyển đổi và điều chỉnh theo tỷ lệ trong một số trường hợp, để đảm bảo rằng 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, 24]. Thiết bị PHẢI triển khai đúng cách các hành vi này, như mô tả chi tiết trong phần này.

Đối với Android 2.2, đây là các cấu hình màn hình phổ biến nhất:

Loại màn hình Chiều rộng (Pixel) Chiều cao (Pixel) Phạm vi chiều dài đường chéo (inch) Nhóm kích thước màn hình Nhóm mật độ màn hình
QVGA 240 320 2.6 – 3.0 Nhỏ Thấp
WQVGA 240 400 3.2 – 3.5 Bình thường Thấp
FWQVGA 240 432 3.5 – 3.8 Bình thường Thấp
HVGA 320 480 3.0 – 3.5 Bình thường Trung bình
WVGA 480 800 3.3 – 4.0 Bình thường Cao
FWVGA 480 854 3,5 – 4,0 Bình thường Cao
WVGA 480 800 4,8 – 5,5 Lớn Trung bình
FWVGA 480 854 5.0 – 5.8 Lớn Trung bình

Việc triển khai thiết bị tương ứng với một trong các cấu hình tiêu chuẩn ở trên PHẢI được định cấu hình để báo cáo kích thước màn hình đã chỉ định cho các ứng dụng thông qua lớp android.content.res.Configuration [Tài nguyên, 24].

Một số gói .apk có tệp kê khai không xác định rằng các gói đó hỗ trợ một phạm vi mật độ cụ thể. Khi chạy các ứng dụng như vậy, các điều kiện ràng buộc sau đây sẽ áp dụng:

  • Việc triển khai thiết bị PHẢI diễn giải các tài nguyên trong tệp .apk thiếu bộ hạn định mật độ theo mặc định là "medium" (thường gọi là "mdpi" trong tài liệu SDK).
  • Khi hoạt động trên màn hình có mật độ "thấp", việc triển khai thiết bị PHẢI giảm tỷ lệ tài sản trung bình/mdpi theo hệ số 0,75.
  • Khi hoạt động trên màn hình có mật độ "cao", việc triển khai thiết bị PHẢI tăng tỷ lệ tài sản trung bình/mdpi theo hệ số 1,5.
  • Việc triển khai thiết bị KHÔNG ĐƯỢC điều chỉnh tỷ lệ thành phần trong một phạm vi mật độ và KHÔNG ĐƯỢC điều chỉnh tỷ lệ thành phần theo các hệ số này giữa các phạm vi mật độ.

8.1.2. Cấu hình màn hình không chuẩn

Các cấu hình hiển thị không khớp với một trong các cấu hình chuẩn được liệt kê trong Mục 8.1.1 cần được xem xét thêm và phải tương thích. Người triển khai thiết bị PHẢI liên hệ với Nhóm tương thích Android như mô tả trong Phần 13 để nhận được thông tin phân loại về nhóm kích thước màn hình, mật độ và hệ số tỷ lệ. Khi được cung cấp thông tin này, các hoạt động triển khai thiết bị PHẢI triển khai theo thông tin được chỉ định.

Xin lưu ý rằng một số cấu hình màn hình (chẳng hạn như màn hình rất lớn hoặc rất nhỏ và một số tỷ lệ khung hình) về cơ bản không tương thích với Android 2.2; do đó, những người triển khai thiết bị nên liên hệ với Nhóm tương thích Android càng sớm càng tốt trong quá trình phát triển.

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

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

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

8.2. 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, 25] (tức là QWERTY hoặc 12 phím)

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

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

  • CÓ THỂ bỏ qua các 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, 25]

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

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.

8.5. 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, 25] 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ỏ

8.6. 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
  • NÊN triển khai tính năng hỗ trợ cho thông số kỹ thuật USB Mass Storage (để có thể truy cập vào bộ nhớ có thể tháo rời hoặc bộ nhớ cố định trên thiết bị từ máy tính lưu trữ)

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

8.8. Mạng dữ liệu không dây

Việc triển khai thiết bị PHẢI bao gồm tính năng hỗ trợ kết nối mạng dữ liệu tốc độ cao không dây. 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 không dây 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, v.v.

Nếu quá trình triển khai thiết bị bao gồm một phương thức cụ thể mà SDK Android bao gồm một API (tức là WiFi, GSM hoặc CDMA), thì quá trình triển khai PHẢI hỗ trợ API đó.

Thiết bị CÓ THỂ triển khai nhiều hình thức kết nối dữ liệu không dây. Thiết bị CÓ THỂ triển khai kết nối dữ liệu có dây (chẳng hạn như Ethernet), nhưng PHẢI bao gồm ít nhất một hình thức kết nối không dây, như trên.

8.9. Camera

Việc triển khai thiết bị PHẢI bao gồm máy ảnh mặt sau. Máy ảnh mặt sau đi kèm:

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

Quá trình 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:

  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. (Đây là định dạng gốc mà gia đình phần cứng 7k sử dụng.) Tức là NV21 PHẢI là giá trị mặc định.

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

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.

Việc triển khai thiết bị CÓ THỂ bao gồm máy ảnh mặt trước. Tuy nhiên, nếu việc triển khai thiết bị bao gồm máy ảnh mặt trước, thì theo mặc định, API máy ảnh được triển khai trên thiết bị KHÔNG ĐƯỢC sử dụng máy ảnh mặt trước. Tức là API máy ảnh trong Android 2.2 chỉ dành cho máy ảnh mặt sau và việc triển khai thiết bị KHÔNG ĐƯỢC sử dụng lại hoặc quá tải API để hoạt động trên máy ảnh mặt trước (nếu có). Xin lưu ý rằng mọi API tuỳ chỉnh do người triển khai thiết bị thêm vào để hỗ trợ máy ảnh mặt trước PHẢI tuân thủ các phần 3.5 và 3.6; ví dụ: nếu một lớp con android.hardware.Camera hoặc Camera.Parameters tuỳ chỉnh được cung cấp để hỗ trợ máy ảnh mặt trước, thì lớp con đó KHÔNG ĐƯỢC nằm trong không gian tên hiện có, như mô tả trong các phần 3.5 và 3.6. Xin lưu ý rằng việc đưa máy ảnh mặt trước vào thiết bị không đáp ứng yêu cầu là thiết bị phải có máy ảnh mặt sau.

8.10. Gia tốc kế

Việc triển khai thiết bị PHẢI bao gồm gia tốc kế 3 trục và PHẢI có khả năng phân phối sự kiện ở tần số 50 Hz trở lên. Hệ toạ độ mà cảm biến gia tốc sử dụng 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, 28]).

8.11. La bàn

Việc triển khai thiết bị PHẢI bao gồm la bàn 3 trục và PHẢI có khả năng phân phối các sự kiện từ 10 Hz trở lên. Hệ toạ độ mà la bàn sử dụng PHẢI tuân thủ hệ toạ độ cảm biến Android như được xác định trong API Android (xem [Tài nguyên, 28]).

8.12. GPS

Việc triển khai thiết bị PHẢI bao gồm một bộ thu GPS và NÊN 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.

8.13. Điện thoại

Android 2.2 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.2 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.

Xem thêm Mục 8.8, Kết nối mạng dữ liệu không dây.

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

Việc triển khai thiết bị PHẢI có ít nhất 92 MB bộ nhớ cho hạt nhân và không gian người dùng. 92 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 128 MB bộ nhớ cho nhân và không gian người dùng, ngoài mọi bộ nhớ dành riêng cho các thành phần phần cứng 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 1 GB bộ nhớ không bay hơi cho dữ liệu người dùng. Xin lưu ý rằng các 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.

8.15. 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 bộ nhớ dùng chung được cung cấp PHẢI có kích thước tối thiểu là 2 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, bộ nhớ dùng chung PHẢI triển khai bộ nhớ khối lượng lớn USB như mô tả trong Mục 8.6. Khi xuất xưởng, bộ nhớ dùng chung PHẢI được gắn với hệ thống tệp FAT.

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ừ 2 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ó kích thước từ 2 GB trở lên, được định dạng là FAT 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í.

8.16. Bluetooth

Việc triển khai thiết bị PHẢI bao gồm một bộ thu phát Bluetooth. Việc triển khai thiết bị PHẢI bật API Bluetooth dựa trên RFCOMM như mô tả trong tài liệu SDK [Tài nguyên, 30]. 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.

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

Một trong những mục tiêu của Chương trình tương thích Android là mang đến cho người tiêu dùng trải nghiệm ứng dụng nhất quán. 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.2 được xác định trong bảng dưới đây:

Chỉ số Ngưỡng hiệu suất Nhận xét
Thời gian chạy ứng dụng Các ứng dụng sau đây sẽ khởi chạy trong thời gian đã chỉ định.
  • Trình duyệt: dưới 1300 mili giây
  • 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.  

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

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

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

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

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

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 đó.

11. 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.2. 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ị.

12. 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 các ứng dụng bên thứ ba, thì bên triển khai thiết bị PHẢI khắc phục lỗi thông qua bản cập nhật phần mềm hiện có có thể áp dụng theo cơ chế vừa mô tả.

13. 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ả.