ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP

หน้านี้ได้รับการแปลโดย Cloud Translation API

นิยามความเข้ากันได้กับ Android 4.1
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

7.3.1. ตัวตรวจวัดความเร่ง
7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
7.3.3. GPS
7.3.4 เครื่องวัดการหมุน
7.3.5 บารอมิเตอร์
7.3.6 เครื่องวัดอุณหภูมิ
7.3.7 โฟโตมิเตอร์
7.3.8. เซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียง
7.4. การเชื่อมต่อข้อมูล
7.4.1. โทรศัพท์
7.4.2. IEEE 802.11 (WiFi)
7.4.2.1. Wi-Fi Direct
7.4.3. บลูทูธ
7.4.4. Near-Field Communications
7.4.5. ความสามารถขั้นต่ำของเครือข่าย
7.5. กล้อง
7.5.1. กล้องหลัง
7.5.2 กล้องหน้า
7.5.3. ลักษณะการทํางานของ Camera API
7.5.4. การวางแนวของกล้อง
7.6. หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
7.7. USB
8. ความเข้ากันได้ด้านประสิทธิภาพ
9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย
9.1. สิทธิ์
9.2. การแยก UID และกระบวนการ
9.3 สิทธิ์ในระบบไฟล์
9.4. สภาพแวดล้อมการดําเนินการอื่น
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
10.1. ชุดเครื่องมือทดสอบความเข้ากันได้
10.2 โปรแกรมตรวจสอบ CTS
10.3. แอปพลิเคชันอ้างอิง
11. ซอฟต์แวร์ที่อัปเดตได้
12. ติดต่อเรา
ภาคผนวก ก - ขั้นตอนการทดสอบบลูทูธ

1. ข้อมูลเบื้องต้น
เอกสารนี้ระบุข้อกำหนดที่อุปกรณ์ต้องมีคุณสมบัติตรงตาม
จึงจะใช้งานร่วมกับ Android 4.1 ได้
การใช้คําว่า "ต้อง" "ต้องไม่" "ต้อง" "ควร" "ไม่ควร"
"แนะนํา" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่กําหนดไว้ใน RFC2119
[แหล่งข้อมูล, 1]
"ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" ในเอกสารนี้หมายถึงบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 4.1
"การติดตั้ง
ใช้งานอุปกรณ์" หรือ "การติดตั้งใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น
การใช้งานอุปกรณ์ต้องเป็นไปตาม
ข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ รวมถึงเอกสารใดๆ
ที่รวมไว้ผ่านการอ้างอิง จึงจะถือว่าเข้ากันได้กับ Android 4.1
ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 10 ไม่มีรายละเอียด
คลุมเครือ หรือไม่สมบูรณ์ ผู้ที่ติดตั้งใช้งานอุปกรณ์มีหน้าที่รับผิดชอบในการตรวจสอบ
ความเข้ากันได้กับการติดตั้งใช้งานที่มีอยู่
ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android [แหล่งข้อมูล 3] จึงถือเป็นทั้งข้อมูลอ้างอิง
และการใช้งาน Android ที่แนะนำ เราขอแนะนําอย่างยิ่งให้นักพัฒนาแอปอุปกรณ์อิงตามการใช้งานจาก
ซอร์สโค้ด"ต้นทาง" ที่มีอยู่จากโปรเจ็กต์โอเพนซอร์ส Android มากที่สุด
แม้ว่า
คอมโพเนนต์บางอย่างจะแทนที่ด้วยการติดตั้งใช้งานทางเลือกได้ แต่เราไม่แนะนํา
แนวทางนี้อย่างยิ่ง เนื่องจากจะทำให้การทดสอบซอฟต์แวร์ผ่านได้ยาก
ยิ่งขึ้น ผู้ใช้งานมีหน้าที่ตรวจสอบว่า
ลักษณะการทำงานเข้ากันได้กับการใช้งาน Android มาตรฐานอย่างเต็มรูปแบบ รวมถึงนอกเหนือจาก
ชุดเครื่องมือทดสอบความเข้ากันได้ สุดท้าย โปรดทราบว่าเอกสารนี้ห้าม
การดัดแปลงและการเปลี่ยนชิ้นส่วนบางอย่างอย่างชัดเจน
2. แหล่งข้อมูล
1.  ระดับข้อกำหนด RFC2119 ของ IETF: http://www.ietf.org/rfc/rfc2119.txt
2.  ภาพรวมโปรแกรมความเข้ากันได้กับอุปกรณ์ Android:
http://source.android.com/compatibility/index.html
3.  โครงการโอเพนซอร์ส Android: http://source.android.com/
4.  คำจำกัดความและเอกสารประกอบของ API:
http://developer.android.com/reference/packages.html
5.  ข้อมูลอ้างอิงเกี่ยวกับสิทธิ์ของ Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  ข้อมูลอ้างอิงสำหรับ android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  สตริงเวอร์ชันที่อนุญาตของ Android 4.1
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  การเร่งด้วยฮาร์ดแวร์:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  คลาส android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  ความสามารถของ HTML5 ออฟไลน์: http://dev.w3.org/html5/spec/Overview.html#offline
13.  แท็กวิดีโอ HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  HTML5/W3C Geolocation API: http://www.w3.org/TR/geolocation-API/
15.  เว็บฐานข้อมูล HTML5/W3C API: http://www.w3.org/TR/webdatabase/
16.  HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.  ข้อกําหนดของ Dalvik Virtual Machine: มีอยู่ในซอร์สโค้ด Android ที่
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  การแจ้งเตือน:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  แหล่งข้อมูลแอปพลิเคชัน: http://code.google.com/android/reference/available-
resources.html
21.  คู่มือสไตล์ไอคอนแถบสถานะ:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Search Manager:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toast: http://developer.android.com/reference/android/widget/Toast.html
24.  ธีม: http://developer.android.com/guide/topics/ui/themes.html

25.  คลาส R.style: http://developer.android.com/reference/android/R.style.html
26.  เอกสารประกอบเกี่ยวกับ Wal ที่เผยแพร่อยู่: http://developer.android.com/resources/articles/live-
wal papers.html
27.  การจัดการอุปกรณ์ Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  คลาส android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  API บริการการช่วยเหลือพิเศษของ Android:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  Android Accessibility APIs:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  โปรเจ็กต์ Eyes Free: http://code.google.com/p/eyes-free
32  Text-To-Speech API:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  เอกสารประกอบของเครื่องมืออ้างอิง (สำหรับ ADB, aapt, ddms):
http://developer.android.com/guide/developing/tools/index.html
34.  คำอธิบายไฟล์ APK ของ Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  เครื่องมือทดสอบ Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  คลาส android.content.pm.PackageManager และฟีเจอร์ของฮาร์ดแวร์ Android
รายการ
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  การรองรับหลายหน้าจอ:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  Bluetooth API:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  โปรโตคอล Push ของ NDEF: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API การวางแนวกล้อง:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53.  USB Host API: http://developer.android.com/guide/topics/usb/host.html
54.  ข้อมูลอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์ของ Android
http://developer.android.com/guide/topics/security/security.html
55.  แอปสําหรับ Android: http://code.google.com/p/apps-for-android
56.  คลาส android.app.DownloadManager
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  รูปแบบสื่อของ Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  NFC Connection Handover: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  การจับคู่บลูทูธที่ปลอดภัยและง่ายดายโดยใช้ NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  Wifi Multicast API:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Action Assist:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  ข้อกำหนดการชาร์จผ่าน USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  เสียงผ่าน USB ของ Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  การตั้งค่าการแชร์ NFC ของ Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wi-Fi Direct (Wi-Fi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  การกำหนดค่าอินพุตแบบสัมผัส: http://source.android.com/tech/input/touch-
devices.html
แหล่งข้อมูลเหล่านี้จำนวนมากมาจาก Android 4.1 SDK โดยตรงหรือโดยอ้อม
และจะทํางานได้เหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ใน
กรณีที่คำจำกัดความความเข้ากันได้นี้หรือชุดทดสอบความเข้ากันได้ขัดแย้งกับ
เอกสารประกอบ SDK ระบบจะถือว่าเอกสารประกอบ SDK นั้นน่าเชื่อถือ
รายละเอียดทางเทคนิคที่ระบุไว้ในข้อมูลอ้างอิงซึ่งรวมอยู่ด้านบนถือว่า
รวมอยู่ในคำจำกัดความความเข้ากันได้นี้
3. ซอฟต์แวร์
3.1. ความเข้ากันได้ของ Managed API
สภาพแวดล้อมการเรียกใช้ที่มีการจัดการ (Dalvik) เป็นแพลตฟอร์มหลักสำหรับแอปพลิเคชัน Android
Application Programming Interface (API) ของ Android คือชุด
อินเทอร์เฟซแพลตฟอร์ม Android ที่แสดงต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อม VM ที่มีการจัดการ
การติดตั้งใช้งานในอุปกรณ์ต้องใช้งานอย่างสมบูรณ์
รวมถึงลักษณะการทำงานทั้งหมดที่ระบุไว้ในเอกสารของ API ที่ระบุไว้ในเอกสารของ Android
4.1 SDK [แหล่งข้อมูล, 4]
การติดตั้งใช้งานในอุปกรณ์ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือ
ลายเซ็น API เบี่ยงเบนจากลักษณะการทำงานที่ระบุไว้ในเอกสาร หรือรวมการดำเนินการที่ไม่มีผล ยกเว้นในกรณีที่
ได้รับอนุญาตโดยเจาะจงจากคำจำกัดความความเข้ากันได้นี้
คำจำกัดความความเข้ากันได้นี้อนุญาตให้การใช้งานอุปกรณ์ละเว้นฮาร์ดแวร์บางประเภทที่ Android
มี API ในกรณีเช่นนี้ API จะต้อง
ยังคงอยู่และทํางานอย่างสมเหตุสมผล โปรดดู
ข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ในส่วนที่ 7
3.2. ความเข้ากันได้ของ API แบบ "ซอฟต์"
นอกเหนือจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API แบบ "ซอฟต์" ที่สำคัญ
สำหรับรันไทม์เท่านั้นในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และ
แง่มุมที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ขณะคอมไพล์แอปพลิเคชัน

3.2.1. สิทธิ์
ผู้ติดตั้งใช้งานอุปกรณ์ต้องรองรับและบังคับใช้ค่าคงที่ของสิทธิ์ทั้งหมดตามที่ระบุไว้ใน
หน้าข้อมูลอ้างอิงเกี่ยวกับสิทธิ์ [แหล่งข้อมูล, 5] โปรดทราบว่าส่วนที่ 10
แสดงข้อกำหนดเพิ่มเติมที่เกี่ยวข้องกับรูปแบบความปลอดภัยของ Android
3.2.2. พารามิเตอร์การสร้าง
API ของ Android มีค่าคงที่หลายรายการในคลาส android.os.Build
[Resources, 6] ซึ่งมีไว้เพื่ออธิบายอุปกรณ์ปัจจุบัน ตารางด้านล่างมี
ข้อจํากัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ ซึ่งการติดตั้งใช้งานอุปกรณ์ต้อง
เป็นไปตามข้อกําหนด เพื่อให้ค่าต่างๆ ที่สอดคล้องกันและ
มีความหมายในการติดตั้งใช้งานอุปกรณ์
พารามิเตอร์
ความคิดเห็น
เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่อ่านได้ ช่องนี้ต้องมี
android.os.Build.VERSION.RELEASE
ค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ใน [Resources, 7]
เวอร์ชันของระบบปฏิบัติการ Android ที่ทำงานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้
android.os.Build.VERSION.SDK
สำหรับ Android 4.1 ช่องนี้ต้องมีค่าจำนวนเต็ม 16

เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้
android.os.Build.VERSION.SDK_INT
สำหรับ Android 4.1 ช่องนี้ต้องมีค่าจำนวนเต็ม 16
ค่าที่ผู้ใช้อุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android
ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ค่านี้ต้องไม่นําไปใช้ซ้ำกับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้
android.os.Build.VERSION.INCREMENTAL
ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มา
ที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่า
ต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
ค่าที่ผู้ใช้อุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เจาะจงซึ่งอุปกรณ์ใช้อยู่ในรูปแบบ
ที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือเพื่อระบุการแก้ไขที่เฉพาะเจาะจงของบอร์ดที่ขับเคลื่อน
android.os.Build.BOARD
อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป
"^[a-zA-Z0-9.,_-]+$"
ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุชื่อบริษัท องค์กร บุคคล ฯลฯ
ที่ผลิตอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือเพื่อระบุ OEM
android.os.Build.BRAND
และ/หรือผู้ให้บริการที่ขายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตได้และตรงกับ
นิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ ดูส่วน 3.3: API เนทีฟ
android.os.Build.CPU_ABI
ความเข้ากันได้
ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ ดูส่วนที่ 3.3: ความเข้ากันได้ของ
android.os.Build.CPU_ABI2
API แบบเนทีฟ
ค่าที่ผู้ใช้อุปกรณ์เลือกเพื่อระบุการกำหนดค่าหรือเวอร์ชันที่เฉพาะเจาะจงของอุปกรณ์
android.os.Build.DEVICE
(บางครั้งเรียกว่า "การออกแบบอุตสาหกรรม") ของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น
ASCI 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน โดยควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตาม
เทมเพลตนี้:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
ตัวอย่างเช่น
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
ลายนิ้วมือต้องไม่มีอักขระเว้นวรรค หากฟิลด์อื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมี
อักขระเว้นวรรค คุณต้องแทนที่ด้วยอักขระอื่นในลายนิ้วมือของบิลด์ เช่น อักขระ
ขีดล่าง ("_") ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตได้
ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งเคอร์เนลหรือ /proc) โดยควรเป็น
android.os.Build.HARDWARE
ที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-
zA-Z0-9.,_-]+$"
สตริงที่ระบุโฮสต์ที่ใช้สร้างบิลด์ในลักษณะที่ไม่ซ้ำกันในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนด
android.os.Build.HOST
สำหรับรูปแบบที่เฉพาะเจาะจงของช่องนี้ ยกเว้นว่าต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
ตัวระบุที่ผู้ใช้งานอุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้
ช่องนี้อาจเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่
android.os.Build.ID
มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกความแตกต่างระหว่างบิลด์ซอฟต์แวร์ ค่าของช่องนี้ต้องเข้ารหัสได้
เป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
ชื่อทางการค้าของผู้ผลิตอุปกรณ์เดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดสำหรับ
android.os.Build.MANUFACTURER
รูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
ค่าที่นักพัฒนาแอปอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางรู้จัก
android.os.Build.MODEL
ควรเป็นชื่อเดียวกับที่ใช้ในการทําการตลาดและขายอุปกรณ์ให้แก่ผู้ใช้ปลายทาง ไม่มี
ข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
ค่าที่ผู้ใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์
android.os.Build.PRODUCT
(SKU) ต้องอ่านออกได้ แต่ไม่จำเป็นต้องมีไว้ให้ผู้ใช้ปลายทางดู ค่าของ
ช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
หมายเลขซีเรียลของฮาร์ดแวร์ (หากมี) ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับ
android.os.Build.SERIAL
นิพจน์ทั่วไป "^([a-zA-Z0-9]{0,20})$"
รายการแท็กคั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม เช่น
android.os.Build.TAGS
"unsigned,debug" ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป
"^[a-zA-Z0-9.,_-]+$"
android.os.Build.TIME
ค่าที่แสดงการประทับเวลาของเวลาที่บิลด์เกิดขึ้น
ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้
ควรมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ "user",
android.os.Build.TYPE
"userdebug" หรือ "eng" ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCI 7 บิตและตรงกับนิพจน์ทั่วไป
"^[a-zA-Z0-9.,_-]+$"
ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์
android.os.Build.USER
ไม่มีข้อกำหนดเกี่ยวกับ
รูปแบบที่เจาะจงของช่องนี้
ยกเว้นว่าต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
3.2.3. ความเข้ากันได้ของ Intent
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามระบบ Intent แบบหลวมๆ ของ Android ตามที่

อธิบายไว้ในส่วนด้านล่าง คำว่า "ปฏิบัติตาม" หมายความว่าผู้ใช้งานอุปกรณ์
ต้องระบุกิจกรรมหรือบริการ Android ที่ระบุตัวกรอง Intent ที่ตรงกันและ
เชื่อมโยงกับและใช้ลักษณะการทำงานที่ถูกต้องสำหรับรูปแบบ Intent ที่ระบุแต่ละรายการ
3.2.3.1. Intent ของแอปพลิเคชันหลัก
โปรเจ็กต์ Upstream ของ Android จะกำหนดแอปพลิเคชันหลักจำนวนหนึ่ง เช่น รายชื่อติดต่อ
ปฏิทิน แกลเลอรีรูปภาพ เครื่องเล่นเพลง และอื่นๆ ผู้ติดตั้งใช้งานอุปกรณ์อาจแทนที่
แอปพลิเคชันเหล่านี้ด้วยเวอร์ชันอื่น
อย่างไรก็ตาม เวอร์ชันทางเลือกดังกล่าวต้องเป็นไปตามรูปแบบ Intent เดียวกันที่ระบุโดย
โปรเจ็กต์ต้นทาง ตัวอย่างเช่น หากอุปกรณ์มีโปรแกรมเล่นเพลงอื่น
อุปกรณ์ดังกล่าวต้องยังคงปฏิบัติตามรูปแบบ Intent ที่ออกโดยแอปพลิเคชันของบุคคลที่สามเพื่อเลือกเพลง
แอปพลิเคชันต่อไปนี้ถือเป็นแอปพลิเคชันระบบหลักของ Android
นาฬิกาตั้งโต๊ะ
เบราว์เซอร์
ปฏิทิน
รายชื่อติดต่อ
แกลเลอรี
การค้นหาทั่วโลก
ตัวเปิดแอป
เพลง
การตั้งค่า
แอปพลิเคชันระบบหลักของ Android ประกอบด้วยคอมโพเนนต์ต่างๆ ของกิจกรรมหรือบริการ
ที่ถือว่า "สาธารณะ" กล่าวคือ แอตทริบิวต์ "android:exported" อาจไม่อยู่หรือ
อาจมีค่าเป็น "true"
สําหรับกิจกรรมหรือบริการทุกรายการที่กําหนดไว้ในแอประบบหลักของ Android รายการใดรายการหนึ่งซึ่งไม่ได้
ทําเครื่องหมายว่าไม่ใช่แบบสาธารณะผ่านแอตทริบิวต์ android:exported ที่มีค่าเป็น "false" การใช้งาน
อุปกรณ์ต้องประกอบด้วยคอมโพเนนต์ประเภทเดียวกันที่ใช้รูปแบบตัวกรอง Intent เดียวกับแอประบบหลักของ Android
กล่าวคือ การใช้งานอุปกรณ์อาจแทนที่แอประบบหลักของ Android
แต่หากเป็นเช่นนั้น การใช้งานอุปกรณ์ต้องรองรับรูปแบบ Intent ทั้งหมดที่กําหนดโดย
แอประบบหลักของ Android แต่ละรายการที่จะแทนที่

3.2.3.2. การลบล้าง Intent
เนื่องจาก Android เป็นแพลตฟอร์มที่ขยายได้ การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามลบล้างรูปแบบ Intent
แต่ละรูปแบบที่อ้างอิงในส่วนที่ 3.2.3.2
การใช้งาน
ซอร์สโค้ดแบบเปิดของ Android เวอร์ชันที่พัฒนาขึ้นต้นอนุญาตให้ดำเนินการนี้โดยค่าเริ่มต้น
ผู้ใช้งานอุปกรณ์ต้องไม่แนบสิทธิ์พิเศษไว้กับการใช้
รูปแบบ Intent เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามเชื่อมโยงและควบคุม
รูปแบบเหล่านี้ ข้อห้ามนี้รวมถึงแต่ไม่จํากัดเพียง
การปิดใช้อินเทอร์เฟซผู้ใช้ "ตัวเลือก" ซึ่งช่วยให้ผู้ใช้เลือกระหว่าง
แอปพลิเคชันหลายรายการที่จัดการรูปแบบ Intent เดียวกัน
อย่างไรก็ตาม การใช้งานอุปกรณ์อาจระบุกิจกรรมเริ่มต้นสำหรับรูปแบบ URI
ที่เฉพาะเจาะจง (เช่น http://play.google.com) หากกิจกรรมเริ่มต้นมีตัวกรองที่เฉพาะเจาะจงมากขึ้น
สำหรับ URI ข้อมูล ตัวอย่างเช่น ตัวกรอง Intent ที่ระบุ URI ของข้อมูล
"http://www.android.com" จะเจาะจงกว่าตัวกรองเบราว์เซอร์สําหรับ "http://" การติดตั้งใช้งาน
ในอุปกรณ์ต้องจัดให้มีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้แก้ไขกิจกรรมเริ่มต้น
สำหรับ Intent
3.2.3.3. เนมสเปซของ Intent
การติดตั้งใช้งานในอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ที่รองรับ
รูปแบบ Intent ใหม่หรือรูปแบบ Broadcast Intent โดยใช้สตริง ACTION, CATEGORY หรือคีย์อื่นๆ
ในเนมสเปซ android.* หรือ com.android.* ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่
รวมคอมโพเนนต์ Android ใดๆ ที่รองรับรูปแบบ Intent ใหม่หรือรูปแบบ Intent แบบ Broadcast
โดยใช้สตริงคีย์ ACTION, CATEGORY หรืออื่นๆ ในสเปซแพ็กเกจที่เป็นของ
องค์กรอื่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่แก้ไขหรือขยาย
รูปแบบ Intent ใดๆ ที่แอปหลักระบุไว้ในส่วนที่ 3.2.3.1 ใช้ การติดตั้งใช้งานอุปกรณ์อาจ
รวมรูปแบบ Intent โดยใช้เนมสเปซที่เชื่อมโยงกับ
องค์กรของตนเองอย่างชัดเจน
การห้ามนี้คล้ายกับการห้ามที่ระบุไว้สำหรับคลาสภาษา Java ในส่วน
3.6
3.2.3.4. การออกอากาศ Intent
แอปพลิเคชันของบุคคลที่สามอาศัยแพลตฟอร์มในการออกอากาศ Intent บางรายการเพื่อแจ้งให้ทราบ

เกี่ยวกับการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์ อุปกรณ์ที่ใช้ร่วมกับ Android ได้
ต้องออกอากาศ Intent การออกอากาศแบบสาธารณะเพื่อตอบสนองต่อเหตุการณ์
ที่เหมาะสมของระบบ Intent แบบออกอากาศมีคำอธิบายอยู่ในเอกสารประกอบของ SDK
3.3. ความเข้ากันได้ของ API เดิม
3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
โค้ดที่มีการจัดการซึ่งทำงานใน Dalvik สามารถคอมไพล์เป็นโค้ดแบบเนทีฟที่ระบุไว้ในไฟล์
.apk ของแอปพลิเคชันเป็นไฟล์ ELF .so ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์ของอุปกรณ์ที่เหมาะสม
เนื่องจากโค้ดแบบเนทีฟต้องอาศัยเทคโนโลยีโปรเซสเซอร์พื้นฐานเป็นอย่างมาก Android
จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) หลายรายการใน NDK ของ Android ในไฟล์
docs/CPU-ARCH-ABIS.html หากการใช้งานอุปกรณ์เข้ากันได้กับ ABI ที่กําหนดไว้
อย่างน้อย 1 รายการ ก็ควรใช้ร่วมกับ Android NDK ได้ ดังที่ระบุไว้ด้านล่าง
หากการติดตั้งใช้งานอุปกรณ์รองรับ ABI ของ Android อุปกรณ์จะต้องมีคุณสมบัติดังนี้
ต้องรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกใช้
โค้ดเนทีฟ โดยใช้ความหมายของอินเทอร์เฟซแบบเนทีฟของ Java (JNI) มาตรฐาน
ต้องเข้ากันได้กับซอร์สโค้ด (กล่าวคือ เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ
ABI) กับไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) เนทีฟที่รองรับ
โดยอุปกรณ์อย่างถูกต้องผ่าน API android.os.Build.CPU_ABI
ต้องรายงานเฉพาะ ABI ที่มีการบันทึกไว้ใน Android
NDK เวอร์ชันล่าสุดในไฟล์ docs/CPU-ARCH-ABIS.txt
ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโปรเจ็กต์โอเพนซอร์สของ Android ต้นทาง
API โค้ดเนทีฟต่อไปนี้ต้องพร้อมใช้งานสำหรับแอปที่มีโค้ดเนทีฟ
libc (ไลบรารี C)
libm (ไลบรารีคณิตศาสตร์)
การรองรับ C++ ขั้นต่ำ
อินเทอร์เฟซ JNI
liblog (การบันทึกของ Android)
libz (การบีบอัด Zlib)
libdl (ตัวลิงก์แบบไดนามิก)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (การจัดการพื้นผิว OpenGL เนทีฟ)
libjnigraphics.so
libOpenSLES.so (การรองรับเสียง OpenSL ES 1.0.1)
libOpenMAXAL.so (การรองรับ OpenMAX AL 1.0.1)
libandroid.so (การรองรับกิจกรรมเนทีฟของ Android)
การรองรับ OpenGL ตามที่อธิบายไว้ด้านล่าง
โปรดทราบว่ารุ่นต่อๆ ไปของ Android NDK อาจรองรับ
ABI เพิ่มเติม
หากการติดตั้งใช้งานอุปกรณ์ใช้งานร่วมกับ ABI ที่กําหนดไว้ล่วงหน้าไม่ได้
ต้องไม่รายงานการรองรับ ABI ใดๆ เลย
ความเข้ากันได้ของโค้ดเนทีฟเป็นเรื่องท้าทาย ด้วยเหตุนี้ เราจึงขอย้ำอีกครั้งว่า
เราขอแนะนำให้ผู้ใช้งานอุปกรณ์ใช้
การติดตั้งใช้งานupstreamของไลบรารีที่ระบุไว้ข้างต้นเพื่อช่วยให้มั่นใจว่าอุปกรณ์จะใช้งานร่วมกันได้
3.4. ความเข้ากันได้ของเว็บ
3.4.1. ความเข้ากันได้ของ WebView
การใช้งานโอเพนซอร์สของ Android ใช้เครื่องมือแสดงผล WebKit เพื่อ
ใช้งาน android.webkit.WebView เนื่องจากการพัฒนา
ชุดทดสอบที่ครอบคลุมสำหรับระบบการแสดงผลเว็บนั้นไม่สามารถทำได้ ผู้ใช้งานอุปกรณ์จึงต้องใช้
บิลด์ที่อัปเดตจาก upstream ของ WebKit ที่เฉพาะเจาะจงในการใช้งาน WebView โดยเฉพาะอย่างยิ่ง
การติดตั้งใช้งาน android.webkit.WebView ของการติดตั้งใช้งานอุปกรณ์ต้อง
อิงตามบิลด์ WebKit 534.30 จากต้นทางของซอร์สโค้ดแบบเปิดของ Android
สำหรับ Android 4.1 บิลด์นี้รวมชุดฟังก์ชันการทำงานและ
การแก้ไขด้านความปลอดภัยที่เฉพาะเจาะจงสำหรับ WebView ผู้ติดตั้งใช้งานอุปกรณ์อาจรวมการปรับแต่งไว้ใน
การติดตั้งใช้งาน WebKit แต่การปรับแต่งดังกล่าวต้องไม่เปลี่ยนแปลง
ลักษณะการทํางานของ WebView รวมถึงลักษณะการแสดงผล
สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบนี้
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ

ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ
android.os.Build.VERSION.RELEASE
ค่าของสตริง $(LOCALE) ควรเป็นไปตามรูปแบบ ISO สำหรับ
รหัสประเทศและภาษา และควรอ้างอิงถึง
ภาษาที่กําหนดค่าไว้ในปัจจุบันของอุปกรณ์
ค่าของสตริง $(MODEL) ต้องเหมือนกับค่าของ
android.os.Build.MODEL
ค่าของสตริง $(BUILD) ต้องเหมือนกับค่าของ
android.os.Build.ID
การติดตั้งใช้งานอุปกรณ์อาจไม่ใส่ Mobile ในสตริง User Agent
คอมโพเนนต์ WebView ควรรองรับ HTML5
[แหล่งข้อมูล, 11] มากที่สุด การติดตั้งใช้งานอุปกรณ์อย่างน้อยที่สุดต้องรองรับ
API ต่อไปนี้ซึ่งเชื่อมโยงกับ HTML5 ใน WebView
การดำเนินการแคช/ออฟไลน์ของแอปพลิเคชัน [แหล่งข้อมูล, 12]
แท็ก <video> [แหล่งข้อมูล, 13]
ตำแหน่งทางภูมิศาสตร์ [แหล่งข้อมูล, 14]
นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ต้องรองรับ HTML5/W3C Webstorage API
[แหล่งข้อมูล, 15] และควรรองรับ HTML5/W3C IndexedDB API [แหล่งข้อมูล
16] โปรดทราบว่าองค์กรมาตรฐานการพัฒนาเว็บกําลังเปลี่ยนไปใช้
IndexedDB แทน webstorage คาดว่า IndexedDB จะกลายเป็น
คอมโพเนนต์ที่จําเป็นใน Android เวอร์ชันในอนาคต
API ของ HTML5 เช่น JavaScript API ทั้งหมดต้องปิดใช้โดยค่าเริ่มต้นใน WebView
เว้นแต่นักพัฒนาแอปจะเปิดใช้ API เหล่านั้นอย่างชัดเจนผ่าน Android API ปกติ
3.4.2. ความเข้ากันได้กับเบราว์เซอร์
การติดตั้งใช้งานอุปกรณ์ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของ
ผู้ใช้ทั่วไป เบราว์เซอร์แบบสแตนด์อโลนอาจอิงตามเทคโนโลยีเบราว์เซอร์
อื่นที่ไม่ใช่ WebKit อย่างไรก็ตาม แม้ว่าจะใช้แอปพลิเคชันเบราว์เซอร์อื่น คอมโพเนนต์
android.webkit.WebView ที่ให้บริการแก่แอปพลิเคชันของบุคคลที่สามต้อง
basiert auf WebKit ตามที่อธิบายไว้ในส่วนที่ 3.4.1
การติดตั้งใช้งานอาจส่งสตริง User Agent ที่กําหนดเองในแอปพลิเคชันเบราว์เซอร์สแตนด์อโลน

แอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit ต้นทาง
หรือแอปพลิเคชันทดแทนของบุคคลที่สาม) ควรรองรับ
HTML5 [แหล่งข้อมูล, 11] ให้ได้มากที่สุด ขั้นต่ำ การใช้งานอุปกรณ์ต้องรองรับ
API แต่ละรายการต่อไปนี้ซึ่งเชื่อมโยงกับ HTML5
แคชแอปพลิเคชัน/การดำเนินการแบบออฟไลน์ [แหล่งข้อมูล, 12]
แท็ก <video> [แหล่งข้อมูล, 13]
ตำแหน่งทางภูมิศาสตร์ [แหล่งข้อมูล, 14]
นอกจากนี้ การใช้งานอุปกรณ์ต้องรองรับ HTML5/W3C Webstorage API
[แหล่งข้อมูล, 15] และควรรองรับ HTML5/W3C IndexedDB API [แหล่งข้อมูล,
16] โปรดทราบว่าเมื่อองค์กรมาตรฐานการพัฒนาเว็บเริ่มหันมาใช้
IndexedDB แทน Web Storage คาดว่า IndexedDB จะกลายเป็น
คอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันในอนาคต
3.5. ความเข้ากันได้ของลักษณะการทํางานของ API
ลักษณะการทํางานของ API แต่ละประเภท (ที่มีการจัดการ ซอฟต์ เนทีฟ และเว็บ) ต้อง
สอดคล้องกับการใช้งานที่ต้องการของโปรเจ็กต์โอเพนซอร์สต้นทางของ Android
[แหล่งข้อมูล 3] ขอบเขตการทำงานที่เข้ากันได้ที่เฉพาะเจาะจง ได้แก่
อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทำงานหรือความหมายของ Intent มาตรฐาน
อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจรของคอมโพเนนต์ระบบ
บางประเภท (เช่น บริการ กิจกรรม ContentProvider ฯลฯ)
อุปกรณ์ต้องไม่เปลี่ยนแปลงความหมายของสิทธิ์มาตรฐาน
รายการข้างต้นเป็นเพียงตัวอย่างบางส่วน ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) จะทดสอบ
ส่วนสำคัญของแพลตฟอร์มเพื่อหาความเข้ากันได้ของลักษณะการทำงาน แต่ไม่ใช่ทั้งหมด
ผู้ติดตั้งใช้งานมีหน้าที่รับผิดชอบในการตรวจสอบความเข้ากันได้ของลักษณะการทำงานกับ
โปรเจ็กต์โอเพนซอร์สของ Android ด้วยเหตุนี้ ผู้ใช้งานอุปกรณ์จึงควรใช้
โค้ดต้นฉบับที่มีให้ผ่านโครงการโอเพนซอร์ส Android หากเป็นไปได้ แทนที่จะ
ติดตั้งใช้งานส่วนสำคัญของระบบอีกครั้ง
3.6. เนมสเปซของ API
Android เป็นไปตามรูปแบบเนมสเปซของแพ็กเกจและคลาสที่กําหนดโดยภาษาโปรแกรม Java

ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่ทำการแก้ไขที่ไม่ได้รับอนุญาต (ดูด้านล่าง) ใน
เนมสเปซของแพ็กเกจ
เหล่านี้เพื่อให้เข้ากันได้กับแอปพลิเคชันของบุคคลที่สาม
java.*
javax.*
sun.*
android.*
com.android.*
การแก้ไขที่ไม่ได้รับอนุญาต ได้แก่
การใช้งานอุปกรณ์ต้องไม่แก้ไข API ที่เผยแพร่ต่อสาธารณะใน
แพลตฟอร์ม Android โดยการเปลี่ยนลายเซ็นเมธอดหรือคลาส หรือนํา
คลาสหรือช่องของคลาสออก
ผู้ใช้งานอุปกรณ์อาจแก้ไขการใช้งาน API พื้นฐานได้ แต่
การแก้ไขดังกล่าวต้องไม่ส่งผลต่อลักษณะการทํางานที่ระบุไว้และ
ลายเซ็นภาษา Java ของ API ที่เผยแพร่ต่อสาธารณะ
ผู้ใช้งานอุปกรณ์ต้องไม่เพิ่มองค์ประกอบที่เผยแพร่ต่อสาธารณะ (เช่น
คลาสหรืออินเทอร์เฟซ หรือช่องหรือเมธอดในคลาสหรืออินเทอร์เฟซที่มีอยู่) ลงใน
API ข้างต้น
"องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือองค์ประกอบใดๆ ที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide"
ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง กล่าวคือ
ผู้ใช้งานอุปกรณ์ต้องไม่เปิดเผย API ใหม่หรือแก้ไข API ที่มีอยู่ในพื้นที่ชื่อ
ที่ระบุไว้ข้างต้น ผู้ติดตั้งใช้งานอุปกรณ์อาจทำการแก้ไขภายในเท่านั้น แต่
ต้องไม่โฆษณาหรือเปิดเผยการแก้ไขเหล่านั้นต่อนักพัฒนาแอป
ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กำหนดเองได้ แต่ API ดังกล่าวต้องไม่อยู่ใน
เนมสเปซที่เป็นของหรืออ้างอิงถึงองค์กรอื่น ตัวอย่างเช่น
ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่ม API ลงในเนมสเปซ com.google.* หรือเนมสเปซที่คล้ายกัน มีเพียง
Google เท่านั้นที่เพิ่มได้ ในทำนองเดียวกัน
Google ต้องไม่เพิ่ม API ลงในเนมสเปซของ
บริษัทอื่นๆ นอกจากนี้ หากการใช้งานอุปกรณ์มี API ที่กำหนดเองนอก
เนมสเปซ Android มาตรฐาน API เหล่านั้นต้องได้รับการบรรจุใน
ไลบรารีที่แชร์ของ Android เพื่อให้มีเพียงแอปที่ใช้ API เหล่านั้นอย่างชัดเจน (ผ่านกลไก <uses-library>
) เท่านั้นที่ได้รับผลกระทบจากการใช้หน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว
หากผู้ใช้งานอุปกรณ์เสนอให้ปรับปรุงเนมสเปซแพ็กเกจใดแพ็กเกจหนึ่งข้างต้น
(เช่น การเพิ่มฟังก์ชันการทำงานใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือการเพิ่ม API ใหม่)
ผู้ใช้งานควรไปที่ source.android.com และเริ่มกระบวนการมีส่วนร่วมใน
การเปลี่ยนแปลงและโค้ด ตามข้อมูลในเว็บไซต์ดังกล่าว
โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับรูปแบบมาตรฐานในการตั้งชื่อ API ใน
ภาษาโปรแกรม Java ส่วนนี้มีจุดประสงค์เพียงเพื่อเสริม
รูปแบบเหล่านั้นและทำให้รูปแบบเหล่านั้นมีผลบังคับใช้ผ่านการรวมไว้ในคำจำกัดความความเข้ากันได้นี้
3.7. ความเข้ากันได้กับเครื่องเสมือน
การติดตั้งใช้งานในอุปกรณ์ต้องรองรับข้อกําหนดของไบต์โค้ด Dalvik Executable (DEX)
ทั้งหมดและความหมายของ Dalvik Virtual Machine [แหล่งข้อมูล, 17]
การติดตั้งใช้งานอุปกรณ์ต้องกำหนดค่า Dalvik เพื่อจัดสรรหน่วยความจำตาม
แพลตฟอร์ม Android ต้นทาง และตามที่ระบุไว้ในตารางต่อไปนี้ (ดูคำจำกัดความของขนาดหน้าจอและความหนาแน่นของหน้าจอใน
ส่วนที่ 7.1.1)
โปรดทราบว่าค่าหน่วยความจำที่ระบุไว้ด้านล่างถือเป็นค่าต่ำสุด และ
การติดตั้งใช้งานอุปกรณ์อาจจัดสรรหน่วยความจำต่อแอปพลิเคชันมากกว่านี้
ขนาดหน้าจอ
ความหนาแน่นของหน้าจอ
หน่วยความจำของแอปพลิเคชัน
smal  / normal / large
ldpi / mdpi
16MB
smal  / normal / large
tvdpi / hdpi
32MB
smal  / normal / large
xhdpi
64MB
xlarge
mdpi
32MB
xlarge
tvdpi / hdpi
64MB
xlarge
xhdpi
128MB
3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.8.1. วิดเจ็ต
Android กําหนดประเภทคอมโพเนนต์และ API ที่เกี่ยวข้อง รวมถึงวงจรชีวิตของแอปพลิเคชันซึ่งช่วยให้

แอปพลิเคชันแสดง "AppWidget" ต่อผู้ใช้ปลายทางได้ [แหล่งข้อมูล, 18] รุ่นอ้างอิงแบบโอเพนซอร์สของAndroid
มีแอปพลิเคชัน Launcher ที่มีฟีเจอร์ต่างๆ ใน
อินเทอร์เฟซผู้ใช้ ซึ่งช่วยให้ผู้ใช้เพิ่ม ดู และนำ App Widgets ออกจาก
หน้าจอหลักได้
การติดตั้งใช้งานอุปกรณ์อาจใช้ทางเลือกอื่นแทน Launcher อ้างอิง (เช่น
หน้าจอหลัก) โปรแกรมเปิดใช้งานทางเลือกควรรองรับ App Widgets ในตัว
และแสดงสิ่งอํานวยความสะดวกของอินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ
App Widgets ออกได้โดยตรงภายในโปรแกรมเปิดใช้งาน แต่ Launcher ทางเลือกอาจไม่มีองค์ประกอบ
อินเทอร์เฟซผู้ใช้เหล่านี้ได้ อย่างไรก็ตาม หากไม่มีองค์ประกอบเหล่านี้ การใช้งานอุปกรณ์ต้อง
มีแอปพลิเคชันแยกต่างหากที่เข้าถึงได้จาก Launcher ซึ่งอนุญาตให้ผู้ใช้เพิ่ม
กำหนดค่า ดู และนำ App Widgets ออก
การติดตั้งใช้งานอุปกรณ์ต้องสามารถแสดงผลวิดเจ็ตขนาด 4 x 4 ใน
ขนาดตารางกริดมาตรฐาน (ดูรายละเอียดได้ในหลักเกณฑ์การออกแบบวิดเจ็ตแอปใน
เอกสารประกอบ Android SDK [แหล่งข้อมูล, 18]
3.8.2. การแจ้งเตือน
Android มี API ที่ช่วยให้นักพัฒนาแอปแจ้งผู้ใช้เกี่ยวกับเหตุการณ์สำคัญได้
[แหล่งข้อมูล, 19] โดยใช้ฟีเจอร์ฮาร์ดแวร์และซอฟต์แวร์ของอุปกรณ์
API บางรายการอนุญาตให้แอปพลิเคชันทำการแจ้งเตือนหรือดึงดูดความสนใจโดยใช้
ฮาร์ดแวร์ โดยเฉพาะเสียง การสั่น และแสง การติดตั้งใช้งานอุปกรณ์ต้อง
รองรับการแจ้งเตือนที่ใช้ฟีเจอร์ฮาร์ดแวร์ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
และรองรับการใช้งานฮาร์ดแวร์ของอุปกรณ์เท่าที่จะทำได้
เช่น หากการติดตั้งใช้งานอุปกรณ์มีเครื่องสั่น การติดตั้งใช้งานต้อง
ใช้ API การสั่นอย่างถูกต้อง หากการติดตั้งใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์
API ที่เกี่ยวข้องต้องติดตั้งใช้งานแบบไม่มีการดำเนินการ โปรดทราบว่า
ลักษณะการทํางานนี้มีรายละเอียดเพิ่มเติมในส่วนที่ 7
นอกจากนี้ การติดตั้งใช้งานต้องแสดงผลทรัพยากรทั้งหมด (ไอคอน ไฟล์เสียง
ฯลฯ) ที่ระบุไว้ใน API [แหล่งข้อมูล 20] หรือในคู่มือสไตล์ไอคอน
แถบสถานะ/แถบระบบ [แหล่งข้อมูล 21] อย่างถูกต้อง ผู้ติดตั้งใช้งานอุปกรณ์อาจให้
ประสบการณ์การใช้งานการแจ้งเตือนระบบอื่นแก่ผู้ใช้นอกเหนือจากที่ การติดตั้งใช้งาน
โอเพนซอร์ส Android อ้างอิงให้ แต่ระบบการแจ้งเตือนระบบอื่นดังกล่าวต้องรองรับ
แหล่งข้อมูลการแจ้งเตือนที่มีอยู่ดังที่ระบุไว้ข้างต้น
Android 4.1 รองรับการแจ้งเตือนแบบริชมีเดีย เช่น มุมมองแบบอินเทอร์แอกทีฟสําหรับ
การแจ้งเตือนอย่างต่อเนื่อง การติดตั้งใช้งานในอุปกรณ์ต้องแสดงและดำเนินการ
การแจ้งเตือนแบบริชมีเดียอย่างถูกต้องตามที่ระบุไว้ใน Android API
3.8.3. การค้นหา
Android มี API [แหล่งข้อมูล, 22] ที่ช่วยนักพัฒนาแอปผสานการค้นหาเข้ากับ
แอปพลิเคชัน และแสดงข้อมูลแอปพลิเคชันในการค้นหาระบบทั่วโลก
โดยทั่วไปแล้ว ฟังก์ชันการทำงานนี้ประกอบด้วยอินเทอร์เฟซผู้ใช้แบบรวมทั่วทั้งระบบ
ที่ช่วยให้ผู้ใช้ได้ป้อนข้อความค้นหา แสดงคำแนะนำขณะที่ผู้ใช้พิมพ์ และแสดง
ผลลัพธ์ Android API ช่วยให้นักพัฒนาแอปนําอินเทอร์เฟซนี้ไปใช้ซ้ำเพื่อให้บริการค้นหา
ภายในแอปของตนเอง และช่วยให้นักพัฒนาแอประบุผลการค้นหาไปยังอินเทอร์เฟซผู้ใช้
การค้นหาทั่วโลกได้
การติดตั้งใช้งานในอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้การค้นหา
แบบแชร์ทั่วทั้งระบบรายการเดียวที่แสดงคำแนะนำแบบเรียลไทม์เพื่อตอบสนองต่ออินพุตของผู้ใช้ การติดตั้งใช้งาน
อุปกรณ์ต้องใช้งาน API ที่อนุญาตให้นักพัฒนาแอปนำ
อินเทอร์เฟซผู้ใช้นี้ไปใช้ซ้ำเพื่อให้บริการค้นหาภายในแอปพลิเคชันของตนเอง การติดตั้งใช้งานในอุปกรณ์
ต้องติดตั้งใช้งาน API ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามเพิ่มคำแนะนำลงใน
ช่องค้นหาเมื่อทำงานในโหมดการค้นหาแบบทั่วไป หากไม่มี
การติดตั้งแอปพลิเคชันของบุคคลที่สามที่ใช้ฟังก์ชันการทำงานนี้ ลักษณะการทำงานเริ่มต้นควรแสดง
ผลการค้นหาและคำแนะนำของเครื่องมือค้นหาบนเว็บ
3.8.4. Toast
แอปพลิเคชันสามารถใช้ API "Toast" (ตามที่ระบุไว้ใน [แหล่งข้อมูล, 23]) เพื่อแสดงสตริงสั้นๆ ที่ไม่ใช่
โมดัลต่อผู้ใช้ปลายทาง ซึ่งจะหายไปหลังจากผ่านไประยะหนึ่ง
การติดตั้งใช้งานในอุปกรณ์ต้องแสดงข้อความแจ้งจากแอปพลิเคชันต่อผู้ใช้ปลายทางในลักษณะที่
มองเห็นได้ชัดเจน
3.8.5. ธีม
Android มี "ธีม" เป็นกลไกสำหรับแอปพลิเคชันเพื่อใช้รูปแบบใน
ทั้งกิจกรรมหรือแอปพลิเคชัน Android 3.0 เปิดตัว
ธีม "Holo" หรือ "โฮโลกราฟิก" ใหม่ เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่
รูปลักษณ์และความรู้สึกของธีม Holo ตามที่กําหนดโดย Android SDK [แหล่งข้อมูล, 24]
การติดตั้งใช้งานในอุปกรณ์ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดงต่อ

แอปพลิเคชัน [แหล่งข้อมูล, 25]
Android 4.0 ได้เปิดตัวธีม "ค่าเริ่มต้นของอุปกรณ์" ใหม่ ซึ่งเป็นชุดสไตล์ที่กําหนดไว้สําหรับ
นักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์ของธีม
อุปกรณ์ตามที่ผู้ใช้งานอุปกรณ์กําหนดไว้ การติดตั้งใช้งานอุปกรณ์อาจแก้ไข
แอตทริบิวต์ธีม DeviceDefault ที่แสดงต่อแอปพลิเคชัน [แหล่งข้อมูล, 25]
3.8.6 วอลเปเปอร์เคลื่อนไหว
Android กําหนดประเภทคอมโพเนนต์และ API และวงจรที่เกี่ยวข้องซึ่งช่วยให้
แอปพลิเคชันแสดง "วอลเปเปอร์เคลื่อนไหว" อย่างน้อย 1 รายการต่อผู้ใช้ปลายทางได้ [แหล่งข้อมูล, 26]
วอลเปเปอร์เคลื่อนไหวคือภาพเคลื่อนไหว ลาย หรือรูปภาพที่คล้ายกันซึ่งมีความสามารถรับอินพุตแบบจํากัด
ซึ่งแสดงเป็นวอลเปเปอร์อยู่เบื้องหลังแอปพลิเคชันอื่นๆ
ระบบฮาร์ดแวร์จะถือว่าสามารถแสดงภาพพื้นหลังแบบสดได้อย่างน่าเชื่อถือหากสามารถแสดงภาพพื้นหลังแบบสด
ทั้งหมดโดยไม่มีข้อจำกัดด้านฟังก์ชันการทำงานที่อัตราเฟรมที่เหมาะสมโดยไม่
ส่งผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดของฮาร์ดแวร์ทําให้วอลเปเปอร์
และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้พลังงาน CPU หรือแบตเตอรี่มากเกินไป หรือ
ทำงานด้วยอัตราเฟรมที่ต่ำจนยอมรับไม่ได้ ระบบจะถือว่าฮาร์ดแวร์ไม่สามารถแสดง
วอลเปเปอร์แบบสดได้ ตัวอย่างเช่น วอลเปเปอร์แบบสดบางรายการอาจใช้บริบท Open GL 1.0 หรือ 2.0
เพื่อแสดงผลเนื้อหา ภาพพื้นหลังแบบเคลื่อนไหวจะทำงานอย่างไม่เสถียรในฮาร์ดแวร์
ที่ไม่รองรับบริบท OpenGL หลายรายการ เนื่องจากภาพพื้นหลังแบบเคลื่อนไหวใช้
บริบท OpenGL อาจขัดแย้งกับแอปพลิเคชันอื่นๆ ที่ใช้บริบท OpenGL ด้วย
การติดตั้งใช้งานอุปกรณ์ที่ทํางานวอลล์เปเปอร์แบบสดได้อย่างน่าเชื่อถือตามที่อธิบาย
ไว้ข้างต้นควรใช้วอลล์เปเปอร์แบบสด การติดตั้งใช้งานอุปกรณ์ที่ระบุว่า
ใช้งานวอลเปเปอร์แบบสดได้อย่างน่าเชื่อถือตามที่อธิบายไว้ข้างต้นต้องไม่ใช้งานวอลเปเปอร์แบบสด
3.8.7. การแสดงแอปพลิเคชันล่าสุด
ซอร์สโค้ดจากอัปสตรีมของ Android 4.1 มีอินเทอร์เฟซผู้ใช้สำหรับแสดง
แอปพลิเคชันล่าสุดโดยใช้รูปภาพขนาดย่อของสถานะกราฟิกของแอปพลิเคชัน ณ
เวลาที่ผู้ใช้ออกจากแอปพลิเคชันล่าสุด การใช้งานอุปกรณ์อาจเปลี่ยนแปลงหรือ
นำอินเทอร์เฟซผู้ใช้นี้ออก แต่เราวางแผนที่จะใช้ฟังก์ชันนี้อย่าง
แพร่หลายมากขึ้นใน Android เวอร์ชันในอนาคต เราขอแนะนำอย่างยิ่ง
ให้ใช้อินเทอร์เฟซผู้ใช้ Android 4.1 เวอร์ชันอัปสตรีม (หรืออินเทอร์เฟซที่คล้ายกันซึ่งอิงตามภาพขนาดย่อ
) สำหรับแอปพลิเคชันล่าสุด ไม่เช่นนั้นแอปพลิเคชันอาจใช้งานร่วมกับ
Android เวอร์ชันในอนาคตไม่ได้
3.8.8. การตั้งค่าการจัดการอินพุต
Android 4.1 รองรับเครื่องมือการจัดการอินพุต API ของ Android 4.1
อนุญาตให้ IME ของแอปที่กำหนดเองระบุการตั้งค่าที่ผู้ใช้ปรับได้ การติดตั้งใช้งานในอุปกรณ์
ต้องระบุวิธีให้ผู้ใช้เข้าถึงการตั้งค่า IME ได้ทุกเมื่อที่ IME ที่
มีการตั้งค่าดังกล่าวสำหรับผู้ใช้แสดงอยู่
3.8.9. รีโมตคอนโทรลหน้าจอล็อก
Android 4.0 เริ่มรองรับ Remote Control API ซึ่งช่วยให้แอปพลิเคชันสื่อ
ผสานรวมกับการควบคุมการเล่นที่แสดงในมุมมองระยะไกลได้ เช่น หน้าจอล็อก
ของอุปกรณ์ [แหล่งข้อมูล, 69] การติดตั้งใช้งานอุปกรณ์ควรรองรับ
การฝังการควบคุมจากระยะไกลในหน้าจอล็อกของอุปกรณ์
3.9 การจัดการอุปกรณ์
Android 4.1 มีฟีเจอร์ที่อนุญาตให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยสามารถดำเนินการ
ฟังก์ชันการจัดการอุปกรณ์ที่ระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือ
การล้างข้อมูลระยะไกล ผ่าน Android Device Administration API [แหล่งข้อมูล,
27] การติดตั้งใช้งานอุปกรณ์ต้องระบุการใช้งาน
คลาส DevicePolicyManager [แหล่งข้อมูล, 28] และควรรองรับ
นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่ระบุไว้ในเอกสารประกอบของ Android SDK [แหล่งข้อมูล,
27]
หมายเหตุ: แม้ว่าข้อกำหนดบางประการที่ระบุไว้ข้างต้นจะระบุว่า "ควร" สำหรับ
Android 4.1 แต่เราวางแผนที่จะเปลี่ยนข้อกำหนดเหล่านี้
เป็น "ต้อง" สำหรับเวอร์ชันในอนาคต กล่าวคือ ข้อกำหนดเหล่านี้เป็นข้อกำหนดที่ไม่บังคับใน Android 4.1 แต่จะเป็นข้อกำหนด
บังคับในเวอร์ชันในอนาคต เราขอแนะนํา
อย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ปฏิบัติตามข้อกําหนดเหล่านี้ใน Android 4.1 ไม่เช่นนั้น
อุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
3.10 การช่วยเหลือพิเศษ
Android 4.1 มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่มีความบกพร่องไปยังส่วนต่างๆ ของ
อุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android 4.1 ยังมี API ของแพลตฟอร์มที่ช่วยให้
การใช้งานบริการการช่วยเหลือพิเศษสามารถรับการโทรกลับสำหรับเหตุการณ์ของผู้ใช้และระบบ
รวมถึงสร้างกลไกการแสดงผลผลป้อนกลับทางเลือก เช่น การอ่านออกเสียงข้อความ
การสัมผัส
และการนำทางด้วยแทร็กบอล /ปุ่มบังคับ [แหล่งข้อมูล, 29]

การติดตั้งใช้งานในอุปกรณ์
ต้องติดตั้งใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ที่สอดคล้อง
กับการติดตั้งใช้งาน Android เริ่มต้น โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้อง
เป็นไปตามข้อกำหนดต่อไปนี้
การใช้งานอุปกรณ์ต้องรองรับการใช้งาน
บริการช่วยเหลือพิเศษของบุคคลที่สามผ่าน API ของ android.accessibilityservice [แหล่งข้อมูล
30]
การใช้งานอุปกรณ์ต้องสร้าง AccessibilityEvents และส่ง
เหตุการณ์เหล่านี้ไปยังการใช้งาน AccessibilityService ที่ลงทะเบียนทั้งหมดในลักษณะที่
สอดคล้องกับการใช้งาน Android เริ่มต้น
การใช้งานอุปกรณ์ต้องจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด
และปิดใช้บริการช่วยเหลือพิเศษ และต้องแสดงอินเทอร์เฟซนี้เพื่อตอบสนอง
ต่อ Intent ของ android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS
นอกจากนี้ การใช้งานอุปกรณ์ควรมีการใช้งาน
บริการการช่วยเหลือพิเศษในอุปกรณ์ และควรมีกลไกให้ผู้ใช้
เปิดใช้บริการการช่วยเหลือพิเศษระหว่างการตั้งค่าอุปกรณ์ การใช้งานโอเพนซอร์ส
ของบริการช่วยเหลือพิเศษมีอยู่ในโปรเจ็กต์ Eyes Free [แหล่งข้อมูล, 31]
3.11 การอ่านออกเสียงข้อความ
Android 4.1 มี API ที่อนุญาตให้แอปพลิเคชันใช้บริการการอ่านออกเสียงข้อความ (TTS)
และอนุญาตให้ผู้ให้บริการนำบริการ TTS ไปใช้งาน
[แหล่งข้อมูล, 32] การติดตั้งใช้งานในอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับ
เฟรมเวิร์ก TTS ของAndroid
การติดตั้งใช้งานในอุปกรณ์ต้องรองรับ API ของเฟรมเวิร์ก TTS ของ Android และ
ควรมีเครื่องมือ TTS ที่รองรับภาษาที่มีใน
อุปกรณ์ โปรดทราบว่าซอฟต์แวร์โอเพนซอร์สจากฝั่งต้นทางของ Android มีการใช้งาน
เครื่องมือ TTS ที่มีฟีเจอร์ครบถ้วน
การใช้งานในอุปกรณ์ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
การใช้งานในอุปกรณ์ต้องมีอินเทอร์เฟซที่ผู้ใช้เข้าถึงได้ ซึ่งช่วยให้
ผู้ใช้เลือกเครื่องมือ TTS เพื่อใช้งานในระดับระบบได้
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งและเรียกใช้ไฟล์ ".apk" ของ Android ตามที่สร้างขึ้นโดย
เครื่องมือ"aapt" ซึ่งรวมอยู่ใน Android SDK อย่างเป็นทางการ [แหล่งข้อมูล, 33]
การติดตั้งใช้งานในอุปกรณ์ต้องไม่ขยายรูปแบบ .apk [ทรัพยากร, 34],
ไฟล์ Manifest ของ Android [ทรัพยากร, 35], บา이트โค้ด Dalvik [ทรัพยากร, 17] หรือบา이트โค้ด RendererScript
ในลักษณะที่ทําให้ไฟล์เหล่านั้นติดตั้ง และทํางานได้อย่างถูกต้อง
ในอุปกรณ์อื่นๆ ที่เข้ากันได้ ผู้ติดตั้งใช้งานอุปกรณ์ควรใช้
การติดตั้งใช้งานตามลำดับชั้นบนของ Dalvik และระบบ
การจัดการแพ็กเกจของการติดตั้งใช้งานตามลำดับชั้นบน
5. ความเข้ากันได้กับมัลติมีเดีย
การใช้งานอุปกรณ์ต้องมีเอาต์พุตเสียงอย่างน้อย 1 รูปแบบ เช่น
ลำโพง ช่องเสียบหูฟัง การเชื่อมต่อลำโพงภายนอก ฯลฯ
5.1. ตัวแปลงรหัสสื่อ
การใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อหลักที่ระบุไว้ใน
เอกสารประกอบ Android SDK [แหล่งข้อมูล, 58] ยกเว้นในกรณีที่ได้รับอนุญาตอย่างชัดแจ้งใน
เอกสารนี้ โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อ
โปรแกรมเข้ารหัส โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่ระบุไว้ในตารางด้านล่าง
ตัวแปลงรหัสเหล่านี้ทั้งหมดมีให้ใช้งานเป็นการใช้งานซอฟต์แวร์ในการใช้งาน Android
ที่ต้องการจากโครงการโอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้
รับรองว่าโค้ดเหล่านี้ไม่อยู่ภายใต้สิทธิบัตรของบุคคลที่สาม
เราขอแนะนำให้ผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์
ทราบว่าการใช้งานโค้ดนี้ รวมถึงในซอฟต์แวร์โอเพนซอร์ส
หรือแชร์แวร์ อาจต้องใช้ใบอนุญาตสิทธิบัตรจากผู้ถือสิทธิบัตรที่เกี่ยวข้อง
โปรดทราบว่าตารางเหล่านี้ไม่ได้แสดงข้อกำหนดอัตราบิตที่เฉพาะเจาะจงสำหรับตัวแปลงรหัสวิดีโอส่วนใหญ่
เนื่องจากฮาร์ดแวร์ของอุปกรณ์ปัจจุบันอาจไม่รองรับอัตราบิตที่ตรงกับอัตราบิตที่กำหนดโดยมาตรฐานที่เกี่ยวข้อง
แต่
การใช้งานอุปกรณ์ควรรองรับอัตราบิตสูงสุดที่เป็นไปได้บนฮาร์ดแวร์

ตามขีดจำกัดที่ระบุไว้ในข้อกำหนด

ประเภทไฟล์ /
รูปแบบ /
ประเภท
โปรแกรมเข้ารหัส
โปรแกรมถอดรหัส
รายละเอียด
คอนเทนเนอร์
ตัวแปลงรหัส
รูปแบบ
การรองรับ
ต้องระบุ
โมโน/สเตอริโอ/5.0/5.1*
MPEG-4
ต้องระบุสำหรับการใช้งานอุปกรณ์
เนื้อหาที่มี
โปรไฟล์ AAC
ซึ่งมีฮาร์ดแวร์ไมโครโฟน
ต้องระบุ
การสุ่มตัวอย่างมาตรฐาน
(AAC LC)
และกำหนด
3GPP
อัตรา 8-48
android.hardware.microphone
(.3gp)
kHz
MPEG-4
รองรับ
(.mp4,
MPEG-4
โมโน/สเตอริโอ/5.0/5.1*
.m4a)
HE AAC
เนื้อหา
ADTS ดิบ

ต้องระบุ
โปรไฟล์
การสุ่มตัวอย่างมาตรฐาน
AAC (.aac,
(AAC+)
อัตรา 16 ถึง 48
ถอดรหัสใน
kHz
Android
3.1 ขึ้นไป
การรองรับ
MPEG-4
ต้องระบุ
สำหรับ
อุปกรณ์
ที่เข้ารหัสใน
โมโน/สเตอริโอ/5.0/5.1*
การใช้งาน HE AAC v2
ซึ่งรวมถึง
เนื้อหา
Android
ที่มี
ฮาร์ดแวร์ไมโครโฟน
โปรไฟล์
และ
4.0 ขึ้นไป
การสุ่มตัวอย่างมาตรฐาน ADIF
(กำหนด

ไม่รองรับ
อัตรา
จาก 16 ถึง 48
AAC+)
android.hardware.microphone
)
kHz
MPEG-TS
MPEG-4
(.ts, not
เสียง
ต้องระบุ
สำหรับอุปกรณ์
การรองรับ
การใช้งานที่ข้ามได้
ประเภทออบเจ็กต์
ซึ่งรวมถึง
เนื้อหาโมโน/สเตอริโอ
Android
ER AAC
ฮาร์ดแวร์ไมโครโฟน และ
ต้องระบุ
ด้วยมาตรฐาน
3.0 ขึ้นไป
ELD
กำหนด
อัตราการสุ่มตัวอย่างจาก
(Enhanced
android.hardware.microphone
16 ถึง 48 kHz
Low Delay
AAC)
ต้องระบุ
ต้องระบุสำหรับการใช้งานอุปกรณ์
4.75 ถึง 12.2 kbps
AMR-NB
ที่มีฮาร์ดแวร์ไมโครโฟน
ต้องระบุ
3GPP (.3gp)
ที่อัตราตัวอย่าง 8 kHz
และกำหนด
android.hardware.microphone
ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์
9 อัตราจาก 6.60
AMR-WB
ที่มีฮาร์ดแวร์ไมโครโฟน
ต้องระบุ
kbit/s ถึง 23.85 kbit/s
3GPP (.3gp)
และกำหนด
ที่ 16kHz
android.hardware.microphone
โมโน/สเตอริโอ (ไม่มี
หลายช่อง)
เสียง
อัตราการสุ่มตัวอย่างสูงสุด
48 kHz (แต่
44.1 kHz แนะนำ
ใน
อุปกรณ์ที่มีเอาต์พุต 44.1
ต้อง
ใช้
ไฟล์ FLAC

kHz เนื่องจากตัวแปลงสัญญาณจาก 48
FLAC (.flac) เท่านั้น
(Android 3.1 ขึ้นไป)
เป็น
ตัวแปลงสัญญาณจาก 44.1 kHz

ไม่มี
ฟิลเตอร์ low-pass) แนะนำ 16 บิต
ไม่
ใช้การกรองสัญญาณรบกวนสำหรับ 24
บิต
โมโน/สเตอริโอ 8-
320Kbps คงที่
MP3

ต้องระบุ
MP3 (.mp3)
(CBR) หรือ
อัตราบิตแบบผันแปร (VBR)
ประเภท 0 และ
MIDI ประเภท 0 และ 1
1 (.mid,
DLS เวอร์ชัน 1 และ
.xmf, .mxmf)
2. XMF และ Mobile
RTTTL/RTX
MIDI

ต้องระบุ
XMF รองรับ
(.rtttl, .rtx)
รูปแบบริงโทน
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
และ iMelody
(.imy)

Ogg (.ogg)
Vorbis

ต้องระบุ

Matroska
(.mkv)
8 บิตและ 16 บิต

PCM เชิงเส้น** (อัตรา
สูงสุดตามขีดจำกัดของ
ฮาร์ดแวร์) อุปกรณ์
ต้องรองรับ
PCM/WAVE
ต้องระบุ
ต้องระบุ
WAVE (.wav)
อัตราตัวอย่างสำหรับ
ไฟล์บันทึก PCM ดิบ
ที่ 8000,16000 และ
44100 Hz

JPEG
ต้องระบุ
ต้องระบุ
Base+progressive
JPEG (.jpg)
GIF

ต้องระบุ

GIF (.gif)
รูปภาพ
PNG
ต้องระบุ
ต้องระบุ

PNG (.png)
BMP

ต้องระบุ

BMP (.bmp)
WEBP
ต้องระบุ
ต้องระบุ

WebP (.webp)
ต้องระบุ
ต้องระบุสำหรับการใช้งานอุปกรณ์
3GPP
ที่มีฮาร์ดแวร์กล้องและ
(.3gp)
H.263
ต้องระบุ

กำหนด android.hardware.camera
MPEG-4
หรือ
(.mp4)
android.hardware.camera.front
3GPP
(.3gp)
ต้องระบุ
MPEG-4
(.mp4)
ต้องระบุสำหรับการใช้งานอุปกรณ์
MPEG-TS
ที่มีฮาร์ดแวร์กล้องและ
โปรไฟล์พื้นฐาน
วิดีโอ
H.264 AVC
ต้องระบุ
(.ts, AAC
กำหนด android.hardware.camera
(BP)
เสียงเท่านั้น
หรือ
ไม่ใช่
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4

ต้องระบุ

3GPP (.3gp)
SP
WebM (.webm)
ต้องระบุ
และ Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*หมายเหตุ: ต้องระบุเฉพาะการลดขนาดเนื้อหา 5.0/5.1 เท่านั้น ไม่จำเป็นต้องบันทึกหรือแสดงผลมากกว่า 2
ช่อง **หมายเหตุ: ต้องทำการบันทึก PCM เชิงเส้น 16 บิต ไม่จำเป็นต้องใช้การบันทึก PCM
แบบเชิงเส้น 8 บิต
5.2 การเข้ารหัสวิดีโอ
การใช้งานอุปกรณ์ Android ที่มีกล้องหลังและประกาศ
android.hardware.camera ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอต่อไปนี้
HD (เมื่อฮาร์ดแวร์รองรับ

SD (คุณภาพต่ำ) SD (คุณภาพสูง)
)
H.264 Baseline
H.264 Baseline
ตัวแปลงรหัสวิดีโอ
H.264 Baseline Profile
Profile
Profile
วิดีโอ
176 x 144 px
480 x 360 px
1280 x 720 px
ความละเอียด
เฟรมวิดีโอ 12 fps
30 fps
30 fps
อัตรา
500 Kbps หรือ
อัตราบิตวิดีโอ 56 Kbps
2 Mbps หรือสูงกว่า
สูงกว่า
ตัวแปลงรหัสเสียง AAC-LC
AAC-LC
AAC-LC

เสียง
1 (โมโน)
2 (สเตอริโอ)
2 (สเตอริโอ)
ช่อง
อัตราบิตเสียง 24 Kbps
128 Kbps
192 Kbps
5.3. การบันทึกเสียง
เมื่อแอปพลิเคชันใช้ API android.media.AudioRecord เพื่อเริ่มบันทึก
สตรีมเสียง การใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและ
ประกาศ android.hardware.microphone จะต้องสุ่มตัวอย่างและบันทึกเสียงด้วยลักษณะการทำงานต่อไปนี้

อุปกรณ์ควรแสดงลักษณะความดังของเสียงเทียบกับความถี่ที่ราบเรียบโดยประมาณ
กล่าวคือ ±3 dB จาก 100 Hz ถึง 4000 Hz
ควรตั้งค่าความไวของอินพุตเสียงให้แหล่งที่มาของระดับกำลังเสียง 90 dB
(SPL) ที่ 1000 Hz ให้ค่า RMS เท่ากับ 2500 สำหรับแซมเปิล 16 บิต
ระดับความดังของเสียง PCM ควรติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นในช่วงอย่างน้อย
30 dB จาก -18 dB ถึง +12 dB โดยเทียบกับ 90 dB SPL ที่ไมโครโฟน
ความผิดเพี้ยนของฮาร์โมนิกทั้งหมดควรน้อยกว่า 1% สำหรับ 1 Khz ที่ระดับอินพุต SPL 90 dB

นอกเหนือจากข้อกำหนดเฉพาะในการบันทึกข้างต้นแล้ว เมื่อแอปพลิเคชันเริ่ม
บันทึกสตรีมเสียงโดยใช้
แหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
ต้องปิดใช้การประมวลผลเพื่อลดเสียงรบกวน (หากมี)
ต้องปิดใช้การควบคุมอัตราขยายเสียงอัตโนมัติ (หากมี)
หมายเหตุ: แม้ว่าข้อกำหนดบางส่วนที่ระบุไว้ข้างต้นจะระบุว่า "ควร" สำหรับ
Android 4.1 แต่เราวางแผนที่จะเปลี่ยนข้อกำหนดเหล่านี้
เป็น "ต้อง" สำหรับเวอร์ชันในอนาคต กล่าวคือ ข้อกำหนดเหล่านี้เป็นข้อกำหนดที่ไม่บังคับใน Android 4.1 แต่จะเป็นข้อกำหนด
บังคับในเวอร์ชันในอนาคต เราขอแนะนํา
อย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ปฏิบัติตามข้อกําหนดเหล่านี้ใน Android 4.1 ไม่เช่นนั้น
อุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
5.4. เวลาในการตอบสนองของเสียง
เวลาในการตอบสนองของเสียงหมายถึงช่วงเวลาระหว่างที่แอปพลิเคชันขอ
การดำเนินการเล่นหรือบันทึกเสียง และเวลาที่การใช้งานอุปกรณ์จริง
เริ่มดำเนินการ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองที่ต่ำเพื่อให้ได้
เอฟเฟกต์แบบเรียลไทม์ เช่น เอฟเฟกต์เสียงหรือการสื่อสารผ่าน VOIP การใช้งานอุปกรณ์
ที่มีฮาร์ดแวร์ไมโครโฟนและประกาศ android.hardware.microphone
ควรเป็นไปตามข้อกำหนดทั้งหมดเกี่ยวกับเวลาในการตอบสนองของเสียงที่ระบุไว้ในส่วนนี้ โปรดดูรายละเอียดเกี่ยวกับเงื่อนไขที่
การติดตั้งใช้งานอุปกรณ์
อาจละเว้นฮาร์ดแวร์ไมโครโฟนในส่วนที่ 7
สำหรับวัตถุประสงค์ของส่วนนี้
"เวลาในการตอบสนองของเอาต์พุตแบบเย็น" หมายถึงช่วงเวลาระหว่างที่แอปพลิเคชัน
ขอเล่นเสียงและเวลาที่เสียงเริ่มเล่น เมื่อระบบเสียง
ไม่ได้ใช้งานและปิดอยู่ก่อนการขอ

"เวลาในการตอบสนองของเอาต์พุตแบบอุ่น" หมายถึงช่วงเวลาระหว่างที่แอปพลิเคชัน
ขอเล่นเสียงและเวลาที่เสียงเริ่มเล่น เมื่อระบบเสียง
เพิ่งใช้งานไปและกำลังทำงานอยู่

"เวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่อง" หมายถึงช่วงเวลาระหว่างที่แอปพลิเคชัน
ส่งคำสั่งให้เล่นตัวอย่างเพลงและเวลาที่ลำโพงเล่น
เสียงที่ตรงกัน ขณะที่อุปกรณ์กำลังเล่นเสียงอยู่

"เวลาในการตอบสนองของอินพุตแบบเย็น" หมายถึงช่วงเวลาระหว่างที่แอปพลิเคชัน
ขอบันทึกเสียงและเวลาที่ส่งตัวอย่างเพลงแรกไปยัง
แอปพลิเคชันผ่านแบ็กแคล เมื่อมีการใช้ระบบเสียงและไมโครโฟน
อยู่ก่อนการขอ

"เวลาในการตอบสนองของอินพุตแบบต่อเนื่อง" หมายถึงเวลาที่เสียงรอบข้างเกิดขึ้นและ
เวลาที่ส่งตัวอย่างเพลงที่ตรงกับเสียงนั้นไปยัง
แอปพลิเคชันบันทึกเสียงผ่านแบ็กแคล ขณะที่อุปกรณ์อยู่ในโหมดบันทึกเสียง
ตามคำจำกัดความข้างต้น การใช้งานอุปกรณ์ควรแสดง
คุณสมบัติต่อไปนี้
เวลาในการตอบสนองของเอาต์พุตแบบเย็น 100 มิลลิวินาทีหรือน้อยกว่า
เวลาในการตอบสนองของเอาต์พุตแบบอุ่น 10 มิลลิวินาทีหรือน้อยกว่า
เวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่อง 45 มิลลิวินาทีหรือน้อยกว่า
เวลาในการตอบสนองของอินพุตแบบเย็น 100 มิลลิวินาทีหรือน้อยกว่า
เวลาในการตอบสนองของอินพุตแบบต่อเนื่อง 50 มิลลิวินาทีหรือน้อยกว่า
หมายเหตุ: แม้ว่าข้อกำหนดที่ระบุไว้ข้างต้นจะระบุว่า "ควร" สำหรับ Android 4.1

เราวางแผนที่จะเปลี่ยนข้อกำหนดเหล่านี้เป็น "ต้อง" ในคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคต
กล่าวคือ ข้อกำหนดเหล่านี้เป็นข้อกำหนดที่ไม่บังคับใน Android 4.1 แต่จะเป็นข้อกำหนดที่ต้องปฏิบัติตามในเวอร์ชันในอนาคต
เราขอแนะนําอย่างยิ่ง
ให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ปฏิบัติตามข้อกําหนดเหล่านี้ใน Android 4.1 ไม่เช่นนั้น
อุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้ อุปกรณ์อาจรายงาน
การรองรับเสียงที่มีเวลาในการตอบสนองต่ำ โดยรายงานฟีเจอร์ "android.hardware.audio.low-
latency" ผ่านคลาส android.content.pm.PackageManager [แหล่งข้อมูล, 37]
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดเหล่านี้ อุปกรณ์ต้อง
ไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
5.5. โปรโตคอลเครือข่าย
อุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 58]
โดยเฉพาะอย่างยิ่ง อุปกรณ์
ต้องรองรับโปรโตคอลเครือข่ายสื่อต่อไปนี้
RTSP (RTP, SDP)
การสตรีมแบบเป็นขั้นเป็นตอนของ HTTP(S)
โปรโตคอลฉบับร่างสตรีมมิงแบบสดของ HTTP(S) เวอร์ชัน 3 [แหล่งข้อมูล, 59]
6. ความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนาแอป
การติดตั้งใช้งานอุปกรณ์ต้องรองรับเครื่องมือสำหรับนักพัฒนาแอป Android ที่มีให้ใน
Android SDK โดยเฉพาะอย่างยิ่ง อุปกรณ์ที่ใช้ร่วมกับ Android ได้ต้องเข้ากันได้กับ
Android Debug Bridge (หรือที่เรียกว่า adb) [แหล่งข้อมูล, 33]
การติดตั้งใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ในเอกสารของ
Android SDK Dæmon adb ฝั่งอุปกรณ์ต้องไม่ทำงานโดยค่าเริ่มต้น และ
ต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด
บริดจ์การแก้ไขข้อบกพร่องของ Android
บริการตรวจสอบข้อบกพร่อง Dalvik (หรือที่เรียกว่า ddms) [แหล่งข้อมูล, 33]
การติดตั้งใช้งานอุปกรณ์ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน
SDK ของ Android เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรไม่มีการใช้งานโดย
ค่าเริ่มต้น แต่ต้องรองรับทุกครั้งที่ผู้ใช้เปิดใช้งาน
บริดจ์การแก้ไขข้อบกพร่องของ Android ตามที่ระบุไว้ข้างต้น
Monkey [แหล่งข้อมูล, 36]
การติดตั้งใช้งานในอุปกรณ์ต้องรวมเฟรมเวิร์ก Monkey และทำให้
พร้อมใช้งานสำหรับแอปพลิเคชัน
ระบบที่ใช้ Linux และ Apple Macintosh ส่วนใหญ่จะจดจำอุปกรณ์ Android
โดยใช้เครื่องมือ Android SDK มาตรฐานโดยไม่ต้องมีการสนับสนุนเพิ่มเติม อย่างไรก็ตาม ระบบ Microsoft
Windows มักจะต้องใช้ไดรเวอร์สำหรับอุปกรณ์ Android ใหม่ (เช่น
รหัสผู้ให้บริการใหม่และบางครั้งรหัสอุปกรณ์ใหม่ต้องใช้ไดรเวอร์ USB ที่กําหนดเองสําหรับ
ระบบ Windows) หากเครื่องมือ adb ไม่รู้จักการติดตั้งใช้งานอุปกรณ์ตามที่
ระบุไว้ใน Android SDK มาตรฐาน ผู้ติดตั้งใช้งานอุปกรณ์ต้องจัดหา
ไดรเวอร์ Windows เพื่อให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์ได้โดยใช้โปรโตคอล adb
ไดรเวอร์เหล่านี้ต้องพร้อมใช้งานสำหรับ Windows XP, Windows Vista และ Windows 7 ทั้ง
เวอร์ชัน 32 บิตและ 64 บิต
7. ความเข้ากันได้ของฮาร์ดแวร์
หากอุปกรณ์มีคอมโพเนนต์ฮาร์ดแวร์บางอย่างที่มี API ที่เกี่ยวข้องสำหรับ
นักพัฒนาแอปบุคคลที่สาม การใช้งานอุปกรณ์จะต้องใช้ API ดังกล่าวตามที่
อธิบายไว้ในเอกสารประกอบของ Android SDK หาก API ใน SDK โต้ตอบกับ
คอมโพเนนต์ฮาร์ดแวร์ที่ระบุไว้ว่าไม่บังคับ และการใช้งานอุปกรณ์
ไม่มีคอมโพเนนต์นั้น
จะต้องมีคำจำกัดความคลาสที่สมบูรณ์ (ตามที่ระบุไว้ในเอกสารประกอบของ SDK) สำหรับ
API ของคอมโพเนนต์
ต้องยังคงอยู่
ลักษณะการทำงาน API ต้องใช้งานแบบไม่ดำเนินการใดๆ ในลักษณะที่เหมาะสม
เมธอด API ต้องแสดงผลค่า Null ในกรณีที่เอกสารประกอบของ SDK อนุญาต
เมธอด API ต้องแสดงผลการใช้งานแบบไม่ดำเนินการใดๆ ของคลาสในกรณีที่เอกสารประกอบของ SDK ไม่อนุญาต
เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
ตัวอย่างทั่วไปของสถานการณ์ที่มีการใช้ข้อกำหนดเหล่านี้คือ API โทรคมนาคม
แม้ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็ต้องใช้งาน API เหล่านี้แบบไม่ดำเนินการใดๆ ในลักษณะที่เหมาะสม

การติดตั้งใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์
ที่ถูกต้องผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String)
ในคลาส android.content.pm.PackageManager [Resources, 37]
7.1. การแสดงผลและกราฟิก
Android 4.1 มีเครื่องมือที่ปรับชิ้นงานแอปพลิเคชันและเลย์เอาต์ UI
ตามความเหมาะสมของอุปกรณ์โดยอัตโนมัติ เพื่อให้แอปพลิเคชันของบุคคลที่สามทำงานได้ดีใน
การกำหนดค่าฮาร์ดแวร์ต่างๆ [แหล่งข้อมูล, 38] อุปกรณ์ต้องใช้
API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้
หน่วยที่อ้างอิงตามข้อกำหนดในส่วนนี้กำหนดไว้ดังนี้
"ขนาดเส้นทแยงมุมจริง" คือระยะทางเป็นนิ้วระหว่างมุมที่ตรงข้ามกัน 2 มุม
ของส่วนที่สว่างของจอแสดงผล
"dpi" (หมายถึง "จุดต่อนิ้ว") คือจํานวนพิกเซลที่ล้อมรอบด้วยเส้น
แนวนอนหรือแนวตั้งยาว 1" ในกรณีที่ระบุค่า dpi ทั้ง dpi แนวนอนและ
แนวตั้งต้องอยู่ในช่วง
"สัดส่วนภาพ" คืออัตราส่วนของมิติข้อมูลที่ยาวกว่าของหน้าจอต่อมิติข้อมูลที่สั้นกว่า
ตัวอย่างเช่น จอแสดงผลขนาด 480x854 พิกเซลจะเป็น 854 / 480 =
1.779 หรือประมาณ "16:9"
"พิกเซลที่ไม่ขึ้นอยู่กับความหนาแน่น" หรือ ("dp") คือหน่วยพิกเซลเสมือนที่ปรับให้เป็นมาตรฐานสำหรับหน้าจอ 160
dpi โดยคำนวณจากสูตร พิกเซล = dps * (ความหนาแน่น / 160)
7.1.1. การกำหนดค่าหน้าจอ
ขนาดหน้าจอ
เฟรมเวิร์ก UI ของ Android รองรับหน้าจอขนาดต่างๆ และอนุญาตให้
แอปพลิเคชันค้นหาขนาดหน้าจอของอุปกรณ์ (หรือที่เรียกว่า "เลย์เอาต์หน้าจอ") ผ่าน
android.content.res.Configuration.screenLayout ด้วย
SCREENLAYOUT_SIZE_MASK การติดตั้งใช้งานอุปกรณ์ต้องรายงาน
ขนาดหน้าจอที่ถูกต้องตามที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล 38] และกำหนดโดย
แพลตฟอร์ม Android ต้นทาง โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้องรายงาน
ขนาดหน้าจอที่ถูกต้องตามมิติข้อมูลหน้าจอแบบตรรกะที่ไม่ขึ้นอยู่กับความหนาแน่นพิกเซล (dp)
ต่อไปนี้
อุปกรณ์ต้องมีขนาดหน้าจออย่างน้อย 426 dp x 320 dp ('เล็ก ')
อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ปกติ" ต้องมีขนาดหน้าจออย่างน้อย 480
dp x 320 dp
อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ใหญ่" ต้องมีขนาดหน้าจออย่างน้อย 640
dp x 480 dp
อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ใหญ่มาก" ต้องมีขนาดหน้าจออย่างน้อย 960
dp x 720 dp
นอกจากนี้ อุปกรณ์ต้องมีขนาดหน้าจออย่างน้อย 2.5 นิ้วในแนวทแยง

อุปกรณ์ต้องไม่เปลี่ยนขนาดหน้าจอที่รายงานไว้ไม่ว่าเมื่อใดก็ตาม
แอปพลิเคชันจะระบุขนาดหน้าจอที่รองรับได้ผ่านแอตทริบิวต์ <supports-
screens> ในไฟล์ AndroidManifest.xml การติดตั้งใช้งานอุปกรณ์ต้อง
รองรับหน้าจอขนาดเล็ก ปกติ ใหญ่ และขนาดใหญ่
ตามที่แอปพลิเคชันระบุไว้อย่างถูกต้อง ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
สัดส่วนภาพ
สัดส่วนภาพต้องอยู่ระหว่าง 1.3333 (4:3) ถึง 1.85 (16:9)
ความหนาแน่นของหน้าจอ
เฟรมเวิร์ก UI ของ Android จะกำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วย
นักพัฒนาแอปกำหนดเป้าหมายทรัพยากรแอป การติดตั้งใช้งานอุปกรณ์ต้อง
รายงานความหนาแน่นของเฟรมเวิร์ก Android เชิงตรรกะอย่างใดอย่างหนึ่งต่อไปนี้ผ่าน
API ของ android.util.DisplayMetrics และต้องเรียกใช้แอปพลิเคชันที่ความหนาแน่นมาตรฐาน
นี้
120 dpi หรือที่เรียกว่า 'ldpi'
160 dpi หรือที่เรียกว่า 'mdpi'
213 dpi หรือที่เรียกว่า 'tvdpi'
240 dpi หรือที่เรียกว่า 'hdpi'
320 dpi หรือที่เรียกว่า 'xhdpi'
480 dpi หรือที่เรียกว่า 'xxhdpi'
การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่
มีตัวเลขใกล้เคียงที่สุดกับความหนาแน่นจริงของหน้าจอ เว้นแต่ความหนาแน่นเชิงตรรกะ

มีตัวเลขใกล้เคียงที่สุดกับความหนาแน่นจริงของหน้าจอ เว้นแต่ความหนาแน่นเชิงตรรกะ
จะดันขนาดหน้าจอที่รายงานให้ต่ำกว่าค่าต่ำสุดที่รองรับ หาก
ความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานซึ่งมีค่าตัวเลขใกล้เคียงกับความหนาแน่นของอุปกรณ์จริงที่สุดส่งผลให้
ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่รองรับ (ความกว้าง 320 dp)
การใช้งานอุปกรณ์ควรรายงาน
ความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป
7.1.2. เมตริกการแสดงผล
การติดตั้งใช้งานอุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่ระบุไว้ใน
android.util.DisplayMetrics [Resources, 39]
7.1.3. การวางแนวหน้าจอ
อุปกรณ์ต้องรองรับการวางแนวแบบไดนามิกตามแอปพลิเคชันเป็นการวางแนวหน้าจอแนวตั้งหรือ
แนวนอน กล่าวคือ อุปกรณ์ต้องเป็นไปตาม
คำขอการวางแนวหน้าจอที่เฉพาะเจาะจงของแอปพลิเคชัน การติดตั้งใช้งานอุปกรณ์อาจเลือก
การวางแนวแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น
อุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่
มีการค้นหาผ่าน android.content.res.Configuration.orientation,
android.view.Display.getOrientation() หรือ API อื่นๆ
อุปกรณ์ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยน
การวางแนว
อุปกรณ์ต้องรายงานการวางแนวหน้าจอที่รองรับ (
android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape)
และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มี
หน้าจอแนวนอนแบบการวางแนวคงที่ เช่น ทีวีหรือแล็ปท็อป จะต้องรายงาน
android.hardware.screen.landscape เท่านั้น
7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ตามที่ระบุ
และรายละเอียดในเอกสารประกอบของ Android SDK การติดตั้งใช้งานอุปกรณ์ต้อง
รองรับ Android Renderscript ด้วย ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
[แหล่งข้อมูล, 8]
การติดตั้งใช้งานอุปกรณ์ต้องระบุตัวเองว่ารองรับ
OpenGL ES 1.0 และ 2.0 อย่างถูกต้องด้วย กล่าวคือ
API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) จะต้องรายงาน
การรองรับ OpenGL ES 1.0 และ 2.0
API OpenGL ของ C/C++ เดิม (นั่นคือ API ที่พร้อมให้บริการแก่แอปผ่าน
libGLES_v1CM.so, libGLES_v2.so หรือ libEGL.so) จะต้องรายงานการรองรับ
OpenGL ES 1.0 และ 2.0
การติดตั้งใช้งานอุปกรณ์อาจใช้ส่วนขยาย OpenGL ES ที่ต้องการ
แต่การติดตั้งใช้งานอุปกรณ์ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน OpenGL ES ที่มีการจัดการและ
API เดิม และในทางกลับกัน ต้องไม่รายงาน
สตริงส่วนขยายที่ไม่รองรับ
โปรดทราบว่า Android 4.1 รองรับแอปพลิเคชันที่จะระบุได้ (ไม่บังคับ) ว่า
ต้องใช้รูปแบบการบีบอัดพื้นผิว OpenGL ที่เฉพาะเจาะจง รูปแบบเหล่านี้มักจะเป็น
รูปแบบเฉพาะของผู้ให้บริการ Android 4.1 ไม่จําเป็นต้องใช้
รูปแบบการบีบอัดพื้นผิวที่เฉพาะเจาะจงใดๆ ในการใช้งานอุปกรณ์ อย่างไรก็ตาม อุปกรณ์ควรรายงาน
รูปแบบการบีบอัดพื้นผิวที่รองรับอย่างถูกต้องผ่านเมธอด getString() ใน
OpenGL API
Android 4.1 มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการ
เปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือ
มุมมอง ผ่านการใช้แท็กไฟล์ Manifest android:hardwareAccelerated หรือ
API call โดยตรง [แหล่งข้อมูล, 9]
ใน Android 4.1 การใช้งานอุปกรณ์ต้องเปิดใช้การเร่งฮาร์ดแวร์โดย
ค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปร้องขอโดย
ตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์
โดยตรงผ่าน Android View API
นอกจากนี้ การใช้งานอุปกรณ์ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบ
SDK ของ Android เกี่ยวกับการเร่งด้วยฮาร์ดแวร์ [แหล่งข้อมูล 9]
Android 4.1 มีออบเจ็กต์ TextureView ที่ช่วยให้ผู้พัฒนาผสานรวม
พื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI
การใช้งานอุปกรณ์ต้องรองรับ TextureView API และต้องแสดง

ลักษณะการทำงานที่สอดคล้องกันกับการใช้งาน Android เวอร์ชันที่ใหม่กว่า
7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม
Android 4.1 ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานในโหมด
ขนาดหน้าจอ "ปกติ" (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิม
ที่ไม่ได้พัฒนาขึ้นสำหรับ Android เวอร์ชันเก่าซึ่งอยู่ก่อนยุคที่รองรับ
หน้าจอทุกขนาด การติดตั้งใช้งานอุปกรณ์ต้องรองรับ
โหมดความเข้ากันได้ของแอปพลิเคชันเดิมตามที่ติดตั้งใช้งานโดยโค้ดโอเพนซอร์สของ Android ต้นทาง กล่าวคือ
การติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่เปิดใช้งาน
โหมดความเข้ากันได้ และจะต้องไม่เปลี่ยนแปลงลักษณะการทํางานของ
โหมดความเข้ากันได้เอง
7.1.6. ประเภทหน้าจอ
หน้าจอการติดตั้งใช้งานอุปกรณ์แบ่งออกเป็น 2 ประเภท ได้แก่
การติดตั้งใช้งานจอแสดงผลพิกเซลคงที่: หน้าจอเป็นแผงเดียวที่รองรับ
ความกว้างและความสูงของพิกเซลเพียงค่าเดียว โดยทั่วไปแล้ว หน้าจอจะผสานรวม
กับอุปกรณ์ เช่น โทรศัพท์มือถือ แท็บเล็ต และอื่นๆ
การใช้งานจอแสดงผลแบบพิกเซลผันแปร: การใช้งานอุปกรณ์ไม่มี
หน้าจอแบบฝังและมีพอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI หรือ
พอร์ตไร้สายสำหรับแสดงผล หรือมีหน้าจอแบบฝังที่สามารถเปลี่ยน
ขนาดพิกเซล ตัวอย่าง ได้แก่ ทีวี กล่องรับสัญญาณ และอื่นๆ
การใช้งานอุปกรณ์พิกเซลคงที่
การใช้งานอุปกรณ์พิกเซลคงที่อาจใช้หน้าจอที่มีขนาดพิกเซลใดก็ได้
ตราบใดที่เป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้
การติดตั้งใช้งานพิกเซลคงที่อาจมีพอร์ตเอาต์พุตวิดีโอสำหรับใช้กับจอแสดงผลภายนอก
อย่างไรก็ตาม หากมีการใช้จอแสดงผลดังกล่าวเพื่อเรียกใช้แอป อุปกรณ์ต้องเป็นไปตาม
ข้อกำหนดต่อไปนี้
อุปกรณ์ต้องรายงานการกำหนดค่าหน้าจอและเมตริกการแสดงผลเดียวกันกับจอแสดงผลแบบพิกเซลคงที่
ตามที่ระบุไว้อย่างละเอียดในส่วนที่ 7.1.1 และ 7.1.2
อุปกรณ์ต้องรายงานความหนาแน่นเชิงตรรกะเดียวกันกับจอแสดงผลแบบพิกเซลคงที่
อุปกรณ์ต้องรายงานขนาดหน้าจอที่เหมือนกับหรือใกล้เคียงมาก
กับจอแสดงผลแบบพิกเซลคงที่
ตัวอย่างเช่น แท็บเล็ตขนาด 7 นิ้วที่มีความละเอียด 1024x600 พิกเซล
จะถือว่าใช้จอแสดงผล mdpi ขนาดใหญ่แบบพิกเซลคงที่ หากมี
พอร์ตเอาต์พุตวิดีโอที่แสดงผลที่ 720p หรือ 1080p การใช้งานอุปกรณ์จะต้องปรับขนาด
เอาต์พุตเพื่อให้แอปพลิเคชันทำงานในหน้าต่าง mdpi ขนาดใหญ่เท่านั้น ไม่ว่า
จะใช้จอแสดงผลพิกเซลคงที่หรือพอร์ตเอาต์พุตวิดีโอก็ตาม
การใช้งานอุปกรณ์ที่มีพิกเซลแบบปรับได้
การใช้งานอุปกรณ์ที่มีพิกเซลแบบปรับได้ต้องรองรับความละเอียด 1280x720 หรือ
1920x1080 อย่างใดอย่างหนึ่งหรือทั้ง 2 อย่าง (นั่นคือ 720p หรือ 1080p) การติดตั้งใช้งานอุปกรณ์ที่มี
จอแสดงผลแบบพิกเซลแปรผันต้องไม่รองรับการกำหนดค่าหรือโหมดหน้าจออื่นๆ
การติดตั้งใช้งานอุปกรณ์ที่มีหน้าจอพิกเซลแบบปรับได้อาจเปลี่ยนการกำหนดค่าหน้าจอหรือ
โหมดขณะรันไทม์หรือเวลาบูต เช่น ผู้ใช้กล่องรับสัญญาณอาจเปลี่ยน
จอแสดงผล 720p เป็นจอแสดงผล 1080p และการใช้งานอุปกรณ์อาจปรับ
ตามนั้น
นอกจากนี้ การใช้งานอุปกรณ์ที่มีพิกเซลแบบปรับขนาดได้ต้องรายงาน
กลุ่มการกำหนดค่า
ต่อไปนี้สำหรับขนาดพิกเซลเหล่านี้
1280x720 (หรือที่เรียกว่า 720p): ขนาดหน้าจอ "ขนาดใหญ่" ความหนาแน่น "tvdpi" (213 dpi)
1920x1080 (หรือที่เรียกว่า 1080p): ขนาดหน้าจอ "ขนาดใหญ่" ความหนาแน่น "xhdpi" (320 dpi)
เพื่อความชัดเจน การใช้งานอุปกรณ์ที่มีพิกเซลแบบปรับขนาดได้ถูกจำกัดไว้ที่
720p หรือ 1080p ใน Android 4.1 และต้องได้รับการกำหนดค่าให้รายงานกลุ่มขนาดหน้าจอและ
ความหนาแน่นตามที่ระบุไว้ข้างต้น
7.1.7. เทคโนโลยีหน้าจอ
แพลตฟอร์ม Android มี API ที่ช่วยให้แอปพลิเคชันแสดงผลกราฟิกอย่างมีประสิทธิภาพบน
จอแสดงผล อุปกรณ์ต้องรองรับ API ทั้งหมดเหล่านี้ตามที่ Android SDK กำหนด
เว้นแต่จะระบุไว้เป็นอย่างอื่นในเอกสารนี้ โดยเฉพาะอย่างยิ่ง
อุปกรณ์ต้องรองรับจอแสดงผลที่แสดงผลกราฟิกสี 16 บิต และ
ควรรองรับจอแสดงผลที่แสดงผลกราฟิกสี 24 บิต
อุปกรณ์ต้องรองรับจอแสดงผลที่แสดงผลภาพเคลื่อนไหว
เทคโนโลยีจอแสดงผลที่ใช้ต้องมีสัดส่วนการแสดงผลของพิกเซล (PAR) ระหว่าง 0.9

และ 1.1 กล่าวคือ สัดส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10%

7.2. อุปกรณ์อินพุต
7.2.1. แป้นพิมพ์
การใช้งานในอุปกรณ์:
ต้องรองรับเฟรมเวิร์กการจัดการอินพุต (ซึ่งช่วยให้นักพัฒนาแอปบุคคลที่สามสร้างเครื่องมือจัดการอินพุตได้ เช่น แป้นพิมพ์เสมือนจริง) ตามที่ระบุไว้อย่างละเอียดใน http://developer.android.com
ต้องจัดเตรียมการใช้งานแป้นพิมพ์เสมือนจริงอย่างน้อย 1 รายการ (ไม่ว่าจะมีแป้นพิมพ์จริงหรือไม่ก็ตาม)
อาจจัดเตรียมการใช้งานแป้นพิมพ์เสมือนจริงเพิ่มเติม
อาจจัดเตรียมแป้นพิมพ์ฮาร์ดแวร์
ต้องไม่จัดเตรียมแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่ง
ที่ระบุไว้ใน android.content.res.Configuration.keyboard [Resources, 40]
(นั่นคือ QWERTY หรือ 12 ปุ่ม)
7.2.2.

การนําทางแบบไม่สัมผัส
การใช้งานอุปกรณ์:
อาจละเว้นตัวเลือกการนําทางแบบไม่สัมผัส (กล่าวคือ อาจละเว้นแทร็กบอล แป้นบังคับทิศทาง หรือ
ล้อ)
ต้องรายงานค่าที่ถูกต้องสําหรับ
android.content.res.Configuration.navigation [ทรัพยากร, 40]
ต้องระบุกลไกอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสําหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือจัดการอินพุต

ซอฟต์แวร์โอเพนซอร์สของ Android เวอร์ชันอัปสตรีมมีกลไกการเลือก
ที่เหมาะสำหรับใช้กับอุปกรณ์ที่ไม่มีอินพุตการไปยังส่วนต่างๆ โดยไม่ต้องสัมผัส
7.2.3. ปุ่มการนําทาง
ฟังก์ชันหน้าแรก เมนู และย้อนกลับเป็นฟังก์ชันสําคัญในแพรามิเตอร์การนําทางของ Android
การติดตั้งใช้งานอุปกรณ์ต้องทำให้ฟังก์ชันเหล่านี้พร้อมใช้งานสำหรับผู้ใช้
ตลอดเวลาเมื่อเรียกใช้แอปพลิเคชัน ฟังก์ชันเหล่านี้อาจใช้ผ่าน
ปุ่มบนอุปกรณ์โดยเฉพาะ (เช่น ปุ่มกดแบบกลไกหรือแบบสัมผัสแบบจุลชีพไฟฟ้า) หรือ
ใช้ผ่านแป้นซอฟต์แวร์เฉพาะ ท่าทางสัมผัส แผงสัมผัส ฯลฯ Android
4.1 รองรับการใช้งานทั้ง 2 แบบ
Android 4.1 เริ่มรองรับการดำเนินการแบบช่วย [แหล่งข้อมูล, 63]
การติดตั้งใช้งานอุปกรณ์ต้องทำให้ผู้ใช้ดำเนินการช่วยเหลือได้ตลอดเวลาเมื่อ
เรียกใช้แอปพลิเคชัน ฟังก์ชันนี้อาจติดตั้งใช้งานผ่านคีย์ฮาร์ดแวร์หรือซอฟต์แวร์

การใช้งานอุปกรณ์อาจใช้พื้นที่บางส่วนของหน้าจอเพื่อแสดง
ปุ่มการนําทาง แต่ในกรณีนี้ต้องเป็นไปตามข้อกําหนดต่อไปนี้
ปุ่มการนําทางของการใช้งานอุปกรณ์ต้องใช้พื้นที่บางส่วนของ
หน้าจอ ซึ่งไม่พร้อมใช้งานสําหรับแอปพลิเคชัน และต้องไม่บดบังหรือ
รบกวนพื้นที่ของหน้าจอที่พร้อมใช้งานสําหรับแอปพลิเคชัน
การใช้งานอุปกรณ์ต้องแสดงปุ่มการนําทางเมื่อแอปพลิเคชัน
ไม่ได้ระบุโหมด UI ของระบบ หรือระบุ SYSTEM_UI_FLAG_VISIBLE
การใช้งานอุปกรณ์ต้องแสดงปุ่มการนําทางในโหมด"โหมดซ่อน" (เช่น สลัว) ที่ไม่รบกวน
เมื่อแอปพลิเคชันระบุ
SYSTEM_UI_FLAG_LOW_PROFILE

การใช้งานอุปกรณ์ต้องซ่อนปุ่มการไปยังส่วนต่างๆ เมื่อแอปพลิเคชัน
ระบุ SYSTEM_UI_FLAG_HIDE_NAVIGATION
การใช้งานอุปกรณ์ต้องแสดงปุ่มเมนูแก่แอปพลิเคชันเมื่อ
targetSdkVersion <= 10 และไม่ควรแสดงปุ่มเมนูเมื่อ
targetSdkVersion > 10
การใช้งานอุปกรณ์ต้องแสดงพื้นที่บางส่วนของจอแสดงผลแก่
แอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
7.2.4. อินพุตหน้าจอสัมผัส
การใช้งานอุปกรณ์ควรมีระบบอินพุตเคอร์เซอร์ประเภทใดประเภทหนึ่ง (
แบบเมาส์หรือแบบสัมผัส) อย่างไรก็ตาม หากการใช้งานอุปกรณ์ไม่รองรับ
ระบบอินพุตของเคอร์เซอร์ อุปกรณ์ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.touchscreen หรือ
android.hardware.faketouch การใช้งานอุปกรณ์ที่

มีระบบอินพุตเคอร์เซอร์
ควรรองรับเคอร์เซอร์ที่ติดตามอย่างอิสระ หากระบบอินพุตของอุปกรณ์
รองรับเคอร์เซอร์หลายรายการ
ต้องรายงานค่าของ android.content.res.Configuration.touchscreen
[Resources, 40] c ซึ่งสอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงใน
อุปกรณ์
Android 4.0 รองรับหน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตการสัมผัสจำลอง
ที่หลากหลาย การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับ
จอแสดงผล [แหล่งข้อมูล, 71] เพื่อให้ผู้ใช้รู้สึกว่าได้ควบคุม
รายการบนหน้าจอโดยตรง เนื่องจากผู้ใช้แตะหน้าจอโดยตรง ระบบจึง
ไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อบ่งชี้วัตถุที่กำลังมีการจัดการ ในทาง
ตรงกันข้าม อินเทอร์เฟซการสัมผัสจำลองมีระบบการป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับ
ความสามารถของหน้าจอสัมผัสเพียงบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุม
เคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อน
แล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายที่ใช้เซ็นเซอร์ไจโร
เคอร์เซอร์แบบไจโร จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบการแตะจำลอง
Android 4.0 มีค่าคงที่ของฟีเจอร์ android.hardware.faketouch ซึ่ง
สอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (นั่นคือ อุปกรณ์ที่ใช้เคอร์เซอร์) ที่มีคุณภาพสูง เช่น
เมาส์หรือแทร็กแพดที่จำลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการรองรับ
ท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของ
หน้าจอสัมผัสจำลองเพียงบางส่วน การติดตั้งใช้งานอุปกรณ์ที่ประกาศฟีเจอร์การแตะจำลอง
ต้องเป็นไปตามข้อกำหนดการแตะจำลองในส่วนที่ 7.2.5
การติดตั้งใช้งานอุปกรณ์ต้องรายงานฟีเจอร์ที่ถูกต้องซึ่งสอดคล้องกับประเภท
อินพุตที่ใช้ การติดตั้งใช้งานอุปกรณ์ที่มีหน้าจอสัมผัส (แบบสัมผัสเดียวหรือดีกว่า)
ต้องรายงานค่าคงที่ของฟีเจอร์แพลตฟอร์ม android.hardware.touchscreen
การติดตั้งใช้งาน
ที่รายงานค่าคงที่ของฟีเจอร์แพลตฟอร์ม
android.hardware.touchscreen ต้องรายงานค่าคงที่ของฟีเจอร์แพลตฟอร์ม
android.hardware.faketouch ด้วย การติดตั้งใช้งานอุปกรณ์ที่ไม่มี
หน้าจอสัมผัส (และใช้อุปกรณ์เคอร์เซอร์เท่านั้น) ต้องไม่รายงาน
ฟีเจอร์หน้าจอสัมผัส และต้องรายงานเฉพาะ android.hardware.faketouch หากเป็นไปตามข้อกำหนด
การแตะจำลองในส่วนที่ 7.2.5
7.2.5.อินพุตการแตะจำลอง
การใช้งานอุปกรณ์ที่ประกาศรองรับ android.hardware.faketouch
ต้องรายงานตำแหน่งสัมบูรณ์ X และ Y ของหน้าจอของตำแหน่งเคอร์เซอร์และ
แสดงเคอร์เซอร์ที่มองเห็นได้บนหน้าจอ[แหล่งข้อมูล, 70]
ต้องรายงานเหตุการณ์การแตะด้วยรหัสการดำเนินการ [แหล่งข้อมูล, 70] ที่ระบุ
การเปลี่ยนแปลงสถานะที่เกิดขึ้นเมื่อเคอร์เซอร์กดลงหรือขึ้น บนหน้าจอ
[แหล่งข้อมูล, 70]
ต้องรองรับการกดลงและยกขึ้นของเคอร์เซอร์บนวัตถุบนหน้าจอ ซึ่งจะช่วยให้
ผู้ใช้จำลองการแตะ บนวัตถุบนหน้าจอได้
ต้องรองรับการกดลง การยกขึ้น การกดลงแล้วยกขึ้นของเคอร์เซอร์ในตำแหน่งเดียวกัน
บนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งจะช่วยให้ผู้ใช้
จำลองการแตะสองครั้งบนวัตถุบนหน้าจอได้
[แหล่งข้อมูล, 70]
ต้องรองรับการกดลงของเคอร์เซอร์ในจุดใดก็ได้บนหน้าจอ การเลื่อนเคอร์เซอร์ไปยัง
จุดใดก็ได้บนหน้าจอตามต้องการ ตามด้วยการยกขึ้น ซึ่งจะช่วยให้ผู้ใช้
จำลองการลากด้วยการแตะได้
ต้องรองรับการกดลงของเคอร์เซอร์ แล้วอนุญาตให้ผู้ใช้ย้ายวัตถุไปยัง
ตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นจึงยกเคอร์เซอร์ขึ้นบนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้
เหวี่ยงวัตถุบนหน้าจอได้
อุปกรณ์ที่ประกาศรองรับ android.hardware.faketouch.multitouch.distinct
ต้องเป็นไปตามข้อกำหนดสำหรับฟีเจอร์การแตะจำลองข้างต้น และจะต้องรองรับ
การติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการด้วย
7.2.6. ไมโครโฟน
การติดตั้งใช้งานอุปกรณ์อาจไม่รวมไมโครโฟน อย่างไรก็ตาม หากการใช้งานอุปกรณ์
ไม่มีไมโครโฟน อุปกรณ์ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
และต้องใช้งาน API การบันทึกเสียงเป็น No-Ops ตามส่วนที่ 7
ในทางกลับกัน การใช้งานอุปกรณ์ที่มีไมโครโฟน
ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
ควรเป็นไปตามข้อกำหนดด้านคุณภาพเสียงในส่วนที่ 5.4
ควรเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองของเสียงในส่วนที่ 5.5
7.3 เซ็นเซอร์

Android 4.1 มี API สําหรับการเข้าถึงเซ็นเซอร์หลายประเภท การติดตั้งใช้งาน
อุปกรณ์โดยทั่วไปอาจไม่รวมเซ็นเซอร์เหล่านี้ตามที่ระบุไว้ใน
ส่วนย่อยต่อไปนี้ หากอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่เกี่ยวข้อง
สำหรับนักพัฒนาแอปบุคคลที่สาม การใช้งานอุปกรณ์จะต้องใช้ API นั้นตามที่
อธิบายไว้ในเอกสารประกอบของ Android SDK ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์
ต้องรายงานการมีอยู่หรือไม่มีของเซ็นเซอร์อย่างถูกต้องตาม
คลาส android.content.pm.PackageManager [แหล่งข้อมูล, 37]
ต้องแสดงรายการเซ็นเซอร์ที่รองรับอย่างถูกต้องผ่าน
SensorManager.getSensorList() และเมธอดที่คล้ายกัน
ต้องทํางานอย่างสมเหตุสมผลสําหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น แสดงผลเป็นจริง
หรือเท็จตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener, ไม่เรียกใช้
Listener ของเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)
ต้องรายงานการวัดผลเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยวัดระหว่างประเทศ
ที่เกี่ยวข้อง (เช่น เมตริก) สําหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
[แหล่งข้อมูล, 41]
รายการข้างต้นไม่ได้ครอบคลุมทั้งหมด ลักษณะการทํางานของ Android SDK ที่ระบุไว้ในเอกสารประกอบ
ถือเป็นข้อมูลที่น่าเชื่อถือ
เซ็นเซอร์บางประเภทเป็นแบบสังเคราะห์ ซึ่งหมายความว่าอาจมาจากข้อมูลที่ได้จาก
เซ็นเซอร์อื่นๆ อย่างน้อย 1 ตัว (เช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์การเร่งความเร็วแบบเส้นตรง
) การติดตั้งใช้งานอุปกรณ์ควรใช้เซ็นเซอร์
ประเภทเหล่านี้เมื่อรวมเซ็นเซอร์ที่จับการเคลื่อนไหวจริงซึ่งจําเป็นไว้ด้วย
API ของ Android 4.1 แนะนําแนวคิดเซ็นเซอร์ "สตรีมมิง" ซึ่งเป็นเซ็นเซอร์ที่
แสดงข้อมูลอย่างต่อเนื่อง ไม่ใช่เฉพาะเมื่อข้อมูลมีการเปลี่ยนแปลง การติดตั้งใช้งาน
อุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะๆ อย่างต่อเนื่องสำหรับ API
ที่เอกสารประกอบ SDK ของ Android 4.1 ระบุว่าเป็นเซ็นเซอร์สตรีมมิง
7.3.1. ตัวตรวจวัดความเร่ง
การติดตั้งใช้งานอุปกรณ์ควรมีตัวตรวจวัดความเร่งแบบ 3 แกน หาก
การติดตั้งใช้งานอุปกรณ์มีเครื่องวัดความเร่ง 3 แกน
ควรสามารถส่งเหตุการณ์ที่ 120 Hz ขึ้นไป โปรดทราบว่าแม้ว่า
ความถี่ของเซ็นเซอร์ตรวจจับแรงสั่นสะเทือนข้างต้นจะระบุเป็น "ควร" สำหรับ Android 4.1 แต่
คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตมีแผนที่จะเปลี่ยนเป็น
"ต้อง" กล่าวคือ มาตรฐานเหล่านี้เป็นตัวเลือกใน Android 4.1 แต่จะเป็น
ข้อกำหนดในเวอร์ชันในอนาคต อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1
ขอแนะนําอย่างยิ่งให้เป็นไปตามข้อกําหนดเหล่านี้ใน Android 4.1 เพื่อให้
อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามที่ระบุไว้ใน
Android API (ดู [แหล่งข้อมูล, 41])
ต้องสามารถวัดจากแรงโน้มถ่วงที่ลดลงได้สูงสุด 2 เท่า (2g) หรือมากกว่าใน
เวกเตอร์เชิงสามมิติ
ต้องมีความแม่นยํา 8 บิตขึ้นไป
ต้องมีความเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^2
7.3.2. Magnetometer
การติดตั้งใช้งานอุปกรณ์ควรมี Magnetometer 3 แกน (เช่น เข็มทิศ) หาก
อุปกรณ์มีแม่เหล็ก 3 แกน
จะต้องมี
ความสามารถในการส่งเหตุการณ์ที่ 10 Hz ขึ้นไป
ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามที่ระบุไว้ใน
Android API (ดู [แหล่งข้อมูล, 41])
ต้องสามารถสุ่มตัวอย่างช่วงความแรงของสนามที่เพียงพอที่จะครอบคลุม
สนามแม่เหล็กโลก
ต้องมีความแม่นยำ 8 บิตหรือมากกว่า
ต้องมีค่าความเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT
7.3.3 GPS
การติดตั้งใช้งานอุปกรณ์ควรมีเครื่องรับ GPS หากการติดตั้งใช้งานอุปกรณ์
มีเครื่องรับสัญญาณ GPS ก็ควรมีเทคนิค "GPS เสริม"
รูปแบบใดรูปแบบหนึ่งเพื่อลดเวลาในการล็อก GPS
7.3.4. ไจโรสโคป
การติดตั้งใช้งานอุปกรณ์ควรมีไจโรสโคป (เช่น เซ็นเซอร์การเปลี่ยนแปลงเชิงมุม)
อุปกรณ์ไม่ควรมีเซ็นเซอร์ไจโรสโคป เว้นแต่จะมีเซ็นเซอร์วัดความเร่ง 3 แกน
ด้วย หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคป

ต้องชดเชยอุณหภูมิ
ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 5.5*Pi
เรเดียน/วินาที (ประมาณ 1,000 องศาต่อวินาที)
ควรส่งเหตุการณ์ที่ 200 Hz ขึ้นไป โปรดทราบว่าแม้ว่า
ความถี่ของ Gyroscope ข้างต้นจะระบุเป็น "ควร" สำหรับ Android 4.1 แต่
คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตมีแผนที่จะเปลี่ยนเป็น
"ต้อง" กล่าวคือ มาตรฐานเหล่านี้เป็นตัวเลือกใน Android 4.1 แต่จะเป็น
ข้อกำหนดในเวอร์ชันในอนาคต เรา
ขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้ใน Android 4.1 เพื่อให้
อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้
ต้องมีความแม่นยำ 12 บิตขึ้นไป
ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz
หรือ rad^2 / s) ความแปรปรวนสามารถเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่างได้ แต่ต้อง
ถูกจำกัดโดยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโร
ที่อัตราการสุ่มตัวอย่าง 1 Hz ค่านี้ไม่ควรเกิน 1e-7 rad^2/s^2
ต้องมีการประทับเวลาให้ใกล้เคียงกับเวลาที่เหตุการณ์ฮาร์ดแวร์เกิดขึ้นมากที่สุด
ต้องนำเวลาในการตอบสนองที่คงที่ออก
7.3.5. บารอมิเตอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงบารอมิเตอร์ (เช่น เซ็นเซอร์ความดันอากาศรอบตัว) หาก
การติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์
จะต้องมี
ความสามารถในการส่งเหตุการณ์ที่ 5 Hz ขึ้นไป
มีความแม่นยำเพียงพอที่จะประมาณระดับความสูง
มีการชดเชยอุณหภูมิ
7.3.7. เทอร์โมมิเตอร์
การติดตั้งใช้งานอุปกรณ์อาจหรือไม่ต้องรวมเทอร์โมมิเตอร์ (เช่น
เซ็นเซอร์อุณหภูมิ) หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดอุณหภูมิ อุปกรณ์นั้นต้อง
วัดอุณหภูมิของ CPU ของอุปกรณ์ และต้องไม่วัด
อุณหภูมิอื่นๆ (โปรดทราบว่าเซ็นเซอร์ประเภทนี้เลิกใช้งานแล้วใน API ของ Android 4.1)
7.3.7. โฟโตมิเตอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงโฟโตมิเตอร์ (เช่น เซ็นเซอร์แสงแวดล้อม)
7.3.8. พร็อกซิมิตีเซ็นเซอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์ หากการติดตั้งใช้งานอุปกรณ์
มีพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์จะต้องวัดระยะใกล้ของวัตถุใน
ทิศทางเดียวกับหน้าจอ กล่าวคือ เซ็นเซอร์ตรวจจับบุคคลในบริเวณใกล้เคียงต้องปรับให้ตรวจจับ
วัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากวัตถุประสงค์หลักของเซ็นเซอร์ประเภทนี้คือตรวจหา
โทรศัพท์ที่ผู้ใช้กำลังใช้อยู่ หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียงที่มี
การวางแนวอื่น อุปกรณ์ต้องเข้าถึงผ่าน API นี้ไม่ได้ หาก
การติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์นั้นต้องมีความแม่นยำ 1 บิตขึ้นไป
7.4. การเชื่อมต่อข้อมูล
7.4.1. โทรศัพท์
"โทรศัพท์" ตามที่ใช้โดย API ของ Android 4.1 และเอกสารนี้หมายถึง
ฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ
CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจใช้หรือไม่ได้ใช้การเปลี่ยนแพ็กเก็ต แต่
สำหรับวัตถุประสงค์ของ Android 4.1 ระบบจะถือว่าการโทรเหล่านี้ไม่เกี่ยวข้องกับการเชื่อมต่อข้อมูลใดๆ ที่
อาจติดตั้งใช้งานโดยใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันการทำงานและ API ของ "โทรศัพท์"
ของ Android หมายถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ เช่น
การใช้งานอุปกรณ์ที่โทรไม่ได้หรือส่ง/รับข้อความ SMS ไม่ได้ต้องไม่
รายงานฟีเจอร์ "android.hardware.telephony" หรือฟีเจอร์ย่อยใดๆ ก็ตาม ไม่ว่า
อุปกรณ์จะใช้เครือข่ายมือถือเพื่อเชื่อมต่ออินเทอร์เน็ตหรือไม่ก็ตาม
Android 4.1 อาจใช้กับอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ได้ กล่าวคือ
Android 4.1 ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์ อย่างไรก็ตาม หาก
การใช้งานอุปกรณ์มีโทรศัพท์ GSM หรือ CDMA อุปกรณ์นั้นต้องรองรับ
API ของเทคโนโลยีนั้นอย่างเต็มรูปแบบ การใช้งานอุปกรณ์ที่ไม่มีฮาร์ดแวร์การสื่อสาร
ต้องใช้งาน API แบบเต็มเป็น No-Ops
7.4.2. IEEE 802.11 (WiFi)
การใช้งานอุปกรณ์ Android 4.1 ควรรองรับ
รูปแบบ 802.11 (b/g/a/n ฯลฯ) อย่างน้อย 1 รูปแบบ หากการติดตั้งใช้งานอุปกรณ์รองรับ 802.11 อุปกรณ์
ต้องใช้งาน Android API ที่เกี่ยวข้อง

การติดตั้งใช้งานอุปกรณ์ต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
[แหล่งข้อมูล, 62]การติดตั้งใช้งานอุปกรณ์ที่รองรับ Wi-Fi
จะต้องรองรับ DNS แบบมัลติแคสต์ (mDNS) การติดตั้งใช้งานอุปกรณ์ต้องไม่กรอง
แพ็กเก็ต mDNS (224.0.0.251) ไม่ว่าเมื่อใดก็ตามที่ดำเนินการ รวมถึงเมื่อหน้าจอไม่ได้อยู่ใน
สถานะทำงาน
7.4.2.1. Wi-Fi Direct
การติดตั้งใช้งานอุปกรณ์ควรรองรับ Wi-Fi Direct (Wi-Fi แบบผู้ใช้ต่อผู้ใช้) หาก
การติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์นั้นต้องใช้
Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบ SDK [แหล่งข้อมูล, 68] หาก
การใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์จะต้องมีคุณสมบัติดังนี้
ต้องรองรับการทํางานของ Wi-Fi ปกติ
ควรรองรับการทํางานของ Wi-Fi และ Wi-Fi Direct พร้อมกัน
7.4.3. บลูทูธ
การติดตั้งใช้งานอุปกรณ์ควรมีตัวรับส่งสัญญาณบลูทูธ การติดตั้งใช้งาน
อุปกรณ์ที่มีตัวรับส่งข้อมูลบลูทูธต้องเปิดใช้ Bluetooth API ที่อิงตาม RFCOMM
ตามที่อธิบายไว้ในเอกสารประกอบ SDK [แหล่งข้อมูล, 42]
การติดตั้งใช้งานอุปกรณ์ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้องเช่น A2DP,
AVRCP, OBEX ฯลฯ ตามเหมาะสมสำหรับอุปกรณ์
ชุดทดสอบความเข้ากันได้มีกรณีต่างๆ ที่ครอบคลุมการดำเนินการพื้นฐานของ
RFCOMM Bluetooth API ของ Android อย่างไรก็ตาม เนื่องจากบลูทูธเป็นโปรโตคอลการสื่อสาร
ระหว่างอุปกรณ์ จึงไม่สามารถทดสอบได้อย่างเต็มที่ด้วยยูนิตเทสต์ที่ทำงานในอุปกรณ์เครื่องเดียว
ด้วยเหตุนี้ การติดตั้งใช้งานอุปกรณ์ต้องผ่านขั้นตอนการทดสอบบลูทูธ
ที่ดำเนินการโดยเจ้าหน้าที่ตามที่อธิบายไว้ในภาคผนวก ก ด้วย
7.4.4. Near Field Communication
การติดตั้งใช้งานอุปกรณ์ควรมีตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ
Near Field Communication (NFC) หากการใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC
อุปกรณ์จะต้อง
รายงานฟีเจอร์ android.hardware.nfc จาก
เมธอด android.content.pm.PackageManager.hasSystemFeature()
[Resources, 37]
ต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC
ต่อไปนี้
ต้องสามารถทําหน้าที่เป็นเครื่องอ่าน/เครื่องเขียนของ NFC Forum (ตามที่ระบุไว้ใน
ข้อกําหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0)
ผ่านมาตรฐาน NFC ต่อไปนี้
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
ควรสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC
ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC ด้านล่างจะระบุเป็น
"ควร" สำหรับ Android 4.1 แต่
เราวางแผนที่จะเปลี่ยนมาตรฐานเหล่านี้เป็น "ต้อง" สำหรับเวอร์ชันในอนาคต กล่าวคือ มาตรฐานเหล่านี้เป็นตัวเลือกใน
Android 4.1 แต่จะเป็นข้อกำหนดในเวอร์ชันในอนาคต เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่
ที่ใช้ Android 4.1 ปฏิบัติตาม
ข้อกำหนดเหล่านี้ใน Android 4.1 เพื่อให้อัปเกรดเป็น
รุ่นแพลตฟอร์มในอนาคตได้
NfcV (ISO 15693)
ต้องสามารถรับส่งข้อมูลผ่านมาตรฐานและโปรโตคอลแบบ
ผู้ใช้ต่อผู้ใช้ต่อไปนี้
ISO 18092
LLCP 1.0 (กำหนดโดย NFC Forum)
SDP 1.0 (กำหนดโดย NFC Forum)
NDEF Push Protocol [แหล่งข้อมูล, 43]
SNEP 1.0 (กำหนดโดย NFC Forum)
ต้องรองรับ Android Beam [แหล่งข้อมูล, 65]:
ต้องติดตั้งใช้งานเซิร์ฟเวอร์เริ่มต้นของ SNEP ข้อความ NDEF ที่ถูกต้อง
ซึ่งเซิร์ฟเวอร์ SNEP เริ่มต้นได้รับต้องส่งไปยังแอปพลิเคชัน
โดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้
Android Beam ในการตั้งค่าต้องไม่ปิดใช้การส่ง
ข้อความ NDEF
ขาเข้า
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตาม Intent
android.settings.NFCSHARING_SETTINGS เพื่อแสดงการตั้งค่าการแชร์ NFC

[แหล่งข้อมูล, 67]
ต้องติดตั้งใช้งานเซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP
ต้องได้รับการประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้น SNEP
ต้องติดตั้งใช้งานไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออก
ไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Android Beam หากไม่พบ
เซิร์ฟเวอร์ SNEP เริ่มต้น ไคลเอ็นต์ต้องพยายามส่งไปยัง
เซิร์ฟเวอร์ NPP

ต้องอนุญาตให้กิจกรรมที่ทำงานอยู่เบื้องหน้าตั้งค่าข้อความ NDEF ของ P2P ขาออก
โดยใช้ android.nfc.NfcAdapter.setNdefPushMessage, และ
android.nfc.NfcAdapter.setNdefPushMessageCal back, และ
android.nfc.NfcAdapter.enableForegroundNdefPush
ควรใช้ท่าทางสัมผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อ
ส่งผ่าน" ก่อนส่งข้อความ NDEF ของ P2P ขาออก
ควรเปิดใช้ Android Beam โดยค่าเริ่มต้น
ต้องรองรับการส่งต่อการเชื่อมต่อ NFC ไปยังบลูทูธเมื่ออุปกรณ์
รองรับโปรไฟล์การส่งผ่านออบเจ็กต์บลูทูธ การติดตั้งใช้งานอุปกรณ์ต้อง
รองรับการส่งต่อการเชื่อมต่อไปยังบลูทูธเมื่อใช้
android.nfc.NfcAdapter.setBeamPushUris โดยการใช้ข้อกำหนด
"การส่งต่อการเชื่อมต่อเวอร์ชัน 1.2" [แหล่งข้อมูล 60] และ "
การจับคู่แบบง่ายที่ปลอดภัยของบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" [แหล่งข้อมูล 61] จาก
NFC Forum การใช้งาน SHOULD ดังกล่าวใช้คําขอ SNEP GET
เพื่อแลกเปลี่ยนคําขอส่งต่อ / เลือกระเบียนผ่าน NFC และ
ต้องใช้โปรไฟล์การพุชออบเจ็กต์บลูทูธสําหรับการโอนข้อมูลบลูทูธจริง

ต้องค้นหาเทคโนโลยีทั้งหมดที่รองรับขณะอยู่ในโหมดการค้นหา NFC
ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอ
เปิดอยู่และหน้าจอล็อกปลดล็อก
(โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่พร้อมใช้งานสำหรับข้อกำหนดของ JIS, ISO และ NFC Forum
ที่ระบุไว้ข้างต้น)
นอกจากนี้ การติดตั้งใช้งานอุปกรณ์อาจรวมถึงการรองรับเครื่องอ่าน/เครื่องเขียนสำหรับเทคโนโลยี MIFARE ต่อไปนี้

MIFARE Classic (NXP MF1S503x [แหล่งข้อมูล, 44], MF1S703x [แหล่งข้อมูล, 44])
MIFARE Ultralight (NXP MF0ICU1 [แหล่งข้อมูล, 46], MF0ICU2 [แหล่งข้อมูล, 46])
NDEF ใน MIFARE Classic (NXP AN130511 [แหล่งข้อมูล, 48], AN130411
[แหล่งข้อมูล, 49])
โปรดทราบว่าAndroid 4.1 มี API สำหรับ MIFARE ประเภทเหล่านี้ หาก
การใช้งานอุปกรณ์รองรับ MIFARE ในบทบาทเครื่องอ่าน/เครื่องเขียน อุปกรณ์จะต้องมีคุณสมบัติดังนี้
ต้องใช้งาน Android API ที่เกี่ยวข้องตามที่ระบุไว้ใน
Android SDK
ต้องรายงานฟีเจอร์ com.nxp.mifare จาก
วิธี android.content.pm.PackageManager.hasSystemFeature()
[แหล่งข้อมูล, 37] โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android และด้วยเหตุนี้
จึงไม่ปรากฏเป็นค่าคงที่ในคลาส PackageManager
ต้องไม่ใช้ Android API ที่เกี่ยวข้องหรือรายงาน
ฟีเจอร์ com.nxp.mifare เว้นแต่จะใช้การรองรับ NFC ทั่วไปด้วยตามที่
อธิบายไว้ในส่วนนี้
หากการใช้งานอุปกรณ์ไม่ได้รวมฮาร์ดแวร์ NFC ไว้ ต้องไม่ประกาศ
ฟีเจอร์ android.hardware.nfc จากเมธอด
android.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 37]
และต้องใช้งาน NFC API ของ Android 4.1 เป็นการดำเนินการที่ไม่มีผล
เนื่องจากคลาส android.nfc.NdefMessage และ android.nfc.NdefRecord แสดง
รูปแบบการแสดงข้อมูลที่ไม่ขึ้นอยู่กับโปรโตคอล การใช้งานอุปกรณ์จึงต้อง
ใช้ API เหล่านี้แม้ว่าจะไม่รองรับ NFC หรือประกาศ
ฟีเจอร์ android.hardware.nfc ก็ตาม
7.4.5. ความสามารถของเครือข่ายขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบการสื่อสารข้อมูล
อย่างน้อย 1 รูปแบบ โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้องรองรับ
มาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่
เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต ฯลฯ
การติดตั้งใช้งานอุปกรณ์ที่ใช้มาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็น
การเชื่อมต่อข้อมูลหลักควรรองรับ
มาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 รายการ เช่น 802.11 (Wi-Fi)
อุปกรณ์อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ

7.5. กล้อง
การติดตั้งใช้งานอุปกรณ์ควรมีกล้องหลัง และอาจมี
กล้องหน้า กล้องหลังคือกล้องที่อยู่ด้านข้าง
อุปกรณ์ตรงข้ามกับจอแสดงผล กล่าวคือ กล้องจะจับภาพฉากที่อยู่ด้านไกลของอุปกรณ์ เช่นเดียวกับ
กล้องแบบดั้งเดิม กล้องหน้าคือกล้องที่อยู่ด้านเดียวกับ
จอแสดงผลของอุปกรณ์ นั่นคือกล้องที่ใช้ถ่ายภาพผู้ใช้ เช่น
การประชุมทางวิดีโอและแอปพลิเคชันอื่นๆ ที่คล้ายกัน
7.5.1. กล้องหลัง
การติดตั้งใช้งานอุปกรณ์ควรมีกล้องหลัง หาก
การใช้งานอุปกรณ์มีกล้องหลัง
จะต้องมีความละเอียดอย่างน้อย 2 ล้านพิกเซล
ควรมีโฟกัสอัตโนมัติแบบฮาร์ดแวร์หรือซอฟต์แวร์
ในไดรเวอร์กล้อง (ทำงานร่วมกับซอฟต์แวร์แอปพลิเคชัน)
อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกแบบขยาย)
อาจมีแฟลช หากกล้องมีแฟลช ไฟแฟลชต้อง
ไม่สว่างขึ้นขณะที่ลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCal แบ็ก
บนพื้นผิวแสดงตัวอย่างของกล้อง เว้นแต่แอปพลิเคชันจะ
เปิดใช้แฟลชโดยเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON
ของออบเจ็กต์ Camera.Parameters อย่างชัดเจน โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับ
แอปพลิเคชันกล้องระบบในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สาม
ที่ใช้ Camera.PreviewCallback เท่านั้น
7.5.2. กล้องหน้า
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงกล้องหน้า หากการใช้งานอุปกรณ์
มีกล้องหน้า
จะต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API กล่าวคือ
API ของกล้องใน Android 4.1 รองรับกล้องหน้าโดยเฉพาะ และ
การใช้งานอุปกรณ์ต้องไม่กำหนดค่า API ให้ถือว่า
กล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวใน
อุปกรณ์ก็ตาม
อาจรวมฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่พร้อมใช้งานสำหรับ
กล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
ต้องแสดงผลสตรีมที่แสดงโดยแอปใน
CameraPreview ในแนวนอนตาม
การวางแนวปัจจุบันของอุปกรณ์ ดังนี้
หากการใช้งานอุปกรณ์สามารถหมุนได้โดยผู้ใช้ (เช่น
หมุนโดยอัตโนมัติผ่านเซ็นเซอร์ความเร่งหรือหมุนด้วยตนเองผ่านอินพุตของผู้ใช้)
พรีวิวของกล้องต้องแสดงผลในแนวนอนตาม
การวางแนวปัจจุบันของอุปกรณ์
หากแอปพลิเคชันปัจจุบันร้องขออย่างชัดเจนให้
หมุนการแสดงผลของกล้องผ่าน
วิธี
android.hardware.Camera.setDisplayOrientation() [แหล่งข้อมูล, 50]

พรีวิวของกล้องต้องแสดงผลในแนวนอนตาม
การวางแนวที่ระบุโดยแอปพลิเคชัน
มิเช่นนั้น
พรีวิวต้องแสดงผลตาม
แกนแนวนอนเริ่มต้นของอุปกรณ์
ต้องแสดงรูปภาพที่แสดงโดยฟีเจอร์ดูตัวอย่างโพสต์ในลักษณะเดียวกับ
สตรีมรูปภาพตัวอย่างของกล้อง (หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ
การแสดงผลภาพหลังดู ก็ไม่จําเป็นต้องปฏิบัติตามข้อกําหนดนี้)
ต้องไม่มิเรอร์สตรีมวิดีโอหรือรูปภาพนิ่งที่จับภาพไว้แล้วซึ่งแสดงผลสุดท้ายซึ่งส่งกลับไปยัง
การเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ
7.5.3. ลักษณะการทํางานของ Camera API
การติดตั้งใช้งานอุปกรณ์ต้องมีลักษณะการทํางานต่อไปนี้สําหรับ API ที่เกี่ยวข้องกับกล้อง
สําหรับทั้งกล้องหน้าและกล้องหลัง
1.  หากแอปพลิเคชันไม่เคยเรียกใช้
android.hardware.Camera.Parameters.setPreviewFormat(int)
อุปกรณ์ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลพรีวิว
ที่ส่งไปยังแอปพลิเคชันเพื่อเรียกข้อมูลย้อนกลับ
2.  หากแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback
และระบบเรียกใช้เมธอด onPreviewFrame() เมื่อรูปแบบพรีวิว
เป็น YCbCr_420_SP ข้อมูลใน byte[] ที่ส่งไปยัง onPreviewFrame()
จะต้องอยู่ในรูปแบบการเข้ารหัส NV21 กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
3.  การใช้งานอุปกรณ์ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่

android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างกล้องทั้ง
กล้องหน้าและกล้องหลัง (ตัวถอดรหัสวิดีโอและกล้องฮาร์ดแวร์อาจ
ใช้รูปแบบพิกเซลเดิมใดก็ได้ แต่การใช้งานอุปกรณ์ต้องรองรับ
การเปลี่ยนรูปแบบเป็น YV12)
การใช้งานอุปกรณ์ต้องใช้ Camera API ทั้งหมดที่รวมอยู่ในเอกสารประกอบ
SDK 4.1 ของ Android [แหล่งข้อมูล, 51])ไม่ว่าอุปกรณ์จะมี
โฟกัสอัตโนมัติของฮาร์ดแวร์หรือความสามารถอื่นๆ ก็ตาม เช่น กล้องที่ไม่มีโฟกัสอัตโนมัติ
ต้องยังคงเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback
ที่ลงทะเบียนไว้ (แม้ว่าจะไม่มีความเกี่ยวข้องกับกล้องที่ไม่โฟกัสอัตโนมัติก็ตาม) โปรดทราบว่า
ข้อมูลนี้ใช้กับกล้องหน้าได้ เช่น แม้ว่า
กล้องหน้าส่วนใหญ่จะไม่รองรับโฟกัสอัตโนมัติ แต่การเรียก API ของกล้องหลังยังคงต้อง "จำลอง" ตามที่อธิบายไว้

การใช้งานอุปกรณ์ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็น
ค่าคงที่ในคลาส android.hardware.Camera.Parameters หาก
ฮาร์ดแวร์พื้นฐานรองรับฟีเจอร์นี้ หากฮาร์ดแวร์ของอุปกรณ์ไม่รองรับฟีเจอร์ใด
API จะต้องทํางานตามที่ระบุไว้ในเอกสารประกอบ ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่
ยอมรับหรือรู้จักค่าคงที่สตริงที่ส่งไปยังเมธอด
android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ในเอกสารประกอบ
ใน android.hardware.Camera.Parameters กล่าวคือ
การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์
อนุญาต และจะต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง
การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Intent Camera.ACTION_NEW_PICTURE
ทุกครั้งที่กล้องถ่ายรูปรูปภาพใหม่และมีการ
เพิ่มรายการรูปภาพลงในที่เก็บสื่อ
การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Intent Camera.ACTION_NEW_VIDEO
ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการ
เพิ่มรายการรูปภาพลงในที่เก็บสื่อ
7.5.4. การวางแนวกล้อง
ทั้งกล้องหน้าและกล้องหลัง (หากมี) จะต้องวางแนวให้
ขนาดยาวของกล้องสอดคล้องกับขนาดยาวของหน้าจอ กล่าวคือ เมื่อ
ถืออุปกรณ์ในแนวนอน กล้องต้องจับภาพใน
แนวนอน ซึ่งมีผลไม่ว่าอุปกรณ์จะวางในแนวใดก็ตาม
กล่าวคือ มีผลกับอุปกรณ์ที่แสดงแนวนอนเป็นหลักและอุปกรณ์ที่แสดงแนวตั้งเป็นหลัก
7.6. หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์ต้องมีหน่วยความจำอย่างน้อย 340 MB สำหรับเคอร์เนล
และพื้นที่ผู้ใช้ 340 MB นี้ต้องเพิ่มขึ้นจากหน่วยความจำที่ใช้สำหรับ
คอมโพเนนต์ฮาร์ดแวร์ เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้
การควบคุมของเคอร์เนล
การติดตั้งใช้งานในอุปกรณ์ต้องมีพื้นที่เก็บข้อมูลแบบถาวรอย่างน้อย 350 MB
สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน กล่าวคือ พาร์ติชัน /data ต้องมีขนาดอย่างน้อย 350 MB
Android API มีเครื่องมือจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลด
ไฟล์ข้อมูล [แหล่งข้อมูล, 56] การติดตั้งใช้งานตัวจัดการการดาวน์โหลดในอุปกรณ์
ต้องสามารถดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้น

7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์ต้องให้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอปพลิเคชัน
พื้นที่เก็บข้อมูลที่ใช้ร่วมกันที่ระบุต้องมีขนาดอย่างน้อย 1 GB
การใช้งานอุปกรณ์ต้องได้รับการกำหนดค่าให้ใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยค่าเริ่มต้น
"พร้อมใช้งานทันที" หากไม่ได้ติดตั้งพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในเส้นทาง Linux /sdcard
อุปกรณ์ต้องมีลิงก์สัญลักษณ์ Linux จาก /sdcard ไปยังจุดต่อเชื่อมจริง
การติดตั้งใช้งานอุปกรณ์ต้องบังคับใช้สิทธิ์
android.permission.WRITE_EXTERNAL_STORAGE ในพื้นที่เก็บข้อมูลที่แชร์นี้ตามที่ระบุไว้
แอปพลิเคชันใดก็ตามที่ได้รับสิทธิ์
นั้นต้องเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันได้
การติดตั้งใช้งานอุปกรณ์อาจมีฮาร์ดแวร์สำหรับพื้นที่เก็บข้อมูลแบบถอดออกได้ซึ่งผู้ใช้เข้าถึงได้
เช่น การ์ด Secure Digital หรือการติดตั้งใช้งานอุปกรณ์อาจจัดสรร
พื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอป

ไม่ว่าระบบจะใช้พื้นที่เก็บข้อมูลแบบใดก็ตาม การใช้งานอุปกรณ์ต้อง
ระบุกลไกบางอย่างในการเข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันจาก
คอมพิวเตอร์โฮสต์ เช่น อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB (UMS) หรือ Media Transfer Protocol (MTP)
การใช้งานอุปกรณ์อาจใช้อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB แต่ควรใช้ Media
Transfer Protocol หากการใช้งานอุปกรณ์รองรับ Media Transfer Protocol
การใช้งานอุปกรณ์ควรเข้ากันได้กับโฮสต์ MTP ของ Android
อ้างอิงจาก Android File Transfer [แหล่งข้อมูล, 57]
การใช้งานอุปกรณ์ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
การใช้งานอุปกรณ์ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"
หากการติดตั้งใช้งานอุปกรณ์ไม่มีพอร์ต USB อุปกรณ์นั้นต้องให้คอมพิวเตอร์โฮสต์
เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันด้วยวิธีอื่น เช่น ระบบไฟล์
เครือข่าย
เราขอยกตัวอย่าง 2 ตัวอย่างที่พบบ่อยเพื่ออธิบาย หากการติดตั้งใช้งานอุปกรณ์มี
ช่องการ์ด SD เพื่อตอบสนองข้อกำหนดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน การ์ด SD รูปแบบ FAT
ขนาด 1 GB ขึ้นไปต้องมาพร้อมกับอุปกรณ์ที่ขายให้แก่ผู้ใช้ และ
ต้องได้รับการต่อเชื่อมโดยค่าเริ่มต้น หรือหากการติดตั้งใช้งานอุปกรณ์ใช้
พื้นที่เก็บข้อมูลแบบคงที่ภายในเพื่อปฏิบัติตามข้อกำหนดนี้ พื้นที่เก็บข้อมูลดังกล่าวต้องมีขนาด 1 GB ขึ้นไปและ
ติดตั้งใน /sdcard (หรือ /sdcard ต้องเป็นลิงก์สัญลักษณ์ไปยังตำแหน่งจริงหาก
ติดตั้งไว้ที่อื่น)
การติดตั้งใช้งานอุปกรณ์ที่มีเส้นทางที่จัดเก็บข้อมูลที่ใช้ร่วมกันหลายเส้นทาง (เช่น ทั้ง
ช่องการ์ด SD และที่จัดเก็บข้อมูลภายในที่ใช้ร่วมกัน) ควรแก้ไขแอปพลิเคชันหลัก เช่น
เครื่องมือสแกนสื่อและ ContentProvider เพื่อรองรับไฟล์ที่อยู่ในทั้ง 2
ตำแหน่งอย่างโปร่งใส
7.7. USB
การติดตั้งใช้งานอุปกรณ์ควรมีพอร์ตไคลเอ็นต์ USB และควรมีพอร์ตโฮสต์
USB
หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตไคลเอ็นต์ USB
พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB-A มาตรฐานได้
พอร์ตควรใช้รูปแบบไมโคร USB ทางด้านอุปกรณ์ เราขอแนะนำให้อุปกรณ์ที่มีอยู่
และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ปฏิบัติตาม
ข้อกำหนดเหล่านี้ใน Android 4.1 เพื่อให้อัปเกรดเป็น
รุ่นแพลตฟอร์มในอนาคตได้
พอร์ตควรอยู่ตรงกลางของขอบ การติดตั้งใช้งานอุปกรณ์
ควรวางพอร์ตไว้ที่ด้านล่างของอุปกรณ์ (ตาม
การวางแนวตามธรรมชาติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึง
หน้าจอหลัก) เพื่อให้จอแสดงผลวาดภาพได้อย่างถูกต้องเมื่ออุปกรณ์วางแนวโดยให้
พอร์ตอยู่ด้านล่าง อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ควร
ปฏิบัติตามข้อกำหนดเหล่านี้ใน Android 4.1 เพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
หากอุปกรณ์มีพอร์ตอื่นๆ (เช่น พอร์ตชาร์จที่ไม่ใช่ USB) พอร์ตดังกล่าวควร
อยู่ด้านเดียวกับพอร์ต micro-USB
อุปกรณ์ต้องอนุญาตให้โฮสต์ที่เชื่อมต่อกับอุปกรณ์เข้าถึงเนื้อหาของ
วอลุ่มพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยใช้อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB หรือ Media Transfer
Protocol
อุปกรณ์ต้องใช้งาน Android Open Accessory API และข้อกำหนดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
และประกาศรองรับ
ฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory [แหล่งข้อมูล, 52]
อุปกรณ์ต้องใช้งานคลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
[แหล่งข้อมูล, 66]
อุปกรณ์ควรรองรับข้อกำหนดการชาร์จแบตเตอรี่ด้วย USB
[แหล่งข้อมูล, 64] อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.1 ควร
ปฏิบัติตามข้อกำหนดเหล่านี้ใน Android 4.1 เพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
หากการใช้งานอุปกรณ์มีพอร์ตโฮสต์ USB
อุปกรณ์อาจใช้รูปแบบพอร์ตที่ไม่ใช่มาตรฐานได้ แต่หากเป็นเช่นนั้น อุปกรณ์ต้องมาพร้อมกับสายหรือ
สายที่เปลี่ยนพอร์ตเป็น USB-A มาตรฐาน
อุปกรณ์ต้องใช้งาน Android USB Host API ตามที่ระบุไว้ในเอกสารประกอบของ Android
SDK และประกาศรองรับ
ฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host [แหล่งข้อมูล, 53]
การใช้งานอุปกรณ์ต้องใช้งาน Android Debug Bridge

หาก
การติดตั้งใช้งานอุปกรณ์ไม่มีพอร์ตไคลเอ็นต์ USB อุปกรณ์นั้นต้องใช้ Android Debug Bridge
ผ่านเครือข่าย LAN (เช่น Ethernet หรือ 802.11)

8. ความเข้ากันได้ด้านประสิทธิภาพ
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามเมตริกประสิทธิภาพหลักของอุปกรณ์ที่ใช้งานร่วมกันได้กับ Android 4.1
ซึ่งระบุไว้ในตารางด้านล่าง
เมตริก
เกณฑ์ประสิทธิภาพ
ความคิดเห็น
แอปพลิเคชันต่อไปนี้
ควรเปิดภายใน
เวลาที่ระบุ
เวลาเริ่มต้นจะวัดจาก
เวลาทั้งหมดในการโหลด
เบราว์เซอร์: น้อยกว่า
กิจกรรมเริ่มต้นสําหรับแอปพลิเคชัน
แอปพลิเคชัน
1300ms
รวมถึงเวลาที่ใช้ในการเริ่ม
เวลาเริ่มต้น
รายชื่อติดต่อ: น้อยกว่า
กระบวนการ Linux, โหลดแพ็กเกจ Android
700ms
ลงใน Dalvik VM และเรียก
การตั้งค่า: น้อยกว่า
onCreate
700 มิลลิวินาที
เมื่อมีการ
เปิดแอปพลิเคชันหลายรายการ
แล้ว การ
เปิดแอปพลิเคชันที่
ทำงานอยู่แล้ว
พร้อมกัน
อีกครั้งหลังจากเปิด

แอปพลิเคชัน
ต้องใช้เวลา
น้อยกว่าเวลาเปิด
ครั้งแรก
9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย
การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งานรูปแบบการรักษาความปลอดภัยที่สอดคล้องกับรูปแบบการรักษาความปลอดภัยของแพลตฟอร์ม Android
ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน
API [แหล่งข้อมูล, 54] ในเอกสารประกอบสำหรับนักพัฒนาแอป Android
การติดตั้งใช้งานอุปกรณ์ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้อง
ขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงานใดๆ
โดยเฉพาะอย่างยิ่ง อุปกรณ์ที่เข้ากันได้ต้องรองรับกลไกการรักษาความปลอดภัยที่อธิบายไว้ใน
ส่วนย่อยต่อไปนี้
9.1. สิทธิ์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสิทธิ์ของ Android ตามที่ระบุไว้ใน
เอกสารประกอบสำหรับนักพัฒนาแอป Android [แหล่งข้อมูล, 54] โดยเฉพาะอย่างยิ่ง การใช้งาน
ต้องบังคับใช้สิทธิ์แต่ละรายการตามที่อธิบายไว้ในเอกสารประกอบ SDK โดย
ต้องไม่ละเว้น เปลี่ยนแปลง หรือละเว้นสิทธิ์ใดๆ การใช้งานอาจเพิ่ม
สิทธิ์เพิ่มเติมได้ ตราบใดที่สตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.*

9.2. การแยก UID และกระบวนการ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบแซนด์บ็อกซ์แอปพลิเคชันของ Android ซึ่ง
แอปพลิเคชันแต่ละรายการจะทำงานเป็น UID สไตล์ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก
การติดตั้งใช้งานอุปกรณ์ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็น
รหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงนามและสร้างอย่างถูกต้องตามที่
ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์ [แหล่งข้อมูล, 54]
9.3. สิทธิ์เข้าถึงระบบไฟล์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสิทธิ์การเข้าถึงไฟล์ Android ตามที่
ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์ [แหล่งข้อมูล, 54]
9.4. สภาพแวดล้อมการเรียกใช้สํารอง
การติดตั้งใช้งานในอุปกรณ์อาจรวมถึงสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชัน
โดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นที่ไม่ใช่เครื่องเสมือน Dalvik หรือโค้ดแบบเนทีฟ
อย่างไรก็ตาม สภาพแวดล้อมการเรียกใช้ทางเลือกดังกล่าวต้องไม่ทำให้
รูปแบบการรักษาความปลอดภัยของ Android หรือความปลอดภัยของแอปพลิเคชัน Android ที่ติดตั้งไว้ลดลง ตามที่อธิบายไว้
ในส่วนนี้
รันไทม์อื่นต้องเป็นแอปพลิเคชัน Android และเป็นไปตาม
รูปแบบการรักษาความปลอดภัย Android มาตรฐานตามที่อธิบายไว้ในส่วนที่ 9
รันไทม์อื่นต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดย
สิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-
permission>

รันไทม์สำรองต้องไม่อนุญาตให้แอปพลิเคชันใช้ฟีเจอร์ที่ได้รับการปกป้อง
โดยสิทธิ์ Android ที่จำกัดไว้สำหรับแอปพลิเคชันระบบ
รันไทม์อื่นต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android โดยเฉพาะอย่างยิ่ง
รันไทม์อื่นควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (นั่นคือ รหัสผู้ใช้ Linux ฯลฯ)
รันไทม์อื่นอาจจัดหาแซนด์บ็อกซ์ Android เดียวที่แชร์โดย
แอปพลิเคชันทั้งหมดที่ใช้รันไทม์อื่น
รันไทม์อื่นและแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์อื่นต้อง
ไม่นำแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่าน
กลไกมาตรฐานของ Android สำหรับรหัสผู้ใช้ที่แชร์และใบรับรองการรับรอง
รันไทม์อื่นต้องไม่เปิดใช้งานด้วย มอบสิทธิ์ให้ หรือได้รับสิทธิ์เข้าถึง
แซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ
รันไทม์อื่นต้องไม่เปิดใช้งานด้วย มอบสิทธิ์ให้ หรือให้สิทธิ์
แอปพลิเคชันอื่นๆ เกี่ยวกับสิทธิ์ของผู้ใช้ระดับซูเปอร์ (รูท) หรือรหัสผู้ใช้อื่นๆ

ไฟล์ .apk ของรันไทม์อื่นอาจรวมอยู่ในอิมเมจระบบของ
การติดตั้งใช้งานอุปกรณ์ แต่ต้องลงนามด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงนาม
แอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์
เมื่อติดตั้งแอปพลิเคชัน รันไทม์อื่นต้องได้รับความยินยอมจากผู้ใช้สำหรับ
สิทธิ์ Android ที่แอปพลิเคชันใช้ กล่าวคือ หากแอปพลิเคชันต้อง
ใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชัน
จะเข้าถึงทรัพยากรนั้นได้
หากสภาพแวดล้อมรันไทม์ไม่ได้บันทึก
ความสามารถของแอปพลิเคชันด้วยวิธีนี้ สภาพแวดล้อมรันไทม์ต้องแสดงรายการ
สิทธิ์ทั้งหมดที่รันไทม์มีเมื่อติดตั้งแอปพลิเคชันที่ใช้รันไทม์นั้น
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้
อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนํา
อย่างยิ่งให้ผู้ใช้งานอุปกรณ์ทํา
การเปลี่ยนแปลงน้อยที่สุดเท่าที่จะเป็นไปได้กับการใช้งานอ้างอิงและการใช้งานที่แนะนําของ Android 4.1
ซึ่งมีอยู่ในโปรเจ็กต์โอเพนซอร์สของ Android วิธีนี้จะช่วยลดความเป็นไปได้ที่จะเกิด
ข้อบกพร่องที่ทำให้เกิดความไม่เข้ากันได้ซึ่งต้องแก้ไขใหม่และอาจต้อง
อัปเดตอุปกรณ์
10.1. ชุดเครื่องมือทดสอบความเข้ากันได้
การติดตั้งใช้งานอุปกรณ์ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้กับ Android (CTS)
[แหล่งข้อมูล, 2] จากโปรเจ็กต์โอเพนซอร์ส Android โดยใช้
ซอฟต์แวร์เวอร์ชันสุดท้ายที่พร้อมจำหน่ายในอุปกรณ์ นอกจากนี้ ผู้ใช้งานอุปกรณ์ควรใช้
การใช้งานตามข้อมูลอ้างอิงในต้นไม้ซอร์สโค้ดโอเพนซอร์สของ Android ให้ได้มากที่สุด และ
ต้องตรวจสอบความเข้ากันได้ในกรณีที่เกิดความคลุมเครือใน CTS และสำหรับ
การใช้งานบางส่วนของซอร์สโค้ดอ้างอิงอีกครั้ง
CTS ออกแบบมาเพื่อใช้งานในอุปกรณ์จริง CTS
อาจมีข้อบกพร่องเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันแยกต่างหากจาก
คำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS เวอร์ชันต่างๆ สำหรับ Android 4.1 การติดตั้งใช้งาน
อุปกรณ์ต้องผ่าน CTS เวอร์ชันล่าสุดที่มีในขณะซอฟต์แวร์
อุปกรณ์เสร็จสมบูรณ์
10.2 โปรแกรมตรวจสอบ CTS
การติดตั้งใช้งานอุปกรณ์ต้องดำเนินการตามกรณีที่เกี่ยวข้องทั้งหมดในโปรแกรมตรวจสอบ CTS
อย่างถูกต้อง โปรแกรมตรวจสอบ CTS จะรวมอยู่ในชุดเครื่องมือทดสอบความเข้ากันได้ และมีไว้
ให้ผู้ดำเนินการที่เป็นมนุษย์ใช้งานเพื่อทดสอบฟังก์ชันการทำงานที่
ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานของกล้องและเซ็นเซอร์อย่างถูกต้อง
โปรแกรมตรวจสอบ CTS มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางประเภทที่
ไม่บังคับ การติดตั้งใช้งานอุปกรณ์ต้องผ่านทุกการทดสอบสำหรับฮาร์ดแวร์ที่
มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง ต้อง
เรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง คุณอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่ระบุ
ว่าไม่บังคับในเอกสารคำจำกัดความความเข้ากันได้นี้
อุปกรณ์และบิลด์ทุกรุ่นต้องเรียกใช้โปรแกรมตรวจสอบ CTS อย่างถูกต้องตามที่ระบุไว้ข้างต้น
อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ใช้งานอุปกรณ์จึงไม่จำเป็นต้อง
เรียกใช้โปรแกรมตรวจสอบ CTS อย่างชัดเจนในบิลด์ที่แตกต่างกันเพียงเล็กน้อย กล่าวโดยละเอียดคือ
การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่าน
โปรแกรมตรวจสอบของ CTS
เฉพาะชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมอยู่ด้วยเท่านั้นอาจไม่จําเป็นต้องทดสอบโปรแกรมตรวจสอบของ CTS

10.3. แอปพลิเคชันอ้างอิง
ผู้ติดตั้งใช้งานอุปกรณ์ต้องทดสอบความเข้ากันได้ของการติดตั้งใช้งานโดยใช้แอปพลิเคชันโอเพนซอร์สต่อไปนี้
แอปพลิเคชัน "แอปสําหรับ Android" [แหล่งข้อมูล, 55]
Replica Island (มีให้บริการใน Android Market)
แอปแต่ละแอปข้างต้นต้องเปิดและทํางานอย่างถูกต้องในการติดตั้งใช้งาน เพื่อให้
การติดตั้งใช้งานได้รับการพิจารณาว่าเข้ากันได้

11. ซอฟต์แวร์ที่อัปเดตได้
การติดตั้งใช้งานอุปกรณ์ต้องระบุกลไกในการแทนที่
ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" กล่าวคือ คุณอาจต้อง
รีสตาร์ทอุปกรณ์
คุณใช้วิธีการใดก็ได้ ตราบใดที่วิธีการดังกล่าวสามารถแทนที่ซอฟต์แวร์
ที่ติดตั้งไว้ล่วงหน้าทั้งหมดในอุปกรณ์ ตัวอย่างเช่น แนวทางใดๆ ต่อไปนี้จะเป็นไปตาม
ข้อกำหนดนี้
การดาวน์โหลดผ่านอากาศ (OTA) ด้วยการอัปเดตแบบออฟไลน์ผ่านการรีบูต
การอัปเดตแบบ"ใช้การเชื่อมต่ออินเทอร์เน็ตมือถือ" ผ่าน USB จาก PC โฮสต์
การอัปเดตแบบ"ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในอุปกรณ์เก็บข้อมูลแบบถอดได้
กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ
กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูล
ที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android ต้นทางมีกลไกการอัปเดต
ที่เป็นไปตามข้อกำหนดนี้
หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากเปิดตัวแล้ว แต่ภายใน
อายุการใช้งานผลิตภัณฑ์ที่เหมาะสมซึ่งกำหนดโดยทีมความเข้ากันได้ของ Android ว่าส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม
ผู้ใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านอัปเดตซอฟต์แวร์ที่มีให้
ใช้ตามกลไกที่อธิบายไปก่อนหน้านี้

12. ติดต่อเรา
คุณสามารถติดต่อผู้เขียนเอกสารที่ compatibility@android.com เพื่อขอคำชี้แจง
และแจ้งปัญหาที่คุณคิดว่าเอกสารไม่ได้กล่าวถึง

ภาคผนวก ก - ขั้นตอนการทดสอบบลูทูธ
ชุดทดสอบความเข้ากันได้มีกรณีต่างๆ ที่ครอบคลุมการดำเนินการพื้นฐานของ
RFCOMM Bluetooth API ของ Android อย่างไรก็ตาม เนื่องจากบลูทูธเป็นโปรโตคอลการสื่อสาร
ระหว่างอุปกรณ์ จึงไม่สามารถทดสอบได้อย่างเต็มที่ด้วยยูนิตเทสต์ที่ทำงานในอุปกรณ์เครื่องเดียว
ด้วยเหตุนี้ การติดตั้งใช้งานอุปกรณ์จึงต้องผ่านขั้นตอนทดสอบบลูทูธ
ที่ดำเนินการโดยเจ้าหน้าที่ตามที่อธิบายไว้ด้านล่างด้วย
ขั้นตอนการทดสอบจะอิงตามแอปตัวอย่าง BluetoothChat ที่รวมอยู่ในต้นไม้โปรเจ็กต์โอเพนซอร์สของ Android
ขั้นตอนนี้ต้องใช้อุปกรณ์ 2 เครื่อง ได้แก่
การติดตั้งใช้งานอุปกรณ์ที่คาดหวังซึ่งใช้บิลด์ซอฟต์แวร์ที่จะทดสอบ
การติดตั้งใช้งานอุปกรณ์แยกต่างหากที่ทราบว่าเข้ากันได้และ
เป็นรุ่นจากการติดตั้งใช้งานอุปกรณ์ที่ทดสอบ นั่นคือ การติดตั้งใช้งานอุปกรณ์ที่ "ทราบแล้วว่าใช้ได้"
ขั้นตอนทดสอบด้านล่างจะเรียกอุปกรณ์เหล่านี้ว่าอุปกรณ์ "ที่คาดหวัง" และอุปกรณ์ที่ "ทราบแล้วว่าใช้ได้" ตามลำดับ

การตั้งค่าและการติดตั้ง
1.  สร้าง BluetoothChat.apk ผ่าน 'make samples' จาก Android source code tree
2.  ติดตั้ง BluetoothChat.apk ในอุปกรณ์ที่ทราบว่าใช้งานได้
3.  ติดตั้ง BluetoothChat.apk ในอุปกรณ์ที่จะทดสอบ
ทดสอบการควบคุมบลูทูธโดยแอป
1.  เปิด BluetoothChat ในอุปกรณ์ที่เลือกขณะที่บลูทูธปิดอยู่
2.  ตรวจสอบว่าอุปกรณ์ที่เลือกเปิดบลูทูธหรือแจ้งให้ผู้ใช้
เปิดบลูทูธ
ทดสอบการจับคู่และการสื่อสาร
1.  เปิดแอป Bluetooth Chat ในอุปกรณ์ทั้ง 2 เครื่อง
2.  ทำให้อุปกรณ์ที่ใช้งานได้ค้นหาได้จากภายใน BluetoothChat (โดยใช้
เมนู)
3.  ในอุปกรณ์ที่สงสัย ให้สแกนหาอุปกรณ์บลูทูธจากภายใน BluetoothChat
(โดยใช้เมนู) และจับคู่กับอุปกรณ์ที่ทราบว่าใช้งานได้
4.  ส่งข้อความอย่างน้อย 10 ข้อความจากอุปกรณ์แต่ละเครื่อง และตรวจสอบว่าอุปกรณ์อีกเครื่อง
ได้รับข้อความอย่างถูกต้อง
5.  ปิดแอป BluetoothChat ในอุปกรณ์ทั้ง 2 เครื่องโดยกดHome
6.  ยกเลิกการจับคู่อุปกรณ์แต่ละเครื่องจากอีกเครื่องหนึ่งโดยใช้แอปการตั้งค่าอุปกรณ์
ทดสอบการจับคู่และการสื่อสารในทิศทาง
opposite
1.  เปิดแอป Bluetooth Chat ในอุปกรณ์ทั้ง 2 เครื่อง
2.  ทำให้อุปกรณ์ที่เลือกค้นพบได้จากภายใน BluetoothChat (โดยใช้
เมนู)
3.  ในอุปกรณ์ที่ใช้งานได้ ให้สแกนหาอุปกรณ์บลูทูธจากภายใน BluetoothChat
(โดยใช้เมนู) และจับคู่กับอุปกรณ์ที่เป็นไปได้
4.  ส่งข้อความ 10 รายการจากอุปกรณ์แต่ละเครื่อง และตรวจสอบว่าอุปกรณ์อีกเครื่อง
ได้รับข้อความอย่างถูกต้อง
5.  ปิดแอปแชทบลูทูธในอุปกรณ์ทั้ง 2 เครื่องโดยกด "ย้อนกลับ" ซ้ำๆ เพื่อ
ไปที่ตัวเปิดแอป
ทดสอบการเปิดตัวอีกครั้ง
1.  เปิดแอปแชทผ่านบลูทูธอีกครั้งในอุปกรณ์ทั้ง 2 เครื่อง
2.  ส่งข้อความ 10 รายการจากอุปกรณ์แต่ละเครื่อง และตรวจสอบว่าอุปกรณ์อีกเครื่อง
ได้รับข้อความอย่างถูกต้อง
หมายเหตุ: การทดสอบข้างต้นมีบางกรณีที่จบส่วนการทดสอบโดยใช้ปุ่มหน้าแรก และ
บางกรณีที่ใช้ปุ่มย้อนกลับ การทดสอบเหล่านี้ไม่ซ้ำซ้อนและไม่ใช่ทางเลือก: วัตถุประสงค์คือ
เพื่อยืนยันว่า Bluetooth API และกองทำงานอย่างถูกต้องทั้งเมื่อมีการ
สิ้นสุดกิจกรรมโดยชัดแจ้ง (ผ่านผู้ใช้ที่กด Back ซึ่งจะเรียกใช้ finish()) และส่ง
ไปยังเบื้องหลังโดยนัย (ผ่านผู้ใช้ที่กด Home) ต้องทําตามลําดับการทดสอบแต่ละรายการ
ตามที่อธิบายไว้