1. ข้อมูลเบื้องต้น
เอกสารนี้แจกแจงข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้อุปกรณ์ใช้งานร่วมกับ Android 8.0 ได้
การใช้ "ต้อง" "ต้องไม่" "ต้องระบุ" "จะ" "จะไม่" "ไม่ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119
ตามที่ใช้ในเอกสารนี้ "ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" คือบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 8.0 "การใช้งานอุปกรณ์" หรือ "การใช้งานคือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น
หากต้องการรับการพิจารณาว่าเข้ากันได้กับ Android 8.0 การใช้งานอุปกรณ์จะต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ รวมถึงเอกสารใดๆ ที่รวบรวมผ่านข้อมูลอ้างอิง
เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 10 เป็นแบบไม่มีเสียง กำกวม หรือไม่สมบูรณ์ ผู้ติดตั้งใช้งานอุปกรณ์มีหน้าที่ตรวจสอบว่าความเข้ากันได้กับการติดตั้งใช้งานที่มีอยู่
ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android จึงเป็นทั้งการอ้างอิงและการติดตั้งใช้งานที่ต้องการของ Android ขอแนะนำเป็นอย่างยิ่งให้ผู้ใช้ใช้อุปกรณ์เพื่อยึดถือในการติดตั้งใช้งานเป็นหลักในซอร์สโค้ด "อัปสตรีม" ที่มีให้จากโครงการโอเพนซอร์สของ Android แม้ว่าองค์ประกอบบางอย่างจะสามารถแทน��ี่โดยการติดตั้งแบบอื่นได้ แต่เราขอแนะนำเป็นอย่างยิ่งว่าอย่าทำตามแนวทางปฏิบัตินี้ เนื่องจากการผ่านการทดสอบซอฟต์แวร์จะยากขึ้นอย่างมาก ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ทางพฤติกรรมอย่างสมบูรณ์กับการใช้งาน Android มาตรฐาน ซึ่งรวมถึงและนอกเหนือจากชุดทดสอบความเข้ากันได้ สุดท้ายนี้ โปรดทราบว่าเอกสารนี้ไม่อนุญาตให้มีการแทนที่และการแก้ไขคอมโพเนนต์บางอย่างอย่างชัดเจน
ทรัพยากรหลายรายการที่เชื่อมโยงกับเอกสารนี้ได้มาจาก Android SDK โดยตรงหรือโดยอ้อม และมีฟังก์ชันการทำงานเหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ในกรณีที่คำจำกัดความความเข้ากันได้หรือชุดทดสอบความเข้ากันได้นี้ไม่สอดคล้องกับเอกสารประกอบของ SDK เอกสาร SDK จะถือว่าเชื่อถือได้ รายละเอียดทางเทคนิคใดๆ ที่ระบุไว้ในทรัพยากรที่ลิงก์ตลอดทั้งเอกสารนี้จะถือว่ารวมอยู่ในคำจำกัดความความเข้ากันได้นี้
1.1 โครงสร้างเอกสาร
1.1.1 ข้อกำหนดตามประเภทอุปกรณ์
ส่วนที่ 2 มีข้อกำหนดทั้งหมดที่ใช้กับอุปกรณ์แต่ละประเภท ส่วนย่อยของส่วนที่ 2 มีไว้สำหรับประเภทอุปกรณ์ที่เฉพาะเจาะจง
ข้อกำหนดอื่นๆ ทั้งหมดซึ่งมีผลกับการใช้งานอุปกรณ์ Android ทั้งหมดจะแสดงอยู่ในส่วนหลังจากส่วนที่ 2 ข้อกำหนดเหล่านี้เรียกว่า "ข้อกำหนดหลัก" ในเอกสารนี้
1.1.2 รหัสข้อกำหนด
มีการกำหนดรหัสข้อกำหนดสำหรับข้อกำหนด "ต้อง" แล้ว
- รหัสได้รับการกำหนดสำหรับข้อกำหนด "ต้อง" เท่านั้น
- ข้อกำหนดที่แนะนำอย่างยิ่งจะมีเครื่องหมายเป็น [SR] แต่ยังไม่มีการกำหนดบัตรประจำตัว
- รหัสประกอบด้วย : รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น C-0-1)
แต่ละรหัสจะมีคำจำกัดความดังนี้
- รหัสประเภทอุปกรณ์ (ดูเพิ่มเติมใน 2. ประเภทอุปกรณ์
- C: หลัก (ข้อกำหนดที่ใช้กับการใช้��านอุปกรณ์ Android ใดๆ ก็ตาม)
- H: อุปกรณ์ Android แบบพกพา
- T: อุปกรณ์ Android TV
- ตอบ: การติดตั้งใช้งาน Android Automotive
- แท็บ: การใช้งานแท็บเล็ต Android
- รหัสเงื่อนไข
- เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะกำหนดรหัสนี้เป็น 0
- เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนด 1 ให้กับเงื่อนไขที่ 1 และเพิ่มตัวเลขครั้งละ 1 ในส่วนเดียวกันและอุปกรณ์ประเภทเดียวกัน
- รหัสข้อกำหนด
- รหัสนี้จะเริ่มต้นจาก 1 และเพิ่มทีละ 1 ภายในส่วนเดียวกันและอยู่ในเงื่อนไขเดียวกัน
1.1.3 รหัสข้อกำหนดในส่วนที่ 2
รหัสข้อกำหนดในส่วนที่ 2 ขึ้นต้นด้วยรหัสส่วนที่เกี่ยวข้อง ตามด้วยรหัสข้อกำหนดที่อธิบายไว้ข้างต้น
- รหัสในส่วนที่ 2 ประกอบด้วยรหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)
2. ประเภทอุปกรณ์
แม้ว่าโครงการโอเพนซอร์สของ Android จะมีกลุ่มซอฟต์แวร์ที่สามารถใช้งานได้กับอุปกรณ์และรูปแบบของอุปกรณ์หลากหลายประเภท แต่ก็มีอุปกรณ์ 2-3 ประเภทที่ระบบนิเวศการเผยแพร่แอปพลิเคชันในระดับที่ค่อนข้างดีกว่า
ส่วนนี้จะอธิบายประเภทอุปกรณ์เหล่านั้น รวมถึงข้อกำหนดและคำแนะนำเพิ่มเติมที่เกี่ยวข้องกับอุปกรณ์แต่ละประเภท
การใช้งานอุปกรณ์ Android ทั้งหมดที่ไม่เข้ากับประเภทอุปกรณ์ใดๆ ที่อธิบายไว้จะต้องยังคงเป็นไปตามข้อกำหนดทั้งหมดในส่วนอื่นๆ ของคำจำกัดความความเข้ากันได้นี้
2.1 การกำหนดค่าอุปกรณ์
สำหรับความแตกต่างที่สำคัญในการกำหนดค่าฮาร์ดแวร์ตามประเภทอุปกรณ์ โปรดดูข้อกำหนดเฉพาะอุปกรณ์ดังต่อไปนี้
2.2 ข้อกำหนดสำหรับอุปกรณ์พกพา
อุปกรณ์ Android พกพาหมายถึงการใช้งานอุปกรณ์ Android ที่โดยปกติจะใช้โดยการถือไว้ในมือ เช่น เครื่องเล่น mp3, โทรศัพท์ หรือแท็บเล็ต
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น "มือถือ" หากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีแหล่งพลังงาน��ี่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- ให้หน้าจอขนาดแนวทแยงมุม 2.5 ถึง 8 นิ้ว
ข้อกำหนดเพิ่มเติมในส่วนอื่นๆ ของส่วนนี้เกี่ยวข้องกับการใช้งานอุปกรณ์ Android แบบพกพาโดยเฉพาะ
2.2.1. ฮาร์ดแวร์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.1.1.1/H-0-1] ต้องมีหน้าจอขนาดแนวทแยงมุมจริงอย่างน้อย 2.5 นิ้ว
- [7.1.1.3/H-SR] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้มีโอกาสในการเปลี่ยนขนาดการแสดงผล (ความหนาแน่นของหน้าจอ)
- [7.1.5/H-0-1] ต้องมีการรองรับโหมดความเข้ากันได้ของแอปพลิเคชันแบบเดิม ซึ่งติดตั้งใช้งานโดยโค้ดโอเพนซอร์สของ Android ต้นทาง กล่าวคือ การใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่จะเปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนลักษณะการทำงานของโหมดความเข้ากันได้
- [7.2.1/H-0-1] ต้องมีการรองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม
- [7.2.3/H-0-1] ต้องมีฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ
- [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดค้างและเหตุการณ์ปกติของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า - [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
- [7.3.1/H-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการใช้งานอุปกรณ์พกพามีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/H-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
หากการใช้งานอุปกรณ์พกพารวมถึงเครื่องวัดการหมุน จะมีการดำเนินการดังนี้
- [7.3.4/H-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
การใช้งานอุปกรณ์เคลื่อนที่ที่สามารถโทรออกและระบุค่าอื่นๆ ที่ไม่ใช่ PHONE_TYPE_NONE
ใน getPhoneType
:
- [7.3.8/H] ควรมีพร็อกซิมิตีเซ็นเซอร์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.3.12/H-SR] แนะนำให้รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 องศา
- [7.4.3/H]ควรมีการรองรับบลูทูธและบลูทูธ LE
การใช้งานอุปกรณ์พกพารวมถึงการเชื่อมต่อแบบจำกัดปริมาณอินเทอร์เน็ตมีดังนี้
- [7.4.7/H-1-1] ต้องระบุโหมดประหยัดอินเทอร์เน็ต
การใช้งานอุปกรณ์เคลื่อนที่
- [7.6.1/H-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
- [7.6.1/H-0-2] ต้องแสดงผล "true" สำหรับ
ActivityManager.isLowRamDevice()
เมื่อมีหน่วยความจำที่ใช้ได้น้อยกว่า 1 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้
หากใช้อุปกรณ์พกพาแบบ 32 บิต ให้ทำดังนี้
-
[7.6.1/H-1-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 512 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ*
- ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
-
[7.6.1/H-2-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 608 MB หากใช้ความหนาแน่นดังต่อไปนี้
- xhdpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/H-3-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/H-4-1] หน่วยความจำที่พร้อมใช้���านสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 560dpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
หากใช้งานอุปกรณ์มือถือเป็นแบบ 64 บิต ให้ทำดังนี้
-
[7.6.1/H-5-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ*
- ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
-
[7.6.1/H-6-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากใช้ความหนาแน่นดังต่อไปนี้
- xhdpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/H-7-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/H-8-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 560dpi ขึ้นไปในหน้าจอขนาดเล็ก/หน้าจอปกติ*
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่มีให้สำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรไว้ให้คอมโพเนนต์ของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.6.2/H-0-1] ต้องไม่ให้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันที่มีขนาดเล็กกว่า 1 GiB
- [7.7.1/H] ควรรวมพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
หากการใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.7.1/H-1-1] ต้องใช้ Android Open Accessory (AOA) API
การใช้งานอุปกรณ์เคลื่อนที่
- [7.8.1/H-0-1] ต้องมีไมโครโฟน
- [7.8.2/H-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
หากการใช้งานอุปกรณ์พกพารวมถึงการรองรับโหมด VR ก็จะมีคุณสมบัติดังนี้
- [7.9.1/H-1-1] ต้องประกาศฟีเจอร์
android.software.vr.mode
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.software.vr.mode
สิ่งต่อไปนี้
- [7.9.1/H-2-1] ต้องมีแอปพลิเคชันที่ใช้งาน
android.service.vr.VrListenerService
ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่านandroid.app.Activity#setVrModeEnabled
หากการใช้งานอุปกรณ์พกพามีคุณสมบัติตรงตามข้อกำหนดทั้งหมดในการประกาศแฟล็กฟีเจอร์ android.hardware.vr.high_performance
สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.9.2/-1-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.vr.high_performance
2.2.2. มัลติมีเดีย
การใช้งานอุปกรณ์พกพาต้องรองรับการเข้ารหัสเสียงต่อไปนี้
- [5.1.1/H-0-1] AMR-NB
- [5.1.1/H-0-2] AMR-WB
- [5.1.1/H-0-3] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1.1/H-0-4] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1.1/H-0-5] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
การใช้งานอุปกรณ์มือถือต้องรองรับการถอดรหัสเสียงต่อไปนี้
การใช้งานอุปกรณ์มือถือต้องรองรับการเข้ารหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
การใช้งานอุปกรณ์มือถือต้องรองรับการถอดรหัสวิดีโอต่อไปนี้
2.2.3. ซอฟต์แวร์
การใช้งานอุปกรณ์เคลื่อนที่
- [3.4.1/H-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์ - [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
- [3.8.1/H-SR] ขอแนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด��ละวิดเจ็ตในแอป
- [3.8.1/H-SR] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนสำหรับทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน ShortcutManager API
- [3.8.1/H-SR] ขอแนะนำอย่างยิ่งให้รวมแอป Launcher เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป
- [3.8.2/H-SR] ขอแนะนำอย่างยิ่งให้รองรับวิดเจ็ตแอปของบุคคลที่สาม
- [3.8.3/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สามแจ้งให้ผู้ใช้ทราบเหตุการณ์ที่สำคัญผ่านคลาส API
Notification
และNotificationManager
- [3.8.3/H-0-2] ต้องรองรับการแจ้งเตือนที่สมบูรณ์
- [3.8.3/H-0-3] ต้องรองรับการแจ้งเตือนล่วงหน้า
- [3.8.3/H-0-4] ต้องมีหน้าต่างแจ้งเตือน ทำให้ผู้ใช้สามารถควบคุมได้โดยตรง (เช่น ตอบกลับ ปิดเสียงเตือนชั่วคราว ปิด บล็อก) การแจ้งเตือนผ่านสำหรับผู้ใช้ เช่น ปุ่มการทำงานหรือแผงควบคุมตามที่ใช้ใน AOSP
- [3.8.4/H-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย
การใช้งานอุปกรณ์มือถือ Android รองรับหน้าจอล็อกจะส่งผลดังนี้
- [3.8.10/H-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9/H-1-1] ต้องใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสาร Android SDK
การใช้งานอุปกรณ์เคลื่อนที่
- [3.10/H-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/H-SR] แนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่โหลดไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
- [3.11/H-0-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคล��ี่สาม
- [3.11/H-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับ��า��าที่����้อมใช้งานในอุปกรณ์
- [3.13/H-SR] ขอแนะนำอย่างยิ่งให้รวมคอมโพเนนต์ UI ของการตั้งค่าด่วน
หากการใช้งานอุปกรณ์พกพาของ Android ประกาศการรองรับ FEATURE_BLUETOOTH
หรือ FEATURE_WIFI
ระบบจะดำเนินการดังต่อไปนี้
- [3.15/H-1-1] ต้องรองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
2.2.4 ประสิทธิภาพและศักยภาพ
- [8.1/H-0-1] เวลาในการตอบสนองเฟรมที่สม่ำเสมอ เวลาในการตอบสนองเฟรมไม่สอดคล้องกันหรือการหน่วงเวลาในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยเกินกว่า 5 เฟรมในวินาที และควรต่ำกว่า 1 เฟรมในวินาที
- [8.1/H-0-2] เวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้ การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้ได้รับประสบการณ์ในการใช้งานที่มีเวลาในการตอบสนองต่ำด้วยการเลื่อนดูรายการรายการ 10,000 รายการตามที่กำหนดโดยชุดทดสอบความเข้ากันได้ของ Android (CTS) ภายในเวลาไม่ถึง 36 วินาที
- [8.1/H-0-3] การสลับงาน เมื่อมีการเปิดตัวแอปพลิเคชันหลายรายการ การเปิดใช้แอปพลิเคชันที่ทำงานอยู่แล้วอีกครั้งหลังจากเปิดตัวไปแล้วจะใช้เวลาไม่ถึง 1 วินาที
การใช้งานอุปกรณ์เคลื่อนที่
- [8.2/H-0-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 5 MB/วินาที
- [8.2/H-0-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาที
- [8.2/H-0-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาที
- [8.2/H-0-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที
- [8.3/H-0-1] แอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze ต้องปรากฏต่อผู้ใช้ปลายทาง
- [8.3/H-0-2] อัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและ Doze ต้องไม่เบี่ยงเบนไปจากโครงการโอเพนซอร์สของ Android
การใช้งานอุปกรณ์เคลื่อนที่
- [8.4/H-0-1] ต้องระบุโปรไฟล์พลังงานต่อองค์ประกอบที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/H-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/H-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/H-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านทางคำสั่ง Shell
adb shell dumpsys batterystats
- [8.4/H] ควรระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
การใช้งานอุปกรณ์พกพารวมถึงหน้าจอหรือเอาต์พุตวิดีโอจะส่งผลดังนี้
- [8.4/H-1-1] ต้องเป็นไปตาม Intent ของ
android.intent.action.POWER_USAGE_SUMMARY
และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้
2.2.5 โมเดลการรักษาความปลอดภัย
การใช้งานอุปกรณ์เคลื่อนที่
- [9.1/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานผ่านสิทธิ์
android.permission.PACKAGE_USAGE_STATS
และกำหนดกลไกที่ผู้ใช้เข้าถึงได้เพื่ออนุญาตหรือเพิกถอนสิทธิ์เข้าถึงแอปดังกล่าวตามเจตนาของandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
2.3 ข้อกำหนดสำหรับโทรทัศน์
อุปกรณ์ทีวี Android หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสำหรับการบริโภคสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสำหรับผู้ใช้ที่อยู่ห่างออกไปประมาณ 10 ฟุต ("อินเทอร์เฟซผู้ใช้หลังเอนหลัง" หรือ "อินเทอร์เฟซผู้ใช้ 10 ฟุต")
การใช้งานอุปกรณ์ Android จัดเป็นทีวีหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีกลไกในการควบคุมอินเทอร์เฟซผู้ใช้ที่แสดงผลจากระยะไกลบนจอแสดงผลที่สามารถอยู่ห่างจากผู้ใช้ 10 ฟุต
- มีจอแสดงผลแบบฝังที่มีความยาวแนวทแยงมากกว่า 24 นิ้ว หรือใส่พอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI, DisplayPort หรือพอร์ตไร้สายสำหรับแสดงผล
ข้อกำหนดเพิ่มเติมในส่วนอื่นของส่วนนี้เกี่ยวข้องกับการใช้งานอุปกรณ์ Android TV เท่านั้น
2.3.1 ฮาร์ดแวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [7.2.2/T-0-1] ต้องรองรับ D-pad
- [7.2.3/T-0-1] ต้องมีฟังก์ชัน "หน้าแรก" และ "ย้อนกลับ"
- [7.2.3/T-0-2] ต้องส่งทั้งเหตุการณ์การกดค้างและเหตุการณ์ปกติของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า - [7.2.6.1/T-0-1] ต้องรวมการรองรับตัวควบคุมเกมและประกาศแฟล็กฟีเจอร์
android.hardware.gamepad
- [7.2.7/T] ควรมีรีโมตคอนโทรลที่ผู้ใช้สามารถเข้าถึงอินพุตการนำทางแบบไม่สัมผัสและแป้นนำทางหลัก
หากการใช้งานอุปกรณ์ทีวีมีเครื่องวัดการหมุนรวมอยู่ด้วย ให้ทำดังนี้
- [7.3.4/T-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
การติดตั้งใช้งานอุปกรณ์ทีวี
- [7.4.3/T-0-1] ต้องรองรับบลูทูธและบลูทูธ LE
- [7.6.1/T-0-1] ต้อง����พ��้����ี่���ก���บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
หากอุปกรณ์ทีวีเป็นแบบ 32 บิต
-
[7.6.1/T-1-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
หากอุปกรณ์ทีวีเป็นแบบ 64 บิต ให้ทำดังนี้
-
[7.6.1/T-2-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นท���่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่มีให้สำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรไว้ให้คอมโพเนนต์ของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์ทีวี
2.3.2 มัลติมีเดีย
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการเข้ารหัสเสียงต่อไปนี้
- [5.1/T-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/T-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/T-0-3] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการเข้ารหัสวิดีโอต่อไปนี้
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.2.2/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส H.264 ที่มีความละเอียด 720p และ 1080p
- [5.22/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 1080p ที่ 30 เฟรมต่อวินาที (FPS)
การใช้งานอุปกรณ์ทีวีต้องรองรับการถอดรหัสวิดีโอต่อไปนี้
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ทีวีเพื่อรองรับการถอดรหัสวิดีโอต่อไปนี้
- [5.3/T-SR] MPEG-2
หากการติดตั้งใช้งานอุปกรณ์ทีวีรองรับตัวถอดรหัส H.264 อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.4/T-1-1] ต้องรองรับ High Profile Level 4.2 และโปรไฟล์การถอดรหัสแบบ HD 1080p (ที่ 60 FPS)
- [5.3.4/T-1-2] ต้องถอดรหัสวิดีโอที่มีโปรไฟล์ HD ทั้ง 2 โปรไฟล์ได้ตามที่ระบุไว้ในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐาน โปรไฟล์หลัก หรือโปรไฟล์ระดับสูงระดับ 4.2
หากการใช้อุปกรณ์ทีวีรองรับตัวแปลงรหัส H.265 และโปรไฟล์การถอดรหัส HD 1080p อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [5.3.5/T-1-1] ต้องรองรับระดับโปรไฟล์หลัก 4.1 ระดับหลัก
- [5.3.5/T-SR] ขอแนะนำอย่างยิ่งให้รองรับอัตราเฟรมวิดีโอ 60 FPS สำหรับ HD 1080p
หากการใช้อุปกรณ์ทีวีรองรับตัวแปลงรหัส H.265 และโปรไฟล์การถอดรหัส UHD ให้ทำดังนี้
- [5.3.5/T-2-1] ตัวแปลงรหัสต้องรองรับโปรไฟล์หลักของระดับ Main10 ระดับ 5
หากการใช้งานอุปกรณ์ทีวีรองรับตัวแปลงรหัส VP8 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [5.3.6/T-1-1] ต้องรองรับโปรไฟล์การถอดรหัส HD 1080p60
หากการใช้งานอุปกรณ์ทีวีรองรับตัวแปลงรหัส VP8 และรองรับ 720p อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [5.3.6/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส HD 720p60
หากการใช้งานอุปกรณ์โทรทัศน์รองรับตัวแปลงรหัส VP9 และการถอดรหัสวิดีโอ UHD อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [5.3.7/T-1-1] ต้องรองรับความลึกของสี 8 บิตและควรรองรับ VP9 Profile 2 (10 บิต)
หากการใช้อุปกรณ์โทรทัศน์รองรับตัวแปลงรหัส VP9, โปรไฟล์ 1080p และการเข้ารหัสฮาร์ดแวร์ VP9 จะมีการดำเนินการต่อไปนี้
- [5.3.7/T-2-1] ต้องรองรับ 60 FPS สำหรับ 1080p
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.8/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการถอดรหัสสตรีมที่ปลอดภัยพร้อมกัน ขอแนะนำเป็นอย่างยิ่งให้ถอดรหัสแบบ 2 ไอน้ำพร้อมกันเป็นอย่างน้อย
หากอุปกรณ์เป็นอุปกรณ์ Android TV และรองรับความละเอียดระดับ 4K ระบบจะดำเนินการดังต่อไปนี้
- [5.8/T-1-1] ต้องรองรับ HDCP 2.2 สำหรับจอแสดงผลภายนอกแบบมีสายทั้งหมด
หากอุปกรณ์ทีวีไม่รองรับความละเอียดระดับ 4K ระบบจะดำเนินการต่อไปนี้
- [5.8/T-2-1] ต้องรองรับ HDCP 1.4 สำหรับจอแสดงผลภายนอกแบบมีสายทั้งหมด
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.5.3/T-0-1] ต้องมีการรองรับระดับเสียงมาสเตอร์ของระบบและการลดระดับเสียงเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตส่งผ่านเสียงที่บีบอัด (ที่ไม่มีการถอดรหัสเสียงในอุปกรณ์)
2.3.3 ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3/T-0-1] ต้องประกาศฟีเจอร์
android.software.leanback
และandroid.hardware.type.television
- [3.4.1/T-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์
หากใช้งานอุปกรณ์ Android TV รองรับหน้าจอล็อก สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.10/T-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.8.14/T-SR] ขอแนะนำอย่างยิ่งให้รองรับหลายหน้าต่างในโหมดการแสดงภาพซ้อนภาพ (PIP)
- [3.10/T-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุ��คลที่สาม
- [3.10/T-SR] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่โหลดไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
หากการใช้งานอุปกรณ์ทีวีรายงานฟีเจอร์ android.hardware.audio.output
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [3.11/T-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
- [3.11/T-1-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.12/T-0-1] ต้องรองรับเฟรมเวิร์กอินพุตทีวี
2.2.4 ประสิทธิภาพและศักยภาพ
- [8.1/T-0-1] เวลาในการตอบสนองเฟรมที่สม่ำเสมอ เวลาในการตอบสนองเฟรมไม่สอดคล้องกันหรือการหน่วงเวลาในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยเกินกว่า 5 เฟรมในวินาที และควรต่ำกว่า 1 เฟรมในวินาที
- [8.2/T-0-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 5 MB/วินาที
- [8.2/T-0-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาที
- [8.2/T-0-3] ต้องตรวจสอบประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาที
-
[8.2/T-0-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที
-
[8.3/T-0-1] ผู้ใช้ปลายทางจะต้องมองเห็นแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและ Doze
- [8.3/T-0-2] อัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและ Doze ต้องไม่เบี่ยงเบนไปจากโครงการโอเพนซอร์สของ Android
การติดตั้งใช้งานอุปกรณ์ทีวี
- [8.4/T-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/T-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/T-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/T] ควรมีการระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
- [8.4/T-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านทางคำสั่ง Shell
adb shell dumpsys batterystats
2.4 ข้อกำหนดของนาฬิกา
อุปกรณ์ Android Watch หมายถึงการใช้งานอุปกรณ์ Android ที่มีจุดประสงค์เพื่อสวมใส่บนร่างกาย หรืออาจเป็นบนข้อมือ
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น "นาฬิกา" ��ากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีหน้าจอที่มีความยาวตามเส้นทแยงมุมจริงอยู่ในช่วง 1.1-2.5 นิ้ว
- มีกลไกสำหรับสวมใส่ร่างกาย
ข้อกำหนดเพิ่มเติมในส่วนอื่นๆ ของส่วนนี้เกี่ยวข้องกับการใช้งานอุปกรณ์ Android Watch เท่านั้น
2.4.1 ฮาร์ดแวร์
ดูการติดตั้งใช้งานอุปกรณ์
-
[7.1.1.1/W-0-1] ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
-
[7.2.3/W-0-1] ต้องมีฟังก์ชัน "หน้าแรก" สำหรับผู้ใช้ และฟังก์ชัน "กลับ" ยกเว้นเมื่ออยู่ใน
UI_MODE_TYPE_WATCH
-
[7.2.4/W-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
-
[7.3.1/W-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
-
[7.4.3/W-0-1] ต้องรองรับบลูทูธ
-
[7.6.1/W-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
-
[7.6.1/W-0-2] ต้องมีหน่วยความจำอย่างน้อย 416 MB สำหรับเคอร์เนลและพื้นที่ผู้ใช้
-
[7.8.1/W-0-1] ต้องมีไมโครโฟน
-
[7.8.2/W] อาจแต่ไม่ควรมีเอาต์พุตเสียง
2.4.2 มัลติมีเดีย
ไม่มีข้อกำหนดเพิ่มเติม
2.4.3 ซอฟต์แวร์
ดูการติดตั้งใช้งานอุปกรณ์
- [3/W-0-1] ต้องประกาศฟีเจอร์
android.hardware.type.watch
- [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_Wwatch
ดูการติดตั้งใช้งานอุปกรณ์
- [3.8.4/W-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย
ดูการใช้งานอุปกรณ์ที่ประกาศแฟล็กฟีเจอร์ android.hardware.audio.output
- [3.10/W-1-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/W-SR] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่โหลดไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
หากการใช้งานอุปกรณ์นาฬิการายงานฟีเจอร์ android.hardware.audio.output ระบบจะดำเนินการต่อไปนี้
-
[3.11/W-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
-
[3.11/W-0-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
2.5 ข้อกำหนดด้านยานยนต์
การติดตั้งใช้งาน Android Automotive หมายถึง���ครื่องเล่นวิทยุของรถยนต์ที่ใช้ Android เป็นระบบปฏิบัติการสำหรับระบบและ/หรือฟังก์ชันการทำงานของระบบและ/หรือสาระบันเทิงทั้งหมด
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น Automotive หากมีการประกาศฟีเจอร์ android.hardware.type.automotive
หรือตรงตามเกณฑ์ต่อไปนี้ทั้งหมด
- ฝังเป็นส่วนหนึ่งของหรือเชื่อมต่อกับรถยนต์ยานยนต์
- ใช้หน้าจอในแถวที่นั่งคนขับเป็นจอแสดงผลหลัก
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้ใช้สำหรับการติดตั้งใช้งานอุปกรณ์ Android Automotive เท่านั้น
2.5.1 ฮาร์ดแวร์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.1.1.1/A-0-1] ต้องมีหน้าจอขนาดแนวทแยงมุมจริงอย่างน้อย 6 นิ้ว
-
[7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจออย่างน้อย 750 dp x 480 dp
-
[7.2.3/A-0-1] ต้องมีฟังก์ชัน Home และอาจจัดให้มีฟังก์ชัน "กลับ" และ "ล่าสุด"
-
[7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์การกดค้างและเหตุการณ์ปกติของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า -
[7.3.1/A-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/A-1-1] ต้องรายงานเหตุการณ์ได้สูงสุดอย่างน้อย 100 Hz
- [7.3.1/A-1-2] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ในรถของ Android
หากการใช้งานอุปกรณ์ Automotive มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
ดังนี้
- [7.3.3/A-1-1] รุ่นเทคโนโลยี GNSS ต้องเป็นปี "2017" ขึ้นไป
หากการใช้งานอุปกรณ์ยานยนต์รวมถึงเครื่องวัดการหมุน จะมีการดำเนินการดังนี้
- [7.3.4/A-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.3.11/A] ควรระบุอุปกรณ์ปัจจุบันเป็��
SENSOR_TYPE_GEAR
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.3.11.2/A-0-1] ต้องรองรับโหมดกลา��วัน/กลางคืนที่กำหนดไว้เป็น
SENSOR_TYPE_NIGHT
- [7.3.11.2/A-0-2] ค่าของแฟล็ก
SENSOR_TYPE_NIGHT
ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตเซ็นเซอร์แสงแวดล้อม -
เซ็นเซอร์แสงแวดล้อมที่อยู่ข้างใต้อาจเหมือนกับ Photometer
-
[7.3.11.3/A-0-1] ต้องรองรับสถานะการขับขี่ที่กำหนดไว้เป็น
SENSOR_TYPE_DRIVING_STATUS
โดยมีค่าเริ่มต้นเป็นDRIVE_STATUS_UNRESTRICTED
เมื่อยานพาหนะหยุดและจอดสนิท ผู้ผลิตอุปกรณ์มีหน้าที่กำหนดค่าSENSOR_TYPE_DRIVING_STATUS
ให้เป็นไปตามกฎหมายและข้อบังคับทั้งหมดที่มีผลบังคับใช้กับตลาดที่มีการจัดส่งผลิตภัณฑ์ -
[7.3.11.4/A-0-1] ต้องระบุความเร็วของยานพาหนะที่กำหนดไว้เป็น
SENSOR_TYPE_CAR_SPEED
-
[7.4.3/A-0-1] ต้องรองรับบลูทูธและควรรองรับ Bluetooth LE
- [7.4.3/A-0-2] การติดตั้งใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้
- การโทรผ่านโทรศัพท์ผ่านโปรไฟล์แฮนด์ฟรี (HFP)
- การเล่นสื่อผ่าน Audio Distribution Profile (A2DP)
- การควบคุมการเล่นสื่อบนโปรไฟล์รีโมตคอนโทรล (AVRCP)
- การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)
-
[7.4.3/A] ควรรองรับ Message Access Profile (MAP)
-
[7.4.5/A] ควรมีการสนับสนุนสำหรับการเชื่อมต่ออินเทอร์เน็ตที่ใช้เครือข่ายมือถือ
-
[7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
หากใช้อุปกรณ์ Automotive เป็นแบบ 32 บิต
-
[7.6.1/A-1-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 512 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
- ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
-
[7.6.1/A-1-2] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 608 MB หากใช้ความหนาแน่นดังต่อไปนี้
- xhdpi ขึ้นไปสำหรับหน้าจอขนาดเล็ก/ปกติ
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-1-3] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-1-4] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 560dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
หากใช้อุปกรณ์ Automotive เป็นแบบ 64 บิต
-
[7.6.1/A-2-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
- ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
-
[7.6.1/A-2-2] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากใช้ความหนาแน่นดังต่อไปนี้
- xhdpi ขึ้นไปสำหรับหน้าจอขนาดเล็ก/ปกติ
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-2-3] ��น่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-2-4] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 560dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่มีให้สำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรไว้ให้คอมโพเนนต์ของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.7.1/A] ควรมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.8.1/A-0-1] ต้องมีไมโครโฟน
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.8.2/A-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
2.5.2 มัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์ในรถยนต์ต้องรองรับการเข้ารหัสเสียงต่อไปนี้
- [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
การใช้งานอุปกรณ์ Automotive ต้องรองรับการเข้ารหัสวิดีโอต่อไปนี้
การใช้งานอุปกรณ์ในรถยนต์ต้องรองรับการถอดรหัสวิดีโอต่อไปนี้
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ในรถยนต์เพื่อรองรับการถอดรหัสวิดีโอต่อไปนี้
- [5.3/A-SR] H.265 HEVC
2.5.3 ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3/A-0-1] ต้องประกาศฟีเจอร์
android.hardware.type.automotive
- [3/A-0-2] ต้องรองรับ uiMode = UI_mode_TYPE_CAR
-
[3/A-0-3] การใช้งาน Android Automotive ต้องรองรับ API สาธารณะทั้งหมดในเนมสเปซ
android.car.*
-
[3.4.1/A-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์ -
[3.8.3/A-0-1] ต้องแสดงการแจ้งเตือนที่ใช้
Notification.CarExtender
API เมื่อแอปพลิเคชันของบุคคลที่สามขอ -
[3.8.4/A-0-1] ต้องใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
-
[3.14/A-0-1] ต้องระบุเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วนที่ 3.14
2.2.4 ประสิทธิภาพและศักยภาพ
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [8.3/A-0-1] ผู้ใช้ปลายทางจะต้องมองเห็นแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและ Doze
-
[8.3/A-0-2] อัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและ Doze ต้องไม่เบี่ยงเบนไปจากโครงการโอเพนซอร์สของ Android
-
[8.4/A-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/A-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/A-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/A] ควรมีการระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
- [8.4/A-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านคำสั่ง Shell
adb shell dumpsys batterystats
2.2.5 โมเดลการรักษาความปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์ Automotive มีผู้ใช้หลายราย ระบบจะดำเนินการต่อไปนี้
- [9.5/A-1-1] ต้องระบุบัญชีผู้มาเยือนที่อนุญาตฟังก์ชันทั้งหมดของระบบในรถโดยที่ผู้ใช้ไม่ต้องเข้าสู่ระบบ
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [9.14/A-0-1] ต้องระบุข้อความที่ปลอดภัยจากระบบย่อยของยานพาหนะที่ใช้เฟรมเวิร์ก Android เช่น การอนุญาตประเภทข้อความที่อนุญาตและแหล่งที่มาของข้อความ
- [9.14/A-0-2] ต้องเฝ้าระวังการโจมตีแบบปฏิเสธการให้บริการจากเฟรมเวิร์กของ Android หรือแอปของบุคคลที่สาม การดำเนินการนี้จะป้องกันซอฟต์แวร์ที่เป็นอันตรายที่ทำให้การจราจรคล่องตัวในเครือข่ายของรถ ซึ่งอาจนำไปสู่ระบบย่อยของยานพาหนะที่ทำงานผิดพลาด
2.6 ข้อกำหนดสำหรับแท็บเล็ต
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่โดยปกติจะใช้โดยถือไว้ในมือทั้ง 2 ข้าง ไม่ใช่ในรูปแบบของอุปกรณ์แบบฝาพับ
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็นแท็บเล็ตหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- ให้หน้าจอขนาดแนวทแยงมุม 7 ถึง 18 นิ้ว
การใช้งานอุปกรณ์แท็บเล็ตมีข้อกำหนดที่คล้ายกับการใช้งานอุปกรณ์มือถือ ข้อยกเว้นต่างๆ ระบุด้วย และ * ในส่วนนั้น และจะมีหมายเหตุไว้เพื่อใช้อ้างอิงในส่วนนี้
2.4.1 ฮาร์ดแวร์
ขนาดหน้าจอ
- [7.1.1.1/Tab-0-1] ต้องมีหน้าจอในช่วง 7-18 นิ้ว
หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ (ส่วนที่ 7.6.1)
ความหนาแน่นของหน้าจอที่แสดงสำหรับหน้าจอขนาดเล็ก/ปกติในข้อกำหนดด้านอุปกรณ์พกพาไม่สามารถใช้ได้กับแท็บเล็ต
โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7.1)
หากอุปกรณ์แท็บเล็ตมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์เหล่านี้จะมีผลดังน��้
- [7.7.1/Tab]อาจใช้ Android Open Accessory (AOA) API
โหมด Virtual Reality (ส่วนที่ 7.9.1)
ความเป็นจริงเสม��อ����ระ�������������า������ง (ส่วนที่ 7.9.2)
ข้อกำหนดเกี่ยวกับ Virtual Reality ใช้ไม่ได้กับแท็บเล็ต
3. ซอฟต์แวร์
3.1 ความเข้ากันได้กับ API ที่มีการจัดการ
สภาพแวดล้อมการดำเนินการแบบไบต์โค้ด Dalvik ที่มีการจัดการเป็นพาหนะหลักสำหรับแอปพลิเคชัน Android Android Application Programming Interface (API) คือชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อมรันไทม์ที่มีการจัดการ
-
[C-0-1] การใช้งานอุปกรณ์ต้องมีการติดตั้งใช้งานที่สมบูรณ์ รวมถึงลักษณะการทำงานตามที่บันทึกไว้ทั้งหมดของ API ที่มีการบันทึกไว้โดย Android SDK หรือ API ใดๆ ที่ตกแต่งด้วยเครื่องหมาย “@SystemApi” ในซอร์สโค้ด Android ต้นทาง
-
[C-0-2] การใช้งานอุปกรณ์ต้องรองรับ/เก็บรักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมดที่คำอธิบายประกอบ TestApi (@TestApi) ไว้
-
[C-0-3] การใช้งานอุปกรณ์ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็นของ API เบี่ยงเบนไปจากลักษณะการทำงานที่บันทึกไว้ หรือรวมสิ่งที่ไม่ดำเนินการ ยกเว้นในกรณีที่คำจำกัดความความเข้ากันได้นี้อนุญาตเป็นการเฉพาะ
-
[C-0-4] การใช้งานอุปกรณ์จะต้องคง API ไว้และทํางานตามที่เหมาะสม แม้ว่าจะละเว้นฟีเจอร์ของฮาร์ดแวร์บางอย่างที่ Android มี API ก็ตาม โปรดดูที่ส่วนที่ 7 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์น��้
3.1.1. ส่วนขยาย Android
Android มีการรองรับการขยาย API ที่มีการจัดการโดยที่ยังคงใช้เวอร์ชัน API ระดับเดิมต่อไปได้
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ Android ต้องโหลดการใช้งาน AOSP ของทั้งไลบรารีที่ใช้ร่วมกัน
ExtShared
และบริการExtServices
ที่มีเวอร์ชันสูงกว่าหรือเท่ากับเวอร์ชันขั้นต่ำที่อนุญาตต่อ API แต่ละระดับล่วงหน้า ตัวอย่างเช่น การใช้งานอุปกรณ์ Android 7.0 ที่ใช้ API ระดับ 24 จะต้องมีเวอร์ชัน 1 เป็นอย่างน้อย
3.2 ความเข้ากันได้ของ Soft API
นอกจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API แบบ "soft" ที่สำคัญเฉพาะรันไทม์เท่านั้น ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ได้ขณะคอมไพล์แอปพลิเคชัน
3.2.1. สิทธิ์
- [C-0-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องรองรับและบังคับใช้ค่าคงที่สิทธิ์ทั้งหมดตามที่บันทึกในหน้าอ้างอิงสิทธิ์ โปรดทราบว่าส่วนที่ 9 แสดงข้อกำหนดเพิ่มเติมเกี่ยวกับรูป��บบความปลอดภัยของ Android
3.2.2 พารามิเตอร์บิลด์
Android API มีค่าคงที่ในคลาส android.os.Build ที่มีวัตถุประสงค์เพื่ออธิบายอุปกรณ์ปัจจุบัน
- [C-0-1] ตารางด้านล่างระบุข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การใช้งานอุปกรณ์จะต้องเป็นไปตามข้อกำหนด ทั้งนี้เพื่อให้ค่าที่มีความหมายและสอดคล้องกันในทุกการใช้งานอุปกรณ์
พารามิเตอร์ | รายละเอียด |
---|---|
VERSION.RELEASE | เวอร์ชันของระบบ Android ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสต��ิงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน 8.0 |
VERSION.SDK | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 8.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 8.0_INT |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 8.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 8.0_INT |
เวอร์ชันที่เพิ่มขึ้น | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ต้องไม่นำค่านี้มาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางเข้าถึงได้ โดยทั่วไปแล้ว ช่องนี้มีไว้เพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") |
กระดาน | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในที่เจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือระบุเวอร์ชันที่เจาะจงของบอร์ดจ่ายไฟของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
แบรนด์ | ค่าที่แสดงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ซึ่งผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรเป็นตัวแทนของผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่จำหน่ายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
SUPPORTED_ABIS | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
SUPPORTED_32 BIT_ABIS | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
SUPPORTED_64 BIT_ABIS | ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
CPU ABI | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
CPU ABI2 | ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
อุปกรณ์ | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าฟีเจอร์ของฮาร์ดแวร์และการออกแบบเชิงอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
Fingerprint |
สตริงที่ระบุบิลด์นี้ได้โ��ยไม่ซ้ำกัน เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ต้องเป็นไปตามเทมเพลตนี้
$(BRAND)/$(ผลิตภัณฑ์)/ เ��่��
acme/myproduct/ ลายนิ้วมือต้องไม่มีอักขระช่องว่าง หากช่องอื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมีอักขระที่เป็นช่องว่าง ต้องแทนที่ช่องดังกล่าวในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต |
ฮาร์ดแวร์ | ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
ผู้จัด | สตริงที่ระบุโฮสต์แบบไม่ซ้ำที่สร้างขึ้นมาในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") |
รหัส | ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ช่องนี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกความแตกต่างระหว่างเวอร์ชันของซอฟต์แวร์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$" |
ผู้ผลิต | ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ช่องต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่มีการเปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
MODEL | ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ช่องต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่มีการเปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ผลิตภัณฑ์ | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ที่เจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับให้ผู้ใช้ปลายทางอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ซี��รียล | หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องมีพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ทุกเครื่องที่มี MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^([a-zA-Z0-9]{6,20})$” |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องม���ค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 แบบ ได้แก่ คีย์การเผยแพร่ คีย์นักพัฒนาซอฟต์แวร์ คีย์การทดสอบ |
เวลา | ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์ |
ประเภท | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android 3 รายการ ได้แก่ user, userdebug หรือ eng |
ผู้ใช้ | ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") |
แพตช์ด้านความปลอดภัย | ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องหมายความว่าเวอร์ชันดังกล่าวไม่มีช่องโหว่ต่อปัญหาต่างๆ ที่อธิบายไว้ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] โดยตรงกับสตริงที่กำหนดในกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android หรือในคำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01" |
BASE_OS | ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่เหมือนกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android โดยต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("") |
รองเท้าบู๊ต | ค่าที่ผู้ให้บริการอุปกรณ์เลือกซึ่งระบุเวอร์ชัน Bootloader ภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้��รหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$" |
getRadioVersion() | ต้อง (หรือส่งคืน) ค่าที่เลือกโดยเครื่องมือของอุปกรณ์ ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-,]+$” |
3.2.3 ความเข้ากันได้กับ Intent
3.2.3.1 จุดประสงค์ของแอปพลิเคชันหลัก
Intent ของ Android อนุญาตให้คอมโพเนนต์ของแอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์อื่นๆ ของ Android ได้ โปรเจ็กต์อัปสตรีมของ Android ประกอบด้วยรายการแอปพลิเคชันที่ถือว่าเป็นแอปพลิเคชันหลักของ Android ซึ่งใช้รูปแบบ Intent ต่างๆ เพื่อดำเนินการทั่วไป
-
[C-0-1] การใช้งานอุปกรณ์ต้องมีแอปพลิเคชัน คอมโพเนนต์บริการ หรือเครื่องจัดการเหล่านี้อย่างน้อย 1 ตัว สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยแอปพลิเคชัน Android หลักต่อไปนี้ใน AOSP
- นาฬิกาตั้งโต๊ะ
- เบราว์เซอร์
- ปฏิทิน
- รายชื่อติดต่อ
- แกลเลอรี
- ค้นหาทั่วโลก
- ปืนยิงลูกระเบิด
- เพลง
- การตั้งค่า
3.2.3.2 ความละเอียดของความตั้งใจ
- [C-0-1] เนื่องจาก Android เป็นแพลตฟอร์มที่ขยายได้ การใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามลบล้างรูปแบบ Intent แต่ละรูปแบบที่อ้างอิงในหัวข้อ 3.2.3.1 ได้ การติดตั้งใช้งานโอเพนซอร์ส Android ต้นทางอนุญาตการดำเนินการนี้โดยค่าเริ่มต้น
-
[C-0-2] ผู้ติดตั้งใช้งานของเจ้าหน้าที่ต้องไม่แนบสิทธิ์พิเศษกับการใช้รูปแบบความตั้งใจเหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามเชื่อมโยงกับและใช้ควบคุมรูปแบบเหล่านี้ ข้อห้ามนี้รวมถึงแต่ไม่จำกัดเพียงการปิดใช้อินเทอร์เฟซผู้ใช้ "เครื่องม��อเลือก" ที่ให้ผู้ใช้เลือกระหว่างแอปพลิเคชันหลายรายการที่จัดการรูปแบบ Intent เดียวกัน
-
[C-0-3] การใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้แก้ไขกิจกรรมเริ่มต้นสำหรับ Intent
-
อย่างไรก็ตาม การใช้งานอุปกรณ์อาจมีกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) เมื่อกิจกรรมเริ่มต้นมีแอตทริบิวต์ที่เจาะจงมากกว่าสำหรับ URI ข้อมูล เช่น รูปแบบตัวกรอง Intent ที่ระบุ URI ข้อมูล "http://www.android.com" จะเฉพาะเจาะจงกว่ารูปแบบ Intent หลักสำหรับ "http://" ของเบราว์เซอร์
Android ยังมีกลไกสำหรับแอปของบุคคลที่สามเพื่อประกาศลักษณะการลิงก์แอปเริ่มต้นที่เชื่อถือได้สำหรับ Intent URI ของเว็บบางประเภท เมื่อกำหนดการประกาศที่เชื่อถือได้ดังกล่าวในรูปแบบตัวกรอง Intent ของแอป การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-0-4] ต้องพยายามตรวจสอบตัวกรอง Intent ใดๆ โดยทำตามขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล ตามที่กำหนดโดยตัวจัดการแพ็กเกจในโปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-5] ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ URI ที่ผ่านการตรวจสอบความถูกต้องแล้วทั้งหมดเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI
- อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากตัวกรองดังกล่าวได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นได้ยืนยันไม่สำเร็จ หากการติดตั้งใช้งานอุปกรณ์มีลักษณะเช่นนี้ ต้องระบุการลบล้างรูปแบบ URL ที่เหมาะสมให้กับผู้ใช้ในเมนูการตั้งค่า
- ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้แก่ผู้ใช้ในการตั้งค่าดังนี้
- [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของ App Link เริ่มต้นในภาพรวมสำหรับแอปให้เป็น "เปิดเสมอ" ถามเสมอ หรือไม่เปิดได้ ซึ่งต้องใช้กับตัวกรอง Intent URI ที่เลือกทั้งหมดเท่าๆ กัน
- [C-0-7] ผู้ใช้ต้องดูรายการตัวกรอง Intent ของ URI ที่เลือกได้
- การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้ลบล้างตัวกรอง Intent ของ URI ของตัวเ��ือกบางรายการที่ได้รับการยืนยันเรียบร้อยแล้ว โดยอิงตามตัวกรองต่อความตั้งใจ
- [C-0-8] การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้สามารถดูและลบล้างตัวกรอง Intent ของ URI ตัวเลือกบางรายการได้ หากการใช้งานอุปกรณ์อนุญาตให้ตัวกรอง Intent ของ URI ที่มีตัวเลือกบางรายการทำการยืนยันได้สำเร็จ ขณะที่บางตัวกรองอาจล้มเหลวได้
3.2.3.3 เนมสเปซ Intent
- [C-0-1] การใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ใดๆ ที่เป็นไปตามรูปแบบ Intent ใหม่ในการออกอากาศ โดยใช้คำสั่ง ACTION, CATEGORY หรือสตริงคีย์อื่นๆ ในเนมสเปซของ Android หรือ com.android.
- [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ใดๆ ของ Android ที่เป็นไปตามรูปแบบ Intent ใหม่ในการออกอากาศ โดยใช้ ACTION, CATEGORY หรือสต���ิงคีย์อื่นๆ ในพื้นที่แพ็กเกจที่เป็นขององค์กรอื่น
- [C-0-3] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงหรือขยายรูปแบบความตั้งใจใดๆ ที่แอปหลักใช้ตามที่ระบุไว้ในหัวข้อ 3.2.3.1
- การใช้งานอุปกรณ์อาจรวมถึงรูปแบบความตั้งใจที่ใช้เนมสเปซอย่างชัดเจนและเห็นได้ชัดว่าเกี่ยวข้องกับองค์กรของตน ข้อห้ามนี้คล้ายกับที่ระบุสำหรับคลาสภาษา Java ในส่วนที่ 3.6
3.2.3.4 ความตั้งใจในการออกอากาศ
แอปพลิเคชันของบุคคลที่สามต้องอาศัยแพลตฟอร์มในการเผยแพร่ความตั้งใจบางอย่าง เพื่อแจ้งเตือนผู้ใช้เกี่ยวกับการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องประกาศ Intent การออกอากาศแบบสาธารณะเพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสมตามที่อธิบายไว้ในเอกสารประกอบของ SDK โปรดทราบว่าข้อกำหนดนี้ไม่ขัดแย้งกับส่วนที่ 3.5 เนื่องจากมีการอธิบายข้อจำกัดสำหรับแอปพลิเคชันในเบื้องหลังไว้ในเอกสาร SDK ด้วย
3.2.3.5 การตั้งค่าแอปเริ่มต้น
Android มีการตั้งค่าที่ช่วยให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นต่างๆ ได้อย่างง่ายดาย เช่น หน้าจอหลักหรือ SMS
การใช้งานอุปกรณ์ต้องมีเมนูการตั้งค่าที่คล้ายกันและเข้ากั��ได้กับรูปแบบตัวกรอง Intent และเมธอด API ที่อธิบายไว้ในเอกสาร SDK ตามด้านล่าง หากจะเหมาะสม
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.home_screen
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องทำตาม Intent ของ android.settings.HOME_SETTINGS จึงจะแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องระบุเมนูการตั้งค่าที่จะเรียกใช้ Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องปฏิบัติตาม Intent android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการแตะและจ่าย
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องทำตาม Intent ของ android.telecom.action.CHANGE_DEFAULT_DIALER เพื่อแสดงกล่องโต้ตอบเพื่ออนุญาตให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้น
หากการติดตั้งใช้งานอุปกรณ์รองรับ VoiceInteractionService การใช้งานจะทำสิ่งต่อไปนี้
- [C-5-1] ต้องเป็นไปตาม Intent ของ android.settings.ACTION_VOICE_INPUT_SETTINGS จึงจะแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการป้อนข้อมูลด้วยเสียงและความช่วยเหลือ
3.2.4 กิจกรรมในจอแสดงผลรอง
หากการใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติในจอแสดงผลรองได้ จะเป็นดังนี้
- [C-1-1] ต้องตั้งค่าแฟล็กฟีเจอร์
android.software.activities_on_secondary_displays
- [C-1-2] ต้องรับประกันความเข้ากันได้ของ API ที่คล้ายกับกิจกรรมที่ทำงานอยู่บนจอแสดงผลหลัก
- [C-1-3] ต้องเข้าชมกิจกรรมใหม่ในจอแสดงผลเดียวกับกิจกรรมที่เรียกใช้กิจกรรมนั้น เมื่อกิจกรรมใหม่เริ่มขึ้นโดยไม่ระบุการแสดงเป้าหมายผ่าน
ActivityOptions.setLaunchDisplayId()
API - [C-1-4] ต้องทำลายกิจกรรมทั้งหมดเมื่อนำจอแสดงผลที่มีแฟล็ก
Display.FLAG_PRIVATE
ออก - [C-1-5] ต้องปรับขนาดกิจกรรมทั้งหมดบน
VirtualDisplay
ให้เหมาะสม หากปรับขนาดจอแสดงผลเอง - อาจแสดง IME (ตัว���ก้ไขวิธีการป้อนข้อมูล ซึ่งเป็นตัวควบคุมของผู้ใช้ที่ช่วยให้ผู้ใช้ป้อนข้อความได้) บนจอแสดงผลหลักเมื่อช่องป้อนข้อความโฟกัสที่จอแสดงผลรอง
- ควรใช้โฟกัสอินพุตบนจอแสดงผลรองแยกต่างหากจากจอแสดงผลหลัก เมื่อรองรับการแตะหรือการป้อนข้อมูลด้วยแป้น
- ควรมี
android.content.res.Configuration
ที่สอดคล้องกับจอแสดงผลดังกล่าวเพื่อให้แสดง ดำเนินการได้อย่างถูกต้อง และคงความเข้ากันได้ไว้หากมีการเปิดตัวกิจกรรมในจอแสดงผลรอง
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติในจอแสดงผลรอง รวมถึงจอแสดงผลหลักและจอแสดงผลรองจะมี android.util.DisplayMetrics ที่แตกต่างกัน ดังนี้
- [C-2-1] ต้องไม่อนุญาตให้ใช้กิจกรรมที่ปรับขนาดไม่ได้ (ซึ่งมี
resizeableActivity=false
ในAndroidManifest.xml
) และแอปที่กำหนดเป้าหมายเป็น API ระดับ 23 หรือต่ำกว่าในจอแสดงผลรอง
หากการใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม Android ปกติในจอแสดงผลรองและจอแสดงผลรองจะมีแฟล็ก android.view.Display.FLAG_PRIVATE ให้ทำดังนี้
- [C-3-1] เฉพาะเจ้าของจอแสดงผล ระบบ และกิจกรรมที่อยู่บนจอแสดงผลนั้นเท่านั้นที่ต้องเปิดจอแสดงผลได้ ทุกคนจะเปิดจอแสดงผลที่มี Flag android.view.Display.FLAG_PUBLIC ได้
3.3 ความเข้ากันได้กับ API เดิม
ความเข้ากันได้ของโค้ดเนทีฟนั้นทำได้ยาก ด้วยเหตุนี้ ผู้ที่ติดตั้งใช้งานอุปกรณ์จึงทำสิ่งต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้ใช้การใช้งานไลบรารีที่ระบุไว้ด้านล่างจากโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
ไบต์โค้ด Dalvik ที่มีการจัดการจะเรียกใช้โค้ดแบบเนทีฟที่ระบุไว้ในไฟล์ .apk
ของแอปพลิเคชันเป็นไฟล์ ELF .so
ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสมได้ เนื่องจากโค้ดแบบเนทีฟต้องอาศัยเทคโนโลยีโปรเซสเซอร์ที่เกี่ยวข้องเป็นหลัก Android จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) จำนวนหนึ่ง���ว้ใน Android NDK
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเข้ากันได้กับ ABI ที่กำหนดไว้อย่างน้อย 1 รายการและใช้ความเข้ากันได้กับ Android NDK
- [C-0-2] ต้องรวมการสนับสนุนสำหรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกโค้ดแบบเนทีฟ โดยใช้ความหมายมาตรฐานของ Java Native Interface (JNI)
- [C-0-3] ต้องเข้ากันได้กับต้นทาง (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) พร้อมด้วยไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
- [C-0-4] ต้องรองรับ ABI 32 บิตที่เทียบเท��า หากมีการสนับสนุน ABI แบบ 64 บิต
- [C-0-5] ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) แบบเนทีฟที่อุปกรณ์รองรับผ่านพารามิเตอร์
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
และandroid.os.Build.SUPPORTED_64_BIT_ABIS
โดยแต่ละรายการจะคั่นด้วยคอมมาของ ABI โดยเรียงลำดับจากมากที่สุดไปน้อยที่สุด - [C-0-6] ต้องรายงานผ่านพารามิเตอร์ข้างต้น เฉพาะ ABI ที่จัดทำเอกสารและอธิบายไว้ในเอกสารประกอบเกี่ยวกับ Android NDK ABI Management เวอร์ชันล่าสุด และต้องรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)
-
[C-0-7] ต้องทำให้ไลบรารีต่อไปนี้ทั้งหมดซึ่งมี API แบบเนทีฟพร้อมใช้งานสำหรับแอปที่มีโค้ดแบบเนทีฟ
- libaaudio.so (รองรับเสียงแบบเสียงเนทีฟ)
- libandroid.so (การสนับสนุนกิจกรรมในเครื่องของ Android)
- libc (ไลบรารี C)
- libcamera2ndk.so
- libdl (ลิงก์แบบไดนามิก)
- libEGL.so (การจัดการแพลตฟอร์ม OpenGL ของระบบ)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (การบันทึกของ Android)
- libmediandk.so (รองรับ API สื่อเนทีฟ)
- libm (ห้องสมุดคณิตศาสตร์)
- libOpenMAXAL.so (การสนับสนุน OpenMAX AL 1.0.1)
- libOpenSLES.so (การสนับสนุนระบบเสียง OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (การสนับสนุนขั้นต่ำสำหรับ C++)
- libvulkan.so (วัลคาน)
- libz (การบีบอัด Zlib)
- อินเทอร์เฟซ JNI
-
[C-0-8] ต้องไม่เพิ่มหรือนำฟังก์ชันสาธารณะสำหรับไลบรารีเนทีฟที่แสดงข้างต้นออก
- [C-0-9] ต้องระบุไลบรารีเพิ่มเติมที่ไม่ใช่ AOSP ที่เปิดเผยกับแอปของบุคคลที่สามโดยตรงใน
/vendor/etc/public.libraries.txt
- [C-0-10] ต้องไม่แสดงไลบรารีแบบเนทีฟอื่นๆ ที่นำไปใช้และให้บริการใน AOSP เป็นไลบรารีระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป เนื่องจากมีการจองไว้
- [C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่กำหนดไว้ใน NDK ผ่านไลบรารี
libGLESv3.so
โปรดทราบว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.1 ได้อธิบายรายละเอียดเพิ่มเติมถึงข้อกำหนดในการติดตั้งใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างครบถ้วน - [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับสัญลักษณ์ฟังก์ชันหลักของ Vulkan 1.0 รวมถึงส่วนขยาย
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
และVK_KHR_get_physical_device_properties2
ผ่านไลบรารีlibvulkan.so
โปรดทราบว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.2 จะอธิบายรายละเอียดเกี่ยวกับข้อกำหนดในการติดตั้งใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างครบถ้วนยิ่งขึ้น - ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
โปรดทราบว่า Android NDK รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม
3.3.2 ความเข้ากันได้กับโค้ดแบบเนทีฟของ ARM 32 บิต
หากใช้อุปกรณ์เป็นอุปกรณ์ ARM 64 บิต จะมีผลดังนี้
-
[C-1-1] แม้ว่าสถาปัตยกรรม ARMv8 จะเลิกใช้งานการดำเนินการของ CPU หลายอย่าง รวมถึงการดำเนินการบางอย่างที่ใช้ในโค้ดเนทีฟที่มีอยู่แล้ว การดำเนินการที่เลิกใช้งานแล้วต่อไปนี้จะต้องใช้ได้กับโค้ด ARM เนทีฟแบบ 32 บิต ไม่ว่าจะผ่านการรองรับ CPU แบบเนทีฟหรือผ่านการจำลองซอฟต์แวร์
- วิธีการส��หรับ SWP และ SWPB
- คำสั่ง SETEND
- การดำเนินการเพื่อกีดขวาง CP15ISB, CP15DSB และ CP15DMB
หากการติดตั้งใช้งานอุปกรณ์มี ARM ABI 32 บิต สิ่งที่จะเกิดขึ้นมีดังนี้
-
[C-2-1] ต้องรวมบรรทัดต่อไปนี้ใน
/proc/cpuinfo
เมื่ออ่านโดยแอปพลิเคชัน ARM 32 บิตเพื่อให้เข้ากันได้กับแอปพลิเคชันที่สร้างขึ้นโดยใช้ Android NDK เวอร์ชันเดิม-
Features:
ตามด้วยรายการฟีเจอร์เสริมของ CPU ARMv7 ที่อุปกรณ์รองรับ -
CPU architecture:
ตามด้วยจำนวนเต็มที่อธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)
-
-
ไม่ควรเปลี่ยน
/proc/cpuinfo
เมื่ออ่านโดยแอปพลิเคชัน ARM 64 บิตหรือที่ไม่ใช่ ARM
3.4 ความเข้ากันได้กับเว็บ
3.4.1 ความเข้ากันได้กับ WebView
หากการติดตั้งใช้งานอุปกรณ์ทำให้การใช้งาน API ของ android.webkit.Webview
เสร็จสมบูรณ์ จะมีผลดังนี้
- [C-1-1] ต้องรายงาน
android.software.webview
- [C-1-2] ต้องใช้บิลด์ของโปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางใน Android 8.0 Branch สําหรับการใช้งาน API
android.webkit.WebView
-
[C-1-3] สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบต่อไปนี้
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ android.os.Build.VERSION.RELEASE
- ค่าของสตริง $(MODEL) ต้องเหมือนกับค่าของ android.os.Build.MODEL
- ค่าของสตริง $(BUILD) ต้องเหมือนกับค่าของ android.os.Build.ID
- ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
- การใช้งานอุปกรณ์อาจเว้น "อุปกรณ์เคลื่อนที่" ในสตริง User Agent
-
คอมโพเนนต์ WebView ควรมีการรองรับฟีเจอร์ HTML5 มากที่สุดเท่าที่จะเป็นไปได้ และหากรองรับฟีเจอร์ ก็ควรเป็นไปตามข้อกำหนดของ HTML5
3.4.2 ความเข้ากันได้กับเบราว์เซอร์
หากอุปกรณ์มีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บทั่วไป การใช้งานจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องรองรับ API แต่ละรายการต่อไปนี้ซึ่งเชื่อมโยงกับ HTML5
- [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ IndexedDB แทน Webstorage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันในอนาคต
- อาจจัดส่งสตริง User Agent ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
- ควรรองรับ HTML5 ในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนให้มากที่สุด (ไม่ว่าจะทำงานบนแอปพลิเคชันเบราว์เซอร์ WebKit ต้นทางหรือการแทนที่ของบุคคลที่สาม)
อย่างไรก็ตาม หากการใช้งานอุปกรณ์ไม่รวมแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน การทำงานจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับรูปแบบความตั้งใจสาธารณะตามที่อธิบายไว้ในส่วนที่ 3.2.3.1
3.5 ความเข้ากันได้ด้านพฤติกรรมของ API
ลักษณะการทำงานของ API แต่ละประเภท (แบบจัดการ ซอฟต์ เนทีฟ และเว็บ) ต้องสอดคล้องกับการติดตั้งใช้งานอัปสตรีมโปรเจ็กต์โอเพนซอร์ส Android ขอบเขตความเข้ากันได้บางประการมีดังนี้
- [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของความตั้งใจมาตรฐาน
- [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายขององค์ประกอบระบบบางประเภท (เช่น บริการ กิจกรรม ผู้ให้บริการเนื้อหา ฯล��)
- [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
- อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันในเบื้องหลัง กล่าวอย่างเจาะจงคือ สําหรับแอปในเบื้องหลัง
- [C-0-4] ลูกค้าต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
GnssMeasurement
และGnssNavigationMessage
- [C-0-5] ผู้ใช้ต้องจำกัดความถี่ในการอัปเดตที่ให้ไว้กับแอปผ่านคลาส API
LocationManager
หรือเมธอดWifiManager.startScan()
- [C-0-6] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องไม่อนุญาตให้ลงทะเบียน Broadcast Receiver เพื่อการเผยแพร่ Intent มาตรฐานของ Android แบบโดยนัยในไฟล์ Manifest ของแอป เว้นแต่ Intent การเผยแพร่จำเป็นต้องได้รับสิทธิ์
"signature"
หรือ"signatureOrSystem"
protectionLevel
หรืออยู่ในรายการการยกเว้น - [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องหยุดบริการในเบื้องหลังของแอป เช่นเดียวกับกรณีที่แอปเรียกใช้เมธอด
stopSelf()
ของบริการ ยกเว้นกรณีที่แอปอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่ผู้ใช้มองเห็นได้ - [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปดังกล่าวจะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป
- [C-0-4] ลูกค้าต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น ความเข้ากันได้ Test Suite (CTS) จะทดสอบความเข้ากันได้ของแพลตฟอร์มในส่วนประกอบสำคัญ แต่ไม่ใช่ทั้งหมด ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ด้านพฤติกรรมกับโครงการโอเพนซอร์ส Android ด้วยเหตุนี้ ผู้ติดตั้งอุปกรณ์จึงควรใช้ซอร์สโค้ดที่มีให้ผ่านทางโครงการโอเพนซอร์ส Android หากทำได้ แทนการนำส่วนต่างๆ ที่สำคัญของระบบมาใช้ใหม่
3.6 เนมสเปซ API
Android เป็นไปตามแบบแผนเนมสเปซของแพ็กเกจและคลาสที่กำหนดโดยภาษาในการเขียนโปรแกรม Java ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่ทำการแก้ไขที่ไม่ได้รับอนุญาต (ดูด้านล่าง) กับเนมสเปซแพ็กเกจเหล่านี้เพื่อให้เข้ากันได้กับแอปพลิเคชันของบุคคลที่สาม
-
java.*
-
javax.*
-
sun.*
-
android.*
-
com.android.*
กล่าวคือ
- [C-0-1] ต้องไม่แก้ไข API ที่เปิดเผยต่อสาธารณะบนแพลตฟอร์ม Android โดยการเปลี่ยนวิธีการหรือลายเซ็นของคลาส หรือโดยการนำชั้นเรียนหรือฟิลด์คลาสออก
- [C-0-2] ต้องไม่เพิ่มองค์ประกอบที่เปิดเผยต่อสาธารณะ (เช่น คลาสหรืออินเทอร์เฟซ หรือฟิลด์หรือเมธอดลงในคลาสหรืออินเทอร์เฟซที่มีอยู่) หรือ API การทดสอบหรือระบบให้กับ API ในเนมสเปซข้างต้น "องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือโครงสร้างที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง
ผู้ใช้อุปกรณ์อาจแก้ไขการติดตั้งใช้งานที่สำคัญของ API แต่การแก้ไขดังกล่าวมีดังนี้
- [C-0-3] ต้องไม่ส่งผลกระทบต่อลักษณะการทำงานที่ระบุไว้และลายเซ็นภาษา Java ของ API ที่เปิดเผยต่อสาธารณะ
- [C-0-4] ต้องไม่โฆษณาหรือเปิดเผยต่อนักพัฒนาซอฟต์แวร์
อย่างไรก็ตาม ผู้ใช้อุปกรณ์อาจเพิ่ม API ที่กำหนดเองนอกเนมสเปซ Android มาตรฐานได้ แต่เพิ่ม API ที่กำหนดเองได้โดยทำดังนี้
- [C-0-5] ต้องไม่อยู่ในเนมสเปซที่เป็นขององค์กรอื่นหรืออ้างอิงถึงองค์กรอื่น ตัวอย่างเช่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่ม API ใน
com.google.*
หรือเนมสเปซที่คล้ายกัน: มีเพียง Google เท่านั้นที่ทำเช่นนั้นได้ ในทำนองเดียวกัน Google ต้องไม่เพิ่ม API ลงในเนมสเปซของบริษัทอื่นๆ - [C-0-6] ต้องมีแพ็กเกจในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้เฉพาะแอปที่ใช้งานอย่างชัดแจ้ง (ผ่านกลไก <uses-library>) ได้รับผลกระทบจากการใช้งาน��น่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว
หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซของแพ็กเกจรายการใดรายการหนึ่งข้างต้น (เช่น โดยการเพิ่มฟังก์ชันใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือเพิ่ม API ใหม่) ผู้ติดตั้งใช้งานควรไปที่ source.android.com และเริ่มขั้นตอนการมีส่วนร่วมในการเปลี่ยนแปลงและโค้ดตามข้อมูลในเว็บไซต์นั้น
โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับแบบแผนมาตรฐานสำหรับการตั้งชื่อ API ในภาษาโปรแกรม Java ส่วนนี้เพียงแต่มีเป้าหมายเพื่อเน้นย้ำข้อกำหนดดังกล่าวและทำให้ข้อกำหนดต่างๆ เชื่อมโยงผ่านการรวมไว้ในคำจำกัดความความเข้ากันได้นี้
3.7 ความเข้ากันได้ของรันไทม์
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) แบบเต็ม และข้อมูลจำเพาะและความหมายของไบต์โค้ด Dalvik
-
[C-0-2] ต้องกำหนดค่ารันไทม์ของ Dalvik เพื่อจัดสรรหน่วยความจำให้สอดคล้องกับแพลตฟอร์ม Android ต้นทางและตามที่ระบุไว้ในตารางต่อไปนี้ (โปรดดูส่วนที่ 7.1.1 สำหรับคำจำกัดความของขนาดหน้าจอและความหนาแน่นของหน้าจอ)
-
ควรใช้ Android RunTime (ART) การติดตั้งใช้งานอัปสตรีมอ้างอิงของ Dalvik Executable Format และระบบการจัดการแพ็กเกจของการใช้ข้อมูลอ้างอิง
-
ควรเรียกใช้การทดสอบ Fuzz ภายใต้โหมดของการดำเนินการและสถาปัตยกรรมเป้าหมายที่หลากหลายเพื่อรักษาความเสถียรของรันไทม์ โปรดดู JFuzz และ DexFuzz ในเว็บไซต์โครงการโอเพนซอร์ส Android
โปรดทราบว่าค่าหน่วยความจำที่ระบุไว้ด้านล่างถือว่าเป็นค่าขั้นต่ำ และการใช้งานอุปกรณ์อาจจัดสรรหน่วยความจำต่อแอปพลิเคชันมากขึ้นได้
รูปแบบหน้าจอ | ความหนาแน่นของหน้าจอ | หน่วยความจำแอปพลิเคชันขั้นต่ำ |
---|---|---|
นาฬิกาข้อมือ Android | 120 dpi (ldpi) | 32MB |
160 dpi (mdpi) | ||
213 dpi (tvdpi) | ||
240 dpi (hdpi) | 36MB | |
280 dpi (280dpi) | ||
320 dpi (Xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
เล็ก/ปกติ | 120 dpi (ldpi) | 32MB |
160 dpi (mdpi) | ||
213 dpi (tvdpi) | 48MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (Xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
ใหญ่ | 120 dpi (ldpi) | 32MB |
160 dpi (mdpi) | 48MB | |
213 dpi (tvdpi) | 80MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (Xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
160 dpi (mdpi) | 80MB | |
213 dpi (tvdpi) | 96MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (Xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8 ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.8.1 Launcher (หน้าจอหลัก)
Android มีแอปพลิเคชัน Launcher (หน้าจอหลัก) และการสนับสนุนแอปพลิเคชันของบุคคลที่สามเพื่อแทนที่ Launcher ของอุปกรณ์ (หน้าจอหลัก)
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันของบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์ได้ การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องประกาศฟีเจอร์ของแพลตฟอร์ม
android.software.home_screen
- [C-1-2] ต้องแสดงผลออบเจ็กต์
AdaptiveIconDrawable
เมื่อแอปพลิเคชันของบุคคลที่สามใช้แท็ก<adaptive-icon>
เพื่อระบุไอคอน และจะเรียกเมธอดPackageManager
เพื่อเรียกไอคอน
หากอุปกรณ์มี Launcher เริ่มต้นที่รองรับการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงาน
true
สำหรับShortcutManager.isRequestPinShortcutSupported()
- [C-2-2] ต้องมีสิทธิ์การเข้าถึงของผู้ใช้ในการถามผู้ใช้ก่อนเพิ่มทางลัดที่ขอโดยแอป��่านเมธอด
ShortcutManager.requestPinShortcut()
API
ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รองรับการปักหมุดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องรายงาน
false
สำหรับShortcutManager.isRequestPinShortcutSupported()
และAppWidgetManager.html#isRequestPinAppWidgetSupported()
หากการใช้อุปกรณ์ใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนไปยังทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน ทางลัดผู้จัดการ API ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องรองรับฟีเจอร์ทางลัดทั้งหมดที่บันทึกไว้ (เช่น ทางลัดแบบคงที่และแบบไดนามิก ทางลัดการปักหมุด) และใช้ API ของคลาส API
ShortcutManager
อย่างเต็มรูปแบบ
หากการใช้งานอุปกรณ์มีแอป Launcher เริ่มต้นซึ่งแสดงป้ายสำหรับไอคอนแอปต่างๆ อุปกรณ์จะมีลักษณะดังนี้
- [C-5-1] ต้องเป็นไปตามเมธอด API ของ
NotificationChannel.setShowBadge()
กล่าวคือ แสดงความสามารถในการมองเห็นที่เชื่อมโยงกับไอคอนแอปหากกำหนดค่าไว้เป็นtrue
และไม่แสดงรูปแบบการติดป้ายไอคอนแอปเมื่อช่องทางการแจ้งเตือนทั้งหมดของแอปกำหนดค่าเป็นfalse
- อาจลบล้างป้ายไอคอนแอปด้วยรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์เมื่อแอปพลิเคชันของบุคคลที่สามระบุการรองรับรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์ผ่านการใช้ API ที่เป็นกรรมสิทธิ์ แต่ควรใช้ทรัพยากรและค่าที่ให้ไว้ผ่าน API ป้ายการแจ้งเตือนที่อธิบายไว้ใน SDK เช่น
Notification.Builder.setNumber()
และNotification.Builder.setBadgeIconType()
API
3.8.2 วิดเจ็ต
Android รองรับวิดเจ็ตแอปของบุคคลที่สามโดยการกำหนดประเภทคอมโพเนนต์และ API และวงจรการใช้งานที่เกี่ยวข้องที่อนุญาตให้แอปพลิเคชันแสดง "AppWidget" แก่ผู้ใช้ปลายทาง
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สาม วิดเจ็ตจะดำเนินการดังนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม android.software.app_widgets
- [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและแสดงความสามารถของอินเทอร์เฟซผู้ใช้ในการเพิ่ม ก��หนดค่า ดู และนำ AppWidgets ออกภายใน Launcher โดยตรง
- [C-1-3] ต้องแสดงภาพวิดเจ็ตขนาด 4 x 4 ในขนาดตารางกริดมาตรฐานได้ ดูรายละเอียดได้ที่หลักเกณฑ์การออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK
- อาจสนับสนุนวิดเจ็ตของแอปพลิเคชันบนหน้าจอล็อก
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สามและการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงาน
true
สำหรับAppWidgetManager.html.isRequestPinAppWidgetSupported()
- [C-2-2] ต้องมีสิทธิ์การเข้าถึงของผู้ใช้ในการถามผู้ใช้ก่อนเพิ่มทางลัดที่ขอโดยแอปผ่านเมธอด
AppWidgetManager.requestPinAppWidget()
API
3.8.3 การแจ้งเตือน
Android มี API ของ Notification
และ NotificationManager
ที่ช่วยให้นักพัฒนาแอปของบุคคลที่สามสามารถแจ้งผู้ใช้เกี่ยวกับกิจกรรมสำคัญและดึงดูดความสนใจของผู้ใช้โดยใช้ส่วนประกอบของฮาร์ดแวร์ (เช่น เสียง การสั่นสะเทือนและแสง) รวมถึงฟีเจอร์ของซอฟต์แวร์ (เช่น หน้าต่างแจ้งเตือน แถบระบบ) ของอุปกรณ์
3.8.3.1 การนำเสนอการแจ้งเตือน
หากการนำอุปกรณ์ไปใช้งานอนุญาตให้แอปของบุคคลที่สามแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์ที่น่าจดจำ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับการแจ้งเตือนที่ใช้ฟีเจอร์ของฮาร์ดแวร์ตามที่อธิบายไว้ในเอกสารประกอบของ SDK และในขอบเขตที่เป็นไปได้สำหรับฮาร์ดแวร์การติดตั้งใช้งานอุปกรณ์ ตัวอย่างเช่น ถ้าการใช้งานอุปกรณ์มีการสั่นเตือน อุปกรณ์นั้นต้องใช้ API การสั่นอย่างถูกต้อง หากการใช้งานอุปกรณ์ขาดฮาร์ดแวร์ ต้องติดตั้งใช้งาน API ที่เกี่ยวข้องเป็นแบบไม่ต้องดำเนินการ ดูรายละเอียดการทำงานนี้เพิ่มเติมในส่วนที่ 7
- [C-1-2] ต้องแสดงทรัพยากร (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ทั้งหมดที่มีให้ใน API หรือในคู่มือรูปแบบไอคอนของแถบสถานะ/ระบบอย่างถูกต้อง แม้ว่าอาจจะให้ประสบการณ์ทางเลือกสำหรับผู้ใช้สำหรับการแจ้งเตือนนอกเหนือจากที่ได้มาจากการใช้งานโอเพนซอร์สของ Android อ้างอิง
- [C-1-3] ต้องยึดตามและดำเนินการตามลักษณะการทำงานที่อธิบายไว้สำหรับ API อย่างเหมาะสมในการอัปเดต นำออก และรับการแจ้งเตือนของกลุ่ม
- [C-1-4] ต้องระบุลักษณะการทำงานทั้งหมดของ NotificationChannel API ที่บันทึกไว้ใน SDK
- [C-1-5] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการบล็อกและแก้ไขการแจ้งเตือนของแอปบุคคลที่สามตามช่องทางและระดับแพ็กเกจแอปแต่ละช่อง
- [C-1-6] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการแสดงช่องทางการแจ้งเตือนที่ลบไปแล้ว
- ควรรองรับการแจ้งเตือนที่สมบูรณ์
- ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
- ผู้ใช้ควรมีกำลังทรัพย์ในการปิดการแจ้งเตือนชั่วคราว
- อาจจัดการได้เฉพาะระดับการเข้าถึงและช่วงเวลาที่แอปของบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์ที่น่าจดจำ เพื่อลดปัญหาด้านความปลอดภัย เช่น การรบกวนผู้ขับขี่
หากอุปกรณ์รองรับการแจ้งเตือนที่สมบูรณ์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้ทรัพยากรตามที่ระบุไว้ผ่านคลาส API
Notification.Style
และคลาสย่อยสำหรับองค์ประกอบทรัพยากรที่แสดงอยู่ - ควรนำเสนอองค์ประกอบทรัพยากรแต่ละรายการ (เช่น ไอคอน ชื่อ และข้อความสรุป) ที่กำหนดไว้ในคลาส API
Notification.Style
และคลาสย่อย
หากการใช้งานอุปกรณ์รองรับการแจ้งเตือนล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้มุมมองการแจ้งเตือนล่วงหน้าและทรัพยากรตามที่อธิบายไว้ในคลาส API ของ
Notification.Builder
เมื่อมีการแสดงการแจ้งเตือนล่วงหน้า
3.8.3.2 บริการฟังการแจ้งเตือน
Android มี API ของ NotificationListenerService
ที่อนุญาตให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง) เพื่อรับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงทีสำหรับบริการ Listener ที่ติดตั้งและเปิดใช้งานดังกล่าวทั้งหมด รวมถึงข้อมูลเมตาทั้งหมดที่แนบกับออบเจ็กต์การแจ้งเตือน
- [C-0-2] ต้องเป็นไปตามการเรียกใช้ API
snoozeNotification()
และปิดการแจ้งเตือนและทำการติดต่อกลับหลังจากระยะเวลาเลื่อนการแจ้งเตือนซึ่งกำหนดไว้ในการเรียก API
หากการติดตั้งอุปกรณ์ทำให้ผู้ใช้สามารถปิดการแจ้งเตือนชั่วคราวได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องแสดงสถานะการแจ้งเตือนเลื่อนการแจ้งเตือนอย่างถูกต้องผ่าน API มาตรฐาน เช่น
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] ต้องทำให้ผู้ใช้รายนี้มีสิทธิ์เข้าถึงเพื่อปิดการแจ้งเตือนชั่วคราวจากแอปของบุคคลที่สามแต่ละแอปที่ติดตั้ง ยกเว้นว่ามาจากบริการที่ทำงานอยู่เบื้องหน้า/ถาวร
3.8.3.3 DND (ห้ามรบกวน)
หากอุปกรณ์รองรับฟีเจอร์ DND ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อเจตจำนง ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS ซึ่งสำหรับการนำไปใช้กับ UI_MODE_TYPE_NORMAL จะต้องเป็นกิจกรรมที่ผู้ใช้สามารถให้หรือปฏิเสธการเข้าถึงแอปในการกำหนดค่านโยบาย DND
- [C-1-2] เมื่อการใช้อุปกรณ์ระบุวิธีการให้ผู้ใช้ให้สิทธิ์หรือปฏิเสธแอปของบุคคลที่สามในการเข้าถึงการกำหนดค่านโยบาย DND ให้แสดงกฎ DND อัตโนมัติที่สร้างโดยแอปพลิเคชันพร้อมกับกฎที่ผู้ใช้สร้างขึ้นและที่กำหนดไว้ล่วงหน้า
- [C-1-3] ต้องปฏิบัติตามค่า
suppressedVisualEffects
ที่ส่งผ่านNotificationManager.Policy
และหากแอปตั้งค่าแฟล็ก SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON ควรแจ้งให้ผู้ใช้ทราบว่าเอฟเฟกต์ภาพ��ม่แสดงในเมนูการตั้งค่า DND
3.8.4 ค้นหา
Android มี API ที่เปิดโอกาสให้นักพัฒนาซอฟต์แวร์รวมการค้นหาไว้ในแอปพลิเคชันของตนและเปิดเผยข้อมูลของแอปพลิเคชันในการค้นหาระบบทั่วโลก กล่าวโดยทั่วไปคือ ฟังก์ชันการทำงานนี้ประกอบด้วยอินเทอร์เฟซผู้ใช้แบบทั้งระบบแบบเดียวที่ให้ผู้ใช้สามารถป้อนคำค้นหา แสดงคำแนะนำขณะที่ผู้ใช้พิมพ์ และแสดงผลลัพธ์ได้ Android API ช่วยให้นักพัฒนาแอปนำอินเทอร์เฟซนี้กลับมาใช้ใหม่เพื่อให้บริการการค้นหาภายในแอปของตนเองและช่วยให้นักพัฒนาแอปแสดงผลการค้นหาไปยังอินเทอร์เฟซผู้ใช้ทั่วไปของการค้นหาทั่วโลกได้
- การใช้งานอุปกรณ์ Android ควรมีการค้นหาส่วนกลาง อินเทอร์เฟซผู้ใช้การค้นหาแบบใช้ร่วมกันการค้นหาทั้งระบบที่สามารถให้คำแนะนำแบบเรียลไทม์เพื่อตอบสนองต่อข้อมูลจากผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์ใช้อินเทอร์เฟซการค้นหาส่ว��กลาง
- [C-1-1] ต้องใช้ API ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามเพิ่มคำแนะนำในช่องค้นหาเมื่อทำงานในโหมดการค้นหาส่วนกลาง
หากไม่ได้ติดตั้งแอปพลิเคชันของบุคคลที่สามที่ใช้การค้นหาส่วนกลาง
- ลักษณะการทำงานเริ่มต้นควรเป็น แสดงผลการค้นหาและคำแนะนำของเครื่องมือค้นหาเว็บ
Android ยังมี Assist API เพื่อให้แอปพลิเคชันเลือกได้ว่าจะแชร์ข้อมูลบริบทปัจจุบันกับ Assistant ในอุปกรณ์มากน้อยแค่ไหน
หากการติดตั้งใช้งานอุปกรณ์รองรับการดำเนินการสนับสนุน การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องระบุอย่างชัดเจนต่อผู้ใช้ปลายทางเมื่อมีการแชร์บริบท โดยทำอย่างใดอย่างหนึ่งต่อไปนี้
- ทุกครั้งที่แอปผู้ช่วยเข้าถึงบริบท ระบบจะแสดงไฟสีขาวรอบขอบหน้าจอที่ด้านหรือเกินระยะเวลาและความสว่างของการดำเนินโครงการโอเพนซอร์ส Android
- สำหรับแอปผู้ช่วยที่ติดตั้งไว้ล่วงหน้า ใ��้ผู้ใช้มีการนำทางน้อยกว่า 2 ด้านในการป้อนข้อมูลด้วยเสียงเริ่มต้นและเมนูการตั้งค่าแอปผู้ช่วย และจะแชร์บริบทเฉพาะเมื่อผู้ใช้เรียกใช้แอปผู้ช่วยอย่างชัดเจนผ่านการป้อนข้อมูลด้วยคำสั่งให้ดำเนินการหรือการป้อนข้อมูลแป้นการนำทางช่วยเหลือเท่านั้น
- [C-2-2] การโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้
VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
- [C-SR] แนะนำอย่างยิ่งให้ใช้การกดแป้น
HOME
ค้างไว้เป็นการโต้ตอบที่กำหนดนี้
3.8.5 การแจ้งเตือนและขนมปังปิ้ง
แอปพลิเคชันสามารถใช้ Toast
API เพื่อแสดงสตริงที่ไม่ใช่โมดัลสั้นๆ แก่ผู้ใช้ปลายทางซึ่งจะหายไปหลังจากช่วงเวลาสั้นๆ และใช้ API ประเภทหน้าต่าง TYPE_APPLICATION_OVERLAY
เพื่อแสดงหน้าต่างการแจ้งเตือนเป็นหน้าต่างวางซ้อนเหนือแอปอื่นๆ
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการบล็อกแอปไม่ให้แสดงหน้าต่างการแจ้งเตือนที่ใช้
TYPE_APPLICATION_OVERLAY
การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการควบคุมในหน้าต่างแจ้งเตือน -
[C-1-2] ต้องปฏิบัติตาม Toast API และแสดง Toasts จากแอปพลิเคชันแก่ผู้ใช้ปลายทางในลักษณะที่เห็นได้ชัดเจน
3.8.6 ธีม
Android มี "ธีม" เป็นกลไกสำหรับแอปพลิเคชันในการนำรูปแบบไปใช้ในกิจกรรมหรือแอปพลิเคชันทั้งหมด
Android มีกลุ่มธีม "Holo" และ "Material" เป็นชุดรูปแบบที่กำหนดเพื่อให้นักพัฒนาแอปใช้หากต้องการให้รูปลักษณ์ของธีม Holo ตามที่ Android SDK กำหนด
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แอปพลิเคชันเห็น
- [C-1-2] ต้องรองรับกลุ่มธีม "Material" และต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Material หรือเนื้อหาที่แสดงในแอปพลิเคชัน
Android ยังมีกลุ่มธีม "ค่าเริ่มต้นของอุปกรณ์" เป็นชุดรูปแบบที่นักพัฒนาแอปกำหนดไว้เพื่อให้นักพัฒนาแอปใช้หากต้องการให้เข้ากับรูปลักษณ์ของธีมของอุปกรณ์ตามที่ผู้ให้บริการอุปกรณ์เป็นผู้กำหนด
- การใช้งานอุปกรณ์อาจแก้ไขแอตทริบิวต์ธีมเริ่มต้นของอุปกรณ์ที่แอปพลิเคชันต่างๆ เห็น
Android รองรับธีมของเวอร์ชันที่มีแถบระบบโปร่งแสงซึ่งช่วยให้นักพัฒนาแอปพลิเคชันใส่เนื้อหาแอปลงในพื้นที่ด้านหลังสถานะและแถบนำทางได้ เพื่อให้นักพัฒนาซอฟต์แวร์ได้รับประสบการณ์การใช้งานที่สอดคล้องกันในการกำหนดค่านี้ สิ่งสำคัญคือสไตล์ไอคอนแถบสถานะจะต้องคงเดิมในการใช้งานอุปกรณ์ต่างๆ
หากการใช้งานอุปกรณ์มีแถบสถานะของระบบ ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องใช้สีขาวสำหรับไอคอนสถานะระบบ (เช่น ความแรงของสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบออกให้ ยกเว้นกรณีที่ไอคอนแสดงสถานะที่เป็นปัญหาหรือแอปขอแถบสถานะแบบสว่างโดยใช้แฟล็ก SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
- [C-2-2] การใช้งานอุปกรณ์ Android ต้องเปลี่ยนสีของไอคอนสถานะของระบบเป็นสีดำ (ดูรายละเอียดได้ที่ R.style) เมื่อแอปขอแถบสถานะแบบสว่าง
3.8.7 วอลเปเปอร์ภาพเคลื่อนไหว
Android กำหนดประเภทของคอมโพเนนต์และ API และวงจรที่เกี่ยวข้องซึ่งอนุญาตให้แอปพลิเคชันแสดง "วอลเปเปอร์เคลื่อนไหว" อย่างน้อย 1 รายการแก่ผู้ใช้ปลายทาง วอลเปเปอร์เคลื่อนไหวเป็นภาพเคลื่อนไหว รูปแบบ หรือรูปภาพที่คล้ายกันซึ่งมีความสามารถในการป้อนข้อมูลที่จำกัดซึ่งแสดงเป็นวอลเปเปอร์ โดยอยู่หลังแอปพลิเคชันอื่นๆ
ฮาร์ดแวร์จะถือว่าสามารถเรียกใช้วอลเปเปอร์เคลื่อนไหวได้อย่างน่าเชื่อถือหากเรียกใช้วอลเปเปอร์เคลื่อนไหวทั้งหมดได้โดยไม่มีข้อจำกัดฟังก์ชันการทำงานในอัตราเฟรมที่เ��มาะสมและไม่ส่งผลกระทบต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดในฮาร์ดแวร์ทำให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้ CPU หรือพลังงานแบตเตอรี่มากเกินไป หรือทำงานในอัตราเฟรมที่ต่ำเกินกว่าจะยอมรับได้ จะถือว่าฮาร์ดแวร์นั้นไม่สามารถใช้งานวอลเปเปอร์เคลื่อนไหวได้ ตัวอย่างเช่น วอลเปเปอร์เคลื่อนไหวบางรายการอาจใช้บริบท OpenGL 2.0 หรือ 3.x ในการแสดงผลเนื้อหา วอลเปเปอร์เคลื่อนไหวจะไม่ทำงานอย่างเสถียรบนฮาร์ดแวร์ที่ไม่รองรับบริบท OpenGL หลายรายการ เนื่องจากการใช้วอลเปเปอร์เคลื่อนไหวของบริบท OpenGL อาจขัดแย้งกับแอปพลิเคชันอื่นที่ใช้บริบท OpenGL เช่นกัน
- การติดตั้งใช้งานอุปกรณ์ที่เรียกใช้วอลเปเปอร์เคลื่อนไหวได้อย่างน่าเชื่อถือตามที่อธิบายไว้ข้างต้น ควรใช้วอลเปเปอร์เคลื่อนไหว
หากอุปกรณ์ที่ใช้วอลเปเปอร์เคลื่อนไหว จะมีการดำเนินการดังนี้
- [C-1-1] ต้องรายงานแฟล็กฟีเจอร์แพลตฟอร์ม android.software.live_wallpaper
3.8.8 การสลับกิจกรรม
ซอร์สโค้ดอัปสตรีมของ Android ประกอบด้วยหน้าจอภาพรวม ซึ่งเป็นอินเทอร์เฟซผู้ใช้ระดับระบบสำหรับการสลับงานและแสดงกิจกรรมและงานที่เข้าถึงล่าสุดโดยใช้ภาพขนาดย่อของสถานะกราฟิกของแอปพลิเคชันในขณะที่ผู้ใช้ออกจากแอปพลิเคชันครั้งสุดท้าย
การใช้งานอุปกรณ์ซึ่งรวมถึงคีย์การนำทางฟังก์ชันล่าสุดตามที่อธิบายไว้��นส่วนที่ 7.2.3 อาจปรับเปลี่ยนอินเทอร์เฟซได้
หากการติดตั้งใช้งานอุปกรณ์ซึ่งรวมถึงคีย์การนําทางของฟังก์ชันล่าสุดตามที่อธิบายไว้ในส่วนที่ 7.2.3 ส่งผลให้อินเทอร์เฟซเปลี่ยนไป
- [C-1-1] ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 20 รายการ
- ควรแสดงชื่อกิจกรรม 4 รายการต่อครั้งเป็นอย่างน้อย
- [C-1-2] ต้องใช้ลักษณะการตรึงหน้าจอ และให้เมนูการตั้งค่าแก่ผู้ใช้เพื่อสลับฟีเจอร์นี้
- ควรแสดงสีไฮไลต์ ไอคอน และชื่อหน้าจอในช่วงล่าสุด
- ควรแสดงราคาปิด ("x") แต่อาจล่าช้าจนกว่าผู้ใช้จะโต��ตอบกับหน้าจอ
- ควรใช้ทางลัดเพื่อสลับไปยังกิจกรรมก่อนหน้าได้อย่างง่ายดาย
- ควรทริกเกอร์การทำงานการสลับอย่างรวดเร็วระหว่างแอปที่ใช้ล่าสุด 2 แอป เมื่อแตะปุ่มฟังก์ชันล่าสุด 2 ครั้ง
- ควรเรียกใช้โหมดหลายหน้าต่างแยกหน้าจอ (หากรองรับ) เมื่อกดแป้นฟังก์ชันล่าสุดค้างไว้
-
อาจแสดงรายการล่าสุดที่เชื่อมโยงเป็นกลุ่มที่ย้ายไปด้วยกัน
-
[C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์โดยใช้อินเทอร์เฟซผู้ใช้ Android ต้นทาง (หรืออินเทอร์เฟซที่ใช้ภาพขนาดย่อที่คล้ายกัน) สำหรับหน้าจอภาพรวม
3.8.9 การจัดการอินพุต
Android มีการสนับสนุนสำหรับการจัดการอินพุต และการรองรับสำหรับตัวแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ดังกล่าวได้ การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และรองรับ IME API ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
- [C-1-2] ต้องระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกำหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สามเพื่อตอบสนองต่อความตั้งใจ android.settings.INPUT_METHOD_SETTINGS
หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.software.autofill
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้ API ของ
AutofillService
และAutofillManager
อย่างสมบูรณ์และปฏิบัติตาม Intent ของandroid.settings.REQUEST_SET_AUTOFILL_SERVICE
เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นเพื่อเปิดใช้และปิดใช้การป้อนข้อความอัตโนมัติ รวมถึงเปลี่ยนบริการป้อนข้อความอัตโนมัติเริ่มต้นสำหรับผู้ใช้
3.8.10 การควบคุมสื่อสำหรับหน้าจอล็อก
API ไคลเอ็นต์รีโมตคอนโทรลเลิกใช้งานจาก Android 5.0 แล้วไปสนับสนุนเทมเพลตการแจ้งเตือนสื่อที่ช่วยให้แอปพลิเคชันสื่อสามารถผสานรวมเข้ากับตัวควบคุมการเล่นที่แสดงบนหน้าจอล็อก
3.8.11 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)
Android รองรับภาพพักหน้าจอแบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า Dreams โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันเมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่บนแท่นชาร์จ อุปกรณ์ Android Watch อาจใช้ภาพพักหน้าจอ แต่การใช้งานอุปกรณ์ประเภทอื่นๆ ควรมีการรองรับโปรแกรมรักษาหน้าจอและมีตัวเลือกการตั้งค่าเพื่อให้ผู้ใช้กำหนดค่าโปรแกรมรักษาหน้าจอตามความตั้งใจของ android.settings.DREAM_SETTINGS
3.8.12 ตำแหน่ง
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ฮาร์ดแวร์ (เช่น GPS) ที่สามารถระบุพิกัดของตำแหน่งได้
- [C-1-1] โหมดตำแหน่งต้องแสดงในเมนูตำแหน่งภายในการตั้งค่า
3.8.13 Unicode และแบบอักษร
Android รองรับอักขระอีโมจิที่กำหนดไว้ใน Unicode 10.0
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องแสดงภาพอักขระอีโมจิเหล่านี้เป็นรูปอักขระสีได้
- [C-1-2] ต้องมีการรองรับสำหรับรายการต่อไปนี้
- แบบอักษร Roboto 2 ที่มีน้ำหนักต่างกัน ได้แก่ sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light สำหรับภาษาที่มีให้บริการบนอ��ปกรณ์
- ความครอบคลุมของ Unicode 7.0 แบบเต็มของภาษาละติน กรีก และซีริลลิก รวมถึงช่วงภาษาละตินแบบขยาย A, B, C และ D และรูปอักขระทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0
- ควรสนับสนุนอีโมจิผิวสีและอีโมจิที่หลากหลายสำหรับครอบครัวตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51
หากอุปกรณ์มี IME รวมอยู่ด้วย ระบบจะดำเนินการดังนี้
- ควรระบุวิธีการป้อนข้อมูลสำหรับอักขระอีโมจิเหล่านี้ให้แก่ผู้ใช้
3.8.14 หลายหน้าต่าง
การติดตั้งใช้งานอุปกรณ์จะแสดงกิจกรรมหลายอย่างในเวลาเดียวกันได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตามลักษณะการทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ในเอกสารสนับสนุนโหมดหลายหน้าต่างของ Android SDK และเป็นไปตามข้อกำหนดต่อไปนี้
- [C-1-2] แอปพลิเคชันสามารถระบุได้ว่าทำงานในโหมดหลายหน้าต่างในไฟล์
AndroidManifest.xml
ได้หรือไม่ ไม่ว่าจะผ่านการตั้งค่าแอตทริบิวต์android:resizeableActivity
เป็นtrue
หรือโดยปริยายด้วยการใช้ targetSdkVersion > 24 แอปที่ตั้งค่าแอตทริบิวต์นี้เป็นfalse
อย่างชัดเจนในไฟล์ Manifest ต้องไม่เปิดขึ้นในโหมดหลายหน้าต่าง แอปเก่าที่มี targetSdkVersion < 24 ที่ไม่ได้ตั้งค่าแอตทริบิวต์android:resizeableActivity
นี้อาจเปิดในโหมดหลายหน้าต่างได้ แต่ระบบต้องแสดงคำเตือนว่าแอปอาจไม่ทำงานตามที่คาดไว้ในโหมดหลายหน้าต่าง - [C-1-3] ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดรูปแบบอิสระหากความสูงของหน้าจอ < 440 dp และความกว้างของหน้าจอน้อยกว่า 440 dp
- การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ
xlarge
ควรรองรับโหมดรูปแบบอิสระ
หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดแยกหน้าจอ การใช้งานจะส่งผลดังนี้
- [C-2-1] ต้องโหลด Launcher ที่ปรับขนาดได้ไว้ล่วงหน้าเป็น��่าเริ่มต้น
- [C-2-2] ต้องครอบตัดกิจกรรมที่อยู่บนแท่นชาร์จของหลายหน้าต่างในโหมดแยกหน้าจอ แต่ควรแสดงเนื้อหาบางอย่าง หากแอป Launcher เป็นหน้าต่างที่โฟกัสอยู่
- [C-2-3] ต้องปฏิบัติตามค่า
AndroidManifestLayout_minWidth
และAndroidManifestLayout_minHeight
ที่ประกาศไว้ของแอปพลิเคชัน Launcher ของบุคคลที่สาม และไม่ลบล้างค่าเหล่านี้ในช่วงที่แสดงเนื้อหาบางส่วนของกิจกรรมบนแท่นชาร์จ
หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดหลายหน้าต่างการแสดงภาพซ้อนภาพ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องเปิดกิจกรรมในโหมดหลายหน้าต่างการแสดงภาพซ้อนภาพเมื่อแอปดำเนินการต่อไปนี้ * API การกำหนดเป้าหมายระดับ 26 ขึ้นไปและประกาศ
android:supportsPictureInPicture
* API การกำหนดเป้าหมายระดับ 25 หรือต่ำกว่า และประกาศทั้งandroid:resizeableActivity
และandroid:supportsPictureInPicture
- [C-3-2] ต้องแสดงการดำเนินการใน SystemUI ตามที่ระบุโดยกิจกรรม PIP ปัจจุบันผ่าน
setActions()
API - [C-3-3] ต้องรองรับสัดส่วนภาพที่มากกว่าหรือเท่ากับ 1:2.39 และน้อยกว่าหรือเท่ากับ 2.39:1 ตามที่ระบุไว้โดยกิจกรรม PIP ผ่าน
setAspectRatio()
API - [C-3-4] ต้องใช้
KeyEvent.KEYCODE_WINDOW
เพื่อควบคุมหน้าต่าง PIP หากไม่ใช้โหมด PIP ต้องมีคีย์ในกิจกรรมเบื้องหน้า - [C-3-5] ต้องเสนอค่าตอบแทนแก่ผู้ใช้ในการบล็อกแอปไม่ให้แสดงในโหมด PIP การใช้ AOSP เป็นไปตามข้อกำหนดนี้โดยการควบคุมในหน้าต่างแจ้งเตือน
- [C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำเป็น 108 dp สำหรับหน้าต่าง PIP และความกว้างขั้นต่ำเป็น 240 dp และความสูง 135 dp สำหรับหน้าต่าง PIP เมื่อกำหนดค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_TELEVISION
3.9 การดูแลระบบของอุปกรณ์
Android มีฟีเจอร์ที่ช่วยให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยสามารถใช้ฟังก์ชันการดูแลระบบอุปกรณ์ในระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านห��ือล้างข้อมูลจากระยะไกล ผ่าน Android Device Administration API]
หากการติดตั้งใช้งานอุปกรณ์ใช้นโยบายการดูแลระบบอุปกรณ์อย่างเต็มรูปแบบตามที่ระบุไว้ในเอกสาร Android SDK นโยบายดังกล่าวจะดำเนินการดังนี้
- [C-1-1] ต้องประกาศ
android.software.device_admin
- [C-1-2] ต้องรองรับการจัดสรรเจ้าของอุปกรณ์ตามที่อธิบายไว้ในส่วนที่ 3.9.1 และส่วนที่ 3.9.1.1
- [C-1-3] ต้องประกาศการรองรับโปรไฟล์ที่จัดการผ่านแฟล็กฟีเจอร์
android.software.managed_users
ยกเว้นในกรณีที่อุปกรณ์ได้รับการกำหนดค่าให้รายงานว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือเพื่อจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
3.9.1 การจัดสรรอุปกรณ์
3.9.1.1 การจัดสรรเจ้าของอุปกรณ์
การใช้งานอุปกรณ์จะประกาศ android.software.device_admin
ดังต่อไปนี้
- [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์ Device Policy (DPC) เป็นแอปเจ้าของอุปกรณ์ตามที่อธิบายไว้ด้านล่าง
- เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่ได้กําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-3] ต้องรายงาน
true
สำหรับDevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
- [C-1-4] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์เพื่อตอบสนองต่อการดำเนินการของ Intent
android.app.action.PROVISION_MANAGED_DEVICE
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่านแฟล็กฟีเจอร์
android.hardware.nfc
และได้รับข้อความ NFC ที่มีระเบียนประเภท MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-3] ต้องรายงาน
- เมื่อการติดตั้งใช้งานอุปกรณ์มีข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-6] ต้องรายงาน
false
สำหรับDevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
- [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป
- [C-1-6] ต้องรายงาน
- เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่ได้กําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-2] ต้องไม่ตั้งค่าแอปพลิเคชัน (รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า) เป็นแอปเจ้าของอุปกรณ์ โดยไม่ได้รับความยินยอมหรือดำเนินการอย่างชัดแจ้งจากผู้ใช้หรือผู้ดูแลระบบ��องอุปกรณ์
หากการนำอุปกรณ์ไปใช้งานประกาศ android.software.device_admin
แต่ยังรวมโซลูชันการจัดการเจ้าของอุปกรณ์ที่เป็นกรรมสิทธิ์ด้วย และให้กลไกในการโปรโมตแอปพลิเคชันที่กำหนดค่าในโซลูชันของตนเป็น "เทียบเท่าเจ้าของอุปกรณ์" กับ "เจ้าของอุปกรณ์" มาตรฐานตามที่ Android DevicePolicyManager API มาตรฐานรู้จัก จะมีการดำเนินการต่อไปนี้
- [C-2-1] ต้องมีขั้นตอนยืนยันว่าแอปที่โปรโมตเป็นโซลูชันการจัดการอุปกรณ์ขององค์กรที่ถูกต้องตามกฎหมาย และได้กำหนดค่าไว้ในโซลูชันที่เป็นกรรมสิทธิ์ให้มีสิทธิ์เทียบเท่า "เจ้าของอุปกรณ์" แล้ว
- [C-2-2] ต้องแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับขั้นตอนที่
android.app.action.PROVISION_MANAGED_DEVICE
เริ่มต้นก่อนที่จะลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์" - อาจมีข้อมูลผู้ใช้อยู่ในอุปกรณ์ก่อนลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์"
3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
-
[C-1-1] ต้องใช้ API เพื่ออนุญาตให้แอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) เป็นเจ้าของโปรไฟล์ที่มีการจัดการใหม่
-
[C-1-2] กระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (ขั้นตอนที่เริ่มต้นโดยผู้ใช้ android.app.action.PROVISION_MANAGED_PROFILE) ประสบการณ์ของผู้ใช้ต้องสอดคล้องกับการใช้งาน AOSP
-
[C-1-3] ต้องระบุค่าบริการต่อไปนี้ของผู้ใช้ภายในการตั้งค่า เพื่อแจ้งให้ผู้ใช้ทราบเมื่อตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ปิดใช้งานฟังก์ชันของระบบบางอย่าง
- ไอคอนที่สอดคล้องกันหรือการชำระเงินอื่นๆ ของผู้ใช้ (เช่น ไอคอนข้อมูล AOSP ต้นทาง) เพื่อแสดงเมื่อผู้ดูแลระบบอุปกรณ์จำกัดการตั้งค่าบางอย่าง
- ข้อความอธิบายสั้นๆ ตามที่ผู้ดูแลระบบอุปกรณ์ระบุไว้ผ่าน
setShortSupportMessage
- ไอคอนของแอปพลิเคชัน DPC
3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์ที่มีการจัดการผ่าน API ของ
android.app.admin.DevicePolicyManager
- [C-1-2] ต้องอนุญาตให้สร้างโปรไฟล์ที่มีการจัดการได้ 1 ��ายการเท่านั้น
- [C-1-3] ต้องใช้ป้ายไอคอน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ รวมถึงองค์ประกอบ UI อื่นๆ ที่มีตราสถานะ เช่น ล่าสุดและการแจ้งเตือน
- [C-1-4] ต้องแสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อระบุว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการเมื่อใด
- [C-1-5] ต้องแสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการหากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ภายในโปรไฟล์ที่มีการจัดการ
- [C-1-6] เมื่อมีโปรไฟล์ที่มีการจัดการอยู่ ต้องแสดงความสามารถในการมองเห็นใน Intent 'Chooser' เพื่อให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากเปิดใช้โดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
- [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีการจ่ายเงินสำหรับผู้ใช้ดังต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- แยกการพิจารณาการใช้งานแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการโดยอิสระ
- การจัดการอิสระของแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันแป้นโทรศัพท์ ที่อยู่ติดต่อ และข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลักได้ หากตัวควบคุมนโยบายด้านอุปกรณ์อนุญาต
- [C-1-9] ต้องตรวจสอบว่าโปรไฟล์นั้นเป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่มีผลบังคับใช้กับอุปกรณ์ที่มีผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
- [C-1-10] ต้องรองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากซึ่งเป็นไปตามข้อกำหนดต่อไปนี้ในการให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการ
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ - ข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้ที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกันกับโปรไฟล์หลักตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- นโยบายรหัสผ่านของ DPC ต้องมีผลเฉพาะกับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการ เว้นแต่ว่ามีการเรียกใช้อินสแตนซ์
DevicePolicyManager
ที่แสดงผลโดย getParentProfileInstance
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ
- เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนระหว่างสายและสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อติดต่อดังกล่าวควรมีป้ายติดป้ายเดียวกับที่ใช้เพื่อระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
3.10 การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่มีความพิการสามารถไปยังส่วนต่างๆ ในอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API ของแพลตฟอร์มที่ช่วยให้ติดตั้งใช้งานบริการการช่วยเหลือพิเศษเพื่อรับ Callback สำหรับเหตุการณ์ของผู้ใช้และระบบ รวมถึงสร้างกลไกการแสดงความคิดเห็นแบบอื่น เช่น การอ่านออกเสียงข้อความ การตอบสนองแบบรู้สึกได้ และการนำทางแทร็กบอล/D-pad
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบของ SDK เกี่ยวกับ API การช่วยเหลือพิเศษ
- [C-1-2] ต้องสร้างเหตุการณ์การช่วยเหลือพิเศษและส่ง
AccessibilityEvent
ที่เหมาะสมไปยังการใช้งานAccessibilityService
ที่ลงทะเบียนไว้ทั้งหมดตามที่ระบุไว้ใน SDK - [C-1-3] ต้องปฏิบัติตามเจตนาของ
android.settings.ACCESSIBILITY_SETTINGS
ในการจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดใช้และปิดใช้บริการการช่วยเหลือพิเศษของบุคคลที่สาม ควบคู่ไปกับบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า - [C-1-4] ต้องเพิ่มปุ่มในแถบนำทางของระบบเพื่อให้ผู้ใช้ควบคุมบริการการช่วยเหลือพิเศษได้เมื่อบริการการช่วยเหลือพิเศษที่เปิดใช้ประกาศปุ่ม
AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON
โปรดทราบว่าสำหรับการใช้อุปกรณ์ที่ไม่มีแถบนำทางของระบบ ข้อกำหนดนี้จะไม่มีผล แต่การใช้งานอุปกรณ์ควรให้ผู้ใช้มีสิทธิ์ในการควบคุมบริการการช่วยเหลือพิเศษเหล่านี้
หากการติดตั้งใช้งานอุปกรณ์มีบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้บริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้าเหล่านี้เป็นแอป Direct Boot Aware เมื่อพื้นที่เก็บข้อมูลได้รับการเข้ารหัสด้วย Fileตาม Encryption (FBE)
- ควรมีกลไกในขั้นตอนการตั้งค่าที่พร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผล และท่าทางสัมผัสการขยาย
3.11 Text-to-Speech
Android มี API ที่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากบริการอ่านออกเสียงข้อความ (TTS) และช่วยให้ผู้ให้บริการติดตั้งใช้งานบริการ TTS ได้
หากอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับ API ของ Android TTS Framework
หากการติดตั้งอุปกรณ์รองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม การติดตั้งจะดำเนินการดังนี้
- [C-2-1] ต้องให้เงินแก่ผู้ใช้เพื่อให้ผู้ใช้เลือกเครื่องมือ TTS สำหรับการใช้งานในระดับระบบ
3.12 เฟรมเวิร์กอินพุตทีวี
Android Television Input Framework (TIF) ทำให้การส่งเนื��อหาสดไปยังอุปกรณ์ Android TV ง่ายขึ้น TIF มี API มาตรฐานเพื่อสร้างโมดูลอินพุตที่ควบคุมอุปกรณ์ Android Television
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องประกาศฟีเจอร์ของแพลตฟอร์ม
android.software.live_tv
- [C-1-2] ต้องโหลดแอปพลิเคชัน TV (แอป TV) ไว้ล่วงหน้าและเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 3.12.1
3.12.1 แอป TV
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF
- [C-1-1] แอป TV ต้องมีสิ่งอำนวยความสะดวกในการติดตั้งและใช้ช่องทีวี และเป็นไปตามข้อกำหนดต่อไปนี้
แอป TV ที่จำเป็นสำหรับการใช้งานอุปกรณ์ Android ที่ประกาศ Flag ฟีเจอร์ android.software.live_tv
ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- การใช้งานอุปกรณ์ควรอนุญาตให้ติดตั้งและจัดการอินพุตที่อิงตาม TIF ของบุคคลที่สาม (อินพุตของบุคคลที่สาม)
- การใช้งานอุปกรณ์อาจมีการแยกภาพระหว่างอินพุตตาม TIF ที่ติดตั้งไว้ล่วงหน้า (อินพุตที่ติดตั้งไว้) และอินพุตของบุคคลที่สาม
- การใช้งานอุปกรณ์ไม่ควรแสดงอินพุตของบุคคลที่สามในการไปยังส่วนต่างๆ จากแอป TV มากกว่า 1 ครั้ง (เช่น การขยายรายการอินพุตของบุคคลที่สามจากแอป TV)
โครงการโอเพนซอร์ส Android นำเสนอการใช้งานแอป TV ที่เป็นไปตามข้อกำหนดข้างต้น
3.12.1.1 คู่มือโปรแกรมอิเล็กทรอนิกส์
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องแสดงโฆษณาซ้อนทับแบบอินเทอร์แอกทีฟที่ให้ข้อมูลและโต้ตอบได้ โดยต้องมีคู่มือโปรแกรมอิเล็กทรอนิกส์ (EPG) ที่สร้างจากค่าในช่อง TvContract.Programs
- [C-1-2] เมื่อเปลี่ยนช่อง การใช้งานอุปกรณ์ต้องแสดงข้อมูล EPG สำหรับโปรแกรมที่เล่นอยู่ในปัจจุบัน
- [SR] EPG ขอแนะนำอย่างยิ่งให้แสดงอินพุตที่ติดตั้งไว้และอินพุตของบุคคลที่สามโดยมีความโดดเด่นเท่ากัน EPG ไม่ควรแสดงอินพุตของบุคคลที่สามมากกว่าการไปยังส่วนต่างๆ เพียงครั้งเดียวจากอินพุตที่ติดตั้งไว้ใน EPG
- EPG ควรแสดงข้อมูลจากอินพุตทั้งหมดที่ติดตั้งไว้และอินพุตของบุคคลที่สาม
- EPG อาจมีการแยกภาพระหว่างอินพุตที่ติดตั้งไว้และอินพุตของบุคคลที่สาม
3.12.1.2 การนำทาง
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF สิ่งที่จะเกิดขึ้นมีดังนี้
-
[C-1-1] ต้องอนุญาตการนำทางสำหรับฟังก์ชันต่อไปนี้ผ่านแป้น D-pad, ย้อนกลับ และ Home ในอุปกรณ์อินพุตของอุปกรณ์ Android TV (เช่น รีโมตคอนโทรล แอปพลิเคชันรีโมตคอนโทรล หรือตัวควบคุมเกม)
- การเปลี่ยนช่องทีวี
- กำลังเปิด EPG
- การกำหนดค่าและปรับแต่งอินพุตตาม TIF ของบุคคลที่สาม
- กำลังเปิดเมนูการตั้งค่า
-
ควรส่งเหตุการณ์สำคัญไปยังอินพุต HDMI ผ่าน CEC
3.12.1.3 การลิงก์แอปอินพุตทีวี
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF
- [C-1-1] การใช้งานอุปกรณ์ Android TV ต้องรองรับการลิงก์แอปอินพุตทีวี ซึ่งอนุญาตให้อินพุตทั้งหมดแสดงลิงก์กิจกรรมจากกิจกรรมปัจจุบันไปยังกิจกรรมอื่น (เช่น ลิงก์จากรายการสดไปยังเนื้อหาที่เกี่ยวข้อง)
- [C-1-2] แอปทีวีต้องแสดงการลิงก์แอปอินพุตทีวีเมื่อมีให้
3.12.1.4 การเปลี่ยนเวลา
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF สิ่งที่จะเกิดขึ้นมีดังนี้
- [SR] แนะนำอย่างเข้มงวดเพื่อรองรับการเปลี่ยนเวลา ซึ่งจะช่วยให้ผู้ใช้หยุดเนื้อหาแบบสดไว้ชั่วคราวและกลับมาเล่นต่อได้
- ควรแจ้งวิธีหยุดโปรแกรมที่กำลังเล่นอยู่ไว้ชั่วคราวและกลับมาใช้งานอีกครั้ง หากโปรแกรมดังกล่าวมีช่วงเวลาที่ต้องการเปลี่ยน
3.12.1.5 การบันทึกรายการทีวี
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF สิ่งที่จะเกิดขึ้นมีดังนี้
- [SR] แนะนำอย่างยิ่งให้สนับสนุนการบันทึกรายการทีวี
- ควรมีอินเทอร์เฟซผู้ใช้ในการเล่นรายการที่บันทึกไว้
- หากอินพุตของทีวีรองรับการบันทึก แต่การบันทึกรายการไม่ใช่สิ่งต้องห้าม EPG อาจมอบวิธีบันทึกรายการให้
3.13 การตั้งค่าด่วน
Android มีคอมโพเนนต์ UI การตั้งค่าด่วนที่ช่วยให้เข้าถึงการดำเนินการ��ี่ใช้บ่อยหรือที่จำเป็นเร่งด่วนได้อย่างรวดเร็ว
หากการใช้งานอุปกรณ์มีคอมโพเนนต์ UI ของการตั้งค่าด่วน ให้ทำดังนี้
- [C-1-1] ต้องอนุญาตให้ผู้ใช้เพิ่มหรือนำไทล์ที่ให้บริการผ่าน
quicksettings
API ออกจากแอปของบุคคลที่สาม - [C-1-2] ต้องไม่เพิ่มการ์ดจากแอปของบุคคลที่สามลงในการตั้งค่าด่วนโดยตรง
- [C-1-3] ต้องแสดงการ์ดที่ผู้ใช้เพิ่มทั้งหมดจากแอปของบุคคลที่สามควบคู่ไปกับการ์ดการตั้งค่าด่วนที่ระบบมีให้
3.14 UI สื่อ
หากการใช้งานอุปกรณ์มีเฟรมเวิร์ก UI ที่รองรับแอปของบุคคลที่สามที่ใช้ MediaBrowser
และ MediaSession
การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องแสดงไอคอน MediaItem และไอคอนการแจ้งเตือนโดยไม่เปลี่ยนแปลง
- [C-1-2] ต้องแสดงรายการเหล่านั้นตามที่อธิบายไว้โดย MediaSession เช่น ข้อมูลเมตา ไอคอน ภาพ
- [C-1-3] ต้องแสดงชื่อแอป
- [C-1-4] ต้องมีลิ้นชักเพื่อแสดงลำดับชั้นของ MediaBrowser
3.15 Instant Apps
การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- [C-0-1] Instant Apps ต้องได้รับสิทธิ์ที่ตั้งค่า
android:protectionLevel
เป็น"ephemeral"
เท่านั้น - [C-0-2] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งผ่าน implicit Intent เว้นแต่จะเป็นไปตามข้อใดข้อหนึ่งต่อไปนี้
- แสดงตัวกรองรูปแบบ Intent ของคอมโพเนนต์และมี CATEGORY_BROWSABLE
- การกระทำนี้เป็นหนึ่งใน ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- เป้าหมายจะปรากฏอย่างชัดเจนด้วย android:visibleToInstantApps
- [C-0-3] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งอย่างชัดเจน เว้นแต่จะเปิดเผยคอมโพเนนต์ผ่าน android:visibleToInstantApps
- [C-0-4] แอปที่ติดตั้งต้องไม่ดูรายละเอียดเกี่ยวกับ Instant Apps ในอุปกรณ์ เว้นแต่ Instant App จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งไว้อย่างชัดเจน
3.16 การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
Android รองรับการจับคู่อุปกรณ์ที่ใช้ร่วมกันเพื่อให้จัดการการเชื่อมโยงกับอุปกรณ์ที่ใช้ร่วมกันได้อย่างมีประสิทธิภาพมากขึ้น รวมถึงมี CompanionDeviceManager
API เพื่อให้แอปเข้าถึงฟีเจอร์นี้ได้
หากการใช้งานอุปกรณ์รองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องประกาศแฟล็กฟีเจอร์
FEATURE_COMPANION_DEVICE_SETUP
- [C-1-2] ต้องตรวจสอบให้แน่ใจว่า API ในแพ็กเกจ
android.companion
ใช้งานได้โดยสมบูรณ์แล้ว - [C-1-3] ต้องให้ข้อมูลสำหรับผู้ใช้แก่ผู้ใช้ในการเลือก/ยืนยันว่ามีอุปกรณ์ที่ใช้ร่วมกันพร้อมใช้งานและทำงานได้
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ ซึ่งสร้างโดยเครื่องมือ “aapt” ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ
- เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย การติดตั้งใช้งานอุปกรณ์จึงแนะนำให้ใช้การติดตั้งใช้งาน System Management SystemDevice ของการใช้งานการอ้างอิง AOSP
- [C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v2 และการลงนาม JAR
- [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik bytescode หรือ RenderScript Bycode ในลักษณะที่จะป้องกันไม่ให้ไฟล์เหล่านั้นติดตั้งและทำงานได้อย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้
-
[C-0-4] ต้องไม่อนุญาตให้แอปอื่นนอกเหนือจาก "โปรแกรมติดตั้งระเบียน" ปัจจุบันของแพ็กเกจทำการถอนการติดตั้งแอปโดยไม่มีข้อความแจ้งใดๆ ต��มที่ระบ��ไว้ใน SDK ���ำหรับ��ิทธิ์
DELETE_PACKAGE
ข้อยกเว้นเพียงอย่างเดียวคือ แอปผู้ตรวจสอบแพ็กเกจของระบบที่จัดการ Intent PACKAGE_NEEDS_VERIFICATION และแอปของตัวจัดการพื้นที่เก็บข้อมูลที่จัดการ Intent ACTION_MANAGE_STORAGE ได้ -
[C-0-5] ต้องมีกิจกรรมที่จัดการ Intent ของ
android.settings.MANAGE_UNKNOWN_APP_SOURCES
-
[C-0-6] ต้องไม่ติดตั้งแพ็กเกจแอปพลิเคชันจากแหล่งที่มาที่ไม่รู้จัก เว้นแต่แอปที่ขอติดตั้งจะเป็นไปตามข้อกำหนดทั้งหมดต่อไปนี้
- ต้องประกาศสิทธิ์
REQUEST_INSTALL_PACKAGES
หรือตั้งค่าandroid:targetSdkVersion
เป็น 24 หรือต่ำกว่า - แอปต้องได้รับอนุญาตจากผู้ใช้ให้ติดตั้งแอปจากแหล่งที่มาที่ไม่รู้จัก
- ต้องประกาศสิทธิ์
-
ควรให้เงินแก่ผู้ใช้ในการให้สิทธิ์/เพิกถอนสิทธิ์ในการติดตั้งแอปจากแหล่งที่มาที่ไม่รู้จักต่อแอปพลิเคชัน แต่อาจเลือกที่จะใช้งานแบบไม่ดำเนินการและแสดงผล
RESULT_CANCELED
สำหรับstartActivityForResult()
หากการใช้งานอุปกรณ์ไม่ต้องการให้ผู้ใช้มีทางเลือกนี้ อย่างไรก็ตาม แม้ในกรณีดังกล่าว ควรระบุให้ผู้ใช้ทราบว่าเหตุใดจึงไม่มีตัวเลือกดังกล่าว
5. ความเข้ากันได้กับมัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับรูปแบบสื่อ โปรแกรมเปลี่ยนไฟล์ โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในส่วนที่ 5.1 สำหรับตัวแปลงรหัสทุกตัวที่ประกาศโดย
MediaCodecList
- [C-0-2] ต้องประกาศและรายงานการรองรับโปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสที่มีให้กับแอปพลิเคชันของบุคคลที่สามผ่าน
MediaCodecList
- [C-0-3] ต้องถอดรหัสและกำหนดให้แอปของบุคคลที่สามใช้งานได้ทุกรูปแบบที่สามารถเข้ารหัสได้ ซึ่งรวมถึงบิตสตรีมทั้งหมดที่โปรแกรมเปลี่ยนไฟล์สร้างขึ้นและโปรไฟล์ที่รายงานใน
CamcorderProfile
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เวลาในการตอบสนองของตัวแปลงรหัสขั้นต่ำ หรือพูดอีกอย่างก็คือ
- ไม่ควรใช้และจัดเก็บบัฟเฟอร์อินพุต รวมถึงแสดงผลบัฟเฟอร์อินพุตเมื่อประมวลผลแล้วเท่านั้น
- ไม่ควรเก็บบัฟเฟอร์ที่ถอดรหัสแล้วไว้นานกว่าที่มาตรฐานระบุไว้ (เช่น SPS)
- ไม่ควรเก็บบัฟเฟอร์ที่เข้ารหัสไว้นานกว่าที่โครงสร้าง GOP กำหนด
ตัวแปลงรหัสทั้งหมดที่ระบุไว้ในส่วนด้านล่างมีไว้เพื่อเป็นการติดตั้งซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโครงการโอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่รับรองว่าตัวแปลงรหัสเหล่านี้ปราศจากสิทธิบัตรของบุคคลที่สาม ผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ได้รับคำแนะนำว่า การใช้โค้ดนี้ รวมทั้งในซอฟต์แวร์โอเพนซอร์สหรือ Shareware อาจต้องมีใบอนุญาตสิทธิบัตรจากผู้ถือครองสิทธิบัตรที่เกี่ยวข้อง
5.1 ตัวแปลงสัญญาณสื่อ
5.1.1 การเข้ารหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์ต้องรองรับการเข้ารหัสเสียงต่อไปนี้
- [C-1-1] PCM/WAVE
5.1.2 การถอดรหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
หากการใช้งานอุปกรณ์ประกาศการรองรับฟีเจอร์ android.hardware.audio.output
การใช้งานอุปกรณ์จะต้องรองรับตัวถอดรหัสเสียงต่อไปนี้
- [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงใหม่)
- [C-1-4] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
- [C-1-5] FLAC
- MP3 [C-1-6]
- [C-1-7] MIDI
- [C-1-8] เวอร์บี
- [C-1-9] PCM/WAVE
- [C-1-10] โอปัส
หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมแบบหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านตัวถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec
API ต้องมีการรองรับดังต่อไปนี้
- [C-2-1] การถอดรหัสต้องดำเนินการโดยไม่ดาวน์มิกซ์ (เช่น ต้องถอดรหัสสตรีม 5.0 AAC เป็น PCM 5 ช่อง ต้องถอดรหัสสตรีม 5.1 AAC เป็น PCM 6 ช่อง)
- [C-2-2] ข้อมูลเมตาของช่วงไดนามิกต้องระบุไว้ใน "การควบคุมช่วงไดนามิก (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
5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|
โปรไฟล์ MPEG-4 AAC (AAC LC) |
รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz |
|
โปรไฟล์ MPEG-4 HE AAC (AAC+) | รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | |
โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ได้รับการปรับปรุง) |
รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | |
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC) | รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | |
AMR-NB | สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s แบบสุ่มตัวอย่างที่ 16 kHz | |
FLAC | โมโน/สเตอริโอ (ไม่ใช่แบบหลายช่องทาง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz สำหรับอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากเครื่องวัดอัตราการสุ่มตัวอย่างเสียงต่ำ 48 ถึง 44.1 kHz ไม่มีตัวกรองแบบ Low Pass) แนะนำให้ใช้ 16 บิต ไม่ได้ใช้ที่ต่างกันสำหรับ 24 บิต | FLAC (.flac) เท่านั้น |
MP3 | ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR) | MP3 (.mp3) |
MIDI | MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ XMF สำหรับอุปกรณ์เคลื่อนที่ รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody |
|
Vorbis |
|
|
PCM/WAVE | PCM เชิงเส้น 16 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM แบบ RAW ที่ความถี่ 8000, 11025, 16000 และ 44100 Hz | WAVE (.wav) |
Opus | มาโทรสกา (.mkv), Ogg(.ogg) |
5.1.4 การเข้ารหัสรูปภาพ
ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ
การใช้งานอุปกรณ์ต้องรองรับการเข้ารหัสการเข้ารหัสรูปภาพต่อไปนี้
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
5.1.5 การถอดรหัสรูปภาพ
ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ
การใช้งานอุปกรณ์ต้องรองรับการเข้ารหัสการถอดรหัสรูปภาพต่อไปนี้
- [C-0-1] JPEG
- GIF [C-0-2]
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] ดิบ
5.1.6 รายละเอียดตัวแปลงรหัสภาพ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|
JPEG | ฐาน +โพรเกรสซีฟ | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
แบบข้อมูลดิบ | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) |
5.1.7 ตัวแปลงรหัสวิดีโอ
- เพื่อคุณภาพที่ยอมรับได้ของบริการสตรีมวิดีโอบนเว็บและบริการประชุมทางวิดีโอ การใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่เป็นไปตามข้อกำหนด
หากการใช้งานอุปกรณ์มีตัวถอดรหัสวิดีโอหรือโปรแกรมเปลี่ยนไฟล์
-
[C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดเอาต์พุตและไบต์บัฟเฟอร์อินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดขนาดใหญ่ที่สุดตามที่มาตรฐานและการกำหนดค่ากำหนดไว้ แต่ต้องไม่ครอบคลุมโดยรวม
-
[C-1-2] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 (COLOR_FormatYUV420แบบยืดหยุ่น)
การติดตั้งใช้งานอุปกรณ์ที่โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities
จะมีผลดังนี้
- [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ HDR
หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh
ในชั้นเรียน MediaCodecInfo.CodecCapabilities
การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-3-1]ต้องรองรับระยะเวลารีเฟรชในช่วง 10 - 60 เฟรมและทำงานอย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้
5.1.8 รายการตัวแปลงรหัสวิดีโอ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด |
ประเภทไฟล์ที่รองรับ/ รูปแบบคอนเทนเนอร์ |
---|---|---|
H.263 |
|
|
H.264 AVC | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
HEVC ของ H.265 | ดูรายละเอียดในส่วนที่ 5.3 | MPEG-4 (.mp4) |
MPEG-2 | โปรไฟล์หลัก | MPEG2-TS |
MPEG-4 SP | 3GPP (.3gp) | |
VP8 | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
VP9 | ดูรายละเอียดในส่วนที่ 5.3 |
|
5.2 การเข้ารหัสวิดีโอ
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอและทำให้แอปของบุคคลที่สามใช้งานได้ ระบบจะดำเนินการดังต่อไปนี้
- ไม่ควรเกิน 2 หน้าต่างเลื่อน มากกว่า 15% ของอัตราบิตระหว่างช่วงเวลาภายในเฟรม (I-Frame)
- ไม่ควรเกิน ~100% ของอัตราบิตในหน้าต่างเลื่อน 1 วินาที
หากการใช้งานอุปกรณ์มีจอแสดงผลแบบฝังบนหน้าจอซึ่งมีความยาวแนวทแยงอย่างน้อย 2.5 นิ้ว หรือมีพอร์ตเอาต์พุตวิดีโอหรือประกาศการรองรับกล้องผ่านแฟล็กฟีเจอร์ android.hardware.camera.any
การดำเนินการเหล่านี้จะมีผลดังนี้
- [C-1-1] ต้องสนับสนุนโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 หรือ H.264 อย่างน้อย 1 โปรแกรม และใช้กับแอปพลิเคชันของบุคคลที่สามได้
- รองรับทั้งโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 และ H.264 และใช้กับแอปพลิเคชันของบุคคลที่สามได้
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ H.264, VP8, VP9 หรือ HEVC ใดๆ ก็ตามและทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกได้
- ควรรองรับอัตราเฟรมที่เปลี่ยนแปลงได้ ซึ่งโปรแกรมเปลี่ยนไฟล์วิดีโอควรกำหนดระยะเวลาของเฟรมทันทีตามการประทับเวลาของบัฟเฟอร์อินพุตและจัดสรรที่เก็บข้อมูลบิตตามระยะเวลาเฟรมนั้น
หากการใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ MPEG-4 SP และทำให้แอปของบุคคลที่สามใช้งานได้ รูปแบบดังกล่าวจะดังต่อไปนี้
- ควรสนับสนุนอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่สนับสนุน
5.2.1 H.263
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์ H.263 และทำให้ใช้งานกับแอปของบุคคลที่สามได้ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 45
- ควรสนับสนุนอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่สนับสนุน
5.2.2 H-264
หากอุปกรณ์รองรับตัวแปลงรหัส H.264 การทำงานเหล่านี้จะมีผลดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 แต่การรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS กับโปรไฟล์พื้นฐานเพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android อื่นๆ
- [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
- ควรรองรับโปรไฟล์หลักระดับ 4
- ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว������นตารางต่อไปนี้
หากการใช้งานอุปกรณ์ร��ยงานการรองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน API ของสื่อ การดำเนินการต่อไปนี้
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 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 |
5.2.3 VP8
หากอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD
- ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (ความละเอียดสูง) ต่อไปนี้
- ควรรองรับการเขียนไฟล์ Matroska WebM
- ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดการเขียนโค้ดฮาร์ดแวร์ RTC ของโปรเจ็กต์ WebM เพื่อให้บริการสตรีมมิงวิดีโอบนเว็บและบริการประชุมทางวิดีโอที่มีคุณภาพที่ยอมรับได้
หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน API ของสื่อ การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 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 |
5.2.4 VP9
หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้
- ควรรองรับการเขียนไฟล์ Matroska WebM
5.3 การถอดรหัสวิดีโอ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับความละเอียดของวิดีโอแบบไดนามิกและอัตราเฟรมที่สลับผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดในแบบเรียลไทม์และสูงสุดถึงความละเอียดสูงสุดที่ตัวแปลงรหัสแต่ละตัวบนอุปกรณ์รองรับ
หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION
ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องมีอุปกรณ์แยกที่รองรับ Dolby Vision
- [C-2-2] ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องในหน้าจอของอุปกรณ์หรือบนพอร์ต���อาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
- [C-2-3] ต้องตั้งค่าดัชนีการติดตามของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับดัชนีการติดตามของเลเยอร์ Dolby Vision แบบรวม
5.3.1 MPEG-2
หากการติดตั้งอุปกรณ์รองรับตัวถอดรหัส MPEG-2 การดำเนินการต่อไปนี้
- [C-1-1] ต้องสนับสนุนระดับสูงของโปรไฟล์หลัก
5.3.2 H.263
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรห��ส H.263 สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 30 และระดับ 45
5.3.3 MPEG-4
หากอุปกรณ์มีตัวถอดรหัส MPEG-4 สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ Simple Profile ระดับ 3
5.3.4 H.264
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.264 ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน ระบบรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) ไม่บังคับ
- [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงอยู่ในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐานและโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
- ควรสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในตารางต่อไปนี้
- [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 60 FPS | 30 FPS (60 FPS ทีวี) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5 H.265 (HEVC)
หากอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องสนับสนุนระดับหลักของโปรไฟล์หลักระดับ 3 และโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
- [C-1-2] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีตัวถอดรหัสฮาร์ดแวร์
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส H.265 หรือ VP9 ของโปรไฟล์ 720, 1080 และ UHD อย่างน้อย 1 รายการ
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/60 FPS (60 fps ทีวีที่มีการถอดรหัสฮาร์ดแวร์ H.265) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.3.6 VP8
หากอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
- ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่ตรงตามข้อกำหนด
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้
หากความสูงตามที่รายงานโดยเมธอด Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอแล้ว ให้ทำดังนี้
- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในตารางต่อไปนี้
- [C-2-2] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 FPS (60 FPS ทีวี) | 30 (60 FPSทีวี) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7 VP9
หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์
- [C-2-1] ต้องสนับสนุนโปรไฟล์การถอดรหัส HD ที่ระบุในตารางต่อไปนี้
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-3-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส VP9 หรือ H.265 อย่างน้อย 1 รายการของโปรไฟล์ 720, 1080 และ UHD
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ทีวีที่มีการถอดรหัสฮาร์ดแวร์ VP9) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.4 การบันทึกเสียง
แม้ว่าข้อกำหนดบางส่วนที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" นับตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" เราแนะนำอุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่ให้ปฏิบัติตามข้อกำหนดเหล่านี้ที่ระบุว่า "ควร" หรือจะไม่สามารถใช้กับ Android เมื่ออัปเกรดเป็นเวอร์ชันอนาคต
5.4.1 การบันทึกเสียงแบบ RAW
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
-
[C-1-1] ต้องอนุญาตให้มีการบันทึกเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100 Hz
- ช่องสัญญาณ: โมโน
-
[C-1-2] ต้องจับอัตราการสุ่มตัวอย่างสูงกว่าโดยไม่มีการสุ่มตัวอย่าง
- [C-1-3] ต้องระบุตัวกรองการลดรอยหยักที่เหมาะสมเมื่ออัตราการสุ่มตัวอย่างที่ระบุข้างต้นได้รับการบันทึกใน���ารสุ่มตัวอย่าง
-
ควรอนุญาตให้มีการบันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ ซึ่งหมายความว่ามีคุณลักษณะดังต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
- ช่องสัญญาณ: สเตอริโอ
หากการติดตั้งอุปกรณ์อนุญาตให้บันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ จะมีผลดังนี้
- [C-2-1] ต้องจับภาพ�������ไม่มีการสุ่มตัวอย่าง���น������������่วนที่สูงกว่า 16000:22050 หรือ 44100:48000
- [C-2-2] ต้องมีตัวกรองขจัดรอยหยักที่เหมาะสมสำหรับการเพิ่มหรือการสุ่มตัวอย่าง
5.4.2 จับภาพสำหรับการจดจำเสียง
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
- [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
ที่อัตราการสุ่มตัวอย่างแบบใดแบบหนึ่ง ได้แก่ 44100 และ 48000 - [C-1-2] โดยค่าเริ่มต้น ต้องปิดใช้การประมวลผลเสียงที่มีการลดเสียงรบกวนเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาเสียง
AudioSource.VOICE_RECOGNITION
- [C-1-3] โดยค่าเริ่มต้น ต้องปิดใช้การควบคุมค่าเกนอัตโนมัติเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาเสียง
AudioSource.VOICE_RECOGNITION
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีคุณลักษณะแอมพลิจูดแบบแบนราบโดยประมาณต่อความถี่ โดยเฉพาะอย่างยิ่ง ±3 dB ตั้งแต่ 100 Hz ถึง 4000 Hz
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงด้วยการตั้งค่าความไวต่ออินพุตที่แหล่งพลังงานเสียง (SPL) 90 dB ที่ 1000 Hz จะให้ค่า RMS 2500 สำหรับตัวอย่าง 16 บิต
- ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นที่ช่วง -18 dB ถึง -18 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีความผิดเพี้ยนแบบฮาร์โมนิก (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
และเทคโนโลยีการตัดเสียงรบกวน (การลด) ที่ปรับแต่งสำหรับการจดจำคำพูด เทคโนโลยีดังกล่าวจะดำเนินการดังนี้
- [C-2-1] ต้องอนุญาตให้ควบคุมเอฟเฟกต์เสียงนี้ด้วย
android.media.audiofx.NoiseSuppressor
API - [C-2-2] ต้องระบุการใช้งานเทคโนโลยีระงับเสียงรบก��นแต่ละรายการผ่านฟิลด์
AudioEffect.Descriptor.uuid
โดยไม่ซ้ำ
5.4.3 จับภาพเพื่อเปลี่ยนเส้นทางการเล่น
ชั้นเรียน android.media.MediaRecorder.AudioSource
มีแหล่งที่มาของเสียง REMOTE_SUBMIX
หากการใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output
และ android.hardware.microphone
ระบบจะดำเนินการต่อไปนี้
-
[C-1-1] ต้องใช้แหล่งที่มาของเสียง
REMOTE_SUBMIX
อย่างถูกต้องเพื่อที่ว่าเมื่อแอปพลิเคชันใช้android.media.AudioRecord
API ในการบันทึกจากแหล่งที่มาเสียงนี้ แอปจะบันทึกการรวมสตรีมเสียงทั้งหมด ยกเว้นรายการต่อไปนี้-
AudioManager.STREAM_RING
-
AudioManager.STREAM_ALARM
-
AudioManager.STREAM_NOTIFICATION
-
5.5 การเล่นเสียง
Android มีการสนับสนุนเพื่ออนุญาตให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงตามที่ระบุไว้ในส่วนที่ 7.8.2
5.5.1 การเล่นเสียงดิบ
การใช้งานอุปกรณ์จะประกาศ android.hardware.audio.output
ดังต่อไปนี้
-
[C-1-1] ต้องอนุญาตการเล่นเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 32000, 44100
- ช่องสัญญาณ: โมโน สเตอริโอ
-
ควรอนุญาตการเล่นเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้
- อัตราการสุ่มตัวอย่าง: 24,000, 48,000
5.5.2 เอฟเฟกต์เสียง
Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการใช้งานในอุปกรณ์
หากการใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.audio.output
ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับการใช้งาน
EFFECT_TYPE_EQUALIZER
และEFFECT_TYPE_LOUDNESS_ENHANCER
ที่ควบคุมได้ผ่านคลาสย่อย AudioEffectEqualizer
,LoudnessEnhancer
- [C-1-2] ต้องรองรับการใช้งาน 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 ระดับเสียงเอาต์พุตเสียง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- ควรอนุญาตให้ปรับระดับเสียงในแต่ละสตรีมเสียงแยกกันโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย AudioAttributes และการใช้เสียงในรถตามที่กำหนดไว้แบบสาธารณะใน
android.car.CarAudioManager
5.6 เวลาในการตอบสนองของเสียง
เวลาในการตอบสนองของเสียงคือการหน่วงเวลาที่สัญญาณเสียงส่งผ่านระบบ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองสั้นๆ เพื่อให้ได้เอฟเฟกต์เสียงแบบเรียลไทม์
สำหรับวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้
- เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM และเมื่อเสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ตัวแปลงสัญญาณหรือสัญญาณในอุปกรณ์ออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
- เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมที่ตามมาหลังจากที่อุปกรณ์เล่นเสียง
- เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ตัวแปลงสัญญาณในอุปกรณ์หรือสัญญาณเข้ามาในอุปกรณ์ผ่านพอร์ต และเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM ที่สอดคล้องกัน
- อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
- เวลาในการตอบสนองแบบ Cold input ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่มีการใ��้งานและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมที่ตามมาขณะที่อุปกรณ์บันทึกเสียง
- Jitter เอาต์พุต Cold ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของเอาต์พุตเย็น
- ความแปรปรวนของเวลาในการตอบสนองแบบ Cold Input ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของอินพุตเย็น
- เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่อง เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่อง บวกกับช่วงเวลาบัฟเฟอร์ 1 ช่วง ร��ยะเวลาบัฟเฟอร์จะช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาสําหรับแอปเพื่อลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
- API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
- API เสียงดั้งเดิมของเสียง ชุด API ของ AAudio ภายใน Android NDK
หากการใช้งานอุปกรณ์ประกาศว่า android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามหรือเกินข้อกำหนดต่อไปนี้
- [SR] เวลาในการตอบสนองเอาต์พุตแบบ Cold 100 มิลลิวินาทีหรือน้อยกว่า
- [SR] เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
- [SR] ลด Jitter เอาต์พุต Cold
หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นหลังจากการปรับเทียบเริ่มต้นเมื่อใช้ API คิวบัฟเฟอร์ของ OpenSL ES PCM สำหรับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold ในอุปกรณ์เอาต์พุตเสียงอย่างน้อย 1 เครื่องที่รองรับ ระบบจะดำเนินการดังต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์
android.hardware.audio.low_latency
- [SR] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API ด้วย
หากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน API คิวบัฟเฟอร์ของ OpenSL ES PCM สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
หากการใช้งานอุปกรณ์รวม android.hardware.microphone
ด้วย เราขอแนะนำเป็นอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับอินพุตต่อไปนี้
- [SR] เวลาในการตอบสนองการป้อนข้อมูลแบบ Cold 100 มิลลิวินาทีหรือน้อยกว่า
- [SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
- [SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
- [SR] ลดเสียงรบกวนของอินพุต Cold
5.7 โปรโตคอลเครือข่าย
การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุในเอกสารประกอบของ Android SDK
หากการใช้งานอุปกรณ์มีเสียงหรือตัวถอดรหัสวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)
-
[C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบสื่อประเภท Segmant ด้านล่างผ่านโปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7
-
[C-1-3] ต้องรองรับโปรไฟล์เสียง RTP ต่อไปนี้และตัวแปลงรหัสที่เกี่ยวข้องในตาราง RTSP ด้านล่าง สำหรับข้อยกเว้น โปรดดูเชิงอรรถของตารางในส่วนที่ 5.1
รูปแบบกลุ่มสื่อ
รูปแบบกลุ่ม | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
สตรีมส่ง MPEG-2 | ISO 13818 |
ตัวแปลงรหัสวิดีโอ:
และ MPEG-2 ในหัวข้อ 5.1.3 ตัวแปลงสัญญาณเสียง:
|
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 | ISO 13818-7 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
WebVTT | WebVTT |
RTSP (RTP, SDP)
ชื่อโปรไฟล์ | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
H264 AVC | RFC 6184 | ดูรายละเอียดเกี่ยวกับ H264 AVC ในหัวข้อ 5.1.3 |
MP4A-ลาตินอเมริกา | RFC 6416 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3 |
H263-2000 | RFC 4629 | ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3 |
AMR | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-NB ในหัวข้อ 5.1.1 |
AMR-WB | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-WB ในหัวข้อ 5.1.1 |
MP4V-ES | RFC 6416 | ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ในหัวข้อ 5.1.3 |
Mpeg4-ทั่วไป | RFC 3640 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
MP2T | RFC 2250 | ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming |
5.8 สื่อที่ปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพ��ตฟอร์มที่ปลอดภัยได้ สิ่งต่อไปนี้จะเกิดขึ้น
- [C-1-1] ต้องประกาศการรองรับ
Display.FLAG_SECURE
หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE
และรองรับโปรโตคอลการแสดงผลแบบไร้สาย สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องรักษาความปลอดภัยลิงก์ด้วยกลไกที่มีการเข้ารหัสที่รัดกุม เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast
หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE
และรองรับจอแสดงผลภายนอกแบบใช้สาย ระบบจะดำเนินการดังต่อไปนี้
- [C-3-1] ต้องรอง���ับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกแบบมีสายทั้งหมด
5.9 Musical Instrument Digital Interface (MIDI)
หากการใช้งานอุปกรณ์รองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน) และรองรับ MIDI มากกว่าการส่งฮาร์ดแวร์ที่ใช้ MIDI ทั้งหมดต่อไปนี้ได้ ซึ่งให้บริการการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป จะเป็น
- [SR] แนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager
การรับส่งข้อมูลฮาร์ดแวร์ที่ใช้ MIDI ได้มีดังนี้
- โหมดโฮสต์ USB (ส่วนที่ 7.7 USB)
- โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7 USB)
- MIDI ผ่าน Bluetooth LE ดำเนินการในบทบาทหลัก (ส่วนที่ 7.4.3 บลูทูธ)
หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI ผ่านการส่งฮาร์ดแวร์ที่รองรับ MIDI ตามที่ระบุไว้ข้างต้น แต่ไม่รองรับ MIDI ผ่านการส่งฮาร์ดแวร์ดังกล่าว จะมีการดำเนินการดังนี้
- [C-1-1] ต้องไม่รายงานการรองรับฟีเจอร์ android.software.midi
5.10 เสียงระดับมืออาชีพ
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro
ผ่านคลาส android.content.pm.PackageManager การตั้งค่าดังกล่าวจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานการรองรับฟีเจอร์
android.hardware.audio.low_latency
- [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในเวลาในการตอบสนองของเสียงในส่วน 5.6 โดยต้องไม่เกิน 20 มิลลิวินาที และควรไม่เกิน 10 มิลลิวินาทีขึ้นไปจากเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
- [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมด���ุปกรณ์ต่อพ่วง USB
- [C-1-4] ต้องรายงานการรองรับฟีเจอร์
android.software.midi
- [C-1-5] ต้องเป็นไปตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียง USB โดยใช้ API คิวบัฟเฟอร์ PCM ของ OpenSL ES
- ควรทำให้ประสิทธิภาพของ CPU ในระดับที่ยั่งยืนขณะใช้งานเสียง
- ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
- ควรลดการลอยของนาฬิกาเสียงที่สัมพันธ์กับ CPU
CLOCK_MONOTONIC
เมื่อใช้งานทั้งคู่ - ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
- ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
- ควรบันทึกการวัดค่าเวลาในการตอบสนองของเสียงในทุกเส้นทาง
- ควรลด Jitter ในเวลาป้อน Callback ให้เสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
- ควรทำให้สัญญาณเสียงต่ำ (เอาต์พุต) หรือการรบกวนมากเกินไป (อินพุต) เป็นศูนย์ภายใต้การใช้งานปกติในเวลาในการตอบสนองที่รายงาน
- ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
- ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
- ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
- ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
- ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
- ควรระบุความแตกต่างของสัญญาณเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตช่องเสียบหูฟัง
- ควรจัดการ Callback ที่เสร็จสมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องในเทรดเดียวกันเมื่อใช้งานทั้ง 2 ฝั่ง และป้อนเอาต์พุต Callback ทันทีหลังจาก Callback อินพุต หรือหากจัดการ Callback ในเทรดเดียวกันไม่ได้ ให้ป้อนเอาต์พุต Callback หลังจากป้อน Callback ของอินพุตเพื่อให้แอปพลิเคชันมีเวลาของด้านอินพุตและเอาต์พุตที่สอดคล้องกัน
- ควรลดคว��มแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง
- ควรลดเวลาในการตอบสนองของการแตะ
- ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด ระบบจะดำเนินการดังต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์
android.hardware.audio.pro
ผ่านคลาสandroid.content.pm.PackageManager
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดผ่าน API คิวบัฟเฟอร์ OpenSL ES PCM จะดำเนินการดังต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเดียวกันผ่าน AAudio API ด้วย
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว จะมีผลดังนี้
- [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องไม่เกิน 20 มิลลิวินาทีในเส้นทางช่องเสียบเสียง
- [SR] แนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดเฉพาะอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อกำหนดของชุดหูฟังสำหรับเสียงแบบมีสาย (v1.1)
- เวลาในการตอบสนองแบบไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าในเส้นทางช่องเสียบเสียง
หากอุปกรณ์ไม่มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ช่อง อุปกรณ์จะมีลักษณะดังนี้
- [C-3-1] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องไม่เกิน 20 มิลลิวินาที
- เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าที่พอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ USB การเชื่อมต่อดังกล่าวจะส่งผลดังนี้
- [C-4-1] ต้องใช้คลาสเสียง USB
หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้
- [C-5-1] ต้องรองรับเอาต์พุตแบบสเตอริโอและแชนเนล 8 ช่องที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มเนื้อหาซ้ำ
5.11 จับภาพสำหรับที่ไม่ได้ประมวลผล
Android รองรับการบันทึกเสียงที่ไม่ได้ประมวลผลผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED
ใน OpenSL ES จะสามารถเข้าถึงได้ด้วยค่าระเบียนที่กำหนดล่วงหน้า SL_ANDROID_RECORDING_PRESET_UNPROCESSED
หากการใช้งานอุปกรณ์มีเจตนาที่จะรองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผลและทำให้แอปของบุคคลที่สามใช้งานได้ สิ่งที่จะเกิดขึ้นมีดังนี้
-
[C-1-1] ต้องรายงานการสนับสนุนผ่านพร็อพเพอร์ตี้
android.media.AudioManager
PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED -
[C-1-2] ต้องแสดงลักษณะของแอมพลิจูดกับความถี่แบบราบโดยประมาณในช่วงความถี่กลาง โดยเฉพาะอย่า���ยิ่ง ±10dB ตั้งแต่ 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนแต่ละตัวและที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล
-
[C-1-3] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
-
[C-1-4] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 7000 Hz ถึง 22 KHz เทียบกับช่วงความถี่กลางของไมโครโฟนแต่ละตัวและทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล
-
[C-1-5] ต้องตั้งค่าความไวของอินพุตเสียงให้แหล่งสัญญาณเสียง 1000 Hz ไซนัสอิดัลเล่นที่ 94 dB ระดับความดันเสียง (SPL) ให้ผลตอบสนองด้วย RMS ที่ 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB สำหรับเสียงที่ประมวลผลแบบจุดลอยตัว/2 คู่ เพื่อบันทึกเสียงและตัวอย่างเสียงที่ไม่แม่นยำทุกตัวอย่าง)
-
[C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่ากันของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)
-
[C-1-7] ต้องมีความผิดเพี้ยนแบบฮาร์มอนิก (THD) รวมน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
-
ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางอื่นที่ไม่ใช่ตัวคูณระดับเพื่อลดระดับไปยังช่วงที่ต้องการ กล่าวคือ
- [C-1-8] หากมีการประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม ต้องปิดใช้และไม่มีการหน่วงเวลาหรือเวลาในการตอบสนองเพิ่มเติมให้กับเส้นทางของสั��ญาณได้อย่างมีประสิทธิภาพ
- [C-1-9] ตัวคูณระดับขณะที่อยู่ในเส้นทาง ต้องไม่ทำให้เกิดการหน่วงเวลาหรือเวลาในการตอบสนองแก่เส้นทางของสัญญาณ
การ������ SPL �����้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
แต่ไม่รองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล การตั้งค่าดังกล่าวจะมีผลดังนี้
- [C-2-1] ต้องแสดงผล
null
สำหรับเมธอดAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API เพื่อระบุการขาดการรองรับอย่างเหมาะสม - [SR] ยังคงแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดจำนวนมากสำหรับเส้นทางสัญญาณสำหรับแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล
6. เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องสนับสนุนเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Android ที่มีให้ใน Android SDK
-
- [C-0-2] ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน SDK ของ Android ซึ่งรวมถึง dumpsys
- [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ระบบอุปกรณ์ (batterystats , Dataprocs, Fingerprint, graphicstats, netstats, notifications, procstats) ที่บันทึกผ่าน dumpsys
- [C-0-4] ต้องมี adb daemon ฝั่งอุปกรณ์ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
- [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android มีการสนับสนุนสำหรับ adb ที่ปลอดภัย Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แ��้วที่รู้จัก
-
[C-0-6] ต้องมีกลไกที่ทำให้สามารถเชื่อมต่อ adb จากเครื่องโฮสต์ได้ เช่น
- การใช้งานอุปกรณ์โดยไม่มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วงต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
- ต้องระบุไดรเวอร์สำหรับ Windows 7, 9 และ 10 ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้
-
บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)
- [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุนสำหรับ ddms ควรไม่ทำงานโดยค่าเริ่มต้น แต่ต้องมีการสนับสนุนทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามด้านบน
-
ลิง
- [C-0-8] ต้องรวมเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันสามารถใช้งานได้
-
SysTrace
- [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องไม่มีการใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้ในการเปิด Systrace
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android มีการสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์ในการกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน
การใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
- [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอัปสตรีมของ Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
- [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และต้องจัดเตรียมกลไกในการเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยไม่ต้องมีรายการที่อนุญาตพิเศษ
- อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ชั่วคราวด้วยการซ่อนหรือปิดใช้เมนูเพื่อไม่ให้เสียสมาธิ��นกรณีที่เกิดข้อกังวลด้านความปลอดภัยของผู้ใช้
7. ความเข้ากันได้ของฮาร์ดแวร์
หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์ที่เจาะจงซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่มีการระบุว่าไม่บังคับและการใช้งานอุปกรณ์ไม่มีคอมโพเนนต์ดังกล่าว
- [C-0-2] ยังคงต้องนำเสนอคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK บันทึกไว้) สำหรับ API ของคอมโพเนนต์
- [C-0-3] ต้องมีการนำลักษณะการทำงานของ API มาใช้เป็น "ไม่ดำเนินการ" ด้วยวิธีการที่สมเหตุสมผล
- [C-0-4] เมธอด API ต้องแสดงค่า Null ตาม��ี่ได้รับอนุญาตโดยเอกสาร SDK
- [C-0-5] เมธอด API ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่เอกสาร SDK ไม่อนุญาตค่า Null
- [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
- [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด
getSystemAvailableFeatures()
และhasSystemFeature(String)
ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน
ตัวอย่างทั่วไปของสถานการณ์ที่ข้อกำหนดเหล่านี้มีผลบังคับใช้คือ API โทรศัพท์ ซึ่งแม้แต่ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็จะต้องติดตั้งใช้งาน API เป็นการดำเนินการที่สมเหตุสมผล
7.1 การแสดงผลและกราฟิก
Android มีหน่วยงานที่ปรับเนื้อหาของแอปพลิเคชันและเลย์เอาต์ UI ให้เหมาะกับอุปกรณ์โดยอัตโนมัติเพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะทำงานได้ดีบนการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย อุปกรณ์ต้องติดตั้งใช้งาน API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามรายละ���อียดในส่วนนี้
หน่วยที่อ้างอิงตามข้อกำหนดในส่วนนี้มีการกำหนดไว้ดังนี้
- ขนาดแนวทแยงมุมจริง ระยะห่าง�����็น������������หว่างมุม 2 มุมที่ตรงข้ามกันของส่วนที่สว่างของจอแสดงผล
- จุดต่อนิ้ว (dpi) จำนวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งแบบเส้นตรงเท่ากับ 1" ในตำแหน่งที่ค่า dpi แสดงอยู่ ทั้ง dpi แนวนอนและแนวตั้งจะต้องอยู่ภายในช่วง
- อัตราส่วน อัตราส่วนของพิกเซลด้านยาวกับด้านที่สั้นกว่าของหน้าจอ เช่น การแสดงผลขนาด 480x854 พิกเซลจะเท่ากับ 854/480 = 1.779 หรือโดยประมาณคือ "16:9"
- ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ได้รับการปรับมาตรฐานให้เป็นหน้าจอ 160 dpi ที่คำนวณเป็นพิกเซล = dps * (ความหนาแน่น/160)
7.1.1 การกำหนดค่าหน้าจอ
7.1.1.1 ขนาดหน้าจอ
เฟรมเวิร์ก UI ของ Android รองรับเลย์เอาต์หน้าจอเชิงตรรกะหลายขนาดที่แตกต่างกัน และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout
ด้วย SCREENLAYOUT_SIZE_MASK
และ Configuration.smallestScreenWidthDp
-
[C-0-1] การใช้งานอุปกรณ์ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ
Configuration.screenLayout
ตามที่กำหนดไว้ในเอกสารประกอบ Android SDK กล่าวอย่างเจาะจงคือ การใช้งานอุปกรณ์ "ต้อง" รายงานมิติข้อมูลหน้าจอพิกเซลอิสระ (dp) แบบเชิงตรรกะที่ถูกต้องดังนี้- อุปกรณ์ที่ตั้งค่า
Configuration.uiMode
เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_Wwatch และรายงานขนาดsmall
สําหรับConfiguration.screenLayout
ต้องมีค่าอย่างน้อย 426 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
normal
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 480 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
large
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 640 dp x 480 dp - อุปกรณ์ที่รายงานขนาด
xlarge
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 960 dp x 720 dp
- อุปกรณ์ที่ตั้งค่า
-
[C-0-2] การใช้งานอุปกรณ์ต้องทำตามการรองรับขนาดหน้าจอที่ระบุไว้ของแอปพลิเคชันอย่างถูกต้องผ่านแอตทร��บิวต์ <
supports-screens
> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
7.1.1.2 สัดส่วนภาพหน้าจอ
แม้จะไม่มีข้อจํากัดเกี่ยวกับค่าสัดส่วนการแสดงผลของหน้าจอจริง แต่สัดส่วนภาพของหน้าจอแบบลอจิคัลที่มีการแสดงผลของแอปบุคคลที่สาม ซึ่งอาจมาจากค่าความสูงและความกว้างที่รายงานผ่าน API ของ view.Display
และ API การกำหนดค่า และต้องเป็นไปตามข้อกำหนดต่อไปนี้
-
[C-0-1] การใช้งานอุปกรณ์โดยตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_NORMAL
ต้องมีค่าสัดส่วนภาพระหว่าง 1.3333 (4:3) ถึง 1.86 (ประมาณ 16:9) เว้นแต่แอปจะถือว่าพร้อมยืดขยายนานขึ้นเมื่อเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
android.max_aspect
- แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
- แอปกําหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ
android:MaxAspectRatio
ที่จะจํากัดสัดส่วนภาพที่อนุญาต
- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
-
[C-0-2] การใช้งานอุปกรณ์โดยตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_WATCH
ต้องมีค่าสัดส่วนภาพเป็น 1.0 (1:1)
7.1.1.3 ความหนาแน่นของหน้าจอ
เฟรมเวิร์ก UI ของ Android กำหนดชุดความหนาแน่นของตรรกะมาตรฐานเพื่อช่วยให้นักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรของแอปพลิเคชันได้
-
[C-0-1] โดยค่าเริ่มต้น การใช้งานอุปกรณ์ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android เชิงตรรกะต่อไปนี้เพียง 1 ในความหนาแน่นของเฟรมเวิร์ก Android ต่อไปนี้ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องไม่เปลี่ยนแปลงได้ทุกเมื่อ อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่แตกต่างกันตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดจอแสดงผล) ซึ่งตั้งไว้หลังจากการเปิดเ��รื่องครั้งแรก
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (hdpi)
- 260 dpi (260dpi)
- 280 dpi (280dpi)
- 300 dpi (300dpi)
- 320 dpi (Xhdpi)
- 340 dpi (340dpi)
- 360 dpi (360dpi)
- 400 dpi (400dpi)
- 420 dpi (420dpi)
- 480 dpi (xxhdpi)
- 560 dpi (560dpi)
- 640 dpi (xxxhdpi)
-
การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงตัวเลขความหนาแน่นของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าค่าต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นจริงมากที่สุดส่งผลให้มีขนาดหน้าจอที่เล็กกว่าขนาดหน้าจอที่เข้ากันได้ซึ่งเล็กที่สุด (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดในลำดับถัดไป
หากไม่สามารถปรับขนาดจอแสดงผลของอุปกรณ์ได้ ให้ทำดังนี้
- [C-1-1] ต้องไม่มีการปรับขนาดการแสดงผลให้ใหญ่กว่า 1.5 เท่าของความหนาแน่นดั้งเดิม หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพน้อยกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) ขึ้นอยู่กับว่ากรณีใดจะเกิดขึ้นก่อน
- [C-1-2] ขนาดการแสดงผลจะต��องไม่เล็กกว่า 0.85 เท่าของความหนาแน่นดั้งเดิม
- เราแนะนำให้กำหนดการปรับขนาดของตัวเลือกการแสดงโฆษณาเนทีฟตามขีดจำกัดที่ระบุไว้ด้านบน เพื่อให้สามารถใช้งานและมีขนาดตัวอักษรสอดคล้องกัน
- เล็ก: 0.85 เท่า
- ค่าเริ่มต้น: 1 เท่า (ขนาดโฆษณาแบบดิสเพลย์เนทีฟ)
- ใหญ่: 1.15 เท่า
- ใหญ่กว่า: 1.3 เท่า
- ใหญ่ที่สุด 1.45 เท่า
7.1.2 แสดงเมตริก
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่กำหนดไว้ใน
android.util.DisplayMetrics
API
หากการใช้งานอุปกรณ์ไม่มีหน้าจอหรือเอาต์พุตวิดีโอแบบฝัง ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงานค่าที่สมเหตุสมผลสำหรับเมตริกการแสดงผลทั้งหมดที่กำหนดไว้ใน
android.util.DisplayMetrics
API สำหรับview.Display
เริ่มต้นที่จำลอง
7.1.3 การวางแนวหน้าจอ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (
android.hardware.screen.portrait
และ/หรือandroid.hardware.screen.landscape
) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 แนว ตัวอย่างเช่น อุปกรณ์ที่มีหน้าจอแนวนอนตามการวางแนวที่คงที่ เช่น ทีวีหรือแล็ปท็อป ��ว������ยงาน�����������android.hardware.screen.landscape
- [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ เมื่อใดก็ตามที่ค้นหาผ่าน
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
หรือ API อื่นๆ
หากการใช้งานอุปกรณ์รองรับการวางแนวหน้าจอทั้ง 2 แบบ จะมีผลดังนี้
- [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันสำหรับการวางแนวหน้าจอแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องเป็นไปตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เฉพาะเจาะจง
- [C-1-2] ต้องไม่เปลี่ยนขนาดหน้าจอหรือความหนาแน่นที่รายงานเมื่อเปลี่ยนการวางแนว
- อาจเลือกการวางแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น
7.1.4 การเร่งกราฟิก 2 มิติและ 3 มิติ
7.1.4.1 OpenGL ES
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) ผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด
GLES10.getString()
) และ API แบบเนทีฟอย่างถูกต้อง - [C-0-2] ต้องมีการรองรับสำหรับ API ที่มีการจัดการและ API แบบเนทีฟทั้งหมดที่เกี่ยวข้องสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุให้รองรับ
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
- [SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.0
- ควรรองรับ OpenGL ES 3.1 หรือ 3.2
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดก็ตาม ก็จะเป็นดังนี้
- [C-2-1] ต้องรายงานผ่าน API ที่มีการจัดการของ OpenGL ES และ API แบบเนทีฟ ส่วนขยายอื่นๆ ของ OpenGL ES ที่ได้ใช้ไป และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ระบบไม่รองรับ
- [C-2-2] ต้องรองรับส่วนขยาย
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
และEGL_ANDROID_recordable
- [SR] แนะนำอย่างยิ่งให้สนับสนุน EGL_KHR_partial_update
- ควรรายงานอย่างถูกต้องผ่านเมธอด
getString()
ซึ่งเป็นรูปแบบการบีบอัดพื้นผิวที่ระบบรองรับ ซึ่งโดยทั่วไปจะเป็นเฉพาะผู้ให้บริการ
หากการใช้งานอุปกรณ์ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 ก็จะมีผลดังนี้
- [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้ นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [C-4-1] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์รองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด จะทำสิ่งต่อไปนี้ได้
- [C-5-1] ต้องระบุการสนับสนุนผ่านแฟล็กฟีเจอร์
android.hardware.opengles.aep
หากการใช้งานอุปกรณ์แสดงการรองรับส่วนขยาย EGL_KHR_mutable_render_buffer
ระบบจะดำเนินการต่อไปนี้
- [C-6-1] ต้องรองรับส่วนขยาย
EGL_ANDROID_front_buffer_auto_refresh
ด้วย
7.1.4.2 Vulkan
Android มีการสนับสนุน Vulkan ซึ่งเป็น API ข้ามแพลตฟอร์มแบบโอเวอร์เฮดสำหรับกราฟิก 3 มิติประสิทธิภาพสูง
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.0 หรือ 3.1 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [SR] ขอแนะนำอย่างยิ่งให้รวมการสนับสนุนสำหรับ Vulkan 1.0
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- ควรมีการรองรับ Vulkan 1.0
การติดตั้งใช้งานอุปกรณ์ ซึ่งรวมถึงการรองรับ Vulkan 1.0
- [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องพร้อมแฟล็กฟีเจอร์
android.hardware.vulkan.level
และandroid.hardware.vulkan.version
- [C-1-2] ต้องแจกแจง
VkPhysicalDevice
อย่างน้อย 1 รายการสำหรับ Vulkan Native APIvkEnumeratePhysicalDevices()
- [C-1-3] ต้องใช้ Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับ
VkPhysicalDevice
แต่ละรายการที่แจกแจง - [C-1-4] ต้องแจกแจงเลเยอร์ซึ่งอยู่ในไลบรารีแบบเนทีฟที่ชื่อ
libVkLayer*.so
ในไดเรกทอรีไลบรารีดั้งเดิมของแพ็กเกจแอปพลิเคชันผ่าน API แบบเนทีฟของ VulkanvkEnumerateInstanceLayerProperties()
และvkEnumerateDeviceLayerProperties()
- [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่มาจากไลบรารีนอกแพ็กเกจแอปพลิเคชัน หรือให้วิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะตั้งค่าแอตทริบิวต์
android:debuggable
เป็นtrue
- [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่ส่วนขยายเหล่านั้นสนับสนุนผ่าน API แบบเนทีฟของ Vulkan และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
การติดตั้งใช้งานอุปกรณ์ หากไม่รวมการรองรับ Vulkan 1.0
- [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan ใดๆ (เช่น
android.hardware.vulkan.level
,android.hardware.vulkan.version
) - [C-2-2] ต้องไม่แจกแจง
VkPhysicalDevice
สำหรับ Vulkan Native APIvkEnumeratePhysicalDevices()
7.1.4.3 RenderScript
- [C-0-1] การใช้งานอุปกรณ์ต้องรองรับ Android RenderScript โปรดดูรายละเอียดในเอกสารประกอบเกี่ยวกับ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ
Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือดูผ่านการใช้แท็กไฟล์ Manifest android:hardware Accelerated หรือการเรียก API โดยตรง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาซอฟต์แวร์ขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
- [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์
Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาซอฟต์แวร์ผสานรวมพื้นผิว OpenGL ES ที่เร่งฮาร์ดแวร์ได้โดยตรงเป็นเป้าหมายการแสดงผลในลำดับชั้น UI
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการติดตั้งใช้งานอัปสตรีม Android
7.1.4.5 จอแสดงผลขอบเขตกว้าง
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับการแสดงผลแบบกว้างผ่าน Configuration.isScreenWideColorGamut()
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบส��
- [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
- [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตพื้นที่อย่างน้อย 90% ของ NTSC 1953 ในพื้นที่ CIE 1931 xyY
- [C-1-4] ต้องรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
- [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_colorspace_scrgb_linear
และEGL_GL_colorspace_display_p3
- [SR] แนะนำอย่างยิ่งให้สนับสนุน
GL_EXT_sRGB
ในทางตรงกันข้าม หากอุปกรณ์ไม่รองรับหน้าจอที่มีขอบเขตกว้าง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่ CIE 1931 xyY แม้ว่าไม่ได้ระบุขอบเขตสีของหน้าจอก็ตาม
7.1.5 โหมดความเข้ากันได้กับแอปพลิเคชันเดิม
Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานในโหมด "ปกติ" ที่มีขนาดเทียบเท่าหน้าจอ (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันรุ่นเก่าที่ไม่ได้พัฒนาสำหรับ Android เวอร์ชันเก่าซึ่งมีความเป็นอิสระของขนาดหน้าจอก่อน
7.1.6 เทคโนโลยีหน้าจอ
แพลตฟอร์ม Android มี API ที่ช่วยให้แอปพลิเคชันแสดงผลกราฟิกสมบูรณ์ในจอแสดงผลได้ อุปกรณ์ต้องรองรับ API เหล่านี้ทั้งหมดตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตเป็นการเฉพาะในเอกสารนี้
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับจอแสดงผลที่สามารถแสดงผลกราฟิกสี 16 บิต
- ควรสนับสนุนจอแสดงผลที่รองรับกราฟิกสี 24 บิต
- [C-0-2] ต้องรองรับการแสดงผลที่สามารถแสดงผลภาพเคลื่อนไหว
- [C-0-3] ต้องใช้เทคโนโลยีการแสดงผลที่มีอัตราส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความอดทน 10 ~ 15%
7.1.7 จอแสดงผลสำรอง
Android มีการสนับสนุนจอแสดงผลรองเพื่อเปิดใช้ความสามารถในการแชร์สื่อและ API สำหรับนักพัฒนาซอฟต์แวร์ใ��การเข้าถึงจอแสดงผลภายนอก
หากอุปกรณ์รองรับการแสดงผลภายนอกผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบฝัง จะมีผลดังนี้
- [C-1-1] ต้องใช้บริการของระบบและ API ของ
DisplayManager
ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
7.2 อุปกรณ์อินพุต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีกลไกการป้อนข้อมูล เช่น หน้าจอสัมผัสหรือการนำทางแบบไม่สัมผัส เพื่อนำทางระหว่างองค์ประกอบ UI
7.2.1 แป้นพิมพ์
หากการใช้งานในอุปกรณ์รองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม ก็จะมีผลดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.software.input_methods
- [C-1-2] ต้องติดตั้งใช้งาน
Input Management Framework
อย่างเต็มรูปแบบ - [C-1-3] ต้องมีซอฟต์แวร์แป้นพิมพ์ที่โหลดไว้ล่วงหน้า
การใช้งานอุปกรณ์: [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 คีย์) ควรมีการใช้งานแป้นพิมพ์เสมือนเพิ่มเติม * อาจรวมแป้นพิมพ์ที่เป็นฮาร์ดแวร์
7.2.2 การนำทางแบบไม่สัมผัส
Android มีการสนับสนุนสำหรับ d-pad, แทร็กบอล และล้อเลื่อนเป็นกลไกสำหรับการนำทางแบบไม่สัมผัส
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานค่าที่ถูกต้องสำหรับ android.content.res.Configuration.navigation
หากการติดตั้งใช้งานอุปกรณ์ขาดการนำทางแบบไม่สัมผัส การทำงานจะมีลักษณะดังนี้
- [C-1-1] ต้องมีกลไกของอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสำหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือการจัดการอินพุต การใช้งานโอเพนซอร์ส Android มีกลไกการเลือกที่เหมาะสำหรับการใช้งานกับอุปกรณ์ที่���ม่มีอินพุตการนำทางแบบไม่สัมผัส
7.2.3 ปุ่มนำทาง
ฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ โดยทั่วไปแล้วจะให้บริการผ่านการโต้ตอบกับปุ่มบนตัวเครื่องโดยเฉพาะหรือส่วนที่เฉพาะเจาะจงของหน้าจอสัมผัส สำคัญอย่างยิ่งต่อกระบวนทัศน์การนำทางของ Android ด้วยเหตุนี้
- [C-0-1] ต้องระบุฟังก์ชัน Home
- ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"
หากมีฟังก์ชัน "หน้าแรก" "ล่าสุด" หรือ "ย้อนกลับ" อยู่ ฟังก์ชันดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเพียงครั้งเดียว (เช่น การแตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงรายการใดก็ได้
- [C-1-2] ต้องระบุตัวบ่งชี้ที่ชัดเจนว่าการดำเนินการใดจะทริกเกอร์แต่ละฟังก์ชัน การมีไอคอนที่มองเห็นได้พิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนระหว่างการตั้งค่าตั้งแต่แกะกล่องคือตัวอย่างของ��ัวบ่งชี้ดังกล่าว
การติดตั้งใช้งานอุปกรณ์
- [SR] ขอแนะนำเป็นอย่างยิ่งว่าไม่มีกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการทำงานตั้งแต่ Android 4.0 แล้ว
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน "เมนู" สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงปุ่มการทำงานเพิ่มเติมทุกครั้งที่ป๊อปอัปเมนูการดำเนินการเพิ่มเติมไม่ว่างเปล่าและแถบการทำงานปรากฏขึ้น
- [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการทำงาน แต่อาจแสดงผลป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงด้วยการเลือกฟังก์ชันเมนู
หากการใช้งานอุปกรณ์ไม่มีฟังก์ชัน "เมนู" สำหรับความเข้ากันได้แบบย้อนหลัง ฟังก์ชันจะมีลักษณะดังนี้ * [C-3-1] ต้องทำให้ฟังก์ชันเมนูพร้อมใช้งานสำหรับแอปพลิเคชันเ��ื่อ targetSdkVersion
มีค่าน้อยกว่า 10 รายการ ไม่ว่าจะเป็นปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้ร่วมกับฟังก์ชันการนำทางอื่นๆ
หากการใช้งานอุปกรณ์มีฟังก์ชันผู้ช่วย องค์ประกอบเหล่านี้ [C-4-1] ต้องทำให้ฟังก์ชัน Assist สามารถเข้าถึงได้ด้วยการดำเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงแป้นนำทางอื่นๆ ได้ [SR] แนะนำอย่างยิ่งให้ใช้การกดค้างที่ฟังก์ชัน HOME เพื่อเป็นการโต้ตอบที่กำหนดนี้
หากการนำอุปกรณ์ไปใช้งานใช้ส่วนที่ต่างกันของหน้าจอเพื่อแสดงแป้นการนำทาง แป้นจะทำงานดังนี้
- [C-5-1] แป้นนำทางต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมใช้งานกับแอปพลิเคชันต่างๆ และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่ใช้งานได้ของแอปพลิเคชัน
- [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในหัวข้อ 7.1.1
- [C-5-3] ต้องยึดตามแฟล็กที่แอปตั้งค่าผ่านเมธอด
View.setSystemUiVisibility()
API เพื่อให้ส่วนเฉพาะของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ถูกซ่อนอย่างเหมาะสมตามที่ระบุไว้ใน SDK
7.2.4 อินพุตหน้าจอสัมผัส
Android มีการสนับสนุนระบบอินพุต Point หลากหลายประเภท เช่น หน้าจอสัมผัส ทัชแพด และอุปกรณ์ป้อนข้อมูลด้วยการสัมผัสปลอม การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลที่ทำให้ผู้ใช้รู้สึกว่ามีการควบคุมสิ่งต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้กำลังแตะหน้าจอโดยตรง ระบบจึงไม่ต้องใช้เงินช่วยเหลือเพิ่มเติมในการระบุวัตถุที่กำลังถูกดัดแปลง
การติดตั้งใช้งานอุปกรณ์
- ควรมีระบบป้อนข้อมูลตัวชี้บางประเภท (แบบเมาส์หรือการแตะ)
- ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์
หากอุปกรณ์มีหน้าจอสัมผัส (แบบแตะครั้งเดียวหรือดีกว่า) จะมีฟีเจอร์ดังต่อไปนี้
- [C-1-1] ต้องรายงาน
TOUCHSCREEN_FINGER
สำหรับช่อง API ของConfiguration.touchscreen
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.touchscreen
และandroid.hardware.faketouch
หากการใช้งานอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะมากกว่า 1 ครั้ง การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องรายงานแฟล็กฟีเจอร์ที่เหมาะสม
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
ที่สอดคล้องกับประเภทของหน้าจอสัมผัสที่เจาะจงในอุปกรณ์
หากการใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส (และใช้อุปกรณ์ตัวชี้เท่านั้น) และเป็นไปตามข้อกำหนดการแตะปลอมในส่วนที่ 7.2.5 เงื่อนไขเหล่านี้จะมีลักษณะดังนี้
- [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ใดๆ ที่ขึ้นต้นด้วย
android.hardware.touchscreen
และต้องรายงานเฉพาะandroid.hardware.faketouch
7.2.5 การป้อนข้อมูลด้วยการสัมผัสปลอม
อินเทอร์เฟซแบบ Fake Touch มีระบบป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่บังคับเคอร์เซอร์บนหน้าจอให้อยู่ใกล้การแตะ แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วค่อยคลิก อุปกรณ์อินพุตจํานวนมาก เช่น เมาส์ แทร็กแพด เมาส์แบบลมแบบ Gyro ตัวชี้ ไจโร จอยสติ๊ก และแทร็กแพดแบบมัลติทัชรองรับการโต้ตอบด้วยการสัมผัสปลอมได้ Android มีฟีเจอร์ android.hardware.faketouch อย่างต่อเนื่อง ซึ่งสอดคล้องกับอุปกรณ์อินพุตที่ไม่ใช่ระบบสัมผัส (ใช้ตัวชี้) ความแม่นยำสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจำลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการสนับสนุนท่าทางสัมผัสพื้นฐาน) และบ่งชี้ว่าอุปกรณ์รองรับชุดย่อยของฟังก์ชันการทำงานของหน้าจอสัมผัสที่จำลองขึ้นมา
หากการใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่รวมระบบอินพุตตัวชี้อื่นๆ ที่ต้องการใช้ อุปกรณ์ดังกล่าวจะดำเนินการดังต่อไปนี้
- ควรประกาศการรองรับ Flag ฟีเจอร์
android.hardware.faketouch
หากการ���ิดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรายงานตำแหน่งหน้าจอ X และ Y แบบสัมบูรณ์ของตำแหน่งตัวชี้ และแสดงตัวชี้แบบภาพบนหน้าจอ
- [C-1-2] ต้องรายงานเหตุการณ์การแตะที่มีโค้ดการดำเนินการซึ่งระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นบนตัวชี้ที่ขึ้นหรือลงบนหน้าจอ
- [C-1-3] ต้องรองรับการชี้ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จำลองการแตะบนวัตถุบนหน้าจอได้
- [C-1-4] ต้องรองรับเคอร์เซอร์ลง ชี้ขึ้น ชี้ลง แล้วชี้ขึ้นที่ตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะสองครั้งบนวัตถุบนหน้าจอได้
- [C-1-5] ต้องรองรับการชี้ลงที่จุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดใดก็ได้ที่กำหนดเองบนหน้าจอ ตามด้วยตัวชี้ขึ้น ซึ่งช่วยให้ผู้ใช้เลียนแบบการลากด้วยการแตะได้
- [C-1-6] ต้องรองรับการชี้ลง จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นตัวชี้ขึ้นบนหน้าจอซึ่งทำให้ผู้ใช้สามารถขว้างวัตถุบนหน้าจอได้
- [C-1-7] ต้องรายงาน
TOUCHSCREEN_NOTOUCH
สำหรับช่อง API ของConfiguration.touchscreen
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.distinct
ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องประกาศการรองรับ
android.hardware.faketouch
- [C-2-2] ต้องรองรับการติดตามที่ไม่ซ้ำกันของอินพุตตั���ชี้อิสระตั้งแต่ 2 รายการขึ้นไป
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.jazzhand
ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องประกาศการรองรับ
android.hardware.faketouch
- [C-3-2] ต้องรองรับการติดตามที่ไม่ซ้ำกัน 5 (การติดตามการใช้นิ้วมือ) หรือมากกว่านั้นอินพุตของตัวชี้แบบแยกกันโดยสมบูรณ์
7.2.6 รองรับเกมคอนโทรลเลอร์
7.2.6.1 การแมปปุ่ม
หากการใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.hardware.gamepad
สถานะของอุปกรณ์ดังกล่าว: [C-1-1] ต้องมีการฝังตัวควบคุมหรือจัดส่งพร้อมกับตัวควบคุมแยกต่างหากในช่อง ซึ่งหมายความว่าให้ป้อนเหตุการณ์ทั้งหมดที่ระบุไว้ในตารางด้านล่าง [C-1-2] ต้องมีความสามารถในการแมปเหตุการณ์ HID กับค่าคงที่ view.InputEvent
ของ Android ที่เชื่อมโยงดังที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งานอัปสตรีม Android รวมถึงการใช้งานสำหรับตัวควบคุมเกมที่เป็��ไปตามข้อกำหนดนี้
Button | การใช้งาน HID2 | ปุ่ม Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
ข1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
x1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
ปี1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad ขึ้น1 D-pad ลง1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad ซ้าย1 D-pad ขวา1 |
0x01 0x00393 | AXIS_HAT_X4 |
ปุ่มไหล่ซ้าย1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
ปุ่มไหล่ขวา1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
คลิกสติ๊กซ้าย1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
คลิกสติ๊กขวา1 | 0x09 0x000f | KEYCODE_BUTTON_THUMBR (107) |
หน้าแรก1 | 0x0c 0x0223 | KEYCODE_หน้าแรก (3) |
กลับ1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
KeyEvent 1 รายการ
2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน Game pad CA (0x01 0x0005)
3 การใช้งานนี้ต้องมีตรรกะขั้นต่ำเป็น 0, ค่าสูงสุดเชิงตรรกะอยู่ที่ 7, ค่าต่ำสุดทางกายภาพเป็น 0, สูงสุดทางกายภาพเป็น 315, หน่วยเป็นองศา และขนาดรายงานเป็น 4 ค่าตรรกะกำหนดเป็นการหมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง เช่น ค่าตรรกะ 0 หมายถึงไม่มีการหมุนและปุ่มขึ้น ส่วนค่าตรรกะ 1 คือการหมุน 45 องศา ทั้งแป้นขึ้นและแป้นซ้ายที่กดอยู่
การควบคุมแบบแอนะล็อก1 | การใช้ HID | ปุ่ม Android |
---|---|---|
ทริกเกอร์ซ้าย | 0x02 0x00C5 | AXIS_LTRIGGER |
ทริกเกอร์ด้านขวา | 0x02 0x00C4 | AXIS_RTRIGGER |
จอยสติ๊กด้านซ้าย |
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
จอยสติ๊กด้านขวา |
0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
เหตุการณ์การเคลื่อนไหว 1 รายการ
7.2.7 รีโมตคอนโทรล
โปรดดูส่วนที่ 2.3.1 สำหรับข้อกำหนดเฉพาะอุ��กรณ์
7.3 เซ็นเซอร์
หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์ที่เฉพาะเจาะจงซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบ Android SDK และเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส
android.content.pm.PackageManager
- [C-0-2] ต้องส่งรายการเซ็นเซอร์ที่รองรับที่แม่นยำผ่าน
SensorManager.getSensorList()
และใช้วิธีการที่คล้ายกัน - [C-0-3] ต้องทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น การส่งคืน
true
หรือfalse
ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียกใช้ Listener เซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง ฯลฯ)
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม การติดตั้งอุปกรณ์เหล่านั้นจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมดโดยใช้ค่าหน่วยเมตริกสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสาร Android SDK
- [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที
- 2 * sample_time สำหรับเคสของเซ็นเซอร์ที่สตรีมโดยมีเวลาในการตอบสนองขั้นต่ำที่ต้องการคือ 5 ms + 2 * sample_time เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
- [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์รายการแรกภายใน 400 มิลลิวินาที + 2 * ตัวอย่าง_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำเป็น 0 ได้
-
[SR] ควรรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK โดยแสดงเวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano() เราขอแนะนำอุปกรณ์ Android ทั้งใหม่และใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจเป็นคอมโพเนนต์ "จำเป็น" ข้อผิดพลาดในการซิงค์ควรต่ำกว่า 100 มิลลิวินาที
-
[C-1-4] สำหรับ API ที่ระบุโดยเอกสาร Android SDK ให้เป็นเซ็นเซอร์แบบต่อเนื่อง การใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมี Jitter ต่ำกว่า 3% โดย Jitter เป็นค่าเบี่ยงเบนมาตรฐานของผลต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่เกิดต่อเนื่องกัน
-
[C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือเริ่มทำงานจากสถานะระงับ
- เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินกว่าผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว
รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทำงานที่ระบุในเอกสารของ Android SDK และเอกสารโอเพนซอร์สของ Android ในเซ็นเซอร์จะถือว่าเชื่อถือได้
เซ็นเซอร์บางประเภทเป็นวัสดุผสม ซึ่งหมายความว่าข้อมูลเหล่านั้นอาจมาจากข้อมูลที่เซ็นเซอร์อื่นอย่างน้อย 1 รายการให้ไว้ (ตัวอย่างเช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์การเร่งความเร็วเชิงเส้น)
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เซ็นเซอร์ประเภทเหล่านี้ เมื่อมีเซ็นเซอร์ทางกายภาพที่จำเป็นก่อน ตามที่อธิบายไว้ในประเภทเซ็นเซอร์
หากการใช้งานอุปกรณ์มีเซ็นเซอร์คอมโพสิต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์แบบผสม
7.3.1 ตัวตรวจวัดความเร่ง
- การใช้งานอุปกรณ์ควรมีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่ง��ี่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
- [C-1-2] ต้องใช้����ะรายงานเซ็นเซอร์
TYPE_ACCELEROMETER
- [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
- [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้ถึงสี่เท่าของแรงโน้มถ่วง(4g) หรือมากกว่าบนแกนใดก็ได้
- [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
- [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 เมตร/วินาที โดยค่าเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีในอัตราการสุ่มตัวอย่างที่เร็วที่สุด
- [SR] แนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_SIGNIFICANT_MOTION
- [SR] ขอแนะนําอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_ACCELEROMETER_UNCALIBRATED
หากมีการปรับเทียบตัวตรวจวัดความเร่งออนไลน์ - ควรใช้เซ็นเซอร์ผสม
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
ตามที่อธิบายไว้ในเอกสาร Android SDK - ควรรายงานเหตุการณ์สูงสุด 200 Hz
- ควรมีความละเอียดอย่างน้อย 16 บิต
- ควรมีการปรับเทียบขณะใช้งานหากลักษณะมีการเปลี่ยนแปลงตลอดวงจรและการชดเชย รวมถึงคงพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- ควรมีการชดเชยอุณหภูมิ
- ควรใช้เซ็นเซอร์
TYPE_ACCELEROMETER_UNCALIBRATED
ด้วย
หากใช้อุปกรณ์รวมถึงตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
, TYPE_STEP_COUNTER
จะมีการใช้งานดังนี้
- [C-2-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
- คุณภาพควรต่ำกว่า 2 mW และ 0.5 mW เมื่ออุปกรณ์อยู่ในสถานะแบบไดนามิกหรือคงที่
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์วัดการหมุน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- ควรใช้เซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_GAME_ROTATION_VECTOR
สำหรับอุปกรณ์ Android ทั้งเก่าและใหม่
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์เครื่องวัดการหมุน และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นขอ���สนามแม่เหล็ก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
7.3.2 เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
- การใช้งานอุปกรณ์ควรมีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 3 แกน
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน การทำงานดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD
- [C-1-2] ต้องรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์สูงสุด 50 Hz เป็นอย่างน้อย
- [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
- [C-1-4] ต้องวัดค่าระหว่าง -900 μT ถึง +900 μT บนแกนแต่ละแกนได้ก่อนความอิ่มตัว
- [C-1-5] ต้องมีค่าออฟเซ็ตเหล็กแข็งต่ำกว่า 700 μT และควรมีค่าต่ำกว่า 200 μT โดยวางเครื่องวัดค่าความเข้มข้นจากสนามแม่เหล็กแบบไดนามิก (กระแสไฟฟ้าเหนี่ยวนำ) และคงที่ (เหนี่ยวนำแม่เหล็ก)
- [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 μT
- [C-1-7] ต้องรองรับการปรับเทียบออนไลน์และการชดเชยอคติจากเหล็กแข็ง และเก็บพารามิเตอร์การชดเชยไว้ระหว่างรีบูตอุปกรณ์
- [C-1-8] ต้องใช้การชดเชยเหล็กอ่อน ปรับเทียบได้ขณะใช้งานหรือขณะผลิตอุปกรณ์
- [C-1-9] ต้องมีค่าเบี่ยงเบนมาตรฐาน โดยคำนวณตามแกนต่อแกนจากตัวอย่างที่เก็บรวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด ไม่เกิน 1.5 μT และควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 μT
- ควรใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD_UNCALIBRATED
สำหรับอุปกรณ์ Android ทั้งเก่าและใหม่
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์วัดการหมุน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน ตัวตรวจวัดความเร่ง ระบบจะดำเนินการต่อไปนี้
- อาจใช้เซ็นเซอร์
TYPE_GEOMAGNETIC_ROTATION_VECTOR
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน ตัวตรวจวัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR
ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
- ควรสิ้นเปลืองพลังงานไม่เกิน 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดแบบกลุ่มที่ 10 Hz
7.3.3 GPS
การติดตั้งใช้งานอุปกรณ์
- ควรมีตัวรับสัญญาณ GPS/GNSS
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
อุปกรณ์เหล่า��ั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งในอัตราอย่างน้อย 1 Hz เมื่อขอผ่าน
LocationManager#requestLocationUpdate
- [C-1-2] ต้องสามารถระบุตำแหน่งในสภาพโล่ง (สัญญาณแรง, เส้นทางหลายทางที่ไม่มีประโยชน์, HDOP < 2) ภายใน 10 วินาที (เวลาที่รวดเร็วในการแก้ไขครั้งแรก) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วอินเทอร์เน็ต 0.5 Mbps ขึ้นไป โดยทั่วไปข้อกำหนดนี้จะเป็นไปตามการใช้เทคนิค GPS/GNSS แบบมีการสนับสนุนหรือที่คาดการณ์ไว้เพื่อลดเวลาล็อกของ GPS/GNSS ให้เหลือน้อยที่สุด (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และ Ephemeris/Clock ดาวเทียม)
- [SR] หลังจากคำนวณตำแหน่งแล้ว ขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์สามารถระบุตำแหน่งได้ในพื้นที่เปิดโล่ง ภายใน 10 วินาทีเมื่อเริ่มต้นคำขอตำแหน่งใหม่ ภายในไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอในภายหลังโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากการเปิดเครื่อง
-
ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร็วน้อยกว่า 1 เมตรต่อวินาทีของความเร่งยกกำลังสอง
- [C-1-3] ต้องสามารถระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วไม่เกิน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
- [C-1-4] ต้องติดตามและรายงานในเวลาเดียวกันผ่าน
GnssStatus.Callback
ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว - ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายกลุ่มดาวได้พร้อมกัน (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อยหนึ่งดาว)
- [C-1-5] ต้องรายงานการสร้างเทคโนโลยี GNSS ผ่าน API การทดสอบ "getGnssYearOf���าร์ดแวร์"
- [SR] ให้เอาต์พุตตำแหน่ง GPS/GNSS ตามปกติต่อไปในระหว่างการโทรออกฉุกเฉิน
- [SR] รายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ดังที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
- [SR] รายงาน AGC และความถี่ของการวัด GNSS
- [SR] รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS แต่ละตำแหน่ง
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเพิ่มเติมที่จำเป็นสำหรับอุปกรณ์ที่รายงานปี "2016" หรือ "2017" ผ่าน Test API ให้ได้มากที่สุดเท่าที่จะเป็นไปได้
LocationManager.getGnssYearOfHardware()
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
และรายงาน LocationManager.getGnssYearOfHardware()
Test API ในปี "2016" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-2-1] ต้องรายงานการวัดด้วย GPS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [C-2-2] ต้องรายงานอัตราจำลองของ GPS และช่วงจำลองที่ ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่โดยมีความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีหรือกำลังสอง ก็เพียงพอที่จะคำนวณตำแหน่งภายในระยะ 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
และรายงาน LocationManager.getGnssYearOfHardware()
Test API ในปี "2017" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-3-1] ต้องให้เอาต์พุตตำแหน่ง GPS/GNSS ตามปกติต่อไปในระหว่างการโทรออกฉุกเฉิน
- [C-3-2] ต้องรายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ตามรายงานในข้อความ GnssStatus) ยกเว้น SBAS
- [C-3-3] ต้องรายงาน AGC และความถี่ของการวัด GNSS
- [C-3-4] ต้องรายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS แต่ละตำแหน่ง
7.3.4 เครื่องวัดการหมุน
การติดตั้งใช้งานอุปกรณ์
- ควรมีเครื่องวัดการหมุน (เซ็นเซอร์การเปลี่ยนแปลงเชิงมุม)
- ไม่ควรรวมเซ็นเซอร์เครื่องวัดการหมุน เว้นแต่จะมีตัวตรวจวัดความเร่งแบบ 3 แกนให้มาด้วย
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุน ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
- [C-1-2] ต้องใช้เซ็นเซอร์
TYPE_GYROSCOPE
และคว��ใช้เซ็นเซอร์TYPE_GYROSCOPE_UNCALIBRATED
ด้วย - [C-1-3] ต้องสามารถวัดการวางแนวที่เปลี่ยนไปได้สูงสุด 1,000 องศาต่อวินาที
- [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป และควรมีความละเอียด 16 บิตขึ้นไป
- [C-1-5] ต้องมีการชดเชยอุณหภูมิ
- [C-1-6] ต้องมีการปรับเทียบและชดเชยขณะใช้งาน และเก็บพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- [C-1-7] ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ค่าความแปรปรวนต่อ Hz หรือ rad^2 / s) ค่าความแปรปรวนจะแตกต่างกันไปตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดโดยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโรด้วยอัตราการสุ่มตัวอย่าง 1 Hz ค่าไม่ควรมากกว่า 1e-7 rad^2/s^2
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
สำหรับอุปกรณ์ Android ทั้งเก่าและใหม่ - [SR] ขอแนะนําอย่างยิ่งให้ใช้ข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์หยุดอยู่กับที่ที่อุณหภูมิห้อง
- ควรรายงานเหตุการณ์สูงสุด 200 Hz
หากการติดตั้งใช้งานอุปกรณ์ประกอบด้วยเครื่องวัดการหมุน เซ็นเซอร์ของตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากอุปกรณ์มีเครื่องวัดการหมุนและเซ็นเซอร์ตัวตรวจวัดความเร่ง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_GAME_ROTATION_VECTOR
สำหรับอุปกรณ์ Android ทั้งเก่าและใหม่ - ควรใช้เซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
7.3.5 บารอมิเตอร์
- การใช้งานอุปกรณ์ควรมีบารอมิเตอร์ (เซ็นเซอร์ความกดอากาศแวดล้อม)
หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ ฟังก์ชันเหล่านี้จะมีผลดังนี้
- [C-1-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_PRESSURE
- [C-1-2] ต้องสามารถส่งเหตุการณ์ในระดับ 5 Hz หรือสูงกว่า
- [C-1-3] ต้องมีการชดเชยอุณหภูมิ
- [SR] แนะนําอย่างยิ่งให้สามารถรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa
- ควรมีความแม่นยำสัมบูรณ์ที่ 1hPa
- ควรมีความแม่นยำสัมพัทธ์ที่ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความถูกต้อง��ม่นยำ ~1m มากกว่า ~200m การเปลี่ยนแปลงที่ระดับน้ำทะเล)
7.3.6 เทอร์โมมิเตอร์
การใช้งานอุปกรณ์: อาจมีเทอร์โมมิเตอร์โดยรอบ (เซ็นเซอร์อุณหภูมิ) อาจ แต่ไม่ควรรวมเซ็นเซอร์อุณหภูมิของ CPU
หากอุปกรณ์มีเทอร์โมมิเตอร์วัดอุณหภูมิแวดล้อม (เซ็นเซอร์อุณหภูมิ) สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องระบุเป็น
SENSOR_TYPE_AMBIENT_TEMPERATURE
และต้องวัดอุณหภูมิแวดล้อม (ห้อง/ห้องโดยสาร) ที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส - [C-1-2] ต้องระบุเป็น
SENSOR_TYPE_TEMPERATURE
- [C-1-3] ต้องวัดอุณหภูมิของ CPU ของอุปกรณ์
- [C-1-4] ต้องไม่วัดอุณหภูมิอื่นใด
โปรดทราบว่ามีการเลิกใช้งานเซ็นเซอร์ประเภท SENSOR_TYPE_TEMPERATURE
ใน Android 4.0 แล้ว
7.3.7 โฟโต้มิเตอร์
- การใช้งานอุปกรณ์อาจมีโฟโต้มิเตอร์ (เซ็นเซอร์แสงแวดล้อม)
7.3.8 พร็อกซิมิตีเซ็นเซอร์
- การใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์
หากอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องวัดระยะใกล้/ไกลของวัตถุในทิศทางเดียวกันกับหน้าจอ กล่าวคือ พร็อกซิมิตีเซ็นเซอร์จะต้องอยู่ในแนวสำหรับตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากจุดประสงค์หลักของเซ็นเซอร์ประเภทนี้คือเพื่อตรวจหาโทรศัพท์ที่ผู้ใช้ใช้งาน หากอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวแบบอื่นๆ ด้วย จะต้องไม่สามารถเข้าถึงได้ผ่านทาง API นี้
- [C-1-2] ต้องมีความแม่นยำอย่างน้อย 1 บิต
7.3.9 เซ็นเซอร์ความแม่นยำสูง
หากการนำอุปกรณ์ไปใช้งานมีชุดเซ็นเซอร์ที่มีคุณภาพสูงกว่าตามที่กำหนดไว้ในส่วนนี้ และทำให้พร้อมใช้งานกับแอปของบุคคลที่สามได้ เซ็นเซอร์เหล่านี้จะทำสิ่งต่อไปนี้
- [C-1-1] ต้องระบุความสามารถผ่านแฟล็กฟีเจอร์
android.hardware.sensor.hifi_sensors
การใช้งานอุปกรณ์จะประกาศ android.hardware.sensor.hifi_sensors
ดังต่อไปนี้
-
[C-2-1] ต้องมีเซ็นเซอร์
TYPE_ACCELEROMETER
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -8 ก. ถึง +8 ก. เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 1024 LSB/G
- ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 400 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงกว่า 400 uG/Cellular คน����่นๆ
- ต้อง���ช้����ป����บ��ี่ไม่���ช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
- ควรมีความเสถียรของเบี่ยงเบนสัญญาณรบกวนแบบอยู่กับที่ที่ \<15 μg เครื่องหมาย การแปลแบบอินเทอร์แอ็กทีฟจากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก. / °C
- ควรมีระดับความไม่เป็นเชิงเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิสูงสุด ≤ 0.03%/C°
- ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ
-
[C-2-2] ต้องมี
TYPE_ACCELEROMETER_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_ACCELEROMETER
-
[C-2-3] ต้องมีเซ็นเซอร์
TYPE_GYROSCOPE
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
- ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 400 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
- ควรมีความเสถียรของเบี่ยงเบนแบบอยู่กับที่ที่ < 0.0002 °/s {/9}Hz จากชุดข้อมูลแบบคงที่ตลอด 24 ชั่วโมง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
- ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
- ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
- ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
- ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ
- ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่
-
[C-2-4] ต้องมี
TYPE_GYROSCOPE_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GYROSCOPE
- [C-2-5] ต้องมีเซ็นเซอร์
TYPE_GEOMAGNETIC_FIELD
ซึ่งมีคุณสมบัติดังนี้- ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 uT เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
- ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนการวัดที่ไม่ม��กกว่า 0.5 uT
- [C-2-6] ต้องมี
TYPE_MAGNETIC_FIELD_UNCALIBRATED
ที่มีข้อกําหนดด้านคุณภาพเดียวกันกับTYPE_GEOMAGNETIC_FIELD
และมีคุณสมบัติต่อไปนี้- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
- ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ
- [C-2-7] ต้องมีเซ็นเซอร์
TYPE_PRESSURE
ซึ่งมีคุณสมบัติดังนี้- ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
- ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 2 mW
- [C-2-8] ต้องมีเซ็นเซอร์
TYPE_GAME_ROTATION_VECTOR
ซึ่งมีคุณสมบัติดังนี้- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
- [C-2-9] ต้องมีเซ็นเซอร์
TYPE_SIGNIFICANT_MOTION
ซึ่งมีคุณสมบัติดังนี้- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-10] ต้องมีเซ็นเซอร์
TYPE_STEP_DETECTOR
ซึ่งมีคุณสมบัติดังนี้- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์เซ็นเซอร์
- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปก��ณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
- [C-2-11] ต้องมีเซ็นเซอร์
TYPE_STEP_COUNTER
ซึ่งมีคุณสมบัติดังนี้- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-12] ต้องมีเซ็นเซอร์
TILT_DETECTOR
ซึ่งมีคุณสมบัติดังนี้- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-13] การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่ง เซ็นเซอร์เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กต้องอยู่ห่างจากกันไม่เกิน 2.5 มิลลิวินาที
- [C-2-14] ต้องมีการประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุนอยู่ในเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดภายใน 1 มิลลิวินาที
- [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์ทางกายภาพใดๆ ข้างต้นไปยังแอปพลิเคชัน
- [C-2-16] ต้องไม่มีปริมาณการใช้พลังงานสูงกว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 2.0 mW เมื่ออุปกรณ์มีการเคลื่อนไหวเมื่อเปิดใช้เซ็นเซอร์ใดๆ ต่อไปนี้ร่วมกัน
-
SENSOR_TYPE_SIGNIFICANT_MOTION
-
SENSOR_TYPE_STEP_DETECTOR
-
SENSOR_TYPE_STEP_COUNTER
-
SENSOR_TILT_DETECTORS
-
- [C-2-17] อาจมีเซ็นเซอร์
TYPE_PROXIMITY
แต่หากมี ต้องมีความสามารถในการบัฟเฟอร์ขั้นต่ำที่ 100 เหตุการณ์เซ็นเซอร์
โปรดทราบว่าข้อกำหนดด้านการใช้พลังงานทั้งหมดในส่วนนี้ไม่รวมถึงการใช้พลังงานของตัวประมวลผลแอปพลิเคชัน โดยรวมถึงกำลังไฟฟ้าที่โซ่เซ็นเซอร์ทั้งโซ่ใช้ ได้แก่ เซ็นเซอร์ วงจรสนับสนุน ระบบประมวลผลเซ็นเซอร์เฉพาะใดๆ เป็นต้น
หากการติดตั้งใช้งานอุ��กรณ์มีการรองรับเซ็นเซอร์โดยตรง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและระดับอัตราในรายงานโดยตรงอย่างถูกต้องผ่าน API ของ
isDirectChannelTypeSupported
และgetHighestDirectReportRateLevel
- [C-3-2] ต้องรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์อย่างน้อย 1 จาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศการรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์
-
TYPE_HARDWARE_BUFFER
-
TYPE_MEMORY_FILE
- ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุกระบบ) ในประเภทต่อไปนี้
-
TYPE_ACCELEROMETER
-
TYPE_ACCELEROMETER_UNCALIBRATED
-
TYPE_GYROSCOPE
-
TYPE_GYROSCOPE_UNCALIBRATED
-
TYPE_MAGNETIC_FIELD
-
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10 เซ็นเซอร์ลายนิ้วมือ
หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรมีเซ็นเซอร์ลายนิ้วมือ
หากการนำอุปกรณ์ไปใช้มีเซ็นเซอร์ลายนิ้วมือและทำให้เซ็นเซอร์พร้อมใช้งานสำหรับแอปของบุคคลที่สาม การตั้งค่าดังกล่าวจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์
android.hardware.fingerprint
- [C-1-2] ต้องใช้ corresponding API อย่างสมบูรณ์ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
- [C-1-3] ต้องมีอัตราการยอมรับที่เป็นเท็จไม่เกิน 0.002%
- [C-1-4] ต้องพยายามจำกัดจำนวนอัตราอย่างน้อย 30 วินาทีหลังจากการทดลองตรวจสอบลายนิ้วมือที่ไม่ถูกต้อง 5 ครั้ง
- [C-1-5] ต้องมีการใช้งานคีย์สโตร์ที่ใช้ฮาร์ดแวร์ และดำเนินการจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
- [C-1-6] ต้องมีข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ���แบบเข้ารหัสลับ เพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอกระบบ Trusted Execution Environment (TEE) ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานบ����ว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
- [C-1-7] ต้องป้องกันไม่ให้มีการเพิ่มลายนิ้วมือโดยไม่สร้างเครือข่ายความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโปรเจ็กต์โอเพนซอร์สของ Android จะเป็นกลไกในเฟรมเวิร์ก
- [C-1-8] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างลายนิ้วมือแต่ละรายการ
- [C-1-9] ต้องทำตามแฟล็ก DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
- [C-1-10] ต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้นเมื่ออัปเกรดจากเวอร์ชันที่เก่ากว่า Android 6.0 หรือนำข้อมูลลายนิ้วมือออกอย่างปลอดภัย
- [SR] แนะนําอย่างยิ่งให้มีอัตราการปฏิเสธเท็จน้อยกว่า 10% ตามที่วัดในอุปกรณ์
- [SR] แนะนำอย่างยิ่งให้เวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อเซ็นเซอร์ลายนิ้วมือถูกแตะจนกระทั่งหน้าจอปลดล็อกสำหรับนิ้วเดียวที่ลงทะเบียน
- ควรใช้ไอคอนลายนิ้วมือของ Android ที่ให้ไว้ในโครงการโอเพนซอร์สของ Android
7.3.11 เซ็นเซอร์สำหรับ Android Automotive เท่านั้น
เซ็นเซอร์สําหรับยานยนต์ได้รับการกำหนดไว้ในandroid.car.CarSensorManager API
7.3.11.1 เฟืองปัจจุบัน
โปรดดูส่วนที่ 2.5.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3.11.2 โหมดกลางวัน/กลางคืน
โปรดดูส่วนที่ 2.5.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3.11.3 สถานะการขับรถ
โปรดดูส่วนที่ 2.5.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3.11.4 ความเร็วของล้อ
โปรดดูส่วนที่ 2.5.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3.12 เซ็นเซอร์ท่าทาง
การติดตั้งใช้งานอุปกรณ์
- อาจรองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา
หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์ตรวจจับการเคลื่อนไหวที่มีการเคลื่อนไหว 6 องศาอิสระ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_POSE_6DOF
- [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว
7.4 การ��ชื่อมต่อข้อมูล
7.4.1 โทรศัพท์
"โทรศัพท์" ตามที่ใช้โดย API ของ Android และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรออกและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA แม้ว่าการโทรด้วยเสียงเหล่านี้อาจมีหรือไม่มีการเปลี่ยนแพ็กเก็ต แต่ก็มีขึ้นเพื่อวัตถุประสงค์ของ Android ที่ถือว่าไม่เกี่ยวข้องกับการเชื่อมต่อข้อมูลใดๆ ที่อาจใช้งานโดยใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันและ API ด้าน "โทรศัพท์" ของ Android หมายถึงโทรศัพท์และ SMS โดยเฉพาะ ตัวอย่างเช่น การใช้งานอุปกรณ์ที่ไม่สามารถโทรออกหรือส่ง/รับข้อความ SMS จะไม่ถือว่าเป็นอุปกรณ์โทรศัพท์ ไม่ว่าอุปกรณ์จะใช้เครือข่ายมือถือในการเชื่อมต่อข้อมูลหรือไม่ก็ตาม
- Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์สำหรับโทรศัพท์ กล่าวคือ Android เข้ากันได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์
หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony
และแฟล็กฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี - [C-1-2] ต้องใช้การสนับสนุน API อย่างสมบูรณ์สำหรับเทคโนโลยีนั้น
หากการติดตั้งใช้งานอุปกรณ์ไม่รวมฮาร์ดแวร์สำหรับโทรศัพท์ การติดตั้งจะมีผลดังนี้
- [C-2-1] ต้องใช้ API เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ
7.4.1.1 ความเข้ากันได้ของการบล็อกหมายเลข
การนำอุปกรณ์ไปใช้งานรายงาน android.hardware.telephony feature
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องมีการสนับสนุนการบล็อกหมายเลข
- [C-1-2] ต้องใช้
BlockedNumberContract
และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ SDK - [C-1-3] ต้องบล็อกการโทรและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยไม่โต้ตอบกับแอป ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
- [C-1-4] ต้องไม่เขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับสายที่ถูกบล็อก
- [C-1-5] ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่บล็อก
- [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งเปิดด้วย Intent ที่เมธอด
TelecomManager.createManageBlockedNumbersIntent()
แสดงผล - [C-1-7] ต้องไม่อนุญาตให้ผู้ใช้รองดูหรือแก้ไขหมายเลขที่ถูกบล็อกในอุปกรณ์เนื่องจากแพลตฟอร์ม Android จะถือว่าผู้ใช้หลักควบคุมบริการโทรศัพท์ได้อย่างเต็มรูปแบบในอุปกรณ์ เช่น การใช้อินสแตนซ์เดียว ต้องซ่อน UI ที่เกี่ยวข้องกับการบล็อกทั้งหมดสำหรับผู้ใช้รอง และรายการที่ถูกบล็อกต้องยังคงทำงานตามเดิม
- ควรย้ายข้อมูลหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0
7.4.2 IEEE 802.11 (Wi-Fi)
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับ 802.11 อย่างน้อย 1 รูปแบบ
หากการนำอุปกรณ์ไปใช้งานมีการรองรับ 802.11 และแสดงฟังก์ชันดังกล่าวแก่แอปพลิเคชันของบุคคลที่สาม การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้ Andr:oid API ที่สอดคล้องกัน
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์
android.hardware.wifi
- [C-1-3] ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
- [C-1-4] ต้องรองรับ Multicast DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) เมื่อใดก็ตามที่ดำเนินการ ซึ่งรวมถึง
- แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงานอยู่
- สำหรับการใช้งานอุปกรณ์ Android TV แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย
- ควรสุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอการตรวจสอบ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้ง ขณะที่ STA ไม่ได้เชื่อมต่ออยู่
- เฟรมคำขอการตรวจสอบแต่ละกลุ่มที่ประกอบด้วยการสแกน 1 รายการควรใช้ที่อยู่ MAC ��ี่��อ��คล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งทางของการสแกน)
- หมายเลขลำดับคำขอตรวจสอบควรทำซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
- หมายเลขลำดับคำขอการตรวจสอบควรสุ่มอยู่ระหว่างคำขอการตรวจสอบสุดท้ายของการสแกนและคำขอการตรวจสอบแรกของการสแกนครั้งถัดไป
- ควรอนุญาตเฉพาะองค์ประกอบข้อมูลต่อไปนี้ในเฟรมคำขอการตรวจสอบ ส่วน STA ไม่ได้เชื่อมต่อ
- ชุดพารามิเตอร์ SSID (0)
- ชุดพารามิเตอร์ DS (3)
7.4.2.1 Wi-Fi Direct
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุน Wi-Fi Direct (Wi-Fi แบบเพียร์ทูเพียร์)
หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Direct การทำงานจะส่งผลดังนี้
- [C-1-1] ต้องใช้ corresponding Android API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
- [C-1-2] ต้องรายงานฟีเจอร์ของฮาร์ดแวร์
android.hardware.wifi.direct
- [C-1-3] ต้องรองรับการทำงาน Wi-Fi ปกติ
- ควรรองรับการทำงาน Wi-Fi และ Wi-Fi Direct ควบคู่กัน
7.4.2.2 การตั้งค่าการเชื่อมต่อโดยตรงผ่านอุโมงค์ Wi-Fi
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับการตั้งค่า Wi-Fi Tunneled Direct Link Setup (TDLS) ดังที่อธิบายไว้ในเอกสารประกอบของ Android SDK
หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLS และ TDLS เปิดใช้อยู่โดย Wi-FiManager API
- [C-1-1] ต้องประกาศการรองรับ TDLS จนถึงวันที่
WifiManager.isTdlsSupported
- ควรใช้ TDLS เมื่อเป็นไปได้และเป็นประโยชน์เท่านั้น
- ควรมีการเรียนรู้และไม่ใช้ TDL เมื่อประสิทธิภาพการทำงานอาจแย่กว่าการใช้จุดเข้าใช้งาน Wi-Fi
7.4.2.3 การรับรู้ Wi-Fi
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับ Wi-Fi Aware
หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Aware และเปิดเผยฟังก์ชันการทํางานแก่แอปของบุคคลที่สาม ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องใช้
WifiAwareManager
API ตามที่อธิบายไว้ในเอกสารประกอบ SDK - [C-1-2] ต้องประกาศ Flag ฟีเจอร์
android.hardware.wifi.aware
- [C-1-3] ต้องรองรับการทำงาน Wi-Fi และ Wi-Fi Aware พร้อมกัน
- [C-1-4] ต้องสุ่มที่อยู่ของอินเทอร์เฟซการจัดการ Wi-Fi Aware ทุกๆ 30 นาที และเมื่อใดก็ตามที่เปิด��ช้ Wi-Fi Aware อยู่
7.4.2.4 รหัสผ่าน Wi-Fi
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับ Wi-Fi Passpoint
หากการใช้งานอุปกรณ์มีการรองรับ Passpoint ของ Wi-Fi ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องใช้ API ของ
WifiManager
ที่เกี่ยวข้อง��ับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบ SDK - [C-1-2] ต้องสนับสนุนมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นพบและการเลือกเครือข่าย เช่น General Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)
ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รองรับ Wi-Fi Passpoint
- [C-2-1] การใช้งาน API ที่เกี่ยวข้องกับ
WifiManager
ของ Passpoint ต้องมีUnsupportedOperationException
7.4.3 บลูทูธ
หากอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ ระบบจะดำเนินการต่อไปนี้
- ควรรองรับตัวแปลงรหัสเสียงขั้นสูงและตัวแปลงรหัสเสียงบลูทูธ (เช่น LDAC)
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.vr.high_performance
สิ่งต่อไปนี้
- [C-1-1] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวของข้อมูล Bluetooth LE
Android มีการสนับสนุนสำหรับบลูทูธและบลูทูธพลังงานต่ำ
หากอุปกรณ์รองรับบลูทูธและบลูทูธพลังงานต่ำ จะมีผลดังนี้
- [C-2-1] ต้องประกาศฟีเจอร์แพลตฟอร์มที่เกี่ยวข้อง (
android.hardware.bluetooth
และandroid.hardware.bluetooth_le
ตามลำดับ) และใช้งาน API ของแพลตฟอร์ม - ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVCP, OBEX ฯลฯ ตามความเหมาะสมกับอุปกรณ์
หากอุปกรณ์รองรับบลูทูธพลังงานต่ำ ระบบจะดำเนินการดังต่อไปนี้
- [C-3-1] ต้องประกาศฟีเจอร์ของฮาร์ดแวร์
android.hardware.bluetooth_le
- [C-3-2] ต้องเปิดใช้ API บลูทูธที่ใช้ GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) ตามที่อธิบายไว้ในเอกสารประกอบ SDK และ android.bluetooth
- [C-3-3] ต้องรายงานค่าที่ถูกต้องสำหรับ
BluetoothAdapter.isOffloadedFilteringSupported()
เพื่อระบุว่ามีการใช้ตรรกะการกรองสำหรับคลาส API ScanFilter หรือไม่ - [C-3-4] ต้องรายงานค่าที่ถูกต้องสำหรับ
BluetoothAdapter.isMultipleAdvertisementSupported()
เพื่อระบุว่ามีการรองรับการโฆษณาพลังงานต่ำหรือไม่ - ควรรองรับการลดภาระของตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API
- ควรรองรับการลดการโหลดของการสแกนแบบก��ุ่มไปยังชิปเซ็ตบลูทูธ
-
ควรรองรับโฆษณาหลายรายการที่มีอย่างน้อย 4 ช่อง
-
[SR] แนะนําอย่างยิ่งให้ใช้ระยะหมดเวลา Resolvable Private Address (RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
7.4.4 การสื่อสารระยะใกล้
การติดตั้งใช้งานอุปกรณ์
- ควรรวมตัวรับสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near Field Communications (NFC)
- [C-0-1] ต้องใช้ API ของ
android.nfc.NdefMessage
และandroid.nfc.NdefRecord
แม้ว่าจะไม่มีการรองรับ NFC หรือประกาศฟีเจอร์android.hardware.nfc
เนื่องจากคลาสต่างๆ แสดงถึงรูปแบบการนำเสนอข้อมูลที่ขึ้นอยู่กับโปรโตคอล
หากการใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC และวางแผนที่จะทำให้แอปของบุคคลที่สามใช้งานได้ การใช้งานจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องรายงานฟีเจอร์
android.hardware.nfc
จากเมธอดandroid.content.pm.PackageManager.hasSystemFeature()
- ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ดังต่อไปนี้ได้
- [C-1-2] ต้องทำหน้าที่เป็นผู้อ่าน/ผู้เขียนฟอรัม NFC (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของฟอรัม NFC NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NFC (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- ประเภทแท็กฟอรัม NFC 1, 2, 3, 4, 5 (กำหนดโดยฟอรัม NFC)
-
[SR] แนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านทางมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้มาตรฐาน NFC จะได้รับการระบุว่า "แนะนำ" อย่างชัดเจน แต่มีการกำหนดมาตรฐานความเข้ากันได้สำหรับเวอร์ชันในอนาคตจะเปลี่ยนแปลงเป็น "ต้อง" มาตรฐานเหล่านี้เป็นตัวเลือกในเวอร์ชันนี้ แต่จะบังคับในเวอร์ชันต่อๆ ไป เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบั������������้อ����หนด�����ล่านี้���ันที เพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นอื่นๆ ในอนาคตได้
-
[C-1-3] ต้องมีความสามารถในการส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลระหว่างเครื่องต่อไปนี้
- ISO 18092
- LLCP 1.2 (กำหนดโดยฟอรัม NFC)
- SDP 1.0 (กำหนดโดยฟอรัม NFC)
- โปรโตคอลการพุช NDEF
- SNEP 1.0 (กำหนดโดยฟอรัม NFC)
- [C-1-4] ต้องมีการสนับสนุนสำหรับ Androidบีม และควรเปิดใช้ Androidบีมโดยค่าเริ่มต้น
- [C-1-5] ต้องรับและส่งโดยใช้ Androidบีมได้ เมื่อเปิดใช้ Androidบีม หรือเปิดโหมด NFC P2p ที่เป็นกรรมสิทธิ์อื่นๆ
- [C-1-6] ต้องใช้เซิร์ฟเวอร์เริ่มต้นของ SNEP ข้อความ NDEF ที่ถูกต้องซึ่งได้รับจากเซิร์ฟเวอร์ SNEP เริ่มต้นจะต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent
android.nfc.ACTION_NDEF_DISCOVERED
การปิดใช้ Androidบีมในการตั้งค่าต้องไม่ปิดใช้การส่งข้อความ NDEF ที่เข้ามาใหม่ - [C-1-7] ต้องปฏิบัติตาม Intent ของ
android.settings.NFCSHARING_SETTINGS
จึงจะแสดงการตั้งค่าการแชร์ NFC ได้ - [C-1-8] ต้องใช้เซิร์ฟเวอร์ NPP ข้อความที่เซิร์ฟเวอร์ NPP ได้รับจะต้องประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้นของ SNEP
- [C-1-9] ต้องใช้ไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Androidบีม หากไม่พบเซิร์ฟเวอร์ SNEP ที่เป็นค่าเริ่มต้น ไคลเอ็นต์ต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
- [C-1-10] ต้องอนุญาตให้กิจกรรมที่ทำงานอยู่เบื้องหน้าตั้งค่าข้อความ NDEF แบบ P2P ขาออกโดยใช้
android.nfc.NfcAdapter.setNdefPushMessage
,android.nfc.NfcAdapter.setNdefPushMessageCallback
และandroid.nfc.NfcAdapter.enableForegroundNdefPush
- ควรใช้ท่าทางสั��ผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อบีม" ก่อนส่งข้อความ NDEF แบบ P2P ขาออก
- [C-1-11] ต้องรองรับการส่งมอบการเชื่อมต่อ NFC ไปยังบลูทูธเมื่ออุปกรณ์รองรับ Bluetooth Object Push Profile
- [C-1-12] ต้องรองรับการส่งมอบการเชื่อมต่อไปยังบลูทูธเมื่อใช้
android.nfc.NfcAdapter.setBeamPushUris
โดยใช้ข้อกำหนดของ "การแฮนด์โอเวอร์การเชื่อมต่อเวอร์ชัน 1.2" และ "การจับคู่อย่างง่ายที่ปลอดภัยบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" จากฟอรัม NFC การติดตั้งใช้งานดังกล่าวต้องใช้บริการ Handover LLCP ที่มีชื่อว่าบริการชื่อ "urn:nfc:sn:handover" สำหรับการแลกเปลี่ยนคำขอโอน/เลือกบันทึกผ่าน NFC และต้องใช้โปรไฟล์พุชของ Bluetooth Object Push สำหรับการโอนข้อมูลบลูทูธจริง ด้วยเหตุผลเดิม (เพื่อให้ยังคงสามารถทำงานร่วมกับอุปกรณ์ Android 4.1 ได้) การใช้งานควรจะยอมรับคำขอ SNEP GET สำหรับการแลกเปลี่ยนคำขอส่ง/บันทึกที่เลือกผ่าน NFC อย่างไรก็ตาม การนำไปใช้ไม่ควรส่งคำขอ SNEP GET เพื่อทำการส่งมอบการเชื่อมต่อ - [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมด���ารค้นหา NFC
- ควรอยู่ในโหมดการค้นหา NFC ขณะอุปกรณ์ทำงานอยู่โดยที่หน้าจอทำงานอยู่และปลดล็อกหน้าจอแล้ว
- ควรสามารถอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC ของ Thinfilm
(โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่พร้อมใช้งานสำหรับข้อกำหนดของฟอรัม JIS, ISO และ NFC ที่อ้างถึงข้างต้น)
Android มีการสนับสนุนโหมด NFC Host Card Emulation (HCE)
หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทางรหัสแอปพลิเคชัน (AID)
- [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์
android.hardware.nfc.hce
- [C-2-2] ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK
หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE สำหรับ NfcF และใช้ฟีเจอร์ดังกล่าวกับแอปพลิเคชันของบุคคลที่สาม การใช้งานดังกล่าวจะส่งผลดังนี้
- [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์
android.hardware.nfc.hcef
- [C-3-2] ต้องใช้ API การจำลองการ์ด NFC ตามที่ระบุไว้ใน Android SDK
หากการใช้งานอุปกรณ์รวมการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทผู้อ่าน/ผู้เขียนเนื้อหาจะมีลักษณะดังนี้
- [C-4-1] ต้องใช้ Android API ที่สอดคล้องกันตามที่ Android SDK ระบุไว้
- [C-4-2] ต้องรายงานฟีเจอร์
com.nxp.mifare
จากเมธอดandroid.content.pm.PackageManager.hasSystemFeature
() โปรดทราบว่าฟีเจอร์นี้ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจึงไม่ปรากฏเป็นค่าคงที่ในคลาสandroid.content.pm.PackageManager
7.4.5 ความสามารถของเครือข่ายขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีการสนับสนุนเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ กล่าวอย่างเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ต้องมีการรองรับมาตรฐานข้อมูลที่มีความเร็ว 200 Kbit/วินาทีอย่างน้อย 1 รายการเป็นอย่างน้อย ตัวอย่างเทคโนโลยีที่ตรงตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต, PAN บลูทูธ ฯลฯ
- [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น
java.net.Socket
และjava.net.URLConnection
รวมถึง API แบบเนทีฟ เช่น ซ็อกเก็ตAF_INET6
- [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
- ต้องตรวจสอบให้แน่ใจว่าการสื่อสารของ IPv6 มีความเสถียรเหมือนกับ IPv4 เป็นต้น
- [C-0-4] ต้องใช้การเชื่อมต่อ IPv6 ในโหมด Doze
- [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่เข้ากันได้กับ IPv6 ซึ่งใช้อายุการใช้งานของ RA อย่างน้อย 180 วินาที
- ควรรวมการสนับสนุนมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
- อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
ระดับการสนับสนุน IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่ายดังต่อไปนี้
หากอุปกรณ์รองรับเครือข่าย Wi-Fi ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi
หากอุปกรณ์รองรับเครือข่ายอีเทอร์เน็ต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับการทำงานแบบสแต็กคู่ในอีเทอร์เน็ต
หากอุปกรณ์รองรับข้อมูลเครือข่ายมือถือ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องตรงตามข้อกำหนดเหล่านี้ในแต่ละเครือข่ายที่เชื่อมต่ออยู่พร้อมกันเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 เครือข่าย (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ)
- ควรรองรับการดำเนินการ IPv6 (IPv6 เท่านั้นและอาจรองรับแบบ 2 สแต็ก) ในข้อมูลเครือข่ายมือถือ
7.4.6 การตั้งค่าการซิงค์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเปิดการตั้งค่าการซิงค์อัตโนมัติหลักไว้โดยค่าเริ่มต้นเพื่อให้เมธอด
getMasterSyncAutomatically()
แสดงค่าเป็น "true"
7.4.7 ประหยัดอินเทอร์เน็ต
หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อแบบจำกัดปริมาณ ระบบจะดำเนินการดังต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้ใช้โหมดประหยัดอินเทอร์เน็ต
หากการติดตั้งใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ API ทั้งหมดในคลาส
ConnectivityManager
ตามที่อธิบายไว้ในเอกสารประกอบ SDK - [C-1-2] ต้องระบุอินเทอร์เฟซผู้ใช้ในการตั้งค่าที่จัดการ Intent ของ
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ซึ่งอนุญาตให้ผู้ใช้เพิ่มแอปพลิเคชันหรือนำแอปพลิเคชันออกจากรายการที่อนุญาตได้
หากอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต ระบบจะดำเนินการดังนี้
- [C-2-1] ต้องส่งค่า
RESTRICT_BACKGROUND_STATUS_DISABLED
สำหรับConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] ต้องไม่ออกอากาศ
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
- [C-2-3] ต้องมีกิจกรรมที่จัดการ Intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
แต่อาจใช้งานโดยไม่มีการด��เนินการ
7.5 กล้อง
หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.camera.any
- [C-1-2] ต้องเป็นไปได้ที่แอปพลิเคชันจะจัดสรร RGBA_8888 บิตแมป 3 รายการพร้อมๆ กับขนาดของภาพที่เกิดจากเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์ ในขณะที่กล้องเปิดอยู่เพื่อการแสดงตัวอย่างเบื้องต้นและการจับภาพ
7.5.1 กล้องหลัง
กล้องหลังคือกล้องที่อยู่ด้านข้างของอุปกรณ์ โดยอยู่ฝั่งตรงข้ามกับจอแสดงผล กล่าวคือจะถ่ายภาพจากมุมอีกด้านหนึ่งของอุปกรณ์เหมือนกับกล้องทั่วไป
การติดตั้งใช้งานอุปกรณ์
- ควรมีกล้องหลัง
หากการใช้งานอุปกรณ์มีกล้องหลังอย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.camera
และandroid.hardware.camera.any
- [C-1-2] ต้องมีความละเอียดอย่างน้อย 2 เมกะพิกเซล
- ควรใช้การโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง (ไม่ต่างจากซอฟต์แวร์แอปพลิเคชัน)
- อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
- อาจรวมแฟลชด้วย
หากกล้องมีแฟลช ให้ทำดังนี้
- [C-2-1] โคมไฟแฟลชต้องไม่ติดสว่างในขณะที่มีการลงทะเบียนอินสแตนซ์
android.hardware.Camera.PreviewCallback
บนพื้นผิวแสดงตัวอย่าง��องกล้อง เว้นแต่แอปพลิเคชันได้เปิดใช้แฟลชอย่างชัดแจ้งด้วยการเปิดใช้แอตทริบิวต์FLASH_MODE_AUTO
หรือFLASH_MODE_ON
ของวัตถุCamera.Parameters
โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้Camera.PreviewCallback
เท่านั้น
7.5.2 กล้องหน้า
กล้องหน้าคือกล้องที่อยู่ด้านเดียวกับจอแสดงผล ซึ่งก็คือกล้องที่ใช้ถ่ายภาพผู้ใช้ เช่น สำหรับการประชุมทางวิดีโอและแอปพลิเคชันที่คล้ายกัน
การติดตั้งใช้งานอุปกรณ์
- อาจมีก��้องหน้า
หากการใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.camera.any
และandroid.hardware.camera.front
- [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
- [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวในอุปกรณ์ก็ตาม
- [C-1-4] ภาพตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุ เมื่อแอปพลิเคชันปัจจุบันขออย่างชัดแจ้งให้หมุนจอแสดงผลของกล้องผ่านการเรียกเมธอด
android.hardware.Camera.setDisplayOrientation()
ในทางกลับกัน ตัวอย่างจะต้องมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์หากแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนจอแสดงผลของกล้องผ่านการเรียกเมธอดandroid.hardware.Camera.setDisplayOrientation()
- [C-1-5] ต้องไม่มิเรอร์ภาพนิ่งหรือสตรีมวิดีโอล่าสุดที่บันทึกกลับไปยังการเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ
- [C-1-6] ต้องจำลองภาพที่แสดงหลังมุมมองโพสต์ ในลักษณะเดียวกับสตรีมภาพตัวอย่างจากกล้อง
- อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
หากผู้ใช้เปลี่ยนการใช้งานอุปกรณ์ได้ (เช่น โดยอัตโนมัติผ่านตัวตรวจวัดความเร่งหรือด้วยตนเองผ่านอินพุตของผู้ใช้) ให้ทำดังนี้
- [C-2-1] ตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์
7.5.3 กล้องภายนอก
การติดตั้งใช้งานอุปกรณ์
- อาจรวมการรองรับกล้องภายนอกที่ไม่จำเป็นต้องเชื่อมต่อตลอดเวลา
หากการใช้งานอุปกรณ์มีการรองรับกล้องภายนอก จะมีผลดังนี้
- [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม
android.hardware.camera.external
และandroid.hardware camera.any
- [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ต USB
- ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้สามารถโอนสตรีมคุณภาพสูงที่ไม่เข้ารหัส (เช่น สตรีมภาพดิบหรือสตรีมที่บีบอัดแบบอ��สระ)
- อาจรองรับกล้องหลายตัว
- อาจรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง
หากระบบรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง ให้ทำดังนี้
- [C-2-1] การใช้งานอุปกรณ์ต้องเข้าถึงสตรีม MJPEG / สตรีมที่ไม่เข้ารหัสพร้อมก���� (QVGA หรือ��วาม���ะเ��ียดสูงกว่า)
7.5.4 การทำงานของ API กล้องถ่ายรูป
Android มีแพ็กเกจ API 2 แพ็กเกจสำหรับเข้าถึงกล้อง API ใหม่ android.hardware.camera2 จะแสดงการควบคุมกล้องในระดับต่ำกว่าแก่แอป ซึ่งรวมถึงโฟลว์การถ่ายภาพ/การสตรีมแบบ Zero Copy ที่มีประสิทธิภาพ การควบคุมการรับแสง ค่าเกน การเพิ่มไวท์บาลานซ์ การแปลงสี การตัดเสียงรบกวน การทำให้คมชัด และอีกมากมาย
แพ็กเกจ API เก่า android.hardware.Camera
มีการทำเครื่องหมายเป็นเลิกใช้งานใน Android 5.0 แต่แพ็กเกจดังกล่าวควรจะยังพร้อมใช้งานสำหรับแอปได้ การใช้งานอุปกรณ์ Android ต้องดูแลให้มีการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK
การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ API ที่เกี่ยวข้องกับกล้องสำหรับกล้องทั้งหมดที่มีอยู่ การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องใช้
android.hardware.PixelFormat.YCbCr_420_SP
สำหรับตัวอย่างข้อมูลที่ให้ไว้กับ Callback ของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียกใช้android.hardware.Camera.Parameters.setPreviewFormat(int)
- [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เพิ่มเติมเมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์
android.hardware.Camera.PreviewCallback
และระบบเรียกเมธอดonPreviewFrame()
และรูปแบบแสดงตัวอย่างคือ YCbCr_420_SP ซึ่งข้อมูลในไบต์[] ที่ส่งไปยังonPreviewFrame()
นั่นคือ NV21 ต้องเป็นค่าเริ่มต้น - [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่แสดงด้วยค่าคงที่
android.graphics.ImageFormat.YV12
) สำหรับการ��สดงตัวอย่างจากกล้องทั้งสำหรับกล้องหน้าและกล้องหลังสำหรับandroid.hardware.Camera
(กล้องและโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อาจใช้พิกเซลดั้งเดิมรูปแบบใดก็ได้ แต่การใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12) - [C-0-4] ต้องรองรับรูปแบบ
android.hardware.ImageFormat.YUV_420_888
และandroid.hardware.ImageFormat.JPEG
เป็นเอาต์พุตผ่านandroid.media.ImageReader
API สำหรับandroid.hardware.camera2
- [C-0-5] ต้องใช้ กล้องถ่ายรูป API แบบเต็มซึ่งรวมอยู่ในเอกสารประกอบของ Android SDK โดยไม่คำนึงว่าอุปกรณ์ดังกล่าวจะมีระบบโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือความสามารถอื่นๆ หรือไม่ ตัวอย่างเช่น กล้องที่ไม่มีการโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์
android.hardware.Camera.AutoFocusCallback
ที่ลงทะเบียนไว้ (แม้ว่าจะไม่เกี่ยวข้องกับกล้องที่ไม่โฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการทำงานนี้มีผลกับกล้องหน้าด้วย เช่น แม้ว่ากล้องหน้าส่วนใหญ่ไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับของ API ยังคงต้อง "ไม่อัปเดต" ตามที่อธิบายไว้ - [C-0-6] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละรายการที่กำหนดเป็นค่าคงที่ในคลาส
android.hardware.Camera.Parameters
ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยึดตามหรือรับรู้ค่าคงที่สตริงที่ส่งไปยังเมธอดandroid.hardware.Camera.setParameters()
ที่ไม่ใช่ค่าคงที่ที่ระบุเป็นค่าคงที่ในandroid.hardware.Camera.Parameters
กล่าวคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และ "ต้องไม่รองรับ" ประเภทพารามิเตอร์กล้องที่กำหนดเอง ตัวอย่างเช่น การใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการสร้างภาพที่มีช่วงไดนามิกกว้าง (HDR) ต้องรองรับพารามิเตอร์กล้องCamera.SCENE_MODE_HDR
- [C-0-7] ต้องรายงานระดับการรองรับพร็อพเพอร์ตี้
android.info.supportedHardwareLevel
ในระดับที่เหมาะสมตามที่อธิบายไว้ใน Android SDK และรายงานแ��ล็กฟีเจอร์เฟรมเวิร์กที่เหมาะสม - [C-0-8] ต้องประกาศความ��ามารถของกล้อง
android.hardware.camera2
แต่ละตัวผ่านพร็อพเพอร์ตี้android.request.availableCapabilities
และประกาศแฟล็กฟีเจอร์ที่เหมาะสม และต้องระบุแฟล็กฟีเจอร์หากอุปกรณ์กล้องที่แนบอยู่รองรับฟีเจอร์นี้ - [C-0-9] ต้องเผยแพร่เจตนาของ
Camera.ACTION_NEW_PICTURE
ทุกครั้งที่กล้องถ่ายภาพใหม่และมีการเพิ่มรูปภาพดังกล่าวลงในที่เก็บสื่อแล้ว - [C-0-10] ต้องเผยแพร่เจตนาของ
Camera.ACTION_NEW_VIDEO
ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของรูปภาพไปยังร้านค้าสื่อแล้ว
7.5.5 การวางแนวกล้อง
หากอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าว
- [C-1-1] ต้องวางแนวเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับด้านยาวของหน้าจอ กล่าวคือ เมื่ออุปกรณ์อยู่ในแนวนอน กล้องต้องจับภาพในแนวนอน ซึ่งจะมีผลไม่ว่าการวางแนวตามธรรมชาติของอุปกรณ์จะเป็นอย่างไรก็ตาม ซึ่งหมายถึงอุปกรณ์หลักแนวนอนและอุปกรณ์หลักแนวตั้ง
7.6 หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1 หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมี Download Manager ที่แอปพลิเคชันสามารถใช้ดาวน์โหลดไฟล์ข้อมูลได้ และต้องดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ลงในตำแหน่ง "แคช" เริ่มต้นได้
7.6.2 พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยแอปพลิเคชัน หรือมักเรียกว่า "ที่จัดเก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน" หรือตามเส้นทาง "/sdcard" ของ Linux ที่ต่อเชื่อมอยู่
- [C-0-2] ต้องกำหนดค่าเป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งต่อเชื่อมโดยค่าเริ่มต้น หรือที่เรียกว่า "พร้อมใช้งานทันที" ไม่ว่าจะใช้งานพื้นที่เก็บข้อมูลกับคอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ดดิจิทัลที่ปลอดภัย)
- [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันบนเส้นทาง Linux
sdcard
โดยตรง หรือรวมล��งก์สัญลักษณ์ของ Linux จากsdcard
ไปยังจุดต่อเชื่อมจริง - [C-0-4] ต้องบังคับใช้สิทธิ์
android.permission.WRITE_EXTERNAL_STORAGE
ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนี้ตามที่ระบุไว้ใน SDK พื้นที่เก็บข้อมูลที่ใช้ร่วมกันต้องเขียนได้โดยแอปพลิเคชันใดๆ ที่มีสิทธิ์ด��ง����่าว
��าร��ช้��านอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้ข้อใดข้อหนึ่งต่อไปนี้
- พื้นที่เก็บข้อมูลแบบถอดได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
- ส่วนหนึ่งของพื้นที่เก็บข้อมูลภายใน (แบบถอดออกได้) ตามที่ใช้ในโครงการโอเพนซอร์ส Android (AOSP)
หากการนำอุปกรณ์ไปใช้งานใช้พื้นที่เก็บข้อมูลแบบถอดได้เพื่อให้เป็นไปตามข้อกำหนดข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องวางคำเตือนอินเทอร์เฟซผู้ใช้แบบข้อความโทสต์หรือป๊อปอัปแก่ผู้ใช้เมื่อไม่มีสื่อการเก็บข้อมูลในช่องแทรก
- [C-1-2] ต้องใส่สื่อการเก็บข้อมูลรูปแบบ FAT (เช่น การ์ด SD) หรือแสดงไว้บนกล่องและวัสดุอื่นๆ ที่มีอยู่ ณ เวลาที่ซื้อซึ่งต้องซื้อสื่อสำหรับจัดเก็บข้อมูลแยกต่างหาก
หากการใช้งานอุปกรณ์ใช้การจัดสรรพื้นที่เก็บข้อมูลแบบถอดได้ไม่ได้เพื่อให้เป็นไปตามข้อกำหนดข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรใช้การใช้งาน AOSP ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายใน
- อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน
หากการใช้งานอุปกรณ์มีเส้นทางพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายเส้นทาง (เช่น ทั้งช่องเสียบการ์ด SD และที่จัดเก็บข้อมูลภายในที่ใช้ร่วมกัน) สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องอนุญาตเฉพาะแอปพลิเคชัน Android ที่ติดตั้งล่วงหน้าและสิทธิ์
WRITE_EXTERNAL_STORAGE
ในการเขียนไปยังพื้นที่เก็บข้อมูลภายนอกสำรอง ยกเว้นเมื่อเขียนไปยังไดเรกทอรีเฉพาะแพ็กเกจหรือภายในURI
ซึ่งแสดงผลด้วยการเริ่ม Intent ของACTION_OPEN_DOCUMENT_TREE
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์เหล่านี้จะมีผลดังนี้
- [C-3-1] ต้องระบุกลไกในการเข้าถึงข้อมูลในที่จัดเก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันจากคอมพิ��เตอร์โฮสต์
- ควรแสดงเนื้อหาจากเส้นทางพื้นที่เก็บข้อมูลทั้ง 2 แบบอย่างโปร่งใสผ่านบริการสแกนสื่อของ Android และ
android.provider.MediaStore
- อาจใช้พื้นที่เก็บข้อมูลแบบ USB จำนวนมาก แต่ควรใช้ Media Transfer Protocol เพื่อให้เป็นไปตามข้อกำหนดนี้
หากการใช้งานอุปกรณ์มีพอร์ต USB ที่มีโหมดอุปกรณ์ต่อพ่วง USB และรองรับ Media Transfer Protocol จะมีผลดังนี้
- ควรเข้ากันได้กับโฮสต์ Android MTP อ้างอิงอย่าง Android File Transfer
- ควรรายงานคลาสของอุปกรณ์ USB เป็น 0x00
- ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"
7.6.3 พื้นที่เก็บข้อมูลแบบ Adoptable
หากอุปกรณ์ควรมีลักษณะเป็นอุปกรณ์เคลื่อนที่ซึ่งต่างจากทีวี การใช้งานอุปกรณ์จะเป็นดังนี้
- [SR] แนะนําอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลแบบนํามาใช้ในพื้นที่ที่มั่นคงในระยะยาว เนื่องจากการเลิกเชื่อมต่อโดยไม่ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย
หากพอร์ตของอุปกรณ์จัดเก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่มั่นคงในระยะยาว เช่น ภายในช่องใส่แบตเตอรี่หรือฝาครอบป้องกันอื่นๆ การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [SR] แนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลที่สามารถนำมาใช้ได้
7.7 USB
หากการใช้งานอุปกรณ์มีพอร์ต USB สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB
7.7.1 โหมดอุปกรณ์ต่อพ่วง USB
หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
- [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB ประเภท A หรือ Type-C แบบมาตรฐานได้
- [C-1-2] ต้องรายงานค่า
iSerialNumber
ที่ถูกต้องในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ผ่านandroid.os.Build.SERIAL
- [C-1-3] ต้องตรวจหาที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจพบการเปลี่ยนแปลงในโฆษณาหากอุปกรณ์รองรับ USB Type-C
- [SR] พอร์ตควรใช้รูปแบบ USB ���บบ micro-B, micro-AB หรือ Type-C เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [SR] พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวที่เป็นธรรมชาติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้แสดงผลได้อย่างถูกต้องเมื่ออุปกรณ์วางอยู่ในแนวเดียวกับพอร์ตที่ด้านล่าง เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [SR] ควรใช้การสนับสนุนเพื่อดึงกระแสไฟฟ้า 1.5 A ในระหว่างการส่งเสียงร้อง HS และการจราจรของข้อมูลตามที่ระบุไว้ในข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [SR] ขอแนะนำเป็นอย่างยิ่งให้ไม่รองรับวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของซิงก์/แหล่งที่มาอาจทำให้เกิดปัญหาเกี่ยวกับความสามารถในการทำงานร่วมกันกับที่ชาร์จหรืออุปกรณ์ที่รองรับวิธีการส่งพลังงาน USB แบบมาตรฐาน แม้จะเรียกว่า "แนะนำอย่างยิ่ง" แต่สำหรับ Android เวอร์ชันต่อๆ ไป เราอาจต้องใช้อุปกรณ์ type-C ทั้งหมดเพื่อรองรับความสามารถในการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C แบบมาตรฐาน
- [SR] แนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงานเมื่อรองรับโหมดโฮสต์ Type-C USB และ USB
- ควรรองรับการส่งพลังงานสำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่น เช่น โหมดจอแสดงผลเอาต์
- ควรใช้ Android Open Accessory (AOA) API และข้อมูลจำเพาะตามที่ระบุไว้ในเอกสาร Android SDK
หากใช้อุปกรณ์รวมถึงพอร์ต USB ให้เป็นไปตามข้อกำหนด AOA อุปกรณ์ดังกล่าวจะดำเนินการดังนี้
- [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์
android.hardware.usb.accessory
- [C-2-2] คลาสที่จัดเก็บข้อมูล USB ขนาดใหญ่ต้องมีสตริง "android" ที่ตอนท้ายของสตริงคำอธิบายอินเทอร์เฟซ
iInterface
ของที่จัดเก็บข้อมูล USB จำนวนมาก
7.7.2 โหมดโฮสต์ USB
หาก����ปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ การใช้งานจะดังนี้
- [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ของฮาร์ดแวร์
android.hardware.usb.host
- [C-1-2] ต้องมีการรองรับเพื่อเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ ต้องเป็นอย่างใดอย่างหนึ่งต่อไปนี้
- มีพอร์ต C ในอุปกรณ์หรือจัดส่งพร้อมสายซึ่งปรับพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ไปเป็นพอร์ต USB type-C มาตรฐาน (อุปกรณ์ USB Type-C)
- มีประเภท A ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ไปยังพอร์ต USB type-A มาตรฐาน
- มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรจัดส่งพร้อมกับสายที่ปรับให้เข้ากับพอร์ตประเภท A มาตรฐาน
- [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB ประเภท A หรือพอร์ตไมโคร AB เป็นพอร์ต type-C (เต้ารับ)
- [SR] แนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
- ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะที่อยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของการแก้ไขข้อมูลจำเพาะของสาย USB Type-C 1.2 สำหรับขั้วต่อ USB Type-C หรือการใช้เอาต์พุตพอร์ตดาวน์สตรีม(CDP) สำหรับการชาร์จช่วงปัจจุบันตามที่ระบุไว้ในข้อมูลจำเพาะของการชาร์จสาย USB Type-C สำหรับหัวชาร์จ USB Type-C การแก้ไขที่ 1.2
- ควรใช้และสนับสนุนมาตรฐาน USB Type-C
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และคลาสเสียง USB อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้
- [C-2-1] ต้องรองรับคลาส USB HID
- [C-2-2] ต้องรองรับการตรวจหาและการแมปช่องข้อมูล HID ต่อไปนี้ซึ่งระบุไว้ในตารางการใช้งาน USB HID และคำขอใช้คำสั่งเสียงกับค่าคงที่
KeyEvent
ดังนี้- รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0E9):
KEYCODE_VOLUME_UP
- รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- รหัสการใช้หน้าการใช้งาน (0xC) (0x0CF):
KEYCODE_VOICE_ASSIST
- รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0CD):
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF)
- [C-3-1] ต้องจดจำอุปกรณ์ MTP (Media Transfer Protocol) ที่เชื่อมต่อจากระยะไกล และทําให้เนื้อหาเข้าถึงได้ผ่าน Intent
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
และACTION_CREATE_DOCUMENT
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C ไหม
- [C-4-1] ต้องใช้ฟังก์ชันการทำงานของพอร์ตบทบาทแบบคู่ตามที่ระบุไว้ในข้อกำหนดเฉพาะ USB Type-C (ส่วนที่ 4.5.1.3.3)
- [SR] แนะนำอย่างยิ่งให้รองรับ DisplayPort และควรรองรับอัตราข้อมูล USB SuperSpeed และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
- [SR] แนะนำอย่างยิ่งให้ไม่รองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก A ของการแก้ไขข้อกำหนดของสาย USB Type-C และขั้วต่อ 1.2
- ควรใช้โมเดล Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบของอุปกรณ์ ตัวอย่างเช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK
7.8 เสียง
7.8.1 ไมโครโฟน
หากอุปกรณ์มีไมโครโฟน จะมีผลดังนี้
- [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์
android.hardware.microphone
- [C-1-2] ต้องมีคุณสมบัติตรงตามข้อกำหนดในการบันทึกเสียงในส่วนที่ 5.4
- [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
- [SR] ขอแนะนำเป็นอย่างยิ่งให้สนับสนุนการบันทึกด้วยอัลตราซาวด์ระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 7.8.3
หากการติดตั้งใช้งานอุปกรณ์ไม่มีไมโครโฟน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์
android.hardware.microphone
- [C-2-2] ต้องใช้ API การบันทึกเสียงอย่างน้อยเป็นไม่ปฏิบัติการตามส่วนที่ 7
7.8.2 เอาต์พุตเสียง
หากอุปกรณ์มีลำโพงหรือพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น ช่องเสียบหูฟัง 3.5 มม. แบบ 4 ตั���นำหรือพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB จะมีผลดังนี้
- [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์
android.hardware.audio.output
- [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
- [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
- [SR] แนะนำอย่างเข้มงวดเพื่อรองรับการเล่นอัลตราซาวด์ในระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 7.8.3
หากการใช้งานอุปกรณ์ไม่มีพอร์ตลำโพงหรือเอาต์พุตเสียง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องไม่รายงานฟีเจอร์
android.hardware.audio output
- [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นไม่ต้องดำเนินการอย่างน้อย
สำหรับวัตถุประสงค์ของส่วนนี้ "พอร์ตเอาต์พุต" คืออินเทอร์เฟซอุปกรณ์จริง เช่น ช่องเสียบหูฟัง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลทางวิทยุ เช่น บลูทูธ, Wi-Fi หรือเครือข่ายมือถือ จะไม่ถือว่าเป็น "พอร์ตเอาต์พุต"
7.8.2.1 พอร์ตเสียงแอนะล็อก
เพื่อให้เข้ากันได้กับชุดหูฟังและอุปกรณ์เสริมเสียงอื่นๆ ที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศของ Android หากการติดตั้งอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต พอร์ตเสียงอย่างน้อย 1 พอร์ตควรเป็นช่องเสียบเสียง 3.5 มม. 4 ตัวนำ
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว อุปกรณ์จะตรงตามเงื่อนไขต่อไปนี้
- [C-1-1] ต้องรองรับการเล่นเสียงในหูฟังสเตอริโอและชุดหูฟังสเตอริโอพร้อมไมโครโฟน
- [C-1-2] ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับ PIN-out ของ CTIA
- [C-1-3] ต้องรองรับการตรวจจับและการแมปกับคีย์โค้ดสำหรับค่าอิมพีแดนซ์ 3 ช่วงต่อไปนี้เทียบเท่าระหว่างไมโครโฟนและตัวนำสายดินของปลั๊กเสียง
-
ไม่เกิน 70 โอห์ม:
KEYCODE_HEADSETHOOK
-
210-290 โอห์ม:
KEYCODE_VOLUME_UP
-
360-680 โอห์ม:
KEYCODE_VOLUME_DOWN
-
ไม่เกิน 70 โอห์ม:
- [C-1-4] ต้องทริกเกอร์
ACTION_HEADSET_PLUG
เมื่อมีการเสียบปลั๊ก แต่เมื่อรายชื่อติดต่อทั้งหมดบนปลั๊กสัมผัสส่วนที่เกี่ยวข้องบนช่องเสียบแล้วเท่าน��้น - [C-1-5] ต้องสามารถขับเคลื่อนได้อย่างน้อย 150mV ± 10% ของแรงดันไฟฟ้าขาออกต่ออิมพีแดนซ์ลำโพง 32 โอห์ม
- [C-1-6] ต้องมีแรงดันไฟฟ้าของมุมเอียงของไมโครโฟนระหว่าง 1.8 โวลต์ ~ 2.9 โวลต์
- [SR] แนะนำอย่างเข้มงวดให้ตรวจหาและแมปกับคีย์โค้ดสำหรับช่วงค่าอิมพีแดนซ์ที่เท่ากันต่อไปนี้ระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียง
-
110-180 โอห์ม:
KEYCODE_VOICE_ASSIST
-
110-180 โอห์ม:
- ควรรองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
- ควรรองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอพร้อมไมโครโฟน
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัวและรองรับไมโครโฟน รวมถึงออกอากาศ android.intent.action.HEADSET_PLUG
โดยตั้งค่าไมโครโฟนค่าพิเศษเป็น 1 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับการตรวจจับไมโครโฟนบนอุปกรณ์เสริมสำหรับเสียงที่เสียบอยู่
7.8.3 ใกล้อัลตราซาวด์
เสียงใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz
การติดตั้งใช้งานอุปกรณ์
- ต้องรายงานการรองรับความสามารถในการส่งเสียงแบบเกือบอัลตราซาวด์อย่างถูกต้องผ่าน AudioManager.getProperty API ดังต่อไปนี้
หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION
และ UNPROCESSED
ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- [C-1-1] การตอบสนองกำลังเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องมีขนาดไม่เกิน 15 dB ต่ำกว่าการตอบสนองที่ 2 kHz
- [C-1-2] ไมโครโฟนที่มีอัตราส่วนสัญญาณต่อเสียงรบกวนที่ไม่ถ่วงน้ำหนักสูงกว่า 18.5 kHz ต่อ 20 kHz สำหรับเสียง 19 kHz ที่ -26 dBFS ต้องไม่เกิน 50 dB
หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
เป็น "จริง" ให้ทำดังนี้
- [C-2-1] การตอบสนองเฉลี่ยของลำโพงที่มีความเร็ว 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 ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลการแจ้งเตือนแบบสามมิติและปิดใช้คอมโพเนนต์ UI ของระบบตาเดียวขณะที่แอปพลิเคชัน VR โฟกัสผู้ใช้อยู่
7.9.2 เทคโนโลยีความจริงเสมือน (VR) ประสิทธิภาพสูง
หากการใช้งานอุปกรณ์ระบุถึงการรองรับ VR ประสิทธิภาพสูงในช่วงเวลาของผู้ใช้ที่ยาวนานขึ้นผ่านแฟล็กฟีเจอร์ android.hardware.vr.high_performance
ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องมี 2 Physical Core เป็นอย่างน้อย
- [C-1-2] ต้องประกาศ
android.software.vr.mode feature
- [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
- [C-1-4] ต้องรองรับ OpenGL ES 3.2
- [C-1-5] ต้องรองรับ Vulkan ฮาร์ดแวร์ระดับ 0 และควรรองรับ Vulkan ฮาร์ดแวร์ระดับ 1
- [C-1-6] ต้องใช้
EGL_KHR_mutable_render_buffer
,EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
,EGL_IMG_context_priority
,EGL_EXT_protected_content
และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่มีให้บริการ - [C-1-7] GPU และจอแสดงผลต้องสามารถซิงค์ข้อมูลการเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ ซึ่งจะทำให้การแสดงผลแบบสลับตาของเนื้อหา VR ที่ 60 FPS พร้อมบริบทในการแสดงภาพ 2 รายการจะแสดงโดยไม่มีอาร์ติแฟกต��ที่ฉีกขาดซึ่งมองเห็นได้
- [C-1-8] ต้องใช้
GL_EXT_multisampled_render_to_texture
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_OVR_multiview_multisampled_render_to_texture
,GL_EXT_protected_textures
และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน - [C-1-9] ต้องใช้การรองรับแฟล็ก
AHardwareBuffer
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
และAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
ตามที่อธิบายไว้ใน NDK - [C-1-10] ต้องใช้การสนับสนุนสำหรับ
AHardwareBuffers
ที่มีมากกว่า 1 เลเยอร์ - [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840x2160@30fps-40Mbps (เทียบเท่ากับ 1920x1080@30fps-10Mbps 4 อินสแตนซ์ หรือ 1920x1080@60fps-20Mbps 2 อินสแตนซ์)
- [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920x1080@30fps-10Mbps และควรถอดรหัส 3840x2160@30fps-20Mbps ได้ (เทียบเท่ากับ 1920x1920x1 อินสแตนซ์ 4 fps)
- [C-1-13] ต้องรองรับ API ของ
HardwarePropertiesManager.getDeviceTemperatures
และแสดงผลค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง - [C-1-14] ต้องมีหน้าจอแบบฝัง และความละเอียดอย่างน้อยต้องเป็น FullHD(1080p) และแนะนำให้ใช้เป็น QuadHD (1440p) ขึ้นไป
- [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
- [C-1-16] เวลาในการเปลี่ยนการแสดงผลระหว่างสีเทาเป็นสีเทา ขาวเป็นดำ และดำเป็นขาวต้องอยู่ที่ ≤ 3 มิลลิวินาที
- [C-1-17] จอแสดงผลต้องรองรับโหมดความต่อเนื่องต่ำที่มีความต่อเนื่อง ≤5 มิลลิวินาที ความต่อเนื่องหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
- [C-1-18] ต้องรองรับบลูทูธ 4.2 และการขยายความยาวของข้อมูลบลูทูธ LE หัวข้อ 7.4.3
- [SR] แนะนําอย่างยิ่งให้รองรับฟีเจอร์
android.hardware.sensor.hifi_sensors
และต้องมีคุณสมบัติตรงตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับandroid.hardware.hifi_sensors
- อาจให้แกนเอกสิทธิ์เฉพาะสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า และอาจรองรับ
Process.getExclusiveCores
API เพื่อแสดงจำนวนของแกน CPU ที่มีเฉพาะในแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
หากระบบรองรับแกนพิเศษ แ��น��ล���������เ��็นดังนี้
- [C-2-1] ต้องไม่อนุญาตให้กระบวนการพื้นที่ผู้ใช้อื่นๆ ทำงานในกระบวนการดังกล่าว (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น
8. ประสิทธิภาพและศักยภาพ
เกณฑ์ด้านประสิทธิภาพขั้นต่ำและเกณฑ์กำลังมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป
8.1 ความสม่ำเสมอของประสบการณ์ของผู้ใช้
ผู้ใช้ปลายทางมีอินเทอร์เฟซผู้ใช้ที่ราบรื่นหากมีข้อกำหนดขั้นต่ำบางประการเพื่อให้แอปพลิเคชันและเกมมีอัตราเฟรมและเวลาในการตอบสนองสอดคล้องกัน การใช้งานอุปกรณ์อาจมีข้อกำหนดที่วัดได้สำหรับเวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้และการสลับงานตามที่อธิบายไว้ในส่วนที่ 2 ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์
8.2 ประสิทธิภาพการเข้าถึงไฟล์ I/O
การระบุพื้นฐานทั่วไปสำหรับประสิทธิภาพการเข้าถึงไฟล์ที่สอดคล้องกันในพื้นที่เก็บข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data
) ช่วยให้นักพัฒนาแอปสร้างความคาดหวังที่เหมาะสมซึ่งจะช่วยในการออกแบบซอฟต์แวร์ของตนได้ การใช้งานอุปกรณ์อาจมีข้อกำหนดบางอย่างตามที่อธิบายไว้ในส่วนที่ 2 สำหรับการดำเนินการอ่านและเขียนต่อไปนี้ ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์
- ประสิทธิภาพการเขียนตามลำดับ วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
- ประสิทธิภาพการเขียนแบบสุ่ม วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
- ประสิทธิภาพการอ่านตามลำดับ วัดโดยการอ่านไฟล์ 256 MB โดยใช้บัฟเฟอร์การเขียน 10 MB
- ประสิทธิภาพการอ่านแบบสุ่ม วัดโดยการอ่านไฟล์ 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB
8.3 โหมดประหยัดพลังงาน
Android มีโหมดประหยัดพลังงานของแอปและ Doze เพื่อเพิ่มประสิทธิภาพการใช้งานแบตเตอรี่ [SR] เราขอแนะนำว่าแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดเหล่านี้ควรแสดงต่อผู้ใช้ปลายทาง [SR] ขอแนะนำเป็นอย่างยิ่งไม่ให้ปรับเปลี่ยนไปจากโครงการโอเพนซอร์สของ Android ทั้งการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงานเหล่านี้
นอกเหนือจากโหมดประหยัดพลังงานแล้ว การนำอุปกรณ์ Android ไปใช้อาจจะใช้สถานะกำลังนอนหลับใดๆ หรือทั้งหมด 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)
หากการติดตั้งใช้งานอุปกรณ์ใช้สถานะกำลัง S3 และ S4 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้
- [C-1-1] ต้องป้อนสถานะเหล่านี้เฉพาะเมื่อปิดฝาอุปกรณ์
8.4 การทำบัญชีการใช้พลังงาน
การทำบัญชีและการรายงานการใช้พลังงานที่ถูกต้องแม่นยำมากขึ้นจะทำให้นักพัฒนาแอปได้รับทั้งสิ่งจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [SR] แนะนำอย่างเข้มงวดให้โปรไฟล์พลังงานต่อองค์ประกอบซึ่งระบุค่าการใช้งานปัจจุบันสำหรับส่วนประกอบฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์สของ Android
- [SR] แนะนำให้รายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิชั่วโมง (mAh)
- [SR] แนะนำอย่างยิ่งให้รายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [SR] แนะนำอย่างเข้มงวดเพื่อให้การใช้พลังงานนี้พร้อมใช้งานผ่านคำสั่ง Shell
adb shell dumpsys batterystats
ไปยังนักพัฒนาแอป - ควรมีแหล่งที่มาจากคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
8.5 ประสิทธิภาพที่สม่ำเสมอ
ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่มีประสิทธิภาพสูง ซึ่งเป็นผลมาจากแอปอื่นๆ ที่ทำงานอยู่เบื้องหลังหรือการควบคุม CPU เนื่องด้วยขีดจำกัดอุณหภูมิ Android มีอินเทอร์เฟซแบบเป็นโปรแกรมที่เมื่ออุปกรณ์สามารถทำงานได้ แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับต้นๆ จะสามารถขอให้ระบบเพิ่มประสิทธิภาพการจัดสรรทรัพยากรเพื่อจัดการกับความผันผวนดังกล่าวได้
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด
PowerManager.isSustainedPerformanceModeSupported()
API -
ควรรองรับโหมดประสิทธิภาพที่ยั่งยืน
หากการใช้งานอุปกรณ์รายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืน การตั้งค่าดังกล่าวจะมีผลดังนี้
- [C-1-1] ต้องให้ระดับประสิทธิภาพที่สม่ำเสมอแก่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนเป็นเวลาอย่างน้อย 30 นาทีเมื่อแอปขอ
- [C-1-2] ต้องใช้
Window.setSustainedPerformanceMode()
API และ API อื่นๆ ที่เกี่ยวข้อง
หากการใช้งานอุปกรณ์มี CPU 2 แกนขึ้นไป การใช้งานจะมีลักษณะดังต่อไปนี้
- ควรระบุ Core พิเศษอย่างน้อย 1 รายการที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนจะสงวนไว้
หากการใช้งานอุปกรณ์รองรับการจองแกนพิเศษ 1 แกนสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้ายอดนิยม อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรายงานหมายเลขรหัสของแกนพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าจองได้ผ่านเมธอด
Process.getExclusiveCores()
API - [C-2-2] ต้องไม่อนุญาตกระบวนการด้านพื้นที่ของผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อเรียกใช้บนแกนเฉพาะ แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น
หากอุปกรณ์ไม่รองรับการใช้งานอุปกรณ์หลัก (พิเศษ) ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้องส่งคืนรายการที่ว่างเปล่าผ่านเมธอด
Process.getExclusiveCores()
API
9. ความเข้ากันได้กับโมเดลความปลอดภัย
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารสำหรับนักพัฒนาซอฟต์แวร์ Android
-
[C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงชื่อด้วยตนเอง โดยไม่ต้องมีสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงาน กล่าวอย่างเจาะจงคือ อุปกรณ์ที่ใช้งานร่วมกันได้ต้องรองรับกลไกการรักษาความปลอดภัยดังที่อธิบายไว้ในส่วนย่อยดังต่อไปนี้
9.1 สิทธิ์
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องรองรับโมเดลสิทธิ์ของ Android ตามที่ระบุไว้ในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ Android กล่าวอย่างเจาะจงคือ ต้องบังคับใช้แต่ละสิทธิ์ตามที่กำหนดไว้ในเอกสาร SDK โดยห้ามละ แก้ไข หรือละเว้นสิทธิ์ใดๆ
-
อาจเพิ่มสิทธิ์เพิ่มเติม หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ
android.\*
-
[C-0-2] ต้องมอบสิทธิ์ที่มี
protectionLevel
เป็นPROTECTION_FLAG_PRIVILEGED
ให้เฉพาะแอปที่โหลดไว้ล่วงหน้าในเส้นทางที่มีสิทธิ์ของอิมเมจระบบและภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การใช้ AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและดำเนินการตามสิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทางetc/permissions/
และใช้เส้นทางsystem/priv-app
เป็นเส้นทางที่ได้รับสิทธิ์
สิทธิ์ที่มีระดับการป้องกันที่เป็นอันตรายคือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion
> 22 จะขอขณะรันไทม์
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะสำหรับผู้ใช้เพื่อตัดสินใจว่าจะให้สิ��ธิ์รันไทม์ตามที่ขอไหม รวมถึงต้องมีอินเทอร์เฟซให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย
- [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงรายการเดียวเท่านั้น
- [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งล่วงหน้า ยกเว้นในกรณีต่อไปนี้
- ต้องได้รับความยินยอมจากผู้ใช้ก่อนที่แอปพลิเคชันจะใช้
- สิทธิ์รันไทม์เชื่อมโยงกับรูปแบบ Intent ที่มีการตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
หากการใช้งานอุปกรณ์มีแอปที่ติดตั้งมาล่วงหน้า หรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [SR] ขอแนะนำเป็นอย่างยิ่งให้กลไกที่ผู้ใช้เข้าถึงได้เพื่อให้หรือเพิกถอนการเข้าถึงสถิติการใช้งานตาม Intent ของ
android.settings.ACTION_USAGE_ACCESS_SETTINGS
สำหรับแอปที่ประกาศสิทธิ์android.permission.PACKAGE_USAGE_STATS
หากการใช้งานอุปกรณ์ตั้งใจที่จะไม่อนุญาตแอปใดๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า ไม่ให้เข้าถึงสถิติการใช้งาน พวกเขาจะ:
- [C-1-1] ต้องมีกิจกรรมที่จัดการรูปแบบ Intent ของ
android.settings.ACTION_USAGE_ACCESS_SETTINGS
แต่ "ต้อง" ใช้แบบ "ไม่มีการดำเนินการ" กล่าวคือต้องมีลักษณะการทำงานที่เทียบเท่าเมื่อผู้ใช้ถูกปฏิเสธการเข้าถึง
9.2 การแยก UID และกระบวนการ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับโมเดลแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID ของ Unixstyle ที่ไม่ซ้ำกันและอยู่ในกระบวนการที่แยกจากกัน
- [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็นรหัสผู้ใช้ Linux เดียวกัน โดยมีการลงนามและการสร้างแอปพลิเคชันอย่างถูกต้องตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์
9.3 สิทธิ์ของระบบไฟล์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับโมเดลสิทธิ์การเข้าถึงไฟล์ Android ตามที่ระบุไว้ในข้อมูลอ้างอิงความปลอดภัยและสิทธิ์
9.4 สภาพแวดล้อมการดำเนินการสำรอง
การใช้งานอุปกรณ์ต้องรักษาความสอดคล้องของโมเดลการรักษาความปลอดภัยและสิทธิ์ของ Android แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นซึ่งไม่ใช่ Dalvik Executable Format หรือโค้ดแบบเนทีฟ กล่าวคือ
-
[C-0-1] รันไทม์สำรองต้องเป็นแอปพลิเคชัน Android เอง และปฏิบัติตามรูปแบบความปลอดภัยของ Android แบบมาตรฐานตามที่อธิบายไว้ในส่วนที่ 9
-
[C-0-2] รันไทม์ทางเลือกต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ป้องกันด้วยสิทธิ์ที่ไม่ได้ขอในไฟล์
AndroidManifest.xml
ของรันไทม์ผ่านกลไก <uses-permission
> -
[C-0-3] รันไทม์สำรองต้องไม่อนุญาตให้แอปพลิเคชันใช้ฟีเจอร์ที่ปกป้องโดยสิทธิ์ของ Android ซึ่งจำกัดไว้เฉพาะแอปพลิเคชันระบบ
-
[C-0-4] รันไทม์สำรองต้องเป็นไปตามโมเดลแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์อื่นต้องไม่นำแซนด์บ็อกซ์ของแอปอื่นๆ ที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นในกรณีที่ใช้กลไกมาตรฐานของ Android ที่แชร์รหัสผู้ใช้และใบรับรองที่ลงนาม
-
[C-0-5] รันไทม์สำรองต้องไม่เปิด ให้สิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ
-
[C-0-6] ต้องไม่เปิดตัว ให้รันไทม์สำรอง หรือให้สิทธิ์ของผู้ใช้ระดับสูง (รูท) หรือรหัสผู้ใช้อื่นๆ แก่แอปพลิเคชันอื่นๆ
-
[C-0-7] เมื่อรวมไฟล์
.apk
ของรันไทม์อื่นไว้ในอิมเมจระบบของการใช้งานอุปกรณ์ ไฟล์ "ต้อง" ต้องรับรองด้วยคีย์ที่ต่างจากคีย์ที่ใช้ในการลงนามแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการใช้งานอุปกรณ์ -
[C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์สำรองต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ของ Android ที่แอปพลิเคชันใช้
-
[C-0-9] เมื่อแอปพลิเคชันต้องใช้ทรัพยากรอุปกรณ์ที่ได้รับอนุญาตจาก Android ที่เกี่ยวข้อง (เช่น กล้องถ่ายรูป, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้
-
[C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่บันทึกความสามารถของแอปพลิเคชันในลักษณะนี้ สภาพแวดล้อมรันไทม์ต้องแสดงสิทธิ์ทั้งหมดที่รันไทม์นั้นเป็นเจ้าของเมื่อทำการติดตั้งแอปพลิเคชันใดๆ ที่ใ��้รันไทม์ดังกล่าว
-
รันไทม์สำรองควรติดตั้งแอปผ่าน
PackageManager
ลงในแซนด์บ็อกซ์ Android ที่แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ) -
รันไทม์สำรองอาจมีแซนด์บ็อกซ์ Android รายการเดียวที่แชร์โดยแอปพลิเคชันทั้งหมดที่ใช้รันไทม์สำรอง
9.5 การสนับสนุนผู้ใช้หลายคน
Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ
- การใช้งานอุปกรณ์อาจแต่ไม่ควรเปิดใช้ผู้ใช้หลายคน หากใช้สื่อแบบถอดได้เป็นที่จัดเก็บข้อมูลภายนอกหลัก
หากการติดตั้งใช้งานอุปกรณ์มีผู้ใช้หลายคน จะมีผลดังนี้
- [C-1-1] ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน
- [C-1-2] สำหรับผู้ใช้แต่ละราย ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API
- [C-1-3] ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก (หรือที่เรียกอีกชื่อหนึ่งว่า
/sdcard
) สำหรับอินสแตนซ์ของผู้ใช้แต่ละรายการ - [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และการเรียกใช้ในนามของผู้ใช้นั้นๆ ไม่สามารถแสดงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองจะจัดเก็บไว้ในระบบไฟล์หรือวอลุ่มเดียวกันก็ตาม
- [C-1-5] ต้องเข้ารหัสเนื้อหาในการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บอยู่ในสื่อที่นำออกไม่ได้ซึ่งเข้าถึงได้เฉพาะระบบเท่านั้นหากอุปกรณ์ใช้สื่อแบบถอดได้สำหรับ API การจัดเก็บข้อมูลภายนอก เนื่องจากการดำเนินการนี้จะทำให้พีซีที่เป็นโฮสต์อ่านสื่อไม่ได้ การใช้งานอุปกรณ์จึงจำเป็นจะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้
หากการใช้งานอุปกรณ์มีผู้ใช้หลายร��ย และไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์มีผู้ใช้หลายราย และประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องไม่รองรับโปรไฟล์ที่จำกัด แต่ต้องสอดคล้องกับการใช้ตัวควบคุมของ AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
9.6 คำเตือนทาง SMS แบบพรีเมียม
Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมที่ส่งออก ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการ ซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปซึ่งกำหนดไว้ในไฟล์
/data/misc/sms/codes.xml
ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ที่มีการติดตั้งใช้งานซึ่งเป็นไปตามข้อกำหนดนี้
9.7 ฟีเจอร์ความปลอดภัยของเคอร์เนล
แซนด์บ็อกซ์ของ Android ประกอบด้วยฟีเจอร์ที่ใช้ระบบควบคุมการเข้าถึง (MAC) ที่บังคับของ Security-Enhanced Linux (SELinux) การทำแซนด์บ็อกซ์ Seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่เดิม แม้จะใช้งาน SELinux หรือฟีเจอร์ด้านความปลอดภัยอื่นๆ ภายใต้เฟรมเวิร์กของ Android ก็ตาม
- [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดด้านความปลอดภัยและบล็อกโด��ฟีเจอร์ความปลอดภัยที่ใช้งานด้านล่างเฟรมเวิร์ก Android ได้สำเร็จ แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดด้านความปลอดภัยที่ไม่ได้บล็อก ซึ่งส่งผลให้การเจาะช่องโหว่สำเร็จ
- [C-0-3] ต้องไม่ทำให้ SELinux หรือฟีเจอร์ความปลอดภัยอื่นใดที่ใช้งานต่ำกว่าเฟรมเวิร์ก Android ที่กำหนดค่าได้สำหรับผู้ใช้หรือนักพัฒนาแอป
- [C-0-4] ต้องไม่อนุญาตแอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) เพื่อกำหนดค่านโยบายที่ละเมิดความเข้ากันได้
- [C-0-5] ต้องแบ่งเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการให้แคบลงได้ตามที่อธิบายไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนลที่อนุญาตให้กรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบหลายเธรด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางเป็นไปตามข้อกำหนดนี้ผ่านการเปิดใช้ seccomp-BPF ที่มีการซิงค์ข้อมูล Threadgroup (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่า Kernel ของ source.android.com
ความสมบูรณ์ของเคอร์เนลและฟีเจอร์การป้องกันตนเองเป็นส่วนสำคัญในการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์
- [C-0-7] ต้องใช้กลไกการป้องกันการล้นของสแต็กเคอร์เนล ตัวอย่างของกลไกดังกล่าวคือ
CC_STACKPROTECTOR_REGULAR
และCONFIG_CC_STACKPROTECTOR_STRONG
- [C-0-8] ต้องใช้การป้องกันหน่วยความจำของเคอร์เนลที่เข้มงวด โดยที่โค้ดสั่งการจะเป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวจะเป็นข้อมูลที่สั่งการไม่ได้และเขียนไม่ได้ และข้อมูลที่เขียนได้นั้นไม่สามารถเรียกใช้ได้ (เช่น
CONFIG_DEBUG_RODATA
หรือCONFIG_STRICT_KERNEL_RWX
) - [SR] แนะนำอย่างเข้มงวดให้เก็บข้อมูลเคอร์เนลที่จะเขียนเฉพาะในช่วงเริ่มต้นที่มีการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น
__ro_after_init
) - [SR} แนะนำอย่างยิ่งให้ใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่าง User-space และ Kernel-space (เช่น
CONFIG_HARDENED_USERCOPY
) - [SR] แนะนำอย่างยิ่งไม่ให้เรียกใช้หน่วยความจำพื้นที่ผู้ใช้เมื่อทำงานในเคอร์เนล (เช่น PXN ของฮาร์ดแวร์หรือจำลองผ่าน
CONFIG_CPU_SW_DOMAIN_PAN
หรือCONFIG_ARM64_SW_TTBR0_PAN
) - [SR] แนะนำอย่างยิ่งว่าอย่าอ่านหรือเขียนหน่วยความจำของพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึงผู้ใช้สำเนาปกติ (เช่น PAN ของฮาร์ดแวร์หรือจำลองผ่าน
CONFIG_CPU_SW_DOMAIN_PAN
หรือCONFIG_ARM64_SW_TTBR0_PAN
) - [SR] แนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และเพื่อหลีกเลี่ยงการเปิดเผยที่อาจเป็นอันตรายต่อการสุ่ม (เช่น
CONFIG_RANDOMIZE_BASE
ด้วยเอนโทรปี Bootloader ผ่าน/chosen/kaslr-seed Device Tree node
หรือEFI_RNG_PROTOCOL
)
หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลของ Linux สิ่งต่างๆ ต่อไปนี้จะเกิดขึ้น
- [C-1-1] ต้องใช้ SELinux
- [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
- [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดที่อนุญาต ซึ่งรวมถึงโดเมนเฉพาะสำหรับอุปกรณ์/ผู้ให้บริการรายใดรายหนึ่ง
- [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎNeverallow ที่อยู่ในโฟลเดอร์ระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ ไม่อนุญาตทั้งหมดที่มีอยู่ สำหรับโดเมน AOSP SELinux และโ��เมนเฉพาะอุปกรณ์/ผู้ให้บริการ
- ควรเก็บนโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ระบบ/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง และเพิ่มในนโยบายนี้เพิ่มเติมเฉพาะสำหรับการกำหนดค่าเฉพาะอุปกรณ์เท่านั้น
หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลอื่นๆ ที่ไม่ใช่ Linux เหตุการณ์ต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็นซึ่งเทียบเท่ากับ SELinux
9.8 ความเป็นส่วนตัว
9.8.1 ประวัติการใช้งาน
Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] จะต้องมีระยะเวลาเก็บรักษาประวัติผู้ใช้อย่างสมเหตุสมผล
- [SR] แนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการใช้งาน AOSP
9.8.2 กำลังบันทึกเสียง
หากการใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่บันทึกเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์ การดำเนินการดังกล่าวจะดำเนินการดังนี้
- [C-1-1] ต้องมีการแจ้งเตือนให้ผู้ใช้ทราบอย่างต่อเนื่องเมื่อใดก็ตามที่มีการเปิดใช้ฟังก์ชันนี้และตั้งใจจับภาพ/บันทึก
หากการใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ได้ทันที ซึ่งสามารถบันทึกเสียงแวดล้อมเพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องไม่จัดเก็บไว้ในพื้นที่เก็บข้อมูลในอุปกรณ์ถาวร หรือส่งไฟล์เสียงเสียงที่บันทึกออกมาจากอุปกรณ์ดังกล่าวหรือรูปแบบใดๆ ที่สามารถแปลงเป็นเสียงต้นฉบับหรือการส่งผ่านโทรสารได้ ยกเว้นในกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้
9.8.3 การเชื่อมต่อ
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์เหล่าน��้จะมีผลดังนี้
- [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้เพื่อขอคำยินยอมจากผู้ใช้ก่อนอนุญาตให้เข้าถึงเนื้อหาในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันผ่านพอร์ต USB
9.8.4 การจราจรของข้อมูลในเครือข่าย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันสำหรับที่เก็บผู้ออกใบรับรอง (CA) ที่ระบบเชื่อถือไว้ล่วงหน้าตามที่ให้ไว้ในโปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-2] ต้องจัดส่งพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า
- [C-0-3] ต้องแสดงคำเตือนแก่ผู้ใช้ที่ระบุว่าอาจมีการตรวจสอบการจราจรของข้อมูลในเครือข่าย เมื่อมีการเพิ่ม CA ระดับรูทของผู้ใช้
หากมีการกำหนดเส้นทางการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องแสดงคำเตือนแก่ผู้ใช้โดยระบุข้อใดข้อหนึ่งต่อไปนี้
- อาจมีการตรวจสอบการจราจรของข้อมูลในเครือข่ายดังกล่าว
- การจราจรของข้อมูลในเครือข่ายดังกล่าวจะส่งผ่านแอปพลิเคชัน VPN ที่เฉพาะเจาะจงซึ่งให้บริการ VPN
หากการใช้งานอุปกรณ์มีกลไกที่เปิดใช้อยู่โดยค่าเริ่มต้น ซึ่งกำหนดเส้นทางการรับส่งข้อมูลเครือข่ายผ่านพร็อกซีเซิร์ฟเวอร์หรือเกตเวย์ VPN (เช่น การโหลดบริการ VPN ล่วงหน้าโดยให้สิทธิ์ android.permission.CONTROL_VPN
) ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว เว้นแต่จะเปิดใช้ VPN โดย Device Policy Controller ผ่าน
DevicePolicyManager.setAlwaysOnVpnPackage()
ซึ่งในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับแจ้งเท่านั้น
9.9 การเข้ารหัสพื้นที่เก็บข้อมูล
หากการใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9.11.1 การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-1-1] ต้องรองรับการเข้ารหัสพื้นที่เก็บข้อมูลของข้อมูลส่วนตัวของแอปพลิเคชัน (
/data partition
) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (/sdcard partition
) ถ้าเป็นส่วนแบบถาวรและไม่สามารถนำออกได้ของอุปกรณ์
หากการใช้งานอุปกรณ์��องรับ��น้า���อล็อกที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9.11.1 �����ะ���องรับการเข้ารหัสพื้นที่เก็บข้อมูล��้วยประสิทธิภาพคริปโตม���ตรฐานการเข้ารหัสขั้นสูง (AES) ที่สูงกว่า 50 MiB/วินาที การดำเนินการดังกล่าวจะส่งผลดังนี้
-
[C-2-1] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าเริ่มต้นให้เสร็จสิ้น หากมีการเปิดตัวอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้วโดยปิดใช้การเข้ารหัสโดยค่าเริ่มต้น อุปกรณ์ดังกล่าวจะไม่สามารถปฏิบัติตามข้อกำหนดผ่านการอัปเดตซอฟต์แวร์ระบบ จึงอาจได้รับการยกเว้น
-
ควรปฏิบัติตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นผ่านการใช้การเข้ารหัสตามไฟล์ (FBE)
9.9.1 Direct Boot
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องใช้ API โหมดการเปิดเครื่องโดยตรง แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม
-
[C-0-2] ระบบต้องเผยแพร่ Intent ของ
ACTION_LOCKED_BOOT_COMPLETED
และACTION_USER_UNLOCKED
เพื่อส่งสัญญาณแจ้งแอปพลิเคชัน Direct Boot Aware ว่าผู้ใช้มีตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE)
9.9.2 การเข้ารหัสตามไฟล์
หากการติดตั้งใช้งานอุปกรณ์รองรับ FBE สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องเปิดเครื่องโดยไม่ให้ผู้ใช้ขอข้อมูลเข้าสู่ระบบและอนุญาตให้แอป Direct Boot ที่รู้จักเข้าถึงพื้นที่เก็บข้อมูล Device Encrypted (DE) หลังจากเผยแพร่ข้อความ
ACTION_LOCKED_BOOT_COMPLETED
- [C-1-2] ต้องอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสข้อมูลรับรอง (CE) เฉพาะหลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยป้อนข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลา��นิ้วมือ) และระบบเผยแพร่ข้อความ
ACTION_USER_UNLOCKED
- [C-1-3] ต้องไม่เสนอวิธีปลดล็อกพื้นที่เก็บข้อมูลที่มีการป้องกัน CE โดยไม่ต้องใช้ข้อมูลเข้าสู่ระบบที่ผู้ใช้ระบุ
- [C-1-4] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันและตรวจสอบว่าคีย์ DE เชื่อมโยงกับรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์แบบเข้ารหัส
- [C-1-5] ต้องรองรับการเข้ารหัสเนื้อหาของไฟล์โดยใช้ AES ที่มีความยาวคีย์ 256 บิตในโหมด XTS
-
[C-1-6] ต้องรองรับชื่อไฟล์การเข้ารหัสโดยใช้ AES ที่มีความยาวคีย์ 256 บิตในโหมด CBC-CTS
-
คีย์ที่ช่วยปกป้องพื้นที่เก็บข้อมูล CE และ DE มีดังนี้
-
[C-1-7] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์
- [C-1-8] คีย์ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้
- [C-1-9] คีย์ CE ต้องผูกกับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบในหน้าจอล็อก
-
[C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ ไม่มีคีย์ CE หรือ DE ของผู้ใช้ที่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
-
[C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่สนับสนุนซึ่งจำเป็นโดยค่าเริ่มต้น
-
ควรทำให้แอปสำคัญที่โหลดไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเซนเจอร์) Direct Boot
- อาจรองรับการเข้ารหัสอื่นๆ ความยาวคีย์ และโหมดสำหรับเนื้อหาไฟล์และการเข้ารหัสชื่อไฟล์
โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำโดยอิงตามฟีเจอร์การเข้ารหัส Kernel ext4 ของ Linux
9.9.3 การเข้ารหัสดิสก์เต็มรูปแบบ
หากการใช้งานอุปกรณ์รองรับการเข้ารหัสดิสก์เต็มรูปแบบ (FDE) ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องใช้ AES กับคีย์ขนาด 128 บิต (หรือสูงกว่า) และโหมดที่ออกแบบมาสำหรับพื้นที่เก็บข้อมูล (เช่น AES-XTS, AES-CBC-ESSIV)
- [C-1-2] ต้องใช้รหัสผ่านเริ่มต้นเพื่อรวมคีย์การเข้ารหัสและต้อ��ไม่เขียนคีย์การเข้ารหัสไปยังพื้นที่เก็บข้อมูลได้ทุกเมื่อโดยไม่มีการเข้ารหัส
- [C-1-3] ต้องให้ความเป็นไปได้แก่ผู้ใช้ AES จะเข้ารหัสคีย์การเข้ารหัส ยกเว้นกรณีที่ใช้งานอยู่ ซึ่งมีการยืดข้อมูลเข้าสู่ระบบหน้าจอล็อกโดยใช้อัลกอริทึมการขยายช้า (เช่น PBKDF2 หรือ scrypt)
- [C-1-4] อัลกอริทึมการขยายรหัสผ่านที่เป็นค่าเริ่มต้นข้างต้นจะต้องผูกกับแหล่งเก็บคีย์นั้นแบบเข้ารหัสในกรณีที่ผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกหรือได้ปิดใช้รหัสผ่านสำหรับการเข้ารหัสและอุปกรณ์มีคีย์สโตร์แบบฮาร์ดแวร์
- [C-1-5] ต้องไม่ส่งคีย์การเข้ารหัสออกไปนอกอุปกรณ์ (แม้ว่าจะพันด้วยรหัสผ่านของผู้ใช้และ/หรือคีย์ที่ผูกกับฮาร์ดแวร์ก็ตาม)
โปรเจ็กต์โอเพนซอร์ส Android ติดตั้งใช้งานฟีเจอร์นี้ที่ต้องการ โดยอิงตาม dm-crypt ของฟีเจอร์เคอร์เนลของ Linux
9.10 ความสมบูรณ์ของอุปกรณ์
ข้อกำหนดต่อไปนี้ช่วยให้สถานะความสมบูรณ์ของอุปกรณ์มีความโปร่งใส การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API
PersistentDataBlockManager.getFlashLockState()
ว่าสถานะ Bootloader อนุญาตให้มีการกะพริบอิมเมจของระบบหรือไม่ สถานะFLASH_LOCK_UNKNOWN
สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ระบบใหม่นี้
การเปิดเครื่องที่ได้รับการยืนยันคือฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการใช้งานอุปกรณ์รองรับฟีเจอร์นี้ ระบบจะดำเนินการดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์ของแพลตฟอร์ม
android.software.verified_boot
- [C-1-2] ต้องทำการยืนยันในทุกลำดับการเปิดเครื่อง
- [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือและไปจนถึงพาร์ติชันระบบ
- [C-1-4] ต้องใช้การยืนยันในแต่ละขั้นตอนเพื่อตรวจสอบความถูกต้องและความน่าเชื่อถือของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
- [C-1-5] ต้องใช้อัลกอริท��มการยืนยันที่มีความรัดกุมเช่นเดียวกับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
- [C-1-6] ต้องไม่อนุญาตให้เปิดเครื่องเมื่อการยืนยันระบบล้มเหล�� เว้นแต่��ู้ใช้ย����ยอมที่จะลองเปิดเครื่องต่อไป ซึ่งในกรณีนี้ ต้องไม่ใช้ข้อมูลจากการบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยัน
- [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้ได้ปลดล็อกตัวโหลดการเปิดเครื่องอย่างชัดเจน
- [SR] หากมีชิปหลายชิปในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์พิเศษ) ระบบจะแนะนำขั้นตอนการเปิดเครื่องของชิปแต่ละชิปดังกล่าวให้ยืนยันทุกขั้นตอนเมื่อเปิดเครื่อง
- [SR] แนะนำอย่างเข้มงวดให้ใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะเมื่อปลดล็อก Bootloader พื้นที่เก็บข้อมูลที่มีการงัดแงะหมายความว่าตัวโหลดการเปิดเครื่องสามารถตรวจสอบได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน HLOS (ระบบปฏิบัติการระดับสูง) หรือไม่
- [SR] แนะนําอย่างยิ่งให้แจ้งเตือนผู้ใช้ขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนอนุญาตให้เปลี่ยนจากโหมดล็อกตัวโหลดบูทเป็นโหมดปลดล็อกตัวโหลดการเปิดเครื่องเป็นโหมดปลดล็อกตัวโหลดการเปิดเครื่อง
- [SR] แนะนำอย่างยิ่งให้ใช้การป้องกันย้อนกลับสำหรับ HLOS (เช่น การเปิดเครื่อง พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่มีการแก้ไขที่ชัดเจนในการจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
- ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์ถาวร (เช่น โมเด็ม กล้อง) และควรใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะในการจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันขั้นต่ำที่อนุญาต
โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำในที่เก็บ external/avb/
ซึ่งสามารถผสานรวมเข้ากับ Boot Loader ที่ใช้สำหรับการโหลด Android
การใช้งานอุปกรณ์กับประสิทธิภาพคริปโตมาตรฐานการเข้ารหัสขั้นสูง (AES) ที่สูงกว่า 50 MiB/วินาที
- [C-2-1] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์
หากมีการเปิดตัวอุปกรณ์โดยไม่รองรับการเปิดเครื่องที่ได้รับการยืนยันใน Android เวอร์ชันก่อนหน้า อุปกรณ์ดังกล่าวจะไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเด��ซอฟต์แวร์ระบบ ดังนั้นจึงจะได้รับการยกเว้นจากข้อกำหนดดังกล่าว
9.11 คีย์และข้อมูลเข้าสู่ระบบ
ระบบคีย์สโตร์ของ Android ช่วยให้นักพัฒนาแอปสามารถจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์และใช้คีย์ดังกล่าวในการดำเนินการเข้ารหัสผ่าน KeyChain API หรือ Keystore API การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอนุญาตคีย์ที่จะนำเข้ามากกว่า 8,192 คีย์เป็นอย่างน้อย
- [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องมีการจำกัดอัตรา และต้องมีอัลกอริทึม Exponential Backoff หากเกินจากความพยายามที่ล้มเหลวเกิน 150 ครั้งแล้ว ความล่าช้าจะต้องมีอย่างน้อย 24 ชั่วโมงต่อความพยายามหนึ่งครั้ง
- ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้
เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องสำรองการใช้งานคีย์สโตร์ด้วยฮาร์ดแวร์ที่ปลอดภัย
- [C-1-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชตระกูล MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่รองรับระบบ Android Keystore อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามผ่านการตรวจสอบของการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแ��บแยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อทำสำเร็จเท่านั้น โปรเจ็กต์โอเพนซอร์ส Android มอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [C-1-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนามในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจต้องใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นไม่ให้มีข้อกำหนดให้ต้องมีคีย์สโตร์ที่อาศัยฮาร์ดแวร์และรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์แบบใช้ฮาร์ดแวร์
9.11.1 หน้าจอล็อกที่ปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งใช้ TrustAgentService
System API จะมีการดำเนินการต่อไปนี้
- [C-1-1] ต้องระบุผู้ใช้ในการตั้งค่าและอินเทอร์เฟซผู้ใช้แบบหน้าจอล็อกในกรณีที่ระบบเลื่อนการล็อกหน้าจออัตโนมัติ หรือเอเจนต์ความน่าเชื่อถือสามารถปลดล็อกหน้าจอได้ AOSP เป็นไปตามข้อกำหนดโดยแสดงข้อความอธิบายสำหรับเมนู "การตั้งค่าล็อกอัตโนมัติ" และ "การตั้งค่าปุ่มเปิด/ปิดล็อกการตั้งค่าทันที" และไอคอนแยกได้บนหน้าจอล็อก
- [C-1-2] ต้องเคารพและติดตั้งใช้งาน API ของเอเจนต์ความน่าเชื่อถือทั้งหมดในคลาส
DevicePolicyManager
เช่น ค่าคงที่KEYGUARD_DISABLE_TRUST_AGENTS
- [C-1-3] ต้องไม่ใช้ฟังก์ชัน
TrustAgentService.addEscrowToken()
โดยสมบูรณ์ในอุปกรณ์ที่ใช้เป็นอุปกรณ์หล��กส่วนตัว (เช่น อุปกรณ์พกพา) แต่อาจใช้ฟังก์ชันอย่างเต็มรูปแบบในการติดตั้งใช้งานอุปกรณ์ที่โดยปกติใช้����วมกัน - [C-1-4] ต้องเข้ารหัสโทเค็นที่เพิ่มโดย
TrustAgentService.addEscrowToken()
ก่อนจัดเก็บไว้ในอุปกรณ์ - [C-1-5] ต้องไม่เก็บคีย์การเข้ารหัสไว้ในอุปกรณ์
- [C-1-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นคนกลางเพื่อถอดรหัสพื้นที่เก็บข้อมูล
หากใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อก จะถือว่าวิธีการตรวจสอบสิทธิ์ดังกล่าวเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ
- [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน Requiring User Authentication For Key Use
- [C-2-2] ต้องปลดล็อกคีย์ทั้งหมดเพื่อให้แอปนักพัฒนาซอฟต์แวร์บุคคลที่สามใช้เมื่อผู้ใช้ปลดล็อกหน้าจอล็อกที่ปลอดภัย เช่น คีย์ทั้งหมดต้องพร้อมใช้งานสำหรับแอปนักพัฒนาซอฟต์แวร์ของบุคคลที่สามผ่าน API ที่เกี่ยวข้อง เช่น
createConfirmDeviceCredentialIntent
และsetUserAuthenticationRequired
หากใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกในกรณีที่อิงตามข้อมูลลับที่ทราบ จะถือว่าวิธีการตรวจสอบสิทธิ์ดังกล่า���เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ
- [C-3-1] เอนโทรปีของอินพุตที่มีความยาวสั้นที่สุดที่อนุญาตต้องมากกว่า 10 บิต
- [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
- [C-3-3] ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์ที่มีอยู่ (PIN,รูปแบบ, รหัสผ่าน) ที่นำไปใช้และระบุไว้ใน AOSP
- [C-3-4] ต้องปิดใช้เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด
DevicePolicyManager.setPasswordQuality()
ซึ่งมีคุณภาพคงที่มากกว่าPASSWORD_QUALITY_SOMETHING
หากใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกในกรณีที่อิงตามโทเค็นจริงหรือตำแหน่ง ระบบจะถือว่าวิธีการตรวจสอบสิทธิ์ดังกล่าวเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ
- [C-4-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและตรงตามข้อกำหนดจึงจะถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
- [C-4-2] ต้องป��ดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเฉพาะเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายด้วยเมธอด
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
หรือเมธอดDevicePolicyManager.setPasswordQuality()
ซึ่งมีคุณภาพคงที่มากกว่าPASSWORD_QUALITY_UNSPECIFIED
- [C-4-3] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลัก (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น
หากใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกตามข้อมูลไบโอเมตริก ระบบจะดำเนินการดังต่อไปนี้เพื่อให้วิธีการตรวจสอบสิทธิ์ดังกล่าวเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ
- [C-5-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตามข้อกำหนดจึงจะถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
- [C-5-2] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเฉพาะเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์คีย์การ์ดโดยเรียกใช้เมธอด
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)
- [C-5-3] ต้องมีอัตราการยอมรับที่เป็นเท็จซึ่งเท่ากับหรือดีกว่าที่กำหนดไว้สำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10 หรือ "ต้องปิดใช้" และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด
DevicePolicyManager.setPasswordQuality()
ซึ่งมีคุณภาพคงที่มากกว่าPASSWORD_QUALITY_BIOMETRIC_WEAK
เท่านั้น - [C-5-4] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลัก (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น
หากใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกและมีการใช้วิธีการตรวจสอบสิทธิ์ดังกล่าวเพื่อปลดล็อกการล็อกปุ่มกด แต่จะไม่ถือว่าเป็นหน้าจอล็อกที่ปลอดภัย การดำเนินการดังกล่าวจะส่งผลดังต่อไปนี้
- [C-6-1] ต้องแสดงผล
false
สำหรับทั้งเมธอดKeyguardManager.isKeyguardSecure()
และKeyguardManager.isDeviceSecure()
- [C-6-2] ต้องปิดใช้เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด
DevicePolicyManager.setPasswordQuality()
ซึ่งมีคุณภาพคงที่มากกว่าPASSWORD_QUALITY_UNSPECIFIED
- [C-6-3] ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่
DevicePolicyManager.setPasswordExpirationTimeout()
กำหนดไว้ - [C-6-4] ต้องไม่ตรวจสอบสิทธิ์การเข้าถึงคีย์สโตร์หากแอปพลิเคชันเรียกใช้
KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)
)
9.12 การลบข้อมูล
การติดตั้งใช้งานอุปกรณ์ทั้งหมด
- [C-0-1] ต้องระบุกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
- [C-0-2] ต้องลบข้อมูลที่ผู้ใช้สร้างขึ้นทั้งหมด ซึ่งก็คือข้อมูลทั้งหมดยกเว้นข้อมูลต่อไปนี้
- อิมเมจระบบ
- ไฟล์ระบบปฏิบัติการใดๆ ก็ตามที่ต้องใช้ในอ��มเมจระบบ
- [C-0-3] ต้องลบข้อมูลในลักษณะที่เป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
- [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอปตัวควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลักเรียกใช้ API ของ
DevicePolicyManager.wipeData()
- อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น
9.13 โหมดปลอดภัยเปิดเครื่อง
Android มีเซฟโหมดซึ่งช่วยให้ผู้ใช้เปิดเครื่องในโหมดที่อนุญาตให้ใช้เฉพาะแอประบบที่ติดตั้งล่วงหน้าและปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการเปิดเครื่องที่ปลอดภัย" ช่วยให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้
การใช้งานอุปกรณ์มีดังนี้
- [SR] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง
หากติดตั้งใช้งานอุปกรณ์ไว้ในโหมดปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
-
[C-1-1] ต้องระบุตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยแบบไม่สามารถขัดจังหวะจากแอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ ยกเว้นเมื่อแอปของบุคคลที่สามเป็นตัวควบคุมนโยบายด้านอุปกรณ์และได้ตั้งค่าแฟล็ก
UserManager.DISALLOW_SAFE_BOOT
เป็น "จริง" -
[C-1-2] ต้องให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้
-
ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยจากเมนูเปิดเครื่องโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเปิดเครื่องปกติ
9.14 การแยกระบบยานพาหนะ
อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายรถยนต์ เช่น CAN Bus
การแลกเปลี่ยนข้อมูลจะปลอดภัยได้ด้วยการใช้ฟีเจอร์ความปลอดภัยด้านล่างเลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายห��ือไม่ได้ตั้งใจกับระบบย่อยเหล่านี้
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจการทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์ให้ทำการเปลี่ยนแปลงน้อยที่สุดเท่าที่จะเป็นไปได้สำหรับข้อมูลอ้างอิงและการติดตั้งใช้งาน Android ที่ต้องการจากโปรเจ็กต์โอเพนซอร์สของ Android วิธีนี้จะช่วยลดความเสี่ยงในการเกิดข้อบกพร่องที่ก่อให้เกิดความไม่เข้ากันที่ต้องมีการปรับปรุงและอัปเดตอุปกรณ์ที่อาจเกิดขึ้น
10.1 ชุดเครื่องมือทดสอบความเข้ากันได้
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) จากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์
-
[C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS และการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ
CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง CTS เองอาจมีข้อบกพร่องอยู่ในตัวเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันต่างๆ แยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และเวอร์ชัน CTS เวอร์ชันต่างๆ อาจมีการเผยแพร่สำหรับ Android 8.0
การติดตั้งใช้งานอุปกรณ์
-
[C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์
-
ควรใช้การใช้งานการอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้มากที่สุดเท่าที่จะเป็นไปได้
10.2 ผู้ตรวจสอบ CTS
เครื่องมือตรวจสอบ CTS จะรวมอยู่ในชุดทดสอบความเข้ากันได้ โดยมีเป้าหมายให้เจ้าหน้าที่ดำเนินการทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติไม่สามาร��ทดสอบได้ เช่น กล้องและเซ็นเซอร์ทำงานได้อย่างถูกต้อง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องดำเนินการกับทุกกรณีที่เกี่ยวข้องในเครื่องมือยืนยัน CTS อย่างถูกต้อง
CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางชนิดด้วย
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีตัวตรวจวัดความเร่ง ตัวตรวจวัดความเร่งจะต้องดำเนินการกับกรอบการทดสอบความเร่งอย่างถูกต้องในเครื่องมือตรวจสอบ CTS
ระบบอาจข้ามหรือละเว้นกรอบการทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับในเอกสารคำจำกัดความความเข้ากันได้นี้
- [C-0-2] อุปกรณ์ทุกเครื่องและทุกบิลด์ต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ติดตั้งใช้งานอุปกรณ์จึงไม่คาดว่าจะเรียกใช้ CTS Verifier อย่างชัดแจ้งในบิลด์ที่แตกต่างกันเพียงเล็กน้อยเท่านั้น กล่าวโดยเจาะจงคือการนำอุปกรณ์ไปใช้งานที่แตกต่างจากการติดตั้งใช้งานที่ผ่านการตรวจสอบ CTS Verifier ผ่านชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมไว้ อาจข้ามการทดสอบ CTS Verifier ได้
11. ซอฟต์แวร์ที่อัปเดตได้
- [C-0-1] การใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "จริง" ซึ่งหมายความว่าอาจจำเป็นต้องรีสตาร์ทอุปกรณ์
วิธีการใดก็ได้สามารถใช้ได้ โดยมีเงื่อนไขว่าจะแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการใดต่อไปนี้จะสอดคล้องกับข้อกำหนดนี้
- การดาวน์โหลด "ผ่านอากาศ (OTA)" จะมีการอัปเดตแบบออฟไลน์ผ่านรีบูต
- อัปเดต "Tethered" ผ่าน USB จากโฮสต์ PC
-
การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนพื้นที่เก็บข้อมูลแบบถอดได้
-
[C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ต้องล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องเก็บรักษาข้อมูลส่วนตัวของแอปพลิเ��ชันและข้อมูลที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android อัปสตรีมมีกลไกการอัปเดตที่เป็นไปตามข้อกำหนดนี้
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่ออินเทอร์เน็ตที่ไม่มีการวัดปริมาณอินเทอร์เน็ต เช่น โปรไฟล์ 802.11 หรือ PAN ของบลูทูธ (เครือข่ายส่วนบุคคล) ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับการดาวน์โหลด OTA ที่มีการอัปเดตแบบออฟไลน์ผ่านรีบูต
สำหรับการใช้งานอุปกรณ์ที่กำลังเปิดตัวด้วย Android 6.0 ขึ้นไป กลไกการอัปเดตควรรองรับการตรวจสอบว่าอิมเมจระบบเป็นไบนารีเดียวกับผลลัพธ์ที่คาดไว้หลังจาก OTA การใช้ OTA แบบบล็อกในโปรเจ็กต์โอเพนซอร์ส Android ที่เพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้
นอกจากนี้ การใช้งานอุปกรณ์ควรรองรับการอัปเดตระบบ A/B AOSP ใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการเปิดเครื่อง
หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากที่เปิดตัวอุปกรณ์แล้ว แต่เป็นไปตามอายุการใช้งานผลิตภัณฑ์ที่สมเหตุสมผล ซึ่งพิจารณาร่วมกับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม
- [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่มีให้ใช้งาน ซึ่งสามารถนำไปใช้ตามกลไกที่อธิบายไว้
Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ หากระบบย่อยของการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy
12. บันทึกการเปลี่ยนแปลงของเอกสาร
สำหรับสรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้ ให้ทำดังนี้
หากต้องการดูสรุปการเปลี่ยนแปลงของแต่ละส่วน ให้ทำดังนี้
- บทนำ
- ประเภทอุปกรณ์
- ซอฟต์แวร์
- การจัดแพ็กเกจแอปพลิเคชัน
- มัลติมีเดีย
- เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
- ความเข้ากันได้ของฮาร์ดแวร์
- ประสิทธิภาพและศักยภาพ
- โมเดลความปลอดภัย
- การทดสอบความเข้ากันได้กับซอฟต์แวร์
- ซอฟต์แวร์ที่อัปเดตได้
- บันทึกการเปลี่ยนแปลงเอกสาร
- ติดต่อเรา
12.1 เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง
การเปลี่ยนแปลงจะมีการทำเครื่องหมายดังต่อไปนี้
-
CDD
การเปลี่ยนแปลงที่สำคัญเกี่ยวกับข้อกำหนดความเข้ากันได้ -
เอกสาร
แก้ไขหรือสร้างการเปลี่ยนแปลงที่เกี่ยวข้อง
เพื่อการแสดงผลที่ดีที่สุด ให้เพิ่มพารามิเตอร์ของ URL pretty=full
และ no-merges
ต่อท้าย URL ของบันทึกการเปลี่ยนแปลง
13. ติดต่อเรา
คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ครอบคลุม