คำจำกัดความความเข้ากันได้ของ Android 2.3

ลิขสิทธิ์ © 2010, Google Inc. สงวนลิขสิทธิ์
ความเข้ากันได้@android.com

สารบัญ

1. บทนำ

เอกสารนี้ระบุข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้โทรศัพท์มือถือเข้ากันได้กับ Android 2.3

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

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

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

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

โปรดทราบว่าข้อกำหนดความเข้ากันได้นี้ออกให้สอดคล้องกับการอัปเดต 2.3.3 สำหรับ Android ซึ่งเป็น API ระดับ 10 คำจำกัดความนี้ล้าสมัยและแทนที่ข้อกำหนดความเข้ากันได้สำหรับ Android เวอร์ชัน 2.3 ก่อน 2.3.3 (นั่นคือเวอร์ชัน 2.3.1 และ 2.3.2 ล้าสมัยแล้ว) อุปกรณ์ที่รองรับ Android ในอนาคตที่ใช้ Android 2.3 จะต้องจัดส่งเวอร์ชัน 2.3.3 หรือใหม่กว่า

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 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
8. คลาส android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. ความสามารถออฟไลน์ HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
11. แท็กวิดีโอ HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. API ตำแหน่งทางภูมิศาสตร์ HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. API ฐานข้อมูลเว็บ HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
15. ข้อมูลจำเพาะ Dalvik Virtual Machine: มีอยู่ในซอร์สโค้ด Android ที่ dalvik/docs
16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. การแจ้งเตือน: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. ทรัพยากรของแอปพลิเคชัน: http://code.google.com/android/reference/available-resources.html
19. คู่มือสไตล์ไอคอนแถบสถานะ: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. ตัวจัดการการค้นหา: http://developer.android.com/reference/android/app/SearchManager.html
21. ขนมปังปิ้ง: http://developer.android.com/reference/android/widget/Toast.html
22. วอลเปเปอร์สด: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. เอกสารประกอบเครื่องมืออ้างอิง (สำหรับ adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. คำอธิบายไฟล์ Android APK: http://developer.android.com/guide/topics/fundamentals.html
25. ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. เครื่องมือทดสอบลิง: https://developer.android.com/studio/test/other-testing-tools/monkey
27. รายการคุณสมบัติฮาร์ดแวร์ Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. รองรับหลายหน้าจอ: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. พื้นที่พิกัดเซ็นเซอร์: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. บลูทูธ API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. โปรโตคอลผลักดัน NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. API การวางแนวกล้อง: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. การอ้างอิงความปลอดภัยและการอนุญาตของ Android: http://developer.android.com/guide/topics/security/security.html
43. แอปสำหรับ Android: http://code.google.com/p/apps-for-android

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

3. ซอฟต์แวร์

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

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

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (รองรับเสียงของ Open Sound Library)
• libandroid.so (รองรับกิจกรรม Android ดั้งเดิม)
• รองรับ OpenGL ตามที่อธิบายไว้ด้านล่าง

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

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

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

นักพัฒนาและแอปพลิเคชันจำนวนมากอาศัยพฤติกรรมของคลาส android.webkit.WebView [ Resources, 8 ] สำหรับอินเทอร์เฟซผู้ใช้ ดังนั้นการใช้งาน WebView จะต้องเข้ากันได้ในทุกการใช้งาน Android ในทำนองเดียวกัน เว็บเบราว์เซอร์ที่ทันสมัยและสมบูรณ์เป็นศูนย์กลางของประสบการณ์ผู้ใช้ Android การใช้งานอุปกรณ์ต้องมีเวอร์ชันของ android.webkit.WebView ที่สอดคล้องกับซอฟต์แวร์อัปสตรีม Android และต้องมีเบราว์เซอร์ที่รองรับ HTML5 รุ่นใหม่ ตามที่อธิบายไว้ด้านล่าง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6. เนมสเปซ API

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.1. วิดเจ็ต

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

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

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

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

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

3.8.3. ค้นหา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.1 ตัวถอดรหัสสื่อ

การใช้งานอุปกรณ์จะต้องรวมถึงการใช้งานตัวถอดรหัสสำหรับตัวแปลงสัญญาณแต่ละตัวและรูปแบบที่อธิบายไว้ในตารางด้านล่าง โปรดทราบว่าตัวถอดรหัสสำหรับแต่ละประเภทสื่อเหล่านี้จัดทำโดยโครงการ Opstream Android Open-Source

5.1.2. ตัวเข้ารหัสสื่อ

การใช้งานอุปกรณ์ควรมีตัวเข้ารหัสสำหรับรูปแบบสื่อจำนวนมากที่ระบุไว้ในส่วนที่ 5.1.1 เป็นไปได้. อย่างไรก็ตามเครื่องเข้ารหัสบางตัวไม่สมเหตุสมผลสำหรับอุปกรณ์ที่ไม่มีฮาร์ดแวร์เสริมบางอย่าง ตัวอย่างเช่น encoder สำหรับวิดีโอ H.263 นั้นไม่สมเหตุสมผลหากอุปกรณ์ขาดกล้องใด ๆ การใช้งานอุปกรณ์จะต้องใช้ตัวเข้ารหัสสื่อตามเงื่อนไขที่อธิบายไว้ในตารางด้านล่าง

ดูส่วนที่ 7 สำหรับรายละเอียดเกี่ยวกับเงื่อนไขภายใต้การใช้งานฮาร์ดแวร์โดยการใช้งานอุปกรณ์

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

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

เมื่อแอปพลิเคชันใช้ android.media.AudioRecord API เพื่อเริ่มบันทึกกระแสเสียงการใช้งานอุปกรณ์ควรสุ่มตัวอย่างและบันทึกเสียงด้วยพฤติกรรมเหล่านี้แต่ละอย่าง:

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

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

5.3. แฝงเสียง

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

สำหรับวัตถุประสงค์ของส่วนนี้:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• หน้าจอต้องมีขนาดเส้นทแยงมุมอย่างน้อย 2.5 นิ้ว
• ความหนาแน่นจะต้องมีอย่างน้อย 100 dpi
• อัตราส่วนภาพต้องอยู่ระหว่าง 1.333 (4: 3) และ 1.779 (16: 9)
• เทคโนโลยีการแสดงผลที่ใช้ประกอบด้วยพิกเซลสี่เหลี่ยมจัตุรัส

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

หน่วยที่ใช้โดยข้อกำหนดข้างต้นหมายถึงดังนี้:

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

การใช้งานอุปกรณ์จะต้องใช้เพียงจอแสดงผลที่มีการกำหนดค่าแบบคงที่เดียว นั่นคือการใช้งานอุปกรณ์จะต้องไม่เปิดใช้งานการกำหนดค่าหลายหน้าจอ ตัวอย่างเช่นเนื่องจากโทรทัศน์ทั่วไปรองรับความละเอียดหลายอย่างเช่น 1080p, 720p และอื่น ๆ การกำหนดค่านี้ไม่สามารถใช้งานได้กับ Android 2.3 (อย่างไรก็ตามการสนับสนุนสำหรับการกำหนดค่าดังกล่าวอยู่ระหว่างการสอบสวนและวางแผนสำหรับ Android เวอร์ชันในอนาคต)

7.1.2. แสดงตัวชี้วัด

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

7.1.3. การสนับสนุนหน้าจอที่ประกาศ

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

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

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

อุปกรณ์จะต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์เมื่อใดก็ตามที่สอบถามผ่าน Android.content.res.configuration.orientation, Android.view.display.getOrientation () หรือ API อื่น ๆ

7.1.5. การเร่งความเร็วกราฟิก 3 มิติ

การใช้งานอุปกรณ์จะต้องรองรับ OpenGL ES 1.0 ตามที่กำหนดโดย Android 2.3 APIs สำหรับอุปกรณ์ที่ขาดฮาร์ดแวร์การเร่งความเร็ว 3 มิติการใช้งานซอฟต์แวร์ของ OpenGL ES 1.0 นั้นจัดทำโดยโครงการ Optream Android Open-Source การใช้งานอุปกรณ์ควรรองรับ OpenGL ES 2.0

การใช้งานอาจไม่สนับสนุนการสนับสนุน GL ES 2.0 อย่างไรก็ตามหากการสนับสนุนถูกละเว้นการใช้งานอุปกรณ์จะต้องไม่รายงานว่าสนับสนุน OpenGL ES 2.0 โดยเฉพาะหากการใช้งานอุปกรณ์ขาดการสนับสนุน OpenGL ES 2.0:

• API ที่ได้รับการจัดการ (เช่นผ่านวิธี GLES10.getString() ) จะต้องไม่รายงานการสนับสนุนสำหรับ OpenGL ES 2.0
• Native C/C ++ OpenGL APIs (นั่นคือแอพที่มีให้กับแอพผ่าน LIBGLES_V1CM.SO, LIBGLES_V2.SO หรือ libegl.SO) จะต้องไม่รายงานการสนับสนุนสำหรับ OpenGL ES 2.0

ในทางกลับกัน หาก การใช้งานอุปกรณ์รองรับ OpenGL ES 2.0 จะต้องรายงานอย่างถูกต้องว่าสนับสนุนผ่านเส้นทางที่เพิ่งแสดงรายการ

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

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

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

7.2.1. คีย์บอร์ด

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

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

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

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

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

7.2.3. กุญแจนำ

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

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

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

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

• ต้องมีหน้าจอสัมผัส
• อาจมีหน้าจอสัมผัสแบบ capacitive หรือตัวต้านทาน
• ต้องรายงานค่าของ android.content.res.Configuration [ ทรัพยากร, 30 ] สะท้อนให้เห็นถึงประเภทของหน้าจอสัมผัสเฉพาะบนอุปกรณ์
• ควรรองรับพอยน์เตอร์ที่ติดตามอย่างอิสระหากหน้าจอสัมผัสรองรับพอยน์เตอร์หลายตัว

7.3. เซนเซอร์

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

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

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

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

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

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

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

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

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

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

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

7.3.3. จีพีเอส

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

7.3.4. ไจโรสโคป

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

• จะต้องมีความสามารถในการวัดการปฐมนิเทศเปลี่ยนสูงถึง 5.5*pi เรเดียน/วินาที (นั่นคือประมาณ 1,000 องศาต่อวินาที)
• จะต้องสามารถส่งมอบกิจกรรมที่ 100 Hz หรือมากกว่า
• ต้องมีความแม่นยำ 8 บิตหรือมากกว่า

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

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

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

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

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

7.3.7. เครื่องวัดแสง

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

7.3.8. เซ็นเซอร์ความใกล้ชิด

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

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

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

7.4.1. โทรศัพท์

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

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

7.4.2. IEEE 802.11 (wifi)

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

7.4.3. บลูทู ธ

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

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

7.4.4. การสื่อสารใกล้สนาม

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

• ต้องรายงานคุณสมบัติ Android.hardware.nfc จาก android.content.pm.PackageManager.hasSystemFeature() [ ทรัพยากร 27 ]
• ต้องมีความสามารถในการอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้:
  • จะต้องมีความสามารถในการทำหน้าที่เป็นตัวอ่าน/นักเขียนฟอรัม NFC (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของฟอรัม NFC NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้:
    • NFCA (ISO14443-3A)
    • NFCB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • ISODEP (ISO 14443-4)
    • แท็กฟอรัม NFC ประเภท 1, 2, 3, 4 (กำหนดโดยฟอรัม NFC)
  • จะต้องมีความสามารถในการส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบเพียร์ทูเพียร์ต่อไปนี้:
    • ISO 18092
    • LLCP 1.0 (กำหนดโดยฟอรัม NFC)
    • SDP 1.0 (กำหนดโดยฟอรัม NFC)
    • NDEF Push Protocol [ ทรัพยากร, 33 ]
  • ต้องสแกนสำหรับเทคโนโลยีที่ได้รับการสนับสนุนทั้งหมดในขณะที่อยู่ในโหมดการค้นพบของ NFC
  • ควรอยู่ในโหมด NFC Discovery ในขณะที่อุปกรณ์ตื่นขึ้นมาพร้อมกับหน้าจอที่ใช้งานอยู่

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

  นอกจากนี้การใช้งานอุปกรณ์ควรรองรับเทคโนโลยี Mifare ที่ปรับใช้อย่างกว้างขวางต่อไปนี้

  • Mifare Classic (NXP MF1S503X [ ทรัพยากร, 34 ], MF1S703X [ ทรัพยากร, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ ทรัพยากร, 36 ], MF0ICU2 [ ทรัพยากร, 37 ])
  • NDEF บน Mifare Classic (NXP AN130511 [ ทรัพยากร, 38 ], AN130411 [ ทรัพยากร, 39 ])

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

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

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

  As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

  7.4.5. Minimum Network Capability

  Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

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

  Devices MAY implement more than one form of data connectivity.

  7.5. กล้อง

  Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

  7.5.1. Rear-Facing Camera

  Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

  • MUST have a resolution of at least 2 megapixels
  • SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
  • MAY have fixed-focus or EDOF (extended depth of field) hardware
  • MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

  7.5.2. Front-Facing Camera

  Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

  • MUST have a resolution of at least VGA (that is, 640x480 pixels)
  • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on อุปกรณ์.
  • MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
  • MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
  • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
  • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

  7.5.3. Camera API Behavior

  Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

  Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

  7.5.4. Camera Orientation

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

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

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

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

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

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

  Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

  Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

  Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

  It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

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

  7.7. ยูเอสบี

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

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. Performance Compatibility

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

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

  9. Security Model Compatibility

  Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

  9.1. สิทธิ์

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

  9.2. UID and Process Isolation

  Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

  9.3. Filesystem Permissions

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

  9.4. Alternate Execution Environments

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

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

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

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

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

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

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

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

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

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

  However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

  10.1. Compatibility Test Suite

  Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

  The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

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

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

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

  Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

  10.3. Reference Applications

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

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

  Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

  11. Updatable Software

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

  Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

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

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

  If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

  12. Contact Us

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

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

  Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.