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

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

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

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.1. "Triển khai thiết bị" hoặc "triển khai" là giải pháp phần cứng/phần mềm được phát triển như vậy.

Để được coi là tương thích với Android 2.1, 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
  • Mức yêu cầu của IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • Tổng quan về chương trình tương thích với Android: http://source.android.com/compatibility/index.html
  • Dự án mã nguồn mở Android: http: //source.android.com/
  • Định nghĩa và tài liệu API: http://developer.android.com/reference/packages.html
  • Tham chiếu về quyền của Android: http://developer.android.com/reference/android/Manifest.permission. html
  • Tham chiếu android.os.Build: http://developer.android.com/reference/android/os/Build.html
  • Chuỗi phiên bản được phép của Android 2.1: http://source.android.com/docs/compatibility/2.1/versions .html
  • lớp android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ multipage/
  • Đặc tả máy ảo Dalvik: có sẵn trong mã nguồn Android, tại dalvik/docs
    •
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Thông báo: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Tài nguyên ứng dụng: http://code.google.com/android/reference/available-resources.html
  • Hướng dẫn về kiểu biểu tượng trên Thanh trạng thái: http://developer.android.com/ hướng dẫn/practices/ui_guideline /icon_design.html#statusbarstructure
  • Trình quản lý tìm kiếm: http://developer.android.com/reference/android/app/SearchManager.html
  • Chúc mừng: http://developer.android.com/reference/android/widget /Toast.html
  • Hình nền động: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android
  • Tham khảo tài liệu về công cụ (dành cho adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Mô tả tệp apk Android: http://developer.android.com/guide/topics/fundamentals .html
  • Tệp kê khai: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Công cụ kiểm tra khỉ: https://developer.android.com/studio/test/other-testing-tools/ khỉ
  • Hỗ trợ nhiều màn hình: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • Không gian tọa độ cảm biến: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Tham chiếu về quyền và bảo mật của Android: http://developer.android.com/guide/topics/security/security.html
  • 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.1 và sẽ có chức năng giống hệt với thông tin trong tài liệu của SDK đó . Trong mọi trường hợp mà Định nghĩa 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" 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.1 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 ứng dụng thời gian biên dịch. 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.1. 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. 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 ] 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ố Nhận xét
    android.os.Build.VERSION.RELEASE Phiên bản của hệ thống Android hiện đang chạy, ở đị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 chạy, ở đị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.1, trường này PHẢI có giá trị nguyên 7.
    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 thực thi, ở đị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 chuyển đến 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ị do người triển khai thiết bị chọn nhằm xác định cấu hình hoặc bản sửa đổi cụ thể của phần thân (đô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 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.1-update1/ERC77/3359:userdebug/test-keys
    Dấu vân tay KHÔNG PHẢI bao gồm khoảng trắng. Nếu các trường khác có trong mẫu ở trên có khoảng trắng, chúng NÊN được thay thế bằng ký tự dấu gạch dưới ASCII ("_") trong dấu vân tay.
    android.os.Build.HOST Một chuỗi xác định duy nhất máy chủ mà 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 Một 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.PRODVEL Giá trị do 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ị biểu thị 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 của Ý đị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
    • Camera
      • Danh
    • bạ
    • Thư
      • viện
    • email
    • Trình khởi chạy
    • tìm kiếm toàn cầu
    • LivePicker (nghĩa 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 (AKA "Mms")
    • Nhạc
    • Cài đặt
    • điện thoại
    • SoundRecorder

    Các ứng dụng hệ thống Android cốt lõi bao gồm các 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 xác định trong các ứng dụng hệ thống cốt lõi được ghi đè bởi các ứng dụng của bên thứ ba. 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.

    Lưu ý: phần này đã được sửa đổi bởi Erratum EX6580.

    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

    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 API 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. Việc triển khai Nguồn mở Android sử dụng công cụ kết xuất WebKit để triển khai WebView.

    Vì việc phát triển bộ thử nghiệm toàn diện cho trình duyệ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ụ thể:

    • WebView PHẢI sử dụng bản dựng WebKit 530.17 từ cây Nguồn mở Android ngược dòng dành cho Android 2.1. 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.
    • 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/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • 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 cho mã quốc gia và ngôn ngữ, đồng thời NÊN tham khảo 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
    Việc triển khai
      • android.os.Build.ID

    CÓ THỂ gửi 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. Hơn nữa, Trình duyệt độc lập CÓ THỂ dựa trên công nghệ trình duyệt thay thế (chẳng hạn như Firefox, Opera, v.v.). Tuy nhiên, ngay cả khi một ứng dụng Trình duyệt thay thế được xuất xưởng, thành phần WebView được cung cấp cho các ứng dụng của bên thứ ba PHẢI dựa trên WebKit, như trên.

    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> ở một số dạng. Ứ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) PHẢI bao gồm hỗ trợ cho các tính năng HTML5 tương tự vừa được liệt kê cho WebView.

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

    Các 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 việc 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 một Ý đị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, ContentProvider, v.v.)
    • Thiết bị KHÔNG PHẢI KHÔNG thay đổ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ề những người triển khai thiết bị để đảm bảo tính 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.*
    • sun.*
    • android.*
    • com.android.*

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

    • Việc triển khai thiết bị PHẢI KHÔNG 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.

    Việc triển khai thiết bị

    tương thích với máy ảo

    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ị PHẢI định cấu hình Dalvik để phân bổ ít nhất 16 MB bộ nhớ cho mỗi ứng dụng trên các thiết bị có màn hình được phân loại là mật độ trung bình hoặc thấp. Việc triển khai thiết bị PHẢI định cấu hình Dalvik để phân bổ ít nhất 24 MB bộ nhớ cho mỗi ứng dụng trên các thiết bị có màn hình được phân loại là mật độ cao. 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 nhưng không bắt buộc.

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

    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à hiển thị 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.

    Ứng dụng

    Toasts

    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. Tham chiếu Khả năng tương thích của phần mềm

    Người triển khai thiết bị PHẢI kiểm tra khả năng tương thích khi 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)
    • Lunar Lander (có trong SDK)
    • Ứng dụng "Ứng dụng dành cho Android" [ Tài nguyên, 18 ].

    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 thử nghiệm 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 thiết bị thực hiện.

    5. Khả năng tương thích với bao bì ứ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 được tạo bởi công cụ "aapt" có trong SDK Android chính thức [ Tài nguyên, 19 ].

    Việc triển khai thiết bị KHÔNG PHẢI mở rộng các định dạng .apk [ Resources, 20 ], Android Manifest [ Resources, 21 ] hoặc Dalvik bytecode [ Resources, 10 ] theo cách có thể 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 . Người triển khai thiết bị NÊN sử dụng triển khai tham chiếu 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 hỗ trợ các codec đa phương tiện sau. 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 ưu tiên từ Dự án mã nguồn mở Android.

    Xin lưu ý rằng cả Google và Open Handset Alliance đều không đưa ra bất kỳ tuyên bố 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 nên lưu ý rằng việc triển khai mã này, kể cả trong phần mềm nguồn mở hoặc phần mềm chia sẻ, có thể yêu cầu giấy phép bằng sáng chế từ những người nắm giữ bằng sáng chế có liên quan.

    Tên Nội dung thô Tốc độ PCM tuyến tính
    âm thanh
    Bộ mã hóa Bộ giải mã Chi tiết Định dạng tệp/vùng chứa
    AAC LC/LTP  X Mono/Stereo ở bất kỳ sự kết hợp nào giữa tốc độ 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ợ AAC (.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 từ 6,60 kbit/s đến 23,85 kbit/s được lấy mẫu @ 16kHz 3GPP (.3gp)
    MP3   X Mono/Stereo 8-320Kbps không đổi (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 di động. Hỗ trợ các định dạng nhạc chuông RTTTL/RTX, OTA và iMelody Type 0 và 1 (.mid, .xmf, .mxmf). Ngoài ra RTTTL/RTX (.rtttl, .rtx), OTA (.ota) và iMelody (.imy)
    Ogg Vorbis   X   Ogg (.ogg)
    PCM  X 8 và 16 bit (tốc độ lên tới giới hạn của phần cứng) WAVE (.wav)
    Hình ảnh
    JPEG X X base+progressive  
    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)

    Lưu ý rằng bảng trên không liệt kê các yêu cầu tốc độ bit 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ợ tốc độ bit ánh xạ chính xác tới tốc độ bit 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ị NÊN hỗ trợ tốc độ bit cao nhất thực tế trên phần cứng, tối đa các giới hạn được xác định bởi thông số kỹ thuật.

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

    Công cụ dành cho nhà phát triển Việc triển khai thiết bị PHẢI hỗ trợ 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 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 trong SDK Android. Trình nền adb phía thiết bị NÊN không hoạt động theo mặc định nhưng PHẢI có cơ chế mà người dùng có thể truy cập để bật Cầu gỡ lỗi Android.
    • Dịch vụ giám sát gỡ lỗi Dalvik (được 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 trong SDK Android. Vì ddms sử dụng adb , nên 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 gỡ lỗi Android, như trên.
    • Khỉ [ 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 phần cứng

    Android nhằm mục đích hỗ trợ người triển khai thiết bị tạo ra các cấu hình và kiểu dáng 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.1 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 dành cho nhà phát triển bên thứ ba thì việc triển khai thiết bị PHẢI triển khai API đó như đượ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 cho là tùy chọn và việc triển khai thiết bị không có thành phần đó:

    • các định nghĩa lớp cho các API của thành phần PHẢI xuất hiện
    • thì các hành vi của API PHẢI được triển khai dưới dạng không hoạt động theo cách thức hợp lý
    • Phương thức API PHẢI trả về giá trị null khi được tài liệu SDK cho phép
    • Phương thức API PHẢI trả về triển khai không hoạt động của các lớp mà giá trị null không được tài liệu SDK cho phép

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

    8.1. Hiển thị

    Android 2.1 bao gồm các phương tiện thực hiện một số thao tác chuyển đổi và chia tỷ lệ 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 khá tốt trên nhiều cấu hình phần cứng [ Tài nguyên, 23 ]. Các thiết bị PHẢI thực hiện đúng các hành vi này, như được nêu chi tiết trong phần này.

    Đối với Android 2.1, đây là các cấu hình hiển thị phổ biến nhất:

    Thấp
    Loại màn hình Chiều rộng (Pixels) Chiều cao (Pixels) Chiều dài đường chéo Phạm vi (inch) Kích thước màn hình Nhóm Mật độ màn hình Nhóm
    QVGA 240 320 2,6 - 3,0 Nhỏ Thấp
    WQVGA 240 400 3,2 - 3,5 Bình thường
    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 Triển

    khai thiết bị

    trung bình lớn 5.0 - 5.8

    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 lớp android.content.res.Configuration [ Resources, 24 ).

    Một số gói .apk có tệp kê khai không xác định chúng 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 sẽ được áp dụng:

    • Việc triển khai thiết bị PHẢI diễn giải tài nguyên trong .apk thiếu bộ định tính mật độ theo mặc định là "trung bình" (được gọi là "mdpi" trong tài liệu SDK.)
    • Khi hoạt động ở mật độ "thấp" màn hình, việc triển khai thiết bị PHẢI giảm tỷ lệ nội dung 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 quy mô nội dung trung bình/mdpi lên hệ số 1,5.
    • Việc triển khai thiết bị KHÔNG PHẢI chia tỷ lệ nội dung trong phạm vi mật độ và PHẢI chia tỷ lệ nội dung theo 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 cần được xem xét bổ sung và hoạt động để 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ư được quy định trong Phần 12 để nhận được các phân loại về giới hạn 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, việc triển khai thiết bị PHẢI triển khai chúng theo quy định.

    Lưu ý rằng một số cấu hình hiển thị (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.1; do đó, những 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. Chỉ số 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, 25 ].

    8.2.

    Triển khai thiết bị

    bàn phím

    :

    • 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 Công cụ quản lý đầu vào -- tức là bàn phím mềm) như chi tiết tại dev.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ó có bàn phím cứ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 PHẢI KHÔNG bao gồm bàn phím phần cứng không khớp với một trong các định dạng được chỉ định trong android.content.res.Configuration.keyboard [ Tài nguyên, 24 ] (nghĩa là QWERTY hoặc 12 phím)

    8.3.

    Triển khai Thiết bị

    điều hướng không cảm ứng

    :

    • CÓ THỂ bỏ qua các tùy chọn điều hướng không cảm ứng (nghĩa là có thể bỏ qua bi xoay, d-pad hoặc bánh xe)
    • PHẢI báo cáo giá trị chính xác cho android.content.res.Configuration.navigation [ Tài nguyên, 24 ]

    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 của ứng dụng theo hướng màn hình dọc hoặc ngang. Nghĩa là, thiết bị phải tôn trọng 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 hướng 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 qua android.content.res.Configuration.orientation, android.view.Display.getOrientation() hoặc các API khác.

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

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

    8.6.

    Triển khai Thiết bị

    USB

    :

    • PHẢI triển khai ứng dụng khách 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ư được mô tả trong Phần 7)
    • PHẢI triển khai thông số bộ lưu trữ dung lượng lớn USB, để cho phép máy chủ được kết nối vào thiết bị để truy cập nội dung của ổ đĩa /sdcard
    • NÊN sử dụng hệ số dạng 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 gửi kèm cáp có khả năng kết nối sơ đồ chân tùy chỉnh với cổng USB-A tiêu chuẩn

    8.7. Các phím điều hướng

    Các chức năng Home, Menu và Back rất cần thiết cho 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. 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.

    Việc triển khai thiết bị

    mạng dữ liệu không dây

    phải bao gồm hỗ trợ 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. Việc thực hiện 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.

    Việc triển khai thiết bị

    camera

    phải bao gồm một máy ảnh. Camera đi kèm:

    • Phải có độ phân giải ít nhất 2 megapixel
    • phải có tiêu điểm tự động phần cứng 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ể tập trung cố định hoặc EDOF (độ sâu mở rộng của trường) Phần cứng
    • có thể bao gồm đè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 camera:

    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 Gọi lạ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.1 [ Tài nguyên, 26 ]), 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 nào đã đăng ký android.hardware.Camera.AutoFocusCallback FocusCallback (mặc dù điều này không liên quan đến camera không tập trung.

    ) 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 dạng 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 , trừ khi các hằng số được đặt trước Tên của người thực hiện thiết bị. 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 trừ khi tên tham số được chỉ định rõ ràng thông qua tiền tố chuỗi là không chuẩn.

    8.10.

    Việc triển khai thiết bị

    gia tốc

    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, 27 ]).

    8.11.

    Việc triển khai thiết bị

    la bàn

    phải bao gồm một 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, 27 ]).

    8.12.

    Việc triển khai thiết bị

    GPS

    phải bao gồm 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.1 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.1 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.

    Việc triển khai thiết bị

    bộ nhớ và lưu trữ

    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.

    Lưu ý: Phần này đã được sửa đổi bởi Erratum EX6580.

    8.15.

    Việc triển khai thiết bị

    lưu trữ được chia sẻ ứng dụng

    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.

    Ngoài ra, 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, bộ
    lưu

    trữ đó phải có kích thước 2GB hoặc lớn hơn 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.)

    : Phần này được thêm vào bởi erratum ex6580.

    8.16.

    Việc triển khai thiết bị

    Bluetooth

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

    Lưu ý: Phần này được thêm vào bởi Erratum EX6580.

    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.1 được xác định trong bảng bên dưới:

    Ngưỡng hiệu suất Số liệu Nhận xét
    Thời gian khởi động ứng dụng Các ứng dụng sau sẽ khởi chạy trong thời gian được chỉ đị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 để tải hoạt động mặc định cho ứng dụng, bao gồm cả thời gian để bắt đầu quá trình Linux, tải Android Gói vào Dalvik VM và gọi OnCreate.
    Các ứng dụng đồng thời Khi nhiều ứng dụng đã được ra mắt, 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.

    Việc triển khai thiết bị tương thích mô hình bảo mật 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 xác định trong tài liệu tham khảo bảo mật và quyền trong API [ Tài nguyên, 28 ] 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.

    Việc triển khai thiết bị

    quyền

    phải hỗ trợ mô hình quyền Android như được định nghĩa trong tài liệu của nhà phát triển Android [ Tài nguyên, 28 ]. 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

    triển khai thiết bị cách ly 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 như cùng một ID người dùng Linux, với điều kiệ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, 28 ].

    10.3.

    Việc triển

    khai thiết bị của FileSystem

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

    11. Việc triển khai thiết bị bộ kiểm tra tương thích

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

    Việc triển khai thiết bị phần mềm có thể cập nhật 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ỳ cách tiếp cận nào sau đây sẽ đáp ứng yêu cầu này:

    • tải xuống trên không (OTA) với bản cập nhật ngoại tuyến thông qua
    • các bản cập nhật "Tethered" trên USB từ máy chủ
    • "ngoại tuyến" thông qua bản khởi động lại và cập nhật từ tệp BẬT 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

    .