แอนดรอยด์ 14
20 พฤศจิกายน 2023
2. ประเภทอุปกรณ์
ดูการแก้ไข
หากการใช้งานอุปกรณ์มือถือประกาศรองรับ ABI 64 บิต (มีหรือไม่มี ABI 32 บิต):
ดูการแก้ไข
- [ 7.5 /H-1-13] ต้องรองรับความสามารถ
LOGICAL_MULTI_CAMERA
สำหรับกล้องหลังหลัก หากมีกล้องหลัง RGB มากกว่า 1 ตัว
- [ 7.5 /H-1-13] ต้องรองรับความสามารถ
ดูการแก้ไข
[ 5.8 /T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI ไปที่ความละเอียดสูงสุดสำหรับรูปแบบ SDR หรือ HDR ที่เลือกซึ่งใช้งานได้กับอัตราการรีเฟรช 50Hz หรือ 60Hz สำหรับจอแสดงผลภายนอก
ต้องตั้งค่าโหมดเอาต์พุต HDMI เพื่อเลือกความละเอียดสูงสุดที่สามารถรองรับด้วยอัตราการรีเฟรช 50Hz หรือ 60Hz
2.4.5. รูปแบบการรักษาความปลอดภัย :
ดูการแก้ไข
- [9/W-0-1] ต้องประกาศ
android.hardware.security.model.compatible feature
- [9/W-0-1] ต้องประกาศ
6. เครื่องมือสำหรับนักพัฒนาและความเข้ากันได้ของตัวเลือก
6.1. เครื่องมือสำหรับนักพัฒนา :
ดูการแก้ไข
- [C-0-12] ต้องเขียน
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ไปยัง
ดูการแก้ไข
- [C-0-13] ต้องใช้คำสั่งเชลล์
dumpsys gpu --gpuwork
เพื่อแสดง
- [C-0-12] ต้องเขียน
9. ความเข้ากันได้ของโมเดลความปลอดภัย
9.7. คุณสมบัติด้านความปลอดภัย :
ดูการแก้ไข
หากการใช้งานอุปกรณ์ใช้เคอร์เนล Linux ที่สามารถรองรับ SELinux พวกเขา:
ดูการแก้ไข
หากการใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux หรือ Linux โดยไม่มี SELinux พวกเขา:
4 ตุลาคม 2023
2. ประเภทอุปกรณ์
2.2. ข้อกำหนดเกี่ยวกับมือถือ :
ดูการแก้ไข
การใช้งานอุปกรณ์ Android จะจัดอยู่ในประเภทอุปกรณ์พกพาหากมีคุณสมบัติตรงตามเกณฑ์ต่อไปนี้ทั้งหมด:
- มีขนาดหน้าจอแนวทแยงในช่วง 4 นิ้ว
3.3 นิ้ว (หรือ 2.5 นิ้วสำหรับการใช้งานอุปกรณ์ที่จัดส่งบน API ระดับ 29 หรือก่อนหน้า)ถึง 8 นิ้ว
เริ่มข้อกำหนดใหม่
- มีอินเทอร์เฟซอินพุตหน้าจอสัมผัส
- มีขนาดหน้าจอแนวทแยงในช่วง 4 นิ้ว
ดูการแก้ไข
การใช้งานอุปกรณ์พกพา:
- [ 7.1 .1.1/H-0-1] ต้องมี
จอแสดงผลที่รองรับ Android อย่างน้อยหนึ่งจอที่ตรงตามข้อกำหนดทั้งหมดที่อธิบายไว้ในเอกสารนี้จอแสดงผลที่มีขนาดอย่างน้อย 2.2 นิ้วบนขอบด้านสั้นและ 3.4 นิ้วบนขอบด้านยาว
หากการใช้งานอุปกรณ์มือถือรองรับการหมุนหน้าจอซอฟต์แวร์ พวกเขา:
- [ 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 หรือก่อนหน้าอาจได้รับการยกเว้นจากข้อกำหนดนี้
เริ่มข้อกำหนดใหม่
[ 7.1 .1.1/H-0-3]* ต้องแมปแต่ละจอแสดงผล
UI_MODE_NORMAL
ที่ทำให้ใช้งานได้สำหรับแอปพลิเคชันของบุคคลที่สาม บนพื้นที่แสดงผลทางกายภาพที่ไม่มีสิ่งกีดขวาง ซึ่งอย่างน้อย 2.2 นิ้วบนขอบสั้นและ 3.4 นิ้วบนขอบยาว[ 7.1 .1.3/H-0-1]* ต้องตั้งค่า
DENSITY_DEVICE_STABLE
เป็น 92% หรือมากกว่าความหนาแน่นทางกายภาพจริงของจอแสดงผลที่เกี่ยวข้อง
หากการใช้งานอุปกรณ์มือถือประกาศ
android.hardware.audio.output
และandroid.hardware.microphone
พวกเขา:[ 5.6 /H-1-1] ต้องมี Mean Continuous Round-Trip latency 300 มิลลิวินาทีหรือน้อยกว่า 5 การวัด โดยมี Mean Absolute Deviation น้อยกว่า 30ms บนเส้นทางข้อมูลต่อไปนี้: "ลำโพงถึงไมโครโฟน", 3.5 มม. อะแดปเตอร์ลูปแบ็ค (หากรองรับ), ลูปแบ็ค USB (หากรองรับ)
[ 5.6 /H-1-2] จะต้องมีค่าหน่วงเวลาแตะต่อโทนเฉลี่ย 300 มิลลิวินาทีหรือน้อยกว่า การวัดอย่างน้อย 5 ครั้งผ่านเส้นทางข้อมูลลำโพงไปยังไมโครโฟน
หากการใช้งานอุปกรณ์มือถือมีตัวกระตุ้นระบบสัมผัสอย่างน้อยหนึ่งตัว พวกเขา:
- [ 7.10 /H]* ไม่ควรใช้แอคทูเอเตอร์ (เครื่องสั่น) มวลหมุนเยื้องศูนย์ (ERM)
- [ 7.10 /H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดเพื่อให้ ระบบสัมผัสที่ชัดเจน ใน android.view.HapticFeedbackConstants ได้แก่ (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START และ ท่าทาง_END)
- [ 7.10 /H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสำหรับ แฮปติกที่ชัดเจน ใน android.os.VibrationEffect กล่าวคือ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ EFFECT_DOUBLE_CLICK) และค่าคงที่
PRIMITIVE_*
สาธารณะที่เป็นไปได้ทั้งหมดสำหรับ แฮบติคที่หลากหลาย ใน android.os.VibrationEffect.Composition คือ ( คลิก, ติ๊ก, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, หมุน, ทัด) สิ่งพื้นฐานบางอย่างเหล่านี้ เช่น LOW_TICK และ SPIN อาจเป็นไปได้ก็ต่อเมื่อเครื่องสั่นสามารถรองรับความถี่ที่ค่อนข้างต่ำได้ - [7.10/H]* ควรปฏิบัติตาม คำแนะนำในการแมปค่าคงที่สาธารณะ ใน android.view.HapticFeedbackConstants กับค่าคงที่ android.os.VibrationEffect ที่แนะนำ โดยมีความสัมพันธ์แอมพลิจูดที่สอดคล้องกัน
- [ 7.10 /H]* ควรปฏิบัติตาม การประเมินคุณภาพ สำหรับ createOneShot() และ createWaveform() API
- [ 7.10 /H]* ควรตรวจสอบว่าผลลัพธ์ของ android.os.Vibrator.hasAmplitudeControl() API สาธารณะสะท้อนถึงความสามารถของเครื่องสั่นได้อย่างถูกต้อง
- [ 7.10 /H]* ควรวางตำแหน่งแอคชูเอเตอร์ให้ใกล้กับตำแหน่งที่โดยปกติแล้วอุปกรณ์จะถือหรือสัมผัสด้วยมือ
หากการใช้งานอุปกรณ์มือถือมีแอคชูเอเตอร์เรโซแนนซ์เชิงเส้น 7.10 สำหรับวัตถุประสงค์ทั่วไป อย่างน้อยหนึ่งตัว พวกเขา:
- [ 7.10 /H] ควรวางตำแหน่งแอคชูเอเตอร์ให้ใกล้กับตำแหน่งที่โดยปกติแล้วอุปกรณ์จะถือหรือสัมผัสด้วยมือ
- [ 7.10 /H] ควรย้ายแอคชูเอเตอร์ระบบสัมผัสในแกน X (ซ้าย-ขวา) ของการวางแนวแนว
ตั้งตามธรรมชาติของอุปกรณ์
หากการใช้งานอุปกรณ์มือถือมีแอคชูเอเตอร์แบบสัมผัส สำหรับวัตถุประสงค์ทั่วไป ซึ่งเป็นแอคชูเอเตอร์เรโซแนนซ์เชิงเส้นแกน X (LRA) พวกเขา:
- [ 7.10 /H] ควรมีความถี่เรโซแนนซ์ของ LRA แกน X ต่ำกว่า 200 Hz
- [ 7.1 .1.1/H-0-1] ต้องมี
ดูการแก้ไข
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และทำให้ใช้ได้กับแอปพลิเคชันบุคคลที่สาม:
- [ 5.2 /H-0-3] AV1
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และเปิดให้ใช้งานได้กับแอปพลิเคชันบุคคลที่สาม:
- [ 5.3 /H-0-6] AV1
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงปุ่มนำทางฟังก์ชันล่าสุดตามรายละเอียดในส่วน 7.2.3 เปลี่ยนแปลงอินเทอร์เฟซ พวกเขา:
- [ 3.8 .3/H-1-1] ต้องใช้พฤติกรรมการปักหมุดหน้าจอและให้ผู้ใช้มีเมนูการตั้งค่าเพื่อสลับคุณสมบัติ
หากการใช้งานอุปกรณ์มือถือรองรับ
ControlsProviderService
และControl
API และอนุญาตให้แอปพลิเคชันบุคคลที่สามเผยแพร่ การควบคุมอุปกรณ์ พวกเขาจะ:- [ 3.8 .16/H-1-6] การใช้งานอุปกรณ์จะต้องทำให้ผู้ใช้ได้รับผลประโยชน์อย่างถูกต้องดังต่อไปนี้:
- หากอุปกรณ์ได้ตั้งค่า
config_supportsMultiWindow=true
และแอปประกาศข้อมูลเมตาMETA_DATA_PANEL_ACTIVITY
ในการประกาศControlsProviderService
รวมถึง ComponentName ของกิจกรรมที่ถูกต้อง (ตามที่กำหนดโดย API) ดังนั้นแอปจะต้องฝังกิจกรรมดังกล่าวไว้ในการชำระเงินของผู้ใช้รายนี้ - หากแอปไม่ประกาศข้อมูลเมตา
META_DATA_PANEL_ACTIVITY
แอปจะต้องแสดงผลฟิลด์ที่ระบุตามที่ControlsProviderService
API ระบุไว้ รวมถึงฟิลด์ที่ระบุใด ๆ ที่จัดทำโดย Control API
- หากอุปกรณ์ได้ตั้งค่า
- [ 3.8 .16/H-1-7] หากแอปประกาศข้อมูลเมตา
META_DATA_PANEL_ACTIVITY
แอปจะต้องผ่านค่าของการตั้งค่าที่กำหนดไว้ใน [3.8.16/H-1-5] โดยใช้EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
เมื่อเรียกใช้กิจกรรมที่ฝังตัว
หากการใช้งานอุปกรณ์อนุญาตให้ผู้ใช้สามารถโทรออกได้ทุกประเภท
- [ 7.4.1.2 /H-0-1] ต้องประกาศคุณลักษณะ flag
android.software.telecom
- [ 7.4.1.2 /H-0-2] จะต้องดำเนินการตาม กรอบโทรคมนาคม
ดูการแก้ไข
การใช้งานอุปกรณ์มือถือ:
- [ 8.5 /H-0-1] ต้องระบุจำนวนเงินที่ผู้ใช้จ่ายได้
ในเมนูการตั้งค่าเพื่อดูแอปทั้งหมดที่มีบริการเบื้องหน้าที่ใช้งานอยู่หรืองานที่ริเริ่มโดยผู้ใช้ รวมถึงระยะเวลาของแต่ละบริการเหล่านี้นับตั้งแต่เริ่มต้นตามที่อธิบายไว้ใน เอกสาร SDK .และความสามารถในการหยุดแอปที่กำลังเรียกใช้บริการเบื้องหน้าหรืองานที่ผู้ใช้ริเริ่มด้วยความสามารถในการหยุดแอปที่เรียกใช้บริการเบื้องหน้าและแสดงแอปทั้งหมดที่มีบริการเบื้องหน้าที่ใช้งานอยู่ และระยะเวลาของแต่ละบริการเหล่านี้นับตั้งแต่เริ่มต้นตามที่อธิบายไว้ใน เอกสาร SDK- แอปบางแอปอาจได้รับการยกเว้นไม่ให้หยุดหรือแสดงอยู่ในราคาที่ผู้ใช้จ่ายได้ตามที่อธิบายไว้ใน เอกสาร SDK
- [ 8.5 /H-0-1] ต้องระบุจำนวนเงินที่ผู้ใช้จ่ายได้
- [ 8.5 /H-0-2]ต้องให้สิทธิ์ผู้ใช้ในการหยุดแอปที่กำลังเรียกใช้บริการเบื้องหน้าหรืองานที่ผู้ใช้ริเริ่ม
2.2.5. รูปแบบการรักษาความปลอดภัย :
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศรองรับ android.hardware.telephony
พวกเขา:
- [ 9.5 /H-1-1] ต้องไม่ตั้งค่า
UserManager.isHeadlessSystemUserMode
เป็นtrue
หากการใช้งานอุปกรณ์มีหน้าจอล็อคที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อยหนึ่งรายการซึ่งใช้ TrustAgentService
System API พวกเขา:
- [ 9.11.1 /H-1-1] ต้องท้าทายผู้ใช้สำหรับหนึ่งในวิธีการรับรองความถูกต้องหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่าหนึ่งครั้งทุกๆ 72 ชั่วโมง
หากการใช้งานอุปกรณ์มือถือตั้งค่า UserManager.isHeadlessSystemUserMode
เป็น true
ก็จะเป็นเช่นนั้น
หากการใช้งานอุปกรณ์มือถือรองรับ System API HotwordDetectionService
หรือกลไกอื่นสำหรับการตรวจจับคำที่นิยมโดยไม่มีการระบุการเข้าถึงไมโครโฟน พวกเขา:
- [9.8/H-1-1] ต้องแน่ใจว่าบริการตรวจจับคำที่นิยมสามารถส่งข้อมูลไปยัง System,
ContentCaptureService
หรือบริการรู้จำคำพูดบนอุปกรณ์ที่สร้างโดยSpeechRecognizer#createOnDeviceSpeechRecognizer()
เท่านั้น - [9.8/H-1-6] ต้องไม่อนุญาตให้ส่งข้อมูลเกิน 100 ไบต์ (ไม่รวมสตรีมเสียง) ที่จะส่งออกจากบริการตรวจจับคำยอดนิยมในแต่ละผลลัพธ์คำที่นิยม
- [9.8/H-1-15] ต้องตรวจสอบให้แน่ใจว่าสตรีมเสียงที่ให้ไว้กับผลลัพธ์คำที่นิยมที่ประสบความสำเร็จจะถูกส่งทางเดียวจากบริการตรวจจับคำที่นิยมไปยังบริการโต้ตอบด้วยเสียง
หากการใช้งานอุปกรณ์มีแอปพลิเคชันที่ใช้ System API HotwordDetectionService
หรือกลไกที่คล้ายกันสำหรับการตรวจหาคำที่นิยมโดยไม่มีการระบุการใช้ไมโครโฟน แอปพลิเคชันจะ:
- [9.8/H-2-3] ต้องไม่ส่งจากบริการตรวจจับคำที่นิยม ข้อมูลเสียง ข้อมูลที่สามารถใช้เพื่อสร้างเสียงใหม่ (ทั้งหมดหรือบางส่วน) หรือเนื้อหาเสียงที่ไม่เกี่ยวข้องกับคำที่นิยมนั้น ยกเว้นไปยัง
ContentCaptureService
หรือ บริการรู้จำเสียงพูดบนอุปกรณ์
หากการใช้งานอุปกรณ์มือถือรองรับ System API VisualQueryDetectionService
หรือกลไกอื่นสำหรับการตรวจจับการสืบค้นโดยไม่มีตัวบ่งชี้การเข้าถึงไมโครโฟนและ/หรือกล้อง พวกเขา:
- [9.8/H-3-1] ต้องแน่ใจว่าบริการตรวจจับแบบสอบถามสามารถส่งข้อมูลไปยังระบบหรือ
ContentCaptureService
หรือบริการรู้จำคำพูดบนอุปกรณ์เท่านั้น (สร้างโดยSpeechRecognizer#createOnDeviceSpeechRecognizer()
) - [9.8/H-3-2] ต้องไม่อนุญาตให้ส่งข้อมูลเสียงหรือวิดีโอใดๆ ออกจาก
VisualQueryDetectionService
ยกเว้นไปยังContentCaptureService
หรือบริการรู้จำคำพูดบนอุปกรณ์ - [9.8/H-3-3] ต้องแสดงการแจ้งเตือนผู้ใช้ใน System UI เมื่ออุปกรณ์ตรวจพบความตั้งใจของผู้ใช้ที่จะมีส่วนร่วมกับแอปพลิเคชัน Digital Assistant (เช่น โดยการตรวจจับการมีอยู่ของผู้ใช้ผ่านกล้อง)
- [9.8/H-3-4] ต้องแสดงตัวบ่งชี้ไมโครโฟนและแสดงข้อความค้นหาของผู้ใช้ที่ตรวจพบใน UI ทันทีหลังจากที่ตรวจพบข้อความค้นหาของผู้ใช้
- [9.8/H-3-5] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจจับการสืบค้นด้วยภาพ
ดูการแก้ไข
หากการใช้งานอุปกรณ์มือถือส่งคืน android.os.Build.VERSION_CODES.T
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
แสดงว่า:
- ต้องเป็นไปตามข้อกำหนดของสื่อที่ระบุไว้ใน Android 13 CDD มาตรา 2.2.7.1
เริ่มข้อกำหนดใหม่
หากการใช้งานอุปกรณ์มือถือส่งคืนandroid.os.Build.VERSION_CODES.U
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
แสดงว่า:- [5.1/H-1-1] ต้องโฆษณาเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์จำนวนสูงสุดที่สามารถทำงานพร้อมกันในชุดตัวแปลงสัญญาณใดๆ ผ่านทางเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-2] ต้องรองรับ 6 อินสแตนซ์ของเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในการรวมกันของตัวแปลงสัญญาณใด ๆ ที่ทำงานพร้อมกันกับ 3 เซสชันที่ความละเอียด 1080p@30 fps และ 3 เซสชันที่ความละเอียด 4k@30fps ยกเว้น AV1 ตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับ 6 อินสแตนซ์ที่ 1080p30fps
- [5.1/H-1-3] ต้องโฆษณาเซสชันฮาร์ดแวร์เข้ารหัสวิดีโอจำนวนสูงสุดที่สามารถทำงานพร้อมกันในชุดตัวแปลงสัญญาณใดๆ ผ่านทางเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-4] ต้องรองรับ 6 อินสแตนซ์ของเซสชันการเข้ารหัสวิดีโอด้วยฮาร์ดแวร์ 8 บิต (SDR) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในการรวมกันของตัวแปลงสัญญาณใด ๆ ที่ทำงานพร้อมกันกับ 4 เซสชันที่ความละเอียด 1080p@30 fps และ 2 เซสชันที่ความละเอียด 4k@30fps ยกเว้น AV1 ตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับ 6 อินสแตนซ์ที่ 1080p30fps
- [5.1/H-1-5] ต้องโฆษณาเซสชันตัวเข้ารหัสวิดีโอและตัวถอดรหัสฮาร์ดแวร์จำนวนสูงสุดที่สามารถทำงานพร้อมกันในชุดตัวแปลงสัญญาณใดๆ ผ่านทางเมธอด
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-6] ต้องรองรับ 6 อินสแตนซ์ของตัวถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) และเซสชันตัวเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดตัวแปลงสัญญาณใด ๆ ที่ทำงานพร้อมกันกับ 3 เซสชันที่ 4K ความละเอียด @30fps (ยกเว้น AV1) โดยส่วนใหญ่ 2 เซสชันเป็นเซสชันตัวเข้ารหัสและ 3 เซสชันที่ความละเอียด 1080p ตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับ 6 อินสแตนซ์ที่ 1080p30fps
- [5.1/H-1-19] ต้องรองรับ 3 อินสแตนซ์ของตัวถอดรหัสวิดีโอฮาร์ดแวร์ 10 บิต (HDR) และเซสชันตัวเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดตัวแปลงสัญญาณใด ๆ ที่ทำงานพร้อมกันที่ความละเอียด 4K@30fps (ยกเว้น AV1) โดยส่วนใหญ่ 1 รายการเป็นเซสชันตัวเข้ารหัส ซึ่งสามารถกำหนดค่าในรูปแบบอินพุต RGBA_1010102 ผ่านพื้นผิว GL ไม่จำเป็นต้องมีการสร้างข้อมูลเมตา HDR โดยตัวเข้ารหัสหากเข้ารหัสจากพื้นผิว GL เซสชันตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้จะต้องใช้ 4K ก็ตาม
- [5.1/H-1-7] ต้องมีเวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณ 40 ms หรือน้อยกว่าสำหรับเซสชันการเข้ารหัสวิดีโอ 1080p หรือน้อยกว่าสำหรับตัวเข้ารหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ในโหลด โหลดที่นี่ถูกกำหนดให้เป็นเซสชันการแปลงรหัสวิดีโออย่างเดียว 1080p ถึง 720p พร้อมกัน โดยใช้ตัวแปลงสัญญาณวิดีโอแบบฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียงและวิดีโอ 1080p สำหรับตัวแปลงสัญญาณ Dolby Vision เวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณจะต้องอยู่ที่ 50 มิลลิวินาทีหรือน้อยกว่า
- [5.1/H-1-8] ต้องมีเวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณ 30 ms หรือน้อยกว่าสำหรับเซสชันการเข้ารหัสเสียง 128 kbps หรือบิตเรตต่ำกว่าสำหรับตัวเข้ารหัสเสียงทั้งหมดเมื่ออยู่ภายใต้การโหลด โหลดที่นี่ถูกกำหนดให้เป็นเซสชันการแปลงรหัสวิดีโออย่างเดียว 1080p ถึง 720p พร้อมกัน โดยใช้ตัวแปลงสัญญาณวิดีโอแบบฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียงและวิดีโอ 1080p
- [5.1/H-1-9] ต้องรองรับ 2 อินสแตนซ์ของเซสชันตัวถอดรหัสวิดีโอด้วยฮาร์ดแวร์ที่ปลอดภัย (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดตัวแปลงสัญญาณใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 4k@30 fps (ยกเว้น AV1) สำหรับทั้ง 8- บิต (SDR) และเนื้อหา HDR 10 บิต เซสชันตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้จะต้องใช้ 4K ก็ตาม
- [5.1/H-1-10] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ไม่ปลอดภัย 3 อินสแตนซ์ พร้อมด้วยเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 1 อินสแตนซ์ (ทั้งหมด 4 อินสแตนซ์) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในตัวแปลงสัญญาณใดๆ การรวมกันทำงานพร้อมกันกับ 3 เซสชันที่ความละเอียด 4K@30 fps (ยกเว้น AV1) ซึ่งรวมถึงเซสชันตัวถอดรหัสที่ปลอดภัยหนึ่งเซสชันและเซสชันที่ปลอดภัย 1 nn ที่ความละเอียด 1080p@30fps โดยที่สูงสุด 2 เซสชันสามารถอยู่ใน HDR 10 บิต เซสชันตัวแปลงสัญญาณ AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้จะต้องใช้ 4K ก็ตาม
- [5.1/H-1-11] ต้องรองรับตัวถอดรหัสที่ปลอดภัยสำหรับฮาร์ดแวร์ตัวถอดรหัส AVC, HEVC, VP9 หรือ AV1 ทุกตัวบนอุปกรณ์
- [5.1/H-1-12] ต้องมีเวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณ 40 ms หรือน้อยกว่าสำหรับเซสชันการถอดรหัสวิดีโอ 1080p หรือน้อยกว่าสำหรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ในโหลด โหลดที่นี่ถูกกำหนดให้เป็นเซสชันการแปลงรหัสวิดีโออย่างเดียว 1080p ถึง 720p พร้อมกัน โดยใช้ตัวแปลงสัญญาณวิดีโอแบบฮาร์ดแวร์ร่วมกับการเริ่มต้นการเล่นเสียง-วิดีโอ 1080p สำหรับตัวแปลงสัญญาณ Dolby Vision เวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณต้องเป็น 50 มิลลิวินาทีหรือน้อยกว่า
- [5.1/H-1-13] ต้องมีเวลาแฝงในการเริ่มต้นตัวแปลงสัญญาณ 30 ms หรือน้อยกว่าสำหรับเซสชันการถอดรหัสเสียง 128 kbps หรือบิตเรตต่ำกว่าสำหรับตัวถอดรหัสเสียงทั้งหมดเมื่ออยู่ในโหลด โหลดที่นี่ถูกกำหนดให้เป็นเซสชันการแปลงรหัสวิดีโออย่างเดียว 1080p ถึง 720p พร้อมกัน โดยใช้ตัวแปลงสัญญาณวิดีโอแบบฮาร์ดแวร์ร่วมกับการเริ่มต้นการเล่นเสียง-วิดีโอ 1080p
- [5.1/H-1-14] ต้องรองรับตัวถอดรหัสฮาร์ดแวร์ AV1 Main 10, ระดับ 4.1 และเนื้อฟิล์ม
- [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
- [5.1/H-1-16] ต้องมีตัวเข้ารหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
- [5.3/H-1-1] ต้องไม่ดรอปมากกว่า 1 เฟรมใน 10 วินาที (เช่น น้อยกว่า 0.167 เปอร์เซ็นต์ของเฟรมดรอป) สำหรับเซสชันวิดีโอ 4K 60 fps ภายใต้การโหลด
- [5.3/H-1-2] ต้องไม่ดรอปเกิน 1 เฟรมใน 10 วินาทีระหว่างการเปลี่ยนแปลงความละเอียดของวิดีโอในเซสชันวิดีโอ 60 fps ภายใต้การโหลดสำหรับเซสชัน 4K
- [5.6/H-1-1] ต้องมีความหน่วงของการแตะต่อโทน 80 มิลลิวินาทีหรือน้อยกว่าโดยใช้การทดสอบแตะต่อโทนของ CTS Verifier
- [5.6/H-1-2] ต้องมีเวลาแฝงของเสียงไปกลับที่ 80 มิลลิวินาทีหรือน้อยกว่าในเส้นทางข้อมูลที่รองรับอย่างน้อยหนึ่งเส้นทาง
- [5.6/H-1-3] ต้องรองรับเสียง >=24 บิตสำหรับเอาต์พุตสเตอริโอผ่านแจ็คเสียง 3.5 มม. หากมี และผ่านเสียง USB หากรองรับผ่านเส้นทางข้อมูลทั้งหมดเพื่อความหน่วงต่ำและการกำหนดค่าสตรีมมิ่ง สำหรับการกำหนดค่าเวลาแฝงต่ำ แอปควรใช้ AAudio ในโหมดโทรกลับเวลาแฝงต่ำ สำหรับการกำหนดค่าการสตรีม แอปควรใช้ 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 ช่องสัญญาณ (ซึ่งใช้โดยตัวควบคุม DJ สำหรับการดูตัวอย่างเพลง)
- [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่สอดคล้องกับคลาสและประกาศฟีเจอร์ MIDI
- [5.6/H-1-9] ต้องรองรับการผสมช่องสัญญาณอย่างน้อย 12 ช่อง นี่แสดงถึงความสามารถในการเปิด AudioTrack ด้วยมาสก์ช่อง 7.1.4 และปรับตำแหน่งหรือดาวน์มิกซ์ช่องทั้งหมดให้เป็นสเตอริโออย่างเหมาะสม
- [5.6/H-SR] ขอแนะนำอย่างยิ่งให้รองรับการผสมช่องสัญญาณ 24 ช่องและรองรับมาสก์ช่อง 9.1.6 และ 22.2 เป็นอย่างน้อย
- [5.7/H-1-2] ต้องรองรับ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
ด้วยความสามารถในการถอดรหัสเนื้อหาด้านล่างนี้
ขนาดตัวอย่างขั้นต่ำ | 4 มิ.ย |
จำนวนตัวอย่างย่อยขั้นต่ำ - H264 หรือ HEVC | 32 |
จำนวนตัวอย่างย่อยขั้นต่ำ - VP9 | 9 |
จำนวนตัวอย่างย่อยขั้นต่ำ - AV1 | 288 |
ขนาดบัฟเฟอร์ตัวอย่างย่อยขั้นต่ำ | 1 มิ.ย |
ขนาดบัฟเฟอร์การเข้ารหัสลับทั่วไปขั้นต่ำ | 500 กิโลไบต์ |
จำนวนเซสชันที่เกิดขึ้นพร้อมกันขั้นต่ำ | 30 |
จำนวนคีย์ขั้นต่ำต่อเซสชัน | 20 |
จำนวนคีย์ทั้งหมดขั้นต่ำ (ทุกเซสชัน) | 80 |
จำนวนคีย์ DRM ทั้งหมดขั้นต่ำ (ทุกเซสชัน) | 6 |
ขนาดข้อความ | 16 กิโลไบต์ |
เฟรมที่ถอดรหัสต่อวินาที | 60 เฟรมต่อวินาที |
- [5.1/H-1-17] ต้องมีตัวถอดรหัสฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ AVIF Baseline Profile
- [5.1/H-1-18] ต้องรองรับตัวเข้ารหัส AV1 ซึ่งสามารถเข้ารหัสความละเอียดสูงสุด 480p ที่ 30fps และ 1Mbps
-
[5.12/H-1-1] ขอแนะนำ [5.12/H-SR] อย่างยิ่งเพื่อรองรับคุณสมบัติFeature_HdrEditing
สำหรับฮาร์ดแวร์เข้ารหัส AV1 และ HEVC ทั้งหมดที่มีอยู่ในอุปกรณ์ - [5.12/H-1-2] ต้องรองรับรูปแบบสี RGBA_1010102 สำหรับฮาร์ดแวร์ตัวเข้ารหัส AV1 และ HEVC ทั้งหมดที่มีอยู่ในอุปกรณ์
- [5.12/H-1-3] ต้องโฆษณาการสนับสนุนสำหรับส่วนขยาย EXT_YUV_target เพื่อสุ่มตัวอย่างจากพื้นผิว YUV ทั้ง 8 และ 10 บิต
- [7.1.4/H-1-1] ต้องมีฮาร์ดแวร์ซ้อนทับอย่างน้อย 6 ตัวในหน่วยประมวลผลข้อมูล (DPU) ตัวเขียนฮาร์ดแวร์ (HWC) โดยอย่างน้อย 2 ตัวสามารถแสดงเนื้อหาวิดีโอ 10 บิตได้
หากการใช้งานอุปกรณ์มือถือส่งคืน android.os.Build.VERSION_CODES.U
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
และรวมถึงการรองรับตัวเข้ารหัส AVC หรือ HEVC ของฮาร์ดแวร์ การดำเนินการเหล่านั้น:
- [5.2/H-2-1] ต้องเป็นไปตามเป้าหมายคุณภาพขั้นต่ำที่กำหนดโดยเส้นโค้งอัตราการบิดเบือนของตัวเข้ารหัสวิดีโอสำหรับตัวแปลงสัญญาณ AVC และ HEVC ของฮาร์ดแวร์ ตามที่กำหนดไว้ในเอกสารประกอบที่กำลังจะมีขึ้น
ดูการแก้ไข
android.os.Build.VERSION_CODES.U
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
แสดงว่า:- [ 7.5 /H-1-1] ต้องมีกล้องหลังหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล รองรับการถ่ายวิดีโอที่ 4k@30fps กล้องด้านหลังหลักคือกล้องด้านหลังที่มีรหัสกล้องต่ำสุด
- [ 7.5 /H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 6 ล้านพิกเซล และรองรับการถ่ายวิดีโอที่ 1080p@30fps กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
- [ 7.5 /H-1-3] ต้องรองรับคุณสมบัติ
android.info.supportedHardwareLevel
เป็นแบบเต็มหรือดีกว่าสำหรับกล้องหลักทั้งสองตัว - [ 7.5 /H-1-4] ต้องรองรับ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
สำหรับกล้องหลักทั้งสองตัว - [ 7.5 /H-1-5] ต้องมีเวลาแฝงในการจับภาพ JPEG ของกล้อง < 1000
900ms สำหรับความละเอียด 1080p ซึ่งวัดโดยการทดสอบประสิทธิภาพของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้งสองตัว - [ 7.5 /H-1-6] ต้องมีเวลาแฝงในการเริ่มต้นของกล้อง2 (เปิดกล้องไปที่เฟรมแสดงตัวอย่างแรก) < 500 ms โดยวัดโดยการทดสอบประสิทธิภาพของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้งสองตัว
- [ 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
สำหรับทั้งกล้องหน้าและกล้องหลังหลัก - [ 7.5 /H-1-15] ต้องรองรับส่วนขยาย
Bokeh และโหมดกลางคืนผ่านส่วนขยาย CameraX และ Camera2 สำหรับกล้องหลัก - [ 7.5 /H-1-16] ต้องรองรับความสามารถ DYNAMIC_RANGE_TEN_BIT สำหรับกล้องหลัก
- [ 7.5 /H-1-17] ต้องรองรับ CONTROL_SCENE_MODE_FACE_PRIORITY และการตรวจจับใบหน้า ( STATISTICS_FACE_DETECT_MODE_SIMPLE หรือ STATISTICS_FACE_DETECT_MODE_FULL ) สำหรับกล้องหลัก
ดูการแก้ไข
android.os.Build.VERSION_CODES.U
สำหรับ 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.1.1.3/H-3-1] ต้องมีจอแสดงผล HDR ที่รองรับค่าเฉลี่ยอย่างน้อย 1,000 nits
- [7.6.1/H-2-1] ต้องมีหน่วยความจำกายภาพอย่างน้อย 8 GB
ดูการแก้ไข
android.os.Build.VERSION_CODES.U
สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
แสดงว่า:- [8.2/H-1-1] ต้องรับประกันประสิทธิภาพการเขียนตามลำดับอย่างน้อย 150 MB/s
- [8.2/H-1-2] ต้องแน่ใจว่าประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/s
- [8.2/H-1-3] ต้องรับประกันประสิทธิภาพการอ่านตามลำดับอย่างน้อย 250 MB/s
- [8.2/H-1-4] ต้องรับประกันประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 100 MB/s
- [8.2/H-1-5] ต้องรับประกันประสิทธิภาพการอ่านและเขียนตามลำดับแบบขนานด้วยประสิทธิภาพการอ่าน 2x และการเขียน 1x อย่างน้อย 50 MB/s
ดูการแก้ไข
การใช้งานอุปกรณ์โทรทัศน์จะต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และเปิดให้ใช้งานได้กับแอปพลิเคชันบุคคลที่สาม:
- [ 5.2 /T-0-3] AV1
การใช้งานอุปกรณ์โทรทัศน์จะต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และทำให้สามารถใช้งานได้กับแอปพลิเคชันบุคคลที่สาม:
- [ 5.3.2 /T-0-7] AV1
2.4.5. รูปแบบการรักษาความปลอดภัย :
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีหน้าจอล็อคที่ปลอดภัยและมีเอเจนต์ที่เชื่อถือได้อย่างน้อยหนึ่งรายการซึ่งใช้ TrustAgentService
System API พวกเขา:
- [ 9.11.1 /W-1-1] ต้องท้าทายผู้ใช้สำหรับหนึ่งในวิธีการรับรองความถูกต้องหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่าหนึ่งครั้งทุกๆ 72 ชั่วโมง
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับวิทยุกระจายเสียง AM/FM และเปิดเผยฟังก์ชันการทำงานแก่แอปพลิเคชันใดๆ พวกเขา:
- [ 7.4
.10/A-0-1] ต้องประกาศการสนับสนุนFEATURE_BROADCAST_RADIO
กล้องมองภาพภายนอกเป็นกล้องที่ถ่ายภาพฉากภายนอกการใช้งานอุปกรณ์ เช่น กล้องมองหลัง
การใช้งานอุปกรณ์ยานยนต์:
- ควรมีกล้องมองภาพภายนอกอย่างน้อยหนึ่งตัว
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภาพภายนอกด้วย สำหรับกล้องดังกล่าว พวกเขา:
- [ 7.5 /A-1-1] ต้องไม่มีกล้องมองภาพภายนอกที่สามารถเข้าถึงได้ผ่าน Android Camera APIs เว้นแต่จะเป็นไปตาม ข้อกำหนดหลัก ของกล้อง
- [ 7.5 /A-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าหมุนหรือสะท้อนภาพตัวอย่างกล้องในแนวนอน
- [ 7.5 /A-SR-2] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 ล้านพิกเซล
- ควรมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ขยายความชัดลึก)
- อาจมีการปรับโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือซอฟต์แวร์โฟกัสอัตโนมัติในไดรเวอร์กล้อง
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภาพภายนอกตั้งแต่หนึ่งตัวขึ้นไป และโหลดบริการระบบมุมมองภายนอก (EVS) สำหรับกล้องดังกล่าว พวกเขา:
- [ 7.5 /A-2-1] ต้องไม่หมุนหรือสะท้อนภาพตัวอย่างกล้องในแนวนอน
การใช้งานอุปกรณ์ยานยนต์:
- อาจมีกล้องตั้งแต่หนึ่งตัวขึ้นไปที่พร้อมใช้งานสำหรับแอปพลิเคชันบุคคลที่สาม
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อยหนึ่งตัวและทำให้สามารถใช้งานได้กับแอปพลิเคชันของบุคคลที่สาม พวกเขา:
- [ 7.5 /A-3-1] ต้องรายงานการตั้งค่าสถานะคุณลักษณะ
android.hardware.camera.any
- [ 7.5 /A-3-2] ต้องไม่ประกาศว่ากล้องเป็น กล้องระบบ
- อาจรองรับกล้องภายนอกที่อธิบายไว้ใน ส่วน 7.5.3
- อาจมีคุณลักษณะต่างๆ (เช่น โฟกัสอัตโนมัติ ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ใน ส่วน 7.5.1
กล้องด้านหลังหมายถึงกล้องที่หันหน้าไปทางโลกซึ่งสามารถติดตั้งได้ทุกที่บนรถและหันหน้าไปทางด้านนอกห้องโดยสารของรถ นั่นคือภาพฉากที่อยู่อีกด้านของตัวรถ เช่น กล้องมองหลัง
กล้องหน้าหมายถึงกล้องที่หันหน้าเข้าหาผู้ใช้ซึ่งสามารถติดตั้งไว้ที่ใดก็ได้บนรถและหันหน้าไปทางภายในห้องโดยสารของรถ นั่นคือรูปภาพของผู้ใช้ เช่น สำหรับการประชุมทางวิดีโอและแอปพลิเคชันที่คล้ายกัน
การใช้งานอุปกรณ์ยานยนต์:
- [7.5/A-SR-1] ขอแนะนำอย่างยิ่งให้รวมกล้องหันหน้าไปทางโลกอย่างน้อย 1 ตัว
- อาจมีกล้องหันหน้าเข้าหาผู้ใช้อย่างน้อยหนึ่งตัว
- [7.5/A-SR-2] ขอแนะนำอย่างยิ่งเพื่อรองรับการสตรีมพร้อมกันของกล้องหลายตัว
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อยหนึ่งตัวที่หันหน้าไปทางโลก สำหรับกล้องดังกล่าว พวกเขา:
- [7.5/A-1-1] ต้องวางแนวเพื่อให้มิติด้านยาวของกล้องอยู่ในแนวเดียวกับระนาบ XY ของแกนเซ็นเซอร์ยานยนต์ Android
- [7.5/A-SR-3] ขอแนะนำอย่างยิ่งให้มีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (Extensed Depth of Field)
- [7.5/A-1-2] ต้องมีกล้องหันหน้าไปทางโลกหลักเป็นกล้องหันหน้าไปทางโลกซึ่งมี ID กล้องต่ำที่สุด
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องที่หันหน้าไปทางผู้ใช้อย่างน้อยหนึ่งตัว สำหรับกล้องดังกล่าว:
- [7.5/A-2-1] กล้องหันหน้าเข้าหาผู้ใช้หลักต้องเป็นกล้องหันหน้าเข้าหาผู้ใช้ซึ่งมี ID กล้องต่ำสุด
- อาจจัดวางเพื่อให้มิติด้านยาวของกล้องอยู่ในแนวเดียวกับระนาบ XY ของแกนเซ็นเซอร์ยานยนต์ Android
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องที่สามารถเข้าถึงได้ผ่าน android.hardware.Camera
หรือ android.hardware.camera2
API พวกเขาจะ:
- [7.5/A-3-1] ต้องเป็นไปตามข้อกำหนดหลักของกล้องในหัวข้อ 7.5
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องที่ไม่สามารถเข้าถึงได้ผ่าน android.hardware.Camera
หรือ android.hardware.camera2
API แสดงว่าอุปกรณ์เหล่านั้น:
- [7.5/A-4-1] ต้องสามารถเข้าถึงได้ผ่านบริการ Extended View System
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องตั้งแต่หนึ่งตัวขึ้นไปที่สามารถเข้าถึงได้ผ่าน Extended View System Service สำหรับกล้องดังกล่าว พวกเขา:
- [7.5/A-5-1] ต้องไม่หมุนหรือสะท้อนภาพตัวอย่างกล้องในแนวนอน
- [7.5/A-SR-4] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 ล้านพิกเซล
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องตั้งแต่หนึ่งตัวขึ้นไปที่สามารถเข้าถึงได้ผ่านทาง Extended View System Service และ android.hardware.Camera
หรือ android.hardware.Camera2
API สำหรับกล้องดังกล่าว พวกเขา:
- [7.5/A-6-1] ต้องรายงานรหัสกล้องเดียวกัน
หากการใช้งานอุปกรณ์ยานยนต์มี API ของกล้องที่เป็นกรรมสิทธิ์ พวกเขา:
- [7.5/A-7-1] ต้องใช้ API ของกล้องดังกล่าวโดยใช้
android.hardware.camera2
API หรือ Extended View System API
ดูการแก้ไข
การใช้งานอุปกรณ์ยานยนต์:
- [ 3.8 /A-0-1] ต้องไม่อนุญาตให้ผู้ใช้รองแบบเต็มที่ไม่ใช่ผู้ใช้เบื้องหน้าปัจจุบันเปิดกิจกรรมและมีสิทธิ์เข้าถึง UI บนจอแสดงผลใดๆ
2.5.5. รูปแบบการรักษาความปลอดภัย :
ดูการแก้ไข
หากการใช้งานอุปกรณ์ยานยนต์ประกาศ android.hardware.microphone
พวกเขา:
- [ 9.8.2 /A-1-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ใช่เมื่อเข้าถึงไมโครโฟนโดย
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
หรือแอปที่มีบทบาทที่เรียกใน ส่วนนี้ เท่านั้น 9.1 พร้อมตัวระบุ CDD [C-4-X] - [ 9.8.2 /A-1-2] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบกับผู้ใช้โดยตรง
- [ 9.8.2 /A-1-3] ต้องให้สิทธิ์ผู้ใช้ในการสลับไมโครโฟนในแอปการตั้งค่า
หากการใช้งานอุปกรณ์ยานยนต์ประกาศ android.hardware.camera.any
แสดงว่า:
- [ 9.8.2 /A-2-1] ต้องแสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องถ่ายทอดสด แต่ไม่ใช่เมื่อเข้าถึงกล้องโดยแอปที่มีบทบาทตามที่
กำหนดไว้ใน หัวข้อ 9.1 สิทธิ์ เท่านั้น พร้อมตัวระบุ CDD [C-4-X][C-3-X]
หากการใช้งานอุปกรณ์มีหน้าจอล็อคที่ปลอดภัยและมีเอเจนต์ที่เชื่อถือได้อย่างน้อยหนึ่งรายการซึ่งใช้ TrustAgentService
System API พวกเขา:
- [ 9.11.1 /A-1-1] ต้องท้าทายผู้ใช้สำหรับหนึ่งในวิธีการรับรองความถูกต้องหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่าหนึ่งครั้งทุกๆ 336 ชั่วโมง
3. ซอฟต์แวร์
3.1. ความเข้ากันได้ของ API ที่มีการจัดการ :
ดูการแก้ไข
การใช้งานอุปกรณ์:
- [C-0-8] ต้องไม่รองรับการติดตั้งแอปพลิเคชันที่กำหนดเป้าหมายระดับ API น้อยกว่า 23
3.2.3.5. จุดประสงค์การใช้งานแบบมีเงื่อนไข :
ดูการแก้ไข
หากการใช้งานอุปกรณ์รายงาน
android.hardware.nfc.uicc
หรือandroid.hardware.nfc.ese
พวกเขา:- [C-19-1] ต้องใช้ NFCADAPTER.ACTION_TRANSACTION_DETETECTENT API (เช่น“ EVT_TRANSACTION” ที่กำหนดโดย ข้อกำหนดทางเทคนิคของสมาคม GSM TS.26-ข้อกำหนดโทรศัพท์มือถือ NFC)
3.3.1. อินเทอร์เฟซไบนารีแอปพลิเคชัน :
ดูการแก้ไข
การใช้งานอุปกรณ์:
- [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชั่นสำหรับ Core
libvulkan.so
1.0Vulkan 1.1 สัญลักษณ์ฟังก์ชั่นเช่นเดียวกับVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
VK_KHR_get_physical_device_properties2
. โปรดทราบว่าในขณะที่สัญลักษณ์ทั้งหมดจะต้องมีอยู่ หัวข้อ 7.1.4.2 อธิบายรายละเอียดเพิ่มเติมเกี่ยวกับข้อกำหนดสำหรับเมื่อคาดว่าจะมีการใช้งานเต็มรูปแบบของแต่ละฟังก์ชั่นที่เกี่ยวข้อง
- [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชั่นสำหรับ Core
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงหน้าจอหรือเอาต์พุตวิดีโอพวกเขา:
- [C-1-5] ต้องสร้างจาน
FRUIT_SALAD
โทนสีRAINBOW
ไดนามิกโดยใช้EXPRESSIVE
ชุดรูปแบบสีที่ระบุในVIBRANT
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
TONAL_SPOT
SPRITZ
ดูandroid.theme.customization.theme_styles
) คือMONOCHROMATIC
.
- [C-1-5] ต้องสร้างจาน
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงคีย์การนำทางฟังก์ชัน Recents ตามรายละเอียดใน ส่วน 7.2.3 เปลี่ยนอินเทอร์เฟซพวกเขา:
- [C-1-2] ต้องใช้ พฤติกรรมการตรึงหน้าจอ และให้เมนูการตั้งค่าให้ผู้ใช้เพื่อสลับคุณสมบัติ
3.9.2 การสนับสนุนโปรไฟล์ที่มีการจัดการ :
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศ
android.software.managed_users
พวกเขา:- [C-1-10] ต้องตรวจสอบให้แน่ใจว่าข้อมูลภาพหน้าจอถูกบันทึกไว้ในที่เก็บข้อมูลโปรไฟล์การทำงานเมื่อภาพหน้าจอถูกจับด้วยหน้าต่าง
topActivity
ที่มี โฟกัส (ผู้ใช้ที่มีปฏิสัมพันธ์กับกิจกรรมทั้งหมด) และเป็นของ โปรไฟล์การทำงาน แอป . - [C-1-1-11] จะต้องไม่จับเนื้อหาหน้าจออื่น ๆ (แถบระบบการแจ้งเตือนหรือเนื้อหาโปรไฟล์ส่วนบุคคลใด ๆ ) ยกเว้น หน้าต่างแอปพลิเคชันโปรไฟล์การทำงาน/หน้าต่าง เมื่อบันทึกภาพหน้าจอไปยังโปรไฟล์การทำงาน (เพื่อให้แน่ใจว่าข้อมูลโปรไฟล์ส่วนบุคคลคือ ไม่ได้บันทึกไว้ในโปรไฟล์การทำงาน)
- [C-1-10] ต้องตรวจสอบให้แน่ใจว่าข้อมูลภาพหน้าจอถูกบันทึกไว้ในที่เก็บข้อมูลโปรไฟล์การทำงานเมื่อภาพหน้าจอถูกจับด้วยหน้าต่าง
3.9.5 กรอบการแก้ไขนโยบายอุปกรณ์ : ส่วนใหม่
ดูการแก้ไข
หากการใช้งานอุปกรณ์รายงาน
android.software.device_admin
หรือandroid.software.managed_users
พวกเขา:- [C-1-1] ต้องแก้ไขความขัดแย้งของนโยบายอุปกรณ์ตามที่บันทึกไว้ในเอกสาร AOSP
5. ความเข้ากันได้ของมัลติมีเดีย
ดูการแก้ไข
การใช้งานอุปกรณ์จะต้องรองรับการเข้ารหัสการเข้ารหัสภาพต่อไปนี้:
- [C-0-4] avif
- อุปกรณ์จะต้องรองรับ
BITRATE_MODE_CQ
และโปรไฟล์พื้นฐาน
- อุปกรณ์จะต้องรองรับ
- [C-0-4] avif
ดูการแก้ไข
การใช้งานอุปกรณ์จะต้องรองรับการถอดรหัสการเข้ารหัสภาพต่อไปนี้:
[C-0-7] AVIF (โปรไฟล์พื้นฐาน)
5.1.6. รายละเอียดตัวแปลงสัญญาณรูปภาพ :
ดูการแก้ไข
รูปแบบ/ตัวแปลงสัญญาณ รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ เจเพ็ก ฐาน+ก้าวหน้า jpeg (.jpg) กิฟ gif (.gif) PNG png (.png) บีเอ็มพี BMP (.BMP) เว็บพี 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) avif (โปรไฟล์พื้นฐาน) รูปภาพ, คอลเลกชันรูปภาพ, ลำดับภาพพื้นฐานของภาพ คอนเทนเนอร์ heif (.avif) 5.1.8. รายการตัวแปลงสัญญาณวิดีโอ :
ดูการแก้ไข
รูปแบบ/ตัวแปลงสัญญาณ รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ H.263 - 3GPP (.3GP)
- MPEG-4 (.MP4)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
H.264 AVC ดู หัวข้อ 5.2 และ 5.3 สำหรับรายละเอียด - 3GPP (.3GP)
- MPEG-4 (.MP4)
- MPEG-2 TS (.TS ไม่สามารถหาได้)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
H.265 HEVC ดู หัวข้อ 5.3 สำหรับรายละเอียด - MPEG-4 (.MP4)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
MPEG-2 โปรไฟล์หลัก - MPEG2-TS (.TS ไม่สามารถหาได้)
- MPEG-4 (.MP4, ถอดรหัสเท่านั้น)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
MPEG-4 SP - 3GPP (.3GP)
- MPEG-4 (.MP4)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
วีพี8 ดู หัวข้อ 5.2 และ 5.3 สำหรับรายละเอียด - Webm (.webm)
- Matroska (.MKV)
วีพี9 ดู หัวข้อ 5.3 สำหรับรายละเอียด - Webm (.webm)
- Matroska (.MKV)
เอวี1 ดู หัวข้อ 5.2 และ ส่วน 5.3 สำหรับรายละเอียด - MPEG-4 (.MP4)
- Matroska (.MKV, ถอดรหัสเท่านั้น)
5.1.10. การจำแนกตัวแปลงสัญญาณสื่อ :
ดูการแก้ไข
หากการใช้งานอุปกรณ์สนับสนุนตัวแปลงสัญญาณวิดีโอ:
- [C-2-1] ตัวแปลงสัญญาณวิดีโอทั้งหมดจะต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้หากรองรับโดยตัวแปลงสัญญาณ:
SD (คุณภาพต่ำ) SD (คุณภาพสูง) เอชดี 720p เอชดี 1080p ยูเอชดี ความละเอียดวิดีโอ - 176 x 144 PX (H263, MPEG2, MPEG4)
- 352 x 288 px (MPEG4 encoder, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (อื่น ๆ )
- 704 x 576 px (H263)
- 640 x 360 PX (VP8, VP9)
- 640 x 480 px (MPEG4 encoder)
- 720 x 480 px (อื่น ๆ , av1 )
- 1408 x 1152 px (H263)
- 1280 x 720 px (อื่น ๆ , av1 )
1920 x 1080 px (นอกเหนือจาก MPEG4, AV1 ) 3840 x 2160 PX (HEVC, VP9, AV1 ) ดูการแก้ไข
หากการใช้งานอุปกรณ์สนับสนุนการเข้ารหัสวิดีโอใด ๆ และทำให้สามารถใช้งานได้กับแอพของบุคคลที่สามพวกเขา:- ไม่ควรเป็นหน้าต่างเลื่อนมากกว่าสองหน้าต่างมากกว่า 15% เหนือบิตเรตระหว่างช่วงเวลาระหว่างเฟรม (เฟรม i-frame)
- ไม่ควรเกิน 100% เหนือบิตเรตผ่านหน้าต่างเลื่อน 1 วินาที
หากการใช้งานอุปกรณ์สนับสนุนการเข้ารหัสวิดีโอใด ๆ และทำให้สามารถใช้งานได้กับแอพของบุคคลที่สามและตั้งค่า
MediaFormat.KEY_BITRATE_MODE
เป็นBITRATE_MODE_VBR
เพื่อให้ตัวเข้ารหัสทำงานในโหมดบิตเรตตัวแปรจากนั้นตราบใดที่มันไม่ส่งผลกระทบต่อ พื้นคุณภาพขั้นต่ำ บิตเรตที่เข้ารหัส:-
[C-5-1] ไม่ควรเป็น มากกว่าหนึ่งหน้าต่างเลื่อนมากกว่า 15% เหนือบิตเรตระหว่างช่วงเวลา intraframe (i-frame) -
[C-5-2] ต้องไม่ เกิน 100% เหนือบิตเรตผ่านหน้าต่างเลื่อน 1 วินาที
หากการใช้งานอุปกรณ์รองรับการเข้ารหัสวิดีโอใด ๆ และทำให้สามารถใช้งานได้กับแอพของบุคคลที่สามและตั้ง
MediaFormat.KEY_BITRATE_MODE
เป็นBITRATE_MODE_CBR
ดังนั้นตัวเข้ารหัสจะทำงานในโหมดบิตเรตคงที่จากนั้นบิตเรตที่เข้ารหัส:-
[C-6-1] ต้องแนะนำให้ใช้ [C-SR-2] อย่างยิ่งว่าจะ ไม่เกิน 15% มากกว่าบิตเรตเป้าหมายผ่านหน้าต่างเลื่อน 1 วินาที
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับการเข้ารหัส H.263 และทำให้สามารถใช้งานได้กับแอพของบุคคลที่สามพวกเขา:
- [C-1-1] ต้องรองรับ ความละเอียด QCIF (176 x 144) โดยใช้ ระดับโปรไฟล์พื้นฐาน 45 ความละเอียด SQCIF เป็นทางเลือก
-
ควรรองรับบิตเรตที่กำหนดค่าได้แบบไดนามิกสำหรับตัวเข้ารหัสที่รองรับ
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับ H.265 Codec พวกเขา:
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3 ถึง 512 x 512 ความละเอียด
-
ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ - [C-SR-1] ขอแนะนำอย่างยิ่งเพื่อสนับสนุน โปรไฟล์ 720 x 480 SD และ โปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีตัวเข้ารหัสฮาร์ดแวร์
5.2.6 AV1 : ส่วนใหม่
ดูการแก้ไข
หากการใช้งานอุปกรณ์สนับสนุนตัวแปลงสัญญาณ AV1 แล้วพวกเขา:
- [C-1-1] ต้องสนับสนุนโปรไฟล์หลักรวมถึงเนื้อหา 8 บิตและ 10 บิต
[C-1-2] ต้องเผยแพร่ข้อมูลประสิทธิภาพเช่นรายงานข้อมูลประสิทธิภาพผ่าน
getSupportedFrameRatesFor()
หรือgetSupportedPerformancePoints()
APIs สำหรับความละเอียดที่รองรับในตารางด้านล่าง[C-1-3] ต้องยอมรับข้อมูลเมตา HDR และส่งออกไปยังบิตสตรีม
หาก encoder AV1 เป็นฮาร์ดแวร์เร่งความเร็วแล้ว:
- [C-2-1] ต้องรองรับและรวมถึงโปรไฟล์การเข้ารหัส HD1080p จากตารางด้านล่าง:
เอสดี เอชดี 720p เอชดี 1080p ยูเอชดี ความละเอียดวิดีโอ 720 x 480 px 1280x720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล อัตราเฟรมวิดีโอ 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที บิตเรตของวิดีโอ 5Mbps 8 Mbps 16 Mbps 50 Mbps ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับตัวถอดรหัส H.263 พวกเขา:
- [C-1-1] ต้องรองรับระดับโปรไฟล์พื้นฐาน 30 (CIF, QCIF และ SQCIF ความละเอียด @ 30FPS 384KBPS) และระดับ 45 (ความละเอียด QCIF และ SQCIF @ 30FPS 128KBPS)
ดูการแก้ไข
หากการใช้งานอุปกรณ์สนับสนุนตัวแปลงสัญญาณ AV1 พวกเขา:- [C-1-1] ต้องสนับสนุนโปรไฟล์ 0 รวมเนื้อหา 10 บิต
หากการใช้งานอุปกรณ์สนับสนุนตัวแปลงสัญญาณ AV1 และทำให้สามารถใช้งานได้กับแอปพลิเคชันของบุคคลที่สามพวกเขา:
- [C-1-1] ต้องสนับสนุนโปรไฟล์หลักรวมถึงเนื้อหา 8 บิตและ 10 บิต
หากการใช้งานอุปกรณ์ให้การสนับสนุนสำหรับตัวแปลงสัญญาณ AV1 ด้วยตัวถอดรหัสฮาร์ดแวร์เร่งให้พวกเขา:
- [C-2-1] จะต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 720p ได้อย่างน้อยจากตารางด้านล่างเมื่อความสูงที่รายงานโดย
Display.getSupportedModes()
มีค่าเท่ากับหรือมากกว่า 720p - [C-2-2] จะต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ได้อย่างน้อยจากตารางด้านล่างเมื่อความสูงที่รายงานโดย
Display.getSupportedModes()
มีค่าเท่ากับหรือมากกว่า 1080p
เอสดี เอชดี 720p เอชดี 1080p ยูเอชดี ความละเอียดวิดีโอ 720 x 480 px 1280x720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล อัตราเฟรมวิดีโอ 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที 30 เฟรมต่อวินาที บิตเรตของวิดีโอ 5Mbps 8 Mbps 16 Mbps 50 Mbps หากการใช้งานอุปกรณ์สนับสนุนโปรไฟล์ HDR ผ่านสื่อ API แล้วพวกเขา:
- [C-3-1] ต้องรองรับการสกัดและส่งออกข้อมูลเมตา HDR จากบิตสตรีมและ/หรือคอนเทนเนอร์
- [C-3-2] ต้องแสดงเนื้อหา HDR อย่างถูกต้องบนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (ตัวอย่างเช่น HDMI)
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศ
android.hardware.microphone
พวกเขา:- ควรตั้งค่าความไวของอินพุตเสียงเช่นแหล่งโทนเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง 90 เดซิเบล (SPL) (วัด
ที่ระยะทาง 30 ซม. จากถัดจาก ไมโครโฟน) ให้การตอบสนองที่เหมาะสมที่สุดของ RMS 2500 ภายในช่วง 1770 และ 3530 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB ± 3dB สเกลสำหรับตัวอย่างจุดลอยตัว/สองตัวอย่าง) สำหรับไมโครโฟนแต่ละตัวและทุกไมโครโฟนที่ใช้ในการบันทึกแหล่งกำเนิดเสียงการจดจำเสียง
- ควรตั้งค่าความไวของอินพุตเสียงเช่นแหล่งโทนเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง 90 เดซิเบล (SPL) (วัด
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศคุณสมบัติ
android.hardware.audio.output
พวกเขา:- [C-1-4] ต้องรองรับ เอฟเฟกต์เสียง ด้วยอินพุตและเอาต์พุตแบบลอยตัว
- [C-1-5] ต้องตรวจสอบให้แน่ใจว่าเอฟเฟกต์เสียงรองรับหลายช่องทางจนถึงจำนวนช่องสัญญาณผสมหรือที่เรียกว่า FCC_LIMIT
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศ
android.hardware.audio.output
พวกเขาขอแนะนำอย่างยิ่งให้ตรงตามหรือเกินข้อกำหนดดังต่อไปนี้:- [C-SR-4] การประทับเวลาการส่งออกที่ส่งคืนโดย Audiotrack.GetTimestamp และ
AAudioStream_getTimestamp
นั้นแม่นยำถึง +/- 1 ms
- [C-SR-4] เวลาแฝงการเดินทางไปกลับที่คำนวณได้ตามการประทับเวลาอินพุตและเอาต์พุตที่ส่งคืนโดย
AAudioStream_getTimestamp
ได้รับการAAUDIO_PERFORMANCE_MODE_NONE
อย่างยิ่งให้อยู่ในระยะเวลา 30 มิลลิวินาทีของเวลาแฝงAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
เดินทางไปกลับที่วัดได้
- [C-SR-4] การประทับเวลาการส่งออกที่ส่งคืนโดย Audiotrack.GetTimestamp และ
7. ความเข้ากันได้ของฮาร์ดแวร์
ดูการแก้ไข
Android มีสิ่งอำนวยความสะดวกที่ปรับสินทรัพย์แอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติสำหรับอุปกรณ์เพื่อให้แน่ใจว่าแอปพลิเคชันของบุคคลที่สามทำงานได้ดีใน
การกำหนดค่าฮาร์ดแวร์ที่หลากหลายความหลากหลายของฮาร์ดแวร์แสดงและการกำหนดค่า จอแสดงผลที่เข้ากันได้กับ Android เป็นหน้าจอแสดงผลที่ใช้พฤติกรรมและ APIs ทั้งหมดที่อธิบายไว้ใน นักพัฒนา Android-ภาพรวมความเข้ากันได้ของหน้าจอ ส่วนนี้ (7.1) และส่วนย่อยรวมถึงพฤติกรรมเฉพาะประเภทอุปกรณ์เพิ่มเติมที่บันทึกไว้ในส่วนที่ 2 ของส่วนที่ 2 ของ ส่วนที่ 2 ของส่วนที่ 2 CDD นี้บนจอแสดงผลที่เข้ากันได้กับ Android ซึ่งแอปพลิเคชันที่เข้ากันได้กับ Android ของบุคคลที่สามทั้งหมดสามารถเรียกใช้งานได้การใช้งานอุปกรณ์จะต้องใช้ API และพฤติกรรมเหล่านี้อย่างถูกต้องตามรายละเอียดในส่วนนี้เริ่มข้อกำหนดใหม่
การใช้งานอุปกรณ์:
- [C-0-1] จะต้องแสดงแอปพลิเคชั่นบุคคลที่สามโดยค่าเริ่มต้นเท่านั้นบนจอแสดงผลที่เข้ากันได้กับ Android เท่านั้น
หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้มีการกำหนดดังนี้:
- ขนาดเส้นทแยงมุมทางกายภาพ ระยะทางเป็นนิ้วระหว่างสองมุมตรงข้ามของส่วนที่ส่องสว่างของจอแสดงผล
- จุด
ต่อนิ้ว (DPI)จำนวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนเชิงเส้นหรือแนวตั้ง 1” แสดงเป็นพิกเซลต่อนิ้ว (PPI หรือ DPI) โดยที่ค่าDPIPPI และ DPI มีการระบุไว้ทั้ง DPI แนวนอนและแนวตั้งจะต้องอยู่ในช่วง ที่ระบุไว้ - อัตราส่วนภาพ อัตราส่วนของพิกเซลของมิติที่ยาวขึ้นต่อมิติที่สั้นลงของหน้าจอ ตัวอย่างเช่นการแสดงผล 480x854 พิกเซลจะเป็น 854/480 = 1.779 หรือประมาณ“ 16: 9”
- พิกเซลที่ไม่ขึ้นกับความหนาแน่น (DP)
หน่วยพิกเซลเสมือน จริง ที่ทำให้เป็นมาตรฐานความหนาแน่นของหน้าจอหน้าจอ 160 dpiที่ 160 สำหรับความหนาแน่น D และจำนวนพิกเซลจำนวน P, จำนวนพิกเซลที่มีความหนาแน่นอิสระ DP คำนวณเป็น:พิกเซล = DPS * (ความหนาแน่น/160)dp = (160 / d) * p
7.1.1.1. ขนาดหน้าจอและรูปร่าง :
ดูการแก้ไข
หากการใช้งานอุปกรณ์รองรับ หน้าจอที่มีความสามารถใน การกำหนดค่าขนาด
UI_MODE_TYPE_NORMAL
และรวมถึง การใช้งานทางกายภาพที่เข้ากันได้กับ Androidพร้อมมุมโค้งมน เพื่อแสดงหน้าจอเหล่านี้ พวกเขา:- [C-1-1] ต้องตรวจสอบให้แน่ใจว่ามีการปฏิบัติตามข้อกำหนดอย่างน้อยหนึ่งข้อต่อไปนี้ สำหรับแต่ละจอแสดงผลดังกล่าว :
- รัศมีของมุมโค้งมนน้อยกว่าหรือเท่ากับ 38 dp
เมื่อกล่อง 15 dp ถึง 15 dp ถูกยึดที่แต่ละมุมของจอแสดงผลเชิงตรรกะอย่างน้อยหนึ่งพิกเซลของแต่ละกล่องจะปรากฏบนหน้าจอ
ควรรวมถึงการจ่ายของผู้ใช้เพื่อเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยม
เริ่มข้อกำหนดใหม่
หากการใช้งานอุปกรณ์มีความสามารถในการกำหนดค่าคีย์บอร์ด
NO_KEYS
เท่านั้นและตั้งใจที่จะรายงานการสนับสนุนสำหรับการกำหนดค่าโหมด UIUI_MODE_TYPE_NORMAL
UI พวกเขา:- [C-4-1] ต้องมีขนาดเลย์เอาต์ไม่รวมการแสดงผลการแสดงผลอย่างน้อย 596 dp x 384 dp หรือมากกว่า
หากการใช้งานอุปกรณ์รวมถึงจอแสดงผลที่เข้ากันได้กับ Android ที่สามารถพับได้หรือรวมถึงบานพับพับระหว่างแผงแสดงผลหลายแผงและทำให้การแสดงดังกล่าวพร้อมใช้งานเพื่อแสดงแอพของบุคคลที่สามพวกเขา:
- [C-2-1] ต้องใช้รุ่นที่มีเสถียรภาพล่าสุดของ Extensions API หรือรุ่น Sidecar API ที่เสถียรเพื่อใช้โดย Window Manager Jetpack Library
หากการใช้งานอุปกรณ์รวมถึงจอแสดงผลที่เข้ากันได้กับ Android ที่สามารถพับได้หรือรวมถึงบานพับพับระหว่างแผงแสดงผลหลายแผงและหากบานพับหรือพับข้ามหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอพวกเขา:
- [C-3-1] ต้องรายงานตำแหน่งขอบเขตและสถานะของบานพับหรือพับผ่านส่วนขยายหรือ APIs ด้านข้างไปยังแอปพลิเคชัน
หากการใช้งานอุปกรณ์รวมถึงพื้นที่แสดงผลที่เข้ากันได้กับ Android หนึ่งพื้นที่ที่สามารถพับได้หรือรวมถึงบานพับพับระหว่างพื้นที่แสดงผลที่เข้ากันได้กับ Android หลายแห่งและทำให้พื้นที่แสดงผลดังกล่าวมีให้กับแอปพลิเคชัน
- [C-4-1] จะต้องใช้เวอร์ชันที่ถูกต้องของระดับ Window Manager Extensions API ตามที่อธิบายไว้ในเอกสารที่กำลังจะมาถึง
7.1.1.2. อัตราส่วนหน้าจอ : ลบออก
7.1.1.3. ความหนาแน่นของหน้าจอ :
ดูการแก้ไข
การใช้งานอุปกรณ์:
- [C-0-1]
โดยค่าเริ่มต้นการใช้งานอุปกรณ์จะต้องรายงานความหนาแน่นของเฟรมเวิร์ก Androidเพียงหนึ่งรายการที่แสดงอยู่ในDisplayMetrics
ผ่านDENSITY_DEVICE_STABLE
API และค่านี้ จะต้องเป็นค่าคงที่สำหรับการแสดงผลทางกายภาพแต่ละครั้งจะต้องไม่เปลี่ยนแปลงได้ตลอดเวลา อย่างไรก็ตามอุปกรณ์อาจรายงานDisplayMetrics.density
ที่แตกต่างกันความหนาแน่นตามการเปลี่ยนแปลงการ กำหนด ค่าการแสดงผลที่ทำโดยผู้ใช้ (ตัวอย่างเช่นขนาดการแสดงผล) ตั้งค่าหลังจากการบูตครั้งแรก
- การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพของหน้าจอมากที่สุดเว้นแต่ความหนาแน่นเชิงตรรกะจะผลักขนาดหน้าจอที่รายงานต่ำกว่าขั้นต่ำที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพมากที่สุดส่งผลให้ขนาดหน้าจอที่เล็กกว่าขนาดหน้าจอที่รองรับขนาดเล็กที่สุด (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานต่ำสุดถัดไป
เริ่มข้อกำหนดใหม่
- ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพของหน้าจอหรือค่าที่จะแมปกับการวัดมุมมองเชิงมุมของอุปกรณ์พกพาที่เทียบเท่ากับอุปกรณ์พกพา
หาก การใช้งานอุปกรณ์
มีความสามารถในการเปลี่ยนขนาดการแสดงผลของอุปกรณ์ พวกเขา :- [C-1-1]
ขนาดการแสดงผลจะต้องไม่ถูกปรับขนาดใด ๆจะต้องไม่ปรับขนาดจอแสดงผล ที่มีขนาดใหญ่กว่า 1.5 เท่าDENSITY_DEVICE_STABLE
ความหนาแน่นดั้งเดิมหรือสร้างมิติหน้าจอขั้นต่ำที่มีประสิทธิภาพน้อยกว่า 320DP (เทียบเท่ากับ Resource Qualifier SW320DP) - [C-1-2]
ขนาดการแสดงผลจะต้องไม่ถูกปรับขนาดใด ๆจะต้องไม่ปรับขนาดจอแสดงผล ที่เล็กกว่า 0.85 เท่าของความหนาแน่นความหนาแน่นDENSITY_DEVICE_STABLE
ความหนาแน่นดั้งเดิม
- [C-0-1]
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ Vulkan
1.0 หรือสูงกว่าพวกเขา:[C-1-3] จะต้องใช้
Vulkan 1.0Vulkan 1.1 APIs อย่างเต็มที่สำหรับแต่ละVkPhysicalDevice
ที่แจกแจง[C-1-5] จะต้องไม่ระบุเลเยอร์ที่จัดทำโดยไลบรารีนอกแพ็คเกจแอปพลิเคชันหรือให้วิธีการอื่น ๆ ในการติดตามหรือสกัดกั้น API Vulkan
true
แอ ปพลิcom.android.graphics.injectLayers.enable
จะ มีandroid:debuggable
com.android.graphics.injectLayers.enable
ตั้งค่าเป็นtrue
- ควรรองรับ
VkPhysicalDeviceProtectedMemoryFeatures
และVK_EXT_global_priority
- [C-1-1-13] จะต้องเป็นไปตามข้อกำหนดที่ระบุโดย โปรไฟล์ Android Baseline 2021
[C-SR-5] ขอแนะนำอย่างยิ่งเพื่อสนับสนุน
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
และVK_EXT_global_priority
[C-SR-6] ขอแนะนำอย่างยิ่งให้ใช้
SkiaVk
กับ HWUI
หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ Vulkan 1.1 และประกาศธงฟีเจอร์ Vulkan ใด ๆ ที่อธิบายไว้ ที่นี่ พวกเขา:
- [C-SR-7] ขอแนะนำอย่างยิ่งในการทำให้ส่วนขยาย
VK_KHR_external_fence_fd
มีให้กับแอปพลิเคชันบุคคลที่สามและเปิดใช้งานแอปพลิเคชันเพื่อส่งออก Payload รั้วและนำเข้าเพย์โหลดรั้วจากตัวบ่งชี้ไฟล์ POSIX ตามที่อธิบายไว้ ที่นี่
7.3.10. เซ็นเซอร์ไบโอเมตริกซ์ :
ดูการแก้ไข
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกซ์หลายตัวพวกเขา:
[C-7-1] ต้องเมื่อไบโอเมตริกซ์อยู่ในการล็อค (เช่นไบโอเมตริกซ์ถูกปิดใช้งานจนกว่าผู้ใช้จะปลดล็อคด้วยการตรวจสอบหลัก) หรือการล็อคเวลาที่มีการผูกมัดเวลา (เช่นไบโอเมตริกซ์จะถูกปิดใช้งานชั่วคราวจนกว่าผู้ใช้จะรอช่วงเวลา) เนื่องจากความพยายามที่ล้มเหลวมากเกินไปจึงล็อคชีวภาพอื่น ๆ ทั้งหมดของคลาสไบโอเมตริกซ์ที่ต่ำกว่า ในกรณีของการล็อคเวลาตามเวลาเวลา backoff สำหรับการตรวจสอบไบโอเมตริกซ์จะต้องเป็นเวลา backoff สูงสุดของ biometrics ทั้งหมดในการล็อคเวลาที่กำหนดเวลา
[C-SR-12] ขอแนะนำอย่างยิ่งเมื่อไบโอเมตริกซ์อยู่ในการล็อค (เช่นไบโอเมตริกซ์จะถูกปิดใช้งานจนกว่าผู้ใช้จะปลดล็อคด้วยการตรวจสอบหลักหลัก) หรือการล็อคแบบกำหนดเวลา (เช่นไบโอเมตริกซ์จะถูกปิดใช้งานชั่วคราวจนกว่าผู้ใช้จะรอเวลา ช่วงเวลา) เนื่องจากความพยายามที่ล้มเหลวมากเกินไปเพื่อล็อคชีวภาพอื่น ๆ ทั้งหมดของคลาสไบโอเมตริกซ์เดียวกัน ในกรณีของการล็อคเวลาตามเวลาแนะนำให้ใช้เวลาย้อนกลับสำหรับการตรวจสอบไบโอเมตริกซ์แนะนำอย่างยิ่งให้เป็นเวลา backoff สูงสุดของไบโอเมตริกซ์ทั้งหมดในการล็อคเวลาที่กำหนดเวลา
[C-7-2] จะต้องท้าทายผู้ใช้สำหรับการตรวจสอบหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) เพื่อรีเซ็ตตัวนับล็อคสำหรับไบโอเมตริกซ์ที่ถูกล็อค Biometrics คลาส 3 อาจได้รับอนุญาตให้รีเซ็ตตัวนับล็อคสำหรับไบโอเมตริกซ์ล็อคของชั้นเรียนเดียวกันหรือต่ำกว่า biometrics คลาส 2 หรือ คลาส 1 จะต้องไม่ได้รับอนุญาตให้ดำเนินการรีเซ็ตการล็อกสำหรับไบโอเมตริกซ์ใด ๆ
หากการใช้งานอุปกรณ์ต้องการรักษาเซ็นเซอร์ไบโอเมตริกซ์เป็น คลาส 1 (เดิมคือ ความสะดวกสบาย ) พวกเขา:
[C-1-12] ต้องมีอัตราการยอมรับการปลอมแปลงและการแอบอ้างไม่สูงกว่า 40% ต่อการนำเสนอเครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบ Biometrics Android
[C-SR-13] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการเปิดเผยไม่สูงกว่า 30% ต่อการนำเสนอเครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบ Biometrics Android
[C-SR-14] ขอแนะนำอย่างยิ่งให้เปิดเผยคลาสไบโอเมตริกซ์ของเซ็นเซอร์ไบโอเมตริกซ์และความเสี่ยงที่สอดคล้องกันในการเปิดใช้งาน
[C-SR-17] ขอแนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซ AIDL ใหม่ (เช่น,
IFace.aidl
และIFingerprint.aidl
)
หากการใช้งานอุปกรณ์ต้องการรักษาเซ็นเซอร์ไบโอเมตริกซ์เป็น คลาส 2 ( อ่อนแอ เดิม) พวกเขา:
- [C-SR-15] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการเปิดเผยไม่สูงกว่า 20% ต่อการนำเสนอเครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบ Biometrics Android
- [C-2-3] จะต้องทำการจับคู่ไบโอเมตริกซ์ในสภาพแวดล้อมการดำเนินการที่แยกได้นอกผู้ใช้ Android หรือพื้นที่เคอร์เนลเช่นสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยก ได้ เครื่องเสมือนที่ตรงตามข้อกำหนดในส่วนที่ 9.17 - [C-2-4] จะต้องมีข้อมูลที่ระบุตัวตนที่สามารถระบุตัวตนได้ทั้งหมดและตรวจสอบสิทธิ์การเข้ารหัสเพื่อให้ไม่สามารถรับอ่านหรือเปลี่ยนแปลงนอกสภาพแวดล้อมการดำเนินการที่แยกได้หรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกได้ตามที่บันทึกไว้ใน แนวทางการดำเนินการ บนไซต์โครงการโอเพ่นซอร์ส Android หรือเครื่องเสมือนที่ได้รับการป้องกันที่ควบคุมโดย Hypervisor ที่ตรงตามข้อกำหนดในส่วนที่ 9.17
- [C-2-5] สำหรับชีวภาพที่ใช้กล้องในขณะที่การตรวจสอบความถูกต้องตามไบโอเมตริกซ์หรือการลงทะเบียนกำลังเกิดขึ้น:
- ต้องใช้งานกล้องในโหมดที่ป้องกันไม่ให้เฟรมกล้องอ่านหรือเปลี่ยนแปลงนอกสภาพแวดล้อมการดำเนินการที่แยกได้หรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกได้ หรือเครื่องเสมือนที่ได้รับการป้องกันที่ควบคุมโดยไฮเปอร์ไวเซอร์ที่ตรงตามข้อกำหนดในส่วน 9.17
- สำหรับโซลูชันกล้องตัวเดียว RGB เฟรมกล้องสามารถอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกได้เพื่อสนับสนุนการดำเนินการเช่นดูตัวอย่างสำหรับการลงทะเบียน แต่จะต้องไม่เปลี่ยนแปลง
- [C-2-7] จะต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกซ์ที่ไม่สามารถเข้ารหัสได้หรือข้อมูลใด ๆ ที่ได้มาจากมัน (เช่นฝังตัว) ไปยังตัวประมวลผลแอปพลิเคชันนอกบริบทของ TEE หรือเครื่องเสมือนที่ได้รับการป้องกันที่ควบคุมโดยไฮเปอร์ไวเซอร์ที่ตรงตามข้อกำหนดในส่วน 9.17 . การอัพเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือก่อนหน้านี้ไม่ได้รับการยกเว้นจาก C-2-7
หากการใช้งานอุปกรณ์ต้องการรักษาเซ็นเซอร์ไบโอเมตริกซ์เป็น คลาส 3 (เดิมคือ แข็งแกร่ง ) พวกเขา:
- [C-SR-16] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการเปิดเผยไม่สูงกว่า 7% ต่อการนำเสนอเครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบ Biometrics Android
7.3.13. IEEE 802.1.15.4 (UWB) :
ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ 802.1.15.4 และเปิดเผยการทำงานของแอปพลิเคชันของบุคคลที่สามพวกเขา:
- [C-1-2] ต้องรายงานคุณสมบัติฮาร์ดแวร์ FATHE FLAG
android.hardware.uwb
- [C-1-3] ต้องรองรับชุดการกำหนดค่าทั้งหมดต่อไปนี้ (ชุดค่าผสมที่กำหนดไว้ล่วงหน้าของพารามิเตอร์ FIRA UCI ) ที่กำหนดไว้ในการใช้งาน AOSP
-
CONFIG_ID_1
: unicast unicastSTATIC STS DS-TWR
ที่กำหนดโดย FIRA, โหมดรอการตัดบัญชี, ช่วงเวลา 240 มิลลิวินาที -
CONFIG_ID_2
:STATIC STS DS-TWR
แบบคงที่แบบหนึ่งถึงหลายต่อหลายรุ่น, โหมดรอการตัดบัญชี, ช่วงเวลา 200 มิลลิวินาที กรณีการใช้งานทั่วไป: สมาร์ทโฟนโต้ตอบกับอุปกรณ์สมาร์ทจำนวนมาก -
CONFIG_ID_3
: เช่นเดียวกับCONFIG_ID_1
ยกเว้นไม่ได้รายงานข้อมูลมุมของการมาถึง (AOA) -
CONFIG_ID_4
: เหมือนกับCONFIG_ID_1
ยกเว้นโหมดความปลอดภัย P-STS เปิดใช้งาน -
CONFIG_ID_5
: เหมือนกับCONFIG_ID_2
ยกเว้นโหมดความปลอดภัย P-STS เปิดใช้งาน -
CONFIG_ID_6
: เหมือนกับCONFIG_ID_3
ยกเว้นโหมดความปลอดภัย P-STS เปิดใช้งาน -
CONFIG_ID_7
: เช่นเดียวกับCONFIG_ID_2
ยกเว้นโหมดคีย์ตัวควบคุมแต่ละตัว P-STS ถูกเปิดใช้งาน
-
- [C-1-4] ต้องจัดหาเงินทุนของผู้ใช้เพื่อให้ผู้ใช้สลับสถานะเปิด/ปิดวิทยุ UWB
- [C-1-5] ต้องบังคับใช้แอพที่ใช้ UWB Radio ถือการอนุญาต
UWB_RANGING
(ภายใต้กลุ่มการอนุญาตNEARBY_DEVICES
)
ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องที่กำหนดโดยองค์กรมาตรฐานรวมถึง FIRA , CCC และ CSA ช่วยให้แน่ใจว่า 802.1.15.4 ฟังก์ชั่นอย่างถูกต้อง
- [C-1-2] ต้องรายงานคุณสมบัติฮาร์ดแวร์ FATHE FLAG
ดูการแก้ไข
“ โทรศัพท์” ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการวางสายเสียงและส่งข้อความ SMS หรือสร้างข้อมูลมือถือผ่านเครือข่ายมือถือ (เช่น GSM, CDMA, LTE, NR) GSM หรือ CDMA อุปกรณ์ที่รองรับ“ โทรศัพท์” อาจเลือกที่จะเสนอบริการการโทรการส่งข้อความและข้อมูลบางส่วนหรือทั้งหมดตามผลิตภัณฑ์
ผ่านเครือข่าย GSM หรือ CDMA ในขณะที่การโทรด้วยเสียงเหล่านี้อาจเปลี่ยนแพ็คเก็ตได้หรือไม่ แต่ก็มีวัตถุประสงค์เพื่อวัตถุประสงค์ของ Android ที่พิจารณาว่าเป็นอิสระจากการเชื่อมต่อข้อมูลใด ๆ ที่อาจนำไปใช้โดยใช้เครือข่ายเดียวกัน กล่าวอีกนัยหนึ่งฟังก์ชั่น“ โทรศัพท์” Android และ APIs อ้างถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่นการใช้งานอุปกรณ์ที่ไม่สามารถโทรหรือส่ง/รับข้อความ SMS จะไม่ถือว่าเป็นอุปกรณ์โทรศัพท์ไม่ว่าพวกเขาจะใช้เครือข่ายมือถือสำหรับการเชื่อมต่อข้อมูลหรือไม่ดูการแก้ไข
หากการใช้งานอุปกรณ์รวมถึงการสนับสนุนสำหรับ 802.11 และเปิดเผยฟังก์ชั่นไปยังแอปพลิเคชันของบุคคลที่สามพวกเขา:
- [C-1-4] ต้องรองรับ Multicast DNS (MDNs) และต้องไม่กรองแพ็คเก็ต MDNS (224.0.0.251 หรือ FF02 :: FB ) ตลอดเวลาของการทำงานรวมถึง เมื่อหน้าจอไม่ได้อยู่ในสถานะที่ใช้งานอยู่ การกรองแพ็คเก็ตเหล่านี้เป็นสิ่งจำเป็นในการอยู่ในช่วงการใช้พลังงานที่ต้องการตามข้อกำหนดด้านกฎระเบียบที่ใช้บังคับกับตลาดเป้าหมาย
สำหรับการใช้งานอุปกรณ์โทรทัศน์ Android แม้ว่าจะอยู่ในสถานะพลังงานสแตนด์บาย
- [C-1-4] ต้องรองรับ Multicast DNS (MDNs) และต้องไม่กรองแพ็คเก็ต MDNS (224.0.0.251 หรือ FF02 :: FB ) ตลอดเวลาของการทำงานรวมถึง เมื่อหน้าจอไม่ได้อยู่ในสถานะที่ใช้งานอยู่ การกรองแพ็คเก็ตเหล่านี้เป็นสิ่งจำเป็นในการอยู่ในช่วงการใช้พลังงานที่ต้องการตามข้อกำหนดด้านกฎระเบียบที่ใช้บังคับกับตลาดเป้าหมาย
ดูการแก้ไข
หากการใช้งานอุปกรณ์ประกาศ feature_bluetooth_le พวกเขา:
- [C-SR-2] ขอแนะนำอย่างยิ่งในการวัดและชดเชยการชดเชย RX เพื่อให้แน่ใจว่าค่ามัธยฐาน BLE RSSI คือ -60DBM +/- 10 dB ที่ระยะทาง 1m จากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่
ADVERTISE_TX_POWER_HIGH
ซึ่งอุปกรณ์จะถูกวาง บน 'เครื่องบินขนาน' ที่มีหน้าจอหันหน้าไปทางทิศทางเดียวกัน - [C-SR-3] ขอแนะนำอย่างยิ่งในการวัดและชดเชยการชดเชย TX เพื่อให้แน่ใจว่าค่ามัธยฐาน BLE RSSI คือ -60DBM +/- 10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในระยะ 1
ADVERTISE_TX_POWER_HIGH
. เช่นนี้อยู่บน 'เครื่องบินขนาน' ที่มีหน้าจอหันหน้าไปทางทิศทางเดียวกัน
- [C-10-3] จะต้องวัดและชดเชยการชดเชย RX เพื่อให้แน่ใจว่าค่ามัธยฐาน BLE RSSI คือ -55DBM +/- 10 dB ที่ระยะ 1 ม. จากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่
ADVERTISE_TX_POWER_HIGH
- [C-10-4] จะต้องวัดและชดเชยการชดเชย TX เพื่อให้แน่ใจว่าค่ามัธยฐาน BLE RSSI คือ -55DBM +/- 10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในระยะ 1
ADVERTISE_TX_POWER_HIGH
.
หากการใช้งานอุปกรณ์รองรับ Bluetooth เวอร์ชัน 5.0 แล้ว:
- [C-SR-4] ขอแนะนำอย่างยิ่งเพื่อให้การสนับสนุน:
- LE 2M Phy
- Le Codec Phy
- ส่วนขยายโฆษณาของ Le
- การโฆษณาเป็นระยะ
- ชุดโฆษณาอย่างน้อย 10 ชุด
- อย่างน้อย 8 การเชื่อมต่อที่เกิดขึ้นพร้อมกันของ LE การเชื่อมต่อแต่ละครั้งสามารถอยู่ในบทบาททอพอโลยีการเชื่อมต่อ
- ความเป็นส่วนตัวของเลเยอร์ Link Link
- ขนาด "รายการแก้ไข" อย่างน้อย 8 รายการ
- [C-SR-2] ขอแนะนำอย่างยิ่งในการวัดและชดเชยการชดเชย RX เพื่อให้แน่ใจว่าค่ามัธยฐาน BLE RSSI คือ -60DBM +/- 10 dB ที่ระยะทาง 1m จากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่
ดูการแก้ไข
- [C-1-7] ต้องตรวจสอบให้แน่ใจว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายใน [0.75m, 1.25m] ซึ่งวัดระยะทางความจริงพื้นดินจากขอบด้านบนของ DUT
คว่ำหน้าและเอียง 45 องศา
- [C-1-7] ต้องตรวจสอบให้แน่ใจว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายใน [0.75m, 1.25m] ซึ่งวัดระยะทางความจริงพื้นดินจากขอบด้านบนของ DUT
ดูการแก้ไข
กล้องหันหน้าไปทางด้านหลังเป็นกล้องที่อยู่ด้านข้างของอุปกรณ์ตรงข้ามจอแสดงผล นั่นคือภาพมันฉากที่อยู่ด้านไกลของอุปกรณ์เช่นกล้องแบบดั้งเดิม
กล้องหันหน้าไปทางด้านหลังเป็นกล้องที่หันหน้าไปทางโลกซึ่งภาพฉากที่อยู่ด้านไกลของอุปกรณ์เช่นกล้องแบบดั้งเดิม บนอุปกรณ์พกพานั่นคือกล้องที่อยู่ด้านข้างของอุปกรณ์ตรงข้ามจอแสดงผล
ดูการแก้ไข
กล้องหน้าหันหน้าไปทางกล้องที่อยู่ด้านข้างของอุปกรณ์เช่นเดียวกับจอแสดงผล นั่นคือกล้องมักใช้ในการถ่ายภาพผู้ใช้เช่นสำหรับการประชุมทางวิดีโอและแอพพลิเคชั่นที่คล้ายกัน
กล้องหน้าหันหน้าไปทางกล้องที่หันหน้าไปทางผู้ใช้ซึ่งโดยทั่วไปจะใช้ในการถ่ายภาพผู้ใช้เช่นสำหรับการประชุมทางวิดีโอและแอพพลิเคชั่นที่คล้ายกัน บนอุปกรณ์พกพานั่นคือกล้องที่อยู่ด้านข้างของอุปกรณ์เช่นเดียวกับจอแสดงผล
ดูการแก้ไข
กล้องภายนอกเป็นกล้องที่สามารถติดตั้งทางกายภาพหรือแยกออกจากการใช้งานอุปกรณ์ได้ตลอดเวลาและสามารถเผชิญหน้ากับทิศทางใดก็ได้ เช่นกล้อง USB
7.5.4. พฤติกรรม API ของกล้อง :
ดูการแก้ไข
การใช้งานอุปกรณ์จะต้องใช้พฤติกรรมต่อไปนี้สำหรับ API ที่เกี่ยวข้องกับกล้องสำหรับกล้องที่มีอยู่ทั้งหมด การใช้งานอุปกรณ์:
- [C-SR-1] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัว ในบริเวณใกล้เคียงและ หันไปในทิศทางเดียวกันขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องเชิงตรรกะที่แสดงรายการ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
เป็นอุปกรณ์ย่อยทางกายภาพ
- [C-SR-1] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัว ในบริเวณใกล้เคียงและ หันไปในทิศทางเดียวกันขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องเชิงตรรกะที่แสดงรายการ
ดูการแก้ไข
อุปกรณ์ที่ปฏิบัติตามเกณฑ์ทั้งหมดต่อไปนี้ได้รับการยกเว้นจากข้อกำหนดข้างต้น:
- การใช้งานอุปกรณ์ที่ไม่สามารถหมุนได้โดยผู้ใช้เช่นอุปกรณ์ยานยนต์
ดูการแก้ไข
อุปกรณ์ที่ตั้งใจจะถือมือหรือสวมใส่อาจรวมถึงแอคทูเอเตอร์สัมผัสวัตถุประสงค์ทั่วไปที่มีอยู่สำหรับแอปพลิเคชันเพื่อจุดประสงค์รวมถึงการได้รับความสนใจผ่านเสียงเรียกเข้าสัญญาณเตือนการแจ้งเตือนและข้อเสนอแนะแบบสัมผัสทั่วไป
หากการใช้งานอุปกรณ์ไม่รวมแอคทูเอเตอร์แบบสัมผัสโดยทั่วไปพวกเขา:
- [7.10/c] ต้องส่งคืนเท็จสำหรับ
Vibrator.hasVibrator()
หากการใช้งานอุปกรณ์นั้นมีแอคชูเอเตอร์สัมผัสอย่างน้อยหนึ่งอย่างอย่างน้อยหนึ่งตัวพวกเขา:
- [C-1-1] ต้องส่งคืนจริงสำหรับ
Vibrator.hasVibrator()
- ไม่ควรใช้แอคชูเอเตอร์สัมผัสแบบหมุนวน (ERM) (Vibrator)
- ควรใช้ค่าคงที่สาธารณะทั้งหมด
VIRTUAL_KEY
สัมผัสที่ชัดเจนVIRTUAL_KEY_RELEASE
android.view.HapticFeedbackConstants
คือ (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
REJECT
KEYBOARD_TAP
,LONG_PRESS
GESTURE_END
TEXT_HANDLE_MOVE
,CONFIRM
,GESTURE_START
- ควรใช้ค่าคงที่สาธารณะทั้งหมดเพื่อ สัมผัส
android.os.VibrationEffect.Composition
ชัดเจน ในandroid.os.VibrationEffect
คือ (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
TICK
EFFECT_DOUBLE_CLICK
) และPRIMITIVE_*
สาธารณะCLICK
LOW_TICK
ไปได้ทั้งหมดQUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
) บางส่วนของดั้งเดิมเหล่านี้เช่นLOW_TICK
และSPIN
อาจเป็นไปได้ก็ต่อเมื่อเครื่องสั่นสามารถรองรับความถี่ที่ค่อนข้างต่ำ - ควรทำตาม คำแนะนำสำหรับการทำแผนที่ค่าคงที่สาธารณะ ใน
android.view.HapticFeedbackConstants
กับค่าคงที่android.os.VibrationEffect
ที่แนะนำพร้อมกับความสัมพันธ์ของแอมพลิจูดที่สอดคล้องกัน - ควรใช้ การแมป ค่าคงที่แบบสัมผัสที่เชื่อมโยงเหล่านี้
- ควรติดตาม การประเมินคุณภาพ สำหรับ
createOneShot()
และcreateWaveform()
API - ควรตรวจสอบว่าผลลัพธ์ของ Public
android.os.Vibrator.hasAmplitudeControl()
API สะท้อนความสามารถของเครื่องสั่นอย่างถูกต้อง - ควรตรวจสอบความสามารถสำหรับความสามารถในการปรับขนาดแอมพลิจูดโดยใช้
android.os.Vibrator.hasAmplitudeControl()
หากการใช้งานอุปกรณ์ติดตามการแมปค่าคงที่ของแฮทติคพวกเขา:
- ควรตรวจสอบสถานะการใช้งานโดยเรียกใช้
android.os.Vibrator.areAllEffectsSupported()
และandroid.os.Vibrator.arePrimitivesSupported()
APIs - ควรทำการ ประเมินคุณภาพ สำหรับค่าคงที่สัมผัส
- ควรตรวจสอบและอัปเดตหากจำเป็นต้องมีการกำหนดค่าทางเลือกสำหรับดั้งเดิมที่ไม่ได้รับการสนับสนุนตามที่อธิบายไว้ใน แนวทางการใช้งาน สำหรับค่าคงที่
- ควรให้การสนับสนุนทางเลือกเพื่อลดความเสี่ยงของความล้มเหลวตามที่อธิบายไว้ ที่นี่
ดูหัวข้อ 2.2.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
- [7.10/c] ต้องส่งคืนเท็จสำหรับ
9. ความเข้ากันได้ของโมเดลความปลอดภัย
ดูการแก้ไข
การใช้งานอุปกรณ์:
- [C-0-4] จะต้องมีการใช้งานหนึ่งเดียวของอินเทอร์เฟซผู้ใช้ทั้งสอง
หากการใช้งานอุปกรณ์ติดตั้งแพ็คเกจใด ๆ ที่เก็บข้อมูลใด ๆ ของ ระบบ UI Intelligence , System Audio Intelligence , System Audio Intelligence , ระบบแจ้งเตือน ระบบ, ระบบข้อความความฉลาด ทางข้อความระบบ หรือบทบาท ความฉลาดทางสายตาของระบบ , แพ็คเกจ:
- [C-4-1] จะต้องปฏิบัติตามข้อกำหนดทั้งหมดที่ระบุไว้สำหรับการใช้งานอุปกรณ์ในส่วน
"9.8.6 การจับเนื้อหา""9.8.6 ข้อมูลระดับ OS และระบบรอบข้างและการใช้งาน API Sandboxed API 9.8.15"
- [C-4-2] ต้องไม่มี Android.Permission.Internet Permission This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- ฮีปบัฟเฟอร์ล้น
- use after free
- ฟรีสองเท่า
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is แบ่งปัน Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. การอนุญาต .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of กังวล.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the