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 Television หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสําหรับรับชมสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสําหรับผู้ใช้ที่อยู่ห่างออกไปประมาณ 10 ฟุต ("การนั่งดูทีวี" หรือ "อินเทอร์เฟซผู้ใช้ระยะ 10 ฟุต") อุปกรณ์ Android Television มีลักษณะดังนี้

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

อุปกรณ์นาฬิกา Android หมายถึงการใช้งานอุปกรณ์ 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 การกําหนดค่าอุปกรณ์

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

หมวดหมู่	ฟีเจอร์	ส่วน	มือถือ	โทรทัศน์	ดู	ยานยนต์	อื่นๆ
อินพุต	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 ความเข้ากันได้ของ Managed API

สภาพแวดล้อมการเรียกใช้ไบต์โค้ด Dalvik ที่มีการจัดการเป็นแพลตฟอร์มหลักสำหรับแอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือชุดอินเทอร์เฟซแพลตฟอร์ม 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 "แบบซอฟต์" ที่สำคัญซึ่งใช้ได้เฉพาะในรันไทม์ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ขณะคอมไพล์แอปพลิเคชันได้

3.2.1. สิทธิ์

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

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

API ของ Android มีค่าคงที่หลายรายการในคลาส 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
VERSION.INCREMENTAL	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ห้ามนำค่านี้ไปใช้กับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")
กระดาน	ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เฉพาะเจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือการระบุการแก้ไขที่เฉพาะเจาะจงของแผงวงจรที่จ่ายไฟให้อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
แบรนด์	ค่าที่แสดงถึงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรแสดงถึงผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่อุปกรณ์ดังกล่าวใช้ในการทำการตลาด ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
SUPPORTED_ABIS	ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
SUPPORTED_32_BIT_ABIS	ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
SUPPORTED_64_BIT_ABIS	ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU_ABI	ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU_ABI2	ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
อุปกรณ์	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อรหัสที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
FINGERPRINT	สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้ $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) เช่น acme/myproduct/     mydevice: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_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SERIAL	หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^([a-zA-Z0-9]{6,20})$"
แท็ก	รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys, test-keys
เวลา	ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น
ประเภท	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ user, userdebug หรือ eng
ผู้ใช้	ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")
SECURITY_PATCH	ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์ไม่มีช่องโหว่ใดๆ เกี่ยวกับปัญหาที่อธิบายไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สำหรับสาธารณะ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กําหนดไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สําหรับสาธารณะหรือในคําแนะนําด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS	ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิวด์ที่เหมือนกันกับบิวด์นี้ทุกประการ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android และต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("")

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

3.2.3.1. Intent ของแอปพลิเคชันหลัก

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

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

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

3.2.3.2. การแก้ไข Intent

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

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

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

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

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

3.2.3.3. เนมสเปซของ Intent

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

3.2.3.4. เจตนาการออกอากาศ

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับ ABI ของ Android การดำเนินการต่อไปนี้จะเกิดขึ้น

• ต้องรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกใช้โค้ดเนทีฟโดยใช้นิพจน์ความหมาย 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 ที่ระบุและอธิบายไว้ในเอกสารประกอบการจัดการ ABI ของ Android NDK เวอร์ชันล่าสุด และต้องรองรับส่วนขยาย 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 (Vulkan)
• 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 ซึ่งจะส่งออกสัญลักษณ์ฟังก์ชันสําหรับ API หลักของ Vulkan 1.0 รวมถึงส่วนขยาย VK_KHR_surface, VK_KHR_android_surface และ VK_KHR_swapchain เสมอ

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

• ต้องรายงาน VkPhysicalDevices อย่างน้อย 1 รายการผ่านการเรียกใช้ vkEnumeratePhysicalDevices
• VkPhysicalDevices ที่ระบุแต่ละรายการต้องใช้งาน Vulkan 1.0 API อย่างเต็มรูปแบบ
• ต้องรายงาน Flag ฟีเจอร์ 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

NDK ของ Android เวอร์ชันเดิมใช้ /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 ในอุปกรณ์ที่มีการติดตั้งใช้งาน android.webkit.WebView API อย่างสมบูรณ์ และห้ามรายงานในอุปกรณ์ที่ไม่มีการติดตั้งใช้งาน API อย่างสมบูรณ์ การใช้งานโอเพนซอร์สของ Android ใช้โค้ดจากโปรเจ็กต์ Chromium เพื่อใช้งาน android.webkit.WebView เนื่องจากการพัฒนาชุดทดสอบที่ครอบคลุมสำหรับระบบการแสดงผลเว็บนั้นไม่สามารถทำได้ ผู้ติดตั้งใช้งานอุปกรณ์จึงต้องใช้ Chromium รุ่นที่อัปเดตจาก upstream ที่เจาะจงในการใช้งาน 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 ต้นทาง
  • การติดตั้งใช้งานอุปกรณ์อาจไม่ใส่ Mobile ในสตริง User Agent

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

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

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

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

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

• แคชแอปพลิเคชัน/การดำเนินการแบบออฟไลน์
• แท็ก<video>
• geolocation

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

3.5 ความเข้ากันได้ของลักษณะการทํางานของ API

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

• อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทํางานหรือความหมายของ Intent มาตรฐาน
• อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจรของคอมโพเนนต์ระบบบางประเภท (เช่น Service, Activity, ContentProvider ฯลฯ)
• อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน

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

3.6 เนมสเปซของ API

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

• java.*
• javax.*
• sun.*
• android.*
• com.android.*

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

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

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

ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กําหนดเองได้ แต่ API ดังกล่าวต้องไม่อยู่ในเนมสเปซที่องค์กรอื่นเป็นเจ้าของหรืออ้างอิงถึง ตัวอย่างเช่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่ม API ลงในเนมสเปซ com.google.* หรือเนมสเปซที่คล้ายกัน เฉพาะ Google เท่านั้นที่เพิ่ม API ได้ ในทำนองเดียวกัน 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 Watch	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

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

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

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

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

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

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

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

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

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

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

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

3.8.4. ค้นหา

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

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

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

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

3.8.5. ข้อความโทสต์

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

การติดตั้งใช้งานอุปกรณ์ที่ทำงานวอลเปเปอร์ภาพเคลื่อนไหวได้อย่างเสถียรตามที่อธิบายไว้ข้างต้นควรใช้วอลเปเปอร์ภาพเคลื่อนไหว และเมื่อติดตั้งใช้งานแล้ว จะต้องรายงาน Flag ฟีเจอร์แพลตฟอร์ม 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 และรองรับ IME API ตามที่ระบุไว้ในเอกสารประกอบ Android SDK

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

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

ระบบเลิกใช้งาน Remote Control Client API ตั้งแต่ Android 5.0 เป็นต้นไป โดยใช้ Media Notification Template แทน ซึ่งช่วยให้แอปพลิเคชันสื่อผสานรวมกับตัวควบคุมการเล่นที่แสดงบนหน้าจอล็อกได้ การติดตั้งใช้งานอุปกรณ์ที่รองรับหน้าจอล็อก (ยกเว้นการติดตั้งใช้งาน Android Automotive หรือนาฬิกา) จะต้องแสดงการแจ้งเตือนบนหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนด้วยสื่อ

3.8.11. โปรแกรมรักษาหน้าจอ (ก่อนหน้านี้เรียกว่า "ความฝัน")

Android รองรับโปรแกรมรักษาหน้าจอแบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า "ภาพพักหน้าจอ" โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันได้เมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่ได้ใช้งานหรือวางอยู่ในแท่นชาร์จบนโต๊ะ อุปกรณ์ Android Watch อาจใช้โปรแกรมรักษาหน้าจอ แต่การใช้งานอุปกรณ์ประเภทอื่นๆ ควรรองรับโปรแกรมรักษาหน้าจอและให้ตัวเลือกการตั้งค่าแก่ผู้ใช้ในการกำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อ Intent 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 Extended A, B, C และ D และสัญลักษณ์ทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0

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

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

• แอปพลิเคชันสามารถระบุได้ว่าสามารถทำงานในโหมดหลายหน้าต่างในไฟล์ AndroidManifest.xml ได้หรือไม่ ไม่ว่าจะระบุอย่างชัดเจนผ่านแอตทริบิวต์ android:resizeableActivity หรือระบุโดยนัยด้วยการกำหนด targetSdkVersion > 24 แอปที่ตั้งค่าแอตทริบิวต์นี้เป็น false อย่างชัดแจ้งในไฟล์ Manifest ต้องไม่เปิดในโหมดหลายหน้าต่าง แอปที่ไม่ได้ตั้งค่าแอตทริบิวต์ในไฟล์ Manifest (targetSdkVersion < 24) จะเปิดได้ในโหมดหลายหน้าต่าง แต่ระบบต้องแสดงคำเตือนว่าแอปอาจไม่ทำงานตามที่คาดไว้ในโหมดหลายหน้าต่าง
• การใช้งานอุปกรณ์ต้องไม่มีโหมดแยกหน้าจอหรือโหมดอิสระหากทั้งความสูงและความกว้างของหน้าจอน้อยกว่า 440 dp
• การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ xlarge ควรรองรับโหมดอิสระ
• การติดตั้งใช้งานอุปกรณ์ Android Television จะต้องรองรับโหมดภาพในภาพ (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 อุปกรณ์จะต้องใช้การจัดสรรแอปเจ้าของอุปกรณ์ของแอปพลิเคชันไคลเอ็นต์นโยบายด้านอุปกรณ์ (DPC) ตามที่ระบุไว้ด้านล่าง

• เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่ได้กําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
  • ต้องรายงาน true สำหรับ DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
  • ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์เพื่อตอบสนองต่อการดำเนินการตาม Intent android.app.action.PROVISION_MANAGED_DEVICE
  • ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์หากอุปกรณ์ประกาศการรองรับ Near-Field Communication (NFC) ผ่าน Flag ฟีเจอร์ 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 ต้องมีการลงทะเบียนแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12. TV Input Framework

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

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

3.12.1. แอปทีวี

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

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

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

3.12.1.1. คู่มือรายการทีวีอิเล็กทรอนิกส์

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

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

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

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

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

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

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

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

3.12.1.4. การเลื่อนเวลา

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

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

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

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

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

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

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

3.14 Vehicle UI API

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

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

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

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

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

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

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

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

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

5.1 ตัวแปลงรหัสสื่อ

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

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

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

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

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

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

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

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

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

5.1.1. ตัวแปลงรหัสเสียง

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
โปรไฟล์ MPEG-4 AAC (AAC LC)	ต้องระบุ 1	ต้องระบุ	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 2 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC ไฟล์ดิบ ADTS (.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 Kbps ถึง 23.85 Kbps ที่อัตราตัวอย่าง 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 และ Mobile XMF รองรับรูปแบบริงโทน RTTTL/RTX, OTA และ iMelody	ประเภท 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		ต้องระบุ		Ogg (.ogg) Matroska (.mkv, Android 4.0 ขึ้นไป)
PCM/WAVE	ต้องระบุ 4 (Android 4.1 ขึ้นไป)	ต้องระบุ	PCM แบบเชิงเส้น 16 บิต (อัตราสูงสุดตามขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM ดิบที่ความถี่ 8000, 11025, 16000 และ 44100 Hz	WAVE (.wav)
Opus		ต้องระบุ (Android 5.0 ขึ้นไป)		Matroska (.mkv), Ogg(.ogg)

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

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

• มีการถอดรหัสโดยไม่ลดขนาด (เช่น สตรีม AAC 5.0 ต้องถอดรหัสเป็น PCM 5 แชนแนล สตรีม AAC 5.1 ต้องถอดรหัสเป็น 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_LEVEL

3 ต้องระบุสำหรับการติดตั้งใช้งานในอุปกรณ์ Android Handheld

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

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

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG	ต้องระบุ	ต้องระบุ	Base+progressive	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_FormatYUV420Flexible)

รูปแบบ/ตัวแปลงรหัส	โปรแกรมเปลี่ยนไฟล์	ตัวถอดรหัส	รายละเอียด	ประเภทไฟล์/ รูปแบบคอนเทนเนอร์ที่รองรับ
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 ขึ้นไป)
H.265 HEVC		ต้องระบุ 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 Television เท่านั้น

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

ตัวแปลงรหัสวิดีโอ H.264, VP8, VP9 และ HEVC

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

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

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

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

5.2.1. H.263

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

5.2.2. H-264

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

• ต้องรองรับโปรไฟล์พื้นฐานระดับ 3
  อย่างไรก็ดี คุณจะรองรับ ASO (การจัดเรียงสไลซ์แบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (สไลซ์ที่ซ้ำกัน) หรือไม่ก็ได้ นอกจากนี้ เราขอแนะนำว่าโปรแกรมเปลี่ยนไฟล์ไม่ควรใช้ 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 ต้องรองรับระดับ High ของโปรไฟล์หลัก

5.3.2. H.263

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

5.3.3. MPEG-4

การติดตั้งใช้งานอุปกรณ์ Android ที่มีโปรแกรมถอดรหัส MPEG-4 จะต้องรองรับโปรไฟล์แบบง่ายระดับ 3

5.3.4. H.264

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

• ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน
  การรองรับ ASO (การจัดเรียงข้อมูลเป็นชิ้นแบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (ข้อมูลย่อยที่ซ้ำกัน) เป็นตัวเลือก
• ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline และโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
• ควรถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ได้ตามที่ระบุไว้ในตารางต่อไปนี้
• นอกจากนี้ อุปกรณ์ Android Television ต่อไปนี้
  • ต้องรองรับโปรไฟล์ High Profile ระดับ 4.2 และโปรไฟล์การถอดรหัส HD 1080p60
  • ต้องสามารถถอดรหัสวิดีโอที่มีทั้งโปรไฟล์ HD ตามที่ระบุไว้ในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline, โปรไฟล์หลัก หรือโปรไฟล์ High ระดับ 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 Television

5.3.5. H.265 (HEVC)

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

• ต้องรองรับโปรไฟล์หลักระดับ 3 ระดับหลักและโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
• ควรรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
• ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมถอดรหัสฮาร์ดแวร์
• นอกจากนี้ อุปกรณ์ Android TV ยังมีลักษณะต่อไปนี้
• ต้องรองรับโปรไฟล์การถอดรหัส HD 720p
• ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD 1080p หากรองรับโปรไฟล์การถอดรหัส HD 1080p อุปกรณ์ต้องรองรับโปรไฟล์หลักระดับ 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 Television ที่มีการถอดรหัสด้วยฮาร์ดแวร์ 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 Television

5.3.7. VP9

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

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

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

  • ต้องรองรับโปรไฟล์การถอดรหัส HD 720p
  • ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD 1080p
  • ควรรองรับโปรไฟล์การถอดรหัส UHD หากรองรับโปรไฟล์การถอดรหัสวิดีโอ UHD อุปกรณ์จะต้องรองรับความลึกของสี 8 บิตและควรรองรับ VP9 โปรไฟล์ 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 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television ที่มีการถอดรหัสด้วยฮาร์ดแวร์ VP9

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

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

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

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

• รูปแบบ : Linear PCM, 16 บิต
• อัตราการสุ่มตัวอย่าง : 8000, 11025, 16000, 44100
• Channels : Mono

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

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

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

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

5.4.3. บันทึกเพื่อเปลี่ยนเส้นทางการเล่น

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

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้

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

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

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

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

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

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

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

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

• สตรีมมิงแบบเป็นขั้นเป็นตอนของ HTTP(S)
  ต้องรองรับตัวแปลงสัญญาณและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)

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

รูปแบบกลุ่ม	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
MPEG-2 Transport Stream	ISO 13818	ตัวแปลงรหัสวิดีโอ: H264 AVC MPEG-4 SP MPEG-2 ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP และ MPEG-2 ได้ที่ส่วนที่ 5.1.3 ตัวแปลงรหัสเสียง 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-LATM	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. Secure Media

การติดตั้งใช้งานอุปกรณ์ที่รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพลตฟอร์มที่ปลอดภัยต้องประกาศการรองรับ 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 ทั้งหมดต่อไปนี้ ซึ่งให้การเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป เราขอแนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager

การส่งผ่านฮาร์ดแวร์ที่รองรับ MIDI มีดังนี้

• โหมดโฮสต์ USB (ส่วนที่ 7.7 USB)
• โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7 USB)
• MIDI ผ่านบลูทูธ 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)

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

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

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

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 เมื่อเทียบกับช่วงความถี่กลาง

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

• SNR มากกว่า 60 dB (ความแตกต่างระหว่าง SPL 94 dB กับ SPL ที่เทียบเท่าของเสียงรบกวนจากตัวอุปกรณ์เอง โดยถ่วงน้ำหนักตาม A)

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

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

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

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

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

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

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

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

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

• Android Debug Bridge (adb)
  • การติดตั้งใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK รวมถึง dumpsys
  • เดรัม adb ฝั่งอุปกรณ์ต้องไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge หากการติดตั้งใช้งานอุปกรณ์ไม่มีโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นต้องใช้ Android Debug Bridge ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ 802.11)
  • Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักซึ่งผ่านการตรวจสอบสิทธิ์ การติดตั้งใช้งานอุปกรณ์ต้องรองรับ adb ที่ปลอดภัย
• Dalvik Debug Monitor Service (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 คุณต้องจัดเตรียมไดรเวอร์เหล่านี้สำหรับ Windows XP, Windows Vista, Windows 7, Windows 8 และ Windows 10 ทั้งเวอร์ชัน 32 บิตและ 64 บิต

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

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

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

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

• คุณต้องยังคงแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
• ลักษณะการทํางานของ API ต้องติดตั้งใช้งานแบบ No-Ops ในลักษณะที่เหมาะสม
• เมธอด 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 ซึ่งคำนวณโดยสูตร pixels = dps * (density/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_WATCH ระบบอาจตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)
• หากแอปของบุคคลที่สามระบุว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity ระบบจะไม่จำกัดค่าสัดส่วนการแสดงผล
• สำหรับกรณีอื่นๆ ทั้งหมด สัดส่วนภาพต้องมีค่าระหว่าง 1.3333 (4:3) ถึง 1.86 (ประมาณ 16:9) เว้นแต่แอปจะระบุไว้อย่างชัดเจนว่ารองรับสัดส่วนภาพหน้าจอที่สูงกว่าผ่านค่าข้อมูลเมตา maxAspectRatio

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

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

• 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.85x
• ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
• ใหญ่: 1.15 เท่า
• ใหญ่ขึ้น: 1.3 เท่า
• ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

การติดตั้งใช้งานอุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่กําหนดไว้ใน 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 ของ OpenGL ที่เป็น C/C++ ดั้งเดิม (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.so จะต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องนอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0

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

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

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

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือมุมมองผ่านการใช้แท็กไฟล์ Manifest android:hardwareAccelerated หรือการเรียก 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 ไม่รองรับโหมดความเข้ากันได้เดิม
• การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมดต้องรองรับโหมดความเข้ากันได้ของแอปพลิเคชันเดิมตามที่ติดตั้งใช้งานโดยโค้ดโอเพนซอร์สจาก upstream ของ 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 ของนักพัฒนาแอปสำหรับการเข้าถึงจอแสดงผลภายนอก หากอุปกรณ์รองรับจอแสดงผลภายนอกผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมที่ฝังอยู่ การใช้งานอุปกรณ์ต้องใช้ display manager 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. การนำทางแบบไม่สัมผัส

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

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

7.2.3. ปุ่มนำทาง

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

• การติดตั้งใช้งานอุปกรณ์ Android แบบพกพาต้องมีฟังก์ชันหน้าแรก ล่าสุด และกลับ
• การติดตั้งใช้งานอุปกรณ์ Android Television ต้องมีฟังก์ชันหน้าแรกและกลับ
• การติดตั้งใช้งานอุปกรณ์ Android Watch ต้องมีฟังก์ชันหน้าแรกและฟังก์ชันกลับสำหรับผู้ใช้ ยกเว้นในกรณีที่อยู่ในโหมด 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 ที่รองรับการดำเนินการ Assist และ/หรือ VoiceInteractionService ต้องสามารถเปิดแอป Assist ด้วยการโต้ตอบเพียงครั้งเดียว (เช่น การแตะ การคลิกสองครั้ง หรือท่าทางสัมผัส) เมื่อปุ่มการไปยังส่วนต่างๆ อื่นๆ ปรากฏอยู่ ขอแนะนำอย่างยิ่งให้ใช้การกดแป้น Home ค้างไว้เป็นอินเทอร์แอกชันนี้ การโต้ตอบที่กําหนดต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ Intent 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 รองรับหน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตการสัมผัสจำลองที่หลากหลาย การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลเพื่อให้ผู้ใช้รู้สึกว่ากำลังควบคุมรายการต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อระบุวัตถุที่กำลังมีการจัดการ ในทางตรงกันข้าม อินเทอร์เฟซการสัมผัสจำลองมีระบบการป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายแบบใช้แรงโน้มถ่วง ปากกาควบคุมแบบใช้แรงโน้มถ่วง จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบสัมผัสจำลอง 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 จะต้องเป็นไปตามข้อกำหนดสำหรับฟีเจอร์การแตะเสมือนจริงข้างต้น และจะต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการแยกกันด้วย

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

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

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

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

ปุ่ม	การใช้งาน HID 2	ปุ่ม Android
A 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y 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)
ปุ่ม L R ขวา 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
คลิกแท่งบังคับซ้าย 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
คลิกแท่งบังคับด้านขวา 1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home 1	0x0c 0x0223	KEYCODE_HOME (3)
กลับ 1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

การควบคุมแบบแอนะล็อก 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 MotionEvent

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

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

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

7.3. เซ็นเซอร์

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

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

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

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

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

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

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

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

การติดตั้งใช้งานอุปกรณ์ควรมีตัววัดความเร่งแบบ 3 แกน ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android Handheld, การติดตั้งใช้งาน 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 m/s^ โดยค่าเบี่ยงเบนมาตรฐานควรคํานวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด
• ควรใช้เซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK เราขอแนะนําอย่างยิ่งให้อุปกรณ์ Android เครื่องเก่าและใหม่ใช้เซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION หากมีการใช้เซ็นเซอร์เหล่านี้ ปริมาณการใช้พลังงานทั้งหมดต้องน้อยกว่า 4 mW เสมอ และแต่ละเซ็นเซอร์ควรมีปริมาณการใช้พลังงานต่ำกว่า 2 mW และ 0.5 mW เมื่ออุปกรณ์อยู่ในสถานะแบบไดนามิกหรือแบบคงที่
• หากมีเซ็นเซอร์ไจโรสโคป ต้องติดตั้งใช้งานเซ็นเซอร์คอมโพสิต 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 และรายงานความสามารถไปยังแอปพลิเคชันผ่าน Flag ฟีเจอร์ android.hardware.location.gps ให้ทำดังนี้

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

การติดตั้งใช้งานอุปกรณ์ที่รองรับชุดเซ็นเซอร์คุณภาพสูงขึ้นซึ่งสามารถปฏิบัติตามข้อกําหนดทั้งหมดที่ระบุไว้ในส่วนนี้ จะต้องระบุการรองรับผ่าน Flag ฟีเจอร์ 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/√Hz
  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์ของเซ็นเซอร์
  • ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ไม่เกิน 3 mW
  • ควรมีความเสถียรของค่าเบี่ยงเบนจากค่าเฉลี่ยของสัญญาณรบกวนแบบคงที่ที่น้อยกว่า 15 μg √Hz จากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
  • ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 1mg / °C
  • ควรมีความไม่เป็นเชิงเส้นของเส้นที่พอดีที่สุดไม่เกิน 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิไม่เกิน 0.03%/C°

• SENSOR_TYPE_GYROSCOPE

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

• 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 ถึง 1,100 hPa เป็นอย่างน้อย
  • ต้องมีความละเอียดการวัดอย่างน้อย 80 LSB/hPa
  • ต้องมีความถี่การวัดขั้นต่ำ 1 Hz หรือต่ำกว่า
  • ต้องมีความถี่การวัดสูงสุด 10 Hz ขึ้นไป
  • ต้องมีสัญญาณรบกวนการวัดไม่เกิน 2 Pa/√Hz
  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 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_DETECTOR
  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 1.5 mW เมื่ออุปกรณ์เคลื่อนไหว

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

• การประทับเวลาของเหตุการณ์ของเหตุการณ์จริงเดียวกันที่รายงานโดยเซ็นเซอร์วัดความเร่ง เซ็นเซอร์ไจโรสโคป และเซ็นเซอร์แม่เหล็กไฟฟ้าต้องอยู่ภายใน 2.5 มิลลิวินาที
• การประทับเวลาเหตุการณ์ของเซ็นเซอร์ Gyroscope ต้องเป็นฐานเวลาเดียวกับระบบย่อยของกล้องและมีความคลาดเคลื่อนไม่เกิน 1 มิลลิวินาที
• เซ็นเซอร์ High Fidelity ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 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
• ต้องใช้งาน API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
• ต้องมีอัตรายอมรับที่ผิดพลาดไม่เกิน 0.002%
• ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% โดยวัดจากอุปกรณ์
• ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที ซึ่งวัดจากเวลาที่แตะเซ็นเซอร์ลายนิ้วมือจนกว่าหน้าจอจะปลดล็อกสำหรับนิ้วที่ลงทะเบียน 1 นิ้ว
• ต้องจำกัดจำนวนครั้งที่พยายามเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการพยายามยืนยันลายนิ้วมือที่ไม่สำเร็จ 5 ครั้ง
• ต้องมีการใช้งานคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์ และทำให้การจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
• ต้องเข้ารหัสข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดและตรวจสอบสิทธิ์ด้วยวิทยาการเข้ารหัสเพื่อให้ไม่สามารถรับ อ่าน หรือแก้ไขข้อมูลดังกล่าวนอก Trusted Execution Environment (TEE) ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
• ต้องป้องกันไม่ให้เพิ่มลายนิ้วมือโดยไม่สร้างเชนความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบใหม่ของอุปกรณ์ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การใช้งานโปรเจ็กต์โอเพนซอร์ส Android มีกลไกในเฟรมเวิร์กสำหรับดำเนินการดังกล่าว
• ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกแยะลายนิ้วมือแต่ละลาย
• ต้องปฏิบัติตาม Flag 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 ค่าของ Flag นี้ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของหน้าแดชบอร์ด และควรอิงตามอินพุตของเซ็นเซอร์แสงรอบข้าง เซ็นเซอร์แสงแวดล้อมที่เกี่ยวข้องอาจเหมือนกับโฟโตมิเตอร์

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. โทรศัพท์

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

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

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

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

• ต้องใช้งาน 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 ที่เกี่ยวข้องและมีคุณสมบัติดังนี้

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

7.4.2.1. Wi-Fi Direct

การติดตั้งใช้งานอุปกรณ์ควรรองรับ Wi-Fi Direct (Wi-Fi แบบผู้ใช้ต่อผู้ใช้) หากการติดตั้งใช้งานอุปกรณ์รองรับ 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

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

• ควรใช้ TDLS เฉพาะเมื่อเป็นไปได้และมีประโยชน์เท่านั้น
• ควรใช้การเรียนรู้เชิงสืบสวนบ้างและอย่าใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าใช้งาน 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 ควรรองรับโปรไฟล์การเข้าถึงข้อความ (MAP) การติดตั้งใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้

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

การติดตั้งใช้งานอุปกรณ์ที่รองรับบลูทูธพลังงานต่ำ

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

7.4.4. Near Field Communication

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

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

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

Android รองรับโหมดการจําลองบัตรของโฮสต์ (HCE) ของ NFC หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทางรหัสแอปพลิเคชัน (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 Classic
• MIFARE Ultralight
• NDEF ใน MIFARE Classic

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

• ต้องใช้ Android API ที่เกี่ยวข้องตามที่ Android SDK ระบุไว้
• ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจะไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager
• ต้องไม่ใช้ Android API ที่เกี่ยวข้องหรือรายงานฟีเจอร์ 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 รูปแบบ กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต, Bluetooth PAN ฯลฯ

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

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

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

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

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

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

การเชื่อมต่อ IPv6 ต้องคงอยู่ในโหมดสลีป

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

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

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 ตัว อุปกรณ์จะมีลักษณะดังนี้

• ต้องรายงาน Flag ฟีเจอร์ 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 ตัว อุปกรณ์จะมีลักษณะดังนี้

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

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

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

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

7.5.4. ลักษณะการทํางานของ Camera API

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

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

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

• หากแอปพลิเคชันไม่เคยเรียก android.hardware.Camera.Parameters.setPreviewFormat(int) อุปกรณ์ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลพรีวิวที่ส่งไปยังการเรียกกลับของแอปพลิเคชัน
• หากแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() เมื่อรูปแบบการแสดงตัวอย่างเป็น YCbCr_420_SP ข้อมูลใน byte[] ที่ส่งไปยัง 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

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

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

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

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

การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Intent Camera.ACTION_NEW_PICTURE ทุกครั้งที่กล้องถ่ายรูปภาพใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ

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

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

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

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

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

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

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

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

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

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

Android API มี 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 เพื่อให้เป็นไปตามข้อกำหนดนี้ หากการติดตั้งใช้งานอุปกรณ์รองรับ Media Transfer Protocol อุปกรณ์จะดำเนินการต่อไปนี้

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

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

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

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

7.7. USB

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

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

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

• พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB Type-A หรือ Type-C มาตรฐานได้
• พอร์ตควรใช้รูปแบบของ USB แบบไมโคร-B, ไมโคร-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 audio class ตามที่ระบุไว้ในเอกสารประกอบ 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 รองรับ Power Delivery สำหรับการแลกเปลี่ยนบทบาทของข้อมูลและพลังงาน
• อุปกรณ์ 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 มาตรฐาน
• อาจใช้พอร์ต USB ไมโคร AB แต่หากใช้ ก็ควรมีสายแปลงพอร์ตเป็นพอร์ต USB Type-A หรือ Type-C มาตรฐาน
• ขอแนะนําอย่างยิ่งให้ใช้ USB audio class ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
• ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
• ควรรองรับการชาร์จอุปกรณ์ขณะอยู่ในโหมดโฮสต์ แสดงกระแสแหล่งที่มาอย่างน้อย 1.5 แอมป์ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของ [ข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับที่ 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสเอาต์พุตของพอร์ตดาวน์สตรีมการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 สำหรับขั้วต่อ Micro-AB
• ขอแนะนำอย่างยิ่งให้อุปกรณ์ USB Type-C รองรับ DisplayPort, ควรรองรับอัตราการโอนข้อมูล SuperSpeed ของ USB และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทระหว่างการชาร์จและการโอนข้อมูล
• อุปกรณ์ที่มีพอร์ต Type-A หรือ Type-AB ต้องไม่มีอะแดปเตอร์ที่แปลงจากพอร์ตนี้ไปเป็นเต้ารับ Type-C
• ต้องจดจำอุปกรณ์ MTP (Media Transfer Protocol) ที่เชื่อมต่อจากระยะไกลและทำให้เนื้อหาของอุปกรณ์เข้าถึงได้ผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT หากรองรับ Storage Access Framework (SAF)
• ต้อง ใช้ฟังก์ชันพอร์ตแบบ 2 บทบาทตามที่ข้อกำหนดเฉพาะของ USB Type-C ระบุไว้ (ส่วนที่ 4.5.1.3.3) หากใช้พอร์ต USB Type-C และรองรับโหมดอุปกรณ์ต่อพ่วง
• ควรใช้รุ่น Try.* ที่เหมาะสมที่สุดกับรูปแบบของอุปกรณ์ หากรองรับฟังก์ชันการทำงานของพอร์ตแบบ 2 บทบาท เช่น อุปกรณ์แบบพกพาควรใช้รูปแบบ Try.SNK

7.8. เสียง

7.8.1. ไมโครโฟน

การติดตั้งใช้งานอุปกรณ์อาจไม่รวมไมโครโฟน อย่างไรก็ตาม หากการใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone และต้องใช้งาน API การบันทึกเสียงเป็น No-Op เป็นอย่างน้อย ตามส่วนที่ 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 ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็น No-Op เป็นอย่างน้อย

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

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

หากการใช้งานอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต อย่างน้อย 1 พอร์ตของพอร์ตเสียงควรเป็นช่องเสียบเสียง 3.5 มม. แบบ 4 สาย เพื่อให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมอื่นๆ สำหรับเสียงที่ใช้ปลั๊กเสียง 3.5 มม. ได้ในระบบนิเวศของ Android หากการติดตั้งใช้งานอุปกรณ์มีแจ็คเสียง 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 โอห์ม
• ต้องมีแรงดันไฟฟ้า Bias ของไมโครโฟนระหว่าง 1.8V ~ 2.9V

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

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

• หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION และ UNPROCESSED ต้องเป็นไปตามข้อกำหนดต่อไปนี้
  • การตอบสนองกำลังไฟฟ้าเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องต่ำกว่าการตอบสนองที่ 2 kHz ไม่เกิน 15 dB
  • อัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ไม่ถ่วงน้ำหนักของไมโครโฟนในช่วงความถี่ 18.5-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 และเครื่องมือในการสร้างแอปพลิเคชัน "Virtual Reality" (VR) รวมถึงประสบการณ์ VR บนอุปกรณ์เคลื่อนที่ที่มีคุณภาพสูง การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

7.9.1. โหมด Virtual Reality

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

7.9.2 ประสิทธิภาพสูงสำหรับ Virtual Reality

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

• การติดตั้งใช้งานอุปกรณ์ต้องมี Physical Core อย่างน้อย 2 แกน
• การติดตั้งใช้งานอุปกรณ์ต้องประกาศฟีเจอร์ android.software.vr.mode
• การติดตั้งใช้งานอุปกรณ์อาจจัดสรรแกนประมวลผลสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าโดยเฉพาะ และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนแกน CPU ที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับบนสุดใช้อยู่โดยเฉพาะ หากรองรับแกนหลักแบบไม่แชร์ แกนหลักต้องไม่อนุญาตให้มีกระบวนการอื่นๆ ใน Userspace ทำงานบนแกนหลัก (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางรายการทำงานได้ตามความจำเป็น
• การติดตั้งใช้งานอุปกรณ์ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
• การติดตั้งใช้งานอุปกรณ์ต้องรองรับ 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_priority และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่พร้อมใช้งาน
• การใช้งานอุปกรณ์ต้องใช้ GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 และ GL_OVR_multiview_multisampled_render_to_texture และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
• การใช้งานอุปกรณ์ต้องใช้ EGL_EXT_protected_content และ GL_EXT_protected_textures เพื่อให้ใช้สำหรับการเล่นวิดีโอด้วยพื้นผิวที่ปลอดภัยได้ และแสดงส่วนขยายในรายการส่วนขยาย 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-5Mbps 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 ส่วนที่ 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 อุปกรณ์จะเข้าสู่สถานะเหล่านี้ได้ก็ต่อเมื่อปิดฝาที่เป็นส่วนหนึ่งของอุปกรณ์เท่านั้น

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

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

• ต้องสามารถติดตามการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์และระบุแหล่งที่มาของการใช้พลังงานนั้นให้กับแอปพลิเคชันหนึ่งๆ กล่าวโดยละเอียดคือ การใช้งานต้องมีลักษณะดังนี้
  • ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กําหนดค่าการใช้พลังงานปัจจุบันสําหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
  • ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
  • ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน
  • ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime
• ต้องทำให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ได้ผ่านคำสั่งเชลล์ 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
• การติดตั้งใช้งานอุปกรณ์ต้องไม่อนุญาตให้มีกระบวนการใดๆ ใน User Space ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อทำงานบนแกนหลัก แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางรายการทำงานได้ตามความจำเป็น

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

9.3. สิทธิ์ในระบบไฟล์

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

9.4. สภาพแวดล้อมการดําเนินการอื่น

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

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

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

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

รันไทม์ทางเลือกต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android โดยรันไทม์ทางเลือก ได้แก่

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

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

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

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

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

• การติดตั้งใช้งานอุปกรณ์ Android Automotive ที่เปิดใช้การรองรับผู้ใช้หลายคนต้องมีบัญชีผู้มาเยือนที่อนุญาตให้ใช้ฟังก์ชันทั้งหมดที่ระบบยานพาหนะมีให้โดยไม่ต้องให้ผู้ใช้เข้าสู่ระบบ
• การติดตั้งใช้งานอุปกรณ์ที่ไม่ได้ประกาศ Flag ฟีเจอร์ android.hardware.telephony จะต้องรองรับโปรไฟล์ที่จํากัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ โปรไฟล์ที่จํากัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้เพิ่มเติมได้อย่างรวดเร็ว พร้อมความสามารถในการจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ในสภาพแวดล้อมเหล่านั้น
• ในทางกลับกัน การใช้งานอุปกรณ์ที่ประกาศ Flag ฟีเจอร์ android.hardware.telephony ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุม AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
• การติดตั้งใช้งานอุปกรณ์แต่ละครั้งต้องใช้รูปแบบความปลอดภัยที่สอดคล้องกับรูปแบบความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API
• อินสแตนซ์ผู้ใช้แต่ละรายการในอุปกรณ์ Android ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลภายนอกแยกต่างหากและแยกกัน การติดตั้งใช้งานอุปกรณ์อาจจัดเก็บข้อมูลของผู้ใช้หลายคนในวอลุ่มหรือระบบไฟล์เดียวกัน อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์ต้องตรวจสอบว่าแอปพลิเคชันที่ผู้ใช้เป็นเจ้าของและทำงานในนามของผู้ใช้รายหนึ่งๆ ไม่สามารถแสดงรายการ อ่าน หรือเขียนข้อมูลของผู้ใช้รายอื่น โปรดทราบว่าสื่อแบบถอดออกได้ เช่น ช่องการ์ด SD อาจอนุญาตให้ผู้ใช้รายหนึ่งเข้าถึงข้อมูลของผู้ใช้รายอื่นได้โดยใช้ PC โฮสต์ ด้วยเหตุนี้ การติดตั้งใช้งานอุปกรณ์ที่ใช้สื่อแบบถอดออกได้สำหรับ API พื้นที่เก็บข้อมูลภายนอกจึงต้องเข้ารหัสเนื้อหาของการ์ด SD หากเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อแบบถอดออกไม่ได้เท่านั้นที่ระบบเข้าถึงได้ เนื่องจากจะทำให้ PC โฮสต์อ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จะต้องเปลี่ยนไปใช้ 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 เป็นโหมดการบังคับใช้แบบรวม
• ต้องกําหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดอนุญาต ซึ่งรวมถึงโดเมนสำหรับอุปกรณ์/ผู้ให้บริการโดยเฉพาะ
• ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ neverallow ที่มีอยู่ในโฟลเดอร์ system/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ขั้นต้น และนโยบายต้องคอมไพล์ด้วยกฎ neverallow ทั้งหมดที่มีอยู่ ทั้งสำหรับโดเมน SELinux ของ AOSP และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
• ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการได้แคบลงตามที่อธิบายไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android

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

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

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

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

9.9.1. Direct Boot

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

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

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

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

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

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

โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ตามฟีเจอร์การเข้ารหัส ext4 ของเคอร์เนล Linux

9.9.3. การเข้ารหัสดิสก์ทั้งเครื่อง

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

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

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

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

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

• ประกาศ Flag ฟีเจอร์แพลตฟอร์ม 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. คีย์และข้อมูลเข้าสู่ระบบ

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

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

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

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

9.11.1. หน้าจอล็อกเพื่อความปลอดภัย

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

• วิธีการตรวจสอบสิทธิ์ (หากอิงตามข้อมูลลับที่ทราบ) ต้องไม่ถือว่ามีความปลอดภัยเท่ากับหน้าจอล็อก เว้นแต่ว่าวิธีการดังกล่าวจะเป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด
  • เอนโทรปีของอินพุตที่มีความยาวน้อยที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์ที่มีอยู่ (PIN, รูปแบบ, รหัสผ่าน) ที่ติดตั้งใช้งานและระบุไว้ใน AOSP
  • ต้องปิดใช้เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ด้วยค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_SOMETHING
• วิธีการตรวจสอบสิทธิ์ต้องไม่ถือว่าปลอดภัยหากอิงตามโทเค็นจริงหรือตำแหน่ง เว้นแต่ว่าวิธีการดังกล่าวจะเป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด
  • โดยต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่ทราบและเป็นไปตามข้อกำหนดเพื่อให้ระบบถือว่าหน้าจอล็อกดังกล่าวปลอดภัย
  • คุณต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักในการปลดล็อกหน้าจอเท่านั้นเมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
• วิธีการตรวจสอบสิทธิ์ (หากอิงตามข้อมูลไบโอเมตริก) ต้องไม่ถือว่ามีความปลอดภัยเท่ากับหน้าจอล็อก เว้นแต่ว่าวิธีการดังกล่าวจะเป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด
  • โดยต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่ทราบและเป็นไปตามข้อกำหนดเพื่อให้ระบบถือว่าหน้าจอล็อกดังกล่าวปลอดภัย
  • โดยต้องปิดใช้และอนุญาตให้มีการตรวจสอบสิทธิ์หลักเท่านั้นที่จะปลดล็อกหน้าจอได้เมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ได้ตั้งค่านโยบายฟีเจอร์ keguard โดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)
  • โดยต้องมีอัตราการยอมรับที่ผิดพลาดเท่ากับหรือเข้มงวดกว่าที่กำหนดไว้สำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10 มิเช่นนั้นจะต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักเพื่อปลดล็อกหน้าจอเท่านั้นเมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
• หากไม่สามารถถือว่าวิธีการตรวจสอบสิทธิ์เป็นหน้าจอล็อกที่ปลอดภัย การดำเนินการจะมีลักษณะดังนี้
  • ต้องแสดงผล false สำหรับทั้งเมธอด KeyguardManager.isKeyguardSecure() และ KeyguardManager.isDeviceSecure()
  • ต้องปิดใช้เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (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 ต้องใช้ค่านี้เพื่อติดตั้งใช้งาน API ของ wipeData() (เป็นส่วนหนึ่งของ Android Device Administration API) ที่อธิบายไว้ในส่วนที่ 3.9 การจัดการอุปกรณ์

อุปกรณ์อาจมีการล้างข้อมูลอย่างรวดเร็วซึ่งจะลบข้อมูลเชิงตรรกะ

9.13. โหมดการบูตอย่างปลอดภัย

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

เราขอแนะนำอย่างยิ่งให้ใช้โหมดการบูตอย่างปลอดภัยในการติดตั้งใช้งานอุปกรณ์ Android และปฏิบัติตามข้อกำหนดต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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