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

1. บทนำ

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

การใช้คำว่า “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” และ “OPTIONAL” เป็นไปตาม IETF มาตรฐานที่กำหนดใน RFC2119 [ ทรัพยากร, 1 ]

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

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

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

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

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

2. ประเภทอุปกรณ์

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

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

• ต้องมีหน้าจอสัมผัสฝังอยู่ในอุปกรณ์
• ต้องมีแหล่งพลังงานที่ช่วยให้เคลื่อนที่ได้ เช่น แบตเตอรี่

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

• ต้องมีหน้าจอแบบฝัง หรือมีพอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI หรือพอร์ตไร้สายสำหรับการแสดงผล
• ต้องประกาศคุณสมบัติ android.software.leanback และ android.hardware.type.television [ แหล่งข้อมูล, 3 ]

อุปกรณ์ Android Watch หมายถึงการใช้งานอุปกรณ์ Android ที่มีจุดประสงค์เพื่อสวมใส่บนร่างกายหรือบนข้อมือ และ:

• ต้องมีหน้าจอที่มีความยาวเส้นทแยงมุมอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
• ต้องประกาศคุณลักษณะ android.hardware.type.watch
• ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH [ ทรัพยากร 4 ]

การใช้งาน Android Automotive หมายถึงเครื่องเสียงรถยนต์ที่ใช้ Android เป็นระบบปฏิบัติการสำหรับฟังก์ชันระบบและ/หรือความบันเทิงบางส่วนหรือทั้งหมด การใช้งานยานยนต์ของ Android ต้องรองรับ uiMode = UI_MODE_TYPE_CAR [ แหล่งข้อมูล, 111 ]

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

2.1 การกำหนดค่าอุปกรณ์

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

3. ซอฟต์แวร์

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

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

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

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

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

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

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

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

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

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

อย่างไรก็ตาม การใช้งานอุปกรณ์อาจมีกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) หากกิจกรรมเริ่มต้นมีตัวกรอง URI ข้อมูลที่เฉพาะเจาะจงมากขึ้น ตัวอย่างเช่น ตัวกรองเจตนาที่ระบุ URI ข้อมูล “http://www.android.com” มีความเฉพาะเจาะจงมากกว่าตัวกรองเบราว์เซอร์สำหรับ “http://” การใช้งานอุปกรณ์จะต้องมีส่วนต่อประสานกับผู้ใช้สำหรับผู้ใช้เพื่อแก้ไขกิจกรรมเริ่มต้นสำหรับเจตนา

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

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

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

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

3.2.3.5. การตั้งค่าแอพเริ่มต้น

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

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

• ต้องปฏิบัติตามเจตนารมณ์ของ android.settings.HOME_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก หากการใช้งานอุปกรณ์รายงาน android.software.home_screen [ แหล่งข้อมูล 10]
• ต้องจัดเตรียมเมนูการตั้งค่าที่จะเรียกจุดประสงค์ android.provider.Telephony.ACTION_CHANGE_DEFAULT เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น หากการใช้งานอุปกรณ์รายงาน android.hardware.telephony [ แหล่งข้อมูล, 9 ]
• ต้องปฏิบัติตามเจตนารมณ์ของ android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับ Tap and Pay หากการใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce [ แหล่งข้อมูล, 10]

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

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

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

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

• ต้องมีการสนับสนุนโค้ดที่ทำงานในสภาพแวดล้อมที่ได้รับการจัดการเพื่อเรียกใช้โค้ดเนทีฟ โดยใช้ซีแมนทิกส์ Java Native Interface (JNI) มาตรฐาน
• จะต้องเข้ากันได้กับแหล่งที่มา (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) โดยแต่ละไลบรารีที่จำเป็นในรายการด้านล่าง
• ต้องรองรับ ABI 32 บิตที่เทียบเท่าหากรองรับ ABI 64 บิตใดๆ
• ต้องรายงาน Application Binary Interface (ABI) ดั้งเดิมที่อุปกรณ์รองรับอย่างถูกต้องผ่านพารามิเตอร์ android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS และ android.os.Build.SUPPORTED_64_BIT_ABIS โดยแต่ละรายการคั่นด้วยเครื่องหมายจุลภาคของ ABI เรียงลำดับจากที่ต้องการมากที่สุดไปน้อยที่สุด
• ต้องรายงานผ่านพารามิเตอร์ข้างต้น เฉพาะ ABI ที่ได้รับการบันทึกไว้ใน Android NDK เวอร์ชันล่าสุด “คู่มือโปรแกรมเมอร์ NDK | การจัดการ ABI” ใน docs/ ไดเร็กทอรี
• ควรสร้างขึ้นโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในอัปสตรีม Android Open Source Project

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

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

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

โปรดทราบว่าการใช้งานอุปกรณ์ต้องมี libGLESv3.so และต้องมีการเชื่อมโยง (ลิงก์สัญลักษณ์) ไปยัง libGLESv2.so ในทางกลับกัน จะต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack [ Resources, 11 ] ทั้งหมดตามที่กำหนดไว้ใน NDK release android-21 แม้ว่าจะต้องมีสัญลักษณ์ทั้งหมดอยู่ แต่จะต้องใช้งานเฉพาะฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชัน OpenGL ES และส่วนขยายที่อุปกรณ์รองรับจริงเท่านั้นจึงจะถูกนำมาใช้อย่างสมบูรณ์

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

3.3.2. ความเข้ากันได้ของโค้ดเนทิฟ ARM 32 บิต

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

• คำแนะนำ SWP และ SWPB
• คำสั่ง SETEND
• การดำเนินการกั้น CP15ISB, CP15DSB และ CP15DMB

Android NDK เวอร์ชันเก่าใช้ /proc/cpuinfo เพื่อค้นหาคุณสมบัติของ CPU จากโค้ดเนทิฟ ARM 32 บิต เพื่อให้เข้ากันได้กับแอปพลิเคชันที่สร้างโดยใช้ NDK นี้ อุปกรณ์ต้องมีบรรทัดต่อไปนี้ใน /proc/cpuinfo เมื่ออ่านโดยแอปพลิเคชัน ARM 32 บิต:

• "คุณสมบัติ: " ตามด้วยรายการคุณสมบัติเสริมของ CPU ARMv7 ที่อุปกรณ์รองรับ
• "สถาปัตยกรรม CPU: " ตามด้วยจำนวนเต็มซึ่งอธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)

ข้อกำหนดเหล่านี้ใช้เฉพาะเมื่อ /proc/cpuinfo ถูกอ่านโดยแอปพลิเคชัน ARM 32 บิต อุปกรณ์ไม่ควรแก้ไข /proc/cpuinfo เมื่ออ่านโดย ARM 64 บิตหรือแอปพลิเคชันที่ไม่ใช่ ARM

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

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

คุณลักษณะแพลตฟอร์ม android.software.webview จะต้องรายงานบนอุปกรณ์ใดๆ ที่มีการปรับใช้ android.webkit.WebView API โดยสมบูรณ์ และจะต้องไม่ถูกรายงานบนอุปกรณ์ที่ไม่มีการใช้งาน API โดยสมบูรณ์ การใช้งาน Android Open Source ใช้โค้ดจาก Chromium Project เพื่อใช้งาน android.webkit.WebView [ Resources, 12 ] เนื่องจากเป็นไปไม่ได้ที่จะพัฒนาชุดทดสอบที่ครอบคลุมสำหรับระบบการเรนเดอร์เว็บ ผู้ติดตั้งอุปกรณ์จึงต้องใช้ Chromium บิวด์อัพสตรีมเฉพาะในการใช้งาน WebView โดยเฉพาะ:

• การใช้งานอุปกรณ์ android.webkit.WebView ต้องขึ้นอยู่กับ Chromium build จากโครงการ Android Open Source อัปสตรีมสำหรับ Android 5.1 โครงสร้างนี้ประกอบด้วยชุดฟังก์ชันการทำงานและการแก้ไขความปลอดภัยเฉพาะสำหรับ WebView [ แหล่งข้อมูล, 13 ]
• สตริงตัวแทนผู้ใช้ที่รายงานโดย WebView ต้องอยู่ในรูปแบบนี้:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML เช่น Gecko) เวอร์ชัน/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • ค่าของสตริง $(VERSION) จะต้องเหมือนกับค่าสำหรับ android.os.Build.VERSION.RELEASE
  • อาจละเว้นสตริง $(WEBVIEW) ได้ แต่ถ้ารวมไว้ต้องเป็น "; wv" โปรดทราบว่านี่คือ webview
  • ค่าของสตริง $(MODEL) จะต้องเหมือนกับค่าสำหรับ android.os.Build.MODEL
  • ค่าของสตริง $(BUILD) จะต้องเหมือนกับค่าสำหรับ android.os.Build.ID
  • ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในอัปสตรีม Android Open Source Project
  • การใช้งานอุปกรณ์อาจละเว้นอุปกรณ์เคลื่อนที่ในสตริงตัวแทนผู้ใช้

คอมโพเนนต์ WebView ควรรวมการรองรับฟีเจอร์ HTML5 ให้ได้มากที่สุด และหากรองรับฟีเจอร์นั้นควรเป็นไปตามข้อกำหนด HTML5 [ แหล่งข้อมูล, 14 ]

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

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

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

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

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

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

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

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

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

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

3.6. เนมสเปซ API

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

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

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

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

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

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

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

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

3.7. ความเข้ากันได้รันไทม์

การใช้งานอุปกรณ์ต้องรองรับรูปแบบ Dalvik Executable (DEX) เต็มรูปแบบ และข้อกำหนดรหัสไบต์ Dalvik และซีแมนทิกส์ [ แหล่งข้อมูล, 20 ] ผู้ใช้อุปกรณ์ควรใช้ ART การใช้งานอัปสตรีมอ้างอิงของรูปแบบปฏิบัติการ Dalvik และระบบการจัดการแพ็คเกจของการใช้งานอ้างอิง

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

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

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

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

Android มีแอปพลิเคชันตัวเรียกใช้งาน (หน้าจอหลัก) และการสนับสนุนแอปพลิเคชันบุคคลที่สามเพื่อแทนที่ตัวเรียกใช้งานอุปกรณ์ (หน้าจอหลัก) การใช้งานอุปกรณ์ที่อนุญาตให้แอปพลิเคชันบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์จะต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.home_screen

3.8.2. วิดเจ็ต

Android กำหนดประเภทส่วนประกอบและ API ที่เกี่ยวข้องและวงจรการใช้งานที่ช่วยให้แอปพลิเคชันเปิดเผย "AppWidget" แก่ผู้ใช้ปลายทาง [ แหล่งข้อมูล 21 ] ซึ่งเป็นคุณลักษณะที่ได้รับการแนะนำอย่างยิ่งให้ได้รับการสนับสนุนในการใช้งานอุปกรณ์มือถือ การใช้งานอุปกรณ์ที่รองรับการฝังวิดเจ็ตบนหน้าจอหลักต้องเป็นไปตามข้อกำหนดต่อไปนี้ และประกาศการสนับสนุนสำหรับคุณลักษณะแพลตฟอร์ม android.software.app_widgets

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

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

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

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

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

Android รองรับการแจ้งเตือนต่างๆ เช่น:

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

การใช้งานอุปกรณ์ Android เมื่อแสดงการแจ้งเตือนดังกล่าว จะต้องดำเนินการการแจ้งเตือน Rich และ Heads-up อย่างถูกต้อง และรวมถึงชื่อ/ชื่อ ไอคอน ข้อความตามที่บันทึกไว้ใน Android APIs [แหล่งข้อมูล, 25]

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

3.8.4. ค้นหา

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

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

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

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

3.8.6. ธีมส์

Android จัดเตรียม "ธีม" ให้เป็นกลไกสำหรับแอปพลิเคชันเพื่อใช้สไตล์กับกิจกรรมหรือแอปพลิเคชันทั้งหมด

Android มีกลุ่มธีม “Holo” เป็นชุดรูปแบบที่กำหนดไว้สำหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีม Holo ตามที่กำหนดโดย Android SDK [ แหล่งข้อมูล, 28 ] การใช้งานอุปกรณ์จะต้องไม่เปลี่ยนแปลงคุณลักษณะธีม Holo ใด ๆ ที่เปิดเผยต่อแอปพลิเคชัน [ แหล่งข้อมูล, 29 ]

Android มีกลุ่มธีม "Material" เป็นชุดรูปแบบที่กำหนดไว้สำหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการให้เข้ากับรูปลักษณ์ของธีมการออกแบบในอุปกรณ์ Android ประเภทต่างๆ ที่หลากหลาย การใช้งานอุปกรณ์ต้องรองรับกลุ่มธีม “Material” และต้องไม่เปลี่ยนแปลงแอตทริบิวต์ของธีม Material ใดๆ หรือทรัพย์สินที่เปิดเผยต่อแอปพลิเคชัน [ แหล่งข้อมูล, 30 ]

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

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

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

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

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

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

3.8.8. การสลับกิจกรรม

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

• ต้องแสดงข้อมูลล่าสุดในเครือเป็นกลุ่มที่เคลื่อนไหวร่วมกัน
• ต้องรองรับกิจกรรมที่แสดงอย่างน้อยสูงสุด 20 กิจกรรม
• อย่างน้อยควรแสดงชื่อกิจกรรม 4 กิจกรรมพร้อมกัน
• ควรแสดงสีไฮไลต์ ไอคอน ชื่อหน้าจอในช่วงล่าสุด
• ต้องใช้พฤติกรรมการปักหมุดหน้าจอ [ แหล่งข้อมูล 33 ] และจัดเตรียมเมนูการตั้งค่าให้กับผู้ใช้เพื่อสลับคุณสมบัติ
• ควรแสดงการจ่ายปิด ("x") แต่อาจเลื่อนออกไปจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ

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

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

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

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

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

Remote Control Client API เลิกใช้งานจาก Android 5.0 แทนเทมเพลตการแจ้งเตือนสื่อที่อนุญาตให้แอปพลิเคชันสื่อรวมเข้ากับการควบคุมการเล่นที่แสดงบนหน้าจอล็อค [ แหล่งข้อมูล, 35 ] การใช้งานอุปกรณ์ที่รองรับหน้าจอล็อค เว้นแต่การใช้งาน Android Automotive หรือ Watch จะต้องแสดงการแจ้งเตือนหน้าจอล็อค รวมถึงเทมเพลตการแจ้งเตือนสื่อ

3.8.11. ความฝัน

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

3.8.12. ที่ตั้ง

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

3.8.13. ยูนิโค้ดและฟอนต์

Android รองรับอักขระอิโมจิสีด้วย เมื่อการใช้งานอุปกรณ์ Android มี IME อุปกรณ์ควรจัดเตรียมวิธีการป้อนข้อมูลให้กับผู้ใช้สำหรับอักขระ Emoji ที่กำหนดใน Unicode 6.1 [ แหล่งข้อมูล, 38 ] อุปกรณ์ทั้งหมดต้องสามารถแสดงอักขระอิโมจิเหล่านี้เป็นสัญลักษณ์สีได้

Android มีการรองรับแบบอักษร Roboto 2 ที่มีน้ำหนักต่างกัน ได้แก่ sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light ซึ่ง ต้องรวมไว้ทั้งหมดสำหรับภาษาที่มีอยู่ในอุปกรณ์และการครอบคลุม Unicode 7.0 เต็มรูปแบบสำหรับละติน กรีก และซิริลลิก รวมถึงช่วงละตินขยาย A, B, C และ D และสัญลักษณ์ทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0

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

Android มีคุณลักษณะที่อนุญาตให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยทำหน้าที่การดูแลระบบอุปกรณ์ในระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือการดำเนินการล้างข้อมูลจากระยะไกล ผ่านทาง API การดูแลระบบอุปกรณ์ Android [ แหล่งข้อมูล 39 ] การใช้งานอุปกรณ์จะต้องมีการใช้งานคลาส DevicePolicyManager [ Resources, 40 ] การใช้งานอุปกรณ์ที่รองรับหน้าจอล็อกด้วย PIN (ตัวเลข) หรือรหัสผ่าน (ตัวอักษรและตัวเลข) ต้องรองรับนโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสารประกอบ Android SDK [ แหล่งข้อมูล 39 ] และรายงานฟีเจอร์แพลตฟอร์ม android.software.device_admin

การใช้งานอุปกรณ์อาจมีแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งทำหน้าที่ดูแลอุปกรณ์ แต่แอปพลิเคชันนี้ต้องไม่ถูกกำหนดให้เป็นแอปเจ้าของอุปกรณ์เริ่มต้น [ ทรัพยากร, 41 ]

3.10. การเข้าถึง

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

การใช้งานอุปกรณ์มีข้อกำหนดต่อไปนี้:

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

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

3.11. ข้อความเป็นคำพูด

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

การใช้งานยานยนต์ Android:

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

การใช้งานอุปกรณ์อื่นๆ ทั้งหมด:

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

3.12. กรอบอินพุตทีวี

Android Television Input Framework (TIF) ช่วยลดความยุ่งยากในการส่งเนื้อหาสดไปยังอุปกรณ์ Android Television TIF จัดเตรียม API มาตรฐานเพื่อสร้างโมดูลอินพุตที่ควบคุมอุปกรณ์ Android Television การใช้งานอุปกรณ์โทรทัศน์ Android ต้องรองรับ Television Input Framework [ แหล่งข้อมูล, 46 ]

การใช้งานอุปกรณ์ที่รองรับ TIF ต้องประกาศคุณสมบัติแพลตฟอร์ม android.software.live_tv

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

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

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

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

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

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

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

5.1.1. ตัวแปลงสัญญาณเสียง

1 จำเป็นสำหรับการใช้งานอุปกรณ์ที่กำหนด android.hardware.microphone แต่เป็นทางเลือกสำหรับการใช้งานอุปกรณ์ Android Watch

2 ต้องการดาวน์มิกซ์เนื้อหา 5.0/5.1 เท่านั้น การบันทึกหรือการเรนเดอร์มากกว่า 2 ช่องเป็นทางเลือก

3 จำเป็นสำหรับการใช้งานอุปกรณ์มือถือ Android

4 จำเป็นสำหรับการใช้งานอุปกรณ์ที่กำหนด android.hardware.microphone รวมถึงการใช้งานอุปกรณ์ Android Watch

5.1.2. ตัวแปลงสัญญาณภาพ

5.1.3. ตัวแปลงสัญญาณวิดีโอ

ตัวแปลงสัญญาณวิดีโอเป็นทางเลือกสำหรับการใช้งานอุปกรณ์ Android Watch

1 จำเป็นสำหรับการใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้องและกำหนด android.hardware.cam หรือ android.hardware.camera.front

2 จำเป็นสำหรับการใช้งานอุปกรณ์ ยกเว้นอุปกรณ์ Android Watch

3 เพื่อคุณภาพที่ยอมรับได้ของบริการสตรีมมิ่งวิดีโอบนเว็บและการประชุมทางวิดีโอ การใช้งานอุปกรณ์ควรใช้ตัวแปลงสัญญาณ VP8 ของฮาร์ดแวร์ที่ตรงตามข้อกำหนดใน [ แหล่งข้อมูล 51 ]

4 การใช้งานอุปกรณ์ควรรองรับการเขียนไฟล์ Matroska WebM

5 ขอแนะนำอย่างยิ่งสำหรับ Android Automotive, ตัวเลือกเสริมสำหรับ Android Watch และจำเป็นสำหรับอุปกรณ์ประเภทอื่นๆ ทั้งหมด

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

การใช้งานอุปกรณ์ Android ที่รองรับตัวแปลงสัญญาณ H.264 ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 และโปรไฟล์การเข้ารหัสวิดีโอ SD (ความคมชัดมาตรฐาน) ต่อไปนี้ และควรรองรับโปรไฟล์หลักระดับ 4 และโปรไฟล์การเข้ารหัสวิดีโอ HD (ความคมชัดสูง) ต่อไปนี้ ขอแนะนำอย่างยิ่งให้อุปกรณ์โทรทัศน์ Android เข้ารหัสวิดีโอ HD 1080p ที่ 30 fps

1 เมื่อรองรับโดยฮาร์ดแวร์ แต่แนะนำอย่างยิ่งสำหรับอุปกรณ์ Android Television

การใช้งานอุปกรณ์ Android ที่รองรับตัวแปลงสัญญาณ VP8 ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD และควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความคมชัดสูง) ต่อไปนี้

1 เมื่อได้รับการสนับสนุนโดยฮาร์ดแวร์

5.3. การถอดรหัสวิดีโอ

การใช้งานอุปกรณ์ต้องรองรับการสลับความละเอียดวิดีโอแบบไดนามิกภายในสตรีมเดียวกันสำหรับตัวแปลงสัญญาณ VP8, VP9, ​​H.264 และ H.265 ทั้งหมดที่เปิดเผยต่อนักพัฒนาผ่าน API ของ Android มาตรฐาน

การใช้งานอุปกรณ์ Android ที่มีตัวถอดรหัส H.264 ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 และโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD อุปกรณ์โทรทัศน์ Android ต้องรองรับ High Profile Level 4.2 และโปรไฟล์การถอดรหัส HD 1080p

1 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นเมื่อฮาร์ดแวร์รองรับเท่านั้น

2 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television

การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงสัญญาณ VP8 ตามที่อธิบายไว้ใน ส่วน 5.1.3 ต้องรองรับโปรไฟล์การถอดรหัส SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD อุปกรณ์โทรทัศน์ Android ต้องรองรับโปรไฟล์การถอดรหัส HD 1080p

1 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นเมื่อฮาร์ดแวร์รองรับเท่านั้น

2 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television

การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงสัญญาณ VP9 ตามที่อธิบายไว้ใน ส่วน 5.1.3 ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD ขอแนะนำอย่างยิ่งให้อุปกรณ์โทรทัศน์ Android รองรับโปรไฟล์การถอดรหัส HD 1080p และควรรองรับโปรไฟล์การถอดรหัส UHD เมื่อรองรับโปรไฟล์การถอดรหัสวิดีโอ UHD จะต้องรองรับความลึกของสี 8 บิต

1 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นเมื่อฮาร์ดแวร์รองรับเท่านั้น

2 แนะนำอย่างยิ่งสำหรับการใช้งานอุปกรณ์ Android Television เมื่อฮาร์ดแวร์รองรับ

การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงสัญญาณ H.265 ตามที่อธิบายไว้ใน ส่วน 5.1.3 ต้องรองรับโปรไฟล์หลักระดับ 3 ระดับหลักและโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD อุปกรณ์โทรทัศน์ Android ควรรองรับโปรไฟล์ Main10 ระดับ 5 Main Tier และโปรไฟล์การถอดรหัส UHD ขอแนะนำอุปกรณ์โทรทัศน์ Android อย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD 1080p หากรองรับโปรไฟล์ถอดรหัส HD 1080p จะต้องรองรับโปรไฟล์หลักระดับ 4.1 ระดับหลัก

1 จำเป็นสำหรับการใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นเมื่อฮาร์ดแวร์รองรับเท่านั้น

2 แนะนำอย่างยิ่งสำหรับการใช้งานอุปกรณ์ Android Television เมื่อฮาร์ดแวร์รองรับ

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

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

5.4.1. บันทึกเสียงดิบ

การใช้งานอุปกรณ์ที่ประกาศ android.hardware.microphone ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะดังต่อไปนี้:

• รูปแบบ : PCM เชิงเส้น 16 บิต
• อัตราการสุ่มตัวอย่าง : 8000, 11025, 16000, 44100
• ช่อง : โมโน

การใช้งานอุปกรณ์ที่ประกาศ android.hardware.microphone ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะดังต่อไปนี้:

• รูปแบบ : PCM เชิงเส้น 16 บิต
• อัตราการสุ่มตัวอย่าง : 22050, 48000
• ช่อง : สเตอริโอ

5.4.2. จับภาพเพื่อการจดจำเสียง

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

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

หากแพลตฟอร์มรองรับเทคโนโลยีการลดเสียงรบกวนที่ปรับแต่งเพื่อการรู้จำเสียง เอฟเฟกต์จะต้องสามารถควบคุมได้จาก android.media.audiofx.NoiseSuppressor API นอกจากนี้ ฟิลด์ UUID สำหรับตัวอธิบายเอฟเฟกต์ของตัวลดเสียงรบกวนจะต้องระบุการใช้งานเทคโนโลยีลดเสียงรบกวนแต่ละครั้งโดยไม่ซ้ำกัน

5.4.3. จับภาพเพื่อกำหนดเส้นทางการเล่นใหม่

คลาส android.media.MediaRecorder.AudioSource มีแหล่งกำเนิดเสียง REMOTE_SUBMIX อุปกรณ์ที่ประกาศ android.hardware.audio.output ต้องใช้แหล่งกำเนิดเสียง REMOTE_SUBMIX อย่างถูกต้อง เพื่อว่าเมื่อแอปพลิเคชันใช้ android.media.AudioRecord API เพื่อบันทึกจากแหล่งกำเนิดเสียงนี้ แอปพลิเคชันจะสามารถจับการผสมผสานของสตรีมเสียงทั้งหมด ยกเว้นสิ่งต่อไปนี้ : :

• สตรีม_ริง
• สตรีม_สัญญาณเตือน
• สตรีม_การแจ้งเตือน

5.5. การเล่นเสียง

การใช้งานอุปกรณ์ที่ประกาศ android.hardware.audio.output ต้องเป็นไปตามข้อกำหนดในส่วนนี้

5.5.1. การเล่นเสียงดิบ

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

• รูปแบบ : PCM เชิงเส้น 16 บิต
• อัตราการสุ่มตัวอย่าง : 8000, 11025, 16000, 22050, 32000, 44100
• ช่อง : โมโน, สเตอริโอ

อุปกรณ์ควรอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีคุณสมบัติดังต่อไปนี้:

• อัตราการสุ่มตัวอย่าง : 24000, 48000

5.5.2. เอฟเฟกต์เสียง

Android จัดเตรียม API สำหรับเอฟเฟกต์เสียงสำหรับการใช้งานอุปกรณ์ [ แหล่งข้อมูล, 52 ] การใช้งานอุปกรณ์ที่ประกาศคุณลักษณะ android.hardware.audio.output:

• ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่สามารถควบคุมผ่านคลาสย่อย AudioEffect Equalizer, LoudnessEnhancer
• ต้องรองรับการใช้งาน Visualizer API ซึ่งสามารถควบคุมได้ผ่านคลาส Visualizer
• ควรสนับสนุนการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่สามารถควบคุมผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer

5.5.3. ระดับเสียงเอาต์พุตเสียง

การใช้งานอุปกรณ์ Android Television จะต้องรองรับระบบ Master Volume และการลดทอนระดับเสียงเอาต์พุตเสียงดิจิทัลบนเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตพาสทรูเสียงที่ถูกบีบอัด (โดยที่ไม่มีการถอดรหัสเสียงบนอุปกรณ์)

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

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

เพื่อวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้:

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

การใช้งานอุปกรณ์ที่ประกาศ android.hardware.audio.output ควรเป็นไปตามหรือเกินกว่าข้อกำหนดเอาต์พุตเสียงเหล่านี้:

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

หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้หลังจากการสอบเทียบเริ่มต้นใดๆ เมื่อใช้ API คิวบัฟเฟอร์ OpenSL ES PCM สำหรับเวลาแฝงเอาต์พุตอย่างต่อเนื่องและเวลาแฝงเอาต์พุตเย็นผ่านอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อยหนึ่งเครื่อง อาจรายงานการสนับสนุนสำหรับเสียงที่มีเวลาแฝงต่ำ โดยการรายงานคุณลักษณะ android.hardware.audio.low_latency ผ่านคลาส android.content.pm.PackageManager [ Resources, 53 ] ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดเหล่านี้ ก็จะต้องไม่รายงานการรองรับเสียงที่มีความหน่วงต่ำ

การใช้งานอุปกรณ์ที่มี android.hardware.microphone ควรเป็นไปตามข้อกำหนดด้านเสียงอินพุตเหล่านี้:

• เวลาแฝงอินพุตเย็น 100 มิลลิวินาทีหรือน้อยกว่า
• เวลาแฝงอินพุตต่อเนื่อง 30 มิลลิวินาทีหรือน้อยกว่า
• เวลาแฝงไปกลับอย่างต่อเนื่อง 50 มิลลิวินาทีหรือน้อยกว่า
• ลดการกระวนกระวายใจอินพุตเย็น

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

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

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

5.8. สื่อที่ปลอดภัย

การใช้งานอุปกรณ์ที่รองรับเอาต์พุตวิดีโอที่ปลอดภัยและสามารถรองรับพื้นผิวที่ปลอดภัยได้ต้องประกาศการรองรับ Display.FLAG_SECURE การใช้งานอุปกรณ์ที่ประกาศรองรับ Display.FLAG_SECURE หากรองรับโปรโตคอลการแสดงผลไร้สาย จะต้องรักษาความปลอดภัยลิงก์ด้วยกลไกการเข้ารหัสที่แข็งแกร่ง เช่น HDCP 2.x หรือสูงกว่าสำหรับจอแสดงผลไร้สาย Miracast ในทำนองเดียวกัน หากรองรับจอแสดงผลภายนอกแบบใช้สาย การใช้งานอุปกรณ์จะต้องรองรับ HDCP 1.2 หรือสูงกว่า การใช้งานอุปกรณ์โทรทัศน์ Android ต้องรองรับ HDCP 2.2 สำหรับอุปกรณ์ที่รองรับความละเอียด 4K และ HDCP 1.4 หรือสูงกว่าสำหรับความละเอียดที่ต่ำกว่า การใช้งานโอเพ่นซอร์ส Android ขั้นต้นนั้นรวมถึงการรองรับจอแสดงผลไร้สาย (Miracast) และแบบมีสาย (HDMI) ที่ตรงตามข้อกำหนดนี้

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

6.1. เครื่องมือสำหรับนักพัฒนา

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

• Android Debug Bridge (adb) [ แหล่งข้อมูล 55 ]

การใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK รวมถึง dumpsys [ Resources, 56 ] adb daemon ฝั่งอุปกรณ์จะต้องปิดใช้งานตามค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge หากการใช้งานอุปกรณ์ละเว้นโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นจะต้องใช้ Android Debug Bridge ผ่านเครือข่ายท้องถิ่น (เช่น อีเธอร์เน็ต หรือ 802.11)

Android มีการรองรับ adb ที่ปลอดภัย Secure adb เปิดใช้งาน adb บนโฮสต์ที่ได้รับการรับรองความถูกต้องที่รู้จัก การใช้งานอุปกรณ์ต้องรองรับ adb ที่ปลอดภัย

• บริการตรวจสอบข้อบกพร่อง Dalvik (ddms) [ แหล่งข้อมูล 57 ]

การใช้งานอุปกรณ์ต้องรองรับคุณสมบัติ ddms ทั้งหมดตามที่บันทึกไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุน ddms ควรปิดใช้งานตามค่าเริ่มต้น แต่จะต้องได้รับการสนับสนุนทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ดังที่กล่าวข้างต้น

• ลิง [ แหล่งข้อมูล, 58 ]

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

• SysTrace [ แหล่งข้อมูล, 59 ]

การใช้งานอุปกรณ์ต้องรองรับเครื่องมือ systrace ตามที่บันทึกไว้ใน Android SDK Systrace จะต้องไม่ใช้งานตามค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace

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

6.2. ตัวเลือกนักพัฒนา

Android รวมถึงการสนับสนุนสำหรับนักพัฒนาเพื่อกำหนดค่าการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอุปกรณ์จะต้องให้เกียรติ Android.settings.application_development_settings ตั้งใจที่จะแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน [ ทรัพยากร, 60 ] การใช้งาน Android อัปสตรีมซ่อนเมนูตัวเลือกนักพัฒนาโดยค่าเริ่มต้นและช่วยให้ผู้ใช้สามารถเปิดตัวเลือกนักพัฒนาได้หลังจากกดเจ็ด (7) ครั้งใน การตั้งค่า > เกี่ยวกับอุปกรณ์ > รายการเมนู หมายเลขสร้าง การใช้งานอุปกรณ์จะต้องให้ประสบการณ์ที่สอดคล้องกันสำหรับตัวเลือกนักพัฒนา โดยเฉพาะการใช้งานอุปกรณ์จะต้องซ่อนตัวเลือกนักพัฒนาโดยค่าเริ่มต้นและต้องจัดเตรียมกลไกเพื่อเปิดใช้งานตัวเลือกนักพัฒนาที่สอดคล้องกับการใช้งาน Android ต้นน้ำ

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

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

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

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

การใช้งานอุปกรณ์จะต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่แม่นยำอย่างต่อเนื่องผ่านวิธี GetSystemAvailableFeatures () และวิธี HassystemFeature (String) บน Android.content.pm.pm.packageManager คลาสสำหรับการสร้างลายนิ้วมือเดียวกัน [ ทรัพยากร, 53]

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

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

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

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

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

7.1.1.1. ขนาดหน้าจอ

เฟรมเวิร์ก Android UI รองรับขนาดหน้าจอที่หลากหลายและอนุญาตให้แอปพลิเคชันสอบถามขนาดหน้าจออุปกรณ์ (หรือที่รู้จัก ตามที่กำหนดไว้ในเอกสารประกอบ Android SDK [ ทรัพยากร, 61 ] และกำหนดโดยแพลตฟอร์ม Android ต้นน้ำโดยเฉพาะการใช้งานอุปกรณ์จะต้องรายงานขนาดหน้าจอที่ถูกต้องตามขนาดหน้าจอ Pixel (DP) ที่มีความหนาแน่นตามตรรกะต่อไปนี้

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

นอกจากนี้,

• อุปกรณ์นาฬิกา Android ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมทางกายภาพในช่วงตั้งแต่ 1.1 ถึง 2.5 นิ้ว
• การใช้งานอุปกรณ์ Android ประเภทอื่น ๆ ที่มีหน้าจอแบบบูรณาการทางกายภาพจะต้องมีหน้าจออย่างน้อย 2.5 นิ้วในขนาดเส้นทแยงมุมทางกายภาพ

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

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

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

อัตราส่วนภาพหน้าจอจะต้องมีค่าจาก 1.3333 (4: 3) ถึง 1.86 (ประมาณ 16: 9) แต่อุปกรณ์ดู Android อาจมีอัตราส่วนภาพที่ 1.0 (1: 1) เนื่องจากการใช้งานอุปกรณ์ดังกล่าวจะใช้ UI_MODE_TYPE_WATCH AS AS Android.content.res.configuration.uimode

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

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

• 120 จุดต่อนิ้ว (ldpi)
• 160 dpi (mdpi)
• 213 จุดต่อนิ้ว (tvdpi)
• 240 จุดต่อนิ้ว (hdpi)
• 280 จุดต่อนิ้ว (280 จุดต่อนิ้ว)
• 320 จุดต่อนิ้ว (xhdpi)
• 400 จุดต่อนิ้ว (400 จุดต่อนิ้ว)
• 480 จุดต่อนิ้ว (xxhdpi)
• 560 จุดต่อนิ้ว (560 จุดต่อนิ้ว)
• 640 จุดต่อนิ้ว (xxxhdpi)

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

7.1.2. เมตริกการแสดงผล

การใช้งานอุปกรณ์จะต้องรายงานค่าที่ถูกต้องสำหรับตัวชี้วัดที่แสดงทั้งหมดที่กำหนดไว้ใน Android.util.displayMetrics [ ทรัพยากร, 62 ] และต้องรายงานค่าเดียวกันโดยไม่คำนึงว่าหน้าจอฝังตัวหรือภายนอกจะใช้เป็นจอแสดงผลเริ่มต้น

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

อุปกรณ์จะต้องรายงานการวางแนวหน้าจอที่พวกเขาสนับสนุน (Android.hardware.screen.portrait และ/หรือ Android.hardware.screen.landscape) และต้องรายงานการวางแนวที่สนับสนุนอย่างน้อยหนึ่งครั้ง ตัวอย่างเช่นอุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่เช่นโทรทัศน์หรือแล็ปท็อปควรรายงานเฉพาะ Android.hardware.screen.landscape

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

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

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

7.1.4. การเร่งความเร็วกราฟิก 2D และ 3D

การใช้งานอุปกรณ์จะต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ซึ่งเป็นตัวเป็นตนและรายละเอียดในเอกสาร Android SDK การใช้งานอุปกรณ์ควรรองรับ OpenGL ES 3.0 หรือ 3.1 บนอุปกรณ์ที่สามารถรองรับได้ การใช้งานอุปกรณ์จะต้องรองรับ Android Renderscript ตามรายละเอียดในเอกสารประกอบ Android SDK [ ทรัพยากร, 63 ]

การใช้งานอุปกรณ์จะต้องระบุตัวเองอย่างถูกต้องว่าสนับสนุน OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 หรือ OpenGL 3.1 นั่นคือ:

• API ที่ได้รับการจัดการ (เช่นผ่านวิธี GLES10.GetString ()) จะต้องรายงานการสนับสนุนสำหรับ OpenGL ES 1.0 และ OpenGL ES 2.0
• Native C/C ++ OpenGL APIs (APIs สำหรับแอพผ่าน LibGles_v1cm.so, libgles_v2.so หรือ libegl.so) ต้องรายงานการสนับสนุนสำหรับ OpenGL ES 1.0 และ OpenGL ES 2.0
• การใช้งานอุปกรณ์ที่ประกาศการสนับสนุนสำหรับ OpenGL ES 3.0 หรือ 3.1 จะต้องสนับสนุน API ที่มีการจัดการที่สอดคล้องกันและรวมถึงการสนับสนุนสำหรับ APIs C/C ++ Native ในการใช้งานอุปกรณ์ที่ประกาศการสนับสนุน OpenGL ES 3.0 หรือ 3.1, Libglesv2.so ต้องส่งออกสัญลักษณ์ฟังก์ชั่นที่เกี่ยวข้องนอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0

นอกเหนือจาก OpenGL ES 3.1 แล้ว Android ยังมีแพ็คส่วนขยายที่มีอินเตอร์เฟส Java [ ทรัพยากร, 64 ] และการสนับสนุนแบบดั้งเดิมสำหรับฟังก์ชั่นกราฟิกขั้นสูงเช่น tessellation และรูปแบบการบีบอัดพื้นผิว ASTC การใช้งานอุปกรณ์ Android อาจรองรับชุดส่วนขยายนี้และ - เพียงอย่างเดียวหากนำไปใช้อย่างเต็มที่ - ระบุการสนับสนุนผ่าน Android.hardware.opengles.aep Feature Flag

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.7. จอแสดงผลรอง

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

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

อุปกรณ์จะต้องรองรับหน้าจอสัมผัสหรือตรงตามข้อกำหนดที่ระบุไว้ใน 7.2.2 สำหรับการนำทางที่ไม่ได้สัมผัส

7.2.1. คีย์บอร์ด

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

• ต้องรวมถึงการสนับสนุนสำหรับกรอบการจัดการอินพุต (ซึ่งช่วยให้นักพัฒนาบุคคลที่สามสามารถสร้างโปรแกรมแก้ไขวิธีการอินพุต-คีย์บอร์ดซอฟท์) ตามรายละเอียดที่ http://developer.android.com
• ต้องจัดเตรียมการใช้แป้นพิมพ์แบบนุ่ม ๆ อย่างน้อยหนึ่งครั้ง (ไม่ว่าจะมีแป้นพิมพ์แข็งอยู่) ยกเว้นอุปกรณ์นาฬิกา Android ที่ขนาดหน้าจอทำให้มีความสมเหตุสมผลน้อยกว่าที่จะมีแป้นพิมพ์นุ่ม
• อาจรวมถึงการใช้งานคีย์บอร์ดอ่อนเพิ่มเติม
• อาจรวมถึงคีย์บอร์ดฮาร์ดแวร์
• จะต้องไม่รวมแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุใน Android.content.res.configuration.keyboard [ ทรัพยากร, 68 ] (Qwerty หรือ 12-key)

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

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

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

7.2.3. ปุ่มนำทาง

ฟังก์ชั่นที่บ้าน, recents และ back (แมปไปยังคีย์เหตุการณ์ Keyde KeyCode_home, Keycode_app_switch, Keycode_back ตามลำดับ) เป็นสิ่งจำเป็นสำหรับกระบวนทัศน์การนำทาง Android และดังนั้น: ดังนั้น: ดังนั้น:

• การใช้งานอุปกรณ์พกพา Android จะต้องจัดหาฟังก์ชั่นที่บ้านและด้านหลัง
• การใช้งานอุปกรณ์โทรทัศน์ Android จะต้องจัดทำฟังก์ชั่นบ้านและหลัง
• การใช้งานอุปกรณ์ดู Android ต้องมีฟังก์ชั่นโฮมสำหรับผู้ใช้และฟังก์ชั่นด้านหลังยกเว้นเมื่ออยู่ใน UI_MODE_TYPE_WATCH
• การใช้งานยานยนต์ Android จะต้องให้ฟังก์ชั่นบ้านและอาจให้ฟังก์ชั่นย้อนกลับและฟังก์ชั่นล่าสุด
• การใช้งานอุปกรณ์ประเภทอื่น ๆ ทั้งหมดจะต้องให้ฟังก์ชั่นที่บ้านและด้านหลัง

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

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

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

ฟังก์ชั่นเมนูเลิกใช้งาน Action Bar ตั้งแต่ Android 4.0 ดังนั้นการใช้งานอุปกรณ์ใหม่ที่จัดส่งพร้อมกับ Android 5.0 และในภายหลังจะต้องไม่ใช้ปุ่มทางกายภาพเฉพาะสำหรับฟังก์ชั่นเมนู การใช้งานอุปกรณ์เก่าไม่ควรใช้ปุ่มทางกายภาพเฉพาะสำหรับฟังก์ชั่นเมนู แต่หากมีการใช้ปุ่มเมนูทางกายภาพและอุปกรณ์กำลังเรียกใช้แอปพลิเคชันด้วย TargetSdKversion> 10 การใช้งานอุปกรณ์:

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

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

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

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

• คีย์การนำทางการใช้งานอุปกรณ์จะต้องใช้ส่วนที่แตกต่างกันของหน้าจอไม่สามารถใช้งานได้กับแอปพลิเคชันและจะต้องไม่ปิดบังหรือรบกวนส่วนหนึ่งของหน้าจอที่มีให้กับแอปพลิเคชัน
• การใช้งานอุปกรณ์จะต้องทำให้ส่วนหนึ่งของการแสดงผลไปยังแอปพลิเคชันที่ตรงตามข้อกำหนดที่กำหนดไว้ใน ส่วน 7.1.1
• การใช้งานอุปกรณ์จะต้องแสดงคีย์การนำทางเมื่อแอปพลิเคชันไม่ระบุโหมดระบบ UI หรือระบุ System_UI_FLAG_VISIBLE
• การใช้งานอุปกรณ์จะต้องนำเสนอคีย์การนำทางในโหมด“ โปรไฟล์ต่ำ” ที่ไม่สร้างความรำคาญ (เช่น Dimmed) เมื่อแอปพลิเคชันระบุ System_UI_FLAG_LOW_PROFILE
• การใช้งานอุปกรณ์จะต้องซ่อนคีย์การนำทางเมื่อแอปพลิเคชันระบุ system_ui_flag_hide_navigation

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

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

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

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

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

7.2.5. อินพุตสัมผัสปลอม

การใช้งานอุปกรณ์ที่ประกาศการสนับสนุนสำหรับ Android.hardware.faketouch:

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

อุปกรณ์ที่ประกาศการสนับสนุนสำหรับ Android.hardware.faketouch.multitouch.distinct ต้องเป็นไปตามข้อกำหนดสำหรับ Faketouch ด้านบนและต้องรองรับการติดตามอินพุตตัวชี้อิสระสองตัวขึ้นไปที่แตกต่างกัน

7.2.6. รองรับคอนโทรลเลอร์เกม

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

7.2.6.1. การแมปปุ่ม

การใช้งานอุปกรณ์โทรทัศน์ Android จะต้องรองรับการแมปคีย์ต่อไปนี้:

1 [ ทรัพยากร, 72 ]

2 การใช้งาน HID ด้านบนจะต้องประกาศภายในแผ่นเกม CA (0x01 0x0005)

3 การใช้งานนี้จะต้องมีขั้นต่ำตรรกะที่ 0, สูงสุดเชิงตรรกะที่ 7, ขั้นต่ำทางกายภาพของ 0, ค่าสูงสุดทางกายภาพของ 315, หน่วยในองศา, และขนาดรายงาน 4 ค่าตรรกะถูกกำหนดให้เป็นการหมุนตามเข็มนาฬิกาตามเข็มนาฬิกาตามเข็มนาฬิกาตามเข็มนาฬิกา ห่างจากแกนแนวตั้ง ตัวอย่างเช่นค่าเชิงตรรกะของ 0 แสดงถึงการหมุนและปุ่ม UP ที่ถูกกดในขณะที่ค่าตรรกะของ 1 แสดงถึงการหมุน 45 องศาและทั้งปุ่ม UP และด้านซ้ายที่ถูกกด

4 [ ทรัพยากร, 71 ]

1 [ ทรัพยากร, 71 ]

7.2.7. รีโมท

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

• ค้นหาการจ่ายเงิน การใช้งานอุปกรณ์จะต้องปิดการใช้งาน keycode_search เมื่อผู้ใช้เรียกใช้การค้นหาเสียงทั้งในระยะไกลทางกายภาพหรือซอฟต์แวร์
• การนำทาง รีโมทโทรทัศน์ Android ทั้งหมดจะต้องรวมปุ่มกลับบ้านและเลือกปุ่มและการสนับสนุนสำหรับกิจกรรม D-Pad [ ทรัพยากร, 72 ]

7.3. เซนเซอร์

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

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

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

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

เซ็นเซอร์ Android บางตัวรองรับโหมดทริกเกอร์“ ต่อเนื่อง” ซึ่งส่งคืนข้อมูลอย่างต่อเนื่อง [ ทรัพยากร, 77 ] สำหรับ API ใด ๆ ที่ระบุโดยเอกสารประกอบ Android SDK เป็นเซ็นเซอร์อย่างต่อเนื่องการใช้งานอุปกรณ์จะต้องจัดทำตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมีอาการกระวนกระวายใจต่ำกว่า 3%ซึ่ง jitter ถูกกำหนดให้เป็นค่าเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างติดต่อกัน เหตุการณ์ต่างๆ

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

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

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

การใช้งานอุปกรณ์ควรมีเครื่องเร่งความเร็ว 3 แกน อุปกรณ์พกพา Android และอุปกรณ์นาฬิกา Android ได้รับการสนับสนุนอย่างยิ่งให้รวมเซ็นเซอร์นี้ หากการใช้งานอุปกรณ์รวมถึงตัวเร่งความเร็ว 3 แกนให้:

• ต้องใช้และรายงานเซ็นเซอร์ Type_accelerometer [ ทรัพยากร, 78 ]
• จะต้องสามารถรายงานเหตุการณ์ได้ถึงความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์นาฬิกา Android เนื่องจากอุปกรณ์ดังกล่าวมีข้อ จำกัด ด้านพลังงานที่เข้มงวดและ 100 Hz สำหรับอุปกรณ์ประเภทอื่น ๆ ทั้งหมด
• ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
• ต้องปฏิบัติตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API [ ทรัพยากร, 74 ]
• จะต้องมีความสามารถในการวัดจาก Freefall ถึงสี่เท่าของแรงโน้มถ่วง (4G) หรือมากกว่าในแกนใด ๆ
• ต้องมีความละเอียดอย่างน้อย 8 บิตและควรมีความละเอียดอย่างน้อย 16 บิต
• ควรได้รับการสอบเทียบในขณะที่ใช้งานหากคุณลักษณะเปลี่ยนแปลงไปทั่ววงจรชีวิตและชดเชยและรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• ควรได้รับการชดเชยอุณหภูมิ
• ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^ซึ่งควรคำนวณค่าเบี่ยงเบนมาตรฐานบนพื้นฐานต่อแกนในตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีในอัตราการสุ่มตัวอย่างที่เร็วที่สุด
• ควรใช้ type_significant_motion, type_tilt_detector, type_step_detector, type_step_counter เซ็นเซอร์คอมโพสิตตามที่อธิบายไว้ในเอกสาร Android SDK อุปกรณ์ Android ที่มีอยู่และใหม่ ได้รับการสนับสนุนอย่างมาก ในการใช้เซ็นเซอร์คอมโพสิต type_significant_motion หากมีการใช้เซ็นเซอร์ใด ๆ เหล่านี้ผลรวมของการใช้พลังงานของพวกเขาจะต้องน้อยกว่า 4 MW และควรต่ำกว่า 2 MW และ 0.5 MW สำหรับเมื่ออุปกรณ์อยู่ในสภาพแบบไดนามิกหรือคงที่
• หากมีการรวมเซ็นเซอร์ gyroscope ต้องใช้เซ็นเซอร์คอมโพสิต Type_Gravity และ Type_Linear_Acceleration และควรใช้เซ็นเซอร์คอมโพสิต Type_GAME_ROTATION_VECTOR อุปกรณ์ Android ที่มีอยู่และใหม่ได้รับการสนับสนุนอย่างยิ่งให้ใช้เซ็นเซอร์ Type_Game_Rotation_Vector
• ควรใช้เซ็นเซอร์คอมโพสิต Type_rotation_Vector หากเซ็นเซอร์ไจโรสโคปและเซ็นเซอร์ Magnetometer รวมอยู่ด้วย

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

การใช้งานอุปกรณ์ควรมีแม่เหล็ก 3 แกน (เข็มทิศ) หากอุปกรณ์มีแม่เหล็ก 3 แกนให้:

• ต้องใช้เซ็นเซอร์ type_magnetic_field และควรใช้เซ็นเซอร์ type_magnetic_field_uncalibrated อุปกรณ์ Android ที่มีอยู่และใหม่ได้รับการสนับสนุนอย่างยิ่งให้ใช้เซ็นเซอร์ Type_magnetic_field_uncalibrated
• จะต้องสามารถรายงานเหตุการณ์ได้ถึงความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์อย่างน้อย 50 Hz
• ต้องปฏิบัติตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API [ ทรัพยากร, 74 ]
• จะต้องมีความสามารถในการวัดระหว่าง -900 µt และ +900 µt ในแต่ละแกนก่อนที่จะอิ่มตัว
• ต้องมีค่าชดเชยเหล็กแข็งน้อยกว่า 700 µt และควรมีค่าต่ำกว่า 200 µt โดยการวางสนามแม่เหล็กไกลจากฟิลด์แม่เหล็กแบบไดนามิก
• ต้องมีความละเอียดเท่ากันหรือหนาแน่นกว่า 0.6 µt และควรมีความละเอียดเท่ากันหรือหนาแน่นกว่า 0.2 µ
• ควรได้รับการชดเชยอุณหภูมิ
• ต้องสนับสนุนการสอบเทียบออนไลน์และการชดเชยอคติเหล็กแข็งและรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• จะต้องใช้การชดเชยเหล็กอ่อน - การสอบเทียบสามารถทำได้ทั้งในขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
• ควรมีค่าเบี่ยงเบนมาตรฐานคำนวณบนพื้นฐานต่อแกนสำหรับตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีในอัตราการสุ่มตัวอย่างที่เร็วที่สุดไม่เกิน 0.5 µt
• ควรใช้เซ็นเซอร์คอมโพสิต Type_rotation_Vector หากเซ็นเซอร์ accelerometer และเซ็นเซอร์ gyroscope รวมอยู่ด้วย
• อาจใช้เซ็นเซอร์ type_geomagnetic_rotation_vector ถ้าเซ็นเซอร์ accelerometer ถูกนำมาใช้ อย่างไรก็ตามหากนำไปใช้งานจะต้องใช้น้อยกว่า 10 MW และควรกินน้อยกว่า 3 MW เมื่อเซ็นเซอร์ลงทะเบียนสำหรับโหมดแบทช์ที่ 10 Hz

7.3.3. จีพีเอส

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

7.3.4. ไจโรสโคป

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

• ต้องใช้เซ็นเซอร์ type_gyroscope และควรใช้เซ็นเซอร์ type_gyroscope_uncalibrated อุปกรณ์ Android ที่มีอยู่และใหม่ได้รับการสนับสนุนอย่างยิ่งให้ใช้เซ็นเซอร์ Sensor_Type_Gyroscope_uncalibrated
• จะต้องมีความสามารถในการวัดการปฐมนิเทศเปลี่ยนสูงถึง 1,000 องศาต่อวินาที
• จะต้องสามารถรายงานเหตุการณ์ได้ถึงความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์นาฬิกา Android เนื่องจากอุปกรณ์ดังกล่าวมีข้อ จำกัด ด้านพลังงานที่เข้มงวดและ 100 Hz สำหรับอุปกรณ์ประเภทอื่น ๆ ทั้งหมด
• ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
• ต้องมีความละเอียด 12 บิตขึ้นไปและควรมีความละเอียด 16 บิตขึ้นไป
• ต้องได้รับการชดเชยอุณหภูมิ
• ต้องได้รับการสอบเทียบและชดเชยขณะใช้งานและรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) ความแปรปรวนได้รับอนุญาตให้แตกต่างกันไปตามอัตราการสุ่มตัวอย่าง แต่ต้องถูก จำกัด ด้วยค่านี้ กล่าวอีกนัยหนึ่งถ้าคุณวัดความแปรปรวนของไจโรที่อัตราการสุ่มตัวอย่าง 1 Hz มันไม่ควรเกิน 1e-7 rad^2/s^2
• ควรใช้เซ็นเซอร์คอมโพสิต Type_rotation_Vector หากเซ็นเซอร์ accelerometer และเซ็นเซอร์ Magnetometer รวมอยู่ด้วย
• หากรวมเซ็นเซอร์ accelerometer ต้องใช้เซ็นเซอร์คอมโพสิต Type_Gravity และ Type_Linear_Acceleration และควรใช้เซ็นเซอร์คอมโพสิต Type_Game_Rotation_Vector อุปกรณ์ Android ที่มีอยู่และใหม่ได้รับการสนับสนุนอย่างยิ่งให้ใช้เซ็นเซอร์ Type_Game_Rotation_Vector

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

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

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

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

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

การใช้งานอุปกรณ์อาจ แต่ไม่ควรรวมเซ็นเซอร์อุณหภูมิ CPU หากมีอยู่จะต้องกำหนดเป็น sensor_type_temperature จะต้องวัดอุณหภูมิของ CPU อุปกรณ์และจะต้องไม่วัดอุณหภูมิอื่นใด หมายเหตุประเภทเซ็นเซอร์ Sensor_type_Temperature ถูกเลิกใช้ใน Android 4.0

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

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

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

การใช้งานอุปกรณ์อาจรวมถึงเซ็นเซอร์ความใกล้ชิด อุปกรณ์ที่สามารถโทรออกด้วยเสียงและระบุค่าใด ๆ นอกเหนือจาก phone_type_none ใน getphonetype ควรมีเซ็นเซอร์ความใกล้ชิด หากการใช้งานอุปกรณ์รวมถึงเซ็นเซอร์ความใกล้ชิดให้:

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

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

7.4.1. โทรศัพท์

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

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

7.4.2. IEEE 802.11 (ไวไฟ)

การใช้งานอุปกรณ์โทรทัศน์ Android จะต้องมีการสนับสนุนสำหรับหนึ่งหรือมากกว่าหนึ่งรูปแบบของ 802.11 (b/g/a/n ฯลฯ ) และการใช้งานอุปกรณ์ Android ประเภทอื่น ๆ ควรรวมถึงการสนับสนุนสำหรับ 802.11 รูปแบบหรือมากกว่า หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ 802.11 และเปิดเผยฟังก์ชั่นไปยังแอปพลิเคชันของบุคคลที่สามจะต้องใช้ Android API ที่เกี่ยวข้องและ::

• ต้องรายงานฮาร์ดแวร์ฟีเจอร์แฟล็ก Android.hardware.wifi
• ต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสาร SDK [ Resources, 79 ]
• ต้องรองรับ Multicast DNS (MDNS) และต้องไม่กรองแพ็คเก็ต MDNS (224.0.0.251) ตลอดเวลาที่ใช้งานได้ตลอดเวลารวมถึงเมื่อหน้าจอไม่ได้อยู่ในสถานะที่ใช้งานอยู่

7.4.2.1. Wi-Fi ตรง

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

• ต้องรายงานคุณสมบัติฮาร์ดแวร์ Android.hardware.wifi.direct
• ต้องสนับสนุนการทำงานของ Wi-Fi ปกติ
• ควรสนับสนุนการดำเนินงานโดยตรง Wi-Fi และ Wi-Fi ที่เกิดขึ้นพร้อมกัน

7.4.2.2. การตั้งค่าลิงก์โดยตรงแบบอุโมงค์ Wi-Fi

การใช้งานอุปกรณ์โทรทัศน์ Android จะต้องมีการสนับสนุนการตั้งค่า Wi-Fi Tunseled Direct Link Setup (TDLs) และการใช้งานอุปกรณ์ Android ประเภทอื่น ๆ ควรรวมถึงการสนับสนุนสำหรับ Wi-Fi TDLs ตามที่อธิบายไว้ในเอกสาร Android SDK [ ทรัพยากร, 81 ] หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLs และ TDLs ถูกเปิดใช้งานโดย Wifimanager API อุปกรณ์:

• ควรใช้ TDLs เฉพาะเมื่อเป็นไปได้และเป็นประโยชน์
• ควรมีฮิวริสติกบางอย่างและไม่ใช้ TDLs เมื่อประสิทธิภาพของมันอาจจะเลวร้ายยิ่งกว่าการผ่านจุดเชื่อมต่อ Wi-Fi

7.4.3. บลูทู ธ

Android มีการรองรับ Bluetooth และ Bluetooth Low Energy [ ทรัพยากร, 82 ] การใช้งานอุปกรณ์ที่รวมถึงการรองรับ Bluetooth และ Bluetooth Low Energy ต้องประกาศคุณสมบัติแพลตฟอร์มที่เกี่ยวข้อง (Android.hardware.bluetooth และ Android.hardware.bluetooth_le ตามลำดับ) และใช้ APIs แพลตฟอร์ม การใช้งานอุปกรณ์ควรใช้โปรไฟล์บลูทู ธ ที่เกี่ยวข้องเช่น A2DP, AVCP, OBEX ฯลฯ ตามความเหมาะสมสำหรับอุปกรณ์ การใช้งานอุปกรณ์โทรทัศน์ Android จะต้องรองรับบลูทู ธ และบลูทู ธ LE

การใช้งานอุปกรณ์รวมถึงการรองรับ Bluetooth Low Energy:

• ต้องประกาศคุณสมบัติฮาร์ดแวร์ Android.hardware.bluetooth_le
• ต้องเปิดใช้งาน GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) APIs ที่ใช้ Bluetooth ตามที่อธิบายไว้ในเอกสาร SDK และ [ ทรัพยากร, 82 ]
• ควรรองรับการขนถ่ายตรรกะการกรองไปยังชิปเซ็ตบลูทู ธ เมื่อใช้ ScanFilter API [ ทรัพยากร, 83 ] และต้องรายงานค่าที่ถูกต้องของการที่ตรรกะการกรองถูกนำไปใช้เมื่อใดก็ตามที่สอบถามผ่าน Android.bluetooth.bluetoothaDapter
• ควรรองรับการขนถ่ายการสแกนแบบแบตช์ไปยังชิปเซ็ตบลูทู ธ แต่หากไม่รองรับต้องรายงาน 'เท็จ' เมื่อใดก็ตามที่สอบถามผ่าน Android.bluetooth.bluetoothadapater.isoffloadedscanbatchingsupported ()
• ควรสนับสนุนการโฆษณาหลายรายการด้วยช่องอย่างน้อย 4 ช่อง แต่หากไม่รองรับต้องรายงาน 'เท็จ' เมื่อใดก็ตามที่สอบถามผ่าน Android.bluetooth.bluetoothadapter.ismultipleadvertisementsupported ()

7.4.4. การสื่อสารระยะใกล้

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

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

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

Android รวมถึงการสนับสนุนโหมดการจำลองการ์ดโฮสต์ NFC (HCE) หากการใช้งานอุปกรณ์รวมถึงชิปเซ็ตคอนโทรลเลอร์ NFC ที่มีความสามารถในการกำหนดเส้นทาง HCE และ Application ID (AID) แล้ว:

• ต้องรายงาน Android.hardware.nfc.hce ค่าคงที่
• ต้องสนับสนุน NFC HCE APIs ตามที่กำหนดไว้ใน Android SDK [ ทรัพยากร, 10 ]

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

• Mifare Classic
• MIFARE อัลตร้าไลท์
• ndef บน mifare classic

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

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

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

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

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

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

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

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

7.4.6. การตั้งค่าการซิงค์

การใช้งานอุปกรณ์จะต้องมีการตั้งค่าการซิงค์อัตโนมัติหลักโดยค่าเริ่มต้นเพื่อให้วิธีการ getMastersyncautomatically () ส่งคืน“ จริง” [ ทรัพยากร, 89 ]

7.5. กล้อง

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

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

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

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

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

7.5.2. กล้องหน้า

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

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

7.5.3. กล้องภายนอก

Device implementations with USB host mode MAY include support for an external camera that connects to the USB port. If a device includes support for an external camera, it:

• MUST declare the platform feature android.hardware.camera.external and android.hardware camera.any.
• MUST support USB Video Class (UVC 1.0 or higher).
• MAY support multiple cameras.

Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of high-quality unencoded streams (ie raw or independently compressed picture streams). Camera-based video encoding MAY be supported. If so, a simultaneous unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the device implementation.

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

Android includes two API packages to access the camera, the newer android.hardware.camera2 API expose lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more.

The older API package, android.hardware.Camera, is marked as deprecated in Android 5.0 but as it should still be available for apps to use Android device implementations MUST ensure the continued support of the API as described in this section and in the Android SDK .

Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras:

• If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
• If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
• For android.hardware.Camera, device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)
• For android.hardware.camera2, device implementations must support the android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG formats as outputs through the android.media.ImageReader API.

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

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 92 ].

Because not all device implementations can fully support all the features of the android.hardware.camera2 API, device implementations MUST report the proper level of support with the android.info.supportedHardwareLevel property as described in the Android SDK [ Resources, 93] and report the appropriate framework feature flags [ Resources, 94] .

Device implementations MUST also declare its Individual camera capabilities of android.hardware.camera2 via the android.request.availableCapabilities property and declare the appropriate feature flags [ Resources, 94] ; a device must define the feature flag if any of its attached camera devices supports the feature.

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.5. การวางแนวกล้อง

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

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

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

The memory available to the kernel and userspace on device implementations MUST be at least equal or larger than the minimum values specified by the following table. (See section 7.1.1 for screen size and density definitions.)

The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace, unless an Android Watch, MUST return the value "true" for ActivityManager.isLowRamDevice().

Android Television devices MUST have at least 5GB and other device implementations MUST have at least 1.5GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 5GB for Android Television devices and at least 1.5GB for other device implementations. Device implementations that run Android are very strongly encouraged to have at least 3GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications MAY use to download data files [ Resources, 95 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default “cache" location.

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

Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.

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

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital (SD) card slot. If this slot is used to satisfy the shared storage requirement, the device implementation:

• MUST implement a toast or pop-up user interface warning the user when there is no SD card.
• MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box and other material available at time of purchase that the SD card has to be separately purchased.
• MUST mount the SD card by default.

Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps as included in the upstream Android Open Source Project; device implementations SHOULD use this configuration and software implementation. If a device implementation uses internal (non-removable) storage to satisfy the shared storage requirement, while that storage MAY share space with the application private data, it MUST be at least 1GB in size and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere).

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

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed and privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except when writing to their package-specific directories or within the URI returned by firing the ACTION_OPEN_DOCUMENT_TREE intent.

However, device implementations SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

Regardless of the form of shared storage used, if the device implementation has a USB port with USB peripheral mode support, it MUST provide some mechanism to access the contents of shared storage from a host computer. Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement. If the device implementation supports Media Transfer Protocol, it:

• SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 96 ].
• SHOULD report a USB device class of 0x00.
• SHOULD report a USB interface name of 'MTP'.

7.7. ยูเอสบี

Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.

If a device implementation includes a USB port supporting peripheral mode:

• The port MUST be connectable to a USB host that has a standard type-A or type -C USB port.
• The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• The port SHOULD either be located on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
  • MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 97 ].
  • MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ].
• It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ]. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
• The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB port supporting host mode, it:

• SHOULD use a type-C USB port, if the device implementation supports USB 3.1.
• MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to a standard type-A or type-C USB port.
• MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port.
• is very strongly RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ].
• MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 100 ].
• SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ].

7.8. เสียง

7.8.1. ไมโครโฟน

Device implementations MAY omit a microphone. However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and MUST implement the audio recording API at least as no-ops, per section 7 . Conversely, device implementations that do possess a microphone:

• MUST report the android.hardware.microphone feature constant
• MUST meet the audio recording requirements in section 5.4
• MUST meet the audio latency requirements in section 5.6

7.8.2. เอาต์พุตเสียง

Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:

• MUST report the android.hardware.audio.output feature constant.
• MUST meet the audio playback requirements in section 5.5 .
• MUST meet the audio latency requirements in section 5.6 .

Conversely, if a device implementation does not include a speaker or audio output port, it MUST NOT report the android.hardware.audio output feature, and MUST implement the Audio Output related APIs as no-ops at least.

Android Watch device implementation MAY but SHOULD NOT have audio output, but other types of Android device implementations MUST have an audio output and declare android.hardware.audio.output.

7.8.2.1. พอร์ตเสียงอนาล็อก

In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem [ Resources, 101 ], if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:

• MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone.
• MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order.
• MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1.
• SHOULD support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 ohm or less : KEYCODE_HEADSETHOOK
  • 210-290 Ohm : KEYCODE_VOLUME_UP
  • 360-680 Ohm : KEYCODE_VOLUME_DOWN
• SHOULD support the detection and mapping to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 110-180 Ohm: KEYCODE_VOICE_ASSIST
• MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
• MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm speaker impedance.
• MUST have a microphone bias voltage between 1.8V ~ 2.9V.

8. Performance Compatibility

Some minimum performance criteria are critical to the user experience and impacts the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria:

8.1. ความสม่ำเสมอของประสบการณ์ผู้ใช้

Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements:

• Consistent frame latency . Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
• User interface latency . Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
• Task switching . When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

8.2. ประสิทธิภาพการเข้าถึงไฟล์ I/O

Device implementations MUST ensure internal storage file access performance consistency for read and write operations.

• Sequential write . Device implementations MUST ensure a sequential write performance of at least 5MB/s for a 256MB file using 10MB write buffer.
• Random write . Device implementations MUST ensure a random write performance of at least 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read . Device implementations MUST ensure a sequential read performance of at least 15MB/s for a 256MB file using 10MB write buffer.
• Random read . Device implementations MUST ensure a random read performance of at least 3.5MB/s for a 256MB file using 4KB write buffer.

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

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

9.1. สิทธิ์

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

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

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

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

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

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

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

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

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

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

Alternate runtimes MUST abide by the Android sandbox model. Specifically, alternate runtimes:

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

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

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

9.5. การสนับสนุนผู้ใช้หลายคน

Android includes support for multiple users and provides support for full user isolation [ Resources, 103] . Device implementations MAY enable multiple users, but when enabled MUST meet the following requirements related to multi-user support [ Resources, 104 ]:

• Device implementations that do not declare the android.hardware.telephony feature flag MUST support restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments.
• Conversely device implementations that declare the android.hardware.telephony feature flag MUST NOT support restricted profiles but MUST align with the AOSP implementation of controls to enable /disable other users from accessing the voice calls and SMS.
• Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ].
• Device implementations MAY support creating users and managed profiles via the android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the platform feature flag android.software.managed_users.
• Device implementations that declare the feature flag android.software.managed_users MUST use the upstream AOSP icon badge to represent the managed applications and other badge UI elements like Recents & Notifications.
• Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the primary external storage APIs MUST encrypt the contents of the SD card if multiuser is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 105 ] for primary external storage.

9.6. คำเตือนทาง SMS ระดับพรีเมียม

Android includes support for warning users of any outgoing premium SMS message [ Resources, 106 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. คุณสมบัติความปลอดภัยของเคอร์เนล

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

• MUST maintain compatibility with existing applications.
• MUST NOT have a visible user interface when a security violation is detected and successfully blocked, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit.
• SHOULD NOT be user or developer configurable.

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux or an equivalent mandatory access control system if using a kernel other than Linux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

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

• MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis, and MUST configure all domains in enforcing mode. No permissive mode domains are allowed, including domains specific to a device/vendor.
• SHOULD load policy from /sepolicy file on the device.
• MUST NOT modify, omit, or replace the neverallow rules present within the sepolicy file provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow present, for both AOSP SELinux domains as well as device/vendor specific domains .
• MUST support dynamic updates of the SELinux policy file without requiring a system image update.

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. ความเป็นส่วนตัว

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

If a device implementation has a mechanism that routes network data traffic through a proxy server or VPN gateway by default (for example, preloading a VPN service with android.permission.CONTROL_VPN granted), the device implementation MUST ask for the user's consent before enabling that กลไก.

9.9. การเข้ารหัสทั้งดิสก์

If the device implementation supports a lock screen with PIN (numeric) or PASSWORD (alphanumeric), the device MUST support full-disk encryption of the application private data (/data partition), as well as the SD card partition if it is a permanent, non-removable part of the device [ Resources, 107 ]. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. Other than when in active use, the encryption key SHOULD be AES encrypted with the lockscreen passcode stretched using a slow stretching algorithm (eg PBKDF2 or scrypt). If the user has not specified a lockscreen passcode or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the linux kernel feature dm-crypt.

9.10. บูตที่ตรวจสอบแล้ว

Verified boot is a feature that guarantees the integrity of the device software. If a device implementation supports the feature, it MUST:

• Declare the platform feature flag android.software.verified_boot
• Perform verification on every boot sequence
• Start verification from a hardware key that is the root of trust, and go all the way up to the system partition
• Implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage
• Use verification algorithms as strong as current recommendations from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048)

Device implementations SHOULD support verified boot for device integrity. While this requirement is SHOULD for this version of the Android platform, it is strongly RECOMMENDED as we expect this to change to MUST in future versions of Android. The upstream Android Open Source Project provides a preferred implementation of this feature based on the linux kernel feature dm-verity.

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

Device implementations MUST pass all tests described in this section.

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

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

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

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

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

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

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

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

11. ซอฟต์แวร์ที่สามารถอัพเดตได้

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

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

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

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile:

• Android Automotive implementations SHOULD support OTA downloads with offline update via reboot.
• All other device implementations MUST support OTA downloads with offline update via reboot.

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

For device implementations that are launching with Android 5.1 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.1, satisfies this requirement.

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

12. บันทึกการเปลี่ยนแปลงเอกสาร

The following table contains a summary of the changes to the Compatibility Definition in this release.

13. ติดต่อเรา

You can join the android-compatibility forum [Resources, 109 ] and ask for clarifications or bring up any issues that you think the document does not cover.

14. ทรัพยากร

1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Android Television features: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch feature: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API definitions and documentation: http://developer.android.com/reference/packages.html

6. Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

8. Android 5.1 allowed version strings: http://source.android.com/compatibility/5.1/versions.html

9. Telephony Provider: http://developer.android.com/reference/android/provider/Telephony.html

10. Host-based Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView compatibility: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

20. Dalvik Executable Format and bytecode specification: available in the Android source code, at dalvik/docs

21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. Application Resources: https://developer.android.com/guide/topics/resources/available-resources.html

24. Status Bar icon style guide: http://developer.android.com/design/style/iconography.html

25. Notifications Resources: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Themes: http://developer.android.com/guide/topics/ui/themes.html

29. R.style class: http://developer.android.com/reference/android/R.style.html

30. Material design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live Wallpapers: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Overview screen resources: http://developer.android.com/guide/components/recents.html

33. Screen pinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Input methods: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Media Notification: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager reference: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service APIs: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free project: http://code.google.com/p/eyes-free

45. Text-To-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Reference tool documentation (for adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

48. Android apk file description: http://developer.android.com/guide/components/fundamentals.html

49. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android Media Formats: http://developer.android.com/guide/appendix/media-formats.html

51. RTC Hardware Coding Requirements: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager class and Hardware Features List:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: /devices/input/diagnostics.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey testing tool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace tool: http://developer.android.com/tools/help/systrace.html

60. Android Application Development-Related Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android extension pack for OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL Extension-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Touch Input Configuration: http://source.android.com/devices/tech/input/touch-devices.html

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android Open Source sensors: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source composite sensors: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Continuous trigger mode: /docs/core/interaction/sensors/report-modes#continuous

78. Accelerometer sensor: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. Android NFC Sharing Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. NFC Connection Handover: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. Camera: http://developer.android.com/reference/android/hardware/Camera.html

92. Camera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Camera hardware level: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Camera version support: http://source.android.com/devices/camera/versioning.html

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. USB Charging Specification: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. USB Host API: http://developer.android.com/guide/topics/connectivity/usb/host.html

101. Wired audio headset: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. Android Security and Permissions reference: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager reference: http://developer.android.com/reference/android/os/UserManager.html

104. External Storage reference: http://source.android.com/docs/core/storage

105. External Storage APIs: http://developer.android.com/reference/android/os/Environment.html

106. SMS Short Code: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: http://source.android.com/docs/security/features/encryption

108. Android Compatibility Program Overview: http://source.android.com//docs/compatibility

109. Android Compatibility forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM project: http://www.webmproject.org/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

Many of these resources are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK's documentation. ในกรณีใดๆ ที่ข้อกำหนดความเข้ากันได้นี้หรือชุดทดสอบความเข้ากันได้ไม่เห็นด้วยกับเอกสารประกอบ SDK เอกสารประกอบ SDK จะถือว่าเชื่อถือได้ Any technical details provided in the references included above are considered by inclusion to be part of this Compatibility Definition.