การใช้คำว่า "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" และ "Optional" เป็นไปตามมาตรฐาน IETF กำหนดไว้ใน RFC2119 [ ทรัพยากร, 1 ]

ตามที่ใช้ในเอกสารนี้ "ผู้ติดตั้งอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" คือบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 4.4 "การใช้งานอุปกรณ์" หรือ "การใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ได้รับการพัฒนา

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

ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ใน ส่วนที่ 10 ไม่มีการโต้ตอบ ไม่ชัดเจน หรือไม่สมบูรณ์ ถือเป็นความรับผิดชอบของผู้ใช้อุปกรณ์ที่จะต้องรับรองความเข้ากันได้กับการใช้งานที่มีอยู่

ด้วยเหตุนี้ โครงการโอเพ่นซอร์ส Android [ ทรัพยากร 3 ] จึงเป็นทั้งข้อมูลอ้างอิงและการใช้งาน Android ที่ต้องการ ผู้ติดตั้งอุปกรณ์ได้รับการสนับสนุนอย่างยิ่งให้วางฐานการใช้งานไว้ในขอบเขตสูงสุดที่เป็นไปได้บนซอร์สโค้ด "อัปสตรีม" ที่มีอยู่ในโครงการ Android Open Source แม้ว่าส่วนประกอบบางส่วนสามารถถูกแทนที่ด้วยการใช้งานแบบอื่นตามสมมุติฐาน แต่แนวทางปฏิบัตินี้ไม่สนับสนุนอย่างยิ่ง เนื่องจากการผ่านการทดสอบซอฟต์แวร์จะยากขึ้นอย่างมาก เป็นความรับผิดชอบของผู้ดำเนินการเพื่อให้แน่ใจว่ามีความเข้ากันได้ทางพฤติกรรมอย่างสมบูรณ์กับการใช้งาน Android มาตรฐาน รวมถึงและนอกเหนือจากชุดทดสอบความเข้ากันได้ สุดท้ายนี้ โปรดทราบว่าการทดแทนและการแก้ไขส่วนประกอบบางอย่างไม่ได้รับอนุญาตอย่างชัดเจนในเอกสารนี้

2. ทรัพยากร

ระดับความต้องการ IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

ภาพรวมโปรแกรมความเข้ากันได้ของ Android: http://source.android.com/docs/compatibility/index.html

โครงการโอเพ่นซอร์ส Android: http://source.android.com/

คำจำกัดความและเอกสารประกอบ API: http://developer.android.com/reference/packages.html

การอ้างอิงสิทธิ์ของ Android: http://developer.android.com/reference/android/Manifest.permission.html

การอ้างอิง android.os.Build: http://developer.android.com/reference/android/os/Build.html

สตริงเวอร์ชันที่อนุญาตของ Android 4.4: http://source.android.com/docs/compatibility/4.4/versions.html

Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html

การเร่งความเร็วด้วยฮาร์ดแวร์: http://developer.android.com/guide/topics/graphics/hardware-accel.html

คลาส android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

ความสามารถออฟไลน์ HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

แท็กวิดีโอ HTML5: http://dev.w3.org/html5/spec/Overview.html#video

API ตำแหน่งทางภูมิศาสตร์ HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API การจัดเก็บเว็บ HTML5/W3C: http://www.w3.org/TR/webstorage/

HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

ข้อมูลจำเพาะ Dalvik Virtual Machine: มีอยู่ในซอร์สโค้ด Android ที่ dalvik/docs

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

การแจ้งเตือน: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

ทรัพยากรของแอปพลิเคชัน: http://code.google.com/android/reference/available-resources.html

คู่มือสไตล์ไอคอนแถบสถานะ: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

ตัวจัดการการค้นหา: http://developer.android.com/reference/android/app/SearchManager.html

ขนมปังปิ้ง: http://developer.android.com/reference/android/widget/Toast.html

ธีม: http://developer.android.com/guide/topics/ui/themes.html

คลาส R.style: http://developer.android.com/reference/android/R.style.html

วอลเปเปอร์สด: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

การดูแลระบบอุปกรณ์ Android: http://developer.android.com/guide/topics/admin/device-admin.html

การอ้างอิง DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

API บริการการเข้าถึงของ Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

API การเข้าถึงของ Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

โครงการ Eyes Free: http://code.google.com/p/eyes-free

API การแปลงข้อความเป็นคำพูด: http://developer.android.com/reference/android/speech/tts/package-summary.html

เอกสารอ้างอิงเครื่องมือ (สำหรับ adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

คำอธิบายไฟล์ Android APK: http://developer.android.com/guide/topics/fundamentals.html

ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html

เครื่องมือทดสอบลิง: https://developer.android.com/studio/test/other-testing-tools/monkey

คลาส Android android.content.pm.PackageManager และรายการคุณสมบัติฮาร์ดแวร์: http://developer.android.com/reference/android/content/pm/PackageManager.html

รองรับหลายหน้าจอ: http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

บลูทูธ API: http://developer.android.com/reference/android/bluetooth/package-summary.html

โปรโตคอลผลักดัน NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

API การวางแนวกล้อง: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

กล้อง: http://developer.android.com/reference/android/hardware/Camera.html

อุปกรณ์เสริม Android Open: http://developer.android.com/guide/topics/usb/accessory.html

API โฮสต์ USB: http://developer.android.com/guide/topics/usb/host.html

การอ้างอิงความปลอดภัยและการอนุญาตของ Android: http://developer.android.com/guide/topics/security/permissions.html

แอปสำหรับ Android: http://code.google.com/p/apps-for-android

ตัวจัดการการดาวน์โหลด Android: http://developer.android.com/reference/android/app/DownloadManager.html

การถ่ายโอนไฟล์ Android: http://www.android.com/filetransfer

รูปแบบสื่อ Android: http://developer.android.com/guide/appendix/media-formats.html

โปรโตคอลร่างสตรีมมิ่ง HTTP สด: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

การส่งมอบการเชื่อมต่อ NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

การจับคู่ Bluetooth อย่างปลอดภัยอย่างง่ายดายโดยใช้ NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Wi-Fi มัลติคาสต์ API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

การดำเนินการช่วยเหลือ: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

ข้อมูลจำเพาะการชาร์จ USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android บีม: http://developer.android.com/guide/topics/nfc/nfc.html

เสียง USB สำหรับ Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

การตั้งค่าการแชร์ Android NFC: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wi-Fi โดยตรง (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

วิดเจ็ตล็อคและหน้าจอหลัก: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

การอ้างอิง UserManager: http://developer.android.com/reference/android/os/UserManager.html

การอ้างอิงที่จัดเก็บข้อมูลภายนอก: https://source.android.com/docs/core/storage

API ที่จัดเก็บข้อมูลภายนอก: http://developer.android.com/reference/android/os/Environment.html

รหัสย่อทาง SMS: http://en.wikipedia.org/wiki/Short_code

ไคลเอนต์การควบคุมระยะไกลสื่อ: http://developer.android.com/reference/android/media/RemoteControlClient.html

ตัวจัดการการแสดงผล: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

ความฝัน: http://developer.android.com/reference/android/service/dreams/DreamService.html

การตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

กล้อง: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

ส่วนขยาย EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

API เหตุการณ์การเคลื่อนไหว: http://developer.android.com/reference/android/view/MotionEvent.html

สัมผัสการกำหนดค่าอินพุต: http://source.android.com/docs/core/interaction/input/touch-devices.html

ยูนิโค้ด 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

ความเข้ากันได้ของ WebView: http://www.chromium.org/

แอปเจ้าของอุปกรณ์ Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

ข้อกำหนดการเข้ารหัสฮาร์ดแวร์ RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

การตั้งค่า LOCATION_MODE ที่ปลอดภัย: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

ตัวแก้ไขเนื้อหา: http://developer.android.com/reference/android/content/ContentResolver.html

การตั้งค่าInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html

การจำลองการ์ดบนโฮสต์: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

ผู้ให้บริการโทรศัพท์: http://developer.android.com/reference/android/provider/Telephony.html

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

3. ซอฟต์แวร์

3.1. ความเข้ากันได้ของ API ที่มีการจัดการ

สภาพแวดล้อมการดำเนินการที่ได้รับการจัดการ (ตาม Dalvik) เป็นเครื่องมือหลักสำหรับแอปพลิเคชัน Android Android Application Programming Interface (API) คือชุดของอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อม VM ที่มีการจัดการ การใช้งานอุปกรณ์จะต้องจัดให้มีการใช้งานที่สมบูรณ์ รวมถึงพฤติกรรมที่บันทึกไว้ทั้งหมดของ API ที่ได้รับการบันทึกไว้ซึ่งเปิดเผยโดย Android SDK [ แหล่งข้อมูล, 4 ]

การใช้งานอุปกรณ์จะต้องไม่ละเว้น API ที่มีการจัดการใดๆ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็น API เบี่ยงเบนไปจากลักษณะการทำงานที่บันทึกไว้ หรือรวมถึงการไม่ดำเนินการ ยกเว้นในกรณีที่ได้รับอนุญาตโดยเฉพาะตามคำจำกัดความความเข้ากันได้นี้

คำจำกัดความความเข้ากันได้นี้อนุญาตให้ฮาร์ดแวร์บางประเภทที่ Android รวม API ไว้ด้วยโดยการใช้งานอุปกรณ์ ในกรณีเช่นนี้ API จะต้องยังคงอยู่และทำงานในลักษณะที่เหมาะสม ดู ส่วนที่ 7 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้

3.2. ความเข้ากันได้ของ Soft API

นอกเหนือจาก API ที่ได้รับการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API แบบ "soft" แบบรันไทม์เท่านั้นที่สำคัญ ในรูปแบบของสิ่งต่าง ๆ เช่น Intent สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ที่ไม่สามารถบังคับใช้ได้ในเวลารวบรวมแอปพลิเคชัน

3.2.1. สิทธิ์

ผู้ใช้อุปกรณ์จะต้องสนับสนุนและบังคับใช้ค่าคงที่การอนุญาตทั้งหมดตามที่จัดทำเอกสารไว้ในหน้าอ้างอิงการอนุญาต [ แหล่งข้อมูล 5 ] โปรดทราบว่าส่วนที่ 9 แสดงรายการข้อกำหนดเพิ่มเติมที่เกี่ยวข้องกับโมเดลความปลอดภัยของ Android

3.2.2. สร้างพารามิเตอร์

Android API มีค่าคงที่จำนวนหนึ่งในคลาส android.os.Build [ Resources, 6 ] ที่มีวัตถุประสงค์เพื่ออธิบายอุปกรณ์ปัจจุบัน เพื่อให้ค่าที่มีความหมายและสอดคล้องกันในการใช้งานอุปกรณ์ต่างๆ ตารางด้านล่างจึงมีข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ซึ่งการใช้งานอุปกรณ์จะต้องปฏิบัติตาม

พารามิเตอร์	ความคิดเห็น
เวอร์ชัน. ปล่อย	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่มนุษย์สามารถอ่านได้ ฟิลด์นี้ต้องมีค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ใน [ ทรัพยากร, 7 ]
เวอร์ชัน.SDK	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่เข้าถึงได้โดยรหัสแอปพลิเคชันบุคคลที่สาม สำหรับ Android 4.4 ฟิลด์นี้ต้องมีค่าจำนวนเต็ม 19
เวอร์ชัน.SDK_INT	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่เข้าถึงได้โดยรหัสแอปพลิเคชันบุคคลที่สาม สำหรับ Android 4.4 ฟิลด์นี้ต้องมีค่าจำนวนเต็ม 19
รุ่นที่เพิ่มขึ้น	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งกำหนดโครงสร้างเฉพาะของระบบ Android ที่กำลังดำเนินการอยู่ ในรูปแบบที่มนุษย์สามารถอ่านได้ จะต้องไม่ใช้ค่านี้ซ้ำสำหรับบิลด์อื่นที่ผู้ใช้ปลายทางสามารถใช้ได้ การใช้งานทั่วไปของฟิลด์นี้คือเพื่อระบุว่าหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาใดที่ใช้ในการสร้างบิลด์ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
กระดาน	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในเฉพาะที่อุปกรณ์ใช้ ในรูปแบบที่มนุษย์สามารถอ่านได้ การใช้ฟิลด์นี้ที่เป็นไปได้คือเพื่อระบุการแก้ไขเฉพาะของบอร์ดที่จ่ายไฟให้กับอุปกรณ์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
ยี่ห้อ	ค่าที่สะท้อนถึงชื่อแบรนด์ที่เกี่ยวข้องกับอุปกรณ์ที่ผู้ใช้ปลายทางรู้จัก ต้องอยู่ในรูปแบบที่มนุษย์สามารถอ่านได้ และควรเป็นตัวแทนของผู้ผลิตอุปกรณ์หรือแบรนด์บริษัทที่จำหน่ายอุปกรณ์นั้น ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
CPU_ABI	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดเนทีฟ ดู ส่วนที่ 3.3: ความเข้ากันได้ของ Native API
CPU_ABI2	ชื่อของชุดคำสั่งที่สอง (ประเภท CPU + แบบแผน ABI) ของโค้ดเนทีฟ ดู ส่วนที่ 3.3: ความเข้ากันได้ของ Native API
อุปกรณ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อรหัสที่ระบุการกำหนดค่าคุณสมบัติฮาร์ดแวร์และการออกแบบทางอุตสาหกรรมของอุปกรณ์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
ลายนิ้วมือ	สตริงที่ระบุโครงสร้างนี้โดยไม่ซ้ำกัน มันควรจะสามารถอ่านได้โดยมนุษย์พอสมควร ต้องเป็นไปตามเทมเพลตนี้: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` ตัวอย่างเช่น: `acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys` ลายนิ้วมือต้องไม่มีอักขระช่องว่าง หากฟิลด์อื่นที่รวมอยู่ในเทมเพลตด้านบนมีอักขระช่องว่าง จะต้องแทนที่ฟิลด์เหล่านั้นในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต
ฮาร์ดแวร์	ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งเคอร์เนลหรือ /proc) มันควรจะสามารถอ่านได้โดยมนุษย์พอสมควร ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
เจ้าภาพ	สตริงที่ระบุโฮสต์โดยไม่ซ้ำกันที่ build สร้างขึ้น ในรูปแบบที่มนุษย์สามารถอ่านได้ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
บัตรประจำตัวประชาชน	ตัวระบุที่ผู้ใช้อุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นเฉพาะ ในรูปแบบที่มนุษย์สามารถอ่านได้ ช่องนี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL ได้ แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกแยะระหว่างรุ่นซอฟต์แวร์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
ผู้ผลิต	ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
แบบอย่าง	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางรู้จัก นี่ควรเป็นชื่อเดียวกับที่ใช้วางตลาดและจำหน่ายอุปกรณ์ให้กับผู้ใช้ปลายทาง ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
ผลิตภัณฑ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์เฉพาะ (SKU) ซึ่งไม่ควรซ้ำกันภายในแบรนด์เดียวกัน ต้องให้มนุษย์สามารถอ่านได้ แต่ไม่จำเป็นว่าจะต้องมีจุดประสงค์ให้ผู้ใช้ปลายทางดู ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
อนุกรม	หมายเลขซีเรียลของฮาร์ดแวร์ซึ่งต้องมีให้ใช้งาน ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^([a-zA-Z0-9]{6,20})$"`
แท็ก	รายการแท็กที่คั่นด้วยเครื่องหมายจุลภาคซึ่งเลือกโดยผู้ใช้อุปกรณ์ ซึ่งจะทำให้โครงสร้างแตกต่างออกไปอีก ตัวอย่างเช่น "ไม่ได้ลงนาม, ดีบัก" ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
เวลา	ค่าที่แสดงถึงการประทับเวลาเมื่อมีการสร้างเกิดขึ้น
พิมพ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ฟิลด์นี้ควรมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android สามค่า: "user", "userdebug" หรือ "eng" ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
ผู้ใช้	ชื่อหรือ ID ผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")

3.2.3. ความเข้ากันได้ของเจตนา

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

3.2.3.1. จุดประสงค์หลักของแอปพลิเคชัน

โครงการอัปสตรีม Android กำหนดแอปพลิเคชันหลักจำนวนหนึ่ง เช่น รายชื่อติดต่อ ปฏิทิน แกลเลอรี่รูปภาพ เครื่องเล่นเพลง และอื่นๆ ผู้ใช้อุปกรณ์อาจแทนที่แอปพลิเคชันเหล่านี้ด้วยเวอร์ชันอื่น

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

แอปพลิเคชันต่อไปนี้ถือเป็นแอปพลิเคชันระบบ Android หลัก:

นาฬิกาตั้งโต๊ะ
เบราว์เซอร์
ปฏิทิน
รายชื่อผู้ติดต่อ
แกลเลอรี่
ค้นหาทั่วโลก
ตัวเปิด
ดนตรี
การตั้งค่า

แอปพลิเคชันระบบ Android หลักประกอบด้วยกิจกรรมหรือส่วนประกอบบริการต่างๆ ที่ถือว่าเป็น "สาธารณะ" นั่นคือแอตทริบิวต์ "android:exported" อาจไม่อยู่หรืออาจมีค่าเป็น "true"

สำหรับทุกกิจกรรมหรือบริการที่กำหนดไว้ในหนึ่งในแอประบบ Android หลักที่ไม่ได้ทำเครื่องหมายว่าไม่เป็นสาธารณะผ่านแอตทริบิวต์ android:exported ที่มีค่า "false" การใช้งานอุปกรณ์จะต้องมีส่วนประกอบประเภทเดียวกันที่ใช้ตัวกรอง Intent เดียวกัน รูปแบบเป็นแอประบบหลักของ Android

กล่าวอีกนัยหนึ่ง การใช้งานอุปกรณ์อาจมาแทนที่แอประบบ Android หลัก อย่างไรก็ตาม หากเป็นเช่นนั้น การใช้งานอุปกรณ์จะต้องรองรับรูปแบบ Intent ทั้งหมดที่กำหนดโดยแอประบบ Android หลักแต่ละตัวที่ถูกแทนที่

3.2.3.2. การแทนที่เจตนา

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

อย่างไรก็ตาม การใช้งานอุปกรณ์อาจมีกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) หากกิจกรรมเริ่มต้นมีตัวกรอง URI ข้อมูลที่เฉพาะเจาะจงมากขึ้น ตัวอย่างเช่น ตัวกรอง Intent ที่ระบุ URI ข้อมูล "http://www.android.com" มีความเฉพาะเจาะจงมากกว่าตัวกรองเบราว์เซอร์สำหรับ "http://" การใช้งานอุปกรณ์จะต้องมีส่วนต่อประสานกับผู้ใช้สำหรับผู้ใช้เพื่อแก้ไขกิจกรรมเริ่มต้นสำหรับเจตนา

3.2.3.3. เนมสเปซเจตนา

การใช้งานอุปกรณ์ต้องไม่รวมส่วนประกอบ Android ใด ๆ ที่ใช้รูปแบบ Intent หรือ Broadcast Intent ใหม่โดยใช้ ACTION, CATEGORY หรือคีย์สตริงอื่น ๆ ในเนมสเปซ android.* หรือ com.android.* ผู้ใช้อุปกรณ์จะต้องไม่รวมส่วนประกอบ Android ใด ๆ ที่ให้เกียรติรูปแบบ Intent หรือ Broadcast Intent ใหม่โดยใช้ ACTION, CATEGORY หรือสตริงคีย์อื่น ๆ ในพื้นที่แพ็คเกจที่เป็นขององค์กรอื่น ผู้ใช้อุปกรณ์จะต้องไม่เปลี่ยนแปลงหรือขยายรูปแบบเจตนาใด ๆ ที่ใช้โดยแอปหลักที่แสดงอยู่ในส่วนที่ 3.2.3.1 การใช้งานอุปกรณ์อาจรวมถึงรูปแบบเจตนาที่ใช้เนมสเปซอย่างชัดเจนและเชื่อมโยงกับองค์กรของตนเองอย่างชัดเจน

ข้อห้ามนี้จะคล้ายคลึงกับที่ระบุไว้สำหรับคลาสภาษา Java ในส่วนที่ 3.6

3.2.3.4. ความตั้งใจในการออกอากาศ

แอปพลิเคชันของบริษัทอื่นอาศัยแพลตฟอร์มในการถ่ายทอด Intent บางอย่างเพื่อแจ้งให้ทราบถึงการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์ อุปกรณ์ที่รองรับ Android จะต้องออกอากาศเจตจำนงการออกอากาศสาธารณะเพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสม จุดประสงค์ในการออกอากาศอธิบายไว้ในเอกสารประกอบ SDK

3.2.3.5. การตั้งค่าแอพเริ่มต้น

Android 4.4 เพิ่มการตั้งค่าที่อนุญาตให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นสำหรับบ้านและ SMS การใช้งานอุปกรณ์ต้องมีเมนูการตั้งค่าผู้ใช้ที่คล้ายกันสำหรับแต่ละอุปกรณ์ ซึ่งเข้ากันได้กับรูปแบบตัวกรอง Intent และวิธีการ API ที่อธิบายไว้ในเอกสารประกอบ SDK [ แหล่งข้อมูล 91 ]

3.3. ความเข้ากันได้ของ API ดั้งเดิม

3.3.1 อินเทอร์เฟซไบนารีของแอปพลิเคชัน

รหัสที่ได้รับการจัดการที่ทำงานใน Dalvik สามารถเรียกใช้โค้ดเนทิฟที่ให้ไว้ในไฟล์ .apk ของแอปพลิเคชัน โดยเป็นไฟล์ ELF .so ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสม เนื่องจากโค้ดเนทิฟขึ้นอยู่กับเทคโนโลยีโปรเซสเซอร์พื้นฐานอย่างมาก Android จึงกำหนด Application Binary Interfaces (ABI) จำนวนหนึ่งใน Android NDK ในไฟล์ docs/CPU-ARCH-ABIS.html หากการใช้งานอุปกรณ์เข้ากันได้กับ ABI ที่กำหนดตั้งแต่หนึ่งรายการขึ้นไป ควรใช้ความเข้ากันได้กับ Android NDK ดังต่อไปนี้

หากการใช้งานอุปกรณ์รองรับ Android ABI มันจะ:

ต้องมีการสนับสนุนโค้ดที่ทำงานในสภาพแวดล้อมที่ได้รับการจัดการเพื่อเรียกใช้โค้ดเนทีฟ โดยใช้ซีแมนทิกส์ Java Native Interface (JNI) มาตรฐาน
จะต้องเข้ากันได้กับแหล่งที่มา (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) โดยแต่ละไลบรารีที่จำเป็นในรายการด้านล่าง
ต้องรายงาน Application Binary Interface (ABI) ดั้งเดิมที่อุปกรณ์รองรับอย่างถูกต้องผ่านพารามิเตอร์ android.os.Build.CPU_ABI API และ android.os.Build.CPU_ABI2
ต้องรายงานผ่าน android.os.Build.CPU_ABI2 เฉพาะ ABI เหล่านั้นที่บันทึกไว้ใน Android NDK เวอร์ชันล่าสุดในไฟล์ docs/CPU-ARCH-ABIS.html
ต้องรายงานผ่าน android.os.Build.CPU_ABI เพียงหนึ่งใน ABI ที่แสดงด้านล่าง

อาร์เมอาบี-v7a
x86
มิพส์

ควรสร้างขึ้นโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในอัปสตรีม Android Open Source Project

API โค้ดเนทีฟต่อไปนี้ต้องพร้อมใช้งานสำหรับแอปที่มีโค้ดเนทีฟ:

libc (ไลบรารี C)
libm (ห้องสมุดคณิตศาสตร์)
การสนับสนุนขั้นต่ำสำหรับ C ++
อินเทอร์เฟซ JNI
liblog (การบันทึก Android)
libz (การบีบอัด Zlib)
libdl (ตัวเชื่อมโยงแบบไดนามิก)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.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 ใดๆ เลย

โปรดทราบว่าการใช้งานอุปกรณ์ต้องมี libGLESv3.so และต้องมีลิงก์ symlink (สัญลักษณ์) ไปยัง libGLESv2.so ในการใช้งานอุปกรณ์ที่ประกาศรองรับ OpenGL ES 3.0 นั้น libGLESv2.so ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.0 นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0

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

3.4. ความเข้ากันได้ของเว็บ

3.4.1. ความเข้ากันได้ของ WebView

การใช้งาน Android Open Source จะใช้โค้ดจากโครงการ Chromium เพื่อใช้งาน android.webkit.WebView [ Resources, 10 ] เนื่องจากเป็นไปไม่ได้ที่จะพัฒนาชุดทดสอบที่ครอบคลุมสำหรับระบบการเรนเดอร์เว็บ ผู้ติดตั้งอุปกรณ์จึงต้องใช้ Chromium บิวด์อัพสตรีมเฉพาะในการใช้งาน WebView โดยเฉพาะ:

การใช้งานอุปกรณ์ android.webkit.WebView ต้องอิงตาม Chromium build จากอัปสตรีม Android Open Source Project สำหรับ Android 4.4 โครงสร้างนี้มีชุดฟังก์ชันการทำงานและการแก้ไขความปลอดภัยเฉพาะสำหรับ WebView [ แหล่งข้อมูล 83 ]
สตริงตัวแทนผู้ใช้ที่รายงานโดย WebView ต้องอยู่ในรูปแบบนี้:
Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- ค่าของสตริง $(VERSION) จะต้องเหมือนกับค่าสำหรับ android.os.Build.VERSION.RELEASE
- ค่าของสตริง $(LOCALE) เป็นทางเลือก โดยควรเป็นไปตามระเบียบ ISO สำหรับรหัสประเทศและภาษา และควรอ้างอิงถึงภาษาที่กำหนดค่าในปัจจุบันของอุปกรณ์ หากละเว้น จะต้องลบเครื่องหมายอัฒภาคต่อท้ายออกด้วย
- ค่าของสตริง $(MODEL) จะต้องเหมือนกับค่าสำหรับ android.os.Build.MODEL
- ค่าของสตริง $(BUILD) จะต้องเหมือนกับค่าสำหรับ android.os.Build.ID
- ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในอัปสตรีม Android Open Source Project
- การใช้งานอุปกรณ์อาจละเว้น Mobile ในสตริงตัวแทนผู้ใช้

คอมโพเนนต์ WebView ควรรองรับ HTML5 [ Resources, 11 ] ให้ได้มากที่สุด

3.4.2. ความเข้ากันได้ของเบราว์เซอร์

การใช้งานอุปกรณ์จะต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป เบราว์เซอร์แบบสแตนด์อโลนอาจใช้เทคโนโลยีเบราว์เซอร์อื่นที่ไม่ใช่ WebKit อย่างไรก็ตาม แม้ว่าจะใช้แอปพลิเคชันเบราว์เซอร์สำรอง ส่วนประกอบ android.webkit.WebView ที่มอบให้กับแอปพลิเคชันบุคคลที่สามจะต้องอิงตาม WebKit ดังที่อธิบายไว้ในส่วน 3.4.1

การใช้งานอาจจัดส่งสตริงตัวแทนผู้ใช้ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน

แอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit อัปสตรีมหรือการแทนที่ของบุคคลที่สาม) ควรรองรับ HTML5 [ แหล่งข้อมูล 11 ] ให้ได้มากที่สุด การใช้งานอุปกรณ์ขั้นต่ำจะต้องรองรับ API แต่ละตัวที่เกี่ยวข้องกับ HTML5:

แคชแอปพลิเคชัน/การทำงานออฟไลน์ [ แหล่งข้อมูล 12 ]
แท็ก <video> [ แหล่งข้อมูล 13 ]
ตำแหน่งทางภูมิศาสตร์ [ แหล่งข้อมูล, 14 ]

นอกจากนี้ การใช้งานอุปกรณ์ต้องรองรับ HTML5/W3C webstorage API [ Resources, 15 ] และควรรองรับ HTML5/W3C IndexedDB API [ Resources, 16 ] โปรดทราบว่าในขณะที่หน่วยงานมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนมาใช้ IndexedDB มากกว่าพื้นที่เก็บข้อมูลบนเว็บ IndexedDB คาดว่าจะกลายเป็นองค์ประกอบที่จำเป็นใน Android เวอร์ชันอนาคต

3.5. ความเข้ากันได้ของพฤติกรรม API

ลักษณะการทำงานของ API แต่ละประเภท (แบบจัดการ, แบบ soft, แบบเนทีฟ และแบบเว็บ) จะต้องสอดคล้องกับการใช้งานที่ต้องการของโครงการอัปสตรีม Android Open Source [ ทรัพยากร, 3 ] ความเข้ากันได้เฉพาะด้านได้แก่:

อุปกรณ์จะต้องไม่เปลี่ยนพฤติกรรมหรือความหมายของเจตนามาตรฐาน
อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรการใช้งานหรือความหมายของวงจรการใช้งานของส่วนประกอบระบบบางประเภท (เช่น บริการ กิจกรรม ContentProvider ฯลฯ)
อุปกรณ์จะต้องไม่เปลี่ยนความหมายของการอนุญาตมาตรฐาน

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

3.6. เนมสเปซ API

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

ชวา.*
จาวาเอ็กซ์.*
ดวงอาทิตย์.*
หุ่นยนต์.*
com.android.*

การแก้ไขที่ต้องห้ามได้แก่:

การใช้งานอุปกรณ์จะต้องไม่แก้ไข API ที่เปิดเผยต่อสาธารณะบนแพลตฟอร์ม Android โดยการเปลี่ยนวิธีการหรือลายเซ็นคลาสใด ๆ หรือโดยการลบคลาสหรือฟิลด์คลาส
ผู้ใช้อุปกรณ์อาจแก้ไขการใช้งานพื้นฐานของ API แต่การแก้ไขดังกล่าวจะต้องไม่ส่งผลกระทบต่อพฤติกรรมที่ระบุไว้และลายเซ็นภาษา Java ของ API ใด ๆ ที่เปิดเผยต่อสาธารณะ
ผู้ใช้อุปกรณ์จะต้องไม่เพิ่มองค์ประกอบที่เปิดเผยต่อสาธารณะ (เช่น คลาสหรืออินเทอร์เฟซ หรือฟิลด์หรือวิธีการในคลาสหรืออินเทอร์เฟซที่มีอยู่) ให้กับ API ข้างต้น

"องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือโครงสร้างใดๆ ที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android อัปสตรีม กล่าวอีกนัยหนึ่ง ผู้ใช้งานอุปกรณ์จะต้องไม่เปิดเผย API ใหม่หรือแก้ไข API ที่มีอยู่ในเนมสเปซที่ระบุไว้ข้างต้น ผู้ใช้อุปกรณ์อาจทำการแก้ไขภายในเท่านั้น แต่การแก้ไขเหล่านั้นจะต้องไม่ได้รับการโฆษณาหรือเปิดเผยต่อนักพัฒนา

ผู้ติดตั้งอุปกรณ์อาจเพิ่ม API ที่กำหนดเอง แต่ API ดังกล่าวจะต้องไม่อยู่ในเนมสเปซที่เป็นขององค์กรอื่นหรืออ้างอิงถึงองค์กรอื่น ตัวอย่างเช่น ผู้ใช้อุปกรณ์ต้องไม่เพิ่ม API ลงใน com.google.* หรือเนมสเปซที่คล้ายกัน มีเพียง Google เท่านั้นที่สามารถทำได้ ในทำนองเดียวกัน Google ต้องไม่เพิ่ม API ไปยังเนมสเปซของบริษัทอื่น นอกจากนี้ หากการใช้งานอุปกรณ์มี API ที่กำหนดเองนอกเนมสเปซ Android มาตรฐาน API เหล่านั้นจะต้องได้รับการบรรจุในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้เฉพาะแอปที่ใช้งานอย่างชัดเจน (ผ่านกลไก <uses-library> ) เท่านั้นที่จะได้รับผลกระทบจากการใช้หน่วยความจำที่เพิ่มขึ้น ของ API ดังกล่าว

หากผู้ดำเนินการอุปกรณ์เสนอให้ปรับปรุงเนมสเปซแพ็คเกจใดรายการหนึ่งข้างต้น (เช่น โดยการเพิ่มฟังก์ชันการทำงานใหม่ที่เป็นประโยชน์ให้กับ API ที่มีอยู่ หรือการเพิ่ม API ใหม่) ผู้ดำเนินการควรไปที่ source.android.com และเริ่มกระบวนการสนับสนุนการเปลี่ยนแปลงและ รหัสตามข้อมูลบนเว็บไซต์นั้น

โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับแบบแผนมาตรฐานสำหรับการตั้งชื่อ API ในภาษาการเขียนโปรแกรม Java ส่วนนี้มีจุดมุ่งหมายเพื่อเสริมสร้างแบบแผนเหล่านั้นและทำให้มีผลผูกพันผ่านการรวมไว้ในคำจำกัดความความเข้ากันได้นี้

3.7. ความเข้ากันได้ของเครื่องเสมือน

การใช้งานอุปกรณ์ต้องรองรับข้อกำหนดเฉพาะของรหัสไบต์ Dalvik Executable (DEX) และความหมายของ Dalvik Virtual Machine [ แหล่งข้อมูล, 17 ]

การใช้งานอุปกรณ์ต้องกำหนดค่า Dalvik ให้จัดสรรหน่วยความจำตามแพลตฟอร์ม Android อัปสตรีม และตามที่ระบุไว้ในตารางต่อไปนี้ (ดู หัวข้อ 7.1.1 สำหรับขนาดหน้าจอและคำจำกัดความความหนาแน่นของหน้าจอ)

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

ขนาดหน้าจอ	ความหนาแน่นของหน้าจอ	หน่วยความจำแอปพลิเคชัน
เล็ก / ปกติ / ใหญ่	ldpi/mdpi	16MB
เล็ก / ปกติ / ใหญ่	ทีวีดีพีไอ/เอชดีพีไอ	32MB
เล็ก / ปกติ / ใหญ่	xhdpi	64MB
เล็ก / ปกติ / ใหญ่	400dpi	96MB
เล็ก / ปกติ / ใหญ่	xxhdpi	128MB
เล็ก / ปกติ / ใหญ่	xxxhdpi	256MB
xlarge	mdpi	32MB
xlarge	ทีวีดีพีไอ/เอชดีพีไอ	64MB
xlarge	xhdpi	128MB
xlarge	400dpi	192MB
xlarge	xxhdpi	256MB
xlarge	xxxhdpi	512MB

3.8. ความเข้ากันได้ของส่วนต่อประสานผู้ใช้

3.8.1. ตัวเรียกใช้ (หน้าจอหลัก)

Android มีแอปพลิเคชันตัวเรียกใช้งาน (หน้าจอหลัก) และการสนับสนุนแอปพลิเคชันบุคคลที่สามเพื่อแทนที่ตัวเรียกใช้งานอุปกรณ์ (หน้าจอหลัก) การใช้งานอุปกรณ์ที่อนุญาตให้แอปพลิเคชันบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์จะต้องประกาศคุณลักษณะแพลตฟอร์ม android.software.home_screen

3.8.2. วิดเจ็ต

Android กำหนดประเภทส่วนประกอบและ API และวงจรการใช้งานที่เกี่ยวข้องซึ่งอนุญาตให้แอปพลิเคชันเปิดเผย "AppWidget" แก่ผู้ใช้ปลายทาง [ แหล่งข้อมูล, 18 ] การใช้งานอุปกรณ์ที่รองรับการฝังวิดเจ็ตบนหน้าจอหลักต้องเป็นไปตามข้อกำหนดต่อไปนี้ และประกาศการสนับสนุนสำหรับคุณลักษณะแพลตฟอร์ม android.software.app_widgets

ตัวเรียกใช้งานอุปกรณ์ต้องมีการสนับสนุน AppWidget ในตัว และเปิดเผยความสามารถในการใช้อินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และลบ AppWidgets ภายใน Launcher โดยตรง
การใช้งานอุปกรณ์ต้องสามารถเรนเดอร์วิดเจ็ตขนาด 4 x 4 ในขนาดกริดมาตรฐานได้ (ดูแนวทางการออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK [ แหล่งข้อมูล 18 ] เพื่อดูรายละเอียด
การใช้งานอุปกรณ์ที่รองรับหน้าจอล็อคต้องรองรับวิดเจ็ตแอพพลิเคชั่นบนหน้าจอล็อค

3.8.3. การแจ้งเตือน

Android มี API ที่ช่วยให้นักพัฒนาสามารถแจ้งผู้ใช้เกี่ยวกับเหตุการณ์สำคัญ [ แหล่งข้อมูล 19 ] โดยใช้คุณสมบัติฮาร์ดแวร์และซอฟต์แวร์ของอุปกรณ์

API บางตัวอนุญาตให้แอปพลิเคชันดำเนินการแจ้งเตือนหรือดึงดูดความสนใจโดยใช้ฮาร์ดแวร์ โดยเฉพาะเสียง การสั่น และแสง การใช้งานอุปกรณ์ต้องรองรับการแจ้งเตือนที่ใช้คุณสมบัติฮาร์ดแวร์ ตามที่อธิบายไว้ในเอกสารประกอบ SDK และในขอบเขตที่เป็นไปได้กับฮาร์ดแวร์การใช้งานอุปกรณ์ ตัวอย่างเช่น หากการใช้งานอุปกรณ์มีเครื่องสั่นด้วย อุปกรณ์นั้นจะต้องใช้ API การสั่นสะเทือนอย่างถูกต้อง หากการใช้งานอุปกรณ์ขาดฮาร์ดแวร์ API ที่เกี่ยวข้องจะต้องถูกนำไปใช้แบบไม่ต้องดำเนินการ โปรดทราบว่าลักษณะการทำงานนี้มีรายละเอียดเพิ่มเติมใน ส่วนที่ 7

นอกจากนี้ การใช้งานต้องแสดงผลทรัพยากรทั้งหมดอย่างถูกต้อง (ไอคอน ไฟล์เสียง ฯลฯ) ที่ให้ไว้ใน APIs [ Resources, 20 ] หรือในคำแนะนำสไตล์ไอคอน Status/System Bar [ Resources, 21 ] ผู้ใช้อุปกรณ์อาจมอบประสบการณ์ผู้ใช้ทางเลือกสำหรับการแจ้งเตือนมากกว่าที่ได้รับจากการใช้งาน Android Open Source อ้างอิง อย่างไรก็ตาม ระบบการแจ้งเตือนทางเลือกดังกล่าวจะต้องสนับสนุนทรัพยากรการแจ้งเตือนที่มีอยู่ดังที่กล่าวข้างต้น

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

3.8.4. ค้นหา

Android มี API [ แหล่งข้อมูล 22 ] ที่ช่วยให้นักพัฒนาสามารถรวมการค้นหาลงในแอปพลิเคชันของตน และเปิดเผยข้อมูลแอปพลิเคชันของตนในการค้นหาระบบทั่วโลก โดยทั่วไป ฟังก์ชันนี้ประกอบด้วยอินเทอร์เฟซผู้ใช้ทั้งระบบเดียวที่ช่วยให้ผู้ใช้สามารถป้อนคำสั่ง แสดงคำแนะนำในขณะที่ผู้ใช้พิมพ์ และแสดงผลลัพธ์ Android API ช่วยให้นักพัฒนาสามารถใช้อินเทอร์เฟซนี้ซ้ำเพื่อค้นหาภายในแอปของตนเอง และอนุญาตให้นักพัฒนาจัดหาผลลัพธ์ให้กับอินเทอร์เฟซผู้ใช้การค้นหาทั่วโลกทั่วไป

การใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้การค้นหาทั่วทั้งระบบเดียวที่ใช้ร่วมกันซึ่งสามารถให้คำแนะนำแบบเรียลไทม์เพื่อตอบสนองต่อการป้อนข้อมูลของผู้ใช้ การใช้งานอุปกรณ์ต้องใช้ API ที่ช่วยให้นักพัฒนาสามารถใช้อินเทอร์เฟซผู้ใช้นี้ซ้ำเพื่อให้การค้นหาภายในแอปพลิเคชันของตนเอง การใช้งานอุปกรณ์ต้องใช้ API ที่อนุญาตให้แอปพลิเคชันบุคคลที่สามเพิ่มคำแนะนำลงในช่องค้นหาเมื่อทำงานในโหมดการค้นหาทั่วโลก หากไม่มีการติดตั้งแอปพลิเคชันของบริษัทอื่นที่ใช้ฟังก์ชันนี้ ลักษณะการทำงานเริ่มต้นควรเป็นการแสดงผลลัพธ์และคำแนะนำของโปรแกรมค้นหาเว็บ

3.8.5. ขนมปังปิ้ง

แอปพลิเคชันสามารถใช้ API "Toast" (กำหนดไว้ใน [ แหล่งข้อมูล 23 ]) เพื่อแสดงสตริงที่ไม่ใช่โมดอลสั้นๆ แก่ผู้ใช้ ซึ่งจะหายไปหลังจากช่วงระยะเวลาสั้นๆ การใช้งานอุปกรณ์จะต้องแสดง Toast จากแอปพลิเคชันไปยังผู้ใช้ในลักษณะที่มองเห็นได้ชัดเจน

3.8.6. ธีมส์

Android จัดเตรียม "ธีม" ให้เป็นกลไกสำหรับแอปพลิเคชันเพื่อใช้สไตล์กับกิจกรรมหรือแอปพลิเคชันทั้งหมด

Android มีตระกูลธีม "Holo" เป็นชุดรูปแบบที่กำหนดไว้สำหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีม Holo ตามที่กำหนดโดย Android SDK [ แหล่งข้อมูล, 24 ] การใช้งานอุปกรณ์จะต้องไม่เปลี่ยนแปลงคุณลักษณะธีม Holo ใด ๆ ที่เปิดเผยต่อแอปพลิเคชัน [ แหล่งข้อมูล, 25 ]

Android ยังรวมกลุ่มธีม "ค่าเริ่มต้นของอุปกรณ์" ไว้เป็นชุดรูปแบบที่กำหนดไว้เพื่อให้นักพัฒนาแอปพลิเคชันใช้หากต้องการจับคู่รูปลักษณ์ของธีมอุปกรณ์ตามที่กำหนดโดยผู้ใช้อุปกรณ์ การใช้งานอุปกรณ์อาจแก้ไขแอตทริบิวต์ธีม DeviceDefault ที่เปิดเผยต่อแอปพลิเคชัน [ ทรัพยากร, 25 ]

จากเวอร์ชัน 4.4 ปัจจุบัน Android รองรับธีมรูปแบบใหม่ที่มีแถบระบบโปร่งแสง ช่วยให้นักพัฒนาแอปพลิเคชันสามารถเติมเนื้อหาแอปในพื้นที่ด้านหลังสถานะและแถบนำทางได้ เพื่อให้นักพัฒนาได้รับประสบการณ์ที่สอดคล้องกันในการกำหนดค่านี้ สิ่งสำคัญคือต้องรักษารูปแบบไอคอนแถบสถานะในการใช้งานอุปกรณ์ต่างๆ ดังนั้น การใช้งานอุปกรณ์ Android ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ความแรงของสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ออกโดยระบบ เว้นแต่ไอคอนจะแสดงสถานะที่มีปัญหา [ แหล่งข้อมูล, 25 ]

3.8.7. วอลเปเปอร์สด

Android กำหนดประเภทส่วนประกอบและ API และวงจรการใช้งานที่เกี่ยวข้องซึ่งอนุญาตให้แอปพลิเคชันเปิดเผย "วอลเปเปอร์สด" หนึ่งรายการขึ้นไปแก่ผู้ใช้ปลายทาง [ แหล่งข้อมูล, 26 ] วอลเปเปอร์เคลื่อนไหวคือภาพเคลื่อนไหว รูปแบบ หรือรูปภาพที่คล้ายกันซึ่งมีความสามารถในการป้อนข้อมูลที่จำกัดซึ่งแสดงเป็นวอลเปเปอร์เบื้องหลังแอปพลิเคชันอื่นๆ

ฮาร์ดแวร์ถือว่ามีความสามารถในการเรียกใช้วอลเปเปอร์สดได้อย่างน่าเชื่อถือ หากสามารถเรียกใช้วอลเปเปอร์สดทั้งหมดได้ โดยไม่มีข้อจำกัดด้านฟังก์ชันการทำงาน ที่อัตราเฟรมที่สมเหตุสมผล โดยไม่มีผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดในฮาร์ดแวร์ทำให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้พลังงาน CPU หรือแบตเตอรี่มากเกินไป หรือทำงานที่อัตราเฟรมต่ำจนไม่อาจยอมรับได้ ฮาร์ดแวร์ดังกล่าวจะถือว่าไม่สามารถเรียกใช้วอลเปเปอร์สดได้ ตัวอย่างเช่น วอลล์เปเปอร์เคลื่อนไหวบางรายการอาจใช้บริบท Open GL 1.0 หรือ 2.0 ในการแสดงเนื้อหา วอลเปเปอร์เคลื่อนไหวจะไม่ทำงานได้อย่างน่าเชื่อถือบนฮาร์ดแวร์ที่ไม่รองรับบริบท OpenGL หลายบริบท เนื่องจากการใช้วอลเปเปอร์เคลื่อนไหวของบริบท OpenGL อาจขัดแย้งกับแอปพลิเคชันอื่นที่ใช้บริบท OpenGL เช่นกัน

การใช้งานอุปกรณ์ที่สามารถเรียกใช้วอลเปเปอร์สดได้อย่างน่าเชื่อถือตามที่อธิบายไว้ข้างต้นควรใช้วอลเปเปอร์สด การใช้งานอุปกรณ์ที่กำหนดว่าไม่สามารถเรียกใช้วอลเปเปอร์สดได้อย่างน่าเชื่อถือตามที่อธิบายไว้ข้างต้น จะต้องไม่ใช้วอลเปเปอร์สด

3.8.8. การแสดงแอปพลิเคชันล่าสุด

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

3.8.9. การจัดการอินพุต

Android รองรับการจัดการอินพุตและรองรับเครื่องมือแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม การใช้งานอุปกรณ์ที่อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามบนอุปกรณ์ต้องประกาศคุณลักษณะแพลตฟอร์ม android.software.input_methods และรองรับ IME API ตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK

การใช้งานอุปกรณ์ที่ประกาศคุณลักษณะ android.software.input_methods ต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกำหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สาม การใช้งานอุปกรณ์จะต้องแสดงอินเทอร์เฟซการตั้งค่าเพื่อตอบสนองต่อเจตนาของ android.settings.INPUT_METHOD_SETTINGS

3.8.10. ล็อคหน้าจอสื่อการควบคุมระยะไกล

Android มีการรองรับ API การควบคุมระยะไกลที่ช่วยให้แอปพลิเคชันสื่อทำงานร่วมกับการควบคุมการเล่นที่แสดงในมุมมองระยะไกล เช่น หน้าจอล็อคอุปกรณ์ [ แหล่งข้อมูล, 74 ] การใช้งานอุปกรณ์ที่รองรับหน้าจอล็อคในอุปกรณ์และอนุญาตให้ผู้ใช้เพิ่มวิดเจ็ตบนหน้าจอหลักจะต้องรองรับการฝังรีโมทคอนโทรลในหน้าจอล็อคอุปกรณ์ [ แหล่งข้อมูล, 69 ]

3.8.11. ความฝัน

Android รองรับสกรีนเซฟเวอร์แบบโต้ตอบที่เรียกว่า Dreams [ Resources, 76 ] Dreams ช่วยให้ผู้ใช้สามารถโต้ตอบกับแอพพลิเคชั่นต่างๆ เมื่อไม่ได้ใช้งานอุปกรณ์ชาร์จหรือเชื่อมต่อเข้ากับแท่นชาร์จบนโต๊ะ การใช้งานอุปกรณ์จะต้องมีการรองรับ Dreams และมีตัวเลือกการตั้งค่าสำหรับผู้ใช้ในการกำหนดค่า Dreams

3.8.12. ที่ตั้ง

โหมดตำแหน่งจะต้องแสดงในเมนูตำแหน่งภายในการตั้งค่า [ ทรัพยากร, 87 ] บริการระบุตำแหน่งที่ให้บริการผ่าน SettingInjectorService ที่นำมาใช้ใน Android 4.4 จะต้องแสดงในเมนูตำแหน่งเดียวกัน [ ทรัพยากร, 89 ]

3.8.13. ยูนิโค้ด

Android 4.4 รองรับอักขระอีโมจิสี การใช้งานอุปกรณ์ Android จะต้องจัดเตรียมวิธีการป้อนข้อมูลให้กับผู้ใช้สำหรับอักขระ Emoji ที่กำหนดใน Unicode 6.1 [ แหล่งข้อมูล 82 ] และต้องสามารถแสดงอักขระอิโมจิเหล่านี้ด้วยสัญลักษณ์สีได้

3.9. การดูแลระบบอุปกรณ์

Android มีคุณลักษณะที่อนุญาตให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยทำหน้าที่การดูแลระบบอุปกรณ์ในระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือการดำเนินการล้างข้อมูลระยะไกล ผ่านทาง API การดูแลระบบอุปกรณ์ Android [ แหล่งข้อมูล 27 ] การใช้งานอุปกรณ์ต้องมีการใช้งานคลาส DevicePolicyManager [ Resources, 28 ] การใช้งานอุปกรณ์ที่มีการรองรับหน้าจอล็อคจะต้องรองรับนโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสารประกอบ Android SDK [ แหล่งข้อมูล, 27 ]

การใช้งานอุปกรณ์อาจมีแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งทำหน้าที่ดูแลอุปกรณ์ แต่แอปพลิเคชันนี้ต้องไม่ถูกกำหนดให้เป็นแอปเจ้าของอุปกรณ์เริ่มต้น [ ทรัพยากร, 84 ]

3.10. การเข้าถึง

Android มีเลเยอร์การเข้าถึงที่ช่วยให้ผู้ใช้ที่มีความพิการสามารถใช้งานอุปกรณ์ของตนได้ง่ายขึ้น นอกจากนี้ Android ยังมี API แพลตฟอร์มที่ช่วยให้สามารถใช้บริการการเข้าถึงเพื่อรับการเรียกกลับสำหรับเหตุการณ์ของผู้ใช้และระบบ และสร้างกลไกการตอบรับแบบอื่น เช่น การอ่านออกเสียงข้อความ การตอบรับแบบสัมผัส และการนำทางของแทร็กบอล/ดีแพด [ แหล่งข้อมูล 29 ] การใช้งานอุปกรณ์จะต้องจัดให้มีการใช้งานกรอบงานการเข้าถึงของ Android ที่สอดคล้องกับการใช้งาน Android เริ่มต้น การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้โดยเฉพาะ

การใช้งานอุปกรณ์ต้องรองรับการใช้งานบริการการเข้าถึงของบุคคลที่สามผ่าน android.accessibilityservice APIs [ แหล่งข้อมูล, 30 ]
การใช้งานอุปกรณ์ต้องสร้าง AccessibilityEvents และส่งมอบเหตุการณ์เหล่านี้ให้กับการใช้งาน AccessibilityService ที่ลงทะเบียนไว้ทั้งหมดในลักษณะที่สอดคล้องกับการใช้งาน Android เริ่มต้น
การใช้งานอุปกรณ์จะต้องมีกลไกที่ผู้ใช้สามารถเข้าถึงได้เพื่อเปิดและปิดบริการการเข้าถึงและต้องแสดงอินเทอร์เฟซนี้เพื่อตอบสนองต่อเจตนา android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS

นอกจากนี้ การใช้งานอุปกรณ์ควรจัดให้มีบริการการเข้าถึงบนอุปกรณ์ และควรจัดให้มีกลไกสำหรับผู้ใช้ในการเปิดใช้งานบริการการเข้าถึงในระหว่างการตั้งค่าอุปกรณ์ การใช้งานบริการการเข้าถึงแบบโอเพ่นซอร์สมีให้จากโครงการ Eyes Free [ แหล่งข้อมูล, 31 ]

3.11. ข้อความเป็นคำพูด

Android มี API ที่อนุญาตให้แอปพลิเคชันใช้บริการแปลงข้อความเป็นคำพูด (TTS) และอนุญาตให้ผู้ให้บริการใช้บริการ TTS ได้ [ Resources, 32 ] การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดเหล่านี้ที่เกี่ยวข้องกับกรอบงาน Android TTS:

การใช้งานอุปกรณ์ต้องรองรับ API เฟรมเวิร์ก Android TTS และควรมีกลไก TTS ที่รองรับภาษาที่มีอยู่ในอุปกรณ์ โปรดทราบว่าซอฟต์แวร์โอเพ่นซอร์ส Android อัปสตรีมมีการใช้งานกลไก TTS ที่มีคุณลักษณะครบถ้วน
การใช้งานอุปกรณ์ต้องรองรับการติดตั้งกลไก TTS ของบริษัทอื่น
การใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซที่ผู้ใช้สามารถเข้าถึงได้ซึ่งอนุญาตให้ผู้ใช้เลือกกลไก TTS เพื่อใช้ในระดับระบบ

4. ความเข้ากันได้ของบรรจุภัณฑ์ของแอปพลิเคชัน

การใช้งานอุปกรณ์จะต้องติดตั้งและเรียกใช้ไฟล์ ".apk" ของ Android ที่สร้างโดยเครื่องมือ "aapt" ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ [ แหล่งข้อมูล, 33 ]

การใช้งานอุปกรณ์ต้องไม่ขยายรูปแบบ .apk [ Resources, 34 ], Android Manifest [ Resources, 35 ], Dalvik bytecode [ Resources, 17 ] หรือรูปแบบโค้ดไบต์ของ renderscript ในลักษณะที่จะป้องกันไม่ให้ไฟล์เหล่านั้นติดตั้งและทำงานอย่างถูกต้องบน อุปกรณ์อื่นๆ ที่รองรับ ผู้ใช้อุปกรณ์ควรใช้การใช้งานอัปสตรีมอ้างอิงของ Dalvik และระบบการจัดการแพ็คเกจของการใช้งานอ้างอิง

5. ความเข้ากันได้ของมัลติมีเดีย

การใช้งานอุปกรณ์ต้องมีเอาต์พุตเสียงอย่างน้อยหนึ่งรูปแบบ เช่น ลำโพง ช่องเสียบหูฟัง การเชื่อมต่อลำโพงภายนอก ฯลฯ

5.1. ตัวแปลงสัญญาณมีเดีย

การใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อหลักที่ระบุในเอกสารประกอบ Android SDK [ แหล่งข้อมูล 58 ] ยกเว้นในกรณีที่ได้รับอนุญาตอย่างชัดเจนในเอกสารนี้ การใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อ ตัวเข้ารหัส ตัวถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในตารางด้านล่างโดยเฉพาะ ตัวแปลงสัญญาณทั้งหมดเหล่านี้จัดทำขึ้นเป็นการใช้งานซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโครงการ Android Open Source

โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้รับรองใดๆ ว่าตัวแปลงสัญญาณเหล่านี้ไม่มีภาระผูกพันจากสิทธิบัตรของบุคคลที่สาม ผู้ที่ต้องการใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ ขอแนะนำว่าการนำโค้ดนี้ไปใช้ รวมถึงในซอฟต์แวร์โอเพ่นซอร์สหรือแชร์แวร์ อาจต้องได้รับใบอนุญาตสิทธิบัตรจากผู้ถือสิทธิบัตรที่เกี่ยวข้อง

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

พิมพ์	รูปแบบ/ตัวแปลงสัญญาณ	ตัวเข้ารหัส	เครื่องถอดรหัส	รายละเอียด	ประเภทไฟล์ / รูปแบบคอนเทนเนอร์
เสียง	โปรไฟล์ MPEG-4 AAC (AAC LC)	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและกำหนด `android.hardware.microphone`	ที่จำเป็น	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1* ด้วยอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, ถอดรหัสใน Android 3.1+, เข้ารหัสใน Android 4.0+, ไม่รองรับ ADIF) MPEG-TS (.ts, ค้นหาไม่ได้, Android 3.0+)
	โปรไฟล์ MPEG-4 HE AAC (AAC+)	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและกำหนด android.hardware.microphone	ที่จำเป็น	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1* ด้วยอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
	โปรไฟล์ MPEG-4 HE AAC v2 (ปรับปรุง AAC+)		ที่จำเป็น	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1* ด้วยอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
	ประเภทวัตถุเสียง MPEG-4 ER AAC ELD (AAC ความล่าช้าต่ำที่ได้รับการปรับปรุง)	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและกำหนด android.hardware.microphone	ที่จำเป็น	รองรับเนื้อหาโมโน/สเตอริโอด้วยอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
	AMR-NB	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและกำหนด `android.hardware.microphone`	ที่จำเป็น	สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8kHz	3GPP (.3gp)
	AMR-WB	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและกำหนด `android.hardware.microphone`	ที่จำเป็น	9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s สุ่มตัวอย่าง @ 16kHz	3GPP (.3gp)
	แฟลค		ที่จำเป็น (แอนดรอยด์ 3.1 ขึ้นไป)	โมโน/สเตอริโอ (ไม่มีหลายช่องสัญญาณ) อัตราตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz บนอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากดาวน์แซมเปลอร์ 48 ถึง 44.1 kHz ไม่รวมตัวกรองความถี่ต่ำผ่าน) แนะนำแบบ 16 บิต; ไม่มีการใช้ dither สำหรับ 24 บิต	FLAC (.flac) เท่านั้น
	เอ็มพี3		ที่จำเป็น	โมโน/สเตอริโอ 8-320Kbps คงที่ (CBR) หรืออัตราบิตตัวแปร (VBR)	MP3 (.mp3)
	มิดิ		ที่จำเป็น	MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody	พิมพ์ 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) โอตะ (.ota) ไอเมโลดี้ (.imy)
	วอร์บิส		ที่จำเป็น		อ็อก (.ogg) มาโตรสก้า (.mkv)
	พีซีเอ็ม/เวฟ	ที่จำเป็น	ที่จำเป็น	PCM เชิงเส้น 8 บิตและ 16 บิต** (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM แบบ Raw ที่ความถี่ 8000,16000 และ 44100 Hz	คลื่น (.wav)
ภาพ	เจเพ็ก	ที่จำเป็น	ที่จำเป็น	ฐาน+ก้าวหน้า	เจเพ็ก (.jpg)
	กิฟ		ที่จำเป็น		จีไอเอฟ (.gif)
	PNG	ที่จำเป็น	ที่จำเป็น		PNG (.png)
	บีเอ็มพี		ที่จำเป็น		บีเอ็มพี (.bmp)
	เว็บพี	ที่จำเป็น	ที่จำเป็น		เว็บพี (.webp)
วีดีโอ	H.263	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้องและกำหนด `android.hardware.camera` หรือ `android.hardware.camera.front`	ที่จำเป็น		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 เอวีซี	จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้องและกำหนด `android.hardware.camera` หรือ `android.hardware.camera.front`	ที่จำเป็น	โปรไฟล์พื้นฐาน (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, เสียง AAC เท่านั้น, ค้นหาไม่ได้, Android 3.0+)
	MPEG-4 SP		ที่จำเป็น		3GPP (.3gp)
	VP8****	ที่จำเป็น (แอนดรอยด์ 4.3 ขึ้นไป)	ที่จำเป็น (แอนดรอยด์ 2.3.3+)		WebM (.webm) และ Matroska (.mkv, Android 4.0+)***
	วีพี9		ที่จำเป็น (แอนดรอยด์ 4.4 ขึ้นไป)		WebM (.webm) และ Matroska (.mkv, Android 4.0+)***

*หมายเหตุ: ต้องใช้ดาวน์มิกซ์เนื้อหา 5.0/5.1 เท่านั้น การบันทึกหรือการเรนเดอร์มากกว่า 2 ช่องเป็นทางเลือก
**หมายเหตุ: จำเป็นต้องมีการจับ PCM เชิงเส้น 16 บิต ไม่จำเป็นต้องมีการจับ PCM เชิงเส้น 8 บิต
***หมายเหตุ: การใช้งานอุปกรณ์ควรรองรับการเขียนไฟล์ Matroska WebM
****หมายเหตุ: เพื่อคุณภาพที่ยอมรับได้ของบริการสตรีมมิ่งวิดีโอบนเว็บและการประชุมทางวิดีโอ การใช้งานอุปกรณ์ควรใช้ตัวแปลงสัญญาณฮาร์ดแวร์ VP8 ที่ตรงตามข้อกำหนดใน [ แหล่งข้อมูล, 86 ]

5.2. การเข้ารหัสวิดีโอ

การใช้งานอุปกรณ์ Android ที่มีกล้องหลังและประกาศ android.hardware.camera ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ H.264 ต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD (เมื่อรองรับโดยฮาร์ดแวร์)
ความละเอียดวิดีโอ	176 x 144 พิกเซล	480 x 360 พิกเซล	1280x720 พิกเซล
อัตราเฟรมวิดีโอ	12 เฟรมต่อวินาที	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที
บิตเรตของวิดีโอ	56 กิโลบิตต่อวินาที	500 Kbps หรือสูงกว่า	2 Mbps หรือสูงกว่า
ตัวแปลงสัญญาณเสียง	AAC-LC	AAC-LC	AAC-LC
ช่องสัญญาณเสียง	1 (โมโน)	2 (สเตอริโอ)	2 (สเตอริโอ)
อัตราบิตของเสียง	24 กิโลบิตต่อวินาที	128 กิโลบิตต่อวินาที	192 กิโลบิตต่อวินาที

การใช้งานอุปกรณ์ Android ที่มีกล้องหลังและประกาศ android.hardware.camera ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ VP8 ต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	เอชดี 720p (เมื่อรองรับโดยฮาร์ดแวร์)	เอชดี 1080p (เมื่อรองรับโดยฮาร์ดแวร์)
ความละเอียดวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280x720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมวิดีโอ	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที
บิตเรตของวิดีโอ	800 กิโลบิตต่อวินาที	2 Mbps	4Mbps	10 Mbps

5.3. การถอดรหัสวิดีโอ

การใช้งานอุปกรณ์ Android ควรรองรับโปรไฟล์การถอดรหัสวิดีโอ VP8, VP9 และ H.264 ต่อไปนี้ การใช้งานอุปกรณ์ควรรองรับการสลับความละเอียดวิดีโอแบบไดนามิกภายในสตรีมเดียวกันสำหรับตัวแปลงสัญญาณ VP8, VP9 และ H.264

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	เอชดี 720p (เมื่อรองรับโดยฮาร์ดแวร์)	เอชดี 1080p (เมื่อรองรับโดยฮาร์ดแวร์)
ความละเอียดวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280x720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมวิดีโอ	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที	30 เฟรมต่อวินาที
บิตเรตของวิดีโอ	800 กิโลบิตต่อวินาที	2 Mbps	8 Mbps	20 Mbps

5.4. การบันทึกเสียง

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

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

นอกเหนือจากข้อกำหนดการบันทึกข้างต้น เมื่อแอปพลิเคชันเริ่มบันทึกสตรีมเสียงโดยใช้แหล่งกำเนิดเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

ต้องปิดใช้งานการประมวลผลการลดเสียงรบกวน (หากมี)
จะต้องปิดใช้งานการควบคุมอัตราขยายอัตโนมัติ (หากมี)

จาก Android 4.4 คลาส android.media.MediaRecorder.AudioSource มีแหล่งเสียงใหม่: REMOTE_SUBMIX อุปกรณ์ต้องใช้แหล่งกำเนิดเสียง REMOTE_SUBMIX อย่างถูกต้อง เพื่อว่าเมื่อแอปพลิเคชันใช้ android.media.AudioRecord API เพื่อบันทึกจากแหล่งกำเนิดเสียงนี้ แอปพลิเคชันจะสามารถจับเสียงที่ผสมกันของสตรีมเสียงทั้งหมด ยกเว้นสิ่งต่อไปนี้:

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

หมายเหตุ: แม้ว่าข้อกำหนดบางประการที่สรุปไว้ข้างต้นจะระบุว่า "ควร" ตั้งแต่ Android 4.3 แต่คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตได้รับการวางแผนให้เปลี่ยนเป็น "ต้อง" นั่นคือข้อกำหนดเหล่านี้เป็นทางเลือกใน Android 4.4 แต่ จะต้องใช้ ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android ได้รับการสนับสนุนอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเหล่านี้ มิฉะนั้นจะไม่สามารถใช้งานร่วมกันได้กับ Android เมื่ออัปเกรดเป็นเวอร์ชันอนาคต

หากแพลตฟอร์มรองรับเทคโนโลยีการปราบปรามเสียงรบกวนที่ปรับสำหรับการจดจำคำพูดเอฟเฟกต์จะต้องสามารถควบคุมได้จาก android.media.audiofx.NoiseSuppressor API ยิ่งไปกว่านั้นฟิลด์ "UUID" สำหรับตัวบ่งชี้เอฟเฟกต์ของตัวยับยั้งเสียงจะต้องระบุการใช้เทคโนโลยีการปราบปรามเสียงแต่ละครั้งโดยเฉพาะ

5.5. เวลาแฝงของเสียง

แฝงเสียงคือการหน่วงเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายคลาสพึ่งพาเวลาแฝงสั้น ๆ เพื่อให้ได้เอฟเฟกต์เสียงแบบเรียลไทม์

เพื่อวัตถุประสงค์ของส่วนนี้:

"เวลาแฝงเอาท์พุท" ถูกกำหนดเป็นช่วงเวลาระหว่างเมื่อแอปพลิเคชันเขียนเฟรมของข้อมูลรหัส PCM และเมื่อได้ยินเสียงที่เกี่ยวข้องโดยผู้ฟังภายนอกหรือสังเกตเห็นโดยทรานสดิวเซอร์
"ความล่าช้าในการส่งออกเย็น" ถูกกำหนดเป็นเวลาแฝงเอาท์พุทสำหรับเฟรมแรกเมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและขับเคลื่อนลงก่อนที่จะมีการร้องขอ
"เวลาแฝงเอาต์พุตอย่างต่อเนื่อง" ถูกกำหนดเป็นเวลาแฝงเอาต์พุตสำหรับเฟรมที่ตามมาหลังจากอุปกรณ์กำลังเล่นเสียงแล้ว
"อินพุตแฝง" เป็นช่วงเวลาระหว่างเมื่อมีการนำเสนอเสียงภายนอกไปยังอุปกรณ์และเมื่อแอปพลิเคชันอ่านเฟรมที่เกี่ยวข้องของข้อมูลรหัส PCM ที่สอดคล้องกัน
"แฝงอินพุตเย็น" ถูกกำหนดเป็นผลรวมของเวลาอินพุตที่หายไปและเวลาแฝงอินพุตสำหรับเฟรมแรกเมื่อระบบอินพุตเสียงไม่ได้ใช้งานและขับเคลื่อนลงก่อนที่จะมีการร้องขอ
"เวลาแฝงอินพุตต่อเนื่อง" ถูกกำหนดเป็นเวลาแฝงอินพุตสำหรับเฟรมที่ตามมาในขณะที่อุปกรณ์กำลังจับเสียงแล้ว
"OpenSL ES PCM Buffer API API" เป็นชุดของ OpenSL es es ที่เกี่ยวข้องกับ PCM ภายใน Android NDK; ดู ndk_root /docs/opensles/index.html

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

เวลาแฝงเอาต์พุตเย็น 100 มิลลิวินาทีหรือน้อยกว่า
เวลาแฝงเอาต์พุตต่อเนื่อง 45 มิลลิวินาทีหรือน้อยกว่า

หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้หลังจากการสอบเทียบเริ่มต้นใด ๆ เมื่อใช้ OpenSL ES Buffer Buffer API API สำหรับเวลาแฝงเอาท์พุทอย่างต่อเนื่อง โดยการรายงานคุณสมบัติ "Android.hardware.audio.low-Latency" ผ่านชั้นเรียน android.content.pm.PackageManager [ ทรัพยากร, 37 ] ในทางกลับกันหากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดเหล่านี้จะต้องไม่รายงานการสนับสนุนสำหรับเสียงต่ำ

ตาม ส่วน 7.2.5 ฮาร์ดแวร์ไมโครโฟนอาจถูกละเว้นโดยการใช้งานอุปกรณ์

การใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟนและประกาศ android.hardware.microphone ควรเป็นไปตามข้อกำหนดเวลาแฝงเสียงเหล่านี้:

เวลาแฝงอินพุตเย็น 100 มิลลิวินาทีหรือน้อยกว่า
เวลาแฝงอินพุตต่อเนื่อง 50 มิลลิวินาทีหรือน้อยกว่า

5.6. โปรโตคอลเครือข่าย

อุปกรณ์จะต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสาร Android SDK [ ทรัพยากร, 58 ] โดยเฉพาะอุปกรณ์จะต้องรองรับโปรโตคอลเครือข่ายสื่อต่อไปนี้:

RTSP (RTP, SDP)
การสตรีมแบบก้าวหน้า http (s)
HTTP (S) โปรโตคอลการสตรีมสดแบบสดรุ่น 3 [ ทรัพยากร, 59 ]

6. เครื่องมือนักพัฒนาและตัวเลือกความเข้ากันได้

6.1. เครื่องมือสำหรับนักพัฒนา

การใช้งานอุปกรณ์ต้องรองรับเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Android ที่ให้ไว้ใน Android SDK โดยเฉพาะอุปกรณ์ที่รองรับ Android จะต้องเข้ากันได้กับ:

Android Debug Bridge (รู้จักกันในชื่อ ADB) [ ทรัพยากร, 33 ]
การใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK adb daemon ด้านอุปกรณ์ต้องไม่ทำงานโดยค่าเริ่มต้นและจะต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดสะพาน Android Debug
Android มีการสนับสนุน ADB ที่ปลอดภัย Secure ADB ช่วยให้ ADB บนโฮสต์ที่ผ่านการรับรองความถูกต้องที่รู้จัก การใช้งานอุปกรณ์จะต้องรองรับ ADB ที่ปลอดภัย
Dalvik Debug Monitor Service (เรียกว่า DDMS) [ ทรัพยากร, 33 ]
การใช้งานอุปกรณ์ต้องรองรับคุณสมบัติ ddms ทั้งหมดตามที่บันทึกไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุน ddms ควรปิดใช้งานตามค่าเริ่มต้น แต่จะต้องได้รับการสนับสนุนทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ดังที่กล่าวไว้ข้างต้น
ลิง [ ทรัพยากร, 36 ]
การใช้งานอุปกรณ์ต้องมีกรอบการทำงาน Monkey และเปิดให้แอปพลิเคชันใช้งานได้
Systrace [ ทรัพยากร, 33 ]
การใช้งานอุปกรณ์จะต้องรองรับเครื่องมือ Systrace ตามที่บันทึกไว้ใน Android SDK Systrace จะต้องไม่ได้ใช้งานโดยค่าเริ่มต้นและจะต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace

ระบบที่ใช้ Linux และระบบ Apple Macintosh ส่วนใหญ่รู้จักอุปกรณ์ Android โดยใช้เครื่องมือ Android SDK มาตรฐาน โดยไม่มีการสนับสนุนเพิ่มเติม อย่างไรก็ตาม โดยทั่วไประบบ Microsoft Windows จะต้องมีไดรเวอร์สำหรับอุปกรณ์ Android ใหม่ (เช่น รหัสผู้ขายใหม่และบางครั้งรหัสอุปกรณ์ใหม่จำเป็นต้องใช้ไดรเวอร์ USB แบบกำหนดเองสำหรับระบบ Windows) หากเครื่องมือ adb ไม่รู้จักการใช้งานอุปกรณ์ตามที่ระบุไว้ใน Android SDK มาตรฐาน ผู้ติดตั้งอุปกรณ์จะต้องจัดเตรียมไดรเวอร์ Windows เพื่อให้นักพัฒนาสามารถเชื่อมต่อได้ อุปกรณ์ที่ใช้โปรโตคอล adb ไดรเวอร์เหล่านี้จะต้องจัดเตรียมไว้สำหรับ Windows XP, Windows Vista, Windows 7 และ Windows 8 ทั้งในรุ่น 32 บิตและ 64 บิต

6.2. ตัวเลือกนักพัฒนา

Android รวมถึงการสนับสนุนสำหรับนักพัฒนาเพื่อกำหนดค่าการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอุปกรณ์จะต้องให้เกียรติ Android.settings.application_development_settings ตั้งใจที่จะแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน [ ทรัพยากร, 77 ] การใช้งาน Android อัปสตรีมซ่อนเมนูตัวเลือกนักพัฒนาโดยค่าเริ่มต้นและช่วยให้ผู้ใช้สามารถเปิดตัวเลือกนักพัฒนาได้หลังจากกดเจ็ด (7) ครั้งในการตั้งค่า> เกี่ยวกับอุปกรณ์> รายการเมนูหมายเลขสร้าง การใช้งานอุปกรณ์จะต้องให้ประสบการณ์ที่สอดคล้องกันสำหรับตัวเลือกนักพัฒนา โดยเฉพาะการใช้งานอุปกรณ์จะต้องซ่อนตัวเลือกนักพัฒนาโดยค่าเริ่มต้นและต้องจัดเตรียมกลไกเพื่อเปิดใช้งานตัวเลือกนักพัฒนาที่สอดคล้องกับการใช้งาน Android ต้นน้ำ

6.2.1. การทดลอง

Android 4.4 แนะนำ Art ซึ่งเป็นรันไทม์ Android ทดลองสามารถเข้าถึงได้ภายในเมนูตัวเลือกนักพัฒนาเพื่อดูตัวอย่าง การใช้งานอุปกรณ์ควรรวมถึงศิลปะ (libart.so) และสนับสนุนการบูตคู่จากตัวเลือกนักพัฒนา แต่ต้องเก็บ Dalvik (libdvm.so) เป็นรันไทม์เริ่มต้น

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์เฉพาะที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาบุคคลที่สาม การใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบ Android SDK หาก API ใน SDK โต้ตอบกับส่วนประกอบฮาร์ดแวร์ที่ระบุว่าเป็นทางเลือกและการใช้งานอุปกรณ์ไม่มีส่วนประกอบนั้น:

คำจำกัดความของคลาสที่สมบูรณ์ (ตามที่จัดทำโดย SDK) สำหรับ API ของส่วนประกอบจะต้องยังคงอยู่
พฤติกรรมของ API จะต้องถูกนำไปใช้โดยไม่มีการดำเนินการในรูปแบบที่สมเหตุสมผล
วิธีการ API ต้องส่งคืนค่าว่างตามที่เอกสาร SDK อนุญาต
วิธีการ API ต้องส่งคืนการใช้งานแบบ no-op ของคลาสโดยที่เอกสาร SDK ไม่อนุญาตให้มีค่า Null
วิธีการ API ต้องไม่ทิ้งข้อยกเว้นที่ไม่ได้จัดทำเป็นเอกสารไว้ในเอกสารประกอบ SDK

ตัวอย่างทั่วไปของสถานการณ์ที่ข้อกำหนดเหล่านี้มีผลบังคับใช้คือ Telephony API: แม้แต่บนอุปกรณ์ที่ไม่ใช่โทรศัพท์ API เหล่านี้ก็ต้องถูกนำไปใช้ในลักษณะที่ไม่มีการดำเนินการที่สมเหตุสมผล

การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างถูกต้องผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager [ ทรัพยากร, 37 ]

7.1. จอแสดงผลและกราฟิก

Android มีสิ่งอำนวยความสะดวกที่ปรับสินทรัพย์แอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติสำหรับอุปกรณ์เพื่อให้แน่ใจว่าแอปพลิเคชันของบุคคลที่สามทำงานได้ดีในการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย [ ทรัพยากร, 38 ] อุปกรณ์ต้องใช้ API และพฤติกรรมเหล่านี้อย่างถูกต้อง ดังรายละเอียดในส่วนนี้

หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้มีการกำหนดดังนี้:

"ขนาดเส้นทแยงมุมทางกายภาพ" คือระยะห่างเป็นนิ้วระหว่างมุมสองมุมที่อยู่ตรงข้ามกันของส่วนที่ส่องสว่างของจอแสดงผล
"dpi" (หมายถึง "จุดต่อนิ้ว") คือจำนวนพิกเซลที่ล้อมรอบด้วยช่วงเชิงเส้นแนวนอนหรือแนวตั้งที่ 1" เมื่อระบุค่า dpi แล้ว dpi ทั้งแนวนอนและแนวตั้งจะต้องอยู่ภายในช่วง
"อัตราส่วนภาพ" คืออัตราส่วนของขนาดที่ยาวกว่าของหน้าจอต่อขนาดที่สั้นกว่า ตัวอย่างเช่น จอแสดงผลขนาด 480x854 พิกเซลจะเป็น 854/480 = 1.779 หรือประมาณ "16:9"
"พิกเซลที่ไม่ขึ้นกับความหนาแน่น" หรือ ("dp") เป็นหน่วยพิกเซลเสมือนจริงที่ทำให้เป็นปกติกับหน้าจอ 160 dpi คำนวณเป็น: pixels = dps * (density / 160)

7.1.1. การกำหนดค่าหน้าจอ

ขนาดหน้าจอ

เฟรมเวิร์ก Android UI รองรับขนาดหน้าจอที่หลากหลายและอนุญาตให้แอปพลิเคชันสอบถามขนาดหน้าจออุปกรณ์ (หรือที่รู้จักกันดีว่า "เค้าโครงหน้าจอ") ผ่าน android.content.res.Configuration.screenLayout พร้อม SCREENLAYOUT_SIZE_MASK การใช้งานอุปกรณ์จะต้องรายงานขนาดหน้าจอที่ถูกต้องตามที่กำหนดไว้ในเอกสาร Android SDK [ ทรัพยากร, 38 ] และกำหนดโดยแพลตฟอร์ม Android ต้นน้ำ โดยเฉพาะการใช้งานอุปกรณ์จะต้องรายงานขนาดหน้าจอที่ถูกต้องตามขนาดหน้าจอ Pixel (DP) ที่ไม่ขึ้นกับตรรกะต่อไปนี้

อุปกรณ์ต้องมีขนาดหน้าจออย่างน้อย 426 dp x 320 dp ('เล็ก')
อุปกรณ์ที่รายงานขนาดหน้าจอ 'ปกติ' ต้องมีขนาดหน้าจออย่างน้อย 480 dp x 320 dp
อุปกรณ์ที่รายงานขนาดหน้าจอ 'ใหญ่' ต้องมีขนาดหน้าจออย่างน้อย 640 dp x 480 dp
อุปกรณ์ที่รายงานขนาดหน้าจอ 'xlarge' ต้องมีขนาดหน้าจออย่างน้อย 960 dp x 720 dp

นอกจากนี้อุปกรณ์จะต้องมีขนาดหน้าจออย่างน้อย 2.5 นิ้วในขนาดเส้นทแยงมุมทางกายภาพ

อุปกรณ์จะต้องไม่เปลี่ยนขนาดหน้าจอที่รายงานได้ตลอดเวลา

แอปพลิเคชันสามารถเลือกระบุขนาดหน้าจอที่รองรับผ่านแอตทริบิวต์ <supports-screens> ในไฟล์ AndroidManifest.xml การใช้งานอุปกรณ์จะต้องให้เกียรติแอพพลิเคชั่นที่ระบุไว้อย่างถูกต้องสำหรับหน้าจอขนาดเล็กปกติขนาดใหญ่และ xlarge ตามที่อธิบายไว้ในเอกสาร Android SDK

อัตราส่วนหน้าจอ

อัตราส่วนภาพต้องเป็นค่าจาก 1.3333 (4: 3) ถึง 1.86 (ประมาณ 16: 9)

ความหนาแน่นของหน้าจอ

เฟรมเวิร์ก Android UI กำหนดชุดของความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยให้นักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรแอปพลิเคชัน การใช้งานอุปกรณ์จะต้องรายงานความหนาแน่นของ Android Framework อย่างใดอย่างหนึ่งต่อไปนี้ผ่าน API android.util.DisplayMetrics API และจะต้องดำเนินการแอปพลิเคชันที่ความหนาแน่นมาตรฐานนี้

120 dpi หรือที่รู้จักกันในชื่อ 'ldpi'
160 DPI หรือที่รู้จักกันในชื่อ 'MDPI'
213 DPI หรือที่รู้จักกันในชื่อ 'TVDPI'
240 DPI หรือที่รู้จักกันในชื่อ 'HDPI'
320 dpi หรือที่รู้จักกันในชื่อ 'xhdpi'
400 dpi หรือที่รู้จักกันในชื่อ '400dpi'
480 dpi หรือที่รู้จักกันในชื่อ 'xxhdpi'
640 DPI หรือที่รู้จักกันในชื่อ 'xxxhdpi'

การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพของหน้าจอมากที่สุดเว้นแต่ความหนาแน่นเชิงตรรกะจะผลักขนาดหน้าจอที่รายงานต่ำกว่าขั้นต่ำที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพมากที่สุดส่งผลให้ขนาดหน้าจอที่เล็กกว่าขนาดหน้าจอที่รองรับขนาดเล็กที่สุด (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานต่ำสุดถัดไป

7.1.2. เมตริกการแสดงผล

การใช้งานอุปกรณ์จะต้องรายงานค่าที่ถูกต้องสำหรับตัวชี้วัดที่แสดงทั้งหมดที่กำหนดไว้ใน android.util.DisplayMetrics [ ทรัพยากร, 39 ]

7.1.3. การวางแนวหน้าจอ

อุปกรณ์จะต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันไปยังการวางแนวหน้าจอแนวหน้าหรือแนวนอน นั่นคืออุปกรณ์จะต้องเคารพคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอเฉพาะ การใช้งานอุปกรณ์อาจเลือกแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

อุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ ทุกครั้งที่สอบถามผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

อุปกรณ์จะต้องไม่เปลี่ยนขนาดหน้าจอที่รายงานหรือความหนาแน่นเมื่อเปลี่ยนการวางแนว

อุปกรณ์จะต้องรายงานการวางแนวหน้าจอที่พวกเขาสนับสนุน ( android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape ) และต้องรายงานการวางแนวที่สนับสนุนอย่างน้อยหนึ่งครั้ง ตัวอย่างเช่นอุปกรณ์ที่มีหน้าจอภูมิทัศน์แบบคงที่เช่นโทรทัศน์หรือแล็ปท็อปจะต้องรายงานเฉพาะ android.hardware.screen.landscape

7.1.4. การเร่งความเร็วกราฟิก 2D และ 3D

การใช้งานอุปกรณ์จะต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ซึ่งเป็นตัวเป็นตนและรายละเอียดในเอกสาร Android SDK การใช้งานอุปกรณ์ควรรองรับ OpenGL ES 3.0 บนอุปกรณ์ที่มีความสามารถในการรองรับ OpenGL ES 3.0 การใช้งานอุปกรณ์จะต้องรองรับ Android Renderscript ตามรายละเอียดในเอกสารประกอบ Android SDK [ ทรัพยากร, 8 ]

การใช้งานอุปกรณ์จะต้องระบุตัวเองอย่างถูกต้องว่าสนับสนุน OpenGL ES 1.0, OpenGL ES 2.0 หรือ OpenGL ES 3.0 นั่นคือ:

API ที่ได้รับการจัดการ (เช่นผ่านวิธี GLES10.getString() ) ต้องรายงานการสนับสนุนสำหรับ OpenGL ES 1.0 และ OpenGL ES 2.0
Native C/C ++ OpenGL APIs (นั่นคือแอพที่มีให้กับแอพผ่าน LIBGLES_V1CM.SO, LIBGLES_V2.SO หรือ libegl.SO) ต้องรายงานการสนับสนุนสำหรับ OpenGL ES 1.0 และ OpenGL ES 2.0
การใช้งานอุปกรณ์ที่ประกาศการสนับสนุนสำหรับ OpenGL ES 3.0 จะต้องรองรับ API ที่ได้รับการจัดการ OpenGL ES 3.0 และรวมถึงการสนับสนุนสำหรับ APIs C/C ++ Native ในการใช้งานอุปกรณ์ที่ประกาศการสนับสนุนสำหรับ OpenGL ES 3.0, LIBGLESV2.so ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.0 นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0

การใช้งานอุปกรณ์อาจใช้ส่วนขยาย OpenGL es ที่ต้องการ อย่างไรก็ตามการใช้งานอุปกรณ์จะต้องรายงานผ่านทาง OpenGL es ที่มีการจัดการและ APIs ดั้งเดิมสตริงส่วนขยายทั้งหมดที่พวกเขาให้การสนับสนุนและในทางกลับกันจะต้องไม่รายงานสตริงส่วนขยายที่พวกเขาไม่สนับสนุน

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

Android มีกลไกสำหรับแอปพลิเคชันเพื่อประกาศว่าพวกเขาต้องการเปิดใช้งานการเร่งความเร็วฮาร์ดแวร์สำหรับกราฟิก 2D ที่แอปพลิเคชันกิจกรรมหน้าต่างหรือระดับมุมมองผ่านการใช้แท็ก Manifest android:hardwareAccelerated หรือ API โดยตรง [ ทรัพยากร, 9 ]

ใน Android 4.4 การใช้งานอุปกรณ์จะต้องเปิดใช้งานการเร่งความเร็วฮาร์ดแวร์ตามค่าเริ่มต้นและต้องปิดใช้งานการเร่งความเร็วฮาร์ดแวร์หากนักพัฒนา SO ร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดการเร่งความเร็วฮาร์ดแวร์โดยตรงผ่าน Android View API

นอกจากนี้การใช้งานอุปกรณ์จะต้องแสดงพฤติกรรมที่สอดคล้องกับเอกสาร Android SDK เกี่ยวกับการเร่งความเร็วของฮาร์ดแวร์ [ ทรัพยากร, 9 ]

Android มีวัตถุ TextureView ที่ให้นักพัฒนารวมพื้นผิว opengl es ที่เร่งความเร็วฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลำดับชั้น UI การใช้งานอุปกรณ์จะต้องรองรับ TextureView API และต้องแสดงพฤติกรรมที่สอดคล้องกับการใช้งาน Android ต้นน้ำ

Android รวมถึงการสนับสนุนสำหรับ EGL_ANDROID_RECORDABLE แอตทริบิวต์ EGLCONFIG ที่ระบุว่า EGLCONFIG รองรับการเรนเดอร์ไปยัง AnativeWindow ที่บันทึกภาพลงในวิดีโอหรือไม่ การใช้งานอุปกรณ์จะต้องรองรับส่วนขยาย EGL_ANDROID_RECORDABLE [ ทรัพยากร, 79 ]

7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันดั้งเดิม

Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กทำงานในโหมดขนาดหน้าจอ 'ปกติ' เทียบเท่า (ความกว้าง 320DP) เพื่อประโยชน์ของแอพพลิเคชั่นดั้งเดิมที่ไม่ได้พัฒนาสำหรับ Android รุ่นเก่า การใช้งานอุปกรณ์จะต้องมีโหมดการรองรับการเข้ากันได้ของแอปพลิเคชันแบบดั้งเดิมตามที่ใช้โดยรหัสโอเพ่นซอร์ส Android ต้นน้ำ นั่นคือการใช้งานอุปกรณ์จะต้องไม่เปลี่ยนทริกเกอร์หรือเกณฑ์ที่โหมดความเข้ากันได้เปิดใช้งานและต้องไม่เปลี่ยนพฤติกรรมของโหมดความเข้ากันได้เอง

7.1.6. ประเภทหน้าจอ

หน้าจอการใช้งานอุปกรณ์จัดเป็นหนึ่งในสองประเภท:

การใช้งานการแสดงผลพิกเซลแบบคงที่: หน้าจอเป็นแผงเดียวที่รองรับความกว้างและความสูงพิกเซลเดียวเท่านั้น โดยทั่วไปแล้วหน้าจอจะถูกรวมเข้ากับอุปกรณ์ ตัวอย่าง ได้แก่ โทรศัพท์มือถือแท็บเล็ตและอื่น ๆ
การใช้งานการแสดงผลตัวแปรพิกเซล: การใช้งานอุปกรณ์ไม่มีหน้าจอฝังตัวและมีพอร์ตเอาต์พุตวิดีโอเช่น VGA, HDMI หรือพอร์ตไร้สายสำหรับการแสดงผลหรือมีหน้าจอฝังตัวที่สามารถเปลี่ยนขนาดพิกเซลได้ ตัวอย่างเช่นโทรทัศน์กล่องรับสัญญาณและอื่น ๆ

การใช้งานอุปกรณ์พิกเซลคงที่

การใช้งานอุปกรณ์พิกเซลแบบคงที่อาจใช้หน้าจอที่มีขนาดพิกเซลใด ๆ โดยที่พวกเขาตรงตามข้อกำหนดที่กำหนดคำจำกัดความความเข้ากันได้นี้

การใช้งานพิกเซลคงที่อาจรวมพอร์ตเอาต์พุตวิดีโอสำหรับใช้กับจอแสดงผลภายนอก อย่างไรก็ตามหากจอแสดงผลนั้นเคยใช้สำหรับการใช้งานแอพอุปกรณ์จะต้องเป็นไปตามข้อกำหนดดังต่อไปนี้:

อุปกรณ์จะต้องรายงานการกำหนดค่าหน้าจอและการแสดงผลการแสดงผลตามรายละเอียดในส่วนที่ 7.1.1 และ 7.1.2 เป็นจอแสดงผลพิกเซลคงที่
อุปกรณ์จะต้องรายงานความหนาแน่นเชิงตรรกะเช่นเดียวกับการแสดงผลพิกเซลคงที่
อุปกรณ์จะต้องรายงานขนาดหน้าจอที่เหมือนกับหรือใกล้กับจอแสดงผลพิกเซลคงที่

ตัวอย่างเช่นแท็บเล็ตที่มีขนาด 7 "เส้นทแยงมุมที่มีความละเอียด 1024x600 พิกเซลถือเป็นการใช้งานจอแสดงผล MDPI ขนาดใหญ่พิกเซลขนาดใหญ่หากมีพอร์ตเอาต์พุตวิดีโอที่แสดงที่ 720p หรือ 1080p การใช้งานอุปกรณ์จะต้องปรับขนาดเอาท์พุทเพื่อให้แอปพลิเคชัน จะดำเนินการเฉพาะในหน้าต่าง MDPI ขนาดใหญ่โดยไม่คำนึงว่ามีการใช้งานพอร์ตการแสดงผลพิกเซลแบบพิกเซลหรือวิดีโอ

การใช้งานอุปกรณ์ตัวแปรพิกเซล

การใช้อุปกรณ์ตัวแปรพิกเซลต้องรองรับอย่างน้อยหนึ่งใน 1280x720, 1920x1080 หรือ 3840x2160 (นั่นคือ 720p, 1080p หรือ 4K) การใช้งานอุปกรณ์ด้วยการแสดงผลตัวแปรพิกเซลจะต้องไม่รองรับการกำหนดค่าหน้าจอหรือโหมดอื่น ๆ การใช้งานอุปกรณ์ด้วยหน้าจอตัวแปรพิกเซลอาจเปลี่ยนการกำหนดค่าหน้าจอหรือโหมดที่รันไทม์หรือเวลาบูต ตัวอย่างเช่นผู้ใช้กล่องรับสัญญาณอาจแทนที่จอแสดงผล 720p ด้วยจอแสดงผล 1080p และการใช้งานอุปกรณ์อาจปรับตาม

นอกจากนี้การใช้งานอุปกรณ์ตัวแปรพิกเซลจะต้องรายงานถังการกำหนดค่าต่อไปนี้สำหรับขนาดพิกเซลเหล่านี้:

1280x720 (เรียกอีกอย่างว่า 720p): ขนาดหน้าจอ 'ขนาดใหญ่', 'TVDPI' (213 DPI) ความหนาแน่น
1920x1080 (หรือที่รู้จักกันในชื่อ 1080p): ขนาดหน้าจอ 'ใหญ่', 'XHDPI' (320 dpi) ความหนาแน่น
3840x2160 (เรียกอีกอย่างว่า 4K): ขนาดหน้าจอ 'ใหญ่', 'xxxhdpi' (640 dpi) ความหนาแน่น

เพื่อความชัดเจนการใช้งานอุปกรณ์ที่มีขนาดพิกเซลตัวแปรถูก จำกัด ไว้ที่ 720p, 1080p หรือ 4K ใน Android 4.4 และต้องกำหนดค่าให้รายงานขนาดหน้าจอและถังความหนาแน่นตามที่ระบุไว้ข้างต้น

7.1.7. เทคโนโลยีหน้าจอ

แพลตฟอร์ม Android รวมถึง API ที่อนุญาตให้แอปพลิเคชันแสดงกราฟิกที่หลากหลายไปยังจอแสดงผล อุปกรณ์จะต้องรองรับ API เหล่านี้ทั้งหมดตามที่กำหนดโดย Android SDK เว้นแต่ได้รับอนุญาตโดยเฉพาะในเอกสารนี้ โดยเฉพาะ:

อุปกรณ์จะต้องรองรับการแสดงผลที่มีความสามารถในการแสดงผลกราฟิกสี 16 บิตและควรรองรับจอแสดงผลที่มีความสามารถในการกราฟิกสี 24 บิต
อุปกรณ์จะต้องรองรับการแสดงผลที่สามารถแสดงภาพเคลื่อนไหวได้
เทคโนโลยีการแสดงผลที่ใช้ต้องมีอัตราส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.1 นั่นคืออัตราส่วนพิกเซลจะต้องอยู่ใกล้สี่เหลี่ยม (1.0) ด้วยความอดทน 10%

7.1.8. จอแสดงผลภายนอก

Android รวมถึงการรองรับการแสดงทุติยภูมิเพื่อเปิดใช้งานความสามารถในการแบ่งปันสื่อและ API ของนักพัฒนาซอฟต์แวร์สำหรับการเข้าถึงจอแสดงผลภายนอก หากอุปกรณ์รองรับการแสดงผลภายนอกไม่ว่าจะผ่านการเชื่อมต่อการแสดงผลเพิ่มเติมแบบมีสาย, ไร้สายหรือการเชื่อมต่อการแสดงผลเพิ่มเติมแบบฝังตัวการใช้งานอุปกรณ์จะต้องใช้ API Display Manager ตามที่อธิบายไว้ในเอกสาร Android SDK [ ทรัพยากร, 75 ] การใช้งานอุปกรณ์ที่รองรับเอาต์พุตวิดีโอที่ปลอดภัยและมีความสามารถในการรองรับพื้นผิวที่ปลอดภัยจะต้องประกาศการสนับสนุนสำหรับ Display.FLAG_SECURE โดยเฉพาะการใช้งานอุปกรณ์ที่ประกาศการสนับสนุนสำหรับ Display.FLAG_SECURE ต้องรองรับ HDCP 2.x หรือสูงกว่า สำหรับการแสดงผลไร้สาย miracast หรือ HDCP 1.2 หรือสูงกว่า สำหรับการแสดงแบบมีสาย การใช้งาน Open Source ของ Android ต้นน้ำรวมถึงการสนับสนุนสำหรับการแสดงแบบไร้สาย (Miracast) และ Wired (HDMI) ที่ตอบสนองความต้องการนี้

7.2. อุปกรณ์อินพุต

7.2.1. คีย์บอร์ด

การใช้งานอุปกรณ์:

ต้องรวมถึงการสนับสนุนสำหรับกรอบการจัดการอินพุต (ซึ่งช่วยให้นักพัฒนาบุคคลที่สามสามารถสร้างเอ็นจิ้นการจัดการอินพุต - IE Soft Keyboard) ตามรายละเอียดที่ http://developer.android.com
ต้องมีการติดตั้งซอฟต์คีย์บอร์ดอย่างน้อยหนึ่งครั้ง (ไม่ว่าจะมีฮาร์ดคีย์บอร์ดหรือไม่ก็ตาม)
อาจรวมถึงการใช้ซอฟต์คีย์บอร์ดเพิ่มเติม
อาจมีแป้นพิมพ์ฮาร์ดแวร์
ต้องไม่รวมแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุใน android.content.res.Configuration.keyboard [ ทรัพยากร, 40 ] (นั่นคือ qwerty หรือ 12-key)

7.2.2. การนำทางแบบไม่สัมผัส

การใช้งานอุปกรณ์:

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

7.2.3. ปุ่มนำทาง

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

ฟังก์ชั่นด้านหลังและการปรับสภาพควรมีปุ่มหรือไอคอนที่มองเห็นได้เว้นแต่จะซ่อนอยู่พร้อมกับฟังก์ชั่นการนำทางอื่น ๆ ในโหมดเต็มหน้าจอ ฟังก์ชั่นโฮมจะต้องมีปุ่มหรือไอคอนที่มองเห็นได้เว้นแต่จะซ่อนอยู่พร้อมกับฟังก์ชั่นการนำทางอื่น ๆ ในโหมดเต็มหน้าจอ

ฟังก์ชั่นเมนูเลิกใช้งาน Action Bar ตั้งแต่ Android 4.0 การใช้งานอุปกรณ์ไม่ควรใช้ปุ่มทางกายภาพเฉพาะสำหรับฟังก์ชั่นเมนู หากปุ่มเมนูทางกายภาพถูกนำไปใช้และอุปกรณ์กำลังเรียกใช้แอปพลิเคชันด้วย targetSdkVersion > 10 การใช้งานอุปกรณ์:

สำหรับอุปกรณ์ที่เปิดใช้งานกับ Android 4.4 ต้องแสดงปุ่ม Action Overflow บนแถบแอ็คชั่นเมื่อมองเห็นแถบการกระทำและเมนูการกระทำที่เกิดขึ้นของ Popu จะไม่ว่างเปล่า
สำหรับอุปกรณ์ที่มีอยู่ที่เปิดตัวด้วยเวอร์ชันก่อนหน้า แต่การอัปเกรดเป็น Android 4.4 ควรแสดงปุ่มการกระทำที่ล้นในแถบแอ็คชั่นเมื่อมองเห็นแถบการกระทำและป๊อปอัปเมนูล้นแอ็คชั่นแอ็คชั่นไม่ว่างเปล่า
ต้องไม่แก้ไขตำแหน่งของการกระทำป๊อปอัพล้นที่แสดงโดยเลือกปุ่มล้นในแถบการกระทำ
อาจทำให้แอ็คชั่นล้นป๊อปอัพที่ตำแหน่งที่แก้ไขบนหน้าจอเมื่อมีการแสดงโดยเลือกปุ่มเมนูฟิสิคัล

สำหรับความเข้ากันได้ย้อนหลังการใช้งานอุปกรณ์จะต้องใช้ฟังก์ชันเมนูไปยังแอปพลิเคชันเมื่อ targetSdkVersion <= 10 ไม่ว่าจะด้วยปุ่มทางกายภาพคีย์ซอฟต์แวร์หรือท่าทาง ควรนำเสนอฟังก์ชั่นเมนูนี้เว้นแต่จะซ่อนอยู่พร้อมกับฟังก์ชั่นการนำทางอื่น ๆ

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

การใช้งานอุปกรณ์อาจใช้ส่วนที่แตกต่างกันของหน้าจอเพื่อแสดงปุ่มนำทาง แต่ถ้าเป็นเช่นนั้นต้องปฏิบัติตามข้อกำหนดเหล่านี้:

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

7.2.4. อินพุตหน้าจอสัมผัส

การใช้งานอุปกรณ์ควรมีระบบอินพุตตัวชี้บางชนิด (ไม่ว่าจะเป็นเมาส์หรือสัมผัส) อย่างไรก็ตามหากการใช้งานอุปกรณ์ไม่รองรับระบบอินพุตตัวชี้จะต้องไม่รายงาน android.hardware.touchscreen หรือ android.hardware.faketouch คงที่คุณลักษณะคงที่ การใช้งานอุปกรณ์ที่มีระบบอินพุตตัวชี้:

ควรรองรับพอยน์เตอร์ที่ติดตามอย่างอิสระหากระบบอินพุตอุปกรณ์รองรับพอยน์เตอร์หลายตัว
ต้องรายงานค่าของ android.content.res.Configuration.touchscreen [ ทรัพยากร, 40 ] สอดคล้องกับประเภทของหน้าจอสัมผัสเฉพาะบนอุปกรณ์

Android รวมถึงการรองรับหน้าจอสัมผัสที่หลากหลายทัชแพดและอุปกรณ์อินพุตสัมผัสปลอม การใช้งานอุปกรณ์บนหน้าจอสัมผัสนั้นเชื่อมโยงกับการแสดงผล [ ทรัพยากร, 81 ] เพื่อให้ผู้ใช้มีความประทับใจในการจัดการรายการโดยตรงบนหน้าจอ เนื่องจากผู้ใช้สัมผัสกับหน้าจอโดยตรงระบบจึงไม่จำเป็นต้องมีการจ่ายเพิ่มเติมใด ๆ เพื่อระบุวัตถุที่ถูกจัดการ ในทางตรงกันข้ามอินเทอร์เฟซแบบสัมผัสปลอมจะให้ระบบอินพุตผู้ใช้ที่ใกล้เคียงกับชุดย่อยของความสามารถหน้าจอสัมผัส ตัวอย่างเช่นเมาส์หรือรีโมทคอนโทรลที่ขับเคอร์เซอร์บนหน้าจอใกล้เคียงกับการสัมผัส แต่ต้องการให้ผู้ใช้ต้องจุดแรกหรือโฟกัสจากนั้นคลิก อุปกรณ์อินพุตจำนวนมากเช่นเมาส์, แทร็กแพด, เมาส์อากาศที่ใช้ไจโร, ไจโร-ตัวชี้, จอยสติ๊กและมัลติทัชแทร็คแพดสามารถรองรับการโต้ตอบแบบสัมผัสปลอม 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 สัมบูรณ์ของตำแหน่งตัวชี้และแสดงตัวชี้ภาพบนหน้าจอ [ ทรัพยากร, 80 ]
ต้องรายงานเหตุการณ์การสัมผัสด้วยรหัสการดำเนินการ [ ทรัพยากร, 80 ] ที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นกับตัวชี้ที่จะ down หรือ up บนหน้าจอ [ ทรัพยากร, 80 ]
ต้องรองรับตัวชี้ down และ up บนวัตถุบนหน้าจอซึ่งช่วยให้ผู้ใช้เลียนแบบแตะบนวัตถุบนหน้าจอ
ต้องรองรับตัวชี้ down , ตัว up , ตัวชี้ down แล้วชี้ up ในสถานที่เดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลาหนึ่งซึ่งช่วยให้ผู้ใช้สามารถเลียนแบบการแตะสองครั้งบนวัตถุบนหน้าจอ [ ทรัพยากร, 80 ]
ต้องรองรับตัวชี้ down บนจุดที่กำหนดไว้บนหน้าจอตัวชี้จะย้ายไปยังจุดอื่น ๆ บนหน้าจอตามด้วยตัวชี้ up ซึ่งช่วยให้ผู้ใช้เลียนแบบการลากแบบสัมผัส
ต้องรองรับตัวชี้ down จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งที่แตกต่างกันบนหน้าจออย่างรวดเร็วจากนั้นชี้ up บนหน้าจอซึ่งช่วยให้ผู้ใช้สามารถเหวี่ยงวัตถุบนหน้าจอ

อุปกรณ์ที่ประกาศการสนับสนุนสำหรับ android.hardware.faketouch.multitouch.distinct ต้องเป็นไปตามข้อกำหนดสำหรับ Faketouch ด้านบนและต้องรองรับการติดตามอินพุตตัวชี้อิสระสองตัวขึ้นไปที่แตกต่างกัน

7.2.6. ไมโครโฟน

การใช้งานอุปกรณ์อาจละเว้นไมโครโฟน อย่างไรก็ตามหากการใช้งานอุปกรณ์ละเว้นไมโครโฟนจะต้องไม่รายงานค่าคงที่ของ android.hardware.microphone คงที่และต้องใช้ API การบันทึกเสียงเป็น NO-OPS ตาม ส่วนที่ 7 ในทางกลับกันการใช้งานอุปกรณ์ที่มีไมโครโฟน:

ต้องรายงาน android.hardware.microphone ค่าคงที่
ควรเป็นไปตามข้อกำหนดด้านคุณภาพเสียงใน ส่วน 5.4
ควรเป็นไปตามข้อกำหนดเวลาแฝงเสียงใน ส่วน 5.5

7.3. เซนเซอร์

Android มี APIs สำหรับการเข้าถึงประเภทเซ็นเซอร์ที่หลากหลาย การใช้งานอุปกรณ์โดยทั่วไปอาจละเว้นเซ็นเซอร์เหล่านี้ ดังที่ระบุไว้ในส่วนย่อยต่อไปนี้ หากอุปกรณ์มีเซ็นเซอร์ประเภทใดประเภทหนึ่งซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาบุคคลที่สาม การใช้งานอุปกรณ์จะต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK ตัวอย่างเช่น การใช้งานอุปกรณ์:

ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager [ ทรัพยากร, 37 ]
ต้องส่งคืนรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่าน SensorManager.getSensorList() และวิธีการที่คล้ายกัน
ต้องทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น โดยการคืนค่าจริงหรือเท็จตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียก Listener เซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)
ต้องรายงานการวัดเซ็นเซอร์ทั้งหมดโดยใช้ระบบระหว่างประเทศที่เกี่ยวข้องของหน่วย (เช่นตัวชี้วัด) สำหรับแต่ละประเภทเซ็นเซอร์ตามที่กำหนดไว้ในเอกสาร Android SDK [ ทรัพยากร, 41 ]

รายการข้างต้นไม่ครอบคลุมทั้งหมด ลักษณะการทำงานที่บันทึกไว้ของ Android SDK นั้นถือว่าเชื่อถือได้

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

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

7.3.1. มาตรความเร่ง

การใช้งานอุปกรณ์ควรมีมาตรความเร่งแบบ 3 แกน หากการใช้งานอุปกรณ์มีมาตรความเร่งแบบ 3 แกน มันจะ:

ควรจะสามารถส่งมอบกิจกรรมที่ 120 Hz หรือมากกว่า โปรดทราบว่าในขณะที่ความถี่ accelerometer ด้านบนระบุว่า "ควร" สำหรับ Android 4.4 คำจำกัดความความเข้ากันได้สำหรับรุ่นในอนาคตมีการวางแผนที่จะเปลี่ยนสิ่งเหล่านี้เป็น "ต้อง" นั่นคือมาตรฐานเหล่านี้เป็นทางเลือกใน Android แต่ จะต้องใช้ ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และใหม่ที่ใช้งาน Android ได้รับการสนับสนุนอย่างมากเพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ใน Android ดังนั้นพวกเขาจะสามารถอัพเกรดเป็นแพลตฟอร์มในอนาคต
ต้องปฏิบัติตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API (ดู [ ทรัพยากร, 41 ])
จะต้องสามารถวัดจากการตกอย่างอิสระจนถึงแรงโน้มถ่วงสองเท่า (2g) หรือมากกว่านั้นบนเวกเตอร์สามมิติใดๆ
ต้องมีความแม่นยำ 8 บิตขึ้นไป
ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^2

7.3.2. แมกนีโตมิเตอร์

การใช้งานอุปกรณ์ควรมีเครื่องวัดสนามแม่เหล็กแบบ 3 แกน (เช่น เข็มทิศ) หากอุปกรณ์มีเครื่องวัดสนามแม่เหล็กแบบ 3 แกนด้วย จะต้อง:

ต้องสามารถส่งเหตุการณ์ที่ 10 Hz หรือสูงกว่า
ต้องปฏิบัติตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API (ดู [ ทรัพยากร, 41 ])
จะต้องสามารถสุ่มตัวอย่างความแรงของสนามแม่เหล็กได้หลากหลายเพียงพอที่จะครอบคลุมสนามแม่เหล็กโลก
ต้องมีความแม่นยำ 8 บิตขึ้นไป
ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT

7.3.3. จีพีเอส

การใช้งานอุปกรณ์ควรมีตัวรับสัญญาณ GPS ด้วย หากการใช้งานอุปกรณ์มีตัวรับสัญญาณ GPS ควรมีเทคนิค "GPS แบบช่วยเหลือ" บางรูปแบบเพื่อลดเวลาล็อค GPS ให้เหลือน้อยที่สุด

7.3.4. ไจโรสโคป

การใช้งานอุปกรณ์ควรมีไจโรสโคป (เช่น เซ็นเซอร์เปลี่ยนเชิงมุม) อุปกรณ์ไม่ควรมีเซ็นเซอร์ไจโรสโคป เว้นแต่จะมีเครื่องวัดความเร่งแบบ 3 แกนรวมอยู่ด้วย หากการใช้งานอุปกรณ์มีไจโรสโคป มันจะ:

ต้องได้รับการชดเชยอุณหภูมิ
จะต้องมีความสามารถในการวัดการปฐมนิเทศเปลี่ยนสูงถึง 5.5*pi เรเดียน/วินาที (นั่นคือประมาณ 1,000 องศาต่อวินาที)
ควรจะสามารถส่งมอบกิจกรรมที่ 200 Hz หรือมากกว่า โปรดทราบว่าในขณะที่ความถี่ของไจโรสโคปด้านบนระบุว่า "ควร" สำหรับ Android 4.4 คำจำกัดความความเข้ากันได้สำหรับรุ่นในอนาคตมีการวางแผนที่จะเปลี่ยนสิ่งเหล่านี้เป็น "ต้อง" นั่นคือมาตรฐานเหล่านี้เป็นทางเลือกใน Android แต่ จะต้องใช้ ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และใหม่ที่ใช้งาน Android ได้รับการสนับสนุนอย่างมากเพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ ดังนั้นพวกเขาจะสามารถอัพเกรดเป็นแพลตฟอร์มในอนาคตได้
ต้องมีความแม่นยำ 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.6. เทอร์โมมิเตอร์

การใช้งานอุปกรณ์อาจรวมถึงเทอร์โมมิเตอร์โดยรอบ (เช่นเซ็นเซอร์อุณหภูมิ) หากมีอยู่จะต้องกำหนดเป็น SENSOR_TYPE_AMBIENT_TEMPERATURE และจะต้องวัดอุณหภูมิโดยรอบ (ห้อง) ในองศาเซลเซียส

การใช้งานอุปกรณ์อาจ แต่ไม่ควรรวมเซ็นเซอร์อุณหภูมิ CPU หากมีอยู่จะต้องกำหนดเป็น SENSOR_TYPE_TEMPERATURE จะต้องวัดอุณหภูมิของ CPU อุปกรณ์และจะต้องไม่วัดอุณหภูมิอื่นใด หมายเหตุประเภทเซ็นเซอร์ SENSOR_TYPE_TEMPERATURE ถูกเลิกใช้ใน Android 4.0

7.3.7. โฟโตมิเตอร์

การใช้งานอุปกรณ์อาจมีโฟโตมิเตอร์ (เช่น เซ็นเซอร์วัดแสงโดยรอบ)

7.3.8. พร็อกซิมิตี้เซนเซอร์

การใช้งานอุปกรณ์อาจรวมถึงเซ็นเซอร์ความใกล้ชิด หากการใช้งานอุปกรณ์มีเซ็นเซอร์ความใกล้ชิด อุปกรณ์นั้นจะต้องวัดความใกล้ชิดของวัตถุในทิศทางเดียวกับหน้าจอ กล่าวคือ พรอกซิมิตี้เซนเซอร์จะต้องได้รับการวางแนวเพื่อตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากจุดประสงค์หลักของเซนเซอร์ประเภทนี้คือการตรวจจับโทรศัพท์ที่ผู้ใช้ใช้งานอยู่ หากการใช้งานอุปกรณ์มีพรอกซิมิตี้เซนเซอร์ที่มีการวางแนวอื่น จะต้องไม่สามารถเข้าถึงได้ผ่าน API นี้ หากการใช้งานอุปกรณ์มีเซ็นเซอร์ความใกล้ชิด จะต้องมีความแม่นยำ 1 บิตขึ้นไป

7.4. การเชื่อมต่อข้อมูล

7.4.1. โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการวางสายเสียงและส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA ในขณะที่การโทรด้วยเสียงเหล่านี้อาจเปลี่ยนแพ็คเก็ตได้หรือไม่ แต่ก็มีวัตถุประสงค์เพื่อวัตถุประสงค์ของ Android ที่พิจารณาว่าเป็นอิสระจากการเชื่อมต่อข้อมูลใด ๆ ที่อาจนำไปใช้โดยใช้เครือข่ายเดียวกัน กล่าวอีกนัยหนึ่ง ฟังก์ชัน "โทรศัพท์" ของ Android และ API อ้างอิงถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่น การใช้งานอุปกรณ์ที่ไม่สามารถโทรออกหรือส่ง/รับข้อความ SMS จะต้องไม่รายงานคุณสมบัติ "android.hardware.telephony" หรือคุณสมบัติย่อยใดๆ โดยไม่คำนึงว่าจะใช้เครือข่ายโทรศัพท์เคลื่อนที่สำหรับการเชื่อมต่อข้อมูลหรือไม่

Android อาจใช้กับอุปกรณ์ที่ไม่รวมฮาร์ดแวร์โทรศัพท์ นั่นคือ Android เข้ากันได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์ อย่างไรก็ตาม หากการใช้งานอุปกรณ์ประกอบด้วยระบบโทรศัพท์ GSM หรือ CDMA อุปกรณ์นั้นจะต้องใช้การสนับสนุนอย่างเต็มที่สำหรับ API สำหรับเทคโนโลยีนั้น การใช้งานอุปกรณ์ที่ไม่มีฮาร์ดแวร์ระบบโทรศัพท์จะต้องใช้งาน API แบบเต็มโดยไม่มีการดำเนินการ

7.4.2. IEEE 802.11 (Wi-Fi)

การใช้งานอุปกรณ์ Android ควรมีการสนับสนุนสำหรับหนึ่งหรือมากกว่าหนึ่งรูปแบบของ 802.11 (b/g/a/n ฯลฯ ) หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ 802.11 จะต้องใช้ Android API ที่สอดคล้องกัน

การใช้งานอุปกรณ์จะต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสาร SDK [ Resources, 62 ] การใช้งานอุปกรณ์ที่รวมถึงการสนับสนุน Wi-Fi จะต้องรองรับ Multicast DNS (MDNs) การใช้งานอุปกรณ์จะต้องไม่กรองแพ็คเก็ต MDNS (224.0.0.251) ตลอดเวลาที่ใช้งานได้ตลอดเวลารวมถึงเมื่อหน้าจอไม่ได้อยู่ในสถานะที่ใช้งานอยู่

7.4.2.1 Wi-Fi โดยตรง

การใช้งานอุปกรณ์ควรรวมถึงการสนับสนุนสำหรับ Wi-Fi Direct (Wi-Fi Peer-to-Peer) หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ Wi-Fi Direct จะต้องใช้ Android API ที่สอดคล้องกันตามที่อธิบายไว้ในเอกสาร SDK [ Resources, 68 ] หากการใช้งานอุปกรณ์รวมถึงการสนับสนุน Wi-Fi Direct ให้:

ต้องสนับสนุนการทำงานของ Wi-Fi ปกติ
ควรสนับสนุนการดำเนินงาน Direct Wi-Fi และ Wi-Fi พร้อมกัน

7.4.2.2 การตั้งค่าลิงค์โดยตรง Wi-Fi

การใช้งานอุปกรณ์ควรรวมถึงการสนับสนุนสำหรับการตั้งค่าลิงก์ Direct Link Wi-Fi (TDLs) ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK [ ทรัพยากร, 85 ] หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLs และ TDLs ถูกเปิดใช้งานโดย Wifimanager API อุปกรณ์:

ควรใช้ TDLs เฉพาะเมื่อเป็นไปได้และเป็นประโยชน์
ควรมีฮิวริสติกบางอย่างและไม่ใช้ TDLs เมื่อประสิทธิภาพของมันอาจจะเลวร้ายยิ่งกว่าการผ่านจุดเชื่อมต่อ Wi-Fi

7.4.3. บลูทู ธ

การใช้งานอุปกรณ์ควรมีตัวรับส่งสัญญาณบลูทูธด้วย การใช้งานอุปกรณ์ที่รวมถึงตัวรับส่งสัญญาณบลูทู ธ จะต้องเปิดใช้งาน Bluetooth API ที่ใช้ RFCOMM ตามที่อธิบายไว้ในเอกสาร SDK และประกาศคุณสมบัติฮาร์ดแวร์ Android.hardware.bluetooth [ ทรัพยากร, 42 ] การใช้งานอุปกรณ์ควรใช้โปรไฟล์ Bluetooth ที่เกี่ยวข้อง เช่น A2DP, AVRCP, OBEX ฯลฯ ตามความเหมาะสมกับอุปกรณ์

การใช้งานอุปกรณ์ที่รวมถึงการสนับสนุนสำหรับ Bluetooth Gatt (โปรไฟล์แอตทริบิวต์ทั่วไป) เพื่อเปิดใช้งานการสื่อสารกับอุปกรณ์บลูทู ธ สมาร์ทหรือสมาร์ทสมาร์ทจะต้องเปิดใช้งาน Bluetooth API ที่ใช้ GATT ตามที่อธิบายไว้ในเอกสาร SDK และประกาศคุณสมบัติฮาร์ดแวร์ Android.hardware.bluetooth_le [ ทรัพยากร 42 ].

7.4.4. การสื่อสารระยะใกล้

การใช้งานอุปกรณ์ควรมีตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near-Field Communications (NFC) หากการใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC อยู่ด้วย ก็จะ:

ต้องรายงานคุณลักษณะ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [ ทรัพยากร, 37 ]
จะต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้:
- ต้องสามารถทำหน้าที่เป็นผู้อ่าน/ผู้เขียน NFC Forum ได้ (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านทางมาตรฐาน NFC ต่อไปนี้:
  - เอ็นเอฟซีเอ (ISO14443-3A)
  - เอ็นเอฟซีบี (ISO14443-3B)
  - เอ็นเอฟซีเอฟ (JIS 6319-4)
  - ไอโซเดป (ISO 14443-4)
  - แท็ก NFC Forum ประเภท 1, 2, 3, 4 (กำหนดโดย NFC Forum)
ควรมีความสามารถในการอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าในขณะที่มาตรฐาน NFC ด้านล่างนี้ระบุว่า "ควร" คำจำกัดความความเข้ากันได้สำหรับรุ่นในอนาคตมีการวางแผนที่จะเปลี่ยนสิ่งเหล่านี้เป็น "ต้อง" นั่นคือมาตรฐานเหล่านี้เป็นทางเลือกในเวอร์ชันนี้ แต่ จะต้องใช้ ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และใหม่ที่ใช้งาน Android รุ่นนี้ ได้รับการสนับสนุนอย่างมากเพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ในขณะนี้ ดังนั้นพวกเขาจะสามารถอัพเกรดเป็นแพลตฟอร์มในอนาคตได้
- เอ็นเอฟซีวี (ISO 15693)
จะต้องสามารถส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบเพียร์ทูเพียร์ต่อไปนี้:
- ISO 18092
- LLCP 1.0 (กำหนดโดยฟอรัม NFC)
- SDP 1.0 (กำหนดโดยฟอรัม NFC)
- NDEF Push Protocol [ ทรัพยากร, 43 ]
- SNEP 1.0 (กำหนดโดยฟอรัม NFC)
ต้องมีการสนับสนุนสำหรับลำแสง Android [ ทรัพยากร, 65 ]:
- MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
- Device implementations MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 67 ].
- MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
- MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
- MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
- SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
- SHOULD enable Android Beam by default
- MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations must support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 60 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 61 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name "urn:nfc:sn:handover" for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
MUST poll for all supported technologies while in NFC discovery mode.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.

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

Android 4.4 introduces support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller capable of HCE and Application ID (AID) routing, then it:

MUST report the android.hardware.nfc.hce feature constant
MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 90 ]

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

MIFARE Classic (NXP MF1S503x [ Resources, 44 ], MF1S703x [ Resources, 45 ])
MIFARE Ultralight (NXP MF0ICU1 [ Resources, 46 ], MF0ICU2 [ Resources, 47 ])
NDEF on MIFARE Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

ต้องใช้ Android API ที่เกี่ยวข้องตามที่จัดทำโดย Android SDK
ต้องรายงานคุณลักษณะ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [ Resources, 37 ] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
ต้องไม่ใช้ Android API ที่เกี่ยวข้องหรือรายงานคุณลักษณะ com.nxp.mifare เว้นแต่จะใช้การสนับสนุน NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 37 ], and MUST implement the Android NFC API as a no-op.

เนื่องจากคลาส android.nfc.NdefMessage และ android.nfc.NdefRecord แสดงถึงรูปแบบการแสดงข้อมูลที่ไม่ขึ้นอยู่กับโปรโตคอล การใช้งานอุปกรณ์จึงต้องใช้ API เหล่านี้ แม้ว่าจะไม่รวมการรองรับ NFC หรือประกาศคุณสมบัติ android.hardware.nfc ก็ตาม

7.4.5. ความสามารถเครือข่ายขั้นต่ำ

การใช้งานอุปกรณ์จะต้องมีการรองรับเครือข่ายข้อมูลหนึ่งรูปแบบขึ้นไป โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์จะต้องมีการรองรับมาตรฐานข้อมูลอย่างน้อยหนึ่งมาตรฐานที่มีความสามารถ 200Kbit/วินาที หรือสูงกว่า ตัวอย่างของเทคโนโลยีที่ตอบสนองความต้องการนี้ ได้แก่ Edge, HSPA, EV-DO, 802.11G, Ethernet ฯลฯ

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

อุปกรณ์อาจใช้การเชื่อมต่อข้อมูลมากกว่าหนึ่งรูปแบบ

7.4.6. Sync Settings

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 88 ].

7.5. กล้อง

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

7.5.1. กล้องมองหลัง

การใช้งานอุปกรณ์ควรมีกล้องหันหน้าไปทางด้านหลัง หากการใช้งานอุปกรณ์มีกล้องหันหน้าไปทางด้านหลัง:

ต้องมีความละเอียดอย่างน้อย 2 ล้านพิกเซล
ควรมีการโฟกัสอัตโนมัติฮาร์ดแวร์หรือซอฟต์แวร์โฟกัสอัตโนมัติที่ใช้ในไดรเวอร์กล้อง (โปร่งใสไปยังซอฟต์แวร์แอปพลิเคชัน)
อาจมีฮาร์ดแวร์คงที่หรือ EDOF (ความลึกของฟิลด์ขยาย)
อาจรวมถึงแฟลช หากกล้องมีแฟลชไฟแฟลชจะต้องไม่ติดสว่างในขณะที่ Android.hardware.camera.previewCallback อินสแตนซ์ได้ลงทะเบียนบนพื้นผิวตัวอย่างกล้องเว้นแต่แอ FLASH_MODE_AUTO ชันจะเปิดใช้งาน FLASH_MODE_ON อย่างชัดเจน Camera.Parameters Object โปรดทราบว่าข้อ จำกัด นี้ไม่ได้ใช้กับแอปพลิเคชันกล้องระบบในตัวของอุปกรณ์ แต่เฉพาะกับแอพพลิเคชั่นของบุคคลที่สามโดยใช้ Camera.PreviewCallback

7.5.2. กล้องหน้า

การใช้งานอุปกรณ์อาจรวมถึงกล้องด้านหน้า หากการใช้งานอุปกรณ์มีกล้องหน้าหันหน้าไปทาง:

ต้องมีความละเอียดอย่างน้อย VGA (นั่นคือ 640x480 พิกเซล)
ต้องไม่ใช้กล้องหน้าหน้าเป็นค่าเริ่มต้นสำหรับกล้อง API That is, the camera API in Android has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the อุปกรณ์.
อาจรวมถึงคุณสมบัติ (เช่นโฟกัสอัตโนมัติ, แฟลช ฯลฯ ) ที่มีให้กับกล้องหันหน้าไปทางด้านหลังตามที่อธิบายไว้ในหัวข้อ 7.5.1
ต้องไตร่ตรองในแนวนอน (เช่นมิเรอร์) สตรีมที่แสดงโดยแอพใน camerapreview ดังต่อไปนี้:

หากการใช้งานอุปกรณ์มีความสามารถในการหมุนโดยผู้ใช้ (เช่นโดยอัตโนมัติผ่านตัวเร่งความเร็วหรือด้วยตนเองผ่านการป้อนข้อมูลของผู้ใช้) ตัวอย่างกล้องจะต้องทำมิเรอร์ในแนวนอนเมื่อเทียบกับการวางแนวปัจจุบันของอุปกรณ์
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
มิฉะนั้นจะต้องดูตัวอย่างตามแนวแกนแนวนอนเริ่มต้นของอุปกรณ์

MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. (If the device implementation does not support postview, this requirement obviously does not apply.)
ต้องไม่สะท้อนภาพสุดท้ายที่จับภาพนิ่งหรือวิดีโอที่ส่งคืนไปยังแอปพลิเคชันโทรกลับหรือมุ่งมั่นที่จะจัดเก็บสื่อ

7.5.3. พฤติกรรม API ของกล้อง

การใช้งานอุปกรณ์จะต้องใช้พฤติกรรมต่อไปนี้สำหรับ API ที่เกี่ยวข้องกับกล้องสำหรับกล้องทั้งด้านหน้าและด้านหลัง:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
หากแอปพลิเคชันลงทะเบียนเป็น android.hardware.Camera.PreviewCallback อินสแตนซ์และระบบเรียกใช้เมธอด onPreviewFrame() เมื่อรูปแบบตัวอย่างคือ YCBCR_420_SP ข้อมูลใน byte[] ที่ส่งผ่านไปยัง onPreviewFrame() จะต้องอยู่ในรูปแบบการเข้ารหัส NV21 นั่นคือ NV21 จะต้องเป็นค่าเริ่มต้น
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

Device implementations MUST implement the full Camera API included in the Android SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. ตัวอย่างเช่นกล้องที่ขาดโฟกัสอัตโนมัติจะต้องโทรหา android.hardware.Camera.AutoFocusCallback อินสแตนซ์ (แม้ว่าสิ่งนี้จะไม่มีความเกี่ยวข้องกับกล้องที่ไม่ใช่ Autofocus) โปรดทราบว่าสิ่งนี้ใช้กับกล้องหน้า ตัวอย่างเช่นแม้ว่ากล้องหน้าส่วนใหญ่ส่วนใหญ่จะไม่รองรับออโต้โฟกัส แต่การเรียก API จะต้องเป็น "ปลอม" ตามที่อธิบายไว้

การใช้งานอุปกรณ์จะต้องรับรู้และให้เกียรติแต่ละชื่อพารามิเตอร์ที่กำหนดเป็นค่าคงที่บนคลาส android.hardware.Camera.Parameters หากฮาร์ดแวร์พื้นฐานรองรับคุณสมบัติ หากฮาร์ดแวร์ของอุปกรณ์ไม่รองรับคุณสมบัติ API จะต้องทำงานตามเอกสาร ในทางกลับกันการใช้งานอุปกรณ์จะต้องไม่ให้เกียรติหรือรับรู้ค่าคงที่สตริงที่ส่งผ่านไปยังวิธี android.hardware.Camera.setParameters() นอกเหนือจากที่บันทึกไว้เป็นค่าคงที่บน android.hardware.Camera.Parameters นั่นคือการใช้งานอุปกรณ์จะต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาตและต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4. การวางแนวกล้อง

ทั้งกล้องด้านหน้าและด้านหลังจะต้องมุ่งเน้นเพื่อให้มิติยาวของกล้องจัดแนวกับมิติยาวของหน้าจอ That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. สิ่งนี้ใช้โดยไม่คำนึงถึงการวางแนวธรรมชาติของอุปกรณ์ นั่นคือมันใช้กับอุปกรณ์ภูมิทัศน์หลักรวมถึงอุปกรณ์ภาพบุคคล

7.6. หน่วยความจำและการจัดเก็บ

7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace MUST return the value "true" for ActivityManager.isLowRamDevice() .

Device implementations MUST have at least 1GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 1GB. Device implementations that run Android are very strongly encouraged to have at least 2GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Shared External Storage

การใช้งานอุปกรณ์จะต้องเสนอที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอปพลิเคชัน ที่เก็บข้อมูลที่ใช้ร่วมกันจะต้องมีขนาดอย่างน้อย 1GB

การใช้งานอุปกรณ์จะต้องกำหนดค่าด้วยที่เก็บข้อมูลที่ใช้ร่วมกันโดยค่าเริ่มต้น "ออกจากกล่อง" หากที่เก็บข้อมูลที่ใช้ร่วมกันไม่ได้ติดตั้งบนเส้นทาง Linux /sdcard อุปกรณ์จะต้องมีลิงก์สัญลักษณ์ Linux จาก /sdcard ไปยังจุดเมานต์จริง

การใช้งานอุปกรณ์จะต้องบังคับใช้เป็นเอกสารการอนุญาต android.permission.WRITE_EXTERNAL_STORAGE ในที่เก็บข้อมูลที่ใช้ร่วมกันนี้ ที่เก็บข้อมูลที่ใช้ร่วมกันจะต้องเขียนได้โดยแอปพลิเคชันใด ๆ ที่ได้รับอนุญาตนั้น

การใช้งานอุปกรณ์อาจมีฮาร์ดแวร์สำหรับที่เก็บข้อมูลที่สามารถถอดออกได้ซึ่งสามารถเข้าถึงได้เช่นการ์ดดิจิตอลที่ปลอดภัย อีกวิธีหนึ่งการใช้งานอุปกรณ์อาจจัดสรรพื้นที่เก็บข้อมูลภายใน (ไม่สามารถถอดออกได้) เป็นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอพ The upstream Android Open Source Project includes an implementation that uses internal device storage for shared external storage APIs; device implementations SHOULD use this configuration and software implementation.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

มันเป็นตัวอย่างที่จะพิจารณาสองตัวอย่างทั่วไป หากการใช้งานอุปกรณ์มีช่องเสียบการ์ด SD เพื่อตอบสนองความต้องการการจัดเก็บที่ใช้ร่วมกันต้องมีการ์ด SD ที่มีรูปแบบไขมันขนาด 1GB หรือใหญ่กว่าจะต้องรวมอยู่ในอุปกรณ์ที่ขายให้กับผู้ใช้และจะต้องติดตั้งตามค่าเริ่มต้น อีกทางเลือกหนึ่งหากการใช้งานอุปกรณ์ใช้ที่เก็บข้อมูลภายในเพื่อตอบสนองความต้องการนี้การจัดเก็บนั้นจะต้องมีขนาด 1GB หรือใหญ่กว่าและติดตั้งบน /sdcard (หรือ /sdcard จะต้องเป็นลิงค์สัญลักษณ์ไปยังตำแหน่งทางกายภาพหากติดตั้งที่อื่น)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST NOT allow Android applications to write to the secondary external storage, except for their package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

7.7. ยูเอสบี

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Androidare very strongly encouraged to meet these requirements in Android so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases
The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. ความเข้ากันได้ด้านประสิทธิภาพ

Device implementations MUST meet the key performance metrics of an Android- compatible device defined in the table below:

เมตริก	เกณฑ์ประสิทธิภาพ	ความคิดเห็น
Application Launch Time	แอปพลิเคชันต่อไปนี้ควรเปิดตัวภายในเวลาที่กำหนด เบราว์เซอร์: น้อยกว่า 1300ms Contacts: less than 700ms Settings: less than 700ms	เวลาเปิดตัวถูกวัดเป็นเวลาทั้งหมดในการโหลดกิจกรรมเริ่มต้นสำหรับแอปพลิเคชันรวมถึงเวลาที่ใช้ในการเริ่มต้นกระบวนการ Linux โหลดแพ็คเกจ Android ลงใน Dalvik VM และเรียกใช้ onCreate
แอปพลิเคชันพร้อมกัน	เมื่อมีการเปิดตัวแอปพลิเคชันหลายครั้งการเปิดตัวแอปพลิเคชันที่ดำเนินการแล้วหลังจากเปิดตัวจะต้องใช้เวลาน้อยกว่าเวลาเปิดตัวเดิม

9. ความเข้ากันได้ของโมเดลความปลอดภัย

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. การใช้งานอุปกรณ์จะต้องสนับสนุนการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องได้รับอนุญาต/ใบรับรองเพิ่มเติมใด ๆ จากบุคคลที่สาม/หน่วยงานใด ๆ โดยเฉพาะอุปกรณ์ที่เข้ากันได้จะต้องสนับสนุนกลไกความปลอดภัยที่อธิบายไว้ในส่วนย่อยตาม

9.1. สิทธิ์

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. โดยเฉพาะการใช้งานจะต้องบังคับใช้แต่ละการอนุญาตที่กำหนดตามที่อธิบายไว้ในเอกสาร SDK; ไม่อนุญาตให้ใช้สิทธิ์เปลี่ยนแปลงหรือเพิกเฉย การใช้งานอาจเพิ่มสิทธิ์เพิ่มเติมหากสตริง ID สิทธิ์ใหม่ไม่ได้อยู่ใน Android* เนมสเปซ

9.2. UID และการแยกกระบวนการ

การใช้งานอุปกรณ์จะต้องรองรับโมเดลแอปพลิเคชันแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID สไตล์ UNIX ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3. สิทธิ์ของระบบไฟล์

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. สภาพแวดล้อมการดำเนินการสำรอง

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

Runtimes ทางเลือกจะต้องเป็นแอปพลิเคชั่น Android และปฏิบัติตามรูปแบบความปลอดภัยของ Android มาตรฐานตามที่อธิบายไว้ในที่อื่นในส่วนที่ 9

Runtimes ทางเลือกจะต้องไม่ได้รับอนุญาตให้เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยการอนุญาตที่ไม่ได้ร้องขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

Runtimes ทางเลือกจะต้องไม่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากคุณสมบัติที่ได้รับการป้องกันโดยการอนุญาต Android ที่ จำกัด เฉพาะแอปพลิเคชันระบบ

Runtimes สำรองจะต้องปฏิบัติตามโมเดล Android Sandbox โดยเฉพาะ:

Runtimes สำรองควรติดตั้งแอพผ่าน PackageManager ลงในกล่องทราย Android แยกต่างหาก (นั่นคือ ID ผู้ใช้ Linux ฯลฯ )
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Runtimes ทางเลือกและแอพพลิเคชั่นที่ติดตั้งโดยใช้รันไทม์สำรองจะต้องไม่นำ Sandbox ของแอพอื่น ๆ ที่ติดตั้งไว้บนอุปกรณ์ใหม่ยกเว้นกลไก Android มาตรฐานของ ID ผู้ใช้ที่ใช้ร่วมกันและใบรับรองการลงนาม
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

ต้องไม่เปิดใช้งาน Runtimes ทางเลือกหรือให้สิทธิ์แก่แอปพลิเคชันอื่น ๆ ของ Superuser (รูท) หรือรหัสผู้ใช้อื่น ๆ

ไฟล์. APK ของ Runtimes ทางเลือกอาจรวมอยู่ในภาพระบบของการใช้งานอุปกรณ์ แต่ต้องลงนามด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงนามในแอปพลิเคชันอื่น ๆ ที่รวมกับการใช้งานอุปกรณ์

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

9.5. Multi-User Support

Android includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
Android includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage.

9.6. Premium SMS Warning

Android includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Kernel Security Features

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

MUST maintain compatibility with existing applications
MUST not have a visible user interface, even when violations are detected
SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

it MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis with:

domains that are in enforcing mode in the upstream Android Open Source implementation (such as installd, netd, and vold) MUST be in enforcing mode
domain(s) for third-party applications SHOULD remain in permissive mode to ensure continued compatibility

it SHOULD load policy from /sepolicy file on the device
it MUST support dynamic updates of the SELinux policy file without requiring a system image update
it MUST log any policy violations without breaking applications or affecting system behavior

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. ความเป็นส่วนตัว

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9. Full-Disk Encryption

IF the device has lockscreen, the device MUST support full-disk encryption.

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การใช้งานอุปกรณ์จะต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้

อย่างไรก็ตามโปรดทราบว่าไม่มีแพ็คเกจทดสอบซอฟต์แวร์ที่ครอบคลุมอย่างสมบูรณ์ For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. สิ่งนี้จะช่วยลดความเสี่ยงของการแนะนำข้อบกพร่องที่สร้างความไม่ลงรอยกันที่ต้องใช้การปรับปรุงใหม่และการอัปเดตอุปกรณ์ที่มีศักยภาพ

10.1. ชุดทดสอบความเข้ากันได้

การใช้งานอุปกรณ์จะต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) [ ทรัพยากร 2 ] พร้อมใช้งานจากโครงการ Android Open Source โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายบนอุปกรณ์ นอกจากนี้ผู้ใช้อุปกรณ์ควรใช้การใช้งานอ้างอิงในแผนผังโอเพ่นซอร์ส Android ให้มากที่สุดและต้องตรวจสอบให้แน่ใจว่าเข้ากันได้ในกรณีที่มีความคลุมเครือใน CTS และสำหรับการปรับแต่งส่วนหนึ่งของซอร์สโค้ดอ้างอิง

CTS ได้รับการออกแบบให้ทำงานบนอุปกรณ์จริง เช่นเดียวกับซอฟต์แวร์ใด ๆ CTS อาจมีข้อบกพร่อง The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.4. การใช้งานอุปกรณ์จะต้องผ่านเวอร์ชัน CTS ล่าสุดที่มีอยู่ในเวลาที่ซอฟต์แวร์อุปกรณ์เสร็จสมบูรณ์

10.2. เครื่องตรวจสอบ CTS

การใช้งานอุปกรณ์จะต้องดำเนินการอย่างถูกต้องทั้งหมดในกรณีที่เกี่ยวข้องในตัวตรวจสอบ CTS ตัวตรวจสอบ CTS นั้นมาพร้อมกับชุดทดสอบความเข้ากันได้และมีวัตถุประสงค์เพื่อดำเนินการโดยผู้ปฏิบัติงานมนุษย์เพื่อทดสอบฟังก์ชั่นที่ไม่สามารถทดสอบได้โดยระบบอัตโนมัติเช่นการทำงานที่ถูกต้องของกล้องและเซ็นเซอร์

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

ทุกอุปกรณ์และการสร้างทุกครั้งจะต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตามเนื่องจากการสร้างจำนวนมากมีความคล้ายคลึงกันมากผู้ใช้อุปกรณ์จึงไม่คาดว่าจะเรียกใช้ตัวตรวจสอบ CTS อย่างชัดเจนในการสร้างที่แตกต่างกันในรูปแบบที่ไม่สำคัญเท่านั้น Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. แอปพลิเคชันอ้างอิง

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Google Play Store)

แต่ละแอพด้านบนจะต้องเปิดตัวและประพฤติอย่างถูกต้องในการใช้งานเพื่อให้การใช้งานเข้ากันได้

11. ซอฟต์แวร์ที่สามารถอัพเดตได้

การใช้งานอุปกรณ์จะต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

วิธีการใด ๆ สามารถใช้งานได้โดยมีเงื่อนไขว่าสามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าบนอุปกรณ์ ตัวอย่างเช่นวิธีการใด ๆ ต่อไปนี้จะตอบสนองความต้องการนี้:

ดาวน์โหลด over-the-air (OTA) ด้วยการอัปเดตออฟไลน์ผ่านการรีบูต
การอัปเดต "Tethered" ผ่าน USB จากพีซีโฮสต์
การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์ในที่เก็บข้อมูลแบบถอดได้

กลไกการอัปเดตที่ใช้จะต้องรองรับการอัปเดตโดยไม่ต้องเช็ดข้อมูลผู้ใช้ That is, the update mechanism MUST preserve application private data and application shared data. โปรดทราบว่าซอฟต์แวร์ Android ต้นน้ำมีกลไกการอัปเดตที่ตอบสนองความต้องการนี้

หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากที่ได้รับการปล่อยตัว แต่ภายในอายุการใช้งานผลิตภัณฑ์ที่สมเหตุสมผลซึ่งพิจารณาในการปรึกษาหารือกับทีมงานความเข้ากันได้ของ Android เพื่อส่งผลกระทบต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สามผู้ใช้อุปกรณ์จะต้องแก้ไขข้อผิดพลาดผ่านซอฟต์แวร์ การอัปเดตที่สามารถใช้งานได้ตามกลไกที่เพิ่งอธิบายไว้

12. Document Changelog

The following table contains a summary of the changes to the Compatibility Definition in this release.

Section(s)	Summary of change
3.2.2. สร้างพารามิเตอร์	Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now required.
3.2.3.5. Default App Settings	New section that adds requirement to comply with new default application settings
3.3.1 Application Binary Interfaces	Clarified allowed values for the `android.os.Build.CPU_ABI` and `android.os.Build.CPU_ABI2` parameters.
3.4.1. ความเข้ากันได้ของ WebView	Added Chromium as required WebView implementation.
3.7. ความเข้ากันได้ของเครื่องเสมือน	Added requirement for xxhdpi and 400dpi screen densities.
3.8.6. ธีมส์	Updated to reflect use of translucent system bars.
3.8.12. ที่ตั้ง	New section that adds requirement location settings be centralized.
3.8.13. ยูนิโค้ด	New section that adds requirement for emoji support.
3.9. Device Administration	Noted preinstalled administrative applications cannot be the default Device Owner application.
5.1. ตัวแปลงสัญญาณมีเดีย	Added VP9 decoder requirement. Added recommended specification for hardware VP8 codecs.
5.3. Video Decoding	Added VP9. Added recommendation for dynamic resolution switching.
5.4. การบันทึกเสียง	Added `REMOTE_SUBMIX` as new required audio source. Made use of `android.media.audiofx.NoiseSuppressor` API a requirement.
6.2.1 Experimental	New section that introduces the ART runtime and requires Dalvik as the default runtime.
7.1.1. Screen Configuration	Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.
7.1.6. Screen Types	Added 640 dpi (4K) resolution configuration.
7.2.3. ปุ่มนำทาง	Added Recents function as essential; demoted Menu function in priority.
7.3.6. เทอร์โมมิเตอร์	Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.
7.4.2.2. Wi-Fi Tunneled Direct Link Setup	New section that adds support for Wi-Fi Tunneled Direct Link Setup (TDLS).
7.4.4. การสื่อสารระยะใกล้	Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push Profile as a requirement.
7.4.6. Sync Settings	New section that adds requirement auto-sync data be enabled by default.
7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ	Added `ActivityManager.isLowRamDevice()` setting requirement for devices with less than 512MB of memory. Increased storage requirements from 512MB and 1GB to 1GB and 2GB, respectively.
7.6.2. Shared "External" Storage	Editorial fixes such as change of section name, and moved text that fits in this section from section 9.5. Noted applications may write to their package-specific directories on secondary external storage.
7.7. ยูเอสบี	Added requirement all devices report a USB serial number.
9.5. Multi-User Support	Moved non multi-user specific text to section 7.6.2.
9.7. Kernel Security Features	Rewritten to note switch of SELinux to enforcing mode and requirement SELinux output not be rendered in the user interface.
9.8. ความเป็นส่วนตัว	New section that adds requirement audio and video recording must trigger continuous notifications to the user.
9.9. Full-Disk Encryption	New section that adds requirement devices with lockscreen support full-disk encryption.
12. Document Changelog	New section that summarizes changes in the CDD by section.

13. Contact Us

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