คำจำกัดความความเข้ากันได้ของ Android 15

1. ข้อมูลเบื้องต้น

เอกสารนี้แจกแจงข้อกำหนดที่ต้องปฏิบัติตาม ใช้ได้กับ Android 15 นะ

การใช้คำว่า "ต้อง" "ต้องไม่" "จำเป็น" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่กำหนดไว้ใน RFC2119

ตามที่ใช้ในเอกสารนี้ "ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" เป็นบุคคล หรือองค์กรการพัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 15. "การติดตั้งใช้งานอุปกรณ์" หรือ "การใช้งาน" คือ โซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้นอีกมาก

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

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

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

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

2.1 การกำหนดค่าอุปกรณ์

ความแตกต่างที่สำคัญในการกำหนดค่าฮาร์ดแวร์ตามอุปกรณ์ โปรดดูข้อกำหนดเฉพาะอุปกรณ์ดังต่อไปนี้ในหัวข้อนี้

2.2 ข้อกำหนดสำหรับอุปกรณ์พกพา

อุปกรณ์ Android พกพา หมายถึงการใช้งานอุปกรณ์ Android ที่ ที่มักใช้โดยถือไว้ในมือ เช่น โปรแกรมเล่น mp3, โทรศัพท์ หรือ แท็บเล็ต

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

• มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
• มีขนาดหน้าจอทแยงมุมจริงในช่วง 4-8 นิ้ว
• มีอินเทอร์เฟซอินพุตแบบหน้าจอสัมผัส

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

2.2.1. ฮาร์ดแวร์

การใช้งานอุปกรณ์เคลื่อนที่

• [7.1.1.1/H-0-1] ต้องมีอย่างน้อย 1 รายการ จอแสดงผลที่เข้ากันได้กับ Android ซึ่งวัดอย่างน้อย 2.2 นิ้ว ด้านขอบสั้น และ 3.4 นิ้ว ในด้านยาว

• [7.1.1.3/H-SR-1] ขอแนะนําอย่างยิ่งให้ ช่วยให้ผู้ใช้สามารถปรับขนาดการแสดงผล (ความหนาแน่นของหน้าจอ) ได้

• [7.1.1.1/H-0-2] ต้องรองรับองค์ประกอบ GPU ของ กราฟิกบัฟเฟอร์อย่างน้อยเท่ากับความละเอียดสูงสุดสำหรับความละเอียดสูงสุดที่มี จอแสดงผล

• [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% หรือมากกว่าความหนาแน่นทางกายภาพจริง ของจอแสดงผลที่เกี่ยวข้อง

หากการใช้งานอุปกรณ์พกพารวมถึงการรองรับ Vulkan จะมีการดำเนินการต่อไปนี้

• [7.1.4.2/H-1-1] ต้องเป็นไปตามข้อกำหนด ที่ระบุไว้ในโปรไฟล์ Android Baseline 2021

หากการใช้อุปกรณ์พกพาอ้างว่าสนับสนุนช่วงไดนามิกกว้าง แสดงผ่านทาง 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 Renderstages ที่กำหนดไว้ในเอกสารประกอบของ Perfetto
• [7.1.4.6/H-1-2] ต้องรายงานค่าที่สอดคล้องกัน สำหรับตัวนับ GPU ของอุปกรณ์ตาม gpu Counter Tracking Pack Pro
• [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
• [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] ต้องรายงานช่วง Pseudorange และ Pseudorange ของ GNSS ในสภาพอากาศที่โล่งหลังจากระบุตำแหน่ง อยู่กับที่หรือการเคลื่อนที่น้อยกว่า 0.2 เมตรต่อวินาทีของ ความเร่ง ก็เพียงพอที่จะคำนวณตำแหน่งที่อยู่ในระยะ 20 เมตร และความเร็ว ภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลาทั้งหมด

หากการใช้งานอุปกรณ์พกพามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้

• [7.3.4/H-3-1] ต้องรายงานเหตุการณ์ได้ตามความถี่ อย่างน้อย 100 Hz
• [7.3.4/H-3-2] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้ ได้สูงสุดถึง 1000 องศาต่อวินาที

การใช้งานอุปกรณ์เคลื่อนที่ที่สามารถโทรออกด้วยเสียงและระบุ ค่าใดๆ ที่ไม่ใช่ PHONE_TYPE_NONE ใน getPhoneType:

• [7.3.8/H] ควรมีพร็อกซิมิตีเซ็นเซอร์

การใช้งานอุปกรณ์เคลื่อนที่

• [7.3.11/H-SR-1] แนะนำอย่างยิ่งให้รองรับเซ็นเซอร์ท่าทาง ด้วยอุณหภูมิอิสระ 6 องศา

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากอุปกรณ์รองรับโปรโตคอล Wi-Fi Neighbor Awareness Networking (NAN) โดย ประกาศ PackageManager.FEATURE_WIFI_AWARE และตำแหน่ง Wi-Fi (Wi-Fi Round เวลาเดินทาง — RTT) โดยประกาศ PackageManager.FEATURE_WIFI_RTT จากนั้นระบบจะดำเนินการดังต่อไปนี้

• [7.4.2.5/H-1-1] ต้องรายงานช่วงอย่างถูกต้องเพื่อ ในระยะ +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณแล้ว พร้อมด้วยฟังก์ชันการกระจายสะสม) ความถี่ +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่ เปอร์เซ็นไทล์ที่ 68, +/-4 เมตรที่แบนด์วิดท์ 40 MHz ที่เปอร์เซ็นไทล์ที่ 68 และ +/-8 เมตรที่แบนด์วิดท์ 20 MHz ที่เปอร์เซ็นไทล์ที่ 68 ที่ระยะทาง 10 ซม., 1 ม., 3 ม. และ 5 ม. ตามสังเกตการณ์ผ่านทางแท็ก WifiRttManager#startRanging Android API

• [7.4.2.5/H-SR-1] ขอแนะนําอย่างยิ่งให้รายงาน วัดช่วงได้แม่นยำภายใน +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่ความเร็ว 90 เปอร์เซ็นไทล์ (คำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 90 และ +/-4 เมตรที่ 40 MHz ที่เปอร์เซ็นไทล์ที่ 90 และ +/-8 เมตรที่แบนด์วิดท์ 20 MHz ที่ เปอร์เซ็นไทล์ที่ 90 ที่ระยะทาง 10 ซม. ตามที่สังเกตการณ์ผ่านทาง WifiRttManager#startRanging Android API

ขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดผลที่ระบุไว้ใน การปรับเทียบสถานที่ตั้ง

หากการใช้งานอุปกรณ์พกพาประกาศเป็น FEATURE_BLUETOOTH_LE สิ่งที่จะเกิดขึ้นมีดังนี้

• [7.4.3/H-1-3] ต้องวัดค่าและชดเชย Rx เพื่อให้มั่นใจว่าค่ามัธยฐานของ BLE RSSI เท่ากับ -50dBm +/-15 dB ที่ระยะห่าง 1 เมตรจาก กำลังส่งอุปกรณ์อ้างอิงเมื่อ ADVERTISE_TX_POWER_HIGH
• [7.4.3/H-1-4] ต้องวัดและชดเชย Tx เพื่อให้มั่นใจว่าค่ามัธยฐานของ BLE RSSI เท่ากับ -50dBm +/-15 dB เมื่อสแกนจาก อุปกรณ์อ้างอิงอยู่ในตำแหน่งที่ระยะห่าง 1 เมตรและกำลังส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH

หากการใช้งานอุปกรณ์พกพารวมถึงอุปกรณ์กล้องเชิงตรรกะที่แสดง โดยใช้ความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ดังนี้

• [7.5.4/H-1-1] ต้องมีขอบเขตการมองเห็น (FOV) ปกติโดยค่าเริ่มต้น และต้องมีค่าระหว่าง 50 ถึง องศา

การใช้งานอุปกรณ์เคลื่อนที่

• [7.6.1/H-0-1] ต้องมีพื้นที่เก็บข้อมูลอย่างน้อย 4 GB พื้นที่เก็บข้อมูลที่ไม่ผันผวนสำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
• [7.6.1/H-0-2] ต้องแสดงผล "จริง" สำหรับ ActivityManager.isLowRamDevice()เมื่อมีหน่วยความจำน้อยกว่า 1 GB พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้

หากการใช้อุปกรณ์พกพาประกาศว่ารองรับ ABI แบบ 32 บิตเท่านั้น ให้ทําดังนี้

• [7.6.1/H-1-1] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 416 MB หากจอแสดงผลเริ่มต้นใช้ FrameBuffer ความละเอียดได้สูงสุด qHD (เช่น FWVGA)

• [7.6.1/H-2-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 592 MB หากจอแสดงผลเริ่มต้นใช้ FrameBuffer ความละเอียดสูงสุดถึง HD+ (เช่น HD, WSVGA)

• [7.6.1/H-3-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากจอแสดงผลเริ่มต้นใช้ FrameBuffer ความละเอียดสูงสุดถึง FHD (เช่น WSXGA+)

• [7.6.1/H-4-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากจอแสดงผลเริ่มต้นใช้ ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง QHD (เช่น QWXGA)

หากการใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI 64 บิต (มีหรือไม่มี ABI แบบ 32 บิต) ให้ทำดังนี้

• [7.6.1/H-5-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้อง มีขนาดอย่างน้อย 816 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์ เป็น qHD (เช่น FWVGA)

• [7.6.1/H-6-1] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีค่าอย่างน้อย 944 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง HD+ (เช่น HD, WSVGA)

• [7.6.1/H-7-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีค่าอย่างน้อย 1280 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)

• [7.6.1/H-8-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีค่าอย่างน้อย 1824 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุด QHD (เช่น QWXGA)

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

หากการใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่าหรือเท่ากับ 1 GB พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้

• [7.6.1/H-9-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.ram.low
• [7.6.1/H-9-2] ต้องมีพื้นที่เก็บข้อมูลอย่างน้อย 1.1 GB พื้นที่เก็บข้อมูลที่ไม่ผันผวนสำหรับแอปพลิเคชัน ข้อมูลส่วนตัว (หรือที่เรียกว่าพาร์ติชัน "/data")

หากใช้งานอุปกรณ์พกพามีหน่วยความจำมากกว่า 1 GB ไปยังเคอร์เนลและพื้นที่ผู้ใช้

• [7.6.1/H-10-1] ต้องมีพื้นที่เก็บข้อมูลอย่างน้อย 4 GB พื้นที่เก็บข้อมูลที่ไม่ผันผวนสำหรับ ข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
• ควรประกาศแฟล็กฟีเจอร์ android.hardware.ram.normal

หากการใช้งานอุปกรณ์พกพามีค่ามากกว่าหรือเท่ากับ 2 GB และมีหน่วยความจำน้อยกว่า 4 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้

• [7.6.1/H-SR-1] แนะนําอย่างยิ่งให้รองรับพื้นที่ผู้ใช้แบบ 32 บิตเท่านั้น (ทั้งแอปและโค้ดของระบบ)

หากการใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่า 2 GB เคอร์เนลและพื้นที่ผู้ใช้

• [7.6.1/H-1-1] ต้องรองรับ ABI เดียวเท่านั้น (64 บิตเท่านั้นหรือ 32 บิต เท่านั้น)

การใช้งานอุปกรณ์เคลื่อนที่

• [7.6.2/H-0-1] ต้องไม่ให้ใบสมัคร พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีขนาดเล็กกว่า 1 GiB
• [7.7.1/H] ควรรวมพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการใช้งานอุปกรณ์พกพามีพอร์ต 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 และมีการรองรับโหมด VR ดังนี้

• [7.9.1/H-1-1] ต้องประกาศส่วน แฟล็กฟีเจอร์ android.hardware.vr.high_performance
• [7.9.1/H-1-2] ต้องระบุแอปพลิเคชัน กำลังติดตั้ง android.service.vr.VrListenerService ที่เปิดใช้ได้ด้วย VR แอปพลิเคชันผ่าน android.app.Activity#setVrModeEnabled

หากใช้งานอุปกรณ์พกพามีพอร์ต USB-C อย่างน้อย 1 พอร์ตในโฮสต์ และติดตั้งใช้งาน (คลาสเสียง USB) นอกเหนือจากข้อกำหนดใน ส่วนที่ 7.7.2 เพื่อนำไปใช้

• [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์ต่อไปนี้ ของโค้ด HID:

การทำงาน	การแมป	บริบท	ลักษณะการทำงาน
ก	หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CD คีย์เคอร์เนล: KEY_PLAYPAUSE คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE	การเล่นสื่อ	อินพุต: กดสั้น เอาต์พุต: เล่นหรือหยุดชั่วคราว
			อินพุต: กดค้าง เอาต์พุต: เปิดคำสั่งเสียง ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ มีการล็อกหรือปิดหน้าจอ จำนวนครั้งที่ส่ง จ่าย android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		สายเรียกเข้า	อินพุต: กดสั้น เอาต์พุต: รับสาย
			อินพุต: กดค้าง เอาต์พุต: ปฏิเสธสาย
		สายที่สนทนาอยู่	อินพุต: กดสั้น เอาต์พุต: วางสาย
			อินพุต: กดค้าง เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน
B	หน้าการใช้งาน 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.getDevices() ขณะที่อุปกรณ์ต่อพ่วง 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 มิลลิวินาที

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

แอคชูเอเตอร์เชิงเส้น (LRA) เป็นระบบสปริงแบบมวลเดี่ยวซึ่งมี ความถี่สะท้อนที่สะท้อนกลับซึ่งมวลแปลไปในทิศทางของ การเคลื่อนไหวที่ต้องการ

หากการใช้งานอุปกรณ์พกพามีวัตถุประสงค์ทั่วไปอย่างน้อย 1 อย่าง 7.10 แอคชูเอเตอร์เรโซแนนต์เชิงเส้น

• [7.10/H] ควรวางตำแหน่งของอุปกรณ์แอคชูเอเตอร์ใกล้กับ ตำแหน่งที่โดยปกติแล้วมือถือหรือสัมผัสอุปกรณ์

• [7.10/สูง] ควรย้ายตัวดำเนินการการโต้ตอบแบบรู้สึกได้ในแกน X (ซ้าย-ขวา) ตามการวางแนวธรรมชาติของอุปกรณ์

หากการใช้งานอุปกรณ์พกพามีวัตถุประสงค์ทั่วไป ตัวดำเนินการแบบรู้สึกได้ ซึ่งเป็นแอคชูเอเตอร์เชิงเส้นแกน X (LRA)

• [7.10/สูง] ควรมีความถี่สะท้อนกลับของ LRA แกน X ต่ำกว่า 200 Hz

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

• [7.10/H]* ควรตรวจสอบสถานะการติดตั้งใช้งานด้วยการเรียกใช้ android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitivesSupported() API

• [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)

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

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8
• [5.2/H-0-3] AV1

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

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9
• [5.3/H-0-6] AV1

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 API
• [3.2.3.1/H-0-2]* ต้องโหลดล่วงหน้า 1 รายการ แอปพลิเคชันหรือคอมโพเนนต์บริการมากกว่า ที่มีเครื่องจัดการ Intent รูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยแอปพลิเคชันต่อไปนี้ Intent แสดงอยู่ที่นี่
• [3.2.3.1/H-SR-1] มีประสิทธิภาพอย่างมาก แนะนำให้โหลดแอปพลิเคชันอีเมลล่วงหน้าที่สามารถจัดการ ACTION_SENDTO ล่วงหน้า หรือ ACTION_SEND หรือ ACTION_SEND_MULTIPLE ต้องการส่งอีเมล
• [3.4.1/H-0-1] ต้องระบุฟิลด์ การใช้งาน android.webkit.Webview API
• [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] ต้องอนุญาตบุคคลที่สาม แอปสำหรับแจ้งเตือนผู้ใช้เกี่ยวกับกิจกรรมสำคัญผ่านทาง Notification และ NotificationManager คลาส API
• [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] ขอแนะนำเป็นอย่างยิ่ง เพื่อใช้ Assistant ในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย

การใช้งานอุปกรณ์พกพารองรับการแจ้งเตือน MediaStyle หรือไม่ ดังนี้

• [3.8.3.1/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง เพื่อมอบพื้นที่โฆษณาสำหรับผู้ใช้ (เช่น ตัวสลับเอาต์พุต) ที่เข้าถึงจาก UI ระบบที่อนุญาตให้ผู้ใช้สลับระหว่างสื่อที่เหมาะสม (เช่น อุปกรณ์บลูทูธและเส้นทางที่ระบุไปยัง MediaRouter2Manager) เมื่อแอปโพสต์การแจ้งเตือน MediaStyle ที่มีโทเค็น MediaSession

หากใช้อุปกรณ์ ซึ่งรวมถึงแป้นการนำทางของฟังก์ชันล่าสุดเป็น โดยละเอียดในส่วนที่ 7.2.3 ปรับเปลี่ยนอินเทอร์เฟซ

• [3.8.3/H-1-1] ต้องใช้หน้าจอ การปักหมุดและให้เมนูการตั้งค่าแก่ผู้ใช้เพื่อเปิด/ปิด

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

• [3.8.4/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง เพื่อกดค้างที่คีย์ HOME เป็นการโต้ตอบที่กำหนดเพื่อเรียกใช้งาน แอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิด แอปช่วยเหลือที่ผู้ใช้เลือก ซึ่งก็คือแอปที่ใช้งาน VoiceInteractionService หรือกิจกรรมที่จัดการ Intent ACTION_ASSIST

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

• [3.8.4/H-1-1]* ต้องแสดง การแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนาด้วย ข้อยกเว้นของการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าอย่างต่อเนื่อง ความสำคัญ:สูง การแจ้งเตือน

การใช้งานอุปกรณ์มือถือ Android รองรับหน้าจอล็อกจะส่งผลดังนี้

• [3.8.10/H-1-1] ต้องแสดงล็อก การแจ้งเตือนบนหน้าจอ รวมถึงเทมเพลตการแจ้งเตือนสื่อ

หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้

• [3.9/H-1-1] ต้องใช้ การดูแลระบบอุปกรณ์ นโยบายที่กำหนดไว้ในเอกสาร Android SDK

หากการใช้งานอุปกรณ์พกพามีการสนับสนุนสำหรับ 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-1-6] การติดตั้งใช้งานอุปกรณ์ ต้องแสดงให้เห็นราคาสำหรับผู้ใช้อย่างถูกต้องดังนี้

  • หากอุปกรณ์ตั้งค่า config_supportsMultiWindow=true และแอปประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY ในช่วง ControlsProviderService รวมถึง ComponentName ของ กิจกรรมที่ถูกต้อง (ตามที่กำหนดโดย API) แอป "ต้องฝัง" ดังกล่าว การกระทำของผู้ใช้ในระดับนี้
  • หากแอปไม่ได้ประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY ฟิลด์ดังกล่าวจะต้องแสดงผลฟิลด์ที่ระบุ ตามที่ ControlsProviderService API และช่องที่ระบุโดย ควบคุม API

• [3.8.16/H-1-7] หากแอปประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY ตัวแปรต้องส่งผ่านค่าของการตั้งค่าที่กำหนดไว้ใน [3.8.16/H-1-5] โดยใช้ EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS เมื่อเปิดใช้งานกิจกรรมที่ฝัง

ในทางกลับกัน หากการใช้งานอุปกรณ์พกพาไม่ได้ใช้การควบคุมดังกล่าว ดังนี้

• [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] โซนการจดจำท่าทางสัมผัสสำหรับปุ่มหน้าแรก ฟังก์ชันควรสูงไม่เกิน 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] ต้องมีกิจกรรมที่จัดการ การตั้งค่า#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYเมื่อฟังก์ชันการแยกเปิดอยู่ กิจกรรมต้องได้รับการคุ้มครองโดย android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK และ "ต้อง" เริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จาก การตั้งค่า#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI

หากการติดตั้งใช้งานอุปกรณ์ช่วยให้ผู้ใช้โทรออกได้ทุกประเภท

• [7.4.1.2/H-0-1] ต้องประกาศแฟล็กฟีเจอร์ android.software.telecom
• [7.4.1.2/H-0-2] ต้องใช้เฟรมเวิร์กโทรคมนาคม

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 ใน 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] ต้องใช้พลังงานเช่นนี้ มีให้บริการผ่าน adb shell dumpsys batterystats เชลล์ไปยังนักพัฒนาแอป
• [8.4/H] ควรมีแหล่งที่มาจาก ของส่วนประกอบฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของส่วนประกอบฮาร์ดแวร์ได้ ในแอปพลิเคชัน

การใช้งานอุปกรณ์พกพารวมถึงหน้าจอหรือเอาต์พุตวิดีโอจะส่งผลดังนี้

• [8.4/H-1-1] ต้องเคารพ android.intent.action.POWER_USAGE_SUMMARY ความตั้งใจ และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้

การใช้งานอุปกรณ์เคลื่อนที่

• [8.5/H-0-1] ต้องระบุ งบประมาณของผู้ใช้ในการดูแอปทั้งหมดซึ่งมีบริการที่ทำงานอยู่เบื้องหน้า หรืองานที่เริ่มต้นโดยผู้ใช้ รวมถึงระยะเวลาของบริการแต่ละอย่าง นับตั้งแต่เริ่มตามที่อธิบายไว้ในเอกสาร SDK

• [8.5/H-0-2]ต้องระบุค่าใช้จ่ายของผู้ใช้ในการ หยุดแอปที่เรียกใช้บริการที่ทำงานอยู่เบื้องหน้าหรืองานที่เริ่มต้นโดยผู้ใช้

2.2.5 โมเดลการรักษาความปลอดภัย

การใช้งานอุปกรณ์เคลื่อนที่

• [9/H-0-1] ต้องประกาศ android.hardware.security.model.compatible
• [9.1/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สามเข้าถึง สถิติการใช้งานผ่านสิทธิ์ android.permission.PACKAGE_USAGE_STATS และจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้เพื่อให้ เพิกถอนการเข้าถึงแอปดังกล่าวเพื่อตอบสนองต่อ android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony ดังนี้

• [9.5/H-1-1] ต้องไม่ตั้งค่า UserManager.isHeadlessSystemUserMode ไปยัง true

การใช้งานอุปกรณ์เคลื่อนที่

• [9.11/H-0-2] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ ในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
• [9.11/H-0-3] ต้องมีการติดตั้งใช้งาน RSA, AES อัลกอริทึมการเข้ารหัส ECDSA และ HMAC รวมถึงตระกูล MD5, SHA-1 และ SHA-2 ฟังก์ชันแฮชเพื่อให้รองรับระบบ Android Keystore อัลกอริทึมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัย เคอร์เนลขึ้นไป การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมด โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของ สภาพแวดล้อมที่แยกจากกัน ซึ่งรวมถึง DMA โอเพนซอร์ส Android แบบโอเพนซอร์ส โปรเจ็กต์ (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งานทรัสตี โซลูชันแบบ ARM TrustZone หรือการตรวจสอบที่ปลอดภัยโดยบุคคลที่สาม การนำการแยกโดยใช้ไฮเปอร์ไวเซอร์ที่เหมาะสมมาใช้เป็นทางเลือก ตัวเลือก
• [9.11/H-0-4] ต้องใช้หน้าจอล็อก การตรวจสอบสิทธิ์ในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และเฉพาะเมื่อ สำเร็จ อนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ ล็อกหน้าจอ ข้อมูลเข้าสู่ระบบจะต้องได้รับการจัดเก็บไว้ในวิธีที่อนุญาตให้มีการดำเนินการที่แยกต่างหากเท่านั้น เพื่อตรวจสอบสิทธิ์หน้าจอล็อก อัปสตรีม Android โครงการโอเพนซอร์สมอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้ ตามข้อกำหนดนี้ได้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

การใช้งานอุปกรณ์เคลื่อนที่ที่รองรับหน้าจอล็อกที่ปลอดภัยจะส่งผลดังนี้

• [9.11/H-1-1] ต้องอนุญาตให้ผู้ใช้เลือก ระยะหมดเวลาสลีป ซึ่งเป็นระยะเวลาการเปลี่ยนจากการปลดล็อกเป็นล็อก โดยมีความยาวไม่เกิน 15 วินาที
• [9.11/H-1-2] ต้องให้เงินช่วยเหลือแก่ผู้ใช้ในการซ่อน การแจ้งเตือนและปิดใช้การตรวจสอบสิทธิ์ทุกรูปแบบ ยกเว้น การตรวจสอบสิทธิ์หลักที่อธิบายไว้ใน 9.11.1 หน้าจอล็อกที่ปลอดภัย AOSP สอดคล้องกับ เป็นโหมดปิดล็อก

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งใช้ TrustAgentService System API อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [9.11.1/H-1-1] ต้องตั้งคำถามผู้ใช้สำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่า 1 ครั้งในทุกๆ 72 ชั่วโมง

หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายคน และ ไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony เนื่องจาก

• [9.5/H-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด คุณลักษณะที่ช่วยให้เจ้าของอุปกรณ์สามารถจัดการผู้ใช้เพิ่มเติมและผู้ใช้ บนอุปกรณ์ เมื่อใช้โปรไฟล์ที่ถูกจำกัด เจ้าของอุปกรณ์สามารถทำสิ่งต่อไปนี้ได้ ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็ว เพื่อให้ผู้ใช้เพิ่มเติมทำงานได้ ด้วยความสามารถในการจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่ ที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น

หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายคน และ ประกาศแฟล็กฟีเจอร์ของ android.hardware.telephony ดังนี้

• [9.5/H-3-1] ต้องไม่รองรับแบบจำกัด แต่ต้องสอดคล้องกับการปรับใช้ AOSP ของการควบคุม เพื่อเปิด /ปิด ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรและ SMS

หากการใช้งานอุปกรณ์พกพาตั้งค่าไว้เป็น UserManager.isHeadlessSystemUserMode ถึง true

• [9.5/H-4-1] ต้องไม่รวมการรองรับ eUICC หรือ eSIM ที่มีความสามารถในการโทร
• [9.5/H-4-2] ต้องไม่ประกาศการรองรับ android.hardware.telephony

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการใช้งานอุปกรณ์พกพารองรับ System API HotwordDetectionService หรือกลไกอื่นสำหรับการตรวจหาคำสั่งให้ดำเนินการโดยไม่มี สัญญาณบอกสถานะการเข้าถึงไมค์

• [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการสามารถส่ง ไปยังระบบ ContentCaptureService หรือบริการการจดจำคำพูดในอุปกรณ์ที่สร้างโดย SpeechRecognizer#createOnDeviceSpeechRecognizer()
• [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการสามารถส่ง ข้อมูลเสียงของไมค์หรือข้อมูลที่ได้จากข้อมูลดังกล่าวไปยังเซิร์ฟเวอร์ของระบบผ่านทาง HotwordDetectionService API หรือไปยัง 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-1-15] ต้องตรวจสอบว่าสตรีมเสียงที่ให้มาด้วยคำสั่งให้ดำเนินการที่ประสบความสำเร็จ ระบบจะส่งผลลัพธ์ทางเดียวจากบริการตรวจหาคำสั่งให้ดำเนินการไปยัง ซึ่งเป็นบริการโต้ตอบด้วยเสียง

• [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 หรือคำพูดในอุปกรณ์ บริการการจดจำเสียง

หากการใช้งานอุปกรณ์พกพารองรับ System API VisualQueryDetectionService หรือกลไกอื่นสำหรับการตรวจหาการค้นหา โดยไม่มีสัญญาณบอกสถานะการเข้าถึงไมค์และ/หรือกล้อง

• [9.8/H-3-1] ต้องตรวจสอบว่าบริการตรวจจับการค้นหาสามารถส่งได้เฉพาะ ไปยังระบบ หรือContentCaptureService หรือเสียงพูดในอุปกรณ์ บริการจดจำเสียง (สร้างโดย SpeechRecognizer#createOnDeviceSpeechRecognizer())
• [9.8/H-3-2] ต้องไม่อนุญาตให้ส่งข้อมูลเสียงหรือวิดีโอ จาก VisualQueryDetectionService ยกเว้น ContentCaptureService หรือบริการรู้จำคำพูด ในอุปกรณ์
• [9.8/H-3-3] ต้องแสดงข้อความแจ้งผู้ใช้ใน UI ของระบบเมื่ออุปกรณ์ตรวจพบผู้ใช้ ความตั้งใจที่จะมีส่วนร่วมกับแอปพลิเคชันผู้ช่วยดิจิทัล (เช่น ด้วยการตรวจจับ การแสดงตัวตนของผู้ใช้ผ่านกล้อง)
• [9.8/H-3-4] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนและแสดงการตรวจพบ คำค้นหาของผู้ใช้ใน UI ทันทีหลังจากตรวจพบคำค้นหาของผู้ใช้
• [9.8/H-3-5] ต้องไม่อนุญาตแอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้ บริการตรวจจับการค้นหาภาพ

หากการใช้งานอุปกรณ์พกพาประกาศเป็น 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() พร้อมกับการระบุแหล่งที่มาทั้งหมด ที่เกี่ยวข้อง
• [9.8.2/H-4-3] ต้องไม่ซ่อนสัญญาณบอกสถานะไมโครโฟนสำหรับ แอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง
• [9.8.2/H-4-4] ต้องแสดงรายการล่าสุดและใช้งานอยู่ แอปที่ใช้ไมโครโฟนตามที่ได้ส่งคืนจาก 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() และข้อความระบุแหล่งที่มาที่เกี่ยวข้อง
• [9.8.2/H-5-3] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับ แอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.2.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก

การใช้งานอุปกรณ์เคลื่อนที่ (* ใช้ไม่ได้กับแท็บเล็ต):

• [6.1/H-0-1]* ต้องรองรับคำสั่ง Shell cmd testharness

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.2.7 ชั้นเรียนประสิทธิภาพของสื่อแบบมือถือ

ดูส่วนที่ 7.11 สำหรับคำจำกัดความของ ระดับประสิทธิภาพของสื่อ

2.2.7.1 สื่อ

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS พวกเขาจะ:

• ต้องเป็นไปตามข้อกำหนดเกี่ยวกับสื่อที่ระบุไว้ในส่วน CDD ของ Android 14 ส่วน 2.2.7.1

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.1/H-1-1] ต้องโฆษณาจำนวนสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์ เซสชันที่สามารถทำงานพร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() วิธี

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.1/H-1-3] ต้องโฆษณาโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ถึงจำนวนสูงสุด เซสชันที่สามารถทำงานพร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() วิธี

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.1/H-1-5] ต้องโฆษณาถึงจำนวนสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์และ เซสชันตัวถอดรหัสที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() วิธี

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.1/H-1-7] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับ เซสชันการเข้ารหัสวิดีโอขนาด 1080p หรือที่เล็กกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ทั้งหมด น้อยกว่าโหลด การโหลดที่นี่หมายถึงวิดีโอแบบ 1080p ถึง 720p ที่เกิดขึ้นพร้อมกัน เซสชันการแปลงโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับความละเอียด 1080p การเริ่มต้นการบันทึกเสียง-วิดีโอ สำหรับตัวแปลงรหัส Dolby Vision ตัวแปลงรหัส เวลาในการตอบสนองการเริ่มต้นต้องไม่เกิน 50 มิลลิวินาที
• [5.1/H-1-8] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 30 มิลลิวินาทีสำหรับ เซสชันการเข้ารหัสเสียงอัตราบิต 128 kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมด น้อยกว่าโหลด การโหลดที่นี่หมายถึงวิดีโอแบบ 1080p ถึง 720p ที่เกิดขึ้นพร้อมกัน เซสชันการแปลงโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับความละเอียด 1080p การเริ่มต้นการบันทึกเสียง-วิดีโอ

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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 การเริ่มต้นเล่นเสียง-วิดีโอ

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
• [5.1/H-1-16] ต้องมีโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อย่างน้อย 1 โปรแกรมที่รองรับ 4K60

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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 มิลลิวินาทีหรือ น้อยกว่าเส้นทางข้อมูลที่รองรับอย่างน้อย 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สำหรับรูปแบบเอาต์พุตเป้าหมาย

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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 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-17] ต้องมีตัวถอดรหัสรูปภาพฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ AVIF โปรไฟล์พื้นฐาน
• [5.1/H-1-18] ต้องรองรับโปรแกรมเปลี่ยนไฟล์ AV1 ซึ่งเข้ารหัสได้สูงสุด 480p ที่ความละเอียด 30fps และ 1Mbps

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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) โดยมีอย่างน้อย 2 หน่วยที่สามารถแสดงเนื้อหาวิดีโอ 10 บิต

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [5.2/H-2-1] ต้องตรงตามเป้าหมายคุณภาพขั้นต่ำที่วิดีโอกำหนด เส้นโค้งการบิดเบี้ยวของอัตราโปรแกรมเปลี่ยนไฟล์สำหรับตัวแปลงรหัส AVC และ HEVC ของฮาร์ดแวร์ ตามที่กำหนดไว้ใน เรียกใช้การทดสอบประสิทธิภาพ Class 14 (PC14) - การทดสอบคุณภาพการเข้ารหัสวิดีโอ (VEQ)

2.2.7.2 กล้อง

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS พวกเขาจะ:

• ต้องเป็นไปตามข้อกำหนดเกี่ยวกับสื่อที่ระบุไว้ในส่วน CDD ของ Android 14 ส่วน 2.2.7.2

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอยู่ที่ อย่างน้อย 6 ล้านพิกเซลและรองรับการบันทึกวิดีโอที่ 1080p@30fps องค์ประกอบหลัก กล้องหน้าคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
• [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ในรูปแบบ FULL ขึ้นไปสำหรับบทบาทหลักด้านหลัง และ LIMITED หรือดีกว่าสำหรับตำแหน่งหลักด้านหน้า กล้อง
• [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEสำหรับทั้งการเลือกตั้งหลัก กล้อง
• [7.5/H-1-5] ต้องมีเวลาในการตอบสนองของการบันทึกภาพ Camera2 JPEG < 1,000 มิลลิวินาทีสำหรับความละเอียด 1080p ตามที่วัดโดย PerformanceTest สำหรับกล้อง CTS ภายใต้ สภาพแสงของ ITS (3,000K) สำหรับกล้องหลักทั้ง 2 ตัว
• [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูตัวอย่างแรก เฟรม) < 500 มิลลิวินาทีตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้ ITS สภาพแสง (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
• [7.5/H-1-8] ต้องรองรับ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW และ android.graphics.ImageFormat.RAW_SENSOR สำหรับกล้องหลังหลัก
• [7.5/H-1-9] ต้องมีกล้องหลักที่ด้านหลังซึ่งรองรับ 720p หรือ 1080p @ 240 fps
• [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 บทบาทหลัก กล้องหน้าและกล้องหลังหลัก
• [7.5/H-1-15] ต้องรองรับ ส่วนขยายโหมดกลางคืนผ่านทั้งส่วนขยาย 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) สำหรับกล้องหลัก

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.2.7.3 ฮาร์ดแวร์

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS กล่าวคือ

• ต้องเป็นไปตามข้อกำหนดเกี่ยวกับสื่อที่ระบุไว้ในส่วน CDD ของ Android 14 ส่วน 2.2.7.3

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [7.1.1.3/H-3-1] ต้องมีจอแสดงผล HDR ที่รองรับอย่างน้อย 1,000 นิต โดยเฉลี่ย

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.2.7.4 ประสิทธิภาพ

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS กล่าวคือ

• ต้องมีคุณสมบัติตามข้อกำหนดด้านประสิทธิภาพที่ระบุไว้ในส่วน CDD ของ Android 14 ส่วน 2.2.7.4

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [8.2/H-1-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 150 MB/วินาที
• [8.2/H-1-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/วินาที
• [8.2/H-1-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 250 MB/วินาที
• [8.2/H-1-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 100 MB/วินาที
• [8.2/H-1-5] ต้องตรวจสอบประสิทธิภาพการอ่านและเขียนตามลำดับพร้อมกัน มีประสิทธิภาพการอ่าน 2 เท่าและ 1 เท่าอย่างน้อย 50 MB/วินาที

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.2.7.5 กราฟิก

2.3 ข้อกำหนดสำหรับโทรทัศน์

อุปกรณ์ Android TV หมายถึงการใช้งานอุปกรณ์ 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] ต้องมีการรองรับเกม และประกาศแฟล็กฟีเจอร์ android.hardware.gamepad
• [7.2.7/T] ควรมีรีโมตคอนโทรลสำหรับ ผู้ใช้สามารถเข้าถึงการนำทางที่ไม่ได้สัมผัส และ ข้อมูลคีย์การนำทางหลัก

หากการใช้งานอุปกรณ์โทรทัศน์มีเครื่องวัดการหมุน 3 แกน การใช้งานจะดำเนินการดังนี้

• [7.3.4/T-1-1] ต้องรายงานเหตุการณ์ได้สูงสุด ความถี่อย่างน้อย 100 Hz
• [7.3.4/T-1-2] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้ ได้สูงสุดถึง 1000 องศาต่อวินาที

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

• [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 ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ

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

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

• [7.8.1/T] ควรมีไมโครโฟน
• [7.8.2/T-0-1] ต้องมีเอาต์พุตเสียงและประกาศ android.hardware.audio.output

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/T-0-1] H.264
• [5.2/T-0-2] VP8
• [5.2/T-0-3] AV1

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

• [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
• [5.3.2/T-0-7] AV1

การใช้งานอุปกรณ์โทรทัศน์ต้องสนับสนุนการถอดรหัส 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 ภาพต่อวินาที ระดับสูงระดับ 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 เฟรมต่อวินาทีเมื่อใช้โปรไฟล์หลักของระดับ Main10 ระดับ 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] ต้องมีการสนับสนุนสำหรับ System Master การลดทอนระดับเสียงและเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตเสียงส่งผ่านที่บีบอัด (เมื่อไม่มีการถอดรหัสเสียง) ในอุปกรณ์)

หากการใช้งานอุปกรณ์ทีวีไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน

• [5.8/T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI เป็น ความละเอียดสูงสุดสำหรับรูปแบบพิกเซลที่เลือกซึ่งทำงานร่วมกับ 50Hz หรือ 60Hz อัตราการรีเฟรชสำหรับจอแสดงผลภายนอก ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอสำหรับ ภูมิภาคที่ขายอุปกรณ์
• [5.8/T-SR-1] แนะนำอย่างยิ่งให้ผู้ใช้ดำเนินการ ตัวเลือกอัตราการรีเฟรช HDMI ที่กำหนดค่าได้
• [5.8] ควรตั้งค่าอัตราการรีเฟรชโหมดเอาต์พุต HDMI เป็น 50Hz หรือ 60Hz ทั้งนี้ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอสำหรับพื้นที่นั้นๆ มีการจำหน่ายอุปกรณ์

หากการใช้งานอุปกรณ์ทีวีไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน 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] ต้องระบุฟิลด์ การใช้งาน android.webkit.Webview API

หากใช้งานอุปกรณ์ 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 ของบุคคลที่สาม

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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 ใน 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] ต้องใช้พลังงานเช่นนี้ มีให้บริการผ่าน adb shell dumpsys batterystats เชลล์ไปยังนักพัฒนาแอป

2.3.5 โมเดลการรักษาความปลอดภัย

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

• [9/T-0-1] ต้องประกาศ android.hardware.security.model.compatible
• [9.11/T-0-1] ต้องสำรองการใช้งานคีย์สโตร์ ในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
• [9.11/T-0-2] ต้องมีการติดตั้งใช้งาน RSA, AES อัลกอริทึมการเข้ารหัส ECDSA และ HMAC รวมถึงตระกูล MD5, SHA-1 และ SHA-2 ฟังก์ชันแฮชเพื่อให้รองรับระบบ Android Keystore อัลกอริทึมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัย เคอร์เนลขึ้นไป การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมด โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของ สภาพแวดล้อมที่แยกจากกัน ซึ่งรวมถึง DMA โอเพนซอร์ส Android แบบโอเพนซอร์ส โปรเจ็กต์ (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งานทรัสตี โซลูชันแบบ ARM TrustZone หรือการตรวจสอบที่ปลอดภัยโดยบุคคลที่สาม การนำการแยกโดยใช้ไฮเปอร์ไวเซอร์ที่เหมาะสมมาใช้เป็นทางเลือก ตัวเลือก
• [9.11/T-0-3] ต้องใช้หน้าจอล็อก การตรวจสอบสิทธิ์ในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และเฉพาะเมื่อ สำเร็จ อนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ ล็อกหน้าจอ ข้อมูลเข้าสู่ระบบจะต้องได้รับการจัดเก็บไว้ในวิธีที่อนุญาตให้มีการดำเนินการที่แยกต่างหากเท่านั้น เพื่อตรวจสอบสิทธิ์หน้าจอล็อก อัปสตรีม Android โครงการโอเพนซอร์สมอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้ ตามข้อกำหนดนี้ได้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.4 ข้อกำหนดของนาฬิกา

อุปกรณ์ Android Watch หมายถึงการใช้งานอุปกรณ์ Android ที่มีจุดประสงค์เพื่อ สวมใส่บนร่างกาย บางทีอาจเป็นที่ข้อมือ

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

• หน้าจอมีความยาวเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
• มีกลไกสำหรับสวมใส่ร่างกาย

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

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 แกน ตัวตรวจวัดความเร่ง

หากการติดตั้งใช้งานอุปกรณ์นาฬิการองรับ Vulkan จะมีการดำเนินการต่อไปนี้

• [7.1.4.2/W-1-1] ต้องเป็นไปตามข้อกำหนด ที่ระบุไว้ในโปรไฟล์ Android Baseline 2021

หากอุปกรณ์นาฬิกามีตัวรับสัญญาณ GPS/GNSS และรายงาน แอปพลิเคชันผ่านฟีเจอร์ android.hardware.location.gps ไม่เหมาะสม

• [7.3.3/W-1-1] ต้องรายงานการวัด GNSS ทันที แม้ว่าจะยังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
• [7.3.3/W-1-2] ต้องรายงานช่วง Pseudorange และ Pseudorange ของ GNSS ในสภาพอากาศที่โล่งหลังจากระบุตำแหน่ง อยู่กับที่หรือการเคลื่อนที่น้อยกว่า 0.2 เมตรต่อวินาทีของ ความเร่ง ก็เพียงพอที่จะคำนวณตำแหน่งที่อยู่ในระยะ 20 เมตร และความเร็ว ภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลาทั้งหมด

หากการใช้งานอุปกรณ์นาฬิกามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้

• [7.3.4/W-2-1] ต้องสามารถวัดการเปลี่ยนการวางแนวได้ ได้สูงสุดถึง 1000 องศาต่อวินาที

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

• [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 สาธารณะทั้งหมดที่กำหนดโดยแอปพลิเคชันต่อไปนี้ Intent แสดงอยู่ที่นี่

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

• [3.8.4/W-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อใช้ Assistant ในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย

ดูการติดตั้งใช้งานอุปกรณ์ที่ประกาศ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 ใน 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] ต้องใช้พลังงานแบบนี้ มีให้บริการผ่าน adb shell dumpsys batterystats เชลล์ไปยังนักพัฒนาแอป
• [8.4/W] ควรระบุว่ามาจาก ของส่วนประกอบฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของส่วนประกอบฮาร์ดแวร์ได้ ในแอปพลิเคชัน

2.4.5 โมเดลการรักษาความปลอดภัย

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

• [9/W-0-1] ต้องประกาศ android.hardware.security.model.compatible

หากการติดตั้งใช้งานอุปกรณ์นาฬิกามีผู้ใช้หลายคน และ ไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony เนื่องจาก

• [9.5/W-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด คุณลักษณะที่ช่วยให้เจ้าของอุปกรณ์สามารถจัดการผู้ใช้เพิ่มเติมและผู้ใช้ บนอุปกรณ์ เมื่อใช้โปรไฟล์ที่ถูกจำกัด เจ้าของอุปกรณ์สามารถทำสิ่งต่อไปนี้ได้ ตั้งค่าสภาพแวดล้อมแยกต่างหากอย่างรวดเร็ว เพื่อให้ผู้ใช้เพิ่มเติมทำงานได้ ด้วยความสามารถในการจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่ ที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์นาฬิกามีผู้ใช้หลายคน และ ประกาศแฟล็กฟีเจอร์ของ android.hardware.telephony ดังนี้

• [9.5/W-2-1] ต้องไม่รองรับแบบจำกัด แต่ต้องสอดคล้องกับการปรับใช้ AOSP ของการควบคุม เพื่อเปิด /ปิด ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรและ SMS

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งใช้ TrustAgentService System API อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [9.11.1/W-1-1] ต้องตั้งคำถามผู้ใช้สำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่า 1 ครั้งในทุกๆ 72 ชั่วโมง

2.5 ข้อกำหนดด้านยานยนต์

การติดตั้งใช้งาน Android Automotive หมายถึงเครื่องเล่นวิทยุของยานพาหนะที่ทํางานอยู่ Android เป็นระบบปฏิบัติการสำหรับระบบบางส่วนหรือทั้งหมด และ/หรือ และสาระบันเทิง

การติดตั้งใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น Automotive หากมีการประกาศ ฟีเจอร์ android.hardware.type.automotive หรือมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้ เกณฑ์

• ฝังเป็นส่วนหนึ่งของหรือเชื่อมต่อกับรถยนต์ยานยนต์
• ใช้หน้าจอในแถวที่นั่งคนขับเป็นจอแสดงผลหลัก

ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้ใช้สำหรับ Android เท่านั้น การติดตั้งใช้งานอุปกรณ์ในรถยนต์

2.5.1 ฮาร์ดแวร์

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

• [7.1.1.1/A-0-1] ต้องมีหน้าจออย่างน้อย 6 หน้าจอ นิ้วในขนาดเส้นทแยงมุมจริง
• [7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจอ อย่างน้อย 750 dp x 480 dp

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับ 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 และส่งออกสัญลักษณ์ทั้งหมด

หากการติดตั้งใช้งานอุปกรณ์ Automotive รวมการรองรับ Vulkan จะมีการดำเนินการต่อไปนี้

• [7.1.4.2/A-1-1] ต้องเป็นไปตามข้อกำหนด ที่ระบุไว้ในโปรไฟล์ Android Baseline 2021

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการใช้งานอุปกรณ์ยานยนต์มีตัวตรวจวัดความเร่ง สิ่งที่จะเกิดขึ้นมีดังนี้

• [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] ขอแนะนําอย่างยิ่งให้กําหนดค่า ช่วงการวัดของเครื่องวัดการหมุนอยู่ที่ +/-250 dps เพื่อเพิ่มความละเอียดให้สูงสุด เท่าที่จะเป็นไปได้

หากอุปกรณ์ยานยนต์มีเครื่องวัดการหมุน 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)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

• [7.4.5/A] ควรมีการรองรับเครือข่ายมือถือ การเชื่อมต่อข้อมูลตามเครือข่าย
• [7.4.5/A] อาจใช้ System API ค่าคงที่ NetworkCapabilities#NET_CAPABILITY_OEM_PAID สำหรับ เครือข่ายที่ควรใช้งานได้ในแอประบบ

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

• 7.4/A-1-1 ต้องประกาศการรองรับ FEATURE_BROADCAST_RADIO

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

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

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

• [7.5/A-SR-1] แนะนำอย่างยิ่งให้ใส่ภาพแบบเผชิญโลกอย่างน้อย 1 ภาพ กล้อง
• อาจมีกล้องที่แสดงต่อผู้ใช้อย่างน้อย 1 ตัว
• [7.5/A-SR-2] ขอแนะนำอย่างยิ่งให้รองรับสตรีมมิงพร้อมกัน กล้องหลายตัว

หากการใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อย 1 ตัว แบบที่ตอบสนองกับโลกภายนอกได้ สำหรับกล้องประเภทนี้

• [7.5/A-1-1] ต้องวางแนวเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกัน ด้วยระนาบ X-Y ของแกนเซ็นเซอร์ Android Automotive
• [7.5/A-SR-3] ได้รับการแนะนำอย่างยิ่งให้ใช้การโฟกัสแบบคงที่หรือ EDOF ฮาร์ดแวร์ (ระยะชัดลึก)
• [7.5/A-1-2] ต้องมีกล้องตัวหลักแบบหันไปข้างโลก ที่มีรหัสกล้องต่ำสุด

หากการใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อย 1 ตัว สำหรับกล้องประเภทนี้

• [7.5/A-2-1] กล้องหลักที่แสดงต่อผู้ใช้ต้องเป็นกล้องที่แสดงต่อผู้ใช้ ด้วยรหัสกล้องที่ต่ำที่สุด
• อาจปรับแนวเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับ X-Y ระนาบของแกนเซ็นเซอร์ยานยนต์ของ Android

หากการติดตั้งใช้งานอุปกรณ์ Automotive มีกล้องที่เข้าถึงได้ผ่านทาง android.hardware.Camera หรือ android.hardware.camera2 API ดังต่อไปนี้

• [7.5/A-3-1] ต้องเป็นไปตามข้อกำหนดหลักของกล้องในส่วน 7.5

หากการติดตั้งใช้งานอุปกรณ์ Automotive มีกล้องที่เข้าถึงไม่ได้ ผ่าน android.hardware.Camera หรือ android.hardware.camera2 API จากนั้น ดังนี้

• [7.5/A-4-1] ต้องเข้าถึงได้ผ่านบริการ Extended View System

หากการติดตั้งใช้งานอุปกรณ์ Automotive มีกล้องอย่างน้อย 1 ตัวที่เข้าถึงได้ผ่าน Extended View System Service สำหรับกล้องประเภทนี้

• [7.5/A-5-1] ต้องไม่หมุนหรือสะท้อนภาพตัวอย่างจากกล้องในแนวนอน
• [7.5/A-SR-4] ขอแนะนำเป็นอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 เมกะพิกเซล

หากการติดตั้งใช้งานอุปกรณ์ในรถยนต์มีกล้องอย่างน้อย 1 ตัวซึ่ง เข้าถึงได้ทั้งผ่านบริการ Extended View System และ 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

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

• [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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากใช้อุปกรณ์ Automotive เป็นแบบ 64 บิต

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

• [7.7.1/A] ควรมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง

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

• [7.8.1/A-0-1] ต้องมีไมโครโฟน

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

• [7.8.2/A-0-1] ต้องมีเอาต์พุตเสียงและประกาศ android.hardware.audio.output

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.5.2 มัลติมีเดีย

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

• [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
• [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
• [5.1/A-0-3] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)

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

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

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

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ในยานยนต์เพื่อสนับสนุน การถอดรหัสวิดีโอต่อไปนี้:

• [5.3/A-SR-1] H.265 HEVC

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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.* Namespace

หากการติดตั้งใช้งานอุปกรณ์ 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] ต้องระบุฟิลด์ การใช้งาน android.webkit.Webview API

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

• [3.8.3/A-0-1] ต้องแสดงผล การแจ้งเตือนที่ใช้Notification.CarExtender API เมื่อแอปพลิเคชันของบุคคลที่สามขอ

• [3.8.4/A-SR-1] ขอแนะนําอย่างยิ่ง เพื่อใช้ Assistant ในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย

หากการใช้งานอุปกรณ์ยานยนต์มีปุ่มกดเพื่อพูด ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้

• [3.8.4/A-1-1] ต้องใช้การกดสั้นๆ ปุ่มกดเพื่อพูดเป็นการโต้ตอบที่กำหนดเพื่อเรียกใช้งาน แอปช่วยเหลือที่ผู้ใช้เลือก ซึ่งก็คือแอปที่ใช้งาน VoiceInteractionService

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

• [3.8.3.1/A-0-1] ต้องถูกต้อง แสดงผลทรัพยากรตามที่อธิบายไว้ใน Notifications on Automotive OS เอกสารเกี่ยวกับ SDK
• [3.8.3.1/A-0-2] ต้องแสดงผล PLAY และ MUTE สำหรับการดำเนินการแจ้งเตือนแทนการดำเนินการที่ดำเนินการผ่าน Notification.Builder.addAction()
• [3.8.3.1/A] ควรจำกัด ใช้งานการจัดการอย่างละเอียด เช่น การควบคุมต่อการแจ้งเตือน 1 ช่อง อาจใช้ความสามารถของ 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] ต้องรองรับ CAR_INTENT_ACTION_MEDIA_TEMPLATE การดำเนินการ Intent แบบไม่เจาะจงปลายทางด้วยฟังก์ชัน 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 Intent

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

• [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 Open โปรเจ็กต์ต้นทางมีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของ 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] ต้องใช้พลังงานเช่นนี้ มีให้บริการผ่าน 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] ต้องรองรับความสามารถในการสร้าง ผู้ใช้ชั่วคราว แม้ในกรณีที่อุปกรณ์ถึงจำนวน ผู้ใช้สูงสุดแล้ว

หากการติดตั้งใช้งานอุปกรณ์ Automotive ประกาศ 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] ต้องให้เงินแก่ผู้ใช้ในการสลับ ไมโครโฟนในแอปการตั้งค่า

หากการติดตั้งใช้งานอุปกรณ์ Automotive ประกาศ android.hardware.camera.any ให้ทําดังนี้ ดังนี้

• [9.8.2/A-2-1] ต้องแสดงสัญญาณบอกสถานะกล้องเมื่อ แอปกำลังเข้าถึงข้อมูลกล้องแบบสด แต่ไม่ใช่เมื่อกล้องใช้อยู่เท่านั้น เข้าถึงโดยแอปที่มีบทบาทตามที่กำหนดไว้ใน ส่วนที่ 9.1 สิทธิ์ ด้วยตัวระบุ CDD [C-4-X]
• [9.8.2/A-2-2] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับ แอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง
• [9.8.2/A-2-3] ต้องระบุราคาของผู้ใช้ในการสลับกล้องในแอปการตั้งค่า
• [9.8.2/A-2-4] ต้องแสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้กล้องตามที่ส่งคืน จาก PermissionManager.getIndicatorAppOpUsageData() รวมถึง ข้อความระบุแหล่งที่มาที่เชื่อมโยงกับข้อความ

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

• [9/A-0-1] ต้องประกาศ android.hardware.security.model.compatible
• [9.11/A-0-1] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ ในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
• [9.11/A-0-2] ต้องมีการติดตั้งใช้งาน RSA, AES อัลกอริทึมการเข้ารหัส ECDSA และ HMAC รวมถึงตระกูล MD5, SHA-1 และ SHA-2 ฟังก์ชันแฮชเพื่อให้รองรับระบบ Android Keystore อัลกอริทึมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัย เคอร์เนลขึ้นไป การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมด โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของ สภาพแวดล้อมที่แยกจากกัน ซึ่งรวมถึง DMA โอเพนซอร์ส Android แบบโอเพนซอร์ส โปรเจ็กต์ (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งานทรัสตี โซลูชันแบบ ARM TrustZone หรือการตรวจสอบที่ปลอดภัยโดยบุคคลที่สาม การนำการแยกโดยใช้ไฮเปอร์ไวเซอร์ที่เหมาะสมมาใช้เป็นทางเลือก ตัวเลือก
• [9.11/A-0-3] ต้องใช้หน้าจอล็อก การตรวจสอบสิทธิ์ในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และเฉพาะเมื่อ สำเร็จ อนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ ล็อกหน้าจอ ข้อมูลเข้าสู่ระบบจะต้องได้รับการจัดเก็บไว้ในวิธีที่อนุญาตให้มีการดำเนินการที่แยกต่างหากเท่านั้น เพื่อตรวจสอบสิทธิ์หน้าจอล็อก อัปสตรีม Android โครงการโอเพนซอร์สมอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้ ตามข้อกำหนดนี้ได้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

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

• [9.14/A-0-1] ต้องมีข้อความกันขโมย จากระบบย่อยของยานพาหนะในเฟรมเวิร์ก Android เช่น ข้อความที่อนุญาตในรายการที่อนุญาต และแหล่งที่มาของข้อความ
• [9.14/A-0-2] ต้องเฝ้าระวัง การโจมตีแบบปฏิเสธการให้บริการจากเฟรมเวิร์กของ Android หรือแอปของบุคคลที่สาม ช่วงเวลานี้ ป้องกันซอฟต์แวร์ที่เป็นอันตรายที่ทำให้การจราจรคล่องตัวในเครือข่ายของรถ ซึ่งอาจทำให้ระบบย่อยของยานพาหนะทำงานผิดพลาด

2.5.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

2.6 ข้อกำหนดสำหรับแท็บเล็ต

อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่ มักจะเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด

• ใช้โดยถือไว้ในมือทั้ง 2 ข้าง
• ไม่มีการกำหนดค่าแบบฝาพับหรือแบบพับจอได้
• การใช้แป้นพิมพ์จริงที่ใช้กับอุปกรณ์เชื่อมต่อโดย วิธีการเชื่อมต่อมาตรฐาน (เช่น USB, บลูทูธ)

• มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่

• มีขนาดการแสดงผลของหน้าจอใหญ่กว่า 7 นิ้วและน้อยกว่า 18 นิ้ว โดยวัดในแนวทแยง

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

2.6.1 ฮาร์ดแวร์

เครื่องวัดการหมุน

หากอุปกรณ์แท็บเล็ตมีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้

• [7.3.4/Tab-1-1] ต้องวัดการวางแนวได้ เปลี่ยนได้ถึง 1000 องศาต่อวินาที

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

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

โหมด Virtual Reality (ส่วนที่ 7.9.1)

ความเป็นจริงเสมือนประสิทธิภาพสูง (ส่วนที่ 7.9.2)

ข้อกำหนดเกี่ยวกับ Virtual Reality ใช้ไม่ได้กับแท็บเล็ต

2.6.2 โมเดลการรักษาความปลอดภัย

คีย์และข้อมูลเข้าสู่ระบบ (ส่วนที่ 9.11)

โปรดดูหัวข้อ [9.11]

หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและ ไม่ประกาศ Flag ฟีเจอร์ 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] ต้องสนับสนุน/รักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมด ที่ระบุโดยคำอธิบายประกอบ 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 ทั้งหมดในส่วนเดียวกันและอินเทอร์เฟซที่ไม่ใช่ SDK เดียวกัน ตามที่ระบุไว้ผ่านแฟล็กชั่วคราวและรายการที่ปฏิเสธใน prebuilts/runtime/appcompat/hiddenapi-flags.csv เส้นทางสำหรับสาขาระดับ API ที่เหมาะสมใน AOSP

• [C-0-7] ต้องรองรับการกำหนดค่าที่ลงนาม กลไกการอัปเดตแบบไดนามิกเพื่อนำอินเทอร์เฟซที่ไม่ใช่ SDK ออกจากรายการที่ถูกจำกัด ด้วยการฝังการกำหนดค่าที่ลงนามไว้ใน APK ใดๆ ก็ตาม โดยใช้คีย์สาธารณะที่มีอยู่ ที่อยู่ใน AOSP

  อย่างไรก็ตาม

  • อาจหากไม่มี API ที่ซ่อนไว้หรือมีการใช้งานในอุปกรณ์ที่แตกต่างออกไป ให้ย้าย API ที่ซ่อนอยู่ไปไว้ในรายการที่ปฏิเสธ หรือละเว้น API นั้น รายชื่อที่ถูกจำกัดทั้งหมด
  • หากยังไม่มี API ที่ซ่อนไว้ใน AOSP ให้เพิ่ม API ไปยังรายชื่อที่ถูกจำกัด

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.1.1. ส่วนขยาย Android

Android รองรับการขยายแพลตฟอร์ม API ที่มีการจัดการของระดับ API เฉพาะโดย อัปเดตเวอร์ชันส่วนขยายสำหรับ API ระดับนั้น android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API จะแสดงผล เวอร์ชันส่วนขยายของ apiLevel ที่ให้ไว้ หากมีส่วนขยาย ระดับ API

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

• [C-0-1] ต้องโหลดการใช้งาน AOSP ของไลบรารีที่ใช้ร่วมกันทั้ง 2 แบบล่วงหน้า 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

เนื่องจากการเลิกใช้งานไคลเอ็นต์ Apache HTTP การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องไม่วางไลบรารี org.apache.http.legacy ไว้ในส่วน Bootclasspath
• [C-0-2] ต้องเพิ่มไลบรารี org.apache.http.legacy ลงในแอปพลิเคชัน classpath เฉพาะเมื่อแอปเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้
  • กำหนดเป้าหมาย API ระดับ 28 หรือต่ำกว่า
  • ประกาศในไฟล์ Manifest ว่าต้องมีไลบรารีโดยการตั้งค่า แอตทริบิวต์ android:name ของ <uses-library> เป็น org.apache.http.legacy

การติดตั้งใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้

3.2 ความเข้ากันได้ของ Soft API

นอกจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมีฟีเจอร์ "Soft" สำหรับรันไทม์เท่านั้น API ในรูปแบบของ เช่น ความตั้งใจ สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ไม่สามารถบังคับใช้ในเวลาคอมไพล์แอปพลิเคชัน

3.2.1. สิทธิ์

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

3.2.2 พารามิเตอร์บิลด์

API ของ Android มีค่าคงที่ใน ชั้นเรียน android.os.Build ที่ใช้อธิบายอุปกรณ์ปัจจุบัน

• [C-0-1] เพื่อให้ค่าที่มีความหมายและสอดคล้องกันในทุกอุปกรณ์ ตารางด้านล่างนี้จะรวมถึงข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบ ของค่าเหล่านี้ซึ่งการติดตั้งใช้งานอุปกรณ์ต้องสอดคล้อง

พารามิเตอร์	รายละเอียด
VERSION.RELEASE	เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบัน ในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน สตริงเวอร์ชันที่อนุญาตสำหรับ Android 15
VERSION.SDK	เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบ รหัสแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 15 ช่องนี้ต้องมีค่าจำนวนเต็ม 15_INT
VERSION.SDK_INT	เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบ รหัสแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 15 ช่องนี้ต้องมีค่าจำนวนเต็ม 15_INT
เวอร์ชันที่เพิ่มขึ้น	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์ที่เฉพาะเจาะจง ของระบบ Android ที่กำลังเรียกใช้อยู่ ในรูปแบบที่มนุษย์อ่านได้ ช่วงเวลานี้ ต้องไม่นําค่ามาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางใช้งานได้ ต การใช้งานตามปกติของฟิลด์นี้คือ เพื่อระบุหมายเลขบิลด์หรือ มีการใช้ตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาในการสร้างบิลด์ ค่า ของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตที่พิมพ์ได้ และตรงกับ นิพจน์ทั่วไป ^[^ :\/~]+$
กระดาน	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุถึง ฮาร์ดแวร์ภายในที่อุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ เป็นไปได้ ช่องนี้ใช้เพื่อระบุเวอร์ชันที่เจาะจงของการจ่ายไฟของบอร์ด อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและ ตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$
แบรนด์	ค่าที่แสดงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ ผู้ใช้ปลายทาง ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้และควรแสดงถึง ผู้ผลิตอุปกรณ์หรือแบรนด์บริษัทที่ใช้อุปกรณ์ดังกล่าว ในการทำการตลาด ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและตรงกัน นิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$
แถบ&ปิดที่รองรับ;ABIS	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
รองรับ_32_BIT_ABIS	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
รองรับ_64_BIT_ABIS	ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของ โค้ดแบบเนทีฟ ดูส่วนที่ 3.3 เนทีฟ ความเข้ากันได้กับ API
แถบ&โลว์บาร์;ABI	ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
แถบ&โลว์บาร์;ABI2	ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของ โค้ดแบบเนทีฟ ดูส่วนที่ 3.3 เนทีฟ ความเข้ากันได้กับ API
อุปกรณ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนา หรือชื่อรหัสที่ระบุการกำหนดค่าฟีเจอร์ของฮาร์ดแวร์และ การออกแบบเชิงอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสได้ เป็น ASCII แบบ 7 บิต และจับคู่นิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$ ชื่ออุปกรณ์นี้จะต้องไม่เปลี่ยนชื่อในระหว่าง อายุการใช้งานของผลิตภัณฑ์
Fingerprint	สตริงที่ระบุบิลด์นี้ได้โดยไม่ซ้ำกัน ควรมีเหตุผล ที่มนุษย์อ่านได้ ต้องเป็นไปตามเทมเพลตนี้ $(BRAND)/$(ผลิตภัณฑ์)/ $(DEVICE):$(VERSION.RELEASE)/$(รหัส)/$(VERSION.INCREMENTAL):$(ประเภท)/$(แท็ก) เช่น acme/myproduct/ mydevice:15/LMYXX/3359:userdebug/test-keys ลายนิ้วมือต้องไม่มีอักขระช่องว่าง ค่าของ ช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต
ฮาร์ดแวร์	ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) ทั้งนี้ ควรให้มนุษย์อ่านเข้าใจได้พอสมควร ค่าของช่องนี้ต้องเป็น เข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$
ผู้จัด	สตริงที่ระบุโฮสต์ที่สร้างบิลด์โดยไม่ซ้ำกัน ที่มนุษย์อ่านได้ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของ ฟิลด์นี้ เว้นแต่ว่าช่องจะต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("")
รหัส	ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างถึง เผยแพร่ในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่เพียงพอ มีความหมายต่อผู้ใช้ปลายทาง เพื่อแยกระหว่างรุ่นซอฟต์แวร์ต่างๆ ค่า ของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ ^[a-zA-Z0-9._-]+$
ผู้ผลิต	ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของบริษัท ผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ว่าต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("") ฟิลด์นี้ ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC_ผู้ผลิต	การแลกเปลี่ยนชื่อผู้ผลิต ระบบหลัก บน ชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SOC รายเดียวกัน ควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC สำหรับ ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสได้ เป็น ASCII แบบ 7 บิต ต้องตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z ]+) ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ช่องนี้ต้องไม่เปลี่ยนแปลงในระหว่าง อายุการใช้งานของผลิตภัณฑ์
&โมเดล SOC	ชื่อรุ่นของระบบหลักบนชิป (SOC) ที่ใช้ใน ผลิตภัณฑ์ อุปกรณ์ที่มี SOC รุ่นเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อใช้ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป ^([0-9A-Za-z ._/+-]+)$ ต้องไม่ขึ้นต้นหรือ ลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ฟิลด์นี้ ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
MODEL	ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่อของ อุปกรณ์ที่ผู้ใช้ปลายทางทราบ ชื่อนี้ควรเป็นชื่อเดียวกับที่ มีการทำการตลาดและขายอุปกรณ์ให้กับผู้ใช้ปลายทาง ไม่มีข้อกำหนดสำหรับ รูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าต้องเป็นค่าว่าง หรือ สตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงในระหว่าง อายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนา หรือรหัสของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) ที่ต้องไม่ซ้ำกันภายใน แบรนด์เดียวกัน ต้องเป็นภาษาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับการดู จากผู้ใช้ปลายทาง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและ ตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$ ผลิตภัณฑ์นี้ ชื่อต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ODM_SKU	ค่าที่ไม่บังคับซึ่งผู้ให้บริการอุปกรณ์เลือกซึ่งมี SKU (Stock Keeping Unit) ใช้เพื่อติดตามการกำหนดค่าที่เจาะจงของ เช่น อุปกรณ์ต่อพ่วงใดๆ ที่รวมอยู่ในอุปกรณ์เมื่อจำหน่าย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป ^([0-9A-Za-z.,_-]+)$
ซีเรียล	ต้องส่งคืน "UNKNOWN"
แท็ก	รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ให้บริการอุปกรณ์เลือก สร้างความโดดเด่นให้กับงานสร้างมากเป็นพิเศษ แท็กต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9._-]+ และ "ต้อง" มีค่าใดค่าหนึ่งที่สอดคล้องกับแพลตฟอร์ม Android ทั่วไป 3 แพลตฟอร์ม การกำหนดค่าการรับรอง: คีย์การเผยแพร่, คีย์นักพัฒนาซอฟต์แวร์ และคีย์การทดสอบ
เวลา	ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์
ประเภท	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุรันไทม์ ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่ง ตามการกำหนดค่ารันไทม์ทั่วไปของ Android 3 แบบ ได้แก่ ผู้ใช้ การแก้ไขข้อบกพร่องของผู้ใช้ หรือการมีส่วนร่วม
ผู้ใช้	ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้าง งานสร้าง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ว่าต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("")
แถบ&โลว์บาร์;แพตช์	ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องแสดงถึง การสร้างแอปไม่ได้มีช่องโหว่ต่อปัญหาใดๆ ที่อธิบายไว้ ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ ต้องเป็น รูปแบบ [YYYY-MM-DD] ตรงกับสตริงที่กำหนดซึ่งระบุไว้ใน ความปลอดภัยสาธารณะของ Android กระดานข่าวสารหรือใน คำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01"
แถบ_ระบบปฏิบัติการ	ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่ หรือเหมือนกันกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ใน กระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android จะต้องรายงานค่าที่ถูกต้อง และถ้า ไม่มีบิลด์ดังกล่าว รายงานสตริงว่างเปล่า ("")
รองเท้าบู๊ต	ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุถึง เวอร์ชัน Bootloader ภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป ^[a-zA-Z0-9._-]+$
getRadioVersion()	ต้อง (หรือส่งคืน) ค่าที่เลือกโดยผู้ใช้อุปกรณ์ ระบุเวอร์ชันวิทยุ/โมเด็มภายในที่ใช้ในอุปกรณ์ ในรูปแบบที่มนุษย์อ่านได้ ถ้าอุปกรณ์ไม่มีภายใน Radio/modem ต้องแสดงผลเป็น 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 มีรายการ แอปพลิเคชันซึ่งใช้รูปแบบความตั้งใจหลายแบบเพื่อทำงานทั่วไป

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

• [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 ที่ ดำเนินการตามรูปแบบความตั้งใจหรือจุดประสงค์ในการออกอากาศใหม่ๆ โดยใช้ ACTION, CATEGORY หรือ สตริงคีย์อื่นๆ ในเนมสเปซ android.* หรือ com.android.*
• [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่มีองค์ประกอบ Android ที่ ยึดรูปแบบความตั้งใจหรือความตั้งใจใหม่ๆ ในการออกอากาศโดยใช้ ACTION, CATEGORY หรือ สตริงคีย์อื่นในพื้นที่แพ็กเกจที่เป็นขององค์กรอื่น
• [C-0-3] ผู้ปฏิบัติงานใช้อุปกรณ์ต้องไม่เปลี่ยนแปลงหรือขยายเจตนาใดๆ รูปแบบที่แสดงในหัวข้อ 3.2.3.1
• การใช้งานอุปกรณ์อาจรวมรูปแบบความตั้งใจที่ใช้เนมสเปซอย่างชัดเจน และเห็นได้ชัดว่ามีความเชื่อมโยงกับองค์กรของตน ข้อห้ามนี้ ซึ่งคล้ายกับที่ระบุสำหรับคลาสภาษา Java ในส่วนที่ 3.6

3.2.3.4 ความตั้งใจในการออกอากาศ

แอปพลิเคชันของบุคคลที่สามต้องอาศัยแพลตฟอร์มในการเผยแพร่ความตั้งใจบางอย่างเพื่อ แจ้งการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์

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

• [C-0-1] ต้องประกาศเจตนารมณ์ในการออกอากาศสู่สาธารณะตามที่แสดงรายการไว้ที่นี่ เพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสมตามที่อธิบายไว้ในเอกสารประกอบของ SDK โปรดทราบว่าข้อกำหนดนี้ไม่ขัดแย้งกับส่วนที่ 3.5 เนื่องจาก มีการอธิบายข้อจำกัดด้านแอปพลิเคชันในพื้นหลังไว้ใน SDK ด้วย เอกสารประกอบ นอกจากนี้ จุดประสงค์การออกอากาศบางรายการขึ้นอยู่กับเงื่อนไขของฮาร์ดแวร์ หากอุปกรณ์รองรับฮาร์ดแวร์ที่จำเป็น ก็ต้องเผยแพร่ Intent และระบุลักษณะการทำงานไปพร้อมกับเอกสาร 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 เป็น รวมถึงบัญชีโทรศัพท์เริ่มต้นซึ่งผู้ให้บริการโทรคมนาคม ใช้ในการโทรออก การติดตั้งใช้งาน 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 Intent และระบุกิจกรรมเพื่อส่ง/แสดงข้อความ 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 เหล่านี้ได้และ มอบการดำเนินการให้สมบูรณ์ตามที่อธิบายไว้ใน SDK

หากการติดตั้งใช้งานอุปกรณ์รายงาน 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' Intent และแสดงกิจกรรมของระบบเพื่ออนุญาตให้ผู้ใช้เปิดบลูทูธ
• [C-5-2] ต้องเคารพ "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" Intent และแสดงกิจกรรมของระบบที่ขอโหมดที่ค้นพบได้

หากอุปกรณ์รองรับฟีเจอร์ DND ระบบจะดำเนินการดังต่อไปนี้

• [C-6-1] ต้องดำเนินกิจกรรมที่จะตอบสนองต่อความตั้งใจ ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS ซึ่งสำหรับการปรับใช้กับ UI_MODE_TYPE_NORMAL ข้อมูลดังกล่าวจะต้องเป็นกิจกรรมที่ ผู้ใช้สามารถให้หรือปฏิเสธการเข้าถึงแอปในการกำหนดค่านโยบาย DND

หากการใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามใน ได้

• [C-7-1] ต้องระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกำหนดค่า วิธีการป้อนข้อมูลของบุคคลที่สามเพื่อตอบสนองต่อ android.settings.INPUT_METHOD_SETTINGS Intent

หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้

• [C-8-1] ต้องปฏิบัติตาม android.settings.ACCESSIBILITY_SETTINGS ในการมอบกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดใช้และปิดใช้ บริการการช่วยเหลือพิเศษของบุคคลที่สามควบคู่ไปกับการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า บริการต่างๆ

หากการใช้งานอุปกรณ์มีการสนับสนุนสำหรับ Wi-Fi Easy Connect และการเปิด ไปยังแอปของบุคคลที่สามได้

• [C-9-1] ต้องใช้การตั้งค่า#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] ต้องเคารพเจตนา android.app.action.ADD_DEVICE_ADMIN เพื่อเรียกใช้ UI เพื่อให้ผู้ใช้เพิ่ม ผู้ดูแลระบบอุปกรณ์ลงใน ระบบ (หรืออนุญาตให้ปฏิเสธ)

• [C-13-2] ต้องเคารพเจตนารมณ์ android.app.action.PROVISION_MANAGED_PROFILE android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD android.app.action.SET_NEW_PASSWORD และ android.app.actionSTART_ENCRYPTION และมีกิจกรรมเพื่อให้บรรลุผลสำหรับ Intent ดังกล่าวตามที่อธิบายไว้ ใน SDK ได้ที่นี่

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.autofill แฟล็กฟีเจอร์

• [C-14-1] ต้องใช้ AutofillService อย่างสมบูรณ์ และ AutofillManager API และใช้ android.settings.REQUEST_SET_AUTOFILL_SERVICE ต้องการแสดงเมนูการตั้งค่าแอปเริ่มต้นเพื่อเปิดใช้และปิดใช้การป้อนข้อความอัตโนมัติ และ เปลี่ยนบริการป้อนข้อความอัตโนมัติเริ่มต้นให้ผู้ใช้

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

• [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้มีกลไกที่ให้ผู้ใช้เข้าถึงได้ในการให้ หรือเพิกถอนการเข้าถึงสถิติการใช้งานตาม android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent สำหรับแอปที่ประกาศandroid.permission.PACKAGE_USAGE_STATS สิทธิ์

หากการใช้งานอุปกรณ์ตั้งใจจะไม่อนุญาตแอปใด ๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า ไม่ให้เข้าถึงสถิติการใช้งาน พวกเขาจะ:

• [C-15-1] ต้องมีกิจกรรมที่จัดการ android.settings.ACTION_USAGE_ACCESS_SETTINGS รูปแบบ Intent แต่ "ต้อง" ใช้ "ไม่มีการดำเนินการ" กล่าวคือ ต้องมีค่าเทียบเท่า เหมือนตอนที่ผู้ใช้ถูกปฏิเสธการเข้าถึง

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

• [C-16-1] ต้องแสดงลิงก์ดังกล่าวสำหรับบริการป้อนข้อความอัตโนมัติทั้งหมดที่ติดตั้งไว้

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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 และ Intent android.speech.tts.engine.GET_SAMPLE_TEXT มีกิจกรรมที่จะแจ้ง Fulfillment สำหรับ Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่

Android รองรับภาพพักหน้าจอแบบอินเทอร์แอกทีฟ เหมือนความฝัน โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้สามารถโต้ตอบกับแอปพลิเคชันเมื่ออุปกรณ์ ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่บนแท่นชาร์จ การใช้งานอุปกรณ์:

• ควรรองรับภาพพักหน้าจอและเสนอตัวเลือกการตั้งค่าสำหรับ ผู้ใช้ให้กำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อ Intent android.settings.DREAM_SETTINGS

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.uicc หรือ android.hardware.nfc.ese ดังนี้

• [C-19-1] ต้องใช้ NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (ดังที่ "EVT_TRANSACTION" กำหนดไว้ตามข้อกำหนดทางเทคนิคของการเชื่อมโยง GSM TS.26 - ข้อกำหนดของเครื่องโทรศัพท์ NFC)

3.2.4 กิจกรรมบนจอแสดงผลรอง/หลายจอแสดงผล

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม Android ปกติมากกว่า จอแสดงผลเดียว โดยจะ

• [C-1-1] ต้องตั้งค่า android.software.activities_on_secondary_displays แฟล็กฟีเจอร์
• [C-1-2] ต้องรับประกันความเข้ากันได้ของ API ที่คล้ายกับกิจกรรมที่ทำงานอยู่ จอแสดงผลหลัก
• [C-1-3] ต้องลงจอดกิจกรรมใหม่บนจอแสดงผลเดียวกับกิจกรรมที่ เปิดใช้งานแล้ว เมื่อมีการเปิดตัวกิจกรรมใหม่โดยไม่ระบุเป้าหมาย แสดงผ่านActivityOptions.setLaunchDisplayId() API
• [C-1-4] ต้องทำลายกิจกรรมทั้งหมดเมื่อจอแสดงผลที่มี Display.FLAG_PRIVATE ธงถูกลบ
• [C-1-5] ต้องซ่อนเนื้อหาบนทุกหน้าจออย่างปลอดภัยเมื่ออุปกรณ์ล็อกอยู่ ที่มีหน้าจอล็อกที่ปลอดภัย เว้นแต่แอปจะเลือกให้แสดงบนล็อก หน้าจอโดยใช้ 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 ที่เรียงลำดับจากมากที่สุดไปน้อยที่สุด

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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 ทั้งหมด สัญลักษณ์ฟังก์ชัน ตามที่กำหนดไว้ใน NDK ผ่านไลบรารี libGLESv3.so โปรดทราบว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.1 จะอธิบาย รายละเอียดเพิ่มเติมเกี่ยวกับข้อกำหนดในการติดตั้งใช้งาน ฟังก์ชันที่เกี่ยวข้อง

• [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับแกนหลัก ฟังก์ชัน Vulkan 1.1 สัญลักษณ์ต่างๆ รวมถึง 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

หากการติดตั้งใช้งานอุปกรณ์ทำให้มีการติดตั้งใช้งาน android.webkit.Webview API ซึ่งจะมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงาน android.software.webview
• [C-1-2] ต้องใช้บิลด์โปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางบน Android 15 สาขาสําหรับการติดตั้งใช้งาน android.webkit.WebView API

• [C-1-3] สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบต่อไปนี้

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) เวอร์ชัน/4.0 $(CHROMIUM_VER) อุปกรณ์เคลื่อนที่ Safari/537.36

  • ค่าของสตริง $(VERSION) ต้องเท่ากับค่าของสตริง android.os.Build.VERSION.RELEASE
  • สตริง $(MODEL) อาจว่างเปล่า แต่ถ้าสตริงไม่ว่างเปล่า สตริงนี้ต้องมี ค่าเดียวกับ android.os.Build.MODEL
  • "สร้าง/$(สร้าง)" อาจละเว้นได้ แต่หากเป็น $(BUILD) สตริงต้องเป็นค่าเดียวกับค่า android.os.Build.ID
  • ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชัน Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
  • การใช้งานอุปกรณ์อาจเว้น "อุปกรณ์เคลื่อนที่" ในสตริง User Agent

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

• [C-1-4] ต้องแสดงผลเนื้อหาที่ให้ไว้หรือเนื้อหา URL ระยะไกลในกระบวนการ ที่แตกต่างจากแอปพลิเคชันที่สร้างอินสแตนซ์ WebView โดยเฉพาะ กระบวนการแสดงผลที่แยกต่างหากต้องถือสิทธิ์ในระดับต่ำกว่า เรียกใช้ เป็นรหัสผู้ใช้แยกต่างหาก ไม่มีสิทธิ์เข้าถึงไดเรกทอรีข้อมูลของแอป ไม่มีการเข้าถึงเครือข่ายโดยตรง และมีเพียงการเข้าถึงเครือข่ายอินเทอร์เน็ตขั้นต่ำ บริการระบบผ่าน Binder การใช้ AOSP ของ WebView เป็นไปตาม ข้อกำหนดนี้

โปรดทราบว่าหากอุปกรณ์เป็นแบบ 32 บิต หรือประกาศแฟล็กฟีเจอร์ android.hardware.ram.low บุคคลเหล่านี้ได้รับการยกเว้นจาก C-1-3

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

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

• [C-1-1] ต้องรองรับ API แต่ละรายการเหล่านี้ที่เชื่อมโยงกับ HTML5
  • แคช/การดำเนินการออฟไลน์ของแอปพลิเคชัน
  • <video> แท็ก
  • ตำแหน่งทางภูมิศาสตร์
• [C-1-2] ต้องรองรับ HTML5/W3C webstorage API และควรรองรับ 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 ทำงาน ความเข้ากันได้ด้านลักษณะการทำงานสำหรับแอปที่เลือกตามอุปกรณ์เท่านั้น ของ Google

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

• [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของ Intent มาตรฐาน
• [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรืออรรถศาสตร์ของ ประเภทของคอมโพเนนต์ระบบที่เฉพาะเจาะจง (เช่น บริการ กิจกรรม ผู้ให้บริการเนื้อหา ฯลฯ)
• [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
• อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันในเบื้องหลัง กล่าวอย่างเจาะจงคือ สำหรับแอปพื้นหลัง
  • [C-0-4] ลูกค้าต้องหยุดการดำเนินการ Callback ที่จดทะเบียนโดย เพื่อรับเอาต์พุตจาก GnssMeasurement และ GnssNavigationMessage
  • [C-0-5] พวกเขาต้องจำกัดความถี่ในการอัปเดตที่ ซึ่งได้รับจากบริการผ่าน LocationManager คลาส API หรือ WifiManager.startScan()
  • [C-0-6] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป พวกเขาต้องไม่ อนุญาตให้ลงทะเบียน Broadcast Receiver สำหรับการออกอากาศโดยนัยของ Intent มาตรฐานของ Android ในไฟล์ Manifest ของแอป เว้นแต่จะเป็นการออกอากาศ Intent ต้องมี "signature" หรือ "signatureOrSystem" protectionLevel หรืออยู่ใน รายการยกเว้น
  • [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปจะต้องหยุด บริการพื้นหลังของแอปพลิเคชัน ราวกับว่าแอปพลิเคชันได้เรียกใช้ บริการ stopSelf() ยกเว้นในกรณีที่แอปนั้นอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการ งานที่ผู้ใช้มองเห็นได้
  • [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป พวกเขาต้อง ปล่อยการทำงานขณะล็อกที่แอปพักการทำงาน
• [C-0-11] อุปกรณ์ต้องส่งผู้ให้บริการด้านความปลอดภัยต่อไปนี้เป็นผู้ให้บริการแรก ค่าอาร์เรย์ 7 ค่าจาก Security.getProviders() ในลำดับที่ระบุ และมีชื่อที่ระบุ (ตามที่ส่งคืนโดย Provider.getName()) และชั้นเรียน ยกเว้นกรณีที่แอปมีการแก้ไขรายการผ่าน insertProviderAt() หรือ removeProvider() อุปกรณ์ อาจแสดงผลผู้ให้บริการเพิ่มเติมหลังจากรายชื่อผู้ให้บริการที่ระบุ ที่ด้านล่าง
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCวิธีแก้ปัญหา - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น การทดสอบชุดทดสอบความเข้ากันได้ (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] ต้องแสดงผลเป็น true สำหรับ 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 หรืออะไรก็ตามที่จะทำให้แอปออกจากสถานะบังคับให้หยุด ซึ่งรวมถึงการผูกบริการ การผูกผู้ให้บริการเนื้อหา การออกอากาศที่ชัดแจ้ง ฯลฯ ซึ่งจะติดตามโดย API UsageStats#getLastTimeAnyComponentUsed() ใหม่
• [C-1-3] ต้องใช้ข้อจำกัดที่มีผลต่อผู้ใช้อุปกรณ์ทั้งหมดเท่านั้น เป็นหลักฐานว่าไม่มีการใช้แพ็กเกจโดยผู้ใช้ใดๆ เป็นเวลาระยะหนึ่ง เราขอแนะนำอย่างยิ่งให้กำหนดระยะเวลานี้อย่างน้อย 1 เดือน
• [C-1-4] ต้องไม่แสดงผลแอปไม่สามารถตอบสนองต่อความตั้งใจของกิจกรรม การเชื่อมโยงบริการ คำขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่อาจไม่เหมาะสม

การไฮเบอร์เนตของแอปใน 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 มาตรฐานได้ Namespace แต่ API ที่กำหนดเองมีลักษณะดังนี้

• [C-0-5] ต้องไม่อยู่ในเนมสเปซที่คุณเป็นเจ้าของหรืออ้างอิงถึง องค์กร ตัวอย่างเช่น ผู้ใช้อุปกรณ์ต้องไม่เพิ่ม API ลงใน com.google.* หรือเนมสเปซที่คล้ายกัน: มีเพียง Google เท่านั้นที่ดำเนินการได้ ในทำนองเดียวกัน Google ต้องไม่เพิ่ม API ให้กับบริษัทอื่น เนมสเปซ
• [C-0-6] ต้องจัดแพ็กเกจในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้เฉพาะแอป ที่ใช้งานอย่างชัดเจน (ผ่านกลไก <uses-library>) ได้แก่ ได้รับผลกระทบจากการใช้งานหน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว

ผู้ใช้อุปกรณ์อาจเพิ่ม API ที่กำหนดเองในภาษาท้องถิ่นนอก NDK ได้ API เฉพาะ API ที่กำหนดเอง

• [C-1-1] ต้องไม่อยู่ในห้องสมุด NDK หรือห้องสมุดของผู้อื่น องค์กรตามที่อธิบายไว้ ที่นี่

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

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

3.7 ความเข้ากันได้ของรันไทม์

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

• [C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) แบบเต็ม และข้อมูลจำเพาะและความหมายของไบต์โค้ด Daalvik

• [C-0-2] ต้องกำหนดค่ารันไทม์ของ Dalvik เพื่อจัดสรรหน่วยความจำ ตามแพลตฟอร์ม Android อัปสตรีม และตามที่ระบุโดย ตารางต่อไปนี้ (ดูส่วนที่ 7.1.1 สำหรับ ขนาดหน้าจอและความหนาแน่นของหน้าจอ)

• ควรใช้ Android RunTime (ART) ซึ่งเป็นอัปสตรีมอ้างอิง การนำรูปแบบปฏิบัติการของ Dalvik มาใช้และการอ้างอิง การจัดการแพ็กเกจของการนำไปใช้งาน

• ควรทำการทดสอบ 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 ของบริการ ShortcutManager คลาส API

หากการใช้งานอุปกรณ์มีแอป Launcher เริ่มต้นที่แสดงป้าย ไอคอนแอปได้

• [C-5-1] ต้องเป็นไปตาม NotificationChannel.setShowBadge() เมธอดของ API กล่าวคือ แสดงภาพในราคาที่เกี่ยวข้องกับไอคอนแอปหาก ได้รับการตั้งค่าเป็น 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] แนะนำอย่างยิ่งให้ทางเลือกแก่ผู้ใช้ในการระบุ แอปที่ยกเว้นไม่ให้แจ้งเตือนผู้ฟังการแจ้งเตือนที่เจาะจงได้

• [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] ต้องใช้แหล่งข้อมูลที่ถูกต้อง ที่ให้บริการผ่าน Notification.Style คลาส API และคลาสย่อยสำหรับองค์ประกอบทรัพยากรที่แสดง
• ควรนำเสนอองค์ประกอบทรัพยากรทั้งหมด (เช่น ไอคอน ชื่อ และข้อความสรุป) ที่กำหนดไว้ใน Notification.Style คลาส API และคลาสย่อย

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

• [C-3-1] ต้องใช้มุมมองทรัพยากรการแจ้งเตือนล่วงหน้าและทรัพยากร ตามที่อธิบายไว้ใน Notification.Builder คลาส API เมื่อมีการแสดงการแจ้งเตือนล่วงหน้า
• [C-3-2] ต้องแสดงการดำเนินการที่ได้จาก Notification.Builder.addAction() กับเนื้อหาการแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ ตามที่อธิบายไว้ใน SDK

3.8.3.2 บริการฟังการแจ้งเตือน

Android มี NotificationListenerService API ที่อนุญาตให้แอป (เมื่อเปิดใช้อย่างชัดแจ้งโดยผู้ใช้) รับสำเนาของ การแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต

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

• [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงที บริการ Listener ที่ติดตั้งและเปิดใช้ ดังกล่าวทั้งหมด รวมถึง ข้อมูลเมตาทั้งหมดที่แนบมากับออบเจ็กต์การแจ้งเตือน
• [C-0-2] ต้องเป็นไปตาม snoozeNotification() เรียก API และปิดการแจ้งเตือนและทำการติดต่อกลับหลังจากปิดเสียงเตือนชั่วคราว ระยะเวลาที่กำหนดไว้ในการเรียก 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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.8.3.4 การป้องกันการแจ้งเตือนที่มีความละเอียดอ่อน

3.8.4 API การสนับสนุน

Android มี Assist API เพื่อให้แอปพลิเคชันเลือกได้ว่าจะให้ ข้อมูลในบริบทปัจจุบันมากน้อยแค่ไหน แชร์กับ Assistant ในอุปกรณ์

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

• [C-2-1] ต้องระบุอย่างชัดเจนถึงผู้ใช้ปลายทางเมื่อมีการแชร์บริบท โดย อย่างใดอย่างหนึ่งต่อไปนี้
  • ทุกครั้งที่แอปผู้ช่วยเข้าถึงบริบท ระบบจะแสดงไอคอนสีขาว รอบขอบหน้าจอที่ด้านหรือเกินระยะเวลาและ ความสว่างของการติดตั้งใช้งานโปรเจ็กต์โอเพนซอร์ส Android
  • สำหรับแอปผู้ช่วยที่ติดตั้งไว้ล่วงหน้า ทำให้ผู้ใช้เสียค่าใช้จ่ายน้อยกว่า การนำทางห่างจาก การป้อนข้อมูลด้วยเสียงเริ่มต้นและเมนูการตั้งค่าแอป Assistant และแชร์เฉพาะบริบทเมื่อมีการเรียกใช้แอปผู้ช่วยอย่างชัดแจ้งเท่านั้น ผู้ใช้ผ่านคำสั่งให้ดำเนินการหรือแป้นนำทางช่วย
• [C-2-2] การโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ ในส่วนที่ 7.2.3 "ต้องเปิดใช้งานรายการที่ผู้ใช้เลือก" แอปผู้ช่วย ซึ่งก็คือแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ Intent ACTION_ASSIST

3.8.5 การแจ้งเตือนและขนมปังปิ้ง

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

หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้

• [C-1-1] ต้องระบุราคาที่ผู้ใช้จะสามารถบล็อกแอปไม่ให้แสดงการแจ้งเตือน หน้าต่างที่ใช้ TYPE_APPLICATION_OVERLAY การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการควบคุมในหน้าต่างแจ้งเตือน

• [C-1-2] ต้องปฏิบัติตาม Toast API และแสดง Toasts จากแอปพลิเคชันแก่ผู้ใช้ปลายทางใน ลักษณะที่มองเห็นได้ง่าย

3.8.6 ธีม

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

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

หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้

• [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดง แอปพลิเคชัน
• [C-1-2] ต้องรองรับ "Material" ธีมของ Google และต้องไม่ดัดแปลง แอตทริบิวต์ธีมวัสดุ หรือเนื้อหาที่เปิดเผยต่อแอปพลิเคชัน

• [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 และMONOCHROMATIC

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

ฮาร์ดแวร์ถือว่าสามารถเรียกใช้วอลเปเปอร์เคลื่อนไหวได้อย่างน่าเชื่อถือหากทำงานได้ วอลเปเปอร์เคลื่อนไหวทั้งหมดโดยไม่มีข้อจำกัดฟังก์ชันต่างๆ ในเฟรมที่เหมาะสม โดยไม่มีผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดใน ฮาร์ดแวร์ทำให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้ กำลัง 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 รายการต่อครั้งเป็นอย่างน้อย
• ควรแสดงสีไฮไลต์ ไอคอน และชื่อหน้าจอในช่วงล่าสุด
• ควรแสดงราคาปิด ("x") แต่อาจล่าช้าจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ
• ควรใช้ทางลัดเพื่อสลับไปยังกิจกรรมก่อนหน้าได้อย่างง่ายดาย
• ควรทริกเกอร์การทำงานสลับอย่างรวดเร็วระหว่างตัวเลือกที่ใช้งานล่าสุด เมื่อมีการแตะแป้นฟังก์ชันล่าสุด 2 ครั้ง
• ควรทริกเกอร์โหมดหลายหน้าต่างแยกหน้าจอ (หากรองรับ) เมื่อ มีการกดแป้นฟังก์ชันล่าสุดค้างไว้
• อาจแสดงรายการล่าสุดที่เชื่อมโยงเป็นกลุ่มที่ย้ายไปด้วยกัน
• [C-SR-1] แนะนําอย่างยิ่งให้ใช้ผู้ใช้ Android อัปสตรีม (หรืออินเทอร์เฟซที่ใช้ภาพขนาดย่อที่คล้ายกัน) สำหรับหน้าจอภาพรวม

3.8.9 การจัดการอินพุต

Android รองรับ การจัดการอินพุต และรองรับตัวแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม

หากการใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามใน ได้

• [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และ รองรับ IME API ตามที่กำหนดไว้ในเอกสารประกอบ Android SDK

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

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 แบบสมบูรณ์ในละติน กรีก และซีริลลิก รวมถึง ภาษาละติน Extended 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
• [C-2-3] ต้องแสดงผลข้อความด้วยแบบอักษรที่ไม่สอดคล้องกับ Unicode เฉพาะ IF a รหัสภาษาที่มี โค้ดสคริปต์ Qaag (เช่น my-Qaag) ไม่มีภาษา ISO หรือรหัสภูมิภาคอื่นๆ (ไม่ว่าจะ ไม่ได้กำหนด ไม่ได้กำหนด หรือจองแล้ว) สามารถใช้เพื่ออ้างอิงถึงรายการที่ไม่ใช่ Unicode แบบอักษรที่สอดคล้องกับเมียนมา นักพัฒนาแอปและผู้เขียนหน้าเว็บสามารถ ระบุ my-Qaag เป็นรหัสภาษาที่กำหนดเช่นเดียวกับ ภาษาอื่น

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

หากการติดตั้งใช้งานอุปกรณ์สามารถแสดงกิจกรรมหลายอย่างที่ ในขณะเดียวกัน

• [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตาม การทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ใน Android SDK เอกสารสนับสนุนโหมดหลายหน้าต่าง และ Meet ข้อกำหนดต่อไปนี้
• [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 ของแอปพลิเคชันตัวเรียกใช้งานของบุคคลที่สาม และไม่แทนที่ค่าเหล่านี้ ในการแสดงเนื้อหา ของกิจกรรมบนแท่นชาร์จ

หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและการแสดงภาพซ้อนภาพ โหมดหลายหน้าต่าง

• [C-3-1] ต้องเปิดกิจกรรมในโหมดหลายหน้าต่างแบบการแสดงภาพซ้อนภาพ เมื่อแอป * API ที่กำหนดเป้าหมายระดับ 26 ขึ้นไปและประกาศ android:supportsPictureInPicture * API เป้าหมายระดับ 25 หรือต่ำกว่า และประกาศทั้ง android:resizeableActivity และ android:supportsPictureInPicture
• [C-3-2] ต้องแสดงการดำเนินการใน SystemUI เป็น ที่ระบุโดยกิจกรรม PIP ปัจจุบันผ่าน setActions() API
• [C-3-3] ต้องรองรับสัดส่วนภาพที่มากกว่าหรือเท่ากับ 1:2.39 และน้อยกว่าหรือเท่ากับ 2.39:1 ตามที่ระบุโดยกิจกรรม PIP ผ่าน setAspectRatio() API
• [C-3-4] ต้องใช้ KeyEvent.KEYCODE_WINDOW เพื่อควบคุมหน้าต่าง PIP หากไม่ได้ใช้โหมด PIP คีย์ต้องเป็น ในกิจกรรมเบื้องหน้า
• [C-3-5] ต้องระบุราคาที่ผู้ใช้จะสามารถบล็อกแอปไม่ให้แสดงใน โหมด PIP การติดตั้งใช้งาน AOSP จะเป็นไปตามข้อกำหนดนี้ ในหน้าต่างแจ้งเตือน

• [C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับ PIP เมื่อแอปพลิเคชันไม่ได้ประกาศค่า AndroidManifestLayout_minWidth และ AndroidManifestLayout_minHeight:

  • อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าไว้นอกเหนือจาก UI_MODE_TYPE_TELEVISION ต้องจัดสรรความกว้างและความสูงขั้นต่ำเป็น 108 dp
  • อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าเป็น UI_MODE_TYPE_TELEVISION ต้องจัดสรรความกว้างขั้นต่ำเป็น 240 dp และความสูงขั้นต่ำเป็น 135 dp

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.8.15 หน้าจอรอยบาก

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

หากการใช้งานอุปกรณ์รวมหน้าจอรอยบากไว้ จะมีผลดังนี้

• [C-1-5] ต้องไม่มีรอยบากหากสัดส่วนภาพของอุปกรณ์คือ 1.0(1:1)
• [C-1-2] ต้องไม่มีคัตเอาต์มากกว่า 1 คัตเอาต์ต่อขอบ
• [C-1-3] ต้องปฏิบัติตามแฟล็กหน้าจอรอยบากที่แอปกำหนดผ่าน 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 การบันทึกเนื้อหาและการค้นหาแอป

หากการนำอุปกรณ์ไปใช้งานจะสร้างการแสดงตัวอย่างที่ผู้ใช้มองเห็นได้เมื่อมีการคัดลอกเนื้อหา ไปยังคลิปบอร์ดสำหรับรายการ ClipData ซึ่ง ClipData.getDescription().getExtras() มี android.content.extra.IS_SENSITIVE มีคุณสมบัติดังนี้

• [C-1-1] ต้องปกปิดตัวอย่างที่ผู้ใช้เห็นได้

การใช้ข้อมูลอ้างอิง AOSP เป็นไปตามข้อกำหนดของคลิปบอร์ดเหล่านี้

3.9 การดูแลระบบของอุปกรณ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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) ผ่านทาง ฟีเจอร์แฟล็ก android.hardware.nfc และรับข้อความ NFC มีระเบียนที่มีประเภท MIME MIME_TYPE_PROVISIONING_NFC
    • [C-1-8] ต้องส่ง ACTION_GET_PROVISIONING_mode Intent หลังมีการเรียกใช้การจัดสรรเจ้าของอุปกรณ์ เพื่อให้ แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือโปรไฟล์ เจ้าของ โดยขึ้นอยู่กับค่าของ android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, เว้นแต่ว่าจะระบุได้จาก ที่ระบุว่ามีตัวเลือกที่ถูกต้องเพียงตัวเลือกเดียว
    • [C-1-9] ต้องระบุ ACTION_ADMIN_POLICY_COMPLIANCE Intent ไปยังแอปเจ้าของอุปกรณ์ หากมีการสร้างเจ้าของอุปกรณ์แล้ว ในระหว่างการจัดสรรโดยไม่คำนึงถึงวิธีการจัดสรร ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าจะ แอปของเจ้าของอุปกรณ์ทำงานให้เสร็จสิ้น
  • เมื่อการใช้งานอุปกรณ์มี ผู้ใช้ หรือ ข้อมูลผู้ใช้ได้อย่างง่ายดาย
    • [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ และอื่นๆ อีกมากมาย

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ

การใช้งานอุปกรณ์จะประกาศ android.software.managed_users ดังต่อไปนี้

• [C-1-1] ต้องใช้ API อนุญาตให้แอปพลิเคชัน Device Policy Controller (DPC) เป็น เจ้าของโปรไฟล์ที่มีการจัดการใหม่

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง 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 Intent

• [C-1-6] ต้องส่ง ACTION_GET_PROVISIONING_mode Intent หลังจากมีการเรียกใช้การจัดสรรเจ้าของโปรไฟล์เพื่อให้แอป 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] ต้องรองรับโปรไฟล์ที่มีการจัดการผ่าน android.app.admin.DevicePolicyManager API
• [C-1-2] ต้องอนุญาตให้สร้างโปรไฟล์ที่มีการจัดการได้ 1 รายการเท่านั้น
• [C-1-3] ต้องใช้ป้ายไอคอน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อ แสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ และองค์ประกอบ UI อื่นๆ ที่มีตราสถานะ เช่น รายการล่าสุดและ การแจ้งเตือน
• [C-1-4] ต้องแสดงไอคอนการแจ้งเตือน (คล้ายกับงานต้นทางของ AOSP ) เพื่อระบุว่ามีผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการเมื่อใด
• [C-1-5] ต้องแสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในกลุ่มที่มีการจัดการ หากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และ แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ในโปรไฟล์ที่มีการจัดการ
• [C-1-6] เมื่อมีโปรไฟล์ที่มีการจัดการ ต้องแสดงความสามารถในการมองเห็น "ตัวเลือก" ของ Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อ Intent จาก โปรไฟล์ให้แก่ผู้ใช้หลัก หรือในทางกลับกัน หากเปิดใช้โดย Device Policy ตัวควบคุม
• [C-1-7] เมื่อมีโปรไฟล์ที่มีการจัดการ ต้องแสดงผู้ใช้ต่อไปนี้ ราคาสำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
  • แยกการพิจารณาการใช้งานแบตเตอรี่ ตำแหน่ง ข้อมูลมือถือ และพื้นที่เก็บข้อมูล สำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
  • การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในไฟล์หลักแบบอิสระ ผู้ใช้หรือโปรไฟล์ที่มีการจัดการ
  • การจัดการแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักอย่างอิสระ หรือโปรไฟล์ที่มีการจัดการ
  • การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือจัดการ โปรไฟล์
• [C-1-8] ต้องตรวจสอบให้แน่ใจว่าแป้นโทรศัพท์ รายชื่อติดต่อ และการรับส่งข้อความที่ติดตั้งไว้ล่วงหน้า สามารถค้นหาและค้นหาข้อมูลผู้โทรจาก โปรไฟล์ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลัก หาก เครื่องมือควบคุมนโยบายด้านอุปกรณ์อนุญาต
• [C-1-9] ต้องตรวจสอบว่าอุปกรณ์ตรงตามข้อกำหนดด้านความปลอดภัยทั้งหมด ใช้ได้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการ ไม่นับว่าเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
• [C-1-10] ต้องตรวจสอบว่าได้บันทึกข้อมูลภาพหน้าจอไว้ในโปรไฟล์งานแล้ว เมื่อจับภาพหน้าจอด้วย topActivity หน้าต่างที่มีโฟกัส (รายการที่ผู้ใช้โต้ตอบด้วยรายการสุดท้ายจากกิจกรรมทั้งหมด) และเป็นของ แอปโปรไฟล์งาน
• [C-1-11] ต้องไม่บันทึกเนื้อหาหน้าจออื่นๆ (แถบระบบ การแจ้งเตือนหรือเนื้อหาในโปรไฟล์ส่วนตัวใดๆ) ยกเว้นโปรไฟล์งาน หน้าต่าง/หน้าต่างแอปพลิเคชัน เมื่อบันทึกภาพหน้าจอไปยังโปรไฟล์งาน (เพื่อให้แน่ใจได้ว่า ไม่ได้บันทึกข้อมูลโปรไฟล์ไว้ในโปรไฟล์งาน)

หากการใช้งานอุปกรณ์ประกาศ android.software.managed_users และ android.software.secure_lock_screen กล่าวคือ

• [C-2-1] ต้องรองรับความสามารถในการระบุการประชุมในหน้าจอล็อกแยกต่างหาก ข้อกำหนดต่อไปนี้เพื่อให้สิทธิ์การเข้าถึงแอปที่ทำงานใน โปรไฟล์เท่านั้น
  • การติดตั้งใช้งานอุปกรณ์ต้องยึดตาม DevicePolicyManager.ACTION_SET_NEW_PASSWORD Intent และแสดงอินเทอร์เฟซเพื่อกำหนดค่าหน้าจอล็อกแยกต่างหาก ข้อมูลเข้าสู่ระบบสำหรับโปรไฟล์ที่มีการจัดการ
  • ข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้ข้อมูลเดียวกัน ที่จัดเก็บข้อมูลรับรองและกลไกการจัดการในฐานะโปรไฟล์หลัก ตามที่ระบุไว้ใน เว็บไซต์โครงการโอเพนซอร์ส 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.9.5 กรอบการแก้ปัญหาของนโยบายด้านอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin หรือ android.software.managed_users จากนั้นจะดำเนินการดังนี้

• [C-1-1] ต้องแก้ไขความขัดแย้งของนโยบายด้านอุปกรณ์ตามที่ได้ระบุไว้ในเอกสาร กรอบการแก้ปัญหานโยบายด้านอุปกรณ์

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

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

หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้

• [C-1-1] ต้องใช้งานฟังก์ชันการช่วยเหลือพิเศษใน Android ตามที่อธิบายไว้ใน API การช่วยเหลือพิเศษ เอกสารเกี่ยวกับ SDK
• [C-1-2] ต้องสร้างเหตุการณ์ความสามารถเข้าถึงได้ง่ายและนำเสนอ AccessibilityEvent สำหรับผู้ที่ลงทะเบียนทั้งหมด AccessibilityService ตามที่กำหนดไว้ใน SDK
• [C-1-4] ต้องให้เงินแก่ผู้ใช้เพื่อควบคุมการช่วยเหลือพิเศษ บริการที่ประกาศ AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON โปรดทราบว่าเมื่อใช้อุปกรณ์ ที่มีแถบนำทางของระบบ ควรให้ผู้ใช้มีตัวเลือกสำหรับปุ่มใน ในการควบคุมบริการเหล่านี้

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

• [C-2-1] ต้องใช้บริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้าเป็น การรับรู้การเปิดเครื่องโดยตรง เมื่อมีการเข้ารหัสพื้นที่เก็บข้อมูลด้วยการเข้ารหัสตามไฟล์ (FBE)
• ควรมีกลไกในขั้นตอนการตั้งค่าที่พร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้ บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผลและท่าทางสัมผัสการขยาย

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

Android มี API ที่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากการอ่านออกเสียงข้อความ (TTS) และช่วยให้ผู้ให้บริการสามารถติดตั้งใช้งาน TTS บริการต่างๆ

หากมีการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output ดังนี้

• [C-1-1] ต้องสนับสนุน เฟรมเวิร์ก Android TTS API

หากการติดตั้งอุปกรณ์รองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม การติดตั้งจะดำเนินการดังนี้

• [C-2-1] ต้องให้เงินแก่ผู้ใช้เพื่อให้ผู้ใช้เลือก TTS เครื่องมือสำหรับการใช้งานในระดับระบบ

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.12 เฟรมเวิร์กอินพุตทีวี

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 ทั้งหมด ลำดับชั้น อาจจำกัดการเข้าถึงในบางลำดับชั้นเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนผู้ขับขี่) แต่ต้องไม่ให้การดูแลเป็นพิเศษตามเนื้อหาหรือ Content Provider

• [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 Apps แคชในเครื่องสำหรับแพ็กเกจแอปแต่ละรายการ
  • [C-1-6] ต้องระบุการแจ้งเตือนสำหรับผู้ใช้อย่างต่อเนื่องที่สามารถ ยุบในขณะที่ Instant App ทำงานอยู่ในเบื้องหน้า ผู้ใช้รายนี้ การแจ้งเตือนต้องระบุว่า Instant Apps ไม่ต้องใช้การติดตั้ง และให้ค่าตอบแทนแก่ผู้ใช้ที่จะนำผู้ใช้ไปยังแอปพลิเคชัน ในหน้าจอ "การตั้งค่า" สำหรับ Instant Apps ที่เปิดตัวผ่านเว็บ 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 รองรับการจับคู่อุปกรณ์ที่ใช้ร่วมกันเพื่อให้จัดการได้อย่างมีประสิทธิภาพมากขึ้น เชื่อมโยงกับอุปกรณ์ที่ใช้ร่วมกันและให้ CompanionDeviceManager API ของแอปเพื่อเข้าถึงฟีเจอร์นี้

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

• [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ FEATURE_COMPANION_DEVICE_SETUP ที่ใช้เวลาเพียง 2 นาที
• [C-1-2] ต้องตรวจสอบให้แน่ใจว่า API ในandroid.companion เสร็จสมบูรณ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

รายชื่อติดต่อข้อมูลดิบ นั้น "เชื่อมโยงกับ" หรือ "จัดเก็บไว้ใน" CANNOT TRANSLATE บัญชี เมื่อ ACCOUNT_NAME, และ ACCOUNT_TYPE สำหรับข้อมูลติดต่อดิบตรงกับ ชื่อบัญชี และ Account.type ของบัญชี

บัญชีเริ่มต้นในเครื่อง: บัญชีสำหรับรายชื่อติดต่อดิบที่เก็บไว้เฉพาะใน อุปกรณ์และไม่เชื่อมโยงกับบัญชีใน ผู้จัดการฝ่ายดูแลลูกค้า ซึ่งสร้างขึ้นด้วยค่า null สำหรับพารามิเตอร์ ACCOUNT_NAME, และ ACCOUNT_TYPE

บัญชีในเครื่องที่กำหนดเอง: บัญชีสำหรับรายชื่อติดต่อดิบที่เก็บไว้เฉพาะใน อุปกรณ์ และไม่เชื่อมโยงกับ "บัญชี" ใน AccountManager ซึ่งเป็น สร้างขึ้นโดยมีค่าที่ไม่ใช่ค่าว่างอย่างน้อย 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 param เป็น true) แม้ว่าจะตั้งค่าพารามิเตอร์ CALLER\_IS\_SYNCADAPTER แล้ว เป็นเท็จหรือไม่ได้ระบุ

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

3.19 การตั้งค่าภาษา

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

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

• [C-0-1] ต้องติดตั้งและเรียกใช้ Android ".apk" ได้ เก็บบันทึกเป็น ที่สร้างโดย "aapt" เครื่องมือที่รวมอยู่ใน Android SDK อย่างเป็นทางการ

  • ตามข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย การติดตั้งใช้งานอุปกรณ์ แนะนำให้ใช้การจัดการแพ็กเกจของการใช้งานข้อมูลอ้างอิง AOSP ระบบ

• [C-0-2] ต้องรองรับการยืนยัน ".apk" โดยใช้ APK Signature Scheme v3.1, APK Signature Scheme v3 รูปแบบลายเซ็น APK เวอร์ชัน 2 และการลงชื่อ JAR

• [C-0-3] ต้องไม่ขยาย .apk Android Manifest Dalvik Bycode หรือ รูปแบบไบต์โค้ดของ RenderScript ในลักษณะที่จะป้องกันไม่ให้ไฟล์เหล่านั้น ติดตั้งและทำงานอย่างถูกต้องบนอุปกรณ์อื่นๆ ที่เข้ากันได้

• [C-0-4] ต้องไม่อนุญาตแอปอื่นนอกเหนือจากแอปปัจจุบัน "โปรแกรมติดตั้งระเบียน" แพ็กเกจสามารถถอนการติดตั้งแอปโดยไม่ต้อง การยืนยันผู้ใช้ ตามที่ระบุไว้ใน SDK สำหรับ DELETE_PACKAGE สิทธิ์ ข้อยกเว้นเพียงอย่างเดียวคือการจัดการแอปของเครื่องมือยืนยันแพ็กเกจของระบบ PACKAGE_NEEDS_VERIFICATION Intent และการจัดการแอปบนตัวจัดการพื้นที่เก็บข้อมูล พื้นที่เก็บข้อมูล ACTION_MANAGE_STORAGE Intent

• [C-0-5] ต้องมีกิจกรรมที่จัดการ android.settings.MANAGE_UNKNOWN_APP_SOURCES Intent

• [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 Open โปรเจ็กต์ต้นทาง

โปรดทราบว่าทั้ง 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 บิตผ่าน android.media.MediaCodec API

5.1.2 การถอดรหัสเสียง

ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.audio.output จะต้องรองรับการถอดรหัส รูปแบบเสียงต่อไปนี้:

• [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
• [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
• [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงใหม่)
• [C-1-4] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile ซึ่งประกอบด้วย โปรไฟล์ฐานของ USAC และช่วงไดนามิกของ ISO/IEC 23003-4 โปรไฟล์ควบคุม)
• [C-1-5] FLAC
• MP3 [C-1-6]
• [C-1-7] MIDI
• [C-1-8] เวอร์บี
• [C-1-9] PCM/WAVE รวมเสียงความละเอียดสูง รูปแบบได้สูงสุด 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 เป็น 6 ช่องสัญญาณของ PCM)
• [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] ขอแนะนำเป็นอย่างยิ่งว่าข้อกำหนด C-2-1 และ C-2-2 ข้างต้น ของผู้ถอดรหัสเสียง AAC ทั้งหมด

เมื่อถอดรหัสเสียง 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 บิตผ่าน android.media.MediaCodec API

หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต 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	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC ดิบ ADTS (ไม่รองรับ .aac, ไม่รองรับ ADIF) MPEG-TS (.ts, ไม่สามารถค้นหาได้, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
โปรไฟล์ MPEG-4 HE AAC (AAC+)	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีมาตรฐาน อัตราการสุ่มตัวอย่างตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว)	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีมาตรฐาน อัตราการสุ่มตัวอย่างตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC)	รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
ฐานความรู้ด้านสิ่งแวดล้อม (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 - ตัวแปลงรหัสเสียงความถี่กว้าง	3GPP (.3gp)
FLAC	สำหรับทั้งโปรแกรมเปลี่ยนไฟล์และเครื่องถอดรหัส: โหมดโมโนและสเตอริโอต้องมีค่าเป็นอย่างต่ำ ที่รองรับ รองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz 16 บิตและ 24 บิต ต้องมีการรองรับความละเอียด ต้องจัดการ FLAC ข้อมูลเสียง 24 บิต ใช้ได้กับการกำหนดค่าเสียงแบบลอย	FLAC (.flac) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MP3	ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MIDI	MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ XMF สำหรับอุปกรณ์เคลื่อนที่ การสนับสนุนสำหรับ รูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody	ประเภท 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.iMelody)
Vorbis	การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ที่มีการสุ่มตัวอย่าง อัตรา 8000, 12000, 16000, 24000 และ 48000 Hz การเข้ารหัส: การสนับสนุนเนื้อหาโมโนและสเตอริโอที่มีอัตราสุ่ม 8000, 12000, 16000, 24000 และ 48000 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv) Webm (.webm)
PCM/WAVE	ตัวแปลงรหัส PCM ต้องรองรับ PCM เชิงเส้น 16 บิตและแบบลอย 16 บิต โบกมือ เครื่องมือแยกข้อมูลต้องรองรับ PCM เชิงเส้น 16 บิต, 24 บิต, 32 บิต และลอยตัว 32 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) ต้องรองรับอัตราการสุ่มตัวอย่างจาก 8 kHz ถึง 192 kHz	WAVE (.wav)
Opus	การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ด้วยอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz การเข้ารหัส: การสนับสนุนเนื้อหาโมโนและสเตอริโอ ด้วยอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv) Webm (.webm)

5.1.4 การเข้ารหัสรูปภาพ

ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ

การใช้งานอุปกรณ์ต้องรองรับการเข้ารหัสการเข้ารหัสรูปภาพต่อไปนี้

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP
• [C-0-4] AVIF
  • อุปกรณ์ต้องรองรับ BITRATE_MODE_CQ และโปรไฟล์พื้นฐาน

หากการใช้งานอุปกรณ์รองรับการเข้ารหัส 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] ดิบ
• [C-0-7] AVIF (โปรไฟล์พื้นฐาน)

หากการใช้งานอุปกรณ์รองรับการถอดรหัสวิดีโอ 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)
AVIF (โปรไฟล์พื้นฐาน)	รูปภาพ คอลเลกชันรูปภาพ โปรไฟล์เส้นฐานของลำดับรูปภาพ	คอนเทนเนอร์ HEIF (.avif)

โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API

• [C-1-1] ต้องรองรับสีที่ปรับเปลี่ยนได้ YUV420 8:8:8 รูปแบบ (COLOR_FormatYUV420Flexible) จนถึง CodecCapabilities

• [C-SR-1] แนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับพื้นผิวอินพุต

• [C-1-3] ต้องรองรับระนาบหรือสัมมนาอย่างน้อย 1 รายการ YUV420 8:8:8 รูปแบบสี: 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 แบบเซมิแพลน: COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) เราขอแนะนำเป็นอย่างยิ่งให้สนับสนุนทั้ง 2 อย่างนี้

• [C-SR-1] เราขอแนะนำเป็นอย่างยิ่งให้ใช้โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอเพื่อรองรับ สี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพฮาร์ดแวร์อย่างน้อยหนึ่งรายการ (YV12, NV12, NV21 หรือรูปแบบที่เพิ่มประสิทธิภาพผู้ให้บริการที่เทียบเท่า)

• [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		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, ถอดรหัสเท่านั้น)
HEVC ของ H.265	ดูรายละเอียดในส่วนที่ 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, ถอดรหัสเท่านั้น)
VP8	โปรดดูส่วนที่ 5.2 และ 5.3 สำหรับรายละเอียด	WebM (.webm) Matroska (.mkv)
VP9	ดูรายละเอียดในส่วนที่ 5.3	WebM (.webm) Matroska (.mkv)
AV1	ดูรายละเอียดได้ในส่วนที่ 5.2 และส่วนที่ 5.3	MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)

5.1.9 ความปลอดภัยของตัวแปลงรหัสสื่อ

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

Android รองรับ OMX ซึ่งเป็นการเร่งความเร็วมัลติมีเดีย API ข้ามแพลตฟอร์ม รวมทั้งตัวแปลงรหัส 2.0 ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียต่ำ

หากการใช้งานอุปกรณ์รองรับมัลติมีเดีย จะมีผลดังนี้

• [C-1-1] ต้องให้การสนับสนุนตัวแปลงรหัสสื่อผ่าน OMX หรือตัวแปลงรหัส 2.0 API (หรือทั้งสองอย่าง) ตามในโครงการโอเพนซอร์ส Android และไม่ปิดใช้หรือ การรักษาความปลอดภัย ซึ่งไม่ได้หมายความว่า ตัวแปลงรหัสต้องใช้ OMX หรือตัวแปลงรหัส 2.0 API เฉพาะที่สนับสนุน หนึ่งใน API เหล่านี้ต้องพร้อมใช้งาน และต้องสนับสนุน 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] ต้องส่งคืนค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่านทาง MediaCodecInfo API

โดยเฉพาะอย่างยิ่ง:

• [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของ OMX IL
• [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ตัวแปลงรหัส 2.0 API และ มีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของตัวแปลงรหัส 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
ความละเอียดของวิดีโอ	176 x 144 พิกเซล (H263, MPEG2, MPEG4) 352 x 288 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4, H263, MPEG2) 320 x 180 พิกเซล (VP8, VP8) 320 x 240 พิกเซล (อื่นๆ)	704 x 576 พิกเซล (H263) 640 x 360 พิกเซล (VP8, VP9) 640 x 480 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4) 720 x 480 พิกเซล (อื่นๆ, AV1)	1408 x 1152 พิกเซล (H263) 1280 x 720 พิกเซล (อื่นๆ, AV1)	1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4, AV1)	3840 x 2160 พิกเซล (HEVC, VP9, AV1)

• [C-2-2] ตัวแปลงรหัสวิดีโอที่มีลักษณะเป็นการเร่งความเร็วด้วยฮาร์ดแวร์ต้อง เผยแพร่ข้อมูลคะแนนประสิทธิภาพ แต่ละรายการต้องมีการสนับสนุนทั้งหมด คะแนนประสิทธิภาพมาตรฐาน (แสดงอยู่ใน PerformancePoint API) เว้นแต่จะครอบคลุมอยู่ในจุดประสิทธิภาพมาตรฐานอื่นๆ ที่รองรับ
• นอกจากนี้ ควรเผยแพร่คะแนนประสิทธิภาพเพิ่มเติมหาก สนับสนุนประสิทธิภาพของวิดีโอที่ยั่งยืน ซึ่งไม่ใช่วิดีโอมาตรฐานที่ระบุไว้

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

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอและทำให้พร้อมใช้งานสำหรับ แอปของบุคคลที่สาม และตั้งค่า
MediaFormat.KEY_BITRATE_MODE ถึง BITRATE_MODE_VBR เพื่อให้โปรแกรมเปลี่ยนไฟล์ทำงานในโหมดอัตราบิตที่ปรับเปลี่ยนได้ ตราบใดที่ไม่ส่งผลต่อคุณภาพขั้นต่ำขั้นต่ำ อัตราบิตที่เข้ารหัส :

• ไม่ควรเป็น มากกว่าหนึ่ง หน้าต่างเลื่อน ซึ่งมากกว่า 15% ของอัตราบิตระหว่างภายในเฟรม (I-Frame) เป็นรอบ
• ไม่ควรเกิน อัตราบิต 100% บนหน้าต่างเลื่อน 1 วินาที

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอและทำให้พร้อมใช้งานสำหรับ แอปของบุคคลที่สาม แล้วตั้งค่า MediaFormat.KEY_BITRATE_MODE ถึง BITRATE_MODE_CBR ดังนั้นโปรแกรมเปลี่ยนไฟล์จะทำงานในโหมดอัตราบิตคงที่ ตามด้วยอัตราบิตที่เข้ารหัส:

• [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ ไม่เกิน 15% ของอัตราบิตเป้าหมายในหน้าต่างเลื่อน 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 ตัวที่รั่วไหลผ่าน android.camera API:

• [C-4-1] โปรแกรมเปลี่ยนไฟล์และรูปภาพวิดีโอที่เร่งการแสดงผลด้วยฮาร์ดแวร์ต้องรองรับ เพื่อเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์
• ควรรองรับเฟรมการเข้ารหัสจากกล้องฮาร์ดแวร์ผ่านวิดีโอทั้งหมด หรือโปรแกรมเปลี่ยนไฟล์รูปภาพ

หากการติดตั้งใช้งานอุปกรณ์มีการเข้ารหัส HDR สิ่งที่จะเกิดขึ้นมีดังนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุปลั๊กอินสำหรับ API การแปลงที่ราบรื่นในการแปลงจากรูปแบบ HDR เป็นรูปแบบ SDR

5.2.1 H.263

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์ H.263 และทำให้พร้อมใช้งานได้ กับแอปของบุคคลที่สาม

• [C-1-1] ต้องรองรับความละเอียด QCIF (176 x 144) โดยใช้โปรไฟล์พื้นฐานระดับ 45 ความละเอียด SQCIF เป็นตัวเลือกที่ไม่บังคับ

5.2.2 H.264

หากอุปกรณ์รองรับตัวแปลงรหัส H.264 การทำงานเหล่านี้จะมีผลดังนี้

• [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 อย่างไรก็ตาม การรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น การเรียงลำดับ Macroblock) และ RS (ส่วนซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เพื่อ สามารถรักษาความเข้ากันได้กับอุปกรณ์ Android อื่นๆ ขอแนะนำว่า โปรแกรมเปลี่ยนไฟล์จะไม่ใช้ ASO, FMO และ RS กับโปรไฟล์พื้นฐาน
• [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 จนถึง ความละเอียด 512 x 512
• [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้สนับสนุน โปรไฟล์ SD ขนาด 720 x 480 และ โปรไฟล์การเข้ารหัส 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.2.6 AV1

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์เหล่านี้จะมีลักษณะดังนี้

• [C-1-1] ต้องสนับสนุนโปรไฟล์หลัก ซึ่งรวมถึงเนื้อหาแบบ 8 บิตและ 10 บิต

• [C-1-2] ต้องเผยแพร่ข้อมูลประสิทธิภาพ เช่น รายงานข้อมูลประสิทธิภาพผ่านทาง getSupportedFrameRatesFor() หรือ getSupportedPerformancePoints() API สำหรับความละเอียดที่รองรับในตารางด้านล่าง

• [C-1-3] ต้องยอมรับข้อมูลเมตา HDR และเอาต์พุตไปยังบิตสตรีม

หากโปรแกรมเปลี่ยนไฟล์ AV1 เร่งฮาร์ดแวร์ ระบบจะดำเนินการต่อไปนี้

• [C-2-1] ต้องรองรับและรวมโปรไฟล์การเข้ารหัส HD1080p จาก ตารางด้านล่าง

	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
อัตราบิตของวิดีโอ	5 Mbps	8 Mbps	16 Mbps	50 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 (ความละเอียด CIF, QCIF และ SQCIF @ 30fps 384kbps) และระดับ 45 (QCIF และ ความละเอียด SQCIF ที่ 30fps 128kbps)

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 (ส่วนที่ซ้ำกัน) ไม่บังคับ
• [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 อย่างน้อย 1 รายการ การถอดรหัสโปรไฟล์ 720, 1080 และ UHD

	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 ผ่านสื่อ 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 ผ่าน "CodecProfileLevel" API สื่อ:

• การรองรับรูปแบบ 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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-3] ต้องตั้งค่ารหัสแทร็ก ของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) เพื่อให้เหมือนกับแท็ก รวมรหัสแทร็กของเลเยอร์ Dolby Vision

5.3.9 AV1

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

• [C-1-1] ต้องสนับสนุนโปรไฟล์หลัก ซึ่งรวมถึงเนื้อหาแบบ 8 บิตและ 10 บิต

หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส AV1 ด้วยฮาร์ดแวร์ Accelerated Decoder ดังนี้

• [C-2-1] ต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอความละเอียดสูง 720p จาก ตารางด้านล่างเมื่อความสูงที่รายงานโดย Display.getSupportedModes() เท่ากับหรือมากกว่า 720p
• [C-2-2] ต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอความละเอียดสูง 1080p ได้อย่างน้อย 1 โปรไฟล์ จากตารางด้านล่างเมื่อความสูงที่รายงานโดย Display.getSupportedModes() เท่ากับหรือมากกว่า 1080p

	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
อัตราบิตของวิดีโอ	5 Mbps	8 Mbps	16 Mbps	50 Mbps

หากการใช้งานอุปกรณ์รองรับโปรไฟล์ HDR ผ่านทาง Media API ดังนี้

• [C-3-1] ต้องรองรับการดึงและเอาต์พุตข้อมูลเมตา HDR จาก บิตสตรีมและ/หรือคอนเทนเนอร์
• [C-3-2] ต้องแสดงเนื้อหา HDR อย่างถูกต้องบนหน้าจอของอุปกรณ์หรือบน พอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)

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

• ควรตั้งค่าความไวของอินพุตเสียงให้แหล่งสัญญาณเสียงไซนัสอยัล 1000 Hz เล่นที่ระดับความดันเสียง (SPL) 90 dB (วัดถัดจากไมโครโฟน) ให้การตอบสนองที่สมบูรณ์แบบที่ RMS 2500 ภายในช่วง 1770 และ 3530 สำหรับ 16 ตัวอย่างบิต (หรือ -22.35 db ±3dB สเกลเต็มสำหรับจุดลอยตัว/ความแม่นยำคู่ ตัวอย่าง) สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกการจดจำเสียง แหล่งที่มาของเสียง

• ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้แอมพลิจูด PCM ระดับต่างๆ จะติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB ตั้งแต่ -18 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone และสัญญาณรบกวน เทคโนโลยีระงับ (การลด) ที่ปรับแต่งสำหรับการจดจำคำพูดจะมีคุณสมบัติดังนี้

• [C-2-1] ต้องอนุญาตให้สามารถควบคุมเอฟเฟกต์เสียงนี้ด้วย android.media.audiofx.NoiseSuppressor API
• [C-2-2] ต้องระบุเทคโนโลยีการตัดเสียงรบกวนแต่ละเทคโนโลยีแยกกัน การใช้งานผ่านช่อง AudioEffect.Descriptor.uuid

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

ชั้นเรียน android.media.MediaRecorder.AudioSource ประกอบด้วย REMOTE_SUBMIX แหล่งที่มาของเสียง

หากการใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output และ android.hardware.microphone กล่าวคือ

• [C-1-1] ต้องใช้แหล่งที่มาของเสียง REMOTE_SUBMIX อย่างถูกต้องเพื่อให้ เมื่อแอปพลิเคชันใช้ android.media.AudioRecord API เพื่อบันทึกจาก แหล่งที่มาของเสียง จะบันทึกการผสมสตรีมเสียงทั้งหมด ยกเว้นรายการต่อไปนี้

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4 อุปกรณ์ตัดเสียงก้อง

การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone ดังต่อไปนี้

• ควรใช้เครื่องตัดเสียงก้องอะคูสติก เทคโนโลยี (AEC) ที่ปรับแต่งสำหรับการสื่อสารด้วยเสียงและนำมาใช้กับเส้นทางการจับภาพ เมื่อจับภาพโดยใช้ AudioSource.VOICE_COMMUNICATION

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

• [C-SR-1] มีสิทธิ์ STRONGLY_RECOMMENDED เพื่อประกาศสิ่งนี้ผ่าน AcosimpleEchoCanceler เมธอด API AcouralEchoCanceler.isavailable()
• [C-SR-2] เป็น STRONGLY_RECOMMENDED เพื่ออนุญาตให้สามารถใช้เอฟเฟกต์เสียงนี้ได้ ควบคุมได้ด้วย AcobasicEchoCanceler API
• [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 แอปพลิเคชันขึ้นไปพร้อมกัน และ ทั้ง 2 แอปไม่มี UI อยู่ด้านบน อันที่เริ่มจับภาพล่าสุด จะรับเสียงได้

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 ที่ควบคุมได้ผ่าน คลาสย่อยของ AudioEffect Equalizer และ LoudnessEnhancer
• [C-1-2] ต้องรองรับการใช้งาน Visualizer API ซึ่งควบคุมได้ผ่าน ชั้นเรียน Visualizer
• [C-1-3] ต้องรองรับการใช้งาน EFFECT_TYPE_DYNAMICS_PROCESSING ควบคุมได้ผ่านคลาสย่อย AudioEffect DynamicsProcessing

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• ควรรองรับ 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 คลิปที่มีรูปแบบเดียวกัน เมื่อระบุโดย API ที่ไม่มีเสียงของแทร็กเสียง และคอนเทนเนอร์สื่อสำหรับ MediaPlayer

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

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

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

• เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรม ของข้อมูลที่เข้ารหัส PCM และเมื่อมีการแสดงเสียงที่เกี่ยวข้องต่อ ที่ตัวแปรสัญญาณในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่าน และสังเกตพบภายนอกได้
• เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาระหว่างการเริ่มต้นสตรีมเอาต์พุตและ เวลานำเสนอของเฟรมแรกตามการประทับเวลา เมื่อเอาต์พุตเสียง ไม่มีการใช้งานระบบและปิดเครื่องก่อนส่งคำขอ
• เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองเอาต์พุตสำหรับเฟรมต่อๆ มา หลังจากที่อุปกรณ์เล่นเสียง
• เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างการนำเสนอเสียงโดย สภาพแวดล้อมของอุปกรณ์ที่ตัวแปลงสัญญาณในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่าน พอร์ตและเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM แล้ว
• อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้งานไม่ได้ หรือ ไม่พร้อมใช้งาน
• เวลาในการตอบสนองแบบ Cold input เวลาระหว่างเริ่มสตรีมและเมื่อ ได้รับเฟรมแรกที่ถูกต้องเมื่อระบบอินพุตเสียงไม่มีการใช้งาน เครื่องไม่ทำงานก่อนร้องขอ
• เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ มา ขณะที่อุปกรณ์บันทึกเสียง
• เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่องบวก เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องบวกช่วงเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์ เวลาที่จะให้แอปประมวลผลสัญญาณ และเวลาเพื่อให้แอปลดระยะ ความแตกต่างระหว่างสตรีมอินพุตและเอาต์พุต
• API คิวบัฟเฟอร์ OpenSL ES PCM ชุดของ PCM OpenSL สเปน API ใน Android NDK
• API เสียงดั้งเดิมของเสียง ชุดของ AAudio API ภายใน Android NDK
• การประทับเวลา คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายใน สตรีมและเวลาโดยประมาณเมื่อเฟรมดังกล่าวเข้าสู่หรือออกจาก ไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง ดูเพิ่มเติม AudioTimestamp
• glitch มีการขัดจังหวะชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง ซึ่งโดยทั่วไปเกิดจาก การบัฟเฟอร์น้อยสำหรับเอาต์พุต บัฟเฟอร์มากเกินไปสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนดิจิทัลหรือแอนะล็อก
• หมายถึงส่วนเบี่ยงเบนสัมบูรณ์ (MAD) ค่าเฉลี่ยของค่าสัมบูรณ์ของค่า การเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-2] เวลาในการตอบสนอง เอาต์พุต แบบ Cold 500 มิลลิวินาที หรือน้อยกว่านั้น

• [C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้ AAudioStreamBuilder_openStream() ต้อง ใช้เวลาไม่ถึง 1,000 มิลลิวินาที

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-3-2] เวลาในการตอบสนองอินพุตแบบ Cold 500 มิลลิวินาที หรือน้อยกว่านั้น
• [C-3-3] การเปิดสตรีมอินพุตโดยใช้ AAudioStreamBuilder_openStream() ต้อง ใช้เวลาไม่ถึง 1,000 มิลลิวินาที

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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	ตัวแปลงรหัสวิดีโอ: H264 AVC MPEG-4 SP MPEG-2 ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP ในหัวข้อ 5.1.8 และ MPEG-2 ตัวแปลงสัญญาณเสียง: AAC ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรได้ในส่วนที่ 5.1.3
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3	ISO 13818-7	ดูส่วนที่ 5.1.1 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
WebVTT	WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC	RFC 6184	ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H264 AVC
MP4A-ลาตินอเมริกา	RFC 6416	ดูส่วนที่ 5.1.3 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
H263-1998	RFC 3551 RFC 4629 RFC 2190	ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H263
H263-2000	RFC 4629	ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H263
AMR	RFC 4867	ดูส่วนที่ 5.1.3 สำหรับรายละเอียดเกี่ยวกับ AMR-NB
AMR-WB	RFC 4867	ดูส่วนที่ 5.1.3 สำหรับรายละเอียดเกี่ยวกับ AMR-WB
MP4V-ES	RFC 6416	ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ MPEG-4 SP
Mpeg4-generic	RFC 3640	ดูส่วนที่ 5.1.3 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และ USB ของโหมดอุปกรณ์ต่อพ่วง
• [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
• [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัว จะมีผลดังนี้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากอุปกรณ์ไม่มีช่องเสียบหูฟัง 3.5 มม. 4 ตัวนำและ มีพอร์ต USB ที่รองรับโหมดโฮสต์ USB ดังนี้

• [C-3-1] ต้องใช้คลาสเสียง USB

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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] ต้องแสดงแอมพลิจูด-กับความถี่ระดับราบโดยประมาณ ในช่วงความถี่กลาง: โดยเฉพาะ ±10 dB จาก 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนทุกตัวที่ใช้ในการบันทึกอุปกรณ์ที่ยังไม่ได้ประมวลผล แหล่งที่มาของเสียง

• [C-1-3] ต้องแสดงระดับแอมพลิจูดในความถี่ต่ำ ช่วง: โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 z ถึง 100 Hz เมื่อเทียบกับ ช่วงความถี่กลางของไมโครโฟนแต่ละตัวที่ใช้บันทึก แหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

• [C-1-4] ต้องแสดงระดับแอมพลิจูดในความถี่สูง ช่วง: โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 7000 Hz ถึง 22 KHz เมื่อเทียบกับ ช่วงความถี่กลางของไมโครโฟนแต่ละตัวที่ใช้บันทึก แหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

• [C-1-5] ต้องตั้งค่าความไวของอินพุตเสียงให้ไซนัสซอยด์ 1000 Hz เสียงต้นฉบับที่เล่นที่ 94 dB ระดับความดันเสียง (SPL) ให้ผลตอบสนองด้วย RMS ของ 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB เต็มขนาดสำหรับจุดลอยตัว/คู่ ตัวอย่างความแม่นยำ) สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกอุปกรณ์ที่ยังไม่ได้ประมวลผล แหล่งที่มาของเสียง

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

• [C-1-2] บัฟเฟอร์เอาต์พุต P010 ต้องสามารถสุ่มตัวอย่างโดย GPU ได้ (เมื่อ จัดสรรพร้อมกับการใช้งาน GPU_SAMPLING) การดำเนินการนี้จะเปิดใช้องค์ประกอบ GPU และที่กำหนดเอง การแมปโทนสีตามแอป

หากตัวถอดรหัสวิดีโอโฆษณาการรองรับ COLOR_Format32bitABGR2101010 เครื่องมือดังกล่าวจะ:

• [C-2-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับรูปแบบเอาต์พุตและ ที่ CPU สามารถอ่านได้ (เอาต์พุต ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_FormatYUVP010 โปรแกรมจะ:

• [C-3-1] ต้องรองรับรูปแบบ P010 สำหรับแพลตฟอร์มอินพุตและเขียน CPU ได้ อินพุต (ImageWriter, MediaImage, ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_Format32bitABGR2101010 โปรแกรมดังกล่าวจะมีลักษณะดังนี้

• [C-4-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับแพลตฟอร์มอินพุตและเขียน CPU ได้ อินพุต (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 (อยู่ในเส้นโค้งการโอนเป้าหมายแล้ว) สำหรับอินพุตทั้งสอง Surface และ ByteBuffer และต้องโฆษณาการสนับสนุน COLOR_Format32bitABGR2101010

หากการใช้งานอุปกรณ์มีตัวแปลงรหัสที่สนับสนุน FEATURE_HdrEditing ให้ทำดังนี้ อุปกรณ์:

• [C-7-4] ต้องโฆษณาการรองรับส่วนขยาย OpenGL EXT_YUV_target

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

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

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

• [C-0-1] ต้องสนับสนุนเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Android ที่มีอยู่ใน Android SDK
• Android Debug Bridge (adb)

• บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)

  • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุนสำหรับ ddms ควรไม่ทำงานโดยค่าเริ่มต้น แต่ ต้องได้รับการสนับสนุนเมื่อใดก็ตามที่ผู้ใช้ได้เปิดใช้งาน Android Debug Bridge เหมือนดังข้างต้น

• SysTrace

  • [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องไม่มีการใช้งานโดยค่าเริ่มต้นและต้องมีผู้ใช้เข้าถึงได้ เพื่อเปิด Systrace

• Perfetto

  • [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้เปิดเผย /system/bin/perfetto ไบนารีของผู้ใช้เชลล์ที่ cmdline ปฏิบัติตาม เอกสาร Perfetto
  • [C-SR-2] ขอแนะนําอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุต กำหนดค่า Protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ใน เอกสาร Perfetto
  • [C-SR-3] ขอแนะนำอย่างยิ่งว่าไบนารี Perfetto จะเขียนเป็นเอาต์พุต การติดตาม Protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ใน เอกสาร Perfetto
  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้ใช้ไบนารี Perfetto คือแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto เป็นอย่างน้อย

• ประหยัดหน่วยความจำต่ำ

  • [C-0-12] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ไปยัง บันทึกที่มีสถิติเมื่อแอปถูกนักฆ่าหน่วยความจําต่ำยกเลิกการใช้งาน

• โหมดโปรแกรมทดสอบอัตโนมัติ หากการใช้งานอุปกรณ์รองรับคำสั่ง Shell cmd testharness และ เรียกใช้ cmd testharness enable ได้

  • [C-2-1] ต้องส่งคืน true เป็นเวลา วันที่ ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] ต้องใช้งานโหมดโปรแกรมควบคุมการทดสอบตามที่อธิบายไว้ใน เอกสารประกอบเกี่ยวกับโหมดโปรแกรมทดสอบอัตโนมัติ

• ข้อมูลการทำงานของ GPU

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

  • [C-0-13] ต้องใช้คำสั่ง Shell dumpsys gpu --gpuwork เพื่อแสดง ข้อมูลงานรวมของ GPU ที่แสดงผลโดยเคอร์เนล power/gpu_work_period Tracepoint หรือไม่แสดงข้อมูลหากระบบไม่รองรับคำสั่งการย้ายข้อมูล AOSP การใช้งานคือ frameworks/native/services/gpuservice/gpuwork/

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่าน แฟล็กฟีเจอร์ android.hardware.vulkan.version รายการ:

• [C-1-1] ต้องจ่ายเงินให้นักพัฒนาแอปในการเปิด/ปิดใช้ เลเยอร์การแก้ไขข้อบกพร่อง GPU
• [C-1-2] ต้องแจกแจงเลเยอร์ในเมื่อเปิดใช้เลเยอร์ดีบัก GPU ไลบรารีที่ให้บริการโดยเครื่องมือภายนอก (เช่น ไม่ได้เป็นส่วนหนึ่งของแพลตฟอร์มหรือ แพ็กเกจแอปพลิเคชัน) ที่พบในแอปพลิเคชันที่แก้ไขข้อบกพร่องได้ ไดเรกทอรีฐานไปยัง รองรับ vkEnumerateInstanceLayerProperties() และ vkCreateInstance() เมธอด API

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 ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่มีค่า Null ไม่ได้รับอนุญาตตามเอกสาร SDK
• [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ SDK ไม่ได้บันทึกไว้ เอกสารประกอบ
• [C-0-7] การใช้งานอุปกรณ์ต้องรายงานฮาร์ดแวร์ที่ถูกต้องอยู่เสมอ ข้อมูลการกำหนดค่าผ่านทาง getSystemAvailableFeatures() และ hasSystemFeature(String) เมธอดใน android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

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

7.1 การแสดงผลและกราฟิก

Android มีหน่วยงานที่ปรับเนื้อหาแอปพลิเคชันและ UI โดยอัตโนมัติ อย่างเหมาะสมสำหรับอุปกรณ์ เพื่อให้แอปพลิเคชันของบุคคลที่สาม ทำงานได้ดีกับจอแสดงผลและการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย CANNOT TRANSLATE จอแสดงผลที่ใช้งานได้กับ Android คือหน้าจอแสดงผลที่ใช้ ลักษณะการทำงานและ API ที่อธิบายไว้ในนักพัฒนาซอฟต์แวร์ Android - ความเข้ากันได้ของหน้าจอ ภาพรวมนี้ ส่วน (7.1) และส่วนย่อย ตลอดจนประเภทอุปกรณ์เพิ่มเติมอื่นๆ ลักษณะการทํางานเฉพาะที่บันทึกไว้ในส่วนที่ 2 ของเรื่องนี้ CDD

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

• [C-0-1] โดยค่าเริ่มต้น แอปพลิเคชันของบุคคลที่สามจะต้องแสดงผลใน จอแสดงผลที่ใช้ได้กับ Android

หน่วยที่อ้างอิงตามข้อกำหนดในส่วนนี้มีการกำหนดไว้ดังนี้

• ขนาดแนวทแยงมุมจริง ระยะทางเป็นนิ้วระหว่าง 2 ฝั่งตรงข้าม มุมของส่วนที่สว่างของจอแสดงผล
• density จำนวนพิกเซลที่รวมด้วยเส้นตรง ช่วงแนวนอนหรือแนวตั้งขนาด 1 นิ้ว แสดงเป็นพิกเซล ต่อนิ้ว (ppi หรือ dpi) ในตำแหน่งที่แสดงค่า ppi และ dpi ทั้ง DPI แนวนอนและแนวตั้งต้องอยู่ในช่วงที่ระบุ
• อัตราส่วน อัตราส่วนของพิกเซลของด้านที่ยาวกว่ากับ มีขนาดหน้าจอที่สั้นลง ตัวอย่างเช่น การแสดงผลขนาด 480x854 พิกเซลจะ 854/480 = 1.779 หรือราวๆ "16:9"
• ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ได้รับการปรับมาตรฐานเป็นความหนาแน่นของหน้าจอที่ 160 สำหรับความหนาแน่นบางส่วน และจำนวนพิกเซล p จำนวนความหนาแน่นของพิกเซลอิสระ dp คือ คำนวณเป็น: dp = (160 / d) * p

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 และใช้การแสดงผลจริงที่มีมุมโค้งมนในการแสดงผลหน้าจอเหล่านี้ ดังนี้

• [C-1-1] ต้องตรวจสอบให้แน่ใจว่าข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ ในแต่ละจอแสดงผล เช่น

  • รัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
  • เมื่อกล่องขนาด 18 dp x 18 dp ถูกยึดไว้ที่มุมของตรรกะ แสดงอย่างน้อยหนึ่งพิกเซลในแต่ละกล่องจะปรากฏบนหน้าจอ

• ควรรวมค่าบริการของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วย เป็นมุมสี่เหลี่ยมผืนผ้า

หากการใช้งานอุปกรณ์สามารถกำหนดค่าแป้นพิมพ์ได้เพียง NO_KEYS เท่านั้น และตั้งใจที่จะรายงานการรองรับโหมด UI ของ UI_MODE_TYPE_NORMAL การกำหนดค่าได้

• [C-4-1] ต้องมีขนาดเลย์เอาต์โดยไม่รวมหน้าจอรอยบาก อย่างน้อย 596 dp x 384 dp ขึ้นไป

หากต้องการรายละเอียดเกี่ยวกับการใช้ API ไฟล์ช่วยเหลือหรือส่วนขยายอย่างถูกต้อง โปรดดูที่ ลงในเอกสารสาธารณะของ Window Manager Jetpack

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

7.1.1.2 สัดส่วนภาพหน้าจอ

ส่วนนี้ถูกลบใน Android 14

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

เฟรมเวิร์ก UI ของ Android กำหนดชุดความหนาแน่นของตรรกะมาตรฐานเพื่อช่วย นักพัฒนาแอปพลิเคชันกำหนดเป้าหมายเป็นทรัพยากรของแอปพลิเคชัน

การใช้งานอุปกรณ์:

• [C-0-1] ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android อย่างใดอย่างหนึ่งที่แสดงอยู่ ใน DisplayMetrics ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องเป็นค่าคงที่สำหรับการแสดงผลจริงแต่ละรายการ อย่างไรก็ตาม อุปกรณ์อาจ รายงาน DisplayMetrics.density อื่น ตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (สำหรับ เช่น ขนาดการแสดงผล) ที่ตั้งค่าหลังจากการเปิดเครื่องครั้งแรก

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

หากการติดตั้งใช้งานอุปกรณ์ทำให้ เปลี่ยนขนาดการแสดงผลของอุปกรณ์

• [C-1-1] ต้องไม่ปรับขนาดจอแสดงผลให้ใหญ่กว่า 1.5 เท่า DENSITY_DEVICE_STABLE หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพซึ่งเล็กกว่า 320dp (เทียบเท่า เป็นตัวระบุทรัพยากร sw320dp) ขึ้นอยู่กับว่ากรณีใดจะเกิดขึ้นก่อน
• [C-1-2] ต้องไม่ปรับขนาดการแสดงผล เล็กกว่า 0.85 เท่าของ DENSITY_DEVICE_STABLE
• เพื่อให้มั่นใจว่าสามารถใช้งานได้ดี และมีขนาดแบบอักษรที่สอดคล้องกัน เราขอแนะนำว่า กำหนดการปรับขนาดของตัวเลือกการแสดงเนทีฟ (โดยปฏิบัติตามขีดจำกัด ที่ระบุข้างต้น)
  • เล็ก: 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 ทุกเวอร์ชันที่ระบุให้รองรับ

หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• ควรรองรับ OpenGL ES 3.2

การทดสอบ dEQP ของ OpenGL ES ได้รับการแบ่งพาร์ติชันเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมี วันที่/หมายเลขเวอร์ชันที่เกี่ยวข้อง รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/glesXX-master-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 ของ 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 วัลกัน

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-master-YYYY-MM-DD.txt อุปกรณ์ที่ รองรับ Vulkan ในระดับที่รายงานด้วยตนเองบ่งชี้ว่าสามารถผ่าน dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า

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

• [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องพร้อมกับ android.hardware.vulkan.level และ android.hardware.vulkan.version แฟล็กฟีเจอร์
• [C-1-2] ต้องแจกแจง VkPhysicalDevice สำหรับ Vulkan อย่างน้อย 1 รายการ API แบบเนทีฟ vkEnumeratePhysicalDevices()
• [C-1-3] ต้องใช้ Vulkan 1.1 API อย่างเต็มรูปแบบสำหรับแต่ละรายการที่แจกแจง VkPhysicalDevice
• [C-1-4] ต้องแจกแจงเลเยอร์ที่อยู่ในไลบรารีเนทีฟซึ่งมีชื่อว่า libVkLayer*.so ในไดเรกทอรีไลบรารีดั้งเดิมของแพ็กเกจแอปพลิเคชัน ผ่าน Vulkan Native API vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
• [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่ให้ไว้โดยไลบรารีที่อยู่นอกส่วน หรือให้ข้อมูลในลักษณะอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีแอตทริบิวต์ android:debuggable ตั้งค่าเป็น true หรือข้อมูลเมตา com.android.graphics.injectLayers.enable ตั้งค่าเป็น true
• [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่ระบบรองรับผ่าน Vulkan Native API และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยาย ที่พวกเขาไม่ได้รองรับอย่างถูกต้อง
• [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 รายการ
• [C-1-12] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_performance_query
• [C-SR-4] แนะนำอย่างยิ่งเพื่อปฏิบัติตามข้อกำหนดที่ระบุโดย โปรไฟล์ Android Baseline 2022
• [C-SR-5] แนะนำอย่างยิ่งให้สนับสนุน VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory และ VK_EXT_global_priority
• [C-SR-6] ขอแนะนำอย่างยิ่งให้ใช้ SkiaVk กับ HWUI

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 ระบบจะดำเนินการต่อไปนี้

• [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
• [C-2-2] ต้องไม่แจกแจง VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()

หากการติดตั้งใช้งานอุปกรณ์มีการรองรับ Vulkan 1.1 และประกาศ แฟล็กฟีเจอร์ Vulkan ที่อธิบายไว้ที่นี่ ดังนี้

• [C-3-1] ต้องแสดงการรองรับสำหรับฉากและแฮนเดิลภายนอกของ SYNC_FD ประเภทและส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer

• [C-SR-7] แนะนำอย่างยิ่งให้สร้าง VK_KHR_external_fence_fd ส่วนขยายที่พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม และเปิดใช้แอปพลิเคชัน เพื่อส่งออกเพย์โหลดของรั้วไปยัง และนำเข้าเพย์โหลดของรั้วจากไฟล์ POSIX ข้อบ่งชี้ตามที่อธิบายไว้ ที่นี่

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:hardware Accelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์ ผ่าน API ของ Android View ได้โดยตรง
• [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] ต้องประกาศ 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] แนะนำอย่างยิ่งให้ใช้ฟังก์ชัน HOME ค้างไว้ดังนี้ การโต้ตอบที่กำหนด

หากการใช้อุปกรณ์ใช้ส่วนที่ต่างกันของหน้าจอเพื่อแสดง แป้นนำทางต่างๆ

• [C-5-1] แป้นนำทางต้องใช้ส่วนที่ต่างกันของหน้าจอ ไม่ใช่ พร้อมใช้งานสำหรับแอปพลิเคชัน และต้องไม่ปิดบังหรือแทรกแซง หน้าจอที่แอปพลิเคชันใช้งานได้
• [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่ มีคุณสมบัติตรงตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
• [C-5-3] ต้องทำตาม Flag ที่แอปกำหนดไว้ผ่าน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_TRANSIENT_BARS_BY_SWIPE แล้ว การปัดจากขอบต้องมีลักษณะเหมือนกับการใช้งานใน AOSP ซึ่งก็คือ อยู่ใน SDK
• [C-7-4] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY WindowInsetsController.BEHAVIOR_DEFAULT หรือ ตั้งค่าตัวบ่งชี้ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE แล้ว ต้องซ่อนแผงระบบแบบปัดดูที่กำหนดเองจนกว่าผู้ใช้จะนำเข้ามา หรือ ยกเลิกการหรี่แถบระบบ (หรือที่เรียกว่า การนำทางและแถบสถานะ) ตามที่มีการใช้งาน ใน AOSP

หากมีฟังก์ชันการนำทางกลับ และผู้ใช้ยกเลิกการย้อนกลับ แล้วทำดังนี้

• [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 สำหรับ Configuration.touchscreen ช่อง API
• [C-1-2] ต้องรายงาน android.hardware.touchscreen และ แฟล็กฟีเจอร์ android.hardware.faketouch รายการ

หากการใช้งานอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามมากกว่า แตะเพียงครั้งเดียวบนจอแสดงผลหลักที่รองรับ 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 สำหรับ Configuration.touchscreen ช่อง API

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] ต้องรองรับตัวชี้ลง ตัวชี้ขึ้น ชี้ลง แล้วชี้ขึ้น ตำแหน่งเดียวกันบนออบเจ็กต์บนหน้าจอ ภายในเกณฑ์เวลา อนุญาตให้ผู้ใช้จำลองการแตะสองครั้ง บนวัตถุบนหน้าจอ
• [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 (การติดตามการใช้นิ้วมือ) อย่างน้อย 1 รายการแยกกันโดยสิ้นเชิง

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

7.2.6.1 การแมปปุ่ม

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

• [C-1-1] ต้องมีความสามารถในการจับคู่เหตุการณ์ HID กับค่าคงที่ InputEvent ที่สอดคล้องกันตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งานอัปสตรีม Android เป็นไปตามข้อกำหนดนี้

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

• [C-2-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.gamepad

ปุ่ม	การใช้งาน 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-pad1 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 ข้างต้นต้องได้รับการประกาศภายในเกม pad CA (0x01 0x0005)

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

4 เหตุการณ์การเคลื่อนไหว

การควบคุมแบบแอนะล็อก1	การใช้ HID	ปุ่ม Android
ทริกเกอร์ซ้าย	0x02 0x00C5	AXIS_LTRIGGER
ทริกเกอร์ด้านขวา	0x02 0x00C4	AXIS_RTRIGGER
จอยสติ๊กด้านซ้าย	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
จอยสติ๊กด้านขวา	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

เหตุการณ์การเคลื่อนไหว 1 รายการ

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

โปรดดูส่วนที่ 2.3.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์

7.3 เซ็นเซอร์

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

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

• [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตาม android.content.pm.PackageManager
• [C-0-2] ต้องส่งรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่านทาง SensorManager.getSensorList() และวิธีการที่คล้ายกัน
• [C-0-3] ต้องทำงานอย่างสมเหตุสมผลกับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น ส่งคืน true หรือ false ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียกใช้ Listener เซ็นเซอร์เมื่อเซ็นเซอร์ที่เกี่ยวข้องไม่ทำงาน ปัจจุบัน; เป็นต้น)

หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาบุคคลที่สาม

• [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมด โดยใช้ค่าระบบหน่วยสากล (เมตริก) ที่เกี่ยวข้องสำหรับ ประเภทเซ็นเซอร์ตามที่กำหนดไว้ในเอกสาร Android SDK
• [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * ตัวอย่าง_time สำหรับกรณีของสตรีมเซ็นเซอร์ที่มี เวลาในการตอบสนองที่ขอสูงสุดคือ 0 มิลลิวินาทีเมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
• [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายในเวลา 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้สามารถยอมรับได้ มีความแม่นยำเป็น 0
• [C-1-4] สำหรับ API ใดๆ ที่ระบุไว้ในเอกสารประกอบของ Android SDK ให้เป็น เซ็นเซอร์แบบต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ "ต้อง" เกิดขึ้นอย่างต่อเนื่อง ตัวอย่างข้อมูลเป็นระยะซึ่งควรมี Jitter ต่ำกว่า 3% โดยที่ Jitter หมายถึงค่าเบี่ยงเบนมาตรฐานของผลต่างของค่า 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 ที่เกี่ยวข้องสําหรับนักพัฒนาซอฟต์แวร์บุคคลที่สาม และเซ็นเซอร์รายงานเพียง 1 รายการ จากนั้นติดตั้งใช้งานอุปกรณ์

• [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สำหรับเซ็นเซอร์และรายงานค่า ผ่าน Sensor.getResolution() เมธอดของ API

หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่รองรับ ข้อมูลเซ็นเซอร์เพิ่มเติม#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 เท่า gravity(4g) หรือมากกว่าบนแกนใดก็ได้
• [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
• [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^ โดยที่ ค่าเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนตามตัวอย่าง เก็บรวบรวมในช่วงเวลาอย่างน้อย 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 กลุ่มดาว Glonass, Beidou Galileo)

• [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] แนะนําอย่างยิ่งให้รายงานช่วงเทียมของ GNSS และ อัตราสมมติในสภาพพื้นที่โล่งหลังจากระบุตำแหน่ง ขณะที่อยู่กับที่หรือเคลื่อนที่ด้วยความเร็วน้อยกว่า 0.2 เมตรต่อวินาทีของ ความเร่ง ก็เพียงพอที่จะคำนวณตำแหน่งที่อยู่ในระยะ 20 เมตร และความเร็ว ภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลาทั้งหมด

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] แนะนำอย่างยิ่งให้สามารถรายงานการวัดความดันใน อยู่ในช่วง 300hPa ถึง 1100hPa
• ควรมีความแม่นยำสัมบูรณ์ที่ 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] ได้รับการแนะนำอย่างยิ่งให้สนับสนุน PowerManager.getThermalHeadroom API

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 ก. เป็นอย่างน้อย และ +16g
  • ต้องมีความละเอียดในการวัดอย่างน้อย 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 ¡Hz ทดสอบที่ห้อง อุณหภูมิ
  • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
  • ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
  • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
  • ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
  • ควรมีข้อผิดพลาดในการปรับน้อยกว่า 0.002 rad/วินาทีใน ช่วงอุณหภูมิ 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 มิลลิวัตต์ เมื่ออุปกรณ์อยู่นิ่งและ 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] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและโดยตรงอย่างถูกต้อง ระดับการรายงานผ่าน isDirectChannelTypeSupported และ getHighestDirectReportRateLevel API
• [C-3-2] ต้องรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์อย่างน้อย 1 ใน 2 ประเภท สำหรับเซ็นเซอร์ทั้งหมดที่ประกาศว่ารองรับช่องสัญญาณโดยตรงของเซ็นเซอร์
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับ เซ็นเซอร์ (ตัวแปรที่ไม่ใช่การปลุกระบบ) ในประเภทต่อไปนี้
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10 เซ็นเซอร์ไบโอเมตริก

หากต้องการทราบข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยของการปลดล็อกด้วยไบโอเมตริก โปรดดู เอกสารการวัดความปลอดภัยด้วยข้อมูลไบโอเมตริก

หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้

• ควรมีเซ็นเซอร์ไบโอเมตริก

เซ็นเซอร์ไบโอเมตริกจัดอยู่ในประเภทคลาส 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) วิธีการอื่นๆ นอกเหนือจากที่ระบุไว้ว่าเป็นค่าคงที่สาธารณะ แอปตรวจสอบสิทธิ์ และการผสมผสานในลักษณะข้างต้น
• [C-4-3] ต้องใช้ ACTION_BIOMETRIC_ENROLL การดำเนินการกับอุปกรณ์ที่มีข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2 การดำเนินการนี้ต้องแสดงจุดแรกเข้าการลงทะเบียนสำหรับชั้นเรียน 3 เท่านั้น หรือไบโอเมตริกคลาส 2

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากอุปกรณ์รองรับข้อมูลไบโอเมตริกแบบแพสซีฟ ข้อมูลเหล่านั้นจะมีลักษณะดังนี้

• [C-5-1] โดยค่าเริ่มต้น ต้องมีขั้นตอนการยืนยันเพิ่มเติม (เช่น การกดปุ่ม)
• [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ ลบล้างค่ากำหนดของแอปพลิเคชัน และต้องมีรายชื่อที่สอดคล้องกันเสมอ ขั้นตอนการยืนยัน
• [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ดำเนินการยืนยัน ที่ทำให้ระบบปฏิบัติการหรือเคอร์เนลถูกบุกรุกได้ ตัวอย่างเช่น จะหมายถึงการดำเนินการยืนยันตามปุ่มจริง จะได้รับการกำหนดเส้นทางผ่าน PIN อินพุต/เอาต์พุตทั่วไป (GPIO) สำหรับอินพุตเท่านั้นของ องค์ประกอบความปลอดภัย (SE) ที่ไม่สามารถขับเคลื่อนด้วยวิธีอื่นใดนอกจาก การกดปุ่มจริง
• [C-5-2] ต้องใช้ขั้นตอนการตรวจสอบสิทธิ์โดยนัยเพิ่มเติม (ไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationrequired(บูลีน) แอปพลิเคชันใดที่สามารถตั้งค่าเพื่อใช้สำหรับขั้นตอนการลงชื่อเข้าใช้ได้

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

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

• [C-SR-12] แนะนําอย่างยิ่งเมื่อข้อมูลไบโอเมตริกไม่สามารถเข้าใช้งานได้ (เช่น ระบบจะปิดใช้ข้อมูลไบโอเมตริกจนกว่าผู้ใช้จะปลดล็อกด้วยการตรวจสอบสิทธิ์หลัก) หรือ การล็อกแบบจำกัดเวลา (เช่น ระบบปิดใช้ข้อมูลไบโอเมตริกชั่วคราวจนกว่า ผู้ใช้รอเป็นช่วง) เนื่องจากมีการยืนยันไม่สำเร็จหลายครั้งเกินไป เพื่อให้ ล็อกข้อมูลไบโอเมตริกอื่นๆ ในกลุ่มข้อมูลไบโอเมตริกเดียวกันออก ในกรณีที่ การล็อกเวลาใช้งาน เวลาแบ็คออฟสำหรับการยืนยันข้อมูลไบโอเมตริกจะสูง แนะนำให้เป็น Backoff Time สูงสุดของข้อมูลไบโอเมตริกทั้งหมดในกรอบเวลา การปิดกั้น

• [C-7-2] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) เพื่อรีเซ็ตตัวนับการเข้าใช้งานสำหรับข้อมูลไบโอเมตริก การเข้าใช้งานไม่ได้ ข้อมูลไบโอเมตริกคลาส 3 อาจได้รับอนุญาตให้รีเซ็ตการล็อกเอาต์ ตัวนับข้อมูลไบโอเมตริกที่ล็อกไว้ของคลาสเดียวกันหรือต่ำกว่า คลาส 2 หรือ ข้อมูลไบโอเมตริกคลาส 1 ต้องไม่ได้รับอนุญาตให้ทำการล็อกการรีเซ็ต สำหรับข้อมูลไบโอเมตริก

• [C-SR-3] มีคำแนะนำอย่างยิ่งให้ยืนยันข้อมูลไบโอเมตริกเพียงรายการเดียว ต่อการตรวจสอบสิทธิ์ (เช่น หากมีทั้งเซ็นเซอร์ลายนิ้วมือและใบหน้า ในอุปกรณ์ onAuthenticationSucceed ควรส่งหลังจากได้รับการยืนยันแล้ว)

เพื่อให้สามารถใช้งานอุปกรณ์เพื่ออนุญาตการเข้าถึงคีย์สโตร์ไปยัง แอปพลิเคชันของบุคคลที่สาม

• [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 วินาที โดยที่ การทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ที่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
• [C-SR-4] แนะนำอย่างยิ่งให้ลดจำนวนการทดลองที่ผิดพลาดทั้งหมด สำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุใน [C-1-9] หากการปลอมแปลงและผู้แอบอ้าง อัตราการยอมรับสูงกว่า 7% เมื่อวัดด้วยข้อมูลไบโอเมตริกของ Android ทดสอบโปรโตคอล
• [C-1-3] ต้องพยายามจำกัดจำนวนอัตราสำหรับการยืนยันข้อมูลไบโอเมตริก โดยที่ การทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ที่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
• [C-SR-5] แนะนำอย่างยิ่งให้ลองจำกัดอัตราคำขออย่างน้อย 1 ครั้ง 30 วินาทีหลังจากการทดลองที่ผิดพลาด 5 ครั้งสำหรับการยืนยันข้อมูลไบโอเมตริกสำหรับ จำนวนสูงสุดของการทดลองที่ผิดพลาดต่อ [C-1-9] - โดยที่การทดลองที่เป็นเท็จคือ หนึ่งครั้งที่มี คุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับ ข้อมูลไบโอเมตริกที่ลงทะเบียน
• [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้กำหนดตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE
• [C-1-10] ต้องปิดใช้ข้อมูลไบโอเมตริกเมื่อการย้อนกลับการตรวจสอบสิทธิ์หลักมี เกิดขึ้นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วนที่ 9.11
• [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและการหลอกลวงที่ไม่สูงกว่า 30% ที่มี (1) อัตราการยอมรับการปลอมแปลงและการหลอกลวงสำหรับการนำเสนอระดับ A ประเภทเครื่องมือโจมตี (PAI) ไม่เกิน 30% และ (2) การปลอมแปลงและ อัตราการยอมรับของสปีชีส์ระดับ B PAI ไม่สูงกว่า 40% เนื่องจาก วัดโดยโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-1-4] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่ได้สร้าง ห่วงโซ่ความไว้วางใจโดยให้ผู้ใช้ยืนยันว่ามีอยู่แล้วหรือเพิ่มอุปกรณ์ใหม่ ข้อมูลเข้าสู่ระบบ (PIN/รูปแบบ/รหัสผ่าน) ที่รักษาความปลอดภัยโดย TEE Android Open การนำโปรเจ็กต์แหล่งที่มามาใช้จะทำให้มีกลไกในกรอบการทำงาน ดังนั้น

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-6] ต้องให้เกียรติธงแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT DevicePolicymanager.KEYGUARD_DISABLE_FACE, หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-SR-7] แนะนำอย่างยิ่งให้ใช้ตรรกะในเฟรมเวิร์กที่ให้ไว้ โดยโครงการโอเพนซอร์ส Android เพื่อบังคับใช้ข้อจำกัดที่ระบุไว้ใน [C-1-7] และ [C-1-8] สำหรับอุปกรณ์ใหม่
• [C-SR-8] ได้รับการแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาด น้อยกว่า 10% ตามที่วัดในอุปกรณ์
• [C-SR-9] แนะนำอย่างยิ่งให้เวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจาก นับตั้งแต่ที่ตรวจพบข้อมูลไบโอเมตริก จนกระทั่งหน้าจอปลดล็อก ข้อมูลไบโอเมตริกที่ลงทะเบียน
• [C-1-12] ต้องมีอัตราการยอมรับการปลอมแปลงและการหลอกลวงที่ไม่สูงกว่า 40% ต่อสายพันธุ์เครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-SR-13] ได้รับการแนะนำอย่างยิ่งให้ปลอมแปลงและ อัตราการยอมรับของผู้หลอกลวงไม่เกิน 30% ต่อสายพันธุ์เครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-SR-8] ได้รับการแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาด น้อยกว่า 10% ตามที่วัดในอุปกรณ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-SR-14] ขอแนะนำอย่างยิ่งให้เปิดเผยคลาสข้อมูลไบโอเมตริกของ เซ็นเซอร์ไบโอเมตริกและความเสี่ยงที่เกี่ยวข้องในการเปิดใช้เซ็นเซอร์

• [C-SR-17] แนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซ AIDL ใหม่ (เช่น IFace.aidl และ IFingerprint.aidl)

หากการใช้งานอุปกรณ์ต้องการจัดการเซ็นเซอร์ไบโอเมตริกเป็นคลาส 2 (เดิมเรียกว่าไม่รัดกุม) ได้แก่

• [C-2-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 1 ข้างต้น
• [C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและการหลอกลวงที่ไม่สูงกว่า 20% ที่มี (1) อัตราการยอมรับการปลอมแปลงและการปลอมแปลงสำหรับ ชนิดเครื่องมือโจมตี (PAI) ระดับ A ไม่สูงกว่า 20% และ (2) อัตราการยอมรับสปีชีส์ระดับ B PAI ระดับ B สูงกว่า 30% โดยวัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-SR-15] ได้รับการแนะนำอย่างยิ่งให้ปลอมแปลงหรือหลอกลวง อัตราการยอมรับไม่สูงกว่า 20% ต่อสายพันธุ์เครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-2-3] ต้องดำเนินการ การจับคู่ไบโอเมตริกในสภาพแวดล้อมการดำเนินการที่แยกต่างหากภายนอก Android ผู้ใช้หรือพื้นที่เคอร์เนล เช่น Trusted Execution Environment (TEE) บนชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหาก หรือในเครื่องเสมือนที่มีการป้องกันซึ่งตรงตามข้อกำหนดในข้อ 9.17
• [C-2-4] ต้องมีข้อมูลที่ระบุตัวบุคคลนั้นได้ทั้งหมดที่เข้ารหัสและเข้ารหัส ตรวจสอบสิทธิ์เพื่อไม่ให้ได้รับ อ่าน หรือเปลี่ยนแปลงนอก สภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยในการเข้าถึง สภาพแวดล้อมการดำเนินการแยกต่างหากตามที่ระบุไว้ใน การใช้งาน หลักเกณฑ์ ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android หรือเครื่องเสมือนที่มีการป้องกัน ควบคุมโดย Hypervisor ซึ่งเป็นไปตามข้อกำหนดในข้อ 9.17
• [C-2-5] สำหรับข้อมูลไบโอเมตริกที่ใช้กล้อง แต่การตรวจสอบสิทธิ์ที่อิงตามข้อมูลไบโอเมตริก หรือการลงทะเบียน
  • ต้องใช้กล้องในโหมดที่ป้องกันไม่ให้เฟรมกล้อง ถูกอ่านหรือเปลี่ยนแปลงภายนอกสภาพแวดล้อมการดำเนินการที่แยกต่างหากหรือชิป ที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหากหรือ เครื่องเสมือนที่ควบคุมโดย Hypervisor ที่เป็นไปตามข้อกำหนดในส่วน 9.17
  • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องสามารถเป็น สามารถอ่านได้ภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้เพื่อรองรับการดำเนินการ เช่น ตัวอย่างสำหรับการลงทะเบียน แต่ต้องไม่สามารถแก้ไขได้
• [C-2-6] ต้องไม่เปิดใช้งานแอปพลิเคชันของบุคคลที่สามเพื่อแยก การลงทะเบียนข้อมูลไบโอเมตริกรายบุคคล
• [C-2-7] ต้องไม่เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลได้ โดยไม่เข้ารหัส หรือ ข้อมูลใดก็ตามที่ได้มาจากไฟล์ (เช่น การฝัง) ไปยังตัวประมวลผลแอปพลิเคชัน นอกบริบทของ TEE หรือการควบคุมเครื่องเสมือนที่มีการป้องกัน โดยไฮเปอร์ไวเซอร์ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17 การอัปเกรดอุปกรณ์ที่เปิดตัวใน 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) อัตราการยอมรับการปลอมแปลงและการปลอมแปลงสำหรับ ชนิดเครื่องมือโจมตี (PAI) ระดับ A ไม่สูงกว่า 7% และ (2) อัตราการปลอมแปลงและการยอมรับของสปีชีส์ PAI ระดับ B ไม่สูงกว่า 20% โดยวัดผลโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
• [C-3-4] ต้องตอบผู้ใช้สำหรับคำถามหลักที่แนะนำ การตรวจสอบสิทธิ์ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 72 ชั่วโมง หรือน้อยกว่านั้น
• [C-3-5] ต้องสร้าง Authenticator ID อีกครั้ง สำหรับข้อมูลไบโอเมตริกคลาส 3 ทั้งหมดที่รองรับในอุปกรณ์ หากมี ลงทะเบียนอีกครั้ง
• [C-3-6] ต้องเปิดใช้คีย์สโตร์ที่ใช้ข้อมูลไบโอเมตริกกับบุคคลที่สาม แอปพลิเคชัน

• [C-SR-16] ได้รับการแนะนำอย่างยิ่งให้ปลอมแปลงหรือหลอกลวง อัตราการยอมรับไม่สูงกว่า 7% ต่อสายพันธุ์เครื่องมือโจมตี (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android หากการใช้งานอุปกรณ์มีเซ็นเซอร์ลายนิ้วมือใต้จอแสดงผล (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 (UWB)

หากการใช้งานอุปกรณ์มีการรองรับ 802.1.15.4 และเปิดให้ กับแอปพลิเคชันของบุคคลที่สามได้

• [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
• [C-1-3] ต้องรองรับชุดการกำหนดค่าต่อไปนี้ทั้งหมด (ที่กำหนดไว้ล่วงหน้า ชุดค่าผสมของพารามิเตอร์ FIRA UCI) กำหนดไว้ในการใช้งาน AOSP
  • CONFIG_ID_1: ช่วง Unicast STATIC STS DS-TWR ที่กำหนดโดย FiRa โหมดหน่วงเวลา ช่วง 240 มิลลิวินาที
  • CONFIG_ID_2: ช่วง STATIC STS DS-TWR แบบ 1 ต่อหลายรายการที่ FiRa กำหนด โหมดหน่วงเวลา ช่วง 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 จะระงับ UWB_RANGING สิทธิ์ (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)

ผ่านการทดสอบความสอดคล้องและการรับรองที่เกี่ยวข้องตามที่กำหนดโดยมาตรฐาน องค์กรต่างๆ ซึ่งรวมถึง FIRA CCC และ CSA ช่วยให้ 802.1.15.4 ทำงานได้อย่างถูกต้อง

7.4 การเชื่อมต่อข้อมูล

7.4.1 โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้กล่าวถึง ฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรออกและการส่งข้อความ SMS หรือ การสร้างข้อมูลมือถือผ่านโทรศัพท์มือถือ (เช่น GSM, CDMA, LTE, NR)GSM หรือ CDMA เครือข่าย อุปกรณ์ที่รองรับ "โทรศัพท์" อาจเลือกที่จะเสนอ บริการการโทร รับส่งข้อความ และอินเทอร์เน็ตตามความเหมาะสม

• 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] ต้องประกาศ 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) และ Rich Communication Services (RCS) และควรจะสอดคล้องกับ กับผู้ให้บริการเครือข่ายมือถือเกี่ยวกับการใช้ การลงทะเบียน IMS สำหรับการรับส่งข้อมูลที่มีการส่งสัญญาณ IMS ทั้งหมดจะต้อง

• [C-5-1] ต้องประกาศ android.hardware.telephony.ims แฟล็กฟีเจอร์ และจัดเตรียมการติดตั้งใช้งาน ImsService API สำหรับทั้ง User Capability Exchange API ของ MMTEL และ RCS
• [C-5-2] ต้องประกาศ android.hardware.telephony.ims.singlereg แฟล็กฟีเจอร์ และติดตั้งใช้งาน SipTransport API ให้เสร็จสมบูรณ์ GbaService API ข้อบ่งชี้สำหรับผู้ถือโดยเฉพาะโดยใช้ IRadio 1.6 HAL และการจัดสรร ผ่านเซิร์ฟเวอร์การกำหนดค่าอัตโนมัติ (ACS) หรือการจัดสรรที่เป็นกรรมสิทธิ์อื่นๆ โดยใช้ API การกำหนดค่า IMS

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony ระบบจะดำเนินการดังนี้

• [C-6-1] SmsManager#sendTextMessage และ SmsManager#sendMultipartTextMessage "ต้อง" ทำให้การเรียกที่สอดคล้องไปยัง CarrierMessagingService สำหรับการให้บริการฟังก์ชันการรับส่งข้อความ SmsManager#sendMultimediaMessage และ SmsManager#downloadMultimediaMessage "ต้อง" ทำให้การเรียกที่สอดคล้องไปยัง CarrierMessagingService สำหรับให้บริการฟังก์ชันการรับส่งข้อความมัลติมีเดีย
• [C-6-2] แอปพลิเคชันที่กำหนดโดย android.provider.Telephony.Sms#getDefaultSmsPackage ต้องใช้ เครื่องมือจัดการ SMS 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] ต้องประกาศ 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] ต้องบล็อกการโทรและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockNumberProvider" โดยที่ไม่โต้ตอบกับแอปใดๆ เลย ข้อยกเว้นเพียงอย่างเดียว คือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ใน 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 กิจกรรมสำหรับ android.telecom API ต่อไปนี้

  • โทร 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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [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 ระดับสูง (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 Tunneled Direct Link (TDLS) ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีการรองรับ TDLS และ TDLS มีการเปิดใช้งานโดย Wi-FiManager API โดยจะมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศการรองรับ TDLS จนถึงวันที่ WifiManager.isTdlsSupported
• ควรใช้ TDLS เมื่อเป็นไปได้และเป็นประโยชน์เท่านั้น
• ควรมีการเรียนรู้และไม่ใช้ TDL เมื่อประสิทธิภาพ แย่กว่าการใช้ จุดเข้าใช้งาน Wi-Fi

7.4.2.3 การรับรู้ Wi-Fi

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

• ควรมีการสนับสนุนสำหรับ Wi-Fi Aware

หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Aware และเปิดเผย ไปยังแอปของบุคคลที่สามได้ จากนั้นกับผลิตภัณฑ์

• [C-1-1] ต้องใช้ WifiAwareManager API ตามที่อธิบายไว้ใน เอกสารประกอบเกี่ยวกับ SDK
• [C-1-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.wifi.aware
• [C-1-3] ต้องรองรับการทำงาน Wi-Fi และ Wi-Fi Aware พร้อมกัน
• [C-1-4] ต้องสุ่มที่อยู่ของอินเทอร์เฟซการจัดการ Wi-Fi Aware เป็นระยะๆ ไม่เกิน 30 นาทีและเมื่อใดก็ตามที่เปิดใช้ Wi-Fi Aware ยกเว้นในกรณีที่ Aware กำลังดำเนินการระยะหรือเส้นทางข้อมูลของ Aware ทำงานอยู่ (การสุ่มไม่ ต้องการตราบเท่าที่เส้นทางข้อมูลทำงานอยู่)

หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Aware และ ตำแหน่ง 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 โดยเฉพาะที่เกี่ยวข้อง ของการค้นพบและการเลือกเครือข่าย เช่น โฆษณาทั่วไป บริการ (GAS) และโปรโตคอลการค้นหาเครือข่ายการเข้าถึง (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 ของต้นทางสำหรับการถ่ายภาพอัจฉริยะแต่ละครั้ง ซึ่งจะดำเนินการขณะที่อินเทอร์เฟซ 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

หากการใช้งานอุปกรณ์มีการรองรับการลดภาระงาน Wi-Fi Keepalive และแสดงฟังก์ชันการทำงานนี้ให้แอปของบุคคลที่สาม

• [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)

หากการติดตั้งใช้งานอุปกรณ์รองรับความน่าเชื่อถือในการใช้งานครั้งแรก (TOFU) และ อนุญาตให้ผู้ใช้กำหนดการกำหนดค่า WPA/WPA2/WPA3-Enterprise ให้ดำเนินการดังนี้

• [C-4-1] ต้องระบุตัวเลือกให้ผู้ใช้เลือกใช้ TOFU

7.4.3 บลูทูธ

หากอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ ระบบจะดำเนินการต่อไปนี้

• ควรรองรับตัวแปลงรหัสเสียงขั้นสูงและตัวแปลงรหัสเสียงบลูทูธ (เช่น LDAC)

หากการติดตั้งใช้งานอุปกรณ์รองรับ HFP, A2DP และ AVRCP ก็จะส่งผลดังนี้

• ควรรองรับอุปกรณ์ทั้งหมดที่เชื่อมต่ออย่างน้อย 5 เครื่อง

หากการใช้งานอุปกรณ์ประกาศ android.hardware.vr.high_performance เหล่านี้

• [C-1-1] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวของข้อมูล Bluetooth LE

Android มีการสนับสนุนสำหรับบลูทูธและบลูทูธพลังงานต่ำ

หากอุปกรณ์รองรับบลูทูธและบลูทูธ วิดีโอพลังงานต่ำ:

• [C-2-1] ต้องประกาศฟีเจอร์ที่เกี่ยวข้องของแพลตฟอร์ม (android.hardware.bluetooth และ android.hardware.bluetooth_le ) และใช้งาน API ของแพลตฟอร์มตามลำดับ
• ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVRCP, OBEX, HFP ฯลฯ ตามความเหมาะสมสำหรับอุปกรณ์

หากอุปกรณ์รองรับบลูทูธพลังงานต่ำ (BLE) จะมีผลดังนี้

• [C-3-1] ต้องประกาศฟีเจอร์ของฮาร์ดแวร์ android.hardware.bluetooth_le
• [C-3-2] ต้องเปิดใช้บลูทูธที่ใช้ GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK และ android.bluetooth
• [C-3-3] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isOffloadedFilteringSupported() เพื่อระบุว่า ตรรกะการกรองสำหรับ ScanFilter มีการใช้คลาส API
• [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()

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

• [C-5-1] ต้องส่งคืน true เป็นเวลา BluetoothAdapter.getProfileProxy(context, Listenerer, 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 เสาอากาศ (ถ้าใช้หลายรายการ) อยู่ห่างกันไม่เกิน +/-3 dB เป็นเวลา 95% ของ การวัดค่าต่างๆ
• [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้วัดและชดเชยการชดเชย Rx ให้กับ ตรวจสอบว่าค่ามัธยฐานของ BLE RSSI คือ -60dBm +/-10 dB ที่ระยะห่าง 1 เมตรจาก อ้างอิงอุปกรณ์ที่กำลังส่งเมื่อ ADVERTISE_TX_POWER_HIGH โดยที่อุปกรณ์อยู่ โดยให้อยู่บน "ระนาบคู่ขนาน" โดยหันหน้าจอด้านเดียวกัน เส้นทางการเรียนรู้
• [C-SR-3] ได้รับการแนะนำอย่างยิ่งให้วัดและชดเชยค่าชดเชย Tx ให้กับ ตรวจสอบว่าค่ามัธยฐานของ BLE RSSI คือ -60 dBm +/-10 dB เมื่อสแกนจากข้อมูลอ้างอิง อุปกรณ์อยู่ในตำแหน่งที่ระยะห่าง 1 เมตรและกำลังส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH ซึ่งอุปกรณ์จะต้องเปิดใช้งาน "ระนาบคู่ขนาน" โดยหันหน้าจอไปในทิศทางเดียวกัน

ขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดผลที่ระบุไว้ใน ข้อกําหนดในการปรับเทียบสถานที่ตั้ง

7.4.4 การสื่อสารระยะใกล้

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

• ควรรวมตัวรับสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near Field Communications (NFC)
• [C-0-1] ต้องใช้ android.nfc.NdefMessage และ android.nfc.NdefRecord API แม้ว่าจะไม่รองรับ 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 Google อีกด้วย

โปรดทราบว่าลิงก์สาธารณะไม่พร้อมใช้งานสำหรับ JIS, ISO และ NFC ข้อกำหนดของฟอรัมที่กล่าวถึงข้างต้น

Android มีการสนับสนุนโหมด NFC Host Card Emulation (HCE)

หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) รวมถึงรองรับการกำหนดเส้นทางรหัสแอปพลิเคชัน (AID) ซึ่งมีคุณสมบัติดังต่อไปนี้

• [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
• [C-2-2] ต้องรองรับ NFC HCE API ในฐานะ ที่กำหนดไว้ใน Android SDK

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

• [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hcef
• [C-3-2] ต้องใช้ API การจำลองการ์ด NFC ตามที่ระบุไว้ใน Android SDK

หากการใช้งานอุปกรณ์มีการรองรับ NFC ทั่วไปตามที่อธิบายไว้ใน และสนับสนุนเทคโนโลยี MIFARE (MIFARE Classic MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทผู้อ่าน/ผู้เขียนจะมีคุณสมบัติดังนี้

• [C-4-1] ต้องใช้ Android API ที่สอดคล้องกันตามเอกสารประกอบ Android SDK
• [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จาก android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android จึงไม่ ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5 โปรโตคอลและ API ของเครือข่าย

7.4.5.1 ความสามารถของเครือข่ายขั้นต่ำ

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

• [C-0-1] ต้องมีการสนับสนุนสำหรับรูปแบบต่อไปนี้ เครือข่ายข้อมูล กล่าวอย่างเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ต้องมีการรองรับ มาตรฐานข้อมูลที่มีขนาดไม่เกิน 200 กิโลบิต/วินาที หรือสูงกว่า ตัวอย่างของ เทคโนโลยีที่ตรงตามข้อกำหนดนี้ ได้แก่ 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 Socket
• [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
  • ต้องตรวจสอบให้แน่ใจว่าการสื่อสารของ IPv6 มีความเสถียรเหมือนกับ IPv4 ตัวอย่างเช่น
    • [C-0-4] ต้องใช้การเชื่อมต่อ IPv6 ในโหมด Doze
    • [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสีย IPv6 สามารถเชื่อมต่อกับเครือข่ายใดก็ได้ที่รองรับ IPv6 ซึ่งใช้อายุการใช้งานของ RA อย่างน้อย 180 วินาที
• [C-0-6] ต้องระบุแอปพลิเคชันของบุคคลที่สามที่มีการเชื่อมต่อ IPv6 โดยตรง ไปยังเครือข่ายเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีที่อยู่รูปแบบใดๆ หรือ การแปลพอร์ตเกิดขึ้นภายในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort) และ NDK API เช่น getsockname() หรือ IPV6_PKTINFO จะต้องส่งคืน IP ที่ใช้เพื่อส่งและรับแพ็กเก็ตบน เครือข่ายและแสดงเป็น IP ต้นทางและพอร์ตไปยังเซิร์ฟเวอร์อินเทอร์เน็ต (เว็บ)

ระดับการสนับสนุน IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่ายดังที่แสดงใน ข้อกำหนดต่อไปนี้

หากอุปกรณ์รองรับ Wi-Fi ระบบจะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi

การใช้งานอุปกรณ์รองรับอีเทอร์เน็ตจะเป็นดังนี้

• [C-2-1] ต้องรองรับการดำเนินการแบบสแต็กคู่และ 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 API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] ต้องดำเนินการตรวจจับแคพทีฟพอร์ทัลและรองรับการเข้าสู่ระบบ ผ่านแอปพลิเคชันแคพทีฟพอร์ทัลเมื่อมีการเชื่อมต่ออุปกรณ์ ไปยังเครือข่ายประเภทใดก็ได้ทั้งเครือข่ายมือถือ/มือถือ, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
• [C-1-3] ต้องรองรับการเข้าสู่ระบบแคพทีฟพอร์ทัลโดยใช้ cleartext DNS เมื่อมีการกำหนดค่าอุปกรณ์ให้ใช้โหมด DNS แบบเข้มงวดส่วนตัว
• [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสาร SDK สำหรับ android.net.LinkProperties.getPrivateDnsServerName และ android.net.LinkProperties.isPrivateDnsActive สำหรับการจราจรของข้อมูลในเครือข่ายทั้งหมดที่ไม่ได้สื่อสารกับ แคพทีฟพอร์ทัล
• [C-1-5] ต้องตรวจสอบว่าขณะที่ผู้ใช้ลงชื่อเข้าสู่ระบบ Captive พอร์ทัล ซึ่งเป็นเครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่แอปพลิเคชันแสดงผล 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 สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยตาม UICC android.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 เป็นการระงับวิทยุ (ในส่วนกลุ่มสิทธิ์ NEARBY_DEVICES)
• [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้ส่งต่อความสอดคล้องที่เกี่ยวข้องและ การทดสอบเพื่อรับใบรับรองที่กำหนดโดยองค์กรมาตรฐาน ซึ่งรวมถึง FIRA, CCC และ CSA
• [C-1-6] ต้องตรวจสอบว่าการวัดระยะทางอยู่ภายใน +/-15 ซม. สำหรับ 95% ของการวัดในระดับแนวสายตาที่ระยะ 1 เมตรใน แบบไม่ใช่เงาสะท้อน
• [C-1-7] ต้องตรวจสอบให้แน่ใจว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ภายในระยะ [0.75 ม., 1.25 ม.] โดยข้อมูลจากภาคพื้นดิน ระยะทางวัดจากขอบด้านบนของ DUT
• [C-SR-2] ได้รับการแนะนําอย่างยิ่งให้ทำตามขั้นตอนการตั้งค่าการวัดผล ที่ระบุใน ข้อกําหนดในการปรับเทียบสถานที่ตั้ง

7.5 กล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้

• [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.camera.any
• [C-1-2] ต้องเป็นไปได้เพื่อให้แอปพลิเคชันจัดสรร 3 RGBA_8888 บิตแมปเท่ากับขนาดของภาพที่สร้างโดย เซ็นเซอร์กล้องที่มีความละเอียดมากที่สุดในอุปกรณ์ ขณะที่กล้องเปิดอยู่สำหรับ เพื่อแสดงตัวอย่างพื้นฐานและยังคงจับภาพได้
• [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 บิตสำหรับทั้งอุปกรณ์หลัก กล้อง
• [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] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้า กล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวในอุปกรณ์ก็ตาม
• [C-1-4] ภาพตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนโดยให้สัมพันธ์กับภาพ การวางแนวที่ระบุโดยแอปพลิเคชันเมื่อแอปพลิเคชันปัจจุบันมี ขอให้ตั้งค่ากล้อง ถูกหมุนผ่านการเรียกไปยัง android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน ตัวอย่างจะต้องแสดงตามค่าเริ่มต้นของอุปกรณ์ แกนแนวนอนเมื่อแอปพลิเคชันปัจจุบันไม่ได้ส่งคำขออย่างชัดเจน ว่าจอแสดงผลของกล้องจะหมุนผ่านการเรียกไปยัง android.hardware.Camera.setDisplayOrientation()
• [C-1-5] ต้องไม่มิเรอร์ภาพนิ่งหรือสตรีมวิดีโอสุดท้ายที่บันทึก กลับไปที่ Callback ของแอปพลิเคชันหรือคอมมิตพื้นที่เก็บข้อมูลสื่อ
• [C-1-6] ต้องจำลองภาพที่แสดงหลังมุมมองโพสต์ในลักษณะเดียวกัน เป็นสตรีมรูปภาพตัวอย่างจากกล้อง
• อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่มีให้ใช้งาน กล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

หากผู้ใช้เปลี่ยนการใช้งานอุปกรณ์ได้ (เช่น โดยอัตโนมัติผ่านตัวตรวจวัดความเร่งหรือด้วยตนเองผ่านอินพุตของผู้ใช้):

• [C-2-1] ภาพตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนโดยสัมพันธ์กับ การวางแนวปัจจุบันของอุปกรณ์

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

กล้องภายนอกคือกล้องที่สามารถเชื่อมต่อหรือถอดออก การติดตั้งใช้งานอุปกรณ์ได้ตลอดเวลาและหันไปในทิศทางใดก็ได้ เช่น USB กล้อง

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

• อาจรวมการสนับสนุนกล้องภายนอกที่อาจไม่จำเป็น เชื่อมต่อตลอดเวลา

หากการใช้งานอุปกรณ์มีการรองรับกล้องภายนอก จะมีผลดังนี้

• [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
• [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 หรือสูงกว่า) หากอุปกรณ์ภายนอก กล้องเชื่อมต่อผ่านพอร์ตโฮสต์ USB
• [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องด้วยอุปกรณ์กล้องภายนอกที่จับต้องได้ เชื่อมต่อ แล้ว ดูรายละเอียดการทดสอบ CTS ของกล้องได้ที่ source.android.com
• ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้โอน สตรีมคุณภาพสูงที่ไม่ได้เข้ารหัส (เช่น รูปภาพที่บีบอัดแบบเป็นไฟล์ RAW หรือรูปภาพที่บีบอัดแบบอิสระ) สตรีม)
• อาจรองรับกล้องหลายตัว
• อาจรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง

หากระบบรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง ให้ทำดังนี้

• [C-2-1] ในเวลาเดียวกัน สตรีมที่ไม่เข้ารหัส / สตรีม MJPEG (QVGA หรือความละเอียดสูงกว่า) ต้องสามารถเข้าถึงได้ การติดตั้งใช้งานอุปกรณ์

7.5.4 การทำงานของ API กล้องถ่ายรูป

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

แพ็กเกจ 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) สำหรับการแสดงตัวอย่างจากกล้องสำหรับทั้ง 2 กลุ่ม กล้องหน้าและกล้องหลังสำหรับ 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 อินสแตนซ์ (แม้ว่าจะไม่มี กับกล้องที่ไม่โฟกัสอัตโนมัติ) โปรดทราบว่าการดำเนินการนี้จะใช้กับกล้องหน้า กล้อง แม้ว่ากล้องหน้าส่วนใหญ่ไม่รองรับ โฟกัสอัตโนมัติ Callback ของ API ยังคงเป็น "Faked" ตามที่อธิบายไว้
• [C-0-6] ต้องรู้จักและทำตามชื่อพารามิเตอร์แต่ละชื่อ เป็นค่าคงที่ในเมตริก android.hardware.Camera.Parameters และชั้นเรียน android.hardware.camera2.CaptureRequest ในทางกลับกัน การใช้งานอุปกรณ์จะต้อง "ไม่" ยอมรับหรือรับรู้ "ค่าคงที่ของสตริง" ที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() ที่ไม่ใช่เมธอด ได้รับการบันทึกเป็นค่าคงที่ใน android.hardware.Camera.Parameters นั่นคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมด หาก อนุญาตและต้องไม่รองรับประเภทพารามิเตอร์กล้องถ่ายรูปที่กำหนดเอง ตัวอย่างเช่น การใช้งานอุปกรณ์ที่สนับสนุนการจับภาพ ที่ใช้เทคนิคการสร้างภาพที่มีช่วงไดนามิกกว้าง (HDR) ต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR
• [C-0-7] ต้องรายงานระดับการสนับสนุนที่เหมาะสมของ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK และรายงาน แฟล็กฟีเจอร์เฟรมเวิร์ก
• [C-0-8] ต้องประกาศความสามารถของกล้องแต่ละตัว android.hardware.camera2 ผ่าน พร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศแฟล็กฟีเจอร์ที่เหมาะสม ต้องกำหนดธงทำเครื่องหมายฟีเจอร์หากอุปกรณ์กล้องที่เชื่อมต่ออยู่ จะรองรับฟีเจอร์นี้
• [C-0-9] ต้องประกาศ Camera.ACTION_NEW_PICTURE เมื่อใดก็ตามที่กล้องถ่ายภาพใหม่และภาพที่ป้อน เพิ่มรูปภาพในที่เก็บสื่อแล้ว
• [C-0-10] ต้องประกาศ Camera.ACTION_NEW_VIDEO เมื่อใดก็ตามที่กล้องบันทึกวิดีโอใหม่และรายการ เพิ่มรูปภาพในที่เก็บสื่อแล้ว
• [C-0-11] ต้องมีกล้องทุกตัวที่เข้าถึงได้ผ่านทาง 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] ต้องระบุ ตัวจัดการการดาวน์โหลด ที่แอปพลิเคชันสามารถใช้ในการดาวน์โหลดไฟล์ข้อมูล และ "ต้อง" สามารถ ดาวน์โหลดไฟล์ขนาดอย่างน้อย 100 MB เป็นค่าเริ่มต้น "แคช" ตำแหน่งนั้น

7.6.2 พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน

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

• [C-0-1] ต้องเสนอพื้นที่เก็บข้อมูลสำหรับใช้ร่วมกันระหว่างแอปพลิเคชัน ซึ่งบ่อยครั้งที่เรียกกันว่า เป็น "ที่จัดเก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน" หรือระบบ Linux เส้นทาง "/sdcard" ก็ติดอยู่
• [C-0-2] ต้องกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันที่ต่อเชื่อมโดยค่าเริ่มต้น ว่า "พร้อมใช้งานทันที" ไม่ว่าจะใช้พื้นที่เก็บข้อมูลบน คอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อการเก็บข้อมูลที่ถอดออกได้ (เช่น Secure ช่องเสียบการ์ดดิจิทัล)
• [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันบนเส้นทาง Linux โดยตรง sdcard หรือใส่ลิงก์สัญลักษณ์ของ Linux จาก sdcard ไปยังตัวต่อเชื่อมจริง คะแนน
• [C-0-4] ต้องเปิดใช้ พื้นที่เก็บข้อมูลที่กำหนดขอบเขต โดยค่าเริ่มต้นสำหรับทั้งหมด แอปที่กำหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในสถานการณ์ต่อไปนี้
  • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
• [C-0-5] ต้องปกปิดข้อมูลเมตาของตำแหน่ง เช่น แท็ก Exif ของ GPS ซึ่งจัดเก็บไว้ใน ไฟล์สื่อเมื่อเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore ยกเว้นเมื่อ แอปการโทรจะถือสิทธิ์ ACCESS_MEDIA_LOCATION

การใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้ ดังต่อไปนี้:

• พื้นที่เก็บข้อมูลแบบถอดได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
• ส่วนหนึ่งของที่จัดเก็บข้อมูลภายใน (แบบถอดออกไม่ได้) ตามที่มีการใช้งานใน โครงการโอเพนซอร์ส Android (AOSP)

หากการใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดได้ตามข้อกำหนดข้างต้น ตามข้อกำหนดเหล่านี้

• [C-1-1] ต้องใช้ข้อความเตือนอินเทอร์เฟซผู้ใช้แบบข้อความโทสต์หรือป๊อปอัป เมื่อไม่มีสื่อพื้นที่เก็บข้อมูลแทรกอยู่ในช่องโฆษณา
• [C-1-2] ต้องใส่สื่อจัดเก็บข้อมูลรูปแบบ FAT (เช่น การ์ด SD) หรือรายการ บนกล่องและวัสดุอื่นๆ ที่มีอยู่ ณ เวลาที่ซื้อ ซึ่งพื้นที่เก็บข้อมูล ต้องซื้อสื่อแยกต่างหาก

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

• ควรใช้การใช้งาน AOSP ของแอปพลิเคชันภายในที่แชร์ พื้นที่เก็บข้อมูล
• อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

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

• [C-3-1] ต้องระบุกลไกในการเข้าถึงข้อมูลบนแอปพลิเคชัน ที่ใช้ร่วมกันจากคอมพิวเตอร์โฮสต์
• ควรแสดงเนื้อหาจากเส้นทางพื้นที่เก็บข้อมูลทั้งสองแบบโปร่งใสผ่าน บริการสแกนสื่อของ Android และ android.provider.MediaStore
• อาจใช้พื้นที่เก็บข้อมูลแบบ USB จำนวนมาก แต่ควรใช้โปรโตคอลการถ่ายโอนสื่อเพื่อให้เป็นไปตามข้อกำหนด ข้อกำหนดนี้

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

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

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

การที่อุปกรณ์ควรจะเป็นอุปกรณ์เคลื่อนที่โดยธรรมชาติ ซึ่งต่างจากโทรทัศน์ การติดตั้งใช้งานอุปกรณ์ ได้แก่

• [C-SR-1] แนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลแบบพื้นฐานใน ที่มั่นคงในระยะยาว เนื่องจากการเลิกเชื่อมต่อโดยไม่ตั้งใจนั้น ทำให้ข้อมูลสูญหาย/เสียหาย

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

• [C-SR-2] แนะนำอย่างยิ่งให้นำไปใช้ พื้นที่เก็บข้อมูลแบบ Adoptable

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 Power Delivery มาตรฐาน ขณะที่ ซึ่งเรียกว่า "แนะนำอย่างยิ่ง" สำหรับ Android เวอร์ชันต่อๆ ไป อาจต้องใช้อุปกรณ์ type-C ทั้งหมดเพื่อรองรับความสามารถในการทำงานร่วมกันอย่างเต็มรูปแบบกับรุ่น Standard ที่ชาร์จแบบ Type-C
• [C-SR-5] แนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับข้อมูลและ การสลับสวิตช์เมื่อรองรับโหมดโฮสต์ USB และ USB Type-C
• ควรสนับสนุน Power Delivery สำหรับการชาร์จไฟแรงสูงและรองรับ โหมดทางเลือก เช่น แสดงผล
• ควรใช้ Android Open Accessory (AOA) API และข้อมูลจำเพาะตาม อยู่ในเอกสารประกอบ Android SDK

หากการใช้งานอุปกรณ์มีพอร์ต USB และใช้ AOA โดยเฉพาะ

• [C-2-1] ต้องประกาศการรองรับฟีเจอร์ของฮาร์ดแวร์ android.hardware.usb.accessory
• [C-2-2] คลาสที่จัดเก็บข้อมูลจำนวนมากของ USB ต้องมีสตริง "android" ที่ สิ้นสุดสตริงคำอธิบายอินเทอร์เฟซ iInterface ของที่เก็บข้อมูล USB ขนาดใหญ่

7.7.2 โหมดโฮสต์ USB

หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ การใช้งานจะดังนี้

• [C-1-1] ต้องใช้ Android USB host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
• [C-1-2] ต้องใช้การสนับสนุนเพื่อเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ พวกเขาต้อง:
  • มีพอร์ต C ในอุปกรณ์หรือจัดส่งพร้อมสายที่ต่อกับอุปกรณ์ พอร์ตที่เป็นกรรมสิทธิ์ไปยังพอร์ต USB type-C มาตรฐาน (อุปกรณ์ USB Type-C)
  • มีประเภท A ในอุปกรณ์ หรือจัดส่งพร้อมสายที่ดัดแปลงใช้กับอุปกรณ์ พอร์ตที่เป็นกรรมสิทธิ์ไปยังพอร์ต USB type-A มาตรฐาน
  • มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรจัดส่งพร้อมกับสายที่ปรับได้ เข้ากับพอร์ตประเภท A มาตรฐาน
• [C-1-3] ต้องไม่จัดส่งด้วยอะแดปเตอร์ที่แปลงจาก USB ประเภท A หรือ พอร์ต micro-AB ให้กับพอร์ต type-C (เต้ารับ)
• [C-SR-1] แนะนำอย่างยิ่งให้ใช้ คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
• ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะอยู่ในโฮสต์ โหมด; การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุใน พารามิเตอร์การสิ้นสุดของ ข้อมูลจำเพาะของสาย USB Type-C และหัวต่อ 1.2 สำหรับ USB Type-C หัวชาร์จไฟฟ้าหรือใช้พอร์ตชาร์จดาวน์สตรีม (CDP) จะเอาต์พุตช่วงปัจจุบันเป็น ที่ระบุไว้ใน ข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB การแก้ไข 1.2 สำหรับหัวชาร์จ Micro-AB
• ควรใช้และสนับสนุนมาตรฐาน 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

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ เฟรมเวิร์กการเข้าถึงพื้นที่เก็บข้อมูล (SAF) ดังนี้

• [C-3-1] ต้องรับรู้ MTP (Media Transfer Protocol) ใดๆ ที่เชื่อมต่อจากระยะไกล และทำให้สามารถเข้าถึงเนื้อหาของอุปกรณ์ได้ผ่าน ACTION_GET_CONTENT ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT Intent

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

• [C-4-1] ต้องใช้ฟังก์ชัน Dual Role Port ตามที่กำหนดโดย USB ข้อมูลจำเพาะของ Type-C (ส่วนที่ 4.5.1.3.3) สำหรับ Dual พอร์ตบทบาท, ในอุปกรณ์ที่มีช่องเสียบหูฟัง 3.5 มม., ซิงก์ USB การตรวจพบ (โหมดโฮสต์) อาจปิดอยู่โดยค่าเริ่มต้น แต่ เพื่อเปิดใช้ได้
• [C-SR-2] แนะนำอย่างยิ่งให้รองรับ DisplayPort และควรรองรับ USB อัตราข้อมูล SuperSpeed และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
• [C-SR-3] แนะนำอย่างยิ่งให้ไม่รองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงเนื่องจาก ตามที่อธิบายไว้ในภาคผนวก A ของ ข้อมูลจำเพาะของสาย USB Type-C และหัวต่อ 1.2
• ควรใช้โมเดล 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] แนะนำอย่างยิ่งให้ใส่ฟิลด์ พอร์ตเสียงที่จะเป็นช่องเสียบหูฟัง 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
• [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
• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงด้วย OMTP ตามลำดับ PIN
• [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 เป็น "true" ต้องเป็นไปตามข้อกำหนดต่อไปนี้ VOICE_RECOGNITION และ UNPROCESSED แหล่งที่มาของเสียง:

• [C-1-1] การตอบสนองพลังงานเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องมีการตอบสนองต่ำกว่า 2 kHz ไม่เกิน 15 dB
• [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 ความสมบูรณ์ของสัญญาณ

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

• ควรระบุเส้นทางสัญญาณเสียงที่ไม่มีข้อบกพร่องสำหรับอินพุตทั้ง 2 ฝั่ง และสตรีมเอาต์พุตในอุปกรณ์พกพา ตามที่ระบุโดยข้อบกพร่อง 0 รายการ วัดระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ OboeTester "การทดสอบข้อบกพร่องอัตโนมัติ"

การทดสอบต้องใช้ดองเกิลวนซ้ำของเสียง ใช้ในช่องเสียบ 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 และสิ่งอำนวยความสะดวกในการสร้าง "ความเป็นจริงเสมือน" (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 ที่มีการกำหนดเลเยอร์ แฟล็ก และรูปแบบที่ระบุใน C-1-10 มากกว่า 1 รายการ
• [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps แล้วบีบอัดเป็นความเร็วเฉลี่ย 40Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x1080 ที่ 30 fps-10 Mbps หรือ 1920 x 1080 2 อินสแตนซ์ที่ 60 fps-20 Mbps)
• [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้เป็นอย่างน้อย ความละเอียด 1920 x 1080 ที่ 30 fps ถูกบีบอัดเป็นความเร็วเฉลี่ย 10 Mbps และควร สามารถถอดรหัส 3840 x 2160 ที่ 30 fps-20 Mbps (เทียบเท่ากับ 1920 x 1080 จำนวน 4 อินสแตนซ์ที่ 30 fps-5 Mbps)
• [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าที่แม่นยำสำหรับอุณหภูมิผิวหนัง
• [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 การโต้ตอบการสัมผัส

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

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

• [7.10/C] ต้องคืนค่า "เท็จ" สำหรับ Vibrator.hasVibrator()

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

• [C-1-1] ต้องแสดงผลเป็น "จริง" สำหรับ Vibrator.hasVibrator()
• ไม่ควรใช้ตัวดำเนินการแบบรู้สึกได้ (การสั่น) ที่หมุนรอบศูนย์กลาง (ERM)
• ควรใช้ค่าคงที่สาธารณะทั้งหมดเพื่อให้เกิดการโต้ตอบการสัมผัสที่ชัดเจน ใน 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 และ GESTURE_END)
• ควรใช้ค่าคงที่สาธารณะทั้งหมดเพื่อให้เกิดการโต้ตอบการสัมผัสที่ชัดเจน ใน android.os.VibrationEffect ได้แก่ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ EFFECT_DOUBLE_CLICK) และค่าคงที่ PRIMITIVE_* สาธารณะที่เป็นไปได้ทั้งหมดสำหรับ การโต้ตอบการสัมผัสที่สมบูรณ์ ใน android.os.VibrationEffect.Composition ได้แก่ (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD) ค่าพื้นฐานเหล่านี้บางส่วน เช่น LOW_TICK และ SPIN อาจทำได้ในกรณีที่การสั่นรองรับได้ค่อนข้างต่ำ ความถี่
• ควรปฏิบัติตามคำแนะนำสำหรับการแมปค่าคงที่สาธารณะ ใน android.view.HapticFeedbackConstants ไปยัง android.os.VibrationEffect ที่แนะนำ คงที่พร้อมความสัมพันธ์ของแอมพลิจูดที่สัมพันธ์กัน
• ควรใช้การแมปค่าคงที่แบบรู้สึกได้ที่ลิงก์ไว้เหล่านี้
• ควรปฏิบัติตามการประเมินคุณภาพ สำหรับ createOneShot() และ createWaveform() API
• ควรตรวจสอบยืนยันผลลัพธ์ของสาธารณะ android.os.Vibrator.hasAmplitudeControl() API แสดงความสามารถของการสั่นอย่างถูกต้อง
• ควรตรวจสอบความสามารถในการปรับขนาดแอมพลิจูดโดยเรียกใช้ android.os.Vibrator.hasAmplitudeControl()

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

• ควรยืนยันสถานะการติดตั้งใช้งานโดยเรียกใช้ android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitivesSupported() API
• ควรทำการประเมินคุณภาพ เพื่อหาค่าคงที่แบบรู้สึกได้
• ควรตรวจสอบและอัปเดตหากจำเป็นสำหรับการกำหนดค่าสำรองสำหรับ ประเภทพื้นฐานที่ไม่รองรับตามที่อธิบายไว้ในหลักเกณฑ์การใช้งาน สำหรับค่าคงที่
• ควรให้การสนับสนุนวิดีโอสำรองเพื่อลดความเสี่ยงของการล้มเหลวตามที่อธิบายไว้ ที่นี่

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 โดยใช้ 4 KB การเขียนบัฟเฟอร์

8.3 โหมดประหยัดพลังงาน

หากการใช้งานอุปกรณ์มีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ ที่รวมอยู่ใน AOSP (เช่น ที่เก็บข้อมูลสแตนด์บายแอป, Doze) หรือขยายฟีเจอร์ต่างๆ ในการใช้ข้อจำกัดที่เข้มงวดมากกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ถูกจำกัด โดยจะดำเนินการดังนี้

• [C-1-1] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการทริกเกอร์ การบำรุงรักษา อัลกอริทึมการปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลาง หรือ DeviceConfig โหมดประหยัดพลังงานของ App Standby และ 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 แบบตามที่กำหนดโดย การกำหนดค่าและ Power Interface (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] ต้องส่งคืนรายการที่ว่างเปล่าผ่านทาง Process.getExclusiveCores() เมธอดของ API

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 เป็นไปตามข้อกำหนดนี้โดยการอ่านและปฏิบัติตาม สิทธิ์ในรายการที่อนุญาตสำหรับแต่ละแอปจากไฟล์ใน etc/permissions/ และใช้เส้นทาง system/priv-app เป็น เส้นทางที่ได้รับสิทธิ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

สิทธิ์ที่มีระดับการป้องกันที่เป็นอันตรายคือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะส่งคำขอในช่วงรันไทม์

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

• [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจ จะให้สิทธิ์รันไทม์ที่ขอไหม และมอบ อินเทอร์เฟซสำหรับจัดการสิทธิ์รันไทม์

• [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 Intent มีหน้าจอ 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 ระดับระบบปฏิบัติการและข้อมูลแวดล้อม และ 9.8.15 การใช้ Sandboxed"

หากการใช้งานอุปกรณ์มีแอปพลิเคชันเริ่มต้นเพื่อรองรับ VoiceInteractionService พวกเขา:

• [C-5-1] ต้องไม่ให้สิทธิ์ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสำหรับการดำเนินการดังกล่าว แอปพลิเคชัน

9.2 การแยก UID และกระบวนการ

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

• [C-0-1] ต้องสนับสนุนแอปพลิเคชัน Android โมเดลแซนด์บ็อกซ์ ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID ของ Unixstyle ที่ไม่ซ้ำกัน และอยู่ในกระบวนการที่แยกต่างหาก
• [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการ เป็นรหัสผู้ใช้ Linux เดียวกัน หากมีการรับรองแอปพลิเคชันอย่างถูกต้อง และสร้างขึ้น ตามที่ระบุไว้ใน ข้อมูลอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์

9.3 สิทธิ์ของระบบไฟล์

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

• [C-0-1] ต้องรองรับการเข้าถึงไฟล์ของ Android ตามที่กำหนดไว้ใน ข้อมูลอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์

9.4 สภาพแวดล้อมการดำเนินการสำรอง

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

• [C-0-1] รันไทม์สำรองต้องเป็นแอปพลิเคชัน Android และปฏิบัติตามรูปแบบความปลอดภัยของ Android แบบมาตรฐานตามที่อธิบายไว้ในที่อื่นๆ ในส่วนที่ 9

• [C-0-2] รันไทม์สำรองต้องไม่มีสิทธิ์เข้าถึงทรัพยากร ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอใน AndroidManifest.xml ของรันไทม์ ผ่าน <uses-permission> Google Analytics

• [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 หรือระบบที่คล้ายกันเพื่อให้โฮสต์ PC ได้ เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

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

• [C-2-1] ต้องมีพื้นที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกันแบบแยกต่างหากและแยกต่างหาก ไดเรกทอรี (หรือที่เรียกว่า /sdcard) สำหรับอินสแตนซ์ของผู้ใช้แต่ละรายการ
• [C-2-2] ต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันที่เป็นของ และทำงานบน ในนามของผู้ใช้ที่ระบุไม่สามารถแสดงรายการ อ่าน หรือเขียนลงในไฟล์ที่เป็นเจ้าของ โดยผู้ใช้อื่นใด แม้ว่าข้อมูลของผู้ใช้ทั้งสองจะได้รับจัดเก็บในเว็บไซต์เดียวกัน หรือระบบไฟล์

การใช้งานอุปกรณ์อาจสร้างโปรไฟล์ผู้ใช้ประเภทเดียวเพิ่มเติม android.os.usertype.profile.CLONE เทียบกับผู้ใช้หลัก (และเฉพาะสำหรับ ผู้ใช้หลัก) โดยมีจุดประสงค์ในการใช้งานอินสแตนซ์คู่ของแอปเดียวกัน อินสแตนซ์คู่เหล่านี้ใช้พื้นที่เก็บข้อมูลที่แยกบางส่วนออกมาบางส่วน โดยจะแสดงต่อ ผู้ใช้ปลายทางใน Launcher พร้อมกันและปรากฏในมุมมองล่าสุดเดียวกัน ตัวอย่างเช่น สามารถใช้เพื่อสนับสนุนผู้ใช้การติดตั้ง อินสแตนซ์ของแอปเดียวในอุปกรณ์แบบ 2 ซิม

หากติดตั้งใช้งานอุปกรณ์ โปรดสร้างโปรไฟล์ผู้ใช้เพิ่มเติมที่กล่าวถึงข้างต้น ให้ดำเนินการดังนี้

• [C-3-1] ต้องให้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือข้อมูลที่มีอยู่แล้วเท่านั้น เข้าถึงได้จากโปรไฟล์ผู้ใช้หลัก หรือเป็นของรายการนี้โดยตรง โปรไฟล์ผู้ใช้เพิ่มเติม
• [C-3-2] ต้องไม่มีเป็นโปรไฟล์งาน
• [C-3-3] ต้องแยกไดเรกทอรีข้อมูลแอปส่วนตัวออกจากไฟล์หลัก บัญชีผู้ใช้
• [C-3-4] ต้องไม่อนุญาตให้สร้างโปรไฟล์ผู้ใช้เพิ่มเติมหากมี จัดสรรเจ้าของอุปกรณ์แล้ว (ดูหัวข้อ 3.9.1) หรืออนุญาตเจ้าของอุปกรณ์ ได้รับการจัดสรรโดยไม่ต้องนำโปรไฟล์ผู้ใช้เพิ่มเติมออกก่อน

หากติดตั้งใช้งานอุปกรณ์ โปรดสร้างโปรไฟล์ผู้ใช้เพิ่มเติมที่กล่าวถึงข้างต้น ให้ดำเนินการดังนี้

• [C-4-1] ต้องอนุญาต Intent ด้านล่างที่มาจาก โปรไฟล์ที่จะได้รับการจัดการโดยแอปพลิเคชันของผู้ใช้หลักในอุปกรณ์:

  • 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] ต้องรับค่าข้อจำกัดของผู้ใช้นโยบายด้านอุปกรณ์ทั้งหมดและเลือก ใช้ restrictions(list below) ที่ไม่ใช่ผู้ใช้กับผู้ใช้หลักของอุปกรณ์แล้ว กับโปรไฟล์ผู้ใช้เพิ่มเติมนี้

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] ต้องอนุญาตให้เขียนเฉพาะรายชื่อติดต่อจากโปรไฟล์เพิ่มเติมนี้ผ่านทาง Intent ต่อไปนี้

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] ต้องไม่มีการซิงค์รายชื่อติดต่อสำหรับแอปพลิเคชันที่ทำงาน โปรไฟล์ผู้ใช้เพิ่มเติมนี้

• [C-4-5] ต้องอนุญาตเฉพาะแอปพลิเคชันในโปรไฟล์เพิ่มเติมที่มี กิจกรรม Launcher เพื่อเข้าถึงรายชื่อติดต่อที่ โปรไฟล์ผู้ใช้หลัก

9.6 คำเตือนทาง SMS แบบพรีเมียม

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

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony ดังนี้

• [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลข ระบุโดยนิพจน์ทั่วไปที่กำหนดไว้ใน /data/misc/sms/codes.xml ไฟล์ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android มอบ การนำไปใช้ที่สอดคล้องกับข้อกำหนดนี้

9.7 ฟีเจอร์ความปลอดภัย

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

แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ Linux ที่เพิ่มประสิทธิภาพด้านความปลอดภัย (SELinux) ระบบการควบคุมการเข้าถึงที่บังคับ (MAC) แซนด์บ็อกซ์ seccomp และอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่เดิม SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ มีการใช้งานภายใต้ระบบปฏิบัติการ Android
• [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อมีการรักษาความปลอดภัย ฟีเจอร์ความปลอดภัยได้ตรวจพบการละเมิดและได้บล็อกเรียบร้อยแล้ว มีการใช้งานต่ำกว่าเฟรมเวิร์ก Android แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้ เมื่อเกิดการละเมิดด้านความปลอดภัยที่ไม่ถูกบล็อกจนทำให้สามารถเจาะระบบได้สำเร็จ
• [C-0-3] ต้องไม่ใช้งาน SELinux หรือคุณลักษณะด้านความปลอดภัยอื่นใด ภายใต้เฟรมเวิร์ก Android ที่กำหนดค่าได้สำหรับผู้ใช้หรือนักพัฒนาแอป
• [C-0-4] ต้องไม่อนุญาตแอปพลิเคชันที่อาจส่งผลกระทบต่อแอปพลิเคชันอื่น ผ่าน API (เช่น Device Administration API) เพื่อกำหนดค่านโยบาย ที่ทำลายความเข้ากันได้
• [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้ ก็เป็นไปได้ที่จะให้สิทธิ์เข้าถึงสำหรับแต่ละกระบวนการในขอบเขตที่แคบลง อธิบาย ในเว็บไซต์โครงการโอเพนซอร์ส Android
• [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนล ซึ่งอนุญาตให้กรองการเรียกใช้ของระบบโดยใช้นโยบายที่กำหนดค่าได้จาก โปรแกรมแบบหลายชุดข้อความ โปรเจ็กต์โอเพนซอร์ส Android มีการอัปเดต ข้อกำหนดผ่านการเปิดใช้ seccomp-BPF กับ Threadgroup การซิงค์ (TSYNC) ตามที่อธิบายไว้ ในส่วนการกำหนดค่าเคอร์เนลของ 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] ต้องใช้ขนาดวัตถุแบบคงที่และแบบไดนามิก การตรวจสอบขอบเขตของสำเนาระหว่าง User-Space และ Kernel Space (เช่น 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] แนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนล ซึ่งจะเขียนเฉพาะในช่วงเริ่มต้นที่มีเครื่องหมายอ่านอย่างเดียวหลังจาก การเริ่มต้น (เช่น __ro_after_init)

• [C-SR-2] แนะนำอย่างยิ่งให้สุ่มการจัดวางรหัสเคอร์เนลและ หน่วยความจำ และเพื่อหลีกเลี่ยงการสัมผัสที่จะส่งผลต่อการสุ่ม (เช่น CONFIG_RANDOMIZE_BASE ที่มีเอนโทรปี Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

• [C-SR-3] แนะนําอย่างยิ่งให้เปิดใช้ความสมบูรณ์ของการควบคุม (CFI) ใน เคอร์เนลเพื่อให้การป้องกันการโจมตีจากโค้ดที่ใช้ซ้ำได้ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

• [C-SR-4] ขอแนะนำเป็นอย่างยิ่งว่าอย่าปิดใช้ความสมบูรณ์ของการควบคุมขั้นตอน (CFI) Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) เปิดอยู่ คอมโพเนนต์ที่มีการเปิดใช้งาน

• [C-SR-5] ขอแนะนําอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สําหรับ คอมโพเนนต์พื้นที่ผู้ใช้ที่ละเอียดอ่อนต่อความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan

• [C-SR-6] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนล เพื่อป้องกันการใช้ตัวแปรภายในเครื่องที่ไม่ได้เริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคาดเดาค่าที่คอมไพเลอร์ใช้เพื่อ เริ่มต้นให้กับคนในท้องถิ่น

• [C-SR-7] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นฮีปในเคอร์เนล เพื่อป้องกันการใช้การจัดสรรฮีปแบบไม่เริ่มต้น (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) และไม่ควรคาดเดาค่าที่ใช้โดย เคอร์เนลเพื่อเริ่มต้นการจัดสรรเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลของ Linux ที่รองรับ SELinux

• [C-1-1] ต้องใช้ SELinux
• [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
• [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่มีโหมดอนุญาต โดเมนที่ได้รับอนุญาต ได้แก่ โดเมนเฉพาะสำหรับอุปกรณ์/ผู้ให้บริการ
• [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎที่ไม่อนุญาตในปัจจุบัน ภายในโฟลเดอร์ระบบ/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_SW_TAGS สำหรับอุปกรณ์ ARMv8 หรือ CONFIG_KASAN_GENERIC สำหรับอุปกรณ์ประเภทอื่น)
• [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

เทคโนโลยีความปลอดภัยของหน่วยความจำเป็นเทคโนโลยีที่ช่วยลดปัญหาต่อไปนี้เป็นอย่างน้อย คลาสของข้อบกพร่องที่มีความเป็นไปได้สูง (> 90%) ในแอปพลิเคชันที่ใช้ android:memtagMode ตัวเลือกไฟล์ Manifest

• ฮีปบัฟเฟอร์ล้น
• ใช้หลังจากฟรี
• ดับเบิลฟรี
• ปราศจาก (ไม่มีมัลแวร์)

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

• [C-SR-15] ขอแนะนำอย่างยิ่งให้ตั้งค่า ro.arm64.memtag.bootctl_supported

หากการติดตั้งใช้งานอุปกรณ์ตั้งค่าพร็อพเพอร์ตี้ระบบ ro.arm64.memtag.bootctl_supportedเป็นจริงโดยมีคุณสมบัติดังนี้

• [C-3-1] ต้องอนุญาตให้พร็อพเพอร์ตี้ของระบบ arm64.memtag.bootctl ยอมรับ รายการค่าต่อไปนี้ที่คั่นด้วยคอมมา โดยให้เอฟเฟกต์ที่ต้องการ ใช้กับการรีบูตครั้งถัดไปครั้งถัดไป

  • memtag: เปิดใช้เทคโนโลยีความปลอดภัยของหน่วยความจำตามที่ระบุไว้ข้างต้นแล้ว
  • memtag-once: เทคโนโลยีความปลอดภัยของหน่วยความจำตามที่ระบุไว้ข้างต้นคือ เปิดใช้ชั่วคราว และปิดใช้โดยอัตโนมัติเมื่อ ถัดไป รีบูต
  • memtag-off: มีการปิดใช้เทคโนโลยีความปลอดภัยของหน่วยความจำตามที่ระบุไว้ข้างต้น

• [C-3-2] ต้องอนุญาตให้ผู้ใช้ Shell ตั้งค่า arm64.memtag.bootctl

• [C-3-3] ต้องอนุญาตให้กระบวนการอ่าน arm64.memtag.bootctl ได้

• [C-3-4] ต้องตั้งค่า arm64.memtag.bootctl เป็นสถานะที่ร้องขอในปัจจุบัน เมื่อเปิดเครื่อง อุปกรณ์ต้องอัปเดตคุณสมบัติด้วย หากการติดตั้งอุปกรณ์ อนุญาตให้แก้ไขสถานะได้โดยไม่ต้องเปลี่ยนคุณสมบัติของระบบ

• [C-SR-16] ขอแนะนำอย่างยิ่งให้แสดง การตั้งค่าสำหรับนักพัฒนาซอฟต์แวร์ที่ memtag เพียงครั้งเดียวและรีบูตอุปกรณ์ ด้วย Bootloader ที่เข้ากันได้ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดข้างต้นผ่าน โปรโตคอล Bootloader ของ MTE

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

9.8 ความเป็นส่วนตัว

9.8.1 ประวัติการใช้งาน

Android จะจัดเก็บประวัติการเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

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

• [C-0-1] จะต้องมีระยะเวลาเก็บรักษาประวัติผู้ใช้อย่างสมเหตุสมผล
• [C-SR-1] แนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันไว้อย่าง โดยค่าเริ่มต้นในการใช้งาน AOSP

Android จัดเก็บเหตุการณ์ของระบบโดยใช้ StatsLog ตัวระบุ และจัดการประวัติดังกล่าวผ่านทาง StatsManager และ API ระบบ IncidentManager

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

• [C-0-2] ต้องรวมเฉพาะช่องที่มีเครื่องหมาย DEST_AUTOMATIC ใน รายงานเหตุการณ์ที่สร้างโดยคลาส API ของระบบ IncidentManager
• [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ มากกว่าที่อธิบายไว้ใน StatsLog เอกสาร SDK หากมีการบันทึกเหตุการณ์อื่นๆ ของระบบ เหตุการณ์ดังกล่าวอาจใช้ ตัวระบุอะตอมที่ต่างกันในช่วงระหว่าง 100,000 ถึง 200,000 ตัว

9.8.2 กำลังบันทึก

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

• [C-0-1] ต้องไม่โหลดหรือแจกจ่ายส่วนประกอบของซอฟต์แวร์ล่วงหน้า ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงใน หน้าจอและรายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้หรือล้างข้อมูล การแจ้งเตือนต่อเนื่อง

• [C-0-2] ต้องแสดงคำเตือนผู้ใช้และได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้ง การอนุญาตให้ข้อมูลที่ละเอียดอ่อนที่แสดงบนหน้าจอของผู้ใช้สามารถ ทุกครั้งที่บันทึกเซสชัน หน้าจอจะเริ่มต้นจาก MediaProjection.createVirtualDisplay() VirtualDeviceManager.createVirtualDisplay(), หรือ API ที่เป็นกรรมสิทธิ์

• [C-0-3] ต้องมีการแจ้งเตือนผู้ใช้อย่างต่อเนื่องในขณะที่ส่งหน้าจอ หรือบันทึกหน้าจออยู่ AOSP ปฏิบัติตามข้อกำหนดนี้โดยการแสดง ไอคอนการแจ้งเตือนต่อเนื่องในแถบสถานะ

• [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงคำเตือนแก่ผู้ใช้ ข้อความเดียวกับที่นำมาใช้ใน AOSP แต่ "สามารถ" เปลี่ยนแปลงได้ เตือนผู้ใช้อย่างชัดเจน ว่าข้อมูลที่ละเอียดอ่อนใดๆ ใน มีการจับภาพหน้าจอ

• [C-0-4] ต้องไม่ให้ค่าตอบแทนแก่ผู้ใช้ในการปิดข้อความแจ้งในอนาคต ผู้ใช้ยินยอมให้จับภาพหน้าจอ เว้นแต่เซสชันจะเริ่มต้นโดย แอประบบที่ผู้ใช้ได้อนุญาตให้ไว้ associate() พร้อมด้วย android.app.role.COMPANION_DEVICE_APP_STREAMING หรือ android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING โปรไฟล์อุปกรณ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง 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, หมายเลขซีเรียลของซิม และอุปกรณ์เคลื่อนที่ระหว่างประเทศ ข้อมูลประจําตัวผู้สมัครใช้บริการ (IMSI) จากแอป เว้นแต่จะเป็นไปตามข้อใดข้อหนึ่งต่อไปนี้ ข้อกำหนด
  • เป็นแอปของผู้ให้บริการที่ได้รับการรับรองและได้รับการยืนยันโดยผู้ผลิตอุปกรณ์
  • ได้รับสิทธิ์ READ_PRIVILEGED_PHONE_STATE แล้ว
  • มีสิทธิ์ของผู้ให้บริการตามที่ระบุไว้ในสิทธิ์ของผู้ให้บริการ UICC
  • เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับสิทธิ์ สิทธิ์READ_PHONE_STATE
  • (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดด้านกฎระเบียบท้องถิ่น ว่าแอปตรวจพบการเปลี่ยนแปลงในข้อมูลประจำตัวของสมาชิก

9.8.6 ระดับระบบปฏิบัติการและข้อมูลแอมเบียนท์

Android ผ่านทาง API ระบบ สนับสนุนกลไกสำหรับอุปกรณ์ ในการบันทึกข้อมูลที่ละเอียดอ่อนต่อไปนี้

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

• เหตุการณ์การป้อนข้อมูล (เช่น การกดแป้น เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)

• หน้าจอหรือข้อมูลอื่นๆ ที่ส่งผ่าน AugmentedAutofillService ไปยัง ระบบ

• หน้าจอหรือข้อมูลอื่นๆ ที่เข้าถึงได้ผ่านทาง Content Capture API

• ข้อมูลแอปพลิเคชันใดๆ ที่ส่งผ่านไปยังระบบผ่าน AppSearchManager API และเข้าถึงได้ผ่านทาง AppSearchGlobalManager.query

• ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่านTextClassifier API ลงใน System TextClassifier เช่น กับบริการของระบบ ความหมายของข้อความ รวมทั้งสร้างการดำเนินการ ที่คาดการณ์ไว้ตาม ข้อความ

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

• ข้อมูลเสียงที่ได้รับจากการใช้ SpeechRecognizer#onDeviceSpeechRecognizer() โดยโปรแกรมรู้จำคำพูด การใช้งาน

• ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) จนถึง AudioRecord SoundTrigger หรือ API เสียงอื่นๆ และไม่ได้แสดงผลให้ผู้ใช้เห็น ตัวบ่งชี้

• ข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ Camera API อื่นๆ และไม่แสดงสัญญาณบอกสถานะที่ผู้ใช้มองเห็นได้

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลใดๆ ข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้

• [C-1-1] ต้องเข้ารหัสข้อมูลทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ ช่วงเวลานี้ อาจดำเนินการโดยใช้การเข้ารหัสตามไฟล์ Android หรือ ของตัวเข้ารหัสที่แสดงเป็น API เวอร์ชัน 26 ขึ้นไปที่อธิบายไว้ใน Cipher SDK
• [C-1-2] ต้องไม่สำรองข้อมูลข้อมูลดิบหรือเข้ารหัสโดยใช้ วิธีการสำรองข้อมูล Android หรือวิธีการสำรองอื่นๆ ขึ้น
• [C-1-3] ต้องส่งข้อมูลดังกล่าวทั้งหมดออกจาก โดยใช้กลไกการรักษาความเป็นส่วนตัว ยกเว้น ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการใช้ข้อมูล แชร์ กลไกการรักษาความเป็นส่วนตัว คือ "รายการที่อนุญาตเฉพาะการวิเคราะห์แบบรวมและป้องกัน การจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้รับจากผู้ใช้แต่ละราย" เพื่อ ป้องกันไม่ให้ข้อมูลต่อผู้ใช้ถูกตรวจสอบย้อนกลับ (เช่น นำไปใช้งานโดยใช้ เทคโนโลยี Differential Privacy เช่น RAPPOR)
• [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น เป็น Account) ในอุปกรณ์ ยกเว้นกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ในแต่ละครั้ง ที่เกี่ยวข้อง
• [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่แชร์ข้อมูล ปฏิบัติตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.6 ระดับระบบปฏิบัติการและข้อมูลแวดล้อม) ยกเว้นได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้งทุก เวลาที่แชร์กัน เว้นแต่ฟังก์ชันการทำงานดังกล่าวจะเป็น สร้างเป็น Android SDK API (AmbientContext HotwordDetectionService)
• [C-1-6] ต้องให้เงินแก่ผู้ใช้ในการลบข้อมูลดังกล่าว การนำไปใช้หรือวิธีการอันเป็นกรรมสิทธิ์ที่เก็บรวบรวมเมื่อ ข้อมูลจะจัดเก็บอยู่ในรูปแบบใดก็ได้ในอุปกรณ์ หาก ผู้ใช้เลือกที่จะลบข้อมูล ต้องนำประวัติที่รวบรวมไว้ออกทั้งหมด

• [C-1-7] ต้องให้ค่าตอบแทนแก่ผู้ใช้ในการเลือกไม่ให้ความยินยอม ผ่าน AppSearch หรือวิธีการที่เป็นกรรมสิทธิ์เพื่อไม่ให้แสดงในแพลตฟอร์ม Android (เช่น Launcher)

• [C-SR-1] แนะนำอย่างยิ่งไม่ให้ขอสิทธิ์อินเทอร์เน็ต

• [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้เข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างที่ได้รับการสนับสนุนโดยการใช้งานโอเพนซอร์สที่พร้อมใช้งานแบบสาธารณะ

• [C-SR-4] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานด้วย Android SDK API หรือ ที่เก็บแบบโอเพนซอร์สซึ่งเป็นเจ้าของโดย OEM ที่คล้ายกัน และ / หรือดำเนินการใน การใช้งานแซนด์บ็อกซ์ (ดูการใช้งาน Sandboxed API เวอร์ชัน 9.8.15)

หากการใช้งานอุปกรณ์รวมถึงบริการที่ใช้ 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 ระบบ และสื่อ

9.8.7 การเข้าถึงคลิปบอร์ด

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

• [C-0-1] ต้องไม่ส่งคืนข้อมูลที่ถูกตัดจากคลิปบอร์ด (เช่น จาก ClipboardManager API) เว้นแต่บุคคลที่สาม เป็น IME เริ่มต้นหรือเป็นแอปที่โฟกัสอยู่

• [C-0-2] ต้องล้างข้อมูลคลิปบอร์ดภายในไม่เกิน 60 นาทีหลังจากดำเนินการล่าสุด ไว้ในคลิปบอร์ดหรืออ่านจากคลิปบอร์ด

9.8.8 ตำแหน่ง

ตำแหน่งมีข้อมูลในคลาสตำแหน่งของ Android( เช่น Latitude, ลองจิจูด ระดับความสูง) รวมถึงตัวระบุที่แปลงเป็นตำแหน่งได้ ตำแหน่งนั้นละเอียดพอๆ กับ DGPS (Differential Global Positioning System) หรือ คร่าวๆ เป็นสถานที่ตั้งระดับประเทศ (เช่น สถานที่ตั้งที่ใช้รหัสประเทศ - MCC - อุปกรณ์เคลื่อนที่ รหัสประเทศ)

ต่อไปนี้เป็นรายการของประเภทสถานที่ตั้งที่ได้จากผู้ใช้โดยตรง สถานที่ตั้งนี้ หรือแปลงเป็นสถานที่ตั้งของผู้ใช้ได้ การตั้งค่าเหล่านี้ไม่ได้ครอบคลุม แต่ควรใช้เป็นตัวอย่างว่า "สถานที่ตั้ง" สามารถ ได้ทางอ้อมจาก:

• GPS/GNSS/DGPS/PPP
  • โซลูชันตำแหน่งทั่วโลก หรือระบบดาวเทียมนำทางทั่วโลกหรือ โซลูชันการวางตำแหน่งโลกที่แตกต่างกัน
  • ซึ่งรวมถึงการวัด 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.setLocationSettings ignored()] เป็นเหตุฉุกเฉินที่ผู้ใช้เป็นผู้เริ่ม (เช่น กดหมายเลข 911 หรือส่งข้อความถึง 911) แต่สำหรับยานยนต์ ยานพาหนะอาจ เริ่มเซสชันฉุกเฉินโดยไม่มีการโต้ตอบของผู้ใช้ที่ใช้งานอยู่ในกรณี ตรวจพบอุบัติเหตุรถชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนด eCall)
• [C-0-4] ต้องรักษาความสามารถของ API การข้ามตำแหน่งในกรณีฉุกเฉินไว้ ข้ามการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่เปลี่ยนการตั้งค่า
• [C-0-5] ต้องตั้งเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากใช้แอปใน พื้นหลังได้เข้าถึงตำแหน่งโดยใช้ [ACCESS_BACKGROUND_LOCATION]

9.8.9 แอปที่ติดตั้ง

แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับ แอปที่ติดตั้งโดยค่าเริ่มต้น (โปรดดูการแสดงแพ็กเกจใน Android เอกสาร SDK)

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

• [C-0-1] ต้องไม่แสดงรายละเอียดแอปที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป แอปอื่นๆ ที่ติดตั้งไว้แล้ว ยกเว้นแอปนั้นจะดูรายละเอียดได้ เกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ผ่าน API ที่มีการจัดการ ซึ่งรวมถึง แต่ ไม่จำกัดเฉพาะรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งเพิ่มโดยอุปกรณ์ ใหม่ หรือเข้าถึงได้ผ่านระบบไฟล์
• [C-0-2] ต้องไม่ให้สิทธิ์อ่านหรือเขียนไฟล์ใน ไดเรกทอรีสำหรับแอปโดยเฉพาะของแอป ภายในที่จัดเก็บข้อมูลภายนอก โดยมีข้อยกเว้นดังนี้
  • สิทธิ์ของผู้ให้บริการพื้นที่เก็บข้อมูลภายนอก (เช่น แอปอย่าง DocumentsUI)
  • ผู้ให้บริการดาวน์โหลดที่ใช้ "ดาวน์โหลด" อำนาจผู้ให้บริการสำหรับ การดาวน์โหลดไฟล์ไปยังพื้นที่เก็บข้อมูลของแอป
  • แอป Media Transfer Protocol (MTP) ที่ลงนามในแพลตฟอร์มซึ่งใช้ สิทธิ์ที่เป็นสิทธิ์ ACCESS_MTP เพื่อเปิดใช้การถ่ายโอนไฟล์ อุปกรณ์อื่น
  • แอปที่ติดตั้งแอปอื่นๆ และมีสิทธิ์ แพ็กเกจการติดตั้ง เข้าถึงได้เฉพาะ "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 ของแพ็กเกจการโทร (หากมีขอบเขต)
  • บัฟเฟอร์บันทึกวิทยุ
  • ดัมพ์ SubscriptionManagerService
• [C-1-5] ต้องไม่มีข้อมูลต่อไปนี้ในรายงานที่สร้างขึ้น
  • ข้อมูลที่ไม่เกี่ยวข้องกับการเชื่อมต่อโดยตรง การแก้ไขข้อบกพร่อง
  • บันทึกการรับส่งข้อมูลของแอปพลิเคชันหรือโปรไฟล์โดยละเอียดที่ติดตั้งโดยผู้ใช้ทุกประเภท ของแอปพลิเคชัน/แพ็กเกจที่ผู้ใช้ติดตั้ง (UID ได้ สำหรับชื่อแพ็กเกจคือ ไม่ได้)
• อาจมีข้อมูลเพิ่มเติมที่ไม่ได้เชื่อมโยงกับผู้ใช้ ตัวตน (เช่น บันทึกของผู้ให้บริการ)

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

• [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้กำหนดการตั้งค่าเริ่มต้นสำหรับนักพัฒนาซอฟต์แวร์เป็น ปิดใช้อยู่ การใช้ข้อมูลอ้างอิง AOSP จะเป็นไปตามนี้โดยการระบุ Enable verbose vendor logging ในการตั้งค่าสำหรับนักพัฒนาซอฟต์แวร์เพื่อรวมบันทึกของผู้ให้บริการเฉพาะอุปกรณ์เพิ่มเติม ในรายงานข้อบกพร่อง

9.8.11 การแชร์ข้อมูล BLOB

Android ผ่าน BlobStoreManager อนุญาตให้แอปร่วมให้ข้อมูล BLOB ไปยังระบบเพื่อแชร์ BLOB ที่เลือกได้ ชุดของแอป

หากการใช้งานอุปกรณ์รองรับ Blob ของข้อมูลที่แชร์ตามที่อธิบายไว้ใน เอกสารประกอบเกี่ยวกับ SDK ดังนี้

• [C-1-1] ต้องไม่แชร์ BLOB ที่เป็นของแอปนอกเหนือไปจากสิ่งที่ ที่มีเจตนาอนุญาต (นั่นคือ ขอบเขตของการเข้าถึงเริ่มต้นและการเข้าถึงอื่นๆ โหมดที่สามารถระบุโดยใช้ BlobStoreManager.session#allowPackageAccess() BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreManager.session#allowPublicAccess() ต้องไม่มีการแก้ไข) การใช้ข้อมูลอ้างอิง AOSP จะเป็นไปตาม
• [C-1-2] ต้องไม่ส่งแฮชที่ปลอดภัยในอุปกรณ์หรือแชร์กับแอปอื่นๆ 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] ต้องแสดงผล "จริง" อย่างถูกต้อง สำหรับข้อมูลที่เกี่ยวข้อง supportsensorToggle() เมธอดของ API
• [C-1-2] ต้องเมื่อแอปพยายามเข้าถึงไมโครโฟนหรือกล้องที่ถูกบล็อก ทำให้ผู้ใช้ไม่สามารถปิดได้ บ่งบอกว่าเซ็นเซอร์ถูกบล็อกและต้องเลือกเพื่อดำเนินการต่อ การบล็อกหรือเลิกบล็อกตามการใช้งาน AOSP ซึ่งเป็นไปตามนี้ ข้อกำหนดในการให้บริการ
• [C-1-3] ต้องส่งข้อมูลกล้องและเสียงที่ว่างเปล่า (หรือปลอม) ไปยังแอปเท่านั้น และไม่รายงานรหัสข้อผิดพลาดเนื่องจากผู้ใช้ไม่ได้เปิดกล้อง หรือไมโครโฟนผ่านงบของผู้ใช้ตาม [C-1-2] ข้างต้น

9.8.14 ไม่มี

9.8.15 การใช้งาน API ที่แซนด์บ็อกซ์

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

การใช้ Sandboxed API

• [C-0-1] ต้องไม่ขอสิทธิ์อินเทอร์เน็ต
• [C-0-2] ต้องเข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างซึ่งสนับสนุนโดย การใช้งานโอเพนซอร์สที่พร้อมใช้งานแบบสาธารณะโดยใช้การรักษาความเป็นส่วนตัว หรือโดยอ้อมผ่านทาง API ของ Android SDK การรักษาความเป็นส่วนตัว คือ "รายการที่อนุญาตให้ใช้การวิเคราะห์แบบรวมและ ป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละราย", เพื่อป้องกันไม่ให้ข้อมูลต่อผู้ใช้สามารถตรวจสอบย้อนกลับได้ (เช่น ใช้งานโดยใช้ เทคโนโลยี Differential Privacy เช่น RAPPOR)
• [C-0-3] ต้องแยกบริการออกจากองค์ประกอบอื่นๆ ของระบบ (เช่น ไม่มีการเชื่อมโยงรหัสบริการหรือรหัสกระบวนการแชร์) ยกเว้น ดังต่อไปนี้:
  • โทรศัพท์, รายชื่อติดต่อ, UI ระบบ และสื่อ
• [C-0-4] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการด้วย แอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้
• [C-0-5] ต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าบันทึกข้อมูลดังกล่าว เว้นแต่ความสามารถในการเปลี่ยนทดแทนจะมีอยู่ใน AOSP (เช่น สำหรับสื่อดิจิทัล) แอป Assistant)
• [C-0-6] ต้องไม่อนุญาตแอปอื่นใดนอกจากบริการที่ติดตั้งไว้ล่วงหน้า ที่จะสามารถเก็บข้อมูลดังกล่าว ยกเว้นความสามารถในการจับภาพดังกล่าว จะใช้ร่วมกับ Android SDK API
• [C-0-7] ต้องให้ค่าตอบแทนแก่ผู้ใช้ในการปิดใช้บริการ
• [C-0-8] ต้องไม่ยกเว้นพื้นที่ของผู้ใช้ในการจัดการสิทธิ์ของ Android ที่ ให้บริการและเป็นไปตามรูปแบบสิทธิ์ของ Android อธิบายไว้ใน ส่วนที่ 9.1 สิทธิ์

9.8.16 ข้อมูลเสียงและกล้องแบบต่อเนื่อง

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-0-1] ต้องใช้สัญญาณบอกสถานะที่สอดคล้องกัน (กล้องและ/หรือไมโครโฟนตาม ตามส่วนที่ 9.8.2 การบันทึก) ยกเว้นในกรณีต่อไปนี้
  • การเข้าถึงนี้เกิดขึ้นจากการใช้งานแซนด์บ็อกซ์ (ดู 9.8.15 การใช้งาน Sandboxed API) ผ่านแพ็กเกจที่มีแพ็กเกจหรือ อื่นๆ ในบทบาทต่อไปนี้ System UI Intelligence System Ambient Audio Intelligence System Audio Intelligence ระบบการแจ้งเตือนอัจฉริยะ System Text Intelligence หรือ System Visual Intelligence
  • การเข้าถึงนี้ดำเนินการผ่านแซนด์บ็อกซ์ มีการใช้งาน และ บังคับใช้ผ่านกลไกใน AOSP (HotwordDetectionService WearableSensingService, VisualQueryDetector)
  • การเข้าถึงเสียงดำเนินการเพื่อวัตถุประสงค์ในการอำนวยความสะดวกโดย Digital แอปพลิเคชัน Assistant ซึ่งให้ SOURCE_HOTWORD เป็นแหล่งที่มาของเสียง
  • การเข้าถึงจะดำเนินการโดยระบบ และปรับใช้กับ ซึ่งเป็นโค้ดโอเพนซอร์ส
• [C-SR-1] แนะนำอย่างยิ่งให้ต้องได้รับความยินยอมจากผู้ใช้ในทุก และปิดใช้โดยค่าเริ่มต้น
• [C-SR-2] แนะนำอย่างยิ่งให้ใช้การรักษาแบบเดียวกัน (เช่น ทำตาม ข้อจำกัดที่ระบุไว้ใน 9.8.2 การบันทึก, 9.8.6 ระดับระบบปฏิบัติการและข้อมูลแอมเบียนท์ 9.8.15 การใช้ Sandboxed API และ 9.8.16 เสียงและกล้องอย่างต่อเนื่อง ข้อมูล) ไปยังข้อมูลกล้องที่มาจากอุปกรณ์ที่สวมใส่ได้ระยะไกล

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-1-1] ต้องระบุให้กับอุปกรณ์ที่สวมใส่ได้ระยะไกลเพื่อ จะแสดงตัวบ่งชี้เพิ่มเติมที่นั่น

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

• [C-2-1] ต้องตรวจสอบว่าการติดตั้งใช้งานดังกล่าวมาจากแพ็กเกจที่ถือ บทบาทandroid.app.role.ASSISTANT
• [C-2-2] ต้องตรวจสอบว่าการติดตั้งใช้งานดังกล่าวใช้ HotwordDetectionService และ/หรือ Android API VisualQueryDetectionService รายการ

9.8.17 Telemetry

Android จัดเก็บบันทึกของระบบและแอปโดยใช้ StatsLog API บันทึกเหล่านี้ได้รับการจัดการ ผ่าน ReportingManager API ซึ่งแอปพลิเคชันระบบที่ได้รับสิทธิ์ใช้งานได้

Analytics ยังมอบวิธีเก็บรวบรวมข้อมูลที่จัดหมวดหมู่เป็นความเป็นส่วนตัวด้วย ที่ละเอียดอ่อนจากอุปกรณ์ที่มีกลไกการรักษาความเป็นส่วนตัว โดยเฉพาะอย่างยิ่ง StatsManager::query API มอบความสามารถในการค้นหาเมตริกที่ถูกจำกัด กำหนดหมวดหมู่แล้ว ใน StatsLog

การค้นหาการติดตั้งใช้งานและการรวบรวมเมตริกที่ถูกจำกัดจาก เครื่องมือจัดการสถิติ:

• [C-0-1] ต้องเป็นแอปพลิเคชัน/การติดตั้งใช้งานเพียงอย่างเดียวในอุปกรณ์และ สิทธิ์ READ_RESTRICTED_STATS
• [C-0-2] ต้องส่งเฉพาะข้อมูลทางไกลและบันทึกของอุปกรณ์โดยใช้ กลไกการรักษาความเป็นส่วนตัว เรากำหนดกลไกการรักษาความเป็นส่วนตัว "ซึ่งอนุญาตให้วิเคราะห์ได้เฉพาะแบบรวมและป้องกันการจับคู่ เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้รับจากผู้ใช้แต่ละราย" เพื่อป้องกัน ข้อมูลต่อผู้ใช้ที่สามารถดูก่อนได้ (เช่น ใช้งานโดยใช้ Differential เทคโนโลยีด้านความเป็นส่วนตัว เช่น RAPPOR)
• [C-0-3] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น บัญชี) ในอุปกรณ์
• [C-0-4] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์ระบบปฏิบัติการอื่นๆ ที่ไม่เป็นไปตามข้อกำหนด ข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.17 การรักษาความเป็นส่วนตัว การตรวจวัดระยะไกล)
• [C-0-5] ต้องให้เงินแก่ผู้ใช้ในการเปิด/ปิดใช้การรักษาความเป็นส่วนตัว การรวบรวม การใช้ และการแชร์การวัดและส่งข้อมูลทางไกล
• [C-0-6] ต้องให้ค่าตอบแทนแก่ผู้ใช้ในการลบข้อมูลที่ ของ Google จะรวบรวมหากมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์ ถ้า ผู้ใช้เลือกที่จะลบข้อมูล ต้องนำข้อมูลทั้งหมดที่จัดเก็บอยู่ในปัจจุบันออก อุปกรณ์
• [C-0-7] ต้องเปิดเผยการใช้โปรโตคอลการรักษาความเป็นส่วนตัวที่เกี่ยวข้อง ในที่เก็บแบบโอเพนซอร์ส
• [C-0-8 ]ต้องบังคับใช้นโยบายข้อมูลขาออกในส่วนนี้เพื่อเข้าเก็บข้อมูล ของข้อมูลในหมวดหมู่เมตริกที่จำกัดที่กำหนด ใน StatsLog

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 โหมดการเปิดเครื่องโดยตรง แม้ว่า จะไม่รองรับการเข้ารหัส Storage

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED Intent ต้องยังคงออกอากาศอยู่เพื่อส่งสัญญาณแจ้งแอปพลิเคชัน Direct Boot ที่ตระหนักถึง ตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) คือ พร้อมใช้งานสำหรับผู้ใช้

9.9.2 ข้อกำหนดการเข้ารหัส

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

• [C-0-1] ต้องเข้ารหัสแอปพลิเคชันให้เป็นส่วนตัว ข้อมูล (พาร์ติชัน /data) ตลอดจนพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรและถอดออกไม่ได้
• [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้น ผู้ใช้ได้ดำเนินการติดตั้งเสร็จแล้ว

• [C-0-3] ต้องเป็นไปตามการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้น ด้วยการใช้วิธีการเข้ารหัสวิธีใดวิธีหนึ่งต่อไปนี้

  • การเข้ารหัสตามไฟล์ (FBE) และ การเข้ารหัสข้อมูลเมตา ตามที่อธิบายไว้ในส่วนที่ 9.9.3.1
  • การเข้ารหัสระดับการบล็อกต่อผู้ใช้ตามที่อธิบายไว้ในส่วนที่ 9.9.3.2

9.9.3 วิธีการเข้ารหัส

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

• [C-1-1] ต้องเปิดเครื่องโดยไม่สอบถามผู้ใช้เกี่ยวกับข้อมูลรับรอง และ อนุญาตให้แอปที่รับรู้การเปิดเครื่องโดยตรงเข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสของอุปกรณ์ (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, AES-256-HCTR2, หรือ Adiantum
• [C-1-12] หากอุปกรณ์มีมาตรฐานการเข้ารหัสขั้นสูง (AES) วิธีการ (เช่น ส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ 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 ฟีเจอร์การเข้ารหัส และของการเข้ารหัสข้อมูลเมตาตามเคอร์เนลของ Linux "dm-default-key"

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] ต้องเชื่อมโยงกับหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง ข้อมูลเข้าสู่ระบบ

การเข้ารหัสระดับการบล็อกต่อผู้ใช้สามารถนำมาใช้ได้โดยใช้เคอร์เนลของ Linux "dm-crypt" แทนพาร์ติชันต่อผู้ใช้

9.9.4 ดำเนินการต่อเมื่อรีบูต

"กลับมาทำงานอีกครั้งเมื่อรีบูต" ช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมด รวมถึงแอปเหล่านั้นได้ ที่ยังไม่รองรับ Direct Boot หลังจากการรีบูตที่เริ่มต้นโดย OTA ช่วงเวลานี้ ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งหลังจาก รีบูต

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

ดังนี้

• [C-0-1] พื้นที่เก็บข้อมูล CE ต้องไม่อ่านได้ แม้แต่ในกรณีที่ผู้โจมตี อุปกรณ์ จากนั้นมีความสามารถและข้อจำกัดต่อไปนี้

  • ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามตามอำเภอใจ ข้อความ
  • อาจทำให้อุปกรณ์รับ OTA ได้
  • สามารถแก้ไขการทำงานของฮาร์ดแวร์ (AP, Flash ฯลฯ) ยกเว้น ด้านล่างนี้ แต่การแก้ไขดังกล่าวเกี่ยวข้องกับความล่าช้าอย่างน้อย และรอบการทำงานที่ทำลายเนื้อหา RAM
  • ไม่สามารถแก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการงัดแงะ (เช่น Titan M)
  • ไม่สามารถอ่าน RAM ของอุปกรณ์ที่กำลังใช้งานอยู่
  • ไม่สามารถรับข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือ มิฉะนั้นระบบจะป้อน URL

ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่มีการใช้งานและเป็นไปตาม ของคำอธิบายที่พบที่นี่ จะเป็นไปตาม [C-0-1]

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

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

• [C-0-1] ต้องรายงานผ่านเมธอด System API อย่างถูกต้อง PersistentDataBlockManager.getFlashLockState() ไม่ว่าจะเป็น Bootloader สถานะอนุญาตให้กะพริบอิมเมจของระบบ

• [C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

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

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

• [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม 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-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่มีการปลอมแปลง: สำหรับการจัดเก็บว่า มีการปลดล็อก Bootloader พื้นที่เก็บข้อมูลที่มีการงัดแงะหมายความว่า Bootloader สามารถ ตรวจจับว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
• [C-1-9] ต้องแจ้งผู้ใช้ขณะใช้อุปกรณ์ และ ต้องมีการยืนยันทางกายภาพก่อนอนุญาตให้เปลี่ยนจาก Bootloader เป็นโหมดปลดล็อก Bootloader
• [C-1-10] ต้องใช้การป้องกันย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น การเปิดเครื่อง พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะเพื่อจัดเก็บ ข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
• [C-1-11] ต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยในระหว่างการปลดล็อก Bootloader และ ตาม "9.12" การลบข้อมูล (รวมถึงพาร์ติชันข้อมูลผู้ใช้และ พื้นที่ว่าง NVRAM)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่ได้รับสิทธิ์ทั้งหมดที่มี ห่วงโซ่ความน่าเชื่อถือที่รูทในพาร์ติชันที่มีการป้องกันด้วยการเปิดเครื่องที่ได้รับการยืนยัน
• [C-SR-3] ขอแนะนำอย่างยิ่งให้ตรวจสอบอาร์ติแฟกต์ปฏิบัติการใดๆ ที่โหลดโดย แอปที่ได้รับสิทธิ์จากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิก หรือ คอมไพล์โค้ด) ก่อนปฏิบัติการหรือขอแนะนำว่าอย่าเรียกใช้โค้ด เลย
• ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มี เฟิร์มแวร์ (เช่น โมเด็ม กล้อง) และควรใช้ที่เก็บข้อมูลที่มีการตรวจหาการงัดแงะสำหรับ จัดเก็บข้อมูลเมตาที่ใช้เพื่อกำหนดเวอร์ชันขั้นต่ำที่อนุญาต

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

โปรเจ็กต์โอเพนซอร์ส Android ที่แนะนําการใช้งาน ฟีเจอร์นี้ในexternal/avb/ ที่เก็บ ซึ่งสามารถผสานรวมเข้ากับ Bootloader ที่ใช้สำหรับการโหลด Android

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

• [C-2-1] รองรับการยืนยันเนื้อหาไฟล์แบบเข้ารหัสโดยไม่ต้องอ่าน ทั้งไฟล์

• [C-2-2] ต้องไม่อนุญาต คำขออ่านในไฟล์ที่มีการป้องกันจะสำเร็จเมื่อเนื้อหาที่อ่านแล้วไม่ ได้รับการยืนยันตาม [C-2-1] ข้างต้น

• [C-2-4] ต้องส่งคืน checksum ของไฟล์ใน O(1) สำหรับไฟล์ที่เปิดใช้งาน

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

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

9.11 คีย์และข้อมูลเข้าสู่ระบบ

ระบบ Android Keystore ช่วยให้นักพัฒนาแอปสามารถจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์และนำไปใช้ใน การดำเนินการเข้ารหัสผ่าน 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, SHA-1 และ SHA-2 ทำงานอย่างเหมาะสมเพื่อรองรับระบบ Android Keystore อัลกอริทึมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัย เคอร์เนลขึ้นไป การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมด โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของ สภาพแวดล้อมที่แยกจากกัน ซึ่งรวมถึง DMA โอเพนซอร์ส Android แบบโอเพนซอร์ส โปรเจ็กต์ (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้ แบบ Trusty แต่ โซลูชันอื่นที่ใช้ ARM TrustZone หรือโซลูชันที่ปลอดภัยโดยบุคคลที่สามที่ได้รับการตรวจสอบ การนำการแยกโดยใช้ไฮเปอร์ไวเซอร์ที่เหมาะสมมาใช้เป็นทางเลือก ตัวเลือก
• [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในการแยก สภาพแวดล้อมการดำเนินการและเฉพาะเมื่อสำเร็จ คีย์ที่จะใช้ ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกต้องจัดเก็บไว้ใน ซึ่งอนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากทำงานในหน้าจอล็อก การตรวจสอบสิทธิ์ โปรเจ็กต์โอเพนซอร์ส Android มอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้ ตามข้อกำหนดนี้ได้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

• [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปเพื่อเปลี่ยนจาก ปลดล็อกเป็นสถานะล็อกอยู่ โดยมีระยะหมดเวลาขั้นต่ำที่อนุญาตสูงสุด 15 วินาที อุปกรณ์ยานยนต์ ซึ่งจะล็อกหน้าจอเมื่อมีเครื่องเล่นวิทยุ ปิดอยู่หรือมีการสลับผู้ใช้ อาจไม่มีระยะหมดเวลาสลีป การกำหนดค่า
• [C-1-6] ต้องรองรับสิ่งใดสิ่งหนึ่งต่อไปนี้
  • IKeymasterDevice 3.0
  • IKeymasterDevice 4.0
  • IKeymasterDevice 4.1
  • IKeyMintDevice เวอร์ชัน 1 หรือ
  • IKeyMintDevice เวอร์ชัน 2
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ IKeyMintDevice เวอร์ชัน 1

9.11.1 หน้าจอล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือน

การใช้งาน AOSP เป็นไปตามโมเดลการตรวจสอบสิทธิ์แบบเป็นขั้นโดยที่ การตรวจสอบสิทธิ์หลักที่อิงตามความรู้จากโรงงานสามารถรับการสนับสนุนโดยใช้ ข้อมูลไบโอเมตริกระดับที่ 2 หรือผ่านรูปแบบที่ 3 ที่อ่อนแอกว่า

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

• [C-SR-1] แนะนำอย่างยิ่งให้ตั้งค่าหนึ่งในรายการต่อไปนี้เป็นการตรวจสอบสิทธิ์หลัก วิธีการ:

  • PIN ที่เป็นตัวเลข
  • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน

  • รูปแบบการปัดในตารางกริดที่มีจุด 3x3 พอดี

    โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีที่แนะนำ วิธีการตรวจสอบสิทธิ์หลักในเอกสารนี้

• [C-0-1] ต้องจำกัดจำนวนความพยายามในการตรวจสอบสิทธิ์หลักที่ล้มเหลว

• [C-SR-5] ได้รับการแนะนำอย่างยิ่งให้ใช้ขอบเขตบนของ 20 ไม่สำเร็จ การตรวจสอบสิทธิ์หลัก และหากผู้ใช้ยินยอมและเลือกใช้ฟีเจอร์ ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" หลังจากมีขั้นตอนหลักที่ล้มเหลวเกินจำนวนครั้งที่กำหนด ความพยายามในการตรวจสอบสิทธิ์

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

• [C-SR-6] เราขอแนะนำอย่างยิ่งให้ป้อน PIN อย่างน้อย 6 หลัก หรือ เทียบเท่ากับเอนโทรปี 20 บิต
• [C-SR-7] ขอแนะนำว่าอย่าป้อน PIN ที่มีความยาวน้อยกว่า 6 หลัก อนุญาตการป้อนข้อความอัตโนมัติโดยไม่ต้องมีการโต้ตอบของผู้ใช้เพื่อไม่เปิดเผย PIN

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

• [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน ต้องใช้การตรวจสอบสิทธิ์ผู้ใช้สำหรับการใช้งานคีย์

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

• [C-3-1] เอนโทรปีของความยาวที่สั้นที่สุดของข้อมูลอินพุตต้องเป็น มากกว่า 10 บิต
• [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
• [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่จะต้องไม่แทนที่ วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) นำไปใช้และให้บริการใน AOSP
• [C-3-4] วิธีการตรวจสอบสิทธิ์ใหม่ต้องถูกปิดใช้งานเมื่อ แอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ได้ตั้งค่ารหัสผ่านแล้ว นโยบายข้อกำหนดผ่าน DevicePolicyManager.setrequiredPasswordComplexity() มีความซับซ้อนและเข้มงวดมากกว่า Password_COMPLEXITY_NONE หรือผ่าน DevicePolicyManager.setPasswordquality() ที่มีความจำกัดมากกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
• [C-3-5] วิธีการตรวจสอบสิทธิ์แบบใหม่ต้องกลับไปใช้ วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (ได้แก่ PIN, รูปแบบ, ) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยต่อ ว่าระบบจะไม่สำรองข้อมูลบางอย่างเพื่อเก็บรักษา ความเป็นส่วนตัวของข้อมูล

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

• [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วน 7.3.10 สำหรับคลาส 1 (เดิมคือ ความสะดวก)
• [C-4-2] ต้องมีกลไกสำรองเพื่อใช้หนึ่งใน วิธีการตรวจสอบสิทธิ์หลักซึ่งอิงตามข้อมูลลับที่ทราบ
• [C-4-3] ต้องปิดใช้และอนุญาตเฉพาะ การตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอเมื่อตัวควบคุมนโยบายด้านอุปกรณ์ (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] ต้องปิดใช้วิธีการใหม่ และอนุญาตเฉพาะ วิธีการตรวจสอบสิทธิ์หลักที่แนะนำในการปลดล็อกหน้าจอเมื่อ แอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (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 หรือ อุปกรณ์ยานยนต์)
• [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
• [C-7-5] ต้องไม่เก็บคีย์การเข้ารหัสหรือโทเค็นเอสโครว์ไว้ อุปกรณ์เดียวกันกับที่ใช้คีย์ ตัวอย่างเช่น ได้รับอนุญาตให้ คีย์ที่จัดเก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้บนทีวี ไม่อนุญาตให้จัดเก็บโทเค็นเอสโครว์สำหรับอุปกรณ์ยานยนต์ บนส่วนใดก็ได้ของยานพาหนะ
• [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อน เปิดใช้งานโทเค็นเอสโครว์เพื่อถอดรหัสที่เก็บข้อมูล
• [C-7-7] ต้องมีกลไกสำรองเพื่อใช้ วิธีการตรวจสอบสิทธิ์หลัก
• [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] ต้องปิดใช้วิธีการใหม่เมื่อเครื่องมือควบคุมนโยบายด้านอุปกรณ์ แอปพลิเคชัน (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] ต้องมีอินสแตนซ์อุปกรณ์เสมือนแยกกันต่อผู้ใช้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึง การป้อนปัจจัยความรู้และพรอมต์ข้อมูลไบโอเมตริก

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

• [C-10-13] ต้องไม่ใช้สถานะล็อกอุปกรณ์เสมือนเป็นการตรวจสอบสิทธิ์ผู้ใช้ ด้วยระบบ Android Keystore โปรดดู KeyGenParameterSpec.Builder.setUserAuthentication*

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

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

• [C-11-1] ต้องเข้ารหัสปัจจัยความรู้ที่มีการรับประกันการปกป้องที่คล้ายกับ ตามที่อธิบายไว้ใน บริการ Google Cloud Key ห้องนิรภัย เอกสารด้านความปลอดภัยเมื่อโอน แหล่งที่มาของความรู้จากอุปกรณ์ต้นทาง ไปยังอุปกรณ์เป้าหมาย เพื่อให้ ปัจจัยความรู้ไม่สามารถถอดรหัสหรือใช้ในการปลดล็อกจากระยะไกลได้ อุปกรณ์ใดอุปกรณ์หนึ่ง
• [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 ชั่วโมง หรือ
  • หากการติดตั้งใช้งานไม่ได้ใช้ความปลอดภัยแบบเข้ารหัสลับและ ระยะที่แม่นยำตามที่กำหนดไว้ใน [C-12-5] เมื่อการเชื่อมต่อเบื้องหลัง กับอุปกรณ์จริงที่พร็อกซิมิตีสูญหาย
• [C-12-5] การใช้งานที่อาศัยระยะที่ปลอดภัยและถูกต้องเพื่อให้สอดคล้องกับ ข้อกำหนดของ [C-12-4] ต้องใช้โซลูชันใดโซลูชันหนึ่งต่อไปนี้
  • การติดตั้งใช้งานโดยใช้ UWB
    • ต้องเป็นไปตามข้อกำหนด การรับรอง ความถูกต้อง ข้อกำหนดการเทียบมาตรฐาน สำหรับ UWB ตามที่อธิบายไว้ใน 7.4.9
    • ต้องใช้โหมดความปลอดภัย P-STS โหมดใดโหมดหนึ่งที่ระบุไว้ใน 7.4.9
  • การติดตั้งใช้งานโดยใช้ Wi-Fi Neighborhood Networking (NAN)
    • ต้องเป็นไปตามข้อกำหนดเกี่ยวกับความถูกต้องใน 2.2.1 [7.4.2.5/H-SR-1] ใช้แบนด์วิดท์ 160 MHz (หรือ สูงกว่า) และทำตามขั้นตอนการตั้งค่าการวัดผลที่ระบุไว้ใน การปรับเทียบสถานที่ตั้ง
    • ต้องใช้ LTF ที่ปลอดภัยตามที่ระบุไว้ใน IEEE 802.11az

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

• [C-13-8] ต้องบล็อก activities ด้วยแอตทริบิวต์ android:canDisplayOnRemoteDevices หรือข้อมูลเมตา android.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น false เพื่อไม่ให้เริ่มทำงานในอุปกรณ์เสมือนจริง อุปกรณ์

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

หากการติดตั้งใช้งานอุปกรณ์รองรับสถานะกำลังแสดงผลแยกต่างหากโดยใช้ DeviceStateManager และรองรับสถานะการล็อกจอแสดงผลแยกต่างหากผ่าน KeyguardDisplayManager กล่าวคือ

• [C-SR-2] แนะนำอย่างยิ่งให้ใช้การประชุมเพื่อรับรอง ข้อกำหนดที่ระบุไว้ในส่วนที่ 9.11.1 หรือการประชุมด้วยข้อมูลไบโอเมตริกเป็นอย่างต่ำ ข้อกำหนดจำเพาะคลาส 1 ที่กำหนดไว้ในข้อ 7.3.10 เพื่อให้การอนุญาต จากหน้าจออุปกรณ์เริ่มต้น
• [C-SR-3] ขอแนะนำอย่างยิ่งให้จำกัดการปลดล็อกหน้าจอแยกต่างหาก ผ่านระยะหมดเวลาการแสดงผลที่กำหนดไว้
• [C-SR-4] แนะนำอย่างยิ่งเพื่ออนุญาตให้ผู้ใช้ล็อกจอแสดงผลทั้งหมดทั่วโลก ผ่านการปิดล็อกจากอุปกรณ์พกพาหลัก

9.11.2 StrongBox

ระบบคีย์สโตร์ของ Android ช่วยให้ เพื่อให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในตัวประมวลผลที่ปลอดภัยโดยเฉพาะ รวมทั้งสภาพแวดล้อมการดำเนินการที่แยกต่างหากตามที่อธิบายไว้ข้างต้น เช่น ตัวประมวลผลที่ปลอดภัยเฉพาะเรียกว่า "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 และโปรเซสเซอร์ร่วม หรือทรัพยากรหลักอื่นๆ ด้วย Application Processor (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-11] ต้องมีเฟิร์มแวร์ที่ประเมินโดย ห้องแล็บทดสอบที่ได้รับการรับรองระดับประเทศที่รวมการโจมตีระดับสูง การประเมินช่องโหว่ที่อาจเกิดขึ้นตาม การใช้เกณฑ์ร่วมกันของศักยภาพในการโจมตีกับสมาร์ทการ์ด
• [C-SR-2] แนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ ประเมินโดยใช้เป้าหมายความปลอดภัย ระดับความรับประกันการประเมิน (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] ต้องใช้ระบบข้อมูลประจำตัว (เช่น 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] ต้องทริกเกอร์ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ด้านบน เมื่อ DevicePolicyManager.wipeData() จะมีการเรียก API โดยแอปตัวควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลัก
• อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น

9.13 โหมดปลอดภัยเปิดเครื่อง

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

การใช้งานอุปกรณ์มีดังนี้

• [C-SR-1] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง

หากติดตั้งใช้งานอุปกรณ์ไว้ในโหมดปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้

• [C-1-1] ต้องระบุตัวเลือกให้กับผู้ใช้ในการ เข้าสู่โหมด Safe Boot ในลักษณะที่สามารถถูกขัดจังหวะจากบุคคลที่สามได้ แอปที่ติดตั้งในอุปกรณ์ ยกเว้นในกรณีที่แอปของบุคคลที่สาม เครื่องมือควบคุมนโยบายด้านอุปกรณ์และได้ตั้งค่า 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] ต้องแสดงตัวบ่งชี้ว่าอุปกรณ์ต้นทางมีข้อมูลอยู่แล้ว ซึ่งทำได้โดยใช้การย้ายข้อมูลระหว่างอุปกรณ์ในเมนูการตั้งค่า ผู้ใช้ ไม่ควรนำตัวบ่งชี้นี้ออกได้

เริ่มข้อกำหนดใหม่สำหรับ 15 คน (เวอร์ชันทดลอง AOSP)

9.17 เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

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

10.1 ชุดเครื่องมือทดสอบความเข้ากันได้

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

• [C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) จากโครงการโอเพนซอร์ส Android โดยใช้การจัดส่งขั้นสุดท้าย ซอฟต์แวร์ในอุปกรณ์

• [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS การนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ

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

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

• [C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ ณ เวลาที่อุปกรณ์ เสร็จสมบูรณ์

• ควรใช้การใช้งานการอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้ได้มากที่สุด

10.2 ผู้ตรวจสอบ CTS

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

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

• [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)" ดาวน์โหลดโดยมีการอัปเดตแบบออฟไลน์ผ่านรีบูต
  • "มีสายรัด" การอัปเดตผ่าน USB จากโฮสต์ PC
  • "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนที่เก็บข้อมูลแบบถอดได้

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

• [C-0-3] การอัปเดตทั้งหมดต้องมีการรับรองและกลไกการอัปเดตในอุปกรณ์ ต้องตรวจสอบการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์

• [C-SR-1] เราขอแนะนำเป็นอย่างยิ่งให้ใช้กลไกการลงนามเพื่อแฮชการอัปเดต ด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

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

• [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. บันทึกการเปลี่ยนแปลงของเอกสาร

สำหรับสรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้ ให้ทำดังนี้

• บันทึกการเปลี่ยนแปลงในเอกสาร

13. ติดต่อเรา

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