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

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

สารบัญ

1. บทนำ

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

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

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

หากต้องการพิจารณาว่าเข้ากันได้กับ Android 2.2 การใช้งานอุปกรณ์:

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

ในกรณีที่คำจำกัดความหรือ CTS นี้ไม่มีการดำเนินการใดๆ คลุมเครือ หรือไม่สมบูรณ์ ถือเป็นความรับผิดชอบของผู้ใช้อุปกรณ์ที่จะต้องแน่ใจว่าเข้ากันได้กับการใช้งานที่มีอยู่ ด้วยเหตุนี้ โครงการโอเพ่นซอร์ส Android [ แหล่งข้อมูล 3 ] จึงเป็นทั้งข้อมูลอ้างอิงและการใช้งาน Android ที่ต้องการ ผู้ติดตั้งอุปกรณ์ได้รับการสนับสนุนอย่างยิ่งให้ใช้งานตามซอร์สโค้ด "อัปสตรีม" ที่มีอยู่ในโครงการ Android Open Source แม้ว่าองค์ประกอบบางอย่างสามารถแทนที่ได้ด้วยการนำไปใช้แบบอื่นตามสมมุติฐาน แต่แนวทางปฏิบัตินี้ไม่สนับสนุนอย่างยิ่ง เนื่องจากการผ่านการทดสอบ CTS จะยากขึ้นอย่างมาก เป็นความรับผิดชอบของผู้ดำเนินการเพื่อให้แน่ใจว่ามีความเข้ากันได้ทางพฤติกรรมอย่างสมบูรณ์กับการใช้งาน 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 2.2: http://source.android.com/docs/compatibility/2.2/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. ข้อมูลจำเพาะ Dalvik Virtual Machine: มีอยู่ในซอร์สโค้ด Android ที่ dalvik/docs
11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. การแจ้งเตือน: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. ทรัพยากรของแอปพลิเคชัน: http://code.google.com/android/reference/available-resources.html
14. คู่มือสไตล์ไอคอนแถบสถานะ: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. ตัวจัดการการค้นหา: http://developer.android.com/reference/android/app/SearchManager.html
16. ขนมปังปิ้ง: http://developer.android.com/reference/android/widget/Toast.html
17. วอลเปเปอร์สด: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. แอปสำหรับ Android: http://code.google.com/p/apps-for-android
19. เอกสารประกอบเครื่องมืออ้างอิง (สำหรับ adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. คำอธิบายไฟล์ Android APK: http://developer.android.com/guide/topics/fundamentals.html
21. ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. เครื่องมือทดสอบลิง: https://developer.android.com/studio/test/other-testing-tools/monkey
23. รายการคุณสมบัติฮาร์ดแวร์ Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. รองรับหลายหน้าจอ: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. พื้นที่พิกัดเซ็นเซอร์: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. การอ้างอิงความปลอดภัยและการอนุญาตของ Android: http://developer.android.com/guide/topics/security/security.html
30. บลูทูธ API: http://developer.android.com/reference/android/bluetooth/package-summary.html

ทรัพยากรเหล่านี้จำนวนมากได้มาจาก Android 2.2 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.2 SDK [ แหล่งข้อมูล, 4 ]

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

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

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

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 หลัก:

• นาฬิกาตั้งโต๊ะ
• เบราว์เซอร์
• ปฏิทิน
• เครื่องคิดเลข
• กล้อง
• รายชื่อผู้ติดต่อ
• อีเมล
• แกลเลอรี่
• ค้นหาทั่วโลก
• ตัวเปิด
• LivePicker (นั่นคือแอปพลิเคชันตัวเลือก Live Wallpaper อาจละเว้นได้หากอุปกรณ์ไม่รองรับ Live Wallpapers ตามหัวข้อ 3.8.5)
• การส่งข้อความ (AKA "Mms")
• ดนตรี
• โทรศัพท์
• การตั้งค่า
• บันทึกเสียง

แอปพลิเคชันระบบ 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 ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสม การใช้งานอุปกรณ์ต้องมีการรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่ได้รับการจัดการเพื่อเรียกใช้โค้ดเนทีฟ โดยใช้ซีแมนทิกส์ Java Native Interface (JNI) มาตรฐาน API ต่อไปนี้จะต้องใช้ได้กับโค้ดเนทีฟ:

• libc (ไลบรารี C)
• libm (ห้องสมุดคณิตศาสตร์)
• อินเทอร์เฟซ JNI
• libz (การบีบอัด Zlib)
• liblog (การบันทึก Android)
• การสนับสนุนขั้นต่ำสำหรับ C ++
• รองรับ OpenGL ตามที่อธิบายไว้ด้านล่าง

การใช้งานอุปกรณ์ต้องรองรับ OpenGL ES 1.0 อุปกรณ์ที่ขาดการเร่งด้วยฮาร์ดแวร์ต้องใช้ OpenGL ES 1.0 โดยใช้ตัวเรนเดอร์ซอฟต์แวร์ การใช้งานอุปกรณ์ควรใช้ OpenGL ES 1.1 ให้มากที่สุดเท่าที่ฮาร์ดแวร์อุปกรณ์รองรับ การใช้งานอุปกรณ์ควรมีการใช้งานสำหรับ OpenGL ES 2.0 หากฮาร์ดแวร์มีประสิทธิภาพที่เหมาะสมบน API เหล่านั้น

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

การใช้งานอุปกรณ์จะต้องรายงาน Application Binary Interface (ABI) ดั้งเดิมที่อุปกรณ์รองรับอย่างถูกต้องผ่าน android.os.Build.CPU_ABI API ABI จะต้องเป็นหนึ่งในรายการที่ได้รับการบันทึกไว้ใน Android NDK เวอร์ชันล่าสุดในไฟล์ docs/CPU-ARCH-ABIS.txt โปรดทราบว่า Android NDK รุ่นเพิ่มเติมอาจมีการรองรับ 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.2 โครงสร้างนี้มีชุดฟังก์ชันการทำงานและการแก้ไขความปลอดภัยเฉพาะสำหรับ 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, แคชของแอปพลิเคชัน และ API การระบุตำแหน่งทางภูมิศาสตร์ [ แหล่งข้อมูล, 9 ] WebView ต้องมีการสนับสนุนสำหรับแท็ก HTML5 <video> HTML5 API เช่นเดียวกับ JavaScript API ทั้งหมด จะต้องปิดใช้งานตามค่าเริ่มต้นใน WebView เว้นแต่นักพัฒนาจะเปิดใช้งานอย่างชัดเจนผ่าน Android API ปกติ

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

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

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

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

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

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

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

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

ชุดทดสอบความเข้ากันได้ (CTS) จะทดสอบส่วนสำคัญของแพลตฟอร์มเพื่อดูความเข้ากันได้ทางพฤติกรรม แต่ไม่ใช่ทั้งหมด เป็นความรับผิดชอบของผู้นำไปใช้ในการตรวจสอบความเข้ากันได้ทางพฤติกรรมกับโครงการ 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 ที่มีอยู่ หรือการเพิ่ม API ใหม่) ผู้ดำเนินการควรไปที่ source.android.com และเริ่มกระบวนการสนับสนุนการเปลี่ยนแปลงและ รหัสตามข้อมูลบนเว็บไซต์นั้น

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

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

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

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

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

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

3.8.1. วิดเจ็ต

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

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

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

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

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

3.8.3. ค้นหา

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

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

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

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

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

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

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

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

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

4. ความเข้ากันได้ของซอฟต์แวร์อ้างอิง

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

• เครื่องคิดเลข (รวมอยู่ใน SDK)
• Lunar Lander (รวมอยู่ใน SDK)
• แอปพลิเคชัน "แอปสำหรับ Android" [ แหล่งข้อมูล, 18 ]
• Replica Island (มีใน Android Market จำเป็นเฉพาะสำหรับการใช้งานอุปกรณ์ที่รองรับ OpenGL ES 2.0)

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

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

• ApiDemos (รวมอยู่ใน SDK)
• ManualSmokeTests (รวมอยู่ใน CTS)

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

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

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

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

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

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

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

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

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

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

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

6.3. แฝงเสียง

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

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

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

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

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

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

7. ความเข้ากันได้ของเครื่องมือนักพัฒนา

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

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

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

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

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

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

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

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

8.1. แสดง

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

สำหรับ Android 2.2 นี่คือการกำหนดค่าการแสดงผลที่พบบ่อยที่สุด:

การใช้งานอุปกรณ์ที่สอดคล้องกับหนึ่งในการกำหนดค่ามาตรฐานด้านบนจะต้องกำหนดค่าเพื่อรายงานขนาดหน้าจอที่ระบุไปยังแอปพลิเคชันผ่าน android.content.res.Configuration [ ทรัพยากร, 24 ] คลาส

แพ็คเกจ. APK บางตัวมีการปรากฏตัวที่ไม่ได้ระบุว่าเป็นช่วงความหนาแน่นที่เฉพาะเจาะจง เมื่อเรียกใช้แอปพลิเคชันดังกล่าวจะใช้ข้อ จำกัด ต่อไปนี้:

• การใช้งานอุปกรณ์จะต้องตีความทรัพยากรใน. APK ที่ไม่มีตัวระบุความหนาแน่นเป็นค่าเริ่มต้นเป็น "กลาง" (เรียกว่า "MDPI" ในเอกสาร SDK)
• เมื่อทำงานบนหน้าจอความหนาแน่น "ต่ำ" การใช้งานอุปกรณ์จะต้องปรับขนาดสินทรัพย์ขนาดกลาง/MDPI ลง 0.75
• เมื่อใช้งานบนหน้าจอความหนาแน่น "สูง" การใช้งานอุปกรณ์จะต้องเพิ่มขนาดสินทรัพย์ขนาดกลาง/MDPI โดยปัจจัย 1.5
• การใช้งานอุปกรณ์จะต้องไม่ปรับขนาดสินทรัพย์ภายในช่วงความหนาแน่นและต้องปรับขนาดสินทรัพย์ด้วยปัจจัยเหล่านี้ระหว่างช่วงความหนาแน่น

8.1.2. การกำหนดค่าการแสดงผลที่ไม่ได้มาตรฐาน

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

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

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

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

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

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

8.2. คีย์บอร์ด

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

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

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

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

• อาจละเว้นตัวเลือกการนำทางที่ไม่ใช่สัมผัส (นั่นคืออาจละเว้นแทร็กบอล, d-pad หรือล้อ)
• ต้องรายงานค่าที่ถูกต้องสำหรับ android.content.res.Configuration.navigation [ ทรัพยากร, 25 ]

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

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

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

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

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

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

8.6. ยูเอสบี

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

• ต้องใช้ไคลเอนต์ USB ที่เชื่อมต่อกับโฮสต์ USB ด้วยพอร์ต USB-A มาตรฐาน
• ต้องใช้สะพาน Debug Android ผ่าน USB (ตามที่อธิบายไว้ในส่วนที่ 7)
• ต้องใช้ข้อมูลจำเพาะของ USB Mass Storage เพื่ออนุญาตให้โฮสต์ที่เชื่อมต่อกับอุปกรณ์เพื่อเข้าถึงเนื้อหาของปริมาณ /sdcard
• ควรใช้รูปแบบฟอร์ม Micro USB ที่ด้านอุปกรณ์
• อาจรวมถึงพอร์ตที่ไม่ได้มาตรฐานในด้านอุปกรณ์ แต่ถ้าเป็นเช่นนั้นจะต้องจัดส่งด้วยสายเคเบิลที่สามารถเชื่อมต่อ pinout ที่กำหนดเองกับพอร์ต USB-A มาตรฐาน
• ควรใช้การสนับสนุนสำหรับข้อกำหนดการจัดเก็บมวล USB (เพื่อให้สามารถเข้าถึงที่เก็บข้อมูลได้หรือที่เก็บข้อมูลคงที่บนอุปกรณ์สามารถเข้าถึงได้จากพีซีโฮสต์)

8.7. ปุ่มนำทาง

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

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

8.8. เครือข่ายข้อมูลไร้สาย

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

หากการใช้งานอุปกรณ์มีรูปแบบเฉพาะที่ Android SDK มี API (นั่นคือ WiFi, GSM หรือ CDMA) การใช้งานจะต้องรองรับ API

อุปกรณ์อาจใช้การเชื่อมต่อข้อมูลไร้สายมากกว่าหนึ่งรูปแบบ อุปกรณ์อาจใช้การเชื่อมต่อข้อมูลแบบมีสาย (เช่นอีเธอร์เน็ต) แต่ต้องมีการเชื่อมต่อไร้สายอย่างน้อยหนึ่งรูปแบบดังกล่าวข้างต้น

8.9. กล้อง

การใช้งานอุปกรณ์จะต้องมีกล้องหันหน้าไปทางด้านหลัง กล้องด้านหลังที่รวมอยู่ด้วย:

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

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

1. หากแอปพลิเคชันไม่เคยเรียก Android.hardware.camera.parameters.setPreviewFormat (Int) อุปกรณ์จะต้องใช้ Android.hardware.pixelformat.ycbcr_420_sp สำหรับข้อมูลตัวอย่างที่ให้ไว้กับแอปพลิเคชัน
2. หากแอปพลิเคชันลงทะเบียนเป็น Android.hardware.camera.previewCallback อินสแตนซ์และระบบเรียกใช้เมธอด OnPreviewFrame () เมื่อรูปแบบตัวอย่างคือ YCBCR_420_SP ข้อมูลในไบต์ [] ที่ส่งผ่านไปยัง OnPreviewFrame () จะต้องอยู่ในรูปแบบการเข้ารหัส NV21 (นี่คือรูปแบบที่ใช้โดยตระกูลฮาร์ดแวร์ 7K) นั่นคือ NV21 จะต้องเป็นค่าเริ่มต้น

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

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

การใช้งานอุปกรณ์อาจรวมถึงกล้องด้านหน้า อย่างไรก็ตามหากการใช้งานอุปกรณ์รวมถึงกล้องด้านหน้า API กล้องที่ใช้งานบนอุปกรณ์จะต้องไม่ใช้กล้องด้านหน้าโดยค่าเริ่มต้น นั่นคือกล้อง API ใน Android 2.2 นั้นใช้สำหรับกล้องด้านหลังเท่านั้นและการใช้งานอุปกรณ์จะต้องไม่นำกลับมาใช้ใหม่หรือโอเวอร์โหลด API เพื่อทำหน้าที่ในกล้องด้านหน้าหากมีอยู่ โปรดทราบว่า API ที่กำหนดเองใด ๆ ที่เพิ่มโดยผู้ใช้อุปกรณ์เพื่อรองรับกล้องหน้าต้องปฏิบัติตามส่วน 3.5 และ 3.6; ตัวอย่างเช่นหาก android.hardware.Camera หรือ Camera.Parameters แบบกำหนดเองได้รับการจัดเตรียมไว้เพื่อรองรับกล้องด้านหน้าจะต้องไม่อยู่ในเนมสเปซที่มีอยู่ตามที่อธิบายไว้ในส่วน 3.5 และ 3.6 โปรดทราบว่าการรวมกล้องหน้าไม่ตรงตามข้อกำหนดที่อุปกรณ์รวมถึงกล้องด้านหลัง

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

การใช้งานอุปกรณ์จะต้องมีเครื่องวัดความเร่ง 3 แกนและจะต้องสามารถส่งมอบกิจกรรมได้ที่ 50 Hz หรือมากกว่า ระบบพิกัดที่ใช้โดย accelerometer จะต้องปฏิบัติตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API (ดู [ ทรัพยากร, 28 ])

8.11. เข็มทิศ

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

8.12. จีพีเอส

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

8.13. โทรศัพท์

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

ดูส่วนที่ 8.8 เครือข่ายข้อมูลไร้สาย

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

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

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

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

8.15. ที่เก็บข้อมูลที่ใช้ร่วมกัน

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

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

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

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

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

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

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

8.16. บลูทู ธ

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

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

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

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

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

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

10.1. สิทธิ์

การใช้งานอุปกรณ์จะต้องรองรับโมเดลการอนุญาต Android ตามที่กำหนดไว้ในเอกสารเกี่ยวกับ Android Developer [ ทรัพยากร, 29 ] โดยเฉพาะการใช้งานจะต้องบังคับใช้แต่ละการอนุญาตที่กำหนดตามที่อธิบายไว้ในเอกสาร SDK; ไม่อนุญาตให้ใช้สิทธิ์เปลี่ยนแปลงหรือเพิกเฉย การใช้งานอาจเพิ่มสิทธิ์เพิ่มเติมหากสตริง ID สิทธิ์ใหม่ไม่ได้อยู่ใน Android* เนมสเปซ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13. ติดต่อเรา

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

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

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

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.