เอกสารนิยามความเข้ากันได้ของ Android 4.0

การแก้ไข 4
อัปเดตล่าสุด: 21 เมษายน 2013

ลิขสิทธิ์ © 2012, Google Inc. สงวนลิขสิทธิ์
[email protected]

สารบัญ

1. บทนำ
2. แหล่งข้อมูล
3. ซอฟต์แวร์
3.1. ความเข้ากันได้ของ Managed API
3.2. ความเข้ากันได้แบบ Soft API
3.3. ความเข้ากันได้ของ Native API
3.4. ความเข้ากันได้ของเว็บ
3.5. ความเข้ากันได้ของลักษณะการทํางานของ API
3.6. เนมสเปซของ API
3.7. ความเข้ากันได้ของเครื่องเสมือน
3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.9 การดูแลระบบอุปกรณ์
3.10 การช่วยเหลือพิเศษ
3.11 การอ่านออกเสียงข้อความ
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
5. ความเข้ากันได้ของมัลติมีเดีย
6. ความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
7. ความเข้ากันได้ของฮาร์ดแวร์
7.1. การแสดงผลและกราฟิก
7.2. อุปกรณ์อินพุต
7.3. เซ็นเซอร์
7.4. การเชื่อมต่อข้อมูล
7.5. กล้อง
7.6. หน่วยความจำและพื้นที่เก็บข้อมูล
7.7. USB
8. ความเข้ากันได้ด้านประสิทธิภาพ
9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
11. ซอฟต์แวร์ที่อัปเดตได้
12. ติดต่อเรา
ภาคผนวก ก - ขั้นตอนการทดสอบบลูทูธ

1. ข้อมูลเบื้องต้น

เอกสารนี้จะระบุข้อกำหนดที่อุปกรณ์ต้องเป็นไปตามข้อกำหนดเพื่อให้ใช้งานร่วมกับ Android 4.0 ได้

การใช้คําว่า "ต้อง" "ต้องไม่" "ต้อง" "ต้องไม่" "ควร" "ไม่ควร" "แนะนํา" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119 [แหล่งข้อมูล, 1]

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

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

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

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

2. แหล่งข้อมูล

  1. ระดับข้อกําหนด IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. ภาพรวมโปรแกรมความเข้ากันได้กับ Android: http://source.android.com/docs/compatibility/index.html
  3. โครงการโอเพนซอร์ส Android: http://source.android.com/
  4. คําจํากัดความและเอกสารประกอบของ API: http://developer.android.com/reference/packages.html
  5. ข้อมูลอ้างอิงเกี่ยวกับสิทธิ์ของ Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. ข้อมูลอ้างอิงสำหรับ android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. สตริงเวอร์ชันที่อนุญาตของ Android 4.0: http://source.android.com/docs/compatibility/4.0/versions.html
  8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
  9. การเร่งด้วยฮาร์ดแวร์: http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. คลาส android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. ความสามารถออฟไลน์ของ HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
  13. แท็กวิดีโอ HTML5: http://dev.w3.org/html5/spec/Overview.html#video
  14. API ตําแหน่งทางภูมิศาสตร์ HTML5/W3C: http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
  17. ข้อกำหนดของเครื่องเสมือน Dalvik: มีอยู่ในซอร์สโค้ด Android ที่ dalvik/docs
  18. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. การแจ้งเตือน: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. แหล่งข้อมูลแอปพลิเคชัน: http://code.google.com/android/reference/available-resources.html
  21. คู่มือสไตล์ไอคอนแถบสถานะ: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  22. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  23. ข้อความแจ้ง: http://developer.android.com/reference/android/widget/Toast.html
  24. ธีม: http://developer.android.com/guide/topics/ui/themes.html
  25. คลาส R.style: http://developer.android.com/reference/android/R.style.html
  26. วอลเปเปอร์ภาพเคลื่อนไหว: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. การดูแลจัดการอุปกรณ์ Android: http://developer.android.com/guide/topics/admin/device-admin.html
  28. คลาส android.app.admin.DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. API บริการการช่วยเหลือพิเศษของ Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android Accessibility API: http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. โปรเจ็กต์ Eyes Free: http://code.google.com/p/eyes-free
  32. Text-To-Speech API: http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. เอกสารประกอบของเครื่องมืออ้างอิง (สำหรับ adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  34. คําอธิบายไฟล์ APK ของ Android: http://developer.android.com/guide/topics/fundamentals.html
  35. ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. เครื่องมือทดสอบ Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  37. คลาส android.content.pm.PackageManager ของ Android และรายการฟีเจอร์ของฮาร์ดแวร์: http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. การรองรับหน้าจอหลายหน้าจอ: http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. โปรโตคอล Push ของ NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  50. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  52. อุปกรณ์เสริมแบบเปิดของ Android: http://developer.android.com/guide/topics/usb/accessory.html
  53. USB Host API: http://developer.android.com/guide/topics/usb/host.html
  54. ข้อมูลอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์ของ Android: http://developer.android.com/guide/topics/security/security.html
  55. แอปสําหรับ Android: http://code.google.com/p/apps-for-android
  56. คลาส android.app.DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android File Transfer: http://www.android.com/filetransfer
  58. รูปแบบสื่อของ Android: http://developer.android.com/guide/appendix/media-formats.html
  59. โปรโตคอลฉบับร่างของ HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html
  61. การกําหนดค่าอินพุตแบบสัมผัส: http://source.android.com/tech/input/touch-devices.html

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

3. ซอฟต์แวร์

3.1 ความเข้ากันได้ของ Managed API

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

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

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

3.2 ความเข้ากันได้แบบ Soft API

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

3.2.1. สิทธิ์

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

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

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

พารามิเตอร์ ความคิดเห็น
android.os.Build.VERSION.RELEASE เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงอย่างใดอย่างหนึ่งที่ระบุไว้ใน [ทรัพยากร, 7]
android.os.Build.VERSION.SDK เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 4.0.1 - 4.0.2 ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 14 สำหรับ Android 4.0.3 ขึ้นไป ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 15
android.os.Build.VERSION.SDK_INT เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 4.0.1 - 4.0.2 ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 14 สำหรับ Android 4.0.3 ขึ้นไป ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 15
android.os.Build.VERSION.INCREMENTAL ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ค่านี้ต้องไม่นําไปใช้ซ้ำกับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("")
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 ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3: ความเข้ากันได้ของ Native API
android.os.Build.DEVICE ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุการกำหนดค่าหรือการแก้ไขที่เฉพาะเจาะจงของบอดี้ (บางครั้งเรียกว่า "การออกแบบอุตสาหกรรม") ของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
android.os.Build.FINGERPRINT สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
ตัวอย่างเช่น
acme/mydevice/generic:4.0/IRK77/3359:userdebug/test-keys
ฟิงเกอร์ปรินต์ต้องไม่มีอักขระที่เป็นช่องว่าง หากฟิลด์อื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมีอักขระที่เป็นช่องว่าง คุณต้องแทนที่อักขระเหล่านั้นในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้
android.os.Build.HARDWARE ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งเคอร์เนลหรือ /proc) ควรเป็นชื่อที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
android.os.Build.HOST สตริงที่ระบุโฮสต์ที่ใช้สร้างบิลด์ที่ไม่ซ้ำกันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจง ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("")
android.os.Build.ID ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้อาจเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกความแตกต่างระหว่างบิลด์ซอฟต์แวร์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
android.os.Build.MANUFACTURER ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("")
android.os.Build.MODEL ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ชื่อนี้ควรเป็นชื่อเดียวกับที่ใช้ในการทําการตลาดและขายอุปกรณ์แก่ผู้ใช้ ไม่มีข้อกำหนดเฉพาะเกี่ยวกับรูปแบบของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("")
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 รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม เช่น "unsigned,debug" ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
android.os.Build.TIME ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น
android.os.Build.TYPE ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ควรมีค่าอย่างใดอย่างหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ "user", "userdebug" หรือ "eng" ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9.,_-]+$"
android.os.Build.USER ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")

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

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

3.2.3.1. Intent ของแอปพลิเคชันหลัก

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

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

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

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

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

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

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

3.2.3.2. การลบล้าง Intent

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

3.2.3.3. เนมสเปซของ Intent

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

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

3.2.3.4. เจตนาการออกอากาศ

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับ ABI ของ Android การดำเนินการต่อไปนี้จะเกิดขึ้น

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

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

  • libc (คลัง C)
  • libm (คลังคณิตศาสตร์)
  • รองรับ C++ เพียงเล็กน้อย
  • อินเทอร์เฟซ JNI
  • liblog (การบันทึกของ Android)
  • libz (การบีบอัด Zlib)
  • libdl (ตัวลิงก์แบบไดนามิก)
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libEGL.so (การจัดการพื้นผิว OpenGL ดั้งเดิม)
  • libjnigraphics.so
  • libOpenSLES.so (การรองรับเสียง OpenSL ES 1.0.1)
  • libOpenMAXAL.so (รองรับ OpenMAX AL 1.0.1)
  • libandroid.so (การรองรับกิจกรรม Android ดั้งเดิม)
  • การรองรับ OpenGL ตามที่อธิบายไว้ด้านล่าง

โปรดทราบว่า Android NDK รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม หากการติดตั้งใช้งานอุปกรณ์ใช้งานร่วมกับ ABI ที่กําหนดไว้ล่วงหน้าไม่ได้ อุปกรณ์ต้องไม่รายงานการรองรับ ABI ใดๆ ทั้งสิ้น

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 ความเข้ากันได้ของลักษณะการทํางานของ API

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

  • อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทํางานหรือความหมายของ Intent มาตรฐาน
  • อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจรของคอมโพเนนต์ระบบบางประเภท (เช่น บริการ กิจกรรม ContentProvider ฯลฯ)
  • อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน

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

3.6 เนมสเปซของ API

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

การแก้ไขที่ไม่ได้รับอนุญาต ได้แก่

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

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

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

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

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

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

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

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

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

ขนาดหน้าจอ ความหนาแน่นของหน้าจอ หน่วยความจําของแอปพลิเคชัน
เล็ก / ปกติ / ใหญ่ ldpi / mdpi 16MB
เล็ก / ปกติ / ใหญ่ tvdpi / hdpi 32MB
เล็ก / ปกติ / ใหญ่ xhdpi 64MB
xlarge mdpi 32MB
xlarge tvdpi / hdpi 64MB
xlarge xhdpi 128MB

3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้

3.8.1. วิดเจ็ต

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

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

การติดตั้งใช้งานอุปกรณ์ต้องสามารถแสดงผลวิดเจ็ตขนาด 4 x 4 ในตารางกริดมาตรฐาน (ดูรายละเอียดได้ในหลักเกณฑ์การออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 18])

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

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

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

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

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

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

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

3.8.4. ข้อความโทสต์

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

3.8.5. ธีม

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

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

3.8.6. วอลเปเปอร์เคลื่อนไหว

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

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

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

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

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

3.8.8. การตั้งค่าการจัดการอินพุต

Android 4.0 รองรับเครื่องมือจัดการอินพุต API ของ Android 4.0 อนุญาตให้ IME ของแอปที่กำหนดเองระบุการตั้งค่าที่ผู้ใช้ปรับได้ การติดตั้งใช้งานในอุปกรณ์ต้องมีวิธีให้ผู้ใช้เข้าถึงการตั้งค่า IME ได้ทุกเมื่อที่ IME ที่ให้บริการการตั้งค่าผู้ใช้ดังกล่าวแสดงขึ้น

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

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

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับนโยบายการดูแลระบบอุปกรณ์อย่างเต็มรูปแบบ การติดตั้งใช้งานต้องไม่อนุญาตให้เปิดใช้แอปพลิเคชันการดูแลระบบอุปกรณ์ กล่าวโดยละเอียดคือ หากอุปกรณ์ไม่รองรับนโยบายการดูแลระบบอุปกรณ์ทั้งหมด การใช้งานอุปกรณ์ต้องตอบสนองต่อ Intent android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN แต่ต้องแสดงข้อความแจ้งให้ผู้ใช้ทราบว่าอุปกรณ์ไม่รองรับการดูแลระบบอุปกรณ์

3.10 การช่วยเหลือพิเศษ

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

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

นอกจากนี้ การใช้งานอุปกรณ์ควรมีการใช้งานบริการการช่วยเหลือพิเศษในอุปกรณ์ และควรมีกลไกให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษในระหว่างการตั้งค่าอุปกรณ์ การติดตั้งใช้งานบริการการช่วยเหลือพิเศษแบบโอเพนซอร์สมีอยู่ในโปรเจ็กต์ EyesFree [แหล่งข้อมูล, 31]

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

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

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

4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน

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

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

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

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

5.1 ตัวแปลงรหัสสื่อ

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

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

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

ประเภท รูปแบบ / ตัวแปลงรหัส โปรแกรมเปลี่ยนไฟล์ ตัวถอดรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์
เสียง AAC LC/LTP ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟน และกำหนด android.hardware.microphone		 ต้องระบุ เนื้อหาโมโน/สเตอริโอในอัตราบิตมาตรฐานสูงสุด 160 Kbps และอัตราตัวอย่าง 8-48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC ไฟล์ดิบ ADTS (.aac, ถอดรหัสใน Android 3.1 ขึ้นไป, เข้ารหัสใน Android 4.0 ขึ้นไป, ไม่รองรับ ADIF)
  • MPEG-TS (.ts, ไม่สามารถกรอได้, Android 3.0 ขึ้นไป)
HE-AACv1 (AAC+)   ต้องระบุ
HE-AACv2 (AAC+ ที่ปรับปรุงแล้ว)   ต้องระบุ
AMR-NB ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟน และกำหนด android.hardware.microphone		 ต้องระบุ 4.75 ถึง 12.2 kbps ที่อัตราตัวอย่าง 8kHz 3GPP (.3gp)
AMR-WB ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์ไมโครโฟน และกำหนด android.hardware.microphone		 ต้องระบุ 9 อัตราตั้งแต่ 6.60 Kbps ถึง 23.85 Kbps ที่อัตราตัวอย่าง 16kHz 3GPP (.3gp)
FLAC   ต้องระบุ
(Android 3.1 ขึ้นไป)		 โมโน/สเตอริโอ (ไม่มีหลายช่อง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz ในอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากตัวแปลงสัญญาณ 48 เป็น 44.1 kHz จะไม่มีตัวกรอง Low Pass) แนะนำ 16 บิต ระบบจะไม่ใช้การกรองความถี่แบบดิทเทอร์สำหรับ 24 บิต FLAC (.flac) เท่านั้น
MP3   ต้องระบุ โมโน/สเตอริโอ 8-320 Kbps แบบคงที่ (CBR) หรืออัตราบิตแบบผันแปร (VBR) MP3 (.mp3)
MIDI   ต้องระบุ MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF รองรับรูปแบบริงโทน RTTTL/RTX, OTA และ iMelody
  • ประเภท 0 และ 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis   ต้องระบุ  
  • Ogg (.ogg)
  • Matroska (.mkv)
PCM/WAVE   ต้องระบุ PCM แบบเชิงเส้น 8 และ 16 บิต (อัตราสูงสุดตามขีดจำกัดของฮาร์ดแวร์) WAVE (.wav)
รูปภาพ JPEG ต้องระบุ ต้องระบุ Base+progressive JPEG (.jpg)
GIF   ต้องระบุ   GIF (.gif)
PNG ต้องระบุ ต้องระบุ   PNG (.png)
BMP   ต้องระบุ   BMP (.bmp)
WEBP ต้องระบุ ต้องระบุ   WebP (.webp)
วิดีโอ H.263 ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้อง และกำหนด android.hardware.camera หรือ android.hardware.camera.front		 ต้องระบุ  
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC ต้องระบุ
ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้อง และกำหนด android.hardware.camera หรือ android.hardware.camera.front		 ต้องระบุ โปรไฟล์พื้นฐาน (BP)
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-TS (.ts, เสียง AAC เท่านั้น, ไม่สามารถกรอได้, Android 3.0 ขึ้นไป)
MPEG-4 SP   ต้องระบุ   3GPP (.3gp)
VP8   ต้องระบุ
(Android 2.3.3 ขึ้นไป)		   WebM (.webm) และ Matroska (.mkv, Android 4.0 ขึ้นไป)

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

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

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

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

เมื่อแอปพลิเคชันใช้ 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 เทียบกับ SPL 90 dB ที่ไมโครโฟน
  • ความเพี้ยนตามฮาร์โมนิกทั้งหมดควรน้อยกว่า 1% จาก 100 Hz ถึง 4000 Hz ที่ระดับอินพุต 90 dB SPL

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

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

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

5.4. เวลาในการตอบสนองของเสียง

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

ความหมายของคำต่างๆ ในส่วนนี้

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

เมื่อใช้คําจํากัดความข้างต้น การติดตั้งใช้งานอุปกรณ์ควรแสดงพร็อพเพอร์ตี้ต่อไปนี้

  • เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 100 มิลลิวินาที
  • เวลาในการตอบสนองของเอาต์พุตที่อุ่นเครื่องแล้วไม่เกิน 10 มิลลิวินาที
  • เวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องไม่เกิน 45 มิลลิวินาที
  • เวลาในการตอบสนองของอินพุตแบบ Cold Start ไม่เกิน 100 มิลลิวินาที
  • เวลาในการตอบสนองของอินพุตต่อเนื่องไม่เกิน 50 มิลลิวินาที

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

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้ อุปกรณ์อาจรายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำโดยการรายงานฟีเจอร์ "android.hardware.audio.low-latency" ผ่านคลาส android.content.pm.PackageManager [แหล่งข้อมูล, 37] ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดเหล่านี้ อุปกรณ์ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

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

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

  • RTSP (RTP, SDP)
  • การสตรีมแบบ Progressive ของ HTTP(S)
  • โปรโตคอลฉบับร่างสําหรับสตรีมมิงแบบสดของ HTTP(S) เวอร์ชัน 3 [แหล่งข้อมูล, 59]

6. ความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

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

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

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

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

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

  • ต้องมีการกำหนดคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
  • ลักษณะการทํางานของ API ต้องติดตั้งใช้งานแบบ No-Ops ในลักษณะที่เหมาะสม
  • เมธอด API ต้องแสดงผลค่า null ตามที่เอกสารประกอบของ SDK อนุญาต
  • เมธอด API ต้องแสดงผลการใช้งานคลาสแบบไม่มีการดำเนินการในกรณีที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
  • เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK

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

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

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

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

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

  • "ขนาดเส้นทแยงมุมจริง" คือระยะทางเป็นนิ้วระหว่างมุมตรงข้ามกัน 2 มุมของส่วนที่สว่างของจอแสดงผล
  • "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 ("เล็ก")
  • อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ปกติ" ต้องมีขนาดหน้าจออย่างน้อย 470 dp x 320 dp
  • อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ใหญ่" ต้องมีหน้าจอขนาดอย่างน้อย 640 dp x 480 dp
  • อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ขนาดใหญ่พิเศษ" ต้องมีหน้าจอขนาดอย่างน้อย 960 dp x 720 dp

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

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

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

สัดส่วนภาพหน้าจอ

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

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

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

  • 120 dpi หรือที่เรียกว่า "ldpi"
  • 160 dpi หรือที่เรียกว่า "mdpi"
  • 213 dpi หรือที่เรียกว่า "tvdpi"
  • 240 dpi หรือที่เรียกว่า "hdpi"
  • 320 dpi หรือที่เรียกว่า "xhdpi"
การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานซึ่งใกล้เคียงกับค่าความหนาแน่นจริงของหน้าจอมากที่สุด เว้นแต่ว่าความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าค่าต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นของอุปกรณ์มากที่สุดทำให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่รองรับ (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป

7.1.2. เมตริก Display

การติดตั้งใช้งานอุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่ระบุไว้ใน 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) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น ทีวีหรือแล็ปท็อป จะต้องรายงานandroid.hardware.screen.landscapeเท่านั้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

การติดตั้งใช้งานอุปกรณ์ต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ตามที่ระบุไว้และอธิบายอย่างละเอียดในเอกสารประกอบของ Android SDK การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Android Renderscript ด้วย ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK [แหล่งข้อมูล, 8]

การติดตั้งใช้งานอุปกรณ์ต้องระบุตัวเองว่ารองรับ OpenGL ES 1.0 และ 2.0 อย่างถูกต้องด้วย นั่นคือ

  • API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) ต้องรายงานการรองรับ OpenGL ES 1.0 และ 2.0
  • API ของ OpenGL ที่เป็น C/C++ ดั้งเดิม (นั่นคือ API ที่พร้อมให้บริการแก่แอปผ่าน libGLES_v1CM.so, libGLES_v2.so หรือ libEGL.so) จะต้องรายงานการรองรับ OpenGL ES 1.0 และ 2.0

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

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

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

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

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

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

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

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

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

หน้าจอการติดตั้งใช้งานอุปกรณ์แบ่งออกเป็น 2 ประเภท ได้แก่

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

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

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

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

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

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

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

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

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

  • 1280x720 (หรือที่เรียกว่า 720p): ขนาดหน้าจอ "ใหญ่" ความหนาแน่น "tvdpi" (213 dpi)
  • 1920x1080 (หรือที่เรียกว่า 1080p): หน้าจอขนาด "ใหญ่" ความหนาแน่น "xhdpi" (320 dpi)

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

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

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

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

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

7.2.1. แป้นพิมพ์

การติดตั้งใช้งานอุปกรณ์

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

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

การติดตั้งใช้งานอุปกรณ์

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

7.2.3. ปุ่มนำทาง

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

การติดตั้งใช้งานอุปกรณ์อาจใช้ส่วนต่างๆ ของหน้าจอเพื่อแสดงปุ่มการนําทาง แต่หากเป็นเช่นนั้น จะต้องเป็นไปตามข้อกําหนดต่อไปนี้

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

7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส

การติดตั้งใช้งานอุปกรณ์

  • ต้องมีระบบอินพุตเคอร์เซอร์บางประเภท (คล้ายเมาส์หรือระบบสัมผัส)
  • อาจมีหน้าจอสัมผัสแบบใดก็ได้ (เช่น คาปาซิทีฟหรือ Resistive)
  • ควรรองรับเคอร์เซอร์ที่ติดตามได้อย่างอิสระทั้งหมด หากหน้าจอสัมผัสรองรับเคอร์เซอร์หลายตัว
  • ต้องรายงานค่าของ android.content.res.Configuration.touchscreen [Resources, 40] ที่สอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงในอุปกรณ์

Android 4.0 รองรับหน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตการสัมผัสจำลองที่หลากหลาย การติดตั้งใช้งานอุปกรณ์ที่ใช้หน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผล [แหล่งข้อมูล, 61] เพื่อให้ผู้ใช้รู้สึกว่าได้โต้ตอบกับรายการบนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อระบุวัตถุที่กำลังมีการจัดการ ในทางตรงกันข้าม อินเทอร์เฟซการสัมผัสจำลองมีระบบการป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายแบบใช้แรงโน้มถ่วง ชี้เซอร์แบบใช้แรงโน้มถ่วง จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบสัมผัสจำลอง Android 4.0 มีค่าคงที่ของฟีเจอร์ android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (นั่นคืออุปกรณ์ที่ใช้เคอร์เซอร์) ที่มีคุณภาพสูง เช่น เมาส์หรือแทร็กแพด ซึ่งสามารถจําลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสชุดย่อยที่จำลอง การติดตั้งใช้งานอุปกรณ์ที่ประกาศฟีเจอร์การแตะจำลองต้องเป็นไปตามข้อกำหนดการแตะจำลองในส่วนที่ 7.2.5

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

7.2.5. การป้อนข้อมูลด้วยการสัมผัสจำลอง

การติดตั้งใช้งานอุปกรณ์ที่ประกาศว่ารองรับ android.hardware.faketouch

  • ต้องรายงานตำแหน่งสัมบูรณ์ X และ Y ของหน้าจอของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ที่มองเห็นได้บนหน้าจอ[แหล่งข้อมูล, 60]
  • ต้องรายงานเหตุการณ์การสัมผัสด้วยรหัสการดำเนินการ [แหล่งข้อมูล, 60] ที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นเมื่อเคอร์เซอร์ไปที่ down หรือ up บนหน้าจอ [แหล่งข้อมูล, 60]
  • ต้องรองรับเคอร์เซอร์ down และ up บนออบเจ็กต์บนหน้าจอ ซึ่งช่วยให้ผู้ใช้จําลองการแตะออบเจ็กต์บนหน้าจอได้
  • ต้องรองรับเคอร์เซอร์ down, เคอร์เซอร์ up, เคอร์เซอร์ down แล้วเคอร์เซอร์ up ในตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะสองครั้งที่วัตถุบนหน้าจอได้ [แหล่งข้อมูล, 60]
  • ต้องรองรับเคอร์เซอร์ down ที่จุดใดก็ได้บนหน้าจอ เคอร์เซอร์ย้ายไปยังจุดใดก็ได้บนหน้าจอ ตามด้วยเคอร์เซอร์ up ซึ่งช่วยให้ผู้ใช้จําลองการลากด้วยการแตะได้
  • ต้องรองรับเคอร์เซอร์ down จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว และรองรับเคอร์เซอร์ up บนหน้าจอ ซึ่งช่วยให้ผู้ใช้สามารถเหวี่ยงวัตถุบนหน้าจอได้

อุปกรณ์ที่ประกาศว่ารองรับ android.hardware.faketouch.multitouch.distinct ต้องเป็นไปตามข้อกำหนดสำหรับฟีเจอร์การแตะเสมือนจริงข้างต้น และต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการแยกกันด้วย

7.2.6. ไมโครโฟน

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

  • ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • ควรเป็นไปตามข้อกำหนดด้านคุณภาพเสียงในส่วนที่ 5.3
  • ควรเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองของเสียงในส่วนที่ 5.4

7.3. เซ็นเซอร์

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

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

รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทํางานของ Android SDK ที่บันทึกไว้ถือเป็นข้อมูลที่น่าเชื่อถือ

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

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

7.3.1. ตัวตรวจวัดความเร่ง

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

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

7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

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

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

7.3.3. GPS

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

7.3.4. เครื่องวัดการหมุน

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

  • ต้องชดเชยอุณหภูมิ
  • ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 5.5*Pi เรเดียน/วินาที (ประมาณ 1,000 องศาต่อวินาที)
  • ต้องส่งเหตุการณ์ที่ 100 Hz ขึ้นไปได้
  • ต้องมีความละเอียด 12 บิตขึ้นไป
  • ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) อนุญาตให้ความแปรปรวนเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของ Gyro ที่อัตราตัวอย่าง 1 Hz ค่าดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
  • ต้องมีการประทับเวลาที่ใกล้เคียงกับเวลาที่เหตุการณ์ฮาร์ดแวร์เกิดขึ้นมากที่สุด ต้องนำเวลาในการตอบสนองที่คงที่ออก

7.3.5. บารอมิเตอร์

การติดตั้งใช้งานอุปกรณ์อาจรวมถึงบารอมิเตอร์ (เช่น เซ็นเซอร์ความดันอากาศรอบตัว) หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะทําสิ่งต่อไปนี้

  • ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
  • ต้องมีความแม่นยำเพียงพอเพื่อให้สามารถประมาณระดับความสูง

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

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

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

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

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

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

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

7.4.1. โทรศัพท์

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

การใช้งานอุปกรณ์ Android 4.0 ควรรองรับ 802.11 อย่างน้อย 1 รูปแบบ (b/g/a/n ฯลฯ) หากการติดตั้งใช้งานอุปกรณ์รองรับ 802.11 อุปกรณ์นั้นต้องใช้ Android API ที่เกี่ยวข้อง

7.4.3. บลูทูธ

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

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

7.4.4. Near Field Communication

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

  • ต้องรายงานฟีเจอร์ android.hardware.nfc จากandroid.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 37]
  • ต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้
    • ต้องทําหน้าที่เป็นเครื่องอ่าน/เครื่องเขียน NFC Forum ได้ (ตามที่ระบุไว้ในข้อกําหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • IsoDep (ISO 14443-4)
      • แท็ก NFC Forum ประเภท 1, 2, 3, 4 (กำหนดโดย NFC Forum)
  • ควรอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ได้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC ด้านล่างจะระบุว่า "ควร" สำหรับ Android 4.0 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" กล่าวคือ มาตรฐานเหล่านี้เป็นตัวเลือกใน Android 4.0 แต่จะต้องใช้ในเวอร์ชันในอนาคต เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android 4.0 ปฏิบัติตามข้อกำหนดเหล่านี้ใน Android 4.0 เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้
    • NfcV (ISO 15693)
  • ต้องสามารถส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบ peer-to-peer ต่อไปนี้
    • ISO 18092
    • LLCP 1.0 (กำหนดโดย NFC Forum)
    • SDP 1.0 (กำหนดโดย NFC Forum)
    • โปรโตคอล Push ของ NDEF [แหล่งข้อมูล, 43]
    • SNEP 1.0 (กำหนดโดย NFC Forum)
  • ต้องรองรับ Android Beam ดังนี้
    • ต้องใช้เซิร์ฟเวอร์เริ่มต้น SNEP ข้อความ NDEF ที่ถูกต้องซึ่งเซิร์ฟเวอร์ SNEP เริ่มต้นได้รับต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้ Android Beam ในการตั้งค่าต้องไม่ปิดใช้การส่งข้อความ NDEF ขาเข้า
    • ต้องติดตั้งใช้งานเซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP ต้องได้รับการประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้น SNEP
    • ต้องติดตั้งใช้งานไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Android Beam หากไม่พบเซิร์ฟเวอร์ SNEP เริ่มต้น ลูกค้าต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
    • ต้องอนุญาตให้กิจกรรมที่ทำงานอยู่เบื้องหน้าตั้งค่าข้อความ NDEF ของ P2P ขาออกโดยใช้ android.nfc.NfcAdapter.setNdefPushMessage และ android.nfc.NfcAdapter.setNdefPushMessageCallback และ android.nfc.NfcAdapter.enableForegroundNdefPush
    • ควรใช้ท่าทางสัมผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อส่งข้อมูลแบบไร้สัมผัส" ก่อนส่งข้อความ NDEF แบบ P2P ขาออก
    • ควรเปิดใช้ Android Beam โดยค่าเริ่มต้น
  • ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC
  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอที่ใช้งานอยู่ และหน้าจอล็อกที่ปลดล็อก

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

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

โปรดทราบว่า Android 4.0 มี API สำหรับ MIFARE ประเภทเหล่านี้ หากการติดตั้งใช้งานอุปกรณ์รองรับ MIFARE ในบทบาทเครื่องอ่าน/เครื่องเขียน อุปกรณ์จะทําสิ่งต่อไปนี้

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

หากการใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์ NFC จะต้องไม่ประกาศฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 37] และต้องใช้งาน NFC API ของ Android 4.0 เป็น No-Op

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

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

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

การติดตั้งใช้งานอุปกรณ์ที่ใช้มาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลักควรรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 รายการ เช่น 802.11 (Wi-Fi)

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

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 พิกเซล)
  • ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API กล่าวคือ API ของกล้องใน Android 4.0 รองรับกล้องหน้าโดยเฉพาะ และการใช้งานอุปกรณ์ต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเดียวในอุปกรณ์ก็ตาม
  • อาจรวมฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่พร้อมใช้งานสำหรับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
  • ต้องสะท้อน (มิเรอร์) สตรีมที่แสดงโดยแอปใน CameraPreview ในแนวนอน ดังนี้
    • หากผู้ใช้สามารถหมุนการใช้งานอุปกรณ์ได้ (เช่น การหมุนโดยอัตโนมัติผ่านเครื่องวัดความเร่งหรือการหมุนด้วยตนเองผ่านอินพุตของผู้ใช้) ตัวอย่างภาพจากกล้องต้องแสดงแบบสะท้อนในแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์
    • หากแอปพลิเคชันปัจจุบันได้ส่งคำขออย่างชัดเจนให้หมุนการแสดงผลของกล้องผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation() [Resources, 50] แสดงว่าภาพตัวอย่างของกล้องต้องแสดงแบบสะท้อนในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุ
    • ไม่เช่นนั้น ตัวอย่างเพลงต้องมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์
  • ต้องมิเรอร์รูปภาพที่แสดงโดยฟีเจอร์ดูภาพหลังโพสต์ในลักษณะเดียวกับสตรีมรูปภาพตัวอย่างของกล้อง (หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับการดูโพสต์ ก็ไม่จําเป็นต้องใช้ข้อกําหนดนี้)
  • ต้องไม่มิเรอร์สตรีมวิดีโอหรือภาพนิ่งที่บันทึกไว้ซึ่งแสดงผลสุดท้ายซึ่งส่งกลับไปยังการเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ

7.5.3. ลักษณะการทํางานของ Camera API

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

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

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

การติดตั้งใช้งานอุปกรณ์ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters หากฮาร์ดแวร์พื้นฐานรองรับฟีเจอร์ดังกล่าว หากฮาร์ดแวร์ของอุปกรณ์ไม่รองรับฟีเจอร์หนึ่งๆ API จะต้องทํางานตามที่ระบุไว้ในเอกสาร ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยอมรับหรือรู้จักค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ในandroid.hardware.Camera.Parameters กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และจะต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง

การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Camera.ACTION_NEW_PICTURE intent ทุกครั้งที่กล้องถ่ายภาพใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ

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

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

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

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

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

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

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

Android API มีเครื่องมือจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล [แหล่งข้อมูล, 56] การติดตั้งใช้งาน Download Manager ของอุปกรณ์ต้องสามารถดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100MB ไปยังตำแหน่ง "แคช" เริ่มต้น

7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน

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

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

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

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

ไม่ว่าระบบจะใช้พื้นที่เก็บข้อมูลร่วมกันในรูปแบบใด การติดตั้งใช้งานอุปกรณ์จะต้องจัดให้มีกลไกในการเข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลร่วมกันจากคอมพิวเตอร์โฮสต์ เช่น อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB (UMS) หรือ Media Transfer Protocol (MTP) การติดตั้งใช้งานอุปกรณ์อาจใช้อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB แต่ควรใช้ Media Transfer Protocol หากการติดตั้งใช้งานอุปกรณ์รองรับ Media Transfer Protocol ให้ทำดังนี้

  • การใช้งานอุปกรณ์ควรเข้ากันได้กับโฮสต์ MTP ของ Android อ้างอิง ซึ่งก็คือ Android File Transfer [แหล่งข้อมูล, 57]
  • การติดตั้งใช้งานอุปกรณ์ควรรายงานคลาสอุปกรณ์ USB ของ 0x00
  • การติดตั้งใช้งานอุปกรณ์ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

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

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

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

7.7. USB

การติดตั้งใช้งานอุปกรณ์ควรมีพอร์ตไคลเอ็นต์ USB และควรมีพอร์ตโฮสต์ USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตไคลเอ็นต์ USB ให้ทำดังนี้

  • พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB-A มาตรฐานได้
  • พอร์ตควรใช้รูปแบบของอุปกรณ์เป็น micro USB
  • อุปกรณ์ต้องอนุญาตให้โฮสต์ที่เชื่อมต่อเข้าถึงเนื้อหาของวอลุ่มพื้นที่เก็บข้อมูลที่แชร์โดยใช้ที่จัดเก็บข้อมูลจำนวนมากแบบ USB หรือ Media Transfer Protocol
  • และต้องใช้งาน Android Open Accessory API และข้อกำหนดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK รวมถึงต้องประกาศรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory [แหล่งข้อมูล, 51]

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตโฮสต์ USB ให้ทำดังนี้

  • อุปกรณ์อาจใช้รูปแบบพอร์ตที่ไม่เป็นไปตามมาตรฐาน แต่หากเป็นเช่นนั้น อุปกรณ์ต้องมาพร้อมกับสายหรือสายแปลงพอร์ตเป็น USB-A มาตรฐาน
  • และต้องติดตั้งใช้งาน Android USB Host API ตามที่ระบุไว้ใน Android SDK และประกาศรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host [แหล่งข้อมูล, 52]

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

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

การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามเมตริกประสิทธิภาพหลักของอุปกรณ์ที่เข้ากันได้กับ Android 4.0 ที่ระบุไว้ในตารางด้านล่าง

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

9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย

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

9.1. สิทธิ์

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

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

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

9.3. สิทธิ์ในระบบไฟล์

การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสิทธิ์การเข้าถึงไฟล์ Android ตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์ [แหล่งข้อมูล, 54]

9.4. สภาพแวดล้อมการดําเนินการอื่น

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

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

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

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

รันไทม์ทางเลือกต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android ดังนี้

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

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

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

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

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

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

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

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

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

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

10.2. โปรแกรมตรวจสอบ CTS

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

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

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

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

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

  • แอปพลิเคชัน "แอปสําหรับ Android" [แหล่งข้อมูล, 55]
  • Replica Island (มีให้บริการใน Android Market)

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

11. ซอฟต์แวร์ที่อัปเดตได้

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

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

  • การดาวน์โหลดผ่านอากาศ (OTA) ที่มีการอัปเดตแบบออฟไลน์ผ่านการรีบูต
  • อัปเดตแบบ "ใช้การต่อฮอตสปอตจากมือถือ" ผ่าน USB จาก PC โฮสต์
  • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในอุปกรณ์เก็บข้อมูลแบบถอดได้

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

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

12. ติดต่อเรา

คุณสามารถติดต่อผู้เขียนเอกสารที่ [email protected] เพื่อขอคำชี้แจงหรือแจ้งปัญหาที่คุณคิดว่าเอกสารไม่ได้กล่าวถึง

ภาคผนวก ก. - ขั้นตอนการทดสอบบลูทูธ

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

ขั้นตอนการทดสอบจะอิงตามแอปตัวอย่าง BluetoothChat ที่รวมอยู่ในต้นไม้โปรเจ็กต์โอเพนซอร์สของ Android ขั้นตอนนี้ต้องใช้อุปกรณ์ 2 เครื่อง ดังนี้

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

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

การตั้งค่าและการติดตั้ง

  1. สร้าง BluetoothChat.apk ผ่าน "make samples" จากโครงสร้างซอร์สโค้ด Android
  2. ติดตั้ง BluetoothChat.apk ในอุปกรณ์ที่ใช้งานได้
  3. ติดตั้ง BluetoothChat.apk ในอุปกรณ์ที่จะใช้

ทดสอบการควบคุมบลูทูธด้วยแอป

  1. เปิด BluetoothChat ในอุปกรณ์ที่เลือกขณะที่บลูทูธปิดอยู่
  2. ยืนยันว่าอุปกรณ์ที่เลือกเปิดบลูทูธหรือแจ้งให้ผู้ใช้เปิดบลูทูธด้วยกล่องโต้ตอบ

ทดสอบการจับคู่และการสื่อสาร

  1. เปิดแอป Bluetooth Chat ในอุปกรณ์ทั้ง 2 เครื่อง
  2. ทำให้อุปกรณ์ที่ทราบว่าใช้งานได้ค้นพบได้จากภายใน BluetoothChat (โดยใช้เมนู)
  3. ในอุปกรณ์ที่เป็นไปได้ ให้สแกนหาอุปกรณ์บลูทูธจากภายใน BluetoothChat (โดยใช้เมนู) และจับคู่กับอุปกรณ์ที่ทราบว่าใช้งานได้
  4. ส่งข้อความอย่างน้อย 10 ข้อความจากอุปกรณ์แต่ละเครื่อง และตรวจสอบว่าอุปกรณ์อีกเครื่องได้รับข้อความอย่างถูกต้อง
  5. ปิดแอป BluetoothChat ในอุปกรณ์ทั้ง 2 เครื่องโดยกดHome
  6. ยกเลิกการจับคู่อุปกรณ์แต่ละเครื่องโดยใช้แอปการตั้งค่าของอุปกรณ์

ทดสอบการจับคู่และการสื่อสารในทิศทางย้อนกลับ

  1. เปิดแอป Bluetooth Chat ในอุปกรณ์ทั้ง 2 เครื่อง
  2. ทำให้อุปกรณ์ที่เลือกค้นพบได้จากภายใน BluetoothChat (โดยใช้เมนู)
  3. ในอุปกรณ์ที่ใช้งานได้ ให้สแกนหาอุปกรณ์บลูทูธจากภายใน BluetoothChat (โดยใช้เมนู) และจับคู่กับอุปกรณ์ที่เป็นไปได้
  4. ส่งข้อความอย่างน้อย 10 ข้อความจากแต่ละอุปกรณ์ และตรวจสอบว่าอุปกรณ์อีกเครื่องได้รับข้อความอย่างถูกต้อง
  5. ปิดแอปแชทบลูทูธในอุปกรณ์ทั้ง 2 เครื่องโดยกด "ย้อนกลับ" ซ้ำๆ เพื่อไปที่ตัวเปิดแอป

ทดสอบการเปิดตัวอีกครั้ง

  1. เปิดแอป Bluetooth Chat อีกครั้งในอุปกรณ์ทั้ง 2 เครื่อง
  2. ส่งข้อความอย่างน้อย 10 ข้อความจากแต่ละอุปกรณ์ และตรวจสอบว่าอุปกรณ์อีกเครื่องได้รับข้อความอย่างถูกต้อง

หมายเหตุ: การทดสอบข้างต้นมีบางกรณีที่จบส่วนการทดสอบโดยใช้แป้น Home และบางกรณีที่ใช้แป้น Back การทดสอบเหล่านี้ไม่ซ้ำซ้อนและไม่ใช่ตัวเลือก วัตถุประสงค์คือเพื่อยืนยันว่า Bluetooth API และกองทำงานได้อย่างถูกต้อง ทั้งเมื่อกิจกรรมสิ้นสุดลงอย่างชัดเจน (เมื่อผู้ใช้กด "ย้อนกลับ" ซึ่งจะเรียกใช้ finish()) และส่งไปยังเบื้องหลังโดยนัย (เมื่อผู้ใช้กด "หน้าแรก") แต่ละชุดการทดสอบต้องทําตามที่อธิบายไว้