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

ลิขสิทธิ์ © 2010, Google Inc. สงวนลิขสิทธิ์
Compatibility@android.com

สารบัญ

1. บทนำ
2. ทรัพยากร
3. ซอฟต์แวร์
3.1. ความเข้ากันได้ของ API ที่มีการจัดการ
3.2. ความเข้ากันได้ของ Soft API
3.3. ความเข้ากันได้ของ Native API
3.4. ความเข้ากันได้ของเว็บ
3.5. ความเข้ากันได้ของพฤติกรรม API
3.6. เนมสเปซ API
3.7. ความเข้ากันได้ของเครื่องเสมือน
3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
4. ความเข้ากันได้ของซอฟต์แวร์อ้างอิง
5. ความเข้ากันได้ของบรรจุภัณฑ์แอปพลิเคชัน
6. ความเข้ากันได้ของมัลติมีเดีย
7. ความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนา
8. ความเข้ากันได้ของฮาร์ดแวร์
8.1. แสดง
8.2. แป้นพิมพ์
8.3. การนำทางแบบไม่สัมผัส
8.4. การวางแนวหน้าจอ
8.5. อินพุตหน้าจอสัมผัส
8.6. ยูเอสบี
8.7. ปุ่มนำทาง
8.8. เครือข่ายข้อมูลไร้สาย
8.9. กล้อง
8.10. มาตรความเร่ง
8.11. เข็มทิศ
8.12. จีพีเอส
8.13. โทรศัพท์
8.14. หน่วยความจำและที่เก็บข้อมูล
8.15. แอปพลิเคชันที่เก็บข้อมูลที่ใช้ร่วมกัน
8.16. บลูทู ธ
9. ความเข้ากันได้ของประสิทธิภาพ
10. ความเข้ากันได้ของรุ่นความปลอดภัย
11. ชุดทดสอบความเข้ากันได้
12. ซอฟต์แวร์ที่อัพเดตได้
13. ติดต่อเรา
ภาคผนวก A - ขั้นตอนการทดสอบบลูทูธ

1. บทนำ

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

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

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

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

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

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

2. ทรัพยากร

  1. ระดับความต้องการ IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. ภาพรวมโปรแกรมความเข้ากันได้ของ Android: http://source.android.com/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/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. วอลเปเปอร์เคลื่อนไหว: http://developer.android.com/resources/articles/live-wallpapers.html
  18. แอปสำหรับ Android: http://code.google.com/p/apps-for-android
  19. เอกสารประกอบเครื่องมืออ้างอิง (สำหรับ adb, aapt, ddms): http://developer.android.com/guide/develping/tools/index.html
  20. คำอธิบายไฟล์ Android apk: http://developer.android.com/guide/topics/fundamentals.html
  21. ไฟล์มานิเฟสต์: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. เครื่องมือทดสอบลิง: http://developer.android.com/guide/developer/tools/monkey.html
  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 (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 APIs รวมค่าคงที่จำนวนหนึ่งบนคลาส android.os.Build [ Resources, 6 ] ที่มีจุดประสงค์เพื่ออธิบายอุปกรณ์ปัจจุบัน เพื่อให้ค่าที่สอดคล้องกันและมีความหมายในการใช้งานอุปกรณ์ต่างๆ ตารางด้านล่างมีข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ซึ่งการใช้งานอุปกรณ์ต้องสอดคล้อง

พารามิเตอร์ ความคิดเห็น
android.os.Build.VERSION.RELEASE เวอร์ชันของระบบ Android ที่กำลังทำงานอยู่ในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้ต้องมีหนึ่งในค่าสตริงที่กำหนดไว้ใน [ Resources, 7 ]
android.os.Build.VERSION.SDK เวอร์ชันของระบบ Android ที่กำลังดำเนินการอยู่ ในรูปแบบที่โค้ดแอปพลิเคชันบุคคลที่สามเข้าถึงได้ สำหรับ Android 2.2 ช่องนี้ต้องมีค่าจำนวนเต็ม 8
android.os.Build.VERSION.INCREMENTAL ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งกำหนดบิลด์เฉพาะของระบบ Android ที่กำลังดำเนินการอยู่ ในรูปแบบที่มนุษย์อ่านได้ ค่านี้ต้องไม่ใช้ซ้ำสำหรับบิลด์ต่างๆ ที่มีให้สำหรับผู้ใช้ปลายทาง การใช้งานทั่วไปของฟิลด์นี้คือเพื่อระบุว่าหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาใดที่ใช้ในการสร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.BOARD ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในเฉพาะที่ใช้โดยอุปกรณ์ ในรูปแบบที่มนุษย์อ่านได้ การใช้งานที่เป็นไปได้ของฟิลด์นี้คือการระบุการแก้ไขเฉพาะของบอร์ดที่จ่ายไฟให้กับอุปกรณ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.BRAND ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งระบุชื่อบริษัท องค์กร บุคคล ฯลฯ ที่ผลิตอุปกรณ์ ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้เป็นไปได้เพื่อระบุ OEM และ/หรือผู้ให้บริการที่ขายอุปกรณ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.DEVICE ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งระบุการกำหนดค่าหรือการแก้ไขเฉพาะของร่างกาย (บางครั้งเรียกว่า "การออกแบบทางอุตสาหกรรม") ของอุปกรณ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.FINGERPRINT สตริงที่ระบุบิลด์นี้โดยเฉพาะ มันควรจะมีเหตุผลพอสมควรที่มนุษย์สามารถอ่านได้ ต้องเป็นไปตามเทมเพลตนี้:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
ตัวอย่างเช่น:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
ลายนิ้วมือต้องไม่มีอักขระเว้นวรรค หากฟิลด์อื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมีอักขระเว้นวรรค จะต้องแทนที่ฟิลด์เหล่านี้ในลายนิ้วมือของบิวด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_")
android.os.Build.HOST สตริงที่ระบุโฮสต์ที่สร้างบิลด์โดยไม่ซ้ำกัน ในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.ID ตัวระบุที่เลือกโดยผู้ดำเนินการอุปกรณ์เพื่ออ้างถึงรุ่นที่เฉพาะเจาะจง ในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกแยะระหว่างการสร้างซอฟต์แวร์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.MODEL ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางรู้จัก ชื่อนี้ควรเป็นชื่อเดียวกับที่ใช้วางตลาดและขายอุปกรณ์ให้กับผู้ใช้ปลายทาง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.PRODUCT ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อรหัสของอุปกรณ์ ต้องสามารถอ่านได้โดยมนุษย์ แต่ไม่จำเป็นต้องมีจุดประสงค์เพื่อให้ผู้ใช้ปลายทางดูได้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")
android.os.Build.TAGS รายการแท็กที่คั่นด้วยเครื่องหมายจุลภาคซึ่งเลือกโดยผู้ติดตั้งอุปกรณ์เพื่อแยกความแตกต่างของบิลด์ ตัวอย่างเช่น "unsigned,debug" ฟิลด์นี้ต้องไม่เป็นค่าว่างหรือสตริงว่าง ("") แต่แท็กเดียว (เช่น "release") ก็ใช้ได้
android.os.Build.TIME ค่าที่แสดงการประทับเวลาเมื่อบิลด์เกิดขึ้น
android.os.Build.TYPE ค่าที่เลือกโดยผู้ดำเนินการอุปกรณ์ซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ฟิลด์นี้ควรมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android สามค่า: "ผู้ใช้", "userdebug" หรือ "eng"
android.os.Build.USER ชื่อหรือ ID ผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของฟิลด์นี้ ยกเว้นจะต้องไม่เป็นค่าว่างหรือสตริงว่าง ("")

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

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

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

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

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

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

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

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

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

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

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

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

3.3. ความเข้ากันได้ของ Native 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 [ แหล่งข้อมูล 8 ] สำหรับอินเทอร์เฟซผู้ใช้ ดังนั้นการใช้งาน WebView จะต้องเข้ากันได้กับการใช้งาน Android ประสบการณ์การใช้งานเว็บแบบเต็มรูปแบบก็เป็นศูนย์กลางของประสบการณ์ผู้ใช้ Android เช่นเดียวกัน การใช้งานอุปกรณ์ต้องมีเวอร์ชันของ android.webkit.WebView ที่สอดคล้องกับซอฟต์แวร์อัปสตรีม Android และต้องมีเบราว์เซอร์รุ่นใหม่ที่มีความสามารถ HTML5 ตามที่อธิบายไว้ด้านล่าง

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

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

  • การใช้งานอุปกรณ์ android.webkit.WebView ของการใช้งานอุปกรณ์ต้องอิงตาม 533.1 WebKit build จากต้นทางต้นทางของ 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 ตำแหน่งทางภูมิศาสตร์ [ Resources, 9 ] WebView ต้องรองรับแท็ก HTML5 <video> HTML5 APIs เช่นเดียวกับ JavaScript APIs ทั้งหมด ต้องถูกปิดใช้งานโดยค่าเริ่มต้นใน 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 อัปสตรีม [ Resources, 3 ] ความเข้ากันได้เฉพาะบางด้าน ได้แก่ :

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

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

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

3.6. เนมสเปซ API

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

  • จาวา.*
  • javax.*
  • ดวงอาทิตย์.*
  • แอนดรอยด์*
  • 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 [ Resources, 10 ]

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

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

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

3.8.1. วิดเจ็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. ตัวแปลงสัญญาณสื่อ

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

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

เครื่องเสียง
ชื่อ ตัวเข้ารหัส ตัวถอดรหัส รายละเอียด รูปแบบไฟล์/คอนเทนเนอร์
AAC LC/LTP X เนื้อหาโมโน/สเตอริโอในการผสมผสานระหว่างอัตราบิตมาตรฐานสูงสุด 160 kbps และอัตราการสุ่มตัวอย่างระหว่าง 8 ถึง 48kHz 3GPP (.3gp) และ MPEG-4 (.mp4, .m4a) ไม่รองรับ AAC แบบดิบ (.aac)
HE-AACv1 (AAC+) X
HE-AACv2 (ปรับปรุง AAC+) X
AMR-NB X X ตัวอย่าง 4.75 ถึง 12.2 kbps ที่ 8kHz 3GPP (.3gp)
AMR-WB X 9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s สุ่มตัวอย่าง @ 16kHz 3GPP (.3gp)
MP3 X โมโน/สเตอริโอ 8-320Kbps คงที่ (CBR) หรือบิตเรทแปรผัน (VBR) MP3 (.mp3)
MIDI X MIDI Type 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody พิมพ์ 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx), OTA (.ota) และ iMelody (.imy) ด้วย
Ogg Vorbis X Ogg (.ogg)
PCM X PCM เชิงเส้น 8 และ 16 บิต (อัตราสูงสุดที่จำกัดของฮาร์ดแวร์) เวฟ (.wav)
ภาพ
JPEG X X เบส+โปรเกรสซีฟ
GIF X
PNG X X
BMP X
วีดีโอ
H.263 X X ไฟล์ 3GPP (.3gp)
H.264 X ไฟล์ 3GPP (.3gp) และ MPEG-4 (.mp4)
MPEG4 Simple Profile X ไฟล์ 3GPP (.3gp)

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

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

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

  • การประมวลผลการลดสัญญาณรบกวน หากมี ควรปิดใช้งาน
  • การควบคุมการขยายอัตโนมัติ หากมี ควรปิดใช้งาน
  • อุปกรณ์ควรแสดงแอมพลิจูดแบนราบโดยประมาณเมื่อเทียบกับลักษณะความถี่ โดยเฉพาะ ±3 dB จาก 100 Hz ถึง 4000 Hz
  • ควรตั้งค่าความไวของสัญญาณเสียงเข้าโดยให้แหล่งกำเนิดเสียงระดับพลังงานเสียง 90 dB (SPL) ที่ 1000 Hz ให้ RMS 5000 สำหรับตัวอย่าง 16 บิต
  • ระดับแอมพลิจูดของ PCM ควรติดตามการเปลี่ยนแปลง SPL อินพุตเชิงเส้นในช่วงอย่างน้อย 30 dB จาก -18 dB ถึง +12 dB อีกครั้ง 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 การใช้งานอุปกรณ์ควรเป็นไปตามข้อกำหนดเวลาในการตอบสนองของเสียงที่ระบุไว้ในส่วนนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. แสดง

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

สำหรับ Android 2.2 นี่คือการกำหนดค่าการแสดงผลทั่วไปส่วนใหญ่:

ประเภทหน้าจอ ความกว้าง (พิกเซล) ความสูง (พิกเซล) ช่วงความยาวแนวทแยง (นิ้ว) กลุ่มขนาดหน้าจอ กลุ่มความหนาแน่นของหน้าจอ
QVGA 240 320 2.6 - 3.0 เล็ก ต่ำ
WQVGA 240 400 3.2 - 3.5 ปกติ ต่ำ
FWQVGA 240 432 3.5 - 3.8 ปกติ ต่ำ
HVGA 320 480 3.0 - 3.5 ปกติ ปานกลาง
WVGA 480 800 3.3 - 4.0 ปกติ สูง
FWVGA 480 854 3.5 - 4.0 ปกติ สูง
WVGA 480 800 4.8 - 5.5 ใหญ่ ปานกลาง
FWVGA 480 854 5.0 - 5.8 ใหญ่ ปานกลาง

การใช้งานอุปกรณ์ที่สอดคล้องกับการกำหนดค่ามาตรฐานอย่างใดอย่างหนึ่งข้างต้น ต้องได้รับการกำหนดค่าให้รายงานขนาดหน้าจอที่ระบุไปยังแอปพลิเคชันผ่านคลาส android.content.res.Configuration [ Resources, 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 [ Resources, 26 ]

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

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

8.2. แป้นพิมพ์

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

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

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

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

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

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

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

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

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

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

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

8.6. ยูเอสบี

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

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

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 วัตถุ โปรดทราบว่าข้อจำกัดนี้ใช้ไม่ได้กับแอปพลิเคชันกล้องระบบในตัวของอุปกรณ์ แต่เฉพาะกับแอปพลิเคชันของบุคคลที่สามที่ใช้ 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 ต้องเป็นค่าเริ่มต้น

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

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

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

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

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

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

8.16. บลูทู ธ

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

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

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

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

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

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

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

10.1. สิทธิ์

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

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

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

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

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

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

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

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

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

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

รันไทม์สำรองต้องเป็นไปตามโมเดลแซนด์บ็อกซ์ของ Android โดยเฉพาะ:

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

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

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

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

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

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

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

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

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

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

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

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

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

13. ติดต่อเรา

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

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

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

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

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

ขั้นตอนการทดสอบด้านล่างหมายถึงอุปกรณ์เหล่านี้เป็นอุปกรณ์ "ผู้สมัคร" และ "อุปกรณ์ที่รู้จัก" ตามลำดับ

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

  1. สร้าง BluetoothChat.apk ผ่าน 'สร้างตัวอย่าง' จากแผนผังซอร์สโค้ดของ Android
  2. ติดตั้ง BluetoothChat.apk บนอุปกรณ์ที่รู้จัก
  3. ติดตั้ง BluetoothChat.apk บนอุปกรณ์ของผู้สมัคร

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

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

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

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