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

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

การใช้ "ต้อง" "ต้องไม่" "ต้องระบุ" "จะ" "จะไม่" "ไม่ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119

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

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

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

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

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

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

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

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

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

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

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

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

• ต้องมีหน้าจอที่มีความยาวตามเส้นทแยงมุมจริงอยู่ในช่วง 1.1-2.5 นิ้ว
• ต้องประกาศฟีเจอร์ android.hardware.type.watch
• ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH

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

• ต้องมีหน้าจอที่มีความยาวเส้นทแยงมุมจริงเท่ากับหรือมากกว่า 6 นิ้ว
• ต้องประกาศฟีเจอร์ android.hardware.type.automotive
• ต้องรองรับ uiMode = UI_MODE_TYPE_CAR
• การติดตั้งใช้งาน Android Automotive ต้องรองรับ API สาธารณะทั้งหมดในเนมสเปซ android.car.*

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

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

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

หมวดหมู่	ฟีเจอร์	โซน	มือถือ	โทรทัศน์	ดู	ยานยนต์	อื่นๆ
อินพุต	D-pad	7.2.2 การนำทางแบบไม่สัมผัส		ต้อง
	หน้าจอสัมผัส	7.2.4 การป้อนข้อมูลด้วยหน้าจอสัมผัส	ต้อง		ต้อง		ควร
	ไมโครโฟน	7.8.1 ไมโครโฟน	ต้อง	ควร	ต้อง	ต้อง	ควร
เซ็นเซอร์	ตัวตรวจวัดความเร่ง	7.3.1 ตัวตรวจวัดความเร่ง	ควร		ควร		ควร
	GPS	7.3.3 GPS	ควร			ควร
การเชื่อมต่อ	Wi-Fi	7.4.2 IEEE 802.11	ควร	ควร		ควร	ควร
	Wi-Fi Direct	7.4.2.1 Wi-Fi Direct	ควร	ควร			ควร
	บลูทูธ	7.4.3 บลูทูธ	ควร	ต้อง	ต้อง	ต้อง	ควร
	บลูทูธพลังงานต่ำ	7.4.3 บลูทูธ	ควร	ต้อง	ควร	ควร	ควร
	วิทยุเซลลูลาร์	7.4.5 ความสามารถของเครือข่ายขั้นต่ำ				ควร
	โหมดโฮสต์/อุปกรณ์ต่อพ่วง USB	7.7 USB	ควร			ควร	ควร
เอาต์พุต	พอร์ตลำโพงและ/หรือเอาต์พุตเสียง	7.8.2 เอาต์พุตเสียง	ต้อง	ต้อง		ต้อง	ต้อง

3. ซอฟต์แวร์

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

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

การใช้งานอุปกรณ์ต้องสนับสนุน/เก็บรักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมดที่ทำเครื่องหมายโดยคำอธิบายประกอบ TestApi (@TestApi)

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

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

3.1.1. ส่วนขยาย Android

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

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

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

3.2.1. สิทธิ์

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

3.2.2 พารามิเตอร์บิลด์

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

พารามิเตอร์	รายละเอียด
VERSION.RELEASE	เวอร์ชันของระบบ Android ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน 7.0
VERSION.SDK	เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 7.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 7.0_INT
VERSION.SDK_INT	เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 7.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 7.0_INT
เวอร์ชันที่เพิ่มขึ้น	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ต้องไม่นำค่านี้มาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางเข้าถึงได้ โดยทั่วไปแล้ว ช่องนี้มีไว้เพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("")
กระดาน	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในที่เจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือระบุเวอร์ชันที่เจาะจงของบอร์ดจ่ายไฟของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$"
แบรนด์	ค่าที่แสดงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ซึ่งผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรเป็นตัวแทนของผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่จำหน่ายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$"
SUPPORTED_ABIS	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม
SUPPORTED_32 BIT_ABIS	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม
SUPPORTED_64 BIT_ABIS	ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม
CPU ABI	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม
CPU ABI2	ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม
อุปกรณ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าฟีเจอร์ของฮาร์ดแวร์และการออกแบบเชิงอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
Fingerprint	สตริงที่ระบุบิลด์นี้ได้โดยไม่ซ้ำกัน เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ต้องเป็นไปตามเทมเพลตนี้ $(BRAND)/$(ผลิตภัณฑ์)/ $(DEVICE):$(VERSION.RELEASE)/$(รหัส)/$(VERSION.INCREMENTAL):$(ประเภท)/$(แท็ก) เช่น acme/myproduct/ อุปกรณ์ของฉัน:7.0/LMYXX/3359:userdebug/test-keys ลายนิ้วมือต้องไม่มีอักขระช่องว่าง หากช่องอื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมีอักขระที่เป็นช่องว่าง ต้องแทนที่ช่องดังกล่าวในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต
ฮาร์ดแวร์	ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$"
ผู้จัด	สตริงที่ระบุโฮสต์แบบไม่ซ้ำที่สร้างขึ้นมาในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("")
รหัส	ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ช่องนี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกความแตกต่างระหว่างเวอร์ชันของซอฟต์แวร์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$"
ผู้ผลิต	ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("")
MODEL	ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("")
ผลิตภัณฑ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ที่เจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับให้ผู้ใช้ปลายทางอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ซีเรียล	หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องมีพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ทุกเครื่องที่มี MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^([a-zA-Z0-9]{6,20})$”
แท็ก	รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 แบบ ได้แก่ คีย์การเผยแพร่ คีย์นักพัฒนาซอฟต์แวร์ คีย์การทดสอบ
เวลา	ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์
ประเภท	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android 3 รายการ ได้แก่ user, userdebug หรือ eng
ผู้ใช้	ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("")
แพตช์ด้านความปลอดภัย	ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องหมายความว่าเวอร์ชันดังกล่าวไม่มีช่องโหว่ต่อปัญหาต่างๆ ที่อธิบายไว้ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] โดยตรงกับสตริงที่กำหนดในกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android หรือในคำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS	ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่เหมือนกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android โดยต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("")

3.2.3 ความเข้ากันได้กับ Intent

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

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

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

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

3.2.3.2 ความละเอียดของความตั้งใจ

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

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

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

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

• ต้องพยายามตรวจสอบตัวกรอง Intent ใดๆ โดยทำตามขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัลที่ Package Manager นำไปใช้ในโปรเจ็กต์โอเพนซอร์สของ Android
• ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ UIR ที่ผ่านการตรวจสอบแล้วทั้งหมดเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ UIR
• อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากตัวกรองดังกล่าวได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นได้ยืนยันไม่สำเร็จ หากการติดตั้งใช้งานอุปกรณ์มีลักษณะเช่นนี้ ต้องระบุการลบล้างรูปแบบ URL ที่เหมาะสมให้กับผู้ใช้ในเมนูการตั้งค่า
• ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้กับผู้ใช้ในการตั้งค่าดังนี้
  • ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของ App Link เริ่มต้นในภาพรวมสำหรับแอปให้เป็น "เปิดตลอดเวลา" ถามเสมอ หรือไม่เปิดเลยได้ ซึ่งจะต้องนำไปใช้กับตัวกรอง Intent URI ที่เลือกทั้งหมดอย่างเท่าเทียมกัน
  • ผู้ใช้ต้องดูรายการตัวกรอง Intent ของ URI ที่เลือกได้
  • การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้ลบล้างตัวกรอง Intent ของ URI ของตัวเลือกบางรายการที่ได้รับการยืนยันเรียบร้อยแล้ว โดยอิงตามตัวกรองต่อความตั้งใจ
  • การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้สามารถดูและลบล้างตัวกรอง Intent ของ URI ที่เลือกได้ หากการใช้งานอุปกรณ์ช่วยให้ตัวกรอง Intent ของ URI ที่มีตัวเลือกบางรายการทำการยืนยันได้สำเร็จ ขณะที่บางตัวกรองอาจล้มเหลวได้

3.2.3.3 เนมสเปซ Intent

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

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

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

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

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

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

• ต้องทำตาม Intent ของ android.settings.HOME_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก หากการใช้งานอุปกรณ์รายงาน android.software.home_screen
• ต้องระบุเมนูการตั้งค่าที่จะเรียกใช้ Intent ของ android.provider.Telephony.ACTION_CHANGE_DEFAULT เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น หากการใช้งานอุปกรณ์รายงาน android.hardware.telephony
• ต้องปฏิบัติตาม Intent android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับ "แตะและจ่าย" หากการใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce
• ต้องทำตาม Intent android.telecom.action.CHANGE_DEFAULT_DIALER เพื่อแสดงกล่องโต้ตอบเพื่ออนุญาตให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้น หากการใช้งานอุปกรณ์รายงาน android.hardware.telephony

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

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

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

ไบต์โค้ด Dalvik ที่มีการจัดการจะเรียกใช้โค้ดแบบเนทีฟที่ระบุไว้ในไฟล์ .apk ของแอปพลิเคชันเป็นไฟล์ ELF .so ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสมได้ เนื่องจากโค้ดแบบเนทีฟต้องอาศัยเทคโนโลยีโปรเซสเซอร์ที่เกี่ยวข้องเป็นหลัก Android จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) จำนวนหนึ่งไว้ใน Android NDK การใช้งานอุปกรณ์ต้องเข้ากันได้กับ ABI ที่กำหนดไว้อย่างน้อย 1 รายการ และต้องใช้งานความเข้ากันได้กับ 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 ABI Management เวอร์ชันล่าสุดเท่านั้น และต้องรวมการรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)
• ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง

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

API โค้ดแบบเนทีฟต่อไปนี้ต้องใช้ได้กับแอปที่มีโค้ดแบบเนทีฟ

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

สำหรับไลบรารีแบบเนทีฟที่ระบุไว้ข้างต้น การใช้งานอุปกรณ์ต้องไม่เพิ่มหรือนำฟังก์ชันสาธารณะออก

ไลบรารีแบบเนทีฟที่ไม่ได้ระบุไว้ข้างต้น แต่ติดตั้งใช้งานและระบุไว้ใน AOSP เนื่องจากมีการสงวนไลบรารีระบบไว้ และต้องไม่มีแอปของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป

การใช้งานอุปกรณ์อาจเพิ่มไลบรารีที่ไม่ใช่ AOSP และแสดงไลบรารีดังกล่าวโดยตรงเป็น API สำหรับแอปของบุคคลที่สาม แต่ไลบรารีเพิ่มเติมควรอยู่ใน /vendor/lib หรือ /vendor/lib64 และต้องอยู่ใน /vendor/etc/public.libraries.txt

โปรดทราบว่าการใช้งานอุปกรณ์ต้องมี libGLESv3.so และในทางกลับกัน คุณจะต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่ระบุไว้ในรุ่น NDK android-24 แม้ว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่คุณจะต้องใช้ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชัน OpenGL ES และส่วนขยายที่อุปกรณ์รองรับอย่างเต็มรูปแบบเท่านั้น

3.3.1.1 คลังกราฟิก

Vulkan คือ API ข้ามแพลตฟอร์มแบบโอเวอร์เฮดสำหรับกราฟิก 3 มิติประสิทธิภาพสูง การติดตั้งใช้งานอุปกรณ์ แม้ว่าจะไม่รองรับ Vulkan API ต้องปฏิบัติตามข้อกำหนดต่อไปนี้

• และต้องมีไลบรารีแบบเนทีฟชื่อ libvulkan.so ซึ่งส่งออกสัญลักษณ์ฟังก์ชันสำหรับ Vulkan 1.0 API หลัก รวมถึงส่วนขยาย VK_KHR_surface, VK_KHR_android_surface และ VK_KHR_swapchain เสมอ

การติดตั้งใช้งานอุปกรณ์ หากรวมการรองรับ Vulkan API

• ต้องรายงาน VkPhysicalDevices อย่างน้อย 1 รายการผ่านการเรียก vkEnumeratePhysicalDevices
• VkPhysicalDevices ที่แจกแจงแต่ละรายการต้องใช้ Vulkan 1.0 API อย่างเต็มรูปแบบ
• ต้องรายงานแฟล็กฟีเจอร์ PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL และ PackageManager#FEATURE_VULKAN_HARDWARE_VERSION ที่ถูกต้อง
• ต้องแจกแจงเลเยอร์ที่อยู่ในไลบรารีแบบเนทีฟที่ชื่อ libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชัน ผ่านฟังก์ชัน vkEnumerateInstanceLayerProperties และ vkEnumerateDeviceLayerProperties ใน libvulkan.so
• ต้องไม่แจกแจงเลเยอร์ที่ระบุโดยไลบรารีนอกแพ็กเกจของแอปพลิเคชัน หรือระบุวิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีแอตทริบิวต์ android:debuggable=”true”

การติดตั้งใช้งานอุปกรณ์ หากไม่ได้รวมการรองรับ Vulkan API

• ต้องรายงาน 0 VkPhysicalDevices ผ่านการเรียก vkEnumeratePhysicalDevices
• ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL และ PackageManager#FEATURE_VULKAN_HARDWARE_VERSION

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 บิต อุปกรณ์ต้องมีบรรทัดต่อไปนี้ใน /proc/cpuinfo เมื่ออ่านโดยแอปพลิเคชัน ARM 32 บิตเพื่อให้เข้ากันได้กับแอปพลิเคชันที่สร้างขึ้นโดยใช้ NDK นี้

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

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

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

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

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

• การใช้งาน android.webkit.WebView ของอุปกรณ์จะต้องอิงตามบิลด์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android สำหรับ Android 7.0 บิลด์นี้มีชุดฟังก์ชันและการแก้ไขด้านความปลอดภัยเฉพาะสำหรับ WebView

• สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบต่อไปนี้

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ android.os.Build.VERSION.RELEASE
  • ค่าของสตริง $(MODEL) ต้องเหมือนกับค่าของ android.os.Build.MODEL
  • ค่าของสตริง $(BUILD) ต้องเหมือนกับค่าของ android.os.Build.ID
  • ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
  • การใช้งานอุปกรณ์อาจเว้น "อุปกรณ์เคลื่อนที่" ในสตริง User Agent

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

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

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

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

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

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

นอกจากนี้ การใช้งานอุปกรณ์ต้องรองรับ Webstorage API แบบ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ IndexedDB แทน Webstorage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันในอนาคต

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

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

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

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

3.6 เนมสเปซ API

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

• java*
• javax*
• ดวงอาทิตย์*
• android*
• com.android*

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

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

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

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

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

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

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

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

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

รูปแบบหน้าจอ	ความหนาแน่นของหน้าจอ	หน่วยความจำแอปพลิเคชันขั้นต่ำ
นาฬิกาข้อมือ Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)
	320 dpi (Xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
เล็ก/ปกติ	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
ใหญ่	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (Xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (Xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

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

3.8.1 Launcher (หน้าจอหลัก)

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

3.8.2 วิดเจ็ต

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

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

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

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

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

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

Android มีการสนับสนุนการแจ้งเตือนต่างๆ เช่น

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

เมื่อใช้งานอุปกรณ์ Android เมื่อมีการแสดงการแจ้งเตือนดังกล่าว จะต้องใช้การแจ้งเตือน Rich and Ups-up อย่างถูกต้อง และมีชื่อ/ชื่อ ไอคอน ข้อความตามที่ระบุไว้ใน Android API

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

การใช้งานอุปกรณ์ที่รองรับฟีเจอร์ DND (ห้ามรบกวน) ต้องเป็นไปตามข้อกำหนดต่อไปนี้

• คุณต้องใช้กิจกรรมที่จะตอบสนองต่อ Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS ซึ่งสำหรับการใช้กับ UI_MODE_TYPE_NORMAL นั้น ต้องเป็นกิจกรรมที่ผู้ใช้สามารถให้สิทธิ์หรือปฏิเสธการเข้าถึงแอปในการกำหนดค่านโยบาย DND ได้
• เมื่อการใช้อุปกรณ์ระบุวิธีการให้ผู้ใช้ให้สิทธิ์หรือปฏิเสธแอปของบุคคลที่สามในการเข้าถึงการกำหนดค่านโยบาย DND ให้แสดงกฎ DND อัตโนมัติที่สร้างโดยแอปพลิเคชันพร้อมกับกฎที่ผู้ใช้สร้างขึ้นและที่กำหนดไว้ล่วงหน้า
• ต้องเป็นไปตามค่า suppressedVisualEffects ที่ส่งผ่าน NotificationManager.Policy และหากแอปตั้งค่าแฟล็ก SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON ไว้ ควรระบุให้ผู้ใช้ทราบว่าเอฟเฟกต์ภาพถูกระงับในเมนูการตั้งค่า DND

3.8.4 ค้นหา

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

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

การใช้อุปกรณ์ Android ควรใช้งาน และการใช้งาน Android Automotive ต้องใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการสนับสนุน

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

3.8.5 ขนมปังปิ้ง

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

3.8.6 ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)

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

3.8.12 ตำแหน่ง

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

3.8.13 Unicode และแบบอักษร

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

อุปกรณ์พกพาของ Android ควรรองรับสีผิวและอีโมจิที่หลากหลายสำหรับครอบครัวตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51

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 ทั้งหมดในช่วงของสัญลักษณ์ละติน กรีก และซีริลลิก ตั้งแต่ Latin, กรีก และซีริลลิก

3.8.14 หลายหน้าต่าง

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

• แอปพลิเคชันสามารถระบุได้ว่าทำงานในโหมดหลายหน้าต่างในไฟล์ AndroidManifest.xml ได้หรือไม่ ไม่ว่าจะอย่างชัดแจ้งผ่านแอตทริบิวต์ android:resizeableActivity หรือโดยปริยายด้วยการใช้ targetSdkVersion > 24. แอปที่ตั้งค่าแอตทริบิวต์นี้เป็น "เท็จ" อย่างชัดเจนในไฟล์ Manifest ต้องไม่เปิดขึ้นในโหมดหลายหน้าต่าง แอปที่ไม่ได้ตั้งค่าแอตทริบิวต์ในไฟล์ Manifest (targetSdkVersion < 24) สามารถเปิดขึ้นในโหมดหลายหน้าต่างได้ แต่ระบบต้องแสดงคำเตือนว่าแอปอาจไม่ทำงานตามที่คาดไว้ในโหมดหลายหน้าต่าง
• การใช้งานอุปกรณ์ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดอิสระ หากทั้งความสูงและความกว้างหน้าจอต่ำกว่า 440 dp
• การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ xlarge ควรรองรับโหมดรูปแบบอิสระ
• การใช้งานอุปกรณ์ทีวี Android ต้องรองรับโหมดการแสดงภาพซ้อนภาพ (PIP) หลายหน้าต่าง และวางหลายหน้าต่าง PIP ที่มุมขวาบนเมื่อ PIP เปิดอยู่
• การใช้งานอุปกรณ์ที่รองรับโหมด PIP หลายหน้าต่าง ต้องจัดสรรอย่างน้อย 240x135 dp สำหรับหน้าต่าง PIP
• หากระบบรองรับโหมดหลายหน้าต่าง PIP ต้องใช้คีย์ KeyEvent.KEYCODE_WINDOW เพื่อควบคุมหน้าต่าง PIP มิเช่นนั้น คีย์ต้องใช้ได้กับกิจกรรมที่ทำงานอยู่เบื้องหน้า

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

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

3.9.1 การจัดสรรอุปกรณ์

3.9.1.1 การจัดสรรเจ้าของอุปกรณ์

หากการใช้งานอุปกรณ์ประกาศฟีเจอร์ android.software.device_admin อุปกรณ์นั้นต้องใช้การจัดสรรแอป Device Owner ของแอปพลิเคชัน Device Policy Client (DPC) ตามที่ระบุไว้ด้านล่าง

• เมื่อติดตั้งอุปกรณ์โดยยังไม่มีการกําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
  • ต้องรายงาน true เนื่องจาก DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
  • ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์เพื่อตอบสนองต่อการดำเนินการของ Intent android.app.action.PROVISION_MANAGED_DEVICE
  • ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่านแฟล็กฟีเจอร์ android.hardware.nfc และได้รับข้อความ NFC ที่มีระเบียนประเภท MIME MIME_TYPE_PROVISIONING_NFC
• เมื่อติดตั้งอุปกรณ์มีข้อมูลผู้ใช้ จะดำเนินการดังนี้
  • ต้องรายงาน false สำหรับ DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
  • ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป

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

3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ

หากการใช้งานอุปกรณ์ประกาศว่า android.software.managed_users ต้องลงทะเบียนแอปพลิเคชัน Device Policy Controller (DPC) เป็นเจ้าของโปรไฟล์ที่มีการจัดการใหม่ได้

กระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (ขั้นตอนที่เริ่มต้นโดย android.app.action.PROVISION_MANAGED_PROFILE) ประสบการณ์ของผู้ใช้ต้องสอดคล้องกับการใช้งาน AOSP

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

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

3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ

อุปกรณ์ที่สามารถใช้งานโปรไฟล์ที่มีการจัดการได้ คืออุปกรณ์ที่มีคุณสมบัติดังนี้

• ประกาศ android.software.device_admin (ดูส่วน 3.9 การดูแลระบบอุปกรณ์ )
• ไม่ใช่อุปกรณ์ที่มี RAM ต่ำ (ดูหัวข้อ 7.6.1 )
• จัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน (ดูส่วนที่ 7.6.2)

อุปกรณ์ที่สามารถใช้งานโปรไฟล์ที่มีการจัดการได้ต้องมีลักษณะดังนี้

• ประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม android.software.managed_users
• รองรับโปรไฟล์ที่มีการจัดการผ่าน API ของ android.app.admin.DevicePolicyManager
• อนุญาตให้สร้างโปรไฟล์ที่มีการจัดการเพียงโปรไฟล์เดียว
• ใช้ป้ายไอคอน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ รวมถึงองค์ประกอบ UI อื่นๆ ที่มีตราสถานะ เช่น ล่าสุดและ การแจ้งเตือน
• แสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อระบุเมื่อผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
• แสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการหากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ภายในโปรไฟล์ที่มีการจัดการ
• หากโปรไฟล์ที่มีการจัดการมีอยู่ ให้แสดงตัวเลือกการแสดงผลใน Intent "ตัวเลือก" เพื่ออนุญาตให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากเปิดใช้โดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
• เมื่อมีโปรไฟล์ที่มีการจัดการอยู่ ให้แสดงพื้นที่เก็บข้อมูลผู้ใช้ดังต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
  • แยกการพิจารณาการใช้งานแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
  • การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการโดยอิสระ
  • การจัดการอิสระของแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
  • การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
• ตรวจสอบว่าโปรแกรมโทรศัพท์ รายชื่อติดต่อ และแอปพลิเคชันรับส่งข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลักได้ หากตัวควบคุมนโยบายด้านอุปกรณ์อนุญาต เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนระหว่างสายและสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อติดต่อดังกล่าวควรมีป้ายติดป้ายเดียวกับที่ใช้เพื่อระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
• ต้องตรวจสอบว่าโปรไฟล์นั้นเป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่ใช้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
• รองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากที่เป็นไปตามข้อกำหนดต่อไปนี้ เพื่อให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการ
  • การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ DevicePolicyManager.ACTION_SET_NEW_PASSWORD และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ
  • ข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้ที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกันกับโปรไฟล์หลักตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
  • นโยบายรหัสผ่านของ DPC ต้องมีผลเฉพาะกับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการ เว้นแต่ว่ามีการเรียกใช้อินสแตนซ์ DevicePolicyManager ที่แสดงผลโดย getParentProfileInstance

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

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

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

• การติดตั้งใช้งาน Android Automotive ควรมีการใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ที่สอดคล้องกับการใช้งานเริ่มต้นของ Android
• การติดตั้งใช้งานอุปกรณ์ (ยกเว้น Android Automotive) ต้องมีการใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ที่สอดคล้องกับการติดตั้งใช้งานเริ่มต้นของ Android
• การใช้งานอุปกรณ์ (ยกเว้น Android Automotive) ต้องรองรับการใช้งานบริการช่วยเหลือพิเศษของบุคคลที่สามผ่าน android.accessibilityservice API
• การติดตั้งใช้งานอุปกรณ์ (ยกเว้น Android Automotive) จะต้องสร้าง AccessibilityEvents และนำส่งเหตุการณ์เหล่านี้ไปยังการใช้งาน AccessibilityService ที่ลงทะเบียนไว้ทั้งหมดในลักษณะที่สอดคล้องกับการติดตั้งใช้งาน Android เริ่มต้น

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

• เราขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีเอาต์พุตเสียงเพื่อให้ใช้บริการการช่วยเหลือพิเศษในอุปกรณ์ได้เทียบเท่าหรือเกินฟังก์ชันการทำงานของ TalkBack** และบริการการช่วยเหลือพิเศษด้วยการเข้าถึงด้วยสวิตช์ (https://github.com/google/Talkback)

• อุปกรณ์ Android Watch ที่มีเอาต์พุตเสียงควรมีการใช้งานบริการการช่วยเหลือพิเศษในอุปกรณ์ที่เทียบเท่าหรือเกินฟังก์ชันของบริการการช่วยเหลือพิเศษของ TalkBack (https://github.com/google/Talkback)
• การใช้งานอุปกรณ์ควรมีกลไกในขั้นตอนการตั้งค่าที่พร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผล และท่าทางสัมผัสการขยาย

** สำหรับภาษาที่การอ่านออกเสียงข้อความรองรับ

นอกจากนี้ โปรดทราบว่าหากอุปกรณ์มีบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า ต้องเป็นแอป {directBootAware} ที่รับรู้การเปิดเครื่องโดยตรงหากอุปกรณ์มีพื้นที่เก็บข้อมูลที่เข้ารหัสโดยใช้ File-Based Encryption (FBE)

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

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

การติดตั้งใช้งาน Android Automotive

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

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

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

3.12 เฟรมเวิร์กอินพุตทีวี

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

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

3.12.1. แอป TV

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

แอป TV ต้องมีสิ่งอำนวยความสะดวกในการติดตั้งและใช้ช่องทีวี และตรงตามข้อกำหนดต่อไปนี้

• การใช้งานอุปกรณ์ต้องอนุญาตให้ติดตั้งและจัดการอินพุตที่อิงตาม TIF ของบุคคลที่สาม ( อินพุตของบุคคลที่สาม)
• การใช้งานอุปกรณ์อาจมีการแยกภาพระหว่างอินพุตตาม TIF ที่ติดตั้งไว้ล่วงหน้า (อินพุตที่ติดตั้งไว้) และอินพุตของบุคคลที่สาม
• การใช้งานอุปกรณ์ต้องไม่แสดงอินพุตของบุคคลที่สามมากกว่า 1 ครั้งต่อแอป TV (เช่น การขยายรายการอินพุตของบุคคลที่สามจากแอป TV)

3.12.1.1 คู่มือโปรแกรมอิเล็กทรอนิกส์

การใช้งานอุปกรณ์ Android TV ต้องแสดงการวางซ้อนที่ให้ข้อมูลและโต้ตอบได้ ซึ่งต้องรวมคู่มือรายการทีวีอิเล็กทรอนิกส์ (EPG) ที่สร้างขึ้นจากค่าในช่อง TvContract.Programs EPG ต้องเป็นไปตามข้อกำหนดต่อไปนี้

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

3.12.1.2 การไปยังรายการต่างๆ

แอป TV ต้องอนุญาตการนำทางสำหรับฟังก์ชันต่อไปนี้ผ่านแป้น D-pad, ย้อนกลับ และ Home ในอุปกรณ์อินพุตของอุปกรณ์ Android TV (เช่น รีโมตคอนโทรล แอปพลิเคชันรีโมตคอนโทรล หรือตัวควบคุมเกม)

• การเปลี่ยนช่องทีวี
• กำลังเปิด EPG
• การกำหนดค่าและปรับแต่งอินพุตตาม TIF ของบุคคลที่สาม
• กำลังเปิดเมนูการตั้งค่า

แอป TV ควรส่งเหตุการณ์สำคัญไปยังอินพุต HDMI ผ่าน CEC

3.12.1.3 การลิงก์แอปอินพุตทีวี

การใช้งานอุปกรณ์ Android TV ต้องรองรับการลิงก์แอปอินพุตทีวี ซึ่งอนุญาตให้อินพุตทั้งหมดแสดงลิงก์กิจกรรมจากกิจกรรมปัจจุบันไปยังกิจกรรมอื่น (เช่น ลิงก์จากรายการสดไปยังเนื้อหาที่เกี่ยวข้อง) แอปทีวีต้องแสดงการลิงก์แอปอินพุตทีวีเมื่อมีให้

3.12.1.4 การเปลี่ยนเวลา

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

3.12.1.5 การบันทึกรายการทีวี

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

3.13 การตั้งค่าด่วน

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

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

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

3.14 API UI ของยานพาหนะ

3.14.1. UI สื่อของยานพาหนะ

การติดตั้งใช้งานอุปกรณ์ที่ประกาศการรองรับยานยนต์ต้องมีเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ MediaBrowser และ MediaSession API

เฟรมเวิร์ก UI ที่รองรับแอปของบุคคลที่สามที่ใช้ MediaBrowser และ MediaSession มีข้อกำหนดด้านการแสดงผลดังนี้

• ต้องแสดงไอคอน MediaItem และไอคอนการแจ้งเตือนโดยไม่เปลี่ยนแปลง
• ต้องแสดงรายการเหล่านั้นตามที่อธิบายไว้โดย MediaSession เช่น ข้อมูลเมตา ไอคอน ภาพ
• ต้องแสดงชื่อแอป
• ต้องมีลิ้นชักเพื่อแสดงลำดับชั้นของ MediaBrowser

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

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

ตัวจัดการแพ็กเกจต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v2 และการลงนาม JAR

การติดตั้งใช้งานอุปกรณ์ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik bytescode หรือ RenderScript ไบต์โค้ดในรูปแบบที่จะทำให้ไฟล์เหล่านั้นติดตั้งและทำงานอย่างไม่ถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้

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

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

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

• ต้องรองรับรูปแบบสื่อหลักที่ระบุในเอกสารประกอบของ Android SDK เว้นแต่จะได้รับอนุญาตอย่างชัดแจ้งในเอกสารนี้

• ต้องรองรับรูปแบบสื่อ โปรแกรมเปลี่ยนไฟล์ โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในตารางด้านล่างและรายงานผ่าน MediaCodecList

• ต้องสามารถถอดรหัสโปรไฟล์ทั้งหมดที่รายงานใน CamcorderProfile ของตน

• ต้องสามารถถอดรหัสทุกรูปแบบที่สามารถเข้ารหัสได้ ซึ่งรวมถึงบิตสตรีมทั้งหมดที่โปรแกรมเปลี่ยนไฟล์สร้างขึ้น

ตัวแปลงรหัสควรมุ่งเป้าไปที่เวลาในการตอบสนองของตัวแปลงรหัสขั้นต่ำ ซึ่งก็คือตัวแปลงรหัส

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

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

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

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

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
โปรไฟล์ MPEG-4 AAC (AAC LC)	ต้องระบุ 1	ต้องระบุ	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 2 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS RAW AAC (.aac, ถอดรหัสใน Android 3.1 ขึ้นไป, เข้ารหัสใน Android 4.0 ขึ้นไป, ไม่รองรับ ADIF) MPEG-TS (.ts, ไม่สามารถค้นหาได้, Android 3.0 ขึ้นไป)
โปรไฟล์ MPEG-4 HE AAC (AAC+)	ต้องระบุ 1 (Android 4.1 ขึ้นไป)	ต้องระบุ	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 2 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
MPEG-4 HE AACv2 โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว)		ต้องระบุ	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 2 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC)	ต้องระบุ 1 (Android 4.1 ขึ้นไป)	ต้องระบุ (Android 4.1 ขึ้นไป)	รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
AMR-NB	ต้องระบุ 3	ต้องระบุ 3	สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8 kHz	3GPP (.3gp)
AMR-WB	ต้องระบุ 3	ต้องระบุ 3	9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s แบบสุ่มตัวอย่างที่ 16 kHz
FLAC		ต้องระบุ (Android 3.1 ขึ้นไป)	โมโน/สเตอริโอ (ไม่ใช่หลายช่องทาง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz สำหรับอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากเครื่องวัดอัตราการสุ่มตัวอย่างเสียงต่ำ 48 ถึง 44.1 kHz ไม่มีตัวกรองแบบ Low Pass) 16 บิตแนะนำ ไม่มีการใช้หารสำหรับ 24 บิต	FLAC (.flac) เท่านั้น
MP3		ต้องระบุ	ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR)	MP3 (.mp3)
MIDI		ต้องระบุ	MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ XMF สำหรับอุปกรณ์เคลื่อนที่ รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody	ประเภท 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.iMelody)
Vorbis		ต้องระบุ		Ogg (.ogg) Matroska (.mkv, Android 4.0 ขึ้นไป)
PCM/WAVE	ต้องระบุ 4 (Android 4.1 ขึ้นไป)	ต้องระบุ	PCM เชิงเส้น 16 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM แบบ RAW ที่ความถี่ 8000, 11025, 16000 และ 44100 Hz	WAVE (.wav)
Opus		ต้องระบุ (Android 5.0 ขึ้นไป)		มาโทรสกา (.mkv), Ogg(.ogg)

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

2 การบันทึกหรือการเล่นอาจทำในแบบโมโนหรือสเตอริโอ แต่การถอดรหัสของบัฟเฟอร์อินพุต AAC ของสตรีมหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านตัวถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec API จะต้องมีการสนับสนุนดังต่อไปนี้:

• สามารถถอดรหัสได้โดยไม่มีการดาวน์มิกซ์ (เช่น ต้องถอดรหัสสตรีม 5.0 AAC เป็น PCM 5 ช่อง ต้องถอดรหัสสตรีม 5.1 AAC เป็น PCM 6 ช่อง)
• ข้อมูลเมตาของช่วงไดนามิก ตามที่ระบุไว้ใน "การควบคุมช่วงไดนามิก (DRC)" ใน ISO/IEC 14496-3 และคีย์ DRC android.media.MediaFormat เพื่อกำหนดค่าพฤติกรรมที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ AAC DRC ได้รับการเริ่มใช้ใน API 21 ได้แก่ KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_ENCODED_TARGET

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

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

5.1.2 ตัวแปลงรหัสภาพ

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG	ต้องระบุ	ต้องระบุ	ฐาน +โพรเกรสซีฟ	JPEG (.jpg)
GIF		ต้องระบุ		GIF (.gif)
PNG	ต้องระบุ	ต้องระบุ		PNG (.png)
BMP		ต้องระบุ		BMP (.bmp)
WebP	ต้องระบุ	ต้องระบุ		WebP (.webp)
แบบข้อมูลดิบ		ต้องระบุ		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3 ตัวแปลงรหัสวิดีโอ

• ตัวแปลงรหัสการโฆษณาการสนับสนุนโปรไฟล์ HDR ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ของ HDR

• หากตัวแปลงรหัสสื่อโฆษณาการสนับสนุนการรีเฟรชภายใน ตัวแปลงรหัสต้องสนับสนุนช่วงเวลาการรีเฟรชในช่วง 10 - 60 เฟรมและทำงานอย่างถูกต้องภายใน 20% ของระยะเวลาการรีเฟรชที่กำหนดค่าไว้

• ตัวแปลงสัญญาณวิดีโอต้องรองรับขนาดเอาต์พุตและไบต์บัฟเฟอร์ข้อมูลอินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดขนาดใหญ่ที่สุดตามที่มาตรฐานและการกำหนดค่ากำหนดไว้ แต่ต้องไม่ครอบคลุมองค์ประกอบโดยรวม

• โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 (COLOR_FormatYUV420แบบยืดหยุ่น)

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	ประเภทไฟล์ที่รองรับ/ รูปแบบคอนเทนเนอร์
H.263	พฤษภาคม	พฤษภาคม		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	ต้องระบุ 2	ต้องระบุ 2	ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, เสียง AAC เท่านั้น, ไม่สามารถค้นหาได้, Android 3.0 ขึ้นไป)
HEVC ของ H.265		ต้องระบุ 5	ดูรายละเอียดในส่วนที่ 5.3	MPEG-4 (.mp4)
MPEG-2		แนะนำอย่างยิ่ง 6	โปรไฟล์หลัก	MPEG2-TS
MPEG-4 SP		ต้องระบุ 2		3GPP (.3gp)
VP8 3	ต้องระบุ 2 (Android 4.3 ขึ้นไป)	ต้องระบุ 2 (Android 2.3.3 ขึ้นไป)	ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3	WebM (.webm) Matroska (.mkv, Android 4.0 ขึ้นไป) 4
VP9		ต้องระบุ 2 (Android 4.4 ขึ้นไป)	ดูรายละเอียดในส่วนที่ 5.3	WebM (.webm) Matroska (.mkv, Android 4.0 ขึ้นไป) 4

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

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

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

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

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

6 มีผลเฉพาะกับการใช้งานอุปกรณ์ Android TV เท่านั้น

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

โปรแกรมเปลี่ยนไฟล์วิดีโอ H.264, VP8, VP9 และ HEVC

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

โปรแกรมเปลี่ยนไฟล์วิดีโอ H.263 และ MPEG-4 ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิก

โปรแกรมเปลี่ยนไฟล์วิดีโอทั้งหมดควรตรงตามเป้าหมายอัตราบิตต่อไปนี้บนหน้าต่างเลื่อน 2 หน้าต่าง

• ไม่ควรเกิน 15% ของอัตราบิตระหว่างช่วงเวลาภายในเฟรม (I-Frame)
• อัตราบิตไม่ควรเกิน ~100% ในหน้าต่างเลื่อน 1 วินาที

5.2.1 H.263

การใช้งานอุปกรณ์ Android ที่มีโปรแกรมเปลี่ยนไฟล์ H.263 ต้องรองรับโปรไฟล์พื้นฐานระดับ 45

5.2.2 H-264

การใช้งานอุปกรณ์ Android ที่รองรับตัวแปลงรหัส H.264

• ต้องรองรับโปรไฟล์พื้นฐานระดับ 3
  แต่การรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS กับโปรไฟล์พื้นฐานเพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android อื่นๆ
• ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
• ควรรองรับโปรไฟล์หลักระดับ 4
• ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
• นอกจากนี้ อุปกรณ์ Android TV ขอแนะนำอย่างยิ่งให้เข้ารหัสวิดีโอ HD 1080p ที่ 30 fps

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p 1	HD 1080p 1
ความละเอียดของวิดีโอ	320 x 240 พิกเซล	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	20 FPS	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	384 Kbps	2 Mbps	4 Mbps	10 Mbps

1 เมื่อฮาร์ดแวร์รองรับแต่เป็นอุปกรณ์ Android TV ที่แนะนำอย่างยิ่ง

5.2.3 VP8

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

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p 1	HD 1080p 1
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	4 Mbps	10 Mbps

1 เมื่อฮาร์ดแวร์รองรับ

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

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

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

• การใช้งานที่รองรับตัวถอดรหัส Dolby Vision -

• ต้องมีเครื่องมือแยกข้อมูลที่รองรับ Dolby Vision

• ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องในหน้าจอของอุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)

• การใช้งานที่มีเครื่องมือแยกข้อมูลที่รองรับ Dolby Vision ต้องตั้งค่าดัชนีการติดตามของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับดัชนีการติดตามของเลเยอร์ Dolby Vision แบบรวม

5.3.1 MPEG-2

อุปกรณ์ Android ที่มีตัวถอดรหัส MPEG-2 ต้องรองรับโปรไฟล์หลักระดับสูง

5.3.2 H.263

การใช้งานอุปกรณ์ Android ที่ใช้ตัวถอดรหัส H.263 ต้องรองรับโปรไฟล์ Baseline ระดับ 30 และ 45

5.3.3 MPEG-4

การใช้อุปกรณ์ Android ที่ใช้ตัวถอดรหัส MPEG-4 ต้องรองรับ Simple Profile Level 3

5.3.4 H.264

การติดตั้งใช้งานอุปกรณ์ Android ที่ใช้ตัวถอดรหัส H.264

• ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน
  ระบบรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) ไม่บังคับ
• ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงอยู่ในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐานและโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
• ควรสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
• นอกจากนี้ อุปกรณ์ Android TV ได้แก่
  • ต้องรองรับ High Profile ระดับ 4.2 และโปรไฟล์การถอดรหัส HD 1080p60
  • ต้องถอดรหัสวิดีโอที่มีโปรไฟล์ HD ทั้ง 2 โปรไฟล์ได้ตามที่ระบุไว้ในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์พื้นฐาน โปรไฟล์หลัก หรือโปรไฟล์ระดับสูงระดับ 4.2

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p 1	HD 1080p 1
ความละเอียดของวิดีโอ	320 x 240 พิกเซล	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	60 FPS	30 FPS (60 FPS 2)
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 ต้องระบุเมื่อความสูงตามที่เมธอด Display.getSupportedModes() รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ

2 ต้องระบุสำหรับการใช้งานอุปกรณ์ Android TV

5.3.5 H.265 (HEVC)

การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส H.265 ตามที่อธิบายไว้ในส่วนที่ 5.1.3

• ต้องรองรับโปรไฟล์หลักระดับ 3 หลักและโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
• ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีตัวถอดรหัสฮาร์ดแวร์
• นอกจากนี้ อุปกรณ์ Android TV ยังมีลักษณะดังนี้
• ต้องรองรับโปรไฟล์การถอดรหัสแบบ HD 720p
• แนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัสแบบ HD 1080p หากรองรับโปรไฟล์การถอดรหัส HD 1080p โปรไฟล์ดังกล่าวต้องรองรับ Main Profile ระดับ Main 4.1
• ควรรองรับโปรไฟล์การถอดรหัส UHD หากโปรไฟล์การถอดรหัส UHD ได้รับการสนับสนุน ตัวแปลงรหัสต้องรองรับโปรไฟล์หลักของระดับ Main10 ระดับ 5

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	352 x 288 พิกเซล	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล	3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 FPS (60 FPS 1)	60 FPS
อัตราบิตของวิดีโอ	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 ต้องระบุสำหรับการใช้งานอุปกรณ์ Android TV ที่มีการถอดรหัสฮาร์ดแวร์ H.265

5.3.6 VP8

การติดตั้งใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส VP8 ตามที่อธิบายไว้ในส่วนที่ 5.1.3

• ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้
• อุปกรณ์ Android TV ต้องรองรับโปรไฟล์การถอดรหัสแบบ HD 1080p60

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p 1	HD 1080p 1
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 FPS (60 FPS 2)	30 (60 FPS 2)
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 ต้องระบุเมื่อความสูงตามที่เมธอด Display.getSupportedModes() รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ

2 ต้องระบุสำหรับการใช้งานอุปกรณ์ Android TV

5.3.7 VP9

การติดตั้งใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส VP9 ตามที่อธิบายไว้ในส่วนที่ 5.1.3

• ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
• ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีเครื่องมือถอดรหัสฮาร์ดแวร์

• นอกจากนี้ อุปกรณ์ Android TV ยังมีลักษณะดังนี้

  • ต้องรองรับโปรไฟล์การถอดรหัสแบบ HD 720p
  • แนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัสแบบ HD 1080p
  • ควรรองรับโปรไฟล์การถอดรหัส UHD หากรองรับโปรไฟล์การถอดรหัสวิดีโอ UHD โปรไฟล์ดังกล่าวต้องรองรับความลึกของสี 8 บิตและควรรองรับ VP9 Profile 2 (10 บิต)

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล	3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 FPS (60 FPS 1)	60 FPS
อัตราบิตของวิดีโอ	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 ต้องระบุ 1 สำหรับการใช้งานอุปกรณ์ Android TV ที่มีการถอดรหัสฮาร์ดแวร์ VP9

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

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

5.4.1 การบันทึกเสียงแบบ RAW

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

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

การเก็บอัตราการสุ่มตัวอย่างข้างต้นจะต้องทำโดยไม่มีการสุ่มตัวอย่างเพิ่มเติม และการสุ่มตัวอย่างลดลงต้องมีตัวกรองการลบรอยหยักที่เหมาะสม

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

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

หากมีการรองรับอัตราการสุ่มตัวอย่างข้างต้น จะต้องดำเนินการบันทึกโดยไม่มีการสุ่มตัวอย่างในอัตราส่วนที่สูงกว่า 16000:22050 หรือ 44100:48000 การสุ่มตัวอย่างเพิ่มขึ้นหรือลดลงจะต้องมีตัวกรองการลบรอยหยักที่เหมาะสม

5.4.2 จับภาพสำหรับการจดจำเสียง

แหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ต้องสนับสนุนการบันทึกที่อัตราการสุ่มตัวอย่าง 44100 และ 48000

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

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

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

• อัตราการสุ่มตัวอย่าง : 24,000, 48,000

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

Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการใช้งานในอุปกรณ์ การใช้งานอุปกรณ์ที่ประกาศฟีเจอร์ android.hardware.audio.output:

• ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect คือ Equalizer, Loudnessร้านเพิ่มประสิทธิภาพ
• ต้องรองรับการใช้งาน 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 TV ต้องรวมถึงการรองรับระดับเสียงหลักของระบบและการลดระดับเสียงเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตส่งผ่านเสียงแบบบีบอัด (ที่ไม่มีการถอดรหัสเสียงในอุปกรณ์)

การใช้อุปกรณ์ Android Automotive ควรอนุญาตให้ปรับระดับเสียงในแต่ละสตรีมเสียงแยกกันโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย AudioAttributes และการใช้เสียงในรถยนต์ตามที่สาธารณะกำหนดไว้ใน android.car.CarAudioManager

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

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

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

• เวลาในการตอบสนองเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM และเมื่อเสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ตัวแปลงสัญญาณหรือสัญญาณในอุปกรณ์ออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
• เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
• เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองเอาต์พุตสำหรับเฟรมที่ตามมาหลังจากที่อุปกรณ์เล่นเสียง
• เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ตัวแปลงสัญญาณในอุปกรณ์หรือสัญญาณเข้ามาในอุปกรณ์ผ่านพอร์ต และเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM ที่สอดคล้องกัน
• อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
• เวลาในการตอบสนองแบบ Cold input ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
• เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมที่ตามมาขณะที่อุปกรณ์บันทึกเสียง
• Jitter เอาต์พุต Cold ความแปรปรวนของการวัดที่แยกกันสำหรับค่าเวลาในการตอบสนองของเอาต์พุตเย็น
• ความแปรปรวนของอินพุตเย็น ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของอินพุตเย็น
• เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่อง เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่อง บวกกับช่วงเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์จะช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาสําหรับแอปเพื่อลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
• API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK

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

• เวลาในการตอบสนองของเอาต์พุต Cold 100 มิลลิวินาทีหรือน้อยกว่า
• เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
• ลด Jitter เอาต์พุต Cold

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

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

• เวลาในการตอบสนองการป้อนข้อมูลแบบ Cold ระดับ 100 มิลลิวินาทีหรือน้อยกว่า
• เวลาในการตอบสนองการป้อนข้อมูลอย่างต่อเนื่องไม่เกิน 30 มิลลิวินาที
• เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
• ลดความแปรปรวนของอินพุต Coldอินพุต

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

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

• HTTP(S) Progressive Streaming
  ตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ต้องได้รับการสนับสนุนบน HTTP(S)

• โปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7
  ต้องมีการรองรับรูปแบบกลุ่มสื่อต่อไปนี้

รูปแบบกลุ่ม	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
สตรีมส่ง MPEG-2	ISO 13818	ตัวแปลงรหัสวิดีโอ: H264 AVC MPEG-4 SP MPEG-2 โปรดดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP ในหัวข้อ 5.1.3 และ MPEG-2 ตัวแปลงสัญญาณเสียง: AAC โปรดดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.1
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3	ISO 13818-7	ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1
WebVTT	WebVTT

• RTSP (RTP, SDP)

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

ชื่อโปรไฟล์	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC	RFC 6184	ดูรายละเอียดเกี่ยวกับ H264 AVC ในหัวข้อ 5.1.3
MP4A-ลาตินอเมริกา	RFC 6416	ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1
H263-1998	RFC 3551 RFC 4629 RFC 2190	ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3
H263-2000	RFC 4629	ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3
AMR	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-NB ในหัวข้อ 5.1.1
AMR-WB	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-WB ในหัวข้อ 5.1.1
MP4V-ES	RFC 6416	ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ในหัวข้อ 5.1.3
Mpeg4-generic	RFC 3640	ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1
MP2T	RFC 2250	ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming

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

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

5.9 Musical Instrument Digital Interface (MIDI)

หากการใช้งานอุปกรณ์รองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน) และรองรับการส่งฮาร์ดแวร์ MIDI ทั้งหมดต่อไปนี้ที่ให้บริการการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป เราขอแนะนำเป็นอย่างยิ่งให้รายงานการสนับสนุนสำหรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager

การรับส่งข้อมูลฮาร์ดแวร์ที่ใช้ MIDI ได้มีดังนี้

• โหมดโฮสต์ USB (ส่วนที่ 7.7 USB)
• โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7 USB)
• MIDI ผ่าน Bluetooth LE ดำเนินการในบทบาทหลัก (ส่วนที่ 7.4.3 บลูทูธ)

ในทางกลับกัน หากการใช้งานอุปกรณ์ให้การเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI ผ่านการส่งฮาร์ดแวร์ที่สามารถ MIDI ได้ตามที่ระบุไว้ข้างต้น แต่ไม่สนับสนุน MIDI ผ่านการส่งฮาร์ดแวร์ดังกล่าว อุปกรณ์จะต้องไม่รายงานการสนับสนุนฟีเจอร์ android.software.midi

5.10 เสียงระดับมืออาชีพ

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดทั้งหมดต่อไปนี้ เราขอแนะนำเป็นอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager

• การใช้งานอุปกรณ์ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency
• เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในส่วน 5.6 เวลาในการตอบสนองของเสียงต้องไม่เกิน 20 มิลลิวินาที และควรไม่เกิน 10 มิลลิวินาทีเมื่อเทียบกับเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
• หากอุปกรณ์มีช่องเสียบหูฟังขนาด 3.5 มม. ตัวนำ 4 ตัว เวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องต้องอยู่ที่ 20 มิลลิวินาทีหรือน้อยกว่าในเส้นทางช่องเสียบเสียง และควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าที่เส้นทางช่องเสียบหูฟัง
• การใช้งานอุปกรณ์ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
• โหมดโฮสต์ USB ต้องใช้คลาสเสียง USB
• หากอุปกรณ์มีพอร์ต HDMI การใช้งานอุปกรณ์ต้องรองรับเอาต์พุตแบบสเตอริโอและแชนเนล 8 ช่องที่ความลึก 20 บิตหรือ 24 บิตและ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มข้อมูลซ้ำ
• การใช้งานอุปกรณ์ต้องรายงานการสนับสนุนสำหรับฟีเจอร์ android.software.midi
• หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม.ตัวนำ 4 ตัว เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์เพื่อให้สอดคล้องกับส่วนข้อมูลจำเพาะของอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อกำหนดสำหรับชุดหูฟังแบบมีสาย (v1.1)

ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB โดยใช้ API คิวบัฟเฟอร์ PCM ของ OpenSL ES

นอกจากนี้ การใช้งานอุปกรณ์ที่รายงานการรองรับฟีเจอร์นี้ควรมีลักษณะดังนี้

• มอบประสิทธิภาพของ CPU ในระดับที่ยั่งยืนขณะที่เสียงเล่นอยู่
• ลดความไม่ถูกต้องของนาฬิกาและการคลาดเคลื่อนเมื่อเทียบกับเวลามาตรฐาน
• ลดการเลื่อนของนาฬิกาเสียงให้สัมพันธ์กับ CPU CLOCK_MONOTONIC ให้น้อยที่สุดเมื่อทั้งคู่ทำงานอยู่
• ลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
• ลดเวลาในการตอบสนองของเสียงเมื่อใช้เสียงดิจิทัลแบบ USB
• บันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
• ลด Jitter ในช่วงการป้อน Callback ที่บัฟเฟอร์เสียงเสร็จสมบูรณ์ เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
• ให้สัญญาณเสียงที่มีประสิทธิภาพต่ำ (เอาต์พุต) หรือการรบกวนมากเกินไป (อินพุต) ภายใต้การใช้งานปกติตามเวลาในการตอบสนองที่รายงาน
• ระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
• ลดเวลาในการตอบสนองเฉลี่ยของ MIDI ในการรับส่งข้อมูลทั้งหมด
• ลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
• ระบุการประทับเวลา MIDI ที่ถูกต้องสำหรับการรับส่งข้อมูลทั้งหมด
• ลดเสียงรบกวนของสัญญาณเสียงบนตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
• ระบุความแตกต่างของนาฬิการะหว่างอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องเป็น 0 เมื่อทั้ง 2 ฝั่งทำงานอยู่ ตัวอย่างของจุดสิ้นสุดที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตช่องเสียบหูฟัง
• จัดการ Callback ที่สมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องในเทรดเดียวกันเมื่อใช้งานทั้ง 2 ฝั่ง และป้อนเอาต์พุต Callback ทันทีหลังจาก Callback อินพุต หรือหากจัดการ Callback ในเทรดเดียวกันไม่ได้ ให้ป้อนเอาต์พุต Callback หลังจากป้อน Callback ของอินพุตเพื่อให้แอปพลิเคชันกำหนดเวลาด้านอินพุตและเอาต์พุตที่สอดคล้องกัน
• ลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง
• ลดเวลาในการตอบสนองของการแตะ
• ลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสเมื่อโหลด (Jitter)

5.11 จับภาพสำหรับที่ไม่ได้ประมวลผล

ตั้งแต่ Android 7.0 เป็นต้นไป มีการเพิ่มแหล่งที่มาของการบันทึกใหม่ คุณสามารถเข้าถึงได้โดยใช้แหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES จะสามารถเข้าถึงได้โดยใช้ค่าระเบียนที่กำหนดล่วงหน้า SL_ANDROID_RECORDING_PRESET_UNPROCESSED

อุปกรณ์ต้องมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้ทั้งหมดจึงจะรายงานการรองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผลผ่านพร็อพเพอร์ตี้ android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED ได้

• อุปกรณ์ต้องแสดงลักษณะแอมพลิจูดระหว่างความถี่แบบราบโดยประมาณในช่วงความถี่กลาง โดยเฉพาะอย่างยิ่ง ±10dB ตั้งแต่ 100 Hz ถึง 7000 Hz

• อุปกรณ์ต้องแสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลาง

• อุปกรณ์ต้องแสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 7000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลาง

• ความไวของอินพุตเสียงต้องตั้งค่าให้แหล่งสัญญาณเสียงไซนัสอยัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ตอบสนองกับ RMS ที่ 520 สําหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างความแม่นยำแบบ 2 เท่า)

• SNR > 60 dB (ความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่าของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)

• ความบิดเบี้ยวแบบฮาร์มอนิกทั้งหมดต้องน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน

• การประมวลผลสัญญาณที่ใช้ได้เพียงอย่างเดียวในเส้นทางคือตัวคูณระดับเพื่อนำระดับไปยังช่วงที่ต้องการ ตัวคูณระดับนี้ต้องไม่ทำให้เกิดการหน่วงเวลาหรือเวลาในการตอบสนองต่อเส้นทางของสัญญาณ

• ไม่อนุญาตให้ประมวลผลสัญญาณอื่นๆ ในเส้นทาง เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง หากมีการประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม ต้องปิดใช้และทำให้เกิดการหน่วงเวลาเป็น 0 หรือเวลาในการตอบสนองเพิ่มเติมให้กับเส้นทางสัญญาณได้อย่างมีประสิทธิภาพ

การวัด SPL ทั้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ

สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

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

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

6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

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

• Android Debug Bridge (adb)
  • การใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK รวมถึง dumpsys
  • Daemon ของ adb ฝั่งเซิร์ฟเวอร์ต้องไม่มีการใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge หากอุปกรณ์ละเว้นโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นต้องใช้ Android Debug Bridge ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ 802.11)
  • Android มีการสนับสนุนสำหรับ adb ที่ปลอดภัย Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แล้วที่รู้จัก การใช้งานอุปกรณ์ต้องรองรับ adb ที่ปลอดภัย
• บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)
  • การใช้งานอุปกรณ์ต้องรองรับฟีเจอร์ DDMS ทั้งหมดตามที่บันทึกไว้ใน Android SDK
  • เนื่องจาก ddms ใช้ adb การสนับสนุนสำหรับ ddms ควรไม่ทำงานโดยค่าเริ่มต้น แต่ต้องมีการสนับสนุนทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามด้านบน
• Monkey การใช้งานอุปกรณ์จะต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
• SysTrace
  • การใช้งานอุปกรณ์ต้องรองรับเครื่องมือ Systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องไม่มีการใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้ในการเปิด Systrace
  • ระบบที่ใช้ Linux และระบบ Apple Macintosh ส่วนใหญ่จะจดจำอุปกรณ์ Android โดยใช้เครื่องมือ Android SDK มาตรฐาน โดยไม่ต้องมีการสนับสนุนเพิ่มเติม แต่โดยทั่วไประบบ Microsoft Windows จะต้องใช้ไดรเวอร์สำหรับอุปกรณ์ Android ใหม่ๆ (ตัวอย่างเช่น รหัสผู้ให้บริการใหม่ๆ และบางครั้งรหัสอุปกรณ์ใหม่ก็ต้องใช้ไดรเวอร์ USB ที่กำหนดเองสำหรับระบบ Windows)
  • หากเครื่องมือ adb ไม่รู้จักการใช้งานอุปกรณ์ตามที่ระบุไว้ใน Android SDK มาตรฐาน ผู้ติดตั้งใช้งานอุปกรณ์ต้องให้ไดรเวอร์ Windows ที่ช่วยให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้ ไดรเวอร์เหล่านี้ต้องมีอยู่ในทั้งเวอร์ชัน 32 บิตและ 64 บิตสำหรับ Windows XP, Windows Vista, Windows 7, Windows 8 และ Windows 10

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

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

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

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

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

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

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

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

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

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

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

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

7.1.1.1 ขนาดหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับหน้าจอหลายขนาดและช่วยให้แอปพลิเคชันค้นหาขนาดหน้าจอของอุปกรณ์ (หรือที่เรียกว่า "เลย์เอาต์หน้าจอ") ผ่าน android.content.res.Configuration.screenLayout ได้ด้วย SCREENLAYOUT_SIZE_MASK การใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอที่ถูกต้องตามที่กำหนดไว้ในเอกสาร Android SDK และกำหนดโดยแพลตฟอร์ม Android ต้นทาง กล่าวอย่างเจาะจงคือ การใช้งานอุปกรณ์ "ต้อง" รายงานขนาดหน้าจอที่ถูกต้องตามขนาดหน้าจอพิกเซลอิสระ (dp) แบบไม่ขึ้นอยู่กับความหนาแน่นเชิงตรรกะต่อไปนี้

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

นอกจากนี้:

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

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

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

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

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

• หากกำหนดค่า uiMode เป็น UI_mode_TYPE_Wwatch ค่าสัดส่วนภาพ อาจกำหนดไว้เป็น 1.0 (1:1)
• หากแอปของบุคคลที่สามระบุว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity ค่าสัดส่วนภาพก็จะไม่มีข้อจำกัดใดๆ
• ในกรณีอื่นๆ ทั้งหมด สัดส่วนภาพต้องเป็นค่าระหว่าง 1.3333 (4:3) ถึง 1.86 (ประมาณ 16:9) เว้นแต่แอปจะได้ระบุไว้อย่างชัดเจนว่ารองรับสัดส่วนภาพหน้าจอที่สูงกว่าผ่านค่าข้อมูลเมตา maxAspectRatio

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

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

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi (Xhdpi)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

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

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

• ขนาดการแสดงผล "ต้องไม่" ปรับขนาดให้ใหญ่กว่า 1.5 เท่าของความหนาแน่นดั้งเดิม หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพซึ่งเล็กกว่า 320dp (เทียบเท่ากับ sw320dp ของตัวระบุทรัพยากร) ขึ้นอยู่กับว่ากรณีใดจะเกิดขึ้นก่อน
• ขนาดการแสดงผลจะต้องไม่เล็กกว่า 0.85 เท่าของความหนาแน่นดั้งเดิม
• เราแนะนำให้กำหนดการปรับขนาดของตัวเลือกการแสดงเนทีฟต่อไปนี้ (ขณะเดียวกันก็ปฏิบัติตามขีดจำกัดที่ระบุไว้ด้านบน) เพื่อให้สามารถใช้งานได้อย่างเหมาะสมและมีขนาดแบบอักษรที่สอดคล้องกัน
• เล็ก: 0.85 เท่า
• ค่าเริ่มต้น: 1 เท่า (ขนาดโฆษณาแบบดิสเพลย์เนทีฟ)
• ใหญ่: 1.15 เท่า
• ใหญ่กว่า: 1.3 เท่า
• ใหญ่ที่สุด 1.45 เท่า

7.1.2 แสดงเมตริก

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

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

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

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

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

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

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

การใช้งานอุปกรณ์ต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ที่รวมอยู่และอธิบายรายละเอียดไว้ในเอกสาร Android SDK การใช้งานอุปกรณ์ควรรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 บนอุปกรณ์ที่รองรับได้ การใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ด้วย ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

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

• API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) ต้องรายงานการรองรับ OpenGL ES 1.0 และ OpenGL ES 2.0
• API เดิมของ C/C++ OpenGL (API ที่พร้อมใช้งานกับแอปผ่าน libGLES_v1CM.so, libGLES_v2.so หรือ libEGL.so) ต้องรายงานการรองรับ OpenGL ES 1.0 และ OpenGL ES 2.0
• การใช้งานอุปกรณ์ที่ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 ต้องรองรับ API ที่มีการจัดการที่สอดคล้องกัน และรวมการรองรับ API แบบ C/C++ แบบเนทีฟด้วย ในการใช้งานอุปกรณ์ที่ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 libGLESv2.ดังนั้น ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องนอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0

Android มีแพ็กส่วนขยาย OpenGL ES พร้อมอินเทอร์เฟซ Java และการรองรับในตัวสำหรับฟังก์ชันการทำงานของกราฟิกขั้นสูง เช่น การขายวิดีโอในภายหลังและรูปแบบการบีบอัดพื้นผิว ASTC การใช้งานอุปกรณ์ Android ต้องรองรับแพ็กส่วนขยายหากอุปกรณ์รองรับ OpenGL ES 3.2 และอาจรองรับด้วยกรณีอื่น หากระบบรองรับแพ็กส่วนขยายทั้งหมด อุปกรณ์ต้องระบุการรองรับผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

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

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

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

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

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

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

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

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 ตัวจัดการการแสดงผลตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

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

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

7.2.1 แป้นพิมพ์

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

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

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

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

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

7.2.3 ปุ่มนำทาง

ฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ (แมปกับเหตุการณ์สำคัญ KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK ตามลำดับ) มีความสำคัญต่อกระบวนทัศน์การนำทางของ Android ดังนั้น

• การใช้งานอุปกรณ์มือถือ Android ต้องมีฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ
• การใช้งานอุปกรณ์ Android TV ต้องมีฟังก์ชันหน้าแรกและย้อนกลับ
• การใช้งานอุปกรณ์ Android Watch ต้องมีฟังก์ชัน Home สำหรับผู้ใช้ และมีฟังก์ชัน "กลับ" ยกเว้นในกรณีที่อุปกรณ์อยู่ใน UI_MODE_TYPE_WATCH
• การติดตั้งใช้งานอุปกรณ์ Android Watch และอุปกรณ์ Android ประเภทอื่นๆ อาจใช้เหตุการณ์การกดค้างในเหตุการณ์สำคัญ KEYCODE_BACK และไม่ส่งไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
• การติดตั้งใช้งาน Android Automotive ต้องมีฟังก์ชัน "อยู่บ้าน" และอาจให้บริการฟังก์ชัน "กลับ" และ "ล่าสุด"
• การใช้งานอุปกรณ์ประเภทอื่นๆ ทั้งหมดต้องมีฟังก์ชัน "หน้าแรก" และ "ย้อนกลับ"

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

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

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

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

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

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

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

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

• คีย์การนำทางสำหรับการใช้อุปกรณ์ต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมใช้งานกับแอปพลิเคชัน และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่แอปพลิเคชันใช้งานได้
• การใช้งานอุปกรณ์ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
• การใช้งานอุปกรณ์ต้องแสดงแป้นการนำทางเมื่อแอปพลิเคชันไม่ได้ระบุโหมด UI ของระบบ หรือระบุ SYSTEM_UI_FLAG_VISIBLE
• การใช้งานอุปกรณ์ต้องแสดงแป้นการนำทางในโหมด "โปรไฟล์ต่ำ" (เช่น สีจาง) ที่ไม่ก่อให้เกิดความรำคาญ เมื่อแอปพลิเคชันระบุ SYSTEM_UI_FLAG_LOW_PROFILE
• การใช้งานอุปกรณ์ต้องซ่อนคีย์การนำทางเมื่อแอปพลิเคชันระบุ SYSTEM_UI_FLAG_HIDE_NAVIGATION

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

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

• ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์ หากระบบอินพุตของอุปกรณ์รองรับเคอร์เซอร์หลายตัว
• ต้องรายงานค่าของ android.content.res.Configuration.touchscreen ให้สอดคล้องกับประเภทของหน้าจอสัมผัสที่กำหนดในอุปกรณ์

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

อุปกรณ์ที่ประกาศว่ารองรับ android.hardware.faketouch.multitouch.distinct ต้องตรงตามข้อกำหนดของ Faketouch ไว้ด้านบน และยังต้องรองรับการติดตามแบบไม่ซ้ำด้วย 2 รายการขึ้นไป

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

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

7.2.6.1 การแมปปุ่ม

การใช้งานอุปกรณ์ Android TV ต้องรองรับการแมปคีย์ต่อไปนี้

ปุ่ม	การใช้งาน HID 2	ปุ่ม Android
A 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
พันล้าน 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
ปี 1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad ขึ้น 1 D-pad ลง 1	0x01 0x0039 3	AXIS_HAT_Y 4
D-pad ด้านซ้าย 1 D-pad ด้านขวา 1	0x01 0x0039 3	AXIS_HAT_X 4
ปุ่มไหล่ซ้าย 1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
คลิกสติ๊กซ้าย 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
คลิกสติ๊กขวา 1	0x09 0x000f	KEYCODE_BUTTON_THUMBR (107)
หน้าแรก 1	0x0c 0x0223	KEYCODE_หน้าแรก (3)
กลับ 1	0x0c 0x0224	KEYCODE_BACK (4)

KeyEvent 1 รายการ

2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน Game pad CA (0x01 0x0005)

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

4 เหตุการณ์การเคลื่อนไหว

การควบคุมแบบแอนะล็อก 1	การใช้ HID	ปุ่ม Android
ทริกเกอร์ซ้าย	0x02 0x00C5	AXIS_LTRIGGER
ทริกเกอร์ด้านขวา	0x02 0x00C4	AXIS_RTRIGGER
จอยสติ๊กด้านซ้าย	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
จอยสติ๊กด้านขวา	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

เหตุการณ์การเคลื่อนไหว 1 รายการ

7.2.7 การควบคุมระยะไกล

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

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

7.3 เซ็นเซอร์

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

• ต้องรายงานการอยู่หรือไม่มีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager
• ต้องส่งคืนรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่านทาง SensorManager.getSensorList() และใช้วิธีการที่คล้ายกัน
• ต้องมีลักษณะการทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น แสดงผลค่า "จริง" หรือ "เท็จ" ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามบันทึก Listener และไม่เรียกใช้ Listener เซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง ฯลฯ)
• ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยหน่วยสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสาร Android SDK
• ควรรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK โดยแสดงเวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano() เราขอแนะนำอุปกรณ์ Android ทั้งใหม่และใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจเป็นคอมโพเนนต์ "จำเป็น" ข้อผิดพลาดในการซิงค์ควรต่ำกว่า 100 มิลลิวินาที
• ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time สำหรับกรณีของเซ็นเซอร์ที่สตรีมโดยมีเวลาในการตอบสนองขั้นต่ำที่ต้องการคือ 5 ms + 2 * sample_time เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
• ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำเป็น 0 ได้

รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทำงานที่มีการบันทึกไว้ของ Android SDK และเอกสารโอเพนซอร์สของ Android บนเซ็นเซอร์จะถือว่าเชื่อถือได้

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

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

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

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

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

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

• ต้องใช้และรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
• ต้องสามารถรายงานเหตุการณ์ด้วยความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์ Android Watch เนื่องจากอุปกรณ์ดังกล่าวมีข้อจำกัดด้านพลังงานที่เข้มงวดกว่าและ 100 Hz สำหรับอุปกรณ์ประเภทอื่นทั้งหมด
• ควรรายงานเหตุการณ์สูงสุด 200 Hz
• ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API การใช้งาน Android Automotive ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ในรถของ Android
• ต้องวัดได้จากการตกแบบอิสระสูงสุด 4 เท่าของแรงโน้มถ่วง (4g) หรือมากกว่าบนแกนใดก็ได้
• ต้องมีความละเอียดอย่างน้อย 12 บิต และควรมีความละเอียดอย่างน้อย 16 บิต
• ควรมีการปรับเทียบขณะใช้งานหากลักษณะมีการเปลี่ยนแปลงตลอดวงจรและการชดเชย รวมถึงเก็บพารามิเตอร์การชดเชยไว้ระหว่างรีบูตอุปกรณ์
• ควรมีการชดเชยอุณหภูมิ
• ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 เมตร/วินาที โดยค่าเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 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 เสมอเมื่ออุปกรณ์อยู่ในสภาพไดนามิกหรือคงที่
• ถ้ารวมเซ็นเซอร์วัดการหมุน ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION และควรใช้เซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่จะได้รับการแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
• ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR หากรวมเซ็นเซอร์เครื่องวัดการหมุนและเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กไว้ด้วย

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

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

• ต้องใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD และควรติดตั้งเซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่จะได้รับการแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED
• ต้องสามารถรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์สูงสุด 50 Hz
• ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
• ต้องวัดได้ระหว่าง -900 μT ถึง +900 μT บนแกนแต่ละแกนก่อนความอิ่มตัว
• ต้องมีค่าออฟเซ็ตเหล็กแข็งน้อยกว่า 700 μT และควรมีค่าต่ำกว่า 200 μT โดยวางเครื่องวัดค่าความเข้มข้นจากสนามแม่เหล็กไฟฟ้า (ปัจจุบัน) และคงที่ (เกิดจากสนามแม่เหล็ก)
• ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 μT และควรมีความละเอียดเท่ากับหรือหนาแน่นมากกว่า 0.2 μT
• ควรมีการชดเชยอุณหภูมิ
• ต้องรองรับการปรับเทียบออนไลน์และการชดเชยอคติจากเหล็กที่แข็ง และรักษาพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
• ต้องใช้การชดเชยเหล็กที่อ่อนนุ่ม การปรับเทียบสามารถทำได้ขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
• ควรมีค่าเบี่ยงเบนมาตรฐาน โดยคำนวณตามแกนต่อแกนจากตัวอย่างที่เก็บรวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีด้วยอัตราการสุ่มตัวอย่างเร็วที่สุด และไม่เกิน 0.5 μT
• ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR หากรวมเซ็นเซอร์ตัวตรวจวัดความเร่งและเครื่องวัดการหมุนไว้ด้วย
• อาจใช้เซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR หากติดตั้งเซ็นเซอร์ตัวตรวจวัดความเร่งด้วย แต่หากใช้งาน เซ็นเซอร์จะต้องใช้พลังงานน้อยกว่า 10 mW และควรใช้พลังงานน้อยกว่า 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดแบบกลุ่มที่ 10 Hz

7.3.3 GPS

การใช้งานอุปกรณ์ ควรรวมตัวรับสัญญาณ GPS/GNSS หากการติดตั้งอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps ดังนี้

• ขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์ยังคงส่งเอาต์พุต GPS/GNSS ตามปกติไปยังแอปพลิเคชันในระหว่างการโทรฉุกเฉิน และไม่บล็อกเอาต์พุตตำแหน่งระหว่างการโทรฉุกเฉิน
• ต้องรองรับเอาต์พุตตำแหน่งในอัตราอย่างน้อย 1 Hz เมื่อขอผ่าน LocationManager#requestLocationUpdate
• บริการนี้ต้องสามารถระบุตำแหน่งในสภาพโล่ง (สัญญาณแรง, เส้นทางหลายทางที่ไม่สำคัญ, HDOP < 2) ภายใน 10 วินาที (เวลาที่รวดเร็วในการแก้ไขครั้งแรก) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็ว 0.5 Mbps ขึ้นไป โดยทั่วไปข้อกำหนดนี้จะเป็นไปตามการใช้เทคนิค GPS/GNSS แบบมีการสนับสนุนหรือที่คาดการณ์ไว้เพื่อลดเวลาล็อกของ GPS/GNSS ให้เหลือน้อยที่สุด (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และ Ephemeris/Clock ดาวเทียม)
  • หลังจากคำนวณตำแหน่งแล้ว ขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์สามารถระบุตำแหน่งได้ในพื้นที่เปิดโล่งภายใน 10 วินาทีเมื่อเริ่มต้นคำขอตำแหน่งใหม่ และใช้เวลาไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอครั้งต่อๆ ไปโดยไม่มีการเชื่อมต่อข้อมูล และ/หรือหลังจากการเปิดเครื่อง
• ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร็วน้อยกว่า 1 เมตรต่อวินาทีของความเร่งยกกำลังสอง
  • เทคโนโลยี "ต้อง" ระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วไม่เกิน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
  • ต้องติดตามและรายงานผ่าน GnssStatus.Callback ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว
  • อุปกรณ์ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายกลุ่มดาวได้พร้อมกัน (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อยหนึ่งดาว)
• โดยจะต้องรายงานการสร้างเทคโนโลยี GNSS ผ่าน API การทดสอบ "getGnssYearOfฮาร์ดแวร์"
• เราขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดทั้งหมดด้านล่าง หากมีการรายงานรุ่นเทคโนโลยี GNSS เป็นปี "2016" หรือรุ่นที่ใหม่กว่า
  • โดยต้องรายงานการวัด GPS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
  • ต้องรายงานช่วงจำลองของ GPS และอัตราเทียม ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่โดยมีความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลังสอง ก็เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลาทั้งหมด

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

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

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

• ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และควรใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED เราขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android ทั้งใหม่และใหม่ในการใช้เซ็นเซอร์ SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
• ต้องสามารถวัดการวางแนวได้ถึง 1,000 องศาต่อวินาที
• ต้องสามารถรายงานเหตุการณ์ด้วยความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์ Android Watch เนื่องจากอุปกรณ์ดังกล่าวมีข้อจำกัดด้านพลังงานที่เข้มงวดกว่าและ 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 หากมีเซ็นเซอร์ตัวตรวจวัดความเร่งและเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมาด้วย
• หากมีเซ็นเซอร์ตัวตรวจวัดความเร่งรวมอยู่ด้วย คุณต้องใช้เซ็นเซอร์คอมโพสิต 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.3.9 เซ็นเซอร์ความแม่นยำสูง

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

อุปกรณ์ที่ประกาศว่า android.hardware.sensor.hifi_sensors ต้องรองรับเซ็นเซอร์ทุกประเภทต่อไปนี้ที่ตรงตามข้อกำหนดด้านคุณภาพดังต่อไปนี้

• SENSOR_TYPE_ACCELEROMeter
  • ต้องมีช่วงการวัดระหว่าง -8 ก. ถึง +8 ก. เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 1024 LSB/G
  • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
  • ต้องมีความถี่การวัดสูงสุด 400 Hz หรือสูงกว่า
  • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงกว่า 400 uG/Cellular คนอื่นๆ
  • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
  • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
  • ควรมีความเสถียรของเบี่ยงเบนสัญญาณรบกวนแบบอยู่กับที่ที่ \<15 μg เครื่องหมาย การแปลแบบอินเทอร์แอ็กทีฟจากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
  • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก. / °C
  • ควรมีระดับความไม่เป็นเชิงเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิสูงสุด ≤ 0.03%/C°

• ประเภทเซ็นเซอร์ตรวจจับการหมุน

  • ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
  • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
  • ต้องมีความถี่การวัดสูงสุด 400 Hz หรือสูงกว่า
  • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
  • ควรมีความเสถียรของอคติแบบอยู่กับที่ของ < 0.0002 °/s ¡Hz จากชุดข้อมูลแบบคงที่ตลอด 24 ชั่วโมง
  • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
  • ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
  • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
  • ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED ซึ่งมีข้อกำหนดด้านคุณภาพเหมือนกับ SENSOR_TYPE_GYROSCOPE

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 uT เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
  • ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
  • ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ SENSOR_TYPE_GEOMAGNETIC_FIELD และเพิ่มเติมด้วย
  • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
• SENSOR_TYPE_PRESSURE
  • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
  • ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
  • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
  • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
  • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 2 mW
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
  • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
• SENSOR_TYPE_STEP_DETECTOR
  • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์เซ็นเซอร์
  • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
• SENSOR_TYPE_STEP_COUNTER
  • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
• SENSOR_TILT_ตัวตรวจจับ
  • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่

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

• การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่ง เซ็นเซอร์เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กต้องอยู่ห่างกันไม่เกิน 2.5 มิลลิวินาที
• การประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุนต้องอยู่ในเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดภายใน 1 มิลลิวินาที
• เซ็นเซอร์ความแม่นยำสูงต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์ทางกายภาพไปยังแอปพลิเคชัน
• การใช้พลังงานต้องไม่สูงกว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 2.0 mW เมื่ออุปกรณ์มีการเคลื่อนไหวเมื่อเปิดใช้เซ็นเซอร์ใดๆ ต่อไปนี้ร่วมกัน
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS ตัว

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

การใช้งานอุปกรณ์ที่ประกาศ android.hardware.sensor.hifi_sensors อาจรองรับเซ็นเซอร์ประเภทต่อไปนี้ด้วย แต่หากมีเซ็นเซอร์ประเภทเหล่านี้อยู่ เซ็นเซอร์นั้นต้องเป็นไปตามข้อกำหนดความสามารถในการบัฟเฟอร์ขั้นต่ำดังต่อไปนี้

• SENSOR_TYPE_PROXIMITY: เหตุการณ์ที่เซ็นเซอร์ 100 รายการ

7.3.10 เซ็นเซอร์ลายนิ้วมือ

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

• ต้องประกาศการรองรับฟีเจอร์ android.hardware.fingerprint
• ต้องใช้ corresponding API อย่างสมบูรณ์ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
• ต้องมีอัตราการยอมรับที่เป็นเท็จไม่เกิน 0.002%
• แนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์
• ขอแนะนำเป็นอย่างยิ่งให้เวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อเซ็นเซอร์ลายนิ้วมือแตะจนกระทั่งปลดล็อกหน้าจอสำหรับนิ้วที่ลงทะเบียนเพียง 1 นิ้ว
• ต้องพยายามจำกัดอัตราคำขอเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดสอบที่ผิดพลาด 5 ครั้งสำหรับการยืนยันลายนิ้วมือ
• ต้องมีการใช้งานคีย์สโตร์ที่อาศัยฮาร์ดแวร์ และดำเนินการจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
• ข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดต้องเข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับเพื่อที่จะไม่สามารถได้ อ่าน หรือเปลี่ยนแปลงนอกกรอบของการดำเนินการที่เชื่อถือได้ (TEE) ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
• ต้องป้องกันไม่ให้มีการเพิ่มลายนิ้วมือโดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้โครงการโอเพนซอร์ส Android ทำให้มีกลไกในกรอบการทำงานดังกล่าว
• ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างลายนิ้วมือแต่ละรายการ
• ต้องทำตามแฟล็ก DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
• ต้องเมื่ออัปเกรดจากเวอร์ชันก่อน Android 6.0 แล้ว ต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้น หรือนำข้อมูลลายนิ้วมือออก
• ควรใช้ไอคอนลายนิ้วมือของ Android ที่ให้ไว้ในโครงการโอเพนซอร์สของ Android

7.3.11 เซ็นเซอร์สำหรับ Android Automotive เท่านั้น

เซ็นเซอร์สําหรับยานยนต์ได้รับการกําหนดไว้ในคอลัมน์ android.car.CarSensorManager API

7.3.11.1 เฟืองปัจจุบัน

การติดตั้งใช้งาน Android Automotive ควรมีเครื่องมือปัจจุบันเป็น SENSOR_TYPE_GEAR

7.3.11.2 โหมดกลางวัน/กลางคืน

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

7.3.11.3 สถานะการขับรถ

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

7.3.11.4 ความเร็วของล้อ

การติดตั้งใช้งาน Android Automotive ต้องระบุความเร็วของยานพาหนะที่กำหนดไว้เป็น SENSOR_TYPE_CAR_SPEED

7.3.12 เซ็นเซอร์ท่าทาง

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

• ต้องใช้และรายงานเซ็นเซอร์ TYPE_POSE_6DOF
• ต้องมีความแม่นยำมากกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

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

7.4.1 โทรศัพท์

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

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

7.4.1.1 ความเข้ากันได้ของการบล็อกหมายเลข

การใช้งานอุปกรณ์โทรศัพท์ Android ต้องมีการรองรับการบล็อกหมายเลขและ

• ต้องใช้ BlockedNumberContract และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบ SDK
• ต้องบล็อกการโทรและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยที่ไม่โต้ตอบกับแอปใดๆ เลย ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• ต้องไม่เขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก
• ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่ถูกบล็อก
• ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งเปิดด้วย Intent ที่ส่งกลับโดยเมธอด TelecomManager.createManageBlockedNumbersIntent()
• ต้องไม่อนุญาตให้ผู้ใช้รองดูหรือแก้ไขหมายเลขที่ถูกบล็อกในอุปกรณ์ เนื่องจากแพลตฟอร์ม Android จะถือว่าผู้ใช้หลักควบคุมบริการโทรศัพท์ได้อย่างเต็มรูปแบบในอุปกรณ์เป็นกรณีเดียว ต้องซ่อน UI ที่เกี่ยวข้องกับการบล็อกทั้งหมดสำหรับผู้ใช้รอง และรายการที่ถูกบล็อกต้องยังคงทำงานตามเดิม
• ควรย้ายข้อมูลหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0

7.4.2 IEEE 802.11 (Wi-Fi)

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

• ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
• ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
• ต้องรองรับ Multicast DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ได้ตลอดเวลา รวมถึงการดำเนินการต่อไปนี้
  • แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงานอยู่
  • สำหรับการใช้งานอุปกรณ์ Android TV แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย

7.4.2.1 Wi-Fi Direct

การใช้งานอุปกรณ์ควรมีการสนับสนุน Wi-Fi Direct (Wi-Fi peer-to-peer) หากการติดตั้งใช้งานอุปกรณ์รวมการรองรับ Wi-Fi Direct อุปกรณ์ต้องใช้ Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบ SDK หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Direct รวมอยู่ด้วย ระบบจะดำเนินการต่อไปนี้

• ต้องรายงานฟีเจอร์ของฮาร์ดแวร์ android.hardware.wifi.direct
• ต้องรองรับการใช้งาน Wi-Fi ปกติ
• ควรรองรับการทำงาน Wi-Fi และ Wi-Fi Direct พร้อมกัน

7.4.2.2 การตั้งค่าการเชื่อมต่อโดยตรงผ่านอุโมงค์ Wi-Fi

การใช้งานอุปกรณ์ควรมีการสนับสนุนสำหรับการตั้งค่า Wi-Fi Tunneled Direct Link (TDLS) ดังที่อธิบายไว้ในเอกสารประกอบของ Android SDK หากการใช้งานอุปกรณ์รวมการสนับสนุน TDLS และ TDLS เปิดใช้งานโดย WiFiManager API อุปกรณ์จะมีลักษณะดังนี้

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

7.4.3 บลูทูธ

การใช้งานอุปกรณ์ที่รองรับฟีเจอร์ android.hardware.vr.high_performance ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวของข้อมูล Bluetooth LE

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

การติดตั้งใช้งาน Android Automotive ควรรองรับ Message Access Profile (MAP) การใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้

• การโทรผ่านโทรศัพท์ผ่านโปรไฟล์แฮนด์ฟรี (HFP)
• การเล่นสื่อผ่าน Audio Distribution Profile (A2DP)
• การควบคุมการเล่นสื่อบนโปรไฟล์รีโมตคอนโทรล (AVRCP)
• การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)

การใช้งานอุปกรณ์รวมถึงการรองรับบลูทูธพลังงานต่ำ

• ต้องประกาศฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le
• ต้องเปิดใช้ API บลูทูธที่ใช้ GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) ตามที่อธิบายไว้ในเอกสารประกอบ SDK และ android.bluetooth
• มีคำแนะนำอย่างยิ่งให้ใช้ระยะหมดเวลาของที่อยู่ส่วนตัวแบบแก้ไขได้ (Resolvable Private Address หรือ RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
• ควรรองรับการลดภาระของตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API และรายงานค่าที่ถูกต้องของตําแหน่งที่ใช้ตรรกะการกรองเมื่อใดก็ตามที่ค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
• ควรรองรับการลดภาระของการสแกนแบบกลุ่มไปยังชิปเซ็ตบลูทูธ แต่หากไม่รองรับ ต้องรายงาน "false" ทุกครั้งที่ค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported()
• ควรสนับสนุนโฆษณาหลายรายการที่มีช่องอย่างน้อย 4 ช่อง แต่หากไม่มีการสนับสนุน ต้องรายงาน "false" ทุกครั้งที่ค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapter.is MultipleAdvertisementSupported()

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

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

• ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
• ต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้
  • ต้องสามารถทำหน้าที่เป็นผู้อ่าน/ผู้เขียนฟอรัม NFC (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของฟอรัม NFC NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFC (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • ประเภทแท็กฟอรัม NFC 1, 2, 3, 4 (กำหนดโดยฟอรัม NFC)
  • แนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF ตลอดจนข้อมูลดิบผ่านทางมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้มาตรฐาน NFC ด้านล่างจะระบุเป็น "แนะนำ" อย่างยิ่ง แต่มีการกำหนดมาตรฐานความเข้ากันได้สำหรับเวอร์ชันในอนาคตจะเปลี่ยนไปเป็น "ต้อง" มาตรฐานเหล่านี้เป็นตัวเลือกในเวอร์ชันนี้ แต่จะบังคับในเวอร์ชันต่อๆ ไป เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบัติตามข้อกำหนดเหล่านี้ทันที เพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นอื่นๆ ในอนาคตได้
    • NfcV (ISO 15693)
  • ควรสามารถอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC ของ Thinfilm
  • ต้องสามารถรับส่งข้อมูลผ่านมาตรฐานและโปรโตคอลระหว่างเครื่องต่อไปนี้ได้
    • ISO 18092
    • LLCP 1.2 (กำหนดโดยฟอรัม NFC)
    • SDP 1.0 (กำหนดโดยฟอรัม NFC)
    • โปรโตคอลการพุช NDEF
    • SNEP 1.0 (กำหนดโดยฟอรัม NFC)
  • ต้องมีการสนับสนุนสำหรับ Androidบีม
  • ต้องใช้เซิร์ฟเวอร์เริ่มต้นของ SNEP ข้อความ NDEF ที่ถูกต้องซึ่งเซิร์ฟเวอร์ SNEP เริ่มต้นได้รับจะต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้ Androidบีมในการตั้งค่าต้องไม่ปิดใช้การส่งข้อความ NDEF ที่เข้ามาใหม่
  • ต้องทำตาม Intent android.settings.NFCSHARING_SETTINGS จึงจะแสดงการตั้งค่าการแชร์ NFC
  • ต้องใช้เซิร์ฟเวอร์ NPP ข้อความที่เซิร์ฟเวอร์ NPP ได้รับจะต้องประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้นของ SNEP
  • ต้องใช้ไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Androidบีม หากไม่พบเซิร์ฟเวอร์ SNEP ที่เป็นค่าเริ่มต้น ไคลเอ็นต์ต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
  • ต้องอนุญาตให้กิจกรรมเบื้องหน้าตั้งค่าข้อความ NDEF แบบ P2P ขาออกโดยใช้ android.nfc.NfcAdapter.setNdefPushMessage และ android.nfc.NfcAdapter.setNdefPushMessageCallback และ android.nfc.NfcAdapter.enableForegroundNdefPush
  • ควรใช้ท่าทางสัมผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อบีม" ก่อนส่งข้อความ NDEF แบบ P2P ขาออก
  • ควรเปิดใช้ Androidอยู่แล้ว
  • ต้องรองรับการส่งมอบการเชื่อมต่อ NFC กับบลูทูธเมื่ออุปกรณ์สนับสนุนโปรไฟล์พุชของออบเจ็กต์บลูทูธ การใช้งานอุปกรณ์ต้องรองรับการส่งมอบการเชื่อมต่อไปยังบลูทูธเมื่อใช้ android.nfc.NfcAdapter.setBeamPushUris โดยใช้ข้อกำหนด "การควบคุมการเชื่อมต่อเวอร์ชัน 1.2 " และ "การจับคู่อย่างง่ายที่ปลอดภัยบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" จากฟอรัม NFC การติดตั้งใช้งานดังกล่าวต้องใช้บริการ Handover LLCP ที่มีชื่อว่าบริการชื่อ "urn:nfc:sn:handover" สำหรับการแลกเปลี่ยนคำขอโอน/เลือกบันทึกผ่าน NFC และต้องใช้โปรไฟล์พุชของ Bluetooth Object Push สำหรับการโอนข้อมูลบลูทูธจริง ด้วยเหตุผลเดิม (เพื่อให้ยังคงสามารถทำงานร่วมกับอุปกรณ์ Android 4.1 ได้) การใช้งานควรจะยอมรับคำขอ SNEP GET สำหรับการแลกเปลี่ยนคำขอส่ง/บันทึกที่เลือกผ่าน NFC อย่างไรก็ตาม การนำไปใช้ไม่ควรส่งคำขอ SNEP GET เพื่อทำการส่งมอบการเชื่อมต่อ
  • ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นหา NFC
  • ควรอยู่ในโหมดการค้นหา NFC ขณะอุปกรณ์ทำงานอยู่โดยที่หน้าจอทำงานอยู่และปลดล็อกหน้าจอแล้ว

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

Android มีการสนับสนุนโหมด NFC Host Card Emulation (HCE) หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทางของ Application ID (AID) ระบบจะดำเนินการต่อไปนี้

• ต้องรายงานฟีเจอร์ android.hardware.nfc.hce แบบคงที่
• ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK

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

• ต้องรายงานฟีเจอร์ android.hardware.nfc.hcef แบบคงที่
• ต้องใช้ NfcF Card Emulation API ดังที่กำหนดไว้ใน Android SDK

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

• MIFARE แบบคลาสสิก
• MIFARE น้ำหนักเบา
• NDEF ใน MIFARE แบบคลาสสิก

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

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

หากการใช้งานอุปกรณ์ไม่รวมฮาร์ดแวร์ NFC อุปกรณ์นั้นต้องไม่ประกาศฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature() และต้องใช้ Android NFC API เป็นการดำเนินการ

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

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

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

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

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

อุปกรณ์ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสารที่ใช้ IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API แบบเนทีฟ เช่น ซ็อกเก็ต AF_INET6 ระดับการสนับสนุน IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่ายดังต่อไปนี้

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

ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น

เพื่อให้มั่นใจว่าการสื่อสาร IPv6 มีความเสถียรเหมือนกับ IPv4 แพ็กเก็ต IPv6 แบบ Unicast ที่ส่งไปยังอุปกรณ์จะต้องไม่สูญหาย แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงานอยู่ก็ตาม แพ็กเก็ต IPv6 แบบมัลติแคสต์ที่ซ้ำซ้อน เช่น การโฆษณาเราเตอร์ที่เหมือนกันซ้ำๆ อาจมีการจำกัดอัตราในฮาร์ดแวร์หรือเฟิร์มแวร์ หากจำเป็นต้องทำเช่นนั้นเพื่อประหยัดพลังงาน ในกรณีดังกล่าว การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 บนเครือข่ายที่สอดคล้องกับ IPv6 ที่ใช้อายุการใช้งานของ RA อย่างน้อย 180 วินาที

การเชื่อมต่อ IPv6 ต้องได้รับการจัดการในโหมด Doze

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

การใช้งานอุปกรณ์ต้องเปิดการตั้งค่าการซิงค์อัตโนมัติหลักไว้โดยค่าเริ่มต้น เพื่อให้เมธอด getMasterSyncautomatic() แสดงค่า "true"

7.4.7 ประหยัดอินเทอร์เน็ต

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

หากการติดตั้งใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต ระบบจะดำเนินการดังนี้

• ต้องรองรับ API ทั้งหมดในคลาส ConnectivityManager ตามที่อธิบายไว้ในเอกสารประกอบ SDK

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

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

• ต้องส่งค่า RESTRICT_BACKGROUND_STATUS_DISABLED สำหรับ ConnectivityManager.getRestrictBackgroundStatus()

• ต้องไม่เผยแพร่ ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• ต้องมีกิจกรรมที่จัดการ Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS แต่อาจใช้งานแบบไม่ดำเนินการ

7.5 กล้อง

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

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

7.5.1 กล้องหลัง

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

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

7.5.2 กล้องหน้า

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

• ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
• ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
• ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API API กล้องถ่ายรูปใน Android มีการสนับสนุนเฉพาะสำหรับกล้องหน้าและการใช้งานอุปกรณ์ต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวในอุปกรณ์ก็ตาม
• อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
• ต้องสะท้อนในแนวนอน (มิเรอร์) สตรีมที่แอปใน CameraPreview แสดง ดังนี้
  • หากผู้ใช้หมุนอุปกรณ์ได้ (เช่น โดยอัตโนมัติผ่านตัวตรวจวัดความเร่งหรือด้วยตนเองผ่านอินพุตของผู้ใช้) ตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์
  • หากแอปพลิเคชันปัจจุบันขออย่างชัดแจ้งให้หมุนจอแสดงผลของกล้องผ่านการเรียกเมธอด android.hardware.camera.setDisplayOrientation() ตัวอย่างจากกล้องจะต้องมิเรอร์ในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุ
  • มิเช่นนั้นตัวอย่างต้องแสดงตามแกนแนวนอนเริ่มต้นของอุปกรณ์
• ต้องจำลองภาพที่แสดงหลังมุมมองหลังการถ่ายทำในลักษณะเดียวกับสตรีมภาพตัวอย่างจากกล้อง หากการใช้งานอุปกรณ์ไม่รองรับมุมมองภายหลัง จะไม่มีการใช้ข้อกำหนดนี้อย่างชัดเจน
• ต้องไม่มิเรอร์สตรีมภาพนิ่งหรือวิดีโอที่บันทึกไว้ล่าสุดซึ่งส่งไปยัง Callback ของแอปพลิเคชันหรือคอมมิตไปยังพื้นที่เก็บข้อมูลสื่อ

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

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

• ต้องประกาศ Flag ฟีเจอร์ของแพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
• อาจรองรับกล้องหลายตัว
• ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ต USB
• ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้สามารถโอนสตรีมคุณภาพสูงที่ไม่เข้ารหัส (เช่น สตรีมภาพดิบหรือสตรีมที่บีบอัดแบบอิสระ)
• อาจรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง หากรองรับ การใช้งานอุปกรณ์จะต้องเข้าถึงสตรีม MJPEG / สตรีม MJPEG พร้อมกัน (QVGA หรือความละเอียดสูงกว่า) ได้

7.5.4 การทำงานของ API กล้องถ่ายรูป

Android มีแพ็กเกจ API 2 แพ็กเกจสำหรับเข้าถึงกล้อง API ใหม่ android.hardware.camera2 จะแสดงการควบคุมกล้องในระดับต่ำกว่าแก่แอป ซึ่งรวมถึงโฟลว์การถ่ายภาพ/การสตรีมแบบ Zero Copy ที่มีประสิทธิภาพ การควบคุมการรับแสง ค่าเกน การเพิ่มไวท์บาลานซ์ การแปลงสี การตัดเสียงรบกวน การทำให้คมชัด และอีกมากมาย

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

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

• หากแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.camera.Parameters.setPreviewFormat(int) มาก่อน อุปกรณ์ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ให้ไว้กับ Callback ของแอปพลิเคชัน
• หากแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() เมื่อรูปแบบการแสดงตัวอย่างคือ YCbCr_420_SP ข้อมูลในไบต์[] ที่ส่งผ่านไปยัง onPreviewFrame() ต้องอยู่ในรูปแบบการเข้ารหัส NV21 ต่อไป นั่นคือ NV21 ต้องเป็นค่าเริ่มต้น
• สำหรับ android.hardware.camera การใช้งานอุปกรณ์ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างจากกล้องสำหรับทั้งกล้องหน้าและกล้องหลัง (กล้องและโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อาจใช้พิกเซลดั้งเดิมรูปแบบใดก็ได้ แต่การใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
• สำหรับ android.hardware.camera2 การใช้งานอุปกรณ์ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API

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

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

เนื่องจากการใช้งานอุปกรณ์บางอย่างอาจรองรับฟีเจอร์ทั้งหมดของ android.hardware.camera2 API ได้อย่างเต็มรูปแบบ การใช้งานอุปกรณ์ต้องรายงานระดับการรองรับที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedฮาร์ดแวร์Level ตามที่อธิบายไว้ใน Android SDK และรายงานแฟล็กฟีเจอร์เฟรมเวิร์กที่เหมาะสม

การใช้งานอุปกรณ์ต้องประกาศความสามารถของกล้องแต่ละตัวเป็น android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities ด้วย และประกาศแฟล็กฟีเจอร์ที่เหมาะสม อุปกรณ์ต้องกำหนดธงทำเครื่องหมายฟีเจอร์ หากอุปกรณ์กล้องที่แนบอยู่รองรับฟีเจอร์นี้

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

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

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

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

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

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

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

ความหนาแน่นและขนาดหน้าจอ	อุปกรณ์ 32 บิต	อุปกรณ์ 64 บิต
อุปกรณ์ Android Watch (เนื่องจากหน้าจอขนาดเล็ก)	416MB	ไม่เกี่ยวข้อง
280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่ ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ	512MB	816MB
xhdpi ขึ้นไปสำหรับหน้าจอขนาดเล็ก/ปกติ hdpi ขึ้นไปบนหน้าจอขนาดใหญ่ MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ	608MB	944MB
400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่ tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ	896MB	1280MB
560dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่ xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ	1344MB	1824MB

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

การใช้งานอุปกรณ์ที่มีหน่วยความจำน้อยกว่า 512 MB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ ยกเว้น Android Watch จะต้องแสดงค่า "true" สำหรับ ActivityManager.isLowRamDevice()

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

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

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

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

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

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

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

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

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

การใช้งานอุปกรณ์ที่มีเส้นทางพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายเส้นทาง (เช่น ทั้งช่องเสียบการ์ด SD และที่จัดเก็บข้อมูลภายในที่ใช้ร่วมกัน) ต้องอนุญาตเฉพาะการติดตั้งล่วงหน้าและ แอปพลิเคชัน Android ที่ได้รับสิทธิ์ WRITE_EXTERNAL_STORAGE มีสิทธิ์เขียนไปยังพื้นที่เก็บข้อมูลภายนอกสำรอง ยกเว้นเมื่อเขียนไปยังไดเรกทอรีเฉพาะแพ็กเกจหรือภายใน URI ซึ่งแสดงผลด้วยการเริ่มทำงานของ Intent ของ ACTION_OPEN_DOCUMENT_TREE

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

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

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

7.6.3 พื้นที่เก็บข้อมูลแบบ Adoptable

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

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

7.7 USB

การใช้งานอุปกรณ์ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB

7.7.1 โหมดอุปกรณ์ต่อพ่วง USB

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง

• พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB ประเภท A หรือ Type-C แบบมาตรฐาน
• พอร์ตควรใช้รูปแบบ USB แบบ micro-B, micro-AB หรือ Type-C เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
• พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวตามธรรมชาติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับทุกแอป (รวมถึงหน้าจอหลัก) เพื่อให้แสดงผลได้อย่างถูกต้องเมื่ออุปกรณ์วางอยู่ในแนวเดียวกับพอร์ตที่ด้านล่าง เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
• ต้องอนุญาตให้โฮสต์ USB ที่เชื่อมต่อกับอุปกรณ์ Android เข้าถึงเนื้อหาของวอลุ่มพื้นที่เก็บข้อมูลที่แชร์โดยใช้พื้นที่เก็บข้อมูลขนาดใหญ่แบบ USB หรือ Media Transfer Protocol
• ควรใช้ Android Open Accessory (AOA) API และข้อมูลจำเพาะตามที่ระบุไว้ในเอกสาร Android SDK และหากเป็นอุปกรณ์มือถือ Android ก็ต้องใช้ AOA API การติดตั้งใช้งานอุปกรณ์ที่ดำเนินการตามข้อกำหนด AOA
  • ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
  • ต้องใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
  • คลาสที่จัดเก็บข้อมูล USB ขนาดใหญ่ต้องมีสตริง "android" ที่ส่วนท้ายของคำอธิบายอินเทอร์เฟซ iInterface สตริงของที่เก็บข้อมูล USB ขนาดใหญ่
• ควรใช้การรองรับการดึงกระแสไฟฟ้า 1.5 A ในระหว่างการส่งเสียงร้อง HS และการจราจรของข้อมูลตามที่ระบุไว้ในข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
• อุปกรณ์ Type-C ต้องตรวจพบที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจพบการเปลี่ยนแปลงในโฆษณา
• เราขอแนะนำเป็นอย่างยิ่งว่าอุปกรณ์ Type-C ที่รองรับโหมดโฮสต์ USB จะรองรับการส่งพลังงานสำหรับการสลับบทบาทข้อมูลและพลังงาน
• อุปกรณ์ Type-C ควรรองรับ Power Delivery สำหรับการชาร์จแรงดันไฟฟ้าสูง และรองรับโหมดสำรอง เช่น โหมดแสดงภาพภายนอก
• ค่าของ iSerialNumber ในตัวบ่งชี้อุปกรณ์มาตรฐาน USB ต้องเท่ากับค่าของ android.os.Build.SERIAL
• เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Type-C เพื่อไม่รองรับวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของอ่างล้างหน้า/แหล่งที่มา ซึ่งอาจทำให้เกิดปัญหากับที่ชาร์จหรืออุปกรณ์ที่รองรับวิธีการส่งพลังงานแบบ USB แบบมาตรฐาน แม้จะเรียกว่า "แนะนำอย่างยิ่ง" แต่สำหรับ Android เวอร์ชันต่อๆ ไป เราอาจต้องใช้อุปกรณ์ type-C ทั้งหมดเพื่อรองรับความสามารถในการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C แบบมาตรฐาน

7.7.2 โหมดโฮสต์ USB

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

• ควรใช้พอร์ต USB Type-C หากการใช้งานอุปกรณ์รองรับ USB 3.1
• อาจใช้รูปแบบพอร์ตที่ไม่ใช่มาตรฐาน แต่หากต้องใช้ ต้องจัดส่งโดยใช้สายหรือสายที่ปรับพอร์ตให้เป็นพอร์ต USB แบบ Type-A หรือ Type-C แบบมาตรฐาน
• อาจใช้พอร์ต Micro-AB USB แต่หากควร ควรจัดส่งโดยใช้สายหรือสายที่ปรับพอร์ตให้เป็นพอร์ต USB แบบ Type-A หรือ Type-C แบบมาตรฐาน
• แนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
• ต้องใช้ Android API โฮสต์ USB ของ Android ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
• ควรรองรับการชาร์จอุปกรณ์ขณะอยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของ [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) สำหรับขั้วต่อ USB Type-C หรือการใช้สายชาร์จดาวน์สตรีม(CDP) ช่วงเอาต์พุตปัจจุบันตามที่ระบุไว้ในข้อกำหนดเฉพาะของแบตเตอรี่ USB แบบ AB1
• อุปกรณ์ USB Type-C ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort และควรรองรับอัตราข้อมูล USB SuperSpeed และแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
• อุปกรณ์ที่มีพอร์ต type-A หรือ type-AB ต้องไม่จัดส่งมาพร้อมกับอะแดปเตอร์ที่แปลงจากพอร์ตนี้เป็นเต้ารับ type-C
• ต้องจดจำอุปกรณ์ MTP (Media Transfer Protocol) ใดๆ ที่เชื่อมต่อจากระยะไกล และทำให้เนื้อหาสามารถเข้าถึงผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT หากรองรับ Storage Framework (SAF)
• หากต้องใช้พอร์ต USB Type-C และรองรับโหมดอุปกรณ์ต่อพ่วง ให้ใช้ฟังก์ชัน Dual Role Port ตามที่กำหนดไว้ในข้อกำหนดเฉพาะ USB Type-C (ส่วน 4.5.1.3.3)
• ในกรณีที่รองรับฟังก์ชัน Dual Role Port ให้ใช้โมเดล Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบของอุปกรณ์ ตัวอย่างเช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK

7.8 เสียง

7.8.1 ไมโครโฟน

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

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

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

การติดตั้งใช้งานอุปกรณ์ซึ่งรวมถึงลำโพงหรือมีพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียงเป็นชุดหูฟังหรือลำโพงภายนอก

• ต้องรายงานฟีเจอร์ android.hardware.audio.output ตลอดเวลา
• เสียงที่ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
• ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
• ขอแนะนำเป็นอย่างยิ่งให้รองรับการเล่นอัลตราซาวด์ในระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 7.8.3

ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รวมลำโพงหรือพอร์ตเอาต์พุตเสียง อุปกรณ์จะต้องไม่รายงานฟีเจอร์เอาต์พุต android.hardware.audio และ "ต้อง" ติดตั้ง API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นอย่างน้อย

การใช้งานอุปกรณ์ Android Watch อาจแต่ไม่มีเอาต์พุตเสียง แต่การใช้งานอุปกรณ์ Android ประเภทอื่นๆ ต้องมีเอาต์พุตเสียงและประกาศ android.hardware.audio.output

7.8.2.1 พอร์ตเสียงแอนะล็อก

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

• ต้องรองรับการเล่นเสียงในหูฟังสเตอริโอและชุดหูฟังสเตอริโอพร้อมไมโครโฟน และควรรองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอพร้อมไมโครโฟน
• ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับการปักหมุด CTIA และควรรองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
• ต้องรองรับการตรวจจับไมโครโฟนบนอุปกรณ์เสริมสำหรับเสียงที่เสียบอยู่ หากการใช้งานอุปกรณ์รองรับไมโครโฟน และเผยแพร่ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนค่าพิเศษเป็น 1
• ต้องรองรับการตรวจจับและการจับคู่กับคีย์โค้ดสำหรับค่าอิมพีแดนซ์เทียบเท่า 3 ช่วงต่อไปนี้ระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียง
  • ไม่เกิน 70 โอห์ม : KEYCODE_HEADSETHOOK
  • 210-290 โอห์ม : KEYCODE_VOLUME_UP
  • 360-680 โอห์ม : KEYCODE_VOLUME_DOWN
• แนะนำอย่างยิ่งให้ตรวจจับและจับคู่กับรหัสคีย์สำหรับช่วงค่าอิมพีแดนซ์ที่เท่ากันต่อไปนี้ระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียง
  • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
• ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อมีการเสียบปลั๊ก แต่เมื่อรายชื่อติดต่อทั้งหมดบนปลั๊กสัมผัสส่วนที่เกี่ยวข้องบนแจ็คเท่านั้น
• ต้องสามารถขับเคลื่อนแรงดันไฟฟ้าขาออกได้อย่างน้อย 150mV ± 10% จากอิมพีแดนซ์ของลำโพง 32 โอห์ม
• ต้องมีแรงดันไฟฟ้าเบี่ยงเบนของไมโครโฟนระหว่าง 1.8V ~ 2.9V

7.8.3 ใกล้อัลตราซาวด์

เสียงใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz การใช้งานอุปกรณ์ต้องรายงานการรองรับความสามารถในการส่งเสียงแบบเกือบอัลตราซาวด์อย่างถูกต้องผ่าน AudioManager.getProperty API ดังนี้

• หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION และ UNPROCESSED ต้องเป็นไปตามข้อกำหนดต่อไปนี้
  • การตอบสนองกำลังเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องไม่มากกว่า 15 dB ต่ำกว่าการตอบสนองที่ 2 kHz
  • อัตราส่วนของสัญญาณต่อเสียงรบกวนที่ไม่ถ่วงน้ำหนักของไมโครโฟนสูงกว่า 18.5 kHz ถึง 20 kHz สำหรับเสียง 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB
• ถ้า PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง" ค่าการตอบสนองเฉลี่ยของลำโพงที่ความเร็ว 18.5 kHz - 20 kHz ต้องไม่น้อยกว่า 40 dB ต่ำกว่าการตอบสนองที่ 2 kHz

7.9 Virtual Reality

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

7.9.1 โหมด Virtual Reality

การใช้อุปกรณ์มือถือ Android ที่รองรับโหมดสำหรับแอปพลิเคชัน VR ที่จัดการการแสดงผลการแจ้งเตือนแบบสามมิติและปิดใช้องค์ประกอบ UI ของระบบตาเดียว ในขณะที่แอปพลิเคชัน VR มีโฟกัสของผู้ใช้ ต้องประกาศฟีเจอร์ android.software.vr.mode อุปกรณ์ที่ประกาศฟีเจอร์นี้ต้องมีแอปพลิเคชันที่ใช้ android.service.vr.VrListenerService ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่าน android.app.Activity#setVrModeEnabled

7.9.2 เทคโนโลยีความจริงเสมือน (VR) ประสิทธิภาพสูง

การใช้งานอุปกรณ์มือถือ Android ต้องระบุการรองรับ Virtual Reality ประสิทธิภาพสูงในช่วงเวลาของผู้ใช้ที่นานขึ้นผ่านแฟล็กฟีเจอร์ android.hardware.vr.high_performance และเป็นไปตามข้อกำหนดต่อไปนี้

• การใช้งานอุปกรณ์ต้องมี 2 Physical Core เป็นอย่างน้อย
• การใช้งานอุปกรณ์ต้องประกาศฟีเจอร์ android.software.vr.mode
• การใช้งานอุปกรณ์อาจเป็นแกนหลักเฉพาะตัวสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าและอาจรองรับ Process.getExclusiveCores API เพื่อแสดงผลจำนวนแกน CPU ที่มีเฉพาะในแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าเท่านั้น หากระบบรองรับแกนพิเศษ แกนหลักต้องไม่อนุญาตให้กระบวนการพื้นที่ผู้ใช้อื่นๆ ทำงานบนแกนดังกล่าว (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น
• การใช้งานอุปกรณ์ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
• การนำอุปกรณ์ไปใช้งานต้องรองรับ OpenGL ES 3.2
• การใช้งานอุปกรณ์ต้องรองรับ Vulkan ฮาร์ดแวร์ระดับ 0 และควรสนับสนุน Vulkan ฮาร์ดแวร์ระดับ 1
• การใช้งานอุปกรณ์ต้องใช้ EGL_KHR_mutable_render_buffer และ EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync และ EGL_KHR_wait_sync มาใช้เพื่อให้สามารถใช้กับโหมดบัฟเฟอร์ที่ใช้ร่วมกันและแสดงส่วนขยายในรายการส่วนขยาย EGL ที่มีให้ใช้งาน
• GPU และจอแสดงผลต้องสามารถซิงค์ข้อมูลการเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ ซึ่งจะทำให้การแสดงผลเนื้อหา VR แบบสลับตาที่ 60 FPS โดยมีบริบทการแสดงภาพ 2 รายการโดยไม่มีอาร์ติแฟกต์ที่ฉีกขาดซึ่งมองเห็นได้
• การติดตั้งใช้งานอุปกรณ์ต้องใช้ EGL_IMG_context_สำคัญ และแสดงส่วนขยายนั้นในรายการส่วนขยาย EGL ที่มีอยู่
• การติดตั้งใช้งานอุปกรณ์ต้องใช้ GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 และ GL_OVR_multiview_multisampled_render_to_texture และแสดงส่วนขยายในรายการส่วนขยาย GL ที่มีอยู่
• การใช้งานอุปกรณ์ต้องใช้ EGL_EXT_ที่ได้รับการป้องกัน_content และ GL_EXT_prevent_textures เพื่อให้สามารถใช้สำหรับการเล่นวิดีโอแบบ Secure Texture และแสดงส่วนขยายในรายการส่วนขยาย EGL และ GL ที่พร้อมใช้งาน
• การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840x2160@30fps-40Mbps (เทียบเท่ากับ 1920x1080@30fps-10Mbps จำนวน 4 อินสแตนซ์ หรือ 1920x1080@60fps-20Mbps 2 อินสแตนซ์)
• การใช้งานอุปกรณ์ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920x1080@30fps-10Mbps และควรสามารถถอดรหัส 3840x2160@30fps-20Mbps ได้ (เทียบเท่ากับ 1920x1080@30fps จำนวน 4 อินสแตนซ์)
• เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์เพื่อรองรับฟีเจอร์ android.hardware.sensor.hifi_sensors และ "ต้อง" เป็นไปตามข้อกำหนดเกี่ยวกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors
• การใช้งานอุปกรณ์ต้องรองรับ hardwarePropertiesManager.getDeviceTemperatures API และแสดงผลค่าที่แม่นยำสำหรับอุณหภูมิผิวหนัง
• อุปกรณ์จะต้องมีหน้าจอแบบฝังและความละเอียดอย่างน้อยต้องเป็น FullHD(1080p) และแนะนำให้ใช้เป็น QuadHD (1440p) ขึ้นไป
• จอแสดงผลต้องวัดระหว่าง 4.7 นิ้ว และ 6 นิ้ว แบบทแยงมุม
• จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
• เวลาในการตอบสนองของการแสดงผลในโหมดสีเทาเป็นสีเทา ขาวเป็นดำ และดำเป็นขาวต้องไม่ต่ำกว่า 3 มิลลิวินาที
• จอแสดงผลต้องรองรับโหมดความต่อเนื่องต่ำที่มีความต่อเนื่อง ≤ 5 มิลลิวินาที ความต่อเนื่องหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
• การใช้งานอุปกรณ์ต้องรองรับบลูทูธ 4.2 และบลูทูธ LE Data Length ส่วนขยายส่วน 7.4.3

8. ประสิทธิภาพและศักยภาพ

เกณฑ์ด้านประสิทธิภาพขั้นต่ำและเกณฑ์กำลังมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป อุปกรณ์ Android Watch ควรและการใช้งานอุปกรณ์ประเภทอื่นๆ ต้องเป็นไปตามเกณฑ์ต่อไปนี้

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

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

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

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

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

• การเขียนตามลำดับ การใช้งานอุปกรณ์ต้องรับประกันประสิทธิภาพการเขียนตามลำดับอย่างน้อย 5 MB/วินาทีสำหรับไฟล์ 256 MB ที่ใช้บัฟเฟอร์การเขียน 10 MB
• การเขียนแบบสุ่ม การใช้งานอุปกรณ์ต้องรับประกันประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาทีสำหรับไฟล์ 256 MB ที่ใช้บัฟเฟอร์การเขียน 4 KB
• การอ่านตามลำดับ การใช้งานอุปกรณ์ต้องรับประกันประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาทีสำหรับไฟล์ 256 MB ที่ใช้บัฟเฟอร์การเขียน 10 MB
• การอ่านแบบสุ่ม การใช้งานอุปกรณ์ต้องรับประกันประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาทีสำหรับไฟล์ 256 MB ที่ใช้บัฟเฟอร์การเขียน 4 KB

8.3 โหมดประหยัดพลังงาน

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

นอกเหนือจากโหมดประหยัดพลังงานแล้ว อุปกรณ์ Android อาจใช้สถานะกำลังนอนหลับในส่วนใดส่วนหนึ่งหรือทั้ง 4 แบบตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI) แต่หากใช้สถานะพลังงาน S3 และ S4 อุปกรณ์ Android จะเข้าสู่สถานะเหล่านี้ได้เมื่อปิดฝาที่เป็นส่วนประกอบของอุปกรณ์เท่านั้น

8.4 การทำบัญชีการใช้พลังงาน

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

• ต้องสามารถติดตามการใช้พลังงานของส่วนประกอบฮาร์ดแวร์ และแอตทริบิวต์ที่ขับเคลื่อนการใช้งานไปยังแอปพลิเคชันที่เฉพาะเจาะจง กล่าวโดยละเอียดคือการติดตั้งใช้งาน ดังนี้
  • ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
  • ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมแปร์ (mAh)
  • ควรมีแหล่งที่มาจากคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
  • ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ uid_cputime
• ต้องทำให้นักพัฒนาแอปใช้การใช้พลังงานนี้ผ่านคำสั่ง Shell adb shell dumpsys batterystats
• ต้องทำตาม Intent android.intent.action.POWER_USAGE_SUMMARY และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้

8.5 ประสิทธิภาพที่สม่ำเสมอ

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

การใช้งานอุปกรณ์ควรรองรับโหมดประสิทธิภาพที่ยั่งยืนซึ่งจะช่วยให้แอปพลิเคชันยอดนิยมในเบื้องหน้ามีประสิทธิภาพที่สอดคล้องกันเป็นระยะเวลานานเมื่อมีการขอผ่านเมธอด Window.setSustainedPerformanceMode() API การใช้งานอุปกรณ์ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด PowerManager.isSustainedPerformanceModeSupported() API

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

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

หากการใช้งานอุปกรณ์ไม่รองรับแกนพิเศษ อุปกรณ์จะต้องแสดงผลรายการที่ว่างเปล่าผ่านเมธอด Process.getExclusiveCores() API

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

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

9.1 สิทธิ์

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

สิทธิ์ที่มี protectionLevel เป็น "PROTECTION_FLAG_PRIVILEGED" ต้องให้แก่แอปที่โหลดไว้ล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ซึ่งอยู่ในรายการที่อนุญาตของอิมเมจระบบเท่านั้น เช่น เส้นทาง system/priv-app ในการใช้งาน AOSP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• การใช้งานอุปกรณ์ Android Automotive ที่เปิดใช้การรองรับผู้ใช้หลายคนจะต้องมีบัญชีผู้มาเยือนที่อนุญาตฟังก์ชันทั้งหมดที่ให้บริการโดยระบบในรถโดยไม่ต้องให้ผู้ใช้เข้าสู่ระบบ
• การใช้งานอุปกรณ์ที่ไม่ได้ประกาศแฟล็กฟีเจอร์ android.hardware.telephony ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
• ในทางกลับกัน การใช้งานอุปกรณ์ที่ประกาศแฟล็กฟีเจอร์ android.hardware.telephony ต้องไม่รองรับโปรไฟล์ที่ถูกจำกัด แต่ต้องสอดคล้องกับการใช้การควบคุม AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
• การใช้งานอุปกรณ์ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API สำหรับผู้ใช้แต่ละคน
• อินสแตนซ์ของผู้ใช้แต่ละรายในอุปกรณ์ Android ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลภายนอกแยกต่างหาก การใช้งานอุปกรณ์อาจจัดเก็บผู้ใช้หลายคน ลงในวอลุ่มหรือระบบไฟล์เดียวกัน อย่างไรก็ตาม การใช้งานอุปกรณ์ต้องดูแลให้แอปพลิเคชันที่เป็นของผู้ใช้และเรียกใช้ในนามของผู้ใช้ที่กำหนดนั้นไม่สามารถแสดงรายการ อ่าน หรือเขียนลงในข้อมูลที่เป็นของผู้ใช้รายอื่น โปรดทราบว่าสื่อแบบถอดได้ เช่น ช่องเสียบการ์ด SD สามารถอนุญาตให้ผู้ใช้รายหนึ่งเข้าถึงข้อมูลของผู้อื่นได้โดยใช้พีซีโฮสต์ ด้วยเหตุนี้ การใช้งานอุปกรณ์ที่ใช้สื่อแบบถอดได้สำหรับ API การจัดเก็บข้อมูลภายนอกต้องเข้ารหัสเนื้อหาในการ์ด SD หากมีการเปิดใช้งานผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บในสื่อที่นำออกไม่ได้ซึ่งเข้าถึงได้ผ่านระบบเท่านั้น เนื่องจากการดำเนินการนี้จะทำให้พีซีที่เป็นโฮสต์อ่านสื่อไม่ได้ การใช้งานอุปกรณ์จึงจำเป็นจะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้ PC โฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้ ดังนั้น การใช้งานอุปกรณ์อาจแต่ไม่ควรเปิดใช้ผู้ใช้หลายคนหากผู้ใช้ใช้สื่อแบบถอดได้เป็นที่จัดเก็บข้อมูลภายนอกหลัก

9.6 คำเตือนทาง SMS แบบพรีเมียม

Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมที่ส่งออก ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการ ซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้ การใช้งานอุปกรณ์ที่ประกาศการรองรับ android.hardware.telephony ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปซึ่งระบุไว้ในไฟล์ /data/misc/sms/codes.xml ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ที่มีการติดตั้งใช้งานซึ่งเป็นไปตามข้อกำหนดนี้

9.7 ฟีเจอร์ความปลอดภัยของเคอร์เนล

แซนด์บ็อกซ์ของ Android ประกอบด้วยฟีเจอร์ที่ใช้ระบบควบคุมการเข้าถึง (MAC) ที่บังคับของ Security-Enhanced Linux (SELinux) การทำแซนด์บ็อกซ์ Seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ที่ใช้งานภายใต้เฟรมเวิร์ก Android:

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

หากมีการเปิดเผย API สำหรับการกำหนดค่านโยบายในแอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่น (เช่น Device Administration API) API จะต้องไม่อนุญาตการกำหนดค่าที่แยกความเข้ากันได้

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

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

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

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

อุปกรณ์ต้องใช้กลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนลที่อนุญาตการกรองการเรียกระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบหลายเธรด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางเป็นไปตามข้อกำหนดนี้ผ่านการเปิดใช้ seccomp-BPF ที่มีการซิงค์ข้อมูล Threadgroup (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่า Kernel ของ source.android.com

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

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

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

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

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

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

9.9 การเข้ารหัสพื้นที่เก็บข้อมูล

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

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

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

9.9.1 Direct Boot

อุปกรณ์ทั้งหมดต้องใช้ API โหมดการเปิดเครื่องโดยตรง แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม โดยเฉพาะอย่างยิ่ง Intent LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED ต้องยังคงเผยแพร่ Intent เพื่อส่งสัญญาณแจ้งแอปพลิเคชัน Direct Boot ที่ทราบว่าอุปกรณ์มีตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) สำหรับผู้ใช้

9.9.2 การเข้ารหัสตามไฟล์

การติดตั้งใช้งานอุปกรณ์ที่รองรับ FBE:

• ต้องเปิดเครื่องโดยไม่ให้ผู้ใช้ขอข้อมูลเข้าสู่ระบบ และอนุญาตให้แอป Direct Boot Aware เข้าถึงพื้นที่เก็บข้อมูล Device Encrypted (DE) หลังจากเผยแพร่ข้อความ LOCKED_BOOT_COMPLETED แล้ว
• ต้องอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสข้อมูลรับรอง (CE) เฉพาะหลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยให้ข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และระบบจะเผยแพร่ข้อความ ACTION_USER_UNLOCKED การใช้งานอุปกรณ์ต้องไม่เสนอวิธีปลดล็อกพื้นที่เก็บข้อมูลที่ได้รับการป้องกันโดย CE โดยผู้ใช้ไม่ต้องเข้าสู่ระบบ
• ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันและตรวจสอบว่าคีย์ DE เชื่อมโยงกับรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์แบบเข้ารหัส
• ต้องรองรับการเข้ารหัสเนื้อหาของไฟล์โดยใช้ AES ที่มีความยาวคีย์ 256 บิตในโหมด XTS
• ต้องรองรับชื่อไฟล์การเข้ารหัสโดยใช้ AES ที่มีความยาวคีย์ 256 บิตในโหมด CBC-CTS
• อาจรองรับการเข้ารหัส ความยาวคีย์ และโหมดอื่นสำหรับเนื้อหาไฟล์และการเข้ารหัสชื่อไฟล์ แต่ "ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมด" ที่สนับสนุนที่จำเป็นโดยค่าเริ่มต้น
• ควรทำให้แอปสำคัญที่โหลดไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเซนเจอร์) Direct Boot

คีย์ที่ช่วยปกป้องพื้นที่เก็บข้อมูล CE และ DE มีดังนี้

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

โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำโดยอิงตามฟีเจอร์การเข้ารหัส Kernel ext4 ของ Linux

9.9.3 การเข้ารหัสดิสก์เต็มรูปแบบ

การใช้งานอุปกรณ์ที่รองรับการเข้ารหัสดิสก์เต็มรูปแบบ (FDE) ต้องใช้ AES กับคีย์ขนาด 128 บิต (หรือมากกว่า) และโหมดที่ออกแบบมาสำหรับพื้นที่เก็บข้อมูล (เช่น AES-XTS, AES-CBC-ESSIV) ต้องไม่มีการเขียนคีย์การเข้ารหัสไปยังพื้นที่เก็บข้อมูลเมื่อใดก็ตามที่ไม่มีการเข้ารหัส นอกเหนือจากการใช้งานจริง คีย์การเข้ารหัสควรเข้ารหัส AES ด้วยข้อมูลเข้าสู่ระบบล็อกหน้าจอที่ขยายโดยใช้อัลกอริทึมการยืดช้า (เช่น PBKDF2 หรือ scrypt) ถ้าผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกหรือปิดใช้รหัสผ่านในการเข้ารหัส ระบบควรใช้รหัสผ่านเริ่มต้นเพื่อรวมคีย์การเข้ารหัส หากอุปกรณ์มีคีย์สโตร์ที่ใช้ฮาร์ดแวร์ อัลกอริทึมการขยายรหัสผ่านจะต้องผูกกับคีย์สโตร์ดังกล่าวแบบเข้ารหัส ต้องไม่มีการส่งคีย์การเข้ารหัสออกจากอุปกรณ์ (แม้ว่าจะพันด้วยรหัสผ่านของผู้ใช้และ/หรือคีย์ที่ผูกกับฮาร์ดแวร์ก็ตาม) โปรเจ็กต์โอเพนซอร์ส Android ติดตั้งใช้งานฟีเจอร์นี้ที่ต้องการโดยอิงตาม dm-crypt ของฟีเจอร์เคอร์เนลของ Linux

9.10 ความสมบูรณ์ของอุปกรณ์

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

การใช้งานอุปกรณ์ต้องรายงานผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() อย่างถูกต้องว่าสถานะ Bootloader ของตนอนุญาตให้มีการกะพริบอิมเมจของระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ระบบใหม่นี้

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

• ประกาศแฟล็กฟีเจอร์แพลตฟอร์ม android.software.verified_boot
• ดำเนินการยืนยันในทุกลำดับการเปิดเครื่อง
• เริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือและไปจนถึงพาร์ติชันระบบ
• ใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความถูกต้องและความน่าเชื่อถือของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
• ใช้อัลกอริทึมการยืนยันที่มีประสิทธิภาพเช่นเดียวกับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
• ต้องไม่อนุญาตให้การเปิดเครื่องเสร็จสมบูรณ์เมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้ยินยอมที่จะลองเปิดเครื่องใหม่ ซึ่งในกรณีนี้ ต้องไม่ใช้ข้อมูลจากการบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยัน
• ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้ได้ปลดล็อกตัวโหลดการเปิดเครื่องอย่างชัดเจน

โปรเจ็กต์โอเพนซอร์ส Android ติดตั้งใช้งานฟีเจอร์นี้ที่ต้องการโดยอิงตาม dm-verity ฟีเจอร์เคอร์เนลของ Linux

ตั้งแต่ Android 6.0 เป็นต้นไป การใช้งานอุปกรณ์ที่มีประสิทธิภาพคริปโตแบบ Advanced Encryption Standard (AES) เกิน 50 MiB/วินาทีต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันสำหรับความสมบูรณ์ของอุปกรณ์

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

9.11 คีย์และข้อมูลเข้าสู่ระบบ

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

การใช้งานอุปกรณ์ Android ทั้งหมดต้องเป็นไปตามข้อกำหนดต่อไปนี้

• ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้ และอย่างน้อยต้องอนุญาตให้มีการนำเข้าคีย์มากกว่า 8,192 รายการ
• การตรวจสอบสิทธิ์หน้าจอล็อกต้องพยายามจำกัดจำนวนอัตราและต้องมีอัลกอริทึม Exponential Backoff หากเกินจากความพยายามที่ล้มเหลวเกิน 150 ครั้ง ความล่าช้าจะต้องมีอย่างน้อย 24 ชั่วโมงต่อความพยายามหนึ่งครั้ง
• เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์ต้องสำรองการใช้งานคีย์สโตร์ด้วยฮาร์ดแวร์ที่ปลอดภัยและเป็นไปตามข้อกำหนดต่อไปนี้
  • ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชสำหรับครอบครัว MD5, SHA1, SHA-2 ที่รองรับอัลกอริทึมที่รองรับระบบคีย์สโตร์ Android อย่างเหมาะสม
  • ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในฮาร์ดแวร์ที่ปลอดภัย และเฉพาะเมื่ออนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์เรียบร้อยแล้ว โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) ที่ทำตามข้อกำหนดนี้ได้

โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่ใช้ฮาร์ดแวร์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint ซึ่งต้องใช้คีย์สโตร์แบบใช้ฮาร์ดแวร์

9.11.1 หน้าจอล็อกที่ปลอดภัย

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

• หากอิงตามข้อมูลลับที่ทราบ ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย เว้นแต่ว่าจะตรงตามข้อกำหนดต่อไปนี้ทั้งหมด
  • เอนโทรปีของอินพุตที่มีความยาวสั้นที่สุดต้องมากกว่า 10 บิต
  • เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์ที่มีอยู่ (PIN, รูปแบบ, รหัสผ่าน) ที่นำไปใช้และระบุไว้ใน AOSP
  • ต้องปิดใช้เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_SOMETHING
• วิธีการตรวจสอบสิทธิ์ที่ใช้โทเค็นจริงหรือตำแหน่ง ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย เว้นแต่ว่าจะมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้ทั้งหมด
  • แอปต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตามข้อกำหนดในการเป็นหน้าจอล็อกที่ปลอดภัย
  • โดยต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_UNSPECIFIED เท่านั้น
• วิธีการตรวจสอบสิทธิ์ หากใช้ข้อมูลไบโอเมตริก ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย เว้นแต่ว่าวิธีดังกล่าวจะเป็นไปตามข้อกำหนดทั้งหมดต่อไปนี้
  • แอปต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตามข้อกำหนดในการเป็นหน้าจอล็อกที่ปลอดภัย
  • โดยต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์คีย์การ์ดโดยเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) เท่านั้น
  • ต้องมีอัตราการยอมรับที่เป็นเท็จ ซึ่งเท่ากับหรือสูงกว่าที่กำหนดไว้สำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10 ไม่เช่นนั้นจะต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเฉพาะเมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่ที่เข้มงวดมากกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
• หากไม่ใช้วิธีการตรวจสอบสิทธิ์เป็นหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการดังนี้
  • ต้องแสดงผล false สำหรับทั้งเมธอด KeyguardManager.isKeyguardSecure() และ KeyguardManager.isDeviceSecure()
  • ต้องปิดใช้เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_UNSPECIFIED
  • ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ DevicePolicyManager.setPasswordExpirationTimeout() ตั้งไว้
  • ต้องไม่ตรวจสอบสิทธิ์การเข้าถึงคีย์สโตร์หากแอปพลิเคชันเรียกใช้ KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) )
• หากวิธีการตรวจสอบสิทธิ์ใช้โทเค็นทางกายภาพ ตำแหน่ง หรือข้อมูลไบโอเมตริกที่มีอัตราการยอมรับเท็จสูงกว่าที่จำเป็นสำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10 ระบบจะดำเนินการต่อไปนี้
  • ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ DevicePolicyManager.setPasswordExpirationTimeout() ตั้งไว้
  • ต้องไม่ตรวจสอบสิทธิ์การเข้าถึงคีย์สโตร์หากแอปพลิเคชันเรียกใช้ KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)

9.12 การลบข้อมูล

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

• อิมเมจระบบ
• ไฟล์ระบบปฏิบัติการใดๆ ก็ตามที่ต้องใช้ในอิมเมจระบบ

ต้องลบข้อมูลที่ผู้ใช้สร้างขึ้นทั้งหมด การดำเนินการนี้ต้องเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้องสำหรับการลบข้อมูล เช่น NIST SP800-88 ต้องใช้สำหรับการติดตั้งใช้งาน {1}WipeData() API (ส่วนหนึ่งของ Android Device Administration API) ที่อธิบายไว้ในส่วนที่ 3.9 การดูแลระบบอุปกรณ์

อุปกรณ์อาจล้างข้อมูลได้อย่างรวดเร็วซึ่งจะทำการลบข้อมูลแบบลอจิคัล

9.13 โหมดปลอดภัยเปิดเครื่อง

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

เราขอแนะนำให้ใช้อุปกรณ์ Android เป็นหลักเพื่อใช้โหมดปลอดภัยและเป็นไปตามข้อกำหนดต่อไปนี้

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

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

• การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้

9.14 การแยกระบบยานพาหนะ

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

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

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

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

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

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

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

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

10.2 ผู้ตรวจสอบ CTS

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

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

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

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

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

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

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

แต่หากการใช้งานอุปกรณ์รวมการรองรับการเชื่อมต่ออินเทอร์เน็ตที่ไม่มีการวัดปริมาณอินเทอร์เน็ต เช่น 802.11 หรือโปรไฟล์ Bluetooth PAN (Personal Area Network) อุปกรณ์จะต้องรองรับการดาวน์โหลด OTA พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต

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

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

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

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

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

สำหรับสรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้ ให้ทำดังนี้

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

หากต้องการดูสรุปการเปลี่ยนแปลงของแต่ละส่วน ให้ทำดังนี้

1. บทนำ
2. ประเภทอุปกรณ์
3. ซอฟต์แวร์
4. การจัดแพ็กเกจแอปพลิเคชัน
5. มัลติมีเดีย
6. เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
7. ความเข้ากันได้ของฮาร์ดแวร์
8. ประสิทธิภาพและศักยภาพ
9. โมเดลความปลอดภัย
10. การทดสอบความเข้ากันได้กับซอฟต์แวร์
11. ซอฟต์แวร์ที่อัปเดตได้
12. บันทึกการเปลี่ยนแปลงของเอกสาร
13. ติดต่อเรา

12.1 เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง

การเปลี่ยนแปลงจะมีการทำเครื่องหมายดังต่อไปนี้

• CDD
  การเปลี่ยนแปลงที่สำคัญในข้อกำหนดด้านความเข้ากันได้

• เอกสาร
  การเปลี่ยนแปลงที่เกี่ยวข้องหรือสร้างขึ้นใหม่

เพื่อการแสดงผลที่ดีที่สุด ให้เพิ่มพารามิเตอร์ของ URL pretty=full และ no-merges ต่อท้าย URL ของบันทึกการเปลี่ยนแปลง

13. ติดต่อเรา

คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ครอบคลุม