1. ข้อมูลเบื้องต้น
เอกสารนี้แจกแจงข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้อุปกรณ์ใช้งานร่วมกับ Android 13 ได้
การใช้ตัวเลือก "ต้อง" "ต้องไม่" "จำเป็น" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119
"ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" คือบุคคลหรือองค์กรที่กำลังพัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 13 ตามที่ใช้ในเอกสารนี้ "การใช้งานอุปกรณ์" หรือ "การใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น
หากต้องการรับการพิจารณาว่าใช้งานร่วมกับ Android 13 ได้ การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ ซึ่งรวมถึงเอกสารใดก็ตามที่รวบรวมผ่านข้อมูลอ้างอิง
เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 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
- W: การใช้งาน Android Watch
- แท็บ: การใช้งานแท็บเล็ต Android
- รหัสเงื่อนไข
- เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะกำหนดรหัสนี้เป็น 0
- เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนด 1 สำหรับเงื่อนไขที่ 1 และเพิ่มตัวเลขครั้งละ 1 ในส่วนเดียวกันและอุปกรณ์ประเภทเดียวกัน
- รหัสข้อกำหนด
- รหัสนี้จะเริ่มต้นจาก 1 และเพิ่มทีละ 1 ภายในส่วนเดียวกันและ เงื่อนไขเดียวกัน
1.1.3 รหัสข้อกำหนดในส่วนที่ 2
รหัสข้อกําหนดในส่วนที่ 2 มี 2 ส่วน ส่วนแรกคือรหัสส่วนตามที่อธิบายไว้ข้างต้น ส่วนที่ 2 จะระบุรูปแบบของอุปกรณ์และข้อกำหนดเฉพาะของรูปแบบของอุปกรณ์
รหัสส่วนตามด้วยรหัสข้อกำหนดที่อธิบายไว้ข้างต้น
- รหัสในส่วนที่ 2 ประกอบด้วย รหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)
2. ประเภทอุปกรณ์
โครงการโอเพนซอร์ส Android มีกลุ่มซอฟต์แวร์ที่สามารถใช้งานได้สำหรับอุปกรณ์และรูปแบบของอุปกรณ์ที่หลากหลาย เพื่อรองรับความปลอดภัยในอุปกรณ์ สแต็กซอฟต์แวร์ ซึ่งรวมถึงระบบปฏิบัติการทดแทนหรือการใช้งานเคอร์เนลสำรอง ควรดำเนินการในสภาพแวดล้อมที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9 และส่วนอื่นภายใน CDD นี้ มีอุปกรณ์ 2-3 ประเภทที่มีระบบนิเวศการจัดจำหน่ายแอปพลิเคชันค่อนข้างดีกว่า
ส่วนนี้จะอธิบายประเภทอุปกรณ์เหล่านั้น รวมถึงข้อกำหนดและคำแนะนำเพิ่มเติมที่เกี่ยวข้องกับอุปกรณ์แต่ละประเภท
การใช้งานอุปกรณ์ Android ทั้งหมดที่ไม่เข้ากับประเภทอุปกรณ์ใดๆ ที่ได้อธิบายไว้ ยังคงต้องตรงตามข้อกำหนดทั้งหมดในส่วนอื่นๆ ของคำจำกัดความความเข้ากันได้นี้
2.1 การกำหนดค่าอุปกรณ์
สำหรับความแตกต่างที่สำคัญในการกำหนดค่าฮาร์ดแวร์ตามประเภทอุปกรณ์ โปรดดูข้อกำหนดเฉพาะอุปกรณ์ที่ตามมาในส่วนนี้
2.2 ข้อกำหนดสำหรับอุปกรณ์พกพา
อุปกรณ์พกพา Android หมายถึงการใช้งานอุปกรณ์ Android ที่โดยปกติจะใช้โดยการถือไว้ในมือ เช่น เครื่องเล่น MP3, โทรศัพท์ หรือแท็บเล็ต
การใช้งานอุปกรณ์ Android จัดว่าเป็นอุปกรณ์พกพาหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- มีขนาดหน้าจอตามจริงในช่วง 3.3 นิ้ว (หรือ 2.5 นิ้วสำหรับการใช้งานอุปกรณ์ซึ่งจัดส่งใน API ระดับ 29 หรือเก่ากว่า) ถึง 8 นิ้ว
ข้อกำหนดเพิ่มเติมในส่วนอื่นของส่วนนี้เกี่ยวข้องกับการใช้งาน มือถือ Android เท่านั้น
2.2.1. ฮาร์ดแวร์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.1.1.1/H-0-1] ต้องมีจอแสดงผลที่รองรับ Android อย่างน้อย 1 เครื่องที่เป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในเอกสารนี้
[7.1.1.3/H-SR-1] แนะนำอย่างหนักแน่นเพื่อช่วยให้เราสามารถเปลี่ยนขนาดการแสดงผล (ความหนาแน่นของหน้าจอ)
[7.1.1.1/H-0-2] ต้องรองรับองค์ประกอบ GPU ของบัฟเฟอร์กราฟิกอย่างน้อยเท่ากับความละเอียดสูงสุดของจอแสดงผลในตัว
หากการใช้งานอุปกรณ์พกพารองรับการหมุนหน้าจอซอฟต์แวร์ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.1.1.1/H-1-1]* ต้องทำให้หน้าจอเชิงตรรกะที่พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามมีขนาดอย่างน้อย 2 นิ้วสำหรับด้านสั้นและ 2.7 นิ้วสำหรับด้านยาว อุปกรณ์ที่จัดส่ง Android API ระดับ 29 หรือเก่ากว่าอาจได้รับการยกเว้นจากข้อกำหนดนี้
หากการใช้งานอุปกรณ์พกพาไม่รองรับการหมุนหน้าจอซอฟต์แวร์ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.1.1.1/H-2-1]* ต้องทำให้หน้าจอเชิงตรรกะที่พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามมีขนาดอย่างน้อย 2.7 นิ้วในด้านขอบสั้นๆ อุปกรณ์ที่จัดส่ง Android API ระดับ 29 หรือเก่ากว่าอาจได้รับการยกเว้นจากข้อกำหนดนี้
หากการใช้งานอุปกรณ์พกพาระบุว่ารองรับการแสดงช่วงไดนามิกกว้างถึง 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.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการทำโปรไฟล์ GPU ผ่านพร็อพเพอร์ตี้ของระบบหรือไม่
graphics.gpu.profiler.support
การใช้งานอุปกรณ์เคลื่อนที่ประกาศการรองรับผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support
จะมีผลดังนี้
- [7.1.4.6/H-1-1] ต้องรายงานว่าสร้างเอาต์พุตเป็นการติดตาม Protobuf ที่สอดคล้องกับสคีมาสำหรับตัวนับ GPU และขั้นตอนการแสดงผล GPU ที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [7.1.4.6/H-1-2] ต้องรายงานค่าที่สอดคล้องกันสำหรับตัวนับ GPU ของอุปกรณ์ตาม โปรโตคอลการติดตามตัวนับ gpu
- [7.1.4.6/H-1-3] ต้องรายงานค่าที่สอดคล้องกันสำหรับ GPU RenderStag ของอุปกรณ์ตาม Proto แพ็คเก็ตการติดตามขั้นตอนการแสดงผล
- [7.1.4.6/H-1-4] ต้องรายงานจุดติดตามความถี่ของ GPU ตามที่ระบุโดยรูปแบบ: power/gpu_frequency
การใช้งานอุปกรณ์เคลื่อนที่
- [7.1.5/H-0-1] ต้องมีการรองรับโหมดความเข้ากันได้ของแอปพลิเคชันเดิมตามที่ใช้โดยโค้ดโอเพนซอร์สของ Android อัปสตรีม กล่าวคือ การใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่จะเปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนลักษณะการทำงานของโหมดความเข้ากันได้
- [7.2.1/H-0-1] ต้องมีการสนับสนุนสำหรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม
- [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์ปกติและเหตุการณ์การกดค้างของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า เหตุการณ์เหล่านี้ต้องไม่ใช้โดยระบบ และทริกเกอร์โดยอุปกรณ์ Android ภายนอกได้ (เช่น แป้นพิมพ์ฮาร์ดแวร์ภายนอก ที่เชื่อมต่อกับอุปกรณ์ Android) - [7.2.3/H-0-3] ต้องระบุฟังก์ชันหน้าแรกบนทุกจอแสดงผลที่รองรับ Android ที่มีหน้าจอหลัก
- [7.2.3/H-0-4] ต้องระบุฟังก์ชันกลับในจอแสดงผลที่รองรับ Android และฟังก์ชันล่าสุดในจอแสดงผลที่รองรับ Android อย่างน้อย 1 จอ
- [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
- [7.2.4/H-SR-1] แนะนําอย่างยิ่งให้เปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ เป็นแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ
ACTION_ASSIST
เมื่อมีการกดKEYCODE_MEDIA_PLAY_PAUSE
หรือKEYCODE_HEADSETHOOK
ค้างไว้ หากกิจกรรมเบื้องหน้าจัดการกิจกรรมการกดค้างเหล่านั้นไม่ได้ - [7.3.1/H-SR-1] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการใช้งานอุปกรณ์พกพามีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/H-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
หากใช้งานอุปกรณ์พกพารวมถึงตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
สิ่งต่อไปนี้
- [7.3.3/H-2-1] ต้องรายงานการวัด GNSS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [7.3.3/H-2-2] ต้องรายงานอัตรา Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีในวินาทีที่ 2 เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 9% ต่อเวลาอย่างน้อย 9% ต่อวินาที
หากการใช้งานอุปกรณ์พกพามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/H-3-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
- [7.3.4/H-3-2] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไป ได้สูงสุด 1,000 องศาต่อวินาที
การใช้งานอุปกรณ์เคลื่อนที่ที่สามารถโทรออกและระบุค่าใดๆ ที่ไม่ใช่ PHONE_TYPE_NONE
ใน getPhoneType
- [7.3.8/H] ควรมีพร็อกซิมิตีเซ็นเซอร์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.3.11/H-SR-1] แนะนำอย่างยิ่งให้รองรับเซ็นเซอร์ท่าทาง ที่มีอิสระ 6 องศา
- [7.4.3/H] ควรมีการรองรับบลูทูธและบลูทูธ LE
หากอุปกรณ์รองรับโปรโตคอล Wi-Fi Neighbor Awareness Networking (NAN) โดยประกาศ PackageManager.FEATURE_WIFI_AWARE
และตำแหน่ง Wi-Fi (Wi-Fi Round Time — RTT) โดยประกาศ PackageManager.FEATURE_WIFI_RTT
อุปกรณ์จะมีลักษณะดังนี้
[7.4.2.5/H-1-1] ต้องรายงานช่วงอย่างถูกต้องภายในช่วงแบนด์วิดท์ +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามการคำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68+ Manager และแบนด์วิดท์ที่ 68 MHz ที่เปอร์เซ็นไทล์ที่ 68+
[7.4.2.5/H-SR-1] API 1 Hz + Hz เป็นคำแนะนำอย่างยิ่งให้รายงานช่วงที่แม่นยำภายในช่วง +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นไทล์ที่ 90 (ตามการคำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่ระยะทาง 80 MHz ที่เปอร์เซ็นไทล์ที่ 90-4 MHz ที่ระยะทาง 80 MHz ที่เปอร์เซ็นไทล์ผู้จัดการ +
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในการปรับเทียบสถานที่ตั้ง
หากการใช้งานอุปกรณ์พกพารวมถึงอุปกรณ์กล้องเชิงตรรกะที่แสดงความสามารถที่ใช้ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
สิ่งต่างๆ ต่อไปนี้
- [7.5.4/H-1-1] ต้องมีขอบเขตการมองเห็น (FOV) ปกติโดยค่าเริ่มต้น และต้องอยู่ระหว่าง 50 ถึง 95 องศา
การใช้งานอุปกรณ์เคลื่อนที่
- [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] ต้องประกาศ Flag ฟีเจอร์
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
หากการใช้งานอุปกรณ์พกพามีขนาดมากกว่าหรือเท่ากับ 2 GB และมีหน่วยความจำที่ใช้ได้น้อยกว่า 4 GB ในเคอร์เนลและพื้นที่ผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับพื้นที่ผู้ใช้แบบ 32 บิตเท่านั้น (ทั้งแอปและโค้ดของระบบ)
หากการใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่า 2 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ จะเกิดสิ่งต่อไปนี้
- [7.6.1/H-1-1] ต้องรองรับ ABI แบบ 32 บิตเท่านั้น
การใช้งานอุปกรณ์เคลื่อนที่
- [7.6.2/H-0-1] ต้องไม่ให้พื้นที่เก็บข้อมูลที่แชร์ในแอปพลิเคชันที่มีขนาดเล็กกว่า 1 GiB
- [7.7.1/H] ควรรวมพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
หากการใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง จะมีผลดังนี้
- [7.7.1/H-1-1] ต้องใช้ API ของ Android Open Accessory (AOA)
หากการใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดโฮสต์ ซึ่งจะดำเนินการดังต่อไปนี้
- [7.7.2/H-1-1] ต้องใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
การใช้งานอุปกรณ์เคลื่อนที่
- [7.8.1/H-0-1] ต้องมีไมโครโฟน
- [7.8.2/H-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
หากการใช้งานอุปกรณ์พกพาสามารถเป็นไปตามข้อกำหนดด้านประสิทธิภาพทั้งหมดสำหรับการรองรับโหมด VR และมีการรองรับการใช้งาน ระบบจะดำเนินการต่อไปนี้
- [7.9.1/H-1-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.vr.high_performance
- [7.9.1/H-1-2] ต้องมีแอปพลิเคชันที่ใช้งาน
android.service.vr.VrListenerService
ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่านandroid.app.Activity#setVrModeEnabled
หากการใช้งานอุปกรณ์พกพามีพอร์ต USB-C อย่างน้อย 1 พอร์ตในโหมดโฮสต์และมีการใช้งาน (คลาสเสียง USB) นอกเหนือจากข้อกำหนดในส่วนที่ 7.7.2 แล้ว การดำเนินการดังต่อไปนี้
- [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์เกี่ยวกับโค้ด HID ต่อไปนี้
การทำงาน | การแมป | บริบท | ลักษณะการทำงาน |
---|---|---|---|
A | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CD คีย์เคอร์เนล: KEY_PLAYPAUSE คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE |
การเล่นสื่อ | อินพุต: กดสั้นๆ เอาต์พุต: เล่นหรือหยุดชั่วคราว |
อินพุต: กดค้าง เอาต์พุต: เปิดคำสั่งเสียง ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ล็อกอยู่หรือหน้าจอปิดอยู่ ให้ส่ง
android.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
สายเรียกเข้า | อินพุต: กดสั้นๆ เอาต์พุต: รับสาย |
||
อินพุต: กดค้าง เอาต์พุต: ปฏิเสธสาย |
|||
สายที่สนทนาอยู่ | อินพุต: กดสั้นๆ เอาต์พุต: วางสาย |
||
อินพุต: กดค้าง เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน |
|||
หมื่นล้าน | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0E9 คีย์เคอร์เนล: KEY_VOLUMEUP คีย์ Android: VOLUME_UP |
การเล่นสื่อ การโทรที่ดำเนินอยู่ | อินพุต: กดสั้นหรือค้าง เอาต์พุต: เพิ่มระดับเสียงของระบบหรือชุดหูฟัง |
C | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0EA คีย์เคอร์เนล: KEY_VOLUMEDOWN คีย์ Android: VOLUME_DOWN |
การเล่นสื่อ การโทรที่ดำเนินอยู่ | อินพุต: การกดสั้นหรือยาว เอาต์พุต: ลดระดับเสียงของระบบหรือชุดหูฟัง |
D | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CF คีย์เคอร์เนล: KEY_VOICECOMMAND คีย์ Android: KEYCODE_VOICE_ASSIST |
ทั้งหมด ทริกเกอร์ได้ในทุกอินสแตนซ์ | อินพุต: กดสั้นหรือค้าง เอาต์พุต: เปิดคำสั่งเสียง |
- [7.8.2.2/H-1-2] ต้องเรียกใช้ ACTION_HEADSET_PLUG เมื่อมีการเสียบปลั๊ก แต่หลังจากมีการระบุอินเทอร์เฟซเสียงและปลายทาง USB อย่างถูกต้องเพื่อระบุประเภทของเทอร์มินัลที่เชื่อมต่อเท่านั้น
เมื่อตรวจพบขั้วปลายสายไฟ USB ประเภท 0x0302 จะเกิดสิ่งต่อไปนี้
- [7.8.2.2/H-2-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย การตั้งค่า "ไมโครโฟน" ส่วนเกินเป็น 0
เมื่อตรวจพบขั้วปลายสายไฟ USB ประเภท 0x0402 จะเกิดสิ่งต่อไปนี้
- [7.8.2.2/H-3-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ส่วนเกินที่ตั้งค่าเป็น 1
เมื่อมีการเรียกใช้ API AudioManager.get Devices() ขณะที่ต่ออุปกรณ์ต่อพ่วง USB อยู่
[7.8.2.2/H-4-1] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x0302
[7.8.2.2/H-4-2] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x0402
[7.8.2.2/H-4-3] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x0402
[7.8.2.2/H-4-4] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x603
[7.8.2.2/H-4-5] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x604
[7.8.2.2/H-4-6] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x400
[7.8.2.2/H-4-7] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x400
[7.8.2.2/H-SR-1] แนะนำอย่างยิ่งเมื่อมีการเชื่อมต่อ อุปกรณ์ต่อพ่วงเสียง USB-C เพื่อแจกแจงข้อบ่งชี้ทาง USB, ระบุประเภทเทอร์มินัลและออกอากาศ Intent ACTION_HEADSET_PLUG ในเวลาน้อยกว่า 1, 000 มิลลิวินาที
หากการใช้งานอุปกรณ์พกพาประกาศเป็น android.hardware.audio.output
และ android.hardware.microphone
สิ่งที่จะเกิดขึ้นมีดังนี้
[5.6/H-1-1] ต้องมีเวลาในการตอบสนองเฉลี่ยแบบไป-กลับที่ 500 มิลลิวินาทีหรือน้อยกว่า ในการวัด 5 ครั้ง โดยมีค่าเบี่ยงเบนเฉลี่ยค่าเบี่ยงเบนน้อยกว่า 50 มิลลิวินาที สำหรับเส้นทางข้อมูลดังต่อไปนี้: "ลำโพงสู่ไมโครโฟน", อะแดปเตอร์แบบวนกลับ 3.5 มม. (หากรองรับ)
[5.6/H-1-2] ต้องมีเวลาในการตอบสนอง "แตะเพื่อโทนเสียง" โดยเฉลี่ยอยู่ที่ 500 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดค่าระหว่างลำโพงสู่ไมโครโฟนอย่างน้อย 5 เส้นทาง
หากการใช้งานอุปกรณ์พกพามีตัวกระตุ้นการโต้ตอบแบบรู้สึกได้อย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.10/H]* ไม่ควรใช้ตัวขับเคลื่อนแบบรู้สึกได้ (การสั่น) แบบหมุนศูนย์กลาง (ERM)
- [7.10/H]* ควรวางตำแหน่งของตัวเปิดใช้งานใกล้กับตำแหน่งที่มักถือหรือสัมผัสอุปกรณ์ด้วยมือ
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสำหรับการโต้ตอบการสัมผัส ใน android.view.HapticFeedbackConstants ซึ่งก็คือ (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYUREBOARD_VITUALE,HANDKEYLE_KEY,
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสำหรับการโต้ตอบแบบรู้สึกได้ชัดเจน
ใน android.os.VibrationEffect
ได้แก่ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ
EFFECT_DOUBLE_CLICK) และ easible Public feasible
ที่สุด
PRIMITIVE_*
constantion ของที่สมบูรณ์ ตัวแปรพื้นฐานเหล่านี้ เช่น LOW_TICK และ SPIN อาจใช้ได้ก็ต่อเมื่อการสั่นรองรับความถี่ได้ค่อนข้างต่ำเท่านั้น [7.10/H]* ควรปฏิบัติตามคำแนะนำในการแมปค่าคงที่สาธารณะใน android.view.HapticFeedbackConstants กับค่าคงที่ android.os.VibrationEffect ที่แนะนำ พร้อมความสัมพันธ์แอมพลิจูดที่สอดคล้องกัน
[7.10/H]* ควรปฏิบัติตาม การประเมินคุณภาพ สำหรับ API ของ createOneShot() และ createWaveform()
[7.10/H]* ควรตรวจสอบว่าผลลัพธ์ของ API สาธารณะ android.os.Vibrator.hasAmplitudeControl() แสดงความสามารถของการสั่นอย่างถูกต้อง
แอคชูเอเตอร์เชิงเส้น (LRA) เป็นระบบสปริงแบบมวลเดี่ยวซึ่งมีความถี่สะท้อนเสียงที่โดดเด่นซึ่งมวลจะแปลไปในทิศทางของการเคลื่อนที่ที่ต้องการ
หากการใช้งานอุปกรณ์พกพามีตัวเปิดใช้เรโซแนนต์เชิงเส้นอย่างน้อย 1 ตัว
- [7.10/H]* ควรย้ายตัวดำเนินการแบบรู้สึกได้ในแกน X (ซ้าย-ขวา) ของการวางแนวตั้ง
หากการใช้งานอุปกรณ์พกพามีตัวกระตุ้นการโต้ตอบแบบรู้สึกได้ที่เป็นแอคชูเอเตอร์เชิงเส้นแกน X (LRA) อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.10/H]* ควรมีความถี่เรโซแนนซ์ของแกน X LRA ต่ำกว่า 200 Hz
หากการใช้งานอุปกรณ์พกพาเป็นไปตามการแมปค่าคงที่แบบรู้สึกได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.10/H]* ควรตรวจสอบสถานะการใช้งานโดยเรียกใช้ API ของ android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitivesSupported()
[7.10/H]* ควรทำการประเมินคุณภาพสำหรับค่าคงที่แบบรู้สึกได้
[7.10/H]* ควรตรวจสอบและอัปเดตหากจำเป็นสำหรับการกำหนดค่าสำรองสำหรับค่าดั้งเดิมที่ไม่รองรับ ตามที่อธิบายไว้ในหลักเกณฑ์การใช้งานสำหรับค่าคงที่
2.2.2. มัลติมีเดีย
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการเข้ารหัสและถอดรหัสเสียงต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/H-0-4] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และทำให้รูปแบบดังกล่าวพร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
2.2.3. ซอฟต์แวร์
การใช้งานอุปกรณ์เคลื่อนที่
- [3.2.3.1/H-0-1] ต้องมีแอปพลิเคชันที่จัดการ
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
และACTION_CREATE_DOCUMENT
ตามที่อธิบายไว้ในเอกสาร SDK และมอบค่าตอบแทนแก่ผู้ใช้ในการเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้DocumentsProvider
- [3.2.3.1/H-0-2]* ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยจุดประสงค์ของแอปพลิเคชันต่อไปนี้ที่แสดงที่นี่
- [3.2.3.1/H-SR-1] แนะนำอย่างยิ่งให้โหลดแอปพลิเคชันอีเมลล่วงหน้าที่สามารถรองรับACTION_SENDTOหรือACTION_SENDหรือACTION_SEND_MULTIPLEการส่งอีเมลได้
- [3.4.1/H-0-1] ต้องมีการติดตั้งใช้งาน API ของ
android.webkit.Webview
ให้เสร็จสมบูรณ์ - [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
- [3.8.1/H-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ widgetFeatures ในแอป
- [3.8.1/H-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนสำหรับทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน API แป้นพิมพ์ลัด
- [3.8.1/H-SR-3] ขอแนะนำอย่างยิ่ง ให้รวมแอป Launcher เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป
- [3.8.2/H-SR-1] ขอแนะนำอย่างยิ่ง ให้รองรับวิดเจ็ตแอปของบุคคลที่สาม
- [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-1] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแรกที่มีให้ผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ - [3.8.3/H-SR-2] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกทั้งหมดที่มีให้ผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดในหน้าต่างแจ้งเตือน - [3.8.3.1/H-SR-1] แนะนำอย่างยิ่งให้แสดงการดำเนินการที่ตั้งค่า
Notification.Action.Builder.setContextual
เป็นtrue
ที่สอดคล้องกับการตอบกลับที่แสดงโดยNotification.Remoteinput.Builder.setChoices
- [3.8.4/H-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ใช้ผู้ช่วยบนอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
หากการใช้งานอุปกรณ์พกพารองรับการแจ้งเตือน MediaStyle การดำเนินการต่อไปนี้
- [3.8.3.1/H-SR-2] แนะนำอย่างยิ่ง
เพื่ออำนวยความสะดวกแก่ผู้ใช้ (เช่น ตัวสลับเอาต์พุต) ที่เข้าถึงจาก UI ของระบบซึ่งอนุญาตให้ผู้ใช้สลับระหว่างเส้นทางสื่อที่เหมาะสมต่างๆ (เช่น อุปกรณ์บลูทูธและเส้นทางที่ให้ไว้
MediaRouter2Manager
) แอปโพสต์การแจ้งเตือนMediaStyle
พร้อมโทเค็นMediaSession
หากการใช้งานอุปกรณ์เคลื่อนที่รองรับการดำเนินการของ "ผู้ช่วย" สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.4/H-SR-2] แนะนำอย่างยิ่งให้กดคีย์
HOME
ค้างไว้เป็นการโต้ตอบที่กำหนดไว้เพื่อเปิดแอปช่วยเหลือตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
หากการใช้งานอุปกรณ์เคลื่อนที่รองรับ conversation notifications
และจัดกลุ่มอุปกรณ์เหล่านี้ไว้เป็นส่วนแยกต่างหากจากการแจ้งเตือนที่ไม่ได้แจ้งเตือนการสนทนาและปิดเสียงการแจ้งเตือน สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.4/H-1-1]* ต้องแสดงการแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือน Priority:high อย่างต่อเนื่อง
การใช้งานอุปกรณ์มือถือ Android รองรับหน้าจอล็อกจะส่งผลดังนี้
- [3.8.10/H-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9/H-1-1] ต้องบังคับใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสาร Android SDK
หากการใช้งานอุปกรณ์พกพารวมถึงการรองรับ API ของ
ControlsProviderService
และ Control
และอนุญาตให้แอปพลิเคชันของบุคคลที่สามเผยแพร่ระบบควบคุมอุปกรณ์ ระบบจะดำเนินการต่อไปนี้
- [3.8.16/H-1-1] ต้องประกาศ
แฟล็กฟีเจอร์
android.software.controls
และตั้งค่าเป็นtrue
- [3.8.16/H-1-2] ต้องระบุความสามารถในการเพิ่ม แก้ไข เลือก และจัดการการควบคุมอุปกรณ์โปรดของผู้ใช้จากการควบคุมที่ลงทะเบียนโดยแอปพลิเคชันบุคคลที่สามผ่าน
ControlsProviderService
และControl
API - [3.8.16/H-1-3] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้รายนี้ภายในการโต้ตอบ 3 ครั้งจาก Launcher เริ่มต้น
[3.8.16/H-1-4] ต้องแสดงผลอย่างถูกต้องในผู้ใช้รายนี้ และระบุชื่อและไอคอนของแอปบุคคลที่สามแต่ละแอปที่แสดงการควบคุมผ่าน
ControlsProviderService
API รวมถึงช่องที่ระบุโดยControl
API[3.8.16/H-1-5] ต้องให้เงินแก่ผู้ใช้ในการเลือกไม่ใช้ระบบควบคุมอุปกรณ์ในการตรวจสอบสิทธิ์ที่กำหนดไว้สำหรับแอปจากการควบคุมที่ลงทะเบียนโดยแอปพลิเคชันบุคคลที่สามผ่าน
ControlsProviderService
และControl
Control.isAuthRequired
API
ในทางกลับกัน หากการใช้งานอุปกรณ์พกพาไม่ได้ใช้การควบคุมดังกล่าว เราจะดำเนินการต่อไปนี้
- [3.8.16/H-2-1] ต้องรายงาน
null
สำหรับControlsProviderService
และControl
API - [3.8.16/H-2-2] ต้องประกาศ
แฟล็กฟีเจอร์
android.software.controls
และตั้งค่าเป็นfalse
หากการใช้งานอุปกรณ์เคลื่อนที่ไม่ทำงานในโหมดล็อกงาน เมื่อคัดลอกเนื้อหาไปยังคลิปบอร์ด จะมีผลดังนี้
- [3.8.17/H-1-1] ต้องแสดงการยืนยันให้ผู้ใช้ทราบว่ามีการคัดลอกข้อมูลไปยังคลิปบอร์ดแล้ว (เช่น ภาพขนาดย่อหรือการแจ้งเตือน "คัดลอกเนื้อหา") นอกจากนี้ โปรดระบุที่นี่ที่ระบุว่าระบบจะซิงค์ข้อมูลคลิปบอร์ดในอุปกรณ์ต่างๆ ด้วยหรือไม่
การใช้งานอุปกรณ์เคลื่อนที่
- [3.10/H-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/H-SR-1] ขอแนะนำเป็นอย่างยิ่งให้โหลดบริการการเข้าถึงล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์สของ TalkBack
- [3.11/H-0-1] ต้องรองรับการติดตั้ง เครื่องมือ TTS ของบุคคลที่สาม
- [3.11/H-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
- [3.13/H-SR-1] ขอแนะนำอย่างยิ่งให้รวมคอมโพเนนต์ UI ของการตั้งค่าด่วน
หากการใช้งานอุปกรณ์พกพาของ Android ประกาศการรองรับ FEATURE_BLUETOOTH
หรือ FEATURE_WIFI
สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.16/H-1-1] ต้องรองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้
- [7.2.3/H] โซนการจดจำท่าทางสัมผัสสำหรับฟังก์ชัน Home ควรสูงจากด้านล่างของหน้าจอไม่เกิน 32 dp
หากการใช้งานอุปกรณ์พกพามีฟังก์ชันการนำทางเป็นท่าทางสัมผัสจากที่ใดก็ได้ที่ขอบซ้ายและขวาของหน้าจอ
- [7.2.3/H-0-1] พื้นที่ท่าทางสัมผัสของฟังก์ชันการนำทาง ต้องมีความกว้างน้อยกว่า 40 dp ในแต่ละด้าน พื้นที่ท่าทางสัมผัสควรมีความกว้าง 24 dp โดยค่าเริ่มต้น
หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัยและมีหน่วยความจำมากกว่าหรือเท่ากับ 2 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่มีการจัดการผ่านแฟล็กฟีเจอร์
android.software.managed_users
หากการใช้งานอุปกรณ์พกพาของ Android ประกาศการรองรับกล้องผ่าน android.hardware.camera.any
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.5.4/H-1-1] ต้องเป็นไปตามความตั้งใจ
android.media.action.STILL_IMAGE_CAMERA
และandroid.media.action.STILL_IMAGE_CAMERA_SECURE
และเปิดกล้องในโหมดภาพนิ่งตามที่อธิบายไว้ใน SDK - [7.5.4/H-1-2] ต้องเป็นไปตาม
android.media.action.VIDEO_CAMERA
ความตั้งใจที่จะเปิดกล้องในโหมดวิดีโอตามที่อธิบายไว้ใน SDK
หากแอปพลิเคชันการตั้งค่าการใช้งานอุปกรณ์พกพาใช้ฟังก์ชันการแยกส่วนโดยใช้การฝังกิจกรรม การดำเนินการต่อไปนี้
- [3.2.3.1/ H-1-1]
ต้องมีกิจกรรมที่จัดการ Intent
การตั้งค่า#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYเมื่อเปิดฟังก์ชันการทำงานแบบแยกส่วน กิจกรรมต้องได้รับการคุ้มครองโดย
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
และต้อง เริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จาก การตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI
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] ต้องเป็นไปตามความตั้งใจ
android.intent.action.POWER_USAGE_SUMMARY
และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้
การใช้งานอุปกรณ์เคลื่อนที่
- [8.5/H-0-1] ต้องระบุราคาสำหรับผู้ใช้ในเมนูการตั้งค่า ซึ่งมีความสามารถในการหยุดแอปที่กำลังให้บริการที่ทำงานอยู่เบื้องหน้า และแสดงแอปทั้งหมดที่มีบริการที่ทำงานอยู่เบื้องหน้าและระยะเวลาของบริการแต่ละรายการตั้งแต่ที่เริ่มให้บริการตามที่อธิบายไว้ในเอกสาร SDK
- แอปบางแอปอาจได้รับการยกเว้นไม่ต้องถูกหยุดหรือระบุไว้ในราคาของผู้ใช้ตามที่อธิบายไว้ในเอกสาร SDK
2.2.5 โมเดลการรักษาความปลอดภัย
การใช้งานอุปกรณ์เคลื่อนที่
- [9.1/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานผ่านสิทธิ์
android.permission.PACKAGE_USAGE_STATS
และมอบกลไกที่ผู้ใช้เข้าถึงได้เพื่ออนุญาตหรือเพิกถอนสิทธิ์เข้าถึงแอปดังกล่าวเพื่อตอบสนองต่อความตั้งใจandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
การใช้งานอุปกรณ์เคลื่อนที่
- [9.11/H-0-2] ต้องสำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/H-0-3] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชตระกูล MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/H-0-4] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/H-0-5] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
- [9/H-0-1] ต้องประกาศฟีเจอร์ "android.hardware.security.model.compatible"
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
การใช้งานอุปกรณ์เคลื่อนที่ที่รองรับหน้าจอล็อกที่ปลอดภัยจะส่งผลดังนี้
- [9.11/H-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาโหมดสลีปที่สั้นที่สุด นั่นคือเวลาเปลี่ยนจากการปลดล็อกมาเป็นสถานะล็อก ซึ่งต้องไม่เกิน 15 วินาที
- [9.11/H-1-2] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการซ่อนการแจ้งเตือนและปิดใช้การตรวจสอบสิทธิ์ทุกรูปแบบ ยกเว้นการตรวจสอบสิทธิ์หลักที่อธิบายไว้ในหน้าจอล็อกที่ปลอดภัยในเวอร์ชัน 9.11.1 AOSP ตรงตามข้อกำหนด สำหรับโหมดปิดล็อก
หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายราย และไม่ได้ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/H-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่ถูกจำกัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็วเพื่อให้ผู้ใช้คนอื่นๆ ทำงานได้ พร้อมกับจัดการข้อจำกัดอย่างละเอียดในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายคนและประกาศแฟล็กฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/H-3-1] ต้องไม่รองรับโปรไฟล์ที่ถูกจำกัด แต่ต้องสอดคล้องกับการใช้การควบคุมของ AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
Android ใช้ VoiceInteractionService ผ่าน System API รองรับกลไก การตรวจจับคำสั่งให้ดำเนินการแบบเปิดตลอดเวลาที่ปลอดภัยโดยไม่มีสัญญาณบอกสถานะการเข้าถึงไมค์
หากการใช้งานอุปกรณ์พกพารองรับ System API HotwordDetectionService
หรือกลไกอื่นสำหรับการตรวจหาคำสั่งให้ดำเนินการโดยไม่มีสัญญาณการเข้าถึงไมค์ ระบบจะดำเนินการดังต่อไปนี้
- [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคำที่นิยมสามารถส่งข้อมูลไปยัง ระบบหรือ ContentCaptureService เท่านั้น
- [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการจะส่งได้เฉพาะข้อมูลเสียงไมค์หรือข้อมูลที่ได้มาจากเซิร์ฟเวอร์ของระบบผ่านทาง API ของ
HotwordDetectionService
หรือไปยังContentCaptureService
ผ่านทาง API ของContentCaptureManager
- [9.8/H-1-3] ต้องไม่ให้เสียงไมโครโฟนที่นานกว่า 30 วินาทีสำหรับคำขอที่ทริกเกอร์ด้วยฮาร์ดแวร์แต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-1-4] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับคำขอแต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-1-5] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีแก่บริการโต้ตอบด้วยเสียงหรือเอนทิตีที่คล้ายกัน
- [9.8/H-1-6] ต้องไม่ส่งข้อมูลที่ไม่ใช่เสียงเกิน 100 ไบต์ออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์คำสั่งให้ดำเนินการที่ประสบความสำเร็จแต่ละรายการ
- [9.8/H-1-7] ต้องไม่ส่งข้อมูลมากกว่า 5 บิตออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์ของคำสั่งให้ดำเนินการเชิงลบแต่ละรายการ
- [9.8/H-1-8] ต้องอนุญาตเฉพาะการส่งข้อมูลออกจากบริการตรวจหาคำที่นิยมในคำขอตรวจสอบคำสั่งให้ดำเนินการจากเซิร์ฟเวอร์ระบบเท่านั้น
- [9.8/H-1-9] ต้องไม่อนุญาตแอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจจับคำสั่งลัด
- [9.8/H-1-10] ต้องไม่แสดงข้อมูลเชิงปริมาณใน UI เกี่ยวกับการใช้งานไมค์ในบริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-1-11] ต้องบันทึกจำนวนไบต์ที่รวมอยู่ในการส่งข้อมูลทุกครั้งจากบริการตรวจจับคำสั่งให้ดำเนินการ เพื่อให้นักวิจัยความปลอดภัยสามารถตรวจสอบได้
- [9.8/H-1-12] ต้องรองรับโหมดแก้ไขข้อบกพร่องที่บันทึกเนื้อหาดิบของการส่งข้อมูลทุกรายการจากบริการตรวจจับคำสั่งให้ดำเนินการ เพื่อให้นักวิจัยด้านความปลอดภัยสามารถตรวจสอบได้
- [9.8/H-1-14] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนตามที่อธิบายไว้ในส่วน 9.8.2 เมื่อมีการส่งผลลัพธ์ของคำสั่งให้ดำเนินการที่ประสบความสำเร็จไปยังบริการโต้ตอบด้วยเสียงหรือเอนทิตีที่คล้ายกัน
- [9.8/H-SR-1] ขอแนะนำอย่างยิ่งให้แจ้งเตือนผู้ใช้ก่อนที่จะตั้งค่าแอปพลิเคชันเป็นผู้ให้บริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ไม่อนุญาตให้ส่งข้อมูลที่ไม่มีโครงสร้างออกจากบริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-SR-3] ขอแนะนำอย่างยิ่งให้รีสตาร์ทกระบวนการที่โฮสต์บริการตรวจจับคำสั่งลัดอย่างน้อย 1 ครั้งทุกชั่วโมงหรือทุก 30 เหตุการณ์ทริกเกอร์ฮาร์ดแวร์ ขึ้นอยู่กับว่ากรณีใดจะเกิดขึ้นก่อน
หากการใช้งานอุปกรณ์มีแอปพลิเคชันที่ใช้ System API HotwordDetectionService
หรือกลไกที่คล้ายกันสำหรับการตรวจหาคำสั่งให้ดำเนินการโดยไม่มีสัญญาณบอกสถานะการใช้งานไมค์ แอปพลิเคชันจะดำเนินการดังนี้
- [9.8/H-2-1] ต้องแจ้งให้ผู้ใช้ทราบอย่างชัดเจนสำหรับวลีคำสั่งให้ดำเนินการที่รองรับ
- [9.8/H-2-2] ต้องไม่เก็บข้อมูลดิบของเสียง หรือข้อมูลที่ได้มาจากบริการตรวจจับคำสั่งให้ดำเนินการ
- [9.8/H-2-3] ต้องไม่ส่งจากบริการตรวจจับคำสั่งให้ดำเนินการ ข้อมูลเสียง ข้อมูลที่นำมาใช้เพื่อสร้างเสียงใหม่ (บางส่วนหรือทั้งหมด) หรือเนื้อหาเสียงที่ไม่เกี่ยวข้องกับคำสั่งให้ดำเนินการได้ ยกเว้นใน
ContentCaptureService
หากการใช้งานอุปกรณ์พกพาประกาศเป็น android.hardware.microphone
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.8.2/H-4-1] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ใช่เมื่อมีการเข้าถึงไมโครโฟนโดย
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
หรือแอปที่มีบทบาทในส่วนที่ 9.1 ด้วยตัวระบุ CDD [C-4-X] เท่านั้น - [9.8.2/H-4-2] ต้องแสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่
โดยใช้ไมโครโฟนที่ส่งคืนจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมกับข้อความ ระบุแหล่งที่มาที่เกี่ยวข้อง
หากการใช้งานอุปกรณ์พกพาประกาศเป็น android.hardware.camera.any
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.8.2/H-5-1] ต้องแสดงสัญญาณบอกสถานะกล้องเมื่อแอป กำลังเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อกล้องเข้าถึงโดย แอปที่มีบทบาทในส่วนที่ 9.1 ด้วยตัวระบุ CDD [C-4-X] เท่านั้น
- [9.8.2/H-5-2] ต้องแสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ "กล้องถ่ายรูป" ที่ส่งคืนจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมด้วยข้อความระบุแหล่งที่มาที่เกี่ยวข้อง
2.2.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
การใช้งานอุปกรณ์เคลื่อนที่ (* ใช้ไม่ได้กับแท็บเล็ต):
- [6.1/H-0-1]* ต้องรองรับคำสั่ง Shell
cmd testharness
การใช้งานอุปกรณ์เคลื่อนที่ (* ใช้ไม่ได้กับแท็บเล็ต):
- Perfetto
- [6.1/H-0-2]* ต้องแสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/H-0-3]* ไบนารี Perfetto ต้องยอมรับเป็น ป้อนการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/H-0-4]* ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/H-0-5]* ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto ผ่าน Perfetto Binary
- [6.1/H-0-6]* ต้องเปิดใช้ Daemon ที่ติดตาม Perfetto โดยค่าเริ่มต้น (คุณสมบัติของระบบ
persist.traced.enable
)
- [6.1/H-0-2]* ต้องแสดงไบนารี
2.2.7 ชั้นเรียนประสิทธิภาพของสื่อแบบมือถือ
ดูส่วนที่ 7.11 สำหรับคำจำกัดความของคลาสประสิทธิภาพของสื่อ
2.2.7.1 สื่อ
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S
เป็นเวลา android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- ต้องเป็นไปตามข้อกำหนดเกี่ยวกับสื่อที่ระบุไว้ในส่วน 2.2.7.1 ของ Android 12
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.T
เป็นเวลา android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์
ที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่านเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30 FPS
- [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ที่เรียกใช้พร้อมกันได้ในชุดค่าผสมใดๆ ของตัวแปลงรหัสผ่านเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์และ
เซสชันโปรแกรมถอดรหัสที่เรียกใช้พร้อมกันในชุดค่าผสมใดๆ ของตัวแปลงรหัสผ่าน
เมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-6] ต้องรองรับตัวถอดรหัสวิดีโอฮาร์ดแวร์และเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/H-1-7] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอขนาด 1080p หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ทั้งหมด เมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียง 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองการเริ่มต้นของตัวแปลงต้องไม่เกิน 50 มิลลิวินาที
- [5.1/H-1-8] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสเสียงที่มีอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียง 1080p
- [5.1/H-1-9] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 2 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30 FPS
- [5.1/H-1-10] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ไม่ปลอดภัย 3 อินสแตนซ์ ร่วมกับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 1 อินสแตนซ์ (ทั้งหมด 4 อินสแตนซ์) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/ H-1-11] ต้องรองรับตัวถอดรหัสที่ปลอดภัยสำหรับฮาร์ดแวร์ AVC, HEVC, VP9 หรือตัวถอดรหัส AV1 ทั้งหมดในอุปกรณ์
- [5.1/H-1-12] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการถอดรหัสวิดีโอขนาด 1080p หรือต่ำกว่าสำหรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นเล่นวิดีโอเสียง 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองการเริ่มต้นของตัวแปลงรหัสต้องไม่เกิน 50 มิลลิวินาที
- [5.1/H-1-13] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการถอดรหัสเสียงที่มีอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับตัวถอดรหัสเสียงทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นเล่นเสียง-วิดีโอ 1080p
- [5.1/H-1-14] ต้องรองรับตัวถอดรหัสฮาร์ดแวร์ AV1 Main 10, ระดับ 4.1
- [5.1/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับฟิล์มเนื้อฟิล์มสำหรับตัวถอดรหัสฮาร์ดแวร์ AV1
- [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
- [5.1/H-1-16] ต้องมีโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อย่างน้อย 1 โปรแกรมที่รองรับ 4K60
- [5.3/H-1-1] ต้องไม่ตัดภาพเกิน 1 เฟรมใน 10 วินาที (เช่น การลดลงของเฟรมน้อยกว่า 0.167 เปอร์เซ็นต์) สำหรับเซสชันวิดีโอ 1080p 60 FPS ระหว่างการโหลด โหลดหมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC 128 kbps
- [5.3/H-1-2] ต้องไม่วางภาพลงมากกว่า 1 เฟรมใน 10 วินาทีระหว่างที่เปลี่ยนความละเอียดของวิดีโอในเซสชันวิดีโอ 60 FPS ในช่วงระหว่างโหลด การโหลดหมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC 128 kbps
- [5.6/H-1-1] ต้องมีเวลาในการตอบสนองของการแตะเพื่อโทนอยู่ที่ 80 มิลลิวินาทีหรือน้อยกว่า โดยใช้การทดสอบการแตะเพื่อโทนของ OboeTester หรือการทดสอบการแตะเพื่อโทนของ CTS Verifier
- [5.6/H-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับไม่เกิน 80 มิลลิวินาทีเมื่อเทียบกับเส้นทางข้อมูลที่รองรับอย่างน้อย 1 เส้นทาง
- [5.6/H-1-3] ต้องรองรับเสียง >=24 บิตสำหรับเอาต์พุตสเตอริโอผ่านช่องเสียบเสียง 3.5 มม.
หากมีและผ่านเสียง USB หากรองรับผ่าน
เส้นทางข้อมูลทั้งหมดสำหรับเวลาในการตอบสนองต่ำและการกำหนดค่าสตรีมมิง สำหรับการกำหนดค่าที่มีเวลาในการตอบสนองต่ำ แอปควรใช้ AAudio ในโหมด Callback ที่มีเวลาในการตอบสนองต่ำ แอปควรใช้ Java AudioTrack สำหรับการกำหนดค่าสตรีมมิง ทั้งสำหรับการกำหนดค่าสตรีมมิงและเวลาในการตอบสนองต่ำ ซิงก์เอาต์พุต HAL ควรยอมรับ
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
หรือAUDIO_FORMAT_PCM_FLOAT
สำหรับรูปแบบเอาต์พุตเป้าหมาย - [5.6/H-1-4] ต้องรองรับอุปกรณ์เสียง USB ที่มีช่องสัญญาณ >=4 ช่อง (ตัวควบคุมของดีเจจะใช้สำหรับการแสดงตัวอย่างเพลง)
- [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่เป็นไปตามคลาสและประกาศแฟล็กฟีเจอร์ MIDI
- [5.7/H-1-2] ต้องรองรับ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
ที่มีความสามารถในการถอดรหัสเนื้อหาด้านล่าง
ขนาดการสุ่มตัวอย่างขั้นต่ำ | 4 MiB |
จำนวนตัวอย่างย่อยขั้นต่ำ - H264 หรือ HEVC | 28 |
จำนวนตัวอย่างย่อยขั้นต่ำ - VP9 | 9 |
จำนวนตัวอย่างย่อยขั้นต่ำ - AV1 | 288 |
ขนาดบัฟเฟอร์ของตัวอย่างย่อยขั้นต่ำ | 1 MiB |
ขนาดบัฟเฟอร์คริปโตทั่วไปขั้นต่ำ | 500 KiB |
จํานวนเซสชันที่เกิดขึ้นพร้อมกันขั้นต่ำ | 30 |
จำนวนคีย์ขั้นต่ำต่อเซสชัน | 20 |
จำนวนคีย์ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) | 80 |
จำนวนคีย์ DRM ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) | 6 |
ขนาดข้อความ | 16 KiB |
เฟรมที่ถอดรหัสต่อวินาที | 60 FPS |
2.2.7.2 กล้อง
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S
เป็นเวลา android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- ต้องเป็นไปตามข้อกำหนดของกล้องที่ระบุไว้ในหัวข้อ 2.2.7.2 ของ Android 12 CDD
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.T
เป็นเวลา android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- [7.5/H-1-1] ต้องมีกล้องหลังตัวหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล ซึ่งรองรับการจับภาพวิดีโอที่ 4k@30fps กล้องหลังตัวหลักคือกล้องหลังที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 5 ล้านพิกเซล และรองรับการบันทึกวิดีโอที่ 1080p@30fps กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้
android.info.supportedHardwareLevel
เป็นFULL
หรือดีกว่าสำหรับกล้องหลักด้านหลัง และLIMITED
หรือดีกว่าสำหรับกล้องหลักหน้า - [7.5/H-1-4] ต้องรองรับ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
สำหรับกล้องหลักทั้ง 2 ตัว - [7.5/H-1-5] ต้องมีเวลาในการตอบสนองในการจับภาพ Camera2 JPEG < 1,000 มิลลิวินาทีสำหรับความละเอียด 1080p ตามที่วัดโดยการทดสอบประสิทธิภาพของกล้อง CTS ภายใต้สภาพแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูเฟรมตัวอย่างแรก) < 500 มิลลิวินาทีที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-8] ต้องรองรับ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
และandroid.graphics.ImageFormat.RAW_SENSOR
สำหรับกล้องหลังหลัก - [7.5/H-1-9] ต้องมีกล้องหลักที่ด้านหลังที่รองรับ 720p หรือ 1080p @ 240fps
- [7.5/H-1-10] ต้องมีค่าขั้นต่ำ ZOOM_RATIO < 1.0 สำหรับกล้องหลักหากมีกล้อง RGB มุมกว้างพิเศษที่หันไปในทิศทางเดียวกัน
- [7.5/H-1-11] ต้องใช้การสตรีมหน้าหลังพร้อมกันในกล้องหลัก
- [7.5/H-1-12] ต้องรองรับ
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
สำหรับกล้องหลังหลัก - [7.5/H-1-13] ต้องรองรับความสามารถของ
LOGICAL_MULTI_CAMERA
สำหรับกล้องหลังหลักหากมีกล้องหลัง RGB มากกว่า 1 ตัว - [7.5/H-1-14] ต้องรองรับความสามารถของ
STREAM_USE_CASE
ทั้งสำหรับกล้องหน้าและกล้องหลังหลัก
2.2.7.3 ฮาร์ดแวร์
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- ต้องเป็นไปตามข้อกำหนดเกี่ยวกับฮาร์ดแวร์ที่ระบุไว้ในส่วน 2.2.7.3 ของ Android 12
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.T
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
- [7.1.1.3/H-2-1] ต้องมีความหนาแน่นของหน้าจออย่างน้อย 400 dpi
- [7.6.1/H-2-1] ต้องมีหน่วยความจำจริงอย่างน้อย 8 GB
2.2.7.4 ประสิทธิภาพ
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพที่ระบุไว้ในส่วน 2.2.7.4 ของ Android 12
หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.T
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้
- [8.2/H-1-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 125 MB/วินาที
- [8.2/H-1-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/วินาที
- [8.2/H-1-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 250 MB/วินาที
- [8.2/H-1-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 40 MB/วินาที
2.3 ข้อกำหนดสำหรับโทรทัศน์
อุปกรณ์ทีวี Android หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสำหรับการบริโภคสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสำหรับผู้ใช้ที่อยู่ห่างออกไปประมาณ 10 ฟุต ("อินเทอร์เฟซผู้ใช้หลังเอนหลัง" หรือ "อินเทอร์เฟซผู้ใช้ 10 ฟุต")
การใช้งานอุปกรณ์ Android จัดเป็นทีวีหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีกลไกในการควบคุมอินเทอร์เฟซผู้ใช้ที่แสดงผลจากระยะไกลบนจอแสดงผลที่สามารถอยู่ห่างจากผู้ใช้ 10 ฟุต
- มีจอแสดงผลแบบฝังที่มีความยาวแนวทแยงมากกว่า 24 นิ้ว หรือใส่พอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI, DisplayPort หรือพอร์ตไร้สายสำหรับจอแสดงผล
ข้อกำหนดเพิ่มเติมในส่วนอื่นของส่วนนี้มีไว้สำหรับการใช้งานอุปกรณ์ทีวี Android เท่านั้น
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] ต้องรวมการรองรับตัวควบคุมเกมและประกาศ Flag ฟีเจอร์
android.hardware.gamepad
- [7.2.7/T] ควรมีรีโมตคอนโทรลที่ผู้ใช้สามารถเข้าถึงอินพุตการนำทางแบบไม่สัมผัสและแป้นนำทางหลัก
หากการใช้งานอุปกรณ์โทรทัศน์มีเครื่องวัดการหมุน 3 แกน การใช้งานจะดำเนินการดังนี้
- [7.3.4/T-1-1] ต้องรายงานเหตุการณ์สูงสุดได้อย่างน้อย 100 Hz
- [7.3.4/T-1-2] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไป ได้สูงสุด 1,000 องศาต่อวินาที
การติดตั้งใช้งานอุปกรณ์ทีวี
- [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-1] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส 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-0-6] MPEG-2
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส MPEG-2 ตามที่อธิบายไว้ในส่วนที่ 5.3.1 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.1/T-1-1] HD 1080p ที่ 29.97 เฟรมต่อวินาที สำหรับโปรไฟล์หลักระดับสูง
- [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาที และมีโปรไฟล์หลักระดับสูง วิดีโอ MPEG-2 ที่มีการสอดประสานและ ให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส H.264 ตามที่อธิบายไว้ในส่วนที่ 5.3.4 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาที ด้วยโปรไฟล์พื้นฐาน
- [5.3.4/T-1-2] HD 1080p ที่ 60 ภาพต่อวินาทีด้วย โปรไฟล์หลัก
- [5.3.4/T-1-3] HD 1080p ที่ 60 เฟรมต่อวินาที ด้วย High Profile ระดับ 4.2
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 ต้องรองรับการถอดรหัส H.265 ตามที่อธิบายไว้ในส่วน 5.3.5 ที่อัตราเฟรมวิดีโอมาตรฐานและความละเอียดสูงสุด รวมถึงรายการต่อไปนี้
- [5.3.5/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาที ด้วยโปรไฟล์หลักระดับ 4.1
หากอุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 รองรับการถอดรหัส H.265 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ Main Tier หลัก 10 ระดับ 5
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส VP8 ตามรายละเอียดในส่วนที่ 5.3.6 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและดังต่อไปนี้
- [5.3.6/T-1-1] โปรไฟล์การถอดรหัสแบบ HD 1080p ที่ 60 เฟรมต่อวินาที
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 ต้องรองรับการถอดรหัส VP9 ตามที่อธิบายไว้ในส่วน 5.3.7 ที่อัตราเฟรมวิดีโอมาตรฐานและความละเอียดสูงสุด รวมถึง
- [5.3.7/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาที พร้อมโปรไฟล์ 0 (ความลึกของสี 8 บิต)
หากอุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 รองรับการถอดรหัส VP9 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.7/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 0 (ความลึกของสี 8 บิต)
- [5.3.7/T-SR1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัสแบบ UHD ที่ความเร็ว 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.5/T-0-1] ต้องมีการรองรับระดับเสียงหลักของระบบและการลดระดับเสียงเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตส่งผ่านเสียงบีบอัด (ที่ไม่มีการถอดรหัสเสียงในอุปกรณ์)
หากการใช้อุปกรณ์โทรทัศน์ไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน อุปกรณ์เหล่านั้นจะมีผลดังนี้
- [5.8/T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI ให้เลือกความละเอียดสูงสุดที่รองรับอัตราการรีเฟรช 50 Hz หรือ 60 Hz
- [5.8/T-SR-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกอัตราการรีเฟรช HDMI ที่กำหนดค่าโดยผู้ใช้
- [5.8] ควรตั้งค่าอัตราการรีเฟรชโหมดเอาต์พุต HDMI เป็น 50 Hz หรือ 60 Hz ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอสําหรับภูมิภาคที่ขายอุปกรณ์
หากการใช้อุปกรณ์โทรทัศน์ไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน อุปกรณ์เหล่านั้นจะมีผลดังนี้
- [5.8/T-1-1] ต้องรองรับ HDCP 2.2
หากอุปกรณ์ทีวีไม่รองรับการถอดรหัส UHD แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน
- [5.8/T-2-1] ต้องรองรับ HDCP 1.4
2.3.3 ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3/T-0-1] ต้องประกาศฟีเจอร์
android.software.leanback
และandroid.hardware.type.television
- [3.2.3.1/T-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
- [3.4.1/T-0-1] ต้องมีการติดตั้งใช้งาน API ของ
android.webkit.Webview
ให้เสร็จสมบูรณ์
หากใช้งานอุปกรณ์ Android TV รองรับหน้าจอล็อก สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.10/T-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.8.14/T-SR-1] ขอแนะนำอย่างยิ่ง ให้รองรับหลายหน้าต่างในโหมดการแสดงภาพซ้อนภาพ (PIP)
- [3.10/T-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/T-SR-1] ขอแนะนำเป็นอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับในเครื่องมือการอ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
หากการใช้งานอุปกรณ์ทีวีรายงานฟีเจอร์ android.hardware.audio.output
ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [3.11/T-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ 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] ต้องลงทะเบียนอุปกรณ์เป็นอุปกรณ์แบบไม่ใช้แบตเตอรี่ตามที่อธิบายไว้ในหัวข้อการรองรับอุปกรณ์แบบใช้แบตเตอรี่
สิ่งที่จะเกิดขึ้นหากการใช้งานอุปกรณ์ทีวีมีแบตเตอรี่มีดังนี้
- [8.3/T-1-3] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ 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.3.5 โมเดลการรักษาความปลอดภัย
การติดตั้งใช้งานอุปกรณ์ทีวี
- [9.11/T-0-1] ต้องสำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/T-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชตระกูล MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและสูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/T-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/T-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
- [9/T-0-1] ต้องประกาศฟีเจอร์ "android.hardware.security.model.compatible"
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
หากการใช้งานอุปกรณ์ทีวีรองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.11/T-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปเพื่อเปลี่ยนจากสถานะปลดล็อกไปเป็นล็อกอยู่ โดยมีระยะหมดเวลาขั้นต่ำที่ไม่เกิน 15 วินาที
หากการใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายราย และไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่ถูกจำกัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็วเพื่อให้ผู้ใช้คนอื่นๆ ทำงานได้ พร้อมกับจัดการข้อจำกัดอย่างละเอียดในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายราย และประกาศแฟล็กฟีเจอร์ android.hardware.telephony
ผู้ใช้จะมีลักษณะดังนี้
- [9.5/T-3-1] ต้องไม่รองรับโปรไฟล์ที่ถูกจำกัด แต่ต้องสอดคล้องกับการใช้การควบคุมของ AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
หากการใช้งานอุปกรณ์ทีวีประกาศ android.hardware.microphone
ค่าจะมีลักษณะดังนี้
- [9.8.2/T-4-1] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ใช่เมื่อเข้าถึงไมโครโฟนโดย HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทในข้อ 9.1 สิทธิ์ที่มีตัวระบุ C-3-X] เท่านั้น
- [9.8.2/T-4-2] ต้องไม่ซ่อนสัญญาณบอกสถานะไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้ หรือการโต้ตอบของผู้ใช้โดยตรง
หากการใช้งานอุปกรณ์ทีวีประกาศ android.hardware.camera.any
ค่าจะมีลักษณะดังนี้
- [9.8.2/T-5-1] ต้องแสดงสัญญาณบอกสถานะกล้องเมื่อแอป กำลังเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อแอป เข้าถึงกล้องซึ่งมีบทบาทที่เรียกใช้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X]
- [9.8.2/T-5-2] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้ หรือการโต้ตอบของผู้ใช้โดยตรง
2.3.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
การติดตั้งใช้งานอุปกรณ์ทีวี
- Perfetto
- [6.1/T-0-1] ต้องแสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/T-0-2] ไบนารี Perfetto ต้องยอมรับเป็น ป้อนการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/T-0-3] ไบนารีของ Perfetto ต้องเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/T-0-4] ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบ Perfetto ผ่าน Perfetto Binary
- [6.1/T-0-1] ต้องแสดงไบนารี
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-1] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการใช้งานอุปกรณ์นาฬิกามีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
รายการต่อไปนี้
- [7.3.3/W-1-1] ต้องรายงานการวัด GNSS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [7.3.3/W-1-2] ต้องรายงานอัตรา Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีในกำลังสอง เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 9% ต่อวินาทีอย่างน้อย 1 วินาที
หากการใช้งานอุปกรณ์นาฬิกามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/W-2-1] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไป ได้สูงสุด 1,000 องศาต่อวินาที
ดูการติดตั้งใช้งานอุปกรณ์
[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.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยจุดประสงค์ของแอปพลิเคชันต่อไปนี้ที่แสดงที่นี่
ดูการติดตั้งใช้งานอุปกรณ์
- [3.8.4/W-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ใช้ผู้ช่วยบนอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
ดูการใช้งานอุปกรณ์ที่ประกาศ Flag ฟีเจอร์ android.hardware.audio.output
- [3.10/W-1-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/W-SR-1] ขอแนะนำอย่างยิ่งให้โหลดบริการการเข้าถึงล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับในเครื่องมืออ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
หากการใช้งานอุปกรณ์นาฬิการายงานฟีเจอร์ android.hardware.audio.output ระบบจะดำเนินการต่อไปนี้
[3.11/W-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
[3.11/W-0-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
2.4.4 ประสิทธิภาพและศักยภาพ
หากการใช้งานอุปกรณ์นาฬิกามีฟีเจอร์ในการปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ต่างๆ ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/W-SR-1] ขอแนะนำเป็นอย่างยิ่งให้เพิ่มเงินให้ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
- [8.3/W-SR-2] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้สามารถเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
ดูการติดตั้งใช้งานอุปกรณ์
- [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.4.5 โมเดลการรักษาความปลอดภัย
ดูการติดตั้งใช้งานอุปกรณ์
- [9/W-0-1] ต้องประกาศฟีเจอร์
android.hardware.security.model.compatible
หากการใช้งานอุปกรณ์นาฬิกามีผู้ใช้หลายราย และไม่ประกาศแฟล็กฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/W-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่ถูกจำกัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็วเพื่อให้ผู้ใช้คนอื่นๆ ทำงานได้ พร้อมกับจัดการข้อจำกัดอย่างละเอียดในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์เฝ้าดูมีผู้ใช้หลายคนและประกาศแฟล็กฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/W-2-1] ต้องไม่รองรับโปรไฟล์ที่ถูกจำกัด แต่ต้องสอดคล้องกับการใช้การควบคุมของ AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
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] ต้องระบุฟังก์ชัน "หน้าแรก" และอาจ มีฟังก์ชัน "กลับ" และ "ล่าสุด"
[7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์ปกติและเหตุการณ์การกดค้างของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า[7.3/A-0-1] ต้องใช้และรายงาน
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
และPARKING_BRAKE_ON
[7.3/A-0-2] ค่าของการแจ้ง
NIGHT_MODE
ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตเซ็นเซอร์แสงแวดล้อม เซ็นเซอร์แสงแวดล้อมที่อยู่ข้างใต้อาจเหมือนกับ Photometer[7.3/A-0-3] ต้องให้ช่องข้อมูลเพิ่มเติมของเซ็นเซอร์
TYPE_SENSOR_PLACEMENT
เป็นส่วนหนึ่งของ SensorAdditionalInfo สำหรับทุกเซ็นเซอร์ที่ให้[7.3/A-SR1] อาจสูญเสียตำแหน่ง โดยการรวม GPS/GNSS กับเซ็นเซอร์เพิ่มเติม หากยกเลิกตำแหน่งแล้ว เราขอแนะนำเป็นอย่างยิ่งให้ใช้และรายงานประเภทเซ็นเซอร์และ/หรือรหัสอสังหาริมทรัพย์ของยานพาหนะที่เกี่ยวข้อง
[7.3/A-0-4] สถานที่ตั้ง ที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่ใช่แผนที่ที่ตรงกัน
[7.3.1/A-0-4] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของรถ Android
[7.3/A-SR-1] STRONGLY_RECOMMENDED รวมตัวตรวจวัดความเร่ง 3 แกนและเครื่องวัดการหมุน 3 แกน
[7.3/A-SR-2] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_HEADING
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับ OpenGL ES 3.1
- [7.1.4.1/A-0-1] ต้องประกาศ OpenGL ES 3.1 ขึ้นไป
- [7.1.4.1/A-0-2] ต้องรองรับ Vulkan 1.1
- [7.1.4.1/A-0-3] ต้องมีตัวโหลด Vulkan และส่งออกสัญลักษณ์ทั้งหมด
หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่ง สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/A-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/A-SR-1] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับตัวตรวจวัดความเร่งที่มีแกนจำกัด
หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่งที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [7.3.1/A-1-3] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES
- [7.3.1/A-1-4] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
หากการใช้งานอุปกรณ์ยานยนต์รวมถึงเครื่องวัดการหมุน จะมีการดำเนินการดังนี้
- [7.3.4/A-2-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
- [7.3.4/A-2-3] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไป ได้สูงสุด 250 องศาต่อวินาที
- [7.3.4/A-SR-1] ขอแนะนำอย่างยิ่งให้กำหนดค่าช่วงการวัดของอุปกรณ์วัดการหมุนเป็น +/-250dps เพื่อให้ได้ความละเอียดสูงสุดที่เป็นไปได้
หากอุปกรณ์ยานยนต์มีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/A-SR-2] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับเครื่องวัดการหมุนที่มีแกนจำกัด
หากการใช้งานอุปกรณ์ยานยนต์มีเครื่องวัดการหมุนที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [7.3.4/A-4-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES
- [7.3.4/A-4-2] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
หากการใช้งานอุปกรณ์ Automotive มีตัวรับสัญญาณ GPS/GNSS แต่ไม่ได้รวมการเชื่อมต่ออินเทอร์เน็ตผ่านเครือข่ายมือถือ อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [7.3.3/A-3-1] ต้องระบุตำแหน่งในครั้งแรกที่ตัวรับสัญญาณ GPS/GNSS เปิดอยู่ หรือหลังจากผ่านไป 4 วันขึ้นไปภายใน 60 วินาที
- [7.3.3/A-3-2] ต้องเป็นไปตามเกณฑ์กำหนดเวลาเพื่อแก้ไขครั้งแรกตามที่อธิบายไว้ใน 7.3.3/C-1-2 และ 7.3.3/C-1-6 สำหรับคำขอตำแหน่งอื่นๆ ทั้งหมด (คำขอที่ไม่ใช่ครั้งแรกหรือหลังผ่านไป 4 วันขึ้นไป) โดยทั่วไปแล้ว ข้อกำหนด 7.3.3/C-1-2 จะ เกิดขึ้นในรถที่ไม่มีการเชื่อมต่ออินเทอร์เน็ตผ่านเครือข่ายมือถือ โดยใช้การคาดการณ์วงโคจรของ GNSS ที่คำนวณบนเครื่องรับ หรือใช้ ตำแหน่งรถที่ทราบล่าสุดควบคู่กับความสามารถในการตกแท่นนานอย่างน้อย 60 วินาทีโดยมีความแม่นยำของตำแหน่งตรงตาม 7.3.3/C-1-3 หรือทั้ง 2 อย่างร่วมกัน
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเซ็นเซอร์ TYPE_HEADING
สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/A-4-3] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 1 Hz
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED เพื่อรายงานเหตุการณ์ด้วยความถี่อย่างน้อย 10 Hz
- ควรอ้างอิงถึงทิศเหนือจริง
- ควรพร้อมใช้งานแม้ในขณะที่ยานพาหนะยังอยู่
- ควรมีความละเอียดอย่างน้อย 1 องศา
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [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-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้าถึงข้อความ (MAP)
[7.4.5/A] ควรมีการสนับสนุนสำหรับการเชื่อมต่อข้อมูล ตามเครือข่ายมือถือ
[7.4.5/A] อาจใช้ค่าคงที่ System API
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
สำหรับเครือข่ายที่ควรใช้กับแอประบบได้
กล้องมุมมองภายนอกคือกล้องที่ใช้ถ่ายภาพฉากนอกเหนือการใช้งานอุปกรณ์ เช่น กล้องมองหลัง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- ควรมีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภายนอกสำหรับกล้องดังกล่าว สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.5/A-1-1] ต้องไม่มีกล้องมุมมองภายนอกที่เข้าถึงได้ผ่าน Android Camera API เว้นแต่ว่าจะเป็นไปตามข้อกำหนดหลักของกล้อง
[7.5/A-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าหมุนหรือมิเรอร์ภาพตัวอย่างจากกล้อง
[7.5/A-SR-2] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 เมกะพิกเซล
ควรมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
อาจมีการใช้ฮาร์ดแวร์โฟกัสอัตโนมัติหรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว และโหลดบริการระบบมุมมองภายนอก (EVS) กล้องจะทำหน้าที่ดังนี้
- [7.5/A-2-1] ต้องไม่หมุนหรือมิเรอร์ในแนวนอนของตัวอย่างกล้อง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- อาจมีกล้องอย่างน้อย 1 ตัวที่พร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม
หากการติดตั้งใช้งานอุปกรณ์ในรถยนต์มีกล้องอย่างน้อย 1 ตัว และใช้กับแอปพลิเคชันของบุคคลที่สามได้ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.5/A-3-1] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.camera.any
- [7.5/A-3-2] ต้องไม่ประกาศว่ากล้องเป็นกล้องของระบบ
- อาจรองรับกล้องภายนอกที่อธิบายไว้ในหัวข้อ 7.5.3
- อาจมีฟีเจอร์ (เช่น การโฟกัสอัตโนมัติ ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
[7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
[7.6.1/A] ควรจัดรูปแบบพาร์ติชันข้อมูล เพื่อเพิ่มประสิทธิภาพและอายุใช้งานของพื้นที่เก็บข้อมูล Flash เช่น ใช้ระบบไฟล์
f2fs
หากการติดตั้งใช้งานอุปกรณ์ Automotive มีพื้นที่เก็บข้อมูลภายนอกที่แชร์ผ่านส่วนหนึ่งของพื้นที่เก็บข้อมูลภายในแบบถอดไม่ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/A-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ลดโอเวอร์เฮดของ I/O ในการดำเนินการกับพื้นที่เก็บข้อมูลภายนอก เช่น โดยใช้
SDCardFS
หากใช้อุปกรณ์ 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)
การใช้งานอุปกรณ์ในรถยนต์ต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และทำให้รูปแบบดังกล่าวพร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม
การใช้งานอุปกรณ์ในรถยนต์ต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และทำให้รูปแบบดังกล่าวพร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ในรถยนต์เพื่อรองรับการถอดรหัสวิดีโอต่อไปนี้
- [5.3/A-SR-1] 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.*
เนมสเปซ
หากการติดตั้งใช้งานอุปกรณ์ Automotive มี API ที่เป็นกรรมสิทธิ์โดยใช้ android.car.CarPropertyManager
ร่วมกับ android.car.VehiclePropertyIds
สิ่งที่จะเกิดขึ้นมีดังนี้
- [3/A-1-1] ต้องไม่แนบสิทธิ์พิเศษกับการใช้พร็อพเพอร์ตี้เหล่านี้ของแอปพลิเคชันของระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามใช้พร็อพเพอร์ตี้เหล่านี้
- [3/A-1-2] ต้องไม่จำลองพร็อพเพอร์ตี้ยานพาหนะที่มีอยู่ใน SDK อยู่แล้ว
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
[3.2.1/A-0-1] ต้องรองรับและบังคับใช้ค่าคงที่ของสิทธิ์ทั้งหมดตามที่บันทึกไว้ในหน้าข้อมูลอ้างอิงสิทธิ์ใช้งานยานยนต์
[3.2.3.1/A-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
[3.4.1/A-0-1] ต้องมีการติดตั้งใช้งาน API ของ
android.webkit.Webview
ให้เสร็จสมบูรณ์[3.8.3/A-0-1] ต้องแสดงการแจ้งเตือนที่ใช้
Notification.CarExtender
API เมื่อแอปพลิเคชันของบุคคลที่สามขอ[3.8.4/A-SR-1] ขอแนะนำอย่างยิ่ง ให้ใช้ผู้ช่วยบนอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
หากการใช้งานอุปกรณ์ยานยนต์มีปุ่มกดเพื่อพูด ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [3.8.4/A-1-1] ต้องใช้การกดปุ่ม Push-to-Talk สั้นๆ เป็นการโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยที่ผู้ใช้เลือก ซึ่งก็คือแอปที่ใช้งาน
VoiceInteractionService
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.8.3.1/A-0-1] ต้องแสดงทรัพยากรอย่างถูกต้องตามที่อธิบายไว้ในเอกสารประกอบ SDK ของ
Notifications on Automotive OS
- [3.8.3.1/A-0-2] ต้องแสดง "เล่น" และ "ปิดเสียง" สำหรับการดำเนินการแจ้งเตือนแทนการดำเนินการที่ดำเนินการผ่าน
Notification.Builder.addAction()
- [3.8.3.1/A] ควรจำกัดการใช้งานงานการจัดการแบบสมบูรณ์ เช่น การควบคุมต่อการแจ้งเตือน-ช่องทาง อาจใช้ความสามารถของ UI ต่อแอปพลิเคชันเพื่อลดการควบคุม
หากการติดตั้งใช้งานอุปกรณ์ในรถยนต์รองรับพร็อพเพอร์ตี้ HAL ของผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9.3/A-1-1] ต้องใช้
พร็อพเพอร์ตี้วงจรของผู้ใช้ทั้งหมด
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.14/A-0-1] ต้องระบุเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วน 3.14
- [3.14/A-0-2] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับแอปพลิเคชันสื่อได้อย่างปลอดภัยขณะขับรถ
- [3.14/A-0-3] ต้องรองรับการดำเนินการ Intent แบบไม่เจาะจงปลายทาง
CAR_INTENT_ACTION_MEDIA_TEMPLATE
ด้วยส่วนเสริมCAR_EXTRA_MEDIA_PACKAGE
- [3.14/A-0-4] ต้องให้เงินช่วยเหลือในการไปยังกิจกรรมที่ต้องการของแอปพลิเคชันสื่อ แต่ต้องเปิดใช้เฉพาะเมื่อข้อจำกัด UX ของรถยนต์ไม่มีผล
- [3.14/A-0-5] ต้องแสดงข้อความแสดงข้อผิดพลาดที่ตั้งค่าโดยแอปพลิเคชันสื่อ และต้องรองรับส่วนเพิ่มเติมที่ไม่บังคับ
ERROR_RESOLUTION_ACTION_LABEL
และERROR_RESOLUTION_ACTION_INTENT
- [3.14/A-0-6] ต้องรองรับราคาในการค้นหาในแอปสำหรับแอปที่รองรับการค้นหา
- [3.14/A-0-7] ต้องเป็นไปตามคำจำกัดความ
CONTENT_STYLE_BROWSABLE_HINT
และCONTENT_STYLE_PLAYABLE_HINT
เมื่อแสดงลำดับชั้น MediaBrowser
หากการติดตั้งใช้งานอุปกรณ์ Automotive มีแอป Launcher เริ่มต้น ระบบจะดำเนินการต่อไปนี้
- [3.14/A-1-1] ต้องระบุบริการสื่อและเปิดด้วยความตั้งใจ
CAR_INTENT_ACTION_MEDIA_TEMPLATE
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.8/A] อาจจำกัดคำขอของแอปพลิเคชันให้เข้าสู่โหมดเต็มหน้าจอตามที่อธิบายไว้ใน
immersive documentation
- [3.8/A] อาจทำให้แถบสถานะและ แถบนำทางมองเห็นได้ตลอดเวลา
- [3.8/A] อาจจำกัดให้แอปพลิเคชันเปลี่ยนสีด้านหลังองค์ประกอบ UI ของระบบเพื่อให้แน่ใจว่ามองเห็นองค์ประกอบเหล่านั้นได้อย่างชัดเจนตลอดเวลา
2.5.4 ประสิทธิภาพและศักยภาพ
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [8.2/A-0-1] ต้องรายงานจำนวนไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลที่ไม่ผันผวนต่อ UID ของกระบวนการแต่ละรายการเพื่อให้นักพัฒนาซอฟต์แวร์เข้าถึงสถิติได้ผ่าน System API
android.car.storagemonitoring.CarStorageMonitoringManager
โปรเจ็กต์โอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของuid_sys_stats
- [8.3/A-1-3] ต้องรองรับโหมดโรงรถ
- [8.3/A] ควรอยู่ในโหมดโรงรถอย่างน้อย 15 นาทีหลังการขับรถทุกครั้ง ยกเว้นในกรณีต่อไปนี้
- แบตเตอรี่หมด
- ไม่มีกำหนดเวลางานที่ไม่มีการใช้งาน
- คนขับออกจากโหมด Garage
- [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.5/A-1-2] ต้องเปลี่ยนเป็นผู้ใช้รอง
ก่อนวันที่
BOOT_COMPLETED
- [9.5/A-1-3] ต้องรองรับความสามารถในการสร้างผู้ใช้ที่เป็นผู้มาเยือน แม้ว่าอุปกรณ์จะมีผู้ใช้ถึงจำนวนสูงสุดแล้ว
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศ android.hardware.camera.any
สิ่งต่อไปนี้
- [9.8.2/A-2-1] ต้องแสดงสัญญาณบอกสถานะกล้องเมื่อแอป กำลังเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อกล้อง เข้าถึงกล้องเท่านั้น โดยแอปที่มีบทบาทดังที่กล่าวไว้ใน ส่วนที่ 9.1 สิทธิ์ ที่มีตัวระบุ CDD [C-3-X]
- [9.8.2/A-2-2] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้ หรือการโต้ตอบของผู้ใช้โดยตรง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [9.11/A-0-1] ต้องสำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/A-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/A-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/A-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
- [9/A-0-1] ต้องประกาศฟีเจอร์ "android.hardware.security.model.compatible"
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [9.14/A-0-1] ต้องระบุข้อความเฝ้าระวังจากระบบย่อยของยานพาหนะที่ใช้เฟรมเวิร์ก Android เช่น การอนุญาตประเภทข้อความที่อนุญาตและแหล่งที่มาของข้อความ
- [9.14/A-0-2] ต้องเฝ้าระวังการโจมตีแบบปฏิเสธการให้บริการจากเฟรมเวิร์ก Android หรือแอปของบุคคลที่สาม การดำเนินการนี้จะป้องกันซอฟต์แวร์ที่เป็นอันตรายไม่ให้การจราจรคับคั่งอยู่ในเครือข่ายของรถ ซึ่งอาจนำไปสู่ระบบย่อยของยานพาหนะที่ขัดข้องได้
2.5.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- Perfetto
- [6.1/A-0-1] ต้องแสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/A-0-2] ไบนารี Perfetto ต้องยอมรับเป็นอินพุตการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/A-0-3] ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตการติดตาม protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/A-0-4] ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบ Perfetto ผ่านทาง Perfetto Binary
- [6.1/A-0-1] ต้องแสดงไบนารี
2.6 ข้อกำหนดสำหรับแท็บเล็ต
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่โดยทั่วไปจะเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- ใช้โดยถือไว้ในมือทั้ง 2 ข้าง
- ไม่มีการกำหนดค่าแบบฝาพับหรือแบบพับจอได้
- การใช้แป้นพิมพ์จริงที่ใช้กับอุปกรณ์เชื่อมต่อโดยใช้วิธีการเชื่อมต่อมาตรฐาน (เช่น USB, บลูทูธ)
- มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- มีขนาดการแสดงผลของหน้าจอใหญ่กว่า 7 นิ้วและน้อยกว่า 18 นิ้ว โดยวัดในแนวทแยง
การใช้งานอุปกรณ์แท็บเล็ตมีข้อกำหนดที่คล้ายกับการใช้งานอุปกรณ์เคลื่อนที่ ข้อยกเว้นต่างๆ จะกำกับด้วยเครื่องหมาย * ในหัวข้อดังกล่าวและมีหมายเหตุไว้เพื่อใช้อ้างอิงในส่วนนี้
2.6.1 ฮาร์ดแวร์
เครื่องวัดการหมุน
หากอุปกรณ์แท็บเล็ตมีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/Tab-1-1] ต้องมีความสามารถในการวัดการวางแนว ที่เปลี่ยนไปได้ถึง 1,000 องศาต่อวินาที
หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ (ส่วนที่ 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 ใช้ไม่ได้กับแท็บเล็ต
2.6.2 โมเดลการรักษาความปลอดภัย
คีย์และข้อมูลเข้าสู่ระบบ (ส่วนที่ 9.11)
โปรดดูหัวข้อ [9.11]
หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายราย และไม่ประกาศแฟล็กฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่ถูกจำกัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็วเพื่อให้ผู้ใช้คนอื่นๆ ทำงานได้ พร้อมกับจัดการข้อจำกัดอย่างละเอียดในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและประกาศแฟล็กฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-2-1] ต้องไม่รองรับโปรไฟล์ที่ถูกจำกัด แต่ต้องสอดคล้องกับการใช้การควบคุมของ AOSP เพื่อเปิด /ปิดไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
2.6.2 ซอฟต์แวร์
- [3.2.3.1/Tab-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
3. ซอฟต์แวร์
3.1 ความเข้ากันได้กับ API ที่มีการจัดการ
สภาพแวดล้อมการดำเนินการแบบไบต์โค้ด Dalvik ที่มีการจัดการเป็นพาหนะหลักสำหรับแอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยแก่แอปพลิเคชันที่ทำงานในสภาพแวดล้อมรันไทม์ที่มีการจัดการ
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องมีการติดตั้งใช้งานที่สมบูรณ์ รวมถึงลักษณะการทำงานที่บันทึกไว้ทั้งหมดของ API ที่บันทึกไว้ใน Android SDK หรือ API ใดๆ ที่ตกแต่งด้วยเครื่องหมาย “@SystemApi” ในซอร์สโค้ดอัปสตรีม Android
[C-0-2] ต้อง support/รักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมดที่ทำเครื่องหมายโดยคำอธิบายประกอบ TestApi (@TestApi)
[C-0-3] ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็นของ API เบี่ยงเบนไปจากลักษณะการทำงานที่บันทึกไว้ หรือละเว้น เว้นแต่ได้รับอนุญาตเป็นการเฉพาะโดยคำจำกัดความความเข้ากันได้นี้
[C-0-4] ต้องคง API ไว้และทํางานในลักษณะที่เหมาะสม แม้ว่าจะละเว้นฟีเจอร์ของฮาร์ดแวร์บางอย่างที่ Android มี API ก็ตาม โปรดดูส่วนที่ 7 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้
[C-0-5] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK ซึ่ง มีการกำหนดว่าเป็นเมธอดและช่องในแพ็กเกจภาษา Java ที่อยู่ใน คลาสการเปิดเครื่องใน AOSP และไม่ได้เป็นส่วนหนึ่งของ SDK สาธารณะ ซึ่งรวมถึง API ที่ตกแต่งด้วยคำอธิบายประกอบ
@hide
แต่ไม่มี@SystemAPI
ตามที่อธิบายไว้ในเอกสาร SDK และสมาชิกคลาสแบบส่วนตัวและแพ็กเกจส่วนตัว[C-0-6] ต้องจัดส่งมาพร้อมกับอินเทอร์เฟซที่ไม่ใช่ SDK แต่ละรายการในรายการแบบจำกัดเดียวกันกับที่ระบุผ่านแฟล็กชั่วคราวและรายการที่ปฏิเสธในเส้นทาง
prebuilts/runtime/appcompat/hiddenapi-flags.csv
สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP[C-0-7] ต้องรองรับกลไกการอัปเดตแบบไดนามิกของการกำหนดค่าที่ลงนามเพื่อนำอินเทอร์เฟซที่ไม่ใช่ SDK ออกจากรายการที่ถูกจำกัด โดยการฝังการกำหนดค่าที่ลงนามใน APK ใดก็ตามโดยใช้คีย์สาธารณะที่มีอยู่ ที่มีอยู่ใน AOSP
อย่างไรก็ตาม
- อาจหากไม่มี API ที่ซ่อนไว้หรือมีการใช้งานที่แตกต่างออกไปในการใช้งานอุปกรณ์ ให้ย้าย API ที่ซ่อนไว้ไปยังรายการที่ไม่อนุญาตหรือยกเว้นจากรายการที่ถูกจำกัดทั้งหมด
- หากยังไม่มี API ที่ซ่อนไว้ใน AOSP ให้เพิ่ม API ที่ซ่อนอยู่ลงในรายการที่ถูกจำกัด
3.1.1. ส่วนขยาย Android
Android รองรับการขยายแพลตฟอร์ม API ที่มีการจัดการของ API ระดับใดระดับหนึ่งโดยการอัปเดตเวอร์ชันส่วนขยายสำหรับระดับ API นั้น android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API จะแสดงเวอร์ชันส่วนขยายของ apiLevel
ที่ระบุ หากมีส่วนขยายสำหรับ API ระดับนั้น
การติดตั้งใช้งานอุปกรณ์ Android
[C-0-1] ต้องโหลดการใช้งาน AOSP ของทั้งไลบรารีที่ใช้ร่วมกัน
ExtShared
และบริการExtServices
ที่มีเวอร์ชันสูงกว่าหรือเท่ากับเวอร์ชันขั้นต่ำที่อนุญาตต่อ API แต่ละระดับล่วงหน้า ตัวอย่างเช่น การใช้งานอุปกรณ์ Android 7.0 ที่ใช้ API ระดับ 24 จะต้องมีเวอร์ชัน 1 เป็นอย่างน้อย[C-0-2] ต้องส่งคืนหมายเลขเวอร์ชันส่วนขยายที่ถูกต้องซึ่ง AOSP กำหนดเท่านั้น
[C-0-3] ต้องรองรับ API ทั้งหมดที่กำหนดโดยเวอร์ชันส่วนขยายที่
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
แสดงผลในลักษณะเดียวกับที่รองรับ API ที่มีการจัดการอื่นๆ ตามข้อกำหนดในส่วนที่ 3.1
3.1.2. ไลบรารี Android
เนื่องจากการเลิกใช้งานไคลเอ็นต์ HTTP ของ Apache การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [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 ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ในสตริงเวอร์ชันที่ได้รับอนุญาตสำหรับ Android 13 |
VERSION.SDK | เวอร์ชันของระบบ Android ที่กำลังใช้งานในปัจจุบัน ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 13 ช่องนี้ต้องมีค่าจำนวนเต็ม 13_INT |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่กำลังใช้งานในปัจจุบัน ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 13 ช่องนี้ต้องมีค่าจำนวนเต็ม 13_INT |
เวอร์ชันที่เพิ่มขึ้น | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์เฉพาะของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ต้องไม่นำค่านี้มาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางเข้าถึงได้ โดยทั่วไปแล้ว ช่องนี้มีไว้เพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตที่พิมพ์ได้ และตรงกับนิพจน์ทั่วไป “^[^ :\/~]+$" |
กระดาน | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในที่เจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้เพื่อระบุการแก้ไขที่เฉพาะเจาะจงของบอร์ดที่จ่ายไฟให้อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น 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 หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่มีการเปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
SOC_ผู้ผลิต | การแลกเปลี่ยนชื่อของผู้ผลิตระบบหลักบนชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SOC รายเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เกี่ยวกับค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต ต้องตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ]+)" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ช่องนี้ต้องไม่มีการเปลี่ยนแปลงตลอดอายุการใช้งานผลิตภัณฑ์ |
โมเดล SOC_MODEL | ชื่อรุ่นของระบบหลักบนชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มี SOC รุ่นเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อใช้ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ._/+-]+)$" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ช่องนี้ต้องไม่มีการเปลี่ยนแปลงในระหว่างอายุการใช้งานของผลิตภัณฑ์ |
MODEL | ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่อของอุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ช่องต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") โดยช่องนี้ต้องไม่มีการเปลี่ยนแปลงในระหว่างอายุการใช้งานของผลิตภัณฑ์ |
ผลิตภัณฑ์ | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ผู้ใช้ปลายทางไม่จำเป็นต้องอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ "ต้องไม่เปลี่ยนแปลง" ตลอดอายุการใช้งานของผลิตภัณฑ์ |
ODM_SKU | ค่าที่ไม่บังคับซึ่งผู้ให้บริการอุปกรณ์เลือกซึ่งมี SKU (สต็อกคีปปิ้งยูนิต) ซึ่งใช้เพื่อติดตามการกำหนดค่าเฉพาะของอุปกรณ์ เช่น อุปกรณ์ต่อพ่วงใดๆ ที่รวมอยู่ในอุปกรณ์เมื่อจำหน่าย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "[0-9A-Za-z.,_-])" |
ซีเรียล | ต้องส่งคืน "UNKNOWN" |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ให้บริการอุปกรณ์เลือกให้แยกความแตกต่างระหว่างบิลด์เพิ่มเติม แท็กต้องเข้ารหัสได้เป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองบนแพลตฟอร์ม Android 3 รายการทั่วไป ได้แก่ Release-key, dev-key และ test-key |
เวลา | ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์ |
ประเภท | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ 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 ทั่วไปของแอปพลิเคชัน
Intent ของ Android อนุญาตให้คอมโพเนนต์ของแอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์อื่นๆ ของ Android ได้ โปรเจ็กต์อัปสตรีมของ Android ประกอบด้วยรายการแอปพลิเคชันที่ใช้รูปแบบ Intent ต่างๆ เพื่อดำเนินการทั่วไป
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้โหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งระบุไว้ที่นี่ และดำเนินการตามความคาดหวังของนักพัฒนาซอฟต์แวร์สำหรับ Intent แอปพลิเคชันทั่วไปเหล่านี้ตามที่อธิบายไว้ใน SDK
โปรดดูส่วนที่ 2 สำหรับ Intent ของแอปพลิเคชันที่จำเป็นสำหรับอุปกรณ์แต่ละประเภท
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 ใดๆ โดยทำตามขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล ตามที่กำหนดโดย Package Manager ในโปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-5] ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ URI ที่ผ่านการตรวจสอบความถูกต้องแล้วทั้งหมดเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI
- อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากตัวกรองดังกล่าวได้รับการยืนยันเรียบร้อยแล้วแต่ตัวกรอง URI อื่นๆ ที่เลือกไม่ผ่านการตรวจสอบ หากการใช้งานอุปกรณ์มีลักษณะเช่นนี้ ระบบ "ต้อง" ลบล้างรูปแบบต่อ URI ที่เหมาะสมให้กับผู้ใช้ในเมนูการตั้งค่า
- ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้กับผู้ใช้ในการตั้งค่าดังนี้
- [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของลิงก์แอปเริ่มต้นในภาพรวมสำหรับแอปให้เป็น "เปิดตลอดเวลา ถามเสมอ หรือไม่เปิดเลย" ได้ ซึ่งจะใช้กับตัวกรอง 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 ด้วย นอกจากนี้ วัตถุประสงค์การเผยแพร่บางเหตุการณ์จะมีเงื่อนไขสำหรับการสนับสนุนฮาร์ดแวร์ หากอุปกรณ์รองรับฮาร์ดแวร์ที่จำเป็น ก็ต้องเผยแพร่ความตั้งใจและจัดเตรียมลักษณะการทำงานไว้ในเอกสาร SDK
3.2.3.5 Intent ของแอปพลิเคชันแบบมีเงื่อนไข
Android มีการตั้งค่าที่ช่วยให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นได้โดยง่าย เช่น หน้าจอหลักหรือ SMS
การใช้งานอุปกรณ์ต้องมีเมนูการตั้งค่าที่คล้ายกันและเข้ากันได้กับรูปแบบตัวกรอง Intent และเมธอด API ที่อธิบายไว้ในเอกสาร SDK ตามด้านล่างตามความเหมาะสม
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.home_screen
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องเป็นไปตามเจตนาของ
android.settings.HOME_SETTINGS
ในการแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony.calling ระบบจะดำเนินการต่อไปนี้
[C-2-1] ต้องระบุเมนูการตั้งค่าที่จะเรียกใช้
android.provider.Telephony.ACTION_CHANGE_DEFAULT
ความตั้งใจที่จะแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น[C-2-2] ต้องเป็นไปตามเจตนาของ
android.telecom.action.CHANGE_DEFAULT_DIALER
ในการแสดงกล่องโต้ตอบเพื่ออนุญาตให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้น- ต้องใช้ UI ของแอปโทรศัพท์เริ่มต้นที่ผู้ใช้เลือกสำหรับการโทรเข้าและโทรออก ยกเว้นการโทรหาหมายเลขฉุกเฉิน ซึ่งจะใช้แอปโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า
[C-2-3] ต้องปฏิบัติตาม android.telecom.action.CHANGE_PHONE_ACCOUNTS ค่าธรรมเนียมสำหรับผู้ใช้ในการกำหนดค่า
ConnectionServices
ที่เชื่อมโยงกับPhoneAccounts
รวมถึง บัญชี Phone เริ่มต้นที่ผู้ให้บริการโทรคมนาคม จะใช้ในการโทรออก การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยใส่เมนู "ตัวเลือกบัญชีการโทร" ไว้ในเมนูการตั้งค่า "การโทร"[C-2-4] ต้องอนุญาต
android.telecom.CallRedirectionService
สำหรับแอปที่มีบทบาทandroid.app.role.CALL_REDIRECTION
[C-2-5] ต้องให้ราคาแก่ผู้ใช้ในการเลือกแอปที่มีบทบาท
android.app.role.CALL_REDIRECTION
[C-2-6] ต้องปฏิบัติตามความตั้งใจของ android.intent.action.SENDTO และ android.intent.action.VIEW รวมถึงระบุกิจกรรมการส่ง/แสดงข้อความ SMS
[C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามความตั้งใจ android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW และ android.intent.action.DIAL ด้วยแอปพลิเคชันแป้นโทรศัพท์ที่โหลดไว้ให้ล่วงหน้า ซึ่งสามารถรองรับ Intent ดังกล่าวและรองรับ Intent เหล่านี้
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องปฏิบัติตาม android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการชำระเงินแบบไม่ต้องสัมผัส
- [C-3-2] ต้องทำตาม android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT เพื่อแสดงกิจกรรมซึ่งเปิดกล่องโต้ตอบเพื่อขอให้ผู้ใช้เปลี่ยน บริการจำลองบัตรเริ่มต้นสำหรับหมวดหมู่หนึ่งๆ ตามที่อธิบายไว้ใน SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องปฏิบัติตาม Intent เหล่านี้ android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED และ android.nfc.action.TECH_DISCOVERED เพื่อแสดงกิจกรรมซึ่งตอบสนองความคาดหวังของนักพัฒนาซอฟต์แวร์สำหรับ Intent เหล่านี้ ตามที่อธิบายไว้ใน SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.bluetooth
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-5-1] ต้องทำตาม ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ และแสดงกิจกรรมของระบบเพื่อให้ผู้ใช้เปิดบลูทูธ
- [C-5-2] ต้องเป็นไปตามความตั้งใจ ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" และแสดงกิจกรรมของระบบที่ขอโหมดที่ค้นพบได้
หากอุปกรณ์รองรับฟีเจอร์ DND ระบบจะดำเนินการดังต่อไปนี้
- [C-6-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อความตั้งใจ
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
ซึ่งสำหรับการใช้งานร่วมกับ UI_MODE_TYPE_NORMAL นั้น ต้องเป็นกิจกรรมที่ ผู้ใช้สามารถให้หรือปฏิเสธการเข้าถึงแอปในการกำหนดค่านโยบาย DND ได้
หากการใช้งานอุปกรณ์ทำให้ผู้ใช้สามารถใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-7-1] ต้องระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกำหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สามเพื่อตอบสนองต่อความตั้งใจของ
android.settings.INPUT_METHOD_SETTINGS
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-8-1] ต้องปฏิบัติตามเจตนาของ
android.settings.ACCESSIBILITY_SETTINGS
ในการจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดใช้และปิดใช้บริการการช่วยเหลือพิเศษของบุคคลที่สามควบคู่ไปกับบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า
หากการใช้งานอุปกรณ์มีการสนับสนุนสำหรับ Wi-Fi Easy Connect และแสดงฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม เหตุการณ์เหล่านี้จะมีลักษณะดังนี้
- [C-9-1] ต้องใช้ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
หากการติดตั้งใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-10-1] ต้องระบุอินเทอร์เฟซผู้ใช้ในการตั้งค่าที่จัดการความตั้งใจของ
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ซึ่งอนุญาตให้ผู้ใช้เพิ่มแอปพลิเคชันหรือนำแอปพลิเคชันออกจากรายการที่อนุญาตได้
หากอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต ระบบจะดำเนินการดังนี้
- [C-11-1] ต้องมีกิจกรรมที่จัดการความตั้งใจของ
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
แต่อาจนำไปใช้โดยไม่มีการดำเนินการ
หากการใช้งานอุปกรณ์ประกาศการรองรับกล้องผ่าน android.hardware.camera.any
ระบบจะดำเนินการดังต่อไปนี้
- [C-12-3] ต้องจัดการและอนุญาตเฉพาะแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้า
ให้จัดการ Intent ต่อไปนี้
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
และMediaStore.ACTION_VIDEO_CAPTURE
ตามที่อธิบายในเอกสาร SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin
สิ่งที่จะเกิดขึ้นมีดังนี้
[C-13-1] ต้องปฏิบัติตาม Intent
android.app.action.ADD_DEVICE_ADMIN
ในการเรียกใช้ UI เพื่อนำผู้ใช้ผ่านการเพิ่มผู้ดูแลระบบอุปกรณ์ ลงในระบบ (หรืออนุญาตให้ปฏิเสธ)[C-13-2] ต้องปฏิบัติตาม Intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD และ android.app.action.START_ENCRYPTION และมีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบาย
หากการใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.software.autofill
จะมีลักษณะดังนี้
- [C-14-1] ต้องใช้ API ของ
AutofillService
และAutofillManager
อย่างสมบูรณ์ และเป็นไปตามเจตนาของ android.settings.REQUEST_SET_AUTOFILL_SERVICE ในการแสดงเมนูการตั้งค่าแอปเริ่มต้นเพื่อเปิดใช้และปิดใช้การป้อนข้อความอัตโนมัติ รวมถึงเปลี่ยนบริการป้อนข้อความอัตโนมัติเริ่มต้นสำหรับผู้ใช้
หากการใช้งานอุปกรณ์มีแอปที่ติดตั้งมาล่วงหน้า หรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานได้ พวกเขาจะได้รับสิทธิ์ดังต่อไปนี้
- [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้กลไกที่ผู้ใช้เข้าถึงได้เพื่ออนุญาตหรือเพิกถอนการเข้าถึงสถิติการใช้งานเพื่อตอบสนองต่อความตั้งใจของ
android.settings.ACTION_USAGE_ACCESS_SETTINGS
สำหรับแอปที่ประกาศสิทธิ์
android.permission.PACKAGE_USAGE_STATS
หากการใช้งานอุปกรณ์ตั้งใจจะไม่อนุญาตแอปใดๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า ไม่ให้เข้าถึงสถิติการใช้งาน พวกเขาจะ:
- [C-15-1] ต้องมีกิจกรรมที่จัดการรูปแบบความตั้งใจ android.settings.ACTION_USAGE_ACCESS_SETTINGS แต่ "ต้องใช้" แบบ "ไม่มีการดำเนินการ" กล่าวคือต้องมีลักษณะการทำงานที่เทียบเท่ากันเมื่อผู้ใช้ถูกปฏิเสธการเข้าถึง
หากการใช้งานอุปกรณ์แสดงลิงก์ไปยังกิจกรรมที่ระบุโดย AutofillService_passwordsActivity ในการตั้งค่าหรือลิงก์ไปยังรหัสผ่านของผู้ใช้ผ่านกลไกที่คล้ายกัน การดำเนินการดังกล่าวจะส่งผลดังนี้
[C-16-1] ต้องแสดงลิงก์ดังกล่าวสำหรับบริการป้อนข้อความอัตโนมัติทั้งหมดที่ติดตั้งไว้
[C-17-1] [ย้ายไปที่ 2.2.3]
หากการนำอุปกรณ์ไปใช้งานรองรับ VoiceInteractionService
และมีแอปพลิเคชันที่ใช้ API นี้ติดตั้งหลายรายการพร้อมกัน ระบบจะดำเนินการดังต่อไปนี้
- [C-18-1] ต้องเป็นไปตามเจตนาของ
android.settings.ACTION_VOICE_INPUT_SETTINGS
ในการแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการป้อนข้อมูลด้วยเสียงและความช่วยเหลือ
หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output
ระบบจะดำเนินการต่อไปนี้
- [C-SR-3] แนะนำอย่างยิ่งให้ทำตาม android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT Intent มีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่
Android รองรับสกรีนเซฟเวอร์แบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า Dreams โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันเมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่บนแท่นชาร์จ การใช้งานอุปกรณ์:
- ควรมีการรองรับโปรแกรมรักษาหน้าจอและเสนอตัวเลือกการตั้งค่าให้ผู้ใช้กำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อความตั้งใจของ
android.settings.DREAM_SETTINGS
3.2.4 กิจกรรมบนจอแสดงผลรอง/หลายจอแสดงผล
หากการใช้งานอุปกรณ์อนุญาตให้เรียกใช้กิจกรรม Android ปกติบนจอแสดงผลมากกว่า 1 จอ จะเกิดสิ่งต่อไปนี้
- [C-1-1] ต้องตั้งค่าแฟล็กฟีเจอร์
android.software.activities_on_secondary_displays
- [C-1-2] ต้องรับประกันความเข้ากันได้ของ API ที่คล้ายกับกิจกรรมที่ทำงานอยู่บนจอแสดงผลหลัก
- [C-1-3] ต้องเข้าชมกิจกรรมใหม่ในจอแสดงผลเดียวกับกิจกรรมที่เรียกใช้ เมื่อกิจกรรมใหม่เริ่มขึ้นโดยไม่ระบุการแสดงเป้าหมายผ่าน API ของ
ActivityOptions.setLaunchDisplayId()
- [C-1-4] ต้องทำลายกิจกรรมทั้งหมดเมื่อนำจอแสดงผลที่มีธง
Display.FLAG_PRIVATE
ออก - [C-1-5] ต้องซ่อนเนื้อหาบนหน้าจอทั้งหมดอย่างปลอดภัยเมื่ออุปกรณ์ล็อกอยู่
ด้วยหน้าจอล็อกที่ปลอดภัย เว้นแต่แอปจะเลือกให้แสดงที่ด้านบนของหน้าจอล็อกโดยใช้
Activity#setShowWhenLocked()
API - ควรมี
android.content.res.Configuration
ที่สอดคล้องกับจอแสดงผลนั้นเพื่อให้แสดง ทำงานได้อย่างถูกต้อง และรักษาความเข้ากันได้ไว้หากมีการเปิดตัวกิจกรรมในจอแสดงผลรอง
หากการใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม Android ปกติในจอแสดงผลรองและจอแสดงผลรองจะมีธงสถานะ android.view.Display.FLAG_PRIVATE ดังนี้
- [C-3-1] เฉพาะเจ้าของจอแสดงผล ระบบ และกิจกรรมที่อยู่บนจอแสดงผลเท่านั้นที่ต้องเปิดจอแสดงผลได้ ทุกคนสามารถเปิดไปยัง จอแสดงผลที่มีธงสถานะ android.view.Display.FLAG_PUBLIC ได้
3.3 ความเข้ากันได้กับ API เดิม
ความเข้ากันได้ของโค้ดเนทีฟนั้นทำได้ยาก ด้วยเหตุนี้ ผู้ติดตั้งใช้งานอุปกรณ์จึงทำสิ่งต่อไปนี้
- [C-SR-1] แนะนำอย่างยิ่งให้ใช้การใช้งานไลบรารีที่ระบุไว้ด้านล่างจากโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
ไบต์โค้ด Dalvik ที่มีการจัดการจะเรียกใช้โค้ดแบบเนทีฟที่ระบุไว้ในไฟล์แอปพลิเคชัน .apk
เป็นไฟล์ ELF .so
ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสมได้ เนื่องจากโค้ดแบบเนทีฟต้องอาศัยเทคโนโลยีตัวประมวลผลพื้นฐานเป็นหลัก Android จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) จำนวนหนึ่งใน Android NDK
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่กำหนดไว้อย่างน้อย 1 รายการ
- [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
(NDK ไม่รองรับการกําหนดเป้าหมายอีกต่อไป)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] ต้องทำให้ไลบรารีต่อไปนี้ทั้งหมดซึ่งมี API แบบเนทีฟพร้อมใช้งานสำหรับแอปที่มีโค้ดแบบเนทีฟ
- libaaudio.so (รองรับเสียงแบบเสียงเนทีฟ)
- libamidi.so (การรองรับ MIDI เนทีฟ หากมีการอ้างสิทธิ์ฟีเจอร์
android.software.midi
ตามที่อธิบายไว้ในส่วน 5.9) - 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
- การดำเนินงานที่เป็นอุปสรรคของ 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 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 เช่น 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
[C-1-4] ต้องแสดงผลเนื้อหาที่ระบุหรือเนื้อหา URL ระยะไกลในกระบวนการที่แตกต่างจากแอปพลิเคชันที่สร้างอินสแตนซ์ WebView กล่าวโดยละเอียดคือ กระบวนการแสดงผลที่แยกต่างหากต้องถือสิทธิ์ระดับล่าง เรียกใช้เป็นรหัสผู้ใช้แยกต่างหาก ไม่มีสิทธิ์เข้าถึงไดเรกทอรีข้อมูลของแอป ไม่มีการเข้าถึงเครือข่ายโดยตรง และมีสิทธิ์เข้าถึงเฉพาะบริการของระบบที่จำเป็นน้อยที่สุดผ่าน Binder เท่านั้น การใช้ AOSP ของ WebView เป็นไปตามข้อกำหนดนี้
โปรดทราบว่าหากติดตั้งใช้งานอุปกรณ์เป็นแบบ 32 บิตหรือประกาศ Flag ฟีเจอร์ android.hardware.ram.low
อุปกรณ์จะได้รับการยกเว้นจาก C-1-3
3.4.2 ความเข้ากันได้กับเบราว์เซอร์
หากการใช้งานอุปกรณ์มีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับ การท่องเว็บทั่วไป จะมีการดำเนินการดังนี้
- [C-1-1] ต้องรองรับ API แต่ละรายการต่อไปนี้ที่เชื่อมโยงกับ HTML5
- [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ HTML5/W3C IndexedDB API โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ 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] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของ Intent มาตรฐาน
- [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 มาตรฐานของแอปในไฟล์ Manifest ของแอป เว้นแต่
Intent การเผยแพร่ต้องใช้สิทธิ์
"signature"
หรือ"signatureOrSystem"
protectionLevel
หรืออยู่ในรายการการยกเว้น - [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปจะต้องหยุดบริการในเบื้องหลังของแอป เช่นเดียวกับกรณีที่แอปเรียกใช้เมธอด
stopSelf()
ของบริการ เว้นแต่แอปจะอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่ผู้ใช้มองเห็นได้ - [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป
- [C-0-4] ผู้ใช้ต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
- [C-0-11] อุปกรณ์ต้องแสดงผู้ให้บริการการรักษาความปลอดภัยต่อไปนี้เป็นค่า
อาร์เรย์ 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 -
รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) จะทดสอบส่วนสำคัญของแพลตฟอร์มเพื่อดูความเข้ากันได้ด้านพฤติกรรม แต่ไม่ใช่ทั้งหมด ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ด้านพฤติกรรมกับโปรเจ็กต์โอเพนซอร์ส Android ด้วยเหตุนี้ ผู้ติดตั้งอุปกรณ์จึงควรใช้ซอร์สโค้ดที่มีให้ผ่านทางโครงการโอเพนซอร์ส Android เมื่อทำได้ แทนการนำส่วนที่สำคัญของระบบมาใช้ใหม่
3.5.1 ข้อจำกัดแอปพลิเคชัน
หากการใช้อุปกรณ์ใช้กลไกที่เป็นกรรมสิทธิ์เพื่อจำกัดแอป (เช่น การเปลี่ยนแปลงหรือจำกัดการทำงานของ API ที่อธิบายไว้ใน SDK) และกลไกนั้นมีข้อจำกัดมากกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ถูกจำกัด เหตุการณ์เหล่านี้จะเกิดขึ้น
- [C-1-1] ต้องอนุญาตให้ผู้ใช้เห็นรายการแอปที่ถูกจำกัด
- [C-1-2] ต้องให้เงินแก่ผู้ใช้ในการเปิด / ปิดข้อจำกัด ที่เป็นกรรมสิทธิ์ทั้งหมดเหล่านี้ในแต่ละแอป
[C-1-3] ต้องไม่ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้โดยอัตโนมัติโดยไม่มีหลักฐานแสดงการทำงานของระบบที่ไม่ดี แต่อาจใช้ข้อจำกัดกับแอปเมื่อตรวจพบการทำงานที่ไม่มีประสิทธิภาพของระบบ เช่น การทำงานขณะล็อกที่ค้าง บริการที่ใช้เวลานาน และเกณฑ์อื่นๆ ผู้ใช้อุปกรณ์อาจกำหนดเกณฑ์นี้ได้แต่ต้องเกี่ยวข้องกับผลกระทบที่แอปมีต่อประสิทธิภาพของระบบ เกณฑ์อื่นๆ ที่ไม่เกี่ยวข้องกับประสิทธิภาพการทำงานของระบบเพียงอย่างเดียว เช่น การที่แอปได้รับความนิยมในตลาด ต้องไม่ใช้เป็นเกณฑ์
[C-1-4] ต้องไม่ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้โดยอัตโนมัติสำหรับแอป เมื่อผู้ใช้ปิดข้อจำกัดของแอปด้วยตนเอง และอาจแนะนำให้ผู้ใช้ ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้
[C-1-5] ต้องแจ้งให้ผู้ใช้ทราบหากข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้มีผลกับแอปโดยอัตโนมัติ คุณต้องระบุข้อมูลดังกล่าวในช่วง 24 ชั่วโมงก่อนการใช้ข้อจำกัดในกรรมสิทธิ์เหล่านี้
[C-1-6] ต้องแสดงผลเป็น "จริง" สำหรับเมธอด ActivityManager.isBackgroundRestricted() สำหรับการเรียก API ทุกรายการจากแอป
[C-1-7] ต้องไม่จำกัดแอปที่ทำงานอยู่เบื้องหน้าด้านบนที่ผู้ใช้ ใช้งานอย่างชัดเจน
[C-1-8] ต้องระงับข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้ในแอปทุกครั้งที่ผู้ใช้เริ่มใช้แอปอย่างชัดแจ้ง ทำให้เป็นแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
[C-1-10] ต้องแสดงเอกสารหรือเว็บไซต์สาธารณะและชัดเจนที่อธิบาย วิธีใช้ข้อจำกัดที่เป็นกรรมสิทธิ์ เอกสารหรือเว็บไซต์นี้จะต้องลิงก์ได้จากเอกสาร Android SDK และต้องมีข้อมูลต่อไปนี้
- เงื่อนไขการทริกเกอร์สำหรับข้อจำกัดที่เป็นกรรมสิทธิ์
- วิธีจำกัดแอปและวิธีจำกัด
- วิธียกเว้นแอปจากข้อจำกัดดังกล่าว
- แอปจะขอยกเว้นจากข้อจำกัดที่เป็นกรรมสิทธิ์ได้อย่างไร หากแอปรองรับการยกเว้นดังกล่าวสำหรับแอปที่ผู้ใช้ติดตั้งได้
หากมีการติดตั้งแอปไว้ล่วงหน้าในอุปกรณ์และผู้ใช้ไม่เคยใช้งานอย่างชัดแจ้งเกิน 30 วัน ระบบจะยกเว้น [C-1-3] [C-1-5]
หากการนำอุปกรณ์ไปใช้งานขยายข้อจำกัดของแอปที่นำมาใช้ใน AOSP การดำเนินการดังกล่าวจะมีผลดังนี้
- [C-2-1]ต้องปฏิบัติตามการดำเนินการที่อธิบายไว้ในเอกสารนี้
3.5.2 ไฮเบอร์เนตของแอปพลิเคชัน
หากการใช้งานอุปกรณ์มี App Hibernation ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP การดำเนินการเหล่านี้จะมีผลดังนี้
- [C-1-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดในข้อ 3.5.1 ยกเว้น [C-1-6] และ [C-1-3]
- [C-1-2] ต้องใช้ข้อจำกัดในแอปสำหรับผู้ใช้เมื่อมีหลักฐานว่าผู้ใช้ไม่ได้ใช้แอปเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้กำหนดระยะเวลานี้อย่างน้อย 1 เดือน การใช้งานต้องกำหนดโดยการโต้ตอบอย่างชัดเจนของผู้ใช้ผ่าน UsageStats#getLastTimeVisible() หรืออะไรก็ตามที่จะทำให้แอปออกจากสถานะที่บังคับให้หยุด ซึ่งรวมถึงการเชื่อมโยงบริการ การเชื่อมโยงผู้ให้บริการเนื้อหา การเผยแพร่ที่ชัดเจน และอื่นๆ ซึ่งจะติดตามโดย API UsageStats#getLastTimeAnyComponentd() ใหม่
- [C-1-3] ต้องใช้ข้อจำกัดที่มีผลต่อผู้ใช้อุปกรณ์ทุกรายเมื่อมีหลักฐานว่าผู้ใช้ไม่มีการใช้แพ็กเกจเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้กำหนดระยะเวลานี้อย่างน้อย 1 เดือน
- [C-1-4] ต้องไม่แสดงผลแอปไม่ให้ตอบสนองต่อ Intent ของกิจกรรม การเชื่อมโยงบริการ คำขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่อาจไม่เหมาะสม
การไฮเบอร์เนตของแอปใน AOSP เป็นไปตามข้อกำหนดข้างต้น
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 ของ NDK ได้ แต่ API ที่กำหนดเองจะมีลักษณะดังนี้
- [C-1-1] ต้องไม่อยู่ในห้องสมุด NDK หรือห้องสมุดขององค์กรอื่นตามที่อธิบายไว้ที่นี่
หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซของแพ็กเกจรายการใดรายการหนึ่งข้างต้น (เช่น เพิ่มฟังก์ชันใหม่ที่มีประโยชน์ลงใน 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 |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
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 |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
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 |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
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 |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
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
หากการใช้งานอุปกรณ์รองรับไอคอนโมโนโครม ไอคอนเหล่านี้
- [C-6-1] ต้องใช้เฉพาะเมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง (เช่น ผ่านเมนูการตั้งค่าหรือตัวเลือกวอลเปเปอร์)
3.8.2 วิดเจ็ต
Android รองรับวิดเจ็ตแอปของบุคคลที่สามโดยการกำหนดประเภทของคอมโพเนนต์และ API และวงจรที่เกี่ยวข้องที่อนุญาตให้แอปพลิเคชันแสดง "AppWidget" ต่อผู้ใช้ปลายทาง
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สาม วิดเจ็ตจะดำเนินการดังนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม
android.software.app_widgets
- [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและแสดงความสามารถของอินเทอร์เฟซผู้ใช้ในการเพิ่ม กำหนดค่า ดู และนำ AppWidgets ออก
- [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 มี Notification
และ
NotificationManager
API ที่ช่วยให้นักพัฒนาแอปของบุคคลที่สามสามารถแจ้งผู้ใช้เกี่ยวกับกิจกรรมสำคัญและดึงดูดความสนใจของผู้ใช้โดยใช้ส่วนประกอบของฮาร์ดแวร์ (เช่น เสียง การสั่น และแสง) รวมถึงฟีเจอร์ของซอฟต์แวร์ (เช่น หน้าต่างแจ้งเตือน แถบระบบ) ของอุปกรณ์
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-1] แนะนำอย่างเข้มงวดเพื่อให้จ่ายเงินแก่ผู้ใช้ในการควบคุมการแจ้งเตือนที่แสดงต่อผู้ใช้ซึ่งได้รับสิทธิ์ Listener การแจ้งเตือน ต้องมีรายละเอียดเพื่อให้ผู้ใช้สามารถควบคุมผู้ฟังการแจ้งเตือนแต่ละคนว่ามีประเภทการแจ้งเตือนใดบ้างที่เชื่อมไปยัง Listener นี้ ประเภทต้องมี "การสนทนา" "การแจ้งเตือน" "ปิดเสียง" และ "การแจ้งเตือนที่สำคัญอย่างต่อเนื่อง"
- [C-SR-2] แนะนำอย่างยิ่งให้ทางเลือกแก่ผู้ใช้ในการระบุแอปที่แยกออกจากการแจ้งเตือน Listener การแจ้งเตือนที่เฉพาะเจาะจง
- [C-SR-3] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแก่ผู้ใช้โดยอัตโนมัติเพื่อบล็อกการแจ้งเตือนของแอปของบุคคลที่สามสำหรับช่องทางและระดับแพ็กเกจแอปแต่ละรายการ หลังจากที่ผู้ใช้ปิดการแจ้งเตือนหลายครั้งแล้ว
- ควรรองรับการแจ้งเตือนที่สมบูรณ์
- ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
- ผู้ใช้ควรสามารถเลื่อนการแจ้งเตือน
- อาจจัดการได้เฉพาะระดับการเข้าถึงและช่วงเวลาที่แอปของบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญๆ เพื่อลดปัญหาด้านความปลอดภัย เช่น สิ่งรบกวนผู้ขับขี่
Android 11 เพิ่มการรองรับการแจ้งเตือนการสนทนา ซึ่งเป็นการแจ้งเตือนที่ใช้ MessagingStyle และให้รหัสทางลัดของ People ที่เผยแพร่แล้ว
การติดตั้งใช้งานอุปกรณ์
- [C-SR-4] ขอแนะนำอย่างยิ่งให้จัดกลุ่มและแสดง
conversation notifications
ก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนของimportance:high
ที่ดำเนินอยู่
หากการติดตั้งใช้งานอุปกรณ์รองรับ conversation notifications
และแอปให้ข้อมูลที่จำเป็นสำหรับ bubbles
อุปกรณ์ดังกล่าวจะดำเนินการดังนี้
- [C-SR-5] แนะนำให้แสดงการสนทนานี้เป็นบับเบิล การใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้พร้อมด้วย UI ของระบบ, การตั้งค่า และ Launcher เริ่มต้น
หากอุปกรณ์รองรับการแจ้งเตือนที่สมบูรณ์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [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
ที่อนุญาตให้แอป (ผู้ใช้เปิดใช้อย่างชัดแจ้ง) เพื่อรับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงทีในบริการ Listener ที่ติดตั้งและเปิดใช้งานดังกล่าวทั้งหมด รวมถึงข้อมูลเมตาทั้งหมดที่แนบกับออบเจ็กต์การแจ้งเตือน
- [C-0-2] ต้องปฏิบัติตามการเรียก API ของ
snoozeNotification()
และปิดการแจ้งเตือนและทำการเรียกกลับหลังจากระยะเวลาเลื่อนการแจ้งเตือนที่ตั้งค่าไว้ในการเรียก API
หากการติดตั้งอุปกรณ์ทำให้ผู้ใช้สามารถปิดการแจ้งเตือนชั่วคราวได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องแสดงสถานะการแจ้งเตือนเลื่อนการแจ้งเตือนอย่างถูกต้องผ่าน API มาตรฐาน เช่น
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] ต้องทำให้มีเงินไม่เพียงพอในการปิดการแจ้งเตือนชั่วคราวจากแอปของบุคคลที่สามที่ติดตั้งไว้แต่ละแอป เว้นแต่ว่าแอปจะมาจากบริการถาวร/ที่ทำงานอยู่เบื้องหน้า
3.8.3.3 DND (ห้ามรบกวน)/ โหมดลำดับความสำคัญ
หากการใช้งานอุปกรณ์รองรับฟีเจอร์ DND (หรือที่เรียกว่าโหมดลำดับความสำคัญ) อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องเสนอกฎ DND อัตโนมัติที่สร้างโดยแอปพลิเคชันควบคู่ไปกับกฎที่สร้างโดยผู้ใช้และกฎที่กำหนดไว้ล่วงหน้าเมื่อการใช้อุปกรณ์ระบุวิธีให้ผู้ใช้ให้สิทธิ์หรือปฏิเสธแอปของบุคคลที่สามในการเข้าถึงการกำหนดค่านโยบาย DND
- [C-1-3] ต้องปฏิบัติตามค่า
suppressedVisualEffects
ที่ส่งผ่านNotificationManager.Policy
และหากแอปตั้งค่าแฟล็ก SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON ควรแจ้งให้ผู้ใช้ทราบว่าเอฟเฟกต์ภาพไม่แสดงในเมนูการตั้งค่า DND
3.8.4 Assist 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 หรือเนื้อหาที่แสดงในแอปพลิเคชัน
[C-1-3] ต้องตั้งค่าชุดแบบอักษร "sans-serif" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือเสนอค่าใช้จ่ายในการเปลี่ยนแบบอักษรที่ใช้ในชุดแบบอักษร "sans-serif" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ
[C-1-4] ต้องสร้างชุดโทนสีไดนามิกตามที่ระบุในเอกสารประกอบ AOSP ของ
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(ดูandroid.theme.customization.system_palette
และandroid.theme.customization.theme_style
)[C-1-5] ต้องสร้างชุดโทนสีแบบไดนามิกโดยใช้รูปแบบธีมสี ตามที่ระบุไว้ในเอกสารประกอบ
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(ดูandroid.theme.customization.theme_styles
) ได้แก่TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
FRUIT_SALAD
ใช้ "สีต้นฉบับ" ในการสร้างชุดสีโทนแบบไดนามิกเมื่อส่งด้วย
android.theme.customization.system_palette
(ตามที่ระบุไว้ในเอกสารSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
)[C-1-6] ต้องมีค่าความคมชัด
CAM16
เท่ากับ 5 ขึ้นไปควรได้มาจากวอลเปเปอร์ผ่าน
com.android.systemui.monet.ColorScheme#getSeedColors
ซึ่งมีสีแหล่งที่มาที่ถูกต้องหลายสีให้เลือกควรใช้ค่า
0xFF1B6EF3
หากไม่มีสีที่ระบุเป็นไปตามข้อกำหนดสีแหล่งที่มาข้างต้น
Android ยังมีกลุ่มธีม "ค่าเริ่มต้นของอุปกรณ์" เป็นชุดรูปแบบที่นักพัฒนาแอปกำหนดไว้เพื่อให้นักพัฒนาแอปใช้หากต้องการให้เข้ากับรูปลักษณ์ของธีมของอุปกรณ์ตามที่ผู้ให้บริการอุปกรณ์เป็นผู้กำหนด
- การใช้งานอุปกรณ์อาจแก้ไขแอตทริบิวต์ธีมเริ่มต้นของอุปกรณ์ที่แสดงต่อแอปพลิเคชัน
Android รองรับธีมของเวอร์ชันที่มีแถบระบบโปร่งแสงซึ่งช่วยให้นักพัฒนาแอปพลิเคชันใส่เนื้อหาแอปลงในพื้นที่ด้านหลังสถานะและแถบนำทางได้ เพื่อให้นักพัฒนาซอฟต์แวร์ได้รับประสบการณ์ที่สอดคล้องกันในการกำหนดค่านี้ สิ่งสำคัญคือสไตล์ไอคอนแถบสถานะจะต้องสอดคล้องกันในการใช้งานอุปกรณ์ที่แตกต่างกัน
หากการใช้งานอุปกรณ์มีแถบสถานะของระบบ ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ความแรงของสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบออกให้ ยกเว้นกรณีที่ไอคอนแสดงสถานะที่เป็นปัญหาหรือแอปขอแถบสถานะไฟโดยใช้ธง WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS
- [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 ครั้ง
- ควรเรียกใช้โหมดหลายหน้าต่างแยกหน้าจอ (หากรองรับ) เมื่อกดแป้นฟังก์ชันล่าสุดค้างไว้
- อาจแสดงรายการล่าสุดที่เชื่อมโยงเป็นกลุ่มที่ย้ายไปด้วยกัน
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซผู้ใช้ Android อัปสตรีม (หรืออินเทอร์เฟซที่ใช้ภาพขนาดย่อที่คล้ายกัน) สำหรับหน้าจอภาพรวม
3.8.9 การจัดการอินพุต
Android มีการสนับสนุนสำหรับ การจัดการอินพุต และการรองรับสำหรับตัวแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม
หากการใช้งานอุปกรณ์ทำให้ผู้ใช้สามารถใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และ รองรับ IME API ตามที่ระบุไว้ในเอกสาร Android SDK
3.8.10 การควบคุมสื่อสำหรับหน้าจอล็อก
Remote Control Client API เลิกใช้งานแล้วจาก Android 5.0 เพื่อไปเปลี่ยนมาใช้ เทมเพลตการแจ้งเตือนสื่อ ที่อนุญาตให้แอปพลิเคชันสื่อผสานรวมกับตัวควบคุมการเล่นที่แสดงบนหน้าจอล็อกได้
3.8.11 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)
ดูส่วนที่ 3.2.3.5 สำหรับการตั้งค่า ที่จะรวมโปรแกรมรักษาหน้าจอเข้าด้วยกัน
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 แบบเต็มของภาษาละติน กรีก และซีริลลิก รวมถึงช่วง Latined A, B, C และ D และอักษรทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0
- [C-1-3] ต้องไม่นำออกหรือแก้ไข NotoColorEmoji.tff ในอิมเมจระบบ (คุณสามารถเพิ่มแบบอักษรอีโมจิใหม่เพื่อลบล้างอีโมจิใน NotoColorEmoji.tff)
- ควรสนับสนุนสีผิวและอีโมจิที่หลากหลายสำหรับครอบครัวตามที่ระบุไว้ใน รายงานทางเทคนิคของ Unicode #51
หากอุปกรณ์มี IME รวมอยู่ด้วย ระบบจะดำเนินการดังนี้
- ควรระบุวิธีการป้อนข้อมูลสำหรับอักขระอีโมจิเหล่านี้ให้แก่ผู้ใช้
Android รองรับการแสดงผลแบบอักษรภาษาเมียนมา เมียนมามีแบบอักษรที่ไม่สอดคล้องกับ Unicode หลายแบบ หรือที่รู้จักกันโดยทั่วไปว่า “Zawgyi” สำหรับแสดงผลภาษาเมียนมา
หากการติดตั้งใช้งานอุปกรณ์ครอบคลุมการรองรับภาษาพม่า การใช้งานจะส่งผลดังนี้
- [C-2-1] ต้องแสดงผลข้อความด้วยแบบอักษรที่สอดคล้องกับ Unicode เป็นค่าเริ่มต้น แบบอักษรที่ไม่สอดคล้องกับ Unicode ต้องไม่ตั้งเป็นแบบอักษรเริ่มต้น เว้นแต่ผู้ใช้จะเลือกแบบอักษรดังกล่าวในตัวเลือกภาษา
- [C-2-2] ต้องรองรับแบบอักษร Unicode และแบบอักษรที่ไม่สอดคล้องกับ Unicode หากอุปกรณ์รองรับแบบอักษรที่ไม่สอดคล้องกับ Unicode แบบอักษรที่ไม่สอดคล้องกับ Unicode ต้องไม่นำแบบอักษร Unicode ออกหรือเขียนทับแบบอักษร Unicode
- [C-2-3] ต้องแสดงผลข้อความด้วยแบบอักษรที่ไม่สอดคล้องกับ Unicode เฉพาะกรณีที่มีการระบุรหัสภาษาที่มี script code Qaag (เช่น my-Qaag) ห้ามใช้รหัสภาษาหรือรหัสภูมิภาค ISO อื่นๆ (ไม่ว่าจะกำหนด ไม่ได้กำหนด หรือสงวนไว้) เพื่ออ้างถึงแบบอักษรที่ไม่สอดคล้องกับ Unicode ในเมียนมา นักพัฒนาแอปและผู้เขียนหน้าเว็บสามารถระบุว่า my-Qaag เป็นรหัสภาษาที่กำหนดได้เหมือนกับรหัสภาษาอื่นๆ
3.8.14 หลายหน้าต่าง
หากการใช้งานอุปกรณ์สามารถแสดงกิจกรรมหลายอย่างในเวลาเดียวกันได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตามลักษณะการทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ในเอกสารประกอบการสนับสนุนโหมดหลายหน้าต่างของ Android SDK และเป็นไปตามข้อกำหนดต่อไปนี้
- [C-1-2] ต้องยึดตาม
android:resizeableActivity
ที่ตั้งค่าโดยแอปในไฟล์AndroidManifest.xml
ตามที่อธิบายไว้ใน SDK นี้ - [C-1-3] ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดอิสระ หากความสูงของหน้าจอต่ำกว่า 440 dp และความกว้างของหน้าจอน้อยกว่า 440 dp
- [C-1-4] ต้องไม่ปรับขนาดกิจกรรมให้มีขนาดเล็กกว่า 220dp ในโหมดหลายหน้าต่างที่ไม่ใช่การแสดงภาพซ้อนภาพ
- การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ
xlarge
ควรรองรับโหมดรูปแบบอิสระ
หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดแยกหน้าจอ การใช้งานจะส่งผลดังนี้
- [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 ผ่านทาง API ของ
setAspectRatio()
- [C-3-4] ต้องใช้
KeyEvent.KEYCODE_WINDOW
เพื่อควบคุมหน้าต่าง PIP หากไม่ใช้โหมด PIP คีย์ต้อง พร้อมใช้งานสำหรับกิจกรรมเบื้องหน้า - [C-3-5] ต้องเสนอค่าตอบแทนแก่ผู้ใช้ในการบล็อกแอปไม่ให้แสดงในโหมด PIP การใช้ AOSP เป็นไปตามข้อกำหนดนี้โดยให้มีการควบคุมในหน้าต่างแจ้งเตือน
[C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับหน้าต่าง PIP เมื่อแอปพลิเคชันไม่ได้ประกาศค่าใดๆ สำหรับ
AndroidManifestLayout_minWidth
และAndroidManifestLayout_minHeight
:- อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าไว้นอกเหนือจาก
UI_MODE_TYPE_TELEVISION
ต้องจัดสรรความกว้างและความสูงขั้นต่ำเป็น 108 dp - อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าเป็น
UI_MODE_TYPE_TELEVISION
ต้องจัดสรรความกว้างขั้นต่ำ 240 dp และความสูงขั้นต่ำ 135 dp
- อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าไว้นอกเหนือจาก
3.8.15 หน้าจอรอยบาก
Android รองรับหน้าจอรอยบาก
ตามที่อธิบายไว้ในเอกสาร SDK DisplayCutout
API กำหนดพื้นที่ที่ขอบของจอแสดงผลซึ่งอาจใช้งานไม่ได้สำหรับแอปพลิเคชันเนื่องจากมีหน้าจอรอยบากหรือหน้าจอโค้ง
หากการใช้งานอุปกรณ์รวมหน้าจอรอยบากไว้ จะมีผลดังนี้
- [C-1-5] ต้องไม่มีรอยบากหากสัดส่วนภาพของอุปกรณ์คือ 1.0(1:1)
- [C-1-2] ต้องไม่มีคัตเอาต์มากกว่า 1 คัตเอาต์ต่อขอบ
- [C-1-3] ต้องใช้ Flag หน้าจอรอยบากที่แอปกำหนดผ่าน
WindowManager.LayoutParams
API ตามที่อธิบายไว้ใน SDK - [C-1-4] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกคัตเอาต์ทั้งหมดที่กำหนดไว้ใน
DisplayCutout
API
3.8.16 ระบบควบคุมอุปกรณ์
Android มี ControlsProviderService
และ Control
API ที่ช่วยให้แอปพลิเคชันของบุคคลที่สามเผยแพร่ระบบควบคุมอุปกรณ์เพื่อดูสถานะและการดำเนินการได้อย่างรวดเร็วสำหรับผู้ใช้
โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2_2_3
3.8.17 คลิปบอร์ด
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่ส่งข้อมูลคลิปบอร์ดไปยังคอมโพเนนต์ กิจกรรม บริการ หรือ ผ่านการเชื่อมต่อเครือข่ายใดๆ โดยไม่มีการดำเนินการอย่างชัดแจ้งของผู้ใช้ (เช่น การกดปุ่มบนการวางซ้อน) ยกเว้นบริการที่กล่าวถึงใน 9.8.6 Content Capture และ App Search
หากการนำอุปกรณ์ไปใช้งานสร้างการแสดงตัวอย่างที่ผู้ใช้มองเห็นได้เมื่อคัดลอกเนื้อหา
ไปยังคลิปบอร์ดสำหรับรายการใน ClipData
ที่
ClipData.getDescription().getExtras()
มี android.content.extra.IS_SENSITIVE
อยู่ด้วย สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องปกปิดตัวอย่างที่ผู้ใช้เห็นได้
การใช้ข้อมูลอ้างอิง AOSP เป็นไปตามข้อกำหนดของคลิปบอร์ดเหล่านี้
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-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์
หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะ
เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์
หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่าน
Flag ฟีเจอร์
android.hardware.nfc
และได้รับข้อความ NFC ที่มีระเบียนประเภท MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-8] ต้องส่ง ACTION_GET_PROVISIONING_mode
หลังจากระบบเรียกใช้การจัดสรรเจ้าของอุปกรณ์ เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์
ขึ้นอยู่กับค่าของ
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
เว้นแต่ว่าจะระบุจากบริบทที่มีเพียงตัวเลือกที่ถูกต้องเพียงตัวเลือกเดียว - [C-1-9] ต้องส่ง ACTION_ADMIN_POLICY_COMPLIANCE ไปยังแอปเจ้าของอุปกรณ์ หากมีการสร้างเจ้าของอุปกรณ์ ในระหว่างการจัดสรร ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าแอปเจ้าของอุปกรณ์จะทำงานเสร็จ
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์
หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะ
เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์
หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่าน
Flag ฟีเจอร์
- เมื่อมีการติดตั้งใช้งานอุปกรณ์
มีข้อมูลผู้ใช้หรือข้อมูลผู้ใช้
- [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป
- เมื่ออุปกรณ์ไม่มีการกำหนดค่าผู้ใช้และข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-2] ต้องแสดงประกาศเกี่ยวกับการเปิดเผยข้อมูลที่เหมาะสม (เช่น ดังที่อ้างถึงใน AOSP) และได้รับความยินยอมจากผู้ใช้ปลายทางก่อนที่แอปจะ ตั้งค่าเป็นเจ้าของอุปกรณ์ เว้นแต่อุปกรณ์จะได้รับการกำหนดค่าแบบเป็นโปรแกรมสำหรับโหมดสาธิตสำหรับร้านค้าปลีกก่อนที่จะโต้ตอบกับผู้ใช้ปลายทางบนหน้าจอ
หากการใช้อุปกรณ์ประกาศ android.software.device_admin
แต่รวมโซลูชันการจัดการอุปกรณ์ที่เป็นกรรมสิทธิ์ด้วย และให้กลไกในการโปรโมตแอปพลิเคชันที่กำหนดค่าในโซลูชันของตนเป็น "เทียบเท่ากับเจ้าของอุปกรณ์" กับ "เจ้าของอุปกรณ์" มาตรฐานตามที่ Android DevicePolicyManager API มาตรฐานรู้จัก จะมีการดำเนินการต่อไปนี้
- [C-2-1] ต้องมีขั้นตอนยืนยันว่าแอปที่โปรโมต เป็นโซลูชันการจัดการอุปกรณ์ขององค์กรที่ถูกต้อง และได้รับการกำหนดค่าในโซลูชันที่เป็นกรรมสิทธิ์ ให้มีสิทธิ์เทียบเท่ากับ "เจ้าของอุปกรณ์"
- [C-2-2] ต้องแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับขั้นตอนที่
android.app.action.PROVISION_MANAGED_DEVICE
เริ่มต้นก่อนที่จะลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์" - [C-2-3] ต้องไม่ฮาร์ดโค้ดความยินยอมหรือป้องกันการใช้แอปอื่นๆ ของเจ้าของอุปกรณ์
3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
[C-1-1] ต้องใช้ API เพื่ออนุญาตให้แอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) เป็น เจ้าของโปรไฟล์ที่มีการจัดการใหม่
[C-1-2] กระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (ขั้นตอนที่เริ่มต้นโดย DPC โดยใช้ android.app.action.PROVISION_MANAGED_PROFILE) หรือตามแพลตฟอร์ม) หน้าจอคำยินยอมและประสบการณ์ของผู้ใช้ต้องสอดคล้องกับการใช้งาน AOSP
[C-1-3] ต้องมีค่าใช้จ่ายสำหรับผู้ใช้ต่อไปนี้ภายในการตั้งค่า เพื่อระบุให้ผู้ใช้ทราบเมื่อตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ปิดใช้งานฟังก์ชันของระบบบางอย่าง
- ไอคอนที่สอดคล้องกันหรือการชำระเงินอื่นๆ ของผู้ใช้ (เช่น ไอคอนข้อมูล AOSP ต้นทาง) เพื่อแสดงเมื่อผู้ดูแลระบบอุปกรณ์จำกัดการตั้งค่าบางอย่าง
- ข้อความอธิบายสั้นๆ ตามที่ผู้ดูแลระบบอุปกรณ์ระบุไว้ผ่าน
setShortSupportMessage
- ไอคอนของแอปพลิเคชัน DPC
[C-1-4] ต้องเปิดใช้งานเครื่องจัดการสำหรับ ACTION_PROVISIONING_SUCCESSFUL ในโปรไฟล์งาน หากมีการสร้างเจ้าของโปรไฟล์เมื่อการจัดสรรเริ่มต้นขึ้นโดยความตั้งใจ android.app.action.PROVISION_MANAGED_PROFILE และ DPC ได้ติดตั้งใช้งานเครื่องจัดการแล้ว
[C-1-5] ต้องส่งประกาศ ACTION_PROFILE_PROVISIONING_COMPLETE ไปยัง DPC ของโปรไฟล์งานเมื่อเริ่มต้นการจัดสรรโดยความตั้งใจ android.app.action.PROVISION_MANAGED_PROFILE
[C-1-6] ต้องส่งความตั้งใจ ACTION_GET_PROVISIONING_mode หลังจากระบบเรียกใช้การจัดสรรเจ้าของโปรไฟล์ เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ยกเว้นในกรณีที่ Intent ทริกเกอร์ android.app.action.PROVISION_MANAGED_PROFILE ทริกเกอร์
[C-1-7] ต้องส่งความตั้งใจ ACTION_ADMIN_POLICY_COMPLIANCE ไปยังโปรไฟล์งานเมื่อมีการสร้างเจ้าของโปรไฟล์ระหว่างการจัดสรร ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม ยกเว้นเมื่อการจัดสรรถูกเรียกใช้โดย Intent android.app.action.PROVISION_MANAGED_PROFILE ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าแอปเจ้าของโปรไฟล์จะทำงานเสร็จ
[C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ไปยัง 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 ตัวเลือก เพื่อให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากถูกเปิดใช้งานโดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
- [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีการจ่ายเงินสำหรับผู้ใช้ดังต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- แยกการพิจารณาแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และการใช้พื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการโดยอิสระ
- การจัดการอิสระของแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันแป้นโทรศัพท์ รายชื่อติดต่อ และการรับส่งข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลักได้ หากเครื่องมือควบคุมนโยบายด้านอุปกรณ์อนุญาต
- [C-1-9] ต้องตรวจสอบว่าโปรไฟล์นั้นเป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่ใช้กับอุปกรณ์ที่มีผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users
และ android.software.secure_lock_screen
นโยบายจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากซึ่งเป็นไปตามข้อกำหนดต่อไปนี้ในการให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการเท่านั้น
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตามจุดประสงค์ของ
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ - ข้อมูลเข้าสู่ระบบในหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้พื้นที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกันกับโปรไฟล์หลักตามที่บันทึกไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- นโยบายรหัสผ่านของ DPC ต้องใช้กับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการเท่านั้น เว้นแต่ว่าจะมีการเรียกอินสแตนซ์
DevicePolicyManager
ที่แสดงผลโดย getParentProfileInstance
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตามจุดประสงค์ของ
- เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนว่ากำลังอยู่ในสาย และการแจ้งเตือนสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อดังกล่าวควรมีป้ายติด ป้ายเดียวกับที่ใช้ระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
3.9.3 การสนับสนุนผู้ใช้ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
- [C-1-1] ต้องมอบเงินแก่ผู้ใช้ในการออกจากระบบของผู้ใช้ปัจจุบันและ
เปลี่ยนกลับไปเป็นผู้ใช้หลักในเซสชันที่มีผู้ใช้หลายคนเมื่อ
isLogoutEnabled
แสดงผลtrue
ราคาที่ผู้ใช้ต้องเข้าถึงได้จากหน้าจอล็อก โดยไม่ต้องปลดล็อกอุปกรณ์
หากการใช้งานอุปกรณ์ประกาศ android.software.device_admin
และให้ค่าตอบแทนผู้ใช้ในอุปกรณ์ในการเพิ่มผู้ใช้รองเพิ่มเติม เงื่อนไขจะมีลักษณะดังนี้
- [C-SR-1] แนะนำอย่างยิ่งโดยแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับที่แสดงในขั้นตอนที่ android.app.action.PROVISION_MANAGED_DEVICE เป็นผู้เริ่มก่อนที่จะอนุญาตให้เพิ่มบัญชีในผู้ใช้รองรายใหม่เพื่อให้ผู้ใช้ทราบว่าอุปกรณ์ได้รับการจัดการ
3.9.4 ข้อกำหนดของบทบาทการจัดการนโยบายด้านอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin
หรือ android.software.managed_users
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับบทบาทการจัดการนโยบายด้านอุปกรณ์ตามที่ระบุไว้ในส่วนที่ 9.1 แอปพลิเคชันที่มีบทบาทการจัดการนโยบายด้านอุปกรณ์อาจกำหนดไว้โดยการตั้งค่า
config_devicePolicyManagement
เป็นชื่อแพ็กเกจ ชื่อแพ็กเกจต้องตามด้วย:
และใบรับรองที่ลงนาม เว้นแต่มีการโหลดแอปพลิเคชันไว้ล่วงหน้า
หากไม่ได้กำหนดชื่อแพ็กเกจสำหรับ config_devicePolicyManagement
ตามที่อธิบายไว้ข้างต้น
- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการจัดสรรโดยไม่มีแอปพลิเคชันผู้ถือบทบาทการจัดการนโยบายด้านอุปกรณ์ (AOSP มีการใช้งานข้อมูลอ้างอิง)
หากมีการกำหนดชื่อแพ็กเกจสำหรับ config_devicePolicyManagement
ตามที่อธิบายไว้ข้างต้น
- [C-3-1] ต้องติดตั้งแอปพลิเคชันใน โปรไฟล์ ทั้งหมดสำหรับผู้ใช้
- [C-3-2] การใช้งานอุปกรณ์อาจกำหนดแอปพลิเคชันที่อัปเดตเจ้าของบทบาทการจัดการนโยบายด้านอุปกรณ์ก่อนการจัดสรรโดยการตั้งค่า
config_devicePolicyManagementUpdater
หากมีการกำหนดชื่อแพ็กเกจสำหรับ config_devicePolicyManagementUpdater
ตามที่อธิบายไว้ข้างต้น
- [C-4-1] อุปกรณ์ต้องติดตั้งแอปพลิเคชันไว้ล่วงหน้า
- [C-4-2] แอปพลิเคชันต้องใช้ตัวกรอง Intent ซึ่งแก้ไข
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
3.10 การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่มีความพิการด้านการใช้งานอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API ของแพลตฟอร์มที่ช่วยให้ติดตั้งใช้งานบริการการช่วยเหลือพิเศษเพื่อรับ Callback สำหรับเหตุการณ์ของผู้ใช้และระบบ รวมถึงสร้างกลไกการแสดงความคิดเห็นอื่นๆ เช่น การอ่านออกเสียงข้อความ การตอบสนองแบบรู้สึกได้ และการนำทางแทร็กบอล/D-pad
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องติดตั้งใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบ SDK ของ API การช่วยเหลือพิเศษ
- [C-1-2] ต้องสร้างเหตุการณ์การช่วยเหลือพิเศษและนำส่ง
AccessibilityEvent
ที่เหมาะสมให้กับการติดตั้งใช้งานAccessibilityService
ที่ลงทะเบียนไว้ทั้งหมดตามที่ระบุไว้ใน SDK - [C-1-4] ต้องให้เงินแก่ผู้ใช้ในการควบคุมบริการการช่วยเหลือพิเศษที่ประกาศ AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON โปรดทราบว่าสำหรับการใช้อุปกรณ์กับแถบนำทางของระบบ ผู้ใช้ควรมีตัวเลือกให้ปุ่มในแถบนำทางของระบบเพื่อควบคุมบริการเหล่านี้
หากการใช้งานอุปกรณ์มีบริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้บริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้าเหล่านี้เป็นแอป Direct Boot Aware เมื่อพื้นที่เก็บข้อมูลได้รับการเข้ารหัสด้วย File As 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 TV
หากการติดตั้งใช้งานอุปกรณ์รองรับ 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 สื่อ
หากการใช้งานอุปกรณ์มีแอปพลิเคชันที่ไม่ได้เปิดใช้งานด้วยเสียง (แอป) ซึ่งโต้ตอบกับแอปพลิเคชันของบุคคลที่สามผ่าน MediaBrowser
หรือ MediaSession
แอปจะดำเนินการดังนี้
[C-1-2] ต้องแสดงไอคอนที่ได้รับจาก getIconBitmap() หรือ getIconUri() อย่างชัดเจน รวมถึงชื่อที่ได้รับผ่านทาง getTitle() ตามที่อธิบายไว้ใน
MediaDescription
อาจย่อชื่อเพื่อให้สอดคล้องกับกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนผู้ขับขี่)[C-1-3] ต้องแสดงไอคอนแอปพลิเคชันของบุคคลที่สามทุกครั้งที่แสดงเนื้อหาที่มาจากแอปพลิเคชันของบุคคลที่สามนี้
[C-1-4] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับ
MediaBrowser
ทั้งลำดับชั้น อาจจำกัดการเข้าถึงในบางลำดับชั้นเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น การรบกวนผู้ขับขี่) แต่ต้องไม่ให้การดูแลเป็นพิเศษตามเนื้อหาหรือผู้ให้บริการเนื้อหา[C-1-5] ต้องแตะ 2 ครั้งสำหรับ
KEYCODE_HEADSETHOOK
หรือKEYCODE_MEDIA_PLAY_PAUSE
เป็นKEYCODE_MEDIA_NEXT
สำหรับMediaSession.Callback#onMediaButtonEvent
3.15 Instant Apps
หากอุปกรณ์รองรับ Instant Apps แอปจะต้องเป็นไปตามข้อกำหนดต่อไปนี้
- [C-1-1] Instant Apps ต้องได้รับสิทธิ์ที่ตั้งค่า
android:protectionLevel
เป็น"instant"
เท่านั้น - [C-1-2] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งผ่าน implicit Intent
เว้นแต่เป็นไปตามข้อใดข้อหนึ่งต่อไปนี้
- แสดงตัวกรองรูปแบบ Intent ของคอมโพเนนต์และมี CATEGORY_BROWSABLE
- การกระทำนี้เป็นหนึ่งใน ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- เป้าหมายจะปรากฏอย่างชัดเจนด้วย android:visibleToInstantApps
- [C-1-3] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งอย่างชัดเจน เว้นแต่ว่าคอมโพเนนต์จะแสดงผ่าน android:visibleToInstantApps
- [C-1-4] แอปที่ติดตั้งต้องไม่ดูรายละเอียดเกี่ยวกับ Instant Apps ในอุปกรณ์ เว้นแต่ Instant App จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งโดยตรง
การนำอุปกรณ์ไปใช้งานต้องมีค่าใช้จ่ายสำหรับผู้ใช้ดังต่อไปนี้ในการโต้ตอบกับ Instant Apps AOSP ตรงตามข้อกำหนดของ UI, การตั้งค่า และ Launcher เริ่มต้น การติดตั้งใช้งานอุปกรณ์
- [C-1-5] ต้องมีค่าใช้จ่ายให้กับผู้ใช้ในการดูและลบ Instant App ที่แคชไว้ในเครื่องสำหรับแพ็กเกจแอปแต่ละรายการ
- [C-1-6] ต้องระบุการแจ้งเตือนผู้ใช้ถาวรที่สามารถยุบได้ขณะที่ Instant App ทำงานอยู่ในเบื้องหน้า การแจ้งเตือนผู้ใช้นี้ต้องระบุว่า Instant Apps ไม่ต้องมีการติดตั้ง
และมอบค่าตอบแทนของผู้ใช้ที่จะนำผู้ใช้ไปยังหน้าจอข้อมูลแอปพลิเคชันในการตั้งค่า สำหรับ Instant App ที่เปิดผ่าน Intent ของเว็บ ตามที่กำหนดโดยการใช้ Intent ที่ตั้งค่าการดำเนินการเป็น
Intent.ACTION_VIEW
และในรูปแบบ "http" หรือ "https" การจ่ายเงินเพิ่มเติมสำหรับผู้ใช้ควรอนุญาตให้ผู้ใช้ไม่ต้องเปิด Instant App และเปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กำหนดค่าไว้ในอุปกรณ์หากมีเบราว์เซอร์ - [C-1-7] ต้องอนุญาตให้เรียกใช้ Instant App จากฟังก์ชัน "ล่าสุด" หากมีฟังก์ชัน "ล่าสุด" ในอุปกรณ์
[C-1-8] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับ Intent ที่ระบุไว้ใน SDK ที่นี่ และแสดง Intent ของ Instant Apps ได้
3.16 การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
Android รองรับการจับคู่อุปกรณ์ที่ใช้ร่วมกันเพื่อให้จัดการการเชื่อมโยงกับอุปกรณ์ที่ใช้ร่วมกันได้อย่างมีประสิทธิภาพมากขึ้น และมี API CompanionDeviceManager
ให้แอปต่างๆ เข้าถึงฟีเจอร์นี้
หากการใช้งานอุปกรณ์รองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน การใช้งานจะมีลักษณะดังนี้
- [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
ที่แอปกำหนด และต้องไม่เปลี่ยนลักษณะการทำงานของแอปตามแอตทริบิวต์ดังกล่าว
3.18 รายชื่อติดต่อ
Android มี Contacts
Provider
API ที่ช่วยให้แอปพลิเคชันจัดการข้อมูลติดต่อที่จัดเก็บไว้ในอุปกรณ์ได้
โดยทั่วไปแล้ว ข้อมูลรายชื่อติดต่อที่ป้อนในอุปกรณ์โดยตรงจะซิงค์กับบริการบนเว็บ แต่ข้อมูลดังกล่าวอาจอยู่ในตัวอุปกรณ์เท่านั้น
รายชื่อติดต่อที่จัดเก็บไว้ในอุปกรณ์เท่านั้นจะเรียกว่ารายชื่อติดต่อภายใน
RawContacts
มีการ "เชื่อมโยง" หรือ "จัดเก็บไว้ใน"
บัญชี
เมื่อคอลัมน์
ACCOUNT_NAME
และ
ACCOUNT_TYPE
ข้อมูลรายชื่อติดต่อดิบตรงกับ
Account.name
และ
Account.type
ที่เกี่ยวข้อง
บัญชีเริ่มต้นในเครื่อง: บัญชีสำหรับรายชื่อติดต่อดิบที่เก็บอยู่ในอุปกรณ์เท่านั้น และไม่ได้เชื่อมโยงกับบัญชีใน Account Manager ซึ่งสร้างด้วยค่า null สำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
บัญชีในเครื่องที่กำหนดเอง: บัญชีสำหรับรายชื่อติดต่อแบบข้อมูลดิบที่จัดเก็บในอุปกรณ์เท่านั้นและไม่ได้เชื่อมโยงกับ "บัญชี" ใน AccountManager ซึ่งสร้างขึ้นด้วยค่าที่ไม่ใช่ Null อย่างน้อย 1 ค่าสำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าสร้างบัญชีในพื้นที่ที่กำหนดเอง
หากการใช้อุปกรณ์ใช้บัญชีในเครื่องที่กำหนดเอง ให้ทำดังนี้
- [C-1-1]
ACCOUNT_NAME
ของบัญชีในเครื่องที่กำหนดเองต้องส่งคืนภายในวันที่ContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
ของบัญชีในเครื่องที่กำหนดเองต้องส่งคืนภายในวันที่ContactsContract.RawContacts.getLocalAccountType
- [C-1-3] รายชื่อติดต่อดิบที่แทรกโดยแอปพลิเคชันของบุคคลที่สามที่มีบัญชีในเครื่องเริ่มต้น (เช่น โดยกำหนดค่า null สำหรับ
ACCOUNT_NAME
และACCOUNT_TYPE
) ต้องแทรกลงในบัญชีในเครื่องที่กำหนดเอง - [C-1-4] ต้องไม่นำรายชื่อติดต่อดิบที่แทรกลงในบัญชีในเครื่องที่กำหนดเองออกเมื่อเพิ่มหรือนำบัญชีออก
- [C-1-5] การดำเนินการลบที่ดำเนินการกับบัญชีในเครื่องที่กำหนดเอง
ต้องทำให้ระบบลบรายชื่อติดต่อดิบอย่างถาวรทันที (เหมือนกับว่าพารามิเตอร์
CALLER_IS_SYNCADAPTER
ได้รับการตั้งค่าเป็นจริง) แม้ว่าพารามิเตอร์CALLER\_IS\_SYNCADAPTER
จะตั้งค่าเป็น "เท็จ" หรือไม่ได้ระบุ
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ ซึ่งสร้างโดยเครื่องมือ “aapt” ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ
- เนื่องจากข้อกำหนดข้างต้นอาจมีความท้าทาย เราจึงขอแนะนำให้ติดตั้งใช้งานอุปกรณ์โดยใช้ระบบจัดการแพ็กเกจของการใช้งานการอ้างอิง AOSP
[C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 และ JAR Signing
[C-0-3] ต้องไม่ขยาย .apk, Android Manifest, Dalvik bytescode หรือ RenderScript ไบต์โค้ดในรูปแบบที่จะทำให้ไฟล์เหล่านั้นติดตั้งและทำงานอย่างไม่ถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้
[C-0-4] ต้องไม่อนุญาตให้แอปอื่นนอกเหนือจาก "โปรแกรมติดตั้งระเบียน" ปัจจุบันของแพ็กเกจทำการถอนการติดตั้งแอปโดยไม่มีการยืนยันจากผู้ใช้ ตามที่ระบุไว้ใน SDK สำหรับสิทธิ์
DELETE_PACKAGE
ข้อยกเว้นเดียวคือแอปของผู้ยืนยันแพ็กเกจระบบที่จัดการ ความตั้งใจ PACKAGE_NEEDS_VERIFICATION และแอปของตัวจัดการพื้นที่เก็บข้อมูลที่ใช้จัดการ ACTION_MANAGE_STORAGE[C-0-5] ต้องมีกิจกรรมที่จัดการความตั้งใจของ
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
ว่าอาจเป็นอันตรายควรเสนอทางเลือกแก่ผู้ใช้ในการเลือกที่จะถอนการติดตั้งหรือเปิดแอปพลิเคชันในหน้าคำเตือน
[C-0-8] ต้องใช้การรองรับระบบไฟล์ส่วนเพิ่มตามเอกสารประกอบที่นี่
[C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4 และ APK Signature Scheme v4.1
5. ความเข้ากันได้กับมัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับรูปแบบสื่อ โปรแกรมเปลี่ยนไฟล์ โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในส่วน 5.1 สำหรับตัวแปลงรหัสทุกตัวที่
MediaCodecList
ประกาศ - [C-0-2] ต้องประกาศและรายงานการรองรับโปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสที่มีสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน
MediaCodecList
- [C-0-3] ต้องสามารถถอดรหัสและทำให้แอปของบุคคลที่สามใช้งานได้ทุกรูปแบบที่สามารถเข้ารหัสได้ ซึ่งรวมถึงบิตสตรีมทั้งหมดที่โปรแกรมเปลี่ยนไฟล์สร้างขึ้นและโปรไฟล์ที่รายงานใน
CamcorderProfile
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เวลาในการตอบสนองของตัวแปลงรหัสขั้นต่ำ กล่าวคือ
- ไม่ควรใช้และจัดเก็บบัฟเฟอร์อินพุต รวมถึงแสดงผลบัฟเฟอร์อินพุตเมื่อประมวลผลแล้วเท่านั้น
- ไม่ควรเก็บบัฟเฟอร์ที่ถอดรหัสแล้วไว้นานกว่าที่มาตรฐานระบุไว้ (เช่น SPS)
- ไม่ควรเก็บบัฟเฟอร์ที่เข้ารหัสไว้นานกว่าที่โครงสร้าง GOP กำหนด
ตัวแปลงรหัสทั้งหมดที่ระบุไว้ในส่วนด้านล่างมีให้ในรูปแบบของการติดตั้งซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโครงการโอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้รับรองว่าตัวแปลงรหัสเหล่านี้ไม่มีสิทธิบัตรของบุคคลที่สาม เราขอแนะนำผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ซอฟต์แวร์ว่า การใช้งานโค้ดนี้ รวมทั้งซอฟต์แวร์โอเพนซอร์สหรือแชร์แวร์ อาจต้องมีใบอนุญาตสิทธิบัตรจากผู้ถือครองสิทธิบัตรที่เกี่ยวข้อง
5.1 ตัวแปลงสัญญาณสื่อ
5.1.1 การเข้ารหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์ต้องรองรับการเข้ารหัสรูปแบบเสียงต่อไปนี้และทำให้ใช้งานกับแอปของบุคคลที่สามได้
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] โอปัส
โปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดต้องสนับสนุนรายการต่อไปนี้
- [C-3-1] เฟรมเสียงสำหรับสั่งซื้อไบต์ดั้งเดิมของ PCM 16 บิตผ่าน API ของ
android.media.MediaCodec
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 Baseline Profile และ ISO/IEC 23003-4 Dynamic Range Control Profile)
- [C-1-5] FLAC
- MP3 [C-1-6]
- [C-1-7] MIDI
- [C-1-8] เวอร์บี
- [C-1-9] PCM/WAVE รวมรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และช่อง 8 ช่อง โปรดทราบว่าข้อกำหนดนี้มีไว้สำหรับการถอดรหัสเท่านั้น และอนุญาตให้อุปกรณ์ลดตัวอย่างและดาวน์มิกซ์ได้ในระยะการเล่น
- [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
- [C-SR-1] เราขอแนะนำเป็นอย่างยิ่งว่าตัวถอดรหัสเสียง AAC ทั้งหมดเป็นไปตามข้อกำหนด C-2-1 และ C-2-2 ข้างต้น
เมื่อถอดรหัสเสียง 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 จะมีความสำคัญเหนือกว่า
ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุต:
- [C-6-1] เฟรมเสียงสำหรับสั่งซื้อไบต์ดั้งเดิมของ PCM 16 บิตผ่าน API ของ
android.media.MediaCodec
หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมแบบหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านตัวถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec
API ต้องมีการรองรับรายการต่อไปนี้
- [C-7-1] ต้องสามารถกำหนดค่าโดยแอปพลิเคชันโดยใช้การถอดรหัสด้วยคีย์
KEY_MAX_OUTPUT_CHANNEL_COUNT
เพื่อควบคุมว่าจะให้เนื้อหาดาวน์มิกซ์เป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือเอาต์พุตโดยใช้จำนวนช่องเสียงดั้งเดิม (เมื่อใช้ค่าที่เท่ากับหรือมากกว่าตัวเลขดังกล่าว) เช่น ค่า 6 ขึ้นไปจะกำหนดค่าตัวถอดรหัสให้เอาต์พุต 6 ช่องสัญญาณเมื่อป้อนเนื้อหา 5.1 - [C-7-2] เมื่อถอดรหัส ตัวถอดรหัสต้องโฆษณามาสก์ช่องทางที่ใช้ในรูปแบบเอาต์พุตด้วยคีย์
KEY_CHANNEL_MASK
โดยใช้ค่าคงที่android.media.AudioFormat
(เช่นCHANNEL_OUT_5POINT1
)
หากการใช้งานอุปกรณ์รองรับตัวถอดรหัสเสียงอื่นที่ไม่ใช่ตัวถอดรหัสเสียง AAC ที่เป็นค่าเริ่มต้นและสามารถเอาต์พุตเสียงแบบหลายช่องได้ (มากกว่า 2 ช่อง) เมื่อป้อนเนื้อหาแบบหลายช่องที่มีการบีบอัดแล้ว ให้ทำดังนี้
- [C-SR-2] เราขอแนะนำเป็นอย่างยิ่งให้แอปพลิเคชันกำหนดค่าตัวถอดรหัสได้โดยใช้การถอดรหัสด้วยคีย์
KEY_MAX_OUTPUT_CHANNEL_COUNT
เพื่อควบคุมว่าจะให้เนื้อหาดาวน์มิกซ์เป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือเอาต์พุตโดยใช้จำนวนช่องเสียงดั้งเดิม (เมื่อใช้ค่าที่เท่ากับหรือมากกว่าตัวเลขดังกล่าว) เช่น ค่า 6 ขึ้นไปจะกำหนดค่าตัวถอดรหัสให้เอาต์พุต 6 ช่องสัญญาณเมื่อป้อนเนื้อหา 5.1 - [C-SR-3] เมื่อถอดรหัส เราขอแนะนำตัวถอดรหัสให้โฆษณามาสก์ช่องทางที่ใช้ในรูปแบบเอาต์พุตด้วยคีย์
KEY_CHANNEL_MASK
โดยใช้ค่าคงที่ android.media.AudioFormat (เช่นCHANNEL_OUT_5POINT1
)
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 ตามที่ระบุไว้ใน AMR-WB, Adaptive Multi-Rate - Wide Band Speech Codec | 3GPP (.3gp) |
FLAC | สำหรับทั้งโปรแกรมเปลี่ยนไฟล์และเครื่องถอดรหัส: ต้องมีการรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย รองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง 24 บิตของ FLAC ต้องใช้งานได้กับการกำหนดค่าเสียงแบบลอย |
|
MP3 | ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR) |
|
MIDI | MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ XMF สำหรับอุปกรณ์เคลื่อนที่ รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody |
|
Vorbis |
|
|
PCM/WAVE | ตัวแปลงรหัส PCM ต้องรองรับ PCM เชิงเส้น 16 บิตและแบบลอย 16 บิต เครื่องมือแยก WAVE ต้องรองรับ PCM เชิงเส้น 16 บิต, 24 บิต, 32 บิต และลอยตัว 32 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อัตราการสุ่มตัวอย่างต้องรองรับตั้งแต่ 8 kHz ถึง 192 kHz | WAVE (.wav) |
Opus | การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz
การเข้ารหัส: รองรับเนื้อหาโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 1400, 1200 และ 1200 Hz |
|
5.1.4 การเข้ารหัสรูปภาพ
ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ
การใช้งานอุปกรณ์ต้องรองรับการเข้ารหัสการเข้ารหัสรูปภาพต่อไปนี้
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
หากการใช้งานอุปกรณ์รองรับการเข้ารหัส HEIC ผ่าน android.media.MediaCodec
สำหรับประเภทสื่อ MIMETYPE_IMAGE_ANDROID_HEIC
จะมีการดำเนินการต่อไปนี้
- [C-1-1] ต้องมีตัวแปลงรหัสโปรแกรมเปลี่ยนไฟล์ HEVC แบบเร่งฮาร์ดแวร์ที่รองรับ
BITRATE_MODE_CQ
โหมดควบคุมอัตราบิต โปรไฟล์HEVCProfileMainStill
และเฟรมขนาด 512 x 512 พิกเซล
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] ดิบ
หากอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC * [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)
ตัวถอดรหัสรูปภาพที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง):
- [C-2-1] ต้องรองรับเอาต์พุตรูปแบบเทียบเท่า 8 บิตหากแอปพลิเคชันขอ เช่น ผ่านการกำหนดค่า
ARGB_8888
ของandroid.graphics.Bitmap
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) |
โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API
[C-1-1] ต้องรองรับรูปแบบสีที่ปรับเปลี่ยนได้ YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) จนถึงCodecCapabilities
[C-SR-1] แนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับโหมดพื้นผิวของอินพุต
[C-1-3] ต้องรองรับรูปแบบสี YUV420 8:8:8 อย่างน้อย 1 รูปแบบ:
COLOR_FormatYUV420PackedPlanar
(เทียบเท่ากับCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่ากับCOLOR_FormatYUV420SemiPlanar
) ขอแนะนำให้รองรับทั้ง 2 รูปแบบ
5.1.7 ตัวแปลงรหัสวิดีโอ
- เพื่อคุณภาพที่ยอมรับได้ของบริการสตรีมมิงวิดีโอบนเว็บและบริการประชุมทางวิดีโอ การใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนด
หากการใช้งานอุปกรณ์มีตัวถอดรหัสวิดีโอหรือโปรแกรมเปลี่ยนไฟล์
[C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดเอาต์พุตและไบต์บัฟเฟอร์อินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดขนาดใหญ่ที่สุดตามที่มาตรฐานและการกำหนดค่ากำหนดไว้ แต่ยังไม่ครอบคลุมไฟล์โดยรวม
[C-1-2] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) ถึงCodecCapabilities
[C-1-3] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบระนาบหรือแบบกึ่งฉากอย่างน้อย 1 รายการ:
COLOR_FormatYUV420PackedPlanar
(เทียบเท่ากับCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่ากับCOLOR_FormatYUV420SemiPlanar
) เราขอแนะนำเป็นอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ[C-SR-1] เราขอแนะนำเป็นอย่างยิ่งให้ใช้โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอเพื่อรองรับรูปแบบสี YUV420 8:8:8 แบบ YUV420 8:8:8 อย่างน้อย 1 รูปแบบ หรือรูปแบบสีสำหรับผู้ให้บริการที่เทียบเท่ากัน)
[C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง) ต้องรองรับเอาต์พุตในรูปแบบ 8 บิตที่เทียบเท่ากันหากแอปพลิเคชันขอ ค่านี้ต้องแสดงโดยการรองรับรูปแบบสี YUV420 8:8:8 ผ่าน
android.media.MediaCodecInfo
การติดตั้งใช้งานอุปกรณ์ที่โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities
จะมีผลดังนี้
- [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ HDR
หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh
ในชั้นเรียน MediaCodecInfo.CodecCapabilities
การดำเนินการต่อไปนี้
- [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10 - 60 เฟรมและทำงานอย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้
การติดตั้งใช้งานตัวถอดรหัสวิดีโอ เว้นแต่แอปพลิเคชันจะระบุไว้เป็นอย่างอื่นโดยใช้คีย์รูปแบบ KEY_COLOR_FORMAT
- [C-4-1] ต้องใช้รูปแบบสีที่เพิ่มประสิทธิภาพสำหรับจอแสดงผลของฮาร์ดแวร์โดยค่าเริ่มต้น หากกำหนดค่าโดยใช้เอาต์พุต Surface
- [C-4-2] ต้องมีค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพสำหรับการอ่านของ CPU หากกำหนดค่าไม่ให้ใช้เอาต์พุต Surface
5.1.8 รายการตัวแปลงรหัสวิดีโอ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ |
---|---|---|
H.263 |
|
|
H.264 AVC | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
HEVC ของ H.265 | ดูรายละเอียดในส่วนที่ 5.3 |
|
MPEG-2 | โปรไฟล์หลัก |
|
MPEG-4 SP |
|
|
VP8 | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
VP9 | ดูรายละเอียดในส่วนที่ 5.3 |
|
5.1.9 ความปลอดภัยของตัวแปลงรหัสสื่อ
การใช้งานอุปกรณ์ต้องแน่ใจถึงการปฏิบัติตามข้อกำหนดของฟีเจอร์ความปลอดภัยของตัวแปลงรหัสสื่อตามที่อธิบายด้านล่าง
Android รองรับ OMX ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม และตัวแปลงรหัส 2.0 ซึ่งเป็น API การเร่งสื่อมัลติมีเดียแบบโอเวอร์เฮดต่ำ
หากการใช้งานอุปกรณ์รองรับมัลติมีเดีย จะมีผลดังนี้
- [C-1-1] ต้องให้การสนับสนุนตัวแปลงรหัสสื่อผ่าน OMX หรือ Codec 2.0 API (หรือทั้ง 2 อย่าง) เช่น ในโครงการโอเพนซอร์ส Android และต้องไม่ปิดใช้หรือหลบเลี่ยงการรักษาความปลอดภัย ซึ่งไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API ต้องรองรับ API เหล่านี้อย่างน้อย 1 ตัวเท่านั้น และการรองรับ API ที่ใช้ได้ต้องมีการป้องกันความปลอดภัยด้วย
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการสนับสนุนตัวแปลงรหัส 2.0 API
หากการใช้งานอุปกรณ์ไม่รองรับตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้
- [C-2-1] ต้องรวมตัวแปลงรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจากโปรเจ็กต์โอเพนซอร์ส Android (หากมี) สำหรับสื่อแต่ละรูปแบบและประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
- [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องใช้ซอร์สโค้ดของ โครงการโอเพนซอร์ส Android
- [C-SR-2] ขอแนะนำเป็นอย่างยิ่งว่าตัวแปลงรหัสซอฟต์แวร์ OMX จะทำงานในกระบวนการของตัวแปลงรหัสที่ไม่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากโปรแกรมแมปหน่วยความจำ
หากอุปกรณ์รองรับตัวแปลงรหัสตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้
- [C-3-1] ต้องรวมตัวแปลงรหัสของซอฟต์แวร์ Codec 2.0 ที่เกี่ยวข้องจาก โครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและสื่อแต่ละประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
- [C-3-2] ต้องจัดเก็บตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ในกระบวนการของตัวแปลงสัญญาณซอฟต์แวร์ตามที่ระบุไว้ในโครงการโอเพนซอร์ส Android เพื่อให้สามารถให้สิทธิ์เข้าถึงตัวแปลงรหัสซอฟต์แวร์ได้อย่างแคบลง
- [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android" ต้องใช้ซอร์สโค้ดของ โครงการโอเพนซอร์ส Android
5.1.10 การจำแนกลักษณะของตัวแปลงรหัสสื่อ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ ตัวแปลงสัญญาณต่อไปนี้
- [C-1-1] ต้องส่งค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่าน API ของ
MediaCodecInfo
โดยเฉพาะอย่างยิ่งในเรื่องต่อไปนี้
- [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อ OMX IL
- [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ API ของ Codec 2.0 และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของ Codec 2.0 สำหรับ Android
- [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." หรือ "c2.android" ต้องไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นการเร่งฮาร์ดแวร์
- [C-1-5] ตัวแปลงรหัสที่ทำงานในกระบวนการของตัวแปลงรหัส (ผู้ให้บริการหรือระบบ) ที่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากผู้จัดสรรหน่วยความจำและผู้ทำแผนที่ต้อง ไม่มีลักษณะเป็นเฉพาะซอฟต์แวร์เท่านั้น
- [C-1-6] ตัวแปลงรหัสที่ไม่มีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android หรือไม่ได้อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องอยู่ในรูปแบบผู้ให้บริการ
- [C-1-7] ตัวแปลงรหัสที่ใช้การเร่งฮาร์ดแวร์จะต้องมีลักษณะ เป็นเร่งฮาร์ดแวร์
- [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด เช่น ตัวแปลงรหัสที่ชื่อว่า "ตัวถอดรหัส" ต้องรองรับการถอดรหัส ส่วนตัวแปลงรหัสที่ชื่อว่า "โปรแกรมเปลี่ยนไฟล์" ต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อที่มีรูปแบบสื่อต้องรองรับรูปแบบเหล่านั้น
หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัสวิดีโอ ให้ทำดังนี้
- [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ |
|
|
|
1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4) | 3840 x 2160 พิกเซล (HEVC, VP9) |
- [C-2-2] ตัวแปลงสัญญาณวิดีโอที่มีลักษณะเป็นการเร่งฮาร์ดแวร์ จะต้องเผยแพร่ข้อมูลจุดประสิทธิภาพ โดยจะต้องระบุคะแนนประสิทธิภาพมาตรฐานที่รองรับทั้งหมด (ระบุไว้ใน
PerformancePoint
API) เว้นแต่ว่าคะแนนประสิทธิภาพมาตรฐานอื่นๆ ที่รองรับจะอยู่ภายใต้เกณฑ์ดังกล่าว - นอกจากนี้ ผู้ลงโฆษณาควรเผยแพร่คะแนนประสิทธิภาพเพิ่มเติม หากสนับสนุนประสิทธิภาพของวิดีโอที่ยั่งยืนนอกเหนือจากประสิทธิภาพมาตรฐานที่ระบุไว้
5.2 การเข้ารหัสวิดีโอ
หากอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอและทำให้แอปของบุคคลที่สามใช้งานได้
- ไม่ควรเกิน 15% ของอัตราบิตระหว่างช่วงเวลาภายในเฟรม (I-Frame) บนหน้าต่างเลื่อน 2 หน้าต่าง
- ไม่ควรเกิน 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 และทำให้แอปของบุคคลที่สามใช้งานได้
- ควรสนับสนุนอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่สนับสนุน
หากการใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์สำหรับวิดีโอหรือรูปภาพที่เร่งการแสดงผลด้วยฮาร์ดแวร์ และรองรับกล้องฮาร์ดแวร์ที่ติดหรือเชื่อมต่อได้อย่างน้อย 1 ตัวที่เปิดเผยผ่าน API ของ android.camera
- [C-4-1] โปรแกรมเปลี่ยนไฟล์และรูปภาพวิดีโอที่เร่งการแสดงผลด้วยฮาร์ดแวร์ทั้งหมดต้องรองรับ การเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์
- ควรรองรับเฟรมการเข้ารหัสจากกล้องฮาร์ดแวร์ผ่านโปรแกรมเปลี่ยนไฟล์วิดีโอหรือรูปภาพทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์มีการเข้ารหัส HDR สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุปลั๊กอินสำหรับ API การแปลงที่ราบรื่นเพื่อแปลงจากรูปแบบ HDR เป็นรูปแบบ SDR
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 อื่นๆ เพื่อคงการใช้งานร่วมกับอุปกรณ์ 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
- ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (ความละเอียดสูง) ต่อไปนี้
- [C-1-2] ต้องรองรับการเขียนไฟล์ 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 อุปกรณ์จะทำงานดังนี้
- [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
- [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
- [C-1-3] ต้องสร้างข้อมูล CodecPrivate
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
- เราขอแนะนำเป็นอย่างยิ่งว่า [C-SR-1] จะรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการใช้อุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน API สื่อ
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ
5.2.5 H.265
หากอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
- ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
- เราขอแนะนำเป็นอย่างยิ่งว่า [C-SR-1] จะรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.3 การถอดรหัสวิดีโอ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับความละเอียดของวิดีโอแบบไดนามิกและการเปลี่ยนอัตราเฟรมผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดในแบบเรียลไทม์และสูงสุดถึงความละเอียดสูงสุดที่ตัวแปลงรหัสแต่ละตัวบนอุปกรณ์รองรับ
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 |
หากการนำอุปกรณ์ไปใช้งานอ้างว่ารองรับโปรไฟล์ HDR ผ่าน Media API
- [C-3-1] การใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็นจากแอปพลิเคชัน รวมถึงรองรับการแยกและส่งออกข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์
- [C-3-2] การใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR อย่างถูกต้องในหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
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 |
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2
หรือ VP9Profile3
ผ่าน API สื่อ "CodecProfileLevel"
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ
หากการนำอุปกรณ์ไปใช้งานอ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) ผ่าน API สื่อ ให้ทำดังนี้
- [C-4-1] การใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็น
(
KEY_HDR_STATIC_INFO
สำหรับโปรไฟล์ HDR ทั้งหมดและ "KEY_HDR10_PLUS_INFO" สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชัน นอกจากนี้ยังต้องรองรับการแยกและเอาต์พุตข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์ - [C-4-2] การใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR อย่างถูกต้องในหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
5.3.8 Dolby Vision
หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION
ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องมีอุปกรณ์แยกที่รองรับ Dolby Vision
- [C-1-2] ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องในหน้าจอของอุปกรณ์หรือ บนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
- [C-1-3] ต้องตั้งค่ารหัสแทร็กของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับรหัสแทร็กของเลเยอร์ Dolby Vision แบบรวม
5.3.9 AV1
หากอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์ 0 ที่รวมเนื้อหาแบบ 10 บิต
5.4 การบันทึกเสียง
แม้ว่าข้อกำหนดบางส่วนที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" ตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" เราแนะนำให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้ที่ระบุว่า "ควร" หรือจะไม่สามารถใช้กับ Android เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
5.4.1 การบันทึกเสียงและข้อมูลไมโครโฟนแบบข้อมูลดิบ
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
[C-1-1] ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบสำหรับสตรีม
AudioRecord
หรือAAudio
INPUT ที่เปิดได้สำเร็จ อย่างน้อยที่สุด ต้องมีการสนับสนุนลักษณะต่อไปนี้:- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
- ช่องสัญญาณ: โมโน
- แหล่งที่มาของเสียง:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
หรือVOICE_PERFORMANCE
และยังใช้กับค่าที่กำหนดล่วงหน้าซึ่งเทียบเท่ากับอินพุตในAAudio
ด้วย เช่นAAUDIO_INPUT_PRESET_CAMCORDER
ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต และ 24 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- ช่องสัญญาณ: กี่ช่องเท่ากับจำนวนไมโครโฟนบนอุปกรณ์
[C-1-2] ต้องจับอัตราการสุ่มตัวอย่างสูงกว่าโดยไม่มีการสุ่มตัวอย่าง
[C-1-3] ต้องระบุตัวกรองการลบรอยหยักที่เหมาะสมเมื่ออัตราการสุ่มตัวอย่างที่ระบุข้างต้นได้รับการบันทึกในการสุ่มตัวอย่าง
ควรอนุญาตให้มีการบันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ ซึ่งหมายถึงลักษณะเฉพาะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
- ช่องสัญญาณ: สเตอริโอ
[C-1-4] ต้องใช้
MicrophoneInfo
API และกรอกข้อมูลอย่างเหมาะสมสำหรับไมโครโฟนที่พร้อมใช้งานบนอุปกรณ์ ที่แอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านAudioManager.getMicrophones()
API สำหรับ AudioRecord ที่ใช้งานอยู่โดยใช้MediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
หรือVOICE_PERFORMANCE
หากการใช้อุปกรณ์อนุญาตให้บันทึกคุณภาพวิทยุและดีวีดี 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
ควรแสดงคุณสมบัติแอมพลิจูดความถี่ราบโดยประมาณในช่วงความถี่กลางๆ โดยเฉพาะ ±3dB ตั้งแต่ 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัว และทุกไมโครโฟนที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
[C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งตั้งแต่ ±20 dB ตั้งแต่ 30 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
[C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL อินพุตแบบเชิงเส้นที่ช่วง -18 dB ถึง +12 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.4.4 อุปกรณ์ตัดเสียงก้อง
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
- ควรใช้เทคโนโลยี Acoural EchoCanceler (AEC) ที่ปรับแต่งเพื่อการสื่อสารด้วยเสียงและใช้กับเส้นทางการจับภาพ
เมื่อจับภาพโดยใช้
AudioSource.VOICE_COMMUNICATION
หากการใช้อุปกรณ์มีตัวยกเลิกเสียงสะท้อนเสียงที่ใส่อยู่ในเส้นทางเสียงเมื่อเลือก AudioSource.VOICE_COMMUNICATION
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-SR-1] เป็น STRONGLY_RECOMMENDED เพื่อประกาศสิ่งนี้ผ่าน Acoการเปิดใช้งานEchoCanceler เมธอด API Acoแสดงความคิดเห็นEchoCanceler.isavailable()
- [C-SR-2] มีค่า STRONGLY_RECOMMENDED เพื่อให้สามารถควบคุมเอฟเฟกต์เสียงนี้ด้วย API AcouralEchoCanceler ได้
- [C-SR-3] คือ STRONGLY_RECOMMENDED เพื่อระบุการใช้งานเทคโนโลยี AEC แต่ละรายการที่ไม่ซ้ำกันผ่านฟิลด์ AudioEffect.Descriptor.uuid
5.4.5 จับภาพพร้อมกัน
หากใช้อุปกรณ์ประกาศ android.hardware.microphone
ก็ต้องใช้การจับภาพพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้
- [C-1-1] ต้องอนุญาตการเข้าถึงไมโครโฟนพร้อมกันโดยบริการการช่วยเหลือพิเศษที่จับภาพด้วย
AudioSource.VOICE_RECOGNITION
และการจับภาพแอปพลิเคชันอย่างน้อย 1 รายการด้วยAudioSource
- [C-1-2] ต้องอนุญาตการเข้าถึงไมโครโฟนพร้อมกันโดยแอปพลิเคชันที่ติดตั้งล่วงหน้าซึ่งมีบทบาท Assistant และแอปพลิเคชันอย่างน้อย 1 รายการที่จับภาพด้วย
AudioSource
ยกเว้นAudioSource.VOICE_COMMUNICATION
หรือAudioSource.CAMCORDER
- [C-1-3] ต้องปิดเสียงการจับภาพสำหรับแอปพลิเคชันอื่นๆ ยกเว้นบริการการช่วยเหลือพิเศษขณะที่แอปพลิเคชันกำลังจับภาพด้วย
AudioSource.VOICE_COMMUNICATION
หรือAudioSource.CAMCORDER
อย่างไรก็ตาม เมื่อแอปกำลังจับภาพผ่านAudioSource.VOICE_COMMUNICATION
แอปอื่นจะจับการโทรด้วยเสียงได้หากเป็นแอปที่ได้รับสิทธิ์ (ติดตั้งล่วงหน้า) ที่มีสิทธิ์CAPTURE_AUDIO_OUTPUT
- [C-1-4] หากแอปพลิเคชัน 2 แอปขึ้นไปจับภาพพร้อมกันและ หากไม่มีแอปใดมี UI อยู่ด้านบน แอปที่เริ่มบันทึกเสียงล่าสุด จะได้รับเสียง
5.4.6 ระดับการรับไมโครโฟน [ย้ายไปที่ 5.4.2]
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, 24000, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
- 96000 ในแบบโมโนและสเตอริโอ
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
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์ในจุดลอยตัวและหลายช่องทาง
5.5.3 ระดับเสียงเอาต์พุตเสียง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- ควรอนุญาตให้ปรับระดับเสียงในแต่ละสตรีมเสียงแยกกันโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย
AudioAttributes
และการใช้งานเสียงในรถยนต์ตามที่เป็นสาธารณะในandroid.car.CarAudioManager
5.5.4 การลดเสียง
หากการใช้งานอุปกรณ์รองรับการเล่นเสียงแบบออฟโหลด ระบบจะดำเนินการต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัดเนื้อหาเสียงที่เล่นแบบไม่ขาดตอนระหว่าง 2 คลิปที่มีรูปแบบเดียวกันเมื่อมีการระบุโดย AudioTrack gapless API และคอนเทนเนอร์สื่อสำหรับ MediaPlayer
5.6 เวลาในการตอบสนองของเสียง
เวลาในการตอบสนองของเสียงคือการหน่วงเวลาที่สัญญาณเสียงส่งผ่านระบบ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองสั้นๆ เพื่อให้ได้เอฟเฟกต์เสียงแบบเรียลไทม์
สำหรับวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้
- เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่มีรหัส PCM และเมื่อเสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ตัวแปลงสัญญาณในอุปกรณ์หรือที่สัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
- เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาระหว่างการเริ่มสตรีมเอาต์พุตและเวลานำเสนอของเฟรมแรกตามการประทับเวลา เมื่อไม่มีการใช้งานระบบเอาต์พุตเสียงและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมต่อๆ มา หลังจากอุปกรณ์เล่นเสียง
- เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างที่ระบบแสดงเสียงไปยังอุปกรณ์ที่ตัวแปลงสัญญาณหรือสัญญาณในอุปกรณ์ผ่านพอร์ต และเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM ที่สอดคล้องกัน
- อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้ไม่ได้หรือใช้งานไม่ได้
- เวลาในการตอบสนองแบบ Cold input ระยะเวลาตั้งแต่เริ่มสตรีมจนถึงตอนได้รับเฟรมแรกที่ถูกต้อง เมื่อระบบอินพุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ มา ขณะอุปกรณ์บันทึกเสียง
- เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่อง และเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง บวกกับช่วงบัฟเฟอร์ 1 ช่วง ระยะบัฟเฟอร์ทำให้แอปมีเวลาในการประมวลผลสัญญาณและเวลาสำหรับแอปเพื่อลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
- API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ที่เกี่ยวข้องกับ PCM OpenSL ES API ภายใน Android NDK
- API เสียงดั้งเดิมของเสียง ชุดของ AAudio API ภายใน Android NDK
- การประทับเวลา คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง ดู AudioTimestamp เพิ่มเติม
- glitch มีการขัดจังหวะชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง โดยทั่วไปจะเกิดจากการบัฟเฟอร์น้อยของเอาต์พุต บัฟเฟอร์มากเกินไปสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนดิจิทัลหรือแอนะล็อก
- หมายถึงส่วนเบี่ยงเบนสัมบูรณ์ ค่าเฉลี่ยของค่าสัมบูรณ์ของค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า
- เวลาในการตอบสนองแบบแตะเพื่อโทนเสียง ช่วงเวลาระหว่างที่แตะหน้าจอจนถึงเวลาที่ได้ยินเสียง ที่เกิดจากการแตะนั้นได้ยินในลำโพง
หากการใช้งานอุปกรณ์ประกาศ android.hardware.audio.output
อุปกรณ์จะต้องเป็นไปตามข้อกําหนดหรือเกินข้อกําหนดต่อไปนี้
- [C-1-1] การประทับเวลาเอาต์พุตที่ได้จาก
AudioTrack.getTimestamp
และ
AAudioStream_getTimestamp
มีความแม่นยำที่ +/- 2 มิลลิวินาที [C-1-2] เวลาในการตอบสนอง เอาต์พุต แบบ Cold 500 มิลลิวินาทีหรือน้อยกว่า
[C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้
AAudioStreamBuilder_openStream()
ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที
หากการใช้งานอุปกรณ์ประกาศว่า android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามหรือเกินข้อกำหนดต่อไปนี้
- [C-SR-1] เวลาในการตอบสนองเอาต์พุตแบบเย็นไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของลำโพง
[C-SR-2] เวลาในการตอบสนองเมื่อแตะโทนเสียงไม่เกิน 80 มิลลิวินาที
[C-SR-4] การประทับเวลาเอาต์พุตที่แสดงผลโดย AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
มีความแม่นยำที่ +/- 1 มิลลิวินาที
หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นหลังจากการปรับเทียบครั้งแรกเมื่อใช้ API เสียงเนทีฟของ AAudio สำหรับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องและเวลาในการตอบสนองแบบ Cold เอาต์พุตบนอุปกรณ์เอาต์พุตเสียงอย่างน้อย 1 เครื่องที่รองรับ ระบบจะดำเนินการดังต่อไปนี้
- [C-SR-5] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์
android.hardware.audio.low_latency
- [C-SR-6] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
- [C-SR-7] ขอแนะนำอย่างยิ่งให้ตรวจสอบให้แน่ใจว่าสำหรับสตรีมที่แสดงผล
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
จากAAudioStream_getPerformanceMode()
ค่าที่AAudioStream_getFramesPerBurst()
แสดงผลน้อยกว่าหรือเท่ากับค่าที่android.media.AudioManager.getProperty(String)
แสดงผลสำหรับคีย์พร็อพเพอร์ตี้AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
หากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน API เสียงแบบ AAudio แบบดั้งเดิม จะมีเงื่อนไขดังนี้
- [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
หากใช้อุปกรณ์รวมถึง android.hardware.microphone
อุปกรณ์จะต้องเป็นไปตามข้อกำหนดเกี่ยวกับอินพุตเสียงต่อไปนี้
[C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลให้เป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงค่าเบี่ยงเบนไปจากค่าที่ถูกต้อง[C-3-2] เวลาในการตอบสนองอินพุตแบบ Cold 500 มิลลิวินาทีหรือน้อยกว่า
[C-3-3] การเปิดสตรีมอินพุตโดยใช้
AAudioStreamBuilder_openStream()
ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที
หากการใช้งานอุปกรณ์รวม android.hardware.microphone
ด้วย เราขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดของอินพุตเสียงเหล่านี้
[C-SR-8] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลไมโครโฟน
[C-SR-11] จำกัดข้อผิดพลาดในการประทับเวลาของอินพุต ตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลให้เป็น +/- 1 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output
และ android.hardware.microphone
นโยบายจะมีลักษณะดังนี้
- [C-SR-12] ขอแนะนำเป็นอย่างยิ่งให้มีเวลาในการตอบสนองเฉลี่ยอย่างต่อเนื่องอยู่ที่ 50 มิลลิวินาทีหรือน้อยกว่าในการวัด 5 ครั้ง โดยมีค่าเบี่ยงเบนเฉลี่ยต่ำกว่า 10 มิลลิวินาทีสำหรับเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
5.7 โปรโตคอลเครือข่าย
การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุในเอกสารประกอบของ Android SDK
การใช้งานอุปกรณ์จะต้องรองรับตัวแปลงรหัสและคอนเทนเนอร์แต่ละรูปแบบ ดังนี้
[C-1-1] ต้องรองรับตัวแปลงรหัสหรือคอนเทนเนอร์ผ่าน HTTP และ HTTPS
[C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่สอดคล้องกันดังที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านทางโปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7
[C-1-3] ต้องรองรับรูปแบบเพย์โหลด RTSP ที่เกี่ยวข้อง ดังที่แสดงในตาราง RTSP ด้านล่าง สำหรับข้อยกเว้น โปรดดูเชิงอรรถของตารางในส่วนที่ 5.1
รูปแบบกลุ่มสื่อ
รูปแบบกลุ่ม | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
สตรีมส่ง MPEG-2 | ISO 13818 |
ตัวแปลงรหัสวิดีโอ:
และ MPEG-2 ในหัวข้อ 5.1.8 ตัวแปลงสัญญาณเสียง:
|
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 | ISO 13818-7 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.1 |
WebVTT | WebVTT |
RTSP (RTP, SDP)
ชื่อโปรไฟล์ | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
H264 AVC | RFC 6184 | ดูรายละเอียดเกี่ยวกับ H264 AVC ในหัวข้อ 5.1.8 |
MP4A-ลาตินอเมริกา | RFC 6416 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.3 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
ดูรายละเอียดเกี่ยวกับ H263 ในส่วนที่ 5.1.8 |
H263-2000 | RFC 4629 | ดูรายละเอียดเกี่ยวกับ H263 ในส่วนที่ 5.1.8 |
AMR | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-NB ในส่วนที่ 5.1.3 |
AMR-WB | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-WB ในส่วนที่ 5.1.3 |
MP4V-ES | RFC 6416 | ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ในส่วน 5.1.8 |
Mpeg4-ทั่วไป | RFC 3640 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.3 |
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
- MIDI ผ่าน Bluetooth LE ดำเนินการในบทบาทหลัก ส่วนที่ 7.4.3
[C-1-2] ต้องรองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน)
[C-1-3] ต้องรวม libamidi.so (การรองรับ MIDI ของระบบ)
ควรรองรับ MIDI ผ่านโหมดอุปกรณ์ต่อพ่วง USB ส่วนที่ 7.7
5.10 เสียงระดับมืออาชีพ
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro
ผ่านคลาส android.content.pm.PackageManager การดำเนินการดังกล่าวจะมีผลดังนี้
- [C-1-1] ต้องรายงานการรองรับฟีเจอร์
android.hardware.audio.low_latency
- [C-1-2] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องตามที่กำหนดไว้ในส่วน 5.6 เวลาในการตอบสนองของเสียงที่ 25 มิลลิวินาทีหรือน้อยกว่าจากเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
- [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
- [C-1-4] ต้องรายงานการรองรับฟีเจอร์
android.software.midi
- [C-1-5] ต้องเป็นไปตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียงแบบ USB ที่ใช้ API เสียงดั้งเดิมของ AAudio และ
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
- [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
- [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า
- [C-1-8] ต้องมีเวลาในการตอบสนอง "แตะเพื่อโทนเสียง" โดยเฉลี่ยอยู่ที่ 80 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดค่าระหว่างลำโพงสู่ไมโครโฟนอย่างน้อย 5 ครั้ง
- [C-SR-1] แนะนำให้ทำให้สอดคล้องกับเวลาในการตอบสนองตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ที่ความเร็ว 20 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดที่มีค่าเบี่ยงเบนเฉลี่ยค่าสัมบูรณ์น้อยกว่า 5 มิลลิวินาทีในเส้นทางไมโครโฟนระหว่างลำโพง
- [C-SR-2] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับ Pro สำหรับเวลาในการตอบสนองของเสียงไป-กลับที่ต่อเนื่อง เวลาในการตอบสนองของอินพุตที่เย็น เวลาในการตอบสนองที่ต่ำ และข้อกำหนดเสียง USB โดยใช้ API เสียงเนทีฟ AAudio ผ่านเส้นทาง MMAP
[C-SR-3] แนะนำอย่างยิ่งเพื่อคงประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและโหลดของ CPU แตกต่างกันไป ซึ่งควรทดสอบโดยใช้แอป Android SynthMark SynthMark ใช้ซอฟต์แวร์สังเคราะห์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองที่วัดประสิทธิภาพของระบบ ดูคำอธิบายการเปรียบเทียบได้ในเอกสาร SynthMark แอป SynthMark จำเป็นต้องเรียกใช้โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
- Voicemark.90 >= 32 เสียง
- เวลาในการตอบสนองmark.fixed.little <= 15 มิลลิวินาที
- เวลาในการตอบสนองmark.dynamic.little <= 50 มิลลิวินาที
ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
ควรลดการเลื่อนของนาฬิกาเสียงให้สัมพันธ์กับ CPU
CLOCK_MONOTONIC
เมื่อทำงานอยู่ทั้ง 2 อย่างควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
ควรบันทึกการวัดค่าเวลาในการตอบสนองของเสียงในทุกเส้นทาง
ควรลด Jitter ในเวลาป้อน Callback ให้เสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน
ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
ควรระบุความแตกต่างของเวลานาฬิกาเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงบนอุปกรณ์ หรืออินพุตและเอาต์พุตช่องเสียบหูฟัง
ควรจัดการ Callback ที่เสร็จสมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องในเทรดเดียวกันเมื่อใช้งานอยู่ และป้อน Callback เอาต์พุตทันทีหลังจากการเรียกกลับอินพุต หรือหากจัดการ Callback ในเทรดเดียวกันไม่ได้ ให้ป้อน Callback เอาต์พุตหลังจากป้อน Callback ของอินพุตเพื่ออนุญาตให้แอปพลิเคชันกำหนดเวลาด้านอินพุตและเอาต์พุตที่สอดคล้องกัน
ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง
ควรลดเวลาในการตอบสนองของการแตะ
ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด ระบบจะดำเนินการดังต่อไปนี้
- [C-SR-4] แนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์
android.hardware.audio.pro
ผ่านคลาสandroid.content.pm.PackageManager
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว จะมีผลดังนี้
- [C-2-1] ต้องมีค่าเฉลี่ยเวลาในการตอบสนองของเสียงไป-กลับแบบต่อเนื่องตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ที่ไม่เกิน 20 มิลลิวินาที และมากกว่า 5 ค่าที่มีค่าเฉลี่ยเบี่ยงเบนเฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางช่องเสียบเสียงโดยใช้ดองเกิลการวนกลับของเสียง
- [C-SR-5] แนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดของอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อมูลจำเพาะของชุดหูฟังสำหรับระบบเสียงแบบมีสาย (v1.1)
หากอุปกรณ์ไม่มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB รายการต่อไปนี้
- [C-3-1] ต้องใช้คลาสเสียง USB
- [C-3-2] ต้องมีค่าตอบสนองเฉลี่ยของเสียงไป-กลับแบบต่อเนื่องไม่เกิน 25 มิลลิวินาที หรือค่าเบี่ยงเบนเฉลี่ย 5 ค่าที่มีค่าเบี่ยงเบนเฉลี่ยน้อยกว่า 5 มิลลิวินาทีสำหรับพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB ที่ใช้คลาสเสียง USB (วัดได้โดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์ที่เชื่อมต่ออินพุตกับเอาต์พุต)
- [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 ช่องในแต่ละทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิตเมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้
- [C-SR-7] เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ AAudio Native Audio API ผ่านเส้นทาง MMAP
หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้
- ควรรองรับเอาต์พุตแบบสเตอริโอและ 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 สเกลแบบเต็มสำหรับต้นฉบับที่ใช้บันทึกจุดลอยตัว/ไมโครโฟนคู่ 1 ตัวอย่าง) ที่จะใช้เพื่อความแม่นยำทุกจุดสำหรับไมโครโฟนที่ไม่ลอย
[C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนแต่ละตัว และไมโครโฟนทุกตัวที่ใช้ในการบันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่ากันของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)
[C-1-7] ต้องมีความผิดเพี้ยนแบบฮาร์มอนิก (THD) รวมน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
[C-1-8] ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางอื่นที่ไม่ใช่ตัวคูณระดับเพื่อเพิ่มระดับไปยังช่วงที่ต้องการ กล่าวคือ
- [C-1-9] หากมีการประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม จะต้องปิดใช้งานและทำให้การหน่วงเวลาเป็น 0 หรือเวลาในการตอบสนองที่เพิ่มขึ้นแก่เส้นทางของสัญญาณได้อย่างมีประสิทธิภาพ
- [C-1-10] ตัวคูณระดับขณะที่อยู่ในเส้นทาง ต้องไม่ ทำให้การหน่วงเวลาหรือเวลาในการตอบสนองแก่เส้นทางของสัญญาณ
การวัด SPL ทั้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว
หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone
แต่ไม่รองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล การตั้งค่าดังกล่าวจะมีผลดังนี้
- [C-2-1] ต้องแสดงผล
null
สำหรับเมธอดAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API เพื่อระบุอย่างเหมาะสมว่ารับการสนับสนุนไม่เพียงพอ - [C-SR-1] ยังคงแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดจำนวนมาก สำหรับเส้นทางสัญญาณสำหรับแหล่งบันทึกที่ไม่ได้ประมวลผล
5.12 วิดีโอ HDR
Android 13 รองรับเทคโนโลยี HDR ตามที่อธิบายไว้ในเอกสารที่กำลังจะเผยแพร่
รูปแบบพิกเซล
หากเครื่องมือถอดรหัสวิดีโอโฆษณาการรองรับ COLOR_FormatYUVP010 แล้ว ให้ทำดังนี้
[C-1-1] ต้องรองรับรูปแบบ P010 สำหรับ CPU-read (ImageReader, MediaImage, ByteBuffer) ใน Android 13 นั้น P010 จะผ่อนคลายเพื่อให้เครื่องบิน Y และ UV วิ่งได้อย่างอิสระ
[C-1-2] บัฟเฟอร์เอาต์พุต P010 ต้องสามารถสุ่มตัวอย่างโดย GPU ได้ (เมื่อจัดสรรโดยใช้ GPU_SAMPLING) ซึ่งช่วยให้สามารถจัดองค์ประกอบ GPU และ การแมปโทนที่กำหนดเองโดยแอปได้
หากตัวถอดรหัสวิดีโอโฆษณาการรองรับ COLOR_Format32bitABGR2101010 เครื่องมือดังกล่าวจะ:
- [C-2-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับรูปแบบเอาต์พุตและ CPU ที่อ่านได้ (เอาต์พุต ByteBuffer)
หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_FormatYUVP010 โปรแกรมจะ:
- [C-3-1] ต้องรองรับรูปแบบ P010 สำหรับแพลตฟอร์มอินพุตและอินพุตแบบ CPU-writeable (ImageWriter, MediaImage, ByteBuffer)
หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_Format32bitABGR2101010 โปรแกรมดังกล่าวจะมีลักษณะดังนี้
- [C-4-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับพื้นผิวอินพุตและอินพุตแบบ CPU-Writer (ImageWriter, ByteBuffer) หมายเหตุ: โปรแกรมเปลี่ยนไฟล์ไม่จำเป็นต้องใช้การแปลงเส้นโค้งการโอนต่างๆ
ข้อกำหนดในการจับภาพ HDR
การใช้งานอุปกรณ์สำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอทั้งหมดที่รองรับโปรไฟล์ HDR
[C-5-1] ต้องไม่คิดว่าข้อมูลเมตา HDR มีความแม่นยำ เช่น เฟรมที่เข้ารหัสอาจมีพิกเซลเกินระดับความสว่างสูงสุด หรือฮิสโตแกรมอาจไม่ได้แสดงถึงเฟรม
ควรรวบรวมข้อมูลเมตา HDR แบบไดนามิกเพื่อสร้างข้อมูลเมตา HDR แบบคงที่ที่เหมาะสมสำหรับสตรีมที่เข้ารหัส และควรแสดงข้อมูลเมตาดังกล่าวเมื่อสิ้นสุดเซสชันการเข้ารหัสแต่ละครั้ง
หากอุปกรณ์รองรับการจับภาพ HDR โดยใช้ CamcorderProfile API ระบบจะดำเนินการดังต่อไปนี้
[C-6-1] ต้องรองรับการจับภาพ HDR ผ่าน Camera2 API ด้วย
[C-6-2] ต้องรองรับโปรแกรมเปลี่ยนไฟล์วิดีโอที่เร่งการแสดงผลด้วยฮาร์ดแวร์อย่างน้อย 1 โปรแกรมสำหรับเทคโนโลยี HDR แต่ละรายการที่รองรับ
[C-6-3] ต้องรองรับการบันทึก HLG (เป็นอย่างต่ำ)
[C-6-4] ต้องรองรับการเขียนข้อมูลเมตา HDR (หากเกี่ยวข้องกับเทคโนโลยี HDR) ลงในไฟล์วิดีโอที่บันทึก สำหรับ AV1, HEVC และ DolbyVision หมายถึงการรวมข้อมูลเมตาลงในบิตสตรีมที่เข้ารหัส
[C-6-5] ต้องรองรับ P010 และ COLOR_FormatYUVP010
[C-6-6] ต้องรองรับ HDR เป็นการแมปโทนสี SDR ในตัวถอดรหัสที่ใช้ฮาร์ดแวร์เร่งการแสดงผลเริ่มต้นสำหรับโปรไฟล์ที่บันทึก กล่าวคือ หากอุปกรณ์จับภาพ HEVC แบบ HDR10+ ได้ ตัวถอดรหัส HEVC เริ่มต้นต้องถอดรหัสสตรีมที่บันทึกใน SDR ได้
ข้อกำหนดในการแก้ไข HDR
หากการใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์วิดีโอที่รองรับการแก้ไข HDR ระบบจะดำเนินการดังต่อไปนี้
- ควรใช้เวลาในการตอบสนองน้อยที่สุดในการสร้างข้อมูลเมตา HDR เมื่อไม่ได้แสดง และควรจัดการสถานการณ์ที่มีข้อมูลเมตาอยู่ในบางเฟรมอย่างระมัดระวัง ข้อมูลเมตานี้ควรมีความแม่นยำ (เช่น แสดงความสว่างสูงสุดจริงและฮิสโตแกรมของเฟรม)
หากการใช้งานอุปกรณ์มีตัวแปลงรหัสที่รองรับ FEATURE_HdrEditing ตัวแปลงรหัสเหล่านั้นจะมีลักษณะดังนี้
[C-7-1] ต้องรองรับโปรไฟล์ HDR อย่างน้อย 1 โปรไฟล์
[C-7-2] ต้องรองรับ FEATURE_HdrEditing สำหรับโปรไฟล์ HDR ทั้งหมดที่ตัวแปลงรหัสดังกล่าวโฆษณา กล่าวคือ ต้องสนับสนุนการสร้างข้อมูลเมตา HDR เมื่อ ไม่แสดงสำหรับโปรไฟล์ HDR ทั้งหมดที่สนับสนุนซึ่งใช้ข้อมูลเมตา HDR
[C-7-3] ต้องรองรับรูปแบบอินพุตโปรแกรมเปลี่ยนไฟล์วิดีโอต่อไปนี้ที่รักษาสัญญาณที่ถอดรหัสแบบ HDR ไว้อย่างสมบูรณ์
- RGBA_1010102 (อยู่ในเส้นโค้งการโอนเป้าหมายแล้ว) สำหรับทั้งแพลตฟอร์มอินพุตและ ByteBuffer และต้องโฆษณาการรองรับ COLOR_Format32bitABGR2101010
หากการใช้งานอุปกรณ์มีตัวแปลงรหัสที่รองรับ FEATURE_HdrEditing อุปกรณ์จะดำเนินการต่อไปนี้
- [C-7-4] ต้องโฆษณาการรองรับส่วนขยาย OpenGL EXT_YUV_target
6. เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Android ที่มีให้ใน Android SDK
-
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปใช้ได้
รวมถึง
dumpsys
cmd stats
- [C-0-11] ต้องรองรับคำสั่ง Shell
cmd testharness
การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มีการบล็อกข้อมูลแบบถาวรอาจได้รับการยกเว้นจาก C-0-11 - [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบอุปกรณ์ (batterystats , Dataprocs, Fingerprint, graphicstats, netstats, notification, procstats) บันทึกผ่านคำสั่ง dumpsys
- [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell
cmd stats
และคลาสStatsManager
System API- เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
- ตรวจพบความผิดปกติ
- รายงานเบรดครัมบ์ของแอปแล้ว
- แอปขัดข้อง
- เกิดแอป
- เปลี่ยนระดับแบตเตอรี่แล้ว
- เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
- 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 รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์จะมีผลดังนี้
- [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
- [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 ซึ่งทำให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องมีเมธอด
AdbManager#isAdbWifiSupported()
ที่แสดงtrue
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต และมีกล้องอย่างน้อย 1 ตัว
- [C-5-1] ต้องมีเมธอด
AdbManager#isAdbWifiQrSupported()
ที่แสดงtrue
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปใช้ได้
รวมถึง
บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)
- [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุนสำหรับ ddms ควรจะไม่ทำงานโดยค่าเริ่มต้น แต่ต้องมีการสนับสนุนเมื่อผู้ใช้เปิดใช้งาน Android Debug Bridge ตามด้านบน
-
- [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องไม่มีการใช้งานโดยค่าเริ่มต้นและต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace
-
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุตสำหรับการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [C-SR-3] ขอแนะนําอย่างยิ่งให้เขียนไบนารี Perfetto เป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [C-SR-4] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto โดยใช้ไบนารี Perfetto
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงไบนารี
-
- [C-0-12] ต้องเขียน
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ไปยังบันทึก statsd เมื่อแอปถูก Low Memory Killer สิ้นสุดการทำงาน
- [C-0-12] ต้องเขียน
โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่ง Shell
cmd testharness
และเรียกใช้cmd testharness enable
การดำเนินการดังกล่าวจะส่งผลดังนี้- [C-2-1] ต้องส่งคืน
true
ในราคาActivityManager.isRunningInUserTestHarness()
- [C-2-2] ต้องใช้โหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบของโหมดโปรแกรมทดสอบ
- [C-2-1] ต้องส่งคืน
ข้อมูลการทำงานของ GPU
การติดตั้งใช้งานอุปกรณ์
- [C-0-13] ต้องใช้คำสั่ง Shell
dumpsys gpu --gpuwork
เพื่อแสดงข้อมูลงานของ GPU แบบรวมที่ส่งคืนโดยจุดการติดตามของเคอร์เนลpower/gpu_work_period
หรือไม่แสดงข้อมูลใดๆ หากระบบไม่รองรับ Tracepoint ดังกล่าว การติดตั้งใช้งาน AOSP คือframeworks/native/services/gpuservice/gpuwork/
- [C-0-13] ต้องใช้คำสั่ง Shell
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่าน Flag ฟีเจอร์ android.hardware.vulkan.version
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องจ่ายเงินให้นักพัฒนาแอปในการเปิด/ปิดใช้เลเยอร์การแก้ไขข้อบกพร่องของ GPU
- [C-1-2] ต้องแจกแจงเลเยอร์ในไลบรารีที่เครื่องมือภายนอกจัดเตรียมไว้ให้ (กล่าวคือ ไม่ได้เป็นส่วนหนึ่งของแพ็กเกจแพลตฟอร์มหรือแพ็กเกจแอปพลิเคชัน) ที่พบในไดเรกทอรีพื้นฐานของแอปพลิเคชันที่แก้ไขข้อบกพร่องได้เพื่อให้รองรับ vkEnumerateInstanceLayerProperties() และเมธอด API ของ vkCreateInstance()
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android มีการสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์ในการกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน
การใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
- [C-0-1] ต้องปฏิบัติตาม 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 อย่างเหมาะสมสำหรับอุปกรณ์โดยอัตโนมัติเพื่อดูแลให้แอปพลิเคชันของบุคคลที่สามทำงานได้ดีบนการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย ในจอแสดงผลที่รองรับ Android ซึ่งแอปพลิเคชันของบุคคลที่สามที่รองรับ Android ได้ทั้งหมด การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งาน 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อาจมีจอแสดงผลที่ใช้งานได้กับ Android ซึ่งมีมุมโค้งมน
หากการใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL
และมีจอแสดงผลที่รองรับ
Android ซึ่งมีมุมโค้งมน ระบบจะดำเนินการต่อไปนี้
[C-1-1] ต้องตรวจสอบว่าตรงตามข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ
- รัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
- เมื่อกล่อง 15 dp x 15 dp ตรึงอยู่ที่มุมของจอแสดงผลเชิงตรรกะแต่ละมุม อย่างน้อย 1 พิกเซลของแต่ละกล่องจะปรากฏบนหน้าจอ
ควรรวมทางเลือกของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยมผืนผ้า
หากการใช้งานอุปกรณ์มีจอแสดงผลที่ใช้งานได้กับ Android ที่พับได้ หรือมีบานพับที่พับได้ระหว่างแผงจอแสดงผลหลายแผงและทำให้จอแสดงผลดังกล่าวพร้อมแสดงผลแอปของบุคคลที่สาม สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้ extensions API เวอร์ชันเสถียรล่าสุดที่มีให้ใช้งาน หรือ sidecar API เวอร์ชันเสถียรที่จะใช้โดยไลบรารี Window Manager Jetpack
หากการใช้งานอุปกรณ์รวมถึงจอแสดงผลที่ใช้งานได้กับ Android ซึ่งพับได้หรือมีบานพับที่พับได้ระหว่างแผงจอแสดงผลหลายแผง และหากบานพับหรือพับพาดผ่านหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือพับผ่าน API ส่วนขยายหรือไฟล์ช่วยเหลือไปยังแอปพลิเคชัน
หากต้องการรายละเอียดเกี่ยวกับการใช้ API ไฟล์ช่วยเหลือหรือส่วนขยายอย่างถูกต้อง โปรดดูเอกสารสาธารณะของ Window Manager Jetpack
7.1.1.2 สัดส่วนภาพหน้าจอ
แม้จะไม่มีข้อจำกัดใดๆ เกี่ยวกับสัดส่วนภาพของอุปกรณ์จริงของจอแสดงผลที่ใช้ร่วมกับ Android ได้ แต่สัดส่วนภาพของแอปแบบลอจิคัลที่มีการแสดงผลแอปของบุคคลที่สาม ซึ่งอาจมาจากค่าความสูงและความกว้างที่รายงานผ่าน API ของ view.Display
และ API การกำหนดค่า แต่ต้องเป็นไปตามข้อกำหนดต่อไปนี้
[C-0-1] การใช้งานอุปกรณ์โดยตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_NORMAL
ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
android.max_aspect
- แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
- แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ
android:maxAspectRatio
ที่จะจำกัดสัดส่วนภาพที่อนุญาต
- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
[C-0-3] การใช้งานอุปกรณ์โดยตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_WATCH
ต้องตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)
7.1.1.3 ความหนาแน่นของหน้าจอ
เฟรมเวิร์ก UI ของ Android กำหนดชุดของความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยนักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรของแอปพลิเคชัน
[C-0-1] โดยค่าเริ่มต้น การใช้งานอุปกรณ์ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android เพียง 1 รายการเท่านั้นที่ระบุไว้ใน
DisplayMetrics
ผ่านDENSITY_DEVICE_STABLE
API และค่านี้ต้องไม่เปลี่ยนแปลงเลย อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่แตกต่างกันตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ที่กำหนดไว้หลังจากการเปิดเครื่องครั้งแรกการใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก 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 แสดงเมตริก
หากการใช้งานอุปกรณ์มีจอแสดงผลหรือเอาต์พุตวิดีโอที่ใช้งานร่วมกับ Android ได้ไปยังหน้าจอแสดงผลที่รองรับ Android จะมีเงื่อนไขดังนี้
- [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกดิสเพลย์ทั้งหมดที่ใช้ร่วมกับ Android ได้ที่กำหนดไว้ใน
android.util.DisplayMetrics
API
หากการใช้งานอุปกรณ์ไม่มีหน้าจอหรือเอาต์พุตวิดีโอแบบฝัง ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่รองรับ Android ตามที่กำหนดไว้ใน
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
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
- ควรรองรับ OpenGL ES 3.2
การทดสอบ dEQP ของ OpenGL ES แบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมีหมายเลขวันที่/เวอร์ชันที่เกี่ยวข้องกัน รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
อุปกรณ์ที่รองรับ OpenGL ES ในระดับที่รายงานด้วยตนเองบ่งบอกว่าสามารถผ่านการทดสอบ dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า
หากการติดตั้งใช้งานอุปกรณ์รองรับ 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
และEGL_ANDROID_GLES_layers
- [C-2-3] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ OpenGL ES ที่รองรับผ่านแฟล็กฟีเจอร์
android.software.opengles.deqp.level
- [C-2-4] ต้องรองรับเวอร์ชัน 132383489 (ตั้งแต่วันที่ 1 มีนาคม 2020) เป็นอย่างน้อย ตามที่รายงานในแฟล็กฟีเจอร์
android.software.opengles.deqp.level
- [C-2-5] ต้องผ่านการทดสอบ OpenGL ES dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 และเวอร์ชันที่ระบุในแฟล็กฟีเจอร์
android.software.opengles.deqp.level
สำหรับเวอร์ชัน OpenGL ES ที่รองรับแต่ละเวอร์ชัน - [C-SR-2] แนะนําอย่างยิ่งให้รองรับส่วนขยาย
EGL_KHR_partial_update
และOES_EGL_image_external
- ควรรายงานอย่างถูกต้องผ่านเมธอด
getString()
ซึ่งเป็นรูปแบบการบีบอัดพื้นผิวที่ระบบรองรับ ซึ่งโดยทั่วไปจะเป็นเฉพาะผู้ให้บริการ - รองรับส่วนขยาย
EGL_IMG_context_priority
และEGL_EXT_protected_content
หากการใช้งานอุปกรณ์ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 ก็จะมีผลดังนี้
- [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
- [C-SR-3] ขอแนะนำอย่างยิ่งให้สนับสนุนส่วนขยาย
OES_EGL_image_external_essl3
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [C-4-1] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Extension Pack ของ 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 อุปกรณ์จะทำงานดังนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
- [C-4-1] ต้องไม่รองรับเวอร์ชันตัวแปร Vulkan (เช่น ส่วนตัวแปรของเวอร์ชันหลักของ Vulkan ต้องเป็น 0)
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-SR-2] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
การทดสอบ Vulkan dEQP ได้รับการแบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมีวันที่/เวอร์ชันที่เกี่ยวข้อง รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
อุปกรณ์ที่รองรับ Vulkan ในระดับที่รายงานด้วยตนเองบ่งชี้ว่าอุปกรณ์สามารถผ่านการทดสอบ dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า
หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.0 ขึ้นไป ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วยแฟล็กฟีเจอร์
android.hardware.vulkan.level
และandroid.hardware.vulkan.version
- [C-1-2] ต้องแจกแจง
VkPhysicalDevice
อย่างน้อย 1 รายการสำหรับ Vulkan API เนทีฟvkEnumeratePhysicalDevices()
- [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_swapchain และ VK_KHR_incremental_present
- [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ Vulkan dEQP ที่รองรับผ่านแฟล็กฟีเจอร์
android.software.vulkan.deqp.level
- [C-1-9] ต้องรองรับเวอร์ชัน
132317953
เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานในแฟล็กฟีเจอร์android.software.vulkan.deqp.level
- [C-1-10] ต้องผ่านการทดสอบ Vulkan dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน
132317953
กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์android.software.vulkan.deqp.level
- [C-1-11] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_video_queue, VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue
- [C-SR-3] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย
VK_KHR_driver_properties
และVK_GOOGLE_display_timing
- ควรรองรับ
VkPhysicalDeviceProtectedMemoryFeatures
และVK_EXT_global_priority
- [C-1-12] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_performance_query
- [C-SR-4] แนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดที่ระบุไว้ในโปรไฟล์ Android Baseline 2021
หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ 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 และประกาศ Flag ฟีเจอร์ Vulkan จะมีผลดังนี้
- [C-3-1] ต้องแสดงการสนับสนุน
SYNC_FD
ประเภทแฮนเดิลภายนอก และประเภทแฮนเดิล รวมถึงส่วนขยาย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:hardwareAccelerated หรือการเรียก 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_EXT_gl_colorspace_display_p3_linear
และEGL_EXT_gl_colorspace_display_p3_passthrough
- [C-SR-1] แนะนําอย่างยิ่งให้สนับสนุน
GL_EXT_sRGB
ในทางตรงกันข้าม หากอุปกรณ์ไม่รองรับหน้าจอที่มีขอบเขตกว้าง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่ CIE 1931 xyY แม้ว่าไม่ได้ระบุขอบเขตสีของหน้าจอก็ตาม
7.1.5 โหมดความเข้ากันได้กับแอปพลิเคชันเดิม
Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานในโหมด "หน้าจอปกติ" ที่มีขนาดเทียบเท่า (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาสำหรับ Android เวอร์ชันเก่าซึ่งมีความเป็นอิสระของขนาดหน้าจอก่อน
7.1.6 เทคโนโลยีหน้าจอ
แพลตฟอร์ม Android มี API ที่อนุญาตให้แอปพลิเคชันแสดงกราฟิกที่สมบูรณ์ในจอแสดงผลที่รองรับ Android อุปกรณ์ต้องรองรับ API เหล่านี้ทั้งหมดตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตเป็นการเฉพาะในเอกสารนี้
จอแสดงผลทั้งหมดที่รองรับการใช้งานอุปกรณ์ Android มีดังนี้
- [C-0-1] ต้องแสดงภาพกราฟิกสี 16 บิตได้
- ควรสนับสนุนจอแสดงผลที่รองรับกราฟิกสี 24 บิต
- [C-0-2] ต้องแสดงภาพภาพเคลื่อนไหวได้
- [C-0-3] ต้องมีอัตราส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 นั่นคือ สัดส่วนภาพพิกเซลต้องใกล้เคียงกับรูปสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10 ~ 15%
7.1.7 จอแสดงผลสำรอง
Android มีการสนับสนุนจอแสดงผลสำรองที่เข้ากันได้กับ Android เพื่อเปิดใช้ความสามารถในการแชร์สื่อและ API สำหรับนักพัฒนาซอฟต์แวร์สำหรับการเข้าถึงจอแสดงผลภายนอก
หากการใช้งานอุปกรณ์รองรับจอแสดงผลภายนอกผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบฝัง จะมีผลดังนี้
- [C-1-1] ต้องใช้บริการของระบบ
DisplayManager
และ API ตามที่อธิบายไว้ในเอกสารประกอบ 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] ต้องระบุตัวบ่งชี้ที่ชัดเจนว่าการทำงานเดี่ยวใดจะทริกเกอร์แต่ละฟังก์ชัน การมีไอคอนที่มองเห็นได้พิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนระหว่างการตั้งค่าตั้งแต่แกะกล่อง ก็เป็นตัวอย่างตัวบ่งชี้ดังกล่าว
การติดตั้งใช้งานอุปกรณ์
[C-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าไม่มีกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการทำงานตั้งแต่ Android 4.0 แล้ว
[C-SR-2] แนะนำให้มีฟังก์ชันการนำทางทั้งหมดแบบยกเลิกได้ "ยกเลิกได้" หมายถึงความสามารถของผู้ใช้ในการป้องกันไม่ให้ฟังก์ชันการนำทางทำงาน (เช่น กลับบ้าน ย้อนกลับ ฯลฯ) หากไม่ได้ปล่อยการปัดผ่านเกณฑ์ที่กำหนด
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน "เมนู" สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงปุ่มการทำงานเพิ่มเติมทุกครั้งที่ป๊อปอัปเมนูการดำเนินการเพิ่มเติมไม่ว่างเปล่าและแถบการทำงานปรากฏขึ้น
- [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการทำงาน แต่อาจแสดงผลป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงด้วยการเลือกฟังก์ชันเมนู
หากการใช้งานอุปกรณ์ไม่มีฟังก์ชัน "เมนู" สำหรับความเข้ากันได้แบบย้อนหลัง จะต้องดำเนินการต่อไปนี้
* [C-3-1] ต้องทำให้ฟังก์ชันเมนูพร้อมใช้งานสำหรับแอปพลิเคชันเมื่อ targetSdkVersion
น้อยกว่า 10 รายการ โดยขึ้นอยู่กับปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้ร่วมกับฟังก์ชันการนำทางอื่นๆ
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันผู้ช่วย ระบบจะดำเนินการดังนี้
- [C-4-1] ต้องทำให้ฟังก์ชัน Assist สามารถเข้าถึงได้ด้วยการทำงานเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงแป้นนำทางอื่นๆ ได้
- [C-SR-3] แนะนำอย่างยิ่งให้ใช้การกดค้างที่ฟังก์ชันหน้าแรกเป็นการโต้ตอบที่กำหนดนี้
หากการนำอุปกรณ์ไปใช้งานใช้ส่วนที่ต่างกันของหน้าจอเพื่อแสดงแป้นการนำทาง แป้นจะทำสิ่งต่อไปนี้
- [C-5-1] แป้นนำทางต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมให้ใช้งานสำหรับแอปพลิเคชัน และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่ใช้งานได้สำหรับแอปพลิเคชัน
- [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่มีคุณสมบัติตรงตามข้อกำหนดที่ระบุไว้ในหัวข้อ 7.1.1
- [C-5-3] ต้องยึดตามแฟล็กที่แอปตั้งค่าผ่านเมธอด
View.setSystemUiVisibility()
API เพื่อซ่อนส่วนเฉพาะของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ให้อยู่ในตำแหน่งที่เหมาะสมตามที่ระบุไว้ใน SDK
หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสในหน้าแรกเท่านั้น - [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในวิดีโอยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน
View#setSystemGestureExclusionRects()
แต่อยู่นอกWindowInsets#getMandatorySystemGestureInsets()
ต้องไม่มีการสกัดกั้นสำหรับฟังก์ชันการนำทาง ตราบใดที่การยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับView#setSystemGestureExclusionRects()
- [C-6-3] ต้องส่งเหตุการณ์
MotionEvent.ACTION_CANCEL
ให้แอปที่ทำงานอยู่เบื้องหน้าเมื่อการแตะเริ่มถูกดักจับสำหรับท่าทางสัมผัสของระบบ ในกรณีที่แอปที่ทำงานอยู่เบื้องหน้ามีการส่งเหตุการณ์MotionEvent.ACTION_DOWN
ไว้ก่อนหน้านี้ - [C-6-4] ต้องให้ผู้ใช้จ่ายเพื่อเปลี่ยนไปใช้การนำทางบนหน้าจอ โดยใช้ปุ่ม (เช่น ในการตั้งค่า)
- ควรมีฟังก์ชัน "หน้าแรก" โดยการปัดขึ้นจากขอบด้านล่างของการวางแนวปัจจุบันของหน้าจอ
- ควรมีฟังก์ชัน "ล่าสุด" เป็นการปัดขึ้นแล้วค้างไว้ก่อนที่จะปล่อยนิ้ว จากพื้นที่เดียวกับท่าทางสัมผัส "หน้าแรก"
- ท่าทางสัมผัสที่เริ่มต้นภายใน
WindowInsets#getMandatorySystemGestureInsets()
ไม่ควรได้รับผลกระทบจากการแก้ไขการยกเว้นซึ่งมาจากแอปพลิเคชันเบื้องหน้าผ่านทางView#setSystemGestureExclusionRects()
หากฟังก์ชันการนำทางมาจากที่ใดก็ได้จากขอบซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
- [C-7-1] ฟังก์ชันการนำทางต้อง "กลับ" และจะต้องเป็นการปัดจากขอบทั้งด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
- [C-7-2] หากแผงระบบแบบปัดดูที่กำหนดเองมีอยู่ที่ขอบด้านซ้ายหรือขวา แผงดังกล่าวจะต้องวางไว้ใน 1/3 ของส่วนบนสุดของหน้าจอ โดยมีภาพบ่งชี้ที่ชัดเจนและมองเห็นได้ตลอดเวลาว่า การลากนิ้วจะเรียกใช้แผงที่กล่าวถึงข้างต้น และด้วยเหตุนี้ จึงไม่ "ย้อนกลับ" ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ใต้ 1/3 ของขอบหน้าจอด้านบน แต่แผงระบบต้องไม่ยาวกว่าขอบ 1/3 ของขอบหน้าจอ
- [C-7-3] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANS_BARS_BY_SWIOR_SHOW_TRANS_BARS_BY_SWIG
- [C-7-4] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_S ระบบซ่อนแถบการนำทางที่กำหนดเอง
หากมีฟังก์ชันการนำทางกลับ และผู้ใช้ยกเลิกท่าทางสัมผัสกลับแล้ว ให้ทำดังนี้
- [C-8-1] ต้องโทรหา
OnBackInvokedCallback.onBackCancelled()
- [C-8-2] ต้องไม่โทรหา
OnBackInvokedCallback.onBackInvoked()
- [C-8-3] ต้องไม่ส่งเหตุการณ์ KEYCODE_BACK
หากมีฟังก์ชันการนำทางกลับ แต่แอปพลิเคชันเบื้องหน้าไม่มีการลงทะเบียน OnBackInvokedCallback
ให้ทำดังนี้
- ระบบควรมีภาพเคลื่อนไหวสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าซึ่งแนะนำให้ผู้ใช้ย้อนกลับตามที่ระบุใน AOSP
หากการนำอุปกรณ์ไปใช้งานรองรับ API ของระบบ setNavBarMode
เพื่ออนุญาตให้แอประบบที่มีสิทธิ์android.permission.STATUS_BAR
ตั้งค่าโหมดแถบนำทาง ระบบจะดำเนินการดังต่อไปนี้
- [C-9-1] ต้องรองรับไอคอนที่เหมาะสำหรับเด็กหรือการนำทางโดยใช้ปุ่ม ตามที่ระบุไว้ในโค้ด AOSP
7.2.4 อินพุตหน้าจอสัมผัส
Android มีการสนับสนุนระบบอินพุตตัวชี้แบบต่างๆ เช่น หน้าจอสัมผัส ทัชแพด และอุปกรณ์อินพุตแบบสัมผัสปลอม การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลที่ทำให้ผู้ใช้รู้สึกว่ามีการควบคุมสิ่งต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้กำลังแตะหน้าจอโดยตรง ระบบจึงไม่ต้องใช้การช่วยเหลือพิเศษใดๆ เพื่อชี้ว่าวัตถุมีการดัดแปลง
การติดตั้งใช้งานอุปกรณ์
- ควรมีระบบป้อนข้อมูลตัวชี้ในบางลักษณะ (แบบเมาส์หรือการแตะ)
- ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์
หากอุปกรณ์มีหน้าจอสัมผัส (แบบแตะครั้งเดียวหรือดีกว่า) บนจอแสดงผลหลักที่รองรับ Android ฟีเจอร์ดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องรายงาน
TOUCHSCREEN_FINGER
สำหรับช่อง API ของConfiguration.touchscreen
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.touchscreen
และandroid.hardware.faketouch
หากอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะ มากกว่า 1 ครั้งบนจอแสดงผลหลักที่รองรับ Android ฟีเจอร์ดังกล่าว
- [C-2-1] ต้องรายงานแฟล็กฟีเจอร์ที่เหมาะสม
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
ตามประเภทของหน้าจอสัมผัสที่เจาะจงในอุปกรณ์
หากการใช้งานอุปกรณ์อาศัยอุปกรณ์อินพุตภายนอก เช่น เมาส์หรือแทร็กบอล (กล่าวคือ ไม่ได้แตะหน้าจอโดยตรง) ในอินพุตบนจอแสดงผลหลักที่ใช้งานร่วมกับ Android ได้ และเป็นไปตามข้อกำหนดการแตะปลอมในส่วนที่ 7.2.5 ข้อกำหนดดังกล่าวจะมีผลดังนี้
- [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่เริ่มต้นด้วย
android.hardware.touchscreen
- [C-3-2] ต้องรายงานเฉพาะ
android.hardware.faketouch
- [C-3-3] ต้องรายงาน
TOUCHSCREEN_NOTOUCH
สำหรับช่อง API ของConfiguration.touchscreen
7.2.5 การป้อนข้อมูลด้วยการสัมผัสปลอม
อินเทอร์เฟซแบบ Fake Touch จะมีระบบป้อนข้อมูลของผู้ใช้โดยประมาณของความสามารถด้านหน้าจอสัมผัส ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่บังคับเคอร์เซอร์บนหน้าจอจะเลื่อนไปประมาณการแตะ แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วค่อยคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เป่าลมแบบใช้ไจโร เครื่องวัดการหมุน จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบสัมผัสปลอมได้ 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] ต้องรองรับเคอร์เซอร์ลง ชี้ขึ้น ชี้ลง แล้วชี้ขึ้นที่ตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะ 2 ครั้งบนวัตถุบนหน้าจอได้
- [C-1-5] ต้องรองรับการชี้ลงที่จุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดใดก็ได้ที่กำหนดเองบนหน้าจอ ตามด้วยตัวชี้ขึ้น ซึ่งช่วยให้ผู้ใช้สามารถจำลองการลากด้วยการแตะได้
- [C-1-6] ต้องรองรับการชี้ลง ซึ่งช่วยให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นตัวชี้ขึ้นบนหน้าจอซึ่งทำให้ผู้ใช้สะบัดวัตถุบนหน้าจอได้
หากการใช้งานอุปกรณ์ประกาศการรองรับ 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 การแมปปุ่ม
การติดตั้งใช้งานอุปกรณ์
- [C-1-1] ต้องมีความสามารถในการจับคู่เหตุการณ์ HID กับค่าคงที่
InputEvent
ที่สอดคล้องกันตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งานอัปสตรีม Android เป็นไปตามข้อกำหนดนี้
หากการใช้อุปกรณ์ฝังตัวควบคุมหรือเรือเข้ากับตัวควบคุมแยกต่างหากในช่อง ซึ่งจะให้วิธีการในการป้อนข้อมูลเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่างนี้
- [C-2-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.gamepad
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 0x0224 | KEYCODE_BACK (4) |
KeyEvent 1 รายการ
2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน CA ของ Gamepad 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
ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียนผู้ฟัง ไม่เรียกผู้ฟังเซ็นเซอร์เมื่อเซ็นเซอร์ที่เกี่ยวข้องไม่ได้อยู่ ฯลฯ)
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่สอดคล้องกับนักพัฒนาซอฟต์แวร์บุคคลที่สาม อุปกรณ์เหล่านั้นจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมด โดยใช้ค่าหน่วยเมตริก (เมตริก) สากลที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภท ตามที่ระบุไว้ในเอกสาร Android SDK
- [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * ตัวอย่างเวลา สำหรับกรณีของสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองตามที่ขอไม่เกิน 0 มิลลิวินาที เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
- [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์รายการแรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีค่าความแม่นยำเป็น 0 ได้
- [C-1-4] สำหรับ API ที่ระบุไว้ในเอกสารประกอบของ Android SDK ให้เป็นเซ็นเซอร์แบบต่อเนื่อง การใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมี Jitter ต่ำกว่า 3% โดย Jitter เป็นค่าเบี่ยงเบนมาตรฐานของผลต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์
- [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือตื่น จากสถานะระงับ
- [C-1-6] ต้องรายงานเวลาของเหตุการณ์ เป็นนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK โดยแสดง เวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
- [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
- เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินกว่าผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว
รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทำงานที่ระบุในเอกสารของ Android SDK และเอกสารโอเพนซอร์สของ Android ในเซ็นเซอร์จะถือว่าเชื่อถือได้
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่สอดคล้องกับนักพัฒนาซอฟต์แวร์บุคคลที่สาม อุปกรณ์เหล่านั้นจะดำเนินการดังต่อไปนี้
- [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่า
ผ่านเมธอด
Sensor.getResolution()
API
เซ็นเซอร์บางประเภทเป็นวัสดุผสม ซึ่งหมายความว่าข้อมูลเหล่านั้นอาจมาจากข้อมูลที่เซ็นเซอร์อื่นอย่างน้อย 1 รายการให้ไว้ (ตัวอย่างเช่น เซ็นเซอร์การวางแนวและ เซ็นเซอร์การเร่งความเร็วเชิงเส้น)
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เซ็นเซอร์ประเภทเหล่านี้ เมื่อมีเซ็นเซอร์ทางกายภาพที่จำเป็นก่อนตามที่อธิบายไว้ในประเภทเซ็นเซอร์
หากการใช้งานอุปกรณ์มีเซ็นเซอร์คอมโพสิต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เรื่องเซ็นเซอร์แบบผสม
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม และเซ็นเซอร์รายงานเพียงค่าเดียว การใช้งานอุปกรณ์จะมีผลดังนี้
- [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สำหรับเซ็นเซอร์และรายงานค่า
ผ่านเมธอด
Sensor.getResolution()
API
หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์แสดงต่อนักพัฒนาซอฟต์แวร์บุคคลที่สาม เหตุการณ์ดังกล่าวจะเกิดขึ้นดังนี้
- [C-4-1] ต้องไม่มีพารามิเตอร์การปรับเทียบแบบคงที่ที่กำหนดโดยโรงงานในข้อมูลที่ให้ไว้
หากการใช้งานอุปกรณ์รวมตัวตรวจวัดความเร่งแบบ 3 แกน, เซ็นเซอร์เครื่องวัดการหมุน 3 แกน หรือเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-SR-2] แนะนำอย่างยิ่งเพื่อให้แน่ใจว่าตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมีตำแหน่งสัมพัทธ์คงที่ กล่าวคือหากอุปกรณ์สามารถเปลี่ยนรูปแบบได้ (เช่น พับได้) แกนเซ็นเซอร์จะยังคงอยู่ในแนวเดียวกันและสอดคล้องกับระบบพิกัดเซ็นเซอร์ในสถานะการแปลงอุปกรณ์ที่เป็นไปได้ทั้งหมด
7.3.1 ตัวตรวจวัดความเร่ง
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] แนะนําอย่างยิ่งให้ใช้ตัวตรวจวัดความเร่งแบบ 3 แกน
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่ง ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
- [C-1-3] ต้องเป็นไปตาม ระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
- [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้ถึง 4 เท่าของแรงโน้มถ่วง(4g) หรือมากกว่าบนแกนใดก็ได้
- [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
- [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดยส่วนเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีด้วยอัตราการสุ่มตัวอย่างที่เร็วที่สุด
- ควรรายงานเหตุการณ์สูงสุด 200 Hz
- ควรมีความละเอียดอย่างน้อย 16 บิต
- ควรมีการปรับเทียบขณะใช้งานหากลักษณะเปลี่ยนแปลงตลอดวงจรและการชดเชย รวมถึงคงพารามิเตอร์การชดเชยไว้ระหว่างที่รีบูตอุปกรณ์
- ควรมีการชดเชยอุณหภูมิ
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER
- [C-SR-4] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_SIGNIFICANT_MOTION
- [C-SR-5] แนะนําอย่างยิ่งให้ใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_UNCALIBRATED
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android เพื่อให้เป็นไปตามข้อกำหนดดังกล่าว เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจเป็น "จำเป็น" - ควรใช้เซ็นเซอร์คอมโพสิต
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
ตามที่อธิบายไว้ในเอกสาร Android SDK
หากติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [C-3-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES
- [C-SR-6] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
หากการใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์ผสม TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
และ TYPE_STEP_COUNTER
จะมีผลดังนี้
- [C-4-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
- คุณภาพควรต่ำกว่า 2 mW และ 0.5 mW เมื่ออุปกรณ์อยู่ในสถานะแบบไดนามิกหรือคงที่
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุน 3 แกน ระบบจะดำเนินการต่อไปนี้
- [C-5-1] ต้องใช้
เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- [C-SR-7] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์ไจโรสโคปแบบ 3 แกน และเซ็นเซอร์แมกนิโตมิเตอร์ อุปกรณ์เหล่านี้จะมีผลดังนี้
- [C-6-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
7.3.2 เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 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
- [C-1-10] ต้องใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD_UNCALIBRATED
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดการหมุน 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
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องรับ 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 ให้เหลือน้อยที่สุด (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และนาฬิกาจำลอง/นาฬิกาจากดาวเทียม)
- [C-1-6] หลังจากคำนวณตำแหน่งแล้ว การใช้งานอุปกรณ์ต้องกำหนดตำแหน่งอุปกรณ์ในท้องฟ้าแบบเปิด ภายใน 5 วินาทีเมื่อคำขอตำแหน่งเริ่มต้นใหม่ และใช้เวลาไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอหลังจากนั้นโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากการเปิดเครื่อง
ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่โดยมีความเร่งน้อยกว่า 1 เมตรต่อวินาทียกกำลังสอง
- [C-1-3] ต้องสามารถระบุตำแหน่งได้ภายใน 20 เมตร และความเร็ว ภายใน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
- [C-1-4] ต้องติดตามและรายงานพร้อมกันผ่าน
GnssStatus.Callback
ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว - ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายดวงพร้อมกันได้ (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อย 1 ดวง)
[C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ระหว่างการโทรฉุกเฉินต่อไป
[C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากทุกกลุ่มดาวที่ติดตาม (ตามรายงานในข้อความ GnssStatus) ยกเว้น SBAS
[C-SR-4] แนะนําอย่างยิ่งให้รายงาน AGC และความถี่ในการวัดผล GNSS
[C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทางของทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
[C-SR-6] ขอแนะนำอย่างยิ่งให้รายงานการวัดของ GNSS ทันทีที่พบ แม้ว่าจะไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
[C-SR-7] ขอแนะนำเป็นอย่างยิ่งให้รายงานช่วง Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยอัตรากำลังสองของความเร่งน้อยกว่า 0.2 เมตรต่อวินาที ก็เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที
7.3.4 เครื่องวัดการหมุน
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ติดตั้งเซ็นเซอร์เครื่องวัดการหมุน
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุน ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
- [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป
- [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
- [C-SR-2] เราขอแนะนำเป็นอย่างยิ่งว่าข้อผิดพลาดในการปรับเทียบให้น้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
- [C-SR-3] ขอแนะนำอย่างยิ่งให้มีความละเอียด 16 บิตขึ้นไป
- ควรรายงานเหตุการณ์สูงสุด 200 Hz
หากอุปกรณ์มีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์
TYPE_GYROSCOPE
- [C-SR-4] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_GYROSCOPE_UNCALIBRATED
หากอุปกรณ์มีเครื่องวัดการหมุนที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES
- [C-SR-5] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
หากอุปกรณ์มีเครื่องวัดการหมุน 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-5-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- [C-SR-6] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
7.3.5 บารอมิเตอร์
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] แนะนำให้ใส่บารอมิเตอร์ (เซ็นเซอร์ความกดอากาศแวดล้อม)
หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ ฟังก์ชันเหล่านี้จะมีผลดังนี้
- [C-1-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_PRESSURE
- [C-1-2] ต้องสามารถส่งเหตุการณ์ในระดับ 5 Hz หรือสูงกว่า
- [C-1-3] ต้องมีการชดเชยอุณหภูมิ
- [C-SR-2] แนะนำอย่างยิ่งให้สามารถรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa
- ควรมีความแม่นยำสัมบูรณ์ที่ 1hPa
- ควรมีความแม่นยำสัมพัทธ์ที่ 0.12hPa ในช่วง 20hPa (ความแม่นยำเทียบเท่ากับประมาณ 1 ม. จากการเปลี่ยนแปลง ~200 ม. ที่ระดับน้ำทะเล)
7.3.6 เทอร์โมมิเตอร์
หากการใช้งานอุปกรณ์มีเทอร์โมมิเตอร์โดยรอบ (เซ็นเซอร์อุณหภูมิ) สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องระบุ
SENSOR_TYPE_AMBIENT_TEMPERATURE
สำหรับเซ็นเซอร์อุณหภูมิแวดล้อม และเซ็นเซอร์ต้องวัดอุณหภูมิแวดล้อม (ห้อง/ห้องโดยสารในรถยนต์) ที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส
หากอุปกรณ์มีเซ็นเซอร์เทอร์โมมิเตอร์ที่วัดอุณหภูมินอกเหนือจากอุณหภูมิแวดล้อม เช่น อุณหภูมิของ CPU ค่าดังกล่าวจะส่งผลดังนี้
- [C-2-1] ต้องไม่กำหนด
SENSOR_TYPE_AMBIENT_TEMPERATURE
สำหรับเซ็นเซอร์อุณหภูมิ
หากการใช้งานอุปกรณ์มีเซ็นเซอร์สำหรับตรวจสอบอุณหภูมิผิวหนัง ระบบจะดำเนินการดังต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ API ของ PowerManager.getThermalHeadroom
7.3.7 โฟโต้มิเตอร์
- การใช้งานอุปกรณ์อาจมีโฟโต้มิเตอร์ (เซ็นเซอร์แสงแวดล้อม)
7.3.8 พร็อกซิมิตีเซ็นเซอร์
- การใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์
หากอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์และรายงานเฉพาะค่าไบนารีที่อ่านว่า "ใกล้" หรือ "ไกล" อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกันกับหน้าจอ กล่าวคือ พร็อกซิมิตีเซ็นเซอร์จะต้องอยู่ในแนวสำหรับตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากจุดประสงค์หลักของเซ็นเซอร์ประเภทนี้คือเพื่อตรวจจับโทรศัพท์ที่ผู้ใช้ใช้งานอยู่ หากการใช้อุปกรณ์รวมพร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวแบบอื่นๆ ด้วย อุปกรณ์นั้นต้องไม่สามารถเข้าถึงได้ผ่าน API นี้
- [C-1-2] ต้องมีความแม่นยำอย่างน้อย 1 บิต
- [C-1-3] ต้องใช้ 0 เซนติเมตรเท่ากับค่าใกล้เคียง และ 5 เซนติเมตรเป็นการอ่านระยะไกล
- [C-1-4] ต้องรายงานช่วงและความละเอียดสูงสุดเป็น 5
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-1] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 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-2] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมของไวท์นอยส์ภายในแบนด์วิดท์นี้
- ควรมีอัตราการเดินแบบสุ่มน้อยกว่า 0.001 °/s CMP อัตราการเดินที่ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 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-3] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 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
[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 เซ็นเซอร์ไบโอเมตริก
หากต้องการทราบข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยของการปลดล็อกด้วยไบโอเมตริก โปรดดู เอกสารการวัดความปลอดภัยของข้อมูลไบโอเมตริก
หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรมีเซ็นเซอร์ไบโอเมตริก
เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 3 (เดิมชื่อรัดกุม), คลาส 2 (เดิมชื่อต่ำ) หรือคลาส 1 (เดิมเรียกว่าความสะดวกสบาย) โดยอิงตามอัตราการยอมรับการปลอมแปลงและตัวปลอม รวมถึงความปลอดภัยของไปป์ไลน์ข้อมูลไบโอเมตริก การแยกประเภทนี้จะดูความสามารถที่เซ็นเซอร์ไบโอเมตริกมีในการเชื่อมต่อกับแพลตฟอร์มและกับแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์ต้องมีคุณสมบัติตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่าง หากต้องการจัดประเภทเป็นคลาส 1 คลาส 2 หรือคลาส 3 ข้อมูลไบโอเมตริกทั้งคลาส 2 และคลาส 3 มีความสามารถเพิ่มเติมตามรายละเอียดด้านล่าง
หากการใช้งานอุปกรณ์ทำให้เซ็นเซอร์ข้อมูลไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2 ตามที่ระบุไว้ในเอกสารนี้
- [C-4-2] ต้องรู้จักและใช้ชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ในคลาส Authenticators และชุดค่าผสมของพารามิเตอร์ดังกล่าว ในทางกลับกัน ต้องไม่ยึดตามหรือรับรู้ค่าคงที่จำนวนเต็มที่ส่งไปยังเมธอด canAuthenticate(int) และ setAllowedAuthenticators(int) อื่นนอกเหนือจากที่ระบุไว้เป็นค่าคงที่สาธารณะใน Authenticators และการผสมผสานค่าดังกล่าว
- [C-4-3] ต้องใช้การดำเนินการ ACTION_BIOMETRIC_ENROLL ในอุปกรณ์ที่มีข้อมูลไบโอเมตริก คลาส 3 หรือ คลาส 2 การดำเนินการนี้ต้องแสดงจุดแรกเข้าของการลงทะเบียนสำหรับข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2
หากอุปกรณ์รองรับข้อมูลไบโอเมตริกแบบแพสซีฟ ข้อมูลเหล่านั้นจะมีลักษณะดังนี้
- [C-5-1] โดยค่าเริ่มต้น ต้องมีขั้นตอนการยืนยันเพิ่มเติม (เช่น การกดปุ่ม)
- [C-SR-1] แนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ลบล้างค่ากำหนดแอปพลิเคชันและต้องมีขั้นตอนการยืนยันประกอบเสมอ
- [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ดำเนินการยืนยันเพื่อความปลอดภัย เพื่อให้ระบบปฏิบัติการหรือเคอร์เนลถูกบุกรุกไม่สามารถปลอมแปลงได้ ตัวอย่างเช่น การดำเนินการยืนยันตามปุ่มจริงจะส่งผ่าน PIN อินพุต/เอาต์พุต (GPIO) สำหรับอินพุตเฉพาะวัตถุประสงค์ทั่วไปขององค์ประกอบความปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นๆ นอกเหนือจากการกดปุ่มจริง
- [C-5-2] ต้องใช้ขั้นตอนการตรวจสอบสิทธิ์แบบโดยนัยเพิ่มเติม (ไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationrequired(boolean) ซึ่งแอปพลิเคชันสามารถตั้งค่าเพื่อใช้สำหรับขั้นตอนการลงชื่อเข้าใช้ได้
หากอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกหลายตัว ระบบจะดำเนินการต่อไปนี้
- [C-SR-3] ขอแนะนำเป็นอย่างยิ่งให้ยืนยันข้อมูลไบโอเมตริกเพียงรายการเดียวต่อการตรวจสอบสิทธิ์ (เช่น หากทั้งเซ็นเซอร์ลายนิ้วมือและใบหน้าในอุปกรณ์ใช้งานได้ ควรส่ง onAuthenticationSucceeded หลังจากที่ยืนยันแล้ว)
ในการใช้งานอุปกรณ์ที่อนุญาตให้เข้าถึงคีย์คีย์สโตร์สำหรับแอปพลิเคชันของบุคคลที่สาม
- [C-6-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 3 ตามที่กำหนดไว้ในส่วนนี้ด้านล่าง
- [C-6-2] ต้องแสดงข้อมูลไบโอเมตริกคลาส 3 เท่านั้นเมื่อการตรวจสอบสิทธิ์ต้องใช้ BIOMETRIC_STRONG หรือมีการเรียกการตรวจสอบสิทธิ์ด้วย CryptoObject
หากการใช้งานอุปกรณ์ต้องการให้เซ็นเซอร์ข้อมูลไบโอเมตริกเป็นคลาส 1 (เดิมชื่อความสะดวก) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องมีอัตราการยอมรับที่เป็นเท็จน้อยกว่า 0.002%
- [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจมีความปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และแจกแจงความเสี่ยงในการเปิดใช้อย่างชัดเจน หากอัตราการยอมรับการปลอมแปลงและการหลอกลวงสูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
- [C-1-9] ต้องให้ผู้ใช้ทำการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) หลังจากทำการทดลองที่ผิดพลาดไม่เกิน 20 ครั้ง และไม่มีเวลาเกิน 90 วินาที Backoff สำหรับยืนยันข้อมูลไบโอเมตริก
- [C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้ลดจำนวนการทดลองทั้งหมดที่ผิดพลาดสำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุไว้ใน [C-1-9] หากอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 7% เมื่อวัดโดยใช้โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
- [C-1-3] ต้องพยายามจำกัดจำนวนอัตราสำหรับการยืนยันด้วยข้อมูลไบโอเมตริก โดยการทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกเพียงพอ
(
BIOMETRIC_ACQUIRED_GOOD
) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้ - [C-SR-5] แนะนำอย่างเข้มงวดให้กำหนดอัตราการจำกัดเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดลองที่ผิดพลาด 5 ครั้งเพื่อการยืนยันข้อมูลไบโอเมตริกสูงสุดสำหรับจำนวนการทดลองที่ผิดพลาดสูงสุดต่อ [C-1-9] โดยการทดลองที่ผิดพลาดเป็นการทดลองที่มีคุณภาพในการบันทึก (BIOMETRIC_ACQUIRED_GOOD) ที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลชีวภาพที่ลงทะเบียน
- [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้กำหนดตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE
- [C-1-10] ต้องปิดใช้ข้อมูลไบโอเมตริกเมื่อการย้อนกลับการตรวจสอบสิทธิ์หลักเริ่มทำงานเป็นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วนที่ 9.11
- [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 30% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีการนำเสนอ (PAI) ระดับ A ไม่เกิน 30% และ (2) อัตราการยอมรับโปรโตคอลที่แปลงและไม่เป็นจริงของสปีชีส์ระดับ BAI ไม่เกิน 40% เนื่องจากการทดสอบโปรโตคอลระดับ BAI ต่ำกว่า 40%
- [C-1-4] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/pattern/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโปรเจ็กต์โอเพนซอร์สของ Android เป็นกลไกในเฟรมเวิร์กในการดำเนินการ
- [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ของผู้ใช้ออกทั้งหมด เมื่อมีการนำบัญชีออก (รวมถึงการรีเซ็ตเป็นค่าเริ่มต้น)
- [C-1-6] ต้องให้เกียรติแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
หรือDevicePolicymanager.KEYGUARD_DISABLE_IRIS
) - [C-1-7] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 24 ชั่วโมงหรือน้อยกว่านั้น หมายเหตุ: การอัปเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือเก่ากว่าต้องแก้ปัญหาให้ผู้ใช้ทำการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งในทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น
- [C-1-8] ต้องให้ผู้ใช้ยืนยันการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หรือไบโอเมตริกคลาส 3 (STRONG)
หลังจากดำเนินการอย่างใดอย่างหนึ่งดังต่อไปนี้
- เมื่อไม่มีความเคลื่อนไหวเป็นเวลา 4 ชั่วโมง หรือ
- ตรวจสอบสิทธิ์ข้อมูลไบโอเมตริกไม่สำเร็จ 3 ครั้ง
- ระบบจะรีเซ็ตระยะหมดเวลาเนื่องจากไม่มีการใช้งานและจำนวนการตรวจสอบสิทธิ์ที่ล้มเหลวหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ หมายเหตุ: การอัปเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือเก่ากว่าอาจได้รับการยกเว้น C-1-8
- [C-SR-7] แนะนำอย่างยิ่งให้ใช้ตรรกะในเฟรมเวิร์กของโครงการโอเพนซอร์ส Android เพื่อบังคับใช้ข้อจำกัดที่ระบุไว้ใน [C-1-7] และ [C-1-8] สำหรับอุปกรณ์ใหม่
- [C-SR-8] ขอแนะนำเป็นอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์
- [C-SR-9] ขอแนะนำเป็นอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อตรวจพบข้อมูลไบโอเมตริก จนกระทั่งหน้าจอปลดล็อกสำหรับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้แต่ละรายการ
หากการใช้งานอุปกรณ์ต้องการจัดการเซ็นเซอร์ไบโอเมตริกเป็นคลาส 2 (เดิมชื่อไม่รัดกุม) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
[C-2-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 1 ข้างต้น
[C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 20% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตี (PAI) ระดับ A ไม่สูงกว่า 20% และ (2) อัตราการยอมรับโปรโตคอลที่แปลงและไม่เป็นจริงของสปีชีส์ BAI ระดับ B ทดสอบโดยวัดจากการวัดชีวภาพระดับ Bไม่เกิน 30% ตามการวัดทางชีวภาพของ Android เท่ากับ การวัดทางชีวภาพของ Android
[C-2-3] ต้องดำเนินการจับคู่ข้อมูลไบโอเมตริกในสภาพแวดล้อมการดำเนินการแยกต่างหากนอกผู้ใช้ Android หรือพื้นที่เคอร์เนล เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
[C-2-4] ต้องมีข้อมูลที่ระบุตัวตนได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับเพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยกับสภาพแวดล้อมการดำเนินการที่แยกออกมา ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
[C-2-5] สำหรับข้อมูลไบโอเมตริกที่ใช้กล้องขณะที่การตรวจสอบสิทธิ์หรือลงทะเบียนด้วยข้อมูลไบโอเมตริก
- ต้องใช้กล้องในโหมดที่ป้องกันไม่ให้อ่านหรือเปลี่ยนแปลงเฟรมกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
- สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องจะอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกออกมาเพื่อสนับสนุนการดำเนินการ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่ต้องไม่สามารถแก้ไขได้
[C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามในการแยกความแตกต่างระหว่างการลงทะเบียนข้อมูลไบโอเมตริกแต่ละรายการ
[C-2-7] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวตนได้หรือข้อมูลใดก็ตามที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ไปยังตัวประมวลผลแอปพลิเคชัน นอกบริบทของ TEE โดยไม่เข้ารหัส การอัปเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือก่อนหน้าจะไม่ได้รับการยกเว้นจาก C-2-7
[C-2-8] ต้องมีไปป์ไลน์การประมวลผลที่ปลอดภัยซึ่งระบบปฏิบัติการหรือการบุกรุกเคอร์เนลไม่สามารถอนุญาตให้แทรกข้อมูลโดยตรงเพื่อตรวจสอบสิทธิ์ว่าเป็นผู้ใช้ได้ หมายเหตุ: หากมีการเปิดตัวอุปกรณ์ใน Android เวอร์ชัน 9 หรือเวอร์ชันก่อนหน้าแล้ว และไม่เป็นไปตามข้อกำหนด C-2-8 ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านั้นอาจได้รับการยกเว้นจากข้อกำหนด
[C-SR-10] ขอแนะนำอย่างยิ่งให้รวมการตรวจหาบุคคลจริงสำหรับวิธีไบโอเมตริกทั้งหมดและการตรวจจับความสนใจสำหรับข้อมูลไบโอเมตริกใบหน้า
[C-2-9] ต้องทำให้แอปพลิเคชันของบุคคลที่สามสามารถใช้เซ็นเซอร์ไบโอเมตริกได้
หากการใช้งานอุปกรณ์ต้องการให้เซ็นเซอร์ข้อมูลไบโอเมตริกเป็นรุ่นคลาส 3 (เดิมชื่อรัดกุม) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดของคลาส 2 ข้างต้น ยกเว้น [C-1-7] และ [C-1-8]
- [C-3-2] ต้องมีการใช้งานคีย์สโตร์ที่ใช้ฮาร์ดแวร์
- [C-3-3] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 7% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีระดับ A (PAI) ไม่สูงกว่า 7% และ (2) อัตราการยอมรับการปลอมแปลงและตัวปลอมของสปีชีส์ PAI ระดับ B ที่ไม่สูงกว่า 20% การวัดไบโอเมตริกของ Android
- [C-3-4] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น
- [C-3-5] ต้องสร้างรหัส Authenticator อีกครั้งสำหรับข้อมูลไบโอเมตริกระดับ 3 ทั้งหมดที่รองรับในอุปกรณ์ หากมีการลงทะเบียนซ้ำ
- [C-3-6] ต้องเปิดใช้คีย์สโตร์ที่ใช้ข้อมูลไบโอเมตริกกับแอปพลิเคชันของบุคคลที่สาม
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ลายนิ้วมือใต้จอแสดงผล (UDFPS) ระบบจะดำเนินการดังนี้
- [C-SR-11] ขอแนะนำอย่างยิ่งเพื่อป้องกันไม่ให้พื้นที่ที่สัมผัสได้ของ UDFPS รบกวนการนำทางแบบ 3 ปุ่ม( ซึ่งผู้ใช้บางรายอาจต้องการเพื่อการเข้าถึง)
7.3.11 เซ็นเซอร์ท่าทาง
การติดตั้งใช้งานอุปกรณ์
- อาจรองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา
หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์ตรวจจับการเคลื่อนไหวที่มีการเคลื่อนไหว 6 องศาอิสระ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_POSE_6DOF
- [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว
7.3.12 เซ็นเซอร์มุมบานพับ
หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์วัดมุมแบบบานพับ อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องใช้และรายงาน
TYPE_HINGLE_ANGLE
- [C-1-2] ต้องรองรับการอ่านค่าอย่างน้อย 2 ค่าระหว่าง 0 ถึง 360 องศา (รวม 0 และ 360 องศา)
- [C-1-3] ต้องส่งคืนเซ็นเซอร์การปลุกระบบ
สำหรับ
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
7.3.13 IEEE 802.1.15.4 [ย้ายไปที่ 7.4.9]
7.4 การเชื่อมต่อข้อมูล
7.4.1 โทรศัพท์
"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรออกและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจมีหรือไม่มีการเปลี่ยนแพ็กเก็ต แต่ก็มีขึ้นเพื่อวัตถุประสงค์ของ Android ซึ่งถือว่าไม่เกี่ยวข้องกับการเชื่อมต่อข้อมูลใดๆ ที่อาจใช้งานโดยใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันและ API ด้าน "โทรศัพท์" ของ Android หมายถึงการโทรและ SMS โดยเฉพาะ ตัวอย่างเช่น การใช้งานอุปกรณ์ที่ไม่สามารถโทรออกหรือส่ง/รับข้อความ SMS จะไม่ถือว่าเป็นอุปกรณ์โทรศัพท์ ไม่ว่าอุปกรณ์จะใช้เครือข่ายมือถือสำหรับการเชื่อมต่อข้อมูลหรือไม่ก็ตาม
- Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์สำหรับโทรศัพท์ กล่าวคือ Android เข้ากันได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์
หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony
และแฟล็กฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี - [C-1-2] ต้องใช้การสนับสนุน API อย่างสมบูรณ์สำหรับเทคโนโลยีนั้น
- ควรอนุญาตบริการเครือข่ายมือถือทุกประเภท (2G, 3G, 4G, 5G ฯลฯ)
ระหว่างการโทรฉุกเฉิน (ไม่ว่าเครือข่ายจะตั้งโดย
SetAllowedNetworkTypeBitmap()
ประเภทใดก็ตาม)
หากการติดตั้งใช้งานอุปกรณ์ไม่รวมฮาร์ดแวร์สำหรับโทรศัพท์ การติดตั้งจะมีผลดังนี้
- [C-2-1] ต้องใช้ API เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ
หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมที่ฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามใช้งานฟังก์ชัน eSIM ได้ ฟังก์ชันดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony.euicc
หากการติดตั้งใช้งานอุปกรณ์ไม่ได้ตั้งค่าพร็อพเพอร์ตี้ของระบบ ro.telephony.iwlan\_operation\_mode
เป็น "เดิม" ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องไม่รายงาน "NETWORK_TYPE_IWLAN" ผ่าน NetworkRegistrationInfo#getAccessNetworkTechnology() เมื่อมีการรายงาน NetworkRegistrationInfo#getTransportType() เป็น "TRANSPORT_TYPE_WWAN" สำหรับอินสแตนซ์ NetworkRegistrationInfo เดียวกัน
หากการใช้งานอุปกรณ์รองรับการลงทะเบียนระบบย่อยแบบมัลติมีเดีย (IMS) แบบ IP เดียวสำหรับทั้งฟีเจอร์บริการโทรศัพท์มัลติมีเดีย (MMTEL) และฟีเจอร์บริการสื่อสารที่สมบูรณ์ (RCS) และเป็นไปตามข้อกำหนดของผู้ให้บริการเครือข่ายมือถือเกี่ยวกับการใช้การลงทะเบียน IMS เดียวสำหรับการรับส่งข้อมูลการส่งสัญญาณ IMS ทั้งหมด
- [C-5-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony.ims
และติดตั้งใช้งาน ImsService API โดยสมบูรณ์สำหรับทั้ง User Capability Exchange API ของ MMTEL และ RCS - [C-5-2] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony.ims.singlereg
และติดตั้งใช้งาน SipTransport API, GbaService API, ตัวบ่งชี้สำหรับผู้ถือโดยเฉพาะโดยใช้ IRadio 1.6 HAL และการจัดสรรผ่าน Auto Configuration Server (ACS) หรือกลไกการจัดสรรที่เป็นกรรมสิทธิ์อื่นๆ โดยใช้ IMS Configuration API
หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony
ระบบจะดำเนินการดังนี้
- [C-6-1]
SmsManager#sendTextMessage
และSmsManager#sendMultipartTextMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อให้บริการฟังก์ชันการรับส่งข้อความSmsManager#sendMultimediaMessage
และSmsManager#downloadMultimediaMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อให้บริการฟังก์ชันการรับส่งข้อความมัลติมีเดีย - [C-6-2] แอปพลิเคชันที่กำหนดโดย
android.provider.Telephony.Sms#getDefaultSmsPackage
ต้องใช้ SmsManager API เมื่อส่งและรับข้อความ SMS และ MMS การใช้งานข้อมูลอ้างอิง AOSP ในแพ็กเกจ/แอป/การรับส่งข้อความจะเป็นไปตามข้อกำหนดนี้ - [C-6-3] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องรองรับการป้อนรหัสแป้นโทรศัพท์ที่กำหนดเองในรูปแบบ*#*#CODE#*#*
และ ทริกเกอร์การออกอากาศTelephonyManager#ACTION_SECRET_CODE
ที่เกี่ยวข้อง - [C-6-4] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องใช้VoicemailContract.Voicemails#TRANSCRIPTION
เพื่อแสดงการถอดข้อความเสียงเป็นภาพต่อผู้ใช้หากรองรับ การถอดข้อความเสียงเป็นภาพ - [C-6-5] ต้องแสดง SubscriptionInfo ทั้งหมดด้วย UUID กลุ่มที่เทียบเท่ากันเป็นการสมัครใช้บริการเดียวในราคาที่แสดงต่อผู้ใช้ทั้งหมดซึ่งจะแสดงและควบคุมข้อมูลซิมการ์ด ตัวอย่างของค่าใช้จ่ายดังกล่าว ได้แก่ อินเทอร์เฟซการตั้งค่าที่ตรงกับ
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
หรือEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] ต้องไม่แสดงหรืออนุญาตการควบคุม SubscriptionInfo ด้วย UUID กลุ่มและบิตของโอกาสที่ไม่เป็นค่าว่าง โดยอนุญาตให้กำหนดค่าหรือควบคุมการตั้งค่าซิมการ์ดได้
หากการใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony
และมีแถบสถานะของระบบ ให้ทำดังนี้
- [C-7-1] ต้องเลือกการสมัครใช้บริการที่เป็นตัวแทนสำหรับ UUID ของกลุ่มหนึ่งๆ เพื่อแสดงต่อผู้ใช้ในทุกราคาที่ให้ข้อมูลสถานะของซิม เช่น ไอคอนสัญญาณมือถือในแถบสถานะหรือการ์ดการตั้งค่าด่วน
- [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ใช้การสมัครใช้บริการของตัวแทนเป็นการสมัครใช้บริการข้อมูลที่ใช้งานอยู่ เว้นแต่อุปกรณ์กำลังอยู่ในสาย โดยในระหว่างนั้นเราขอแนะนำอย่างยิ่งว่าการสมัครใช้บริการของตัวแทนจะเป็นการสมัครใช้บริการ Voice ที่ใช้งานอยู่
หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony
ระบบจะดำเนินการดังนี้
- [C-6-7] ต้องมีความสามารถในการเปิดและใช้ช่องทางเชิงตรรกะพร้อมกันถึงจำนวนสูงสุด (รวม 20 แชแนล) สำหรับแต่ละ UICC ตาม ETSI TS 102 221
- [C-6-8] ต้องไม่ใช้ลักษณะการทำงานต่อไปนี้กับแอปของผู้ให้บริการที่ใช้งานอยู่
(ตามที่กำหนดโดย
TelephonyManager#getCarrierServicePackageName
) โดยอัตโนมัติหรือไม่มีการยืนยันจากผู้ใช้อย่างชัดแจ้ง- เพิกถอนหรือจำกัดสิทธิ์เข้าถึงเครือข่าย
- เพิกถอนสิทธิ์
- จำกัดการดำเนินการของแอปในเบื้องหลังหรือเบื้องหน้านอกเหนือจากฟีเจอร์การจัดการพลังงานที่มีอยู่ซึ่งรวมอยู่ใน AOSP
- ปิดใช้หรือถอนการติดตั้งแอป
หากใช้อุปกรณ์รายงานฟีเจอร์ android.hardware.telephony
และการสมัครใช้บริการที่ไม่ใช่โอกาสทั้งหมดที่ใช้งานอยู่ทั้งหมดซึ่งแชร์ UUID ของกลุ่ม ถูกนำออกจากอุปกรณ์จริง หรือทำเครื่องหมายว่ามีโอกาส อุปกรณ์จะมีผลดังนี้
- [C-8-1] ต้องปิดใช้การสมัครใช้บริการ โอกาส ที่ใช้งานอยู่ทั้งหมดที่เหลืออยู่ในกลุ่มเดียวกันโดยอัตโนมัติ
หากการติดตั้งใช้งานอุปกรณ์รวมถึงการใช้โทรศัพท์ GSM แต่ไม่ใช่โทรศัพท์ CDMA ระบบจะดำเนินการต่อไปนี้
- [C-9-1] ต้องไม่ประกาศ
PackageManager#FEATURE_TELEPHONY_CDMA
- [C-9-2] ต้องใส่
IllegalArgumentException
เมื่อมีการพยายามตั้งค่าประเภทเครือข่าย 3GPP2 เป็นบิตมาสก์ประเภทเครือข่ายที่ต้องการหรือที่ได้รับอนุญาต - [C-9-3] ต้องแสดงผลสตริงว่างจาก
TelephonyManager#getMeid
หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC ที่มีพอร์ตและโปรไฟล์หลายรายการ ระบบจะดำเนินการดังต่อไปนี้
- [C-10-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony.euicc.mep
7.4.1.1 ความเข้ากันได้ของการบล็อกหมายเลข
การนำอุปกรณ์ไปใช้งานรายงานฟีเจอร์ android.hardware.telephony.calling
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องมีการสนับสนุนการบล็อกหมายเลข
- [C-1-2] ต้องใช้
BlockedNumberContract
และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ SDK [C-1-3] ต้องบล็อกการโทรและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยไม่โต้ตอบกับแอปใดๆ เลย ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
[C-1-4] ต้องเขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก และต้องกรองการโทรที่มี
BLOCKED_TYPE
ออกจากมุมมองบันทึกการโทรเริ่มต้นในแอปแป้นโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า[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.calling
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ API ของ
ConnectionService
ที่อธิบายไว้ใน SDK - [C-1-2] ต้องแสดงสายเรียกเข้าใหม่และระบุราคาของผู้ใช้ในการยอมรับหรือปฏิเสธสายเรียกเข้าเมื่อผู้ใช้กำลังโทรอยู่
ซึ่งสร้างโดยแอปของบุคคลที่สามที่ไม่รองรับฟีเจอร์พักสาย
ที่ระบุผ่าน
CAPABILITY_SUPPORT_HOLD
- [C-1-3] ต้องมีแอปพลิเคชันที่ใช้งาน InCallService
[C-SR-1] ขอแนะนำอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบว่าการรับสายที่โทรเข้าจะตัดสายที่สนทนาอยู่
การใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้โดยมีการแจ้งเตือนล่วงหน้าซึ่งระบุให้ผู้ใช้ทราบว่าการรับสายเรียกเข้าจะทำให้สายอื่นๆ หลุด
[C-SR-2] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรศัพท์เริ่มต้นล่วงหน้าที่แสดงรายการบันทึกการโทรและชื่อแอปของบุคคลที่สามในบันทึกการโทร เมื่อแอปของบุคคลที่สามตั้งค่าคีย์เพิ่มเติมของ
EXTRA_LOG_SELF_MANAGED_CALLS
ในPhoneAccount
เป็นtrue
[C-SR-3] ขอแนะนำเป็นอย่างยิ่งให้จัดการเหตุการณ์
KEYCODE_MEDIA_PLAY_PAUSE
ของชุดหูฟังเสียงและKEYCODE_HEADSETHOOK
สำหรับ API ของandroid.telecom
ดังนี้- โทรหา
Connection.onDisconnect()
เมื่อตรวจพบการกดปุ่มเหตุการณ์สำคัญสั้นๆ ระหว่างที่โทรอยู่ - โทรหา
Connection.onAnswer()
เมื่อตรวจพบการกดแป้นสั้นๆ ระหว่างที่มีสายเรียกเข้า - โทร
Connection.onReject()
เมื่อตรวจพบการกดแป้นค้างระหว่างที่มีสายเรียกเข้า - สลับสถานะการปิดเสียงของ
CallAudioState
- โทรหา
7.4.1.3 การลดภาระงาน NAT-T Keepalive ของเครือข่ายมือถือ
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือ
หากการใช้งานอุปกรณ์มีการรองรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือและแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ SocketKeepAlive API
- [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ
- [C-1-3] ต้องรองรับสล็อต Keepalive ผ่านเครือข่ายมือถือพร้อมกันได้มากเท่าที่ Cellular Radio HAL รองรับ
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับช่อง Keepalive ของเครือข่ายมือถืออย่างน้อย 3 ช่องต่ออินสแตนซ์วิทยุ
หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงผล ERROR_UNSUPPORTED
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] ต้องไม่ใช้การเรียกเมธอด
WifiManager.enableNetwork()
การเรียกเมธอด API เป็นตัวบ่งชี้ที่เพียงพอในการเปลี่ยนรายการที่ใช้งานอยู่ในปัจจุบันNetwork
ซึ่งใช้โดยค่าเริ่มต้นสำหรับการรับส่งข้อมูลแอปพลิเคชัน และจะแสดงผล โดยConnectivityManager
เมธอด API เช่นgetActiveNetwork
และregisterDefaultNetworkCallback
กล่าวคือ อาจปิดใช้งานการเข้าถึงอินเทอร์เน็ตที่ให้บริการโดยผู้ให้บริการเครือข่ายรายอื่น (เช่น อินเทอร์เน็ตมือถือ) เฉพาะเมื่อตรวจสอบแล้วว่าเครือข่าย Wi-Fi ได้ให้การเข้าถึงอินเทอร์เน็ตเท่านั้น - [C-1-6] แนะนำอย่างยิ่งต่อเมื่อมีการเรียกเมธอด
ConnectivityManager.reportNetworkConnectivity()
API ให้ประเมินการเข้าถึงอินเทอร์เน็ตในNetwork
อีกครั้ง และเมื่อการประเมินระบุว่าNetwork
ปัจจุบันไม่มีการเข้าถึงอินเทอร์เน็ตแล้ว ให้เปลี่ยนไปใช้เครือข่ายอื่นๆ ที่มี (เช่น อินเทอร์เน็ตมือถือ) ที่เข้าถึงอินเทอร์เน็ตได้ - [C-1-7] ต้องสุ่มที่อยู่ MAC ของแหล่งที่มาและหมายเลขลำดับของเฟรมคำขอตรวจสอบ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้ง ขณะที่ไม่มีการเชื่อมต่อ STA
- [C-1-8] ต้องใช้ที่อยู่ MAC ที่สอดคล้องกันเพียงรายการเดียว (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งทางของการสแกน)
- [C-1-9] ต้องทำซ้ำหมายเลขลำดับการตรวจสอบของคำขอตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
- [C-1-10] ต้องสุ่มหมายเลขลำดับคำขอการตรวจสอบระหว่างคำขอการตรวจสอบสุดท้ายของการสแกนกับคำขอตรวจสอบแรกของการสแกนครั้งถัดไป
- [C-SR-1] แนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ของแหล่งที่มาที่ใช้สำหรับการสื่อสาร STA ทั้งหมดกับจุดเข้าใช้งาน (AP) ขณะที่ทำการเชื่อมโยงและเชื่อมโยง
- อุปกรณ์ต้องใช้ที่อยู่ MAC แบบสุ่มที่แตกต่างกันสําหรับ SSID (FQDN สําหรับ Passpoint) แต่ละรายการที่สื่อสารด้วย
- อุปกรณ์ต้องระบุตัวเลือกให้ผู้ใช้ในการควบคุมการสุ่มต่อ SSID (FQDN สำหรับ Passpoint) โดยใช้ตัวเลือกที่ไม่ใช่แบบสุ่มและแบบสุ่ม และต้องตั้งค่าโหมดเริ่มต้นสำหรับการกำหนดค่า Wi-Fi ใหม่เป็นแบบสุ่ม
- [C-SR-2] แนะนำอย่างยิ่งให้ใช้ BSSID แบบสุ่มสำหรับ AP ที่บริษัทสร้างขึ้น
- ที่อยู่ MAC ต้องเป็นที่อยู่แบบสุ่มและยังคงอยู่ต่อ SSID ที่ AP ใช้
- DEVICE อาจให้ตัวเลือกกับผู้ใช้ในการปิดใช้งานฟีเจอร์นี้ หากมีตัวเลือกดังกล่าว การสุ่มต้องเปิดใช้งานโดยค่าเริ่มต้น
หากการใช้งานอุปกรณ์รวมการสนับสนุนสำหรับโหมดประหยัดพลังงาน Wi-Fi ตามที่ระบุไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์เหล่านี้จะมีผลดังนี้
- ควรปิดโหมดประหยัดพลังงานของ Wi-Fi ทุกครั้งที่แอปได้ล็อก
WIFI_MODE_FULL_HIGH_PERF
หรือล็อกWIFI_MODE_FULL_LOW_LATENCY
ผ่านWifiManager.createWifiLock()
และWifiManager.WifiLock.acquire()
API และล็อกทำงานอยู่ - [C-3-2] เวลาในการตอบสนองไป-กลับโดยเฉลี่ยระหว่างอุปกรณ์กับจุดเข้าใช้งาน
ขณะที่อุปกรณ์อยู่ในโหมดล็อกเวลาในการตอบสนองต่ำของ Wi-Fi
(
WIFI_MODE_FULL_LOW_LATENCY
) ต้องน้อยกว่าเวลาในการตอบสนองระหว่างโหมดล็อก Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
) - [C-SR-3] ขอแนะนำอย่างยิ่งให้ลดเวลาในการตอบสนองของ Wi-Fi แบบไป-กลับเมื่อมีการใช้การล็อกเวลาในการตอบสนองต่ำ (
WIFI_MODE_FULL_LOW_LATENCY
) และมีผลใช้งาน
หากการใช้งานอุปกรณ์รองรับ 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 ควบคู่กัน
- [C-SR-1] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางสำหรับการเชื่อมต่อ Wi-Fi Direct ที่สร้างขึ้นใหม่ทั้งหมด
7.4.2.2 การตั้งค่าการเชื่อมต่อโดยตรงผ่านอุโมงค์ Wi-Fi
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับการตั้งค่าลิงก์โดยตรงผ่านอุโมงค์ Wi-Fi (TDLS) ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLS และ TDLS เปิดใช้อยู่โดย WiFiManager 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 อยู่ เว้นแต่จะมีการใช้งานระยะ Aware อย่างต่อเนื่องหรือเส้นทางข้อมูลของ Aware ทำงานอยู่ (ไม่น่าจะมีการสุ่มตราบเท่าที่เส้นทางข้อมูลทำงานอยู่)
หากการใช้งานอุปกรณ์รวมการสนับสนุนตำแหน่งการรับรู้ Wi-Fi และ Wi-Fi ตามที่อธิบายไว้ในส่วนที่ 7.4.2.5 และแสดงฟังก์ชันเหล่านี้กับแอปของบุคคลที่สาม การใช้งานดังกล่าวจะต้องดำเนินการดังต่อไปนี้
- [C-2-1] ต้องใช้ API การค้นพบที่รับรู้ตำแหน่ง: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm และ onServiceDiscoveredinternalRange
7.4.2.4 รหัสผ่าน Wi-Fi
หากการติดตั้งใช้งานอุปกรณ์มีการรองรับ 802.11 (Wi-Fi) อุปกรณ์ดังกล่าวจะดำเนินการดังนี้
- [C-1-1] ต้องมีการรองรับ Wi-Fi Passpoint
- [C-1-2] ต้องใช้ API ของ
WifiManager
ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับ SDK - [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นพบและการเลือกเครือข่าย เช่น General Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)
- [C-1-4] ต้องประกาศ Flag ฟีเจอร์
android.hardware.wifi.passpoint
- [C-1-5] ต้องปฏิบัติตามการใช้งาน AOSP เพื่อค้นหา จับคู่ และเชื่อมโยงกับเครือข่าย Passpoint
- [C-1-6] ต้องรองรับโปรโตคอลการจัดสรรอุปกรณ์ชุดย่อยต่อไปนี้เป็นอย่างน้อย ตามที่กำหนดไว้ใน Wi-Fi Alliance Passpoint R2: การตรวจสอบสิทธิ์ EAP-TTLS และ SOAP-XML
- [C-1-7] ต้องประมวลผลใบรับรองเซิร์ฟเวอร์ AAA ตามที่อธิบายไว้ในข้อมูลจำเพาะของฮอตสปอต 2.0 R3
- [C-1-8] ต้องรองรับการควบคุมการจัดสรรผู้ใช้ผ่านเครื่องมือเลือก Wi-Fi
- [C-1-9] ต้องคงการกำหนดค่า Passpoint ไว้ตลอดเมื่อรีบูต
- [C-SR-1] แนะนำอย่างยิ่งให้สนับสนุนคุณลักษณะ การยอมรับข้อกำหนดในการให้บริการ
- [C-SR-2] แนะนําอย่างยิ่งให้รองรับฟีเจอร์ข้อมูลสถานที่
หากมีสวิตช์ปิดใช้การควบคุมผู้ใช้ Passpoint ส่วนกลาง การใช้งานจะมีดังนี้
- [C-3-1] ต้องเปิดใช้ Passpoint โดยค่าเริ่มต้น
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 นั้นไม่ได้เชื่อมโยงกับจุดเข้าใช้งาน
- [C-1-4] ต้องมีความแม่นยำภายในระยะ 2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม)
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รายงานอย่างถูกต้องภายในระยะ 1.5 เมตร ที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม)
7.4.2.6 การลดภาระงาน Wi-Fi Keepalive
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับการลดภาระงาน Wi-Fi Keepalive
หากการนำอุปกรณ์ไปใช้มีการรองรับการเลิกใช้ Keepalive ของ Wi-Fi และแสดงฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม เหตุการณ์เหล่านี้จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ SocketKeepAlive API
- [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi
หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Wi-Fi Keepalive สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องส่งคืน
ERROR_UNSUPPORTED
7.4.2.7 Wi-Fi Easy Connect (โปรโตคอลการจัดสรรอุปกรณ์)
การติดตั้งใช้งานอุปกรณ์
- ควรมีการรองรับ Wi-Fi Easy Connect (DPP)
หากการใช้งานอุปกรณ์มีการสนับสนุนสำหรับ Wi-Fi Easy Connect และแสดงฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม เหตุการณ์เหล่านี้จะมีลักษณะดังนี้
- [C-1-1] ต้องมีเมธอด WifiManager#isEasyConnectSupported()
แสดงผล
true
7.4.2.8 การตรวจสอบใบรับรองเซิร์ฟเวอร์ Wi-Fi ขององค์กร
หากไม่มีการตรวจสอบใบรับรองเซิร์ฟเวอร์ Wi-Fi หรือไม่ได้ตั้งค่าชื่อโดเมนของเซิร์ฟเวอร์ Wi-Fi ไว้ การใช้งานอุปกรณ์จะมีผลดังนี้
- [C-SR-1] แนะนำอย่างยิ่งไม่ให้มีตัวเลือกให้ผู้ใช้เพิ่มเครือข่าย Wi-Fi ขององค์กรในแอปการตั้งค่าด้วยตนเอง
7.4.2.9 Trust On First Use (TOFU)
หากการติดตั้งใช้งานอุปกรณ์รองรับ Trust on first use (TOFU) และอนุญาตให้ผู้ใช้กำหนดค่า WPA/WPA2/WPA3-Enterprise ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องระบุตัวเลือกให้ผู้ใช้เลือกใช้ TOFU
7.4.3 บลูทูธ
หากอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ ระบบจะดำเนินการต่อไปนี้
- ควรรองรับตัวแปลงรหัสเสียงขั้นสูงและตัวแปลงรหัสเสียงบลูทูธ (เช่น LDAC) พร้อม A2DP
หากการติดตั้งใช้งานอุปกรณ์รองรับ 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 ฯลฯ ตามความเหมาะสมกับอุปกรณ์
หากอุปกรณ์รองรับบลูทูธพลังงานต่ำ (BLE) จะมีผลดังนี้
- [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()
เพื่อระบุว่า รองรับการโฆษณาแบบใช้พลังงานต่ำหรือไม่ - [C-3-5] ต้องใช้ระยะหมดเวลา Resolvable Private Address (RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์กำลังใช้ BLE ในการสแกนหรือการโฆษณา และในการป้องกันการโจมตีแบบจับเวลา ระยะหมดเวลาจะต้องเป็นแบบสุ่มระหว่าง 5 ถึง 15 นาทีด้วย
- ควรรองรับการลดภาระของตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API
- ควรรองรับการลดการโหลดของการสแกนแบบกลุ่มไปยังชิปเซ็ตบลูทูธ
- ควรรองรับโฆษณาหลายรายการที่มีอย่างน้อย 4 ช่อง
หากอุปกรณ์รองรับ Bluetooth LE และใช้ Bluetooth LE สำหรับการสแกนตำแหน่ง ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องระบุราคาสำหรับการเปิด/ปิดใช้ค่าที่อ่านผ่าน System API
BluetoothAdapter.isBleScanAlwaysAvailable()
หากการใช้งานอุปกรณ์รวมการรองรับบลูทูธ LE และโปรไฟล์เครื่องช่วยฟังตามที่อธิบายไว้ในการรองรับเสียงจากเครื่องช่วยฟังโดยใช้ Bluetooth LE การใช้งานดังกล่าวจะส่งผลดังนี้
- [C-5-1] ต้องแสดงผล
true
สำหรับ BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID)
หากอุปกรณ์รองรับบลูทูธหรือบลูทูธพลังงานต่ำ จะมีการดำเนินการดังนี้
- [C-6-1] ต้องจำกัดการเข้าถึงข้อมูลเมตาของบลูทูธ (เช่น ผลการสแกน) ที่อาจนำมาใช้ค้นหาตำแหน่งของอุปกรณ์ได้ เว้นแต่ว่าแอปที่ส่งคำขอจะผ่านการตรวจสอบสิทธิ์
android.permission.ACCESS_FINE_LOCATION
ตามสถานะเบื้องหน้า/เบื้องหลังปัจจุบัน
หากการใช้งานอุปกรณ์รวมการรองรับบลูทูธหรือบลูทูธพลังงานต่ำ และไฟล์ Manifest ของแอปไม่ได้รวมประกาศจากนักพัฒนาแอปที่ระบุว่า อุปกรณ์ไม่ได้มาจากบลูทูธ ก็จะมีการทำดังนี้
- [C-6-2] ต้องกั้นการเข้าถึงบลูทูธไว้หลัง
android.permission.ACCESS_FINE_LOCATION
หากการติดตั้งใช้งานอุปกรณ์แสดงผล true
สำหรับ BluetoothAdapter.isLeAudioSupported()
API ระบบจะดำเนินการดังต่อไปนี้
- [C-7-1] ต้องรองรับไคลเอ็นต์ unicast
- [C-7-2] ต้องรองรับ 2M PHY
- [C-7-3] ต้องรองรับการโฆษณา LE Extended
- [C-7-4] ต้องรองรับการเชื่อมต่อ CIS อย่างน้อย 2 รายการใน CIG
- [C-7-5] ต้องเปิดใช้ไคลเอ็นต์ BAP unicast, ผู้ประสานงานชุด CSIP, เซิร์ฟเวอร์ MCP, ตัวควบคุม VCP, เซิร์ฟเวอร์ CCP พร้อมกัน
- [C-SR-1] แนะนําอย่างยิ่งให้เปิดใช้ไคลเอ็นต์ Unicast HAP
หากการติดตั้งใช้งานอุปกรณ์แสดงผล true
สำหรับ BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API ระบบจะดำเนินการดังต่อไปนี้
- [C-8-1] ต้องรองรับลิงก์ BIS อย่างน้อย 2 ลิงก์ใน BIG
- [C-8-2] ต้องเปิดใช้แหล่งที่มาของการออกอากาศ BAP, ผู้ช่วยออกอากาศ BAP พร้อมกัน
- [C-8-3] ต้องรองรับการโฆษณาของ LE Periodic
หากการติดตั้งใช้งานอุปกรณ์แสดงผล true
สำหรับ BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API ระบบจะดำเนินการดังต่อไปนี้
- [C-9-1] ต้องรองรับ PAST (Periodic Advertising Sync Transfer)
- [C-9-2] ต้องรองรับการโฆษณา LE Periodic
การใช้งานอุปกรณ์จะประกาศ FEATURE_BLUETOOTH_LE
ดังต่อไปนี้
- [C-10-1] ต้องมีค่า RSSI ที่อยู่ในช่วง +/-9dB สำหรับ 95% ของการวัดที่ระยะห่าง 1 เมตรจากอุปกรณ์อ้างอิงที่กำลังส่งที่
ADVERTISE_TX_POWER_HIGH
ในสภาพแวดล้อมแนวสายตา - [C-10-2] ต้องรวมการแก้ไข Rx/Tx เพื่อลดการเบี่ยงเบนต่อช่องสัญญาณ เพื่อให้ค่าที่วัดได้ในแต่ละช่องสัญญาณทั้ง 3 เสาอากาศแต่ละเสา (หากใช้หลายสาย) จะอยู่ภายใน +/-3dB ของกันและกันสำหรับค่าที่วัดได้ 95%
- [C-SR-2] ขอแนะนำอย่างยิ่งให้วัดและชดเชยออฟเซ็ต Rx เพื่อให้ค่ามัธยฐานของ BLE RSSI เท่ากับ -60dBm +/-10 dB ที่ระยะห่าง 1 เมตรจากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่
ADVERTISE_TX_POWER_HIGH
โดยที่อุปกรณ์อยู่ในแนว "ระนาบคู่ขนาน" โดยหน้าจอหันไปในทิศทางเดียวกัน - [C-SR-3] ขอแนะนำอย่างยิ่งให้วัดและชดเชยค่าออฟเซ็ต Tx เพื่อให้ค่ามัธยฐานของ BLE RSSI เท่ากับ -60dBm +/-10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในตำแหน่งระยะ 1 เมตรและส่งที่
ADVERTISE_TX_POWER_HIGH
โดยที่อุปกรณ์จะอยู่ในทิศทางเดียวกันโดยอยู่ใน "ระนาบคู่ขนาน" เมื่อหน้าจออยู่ในทิศทางเดียวกัน
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในการปรับเทียบสถานที่ตั้ง
หากอุปกรณ์รองรับบลูทูธเวอร์ชัน 5.0 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้สนับสนุนสิ่งต่อไปนี้
- เล 2 เอ็ม ฟี
- LE Codec PHY
- ส่วนขยายโฆษณา LE
- การโฆษณาตามระยะเวลา
- ชุดโฆษณาอย่างน้อย 10 ชุด
- การเชื่อมต่อพร้อมกันอย่างน้อย 8 LE การเชื่อมต่อแต่ละรายการอาจอยู่ในบทบาท โทโพโลยีการเชื่อมต่ออย่างใดอย่างหนึ่ง
- นโยบายความเป็นส่วนตัวของ LE Link Layer
- ขนาด "รายการที่กำลังแก้ไข" อย่างน้อย 8 รายการ
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)
[C-SR-1] แนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านทางมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC จะระบุว่าเป็น "แนะนำ" อย่างชัดเจน แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" มาตรฐานเหล่านี้ไม่บังคับในเวอร์ชันนี้ แต่จะจำเป็นในเวอร์ชันต่อๆ ไป เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบัติตามข้อกำหนดเหล่านี้ทันทีเพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นใหม่ๆ ในอนาคตได้
[C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นหา NFC
ควรอยู่ในโหมดการค้นหา NFC ในขณะที่อุปกรณ์ทำงานอยู่ขณะที่หน้าจอทำงานอยู่และปลดล็อกหน้าจอล็อกแล้ว
ควรสามารถอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC แบบ Thinfilm
โปรดทราบว่าลิงก์ที่พร้อมใช้งานแบบสาธารณะไม่พร้อมใช้งานสำหรับข้อมูลจำเพาะของ JIS, ISO และ NFC ของฟอรัมที่อ้างถึงข้างต้น
Android มีการสนับสนุนโหมด NFC Host Card Emulation (HCE)
หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NFC และ/หรือ 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 โปรโตคอลและ API ของเครือข่าย
7.4.5.1 ความสามารถของเครือข่ายขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีการรองรับเครือข่ายข้อมูล อย่างน้อย 1 รูปแบบ กล่าวอย่างเจาะจงคือ การใช้งานอุปกรณ์ต้องมีการรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่ความเร็ว 200 Kbit/วินาทีหรือมากกว่านั้น ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต และ PAN บลูทูธ
- ควรรวมการสนับสนุนมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
- อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
7.4.5.2 IPv6
การติดตั้งใช้งานอุปกรณ์
- [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 วินาที
- ต้องตรวจสอบว่าการสื่อสารของ IPv6 มีความเสถียรเหมือนกับ IPv4 ตัวอย่างเช่น
- [C-0-6] ต้องให้แอปพลิเคชันของบุคคลที่สามที่มีการเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดเลยในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น
Socket#getLocalAddress
หรือSocket#getLocalPort
) และ NDK API เช่นgetsockname()
หรือIPV6_PKTINFO
ต้องส่งคืนที่อยู่ IP และพอร์ตที่ใช้จริงเพื่อส่งและรับแพ็กเก็ตในเครือข่ายจริงๆ และแสดงเป็น IP ต้นทางและพอร์ตไปยังอินเทอร์เน็ต (เว็บ)
ระดับการรองรับ IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่ายดังที่แสดงในข้อกำหนดต่อไปนี้
หากอุปกรณ์รองรับ Wi-Fi ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi
การใช้งานอุปกรณ์รองรับอีเทอร์เน็ตจะเป็นดังนี้
- [C-2-1] ต้องรองรับการดำเนินการแบบ 2 สแต็กและ IPv6 เท่านั้นบนอีเทอร์เน็ต
หากอุปกรณ์รองรับข้อมูลเครือข่ายมือถือ ก็จะเป็นดังนี้
- [C-3-1] ต้องรองรับการดำเนินการ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ 2 สแต็ก) ในเครือข่ายมือถือ
หากการติดตั้งใช้งานอุปกรณ์รองรับเครือข่ายมากกว่า 1 ประเภท (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ)
- [C-4-1] ต้องตรงตามข้อกำหนดข้างต้นในแต่ละเครือข่ายพร้อมกัน เมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 ประเภทพร้อมกัน
7.4.5.3 แคพทีฟพอร์ทัล
แคพทีฟพอร์ทัลหมายถึงเครือข่ายที่ต้องมีการลงชื่อเข้าใช้เพื่อให้เชื่อมต่ออินเทอร์เน็ตได้
หากการติดตั้งใช้งานอุปกรณ์ทำให้มีการติดตั้งใช้งาน android.webkit.Webview API
โดยสมบูรณ์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องระบุแอปพลิเคชันแคพทีฟพอร์ทัลเพื่อจัดการ Intent
ACTION_CAPTIVE_PORTAL_SIGN_IN
และแสดงหน้าการเข้าสู่ระบบแคพทีฟพอร์ทัลโดยส่ง Intent ดังกล่าว ไปยัง System APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
- [C-1-2] ต้องดำเนินการตรวจจับแคพทีฟพอร์ทัล และรองรับการเข้าสู่ระบบ ผ่านแอปพลิเคชันแคพทีฟพอร์ทัลเมื่ออุปกรณ์เชื่อมต่อกับ เครือข่ายทุกประเภท รวมถึงเครือข่ายมือถือ/มือถือ, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
- [C-1-3] ต้องรองรับการเข้าสู่ระบบแคพทีฟพอร์ทัลโดยใช้ DNS แบบ cleartext เมื่อกำหนดค่าอุปกรณ์ให้ใช้โหมด DNS แบบเข้มงวดส่วนตัว
- [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสาร SDK สำหรับ
android.net.LinkProperties.getPrivateDnsServerName
และandroid.net.LinkProperties.isPrivateDnsActive
สำหรับการจราจรของข้อมูลในเครือข่ายทั้งหมดที่ไม่ได้สื่อสารกับแคพทีฟพอร์ทัลอย่างชัดเจน - [C-1-5] ต้องตรวจสอบว่าขณะที่ผู้ใช้ลงชื่อเข้าสู่ระบบแคพทีฟพอร์ทัล เครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
แสดงผลและมีการใช้งานโดย API เครือข่าย Java เช่น java.net.Socket และ API แบบเนทีฟ เช่น Connect()) เป็นเครือข่ายอื่นที่ให้การเข้าถึงอินเทอร์เน็ตได้ (หากมี)
7.4.6 การตั้งค่าการซิงค์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเปิดการตั้งค่าการซิงค์อัตโนมัติหลักไว้โดยค่าเริ่มต้นเพื่อให้เมธอด
getMasterSyncAutomatically()
แสดงค่า "true"
7.4.7 ประหยัดอินเทอร์เน็ต
หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อแบบจำกัดปริมาณ ระบบจะดำเนินการดังต่อไปนี้
- [C-SR-1] แนะนำอย่างยิ่งให้ใช้โหมดประหยัดอินเทอร์เน็ต
หากการติดตั้งใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ API ทั้งหมดในคลาส
ConnectivityManager
ตามที่อธิบายไว้ในเอกสารประกอบ SDK
หากอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต ระบบจะดำเนินการดังนี้
- [C-2-1] ต้องแสดงค่า
RESTRICT_BACKGROUND_STATUS_DISABLED
สำหรับConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] ต้องไม่ออกอากาศ
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
7.4.8 องค์ประกอบความปลอดภัย
หากการใช้งานอุปกรณ์รองรับองค์ประกอบความปลอดภัยที่ใช้ Open Mobile API ได้และทำให้ใช้งานในแอปของบุคคลที่สามได้ การดำเนินการดังกล่าวจะส่งผลดังนี้
[C-1-1] ต้องแจกแจงผู้อ่านองค์ประกอบความปลอดภัยที่ใช้ได้ผ่าน
android.se.omapi.SEService.getReaders()
API[C-1-2] ต้องประกาศแฟล็กฟีเจอร์ที่ถูกต้องผ่าน
android.hardware.se.omapi.uicc
สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยตาม UICCandroid.hardware.se.omapi.ese
สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยแบบ eSE และandroid.hardware.se.omapi.sd
สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยแบบ SD
7.4.9 UWB
หากการใช้งานอุปกรณ์รวมการรองรับ 802.1.15.4 และมีฟังก์ชันการทำงานนี้ให้แอปพลิเคชันของบุคคลที่สามแสดง ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องใช้ Android API ที่สอดคล้องกันใน android.uwb
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
- [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่กำหนดไว้ใน การใช้งาน Android
- [C-1-4] ต้องระบุค่าบริการเพื่อให้ผู้ใช้สามารถสลับสถานะเปิด/ปิดวิทยุ UWB
- [C-1-5] ต้องบังคับใช้การใช้สิทธิ์ UWB_RANGING ของแอปโดยใช้สิทธิ์ UWB_RANGING ของแอป (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)
[C-SR-1] ขอแนะนำอย่างยิ่งให้ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องซึ่งกำหนดโดยองค์กรมาตรฐาน รวมถึง FIRA, CCC และ CSA
- [C-1-6] ต้องตรวจสอบว่าการวัดระยะทางอยู่ภายใน +/-15 ซม. สำหรับ 95% ของการวัดในแนวสายตาที่ระยะห่าง 1 ม. ในห้องที่ไม่สะท้อน
- [C-1-7] ต้องตรวจสอบว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายใน [0.75 ม., 1.25 ม.] โดยวัดระยะทางความจริงของพื้นจากขอบด้านบนของ DUT ที่ถือขึ้นโดยหงายขึ้นและเอียง 45 องศา
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ทำตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในการปรับเทียบสถานที่ตั้ง
7.5 กล้อง
หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.camera.any
- [C-1-2] ต้องเป็นไปได้ที่แอปพลิเคชันจะจัดสรร RGBA_8888 บิตแมป 3 รายการพร้อมกันให้เท่ากับขนาดของภาพที่เกิดจากเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์ ในขณะที่กล้องเปิดอยู่เพื่อให้แสดงตัวอย่างเบื้องต้นและยังคงจับภาพได้
- [C-1-3] ต้องตรวจสอบว่าแอปพลิเคชันกล้องเริ่มต้นที่ติดตั้งไว้ล่วงหน้า
การจัดการ Intent
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
หรือMediaStore.ACTION_VIDEO_CAPTURE
มีหน้าที่นำตำแหน่งผู้ใช้ในข้อมูลเมตาของรูปภาพ ออกก่อนที่จะส่งไปยังแอปพลิเคชันที่ใช้รับเมื่อแอปพลิเคชันที่ใช้รับไม่มีACCESS_FINE_LOCATION
หากอุปกรณ์รองรับความสามารถในการเอาต์พุต HDR 10 บิต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์ HLG HDR เป็นอย่างน้อยสำหรับอุปกรณ์กล้องทุกตัวที่รองรับเอาต์พุต 10 บิต
- [C-2-2] ต้องรองรับเอาต์พุต 10 บิตสำหรับกล้องหลังหรือกล้องหน้าหลัก
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอาต์พุต 10 บิตสำหรับกล้องหลักทั้ง 2 ตัว
- [C-2-3] ต้องรองรับโปรไฟล์ HDR เดียวกันสำหรับกล้องย่อยตัวจริงที่รองรับ BACKWARD_COMPATIBLE ของกล้องตรรกะ และกล้องตรรกะเอง
สำหรับอุปกรณ์กล้อง Logical ที่รองรับ HDR 10 บิตที่ใช้ android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้
- [C-3-1] ต้องรองรับการสลับระหว่างกล้องตัวจริงที่เข้ากันได้แบบย้อนหลังทั้งหมดผ่านตัวควบคุม
CONTROL_ZOOM_RATIO
ในกล้องตรรกะ
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] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ กล้องถ่ายรูป 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] ต้องประกาศ Flag ฟีเจอร์ของแพลตฟอร์ม
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 แพ็กเกจสำหรับเข้าถึงกล้อง ซึ่งได้แก่ android.hardware.camera2 API เวอร์ชันใหม่จะเผยการควบคุมกล้องในระดับล่างออกมาแก่แอป ซึ่งรวมถึงโฟลว์ภาพถ่ายอัจฉริยะ/การสตรีมแบบไม่คัดลอกเนื้อหา และการควบคุมภาพต่อเฟรม, อัตราขยาย, การเพิ่มสมดุลแสงขาว, การแปลงสี, การตัดเสียงรบกวน, การทำภาพให้คมชัด และอีกมากมาย
แพ็กเกจ API เก่า android.hardware.Camera
มีการทำเครื่องหมายเป็นเลิกใช้งานใน Android 5.0 แต่เนื่องจากควรจะยังพร้อมใช้งานสำหรับแอปได้ การใช้งานอุปกรณ์ Android ต้องดูแลให้มีการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK
ฟีเจอร์ทั้งหมดที่มีการใช้งานร่วมกันในคลาส android.hardware.camera และแพ็กเกจ android.hardware.camera2 รุ่นที่ใหม่กว่าต้องมีประสิทธิภาพและคุณภาพเทียบเท่ากันใน API ทั้งสอง เช่น ด้วยการตั้งค่าที่เทียบเท่ากัน ความเร็วในการโฟกัสอัตโนมัติและความแม่นยำต้องเหมือนกัน และคุณภาพของรูปภาพที่จับภาพต้องเหมือนกัน ฟีเจอร์ที่ต้องอาศัยความหมายที่ต่างกันของ 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.camera2.CaptureRequest
ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยึดตามหรือรับรู้ค่าคงที่สตริงที่ส่งไปยังเมธอดandroid.hardware.Camera.setParameters()
ที่ไม่ใช่ค่าคงที่ที่ระบุเป็นค่าคงที่ในandroid.hardware.Camera.Parameters
กล่าวคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง เช่น การใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการสร้างภาพของ High Dynamic Range (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-0-11] ต้องมีกล้องทุกตัวที่เข้าถึงได้ผ่านทาง API ที่เลิกใช้งานแล้ว
android.hardware.Camera
API ยังเข้าถึงได้ผ่านandroid.hardware.camera2
API ด้วย - [C-0-12] ต้องตรวจสอบว่าลักษณะใบหน้าไม่ได้เปลี่ยนแปลง ซึ่งรวมถึงแต่ไม่จำกัดเพียงการปรับเปลี่ยนรูปเรขาคณิต สีผิวหน้า หรือการปรับผิวหน้าให้เรียบเนียนสำหรับ
android.hardware.camera2
หรือandroid.hardware.Camera
API - [C-SR-1] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัวที่หันไปในทิศทางเดียวกัน ขอแนะนำเป็นอย่างยิ่งให้รองรับอุปกรณ์กล้องเชิงตรรกะที่แสดงความสามารถ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปในทิศทางเดียวกันว่าเป็นอุปกรณ์ย่อยจริง
หากอุปกรณ์ให้ API กล้องที่เป็นกรรมสิทธิ์แก่แอปของบุคคลที่สาม การใช้งานจะทำสิ่งต่อไปนี้
- [C-1-1] ต้องใช้ API กล้องดังกล่าวโดยใช้
android.hardware.camera2
API - อาจให้แท็กผู้ให้บริการและ/หรือส่วนขยายแก่
android.hardware.camera2
API
7.5.5 การวางแนวกล้อง
หากอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าว
- [C-1-1] ต้องวางแนวเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับด้านยาวของหน้าจอ กล่าวคือ เมื่ออุปกรณ์อยู่ในแนวนอน กล้องจะต้องจับภาพในแนวนอน โดยจะใช้กับอุปกรณ์ไม่ว่าการวางแนวตามปกติของอุปกรณ์จะเป็นอย่างไรก็ตาม กล่าวคือมีผลกับอุปกรณ์หลักแนวนอนและอุปกรณ์หลักแนวตั้ง
อุปกรณ์ที่มีคุณสมบัติตรงตามเกณฑ์ต่อไปนี้ทั้งหมดจะได้รับการยกเว้นจากข้อกำหนดข้างต้น
- อุปกรณ์ใช้หน้าจอที่มีเรขาคณิตหลากหลายแบบ เช่น จอแสดงผลแบบพับได้หรือแบบบานพับ
- เมื่อสถานะการพับหรือบานพับของอุปกรณ์เปลี่ยนไป อุปกรณ์จะเปลี่ยนระหว่างการวางแนวแนวตั้ง-หลักเป็นแนวนอน-หลัก (หรือกลับกัน)
7.6 หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1 หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมี Download Manager ที่แอปพลิเคชันอาจใช้ในการดาวน์โหลดไฟล์ข้อมูล และต้องดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้นได้
7.6.2 พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยแอปพลิเคชัน หรือมักเรียกว่า "ที่จัดเก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน" หรือเส้นทาง Linux "/sdcard" ที่ต่อเชื่อมอยู่
- [C-0-2] ต้องกำหนดค่าโดยใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันแบบต่อเชื่อมโดยค่าเริ่มต้น หรือเรียกอีกอย่างหนึ่งว่า "พร้อมใช้งานทันที" ไม่ว่าจะมีการใช้งานพื้นที่เก็บข้อมูลบนคอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ดดิจิทัลที่ปลอดภัย)
- [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชันบนเส้นทาง Linux โดยตรง
sdcard
หรือรวมลิงก์สัญลักษณ์ของ Linux จากsdcard
ไปยังจุดต่อเชื่อมจริง - [C-0-4] ต้องเปิดใช้พื้นที่เก็บข้อมูลที่กำหนดขอบเขตโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กําหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในสถานการณ์ต่อไปนี้
- เมื่อแอปขอ
android:requestLegacyExternalStorage="true"
ในไฟล์ Manifest
- เมื่อแอปขอ
- [C-0-5] ต้องปกปิดข้อมูลเมตาของตำแหน่ง เช่น แท็ก GPS Exif ซึ่งจัดเก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์ดังกล่าวผ่าน
MediaStore
ยกเว้นในกรณีที่แอปการโทรจะถือสิทธิ์ACCESS_MEDIA_LOCATION
การใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้ข้อใดข้อหนึ่งต่อไปนี้
- พื้นที่เก็บข้อมูลแบบถอดได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
- ส่วนหนึ่งของพื้นที่เก็บข้อมูลภายใน (แบบถอดออกได้) ตามที่ใช้ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP)
หากมีการใช้อุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดได้เพื่อให้เป็นไปตามข้อกำหนดข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องใช้ข้อความโทสต์หรือป๊อปอัปคำเตือนอินเทอร์เฟซผู้ใช้ เมื่อไม่มีสื่อการเก็บข้อมูลในช่องแทรก
- [C-1-2] ต้องใส่สื่อการเก็บข้อมูลรูปแบบ FAT (เช่น การ์ด SD) หรือแสดงไว้บนกล่องและวัสดุอื่นๆ ที่มีอยู่ ณ เวลาที่ซื้อซึ่งต้องซื้อสื่อสำหรับจัดเก็บข้อมูลแยกต่างหาก
หากการใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดไม่ได้ส่วนหนึ่งตามข้อกำหนดข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรใช้การใช้งาน AOSP ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายใน
- อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน
หากอุปกรณ์มีพอร์ต 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
หากอุปกรณ์ควรมีลักษณะเป็นอุปกรณ์เคลื่อนที่ซึ่งต่างจากทีวี การใช้งานอุปกรณ์จะเป็นดังนี้
- [C-SR-1] แนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลที่สามารถนำมาใช้ได้ในตำแหน่งที่เสถียรระยะยาว เนื่องจากการถอดการเชื่อมต่อโดยไม่ได้ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย
หากพอร์ตของอุปกรณ์จัดเก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่มั่นคงในระยะยาว เช่น ภายในช่องใส่แบตเตอรี่หรือฝาครอบป้องกันอื่นๆ การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-SR-2] แนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลที่สามารถนำมาใช้ได้
7.7 USB
หากการใช้งานอุปกรณ์มีพอร์ต USB สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB
- ควรรองรับการปิดใช้การส่งสัญญาณข้อมูลผ่าน USB
7.7.1 โหมดอุปกรณ์ต่อพ่วง USB
หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
- [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB แบบ type-A หรือ type-C แบบมาตรฐานได้
- [C-1-2] ต้องรายงานค่า
iSerialNumber
ที่ถูกต้องในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ผ่านandroid.os.Build.SERIAL
- [C-1-3] ต้องตรวจหาที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และ "ต้องตรวจจับการเปลี่ยนแปลงในโฆษณา" หากรองรับ USB Type-C
- [C-SR-1] พอร์ตควรใช้รูปแบบ micro-B, micro-AB หรือ Type-C USB เราแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่ปฏิบัติตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [C-SR-2] พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวตามธรรมชาติ) หรือเปิดใช้งานการหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้แสดงผลได้อย่างถูกต้องเมื่ออุปกรณ์วางอยู่ในแนวเดียวกับพอร์ตที่ด้านล่าง เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [C-SR-3] ควรใช้การสนับสนุนเพื่อดึงกระแสไฟฟ้า 1.5 A ระหว่างเสียงร้องเตือน HS และการจราจรของข้อมูลตามที่ระบุไว้ในข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 เราแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่ปฏิบัติตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
- [C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้ไม่รองรับวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของซิงก์/แหล่งที่มาอาจทำให้เกิดปัญหาด้านความสามารถในการทำงานร่วมกันกับที่ชาร์จหรืออุปกรณ์ที่รองรับวิธีการส่งพลังงาน USB แบบมาตรฐาน แม้จะเรียกว่า "แนะนำอย่างยิ่ง" แต่สำหรับ Android เวอร์ชันต่อๆ ไป เราอาจต้องใช้อุปกรณ์ type-C ทั้งหมดเพื่อรองรับความสามารถในการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C แบบมาตรฐาน
- [C-SR-5] แนะนำอย่างยิ่งให้รองรับ 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 ขนาดใหญ่ - ไม่ควรใช้เสียง AOAv2 ที่ระบุในเอกสารประกอบ Android Open Accessory Protocol 2.0 เสียง AOAv2 เลิกใช้งานแล้วตั้งแต่ Android เวอร์ชัน 8.0 (API ระดับ 26)
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 เป็นพอร์ตประเภท C (เต้ารับ)
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
- ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะที่อยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของการแก้ไขข้อมูลจำเพาะของสาย USB Type-C และหัวต่อ 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงเอาต์พุตของการชาร์จพอร์ตดาวน์สตรีม(CDP) ตามที่ระบุไว้ในข้อมูลจำเพาะของการชาร์จสาย 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) สำหรับ Dual Role Ports ในอุปกรณ์ที่มีช่องเสียบเสียง 3.5 มม. การตรวจหาซิงก์ USB (โหมดโฮสต์) อาจปิดอยู่โดยค่าเริ่มต้น แต่ผู้ใช้ต้องเปิดใช้ได้
- [C-SR-2] ขอแนะนำให้รองรับ DisplayPort และควรรองรับอัตราข้อมูล SuperSpeed ของ USB และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
- [C-SR-3] แนะนำอย่างยิ่งให้ไม่รองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก 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
- [C-SR-1] แนะนำอย่างยิ่งให้รองรับการบันทึกภาพด้วยอัลตราซาวด์ ดังที่อธิบายไว้ในส่วนที่ 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
- [C-SR-1] แนะนำอย่างยิ่งให้สนับสนุนการเล่นอัลตราซาวด์ในระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 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] ขอแนะนำอย่างยิ่งให้รวมพอร์ตเสียงอย่างน้อย 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-2] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
- [C-SR-3] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอพร้อมไมโครโฟน
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัวและรองรับไมโครโฟน และประกาศ android.intent.action.HEADSET_PLUG
ด้วยการตั้งค่าไมโครโฟนค่าพิเศษเป็น 1 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับการตรวจจับไมโครโฟนบน อุปกรณ์เสริมสำหรับเสียงที่เสียบอยู่
7.8.2.2 พอร์ตเสียงดิจิทัล
โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2.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.8.4 ความสมบูรณ์ของสัญญาณ
การติดตั้งใช้งานอุปกรณ์
- ควรมีเส้นทางสัญญาณเสียงที่ไม่มีข้อบกพร่องสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์มือถือ ตามที่กำหนดโดยข้อบกพร่อง 0 รายการที่วัดได้ระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ OboeTester "Automated Glitch Test"
การทดสอบต้องใช้ดองเกิลเสียงวนซ้ำซึ่งใช้ในช่องเสียบ 3.5 มม. โดยตรงและ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด
ปัจจุบัน OboeTester รองรับเส้นทาง AAudio ดังนั้น คุณควรทดสอบชุดค่าผสมต่อไปนี้เพื่อหาข้อบกพร่องโดยใช้ AAudio
โหมด Perf | การแชร์ | อัตราการสุ่มตัวอย่างออก | ในชาน | เพลงชวนคุย |
---|---|---|---|---|
เวลาในการตอบสนองต่ำ | พิเศษ | ไม่ได้ระบุ | 1 | 2 |
เวลาในการตอบสนองต่ำ | พิเศษ | ไม่ได้ระบุ | 2 | 1 |
เวลาในการตอบสนองต่ำ | แชร์ | ไม่ได้ระบุ | 1 | 2 |
เวลาในการตอบสนองต่ำ | แชร์ | ไม่ได้ระบุ | 2 | 1 |
ไม่มี | แชร์ | 48000 | 1 | 2 |
ไม่มี | แชร์ | 48000 | 2 | 1 |
ไม่มี | แชร์ | 44100 | 1 | 2 |
ไม่มี | แชร์ | 44100 | 2 | 1 |
ไม่มี | แชร์ | 16000 | 1 | 2 |
ไม่มี | แชร์ | 16000 | 2 | 1 |
สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อเสียงรบกวน (SNR) และการบิดเบี้ยวรวมฮาร์โมนิก (THD) สำหรับไซน์ 2000 Hz
ตัวแปรสัญญาณ | THD | SNR |
---|---|---|
ลำโพงหลักในตัว วัดโดยใช้ไมโครโฟนอ้างอิงภายนอก | น้อยกว่า 3.0% | >= 50 เดซิเบล |
ไมโครโฟนหลักในตัว วัดโดยใช้ลำโพงอ้างอิงภายนอก | น้อยกว่า 3.0% | >= 50 เดซิเบล |
ช่องเสียบแบบแอนะล็อกในตัว 3.5 มม. ผ่านการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ | < 1% | >= 60 เดซิเบล |
อะแดปเตอร์ USB ที่ให้มาพร้อมกับโทรศัพท์ ได้รับการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ | น้อยกว่า 1.0% | >= 60 เดซิเบล |
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_EXT_protected_textures
และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน - [C-SR-1] แนะนําอย่างยิ่งให้ใช้
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
และแสดงส่วนขยายในรายการส่วนขยาย GL ที่มีให้บริการ - [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
- [C-SR-3] แนะนําอย่างยิ่งให้ใช้
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
และเปิดเผยในรายการส่วนขยาย Vulkan ที่มี - [C-SR-4] ขอแนะนำอย่างยิ่งให้แสดงกลุ่มคิว 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-5] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร
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 ที่อัตรา 30 fps - 20 fps เป็น 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-6] แนะนำอย่างยิ่งให้ใช้ความละเอียดในการแสดงผลอย่างน้อย 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-7] ขอแนะนำอย่างยิ่งให้รองรับประเภทแชแนลโดยตรง
TYPE_HARDWARE_BUFFER
สำหรับประเภทแชแนลโดยตรงทั้งหมดที่ระบุไว้ข้างต้น - [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ
android.hardware.hifi_sensors
ตามที่ระบุไว้ในส่วนที่ 7.3.9 - [C-SR-8] แนะนําอย่างยิ่งให้รองรับฟีเจอร์
android.hardware.sensor.hifi_sensors
- [C-1-22] ต้องมีเวลาในการตอบสนองของการเคลื่อนไหวจากต้นทางถึงปลายทางเป็นโฟตอนไม่สูงกว่า 28 มิลลิวินาที
- [C-SR-9] แนะนำอย่างยิ่งให้มีการเปลี่ยนแปลงการเคลื่อนไหวจากต้นทางถึงปลายทางต่อเวลาในการตอบสนองของโฟตอน ไม่เกิน 20 มิลลิวินาที
- [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวและความสว่างของพิกเซลสีขาวในสถานะคงที่อย่างน้อย 85%
- [C-SR-10] แนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
- อาจให้แกนเอกสิทธิ์เฉพาะสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าและอาจรองรับ
Process.getExclusiveCores
API เพื่อแสดงจำนวนของแกน CPU ที่มีเฉพาะในแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าเท่านั้น
หากระบบรองรับแกนพิเศษ แกนหลักจะเป็นดังนี้
- [C-2-1] ต้องไม่อนุญาตให้กระบวนการพื้นที่ผู้ใช้อื่นๆ ทำงานบนขั้นตอนดังกล่าว (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่อาจอนุญาตให้การประมวลผลเคอร์เนลบางรายการทำงานตามความจำเป็น
7.10 การโต้ตอบการสัมผัส
โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2.2.1
7.11 ชั้นเรียนประสิทธิภาพของสื่อ
สามารถดูระดับประสิทธิภาพของสื่อของการใช้งานอุปกรณ์ได้จาก API ของ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
จะมีการกำหนดข้อกำหนดสำหรับคลาสประสิทธิภาพสื่อสำหรับ Android แต่ละเวอร์ชันที่ขึ้นต้นด้วย R (เวอร์ชัน 30) ค่าพิเศษ 0 ระบุว่าอุปกรณ์ไม่ใช่คลาสประสิทธิภาพของสื่อ
หากการติดตั้งใช้งานอุปกรณ์แสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการต่อไปนี้
[C-1-1] ต้องแสดงค่า
android.os.Build.VERSION_CODES.R
เป็นอย่างน้อย[C-1-2] ต้องเป็นการใช้งานอุปกรณ์พกพา
[C-1-3] ต้องเป็นไปตามข้อกำหนดทั้งหมดสำหรับ "คลาสประสิทธิภาพของสื่อ" ที่อธิบายไว้ในส่วนที่ 2.2.7
กล่าวคือ คลาสประสิทธิภาพของสื่อใน Android T ได้รับการกำหนดไว้สำหรับอุปกรณ์พกพาในเวอร์ชัน T, S หรือ R เท่านั้น
โปรดดูส่วนที่ 2.2.7 สำหรับข้อกำหนดเฉพาะอุปกรณ์
8. ประสิทธิภาพและศักยภาพ
เกณฑ์ด้านประสิทธิภาพขั้นต่ำและเกณฑ์กำลังมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาซอฟต์แวร์จะมีเมื่อพัฒนาแอป
8.1 ความสม่ำเสมอของประสบการณ์ของผู้ใช้
ผู้ใช้ปลายทางมีอินเทอร์เฟซผู้ใช้ที่ราบรื่นหากมีข้อกำหนดขั้นต่ำบางประการเพื่อให้อัตราเฟรมและเวลาในการตอบสนองสอดคล้องกันสำหรับแอปพลิเคชันและเกม การใช้งานอุปกรณ์อาจมีข้อกำหนดที่วัดได้สำหรับเวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้และการสลับงานตามที่อธิบายไว้ในส่วนที่ 2 ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์
8.2 ประสิทธิภาพการเข้าถึงไฟล์ I/O
การระบุพื้นฐานทั่วไปสำหรับประสิทธิภาพการเข้าถึงไฟล์ที่สอดคล้องกันในพื้นที่เก็บข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data
) ช่วยให้นักพัฒนาแอปสร้างความคาดหวังที่เหมาะสมซึ่งจะช่วยในการออกแบบซอฟต์แวร์ของตนได้ การใช้งานอุปกรณ์อาจมีข้อกำหนดบางอย่างซึ่งอธิบายไว้ในส่วนที่ 2 สำหรับการดำเนินการอ่านและเขียนต่อไปนี้ ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์
- ประสิทธิภาพการเขียนตามลำดับ วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
- ประสิทธิภาพการเขียนแบบสุ่ม วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
- ประสิทธิภาพการอ่านตามลำดับ วัดจากการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
- ประสิทธิภาพการอ่านแบบสุ่ม วัดจากการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4KB
8.3 โหมดประหยัดพลังงาน
หากการใช้งานอุปกรณ์มีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP (เช่น ที่เก็บข้อมูลสแตนด์บายแอป, Doze) หรือขยายฟีเจอร์ต่างๆ เพื่อใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ถูกจำกัด การดำเนินการดังกล่าวจะส่งผลดังต่อไปนี้
- [C-1-1] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการทริกเกอร์ การบำรุงรักษา อัลกอริทึมการปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางหรือ DeviceConfig ของโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
- [C-1-2] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางหรือ DeviceConfig เพื่อจัดการการควบคุมงาน สัญญาณเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสำหรับการสแตนด์บายแอป
- [C-1-3] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับจำนวนที่เก็บข้อมูลสแตนด์บายแอปที่ใช้สำหรับสแตนด์บายแอป
- [C-1-4] ต้องใช้ที่เก็บข้อมูลสแตนด์บายแอปและ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
- [C-1-5] ต้องส่งคืน
true
สำหรับPowerManager.isPowerSaveMode()
เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน - [C-1-6] ต้องมีค่าใช้จ่ายสำหรับผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้น จากโหมดสแตนด์บายแอปและ Doze หรือการเพิ่มประสิทธิภาพแบตเตอรี่ใดๆ และต้องใช้ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS ในการขอให้ผู้ใช้อนุญาตให้แอปละเว้นการเพิ่มประสิทธิภาพแบตเตอรี่
- [C-SR-1] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้สามารถเปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
- [C-SR-2] ขอแนะนำเป็นอย่างยิ่งว่าจะแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
หากการนำอุปกรณ์ไปใช้งานขยายขอบเขตฟีเจอร์การจัดการพลังงานที่รวมอยู่ใน AOSP และส่วนขยายดังกล่าวใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลสแตนด์บายแอป Rare โปรดดูส่วนที่ 3.5.1
นอกจากโหมดประหยัดพลังงานแล้ว การติดตั้งใช้งานอุปกรณ์ Android อาจใช้สถานะกำลังนอนหลับส่วนใดส่วนหนึ่งหรือทั้งหมด 4 แบบตามที่กำหนดโดยการกำหนดค่าขั้นสูงและอินเทอร์เฟซพลังงาน (ACPI)
หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟ S4 ตามที่กำหนดโดย ACPI มีดังนี้
- [C-1-1] ต้องป้อนสถานะนี้หลังจากที่ผู้ใช้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ใช้งานเท่านั้น (เช่น ปิดฝาที่ชิ้นส่วนของอุปกรณ์หรือปิดยานพาหนะหรือโทรทัศน์) และก่อนที่ผู้ใช้จะเปิดใช้งานอุปกรณ์อีกครั้ง (เช่น โดยเปิดฝาหรือเปิดรถยนต์หรือโทรทัศน์)
หากการติดตั้งใช้งานอุปกรณ์มีสถานะพลังงาน 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 การทำบัญชีการใช้พลังงาน
การทำบัญชีและการรายงานการใช้พลังงานที่ถูกต้องแม่นยำมากขึ้นจะทำให้นักพัฒนาแอปได้รับทั้งสิ่งจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] แนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ซึ่งกำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
- [C-SR-2] แนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [C-SR-3] แนะนำอย่างยิ่งให้รายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ
โปรเจ็กต์โอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนล
uid_cputime
- [C-SR-4] แนะนำอย่างหนักเพื่อให้การใช้พลังงานนี้พร้อมใช้งานผ่านคำสั่งเชลล์
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 แกนขึ้นไป การใช้งานจะมีลักษณะดังต่อไปนี้
- ควรระบุแกนพิเศษอย่างน้อย 1 รายการที่แอปพลิเคชันพื้นฐานอันดับต้นๆ จองได้
หากการใช้งานอุปกรณ์รองรับการจองแกนพิเศษ 1 แกนสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า จะมีการดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงานหมายเลขรหัสของแกนพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนจองได้ผ่านเมธอด
Process.getExclusiveCores()
API - [C-2-2] ต้องไม่อนุญาตให้กระบวนการด้านพื้นที่ของผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้ให้ทำงานบนแกนเฉพาะ แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น
หากอุปกรณ์ไม่รองรับการใช้งานอุปกรณ์หลัก (พิเศษ) ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้องแสดงผลรายการที่ว่างเปล่าผ่านทางเมธอด API ของ
Process.getExclusiveCores()
9. ความเข้ากันได้กับโมเดลความปลอดภัย
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารสำหรับนักพัฒนาซอฟต์แวร์ Android
[C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงชื่อด้วยตนเอง โดยไม่ต้องมีสิทธิ์/ใบรับรองเพิ่มเติมใดๆ จากบุคคลที่สาม/หน่วยงาน
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.security.model.compatible
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับข้อกำหนดที่ระบุไว้ในส่วนย่อยต่อไปนี้
9.1 สิทธิ์
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องรองรับโมเดลสิทธิ์ของ Android และ Android Roles Model ตามที่ระบุไว้ในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ Android กล่าวอย่างเจาะจงคือ ต้องบังคับใช้สิทธิ์และบทบาทแต่ละรายการตามที่กำหนดไว้ในเอกสาร SDK ไม่อนุญาตให้ละ แก้ไข หรือละเว้นสิทธิ์และบทบาทใดๆ
อาจเพิ่มสิทธิ์เพิ่มเติม หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ
android.\*
[C-0-2] สิทธิ์ที่มี
protectionLevel
เป็นPROTECTION_FLAG_PRIVILEGED
ต้องให้แก่แอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบ (รวมถึงไฟล์ APEX) เท่านั้น และอยู่ภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและยึดตามสิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทางsystem/priv-app
etc/permissions/
และ
สิทธิ์ที่มีระดับการป้องกันที่เป็นอันตรายคือสิทธิ์รันไทม์
แอปพลิเคชันที่มี targetSdkVersion
> 22 จะขอขณะรันไทม์
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะสำหรับผู้ใช้เพื่อตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอไหม และมีอินเทอร์เฟซให้ผู้ใช้จัดการสิทธิ์รันไทม์หรือไม่
- [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงรายการเดียวเท่านั้น หากการใช้อุปกรณ์รองรับอุปกรณ์ที่ใช้ร่วมกัน อุปกรณ์ดังกล่าวอาจมีอินเทอร์เฟซเพิ่มเติมให้
[C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอป ยกเว้นในกรณีต่อไปนี้
- โดยจะติดตั้งไว้แล้วเมื่อมีการจัดส่งอุปกรณ์ และ
จะขอคำยินยอมจากผู้ใช้ได้ ก่อนที่แอปพลิเคชันจะใช้สิทธิ์นั้น
หรือ
สิทธิ์รันไทม์มาจากนโยบายการให้สิทธิ์เริ่มต้นหรือสำหรับการคงบทบาทแพลตฟอร์ม
[C-0-6] ต้องให้สิทธิ์
android.permission.RECOVER_KEYSTORE
แก่แอประบบที่ลงทะเบียน Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างถูกต้องเท่านั้น Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างเหมาะสมหมายถึง Agent ซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งมาพร้อมกับฮาร์ดแวร์ที่ปลอดภัยซึ่งมีการปกป้องเทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key ห้องนิรภัย เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซในปัจจัยที่เกี่ยวข้องกับหน้าจอล็อก
การติดตั้งใช้งานอุปกรณ์
[C-0-7] ต้องปฏิบัติตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android เมื่อแอปขอข้อมูลตำแหน่งหรือการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้
- ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด) ตามที่อธิบายไว้ในส่วนที่ 9.8.8
- ข้อมูลที่ใช้พิจารณาหรือประมาณตำแหน่งของอุปกรณ์ได้ (เช่น SSID, BSSID, รหัสมือถือ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
- กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจัดประเภทกิจกรรมการเคลื่อนไหวร่างกาย
กล่าวอย่างเจาะจงคือ การติดตั้งใช้งานอุปกรณ์มีดังนี้
- [C-0-8] ต้องได้รับความยินยอมจากผู้ใช้ในการอนุญาตให้แอปเข้าถึงข้อมูลตำแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
- [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มีสิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น
ตัวอย่างเช่น TelephonyManager#getServiceState ต้องมี
android.permission.ACCESS_FINE_LOCATION
)
ข้อยกเว้นเพียงอย่างเดียวสำหรับพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android ข้างต้นคือสำหรับแอปที่ไม่ได้เข้าถึงตำแหน่งเพื่อตรวจหาหรือระบุตำแหน่งของผู้ใช้ โดยเฉพาะอย่างยิ่ง
- เมื่อแอปถือสิทธิ์
RADIO_SCAN_WITHOUT_LOCATION
- เพื่อวัตถุประสงค์ในการกำหนดค่าและการตั้งค่าอุปกรณ์ โดยแอประบบถือสิทธิ์
NETWORK_SETTINGS
หรือNETWORK_SETUP_WIZARD
ระบบอาจทำเครื่องหมายสิทธิ์ว่า "จำกัด" ซึ่งจะเปลี่ยนลักษณะการทำงานของสิทธิ์
[C-0-10] สิทธิ์ที่มีเครื่องหมายแฟล็ก
hardRestricted
ต้องไม่ ให้สิทธิ์กับแอป เว้นแต่จะ- ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
- ผู้ใช้มอบหมายบทบาทที่เชื่อมโยงกับสิทธิ์
hardRestricted
ให้กับแอป - โปรแกรมติดตั้งให้สิทธิ์
hardRestricted
แก่แอป - แอปได้รับสิทธิ์
hardRestricted
ใน Android เวอร์ชันก่อนหน้า
[C-0-11] แอปที่ถือสิทธิ์
softRestricted
ต้องได้รับสิทธิ์เข้าถึงแบบจำกัดเท่านั้น และต้องไม่รับสิทธิ์เข้าถึงโดยสมบูรณ์จนกว่าจะได้รับอนุญาตตามที่อธิบายไว้ใน SDK ซึ่งกำหนดสิทธิ์เข้าถึงแบบเต็มและแบบจำกัดสำหรับสิทธิ์softRestricted
แต่ละรายการ (เช่นREAD_EXTERNAL_STORAGE
)[C-0-12] ต้องไม่มีฟังก์ชันหรือ API ที่กำหนดเองเพื่อข้ามการจำกัดสิทธิ์ที่กำหนดไว้ใน setPermissionsPolicy และ setPermissionsGrantState API
[C-0-13] ต้องใช้ AppOpsManager API เพื่อบันทึกและติดตาม การเข้าถึงแบบเป็นโปรแกรมแต่ละครั้งของข้อมูลที่ได้รับการป้องกันโดยสิทธิ์ที่เป็นอันตรายจาก กิจกรรมและบริการของ Android
[C-0-14] ต้องมอบหมายบทบาทให้แอปพลิเคชันที่มีฟังก์ชันตรงตามข้อกำหนดของบทบาทเท่านั้น
[C-0-15] ต้องไม่กำหนดบทบาทที่ซ้ำกันหรือฟังก์ชันการทำงานพิเศษของบทบาทที่กำหนดโดยแพลตฟอร์ม
หากอุปกรณ์รายงานว่า android.software.managed_users
จะเกิดสิ่งต่อไปนี้
- [C-1-1] ต้องไม่มีสิทธิ์ต่อไปนี้ซึ่งผู้ดูแลระบบมอบให้โดยไม่มีการแจ้งเตือน
- ตำแหน่ง (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
- กล้อง (CAMERA)
- ไมโครโฟน (RECORD_AUDIO)
- เซ็นเซอร์ร่างกาย (BODY_SENSORS)
- การเคลื่อนไหวร่างกาย (ACTIVITY_RECOGNITION)
หากการติดตั้งใช้งานอุปกรณ์ช่วยให้ผู้ใช้เลือกได้ว่าแอปใดจะแสดงก่อนแอปอื่นๆ ด้วยกิจกรรมที่จัดการความตั้งใจของ ACTION_MANAGE_OVERLAY_PERMISSION
ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง Intent สำหรับ
ACTION_MANAGE_OVERLAY_PERMISSION
มีหน้าจอ UI เดียวกัน โดยไม่คำนึงถึงแอปที่เริ่มต้นหรือข้อมูลใดก็ตามที่ระบุไว้
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องแสดงข้อจำกัดความรับผิดในระหว่างการตั้งค่าอุปกรณ์ที่มีการจัดการครบวงจร (การตั้งค่าเจ้าของอุปกรณ์) ที่ระบุว่าผู้ดูแลระบบไอทีจะสามารถอนุญาตให้แอปควบคุมการตั้งค่าในโทรศัพท์ได้ รวมถึงไมโครโฟน กล้อง และตำแหน่ง พร้อมตัวเลือกให้ผู้ใช้ตั้งค่าต่อหรือออกจากการตั้งค่า เว้นแต่ผู้ดูแลระบบจะเลือกไม่ใช้การควบคุมสิทธิ์ต่างๆ ในอุปกรณ์
หากติดตั้งใช้งานอุปกรณ์ไว้ล่วงหน้า ให้ติดตั้งแพ็กเกจที่มีบทบาท System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence หรือ System Visual Intelligence แพ็กเกจจะมีลักษณะดังนี้
- [C-4-1] ต้องทำตามข้อกำหนดทั้งหมดที่ระบุไว้สำหรับการติดตั้งใช้งานอุปกรณ์ในส่วน "9.8.6 การบันทึกเนื้อหา"
- [C-4-2] ต้องไม่มีสิทธิ์ android.permission.INTERNET ซึ่งจะเข้มงวดกว่า "แนะนำอย่างยิ่ง" ในหัวข้อ 9.8.6
- [C-4-3] ต้องไม่เชื่อมโยงกับแอปอื่นๆ ยกเว้นแอประบบต่อไปนี้ ซึ่งได้แก่ บลูทูธ, Contacts, Media, Telephony, SystemUI และคอมโพเนนต์ที่ให้บริการ Internet API ซึ่งเข้มงวดกว่าที่ระบุไว้ในส่วนที่ 9.8.6
9.2 การแยก UID และกระบวนการ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับโมเดลแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น Unixstyle UID ที่ไม่ซ้ำกัน และอยู่ในกระบวนการที่แยกจากกัน
- [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 มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบและโคลนโปรไฟล์ผู้ใช้ด้วยการแยกบางส่วน(เช่น โปรไฟล์ผู้ใช้เพิ่มเติมเดี่ยวในประเภท android.os.usertype.profile.CLONE
)
- การใช้งานอุปกรณ์อาจแต่ไม่ควรเปิดใช้ผู้ใช้หลายคน หากใช้สื่อแบบถอดได้สำหรับที่จัดเก็บข้อมูลภายนอกหลัก
หากการใช้งานอุปกรณ์มีการรองรับผู้ใช้หลายคน จะมีผลดังนี้
- [C-1-2] สำหรับผู้ใช้แต่ละราย ต้องใช้โมเดลการรักษาความปลอดภัย ที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ใน เอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ ใน API
- [C-1-3] ต้องมีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก
(หรือที่เรียกอีกชื่อหนึ่งว่า
/sdcard
) สำหรับอินสแตนซ์ของผู้ใช้แต่ละรายการ - [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และเรียกใช้ในนามของผู้ใช้นั้นไม่สามารถลงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองคนจะจัดเก็บอยู่ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
- [C-1-5] ต้องเข้ารหัสเนื้อหาในการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บอยู่ในสื่อที่นำออกไม่ได้ซึ่งเข้าถึงได้เฉพาะระบบเท่านั้นหากอุปกรณ์ใช้สื่อที่นำออกได้สำหรับ API การจัดเก็บข้อมูลภายนอก เนื่องจากการดำเนินการดังกล่าวจะทำให้พีซีโฮสต์อ่านสื่อไม่ได้ การใช้งานอุปกรณ์จึงจำเป็นจะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้
หากการใช้งานอุปกรณ์รวมการรองรับผู้ใช้หลายคนแล้ว สำหรับผู้ใช้ทั้งหมด ยกเว้นผู้ใช้ที่สร้างขึ้นเพื่อการใช้อินสแตนซ์คู่ของแอปเดียวกันโดยเฉพาะ จะมีการดำเนินการดังต่อไปนี้
- [C-2-1] ต้องมีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก (หรือ /sdcard) สำหรับอินสแตนซ์ผู้ใช้แต่ละรายการ
- [C-2-2] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และทำงานอยู่ในนามของผู้ใช้ที่กำหนดนั้นไม่สามารถแสดงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองจะเก็บไว้ในปริมาณหรือระบบไฟล์เดียวกันก็ตาม
การใช้งานอุปกรณ์อาจสร้างโปรไฟล์ผู้ใช้ประเภท android.os.usertype.profile.CLONE
เพิ่มเติม 1 รายการสำหรับผู้ใช้หลัก (และกับผู้ใช้หลักเท่านั้น) เพื่อวัตถุประสงค์ในการเรียกใช้อินสแตนซ์คู่ของแอปเดียวกัน
อินสแตนซ์คู่เหล่านี้ใช้พื้นที่เก็บข้อมูลที่แยกบางส่วน โดยแสดงต่อผู้ใช้ใน Launcher พร้อมกันและปรากฏในมุมมองล่าสุดเดียวกัน
เช่น ใช้เพื่อรองรับผู้ใช้ติดตั้ง 2 อินสแตนซ์แยกกันของแอปเดียวในอุปกรณ์แบบ 2 ซิม
หากการนำอุปกรณ์ไปใช้งานสร้างโปรไฟล์ผู้ใช้เพิ่มเติมที่กล่าวถึงข้างต้น ระบบจะดำเนินการดังต่อไปนี้
- [C-3-1] ต้องให้สิทธิ์เข้าถึงเฉพาะพื้นที่เก็บข้อมูลหรือข้อมูลที่โปรไฟล์ผู้ใช้หลักเข้าถึงได้อยู่แล้ว หรือเป็นของโปรไฟล์ผู้ใช้เพิ่มเติมนี้โดยตรง
- [C-3-2] ต้องไม่มีเป็นโปรไฟล์งาน
- [C-3-3] ต้องมีการแยกไดเรกทอรีข้อมูลแอปส่วนตัวจากบัญชีผู้ใช้หลัก
- [C-3-4] ต้องไม่อนุญาตให้สร้างโปรไฟล์ผู้ใช้เพิ่มเติมหากมีการจัดสรรเจ้าของอุปกรณ์ (ดูหัวข้อ 3.9.1) หรืออนุญาตให้มีการจัดสรรเจ้าของอุปกรณ์โดยไม่ต้องนำโปรไฟล์ผู้ใช้เพิ่มเติมออกก่อน
9.6 คำเตือนทาง SMS แบบพรีเมียม
Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมขาออก ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการเครือข่ายซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปซึ่งกำหนดในไฟล์
/data/misc/sms/codes.xml
ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ที่มีการติดตั้งใช้งาน ซึ่งเป็นไปตามข้อกำหนดนี้
9.7 ฟีเจอร์ความปลอดภัย
การใช้งานอุปกรณ์ต้องแน่ใจถึงการปฏิบัติตามข้อกำหนดของฟีเจอร์ความปลอดภัยทั้งในเคอร์เนลและแพลตฟอร์มตามที่อธิบายไว้ด้านล่าง
แซนด์บ็อกซ์ของ Android ประกอบด้วยคุณลักษณะที่ใช้ระบบการควบคุมการเข้าถึง (MAC) ที่บังคับของการรักษาความปลอดภัย (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 synchronization (TSYNC) ตามที่อธิบายไว้ ในส่วน Kernel Configuration ของ source.android.com
ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการปกป้องตนเองเป็นส่วนสำคัญในการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์
- [C-0-7] ต้องใช้กลไกการป้องกันการล้นของสแต็กเคอร์เนล
ตัวอย่างของกลไกดังกล่าวคือ
CC_STACKPROTECTOR_REGULAR
และ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] ต้องใช้การแยกตารางหน้าเคอร์เนลหากฮาร์ดแวร์มีช่องโหว่ต่อ CVE-2017-5754 ในอุปกรณ์ทั้งหมดที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป (เช่น
CONFIG_PAGE_TABLE_ISOLATION
หรือCONFIG_UNMAP_KERNEL_AT_EL0
) - [C-0-13] ต้องใช้การเสริมการคาดการณ์สาขาหากฮาร์ดแวร์มีช่องโหว่กับ CVE-2017-5715 ในอุปกรณ์ทั้งหมดที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป (เช่น
CONFIG_HARDEN_BRANCH_PREDICTOR
) - [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในเครื่องที่ไม่ได้กำหนดค่าเริ่มต้น (
CONFIG_INIT_STACK_ALL
หรือCONFIG_INIT_STACK_ALL_ZERO
) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคาดเดาค่าที่คอมไพเลอร์ใช้ในการเริ่มต้นในเครื่อง - [C-SR-2] แนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนล
ซึ่งเขียนเฉพาะระหว่างการเริ่มต้นที่ได้รับการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจาก
การเริ่มต้น (เช่น
__ro_after_init
) [C-SR-3] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของรหัสเคอร์เนลและหน่วยความจำ และเพื่อหลีกเลี่ยงการรับแสงที่อาจส่งผลต่อการสุ่ม (เช่น
CONFIG_RANDOMIZE_BASE
ด้วยเอนโทรปี Bootloader ผ่าน/chosen/kaslr-seed Device Tree node
หรือEFI_RNG_PROTOCOL
)[C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้ความสมบูรณ์ของโฟลว์การควบคุม (CFI) ในเคอร์เนล เพื่อเสริมการป้องกันการโจมตีโดยใช้โค้ดซ้ำ (เช่น
CONFIG_CFI_CLANG
และCONFIG_SHADOW_CALL_STACK
)[C-SR-5] แนะนำอย่างยิ่งไม่ให้ปิดใช้ Control-Flow Integrity (CFI), Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) บนคอมโพเนนต์ที่เปิดใช้
[C-SR-6] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์พื้นที่ผู้ใช้ที่ละเอียดอ่อนด้านความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan
[C-SR-7] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนล เพื่อป้องกันการใช้ตัวแปรภายในเครื่องที่ไม่ได้เริ่มต้น (
CONFIG_INIT_STACK_ALL
หรือCONFIG_INIT_STACK_ALL_ZERO
) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคิดเอาค่าที่คอมไพเลอร์ใช้เพื่อเริ่มต้นในเครื่อง[C-SR-8] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นฮีปในเคอร์เนลเพื่อป้องกันการใช้งานการจัดสรรฮีปแบบไม่เริ่มต้น (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) และไม่ควรคาดเดาค่าที่เคอร์เนลใช้ในการเริ่มต้นการจัดสรรเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลของ Linux ที่รองรับ SELinux จะ
- [C-1-1] ต้องใช้ SELinux
- [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
- [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนในโหมดที่อนุญาต ซึ่งรวมถึงโดเมนที่เจาะจงเฉพาะอุปกรณ์/ผู้ให้บริการ
- [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่มีอยู่ในโฟลเดอร์ระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ ไม่อนุญาตทั้งหมดที่มีอยู่ สำหรับทั้งโดเมน AOSP SELinux และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
- [C-1-5] ต้องใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไป ในแซนด์บ็อกซ์ SELinux ตามแอปพลิเคชันที่มีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
- ควรเก็บนโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ระบบ/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android อัปสตรีม และเพิ่มลงในนโยบายนี้เพิ่มเติมเฉพาะสำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเอง
หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux หรือ Linux โดยไม่มี SELinux จะเกิดสิ่งต่อไปนี้
- [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็น เทียบเท่ากับ SELinux
หากการติดตั้งใช้งานอุปกรณ์ใช้อุปกรณ์ I/O ที่รองรับ DMA การดำเนินการต่อไปนี้
- [C-SR-9] ขอแนะนำอย่างยิ่งให้แยกอุปกรณ์ I/O แต่ละเครื่องที่ใช้ DMA ได้ โดยใช้ IOMMU (เช่น ARM SMMU)
Android มีฟีเจอร์การป้องกันในเชิงลึกหลายอย่างที่เป็นส่วนสำคัญในการรักษาความปลอดภัยของอุปกรณ์ นอกจากนี้ Android ยังมุ่งเน้นที่การลดคลาสหลักๆ ของข้อบกพร่องที่พบบ่อยซึ่งมีส่วนทำให้คุณภาพและความปลอดภัยไม่ดีด้วย
เพื่อลดข้อบกพร่องของหน่วยความจำ การใช้งานอุปกรณ์จะต้องดำเนินการต่อไปนี้
- [C-SR-10] ขอแนะนำอย่างยิ่งให้ทดสอบโดยใช้เครื่องมือตรวจหาข้อผิดพลาดของหน่วยความจำของผู้ใช้ เช่น MTE สำหรับอุปกรณ์ ARMv9, HWASan สำหรับอุปกรณ์ ARMv8+ หรือ ASan สำหรับอุปกรณ์ประเภทอื่น
- [C-SR-11] แนะนำให้ทดสอบโดยใช้เครื่องมือตรวจหาข้อผิดพลาดของหน่วยความจําของเคอร์เนล เช่น KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS สําหรับอุปกรณ์ ARMv9, CONFIG_KASAN_SRMW_TAGS สำหรับอุปกรณ์ AGAv8 หรือ CONFIG_KASAN)
- [C-SR-12] ขอแนะนำอย่างยิ่งให้ใช้เครื่องมือตรวจจับข้อผิดพลาดของหน่วยความจำในเวอร์ชันที่ใช้งานจริง เช่น MTE, GWP-ASan และ KFENCE
หากอุปกรณ์ใช้ TEE ที่ใช้ Arm TrustZone จะมีผลดังนี้
- [C-SR-13] ขอแนะนำอย่างยิ่งให้ใช้โปรโตคอลมาตรฐานสำหรับการแชร์หน่วยความจำระหว่าง Android และ TEE เช่น Arm Firmware Framework สำหรับ Armv8-A (FF-A)
- [C-SR-14] ขอแนะนำอย่างยิ่งให้จำกัดแอปพลิเคชันที่เชื่อถือได้ให้เข้าถึงเฉพาะหน่วยความจำที่มีการแชร์อย่างชัดแจ้งกับแอปพลิเคชันผ่านโปรโตคอลข้างต้นเท่านั้น หากอุปกรณ์รองรับระดับข้อยกเว้น Arm S-EL2 ควรบังคับใช้โดยเครื่องมือจัดการพาร์ติชันที่ปลอดภัย มิฉะนั้น ระบบปฏิบัติการ TEE ควรบังคับใช้
9.8 ความเป็นส่วนตัว
9.8.1 ประวัติการใช้งาน
Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] จะต้องมีระยะเวลาเก็บรักษาประวัติผู้ใช้อย่างสมเหตุสมผล
- [C-SR-1] ขอแนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการใช้งาน AOSP
Android จะจัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog
และจัดการประวัติดังกล่าวผ่าน StatsManager
และ IncidentManager
System API
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องรวมเฉพาะช่องที่มีเครื่องหมาย
DEST_AUTOMATIC
ในรายงานเหตุการณ์ที่สร้างโดยคลาส API ของระบบIncidentManager
- [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบในการบันทึกเหตุการณ์อื่นๆ
นอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ
StatsLog
หากมีการบันทึกเหตุการณ์เพิ่มเติมของระบบ เหตุการณ์เหล่านั้นอาจใช้ตัวระบุอะตอมอื่นในช่วงระหว่าง 100,000 ถึง 200,000
9.8.2 กำลังบันทึกเสียง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่โหลดล่วงหน้าหรือแจกจ่ายส่วนประกอบซอฟต์แวร์ออกจากกล่องที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้ หรือล้างการแจ้งเตือนอย่างต่อเนื่อง
- [C-0-2] ต้องแสดงและขอความยินยอมอย่างชัดแจ้งจากผู้ใช้เพื่ออนุญาตให้ระบบบันทึกข้อมูลที่ละเอียดอ่อนซึ่งแสดงบนหน้าจอของผู้ใช้ทุกครั้งที่มีการเปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอผ่าน
MediaProjection
หรือ API ที่เป็นกรรมสิทธิ์ ต้องไม่ให้เงินแก่ผู้ใช้ในการปิดใช้การแสดงความยินยอมของผู้ใช้ในอนาคต - [C-0-3] ต้องมีการแจ้งเตือนผู้ใช้อย่างต่อเนื่องในขณะที่เปิด การแคสต์หน้าจอหรือบันทึกหน้าจออยู่ AOSP เป็นไปตามข้อกำหนดนี้โดยการแสดงไอคอน การแจ้งเตือนต่อเนื่องในแถบสถานะ
หากการนำอุปกรณ์ไปใช้งานมีฟังก์ชันการทำงานในระบบซึ่งจับภาพเนื้อหาที่แสดงบนหน้าจอ และ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์นอกเหนือจากผ่านทาง System API ContentCaptureService
หรือวิธีการเฉพาะอื่นๆ ซึ่งอธิบายไว้ในส่วนที่ 9.8.6 การบันทึกเนื้อหา การดำเนินการดังกล่าวจะ
- [C-1-1] ต้องมีการแจ้งเตือนให้ผู้ใช้ทราบอย่างต่อเนื่องเมื่อมีการเปิดใช้ฟังก์ชันดังกล่าวและกำลังบันทึก/บันทึกอยู่
หากการใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ตั้งแต่แกะกล่อง ซึ่งสามารถบันทึกเสียงรอบข้างและ/หรือบันทึกเสียงที่เล่นในอุปกรณ์เพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องไม่จัดเก็บไว้ในพื้นที่เก็บข้อมูลบนอุปกรณ์ถาวร หรือส่งไฟล์เสียงเสียงที่บันทึกออกมาจากอุปกรณ์อย่างถาวร หรือรูปแบบใดๆ ที่สามารถแปลงเป็นเสียงต้นฉบับหรือสัญญาณเสียงใกล้แฟกซ์ได้ เว้นแต่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้
"สัญญาณบอกสถานะไมโครโฟน" หมายถึงมุมมองบนหน้าจอที่ผู้ใช้มองเห็นอย่างต่อเนื่องและไม่ถูกบดบัง ซึ่งผู้ใช้เข้าใจว่ามีการใช้ไมโครโฟนอยู่(ผ่านข้อความ สี ไอคอน หรือทั้งสองอย่างผสมกัน)
"สัญญาณบอกสถานะกล้อง" หมายถึงมุมมองบนหน้าจอที่ผู้ใช้มองเห็นอย่างต่อเนื่องและไม่ถูกบดบัง ซึ่งผู้ใช้เข้าใจว่ากำลังใช้งานกล้องอยู่ (ผ่านข้อความ สี ไอคอน หรือรูปแบบบางอย่างที่ไม่ซ้ำกัน)
หลังจากแสดง 1 วินาทีแรก ตัวบ่งชี้อาจเปลี่ยนไปตามที่เห็น เช่น มีขนาดเล็กลง และไม่จำเป็นต้องแสดงเป็นที่นำเสนอและเข้าใจในตอนแรก
สัญญาณบอกสถานะไมโครโฟนอาจรวมเข้ากับสัญญาณบอกสถานะกล้อง ซึ่งจะแสดงอย่างชัดเจน โดยมีข้อความ ไอคอน หรือสี เพื่อบอกผู้ใช้ว่าได้เริ่มใช้ไมโครโฟนแล้ว
สัญญาณบอกสถานะกล้องอาจรวมกับสัญญาณบอกสถานะไมโครโฟน ที่แสดงอยู่บนหน้าจอ โดยมีข้อความ ไอคอน หรือสี เพื่อบอกผู้ใช้ว่าได้เริ่มใช้กล้องแล้ว
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงสัญญาณบอกสถานะไมโครโฟนเมื่อแอป
เข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ใช่เมื่อเข้าถึงไมโครโฟน
โดย
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
หรือแอปที่มีบทบาทซึ่งเรียกใช้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X] เท่านั้น - [C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ไมโครโฟนที่ส่งคืนจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมกับข้อความระบุแหล่งที่มาที่เกี่ยวข้อง - [C-SR-3] ขอแนะนำเป็นอย่างยิ่งว่าอย่าซ่อนสัญญาณบอกสถานะไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง
การใช้งานอุปกรณ์จะประกาศ android.hardware.camera.any
ดังต่อไปนี้
- [C-SR-4] ขอแนะนำอย่างยิ่งให้แสดงสัญญาณบอกสถานะกล้องเมื่อแอปเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อแอปเข้าถึงกล้องเฉพาะที่มีบทบาทที่เรียกใช้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X]
- [C-SR-5] ขอแนะนำอย่างยิ่งให้แสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ "กล้อง" ที่ส่งคืนจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมกับข้อความระบุแหล่งที่มาที่เกี่ยวข้อง - [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้ไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง
9.8.3 การเชื่อมต่อ
หากอุปกรณ์มีพอร์ต USB ที่รองรับอุปกรณ์ต่อพ่วง USB จะมีลักษณะดังนี้
- [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้เพื่อขอคำยินยอมจากผู้ใช้ก่อนอนุญาตให้เข้าถึงเนื้อหาในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันผ่านพอร์ต USB
9.8.4 การจราจรของข้อมูลในเครือข่าย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันสำหรับที่เก็บผู้ออกใบรับรอง (CA) ที่ระบบเชื่อถือไว้ล่วงหน้าตามที่ให้ไว้ในโปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-2] ต้องจัดส่งพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า
- [C-0-3] ต้องแสดงคำเตือนแก่ผู้ใช้ที่ระบุว่าอาจมีการตรวจสอบการจราจรของข้อมูลในเครือข่าย เมื่อมีการเพิ่ม CA ระดับรูทของผู้ใช้
หากมีการกำหนดเส้นทางการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องแสดงคำเตือนแก่ผู้ใช้โดยระบุข้อใดข้อหนึ่งต่อไปนี้
- อาจมีการตรวจสอบการจราจรของข้อมูลในเครือข่ายดังกล่าว
- การจราจรของข้อมูลในเครือข่ายดังกล่าวจะส่งผ่านแอปพลิเคชัน VPN ที่เฉพาะเจาะจงซึ่งให้บริการ VPN
หากการใช้งานอุปกรณ์มีกลไกที่เปิดใช้อยู่โดยค่าเริ่มต้นซึ่งจะกำหนดเส้นทางการรับส่งข้อมูลเครือข่ายผ่านพร็อกซีเซิร์ฟเวอร์หรือเกตเวย์ VPN (เช่น การโหลดบริการ VPN ล่วงหน้าที่ได้รับสิทธิ์ android.permission.CONTROL_VPN
) ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว เว้นแต่ว่าเครื่องมือควบคุมนโยบายด้านอุปกรณ์จะเปิดใช้ VPN ผ่าน
DevicePolicyManager.setAlwaysOnVpnPackage()
ซึ่งในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับแจ้งเท่านั้น
หากการใช้งานอุปกรณ์ใช้ราคาที่ให้ผู้ใช้เปิดใช้ฟังก์ชัน "VPN แบบเปิดตลอดเวลา" ของแอป VPN ของบุคคลที่สาม สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องปิดใช้การชำระเงินสำหรับผู้ใช้รายนี้สำหรับแอปที่ไม่รองรับบริการ VPN แบบเปิดตลอดเวลาในไฟล์
AndroidManifest.xml
ผ่านการตั้งค่าแอตทริบิวต์SERVICE_META_DATA_SUPPORTS_ALWAYS_ON
เป็นfalse
9.8.5 ตัวระบุอุปกรณ์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องป้องกันไม่ให้มีการเข้าถึงหมายเลขซีเรียลของอุปกรณ์ และ (หากมี) IMEI/MEID, หมายเลขซีเรียลของซิม และ International Mobile Subscriber Identity (IMSI) จากแอป เว้นแต่เป็นไปตามข้อกำหนดข้อใดข้อหนึ่งต่อไปนี้
- เป็นแอปของผู้ให้บริการที่ได้รับการรับรองและได้รับการยืนยันโดยผู้ผลิตอุปกรณ์
- ได้รับสิทธิ์
READ_PRIVILEGED_PHONE_STATE
แล้ว - มีสิทธิ์ของผู้ให้บริการตามที่ระบุไว้ในสิทธิ์ของผู้ให้บริการ UICC
- เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับสิทธิ์
READ_PHONE_STATE
- (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดของกฎระเบียบท้องถิ่น เพื่อให้แอปตรวจพบการเปลี่ยนแปลงข้อมูลประจำตัวของผู้สมัครใช้บริการ
9.8.6 การบันทึกเนื้อหาและการค้นหาแอป
Android ที่ใช้ System API ContentCaptureService
, AugmentedAutofillService
, AppSearchGlobalManager.query
หรือโดยวิธีการที่เป็นกรรมสิทธิ์อื่นๆ จะสนับสนุนกลไกการนำอุปกรณ์ไปใช้งานเพื่อบันทึกการโต้ตอบของข้อมูลแอปพลิเคชันต่อไปนี้ระหว่างแอปพลิเคชันและผู้ใช้
- ข้อความและกราฟิกที่แสดงบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน
AssistStructure
API - ข้อมูลสื่อ เช่น เสียงหรือวิดีโอ ที่อุปกรณ์บันทึกหรือเล่น
- เหตุการณ์การป้อนข้อมูล (เช่น การกดแป้น เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)
- เหตุการณ์อื่นๆ ที่แอปพลิเคชันมอบให้ระบบผ่าน
Content Capture
API หรือAppSearchManager
API ที่เป็น Android ที่มีความสามารถใกล้เคียงกันและ API ที่เป็นกรรมสิทธิ์ - ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน
TextClassifier API
ไปยัง System TextClassifier เช่น ไปยังบริการของระบบเพื่อทำความเข้าใจความหมายของข้อความ รวมถึงสร้างการดำเนินการถัดไปที่คาดการณ์ไว้ตามข้อความ - ข้อมูลที่จัดทำดัชนีโดยใช้ AppSearch ของแพลตฟอร์ม ซึ่งรวมถึงแต่ไม่จำกัดเพียงข้อความ กราฟิก ข้อมูลสื่อ หรือข้อมูลอื่นๆ ที่คล้ายกัน
หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องเข้ารหัสข้อมูลทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้ Android File-Based Encryption หรือการเข้ารหัสใดๆ ที่ระบุไว้เป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
- [C-1-2] ต้องไม่สำรองข้อมูลข้อมูลดิบหรือที่เข้ารหัสโดยใช้ วิธีการสำรองข้อมูลของ Android หรือ วิธีการสำรองอื่นๆ
- [C-1-3] ต้องส่งเฉพาะข้อมูลดังกล่าวและบันทึกของอุปกรณ์โดยใช้
กลไกการรักษาความเป็นส่วนตัวเท่านั้น กลไกการรักษาความเป็นส่วนตัวหมายถึง "รายการที่อนุญาตให้ใช้การวิเคราะห์แบบรวมและป้องกันการจับคู่เหตุการณ์ที่บันทึกหรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละรายเท่านั้น" เพื่อป้องกันไม่ให้ข้อมูลผู้ใช้แต่ละรายการสามารถตรวจสอบได้ (เช่น ใช้งานโดยใช้เทคโนโลยี Differential Privacy เช่น
RAPPOR
) - [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวผู้ใช้ (เช่น
Account
) ในอุปกรณ์ ยกเว้นกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล - [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.6 การบันทึกเนื้อหา) เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้งทุกครั้งที่มีการแชร์
- [C-1-6] ต้องให้เงินแก่ผู้ใช้ในการลบข้อมูลดังกล่าวซึ่ง
ContentCaptureService
หรือวิธีการที่เป็นกรรมสิทธิ์เก็บรวบรวม หากข้อมูลดังกล่าวได้รับการจัดเก็บไว้ในรูปแบบใดๆ ในอุปกรณ์ - [C-1-7] ต้องให้เงินแก่ผู้ใช้ในการเลือกไม่รับข้อมูล ซึ่งเก็บรวบรวมผ่าน AppSearch หรือวิธีที่เป็นกรรมสิทธิ์เพื่อไม่ให้แสดงในแพลตฟอร์ม Android เช่น Launcher
- [C-SR-1] แนะนำอย่างยิ่งไม่ให้ขอสิทธิ์อินเทอร์เน็ต
- [C-SR-2] ขอแนะนำอย่างยิ่งให้เข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างซึ่งสนับสนุนโดยการใช้งานโอเพนซอร์สที่เผยแพร่ต่อสาธารณะเท่านั้น
หากการนำอุปกรณ์ไปใช้งานครอบคลุมบริการที่ใช้ System API ContentCaptureService
, AppSearchManager.index
หรือบริการที่เป็นกรรมสิทธิ์ใดๆ ซึ่งบันทึกข้อมูลตามที่อธิบายไว้ข้างต้น การดำเนินการเหล่านี้จะมีผลดังนี้
- [C-2-1] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้ และต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าบันทึกข้อมูลดังกล่าว
- [C-2-2] ต้องไม่อนุญาตให้แอปอื่นๆ นอกเหนือจากกลไกของบริการที่ติดตั้งไว้ล่วงหน้าบันทึกข้อมูลดังกล่าวได้
- [C-2-3] ต้องให้ค่าตอบแทนแก่ผู้ใช้ในการปิดใช้บริการ
- [C-2-4] ต้องไม่ใช้สิทธิ์ของผู้ใช้ในการจัดการสิทธิ์ของ Android ที่บริการมี และทำตามโมเดลสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์
[C-SR-3] แนะนำอย่างยิ่งให้แยกบริการออกจากองค์ประกอบอื่นๆ ของระบบ(เช่น ไม่เชื่อมโยงบริการหรือรหัสกระบวนการแชร์) ยกเว้นในกรณีต่อไปนี้
- โทรศัพท์, รายชื่อติดต่อ, UI ระบบ และสื่อ
Android ผ่านทาง SpeechRecognizer#onDeviceSpeechRecognizer()
จะช่วยให้ใช้การจดจำคำพูด
บนอุปกรณ์ได้โดยไม่เกี่ยวข้องกับเครือข่าย
การใช้งาน SpeechRecognizer ในอุปกรณ์ต้องเป็นไปตามนโยบายที่ระบุไว้ในส่วนนี้
9.8.7 การเข้าถึงคลิปบอร์ด
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่แสดงผลข้อมูลที่ถูกตัดจากคลิปบอร์ด (เช่น ผ่าน
ClipboardManager
API) เว้นแต่แอปของบุคคลที่สามจะเป็น IME เริ่มต้นหรือแอปที่คุณโฟกัสอยู่ในปัจจุบัน - [C-0-2] ต้องล้างข้อมูลคลิปบอร์ดภายในไม่เกิน 60 นาทีหลังจากวางข้อมูลไว้ในคลิปบอร์ดหรืออ่านจากคลิปบอร์ด
9.8.8 ตำแหน่ง
ตำแหน่งมีข้อมูลในคลาสตำแหน่งของ Android( เช่น ละติจูด ลองจิจูด ระดับความสูง) และตัวระบุที่สามารถแปลงเป็นตำแหน่งได้ ตำแหน่งอาจละเอียดพอๆ กับ DGPS (Differential Global Positioning System) หรือตำแหน่งคร่าวๆ ในระดับสถานที่ตั้งระดับประเทศ (เช่น ตำแหน่งรหัสประเทศ - MCC - รหัสประเทศของอุปกรณ์เคลื่อนที่)
ต่อไปนี้คือรายการของประเภทสถานที่ตั้งที่ได้มาจากสถานที่ตั้งของผู้ใช้โดยตรงหรือสามารถแปลงเป็นสถานที่ตั้งของผู้ใช้ได้ รายการนี้ไม่ใช่รายการที่ครอบคลุม แต่ควรใช้เป็นตัวอย่างว่า "สถานที่ตั้ง" สามารถดึง "สถานที่ตั้ง" มาจากที่ใดโดยตรงหรือโดยอ้อม
- GPS/GNSS/DGPS/PPP
- โซลูชันการจัดตำแหน่งระดับโลก หรือระบบดาวเทียมการนำทางทั่วโลก หรือโซลูชันการวางตำแหน่งทั่วโลกแบบ Differential
- ซึ่งรวมถึงการวัด GNSS ไฟล์ข้อมูล GNSS และสถานะ GNSS
- ตำแหน่งโดยละเอียดอาจมาจากการวัด GNSS ไฟล์ข้อมูล RAW
- เทคโนโลยีไร้สายที่มีตัวระบุที่ไม่ซ้ำกัน เช่น
- จุดเข้าใช้งาน Wi-Fi (MAC, BSSID, ชื่อ หรือ SSID)
- บลูทูธ/BLE (MAC, BSSID, ชื่อ หรือ SSID)
- UWB (MAC, BSSID, ชื่อ หรือ SSID)
- รหัสเสาสัญญาณมือถือ (3G, 4G, 5G... รวมถึงเทคโนโลยีโมเด็มเครือข่ายมือถือในอนาคตทั้งหมดที่มีตัวระบุที่ไม่ซ้ำกัน)
เพื่อเป็นข้อมูลอ้างอิงหลัก ให้ดู Android API ที่ต้องใช้สิทธิ์ ACCESS_FINE_Location หรือ ACCESS_COARSE_Location
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมที่ชัดเจนจากผู้ใช้หรือการเริ่มต้นจากผู้ใช้
- [C-0-2] ต้องให้ผู้ใช้เข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่งได้ ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้งาน การสแกนหา Wi-Fi/บลูทูธเพื่อระบุตำแหน่ง
- [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ API การข้ามตำแหน่งกรณีฉุกเฉิน [LocationRequest.setLocationSettingsignored()] เป็นเซสชันฉุกเฉินที่ผู้ใช้เป็นผู้เริ่ม (เช่น กดหมายเลข 911 หรือส่งข้อความไปที่ 911) แต่สำหรับยานยนต์ รถยนต์อาจเริ่มเซสชันฉุกเฉินโดยไม่มีการโต้ตอบของผู้ใช้ที่ใช้งานอยู่ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนด eCall)
- [C-0-4] ต้องคงความสามารถของ API การข้ามตำแหน่งในกรณีฉุกเฉิน ในการข้ามการตั้งค่าตำแหน่งของอุปกรณ์ไว้โดยไม่เปลี่ยนการตั้งค่า
- [C-0-5] ต้องกำหนดเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งโดยใช้สิทธิ์ [
ACCESS_BACKGROUND_LOCATION
]
9.8.9 แอปที่ติดตั้ง
แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้โดยค่าเริ่มต้นไม่ได้ (ดูระดับการเข้าถึงแพ็กเกจในเอกสารประกอบ SDK ของ Android)
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่เปิดเผยข้อมูลแอปที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป เกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ เว้นแต่ว่าแอปจะสามารถเห็นรายละเอียดของ แอปที่ติดตั้งอยู่อีกแอปหนึ่งผ่าน API ที่มีการจัดการ ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งเพิ่มโดยผู้ใช้อุปกรณ์ หรือเข้าถึงได้ผ่านระบบไฟล์
- [C-0-2] ต้องไม่ให้สิทธิ์อ่านหรือเขียนไฟล์ในไดเรกทอรีเฉพาะแอปเฉพาะของแอปใดๆ ภายในพื้นที่เก็บข้อมูลภายนอก ข้อยกเว้นมีดังนี้
- สิทธิ์ของผู้ให้บริการพื้นที่เก็บข้อมูลภายนอก (เช่น แอปอย่าง DocumentsUI)
- ผู้ให้บริการดาวน์โหลดที่ใช้สิทธิ์ของผู้ให้บริการ "ดาวน์โหลด" ในการดาวน์โหลดไฟล์ไปยังพื้นที่เก็บข้อมูลของแอป
- แอป Media Transfer Protocol (MTP) ที่ลงนามโดยแพลตฟอร์มซึ่งใช้สิทธิ์ ACCESS_MTP ที่เป็นสิทธิพิเศษเพื่อเปิดใช้การโอนไฟล์ไปยังอุปกรณ์อื่น
- แอปที่ติดตั้งแอปอื่นๆ และมีสิทธิ์ INSTALL_PACKAGES จะเข้าถึงได้เฉพาะไดเรกทอรี "obb" เพื่อจุดประสงค์ในการจัดการ ไฟล์สำหรับขยาย APK
9.8.10 รายงานข้อบกพร่องเกี่ยวกับการเชื่อมต่อ
หากการใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.hardware.telephony
จะมีการดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับการสร้างรายงานข้อบกพร่องของการเชื่อมต่อผ่าน
BUGREPORT_MODE_TELEPHONY
ด้วย BugreportManager - [C-1-2] ต้องได้รับความยินยอมจากผู้ใช้ทุกครั้งที่มีการใช้
BUGREPORT_MODE_TELEPHONY
ในการสร้างรายงาน และต้องไม่แจ้งให้ผู้ใช้ให้ความยินยอมต่อคำขอในอนาคตทั้งหมดจากแอปพลิเคชัน - [C-1-3] ต้องไม่ส่งรายงานที่สร้างขึ้นกลับไปยังแอปที่ขอโดยไม่มีการยินยอมที่ชัดเจนจากผู้ใช้
- [C-1-4] รายงานที่สร้างขึ้นโดยใช้
BUGREPORT_MODE_TELEPHONY
ต้องมีข้อมูลต่อไปนี้เป็นอย่างน้อย- ดัมพ์
TelephonyDebugService
- ดัมพ์
TelephonyRegistry
- ดัมพ์
WifiService
- ดัมพ์
ConnectivityService
- ดัมพ์ของอินสแตนซ์
CarrierService
ของแพ็กเกจการโทร (หากมีขอบเขต) - บัฟเฟอร์บันทึกวิทยุ
- ดัมพ์
- [C-1-5] ต้องไม่มีข้อมูลต่อไปนี้ในรายงานที่สร้างขึ้น
- ข้อมูลที่ไม่เกี่ยวข้องกับการแก้ไขข้อบกพร่องเกี่ยวกับการเชื่อมต่อโดยตรง
- บันทึกการรับส่งข้อมูลของแอปพลิเคชันที่ติดตั้งโดยผู้ใช้หรือโปรไฟล์โดยละเอียดของแอปพลิเคชัน/แพ็กเกจที่ผู้ใช้ติดตั้ง (ใช้ UID ได้ แต่ไม่ใช่ชื่อแพ็กเกจ)
- อาจมีข้อมูลเพิ่มเติมที่ไม่เกี่ยวข้องกับตัวตนของผู้ใช้ (เช่น บันทึกของผู้ให้บริการ)
หากการติดตั้งใช้งานอุปกรณ์มีข้อมูลเพิ่มเติม (เช่น บันทึกของผู้ให้บริการ) ในรายงานข้อบกพร่อง และข้อมูลดังกล่าวส่งผลต่อความเป็นส่วนตัว/ความปลอดภัย/แบตเตอรี่/พื้นที่เก็บข้อมูล/หน่วยความจำ การตั้งค่าดังกล่าวจะมีผลดังนี้
- [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้กำหนดการตั้งค่าเริ่มต้นของนักพัฒนาซอฟต์แวร์เป็นปิดใช้ การใช้ข้อมูลอ้างอิง AOSP จะตอบโจทย์ปัญหานี้ด้วยการมอบตัวเลือก
Enable verbose vendor logging
ในการตั้งค่าสำหรับนักพัฒนาซอฟต์แวร์เพื่อรวมบันทึกเพิ่มเติมของผู้ให้บริการเฉพาะอุปกรณ์ไว้ในรายงานข้อบกพร่อง
9.8.11 การแชร์ข้อมูล BLOB
Android ผ่านทาง BlobStoreManager ทำให้แอปที่แชร์ Blob ของข้อมูลไปยังระบบกับชุดแอปที่เลือกได้
หากการติดตั้งใช้งานอุปกรณ์รองรับ Blob ของข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสาร SDK ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องไม่แชร์ข้อมูล BLOB ที่เป็นของแอปนอกเหนือจากที่แอปตั้งใจจะอนุญาต (เช่น ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreAccessManager())#PublicAccessManager) การใช้ข้อมูลอ้างอิง AOSP จะเป็นไปตามข้อกำหนดเหล่านี้
- [C-1-2] ต้องไม่ส่งแฮชที่ปลอดภัยของ Data Blob (ซึ่งใช้เพื่อควบคุมการเข้าถึง) ให้กับแอปอื่นหรือแชร์กับแอปอื่นๆ
9.8.12 การรับรู้เพลง
Android ที่ใช้ MusicRecognitionManager ซึ่งเป็น System API รองรับกลไกการนำอุปกรณ์ไปใช้งานเพื่อขอการจดจำเพลง มอบการบันทึกเสียง และให้สิทธิ์การจดจำเพลงแก่แอปที่ได้รับสิทธิ์ที่ใช้ MusicRecognitionService API
หากการใช้งานอุปกรณ์รวมถึงบริการที่ใช้ System API MusicRecognitionManager หรือบริการที่เป็นกรรมสิทธิ์ใดๆ ซึ่งสตรีมข้อมูลเสียงตามที่อธิบายไว้ข้างต้น
- [C-1-1] ต้องบังคับให้ผู้เรียกใช้ MusicRecognitionManager มีสิทธิ์
MANAGE_MUSIC_RECOGNITION
- [C-1-2] ต้องบังคับให้แอปพลิเคชันการจดจำเพลงที่ติดตั้งไว้ล่วงหน้า แอปพลิเคชันเดียวใช้ MusicRecognitionService
- [C-1-3] ต้องไม่อนุญาตให้ผู้ใช้แทนที่ MusicRecognitionManagerService หรือ MusicRecognitionService ด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้
- [C-1-4] ต้องตรวจสอบว่าเมื่อ MusicRecognitionManagerService เข้าถึง ไฟล์บันทึกเสียงและส่งต่อไปยังแอปพลิเคชันที่ใช้ MusicRecognitionService การเข้าถึงเสียงจะได้รับการติดตามผ่านการเรียกใช้ AppOpsManager.noteOp / startOp
หากอุปกรณ์ของ MusicRecognitionManagerService หรือ MusicRecognitionService จัดเก็บข้อมูลเสียงที่บันทึกไว้ อุปกรณ์จะดำเนินการดังนี้
- [C-2-1] ต้องไม่เก็บลายนิ้วมือที่เป็นเสียงหรือภาพบนดิสก์เลย หรือในหน่วยความจำนานกว่า 14 วัน
- [C-2-2] ต้องไม่แชร์ข้อมูลดังกล่าวนอกเหนือจาก MusicRecognitionService เว้นแต่จะได้รับคำยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการแชร์
9.8.13 ผู้จัดการเซ็นเซอร์ความเป็นส่วนตัว
หากการติดตั้งอุปกรณ์ช่วยให้ผู้ใช้มีเงินพอที่จะปิดอินพุตกล้องและ/หรือไมโครโฟนสำหรับการติดตั้งใช้งานอุปกรณ์ได้
- [C-1-1] ต้องแสดงผล "true" อย่างถูกต้องสำหรับเมธอด API ที่เกี่ยวข้อง supportsSensorToggle()
- [C-1-2] ต้องเสนอเมื่อแอปพยายามเข้าถึงไมโครโฟนหรือกล้องที่ถูกบล็อก โดยต้องให้ผู้ใช้ได้เห็นราคาที่ปิดไม่ได้แก่ผู้ใช้ซึ่งระบุอย่างชัดเจนว่าเซ็นเซอร์ถูกบล็อกและกำหนดให้ต้องเลือกว่าจะบล็อกหรือเลิกบล็อกต่อไปตามการใช้งาน AOSP ซึ่งเป็นไปตามข้อกำหนดนี้
- [C-1-3] จะต้องส่งข้อมูลกล้องและเสียงที่ไม่มี (หรือปลอม) ไปยังแอปเท่านั้น และไม่รายงานรหัสข้อผิดพลาดเนื่องจากผู้ใช้ไม่ได้เปิดกล้อง หรือไมโครโฟนผ่านงบของผู้ใช้ตามราคาที่ [C-1-2] ด้านบน
9.9 การเข้ารหัสพื้นที่เก็บข้อมูล
อุปกรณ์ทั้งหมดต้องตรงตามข้อกำหนดของส่วนที่ 9.9.1 อุปกรณ์ที่เปิดตัวในระดับ API ก่อนวันที่ในเอกสารนี้จะได้รับการยกเว้นจากข้อกำหนดในส่วนที่ 9.9.2 และ 9.9.3 แต่ต้องเป็นไปตามข้อกำหนดในส่วนที่ 9.9 ของเอกสารคำจำกัดความความเข้ากันได้ของ Android ที่สอดคล้องกับระดับ API ที่อุปกรณ์เปิดตัวไป
9.9.1 Direct Boot
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องใช้ API โหมดการเปิดเครื่องโดยตรง แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม
[C-0-2]
ACTION_LOCKED_BOOT_COMPLETED
และACTION_USER_UNLOCKED
Intent ต้องยังคงออกอากาศอยู่เพื่อส่งสัญญาณแจ้งแอปพลิเคชันที่รับรู้การเปิดเครื่องโดยตรงว่า ตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) จะพร้อมใช้งานสำหรับผู้ใช้
9.9.2 ข้อกำหนดการเข้ารหัส
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเข้ารหัสข้อมูลส่วนตัวของแอปพลิเคชัน (
/data
พาร์ติชัน) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (พาร์ติชัน/sdcard
) หากเป็นส่วนถาวรและนำออกไม่ได้ของอุปกรณ์ - [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าเริ่มต้นเสร็จแล้ว
[C-0-3] ต้องเป็นไปตามข้อกำหนดในการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้น โดยการใช้วิธีการเข้ารหัส 1 ใน 2 วิธีต่อไปนี้
- การเข้ารหัสตามไฟล์ (FBE) และการเข้ารหัสข้อมูลเมตา ตามที่อธิบายไว้ในส่วนที่ 9.9.3.1
- การเข้ารหัสระดับการบล็อกต่อผู้ใช้ตามที่อธิบายไว้ในส่วนที่ 9.9.3.2
9.9.3 วิธีการเข้ารหัส
การติดตั้งใช้งานอุปกรณ์จะได้รับการเข้ารหัสดังนี้
- [C-1-1] ต้องเปิดเครื่องโดยไม่ให้ผู้ใช้ขอข้อมูลเข้าสู่ระบบและอนุญาตให้แอป Direct Boot ที่รู้จักเข้าถึงพื้นที่เก็บข้อมูล Device Encrypted (DE) หลังจากเผยแพร่ข้อความ
ACTION_LOCKED_BOOT_COMPLETED
- [C-1-2] ต้องอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) หลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยให้ข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และระบบเผยแพร่ข้อความ
ACTION_USER_UNLOCKED
แล้วเท่านั้น - [C-1-13] ต้องไม่เสนอวิธีปลดล็อกพื้นที่เก็บข้อมูลที่มีการป้องกัน CE ที่ไม่มีข้อมูลเข้าสู่ระบบที่ผู้ใช้ระบุ คีย์เอสโครว์ที่ลงทะเบียนแล้ว หรือการดำเนินการต่อเมื่อรีบูตตามข้อกำหนดในส่วนที่ 9.9.4
- [C-1-4] ต้องใช้การเปิดเครื่องที่ได้รับการยืนยัน
9.9.3.1 การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา
หากการใช้งานอุปกรณ์ใช้การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา ระบบจะดำเนินการต่อไปนี้
- [C-1-5] ต้องเข้ารหัสเนื้อหาไฟล์และข้อมูลเมตาของระบบไฟล์โดยใช้ AES-256-XTS หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวคีย์เข้ารหัส 256 บิต ซึ่งทำงานในโหมด XTS ความยาวเต็มของคีย์คือ 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ที่ https://github.com/google/adiantum ข้อมูลเมตาของระบบไฟล์คือข้อมูลอย่างเช่น ขนาดไฟล์ การเป็นเจ้าของ โหมด และแอตทริบิวต์แบบขยาย (xattr)
- [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS หรือ Adiantum
- [C-1-12] หากอุปกรณ์มีวิธีการที่ใช้มาตรฐานการเข้ารหัสขั้นสูง (AES) (เช่น ARMv8 Cryptography Extensions ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86) คุณต้องใช้ตัวเลือกแบบ AES ข้างต้นสำหรับชื่อไฟล์ เนื้อหาไฟล์ และการเข้ารหัสข้อมูลเมตาของระบบไฟล์ ไม่ใช่ Adiantum
- [C-1-13] ต้องใช้ฟังก์ชันดึงข้อมูลคีย์ที่มีการเข้ารหัสที่รัดกุมและย้อนกลับไม่ได้ (เช่น HKDF-SHA512) เพื่อรับคีย์ย่อยที่จำเป็น (เช่น คีย์ต่อไฟล์) จากคีย์ CE และ DE "มีประสิทธิภาพในการเข้ารหัสและย้อนกลับไม่ได้" หมายความว่าฟังก์ชันการดึงคีย์มีความรัดกุมด้านความปลอดภัยอย่างน้อย 256 บิต และทํางานเป็นชุดฟังก์ชัน Pseudorandom สําหรับอินพุต
- [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยที่เข้ารหัสตามไฟล์ (FBE) เดียวกันเพื่อวัตถุประสงค์ในการเข้ารหัสที่แตกต่างกัน (เช่น ทั้งการเข้ารหัสและการดึงคีย์ หรือสำหรับอัลกอริทึมการเข้ารหัสที่แตกต่างกัน 2 รายการ)
- [C-1-15] ต้องตรวจสอบว่าบล็อกเนื้อหาไฟล์ที่เข้ารหัสซึ่งไม่ได้ลบทั้งหมดบนพื้นที่เก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่ขึ้นอยู่กับทั้งไฟล์และออฟเซ็ตภายในไฟล์ นอกจากนี้ ชุดค่าผสมทั้งหมดต้องแตกต่างกัน ยกเว้นในกรณีที่การเข้ารหัสโดยใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่รองรับความยาว IV ที่ 32 บิตเท่านั้น
- [C-1-16] ต้องตรวจสอบว่าชื่อไฟล์ที่เข้ารหัสซึ่งไม่ได้ลบทั้งหมดบนพื้นที่เก็บข้อมูลถาวรในไดเรกทอรีแยกได้รับการเข้ารหัสโดยใช้ชุดคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่แตกต่างกัน
[C-1-17] ต้องตรวจสอบว่าบล็อกข้อมูลเมตาของระบบไฟล์ที่เข้ารหัสทั้งหมดในพื้นที่เก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่แตกต่างกัน
คีย์ที่ปกป้องพื้นที่เก็บข้อมูลของ CE และ DE และข้อมูลเมตาของระบบไฟล์มีดังนี้
- [C-1-7] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
- [C-1-8] คีย์ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้
- [C-1-9] คีย์ CE ต้องเชื่อมโยงกับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบในหน้าจอล็อก
- [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ ไม่มีคีย์ CE หรือ DE ของผู้ใช้ที่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
- [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่สนับสนุนที่จำเป็น
- [C-1-12] ต้องลบข้อมูลอย่างปลอดภัยในระหว่างการปลดล็อก Bootloader และล็อกตามที่อธิบายไว้ที่นี่
ควรทำให้แอปสำคัญที่ติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเสนเจอร์) รับรู้การเปิดเครื่องโดยตรง
โปรเจ็กต์ต้นทางของ Android ต้นทางมีการติดตั้งใช้งานที่แนะนำสำหรับการเข้ารหัสตามไฟล์ โดยอิงตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนลของ Linux และการเข้ารหัสข้อมูลเมตาที่อิงตามฟีเจอร์ "dm-default-key" ของเคอร์เนลของ Linux
9.9.3.2 การเข้ารหัสระดับการบล็อกต่อผู้ใช้
หากการใช้งานอุปกรณ์ใช้การเข้ารหัสระดับบล็อกต่อผู้ใช้ การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องเปิดใช้การสนับสนุนผู้ใช้หลายคนตามที่อธิบายไว้ในส่วน 9.5
- [C-1-2] ต้องระบุพาร์ติชันต่อผู้ใช้ ไม่ว่าจะใช้พาร์ติชันดิบหรือวอลุ่มเชิงตรรกะ
- [C-1-3] ต้องใช้คีย์การเข้ารหัสที่ไม่ซ้ำกันและไม่ซ้ำกันต่อผู้ใช้สำหรับการเข้ารหัสอุปกรณ์บล็อกพื้นฐาน
[C-1-4] ต้องใช้ AES-256-XTS สำหรับการเข้ารหัสระดับบล็อกของพาร์ติชันผู้ใช้
คีย์ที่ช่วยปกป้องอุปกรณ์ที่เข้ารหัสระดับการบล็อกต่อผู้ใช้มีดังนี้
- [C-1-5] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
- [C-1-6] ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง
การเข้ารหัสระดับบล็อกต่อผู้ใช้สามารถนำมาใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของ Linux เหนือพาร์ติชันต่อผู้ใช้
9.9.4 ดำเนินการต่อเมื่อรีบูต
"กลับมาทำงานอีกครั้งเมื่อรีบูต" จะช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมด รวมถึงแอปที่ยังไม่รองรับ Direct Boot หลังจากการรีบูตที่เริ่มต้นโดย OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้หลังจากรีบูต
การใช้การดำเนินการต่อเมื่อรีบูตจะต้องดำเนินไปอย่างต่อเนื่องเพื่อให้มั่นใจว่าเมื่ออุปกรณ์ตกอยู่ในมือของผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัส CE ของผู้ใช้ได้ยากมากแม้ว่าอุปกรณ์จะเปิดอยู่ มีการปลดล็อกพื้นที่เก็บข้อมูล CE และผู้ใช้ที่ปลดล็อกอุปกรณ์หลังจากได้รับ OTA ก็ตาม สำหรับการต้านทานการโจมตีจากบุคคลภายใน เราสันนิษฐานว่าผู้โจมตีมีสิทธิ์เข้าถึงการเผยแพร่คีย์การเข้ารหัสลับ
ดังนี้
[C-0-1] พื้นที่เก็บข้อมูล CE ต้องไม่อ่านได้ แม้แต่ผู้โจมตีที่มีอุปกรณ์จริงและมีความสามารถและข้อจำกัดต่อไปนี้
- ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามในข้อความที่กำหนดเอง
- อาจทำให้อุปกรณ์รับ OTA ได้
- แก้ไขการทำงานของฮาร์ดแวร์ใดก็ได้ (AP, Flash และอื่นๆ) ยกเว้นตามรายละเอียดด้านล่าง แต่การแก้ไขดังกล่าวจะมีความล่าช้าอย่างน้อย 1 ชั่วโมงและรอบการเปิดปิดที่ทำลายเนื้อหา RAM
- ไม่สามารถแก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการงัดแงะ (เช่น Titan M)
- ไม่สามารถอ่าน RAM ของอุปกรณ์ที่กำลังใช้งานอยู่
- ขอรับข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) ไม่ได้หรือทำให้ต้องป้อนข้อมูลดังกล่าว
ตัวอย่างเช่น การใช้งานอุปกรณ์ที่มีการใช้งานและสอดคล้องกับคำอธิบายทั้งหมดที่นี่จะเป็นไปตามข้อกำหนด [C-0-1]
9.10 ความสมบูรณ์ของอุปกรณ์
ข้อกำหนดต่อไปนี้ช่วยให้สถานะความสมบูรณ์ของอุปกรณ์มีความโปร่งใส การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API
PersistentDataBlockManager.getFlashLockState()
ว่าสถานะของ Bootloader อนุญาตให้มีการกะพริบอิมเมจของระบบหรือไม่[C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์
หากมีการเปิดตัวการใช้งานอุปกรณ์โดยไม่รองรับการเปิดเครื่องที่ได้รับการยืนยันใน Android เวอร์ชันก่อนหน้าแล้ว และไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบได้ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด
การเปิดเครื่องที่ได้รับการยืนยันคือฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์นี้ ฟีเจอร์จะทำงานดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์ของแพลตฟอร์ม
android.software.verified_boot
- [C-1-2] ต้องทำการยืนยันในทุกลำดับการเปิดเครื่อง
- [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรากฐานของความน่าเชื่อถือและไปจนถึงพาร์ติชันระบบ
- [C-1-4] ต้องใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความถูกต้องและความน่าเชื่อถือของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
- [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่เข้มงวดเช่นเดียวกับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
- [C-1-6] ต้องไม่อนุญาตให้เปิดเครื่องเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้ยินยอมที่จะลองเปิดเครื่องอีกครั้ง ซึ่งในกรณีนี้ ต้องไม่ใช้ข้อมูลจากการบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยัน
- [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ว่าผู้ใช้ปลดล็อก Bootloader อย่างชัดแจ้ง
- [C-SR-1] หากมีชิปแยกต่างหากหลายชิปในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์พิเศษ) ขอแนะนำอย่างยิ่งให้เปิดเครื่องของแต่ละชิปดังกล่าวเพื่อยืนยันทุกขั้นตอนเมื่อเปิดเครื่อง
- [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะ เพื่อจัดเก็บว่า Bootloader ถูกปลดล็อกหรือไม่ พื้นที่เก็บข้อมูลที่มีการงัดแงะหมายความว่า Bootloader ตรวจสอบได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
- [C-1-9] ต้องแจ้งผู้ใช้ขณะใช้อุปกรณ์ และต้องขอการยืนยันทางกายภาพก่อนอนุญาตให้เปลี่ยนจากโหมดล็อก Bootloader เป็นโหมดปลดล็อก Bootloader
- [C-1-10] ต้องใช้การป้องกันย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น การเปิดเครื่อง พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่ชัดเจนสำหรับการจัดเก็บข้อมูลเมตาที่ใช้กำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
- [C-1-11] ต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยในระหว่างการปลดล็อกและล็อก Bootloader ตาม "9.12" การลบข้อมูล (รวมถึงพาร์ติชันข้อมูลผู้ใช้และพื้นที่ทำงาน NVRAM)
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดกับเชนความน่าเชื่อถือที่รูทในพาร์ติชันที่มีการป้องกันโดยการเปิดเครื่องที่ได้รับการยืนยัน
- [C-SR-3] ขอแนะนำเป็นอย่างยิ่งให้ยืนยันอาร์ติแฟกต์ที่เรียกใช้ได้ซึ่งโหลดโดยแอปที่ได้รับสิทธิ์จากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์) ก่อนที่จะเรียกใช้ หรือขอแนะนำว่าอย่าเรียกใช้เนื้อหาดังกล่าวเลย
- ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์ถาวร (เช่น โมเด็ม กล้อง) และควรใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะในการจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันต่ำสุดที่อนุญาต
หากการใช้งานอุปกรณ์เปิดตัวไปแล้วโดยไม่รองรับ C-1-8 ถึง C-1-11 ใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านี้อาจได้รับการยกเว้นจากข้อกำหนดนั้นๆ
โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำในที่เก็บ external/avb/
ซึ่งผสานรวมเข้ากับ Bootloader ที่ใช้สำหรับการโหลด Android
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องรองรับการยืนยันเนื้อหาไฟล์แบบเข้ารหัสกับคีย์ที่เชื่อถือได้โดยไม่ต้องอ่านทั้งไฟล์
- [C-0-4] ต้องไม่อนุญาตให้คำขอการอ่านในไฟล์ที่มีการป้องกันประสบความสำเร็จเมื่อเนื้อหาที่อ่านไม่ได้รับการยืนยันกับคีย์ที่เชื่อถือได้
หากมีการเปิดตัวอุปกรณ์ไปแล้วโดยไม่สามารถยืนยันเนื้อหาไฟล์กับคีย์ที่เชื่อถือได้ใน Android เวอร์ชันก่อนหน้า และจะเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบไม่ได้ การใช้งานอุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำโดยอิงตามฟีเจอร์ fs-verity ของเคอร์เนลของ Linux
การติดตั้งใช้งานอุปกรณ์
- [C-SR-4] ขอแนะนำอย่างยิ่งให้รองรับ Android Protected Verifyation API
หากอุปกรณ์รองรับ Android Protected Verifyation API
[C-3-1] ต้องรายงาน
true
สำหรับConfirmationPrompt.isSupported()
API[C-3-2] ต้องตรวจสอบว่าโค้ดที่ทำงานในระบบปฏิบัติการ Android รวมถึงเคอร์เนลของระบบปฏิบัติการ Android เป็นอันตรายหรือไม่เช่นนั้น ต้องไม่สร้างการตอบสนองเชิงบวกหากไม่มีการโต้ตอบจากผู้ใช้
[C-3-3] ต้องตรวจสอบว่าผู้ใช้ตรวจสอบและอนุมัติข้อความที่แจ้งแล้วได้ แม้ว่าระบบปฏิบัติการ Android ซึ่งรวมถึงเคอร์เนลจะมีช่องโหว่ก็ตาม
9.11 คีย์และข้อมูลเข้าสู่ระบบ
ระบบคีย์สโตร์ของ Android ช่วยให้นักพัฒนาแอปสามารถจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์และใช้คีย์ดังกล่าวในการดำเนินการเข้ารหัสผ่าน KeyChain API หรือ Keystore API การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอนุญาตให้นำเข้าหรือสร้างคีย์ได้อย่างน้อย 8,192 คีย์
- [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องใช้ช่วงเวลาระหว่างจำนวนครั้งที่ดำเนินการไม่สำเร็จ หากมี n เป็นจำนวนครั้งที่ล้มเหลว ช่วงเวลาจะต้องไม่ต่ำกว่า 30 วินาทีเป็นเวลา 9 < n < 30 วินาที สำหรับ n > 29 ค่าช่วงเวลาต้องเป็นอย่างน้อย 30*2^floor((n-30)/10)) วินาทีหรืออย่างน้อย 24 ชั่วโมง ขึ้นอยู่กับว่ากรณีใดน้อยกว่า
- ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้
เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องสำรองข้อมูลการใช้คีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการที่แยกไว้
- [C-1-2] ต้องมีการใช้งาน RSA, AES, ECDSA, ECDH (หากรองรับ IKeyMintDevice), 3DES, และอัลกอริทึมการเข้ารหัส HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่รองรับระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัยในเคอร์เนล การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อทำสำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกจะต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากเท่านั้นในการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android นี้มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [C-1-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนามในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
- [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปเพื่อเปลี่ยนจาก ปลดล็อกเป็นสถานะล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตสูงสุด 15 วินาที อุปกรณ์ยานยนต์ที่จะล็อกหน้าจอเมื่อมีการปิด เครื่องเสียงหรือสลับผู้ใช้ อาจไม่มีการกำหนดค่า ระยะหมดเวลาสลีป
- [C-1-6] ต้องรองรับ IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice เวอร์ชัน 1 หรือ IKeyMintDevice เวอร์ชัน 2
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ IKeyMintDevice เวอร์ชัน 1
9.11.1 หน้าจอล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือน
การใช้งาน AOSP เป็นไปตามโมเดลการตรวจสอบสิทธิ์แบบเป็นขั้น ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตามความรู้สามารถรองรับได้โดยใช้ข้อมูลไบโอเมตริกระดับรองที่แข็งแกร่งหรือวิธีการที่สามซึ่งมีประสิทธิภาพน้อยกว่า
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] แนะนำอย่างยิ่งให้ตั้งค่าวิธีใดวิธีหนึ่งต่อไปนี้เป็นวิธีการตรวจสอบสิทธิ์หลัก
- PIN ที่เป็นตัวเลข
- รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
- รูปแบบการปัดในตารางกริดที่มีจุด 3x3 พอดี
โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเป็นวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้
หากการใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำและใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะเป็นดังนี้
- [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน Requiring User Authentication For Key Use
หากใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกหากอิงตามข้อมูลลับที่ทราบ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อให้ถือว่าเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ
- [C-3-1] เอนโทรปีของอินพุตที่มีความยาวสั้นที่สุดต้องไม่เกิน 10 บิต
- [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
- [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) และระบุไว้ใน AOSP
- [C-3-4] วิธีการตรวจสอบสิทธิ์ใหม่จะต้องปิดใช้เมื่อ แอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้ง นโยบายข้อกำหนดของรหัสผ่านผ่าน DevicePolicyManager.setrequiredPasswordComplexity() ด้วยค่าคงที่ที่มีความซับซ้อนมากกว่า PASSWORD_COMPLEXITY_NONE หรือผ่านเมธอด DevicePolicyManager.setPasswordQITY() โดยมีค่าคงที่มากกว่า PasswordQMETRICITY
- [C-3-5] วิธีการตรวจสอบสิทธิ์แบบใหม่ต้องกลับไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยให้ผู้ใช้ทราบอย่างชัดเจนว่าจะไม่มีการสำรองข้อมูลบางส่วนเพื่อรักษาความเป็นส่วนตัวของข้อมูล
หากการใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในการปลดล็อกหน้าจอล็อกและใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามข้อมูลไบโอเมตริกเพื่อให้เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ เราจะใช้วิธีการใหม่ดังนี้
- [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 7.3.10 สำหรับคลาส 1 (เดิมคือความสะดวกสบาย)
- [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ซึ่งอิงตามข้อมูลลับที่ทราบ
- [C-4-3] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์การล็อกโดยเรียกใช้เมธอด
DevicePolicyManager.setKeyguardDisabledFeatures()
ด้วยแฟล็กข้อมูลไบโอเมตริกที่เกี่ยวข้อง (เช่นKEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
,KEYGUARD_DISABLE_FACE
หรือKEYGUARD_DISABLE_IRIS
)
หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับคลาส 3 (เดิมเรียกว่ารัดกุม) ตามที่อธิบายไว้ในส่วนที่ 7.3.10 ให้ทำดังนี้
- [C-5-1] จะต้องปิดใช้เมธอดหากแอปพลิเคชัน Device Policy Controller (DPC)
ตั้งค่านโยบายคุณภาพของข้อกำหนดของรหัสผ่านผ่าน
DevicePolicyManager.setrequiredPasswordComplexity()
ที่มีที่เก็บข้อมูลความซับซ้อนที่จำกัดมากกว่า
PASSWORD_COMPLEXITY_LOW
หรือใช้เมธอด DevicePolicyManager.setPasswordquality() ซึ่งมีคุณภาพคงที่ที่เข้มงวดกว่าPASSWORD_QUALITY_BIOMETRIC_WEAK
- [C-5-2] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วนที่ 7.3.10
- [C-5-3] วิธีการนี้ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อกำหนดที่ขึ้นต้นด้วย C-8 ในส่วนนี้ด้านล่าง
หากมีการใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกและวิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามโทเค็นจริงหรือตำแหน่ง
- [C-6-1] ผู้ดูแลระบบต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตาม ข้อกำหนดในการถือเป็นหน้าจอล็อกที่ปลอดภัย
- [C-6-2] ต้องปิดใช้วิธีการใหม่นี้และอนุญาตเฉพาะวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นในการปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายอย่างใดอย่างหนึ่งต่อไปนี้
- เมธอด
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- วิธี
DevicePolicyManager.setPasswordQuality()
ที่มีค่าคงที่ด้านคุณภาพที่จำกัดมากกว่าPASSWORD_QUALITY_NONE
- วิธี
DevicePolicyManager.setRequiredPasswordComplexity()
ที่มีที่เก็บข้อมูลความซับซ้อนที่จำกัดมากกว่าPASSWORD_COMPLEXITY_NONE
- เมธอด
- [C-6-3] ผู้ใช้ต้องได้รับคำถามสำหรับวิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่งที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 4 ชั่วโมงหรือน้อยกว่านั้น เมื่อโทเค็นจริงตรงตามข้อกำหนดสำหรับการติดตั้งใช้งาน TrustAgent ใน C-X ข้อจำกัดการหมดเวลาที่กำหนดไว้ใน C-9-5 จะมีผลแทน
- [C-6-4] วิธีการใหม่ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการซึ่งใช้ TrustAgentService
System API จะมีการดำเนินการต่อไปนี้
- [C-7-1] ต้องระบุข้อมูลที่ชัดเจนในเมนูการตั้งค่าและในหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ หรือสามารถปลดล็อกได้โดยเอเจนต์ความน่าเชื่อถือ ตัวอย่างเช่น AOSP เป็นไปตามข้อกำหนดนี้โดยการแสดงคำอธิบายข้อความสำหรับ "การตั้งค่าล็อกอัตโนมัติ" และ "ล็อกปุ่มเปิด/ปิดทันที" ในเมนูการตั้งค่าและไอคอนแยกได้บนหน้าจอล็อก
- [C-7-2] ต้องเคารพและติดตั้งใช้งาน API ของเอเจนต์ความน่าเชื่อถือทั้งหมดในคลาส
DevicePolicyManager
เช่น ค่าคงที่KEYGUARD_DISABLE_TRUST_AGENTS
- [C-7-3] ต้องไม่ใช้ฟังก์ชัน
TrustAgentService.addEscrowToken()
อย่างสมบูรณ์ในอุปกรณ์ที่ใช้เป็นอุปกรณ์หลักส่วนตัว (เช่น มือถือ) แต่อาจใช้ฟังก์ชันเต็มรูปแบบในอุปกรณ์ที่มักใช้ร่วมกัน (เช่น Android TV หรืออุปกรณ์ Automotive) - [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย
TrustAgentService.addEscrowToken()
- [C-7-5] ต้องไม่เก็บคีย์การเข้ารหัสหรือโทเค็นเอสโครว์ไว้ในอุปกรณ์เดียวกับที่ใช้คีย์ เช่น อนุญาตให้ใช้คีย์ที่จัดเก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้ในทีวี สำหรับอุปกรณ์ยานยนต์ ระบบไม่อนุญาตให้จัดเก็บโทเค็นเอสโครว์ไว้ในส่วนใดๆ ของยานพาหนะ
- [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นเอสโครว์เพื่อถอดรหัสพื้นที่เก็บข้อมูล
- [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีหนึ่ง
- [C-7-8] ผู้ใช้ต้องได้รับการยืนยันตัวตนสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่า เว้นแต่ว่าจะคำนึงถึงความปลอดภัยของผู้ใช้ (เช่น การรบกวนผู้ขับขี่)
- [C-7-9] ผู้ใช้ต้องได้รับการยืนยันตัวตนสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในหัวข้อ 7.3.10 เว้นแต่ว่าจะคำนึงถึงความปลอดภัยของผู้ใช้ (เช่น การรบกวนผู้ขับขี่)
- [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องปฏิบัติตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
- [C-7-11] ต้องไม่อนุญาตให้ TrustAgents ในอุปกรณ์หลักส่วนตัว (เช่น มือถือ) ในการปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกแล้วเป็นเวลาสูงสุด 4 ชั่วโมงเท่านั้น การใช้งาน TrustManagerService ตามค่าเริ่มต้นใน AOSP เป็นไปตามข้อกำหนดนี้
- [C-7-12] ต้องใช้ช่องทางการสื่อสารที่มีการเข้ารหัสเพื่อความปลอดภัย (เช่น UKEY2) เพื่อส่งโทเค็นคนกลางจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย
หากใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อกการล็อกปุ่มกด
- [C-8-1] ต้องปิดใช้วิธีการใหม่เมื่อแอปพลิเคชัน Device Policy Controller
(DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด
DevicePolicyManager.setPasswordQuality()
ที่มีค่าคงที่ที่มีคุณภาพที่เข้มงวดมากกว่าPASSWORD_QUALITY_NONE
หรือผ่านDevicePolicyManager.setRequiredPasswordComplexity()
ที่มีค่าคงที่ที่เข้มงวดมากกว่า "PASSWORD_COMPLEXITY_NONE" - [C-8-2] ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่
DevicePolicyManager.setPasswordExpirationTimeout()
ตั้งไว้ - [C-8-3] ต้องไม่เปิดเผย API ให้แอปของบุคคลที่สามใช้งานเพื่อระบุสถานะการล็อก
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและไม่รองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager
จะมีการดำเนินการต่อไปนี้
- [C-9-1] ต้องล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ล็อกอยู่ และปลดล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ปลดล็อกอยู่
หากการนำอุปกรณ์ไปใช้งานทำให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองได้และรองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager เหตุการณ์จะมีลักษณะดังนี้
- [C-10-1] ต้องรองรับสถานะการล็อกที่แยกต่างหากต่ออุปกรณ์เสมือน
- [C-10-2] ต้องยกเลิกการเชื่อมต่ออุปกรณ์เสมือนทั้งหมดเมื่อไม่มีการใช้งานจนถึงระยะหมดเวลา
- [C-10-3] ต้องมีระยะหมดเวลาเนื่องจากไม่มีการใช้งาน
- [C-10-4] ต้องล็อกจอแสดงผลทั้งหมดเมื่อผู้ใช้เริ่ม การปิดล็อก รวมถึง การชำระค่าปิดล็อกสำหรับอุปกรณ์พกพาที่จำเป็น (ดู ส่วนที่ 2.2.5[9.11/H-1-2])
- [C-10-5] ต้องมีอินสแตนซ์อุปกรณ์เสมือนแยกกันต่อผู้ใช้
- [C-10-6] ต้องปิดใช้การสร้างเหตุการณ์อินพุตที่เกี่ยวข้องผ่าน
VirtualDeviceManager
เมื่อระบุโดยDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] ต้องใช้คลิปบอร์ดแยกกันสำหรับอุปกรณ์เสมือนแต่ละเครื่องเท่านั้น (หรือปิดใช้คลิปบอร์ดสำหรับอุปกรณ์เสมือน)
- [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึง การป้อนปัจจัยความรู้และข้อความแจ้งข้อมูลไบโอเมตริก
- [C-10-12] ต้องจำกัด Intent ที่เริ่มต้นจากอุปกรณ์เสมือนให้แสดงเฉพาะ บนอุปกรณ์เสมือนเครื่องเดียวกันเท่านั้น
- [C-10-13] ต้องไม่ใช้สถานะล็อกอุปกรณ์เสมือนเป็นการให้สิทธิ์การตรวจสอบสิทธิ์ผู้ใช้ด้วยระบบ Android Keystore โปรดดู
KeyGenParameterSpec.Builder.setUserAuthentication*
เมื่อใช้งานอุปกรณ์อนุญาตให้ผู้ใช้โอนปัจจัยความรู้ในการตรวจสอบสิทธิ์หลักจากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เช่น การตั้งค่าเริ่มต้นของอุปกรณ์เป้าหมาย การดำเนินการเหล่านี้จะมีผลดังนี้
- [C-11-1] ต้องเข้ารหัสฐานความรู้โดยมีการรับประกันการปกป้องที่คล้ายคลึงกับที่ระบุไว้ในสมุดปกขาวเกี่ยวกับความปลอดภัยของบริการ Google Cloud Key Vault เมื่อโอนปัจจัยความรู้จากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เพื่อไม่ให้ระบบสามารถถอดรหัสหรือใช้เครื่องมือความรู้จากระยะไกลเพื่อปลดล็อกอุปกรณ์ใดอุปกรณ์หนึ่งได้จากระยะไกล
- [C-11-2] ต้องขอให้ผู้ใช้ยืนยันปัจจัยความรู้ของอุปกรณ์ต้นทางก่อนที่จะโอนปัจจัยความรู้ไปยังอุปกรณ์เป้าหมาย
- [C-11-3] ในอุปกรณ์เป้าหมายที่ไม่มีองค์ความรู้ด้านการตรวจสอบสิทธิ์หลักที่ตั้งไว้ ขอให้ผู้ใช้ยืนยันปัจจัยความรู้ที่โอนในอุปกรณ์เป้าหมายก่อนตั้งค่ากราฟความรู้เป็นปัจจัยหลักในการตรวจสอบสิทธิ์สำหรับอุปกรณ์เป้าหมาย และก่อนที่จะทำให้ข้อมูลที่โอนมาจากอุปกรณ์ต้นทางพร้อมใช้งาน
หากการนำอุปกรณ์ไปใช้งานมีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งเรียกใช้ TrustAgentService.grantTrust()
System API ด้วยแฟล็ก FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
จะมีคำสั่งต่อไปนี้
- [C-12-1] ต้องเรียกใช้
grantTrust()
พร้อมธงเฉพาะเมื่อเชื่อมต่อกับอุปกรณ์จริงในบริเวณใกล้เคียงที่มีหน้าจอล็อกของตนเอง และเมื่อผู้ใช้ตรวจสอบสิทธิ์ตัวตนกับหน้าจอล็อกนั้นแล้ว อุปกรณ์ที่อยู่ในบริเวณใกล้เคียงสามารถใช้กลไกการตรวจจับบนข้อมือหรือบนร่างกายหลังจากที่ปลดล็อกผู้ใช้ครั้งเดียวแล้วเพื่อให้เป็นไปตามข้อกำหนดในการตรวจสอบสิทธิ์ของผู้ใช้ - [C-12-2] ต้องทำให้การใช้งานอุปกรณ์อยู่ในสถานะ
TrustState.TRUSTABLE
เมื่อหน้าจอปิด (เช่น การกดปุ่มหรือหมดเวลาหน้าจอ) และ TrustAgent ไม่ได้เพิกถอนความไว้วางใจ AOSP เป็นไปตาม ข้อกำหนดนี้ - [C-12-3] ต้องย้ายอุปกรณ์จาก
TrustState.TRUSTABLE
ไปยังสถานะTrustState.TRUSTED
เฉพาะเมื่อ TrustAgent ยังคงให้ความไว้วางใจตามข้อกำหนดใน C-12-1 - [C-12-4] ต้องเรียกใช้
TrustManagerService.revokeTrust()
หลังจากเวลาสูงสุด 24 ชั่วโมงนับจากที่ให้สิทธิ์ กรอบเวลาที่ไม่มีการใช้งาน 8 ชั่วโมง หรือเมื่อการเชื่อมต่อพื้นฐานกับอุปกรณ์จริงที่อยู่ใกล้ๆ ขาดหาย
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและรองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager และจอแสดงผลไม่ได้ทำเครื่องหมายด้วย VIRTUAL_DISPLAY_FLAG_SECURE ไว้ สิ่งต่อไปนี้จะเกิดขึ้น
- [C-13-8] ต้องบล็อก activities ด้วยแอตทริบิวต์ android:canDisplayOnRemote Devices หรือเมตา-data android.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น "เท็จ" ไม่ให้เริ่มทำงานในอุปกรณ์เสมือนจริง
- [C-13-9] ต้องบล็อกกิจกรรม ซึ่งไม่ได้เปิดใช้สตรีมมิงอย่างชัดแจ้ง และ ระบุว่าแสดงเนื้อหาที่ละเอียดอ่อนผ่าน SurfaceView#setSecure, FLAG_SECURE หรือ SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS ไม่ให้เริ่มทำงานบนอุปกรณ์เสมือน
หากการใช้งานอุปกรณ์รองรับสถานะกำลังแสดงผลแบบแยกกันผ่าน DeviceStateManager
และรองรับสถานะการล็อก Display แยกกันผ่าน KeyguardDisplayManager
ระบบจะดำเนินการต่อไปนี้
- [C-SR-2] แนะนำอย่างยิ่งให้ใช้ข้อกำหนดในการรับรองเอกสารรับรองตามที่ระบุไว้ในส่วนที่ 9.11.1 หรือข้อกำหนดเฉพาะด้านข้อมูลไบโอเมตริกอย่างน้อย คลาส 1 ที่ระบุไว้ในข้อ 7.3.10 เพื่อให้สามารถปลดล็อกด้วยตนเองจากจอแสดงผลของอุปกรณ์เริ่มต้น
- [C-SR-3] ขอแนะนำอย่างยิ่งให้จำกัดการปลดล็อกจอแสดงผลแยกต่างหาก ผ่านระยะหมดเวลาการแสดงผลที่กำหนดไว้
- [C-SR-4] ขอแนะนำอย่างยิ่งเพื่ออนุญาตให้ผู้ใช้ล็อกจอแสดงผลทั้งหมดทั่วโลกผ่านการปิดล็อกจากอุปกรณ์พกพาหลัก
9.11.2 StrongBox
ระบบ Android Keystore ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะได้เช่นเดียวกับสภาพแวดล้อมการดำเนินการที่แยกต่างหากตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 ถึง C-1-11 ด้านล่างเป็นข้อกำหนดที่อุปกรณ์ต้องปฏิบัติตามเพื่อให้เป็น StrongBox
การใช้งานอุปกรณ์ที่มีหน่วยประมวลผลที่ปลอดภัยโดยเฉพาะ
- [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้สนับสนุน StrongBox StrongBox มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป
หากการติดตั้งใช้งานอุปกรณ์รองรับ StrongBox สิ่งที่จะเกิดขึ้นมีดังนี้
[C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE
[C-1-2] ต้องระบุฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะที่ใช้ในการสนับสนุนคีย์สโตร์และการตรวจสอบสิทธิ์ผู้ใช้ที่ปลอดภัย ฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะอาจถูกใช้เพื่อวัตถุประสงค์อื่นๆ ได้เช่นกัน
[C-1-3] ต้องมี CPU แบบแยกส่วนที่ไม่แชร์แคช, DRAM, โปรเซสเซอร์ร่วม หรือทรัพยากรหลักอื่นๆ กับตัวประมวลผลแอปพลิเคชัน (AP)
[C-1-4] ต้องตรวจสอบให้แน่ใจว่าอุปกรณ์ต่อพ่วงที่แชร์กับ AP ต้องไม่แก้ไขการประมวลผล StrongBox ในทุกกรณี หรือรับข้อมูลจาก StrongBox AP อาจปิดใช้หรือบล็อกการเข้าถึง StrongBox
[C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำพอสมควร (+-10%) ซึ่งภูมิคุ้มกันต่อการควบคุมโดย AP
[C-1-6] ต้องมีโปรแกรมสร้างตัวเลขสุ่มจริงที่สร้างผลลัพธ์ที่มีการกระจายอย่างสม่ำเสมอและคาดเดาไม่ได้
[C-1-7] ต้องมีการป้องกันการงัดแงะ รวมถึงความต้านทานการเจาะทะลุ ทางกายภาพและการแตกร้าว
[C-1-8] ต้องมี ความต้านทานต่อช่องสัญญาณด้านข้าง ซึ่งรวมถึง ความต้านทานการรั่วไหลของข้อมูลทางกำลัง เวลา รังสีแม่เหล็กไฟฟ้า และช่องที่แผ่รังสีความร้อน
[C-1-9] ต้องมีพื้นที่เก็บข้อมูลที่ปลอดภัยซึ่งจะช่วยรักษาข้อมูลที่เป็นความลับ ความซื่อสัตย์ ความถูกต้อง ความสอดคล้อง และความใหม่ของเนื้อหา พื้นที่เก็บข้อมูลต้องอ่านหรือแก้ไขไม่ได้ เว้นแต่ที่ StrongBox API อนุญาต
หากต้องการตรวจสอบการปฏิบัติตามข้อกำหนดกับ [C-1-3] จนถึง [C-1-9] การติดตั้งใช้งานอุปกรณ์ ให้ทำดังนี้
- [C-1-10] ต้องรวมฮาร์ดแวร์ที่ได้รับการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่เป็นไปได้ในการโจมตีสูงตามการใช้เกณฑ์ทั่วไปของโอกาสในการโจมตีกับสมาร์ทการ์ด
- [C-1-11] ต้องรวมเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับชาติซึ่งรวมการประเมินช่องโหว่ของการโจมตีที่มีโอกาสเกิดการโจมตีสูงตามการใช้เกณฑ์ร่วมกันของโอกาสในการโจมตีกับสมาร์ทการ์ด
- [C-SR-2] แนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ประเมินโดยใช้เป้าหมายความปลอดภัย, Evaluation Assurance Level (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มจะเป็นข้อกำหนด สำหรับการเผยแพร่ในอนาคต
- [C-SR-3] ขอแนะนำอย่างยิ่งให้เสริมการป้องกันการโจมตีจากบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox สามารถเปิดเผยข้อมูลลับ เพื่อหลบเลี่ยงข้อกำหนดด้านความปลอดภัยด้านฟังก์ชันการทำงาน หรือให้สิทธิ์เข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการใช้ IAR คืออนุญาตการอัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านหลักของผู้ใช้ผ่าน IAuthSecret HAL
9.11.3 ข้อมูลประจำตัว
ระบบจะกำหนดและใช้ระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัวด้วยการใช้ API ทั้งหมดในแพ็กเกจ android.security.identity.*
API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและเรียกข้อมูลเอกสารข้อมูลประจำตัวของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้ใช้ระบบข้อมูลประจำตัว
หากการติดตั้งใช้งานอุปกรณ์นำระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัวมาใช้ ระบบจะดำเนินการดังต่อไปนี้
[C-1-1] ต้องแสดงผลค่าที่ไม่ใช่ null สำหรับเมธอด IdentityCredentialStore#getInstance()
[C-1-2] ต้องใช้ระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัว (เช่น API ของ
android.security.identity.*
) ที่มีการสื่อสารโค้ดกับแอปพลิเคชันที่เชื่อถือในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและสูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA[C-1-3] การดำเนินการเข้ารหัสที่จำเป็นในการติดตั้งใช้งานระบบข้อมูลประจำตัว (เช่น API ของ
android.security.identity.*
) จะต้องดำเนินการทั้งหมดในแอปพลิเคชันที่เชื่อถือและเนื้อหาของคีย์ส่วนตัวต้องไม่ออกจากสภาพแวดล้อมการดำเนินการที่แยกออกมา เว้นแต่จะต้องการอย่างเจาะจงสำหรับ API ระดับสูงกว่า (เช่น เมธอด createEphemeralKeyPair())[C-1-4] แอปพลิเคชันที่เชื่อถือได้จะต้องใช้งานในลักษณะที่ไม่กระทบต่อคุณสมบัติด้านความปลอดภัย (เช่น ระบบจะไม่เผยแพร่ข้อมูลเข้าสู่ระบบ เว้นแต่จะเป็นไปตามเงื่อนไขการควบคุมการเข้าถึง จึงไม่สามารถสร้าง MAC สำหรับข้อมูลที่กำหนดเองได้) แม้ว่า Android จะทำงานผิดปกติหรือถูกบุกรุก
โปรเจ็กต์โอเพนซอร์ส Android มีการติดตั้งใช้งานข้อมูลอ้างอิงของแอปพลิเคชันที่เชื่อถือได้ (libeic) ซึ่งสามารถใช้เพื่อติดตั้งใช้งานระบบข้อมูลประจำตัวได้
9.12 การลบข้อมูล
การติดตั้งใช้งานอุปกรณ์ทั้งหมด
- [C-0-1] ต้องระบุกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
- [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ข้อมูลผู้ใช้เมื่อดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
- [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88 เมื่อดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
- [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอป Device Policy Controller ของผู้ใช้หลักเรียกใช้ API ของ
DevicePolicyManager.wipeData()
API - อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น
9.13 โหมดปลอดภัยเปิดเครื่อง
Android มีเซฟโหมดซึ่งช่วยให้ผู้ใช้เปิดเครื่องในโหมดที่ อนุญาตให้เรียกใช้ได้เฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าและ ปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการเปิดเครื่องที่ปลอดภัย" ช่วยให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้
การใช้งานอุปกรณ์มีดังนี้
- [C-SR-1] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง
หากติดตั้งใช้งานอุปกรณ์ไว้ในโหมดปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
[C-1-1] ต้องระบุตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยด้วยการเปิดเครื่องในลักษณะที่ไม่ขัดจังหวะการทำงานของแอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ ยกเว้นในกรณีที่แอปของบุคคลที่สามเป็นตัวควบคุมนโยบายด้านอุปกรณ์ และได้ตั้งค่าสถานะ
UserManager.DISALLOW_SAFE_BOOT
เป็น "จริง"[C-1-2] ต้องให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้
ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยจากเมนูเปิดเครื่องโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเปิดเครื่องปกติ
9.14 การแยกระบบยานพาหนะ
อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายรถยนต์ เช่น CAN Bus
การแลกเปลี่ยนข้อมูลจะปลอดภัยได้ด้วยการใช้ฟีเจอร์ความปลอดภัยด้านล่างเลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายหรือไม่ได้ตั้งใจกับระบบย่อยเหล่านี้
9.15 แพ็กเกจการสมัครใช้บริการ
"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ด้านการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()
การติดตั้งใช้งานอุปกรณ์ทั้งหมด
- [C-0-1] ต้องส่งคืนแพ็กเกจการสมัครใช้บริการไปยังแอปของผู้ให้บริการเครือข่ายมือถือที่ได้จัดเตรียมแพ็กเกจไว้ในตอนแรกเท่านั้น
- [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
- [C-0-3] ต้องอนุญาตเฉพาะการลบล้าง เช่น
SubscriptionManager.setSubscriptionOverrideCongested()
จากแอปของผู้ให้บริการเครือข่ายมือถือที่กำลังเสนอแพ็กเกจการสมัครใช้บริการที่ถูกต้องอยู่เท่านั้น
9.16 การย้ายข้อมูลแอปพลิเคชัน
หากการใช้งานอุปกรณ์มีความสามารถในการย้ายข้อมูลจากอุปกรณ์ไปยังอุปกรณ์อื่น และไม่จำกัดข้อมูลแอปพลิเคชันที่คัดลอกไว้ตามที่นักพัฒนาแอปพลิเคชันกำหนดค่าไว้ในไฟล์ Manifest ผ่านแอตทริบิวต์ android:fullBackupContent จะมีการดำเนินการดังนี้
- [C-1-1] ต้องไม่เริ่มการโอนข้อมูลแอปพลิเคชันจากอุปกรณ์ที่ผู้ใช้ไม่ได้ตั้งค่าการตรวจสอบสิทธิ์หลักตามที่อธิบายไว้ในหน้าจอล็อกและการตรวจสอบสิทธิ์ที่ปลอดภัยเวอร์ชัน 9.11.1
- [C-1-2] ต้องยืนยันการตรวจสอบสิทธิ์หลักในอุปกรณ์ต้นทางอย่างปลอดภัยและยืนยันกับเจตนาของผู้ใช้ในการคัดลอกข้อมูลในอุปกรณ์ต้นทางก่อนที่จะโอนข้อมูล
- [C-1-3] ต้องใช้เอกสารรับรองคีย์ความปลอดภัยเพื่อให้แน่ใจว่าทั้งอุปกรณ์ต้นทางและอุปกรณ์เป้าหมายในการย้ายข้อมูลระหว่างอุปกรณ์เป็นอุปกรณ์ Android ที่ถูกต้องตามกฎหมายและมี Bootloader ที่ล็อกไว้
- [C-1-4] ต้องย้ายข้อมูลแอปพลิเคชันไปยังแอปพลิเคชันเดียวกันในอุปกรณ์เป้าหมายที่มีชื่อแพ็กเกจและใบรับรองที่ลงนามเดียวกันเท่านั้น
- [C-1-5] ต้องแสดงตัวบ่งชี้ว่าอุปกรณ์ต้นทางได้มีการย้ายข้อมูลโดยการย้ายข้อมูลอุปกรณ์ไปยังอุปกรณ์ในเมนูการตั้งค่า ผู้ใช้ไม่ควรนำตัวบ่งชี้นี้ออกได้
9.17 เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android
หากอุปกรณ์ใช้การรองรับ Android Virtualization Framework (android.system.virtualmachine.*
) โฮสต์ Android จะทำสิ่งต่อไปนี้
- [C-1-1] ต้องรองรับ API ทั้งหมดที่กำหนดโดยแพ็กเกจ
android.system.virtualmachine.*
- [C-1-2] ต้องไม่แก้ไข SELinux ของ Android และโมเดลสิทธิ์สำหรับการจัดการเครื่องเสมือนที่มีการป้องกัน
- [C-1-3] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy ที่ระบุในโปรเจ็กต์โอเพนซอร์ส Android อัปสตรีม (AOSP) และนโยบายต้องคอมไพล์ด้วยกฎที่ไม่อนุญาตทั้งหมดที่มีอยู่
- [C-1-4] ต้องไม่อนุญาตให้โค้ดที่ไม่น่าเชื่อถือ (เช่น แอป 3p) สร้างและเรียกใช้เครื่องเสมือนที่มีการป้องกัน หมายเหตุ: ข้อมูลนี้อาจเปลี่ยนแปลงได้ใน Android รุ่นต่อๆ ไป
- [C-1-5] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้โค้ดที่ไม่ได้เป็นส่วนหนึ่งของอิมเมจเริ่มต้นหรือการอัปเดต สิ่งใดก็ตามที่ไม่ได้ครอบคลุมอยู่ในการเปิดเครื่องที่ได้รับการยืนยันของ Android (เช่น ไฟล์ที่ดาวน์โหลดจากอินเทอร์เน็ตหรือไซด์โหลด) ต้องไม่ได้รับอนุญาตให้ทำงานในเครื่องเสมือนที่มีการป้องกัน
หากอุปกรณ์ใช้การรองรับสำหรับ Android Virtualization Framework API (android.system.virtualmachine.*
) อินสแตนซ์ของเครื่องเสมือนที่มีการปกป้องจะทำสิ่งต่อไปนี้
- [C-2-1] ต้องเรียกใช้ระบบปฏิบัติการทั้งหมดที่มีอยู่ใน APEX เสมือนในเครื่องเสมือนที่มีการป้องกันได้
- [C-2-2] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้ระบบปฏิบัติการที่ไม่ได้รับรองโดยผู้ติดตั้งอุปกรณ์หรือผู้ให้บริการระบบปฏิบัติการ
- [C-2-3] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้ข้อมูลเป็นโค้ด (เช่น SELinux ไม่อนุญาต execmem)
- [C-2-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy/microdroid ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP)
- [C-2-5] ต้องใช้กลไกการป้องกันเชิงลึกของเครื่องเสมือนที่มีการป้องกัน (เช่น SELinux สำหรับ pVM) แม้แต่สำหรับระบบปฏิบัติการที่ไม่ใช่ Microdroid
- [C-2-6] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM ปฏิเสธที่จะเปิดเครื่องหากไม่สามารถยืนยันอิมเมจเริ่มต้นได้
- [C-2-7] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM ปฏิเสธที่จะเปิดเครื่องหากความสมบูรณ์ของอินสแตนซ์.img ลดลง
หากอุปกรณ์ใช้การรองรับ Android Virtualization Framework (android.system.virtualmachine.*
) ไฮเปอร์ไวเซอร์
- [C-3-1] ต้องไม่อนุญาตให้ pVM เข้าถึงหน้าเว็บที่เป็นของเอนทิตีอื่น (เช่น pVM หรือ Hypervisor อื่นๆ) เว้นแต่เจ้าของเพจจะแชร์อย่างชัดแจ้ง ซึ่งรวมถึง VM ของโฮสต์ ซึ่งจะมีผลกับทั้งการเข้าถึง CPU และ DMA
- [C-3-2] ต้องล้างข้อมูลหน้าหลังจากที่ VM ใช้และก่อนที่จะส่งกลับไปให้โฮสต์ (เช่น pVM ถูกทำลาย)
- [C-3-3] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM นั้นโหลดและเรียกใช้ก่อนโค้ดใดๆ ใน pVM
- [C-3-4] ต้องตรวจสอบว่า BCC และ CDI ที่ระบุให้กับอินสแตนซ์ pVM จะดึงมาจากอินสแตนซ์ดังกล่าวเท่านั้น
หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การดำเนินการทั้งหมดจะมีผลดังนี้
- [C-4-1] ต้องไม่มอบฟังก์ชันการทำงานให้แก่ pVM ที่อนุญาตให้ข้ามโมเดลความปลอดภัยของ Android
หากอุปกรณ์ใช้การรองรับ API ของ Virtualization Framework ของ Android คุณจะต้องดำเนินการต่อไปนี้
- [C-5-1] ต้องรองรับการคอมไพล์ Isolated ของการอัปเดตรันไทม์ ART
หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การจัดการคีย์จะมีผลดังนี้
- [C-6-1] ต้องรูทเชน DICE ตรงจุดที่ผู้ใช้แก้ไขไม่ได้แม้ในอุปกรณ์ที่ไม่ได้ล็อก (เพื่อให้แน่ใจว่าไม่มีการปลอมแปลง)
- [C-6-2] ต้อง DICE อย่างถูกต้อง นั่นคือ ระบุค่าที่ถูกต้อง
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจการทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ทำการเปลี่ยนแปลงข้อมูลอ้างอิงและการติดตั้งใช้งาน Android ที่ต้องการจากโปรเจ็กต์โอเพนซอร์ส Android ให้น้อยที่สุดเท่าที่จะเป็นไปได้ วิธีนี้จะช่วยลดความเสี่ยงในการเกิดข้อบกพร่องที่ก่อให้เกิดความไม่เข้ากัน ซึ่งต้องมีการปรับปรุงและอัปเดตอุปกรณ์ที่อาจเกิดขึ้น
10.1 ชุดเครื่องมือทดสอบความเข้ากันได้
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) ที่มีให้จากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์
[C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS และการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ
CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง CTS เองอาจมีข้อบกพร่องอยู่ในตัวเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะได้รับเวอร์ชันแยกกันตามคำจำกัดความความเข้ากันได้นี้ และ CTS เวอร์ชันต่างๆ อาจมีการเผยแพร่ใน Android 13
การติดตั้งใช้งานอุปกรณ์
[C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์
ควรใช้การใช้งานข้อมูลอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้มากที่สุด
10.2 ผู้ตรวจสอบ CTS
เครื่องมือตรวจสอบ CTS จะรวมอยู่ในชุดทดสอบความเข้ากันได้ โดยมีเป้าหมายให้เจ้าหน้าที่ดำเนินการทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น กล้องและเซ็นเซอร์ทำงานได้อย่างถูกต้อง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องดำเนินการกับทุกกรณีที่เกี่ยวข้องในเครื่องมือยืนยัน CTS อย่างถูกต้อง
CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางชนิดที่ไม่บังคับ
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีตัวตรวจวัดความเร่ง ตัวตรวจวัดความเร่งจะต้องดำเนินการกับเคสทดสอบตัวตรวจวัดความเร่งอย่างถูกต้องในโปรแกรมตรวจสอบ CTS
กรณีทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับโดยคำจำกัดความความเข้ากันได้นี้ ระบบอาจข้ามหรือละเว้นเอกสารดังกล่าว
- [C-0-2] อุปกรณ์ทุกเครื่องและทุกบิลด์ต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่กล่าวไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ติดตั้งใช้งานอุปกรณ์จึงไม่คาดว่าจะเรียกใช้ CTS Verifier อย่างชัดแจ้งในบิลด์ที่แตกต่างกันเพียงเล็กน้อยเท่านั้น กล่าวอย่างเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่านการตรวจสอบ CTS Verifier ผ่านชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมไว้ อาจข้ามการทดสอบ CTS Verifier ได้
11. ซอฟต์แวร์ที่อัปเดตได้
[C-0-1] การใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "จริง" กล่าวคืออาจจำเป็นต้องรีสตาร์ทอุปกรณ์ คุณจะใช้วิธีการใดก็ได้ โดยมีเงื่อนไขว่าจะแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการใดต่อไปนี้จะสอดคล้องกับข้อกำหนดนี้
- การดาวน์โหลด "ผ่านอากาศ (OTA)" ด้วยการอัปเดตแบบออฟไลน์ผ่านรีบูต
- การอัปเดต "Tethered" ผ่าน USB จากคอมพิวเตอร์โฮสต์
- การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนที่เก็บข้อมูลแบบถอดได้
[C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ต้องล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องเก็บรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android อัปสตรีมมีกลไกการอัปเดตที่เป็นไปตามข้อกำหนดนี้
[C-0-3] การอัปเดตทั้งหมดต้องมีการลงชื่อและกลไกการอัปเดตในอุปกรณ์ ต้องตรวจสอบการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์
[C-SR-1] เราขอแนะนำอย่างยิ่งให้แฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256
หากการใช้งานอุปกรณ์รองรับการเชื่อมต่ออินเทอร์เน็ตที่ไม่มีการวัดปริมาณอินเทอร์เน็ต เช่น 802.11 หรือโปรไฟล์ PAN ของบลูทูธ (เครือข่ายส่วนบุคคล) ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับการดาวน์โหลด OTA ที่มีการอัปเดตแบบออฟไลน์ผ่านรีบูต
การใช้งานอุปกรณ์ควรยืนยันว่าอิมเมจระบบเป็นไบนารีเดียวกันกับผลลัพธ์ที่คาดไว้หลังจาก OTA การใช้งาน OTA แบบบล็อกในโปรเจ็กต์โอเพนซอร์ส Android ที่เพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้
นอกจากนี้ การใช้งานอุปกรณ์ควรรองรับการอัปเดตระบบ A/B AOSP ใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการเปิดเครื่อง
หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากที่เผยแพร่แล้ว แต่อยู่ภายในอายุการใช้งานผลิตภัณฑ์ที่สมเหตุสมผล ซึ่งพิจารณาร่วมกับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม
- [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่มีให้ใช้งาน ซึ่งสามารถนำไปใช้ตามกลไกที่อธิบายไว้ได้
Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ หากระบบย่อยของการอัปเดตระบบสำหรับอุปกรณ์ รายงานว่าเป็น android.software.device_admin ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy
12. บันทึกการเปลี่ยนแปลงของเอกสาร
ต่อไปนี้เป็นข้อมูลสรุปเกี่ยวกับการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้
4 ตุลาคม 2023
2. ประเภทอุปกรณ์
-
ดูการแก้ไข
- [9.8/H-1-14] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนตามที่อธิบายไว้ในส่วน 9.8.2
[9.8/C-3-1]เมื่อมีการส่งผลลัพธ์ของคำสั่งให้ดำเนินการไปยังเสียงพูด
- [9.8/H-1-14] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนตามที่อธิบายไว้ในส่วน 9.8.2
-
ดูการแก้ไข
[5.1/H-1-7] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอขนาด 1080p หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ทั้งหมด เมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียง 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองการเริ่มต้นของตัวแปลงต้องไม่เกิน 50 มิลลิวินาที
[5.1/H-1-12] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการถอดรหัสวิดีโอขนาด 1080p หรือต่ำกว่าสำหรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นเล่นวิดีโอเสียง 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองการเริ่มต้นของตัวแปลงรหัสต้องไม่เกิน 50 มิลลิวินาที
[5.1/H-1-13] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการถอดรหัสเสียงที่มีอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับตัวถอดรหัสเสียงทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นเล่นเสียง-วิดีโอ 1080p
7.4. การเชื่อมต่อข้อมูล
7.4.1.1 ความสามารถในการบล็อกหมายเลข
ดูการแก้ไข
การนำอุปกรณ์ไปใช้งานรายงานฟีเจอร์
android.hardware.telephony.calling
สิ่งที่จะเกิดขึ้นมีดังนี้-
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รายงาน
android.hardware.telephony.calling
สิ่งที่จะเกิดขึ้นมีดังนี้
9.11 คีย์และข้อมูลเข้าสู่ระบบ
-
ดูการแก้ไข
มีให้บริการผ่าน IAuthSecret HAL
ถูกนำออก IAR จะกลายเป็นข้อกำหนดที่จำเป็นใน Android 14
26 มิถุนายน 2023
2. ประเภทอุปกรณ์
-
นำข้อกำหนด 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7 ออก
การอัปเดตอื่นๆ:
ดูการแก้ไข
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดผลที่ระบุไว้ใน
ข้อกําหนดการปรับเทียบสถานที่ตั้งของผู้ใช้
-
ดูการแก้ไข
หากใช้อุปกรณ์ 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 ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
3. ซอฟต์แวร์
3.2.3.5 Intent ของแอปพลิเคชันแบบมีเงื่อนไข
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony.calling
ระบบจะดำเนินการต่อไปนี้android.hardware.telephony
7. ความเข้ากันได้ของฮาร์ดแวร์
-
ดูการแก้ไข
ข้อกำหนดการปรับเทียบสถานที่ตั้ง
9. ความเข้ากันได้กับโมเดลความปลอดภัย
-
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์
[C-0-5] ต้องไม่ให้สิทธิ์รันไทม์กับแอปที่
ติดตั้งไว้ล่วงหน้ายกเว้นในกรณีต่อไปนี้- จะติดตั้งให้แล้ว ณ เวลาที่จัดส่งอุปกรณ์ และ
- ต้องได้รับความยินยอมจากผู้ใช้ก่อน แอปพลิเคชัน
จะใช้
สิทธิ์สิทธิ์ดังกล่าว
OR
- สิทธิ์รันไทม์มาจากนโยบายการให้สิทธิ์เริ่มต้นหรือสำหรับการถือบทบาทแพลตฟอร์ม
ที่เชื่อมโยงกับรูปแบบ Intent ที่มีการตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
-
- นำข้อกำหนด [C-13-10] และ 9.11.4 ออก
20 มีนาคม 2023
2. ประเภทอุปกรณ์
-
ดูการแก้ไข
หากแอปพลิเคชันการตั้งค่าการใช้งานอุปกรณ์พกพาใช้ฟังก์ชันการแยกส่วนโดยใช้การฝังกิจกรรม การดำเนินการต่อไปนี้
- [
C-17-13.2.3.1/ H-1-1] ต้องมีกิจกรรมที่จัดการ การตั้งค่า#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY เมื่อเปิดฟังก์ชันการทำงานแบบแยกส่วน กิจกรรมต้องได้รับการคุ้มครองโดยandroid.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
และต้องเริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จากการตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI
สิ้นสุดข้อกำหนดใหม่
- [
-
ดูการแก้ไข
หากอุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 รองรับการถอดรหัส VP9 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.7/T-
2-1SR1] แนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)
- [5.3.7/T-
-
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
[7.3/A-
0-1SR1] อาจสิ้นเปลืองเวลา ตำแหน่ง โดยการรวม GPS/GNSS กับเซ็นเซอร์เพิ่มเติม หากยกเลิกตำแหน่งแล้ว เราขอแนะนำเป็นอย่างยิ่งให้ใช้และรายงานประเภทเซ็นเซอร์และ/หรือรหัสอสังหาริมทรัพย์ของยานพาหนะที่เกี่ยวข้อง[7.3/A-
0-20-4] สถานที่ ที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่ใช่แผนที่ที่ตรงกัน
3. ซอฟต์แวร์
-
ดูการแก้ไข
บัญชีเริ่มต้นสำหรับรายชื่อติดต่อใหม่: Contacts Provider มี API สำหรับจัดการการตั้งค่าของบัญชีเริ่มต้นเมื่อสร้างรายชื่อติดต่อใหม่
หากอุปกรณ์ติดตั้งใช้งานแอปรายชื่อติดต่อไว้ล่วงหน้า แอปรายชื่อติดต่อที่โหลดไว้ล่วงหน้า จะดำเนินการต่อไปนี้
[C-2-1] ต้องจัดการ Intent
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
เพื่อเปิดใช้ UI สำหรับการเลือกบัญชี และบันทึกการตั้งค่าไปยัง Contacts Provider เมื่อมีการเลือกบัญชี[C-2-2] ต้องใช้การตั้งค่าบัญชีเริ่มต้นเมื่อจัดการ
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
สำหรับContactsContracts.Contacts.CONTENT_TYPE
และContactsContract.RawContacts.CONTENT_TYPE
โดยเลือกบัญชีในตอนแรก
สิ้นสุดข้อกำหนดใหม่
3.2.3.5 Intent ของแอปพลิเคชันแบบมีเงื่อนไข
ดูการแก้ไข
[ย้ายไปยัง 2.2.3]
หากแอปพลิเคชันการตั้งค่าการใช้งานอุปกรณ์ใช้ฟังก์ชันการแยกส่วนโดยใช้การฝังกิจกรรม การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-17-1] ต้องมีกิจกรรมที่จัดการ Intent
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY เมื่อเปิดใช้ฟังก์ชันแบบแยก กิจกรรมต้องได้รับการคุ้มครองโดย
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
และต้อง เริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จาก การตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI
สิ้นสุดข้อกำหนดใหม่
- [C-17-1] ต้องมีกิจกรรมที่จัดการ Intent
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY เมื่อเปิดใช้ฟังก์ชันแบบแยก กิจกรรมต้องได้รับการคุ้มครองโดย
6. เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
ดูการแก้ไข
- ลิง
- [C-0-8] ต้องรวมเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันต่างๆ ใช้ได้
- ลิง
7. ความเข้ากันได้ของฮาร์ดแวร์
-
ดูการแก้ไข
[ย้ายไปที่ 7.4.9]
หากการใช้งานอุปกรณ์มีการรองรับ 802.1.15.4 และมีฟังก์ชันการทำงานนี้แก่แอปพลิเคชันของบุคคลที่สาม สิทธิ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้ Android API ที่สอดคล้องกันใน android.uwb
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
- [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่กำหนดไว้ใน การใช้งาน Android
- [C-1-4] ต้องระบุค่าบริการเพื่อให้ผู้ใช้สามารถสลับสถานะเปิด/ปิดวิทยุ UWB
- [C-1-5] ต้องบังคับใช้การใช้สิทธิ์ UWB_RANGING ของแอปโดยใช้สิทธิ์ UWB_RANGING ของแอป (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)
- [C-1-6] ขอแนะนำเป็นอย่างยิ่งให้ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องที่กำหนดโดยองค์กรมาตรฐาน รวมถึง FIRA, CCC และ CSA
สิ้นสุดข้อกำหนดใหม่
-
ดูการแก้ไข
หากการใช้งานอุปกรณ์
รวมถึงโทรศัพท์ GSM หรือ CDMAรายงานฟีเจอร์android.hardware.telephony
ให้ทำดังนี้- [C-6-1]
SmsManager#sendTextMessage
และSmsManager#sendMultipartTextMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อให้บริการฟังก์ชันการรับส่งข้อความSmsManager#sendMultimediaMessage
และSmsManager#downloadMultimediaMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อมอบฟังก์ชันการรับส่งข้อความมัลติมีเดีย - [C-6-2] แอปพลิเคชันที่กำหนดโดย
android.provider.Telephony.Sms#getDefaultSmsPackage
ต้องใช้ SmsManager API เมื่อส่งและรับข้อความ SMS และ MMS การใช้งานข้อมูลอ้างอิง AOSP ในแพ็กเกจ/แอป/การรับส่งข้อความจะเป็นไปตามข้อกำหนดนี้ - [C-6-3] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องรองรับการป้อนรหัสแป้นโทรศัพท์ที่กำหนดเองในรูปแบบ*#*#CODE#*#*
และ ทริกเกอร์การออกอากาศTelephonyManager#ACTION_SECRET_CODE
ที่เกี่ยวข้อง - [C-6-4] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องใช้VoicemailContract.Voicemails#TRANSCRIPTION
เพื่อแสดงการถอดข้อความเสียงเป็นภาพต่อผู้ใช้หากรองรับ การถอดข้อความเสียงเป็นภาพ - [C-6-5] ต้องแสดง SubscriptionInfo ทั้งหมดด้วย UUID กลุ่มที่เทียบเท่ากันเป็นการสมัครใช้บริการเดียวในราคาที่แสดงต่อผู้ใช้ทั้งหมดซึ่งจะแสดงและควบคุมข้อมูลซิมการ์ด ตัวอย่างของค่าใช้จ่ายดังกล่าว ได้แก่ อินเทอร์เฟซการตั้งค่าที่ตรงกับ
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
หรือEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] ต้องไม่แสดงหรืออนุญาตการควบคุม SubscriptionInfo ด้วย UUID กลุ่มและบิตของโอกาสที่ไม่เป็นค่าว่าง โดยอนุญาตให้กำหนดค่าหรือควบคุมการตั้งค่าซิมการ์ดได้
หากการใช้งานอุปกรณ์
มีระบบโทรศัพท์ GSM หรือ CDMAให้รายงานฟีเจอร์android.hardware.telephony
และมีแถบสถานะของระบบ จากนั้นให้ทำดังนี้- [C-
6-7-1] ต้องเลือกการสมัครใช้บริการที่เป็นตัวแทนซึ่งใช้งานอยู่สำหรับ UUID ของกลุ่มที่ระบุเพื่อแสดงต่อผู้ใช้ในทุกระดับราคาที่จะให้ข้อมูลสถานะซิม เช่น ไอคอนสัญญาณมือถือในแถบสถานะหรือการ์ดการตั้งค่าด่วน - [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้ใช้การสมัครใช้บริการของตัวแทนเป็นการสมัครใช้บริการข้อมูลที่ใช้งานอยู่ เว้นแต่อุปกรณ์กำลังอยู่ในสาย โดยในระหว่างนั้นเราขอแนะนำอย่างยิ่งว่าการสมัครใช้บริการของตัวแทนจะเป็นการสมัครใช้บริการ Voice ที่ใช้งานอยู่
หากการใช้งานอุปกรณ์
รวมถึงโทรศัพท์ GSM หรือ CDMAรายงานฟีเจอร์android.hardware.telephony
จากนั้นให้ทำดังนี้- [C-6-
87] ต้องมีความสามารถในการเปิดและใช้ช่องทางเชิงตรรกะจำนวนสูงสุดพร้อมกัน (ทั้งหมด 20 แชแนล) สำหรับ UICC แต่ละรายการตาม ETSI TS 102 221 - [C-6-
108] ต้องไม่ใช้ลักษณะการทำงานต่อไปนี้กับแอปของผู้ให้บริการที่ใช้งานอยู่ (ตามที่กำหนดโดยTelephonyManager#getCarrierServicePackageName
) โดยอัตโนมัติหรือไม่มีการยืนยันจากผู้ใช้อย่างชัดแจ้ง- เพิกถอนหรือจำกัดสิทธิ์เข้าถึงเครือข่าย
- เพิกถอนสิทธิ์
- จำกัดการดำเนินการของแอปในเบื้องหลังหรือเบื้องหน้านอกเหนือจากฟีเจอร์การจัดการพลังงานที่มีอยู่ซึ่งรวมอยู่ใน AOSP
- ปิดใช้หรือถอนการติดตั้งแอป
หากใช้อุปกรณ์
มีระบบโทรศัพท์ GSM หรือ CDMAรายงานฟีเจอร์android.hardware.telephony
และการสมัครใช้บริการที่ไม่ก่อให้เกิดโอกาสที่ใช้งานอยู่ทั้งหมดซึ่งแชร์ UUID ของกลุ่มนั้น, นำอุปกรณ์ออกจากเครื่องทันทีหรือทำเครื่องหมายเป็นโอกาส อุปกรณ์จะมีผลดังนี้- [C-
78-1] ต้องปิดใช้การสมัครใช้บริการตามโอกาสที่ยังใช้งานอยู่ทั้งหมดในกลุ่มเดียวกันโดยอัตโนมัติ
หากการติดตั้งใช้งานอุปกรณ์รวมถึงการใช้โทรศัพท์ GSM แต่ไม่ใช่โทรศัพท์ CDMA ระบบจะดำเนินการต่อไปนี้
- [C-
89-1] ต้องไม่ประกาศPackageManager#FEATURE_TELEPHONY_CDMA
- [C-
89-2] ต้องใส่IllegalArgumentException
เมื่อมีการพยายามตั้งค่าประเภทเครือข่าย 3GPP2 ในบิตมาสก์ประเภทเครือข่ายที่ต้องการหรืออนุญาต - [C-
89-3] ต้องแสดงผลสตริงว่างจากTelephonyManager#getMeid
หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC ที่มีพอร์ตและโปรไฟล์หลายรายการ ระบบจะดำเนินการดังต่อไปนี้
- [C-
1110-1] ต้องประกาศแฟล็กฟีเจอร์android.hardware.telephony.euicc.mep
- [C-6-1]
-
ดูการแก้ไข
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์หากการใช้งานอุปกรณ์มีการรองรับ 802.1.15.4 และแสดงฟังก์ชันดังกล่าวแก่แอปพลิเคชันของบุคคลที่สาม ระบบจะดำเนินการดังต่อไปนี้android.hardware.uwb
ผ่านคลาสandroid.content.pm.PackageManager
- [C-1-1] ต้องใช้ Android API ที่สอดคล้องกันใน android.uwb
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
- [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่กำหนดไว้ใน การใช้งาน Android
- [C-1-4] ต้องระบุค่าบริการเพื่อให้ผู้ใช้สามารถสลับสถานะเปิด/ปิดวิทยุ UWB
- [C-1-5] ต้องบังคับใช้การใช้สิทธิ์ UWB_RANGING ของแอปโดยใช้สิทธิ์ UWB_RANGING ของแอป (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องซึ่งกำหนดโดยองค์กรมาตรฐาน รวมถึง FIRA, CCC และ CSA
- [C-1-
16] ต้องตรวจสอบว่าระยะที่วัดได้อยู่ในช่วง +/-15 ซม. สำหรับ 95% ของค่าที่วัดในระดับสายตาของสภาพแวดล้อมที่ระยะห่าง 1 ม. ในห้องที่ไม่สะท้อน - [C-1-
27] ต้องตรวจสอบว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายใน [0.75 ม., 1.25 ม.] โดยระยะห่างจากความจริงของพื้นวัดจากขอบด้านบนของ DUT ที่ถือขึ้นโดยหงายขึ้นและเอียง 45 องศา - [C-SR-2] ขอแนะนำอย่างยิ่งให้ทำตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกำหนดในการปรับเทียบสถานที่ตั้ง
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการปรับเทียบสถานที่ตั้งของผู้ใช้สิ้นสุดข้อกำหนดใหม่
-
ดูการแก้ไข
เพื่อให้เข้ากันได้กับชุดหูฟังและอุปกรณ์เสริมเสียงอื่นๆ ที่ใช้เครื่องมือเชื่อมต่อ USB-C และมีการใช้งาน (คลาสเสียง USB) ในระบบนิเวศของ Android ตามที่ระบุไว้ในข้อมูลจำเพาะของชุดหูฟัง USB สำหรับ Android
19 ตุลาคม 2022
2. ประเภทอุปกรณ์
-
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาไม่ทำงานในโหมดล็อกงาน เมื่อคัดลอกเนื้อหาไปยังคลิปบอร์ดแล้ว ระบบจะดำเนินการดังต่อไปนี้
- [3.8.17/H-1-1] ต้องแสดงการยืนยันแก่ผู้ใช้ว่ามีการคัดลอกข้อมูลไปยังคลิปบอร์ด (เช่น ภาพขนาดย่อหรือการแจ้งเตือน "คัดลอกเนื้อหา") นอกจากนี้ ต้องใส่หมายเหตุที่นี่ด้วยระบุว่าระบบจะซิงค์ข้อมูลคลิปบอร์ดในอุปกรณ์ต่างๆ หรือไม่
3. ซอฟต์แวร์
3.2.3.5 Intent ของแอปพลิเคชันแบบมีเงื่อนไข
ดูการแก้ไข
หาก แอปพลิเคชันการตั้งค่าของอุปกรณ์ใช้งานฟังก์ชันการแยกส่วนโดยใช้การฝังกิจกรรม การดำเนินการดังกล่าวจะดำเนินการดังนี้
- [C-17-1] ต้องมีกิจกรรมที่จัดการ
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
เมื่อเปิดฟังก์ชันการทำงานแบบแยกส่วน กิจกรรมต้องได้รับการคุ้มครอง
โดย
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
และ ต้องเริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จาก การตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI
หากการนำอุปกรณ์ไปใช้งานรองรับ
VoiceInteractionService
และมีแอปพลิเคชันที่ใช้ API นี้ติดตั้งหลายรายการพร้อมกัน ระบบจะดำเนินการดังต่อไปนี้- [C-18-1] ต้องเป็นไปตามความตั้งใจของ
android.settings.ACTION_VOICE_INPUT_SETTINGS
ที่จะแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการป้อนข้อมูลด้วยเสียงและความช่วยเหลือ
- [C-17-1] ต้องมีกิจกรรมที่จัดการ
Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
เมื่อเปิดฟังก์ชันการทำงานแบบแยกส่วน กิจกรรมต้องได้รับการคุ้มครอง
โดย
3.4.1 ความเข้ากันได้กับ WebView
ดูการแก้ไข
- [C-1-4]ต้องแสดงผลเนื้อหาหรือเนื้อหา URL ระยะไกลที่ให้ไว้ในกระบวนการที่แตกต่างจากแอปพลิเคชันที่สร้างอินสแตนซ์ WebView กล่าวคือ กระบวนการแสดงผลที่แยกต่างหากต้องถือสิทธิ์ระดับล่าง เรียกใช้เป็นรหัสผู้ใช้แยกต่างหาก ไม่มีสิทธิ์เข้าถึงไดเรกทอรีข้อมูลของแอป ไม่มีการเข้าถึงเครือข่ายโดยตรง และมีสิทธิ์เข้าถึงเฉพาะบริการระบบที่จำเป็นขั้นต่ำผ่าน Binder เท่านั้น การใช้ AOSP ของ WebView เป็นไปตามข้อกำหนดนี้
7. ความเข้ากันได้ของฮาร์ดแวร์
-
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมการสนับสนุนสำหรับโหมดประหยัดพลังงาน Wi-Fi ตามที่ระบุไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์เหล่านี้จะมีผลดังนี้
[C-3-1] ต้องควร ปิดโหมดประหยัดพลังงาน Wi-Fi ทุกครั้งที่แอปติดตั้งWIFI_MODE_FULL_HIGH_PERF
ล็อกหรือWIFI_MODE_FULL_LOW_LATENCY
ล็อก ผ่านWifiManager.createWifiLock()
และWifiManager.WifiLock.acquire()
-
ดูการแก้ไข
หากอุปกรณ์รองรับบลูทูธพลังงานต่ำ (BLE) จะมีผลดังนี้
- [C-3-5] ต้องใช้ระยะหมดเวลา Resolvable Private Address (RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์กำลังใช้ BLE ในการสแกนหรือโฆษณา นอกจากนี้ ระบบจะสุ่มระยะหมดเวลาระหว่าง 5 ถึง 15 นาทีเพื่อป้องกันการโจมตีแบบจับเวลา
ดูการแก้ไข
หากอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าว
- [C-1-1] ต้องวางแนวเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับด้านยาวของหน้าจอ กล่าวคือ เมื่ออุปกรณ์อยู่ในแนวนอน กล้องจะต้องจับภาพในแนวนอน โดยจะใช้กับอุปกรณ์ไม่ว่าการวางแนวตามปกติของอุปกรณ์จะเป็นอย่างไรก็ตาม กล่าวคือมีผลกับอุปกรณ์หลักแนวนอนและอุปกรณ์หลักแนวตั้ง
อุปกรณ์ที่มีคุณสมบัติตรงตามเกณฑ์ต่อไปนี้ทั้งหมดจะได้รับการยกเว้นจากข้อกำหนดข้างต้น- อุปกรณ์ใช้หน้าจอที่มีเรขาคณิตหลากหลายแบบ เช่น จอแสดงผลแบบพับได้หรือแบบบานพับ
- เมื่อสถานะการพับหรือบานพับของอุปกรณ์เปลี่ยนไป อุปกรณ์จะเปลี่ยนระหว่างการวางแนวแนวตั้ง-หลักเป็นแนวนอน-หลัก (หรือกลับกัน)
สิ้นสุดข้อกำหนดใหม่
9. ความเข้ากันได้กับโมเดลความปลอดภัย
-
ดูการแก้ไข
เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้
- [C-1-6] ต้องรองรับ IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice เวอร์ชัน 1 หรือ IKeyMintDevice เวอร์ชัน 2
9.17 เฟรมเวิร์กเสมือนจริงของ Android
ดูการแก้ไข
หากอุปกรณ์ใช้การรองรับ API ของ Virtualization Framework ของ Android (
android.system.virtualmachine.*
) โฮสต์ Android จะทำสิ่งต่อไปนี้[C-1-3] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ ไม่อนุญาตภายในระบบ/sepolicy ที่ระบุในโปรเจ็กต์โอเพนซอร์ส Android อัปสตรีม (AOSP) และนโยบายต้องคอมไพล์ด้วยกฎที่ไม่อนุญาตทั้งหมดที่มีอยู่
หากอุปกรณ์รองรับ API เฟรมเวิร์กเสมือนจริงของ Android (
android.system.virtualmachine.*
) อินสแตนซ์ของเครื่องเสมือนที่มีการป้องกันจะมีลักษณะดังนี้[C-2-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy/microdroid ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP)
หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การจัดการคีย์จะมีผลดังนี้
- [C-6-2] ต้อง DICE อย่างถูกต้อง นั่นคือ ระบุค่าที่ถูกต้อง
แต่อาจไม่จำเป็นต้องลงรายละเอียดถึงระดับนั้น
15 สิงหาคม 2022
2. ประเภทอุปกรณ์
2.2.1 ฮาร์ดแวร์: การเปลี่ยนแปลงข้อกำหนดของฮาร์ดแวร์ดังนี้
อุปกรณ์อินพุต:
ดูการแก้ไข
การใช้งานอุปกรณ์เคลื่อนที่
- [7.2.3/H-0-5] ต้องเรียกใช้
OnBackInvokedCallback.onBackStarted()
ในหน้าต่างที่โฟกัสอยู่เมื่อท่าทางสัมผัสการย้อนกลับเริ่มขึ้นหรือปุ่มย้อนกลับ (KEYCODE_BACK
) ถูกกด "ลง" - [7.2.3/H-0-6] ต้องเรียกใช้
OnBackInvokedCallback.onBackInvoked()
เมื่อมีการใช้ท่าทางสัมผัสการย้อนกลับหรือเมื่อปล่อยปุ่มย้อนกลับ (UP) - [7.2.3/H-0-7] ต้องเรียกใช้
OnBackInvokedCallback.onBackCancelled()
หากไม่มีการทำท่าทางสัมผัสย้อนกลับหรือยกเลิกเหตุการณ์KEYCODE_BACK
สิ้นสุดข้อกำหนดใหม่
หากอุปกรณ์รองรับโปรโตคอล Wi-Fi Neighbor Awareness Networking (NAN) โดยประกาศ
PackageManager.FEATURE_WIFI_AWARE
และตำแหน่ง Wi-Fi (Wi-Fi Round Time — RTT) โดยประกาศPackageManager.FEATURE_WIFI_RTT
อุปกรณ์จะมีลักษณะดังนี้[7.4.2.5/H-1-1] ต้องรายงานช่วงอย่างถูกต้องภายในช่วงแบนด์วิดท์ +/-1 เมตรที่ 160 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามการคำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 และเปอร์เซ็นต์ Wi-Fi Manager ที่เปอร์เซ็นไทล์ที่ 68 และ 4-4 เมตรที่เปอร์เซ็นไทล์ที่ 68
[7.4.2.5/H-SR] แนะนำอย่างยิ่งให้รายงานช่วงอย่างถูกต้องภายในระยะ +/-1 เมตรที่ 160 MHz ที่เปอร์เซ็นไทล์ที่ 90 เปอร์เซ็นไทล์ที่ 90 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 90-RHz ที่ระยะทาง 90 MHz ที่เปอร์เซ็นไทล์ที่ 90 MHz และที่ระยะทาง 90 MHz ที่เปอร์เซ็นไทล์ที่ 90 MHz
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการปรับเทียบสถานที่ตั้ง
สิ้นสุดข้อกำหนดใหม่
- [7.2.3/H-0-5] ต้องเรียกใช้
เวลาในการตอบสนองของเสียง:
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาประกาศเป็น
android.hardware.audio.output
และandroid.hardware.microphone
สิ่งที่จะเกิดขึ้นมีดังนี้- [5.6/H-1-1] ต้องมีเวลาในการตอบสนองเฉลี่ยแบบไป-กลับที่
500
800มิลลิวินาทีหรือน้อยกว่าสำหรับการวัด 5 ครั้ง โดยมีค่าเบี่ยงเบนค่าเฉลี่ยต่ำกว่า 50100มิลลิวินาทีที่รองรับ, ผ่าน เส้นทางอะแดปเตอร์ต่อสาย USB 3 มม.)เส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
- [5.6/H-1-1] ต้องมีเวลาในการตอบสนอง "แตะเพื่อโทนเสียง" โดยเฉลี่ยอยู่ที่ 500 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดค่าระหว่างลำโพงสู่ไมโครโฟนอย่างน้อย 5 เส้นทาง
สิ้นสุดข้อกำหนดใหม่
- [5.6/H-1-1] ต้องมีเวลาในการตอบสนองเฉลี่ยแบบไป-กลับที่
500
อินพุตแบบรู้สึกได้:
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพามีตัวกระตุ้นการโต้ตอบแบบรู้สึกได้อย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.10/H]* ไม่ควรใช้ตัวขับเคลื่อนแบบรู้สึกได้ (การสั่น) แบบหมุนศูนย์กลาง (ERM)
- [7.10/H]* ควรวางตำแหน่งของตัวเปิดใช้งานใกล้กับตำแหน่งที่มักถือหรือสัมผัสอุปกรณ์ด้วยมือ
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสำหรับการโต้ตอบการสัมผัส ใน android.view.HapticFeedbackConstants ซึ่งก็คือ (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYUREBOARD_VITUALE,HANDKEYLE_KEY,
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสำหรับ
การโต้ตอบการสัมผัสที่ชัดเจน
ใน android.os.VibrationEffect
เช่น (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ
EFFECT_DOUBLE_CLICK) และค่าคงที่ feasible {/10 (การตั้งค่าที่ควบคุมได้)
PRIMITIVE_*
- [7.10/H]* ควรทำตามคำแนะนำสำหรับการแมปค่าคงที่สาธารณะใน android.view.HapticFeedbackConstants กับค่าคงที่ android.os.VibrationEffect ที่แนะนำ พร้อมความสัมพันธ์แอมพลิจูดที่สอดคล้องกัน
สิ้นสุดข้อกำหนดใหม่
- [7.10/H]* ควรตรวจสอบว่าผลลัพธ์ของ API สาธารณะ android.os.Vibrator.hasAmplitudeControl() แสดงความสามารถของการสั่นอย่างถูกต้อง
สิ้นสุดข้อกำหนดใหม่
- [7.10/H]* ควรตรวจสอบความสามารถในการปรับขนาดแอมพลิจูดโดยเรียกใช้ android.os.Vibrator.hasAmplitudeControl()
หากการใช้งานอุปกรณ์พกพามีตัวเปิดใช้เรโซแนนต์เชิงเส้นอย่างน้อย 1 ตัว
[7.10/H]* ควรย้ายตัวดำเนินการแบบรู้สึกได้ในแกน X (ซ้าย-ขวา) ของการวางแนวแนวตั้ง
[7.10/H]* ควรตรวจสอบและอัปเดตหากจำเป็นสำหรับการกำหนดค่าสำรองสำหรับค่าพื้นฐานที่ไม่รองรับ ตามที่อธิบายไว้ในหลักเกณฑ์การใช้งานสำหรับค่าคงที่
[7.10/H]* ควรมีการสนับสนุนวิดีโอสำรองเพื่อลดความเสี่ยงของความล้มเหลวตามที่อธิบายไว้ที่นี่
-
การตรวจสอบสิทธิ์ Trivial Device Cotntrols:
ดูการแก้ไข
- [3.8.16/H-1-5] ต้องให้เงินแก่ผู้ใช้
ในการเลือกไม่ใช้ระบบควบคุมอุปกรณ์ในการตรวจสอบสิทธิ์ที่กำหนดไว้สำหรับแอปจาก
การควบคุมที่ลงทะเบียนโดยแอปพลิเคชันของบุคคลที่สามผ่าน
ControlsProviderService
และControl
Control.isAuthRequired
API
- [3.8.16/H-1-5] ต้องให้เงินแก่ผู้ใช้
ในการเลือกไม่ใช้ระบบควบคุมอุปกรณ์ในการตรวจสอบสิทธิ์ที่กำหนดไว้สำหรับแอปจาก
การควบคุมที่ลงทะเบียนโดยแอปพลิเคชันของบุคคลที่สามผ่าน
การแจ้งเตือน MediaStyle:
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพารองรับการแจ้งเตือน MediaStyle การดำเนินการต่อไปนี้
- [3.8.3.1/H-1-SR] แนะนำอย่างยิ่ง เพื่อจัดหาเงินช่วยเหลือแก่ผู้ใช้(เช่น “ตัวสลับเอาต์พุต”) ที่เข้าถึงจาก UI ของระบบซึ่งช่วยให้ผู้ใช้สลับการใช้งานสื่อต่างๆ ที่เหมาะสม(เช่น อุปกรณ์บลูทูธและเส้นทางที่ให้บริการใน MediaRouter2Manager) เมื่อแอปโพสต์การแจ้งเตือนโทเค็น MediaStyle
2.2.4 ประสิทธิภาพและพลังงาน: ข้อกำหนดใหม่สำหรับแอปที่ใช้บริการที่ทำงานอยู่เบื้องหน้า
ดูการแก้ไข
การใช้งานอุปกรณ์เคลื่อนที่
- [8.5/H-0-1] ต้องระบุราคาสำหรับผู้ใช้ในเมนูการตั้งค่า ซึ่งมีความสามารถในการหยุดแอปที่กำลังให้บริการที่ทำงานอยู่เบื้องหน้า และแสดงแอปทั้งหมดที่มีบริการที่ทำงานอยู่เบื้องหน้าและระยะเวลาของบริการแต่ละรายการตั้งแต่ที่เริ่มให้บริการตามที่อธิบายไว้ในเอกสาร SDK
- แอปบางแอปอาจได้รับการยกเว้นไม่ต้องถูกหยุดหรือระบุไว้ในราคาของผู้ใช้ตามที่อธิบายไว้ในเอกสาร SDK
สิ้นสุดข้อกำหนดใหม่
- [8.5/H-0-1] ต้องระบุราคาสำหรับผู้ใช้ในเมนูการตั้งค่า ซึ่งมีความสามารถในการหยุดแอปที่กำลังให้บริการที่ทำงานอยู่เบื้องหน้า และแสดงแอปทั้งหมดที่มีบริการที่ทำงานอยู่เบื้องหน้าและระยะเวลาของบริการแต่ละรายการตั้งแต่ที่เริ่มให้บริการตามที่อธิบายไว้ในเอกสาร SDK
2.2.7.1 สื่อ: การปรับปรุงส่วน "สื่อข้อกำหนดสำหรับอุปกรณ์เคลื่อนที่" มีดังนี้
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาแสดงผล
android.os.Build.VERSION_CODES.T
เป็นเวลาandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้- [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์
ที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่านเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30 FPS
- [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ที่เรียกใช้พร้อมกันได้ในชุดค่าผสมใดๆ ของตัวแปลงรหัสผ่านเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์และ
เซสชันโปรแกรมถอดรหัสที่เรียกใช้พร้อมกันในชุดค่าผสมใดๆ ของตัวแปลงรหัสผ่าน
เมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-6] ต้องรองรับตัวถอดรหัสวิดีโอฮาร์ดแวร์และเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/H-1-7] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอขนาด 1080p หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ทั้งหมด เมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียง 1080p
- [5.1/H-1-8] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสเสียงที่มีอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดเมื่ออยู่ระหว่างการโหลด "โหลดที่นี่" หมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียง 1080p
- [5.1/H-1-9] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 2 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30 FPS
- [5.1/H-1-10] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ไม่ปลอดภัย 3 อินสแตนซ์ ร่วมกับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 1 อินสแตนซ์ (ทั้งหมด 4 อินสแตนซ์) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30fps
- [5.1/ H-1-11] ต้องรองรับตัวถอดรหัสที่ปลอดภัยสำหรับฮาร์ดแวร์ AVC, HEVC, VP9 หรือตัวถอดรหัส AV1 ทั้งหมดในอุปกรณ์
- [5.1/H-1-12] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวถอดรหัสวิดีโอไม่เกิน 40 มิลลิวินาที
- [5.1/H-1-13] ต้องมีเวลาในการตอบสนองเริ่มต้นของตัวถอดรหัสเสียงไม่เกิน 30 มิลลิวินาที
- [5.1/H-1-14] ต้องรองรับตัวถอดรหัสฮาร์ดแวร์ AV1 Main 10, ระดับ 4.1
- [5.1/H-SR] ขอแนะนำอย่างยิ่งให้รองรับเนื้อฟิล์มสำหรับตัวถอดรหัสฮาร์ดแวร์ AV1
- [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
- [5.1/H-1-16] ต้องมีโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อย่างน้อย 1 โปรแกรมที่รองรับ 4K60
- [5.3/H-1-1] ต้องไม่ตัดภาพเกิน 1 เฟรมใน 10 วินาที (เช่น การลดลงของเฟรมน้อยกว่า 0.167 เปอร์เซ็นต์) สำหรับเซสชันวิดีโอ 1080p 60 FPS ระหว่างการโหลด โหลดหมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC 128 kbps
- [5.3/H-1-2] ต้องไม่วางภาพลงมากกว่า 1 เฟรมใน 10 วินาทีระหว่างที่เปลี่ยนความละเอียดของวิดีโอในเซสชันวิดีโอ 60 FPS ในช่วงระหว่างโหลด การโหลดหมายถึงเซสชันการแปลงวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC 128 kbps
- [5.6/H-1-1] ต้องมีเวลาในการตอบสนองของการแตะเพื่อโทนอยู่ที่ 80 มิลลิวินาทีหรือน้อยกว่า โดยใช้การทดสอบการแตะเพื่อโทนของ OboeTester หรือการทดสอบการแตะเพื่อโทนของ CTS Verifier
- [5.6/H-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับไม่เกิน 80 มิลลิวินาทีเมื่อเทียบกับเส้นทางข้อมูลที่รองรับอย่างน้อย 1 เส้นทาง
- [5.6/H-1-3] ต้องรองรับเสียง >=24 บิตสำหรับเอาต์พุตสเตอริโอผ่านช่องเสียบเสียง 3.5 มม.
หากมีและผ่านเสียง USB หากรองรับผ่าน
เส้นทางข้อมูลทั้งหมดสำหรับเวลาในการตอบสนองต่ำและการกำหนดค่าสตรีมมิง สำหรับการกำหนดค่าที่มีเวลาในการตอบสนองต่ำ แอปควรใช้ AAudio ในโหมด Callback ที่มีเวลาในการตอบสนองต่ำ แอปควรใช้ Java AudioTrack สำหรับการกำหนดค่าสตรีมมิง ทั้งสำหรับการกำหนดค่าสตรีมมิงและเวลาในการตอบสนองต่ำ ซิงก์เอาต์พุต HAL ควรยอมรับ
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
หรือAUDIO_FORMAT_PCM_FLOAT
สำหรับรูปแบบเอาต์พุตเป้าหมาย - [5.6/H-1-4] ต้องรองรับอุปกรณ์เสียง USB ที่มีช่องสัญญาณ >=4 ช่อง (ตัวควบคุมของดีเจจะใช้สำหรับการแสดงตัวอย่างเพลง)
- [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่เป็นไปตามคลาสและประกาศแฟล็กฟีเจอร์ MIDI
- [5.7/H-1-2] ต้องรองรับ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
ที่มีความสามารถในการถอดรหัสเนื้อหาด้านล่าง
ขนาดการสุ่มตัวอย่างขั้นต่ำ 4 MiB จำนวนตัวอย่างย่อยขั้นต่ำ - H264 หรือ HEVC 28 จำนวนตัวอย่างย่อยขั้นต่ำ - VP9 9 จำนวนตัวอย่างย่อยขั้นต่ำ - AV1 288 ขนาดบัฟเฟอร์ของตัวอย่างย่อยขั้นต่ำ 1 MiB ขนาดบัฟเฟอร์คริปโตทั่วไปขั้นต่ำ 500 KiB จํานวนเซสชันที่เกิดขึ้นพร้อมกันขั้นต่ำ 30 จำนวนคีย์ขั้นต่ำต่อเซสชัน 20 จำนวนคีย์ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 80 จำนวนคีย์ DRM ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 6 ขนาดข้อความ 16 KiB เฟรมที่ถอดรหัสต่อวินาที 60 FPS สิ้นสุดข้อกำหนดใหม่
- [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์
ที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่านเมธอด
2.2.7.2 กล้อง: การอัปเดตข้อกำหนดของกล้องสำหรับชั้นเรียนประสิทธิภาพของสื่อ
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาแสดงผล
android.os.Build.VERSION_CODES.T
เป็นเวลาandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้- [7.5/H-1-1] ต้องมีกล้องหลังตัวหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล ซึ่งรองรับการจับภาพวิดีโอที่ 4k@30fps กล้องหลังตัวหลักคือกล้องหลังที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 5 ล้านพิกเซล และรองรับการบันทึกวิดีโอที่ 1080p@30fps กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้
android.info.supportedHardwareLevel
เป็นFULL
หรือดีกว่าสำหรับกล้องหลักทั้ง 2 ตัว - [7.5/H-1-4] ต้องรองรับ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
สำหรับกล้องหลักทั้ง 2 ตัว - [7.5/H-1-5] ต้องมีเวลาในการตอบสนองในการจับภาพ Camera2 JPEG < 1,000 มิลลิวินาทีสำหรับความละเอียด 1080p ตามที่วัดโดยการทดสอบประสิทธิภาพของกล้อง CTS ภายใต้สภาพแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูเฟรมตัวอย่างแรก) < 500 มิลลิวินาทีที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-8] ต้องรองรับ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
และandroid.graphics.ImageFormat.RAW_SENSOR
สำหรับกล้องหลังหลัก - [7.5/H-1-9] ต้องมีกล้องหลักที่ด้านหลังที่รองรับ 720p หรือ 1080p @ 240fps
- [7.5/H-1-10] ต้องมีค่าขั้นต่ำ ZOOM_RATIO < 1.0 สำหรับกล้องหลักหากมีกล้อง RGB มุมกว้างพิเศษที่หันไปในทิศทางเดียวกัน
- [7.5/H-1-11] ต้องใช้การสตรีมหน้าหลังพร้อมกันในกล้องหลัก
- [7.5/H-1-12] ต้องรองรับ
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
ทั้งสำหรับกล้องหน้าและกล้องหลังหลัก - [7.5/H-1-13] ต้องรองรับความสามารถของ
LOGICAL_MULTI_CAMERA
สำหรับกล้องหลักหากมีกล้อง RGB มากกว่า 1 ตัวที่หันไปในทิศทางเดียวกัน - [7.5/H-1-14] ต้องรองรับความสามารถของ
STREAM_USE_CASE
ทั้งสำหรับกล้องหน้าและกล้องหลังหลัก
สิ้นสุดข้อกำหนดใหม่
2.2.7.3 ฮาร์ดแวร์: การปรับปรุงข้อกำหนดของคลาสประสิทธิภาพของสื่อสำหรับฮาร์ดแวร์
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาแสดงผล
android.os.Build.VERSION_CODES.T
สำหรับandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้- [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
- [7.1.1.3/H-2-1] ต้องมีความหนาแน่นของหน้าจออย่างน้อย 400 dpi
- [7.6.1/H-2-1] ต้องมีหน่วยความจำจริงอย่างน้อย 8 GB
สิ้นสุดข้อกำหนดใหม่
2.2.7.4 ประสิทธิภาพ: การอัปเดตคลาสประสิทธิภาพของสื่อสำหรับประสิทธิภาพ
ดูการแก้ไข
หากการใช้งานอุปกรณ์พกพาแสดงผล
android.os.Build.VERSION_CODES.T
สำหรับandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการดังต่อไปนี้- [8.2/H-1-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 125 MB/วินาที
- [8.2/H-1-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/วินาที
- [8.2/H-1-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 250 MB/วินาที
- [8.2/H-1-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 40 MB/วินาที
สิ้นสุดข้อกำหนดใหม่
ฮาร์ดแวร์ 2.5.1: การอัปเดตข้อกำหนดของตัวตรวจวัดความเร่งแบบ 3 แกนและเครื่องวัดการหมุน 3 แกน รวมถึงข้อกำหนดของกล้องมุมมองภายนอก
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.3.1/A-0-4] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของรถ Android
- [7.3/A-SR] STRONGLY_RECOMMENDED ให้รวมตัวตรวจวัดความเร่งแบบ 3 แกนและเครื่องวัดการหมุน 3 แกน
- [7.3/A-SR] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_HEADING
หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่ง สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/A-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.1/A-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับตัวตรวจวัดความเร่งที่มีแกนจำกัด
หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่งที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [7.3.1/A-1-3] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES
- [7.3.1/A-1-4] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
หากการใช้งานอุปกรณ์ยานยนต์รวมถึงเครื่องวัดการหมุน จะมีการดำเนินการดังนี้
- [7.3.4/A-2-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
- [7.3.4/A-2-3] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไป ได้สูงสุด 250 องศาต่อวินาที
- [7.3.4/A-SR] ขอแนะนำอย่างยิ่งให้กำหนดค่าช่วงการวัดของอุปกรณ์วัดการหมุนเป็น +/-250dps เพื่อให้ได้ความละเอียดสูงสุดที่เป็นไปได้
สิ้นสุดข้อกำหนดใหม่
หากอุปกรณ์ยานยนต์มีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/A-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับเครื่องวัดการหมุนที่จำกัดแกน
หากการใช้งานอุปกรณ์ยานยนต์มีเครื่องวัดการหมุนที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [7.3.4/A-4-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES
- [7.3.4/A-4-2] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเซ็นเซอร์
TYPE_HEADING
สิ่งที่จะเกิดขึ้นมีดังนี้- [7.3.4/A-4-3] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 1 Hz
- [7.3.4/A-SR] STRONGLY_RECOMMENDED เพื่อรายงานเหตุการณ์ด้วยความถี่อย่างน้อย 10 Hz
- ควรอ้างอิงถึงทิศเหนือจริง
- ควรพร้อมใช้งานแม้ในขณะที่ยานพาหนะยังอยู่
- ควรมีความละเอียดอย่างน้อย 1 องศา
สิ้นสุดข้อกำหนดใหม่
กล้องมุมมองภายนอกคือกล้องที่ใช้ถ่ายภาพทิวทัศน์นอกเหนือการใช้งานอุปกรณ์ เช่น กล้องมองหลัง
Dashcamหากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภายนอกสำหรับกล้องดังกล่าว สิ่งที่จะเกิดขึ้นมีดังนี้
[7.5.5/A-SR] ขอแนะนำอย่างยิ่งให้ปรับทิศทางเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับแนวเส้นขอบฟ้าควรรองรับเฟรมเวิร์กการซิงค์ข้อมูล Androidอาจมีการใช้ฮาร์ดแวร์โฟกัสอัตโนมัติหรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว และโหลดบริการระบบมุมมองภายนอก (EVS) กล้องจะทำหน้าที่ดังนี้
- [7.5/A-2-1] ต้องไม่หมุนหรือมิเรอร์ในแนวนอนของตัวอย่างกล้อง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- อาจมีกล้องอย่างน้อย 1 ตัวที่พร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม
หากการติดตั้งใช้งานอุปกรณ์ในรถยนต์มีกล้องอย่างน้อย 1 ตัว และใช้กับแอปพลิเคชันของบุคคลที่สามได้ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.5/A-3-1] ต้องรายงานแฟล็กฟีเจอร์
android.hardware.camera.any
- [7.5/A-3-2] ต้องไม่ประกาศว่ากล้องเป็นกล้องของระบบ
- อาจรองรับกล้องภายนอกที่อธิบายไว้ในหัวข้อ 7.5.3
- อาจมีฟีเจอร์ (เช่น การโฟกัสอัตโนมัติ ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
สิ้นสุดข้อกำหนดใหม่
โมเดลความปลอดภัย 2.5.5: ข้อกำหนดใหม่สำหรับสิทธิ์เข้าถึงกล้องสำหรับอุปกรณ์ยานยนต์
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศ
android.hardware.camera.any
สิ่งต่อไปนี้[9.8.2/A-2-1] ต้องแสดงสัญญาณบอกสถานะกล้องเมื่อแอป กำลังเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อแอปเข้าถึงกล้องเท่านั้น ที่มีบทบาทดังที่ระบุไว้ใน ส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X]
[9.8.2/A-2-2] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้ หรือการโต้ตอบของผู้ใช้โดยตรง
สิ้นสุดข้อกำหนดใหม่
2.6.1 ข้อกำหนดของแท็บเล็ต — ฮาร์ดแวร์: การปรับปรุงข้อกำหนดเกี่ยวกับขนาดหน้าจอของแท็บเล็ต
ดูการแก้ไข
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่โดยทั่วไปจะเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีขนาดการแสดงผลของหน้าจอใหญ่กว่า 7 นิ้ว และน้อยกว่า 18 นิ้ว โดยวัดตามเส้นทแยงมุม
ขนาดหน้าจอ
- [7.1.1.1/Tab-0-1] ต้องมีหน้าจอในช่วง 7-18 นิ้ว
3. ซอฟต์แวร์
3.2.2 พารามิเตอร์บิลด์: อัปเดตอักขระ ASCII ใน
getSerial()
แล้วดูการแก้ไข
- [C-0-1] ตารางด้านล่างระบุข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การใช้งานอุปกรณ์จะต้องสอดคล้อง เพื่อให้ได้ค่าที่มีความหมายและสอดคล้องกันตลอดการใช้งานอุปกรณ์
พารามิเตอร์ รายละเอียด getSerial() ต้อง (หรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ซึ่งต้องมีพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่ใช้ MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9]+$” 3.2.3.5 Intent แอปพลิเคชันแบบมีเงื่อนไข: การอัปเดตข้อกำหนดสำหรับ Intent แอปพลิเคชันแบบมีเงื่อนไข
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีจอแสดงผลขนาดใหญ่ (โดยทั่วไปจะมีความกว้างและความสูงของจอแสดงผลตั้งแต่ 600dp ขึ้นไป) และรองรับฟังก์ชันการแยกหน้าจอ จะมีการดำเนินการต่อไปนี้
- [C-17-1] ต้องมีกิจกรรมที่จัดการ
การตั้งค่า#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
เมื่อเปิดฟังก์ชันแยกไว้ กิจกรรมต้องได้รับการคุ้มครองโดย
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
และต้องเริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จากการตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI
สิ้นสุดข้อกำหนดใหม่
- [C-17-1] ต้องมีกิจกรรมที่จัดการ
การตั้งค่า#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
เมื่อเปิดฟังก์ชันแยกไว้ กิจกรรมต้องได้รับการคุ้มครองโดย
3.5.1 ข้อจำกัดแอปพลิเคชัน: การอัปเดตข้อจำกัดของแอปพลิเคชัน
ดูการแก้ไข
หากการใช้อุปกรณ์ใช้กลไกที่เป็นกรรมสิทธิ์เพื่อจำกัดแอป (เช่น การเปลี่ยนแปลงหรือจำกัดการทำงานของ API ที่อธิบายไว้ใน SDK) และกลไกนั้นมีข้อจำกัดมากกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ถูกจำกัด พวกเขาจะดำเนินการต่อไปนี้
- [C-1-1] ต้องอนุญาตให้ผู้ใช้เห็นรายการแอปที่ถูกจำกัด
- [C-1-2] ต้องให้เงินแก่ผู้ใช้ในการเปิด / ปิดข้อจำกัด ที่เป็นกรรมสิทธิ์ทั้งหมดเหล่านี้ในแต่ละแอป
- [C-1-3] ต้องไม่ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้โดยอัตโนมัติโดยไม่มีหลักฐานแสดงการทำงานของระบบที่ไม่ดี แต่อาจใช้ข้อจำกัดกับแอปเมื่อตรวจพบการทำงานที่ไม่มีประสิทธิภาพของระบบ เช่น การทำงานขณะล็อกที่ค้าง บริการที่ใช้เวลานาน และเกณฑ์อื่นๆ ผู้ใช้อุปกรณ์อาจกำหนดเกณฑ์นี้ได้แต่ต้องเกี่ยวข้องกับผลกระทบที่แอปมีต่อประสิทธิภาพของระบบ เกณฑ์อื่นๆ ที่ไม่เกี่ยวข้องกับประสิทธิภาพการทำงานของระบบเพียงอย่างเดียว เช่น การที่แอปได้รับความนิยมในตลาด ต้องไม่ใช้เป็นเกณฑ์
- [C-1-4] ต้องไม่ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้โดยอัตโนมัติสำหรับแอป เมื่อผู้ใช้ปิดข้อจำกัดของแอปด้วยตนเอง และอาจแนะนำให้ผู้ใช้ ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้
[C-1-5] ต้องแจ้งให้ผู้ใช้ทราบหากข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้มีผลกับแอปโดยอัตโนมัติ คุณต้องระบุข้อมูลดังกล่าวในช่วง 24 ชั่วโมงก่อนการใช้ข้อจำกัดในกรรมสิทธิ์เหล่านี้
[C-1-6] ต้องแสดงผลเป็น "จริง" สำหรับเมธอด ActivityManager.isBackgroundRestricted() สำหรับการเรียก API จากแอป
[C-1-7] ต้องไม่จำกัดแอปที่ทำงานอยู่เบื้องหน้าด้านบนที่ผู้ใช้ ใช้งานอย่างชัดเจน
[C-1-8] ต้องระงับข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้ในแอปทุกครั้งที่ผู้ใช้เริ่มใช้แอปอย่างชัดแจ้ง ทำให้เป็นแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
[C-1-9] ต้องรายงานเหตุการณ์เกี่ยวกับข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้ทั้งหมดผ่านUsageStats
[C-1-10] ต้องแสดงเอกสารหรือเว็บไซต์สาธารณะและชัดเจนที่อธิบาย วิธีใช้ข้อจำกัดที่เป็นกรรมสิทธิ์ เอกสารหรือเว็บไซต์นี้จะต้องลิงก์ได้จากเอกสาร Android SDK และต้องมีข้อมูลต่อไปนี้
- เงื่อนไขการทริกเกอร์สำหรับข้อจำกัดที่เป็นกรรมสิทธิ์
- วิธีจำกัดแอปและวิธีจำกัด
- วิธียกเว้นแอปจากข้อจำกัดดังกล่าว
- แอปจะขอยกเว้นจากข้อจำกัดที่เป็นกรรมสิทธิ์ได้อย่างไร หากแอปรองรับการยกเว้นดังกล่าวสำหรับแอปที่ผู้ใช้ติดตั้งได้
หากมีการติดตั้งแอปไว้ล่วงหน้าในอุปกรณ์และผู้ใช้ไม่เคยใช้งานอย่างชัดแจ้งเกิน 30 วัน ระบบจะยกเว้น [C-1-3] [C-1-5]
สิ้นสุดข้อกำหนดใหม่
3.8.1 Launcher (หน้าจอหลัก): การอัปเดตการรองรับสำหรับ
monochrome/adaptive-icon
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับไอคอนโมโนโครม ไอคอนเหล่านี้
- [C-6-1] ต้องใช้เฉพาะเมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง (เช่น ผ่านเมนูการตั้งค่าหรือตัวเลือกวอลเปเปอร์)
สิ้นสุดข้อกำหนดใหม่
3.8.2 วิดเจ็ต: การอัปเดตการแสดงวิดเจ็ตแอปของบุคคลที่สามใน Launcher
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สาม วิดเจ็ตจะดำเนินการดังนี้
- [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและแสดงความสามารถของอินเทอร์เฟซผู้ใช้ในการเพิ่ม กำหนดค่า ดู และนำ AppWidgets ออก
ภายใน Launcher โดยตรง
- [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและแสดงความสามารถของอินเทอร์เฟซผู้ใช้ในการเพิ่ม กำหนดค่า ดู และนำ AppWidgets ออก
3.8.3.1 การนำเสนอการแจ้งเตือน: อธิบายคำจำกัดความของการแจ้งเตือนล่วงหน้า
ดูการแก้ไข
การแจ้งเตือนล่วงหน้าคือการแจ้งเตือนที่แสดงแก่ผู้ใช้เมื่อผู้ใช้เข้ามาโดยไม่ขึ้นอยู่กับแพลตฟอร์มที่ผู้ใช้เปิดอยู่
3.8.3.3 DND (ห้ามรบกวน) / โหมดลำดับความสำคัญ: อัปเดตเพื่อรวมข้อกำหนดของโหมดลำดับความสำคัญใน DND (ห้ามรบกวน)
ดูการแก้ไข
3.8.3.3 DND (ห้ามรบกวน) / โหมดลำดับความสำคัญ
หากการใช้งานอุปกรณ์รองรับฟีเจอร์ DND (หรือที่เรียกว่าโหมดลำดับความสำคัญ) ระบบจะดำเนินการดังต่อไปนี้
3.8.6 ธีม: ข้อกำหนดใหม่สำหรับชุดโทนสีไดนามิก
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
[C-1-4] ต้องสร้างชุดโทนสีไดนามิกตามที่ระบุในเอกสารประกอบ AOSP ของ
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(ดูandroid.theme.customization.system_palette
และandroid.theme.customization.theme_style
)[C-1-5] ต้องสร้างชุดโทนสีแบบไดนามิกโดยใช้รูปแบบธีมสี ตามที่ระบุไว้ในเอกสารประกอบ
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(ดูandroid.theme.customization.theme_styles
) ได้แก่TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
FRUIT_SALAD
ใช้ "สีต้นฉบับ" ในการสร้างชุดสีโทนแบบไดนามิกเมื่อส่งด้วย
android.theme.customization.system_palette
(ตามที่ระบุไว้ในเอกสารSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
)[C-1-6] ต้องมีค่าความคมชัด
CAM16
เท่ากับ 5 ขึ้นไปควรได้มาจากวอลเปเปอร์ผ่าน
com.android.systemui.monet.ColorScheme#getSeedColors
ซึ่งมีสีแหล่งที่มาที่ถูกต้องหลายสีให้เลือกควรใช้ค่า
0xFF1B6EF3
หากไม่มีสีที่ระบุเป็นไปตามข้อกำหนดสีแหล่งที่มาข้างต้น
สิ้นสุดข้อกำหนดใหม่
3.8.17 คลิปบอร์ด: เพิ่มส่วนข้อกำหนดใหม่สำหรับเนื้อหาในคลิปบอร์ด
ดูการแก้ไข
3.8.17 คลิปบอร์ด
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่ส่งข้อมูลคลิปบอร์ดไปยังคอมโพเนนต์ กิจกรรม บริการ หรือ ผ่านการเชื่อมต่อเครือข่ายใดๆ โดยไม่มีการดำเนินการอย่างชัดแจ้งของผู้ใช้ (เช่น การกดปุ่มบนการวางซ้อน) ยกเว้นบริการที่กล่าวถึงใน 9.8.6 Content Capture และ App Search
หากการนำอุปกรณ์ไปใช้งานสร้างการแสดงตัวอย่างที่ผู้ใช้มองเห็นได้เมื่อคัดลอกเนื้อหา ไปยังคลิปบอร์ดสำหรับรายการใน
ClipData
ที่ClipData.getDescription().getExtras()
มีandroid.content.extra.IS_SENSITIVE
อยู่ด้วย สิ่งที่จะเกิดขึ้นมีดังนี้- [C-1-1] ต้องปกปิดตัวอย่างที่ผู้ใช้เห็นได้
การใช้ข้อมูลอ้างอิง AOSP เป็นไปตามข้อกำหนดของคลิปบอร์ดเหล่านี้
สิ้นสุดข้อกำหนดใหม่
3.9.1.1 การจัดสรรเจ้าของอุปกรณ์: การอัปเดตข้อกำหนดการจัดสรรเจ้าของอุปกรณ์
ดูการแก้ไข
การใช้งานอุปกรณ์จะประกาศ
android.software.device_admin
ดังต่อไปนี้- [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์ Device Policy (DPC) เป็น
แอปเจ้าของอุปกรณ์
ตามที่อธิบายไว้ด้านล่าง
- เมื่อการใช้งานอุปกรณ์ไม่ได้กำหนดค่า ผู้ใช้และ
ข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์
หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะ
เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์
หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่าน
แฟล็กฟีเจอร์
android.hardware.nfc
และได้รับข้อความ NFC ที่มีระเบียนประเภท MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-8] ต้องส่งคำสั่ง ACTION_GET_PROVISIONING_mode
หลังจากระบบเรียกใช้การจัดสรรเจ้าของอุปกรณ์ เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ขึ้นอยู่กับค่าของ
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
เว้นแต่ว่าจะระบุจากบริบทว่ามีตัวเลือกที่ถูกต้องเพียงตัวเลือกเดียว(เช่น การจัดสรรแบบ NFC ซึ่งไม่รองรับการจัดสรรเจ้าของโปรไฟล์) - [C-1-9] ต้องส่ง ACTION_ADMIN_POLICY_COMPLIANCE ไปยังแอปเจ้าของอุปกรณ์ หากมีการสร้างเจ้าของอุปกรณ์ ในระหว่างการจัดสรร ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าแอปเจ้าของอุปกรณ์จะทำงานเสร็จ
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์
หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะ
เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์
หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่าน
แฟล็กฟีเจอร์
- เมื่อติดตั้งอุปกรณ์มีข้อมูลผู้ใช้
ผู้ใช้หรือ
ข้อมูล จะดำเนินการดังนี้
- [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป
- เมื่อการใช้งานอุปกรณ์ไม่ได้กำหนดค่า ผู้ใช้และ
ข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-2] ต้องแสดงประกาศการเปิดเผยข้อมูลที่เหมาะสม (เช่น ดังที่อ้างถึงใน AOSP) และได้รับความยินยอมจากผู้ใช้ปลายทางก่อนที่แอปจะตั้งค่าเป็นเจ้าของอุปกรณ์ เว้นแต่อุปกรณ์จะได้รับการกำหนดค่าสำหรับโหมดสาธิตสำหรับร้านค้าปลีกก่อนการโต้ตอบของผู้ใช้บนหน้าจอ
ต้องมีการดำเนินการยืนยันก่อนหรือระหว่างขั้นตอนการตั้งค่าอุปกรณ์ ความยินยอมอาจผ่านการดำเนินการของผู้ใช้หรือวิธีการแบบเป็นโปรแกรมบางอย่างก็ได้ แต่ต้องแสดงประกาศการเปิดเผยข้อมูลที่เหมาะสม (ตามที่อ้างอิงใน AOSP) ก่อนเริ่มการจัดสรรเจ้าของอุปกรณ์ นอกจากนี้ กลไกความยินยอมของเจ้าของอุปกรณ์แบบเป็นโปรแกรมที่ใช้ (โดยองค์กร) สำหรับการจัดสรรเจ้าของอุปกรณ์ต้องไม่แทรกแซงประสบการณ์การใช้งานนอกกล่องสำหรับการใช้งานในองค์กร [C-1-3] ต้องไม่ฮาร์ดโค้ดความยินยอมหรือป้องกันไม่ให้มีการใช้แอปอื่นๆ ของเจ้าของอุปกรณ์
หากการใช้อุปกรณ์ประกาศ
android.software.device_admin
แต่ยังรวมโซลูชันการจัดการอุปกรณ์เจ้าของอุปกรณ์ที่เป็นกรรมสิทธิ์ด้วย และให้กลไกในการโปรโมตแอปพลิเคชันที่กำหนดค่าในโซลูชันของตนเป็น "เทียบเท่ากับเจ้าของอุปกรณ์" กับ "เจ้าของอุปกรณ์" มาตรฐานตามที่ Android DevicePolicyManager API มาตรฐานรู้จัก จะมีการดำเนินการต่อไปนี้- [C-2-1] ต้องมีขั้นตอนยืนยันว่าแอปที่โปรโมต เป็นโซลูชันการจัดการอุปกรณ์ขององค์กรที่ถูกต้อง และได้รับการกำหนดค่าในโซลูชันที่เป็นกรรมสิทธิ์ ให้มีสิทธิ์เทียบเท่ากับ "เจ้าของอุปกรณ์"
- [C-2-2] ต้องแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับขั้นตอนที่
android.app.action.PROVISION_MANAGED_DEVICE
เริ่มต้นก่อนที่จะลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์" - [C-2-3] ต้องไม่ฮาร์ดโค้ดความยินยอมหรือป้องกันการใช้แอปอื่นๆ ของเจ้าของอุปกรณ์
อาจมีข้อมูลผู้ใช้อยู่ในอุปกรณ์ก่อนที่จะลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์"
- [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์ Device Policy (DPC) เป็น
แอปเจ้าของอุปกรณ์
ตามที่อธิบายไว้ด้านล่าง
3.9.4 ข้อกำหนดของบทบาทในการจัดการอุปกรณ์: เพิ่มส่วนสำหรับข้อกำหนดของบทบาทในการจัดการอุปกรณ์
ดูการแก้ไข
3.9.4 ข้อกำหนดของบทบาทการจัดการนโยบายด้านอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์รายงาน
android.software.device_admin
หรือandroid.software.managed_users
ระบบจะดำเนินการต่อไปนี้- [C-1-1] ต้องรองรับบทบาทการจัดการนโยบายด้านอุปกรณ์ตามที่ระบุไว้ในส่วนที่ 9.1 แอปพลิเคชันที่มีบทบาทการจัดการนโยบายด้านอุปกรณ์อาจกำหนดไว้โดยการตั้งค่า
config_devicePolicyManagement
เป็นชื่อแพ็กเกจ ชื่อแพ็กเกจต้องตามด้วย:
และใบรับรองที่ลงนาม เว้นแต่มีการโหลดแอปพลิเคชันไว้ล่วงหน้า
หากไม่ได้กำหนดชื่อแพ็กเกจสำหรับ
config_devicePolicyManagement
ตามที่อธิบายไว้ข้างต้น- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการจัดสรรโดยไม่มีแอปพลิเคชันผู้ถือบทบาทการจัดการนโยบายด้านอุปกรณ์ (AOSP มีการใช้งานข้อมูลอ้างอิง)
หากมีการกำหนดชื่อแพ็กเกจสำหรับ
config_devicePolicyManagement
ตามที่อธิบายไว้ข้างต้น- [C-3-1] ต้องติดตั้งแอปพลิเคชันใน โปรไฟล์ ทั้งหมดสำหรับผู้ใช้
- [C-3-2] การใช้งานอุปกรณ์อาจกำหนดแอปพลิเคชันที่อัปเดตเจ้าของบทบาทการจัดการนโยบายด้านอุปกรณ์ก่อนการจัดสรรโดยการตั้งค่า
config_devicePolicyManagementUpdater
หากมีการกำหนดชื่อแพ็กเกจสำหรับ
config_devicePolicyManagementUpdater
ตามที่อธิบายไว้ข้างต้น- [C-4-1] อุปกรณ์ต้องติดตั้งแอปพลิเคชันไว้ล่วงหน้า
- [C-4-2] แอปพลิเคชันต้องใช้ตัวกรอง Intent ซึ่งแก้ไข
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
สิ้นสุดข้อกำหนดใหม่
- [C-1-1] ต้องรองรับบทบาทการจัดการนโยบายด้านอุปกรณ์ตามที่ระบุไว้ในส่วนที่ 9.1 แอปพลิเคชันที่มีบทบาทการจัดการนโยบายด้านอุปกรณ์อาจกำหนดไว้โดยการตั้งค่า
3.18 รายชื่อติดต่อ: การเพิ่ม ข้อมูลสำหรับรายชื่อติดต่อใหม่
ดูการแก้ไข
บัญชีเริ่มต้นสำหรับรายชื่อติดต่อใหม่: Contacts Provider มี API สำหรับจัดการการตั้งค่าของบัญชีเริ่มต้นเมื่อสร้างรายชื่อติดต่อใหม่
หากอุปกรณ์ติดตั้งใช้งานแอปรายชื่อติดต่อไว้ล่วงหน้า แอปรายชื่อติดต่อที่โหลดไว้ล่วงหน้า จะดำเนินการต่อไปนี้
[C-2-1] ต้องจัดการ Intent
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
เพื่อเปิดใช้ UI สำหรับการเลือกบัญชี และบันทึกการตั้งค่าไปยัง Contacts Provider เมื่อมีการเลือกบัญชี[C-2-2] ต้องใช้การตั้งค่าบัญชีเริ่มต้นเมื่อจัดการ
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
สำหรับContactsContracts.Contacts.CONTENT_TYPE
และContactsContract.RawContacts.CONTENT_TYPE
โดยเลือกบัญชีในตอนแรก
สิ้นสุดข้อกำหนดใหม่
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
4. ความเข้ากันได้กับแพ็กเกจแอปพลิเคชัน: การอัปเดตเป็นเวอร์ชัน APK Signature Scheme
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์
[C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v3.1 , APK Signature Scheme v3, APK Signature Scheme v2 และ JAR Signing
[C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4 และ APK Signature Scheme v4.1
5. ความเข้ากันได้กับมัลติมีเดีย
การถอดรหัสเสียง 5.1.2: เพิ่มข้อกำหนดใหม่สำหรับตัวถอดรหัสที่สามารถส่งออกเสียงหลายช่องสัญญาณ
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมแบบหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านตัวถอดรหัสเสียง AAC เริ่มต้นใน
android.media.MediaCodec
API ต้องมีการรองรับรายการต่อไปนี้- [C-7-1] ต้องสามารถกำหนดค่าโดยแอปพลิเคชันโดยใช้การถอดรหัสด้วยคีย์
KEY_MAX_OUTPUT_CHANNEL_COUNT
เพื่อควบคุมว่าจะให้เนื้อหาดาวน์มิกซ์เป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือเอาต์พุตโดยใช้จำนวนช่องเสียงดั้งเดิม (เมื่อใช้ค่าที่เท่ากับหรือมากกว่าตัวเลขดังกล่าว) เช่น ค่า 6 ขึ้นไปจะกำหนดค่าตัวถอดรหัสให้เอาต์พุต 6 ช่องสัญญาณเมื่อป้อนเนื้อหา 5.1 - [C-7-2] เมื่อถอดรหัส ตัวถอดรหัสต้องโฆษณามาสก์ช่องทางที่ใช้ในรูปแบบเอาต์พุตด้วยคีย์
KEY_CHANNEL_MASK
โดยใช้ค่าคงที่android.media.AudioFormat
(เช่นCHANNEL_OUT_5POINT1
)
หากการใช้งานอุปกรณ์รองรับตัวถอดรหัสเสียงอื่นที่ไม่ใช่ตัวถอดรหัสเสียง AAC ที่เป็นค่าเริ่มต้นและสามารถเอาต์พุตเสียงแบบหลายช่องได้ (มากกว่า 2 ช่อง) เมื่อป้อนเนื้อหาแบบหลายช่องที่มีการบีบอัดแล้ว ให้ทำดังนี้
- [C-SR] เราขอแนะนำเป็นอย่างยิ่งให้แอปพลิเคชันกำหนดค่าตัวถอดรหัสได้โดยใช้การถอดรหัสด้วยคีย์
KEY_MAX_OUTPUT_CHANNEL_COUNT
เพื่อควบคุมว่าจะให้เนื้อหาดาวน์มิกซ์เป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือเอาต์พุตโดยใช้จำนวนช่องเสียงดั้งเดิม (เมื่อใช้ค่าที่เท่ากับหรือมากกว่าตัวเลขดังกล่าว) เช่น ค่า 6 ขึ้นไปจะกำหนดค่าตัวถอดรหัสให้เอาต์พุต 6 ช่องสัญญาณเมื่อป้อนเนื้อหา 5.1 - [C-SR] เมื่อถอดรหัส ขอแนะนำอย่างยิ่งให้ใช้ตัวถอดรหัสเพื่อโฆษณามาสก์ช่องทางที่ใช้ในรูปแบบเอาต์พุตด้วยคีย์
KEY_CHANNEL_MASK
โดยใช้ค่าคงที่ android.media.AudioFormat (เช่นCHANNEL_OUT_5POINT1
)
สิ้นสุดข้อกำหนดใหม่
- [C-7-1] ต้องสามารถกำหนดค่าโดยแอปพลิเคชันโดยใช้การถอดรหัสด้วยคีย์
5.4.1 การบันทึกเสียงดิบและข้อมูลไมโครโฟน: การอัปเดตแหล่งที่มาของเสียงที่รองรับสำหรับสตรีมอินพุตเสียง
ดูการแก้ไข
การใช้งานอุปกรณ์จะประกาศ
android.hardware.microphone
ดังต่อไปนี้[C-1-1] ต้องอนุญาตการบันทึกเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้ สำหรับสตรีม
AudioRecord
หรือAAudio
INPUT ที่เปิดได้สำเร็จ อย่างน้อยที่สุด ต้องรองรับฟีเจอร์ต่อไปนี้- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
- ช่องสัญญาณ: โมโน
- แหล่งที่มาของเสียง:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
หรือVOICE_PERFORMANCE
นอกจากนี้ยังมีผลกับค่าที่กำหนดล่วงหน้าซึ่งเทียบเท่ากับอินพุตในAAudio
ด้วย เช่นAAUDIO_INPUT_PRESET_CAMCORDER
- [C-1-4] ต้องใช้
MicrophoneInfo
API และกรอกข้อมูลอย่างเหมาะสมสำหรับไมโครโฟนที่พร้อมใช้งานบนอุปกรณ์ ที่แอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านAudioManager.getMicrophones()
API สำหรับ AudioRecord ที่ใช้งานอยู่โดยใช้MediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
หรือVOICE_PERFORMANCE
และไมโครโฟนที่ใช้งานอยู่ในปัจจุบัน ซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน APIAudioRecord.getActiveMicrophones()
และMediaRecorder.getActiveMicrophones()
5.4.2 การบันทึกสำหรับการจดจำเสียง: ข้อกำหนดที่อัปเดตสำหรับสตรีมเสียงสำหรับการจดจำเสียงและข้อกำหนดเพิ่มเติม สำหรับระดับการรับเสียงไมโครโฟน
ดูการแก้ไข
การใช้งานอุปกรณ์จะประกาศ
android.hardware.microphone
ดังต่อไปนี้- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีคุณลักษณะแอมพลิจูดแบบแบนราบเมื่อเทียบกับความถี่โดยประมาณ ±3 dB ตั้งแต่ 100 Hz ถึง 4000 Hz
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงด้วยการตั้งค่าความไวต่ออินพุต เพื่อให้แหล่งพลังงานเสียง (SPL) 90 dB ที่ 1000 Hz ให้ค่า RMS 2500 สำหรับตัวอย่าง 16 บิต
- ควรแสดงคุณสมบัติแอมพลิจูดความถี่ราบโดยประมาณในช่วงความถี่กลางๆ โดยเฉพาะ ±3dB ตั้งแต่ 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัว และทุกไมโครโฟนที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 30 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
สิ้นสุดข้อกำหนดใหม่
5.4.6 ระดับการเพิ่มขึ้นของไมโครโฟน: ย้ายข้อกำหนดสำหรับระดับการรับไมโครโฟนไปยังส่วน 5.4.2
ดูการแก้ไข
5.4.6 ระดับการรับเสียงของไมโครโฟน [ย้ายไปที่ 5.4.2]
การใช้งานอุปกรณ์จะประกาศ
android.hardware.microphone
ดังต่อไปนี้- ควรแสดงลักษณะเฉพาะของแอมพลิจูดกับความถี่แบบแบนราบโดยประมาณในช่วงความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวและทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนแต่ละตัวและไมโครโฟนที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- ควรตั้งค่าความไวของอินพุตเสียงให้แหล่งสัญญาณเสียงไซนัสอยัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB ตอบสนองด้วย RMS ที่ 2500 สำหรับตัวอย่างเสียง 16 บิต (หรือ -22.35 dB สำหรับสเกลเสียงลอยตัว/คู่) เพื่อการบันทึกเสียงทุกตัวอย่างที่ใช้เพื่อความแม่นยำในการจดจำเสียงทุกตัว
5.5.4 การลดเสียง: การอัปเดตข้อกำหนดในการเล่นการลดเสียง
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับการเล่นเสียงแบบออฟโหลด ระบบจะดำเนินการต่อไปนี้
- [C-SR] ขอแนะนำอย่างยิ่งให้ตัดเนื้อหาเสียงที่เล่นแบบไม่ขาดตอน ระหว่าง 2 คลิปที่มีรูปแบบเดียวกัน เมื่อระบุโดย AudioTrack gapless API และคอนเทนเนอร์สื่อสำหรับ MediaPlayer
5.6 เวลาในการตอบสนองของเสียง: การอัปเดตข้อกำหนดด้านเวลาในการตอบสนองของเสียง
ดูการแก้ไข
สำหรับวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้
- Jitter เอาต์พุต Cold ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองเอาต์พุตเย็น
- ความแปรปรวนของเวลาในการตอบสนองแบบ Cold Input ความแปรปรวนของการวัดที่แยกกันสำหรับค่าเวลาในการตอบสนองของการป้อนข้อมูลอัตโนมัติ
หากการใช้งานอุปกรณ์ประกาศ
android.hardware.audio.output
อุปกรณ์จะต้องเป็นไปตามข้อกําหนดหรือเกินข้อกําหนดต่อไปนี้- [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบเย็นไม่เกิน 500 มิลลิวินาที
- [C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้
AAudioStreamBuilder_openStream()
ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที
หากการใช้งานอุปกรณ์ประกาศว่า
android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามหรือเกินข้อกำหนดต่อไปนี้- [C-SR] เวลาในการตอบสนองเอาต์พุตแบบ Cold 100 มิลลิวินาทีหรือน้อยกว่าในเส้นทางข้อมูลของลำโพง
เราขอแนะนำอุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้อย่างมากให้เป็นไปตามข้อกำหนดเหล่านี้ตั้งแต่ตอนนี้ สำหรับแพลตฟอร์มที่เปิดตัวในอนาคต เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่านั้น เนื่องจากต้อง [C-SR] ลด Jitter เอาต์พุต Cold
หากใช้อุปกรณ์รวมถึง
android.hardware.microphone
อุปกรณ์จะต้องเป็นไปตามข้อกำหนดเกี่ยวกับอินพุตเสียงต่อไปนี้- [C-3-2] เวลาในการตอบสนองอินพุตแบบเย็นไม่เกิน 500 มิลลิวินาที
- [C-3-3] การเปิดสตรีมอินพุตโดยใช้
AAudioStreamBuilder_openStream()
ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที
หากการใช้งานอุปกรณ์รวม
android.hardware.microphone
ด้วย เราขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดของอินพุตเสียงเหล่านี้- [C-SR] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาทีในเส้นทางข้อมูลไมโครโฟน
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ทันที สำหรับแพลตฟอร์มรุ่นถัดไป เราจะกำหนดเวลาในการตอบสนองของอินพุต Cold ไม่เกิน 200 มิลลิวินาที เนื่องจาก "ต้อง"
- [C-SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
- [C-SR] ลดเสียงรบกวนของอินพุต Cold
5.10 เสียงระดับมืออาชีพ: การปรับปรุงข้อกำหนดด้านเวลาในการตอบสนองของเสียงสำหรับการสนับสนุนด้านเสียงแบบมืออาชีพ
ดูการแก้ไข
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์
android.hardware.audio.pro
ผ่านคลาส android.content.pm.PackageManager การดำเนินการดังกล่าวจะมีผลดังนี้- [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ไม่เกิน 25 มิลลิวินาที
และควรไม่เกิน 10 มิลลิวินาทีสำหรับเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง - [C-1-5] ต้องเป็นไปตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียงทาง USB โดยใช้
AAudio Native Audio
API และ
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
- [C-1-8] ต้องมีเวลาในการตอบสนอง "แตะเพื่อโทนเสียง" โดยเฉลี่ย ไม่เกิน 80 มิลลิวินาที สำหรับการวัดอย่างน้อย 5 ค่าผ่านเส้นทางการส่งข้อมูลของลำโพงสู่ไมโครโฟน
- [C-SR] แนะนำอย่างยิ่งให้มอบประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและโหลดของ CPU จะแตกต่างกันไป ซึ่งควรทดสอบโดยใช้แอป Android SynthMark SynthMark ใช้ซอฟต์แวร์สังเคราะห์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองที่วัดประสิทธิภาพของระบบ ดูคำอธิบายการเปรียบเทียบได้ในเอกสารประกอบของ SynthMark แอป SynthMark ต้องเรียกใช้โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้ * audiomark.90 >= 32 Voices *เวลาในการตอบสนองmark.fixed.little <= 15 msec * delaymark.dynamic.little <= 50 msec
ควรมีเวลาในการตอบสนองจากการป้อนข้อมูลด้วยการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 40 มิลลิวินาที
หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว จะมีผลดังนี้
- [C-2-1] ต้องมีค่าเฉลี่ยเวลาในการตอบสนองของเสียงไป-กลับแบบต่อเนื่องตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ไม่เกิน 20 มิลลิวินาที มากกว่า 5 ค่าเบี่ยงเบนเฉลี่ยที่มีค่าเบี่ยงเบนเฉลี่ยต่ำกว่า 5 มิลลิวินาทีในเส้นทางช่องเสียบเสียงโดยใช้ดองเกิลการวนกลับของเสียง
- [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ไม่เกิน 25 มิลลิวินาที
วิดีโอ HDR 5.12: เพิ่มส่วนใหม่สำหรับข้อกำหนดของวิดีโอ HDR
6. เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์: การอัปเดตเกี่ยวกับการเชื่อมต่อและข้อกำหนดของเคอร์เนล GPU
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องมีเมธอด
AdbManager#isAdbWifiSupported()
ที่แสดงtrue
หากการติดตั้งอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต และมีกล้องอย่างน้อย 1 ตัว
- [C-5-1] ต้องมีเมธอด
AdbManager#isAdbWifiQrSupported()
ที่แสดงผลtrue
ข้อมูลการทำงานของ GPU
การติดตั้งใช้งานอุปกรณ์
- [C-6-1] ต้องใช้คำสั่ง Shell
dumpsys gpu --gpuwork
เพื่อแสดงข้อมูลงานของ GPU แบบรวมที่ส่งคืนโดยจุดการติดตามของเคอร์เนลpower/gpu_work_period
หรือไม่แสดงข้อมูลใดๆ หากระบบไม่รองรับ Tracepoint ดังกล่าว การติดตั้งใช้งาน AOSP คือframeworks/native/services/gpuservice/gpuwork/
- [C-6-1] ต้องใช้คำสั่ง Shell
สิ้นสุดข้อกำหนดใหม่
- [C-4-1] ต้องมีเมธอด
7. ความเข้ากันได้ของฮาร์ดแวร์
7.1.4.1 OpenGL ES: การอัปเดตส่วนขยายที่แนะนำ
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดก็ตาม ก็จะเป็นดังนี้
- รองรับส่วนขยาย
EGL_IMG_context_priority
และEGL_EXT_protected_content
สิ้นสุดข้อกำหนดใหม่
- รองรับส่วนขยาย
7.1.4.2 Vulkan: การอัปเดตเวอร์ชันที่รองรับสำหรับ Vulkan
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำงานดังนี้
- [SR] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
Vulkan 1.1 - ต้องไม่รองรับเวอร์ชัน Vulkan Variant (เช่น ส่วนตัวแปรของเวอร์ชันหลักของ Vulkan ต้องเป็น 0)
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [SR] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
Vulkan 1.1
หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.0 ขึ้นไป ระบบจะดำเนินการดังต่อไปนี้
- ควรรองรับ
VkPhysicalDeviceProtectedMemoryFeatures
และVK_EXT_global_priority
- [C-1-12] ต้องไม่แจกแจงการรองรับส่วนขยาย
VK_KHR_performance_query
- [C-SR] ได้รับการแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดที่ระบุโดยโปรไฟล์ Android Baseline 2021
- [SR] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์
- [C-SR] ขอแนะนำอย่างยิ่งให้เสนอฟังก์ชันการนำทางทั้งหมดเป็นแบบยกเลิกได้ "ยกเลิกได้" หมายถึงความสามารถของผู้ใช้ในการป้องกันไม่ให้ฟังก์ชันการนำทางทำงาน (เช่น กลับบ้าน ย้อนกลับ ฯลฯ) หากไม่ได้ปล่อยการปัดผ่านเกณฑ์ที่กำหนด
สิ้นสุดข้อกำหนดใหม่
หากมีฟังก์ชันการนำทางกลับ และผู้ใช้ยกเลิกท่าทางสัมผัสกลับแล้ว ให้ทำดังนี้
- [C-8-1] ต้องโทรหา
OnBackInvokedCallback.onBackCancelled()
- [C-8-2] ต้องไม่โทรหา
OnBackInvokedCallback.onBackInvoked()
- [C-8-3] ต้องไม่ส่งเหตุการณ์ KEYCODE_BACK
หากมีฟังก์ชันการนำทางกลับ แต่แอปพลิเคชันเบื้องหน้าไม่มีการลงทะเบียน
OnBackInvokedCallback
ให้ทำดังนี้- ระบบควรมีภาพเคลื่อนไหวสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าซึ่งแนะนำให้ผู้ใช้ย้อนกลับตามที่ระบุใน AOSP
หากการนำอุปกรณ์ไปใช้งานรองรับ API ของระบบ
setNavBarMode
เพื่ออนุญาตให้แอประบบที่มีสิทธิ์android.permission.STATUS_BAR
ตั้งค่าโหมดแถบนำทาง ระบบจะดำเนินการดังต่อไปนี้- [C-9-1] ต้องรองรับไอคอนที่เหมาะสำหรับเด็กหรือการนำทางโดยใช้ปุ่ม ตามที่ระบุไว้ในโค้ด AOSP
สิ้นสุดข้อกำหนดใหม่
7.3.1 ตัวตรวจวัดความเร่ง: การอัปเดตข้อกำหนดของเซ็นเซอร์สำหรับตัวตรวจวัดความเร่ง
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีตัวตรวจวัดความเร่ง
ตัวตรวจวัดความเร่งแบบ 3 แกนอุปกรณ์จะดำเนินการดังนี้[C-1-2] ต้องใช้และรายงานเซ็นเซอร์TYPE_ACCELEROMETER
[SR] แนะนำอย่างยิ่งให้ใช้TYPE_SIGNIFICANT_MOTION
เซ็นเซอร์คอมโพสิต- เราแนะนำ
[SR] อย่างยิ่งให้ใช้และรายงานเซ็นเซอร์TYPE_ACCELEROMETER_UNCALIBRATED
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android เพื่อให้เป็นไปตามข้อกำหนดดังกล่าว เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจกำหนดให้จำเป็น ควรใช้TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
คอมโพสิตเซ็นเซอร์ ตามที่อธิบายไว้ในเอกสาร Android SDK
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_SIGNIFICANT_MOTION
- [C-SR] แนะนำอย่างยิ่งให้ใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_UNCALIBRATED
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android เพื่อให้เป็นไปตามข้อกำหนดดังกล่าว เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจเป็น "จำเป็น" - ควรใช้เซ็นเซอร์คอมโพสิต
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
ตามที่อธิบายไว้ในเอกสาร Android SDK
หากติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [C-3-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES
- [C-SR] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
สิ้นสุดข้อกำหนดใหม่
หากการใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์ผสม
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
และTYPE_STEP_COUNTER
จะมีผลดังนี้- [C-4-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุน 3 แกน ระบบจะดำเนินการต่อไปนี้
- [C-5-1] ต้องใช้
เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์ไจโรสโคปแบบ 3 แกน และเซ็นเซอร์แมกนิโตมิเตอร์ อุปกรณ์เหล่านี้จะมีผลดังนี้
- [C-6-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
7.3.4 เครื่องวัดการหมุน: การอัปเดต ข้อกำหนดของเซ็นเซอร์สำหรับเครื่องวัดการหมุน
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุน ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
- [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป
- [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
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้เกิดข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
- [C-SR] ขอแนะนำอย่างยิ่งให้มีความละเอียด 16 บิตขึ้นไป
- ควรรายงานเหตุการณ์สูงสุด 200 Hz
สิ้นสุดข้อกำหนดใหม่
หากการใช้งานอุปกรณ์รวมถึงเครื่องวัดการหมุน 3 แกน ระบบจะดำเนินการดังต่อไปนี้
- [C-2-1] ต้องใช้
เซ็นเซอร์
TYPE_GYROSCOPE
หากอุปกรณ์มีเครื่องวัดการหมุนที่มีน้อยกว่า 3 แกน ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้และรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES
- [C-SR] STRONGLY_RECOMMENDED ติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
สิ้นสุดข้อกำหนดใหม่
หากอุปกรณ์มีเครื่องวัดการหมุน 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-5-1] ต้องใช้
เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
7.3.10 เซ็นเซอร์ไบโอเมตริก: การอัปเดตข้อกำหนดของเซ็นเซอร์สำหรับเซ็นเซอร์ไบโอเมตริก
ดูการแก้ไข
เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 3 (เดิมชื่อรัดกุม), คลาส 2 (เดิมชื่อต่ำ) หรือคลาส 1 (เดิมเรียกว่าความสะดวกสบาย) โดยอิงตามอัตราการยอมรับการปลอมแปลงและตัวปลอม รวมถึงความปลอดภัยของไปป์ไลน์ข้อมูลไบโอเมตริก การแยกประเภทนี้จะดูความสามารถที่เซ็นเซอร์ไบโอเมตริกมีในการเชื่อมต่อกับแพลตฟอร์มและกับแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์ต้องมีคุณสมบัติตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่าง หากต้องการจัดประเภทเป็นระดับ 1 ระดับ 2 หรือระดับ 3
เซ็นเซอร์จะได้รับการจัดประเภทเป็นคลาส 1 โดยค่าเริ่มต้น และต้องมีคุณสมบัติตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่างหากต้องการจัดประเภทเป็นคลาส 2 หรือคลาส 3 ข้อมูลไบโอเมตริกทั้งคลาส 2 และคลาส 3 มีความสามารถเพิ่มเติมตามรายละเอียดด้านล่างหากการใช้งานอุปกรณ์ต้องการให้เซ็นเซอร์ข้อมูลไบโอเมตริกเป็นคลาส 1 (เดิมชื่อความสะดวก) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 30% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีการนำเสนอ (PAI) ระดับ A ไม่เกิน 30% และ (2) อัตราการยอมรับโปรโตคอลที่แปลงและไม่เป็นจริงของสปีชีส์ระดับ BAI ไม่เกิน 40% เนื่องจากการทดสอบโปรโตคอลระดับ BAI ต่ำกว่า 40%
สิ้นสุดข้อกำหนดใหม่
หากการใช้งานอุปกรณ์ต้องการจัดการเซ็นเซอร์ไบโอเมตริกเป็นคลาส 2 (เดิมชื่อไม่รัดกุม) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 20% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับของผู้แอบอ้างสำหรับสปีชีส์ประเภทเครื่องมือโจมตีการนำเสนอ (PAI) ระดับ A ไม่สูงกว่า 20% และ (2) อัตราการยอมรับโปรโตคอลที่หลอกและหลอกลวงของสปีชีส์ระดับ B PAI โดยทดสอบโดย โปรโตคอลไบโอเมตริกระดับ B,
หากการใช้งานอุปกรณ์ต้องการให้เซ็นเซอร์ข้อมูลไบโอเมตริกเป็นรุ่นคลาส 3 (เดิมชื่อรัดกุม) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-3-3] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 7% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับตัวปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีการนำเสนอ (PAI) ระดับ A ไม่สูงกว่า 7% และ (2) อัตราการยอมรับการปลอมแปลงและตัวปลอมของสปีชีส์ PAI ระดับ B ที่ไม่สูงกว่า 20% โปรโตคอลการทดสอบ Android
7.3.13 IEEE 802.1.15.4 (UWB): เพิ่มส่วนข้อกำหนดใหม่สำหรับ UWB
ดูการแก้ไข
7.3.13 IEEE 802.1.15.4 (UWB)
หากการใช้งานอุปกรณ์มีการรองรับ 802.1.15.4 และมีฟังก์ชันการทำงานนี้แก่แอปพลิเคชันของบุคคลที่สาม สิทธิ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้ Android API ที่สอดคล้องกันใน android.uwb
- [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
- [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่กำหนดไว้ใน การใช้งาน Android
- [C-1-4] ต้องระบุค่าบริการเพื่อให้ผู้ใช้สามารถสลับสถานะเปิด/ปิดวิทยุ UWB
- [C-1-5] ต้องบังคับใช้การใช้สิทธิ์ UWB_RANGING ของแอปโดยใช้สิทธิ์ UWB_RANGING ของแอป (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)
- [C-1-6] ขอแนะนำเป็นอย่างยิ่งให้ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องที่กำหนดโดยองค์กรมาตรฐาน รวมถึง FIRA, CCC และ CSA
สิ้นสุดข้อกำหนดใหม่
7.4.1 โทรศัพท์: การอัปเดตข้อกำหนดเกี่ยวกับโทรศัพท์สำหรับการตั้งค่าโทรศัพท์ GSM และ CDMA รวมถึงการใช้งานเครือข่ายมือถือ
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมที่ฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามใช้งานฟังก์ชัน eSIM ได้ ฟังก์ชันดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้อง ประกาศ Flag ฟีเจอร์
android.hardware.telephony.euicc
ติดตั้งใช้งาน Flag ฟีเจอร์EuiccManager API
โดยสมบูรณ์
หากการติดตั้งใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA ให้ทำดังนี้
- [C-6-1]
SmsManager#sendTextMessage
และSmsManager#sendMultipartTextMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อให้บริการฟังก์ชันการรับส่งข้อความSmsManager#sendMultimediaMessage
และSmsManager#downloadMultimediaMessage
ต้องส่งผลให้เกิดการเรียกที่สอดคล้องกันไปยังCarrierMessagingService
เพื่อให้บริการฟังก์ชันการรับส่งข้อความมัลติมีเดีย - [C-6-2] แอปพลิเคชันที่กำหนดโดย
android.provider.Telephony.Sms#getDefaultSmsPackage
ต้องใช้ SmsManager API เมื่อส่งและรับข้อความ SMS และ MMS การใช้งานข้อมูลอ้างอิง AOSP ในแพ็กเกจ/แอป/การรับส่งข้อความจะเป็นไปตามข้อกำหนดนี้ - [C-6-3] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องรองรับการป้อนรหัสแป้นโทรศัพท์ที่กำหนดเองในรูปแบบ*#*#CODE#*#*
และ ทริกเกอร์การออกอากาศTelephonyManager#ACTION_SECRET_CODE
ที่เกี่ยวข้อง - [C-6-4] แอปพลิเคชันที่ตอบสนองต่อ
Intent#ACTION_DIAL
ต้องใช้VoicemailContract.Voicemails#TRANSCRIPTION
เพื่อแสดงการถอดข้อความเสียงเป็นภาพต่อผู้ใช้หากรองรับ การถอดข้อความเสียงเป็นภาพ - [C-6-5] ต้องแสดง SubscriptionInfo ทั้งหมดด้วย UUID กลุ่มที่เทียบเท่ากันเป็นการสมัครใช้บริการเดียวในราคาที่แสดงต่อผู้ใช้ทั้งหมดซึ่งจะแสดงและควบคุมข้อมูลซิมการ์ด ตัวอย่างของค่าใช้จ่ายดังกล่าว ได้แก่ อินเทอร์เฟซการตั้งค่าที่ตรงกับ
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
หรือEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] ต้องไม่แสดงหรืออนุญาตการควบคุม SubscriptionInfo ด้วย UUID กลุ่มและบิตของโอกาสที่ไม่เป็นค่าว่าง โดยอนุญาตให้กำหนดค่าหรือควบคุมการตั้งค่าซิมการ์ดได้
หากการใช้งานอุปกรณ์รวมถึงระบบโทรศัพท์ GSM หรือ CDMA และมีแถบสถานะของระบบ ให้ทำดังนี้
- [C-6-7] ต้องเลือกการสมัครใช้บริการที่เป็นตัวแทนสำหรับ UUID ของกลุ่มหนึ่งๆ เพื่อแสดงต่อผู้ใช้ในทุกราคาที่ให้ข้อมูลสถานะของซิม เช่น ไอคอนสัญญาณมือถือในแถบสถานะหรือการ์ดการตั้งค่าด่วน
- [C-SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้การสมัครใช้บริการของตัวแทนเป็นการสมัครใช้บริการข้อมูลที่ใช้งานอยู่ เว้นแต่อุปกรณ์จะอยู่ในสายสนทนา ซึ่งในระหว่างนั้นเราขอแนะนำอย่างยิ่งว่าการสมัครใช้บริการของตัวแทนจะเป็นการสมัครใช้บริการ Voice ที่ใช้งานอยู่
หากการติดตั้งใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA ให้ทำดังนี้
- [C-6-8] ต้องมีความสามารถในการเปิดและใช้ช่องทางเชิงตรรกะพร้อมกันถึงจำนวนสูงสุด (รวม 20 แชแนล) สำหรับแต่ละ UICC ตาม ETSI TS 102 221
- [C-6-10] ต้องไม่ใช้ลักษณะการทำงานต่อไปนี้กับแอปของผู้ให้บริการที่ใช้งานอยู่
(ตามที่กำหนดโดย
TelephonyManager#getCarrierServicePackageName
) โดยอัตโนมัติหรือไม่มีการยืนยันจากผู้ใช้อย่างชัดแจ้ง- เพิกถอนหรือจำกัดสิทธิ์เข้าถึงเครือข่าย
- เพิกถอนสิทธิ์
- จำกัดการดำเนินการของแอปในเบื้องหลังหรือเบื้องหน้านอกเหนือจากฟีเจอร์การจัดการพลังงานที่มีอยู่ซึ่งรวมอยู่ใน AOSP
- ปิดใช้หรือถอนการติดตั้งแอป
หากการใช้งานอุปกรณ์รวมถึงระบบโทรศัพท์ GSM หรือ CDMA และการสมัครใช้บริการที่ไม่ใช่โอกาสที่ใช้งานอยู่ทั้งหมด ซึ่งใช้ UUID ของกลุ่มร่วมกันถูกปิดใช้, ถูกนำออกจากอุปกรณ์จริง หรือทำเครื่องหมายว่าเป็นการฉวยโอกาส อุปกรณ์จะมีผลดังนี้
- [C-7-1] ต้องปิดใช้ การสมัครใช้บริการโอกาส ที่ใช้งานอยู่ทั้งหมดที่เหลืออยู่ในกลุ่มเดียวกันโดยอัตโนมัติ
หากการติดตั้งใช้งานอุปกรณ์รวมถึงการใช้โทรศัพท์ GSM แต่ไม่ใช่โทรศัพท์ CDMA ระบบจะดำเนินการต่อไปนี้
- [C-8-1] ต้องไม่ประกาศ
PackageManager#FEATURE_TELEPHONY_CDMA
- [C-8-2] ต้องใส่
IllegalArgumentException
เมื่อมีการพยายามตั้งค่าประเภทเครือข่าย 3GPP2 เป็นบิตมาสก์ประเภทเครือข่ายที่ต้องการหรือที่ได้รับอนุญาต - [C-8-3] ต้องแสดงผลสตริงว่างจาก
TelephonyManager#getMeid
หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC ที่มีพอร์ตและโปรไฟล์หลายรายการ ระบบจะดำเนินการดังต่อไปนี้
- [C-11-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.telephony.euicc.mep
สิ้นสุดข้อกำหนดใหม่
- [C-3-1] ต้อง ประกาศ Flag ฟีเจอร์
7.4.1.1 ความเข้ากันได้ของการบล็อกหมายเลข: การอัปเดตข้อกำหนดในการบล็อกหมายเลข
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์รายงาน
android.hardware.telephony feature
ระบบจะดำเนินการต่อไปนี้- [C-1-4] ต้องไม่เขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก
- [C-1-4] ต้องเขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก และต้องกรองการโทรที่มี
BLOCKED_TYPE
ออกจากมุมมองบันทึกการโทรเริ่มต้นในแอปแป้นโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า - ควรอำนวยความสะดวกให้ผู้ใช้ในการแสดงสายที่ถูกบล็อกในแอปโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า
สิ้นสุดข้อกำหนดใหม่
7.4.1.3 Cellular NAT-T Keepalive Offload: ส่วนใหม่สำหรับเครือข่ายมือถือ NAT-T Keepalive Offload
ดูการแก้ไข
7.4.1.3 การลดภาระงาน NAT-T Keepalive ของเครือข่ายมือถือ
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือ
หากการใช้งานอุปกรณ์มีการรองรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือและแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ SocketKeepAlive API
- [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ
- [C-1-3] ต้องรองรับสล็อต Keepalive ผ่านเครือข่ายมือถือพร้อมกันได้มากเท่าที่ Cellular Radio HAL รองรับ
- [C-SR] ขอแนะนำอย่างยิ่งให้รองรับช่อง Keepalive ของเครือข่ายมือถืออย่างน้อย 3 ช่องต่ออินสแตนซ์วิทยุ
หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงผล ERROR_UNSUPPORTED
สิ้นสุดข้อกำหนดใหม่
7.4.2.5 ตำแหน่ง Wi-Fi (ระยะเวลารับส่งข้อมูล Wi-Fi - RTT): การอัปเดตความแม่นยำของตำแหน่ง Wi-Fi
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีการรองรับตำแหน่ง Wi-Fi และเปิดเผยฟังก์ชันให้แก่แอปของบุคคลที่สาม การใช้งานจะมีลักษณะดังนี้
- [C-1-4] ต้องมีความแม่นยำภายในระยะ 2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม)
- [C-SR] แนะนำให้รายงานอย่างถูกต้องภายในระยะ 1.5 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม)
สิ้นสุดข้อกำหนดใหม่
7.4.2.6 Wi-Fi Keepalive Offload: อัปเดตเพื่อเพิ่มข้อกำหนดการลดภาระงาน Keepalive ของเครือข่ายมือถือ
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์
- ควรมีการสนับสนุนสำหรับการลดภาระงาน Wi-Fi Keepalive
หากการนำอุปกรณ์ไปใช้มีการรองรับการเลิกใช้ Keepalive ของ Wi-Fi และแสดงฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม เหตุการณ์เหล่านี้จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ SocketKeepAlive API
- [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi
และช่อง Keepalive อย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ
หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Wi-Fi Keepalive สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องส่งคืน
ERROR_UNSUPPORTED
7.4.2.9 ความน่าเชื่อถือในการใช้งานครั้งแรก (TOFU): ส่วนข้อกำหนดของความเชื่อมั่นในการใช้ครั้งแรกที่เพิ่ม
ดูการแก้ไข
7.4.2.9 การเชื่อถือสำหรับการใช้งานครั้งแรก (TOFU)
หากการติดตั้งใช้งานอุปกรณ์รองรับ Trust on first use (TOFU) และอนุญาตให้ผู้ใช้กําหนดค่า WPA/WPA2/WPA3-Enterprise ระบบจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องระบุตัวเลือกให้ผู้ใช้เลือกใช้ TOFU
สิ้นสุดข้อกำหนดใหม่
7.4.3 บลูทูธ: การอัปเดตข้อกำหนดของบลูทูธ
ดูการแก้ไข
หากอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ ระบบจะดำเนินการต่อไปนี้
- ควรรองรับตัวแปลงรหัสเสียงขั้นสูงและตัวแปลงรหัสเสียงบลูทูธ (เช่น LDAC) ที่มี A2DP
หากการติดตั้งใช้งานอุปกรณ์แสดงผล
true
สำหรับBluetoothAdapter.isLeAudioSupported()
API ระบบจะดำเนินการดังต่อไปนี้- [C-7-1] ต้องรองรับไคลเอ็นต์ unicast
- [C-7-2] ต้องรองรับ 2M PHY
- [C-7-3] ต้องรองรับการโฆษณา LE Extended
- [C-7-4] ต้องรองรับการเชื่อมต่อ CIS อย่างน้อย 2 รายการใน CIG
- [C-7-5] ต้องเปิดใช้ไคลเอ็นต์ BAP unicast, ผู้ประสานงานชุด CSIP, เซิร์ฟเวอร์ MCP, ตัวควบคุม VCP, เซิร์ฟเวอร์ CCP พร้อมกัน
- [C-SR] แนะนำอย่างยิ่งให้เปิดใช้ไคลเอ็นต์ HAP unicast
หากการติดตั้งใช้งานอุปกรณ์แสดงผล
true
สำหรับBluetoothAdapter.isLeAudioBroadcastSourceSupported()
API ระบบจะดำเนินการดังต่อไปนี้- [C-8-1] ต้องรองรับลิงก์ BIS อย่างน้อย 2 ลิงก์ใน BIG
- [C-8-2] ต้องเปิดใช้แหล่งที่มาของการออกอากาศ BAP, ผู้ช่วยออกอากาศ BAP พร้อมกัน
- [C-8-3] ต้องรองรับการโฆษณาของ LE Periodic
หากการติดตั้งใช้งานอุปกรณ์แสดงผล
true
สำหรับBluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API ระบบจะดำเนินการดังต่อไปนี้- [C-9-1] ต้องรองรับ PAST (Periodic Advertising Sync Transfer)
- [C-9-2] ต้องรองรับการโฆษณา LE Periodic
การใช้งานอุปกรณ์จะประกาศ
FEATURE_BLUETOOTH_LE
ดังต่อไปนี้- [C-10-1] ต้องมีค่า RSSI ที่อยู่ในช่วง +/-9dB สำหรับ 95% ของการวัดที่ระยะห่าง 1 เมตรจากอุปกรณ์อ้างอิงที่กำลังส่งที่
ADVERTISE_TX_POWER_HIGH
ในสภาพแวดล้อมแนวสายตา - [C-10-2] ต้องรวมการแก้ไข Rx/Tx เพื่อลดการเบี่ยงเบนต่อช่องสัญญาณ เพื่อให้ค่าที่วัดได้ในแต่ละช่องสัญญาณทั้ง 3 เสาอากาศแต่ละเสา (หากใช้หลายสาย) จะอยู่ภายใน +/-3dB ของกันและกันสำหรับค่าที่วัดได้ 95%
- [C-SR] ขอแนะนำอย่างยิ่งให้วัดและชดเชยออฟเซ็ต Rx เพื่อให้ค่ามัธยฐานของ BLE RSSI เท่ากับ -60dBm +/-10 dB ที่ระยะห่าง 1 เมตรจากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่
ADVERTISE_TX_POWER_HIGH
โดยที่อุปกรณ์อยู่ในแนว "ระนาบคู่ขนาน" โดยหน้าจอหันไปในทิศทางเดียวกัน - [C-SR] ขอแนะนำอย่างยิ่งให้วัดและค่าชดเชย Tx เพื่อให้แน่ใจว่าค่ามัธยฐานของ BLE RSSI คือ -60dBm +/-10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในตำแหน่งระยะ 1 เมตรและส่งที่
ADVERTISE_TX_POWER_HIGH
โดยที่อุปกรณ์อยู่ในทิศทางเดียวกับหน้าจอที่หันหน้าไปทาง "ระนาบคู่ขนาน"
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการปรับเทียบสถานที่ตั้ง
หากอุปกรณ์รองรับบลูทูธเวอร์ชัน 5.0 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-SR] ได้รับการแนะนำอย่างยิ่งให้ให้การสนับสนุนสำหรับสิ่งต่อไปนี้
- เล 2 เอ็ม ฟี
- LE Codec PHY
- ส่วนขยายโฆษณา LE
- การโฆษณาตามระยะเวลา
- ชุดโฆษณาอย่างน้อย 10 ชุด
- การเชื่อมต่อพร้อมกันอย่างน้อย 8 LE การเชื่อมต่อแต่ละรายการอาจอยู่ในบทบาท โทโพโลยีการเชื่อมต่ออย่างใดอย่างหนึ่ง
- นโยบายความเป็นส่วนตัวของ LE Link Layer
- ขนาด "รายการที่กำลังแก้ไข" อย่างน้อย 8 รายการ
สิ้นสุดข้อกำหนดใหม่
7.4.9 UWB: เพิ่มส่วนข้อกำหนดสำหรับฮาร์ดแวร์ UWB
ดูการแก้ไข
7.4.9 UWB
หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์
android.hardware.uwb
ผ่านชั้นเรียนandroid.content.pm.PackageManager
ระบบจะดำเนินการดังต่อไปนี้- [C-1-1] ต้องตรวจสอบว่าการวัดระยะทางอยู่ภายใน +/-15 ซม. สำหรับ 95% ของการวัดในแนวสายตาที่ระยะห่าง 1 ม. ในห้องที่ไม่สะท้อน
- [C-1-2] ต้องตรวจสอบว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายใน [0.75 ม., 1.25 ม.] โดยวัดระยะทางความจริงของพื้นจากขอบด้านบนของ DUT ที่ถือขึ้นโดยหงายขึ้นและเอียง 45 องศา
เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการปรับเทียบสถานที่ตั้ง
สิ้นสุดข้อกำหนดใหม่
กล้อง 7.5: การอัปเดตข้อกำหนดสำหรับความสามารถด้านเอาต์พุต HDR 10 บิต
ดูการแก้ไข
หากอุปกรณ์รองรับความสามารถในการเอาต์พุต HDR 10 บิต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์ HLG HDR เป็นอย่างน้อยสำหรับอุปกรณ์กล้องทุกตัวที่รองรับเอาต์พุต 10 บิต
- [C-2-2] ต้องรองรับเอาต์พุต 10 บิตสำหรับกล้องหลังหรือกล้องหน้าหลัก
- [C-SR] ขอแนะนำอย่างยิ่งให้รองรับเอาต์พุต 10 บิตสำหรับกล้องหลักทั้ง 2 ตัว
- [C-2-3] ต้องรองรับโปรไฟล์ HDR เดียวกันสำหรับกล้องย่อยตัวจริงที่รองรับ BACKWARD_COMPATIBLE ของกล้องตรรกะ และกล้องตรรกะเอง
สำหรับอุปกรณ์กล้อง Logical ที่รองรับ HDR 10 บิตที่ใช้
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้- [C-3-1] ต้องรองรับการสลับระหว่างกล้องตัวจริงที่เข้ากันได้แบบย้อนหลังทั้งหมดผ่านตัวควบคุม
CONTROL_ZOOM_RATIO
ในกล้องตรรกะ
สิ้นสุดข้อกำหนดใหม่
โหมดโฮสต์ USB 7.7.2: การแก้ไขสำหรับพอร์ตบทบาทคู่
ดูการแก้ไข
หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C ไหม
- [C-4-1] ต้องใช้ฟังก์ชันการทำงานของพอร์ตบทบาทแบบคู่ตามที่ระบุไว้ในข้อกำหนดเฉพาะ USB Type-C (ส่วนที่ 4.5.1.3.3) สำหรับ Dual Role Ports ในอุปกรณ์ที่มีช่องเสียบเสียง 3.5 มม.การตรวจหาซิงก์ USB (โหมดโฮสต์) อาจปิดอยู่โดยค่าเริ่มต้น แต่ผู้ใช้ต้องเปิดใช้ได้
7.11 ชั้นเรียนประสิทธิภาพของสื่อ: อัปเดตให้รวม Android T ด้วย
ดูการแก้ไข
หากการติดตั้งใช้งานอุปกรณ์แสดงผลค่าที่ไม่ใช่ 0 สำหรับ
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
ระบบจะดำเนินการต่อไปนี้- [C-1-3] ต้องเป็นไปตามข้อกำหนดทั้งหมดสำหรับ "คลาสประสิทธิภาพของสื่อ" ที่อธิบายไว้ในส่วนที่ 2.2.7
กล่าวคือ คลาสประสิทธิภาพของสื่อใน Android T ได้รับการกำหนดไว้สำหรับอุปกรณ์พกพาในเวอร์ชัน T, S หรือ R เท่านั้น
สิ้นสุดข้อกำหนดใหม่
ดูส่วนที่ 2.2.7 สำหรับข้อกำหนดเฉพาะอุปกรณ์
9. ความเข้ากันได้กับโมเดลความปลอดภัย
9.1 สิทธิ์: ขยายเส้นทางที่ยอมรับได้สำหรับรายการที่อนุญาตของสิทธิ์สำหรับแอปที่ติดตั้งล่วงหน้าไปยังไฟล์ APEX
ดูการแก้ไข
- [C-0-2] สิทธิ์ที่มี
protectionLevel
เป็นPROTECTION_FLAG_PRIVILEGED
ต้องให้แก่แอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบ (รวมถึงไฟล์ APEX) และอยู่ภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอปเท่านั้น การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและให้สิทธิ์ที่อนุญาตสำหรับแต่ละเส้นทางจากเส้นทางและไฟล์ในetc/permissions/
system/priv-app
- [C-0-2] สิทธิ์ที่มี
9.7 ฟีเจอร์ความปลอดภัย: การอัปเดตข้อกำหนดในการเริ่มต้นเพื่อรักษาความสมบูรณ์ของเคอร์เนล
ดูการแก้ไข
ความสมบูรณ์ของเคอร์เนลและฟีเจอร์การป้องกันตนเองเป็นส่วนสำคัญในการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์
- [C-SR] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในที่ไม่ได้เริ่มต้น (
CONFIG_INIT_STACK_ALL
หรือCONFIG_INIT_STACK_ALL_ZERO
) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคาดเดาค่าที่คอมไพเลอร์ใช้ในการเริ่มต้นในเครื่อง
สิ้นสุดข้อกำหนดใหม่
- [C-SR] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในที่ไม่ได้เริ่มต้น (
9.8.7 ความเป็นส่วนตัว - การเข้าถึงคลิปบอร์ด: ล้างข้อมูลคลิปบอร์ดโดยอัตโนมัติหลังจาก 60 นาทีหลังจากตัด/คัดลอก/วาง เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
ดูการแก้ไข
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องไม่ส่งคืนข้อมูลที่ถูกตัดจากคลิปบอร์ด (เช่น ผ่าน
ClipboardManager
API) เว้นแต่แอป ของบุคคลที่สาม จะเป็น IME เริ่มต้นหรือแอปที่คุณโฟกัสอยู่ในปัจจุบัน - [C-0-2] ต้องล้างข้อมูลคลิปบอร์ดไม่เกิน 60 นาทีหลังจากวางในคลิปบอร์ดหรืออ่านจากคลิปบอร์ด
- [C-0-1] ต้องไม่ส่งคืนข้อมูลที่ถูกตัดจากคลิปบอร์ด (เช่น ผ่าน
9.11 คีย์และข้อมูลเข้าสู่ระบบ: การอัปเดตข้อกำหนดของหน้าจอล็อกที่ปลอดภัย ซึ่งรวมถึงการเพิ่ม ECDH และ 3DES ในอัลกอริทึมคริปโต
ดูการแก้ไข
เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้
- [C-1-2] ต้องมีการใช้งาน RSA, AES, ECDSA, ECDH (หากรองรับ IKeyMintDevice), 3DES, และอัลกอริทึมการเข้ารหัส HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่อยู่เหนือและแยกโค้ดที่ทำงานบนเคอร์เนลอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
9.11.1 หน้าจอล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือน: เพิ่มส่วนข้อกำหนดสำหรับอุปกรณ์เสมือนและการโอนการตรวจสอบสิทธิ์
ดูการแก้ไข
หากมีการใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกและวิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามโทเค็นจริงหรือตำแหน่ง
- [C-6-3] ผู้ใช้ต้องได้รับคำถามสำหรับวิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่งที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 4 ชั่วโมงหรือน้อยกว่านั้น เมื่อโทเค็นจริงตรงตามข้อกำหนดสำหรับการติดตั้งใช้งาน TrustAgent ใน C-X ข้อจำกัดการหมดเวลาที่กำหนดไว้ใน C-9-5 จะมีผลแทน
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและไม่รองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน
VirtualDeviceManager
จะมีการดำเนินการต่อไปนี้- [C-9-1] ต้องล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ล็อกอยู่ และปลดล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ปลดล็อกอยู่
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและรองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager การดำเนินการจะมีลักษณะดังนี้
- [C-10-1] ต้องรองรับสถานะการล็อกที่แยกต่างหากต่ออุปกรณ์เสมือน
- [C-10-2] ต้องยกเลิกการเชื่อมต่ออุปกรณ์เสมือนทั้งหมดเมื่อไม่มีการใช้งานจนถึงระยะหมดเวลา
- [C-10-3] ต้องมีระยะหมดเวลาเนื่องจากไม่มีการใช้งาน
- [C-10-4] ต้องล็อกจอแสดงผลทั้งหมดเมื่อผู้ใช้เริ่ม การปิดล็อก รวมถึง การชำระค่าปิดล็อกสำหรับอุปกรณ์พกพาที่จำเป็น (ดู ส่วนที่ 2.2.5[9.11/H-1-2])
- [C-10-5] ต้องมีอินสแตนซ์อุปกรณ์เสมือนแยกกันต่อผู้ใช้
- [C-10-6] ต้องปิดใช้การสร้างเหตุการณ์อินพุตที่เกี่ยวข้องผ่าน
VirtualDeviceManager
เมื่อระบุโดยDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] ต้องใช้คลิปบอร์ดแยกกันสำหรับอุปกรณ์เสมือนแต่ละเครื่องเท่านั้น (หรือปิดใช้คลิปบอร์ดสำหรับอุปกรณ์เสมือน)
- [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึง การป้อนปัจจัยความรู้และข้อความแจ้งข้อมูลไบโอเมตริก
- [C-10-12] ต้องจำกัด Intent ที่เริ่มต้นจากอุปกรณ์เสมือนให้แสดงเฉพาะ บนอุปกรณ์เสมือนเครื่องเดียวกันเท่านั้น
- [C-10-13] ต้องไม่ใช้สถานะล็อกอุปกรณ์เสมือนเป็นการให้สิทธิ์การตรวจสอบสิทธิ์ผู้ใช้ด้วยระบบ Android Keystore โปรดดู
KeyGenParameterSpec.Builder.setUserAuthentication*
เมื่อใช้งานอุปกรณ์อนุญาตให้ผู้ใช้โอนปัจจัยความรู้ในการตรวจสอบสิทธิ์หลักจากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เช่น การตั้งค่าเริ่มต้นของอุปกรณ์เป้าหมาย การดำเนินการเหล่านี้จะมีผลดังนี้
- [C-11-1] ต้องเข้ารหัสฐานความรู้โดยมีการรับประกันการปกป้องที่คล้ายคลึงกับที่ระบุไว้ในสมุดปกขาวเกี่ยวกับความปลอดภัยของบริการ Google Cloud Key Vault เมื่อโอนปัจจัยความรู้จากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เพื่อไม่ให้ระบบสามารถถอดรหัสหรือใช้เครื่องมือความรู้จากระยะไกลเพื่อปลดล็อกอุปกรณ์ใดอุปกรณ์หนึ่งได้จากระยะไกล
- [C-11-2] ต้องขอให้ผู้ใช้ยืนยันปัจจัยความรู้ของอุปกรณ์ต้นทางก่อนที่จะโอนปัจจัยความรู้ไปยังอุปกรณ์เป้าหมาย
- [C-11-3] ในอุปกรณ์เป้าหมายที่ไม่มีองค์ความรู้ด้านการตรวจสอบสิทธิ์หลักที่ตั้งไว้ ขอให้ผู้ใช้ยืนยันปัจจัยความรู้ที่โอนในอุปกรณ์เป้าหมายก่อนตั้งค่ากราฟความรู้เป็นปัจจัยหลักในการตรวจสอบสิทธิ์สำหรับอุปกรณ์เป้าหมาย และก่อนที่จะทำให้ข้อมูลที่โอนมาจากอุปกรณ์ต้นทางพร้อมใช้งาน
หากการนำอุปกรณ์ไปใช้งานมีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งเรียกใช้
TrustAgentService.grantTrust()
System API ด้วยแฟล็กFLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
จะมีคำสั่งต่อไปนี้- [C-12-1] ต้องเรียกใช้
grantTrust()
พร้อมธงเฉพาะเมื่อเชื่อมต่อกับอุปกรณ์จริงในบริเวณใกล้เคียงที่มีหน้าจอล็อกของตนเอง และเมื่อผู้ใช้ตรวจสอบสิทธิ์ตัวตนกับหน้าจอล็อกนั้นแล้ว อุปกรณ์ที่อยู่ในบริเวณใกล้เคียงสามารถใช้กลไกการตรวจจับบนข้อมือหรือบนร่างกายหลังจากที่ปลดล็อกผู้ใช้ครั้งเดียวแล้วเพื่อให้เป็นไปตามข้อกำหนดในการตรวจสอบสิทธิ์ของผู้ใช้ - [C-12-2] ต้องทำให้การใช้งานอุปกรณ์อยู่ในสถานะ
TrustState.TRUSTABLE
เมื่อหน้าจอปิด (เช่น การกดปุ่มหรือหมดเวลาหน้าจอ) และ TrustAgent ไม่ได้เพิกถอนความไว้วางใจ AOSP เป็นไปตาม ข้อกำหนดนี้ - [C-12-3] ต้องย้ายอุปกรณ์จาก
TrustState.TRUSTABLE
ไปยังสถานะTrustState.TRUSTED
เฉพาะเมื่อ TrustAgent ยังคงให้ความไว้วางใจตามข้อกำหนดใน C-12-1 - [C-12-4] ต้องเรียกใช้
TrustManagerService.revokeTrust()
หลังจากเวลาสูงสุด 24 ชั่วโมงนับจากที่ให้สิทธิ์ กรอบเวลาที่ไม่มีการใช้งาน 8 ชั่วโมง หรือเมื่อการเชื่อมต่อพื้นฐานกับอุปกรณ์จริงที่อยู่ใกล้ๆ ขาดหาย
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและรองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager และจอแสดงผลไม่ได้ทำเครื่องหมายด้วย VIRTUAL_DISPLAY_FLAG_SECURE ไว้ สิ่งต่อไปนี้จะเกิดขึ้น
- [C-13-8] ต้องบล็อก activities ด้วยแอตทริบิวต์ android:canDisplayOnRemoteDevices หรือเมตา-data android.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น false ไม่ให้เริ่มทำงานบนอุปกรณ์เสมือนจริง
- [C-13-9] ต้องบล็อกกิจกรรม ซึ่งไม่ได้เปิดใช้สตรีมมิงอย่างชัดแจ้ง และ ระบุว่าแสดงเนื้อหาที่ละเอียดอ่อนผ่าน SurfaceView#setSecure, FLAG_SECURE หรือ SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS ไม่ให้เริ่มทำงานบนอุปกรณ์เสมือน
- [C-13-10] ต้องปิดใช้การติดตั้งแอปที่เริ่มต้นจากอุปกรณ์เสมือน
สิ้นสุดข้อกำหนดใหม่
9.11.2 Strongbox: ทำให้ ความต้านทานการโจมตีภายใน (IAR) เป็นข้อกำหนดที่จำเป็น
ดูการแก้ไข
หากต้องการตรวจสอบการปฏิบัติตามข้อกำหนดกับ [C-1-3] จนถึง [C-1-9] การติดตั้งใช้งานอุปกรณ์ ให้ทำดังนี้
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ป้องกันการโจมตีแบบบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox รั่วไหลข้อมูลลับ เพื่อข้ามข้อกำหนดด้านความปลอดภัยที่ใช้งานได้ หรือเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการใช้ IAR คืออนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านหลักของผู้ใช้ผ่าน IAuthSecret HAL IAR จะกลายเป็นข้อกำหนดที่จำเป็นใน Android 14
9.11.3 ข้อมูลเข้าสู่ระบบข้อมูลประจำตัว: เพิ่มข้อมูลเกี่ยวกับการใช้งานการอ้างอิงระบบข้อมูลประจำตัว
ดูการแก้ไข
ระบบจะกำหนดและใช้ระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัวด้วยการใช้ API ทั้งหมดในแพ็กเกจ
android.security.identity.*
API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและเรียกข้อมูลเอกสารข้อมูลประจำตัวของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์โปรเจ็กต์โอเพนซอร์ส Android มีการปรับใช้การอ้างอิงของแอปพลิเคชันที่เชื่อถือได้ (libeic) ซึ่งสามารถใช้เพื่อใช้งานระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัว
สิ้นสุดข้อกำหนดใหม่
9.11.4 เอกสารรับรองรหัส: เพิ่มหัวข้อสำหรับข้อกำหนดเอกสารรับรองรหัส
ดูการแก้ไข
9.17 เฟรมเวิร์กเสมือนจริงของ Android: เพิ่มส่วนข้อกำหนดสำหรับเฟรมเวิร์กเสมือนจริงของ Android
ดูการแก้ไข
9.17 เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android
หากอุปกรณ์ใช้การรองรับ Android Virtualization Framework (
android.system.virtualmachine.*
) โฮสต์ Android จะทำสิ่งต่อไปนี้- [C-1-1] ต้องรองรับ API ทั้งหมดที่กำหนดโดยแพ็กเกจ
android.system.virtualmachine.*
- [C-1-2] ต้องไม่แก้ไข SELinux ของ Android และโมเดลสิทธิ์สำหรับการจัดการเครื่องเสมือนที่มีการป้องกัน
- [C-1-3] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy ที่ระบุในโปรเจ็กต์โอเพนซอร์ส Android อัปสตรีม (AOSP) และนโยบายต้องคอมไพล์ด้วยกฎที่ไม่อนุญาตทั้งหมดที่มีอยู่
- [C-1-4] ต้องไม่อนุญาตให้โค้ดที่ไม่น่าเชื่อถือ (เช่น แอป 3p) สร้างและเรียกใช้เครื่องเสมือนที่มีการป้องกัน หมายเหตุ: ข้อมูลนี้อาจเปลี่ยนแปลงได้ใน Android รุ่นต่อๆ ไป
- [C-1-5] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้โค้ดที่ไม่ได้เป็นส่วนหนึ่งของอิมเมจเริ่มต้นหรือการอัปเดต สิ่งใดก็ตามที่ไม่ได้ครอบคลุมอยู่ในการเปิดเครื่องที่ได้รับการยืนยันของ Android (เช่น ไฟล์ที่ดาวน์โหลดจากอินเทอร์เน็ตหรือไซด์โหลด) ต้องไม่ได้รับอนุญาตให้ทำงานในเครื่องเสมือนที่มีการป้องกัน
หากอุปกรณ์ใช้การรองรับสำหรับ Android Virtualization Framework API (
android.system.virtualmachine.*
) อินสแตนซ์ของเครื่องเสมือนที่มีการปกป้องจะทำสิ่งต่อไปนี้- [C-2-1] ต้องเรียกใช้ระบบปฏิบัติการทั้งหมดที่มีอยู่ใน APEX เสมือนในเครื่องเสมือนที่มีการป้องกันได้
- [C-2-2] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้ระบบปฏิบัติการที่ไม่ได้รับรองโดยผู้ติดตั้งอุปกรณ์หรือผู้ให้บริการระบบปฏิบัติการ
- [C-2-3] ต้องไม่อนุญาตให้เครื่องเสมือนที่มีการป้องกันเรียกใช้ข้อมูลเป็นโค้ด (เช่น SELinux ไม่อนุญาต execmem)
- [C-2-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy/microdroid ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP)
- [C-2-5] ต้องใช้กลไกการป้องกันเชิงลึกของเครื่องเสมือนที่มีการป้องกัน (เช่น SELinux สำหรับ pVM) แม้แต่สำหรับระบบปฏิบัติการที่ไม่ใช่ Microdroid
- [C-2-6] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM ปฏิเสธที่จะเปิดเครื่องหากไม่สามารถยืนยันอิมเมจเริ่มต้นได้
- [C-2-7] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM ปฏิเสธที่จะเปิดเครื่องหากความสมบูรณ์ของอินสแตนซ์.img ลดลง
หากอุปกรณ์ใช้การรองรับ Android Virtualization Framework (
android.system.virtualmachine.*
) ไฮเปอร์ไวเซอร์- [C-3-1] ต้องไม่อนุญาตให้ pVM เข้าถึงหน้าเว็บที่เป็นของเอนทิตีอื่น (เช่น pVM หรือ Hypervisor อื่นๆ) เว้นแต่เจ้าของเพจจะแชร์อย่างชัดแจ้ง ซึ่งรวมถึง VM ของโฮสต์ ซึ่งจะมีผลกับทั้งการเข้าถึง CPU และ DMA
- [C-3-2] ต้องล้างข้อมูลหน้าหลังจากที่ VM ใช้และก่อนที่จะส่งกลับไปให้โฮสต์ (เช่น pVM ถูกทำลาย)
- [C-3-3] ต้องตรวจสอบว่าเฟิร์มแวร์ pVM นั้นโหลดและเรียกใช้ก่อนโค้ดใดๆ ใน pVM
- [C-3-4] ต้องตรวจสอบว่า BCC และ CDI ที่ระบุให้กับอินสแตนซ์ pVM จะดึงมาจากอินสแตนซ์ดังกล่าวเท่านั้น
หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การดำเนินการทั้งหมดจะมีผลดังนี้
- [C-4-1] ต้องไม่มอบฟังก์ชันการทำงานให้แก่ pVM ที่อนุญาตให้ข้ามโมเดลความปลอดภัยของ Android
หากอุปกรณ์ใช้การรองรับ API ของ Virtualization Framework ของ Android คุณจะต้องดำเนินการต่อไปนี้
- [C-5-1] ต้องรองรับการคอมไพล์ Isolated ของการอัปเดตรันไทม์ ART
หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การจัดการคีย์จะมีผลดังนี้
- [C-6-1] ต้องรูทเชน DICE ตรงจุดที่ผู้ใช้แก้ไขไม่ได้แม้ในอุปกรณ์ที่ไม่ได้ล็อก (เพื่อให้แน่ใจว่าไม่มีการปลอมแปลง)
- [C-6-2] ต้อง DICE อย่างถูกต้อง นั่นคือ ระบุค่าที่ถูกต้อง แต่อาจไม่จำเป็นต้องลงรายละเอียดถึงระดับนั้น
สิ้นสุดข้อกำหนดใหม่
- [C-1-1] ต้องรองรับ API ทั้งหมดที่กำหนดโดยแพ็กเกจ
13. ติดต่อเรา
คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารนั้นไม่ครอบคลุม