1. ข้อมูลเบื้องต้น
เอกสารนี้แจกแจงข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้อุปกรณ์ใช้งานร่วมกับ Android 9 ได้
การใช้ "ต้อง" "ต้องไม่" "ต้องระบุ" "จะ" "จะไม่" "ไม่ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119
ตามที่ใช้ในเอกสารนี้ "ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" คือบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 9 "การใช้งานอุปกรณ์" หรือ "การใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น
หากต้องการรับการพิจารณาว่าเข้ากันได้กับ Android 9 การใช้งานอุปกรณ์จะต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ รวมถึงเอกสารใดๆ ที่รวบรวมผ่านการอ้างอิง
เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 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] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้มีโอกาสในการเปลี่ยนขนาดการแสดงผล (ความหนาแน่นของหน้าจอ)
หากการใช้งานอุปกรณ์เคลื่อนที่อ้างว่ารองรับการแสดงผลภาพที่มีช่วงการรับแสงสูงกว่าปกติถึง Configuration.isScreenHdr()
ระบบจะดำเนินการดังต่อไปนี้
- [7.1.4.5/H-1-1] ต้องโฆษณาการรองรับส่วนขยาย
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
และVK_EXT_hdr_metadata
การใช้งานอุปกรณ์เคลื่อนที่
- [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
) ไปยังแอปพลิเคชันเบื้องหน้า เหตุการณ์เหล่านี้ต้องไม่ใช้โดยระบบ และเมื่ออยู่นอกอุปกรณ์ Android ได้ (เช่น แป้นพิมพ์ฮาร์ดแวร์ภายนอกที่เชื่อมต่อกับอุปกรณ์ Android) - [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
- [7.2.4/H-SR] แนะนําอย่างยิ่งให้เปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ เป็นแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ
ACTION_ASSIST
เมื่อกดKEYCODE_MEDIA_PLAY_PAUSE
หรือKEYCODE_HEADSETHOOK
ค้างไว้ หากกิจกรรมเบื้องหน้าจัดการกิจกรรมการกดค้างเหล่านั้นไม่ได้ - [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 สำหรับเคอร์เนลและพื้นที่ผู้ใช้
หากการใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI แบบ 32 บิตเท่านั้น
-
[7.6.1/H-1-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 416 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง qHD (เช่น FWVGA)
-
[7.6.1/H-2-1] หน่วยความจำที่มีให้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 592 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง HD+ (เช่น HD, WSVGA)
-
[7.6.1/H-3-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
-
[7.6.1/H-4-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง QHD (เช่น QWXGA)
หากการใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI 64 บิต (มีหรือไม่มี ABI แบบ 32 บิต) ให้ทำดังนี้
-
[7.6.1/H-5-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง qHD (เช่น FWVGA)
-
[7.6.1/H-6-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง HD+ (เช่น HD, WSVGA)
-
[7.6.1/H-7-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
-
[7.6.1/H-8-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง QHD (เช่น QWXGA)
โปรดทราบว่า "หน่วยความจำที่มีให้สำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรไว้ให้คอมโพเนนต์ของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
หากการใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่าหรือเท่ากับ 1 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/H-9-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.ram.low
- [7.6.1/H-9-2] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 1.1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
หากการใช้งานอุปกรณ์พกพามีหน่วยความจำมากกว่า 1 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ จะเกิดสิ่งต่อไปนี้
- [7.6.1/H-10-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
- ควรประกาศแฟล็กฟีเจอร์
android.hardware.ram.normal
การใช้งานอุปกรณ์เคลื่อนที่
- [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 และมีการรองรับโหมด VR ระบบจะดำเนินการดังต่อไปนี้
- [7.9.1/H-1-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.vr.high_performance
- [7.9.1/H-1-2] ต้องมีแอปพลิเคชันที่ใช้งาน
android.service.vr.VrListenerService
ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่านandroid.app.Activity#setVrModeEnabled
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.2.3.1/H-0-1] ต้องมีแอปพลิเคชันที่จัดการ Intent
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
และACTION_CREATE_DOCUMENT
ตามที่อธิบายไว้ในเอกสาร SDK และมอบโอกาสในการเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้ APIDocumentsProvider
- [3.4.1/H-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์ - [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
- [3.8.1/H-SR] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ WidgetFeatures ในแอป
- [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.3/H-0-5] ต้องแสดงตัวเลือกที่มีให้ใน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือน - [3.8.3/H-SR] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแรกที่มีให้ผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ - [3.8.3/H-SR] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกทั้งหมดที่ให้ผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดในหน้าต่างแจ้งเตือน - [3.8.4/H-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย
หากการใช้งานอุปกรณ์เคลื่อนที่รองรับการดำเนินการของ "ผู้ช่วย" สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.4/H-SR] ขอแนะนำอย่างยิ่งให้ใช้การกดแป้น
HOME
ค้างไว้เป็นการโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 "คุณต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก" กล่าวคือ เป็นแอปที่ใช้VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
การใช้งานอุปกรณ์มือถือ Android รองรับหน้าจอล็อกจะส่งผลดังนี้
- [3.8.10/H-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9/H-1-1] ต้องใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสาร Android SDK
- [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่มีการจัดการผ่านแฟล็กฟีเจอร์
android.software.managed_users
ยกเว้นเมื่อกำหนดค่าอุปกรณ์ให้รายงานว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือเพื่อจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
การใช้งานอุปกรณ์เคลื่อนที่
- [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.16/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/วินาที
หากการใช้งานอุปกรณ์พกพามีฟีเจอร์ในการปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP หรือขยายขอบเขตของฟีเจอร์ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/H-1-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
- [8.3/H-1-2] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
การใช้งานอุปกรณ์เคลื่อนที่
- [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
การใช้งานอุปกรณ์เคลื่อนที่ที่รองรับหน้าจอล็อกที่ปลอดภัยจะส่งผลดังนี้
- [9.11/H-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปที่สั้นที่สุด นั่นคือเวลาเปลี่ยนจากการปลดล็อกมาเป็นสถานะล็อก ซึ่งต้องไม่เกิน 15 วินาที
- [9.11/H-1-2] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการซ่อนการแจ้งเตือนและปิดใช้การตรวจสอบสิทธิ์ทุกรูปแบบ ยกเว้นการตรวจสอบสิทธิ์หลักที่อธิบายไว้ในหน้าจอล็อกที่ปลอดภัยใน 9.11.1 AOSP มีคุณสมบัติตรงตามข้อกำหนดเป็นโหมดปิดล็อก
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")
หากการใช้งานอุปกรณ์โทรทัศน์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.5.3/T-1-1] ต้องรองรับกล้องภายนอกที่เชื่อมต่อผ่านพอร์ต USB นี้ แต่อาจไม่ได้เชื่อมต่อตลอดเวลา
หากอุปกรณ์ทีวีเป็นแบบ 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 ที่ความเร็ว 30 เฟรมต่อวินาที
การใช้งานอุปกรณ์ทีวีต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์ทีวีเพื่อรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้
- [5.3.1/T-SR] MPEG-2
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส H.264 ตามที่อธิบายไว้ในส่วนที่ 5.3.4 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.4.4/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาทีด้วย Basline Profile
- [5.3.4.4/T-1-2] HD 1080p ที่ 60 เฟรมต่อวินาทีเมื่อใช้โปรไฟล์หลัก
- [5.3.4.4/T-1-3] HD 1080p ที่ 60 ภาพต่อวินาทีด้วย High Profile ระดับ 4.2
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 ต้องรองรับการถอดรหัส H.265 ตามที่อธิบายไว้ในส่วน 5.3.5 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุด รวมถึงรายการต่อไปนี้
- [5.3.5.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีและมีโปรไฟล์หลักระดับ 4.1
หากอุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 รองรับการถอดรหัส H.265 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.5.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ Main Tier หลัก 10 ระดับ 5
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส VP8 ตามรายละเอียดในส่วนที่ 5.3.6 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.6.4/T-1-1] โปรไฟล์การถอดรหัสแบบ HD 1080p ที่ 60 เฟรมต่อวินาที
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 ต้องรองรับการถอดรหัส VP9 ตามที่อธิบายไว้ในส่วน 5.3.7 ที่อัตราเฟรมวิดีโอมาตรฐานและความละเอียดสูงสุด รวมถึงสิ่งต่อไปนี้
- [5.3.7.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีพร้อมโปรไฟล์ 0 (ความลึกของสี 8 บิต)
หากอุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 รองรับการถอดรหัส VP9 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [5.3.7.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 0 (ความลึกของสี 8 บิต)
- [5.3.7.5/T-2-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัสแบบ UHD ที่ความเร็ว 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.5.3/T-0-1] ต้องมีการรองรับระดับเสียงมาสเตอร์ของระบบและการลดระดับเสียงเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตส่งผ่านเสียงที่บีบอัด (ที่ไม่มีการถอดรหัสเสียงในอุปกรณ์)
- [5.8/T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI เพื่อเลือกความละเอียดสูงสุดที่รองรับอัตราการรีเฟรช 50Hz หรือ 60Hz สำหรับจอแสดงผลแบบใช้สายทั้งหมด
- [5.8/T-SR] ขอแนะนำอย่างยิ่งให้เสนอตัวเลือกอัตราการรีเฟรช HDMI ที่กำหนดค่าได้สำหรับจอแสดงผลแบบมีสายทั้งหมด
- [5.8/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการถอดรหัสสตรีมที่ปลอดภัยพร้อมกัน ขอแนะนำเป็นอย่างยิ่งให้ถอดรหัสแบบ 2 ไอน้ำพร้อมกันเป็นอย่างน้อย
- [5.8] ควรตั้งค่าอัตราการรีเฟรชโหมดเอาต์พุต HDMI เป็น 50 Hz หรือ 60 Hz ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอในภูมิภาคที่ขายอุปกรณ์สำหรับจอแสดงผลแบบใช้สายทั้งหมด
หากการใช้งานอุปกรณ์ทีวีรองรับการถอดรหัส UHD และรองรับจอแสดงผลภายนอก ระบบจะดำเนินการต่อไปนี้
- [5.8/T-1-1] ต้องรองรับ HDCP 2.2
หากการใช้งานอุปกรณ์ทีวีไม่รองรับการถอดรหัส UHD แต่รองรับจอแสดงผลภายนอก ระบบจะดำเนินการต่อไปนี้
- [5.8/T-2-1] ต้องรองรับ HDCP 1.4
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.3.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/วินาที
หากการใช้งานอุปกรณ์ทีวีมีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/T-1-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
- [8.3/T-1-2] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
การติดตั้งใช้งานอุปกรณ์ทีวี
- [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.4.4 ประสิทธิภาพและศักยภาพ
หากการใช้งานอุปกรณ์นาฬิกามีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ต่างๆ ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีผลดังนี้
- [8.3/W-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
- [8.3/W-SR] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้สามารถเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
ดูการติดตั้งใช้งานอุปกรณ์
- [8.4/W-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/W-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/W-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/W-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านคำสั่ง Shell
adb shell dumpsys batterystats
- [8.4/W] ควรระบุว่ามาจากคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
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
หากการใช้งานอุปกรณ์ยานยนต์รวมถึงเครื่องวัดการหมุน จะมีการดำเนินการดังนี้
- [7.3.4/A-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.3.11/A-0-1] ต้องระบุเครื่องมือปัจจุบันเป็น
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.4/A-0-1] ต้องระบุความเร็วของยานพาหนะตามที่กำหนดโดย
SENSOR_TYPE_CAR_SPEED
-
[7.3.11.5/A-0-1] ต้องระบุสถานะเบรกจอดรถตามที่กำหนดโดย
SENSOR_TYPE_PARKING_BRAKE
-
[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-SR] ได้รับการแนะนำอย่างยิ่งให้รองรับ Message Access Profile (MAP)
-
[7.4.5/A] ควรมีการรองรับการเชื่อมต่อข้อมูลตามเครือข่ายมือถือ
-
[7.4.5/A] อาจใช้ค่าคงที่
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
ของระบบสำหรับเครือข่ายที่ควรใช้งานได้ในแอประบบ -
[7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.6.1/A] ควรจัดรูปแบบพาร์ติชันข้อมูลเพื่อเพิ่มประสิทธิภาพและอายุใช้งานของพื้นที่เก็บข้อมูล Flash เช่น ใช้ระบบไฟล์
f2fs
หากการใช้งานอุปกรณ์ Automotive มีพื้นที่เก็บข้อมูลภายนอกที่แชร์ผ่านส่วนหนึ่งของพื้นที่เก็บข้อมูลภายในแบบถอดไม่ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/A-SR] ขอแนะนำเป็นอย่างยิ่งให้ลดค่าใช้จ่ายในการดำเนินการ I/O สำหรับการดำเนินการบนพื้นที่เก็บข้อมูลภายนอก เช่น โดยใช้
SDCardFS
หากใช้อุปกรณ์ 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] ต้องรองรับ 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-SR] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
-
[3.13/A-SR] ขอแนะนำอย่างยิ่งให้รวมคอมโพเนนต์ UI ของการตั้งค่าด่วน
หากการใช้งานอุปกรณ์ยานยนต์มีปุ่มกดเพื่อพูด ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [3.8.4/A-1-1] ต้องใช้การกดปุ่ม Push-to-Talk สั้นๆ เป็นการโต้ตอบที่กำหนดเพื่อเปิดแอปช่วยเหลือที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้
VoiceInteractionService
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.14/A-0-1] ต้องระบุเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วน 3.14
2.5.4 ประสิทธิภาพและศักยภาพ
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีฟีเจอร์สำหรับปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/A-1-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
- [8.3/A-1-2] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [8.2/A-0-1] ต้องรายงานจำนวนไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลที่ไม่ผันผวนต่อ UID ของกระบวนการแต่ละรายการ เพื่อให้นักพัฒนาซอฟต์แวร์ดูสถิติได้ผ่าน System API
android.car.storagemonitoring.CarStorageMonitoringManager
โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของuid_sys_stats
- [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.5.5 โมเดลการรักษาความปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับผู้ใช้หลายคน สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/A-1-1] ต้องระบุบัญชีผู้มาเยือนที่อนุญาตฟังก์ชันทั้งหมดของระบบในรถโดยที่ผู้ใช้ไม่ต้องเข้าสู่ระบบ
หากการใช้งานอุปกรณ์ยานยนต์รองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.9.2/A-1-1] ต้องรองรับการเข้ารหัสต่อคีย์การตรวจสอบสิทธิ์เฉพาะผู้ใช้ การเข้ารหัสตามไฟล์ (FBE) เป็นวิธีหนึ่งที่ทำได้
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [9.14/A-0-1] ต้องระบุข้อความที่ปลอดภัยจากระบบย่อยของยานพาหนะที่ใช้เฟรมเวิร์ก Android เช่น การอนุญาตประเภทข้อความที่อนุญาตและแหล่งที่มาของข้อความ
- [9.14/A-0-2] ต้องเฝ้าระวังการโจมตีแบบปฏิเสธการให้บริการจากเฟรมเวิร์กของ Android หรือแอปของบุคคลที่สาม การดำเนินการนี้จะป้องกันซอฟต์แวร์ที่เป็นอันตรายที่ทำให้การจราจรคล่องตัวในเครือข่ายของรถ ซึ่งอาจนำไปสู่ระบบย่อยของยานพาหนะที่ทำงานผิดพลาด
2.6 ข้อกำหนดสำหรับแท็บเล็ต
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่ตรงตามเกณฑ์ต่อไปนี้ทั้งหมด
- โดยทั่วไปจะใช้โดยจับด้วยมือทั้ง 2 ข้าง
- ไม่มีการกำหนดค่าแบบฝาพับหรือแบบพับจอได้
- การใช้แป้นพิมพ์จริงที่ใช้กับอุปกรณ์ต้องเชื่อมต่อด้วยการเชื่อมต่อมาตรฐาน
- มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- มีขนาดหน้าจอในแนวทแยงมุม 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 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้
-
[C-0-5] ต้องจำกัดการใช้ API ที่ซ่อนไว้ของแอปบุคคลที่สาม ซึ่งก็คือ API ในเนมสเปซ Android ที่ตกแต่งด้วยคำอธิบายประกอบ
@hidden
แต่ไม่ใช่ด้วย@SystemAPI
หรือ@TestApi
ตามที่อธิบายไว้ในเอกสาร SDK และจัดส่งไปพร้อมกับ API ทั้งหมดที่ซ่อนไว้ในรายการที่จำกัดเดียวกันกับที่ระบุผ่านรายการชั่วคราวและไฟล์รายการที่ปฏิเสธในเส้นทางprebuilts/runtime/appcompat/
สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP อย่างไรก็ตาม- อาจหากไม่มี API ที่ซ่อนไว้หรือมีการใช้งานที่ต่างจากเดิมในการติดตั้งใช้งานอุปกรณ์ ให้ย้าย API ที่ซ่อนอยู่ไปยังรายการที่ไม่อนุญาตหรือยกเว้น API ดังกล่าวจากรายการที่ถูกจำกัดทั้งหมด
- หากยังไม่มี API ที่ซ่อนไว้ใน AOSP ให้เพิ่ม API ที่ซ่อนไว้ลงในรายการที่ถูกจำกัด
- อาจใช้กลไกการอัปเดตแบบไดนามิกที่ย้าย API ที่ซ่อนอยู่จากรายการที่ถูกจำกัดไปยังรายการที่จำกัดน้อยกว่า ยกเว้นรายการที่อนุญาต
3.1.1. ส่วนขยาย Android
Android มีการรองรับการขยาย API ที่มีการจัดการโดยที่ยังคงใช้เวอร์ชัน API ระดับเดิมต่อไปได้
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ Android ต้องโหลดการใช้งาน AOSP ของทั้งไลบรารีที่ใช้ร่วมกัน
ExtShared
และบริการExtServices
ที่มีเวอร์ชันสูงกว่าหรือเท่ากับเวอร์ชันขั้นต่ำที่อนุญาตต่อ API แต่ละระดับล่วงหน้า ตัวอย่างเช่น การใช้งานอุปกรณ์ Android 7.0 ที่ใช้ API ระดับ 24 จะต้องมีเวอร์ชัน 1 เป็นอย่างน้อย
3.1.2. ไลบรารี Android
การติดตั้งใช้งานอุปกรณ์จะเกิดขึ้นเนื่องจากการเลิกใช้งานไคลเอ็นต์ Apache HTTP
- [C-0-1] ต้องไม่วางไลบรารี
org.apache.http.legacy
ใน Bootclasspath - [C-0-2] ต้องเพิ่มไลบรารี
org.apache.http.legacy
ไปยังคลาสพาธของแอปพลิเคชันเฉพาะเมื่อแอปเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- กำหนดเป้าหมาย API ระดับ 28 หรือต่ำกว่า
- ประกาศในไฟล์ Manifest ว่าต้องมีไลบรารีโดยการตั้งค่าแอตทริบิวต์
android:name
ของ<uses-library>
เป็นorg.apache.http.legacy
การติดตั้งใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้
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 ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน 9 |
VERSION.SDK | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 9 ช่องนี้ต้องมีค่าจำนวนเต็ม 9_INT |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 9 ช่องนี้ต้องมีค่าจำนวนเต็ม 9_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_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ซีเรียล | ต้องส่งคืน "UNKNOWN" |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม 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._-,]+$” |
getSerial() | ต้อง (หรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องมีและไม่ซ้ำกันในอุปกรณ์ที่มี MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น 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 สำหรับรูปแบบตัวกรอง 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 เริ่มต้น -
[C-2-2] ต้องเป็นไปตาม Intent ของ
android.telecom.action.CHANGE_DEFAULT_DIALER
ในการแสดงกล่องโต้ตอบเพื่อให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้นได้- ต้องใช้ UI ของแอปโทรศัพท์เริ่มต้นที่ผู้ใช้เลือกสำหรับการโทรเข้าและโทรออก ยกเว้นการโทรหาหมายเลขฉุกเฉิน ซึ่งจะใช้แอปโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า
-
[C-2-3] ต้องปฏิบัติตามเจตนาของ android.telecom.action.CHANGE_PHONE_ACCOUNTS เพื่อให้ผู้ใช้สามารถกำหนดค่า
ConnectionServices
ที่เชื่อมโยงกับPhoneAccounts
รวมถึงบัญชีโทรศัพท์เริ่มต้นที่ผู้ให้บริการโทรคมนาคมจะใช้ในการโทรออก การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยใส่เมนู "ตัวเลือกบัญชีการโทร" ไว้ในเมนูการตั้งค่า "การโทร"
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องปฏิบัติตาม Intent android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการแตะและจ่าย
หากการติดตั้งใช้งานอุปกรณ์รองรับ VoiceInteractionService
และมีแอปพลิเคชันที่ใช้ API นี้ติดตั้งมากกว่า 1 แอปพลิเคชันพร้อมกัน ระบบจะดำเนินการต่อไปนี้
- [C-4-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-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 ต่อไปนี้ที่ระบุไว้ข้างต้น และต้องไม่รายงาน ABI ใดๆ ที่ไม่ได้อยู่ในรายการ โดยใช้พารามิเตอร์ข้างต้น
-
armeabi
-
armeabi-v7a
-
arm64-v8a
-
x86
-
x86-64
-
[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 (ห้องสมุดคณิตศาสตร์)
- libneuralnetworks.so (API เครือข่ายประสาทเทียม)
- 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 รุ่นต่อๆ ไปอาจเพิ่มการรองรับ ABI เพิ่มเติม
3.3.2 ความเข้ากันได้กับโค้ดแบบเนทีฟของ ARM 32 บิต
การนำอุปกรณ์ไปใช้รายงานการรองรับ ABI ของ armeabi
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องรองรับ
armeabi-v7a
และรายงานการรองรับด้วย เนื่องจากarmeabi
มีไว้สำหรับความเข้ากันได้แบบย้อนหลังกับแอปรุ่นเก่าเท่านั้น
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ ABI ของ armeabi-v7a
สําหรับแอปที่ใช้ ABI นี้ ระบบจะดำเนินการดังนี้
-
[C-2-1] ต้องระบุบรรทัดต่อไปนี้ใน
/proc/cpuinfo
และไม่ควรเปลี่ยนค่าในอุปกรณ์เดียวกัน แม้ว่า ABI อื่นๆ จะอ่านค่าก็ตาม-
Features:
ตามด้วยรายการฟีเจอร์เสริมของ CPU ARMv7 ที่อุปกรณ์รองรับ -
CPU architecture:
ตามด้วยจำนวนเต็มที่อธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)
-
-
[C-2-2] ต้องทำให้การดำเนินการต่อไปนี้พร้อมใช้งานเสมอ แม้ในกรณีที่มีการใช้ ABI ในสถาปัตยกรรม ARMv8 ไม่ว่าจะผ่านการรองรับ CPU ในระบบหรือผ่านการจำลองซอฟต์แวร์ก็ตาม
- วิธีการสำหรับ SWP และ SWPB
- SETEND คำสั่ง
- การดำเนินงานที่เป็นอุปสรรคของ CP15ISB, CP15DSB และ CP15DMB
-
[C-2-3] ต้องมีการรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)
3.4 ความเข้ากันได้กับเว็บ
3.4.1 ความเข้ากันได้กับ WebView
หากการติดตั้งใช้งานอุปกรณ์ทำให้การใช้งาน API ของ android.webkit.Webview
เสร็จสมบูรณ์ จะมีผลดังนี้
- [C-1-1] ต้องรายงาน
android.software.webview
- [C-1-2] ต้องใช้บิลด์ของโปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางใน Android 9 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/$(BUILD)" ได้ แต่หากแสดง สตริง $(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
การติดตั้งใช้งานอุปกรณ์
- [C-0-9] ต้องตรวจสอบว่ามีการใช้ความเข้ากันได้ของลักษณะการทำงานของ API กับแอปที่ติดตั้งไว้ทั้งหมด เว้นแต่จะถูกจำกัดไว้ตามที่อธิบายไว้ในส่วนที่ 3.5.1
- [C-0-10] ต้องไม่ใช้แนวทางการให้อนุญาตที่รับรองความเข้ากันได้ด้านลักษณะการทำงานของ 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 ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
- [C-0-9] อุปกรณ์ต้องแสดงผู้ให้บริการการรักษาความปลอดภัยต่อไปนี้เป็นค่าอาร์เรย์ 7 ค่าแรกจากเมธอด
Security.getProviders()
ตามลำดับที่ระบุ (ตามที่Provider.getName()
ส่งคืน) และคลาส เว้นแต่แอปได้แก้ไขรายการผ่านinsertProviderAt()
หรือremoveProvider()
อุปกรณ์อาจส่งคืนผู้ให้บริการเพิ่มเติมหลังจากรายชื่อผู้ให้บริการที่ระบุด้านล่าง-
AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
-
AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
-
CertPathProvider -
sun.security.provider.CertPathProvider
-
AndroidKeyStoreBCวิธีแก้ปัญหา -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
-
BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
-
HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
-
AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
-
AndroidNSSP -
รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น ความเข้ากันได้ Test Suite (CTS) จะทดสอบความเข้ากันได้ของแพลตฟอร์มในส่วนประกอบสำคัญ แต่ไม่ใช่ทั้งหมด ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ด้านพฤติกรรมกับโครงการโอเพนซอร์ส Android ด้วยเหตุนี้ ผู้ติดตั้งอุปกรณ์จึงควรใช้ซอร์สโค้ดที่มีให้ผ่านทางโครงการโอเพนซอร์ส Android หากทำได้ แทนการนำส่วนต่างๆ ที่สำคัญของระบบมาใช้ใหม่
3.5.1 การจำกัดการทำงานในเบื้องหลัง
หากการนำอุปกรณ์ปรับใช้ข้อจำกัดของแอปที่รวมอยู่ใน AOSP หรือขยายข้อจำกัดของแอป จะมีผลดังนี้
- [C-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในกรณีที่ผู้ใช้สามารถดูรายการแอปที่ถูกจำกัดได้
- [C-1-2] ต้องให้เงินแก่ผู้ใช้ในการเปิด / ปิดข้อจำกัดของแต่ละแอป
- [C-1-3] ต้องไม่ใช้ข้อจำกัดโดยอัตโนมัติโดยไม่มีหลักฐานแสดงลักษณะการทำงานของระบบที่ไม่ดี แต่อาจใช้การจำกัดกับแอปเมื่อตรวจพบพฤติกรรมการทำงานที่ไม่ดีของระบบ เช่น การทำงานขณะล็อกที่ค้าง บริการที่ทำงานเป็นเวลานาน และเกณฑ์อื่นๆ เกณฑ์อาจกำหนดโดยผู้ติดตั้งใช้งานอุปกรณ์ แต่ต้องเกี่ยวข้องกับผลกระทบที่แอปมีต่อประสิทธิภาพของระบบ เกณฑ์อื่นๆ ที่ไม่ได้เกี่ยวข้องกับประสิทธิภาพการทำงานของระบบเพียงอย่างเดียว เช่น แอปไม่ได้รับความนิยมในตลาด ต้องไม่ใช้เป็นเกณฑ์
- [C-1-4] ต้องไม่ใช้การจำกัดแอปโดยอัตโนมัติกับแอป เมื่อผู้ใช้ปิดการจำกัดแอปด้วยตนเอง และอาจแนะนำให้ผู้ใช้ใช้การจำกัดแอป
- [C-1-5] ต้องแจ้งให้ผู้ใช้ทราบเมื่อมีการนำข้อจำกัดของแอปไปใช้กับแอปโดยอัตโนมัติ
- [C-1-6] ต้องแสดงผล
true
สำหรับActivityManager.isBackgroundRestricted()
เมื่อแอปที่ถูกจำกัดเรียกใช้ API นี้ - [C-1-7] ต้องไม่จำกัดแอปที่ทำงานอยู่เบื้องหน้าด้านบนที่ผู้ใช้มีการใช้งานอย่างชัดเจน
- [C-1-8] ต้องระงับการจำกัดในแอปที่จะกลายเป็นแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าเมื่อผู้ใช้เริ่มใช้แอปที่เคยถูกจำกัดอย่างชัดแจ้ง
3.6 เนมสเปซ API
Android เป็นไปตามแบบแผนเนมสเปซของแพ็กเกจและคลาสที่กำหนดโดยภาษาในการเขียนโปรแกรม Java ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่ทำการแก้ไขที่ไม่ได้รับอนุญาต (ดูด้านล่าง) กับเนมสเปซแพ็กเกจเหล่านี้เพื่อให้เข้ากันได้กับแอปพลิเคชันของบุคคลที่สาม
-
java.*
-
javax.*
-
sun.*
-
android.*
-
androidx.*
-
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-2-3] ต้องรองรับแป้นพิมพ์ลัดที่ปักหมุดไว้ รวมถึงทางลัดแบบไดนามิกและแบบคงที่ตามที่ระบุไว้ในหน้าทางลัดของแอป
ในทางกลับกัน หากอุปกรณ์ไม่รองรับการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องรายงาน
false
สำหรับShortcutManager.isRequestPinShortcutSupported()
หากการใช้อุปกรณ์ใช้ 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-1-7] ต้องแสดงผลทรัพยากรทั้งหมด (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่จัดเตรียมไว้อย่างถูกต้องผ่าน Notification.MessagingStyle พร้อมกับข้อความแจ้งเตือนโดยไม่ต้องโต้ตอบกับผู้ใช้เพิ่มเติม เช่น "ต้อง" แสดงทรัพยากรทั้งหมดรวมถึงไอคอนที่มีให้ผ่าน android.app.Person ในการสนทนากลุ่มที่ตั้งค่าไว้ผ่าน setGroupConversation
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแก่ผู้ใช้โดยอัตโนมัติในการบล็อกการแจ้งเตือนของแอปของบุคคลที่สามสำหรับช่องทางและระดับแพ็กเกจแอปแต่ละรายการ หลังจากที่ผู้ใช้ปิดการแจ้งเตือนหลายครั้งแล้ว
- ควรรองรับการแจ้งเตือนที่สมบูรณ์
- ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
- ผู้ใช้ควรสามารถเลื่อนการแจ้งเตือน
- อาจจัดการได้เฉพาะระดับการเข้าถึงและช่วงเวลาที่แอปของบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์ที่น่าจดจำ เพื่อลดปัญหาด้านความปลอดภัย เช่น การรบกวนผู้ขับขี่
หากอุปกรณ์รองรับการแจ้งเตือนที่สมบูรณ์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้ทรัพยากรตามที่ระบุไว้ผ่านคลาส API
Notification.Style
และคลาสย่อยสำหรับองค์ประกอบทรัพยากรที่แสดงอยู่ - ควรนำเสนอองค์ประกอบทรัพยากรแต่ละรายการ (เช่น ไอคอน ชื่อ และข้อความสรุป) ที่กำหนดไว้ในคลาส API
Notification.Style
และคลาสย่อย
หากการใช้งานอุปกรณ์รองรับการแจ้งเตือนล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้มุมมองการแจ้งเตือนล่วงหน้าและทรัพยากรตามที่อธิบายไว้ในคลาส API ของ
Notification.Builder
เมื่อมีการแสดงการแจ้งเตือนล่วงหน้า - [C-3-2] ต้องแสดงการดำเนินการที่ได้รับจาก
Notification.Builder.addAction()
ร่วมกับเนื้อหาการแจ้งเตือน โดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ตามที่อธิบายไว้ใน SDK
3.8.3.2 บริการฟังการแจ้งเตือน
Android มี API ของ NotificationListenerService
ที่อนุญาตให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง) เพื่อรับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต
หากการติดตั้งใช้งานอุปกรณ์รายงานแฟล็กฟีเจอร์ android.hardware.ram.normal
การดำเนินการต่อไปนี้
- [C-1-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงทีในบริการ Listener ที่ติดตั้งและเปิดใช้งานดังกล่าวทั้งหมด รวมถึงข้อมูลเมตาทั้งหมดที่แนบกับออบเจ็กต์การแจ้งเตือน
- [C-1-2] ต้องเป็นไปตามการเรียกใช้ API
snoozeNotification()
และปิดการแจ้งเตือนและทำการติดต่อกลับหลังจากระยะเวลาเลื่อนการแจ้งเตือนซึ่งกำหนดไว้ในการเรียก API
หากการติดตั้งอุปกรณ์ทำให้ผู้ใช้สามารถปิดการแจ้งเตือนชั่วคราวได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงสถานะการแจ้งเตือนเลื่อนการแจ้งเตือนอย่างถูกต้องผ่าน API มาตรฐาน เช่น
NotificationListenerService.getSnoozedNotifications()
- [C-2-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
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] ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 7 รายการ
- ควรแสดงชื่อกิจกรรม 4 รายการต่อครั้งเป็นอย่างน้อย
- [C-1-2] ต้องใช้ลักษณะการตรึงหน้าจอ และให้เมนูการตั้งค่าแก่ผู้ใช้เพื่อสลับฟีเจอร์นี้
- ควรแสดงสีไฮไลต์ ไอคอน และชื่อหน้าจอในช่วงล่าสุด
- ควรแสดงราคาปิด ("x") แต่อาจล่าช้าจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ
- ควรใช้ทางลัดเพื่อสลับไปยังกิจกรรมก่อนหน้าได้อย่างง่ายดาย
- ควรทริกเกอร์การทำงานการสลับอย่างรวดเร็วระหว่างแอปที่ใช้ล่าสุด 2 แอป เมื่อแตะปุ่มฟังก์ชันล่าสุด 2 ครั้ง
- ควรเรียกใช้โหมดหลายหน้าต่างแยกหน้าจอ (หากรองรับ) เมื่อกดแป้นฟังก์ชันล่าสุดค้างไว้
- อาจแสดงรายการล่าสุดที่เชื่อมโยงเป็นกลุ่มที่ย้ายไปด้วยกัน
- [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-2] ต้องแสดงสถานะปัจจุบันของตำแหน่งในเมนู "ตำแหน่ง" ภายใน "การตั้งค่า"
- [C-1-3] ต้องไม่แสดงโหมดตำแหน่งในเมนู "ตำแหน่ง" ภายใน "การตั้งค่า"
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.8.15 หน้าจอรอยบาก
Android รองรับหน้าจอรอยบากตามที่อธิบายไว้ในเอกสาร SDK DisplayCutout
API กำหนดพื้นที่ขอบของจอแสดงผลที่ไม่สามารถแสดงเนื้อหาได้
หากการใช้งานอุปกรณ์รวมหน้าจอรอยบากไว้ จะมีผลดังนี้
- [C-1-1] ต้องมีเฉพาะรอยบากที่ขอบด้านสั้นๆ ของอุปกรณ์ ในทางกลับกัน หากสัดส่วนภาพของอุปกรณ์คือ 1.0(1:1) อุปกรณ์ต้องไม่มีคัตเอาต์
- [C-1-2] ต้องไม่มีคัตเอาต์มากกว่า 1 คัตเอาต์ต่อขอบ
- [C-1-3] ต้องปฏิบัติตาม Flag หน้าจอรอยบากที่แอปกำหนดผ่าน
WindowManager.LayoutParams
API ตามที่อธิบายไว้ใน SDK - [C-1-4] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกคัตเอาต์ทั้งหมดที่กำหนดไว้ใน
DisplayCutout
API
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
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.9.3 การสนับสนุนผู้ใช้ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
- [C-1-1] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการออกจากระบบของผู้ใช้ปัจจุบัน และสลับกลับไปเป็นผู้ใช้หลักในเซสชันที่มีผู้ใช้หลายคนเมื่อ
isLogoutEnabled
แสดงผลtrue
ราคาที่ผู้ใช้ต้องเข้าถึงได้จากหน้าจอล็อกโดยไม่ต้องปลดล็อกอุปกรณ์
3.10 การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่มีความพิการสามารถไปยังส่วนต่างๆ ในอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API ของแพลตฟอร์มที่ช่วยให้ติดตั้งใช้งานบริการการช่วยเหลือพิเศษเพื่อรับ Callback สำหรับเหตุการณ์ของผู้ใช้และระบบ รวมถึงสร้างกลไกการแสดงความคิดเห็นแบบอื่น เช่น การอ่านออกเสียงข้อความ การตอบสนองแบบรู้สึกได้ และการนำทางแทร็กบอล/D-pad
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบของ SDK เกี่ยวกับ API การช่วยเหลือพิเศษ
- [C-1-2] ต้องสร้างเหตุการณ์การช่วยเหลือพิเศษและส่ง
AccessibilityEvent
ที่เหมาะสมไปยังการใช้งานAccessibilityService
ที่ลงทะเบียนไว้ทั้งหมดตามที่ระบุไว้ใน SDK - [C-1-3] ต้องปฏิบัติตาม Intent ของ
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] ต้องรองรับ TIF API ทั้งหมดเพื่อให้แอปพลิเคชันที่ใช้ API เหล่านี้และบริการอินพุตที่อิงตาม TIF ของบุคคลที่สามติดตั้งและใช้งานในอุปกรณ์ได้
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 และมีค่าตอบแทนผู้ใช้สำหรับลำดับชั้น MediaBrowser
- [C-1-5] ต้องแตะ
KEYCODE_HEADSETHOOK
สองครั้งหรือKEYCODE_MEDIA_PLAY_PAUSE
เป็นKEYCODE_MEDIA_NEXT
สำหรับMediaSession.Callback#onMediaButtonEvent
3.15 Instant Apps
การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- [C-0-1] Instant Apps ต้องได้รับสิทธิ์ที่ตั้งค่า
android:protectionLevel
เป็น"instant"
เท่านั้น - [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] ต้องให้ข้อมูลสำหรับผู้ใช้แก่ผู้ใช้ในการเลือก/ยืนยันว่ามีอุปกรณ์ที่ใช้ร่วมกันพร้อมใช้งานและทำงานได้
3.17. แอปขนาดใหญ่
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องมีแอปที่ติดตั้งไว้เพียงแอปเดียวที่ระบุว่า
cantSaveState
ทำงานอยู่ในระบบในแต่ละครั้ง หากผู้ใช้ออกจากแอปดังกล่าวโดยไม่ได้ออกจากแอปอย่างชัดเจน (เช่น กดปุ่มหน้าแรกขณะออกจากระบบซึ่งมีกิจกรรมที่ใช้งานอยู่ แทนที่จะกดกลับโดยไม่มีกิจกรรมที่ใช้งานอยู่เหลืออยู่ในระบบ) การใช้งานอุปกรณ์จะต้องให้ความสำคัญกับแอปนั้นใน RAM เช่นเดียวกับการดำเนินการอื่นๆ ที่คาดว่าจะยังคงทำงานอยู่ เช่น บริการที่ทำงานอยู่เบื้องหน้า ในขณะที่แอปเหล่านั้นทำงานอยู่เบื้องหลัง ระบบจะยังคงใช้ฟีเจอร์การจัดการพลังงานกับแอปได้ เช่น การจำกัดการเข้าถึง CPU และเครือข่าย - [C-1-2] ต้องระบุราคา UI เพื่อเลือกแอปที่จะไม่เข้าร่วมในกลไกการบันทึก/กู้คืนสถานะปกติเมื่อผู้ใช้เปิดแอปที่ 2 ที่ประกาศด้วยแอตทริบิวต์
cantSaveState
- [C-1-3] ต้องไม่ใช้การเปลี่ยนแปลงอื่นๆ ในนโยบายกับแอปที่ระบุ
cantSaveState
เช่น การเปลี่ยนประสิทธิภาพของ CPU หรือการเปลี่ยนลำดับความสำคัญของกำหนดการ
การติดตั้งใช้งานอุปกรณ์ไม่ได้ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
จะมีผลดังนี้
- [C-1-1] ต้องละเว้นแอตทริบิวต์
cantSaveState
ที่แอปกำหนด และต้องไม่เปลี่ยนลักษณะการทำงานของแอปตามแอตทริบิวต์นั้น
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ ซึ่งสร้างโดยเครื่องมือ “aapt” ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ
- เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย จึงขอแนะนำให้ติดตั้งใช้งานอุปกรณ์เพื่อใช้ระบบการจัดการแพ็กเกจของการใช้งานข้อมูลอ้างอิง AOSP
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v3 , 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()
หากการใช้งานอุปกรณ์ไม่ต้องการให้ผู้ใช้มีทางเลือกนี้ อย่างไรก็ตาม แม้ในกรณีดังกล่าว ควรระบุให้ผู้ใช้ทราบว่าเหตุใดจึงไม่มีตัวเลือกดังกล่าว -
[C-0-7] ต้องแสดงกล่องโต้ตอบคำเตือนพร้อมสตริงคำเตือนที่ได้รับจาก API ของระบบ
PackageManager.setHarmfulAppWarning
ต่อผู้ใช้ก่อนเปิดตัวกิจกรรมในแอปพลิเคชันที่มีการทำเครื่องหมายโดย API ระบบเดียวกันว่าPackageManager.setHarmfulAppWarning
ว่าอาจเป็นอันตราย - ควรเสนอทางเลือกแก่ผู้ใช้ในการเลือกที่จะถอนการติดตั้งหรือเปิดแอปพลิเคชันในหน้าคำเตือน
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-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile ซึ่งรวมถึงโปรไฟล์ฐานของ USAC และโปรไฟล์ควบคุมช่วงไดนามิก ISO/IEC 23003-4)
- [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_LEVEL
เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)
- [C-3-1] ความดังและข้อมูลเมตา DRC ต้องตีความและนำไปใช้ตาม MPEG-D DRC Dynamic Range Control Profile Level 1
- [C-3-2] ตัวถอดรหัสต้องทำงานตามการกำหนดค่าที่ตั้งไว้ด้วยคีย์
android.media.MediaFormat
ต่อไปนี้KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
และKEY_AAC_DRC_EFFECT_TYPE
ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2:
- อาจรองรับความดังและการควบคุมช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิกแบบ ISO/IEC 23003-4
หากระบบรองรับ ISO/IEC 23003-4 และหากมีทั้งข้อมูลเมตา ISO/IEC 23003-4 และข้อมูลเมตา ISO/IEC 14496-3 ในบิตสตรีมที่ถอดรหัสแล้ว ให้ทำดังนี้
- ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสำคัญเหนือกว่า
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 | |
ฐานความรู้ด้านสิ่งแวดล้อม (USAC) | รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz | MPEG-4 (.mp4, .m4a) |
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] ดิบ
- [C-0-7] HEIF (HEIC)
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) | |
HEIF | รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ | HEIF (.heif), HEIC (.heic) |
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 บิต 8 บิต ทศนิยม
- ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องทางที่ถูกต้องสูงสุด 8 ช่อง
-
อัตราการสุ่มตัวอย่าง (ในรูปแบบ Hz):
- 8000, 11025, 16000, 22050, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
- 96000 ในแบบโมโนและสเตอริโอ
-
ควรอนุญาตการเล่นเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้
- อัตราการสุ่มตัวอย่าง: 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
- [C-1-3] ต้องรองรับการใช้งาน
EFFECT_TYPE_DYNAMICS_PROCESSING
ที่ควบคุมได้ผ่านคลาสย่อย AudioEffectDynamicsProcessing
- ควรรองรับการใช้งาน
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
- การประทับเวลา คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง โปรดดูเพิ่มเติมที่ AudioTimestamp
หากการใช้งานอุปกรณ์ประกาศว่า android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามหรือเกินข้อกำหนดต่อไปนี้
- [C-SR] เวลาในการตอบสนองเอาต์พุตแบบเย็นไม่เกิน 100 มิลลิวินาที
- [C-SR] เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
- [C-SR] ลด Jitter เอาต์พุต Cold
- [C-SR] การประทับเวลาเอาต์พุตที่แสดงผลโดย AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
ถูกต้องเป็น +/- 1 มิลลิวินาที
หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังการปรับเทียบเริ่มต้น เมื่อใช้ทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ API เสียงแบบ AAudio สำหรับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold ส่งออกข้อมูลดังกล่าวในอุปกรณ์เอาต์พุตเสียงอย่างน้อย 1 เครื่องที่รองรับ
- [C-SR] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์
android.hardware.audio.low_latency
- [C-SR] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
- [C-SR] แนะนำอย่างเข้มงวดเพื่อให้มั่นใจว่าสำหรับสตรีมที่แสดงผล
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
จากAAudioStream_getPerformanceMode()
ค่าที่AAudioStream_getFramesPerBurst()
แสดงผลจะน้อยกว่าหรือเท่ากับค่าที่android.media.AudioManager.getProperty(String)
แสดงผลสำหรับคีย์พร็อพเพอร์ตี้AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
หากการใช้อุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่านทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ API เสียงแบบ AAudio แบบเนทีฟ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
หากการใช้งานอุปกรณ์รวม android.hardware.microphone
ด้วย เราขอแนะนำเป็นอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับอินพุตต่อไปนี้
- [C-SR] เวลาในการตอบสนองแบบ Cold input ไม่เกิน 100 มิลลิวินาที
- [C-SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
- [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
- [C-SR] ลดเสียงรบกวนของอินพุต Cold
- [C-SR] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลให้เป็น +/- 1 มิลลิวินาที
5.7 โปรโตคอลเครือข่าย
การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุในเอกสารประกอบของ Android SDK
หากการใช้งานอุปกรณ์มีเสียงหรือตัวถอดรหัสวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)
-
[C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านโปรโตคอลฉบับร่างของ 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)
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi
ผ่านคลาส android.content.pm.PackageManager
ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องรองรับ MIDI กับการส่งฮาร์ดแวร์ที่ใช้ MIDI ทั้งหมด ซึ่งให้บริการการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป ซึ่งการขนส่งดังกล่าวมีลักษณะดังนี้
- โหมดโฮสต์ USB ส่วนที่ 7.7
- โหมดอุปกรณ์ต่อพ่วง USB ส่วนที่ 7.7
- MIDI ผ่าน Bluetooth LE ดำเนินการในบทบาทหลัก ส่วนที่ 7.4.3
-
[C-1-2] ต้องรองรับการรับส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ 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 โดยใช้ทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ API เสียงแบบเนทีฟของ AAudio
- [SR] แนะนําอย่างยิ่งให้มอบประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและโหลดของ CPU แตกต่างกันไป ซึ่งควรทดสอบโดยใช้คอมมิต SimpleSynth 1bd6391 แอป SimpleSynth ต้องเรียกใช้โดยมีพารามิเตอร์ด้านล่างและต่ำกว่า 0 หลังจากผ่านไป 10 นาที
- รอบการทำงาน: 200,000
- โหลดของตัวแปร: เปิด (จะสลับระหว่าง 100% ถึง 10% ของค่ารอบการทำงานทุก 2 วินาที และออกแบบมาเพื่อทดสอบลักษณะการทำงานของตัวกำกับดูแล 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)
- ควรมีเวลาในการตอบสนองจากการป้อนข้อมูลด้วยการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 40 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด ระบบจะดำเนินการดังต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์
android.hardware.audio.pro
ผ่านคลาสandroid.content.pm.PackageManager
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว จะมีผลดังนี้
- [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องไม่เกิน 20 มิลลิวินาทีในเส้นทางช่องเสียบเสียง
- [SR] แนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดเฉพาะอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อกำหนดของชุดหูฟังสำหรับเสียงแบบมีสาย (v1.1)
- เวลาในการตอบสนองแบบไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าในเส้นทางช่องเสียบเสียง
หากอุปกรณ์ไม่มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB รายการต่อไปนี้
- [C-3-1] ต้องใช้คลาสเสียง USB
- [C-3-2] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องไม่เกิน 20 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB
- เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าที่พอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB
หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้
- [C-4-1] ต้องรองรับเอาต์พุตสเตอริโอและแชนเนล 8 ช่องที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มเนื้อหาซ้ำในการกำหนดค่าอย่างน้อย 1 รายการ
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 ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง
dumpsys
และcmd stats
- [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบอุปกรณ์ (batterystats , Diskstats, Fingerprint, graphicstats, netstats, notifications, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
- [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell
cmd stats
และคลาส System APIStatsManager
- เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
- ตรวจพบความผิดปกติ
- รายงานเบรดครัมบ์ของแอปแล้ว
- แอปขัดข้อง
- เกิดแอป
- เปลี่ยนระดับแบตเตอรี่แล้ว
- เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
- BleScanผลลัพธ์ได้รับ
- เปลี่ยนสถานะ BleScan แล้ว
- เปลี่ยนสถานะการชาร์จแล้ว
- เปลี่ยนสถานะโหมดอุปกรณ์ชั่วคราวแล้ว
- เปลี่ยนสถานะของบริการที่ทำงานอยู่เบื้องหน้าแล้ว
- เปลี่ยนสถานะการสแกน GPS แล้ว
- เปลี่ยนสถานะของงานแล้ว
- สถานะเสียบปลั๊กเปลี่ยน
- เปลี่ยนสถานะงานที่กำหนดเวลาไว้แล้ว
- สถานะหน้าจอเปลี่ยน
- สถานะการซิงค์เปลี่ยนแปลง
- แบบเรียลไทม์โดยระบบ
- เปลี่ยนสถานะ UidProcess แล้ว
- เปลี่ยนสถานะ Wake Lock แล้ว
- ตั้งปลุกแล้ว
- เปลี่ยนสถานะ WifiLock
- เปลี่ยนสถานะ Wifiมัลติแคสต์ล็อกแล้ว
- เปลี่ยนสถานะการสแกน Wi-Fi แล้ว
- [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 ได้
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง
-
บริการตรวจสอบแก้ไขข้อบกพร่องของ 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
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านแฟล็กฟีเจอร์ android.hardware.vulkan.version
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องจ่ายเงินให้นักพัฒนาแอปเปิด/ปิดใช้เลเยอร์แก้ไขข้อบกพร่องของ GPU
- [C-1-2] ต้องแจกแจงเลเยอร์ในไลบรารีที่เครื่องมือภายนอกมีให้ (กล่าวคือ ไม่ใช่ส่วนหนึ่งของแพ็กเกจแพลตฟอร์มหรือแพ็กเกจแอปพลิเคชัน) เมื่อเปิดใช้เลเยอร์แก้ไขข้อบกพร่องของ GPU เพื่อรองรับเมธอด API vkEnumerateInstanceLayerProperties() และ vkCreateInstance()
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android มีการสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์ในการกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน
การใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
- [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอัปสตรีมของ Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
- [C-0-2] ต้องซ่อนตัวเลือกของนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น
- [C-0-3] ต้องระบุกลไกที่ชัดเจนว่าจะไม่ให้การจัดการเป็นพิเศษแก่แอปบุคคลที่สามแอปหนึ่ง แทนที่จะเป็นอีกแอปหนึ่งเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ ต้องระบุเอกสารหรือเว็บไซต์ที่เปิดเป็นสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ เอกสารหรือเว็บไซต์นี้ต้องลิงก์ได้จากเอกสาร Android SDK
- ควรมีการแจ้งเตือนผู้ใช้ด้วยภาพอย่างต่อเนื่องเมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์และความปลอดภัยของผู้ใช้เป็นข้อกังวลใจในความปลอดภัยของผู้ใช้
- อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ชั่วคราวด้วยการซ่อนหรือปิดใช้เมนูเพื่อไม่ให้เสียสมาธิในกรณีที่เกิดข้อกังวลด้านความปลอดภัยของผู้ใช้
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 -
อาจมีจอแสดงผลที่มีมุมโค้งมน
หากการติดตั้งใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL
และมีจอแสดงผลมุมมน ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องตรวจสอบว่ารัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
- ควรรวมทางเลือกของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยมผืนผ้า
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.1 และ 2.0 ตามที่อธิบายไว้และระบุไว้ในเอกสารประกอบ Android SDK
- [SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
- ควรรองรับ OpenGL ES 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.1 อุปกรณ์จะทำงานดังนี้
- [SR] ขอแนะนำอย่างยิ่งให้รวมการสนับสนุนสำหรับ Vulkan 1.1
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- ควรมีการรองรับ Vulkan 1.1
หากการติดตั้งใช้งานอุปกรณ์รองรับ 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 และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
- [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_แถบเลื่อน และ VK_KHR_incremental_present
หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan ใดๆ (เช่น
android.hardware.vulkan.level
,android.hardware.vulkan.version
) - [C-2-2] ต้องไม่แจกแจง
VkPhysicalDevice
สำหรับ Vulkan Native APIvkEnumeratePhysicalDevices()
หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.1 จะทำสิ่งต่อไปนี้ได้
- [C-3-1] ต้องแสดงการสนับสนุนสำหรับเครื่องหมายภายนอกและประเภทแฮนเดิล
SYNC_FD
- [SR] แนะนําอย่างยิ่งให้สนับสนุนส่วนขยาย
VK_ANDROID_external_memory_android_hardware_buffer
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% ของ DCI-P3 ในพื้นที่ CIE 1931 xyY
- [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
- [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
และEGL_KHR_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] ต้องให้เงินแก่ผู้ใช้ในการเปิดใช้งานแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่มีการตั้งค่า
<intent-filter>
ด้วยACTION=MAIN
และCATEGORY=LAUNCHER
หรือCATEGORY=LEANBACK_LAUNCHER
สำหรับการใช้งานอุปกรณ์ทีวี ฟังก์ชัน Home ควรเป็นกลไกสำหรับค่าใช้จ่ายของผู้ใช้รายนี้ - ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"
หากมีฟังก์ชัน "หน้าแรก" "ล่าสุด" หรือ "ย้อนกลับ" อยู่ ฟังก์ชันดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเพียงครั้งเดียว (เช่น การแตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงรายการใดก็ได้
- [C-1-2] ต้องระบุตัวบ่งชี้ที่ชัดเจนว่าการดำเนินการใดจะทริกเกอร์แต่ละฟังก์ชัน การมีไอคอนที่มองเห็นได้พิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนระหว่างการตั้งค่าตั้งแต่แกะกล่องคือตัวอย่างของตัวบ่งชี้ดังกล่าว
การติดตั้งใช้งานอุปกรณ์
- [SR] ขอแนะนำเป็นอย่างยิ่งว่าไม่มีกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการทำงานตั้งแต่ Android 4.0 แล้ว
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน "เมนู" สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงปุ่มการทำงานเพิ่มเติมทุกครั้งที่ป๊อปอัปเมนูการดำเนินการเพิ่มเติมไม่ว่างเปล่าและแถบการทำงานปรากฏขึ้น
- [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการทำงาน แต่อาจแสดงผลป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงด้วยการเลือกฟังก์ชันเมนู
หากการใช้งานอุปกรณ์ไม่มีฟังก์ชัน "เมนู" สำหรับความเข้ากันได้แบบย้อนหลัง ฟังก์ชันจะมีลักษณะดังนี้ * [C-3-1] ต้องทำให้ฟังก์ชันเมนูพร้อมใช้งานสำหรับแอปพลิเคชันเมื่อ targetSdkVersion
มีค่าน้อยกว่า 10 รายการ ไม่ว่าจะเป็นปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้ร่วมกับฟังก์ชันการนำทางอื่นๆ
หากการใช้งานอุปกรณ์มีฟังก์ชัน Assist คุณลักษณะดังกล่าว * [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 ดาวเทียม)
- [C-1-6] หลังจากคำนวณตำแหน่งแล้ว การใช้งานอุปกรณ์ต้องกำหนดตำแหน่งอุปกรณ์ในที่โล่งภายใน 5 วินาที เมื่อรีสตาร์ทคำขอตำแหน่ง และใช้เวลาไม่เกิน 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/GNSS แต่ละตำแหน่ง
- [SR] เราขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเพิ่มเติมที่จำเป็นสำหรับอุปกรณ์ที่รายงานปี "2016" หรือ "2017" ผ่าน Test API ให้ได้มากที่สุดเท่าที่จะเป็นไปได้
LocationManager.getGnssYearOfHardware()
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
และรายงาน LocationManager.getGnssYearOfHardware()
Test API ในปี "2016" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-2-1] ต้องรายงานการวัด GNSS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [C-2-2] ต้องรายงานอัตรา Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาวะทางท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่โดยมีความเร่งน้อยกว่า 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/GNSS แต่ละตำแหน่ง
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
และรายงาน LocationManager.getGnssYearOfHardware()
Test API ในปี "2018" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-4-1] ต้องนำส่งเอาต์พุต GPS/GNSS ตามปกติไปยังแอปพลิเคชันต่อไประหว่างการโทรเซสชันฉุกเฉินที่เริ่มโดยเครือข่ายจากสถานีมือถือ (MS-Based)
- [C-4-2] ต้องรายงานตำแหน่งและการวัดไปยัง GNSS Location Provider API
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 ก. เป็นอย่างน้อย และควรมีช่วงการวัดอยู่ระหว่าง -16 ก. ถึง +16 ก. เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
- ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควรรองรับ SensorDirectChannel
RATE_VERY_FAST
- ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 400 μg/ทั้งหมดใน{/9}
- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
- ควรมีความเร่งเดินแบบสุ่มน้อยกว่า 30 μg หน้าร้าน และลดค่า Hz ผ่านการทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
- ควรมีระดับความไม่เป็นเชิงเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิสูงสุด ≤ 0.03%/C°
- ควรมีความไวข้ามแกน < 2.5 % และความไวข้ามแกน < 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
-
[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 หรือสูงกว่า ควรรองรับ SensorDirectChannel
RATE_VERY_FAST
- ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
- ควรมีอัตราการเดินแบบสุ่มน้อยกว่า 0.001 °/s ¡Hz ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
- ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
- ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
- ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
- ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่
- ควรมีความไวต่อ g น้อยกว่า 0.1°/s/g
- ควรมีความไวข้ามแกน < 4.0 % และความไวข้ามแกน < 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
-
[C-2-4] ต้องมี
TYPE_GYROSCOPE_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GYROSCOPE
-
[C-2-5] ต้องมีเซ็นเซอร์
TYPE_GEOMAGNETIC_FIELD
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
- ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
-
[C-2-6] ต้องมี
TYPE_MAGNETIC_FIELD_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GEOMAGNETIC_FIELD
และมีคุณสมบัติดังต่อไปนี้- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานเป็น 50 Hz หรือสูงกว่า
-
[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 มิลลิวินาที การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่งและเครื่องวัดการหมุนควรอยู่ห่างกันไม่เกิน 0.25 มิลลิวินาที
- [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_ACCELEROMETER
-
TYPE_ACCELEROMETER_UNCALIBRATED
-
TYPE_GYROSCOPE
-
TYPE_GYROSCOPE_UNCALIBRATED
-
TYPE_MAGNETIC_FIELD
-
TYPE_MAGNETIC_FIELD_UNCALIBRATED
-
7.3.10 เซ็นเซอร์ไบโอเมตริก
7.3.10.1 เซ็นเซอร์ลายนิ้วมือ
หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรมีเซ็นเซอร์ลายนิ้วมือ
หากการนำอุปกรณ์ไปใช้มีเซ็นเซอร์ลายนิ้วมือและทำให้เซ็นเซอร์พร้อมใช้งานสำหรับแอปของบุคคลที่สาม การตั้งค่าดังกล่าวจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์
android.hardware.fingerprint
- [C-1-2] ต้องใช้ corresponding API อย่างสมบูรณ์ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
- [C-1-3] ต้องมีอัตราการยอมรับที่เป็นเท็จไม่เกิน 0.002%
- [SR] แนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการหลอกลวงให้ไม่เกิน 7%
- [C-1-4] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และแจกแจงความเสี่ยงในการเปิดใช้อย่างชัดเจน หากอัตราการปลอมแปลงและการยอมรับของผู้แอบอ้างสูงกว่า 7%
- [C-1-5] ต้องพยายามจำกัดอัตราคำขอเป็นเวลาอย่างน้อย 30 วินาทีหลังการทดสอบที่ผิดพลาด 5 ครั้งสำหรับการยืนยันลายนิ้วมือ
- [C-1-6] ต้องมีการใช้งานคีย์สโตร์ที่ใช้ฮาร์ดแวร์ และดำเนินการจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
- [C-1-7] ต้องมีข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับเพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอก TEE ได้ หรือต้องมีชิปที่มีช่องทางที่ปลอดภัยของ TEE ดังที่ระบุในหลักเกณฑ์การใช้งานในเว็บไซต์โครงการโอเพนซอร์ส Android
- [C-1-8] ต้องป้องกันไม่ให้มีการเพิ่มลายนิ้วมือโดยไม่สร้างเครือข่ายความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโปรเจ็กต์โอเพนซอร์สของ Android จะเป็นกลไกในเฟรมเวิร์ก
- [C-1-9] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างลายนิ้วมือแต่ละรายการ
- [C-1-10] ต้องทำตามแฟล็ก DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
- [C-1-11] ต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้นเมื่ออัปเกรดจากเวอร์ชันที่เก่ากว่า Android 6.0 หรือนำข้อมูลลายนิ้วมือออกอย่างปลอดภัย
- [C-1-12] ต้องนำข้อมูลลายนิ้วมือที่ระบุตัวตนได้ของผู้ใช้ออกทั้งหมดเมื่อมีการลบบัญชีของผู้ใช้ (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
- [C-1-13] ต้องไม่อนุญาตให้มีการเข้าถึงข้อมูลลายนิ้วมือที่ระบุตัวตนได้หรือข้อมูลใดก็ตามที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ไปยังตัวประมวลผลแอปพลิเคชันโดยไม่เข้ารหัส
- [SR] ขอแนะนําอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์
- [SR] ขอแนะนำเป็นอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อเซ็นเซอร์ลายนิ้วมือถูกแตะจนกระทั่งหน้าจอปลดล็อกสำหรับนิ้วที่ลงทะเบียนเพียง 1 นิ้ว
- ควรใช้ไอคอนลายนิ้วมือของ Android ที่ให้ไว้ในโครงการโอเพนซอร์สของ Android
7.3.10.2 เซ็นเซอร์ไบโอเมตริกอื่นๆ
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกที่ไม่ใช้ลายนิ้วมืออย่างน้อย 1 ตัว และทำให้พร้อมใช้งานกับแอปของบุคคลที่สาม เซ็นเซอร์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องมีอัตราการยอมรับที่เป็นเท็จไม่เกิน 0.002%
- [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการหลอกลวงให้ไม่สูงกว่า 7%
- [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และแจกแจงความเสี่ยงในการเปิดใช้อย่างชัดเจน หากอัตราการปลอมแปลงและการยอมรับของผู้แอบอ้างสูงกว่า 7%
- [C-1-3] ต้องพยายามจำกัดอัตราคำขอเป็นเวลาอย่างน้อย 30 วินาทีหลังการทดลองยืนยันข้อมูลไบโอเมตริกที่ผิดพลาด 5 ครั้ง โดยการทดลองที่เป็นเท็จคือการทดสอบที่มีคุณภาพการจับข้อมูลที่เพียงพอ (ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
- [C-1-4] ต้องมีการใช้งานคีย์สโตร์ที่ใช้ฮาร์ดแวร์ และดำเนินการจับคู่ข้อมูลไบโอเมตริกใน TEE หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
- [C-1-5] ต้องมีข้อมูลที่ระบุตัวบุคคลนั้นได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับเพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอก TEE ได้ หรือต้องมีชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
- [C-1-6] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลเข้าสู่ระบบของอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโครงการโอเพนซอร์ส Android จะให้กลไกในเฟรมเวิร์กในการดำเนินการ
- [C-1-7] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างการลงทะเบียนข้อมูลไบโอเมตริก
- [C-1-8] ต้องให้เกียรติแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
หรือDevicePolicymanager.KEYGUARD_DISABLE_IRIS
) - [C-1-9] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ทั้งหมดของผู้ใช้ออกโดยสมบูรณ์เมื่อมีการลบบัญชีของผู้ใช้ (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
- [C-1-10] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวตนได้หรือข้อมูลใดก็ตามที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ไปยังผู้ประมวลผลแอปพลิเคชันโดยไม่เข้ารหัส นอกบริบทของ TEE
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อตรวจพบข้อมูลไบโอเมตริกจนกระทั่งปลดล็อกหน้าจอสำหรับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้แต่ละรายการ
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 สถานะการขับรถ
ข้อกำหนดนี้เลิกใช้งานแล้ว
7.3.11.4 ความเร็วของล้อ
โปรดดูส่วนที่ 2.5.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3.11.5 เบรกมือ
โปรดดูส่วนที่ 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.1.2 API โทรคมนาคม
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ API ของ
ConnectionService
ที่อธิบายไว้ใน SDK - [C-1-2] ต้องแสดงสายเรียกเข้าที่เข้ามาใหม่ และให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการยอมรับหรือปฏิเสธสายเรียกเข้าเมื่อผู้ใช้กำลังโทรอยู่ซึ่งมาจากแอปของบุคคลที่สามที่ไม่รองรับฟีเจอร์พักสายที่ระบุผ่าน
CAPABILITY_SUPPORT_HOLD
-
[C-SR] ขอแนะนำอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบว่าการรับสายเรียกเข้าจะเป็นการตัดสายที่สนทนาอยู่
การใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้โดยการแจ้งเตือนล่วงหน้าซึ่งระบุให้ผู้ใช้ทราบว่าการรับสายเรียกเข้าจะทำให้สายที่โทรเข้ามาหลุด
-
[C-SR] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรศัพท์เริ่มต้นล่วงหน้าซึ่งแสดงรายการบันทึกการโทรและชื่อแอปของบุคคลที่สามในบันทึกการโทรเมื่อแอปของบุคคลที่สามตั้งค่าคีย์เพิ่มเติมของ
EXTRA_LOG_SELF_MANAGED_CALLS
ในPhoneAccount
เป็นtrue
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้จัดการเหตุการณ์
KEYCODE_MEDIA_PLAY_PAUSE
และKEYCODE_HEADSETHOOK
ของชุดหูฟังสำหรับandroid.telecom
API ดังนี้- โทรหา
Connection.onDisconnect()
เมื่อตรวจพบการกดปุ่มเหตุการณ์สำคัญสั้นๆ ระหว่างที่โทรอยู่ - โทรหา
Connection.onAnswer()
เมื่อตรวจพบการกดแป้นสั้นๆ ระหว่างที่มีสายเรียกเข้า - โทรหา
Connection.onReject()
เมื่อตรวจพบการกดแป้นค้างไว้ระหว่างที่มีสายเรียกเข้า - สลับสถานะการปิดเสียงของ
CallAudioState
- โทรหา
7.4.2 IEEE 802.11 (Wi-Fi)
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับ 802.11 อย่างน้อย 1 รูปแบบ
หากการนำอุปกรณ์ไปใช้งานมีการรองรับ 802.11 และแสดงฟังก์ชันดังกล่าวแก่แอปพลิเคชันของบุคคลที่สาม การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้ Android 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 แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย
- [C-1-5] ต้องไม่ถือว่าการเรียกเมธอด API
WifiManager.enableNetwork()
เป็นตัวบ่งชี้ที่เพียงพอในการเปลี่ยนNetwork
ที่ใช้งานอยู่ในปัจจุบัน ซึ่งใช้เป็นค่าเริ่มต้นสำหรับการรับส่งข้อมูลของแอปพลิเคชัน และจะแสดงผลโดยเมธอด APIConnectivityManager
เช่นgetActiveNetwork
และregisterDefaultNetworkCallback
กล่าวคือ อาจปิดใช้งานการเข้าถึงอินเทอร์เน็ตที่ให้บริการโดยผู้ให้บริการเครือข่ายรายอื่น (เช่น ข้อมูลมือถือ) เท่านั้น หากตรวจสอบแล้วว่าเครือข่าย Wi-Fi ได้ให้การเข้าถึงอินเทอร์เน็ต - [C-SR] แนะนำอย่างยิ่ง เมื่อมีการเรียกเมธอด
ConnectivityManager.reportNetworkConnectivity()
API ให้ประเมินการเข้าถึงอินเทอร์เน็ตในNetwork
อีกครั้ง และเมื่อการประเมินระบุว่าNetwork
ปัจจุบันไม่มีการเข้าถึงอินเทอร์เน็ตแล้ว ให้เปลี่ยนไปใช้เครือข่ายอื่นๆ ที่พร้อมใช้งาน (เช่น อินเทอร์เน็ตมือถือ) ที่เข้าถึงอินเทอร์เน็ตได้ - [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอตรวจสอบ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้ง ขณะที่ STA ไม่ได้เชื่อมต่อ
- เฟรมคำขอการตรวจสอบแต่ละกลุ่มที่ประกอบด้วยการสแกน 1 รายการควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งทางของการสแกน)
- หมายเลขลำดับคำขอตรวจสอบควรทำซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
- หมายเลขลำดับคำขอการตรวจสอบควรสุ่มอยู่ระหว่างคำขอการตรวจสอบสุดท้ายของการสแกนและคำขอการตรวจสอบแรกของการสแกนครั้งถัดไป
- [C-SR] แนะนำอย่างยิ่งในขณะที่ STA ถูกตัดการเชื่อมต่อเพื่ออนุญาตเฉพาะองค์ประกอบต่อไปนี้ในเฟรมคำขอการตรวจสอบ
- ชุดพารามิเตอร์ SSID (0)
- ชุดพารามิเตอร์ DS (3)
หากการใช้งานอุปกรณ์รองรับ Wi-Fi และใช้ Wi-Fi ในการสแกนหาตำแหน่ง ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องระบุราคาของผู้ใช้ในการเปิดใช้/ปิดใช้ค่าที่อ่านผ่านเมธอด
WifiManager.isScanAlwaysAvailable
API
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 ปกติ
- [C-1-4] ต้องรองรับการดำเนินการ 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 อยู่
หากการใช้งานอุปกรณ์รวมการสนับสนุนสำหรับการรับรู้ถึง Wi-Fi และตำแหน่ง Wi-Fi ตามที่อธิบายไว้ในส่วนที่ 7.4.2.5 และแสดงฟังก์ชันเหล่านี้แก่แอปของบุคคลที่สาม ฟังก์ชันดังกล่าวจะต้องดำเนินการต่อไปนี้
- [C-2-1] ต้องใช้ API การค้นพบที่รับรู้ตำแหน่ง: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm และ onServiceDiscoveredหลายครั้งใน
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.2.5 ตำแหน่ง Wi-Fi (ระยะเวลารับส่งของ Wi-Fi - RTT)
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับตำแหน่ง Wi-Fi
หากการใช้งานอุปกรณ์มีการรองรับตำแหน่ง Wi-Fi และเปิดเผยฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม การใช้งานจะส่งผลดังนี้
- [C-1-1] ต้องใช้
WifiRttManager
API ตามที่อธิบายไว้ในเอกสารประกอบ SDK - [C-1-2] ต้องประกาศ Flag ฟีเจอร์
android.hardware.wifi.rtt
- [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางสำหรับการถ่ายภาพ RTT แต่ละรายการที่ดำเนินการในขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT นั้นไม่ได้เชื่อมโยงกับจุดเข้าใช้งาน
7.4.3 บลูทูธ
หากอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ ระบบจะดำเนินการต่อไปนี้
- ควรรองรับตัวแปลงรหัสเสียงขั้นสูงและตัวแปลงรหัสเสียงบลูทูธ (เช่น LDAC)
หากการติดตั้งใช้งานอุปกรณ์รองรับ HFP, A2DP และ AVRCP ก็จะส่งผลดังนี้
- ควรรองรับอุปกรณ์ทั้งหมดที่เชื่อมต่ออย่างน้อย 5 เครื่อง
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ 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, AVRCP, OBEX, HFP ฯลฯ ตามความเหมาะสมกับอุปกรณ์
หากอุปกรณ์รองรับบลูทูธพลังงานต่ำ ระบบจะดำเนินการดังต่อไปนี้
- [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 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
หากอุปกรณ์รองรับ Bluetooth LE และใช้ Bluetooth LE เพื่อสแกนหาตำแหน่ง ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องระบุราคาสำหรับการเปิด/ปิดใช้ค่าที่อ่านผ่าน System API
BluetoothAdapter.isBleScanAlwaysAvailable()
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 บลูทูธ
- ควรรวมการสนับสนุนมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
- อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
- [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 วินาที
- [C-0-6] ต้องมีแอปพลิเคชันของบุคคลที่สามที่มีการเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยที่ไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ เกิดขึ้นภายในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น
Socket#getLocalAddress
หรือSocket#getLocalPort
) และ NDK API เช่นgetsockname()
หรือIPV6_PKTINFO
ต้องส่งคืนที่อยู่ IP และพอร์ตที่ใช้จริงเพื่อส่งและรับแพ็กเก็ตในเครือข่าย
ระดับการสนับสนุน IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่าย ดังที่ปรากฏในข้อกำหนดต่อไปนี้
หากอุปกรณ์รองรับ Wi-Fi ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi
การใช้งานอุปกรณ์รองรับอีเทอร์เน็ตจะเป็นดังนี้
- [C-2-1] ต้องรองรับการทำงานแบบสแต็กคู่ในอีเทอร์เน็ต
หากอุปกรณ์รองรับข้อมูลเครือข่ายมือถือ ก็จะเป็นดังนี้
- ควรรองรับการดำเนินการ IPv6 (IPv6 เท่านั้นและอาจรองรับแบบ 2 สแต็ก) ในเครือข่ายมือถือ
หากการติดตั้งใช้งานอุปกรณ์รองรับเครือข่ายมากกว่า 1 ประเภท (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ)
- [C-3-1] ต้องตรงตามข้อกำหนดข้างต้นในแต่ละเครือข่ายพร้อมกันเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 ประเภท
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.4.8 องค์ประกอบความปลอดภัย
หากการใช้งานอุปกรณ์รองรับองค์ประกอบความปลอดภัยที่รองรับ Open Mobile API และทำให้ใช้งานกับแอปของบุคคลที่สามได้ การใช้งานดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องแจกแจงผู้อ่านองค์ประกอบความปลอดภัยที่มีอยู่เมื่อเรียกใช้เมธอด
android.se.omapi.SEService.getReaders()
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
- [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องด้วยอุปกรณ์กล้องภายนอกที่จับต้องได้ที่เชื่อมต่ออยู่ ดูรายละเอียดการทดสอบ CTS ของกล้องได้ที่ source.android.com
- ควรรองรับการบีบอัดวิดีโอ เช่น 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
ฟีเจอร์ทั้งหมดที่มีการใช้งานร่วมกันระหว่างคลาส android.hardware.camera ที่เลิกใช้งานแล้วและแพ็กเกจ android.hardware.camera2 ใหม่ต้องมีประสิทธิภาพและคุณภาพเท่ากันใน API ทั้ง 2 รุ่น เช่น หากมีการตั้งค่าที่เทียบเท่า ความเร็วในการโฟกัสอัตโนมัติและความแม่นยำจะต้องเหมือนกัน และคุณภาพของรูปภาพที่จับภาพต้องเท่ากัน ฟีเจอร์ที่ต้องอาศัยความหมายที่ต่างกันของ API ทั้งสองไม่จำเป็นต้องมีความเร็วหรือคุณภาพตรงกัน แต่ควรจับคู่ให้ใกล้เคียงมากที่สุด
การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ 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
ที่โฆษณาความสามารถREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
ในandroid.request.availableCapabilities
- [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
ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของรูปภาพไปยังร้านค้าสื่อแล้ว - [C-SR] แนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องเชิงตรรกะที่แสดงความสามารถ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
สำหรับอุปกรณ์ที่มีกล้องหลายตัวหันไปในทิศทางเดียวกัน โดยประกอบด้วยกล้องจริงแต่ละตัวที่หันไปในทิศทางนั้น ตราบใดที่เฟรมเวิร์กรองรับประเภทกล้องจริงและCameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL
สำหรับกล้องจริงคือLIMITED
,FULL
หรือLEVEL_3
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 พอร์ต สิ่งต่อไปนี้
- [C-SR] ขอแนะนำอย่างยิ่งให้รวมพอร์ตเสียงอย่างน้อย 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 โวลต์
- [C-1-7] ต้องตรวจหาและแมปกับคีย์โค้ดสำหรับช่วงของค่าอิมพีแดนซ์ที่เท่ากันระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียงดังต่อไปนี้
-
110-180 โอห์ม:
KEYCODE_VOICE_ASSIST
-
110-180 โอห์ม:
- [C-SR] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
- [C-SR] แนะนำอย่างยิ่งให้สนับสนุนการบันทึกเสียงจากชุดหูฟังสเตอริโอด้วยไมโครโฟน
หากอุปกรณ์มีช่องเสียบหูฟัง 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 โหมด Virtual Reality - ประสิทธิภาพสูง
หากอุปกรณ์รองรับโหมด VR อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องมี 2 Physical Core เป็นอย่างน้อย
- [C-1-2] ต้องประกาศฟีเจอร์
android.hardware.vr.high_performance
- [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
- [C-1-4] ต้องรองรับ OpenGL ES 3.2
- [C-1-5] ต้องรองรับ
android.hardware.vulkan.level
0 - ควรรองรับ
android.hardware.vulkan.level
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_EXT_image_gl_colorspace
และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่มีให้บริการ - [C-1-8] ต้องใช้
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_OVR_multiview_multisampled_render_to_texture
,GL_EXT_protected_textures
และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน - [C-SR] แนะนําอย่างยิ่งให้ใช้
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน - [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
และเปิดเผยในรายการส่วนขยาย Vulkan ที่มีให้บริการ - [C-SR] ขอแนะนำอย่างยิ่งให้แสดงกลุ่มคิว Vulkan อย่างน้อย 1 กลุ่มซึ่ง
flags
มีทั้งVK_QUEUE_GRAPHICS_BIT
และVK_QUEUE_COMPUTE_BIT
และqueueCount
ต้องมีอย่างน้อย 2 กลุ่ม - [C-1-7] GPU และจอแสดงผลต้องสามารถซิงค์ข้อมูลการเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ ซึ่งจะทำให้การแสดงผลแบบสลับตาของเนื้อหา VR ที่ 60 FPS พร้อมบริบทในการแสดงภาพ 2 รายการจะแสดงโดยไม่มีอาร์ติแฟกต์ที่ฉีกขาดซึ่งมองเห็นได้
- [C-1-9] ต้องใช้การรองรับแฟล็ก
AHardwareBuffer
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
และAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
ตามที่อธิบายไว้ใน NDK - [C-1-10] ต้องใช้การรองรับ
AHardwareBuffer
ที่มีแฟล็กการใช้งานAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
ร่วมกันสำหรับรูปแบบต่อไปนี้AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
เป็นอย่างน้อย - [C-SR] แนะนำอย่างยิ่งให้รองรับการจัดสรร
AHardwareBuffer
ที่มีมากกว่า 1 เลเยอร์ แฟล็ก และรูปแบบที่ระบุใน C-1-10 - [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps โดยบีบอัดให้มีค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 1920 x1080 จำนวน 4 อินสแตนซ์ที่ 30 fps-10 Mbps หรือ 1920 x 1920 x 20fps 2 อินสแตนซ์)
- [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920 x 1080 ที่ 30 fps ที่บีบอัดให้มีความเร็วเฉลี่ย 10 Mbps และควรสามารถถอดรหัส 3840 x 2160 bps ที่อินสแตนซ์ 10-20 fps ถึง 30 fps ถึง 30 fps เป็นความเร็วเฉลี่ย 3840 x 2160 ที่อัตรา 30 fps ถึง 30 fps เท่ากับค่าเฉลี่ย 3840 x 2160 ที่ 30 fps ถึง 20 fps
- [C-1-13] ต้องรองรับ API ของ
HardwarePropertiesManager.getDeviceTemperatures
และแสดงผลค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง - [C-1-14] ต้องมีหน้าจอแบบฝัง และความละเอียดต้องมีขนาดอย่างน้อย 1920 x 1080
- [C-SR] แนะนำอย่างยิ่งให้ใช้ความละเอียดในการแสดงผลอย่างน้อย 2560 x 1440
- [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
- [C-1-17] จอแสดงผลต้องรองรับโหมดความต่อเนื่องต่ำที่มีความต่อเนื่อง ≤ 5 มิลลิวินาที ความต่อเนื่องหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
- [C-1-18] ต้องรองรับบลูทูธ 4.2 และการขยายความยาวของข้อมูลบลูทูธ LE หัวข้อ 7.4.3
- [C-1-19] ต้องรองรับและรายงานประเภทช่องทางโดยตรงอย่างถูกต้องสำหรับเซ็นเซอร์เริ่มต้นทุกประเภทต่อไปนี้
-
TYPE_ACCELEROMETER
-
TYPE_ACCELEROMETER_UNCALIBRATED
-
TYPE_GYROSCOPE
-
TYPE_GYROSCOPE_UNCALIBRATED
-
TYPE_MAGNETIC_FIELD
-
TYPE_MAGNETIC_FIELD_UNCALIBRATED
-
- [C-SR] ขอแนะนำอย่างยิ่งให้รองรับประเภทแชแนลโดยตรง
TYPE_HARDWARE_BUFFER
สำหรับประเภทแชแนลโดยตรงทั้งหมดที่แสดงข้างต้น - [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ
android.hardware.hifi_sensors
ตามที่ระบุไว้ในส่วน 7.3.9 - [C-SR] แนะนำอย่างยิ่งให้สนับสนุนฟีเจอร์
android.hardware.sensor.hifi_sensors
- [C-1-22] ต้องมีเวลาในการตอบสนองของการเคลื่อนไหวจากต้นทางถึงปลายทางเป็นโฟตอนไม่สูงกว่า 28 มิลลิวินาที
- [C-SR] แนะนำอย่างยิ่งให้มีการเปลี่ยนแปลงการเคลื่อนไหวจากต้นทางถึงปลายทางต่อเวลาในการตอบสนองของโฟตอนไม่สูงกว่า 20 มิลลิวินาที
- [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวและความสว่างของพิกเซลสีขาวในสถานะคงที่อย่างน้อย 85%
- [C-SR] แนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
- อาจให้แกนเอกสิทธิ์เฉพาะสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า และอาจรองรับ
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 โหมดประหยัดพลังงาน
หากการนำอุปกรณ์ไปใช้งานมีฟีเจอร์ในการปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP การดำเนินการดังกล่าวจะมีผลดังนี้
- [C-1-1] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับอัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและโหมดประหยัดพลังงาน Doze
- [C-1-2] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการควบคุมงาน สัญญาณเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสำหรับการสแตนด์บายแอป
- [C-1-3] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับจำนวนที่เก็บข้อมูลสแตนด์บายแอปที่ใช้สำหรับสแตนด์บายแอป
- [C-1-4] ต้องใช้ที่เก็บข้อมูลสแตนด์บายแอปและ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
- [C-1-5] ต้องส่งคืน
true
สำหรับPowerManager.isPowerSaveMode()
เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน - [C-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
- [C-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
นอกเหนือจากโหมดประหยัดพลังงานแล้ว การนำอุปกรณ์ Android ไปใช้อาจจะใช้สถานะกำลังนอนหลับใดๆ หรือทั้งหมด 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)
หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟ S4 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้
- >
หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟฟ้า S3 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้
-
[C-2-1] ต้องตรงตาม C-1-1 ข้างต้น หรือต้องป้อนสถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่จำเป็นต้องใช้ทรัพยากรระบบ (เช่น หน้าจอ, CPU)
ในทางกลับกัน ต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรระบบตามที่อธิบายไว้ใน SDK นี้
เช่น ในขณะที่แอปพลิเคชันของบุคคลที่สามจะขอเปิดหน้าจอไว้ผ่าน
FLAG_KEEP_SCREEN_ON
หรือให้ CPU ทำงานอย่างต่อเนื่องผ่านPARTIAL_WAKE_LOCK
อุปกรณ์ต้องไม่ป้อนสถานะ S3 เว้นแต่ผู้ใช้ได้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ใช้งาน ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน ในช่วงเวลาหนึ่งเมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามทำผ่าน JobScheduler หรือมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ผู้ใช้ได้เปลี่ยนอุปกรณ์ให้เป็นสถานะไม่ใช้งาน ตัวอย่างเหล่านี้ไม่ใช่ตัวอย่างที่ครอบคลุมและ AOSP ใช้สัญญาณการปลุกระบบที่ครอบคลุมซึ่งจะกระตุ้นการปลุกระบบจากสถานะนี้
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 ที่มีการตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
- [C-0-6] ต้องให้สิทธิ์แก่
android.permission.RECOVER_KEYSTORE
แก่แอปของระบบที่ลงทะเบียน Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างถูกต้องเท่านั้น Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างเหมาะสมหมายถึง Agent ซอฟต์แวร์ในอุปกรณ์ที่ซิงค์ข้อมูลกับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยซึ่งมีการปกป้องเทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key ห้องนิรภัย เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซในปัจจัยที่เกี่ยวข้องกับหน้าจอล็อก
หากการใช้งานอุปกรณ์มีแอปที่ติดตั้งมาล่วงหน้า หรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [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] ต้องใช้การป้องกันรายการเพิ่มเติมของสแต็กเคอร์เนล (เช่น
CONFIG_CC_STACKPROTECTOR_STRONG
) - [C-0-8] ต้องใช้การป้องกันหน่วยความจำของเคอร์เนลที่เข้มงวด โดยที่โค้ดสั่งการจะเป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวจะเป็นข้อมูลที่สั่งการไม่ได้และเขียนไม่ได้ และข้อมูลที่เขียนได้นั้นไม่สามารถเรียกใช้ได้ (เช่น
CONFIG_DEBUG_RODATA
หรือCONFIG_STRICT_KERNEL_RWX
) - [C-0-9] ต้องใช้การตรวจสอบขอบเขตของขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และเคอร์เนล (เช่น
CONFIG_HARDENED_USERCOPY
) ในอุปกรณ์ที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป - [C-0-10] ต้องไม่เรียกใช้หน่วยความจำพื้นที่ผู้ใช้เมื่อทำงานในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือจำลองผ่าน
CONFIG_CPU_SW_DOMAIN_PAN
หรือCONFIG_ARM64_SW_TTBR0_PAN
) ในอุปกรณ์ที่จัดส่งด้วย API ระดับ 28 ขึ้นไปแต่เดิม - [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำของพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึงผู้ใช้สำเนาปกติ (เช่น PAN ของฮาร์ดแวร์ หรือจำลองผ่าน
CONFIG_CPU_SW_DOMAIN_PAN
หรือCONFIG_ARM64_SW_TTBR0_PAN
) ในอุปกรณ์ที่จัดส่งด้วย API ระดับ 28 ขึ้นไปแต่เดิม - [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลในอุปกรณ์ทั้งหมดที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป (เช่น
CONFIG_PAGE_TABLE_ISOLATION
หรือ "CONFIG_UNMAP_KERNEL_AT_EL0) - [SR] แนะนำอย่างเข้มงวดให้เก็บข้อมูลเคอร์เนลที่จะเขียนเฉพาะในช่วงเริ่มต้นที่มีการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น
__ro_after_init
) - [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] ต้องไม่แก้