คำจำกัดความความเข้ากันได้ของ Android 17 [ตัวอย่าง]

1. บทนำ

เอกสารนี้แสดงข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้ อุปกรณ์เข้ากันได้กับ Android 17

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

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

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

ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 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. ประเภทอุปกรณ์)
  • ค: หลัก (ข้อกำหนดที่ใช้กับการติดตั้งใช้งานอุปกรณ์ Android ทั้งหมด)
  • H: อุปกรณ์พกพา Android
  • T: อุปกรณ์ Android TV
  • ตอบ: การติดตั้งใช้งาน Android Automotive
  • W: การติดตั้งใช้งานนาฬิกา Android
  • แท็บ: การติดตั้งใช้งานแท็บเล็ต Android
• รหัสเงื่อนไข
  • เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะตั้งค่ารหัสนี้เป็น 0
  • เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนดหมายเลข 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] ต้องมีจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอ ซึ่งมีขนาดอย่างน้อย 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

หากการใช้งานอุปกรณ์พกพาระบุว่ารองรับจอแสดงผลแบบ High Dynamic Range ผ่าน Configuration.isScreenHdr() อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [7.1.4.5/H-1-1] ต้องโฆษณาส่วนขยายที่รองรับ EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace และ VK_EXT_hdr_metadata

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

• [7.1.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการสร้างโปรไฟล์ GPU หรือไม่ผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support

หากการใช้งานอุปกรณ์พกพาระบุว่ารองรับผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support จะมีข้อกำหนดดังนี้

• [7.1.4.6/H-1-1] ต้องรายงานเป็นเอาต์พุต การติดตาม Protobuf ที่เป็นไปตามสคีมาสำหรับตัวนับ GPU และ สถานะการแสดงผล GPU ที่กำหนดไว้ในเอกสารประกอบ Perfetto

• [7.1.4.6/H-1-2] ต้องรายงานค่าที่เป็นไปตามข้อกำหนด สำหรับตัวนับ GPU ของอุปกรณ์ตาม gpu counter trace โปรโตคอลแพ็กเก็ต

• [7.1.4.6/H-1-3] ต้องรายงานค่าที่เป็นไปตามข้อกำหนด สำหรับ RenderStage ของ GPU ของอุปกรณ์ตาม render stage trace packet 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] ต้องรองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม

• [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างของฟังก์ชันย้อนกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า ระบบต้องไม่ใช้เหตุการณ์เหล่านี้ และสามารถทริกเกอร์ได้จากภายนอกอุปกรณ์ Android (เช่น แป้นพิมพ์ฮาร์ดแวร์ภายนอกที่เชื่อมต่อกับอุปกรณ์ Android)

• [7.2.3/H-0-3] ต้องมีฟังก์ชันหน้าแรกใน จอแสดงผลทั้งหมดที่รองรับ Android ซึ่งมีหน้าจอหลัก

• [7.2.3/H-0-4] ต้องมีฟังก์ชันย้อนกลับในจอแสดงผลทั้งหมดที่เข้ากันได้กับ Android และฟังก์ชันล่าสุดในจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอ

• [7.2.4/H-0-1] ต้องรองรับการป้อนข้อมูลด้วยหน้าจอสัมผัส

• [7.2.4/H-SR-1] ขอแนะนำอย่างยิ่งให้เปิดตัว แอปผู้ช่วยที่ผู้ใช้เลือก หรือกล่าวอีกนัยหนึ่งคือแอปที่ใช้VoiceInteractionService หรือกิจกรรมที่จัดการACTION_ASSIST เมื่อกดKEYCODE_MEDIA_PLAY_PAUSE หรือ KEYCODE_HEADSETHOOK ค้างไว้ หากกิจกรรมในเบื้องหน้าไม่ได้จัดการเหตุการณ์การกดค้างเหล่านั้น

• [7.3.1/H-SR-1] ขอแนะนำอย่างยิ่งให้รวมตัววัดความเร่งแบบ 3 แกน

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

• [7.3.1/H-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz

หากการใช้งานอุปกรณ์พกพารวมถึงเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่านแฟล็กฟีเจอร์android.hardware.location.gps จะมีลักษณะดังนี้

• [7.3.3/H-2-1] ต้องรายงานค่าจาก GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม

• [7.3.3/H-2-2] ต้องรายงานระยะหลอก GNSS และอัตราการเปลี่ยนแปลงของระยะหลอก ซึ่งในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะที่ อยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีกำลังสอง จะเพียงพอต่อการคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา

หากการใช้งานอุปกรณ์พกพารวมถึงไจโรสโคปแบบ 3 แกน จะต้องมีคุณสมบัติดังนี้

• [7.3.4/H-3-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz

• [7.3.4/H-3-2] ต้องวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที

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

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

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

• [7.3.11/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา

การติดตั้งใช้งานอุปกรณ์พกพาที่รองรับบลูทูธ LE มีดังนี้

• [7.4.3/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยายความยาวแพ็กเก็ตข้อมูลบลูทูธ LE

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 (Wi-Fi) จะต้องมีคุณสมบัติดังนี้

• [7.4.2.4/H-1-1] ต้องรองรับ Wi-Fi Passpoint

หากอุปกรณ์รองรับโปรโตคอล Neighbor Awareness Networking (NAN) ผ่าน Wi-Fi โดยการประกาศ PackageManager.FEATURE_WIFI_AWARE และตำแหน่ง Wi-Fi (เวลาไปกลับของ Wi-Fi หรือ 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 offset เพื่อให้มั่นใจว่าค่ามัธยฐานของ BLE RSSI คือ -50 dBm +/-15 dB ที่ระยะ 1 ม. จากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH

• [7.4.3/H-1-4] ต้องวัดและชดเชย Tx offset เพื่อให้มั่นใจว่าค่ามัธยฐานของ BLE RSSI คือ -50 dBm +/-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 หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด qHD (เช่น FWVGA)

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

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

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

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

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

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

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

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

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

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

• [7.6.1/H-9-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.ram.low

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

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

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

• ควรประกาศแฟล็กฟีเจอร์ android.hardware.ram.normal

หากการใช้งานอุปกรณ์พกพารวมถึงหน่วยความจำตั้งแต่ 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 ที่รองรับโหมดอุปกรณ์ต่อพ่วง

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

• [7.7.1/H-1-1] ต้องใช้ Android Open Accessory (AOA) API

หากการใช้งานอุปกรณ์พกพารวมถึงพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [7.7.2/H-1-1] ต้องใช้ คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบ Android SDK

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

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

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

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

• [7.9.1/H-1-1] ต้องประกาศ android.hardware.vr.high_performance แฟล็กฟีเจอร์

• [7.9.1/H-1-2] ต้องมีแอปพลิเคชัน ที่ใช้ android.service.vr.VrListenerService ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่าน android.app.Activity#setVrModeEnabled

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

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

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

เมื่อตรวจพบเทอร์มินัลเสียง USB ประเภท 0x0402 ระบบจะดำเนินการต่อไปนี้

• [7.8.2.2/H-3-1] ต้องออกอากาศ Intent ACTION_HEADSET_PLUG โดยตั้งค่าส่วนเสริม "microphone" เป็น 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 มิลลิวินาที

สำหรับการใช้งานอุปกรณ์พกพาที่ประกาศ android.hardware.audio.output และ android.hardware.microphone โปรดดูข้อกำหนด RTL และ TTL ในส่วน 5.6

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

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

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

• [7.10/H] ควรเลื่อนตัวกระตุ้นแบบสัมผัสในแกน X (ซ้าย-ขวา) ของการวางแนวตามธรรมชาติของอุปกรณ์

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

• [7.10/H] ควรมีความถี่เรโซแนนซ์ของ LRA แกน X ต่ำกว่า 200 Hz

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

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

• [7.10/H]^* ควรดำเนินการ การประเมินคุณภาพ สำหรับค่าคงที่แบบสัมผัส

• [7.10/H]^* ควรยืนยันและอัปเดตหากจำเป็น การกำหนดค่าสำรองสำหรับ Primitive ที่ไม่รองรับตามที่อธิบายไว้ใน คำแนะนำในการติดตั้งใช้งาน สำหรับค่าคงที่

2.2.2. มัลติมีเดีย

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

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] โปรไฟล์ MPEG-4 AAC (AAC LC)
• [5.1/H-0-4] โปรไฟล์ MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (AAC ที่มีความหน่วงต่ำที่ปรับปรุงแล้ว)

2.2.3. ซอฟต์แวร์

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

• [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] ต้องมีแอปพลิเคชันที่จัดการ Intent ACTION_GET_CONTENT ACTION_OPEN_DOCUMENT ACTION_OPEN_DOCUMENT_TREE และ ACTION_CREATE_DOCUMENT ตามที่อธิบายไว้ในเอกสาร SDK และให้ความสามารถแก่ผู้ใช้ในการเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้ DocumentsProvider API

• [3.2.3.1/H-SR-1] ขอแนะนำACTION_SENDTO หรือ ACTION_SEND หรือ ACTION_SEND_MULTIPLE อย่างยิ่งให้โหลดแอปพลิเคชันอีเมลล่วงหน้าซึ่งสามารถจัดการ Intent เพื่อส่งอีเมลได้

• [3.4.1/H-0-1] ต้องมีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

• [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน สำหรับการท่องเว็บของผู้ใช้ทั่วไป

• [3.8.1/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง ให้ใช้ตัวเรียกใช้เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ widgetFeatures ในแอป

• [3.8.1/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง ให้ใช้ตัวเรียกใช้เริ่มต้นที่ให้สิทธิ์เข้าถึงทางลัดเพิ่มเติมที่แอปของบุคคลที่สามระบุไว้อย่างรวดเร็วผ่าน ShortcutManager API

• [3.8.1/H-SR-3] ขอแนะนำเป็นอย่างยิ่ง ให้รวมแอปตัวเรียกใช้เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป

• [3.8.3/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สาม แจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญผ่านคลาส API Notification และ NotificationManager

• [3.8.3/H-0-2] ต้องรองรับการแจ้งเตือนที่สมบูรณ์

• [3.8.3/H-0-3] ต้องรองรับการแจ้งเตือนแบบลอย

• [3.8.3/H-0-4] ต้องมีหน้าต่างแจ้งเตือนเพื่อให้ผู้ใช้ควบคุมการแจ้งเตือนได้โดยตรง (เช่น ตอบกลับ เลื่อน ปิด บล็อก) ผ่านข้อบ่งชี้การใช้งานของผู้ใช้ เช่น ปุ่มดำเนินการหรือแผงควบคุมตามที่ใช้งานใน AOSP

• [3.8.3/H-0-5] ต้องแสดงตัวเลือก ที่ระบุผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือน

• [3.8.3/H-SR-1] ขอแนะนําอย่างยิ่ง ให้แสดงตัวเลือกแรกที่ระบุผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้

• [3.8.3/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง ให้แสดงตัวเลือกทั้งหมดที่ระบุผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดใน หน้าต่างแจ้งเตือน

• [3.8.3.1/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง ให้แสดงการดำเนินการที่ตั้งค่า Notification.Action.Builder.setContextual เป็น true ในบรรทัดเดียวกับคำตอบที่แสดงโดย Notification.Remoteinput.Builder.setChoices

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

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

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

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

หากการใช้งานอุปกรณ์พกพาประกาศระดับ API 36.1 ขึ้นไป จะมีข้อกำหนดดังนี้

• [3.8.3.1/H-0-1] ต้องแสดงการแจ้งเตือนการอัปเดตสดที่โปรโมตในตำแหน่งที่โดดเด่น บนหน้าจอล็อก

• [3.8.3.1/H-0-12] ต้องแสดงที่ด้านบนของกลุ่มการแจ้งเตือน การแจ้งเตือนแบบลอย และการแจ้งเตือนที่มีการเปลี่ยนสีด้านบน (เมื่อ setColorized เป็น true) เมื่อ การแจ้งเตือนการอัปเดตไลฟ์สดที่โปรโมตแสดงขึ้นพร้อมกับการแจ้งเตือนอื่นๆ

  • MAY จะกำหนดลำดับการแสดงการแจ้งเตือนการอัปเดตสดที่ได้รับการโปรโมต ซึ่งแสดงในหน้าต่างแจ้งเตือนและหน้าจอล็อกเมื่อมีแอปมากกว่า 1 แอป ที่มีสิทธิ์ได้รับการแจ้งเตือนการอัปเดตสดที่ได้รับการโปรโมต

• [3.8.3.1/H-0-2] ต้องแสดงการแจ้งเตือนการอัปเดตสดที่โปรโมตในสถานะที่ขยาย

• [3.8.3.1/H-0-3] ต้องไม่แสดงส่วนติดต่อผู้ใช้เพื่อยุบการแจ้งเตือนที่ขยาย ด้านบน

• [3.8.3.1/H-0-4] ต้องแสดงรูปแบบพื้นฐาน (ตัวหนา ตัวเอียง และขีดเส้นใต้) ของเนื้อหาข้อความ ในการแจ้งเตือนการอัปเดตแบบสดที่โปรโมตตามที่ระบุโดย StyleSpan หรือ UnderlineSpan

• [3.8.3.1/H-0-5] ต้องแสดงเฉพาะออบเจ็กต์การดำเนินการมาตรฐาน (ผ่าน Notification.Action) และต้องซ่อนออบเจ็กต์การดำเนินการที่ไม่เป็นไปตามมาตรฐาน เช่น ช่องป้อนข้อมูล ปุ่มตอบกลับ และการดำเนินการตามบริบท (ผ่าน addRemoteInput() และ setContextual()) ในการแจ้งเตือนการอัปเดตสดที่โปรโมต แม้ว่าการแจ้งเตือน จะมีออบเจ็กต์ดังกล่าวก็ตาม

• [3.8.3.1/H-0-6] ต้องแสดงการแสดงผลแบบย่อ ซึ่งเรียกอีกอย่างว่า ชิปสถานะ ในเอกสารประกอบของ SDK สำหรับการแจ้งเตือนการอัปเดตการแข่งขันสดที่โปรโมตซึ่งต้อง มี Notification.getSmallIcon()

  • [3.8.3.1/H-0-7] ฟิลด์อื่นๆ เป็นฟิลด์ที่ไม่บังคับสำหรับการแสดงแบบย่อ แต่เมื่อใดก็ตามที่ ขยายการแสดงแบบย่อได้ จะต้องแสดง Notification.getShortCriticalText() หากมี หรือ Notification.when หากไม่มี Notification.getShortCriticalText

  • [3.8.3.1/H-0-8] เมื่อมีการแจ้งเตือนการอัปเดตแบบเรียลไทม์ที่โปรโมตมากกว่า 1 รายการ ต้องแสดงอย่างน้อย 1 รายการในแถบสถานะเป็น การแสดงแบบกะทัดรัด

  • [3.8.3.1/H-0-9] ต้องแสดงการแจ้งเตือนที่เกี่ยวข้อง (แนะนำ) หรือเปิด แอปที่เกี่ยวข้อง (ผ่าน Notification.contentIntent) เมื่อผู้ใช้แตะการแสดงแบบย่อ

  • [3.8.3.1/H-0-13] ต้องแสดงเนื้อหาเดียวกันทั้งหมดในการแจ้งเตือนที่เชื่อมโยงกับการแจ้งเตือนที่พร้อมใช้งานในหน้าต่างแจ้งเตือน

• [3.8.3.1/H-0-10] ต้องมีตัวเลือกให้ผู้ใช้ปิดและเปิดใช้การแสดงผลที่ได้รับการโปรโมต ของการแจ้งเตือนของแอปแต่ละรายการ

• [3.8.3.1/H-0-11] ต้องแสดงการแจ้งเตือนการอัปเดตสดทั้งหมดอย่างถูกต้อง ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนการอัปเดตสดที่ไม่ได้โปรโมตซึ่งไม่เป็นไปตามหรือเป็นไปตามลักษณะการโปรโมตเพียงบางส่วน การแจ้งเตือนที่ไม่ได้โปรโมตดังกล่าวต้องแสดงในสถานะที่ไม่ได้โปรโมต

หากการใช้งานอุปกรณ์รวมถึงแป้นนำทางฟังก์ชัน "ล่าสุด" ตามที่ระบุไว้ในส่วน 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]^* ต้องแสดง การแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา โดยมี ข้อยกเว้นสำหรับการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าที่กำลังดำเนินการอยู่และ การแจ้งเตือนที่มีimportance:high

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

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

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

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

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

• [3.8.16/H-1-1] ต้องประกาศฟีเจอร์ Flag 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 ของ Control

• [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 และ API ของ Control

• [3.8.16/H-2-2] ต้องประกาศฟีเจอร์ Flag 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 Engine ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์

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

2.2.4. ประสิทธิภาพและพลังงาน

• [8.1/H-0-1] เวลาในการตอบสนองของเฟรมที่สอดคล้องกัน ความหน่วงของเฟรมที่ไม่สอดคล้องกันหรือความล่าช้าในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมต่อวินาที และควรต่ำกว่า 1 เฟรมต่อวินาที

• [8.1/H-0-2] เวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้ การใช้งานอุปกรณ์ต้องรับประกันประสบการณ์ของผู้ใช้ที่มีเวลาในการตอบสนองต่ำด้วยการเลื่อน รายการที่มีรายการ 10,000 รายการตามที่กำหนดโดยชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android ภายในเวลาไม่เกิน 36 วินาที

• [8.1/H-0-3] การสลับงาน เมื่อเปิดใช้แอปพลิเคชันหลายรายการ การเปิดใช้แอปพลิเคชันที่ทำงานอยู่แล้วอีกครั้งหลังจากเปิดใช้แล้วจะต้องใช้เวลาน้อยกว่า 1 วินาที

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

• [8.2/H-0-1] ต้องรับประกันประสิทธิภาพการเขียนแบบลำดับอย่างน้อย 5 MB/s

• [8.2/H-0-2] ต้องรับประกันประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/s

• [8.2/H-0-3] ต้องรับประกันประสิทธิภาพการอ่านแบบลำดับ อย่างน้อย 15 MB/วินาที

• [8.2/H-0-4] ต้องตรวจสอบว่าประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที

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

• [8.3/H-1-1] ต้องมีส่วนติดต่อผู้ใช้เพื่อเปิดใช้ และปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่

• [8.3/H-1-2] ต้องมีส่วนที่ผู้ใช้สามารถ แสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานของสแตนด์บายแอปและ Doze

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

• [8.4/H-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้พลังงานปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการระบายแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android

• [8.4/H-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ต่อชั่วโมง (mAh)

• [8.4/H-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime

• [8.4/H-0-4] ต้องทำให้การใช้พลังงานนี้ พร้อมใช้งานผ่านคำสั่งเชลล์ 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

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

• [9.1/H-0-2] ต้องไม่ให้สิทธิ์ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสำหรับแอปพลิเคชันนั้น

การติดตั้งใช้งานอุปกรณ์ต้องประกาศการรองรับ android.software.credentials และ

• [9/H-0-2] ต้องปฏิบัติตามandroid.settings.CREDENTIAL_PROVIDERเจตนา เพื่ออนุญาตให้เลือกผู้ให้บริการที่ต้องการสำหรับ Credential Manager ระบบจะเปิดใช้ผู้ให้บริการนี้สำหรับการป้อนข้อความอัตโนมัติ และจะเป็นตำแหน่งเริ่มต้นในการบันทึกข้อมูลเข้าสู่ระบบใหม่ที่ป้อนผ่าน Credential Manager ด้วย

• [9/H-0-3] ต้องรองรับผู้ให้บริการข้อมูลเข้าสู่ระบบพร้อมกันอย่างน้อย 2 ราย และมีตัวเลือกสำหรับผู้ใช้ในแอปการตั้งค่า เพื่อเปิดหรือปิดใช้ผู้ให้บริการ

• [9.5/H-1-1] นำข้อกำหนดออกใน Android 16

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

• [9.11/H-0-2] ต้องสำรองข้อมูลการติดตั้งใช้งาน Keystore ด้วยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก

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

• [9.11/H-0-4] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อก ในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้เฉพาะเมื่อ สำเร็จเท่านั้น ต้องจัดเก็บข้อมูลเข้าสู่ระบบของหน้าจอล็อก ในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกจากกัน ทำการตรวจสอบสิทธิ์หน้าจอล็อกได้ Android Open Source Project ต้นทางมี Gatekeeper ระดับชั้นการจัดการฮาร์ดแวร์โดยตรง (HAL) และ Trusty ซึ่งใช้เพื่อตอบสนองข้อกำหนดนี้ได้

• [9.11/H-0-5] ต้องรองรับการรับรองคีย์ที่ คีย์การลงนามการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนาม ในฮาร์ดแวร์ที่ปลอดภัย ต้องป้องกันไม่ให้ใช้คีย์การลงนามการรับรองเป็นตัวระบุอุปกรณ์ถาวร

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

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

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

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

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

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

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

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

• [9.5/H-4-1] นำข้อกำหนดออกใน Android 16

• [9.5/H-4-2] นำข้อกำหนดออกใน Android 16

การตั้งค่าที่จำกัด

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

• ได้รับการติดตั้งหลังจากดาวน์โหลดผ่านแอปพลิเคชัน (เช่น แอปพลิเคชันรับส่งข้อความหรือเบราว์เซอร์) อื่นๆ ที่ไม่ใช่ แอปพลิเคชัน "App Store" ที่ระบุโดย PackageManager เป็น PACKAGE_DOWNLOADED_FILE

• ติดตั้งจากไฟล์ในเครื่อง (เช่น แอปพลิเคชันได้รับการโหลดด้านข้าง) ระบุโดย PackageManager เป็น PACKAGE_SOURCE_LOCAL_FILE

สำหรับสิทธิ์ที่บังคับใช้และตัวระบุที่เกี่ยวข้องซึ่งระบุไว้ใน[9.8/H-0-5] ด้านล่าง

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

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

• [9.8/H-0-1] ต้องใช้การตั้งค่าที่จำกัดตามที่ระบุไว้ข้างต้นสำหรับ รายการต่อไปนี้

  • สิทธิ์พิเศษ

    • การช่วยเหลือพิเศษ (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • ตัวฟังการแจ้งเตือน (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • แอปผู้ดูแลระบบอุปกรณ์ (Manifest.permission.BIND_DEVICE_ADMIN)
    • แสดงทับแอปอื่นๆ (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • สิทธิ์การเข้าถึงการใช้งาน (AppOpsManager.OPSTR_GET_USAGE_STATS)

  • บทบาท (แอปเริ่มต้น)

    • Dialer (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)

  • สิทธิ์รันไทม์

    • ระยะเวลาของ SMS (Manifest.permission_group.SMS)

• [9.8/H-0-2] ต้องเปิดใช้การตั้งค่าที่จำกัดเป็นค่าเริ่มต้น และ ขอแนะนำอย่างยิ่งว่าไม่ควรมีส่วนใดที่อนุญาตให้ผู้ใช้ ปิดใช้การตั้งค่าที่จำกัดสำหรับแอปพลิเคชันทั้งหมด

• [9.8/H-0-3] ต้องตรวจสอบว่าได้รับความยืนยันจากผู้ใช้สำหรับ แอปพลิเคชันที่ครอบคลุมแต่ละรายการก่อนที่จะให้สิทธิ์ที่บังคับใช้

• [9.8/H-0-4] ต้องอนุญาตให้ยืนยันผู้ใช้เพื่อเปิดใช้การตั้งค่าที่จำกัด จากหน้า AppInfo ของแอปพลิเคชันที่ครอบคลุมเท่านั้น โดยใช้ EnhancedConfirmationManager API

• [9.8/H-0-5] ขอแนะนำอย่างยิ่งให้ผสานรวมและเรียกใช้ EnhancedConfirmationManager สำหรับสิทธิ์พิเศษทั้งหมด เพื่อพิจารณาแบบไดนามิกว่าสิทธิ์เหล่านั้นเป็นการตั้งค่าที่ถูกจำกัดหรือไม่

  • การปลุกและการช่วยเตือน: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • การเข้าถึงไฟล์ทั้งหมด: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • แสดงทับแอปอื่นๆ: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • ติดตั้งแอปที่ไม่รู้จัก: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • จัดการสื่อ: AppOpsManager.OPSTR_MANAGE_MEDIA
  • แก้ไขการตั้งค่าระบบ: AppOpsManager.OPSTR_WRITE_SETTINGS
  • การแสดงภาพซ้อนภาพ: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • เปิดหน้าจอ: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • การแจ้งเตือนแบบเต็มหน้าจอ: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • การควบคุม Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • การช่วยเหลือพิเศษ: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • ตัวฟังการแจ้งเตือน: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • สิทธิ์เข้าถึงการใช้งาน: AppOpsManager.OPSTR_GET_USAGE_STATS
  • ผู้ดูแลระบบอุปกรณ์: Manifest.permission.BIND_DEVICE_ADMIN
  • ห้ามรบกวน: Manifest.permission.MANAGE_NOTIFICATIONS

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

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

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

• [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจหาคีย์เวิร์ดสามารถส่งข้อมูลเสียงจากไมโครโฟนหรือข้อมูลที่ได้จากข้อมูลเสียงดังกล่าวไปยังเซิร์ฟเวอร์ของระบบผ่าน HotwordDetectionService API หรือไปยัง ContentCaptureService ผ่าน ContentCaptureManager API เท่านั้น

• [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] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องถ่ายรูปสำหรับแอปของระบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง

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

• [9.10/H-1-1] ต้องยืนยันพาร์ติชันแบบอ่านอย่างเดียวทั้งหมด ที่เมานต์ระหว่างลำดับการบูต Android และข้อมูลสรุป VBMeta ต้องรวมพาร์ติชันที่ยืนยันแล้วทั้งหมดเหล่านี้ในการคำนวณ

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

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

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

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

• Perfetto

  • [6.1/H-0-2] ต้องแสดง /system/bin/perfettoไบนารีต่อผู้ใช้ Shell ซึ่งบรรทัดคำสั่งเป็นไปตามเอกสารประกอบของ Perfetto

  • [6.1/H-0-3] ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า Protobuf เป็นอินพุตซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto

  • [6.1/H-0-4] ไบนารีของ Perfetto ต้องเขียนเป็น เอาต์พุตการติดตาม Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ใน เอกสารประกอบของ Perfetto

  • [6.1/H-0-5] ต้องระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไบนารี Perfetto

  • [6.1/H-0-6] ต้องเปิดใช้ Daemon ที่ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

2.2.7. Handheld Media Performance Class

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

2.2.7.1. สื่อ

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะต้องมีลักษณะดังนี้

• ต้องเป็นไปตามข้อกำหนดด้านสื่อทั้งหมดที่ระบุไว้ในส่วน 2.2.7.1 ของ CDD สำหรับ Android 17 ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

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

• [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือรุ่นที่ใหม่กว่า), อินสแตนซ์พร้อมกัน และเฟรมหลุด ที่สอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศ

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

• [5.1/H-1-4] ต้องรองรับเซสชันตัวเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือรุ่นที่ใหม่กว่า), อินสแตนซ์พร้อมกัน และเฟรม ดรอปที่สอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศ

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

• [5.1/H-1-6] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์และตัวเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือรุ่นที่ใหม่กว่า), อินสแตนซ์พร้อมกัน และเฟรม หลุดที่สอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศ

• [5.1/H-1-7] ต้องมีเวลาในการตอบสนองในการเริ่มต้นตัวแปลงรหัสสำหรับเซสชันการเข้ารหัสวิดีโอ 1080p หรือเล็กกว่าสำหรับตัวเข้ารหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ภายใต้ภาระงานที่สอดคล้องกับระดับประสิทธิภาพสื่อที่ประกาศไว้ของอุปกรณ์

• [5.1/H-1-8] ต้องมีเวลาในการตอบสนองในการเริ่มต้นตัวแปลงรหัสสำหรับเซสชันการเข้ารหัสเสียงที่มีอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับตัวเข้ารหัสเสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงานซึ่งสอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-9] ต้องรองรับอินสแตนซ์ 2 รายการของเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย (AVC, HEVC, VP9, AV1 หรือรุ่นที่ใหม่กว่า) และเฟรมที่ขาดหายไปซึ่งสอดคล้องกับระดับประสิทธิภาพสื่อที่ประกาศของอุปกรณ์

• [5.1/H-1-10] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ไม่ปลอดภัย 3 รายการ พร้อมกับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 1 รายการ (รวม 4 รายการ) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า), ความละเอียด และเฟรมหลุดที่สอดคล้องกับระดับประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-11] ต้องรองรับตัวถอดรหัสที่ปลอดภัยสำหรับตัวถอดรหัส AVC, HEVC, VP9 หรือ AV1 ของฮาร์ดแวร์ทุกตัวที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-12] ต้องมีเวลาในการตอบสนองในการเริ่มต้นตัวแปลงรหัสสำหรับเซสชันการถอดรหัสวิดีโอ 1080p หรือเล็กกว่า สำหรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ภายใต้ ภาระงานที่สอดคล้องกับ ระดับประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-13] ต้องมีเวลาในการตอบสนองในการเริ่มต้นตัวแปลงรหัสสำหรับเซสชันการถอดรหัสเสียงที่ 128 Kbps หรือ อัตราบิตที่ต่ำกว่าสำหรับตัวถอดรหัสเสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงาน ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-14] ต้องรองรับโปรไฟล์ ฟีเจอร์ และวิธีการแสดงผลของตัวถอดรหัสฮาร์ดแวร์ AV1 ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60 ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-16] ต้องมีตัวเข้ารหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60 ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-17] ต้องมีตัวถอดรหัสรูปภาพฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ AVIF โปรไฟล์พื้นฐาน ซึ่งสอดคล้องกับ ระดับ Media Performance Class ที่อุปกรณ์ประกาศ

• [5.1/H-1-18] ต้องรองรับตัวเข้ารหัส AV1 ที่มีอัตราบิต เฟรมต่อวินาที และความละเอียดตามที่อุปกรณ์ประกาศไว้ ระดับชั้นประสิทธิภาพของสื่อ

• [5.1/H-1-19] ต้องรองรับอินสแตนซ์ 3 รายการของตัวถอดรหัสวิดีโอฮาร์ดแวร์ 10 บิต (HDR) และเซสชันตัวเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ความละเอียด และเฟรมหลุดที่สอดคล้องกับระดับชั้นประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-20] ต้องรองรับฟีเจอร์ Feature_HdrEditing สำหรับตัวเข้ารหัส AV1 และ HEVC ของฮาร์ดแวร์ทั้งหมดที่มีในอุปกรณ์ ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-21] ต้องรองรับ FEATURE_DynamicColorAspect สำหรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมด (AVC, HEVC, VP9, AV1 หรือรุ่นที่ใหม่กว่า) ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.1/H-1-22] ต้องรองรับการเข้ารหัส การถอดรหัส การแก้ไขด้วย GPU และการแสดง เนื้อหาวิดีโอในสัดส่วนภาพแนวตั้งที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.2/H-2-1] หากการติดตั้งใช้งานอุปกรณ์รองรับตัวเข้ารหัส AVC หรือ HEVC ในฮาร์ดแวร์ จะต้องเป็นไปตามเป้าหมายคุณภาพขั้นต่ำ ที่กำหนดโดยเส้นโค้งอัตราการบิดเบือนของตัวเข้ารหัสวิดีโอสำหรับตัวแปลงรหัสเหล่านั้น ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.3/H-1-1] ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพของเซสชันวิดีโอและเฟรมหลุดที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.3/H-1-2] ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพการเปลี่ยนความละเอียดของวิดีโอ ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.6/H-1-1] ต้องเป็นไปตามข้อกำหนดเวลาในการตอบสนองต่อการแตะที่สอดคล้องกับ ระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.6/H-1-2] ต้องเป็นไปตามข้อกำหนดเวลาในการตอบสนองของเสียงไป-กลับ ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.6/H-1-3] ต้องเป็นไปตามข้อกำหนดของเสียง 24 บิตที่สอดคล้องกับ ระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.6/H-1-4] ต้องรองรับอุปกรณ์เสียง USB ที่มีช่องสัญญาณตั้งแต่ 4 ช่องขึ้นไปซึ่งสอดคล้องกับ ระดับ Media Performance Class ที่อุปกรณ์ประกาศไว้

• [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่เป็นไปตามข้อกำหนดของคลาสและประกาศแฟล็กฟีเจอร์ MIDI ที่สอดคล้องกับระดับ Media Performance Class ที่ประกาศของอุปกรณ์

• [5.6/H-1-9] ต้องรองรับการมิกซ์เสียงอย่างน้อย 12 ช่องที่สอดคล้องกับ ระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.6/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับการมิกซ์ช่องสัญญาณเสียง ที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.7/H-1-2] ต้องรองรับ MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL พร้อมความสามารถในการถอดรหัสที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.12/H-1-2] ต้องเป็นไปตามข้อกำหนดรูปแบบสีสำหรับตัวเข้ารหัส AV1 และ HEVC ของฮาร์ดแวร์ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [5.12/H-1-3] ต้องโฆษณาการรองรับส่วนขยาย EXT_YUV_target ที่สอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศ

• [7.1.4/H-1-1] ต้องเป็นไปตามข้อกำหนดของหน่วยประมวลผลการแสดงผล (DPU) ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

2.2.7.2. กล้อง

หากการใช้งานอุปกรณ์พกพาส่งคืนค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS การใช้งานดังกล่าวจะมีลักษณะดังนี้

• ต้องเป็นไปตามข้อกำหนดของกล้องที่ระบุไว้ในส่วน 2.2.7.2 ของ CDD สำหรับ Android 17 ซึ่งสอดคล้องกับระดับ Media Performance Class ที่ประกาศไว้ของอุปกรณ์

หากการใช้งานอุปกรณ์พกพาส่งคืนค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS การใช้งานดังกล่าวจะมีลักษณะดังนี้

• [7.5/H-1-1] ต้องเป็นไปตามข้อกำหนดด้านความละเอียดของกล้องหลักที่หันไปด้านหลังและข้อกำหนดด้านการจับภาพวิดีโอที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

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

• [7.5/H-1-3] ต้องรองรับ android.info.supportedHardwareLevel ข้อกำหนดของพร็อพเพอร์ตี้ที่สอดคล้องกับ ระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME สำหรับทั้งกล้องหลัก ที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-5] ต้องเป็นไปตาม ข้อกำหนดเวลาในการตอบสนองการจับภาพ JPEG ของ camera2 ที่สอดคล้องกับระดับ Media Performance Class ที่ประกาศไว้ของอุปกรณ์

• [7.5/H-1-6] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองเมื่อเริ่มต้นของ Camera2 ซึ่งสอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศไว้

• [7.5/H-1-8] ต้องเป็นไปตามข้อกำหนดในการจับภาพจากกล้อง RAW ที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

• [7.5/H-1-9] ต้องเป็นไปตามข้อกำหนดการจับภาพวิดีโอความเร็วสูงของกล้องหลักที่หันไปด้านหลัง ซึ่งสอดคล้องกับระดับ Media Performance Class ที่อุปกรณ์ประกาศไว้

• [7.5/H-1-10] ต้องเป็นไปตามข้อกำหนดอัตราส่วนการซูมขั้นต่ำ ที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่ประกาศของอุปกรณ์

• [7.5/H-1-11] ต้องใช้การสตรีมพร้อมกันทั้งกล้องหน้าและกล้องหลังในกล้องหลักที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-12] ต้องรองรับการป้องกันภาพสั่นสำหรับกล้องหลักด้านหลังที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-13] ต้องรองรับLOGICAL_MULTI_CAMERAความสามารถสำหรับกล้องหลักที่หันไปด้านหลังซึ่งสอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-14] ต้องรองรับความสามารถ STREAM_USE_CASE สำหรับ ทั้งกล้องหน้าหลักและกล้องหลังหลักที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-15] ต้อง รองรับส่วนขยายโหมดกลางคืนผ่านทั้งส่วนขยาย CameraX และ Camera2 สำหรับ กล้องหลักที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-16] ต้องรองรับDYNAMIC_RANGE_TEN_BITความสามารถสำหรับกล้องหลักที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-17] ต้องรองรับฟีเจอร์การตรวจจับใบหน้าสำหรับ กล้องหลักที่สอดคล้องกับ ระดับ Media Performance Class ที่อุปกรณ์ประกาศ

• [7.5/H-1-18] ต้องรองรับ JPEG_R สำหรับกล้องหลังหลักและกล้องหน้าหลักที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-19] ต้องรองรับ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION สำหรับกล้องหลัก ด้านหลังที่สอดคล้องกับระดับประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

• [7.5/H-1-20] ต้องแสดงผล JPEG_R สำหรับกล้องหลักด้านหลังและกล้องหลักด้านหน้าในแอปกล้องดั้งเดิมที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์โดยค่าเริ่มต้น

2.2.7.3. ฮาร์ดแวร์

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะต้องมีลักษณะดังนี้

• ต้องเป็นไปตามข้อกำหนดด้านฮาร์ดแวร์ที่ระบุไว้ในส่วน 2.2.7.3 ของ CDD สำหรับ Android 17 ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะต้องมีลักษณะดังนี้

• [7.1.1.1/H-1-1] รายการนี้ถูกข้ามโดยตั้งใจ

• [7.1.1.1/H-2-1] ต้องมีความละเอียดของหน้าจอที่สอดคล้องกับ ระดับMedia Performance Class ที่ ประกาศ ไว้ของอุปกรณ์

• [7.1.1.3/H-1-1] รายการนี้ถูกข้ามโดยตั้งใจ

• [7.1.1.3/H-2-1] ต้องมีความหนาแน่นของหน้าจอที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

• [7.1.1.3/H-3-1] ต้องรองรับข้อกำหนดของจอแสดงผล HDR ที่สอดคล้องกับระดับประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

• [7.6.1/H-1-1] รายการนี้ถูกข้ามโดยตั้งใจ

• [7.6.1/H-2-1] ต้องเป็นไปตามข้อกำหนดด้านหน่วยความจำที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศของอุปกรณ์

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

หากการใช้งานอุปกรณ์พกพาส่งคืนค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS การใช้งานดังกล่าวจะมีลักษณะดังนี้

• ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพที่ระบุไว้ในส่วน 2.2.7.4 ของ CDD สำหรับ Android 17 ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่ประกาศไว้ของอุปกรณ์

หากการใช้งานอุปกรณ์พกพาส่งคืนค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS การใช้งานดังกล่าวจะมีลักษณะดังนี้

• [8.2/H-1-1] ต้องรับประกันประสิทธิภาพการเขียนตามลำดับที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [8.2/H-1-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [8.2/H-1-3] ต้องรับประกันประสิทธิภาพการอ่านตามลำดับที่สอดคล้องกับระดับประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [8.2/H-1-4] ต้องรับประกันประสิทธิภาพการอ่านแบบสุ่มที่สอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [8.2/H-1-5] ต้องรับประกันประสิทธิภาพการอ่านและการเขียนแบบลำดับแบบขนาน ซึ่งสอดคล้องกับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

2.2.7.5. กราฟิก

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะต้องมีลักษณะดังนี้

• [7.1.4.1/H-1-2] ต้องรองรับส่วนขยาย EGL ที่จำเป็นซึ่งสอดคล้อง กับระดับชั้นประสิทธิภาพของสื่อที่อุปกรณ์ประกาศ

• [7.1.4.1/H-1-3] ต้องรองรับฟีเจอร์ Vulkan ที่จำเป็นซึ่งสอดคล้อง กับระดับประสิทธิภาพสื่อที่อุปกรณ์ประกาศ

2.3 ข้อกำหนดของทีวี

อุปกรณ์โทรทัศน์ Android หมายถึงการติดตั้งใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสำหรับการใช้สื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสำหรับผู้ใช้ที่นั่งห่างออกไปประมาณ 10 ฟุต ("เอนหลัง" หรือ "อินเทอร์เฟซผู้ใช้ 10 ฟุต")

การใช้งานอุปกรณ์ Android จะจัดเป็นโทรทัศน์หากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด

• มีกลไกในการควบคุมอินเทอร์เฟซผู้ใช้ที่แสดงผลจากระยะไกลบน จอแสดงผลซึ่งอาจอยู่ห่างจากผู้ใช้ 10 ฟุต
• มีจอแสดงผลแบบฝังที่มีความยาวในแนวทแยงมากกว่า 24 นิ้ว หรือมีพอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI, DisplayPort หรือพอร์ตไร้สายสำหรับแสดงผล

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

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] ต้องวัดการเปลี่ยนแปลงการวางแนวได้ สูงสุด 1,000 องศาต่อวินาที

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

• [7.4.3/T-0-1] ต้องรองรับบลูทูธและ บลูทูธ LE
• [7.6.1/T-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบไม่ลบเลือนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")

หากการติดตั้งใช้งานอุปกรณ์โทรทัศน์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [7.5.3/T-1-1] ต้องรองรับกล้องภายนอก ที่เชื่อมต่อผ่านพอร์ต USB นี้ แต่ไม่จำเป็นต้องเชื่อมต่ออยู่เสมอ

หากการติดตั้งใช้งานอุปกรณ์ทีวีเป็นแบบ 32 บิต ให้ทำดังนี้

• [7.6.1/T-1-1] หน่วยความจำที่เคอร์เนล และพื้นที่ผู้ใช้ใช้ได้ต้องมีอย่างน้อย 896 MB หากใช้ความหนาแน่นต่อไปนี้

  • 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
  • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
  • tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ

หากการติดตั้งใช้งานอุปกรณ์ทีวีเป็นแบบ 64 บิต ให้ทำดังนี้

• [7.6.1/T-2-1] หน่วยความจำที่เคอร์เนลและพื้นที่ผู้ใช้ใช้ได้ต้องมีอย่างน้อย 1280 MB หากใช้ความหนาแน่นต่อไปนี้

  • 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
  • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
  • tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ

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

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

• [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 เฟรมต่อวินาที ที่มี Main Profile High Level
• [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาที พร้อม Main Profile High Level โดยต้องยกเลิกการสอดแทรกวิดีโอ 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 เฟรมต่อวินาทีพร้อม Main Profile
• [5.3.4/T-1-3] HD 1080p ที่ 60 เฟรมต่อวินาทีโดยมี High Profile Level 4.2

การติดตั้งใช้งานอุปกรณ์โทรทัศน์ที่มีตัวถอดรหัสฮาร์ดแวร์ H.265 ต้องรองรับ การถอดรหัส H.265 ตามที่ระบุไว้ในส่วน 5.3.5 ที่อัตราเฟรมวิดีโอมาตรฐาน และความละเอียดสูงสุดถึงและรวมถึง

• [5.3.5/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีโดยมี Main Profile Level 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] ต้องรองรับการลดระดับเสียงหลักของระบบและระดับเสียงเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตการส่งผ่านเสียงที่บีบอัด (ซึ่งไม่มีการถอดรหัสเสียง ในอุปกรณ์)

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

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

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

• [5.8/T-1-1] ต้องรองรับ HDCP 2.2

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

• [5.8/T-2-1] ต้องรองรับ HDCP 1.4

2.3.3. ซอฟต์แวร์

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

• [3/T-0-1] ต้องประกาศฟีเจอร์ android.software.leanback และ android.hardware.type.television
• [3.2.3.1/T-0-1] ต้องโหลดล่วงหน้าอย่างน้อย 1 แอปพลิเคชันหรือคอมโพเนนต์บริการที่มีตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงที่นี่
• [3.4.1/T-0-1] ต้องมีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์ Android Television รองรับหน้าจอล็อก อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [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) ของบุคคลที่สาม

เฟรมเวิร์กอินพุตของ Android Television (TIF) ช่วยให้การ นำส่งเนื้อหาสดไปยังอุปกรณ์ Android Television เป็นเรื่องง่าย TIF มี API มาตรฐาน สำหรับสร้างโมดูลอินพุตที่ควบคุมอุปกรณ์ Android Television

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

• [3/T-0-2] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.live_tv
• [3/T-0-3] ต้องรองรับ TIF API ทั้งหมดเพื่อให้ติดตั้งและใช้แอปพลิเคชันที่ใช้ API เหล่านี้และบริการอินพุตที่อิงตาม TIF ของบุคคลที่สาม ในอุปกรณ์ได้

Android Television Tuner Framework (TF) รวมการจัดการเนื้อหาแบบสดจาก Tuner กับเนื้อหาสตรีมจาก IP ในอุปกรณ์ Android Television Tuner Framework มี API มาตรฐาน สำหรับสร้างบริการอินพุตที่ใช้ Android Television Tuner

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

• [3/T-1-1] ต้องรองรับ API ของ Tuner Framework ทั้งหมดเพื่อให้สามารถติดตั้งและใช้แอปพลิเคชันที่ใช้ API เหล่านี้ในอุปกรณ์ได้

2.3.4. ประสิทธิภาพและพลังงาน

• [8.1/T-0-1] เวลาในการตอบสนองของเฟรมที่สม่ำเสมอ ความหน่วงของเฟรมที่ไม่สอดคล้องกันหรือความล่าช้าในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมต่อวินาที และควรต่ำกว่า 1 เฟรมต่อวินาที
• [8.2/T-0-1] ต้องรับประกันประสิทธิภาพการเขียนแบบลำดับอย่างน้อย 5 MB/s
• [8.2/T-0-2] ต้องรับประกันประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/s
• [8.2/T-0-3] ต้องรับประกันประสิทธิภาพการอ่านแบบลำดับ อย่างน้อย 15 MB/s
• [8.2/T-0-4] ต้องตรวจสอบว่าประสิทธิภาพการอ่านแบบสุ่มมีอย่างน้อย 3.5 MB/s

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

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

• [9.1/T-0-1] ต้องไม่ให้สิทธิ์ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสำหรับแอปพลิเคชันนั้น

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

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

• [9.11/T-0-4] ต้องรองรับการรับรองคีย์ที่ คีย์การลงนามการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนาม ในฮาร์ดแวร์ที่ปลอดภัย ต้องป้องกันไม่ให้ใช้คีย์การลงนามการรับรองเป็นตัวระบุอุปกรณ์ถาวร

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

หากการใช้งานอุปกรณ์โทรทัศน์รองรับหน้าจอล็อกที่ปลอดภัย จะมีลักษณะดังนี้

• [9.11/T-1-1] ต้องอนุญาตให้ผู้ใช้เลือกการหมดเวลาสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นสถานะล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตไม่เกิน 15 วินาที

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

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

• Perfetto

  • [6.1/T-0-1] ต้องแสดง /system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ซึ่งบรรทัดคำสั่งเป็นไปตาม เอกสารประกอบของ Perfetto
  • [6.1/T-0-2] ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า Protobuf เป็นอินพุต ซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
  • [6.1/T-0-3] ไบนารีของ Perfetto ต้องเขียนเป็นเอาต์พุตของร่องรอย Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
  • [6.1/T-0-4] ต้องระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไบนารี Perfetto
  • [6.1/T-0-5] ต้องเปิดใช้ Daemon ที่ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

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

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

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

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

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

2.4.1. ฮาร์ดแวร์

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

• [7.1.1.1/W-0-1] ต้องมีหน้าจอที่มี ขนาดเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว

• [7.2.3/W-0-1] ต้องมีฟังก์ชันหน้าแรกพร้อมให้บริการ แก่ผู้ใช้ และฟังก์ชันย้อนกลับ ยกเว้นเมื่ออยู่ใน UI_MODE_TYPE_WATCH

• [7.2.4/W-0-1] ต้องรองรับการป้อนข้อมูลด้วยหน้าจอสัมผัส

• [7.3.1/W-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องวัดความเร่ง 3 แกน

หากการติดตั้งใช้งานอุปกรณ์ Wear OS มีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่านฟีเจอร์ android.hardware.location.gps flag จะมีลักษณะดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์นาฬิกามีไจโรสโคปแบบ 3 แกน จะต้องมีคุณสมบัติดังนี้

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

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

• [7.4.3/W-0-1] ต้องรองรับบลูทูธ

• [7.6.1/W-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบไม่ลบเลือนอย่างน้อย 1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")

• [7.6.1/W-0-2] ต้องมีหน่วยความจำอย่างน้อย 416 MB ที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้

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

• [7.8.2/W] อาจมีเอาต์พุตเสียง

2.4.2. มัลติมีเดีย

ไม่มีข้อกำหนดเพิ่มเติม

2.4.3. ซอฟต์แวร์

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

• [3/W-0-1] ต้องประกาศฟีเจอร์ android.hardware.type.watch
• [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH
• [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงที่นี่

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

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

ดูการติดตั้งใช้งานอุปกรณ์ที่ประกาศandroid.hardware.audio.output แฟล็กฟีเจอร์

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

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

• [3.11/W-SR-1] ขอแนะนำอย่างยิ่งให้รวม เครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์

• [3.11/W-0-1] ต้องรองรับการติดตั้ง เครื่องมือ TTS ของบุคคลที่สาม

2.4.4. ประสิทธิภาพและพลังงาน

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

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

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

• [8.4/W-0-1] ต้องระบุ โปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้พลังงานปัจจุบัน สำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และแบตเตอรี่หมดเร็วโดยประมาณที่เกิดจาก คอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
• [8.4/W-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ต่อชั่วโมง (mAh)
• [8.4/W-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime
• [8.4/W-0-4] ต้องทำให้การใช้พลังงานนี้ พร้อมใช้งานผ่านคำสั่งเชลล์ adb shell dumpsys batterystats แก่นักพัฒนาแอป
• [8.4/W] ควรระบุแหล่งที่มาของ คอมโพเนนต์ฮาร์ดแวร์เอง หากระบุแหล่งที่มาของการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ ไปยังแอปพลิเคชันไม่ได้

2.4.5. โมเดลความปลอดภัย

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

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

หากการติดตั้งใช้งานอุปกรณ์ Wear มีแอปพลิเคชันเริ่มต้นที่รองรับ VoiceInteractionService แอปพลิเคชันดังกล่าว

• [9.1/W-0-1] ต้องไม่ให้สิทธิ์ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสำหรับแอปพลิเคชันนั้น

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

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

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

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

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

2.5 ข้อกำหนดเกี่ยวกับยานยนต์

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

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

• ฝังเป็นส่วนหนึ่งของยานยนต์หรือเสียบเข้ากับยานยนต์ได้

• ใช้หน้าจอในแถวที่นั่งคนขับเป็นจอแสดงผลหลัก

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

2.5.1. ฮาร์ดแวร์

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

• [7.1.1.1/A-0-1] ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมอย่างน้อย 6 นิ้ว

• [7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจอ อย่างน้อย 750 dp x 480 dp

• [7.1.1.1/A-0-3] ต้องรองรับการคอมโพส GPU ของบัฟเฟอร์กราฟิกที่มีขนาดอย่างน้อยเท่ากับความละเอียดสูงสุดของจอแสดงผลในตัว

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [7.1.1.1/A-1-1] ต้องมีหน้าจอแยกที่มีขนาดเส้นทแยงมุมอย่างน้อย 6 นิ้วสำหรับโซนผู้โดยสารแต่ละโซนสำหรับจอแสดงผลหลัก โดยควรติดป้ายกำกับเป็น CarOccupantZoneManager.DISPLAY_TYPE_MAIN สำหรับแต่ละโซนของผู้เข้าพัก

• [7.1.1.1/A-1-2] ต้องมีเลย์เอาต์ขนาดหน้าจอ อย่างน้อย 750 dp x 480 dp สำหรับจอแสดงผลหลักแต่ละจอ

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รวมถึงการรองรับ Vulkan จะต้องมีคุณสมบัติดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์อ้างว่ารองรับจอแสดงผลที่มีช่วงไดนามิกสูง ผ่าน Configuration.isScreenHdr() อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [7.1.4.5/A-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/A-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการสร้างโปรไฟล์ GPU ผ่านพร็อพเพอร์ตี้ของระบบหรือไม่ graphics.gpu.profiler.support

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศการรองรับผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [7.1.4.6/A-1-1] ต้องรายงานเป็นเอาต์พุต การติดตาม Protobuf ที่เป็นไปตามสคีมาสำหรับตัวนับ GPU และ GPU RenderStages ที่กำหนดไว้ใน เอกสารประกอบ Perfetto

• [7.1.4.6/A-1-2] ต้องรายงานค่าที่เป็นไปตามข้อกำหนด สำหรับตัวนับ GPU ของอุปกรณ์ตาม gpu counter trace โปรโตคอลแพ็กเก็ต

• [7.1.4.6/A-1-3] ต้องรายงานค่าที่เป็นไปตามข้อกำหนด สำหรับ RenderStage ของ GPU ของอุปกรณ์ตาม render stage trace packet proto

• [7.1.4.6/A-1-4] ต้องรายงานจุดติดตามความถี่ของ GPU ตามที่ระบุไว้ในรูปแบบ power/gpu_frequency

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

• [7.1.5/A-0-1] ต้องรองรับโหมดความเข้ากันได้ของแอปเวอร์ชันเดิมตามที่โค้ดโอเพนซอร์สของ Android ต้นทางได้ติดตั้งใช้งาน กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือ เกณฑ์ที่เปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนแปลง ลักษณะการทำงานของโหมดความเข้ากันได้เอง

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

• [7.1.7/A-0-1] ต้องกำหนดค่า จอแสดงผลรอง ในแนวสายตาของผู้ขับเป็น FLAG_PRIVATE

• [7.2.3/A-0-1] ต้องมีฟังก์ชันหน้าแรกและ อาจมีฟังก์ชันย้อนกลับและล่าสุด

• [7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้าง ของฟังก์ชันย้อนกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันที่อยู่เบื้องหน้า

• [7.3/A-0-1] ต้องใช้และรายงาน GEAR_SELECTION NIGHT_MODE PERF_VEHICLE_SPEED และ PARKING_BRAKE_ON

• [7.3/A-0-2] ค่าของ NIGHT_MODE แฟล็ก ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตาม อินพุตจากเซ็นเซอร์แสงแวดล้อม เซ็นเซอร์แสงแวดล้อมพื้นฐานอาจเหมือนกับโฟโตมิเตอร์

• [7.3/A-0-3] ต้องระบุฟิลด์ข้อมูลเพิ่มเติมของเซ็นเซอร์ TYPE_SENSOR_PLACEMENT เป็นส่วนหนึ่งของ SensorAdditionalInfo สำหรับเซ็นเซอร์ทุกตัวที่ระบุ

• [7.3/A-SR1] อาจคาดคะเนตำแหน่ง ตำแหน่ง โดยการรวม GPS/GNSS กับเซ็นเซอร์เพิ่มเติม หากมีการประมาณตำแหน่งโดยใช้ข้อมูลที่ทราบล่าสุด Location เราขอแนะนำอย่างยิ่งให้ใช้และรายงานประเภทเซ็นเซอร์ และ/หรือรหัสพร็อพเพอร์ตี้ยานพาหนะ ที่เกี่ยวข้อง

• [7.3/A-0-4] ตำแหน่ง ที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่ตรงกับแผนที่

• [7.3.1/A-0-4] ต้องเป็นไปตาม ระบบพิกัดเซ็นเซอร์รถยนต์ของ Android

• [7.3/A-SR-1] ขอแนะนำอย่างยิ่งให้มีตัววัดความเร่งแบบ 3 แกน และไจโรสโคปแบบ 3 แกน

• [7.3/A-SR-2] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงาน TYPE_HEADING เซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [7.3/A-1-1] ต้องตั้งค่าสถานะ NIGHT_MODE ให้สอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ดใน จอแสดงผลทั้งหมด รวมถึงจอแสดงผลที่เบาะหลัง

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

• [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 เซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเครื่องรับ 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] ขอแนะนำอย่างยิ่งให้รายงานเหตุการณ์ที่มีความถี่อย่างน้อย 10 Hz

• ควรเป็นทิศเหนือจริง

• ควรพร้อมใช้งานแม้ว่ายานพาหนะจะจอดอยู่ก็ตาม

• ควรมีความละเอียดอย่างน้อย 1 องศา

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

• [7.4.3/A-0-1] ต้องรองรับบลูทูธและควร รองรับบลูทูธ LE

• [7.4.3/A-0-2] การใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้

  • การโทรผ่านโปรไฟล์แฮนด์ฟรี (HFP)
  • การเล่นสื่อผ่าน Audio Distribution Profile (A2 DP)
  • การควบคุมการเล่นสื่อผ่านโปรไฟล์การควบคุมระยะไกล (AVRCP)
  • การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)

• [7.4.3/A-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Message Access Profile (MAP) หากอุปกรณ์มีโซนที่นั่งคนขับ

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [7.4.3/A-1-1] ต้องเป็นอิสระและไม่รบกวน ประสบการณ์การใช้งาน BT ของผู้ใช้รายอื่น

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

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

• [7.5/A-SR-3] ขอแนะนำอย่างยิ่งให้มีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (Extended Depth of Field)

• [7.5/A-1-2] ต้องมีกล้องหลักที่หันออกด้านนอกเป็นกล้องที่หันออกด้านนอก ซึ่งมีรหัสกล้องต่ำที่สุด

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

• [7.5/A-2-1] กล้องหลักที่หันหน้าเข้าหาผู้ใช้ต้องเป็นกล้องที่หันหน้าเข้าหาผู้ใช้ ซึ่งมีรหัสกล้องต่ำที่สุด

• อาจวางแนวให้มิติยาวของกล้องสอดคล้องกับระนาบ X-Y ของแกนเซ็นเซอร์ยานยนต์ Android

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

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

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

• [7.5/A-5-1] ต้องไม่หมุนหรือพลิกภาพตัวอย่างกล้องในแนวนอน

• [7.5/A-SR-4] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 เมกะพิกเซล

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อย 1 ตัวที่เข้าถึงได้ผ่านทั้ง Extended View System Service และ android.hardware.Camera หรือ android.hardware.Camera2 API กล้องดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [7.5/A-6-1] ต้องรายงานรหัสกล้องเดียวกัน

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

• [7.5/A-7-1] ต้องใช้ API กล้องดังกล่าวโดยใช้ android.hardware.camera2 API หรือ Extended View System API

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

• [7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบไม่ลบเลือนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data)

• [7.6.1/ก] ควรจัดรูปแบบพาร์ติชันข้อมูล เพื่อให้ประสิทธิภาพดีขึ้นและใช้งานได้นานขึ้นในพื้นที่เก็บข้อมูลแบบแฟลช (เช่น ใช้ระบบไฟล์ f2fs)

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

• [7.6.1/A-SR-1] ขอแนะนำอย่างยิ่งให้ลด ค่าใช้จ่าย I/O ในการดำเนินการที่ทำในพื้นที่เก็บข้อมูลภายนอก เช่น โดย ใช้ SDCardFS

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์เป็นแบบ 64 บิต ให้ทำดังนี้

• [7.6.1/A-2-1] หน่วยความจำที่เคอร์เนลและพื้นที่ผู้ใช้ใช้ได้ต้องมีอย่างน้อย 816 MB ต่อจอแสดงผลหลัก หากใช้ความหนาแน่นต่อไปนี้

  • 280 DPI หรือต่ำกว่าในหน้าจอขนาดเล็ก/ปกติ
  • ldpi หรือต่ำกว่าในหน้าจอขนาดใหญ่พิเศษ
  • mdpi หรือต่ำกว่าในหน้าจอขนาดใหญ่

• [7.6.1/A-2-2] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีอย่างน้อย 944 MB ต่อจอแสดงผลหลัก หากใช้ความหนาแน่นต่อไปนี้

  • xhdpi ขึ้นไปในหน้าจอขนาดเล็ก/ปกติ
  • hdpi ขึ้นไปในหน้าจอขนาดใหญ่
  • mdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ

• [7.6.1/A-2-3] หน่วยความจำที่เคอร์เนลและพื้นที่ผู้ใช้ใช้ได้ต้องมีอย่างน้อย 1280 MB ต่อจอแสดงผลหลัก หากใช้ความหนาแน่นต่อไปนี้

  • 400 DPI ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
  • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
  • tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ

• [7.6.1/A-2-4] หน่วยความจำที่เคอร์เนลและพื้นที่ผู้ใช้ใช้ได้ต้องมีอย่างน้อย 1824 MB ต่อจอแสดงผลหลัก หากใช้ความหนาแน่นต่อไปนี้

  • 560 dpi ขึ้นไปในหน้าจอขนาดเล็ก/ปกติ
  • 400 DPI ขึ้นไปบนหน้าจอขนาดใหญ่
  • xhdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ

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

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

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

หากการใช้งานอุปกรณ์ยานยนต์มีพอร์ต USB พร้อมคอนโทรลเลอร์ ที่ทำงานในโหมดอุปกรณ์ต่อพ่วง จะมีลักษณะดังนี้

• [7.7.1/A-1-1] ต้องใช้ Android Open Accessory (AOA) API

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [7.7.2/A-1-1] ต้องใช้ คลาสเสียง USB ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [7.8.2/A-1-1] ต้องมีอุปกรณ์เอาต์พุตเสียงสำหรับจอแสดงผลหลักแต่ละจอ สำหรับระบบผู้ใช้หลายคนพร้อมกัน

• [7.8.2/A-1-2] ต้องมีโซนเสียงสำหรับคนขับที่ครอบคลุมลำโพงในห้องโดยสารส่วนกลาง โซนผู้โดยสารด้านหน้าสามารถแชร์โซนเสียงของคนขับ หรือมีเอาต์พุตเสียงของตัวเองได้

เมื่อเรียกใช้ AudioManager.getDevices() API ขณะที่เชื่อมต่ออุปกรณ์ต่อพ่วง USB ระบบจะทำดังนี้

• [7.8.2.2/A-1-1] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB เป็น 0x0302

• [7.8.2.2/A-1-2] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB เป็น 0x0402

• [7.8.2.2/A-1-3] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB เป็น 0x0603

• [7.8.2.2/A-1-4] ต้องแสดงอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB เป็น 0x0400

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

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

• [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)

• [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)

• [5.1/A-0-3] AAC ELD (AAC ที่มีความหน่วงต่ำที่ได้รับการปรับปรุง)

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

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

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [5.5.3/A-1-1] ต้องกำหนดเส้นโค้งระดับเสียงที่เหมือนกันสำหรับ สตรีมเอาต์พุตเสียงทั้งหมดที่แมปกับกลุ่มระดับเสียงเดียวกันตามที่กำหนดไว้ใน ไฟล์กำหนดค่าเสียงในรถยนต์

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มี 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.2.3.1/A-0-2] ต้องมีแอปที่จัดการ ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, และ ACTION_CREATE_DOCUMENT Intent ตามที่อธิบายไว้ในเอกสาร SDK และมอบความสามารถให้ผู้ใช้ เข้าถึงข้อมูลของผู้ให้บริการเอกสารโดยใช้ DocumentsProvider API

หากการใช้การตั้งค่าของอุปกรณ์ยานยนต์ใช้ฟังก์ชันการแยก โดยใช้การฝังกิจกรรม จะมีลักษณะดังนี้

• [3.2.3.1/A-1-1] ต้องมีกิจกรรม ที่จัดการ Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent เมื่อเปิดฟังก์ชันการแยก กิจกรรมต้องได้รับการปกป้องโดย android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK และต้องเริ่ม กิจกรรมของ Intent ที่แยกวิเคราะห์จาก Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI

• [3.4.1/A-0-1] ต้องมีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับการใช้งานแบบหลายคนหนึ่งเครื่องพร้อมกัน (ซึ่งผู้ใช้ Android หลายคนสามารถโต้ตอบกับอุปกรณ์พร้อมกันได้ โดยแต่ละคนจะใช้จอแสดงผลของตนเองเมื่อเปิดใช้ config_multiuserVisibleBackgroundUsers ) จะมีลักษณะดังนี้

• [3.8/A-1-1] ต้องใช้รายการUserRestrictionsที่กำหนดไว้ล่วงหน้าต่อไปนี้สำหรับผู้ใช้รองแบบเต็ม ซึ่งไม่ใช่ผู้ใช้ที่อยู่เบื้องหน้าในปัจจุบัน แต่มีสิทธิ์เข้าถึง UI ของจอแสดงผล ที่กำหนดให้ รายการ UserRestrictions มีดังนี้ DISALLOW_CONFIG_LOCALE DISALLOW_CONFIG_BLUETOOTH DISALLOW_BLUETOOTH DISALLOW_CAMERA_TOGGLE และ DISALLOW_MICROPHONE_TOGGLE

• [3.8/A-1-2] ต้องไม่อนุญาตให้ผู้ใช้รองแบบเต็ม ซึ่งไม่ใช่ผู้ใช้ที่ใช้งานอยู่เบื้องหน้าในปัจจุบัน แต่มีสิทธิ์เข้าถึง UI ของจอแสดงผลที่กำหนดให้เปลี่ยนโหมดกลางวัน/กลางคืน ภาษา วันที่ เวลา เขตเวลา หรือฟีเจอร์สีของจอแสดงผล (รวมถึงความสว่าง แสงตอนกลางคืน การเปลี่ยนเป็นสีเทาในไลฟ์สไตล์ดิจิทัล และลดสีสว่าง) สำหรับผู้ใช้รายอื่นผ่านการตั้งค่าหรือจาก API

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

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

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

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

• [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/ก] ควรจำกัด การใช้งานงานการจัดการที่ซับซ้อน เช่น การควบคุมต่อช่องทางการแจ้งเตือน อาจใช้ความสามารถของ UI ต่อแอปพลิเคชันเพื่อลดการควบคุม

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

• [3.9.3/A-1-1] ต้องใช้พร็อพเพอร์ตี้วงจรของผู้ใช้ทั้งหมดต่อไปนี้ INITIAL_USER_INFO, SWITCH_USER, CREATE_USER และ REMOVE_USER

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

• [3.14/A-0-1] ต้องมีเฟรมเวิร์ก UI เพื่อรองรับ แอปของบุคคลที่สามที่ใช้ Media 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] ต้องมีองค์ประกอบที่ช่วยให้ไปยังกิจกรรมการตั้งค่าของแอปพลิเคชันสื่อได้ แต่ต้องเปิดใช้เมื่อข้อจำกัดของ Car 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

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

• [3.14/A-1-1] ต้องมีบริการสื่อและเปิดบริการเหล่านั้นด้วย เจตนา CAR_INTENT_ACTION_MEDIA_TEMPLATE

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

• [3.8/A] อาจจำกัดคำขอของแอปพลิเคชัน เพื่อเข้าสู่โหมดเต็มหน้าจอตามที่อธิบายไว้ใน immersive documentation

• [3.8/A] อาจแสดงแถบสถานะและ แถบนำทางตลอดเวลา

• [3.8/A] อาจจำกัดคำขอของแอปพลิเคชัน เพื่อเปลี่ยนสีด้านหลังองค์ประกอบ UI ของระบบ เพื่อให้มั่นใจว่า องค์ประกอบเหล่านั้นจะมองเห็นได้อย่างชัดเจนตลอดเวลา

2.5.4. ประสิทธิภาพและพลังงาน

• [8.1/A-0-1] เวลาในการตอบสนองของเฟรมที่สม่ำเสมอ ความหน่วงของเฟรมที่ไม่สอดคล้องกันหรือความล่าช้าในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมต่อวินาที และควรต่ำกว่า 1 เฟรมต่อวินาที

• [8.1/A-0-2] เวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้ การใช้งานอุปกรณ์ต้องรับประกันประสบการณ์ของผู้ใช้ที่มีเวลาในการตอบสนองต่ำโดยการเลื่อน รายการที่มีรายการ 10,000 รายการตามที่กำหนดโดยชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android ในเวลาน้อยกว่า 36 วินาที

• [8.1/A-0-3] การสลับงาน เมื่อเปิดใช้แอปหลายแอป การเปิดใช้แอปพลิเคชันที่ทำงานอยู่แล้วอีกครั้งหลังจากที่เปิดใช้ไปแล้วจะต้องใช้เวลาน้อยกว่า 1 วินาที

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

• [8.2/A-0-1] ต้องรายงานจำนวนไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลแบบไม่ลบเลือนต่อ UID ของแต่ละกระบวนการ เพื่อให้นักพัฒนาแอปเข้าถึงสถิติผ่าน System API android.car.storagemonitoring.CarStorageMonitoringManager ได้ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านuid_sys_statsโมดูลเคอร์เนล

• [8.2/A-0-2] ต้องรับประกันประสิทธิภาพการเขียนแบบลำดับอย่างน้อย 5 MB/วินาที

• [8.2/A-0-3] ต้องรับประกันประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/s

• [8.2/A-0-4] ต้องรับประกันประสิทธิภาพการอ่านแบบลำดับ อย่างน้อย 15 MB/วินาที

• [8.2/A-0-5] ต้องรับประกันประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์แสดงผล android.os.Build.VERSION_CODES.U หรือมากกว่าสำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะมีลักษณะดังนี้

• [8.2/A-1-1] ต้องรับประกันประสิทธิภาพการเขียนแบบลำดับอย่างน้อย 150 MB/วินาที

• [8.2/A-1-2] ต้องตรวจสอบว่าประสิทธิภาพการเขียนแบบสุ่ม มีอย่างน้อย 10 MB/s

• [8.2/A-1-3] ต้องรับประกันประสิทธิภาพการอ่านแบบลำดับอย่างน้อย 250 MB/วินาที

• [8.2/A-1-4] ต้องรับประกันประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 100 MB/s

• [8.2/A-1-5] ต้องรับประกันประสิทธิภาพการอ่านและเขียนแบบขนาน ตามลำดับด้วยประสิทธิภาพการอ่าน 2 เท่าและประสิทธิภาพการเขียน 1 เท่า อย่างน้อย 50 MB/s

• [8.3/A-1-3] ต้องรองรับโหมดโรงรถ

• [8.3/ก] ควรอยู่ในโหมดโรงรถอย่างน้อย 15 นาทีหลังจากการขับขี่ทุกครั้ง เว้นแต่ในกรณีต่อไปนี้

  • แบตเตอรี่หมด
  • ไม่มีการกำหนดเวลางานที่ไม่ได้ใช้งาน
  • คนขับออกจากโหมดโรงรถ

• [8.4/A-0-1] ต้องระบุ โปรไฟล์การใช้พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้พลังงานปัจจุบัน สำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการใช้แบตเตอรี่หมดเร็วโดยประมาณที่เกิดจาก คอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android

• [8.4/A-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ต่อชั่วโมง (mAh)

• [8.4/A-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime

• [8.4/ก] ควรระบุแหล่งที่มาของ คอมโพเนนต์ฮาร์ดแวร์เองหากระบุแหล่งที่มาของการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ ไปยังแอปพลิเคชันไม่ได้

• [8.4/A-0-4] ต้องทำให้การใช้พลังงานนี้ พร้อมใช้งานผ่านคำสั่งเชลล์ adb shell dumpsys batterystats แก่นักพัฒนาแอป

2.5.5. โมเดลความปลอดภัย

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

• [9.5/A-1-1] ต้องไม่อนุญาตให้ผู้ใช้โต้ตอบกับ หรือเปลี่ยนไปใช้ผู้ใช้ระบบแบบไม่มีส่วนหัว ยกเว้นการจัดเตรียมอุปกรณ์

• [9.5/A-1-2] ต้องเปลี่ยนเป็นผู้ใช้รอง ก่อน BOOT_COMPLETED

• [9.5/A-1-3] ต้องรองรับความสามารถในการสร้างผู้ใช้ชั่วคราว แม้ว่าจะมีผู้ใช้ในอุปกรณ์ถึงจำนวนสูงสุดแล้วก็ตาม

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

• [9.8/A-1-1] ต้องตรวจสอบว่าบริการตรวจหาคำค้นสามารถส่งข้อมูลไปยังระบบ ContentCaptureService หรือบริการจดจำเสียงพูดในอุปกรณ์ (สร้างโดย SpeechRecognizer#createOnDeviceSpeechRecognizer()) เท่านั้น

• [9.8/A-1-2] ต้องไม่อนุญาตให้ส่งข้อมูลเสียงหรือวิดีโอ ออกจาก VisualQueryDetectionService ยกเว้นไปยัง ContentCaptureService หรือบริการจดจำเสียงพูดในอุปกรณ์

• [9.8/A-1-3] ต้องแสดงประกาศสำหรับผู้ใช้ใน UI ของระบบเมื่ออุปกรณ์ตรวจพบความตั้งใจของผู้ใช้ที่จะโต้ตอบกับแอปพลิเคชันผู้ช่วยดิจิทัล (เช่น ตรวจจับการปรากฏตัวของผู้ใช้ผ่านกล้อง)

• [9.8/A-1-4] ต้องแสดงตัวบ่งชี้ไมโครโฟนและแสดงคำค้นหาของผู้ใช้ที่ตรวจพบใน UI ทันทีหลังจากตรวจพบคำค้นหาของผู้ใช้

• [9.8/A-1-5] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้ ให้บริการตรวจหาคำค้นหาด้วยภาพ

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศ android.hardware.microphone, อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [9.8.2/A-1-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อ แอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทที่ระบุไว้ในส่วน 9.1 ที่มีตัวระบุ CDD [C-4-X] เข้าถึงไมโครโฟนเท่านั้น

• [9.8.2/A-1-2] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับ แอปของระบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง

• [9.8.2/A-1-3] ต้องมีส่วนควบคุมสำหรับผู้ใช้เพื่อเปิด/ปิด ไมโครโฟนในแอปการตั้งค่า

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศ android.hardware.camera.any, อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [9.8.2/A-2-1] ต้องแสดงสัญญาณบอกสถานะกล้องถ่ายรูปเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปเข้าถึงกล้องเฉพาะแอปที่มีบทบาทตามที่กำหนดไว้ในส่วนที่ 9.1 สิทธิ์ ที่มีตัวระบุ CDD [C-4-X]

• [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] ต้องสำรองข้อมูลการติดตั้งใช้งาน Keystore ด้วยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก

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

• [9.11/A-0-3] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อก ในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้เฉพาะเมื่อ สำเร็จเท่านั้น ต้องจัดเก็บข้อมูลเข้าสู่ระบบของหน้าจอล็อก ในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกจากกัน ทำการตรวจสอบสิทธิ์หน้าจอล็อกได้ Android Open Source Project ต้นทางมี Gatekeeper ระดับชั้นการจัดการฮาร์ดแวร์โดยตรง (HAL) และ Trusty ซึ่งใช้เพื่อตอบสนองข้อกำหนดนี้ได้

• [9.11/A-0-4] ต้องรองรับการรับรองคีย์ที่ คีย์การลงนามการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนาม ในฮาร์ดแวร์ที่ปลอดภัย ต้องป้องกันไม่ให้ใช้คีย์การลงนามการรับรองเป็นตัวระบุอุปกรณ์ถาวร

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

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

• [9.14/A-0-1] ต้องควบคุมข้อความ จากระบบย่อยของยานพาหนะในเฟรมเวิร์ก Android (เช่น อนุญาตประเภทข้อความและแหล่งที่มาของข้อความที่อนุญาต)

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

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

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

• Perfetto

  • [6.1/A-0-1] ต้องแสดง /system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ซึ่ง cmdline เป็นไปตาม เอกสารประกอบของ Perfetto

  • [6.1/A-0-2] ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า Protobuf เป็นอินพุตซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto

  • [6.1/A-0-3] ไบนารีของ Perfetto ต้องเขียนเป็น เอาต์พุตของร่องรอย Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ใน เอกสารประกอบของ Perfetto

  • [6.1/A-0-4] ต้องระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไบนารี Perfetto

  • [6.1/A-0-5] ต้องเปิดใช้ daemon ที่ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

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

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

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

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

2.6.1. ฮาร์ดแวร์

Gyroscope

หากการใช้งานอุปกรณ์แท็บเล็ตมีไจโรสโคปแบบ 3 แกน จะต้องมีคุณสมบัติดังนี้

• [7.3.4/Tab-1-1] ต้องวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที

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

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

โหมดความจริงเสมือน (ส่วนที่ 7.9.1)

ประสิทธิภาพสูงของ Virtual Reality (ส่วนที่ 7.9.2)

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

2.6.2. โมเดลความปลอดภัย

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

โปรดดูส่วน [9.11]

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

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

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

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

2.6.2. ซอฟต์แวร์

• [3.2.3.1/Tab-0-1] ต้องโหลดล่วงหน้าอย่างน้อย 1 แอปพลิเคชันหรือคอมโพเนนต์บริการที่มีตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงที่นี่

3. ซอฟต์แวร์

3.1 ความเข้ากันได้ของ Managed API

สภาพแวดล้อมการดำเนินการ Dalvik bytecode ที่มีการจัดการเป็นพาหนะหลักสำหรับ แอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือ ชุดอินเทอร์เฟซแพลตฟอร์ม 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 ทุกรายการในรายการที่ถูกจำกัดเดียวกันกับที่ระบุผ่านแฟล็กชั่วคราวและแฟล็กรายการที่ปฏิเสธในเส้นทาง prebuilts/runtime/appcompat/hiddenapi-flags.csv สำหรับสาขา ระดับ API ที่เหมาะสมใน AOSP

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

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

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

3.1.1. ส่วนขยาย Android

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

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

• [C-0-1] ต้องโหลดล่วงหน้าการใช้งาน AOSP ของทั้งไลบรารีที่ใช้ร่วมกัน ExtShared และบริการ ExtServices ที่มีเวอร์ชันมากกว่าหรือเท่ากับ เวอร์ชันขั้นต่ำที่อนุญาตต่อระดับ API แต่ละระดับ เช่น การติดตั้งใช้งานอุปกรณ์ Android 7.0 ที่ใช้ระดับ API 24 ต้องมีเวอร์ชัน 1 เป็นอย่างน้อย

• [C-0-2] ต้องแสดงเฉพาะหมายเลขเวอร์ชันของส่วนขยายที่ถูกต้องซึ่งกำหนดโดย AOSP

• [C-0-3] ต้องรองรับ API ทั้งหมดที่กำหนดโดยเวอร์ชันส่วนขยาย ที่ส่งคืนโดย android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) ในลักษณะเดียวกับการรองรับ API ที่มีการจัดการอื่นๆ ตามข้อกำหนดในส่วนที่ 3.1

3.1.2. ไลบรารี Android

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

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

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

3.2 ความเข้ากันได้ของ API แบบยืดหยุ่น

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

3.2.1. สิทธิ์

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

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

API ของ Android มีค่าคงที่หลายรายการใน คลาส android.os.Build ซึ่งมีไว้เพื่ออธิบายอุปกรณ์ปัจจุบัน

3.2.3. ความเข้ากันได้ของความตั้งใจ

3.2.3.1. Intent การสมัครที่พบบ่อย

Intent ของ Android ช่วยให้คอมโพเนนต์ของแอปพลิเคชันขอฟังก์ชันการทำงานจาก คอมโพเนนต์อื่นๆ ของ Android ได้ โปรเจ็กต์ต้นทางของ Android มีรายการแอปพลิเคชันที่ใช้รูปแบบ Intent หลายรูปแบบเพื่อดำเนินการทั่วไป

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

• [C-SR-1] ขอแนะนำอย่างยิ่งให้โหลดล่วงหน้าสำหรับแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการที่มีตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่ระบุไว้ที่นี่ และให้บริการตามคำขอ ซึ่งก็คือเป็นไปตามความคาดหวังของนักพัฒนาซอฟต์แวร์สำหรับ Intent ของแอปพลิเคชันทั่วไปเหล่านี้ตามที่อธิบายไว้ใน SDK

โปรดดูส่วนที่ 2 สำหรับ Intent ของแอปพลิเคชันที่จำเป็น สำหรับอุปกรณ์แต่ละประเภท

3.2.3.2. การแก้ปัญหา Intent

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

• [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่แนบสิทธิ์พิเศษกับการใช้รูปแบบ Intent เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สาม ผูกและควบคุมรูปแบบเหล่านี้ ข้อห้ามนี้ รวมถึงแต่ไม่จำกัดเพียงการปิดใช้ส่วนติดต่อผู้ใช้ "ตัวเลือก" ที่อนุญาตให้ผู้ใช้เลือกระหว่างแอปพลิเคชันหลายรายการที่ จัดการรูปแบบ 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 โดยทำตาม ขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล (Digital Asset Links) ตามที่เครื่องมือจัดการแพ็กเกจได้นำไปใช้ในโครงการโอเพนซอร์ส Android จากต้นน้ำ
• [C-0-5] ต้องพยายามตรวจสอบตัวกรอง Intent ในระหว่างการติดตั้ง แอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ URI ที่ตรวจสอบสำเร็จทั้งหมดเป็น ตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตัวกรองเหล่านั้น
• อาจตั้งค่าตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากได้รับการยืนยันสำเร็จ แต่ตัวกรอง URI อื่นๆ ที่เป็นตัวเลือกไม่ผ่าน การยืนยัน หากการใช้งานอุปกรณ์ทำเช่นนี้ อุปกรณ์จะต้องระบุการลบล้างรูปแบบต่อ URI ที่เหมาะสมของผู้ใช้ในเมนูการตั้งค่า
• ต้องให้การควบคุม App Link ต่อแอปแก่ผู้ใช้ในการตั้งค่าดังนี้
  • [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของ App Link เริ่มต้นของแอปโดยรวมเพื่อให้แอปมีลักษณะดังนี้ เปิดเสมอ ถามเสมอ หรือไม่เปิดเลย ซึ่งต้องใช้กับตัวกรอง Intent ของ URI ที่เป็นไปได้ทั้งหมดอย่างเท่าเทียมกัน
  • [C-0-7] ผู้ใช้ต้องดูรายการตัวกรอง Intent ของ URI ที่เป็นไปได้
  • การติดตั้งใช้งานอุปกรณ์อาจให้ผู้ใช้มีความสามารถในการ ลบล้างตัวกรอง Intent ของ URI ที่เป็นผู้สมัครที่เฉพาะเจาะจงซึ่งได้รับการยืนยัน เรียบร้อยแล้ว โดยอิงตามตัวกรอง Intent แต่ละรายการ
  • [C-0-8] การติดตั้งใช้งานอุปกรณ์ต้องให้ผู้ใช้สามารถดูและลบล้างตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงได้ หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงบางตัวผ่านการยืนยัน แต่ตัวกรองอื่นๆ อาจไม่ผ่าน

3.2.3.3. เนมสเปซของความตั้งใจ

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

3.2.3.4. Broadcast Intents

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

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

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

3.2.3.5. ความตั้งใจในการสมัครแบบมีเงื่อนไข

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 Intent เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น

• [C-2-2] ต้องปฏิบัติตามandroid.telecom.action.CHANGE_DEFAULT_DIALER ความตั้งใจที่จะแสดงกล่องโต้ตอบเพื่อให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์ เริ่มต้น

  • ต้องใช้ UI ของแอปโทรศัพท์เริ่มต้นที่ผู้ใช้เลือกสำหรับสายเรียกเข้าและ โทรออก ยกเว้นสายฉุกเฉินซึ่งจะใช้แอปโทรศัพท์ที่ ติดตั้งมาล่วงหน้า

• [C-2-3] ต้องปฏิบัติตามเจตนา android.telecom.action.CHANGE_PHONE_ACCOUNTS เพื่อมอบความสามารถให้ผู้ใช้กำหนดค่า ConnectionServices ที่เชื่อมโยงกับ PhoneAccounts รวมถึง PhoneAccount เริ่มต้นที่ผู้ให้บริการโทรคมนาคมจะใช้เพื่อโทรออก การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดย รวมเมนู "ตัวเลือกบัญชีการโทร" ไว้ในเมนูการตั้งค่า "การโทร"

• [C-2-4] ต้องอนุญาต android.telecom.CallRedirectionService สำหรับแอปที่มีบทบาท android.app.role.CALL_REDIRECTION

• [C-2-5] ต้องมีส่วนควบคุมสำหรับผู้ใช้เพื่อเลือกแอปที่มีบทบาท android.app.role.CALL_REDIRECTION

• [C-2-6] ต้องปฏิบัติตาม Intent android.intent.action.SENDTO และ android.intent.action.VIEW และจัดหากิจกรรมเพื่อส่ง/แสดงข้อความ SMS

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้ Intent android.intent.action.ANSWER android.intent.action.CALL android.intent.action.CALL_BUTTON android.intent.action.VIEW และ android.intent.action.DIAL กับแอปพลิเคชันโทรศัพท์ที่โหลดไว้ล่วงหน้าซึ่งสามารถจัดการ Intent เหล่านี้และ ให้การดำเนินการตามที่อธิบายไว้ใน SDK

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce จะมีลักษณะดังนี้

• [C-3-1] ต้องยอมรับ Intent android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการชำระเงินแบบไม่ต้องสัมผัส
• [C-3-2] ต้องปฏิบัติตาม Intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT เพื่อแสดงกิจกรรมที่เปิดกล่องโต้ตอบเพื่อขอให้ผู้ใช้เปลี่ยน บริการจำลองบัตรเริ่มต้นสำหรับหมวดหมู่หนึ่งๆ ตามที่อธิบายไว้ใน SDK

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc จะมีลักษณะดังนี้

• [C-4-1] ต้องปฏิบัติตาม Intent เหล่านี้ android.nfc.action.NDEF_DISCOVERED android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED เพื่อแสดงกิจกรรมที่ตรงกับความคาดหวังของนักพัฒนาซอฟต์แวร์สำหรับ Intent เหล่านี้ตามที่อธิบายไว้ใน SDK

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.bluetooth จะมีลักษณะดังนี้

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

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

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

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

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

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

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

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

• [C-9-1] ต้องใช้ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI API ของ Intent ตามที่อธิบายไว้ในเอกสารประกอบของ SDK

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

• [C-10-1] ต้องมีอินเทอร์เฟซผู้ใช้ในการตั้งค่าที่จัดการเจตนาของ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS เพื่อให้ผู้ใช้เพิ่มหรือนำแอปพลิเคชันออกจาก รายการที่อนุญาตได้

หากการติดตั้งใช้งานอุปกรณ์ไม่ได้มีโหมดประหยัดอินเทอร์เน็ต จะเกิดสิ่งต่อไปนี้

• [C-11-1] ต้องมีกิจกรรมที่จัดการ Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS แต่จะใช้เป็น no-op ก็ได้

หากการใช้งานอุปกรณ์ประกาศการรองรับกล้องผ่าน android.hardware.camera.any จะมีข้อกำหนดดังนี้

• [C-12-3] ต้องจัดการและอนุญาตเฉพาะแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้า เพื่อจัดการ Intent ต่อไปนี้ MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE และ MediaStore.ACTION_VIDEO_CAPTURE ตามที่อธิบายไว้ในเอกสาร SDK

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin จะมีลักษณะดังนี้

• [C-13-1] ต้องปฏิบัติตาม Intent android.app.action.ADD_DEVICE_ADMIN เพื่อเรียกใช้ UI เพื่อนำผู้ใช้ไปสู่การเพิ่มผู้ดูแลระบบอุปกรณ์ลงใน ระบบ (หรืออนุญาตให้ผู้ใช้ปฏิเสธได้)

• [C-13-2] ต้องดำเนินการตาม Intent android.app.action.PROVISION_MANAGED_PROFILE android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION และมีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบาย ใน SDK ที่นี่

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

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

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

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

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

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

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

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

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

• [C-18-1] ต้องปฏิบัติตามandroid.settings.ACTION_VOICE_INPUT_SETTINGS เจตนาที่จะแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการป้อนข้อมูลด้วยเสียงและการช่วยเหลือ

หากการใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output, อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-SR-3] ขอแนะนำอย่างยิ่งให้ปฏิบัติตาม Intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT โดยมีกิจกรรมเพื่อให้บริการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่

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

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

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.uicc หรือ android.hardware.nfc.ese อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

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

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

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

• [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 Activities ปกติบนจอแสดงผลรองและจอแสดงผลรองมีแฟล็ก 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 ที่คั่นด้วยคอมมา ซึ่งเรียงจาก ABI ที่ต้องการมากที่สุดไปน้อยที่สุด

• [C-0-6] ต้องรายงานผ่านพารามิเตอร์ข้างต้น ซึ่งเป็นชุดย่อยของรายการ ABI ต่อไปนี้ และต้องไม่รายงาน ABI ที่ไม่ได้อยู่ในรายการ

  • armeabi (NDK ไม่รองรับเป็นเป้าหมายอีกต่อไป)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64
  • riscv64

• [C-0-7] ต้องทำให้ไลบรารีต่อไปนี้ทั้งหมดซึ่งมี API เนทีฟ พร้อมใช้งานสำหรับแอปที่มีโค้ดแบบเนทีฟ

  • libaaudio.so (การรองรับเสียงดั้งเดิมของ AAudio)
  • 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 (Neural Networks API)
  • libOpenMAXAL.so (รองรับ OpenMAX AL 1.0.1)
  • libOpenSLES.so (รองรับเสียง OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (รองรับ C++ ขั้นต่ำ)
  • libvulkan.so (Vulkan)
  • libz (การบีบอัด Zlib)
  • อินเทอร์เฟซ JNI

• [C-0-8] ต้องไม่เพิ่มหรือนำฟังก์ชันสาธารณะสำหรับไลบรารีเนทีฟ ที่ระบุไว้ข้างต้นออก

• [C-0-9] ต้องแสดงรายการไลบรารีที่ไม่ใช่ AOSP เพิ่มเติมที่เปิดเผยต่อแอปของบุคคลที่สามโดยตรงใน /vendor/etc/public.libraries.txt

• [C-0-10] ต้องไม่เปิดเผยไลบรารีเนทีฟอื่นๆ ที่มีการติดตั้งใช้งานและ จัดไว้ให้ใน AOSP เป็นไลบรารีของระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมาย API ระดับ 24 ขึ้นไป เนื่องจากมีการสงวนไว้

• [C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชันทั้งหมดของ OpenGL ES 3.1 และ Android Extension Pack ตามที่กำหนดไว้ใน NDK ผ่านไลบรารี libGLESv3.so โปรดทราบว่าแม้ว่าสัญลักษณ์ทั้งหมดจะต้องมีอยู่ แต่ส่วน 7.1.4.1 จะอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับข้อกำหนดเมื่อคาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละฟังก์ชันอย่างเต็มรูปแบบ

• [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับฟังก์ชันหลักของ Vulkan 1.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 มีไว้เพื่อความเข้ากันได้แบบย้อนหลังกับแอปเก่าเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ armeabi-v7a ABI สำหรับแอป ที่ใช้ 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 17 สำหรับการใช้งาน android.webkit.WebView API

• [C-1-3] สตริง User-Agent ที่รายงานโดย WebView สำหรับแอปที่กำหนดเป้าหมายเป็นระดับ SDK 35 และต่ำกว่า ต้องอยู่ในรูปแบบต่อไปนี้

  Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ android.os.Build.VERSION.RELEASE

  • สตริง $(MODEL) อาจว่างเปล่า แต่หากไม่ว่างเปล่า สตริงนี้ต้องมีค่าเดียวกับ android.os.Build.MODEL

  • อาจละเว้น "Build/$(BUILD)" ได้ แต่หากมีอยู่ $(BUILD) สตริงต้องเหมือนกับค่าของ android.os.Build.ID

  • ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในโครงการโอเพนซอร์ส Android ต้นทาง

  • การติดตั้งใช้งานอุปกรณ์อาจละเว้น "Mobile" ในสตริง User Agent

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

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

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

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

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

• [C-1-1] ต้องรองรับ API แต่ละรายการต่อไปนี้ที่เชื่อมโยงกับ HTML5

  • แคชของแอปพลิเคชัน/การทำงานแบบออฟไลน์
  • แท็ก <video>
  • ตำแหน่งทางภูมิศาสตร์

• [C-1-2] ต้องรองรับ Web Storage API ของ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากหน่วยงานมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ IndexedDB แทน Web Storage จึงคาดว่า IndexedDB จะกลายเป็น คอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันอนาคต

• อาจจัดส่งสตริง User Agent ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน

• ควรใช้การรองรับ HTML5 ให้มากที่สุดเท่าที่จะเป็นไปได้ในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit ต้นทางหรือการแทนที่ของบุคคลที่สาม)

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

• [C-2-1] ต้องยังคงรองรับรูปแบบความตั้งใจสาธารณะตามที่อธิบายไว้ในส่วน 3.2.3.1

3.5 ความเข้ากันได้ของลักษณะการทำงานของ API

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

• [C-0-9] ต้องตรวจสอบว่ามีการใช้ความเข้ากันได้ของลักษณะการทำงานของ API กับแอปที่ติดตั้งทั้งหมด เว้นแต่จะมีการจำกัดตามที่อธิบายไว้ในส่วน 3.5.1
• [C-0-10] ต้องไม่ใช้วิธีการรายการที่อนุญาตที่รับประกันความเข้ากันได้เชิงพฤติกรรมของ API เฉพาะสำหรับแอปที่ผู้ติดตั้งใช้งานอุปกรณ์ เลือก

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

• [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทำงานหรือความหมายของ Intent มาตรฐาน
• [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจร ของคอมโพเนนต์ระบบประเภทใดประเภทหนึ่ง (เช่น บริการ กิจกรรม ContentProvider ฯลฯ)
• [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
• อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันที่ทำงานในเบื้องหลัง กล่าวโดยละเอียดคือ สำหรับแอปที่ทำงานในเบื้องหลัง ให้ทำดังนี้
  • [C-0-4] ต้องหยุดการเรียกกลับที่แอปจดทะเบียนไว้เพื่อรับเอาต์พุตจาก 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 ขึ้นไป แอปต้อง ปล่อย Wake Lock ที่แอปถืออยู่
• [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. AndroidKeyStoreBCWorkaround - 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 (AOSP) หากเป็นไปได้ แทนที่จะติดตั้งใช้งานส่วนสำคัญของระบบอีกครั้ง

3.5.1. การจำกัดแอปพลิเคชัน

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

• [C-1-1] ต้องอนุญาตให้ผู้ใช้ดูรายการแอปที่ถูกจำกัด
• [C-1-2] ต้องมีตัวเลือกให้ผู้ใช้เปิด / ปิดข้อจำกัดที่เป็นกรรมสิทธิ์ทั้งหมดเหล่านี้ ในแต่ละแอป

• [C-1-3] ต้องไม่ใช้ข้อจำกัดที่เป็นกรรมสิทธิ์เหล่านี้โดยอัตโนมัติหากไม่มีหลักฐานว่าระบบมีพฤติกรรมที่ส่งผลเสียต่อสุขภาพของระบบ แต่สามารถใช้ข้อจำกัดกับแอปได้เมื่อตรวจพบพฤติกรรมที่ส่งผลเสียต่อสุขภาพของระบบ เช่น Wake Lock ที่ค้างอยู่ บริการที่ทำงานเป็นเวลานาน และเกณฑ์อื่นๆ ผู้ติดตั้งใช้งานอุปกรณ์อาจกำหนดเกณฑ์ แต่ต้องเกี่ยวข้องกับผลกระทบของแอปต่อสถานะของระบบ ห้ามใช้เกณฑ์อื่นๆ ที่ไม่ได้เกี่ยวข้องกับสุขภาพของระบบโดยตรง เช่น ความไม่นิยมของแอปในตลาด เป็นเกณฑ์

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

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

• [C-1-6] ต้องแสดงผลเป็นจริงสำหรับเมธอด ActivityManager.isBackgroundRestricted() สำหรับการเรียก API จากแอป

• [C-1-7] ต้องไม่จำกัดแอปที่ทำงานอยู่เบื้องหน้าด้านบนสุดซึ่งผู้ใช้ใช้โดยชัดแจ้ง

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

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

  • เงื่อนไขที่ทำให้เกิดข้อจำกัดที่เป็นกรรมสิทธิ์
  • สิ่งที่สามารถจำกัดได้และวิธีจำกัดแอป
  • วิธียกเว้นแอปจากข้อจำกัดดังกล่าว
  • วิธีที่แอปจะขอรับการยกเว้นจากข้อจำกัดที่เป็นกรรมสิทธิ์ได้ หากแอป รองรับการยกเว้นดังกล่าวสำหรับแอปที่ผู้ใช้ติดตั้งได้

หากมีการติดตั้งแอปไว้ล่วงหน้าในอุปกรณ์และผู้ใช้ไม่เคยใช้แอปอย่างชัดเจนนานกว่า 30 วัน ระบบจะยกเว้น [C-1-3] [C-1-5]

หากการใช้งานอุปกรณ์ขยายข้อจำกัดของแอปที่ใช้งานใน AOSP จะมีลักษณะดังนี้

• [C-2-1]ต้องทําตามการติดตั้งใช้งานที่อธิบายไว้ในเอกสารนี้

3.5.2. การพักใช้งานแอปพลิเคชัน

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

• [C-1-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดในส่วนที่ 3.5.1 ยกเว้น [C-1-6] และ [C-1-3]
• [C-1-2] ต้องใช้ข้อจำกัดกับแอปสำหรับผู้ใช้เฉพาะในกรณีที่มี หลักฐานว่าผู้ใช้ไม่ได้ใช้แอปเป็นระยะเวลาหนึ่ง เราขอแนะนำเป็นอย่างยิ่งให้ระยะเวลานี้เป็น 1 เดือนขึ้นไป การใช้งานต้องกำหนดโดยการโต้ตอบของผู้ใช้โดยชัดแจ้งผ่าน API UsageStats#getLastTimeVisible() หรือสิ่งใดก็ตามที่จะทําให้แอปออกจากสถานะหยุดทำงานโดยบังคับ ซึ่งรวมถึงการเชื่อมโยงบริการ การเชื่อมโยง Content Provider การออกอากาศโดยชัดแจ้ง ฯลฯ ซึ่งจะติดตามโดย API ใหม่ UsageStats#getLastTimeAnyComponentUsed()
• [C-1-3] ต้องใช้ข้อจำกัดที่ส่งผลต่อผู้ใช้อุปกรณ์ทั้งหมดเมื่อมีหลักฐานว่าไม่มีผู้ใช้ใช้แพ็กเกจเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้ระยะเวลานี้เป็น 1 เดือนขึ้นไป
• [C-1-4] ต้องไม่ทําให้แอปไม่สามารถตอบสนองต่อ Intent ของกิจกรรม การเชื่อมโยงบริการ คําขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่ชัดเจน

การพักแอปใน AOSP เป็นไปตามข้อกำหนดข้างต้น

3.6 เนมสเปซของ API

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

• java.*
• javax.*
• sun.*
• android.*
• androidx.*
• com.android.*

กล่าวคือ

• [C-0-1] ต้องไม่แก้ไข API ที่เปิดเผยต่อสาธารณะในแพลตฟอร์ม Android โดยการเปลี่ยนลายเซ็นของเมธอดหรือคลาส หรือโดยการนำคลาสหรือฟิลด์คลาส ออก
• [C-0-2] ต้องไม่เพิ่มองค์ประกอบที่เปิดเผยต่อสาธารณะ (เช่น คลาสหรืออินเทอร์เฟซ หรือฟิลด์หรือเมธอดไปยังคลาสหรืออินเทอร์เฟซที่มีอยู่) หรือ Test หรือ System API ไปยัง API ในเนมสเปซข้างต้น "องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือโครงสร้างใดๆ ที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง

ผู้ติดตั้งใช้งานอุปกรณ์อาจแก้ไขการติดตั้งใช้งานพื้นฐานของ API แต่ การแก้ไขดังกล่าวต้องเป็นไปตามข้อกำหนดต่อไปนี้

• [C-0-3] ต้องไม่ส่งผลต่อลักษณะการทำงานที่ระบุและลายเซ็นภาษา Java ของ API ที่เปิดเผยต่อสาธารณะ
• [C-0-4] ต้องไม่ได้รับการโฆษณาหรือเปิดเผยต่อผู้พัฒนา

อย่างไรก็ตาม ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กำหนดเองนอกเนมสเปซ Android มาตรฐานได้ แต่ API ที่กำหนดเองต้องมีคุณสมบัติดังนี้

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

ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กำหนดเองในภาษาเนทีฟภายนอก NDK API แต่ API ที่กำหนดเองต้องมีลักษณะดังนี้

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

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

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

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

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

• [C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) ทั้งหมด และข้อกำหนดและความหมายของ Dalvik bytecode

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

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

• ควรเรียกใช้การทดสอบแบบฟัซภายใต้โหมดการดำเนินการต่างๆ และสถาปัตยกรรมเป้าหมายเพื่อให้มั่นใจในความเสถียรของรันไทม์ ดูข้อมูลเพิ่มเติมได้ที่ JFuzz และ DexFuzz ในเว็บไซต์โครงการโอเพนซอร์ส Android

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

เลย์เอาต์หน้าจอ	ความหนาแน่นของหน้าจอ	หน่วยความจำแอปพลิเคชันขั้นต่ำ
Android Watch	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)	512 MB
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 ของ ShortcutManager จะมีลักษณะดังนี้

• [C-4-1] ต้องรองรับฟีเจอร์ทางลัดทั้งหมดที่ระบุไว้ในเอกสาร (เช่น ทางลัดแบบคงที่และแบบไดนามิก การปักหมุดทางลัด) และใช้ API ของคลาส ShortcutManager API อย่างเต็มรูปแบบ

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

• [C-5-1] ต้องปฏิบัติตามเมธอด API NotificationChannel.setShowBadge() กล่าวคือ แสดงความสามารถในการมองเห็นที่เชื่อมโยงกับไอคอนแอปหากตั้งค่าเป็น true และไม่แสดงรูปแบบการติดป้ายไอคอนแอปเมื่อช่องการแจ้งเตือนทั้งหมดของแอปตั้งค่าเป็น false

• อาจลบล้างป้ายไอคอนแอปด้วยรูปแบบการติดป้ายของตนเองเมื่อ แอปพลิเคชันของบุคคลที่สามระบุว่ารองรับรูปแบบการติดป้ายของตนเอง ผ่านการใช้ API ที่เป็นกรรมสิทธิ์ แต่ควรใช้ทรัพยากรและค่า ที่ระบุผ่าน API ป้ายการแจ้งเตือนที่อธิบายไว้ใน SDK เช่น API Notification.Builder.setNumber() และ Notification.Builder.setBadgeIconType()

หากการใช้งานอุปกรณ์รองรับไอคอน ขาวดำ ไอคอนเหล่านี้จะ

• [C-6-1] ต้องใช้เฉพาะเมื่อผู้ใช้เปิดใช้โดยชัดแจ้ง (เช่น ผ่านเมนูการตั้งค่าหรือเครื่องมือเลือกวอลเปเปอร์)

3.8.2. วิดเจ็ต

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

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

• อาจรองรับวิดเจ็ตแอปพลิเคชันในหน้าจอล็อก

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

• [C-2-1] ต้องรายงาน true สำหรับ AppWidgetManager.html.isRequestPinAppWidgetSupported()

• [C-2-2] ต้องมีส่วนที่ผู้ใช้โต้ตอบได้ซึ่งจะขอให้ผู้ใช้ดำเนินการก่อนเพิ่มทางลัด ที่แอปขอผ่านAppWidgetManager.requestPinAppWidget() วิธีการ API

3.8.3. การแจ้งเตือน

Android มี API Notification และ NotificationManager ที่ช่วยให้นักพัฒนาแอปบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญและ ดึงดูดความสนใจของผู้ใช้โดยใช้คอมโพเนนต์ฮาร์ดแวร์ (เช่น เสียง การสั่น และแสง) และฟีเจอร์ซอฟต์แวร์ (เช่น หน้าต่างแจ้งเตือน แถบระบบ) ของ อุปกรณ์

3.8.3.1. การนำเสนอการแจ้งเตือน

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

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

• [C-1-2] ต้องแสดงทรัพยากร (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ทั้งหมดที่ระบุไว้ใน API หรือในคู่มือรูปแบบไอคอนแถบสถานะ/ระบบอย่างถูกต้อง แม้ว่าอาจมอบประสบการณ์ของผู้ใช้ทางเลือกสำหรับการแจ้งเตือน ที่แตกต่างจากที่ระบุไว้ในการใช้งาน Android Open Source อ้างอิง

• [C-1-3] ต้องปฏิบัติตามและใช้ลักษณะการทำงานที่อธิบายไว้สำหรับ API เพื่ออัปเดต นำออก และจัดกลุ่มการแจ้งเตือนอย่างถูกต้อง

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

• ควรรองรับการแจ้งเตือนสมบูรณ์

• ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า

• ควรมีตัวเลือกให้ผู้ใช้เลื่อนการแจ้งเตือน

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

Android 11 เปิดตัวการรองรับการแจ้งเตือนการสนทนา ซึ่งเป็นการแจ้งเตือนที่ใช้ MessagingStyle และมีรหัสทางลัดผู้ติดต่อ ที่เผยแพร่

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

• [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] ต้องใช้มุมมองและการแจ้งเตือนล่วงหน้าและทรัพยากร ตามที่อธิบายไว้ในคลาส API ของ Notification.Builder เมื่อมีการแสดงการแจ้งเตือนล่วงหน้า

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

3.8.3.2. บริการ Listener การแจ้งเตือน

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

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

• [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงที ไปยังบริการ Listener ที่ติดตั้งและผู้ใช้เปิดใช้ทั้งหมด รวมถึงข้อมูลเมตาทั้งหมด ที่แนบมากับออบเจ็กต์การแจ้งเตือน

• [C-0-2] ต้องปฏิบัติตามการเรียก API ของ snoozeNotification() และปิดการแจ้งเตือนและเรียกใช้ฟังก์ชันเรียกกลับหลังจากระยะเวลาการเลื่อนที่ตั้งค่าไว้ในการเรียก API

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

• [C-1-1] ต้องแสดงสถานะการเลื่อนการแจ้งเตือนอย่างถูกต้อง ผ่าน API มาตรฐาน เช่น NotificationListenerService.getSnoozedNotifications()

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

3.8.3.3. โหมด DND (ห้ามรบกวน) / โหมดลำดับความสำคัญ

หากการใช้งานอุปกรณ์รองรับฟีเจอร์ห้ามรบกวน (หรือที่เรียกว่าโหมดสำคัญ) อุปกรณ์จะทำสิ่งต่อไปนี้

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

• [C-1-3] ต้องใช้ค่าของ suppressedVisualEffects ที่ส่งมาพร้อมกับ NotificationManager.Policy และหากแอปตั้งค่าแฟล็ก SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON ใดไว้ แอปควรระบุให้ผู้ใช้ทราบว่าระบบจะระงับเอฟเฟกต์ภาพในเมนูการตั้งค่าโหมดห้ามรบกวน

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

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

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

• [C-1-1] ต้องปกปิดข้อมูลการแจ้งเตือนที่ละเอียดอ่อนไม่ให้ส่งไปยัง เครื่องมือฟังการแจ้งเตือน เว้นแต่บริการเครื่องมือฟังจะเป็นอย่างใดอย่างหนึ่งต่อไปนี้

  • แอปที่ระบบลงนามซึ่งมี uid < 10000
  • UI ของระบบ
  • เปลือกหอย
  • แอปอุปกรณ์ที่ใช้ร่วมกันที่กำหนด (กำหนดโดย CompanionDeviceManager)
  • บทบาท SYSTEM_AUTOMOTIVE_PROJECTION
  • บทบาท SYSTEM_NOTIFICATION_INTELLIGENCE
  • บทบาท HOME

การติดตั้งใช้งาน AOSP ของ NotificationAssistantServices แสดงให้เห็นและเป็นไปตามข้อกำหนดเหล่านี้ ดูตัวอย่างได้ที่ android.ext.services.notification

3.8.4. Assist APIs

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

• [C-2-2] การโต้ตอบที่กำหนดเพื่อเปิดใช้แอปผู้ช่วยตามที่อธิบายไว้ ในส่วน 7.2.3 ต้องเปิดใช้แอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้VoiceInteractionService หรือกิจกรรมที่จัดการ Intent ACTION_ASSIST

3.8.5. การแจ้งเตือนและข้อความป๊อปอัป

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

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

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

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

3.8.6. ธีม

Android มี "ธีม" เป็นกลไกให้แอปพลิเคชันใช้สไตล์ใน Activity หรือแอปพลิเคชันทั้งหมด

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

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

• [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดงต่อแอปพลิเคชัน

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

• [C-1-3] ต้องตั้งค่าชุดแบบอักษร "Sans Serif" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือให้ผู้ใช้เปลี่ยนแบบอักษรที่ใช้สำหรับชุดแบบอักษร "Sans Serif" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ

• [C-1-4] ต้องสร้างชุดสีแบบไดนามิกตามที่ระบุไว้ในเอกสารประกอบ AOSP ของ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ดู android.theme.customization.system_palette และ android.theme.customization.theme_style)

• [C-1-5] ต้องสร้างชุดสีแบบโทนสีแบบไดนามิกโดยใช้รูปแบบธีมสี ที่ระบุไว้ในเอกสารประกอบ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ดู android.theme.customization.theme_styles) ซึ่งได้แก่ TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD และ 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 รวมถึงวงจรที่เกี่ยวข้องซึ่งอนุญาตให้แอปพลิเคชันแสดง"วอลเปเปอร์เคลื่อนไหว"อย่างน้อย 1 รายการต่อผู้ใช้ปลายทาง วอลเปเปอร์เคลื่อนไหวคือภาพเคลื่อนไหว ลวดลาย หรือรูปภาพที่คล้ายกัน ซึ่งมีความสามารถในการป้อนข้อมูลที่จำกัดซึ่งจะแสดงเป็นวอลเปเปอร์อยู่เบื้องหลังแอปพลิเคชันอื่นๆ

ระบบจะถือว่าฮาร์ดแวร์มีความสามารถในการเรียกใช้วอลเปเปอร์ภาพเคลื่อนไหวได้อย่างน่าเชื่อถือ หากฮาร์ดแวร์นั้นเรียกใช้ วอลเปเปอร์ภาพเคลื่อนไหวทั้งหมดได้โดยไม่มีข้อจำกัดด้านฟังก์ชันการทำงานที่อัตราเฟรมที่เหมาะสม โดยไม่มีผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดใน ฮาร์ดแวร์ทำให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้ CPU หรือพลังงานแบตเตอรี่มากเกินไป หรือทำงานที่อัตราเฟรมต่ำเกินไปจนรับไม่ได้ ระบบจะถือว่าฮาร์ดแวร์ไม่สามารถเรียกใช้วอลเปเปอร์เคลื่อนไหวได้ ตัวอย่างเช่น วอลเปเปอร์เคลื่อนไหวบางรายการอาจใช้บริบท OpenGL 2.0 หรือ 3.x เพื่อแสดงเนื้อหา วอลเปเปอร์เคลื่อนไหวจะทำงานบนฮาร์ดแวร์ที่ไม่รองรับบริบท OpenGL หลายรายการไม่ได้เนื่องจากวอลเปเปอร์เคลื่อนไหวที่ใช้บริบท OpenGL อาจขัดแย้งกับแอปพลิเคชันอื่นๆ ที่ใช้บริบท OpenGL ด้วย

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

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

• [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ของแพลตฟอร์ม android.software.live_wallpaper

3.8.8. การสลับกิจกรรม

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

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

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

• [C-1-1] ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 7 รายการ

• ควรแสดงชื่อกิจกรรมอย่างน้อย 4 รายการพร้อมกัน

• ควรแสดงสีไฮไลต์ ไอคอน ชื่อหน้าจอในรายการล่าสุด

• ควรแสดงความสามารถในการปิด ("x") แต่อาจเลื่อนเวลาจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ

• ควรใช้ทางลัดเพื่อเปลี่ยนไปใช้กิจกรรมก่อนหน้าได้อย่างง่ายดาย

• ควรเรียกใช้การดำเนินการสลับอย่างรวดเร็วระหว่างแอป 2 รายการที่ใช้ล่าสุด เมื่อแตะแป้นฟังก์ชัน "ล่าสุด" 2 ครั้ง

• ควรเรียกใช้โหมดหลายหน้าต่างแบบแยกหน้าจอ หากรองรับ เมื่อกดปุ่มฟังก์ชัน ล่าสุดค้างไว้

• อาจแสดงรายการล่าสุดที่เกี่ยวข้องเป็นกลุ่มที่เลื่อนไปพร้อมกัน

• [C-SR-1] ขอแนะนําอย่างยิ่งให้ใช้อินเทอร์เฟซผู้ใช้ Android ต้นทาง (หรืออินเทอร์เฟซที่คล้ายกันซึ่งอิงตามภาพขนาดย่อ) สําหรับหน้าจอภาพรวม

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

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

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

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

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

เราเลิกใช้งาน Remote Control Client API ตั้งแต่ Android 5.0 เพื่อให้ใช้ เทมเพลตการแจ้งเตือนสื่อ แทน ซึ่งช่วยให้แอปพลิเคชันสื่อผสานรวมกับตัวควบคุมการเล่นที่ แสดงบนหน้าจอล็อกได้

3.8.11. ภาพพักหน้าจอ (เดิมคือดรีม)

ดูการตั้งค่าในส่วน 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 ทั้งหมดของละติน กรีก และซีริลลิก ซึ่งรวมถึงช่วงละตินเพิ่มเติม A, B, C และ D และอักขระทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0

• [C-1-3] ต้องไม่นำ NotoColorEmoji.tff ออกหรือแก้ไขในอิมเมจระบบ (คุณเพิ่มแบบอักษรอีโมจิใหม่เพื่อลบล้างอีโมจิใน NotoColorEmoji.tff ได้)

• ควรรองรับอีโมจิสีผิวและอีโมจิครอบครัวที่หลากหลายตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51

หากการติดตั้งใช้งานอุปกรณ์มี IME จะต้องมีคุณสมบัติดังนี้

• ควรมีวิธีการป้อนข้อมูลสำหรับอักขระอีโมจิเหล่านี้ให้แก่ผู้ใช้

Android รองรับการแสดงผลแบบอักษรเมียนมา เมียนมามีแบบอักษรหลายแบบที่ไม่เป็นไปตามมาตรฐาน Unicode ซึ่งมักเรียกว่า "Zawgyi" สำหรับการแสดงภาษาเมียนมา

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

• [C-2-1] ต้องแสดงข้อความด้วยแบบอักษรที่เป็นไปตามข้อกำหนดของ Unicode เป็นค่าเริ่มต้น ห้ามตั้งค่าแบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode เป็นแบบอักษรเริ่มต้น เว้นแต่ผู้ใช้ จะเลือกในเครื่องมือเลือกภาษา

• [C-2-2] ต้องรองรับแบบอักษร Unicode และแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode หากอุปกรณ์รองรับแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode แบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode ต้องไม่นำแบบอักษร Unicode ออกหรือเขียนทับ

• [C-2-3] ต้องแสดงข้อความด้วยแบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode ก็ต่อเมื่อมีการระบุรหัสภาษาที่มีรหัสสคริปต์ Qaag (เช่น my-Qaag) ห้ามใช้รหัสภาษาหรือภูมิภาค ISO อื่นๆ (ไม่ว่าจะมีการกำหนด ไม่มีการกำหนด หรือสงวนไว้) เพื่ออ้างอิงแบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode สำหรับภาษาพม่า นักพัฒนาแอปและผู้เขียนหน้าเว็บสามารถระบุ my-Qaag เป็นรหัสภาษาที่กำหนดได้เช่นเดียวกับภาษาอื่นๆ

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

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

• [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตาม ลักษณะการทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ใน Android SDK เอกสารประกอบการรองรับโหมดหลายหน้าต่าง และเป็นไปตามข้อกำหนดต่อไปนี้

• [C-1-2] นำข้อกำหนดออกใน Android 16

• [C-1-3] ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดอิสระหาก ความสูงของหน้าจอน้อยกว่า 440 dp และความกว้างของหน้าจอน้อยกว่า 440 dp

• [C-1-4] ต้องไม่ปรับขนาดกิจกรรมให้เล็กกว่า 220 dp ในโหมดหลายหน้าต่างที่ไม่ใช่โหมดภาพในภาพ

• การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ xlarge ควร รองรับโหมดอิสระ

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

• [C-2-2] ต้องครอบตัดกิจกรรมที่ตรึงของมัลติวินโดว์แบบแยกหน้าจอ แต่ควรแสดงเนื้อหาบางส่วนของกิจกรรมนั้น หากแอป Launcher เป็นหน้าต่างที่โฟกัส

• [C-2-3] ต้องปฏิบัติตามค่าที่ประกาศของ AndroidManifestLayout_minWidth และ AndroidManifestLayout_minHeight แอปพลิเคชันตัวเรียกใช้ของบุคคลที่สาม และไม่ลบล้างค่าเหล่านี้ ในระหว่างการแสดงเนื้อหาบางอย่างของกิจกรรมที่เชื่อมต่อ

หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดหลายหน้าต่างแบบ Picture-in-Picture อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-3-1] ต้องเปิดใช้กิจกรรมในโหมดหลายหน้าต่างแบบการแสดงภาพซ้อนภาพ เมื่อแอปอยู่ในสถานะต่อไปนี้

  • กำหนดเป้าหมาย API ระดับ 26 ขึ้นไปและประกาศ android:supportsPictureInPicture

  • กำหนดเป้าหมาย API ระดับ 25 หรือต่ำกว่า และประกาศทั้ง android:resizeableActivity และ android:supportsPictureInPicture

• [C-3-2] ต้องแสดงการดำเนินการใน SystemUI ตามที่กิจกรรม PIP ปัจจุบันระบุผ่าน API setActions()

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

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

• [C-4-1] ต้องรองรับโหมดหลายหน้าต่าง

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

• [C-5-1] ต้องใช้ API ระดับส่วนขยาย Window Manager เวอร์ชันที่ถูกต้องตามที่อธิบายไว้ในWindowManager ส่วนขยาย

3.8.15. คัตเอาท์ดิสเพลย์

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

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

• [C-1-5] ต้องไม่มีรอยบากหากสัดส่วนภาพของอุปกรณ์เป็น 1.0 (1:1)

• [C-1-2] ต้องมีรอยบากไม่เกิน 1 รอยต่อขอบ

• [C-1-3] ต้องปฏิบัติตาม Flag หน้าจอรอยบากที่แอปตั้งค่าผ่าน WindowManager.LayoutParams API ตามที่อธิบายไว้ใน SDK

• [C-1-4] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการตัดออกทั้งหมดที่กำหนดไว้ใน DisplayCutout API

3.8.16. ระบบควบคุมอุปกรณ์

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

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 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.8.18. ปุ่มตำแหน่ง

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

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

3.9.1. การจัดสรรอุปกรณ์

3.9.1.1. การจัดสรรอุปกรณ์ของเจ้าของ

หากการใช้งานอุปกรณ์ประกาศ android.software.device_admin จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องรองรับการลงทะเบียนเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) เป็นแอปเจ้าของอุปกรณ์ ตามที่อธิบายไว้ด้านล่าง

  • เมื่อการติดตั้งใช้งานอุปกรณ์ ไม่ได้กำหนดค่าผู้ใช้หรือ ข้อมูลผู้ใช้ ระบบจะดำเนินการต่อไปนี้

    • [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะ เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ หากอุปกรณ์ประกาศการรองรับ Near-Field Communications (NFC) ผ่าน แฟล็กฟีเจอร์ android.hardware.nfc และได้รับข้อความ NFC ที่มีระเบียนที่มีประเภท MIME เป็น MIME_TYPE_PROVISIONING_NFC

    • [C-1-8] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากทริกเกอร์การจัดสรรผู้เป็นเจ้าของอุปกรณ์ เพื่อให้แอป DPC เลือกได้ว่าจะเป็นผู้เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ โดยขึ้นอยู่กับค่าของ android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES เว้นแต่จะพิจารณาจากบริบทได้ว่ามีตัวเลือกที่ใช้ได้เพียงตัวเลือกเดียว

    • [C-1-9] ต้องส่ง Intent ACTION_ADMIN_POLICY_COMPLIANCE ไปยังแอป Device Owner หากมีการสร้าง Device Owner ในระหว่างการจัดสรร ไม่ว่าวิธีการจัดสรรที่ใช้จะเป็นอะไรก็ตาม ผู้ใช้ต้องไม่สามารถดำเนินการต่อในวิซาร์ดการตั้งค่าจนกว่าแอป เจ้าของอุปกรณ์จะเสร็จสิ้น

  • เมื่อการติดตั้งใช้งานอุปกรณ์มีผู้ใช้หรือ ข้อมูลผู้ใช้ ระบบจะดำเนินการต่อไปนี้

    • [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ อีกต่อไป

• [C-1-2] นำข้อกำหนดออกใน Android 15

• [C-2-1] ข้อกำหนดถูกนำออกใน Android 15

• [C-2-2] นำข้อกำหนดออกใน Android 15

• [C-2-3] ข้อกำหนดถูกนำออกใน Android 15

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

หากการใช้งานอุปกรณ์ประกาศ android.software.managed_users จะมีข้อกำหนดดังนี้

• [C-1-1] ต้อง ประกาศ android.software.device_admin และ ใช้ API ที่อนุญาตให้แอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) กลายเป็น เจ้าของโปรไฟล์ที่มีการจัดการใหม่

• [C-1-2] นำข้อกำหนดออกใน Android 16

• [C-1-3] ต้องมีสิ่งอำนวยความสะดวกสำหรับผู้ใช้ต่อไปนี้ในการตั้งค่าเพื่อ ระบุให้ผู้ใช้ทราบเมื่อเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ปิดใช้ฟังก์ชันระบบหนึ่งๆ

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

• [C-1-4] ต้องเปิดตัวแฮนเดิลสําหรับ ACTION_PROVISIONING_SUCCESSFUL Intent ในโปรไฟล์งานหากมีการสร้างเจ้าของโปรไฟล์เมื่อ มีการเริ่มการจัดสรรโดย Intent 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] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากทริกเกอร์การจัดสรรเจ้าของโปรไฟล์ เพื่อให้แอป DPC เลือกได้ว่าจะกลายเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ยกเว้นในกรณีที่ Intent android.app.action.PROVISION_MANAGED_PROFILE เป็นตัวทริกเกอร์การจัดสรร

• [C-1-7] ต้องส่ง Intent 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 Controller เปิดใช้

• [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 จะมีข้อกำหนดดังนี้

• [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 จะมีข้อกำหนดดังนี้

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

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

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

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

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

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

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

3.12. ไม่มี

3.13 การตั้งค่าด่วน

Android มีคอมโพเนนต์ UI ของการตั้งค่าด่วนที่ช่วยให้เข้าถึงการดำเนินการที่ใช้บ่อยหรือจำเป็นเร่งด่วนได้อย่างรวดเร็ว

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

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

3.14. UI ของสื่อ

หากการติดตั้งใช้งานอุปกรณ์มีแอปพลิเคชันที่ไม่ได้เปิดใช้งานด้วยเสียง (แอป) ซึ่งโต้ตอบกับ แอปพลิเคชันของบุคคลที่สามผ่าน MediaBrowser หรือ MediaSession แอปจะต้องมีลักษณะดังนี้

• [C-1-2] ต้องแสดงไอคอนที่ได้รับผ่าน getIconBitmap() หรือ getIconUri() และชื่อ ที่ได้รับผ่าน getTitle() อย่างชัดเจนตามที่อธิบายไว้ใน MediaDescription อาจย่อชื่อเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น การรบกวนสมาธิของผู้ขับขี่)

• [C-1-3] ต้องแสดงไอคอนแอปพลิเคชันของบุคคลที่สามทุกครั้งที่แสดงเนื้อหาที่แอปพลิเคชันของบุคคลที่สามนี้ เป็นผู้ให้บริการ

• [C-1-4] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับลำดับชั้นของ MediaBrowser ทั้งหมด อาจจำกัดการเข้าถึงส่วนหนึ่งของลำดับชั้นเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น การเสียสมาธิของผู้ขับ) แต่ต้องไม่ให้สิทธิพิเศษตามเนื้อหาหรือผู้ให้บริการเนื้อหา

• [C-1-5] ต้องพิจารณาการแตะสองครั้งของ KEYCODE_HEADSETHOOK หรือ KEYCODE_MEDIA_PLAY_PAUSE เป็น KEYCODE_MEDIA_NEXT สำหรับ MediaSession.Callback#onMediaButtonEvent

3.15 Instant Apps

หากการติดตั้งใช้งานอุปกรณ์รองรับ Instant Apps อุปกรณ์ดังกล่าวต้องเป็นไปตามข้อกำหนดต่อไปนี้

• [C-1-1] แอปด่วนต้องได้รับสิทธิ์ที่มี android:protectionLevel ตั้งค่าเป็น "instant" เท่านั้น
• [C-1-2] Instant App ต้องไม่โต้ตอบกับแอปที่ติดตั้งผ่านIntent โดยนัย เว้นแต่ข้อใดข้อหนึ่งต่อไปนี้เป็นจริง
  • ตัวกรองรูปแบบ Intent ของคอมโพเนนต์จะแสดงและมี CATEGORY_BROWSABLE
  • การดำเนินการเป็นหนึ่งใน ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • เป้าหมายจะแสดงอย่างชัดเจนด้วย android:visibleToInstantApps
• [C-1-3] Instant App ต้องไม่โต้ตอบอย่างชัดเจนกับแอปที่ติดตั้งไว้ เว้นแต่จะมีการเปิดเผยคอมโพเนนต์ผ่าน android:visibleToInstantApps
• [C-1-4] แอปที่ติดตั้งแล้วต้องไม่เห็นรายละเอียดเกี่ยวกับ Instant Apps ใน อุปกรณ์ เว้นแต่ Instant Apps จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งแล้วอย่างชัดเจน

• การใช้งานอุปกรณ์ต้องมีสิ่งต่อไปนี้เพื่อให้ผู้ใช้ โต้ตอบกับ Instant App ได้ AOSP เป็นไปตามข้อกำหนดด้วย UI ของระบบ การตั้งค่า และ Launcher เริ่มต้น การติดตั้งใช้งานอุปกรณ์

  • [C-1-5] ต้องมีตัวเลือกให้ผู้ใช้ดูและลบ Instant Apps ที่แคชไว้ในเครื่องสำหรับแพ็กเกจแอปแต่ละรายการ
  • [C-1-6] ต้องแสดงการแจ้งเตือนผู้ใช้แบบต่อเนื่องที่ยุบได้ขณะที่ Instant App ทำงานอยู่เบื้องหน้า การแจ้งเตือนผู้ใช้ นี้ต้องระบุว่า Instant App ไม่จำเป็นต้องติดตั้ง และแสดงความสามารถของผู้ใช้ที่นำผู้ใช้ไปยังหน้าจอข้อมูลแอปพลิเคชัน ในการตั้งค่า สำหรับ Instant App ที่เปิดตัวผ่าน Web Intent ตามที่กำหนดโดยใช้ Intent ที่ตั้งค่าการดำเนินการเป็น Intent.ACTION_VIEW และมีรูปแบบเป็น "http" หรือ "https" ความสามารถเพิ่มเติมของผู้ใช้ ควรอนุญาตให้ผู้ใช้ไม่เปิด Instant App และ เปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กำหนดค่าไว้ หากมีเบราว์เซอร์ ในอุปกรณ์
  • [C-1-7] ต้องอนุญาตให้เข้าถึงการเรียกใช้ Instant Apps จากฟังก์ชัน "ล่าสุด" หากฟังก์ชัน "ล่าสุด" พร้อมใช้งานในอุปกรณ์

• [C-1-8] ต้องโหลดล่วงหน้าซึ่งแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการ พร้อมตัวแฮนเดิล Intent สำหรับ Intent ที่แสดงใน SDK ที่นี่ และทำให้ Intent ปรากฏต่อ Instant App

3.16 การจับคู่อุปกรณ์ที่ใช้ร่วมกัน

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

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

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

• [C-1-2] ต้องตรวจสอบว่า API ในแพ็กเกจ android.companion ได้รับการติดตั้งใช้งานอย่างสมบูรณ์

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

RawContacts จะ "เชื่อมโยงกับ" หรือ "จัดเก็บไว้ใน" Account เมื่อคอลัมน์ ACCOUNT_NAME และ ACCOUNT_TYPE ของ RawContacts ตรงกับฟิลด์ Account.name และ Account.type ที่เกี่ยวข้องของบัญชี

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

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

• [C-1-4] ระบบต้องไม่นำรายชื่อติดต่อดิบที่แทรกลงในบัญชีภายในเครื่องที่กำหนดเองออก เมื่อมีการเพิ่มหรือนำบัญชีออก

• [C-1-5] การดำเนินการลบที่ทำกับบัญชีภายในที่กำหนดเอง ต้องส่งผลให้ระบบล้างข้อมูลรายชื่อติดต่อดิบทันที (ราวกับว่ามีการตั้งค่า CALLER_IS_SYNCADAPTER เป็น true) แม้ว่าจะมีการตั้งค่าพารามิเตอร์ CALLER_IS_SYNCADAPTER เป็น false หรือไม่ได้ระบุไว้ก็ตาม

3.18.2. เครื่องมือเลือกรายชื่อติดต่อของระบบ

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

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

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

3.20 ประสบการณ์การใช้งานที่อิงตาม Assistant

3.20.1. ข้อกำหนดของสตรีมเสียงสำหรับ Assistant

3.21 การสนับสนุนฟีเจอร์การซิงค์อุปกรณ์ที่ใช้ร่วมกัน

3.22. ComputerControls API

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

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

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

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

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

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

• [C-0-6] ต้องไม่ติดตั้งแพ็กเกจแอปพลิเคชันจากแหล่งที่มาที่ไม่รู้จัก เว้นแต่แอปที่ขอติดตั้ง เป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด

  • ต้องประกาศสิทธิ์ REQUEST_INSTALL_PACKAGES หรือตั้งค่า android:targetSdkVersion เป็น 24 หรือต่ำกว่า
  • ต้องได้รับสิทธิ์จากผู้ใช้ในการติดตั้งแอปจาก แหล่งที่มาที่ไม่รู้จัก

• ควรมีส่วนติดต่อผู้ใช้เพื่ออนุญาต/เพิกถอนสิทธิ์ในการ ติดตั้งแอปจากแหล่งที่ไม่รู้จักต่อแอปพลิเคชัน แต่สามารถเลือกที่จะ ใช้การดำเนินการนี้เป็นแบบไม่มีการดำเนินการและแสดงผล RESULT_CANCELED สำหรับ startActivityForResult() หากการติดตั้งใช้งานอุปกรณ์ไม่ต้องการอนุญาตให้ผู้ใช้มีตัวเลือกนี้ อย่างไรก็ตาม แม้ในกรณีดังกล่าว ผู้ให้บริการก็ควรระบุให้ผู้ใช้ทราบว่าเหตุใดจึงไม่มีตัวเลือกดังกล่าว

• [C-0-7] ต้องแสดงกล่องโต้ตอบคำเตือนพร้อมสตริงคำเตือนที่ ระบุผ่าน System API PackageManager.setHarmfulAppWarning ต่อผู้ใช้ก่อนที่จะเปิดตัวกิจกรรมในแอปพลิเคชันที่ System 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 Source

โปรดทราบว่าทั้ง 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] Opus

ตัวเข้ารหัสเสียงทั้งหมดต้องรองรับสิ่งต่อไปนี้

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

หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมหลายช่อง (เช่น มากกว่า 2 ช่อง) เป็น PCM ผ่านตัวแปลงสัญญาณเสียง AAC เริ่มต้นใน API ของ android.media.MediaCodec จะต้องรองรับรายการต่อไปนี้

• [C-2-1] ต้องทำการถอดรหัสโดยไม่มีการดาวน์มิกซ์ (เช่น สตรีม AAC 5.0 ต้องถอดรหัสเป็น PCM 5 ช่อง สตรีม AAC 5.1 ต้องถอดรหัสเป็น PCM 6 ช่อง)

• [C-2-2] ข้อมูลเมตาของช่วงไดนามิกต้องเป็นไปตามที่กำหนดไว้ใน "การควบคุมช่วงไดนามิก (DRC)" ใน ISO/IEC 14496-3 และandroid.media.MediaFormatคีย์ DRC เพื่อ กำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ AAC DRC เปิดตัวใน API 21 และมีดังนี้ KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_ENCODED_TARGET_LEVEL

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัวถอดรหัสเสียง AAC ทั้งหมดเป็นไปตามข้อกำหนด C-2-1 และ C-2-2 ข้างต้น

เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)

• [C-3-1] ต้องตีความและใช้ข้อมูลเมตาความดังและ DRC ตามโปรไฟล์การควบคุมช่วงไดนามิก DRC ของ MPEG-D ระดับ 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:

• MAY รองรับการควบคุมความดังและช่วงไดนามิกโดยใช้ 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. รายละเอียดตัวแปลงรหัสเสียง

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

• [C-0-2] GIF

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

5.1.7. ตัวแปลงรหัสวิดีโอ

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

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

• [C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาด Bytebuffer ของเอาต์พุตและอินพุตที่ รองรับเฟรมที่บีบอัดและไม่บีบอัดที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้ตามที่ มาตรฐานและการกำหนดค่ากำหนดไว้ แต่ก็ต้องไม่จัดสรรมากเกินไป

• [C-1-2] ตัวเข้ารหัสและตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 8:8:8 (COLOR_FormatYUV420Flexible) ผ่าน CodecCapabilities

• [C-1-3] ตัวเข้ารหัสและตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบระนาบหรือแบบกึ่งระนาบอย่างน้อย 1 รูปแบบ COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) ขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัวเข้ารหัสและตัวถอดรหัสวิดีโอรองรับ รูปแบบสี YUV420 8:8:8 แบบระนาบหรือแบบกึ่งระนาบที่ฮาร์ดแวร์เพิ่มประสิทธิภาพแล้วอย่างน้อย 1 รูปแบบ (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, ถอดรหัสเท่านั้น)
H.265 HEVC	ดูรายละเอียดได้ที่ส่วนที่ 5.3	MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-2	โปรไฟล์หลัก	MPEG2-TS (.ts, ไม่สามารถค้นหาได้) MPEG-4 (.mp4, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)
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 การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม รวมถึง Codec 2.0 ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียที่มีค่าใช้จ่ายต่ำ

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

• [C-1-1] ต้องรองรับตัวแปลงรหัสสื่อผ่าน OMX หรือ Codec 2.0 API (หรือทั้ง 2 อย่าง) ตามที่ระบุไว้ในโครงการโอเพนซอร์ส Android และต้องไม่ปิดใช้หรือ หลบเลี่ยงการรักษาความปลอดภัย ซึ่งไม่ได้หมายความว่า ตัวแปลงรหัสทุกตัวต้องใช้ API ของ OMX หรือ Codec 2.0 แต่หมายความว่า ต้องรองรับ API อย่างน้อย 1 รายการ และการรองรับ API ที่มี ต้องรวมการป้องกันด้านความปลอดภัยด้วย

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Codec 2.0 API

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

• [C-2-1] ต้องมีตัวแปลงรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจาก Android Open Source Project (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละรายการ (ตัวเข้ารหัสหรือตัวถอดรหัส) ที่อุปกรณ์รองรับ

• [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ตัวแปลงรหัสซอฟต์แวร์ OMX ทำงานใน กระบวนการตัวแปลงรหัสที่ไม่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์อื่นนอกเหนือจาก ตัวแมปหน่วยความจำ

หากการใช้งานอุปกรณ์รองรับ Codec 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." ต้องใช้ API ของ OMX และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อ OMX IL

• [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2." ต้องใช้ Codec 2.0 API และ มีชื่อที่เป็นไปตามหลักเกณฑ์การตั้งชื่อ Codec 2.0 สำหรับ Android

• [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." หรือ "c2.android." ต้อง ไม่ระบุว่าเป็นของผู้ให้บริการหรือเป็นแบบเร่งด้วยฮาร์ดแวร์

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

• [C-1-6] ตัวแปลงรหัสที่ไม่มีในโครงการโอเพนซอร์ส Android หรือไม่ได้อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องถือว่าเป็นของผู้ให้บริการ

• [C-1-7] ต้องระบุลักษณะตัวแปลงรหัสที่ใช้การเร่งฮาร์ดแวร์ เป็นการเร่งฮาร์ดแวร์

• [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด เช่น ตัวแปลงรหัสที่ชื่อ "decoders" ต้องรองรับการถอดรหัส และตัวแปลงรหัสที่ชื่อ "encoders" ต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อซึ่งมีรูปแบบสื่อต้องรองรับรูปแบบเหล่านั้น

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

• [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 (Flexible Macroblock Ordering) และ RS (Redundant Slices) เป็นแบบไม่บังคับ นอกจากนี้ เพื่อ รักษาความเข้ากันได้กับอุปกรณ์ 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
• ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (HD) ต่อไปนี้
• [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 ผ่าน Media API ให้ทำดังนี้

• การรองรับรูปแบบ 12 บิตเป็นแบบไม่บังคับ

5.2.5. H.265

หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์ดังกล่าวจะ

• [C-1-1] ต้องรองรับ Main Profile ระดับ 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] ต้องรองรับ Main Profile รวมถึงเนื้อหา 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 การถอดรหัสวิดีโอ

5.3.1. MPEG-2

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส MPEG-2 จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับโปรไฟล์หลักระดับสูง

5.3.2. H.263

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.263 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับ Baseline Profile ระดับ 30 (ความละเอียด CIF, QCIF และ SQCIF ที่ 30fps 384kbps) และระดับ 45 (ความละเอียด QCIF และ SQCIF ที่ 30fps 128kbps)

5.3.3. MPEG-4

หากมีการติดตั้งใช้งานอุปกรณ์ที่มีตัวถอดรหัส MPEG-4 จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับ Simple Profile Level 3

5.3.4. H.264

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.264 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน การรองรับ ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) และ RS (Redundant Slices) เป็นแบบไม่บังคับ
• [C-1-2] ต้องถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ตามที่ระบุไว้ในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์พื้นฐาน และ Main Profile Level 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 ผ่าน Media API ให้ทำดังนี้

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

5.3.6. VP8

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

• [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
• ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนด
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้

หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับ หรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

• [C-2-1] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในตารางต่อไปนี้
• [C-2-2] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในตารางต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 FPS (60 FPSโทรทัศน์)	30 (60 FPS Television)
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้

หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์ ให้ทำดังนี้

• [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้

หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

• [C-3-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส VP9 หรือ H.265 อย่างน้อย 1 รายการ ของโปรไฟล์ 720, 1080 และ UHD

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล	3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 FPS (60 FPSโทรทัศน์ที่มีการถอดรหัสฮาร์ดแวร์ VP9)	60 FPS
อัตราบิตของวิดีโอ	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2 หรือ VP9Profile3 ผ่าน API สื่อ 'CodecProfileLevel'

• การรองรับรูปแบบ 12 บิตเป็นแบบไม่บังคับ

หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) ผ่าน API สื่อ

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

5.3.8. Dolby Vision

หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-1-1] ต้องมีโปรแกรมแยกที่รองรับ Dolby Vision

• [C-1-2] ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องบนหน้าจออุปกรณ์ หรือบนจอแสดงผลภายนอกที่เชื่อมต่อผ่านพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)

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

5.3.9. AV1

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

• [C-1-1] ต้องรองรับ Main Profile รวมถึงเนื้อหา 8 บิตและ 10 บิต

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

• [C-2-1] ต้องถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 720p อย่างน้อยจาก ตารางด้านล่างเมื่อความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่า 720p
• [C-2-2] ต้องถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 1080p อย่างน้อยจากตารางด้านล่างได้ เมื่อความสูงที่รายงานโดยเมธอด 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 ใดก็ตามที่เปิด สำเร็จ ระบบต้องรองรับลักษณะต่อไปนี้อย่างน้อย

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
  • ช่อง: โมโน
  • แหล่งที่มาของเสียง: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, หรือ VOICE_PERFORMANCE ซึ่งรวมถึงค่าที่กำหนดล่วงหน้าของอินพุตที่เทียบเท่ากันใน AAudio ด้วย เช่น AAUDIO_INPUT_PRESET_CAMCORDER

• ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต และ 24 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • ช่อง: จำนวนช่องเท่ากับจำนวนไมโครโฟนใน อุปกรณ์

• [C-1-2] ต้องบันทึกที่อัตราการสุ่มตัวอย่างข้างต้นโดยไม่มีการอัปแซมปลิง

• [C-1-3] ต้องมีตัวกรองป้องกันรอยหยักที่เหมาะสมเมื่อจับภาพอัตราการสุ่มตัวอย่างที่ระบุไว้ข้างต้นด้วยการลดอัตราการสุ่มตัวอย่าง

• ควรอนุญาตให้จับภาพเนื้อหาเสียงดิบที่มีคุณภาพเทียบเท่าวิทยุ AM และ DVD ซึ่งหมายถึงลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
  • ช่องสัญญาณ: สเตอริโอ

• [C-1-4] ต้องปฏิบัติตาม API MicrophoneInfo และกรอกข้อมูลอย่างถูกต้องสำหรับไมโครโฟนที่พร้อมใช้งานในอุปกรณ์ ซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน AudioManager.getMicrophones() API สำหรับ AudioRecord ที่ใช้งานอยู่โดยใช้ MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED หรือ VOICE_PERFORMANCE หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้มีการจับภาพเนื้อหาเสียงดิบในคุณภาพวิทยุ AM และ DVD อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [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 Full Scale สำหรับตัวอย่างแบบจุดลอย/ความแม่นยำสองเท่า) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งกำเนิดเสียงสำหรับการจดจำเสียงพูด

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศเทคโนโลยีการ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

5.4.5. การจับภาพพร้อมกัน

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะต้อง ใช้การจับภาพพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้

• [C-1-1] ต้องอนุญาตให้บริการการช่วยเหลือพิเศษเข้าถึงไมโครโฟนพร้อมกันได้โดยการบันทึกด้วย AudioSource.VOICE_RECOGNITION และแอปพลิเคชันอย่างน้อย 1 รายการที่บันทึกด้วย AudioSource ใดก็ได้
• [C-1-2] ต้องอนุญาตให้แอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งมีบทบาทเป็น Assistant และแอปพลิเคชันอย่างน้อย 1 รายการที่บันทึกด้วย AudioSource ใดก็ได้เข้าถึงไมโครโฟนพร้อมกันได้ ยกเว้น AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER
• [C-1-3] ต้องปิดเสียงที่แอปพลิเคชันอื่นๆ บันทึกไว้ ยกเว้นบริการการช่วยเหลือพิเศษ ขณะที่แอปพลิเคชันกำลังบันทึกด้วย AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER อย่างไรก็ตาม เมื่อ แอปบันทึกผ่าน AudioSource.VOICE_COMMUNICATION แอปอื่น จะบันทึกการโทรด้วยเสียงได้หากเป็นแอปที่มีสิทธิ์ (ติดตั้งไว้ล่วงหน้า) ซึ่งมี สิทธิ์ CAPTURE_AUDIO_OUTPUT

• [C-1-4] หากแอปพลิเคชัน 2 รายการขึ้นไปจับภาพพร้อมกันและหากไม่มีแอปใดมี UI อยู่ด้านบน แอปที่เริ่มจับภาพล่าสุดจะได้รับเสียง

5.5 การเล่นเสียง

Android มีการรองรับเพื่อให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงได้ตามที่กำหนดไว้ในส่วน 7.8.2

5.5.1. การเล่นเสียงดิบ

หากการใช้งานอุปกรณ์ประกาศ android.hardware.audio.output จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบแหล่งที่มา: Linear PCM, 16 บิต, 8 บิต, Float
  • ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องสัญญาณที่ถูกต้อง โดยมีช่องสัญญาณสูงสุด 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

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

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

• ควรสนับสนุนการใช้งาน 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 แบบเล่นต่อเนื่องของ AudioTrack และคอนเทนเนอร์สื่อสำหรับ MediaPlayer

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้การเล่นแบบออฟโหลดสำหรับรูปแบบ AAC, MP3, OPUS และ PCM

5.5.5. พารามิเตอร์การเล่น

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

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

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

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

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

• เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมถัดไป หลังจากที่อุปกรณ์เล่นเสียง

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

• อินพุตสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้ไม่ได้หรือ ไม่พร้อมใช้งาน

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

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

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

• OpenSL ES PCM คิวบัฟเฟอร์ API ชุด API ที่เกี่ยวข้องกับ PCM ของ OpenSL ES ภายใน Android NDK

• AAudio Native Audio API ชุด API ของ AAudio ภายใน Android NDK

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

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

• ค่าเบี่ยงเบนสัมบูรณ์เฉลี่ย (MAD) ค่าเฉลี่ยของค่าสัมบูรณ์ของ ค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า

• เวลาในการตอบสนองต่อการแตะ (TTL) ตามที่วัดโดย CTS Verifier คือเวลาตั้งแต่ตอนที่แตะหน้าจอจนถึงตอนที่ได้ยินเสียง ซึ่งเกิดจากการแตะดังกล่าวที่ลำโพง ค่านี้เป็นค่าเฉลี่ยจากการวัด 5 ครั้งโดยใช้ AAudio Native Audio API สำหรับเอาต์พุต

• เวลาในการตอบสนองแบบไป-กลับ (RTL) ตามที่วัดโดย CTS Verifier คือเวลาในการตอบสนองต่อเนื่องโดยเฉลี่ยจากการวัด 5 ครั้ง ซึ่งวัดผ่านเส้นทาง Loopback ที่ป้อนเอาต์พุตกลับไปยังอินพุตโดยใช้ AAudio Native Audio API

  เส้นทาง Loopback มีดังนี้

  • ลำโพง/ไมค์: ลำโพงในตัวถึงไมโครโฟนในตัว
  • แอนะล็อก: ช่องเสียบแอนะล็อก 3.5 มม. และอะแดปเตอร์ลูปแบ็ก
  • USB: อะแดปเตอร์ USB เป็น 3.5 มม. และอะแดปเตอร์ลูปแบ็ก หรืออินเทอร์เฟซเสียง USB และสายลูปแบ็ก

• FEATURE_AUDIO_LOW_LATENCY ประกาศฟีเจอร์ android.hardware.audio.low_latency

• FEATURE_AUDIO_PRO ประกาศฟีเจอร์ android.hardware.audio.pro

• MPC Media Performance Class

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

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

• [C-1-1] นำข้อกำหนดออกใน Android 15

• [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบเย็นไม่เกิน 500 มิลลิวินาที

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

• [C-1-4] เวลาในการตอบสนองแบบไปกลับที่คำนวณแล้วตามการประทับเวลาอินพุตและเอาต์พุต ที่ AAudioStream_getTimestamp ส่งคืนมาต้องอยู่ภายใน 200 มิลลิวินาทีของเวลาในการตอบสนองแบบไปกลับที่วัดได้สำหรับ AAUDIO_PERFORMANCE_MODE_NONE และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY สำหรับลำโพง ชุดหูฟังแบบมีสาย และชุดหูฟังไร้สาย

• [C-SR-1] นำข้อกำหนดออกใน Android 15

• [C-SR-2] นำข้อกำหนดออกใน Android 15

• [C-SR-4] นำข้อกำหนดออกใน Android 15

• [C-SR-5] นำข้อกำหนดออกใน Android 15

• [C-SR-6] นำข้อกำหนดออกใน Android 15

• [C-SR-7] นำข้อกำหนดออกใน Android 15

• [C-2-1] ข้อกำหนดถูกนำออกใน Android 15

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

• [C-3-1] นำข้อกำหนดออกใน Android 15

• [C-3-2] เวลาในการตอบสนองของอินพุตแบบ Cold Start ไม่เกิน 500 มิลลิวินาที

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

• [C-SR-8] นำข้อกำหนดออกใน Android 15

• [C-SR-11] นำข้อกำหนดออกใน Android 15

• [C-SR-12] นำข้อกำหนดออกใน Android 15

ตารางต่อไปนี้กำหนดข้อกำหนดสำหรับ RTL สำหรับการใช้งานอุปกรณ์พกพาที่กำหนดไว้ใน 2.2.1 ที่ประกาศ android.hardware.audio.output และ android.hardware.microphone

ตารางต่อไปนี้จะกำหนดข้อกำหนดสำหรับ TTL สำหรับการใช้งานอุปกรณ์พกพาที่กำหนดไว้ใน 2.2.1 ซึ่งประกาศ android.hardware.audio.output และ android.hardware.microphone

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

• [C-4-1] ต้องแสดงเวลาในการตอบสนองสูงสุดของการติดตามศีรษะต่อการอัปเดตเสียง ที่ 300 มิลลิวินาที

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 และ MPEG-2 ได้ที่ส่วนที่ 5.1.8 ตัวแปลงสัญญาณเสียง: AAC ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
AAC ที่มีเฟรม ADTS และแท็ก ID3	ISO 13818-7	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
WebVTT	WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์	การอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC	RFC 6184	ดูรายละเอียดเกี่ยวกับ H264 AVC ได้ที่ส่วนที่ 5.1.8
MP4A-LATM	RFC 6416	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
H263-1998	RFC 3551 RFC 4629 RFC 2190	ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8
H263-2000	RFC 4629	ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8
AMR	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-NB ได้ที่ส่วนที่ 5.1.3
AMR-WB	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-WB ได้ที่ส่วนที่ 5.1.3
MP4V-ES	RFC 6416	ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ได้ที่ส่วนที่ 5.1.8
mpeg4-generic	RFC 3640	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
MP2T	RFC 2250	ดูรายละเอียดได้ที่ MPEG-2 Transport Stream ในส่วน HTTP Live Streaming

5.8. สื่อที่ปลอดภัย

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

• [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE และรองรับ โปรโตคอลการแสดงผลแบบไร้สาย อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกที่แข็งแกร่งทางคริปโตกราฟี เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และ รองรับจอแสดงผลภายนอกแบบมีสาย อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อ ผ่านพอร์ตแบบใช้สายที่ผู้ใช้เข้าถึงได้

5.9. Musical Instrument Digital Interface (MIDI)

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมด สำหรับ การเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI ซึ่งมีการรับส่งดังกล่าว

  • โหมดโฮสต์ USB ส่วน 7.7
  • MIDI ผ่านบลูทูธ LE ที่ทำหน้าที่เป็นอุปกรณ์กลาง ส่วน 7.4.3

• [C-1-2] ต้องรองรับการส่งผ่านซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน)

• [C-1-3] ต้องมี libamidi.so (การรองรับ MIDI ดั้งเดิม)

• ควรรองรับโหมดอุปกรณ์ต่อพ่วง MIDI ผ่าน USB, ส่วน 7.7

5.10. เสียงระดับมืออาชีพ

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency

• [C-1-2] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองสำหรับ FEATURE_AUDIO_PRO ตามที่กำหนดไว้ในส่วน5.6 เวลาในการตอบสนองของเสียง

• [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB

• [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi

• [C-1-5] ต้องเป็นไปตามข้อกำหนดเวลาในการตอบสนองของเสียง USB โดยใช้ AAudio native audio API และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY

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

• [C-1-7] ต้องมีเวลาในการตอบสนองเมื่อเริ่มทำงานแบบเย็นไม่เกิน 200 มิลลิวินาที

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

• [C-2-2] ต้องเป็นไปตามส่วนข้อกำหนดของอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อกำหนดชุดหูฟังเสียงแบบใช้สาย (v1.1)

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

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

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

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

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

• [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับ ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล (ในขณะที่ SNR วัดเป็นความแตกต่างระหว่าง 94 dB SPL กับ SPL ที่เทียบเท่า ของสัญญาณรบกวนในตัวแบบถ่วงน้ำหนัก A)

• [C-1-7] ต้องมีค่าความเพี้ยนฮาร์มอนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ในไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

• [C-1-8] ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมอัตราขยายอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางนอกเหนือจากตัวคูณระดับเพื่อนำระดับไปสู่ช่วงที่ต้องการ กล่าวคือ

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

การวัด SPL ทั้งหมดจะดำเนินการข้างไมโครโฟนที่อยู่ระหว่างการทดสอบโดยตรง สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone แต่ไม่ รองรับแหล่งที่มาของเสียงที่ไม่มีการประมวลผล อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องแสดงผล null สำหรับเมธอด AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API เพื่อระบุการไม่รองรับอย่างถูกต้อง

• [C-SR-1] ยังคงเป็นข้อแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดส่วนใหญ่ สำหรับเส้นทางสัญญาณของแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล

5.12. วิดีโอ HDR

Android 13 รองรับเทคโนโลยี HDR ตามที่อธิบายไว้ในเอกสารที่จะเผยแพร่ในเร็วๆ นี้

รูปแบบพิกเซล

หากตัวถอดรหัสวิดีโอโฆษณาสนับสนุน COLOR_FormatYUVP010 จะเกิดสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับรูปแบบ P010 สำหรับการอ่าน CPU (ImageReader, MediaImage, ByteBuffer) ใน Android 13 เราได้ผ่อนปรน P010 เพื่อ อนุญาตให้ใช้ระยะก้าวย่างที่กำหนดเองสำหรับระนาบ Y และ UV

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

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

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

หากตัวเข้ารหัสวิดีโอโฆษณาว่ารองรับ 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 โดยใช้ API ของ CamcorderProfile อุปกรณ์จะทำสิ่งต่อไปนี้

• [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] ต้องโฆษณาการรองรับEXT_YUV_targetส่วนขยาย OpenGL

ข้อกำหนดของจอแสดงผล HDR

หากการติดตั้งใช้งานอุปกรณ์ได้รับเนื้อหาบัฟเฟอร์ที่เข้ารหัสด้วย ADATASPACE_TRANSFER_HLG และมีการส่งเนื้อหานั้นไปยังจอแสดงผลผ่าน SurfaceControl.Transaction#setBuffer

• [C-8-1] ต้องปฏิบัติตามคำแนะนำเกี่ยวกับสีขาวของกราฟิกใน BT. 2408-7 และแสดงเนื้อหาดังกล่าวให้มีความสว่างมากกว่าเนื้อหา SDR ไม่เกิน 4.926 เท่า

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

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

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

• [C-0-1] ต้องรองรับเครื่องมือสำหรับนักพัฒนาแอป Android ที่มีให้ใน Android SDK

• Android Debug Bridge (adb)

• [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง dumpsys cmd stats และ Simpleperf

• [C-0-11] ต้องรองรับคำสั่ง Shell cmd testharness การอัปเกรด การติดตั้งใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มี บล็อกข้อมูลแบบถาวรอาจได้รับการยกเว้นจาก C-0-11

• [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ระบบอุปกรณ์ (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys

• [C-0-10] ต้องบันทึกเหตุการณ์ต่อไปนี้โดยไม่มีการละเว้น และทำให้เหตุการณ์ดังกล่าว เข้าถึงได้และพร้อมใช้งานสำหรับcmd stats คำสั่ง Shell และคลาส System API ของ StatsManager

  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • PressureStallInformation
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

• [C-0-4] ต้องมี daemon adb ฝั่งอุปกรณ์ที่ไม่ได้ใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge

• [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่ได้รับการตรวจสอบสิทธิ์ที่รู้จัก

• [C-0-6] ต้องมีกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

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

• [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ต หรือ Wi-Fi)

• [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 เพื่อให้ นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-4-1] ต้องมี AdbManager#isAdbWifiSupported() method return true

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต และ มีกล้องอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-5-1] ต้องมีเมธอด AdbManager#isAdbWifiQrSupported() ที่ส่งคืน true

• บริการตรวจสอบข้อบกพร่องของ Dalvik (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] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ยอมรับไบนารีของ Perfetto เป็นอินพุต การกำหนดค่า Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto

  • [C-SR-3] ขอแนะนําอย่างยิ่งให้เขียนไบนารีของ Perfetto เป็นเอาต์พุต การติดตาม Protobuf ที่เป็นไปตามสคีมาที่กําหนดไว้ใน เอกสารประกอบของ Perfetto

  • [C-SR-4] ขอแนะนำอย่างยิ่งให้ระบุผ่านไบนารี perfetto อย่างน้อยแหล่งข้อมูลที่อธิบายไว้ใน เอกสารประกอบของ Perfetto

• Low Memory Killer

  • [C-0-12] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ไปยัง บันทึก statsd เมื่อ Low Memory Killer ปิดแอป

• โหมดโปรแกรมทดสอบอัตโนมัติ

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

  • [C-2-1] ต้องส่งคืน true สำหรับ ActivityManager.isRunningInUserTestHarness()

  • [C-2-2] ต้องใช้โหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบโหมดโปรแกรมทดสอบอัตโนมัติ

• ข้อมูลงาน GPU

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

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

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

• [C-1-1] ต้องมีส่วนที่ช่วยให้นักพัฒนาแอปเปิด/ปิดใช้เลเยอร์การแก้ไขข้อบกพร่อง GPU ได้

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

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

Android มีการรองรับให้นักพัฒนาแอปกำหนดค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน

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

• [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การติดตั้งใช้งาน Android ต้นทางจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาแอปได้หลังจากกด 7 ครั้งในรายการในเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
• [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น
• [C-0-3] ต้องมีกลไกที่ชัดเจนซึ่งไม่ให้สิทธิพิเศษแก่แอปของบุคคลที่สามแอปใดแอปหนึ่งเมื่อเทียบกับแอปอื่นเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป ต้องระบุเอกสารหรือเว็บไซต์ที่มองเห็นได้แบบสาธารณะซึ่งอธิบายวิธี เปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป เอกสารหรือเว็บไซต์นี้ต้องลิงก์จากเอกสาร Android SDK ได้
• ควรมีการแจ้งเตือนแบบภาพอย่างต่อเนื่องแก่ผู้ใช้เมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปและมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้
• MAY อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาแอปชั่วคราวโดยการซ่อนหรือปิดใช้เมนูเพื่อป้องกันไม่ให้ผู้ใช้เสียสมาธิในสถานการณ์ที่อาจเป็นอันตรายต่อผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีคอมโพเนนต์ฮาร์ดแวร์ที่เฉพาะเจาะจงซึ่งมี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม ให้ทำดังนี้

• [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

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

• [C-0-2] ต้องยังคงแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
• [C-0-3] ต้องใช้ลักษณะการทำงานของ API เป็นการดำเนินการที่ไม่ทำอะไรเลยในลักษณะที่สมเหตุสมผล
• [C-0-4] เมธอด API ต้องแสดงค่า Null ในกรณีที่เอกสารประกอบ SDK อนุญาต
• [C-0-5] เมธอด API ต้องแสดงการใช้งานแบบไม่มีการดำเนินการของคลาสที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
• [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
• [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับรหัสเฉพาะของบิลด์เดียวกัน

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

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

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

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

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

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

• ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้าม 2 มุม ของส่วนที่สว่างของจอแสดงผล

• ความหนาแน่น จำนวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งเชิงเส้น 1 นิ้ว ซึ่งแสดงเป็นพิกเซลต่อนิ้ว (ppi หรือ dpi) หากมีการระบุค่า ppi และ dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วงที่ระบุ

• สัดส่วนภาพ อัตราส่วนของพิกเซลของด้านที่ยาวกว่าต่อด้านที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480 x 854 พิกเซล จะมีอัตราส่วนเป็น 854 / 480 = 1.779 หรือประมาณ "16:9"

• ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นความหนาแน่นของหน้าจอที่ 160 สำหรับความหนาแน่น d และจำนวนพิกเซล 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_WATCH และรายงานขนาด 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 ที่มุมแต่ละมุมของ จอแสดงผลเชิงตรรกะ พิกเซลอย่างน้อย 1 พิกเซลของแต่ละกล่องจะปรากฏบน หน้าจอ

• ควรมีส่วนที่ผู้ใช้สามารถเปลี่ยนไปใช้โหมดแสดงผลที่มี มุมสี่เหลี่ยมผืนผ้า

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

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

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

• [C-4-1] นำข้อกำหนดออกใน Android 15

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 หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพให้เล็กกว่า 320 dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) แล้วแต่ว่าอย่างใดจะเกิดขึ้นก่อน

• [C-1-2] ต้องไม่ปรับขนาดการแสดงผลให้เล็กกว่า 0.85 เท่าของ DENSITY_DEVICE_STABLE

• ขอแนะนำให้ระบุการปรับขนาดตัวเลือกโฆษณา Display เนทีฟต่อไปนี้ (ขณะที่ปฏิบัติตามข้อจำกัดที่ระบุไว้ข้างต้น) เพื่อให้มั่นใจว่าผู้ใช้จะได้รับประสบการณ์การใช้งานที่ดีและมีขนาดแบบอักษรที่สอดคล้องกัน

  • เล็ก: 0.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15x
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

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] นำข้อกำหนดออกใน Android 16

• [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยน การวางแนว

• MAY อาจเลือกการวางแนวแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1. OpenGL ES

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

• [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API ดั้งเดิม

• [C-0-2] ต้องรองรับ API ที่มีการจัดการที่เกี่ยวข้องทั้งหมดและ API ดั้งเดิมสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุว่ารองรับ

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

• [C-1-1] ต้องรองรับ OpenGL ES 1.1, 2.0, 3.0 และ 3.1 ตามที่ระบุและ อธิบายไว้ใน เอกสารประกอบ Android SDK

• [C-SR-1] นำข้อกำหนดออกใน Android 15

• ควรจะรองรับ 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] ต้องรายงานผ่าน OpenGL ES Managed API และ Native 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] ต้องผ่านการทดสอบ dEQP ของ OpenGL ES ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 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] ต้องรองรับ OpenGL ES Android Extension Pack ทั้งหมด

หากการใช้งานอุปกรณ์รองรับ OpenGL ES Android Extension Pack ทั้งหมด อุปกรณ์จะทำสิ่งต่อไปนี้ได้

• [C-5-1] ต้องระบุการรองรับผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

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

• [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย

7.1.4.2. Vulkan

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

หากการใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3

• [C-4-1] ต้องไม่รองรับเวอร์ชันย่อยของ Vulkan (กล่าวคือ ส่วนย่อย ของเวอร์ชันหลักของ Vulkan ต้องเป็น 0)

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

• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.3

การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เกี่ยวข้อง โดยจะอยู่ในโครงสร้างแหล่งที่มาของ 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 อย่างน้อย 1 รายการสำหรับ Vulkan native API vkEnumeratePhysicalDevices()

• [C-1-3] ต้องใช้ API ของ Vulkan 1.1 อย่างเต็มรูปแบบสำหรับแต่ละรายการที่ระบุ VkPhysicalDevice

• [C-1-4] ต้องแสดงรายการเลเยอร์ที่อยู่ในไลบรารีแบบเนทีฟซึ่งมีชื่อเป็น libVkLayer*.so ในไดเรกทอรีไลบรารีแบบเนทีฟของแพ็กเกจแอปพลิเคชัน ผ่าน API แบบเนทีฟของ Vulkan vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()

• [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน Vulkan Native API และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยาย ที่ไม่รองรับอย่างถูกต้อง

• [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของ Vulkan dEQP Tests ที่รองรับผ่านแฟล็กฟีเจอร์android.software.vulkan.deqp.level

• [C-1-9] ต้องรองรับเวอร์ชัน 132317953 (ตั้งแต่วันที่ 1 มี.ค. 2019) เป็นอย่างน้อยตามที่รายงานในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level

• [C-1-10] ต้องผ่านการทดสอบ dEQP ของ Vulkan ทั้งหมดในรายการทดสอบระหว่าง เวอร์ชัน 132317953 กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level

• [C-1-11] ต้องไม่แสดงการรองรับส่วนขยาย VK_KHR_video_queue, VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue

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

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

• [C-SR-8] ขอแนะนำอย่างยิ่งว่าไม่ควรแก้ไขตัวโหลด Vulkan

• [C-1-14] ต้องไม่แสดงรายการส่วนขยายอุปกรณ์ Vulkan ประเภท "KHR", "GOOGLE" หรือ "ANDROID" เว้นแต่ส่วนขยายเหล่านี้จะรวมอยู่ใน android.software.vulkan.deqp.level แฟล็กฟีเจอร์

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

• [C-2-1] ต้องไม่ประกาศฟีเจอร์แฟล็ก Vulkan ใดๆ (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)

• [C-2-2] ต้องไม่แจงนับ VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()

7.1.4.3. RenderScript

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

• [C-0-1] ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

7.1.4.4. การเร่งกราฟิก 2 มิติ

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

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

• [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาซอฟต์แวร์ร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API

• [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาซอฟต์แวร์ผสานรวม เท็กซ์เจอร์ OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI

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

• [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการใช้งาน Android ต้นทาง

7.1.4.5. จอแสดงผลแบบขอบเขตสีกว้าง

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับจอแสดงผลแบบไวด์แกมมาผ่าน Configuration.isScreenWideColorGamut() อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสีแล้ว

• [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตสีครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY

• [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตสีซึ่งมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ xyY ของ CIE 1931

• [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% ในพื้นที่ xyY ของ CIE 1931 แม้ว่า ขอบเขตสีของหน้าจอจะไม่ได้กำหนดไว้ก็ตาม

7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม

Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานในโหมดขนาดหน้าจอ "ปกติ" ที่เทียบเท่า (ความกว้าง 320 dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาสำหรับ 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. แป้นพิมพ์

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

หากมีฟังก์ชันหน้าแรก ล่าสุด หรือย้อนกลับ ฟังก์ชันเหล่านั้นจะทำงานดังนี้

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

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

• [C-5-1] ปุ่มนำทางต้องใช้ส่วนที่แตกต่างกันของหน้าจอ ซึ่งแอปพลิเคชันไม่สามารถเข้าถึงได้ และต้องไม่บดบังหรือรบกวนส่วนของหน้าจอที่แอปพลิเคชันเข้าถึงได้
• [C-5-2] ต้องจัดสรรพื้นที่แสดงผลส่วนหนึ่งให้กับแอปพลิเคชันที่ เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วน 7.1.1
• [C-5-3] ต้องปฏิบัติตามค่าสถานะที่แอปตั้งค่าผ่านเมธอด View.setSystemUiVisibility() API เพื่อให้ส่วนที่แตกต่างกันของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ซ่อนอยู่อย่างถูกต้องตามที่ระบุไว้ใน SDK

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการกระทำบนหน้าจอที่อิงตามท่าทางสัมผัส ให้ทำดังนี้

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสหน้าแรกเท่านั้น
• [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในสี่เหลี่ยมผืนผ้าการยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าให้ไว้ผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets() ต้องไม่ถูกสกัดกั้นสำหรับฟังก์ชันการนำทางตราบใดที่สี่เหลี่ยมผืนผ้าการยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
• [C-6-3] ต้องส่งเหตุการณ์ a 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

หากการติดตั้งใช้งานอุปกรณ์รองรับ System 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

หากการใช้งานอุปกรณ์มีหน้าจอสัมผัสที่ติดตามการสัมผัสมากกว่า 1 ครั้งบนจอแสดงผลหลักที่รองรับ Android อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องรายงานค่าสถานะฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand ซึ่งสอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงในอุปกรณ์

หากการใช้งานอุปกรณ์ต้องอาศัยอุปกรณ์ป้อนข้อมูลภายนอก เช่น เมาส์หรือ แทร็กบอล (กล่าวคือ ไม่ได้สัมผัสหน้าจอโดยตรง) สำหรับการป้อนข้อมูลในจอแสดงผลหลักที่เข้ากันได้กับ Android และเป็นไปตามข้อกำหนดการสัมผัสปลอมในส่วน 7.2.5 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่ขึ้นต้นด้วย android.hardware.touchscreen
• [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
• [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับฟิลด์ API ของ Configuration.touchscreen

7.2.5. การป้อนข้อมูลด้วยการสัมผัสปลอม

อินเทอร์เฟซแบบ Fake Touch มีระบบข้อมูลจากผู้ใช้ที่ประมาณค่าชุดย่อยของความสามารถของหน้าจอสัมผัส ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่ขับเคลื่อน เคอร์เซอร์บนหน้าจอจะคล้ายกับการแตะ แต่กำหนดให้ผู้ใช้ต้องชี้หรือ โฟกัสก่อน แล้วจึงคลิก อุปกรณ์ป้อนข้อมูลจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์อากาศที่ใช้ไจโร สโคป ไจโรพอยน์เตอร์ จอยสติ๊ก และแทร็กแพดมัลติทัชสามารถรองรับการโต้ตอบด้วยการสัมผัส ปลอมได้ Android มีฟีเจอร์ constant android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัสที่มีความเที่ยงตรงสูง (อิงตามเคอร์เซอร์) เช่น เมาส์หรือแทร็กแพดที่สามารถ จำลองอินพุตแบบสัมผัสได้อย่างเหมาะสม (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่า อุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสที่จำลองมาบางส่วน

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

• ควรประกาศการรองรับแฟล็กฟีเจอร์ 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 รายการ (ติดตามมือของนิ้ว) ขึ้นไปอย่างอิสระโดยสมบูรณ์

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)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad ขึ้น1 D-pad ลง1	0x01 0x00393	AXIS_HAT_Y4
D-pad ซ้าย1 D-pad ขวา1	0x01 0x00393	AXIS_HAT_X4
ปุ่มไหล่ซ้าย1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
คลิกปุ่มแท่งซ้าย1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
คลิกปุ่มแท่งขวา1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
กลับ1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ต้องประกาศการใช้งาน HID ข้างต้นภายใน CA ของเกม แพด (0x01 0x0005)

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

4 MotionEvent

การควบคุมแบบแอนะล็อก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 MotionEvent

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

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

7.3 เซ็นเซอร์

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

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

• [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager

• [C-0-2] ต้องแสดงรายการเซ็นเซอร์ที่รองรับอย่างถูกต้องผ่าน SensorManager.getSensorList() และวิธีการที่คล้ายกัน

• [C-0-3] ต้องทํางานอย่างสมเหตุสมผลสําหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น โดยการ แสดงผล true หรือ false ตามความเหมาะสมเมื่อแอปพลิเคชันพยายาม ลงทะเบียน Listener, ไม่เรียกใช้ Listener ของเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)

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

• [C-1-1] ต้อง รายงานการวัดเซ็นเซอร์ทั้งหมด โดยใช้ค่าระบบหน่วยวัดสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภท ตามที่กำหนดไว้ในเอกสารประกอบ Android SDK

• [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time สำหรับกรณีของสตรีมเซ็นเซอร์ที่มี เวลาในการตอบสนองที่ขอสูงสุด 0 มิลลิวินาที เมื่อโปรเซสเซอร์แอปพลิเคชัน ทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง

• [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของการเปิดใช้งานเซ็นเซอร์ ตัวอย่างนี้ยอมรับความแม่นยำที่ 0 ได้

• [C-1-4] สำหรับ API ใดๆ ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์ต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะๆ อย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยความผันผวนหมายถึงค่าเบี่ยงเบนมาตรฐานของความแตกต่างของ ค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน

• [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์ของเซ็นเซอร์ ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือปลุก จากสถานะระงับ

• [C-1-6] ต้อง รายงานเวลาของเหตุการณ์ ในหน่วยนาโนวินาทีตามที่กําหนดไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงถึง เวลาที่เกิดเหตุการณ์และซิงค์กับ นาฬิกา SystemClock.elapsedRealtimeNano()

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

• เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกิน ผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น โดยพฤติกรรมที่บันทึกไว้ของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับ เซ็นเซอร์ถือเป็นข้อมูลที่เชื่อถือได้

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

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

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

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

• ควรใช้เซ็นเซอร์ประเภทเหล่านี้เมื่อมีเซ็นเซอร์จริงที่เป็นข้อกำหนดเบื้องต้นตามที่อธิบายไว้ในประเภทเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์แบบผสม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์แบบรวม

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

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

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์นั้นแสดงต่อผู้พัฒนาแอปบุคคลที่สาม ผู้พัฒนาแอปบุคคลที่สามจะทำสิ่งต่อไปนี้

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

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการผสมผสานระหว่างตัววัดความเร่งแบบ 3 แกน ไจโรสโคปแบบ 3 แกน หรือเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก จะมีลักษณะดังนี้

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

7.3.1. ตัวตรวจวัดความเร่ง

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

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมตัววัดความเร่งแบบ 3 แกน

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

• [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz

• [C-1-3] ต้องเป็นไปตาม ระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API

• [C-1-4] ต้องวัดได้ตั้งแต่การตกอย่างอิสระจนถึง 4 เท่าของ gravity(4g) หรือมากกว่าในแกนใดก็ได้

• [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต

• [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดย ควรคำนวณค่าเบี่ยงเบนมาตรฐานต่อแกนจากตัวอย่าง ที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด

• ควรรายงานเหตุการณ์ที่ความถี่อย่างน้อย 200 Hz

• ควรมีความละเอียดอย่างน้อย 16 บิต

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

• ควรมีการชดเชยอุณหภูมิ

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

• [C-2-1] ต้องใช้และรายงานTYPE_ACCELEROMETERเซ็นเซอร์

• [C-SR-4] ขอแนะนำอย่างยิ่งให้ใช้TYPE_SIGNIFICANT_MOTION เซ็นเซอร์แบบรวม

• [C-SR-5] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงาน TYPE_ACCELEROMETER_UNCALIBRATED เซ็นเซอร์ เราขอ แนะนำเป็นอย่างยิ่งให้อุปกรณ์ Android เป็นไปตามข้อกำหนดนี้ เพื่อให้อัปเกรดเป็น แพลตฟอร์มเวอร์ชันในอนาคตได้ ซึ่งอาจต้องใช้ข้อกำหนดนี้

• ควรใช้เซ็นเซอร์ผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK

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

• [C-3-1] ต้องใช้และรายงานTYPE_ACCELEROMETER_LIMITED_AXESเซ็นเซอร์

• [C-SR-6] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงาน TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED เซ็นเซอร์

หากการใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกนและมีการใช้งานเซ็นเซอร์แบบผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER อย่างใดอย่างหนึ่ง ให้ทำดังนี้

• [C-4-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 มิลลิวัตต์เสมอ

• ควรมีค่าต่ำกว่า 2 มิลลิวัตต์และ 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่ใน สภาวะไดนามิกหรือสภาวะคงที่

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตัววัดความเร่งแบบ 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 แกนและตัววัดความเร่ง

• MAY จะติดตั้งใช้งานเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR

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

• [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 มิลลิวัตต์

• ควรใช้พลังงานน้อยกว่า 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 + Glonass, Beidou หรือ Galileo อย่างน้อย 1 กลุ่ม)

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ต่อไปในระหว่างการโทรฉุกเฉิน

• [C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวทั้งหมด ที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS

• [C-SR-4] ขอแนะนำอย่างยิ่งให้รายงาน AGC และความถี่ของการวัด GNSS

• [C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึง Bearing, Speed และ Vertical) เป็นส่วนหนึ่งของตำแหน่ง 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 rad/s เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง

• [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] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงาน 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

• ควรมีความแม่นยำสัมบูรณ์ 1 hPa

• ควรมีความแม่นยำสัมพัทธ์ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความแม่นยำ ~1 ม. ในการเปลี่ยนแปลง ~200 ม. ที่ระดับน้ำทะเล)

การติดตั้งใช้งานอุปกรณ์ที่ประกาศพร็อพเพอร์ตี้ของระบบ sensor.barometer.high_quality.implemented:

• [C-2-1] ต้องรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa โดยมีความแม่นยำสัมบูรณ์ +/- 1 hPa

• [C-2-2] ต้องมีความแม่นยำสัมพัทธ์ 0.15 hPa ในช่วง 100 hPa ซึ่งเทียบเท่ากับความแม่นยำ ~1 ม. ในการเปลี่ยนแปลง ~1, 000 ม. ที่ ระดับน้ำทะเล

• [C-2-3] ต้องมีความเสถียรภายใน +/- 0.5 hPa เมื่อผู้ใช้แตะ กด หรือบีบอุปกรณ์

• [C-2-4] ต้องมีความเสถียรภายใน +/- 0.15 hPa เมื่อผู้ใช้เดินพร้อมกับ อุปกรณ์ในมือหรือในกระเป๋า

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

• [C-2-6] ต้องมีความเสถียรภายใน +/- 0.15 hPa เมื่อสัมผัสกับความถี่ของแสงและคลื่นวิทยุในชีวิตประจำวันจากแหล่งที่มาทั่วไป เช่น บลูทูธ, การเชื่อมต่อเครือข่ายมือถือ หรือ Wi-Fi

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 ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดระหว่าง -8g ถึง +8g เป็นอย่างน้อย และขอแนะนำอย่างยิ่งให้มีช่วงการวัดระหว่าง -16g ถึง +16g เป็นอย่างน้อย

  • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g

  • ต้องมีความถี่ในการวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า

  • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป ควรรองรับ SensorDirectChannel RATE_VERY_FAST

  • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 400 μg/√Hz

  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์ เหตุการณ์เซ็นเซอร์อย่างน้อย 3,000 รายการ

  • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 3 มิลลิวัตต์

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3 dB อย่างน้อย 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 ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดระหว่าง -1000 ถึง +1000 dps เป็นอย่างน้อย

  • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps

  • ต้องมีความถี่ในการวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า

  • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป ควรรองรับ SensorDirectChannel RATE_VERY_FAST

  • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.014&°/s/√Hz

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3 dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายใน แบนด์วิดท์นี้

  • ควรมีการเดินแบบสุ่มของอัตราที่น้อยกว่า 0.001&°/s √Hz ซึ่งทดสอบที่อุณหภูมิห้อง

  • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 0.05&°/ s / °C

  • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.02% / °C

  • ควรมีเส้นที่เหมาะสมที่สุดซึ่งมีความไม่เชิงเส้น ≤ 0.2%

  • ควรมีความหนาแน่นของสัญญาณรบกวน ≤ 0.007&°/s/√Hz

  • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่

  • ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 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/√Hz

  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์จากเซ็นเซอร์อย่างน้อย 300 รายการ

  • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 2 มิลลิวัตต์

• [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR

• [C-2-9] ต้องมีเซ็นเซอร์TYPE_SIGNIFICANT_MOTIONซึ่งมีคุณสมบัติดังนี้

  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่

• [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่งมีคุณสมบัติดังนี้

  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 100 รายการ

  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่

  • ต้องมีการใช้พลังงานแบบกลุ่มไม่แย่กว่า 4 มิลลิวัตต์

• [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่

• [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่

• [C-2-13] การประทับเวลาของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดย เครื่องวัดความเร่ง ไจโรสโคป และเครื่องวัดสนามแม่เหล็กต้องอยู่ภายใน 2.5 มิลลิวินาที ของกันและกัน การประทับเวลาของเหตุการณ์จริงเดียวกันที่รายงานโดย เครื่องวัดความเร่งและไจโรสโคปควรอยู่ภายใน 0.25 มิลลิวินาทีของกันและกัน

• [C-2-14] ต้องมีการประทับเวลาของเหตุการณ์เซ็นเซอร์ไจโรสโคปในฐานเวลาเดียวกัน กับระบบย่อยของกล้องและมีข้อผิดพลาดไม่เกิน 1 มิลลิวินาที

• [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจาก เวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงข้างต้น ไปยังแอปพลิเคชัน

• [C-2-16] ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์ เมื่ออุปกรณ์อยู่กับที่และ 2.0 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่ เมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] อาจมีTYPE_PROXIMITYเซ็นเซอร์ แต่หากมีจะต้องมี ความสามารถในการบัฟเฟอร์ขั้นต่ำของเหตุการณ์เซ็นเซอร์ 100 รายการ

โปรดทราบว่าข้อกำหนดการใช้พลังงานทั้งหมดในส่วนนี้ไม่รวม การใช้พลังงานของ Application Processor ซึ่งรวมถึงกำลังไฟ ที่ใช้โดยห่วงโซ่เซ็นเซอร์ทั้งหมด ได้แก่ เซ็นเซอร์ วงจรสนับสนุน ระบบประมวลผลเซ็นเซอร์เฉพาะ ฯลฯ

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

• [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) นอกเหนือจากค่าที่ระบุไว้เป็นค่าคงที่สาธารณะใน Authenticators และค่าผสมใดๆ ของค่าเหล่านั้น

• [C-4-3] ต้องใช้การดำเนินการ ACTION_BIOMETRIC_ENROLL ในอุปกรณ์ที่มีข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 การดำเนินการนี้ต้องแสดงเฉพาะจุดแรกเข้าของการลงทะเบียนสำหรับข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 เท่านั้น

• [C-4-4] ต้องอนุญาตให้แอปพลิเคชันเพิ่มเนื้อหาที่กำหนดเองลงใน BiometricPrompt โดยใช้รูปแบบการแสดงเนื้อหา PromptContentView รูปแบบการแสดงเนื้อหา ต้องไม่ขยายเพื่ออนุญาตให้ใช้ภาพ ลิงก์ เนื้อหาแบบอินเทอร์แอกทีฟ หรือสื่อรูปแบบอื่นๆ ที่ไม่ได้เป็นส่วนหนึ่งของ BiometricPrompt API อยู่แล้ว คุณสามารถทำการปรับแต่งสไตล์ที่ไม่เปลี่ยนแปลง บดบัง หรือตัดเนื้อหานี้ได้ (เช่น การเปลี่ยนตำแหน่ง ระยะห่างภายใน ขอบ และการจัดรูปแบบตัวอักษร)

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

• [C-5-1] ต้องกำหนดให้มีขั้นตอนการยืนยันเพิ่มเติมโดยค่าเริ่มต้น (เช่น การกดปุ่ม)

• [C-SR-1] ขอแนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ ลบล้างค่ากำหนดของแอปพลิเคชันและกำหนดให้มี ขั้นตอนการยืนยันประกอบเสมอ

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

• [C-5-2] ต้องใช้ขั้นตอนการตรวจสอบสิทธิ์โดยนัยเพิ่มเติม (โดยไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationRequired(boolean) ซึ่งแอปพลิเคชันสามารถตั้งค่าเพื่อใช้สำหรับขั้นตอนการลงชื่อเข้าใช้

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

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

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

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

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

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

• [C-6-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 3 ตามที่กำหนดไว้ในส่วนนี้ ด้านล่าง

• [C-6-2] ต้องแสดงเฉพาะข้อมูลไบโอเมตริกระดับ 3 เมื่อการตรวจสอบสิทธิ์ ต้องใช้ BIOMETRIC_STRONG หรือเมื่อเรียกใช้การตรวจสอบสิทธิ์ด้วย CryptoObject

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

• [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดน้อยกว่า 0.002%

• [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจมีความปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และระบุความเสี่ยงของการเปิดใช้โหมดนี้อย่างชัดเจน หากอัตราการยอมรับการสวมรอยและการแอบอ้างเป็นบุคคลอื่นสูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android

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

• [C-SR-4] ขอแนะนำอย่างยิ่งให้ลดจำนวนการทดลองที่ผิดพลาดทั้งหมด สำหรับการยืนยันด้วยไบโอเมตริกที่ระบุไว้ใน [C-1-9] หากอัตราการยอมรับการสวมรอยและผู้แอบอ้าง สูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android

• [C-1-3] ต้องจำกัดอัตราการพยายามยืนยันด้วยข้อมูลไบโอเมตริก โดยการลองผิดที่สำเร็จคือการลองที่มีคุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้

• [C-SR-5] ขอแนะนำอย่างยิ่งให้จำกัดอัตราการพยายามอย่างน้อย 30 วินาทีหลังจากลองผิด 5 ครั้งสำหรับการยืนยันทางชีวมิติสำหรับจำนวนการลองผิดสูงสุดต่อ [C-1-9] โดยการลองผิดคือการลองที่มีคุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับชีวมิติที่ลงทะเบียนไว้

• [C-SR-6] ขอแนะนำอย่างยิ่งให้มีตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE

• [C-1-10] ต้องปิดใช้ไบโอเมตริกเมื่อมีการเรียกใช้การหยุดชั่วคราวของการตรวจสอบสิทธิ์หลักเป็นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วน 9.11

• [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นไม่เกิน 30% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสำหรับระดับ A เครื่องมือโจมตีด้วยการนำเสนอ (PAI) ไม่เกิน 30% และ (2) อัตราการยอมรับการปลอมแปลงและ การแอบอ้างเป็นบุคคลอื่นของ PAI ระดับ B ไม่เกิน 40% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android

• [C-1-4] ต้องป้องกันการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้าง ห่วงโซ่ความน่าเชื่อถือก่อนด้วยการให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์ที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบของอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การติดตั้งใช้งานโครงการโอเพนซอร์ส Android มีกลไกในเฟรมเวิร์กเพื่อดำเนินการดังกล่าว

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

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

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

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

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

• [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% ตามที่วัดในอุปกรณ์

• [C-1-15] ต้องอนุญาตให้ผู้ใช้นำการลงทะเบียนไบโอเมตริกออกทีละรายการหรือหลายรายการ

• [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) อัตราการยอมรับการสวมรอยและการแอบอ้างของ PAI ระดับ B ไม่ เกิน 30% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android

• [C-SR-15] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการสวมรอยและการแอบอ้าง ไม่เกิน 20% ต่อชนิดเครื่องมือโจมตีด้วยการนำเสนอ (PAI) ตามที่วัดโดย โปรโตคอลการทดสอบไบโอเมตริกของ Android

• [C-2-3] ต้องดำเนินการ การจับคู่ไบโอเมตริกในสภาพแวดล้อมการดำเนินการที่แยกจากกันภายนอกพื้นที่ผู้ใช้หรือเคอร์เนลของ Android เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ในชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกจากกัน หรือในเครื่องเสมือนที่ได้รับการปกป้องซึ่งเป็นไปตามข้อกำหนดใน ส่วนที่ 9.17

• [C-2-4] ต้องเข้ารหัสข้อมูลที่ระบุตัวบุคคลได้ทั้งหมดและตรวจสอบสิทธิ์ด้วยการเข้ารหัสเพื่อให้มั่นใจว่าจะไม่สามารถรับ อ่าน หรือเปลี่ยนแปลงข้อมูลนอกสภาพแวดล้อมการดำเนินการที่แยกไว้หรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่ระบุไว้ในหลักเกณฑ์การติดตั้งใช้งานในเว็บไซต์โครงการโอเพนซอร์ส Android หรือเครื่องเสมือนที่ได้รับการปกป้องซึ่งควบคุมโดยไฮเปอร์ไวเซอร์ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17

• [C-2-5] สำหรับข้อมูลไบโอเมตริกที่อิงตามกล้อง ขณะที่การตรวจสอบสิทธิ์ หรือการลงทะเบียนที่อิงตามข้อมูลไบโอเมตริกกำลังเกิดขึ้น ให้ทำดังนี้

  • ต้องใช้งานกล้องในโหมดที่ป้องกันไม่ให้มีการอ่านหรือแก้ไขเฟรมของกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือเครื่องเสมือนที่ได้รับการปกป้องซึ่งควบคุมโดยไฮเปอร์ไวเซอร์ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17

  • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องสามารถอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกจากกันเพื่อรองรับการดำเนินการต่างๆ เช่น ตัวอย่างสำหรับการลงทะเบียน แต่ต้องยังคงแก้ไขไม่ได้

• [C-2-6] ต้องไม่อนุญาตให้แอปพลิเคชันของบุคคลที่สามแยกความแตกต่างระหว่าง การลงทะเบียนไบโอเมตริกแต่ละรายการ

• [C-2-7] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลนั้นได้หรือ ข้อมูลใดๆ ที่ได้จากข้อมูลดังกล่าว (เช่น การฝัง) ไปยัง Application Processor ภายนอกบริบทของ TEE หรือเครื่องเสมือนที่ได้รับการปกป้องซึ่งควบคุม โดยไฮเปอร์ไวเซอร์ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17 การอัปเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือก่อนหน้าจะไม่ได้รับการยกเว้นจาก [C-2-7]

• [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, รูปแบบ, รหัสผ่าน) ทุกๆ 72 ชั่วโมงหรือน้อยกว่า

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

• [C-3-6] ต้องเปิดใช้คีย์ Keystore ที่มีข้อมูลไบโอเมตริกสำหรับแอปพลิเคชันของบุคคลที่สาม

• [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_HINGE_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: การวัดระยะแบบหนึ่งต่อหลายรายการที่กำหนดโดย FiRa STATIC STS DS-TWR โหมดเลื่อน การวัดระยะช่วง 200 มิลลิวินาที กรณีการใช้งานทั่วไป สมาร์ทโฟนโต้ตอบกับอุปกรณ์อัจฉริยะหลายเครื่อง

  • CONFIG_ID_3: เหมือนกับ CONFIG_ID_1 ยกเว้นว่าจะไม่มีการรายงานข้อมูลมุมของการมาถึง (AoA)

  • CONFIG_ID_4: เหมือนกับ CONFIG_ID_1 ยกเว้นว่าจะเปิดใช้โหมดความปลอดภัย P-STS

  • CONFIG_ID_5: เหมือนกับ CONFIG_ID_2 ยกเว้นว่าจะเปิดใช้โหมดความปลอดภัย P-STS

  • CONFIG_ID_6: เหมือนกับ CONFIG_ID_3 ยกเว้นว่าจะเปิดใช้โหมดความปลอดภัย P-STS

  • CONFIG_ID_7: เหมือนกับ CONFIG_ID_2 ยกเว้นว่าจะมีการเปิดใช้โหมดคีย์ของบุคคลที่ถูกควบคุมโดย P-STS

• [C-1-4] ต้องมีส่วนติดต่อผู้ใช้ที่อนุญาตให้ผู้ใช้สลับสถานะเปิด/ปิดของ วิทยุ UWB

• [C-1-5] ต้องบังคับใช้ว่าแอปที่ใช้คลื่นวิทยุ UWB ต้องมีUWB_RANGING สิทธิ์ (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)

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

7.3.14. เซ็นเซอร์ที่กำหนดเอง

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

สำหรับเซ็นเซอร์ดังกล่าว รหัสเซ็นเซอร์จะมีลักษณะดังนี้

• [C-0-1] ต้องสูงกว่า 65536

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

• [C-0-2] ต้องได้รับการปกป้องด้วยสิทธิ์ของแพลตฟอร์มหรือสิทธิ์ของระบบ

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

7.4.1. โทรศัพท์

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

• Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศ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 เป็น legacy จะเกิดสิ่งต่อไปนี้

• [C-4-1] ต้องไม่รายงาน NETWORK_TYPE_IWLAN ผ่าน NetworkRegistrationInfo#getAccessNetworkTechnology() เมื่อมีการรายงาน NetworkRegistrationInfo#getTransportType() เป็น TRANSPORT_TYPE_WWAN สําหรับอินสแตนซ์ NetworkRegistrationInfo เดียวกัน

หากการใช้งานอุปกรณ์รองรับการลงทะเบียน IP Multimedia Subsystem (IMS) รายการเดียว สำหรับทั้งฟีเจอร์บริการโทรศัพท์มัลติมีเดีย (MMTEL) และ บริการ Rich Communication Services (RCS) และคาดว่าจะปฏิบัติตาม ข้อกำหนดของผู้ให้บริการเครือข่ายมือถือเกี่ยวกับการใช้การลงทะเบียน IMS รายการเดียว สำหรับการรับส่งสัญญาณ IMS ทั้งหมด อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-5-1] ต้องประกาศ android.hardware.telephony.ims แฟล็กฟีเจอร์ และติดตั้งใช้งาน ImsService API สำหรับทั้ง MMTEL และ RCS User Capability Exchange API ให้เสร็จสมบูรณ์

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

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

• [C-6-1] SmsManager#sendTextMessage และ SmsManager#sendMultipartTextMessage ต้องส่งผลให้มีการเรียกใช้ CarrierMessagingService ที่เกี่ยวข้องเพื่อให้บริการฟังก์ชันการรับส่งข้อความ SmsManager#sendMultimediaMessage และ SmsManager#downloadMultimediaMessage ต้องส่งผลให้มีการเรียกใช้CarrierMessagingService ที่เกี่ยวข้องเพื่อจัดหาฟังก์ชันการรับส่งข้อความมัลติมีเดีย

• [C-6-2] แอปพลิเคชันที่กำหนดโดย android.provider.Telephony.Sms#getDefaultSmsPackage ต้องใช้ API ของ SmsManager เมื่อส่งและรับข้อความ 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 ของกลุ่ม ที่ระบุเพื่อแสดงต่อผู้ใช้ในข้อเสนอที่ให้ข้อมูลสถานะ SIM ตัวอย่างของความสามารถดังกล่าว ได้แก่ ไอคอนสัญญาณโทรศัพท์มือถือในแถบสถานะหรือการ์ดการตั้งค่าด่วน

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

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

• [C-1-4] ต้องเขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์ม สำหรับการโทรที่ถูกบล็อก และต้องกรองการโทรที่มี BLOCKED_TYPE ออกจาก มุมมองบันทึกการโทรเริ่มต้นในแอปโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า

• [C-1-5] ต้องไม่เขียนถึง ผู้ให้บริการโทรศัพท์ สำหรับข้อความที่ถูกบล็อก

• [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งจะเปิดขึ้น พร้อมกับ Intent ที่แสดงผลโดยเมธอด TelecomManager.createManageBlockedNumbersIntent()

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

• ควรย้ายหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0

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

7.4.1.2. Telecom API

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony.calling จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับ API ConnectionService ที่อธิบายไว้ใน SDK

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

• [C-1-3] ต้องมีแอปพลิเคชันที่ใช้ InCallService

• [C-SR-1] ขอแนะนำอย่างยิ่งให้แจ้งผู้ใช้ว่าการรับสายเรียกเข้าจะทำให้สายที่กำลังคุยอยู่หลุด

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

• [C-SR-2] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรศัพท์เริ่มต้นที่ แสดงรายการบันทึกการโทรและชื่อแอปของบุคคลที่สามในบันทึกการโทร เมื่อแอปของบุคคลที่สามตั้งค่า EXTRA_LOG_SELF_MANAGED_CALLS คีย์พิเศษใน PhoneAccount เป็น true

• [C-SR-3] ขอแนะนำอย่างยิ่งให้จัดการเหตุการณ์ KEYCODE_MEDIA_PLAY_PAUSE และ KEYCODE_HEADSETHOOK ของชุดหูฟังเสียงสำหรับ API android.telecom ตามด้านล่าง

  • โทร Connection.onDisconnect() เมื่อตรวจพบการกดเหตุการณ์สำคัญแบบสั้นระหว่างการโทรที่กำลังดำเนินอยู่

  • โทร Connection.onAnswer() เมื่อตรวจพบการกดเหตุการณ์สำคัญแบบสั้นระหว่างการโทรเข้า

  • เรียกใช้ Connection.onReject() เมื่อตรวจพบการกดเหตุการณ์สำคัญค้างระหว่างสายเรียกเข้า

  • สลับสถานะการปิดเสียงของ CallAudioState

7.4.1.3. การลดภาระการทำงานของ Keepalive NAT-T ของเครือข่ายมือถือ

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

• ควรมีการรองรับการส่งต่อการทำงานของฟีเจอร์ Keepalive ของเครือข่ายมือถือ

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

• [C-1-1] ต้องรองรับ SocketKeepAlive API

• [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ

• [C-1-3] ต้องรองรับช่อง Keepalive ของเครือข่ายมือถือพร้อมกันให้มากที่สุดเท่าที่ HAL ของวิทยุเครือข่ายมือถือรองรับ

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับสล็อต Keepalive ของเครือข่ายมือถืออย่างน้อย 3 สล็อตต่ออินสแตนซ์วิทยุ

หากการใช้งานอุปกรณ์ไม่รองรับการส่งต่อการทำงานของ Keepalive ของเครือข่ายมือถือ อุปกรณ์จะ

• [C-2-1] ต้องส่งคืน ERROR_UNSUPPORTED

7.4.2. IEEE 802.11 (Wi-Fi)

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

• ควรมีการรองรับ 802.11 อย่างน้อย 1 รูปแบบ

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

• [C-1-1] ต้องใช้ Android API ที่เกี่ยวข้อง

• [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ของฮาร์ดแวร์ android.hardware.wifi

• [C-1-3] ต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK

• [C-1-4] ต้องรองรับ mDNS และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251 หรือ ff02::fb) ในเวลาใดก็ตามที่ดำเนินการ รวมถึงเมื่อ หน้าจอไม่ได้อยู่ในสถานะที่ใช้งานอยู่ เว้นแต่จะไม่ได้ล็อกมัลติแคสต์ไว้และ แพ็กเก็ตถูกกรองโดย APF ไม่จำเป็นต้องใช้แพ็กเก็ตเพื่อดำเนินการ mDNS ที่แอปพลิเคชันขอผ่าน NsdManager API ในปัจจุบัน อย่างไรก็ตาม อุปกรณ์อาจกรองแพ็กเก็ต mDNS หากจำเป็น เพื่อให้การใช้พลังงานอยู่ในช่วงที่ข้อกำหนดด้านกฎระเบียบ ที่เกี่ยวข้องกับตลาดเป้าหมายกำหนด

• [C-1-5] ต้องไม่ถือว่าการเรียกใช้เมธอด API ของ WifiManager.enableNetwork() เป็นข้อบ่งชี้ที่เพียงพอในการเปลี่ยนNetwork ที่ใช้งานอยู่ในปัจจุบันซึ่งใช้โดยค่าเริ่มต้นสำหรับการรับส่งข้อมูลของแอปพลิเคชันและแสดงผล โดยเมธอด API ของ ConnectivityManager เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ ผู้ให้บริการอาจปิดใช้การเข้าถึงอินเทอร์เน็ตที่ผู้ให้บริการเครือข่ายรายอื่น (เช่น อินเทอร์เน็ตมือถือ) ให้บริการได้ก็ต่อเมื่อตรวจสอบได้สำเร็จว่าเครือข่าย Wi-Fi ให้บริการการเข้าถึงอินเทอร์เน็ต

• [C-1-6] ขอแนะนำอย่างยิ่งให้เมื่อมีการเรียกใช้เมธอด API ของ ConnectivityManager.reportNetworkConnectivity() ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และ เมื่อการประเมินระบุว่า Network ปัจจุบันไม่สามารถเข้าถึง อินเทอร์เน็ตได้อีกต่อไป ให้เปลี่ยนไปใช้เครือข่ายอื่นที่พร้อมใช้งาน (เช่น อินเทอร์เน็ตบนมือถือ) ซึ่งมีการเข้าถึงอินเทอร์เน็ต

• [C-1-7] ต้องสุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรม Probe Request หนึ่งครั้งที่จุดเริ่มต้นของการสแกนแต่ละครั้ง ขณะที่ STA ไม่ได้เชื่อมต่อ

• [C-1-8] ต้องใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ระหว่างการสแกน)

• [C-1-9] ต้องวนซ้ำหมายเลขลำดับคำขอ Probe ตามปกติ (ตามลำดับ) ระหว่างคำขอ Probe ในการสแกน

• [C-1-10] ต้องสุ่มหมายเลขลำดับคำขอ Probe ระหว่างคำขอ Probe สุดท้ายของการสแกนกับคำขอ Probe แรกของการสแกนครั้งถัดไป

• [C-SR-1] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางที่ใช้ สำหรับการสื่อสาร STA ทั้งหมดไปยังจุดเข้าใช้งาน (AP) ขณะเชื่อมโยงและ เชื่อมโยงแล้ว

  • อุปกรณ์ต้องใช้ที่อยู่ MAC แบบสุ่มที่แตกต่างกันสำหรับแต่ละ SSID (FQDN สำหรับ Passpoint) ที่อุปกรณ์สื่อสารด้วย

  • อุปกรณ์ต้องมีตัวเลือกให้ผู้ใช้ควบคุม การสุ่มต่อ SSID (FQDN สำหรับ Passpoint) โดยมีตัวเลือกแบบไม่สุ่มและ แบบสุ่ม และต้องตั้งค่าเริ่มต้นสำหรับการกำหนดค่า Wi-Fi ใหม่ ให้เป็นแบบสุ่ม

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้ BSSID แบบสุ่มสำหรับ AP ใดก็ตามที่สร้างขึ้น

  • ที่อยู่ MAC ต้องเป็นแบบสุ่มและคงอยู่ตาม SSID ที่ AP ใช้

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

หากการใช้งานอุปกรณ์รวมถึงการรองรับโหมดประหยัดพลังงาน 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] ต้องใช้ Android API ที่เกี่ยวข้อง ตามที่อธิบายไว้ในเอกสารประกอบของ SDK

• [C-1-2] ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct

• [C-1-3] ต้องรองรับการทำงานของ Wi-Fi ปกติ

• [C-1-4] ต้องรองรับการทำงานของ Wi-Fi และ Wi-Fi Direct พร้อมกัน

• [C-SR-1] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางสำหรับการเชื่อมต่อ Wi-Fi Direct ที่สร้างขึ้นใหม่ทั้งหมด

7.4.2.2. การตั้งค่าลิงก์โดยตรงที่ผ่านอุโมงค์ Wi-Fi

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

• ควรมีการรองรับ การตั้งค่าลิงก์โดยตรงแบบอุโมงค์ Wi-Fi (TDLS) ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

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

• [C-1-1] ต้องประกาศการรองรับ TDLS ผ่าน WifiManager.isTdlsSupported

• ควรใช้ TDL เฉพาะในกรณีที่เป็นไปได้และเป็นประโยชน์

• ควรมีฮิวริสติกและไม่ใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการเชื่อมต่อผ่านจุดเข้าใช้งาน Wi-Fi

7.4.2.3. Wi-Fi Aware

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

• ควรรองรับ Wi-Fi Aware

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

• [C-1-1] ต้องใช้ WifiAwareManager API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK

• [C-1-2] ต้องประกาศ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 และ onServiceDiscoveredWithinRange

7.4.2.4. Passpoint ของ Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 (Wi-Fi) จะต้องมีคุณสมบัติดังนี้

• ควรรองรับ Wi-Fi Passpoint

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Passpoint อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-1-2] ต้องใช้ WifiManager API ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบของ SDK

• [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้อง กับการค้นหาและการเลือกเครือข่าย เช่น Generic Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)

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

• [C-1-5] ต้องทำตามการติดตั้งใช้งาน AOSP เพื่อค้นหา จับคู่ และเชื่อมโยง กับเครือข่าย Passpoint

• [C-1-6] ต้องรองรับโปรโตคอลการจัดเตรียมอุปกรณ์อย่างน้อยชุดย่อยต่อไปนี้ ตามที่กำหนดไว้ใน Passpoint R2 ของ Wi-Fi Alliance: การตรวจสอบสิทธิ์ EAP-TTLS และ SOAP-XML

• [C-1-7] ต้องประมวลผลใบรับรองเซิร์ฟเวอร์ AAA ตามที่อธิบายไว้ใน ข้อกําหนด Hotspot 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] ต้องประกาศandroid.hardware.wifi.rttแฟล็กฟีเจอร์

• [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางสำหรับแต่ละ RTT Burst ซึ่งดำเนินการขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT ไม่ได้เชื่อมโยงกับ Access Point

• [C-1-4] ต้องมีความแม่นยำภายใน 2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการแจกแจงสะสม)

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รายงานอย่างถูกต้องภายใน 1.5 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสม)

7.4.2.6. Wi-Fi Keepalive Offload

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

• ควรมีการรองรับการลดภาระการทำงานของ 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. เชื่อถือเมื่อใช้ครั้งแรก (TOFU)

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

• [C-4-1] ต้องมีตัวเลือกให้ผู้ใช้เลือกใช้ TOFU

7.4.2.10. การตรวจหาฮาร์ดแวร์ใกล้เคียงด้วย Wi-Fi

7.4.3. บลูทูธ

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศandroid.hardware.vr.high_performance ฟีเจอร์ จะมีลักษณะดังนี้

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

Android รองรับบลูทูธและบลูทูธพลังงานต่ำ

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

• [C-2-1] ต้องประกาศฟีเจอร์แพลตฟอร์มที่เกี่ยวข้อง (android.hardware.bluetooth และ android.hardware.bluetooth_le ตามลำดับ) และใช้ API ของแพลตฟอร์ม

• ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVRCP, OBEX, HFP ฯลฯ ตามความเหมาะสมกับอุปกรณ์

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

• [C-3-1] ต้องประกาศฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le

• [C-3-2] ต้องเปิดใช้ API บลูทูธที่อิงตาม GATT (Generic Attribute Profile) ตามที่อธิบายไว้ในเอกสารประกอบ SDK และ android.bluetooth

• [C-3-3] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isOffloadedFilteringSupported() เพื่อระบุว่ามีการใช้ ตรรกะการกรองสำหรับคลาส API ของ ScanFilter หรือไม่

• [C-3-4] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isMultipleAdvertisementSupported() เพื่อระบุ ว่ารองรับการโฆษณาแบบประหยัดพลังงานหรือไม่

• [C-3-5] ต้องใช้การหมดเวลาของที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) ไม่เกิน 15 นาที และหมุนเวียนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์ใช้ BLE อย่างต่อเนื่องเพื่อสแกนหรือโฆษณา ช่วงหมดเวลาต้องสุ่มระหว่าง 5 ถึง 15 นาทีด้วยเพื่อป้องกันการโจมตีแบบกำหนดเวลา

• ควรสนับสนุนการส่งต่อตรรกะการกรองไปยังชิปเซ็ตบลูทูธ เมื่อใช้ ScanFilter API

• ควรสนับสนุนการส่งต่อการสแกนแบบเป็นชุดไปยังชิปเซ็ตบลูทูธ

• ควรรองรับโฆษณาหลายรายการที่มีช่องอย่างน้อย 4 ช่อง

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

• [C-4-1] ต้องมีส่วนประกอบที่ผู้ใช้สามารถใช้เพื่อเปิด/ปิดค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable()

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

• [C-5-1] ต้องแสดง true สำหรับ BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID)

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

• [C-6-1] ต้องจำกัดการเข้าถึงข้อมูลเมตาของบลูทูธ (เช่น ผลการสแกน) ซึ่งอาจใช้เพื่อหาตำแหน่งของอุปกรณ์ เว้นแต่แอปที่ขอจะผ่านการตรวจสอบสิทธิ์ android.permission.ACCESS_FINE_LOCATION ตามสถานะปัจจุบันในเบื้องหน้า/เบื้องหลัง

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธหรือบลูทูธพลังงานต่ำ และไฟล์ Manifest ของแอปไม่มีการประกาศจากนักพัฒนาแอปที่ระบุว่า ไม่ได้ดึงข้อมูลตำแหน่งจากบลูทูธ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-6-2] ต้องควบคุมการเข้าถึงบลูทูธด้วยandroid.permission.ACCESS_FINE_LOCATION

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioSupported() API จะมีลักษณะดังนี้

• [C-7-1] ต้องรองรับไคลเอ็นต์แบบ Unicast

• [C-7-2] ต้องรองรับ 2M PHY

• [C-7-3] ต้องรองรับการโฆษณาแบบขยายของ LE

• [C-7-4] ต้องรองรับการเชื่อมต่อ CIS อย่างน้อย 2 รายการใน CIG

• [C-7-5] ต้องเปิดใช้ไคลเอ็นต์ BAP แบบ Unicast, ผู้ประสานงานชุด CSIP, เซิร์ฟเวอร์ MCP, ตัวควบคุม VCP และเซิร์ฟเวอร์ CCP พร้อมกัน

• [C-SR-1] ขอแนะนำอย่างยิ่งให้เปิดใช้ไคลเอ็นต์ HAP Unicast

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioBroadcastSourceSupported() API จะมีลักษณะดังนี้

• [C-8-1] ต้องรองรับลิงก์ BIS อย่างน้อย 2 ลิงก์ใน BIG

• [C-8-2] ต้องเปิดใช้แหล่งที่มาของการออกอากาศ BAP และผู้ช่วยการออกอากาศ BAP พร้อมกัน

• [C-8-3] ต้องรองรับการโฆษณาเป็นระยะของ LE

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API จะมีลักษณะดังนี้

• [C-9-1] ต้องรองรับ PAST (การโอนการซิงค์การโฆษณาเป็นระยะ)

• [C-9-2] ต้องรองรับการกระจายข้อมูลเป็นระยะของ LE

หากการใช้งานอุปกรณ์ประกาศ FEATURE_BLUETOOTH_LE จะมีข้อกำหนดดังนี้

• [C-10-1] ต้องมีการวัด RSSI ภายใน +/-9 dB สำหรับการวัด 95% ที่ระยะ 1 ม. จากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH ในสภาพแวดล้อมที่มีแนวสายตา

• [C-10-2] ต้องมีการแก้ไข Rx/Tx เพื่อลดความเบี่ยงเบนต่อช่อง เพื่อให้การวัดในแต่ละช่องจาก 3 ช่อง และในแต่ละเสาอากาศ (หากใช้หลายเสาอากาศ) อยู่ภายใน +/-3 dB ของกันและกันสำหรับการวัด 95%

หากการใช้งานอุปกรณ์ประกาศ FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING จะมีข้อกำหนดดังนี้

• [C-11-1] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le.channel_sounding

• [C-11-2] ต้องรายงานช่วงอย่างถูกต้องภายใน +/- 0.5 ม. ที่เปอร์เซ็นไทล์ที่ 90 ตามที่คำนวณด้วยฟังก์ชันการกระจายสะสมที่ระยะทาง 1 ม.

หากการใช้งานอุปกรณ์ประกาศ FEATURE_BLUETOOTH_LE จะมีข้อกำหนดดังนี้

• [C-SR-2] ขอแนะนำอย่างยิ่งให้วัดและชดเชยออฟเซ็ต Rx เพื่อ ให้มั่นใจว่าค่ามัธยฐานของ BLE RSSI คือ -60 dBm +/-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 Communication

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

• ควรมีตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near-Field Communications (NFC)

• [C-0-1] ต้องใช้ API android.nfc.NdefMessage และ android.nfc.NdefRecord แม้ว่าจะไม่รองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc เนื่องจากคลาสต่างๆ แสดงรูปแบบการแสดงข้อมูลที่ไม่ขึ้นกับโปรโตคอล

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

• [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()

• ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ได้ ตามที่ระบุไว้ด้านล่าง

• [C-1-2] ต้องทำหน้าที่เป็นเครื่องอ่าน/เขียนของ NFC Forum ได้ (ตามที่กำหนดไว้ในข้อกำหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้

  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • แท็ก NFC Forum ประเภท 2, 3, 4, 5 (กำหนดโดย NFC Forum)

• [C-SR-1] ขอแนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่า แม้ว่ามาตรฐาน NFC จะระบุว่า "แนะนำอย่างยิ่ง" แต่ คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตมีแผนที่จะเปลี่ยน เป็น "ต้อง" มาตรฐานเหล่านี้เป็นตัวเลือกในเวอร์ชันนี้ แต่จะต้องใช้ในเวอร์ชันต่อๆ ไป เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ เพื่อให้อุปกรณ์อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้

• [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นหา NFC

• ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานโดยมี หน้าจอที่ใช้งานอยู่และหน้าจอล็อกปลดล็อกแล้ว

• ควรอ่านบาร์โค้ดและ URL (หากมีการเข้ารหัส) ของผลิตภัณฑ์ Thinfilm NFC Barcode ได้

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

Android รองรับโหมด Host Card Emulation (HCE) ของ NFC

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

• [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce

• [C-2-2] ต้องรองรับ API ของ NFC HCE ตามที่กำหนดไว้ใน Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE สำหรับ NfcF และติดตั้งใช้งานฟีเจอร์สำหรับแอปพลิเคชันของบุคคลที่สาม จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องรายงานandroid.hardware.nfc.hcefค่าคงที่ของฟีเจอร์

• [C-3-2] ต้องใช้ NfcF Card Emulation APIs ตามที่กำหนดไว้ใน Android SDK

หากการใช้งานอุปกรณ์รวมถึงการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้ และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทของเครื่องอ่าน/เครื่องเขียน อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-4-1] ต้องใช้ Android API ที่เกี่ยวข้องตามที่ระบุไว้ใน Android SDK

• [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android จึงไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5. โปรโตคอลและ API ของเครือข่าย

7.4.5.1. ความสามารถของเครือข่ายขั้นต่ำ

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

• [C-0-1] ต้องรองรับการเชื่อมต่อเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่สามารถรองรับ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่ตรงตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, Ethernet และ Bluetooth PAN

• ควรมีการรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายจริง (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก

• อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ

7.4.5.2. IPv6

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

• [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API ดั้งเดิม เช่น ซ็อกเก็ต AF_INET6

• [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น

• ต้องตรวจสอบว่าการสื่อสาร IPv6 มีความน่าเชื่อถือเท่ากับ IPv4 เช่น

• [C-0-4] ต้องรักษาการเชื่อมต่อ IPv6 ในโหมดพัก

• [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่รองรับ IPv6 ซึ่งใช้ช่วงเวลาที่ RA มีผลอย่างน้อย 180 วินาที

• [C-0-6] ต้องให้การเชื่อมต่อ IPv6 โดยตรงแก่แอปพลิเคชันของบุคคลที่สาม กับเครือข่ายเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ ที่เกิดขึ้นในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort และ API ของ NDK เช่น getsockname() หรือ IPV6_PKTINFO ต้องแสดง IP Address และพอร์ตที่ใช้จริงในการส่งและรับแพ็กเก็ตใน เครือข่าย และแสดงเป็น IP ต้นทางและพอร์ตไปยังเซิร์ฟเวอร์อินเทอร์เน็ต (เว็บ)

ระดับการรองรับ IPv6 ที่จำเป็นจะขึ้นอยู่กับประเภทเครือข่าย ดังที่แสดงใน ข้อกำหนดต่อไปนี้

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับการทำงานแบบ Dual-stack และ IPv6 เท่านั้นบน Wi-Fi

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

• [C-2-1] ต้องรองรับการทำงานแบบ Dual-stack และ IPv6 เท่านั้นใน อีเทอร์เน็ต

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

• [C-3-1] ต้องรองรับการทำงานของ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ Dual-Stack) บน เซลลูลาร์

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

• [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสารประกอบ SDK สำหรับ android.net.LinkProperties.getPrivateDnsServerName และ android.net.LinkProperties.isPrivateDnsActive สำหรับการจราจรของข้อมูลในเครือข่ายทั้งหมดที่ไม่ได้สื่อสารกับ แคปทีฟพอร์ทัลอย่างชัดเจน

• [C-1-5] ต้องตรวจสอบว่าขณะที่ผู้ใช้เข้าสู่ระบบแคปทีฟพอร์ทัล เครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่แสดงโดย ConnectivityManager.getActiveNetwork ConnectivityManager.registerDefaultNetworkCallback และใช้โดยค่าเริ่มต้นโดย Java Networking API เช่น java.net.Socket และ API ดั้งเดิม เช่น connect()) เป็นเครือข่ายอื่นที่พร้อมใช้งาน ซึ่งให้สิทธิ์เข้าถึงอินเทอร์เน็ต หากมี

7.4.6. การตั้งค่าการซิงค์

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

• [C-0-1] ต้องมีการตั้งค่าการซิงค์อัตโนมัติหลักเปิดอยู่โดยค่าเริ่มต้นเพื่อให้ เมธอด getMasterSyncAutomatically() แสดงผลเป็น "จริง"

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 ต้องมีสิทธิ์ UWB_RANGING (ภายใต้กลุ่มสิทธิ์ NEARBY_DEVICES)

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ผ่านการทดสอบการรับรองและความสอดคล้องที่เกี่ยวข้องซึ่งกำหนดโดยองค์กรมาตรฐาน รวมถึง FIRA, CCC และ CSA

• [C-1-6] ต้องตรวจสอบว่าการวัดระยะทางอยู่ภายใน +/-15 ซม. สำหรับ การวัด 95% ในสภาพแวดล้อมที่มีแนวสายตาที่ระยะ 1 ม. ในห้องที่ไม่สะท้อนแสง

• [C-1-7] ต้องตรวจสอบว่าค่ามัธยฐานของการวัดระยะทางที่ 1 ม. จากอุปกรณ์อ้างอิงอยู่ในช่วง [0.75 ม., 1.25 ม.] โดยวัดระยะทางความจริง จากขอบด้านบนของ DUT

• [C-SR-2] ขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดผล ที่ระบุไว้ใน ข้อกําหนดในการปรับเทียบการตรวจหาการเข้าพัก

7.5 กล้องถ่ายรูป

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศ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

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว และแอปพลิเคชันกล้องที่ติดตั้งไว้ล่วงหน้า จัดการ Intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE หรือ MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE จะมีลักษณะดังนี้

• [C-1-4] ต้องตรวจสอบว่าเมื่อจัดการ Intent เหล่านี้ แอปกล้องที่ติดตั้งไว้ล่วงหน้า จะนำตำแหน่งของผู้ใช้ออกจากข้อมูลเมตาของรูปภาพก่อนส่งไปยัง แอปพลิเคชันที่รับซึ่งไม่มี ACCESS_FINE_LOCATION

• [C-1-5] ต้องตรวจสอบว่ารูปภาพเคลื่อนไหวที่ส่งคืนใช้ข้อกำหนดรูปแบบรูปภาพเคลื่อนไหว เวอร์ชัน 1.0

หากการใช้งานอุปกรณ์รองรับความสามารถในการแสดงผล HDR 10 บิต อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรองรับโปรไฟล์ HLG HDR อย่างน้อยสำหรับอุปกรณ์กล้องทุกเครื่อง ที่รองรับเอาต์พุต 10 บิต

• [C-2-2] ต้องรองรับเอาต์พุต 10 บิตสำหรับกล้องหลักด้านหลังหรือกล้องหลักด้านหน้า

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอาต์พุต 10 บิตสำหรับกล้องหลักทั้ง 2 ตัว

• [C-2-3] ต้องรองรับโปรไฟล์ HDR เดียวกันสำหรับกล้องย่อยจริงทั้งหมดที่BACKWARD_COMPATIBLEใช้ได้ของกล้องตรรกะ และกล้องตรรกะเอง

สำหรับอุปกรณ์กล้องแบบตรรกะที่รองรับ 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

• ควรมีการโฟกัสอัตโนมัติของฮาร์ดแวร์หรือซอฟต์แวร์ ในไดรเวอร์กล้อง (โปร่งใสต่อซอฟต์แวร์แอปพลิเคชัน)

• อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)

• อาจมีแฟลช

หากกล้องมีแฟลช ให้ทำดังนี้

• [C-2-1] ต้องไม่เปิดหลอดแฟลชขณะที่android.hardware.Camera.PreviewCallbackอินสแตนซ์ได้รับการลงทะเบียน บนพื้นผิวตัวอย่างกล้อง เว้นแต่แอปพลิเคชันจะเปิดใช้ แฟลชอย่างชัดเจนโดยการเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของออบเจ็กต์ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับ แอปพลิเคชันกล้องของระบบในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สาม ที่ใช้ Camera.PreviewCallback เท่านั้น

7.5.2. กล้องหน้า

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

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

• อาจมีกล้องหน้า

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front

• [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)

• [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็น กล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเดียวในอุปกรณ์ก็ตาม

• [C-1-4] ตัวอย่างกล้องต้องมีการมิเรอร์ในแนวนอนเทียบกับ การวางแนวที่แอปพลิเคชันระบุเมื่อแอปพลิเคชันปัจจุบันได้ ขออย่างชัดเจนให้หมุนการแสดงผลของกล้อง ผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน ตัวอย่างต้องได้รับการมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์เมื่อแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนจอแสดงผลของกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation()

• [C-1-5] ต้องไม่มิเรอร์สตรีมภาพนิ่งหรือวิดีโอที่จับภาพสุดท้าย ซึ่งส่งคืนไปยังการเรียกกลับของแอปพลิเคชันหรือคอมมิตไปยังที่เก็บข้อมูลสื่อ

• [C-1-6] ต้องมิเรอร์รูปภาพที่แสดงโดยการดูภายหลังในลักษณะเดียวกับ สตรีมรูปภาพตัวอย่างของกล้อง

• อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับ กล้องด้านหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

หากการติดตั้งใช้งานอุปกรณ์หมุนได้โดยผู้ใช้ (เช่น โดยอัตโนมัติผ่านเครื่องวัดความเร่งหรือด้วยตนเองผ่านข้อมูลจากผู้ใช้):

• [C-2-1] พรีวิวของกล้องต้องเป็นภาพที่ปรับให้เหมือนภาพในกระจกในแนวนอนเมื่อเทียบกับการวางแนวปัจจุบันของอุปกรณ์

7.5.3. กล้องภายนอก

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

• อาจรองรับกล้องหลายตัว

• MAY รองรับการเข้ารหัสวิดีโอที่อิงตามกล้อง

หากรองรับการเข้ารหัสวิดีโอที่ใช้กล้อง ให้ทำดังนี้

• [C-2-1] การติดตั้งใช้งานอุปกรณ์ต้องเข้าถึงสตรีมที่ไม่ได้เข้ารหัส / MJPEG พร้อมกัน (ความละเอียด QVGA ขึ้นไป) ได้

7.5.4. ลักษณะการทำงานของ Camera API

Android มีแพ็กเกจ API 2 รายการสำหรับเข้าถึงกล้อง โดย API android.hardware.camera2 ที่ใหม่กว่าจะแสดงการควบคุมกล้องระดับล่างให้กับแอป ซึ่งรวมถึงโฟลว์การสตรีม/การถ่ายภาพต่อเนื่องแบบไม่มีการคัดลอกที่มีประสิทธิภาพ และการควบคุมต่อเฟรมของค่าแสง เกน เกนสมดุลสีขาว การแปลงสี การลดสัญญาณรบกวน การเพิ่มความคมชัด และอื่นๆ

เราได้ทำเครื่องหมายแพ็กเกจ API รุ่นเก่า android.hardware.Camera ว่าเลิกใช้งานแล้วใน Android 5.0 แต่แอปยังคงใช้แพ็กเกจนี้ได้ การติดตั้งใช้งานอุปกรณ์ Android ต้องรับประกันการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK

ฟีเจอร์ทั้งหมดที่ใช้ร่วมกันระหว่างคลาส android.hardware.Camera ที่เลิกใช้งานแล้วกับแพ็กเกจ android.hardware.camera2 ที่ใหม่กว่าจะต้องมีประสิทธิภาพและคุณภาพเทียบเท่ากันในทั้ง 2 API เช่น เมื่อใช้การตั้งค่าที่เทียบเท่ากัน ความเร็วและความแม่นยำของ โฟกัสอัตโนมัติต้องเหมือนกัน และคุณภาพของรูปภาพที่ถ่าย ต้องเหมือนกัน ฟีเจอร์ที่ขึ้นอยู่กับความหมายที่แตกต่างกันของ API ทั้ง 2 รายการไม่จำเป็นต้องมีความเร็วหรือคุณภาพที่ตรงกัน แต่ควรตรงกัน ให้ได้มากที่สุด

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

• [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับตัวอย่าง ข้อมูลที่ระบุในการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.Camera.Parameters.setPreviewFormat(int)

• [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชัน ลงทะเบียนandroid.hardware.Camera.PreviewCallback อินสแตนซ์ และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบตัวอย่าง คือ YCbCr_420_SP ข้อมูลในไบต์[] ที่ส่งไปยัง onPreviewFrame() กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น

• [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับตัวอย่างกล้องของทั้งกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (ฮาร์ดแวร์ ตัวเข้ารหัสวิดีโอและกล้องอาจใช้รูปแบบพิกเซลดั้งเดิมใดก็ได้ แต่การติดตั้งใช้งานอุปกรณ์ ต้องรองรับการแปลงเป็น YV12)

• [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่ โฆษณาความสามารถ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities

• [C-0-5] ต้องยังคงใช้Camera API แบบเต็มที่รวมอยู่ในเอกสารประกอบของ Android SDK ไม่ว่าอุปกรณ์จะมีฮาร์ดแวร์โฟกัสอัตโนมัติหรือความสามารถอื่นๆ หรือไม่ก็ตาม เช่น กล้อง ที่ไม่มีโฟกัสอัตโนมัติยังคงต้องเรียกใช้android.hardware.Camera.AutoFocusCallbackอินสแตนซ์ที่ลงทะเบียน ไว้ (แม้ว่าการดำเนินการนี้จะ ไม่เกี่ยวข้องกับกล้องที่ไม่มีโฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการดำเนินการนี้ใช้กับ กล้องหน้าด้วย ตัวอย่างเช่น แม้ว่ากล้องหน้าส่วนใหญ่ จะไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับของ API ก็ยังต้อง "จำลอง" ตามที่อธิบายไว้

• [C-0-6] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ ในคลาส android.hardware.Camera.Parameters และคลาส android.hardware.camera2.CaptureRequest ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยอมรับหรือรู้จักค่าคงที่สตริง ที่ส่งไปยังandroid.hardware.Camera.setParameters()เมธอด นอกเหนือจากค่าคงที่ที่ระบุไว้ใน android.hardware.Camera.Parameters กล่าวคือ การใช้งานอุปกรณ์ต้อง รองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และต้องไม่ รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง เช่น การใช้งานอุปกรณ์ ที่รองรับการจับภาพโดยใช้เทคนิคการถ่ายภาพแบบ High Dynamic Range (HDR) ต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR

• [C-0-7] ต้องรายงานระดับการสนับสนุนที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK และรายงาน ค่าสถานะฟีเจอร์ของเฟรมเวิร์กที่เหมาะสม

• [C-0-8] ต้องประกาศความสามารถของกล้องแต่ละตัวของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศแฟล็กฟีเจอร์ที่เหมาะสมด้วย ต้องกำหนดแฟล็กฟีเจอร์หากอุปกรณ์กล้องที่เชื่อมต่อรองรับฟีเจอร์ดังกล่าว

• [C-0-9] ต้องออกอากาศCamera.ACTION_NEW_PICTURE Intent ทุกครั้งที่กล้องถ่ายรูปภาพใหม่และมีการเพิ่มรายการของ รูปภาพลงในร้านค้าสื่อ

• [C-0-10] ต้องออกอากาศCamera.ACTION_NEW_VIDEO เจตนาทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของ รูปภาพลงในร้านค้าสื่อ

• [C-0-11] ต้องเข้าถึงกล้องทั้งหมดได้ผ่าน API android.hardware.Camera ที่เลิกใช้งานแล้ว และเข้าถึงได้ผ่าน API android.hardware.camera2 ด้วย

• [C-0-12] ต้องตรวจสอบว่าไม่ได้ดัดแปลงลักษณะใบหน้า ซึ่งรวมถึงแต่ไม่จำกัดเพียงการดัดแปลงรูปทรงเรขาคณิตของใบหน้า สีผิวของใบหน้า หรือการปรับผิวหน้าให้เนียนสำหรับ android.hardware.camera2 หรือ android.hardware.Camera API

• [C-SR-1] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัวใน บริเวณใกล้เคียงและหันไปในทิศทางเดียวกัน ขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องตรรกะที่แสดงรายการความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปในทิศทางนั้นเป็นอุปกรณ์ย่อยทางกายภาพ

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

• [C-1-1] ต้องใช้ API กล้องดังกล่าวโดยใช้ android.hardware.camera2 API

• อาจให้แท็กและ/หรือส่วนขยายของผู้ให้บริการแก่ android.hardware.camera2 API

7.5.5. การวางแนวของกล้อง

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

• [C-1-1] ต้องวางแนวให้ด้านยาวของกล้องตรงกับด้านยาวของหน้าจอ กล่าวคือ เมื่อถืออุปกรณ์ใน แนวนอน กล้องต้องจับภาพใน แนวนอน การตั้งค่านี้จะมีผลไม่ว่าอุปกรณ์จะวางในแนวใด กล่าวคือ จะมีผลกับอุปกรณ์ที่วางในแนวนอนเป็นหลักและอุปกรณ์ที่วางในแนวตั้งเป็นหลัก

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

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

  • การใช้งานอุปกรณ์ที่ผู้ใช้หมุนไม่ได้ เช่น อุปกรณ์ยานยนต์

7.6. หน่วยความจำและพื้นที่เก็บข้อมูล

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

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

• [C-0-1] ต้องมี Download Manager ที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล และต้องสามารถ ดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้น

7.6.2. Application Shared Storage

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

• [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่แอปพลิเคชันใช้ร่วมกันได้ ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชัน" หรือตามเส้นทาง Linux "/sdcard" ที่ติดตั้ง
• [C-0-2] ต้องได้รับการกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งต่อเชื่อมโดยค่าเริ่มต้น กล่าวคือ "พร้อมใช้งาน" ไม่ว่าพื้นที่เก็บข้อมูลจะติดตั้งใช้งานในคอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อบันทึกข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ด Secure Digital) ก็ตาม
• [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] ต้องใช้คำเตือนในอินเทอร์เฟซผู้ใช้แบบข้อความป๊อปอัปหรือข้อความ Toast เพื่อเตือนผู้ใช้ เมื่อไม่มีสื่อบันทึกข้อมูลเสียบอยู่ในช่อง
• [C-1-2] ต้องมีสื่อบันทึกข้อมูลที่ฟอร์แมตเป็น FAT (เช่น การ์ด SD) หรือแสดง บนกล่องและสื่ออื่นๆ ที่มีจำหน่าย ณ เวลาที่ซื้อว่าต้องซื้อสื่อบันทึกข้อมูล แยกต่างหาก

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

• ควรใช้การติดตั้งใช้งาน AOSP ของพื้นที่เก็บข้อมูลที่แชร์ภายในของแอปพลิเคชัน
• อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-3-1] ต้องมีกลไกในการเข้าถึงข้อมูลในที่เก็บข้อมูลของแอปพลิเคชัน ที่ใช้ร่วมกันจากคอมพิวเตอร์โฮสต์
• ควรแสดงเนื้อหาจากทั้ง 2 เส้นทางการจัดเก็บอย่างโปร่งใสผ่าน บริการ Media Scanner ของ Android และ android.provider.MediaStore
• อาจใช้ที่เก็บข้อมูลจำนวนมากผ่าน USB แต่ควรใช้ Media Transfer Protocol เพื่อให้เป็นไปตามข้อกำหนดนี้

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

• ควรใช้ร่วมกับโฮสต์ MTP ของ Android อ้างอิง ซึ่งก็คือ Android File Transfer
• ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
• ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable

หากคาดว่าอุปกรณ์จะเป็นอุปกรณ์เคลื่อนที่ซึ่งแตกต่างจากโทรทัศน์ การใช้งานอุปกรณ์จะเป็นดังนี้

• [C-SR-1] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานพื้นที่เก็บข้อมูลแบบ Adoptable ใน ตำแหน่งที่เสถียรในระยะยาว เนื่องจากหากถอดการเชื่อมต่อโดยไม่ได้ตั้งใจอาจ ทําให้ข้อมูลสูญหาย/เสียหายได้

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

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลแบบ Adoptable

7.7 USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB จะต้องมีคุณสมบัติดังนี้

• ควรจะรองรับโหมดอุปกรณ์ USB

• ควรจะรองรับโหมดโฮสต์ USB

• ควรรองรับการปิดใช้การส่งสัญญาณข้อมูลผ่าน USB

7.7.1. โหมดอุปกรณ์ USB

หากการใช้งานอุปกรณ์มีพอร์ต 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 มาตรฐาน โดยต้องมีสิ่งใดสิ่งหนึ่งต่อไปนี้
  • พอร์ต USB Type-C ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์เป็นพอร์ต USB Type-C มาตรฐาน (อุปกรณ์ USB Type-C)
  • พอร์ต USB Type-A ในอุปกรณ์หรือมาพร้อมกับสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ ให้เป็นพอร์ต USB Type-A มาตรฐาน
  • พอร์ต USB ขนาดเล็ก AB ในอุปกรณ์ ซึ่งควรมาพร้อมกับสายที่แปลงเป็นพอร์ต USB Type-A มาตรฐาน
• [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB Type-A หรือ micro-AB เป็นพอร์ต USB 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 ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF) อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-3-1] ต้องรู้จักอุปกรณ์ MTP (โปรโตคอลการโอนสื่อ) ที่เชื่อมต่อจากระยะไกล และทำให้เข้าถึงเนื้อหาของอุปกรณ์ได้ผ่าน Intent ACTION_GET_CONTENT ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-4-1] ต้องใช้ฟังก์ชันการทำงานของ Dual Role Power (DRP) ตามที่กำหนดไว้ใน ข้อกำหนดเฉพาะของ USB Type-C (ส่วน 4.5.1.3.3) สำหรับพอร์ต DRP ในอุปกรณ์ที่มีช่องเสียบเสียง 3.5 มม. การตรวจหาแหล่งจ่ายไฟ USB (โหมดโฮสต์) อาจปิดอยู่โดยค่าเริ่มต้น แต่ผู้ใช้ต้องเปิดใช้ได้
• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort
  • ควรสนับสนุนอัตราการรับส่งข้อมูล USB SuperSpeed
  • ขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทด้านข้อมูลและ การจ่ายไฟ
• [C-SR-3] ขอแนะนำอย่างยิ่งว่าไม่ควรสนับสนุนโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียง ตามที่อธิบายไว้ในภาคผนวก ก ของข้อกำหนดสายเคเบิลและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2
• ควรใช้รูปแบบ Try.* ที่เหมาะสมที่สุดสำหรับ รูปแบบอุปกรณ์ เช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK

7.7.3. USB Power Delivery

7.8. เสียง

7.8.1. ไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีไมโครโฟน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
• [C-1-2] ต้องเป็นไปตามข้อกำหนดในการบันทึกเสียงในส่วนที่ 5.4
• [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงย่านใกล้อัลตราซาวด์ตามที่อธิบายไว้ ในส่วน 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
• [C-2-2] ต้องใช้ API การบันทึกเสียงอย่างน้อยเป็นแบบไม่มีการดำเนินการ ตามส่วนที่ 7

7.8.2. เอาต์พุตเสียง

หากการติดตั้งใช้งานอุปกรณ์มีลำโพงหรือพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น ช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์หรือพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB จะต้องมีลักษณะดังนี้

• [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
• [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
• [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับการเล่นที่ใกล้เคียงกับอัลตราซาวด์ตามที่อธิบายไว้ ในส่วน 7.8.3

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

• [C-2-1] ต้องไม่รายงานฟีเจอร์ android.hardware.audio.output
• [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นฟังก์ชันที่ไม่มีการดำเนินการอย่างน้อย

ในส่วนนี้ "พอร์ตเอาต์พุต" หมายถึงอินเทอร์เฟซจริง เช่น ช่องเสียบเสียง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลที่ใช้คลื่นวิทยุ เช่น บลูทูธ Wi-Fi หรือเครือข่ายมือถือ ไม่ถือว่าเป็นการรวม "พอร์ตเอาต์พุต"

7.8.2.1. พอร์ตเสียงแอนะล็อก

หากต้องการให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมสำหรับเสียงอื่นๆ ที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศ Android ได้ หากการใช้งานอุปกรณ์ มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้มี พอร์ตเสียงอย่างน้อย 1 พอร์ตเป็นช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์

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

• [C-1-1] ต้องรองรับการเล่นเสียงไปยังหูฟังสเตอริโอและชุดหูฟังสเตอริโอ ที่มีไมโครโฟน
• [C-1-2] ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับการต่อพิน 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.8V ~ 2.9V
• [C-1-7] ต้องตรวจหาและแมปกับรหัสปุ่มสำหรับช่วงความต้านทานสมมูลต่อไปนี้ระหว่างตัวนำไมโครโฟนกับตัวนำกราวด์ บนปลั๊กเสียง
  • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการเชื่อมต่อ OMTP
• [C-SR-3] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอ ที่มีไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์และรองรับไมโครโฟน และออกอากาศ android.intent.action.HEADSET_PLUG โดยมีค่าพิเศษของไมโครโฟนตั้งค่าเป็น 1 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรองรับการตรวจจับไมโครโฟนในอุปกรณ์เสริมเสียงที่เสียบอยู่

7.8.2.2. พอร์ตเสียงดิจิทัล

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.1

7.8.3. เกือบอัลตราซาวด์

เสียงย่านความถี่ใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz

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

• ต้องรายงานการรองรับความสามารถด้านเสียงย่านความถี่สูงอย่างถูกต้องผ่าน API AudioManager.getProperty ดังนี้

หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง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. ความสมบูรณ์ของสัญญาณ

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

• ควรมีเส้นทางสัญญาณเสียงที่ราบรื่นสำหรับทั้งสตรีมอินพุต และเอาต์พุตในอุปกรณ์พกพา ตามที่กำหนดโดยไม่มีข้อบกพร่อง ที่วัดได้ในระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ OboeTester "Automated Glitch Test"

การทดสอบต้องใช้ดองเกิลลูปแบ็กเสียง ที่ใช้ในแจ็ก 3.5 มม. โดยตรง และ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

ปัจจุบัน OboeTester รองรับเส้นทาง AAudio ดังนั้นควรทดสอบการทำงานที่ผิดพลาดโดยใช้ AAudio สำหรับการผสมผสานต่อไปนี้

โหมดประสิทธิภาพ	การแชร์	อัตราการสุ่มตัวอย่างเอาต์พุต	ในช่อง	Out Chans
LOW_LATENCY	พิเศษ	ไม่ได้ระบุ	1	2
LOW_LATENCY	พิเศษ	ไม่ได้ระบุ	2	1
LOW_LATENCY	แชร์	ไม่ได้ระบุ	1	2
LOW_LATENCY	แชร์	ไม่ได้ระบุ	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 dB
ไมโครโฟนหลักในตัวที่วัดโดยใช้ลำโพงอ้างอิงภายนอก	< 3.0%	>= 50 dB
ช่องเสียบ 3.5 มม. แบบแอนะล็อกในตัว ซึ่งทดสอบโดยใช้อะแดปเตอร์ Loopback	< 1%	>= 60 dB
อะแดปเตอร์ USB ที่มาพร้อมกับโทรศัพท์ ทดสอบโดยใช้อะแดปเตอร์ลูปแบ็ก	< 1.0%	>= 60 dB

7.9. Virtual Reality

Android มี API และเครื่องมือในการสร้างแอปพลิเคชัน "เทคโนโลยีความจริงเสมือน (VR)" รวมถึงประสบการณ์ VR บนอุปกรณ์เคลื่อนที่คุณภาพสูง การใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

7.9.1. โหมดความจริงเสมือน

Android รองรับโหมด VR ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลแบบสเตอริโอของการแจ้งเตือนและปิดใช้คอมโพเนนต์ UI ของระบบแบบตาเดียวในขณะที่แอปพลิเคชัน VR ได้รับโฟกัสจากผู้ใช้

7.9.2. โหมดความจริงเสมือน - ประสิทธิภาพสูง

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

• [C-1-1] ต้องมี Physical Core อย่างน้อย 2 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 แบบสลับตาที่ 60fps ด้วยบริบทการแสดงผล 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] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffers ที่มีเลเยอร์มากกว่า 1 เลเยอร์ รวมถึงรองรับการตั้งค่าสถานะและรูปแบบที่ระบุไว้ใน C-1-10
• [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps บีบอัดเป็นค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 fps-10 Mbps หรือ 2 อินสแตนซ์ของ 1920 x 1080 ที่ 60 fps-20 Mbps)
• [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องถอดรหัสได้อย่างน้อย 1920 x 1080 ที่ 30 FPS บีบอัดเป็นค่าเฉลี่ย 10 Mbps และควร ถอดรหัส 3840 x 2160 ที่ 30 FPS-20 Mbps ได้ (เทียบเท่ากับ อินสแตนซ์ 4 รายการของ 1920 x 1080 ที่ 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%
• อาจจัดสรรคอร์หลักแบบเฉพาะให้แก่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้า และอาจรองรับ API Process.getExclusiveCores เพื่อแสดงผลจำนวนคอร์ 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 ที่แนะนำ โดยมีความสัมพันธ์ของแอมพลิจูดที่สอดคล้องกัน
• ควรใช้การแมปค่าคงที่แบบสัมผัสที่ลิงก์เหล่านี้
• ควรปฏิบัติตามการประเมินคุณภาพ สำหรับ API ของ createOneShot() และ createWaveform()
• ควรยืนยันว่าผลลัพธ์ของ android.os.Vibrator.hasAmplitudeControl() API สาธารณะแสดงถึงความสามารถของเครื่องสั่นอย่างถูกต้อง
• ควรยืนยันความสามารถในการปรับขนาดแอมพลิจูดโดยเรียกใช้ android.os.Vibrator.hasAmplitudeControl()

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

• ควรยืนยันสถานะการติดตั้งใช้งานโดยเรียกใช้ API android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitivesSupported()
• ควรประเมินคุณภาพ สำหรับค่าคงที่แบบสัมผัส
• ควรยืนยันและอัปเดตการกำหนดค่าสำรองสำหรับ Primitive ที่ไม่รองรับหากจำเป็น ตามที่อธิบายไว้ในคำแนะนำในการใช้งาน สำหรับค่าคงที่
• ควรให้การสนับสนุนแบบสำรองเพื่อลดความเสี่ยงที่จะเกิดข้อผิดพลาดตามที่อธิบายไว้ที่นี่

7.11. คลาสประสิทธิภาพของสื่อ

คุณดูคลาสประสิทธิภาพของสื่อในการติดตั้งใช้งานอุปกรณ์ได้จาก android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API ข้อกำหนด สำหรับคลาสประสิทธิภาพสื่อจะกำหนดไว้สำหรับ 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 ของโหมดประหยัดพลังงานสแตนด์บายแอปและ Doze
• [C-1-2] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลาง หรือ DeviceConfig เพื่อจัดการการจำกัดงาน การปลุก และ เครือข่ายสำหรับแอปในแต่ละ Bucket สำหรับ App Standby
• [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวน กลุ่มการทำงานของแอปในโหมดสแตนด์บาย ที่ใช้สำหรับโหมดสแตนด์บายของแอป
• [C-1-4] ต้องใช้สแตนด์บายแอป Bucket และ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
• [C-1-5] ต้องส่งคืน true สำหรับ PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
• [C-1-6] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้แสดงแอปทั้งหมดที่ได้รับการยกเว้น จากสแตนด์บายแอปและโหมดประหยัดพลังงาน Doze หรือการเพิ่มประสิทธิภาพแบตเตอรี่ และต้องใช้ Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS เพื่อขอให้ผู้ใช้อนุญาตให้แอปไม่สนใจการเพิ่มประสิทธิภาพแบตเตอรี่
• [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการเปิดและ ปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
• [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการแสดงแอปทั้งหมด ที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงาน Doze

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

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การใช้งานอุปกรณ์ Android อาจ ใช้สถานะพลังงานขณะพักทั้ง 4 สถานะตามที่กำหนดโดย Advanced Configuration and 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 shell แก่นักพัฒนาแอป
• ควรระบุแหล่งที่มาของคอมโพเนนต์ฮาร์ดแวร์เองหากระบุแหล่งที่มาของ การใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์กับแอปพลิเคชันไม่ได้

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] ต้องรายงานผ่านเมธอด API ของ Process.getExclusiveCores() หมายเลขรหัสของคอร์แบบพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนสามารถจองได้
• [C-2-2] ต้องไม่อนุญาตให้กระบวนการในพื้นที่ผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ ที่แอปพลิเคชันใช้เพื่อเรียกใช้ในคอร์แบบเฉพาะ แต่สามารถอนุญาตให้กระบวนการเคอร์เนลบางอย่าง ทำงานได้ตามความจำเป็น

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

• [C-3-1] ต้องแสดงผลรายการว่างผ่านเมธอด API ของ Process.getExclusiveCores()

8.6. ขีดจำกัดหน่วยความจำของแอป

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

• อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ ไม่ได้อยู่ในเนมสเปซ android.\*

• [C-0-2] สิทธิ์ที่มี protectionLevel ของ PROTECTION_FLAG_PRIVILEGED ต้องให้เฉพาะแอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของ อิมเมจระบบ (รวมถึงไฟล์ APEX) และต้องอยู่ ภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและปฏิบัติตาม สิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็น เส้นทางที่ได้รับสิทธิ์

• [C-SR-1] ขอแนะนำอย่างยิ่งว่าควรให้สิทธิ์ที่มี protectionLevel ของ PROTECTION_SIGNATURE แก่บุคคลต่อไปนี้เท่านั้น

  • แอปที่ติดตั้งไว้ล่วงหน้าในอิมเมจระบบ (รวมถึงไฟล์ APEX)

  • แอปที่เพิ่มในรายการที่อนุญาตซึ่งมีสิทธิ์ที่อนุญาตหากไม่ได้รวมอยู่ในอิมเมจระบบ

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะขอสิทธิ์รันไทม์

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

• [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจ ว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ และต้องมี อินเทอร์เฟซเพื่อให้ผู้ใช้จัดการสิทธิ์รันไทม์ได้

• [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอป เว้นแต่ในกรณีต่อไปนี้

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

  หรือ

  • สิทธิ์รันไทม์จะได้รับ จากนโยบายการให้สิทธิ์เริ่มต้น หรือสำหรับการถือครองบทบาทของแพลตฟอร์ม

• [C-0-6] ต้องให้android.permission.RECOVER_KEYSTOREสิทธิ์ เฉพาะกับแอปของระบบที่ลงทะเบียน Recovery Agent ที่ได้รับการรักษาความปลอดภัยอย่างเหมาะสม Recovery Agent ที่ได้รับการรักษาความปลอดภัยอย่างเหมาะสมคือเอเจนต์ซอฟต์แวร์ในอุปกรณ์ ที่ซิงค์กับที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งมี ฮาร์ดแวร์ที่ปลอดภัยพร้อมการป้องกันที่เทียบเท่าหรือแข็งแกร่งกว่าที่ อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีแบบ Brute Force ในปัจจัยความรู้ของหน้าจอล็อก

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

• [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 ที่กำหนดเองเพื่อหลีกเลี่ยง ข้อจำกัดด้านสิทธิ์ที่กำหนดไว้ใน API setPermissionPolicy และ setPermissionGrantState

• [C-0-13] ต้องใช้ AppOpsManager API เพื่อบันทึกและติดตามการเข้าถึงข้อมูลแต่ละรายการและทุกรายการแบบเป็นโปรแกรมซึ่งได้รับการปกป้องโดยสิทธิ์ที่เป็นอันตรายจากกิจกรรมและบริการของ Android

• [C-0-14] ต้องมอบหมายบทบาทให้กับแอปพลิเคชันที่มีฟังก์ชันการทำงานที่ ตรงตามข้อกำหนดของบทบาทเท่านั้น

• [C-0-15] ต้องไม่กำหนดบทบาทที่ซ้ำกันหรือมีฟังก์ชันการทำงานที่ครอบคลุมกว่า บทบาทที่กำหนดโดยแพลตฟอร์ม

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

• [C-0-16] ต้องได้รับการป้องกันโดยสิทธิ์ของแพลตฟอร์มจาก android.permission-group.HEALTH หากมีสิทธิ์ที่เกี่ยวข้องใน HealthPermissions

• [C-0-17] ต้องมีสิทธิ์ของระบบที่กำหนดเองป้องกัน หากไม่มีสิทธิ์ของแพลตฟอร์มที่ตรงกับประเภทข้อมูลที่ต้องการ (เช่น ELECTROCARDIOGRAM)

หากอุปกรณ์รายงาน android.software.managed_users แสดงว่าอุปกรณ์มีลักษณะดังนี้

• [C-1-1] ต้องไม่ได้รับสิทธิ์ต่อไปนี้โดยอัตโนมัติจากผู้ดูแลระบบ

  • สถานที่ (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
  • กล้อง (CAMERA)
  • ไมโครโฟน (RECORD_AUDIO)
  • เซ็นเซอร์ร่างกาย (BODY_SENSORS)
  • สุขภาพ (HealthPermissions)
  • การเคลื่อนไหวร่างกาย (ACTIVITY_RECOGNITION)

หากอุปกรณ์รายงาน 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 Intent จะมีลักษณะดังนี้

• [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง Intent สำหรับ Intent ของ ACTION_MANAGE_OVERLAY_PERMISSION มีหน้าจอ UI เดียวกัน ไม่ว่าจะเป็นแอปที่เริ่มต้นหรือข้อมูลใดๆ ที่แอปนั้นระบุ

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin จะมีลักษณะดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์มีการติดตั้งแพ็กเกจใดๆ ที่มีบทบาทของ 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 API

9.2 UID และการแยกกระบวนการ

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

• [C-0-1] ต้องรองรับโมเดลแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID รูปแบบ Unix ที่ไม่ซ้ำกัน และในกระบวนการแยกต่างหาก
• [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการ ในฐานะรหัสผู้ใช้ Linux เดียวกัน โดยแอปพลิเคชันจะต้องได้รับการลงนามอย่างถูกต้อง และสร้างขึ้นตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3 สิทธิ์ของระบบไฟล์

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

• [C-0-1] ต้องรองรับโมเดลสิทธิ์การเข้าถึงไฟล์ของ Android ตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.4 สภาพแวดล้อมการดำเนินการอื่น

การติดตั้งใช้งานอุปกรณ์ต้องรักษาความสอดคล้องของโมเดลความปลอดภัยและสิทธิ์ของ Android แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นๆ นอกเหนือจากรูปแบบที่เรียกใช้งานได้ของ Dalvik หรือโค้ดแบบเนทีฟก็ตาม กล่าวคือ

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

• [C-0-2] รันไทม์อื่นต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากร ที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในAndroidManifest.xmlของรันไทม์ ผ่านกลไก <uses-permission>

• [C-0-3] รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ฟีเจอร์ที่ได้รับการปกป้องโดย Android ซึ่งจำกัดไว้สำหรับแอปพลิเคชันระบบ

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

• [C-0-5] รันไทม์สำรองต้องไม่เปิดตัว ให้สิทธิ์ หรือได้รับสิทธิ์ เข้าถึงแซนด์บ็อกซ์ที่สอดคล้องกับแอปพลิเคชัน Android อื่นๆ

• [C-0-6] รันไทม์สำรองต้องไม่เปิดตัว ไม่ได้รับ หรือไม่ให้สิทธิ์ แก่แอปพลิเคชันอื่นๆ ในการเข้าถึงสิทธิ์ของ Superuser (รูท) หรือสิทธิ์ของ รหัสผู้ใช้รายอื่น

• [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์สำรองไว้ใน อิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ จะต้องทำ Signing ด้วยคีย์ที่แตกต่าง จากคีย์ที่ใช้ทำ Signing แอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับผู้ใช้หลายราย ผู้ใช้ทั้งหมด (ยกเว้นผู้ใช้ที่สร้างขึ้นเพื่อเรียกใช้แอปเดียวกัน 2 อินสแตนซ์โดยเฉพาะ) จะมีลักษณะดังนี้

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

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

การติดตั้งใช้งานอุปกรณ์อาจสร้างโปรไฟล์ผู้ใช้เพิ่มเติมรายการเดียวประเภท android.os.usertype.profile.CLONEสำหรับผู้ใช้หลัก (และสำหรับผู้ใช้หลักเท่านั้น) เพื่อวัตถุประสงค์ในการเรียกใช้แอปเดียวกัน 2 อินสแตนซ์ อินสแตนซ์คู่เหล่านี้จะใช้พื้นที่เก็บข้อมูลที่แยกกันบางส่วน โดยจะแสดงต่อผู้ใช้ปลายทางในตัวเรียกใช้พร้อมกัน และจะปรากฏในมุมมองล่าสุดเดียวกัน เช่น อาจใช้เพื่อรองรับผู้ใช้ที่ติดตั้งแอปเดียว 2 อินสแตนซ์แยกกันในอุปกรณ์แบบ 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] ต้องอนุญาตให้เฉพาะแอปพลิเคชันในโปรไฟล์เพิ่มเติมที่มีกิจกรรมตัวเรียกใช้เข้าถึงรายชื่อติดต่อที่โปรไฟล์ผู้ใช้หลักเข้าถึงได้อยู่แล้วเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์สร้างโปรไฟล์ผู้ใช้เพิ่มเติมตามที่กล่าวถึงข้างต้น อุปกรณ์ดังกล่าวจะมีกล้องอย่างน้อย 1 ตัว และแอปพลิเคชันกล้องที่ติดตั้งไว้ล่วงหน้า จะจัดการ Intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE หรือ MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE โดยมีลักษณะดังนี้

• [C-5-1] ต้องอนุญาตให้แอปพลิเคชันของผู้ใช้หลักจัดการ Intent เหล่านี้ ซึ่งมาจากโปรไฟล์ผู้ใช้เพิ่มเติมนั้น

9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.telephony อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปที่กำหนดไว้ใน/data/misc/sms/codes.xml ไฟล์ในอุปกรณ์ โครงการโอเพนซอร์ส Android ต้นทางมี การใช้งานที่ตรงตามข้อกำหนดนี้

9.7 Security Features

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

แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ระบบการควบคุมการเข้าถึงที่จำเป็น (MAC) ของ Security-Enhanced Linux (SELinux), การแซนด์บ็อกซ์ seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่ แม้ว่าจะมีการติดตั้งใช้งาน SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ใต้เฟรมเวิร์ก Android ก็ตาม

• [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดความปลอดภัยและฟีเจอร์ความปลอดภัยที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android บล็อกการละเมิดดังกล่าวได้สำเร็จ แต่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดความปลอดภัยที่ไม่ได้บล็อกซึ่งส่งผลให้มีการใช้ช่องโหว่สำเร็จ

• [C-0-3] ต้องไม่ทำให้ SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ที่ติดตั้งใช้งาน ใต้เฟรมเวิร์ก Android สามารถกำหนดค่าได้สำหรับผู้ใช้หรือนักพัฒนาแอป

• [C-0-4] ต้องไม่อนุญาตให้แอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่น ผ่าน API (เช่น Device Administration API) กำหนดค่านโยบาย ที่ทำให้เกิดการหยุดทำงาน

• [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการได้แคบลงตามที่อธิบายไว้ ในเว็บไซต์โครงการโอเพนซอร์ส Android

• [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์ของแอปพลิเคชันเคอร์เนล ซึ่งอนุญาตให้กรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จาก โปรแกรมแบบมัลติเธรด Android Open Source Project ต้นทางเป็นไปตามข้อกำหนดนี้ โดยการเปิดใช้ seccomp-BPF ที่มีการซิงโครไนซ์ Threadgroup (TSYNC) ตามที่อธิบายไว้ ในส่วนการกำหนดค่าเคอร์เนลของ source.android.com

ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการป้องกันตนเองเป็นส่วนสำคัญของการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

• [C-0-7] ต้องใช้กลไกการป้องกันบัฟเฟอร์สแต็กเคอร์เนลล้น ตัวอย่างกลไกดังกล่าว ได้แก่ CC_STACKPROTECTOR_REGULAR และ CONFIG_CC_STACKPROTECTOR_STRONG

• [C-0-8] ต้องใช้การป้องกันหน่วยความจำเคอร์เนลอย่างเข้มงวดซึ่งโค้ดที่เรียกใช้งานได้ เป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวเรียกใช้งานไม่ได้และเขียนไม่ได้ และ ข้อมูลที่เขียนได้เรียกใช้งานไม่ได้ (เช่น เปิดใช้ทั้ง rodata และ CONFIG_STRICT_KERNEL_RWX)

• [C-0-9] ต้องใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกระหว่างพื้นที่ผู้ใช้และพื้นที่เคอร์เนล (เช่น CONFIG_HARDENED_USERCOPY) ในอุปกรณ์ที่จัดส่งพร้อมระดับ API 28 ขึ้นไป

• [C-0-10] ต้องไม่เรียกใช้หน่วยความจำในพื้นที่ของผู้ใช้เมื่อเรียกใช้ในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อมระดับ API 28 ขึ้นไปตั้งแต่แรก

• [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำในพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึง usercopy ปกติ (เช่น 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 ที่มีเอนโทรปีของโปรแกรมโหลดระบบปฏิบัติการผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

• [C-SR-3] ขอแนะนำอย่างยิ่งให้เปิดใช้การควบคุมโฟลว์ของโปรแกรม (CFI) ใน เคอร์เนลเพื่อเพิ่มการป้องกันการโจมตีด้วยการนำโค้ดกลับมาใช้ใหม่ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

• [C-SR-4] ขอแนะนำอย่างยิ่งไม่ให้ปิดใช้การตรวจสอบความสมบูรณ์ของโฟลว์การควบคุม (CFI), สแต็กการเรียกแบบเงา (SCS) หรือการล้างข้อมูลการล้นจำนวนเต็ม (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-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไป ในแซนด์บ็อกซ์ SELinux ต่อแอปพลิเคชัน โดยมีการจำกัด SELinux ต่อแอปใน ไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน

• ควรเก็บรักษานโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ system/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%) ในแอปพลิเคชันที่ใช้ตัวเลือกไฟล์ Manifest ของ android:memtagMode

• Heap Buffer Overflow
• ใช้หลังจากปล่อย
• ดับเบิลฟรี
• wild free (ไม่มีตัวชี้ที่ไม่ใช่ malloc)

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

• [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-once และรีบูตอุปกรณ์ เมื่อใช้ Bootloader ที่เข้ากันได้ โครงการโอเพนซอร์ส Android จะเป็นไปตามข้อกำหนดข้างต้นผ่านโปรโตคอล Bootloader ของ MTE

หากอุปกรณ์ประกาศว่าandroid.hardware.telephonyรองรับความสามารถของวิทยุ CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK และ มีโมเด็มมือถือที่รองรับการเชื่อมต่อ 2G การติดตั้งใช้งานอุปกรณ์ ต้องเป็นไปตามข้อกำหนดต่อไปนี้

• [C-SR-17] ขอแนะนำอย่างยิ่งให้ผู้ใช้มีตัวเลือกในการปิดใช้และ เปิดใช้ 2G

• [C-SR-18] ขอแนะนำอย่างยิ่งว่าไม่ควรลบล้างความสามารถของผู้ใช้ในการ ปิดและเปิดใช้ 2G ผ่านเอนทิตีอุปกรณ์อื่นๆ ยกเว้นผู้ดูแลระบบอุปกรณ์ที่ใช้ UserManager.DISALLOW_CELLULAR_2G

• [C-SR-19] ขอแนะนำอย่างยิ่งให้โทรหา TelephonyManager.setAllowedNetworkTypesForReason พร้อมระบุเหตุผลALLOWED_NETWORK_TYPES_REASON_ENABLE_2Gเพื่อให้เป็นไปตามข้อกำหนดนี้

• [C-SR-20] ขอแนะนำอย่างยิ่งให้ตรวจสอบการรองรับโมเด็มมือถือสำหรับ 2G โดยโทรไปที่ TelephonyManager.getSupportedRadioAccessFamily ดูรายละเอียดได้ที่ ปิดใช้ 2G

9.8. ความเป็นส่วนตัว

9.8.1. ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดยใช้ UsageStatsManager

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

• [C-0-1] ต้องเก็บประวัติผู้ใช้ดังกล่าวไว้ตามระยะเวลาการเก็บรักษาที่สมเหตุสมผล

• [C-SR-1] ขอแนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการติดตั้งใช้งาน AOSP

Android จัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ IncidentManager System API

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

• [C-0-2] ต้องมีเฉพาะฟิลด์ที่ทำเครื่องหมายด้วย DEST_AUTOMATIC ใน รายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager

• [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร StatsLog SDK หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม เหตุการณ์เหล่านั้นอาจใช้ตัวระบุ Atom ที่แตกต่างกันในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

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

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

• [C-0-2] ต้องแสดงคำเตือนแก่ผู้ใช้และขอความยินยอมของผู้ใช้อย่างชัดแจ้ง เพื่ออนุญาตให้บันทึกข้อมูลที่ละเอียดอ่อนซึ่งแสดงบนหน้าจอของผู้ใช้ ทุกครั้งที่มีการเปิดใช้เซสชันเพื่อบันทึกการแคสต์หน้าจอ หรือการบันทึกหน้าจอผ่าน MediaProjection.createVirtualDisplay() หรือ API ที่เป็นกรรมสิทธิ์

• [C-0-3] ต้องมีการแจ้งเตือนต่อเนื่องให้ผู้ใช้ทราบขณะที่เปิดใช้การแคสต์หน้าจอ หรือการบันทึกหน้าจอ AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงไอคอนการแจ้งเตือนต่อเนื่องในแถบสถานะ

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

• [C-0-4] นำข้อกำหนดออกใน Android 16

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

• [C-0-7] ต้องไม่บันทึก ฉาย หรือแคสต์ข้อมูลที่ละเอียดอ่อน เช่น

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

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่ บันทึกเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียง ที่เล่นบนอุปกรณ์นอกเหนือจากผ่าน System API ContentCaptureService หรือ วิธีการที่เป็นกรรมสิทธิ์อื่นๆ ที่อธิบายไว้ใน ส่วนที่ 9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลโดยรอบ จะต้องมีลักษณะดังนี้

• [C-1-1] ต้องมีการแจ้งเตือนต่อเนื่องให้ผู้ใช้ทุกครั้งที่เปิดใช้ฟังก์ชันนี้และมีการจับภาพ/บันทึกอย่างต่อเนื่อง

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

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

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

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

หลังจากแสดงเป็นเวลา 1 วินาทีแรกแล้ว ตัวบ่งชี้อาจเปลี่ยนรูปแบบ เช่น มีขนาดเล็กลง และไม่จำเป็นต้องแสดงตามที่นำเสนอและ เข้าใจในตอนแรก

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

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

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะมีข้อกำหนดดังนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทที่ระบุไว้ในส่วน 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X] เข้าถึงไมโครโฟนเท่านั้น

• [C-SR-2] ขอแนะนําอย่างยิ่งให้แสดงรายการแอปที่ใช้งานล่าสุดและที่ใช้งานอยู่ ซึ่งใช้ไมโครโฟนตามที่ส่งคืนจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับข้อความระบุแหล่งที่มา ที่เชื่อมโยงกับแอปเหล่านั้น

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

หากการใช้งานอุปกรณ์ประกาศ android.hardware.camera.any จะมีข้อกำหนดดังนี้

• [C-SR-4] ขอแนะนำอย่างยิ่งให้แสดงสัญญาณบอกสถานะกล้องถ่ายรูปเมื่อแอป เข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปเข้าถึงกล้อง ที่ถือบทบาทที่ระบุไว้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X] เท่านั้น

• [C-SR-5] ขอแนะนําอย่างยิ่งให้แสดงแอปที่ใช้งานล่าสุดและแอปที่ใช้งานอยู่โดยใช้ กล้องตามที่ส่งคืนจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น

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

9.8.3. การเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้ที่ขอความยินยอมจากผู้ใช้ก่อน อนุญาตให้เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่แชร์ผ่านพอร์ต USB

9.8.4. การจราจรของข้อมูลในเครือข่าย

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

• [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันล่วงหน้าสำหรับที่เก็บผู้ออกใบรับรอง (CA) ที่ระบบเชื่อถือ ตามที่ระบุ ในโครงการโอเพนซอร์ส Android ต้นทาง

• [C-0-2] ต้องจัดส่งพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า

• [C-0-3] ต้องแสดงประกาศเตือนแก่ผู้ใช้ที่ระบุว่าอาจมีการตรวจสอบการจราจรของข้อมูลในเครือข่าย เมื่อมีการเพิ่ม CA รูทของผู้ใช้

หากการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

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

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

• [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนที่จะเปิดใช้กลไกดังกล่าว เว้นแต่ว่า เครื่องมือควบคุมนโยบายด้านอุปกรณ์ จะเปิดใช้ VPN นั้นผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ ต้องได้รับการแจ้งเตือนเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้ความสามารถของผู้ใช้ในการเปิด/ปิดฟังก์ชัน "VPN แบบเปิดตลอดเวลา" ของแอป VPN ของบุคคลที่สาม การติดตั้งใช้งานดังกล่าวจะต้องมีลักษณะดังนี้

• [C-3-1] ต้องปิดใช้ความสามารถนี้สำหรับแอปที่ไม่รองรับบริการ VPN ที่เปิดตลอดเวลาในไฟล์ AndroidManifest.xml โดยตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

9.8.5. ตัวระบุอุปกรณ์

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

• [C-0-1] ต้องป้องกันการเข้าถึงหมายเลขซีเรียลของอุปกรณ์ และในกรณีที่เกี่ยวข้อง IMEI/MEID, หมายเลขซีเรียลของซิม และ International Mobile Subscriber Identity (IMSI) จากแอป เว้นแต่จะเป็นไปตามข้อกำหนดต่อไปนี้ข้อใดข้อหนึ่ง
  • เป็นแอปของผู้ให้บริการที่ลงนามแล้วซึ่งได้รับการยืนยันจากผู้ผลิตอุปกรณ์
  • ได้รับสิทธิ์ READ_PRIVILEGED_PHONE_STATE
  • มีสิทธิ์ของผู้ให้บริการตามที่กำหนดไว้ในสิทธิ์ของผู้ให้บริการ UICC
  • เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับREAD_PHONE_STATEสิทธิ์
  • (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดตามกฎระเบียบท้องถิ่น ที่แอปต้องตรวจหาการเปลี่ยนแปลงในข้อมูลประจำตัวของผู้สมัครใช้บริการ

9.8.6. ตัวป้องกันข้อมูลระดับระบบปฏิบัติการและข้อมูลโดยรอบ

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

• ข้อมูลสื่อ เช่น เสียงหรือวิดีโอที่อุปกรณ์บันทึกหรือเล่น

• เหตุการณ์การป้อนข้อมูล (เช่น คีย์ เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)

• หน้าจอหรือข้อมูลอื่นๆ ที่ส่งผ่าน AugmentedAutofillService ไปยังระบบ

• หน้าจอหรือข้อมูลอื่นๆ ที่เข้าถึงได้ผ่าน Content Capture API

• ข้อมูลแอปพลิเคชันที่ส่งไปยังระบบผ่าน AppSearchManager API และเข้าถึงได้ผ่าน AppSearchGlobalManager.query

• ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน TextClassifier API ไปยัง TextClassifier ของระบบ กล่าวคือ ไปยังบริการของระบบเพื่อทำความเข้าใจ ความหมายของข้อความ รวมถึงสร้างการดำเนินการถัดไปที่คาดการณ์ไว้ตาม ข้อความ

• ข้อมูลที่จัดทำดัชนีโดยการติดตั้งใช้งาน AppSearch ของแพลตฟอร์ม ซึ่งรวมถึงแต่ไม่จำกัดเพียงข้อความ กราฟิก ข้อมูลสื่อ หรือข้อมูลอื่นๆ ที่คล้ายกัน

• ข้อมูลเสียงที่ได้จากการใช้ SpeechRecognizer#onDeviceSpeechRecognizer() โดยการติดตั้งใช้งาน Speech Recognizer

• ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ Audio API อื่นๆ และไม่ส่งผลให้เกิดตัวบ่งชี้ที่ผู้ใช้มองเห็น

• ข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ API กล้องอื่นๆ และไม่ส่งผลให้เกิดตัวบ่งชี้ที่ผู้ใช้มองเห็น

• [C-1-7] ต้องมีตัวเลือกให้ผู้ใช้เลือกไม่ใช้ข้อมูลที่เก็บรวบรวม ผ่าน AppSearch หรือวิธีการที่เป็นกรรมสิทธิ์ไม่ให้แสดงในแพลตฟอร์ม Android (เช่น ตัวเรียกใช้)

• [C-SR-1] ขอแนะนำอย่างยิ่งว่าไม่ควรขอสิทธิ์ INTERNET

• [C-SR-2] ขอแนะนำอย่างยิ่งให้เข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างซึ่งได้รับการสนับสนุนจากการใช้งานโอเพนซอร์สที่พร้อมให้บริการแก่สาธารณะเท่านั้น

• [C-SR-4] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานด้วย Android SDK API หรือ ที่เก็บแบบโอเพนซอร์สที่คล้ายกันซึ่งเป็นของ OEM และ / หรือดำเนินการใน การติดตั้งใช้งานแบบแซนด์บ็อกซ์ (ดู 9.8.15 การติดตั้งใช้งาน API แบบแซนด์บ็อกซ์)

9.8.7. การเข้าถึงคลิปบอร์ด

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

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

• [C-0-2] ต้องล้างข้อมูลในคลิปบอร์ดภายใน 60 นาทีหลังจากที่วางหรืออ่านข้อมูลจากคลิปบอร์ดครั้งล่าสุด

9.8.8. ตำแหน่ง

ตำแหน่งประกอบด้วยข้อมูลในคลาสตำแหน่งของ Android( เช่น ละติจูด ลองจิจูด ระดับความสูง) รวมถึงตัวระบุที่แปลงเป็นตำแหน่งได้ ตำแหน่งอาจมีความละเอียดเท่ากับ DGPS (ระบบดาวเทียมนำร่องแบบดิฟเฟอเรนเชียล) หรือมีความหยาบเท่ากับตำแหน่งระดับประเทศ (เช่น ตำแหน่งรหัสประเทศ - MCC - รหัสโทรศัพท์มือถือของประเทศ)

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

• GPS/GNSS/DGPS/PPP

  • โซลูชันการกำหนดตำแหน่งทั่วโลกหรือระบบดาวเทียมนำร่องทั่วโลกหรือ โซลูชันการกำหนดตำแหน่งทั่วโลกแบบดิฟเฟอเรนเชียล
  • ซึ่งรวมถึงการวัด GNSS ไฟล์ข้อมูลดิบและสถานะ GNSS ด้วย
    • ตำแหน่งที่แน่นอนสามารถได้มาจากค่าจาก GNSS เต็มรูปแบบ

• เทคโนโลยีไร้สายที่มีตัวระบุที่ไม่ซ้ำกัน เช่น

  • จุดเข้าใช้งาน Wi-Fi (MAC, BSSID, ชื่อ หรือ SSID)
  • บลูทูธ/BLE (MAC, BSSID, ชื่อ หรือ SSID)
  • UWB (MAC, BSSID, ชื่อ หรือ SSID)
  • รหัสเสาสัญญาณโทรศัพท์ (3G, 4G, 5G ฯลฯ รวมถึงเทคโนโลยีโมเด็มมือถือทั้งหมดในอนาคต ที่มีตัวระบุที่ไม่ซ้ำกัน)

โปรดดู API ของ Android ที่ต้องใช้สิทธิ์ ACCESS_FINE_Location หรือ ACCESS_COARSE_Location เป็นจุดอ้างอิงหลัก

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

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

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

• [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() เป็นเซสชันฉุกเฉินที่ผู้ใช้เริ่ม (เช่น โทรหา 911 หรือส่งข้อความถึง 911) อย่างไรก็ตาม สำหรับยานยนต์ ยานพาหนะอาจเริ่มเซสชันฉุกเฉินโดยไม่ต้องมีการโต้ตอบจากผู้ใช้ที่ใช้งานอยู่ ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนดของ eCall )

• [C-0-4] ต้องคงความสามารถของ Emergency Location Bypass API ในการ ข้ามการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่ต้องเปลี่ยนการตั้งค่า

• [C-0-5] ต้องตั้งเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งของผู้ใช้โดยใช้สิทธิ์ ACCESS_BACKGROUND_LOCATION

9.8.9. แอปที่ติดตั้ง

โดยค่าเริ่มต้นแล้ว แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไม่ได้ (ดูระดับการมองเห็นแพ็กเกจในเอกสารประกอบ SDK ของ Android)

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

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

• [C-0-2] ต้องไม่อนุญาตให้แอปใดก็ตามมีสิทธิ์อ่านหรือเขียนไฟล์ในไดเรกทอรีเฉพาะของแอป ภายในพื้นที่เก็บข้อมูลภายนอก ข้อยกเว้นเพียงอย่างเดียวคือกรณีต่อไปนี้

  • สิทธิ์ของผู้ให้บริการพื้นที่เก็บข้อมูลภายนอก (เช่น แอปอย่าง DocumentsUI)

  • Download Provider ซึ่งใช้สิทธิ์ของผู้ให้บริการ "downloads" สำหรับ การดาวน์โหลดไฟล์ไปยังพื้นที่เก็บข้อมูลของแอป

  • แอปโปรโตคอลการโอนสื่อ (MTP) ที่แพลตฟอร์มลงนามซึ่งใช้ สิทธิ์ที่มีสิทธิ์พิเศษ ACCESS_MTP เพื่อเปิดใช้การโอนไฟล์ไปยัง อุปกรณ์อื่น

  • แอปที่ติดตั้งแอปอื่นๆ และมีสิทธิ์ INSTALL_PACKAGES จะเข้าถึงได้เฉพาะไดเรกทอรี "obb" เพื่อวัตถุประสงค์ในการจัดการ ไฟล์ขยาย APK

9.8.10. รายงานข้อบกพร่องด้านการเชื่อมต่อ

หากการใช้งานอุปกรณ์ประกาศแฟล็กฟีเจอร์ 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 ข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK

• [C-1-1] ต้องไม่แชร์ Blob ของข้อมูลที่เป็นของแอปเกินกว่าที่แอปตั้งใจจะอนุญาต (เช่น ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess() BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreManager.session#allowPublicAccess() ต้องไม่ได้รับการแก้ไข) การใช้งานการอ้างอิงของ AOSP เป็นไปตามข้อกำหนดเหล่านี้

• [C-1-2] ต้องไม่ส่งออกจากอุปกรณ์หรือแชร์กับแอปอื่นๆ ซึ่งแฮชที่ปลอดภัย ของ Blob ข้อมูล (ซึ่งใช้เพื่อควบคุมการเข้าถึง)

9.8.12. การรับรู้เพลง

Android รองรับกลไก สำหรับการติดตั้งใช้งานอุปกรณ์เพื่อขอการจดจำเพลงเมื่อมีการบันทึกเสียง และมอบสิทธิ์การจดจำเพลงให้กับแอปที่มีสิทธิ์ซึ่งใช้ MusicRecognitionService API ผ่าน System API MusicRecognitionManager

หากการใช้งานอุปกรณ์มีบริการที่ใช้ 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. SensorPrivacyManager

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

• [C-1-1] ต้องแสดงผล "จริง" อย่างถูกต้องสำหรับเมธอด API ที่เกี่ยวข้อง supportsSensorToggle()

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

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

9.8.14. ไม่มี

9.8.15. การติดตั้งใช้งาน Private Compute Core และแอปพลิเคชันเกตเวย์

9.8.16. ข้อมูลเสียงและกล้องอย่างต่อเนื่อง

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลใดๆ ตามที่อธิบายไว้ในส่วน 9.8.2 หรือส่วน 9.8.6 และหากการติดตั้งใช้งานดังกล่าว ใช้ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ Audio API อื่นๆ หรือข้อมูลกล้องที่ได้รับ ในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ Camera API อื่นๆ การติดตั้งใช้งานดังกล่าวจะต้องมีลักษณะดังนี้

• [C-0-1] ต้องบังคับใช้ตัวบ่งชี้ที่เกี่ยวข้อง (กล้องและ/หรือไมโครโฟนตาม ส่วนที่ 9.8.2 การบันทึก) เว้นแต่ในกรณีต่อไปนี้

  • การเข้าถึงนี้ดำเนินการในการติดตั้งใช้งานแซนด์บ็อกซ์ (ดู 9.8.15 การติดตั้งใช้งาน API แซนด์บ็อกซ์) ผ่านแพ็กเกจที่มีบทบาทต่อไปนี้อย่างน้อย 1 รายการ UI ของระบบ Intelligence System Ambient Audio Intelligence System Audio Intelligence System Notification Intelligence System Text Intelligence หรือ System Visual Intelligence

  • การเข้าถึงจะดำเนินการผ่านแซนด์บ็อกซ์ที่ใช้งานและบังคับใช้ผ่านกลไกใน AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector)

  • แอปพลิเคชันผู้ช่วยดิจิทัลจะเข้าถึงเสียงเพื่อวัตถุประสงค์ในการช่วยเหลือ โดยจะให้ SOURCE_HOTWORD เป็นแหล่งเสียง

  • ระบบจะดำเนินการเข้าถึงและใช้โค้ดโอเพนซอร์ส

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

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้การจัดการเดียวกัน (เช่น ปฏิบัติตามข้อจำกัดที่ระบุไว้ใน 9.8.2 การบันทึก, 9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลโดยรอบ, 9.8.15 การใช้งาน API แบบแซนด์บ็อกซ์ และ 9.8.16 ข้อมูลเสียงและกล้องอย่างต่อเนื่อง) กับข้อมูลกล้องที่มาจากอุปกรณ์ที่สวมใส่ได้ระยะไกล

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

• [C-1-1] ต้องแจ้งให้อุปกรณ์ที่สวมใส่ได้ระยะไกลแสดงตัวบ่งชี้เพิ่มเติมที่นั่น

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

• [C-2-1] ต้องตรวจสอบว่าการติดตั้งใช้งานดังกล่าวมาจากแพ็กเกจที่มีandroid.app.role.ASSISTANTบทบาท

• [C-2-2] ต้องตรวจสอบว่าการติดตั้งใช้งานดังกล่าวใช้ HotwordDetectionService และ/หรือ VisualQueryDetectionService Android API

9.8.17. การส่งข้อมูลทางไกล

Android จัดเก็บบันทึกของระบบและแอปโดยใช้ StatsLog API ระบบจะจัดการบันทึกเหล่านี้ผ่าน StatsManager API ซึ่งแอปพลิเคชันของระบบที่ได้รับสิทธิ์สามารถใช้ได้

นอกจากนี้ StatsManager ยังมีวิธีรวบรวมข้อมูลที่จัดอยู่ในหมวดหมู่ความเป็นส่วนตัว ที่มีความละเอียดอ่อนจากอุปกรณ์ที่มีกลไกการรักษาความเป็นส่วนตัว โดยเฉพาะอย่างยิ่ง StatsManager::query API ช่วยให้คุณสามารถค้นหาเมตริกที่จำกัด ซึ่งกำหนดไว้ ใน StatsLog

การใช้งานใดๆ ที่ค้นหาและรวบรวมเมตริกที่จำกัดจาก StatsManager:

• [C-0-1] ต้องเป็นแอปพลิเคชัน/การใช้งานเพียงอย่างเดียวในอุปกรณ์และมีสิทธิ์ READ_RESTRICTED_STATS

• [C-0-2] ต้องส่งเฉพาะข้อมูลการวัดและบันทึกของอุปกรณ์โดยใช้กลไกที่รักษาความเป็นส่วนตัว กลไกการรักษาความเป็นส่วนตัวได้รับการกําหนดให้เป็น "กลไกที่อนุญาตให้วิเคราะห์แบบรวมเท่านั้น และป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้กับผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้มีการตรวจสอบข้อมูลต่อผู้ใช้ (เช่น การใช้เทคโนโลยีความเป็นส่วนตัวเชิงอนุพันธ์ เช่น RAPPOR)

• [C-0-3] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น บัญชี) ในอุปกรณ์

• [C-0-4] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตาม ข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.17. Telemetry)

• [C-0-5] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้เปิด/ปิดใช้การรวบรวม การใช้ และการแชร์ข้อมูลการวัดและส่งข้อมูลที่รักษาความเป็นส่วนตัว

• [C-0-6] ต้องมีตัวเลือกให้ผู้ใช้ลบข้อมูลดังกล่าวที่การติดตั้งใช้งานรวบรวม หากมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์ หากผู้ใช้เลือกที่จะลบข้อมูล จะต้องนำข้อมูลทั้งหมดที่จัดเก็บไว้ในอุปกรณ์ออก

• [C-0-7] ต้องเปิดเผยการติดตั้งใช้งานโปรโตคอลพื้นฐานที่รักษาความเป็นส่วนตัว ในที่เก็บแบบโอเพนซอร์ส

• [C-0-8] ต้องบังคับใช้นโยบายการส่งออกข้อมูลในส่วนนี้เพื่อควบคุมการรวบรวม ข้อมูลในหมวดหมู่เมตริกที่จำกัดซึ่งกำหนดไว้ ใน StatsLog

9.8.18. ความเป็นส่วนตัวของฟังก์ชัน Agent

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 Direct Boot mode แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

• [C-0-2] ระบบยังคงต้องออกอากาศ Intent ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED เพื่อส่งสัญญาณไปยังแอปพลิเคชันที่รับรู้การบูตโดยตรงว่า ตำแหน่งที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) พร้อมใช้งานสำหรับผู้ใช้

9.9.2. ข้อกำหนดด้านการเข้ารหัส

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

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

• [C-0-3] ต้องเป็นไปตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้น โดยใช้การเข้ารหัส 2 วิธีต่อไปนี้วิธีใดวิธีหนึ่ง

  • การเข้ารหัสตามไฟล์ (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 ข้อมูลเมตาของระบบไฟล์คือข้อมูล เช่น ขนาดไฟล์ การเป็นเจ้าของ โหมด และแอตทริบิวต์เพิ่มเติม (xattrs)
• [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 บิต และทําหน้าที่เป็นตระกูลฟังก์ชันแบบสุ่มเทียม ในอินพุต
• [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยของการเข้ารหัสที่อิงตามไฟล์ (FBE) เดียวกัน เพื่อวัตถุประสงค์ในการเข้ารหัสที่แตกต่างกัน (เช่น ทั้งสำหรับการเข้ารหัสและการ ได้คีย์ หรือสำหรับอัลกอริทึมการเข้ารหัส 2 แบบที่แตกต่างกัน)
• [C-1-15] ต้องตรวจสอบว่าบล็อกทั้งหมดของเนื้อหาไฟล์ที่เข้ารหัสซึ่งไม่ได้ถูกลบในพื้นที่เก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์เริ่มต้น (IV) ที่ขึ้นอยู่กับทั้งไฟล์และออฟเซ็ตภายในไฟล์ นอกจากนี้ ชุดค่าผสมดังกล่าวทั้งหมดต้องแตกต่างกัน ยกเว้นในกรณีที่ การเข้ารหัสทำโดยใช้ฮาร์ดแวร์การเข้ารหัสในบรรทัดที่รองรับเฉพาะ ความยาว IV 32 บิต
• [C-1-16] ต้องตรวจสอบว่าชื่อไฟล์ที่เข้ารหัสซึ่งไม่ได้ถูกลบทั้งหมดในพื้นที่เก็บข้อมูลถาวรในไดเรกทอรีที่แตกต่างกันได้รับการเข้ารหัสโดยใช้ชุดค่าผสมที่แตกต่างกันของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV)

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

• คีย์ที่ปกป้องพื้นที่เก็บข้อมูล CE และ DE รวมถึงข้อมูลเมตาของระบบไฟล์

  • [C-1-7] ต้องผูกกับการเข้ารหัสกับที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและฮาร์ดแวร์รูทของความน่าเชื่อถือของอุปกรณ์
  • [C-1-8] คีย์ CE ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้
  • [C-1-9] ต้องเชื่อมโยงคีย์ CE กับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบของหน้าจอล็อก
  • [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ คีย์ CE หรือ DE ของผู้ใช้รายใดรายหนึ่ง ต้องไม่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
  • [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และ โหมดที่รองรับตามข้อกำหนด
  • [C-1-12] ต้องลบอย่างปลอดภัยในระหว่างการปลดล็อกและล็อก Bootloader ตามที่อธิบายไว้ที่นี่

• ควรทำให้แอปที่จำเป็นซึ่งติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ Messenger) รับรู้การบูตโดยตรง

โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานที่ต้องการของ การเข้ารหัสตามไฟล์ซึ่งอิงตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนล Linux และการเข้ารหัสข้อมูลเมตาซึ่งอิงตามฟีเจอร์ "dm-default-key" ของเคอร์เนล Linux

9.9.3.2. การเข้ารหัสระดับบล็อกต่อผู้ใช้

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

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

• [C-1-4] ต้องใช้ AES-256-XTS สำหรับการเข้ารหัสระดับบล็อกของพาร์ติชันผู้ใช้

• คีย์ที่ปกป้องอุปกรณ์ที่เข้ารหัสระดับบล็อกต่อผู้ใช้

  • [C-1-5] ต้องผูกกับการเข้ารหัสกับที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและฮาร์ดแวร์รูทของความน่าเชื่อถือของอุปกรณ์
  • [C-1-6] ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง

การเข้ารหัสระดับบล็อกต่อผู้ใช้สามารถใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของเคอร์เนล Linux ในพาร์ติชันต่อผู้ใช้

9.9.4. เล่นต่อเมื่อรีบูต

การดำเนินการต่อเมื่อรีบูตช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดได้ ซึ่งรวมถึงแอปที่ยังไม่รองรับการบูตโดยตรง หลังจากรีบูตที่เริ่มต้นโดย OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้หลังจากรีบูต

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

ดังนี้

• [C-0-1] ที่เก็บข้อมูล CE ต้องอ่านไม่ได้แม้แต่ผู้โจมตีที่มีอุปกรณ์อยู่กับตัว และมีความสามารถและข้อจำกัดต่อไปนี้

  • ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามข้อความที่กำหนดเอง
  • อาจทำให้อุปกรณ์ได้รับการอัปเดต OTA
  • สามารถแก้ไขการทำงานของฮาร์ดแวร์ (AP, แฟลช ฯลฯ) ได้ ยกเว้นตามที่ ระบุไว้ด้านล่าง แต่การแก้ไขดังกล่าวจะทำให้เกิดความล่าช้าอย่างน้อย 1 ชั่วโมงและต้องปิดเปิดเครื่องใหม่ ซึ่งจะลบเนื้อหาใน RAM
  • แก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการดัดแปลง (เช่น Titan M) ไม่ได้
  • อ่าน RAM ของอุปกรณ์ที่ใช้งานจริงไม่ได้
  • ไม่สามารถขอข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือ ทำให้มีการป้อนข้อมูลดังกล่าว

ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่ติดตั้งใช้งานและเป็นไปตามคำอธิบายทั้งหมดที่พบที่นี่ จะเป็นไปตาม [C-0-1]

9.10. ความสมบูรณ์ของอุปกรณ์

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

• [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะของ Bootloader อนุญาตให้แฟลชอิมเมจระบบหรือไม่

• [C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

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

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

• [C-1-1] ต้องประกาศฟีเจอร์ Flag ของแพลตฟอร์ม android.software.verified_boot
• [C-1-2] ต้องทำการยืนยันในทุกๆ ลำดับการบูต
• [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือ และดำเนินการไปจนถึงพาร์ติชันระบบ
• [C-1-4] ต้องใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความสมบูรณ์ และความถูกต้องของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดใน ขั้นตอนถัดไป
• [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่แข็งแกร่งเท่ากับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
• [C-1-6] ต้องไม่อนุญาตให้บูตจนเสร็จเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้จะยินยอมให้ลองบูตต่อไป ในกรณีนี้ต้องไม่ใช้ข้อมูลจาก บล็อกพื้นที่เก็บข้อมูลที่ไม่ได้ยืนยัน
• [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ยืนยันแล้วในอุปกรณ์ เว้นแต่ผู้ใช้จะปลดล็อก Bootloader อย่างชัดเจน
• [C-1-8] ต้องใช้ที่เก็บข้อมูลที่ป้องกันการดัดแปลง: สำหรับจัดเก็บว่า Bootloader ถูกปลดล็อกหรือไม่ พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงหมายความว่า Bootloader สามารถตรวจหาได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
• [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ล็อกเป็นโหมด Bootloader ปลดล็อก
• [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันการบูตและระบบ) และใช้พื้นที่เก็บข้อมูลที่ตรวจพบการดัดแปลงได้เพื่อจัดเก็บ ข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชัน OS ขั้นต่ำที่อนุญาต

• [C-1-11] ต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยในระหว่างการปลดล็อกและ ล็อก Bootloader ตามที่ระบุไว้ใน "9.12 การลบข้อมูล" (รวมถึงพาร์ติชัน userdata และ พื้นที่ NVRAM)

• [C-1-14] ต้องยืนยันลายเซ็นอย่างน้อย 1 ครั้งต่อการบูตสำหรับแพ็กเกจที่อยู่ในรายการที่อนุญาต ซึ่งระบุเป็น require-strict-signature ในการกำหนดค่าระบบ

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

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

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

โครงการโอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานที่แนะนำสำหรับฟีเจอร์นี้ในที่เก็บ external/avb/ ซึ่งสามารถผสานรวมเข้ากับ Bootloader ที่ใช้ในการโหลด Android ได้

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

• [C-2-1] รองรับการยืนยันเนื้อหาของไฟล์ด้วยการเข้ารหัสโดยไม่ต้องอ่าน ทั้งไฟล์

• [C-2-2] ต้องไม่อนุญาตให้คำขออ่านในไฟล์ที่ได้รับการปกป้องสำเร็จเมื่อเนื้อหาที่อ่านไม่ได้รับการยืนยันตาม [C-2-1] ด้านบน

• [C-2-4] ต้องแสดงผลผลรวมตรวจสอบของไฟล์ใน O(1) สำหรับไฟล์ที่เปิดใช้

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

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-3] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์เฉพาะเมื่อสำเร็จเท่านั้น ต้องจัดเก็บข้อมูลเข้าสู่ระบบของหน้าจอล็อก ในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกจากกันเท่านั้นที่ทำการตรวจสอบสิทธิ์ หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android ต้นทางมี ระดับชั้นการจัดการฮาร์ดแวร์โดยตรง (HAL) ของ Gatekeeper และ Trusty ซึ่งใช้เพื่อตอบสนองข้อกำหนดนี้ได้

• [C-1-4] ต้องรองรับเอกสารรับรองคีย์ที่คีย์การลงนามเอกสารรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัย และการลงนามดำเนินการในฮาร์ดแวร์ที่ปลอดภัย ต้องป้องกันไม่ให้ใช้คีย์การลงนามการรับรองเป็นตัวระบุอุปกรณ์ถาวร

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

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

• [C-1-6] ต้องรองรับ IKeymasterDevice 3.0 ขึ้นไป หรือ IKeyMintDevice เวอร์ชัน 1 ขึ้นไป

9.11.1. การล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือนจริง

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

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

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ตั้งค่าเพียงอย่างใดอย่างหนึ่งต่อไปนี้เป็น วิธีการตรวจสอบสิทธิ์หลัก

  • PIN ที่เป็นตัวเลข
  • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
  • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 พอดี

  โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

• [C-0-1] ต้องจำกัดจำนวนครั้งที่พยายามทำการตรวจสอบสิทธิ์หลักไม่สำเร็จ

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

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

• [C-SR-6] ขอแนะนำอย่างยิ่งให้ PIN มีตัวเลขอย่างน้อย 6 หลัก หรือ เทียบเท่ากับ Entropy 20 บิต

• [C-SR-7] ขอแนะนำอย่างยิ่งว่าไม่ควรอนุญาตให้ป้อน PIN ที่มีความยาวน้อยกว่า 6 หลักโดยอัตโนมัติโดยไม่ต้องมีการโต้ตอบจากผู้ใช้เพื่อหลีกเลี่ยงการเปิดเผยความยาวของ PIN

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

• [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน การกำหนดให้มีการตรวจสอบสิทธิ์ผู้ใช้สำหรับการใช้คีย์

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

• [C-3-1] Entropy ของความยาวอินพุตที่สั้นที่สุดที่อนุญาตต้องมากกว่า 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) ได้ตั้งค่านโยบายฟีเจอร์ Keyguard โดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() พร้อมด้วยค่าสถานะไบโอเมตริกที่เชื่อมโยง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับคลาส 3 (เดิมคือเข้มงวด) ตามที่อธิบายไว้ในส่วนที่ 7.3.10

• [C-5-1] ต้องปิดใช้เมธอดหากแอปพลิเคชัน เครื่องมือควบคุมนโยบายด้านอุปกรณ์ (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] ต้องปิดใช้เมธอดใหม่และอนุญาตให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพียง 1 วิธีเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (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 Television หรือ อุปกรณ์ยานยนต์)

• [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] ต้องไม่อนุญาตให้ TrustAgent ในอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) ปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อ ทำให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกได้นานสูงสุด ไม่เกิน 4 ชั่วโมง การใช้งาน TrustManagerService เริ่มต้นใน AOSP เป็นไปตามข้อกำหนดนี้

• [C-7-12] ต้องใช้ช่องทางการสื่อสารที่ปลอดภัยด้วยการเข้ารหัส (เช่น UKEY2) เพื่อส่งโทเค็นการฝากจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย

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

• [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] นำข้อกำหนดออกใน Android 16

• [C-10-3] นำข้อกำหนดออกใน Android 16

• [C-10-4] ต้องล็อกจอแสดงผลทั้งหมดเมื่อผู้ใช้เริ่มล็อกดาวน์ รวมถึงผ่านความสามารถในการใช้งานของผู้ใช้ที่ล็อกดาวน์ซึ่งจำเป็นสำหรับอุปกรณ์ถือ (ดูส่วนที่ 2.2.5[9.11/H-1-2])

• [C-10-5] ต้องมีอินสแตนซ์อุปกรณ์เสมือนจริงแยกกันต่อผู้ใช้ 1 ราย

• [C-10-6] ต้องปิดใช้การสตรีมแอปตามที่ระบุโดย DevicePolicyManager.setNearbyAppStreamingPolicy

• [C-10-7] นำข้อกำหนดออกใน Android 16

• [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึง การป้อนปัจจัยด้านความรู้และข้อความแจ้งไบโอเมตริก

• [C-10-12] นำข้อกำหนดออกใน Android 16

• [C-10-13] ต้องไม่ใช้สถานะการล็อกอุปกรณ์เสมือนจริงเป็นการตรวจสอบสิทธิ์ผู้ใช้ การให้สิทธิ์ด้วยระบบ Android Keystore ดูKeyGenParameterSpec.Builder.setUserAuthentication*

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

• [C-10-15] ต้องแสดงการแจ้งเตือนเมื่อมีการเข้าถึงข้อมูลในคลิปบอร์ด ทั้งในอุปกรณ์ที่ใช้เข้าถึงและในอุปกรณ์ที่ คลิปบอร์ดนั้นมาจาก

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

• [C-11-1] ต้องเข้ารหัสปัจจัยความรู้โดยมีการรับประกันการป้องกันคล้ายกับที่อธิบายไว้ในสมุดปกขาวเกี่ยวกับความปลอดภัยของบริการที่เก็บคีย์ของ Google Cloudเมื่อโอนปัจจัยความรู้จากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เพื่อให้ไม่สามารถถอดรหัสปัจจัยความรู้จากระยะไกลหรือใช้เพื่อปลดล็อกอุปกรณ์ใดอุปกรณ์หนึ่งจากระยะไกลได้

• [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-5] การติดตั้งใช้งานที่อาศัยการวัดระยะที่ปลอดภัยและแม่นยำเพื่อให้เป็นไปตามข้อกำหนดของ [C-12-4] ต้องใช้โซลูชันใดโซลูชันหนึ่งต่อไปนี้

  • การใช้งานที่ใช้ UWB

    • ต้องเป็นไปตามข้อกำหนดด้านความสอดคล้อง การรับรอง ความแม่นยำ และการปรับเทียบ สำหรับ UWB ที่อธิบายไว้ใน 7.4.9

    • ต้องใช้โหมดความปลอดภัย P-STS อย่างใดอย่างหนึ่งที่ระบุไว้ใน 7.4.9

  • การติดตั้งใช้งานที่ใช้ Neighbor Awareness Networking (NAN) ของ Wi-Fi

    • ต้องเป็นไปตามข้อกำหนดด้านความแม่นยำใน 2.2.1 [7.4.2.5/H-SR-1] ใช้แบนด์วิดท์ 160 MHz (หรือสูงกว่า) และทำตามขั้นตอนการตั้งค่าการวัด ที่ระบุไว้ในการปรับเทียบการตรวจหาการเข้าพัก

    • ต้องใช้ LTF ที่ปลอดภัยตามที่กำหนดไว้ใน IEEE 802.11az

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

• [C-13-8] ต้องบล็อกกิจกรรมที่มีแอตทริบิวต์ android:canDisplayOnRemoteDevices หรือข้อมูลเมตาandroid.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น false ไม่ให้เริ่มในอุปกรณ์เสมือนจริง

• [C-13-9] ต้องบล็อกกิจกรรม ที่ไม่ได้เปิดใช้การสตรีมอย่างชัดเจนและระบุว่าแสดง เนื้อหาที่ละเอียดอ่อน รวมถึงผ่าน SurfaceView#setSecure และ FLAG_SECURE ไม่ให้เริ่มในอุปกรณ์เสมือนจริง

หากการใช้งานอุปกรณ์รองรับสถานะเปิด/ปิดหน้าจอแยกต่างหากผ่าน DeviceStateManager และรองรับสถานะล็อกหน้าจอแยกต่างหากผ่าน KeyguardDisplayManager อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้ข้อมูลเข้าสู่ระบบที่ตรงตามข้อกำหนดที่ระบุไว้ในส่วน 9.11.1 หรือไบโอเมตริกที่ตรงตามข้อกำหนดอย่างน้อย Class 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-10] ต้องมีฮาร์ดแวร์ที่ได้รับการรับรองตาม โปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือ BSI-CC-PP-0117-2022 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวม การประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตาม การใช้เกณฑ์ร่วมกันของศักยภาพในการโจมตีกับสมาร์ทการ์ด

• [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] ต้องแสดงผลที่ไม่ใช่ค่าว่างสำหรับเมธอด IdentityCredentialStore#getInstance()

• [C-1-2] ต้องใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว (เช่น android.security.identity.* API) กับโค้ดที่สื่อสารกับแอปพลิเคชันที่เชื่อถือได้ ในพื้นที่ที่แยกจากโค้ดที่ทำงานบน เคอร์เนลและเหนือกว่าอย่างปลอดภัย การแยกอย่างปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมด ซึ่งโค้ดเคอร์เนลหรือโค้ดในพื้นที่ผู้ใช้อาจใช้เพื่อเข้าถึงสถานะภายในของ สภาพแวดล้อมที่แยก รวมถึง DMA

• [C-1-3] การดำเนินการเข้ารหัสที่จำเป็นต่อการใช้งานระบบข้อมูลประจำตัว (เช่น android.security.identity.* API) ต้องดำเนินการทั้งหมดในแอปพลิเคชันที่เชื่อถือได้ และเนื้อหาคีย์ส่วนตัวต้องไม่ ออกจากสภาพแวดล้อมการดำเนินการที่แยกจากกัน เว้นแต่จะจำเป็นอย่างยิ่ง ตาม API ระดับสูงกว่า (เช่น วิธีการ createEphemeralKeyPair())

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

โครงการโอเพนซอร์ส Android ต้นทางมีข้อมูลอ้างอิง การใช้งานแอปพลิเคชันที่เชื่อถือได้ (libeic) ซึ่งสามารถใช้เพื่อติดตั้งใช้งานระบบข้อมูลประจำตัวได้

9.12. การลบข้อมูล

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

• [C-0-1] ต้องจัดหากลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
• [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ userdata เมื่อทำการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
• [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88 เมื่อดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
• [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของDevicePolicyManager.wipeData() ผู้ใช้หลักเรียกใช้ API
• อาจมีตัวเลือกการล้างข้อมูลอย่างรวดเร็วที่ดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการเปิดเครื่องที่ปลอดภัย

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

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

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้โหมดการเปิดเครื่องที่ปลอดภัย

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

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

• [C-1-2] ต้องให้ความสามารถแก่ผู้ใช้ในการ ถอนการติดตั้งแอปของบุคคลที่สามในโหมดปลอดภัย

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

9.14. การแยกระบบยานยนต์

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ยานพาหนะ เพื่อส่งและรับข้อความผ่านเครือข่ายยานพาหนะ เช่น CAN Bus

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

9.15. แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ในการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

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

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

9.16. การย้ายข้อมูลแอปพลิเคชัน

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

• [C-1-1] ต้องไม่เริ่มการโอนข้อมูลแอปพลิเคชันจาก อุปกรณ์ที่ผู้ใช้ไม่ได้ตั้งค่าการตรวจสอบสิทธิ์หลักตามที่อธิบายไว้ใน 9.11.1 หน้าจอล็อกที่ปลอดภัยและการตรวจสอบสิทธิ์
• [C-1-2] ต้องยืนยันการตรวจสอบสิทธิ์หลักในอุปกรณ์ต้นทางอย่างปลอดภัย และยืนยันความตั้งใจของผู้ใช้ที่จะคัดลอกข้อมูลในอุปกรณ์ต้นทางก่อนที่จะโอนข้อมูล
• [C-1-3] ต้องใช้เอกสารรับรองคีย์ความปลอดภัยเพื่อให้แน่ใจว่าทั้งอุปกรณ์ต้นทางและอุปกรณ์เป้าหมายในการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งเป็นอุปกรณ์ Android ที่ถูกต้องและมี Bootloader ที่ล็อกอยู่
• [C-1-4] ต้องย้ายข้อมูลแอปพลิเคชันไปยังแอปพลิเคชันเดียวกันใน อุปกรณ์เป้าหมายเท่านั้น โดยมีชื่อแพ็กเกจและใบรับรองการลงนามเดียวกัน

• [C-1-5] ต้องแสดงข้อบ่งชี้ว่าอุปกรณ์ต้นทางมีการย้ายข้อมูล โดยการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งในเมนูการตั้งค่า ผู้ใช้ ไม่ควรนำข้อบ่งชี้นี้ออกได้

9.17. เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android

API ของ เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android (AVF) (android.system.virtualmachine.*) ช่วยให้แอปพลิเคชันสร้างเครื่องเสมือน (VM) ที่ป้องกัน (pVM) และไม่ป้องกัน (non-pVM) ในอุปกรณ์ได้ ซึ่งจะโหลดและเรียกใช้ไบนารีแบบเนทีฟเป็นเพย์โหลด

หากการติดตั้งใช้งานอุปกรณ์ตั้งค่า FEATURE_VIRTUALIZATION_FRAMEWORK เป็น true อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องตรวจสอบว่า android.system.virtualmachine.VirtualMachineManager.getCapabilities() แสดงผลอย่างใดอย่างหนึ่งต่อไปนี้

  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. การยืนยันนักพัฒนาซอฟต์แวร์

การใช้งานอุปกรณ์ที่ประกาศ API ระดับ 36.1 ขึ้นไป

• อาจรวมถึงการรองรับบริการตรวจสอบนักพัฒนาแอปเพื่อรับรองว่า แอปพลิเคชันมาจากนักพัฒนาแอปที่รู้จัก

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

• [9.18/C-1-1] ต้องเรียกใช้ android.content.pm.verify.developer.DeveloperVerifierService ที่กำหนดค่าไว้สำหรับ การติดตั้งแพ็กเกจแอปพลิเคชันทุกครั้ง ซึ่งรวมถึงการติดตั้งใหม่และการอัปเดตแอปพลิเคชันที่มีอยู่

การใช้งานอุปกรณ์ที่ประกาศ API ระดับ 36.1 ขึ้นไป

• นอกจากนี้ MAY ยังกำหนดค่าผู้รับมอบสิทธิ์สำหรับการตั้งค่านโยบายที่ใช้งานอยู่ได้โดยการกำหนด config_developerVerificationPolicyDelegatePackageName ใน config.xml

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

• [9.18/C-2-1] ต้องอนุญาตให้เฉพาะเครื่องมือยืนยันตัวตนของนักพัฒนาแอปหรือผู้รับมอบสิทธิ์ที่กำหนดค่าไว้ ตั้งค่านโยบายการติดตั้งตามที่กำหนดไว้ใน android.content.pm.PackageInstaller

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

• [9.18/C-3-1] ต้องป้องกันการติดตั้งแพ็กเกจแอปพลิเคชันในกรณีต่อไปนี้

  • การติดตั้งไม่ผ่านการยืนยันตัวตนของนักพัฒนาแอป

  • นโยบายการยืนยันนักพัฒนาแอปสำหรับเซสชันการติดตั้งจะตั้งค่า เป็นค่าอื่นที่ไม่ใช่ DEVELOPER_VERIFICATION_POLICY_NONE

  • เว้นแต่จะเข้าข่ายข้อ 9.18/C-3-2 หรือ 9.18/C-3-3

• [9.18/C-3-3] ต้องไม่ป้องกันการติดตั้งแพ็กเกจแอปพลิเคชัน เมื่อเป็นไปตามเงื่อนไขต่อไปนี้ทั้งหมด

  • ตั้งค่านโยบายเป็น DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN หรือ DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN

  • ระบบจะรายงานว่าการยืนยันไม่สมบูรณ์

  • โปรแกรมติดตั้งระบุว่าผู้ใช้ขอให้ดำเนินการติดตั้งต่ออย่างชัดเจนโดยการรายงาน DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

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

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

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

• [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) ที่พร้อมใช้งานจากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์ที่จัดส่งขั้นสุดท้ายในอุปกรณ์

• [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความคลุมเครือใน CTS และสำหรับการ นำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงไปใช้ซ้ำ

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

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

• [C-0-3] ต้องผ่าน CTS เวอร์ชันล่าสุดที่พร้อมใช้งานในขณะที่ซอฟต์แวร์ของอุปกรณ์ เสร็จสมบูรณ์

• ควรใช้การติดตั้งใช้งานอ้างอิงในโครงสร้าง Android Open Source ให้มากที่สุด

10.2. โปรแกรมตรวจสอบ CTS

CTS Verifier รวมอยู่ในชุดเครื่องมือทดสอบความเข้ากันได้ และมีไว้ให้ผู้ปฏิบัติงานที่เป็นมนุษย์เรียกใช้เพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติไม่สามารถทดสอบได้ เช่น การทำงานที่ถูกต้องของกล้องและเซ็นเซอร์

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

• [C-0-1] ต้องเรียกใช้กรณีที่เกี่ยวข้องทั้งหมดใน CTS Verifier อย่างถูกต้อง

CTS Verifier มีการทดสอบสำหรับฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่าง ที่ไม่บังคับ

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

• [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง อุปกรณ์ต้องเรียกใช้ กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง

อาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับโดยเอกสารคำจำกัดความความเข้ากันได้นี้

• [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 หรือ Bluetooth PAN (เครือข่ายส่วนบุคคล) อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรองรับการดาวน์โหลด OTA พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต

การติดตั้งใช้งานอุปกรณ์ควรตรวจสอบว่าอิมเมจระบบเป็นไบนารีที่เหมือนกัน กับผลลัพธ์ที่คาดไว้หลังจากการ OTA การติดตั้งใช้งาน OTA แบบบล็อก ในโครงการโอเพนซอร์ส Android ต้นทาง ซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้

นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ควรจะรองรับการอัปเดตระบบ A/B AOSP จะใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการบูต

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

• [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ ที่พร้อมใช้งานซึ่งสามารถใช้ได้ตามกลไกที่อธิบายไว้ข้างต้น

Android มีฟีเจอร์ที่ช่วยให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบได้ หากระบบย่อยการอัปเดตระบบ สำหรับอุปกรณ์รายงาน android.software.device_admin แสดงว่าอุปกรณ์มีลักษณะดังนี้

• [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

ตั้งแต่ Android 16 เป็นต้นไป จะไม่มีบันทึกการเปลี่ยนแปลงที่แยกต่างหาก การเปลี่ยนแปลงทั้งหมดจากเวอร์ชันก่อนหน้าจะไฮไลต์ไว้ในเอกสารนี้

13. ติดต่อเรา

คุณเข้าร่วมฟอรัมความเข้ากันได้ของ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ได้ กล่าวถึงได้