Định nghĩa tương thích Android 2.2

Bản quyền © 2010, Google Inc. Mọi quyền được bảo lưu.
khả năng tương thích@android.com

Mục lục

1. Giới thiệu
2. Tài nguyên
3. Phần mềm
4. Khả năng tương thích phần mềm tham khảo
5. Khả năng tương thích của bao bì ứng dụng
6. Khả năng tương thích đ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 phần cứng
9. Khả năng tương thích 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 tra 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 tra Bluetooth

1. Giới thiệu

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

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

Như được sử dụng trong tài liệu này, "người triển khai thiết bị" hay "người triển khai" là cá nhân hoặc tổ chức đang 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 như vậy.

Để được coi là tương thích với Android 2.2, việc triển khai thiết bị:

  • PHẢI đáp ứng các yêu cầu được trình bày trong Định nghĩa 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 tra khả năng tương thích Android (CTS) có sẵn tại thời điểm hoàn tất quá trình triển khai phần mềm của thiết bị. (CTS có sẵn như một phần của Dự án mã nguồn mở Android [ Tài nguyên, 2 ].) CTS kiểm tra nhiều, nhưng không phải tất cả, cá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ó nghĩa, mơ hồ hoặc không đầy đủ thì người triển khai thiết bị có trách nhiệm đảm bảo tính tương thích với các triển khai hiện có. Vì lý do này, Dự án mã nguồn mở Android [ Tài nguyên, 3 ] vừa là tài liệu tham khảo vừa là triển khai ưu tiên của Android. Những người triển khai thiết bị được khuyến khích thực hiện dựa trên mã nguồn "ngược dòng" có sẵn từ Dự án mã nguồn mở Android. Mặc dù theo giả thuyết, một số thành phần có thể được thay thế bằng các triển khai thay thế nhưng thực tế này không được khuyến khích vì việc vượt qua các bài kiểm tra CTS sẽ trở nên khó khăn hơn đáng kể. Trách nhiệm của người triển khai là đảm bảo khả năng tương thích hoàn toàn về mặt hành vi với việc triển khai Android tiêu chuẩn, bao gồm và ngoài Bộ kiểm tra khả năng tương thích. Cuối cùng, lưu ý rằng việc thay thế và sửa đổi thành phần nhất định bị cấm rõ ràng bởi tài liệu này.

2. Tài nguyên

  1. Mức 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 với Android: http://source.android.com/docs/compabilities/index.html
  3. Dự án mã nguồn mở Android: http://source.android.com/
  4. Định nghĩa và tài liệu API: http://developer.android.com/reference/packages.html
  5. Tham khảo Quyền của Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. 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ó sẵn trong mã nguồn Android, tại dalvik/docs
  11. AppWidget: 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. Chúc mừng: 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 công cụ tham khảo (dành cho adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  20. 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 tra khỉ: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Danh sách tính năng phần cứng của 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 tọa độ cảm biến: http://developer.android.com/reference/android/hardware/SensorEvent.html
  29. Tham khảo về Quyền và Bảo mật của Android: http://developer.android.com/guide/topics/security/security.html
  30. API Bluetooth: 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 hệt với thông tin trong tài liệu của SDK đó. Trong mọi trường hợp mà Định nghĩa tương thích này hoặc Bộ kiểm tra tương thích không đồng ý với tài liệu SDK thì tài liệu SDK đó được coi là có thẩm quyền. Bất kỳ chi tiết kỹ thuật nào đượ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 tương thích này.

3. Phần mềm

Nền tảng Android bao gồm một tập hợp các API được quản lý, một tập hợp các API gốc và một loạt các API được gọi là "mềm" chẳng hạn như hệ thống Intent và các API ứng dụng web. Phần này nêu chi tiết các API cứng và mềm không thể thiếu cho khả năng tương thích, cũng như một số hành vi giao diện người dùng và kỹ thuật 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 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 VM được quản lý. Việc triển khai thiết bị PHẢI cung cấp các hoạt động triển khai hoàn chỉnh, bao gồm tất cả các hành vi được ghi lại, của bất kỳ API được ghi lại nào được SDK Android 2.2 hiển thị [ Tài nguyên, 4 ].

Việc triển khai thiết bị KHÔNG PHẢI bỏ qua bất kỳ API được quản lý nào, thay đổi giao diện hoặc chữ ký API, đi chệch khỏi hành vi được ghi lại hoặc bao gồm các lệnh cấm, trừ khi được Định nghĩa tương thích này cho phép cụ thể.

3.2. Khả năng tương thích API mềm

Ngoài các API được quản lý từ Phần 3.1, Android còn bao gồm một API "mềm" chỉ dành cho thời gian chạy đáng kể, dưới dạng những thứ 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 nêu 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 trình bày 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 trong trang Tham chiếu quyền [ Tài nguyên, 5 ]. Lưu ý rằng Phần 10 liệt kê các yêu cầu bổ sung liên quan đến mô hình bảo mật Android.

3.2.2. Xây dựng thông số

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

Tham số Bình luận
android.os.Build.VERSION.RELEASE Phiên bản của hệ thống Android hiện đang hoạt động, ở đị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 hiện đang hoạt động, ở định dạng có thể truy cập được bằng mã ứng dụng của bên thứ ba. Đối với Android 2.2, trường này PHẢI có giá trị nguyên 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 hiện đang chạy, ở định dạng mà con người có thể đọc được. Giá trị này KHÔNG PHẢI được sử dụng lại cho các bản dựng khác nhau được cung cấp cho người dùng cuối. Cách sử dụng thông thường của trường này là để cho biết số bản dựng hoặc mã định danh thay đổi kiểm soát nguồn nào đã được sử dụng để tạo bản dựng. 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 nó KHÔNG PHẢI 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 bên trong cụ thể được thiết bị sử dụng, ở định dạng mà con người có thể đọc được. Việc sử dụng trường này có thể là để chỉ ra phiên bản cụ thể của bo mạch cấp nguồn cho thiết bị. 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 nó KHÔNG PHẢI 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., người đã sản xuất thiết bị, ở định dạng mà con người có thể đọc được. Việc sử dụng trường này có thể là để chỉ ra OEM và/hoặc nhà cung cấp dịch vụ đã bán thiết bị. 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 nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").
android.os.Build.DEVICE Giá trị được người triển khai thiết bị chọn nhằm xác định cấu hình cụ thể hoặc bản sửa đổi phần thân (đôi khi được gọi là "kiểu dáng công nghiệp") của thiết bị. 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 nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").
android.os.Build.FingerPRINT Một chuỗi xác định duy nhất bản dựng này. Nó NÊN có thể đọc được một cách hợp lý. Nó PHẢI làm theo mẫu này:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Ví dụ:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
Dấu vân tay KHÔNG PHẢI bao gồm các 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ì chúng PHẢI được thay thế trong dấu vân tay bản dựng bằng một ký tự khác, chẳng hạn như ký tự gạch dưới ("_").
android.os.Build.HOST Một chuỗi xác định duy nhất máy chủ chứa bản dựng được xây dựng trên đó, ở định dạng mà con người có thể đọc được. 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 nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").
android.os.Build.ID Mã định danh được 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 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 nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").
android.os.Build.MODEL Giá trị được người triển khai thiết bị chọn có chứa tên của thiết bị mà người dùng cuối đã biết. Đây PHẢI là 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 nào về định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").
android.os.Build.SẢN PHẨM Giá trị được người triển khai thiết bị chọn có chứa tên phát triển hoặc tên mã của thiết bị. PHẢI có thể đọc được nhưng không nhất thiết dành cho người dùng cuối xem. 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 nó KHÔNG PHẢI 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 rõ hơn bản dựng. Ví dụ: "không dấu, gỡ lỗi". Trường này KHÔNG PHẢI có giá trị rỗng hoặc chuỗi trống (""), nhưng một thẻ duy nhất (chẳng hạn như "phát hành") là được.
android.os.Build.TIME Một giá trị đại diện cho dấu thời gian khi quá trình xây dựng diễn 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 ba cấu hình thời gian chạy Android điển hình: "user", "userdebug" hoặc "eng".
android.os.Build.USER Tên hoặc ID 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 nào về định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI rỗng hoặc chuỗi trống ("").

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

Android sử dụng Ý định để đạt được sự tích hợp 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 các mẫu Ý định PHẢI được đáp ứng khi triển khai thiết bị. Khi nói "được vinh danh", điều đó có nghĩa là người triển khai thiết bị PHẢI cung cấp Hoạt động hoặc Dịch vụ Android chỉ định bộ lọc Ý định phù hợp, đồng thời liên kết và triển khai hành vi đúng cho từng mẫu Ý định được chỉ định.

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

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ổ liên lạc, máy nghe nhạc, v.v. Người triển khai thiết bị CÓ THỂ thay thế các ứng dụng này bằng các phiên bản thay thế.

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

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

  • Đồng hồ để bàn
  • Trình duyệt
  • Lịch
  • Máy tính
  • Máy ảnh
  • Liên lạc
  • E-mail
  • Phòng trưng bày
  • Tìm kiếm toàn cầu
  • Trình khởi chạy
  • LivePicker (nghĩa là ứng dụng 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 (AKA "Mms")
  • Âm nhạc
  • Điện thoại
  • Cài đặt
  • Máy ghi âm thanh

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

Đối với mọi Hoạt động hoặc Dịch vụ được xác định trong một trong các ứng dụng cốt lõi của hệ thống Android 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", việc triển khai thiết bị PHẢI bao gồm một thành phần cùng loại triển khai cùng một bộ lọc Ý định các mẫu làm ứ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 cốt lõi của hệ thống Android; tuy nhiên, nếu đúng như vậy thì việc triển khai thiết bị PHẢI hỗ trợ tất cả các mẫu Ý định được xác định bởi từng ứng dụng hệ thống Android cốt lõi đang được thay thế.

3.2.3.2. Ghi đè ý định

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

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

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

Lệnh cấm này tương tự như lệnh cấm được chỉ định cho các lớp ngôn ngữ Java trong Phần 3.6.

3.2.3.4. Ý định phát sóng

Các ứng dụng của bên thứ ba dựa vào nền tảng để phát một số Ý định nhất định nhằm thông báo cho họ 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 phát sóng Ý định phát sóng công khai để phản hồi các sự kiện hệ thống thích hợp. Ý định phát sóng được mô tả trong tài liệu SDK.

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

Mã được quản lý chạy trong Dalvik có thể gọi mã gốc được cung cấp trong tệp .apk của ứng dụng dưới dạng tệp ELF .so được biên dịch cho kiến ​​trúc phần cứng thiết bị phù hợp. Việc triển khai thiết bị PHẢI bao gồm hỗ trợ mã chạy trong môi trường được quản lý để gọi vào mã gốc, sử dụng ngữ nghĩa Giao diện gốc Java (JNI) tiêu chuẩn. Các API sau PHẢI có sẵn cho mã gốc:

  • 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ư được mô tả bên dưới

Việc triển khai thiết bị PHẢI hỗ trợ OpenGL ES 1.0. Các thiết bị thiếu khả 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ị NÊN triển khai OpenGL ES 1.1 nhiều như phần cứng thiết bị hỗ trợ. Việc triển khai thiết bị NÊN cung cấp triển khai cho OpenGL ES 2.0, nếu phần cứng có khả năng hoạt động 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 nhị phân (đối với kiến ​​trúc bộ xử lý nhất định) với các phiên bản được cung cấp trong Bionic bởi dự án Nguồn mở Android. Do việc triển khai Bionic không hoàn toàn tương thích với các triển khai khác, chẳng hạn như thư viện GNU C, nên người triển khai thiết bị NÊN sử dụng triển khai Android. Nếu người triển khai thiết bị sử dụng cách triển khai khác của các thư viện này, họ PHẢI đảm bảo khả năng tương thích về tiêu đề, 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 gốc (ABI) được thiết bị hỗ trợ, thông qua API android.os.Build.CPU_ABI . ABI PHẢI là một trong những 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 . Lưu ý rằng các bản phát hành bổ sung của Android NDK có thể hỗ trợ các ABI bổ sung.

Khả năng tương thích mã gốc là một thách thức. Vì lý do này, cần nhắc lại rằng những người triển khai thiết bị RẤT được khuyến khích sử dụng các triển khai ngược dòng của các thư viện được liệt kê ở trên để giúp đảm bảo tính tương thích.

3.4. Khả năng tương thích 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ọ, do đó việc triển khai WebView phải tương thích trên các triển khai Android. Tương tự, trải nghiệm web đầy đủ là trọng 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 phù hợp với phần mềm Android ngược dòng và PHẢI bao gồm trình duyệt hiện đại có hỗ trợ HTML5, như được mô tả bên dưới.

3.4.1. Khả năng tương thích của WebView

Việc triển khai Nguồn mở Android sử dụng công cụ kết xuất WebKit để triển khai android.webkit.WebView . Vì việc phát triển bộ thử nghiệm toàn diện cho hệ thống kết xuất web là không khả thi nên người triển khai thiết bị PHẢI sử dụng bản dựng WebKit ngược dòng cụ thể trong quá trình triển khai WebView. Đặc biệt:

  • Việc triển khai android.webkit.WebView của việc 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 dành cho Android 2.2. Bản dựng này bao gồm một bộ chức năng và bản sửa lỗi bảo mật cụ thể cho WebView. Người triển khai thiết bị CÓ THỂ bao gồm các tùy chỉnh để triển khai WebKit; tuy nhiên, mọi tùy chỉnh như vậy KHÔNG PHẢI thay đổi hành vi của WebView, bao gồm cả hành vi hiển thị.
  • Chuỗi tác nhân người dùng được WebView báo cáo PHẢI ở đị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 NÊN tham chiếu đến ngôn ngữ được đị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 bao gồm hỗ trợ cho cơ sở dữ liệu HTML5, bộ đệm ứng dụng và API định vị địa lý [ Tài nguyên, 9 ]. WebView PHẢI bao gồm hỗ trợ cho thẻ HTML5 <video> . API HTML5, giống như tất cả các API JavaScript, PHẢI bị tắt theo mặc định trong WebView, trừ khi nhà phát triển bật chúng một cách rõ ràng thông qua API Android thông thường.

3.4.2. tính tương thích của trình duyệt web

Việc triển khai thiết bị PHẢI bao gồm một ứng dụng Trình duyệt độc lập để duyệt web cho người dùng nói chung. Trình duyệt độc lập CÓ THỂ dựa trên 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 cung cấp, thành phần android.webkit.WebView được cung cấp cho ứng dụng bên thứ ba PHẢI dựa trên WebKit, như được mô tả trong Phần 3.4.1.

Việc triển khai CÓ THỂ gửi một chuỗi tác nhân người dùng tùy 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 ngược dòng hay ứng dụng thay thế của bên thứ ba) NÊN bao gồm hỗ trợ cho càng nhiều HTML5 [ Tài nguyên, 9 ] càng tốt. Tối thiểu, việc triển khai thiết bị PHẢI hỗ trợ định vị địa lý HTML5, bộ đệm ứng dụng và API cơ sở dữ liệu 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 hành vi 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 ngược dòng [ Tài nguyên, 3 ]. Một số lĩnh vực tương thích cụ thể là:

  • Thiết bị KHÔNG PHẢI thay đổi hành vi hoặc ý nghĩa của Ý định tiêu chuẩn
  • Thiết bị KHÔNG PHẢI 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, Nhà cung cấp nội dung, v.v.)
  • Thiết bị KHÔNG PHẢI thay đổi ngữ nghĩa của một quyền cụ thể

Danh sách trên không đầy đủ và trách nhiệm thuộc về 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 mã 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 khả năng tương thích (CTS) kiểm tra các phần quan trọng của nền tảng về khả năng tương thích hành vi, nhưng không phải tất cả. Trách nhiệm của người triển khai là đảm bảo khả năng tương thích về mặt hành vi với Dự án mã 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 được xác định bởi ngôn ngữ lập trình Java. Để đảm bảo khả năng tương thích với các ứng dụng của bên thứ ba, người triển khai thiết bị KHÔNG PHẢI thực hiện bất kỳ sửa đổi bị cấm nào (xem bên dưới) đối với các không gian tên gói này:

  • java.*
  • javax.*
  • mặt trời.*
  • android.*
  • com.android.*

Các sửa đổi bị cấm bao gồm:

  • Việc triển khai thiết bị KHÔNG PHẢI sửa đổi các API được hiển thị công khai trên nền tảng Android bằng cách thay đổi bất kỳ phương thức hoặc chữ ký lớp nào hoặc bằng cách xóa 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 API, nhưng những sửa đổi đó KHÔNG PHẢI ảnh hưởng đến hành vi đã nêu và chữ ký ngôn ngữ Java của bất kỳ API nào được hiển thị công khai.
  • Người triển khai thiết bị KHÔNG PHẢI thêm bất kỳ thành phần nào được hiển thị công khai (chẳng hạn như các lớp hoặc giao diện hoặc cá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ử được hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng điểm đánh dấu "@hide" 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 PHẢI hiển thị các API mới hoặc thay đổi các API hiện có trong các 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ỉ nội bộ, nhưng những sửa đổi đó KHÔNG PHẢI được quảng cáo hoặc tiết lộ cho các nhà phát triển.

Người triển khai thiết bị CÓ THỂ thêm các API tùy chỉnh, nhưng mọi API như vậy KHÔNG PHẢI nằm trong vùng tên do tổ chức khác sở hữu hoặc đề cập đến. Ví dụ: người triển khai thiết bị KHÔNG PHẢI 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 PHẢI thêm API vào vùng 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 ở trên (chẳng hạn như bằng cách thêm chức năng mới hữu ích vào API hiện có hoặc thêm API mới), thì người triển khai NÊN truy cập source.android.com và bắt đầu quá trình đóng góp các thay đổi và mã, theo thông tin trên trang web đó.

Lưu ý rằng các hạn chế ở trên tương ứng với các quy ước tiêu chuẩn để đặt tên API bằng ngôn ngữ lập trình Java; phần này chỉ nhằm mục đích củng cố các quy ước đó và làm cho chúng có tính ràng buộ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 máy ảo

Việc triển khai thiết bị PHẢI hỗ trợ đặc tả mã byte Dalvik Executable (DEX) đầy đủ và ngữ nghĩa của Máy ảo Dalvik [ Tài nguyên, 10 ].

Việc triển khai thiết bị với 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ị với màn hình được phân loại là mật độ 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. 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 số liệu này.

3.8. Khả năng tương thích 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 các nhà phát triển kết nối với giao diện người dùng 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 tiêu chuẩn này vào giao diện người dùng tùy chỉnh mà chúng phát triển, như được giải thích bên dưới.

3.8.1. Widget

Android xác định loại thành phần, API và vòng đời tương ứng cho phép các ứng dụng hiển thị "AppWidget" cho người dùng cuối [ Tài nguyên, 11 ]. Bản phát hành tham chiếu Nguồn mở Android bao gồm ứng dụng Trình khởi chạy bao gồm các thành phần giao diện người dùng cho phép người dùng thêm, xem và xóa AppWidget khỏi màn hình chính.

Người triển khai thiết bị CÓ THỂ thay thế một giải pháp thay thế cho Trình khởi chạy tham chiếu (tức là màn hình chính). Trình khởi chạy thay thế NÊN bao gồm hỗ trợ tích hợp cho AppWidget 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à xóa AppWidget trực tiếp trong Trình khởi chạy. Trình khởi 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 chúng bị bỏ qua, 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 khởi chạy để cho phép người dùng thêm, định cấu hình, xem và xóa AppWidget.

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 cung cấp hỗ trợ cho từng loại thông báo được xác định như vậy; cụ thể: âm thanh, độ rung, ánh sáng và thanh trạng thái.

Ngoài ra, việc 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 kiểu biểu tượng Thanh trạng thái [ Tài nguyên, 14 ]. Người 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 được cung cấp bởi việc triển khai Nguồn mở Android tham chiếu; tuy nhiên, các hệ thống thông báo thay thế đó PHẢI hỗ trợ các tài nguyên thông báo hiện có, như trên.

Android bao gồm các API [ Tài nguyên, 15 ] cho phép các nhà phát triển kết hợp tìm kiếm vào ứng dụng của họ và đưa dữ liệu ứng dụng của họ vào 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ị đề 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ìm kiếm trong ứng dụng của riêng họ và 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 duy nhất, được chia sẻ, trên toàn hệ thống, có khả năng đưa ra các đề xuất theo thời gian thực để phản hồi thông tin đầu vào của người dùng. 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ìm kiếm trong ứ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 của bên thứ ba thêm đề xuất vào hộp tìm kiếm khi nó chạy ở chế độ tìm kiếm chung. Nếu không có ứng dụng của 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ị các đề xuất và kết quả 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 NÊN bao gồm nút tìm kiếm chuyên dụng cứng hoặc mềm, có thể được sử dụng bất kỳ 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. nâng cốc chúc mừng

Các ứng dụng có thể sử dụng API "Toast" (được định nghĩa trong [ Tài nguyên, 16 ]) để hiển thị các chuỗi ngắn không theo 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 chúc mừng từ ứng dụng tới người dùng cuối theo cách có khả năng hiển thị cao.

3.8.5. Hình Nền Động

Android xác định loại thành phần, API và vòng đời tương ứng cho phép ứ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à hình động, mẫu hoặc hình ảnh tương tự với khả năng nhập liệu 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 nó có thể chạy tất cả các hình nền động, không có giới hạn về chức năng, ở tốc độ khung hình hợp lý và không ảnh hưởng xấu đến các ứng dụng khác. Nếu các giới hạn trong phần cứng khiến hình nền và/hoặc ứng dụng bị treo, trục trặc, tiêu tốn quá nhiều năng lượng CPU hoặc pin hoặc chạy ở tốc độ khung hình thấp không thể chấp nhận được thì phần cứng được coi là không có khả năng 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 đáng tin cậy 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 trong 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.

Việc triển khai thiết bị có khả năng chạy hình nền động một cách đáng tin cậy như được mô tả ở trên NÊN triển khai hình nền động. Việ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ư được mô tả ở trên KHÔNG PHẢI triển khai hình nền động.

4. Khả năng tương thích phần mềm tham khảo

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

  • Máy tính (có trong SDK)
  • Tàu đổ bộ mặt trăng (có trong SDK)
  • Các ứng dụng "Ứng dụng dành cho Android" [ Tài nguyên, 18 ].
  • Đảo bản sao (có sẵn trên Android Market; chỉ bắt buộc đối với việ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 tra từng mục menu (bao gồm tất cả các menu phụ) của từng ứng dụng kiểm tra khói này:

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

Mỗi trường hợp thử nghiệm trong các ứng dụng ở trên phải chạy chính xác trên việc triển khai thiết bị.

5. Khả năng tương thích bao bì ứng dụng

Việc triển khai thiết bị phải cài đặt và chạy Android ".APK" Tệp được tạo bởi công cụ "AAPT" có trong SDK chính thức của Android SDK [ Resources, 19 ].

Việc triển khai các thiết bị không được mở rộng .apk [ tài nguyên, 20 ], Android Manifest [ Tài nguyên, 21 ] hoặc Dalvik Bytecode [ Tài nguyên, 10 ] định dạng theo cách ngăn chặ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 . Người triển khai thiết bị nên sử dụng việc triển khai ngược dòng của Dalvik và hệ thống quản lý gói của 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 thực hiện đầy đủ tất cả các API đa phương tiện. Việc triển khai thiết bị phải bao gồm hỗ trợ cho tất cả các codec đa phương tiện được mô tả dưới đây và phải đáp ứng các hướng dẫn xử lý âm thanh được mô tả dưới đây.

6.1. Codec phương tiện truyền thông

Việc triển khai thiết bị phải hỗ trợ các codec đa phương tiện sau đây. Tất cả các codec này được cung cấp dưới dạng triển khai phần mềm trong triển khai Android ưa thích 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ỳ đại diện nào rằng các codec này không bị cản trở 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 được khuyến cáo rằng việc triển khai mã này, bao gồm trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ các chủ sở hữu bằng sáng chế có liên quan.

Âm thanh
Tên Mã hoá Bộ giải mã Chi tiết Định dạng tệp/container
AAC LC/LTP X Nội dung đơn/âm thanh nổi trong bất kỳ sự kết hợp của tỷ lệ bit tiêu chuẩn lên tới 160 kbps và tốc độ lấy mẫu từ 8 đến 48kHz 3GPP (.3GP) và MPEG-4 (.mp4, .m4a). Không hỗ trợ cho AAC RAW (.AAC)
He-AACV1 (AAC+) X
He-AACV2 (AAC+nâng cao) X
AMR-NB X X 4,75 đến 12,2 kbps được lấy mẫu @ 8kHz 3GPP (.3GP)
AMR-WB X 9 giá từ 6,60 kbit/s đến 23,85 kbit/s được lấy mẫu @ 16kHz 3GPP (.3GP)
MP3 X Hằng số mono/stereo 8-320kbps (CBR) hoặc tỷ lệ bit biến (VBR) Mp3 (.mp3)
MIDI X MIDI Loại 0 và 1. DLS Phiên bản 1 và 2. XMF và XMF di động. Hỗ trợ cho các định dạng nhạc chuông RTTTL/RTX, OTA và Imelody Loại 0 và 1 (.mid, .xmf, .mxmf). Cũng rtttl/rtx (.rtttl, .rtx), ota (.ota) và imelody (.imy)
OGG Vorbis X OGG (.OGG)
PCM X PCM tuyến tính 8- và 16 bit (tỷ lệ lên đến giới hạn phần cứng) Sóng (.wav)
Hình ảnh
JPEG X X cơ sở+tiến bộ
GIF X
PNG X X
BMP X
Băng hình
H.263 X X Các tệp 3GPP (.3gp)
H.264 X Các tệp 3GPP (.3GP) và MPEG-4 (.mp4)
MPEG4 Hồ sơ đơn giản X Tệp 3GPP (.3gp)

Lưu ý rằng bảng trên không liệt kê các yêu cầu bitrate cụ thể cho hầu hết các codec video. Lý do cho điều này 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ợ bitrates ánh xạ chính xác đến các bitrates cần thiết được chỉ định bởi các tiêu chuẩn liên quan. Thay vào đó, việc triển khai thiết bị sẽ hỗ trợ thực tế bitrate cao nhất trên phần cứng, theo các giới hạn được xác định bởi các thông số kỹ thuật.

6.2. Ghi âm

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

  • Xử lý giảm tiếng ồn, nếu có, nên bị vô hiệu hóa.
  • Kiểm soát đạt được tự động, nếu có, nên bị vô hiệu hóa.
  • Thiết bị nên thể hiện biên độ phẳng so với đặc tính tần số; Cụ thể, ± 3 dB, từ 100 Hz đến 4000 Hz
  • Độ nhạy đầu vào âm thanh phải được đặt sao cho nguồn công suất âm thanh 90 dB (SPL) ở mức 1000 Hz mang lại RMS 5000 cho các mẫu 16 bit.
  • Mức biên độ PCM nên theo dõi tuyến tính các thay đổi SPL đầu vào trên ít nhất một phạm vi 30 dB từ -18 dB đến +12 dB RE 90 dB SPL tại micrô.
  • Tổng độ méo điều hòa phải dưới 1% từ 100 Hz đến 4000 Hz ở mức đầu vào SPL 90 dB.

Lưu ý: Mặc dù các yêu cầu được nêu ở trên được nêu là "nên" đối với Android 2.2, định nghĩa tương thích cho phiên bản trong tương lai được lên kế hoạch thay đổi chúng thành "phải". Đó là, các yêu cầu này là tùy chọn trong Android 2.2 nhưng sẽ được yêu cầu bởi một phiên bản trong tương lai. Các thiết bị hiện tại và mới chạy Android 2.2 Android được khuyến khích rất mạnh mẽ để đáp ứng các yêu cầu này trong Android 2.2 hoặc chúng sẽ không thể đạt được khả năng tương thích Android khi nâng cấp lên phiên bản tương lai.

6.3. Độ trễ âm thanh

Độ trễ âm thanh được định nghĩa rộng rãi là khoảng thời gian giữa khi ứng dụng yêu cầu phát lại âm thanh hoặc hoạt động ghi âm và khi việc triển khai thiết bị thực sự bắt đầu hoạt động. Nhiều loại ứng dụng dựa vào độ trễ ngắn, để đạt được các hiệu ứng thời gian thực như hiệu ứng âm thanh hoặc giao tiếp VoIP. Việc triển khai thiết bị sẽ đáp ứng tất cả các yêu cầu về độ trễ âm thanh được nêu trong phần này.

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

  • "Độ trễ đầu ra lạnh" được xác định là khoảng thời gian giữa khi ứng dụng yêu cầu phát lại âm thanh và khi âm thanh bắt đầu phát, khi hệ thống âm thanh không hoạt động và được cung cấp trước khi yêu cầu
  • "Độ trễ đầu ra ấm" được định nghĩa là khoảng thời gian giữa khi ứng dụng yêu cầu phát lại âm thanh và khi âm thanh bắt đầu phát, khi hệ thống âm thanh được sử dụng gần đây nhưng hiện đang nhàn rỗi (đó là im lặng)
  • "Độ trễ đầu ra liên tục" được xác định là khoảng thời gian giữa khi ứng dụng phát hành mẫu sẽ được phát và khi loa phát âm thanh tương ứng, trong khi thiết bị hiện đang phát âm thanh trở lại
  • "Độ trễ đầu vào lạnh" được xác định là khoảng thời gian giữa khi ứng dụng yêu cầu ghi âm và khi mẫu đầu tiên được gửi đến ứng dụng thông qua cuộc gọi lại, khi hệ thống âm thanh và micrô đã không hoạt động và được cung cấp trước
  • "Độ trễ đầu vào liên tục" được xác định là khi âm thanh xung quanh xảy ra và khi mẫu tương ứng với âm thanh đó được chuyển đến ứng dụng ghi âm thông qua cuộc gọi lại của nó, trong khi thiết bị ở chế độ ghi

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

  • Độ trễ sản lượng lạnh từ 100 mili giây hoặc ít hơn
  • Độ trễ sản lượng ấm từ 10 mili giây hoặc ít hơn
  • Độ trễ đầu ra liên tục từ 45 mili giây hoặc ít hơn
  • Độ trễ đầu vào lạnh từ 100 mili giây hoặc ít hơn
  • Độ trễ đầu vào liên tục từ 50 mili giây hoặc ít hơn

Lưu ý: Mặc dù các yêu cầu được nêu ở trên được nêu là "nên" đối với Android 2.2, định nghĩa tương thích cho phiên bản trong tương lai được lên kế hoạch thay đổi chúng thành "phải". Đó là, các yêu cầu này là tùy chọn trong Android 2.2 nhưng sẽ được yêu cầu bởi một phiên bản trong tương lai. Các thiết bị hiện tại và mới chạy Android 2.2 Android được khuyến khích rất mạnh mẽ để đáp ứng các yêu cầu này trong Android 2.2 hoặc chúng sẽ không thể đạt được khả năng tương thích Android khi nâng cấp lên phiên bản tương lai.

7. Khả năng tương thích công cụ nhà phát triển

Việc triển khai thiết bị phải hỗ trợ các công cụ nhà phát triển Android được cung cấp trong SDK Android. Cụ thể, các thiết bị tương thích Android phải tương thích với:

  • Cầu gỡ lỗi Android (được 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 chức năng adb như được ghi lại trong SDK Android. Trình nền adb phía thiết bị phải không hoạt động theo mặc định, nhưng phải có một cơ chế có thể truy cập được người dùng để bật cầu Debug Android.
  • Dịch vụ giám sát gỡ lỗi Dalvik (được gọi là DDMS) [ Tài nguyên, 19 ]
    Việc triển khai thiết bị phải hỗ trợ tất cả các tính năng ddms như được ghi lại trong SDK Android. Vì ddms sử dụng adb , hỗ trợ cho ddms nên 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 Debug Android, như trên.
  • Khỉ [ Tài nguyên, 22 ]
    Việc triển khai thiết bị phải bao gồm khung khỉ và cung cấp cho các ứng dụng để sử dụng.

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

Android nhằm hỗ trợ người triển khai thiết bị tạo ra các yếu tố và cấu hình hình thức sáng tạo. Đồng thời các 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ả cá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ả các thiết bị tương thích Android 2.2 phải hỗ trợ.

Nếu một thiết bị bao gồm một thành phần phần cứng cụ thể có API tương ứng cho các nhà phát triển bên thứ ba, việc triển khai thiết bị phải triển khai API đó như được định nghĩa trong tài liệu SDK Android. Nếu API trong SDK tương tác với thành phần phần cứng được nêu là tùy chọn và việc triển khai thiết bị không sở hữu thành phần đó:

  • Định nghĩa lớp cho API của thành phần phải có mặt
  • Các hành vi của API phải được thực hiện dưới dạng không có thời gian hợp lý
  • Các phương thức API phải trả về các giá trị null khi được cho phép bởi tài liệu SDK
  • Các phương thức API phải trả về việc không thực hiện các lớp trong đó các giá trị null không được phép bởi tài liệu SDK

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

8.1. Trưng bày

Android 2.2 bao gồm các cơ sở thực hiện các hoạt động mở rộng và chuyển đổi tự động nhất định 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 hợp lý trên nhiều cấu hình phần cứng [ Tài nguyên, 24 ]. Các thiết bị phải thực hiện đúng các hành vi này, như chi tiết trong phần này.

Đối với Android 2.2, đây là những cấu hình hiển thị 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 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 Bé 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 được chỉ định cho các ứng dụng thông qua android.content.res.Configuration [ Tài nguyên, lớp 24 ].

Một số gói .APK có các biểu hiện không xác định chúng là hỗ trợ một phạm vi mật độ cụ thể. Khi chạy các ứng dụng như vậy, các ràng buộc sau áp dụng:

  • Việc triển khai thiết bị phải giải thích các tài nguyên trong một .APK thiếu vòng loại mật độ là mặc định thành "Medium" (được gọi là "MDPI" trong tài liệu SDK.)
  • Khi hoạt động trên màn hình mật độ "thấp", việc triển khai thiết bị phải thu nhỏ tài sản trung bình/MDPI theo hệ số 0,75.
  • Khi hoạt động trên màn hình mật độ "cao", việc triển khai thiết bị phải tăng quy mô tài sản trung bình/MDPI theo hệ số 1,5.
  • Việc triển khai thiết bị không được mở rộng quy mô tài sản trong phạm vi mật độ và phải mở rộng các tài sản bằng chính xác các yếu tố này giữa các phạm vi mật độ.

8.1.2. Cấu hình hiển thị 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 tiêu chuẩn được liệt kê trong Phần 8.1.1 yêu cầu xem xét thêm và làm việc để tương thích. Người thực hiện thiết bị phải liên hệ với nhóm tương thích Android như được mô tả trong Phần 13 để có được phân loại cho hệ số, mật độ và tỷ lệ kích thước màn hình. Khi được cung cấp thông tin này, việc triển khai thiết bị phải thực hiện chúng theo quy định.

Lưu ý rằng một số cấu hình hiển thị (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 đó, người triển khai thiết bị được khuyến khích 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. Hiển thị số liệu

Việc triển khai thiết bị phải báo cáo các giá trị chính xác cho tất cả các số liệu 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 được tuyên bố

Các ứng dụng có thể cho biết kích thước màn hình nào mà chú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 tôn trọng chính xác hỗ trợ đã nêu của các ứng dụng cho các màn hình nhỏ, vừa và lớn, như được mô tả trong tài liệu SDK Android.

8.2. Bàn phím

Thực hiện thiết bị:

  • Phải bao gồm hỗ trợ cho Khung quản lý đầu vào (cho phép các nhà phát triển bên thứ ba tạo ra các công cụ quản lý đầu vào - tức là bàn phím mềm) như chi tiết tại nhà phát triển.android.com
  • Phải cung cấp ít nhất một triển khai bàn phím mềm (bất kể có bàn phím cứng có mặt hay không)
  • Có thể bao gồm các triển khai bàn phím mềm bổ sung
  • Có thể bao gồm bàn phím phần cứng
  • Không được bao gồm một 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 ] (nghĩa là QWERTY hoặc 12 KEY)

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

Thực hiện thiết bị:

  • Có thể bỏ qua một tùy chọn điều hướng không chạm (nghĩa là, có thể bỏ qua một đường đua, D-pad hoặc bánh xe)
  • Phải báo cáo giá trị chính xác cho android.content.res.Configuration.navigation [ Tài nguyên, 25 ]

8.4. Định hướng màn hình

Các thiết bị tương thích phải hỗ trợ định hướng động theo các ứng dụng để định hướng màn hình chân dung hoặc cảnh quan. Đó là, thiết bị phải tôn trọng yêu cầu của ứng dụng đối với một hướng màn hình cụ thể. Việc triển khai thiết bị có thể chọn định hướng chân dung hoặc cảnh quan làm mặc định.

Các thiết bị phải báo cáo giá trị chính xác cho định 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 API khác.

8,5. Đầu vào màn hình cảm ứng

Thực hiệ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 độc lập hoàn toàn, nếu màn hình cảm ứng hỗ trợ nhiều gợi ý

8.6. USB

Thực hiện thiết bị:

  • Phải triển khai ứng dụng khách USB, có thể kết nối với máy chủ USB với cổng USB-A tiêu chuẩn
  • Phải triển khai Cầu gỡ lỗi Android qua USB (như được mô tả trong Phần 7)
  • Phải triển khai đặc tả lưu trữ lớn USB, để cho phép một máy chủ kết nối với thiết bị để truy cập vào nội dung của khối lượng /sdcard
  • Nên sử dụng hệ số biểu mẫu Micro USB ở phía thiết bị
  • Có thể bao gồm một cổng không chuẩn ở phía thiết bị, nhưng nếu vậy phải vận chuyển với cáp có khả năng kết nối pinout tùy chỉnh với cổng USB-A tiêu chuẩn
  • Nên thực hiện hỗ trợ cho đặc tả lưu trữ khối lượng lớn USB (để có thể truy cập lưu trữ có thể tháo rời hoặc cố định trên thiết bị từ PC máy chủ)

8.7. Phím điều hướng

Các chức năng nhà, thực đơn và lưng là rất cần thiết cho mô hình điều hướng 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. Các chức năng này nên được thực hiện thông qua các nút chuyên dụng. Chúng có thể được triển khai bằng phần mềm, cử chỉ, bảng cảm ứng, v.v., nhưng nếu vậy chúng phải luôn luôn có thể truy cập và không bị che khuất hoặc can thiệp vào khu vực hiển thị ứng dụng có sẵn.

Người thực hiện thiết bị cũng nên cung cấp một khóa tìm kiếm chuyên dụng. Người triển khai thiết bị cũng có thể cung cấp các khóa gửi và kết thúc cho các 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 hỗ trợ cho mạng dữ liệu tốc độ cao không dây. Cụ thể, việc triển khai thiết bị phải bao gồm hỗ trợ cho ít nhất một tiêu chuẩn dữ liệu không dây có khả năng 200kbit/giây hoặc lớn hơ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 việc triển khai thiết bị bao gồm một phương thức cụ thể mà SDK Android bao gồm API (nghĩa là WiFi, GSM hoặc CDMA), việc triển khai phải hỗ trợ API.

Các thiết bị có thể triển khai nhiều hơn một dạng kết nối dữ liệu không dây. Các thiết bị có thể triển khai kết nối dữ liệu có dây (như Ethernet), nhưng dù sao cũng phải bao gồm ít nhất một dạng kết nối không dây, như trên.

8,9. Máy ảnh

Việc triển khai thiết bị phải bao gồm một camera phía sau. Camera phía sau đi kèm:

  • Phải có độ phân giải ít nhất 2 megapixel
  • Nên có phần cứng tự động lấy nét hoặc lấy nét tự động phần mềm được triển khai trong trình điều khiển camera (trong suốt cho phần mềm ứng dụng)
  • Có thể có phần cứng tập trung cố định hoặc EDOF (độ sâu mở rộng của trường)
  • Có thể bao gồm một đèn flash. Nếu camera bao gồm đèn flash, đèn flash không được thắp sáng trong khi Android.hardware.camera.previewCallback đã được đăng ký trên bề mặt xem trước camera, trừ khi ứng dụng đã kích hoạt rõ ràng flash bằng cách kích hoạt các thuộc tính FLASH_MODE_AUTO hoặc FLASH_MODE_ON Camera.Parameters đối tượng. Lưu ý rằng ràng buộc này không áp dụng cho ứng dụng camera hệ thống tích hợp của thiết bị, mà chỉ cho các ứng dụng của bên thứ ba bằng Camera.PreviewCallback .

Việc triển khai thiết bị phải thực hiện các hành vi sau đây cho 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.parameter.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 các cuộc gọi ứng dụng.
  2. Nếu một ứng dụng đăng ký 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, dữ liệu trong byte [] được chuyển vào onpreviewframe () (Đây là định dạng được sử dụng nguyên bản bởi họ phần cứng 7K.) Đó là, NV21 phải là mặc định.

Việc triển khai thiết bị phải triển khai API camera đầy đủ có trong tài liệu SDK Android 2.2 [ Tài nguyên, 27 ]), bất kể thiết bị có bao gồm tự động lấy nét phần cứng hay các khả năng khác. Chẳng hạn, các camera thiếu tự động lấy nét vẫn phải gọi bất kỳ phiên bản android.hardware.Camera.AutoFocusCallback đã đăng ký nào (mặc dù điều này không liên quan đến camera không tập trung.)

Việc triển khai thiết bị phải nhận ra và tôn vinh 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ếu phần cứng thiết bị không hỗ trợ một tính năng, API phải hoạt động như được ghi lại. Ngược lại, việc triển khai thiết bị không được tôn vinh hoặc nhận ra các hằng số chuỗi được truyền cho phương thức android.hardware.Camera.setParameters() khác với các phương thức được ghi là hằng số trên android.hardware.Camera.Parameters . Nghĩa là, việc triển khai thiết bị phải hỗ trợ tất cả các tham số camera tiêu chuẩn nếu phần cứng cho phép và không được hỗ trợ các loại tham số camera tùy chỉnh.

Việc triển khai thiết bị có thể bao gồm một camera phía trước. Tuy nhiên, nếu việc triển khai thiết bị bao gồm camera phía trước, API camera như được triển khai trên thiết bị không được sử dụng camera phía trước theo mặc định. Đó là, API camera trong Android 2.2 chỉ dành cho camera phía sau và việc triển khai thiết bị không được sử dụng lại hoặc quá tải API để hành động trên camera phía trước, nếu có. Lưu ý rằng bất kỳ API tùy chỉnh nào được thêm bởi người triển khai thiết bị để hỗ trợ các camera phía trước phải tuân thủ các phần 3.5 và 3.6; Chẳng hạn, nếu một lớp con android.hardware.Camera hoặc Camera.Parameters . Lưu ý rằng việc bao gồm một camera phía trước không đáp ứng yêu cầu rằng các thiết bị bao gồm camera phía 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 cung cấp các sự kiện ở mức 50 Hz trở lên. Hệ thống tọa độ được sử dụng bởi gia tốc kế phải tuân thủ hệ tọa độ cảm biến Android như 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 cung cấp các sự kiện từ 10 Hz trở lên. Hệ thống tọa độ được sử dụng bởi la bàn phải tuân thủ hệ tọa độ cảm biến Android như được định nghĩa 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áy thu GPS và nên bao gồm một số hình thức kỹ thuật "GPS được hỗ trợ" để giảm thiểu thời gian khóa 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 bao gồm phần cứng điện thoại. Đó là, Android 2.2 tương thích với các thiết bị không phải là điện thoại. Tuy nhiên, nếu việc triển khai thiết bị bao gồm điện thoại GSM hoặc CDMA, nó phải thực hiện hỗ trợ đầy đủ cho API cho công nghệ đó. Việc triển khai thiết bị không bao gồm phần cứng điện thoại phải triển khai các API đầy đủ dưới dạng không có.

Xem thêm Phần 8.8, Mạng dữ liệu không dây.

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

Việc triển khai thiết bị phải có sẵn ít nhất 92MB bộ nhớ cho kernel và không gian người dùng. 92MB phải bổ sung cho bất kỳ bộ nhớ nào dành riêng cho các thành phần phần cứng như radio, bộ nhớ, v.v. không nằm dưới sự kiểm soát của kernel.

Việc triển khai thiết bị phải có ít nhất 150 MB dung lượng lưu trữ không bay hơi có sẵn cho dữ liệu người dùng. Đó là, phân vùng /data phải có ít nhất 150MB.

Ngoài các yêu cầu ở trên, việc triển khai thiết bị nên có ít nhất 128 MB bộ nhớ có sẵn cho kernel và không gian người dùng, ngoài bất kỳ bộ nhớ nào dành riêng cho các thành phần phần cứng không nằm dưới sự kiểm soát của kernel. Việc triển khai thiết bị phải có ít nhất 1GB dung lượng lưu trữ không bay hơi cho dữ liệu người dùng. Lưu ý rằng các yêu cầu cao hơn này được lên kế hoạch để trở thành mức tối thiểu khó khăn trong phiên bản Android trong tương lai. Việc triển khai thiết bị được khuyến khích mạnh mẽ để đáp ứng các yêu cầu này ngay bây giờ, nếu không chúng có thể không đủ điều kiện để tương thích cho phiên bản Android trong tương lai.

8.15. Ứng dụng lưu trữ chia sẻ

Việc triển khai thiết bị phải cung cấp lưu trữ chung cho các ứng dụng. Bộ lưu trữ được chia sẻ được cung cấp phải có kích thước ít nhất 2GB.

Việc triển khai thiết bị phải được cấu hình với bộ lưu trữ được chia sẻ được gắn theo mặc định, "Out of the Box". Nếu lưu trữ được chia sẻ không được gắn trên đường dẫn /sdcard Linux, thì thiết bị phải bao gồm một liên kết tượng trưng Linux từ /sdcard đến điểm gắn kết thực tế.

Việc triển khai thiết bị phải thực thi như đã ghi lại sự cho phép android.permission.WRITE_EXTERNAL_STORAGE trên bộ lưu trữ được chia sẻ này. Lưu trữ được chia sẻ phải được ghi bởi bất kỳ ứng dụng nào có được sự cho phép đó.

Việc triển khai thiết bị có thể có phần cứng để lưu trữ có thể tháo rời có thể truy cập người dùng, chẳng hạn như thẻ kỹ thuật số an toàn. Ngoài ra, việc triển khai thiết bị có thể phân bổ lưu trữ nội bộ (không thể tháo rời) dưới dạng lưu trữ được chia sẻ cho các ứng dụng.

Bất kể hình thức lưu trữ chung được sử dụng, lưu trữ chung phải triển khai lưu trữ lớn USB, như được mô tả trong Phần 8.6. Khi được vận chuyển ra khỏi hộp, bộ lưu trữ được chia sẻ phải được gắn với hệ thống tập tin chất béo.

Đó là minh họa để xem xét hai ví dụ phổ biến. Nếu việc triển khai thiết bị bao gồm khe cắm thẻ SD để đáp ứng yêu cầu lưu trữ được chia sẻ, kích thước thẻ SD được định dạng chất béo 2GB phải được bao gồm trong thiết bị như được bán cho người dùng và phải được gắn theo mặc định. Cách khác, nếu việc triển khai thiết bị sử dụng lưu trữ cố định nội bộ để đáp ứng yêu cầu này, thì lưu trữ đó phải có kích thước 2GB hoặc lớn hơn, được định dạng là chất béo và được gắn trên /sdcard (hoặc /sdcard phải là một liên kết tượng trưng đến vị trí vật lý nếu nó được gắn ở nơi khác.)

Việc triển khai thiết bị bao gồm nhiều đường dẫn lưu trữ được chia sẻ (chẳng hạn như cả khe cắm thẻ SD và bộ lưu trữ nội bộ được chia sẻ) sẽ sửa đổi các ứng dụng cốt lõi như máy quét phương tiện và contentProvider để hỗ trợ một cách rõ ràng ở cả hai vị trí.

8.16. Bluetooth

Việc triển khai thiết bị phải bao gồm bộ thu phát Bluetooth. Việc triển khai thiết bị phải cho phép API Bluetooth dựa trên RFCOMM như được mô tả trong tài liệu SDK [ Tài nguyên, 30 ]. Việc triển khai thiết bị nên thực hiện các cấu hình Bluetooth có liên quan, chẳng hạn như A2DP, AVRCP, OBEX, v.v. khi thích hợp cho thiết bị.

Bộ kiểm tra khả năng tương thích bao gồm các trường hợp bao gồm hoạt động cơ bản của API Bluetooth Android RFComm. Tuy nhiên, vì Bluetooth là giao thức truyền thông giữa các thiết bị, nên nó không thể được kiểm tra đầy đủ bằng các thử nghiệm đơ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 thử nghiệm Bluetooth do con người mô tả trong Phụ lục A.

9. Khả năng tương thích 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à cho phép trải nghiệm ứng dụng nhất quán cho người tiêu dùng. Việc triển khai tương thích phải đảm bảo không chỉ các ứng dụng chỉ cần chạy chính xác trên thiết bị mà còn làm như vậy với hiệu suất hợp lý và trải nghiệm người dùng tốt tổng thể. Việc triển khai thiết bị phải đáp ứng các số liệu hiệu suất chính của thiết bị tương thích Android 2.2 được xác định trong bảng dưới đây:

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

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

Việc triển khai thiết bị phải triển khai mô hình bảo mật phù hợp với mô hình bảo mật nền tảng Android như được định nghĩa trong tài liệu tham khảo bảo mật và quyền trong API [ Tài nguyên, 29 ] trong tài liệu Nhà phát triển Android. Việc triển khai thiết bị phải hỗ trợ cài đặt các ứng dụng tự ký mà không yêu cầu bất kỳ quyền/chứng chỉ bổ sung nào từ bất kỳ bên/cơ quan thứ ba nào. Cụ thể, các thiết bị tương thích phải hỗ trợ các cơ chế bảo mật được mô tả trong các phần phụ sau.

10.1. Quyền

Việc triển khai thiết bị phải hỗ trợ mô hình quyền Android như được định nghĩa trong tài liệu nhà phát triển Android [ Tài nguyên, 29 ]. Cụ thể, việc triển khai phải thực thi từng quyền được xác định như được mô tả trong tài liệu SDK; Không có quyền có thể được bỏ qua, thay đổi hoặc bỏ qua. Việc triển khai có thể thêm các quyền bổ sung, miễn là chuỗi ID quyền mới không có trong Android.* Không gian tên.

10.2. Uid và quá trình cô lập

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 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 ID người dùng Linux giống nhau, miễn là các ứng dụng được ký và xây dựng đúng, như được định nghĩa trong tham chiếu bảo mật và quyền [ Tài nguyên, 29 ].

10.3. Quyền hệ thống tập tin

Việc triển khai thiết bị phải hỗ trợ mô hình quyền truy cập tệp Android như được định nghĩa theo định nghĩa trong tham chiếu bảo mật và quyền [ 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 hiện các ứng dụng bằng một số phần mềm hoặc công nghệ khác so vớ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 thỏa hiệp mô hình bảo mật Android hoặc bảo mật của các ứng dụng Android đã cài đặt, như được mô tả trong phần này.

Runtimes thay thế phải là các ứng dụng Android và tuân thủ mô hình bảo mật Android tiêu chuẩn, như được mô tả ở nơi khác trong Phần 10.

Không được cấp quyền truy cập vào các tài nguyên được bảo vệ bởi các quyền không được yêu cầu trong tệp AndroidManifest.xml của RunTime thông qua cơ chế <uses-permission> .

Runtimes 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ởi các quyền Android bị giới hạn cho các ứng dụng hệ thống.

Runtimes thay thế phải tuân theo mô hình hộp cát Android. Đặc biệt:

  • Runtimes thay thế nên cài đặt các ứng dụng thông qua Packagemanager vào các hộp cát Android riêng biệt (nghĩa là ID người dùng Linux, v.v.)
  • Runtimes thay thế có thể cung cấp một hộp cát Android duy nhất được chia sẻ bởi tất cả các ứng dụng bằng thời gian chạy thay thế.
  • Runtimes thay thế và các ứng dụng được cài đặt bằ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 cài đặt trên thiết bị, ngoại trừ thông qua các cơ chế Android tiêu chuẩn của ID người dùng được chia sẻ và chứng chỉ ký
  • Runtimes thay thế không được khởi chạy với, 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 khởi chạy thay thế, được cấp hoặc cấp cho các ứng dụng khác bất kỳ đặc quyền nào của Superuser (root) hoặc của bất kỳ ID người dùng nào khác.

Các tệp .APK của Runtimes thay thế có thể được bao gồm trong hình ảnh hệ thống của việc triển khai thiết bị, nhưng phải được ký với khóa khác biệt với khóa được sử dụng để ký các ứng dụng khác có trong triển khai thiết bị.

Khi cài đặt các ứng dụng, Runtimes thay thế phải có được sự đồng ý của người dùng đối với các quyền Android được sử dụng bởi ứng dụng. Đó là, nếu một ứng dụng cần sử dụng tài nguyên thiết bị có quyền Android tương ứng (như camera, GPS, v.v.), 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 tài nguyên đó . Nếu môi trường thời gian chạy không ghi lại các khả năng ứng dụng theo cách này, môi trường thời gian chạy phải liệt kê tất cả các quyền được giữ bởi chính thời gian chạy khi cài đặt bất kỳ ứng dụng nào bằng thời gian chạy đó.

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

Việc triển khai thiết bị phải vượt qua Bộ kiểm tra khả năng tương thích Android (CTS) [ Tài nguyên, 2 ] có sẵn từ dự án nguồn mở Android, sử dụng phần mềm vận chuyển cuối cùng trên thiết bị. Ngoài ra, người triển khai thiết bị nên sử dụng việ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 các trường hợp mơ hồ trong CTS và cho bất kỳ sự tái tạo nào của 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 tế. Giống như bất kỳ phần mềm nào, CTS có thể chứa các lỗi. CTS sẽ được phiên bản độc lập với định nghĩa 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 phần mềm thiết bị được hoàn thành.

12. Phần mềm cập nhật

Việc 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ế không cần phải thực hiện nâng cấp "trực tiếp" - nghĩa là, có thể yêu cầu khởi động lại thiết bị.

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

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

Cơ chế cập nhật được sử dụng phải hỗ trợ cập nhật mà không cần xóa dữ liệu người dùng. Lưu ý rằng phần mềm Android ngược dòng bao gồm một cơ chế cập nhật đáp ứng yêu cầu này.

Nếu một lỗi được tìm thấy trong việc triển khai thiết bị sau khi nó được phát hành nhưng trong vòng đời sản phẩm hợp lý của nó đượ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 cạnh, người thực hiện thiết bị phải sửa lỗi thông qua phần mềm Cập nhật có sẵn có thể được áp dụng theo cơ chế vừa được mô tả.

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

Bạn có thể liên hệ với các tác giả tài liệu tại Testability@android.com để làm rõ và đưa ra bất kỳ vấn đề nào mà bạn nghĩ rằng tài liệu không bao gồm.

Phụ lục A - Quy trình kiểm tra Bluetooth

Bộ kiểm tra khả năng tương thích bao gồm các trường hợp bao gồm hoạt động cơ bản của API Bluetooth Android RFComm. Tuy nhiên, vì Bluetooth là giao thức truyền thông giữa các thiết bị, nên nó không thể được kiểm tra đầy đủ bằng các thử nghiệm đơn vị chạy trên một thiết bị. Consequently, device implementations MUST also pass the human-driven Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.