Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Định nghĩa khả năng tương thích của Android 1.6

Định nghĩa tương thích Android: Android 1.6
Android 1.6 r2
Google Inc.
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 được
tương thích với Android 1.6. Định nghĩa này giả định quen thuộc với Chương trình tương thích Android
[Tài nguyên, 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", "khuyến nghị",
"có thể" và "tùy chọn" theo tiêu chuẩn IETF được xác định trong RFC2119 [ Tài nguyên , 2].
Như được sử dụng trong tài liệu này, "người triển khai thiết bị" hoặc "người triển khai" là một người hoặc tổ chức đang phát triển
một giải pháp phần cứng/phần mềm chạy Android 1.6. "Triển khai thiết bị" hoặc "triển khai" là
giải pháp phần cứng/phần mềm rất phát triển.
Để được coi là tương thích với Android 1.6, việc triển khai thiết bị:
1. 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
kết hợp thông qua tài liệu tham khảo.
2. PHẢI vượt qua Bộ kiểm tra khả năng tương thích của Android (CTS) có sẵn như một phần của Android Open
Dự án Nguồn [ Tài nguyên , 3]. CTS kiểm tra hầu hết, nhưng không phải tất cả , các thành phần được nêu trong phần này
tài liệu.
Khi định nghĩa này hoặc CTS im lặng, mơ hồ hoặc không đầy đủ, đó là trách nhiệm của thiết bị
triển khai để đảm bảo khả năng tương thích với các triển khai hiện có. Vì lý do này, Android Open
Dự án nguồn [ Tài nguyên , 4] vừa là tài liệu tham khảo vừa là triển khai ưa thích của Android. Thiết bị
những người triển khai được khuyến khích mạnh mẽ dựa trên việc triển khai của họ dựa trên mã nguồn "ngược dòng"
có sẵn từ Dự án mã nguồn mở Android. Trong khi một số thành phần có thể được thay thế theo giả thuyết
với các triển khai thay thế, phương pháp này không được khuyến khích mạnh mẽ, vì việc vượt qua các bài kiểm tra CTS sẽ trở thành
khó khăn hơn nhiều. Người triển khai có trách nhiệm đảm bảo tương thích hoàn toàn về hành vi với
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.
2. Tài nguyên
Định nghĩa tương thích này tham chiếu đến một số tài nguyên có thể lấy được tại đây.
1. Tổng quan về chương trình tương thích với Android: https://sites.google.com/a/android.com/compatibility/
làm thế nào nó hoạt động
2. Mức yêu cầu IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Bộ kiểm tra khả năng tương thích: http://sites.google.com/a/android.com/compatibility/compatibility-test-
bộ--cts
4. Dự án nguồn mở Android: http://source.android.com/
5. Tài liệu và định nghĩa API: http://developer.android.com/reference/packages.html
6. Nhà cung cấp nội dung: http://code.google.com/android/reference/android/provider/package-
tóm tắt.html
7. Tài nguyên có sẵn: http://code.google.com/android/reference/available-resources.html
8. Tệp kê khai Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Tham khảo quyền của Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. Hằng số bản dựng: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Tiện ích mở rộng trình duyệt Gears: http://code.google.com/apis/gears/

13. Thông số kỹ thuật của Máy ảo Dalvik, được tìm thấy trong thư mục dalvik/docs của mã nguồn
Thủ tục thanh toán; cũng có tại http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. Widget ứng dụng: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Thông báo: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. 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
17. Trình quản lý tìm kiếm: http://developer.android.com/reference/android/app/SearchManager.html
18. Bánh mì nướng: http://developer.android.com/reference/android/widget/Toast.html
19. Ứng dụng dành cho Android: http://code.google.com/p/apps-for-android
20. Mô tả tệp apk Android: http://developer.android.com/guide/topics/fundamentals.html
21. Cầu gỡ lỗi Android (adb): http://code.google.com/android/reference/adb.html
22. Dịch vụ màn hình gỡ lỗi Dalvik (ddms): http://code.google.com/android/reference/ddms.html
23. Con khỉ: http://developer.android.com/guide/developing/tools/monkey.html
24. Tài liệu độc lập về màn hình:
25. Hằng số cấu hình: http://developer.android.com/reference/android/content/res/
Cấu hình.html
26. Số liệu hiển thị: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Máy ảnh: 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/
Cảm biếnEvent.html
29. Tài liệu tham khảo về quyền và bảo mật của Android: http://developer.android.com/guide/topics/security/
an ninh.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 1.6 và sẽ được
giống hệt về mặt chức năng với thông tin trong tài liệu của SDK đó. Trong mọi trường hợp mà điều này
Định nghĩa tương thích không đồng ý với tài liệu SDK, tài liệu SDK được xem xét
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 ở trên đều được xem xét bằng cách đưa vào
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 cả một bộ API ("cứng") được quản lý và phần thân của cái gọi là API "mềm"
chẳng hạn như hệ thống Ý định, API mã gốc và API ứng dụng web. Phần này nêu chi tiết những khó khăn và
các API mềm không thể thiếu để tương thích, cũng như một số giao diện người dùng và kỹ thuật có liên quan khác
hành vi cư xử. 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. Các
Giao diện lập trình ứng dụng Android (API) là tập hợp các giao diện nền tảng Android tiếp xúc với
các ứng dụng đang chạy trong môi trường VM được quản lý. Triển khai thiết bị PHẢI cung cấp đầy đủ
triển khai, bao gồm tất cả các hành vi được ghi lại, của mọi API được ghi lại bởi Android
SDK 1.6, chẳng hạn như:
1. Các API ngôn ngữ Java cốt lõi của Android [Tài nguyên, 5].
2. Nhà cung cấp nội dung [Tài nguyên , 6].
3. Tài nguyên [Resources, 7].
4. Thuộc tính và phần tử AndroidManifest.xml [Tài nguyên, 8].

Việc triển khai thiết bị KHÔNG ĐƯỢC bỏ qua bất kỳ API được quản lý nào, thay đổi giao diện hoặc chữ ký API, làm sai lệch
từ hành vi được ghi lại hoặc bao gồm các lỗi không hoạt động, trừ khi được cho phép cụ thể bởi Khả năng tương thích này
Sự định nghĩa.
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ũng bao gồm một "mềm" chỉ dành cho thời gian chạy đáng kể
API, ở 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
mà không thể được thi hành tại thời điểm biên dịch ứng dụng. Phần này trình bày chi tiết các API và hệ thống "mềm"
hành vi cần thiết để tương thích với Android 1.6. Triển khai thiết bị PHẢI đáp ứng tất cả các
yêu cầu 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 lại bởi
Trang tham chiếu quyền [ Tài nguyên , 9]. 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, 10] là
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 trên thiết bị
triển khai, 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à
triển khai thiết bị PHẢI phù hợp.
Tham số
Bình luận
Phiên bản của hệ thống Android hiện đang chạy, ở dạng người-
android.os.Build.VERSION.RELEASE
định dạng có thể đọc được. Đối với Android 1.6, trường này PHẢI có giá trị chuỗi
"1.6".
Phiên bản của hệ thống Android hiện đang chạy, ở định dạng
android.os.Build.VERSION.SDK
có thể truy cập vào mã ứng dụng của bên thứ ba. Đối với Android 1.6, trường này
PHẢI có giá trị nguyên 4.
Một giá trị được chọn bởi người triển khai thiết bị chỉ định bản dựng cụ thể
của hệ thống Android hiện đang chạy, ở định dạng con người có thể đọc được.
Giá trị này KHÔNG ĐƯỢC sử dụng lại cho các bản dựng khác nhau được vận chuyển đến cuối
người dùng android.os.Build.VERSION.INCREMENTAL. Một cách sử dụng thông thường của trường này là để chỉ ra số bản dựng hoặc
mã định danh thay đổi kiểm soát nguồn đã được sử dụng để tạo bản dựng. Ở đó
không có yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc nó
KHÔNG PHẢI là null hoặc chuỗi rỗng ("").
Một giá trị được chọn bởi người triển khai thiết bị xác định nội bộ cụ thể
phần cứng được sử dụng bởi thiết bị, ở định dạng con người có thể đọc được. Một khả năng sử dụng
android.os.Build.BOARD
của trường này là để chỉ ra bản sửa đổi cụ thể của bảng cung cấp năng lượng cho
thiết bị. Không có yêu cầu về định dạng cụ thể của lĩnh vực này,
ngoại trừ việc nó KHÔNG PHẢI là null hoặc chuỗi rỗng ("").
Một giá trị được chọn bởi người triển khai thiết bị xác định tên của
android.os.Build.BRAND
công ty, tổ chức, cá nhân, v.v. đã sản xuất thiết bị, trong
định dạng con người có thể đọc được. Việc sử dụng có thể có của trường này là để chỉ ra OEM

và/hoặc nhà mạng đã bán thiết bị. Không có yêu cầu về
định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI là null hoặc để trống
chuỗi ("").
Một giá trị được chọn bởi người triển khai thiết bị xác định cụ thể
cấu hình hoặc sửa đổi cơ thể (đôi khi được gọi là "công nghiệp
android.os.Build.DEVICE
design") của thiết bị. Không có yêu cầu về định dạng cụ thể
của trường này, ngoại trừ việc nó KHÔNG PHẢI là null hoặc chuỗi rỗng ("").
Một chuỗi xác định duy nhất bản dựng này. Nó NÊN hợp lý
con người có thể đọc được. Nó PHẢI tuân theo mẫu này:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Ví dụ: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Dấu vân tay KHÔNG ĐƯỢC bao gồm dấu cách. Nếu các trường khác được bao gồm trong
mẫu ở trên có khoảng trắng, chúng NÊN được thay thế bằng ASCII
ký tự gạch dưới ("_") trong dấu vân tay.
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 đó, ở dạng người
android.os.Build.HOST
định dạng có thể đọc được. Không có yêu cầu về định dạng cụ thể của điều này
trường, ngoại trừ việc nó KHÔNG PHẢI là null hoặc chuỗi rỗng ("").
Mã định danh do người triển khai thiết bị chọn để tham chiếu đến một thiết bị cụ thể
phát hành, ở định dạng con người có thể đọc được. Trường này có thể giống như
android.os.Build.VERSION.INCREMENTAL, nhưng NÊN là một giá trị
android.os.Build.ID
nhằm mục đích có ý nghĩa phần nào đối với người dùng cuối. Không có
các yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI
là null hoặc chuỗi rỗng ("").
Một giá trị được chọn bởi người triển khai thiết bị có chứa tên của
thiết bị mà người dùng cuối đã biết. Cái này NÊN trùng tên
android.os.Build.MODEL
theo đó thiết bị được tiếp thị và bán cho người dùng cuối. Không có
các yêu cầu về định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI
là null hoặc chuỗi rỗng ("").
Một giá trị được chọn bởi người triển khai thiết bị có chứa sự phát triển
tên hoặc tên mã của thiết bị. PHẢI là con người có thể đọc được, nhưng không phải là
android.os.Build.SẢN PHẨM
nhất thiết phải dành cho người dùng cuối xem. không có yêu cầu
trên định dạng cụ thể của trường này, ngoại trừ việc nó KHÔNG PHẢI là null hoặc
chuỗi rỗng ("").
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". Vùng này
android.os.Build.TAGS
KHÔNG PHẢI là null hoặc chuỗi trống (""), mà là một thẻ đơn (chẳng hạn như
"phát hành") là tốt.
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.
Một giá trị được chọn bởi người triển khai thiết bị chỉ định thời gian chạy
cấu hình của bản dựng. Trường này NÊN có một trong các giá trị
android.os.Build.TYPE
tương ứng với ba cấu hình thời gian chạy Android điển hình: "người dùng",
"userdebug" hoặc "eng".
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
android.os.Build.USER
xây dựng. Không có yêu cầu về định dạng cụ thể của lĩnh vực này,
ngoại trừ việc nó KHÔNG PHẢI là null hoặc chuỗi rỗ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 thực hiện bằng cách triển khai thiết bị. Qua
"vinh dự", điều đó có nghĩa là người triển khai thiết bị PHẢI cung cấp Hoạt động, Dịch vụ Android hoặc dịch vụ khác
thành phần chỉ định bộ lọc Ý định phù hợp và liên kết cũng như 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 của 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, bất kỳ phiên bản thay thế nào như vậy PHẢI tôn trọng các mẫu Ý định giống nhau do thượng nguồn cung cấp
dự án. (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 Intent
do các ứng dụng của bên thứ ba đưa ra để chọn một bài hát.) Việc triển khai thiết bị PHẢI hỗ trợ tất cả các mẫu Intent
liệt kê trong Phụ lục A.
3.2.3.2. Ghi đè ý định
Vì Android là một nền tảng có thể mở rộng, nên những người triển khai thiết bị PHẢI cho phép từng mẫu Ý định được mô tả trong
Phụ lục A sẽ 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 ĐƯỢC gắn các đặc quyền đặc biệt cho các ứng dụng hệ thống'
việc sử dụng các mẫu Ý định này hoặc ngăn các ứng dụng của bên thứ ba liên kết và giả định quyền kiểm soát
những mẫu này. Lệnh cấm này đặc biệt bao gồm việc vô hiệu hóa giao diện người dùng "Chooser" cho phép
người dùng chọn giữa nhiều ứng dụng, tất cả đều xử lý cùng một mẫu Intent.
3.2.3.3. Không gian tên ý định
Người triển khai thiết bị KHÔNG ĐƯỢC bao gồm bất kỳ thành phần Android nào tôn vinh bất kỳ Ý định mới hoặc
Các mẫu Ý định quảng bá bằng cách sử dụng ACTION, CATEGORY hoặc chuỗi khóa khác trong không gian tên android.*.
Trình triển khai thiết bị KHÔNG ĐƯỢC bao gồm bất kỳ thành phần Android nào tôn vinh bất kỳ Ý định mới hoặc
Các mẫu Mục đích quảng bá bằng cách sử dụng một ACTION, CATEGORY hoặc chuỗi khóa khác trong một không gian gói
thuộc tổ chức khác. Người triển khai thiết bị KHÔNG ĐƯỢC thay đổi hoặc mở rộng bất kỳ Mục đích nào
các mẫu được liệt kê trong Phụ lục A hoặc B.
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 để 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 công khai
Ý định để đáp ứng với các sự kiện hệ thống thích hợp. Một danh sách các Ý định phát sóng bắt buộc được cung cấp trong
Phụ lục B; tuy nhiên, hãy lưu ý rằng SDK có thể xác định các ý định phát sóng bổ sung, ý định này cũng PHẢI được
được vinh danh.
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 ELF
Tệp .so được biên dịch cho kiến trúc phần cứng thiết bị phù hợp. 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 mã gốc, sử dụng Java tiêu chuẩn
Ngữ nghĩa Giao diện gốc (JNI). 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++
• OpenGL ES 1.1
Các thư viện này PHẢI tương thích với nguồn (tức là tương thích với tiêu đề) và tương thích với nhị phân (đối với một
kiến trúc bộ xử lý) với các phiên bản được cung cấp trong Bionic bởi dự án Nguồn mở Android. Từ
cá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ư GNU C
thư việ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 một
triển khai khác nhau của các thư viện này, chúng phải đảm bảo khả năng tương thích tiêu đề và nhị phân.
Khả năng tương thích mã gốc là một thách thức. Vì lý do này, chúng tôi muốn nhắc lại rằng những người triển khai thiết bị là
RẤT 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 ,
11] cho giao diện người dùng của họ, vì vậy việc triển khai WebView phải tương thích trên Android
triển khai. Việc triển khai Nguồn mở Android sử dụng phiên bản công cụ kết xuất WebKit để
triển khai WebView.
Vì không khả thi để phát triển một bộ thử nghiệm toàn diện cho trình duyệt web, những người triển khai thiết bị
PHẢI sử dụng bản dựng ngược dòng cụ thể của WebKit trong quá trình triển khai WebView. Đặc biệt:
• WebView PHẢI sử dụng bản dựng WebKit 528.5 trở lên từ cây Nguồn mở Android ngược dòng cho
Androi 1.6. Bản dựng này bao gồm một bộ chức năng cụ thể và các bản sửa lỗi bảo mật cho WebView.
• Chuỗi tác nhân người dùng do WebView báo cáo PHẢI ở định dạng sau:
Mozilla/5.0 (Linux; U; Android 1.6; <ngôn ngữ>-<quốc gia>; <thiết bị
tên>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, như Gecko)
Phiên bản/3.1.2 Mobile Safari/525.20.1

◦ Chuỗi "<tên thiết bị>" PHẢI giống với giá trị của
android.os.Build.MODEL
◦ Chuỗi "<build ID>" PHẢI giống với giá trị của android.os.Build.ID.
◦ Các chuỗi "<ngôn ngữ>" và "<quốc gia>" NÊN tuân theo các quy ước thông thường cho
mã quốc gia và ngôn ngữ, và NÊN tham khảo ngôn ngữ hiện tại của thiết bị tại
thời gian của yêu cầu.
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. cái gì
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 vận chuyển, 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.
Ứng dụng Trình duyệt độc lập NÊN bao gồm hỗ trợ cho Gears [ Tài nguyên, 12] và MAY
bao gồm hỗ trợ cho một số hoặc tất cả HTML5.
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
ưu tiên triển khai Android có sẵn từ Dự án mã nguồn mở Android.
Một số lĩnh vực tương thích cụ thể là:
• Các thiết bị KHÔNG ĐƯỢC thay đổi hành vi hoặc ý nghĩa của một Intent tiêu chuẩn
• Các thiết bị KHÔNG ĐƯỢC làm thay đổi vòng đời hoặc ngữ nghĩa vòng đời của một loại hệ thống cụ thể
thành phần (chẳng hạn như Dịch vụ, Hoạt động, Trình cung cấp nội dung, v.v.)
• Thiết bị KHÔNG ĐƯỢC thay đổi ngữ nghĩa của một quyền cụ thể
Danh sách trên không đầy đủ và trách nhiệm thuộc về người triển khai thiết bị để đảm bảo hành vi
khả năng tương thích. Vì lý do này, những người triển khai thiết bị NÊN sử dụng mã nguồn có sẵn thông qua
Dự án nguồn mở Android nếu có thể, thay vì triển khai lại các phần quan trọng của hệ thống.
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ả. Người triển khai có trách nhiệm đảm bảo khả năng tương thích hành vi với Android
Dự án mã nguồn mở.
3.6. Không gian tên API
Android tuân theo các quy ước không gian tên gói và lớp được xác định bởi lập trình Java
ngôn ngữ. Để đả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 ĐƯỢC thực hiện
mọi sửa đổi bị cấm (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.*
Sửa đổi bị cấm bao gồm:
• Việc triển khai thiết bị KHÔNG ĐƯỢC 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ư vậy
sửa đổi KHÔNG ĐƯỢC ảnh hưởng đến hành vi đã nêu và chữ ký ngôn ngữ Java của bất kỳ
API được hiển thị công khai.
• Người triển khai thiết bị KHÔNG ĐƯỢC thêm bất kỳ phần tử nào được hiển thị công khai (chẳng hạn như các lớp hoặc
giao diện, hoặc trường hoặc phương thức cho các lớp hoặc giao diện hiện có) cho các API ở trên.
"Phần tử hiển thị công khai" là bất kỳ cấu trúc nào không được trang trí bằng dấu "@hide" trong
ngược dòng mã nguồn Android. Nói cách khác, những người triển khai thiết bị KHÔNG ĐƯỢC để lộ các API mới hoặc
thay đổi các API hiện có trong các không gian tên đã lưu ý ở trên. Người triển khai thiết bị CÓ THỂ chỉ thực hiện nội bộ
sửa đổi, nhưng những sửa đổi đó KHÔNG ĐƯỢ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 bất kỳ API nào như vậy KHÔNG PHẢI nằm trong một không gian tên được sở hữu
bởi hoặc đề cập đến một tổ chức khác. Chẳng hạn, người triển khai thiết bị KHÔNG ĐƯỢC thêm API vào
com.google.* hoặc không gian tên tương tự; chỉ Google mới có thể làm như vậy. Tương tự, Google KHÔNG ĐƯỢC thêm API vào
không gian tên của các công ty khác.
Nếu một 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 cho API hiện có hoặc thêm API mới), 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 trong Java
ngôn ngữ lập trình; phần này chỉ nhằm mục đích củng cố những quy ước đó và làm cho chúng trở nên ràng buộc
thông qua việc đưa vào định nghĩa tương thích này.
3.7. Khả năng tương thích của máy ảo
Một thiết bị Android tương thích phải hỗ trợ đặc tả mã byte Dalvik Executable (DEX) đầy đủ và
Ngữ nghĩa máy ảo Dalvik [Tài nguyên, 13].
3.8. 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 người dùng hệ thống
giao diện. 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
chúng phát triển, như được giải thích dưới đây.
3.8.1. tiện ích
Android định nghĩa một loại thành phần và API và vòng đời tương ứng cho phép các ứng dụng hiển thị
một "AppWidget" cho người dùng cuối [Resources , 14] . Bản phát hành tham khảo mã nguồn mở Android bao gồm một
Ứng dụng trình khởi chạy bao gồm các yếu tố giao diện người dùng cho phép người dùng thêm, xem và xóa
AppWidgets từ 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 AppWidgets và hiển thị giao diện người dùng
các phần tử để thêm, 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 yếu tố 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
ứng dụng riêng biệt có thể truy cập từ Trình khởi chạy cho phép người dùng thêm, 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, 15]. Thiết bị
người triển khai 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 và tất cả cá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, 7] hoặc trong hướng dẫn kiểu biểu tượng Thanh trạng thái [Tài nguyên , 16]. Thiết bị
người triển khai 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
tham khảo triển khai Mã nguồn mở Android; tuy nhiên, các hệ thống thông báo thay thế như vậy PHẢI
hỗ trợ các tài nguyên thông báo hiện có, như trên.
3.8.3. Tìm kiếm
Android bao gồm API [Tài nguyên, 17] cho phép 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 của ứng dụng của họ vào hệ thống tìm kiếm 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 các truy vấn, hiển thị các đề xuất
as users type, and displays results. The Android APIs allow developers to reuse this interface to provide
search within their own apps, and allow developers to supply results to the common global search user
interface.
Device implementations MUST include a single, shared, system-wide search user interface capable of
real-time suggestions in response to user input. Device implementations MUST implement the APIs that
allow developers to reuse this user interface to provide search within their own applications.
Device implementations MUST implement the APIs that allow third-party applications to add suggestions
to the search box when it is run in global search mode. If no third-party applications are installed that
make use of this functionality, the default behavior SHOULD be to display web search engine results and
suggestions.
Device implementations MAY ship alternate search user interfaces, but SHOULD include a hard or soft
dedicated search button, that can be used at any time within any app to invoke the search framework,
with the behavior provided for in the API documentation.
3.8.4. Toasts
Applications can use the "Toast" API (defined in [ Resources, 18]) to display short non-modal strings to the
end user, that disappear after a brief period of time. Device implementations MUST display Toasts from
applications to end users in some high-visibility manner.
4. Reference Software Compatibility
Device implementers MUST test implementation compatibility using the following open-source
applications:
• Calculator (included in SDK)
• Lunar Lander (included in SDK)
• ApiDemos (included in SDK)
• The "Apps for Android" applications [ Resources, 19]
Each app above MUST launch and behave correctly on the implementation, for the implementation to be

considered compatible.
5. Application Packaging Compatibility
Device implementations MUST install and run Android ".apk" files as generated by the "aapt" tool
included in the official Android SDK [ Resources , 20].
Devices implementations MUST NOT extend either the .apk, Android Manifest, or Dalvik bytecode
formats in such a way that would prevent those files from installing and running correctly on other
compatible devices. Device implementers SHOULD use the reference upstream implementation of Dalvik,
and the reference implementation's package management system.
6. Multimedia Compatibility
A compatible Android device must support the following multimedia codecs. All of these codecs are
provided as software implementations in the preferred Android implementation from the Android Open
Source Project [ Resources , 4].
Please note that neither Google nor the Open Handset Alliance make any representation that these
codecs are unencumbered by third-party patents. Those intending to use this source code in hardware or
software products are advised that implementations of this code, including in open source software or
shareware, may require patent licenses from the relevant patent holders.
Audio
Name
Encoder Decoder Details
Files Supported
Mono/Stereo content in any
3GPP (.3gp) and
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
up to 160 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
3GPP (.3gp) and
HE-AACv1
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
X
(AAC+)
up to 96 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
HE-AACv2
3GPP (.3gp) and
combination of standard bit rates
(enhanced
MPEG-4 (.mp4, .m4a)
X
up to 96 kbps and sampling rates
AAC+)
files. No support for raw
between 8 to 48kHz
AAC (.aac)
AMR-NB
4.75 to 12.2 kbps sampled @
3GPP (.3gp) files
X
X
8kHz
AMR-WB
9 rates from 6.60 kbit/s to 23.85
-3GPP (.3gp) files
X
kbit/s sampled @ 16kHz
MP3
Mono/Stereo 8-320Kbps constant MP3 (.mp3) files
X
(CBR) or variable bit-rate (VBR)
Type 0 and 1 (.mid, .xmf,
MIDI Type 0 and 1. DLS Version 1
MIDI
X
.mxmf). Also RTTTL/RTX
and 2. XMF and Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Support for ringtone formats
and iMelody (.imy)
RTTTL/RTX, OTA, and iMelody
Ogg Vorbis
.ogg
X
8- and 16-bit linear PCM (rates up
PCM
X
WAVE
to limit of hardware)
Image
Files
Name
Encoder Decoder Details
Supported
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
Files
Name
Encoder Decoder Details
Supported
3GPP (.3gp)
H.263
X
X
files
3GPP (.3gp)
H.264
X
and MPEG-4
(.mp4) files
MPEG4
X
3GPP (.3gp) file
SP
7. Developer Tool Compatibility
Device implementations MUST support the Android Developer Tools provided in the Android SDK.
Specifically, Android-compatible devices MUST be compatible with:
• Android Debug Bridge or adb [Resources , 21]
Device implementations MUST support all adb functions as documented in the Android
SDK. The device-side adb daemon SHOULD be inactive by default, but there MUST be a user-
accessible mechanism to turn on the Android Debug Bridge.
• Dalvik Debug Monitor Service or ddms [Resources , 22]
Device implementations MUST support all ddms features as documented in the Android SDK.
As ddms uses adb, support for ddms SHOULD be inactive by default, but MUST be supported
whenever the user has activated the Android Debug Bridge, as above.

• Monkey [Resources, 23]
Device implementations MUST include the Monkey framework, and make it available for
applications to use.
8. Hardware Compatibility
Android is intended to support device implementers creating innovative form factors and configurations.
At the same time Android developers expect certain hardware, sensors and APIs across all Android
device. This section lists the hardware features that all Android 1.6 compatible devices must support. In
Android 1.6, the majority of hardware features (such as WiFi, compass, and accelerometer) are required.
If a device includes a particular hardware component that has a corresponding API for third-party
developers, the device implementation MUST implement that API as defined in the Android SDK
documentation.
8.1. Display
Android 1.6 includes facilities that perform certain automatic scaling and transformation operations under
some circumstances, to ensure that third-party applications run reasonably well on hardware
configurations for which they were not necessarily explicitly designed [Resources, 24] . Devices MUST
properly implement these behaviors, as detailed in this section.
8.1.1. Standard Display Configurations
This table lists the standard screen configurations considered compatible with Android:
Diagonal
Screen Size
Screen Density
Screen Type
Width (Pixels)
Height (Pixels)
Length Range
Group
Group
(inches)
QVGA
240
320
2.6 - 3.0
Small
Low
WQVGA
240
400
3.2 - 3.5
Normal
Low
FWQVGA
240
432
3.5 - 3.8
Normal
Low
HVGA
320
480
3.0 - 3.5
Normal
Medium
WVGA
480
800
3.3 - 4.0
Normal
High
FWVGA
480
854
3.5 - 4.0
Normal
High
WVGA
480
800
4.8 - 5.5
Large
Medium
FWVGA
480
854
5.0 - 5.8
Large
Medium
Device implementations corresponding to one of the standard configurations above MUST be configured
to report the indicated screen size to applications via the android.content.res.Configuration [ Resources,
25] class.
Some .apk packages have manifests that do not identify them as supporting a specific density range.
When running such applications, the following constraints apply:

• Device implementations MUST interpret any resources that are present as defaulting to
"medium" (known as "mdpi" in the SDK documentation.)
• When operating on a "low" density screen, device implementations MUST scale down medium/
mdpi assets by a factor of 0.75.
• When operating on a "high" density screen, device implementations MUST scale up medium/
mdpi assets by a factor of 1.5.
• Device implementations MUST NOT scale assets within a density range, and MUST scale
assets by exactly these factors between density ranges.
8.1.2. Non-Standard Display Configurations
Display configurations that do not match one of the standard configurations listed in Section 8.2.1 require
additional consideration and work to be compatible. Device implementers MUST contact Android
Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density,
and scaling factor. When provided with this information, device implementations MUST implement them
as specified.
Note that some display configurations (such as very large or very small screens, and some aspect ratios)
are fundamentally incompatible with Android 1.6; therefore device implementers are encouraged to
contact Android Compatibility Team as early as possible in the development process.
8.1.3. Display Metrics
Device implementations MUST report correct values for all display metrics defined in
android.util.DisplayMetrics [Resources , 26].
8.2. Keyboard
Device implementations:
• MUST include support for the Input Management Framework (which allows third party
developers to create Input Management Engines -- ie soft keyboard) as detailed at
developer.android.com
• MUST provide at least one soft keyboard implementation (regardless of whether a hard
keyboard is present)
• MAY include additional soft keyboard implementations
• MAY include a hardware keyboard
• MUST NOT include a hardware keyboard that does not match one of the formats specified
in android.content.res.Configuration [ Resources, 25] (that is, QWERTY, or 12-key)
8.3. Non-touch Navigation
Device implementations:
• MAY omit non-touch navigation options (that is, may omit a trackball, 5-way directional pad, or
wheel)
• MUST report via android.content.res.Configuration [Resources , 25] the correct value for the
device's hardware

8.4. Screen Orientation
Compatible devices MUST support dynamic orientation by applications to either portrait or landscape
screen orientation. That is, the device must respect the application's request for a specific screen
orientation. Device implementations MAY select either portrait or landscape orientation as the default.
Devices MUST report the correct value for the device's current orientation, whenever queried via the
android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.
8.5. Touchscreen input
Device implementations:
• MUST have a touchscreen
• MAY have either capacative or resistive touchscreen
• MUST report the value of android.content.res.Configuration [ Resources, 25] reflecting
corresponding to the type of the specific touchscreen on the device
8.6. USB
Device implementations:
• MUST implement a USB client, connectable to a USB host with a standard USB-A port
• MUST implement the Android Debug Bridge over USB (as described in Section 7)
• MUST implement a USB mass storage client for the removable/media storage is present in the
device
• SHOULD use the micro USB form factor on the device side
• SHOULD implement support for the USB Mass Storage specification (so that either removable
or fixed storage on the device can be accessed from a host PC)
• MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of
connecting the custom pinout to standard USB-A port
8.7. Navigation keys
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device
implementations MUST make these functions available to the user at all times, regardless of application
state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented
using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or
interfere with the available application display area.
Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also
provide send and end keys for phone calls.
8.8. WiFi
Device implementations MUST support 802.11b and 802.11g, and MAY support 802.11a.

8.9. Camera
Device implementations MUST include a camera. The included camera:
• MUST have a resolution of at least 2 megapixels
• SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera
driver (transparent to application software)
• MAY have fixed-focus or EDOF (extended depth of field) hardware
• MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an
android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview
surface.
Device implementations MUST implement the following behaviors for the camera-related APIs
[Resources, 27] :
1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int),
then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data
provided to application callbacks.
2. If an application registers an android.hardware.Camera.PreviewCallback instance and the
system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the
data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format.
(This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.
8.9.1. Non-Autofocus Cameras
If a device lacks an autofocus camera, the device implementer MUST meet the additional requirements in
this section. Device implementations MUST implement the full Camera API included in the Android 1.6
SDK documentation in some reasonable way, regardless of actual camera hardware's capabilities.
For Android 1.6, if the camera lacks auto-focus, the device implementation MUST adhere to the following:
1. The system MUST include a read-only system property named "ro.workaround.noautofocus"
with the value of "1". This value is intended to be used by applications such as Android Market to
selectively identify device capabilities, and will be replaced in a future version of Android with a
robust API.
2. If an application calls android.hardware.Camera.autoFocus(), the system MUST call the
onAutoFocus() callback method on any registered
android.hardware.Camera.AutoFocusCallback instances, even though no focusing actually
happened. This is to avoid having existing applications break by waiting forever for an autofocus
callback that will never come.
3. The call to the AutoFocusCallback.onAutoFocus() method MUST be triggered by the driver or
framework in a new event on the main framework Looper thread. That is, Camera.autoFocus()
MUST NOT directly call AutoFocusCallback.onAutoFocus() since this violates the Android
framework threading model and will break apps.
8.10. Accelerometer
Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at at
least 50 Hz. The coordinate system used by the accelerometer MUST comply with the Android sensor
coordinate system as detailed in the Android API s [Resources , 28].

8.11. Compass
Device implementations MUST include a 3-axis compass and MUST be able to deliver events at at least
10 Hz. The coordinate system used by the compass MUST comply with the Android sensor coordinate
system as defined in the Android API [Resources , 28].
8.12. GPS
Device implementations MUST include a GPS, and SHOULD include some form of "assisted GPS"
technique to minimize GPS lock-on time.
8.13. Telephony
Device implementations:
• MUST include either GSM or CDMA telephony
• MUST implement the appropriate APIs as detailed in the Android SDK documentation at
developer.android.com
Note that this requirement implies that non-phone devices are not compatible with Android 1.6; Android
1.6 devices MUST include telephony hardware. Please see Appendix C for information on non-phone
devices.
8.14. Volume controls
Android-compatible devices MUST include a mechanism to allow the user to increase and decrease the
audio volume. Device implementations MUST make these functions available to the user at all times,
regardless of application state. These functions MAY be implemented using physical hardware keys,
software, gestures, touch panel, etc., but they MUST be always accessible and not obscure or interfere
with the available application display area (see Display above).
When these buttons are used, the corresponding key events MUST be generated and sent to the
foreground application. If the event is not intercepted and sunk by the application then device
implementation MUST handle the event as a system volume control.
9. Performance Compatibility
One of the goals of the Android Compatibility Program is to ensure a consistent application experience for
consumers. Compatible implementations must ensure not only that applications simply run correctly on
the device, but that they do so with reasonable performance and overall good user experience.
Device implementations MUST meet the key performance metrics of an Android 1.6 compatible device,
as in the table below:
Metric
Performance Threshold
Comments

This is tested by CTS.
The following applications
The launch time is measured as the total time to
should launch within the
complete loading the default activity for the
Application
specified time.
application, including the time it takes to start the
Launch Time
Browser: less than 1300ms
Linux process, load the Android package into the
MMS/SMS: less than 700ms
Dalvik VM, and call onCreate.
AlarmClock: less than 650ms
Multiple applications will be
This is tested by CTS.
launched. Re-launching the
Simultaneous first application should
Applications
complete taking less than the
original launch time.
10. Security Model Compatibility
Device implementations MUST implement a security model consistent with the Android platform security
model as defined in Security and Permissions reference document in the APIs [Resources, 29] in the
Android developer documentation. Device implementations MUST support installation of self-signed
applications without requiring any additional permissions/certificates from any third parties/authorities.
Specifically, compatible devices MUST support the following security mechanisms:
10.1. Permissions
Device implementations MUST support the Android permissions model as defined in the Android
developer documentation [ Resources , 9]. Specifically, implementations MUST enforce each permission
defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored.
Implementations MAY add additional permissions, provided the new permission ID strings are not in the
android.* namespace.
10.2. User and Process Isolation
Device implementations MUST support the Android application sandbox model, in which each application
runs as a unique Unix-style UID and in a separate process.
Device implementations MUST support running multiple applications as the same Linux user ID, provided
that the applications are properly signed and constructed, as defined in the Security and Permissions
reference [ Resources , 29].

10.3. Filesystem Permissions
Device implementations MUST support the Android file access permissions model as defined in as
defined in the Security and Permissions reference [Resources , 29].
11. Compatibility Test Suite
Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 3] available
from the Android Open Source Project, using the final shipping software on the device. Additionally,
device implementers SHOULD use the reference implementation in the Android Open Source tree as
much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any
reimplementations of parts of the reference source code.
The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs.
The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the
CTS may be released for Android 1.6. However, such releases will only fix behavioral bugs in the CTS
tests and will not impose any new tests, behaviors or APIs for a given platform release.
12. Contact Us
You can contact the Android Compatibility Team at compatibility@android.com for clarifications related to
this Compatibiltiy Definition and to provide feedback on this Definition.

Appendix A: Required Application Intents
NOTE: this list is provisional, and will be updated in the future.
Application Actions
Schemes MIME Types
(none)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(none)
android.intent.action.WEB_SEARCH
http
(none)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Camera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
image
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
video
android.intent.action.ATTACH_DATA
image/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Phone /
android.intent.action.VIEW
tel
Contacts
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
person

vnd.android.cursor.dir/
person
vnd.android.cursor.dir/
android.intent.action.PICK
phone
vnd.android.cursor.dir/
postal-address
vnd.android.cursor.item/
person
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
phone
vnd.android.cursor.item/
postal-address
text/plain
Email
android.intent.action.SEND
image/*
video/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Music
android.intent.action.VIEW
file
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
nowplaying
vnd.android.cursor.dir/
track
nd.android.cursor.dir/
playlist
vnd.android.cursor.dir/
video
media/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
video/*

content
Package
android.intent.action.VIEW
file
Installer
package
file
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Settings
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Search
android.intent.action.SEARCH
query
android.intent.action.SEARCH_LONG_PRESS
Voice
android.intent.action.VOICE_COMMAND
Contacts Management
Intent Action
Description
Starts an Activity that lets the user pick
ATTACH_IMAGE
a contact to attach an image to.
Used
EXTRA_CREATE_DESCRIPTION
with SHOW_OR_CREATE_CONTACT to
specify an exact description to be

shown when prompting user about
creating a new contact.
Used
with SHOW_OR_CREATE_CONTACT to
EXTRA_FORCE_CREATE
force creating a new contact if no
matching contact found.
This is the intent that is fired when a
SEARCH_SUGGESTION_CLICKED
search suggestion is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED search suggestion for creating a
contact is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
search suggestion for dialing a number
is clicked on.
Takes as input a data URI with a mailto:
SHOW_OR_CREATE_CONTACT
or tel: scheme.

Appendix B: Required Broadcast Intents NOTE: this list is provisional, and will be
updated in the future.
Intent Action
Description
Broadcast Action: This is broadcast once, after the
ACTION_BOOT_COMPLETED
system has finished booting.
Broadcast Action: This is broadcast once, when a
ACTION_CALL_BUTTON
call is received.
Broadcast Action: The "Camera Button" was
ACTION_CAMERA_BUTTON
pressed.
Broadcast Action: The current
ACTION_CONFIGURATION_CHANGED
device Configuration (orientation, locale, etc) has
changed.
ACTION_DATE_CHANGED
Broadcast Action: The date has changed.
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_LOW
on the device
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_OK
on the device no longer exists
Broadcast Action: Wired Headset plugged in or
ACTION_HEADSET_PLUG
unplugged.
Broadcast Action: An input method has been
ACTION_INPUT_METHOD_CHANGED
changed.
Broadcast Action: External media was removed
ACTION_MEDIA_BAD_REMOVAL
from SD card slot, but mount point was not
unmounted.
Broadcast Action: The "Media Button" was
ACTION_MEDIA_BUTTON
pressed.
Broadcast Action: External media is present, and
being disk-checked The path to the mount point for
ACTION_MEDIA_CHECKING
the checking media is contained in the
Intent.mData field.
Broadcast Action: User has expressed the desire to
ACTION_MEDIA_EJECT
remove the external storage media.
Broadcast Action: External media is present and
ACTION_MEDIA_MOUNTED
mounted at its mount point.
Broadcast Action: External media is present, but is
using an incompatible fs (or is blank) The path to
ACTION_MEDIA_NOFS
the mount point for the checking media is
contained in the Intent.mData field.
Broadcast Action: External media has been
ACTION_MEDIA_REMOVED
removed.
Broadcast Action: The media scanner has finished
ACTION_MEDIA_SCANNER_FINISHED
scanning a directory.
Broadcast Action: Request the media scanner to
ACTION_MEDIA_SCANNER_SCAN_FILE
scan a file and add it to the media database.

Broadcast Action: The media scanner has started
ACTION_MEDIA_SCANNER_STARTED
scanning a directory.
Broadcast Action: External media is unmounted
ACTION_MEDIA_SHARED
because it is being shared via USB mass storage.
Broadcast Action: External media is present but
ACTION_MEDIA_UNMOUNTABLE
cannot be mounted.
Broadcast Action: External media is present, but
ACTION_MEDIA_UNMOUNTED
not mounted at its mount point.
Broadcast Action: An outgoing call is about to be
ACTION_NEW_OUTGOING_CALL
placed.
Broadcast Action: A new application package has
ACTION_PACKAGE_ADDED
been installed on the device.
Broadcast Action: An existing application package
ACTION_PACKAGE_CHANGED
has been changed (eg a component has been
enabled or disabled.
Broadcast Action: The user has cleared the data of
a package. This should be preceded
by ACTION_PACKAGE_RESTARTED, after which
ACTION_PACKAGE_DATA_CLEARED
all of its persistent data is erased and this
broadcast sent. Note that the cleared package
does not receive this broadcast. The data contains
the name of the package.
Broadcast Action: An existing application package
has been removed from the device. The data
ACTION_PACKAGE_REMOVED
contains the name of the package. The package
that is being installed does not receive this Intent.
Broadcast Action: A new version of an application
ACTION_PACKAGE_REPLACED
package has been installed, replacing an existing
version that was previously installed.
Broadcast Action: The user has restarted a
package, and all of its processes have been killed.
All runtime state associated with it (processes,
ACTION_PACKAGE_RESTARTED
alarms, notifications, etc) should be removed. Note
that the restarted package does not receive this
broadcast. The data contains the name of the
package.
Broadcast Action: Some content providers have
parts of their namespace where they publish new
ACTION_PROVIDER_CHANGED
events or items that the user may be especially
interested in.
ACTION_SCREEN_OFF
Broadcast Action: Sent after the screen turns off.
ACTION_SCREEN_ON
Broadcast Action: Sent after the screen turns on.
Broadcast Action: A user ID has been removed
ACTION_UID_REMOVED
from the system.
Broadcast Action: The device has entered USB
ACTION_UMS_CONNECTED
Mass Storage mode.

Broadcast Action: The device has exited USB
ACTION_UMS_DISCONNECTED
Mass Storage mode.
Broadcast Action: Sent when the user is present
ACTION_USER_PRESENT
after device wakes up (eg when the keyguard is
gone).
Broadcast Action: The current system wallpaper
ACTION_WALLPAPER_CHANGED
has changed.
ACTION_TIME_CHANGED
Broadcast Action: The time was set.
ACTION_TIME_TICK
Broadcast Action: The current time has changed.
ACTION_TIMEZONE_CHANGED
Broadcast Action: The timezone has changed.
Broadcast Action: The charging state, or charge
ACTION_BATTERY_CHANGED
level of the battery has changed.
Broadcast Action: Indicates low battery condition
ACTION_BATTERY_LOW
on the device. This broadcast corresponds to the
"Low battery warning" system dialog.
Broadcast Action: Indicates the battery is now okay
after being low. This will be sent
ACTION_BATTERY_OKAY
after ACTION_BATTERY_LOW once the battery
has gone back up to an okay state.
Network State
Intent Action
Description
Broadcast intent action indicating that the
NETWORK_STATE_CHANGED_ACTION
state of Wi-Fi connectivity has changed.
Broadcast intent action indicating that the
RSSI_CHANGED_ACTION
RSSI (signal strength) has changed.
Broadcast intent action indicating that a
SUPPLICANT_STATE_CHANGED_ACTION
connection to the supplicant has been
established or lost.
Broadcast intent action indicating that Wi-Fi
WIFI_STATE_CHANGED_ACTION
has been enabled, disabled, enabling,
disabling, or unknown.
The network IDs of the configured networks
NETWORK_IDS_CHANGED_ACTION
could have changed.
Broadcast intent action indicating that the
ACTION_BACKGROUND_DATA_SETTING_CHANGED setting for background data usage has
changed values.
Broadcast intent indicating that a change in
CONNECTIVITY_ACTION
network connectivity has occurred.
Broadcast Action: The user has switched the
ACTION_AIRPLANE_MODE_CHANGED
phone into or out of Airplane Mode.

Appendix C: Future Considerations This appendix clarifies certain portions of this Android
1.6 Compatibility Definition, and in some cases discusses anticipated or planned changes intended for a
future version of the Android platform. This appendix is for informational and planning purposes only, and
is not part of the Compatibility Definition for Android 1.6.
1. Non-telephone Devices
Android 1.6 is intended exclusively for telephones; telephony functionality is not optional. Future versions
of the Android platform are expected to make telephony optional (and thus allow for non-phone Android
devices), but only phones are compatible with Android 1.6.
2. Bluetooth Compatibility
The Android 1.6 release of Android does not support Bluetooth APIs, so from a compatibility perspective
Bluetooth does not impose any considerations for this version of the platform. However, a future version
of Android will introduce Bluetooth APIs. At that point, supporting Bluetooth will become mandatory for
compatibility.
Consequently, we strongly recommend that Android 1.6 devices include Bluetooth, so that they will be
compatible with future versions of Android that require Bluetooth.
3. Required Hardware Components
All hardware components in Section 8 (including WiFi, magnetometer/compass, accelerometer, etc.) are
required and may not be omitted. Future versions of Android are expected to make some (but not all) of
these components optional, in tandem with corresponding tools for third-party developers to handle these
changes.
4. Sample Applications
The Compatibility Definition Document for a future version of Android will include a more extensive and
representative list of applications than the ones listed in Section 4, above. For Android 1.6, the
applications listed in Section 4 must be tested.
5. Touch Screens
Future versions of the Compatibility Definition may or may not allow for devices to omit touchscreens.
However, currently much of the Android framework implementation assumes the existence of a
touchscreen; omitting a touchscreen would break substantially all current third-party Android applications,
so in Android 1.6 a touchscreen is required for compatibility.

6. Performance
Future versions of CTS will also measure the CPU utilization and performance of the following
components of an implementation:
• 2D graphics
• 3D graphics
• Video playback
• Audio playback
• Bluetooth A2DP playback

Định nghĩa khả năng tương thích của Android 1.6

Document Outline