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

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

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

ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ใน ส่วนที่ 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.3: http://source.android.com/docs/compatibility/4.3/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/webdatabase/

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/security.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

Wifi Multicast 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

Wifi โดยตรง (Wifi 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

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

3. ซอฟต์แวร์

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

สภาพแวดล้อมการดำเนินการที่ได้รับการจัดการ (ตาม Dalvik) เป็นเครื่องมือหลักสำหรับแอปพลิเคชัน Android Android Application Programming Interface (API) คือชุดของอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อม VM ที่มีการจัดการ การใช้งานอุปกรณ์ต้องจัดให้มีการใช้งานที่สมบูรณ์ รวมถึงพฤติกรรมที่บันทึกไว้ทั้งหมดของ API ที่ได้รับการบันทึกไว้ซึ่งเปิดเผยโดย Android 4.3 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.os.Build.VERSION.RELEASE	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่มนุษย์สามารถอ่านได้ ฟิลด์นี้ต้องมีค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ใน [ ทรัพยากร, 7 ]
android.os.Build.VERSION.SDK	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่เข้าถึงได้โดยรหัสแอปพลิเคชันบุคคลที่สาม สำหรับ Android 4.3 ฟิลด์นี้ต้องมีค่าจำนวนเต็ม 18
android.os.Build.VERSION.SDK_INT	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบัน ในรูปแบบที่เข้าถึงได้โดยรหัสแอปพลิเคชันบุคคลที่สาม สำหรับ Android 4.3 ฟิลด์นี้ต้องมีค่าจำนวนเต็ม 18
android.os.Build.VERSION.INCREMENTAL	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งกำหนดโครงสร้างเฉพาะของระบบ Android ที่กำลังดำเนินการอยู่ ในรูปแบบที่มนุษย์สามารถอ่านได้ จะต้องไม่ใช้ค่านี้ซ้ำสำหรับบิลด์อื่นที่ผู้ใช้ปลายทางสามารถใช้ได้ การใช้งานทั่วไปของฟิลด์นี้คือเพื่อระบุว่าหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาใดที่ใช้ในการสร้างบิลด์ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.BOARD	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในเฉพาะที่อุปกรณ์ใช้ ในรูปแบบที่มนุษย์สามารถอ่านได้ การใช้ฟิลด์นี้ที่เป็นไปได้คือเพื่อระบุการแก้ไขเฉพาะของบอร์ดที่จ่ายไฟให้กับอุปกรณ์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.BRAND	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุชื่อของบริษัท องค์กร บุคคล ฯลฯ ที่ผลิตอุปกรณ์ ในรูปแบบที่มนุษย์สามารถอ่านได้ การใช้ฟิลด์นี้ที่เป็นไปได้คือเพื่อระบุ OEM และ/หรือผู้ให้บริการที่ขายอุปกรณ์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.CPU_ABI	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดเนทีฟ ดู ส่วนที่ 3.3: ความเข้ากันได้ของ Native API
android.os.Build.CPU_ABI2	ชื่อของชุดคำสั่งที่สอง (ประเภท CPU + แบบแผน ABI) ของโค้ดเนทีฟ ดู ส่วนที่ 3.3: ความเข้ากันได้ของ Native API
android.os.Build.DEVICE	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุการกำหนดค่าหรือการแก้ไขเฉพาะของอุปกรณ์ (บางครั้งเรียกว่า "การออกแบบทางอุตสาหกรรม") ของอุปกรณ์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.ลายนิ้วมือ	สตริงที่ระบุโครงสร้างนี้โดยไม่ซ้ำกัน มันควรจะสามารถอ่านได้โดยมนุษย์พอสมควร ต้องเป็นไปตามเทมเพลตนี้: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` ตัวอย่างเช่น: `acme/mydevice/generic:4.3/JRN53/3359:userdebug/test-keys` ลายนิ้วมือต้องไม่มีอักขระช่องว่าง หากฟิลด์อื่นที่รวมอยู่ในเทมเพลตด้านบนมีอักขระช่องว่าง จะต้องแทนที่ฟิลด์เหล่านั้นในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต
android.os.Build.ฮาร์ดแวร์	ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งเคอร์เนลหรือ /proc) มันควรจะสามารถอ่านได้โดยมนุษย์พอสมควร ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.HOST	สตริงที่ระบุโฮสต์โดยไม่ซ้ำกันที่ build สร้างขึ้น ในรูปแบบที่มนุษย์สามารถอ่านได้ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.ID	ตัวระบุที่ผู้ใช้อุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นเฉพาะ ในรูปแบบที่มนุษย์สามารถอ่านได้ ช่องนี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL ได้ แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกแยะระหว่างรุ่นซอฟต์แวร์ ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.ผู้ผลิต	ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.MODEL	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางรู้จัก นี่ควรเป็นชื่อเดียวกับที่ใช้วางตลาดและจำหน่ายอุปกรณ์ให้กับผู้ใช้ปลายทาง ไม่มีข้อกำหนดในรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.PRODUCT	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ (SKU) ต้องให้มนุษย์สามารถอ่านได้ แต่ไม่จำเป็นว่าจะต้องมีจุดประสงค์ให้ผู้ใช้ปลายทางดู ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.SERIAL	หมายเลขซีเรียลของฮาร์ดแวร์ หากมี ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป `"^([a-zA-Z0-9]{0,20})$"`
android.os.Build.TAGS	รายการแท็กที่คั่นด้วยเครื่องหมายจุลภาคซึ่งเลือกโดยผู้ใช้อุปกรณ์ ซึ่งจะทำให้โครงสร้างแตกต่างออกไปอีก ตัวอย่างเช่น "ไม่ได้ลงนาม, ดีบัก" ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.TIME	ค่าที่แสดงถึงการประทับเวลาเมื่อมีการสร้างเกิดขึ้น
android.os.Build.TYPE	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ฟิลด์นี้ควรมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android สามค่า: "user", "userdebug" หรือ "eng" ค่าของฟิลด์นี้จะต้องเข้ารหัสเป็น ASCII 7 บิต และตรงกับนิพจน์ทั่วไป `"^[a-zA-Z0-9.,_-]+$"`
android.os.Build.USER	ชื่อหรือ 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.2 ถูกแทนที่โดยแอปพลิเคชันบุคคลที่สาม การใช้งานโอเพนซอร์สอัปสตรีม 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.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
ต้องรายงานเฉพาะ ABI ที่ได้รับการบันทึกไว้ใน Android NDK เวอร์ชันล่าสุดในไฟล์ docs/CPU-ARCH-ABIS.txt
ควรสร้างขึ้นโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในอัปสตรีม 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 ใช้เครื่องมือการเรนเดอร์ WebKit เพื่อใช้งาน android.webkit.WebView [ Resources, 10 ] เนื่องจากเป็นไปไม่ได้ที่จะพัฒนาชุดทดสอบที่ครอบคลุมสำหรับระบบการเรนเดอร์เว็บ ผู้ใช้งานอุปกรณ์จึงต้องใช้อัพสตรีมบิวด์เฉพาะของ WebKit ในการใช้งาน WebView โดยเฉพาะ:

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

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

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

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

HTML5 API เช่นเดียวกับ JavaScript API ทั้งหมด จะต้องปิดใช้งานตามค่าเริ่มต้นใน WebView เว้นแต่นักพัฒนาจะเปิดใช้งานอย่างชัดเจนผ่าน Android API ปกติ

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

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

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

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

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

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
xlarge	mdpi	32MB
xlarge	ทีวีดีพีไอ/เอชดีพีไอ	64MB
xlarge	xhdpi	128MB

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

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

Android 4.3 มีแอปพลิเคชันตัวเรียกใช้งาน (หน้าจอหลัก) และการสนับสนุนแอปพลิเคชันบุคคลที่สามเพื่อแทนที่ตัวเรียกใช้อุปกรณ์ (หน้าจอหลัก) การใช้งานอุปกรณ์ที่อนุญาตให้แอปพลิเคชันบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์จะต้องประกาศคุณลักษณะแพลตฟอร์ม 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 4.3 มีการรองรับการแจ้งเตือนที่หลากหลาย เช่น 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 4.3 มีธีม "Holo" หรือ "โฮโลแกรม" เป็นชุดรูปแบบที่กำหนดไว้สำหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีม Holo ตามที่กำหนดโดย Android SDK [ แหล่งข้อมูล, 24 ] การใช้งานอุปกรณ์จะต้องไม่เปลี่ยนแปลงคุณลักษณะธีม Holo ใด ๆ ที่เปิดเผยต่อแอปพลิเคชัน [ แหล่งข้อมูล, 25 ]

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11. ความฝัน

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

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

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

3.10 การเข้าถึง

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

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

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

3.11 การอ่านออกเสียงข้อความ

Android 4.3 มี 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)
	วีพี8	ที่จำเป็น (แอนดรอยด์ 4.3 ขึ้นไป)	ที่จำเป็น (แอนดรอยด์ 2.3.3+)		WebM (.webm) และ Matroska (.mkv, Android 4.0+)***

*หมายเหตุ: ต้องใช้ดาวน์มิกซ์เนื้อหา 5.0/5.1 เท่านั้น การบันทึกหรือการเรนเดอร์มากกว่า 2 ช่องเป็นทางเลือก
**หมายเหตุ: จำเป็นต้องมีการจับ PCM เชิงเส้น 16 บิต ไม่จำเป็นต้องมีการจับ PCM เชิงเส้น 8 บิต
***หมายเหตุ: การใช้งานอุปกรณ์ควรรองรับการเขียนไฟล์ Matroska WebM

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 และ 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.3 แต่คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตได้รับการวางแผนให้เปลี่ยนข้อกำหนดเหล่านี้เป็น "ต้อง" นั่นคือข้อกำหนดเหล่านี้เป็นทางเลือกใน Android 4.3 แต่ จะต้องมี ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.3 ได้ รับการสนับสนุนอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเหล่านี้ใน Android 4.3 มิฉะนั้นจะไม่สามารถรองรับความเข้ากันได้ของ Android เมื่ออัปเกรดเป็นเวอร์ชันอนาคต

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

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

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

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

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

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

หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้หลังจากการสอบเทียบเริ่มต้นใดๆ เมื่อใช้ API คิวบัฟเฟอร์ OpenSL ES PCM สำหรับเวลาแฝงเอาต์พุตอย่างต่อเนื่องและเวลาแฝงเอาต์พุตเย็นผ่านอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อยหนึ่งเครื่อง อาจรายงานการสนับสนุนสำหรับเสียงที่มีเวลาแฝงต่ำ โดยการรายงานคุณลักษณะ "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 Bridge
Android 4.3 รองรับ adb ที่ปลอดภัย Secure adb เปิดใช้งาน adb บนโฮสต์ที่ได้รับการรับรองความถูกต้องที่รู้จัก การใช้งานอุปกรณ์ต้องรองรับ adb ที่ปลอดภัย
บริการตรวจสอบข้อบกพร่อง Dalvik (เรียกว่า 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 4.3 มีการสนับสนุนสำหรับนักพัฒนาในการกำหนดค่าการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอุปกรณ์ต้องเป็นไปตามเจตนารมณ์ของ android.settings.APPLICATION_DEVELOPMENT_SETTINGS ที่จะแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน [ ทรัพยากร, 77 ] การใช้งานอัปสตรีม Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาตามค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาได้หลังจากกดเจ็ด (7) ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์ การใช้งานอุปกรณ์จะต้องมอบประสบการณ์ที่สอดคล้องกันสำหรับตัวเลือกของนักพัฒนา โดยเฉพาะ การใช้งานอุปกรณ์จะต้องซ่อนตัวเลือกของนักพัฒนาตามค่าเริ่มต้น และต้องมีกลไกในการเปิดใช้งานตัวเลือกของนักพัฒนาที่สอดคล้องกับการใช้งาน Android อัปสตรีม

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

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

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

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

ขนาดหน้าจอ

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

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

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

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

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

อัตราส่วนภาพของหน้าจอ

อัตราส่วนภาพต้องอยู่ระหว่าง 1.3333 (4:3) ถึง 1.85 (16:9)

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

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

120 dpi หรือที่เรียกว่า 'ldpi'
160 dpi หรือที่เรียกว่า 'mdpi'
213 dpi หรือที่เรียกว่า 'tvdpi'
240 dpi หรือที่เรียกว่า 'hdpi'
320 dpi หรือที่เรียกว่า 'xhdpi'
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 4.3 มีการสนับสนุนแอปพลิเคชันเพื่อระบุว่าพวกเขาต้องการรูปแบบการบีบอัดพื้นผิว OpenGL เฉพาะ โดยทั่วไปรูปแบบเหล่านี้จะเฉพาะผู้ขาย การใช้งานอุปกรณ์ไม่จำเป็นต้องใช้โดย Android 4.3 เพื่อใช้รูปแบบการบีบอัดพื้นผิวที่เฉพาะเจาะจง อย่างไรก็ตามพวกเขาควรรายงานรูปแบบการบีบอัดพื้นผิวใด ๆ ที่พวกเขาสนับสนุนผ่านวิธี getString() ใน OpenGL API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android 4.3 รวมถึงการรองรับการแสดงผลรองเพื่อเปิดใช้งานความสามารถในการแบ่งปันสื่อและ 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
ต้องจัดเตรียมการใช้แป้นพิมพ์แบบนุ่มอย่างน้อยหนึ่งครั้ง (ไม่ว่าจะมีแป้นพิมพ์แข็งอยู่) หรือไม่)
อาจรวมถึงการใช้งานคีย์บอร์ด Soft เพิ่มเติม
อาจรวมถึงคีย์บอร์ดฮาร์ดแวร์
ต้องไม่รวมแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุใน android.content.res.Configuration.keyboard [ ทรัพยากร, 40 ] (นั่นคือ qwerty หรือ 12-key)

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

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

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

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

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

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

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

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

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

Android 4.3 รวมถึงการรองรับหน้าจอสัมผัสที่หลากหลายทัชแพดและอุปกรณ์อินพุตสัมผัสปลอม การใช้งานอุปกรณ์บนหน้าจอสัมผัสนั้นเชื่อมโยงกับการแสดงผล [ ทรัพยากร, 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 4.3 มี APIs สำหรับการเข้าถึงประเภทเซ็นเซอร์ที่หลากหลาย การใช้งานอุปกรณ์โดยทั่วไปอาจละเว้นเซ็นเซอร์เหล่านี้ตามที่ระบุไว้ในส่วนย่อยต่อไปนี้ หากอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาบุคคลที่สามการใช้งานอุปกรณ์จะต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสาร Android SDK ตัวอย่างเช่นการใช้งานอุปกรณ์:

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

รายการด้านบนไม่ครอบคลุม พฤติกรรมที่บันทึกไว้ของ Android SDK จะได้รับการพิจารณาอย่างเป็นทางการ

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

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

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

การใช้งานอุปกรณ์ควรมีเครื่องเร่งความเร็ว 3 แกน หากการใช้งานอุปกรณ์รวมถึงตัวเร่งความเร็ว 3 แกนให้:

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

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

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

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

7.3.3. จีพีเอส

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

7.3.4. ไจโรสโคป

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

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

การใช้งานอุปกรณ์อาจ แต่ไม่ควรรวมเทอร์โมมิเตอร์ (เช่นเซ็นเซอร์อุณหภูมิ) หากการใช้งานอุปกรณ์มีเทอร์โมมิเตอร์จะต้องวัดอุณหภูมิของอุปกรณ์ CPU จะต้องไม่วัดอุณหภูมิอื่น ๆ (โปรดทราบว่าประเภทเซ็นเซอร์นี้เลิกใช้ใน Android 4.3 APIs)

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

การใช้งานอุปกรณ์อาจรวมถึงเครื่องวัดแสง (เช่นเซ็นเซอร์แสงโดยรอบ)

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

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

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

7.4.1. โทรศัพท์

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

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

7.4.2. IEEE 802.11 (อินเตอร์เน็ตไร้สาย)

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

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

7.4.2.1. wifi โดยตรง

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

ต้องสนับสนุนการทำงานของ WiFi ปกติ
ควรสนับสนุนการดำเนินงานโดยตรง WiFi และ WiFi ที่เกิดขึ้นพร้อมกัน

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. การสื่อสารระยะใกล้

การใช้งานอุปกรณ์ควรรวมถึงตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับการสื่อสารใกล้สนาม (NFC) หากการใช้งานอุปกรณ์รวมถึงฮาร์ดแวร์ NFC ให้:

ต้องรายงานคุณสมบัติ Android.hardware.nfc จาก android.content.pm.PackageManager.hasSystemFeature() [ ทรัพยากร, 37 ]
ต้องมีความสามารถในการอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้:
- จะต้องมีความสามารถในการทำหน้าที่เป็นตัวอ่าน/นักเขียนฟอรัม NFC (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของฟอรัม NFC NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - ISODEP (ISO 14443-4)
  - แท็กฟอรัม NFC ประเภท 1, 2, 3, 4 (กำหนดโดยฟอรัม NFC)
ควรมีความสามารถในการอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าในขณะที่มาตรฐาน NFC ด้านล่างนี้ระบุว่า "ควร" สำหรับ Android 4.3 คำจำกัดความความเข้ากันได้สำหรับรุ่นในอนาคตมีการวางแผนที่จะเปลี่ยนสิ่งเหล่านี้เป็น "ต้อง" นั่นคือมาตรฐานเหล่านี้เป็นทางเลือกใน Android 4.3 แต่ จะต้องใช้ ในเวอร์ชันอนาคต อุปกรณ์ที่มีอยู่และใหม่ที่ใช้ Android 4.3 ได้ รับการสนับสนุนอย่างมากเพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ใน Android 4.3 ดังนั้นพวกเขาจะสามารถอัพเกรดเป็นแพลตฟอร์มในอนาคตได้
- NFCV (ISO 15693)
จะต้องมีความสามารถในการส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบเพียร์ทูเพียร์ต่อไปนี้:
- ISO 18092
- LLCP 1.0 (กำหนดโดยฟอรัม NFC)
- SDP 1.0 (กำหนดโดยฟอรัม NFC)
- NDEF Push Protocol [ ทรัพยากร, 43 ]
- SNEP 1.0 (กำหนดโดยฟอรัม NFC)
ต้องมีการสนับสนุนสำหรับลำแสง Android [ ทรัพยากร, 65 ]:
- ต้องใช้เซิร์ฟเวอร์เริ่มต้น SNEP ข้อความ NDEF ที่ถูกต้องที่ได้รับจากเซิร์ฟเวอร์ SNEP เริ่มต้นจะต้องถูกส่งไปยังแอปพลิเคชันโดยใช้ Android.nfc.action_ndef_discovered เจตนา การปิดใช้งานลำแสง Android ในการตั้งค่าจะต้องไม่ปิดใช้งานการส่งข้อความ NDEF ที่เข้ามา
- การใช้งานอุปกรณ์จะต้องให้เกียรติ Android.settings.nfcsharing_settings ตั้งใจที่จะแสดงการตั้งค่าการแบ่งปัน NFC [ ทรัพยากร, 67 ]
- ต้องใช้เซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP จะต้องประมวลผลเช่นเดียวกับเซิร์ฟเวอร์เริ่มต้น SNEP
- ต้องใช้ไคลเอนต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้งานลำแสง Android หากไม่พบเซิร์ฟเวอร์ SNEP เริ่มต้นไคลเอนต์จะต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
- ต้องอนุญาตให้กิจกรรมเบื้องหน้าตั้งค่าข้อความ P2P NDEF ขาออกโดยใช้ Android.nfc.nfcadapter.setndefpushMessage และ Android.nfc.nfcadapter.setndefpushmessageCallback และ Android.nfcadapter
- ควรใช้ท่าทางหรือการยืนยันบนหน้าจอเช่น 'Touch to Beam' ก่อนที่จะส่งข้อความ P2P NDEF ขาออก
- ควรเปิดใช้งานลำแสง Android โดยค่าเริ่มต้น
- ต้องรองรับการส่งมอบการเชื่อมต่อ NFC ไปยังบลูทู ธ เมื่ออุปกรณ์รองรับโปรไฟล์การกดวัตถุบลูทู ธ การใช้งานอุปกรณ์จะต้องรองรับการเชื่อมต่อการเชื่อมต่อไปยังบลูทู ธ เมื่อใช้ Android.nfc.nfcadapter.setBeampushuris โดยใช้ "การเชื่อมต่อการส่งมอบเวอร์ชัน 1.2" [ ทรัพยากร 60 ] และ "การจับคู่อย่างง่ายของบลูทู ธ โดยใช้ NFC เวอร์ชัน 1.0" [ ทรัพยากร 61 ] ฟอรัม NFC การใช้งานดังกล่าวควรใช้การร้องขอ SNEP Get สำหรับการแลกเปลี่ยนคำขอส่งมอบ / เลือกบันทึกผ่าน NFC และจะต้องใช้โปรไฟล์การกดวัตถุบลูทู ธ สำหรับการถ่ายโอนข้อมูลบลูทู ธ จริง
ต้องสำรวจความคิดเห็นสำหรับเทคโนโลยีที่ได้รับการสนับสนุนทั้งหมดในขณะที่อยู่ในโหมดการค้นพบของ NFC
ควรอยู่ในโหมด NFC Discovery ในขณะที่อุปกรณ์ตื่นขึ้นมาพร้อมกับหน้าจอที่ใช้งานอยู่และปลดล็อคหน้าจอล็อค

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

นอกจากนี้การใช้งานอุปกรณ์อาจรวมถึงการสนับสนุนผู้อ่าน/นักเขียนสำหรับเทคโนโลยี Mifare ต่อไปนี้

Mifare Classic (NXP MF1S503X [ ทรัพยากร, 44 ], MF1S703X [ ทรัพยากร, 45 ])
Mifare Ultralight (NXP MF0ICU1 [ ทรัพยากร, 46 ], MF0ICU2 [ ทรัพยากร, 47 ])
NDEF บน Mifare Classic (NXP AN130511 [ ทรัพยากร, 48 ], AN130411 [ ทรัพยากร, 49 ])

โปรดทราบว่า Android 4.3 มี APIs สำหรับประเภท mifare เหล่านี้ หากการใช้งานอุปกรณ์รองรับ mifare ในบทบาทผู้อ่าน/นักเขียนมัน:

ต้องใช้ Android API ที่สอดคล้องกันตามที่บันทึกไว้โดย Android SDK
ต้องรายงานคุณสมบัติ com.nxp.mifare จากวิธี android.content.pm.PackageManager.hasSystemFeature() [ ทรัพยากร, 37 ] โปรดทราบว่านี่ไม่ใช่คุณสมบัติ Android มาตรฐานและเช่นนี้จะไม่ปรากฏเป็นค่าคงที่ในคลาส PackageManager
จะต้องไม่ใช้แอนดรอยด์ APIs ที่เกี่ยวข้องหรือรายงานคุณสมบัติ com.nxp.mifare เว้นแต่จะใช้การสนับสนุน NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้

หากการใช้งานอุปกรณ์ไม่รวมฮาร์ดแวร์ NFC จะต้องไม่ประกาศคุณลักษณะ Android.hardware.nfc จาก android.content.pm.PackageManager.hasSystemFeature() วิธี [ ทรัพยากร, 37 ] และต้องใช้ Android 4.3 NFC API AS ไม่มี

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

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

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

การใช้งานอุปกรณ์ที่มาตรฐานเครือข่ายทางกายภาพ (เช่นอีเธอร์เน็ต) คือการเชื่อมต่อข้อมูลหลักควรรวมถึงการสนับสนุนอย่างน้อยหนึ่งมาตรฐานข้อมูลไร้สายทั่วไปเช่น 802.11 (WiFi)

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

7.5. กล้อง

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

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

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

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

7.5.2. กล้องหน้า

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

ต้องมีความละเอียดอย่างน้อย VGA (นั่นคือ 640x480 พิกเซล)
ต้องไม่ใช้กล้องหน้าหน้าเป็นค่าเริ่มต้นสำหรับกล้อง API นั่นคือกล้อง API ใน Android 4.3 มีการรองรับเฉพาะสำหรับกล้องด้านหน้าและการใช้งานอุปกรณ์จะต้องไม่กำหนดค่า API เพื่อรักษากล้องหน้าหันหน้าเป็นกล้องด้านหลังเริ่มต้นแม้ว่าจะเป็นกล้องตัวเดียวเท่านั้น อุปกรณ์.
อาจรวมถึงคุณสมบัติ (เช่นโฟกัสอัตโนมัติ, แฟลช ฯลฯ ) ที่มีให้กับกล้องหันหน้าไปทางด้านหลังตามที่อธิบายไว้ในหัวข้อ 7.5.1
ต้องไตร่ตรองในแนวนอน (เช่นมิเรอร์) สตรีมที่แสดงโดยแอพใน camerapreview ดังต่อไปนี้:

หากการใช้งานอุปกรณ์มีความสามารถในการหมุนโดยผู้ใช้ (เช่นโดยอัตโนมัติผ่านตัวเร่งความเร็วหรือด้วยตนเองผ่านการป้อนข้อมูลของผู้ใช้) ตัวอย่างกล้องจะต้องทำมิเรอร์ในแนวนอนเมื่อเทียบกับการวางแนวปัจจุบันของอุปกรณ์
หากแอปพลิเคชันปัจจุบันได้ร้องขออย่างชัดเจนว่าการแสดงของกล้องจะหมุนผ่านการโทรไปยัง android.hardware.Camera.setDisplayOrientation() [ ทรัพยากร, 50 ] วิธีการดูตัวอย่างกล้องจะต้องทำมิเรอร์ในแนวนอนเมื่อเทียบกับทิศทางที่ระบุโดยแอปพลิเคชัน
มิฉะนั้นจะต้องดูตัวอย่างตามแนวแกนแนวนอนเริ่มต้นของอุปกรณ์

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

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

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

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

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

การใช้งานอุปกรณ์จะต้องรับรู้และให้เกียรติแต่ละชื่อพารามิเตอร์ที่กำหนดเป็นค่าคงที่บนคลาส android.hardware.Camera.Parameters หากฮาร์ดแวร์พื้นฐานรองรับคุณสมบัติ หากฮาร์ดแวร์อุปกรณ์ไม่รองรับคุณสมบัติ API จะต้องทำงานตามที่บันทึกไว้ Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. 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. การวางแนวกล้อง

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

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 MUST have at least 512MB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 512MB. Device implementations that run Android 4.3 are very strongly encouraged to have at least 1GB 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. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

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

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

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

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.

เป็นการแสดงให้เห็นเป็นตัวอย่างในการพิจารณาตัวอย่างทั่วไปสองตัวอย่าง If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

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 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 4.3 are very strongly encouraged to meet these requirements in Android 4.3 so they will be able to upgrade to the future platform releases

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 4.3 compatible device defined in the table below:

เมตริก	Performance Threshold	ความคิดเห็น
Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

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 และการแยกกระบวนการ

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 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. สภาพแวดล้อมการดำเนินการสำรอง

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. โดยเฉพาะ:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9.5. Multi-User Support

Android 4.3 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 4.3 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. The upstream Android Open Source Project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage.

9.6. Premium SMS Warning

Android 4.3 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 in Android 4.3 includes features that can use the SELinux mandatory access control system (MAC) and other security features in the Linux kernel. Device implementations MUST support SELinux MAC. Note that the upstream Android Open Source Project provides an implementation that satisfies this requirement.

SELinux or any security features implemented below the Android framework MUST maintain compatibility with existing applications. These features SHOULD be invisible to users and developers. These features 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. To ensure continued compatibility the reference implementation allows the use of SELinux in a permissive mode and supports dynamic policy updates without requiring a system image update. Device implementations using SELinux MUST support this permissive mode, support dynamic policy updates and log any policy violations without breaking applications or affecting system behavior. Implementations using SELinux SHOULD load policy from /sepolicy file on the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement. Device implementations SHOULD use the reference implementation in the Android Open Source Project, and device implementations MUST be compatible with the upstream Android Open Source Project.

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

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. 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 4.3 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

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

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. นอกจากนี้ ผู้ใช้อุปกรณ์ควรใช้การใช้งานอ้างอิงในแผนผัง Android Open Source ให้มากที่สุดเท่าที่จะเป็นไปได้ และต้องรับรองความเข้ากันได้ในกรณีที่มีความคลุมเครือใน 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.3. การใช้งานอุปกรณ์จะต้องผ่านเวอร์ชัน CTS ล่าสุดที่มีอยู่ในเวลาที่ซอฟต์แวร์อุปกรณ์เสร็จสมบูรณ์

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

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. 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. ซอฟต์แวร์ที่สามารถอัพเดตได้

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

สามารถใช้วิธีการใดก็ได้ โดยมีเงื่อนไขว่าสามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าบนอุปกรณ์ได้ For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. โปรดทราบว่าซอฟต์แวร์อัปสตรีม Android มีกลไกการอัปเดตที่ตรงตามข้อกำหนดนี้

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software มีการอัปเดตที่สามารถนำมาใช้ตามกลไกที่อธิบายไว้

12. ติดต่อเรา

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.