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

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

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

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

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

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

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

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

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

1.1 โครงสร้างเอกสาร

1.1.1 ข้อกำหนดตามประเภทอุปกรณ์

ส่วนที่ 2 ประกอบด้วยข้อกำหนดทั้งหมดที่มีผลกับ ประเภทอุปกรณ์ที่เฉพาะเจาะจง ส่วนย่อยแต่ละส่วนของส่วนที่ 2 คือ ที่มีไว้สำหรับประเภทอุปกรณ์ที่เฉพาะเจาะจง

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

1.1.2 รหัสข้อกำหนด

มีการกำหนดรหัสข้อกำหนดสำหรับข้อกำหนด "ต้อง" แล้ว

  • รหัสได้รับการกำหนดสำหรับข้อกำหนด "ต้อง" เท่านั้น
  • ข้อกำหนดที่แนะนำอย่างยิ่งจะมีเครื่องหมายเป็น [SR] แต่ยังไม่มีการกำหนดบัตรประจำตัว
  • รหัสประกอบด้วย : รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น C-0-1)

แต่ละรหัสจะมีคำจำกัดความดังนี้

  • รหัสประเภทอุปกรณ์ (ดูข้อมูลเพิ่มเติมใน 2. ประเภทอุปกรณ์)
    • C: หลัก (ข้อกำหนดที่ใช้กับการใช้งานอุปกรณ์ Android ทั้งหมด)
    • H: อุปกรณ์ Android แบบพกพา
    • T: อุปกรณ์ Android TV
    • ตอบ: การติดตั้งใช้งาน Android Automotive
    • W: การใช้งาน Android Watch
    • แท็บ: การใช้งานแท็บเล็ต Android
  • รหัสเงื่อนไข
    • เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะกำหนดรหัสนี้เป็น 0
    • เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนด 1 ให้กับรายการที่ 1 และตัวเลขจะเพิ่มขึ้นทีละ 1 ในส่วนเดียวกันและ อุปกรณ์ประเภทเดียวกัน
  • รหัสข้อกำหนด
    • รหัสนี้เริ่มจาก 1 และเพิ่มขึ้นครั้งละ 1 ภายในส่วนเดียวกันและ เงื่อนไขเดียวกัน

1.1.3 รหัสข้อกำหนดในส่วนที่ 2

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

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

  • รหัสในส่วนที่ 2 ประกอบด้วย รหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)

2. ประเภทอุปกรณ์

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

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

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

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

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

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

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

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

  • มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
  • กำหนดหน้าจอขนาดตามจริงในช่วง 3.3 นิ้ว (หรือ 2.5 นิ้ว นิ้วสำหรับการใช้งานอุปกรณ์ซึ่งจัดส่งใน API ระดับ 29 หรือก่อนหน้า) ถึง 8 นิ้ว

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

หมายเหตุ: ข้อกำหนดที่ไม่มีผลกับอุปกรณ์แท็บเล็ต Android จะมีเครื่องหมาย *

2.2.1. ฮาร์ดแวร์

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

  • [7.1.1.1/H-0-1] ต้องมีอย่างน้อย 1 รายการ จอแสดงผลที่เข้ากันได้กับ Android ซึ่งเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในบทความนี้ เอกสาร
  • [7.1.1.3/H-SR-1] ขอแนะนําอย่างยิ่งให้ ช่วยให้ผู้ใช้สามารถปรับขนาดการแสดงผล (ความหนาแน่นของหน้าจอ) ได้

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

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

  • [7.1.1.1/H-1-1]* ต้องทำให้หน้าจอแสดงตรรกะ ที่พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามจะต้องมีขนาดอย่างน้อย 2 นิ้วบน ด้านขอบสั้นและ 2.7 นิ้วสำหรับขอบยาว อุปกรณ์ที่จัดส่ง Android API ระดับ 29 หรือเก่ากว่าอาจได้รับการยกเว้น ข้อกำหนดนี้

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

  • [7.1.1.1/H-2-1]* ต้องทำให้หน้าจอแสดงตรรกะ สำหรับแอปพลิเคชันของบุคคลที่สามจะมีขนาดอย่างน้อย 2.7 นิ้ว ขอบสั้น อุปกรณ์ที่จัดส่ง Android API ระดับ 29 หรือเก่ากว่าอาจได้รับการยกเว้น ข้อกำหนดนี้

หากการใช้อุปกรณ์พกพาอ้างว่าสนับสนุนช่วงไดนามิกกว้าง แสดงผ่านทาง Configuration.isScreenHdr() นั้น

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

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

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

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

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

  • [7.1.5/H-0-1] ต้องรวมการสนับสนุนสำหรับรุ่นเดิม โหมดความเข้ากันได้ของแอปพลิเคชันที่ใช้งานโดยอัปสตรีม Android ที่เปิดอยู่ ซอร์สโค้ด กล่าวคือ การใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์ หรือ ที่จะเปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนแปลง ของโหมดความเข้ากันได้
  • [7.2.1/H-0-1] ต้องมีการสนับสนุนสำหรับบุคคลที่สาม แอปพลิเคชัน Input Method Editor (IME)
  • [7.2.3/H-0-3] ต้องเปิดฟังก์ชัน "อยู่บ้าน" ทุกหน้าจอที่รองรับ Android ซึ่งมีหน้าจอหลัก
  • [7.2.3/H-0-4] ต้องระบุฟังก์ชัน "กลับ" ทั้งหมด จอแสดงผลที่รองรับ Android และฟังก์ชัน "ล่าสุด" บน จอแสดงผลที่รองรับ Android
  • [7.2.3/H-0-2] ต้องส่งทั้งการกดปกติและกดค้าง เหตุการณ์ของฟังก์ชันย้อนกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันเบื้องหน้า เหตุการณ์เหล่านี้ต้องไม่ใช้โดยระบบ และอยู่นอกอุปกรณ์ Android (เช่น ฮาร์ดแวร์ภายนอก) แป้นพิมพ์ที่เชื่อมต่อกับอุปกรณ์ Android)
  • [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
  • [7.2.4/H-SR-1] ขอแนะนำอย่างยิ่งให้เปิดตัว แอปช่วยเหลือที่ผู้ใช้เลือก ซึ่งก็คือแอปที่ใช้งาน VoiceInteractionService หรือกิจกรรมที่จัดการACTION_ASSIST เมื่อกด KEYCODE_MEDIA_PLAY_PAUSE ค้างไว้ หรือ KEYCODE_HEADSETHOOK หากกิจกรรมเบื้องหน้าไม่สามารถจัดการกิจกรรมการกดค้างเหล่านั้นได้
  • [7.3.1/H-SR-1] แนะนําอย่างยิ่งให้รวมแกน 3 แกน ตัวตรวจวัดความเร่ง

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

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

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

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

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

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

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

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

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

  • [7.3.11/H-SR-1] แนะนำให้รองรับเซ็นเซอร์ท่าทางที่มี 6 หลายระดับ
  • [7.4.3/H] ควรรวมการสนับสนุนบลูทูธและ บลูทูธ LE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดโฮสต์ ดังนี้

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

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

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

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

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

  • [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์ต่อไปนี้ ของโค้ด HID:
การทำงาน การแมป บริบท ลักษณะการทำงาน
หน้าการใช้งาน HID: 0x0C
การใช้งาน HID: 0x0CD
คีย์เคอร์เนล: KEY_PLAYPAUSE
คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE
การเล่นสื่อ อินพุต: กดสั้น
เอาต์พุต: เล่นหรือหยุดชั่วคราว
อินพุต: กดค้าง
เอาต์พุต: เปิดคำสั่งเสียง
ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ มีการล็อกหรือปิดหน้าจอ จำนวนครั้งที่ส่ง จ่าย android.speech.RecognizerIntent.ACTION_WEB_SEARCH
สายเรียกเข้า อินพุต: กดสั้น
เอาต์พุต: รับสาย
อินพุต: กดค้าง
เอาต์พุต: ปฏิเสธสาย
สายที่สนทนาอยู่ อินพุต: กดสั้น
เอาต์พุต: วางสาย
อินพุต: กดค้าง
เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน
B หน้าการใช้งาน HID: 0x0C
การใช้งาน HID: 0x0E9
คีย์เคอร์เนล: KEY_VOLUMEUP
คีย์ Android: VOLUME_UP
การเล่นสื่อ การโทรที่ดำเนินอยู่ อินพุต: กดสั้นหรือค้าง
เอาต์พุต: เพิ่มระดับเสียงของระบบหรือชุดหูฟัง
C หน้าการใช้งาน HID: 0x0C
การใช้งาน HID: 0x0EA
คีย์เคอร์เนล: KEY_VOLUMEDOWN
คีย์ Android: VOLUME_DOWN
การเล่นสื่อ การโทรที่ดำเนินอยู่ อินพุต: กดสั้นหรือค้าง
เอาต์พุต: ลดระดับเสียงของระบบหรือชุดหูฟัง
D หน้าการใช้งาน HID: 0x0C
การใช้งาน HID: 0x0CF
คีย์เคอร์เนล: KEY_VOICECOMMAND
คีย์ Android: KEYCODE_VOICE_ASSIST
ทั้งหมด ทริกเกอร์ได้ในทุกอินสแตนซ์ อินพุต: กดสั้นหรือค้าง
เอาต์พุต: เปิดคำสั่งเสียง
  • [7.8.2.2/H-1-2] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อมีการเสียบปลั๊ก แต่เฉพาะเมื่อต่ออินเทอร์เฟซเสียงและปลายทาง USB แล้ว ได้รับการระบุอย่างเหมาะสมเพื่อระบุประเภทของขั้วต่อที่เชื่อมต่อ

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

  • [7.8.2.2/H-2-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ตั้งค่าพิเศษเป็น 0

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

  • [7.8.2.2/H-3-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ตั้งค่าเพิ่มเติมเป็น 1

เมื่อมีการเรียกใช้ API AudioManager.getdevices() ในขณะที่อุปกรณ์ต่อพ่วง USB อยู่ เชื่อมต่อไว้:

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

  • [7.8.2.2/H-4-2] ต้องระบุประเภทอุปกรณ์ AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากขั้วปลายสายไฟเสียง USB ฟิลด์ประเภทคือ 0x0402

  • [7.8.2.2/H-4-3] ต้องระบุประเภทอุปกรณ์ AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSource() หากขั้วปลายสายไฟ USB ฟิลด์ประเภทคือ 0x0402

  • [7.8.2.2/H-4-4] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทเทอร์มินัลเสียง USB เป็น 0x603

  • [7.8.2.2/H-4-5] ต้องระบุประเภทอุปกรณ์ AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากขั้วปลายสายไฟ USB ฟิลด์ประเภท คือ 0x604

  • [7.8.2.2/H-4-6] ต้องระบุประเภทอุปกรณ์ AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากประเภทขั้วปลายสายไฟเสียง USB คือ 0x400

  • [7.8.2.2/H-4-7] ต้องระบุประเภทอุปกรณ์ AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากขั้วปลายสายไฟ USB คือ 0x400

  • [7.8.2.2/H-SR-1] ขอแนะนำอย่างยิ่งเมื่อเชื่อมโยงกับ อุปกรณ์ต่อพ่วงเสียง USB-C สำหรับทำการแจงนับข้อบ่งชี้ USB ประเภทเทอร์มินัลและ Intent การออกอากาศ ACTION_HEADSET_PLUG ที่น้อยกว่า 1,000 มิลลิวินาที

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

  • [5.6(#56_audio-latency)/H-1-1] ต้องมีการเดินทางไป-กลับเฉลี่ยต่อเนื่อง เวลาในการตอบสนอง 800 มิลลิวินาทีหรือน้อยกว่า ในการวัด 5 ครั้ง โดยมีค่าเฉลี่ย ค่าเบี่ยงเบนสัมบูรณ์น้อยกว่า 100 มิลลิวินาที หรือมีเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง

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

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

หากการใช้งานอุปกรณ์พกพามีเรโซแนนต์เชิงเส้นอย่างน้อย 1 ตัว ของตน

  • [7.10/H]* ควรย้ายตัวดำเนินการการโต้ตอบแบบรู้สึกได้ในแกน X ของ ในแนวตั้ง

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

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

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

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

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

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

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

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

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

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

2.2.3. ซอฟต์แวร์

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

  • [3.2.3.1/H-0-1] ต้องมี ที่จัดการ ACTION_GET_CONTENT ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, และ ACTION_CREATE_DOCUMENT ตามที่อธิบายไว้ในเอกสาร SDK และช่วยให้ผู้ใช้จ่ายได้ เพื่อเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้ DocumentsProvider API
  • [3.2.3.1/H-0-2]* ต้องโหลดล่วงหน้า 1 รายการ แอปพลิเคชันหรือคอมโพเนนต์บริการมากกว่า ที่มีเครื่องจัดการ Intent รูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยแอปพลิเคชันต่อไปนี้ Intent แสดงอยู่ที่นี่
  • [3.2.3.1/H-SR-1] มีประสิทธิภาพอย่างมาก แนะนำให้โหลดแอปพลิเคชันอีเมลล่วงหน้าที่สามารถจัดการ ACTION_SENDTO ล่วงหน้า หรือ ACTION_SEND หรือ ACTION_SEND_MULTIPLE ต้องการส่งอีเมล
  • [3.4.1/H-0-1] ต้องระบุฟิลด์ การใช้งาน android.webkit.Webview API
  • [3.4.2/H-0-1] ต้องมีเบราว์เซอร์แบบสแตนด์อโลน แอปพลิเคชันสำหรับเรียกดูเว็บของผู้ใช้ทั่วไป
  • [3.8.1/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัดในแอป วิดเจ็ต และ widgetFeatures
  • [3.8.1/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง เพื่อใช้ Launcher เริ่มต้นที่ช่วยให้เข้าถึง แป้นพิมพ์ลัดที่ได้จากแอปของบุคคลที่สามผ่าน แป้นพิมพ์ลัด API
  • [3.8.1/H-SR-3] ขอแนะนำเป็นอย่างยิ่ง เพื่อรวมแอป Launcher เริ่มต้นซึ่งแสดงป้ายสำหรับไอคอนแอป
  • [3.8.2/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อรองรับวิดเจ็ตแอปของบุคคลที่สาม
  • [3.8.3/H-0-1] ต้องอนุญาตบุคคลที่สาม แอปสำหรับแจ้งเตือนผู้ใช้เกี่ยวกับกิจกรรมสำคัญผ่านทาง Notification และ NotificationManager คลาส API
  • [3.8.3/H-0-2] ต้องรองรับเวอร์ชันสมบูรณ์ การแจ้งเตือน
  • [3.8.3/H-0-3] ต้องรองรับการแจ้งเตือน การแจ้งเตือน
  • [3.8.3/H-0-4] ต้องมี หน้าต่างแจ้งเตือน ซึ่งช่วยให้ผู้ใช้สามารถควบคุมได้โดยตรง (เช่น ตอบ, เลื่อนการแจ้งเตือน, ปิด, บล็อก) การแจ้งเตือนผ่านโฆษณาสำหรับผู้ใช้ เช่น ปุ่มดำเนินการหรือแผงควบคุมตามที่ใช้ใน AOSP
  • [3.8.3/H-0-5] ต้องแสดงตัวเลือก ให้บริการผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือน
  • [3.8.3/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อแสดงตัวเลือกแรกที่ให้ไว้ผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้
  • [3.8.3/H-SR-2] ขอแนะนำเป็นอย่างยิ่ง เพื่อแสดงตัวเลือกทั้งหมดที่ให้ไว้ผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดในหน้าต่าง หน้าต่างแจ้งเตือน
  • [3.8.3.1/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อแสดงการทำงานที่ Notification.Action.Builder.setContextual ตั้งค่าเป็น true ในบรรทัดโดยแสดงการตอบโดย Notification.Remoteinput.Builder.setChoices
  • [3.8.4/H-SR-1] ขอแนะนำเป็นอย่างยิ่ง เพื่อใช้ Assistant ในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย

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

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

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

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

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

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

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

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

  • [3.8.16/H-1-1] ต้องประกาศฟีเจอร์ แฟล็ก android.software.controls แล้วตั้งค่าเป็น true
  • [3.8.16/H-1-2] ต้องระบุผู้ใช้ สามารถให้บริการเพิ่ม แก้ไข เลือก และดำเนินการ ระบบควบคุมอุปกรณ์โปรดจากการควบคุมที่ลงทะเบียนโดยบุคคลที่สาม ผ่าน ControlsProviderService และ Control API
  • [3.8.16/H-1-3] ต้องให้สิทธิ์เข้าถึง ผู้ใช้นี้มีสิทธิ์การเข้าถึงภายใน 3 การโต้ตอบจาก Launcher เริ่มต้น
  • [3.8.16/H-1-4] ต้องแสดงผลอย่างถูกต้อง ในการสูญเสียชื่อและไอคอนของแอปบุคคลที่สามแต่ละแอป มอบการควบคุมผ่าน ControlsProviderService API และช่องที่ระบุโดย Control API

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

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

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

หากการใช้งานอุปกรณ์พกพาของ Android ประกาศเป็น FEATURE_BLUETOOTH หรือ FEATURE_WIFI ซึ่งมีคุณสมบัติดังนี้

  • [3.16/H-1-1] ต้องรองรับการจับคู่อุปกรณ์ที่ใช้ร่วมกัน

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้

  • [7.2.3/H] โซนการจดจำท่าทางสัมผัสสำหรับปุ่มหน้าแรก ฟังก์ชันควรสูงไม่เกิน 32 dp จากด้านล่างของ บนหน้าจอ

หากการใช้งานอุปกรณ์พกพามีฟังก์ชันการนำทางเป็นท่าทางสัมผัส จากส่วนใดก็ได้จากขอบด้านซ้ายและขวาของหน้าจอ:

  • [7.2.3/H-0-1] พื้นที่ท่าทางสัมผัสของฟังก์ชันการนำทาง ต้องมีความกว้างน้อยกว่า 40 dp ในแต่ละด้าน พื้นที่ท่าทางสัมผัสควร ความกว้าง 24 dp โดยค่าเริ่มต้น

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

  • [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่มีการจัดการผ่านทาง แฟล็กฟีเจอร์ android.software.managed_users

หากการใช้งานอุปกรณ์พกพาของ Android ประกาศการรองรับกล้องผ่าน android.hardware.camera.any พวกเขา:

2.2.4 ประสิทธิภาพและศักยภาพ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการสามารถส่ง ข้อมูลไปยัง System หรือ ContentCaptureService
  • [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการสามารถส่ง ข้อมูลเสียงของไมค์หรือข้อมูลที่ได้จากข้อมูลดังกล่าวไปยังเซิร์ฟเวอร์ของระบบผ่านทาง HotwordDetectionService API หรือไปยัง ContentCaptureService ผ่าน API ContentCaptureManager
  • [9.8/H-1-3] ต้องไม่ให้เสียงไมค์ที่ยาวกว่า 30 วินาทีสำหรับ คำขอที่ทริกเกอร์โดยฮาร์ดแวร์แต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-4] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับ แต่ละคำขอไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-5] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีไปยัง บริการโต้ตอบด้วยเสียงหรือเอนทิตีที่คล้ายกัน
  • [9.8/H-1-6] ต้องไม่อนุญาตให้ส่งข้อมูลเกิน 100 ไบต์ ของบริการตรวจจับคำสั่งให้ดำเนินการในแต่ละผลลัพธ์ของคำสั่งให้ดำเนินการที่ประสบความสำเร็จ
  • [9.8/H-1-7] ต้องไม่อนุญาตให้ส่งข้อมูลออกเกินกว่า 5 บิต ของบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์ของคำสั่งให้ดำเนินการเชิงลบแต่ละรายการ
  • [9.8/H-1-8] ต้องอนุญาตการส่งข้อมูลออกจากคำสั่งให้ดำเนินการเท่านั้น บริการตรวจจับในคำขอตรวจสอบคำสั่งให้ดำเนินการจากเซิร์ฟเวอร์ระบบ
  • [9.8/H-1-9] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้มอบ บริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-10] ต้องไม่แสดงข้อมูลเชิงปริมาณใน UI เกี่ยวกับการใช้งานไมค์ตาม บริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-11] ต้องบันทึกจำนวนไบต์ที่รวมอยู่ในการส่งข้อมูลทุกครั้ง จากบริการตรวจจับคำสั่งให้ดำเนินการเพื่อให้ตรวจสอบเพื่อความปลอดภัยได้ นักวิจัย
  • [9.8/H-1-12] ต้องรองรับโหมดแก้ไขข้อบกพร่องที่บันทึกเนื้อหาดิบของ การส่งข้อมูลจากบริการตรวจจับคำสั่งให้ดำเนินการเพื่อให้ตรวจสอบได้ และนักวิจัยด้านความปลอดภัย
  • [9.8/H-1-13] ต้องรีสตาร์ทกระบวนการที่โฮสต์บริการตรวจจับคำสั่งให้ดำเนินการ อย่างน้อย 1 ครั้งในทุกชั่วโมง หรือทุก 30 เหตุการณ์ทริกเกอร์ฮาร์ดแวร์ แล้วแต่ว่ากรณีใด มาก่อน
  • [9.8/H-1-14] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนตามที่อธิบายไว้ในส่วน 9.8.2 เมื่อมีการส่งผลลัพธ์ของคำสั่งให้ดำเนินการไปยังเสียงพูด บริการโต้ตอบหรือเอนทิตีที่คล้ายกัน
  • [9.8/H-SR-1] แนะนําอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบก่อนตั้งค่า เป็นผู้ให้บริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ไม่อนุญาตให้ส่ง ที่ไม่มีโครงสร้างออกจากบริการตรวจจับคำสั่งให้ดำเนินการ

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

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

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

  • [9.8.2/H-4-1] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนเมื่อ มีแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่เข้าถึงข้อมูลเสียงจากไมโครโฟน HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทในการเรียกใช้ ส่วนที่ 9.1 ที่มีตัวระบุ CDD [C-4-X]
  • [9.8.2/H-4-2] ต้องแสดงรายการล่าสุดและใช้งานอยู่ แอปที่ใช้ไมโครโฟนตามที่ได้ส่งคืนจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับการระบุแหล่งที่มาทั้งหมด ที่เกี่ยวข้อง
  • [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] ต้องไม่ซ่อนสัญญาณบอกสถานะกล้องสำหรับ แอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบของผู้ใช้โดยตรง

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

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

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

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

  • Perfetto
    • [6.1/H-0-2]* ต้องแสดง /system/bin/perfetto ไบนารีของผู้ใช้เชลล์ที่ cmdline ปฏิบัติตาม เอกสาร 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 ชั้นเรียนประสิทธิภาพของสื่อแบบมือถือ

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

2.2.7.1 สื่อ

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

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

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S ในราคา android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS ให้ดำเนินการดังนี้

  • [5.1/H-1-1] ต้องโฆษณาจำนวนสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์ เซสชันที่สามารถทำงานพร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() เมธอด
  • [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9* ขึ้นไป) ในชุดค่าผสมของตัวแปลงรหัสใดก็ได้ที่ทำงานอยู่ พร้อมกันที่ความละเอียด 720p@30 FPS *ต้องใช้ 2 อินสแตนซ์เท่านั้นหาก มีตัวแปลงรหัส VP9
  • [5.1/H-1-3] ต้องโฆษณาโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ถึงจำนวนสูงสุด เซสชันที่สามารถทำงานพร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() เมธอด
  • [5.1/H-1-4] ต้องรองรับ 6 อินสแตนซ์ของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ เซสชัน (AVC, HEVC, VP9* ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานอยู่ พร้อมกันที่ความละเอียด 720p@30fps *ต้องระบุ 2 อินสแตนซ์เท่านั้น หากมีตัวแปลงรหัส VP9
  • [5.1/H-1-5] ต้องโฆษณาถึงจำนวนสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์และ เซสชันตัวถอดรหัสที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints() เมธอด
  • [5.1/H-1-6] ต้องรองรับตัวถอดรหัสวิดีโอและฮาร์ดแวร์ 6 ชุด เซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอ (AVC, HEVC, VP9* ขึ้นไป) ในตัวแปลงรหัสใดก็ได้ ชุดค่าผสมที่ทำงานพร้อมกันที่ความละเอียด 720p@30fps *ต้องมี 2 อินสแตนซ์เท่านั้นหากมีตัวแปลงรหัส VP9
  • [5.1/H-1-7] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 50 มิลลิวินาทีสำหรับ เซสชันการเข้ารหัสวิดีโอความละเอียด 1080p หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ทั้งหมด (นอกเหนือจากตัวแปลงรหัส Dolby Vision) เมื่ออยู่ระหว่างการโหลด โหลดที่นี่กำหนดไว้เป็น เซสชันการแปลงวิดีโอเท่านั้นแบบ 1080p เป็น 720p พร้อมกันโดยใช้วิดีโอฮาร์ดแวร์ พร้อมกับการเริ่มต้นการบันทึกเสียง 1080p
  • [5.1/H-1-8] ต้องมีเวลาในการตอบสนองของการเริ่มต้นตัวแปลงรหัสไม่เกิน 40 มิลลิวินาทีสำหรับ เซสชันการเข้ารหัสเสียงอัตราบิต 128 kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมด น้อยกว่าโหลด การโหลดที่นี่หมายถึงวิดีโอแบบ 1080p ถึง 720p ที่เกิดขึ้นพร้อมกัน เซสชันการแปลงโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับความละเอียด 1080p การเริ่มต้นการบันทึกเสียง-วิดีโอ
  • [5.3/H-1-1] ต้องไม่วางมากกว่า 2 เฟรมใน 10 วินาที (กล่าวคือ เฟรมตกน้อยกว่า 0.333 เปอร์เซ็นต์) สำหรับเซสชันวิดีโอ 1080p 60 FPS น้อยกว่าโหลด การโหลดหมายถึงการโหลดพร้อมกันในระดับวิดีโอเท่านั้นที่มีความละเอียด 1080p ถึง 720p เซสชันการแปลงโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึง การเล่นเสียง AAC 128 kbps
  • [5.3/H-1-2] ต้องไม่วางมากกว่า 2 เฟรมใน 10 วินาทีระหว่างวิดีโอ การเปลี่ยนแปลงความละเอียดในเซสชันวิดีโอ 60 fps ภายใต้การโหลด โหลดได้รับการกำหนดให้เป็น เซสชันการแปลงวิดีโอเท่านั้นแบบ 1080p เป็น 720p พร้อมกันโดยใช้ฮาร์ดแวร์ ตัวแปลงรหัสวิดีโอ รวมถึงการเล่นเสียง AAC 128 kbps
  • [5.6/H-1-1] ต้องมีเวลาในการตอบสนองของการแตะเพื่อโทนน้อยกว่า 100 มิลลิวินาที โดยใช้การทดสอบการแตะเพื่อโทนเสียงของ OboeTester หรือการทดสอบการแตะเพื่อโทนเสียงของ CTS Verifier

2.2.7.2 กล้อง

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

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

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.S ในราคา android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS ให้ดำเนินการดังนี้

  • [7.5/H-1-1] ต้องมีกล้องหลังตัวหลักที่มีความละเอียด รองรับการจับภาพวิดีโอที่ 4k@30fps อย่างน้อย 12 ล้านพิกเซล องค์ประกอบหลัก กล้องหลังคือกล้องหลังที่มีรหัสกล้องต่ำสุด
  • [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียด ความละเอียดอย่างน้อย 5 เมกะพิกเซล และรองรับการบันทึกวิดีโอที่ 1080p@30 FPS องค์ประกอบหลัก กล้องหน้าคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
  • [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ในฐานะ FULL หรือดีกว่าสำหรับตำแหน่งหลักด้านหลัง และ LIMITED หรือดีกว่าสำหรับตำแหน่งหลักด้านหน้า กล้อง
  • [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME สำหรับทั้ง 2 เขตหลัก กล้อง
  • [7.5/H-1-5] ต้องมีเวลาในการตอบสนองของการบันทึกภาพ Camera2 JPEG < 1000 มิลลิวินาทีสำหรับ ความละเอียด 1080p ตามที่วัดโดย PerformanceTest สำหรับกล้อง CTS ภายใต้ ITS สภาพแสง (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูตัวอย่างแรก เฟรม) < 600 มิลลิวินาทีตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้ ITS สภาพแสง (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-8] ต้องรองรับ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW และ android.graphics.ImageFormat.RAW_SENSOR สำหรับกล้องหลังหลัก

2.2.7.3 ฮาร์ดแวร์

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.R ในราคา android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS ให้ดำเนินการดังนี้

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

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

  • [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
  • [7.1.1.3/H-2-1] ต้องมีความหนาแน่นของหน้าจออย่างน้อย 400 dpi
  • [7.6.1/H-2-1] ต้องมีหน่วยความจำทางกายภาพอย่างน้อย 6 GB

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

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

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

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

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

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

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

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

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

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

2.3.1 ฮาร์ดแวร์

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

  • [7.2.2/T-0-1] ต้องรองรับ D-pad
  • [7.2.3/T-0-1] ต้องให้หน้าแรกและกลับ
  • [7.2.3/T-0-2] ต้องส่งทั้งการกดปกติและค้าง เหตุการณ์ของฟังก์ชันย้อนกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันเบื้องหน้า
  • [7.2.6.1/T-0-1] ต้องมีการรองรับเกม และประกาศแฟล็กฟีเจอร์ android.hardware.gamepad
  • [7.2.7/T] ควรมีรีโมตคอนโทรลสำหรับ ผู้ใช้สามารถเข้าถึงการนำทางที่ไม่ได้สัมผัส และ ข้อมูลคีย์การนำทางหลัก

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

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

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

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

หากอุปกรณ์ทีวีมีพอร์ต USB ที่รองรับโหมดโฮสต์ ดังนี้

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

หากอุปกรณ์ทีวีเป็นแบบ 32 บิต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.2.2/T-SR-1] แนะนําอย่างยิ่งให้สนับสนุน การเข้ารหัส H.264 ที่มีความละเอียด 720p และ 1080p ที่ 30 เฟรมต่อวินาที

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

การใช้งานอุปกรณ์โทรทัศน์ต้องสนับสนุนการถอดรหัส MPEG-2 ตามรายละเอียดใน ส่วนที่ 5.3.1 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานไม่เกิน ซึ่งรวมถึง

  • [5.3.1/T-1-1] HD 1080p ที่ 29.97 เฟรมต่อวินาที ที่มีโปรไฟล์หลักอยู่ในระดับสูง
  • [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาที ที่มีโปรไฟล์หลักอยู่ในระดับสูง ต้องป้องกันการสอดประสานวิดีโอ MPEG-2 แบบอินเตอร์เลซ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้

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

  • [5.3.4/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาที โปรไฟล์พื้นฐาน
  • [5.3.4/T-1-2] HD 1080p ที่ 60 ภาพต่อวินาที โปรไฟล์หลัก
  • [5.3.4/T-1-3] HD 1080p ที่ 60 ภาพต่อวินาที ระดับสูงระดับ 4.2

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

  • [5.3.5/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาที ระดับโปรไฟล์หลัก 4.1

ในกรณีที่ใช้อุปกรณ์ทีวีที่รองรับตัวถอดรหัสฮาร์ดแวร์ H.265 การถอดรหัส H.265 และโปรไฟล์การถอดรหัส UHD มีดังนี้

  • [5.3.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีเมื่อใช้โปรไฟล์หลักของระดับ Main10 ระดับ 5

การใช้งานอุปกรณ์ทีวีต้องรองรับการถอดรหัส VP8 ตามรายละเอียดใน ส่วนที่ 5.3.6 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุด และ ซึ่งรวมถึง

  • [5.3.6/T-1-1] โปรไฟล์การถอดรหัสแบบ HD 1080p ที่ 60 เฟรมต่อวินาที

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

  • [5.3.7/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาที โปรไฟล์ 0 (ความลึกของสี 8 บิต)

การใช้อุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 รองรับ VP9 และการถอดรหัสแบบ UHD จะทำสิ่งต่อไปนี้ได้

  • [5.3.7/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีและมีโปรไฟล์ 0 (ความลึกของสี 8 บิต)
  • [5.3.7/T-2-1] ขอแนะนำอย่างยิ่งให้รองรับ โปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)

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

  • [5.5/T-0-1] ต้องมีการสนับสนุนสำหรับ System Master การลดทอนระดับเสียงและเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตเสียงส่งผ่านที่บีบอัด (เมื่อไม่มีการถอดรหัสเสียง) ในอุปกรณ์)

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

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

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

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

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

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

2.3.3 ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

  • [3.12/T-0-1] ต้องรองรับเฟรมเวิร์กอินพุตทีวี

2.3.4 ประสิทธิภาพและศักยภาพ

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ทีวีประกาศ android.hardware.microphone ค่าจะมีลักษณะดังนี้

  • [9.8.2/T-4-1] ต้องแสดงสัญญาณบอกสถานะไมโครโฟนเมื่อ มีแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่เข้าถึงข้อมูลเสียงจากไมโครโฟน ไมโครโฟนเข้าถึงได้โดย HotwordDetectionService, SOURCE_HOTWORD ContentCaptureService หรือแอปที่มีบทบาทที่ระบุไว้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ 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 ไบนารีของผู้ใช้เชลล์ที่ cmdline ปฏิบัติตาม เอกสาร Perfetto
    • [6.1/T-0-2] ไบนารี Perfetto ต้องยอมรับเป็น ป้อนการกำหนดค่า Protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ใน เอกสาร Perfetto
    • [6.1/T-0-3] ไบนารี Perfetto ต้องเขียนเป็น แสดงผลการติดตาม Protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ใน เอกสาร Perfetto
    • [6.1/T-0-4] ต้องระบุ โดยผ่าน Perfetto อย่างน้อยที่สุดคือแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto

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

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

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

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

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

2.4.1 ฮาร์ดแวร์

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

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

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

  • [7.2.4/W-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.3 ซอฟต์แวร์

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

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

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

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

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

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

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

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

2.4.4 ประสิทธิภาพและศักยภาพ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

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

  • [7.3/A-0-2] สถานที่ตั้ง ได้รับคำขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่ใช่แผนที่ที่ตรงกัน

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

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

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

  • [7.3.4/A-2-1] ต้องรายงานเหตุการณ์ได้สูงสุด ความถี่อย่างน้อย 100 Hz
  • [7.3.4/A-2-3] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้ ได้สูงสุดถึง 250 องศาต่อวินาที
  • [7.3.4/A-SR-1] ขอแนะนําอย่างยิ่งให้กําหนดค่า ช่วงการวัดของเครื่องวัดการหมุนอยู่ที่ +/-250 dps เพื่อเพิ่มความละเอียดให้สูงสุด ที่เป็นไปได้

หากใช้อุปกรณ์ Automotive มีตัวรับ GPS/GNSS แต่ไม่ได้ รวมถึงการเชื่อมต่อข้อมูลผ่านเครือข่ายมือถือ ซึ่งจะ:

  • [7.3.3/A-3-1] ต้องกำหนดตำแหน่งในครั้งแรก ตัวรับสัญญาณ GPS/GNSS เปิดอยู่หรือหลังจากผ่านไป 4 วันขึ้นไปภายใน 60 วินาที
  • [7.3.3/A-3-2] ต้องเป็นไปตามเกณฑ์กำหนดเวลาที่ต้องแก้ไขก่อนดังที่ระบุ ตามที่อธิบายไว้ใน 7.3.3/C-1-2 และ 7.3.3/C-1-6 สําหรับคําขอตำแหน่งอื่นๆ ทั้งหมด (เช่น คําขอที่ไม่ใช่ครั้งแรก เลยหรือหลังจาก 4 วันขึ้นไป) ข้อกำหนด 7.3.3/C-1-2 คือ ในรถยนต์ที่ไม่มีการเชื่อมต่ออินเทอร์เน็ต ผ่านเครือข่ายมือถือ โดยใช้การคาดการณ์วงโคจรของ GNSS ที่คำนวณบนเครื่องรับ หรือใช้ ตำแหน่งล่าสุดที่ทราบของยานพาหนะ รวมถึงความสามารถในการจอดพัก อย่างน้อย 60 วินาทีโดยความถูกต้องของตำแหน่งเป็นไปตามที่กำหนด 7.3.3/C-1-3 หรือทั้ง 2 อย่างร่วมกัน

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

  • [7.4.3/A-0-1] ต้องรองรับบลูทูธและควร รองรับ Bluetooth LE
  • [7.4.3/A-0-2] การติดตั้งใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้
    • การโทรผ่านโทรศัพท์ผ่านโปรไฟล์แฮนด์ฟรี (HFP)
    • การเล่นสื่อผ่าน Audio Distribution Profile (A2DP)
    • การควบคุมการเล่นสื่อบนโปรไฟล์รีโมตคอนโทรล (AVRCP)
    • การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)
  • [7.4.3/A-SR-1] แนะนําอย่างยิ่งให้สนับสนุน Message Access Profile (MAP)

  • [7.4.5/A] ควรมีการรองรับเครือข่ายมือถือ การเชื่อมต่อข้อมูลตามเครือข่าย

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

กล้องมุมมองภายนอกคือกล้องที่บันทึกภาพบรรยากาศภายนอกอุปกรณ์ เช่น Dashcam

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

  • ควรมีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว

หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภายนอก กล้องถ่ายรูป

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

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

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

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

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

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

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

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

    • 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
    • ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
    • mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
  • [7.6.1/A-1-2] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 608 MB หากใช้ความหนาแน่นดังต่อไปนี้

    • xhdpi ขึ้นไปสำหรับหน้าจอขนาดเล็ก/ปกติ
    • hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
    • MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
  • [7.6.1/A-1-3] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นดังต่อไปนี้

    • 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
    • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
    • tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
  • [7.6.1/A-1-4] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากความหนาแน่นดังต่อไปนี้ ที่ใช้:

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

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

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

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

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

    • 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
    • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
    • tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
  • [7.6.1/A-2-4] หน่วยความจำที่มีให้กับเคอร์เนล และพื้นที่ของผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากใช้ความหนาแน่นดังต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3 ซอฟต์แวร์

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

  • [3/A-0-1] ต้องประกาศฟีเจอร์ android.hardware.type.automotive

  • [3/A-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_CAR

  • [3/A-0-3] ต้องรองรับ API สาธารณะทั้งหมดใน android.car.* Namespace

หากการติดตั้งใช้งานอุปกรณ์ Automotive มี API ที่เป็นกรรมสิทธิ์โดยใช้ android.car.CarPropertyManager ที่มี android.car.VehiclePropertyIds, ดังนี้

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

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

  • [3.2.1/A-0-1] ต้องรองรับและบังคับใช้ทั้งหมด สิทธิ์คงที่ตามที่บันทึกข้อมูลไว้ในหน้าข้อมูลอ้างอิงสิทธิ์สำหรับยานยนต์

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

  • [3.4.1/A-0-1] ต้องระบุฟิลด์ การใช้งาน android.webkit.Webview API

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

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

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

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

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

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

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

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

  • [3.14/A-0-1] ต้องมีเฟรมเวิร์ก UI เพื่อสนับสนุน แอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วน 3.14
  • [3.14/A-0-2] ต้องอนุญาตให้ผู้ใช้โต้ตอบได้อย่างปลอดภัย ด้วยแอปพลิเคชันสื่อขณะขับรถ
  • [3.14/A-0-3] ต้องรองรับ CAR_INTENT_ACTION_MEDIA_TEMPLATE การดำเนินการ Intent แบบไม่เจาะจงปลายทางด้วยฟังก์ชัน CAR_EXTRA_MEDIA_PACKAGE เพิ่มเติม
  • [3.14/A-0-4] ต้องมีเงินเพียงพอในการเข้าใช้ ของแอปพลิเคชันสื่อ ค่ากำหนด กิจกรรม แต่ต้องเปิดใช้เฉพาะเมื่อข้อจำกัด UX ของรถยนต์ไม่มีผล
  • [3.14/A-0-5] ต้องแสดง ข้อความแสดงข้อผิดพลาด ตั้งค่าโดยแอปพลิเคชันสื่อ และต้องรองรับบริการเสริม ERROR_RESOLUTION_ACTION_LABEL และ ERROR_RESOLUTION_ACTION_INTENT
  • [3.14/A-0-6] ต้องรองรับราคาในการค้นหาในแอปสำหรับ ซึ่งเป็นแอปที่รองรับการค้นหา
  • [3.14/A-0-7] ต้องเคารพ CONTENT_STYLE_BROWSABLE_HINT และ CONTENT_STYLE_PLAYABLE_HINT เมื่อแสดง MediaBrowser ลำดับชั้น

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

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

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

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

2.5.4 ประสิทธิภาพและศักยภาพ

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

  • [8.2/A-0-1] ต้องรายงานจำนวน ไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลที่ไม่ผันผวนต่อ UID ของแต่ละกระบวนการเพื่อค่า สถิติพร้อมให้นักพัฒนาซอฟต์แวร์ใช้งานผ่าน System API android.car.storagemonitoring.CarStorageMonitoringManager Android Open โปรเจ็กต์ต้นทางมีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของ uid_sys_stats
  • [8.3/A-1-3] ต้องรองรับโหมดโรงรถ
  • [8.3/A] ควรอยู่ในโหมดโรงรถอย่างน้อย 15 นาทีหลังการขับขี่ทุกครั้ง ยกเว้นในกรณีต่อไปนี้
    • แบตเตอรี่หมด
    • ไม่มีกำหนดเวลางานที่ไม่มีการใช้งาน
    • คนขับออกจากโหมด Garage
  • [8.4/A-0-1] ต้องระบุ โปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดมูลค่าการใช้งานปัจจุบัน ของส่วนประกอบฮาร์ดแวร์แต่ละส่วนและ ปริมาณการใช้แบตเตอรี่โดยประมาณที่เกิดจาก ในช่วงเวลาที่ผ่านมาตามที่ระบุไว้ในไซต์โครงการโอเพนซอร์ส Android
  • [8.4/A-0-2] ต้องรายงานพลังงานทั้งหมด ค่าการบริโภคในหน่วยมิลลิแอมแปร์ชั่วโมง (mAh)
  • [8.4/A-0-3] ต้องรายงานกำลังของ CPU การใช้งานต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android พบกับ ผ่านการใช้งานโมดูลเคอร์เนล uid_cputime
  • [8.4/A] ควรมีแหล่งที่มาจาก ของส่วนประกอบฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของส่วนประกอบฮาร์ดแวร์ได้ ในแอปพลิเคชัน
  • [8.4/A-0-4] ต้องใช้พลังงานเช่นนี้ มีให้บริการผ่าน adb shell dumpsys batterystats เชลล์ไปยังนักพัฒนาแอป

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

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

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

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

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

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

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

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

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

  • Perfetto
    • [6.1/A-0-1] ต้องแสดง /system/bin/perfetto ไบนารีของผู้ใช้เชลล์ที่ 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

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

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

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

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

2.6.1 ฮาร์ดแวร์

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

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

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

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

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

โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7.1)

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

  • [7.7.1/Tab] อาจใช้ Android Open Accessory (AOA) API

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

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

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

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

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

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

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

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

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

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

2.6.2 ซอฟต์แวร์

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

3. ซอฟต์แวร์

3.1 ความเข้ากันได้กับ API ที่มีการจัดการ

สภาพแวดล้อมการดำเนินการแบบไบต์โค้ด Dalvik ที่มีการจัดการคือพาหนะหลักสำหรับ แอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือ ชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยต่อแอปพลิเคชันที่ทำงานใน สภาพแวดล้อมรันไทม์ที่มีการจัดการ

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

  • [C-0-1] ต้องมีการติดตั้งใช้งานที่สมบูรณ์ รวมถึงเอกสารทั้งหมด ของ API ที่บันทึกไว้ใน Android SDK หรือ API ใดๆ ที่ตกแต่งด้วยเครื่องหมาย “@SystemApi” ในอัปสตรีม Android ซอร์สโค้ด

  • [C-0-2] ต้องสนับสนุน/รักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมด ที่ระบุโดยคำอธิบายประกอบ TestApi (@TestApi)

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

  • [C-0-4] ต้องทำให้ API ยังอยู่และทำงานได้ อย่างเหมาะสม แม้แต่ในกรณีที่คุณลักษณะของฮาร์ดแวร์บางอย่างที่ Android โดยจะละเว้น API เอาไว้ ดูส่วนที่ 7 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้

  • [C-0-5] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK คือเมธอดและฟิลด์ในแพ็กเกจภาษา Java ที่ ในคลาสพาธการเปิดเครื่องใน AOSP และไม่ใช่ส่วนหนึ่งของผู้ใช้ทั่วไป SDK ซึ่งรวมถึง API ที่ตกแต่งด้วยคำอธิบายประกอบ @hide แต่ไม่มีกับ @SystemAPI ตามที่อธิบายไว้ในเอกสาร SDK ทั้งแบบส่วนตัวและแบบแพ็กเกจ

  • [C-0-6] ต้องจัดส่งอินเทอร์เฟซที่ไม่ใช่ SDK ทั้งหมดในส่วนเดียวกันและอินเทอร์เฟซที่ไม่ใช่ SDK เดียวกัน ตามที่ระบุไว้ผ่านแฟล็กชั่วคราวและรายการที่ปฏิเสธใน prebuilts/runtime/appcompat/hiddenapi-flags.csv เส้นทางสำหรับสาขาระดับ API ที่เหมาะสมใน AOSP

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

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

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

3.1.1. ส่วนขยาย Android

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

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

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

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

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

3.1.2. ไลบรารี Android

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

  • [C-0-1] เพื่อให้ค่าที่มีความหมายและสอดคล้องกันในทุกอุปกรณ์ ตารางด้านล่างนี้จะรวมถึงข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบ ของค่าเหล่านี้ซึ่งการติดตั้งใช้งานอุปกรณ์ต้องสอดคล้อง
พารามิเตอร์ รายละเอียด
VERSION.RELEASE เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบัน ในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน สตริงเวอร์ชันที่อนุญาตสำหรับ Android 12
VERSION.SDK เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบ รหัสแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 12 ช่องนี้ต้องมีค่าจำนวนเต็ม 12_INT
VERSION.SDK_INT เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบ รหัสแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 12 ช่องนี้ต้องมีค่าจำนวนเต็ม 12_INT
เวอร์ชันที่เพิ่มขึ้น ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์ที่เฉพาะเจาะจง ของระบบ Android ที่กำลังเรียกใช้อยู่ ในรูปแบบที่มนุษย์อ่านได้ ช่วงเวลานี้ ต้องไม่นําค่ามาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางใช้งานได้ ต การใช้งานตามปกติของฟิลด์นี้คือ เพื่อระบุหมายเลขบิลด์หรือ มีการใช้ตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาในการสร้างบิลด์ ค่า ของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตที่พิมพ์ได้ และตรงกับ นิพจน์ทั่วไป “^[^ :\/~]+$”
กระดาน ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุถึง ฮาร์ดแวร์ภายในที่อุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ เป็นไปได้ ช่องนี้ใช้เพื่อระบุเวอร์ชันที่เจาะจงของการจ่ายไฟของบอร์ด อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและ จับคู่นิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$"
แบรนด์ ค่าที่แสดงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ ผู้ใช้ปลายทาง ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้และควรแสดงถึง ผู้ผลิตอุปกรณ์หรือแบรนด์บริษัทของอุปกรณ์ ในการทำการตลาด ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและตรงกัน นิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$"
SUPPORTED_ABIS ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
SUPPORTED_32 BIT_ABIS ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
SUPPORTED_64 BIT_ABIS ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของ โค้ดแบบเนทีฟ ดูส่วนที่ 3.3 เนทีฟ ความเข้ากันได้กับ API
CPU ABI ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโฆษณาเนทีฟ โค้ด ดูส่วนที่ 3.3 API ดั้งเดิม ความเข้ากันได้
CPU ABI2 ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของ โค้ดแบบเนทีฟ ดูส่วนที่ 3.3 เนทีฟ ความเข้ากันได้กับ API
อุปกรณ์ ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนา หรือชื่อรหัสที่ระบุการกำหนดค่าฟีเจอร์ของฮาร์ดแวร์และ การออกแบบเชิงอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสได้ เป็น ASCII แบบ 7 บิต และจับคู่นิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้จะต้องไม่เปลี่ยนชื่อในระหว่าง อายุการใช้งานของผลิตภัณฑ์
Fingerprint สตริงที่ระบุบิลด์นี้ได้โดยไม่ซ้ำกัน ควรมีเหตุผล ที่มนุษย์อ่านได้ ต้องเป็นไปตามเทมเพลตนี้

$(BRAND)/$(ผลิตภัณฑ์)/
$(DEVICE):$(VERSION.RELEASE)/$(รหัส)/$(VERSION.INCREMENTAL):$(ประเภท)/$(แท็ก)

เช่น

acme/myproduct/
mydevice:12/LMYXX/3359:userdebug/test-keys

ลายนิ้วมือต้องไม่มีอักขระช่องว่าง ค่าของ ช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต

ฮาร์ดแวร์ ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) ทั้งนี้ ควรให้มนุษย์อ่านเข้าใจได้พอสมควร ค่าของช่องนี้ต้องเป็น เข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
ผู้จัด สตริงที่ระบุโฮสต์ที่สร้างบิลด์โดยไม่ซ้ำกัน ที่มนุษย์อ่านได้ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของ ฟิลด์นี้ เว้นแต่ว่าช่องจะต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("")
รหัส ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างถึง เผยแพร่ในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่เพียงพอ มีความหมายต่อผู้ใช้ปลายทาง เพื่อแยกระหว่างรุ่นซอฟต์แวร์ต่างๆ ค่า ของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ “^[a-zA-Z0-9._-]+$"
ผู้ผลิต ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของบริษัท ผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ว่าต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("") ฟิลด์นี้ ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC_ผู้ผลิต การแลกเปลี่ยนชื่อผู้ผลิต ระบบหลัก บน ชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SOC รายเดียวกัน ควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC สำหรับ ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสได้ เป็น ASCII แบบ 7 บิต ต้องตรงกับนิพจน์ทั่วไป “^([0-9A-Za-z ]+)” ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่รู้จัก" ช่องนี้ต้องไม่เปลี่ยนแปลงในระหว่าง อายุการใช้งานของผลิตภัณฑ์
โมเดล SOC_MODEL ชื่อรุ่นของระบบหลักบนชิป (SOC) ที่ใช้ใน ผลิตภัณฑ์ อุปกรณ์ที่มี SOC รุ่นเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อใช้ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป “^([0-9A-Za-z ._/+-]+)$” ต้องไม่ขึ้นต้น หรือ ลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ฟิลด์นี้ ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
MODEL ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่อของ อุปกรณ์ที่ผู้ใช้ปลายทางทราบ ชื่อนี้ควรเป็นชื่อเดียวกับที่ มีการทำการตลาดและขายอุปกรณ์ให้กับผู้ใช้ปลายทาง ไม่มีข้อกำหนดสำหรับ รูปแบบเฉพาะของฟิลด์นี้ ยกเว้นว่าต้องเป็นค่าว่าง หรือ สตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงในระหว่าง อายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์ ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนา หรือรหัสของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) ที่ต้องไม่ซ้ำกันภายใน แบรนด์เดียวกัน ต้องเป็นภาษาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับการดู จากผู้ใช้ปลายทาง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและ จับคู่นิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ผลิตภัณฑ์นี้ ชื่อต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ODM_SKU ค่าที่ไม่บังคับซึ่งผู้ให้บริการอุปกรณ์เลือกซึ่งมี SKU (Stock Keeping Unit) ใช้เพื่อติดตามการกำหนดค่าที่เจาะจงของ เช่น อุปกรณ์ต่อพ่วงใดๆ ที่รวมอยู่ในอุปกรณ์เมื่อจำหน่าย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป ^([0-9A-Za-z.,_-]+)$
ซีเรียล ต้องส่งคืน "UNKNOWN"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ให้บริการอุปกรณ์เลือก สร้างความโดดเด่นให้กับงานสร้างมากเป็นพิเศษ แท็กต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และจับคู่นิพจน์ทั่วไป “^[a-zA-Z0-9._-]+” และ "ต้อง" มีค่าใดค่าหนึ่งที่สอดคล้องกับแพลตฟอร์ม Android ทั่วไป 3 แพลตฟอร์ม การกำหนดค่าการรับรอง: คีย์การเผยแพร่, คีย์นักพัฒนาซอฟต์แวร์ และคีย์การทดสอบ
เวลา ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์
ประเภท ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุรันไทม์ ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่ง ตามการกำหนดค่ารันไทม์ทั่วไปของ Android 3 แบบ ได้แก่ ผู้ใช้ การแก้ไขข้อบกพร่องของผู้ใช้ หรือการมีส่วนร่วม
ผู้ใช้ ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้าง งานสร้าง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ว่าต้องไม่เป็นค่าว่างหรือสตริงว่างเปล่า ("")
แพตช์ด้านความปลอดภัย ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องแสดงถึง การสร้างแอปไม่ได้มีช่องโหว่ต่อปัญหาใดๆ ที่อธิบายไว้ ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ ต้องเป็น รูปแบบ [YYYY-MM-DD] ตรงกับสตริงที่กำหนดซึ่งระบุไว้ใน กระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android หรือใน คำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่ หรือเหมือนกันกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ใน กระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android จะต้องรายงานค่าที่ถูกต้อง และถ้า ไม่มีบิลด์ดังกล่าว รายงานสตริงว่างเปล่า ("")
รองเท้าบู๊ต ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุถึง เวอร์ชัน Bootloader ภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับ นิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$"
getRadioVersion() ต้อง (หรือส่งคืน) ค่าที่เลือกโดยผู้ใช้อุปกรณ์ ระบุเวอร์ชันวิทยุ/โมเด็มภายในที่ใช้ในอุปกรณ์ ในรูปแบบที่มนุษย์อ่านได้ ถ้าอุปกรณ์ไม่มีภายใน Radio/modem ต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเป็น เข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$"
getSerial() ต้อง (มีหรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่ง "ต้องมี" และไม่ซ้ำกับผู้อื่นบนอุปกรณ์ที่ใช้ MODEL และ MANUFACTURER เหมือนกัน ค่าของ ช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$"

3.2.3 ความเข้ากันได้กับ Intent

3.2.3.1 Intent ทั่วไปของแอปพลิเคชัน

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

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

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

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

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

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

  • [C-0-3] การใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้ แก้ไขกิจกรรมเริ่มต้นสำหรับ Intent

  • อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์อาจมีกิจกรรมเริ่มต้นสำหรับ รูปแบบ URI (เช่น http://play.google.com) เมื่อกิจกรรมเริ่มต้นระบุพารามิเตอร์ แอตทริบิวต์ที่เจาะจงมากขึ้นสำหรับ URI ข้อมูล เช่น รูปแบบตัวกรอง Intent การระบุ URI ข้อมูล “http://www.android.com” เฉพาะเจาะจงมากกว่า รูปแบบ Intent หลักของเบราว์เซอร์สำหรับ “http://”

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

  • [C-0-4] ต้องพยายามตรวจสอบตัวกรอง Intent โดยการดำเนินการ ขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดเกี่ยวกับลิงก์เนื้อหาดิจิทัล ตามที่มีการใช้โดย Package Manager ในโอเพนซอร์ส Android โอเพนซอร์ส โปรเจ็กต์
  • [C-0-5] ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้ง แอปพลิเคชันและตั้งค่าตัวกรอง Intent URI ที่ผ่านการตรวจสอบความถูกต้องทั้งหมดแล้วเป็น เครื่องจัดการแอปเริ่มต้นสำหรับ URI ของตน
  • อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของผู้ใช้ หากยืนยันสำเร็จ แต่ตัวกรอง URI ที่แนะนำอื่นๆ ดำเนินการไม่สำเร็จ การยืนยันของคุณ หากการติดตั้งใช้งานอุปกรณ์มีลักษณะดังกล่าว จะต้องระบุ ลบล้างรูปแบบต่อ URI ที่เหมาะสมในเมนูการตั้งค่า
  • ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้กับผู้ใช้ในการตั้งค่าเป็น ดังต่อไปนี้:
    • [C-0-6] ผู้ใช้ต้องสามารถลบล้างแอปเริ่มต้นในภาพรวมได้ เป็นลักษณะการทำงานของลิงก์ เช่น เปิดตลอดเวลา ถามทุกครั้ง หรือไม่เปิดเลย ซึ่งต้องนำไปใช้กับตัวกรอง Intent ของ URI ที่เป็นตัวเลือกเท่าๆ กัน
    • [C-0-7] ผู้ใช้ต้องสามารถดูรายการ Intent ของ URI ที่รอการพิจารณา ตัวกรอง
    • การนำอุปกรณ์มาใช้อาจทำให้ผู้ใช้ดำเนินการต่อไปนี้ได้ ลบล้างตัวกรอง Intent ของ URI ที่เป็นตัวเลือกที่ดำเนินการสำเร็จ ได้รับการยืนยันตามตัวกรองต่อความตั้งใจ
    • [C-0-8] การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้สามารถ ดูและลบล้างตัวกรอง Intent ของ URI ที่เป็นตัวเลือกที่เจาะจงหากอุปกรณ์ การใช้งานช่วยให้ตัวกรอง Intent ของ URI ที่เลือกประสบความสำเร็จได้ แต่บางกรณีก็อาจล้มเหลวได้
3.2.3.3 เนมสเปซ Intent
  • [C-0-1] การใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ที่ ดำเนินการตามรูปแบบความตั้งใจหรือจุดประสงค์ในการออกอากาศใหม่ๆ โดยใช้ ACTION, CATEGORY หรือ สตริงคีย์อื่นๆ ในเนมสเปซ android.* หรือ com.android.*
  • [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่มีองค์ประกอบ Android ที่ ยึดรูปแบบความตั้งใจหรือความตั้งใจใหม่ๆ ในการออกอากาศโดยใช้ ACTION, CATEGORY หรือ สตริงคีย์อื่นในพื้นที่แพ็กเกจที่เป็นขององค์กรอื่น
  • [C-0-3] ผู้ปฏิบัติงานใช้อุปกรณ์ต้องไม่เปลี่ยนแปลงหรือขยายเจตนาใดๆ รูปแบบที่แสดงในหัวข้อ 3.2.3.1
  • การใช้งานอุปกรณ์อาจรวมรูปแบบความตั้งใจที่ใช้เนมสเปซอย่างชัดเจน และเห็นได้ชัดว่ามีความเชื่อมโยงกับองค์กรของตน ข้อห้ามนี้ ซึ่งคล้ายกับที่ระบุสำหรับคลาสภาษา Java ในส่วนที่ 3.6
3.2.3.4 ความตั้งใจในการออกอากาศ

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

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

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

Android มีการตั้งค่าที่ช่วยให้ผู้ใช้สามารถเลือก แอปพลิเคชันเริ่มต้น เช่น หน้าจอหลักหรือ SMS

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

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

  • [C-1-1] ต้องปฏิบัติตาม android.settings.HOME_SETTINGS ต้องการแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก

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

  • [C-2-1] ต้องระบุเมนูการตั้งค่าที่เรียก android.provider.Telephony.ACTION_CHANGE_DEFAULT ต้องการแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น

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

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

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

  • [C-2-5] ต้องให้เงินแก่ผู้ใช้ในการเลือกแอปที่มี android.app.role.CALL_REDIRECTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ประกาศการรองรับกล้องผ่านทาง android.hardware.camera.any พวกเขา:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม Android ปกติในอุปกรณ์รอง และจอแสดงผลรองจะมี android.view.Display.FLAG_PRIVATE ธง:

  • [C-3-1] เฉพาะเจ้าของจอแสดงผล ระบบ และกิจกรรมที่ อยู่บนจอแสดงผลนั้นอยู่แล้ว ต้องเปิดในจอแสดงผลนั้นได้ ทุกคนสามารถเปิดใช้งาน จอแสดงผลที่มี android.view.Display.FLAG_PUBLIC แจ้ง

3.3 ความเข้ากันได้กับ API เดิม

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

  • [C-SR-1] แนะนำอย่างยิ่งให้ใช้การใช้งานของไลบรารี ที่แสดงด้านล่างจากโปรเจ็กต์โอเพนซอร์ส Android

3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน

ไบต์โค้ด Dalvik ที่มีการจัดการจะเรียกใช้โค้ดแบบเนทีฟที่ระบุไว้ในแอปพลิเคชันได้ ไฟล์ .apk เป็นไฟล์ ELF .so ที่คอมไพล์ไว้สำหรับฮาร์ดแวร์อุปกรณ์ที่เหมาะสม สถาปัตยกรรม เนื่องจากโค้ดแบบเนทีฟจะขึ้นอยู่กับโปรเซสเซอร์ที่เกี่ยวข้องเป็นสำคัญ Android ได้กำหนด จำนวนอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) ใน Android NDK

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

  • [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่กำหนดไว้อย่างน้อย 1 รายการ
  • [C-0-2] ต้องมีการรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อ ลงในโค้ดแบบเนทีฟ โดยใช้ Java Native Interface (JNI) มาตรฐาน อรรถศาสตร์
  • [C-0-3] ต้องรองรับแหล่งที่มา (เช่น ใช้ร่วมกับส่วนหัวได้) และ ไบนารีที่ใช้ร่วมกันได้ (สำหรับ ABI) พร้อมด้วยไลบรารีที่จำเป็นแต่ละรายการในรายการ ที่ด้านล่าง
  • [C-0-5] ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชันแบบเนทีฟอย่างถูกต้อง (ABI) ที่อุปกรณ์รองรับผ่าน android.os.Build.SUPPORTED_ABIS android.os.Build.SUPPORTED_32_BIT_ABIS และ android.os.Build.SUPPORTED_64_BIT_ABIS พารามิเตอร์ คั่นแต่ละรายการด้วยเครื่องหมายจุลภาค รายการ ABI ที่เรียงลำดับจากมากที่สุดไปน้อยที่สุด
  • [C-0-6] ต้องรายงานชุดย่อยของข้อมูลต่อไปนี้ โดยใช้พารามิเตอร์ข้างต้น รายชื่อ ABI และต้องไม่รายงาน ABI ใดๆ ที่ไม่ได้อยู่ในรายการ

    • armeabi (NDK ไม่รองรับการกําหนดเป้าหมายอีกต่อไป)
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64
  • [C-0-7] ต้องสร้างไลบรารีต่อไปนี้ทั้งหมด โดยให้ API แบบเนทีฟ ใช้ได้กับแอปที่มีโค้ดแบบเนทีฟ

    • libaaudio.so (รองรับเสียงแบบเนทีฟ)
    • libamidi.so (การรองรับ MIDI เนทีฟหากมีฟีเจอร์ android.software.midi มีการอ้างสิทธิตามที่อธิบายไว้ในส่วน 5.9)
    • libandroid.so (การสนับสนุนกิจกรรมในเครื่องของ Android)
    • libc (ไลบรารี C)
    • libcamera2ndk.so
    • libdl (ลิงก์แบบไดนามิก)
    • libEGL.so (การจัดการแพลตฟอร์ม OpenGL ของระบบ)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (การบันทึกของ Android)
    • libmediandk.so (รองรับ API สื่อเนทีฟ)
    • libm (ห้องสมุดคณิตศาสตร์)
    • libneuralnetworks.so (API เครือข่ายประสาทเทียม)
    • libOpenMAXAL.so (การสนับสนุน OpenMAX AL 1.0.1)
    • libOpenSLES.so (การสนับสนุนระบบเสียง OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (การสนับสนุนขั้นต่ำสำหรับ C++)
    • libvulkan.so (วัลคาน)
    • libz (การบีบอัด Zlib)
    • อินเทอร์เฟซ JNI
  • [C-0-8] ต้องไม่เพิ่มหรือนำฟังก์ชันสาธารณะสำหรับไลบรารีเนทีฟออก ตามรายการข้างต้น

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

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

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

  • [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับฟังก์ชัน Vulkan 1.0 หลัก สัญลักษณ์ต่างๆ รวมถึง VK_KHR_surface, VK_KHR_android_surface VK_KHR_swapchain, VK_KHR_maintenance1 และ ส่วนขยายจำนวน VK_KHR_get_physical_device_properties2 คลัง libvulkan.so โปรดทราบว่าแม้ต้องมีสัญลักษณ์ทั้งหมด ส่วนที่ 7.1.4.2 อธิบายรายละเอียดเพิ่มเติมถึงข้อกำหนดเกี่ยวกับ การใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการนั้นคาดว่าจะได้รับ

  • ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ใน อัปสตรีมโครงการโอเพนซอร์ส Android

โปรดทราบว่า Android รุ่นต่อๆ ไปอาจเพิ่มการรองรับ ABI

3.3.2 ความเข้ากันได้กับโค้ดแบบเนทีฟของ ARM 32 บิต

การนำอุปกรณ์ไปใช้รายงานการรองรับ ABI ของ armeabi สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-3-1] ต้องสนับสนุน armeabi-v7a ด้วยและรายงานการรองรับ เช่น armeabi มีไว้สำหรับความเข้ากันได้แบบย้อนหลังกับแอปรุ่นเก่าเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ ABI ของ armeabi-v7a สำหรับแอป ที่ใช้ ABI นี้

  • [C-2-1] ต้องใส่บรรทัดต่อไปนี้ใน /proc/cpuinfo และไม่ควร ปรับเปลี่ยนค่าในอุปกรณ์เดียวกัน แม้ว่า ABI อื่นๆ จะอ่านค่านั้นก็ตาม

    • Features: ตามด้วยรายการฟีเจอร์ CPU ARMv7 ที่ไม่บังคับ ที่อุปกรณ์รองรับ
    • CPU architecture: ตามด้วยจำนวนเต็มที่อธิบายข้อมูลต่อไปนี้ สถาปัตยกรรม ARM ที่รองรับสูงสุด (เช่น "8" สำหรับอุปกรณ์ ARMv8)
  • [C-2-2] ต้องทำให้การดำเนินการต่อไปนี้พร้อมใช้งานเสมอ แม้ใน ในกรณีที่มีการใช้ ABI ในสถาปัตยกรรม ARMv8 ไม่ว่าจะผ่าน การสนับสนุน CPU ในตัวหรือผ่านการจำลองซอฟต์แวร์:

    • วิธีการสำหรับ SWP และ SWPB
    • การดำเนินงานที่เป็นอุปสรรคของ CP15ISB, CP15DSB และ CP15DMB
  • [C-2-3] ต้องรวมการรองรับ Advanced SIMD (หรือที่เรียกว่า NEON)

3.4 ความเข้ากันได้กับเว็บ

3.4.1 ความเข้ากันได้กับ WebView

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

  • [C-1-1] ต้องรายงาน android.software.webview
  • [C-1-2] ต้องใช้บิลด์โปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางบน Android 12 สาขาสำหรับการติดตั้งใช้งาน android.webkit.WebView API
  • [C-1-3] สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบต่อไปนี้

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

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

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

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

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

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

  • [C-1-1] ต้องรองรับ API แต่ละรายการเหล่านี้ที่เชื่อมโยงกับ HTML5
  • [C-1-2] ต้องรองรับ HTML5/W3C webstorage API และควรรองรับ HTML5/W3C IndexedDB API โปรดทราบว่าตามที่เว็บ หน่วยงานด้านมาตรฐานการพัฒนากำลังเปลี่ยนไปใช้ IndexedDB webstorage คาดหวังว่า IndexedDB จะเป็นองค์ประกอบที่จำเป็นใน Android เวอร์ชันอนาคต
  • อาจจัดส่งสตริง User Agent ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
  • ควรใช้การสนับสนุน HTML5 ให้มากที่สุดเท่าที่จะเป็นไปได้ในสแตนด์อโลน แอปพลิเคชันเบราว์เซอร์ (ไม่ว่าจะใช้เบราว์เซอร์ WebKit อัปสตรีมหรือไม่ก็ตาม หรือบุคคลที่สาม)

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

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

3.5 ความเข้ากันได้ด้านพฤติกรรมของ API

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

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

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

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

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

3.5.1 ข้อจำกัดแอปพลิเคชัน

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

  • [C-1-1] ต้องให้เงินแก่ผู้ใช้ที่ผู้ใช้สามารถดูรายการ แอปที่ถูกจำกัด
  • [C-1-2] ต้องให้เงินแก่ผู้ใช้ในการเปิด / ปิดข้อจำกัด ในแต่ละแอป
  • [C-1-3] ต้องไม่ใช้ข้อจำกัดโดยอัตโนมัติหากไม่มีหลักฐานว่ามีประสิทธิภาพไม่ดี ลักษณะการทำงานของระบบแต่อาจใช้การจำกัดในแอปเมื่อตรวจพบ แสดงการทำงานของระบบที่ไม่ดี เช่น การทำงานขณะล็อกที่ค้าง บริการที่ใช้เวลานาน และ เกณฑ์อื่นๆ ผู้ให้บริการอุปกรณ์อาจกำหนดเกณฑ์นี้ได้ แต่จะต้อง เกี่ยวข้องกับผลกระทบที่แอปมีต่อประสิทธิภาพของระบบ เกณฑ์อื่นๆ ที่ไม่ใช่ เกี่ยวข้องกับประสิทธิภาพของระบบแต่เพียงอย่างเดียว เช่น การที่แอปไม่ได้รับความนิยม ตลาดต้องไม่ใช่เกณฑ์
  • [C-1-4] ต้องไม่ใช้การจำกัดแอปกับแอปโดยอัตโนมัติเมื่อผู้ใช้ ปิดการจำกัดแอปด้วยตนเอง และอาจแนะนำให้ผู้ใช้ใช้ ข้อจำกัดแอป
  • [C-1-5] ต้องแจ้งให้ผู้ใช้ทราบหากมีการใช้ข้อจำกัดของแอปกับแอป โดยอัตโนมัติ ข้อมูลดังกล่าวจะต้องแสดงภายใน 24 ชั่วโมงหลังจาก มีข้อจำกัด
  • [C-1-6] ต้องส่งคืน true ในราคา ActivityManager.isBackgroundRestricted() เมื่อแอปที่ถูกจำกัดเรียกใช้ API นี้
  • [C-1-7] ต้องไม่จำกัดแอปที่ทำงานอยู่เบื้องหน้าด้านบนที่ใช้อย่างชัดแจ้ง โดยผู้ใช้
  • [C-1-8] ต้องระงับการจำกัดแอปที่จะกลายเป็นเบื้องหน้าอันดับแรก เมื่อผู้ใช้เริ่มใช้แอปที่เคยใช้งาน แบบจำกัด
  • [C-1-10] ต้องไม่อนุญาตให้วางแอปในกลุ่ม "ถูกจำกัด" โดยอัตโนมัติ ที่เก็บข้อมูลภายใน 2 ชั่วโมงหลังจากที่ผู้ใช้ใช้งานล่าสุด

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

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

3.5.2 ไฮเบอร์เนตของแอปพลิเคชัน

หากการใช้งานอุปกรณ์มี App Hibernation ที่รวมอยู่ใน AOSP หรือ ขยายฟีเจอร์ที่รวมอยู่ใน AOSP จากนั้นจะ

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

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

3.6 เนมสเปซ API

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

รูปแบบหน้าจอ ความหนาแน่นของหน้าจอ หน่วยความจำแอปพลิเคชันขั้นต่ำ
นาฬิกาข้อมือ Android 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (Xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
เล็ก/ปกติ 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (Xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
ใหญ่ 120 dpi (ldpi) 32MB
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (Xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
xlarge 120 dpi (ldpi) 48MB
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (Xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8 ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้

3.8.1 Launcher (หน้าจอหลัก)

Android มีแอปพลิเคชัน Launcher (หน้าจอหลัก) และการรองรับ แอปพลิเคชันของบุคคลที่สามที่จะแทนที่ Launcher ของอุปกรณ์ (หน้าจอหลัก)

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

  • [C-1-1] ต้องประกาศฟีเจอร์ของแพลตฟอร์ม android.software.home_screen
  • [C-1-2] ต้องส่งคืน AdaptiveIconDrawable เมื่อแอปพลิเคชันของบุคคลที่สามใช้แท็ก <adaptive-icon> เพื่อระบุ ไอคอนของผู้ใช้ และPackageManager มีการเรียกเมธอดในการเรียกไอคอน

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

  • [C-2-1] ต้องรายงาน true สำหรับ ShortcutManager.isRequestPinShortcutSupported()
  • [C-2-2] ต้องมีค่าใช้จ่ายของผู้ใช้ที่ขอผู้ใช้ก่อนที่จะเพิ่มทางลัดที่ขอ ผ่าน ShortcutManager.requestPinShortcut() เมธอดของ API
  • [C-2-3] ต้องรองรับแป้นพิมพ์ลัดที่ปักหมุดไว้ รวมถึงแบบไดนามิกและแบบคงที่ ตามที่บันทึกไว้ในหน้าทางลัดของแอป

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

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

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

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

  • [C-5-1] ต้องเป็นไปตาม NotificationChannel.setShowBadge() เมธอดของ API กล่าวคือ แสดงภาพในราคาที่เกี่ยวข้องกับไอคอนแอปหาก ได้รับการตั้งค่าเป็น true และไม่แสดงรูปแบบการติดป้ายไอคอนแอปใดๆ เมื่อทั้งหมด ของช่องทางการแจ้งเตือนของแอปได้กำหนดค่าเป็น false
  • อาจลบล้างป้ายไอคอนแอปด้วยรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์เมื่อ แอปพลิเคชันของบุคคลที่สามระบุการรองรับรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์ ผ่านการใช้ API ที่เป็นกรรมสิทธิ์ แต่ควรใช้ทรัพยากรและค่า ที่มีให้ผ่าน API ป้ายการแจ้งเตือนที่อธิบายไว้ใน SDK เช่น Notification.Builder.setNumber() และ Notification.Builder.setBadgeIconType() API

3.8.2 วิดเจ็ต

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

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

  • [C-1-1] ต้องประกาศการรองรับฟีเจอร์ของแพลตฟอร์ม android.software.app_widgets
  • [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและเปิดเผย ความสามารถของอินเทอร์เฟซผู้ใช้สำหรับการเพิ่ม กำหนดค่า ดู และนำ AppWidgets ออก ภายใน Launcher โดยตรง
  • [C-1-3] ต้องสามารถแสดงผลวิดเจ็ตขนาด 4 x 4 ในขนาดตารางกริดมาตรฐาน ดูหลักเกณฑ์การออกแบบวิดเจ็ตของแอป ในเอกสารประกอบของ Android SDK เพื่อดูรายละเอียด
  • อาจสนับสนุนวิดเจ็ตของแอปพลิเคชันบนหน้าจอล็อก

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

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

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

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

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

  • [C-1-1] ต้องรองรับการแจ้งเตือนที่ใช้ฟีเจอร์ของฮาร์ดแวร์ตามที่อธิบายไว้ใน เอกสารประกอบเกี่ยวกับ SDK และในขอบเขตที่เป็นไปได้สำหรับการใช้งานอุปกรณ์ ฮาร์ดแวร์ ตัวอย่างเช่น หากการติดตั้งอุปกรณ์มีเครื่องสั่นด้วย ก็ต้อง ใช้ API การสั่นอย่างถูกต้อง หากไม่มีการติดตั้งใช้งานอุปกรณ์ API ที่เกี่ยวข้องจะต้องใช้งานเป็นแบบไม่ต้องดำเนินการ ลักษณะการทำงานนี้ ดูรายละเอียดเพิ่มเติมในส่วนที่ 7
  • [C-1-2] ต้องแสดงผลทรัพยากรทั้งหมดอย่างถูกต้อง (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ที่มีให้ใน API หรือใน คู่มือรูปแบบไอคอนของแถบสถานะ/แถบระบบ แม้ส่วนขยายอาจนำเสนอประสบการณ์ของผู้ใช้ ในรูปแบบอื่นสำหรับการแจ้งเตือน มากกว่าที่ได้จากการใช้งานโอเพนซอร์ส Android อ้างอิง
  • [C-1-3] ต้องให้เกียรติและดำเนินการตามพฤติกรรมที่อธิบายไว้สำหรับ API เพื่ออัปเดต นำออก และการแจ้งเตือนกลุ่ม
  • [C-1-4] ต้องระบุลักษณะการทำงานทั้งหมดของ NotificationChannel API ที่บันทึกไว้ใน SDK
  • [C-1-5] ต้องเสนอค่าตอบแทนของผู้ใช้ในการบล็อกและแก้ไข การแจ้งเตือนของแอปของบุคคลที่สามในแต่ละช่องและระดับแพ็กเกจแอป
  • [C-1-6] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการแสดงการแจ้งเตือนที่ลบไปแล้ว แชแนล
  • [C-1-7] ต้องแสดงผลทรัพยากรทั้งหมดอย่างถูกต้อง (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่ให้บริการผ่าน Notification.MessagingStyle ข้างข้อความแจ้งเตือนโดยไม่มีการโต้ตอบเพิ่มเติมจากผู้ใช้ สำหรับ เช่น ต้องแสดงทรัพยากรทั้งหมด รวมถึงไอคอนที่จัดเตรียมให้ android.app.Person ในการสนทนากลุ่มที่ตั้งค่าไว้ผ่าน setGroupConversation
  • [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้แสดงค่าตอบแทนของผู้ใช้โดยอัตโนมัติ บล็อกการแจ้งเตือนของแอปบุคคลที่สามบางรายการสำหรับแต่ละช่องและแอป ระดับแพ็กเกจหลังจากที่ผู้ใช้ปิดการแจ้งเตือนดังกล่าวหลายครั้ง
  • [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้จ่ายเงินแก่ผู้ใช้ในการ ควบคุมการแจ้งเตือนที่แสดงต่อแอปที่ได้รับอนุญาต สิทธิ์ผู้ฟังการแจ้งเตือน รายละเอียดต้องเท่ากับว่า ผู้ใช้จะควบคุมการแจ้งเตือน ผู้ฟังการแจ้งเตือน แต่ละรายได้ จะเชื่อมเข้ากับ Listener นี้ ประเภทต้องมี "การสนทนา" "การแจ้งเตือน" "ปิดเสียง" และ "การดำเนินการที่สำคัญอย่างต่อเนื่อง" การแจ้งเตือน
  • [C-SR-3] ได้รับการแนะนำอย่างยิ่งให้มอบโอกาสแก่ผู้ใช้ในการ ระบุแอปที่จะยกเว้นไม่ให้แจ้งเตือนผู้ฟังการแจ้งเตือนที่เจาะจง
  • ควรรองรับการแจ้งเตือนที่สมบูรณ์
  • ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
  • ผู้ใช้ควรสามารถเลื่อนการแจ้งเตือน
  • อาจจัดการได้เฉพาะระดับการมองเห็นและช่วงเวลาที่แอปของบุคคลที่สามสามารถแจ้งเตือนได้เท่านั้น ผู้ใช้เหตุการณ์ที่โดดเด่นเพื่อลดปัญหาด้านความปลอดภัย เช่น สิ่งรบกวนผู้ขับขี่

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

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

  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้จัดกลุ่มและแสดงผล conversation notifications ก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้น การแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและ importance:high การแจ้งเตือน

หากการใช้งานอุปกรณ์รองรับ conversation notifications และแอปให้ข้อมูลที่จำเป็นสำหรับ bubbles พวกเขา:

  • [C-SR-5] แนะนำให้แสดงการสนทนานี้เป็นบับเบิล การติดตั้งใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้ด้วย UI เริ่มต้นของระบบ การตั้งค่าและ Launcher

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องแสดงสถานะการแจ้งเตือนที่เลื่อนการแจ้งเตือนอย่างถูกต้อง ผ่าน API มาตรฐาน เช่น NotificationListenerService.getSnoozedNotifications()
  • [C-1-2] ต้องทำให้ผู้ใช้รายนี้มีกำลังมากพอที่จะเลื่อนการแจ้งเตือน จากแอปพลิเคชันของบุคคลที่สามที่ติดตั้งแต่ละแอป เว้นแต่ว่าจะมาจาก บริการที่ทำงานอยู่เบื้องหน้า/ถาวร
3.8.3.3 DND (ห้ามรบกวน)

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

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

3.8.4 Assist API

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

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

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

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

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

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

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

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

3.8.6 ธีม

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

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

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

  • [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดง แอปพลิเคชัน
  • [C-1-2] ต้องรองรับกลุ่มธีม "วัสดุ" และต้องไม่ดัดแปลง แอตทริบิวต์ธีมวัสดุ หรือเนื้อหาที่เปิดเผยต่อแอปพลิเคชัน
  • [C-1-3] ต้องตั้งค่า "sans-serif" ชุดแบบอักษรเป็น Roboto เวอร์ชัน 2.x สำหรับภาษาต่างๆ ที่ Roboto รองรับ หรือมอบค่าตอบแทนของผู้ใช้ในการเปลี่ยนแบบอักษรที่ใช้ สำหรับ "sans-serif" ชุดแบบอักษรเป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ

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

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

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

  • [C-2-1] ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ความแรงของสัญญาณและ ระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบออกให้ ยกเว้นกรณีที่ไอคอน การแสดงสถานะที่เป็นปัญหาหรือแอปขอแถบสถานะไฟโดยใช้ WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS แจ้ง
  • [C-2-2] การใช้งานอุปกรณ์ Android ต้องเปลี่ยนสีของระบบ ไอคอนสถานะให้เป็นสีดำ (โปรดดูรายละเอียดใน R.style) เมื่อแอป ขอแถบสถานะไฟ

3.8.7 วอลเปเปอร์เคลื่อนไหว

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

ฮาร์ดแวร์ถือว่าสามารถเรียกใช้วอลเปเปอร์เคลื่อนไหวได้อย่างน่าเชื่อถือหากทำงานได้ วอลเปเปอร์เคลื่อนไหวทั้งหมดโดยไม่มีข้อจำกัดฟังก์ชันต่างๆ ในเฟรมที่เหมาะสม โดยไม่มีผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดใน ฮาร์ดแวร์ทำให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้ กำลัง CPU หรือแบตเตอรี่มากเกินไป หรือมีอัตราเฟรมต่ำ ซึ่งยอมรับไม่ได้ ฮาร์ดแวร์ถือว่าไม่สามารถใช้งานวอลเปเปอร์เคลื่อนไหวได้ ตัวอย่างเช่น วอลเปเปอร์เคลื่อนไหวอาจใช้บริบท OpenGL 2.0 หรือ 3.x ในการแสดงผลเนื้อหา วอลเปเปอร์เคลื่อนไหวจะไม่ทำงานอย่างเสถียรบนฮาร์ดแวร์ที่ไม่รองรับ บริบท OpenGL เนื่องจากการใช้วอลเปเปอร์เคลื่อนไหวของบริบท OpenGL อาจขัดแย้งกัน กับแอปพลิเคชันอื่นๆ ที่ใช้บริบท OpenGL เช่นกัน

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

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

  • [C-1-1] ต้องรายงานแฟล็กฟีเจอร์แพลตฟอร์ม android.software.live_wallpaper

3.8.8 การสลับกิจกรรม

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

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

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

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

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

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

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

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

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

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

3.8.11 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)

ดูการตั้งค่าในส่วนที่ 3.2.3.5 ในการกำหนดเป้าหมายโปรแกรมรักษาหน้าจอ

3.8.12 ตำแหน่ง

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ฮาร์ดแวร์ (เช่น GPS) ที่สามารถ ในการให้พิกัดตำแหน่ง

3.8.13 Unicode และแบบอักษร

Android รองรับอักขระอีโมจิที่กำหนดไว้ใน Unicode 10.0

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

  • [C-1-1] ต้องแสดงภาพอักขระอีโมจิเหล่านี้เป็นรูปอักขระสีได้
  • [C-1-2] ต้องมีการสนับสนุนสำหรับ:
    • แบบอักษร Roboto 2 ที่มีน้ำหนักต่างกัน เช่น sans-serif-thin, sans-serif-light sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light สำหรับภาษาที่พร้อมใช้งานในอุปกรณ์
    • ครอบคลุม Unicode 7.0 แบบสมบูรณ์ในละติน กรีก และซีริลลิก รวมถึง ภาษาละติน Extended A, B, C และ D และรูปอักขระทั้งหมดในสกุลเงิน บล็อกสัญลักษณ์ของ Unicode 7.0
  • [C-1-3] ต้องไม่นำออกหรือแก้ไข NotoColorEmoji.tff ในอิมเมจระบบ (คุณสามารถเพิ่มแบบอักษรอีโมจิใหม่เพื่อแทนที่อีโมจิใน NotoColorEmoji.tff)
  • ควรรองรับสีผิวและอีโมจิที่หลากหลายสำหรับครอบครัวตามที่ระบุไว้ใน รายงานทางเทคนิคของ Unicode #51

หากอุปกรณ์มี IME รวมอยู่ด้วย ระบบจะดำเนินการดังนี้

  • ควรระบุวิธีการป้อนข้อมูลสำหรับอักขระอีโมจิเหล่านี้ให้แก่ผู้ใช้

Android รองรับการแสดงผลแบบอักษรภาษาเมียนมา เมียนมามี แบบอักษรที่ไม่ปฏิบัติตาม Unicode หรือที่รู้จักกันโดยทั่วไปว่า "Zawgyi" สำหรับการแสดงผลเมียนมา ภาษา

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

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

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

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

  • [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตาม การทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ใน Android SDK เอกสารสนับสนุนโหมดหลายหน้าต่าง และ Meet ข้อกำหนดต่อไปนี้
  • [C-1-2] ต้องทำตาม android:resizeableActivity ที่กำหนดโดยแอปในไฟล์ AndroidManifest.xml ตามที่อธิบายไว้ใน SDK นี้
  • [C-1-3] ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดอิสระ ความสูงหน้าจอน้อยกว่า 440 dp และความกว้างหน้าจอน้อยกว่า 440 dp
  • [C-1-4] ต้องไม่ปรับขนาดกิจกรรมให้มีขนาดเล็กกว่า 220dp โหมดหลายหน้าต่างนอกเหนือจากการแสดงภาพซ้อนภาพ
  • การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ xlarge ควรรองรับรูปแบบอิสระ

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

  • [C-2-2] ต้องครอบตัดกิจกรรมที่อยู่บนแท่นชาร์จของโหมดแยกหน้าจอหลายหน้าต่าง แต่ ควรแสดงเนื้อหาบางส่วน หากแอป Launcher เป็นหน้าต่างที่โฟกัสอยู่
  • [C-2-3] ต้องปฏิบัติตาม AndroidManifestLayout_minWidth ที่ประกาศไว้ และ AndroidManifestLayout_minHeight ของแอปพลิเคชันตัวเรียกใช้งานของบุคคลที่สาม และไม่แทนที่ค่าเหล่านี้ ในการแสดงเนื้อหา ของกิจกรรมบนแท่นชาร์จ

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

  • [C-3-1] ต้องเปิดกิจกรรมในโหมดหลายหน้าต่างแบบการแสดงภาพซ้อนภาพ เมื่อแอป

  • [C-3-2] ต้องแสดงการดำเนินการใน SystemUI เป็น ที่ระบุโดยกิจกรรม PIP ปัจจุบันผ่าน setActions() API

  • [C-3-3] ต้องรองรับสัดส่วนภาพที่มากกว่าหรือเท่ากับ 1:2.39 และน้อยกว่าหรือเท่ากับ 2.39:1 ตามที่ระบุโดยกิจกรรม PIP ผ่าน setAspectRatio() API

  • [C-3-4] ต้องใช้ KeyEvent.KEYCODE_WINDOW เพื่อควบคุมหน้าต่าง PIP หากไม่ได้ใช้โหมด PIP คีย์ต้องเป็น ในกิจกรรมเบื้องหน้า

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

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

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

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

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

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

  • [C-1-5] ต้องไม่มีรอยบากหากสัดส่วนภาพของอุปกรณ์คือ 1.0(1:1)
  • [C-1-2] ต้องไม่มีคัตเอาต์มากกว่า 1 คัตเอาต์ต่อขอบ
  • [C-1-3] ต้องปฏิบัติตามแฟล็กหน้าจอรอยบากที่แอปกำหนดผ่าน WindowManager.LayoutParams API ตามที่อธิบายไว้ใน SDK
  • [C-1-4] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกคัตเอาต์ทั้งหมดที่กำหนดไว้ในฟิลด์ DisplayCutout API

3.8.16 ระบบควบคุมอุปกรณ์

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

โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2_2_3

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

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

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

  • [C-1-1] ต้องประกาศ android.software.device_admin
  • [C-1-2] ต้องรองรับการจัดสรรเจ้าของอุปกรณ์ตามที่อธิบายไว้ใน ส่วนที่ 3.9.1 และ ส่วน 3.9.1.1

3.9.1 การจัดสรรอุปกรณ์

3.9.1.1 การจัดสรรเจ้าของอุปกรณ์

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

  • [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์ Device Policy (DPC) เป็น แอปของเจ้าของอุปกรณ์ ตามที่อธิบายไว้ด้านล่าง
    • เมื่อติดตั้งอุปกรณ์โดยยังไม่มีการกําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
      • [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์หาก อุปกรณ์ประกาศว่ารองรับ Near Field Communications (NFC) ผ่านฟีเจอร์นี้ ตั้งค่าสถานะ android.hardware.nfc และรับข้อความ NFC ที่มี ระเบียนที่มีประเภท MIME MIME_TYPE_PROVISIONING_NFC
      • [C-1-8] ต้องส่ง ACTION_GET_PROVISIONING_mode Intent หลังมีการเรียกใช้การจัดสรรเจ้าของอุปกรณ์ เพื่อให้ แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือโปรไฟล์ เจ้าของ เว้นแต่จะระบุได้จากบริบทว่ามี ตัวเลือกที่ใช้ได้หนึ่งตัวเลือก (เช่น สำหรับการจัดสรรแบบ NFC โดยที่โปรไฟล์ ไม่รองรับการจัดสรรเจ้าของ)
      • [C-1-9] ต้องส่ง ACTION_ADMIN_POLICY_COMPLIANCE Intent ไปยังแอปเจ้าของอุปกรณ์ หากมีการสร้างเจ้าของอุปกรณ์แล้ว ในระหว่างการจัดสรรโดยไม่คำนึงถึงวิธีการจัดสรร ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าจะ แอปของเจ้าของอุปกรณ์ทำงานให้เสร็จสิ้น
    • เมื่อติดตั้งอุปกรณ์มีข้อมูลผู้ใช้ จะดำเนินการดังนี้
      • [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ และอื่นๆ อีกมากมาย
  • [C-1-2] ต้องมีการดำเนินการยืนยันบางอย่างก่อนหรือระหว่าง กระบวนการจัดสรรเพื่อยินยอมให้มีการตั้งค่าแอปเป็นเจ้าของอุปกรณ์ ความยินยอมอาจผ่านการดำเนินการของผู้ใช้หรือวิธีการทางโปรแกรมบางอย่างก็ได้ แต่ก็เหมาะสม ประกาศการเปิดเผยข้อมูล (ดังที่กล่าวถึงใน AOSP) จะต้องแสดงก่อนเจ้าของอุปกรณ์ เริ่มการจัดสรรแล้ว รวมถึงความยินยอมของเจ้าของอุปกรณ์แบบเป็นโปรแกรม กลไกที่ใช้ (โดยองค์กร) สำหรับการจัดสรรเจ้าของอุปกรณ์ต้องไม่ รบกวนการใช้งานนอกกล่องสำหรับการใช้งานที่ไม่ใช่ขององค์กร
  • [C-1-3] ต้องไม่ฮาร์ดโค้ดความยินยอมหรือป้องกันการใช้อุปกรณ์อื่น แอปของเจ้าของ

หากการใช้งานอุปกรณ์ประกาศ android.software.device_admin แต่ มีโซลูชันการจัดการเจ้าของอุปกรณ์ที่เป็นกรรมสิทธิ์และมีกลไก เพื่อโปรโมตแอปพลิเคชันที่กำหนดค่าในโซลูชันเป็น "เจ้าของอุปกรณ์ เทียบเท่า" "เจ้าของอุปกรณ์" แบบมาตรฐาน ที่รู้จักโดย Android มาตรฐาน ตัวจัดการนโยบายด้านอุปกรณ์ API เหล่านี้มีคุณสมบัติดังนี้

  • [C-2-1] ต้องมีขั้นตอนยืนยันว่าแอปที่ระบุ ได้รับการโปรโมตอยู่ในการจัดการอุปกรณ์ขององค์กรที่ถูกต้องตามกฎหมาย และกำหนดค่าไว้ในโซลูชันที่เป็นกรรมสิทธิ์แล้ว เพื่อรับสิทธิ์เทียบเท่ากับ "เจ้าของอุปกรณ์"
  • [C-2-2] ต้องแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับ การดำเนินการโดย android.app.action.PROVISION_MANAGED_DEVICE ก่อนลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์"
  • อาจมีข้อมูลผู้ใช้อยู่ในอุปกรณ์ก่อนลงทะเบียนแอปพลิเคชัน DPC ว่า "เจ้าของอุปกรณ์"
3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ

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

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

  • [C-1-2] กระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (ขั้นตอนที่เริ่มต้นโดย DPC โดยใช้ android.app.action.PROVISION_MANAGED_PROFILE) หรือตามแพลตฟอร์ม) หน้าจอขอความยินยอมและประสบการณ์ของผู้ใช้ต้องสอดคล้องกับ การนำ AOSP มาใช้

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

    • ไอคอนที่สม่ำเสมอหรืออัตราราคาอื่นๆ ของผู้ใช้ (เช่น อัปสตรีม) ไอคอนข้อมูล AOSP) เพื่อแสดงเมื่อการตั้งค่าบางอย่างถูกจำกัดโดย ผู้ดูแลระบบอุปกรณ์
    • ข้อความอธิบายสั้นๆ ตามที่ผู้ดูแลระบบอุปกรณ์ระบุไว้ผ่าน setShortSupportMessage
    • ไอคอนของแอปพลิเคชัน DPC
  • [C-1-4] ต้องเปิดเครื่องจัดการสำหรับ ACTION_PROVISIONING_SUCCESSFUL ในโปรไฟล์งาน หากสร้างเจ้าของโปรไฟล์เมื่อ การจัดสรรเริ่มต้นโดย android.app.action.PROVISION_MANAGED_PROFILE และ DPC ได้ติดตั้งใช้งานเครื่องจัดการแล้ว

  • [C-1-5] ต้องส่ง ACTION_PROFILE_PROVISIONING_COMPLETE ประกาศไปยัง DPC ของโปรไฟล์งานเมื่อเริ่มต้นการจัดสรรโดย android.app.action.PROVISION_MANAGED_PROFILE Intent

  • [C-1-6] ต้องส่ง ACTION_GET_PROVISIONING_mode Intent หลังจากมีการเรียกใช้การจัดสรรเจ้าของโปรไฟล์เพื่อให้แอป DPC สามารถเลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือผู้บริหารเจ้าของโปรไฟล์เมื่อ การจัดสรรจะทริกเกอร์โดย Intent android.app.action.PROVISION_MANAGED_PROFILE

  • [C-1-7] ต้องส่ง ACTION_ADMIN_POLICY_COMPLIANCE ข้อมูลในโปรไฟล์งานเมื่อมีการสร้างเจ้าของโปรไฟล์ระหว่าง การจัดสรร โดยไม่คำนึงว่าจะใช้วิธีการจัดสรรใดก็ตาม เมื่อ Intent android.app.action.PROVISION_MANAGED_PROFILE ทริกเกอร์การจัดสรร ผู้ใช้ต้องไม่สามารถดำเนินการในวิซาร์ดการตั้งค่าได้จนกว่าจะ ใช้งานแอปของเจ้าของเสร็จแล้ว

  • [C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ประกาศไปยัง DPC ของโปรไฟล์ส่วนตัวเมื่อสร้างเจ้าของโปรไฟล์แล้ว ไม่ว่าจะใช้วิธีการจัดสรรแบบใดก็ตาม

3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.13 การตั้งค่าด่วน

Android มีคอมโพเนนต์ UI การตั้งค่าด่วนที่ช่วยให้เข้าถึง การดำเนินการที่ใช้บ่อยหรือที่จำเป็นอย่างเร่งด่วน

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

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

3.14 UI สื่อ

หากการใช้งานอุปกรณ์มีแอปพลิเคชันที่ไม่ได้เปิดใช้งานด้วยเสียง (แอป) ซึ่งโต้ตอบกับ แอปพลิเคชันของบุคคลที่สามผ่าน MediaBrowser หรือ MediaSession แอป

  • [C-1-2] ต้องแสดงไอคอนที่ได้รับผ่านทาง getIconBitmap() หรือ getIconUri() และชื่ออย่างชัดเจน ได้รับผ่านทาง getTitle() ตามที่อธิบายไว้ใน MediaDescription อาจย่อชื่อเพื่อให้สอดคล้องกับกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนผู้ขับขี่)

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

  • [C-1-4] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับ MediaBrowser ทั้งหมด ลำดับชั้น อาจจำกัดการเข้าถึงในบางลำดับชั้นเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนผู้ขับขี่) แต่ต้องไม่ให้การดูแลเป็นพิเศษตามเนื้อหาหรือ Content Provider

  • [C-1-5] ต้องแตะ 2 ครั้ง KEYCODE_HEADSETHOOK หรือ KEYCODE_MEDIA_PLAY_PAUSE ด้วย KEYCODE_MEDIA_NEXT สำหรับ MediaSession.Callback#onMediaButtonEvent

3.15 Instant Apps

หากอุปกรณ์รองรับ Instant Apps แอปจะต้องเป็นไปตามเงื่อนไขต่อไปนี้ ข้อกำหนด

  • [C-1-1] Instant Apps ต้องได้รับสิทธิ์ที่มี android:protectionLevel ตั้งค่าเป็น "instant"
  • [C-1-2] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งผ่าน implicit Intent ยกเว้นในกรณีต่อไปนี้
    • แสดงตัวกรองรูปแบบ Intent ของคอมโพเนนต์และมี CATEGORY_BROWSABLE
    • การกระทำนี้เป็นหนึ่งใน ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • เป้าหมายจะปรากฏอย่างชัดเจนด้วย android:visibleToInstantApps
  • [C-1-3] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งอย่างชัดเจน เว้นแต่ คอมโพเนนต์ถูกเปิดเผยผ่าน android:visibleToInstantApps
  • [C-1-4] แอปที่ติดตั้งต้องไม่ดูรายละเอียดเกี่ยวกับ Instant Apps บน ยกเว้นในกรณีที่ Instant App เชื่อมต่อกับ ติดตั้งแอปพลิเคชันแล้ว
  • การติดตั้งใช้งานอุปกรณ์ต้องให้เงินช่วยเหลือต่อไปนี้แก่ผู้ใช้ ที่โต้ตอบกับ Instant Apps ได้ AOSP มีคุณสมบัติตามข้อกำหนดเกี่ยวกับ UI, การตั้งค่า และ Launcher เริ่มต้นของระบบ การติดตั้งใช้งานอุปกรณ์

    • [C-1-5] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการดูและลบ Instant Apps แคชในเครื่องสำหรับแพ็กเกจแอปแต่ละรายการ
    • [C-1-6] ต้องระบุการแจ้งเตือนสำหรับผู้ใช้อย่างต่อเนื่องที่สามารถ ยุบในขณะที่ Instant App ทำงานอยู่ในเบื้องหน้า ผู้ใช้รายนี้ การแจ้งเตือนต้องระบุว่า Instant Apps ไม่ต้องใช้การติดตั้ง และให้ค่าตอบแทนแก่ผู้ใช้ที่จะนำผู้ใช้ไปยังแอปพลิเคชัน ในหน้าจอ "การตั้งค่า" สำหรับ Instant Apps ที่เปิดตัวผ่านเว็บ Intent กำหนดโดยใช้ Intent ที่มีชุดการดำเนินการเป็น Intent.ACTION_VIEW และ ด้วยรูปแบบ "http" หรือ "https" ซึ่งเป็นค่าใช้จ่ายสำหรับผู้ใช้เพิ่มเติม ควรอนุญาตให้ผู้ใช้เปิด Instant App และ ให้เปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กำหนดค่าไว้ หากเบราว์เซอร์ ในอุปกรณ์
    • [C-1-7] ต้องอนุญาตให้เรียกใช้ Instant App จากรายการล่าสุด หากมีฟังก์ชัน "ล่าสุด" ในอุปกรณ์
  • [C-1-8] ต้องโหลดแอปพลิเคชันหรือองค์ประกอบบริการล่วงหน้าอย่างน้อย 1 รายการ ด้วยเครื่องจัดการ Intent สำหรับ Intent ที่แสดงอยู่ใน SDK ที่นี่ และแสดง Intent ของ Instant Apps ได้

3.16 การจับคู่อุปกรณ์ที่ใช้ร่วมกัน

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

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

  • [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ FEATURE_COMPANION_DEVICE_SETUP ที่ใช้เวลาเพียง 2 นาที
  • [C-1-2] ต้องตรวจสอบให้แน่ใจว่า API ในandroid.companion เสร็จสมบูรณ์
  • [C-1-3] ต้องให้ข้อมูลสำหรับผู้ใช้ในการเลือก/ยืนยันโฆษณาที่แสดงร่วม อุปกรณ์ทำงานและใช้งานได้

3.17. แอปขนาดใหญ่

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE ให้ดำเนินการดังนี้

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

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

  • [C-1-1] ต้องละเว้น cantSaveState ที่แอปและต้องไม่เปลี่ยนลักษณะการทำงานของแอปตามนั้น

3.18 รายชื่อติดต่อ

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

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

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

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

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

  • [C-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าสร้างบัญชีในพื้นที่ที่กำหนดเอง

หากการใช้อุปกรณ์ใช้บัญชีในเครื่องที่กำหนดเอง ให้ทำดังนี้

  • [C-1-1] ACCOUNT_NAME ของบัญชีท้องถิ่นที่กำหนดเองต้องส่งคืนโดย ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] ACCOUNT_TYPE ของบัญชีท้องถิ่นที่กำหนดเองต้องส่งคืนโดย ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] รายชื่อติดต่อดิบที่แทรกโดยแอปพลิเคชันของบุคคลที่สามที่มี บัญชีภายในที่เป็นค่าเริ่มต้น (กล่าวคือ ด้วยการกำหนดค่า Null สำหรับ ACCOUNT_NAME และ ACCOUNT_TYPE) ต้องแทรกลงในท้องถิ่นที่กำหนดเอง บัญชี
  • [C-1-4] รายชื่อติดต่อดิบที่แทรกลงในบัญชีในเครื่องที่กำหนดเองต้องไม่ นำออกเมื่อมีการเพิ่มหรือนำบัญชีออก
  • [C-1-5] การลบดำเนินการในบัญชีในเครื่องที่กำหนดเอง ต้องทำให้ รายชื่อติดต่อดิบ ถูกล้างทันที (เหมือนกับว่า CALLER_IS_SYNCADAPTER param เป็น true) แม้ว่าจะตั้งค่าพารามิเตอร์ CALLER\_IS\_SYNCADAPTER แล้ว เป็นเท็จหรือไม่ได้ระบุ

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

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

  • [C-0-1] ต้องสามารถติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ในรูปแบบ โดยใช้เครื่องมือ “aapt” ที่มีอยู่ใน Android SDK อย่างเป็นทางการ
    • ตามข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย การติดตั้งใช้งานอุปกรณ์ แนะนำให้ใช้การจัดการแพ็กเกจของการใช้งานข้อมูลอ้างอิง AOSP ระบบ

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

  • [C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v3 , APK Signature Scheme v2 และการลงชื่อ JAR
  • [C-0-3] ต้องไม่ขยาย .apk Android Manifest Dalvik Bycode หรือ รูปแบบไบต์โค้ดของ RenderScript ในลักษณะที่จะป้องกันไม่ให้ไฟล์เหล่านั้น ติดตั้งและทำงานอย่างถูกต้องบนอุปกรณ์อื่นๆ ที่เข้ากันได้
  • [C-0-4] ต้องไม่อนุญาตแอปอื่นนอกเหนือจากแอปปัจจุบัน "โปรแกรมติดตั้งระเบียน" แพ็กเกจสามารถถอนการติดตั้งแอปโดยไม่ต้อง การยืนยันผู้ใช้ตามที่ระบุไว้ใน SDK สำหรับ DELETE_PACKAGE สิทธิ์ ข้อยกเว้นเพียงรายการเดียวคือการจัดการแอปของเครื่องมือยืนยันแพ็กเกจของระบบ PACKAGE_NEEDS_VERIFICATION Intent และแอปตัวจัดการพื้นที่เก็บข้อมูลที่รองรับ ACTION_MANAGE_STORAGE Intent

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

  • [C-0-6] ต้องไม่ติดตั้งแพ็กเกจแอปพลิเคชันจาก ยกเว้นแอปที่ขอการติดตั้ง มีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้ทั้งหมด

    • ต้องประกาศ REQUEST_INSTALL_PACKAGES หรือตั้งค่า android:targetSdkVersion เป็น 24 หรือต่ำกว่า
    • แอปต้องได้รับอนุญาตจากผู้ใช้ แหล่งที่มาที่ไม่รู้จัก
  • ควรให้ค่าตอบแทนแก่ผู้ใช้ในการให้สิทธิ์/เพิกถอนการให้สิทธิ์ ติดตั้งแอปพลิเคชันจากแหล่งที่มาที่ไม่รู้จักต่อแอปพลิเคชัน แต่อาจเลือกใช้ได้ รายการนี้เป็นแบบไม่มีการดำเนินการและแสดงผล RESULT_CANCELED สำหรับ startActivityForResult() หากการใช้อุปกรณ์ไม่ต้องการให้ผู้ใช้มีตัวเลือกนี้ อย่างไรก็ตาม ในกรณีเหล่านี้ ควรระบุให้ผู้ใช้ทราบว่าไม่มี เสนอทางเลือกดังกล่าว

  • [C-0-7] ต้องแสดงกล่องคำเตือนพร้อมสตริงคำเตือนที่ ระบุผ่าน API ระบบ PackageManager.setHarmfulAppWarning กับผู้ใช้ก่อนที่จะเปิดกิจกรรมในแอปพลิเคชันที่มีการทำเครื่องหมายว่า โดย API ระบบเดียวกันกับ PackageManager.setHarmfulAppWarning เป็นอันตราย

  • ควรเสนอทางเลือกแก่ผู้ใช้ในการเลือกที่จะถอนการติดตั้งหรือเปิดตัว บนกล่องโต้ตอบคำเตือน

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

  • [C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4

5. ความเข้ากันได้กับมัลติมีเดีย

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

  • [C-0-1] ต้องรองรับรูปแบบสื่อ โปรแกรมเปลี่ยนไฟล์ โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในส่วนที่ 5.1 สำหรับตัวแปลงรหัสแต่ละตัวและทุกๆ ตัวแปลงรหัสที่ประกาศโดย MediaCodecList
  • [C-0-2] ต้องประกาศและรายงานการรองรับโปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสที่มี ไปยังแอปพลิเคชันของบุคคลที่สามผ่าน MediaCodecList
  • [C-0-3] ต้องสามารถถอดรหัสและเปิดเผยต่อบุคคลที่สามได้อย่างเหมาะสม ทุกรูปแบบที่สามารถเข้ารหัสได้ ซึ่งรวมถึงบิตสตรีมทั้งหมดที่ โปรแกรมเปลี่ยนไฟล์จะสร้างและโปรไฟล์ที่รายงานในไฟล์ CamcorderProfile

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

  • ควรใช้เวลาในการตอบสนองของตัวแปลงรหัสขั้นต่ำ
    • ไม่ควรใช้และจัดเก็บบัฟเฟอร์อินพุต รวมถึงแสดงผลบัฟเฟอร์อินพุตเท่านั้น เมื่อประมวลผลแล้ว
    • ไม่ควรเก็บบัฟเฟอร์ที่ถอดรหัสแล้วไว้นานกว่าที่ มาตรฐาน (เช่น SPS)
    • ไม่ควรเก็บบัฟเฟอร์ที่เข้ารหัสไว้นานกว่าที่ GOP กำหนด ใหม่

ตัวแปลงรหัสทั้งหมดที่ระบุในส่วนด้านล่างเป็นซอฟต์แวร์ ในการใช้งาน Android ที่แนะนำ จาก Android Open โปรเจ็กต์ต้นทาง

โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้ให้ เพื่อแสดงให้เห็นว่าตัวแปลงรหัสเหล่านี้ไม่มีสิทธิบัตรของบุคคลที่สาม เหล่านั้น หากตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ การติดตั้งโค้ดนี้ ซึ่งรวมถึงในซอฟต์แวร์โอเพนซอร์สหรือ แชร์แวร์ อาจต้องมีใบอนุญาตสิทธิบัตรจากผู้ถือสิทธิบัตรที่เกี่ยวข้อง

5.1 ตัวแปลงสัญญาณสื่อ

5.1.1 การเข้ารหัสเสียง

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

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

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] โอปัส

โปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดต้องสนับสนุนรายการต่อไปนี้

  • [C-3-1] เฟรมเสียงสำหรับสั่งซื้อไบต์ดั้งเดิมของ PCM 16 บิตผ่าน android.media.MediaCodec API

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

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

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

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

หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC สตรีมแบบหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านค่าเริ่มต้น โปรแกรมถอดรหัสเสียง AAC ใน android.media.MediaCodec API ต้องมีสิ่งต่อไปนี้ รองรับ

  • [C-2-1] ต้องถอดรหัสโดยไม่ต้องลงมิกซ์ (เช่น 5.0 AAC ต้องถอดรหัสสตรีมเป็น PCM 5 ช่อง และต้องถอดรหัสสตรีม 5.1 AAC เป็น 6 ช่องสัญญาณของ PCM)
  • [C-2-2] ข้อมูลเมตาของช่วงไดนามิกต้องระบุไว้ใน "การควบคุมช่วงไดนามิก" (DRC)" ใน ISO/IEC 14496-3 และคีย์ DRC android.media.MediaFormat เพื่อ กำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของเครื่องมือถอดรหัสเสียง คีย์ AAC DRC เปิดตัวใน API 21 และมีคุณสมบัติดังนี้ KEY_AAC_DRC_ATTENUATION_FACTOR KEY_AAC_DRC_BOOST_FACTOR KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_ENCODED_TARGET_LEVEL
  • [SR-1] ขอแนะนำเป็นอย่างยิ่งว่าข้อกำหนด C-2-1 และ C-2-2 ข้างต้นนั้น ของผู้ถอดรหัสเสียง AAC ทั้งหมด

เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)

  • [C-3-1] ต้องตีความและนำไปใช้ความดังและข้อมูลเมตาของ DRC ตามที่ระบุใน MPEG-D DRC Dynamic Range Control Profile Level 1
  • [C-3-2] ตัวถอดรหัสต้องทำงานตามการกำหนดค่า ตั้งค่าด้วยคีย์ android.media.MediaFormat ต่อไปนี้ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_DRC_EFFECT_TYPE

ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2:

  • อาจรองรับความดังและการควบคุมช่วงไดนามิกโดยใช้ ISO/IEC 23003-4 โปรไฟล์การควบคุมช่วงไดนามิก

รองรับ ISO/IEC 23003-4 และรองรับทั้ง ISO/IEC 23003-4 และ ข้อมูลเมตา ISO/IEC 14496-3 แสดงอยู่ในบิตสตรีมที่ถอดรหัสแล้ว จากนั้น

  • ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสำคัญเหนือกว่า

ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุต:

  • [C-6-1] เฟรมเสียงสำหรับสั่งซื้อไบต์เนทีฟแบบ PCM 16 บิตผ่าน android.media.MediaCodec API

5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง

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

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

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

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

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

หากการใช้งานอุปกรณ์รองรับการเข้ารหัส HEIC ผ่าน android.media.MediaCodec สำหรับประเภทสื่อ MIMETYPE_IMAGE_ANDROID_HEIC ดังนี้

  • [C-1-1] ต้องระบุตัวแปลงรหัส HEVC ที่ใช้ฮาร์ดแวร์เร่งการแสดงผล ซึ่ง รองรับ BITRATE_MODE_CQ โหมดควบคุมอัตราบิต HEVCProfileMainStill และเฟรมขนาด 512 x 512 พิกเซลได้

5.1.5 การถอดรหัสรูปภาพ

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

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

  • [C-0-1] JPEG
  • GIF [C-0-2]
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] ดิบ

หากการใช้งานอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC การดำเนินการต่อไปนี้

  • [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)

ตัวถอดรหัสรูปภาพที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง):

  • [C-2-1] ต้องรองรับเอาต์พุตรูปแบบ 8 บิตที่เทียบเท่ากันหากได้รับคำขอจาก แอปพลิเคชัน เช่น ผ่าน ARGB_8888 การกำหนดค่าของ android.graphics.Bitmap

5.1.6 รายละเอียดตัวแปลงรหัสภาพ

รูปแบบ/ตัวแปลงรหัส รายละเอียด รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG ฐาน +โพรเกรสซีฟ JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
แบบข้อมูลดิบ ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf) PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ HEIF (.heif), HEIC (.heic)

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

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

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

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

5.1.7 ตัวแปลงรหัสวิดีโอ

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

หากการใช้งานอุปกรณ์มีตัวถอดรหัสวิดีโอหรือโปรแกรมเปลี่ยนไฟล์

  • [C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดเอาต์พุตและไบต์บัฟเฟอร์อินพุตที่ รองรับเฟรมที่บีบอัดและไม่บีบอัดขนาดใหญ่ที่สุดเท่าที่จะทำได้ ตามมาตรฐานและการกำหนดค่า แต่ก็ไม่ใช่ภาพรวม

  • [C-1-2] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับสีที่ปรับเปลี่ยนได้ YUV420 8:8:8 รูปแบบ (COLOR_FormatYUV420Flexible) จนถึง CodecCapabilities

  • [C-1-3] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับระนาบหรือ รูปแบบสี YUV420 8:8:8 แบบเซมิแพลน: COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) เราขอแนะนำเป็นอย่างยิ่งให้สนับสนุนทั้ง 2 อย่างนี้

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

  • [C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง) ต้องรองรับเอาต์พุตรูปแบบ 8 บิตที่เทียบเท่ากัน ตามที่แอปพลิเคชันขอ สิ่งนี้ต้องสะท้อนให้เห็นโดยการสนับสนุน YUV420 รูปแบบสี 8:8:8 ผ่าน android.media.MediaCodecInfo

การนำอุปกรณ์ไปใช้งานจะโฆษณาการรองรับโปรไฟล์ HDR ผ่านทาง Display.HdrCapabilities ดังนี้

  • [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ HDR

หากมีการติดตั้งใช้งานอุปกรณ์ ระบบจะโฆษณาการสนับสนุนการรีเฟรชภายในผ่าน FEATURE_IntraRefresh ในMediaCodecInfo.CodecCapabilities ได้

  • [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10 - 60 เฟรมและ ทำงานได้อย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้

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

  • [C-4-1] ต้องมีค่าเริ่มต้นเป็นรูปแบบสีที่เหมาะกับการแสดงผลด้วยฮาร์ดแวร์ หากกำหนดค่าโดยใช้เอาต์พุต Surface
  • [C-4-2] ต้องมีค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพสำหรับ CPU อ่านค่าหากมีการกำหนดค่าไว้ไม่ให้ใช้เอาต์พุต Surface

5.1.8 รายการตัวแปลงรหัสวิดีโอ

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
H.264 AVC ดูส่วนที่ 5.2 และ 5.3 สำหรับรายละเอียด
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, ไม่สามารถค้นหาได้)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
HEVC ของ H.265 ดูรายละเอียดในส่วนที่ 5.3
  • MPEG-4 (.mp4)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-2 โปรไฟล์หลัก
  • MPEG2-TS (.ts, ไม่สามารถค้นหาได้)
  • MPEG-4 (.mp4, ถอดรหัสเท่านั้น)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
VP8 โปรดดูส่วนที่ 5.2 และ 5.3 สำหรับรายละเอียด
VP9 ดูรายละเอียดในส่วนที่ 5.3

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

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

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

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

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

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

  • [C-2-1] ต้องรวมตัวแปลงรหัสซอฟต์แวร์ OMX ที่สอดคล้องกันจาก Android โปรเจ็กต์โอเพนซอร์ส (หากมี) สำหรับรูปแบบและสื่อแต่ละประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
  • [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องอิงตาม เกี่ยวกับซอร์สโค้ดของโครงการโอเพนซอร์ส Android
  • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งว่าตัวแปลงรหัสซอฟต์แวร์ OMX จะทำงานในตัวแปลงรหัส กระบวนการที่ไม่สามารถเข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากนักทำแผนที่หน่วยความจำ

หากอุปกรณ์รองรับตัวแปลงรหัสตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้

  • [C-3-1] ต้องรวมตัวแปลงรหัสของซอฟต์แวร์ Codec 2.0 ที่สอดคล้องกันจาก โปรเจ็กต์โอเพนซอร์ส Android (หากมี) สำหรับสื่อแต่ละรูปแบบและประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
  • [C-3-2] ต้องเก็บตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ไว้ในตัวแปลงรหัสของซอฟต์แวร์ ตามที่กำหนดไว้ในโครงการโอเพนซอร์ส Android เพื่อทำให้ เพื่อให้สิทธิ์เข้าถึงตัวแปลงรหัสซอฟต์แวร์ในวงแคบ
  • [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android" ต้องอิงตาม เกี่ยวกับซอร์สโค้ดของโครงการโอเพนซอร์ส Android

5.1.10 การจำแนกลักษณะของตัวแปลงรหัสสื่อ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ ตัวแปลงสัญญาณต่อไปนี้

  • [C-1-1] ต้องส่งคืนค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่านทาง MediaCodecInfo API

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

  • [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของ OMX IL
  • [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ตัวแปลงรหัส 2.0 API และ มีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของตัวแปลงรหัส 2.0 สำหรับ Android
  • [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" หรือ "c2.android" ต้อง ไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นการเร่งฮาร์ดแวร์
  • [C-1-5] ตัวแปลงรหัสที่ทำงานในกระบวนการของตัวแปลงรหัส (ผู้ให้บริการหรือระบบ) ที่มี การเข้าถึงไดรเวอร์ฮาร์ดแวร์อื่นๆ นอกเหนือจากเครื่องมือจัดสรรหน่วยความจำและผู้ทำแผนที่ต้อง มีลักษณะเป็นซอฟต์แวร์เท่านั้น
  • [C-1-6] ตัวแปลงรหัสไม่มีอยู่ในโครงการโอเพนซอร์ส Android หรือไม่ได้อ้างอิง ในซอร์สโค้ดในโปรเจ็กต์นั้นต้องอยู่ในรูปแบบผู้ให้บริการ
  • [C-1-7] ตัวแปลงรหัสที่ใช้การเร่งฮาร์ดแวร์จะต้องมีลักษณะพิเศษ เป็นการเร่งฮาร์ดแวร์
  • [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด ตัวอย่างเช่น ตัวแปลงรหัสที่ชื่อ "ตัวถอดรหัส" ต้องรองรับการถอดรหัส และโปรแกรมที่ชื่อ "โปรแกรมเปลี่ยนไฟล์" ต้องรองรับ การเข้ารหัส ตัวแปลงรหัสที่มีชื่อที่มีรูปแบบสื่อต้องรองรับ

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

  • [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้ ขนาดต่อไปนี้หากตัวแปลงรหัสสนับสนุน:
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ
  • 176 x 144 พิกเซล (H263, MPEG2, MPEG4)
  • 352 x 288 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4, H263, MPEG2)
  • 320 x 180 พิกเซล (VP8, VP8)
  • 320 x 240 พิกเซล (อื่นๆ)
  • 704 x 576 พิกเซล (H263)
  • 640 x 360 พิกเซล (VP8, VP9)
  • 640 x 480 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4)
  • 720 x 480 พิกเซล (อื่นๆ)
  • 1408 x 1152 พิกเซล (H263)
  • 1280 x 720 พิกเซล (อื่นๆ)
1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4) 3840 x 2160 พิกเซล (HEVC, VP9)
  • [C-2-2] ตัวแปลงรหัสวิดีโอที่มีลักษณะเป็นการเร่งความเร็วด้วยฮาร์ดแวร์ต้อง เผยแพร่ข้อมูลคะแนนประสิทธิภาพ แต่ละรายการต้องมีการสนับสนุนทั้งหมด คะแนนประสิทธิภาพมาตรฐาน (แสดงอยู่ใน PerformancePoint API) เว้นแต่จะครอบคลุมอยู่ในจุดประสิทธิภาพมาตรฐานอื่นๆ ที่รองรับ
  • นอกจากนี้ ควรเผยแพร่คะแนนประสิทธิภาพเพิ่มเติมหาก สนับสนุนประสิทธิภาพของวิดีโอที่ยั่งยืน ซึ่งไม่ใช่วิดีโอมาตรฐานที่ระบุไว้

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

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

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

หากการใช้งานอุปกรณ์รวมการแสดงผลของหน้าจอแบบฝังที่มี ความยาวแนวทแยงมุมอย่างน้อย 2.5 นิ้ว หรือรวมพอร์ตเอาต์พุตวิดีโอ หรือ ประกาศการรองรับกล้องผ่าน android.hardware.camera.any แฟล็กฟีเจอร์

  • [C-1-1] ต้องมีการสนับสนุนวิดีโอ VP8 หรือ H.264 อย่างน้อย 1 รายการ โปรแกรมเปลี่ยนไฟล์ และทำให้ใช้งานได้สำหรับแอปพลิเคชันของบุคคลที่สาม
  • รองรับทั้งโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 และ H.264 และทำให้ใช้งานได้ สำหรับแอปพลิเคชันของบุคคลที่สาม

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

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

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

  • ควรสนับสนุนอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่สนับสนุน

หากการติดตั้งอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์วิดีโอหรือรูปภาพที่ใช้ฮาร์ดแวร์เร่งการแสดงผล และรองรับกล้องฮาร์ดแวร์ที่ติดหรือเชื่อมต่อได้อย่างน้อย 1 ตัวที่รั่วไหลผ่าน android.camera API:

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

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

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

5.2.1 H.263

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

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

5.2.2 H.264

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

  • [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 อย่างไรก็ตาม การรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น การเรียงลำดับ Macroblock) และ RS (ส่วนซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เพื่อ สามารถรักษาความเข้ากันได้กับอุปกรณ์ Android อื่นๆ ขอแนะนำว่า โปรแกรมเปลี่ยนไฟล์จะไม่ใช้ ASO, FMO และ RS กับโปรไฟล์พื้นฐาน
  • [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
  • ควรรองรับโปรไฟล์หลักระดับ 4
  • ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) เป็น ที่ระบุไว้ในตารางต่อไปนี้

หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส H.264 สำหรับ 720p หรือ 1080p ความละเอียดวิดีโอผ่าน API สื่อต่างๆ ได้

  • [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 240 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 20 FPS 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3 VP8

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

  • [C-1-1] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD
  • ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (ความละเอียดสูง) ต่อไปนี้
  • [C-1-2] ต้องรองรับการเขียนไฟล์ Matroska WebM
  • ควรมีตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่ตรงตาม ข้อกำหนดการเขียนโค้ดฮาร์ดแวร์ RTC ของโครงการ WebM เพื่อให้แน่ใจว่า คุณภาพที่ยอมรับได้ของบริการสตรีมมิงวิดีโอบนเว็บและการประชุมทางวิดีโอ

หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับ 720p หรือ 1080p ความละเอียดวิดีโอผ่าน API สื่อต่างๆ ได้

  • [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4 VP9

หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้

  • [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
  • [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
  • [C-1-3] ต้องสร้างข้อมูล CodecPrivate
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
  • [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้สนับสนุนโปรไฟล์การถอดรหัส HD เนื่องจาก ซึ่งจะระบุในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน API สื่อ:

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

5.2.5 H.265

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
  • ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้ารหัส HD ซึ่งจะระบุในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3 การถอดรหัสวิดีโอ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องรองรับความละเอียดของวิดีโอแบบไดนามิกและการสลับอัตราเฟรม ผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับ VP8, VP9 ตัวแปลงรหัส H.264 และ H.265 แบบเรียลไทม์และมีความละเอียดสูงสุดที่รองรับ ตามตัวแปลงรหัสแต่ละตัวบนอุปกรณ์

5.3.1 MPEG-2

หากการติดตั้งอุปกรณ์รองรับตัวถอดรหัส MPEG-2 การดำเนินการต่อไปนี้

  • [C-1-1] ต้องสนับสนุนระดับสูงของโปรไฟล์หลัก

5.3.2 H.263

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

  • [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 30 และระดับ 45

5.3.3 MPEG-4

หากอุปกรณ์มีตัวถอดรหัส MPEG-4 สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-1-1] ต้องรองรับ Simple Profile ระดับ 3

5.3.4 H.264

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน ที่ค้ำ สำหรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (ส่วนที่ซ้ำกัน) ไม่บังคับ
  • [C-1-2] ต้องสามารถถอดรหัสวิดีโอด้วย SD (ความละเอียดมาตรฐาน) โปรไฟล์ที่แสดงในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐาน และโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
  • ควรสามารถถอดรหัสวิดีโอด้วยโปรไฟล์ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้

หากความสูงที่เมธอด Display.getSupportedModes() รายงานคือ เท่ากับหรือมากกว่าความละเอียดของวิดีโอ การใช้งานอุปกรณ์

  • [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในสิ่งต่อไปนี้
  • [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในลักษณะต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 240 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 60 FPS 30 FPS (60 FPS ทีวี)
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5 H.265 (HEVC)

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

  • [C-1-1] ต้องรองรับระดับโปรไฟล์หลักระดับ 3 และวิดีโอ SD การถอดรหัสโปรไฟล์ตามที่ระบุในตารางต่อไปนี้
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
  • [C-1-2] ต้องสนับสนุนโปรไฟล์การถอดรหัส HD ดังที่ระบุต่อไปนี้ หากมีตัวถอดรหัสฮาร์ดแวร์

หากความสูงที่เมธอด Display.getSupportedModes() รายงานคือ เท่ากับหรือมากกว่าความละเอียดของวิดีโอแล้ว:

  • [C-2-1] การใช้งานอุปกรณ์ต้องรองรับ H.265 หรือ VP9 อย่างน้อย 1 รายการ การถอดรหัสโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 352 x 288 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30/60 FPS (60 fps ทีวีที่มีการถอดรหัสฮาร์ดแวร์ H.265) 60 FPS
อัตราบิตของวิดีโอ 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR ผ่านสื่อ API:

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

5.3.6 VP8

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

  • [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
  • ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่ตรงตาม ข้อกำหนด
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้

หากความสูงตามที่รายงานโดยเมธอด Display.getSupportedModes() มีค่าเท่ากับ หรือมากกว่าความละเอียดของวิดีโอแล้ว:

  • [C-2-1] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในส่วน ตารางต่อไปนี้
  • [C-2-2] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในส่วน ตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 FPS (60 FPS ทีวี) 30 (60 FPSทีวี)
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7 VP9

หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้

  • [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ใน ตารางต่อไปนี้
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้

หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์

  • [C-2-1] ต้องสนับสนุนโปรไฟล์การถอดรหัส HD ดังที่ระบุต่อไปนี้

หากความสูงที่เมธอด Display.getSupportedModes() รายงานคือ เท่ากับหรือมากกว่าความละเอียดของวิดีโอแล้ว:

  • [C-3-1] การใช้งานอุปกรณ์ต้องรองรับ VP9 หรือ H.265 อย่างน้อย 1 รายการ การถอดรหัสของโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps (60 fpsทีวีที่มีการถอดรหัสฮาร์ดแวร์ VP9) 60 FPS
อัตราบิตของวิดีโอ 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

หากการใช้อุปกรณ์อ้างว่ารองรับ VP9Profile2 หรือ VP9Profile3 ผ่าน "CodecProfileLevel" API สื่อ:

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) จนถึง API สื่อ:

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

5.3.8 Dolby Vision

หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION นั้น

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

5.3.9 AV1

หากอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำงานดังนี้

  • [C-1-1] ต้องรองรับโปรไฟล์ 0 ที่รวมเนื้อหาแบบ 10 บิต

5.4 การบันทึกเสียง

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

5.4.1 การบันทึกเสียงและข้อมูลไมโครโฟนแบบข้อมูลดิบ

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

  • [C-1-1] ต้องอนุญาตให้มีการบันทึกเนื้อหาเสียงดิบที่มีรายการต่อไปนี้ ลักษณะเฉพาะ:

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
    • ช่องสัญญาณ: โมโน
  • ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีรายการต่อไปนี้ ลักษณะเฉพาะ:

    • รูปแบบ: PCM เชิงเส้น 16 บิต และ 24 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • ช่องสัญญาณ: กี่ช่องเท่ากับจำนวนไมโครโฟนบน อุปกรณ์
  • [C-1-2] ต้องจับอัตราการสุ่มตัวอย่างสูงกว่าโดยไม่มีการสุ่มตัวอย่าง

  • [C-1-3] ต้องใส่ตัวกรองการลบรอยหยักที่เหมาะสมเมื่อ อัตราการสุ่มตัวอย่างที่ระบุข้างต้นจะได้รับการบันทึกด้วยการสุ่มตัวอย่างลดลง

  • ควรอนุญาตให้มีการบันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ หมายถึงลักษณะดังต่อไปนี้:

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
    • ช่องสัญญาณ: สเตอริโอ
  • [C-1-4] ต้องใช้ MicrophoneInfo API และกรอกข้อมูลอย่างถูกต้องสำหรับไมโครโฟนที่มีในอุปกรณ์ แอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านทาง AudioManager.getMicrophones() API และไมโครโฟนที่ใช้งานอยู่ในขณะนี้ซึ่งบุคคลที่สามเข้าถึงได้ แอปพลิเคชันของบุคคลที่สามผ่าน AudioRecord.getActiveMicrophones() และ MediaRecorder.getActiveMicrophones() API หากการติดตั้งอุปกรณ์อนุญาตให้บันทึกคุณภาพเสียงจากวิทยุและดีวีดี AM ของเสียงดิบ เนื้อหาจะมีลักษณะต่อไปนี้

  • [C-2-1] ต้องจับภาพโดยไม่มีการสุ่มตัวอย่างในอัตราส่วนที่สูงกว่า 16000:22050 หรือ 44100:48000

  • [C-2-2] ต้องมีตัวกรองขจัดรอยหยักที่เหมาะสมสำหรับ Up-Sampling หรือ Down-Sampling

5.4.2 จับภาพสำหรับการจดจำเสียง

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

  • [C-1-1] ต้องจับภาพ android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION แหล่งที่มาของเสียงที่ หนึ่งในอัตราการสุ่มตัวอย่าง ได้แก่ 44100 และ 48000
  • [C-1-2] ต้องปิดใช้การประมวลผลเสียงการลดเสียงรบกวนโดยค่าเริ่มต้นเมื่อ กำลังบันทึกสตรีมเสียงจากเสียง AudioSource.VOICE_RECOGNITION แหล่งที่มา
  • [C-1-3] โดยค่าเริ่มต้น ต้องปิดใช้การควบคุมค่าเกนอัตโนมัติเมื่อบันทึก สตรีมเสียงจากแหล่งที่มาเสียง AudioSource.VOICE_RECOGNITION
  • ควรบันทึกสตรีมเสียงการจดจำเสียงที่มีอัตราคงที่โดยประมาณ ลักษณะแอมพลิจูดเทียบกับความถี่: โดยเฉพาะ ±3 dB จาก 100 Hz เป็น 4000 Hz
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงด้วยการตั้งค่าความไวต่ออินพุต ซึ่งก็คือแหล่งพลังงานเสียง (SPL) 90 dB ที่ 1000 Hz จะให้ค่า RMS 2500 สำหรับตัวอย่าง 16 บิต
  • ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้แอมพลิจูด PCM ระดับต่างๆ จะติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB ตั้งแต่ -18 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน
  • ควรบันทึกสตรีมเสียงการจดจำเสียงด้วยฮาร์มอนิกทั้งหมด การบิดเบี้ยว (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ ไมโครโฟน

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

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

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

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

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

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

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

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

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

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

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

  • [C-SR-1] มีสิทธิ์ STRONGLY_RECOMMENDED เพื่อประกาศสิ่งนี้ผ่าน AcosimpleEchoCanceler เมธอด API AcouralEchoCanceler.isavailable()
  • [C-SR-2] เป็น STRONGLY_RECOMMENDED เพื่ออนุญาตให้สามารถใช้เอฟเฟกต์เสียงนี้ได้ ควบคุมได้ด้วย AcobasicEchoCanceler API
  • [C-SR-3] คือ STRONGLY_RECOMMENDED เพื่อระบุเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกัน การใช้งานผ่าน AudioEffect.Descriptor.uuid ด้วย

5.4.5 จับภาพพร้อมกัน

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone ก็ต้อง ใช้การบันทึกพร้อมกันดังที่อธิบายไว้ในเอกสารนี้ ดังนี้

  • [C-1-1] ต้องอนุญาตการเข้าถึงไมโครโฟนพร้อมกันโดยการช่วยเหลือพิเศษ บริการจับภาพที่มี AudioSource.VOICE_RECOGNITION และอย่างน้อย 1 รายการ ขณะบันทึกแอปพลิเคชันด้วย AudioSource
  • [C-1-2] ต้องอนุญาตการเข้าถึงไมโครโฟนพร้อมกันโดยอุปกรณ์ที่ติดตั้งมาล่วงหน้า แอปพลิเคชันที่มีบทบาท Assistant และแอปพลิเคชันอย่างน้อย 1 รายการ การจับภาพที่มี AudioSource ใดๆ ยกเว้น AudioSource.VOICE_COMMUNICATIONหรือAudioSource.CAMCORDER
  • [C-1-3] ต้องปิดเสียงการบันทึกเสียงสำหรับแอปพลิเคชันอื่นๆ ยกเว้น บริการการช่วยเหลือพิเศษขณะที่แอปพลิเคชันกำลังจับภาพ AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER แต่เมื่อ แอปกำลังบันทึกข้อมูลผ่าน AudioSource.VOICE_COMMUNICATION จากนั้นอีกแอปหนึ่ง สามารถบันทึกเสียงหากเป็นแอปที่ได้รับสิทธิ์ (ติดตั้งไว้ล่วงหน้า) ที่มี สิทธิ์ CAPTURE_AUDIO_OUTPUT
  • [C-1-4] ในกรณีที่มีแอปพลิเคชันตั้งแต่ 2 แอปพลิเคชันขึ้นไปพร้อมกัน และ ทั้ง 2 แอปไม่มี UI อยู่ด้านบน อันที่เริ่มจับภาพล่าสุด จะรับเสียงได้

5.4.6 ระดับเสียงไมโครโฟน

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

  • ควรแสดงแอมพลิจูดความถี่ราบโดยประมาณเทียบกับความถี่แอมพลิจูด-กับความถี่ ลักษณะในช่วงความถี่กลาง: โดยเฉพาะ ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกเสียง การจดจำแหล่งที่มาของเสียง
  • ควรตั้งค่าความไวของอินพุตเสียงเป็นไซนัสซอยด์ 1000 Hz เสียงต้นฉบับที่เล่นที่ 90 dB ระดับความดันเสียง (SPL) ให้ผลตอบสนอง ด้วย RMS 2500 สำหรับตัวอย่าง 16 บิต (หรือ Full Scale สำหรับลอยตัว -22.35 dB ตัวอย่างความแม่นยำแบบจุด/คู่) สำหรับไมโครโฟนทุกตัวที่ใช้ บันทึกแหล่งที่มาของเสียงในการจดจำเสียง
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในที่ต่ำ ช่วงความถี่: โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เมื่อเทียบกับ ให้ครอบคลุมช่วงความถี่กลางของไมโครโฟนแต่ละตัวที่ใช้ในการบันทึก แหล่งที่มาของเสียงในการจดจำเสียง
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดใน ช่วงความถี่สูง: โดยเฉพาะตั้งแต่ ±30 dB ตั้งแต่ 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนทุกตัวที่ใช้ เพื่อบันทึกแหล่งที่มาของเสียงในการจดจำเสียง

5.5 การเล่นเสียง

Android มีการสนับสนุนเพื่ออนุญาตให้แอปเล่นเสียงผ่านเสียง เอาต์พุตของอุปกรณ์ต่อพ่วงตามที่ระบุไว้ในส่วน 7.8.2

5.5.1 การเล่นเสียงดิบ

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

  • [C-1-1] ต้องอนุญาตการเล่นเนื้อหาเสียงดิบที่มีรายการต่อไปนี้ ลักษณะเฉพาะ:

    • รูปแบบต้นฉบับ: PCM เชิงเส้น 16 บิต 8 บิต ทศนิยม
    • ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องทางที่ถูกต้อง ได้สูงสุดถึง 8 ช่อง
    • อัตราการสุ่มตัวอย่าง (ในรูปแบบ Hz):
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 ที่แชแนล การกำหนดค่าข้างต้น
      • 96000 ในแบบโมโนและสเตอริโอ

5.5.2 เอฟเฟกต์เสียง

Android มี API สำหรับเอฟเฟกต์เสียง สำหรับการใช้งานอุปกรณ์

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

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

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

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

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

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

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

  • [C-1-1] การประทับเวลาเอาต์พุตแสดงผลโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำที่ +/- 2 มิลลิวินาที
  • [C-1-2] เวลาในการตอบสนองแบบ Cold Output ไม่เกิน 500 มิลลิวินาที

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

  • [C-SR-1] เวลาในการตอบสนองเอาต์พุตแบบเย็นไม่เกิน 100 มิลลิวินาทีสำหรับข้อมูลลำโพง เส้นทาง อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้มีความสำคัญมาก ขอแนะนำเป็นอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเหล่านี้ทันที ในแพลตฟอร์มในอนาคต เราจะต้องใช้เวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า เนื่องจาก "ต้อง"
  • [C-SR-2] เวลาในการตอบสนองเมื่อแตะโทนเสียงไม่เกิน 80 มิลลิวินาที
  • [C-SR-3] ลด Jitter เอาต์พุต Cold
  • [C-SR-4] การประทับเวลาเอาต์พุตแสดงผลโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำที่ +/- 1 มิลลิวินาที

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

  • [C-SR-5] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศ แฟล็กฟีเจอร์ android.hardware.audio.low_latency
  • [C-SR-6] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเวลาในการตอบสนองต่ำ เสียงผ่าน AAudio API ได้
  • [C-SR-7] แนะนำอย่างยิ่งเพื่อให้มั่นใจว่าสำหรับสตรีมที่ส่งกลับ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY จาก AAudioStream_getPerformanceMode() ค่าที่ AAudioStream_getFramesPerBurst() แสดงผล น้อยกว่าหรือเท่ากับค่าที่ android.media.AudioManager.getProperty(String) แสดงผล สำหรับคีย์พร็อพเพอร์ตี้ AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER

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

  • [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

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

  • [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาของอินพุต ตามที่ส่งคืนโดย AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp ไปจนถึง +/- 2 มิลลิวินาที "ข้อผิดพลาด" หมายถึงส่วนเบี่ยงเบนไปจากค่าที่ถูกต้อง
  • [C-3-2] เวลาในการตอบสนองแบบ Cold input ไม่เกิน 500 มิลลิวินาที

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

  • [C-SR-8] เวลาในการตอบสนองผ่านอินพุตเย็นที่ไม่เกิน 100 มิลลิวินาทีผ่านทางไมโครโฟน เส้นทางข้อมูล อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ เราแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเหล่านี้ทันที ในอนาคต ที่เปิดตัวแพลตฟอร์ม เราจะต้องใช้เวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า ต้อง
  • [C-SR-9] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [C-SR-10] ลดเสียงรบกวนของอินพุต Cold
  • [C-SR-11] จำกัดข้อผิดพลาดในการประทับเวลาของอินพุต ตามที่ส่งคืนโดย AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp ไปจนถึง +/- 1 มิลลิวินาที

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

  • [C-SR-12] ได้รับการแนะนำอย่างยิ่งให้มีเวลาตอบสนองระหว่างเดินทางได้อย่างต่อเนื่องปานกลาง 50 มิลลิวินาทีหรือน้อยกว่าในการวัด 5 ค่า โดยมีค่าเบี่ยงเบนค่าเฉลี่ยสัมบูรณ์ น้อยกว่า 10 มิลลิวินาที มากกว่า 1 เส้นทางที่รองรับ

5.7 โปรโตคอลเครือข่าย

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

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

  • [C-1-1] ต้องรองรับตัวแปลงรหัสหรือคอนเทนเนอร์ผ่าน HTTP และ HTTPS

  • [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่สอดคล้องกันดังที่แสดงใน ตารางรูปแบบกลุ่มสื่อด้านล่างในช่วง โปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7

  • [C-1-3] ต้องรองรับรูปแบบเพย์โหลด RTSP ที่เกี่ยวข้อง ดังที่แสดงใน ตาราง RTSP ด้านล่าง สำหรับข้อยกเว้น โปรดดูเชิงอรรถของตารางใน ส่วนที่ 5.1

รูปแบบกลุ่มสื่อ

รูปแบบกลุ่ม ข้อมูลอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
สตรีมส่ง MPEG-2 ISO 13818 ตัวแปลงรหัสวิดีโอ:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP
ในหัวข้อ 5.1.8 และ MPEG-2

ตัวแปลงสัญญาณเสียง:

  • AAC
ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรได้ในส่วนที่ 5.1.3
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 ISO 13818-7 ดูส่วนที่ 5.1.1 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
WebVTT WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์ ข้อมูลอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC RFC 6184 ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H264 AVC
MP4A-ลาตินอเมริกา RFC 6416 ดูส่วนที่ 5.1.3 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
H263-1998 RFC 3551
RFC 4629
RFC 2190
ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H263
H263-2000 RFC 4629 ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ H263
AMR RFC 4867 ดูส่วนที่ 5.1.3 สำหรับรายละเอียดเกี่ยวกับ AMR-NB
AMR-WB RFC 4867 ดูส่วนที่ 5.1.3 สำหรับรายละเอียดเกี่ยวกับ AMR-WB
MP4V-ES RFC 6416 ดูส่วนที่ 5.1.8 สำหรับรายละเอียดเกี่ยวกับ MPEG-4 SP
Mpeg4-ทั่วไป RFC 3640 ดูส่วนที่ 5.1.3 เพื่อดูรายละเอียดเกี่ยวกับ AAC และตัวแปร
MP2T RFC 2250 ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming

5.8 สื่อที่ปลอดภัย

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

  • [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และการสนับสนุน โปรโตคอลการแสดงผลแบบไร้สายนั้น

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

หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และ รองรับจอแสดงผลภายนอกแบบใช้สาย

  • [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อ ผ่านพอร์ตแบบมีสายที่ผู้ใช้เข้าถึงได้

5.9 Musical Instrument Digital Interface (MIDI)

หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านทาง android.content.pm.PackageManager ได้

  • [C-1-1] ต้องรองรับ MIDI กับการรับส่งฮาร์ดแวร์ที่ใช้ MIDI ทั้งหมดสำหรับ ซึ่งมีการเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI โดยที่การขนส่งดังกล่าวมีลักษณะดังนี้

  • [C-1-2] ต้องรองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน)

  • [C-1-3] ต้องรวม libamidi.so (การรองรับ MIDI ของระบบ)

  • ควรรองรับ MIDI ผ่านโหมดอุปกรณ์ต่อพ่วง USB ส่วนที่ 7.7

5.10 เสียงระดับมืออาชีพ

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่าน android.content.pm.PackageManager ได้

  • [C-1-1] ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency
  • [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ใน ส่วน 5.6 เวลาในการตอบสนองของเสียง ต้องไม่เกิน 20 มิลลิวินาที และควรยาว 10 มิลลิวินาทีหรือน้อยกว่า สำหรับเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
  • [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และ USB ของอุปกรณ์ต่อพ่วง
  • [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
  • [C-1-5] ต้องสอดคล้องตามเวลาในการตอบสนองและข้อกำหนดด้านเสียง USB โดยใช้ เสียงแบบเนทีฟ API
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-SR-1] แนะนำอย่างยิ่งเพื่อตอบสนองต่อเวลาในการตอบสนองตามที่กำหนดไว้ในส่วน เวลาในการตอบสนองของเสียง 5.6 ครั้งละ 20 มิลลิวินาที หรือ น้อยกว่า มากกว่า 5 การวัดที่มีค่าเบี่ยงเบนค่าเฉลี่ยน้อยกว่า 5 มิลลิวินาทีผ่านเส้นทางลำโพงสู่ไมโครโฟน
  • [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับมือโปรสำหรับ เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่อง เวลาในการตอบสนองการป้อนข้อมูลแบบ Cold และเอาต์พุต Cold ข้อกำหนดด้านเวลาในการตอบสนองและเสียงผ่าน USB ที่ใช้ API เสียงดั้งเดิมของ AAudio บนเส้นทาง MMAP
  • [C-SR-3] แนะนำอย่างยิ่งให้ใช้ CPU ในระดับที่สม่ำเสมอ ประสิทธิภาพในขณะที่ใช้งานเสียงอยู่และโหลดของ CPU จะแตกต่างกันไป ต้องได้รับการทดสอบ โดยใช้แอป Android SynthMark SynthMark ใช้ซอฟต์แวร์สังเคราะห์ที่ทำงานบนเฟรมเวิร์กเสียงจำลอง ที่วัดประสิทธิภาพของระบบ แอป SynthMark ต้องเรียกใช้โดยใช้ ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
    • Voicemark.90 >= 32 เสียง
    • เวลาในการตอบสนองmark.fixed.little <= 15 มิลลิวินาที
    • เวลาในการตอบสนองmark.dynamic.little <= 50 มิลลิวินาที

ดูเอกสารประกอบของ SynthMark เพื่อดูคำอธิบายการเปรียบเทียบ

  • ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
  • ควรลดการเลื่อนของนาฬิกาเสียงให้สัมพันธ์กับ CPU CLOCK_MONOTONIC เมื่อทั้งคู่ทำงาน
  • ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
  • ควรลด Jitter ในเวลาเข้า Callback ของบัฟเฟอร์เสียงจนจบ ด้วยเหตุผลนี้ ส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มโดย Callback
  • ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน
  • ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
  • ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
  • ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
  • ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ ซึ่งรวมถึง ระยะเวลาทันทีหลัง Cold Start
  • ควรระบุความแตกต่างของนาฬิการะหว่างอินพุตและเอาต์พุตเป็น 0 ปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 จุดทำงานอยู่ ตัวอย่างของความสอดคล้อง จุดสิ้นสุดรวมถึงไมโครโฟนและลำโพงของอุปกรณ์ หรืออินพุตช่องเสียบเสียง และเอาต์พุต
  • ควรจัดการ Callback ที่เสร็จสมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุต ของจุดสิ้นสุดที่สอดคล้องกันในเทรดเดียวกันเมื่อทั้ง 2 จุดทำงานอยู่ และป้อน Callback เอาต์พุตทันทีหลังการย้อนกลับจาก Callback อินพุต หรือ หากไม่สามารถจัดการ Callback ในชุดข้อความเดียวกัน ให้ป้อน เอาต์พุต Callback หลังจากป้อน Callback อินพุตเพื่ออนุญาตให้ ให้เวลาด้านอินพุตและเอาต์พุตสอดคล้องกัน
  • ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับอินพุต และด้านเอาต์พุตของจุดสิ้นสุดที่สัมพันธ์กัน
  • ควรลดเวลาในการตอบสนองของการแตะ
  • ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)
  • ควรมีเวลาในการตอบสนองจากการป้อนข้อมูลด้วยการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่า หรือ เท่ากับ 40 มิลลิวินาที

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

  • [C-SR-4] แนะนำอย่างยิ่งให้รายงานการสนับสนุนสำหรับฟีเจอร์ android.hardware.audio.pro ผ่าน android.content.pm.PackageManager

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

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

  • [C-3-1] ต้องใช้คลาสเสียง USB
  • [C-3-2] ต้องมีค่าเวลาในการตอบสนองของเสียงไป-กลับแบบเฉลี่ยต่อเนื่องเท่ากับ ไม่เกิน 25 มิลลิวินาที วัดค่าได้เกิน 5 ค่าซึ่งมีค่าเบี่ยงเบนค่าเฉลี่ยสัมบูรณ์ น้อยกว่า 5 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB (วัดได้โดยใช้อะแดปเตอร์ USB-3.5 มม. และ Audio Loopback ดองเกิล หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายเคเบิลเชื่อมต่อ อินพุตไปยังเอาต์พุต)
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันได้สูงสุด 8 ช่อง แต่ละทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิตเมื่อใช้งาน ด้วยอุปกรณ์ต่อพ่วงระบบเสียง USB ที่สนับสนุนข้อกำหนดเหล่านี้
  • [C-SR-7] ได้รับการแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ AAudio Native Audio API บนเส้นทาง MMAP

หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้

  • ควรรองรับเอาต์พุตสเตอริโอและ 8 ช่องสัญญาณที่ 20 บิตหรือ ความลึก 24 บิตและ 192 kHz โดยไม่สูญเสียความลึกของบิตหรือการสุ่มตัวอย่างซ้ำ ในการกำหนดค่าอย่างน้อย 1 รายการ

5.11 จับภาพสำหรับที่ไม่ได้ประมวลผล

Android รองรับการบันทึกเสียงที่ไม่ได้ประมวลผลผ่าน แหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES จะเข้าถึงได้โดยใช้ค่าที่กำหนดล่วงหน้าสำหรับระเบียน SL_ANDROID_RECORDING_PRESET_UNPROCESSED

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

  • [C-1-1] ต้องรายงานการสนับสนุนผ่าน android.media.AudioManager พร็อพเพอร์ตี้ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

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

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

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

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

  • [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับ ไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (โดยวัด SNR เป็นความแตกต่างระหว่าง 94 dB SPL และที่เทียบเท่า SPL ของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)

  • [C-1-7] ต้องมีค่าความผิดเพี้ยนของฮาร์มอนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้ บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

  • [C-1-8] ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การปรับเพิ่มอัตโนมัติ การควบคุม ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางอื่นที่ไม่ใช่ ตัวคูณระดับเพื่อเพิ่มระดับไปยังช่วงที่ต้องการ กล่าวคือ

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

การวัด SPL ทั้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับ ไมโครโฟนแต่ละตัว

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone แต่ไม่ รองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

  • [C-2-1] ต้องส่งคืน null สำหรับ AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) เมธอด API เพื่อระบุการขาดการรองรับอย่างเหมาะสม
  • [C-SR-1] ยังคงแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดจำนวนมาก สำหรับเส้นทางสัญญาณสำหรับแหล่งที่มาของการบันทึกที่ไม่ได้ประมวลผล

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

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

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

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

    • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และ Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปใช้ได้ รวมถึง dumpsys cmd stats
    • [C-0-11] ต้องรองรับคำสั่ง Shell cmd testharness กำลังอัปเกรด การติดตั้งใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มี การบล็อกข้อมูลถาวรอาจได้รับการยกเว้นจาก C-0-11
    • [C-0-3] ต้องไม่ดัดแปลงรูปแบบหรือเนื้อหาของระบบอุปกรณ์ เหตุการณ์ (batterystats , Diskstats, Fingerprint, graphicstats, netstats, notifications, procstats) บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำเหตุการณ์ต่อไปนี้ สามารถเข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell cmd stats และ StatsManager คลาส System API
      • เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
      • ตรวจพบความผิดปกติ
      • รายงานเบรดครัมบ์ของแอปแล้ว
      • แอปขัดข้อง
      • เกิดแอป
      • เปลี่ยนระดับแบตเตอรี่แล้ว
      • เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
      • BleScanผลลัพธ์ได้รับ
      • เปลี่ยนสถานะ BleScan แล้ว
      • เปลี่ยนสถานะการชาร์จแล้ว
      • เปลี่ยนสถานะโหมดอุปกรณ์ชั่วคราวแล้ว
      • เปลี่ยนสถานะของบริการที่ทำงานอยู่เบื้องหน้าแล้ว
      • เปลี่ยนสถานะการสแกน GPS แล้ว
      • เปลี่ยนสถานะของงานแล้ว
      • สถานะเสียบปลั๊กเปลี่ยน
      • เปลี่ยนสถานะงานที่กำหนดเวลาไว้แล้ว
      • สถานะหน้าจอเปลี่ยน
      • สถานะการซิงค์เปลี่ยนแปลง
      • แบบเรียลไทม์โดยระบบ
      • เปลี่ยนสถานะ UidProcess แล้ว
      • เปลี่ยนสถานะ Wake Lock แล้ว
      • ตั้งปลุกแล้ว
      • เปลี่ยนสถานะ WifiLock
      • เปลี่ยนสถานะ Wifiมัลติแคสต์ล็อกแล้ว
      • เปลี่ยนสถานะการสแกน Wi-Fi แล้ว
    • [C-0-4] ต้องมี adb daemon ฝั่งเซิร์ฟเวอร์ไม่ทำงานโดยค่าเริ่มต้น และ ต้องมีกลไกที่ผู้ใช้สามารถเข้าถึงได้ในการเปิดการแก้ไขข้อบกพร่องของ Android สะพาน
    • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android มีการสนับสนุนสำหรับ คำกริยาวิเศษณ์ Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แล้วที่รู้จัก
    • [C-0-6] ต้องระบุกลไกที่ทำให้สามารถเชื่อมต่อ adb จาก เครื่องโฮสต์ ดังนี้

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

    • [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ต หรือ Wi-Fi)
    • [C-3-2] ต้องระบุไดรเวอร์สำหรับ Windows 7, 8 และ 10 เพื่อให้ เพื่อเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb

    หากการใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi มีประโยชน์ดังนี้

    • [C-4-1] ต้องมีเมธอด AdbManager#isAdbWifiSupported() การคืนสินค้า true

    หากการใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi และรวมถึงกล้องอย่างน้อย 1 ตัว ซึ่งจะ:

    • [C-5-1] ต้องมีเมธอด AdbManager#isAdbWifiQrSupported() การคืนสินค้า true
  • บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)

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

    • [C-0-8] ต้องรวมเฟรมเวิร์ก Monkey และทำให้ใช้งานได้สำหรับ แอปพลิเคชันที่จะใช้
  • SysTrace

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

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

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

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

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

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

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

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

  • [C-0-1] ต้องเคารพ android.settings.APPLICATION_DEVELOPMENT_SETTINGS ต้องการแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน อัปสตรีม Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และทำให้ผู้ใช้ เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งที่การตั้งค่า > เกี่ยวกับอุปกรณ์ > รายการในเมนูหมายเลขบิลด์
  • [C-0-2] ต้องซ่อนตัวเลือกของนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น
  • [C-0-3] ต้องระบุกลไกที่ชัดเจนว่าไม่ได้ให้สิทธิพิเศษ การดำเนินการกับแอปของบุคคลที่สามแอปหนึ่ง แทนที่จะเป็นแอปอีกแอปหนึ่งเพื่อให้นักพัฒนาแอป ตัวเลือก ต้องระบุเอกสารหรือเว็บไซต์ที่เปิดเผยต่อสาธารณะซึ่งอธิบายวิธี เปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ เอกสารหรือเว็บไซต์ต้องลิงก์ได้จาก เอกสาร Android SDK
  • ควรมีการแจ้งเตือนด้วยภาพแก่ผู้ใช้อย่างต่อเนื่องเมื่อนักพัฒนาแอป ตัวเลือกเปิดใช้อยู่ และคำนึงถึงความปลอดภัยของผู้ใช้
  • อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ไว้ชั่วคราวโดยดูด้วยสายตา การซ่อนหรือปิดใช้งานเมนู เพื่อไม่ให้รบกวนในกรณีที่ ความปลอดภัยของผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์ที่เจาะจง API สำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม:

  • [C-0-1] การปรับใช้อุปกรณ์ต้องนำไปใช้ API ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

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

  • [C-0-2] คำจำกัดความคลาสที่สมบูรณ์ (ตามที่ SDK บันทึกไว้) สำหรับคอมโพเนนต์ ต้องมี API อยู่
  • [C-0-3] ต้องนำลักษณะการทำงานของ API มาใช้เป็น "ไม่มีการดำเนินการ" ในบางสถานการณ์ แฟชั่น
  • [C-0-4] เมธอด API ต้องแสดงค่า Null หาก SDK อนุญาต เอกสารประกอบ
  • [C-0-5] เมธอด API ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่มีค่า Null ไม่ได้รับอนุญาตตามเอกสาร SDK
  • [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ SDK ไม่ได้บันทึกไว้ เอกสารประกอบ
  • [C-0-7] การใช้งานอุปกรณ์ต้องรายงานฮาร์ดแวร์ที่ถูกต้องอยู่เสมอ ข้อมูลการกำหนดค่าผ่านทาง getSystemAvailableFeatures() และ hasSystemFeature(String) เมธอดใน android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

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

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

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

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

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

7.1.1 การกำหนดค่าหน้าจอ

7.1.1.1 ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับเลย์เอาต์หน้าจอแบบลอจิคัลที่หลากหลาย และอนุญาตให้แอปพลิเคชันสืบค้นหน้าจอของการกำหนดค่าปัจจุบัน ขนาดเลย์เอาต์ผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

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

  • [C-0-1] ต้องรายงานขนาดการจัดวางที่ถูกต้องสำหรับ Configuration.screenLayout ตามที่ให้คำจำกัดความไว้ในเอกสาร Android SDK กล่าวอย่างเจาะจงคือ การใช้งานอุปกรณ์ "ต้องรายงาน" ขนาดหน้าจอของพิกเซลอิสระ (dp) มีดังนี้

    • อุปกรณ์ที่ตั้งค่า Configuration.uiMode เป็นค่าใดก็ได้นอกเหนือจาก UI_MODE_TYPE_Wwatch และรายงานขนาด small สําหรับ Configuration.screenLayout ต้องมีอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด normal สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด large สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 960 dp x 720 dp
  • [C-0-2] ต้องปฏิบัติตาม ระบุไว้ รองรับขนาดหน้าจอผ่านทางแท็ก <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ ในเอกสารประกอบของ Android SDK

  • อาจมีจอแสดงผลที่ใช้งานได้กับ Android ซึ่งมีมุมโค้งมน

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

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

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

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

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

  • [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือพับ หรือ API ไฟล์ช่วยเหลือไปยังแอปพลิเคชัน

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

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

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

  • [C-0-1] ตั้งค่าการใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ เป็น 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามข้อใดข้อหนึ่งต่อไปนี้ เงื่อนไข:

    • แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอที่ใหญ่ขึ้น ผ่านandroid.max_aspect ค่าข้อมูลเมตา
    • แอปประกาศว่าปรับขนาดได้ผ่าน android:resizeableActivity
    • แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ android:maxAspectRatio ซึ่งจะจำกัดสัดส่วนภาพที่อนุญาต
  • [C-0-3] การใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_WATCH ต้องตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)

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

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

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

  • การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐาน ที่ใกล้เคียงที่สุดกับความหนาแน่นของหน้าจอที่เป็นตัวเลขมากที่สุด เว้นแต่ว่า ความหนาแน่นเชิงตรรกะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าขนาดต่ำสุดที่รองรับ ถ้า ความหนาแน่นของเฟรมเวิร์ก Android มาตรฐาน ที่เป็นตัวเลขที่ใกล้เคียงที่สุด ความหนาแน่นทางกายภาพส่งผลให้มีขนาดของหน้าจอที่เล็กกว่าหน้าจอที่เล็กที่สุด ขนาดหน้าจอที่ใช้งานร่วมกันได้ (ความกว้าง 320 dp) การใช้งานอุปกรณ์ รายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดในลำดับถัดไป

หากไม่สามารถปรับขนาดจอแสดงผลของอุปกรณ์ได้ ให้ทำดังนี้

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

7.1.2 แสดงเมตริก

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

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับจอแสดงผลที่รองรับ Android ทั้งหมด เมตริกที่กำหนดไว้ใน android.util.DisplayMetrics API

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

  • [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่รองรับ Android ตามที่ระบุไว้ใน android.util.DisplayMetrics API สำหรับ view.Display เริ่มต้นการจำลอง

7.1.3 การวางแนวหน้าจอ

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

  • [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานว่ามีการสนับสนุนอย่างน้อย 1 รายการ การวางแนว ตัวอย่างเช่น อุปกรณ์ที่มีการวางแนวคงที่ เช่น โทรทัศน์ หรือแล็ปท็อป ควรเฉพาะ รายงาน android.hardware.screen.landscape
  • [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับกระแสไฟฟ้าของอุปกรณ์ เมื่อใดก็ตามที่ค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

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

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

7.1.4 การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

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

  • [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับให้ถูกต้อง (1.1, 2.0, 3.0, 3.1, 3.2) ผ่าน API ที่มีการจัดการ (เช่น ผ่าน GLES10.getString()) และ API แบบเนทีฟ
  • [C-0-2] ต้องมีการสนับสนุนสำหรับ API ที่มีการจัดการที่เกี่ยวข้องทั้งหมด และ API แบบเนทีฟสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุให้รองรับ

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

  • [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ซึ่งเป็นแบบรวมและมีรายละเอียด ในเอกสารประกอบ Android SDK
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

การทดสอบ dEQP ของ OpenGL ES ได้รับการแบ่งพาร์ติชันเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมี วันที่/หมายเลขเวอร์ชันที่เกี่ยวข้อง รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt อุปกรณ์ที่ รองรับ OpenGL ES ในระดับที่รายงานด้วยตนเองบ่งบอกว่าสามารถผ่าน dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดก็ตาม ก็จะเป็นดังนี้

  • [C-2-1] ต้องรายงานผ่าน API ที่มีการจัดการของ OpenGL ES และ API แบบเนทีฟ ส่วนขยายอื่นๆ ของ OpenGL ES ที่ได้ติดตั้งไปแล้ว และในทางกลับกัน ไม่รายงานสตริงส่วนขยายที่ระบบไม่รองรับ
  • [C-2-2] ต้องรองรับ EGL_KHR_image, EGL_KHR_image_base EGL_ANDROID_image_native_buffer EGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_swap_buffers_with_damage ส่วนขยาย EGL_ANDROID_recordable และ EGL_ANDROID_GLES_layers
  • [C-2-3] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ OpenGL ES รองรับผ่านแฟล็กฟีเจอร์ android.software.opengles.deqp.level
  • [C-2-4] ต้องรองรับเวอร์ชัน 132383489 (ตั้งแต่วันที่ 1 มีนาคม 2020) เป็นอย่างน้อย ได้รับการรายงานไว้ในแฟล็กฟีเจอร์android.software.opengles.deqp.level
  • [C-2-5] ต้องผ่านการทดสอบ OpenGL ES dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 และเวอร์ชันที่ระบุไว้ใน แฟล็กฟีเจอร์ android.software.opengles.deqp.level รายการ สำหรับแต่ละฟีเจอร์ที่รองรับ เวอร์ชัน OpenGL ES
  • [C-SR-2] แนะนําอย่างยิ่งให้สนับสนุน EGL_KHR_partial_update และ ส่วนขยาย OES_EGL_image_external รายการ
  • ควรรายงานอย่างถูกต้องผ่านทางเมธอด getString() พื้นผิว รูปแบบการบีบอัดที่ระบบรองรับ ซึ่งโดยทั่วไปจะเจาะจงเฉพาะผู้ให้บริการ

หากการใช้งานอุปกรณ์ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 ก็จะมีผลดังนี้

  • [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้ใน นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
  • [C-SR-3] แนะนำอย่างยิ่งให้สนับสนุน OES_EGL_image_external_essl3 ส่วนขยาย

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

  • [C-4-1] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด

หากการใช้งานอุปกรณ์รองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมดจะ:

  • [C-5-1] ต้องระบุการสนับสนุนผ่าน android.hardware.opengles.aep แฟล็กฟีเจอร์

หากการใช้งานอุปกรณ์แสดงการรองรับ EGL_KHR_mutable_render_buffer ส่วนขยาย

  • [C-6-1] ต้องรองรับ EGL_ANDROID_front_buffer_auto_refresh ด้วย ส่วนขยาย
7.1.4.2 Vulkan

Android รองรับ Vulkan ซึ่งเป็น API ข้ามแพลตฟอร์มแบบโอเวอร์เฮดต่ำสำหรับกราฟิก 3 มิติประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำงานดังนี้

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.1

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

  • ควรมีการรองรับ Vulkan 1.1

การทดสอบ Vulkan dEQP ได้รับการแบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมี วันที่/เวอร์ชันที่เกี่ยวข้อง รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt อุปกรณ์ที่ รองรับ Vulkan ในระดับที่รายงานด้วยตนเองบ่งชี้ว่าสามารถผ่าน dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า

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

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องพร้อมกับ android.hardware.vulkan.level และ android.hardware.vulkan.version แฟล็กฟีเจอร์
  • [C-1-2] ต้องแจกแจง VkPhysicalDevice สำหรับ Vulkan อย่างน้อย 1 รายการ API แบบเนทีฟ vkEnumeratePhysicalDevices() ที่ใช้เวลาเพียง 2 นาที
  • [C-1-3] ต้องใช้ Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับแต่ละรายการที่แจกแจง VkPhysicalDevice
  • [C-1-4] ต้องแจกแจงเลเยอร์ที่อยู่ในไลบรารีเนทีฟซึ่งมีชื่อว่า libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชัน ผ่าน Vulkan Native API vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties() ที่ใช้เวลาเพียง 2 นาที
  • [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่ให้ไว้โดยไลบรารีที่อยู่นอกส่วน หรือให้ข้อมูลในลักษณะอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีแอตทริบิวต์ android:debuggable ตั้งค่าเป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่ระบบรองรับผ่าน Vulkan Native API และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยาย ที่พวกเขาไม่ได้รองรับอย่างถูกต้อง
  • [C-1-7] ต้องรองรับ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และส่วนขยาย VK_KHR_incremental_present ของคุณ
  • [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ Vulkan dEQP รองรับผ่านแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-9] ต้องรองรับเวอร์ชัน 132317953 (ตั้งแต่วันที่ 1 มีนาคม 2019) เป็นอย่างน้อย ที่รายงานไว้ในแฟล็กฟีเจอร์android.software.vulkan.deqp.level
  • [C-1-10] ต้องผ่านการทดสอบ Vulkan dEQP ทั้งหมดในรายการทดสอบระหว่าง เวอร์ชัน 132317953 และเวอร์ชันที่ระบุไว้ใน แฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-11] ต้องไม่แจกแจงการสนับสนุนสำหรับ VK_KHR_video_queue ส่วนขยาย VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue นี้
  • [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้สนับสนุน VK_KHR_driver_properties และ VK_GOOGLE_display_timing ส่วนขยาย

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

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

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

  • [C-3-1] ต้องแสดงการรองรับสำหรับฉากและแฮนเดิลภายนอกของ SYNC_FD ประเภทและส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer
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" หรือปิดใช้การเร่งฮาร์ดแวร์ ผ่าน API ของ Android View ได้โดยตรง
  • [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับ เอกสารประกอบของ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาซอฟต์แวร์ผสานรวม พื้นผิว OpenGL ES ที่เร่งการแสดงผลด้วยฮาร์ดแวร์เป็นเป้าหมายการแสดงผลในลำดับชั้น UI

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

  • [C-0-3] ต้องสนับสนุน TextureView API และต้องแสดง พฤติกรรมที่สอดคล้องกับการติดตั้งใช้งานอัปสตรีม Android
7.1.4.5 จอแสดงผลขอบเขตกว้าง

หากการใช้งานอุปกรณ์อ้างว่ารองรับการแสดงผลที่มีขอบเขตกว้างผ่านทาง Configuration.isScreenWideColorGamut() นั้น

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
  • [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตพื้นที่อย่างน้อย 90% DCI-P3 ในพื้นที่ CIE 1931 xyY
  • [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
  • [C-1-5] ต้องโฆษณาการสนับสนุนสำหรับ EGL_KHR_no_config_context EGL_EXT_pixel_format_float EGL_KHR_gl_colorspace EGL_EXT_gl_colorspace_scrgb EGL_EXT_gl_colorspace_scrgb_linear EGL_EXT_gl_colorspace_display_p3 EGL_EXT_gl_colorspace_display_p3_linear และEGL_EXT_gl_colorspace_display_p3_passthrough ส่วนขยาย
  • [C-SR-1] แนะนําอย่างยิ่งให้สนับสนุน GL_EXT_sRGB

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

  • [C-2-1] ควรครอบคลุม sRGB 100% ขึ้นไปในพื้นที่ CIE 1931 xyY แม้ว่า ไม่ได้ระบุขอบเขตสีของหน้าจอ

7.1.5 โหมดความเข้ากันได้กับแอปพลิเคชันเดิม

Android จะระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานใน "ปกติ" โหมดเทียบเท่าขนาดหน้าจอ (ความกว้าง 320dp) เพื่อประโยชน์ของรุ่นเดิม แอปพลิเคชันที่ไม่ได้พัฒนาขึ้นสำหรับ Android เวอร์ชันเก่า และขนาดหน้าจอ

7.1.6 เทคโนโลยีหน้าจอ

แพลตฟอร์ม Android มี API ที่อนุญาตให้แอปพลิเคชันแสดงภาพ กราฟิกลงในจอแสดงผลที่รองรับ Android อุปกรณ์ต้องรองรับทั้งหมดนี้ API ตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตเป็นการเฉพาะในเอกสารนี้

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

  • [C-0-1] ต้องแสดงภาพกราฟิกสี 16 บิตได้
  • ควรสนับสนุนจอแสดงผลที่รองรับกราฟิกสี 24 บิต
  • [C-0-2] ต้องแสดงภาพภาพเคลื่อนไหวได้
  • [C-0-3] ต้องมีอัตราส่วนพิกเซล (PAR) ตั้งแต่ 0.9 ถึง 1.15 นั่นคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับรูปสี่เหลี่ยมจัตุรัส (1.0) มีความอดทน 10 ~ 15%

7.1.7 จอแสดงผลสำรอง

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

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

  • [C-1-1] ต้องใช้ DisplayManager บริการระบบและ API ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

7.2 อุปกรณ์อินพุต

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

7.2.1 แป้นพิมพ์

หากการใช้งานอุปกรณ์มีการสนับสนุนสำหรับบุคคลที่สาม แอปพลิเคชัน Input Method Editor (IME) ซึ่งจะ:

  • [C-1-1] ต้องประกาศ android.software.input_methods แฟล็กฟีเจอร์
  • [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
  • [C-1-3] ต้องมีซอฟต์แวร์แป้นพิมพ์ที่ติดตั้งไว้ล่วงหน้า

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

  • [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับ รูปแบบที่ระบุใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 คีย์)
  • ควรมีการใช้งานแป้นพิมพ์เสมือนเพิ่มเติม
  • อาจรวมแป้นพิมพ์ที่เป็นฮาร์ดแวร์ด้วย

7.2.2 การนำทางแบบไม่สัมผัส

Android มีการสนับสนุนสำหรับ D-pad แทร็กบอล และวงล้อเป็นกลไกสำหรับ การนำทางแบบไม่สัมผัส

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

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

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

7.2.3 ปุ่มนำทาง

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

  • [C-0-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดใช้งานแอปพลิเคชันที่ติดตั้ง ที่มีกิจกรรมกับ <intent-filter> ซึ่งตั้งค่าด้วย ACTION=MAIN และ CATEGORY=LAUNCHER หรือ CATEGORY=LEANBACK_LAUNCHER สำหรับอุปกรณ์ทีวี การนำไปใช้งานจริง ฟังก์ชัน Home ควรเป็นกลไกสำหรับค่าใช้จ่ายของผู้ใช้รายนี้
  • ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"

หากมีฟังก์ชัน "หน้าแรก" "ล่าสุด" หรือ "ย้อนกลับ" ฟังก์ชันต่อไปนี้

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

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

  • [C-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าจัดเตรียมกลไกการป้อนข้อมูลสำหรับ ฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการดำเนินการตั้งแต่ Android 4.0 แล้ว

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

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

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

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

หากอุปกรณ์มีฟังก์ชันผู้ช่วย ดังนี้

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

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

  • [C-5-1] แป้นนำทางต้องใช้ส่วนที่ต่างกันของหน้าจอ ไม่ใช่ พร้อมใช้งานสำหรับแอปพลิเคชัน และต้องไม่ปิดบังหรือแทรกแซง หน้าจอที่แอปพลิเคชันใช้งานได้
  • [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่ มีคุณสมบัติตรงตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
  • [C-5-3] ต้องทำตาม Flag ที่แอปกำหนดไว้ผ่านView.setSystemUiVisibility() API เพื่อให้ส่วนเฉพาะของหน้าจอนี้ (หรือที่เรียกว่าแถบนำทาง) มีการซ่อนไว้อย่างถูกต้องตามที่ระบุไว้ใน SDK

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสในหน้าแรกเท่านั้น
  • [C-6-2] ท่าทางสัมผัสที่เริ่มต้นในรูปสี่เหลี่ยมผืนผ้าที่ยกเว้นตามที่ระบุโดย แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets(), ต้องไม่ถูกดักฟังสำหรับฟังก์ชันการนำทางตราบใดที่มีการยกเว้น อนุญาตให้มีสี่เหลี่ยมผืนผ้าภายในขีดจำกัดการยกเว้นสูงสุด ตามที่ระบุใน เอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
  • [C-6-3] ต้องส่งแอปที่ทำงานอยู่เบื้องหน้า MotionEvent.ACTION_CANCEL เหตุการณ์เมื่อการแตะเริ่มถูกดักจับสำหรับท่าทางสัมผัสของระบบ มีการส่งแอปที่ทำงานอยู่เบื้องหน้าไว้ก่อนหน้านี้หรือไม่ MotionEvent.ACTION_DOWN กิจกรรม
  • [C-6-4] ต้องให้ราคาแก่ผู้ใช้ในการเปลี่ยนไปดูหน้าจอ การไปยังส่วนต่างๆ โดยใช้ปุ่ม (เช่น ในการตั้งค่า)
  • ควรมีฟังก์ชัน "หน้าแรก" โดยการปัดขึ้นจากขอบด้านล่างของ การวางแนวหน้าจอในปัจจุบัน
  • ควรมีฟังก์ชัน "ล่าสุด" เป็นการปัดขึ้นแล้วค้างไว้ก่อนที่จะปล่อย บริเวณเดียวกับท่าทางสัมผัสสำหรับหน้าแรก
  • ท่าทางสัมผัสที่เริ่มต้นภายใน WindowInsets#getMandatorySystemGestureInsets() ไม่ควรได้รับผลกระทบจากการแก้ไขการยกเว้นที่จัดเตรียมโดยเบื้องหน้า ใบสมัครผ่าน View#setSystemGestureExclusionRects()

หากฟังก์ชันการนำทางมาจากที่ใดก็ได้จากขอบด้านซ้ายและขวา ของการวางแนวหน้าจอปัจจุบัน:

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

7.2.4 อินพุตหน้าจอสัมผัส

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

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

  • ควรมีระบบป้อนข้อมูลตัวชี้บางประเภท (คล้ายเมาส์หรือการแตะ)
  • ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์

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

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

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

  • [C-2-1] ต้องรายงานแฟล็กฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch android.hardware.touchscreen.multitouch.distinct android.hardware.touchscreen.multitouch.jazzhand ตามประเภทหน้าจอสัมผัสที่เฉพาะเจาะจงบนอุปกรณ์

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

  • [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่เริ่มต้นด้วย android.hardware.touchscreen
  • [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
  • [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับ Configuration.touchscreen ช่อง API

7.2.5 การป้อนข้อมูลด้วยการสัมผัสปลอม

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

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

  • ควรประกาศการรองรับ Flag ฟีเจอร์ android.hardware.faketouch

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

  • [C-1-1] ต้องรายงานตำแหน่งหน้าจอ X และ Y แบบสัมบูรณ์ ของตำแหน่งเคอร์เซอร์ และแสดงตัวชี้แบบภาพบนหน้าจอ
  • [C-1-2] ต้องรายงานเหตุการณ์การสัมผัสที่มีโค้ดการดำเนินการที่ระบุ การเปลี่ยนแปลงสถานะที่เกิดขึ้นในตัวชี้ขึ้นหรือลงใน หน้าจอ
  • [C-1-3] ต้องรองรับการชี้ลงและขึ้นบนวัตถุบนหน้าจอ ช่วยให้ผู้ใช้จำลองการแตะบนวัตถุบนหน้าจอได้
  • [C-1-4] ต้องรองรับตัวชี้ลง ตัวชี้ขึ้น ชี้ลง แล้วชี้ขึ้น ตำแหน่งเดียวกันบนออบเจ็กต์บนหน้าจอ ภายในเกณฑ์เวลา อนุญาตให้ผู้ใช้จำลองการแตะสองครั้ง บนวัตถุบนหน้าจอ
  • [C-1-5] ต้องรองรับการชี้ลงไปยังจุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดที่กำหนดเองอื่นๆ บนหน้าจอ ตามด้วยตัวชี้ ขึ้น ซึ่งทำให้ผู้ใช้สามารถเลียนแบบการลากด้วยการแตะได้
  • [C-1-6] ต้องรองรับตัวชี้ลง เพื่อให้ผู้ใช้สามารถเลื่อน ไปยังตำแหน่งอื่นบนหน้าจอ แล้วชี้ขึ้นบนหน้าจอ ซึ่งช่วยให้ผู้ใช้สะบัดวัตถุบนหน้าจอได้

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.distinct ได้

  • [C-2-1] ต้องประกาศการรองรับ android.hardware.faketouch
  • [C-2-2] ต้องรองรับการติดตามที่ไม่ซ้ำกันของตัวชี้อิสระ 2 ตัวขึ้นไป อินพุต

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.jazzhand ได้

  • [C-3-1] ต้องประกาศการรองรับ android.hardware.faketouch
  • [C-3-2] ต้องรองรับการติดตาม 5 (การติดตามการใช้นิ้วมือ) อย่างน้อย 1 รายการแยกกันโดยสิ้นเชิง

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

7.2.6.1 การแมปปุ่ม

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

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

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

  • [C-2-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.gamepad
ปุ่ม การใช้งาน HID2 ปุ่ม Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
1 0x09 0x0002 KEYCODE_BUTTON_B (97)
x1 0x09 0x0004 KEYCODE_BUTTON_X (99)
ปี1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad1
D-pad ลง1
0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ด้านขวา1
0x01 0x00393 AXIS_HAT_X4
ปุ่มไหล่ซ้าย1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกสติ๊กซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกสติ๊กขวา1 0x09 0x000f KEYCODE_BUTTON_THUMBR (107)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

KeyEvent 1 รายการ

2 การใช้งาน HID ข้างต้นต้องได้รับการประกาศภายในเกม pad CA (0x01 0x0005)

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

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

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

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

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

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

7.3 เซ็นเซอร์

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

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

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

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

  • [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมด โดยใช้ค่าระบบหน่วยสากล (เมตริก) ที่เกี่ยวข้องสำหรับ ประเภทเซ็นเซอร์ตามที่กำหนดไว้ในเอกสาร Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * ตัวอย่าง_time สำหรับกรณีของสตรีมเซ็นเซอร์ที่มี เวลาในการตอบสนองที่ขอสูงสุดคือ 0 มิลลิวินาทีเมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
  • [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายในเวลา 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้สามารถยอมรับได้ มีความแม่นยำเป็น 0
  • [C-1-4] สำหรับ API ใดๆ ที่ระบุไว้ในเอกสารประกอบของ Android SDK ให้เป็น เซ็นเซอร์แบบต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ "ต้อง" เกิดขึ้นอย่างต่อเนื่อง ตัวอย่างข้อมูลเป็นระยะซึ่งควรมี Jitter ต่ำกว่า 3% โดยที่ Jitter หมายถึงค่าเบี่ยงเบนมาตรฐานของผลต่างของค่า Jitter ค่าการประทับเวลาที่มีการรายงานระหว่างเหตุการณ์ที่เกิดต่อเนื่องกัน
  • [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือการปลุกระบบ จากสถานะระงับ
  • [C-1-6] ต้องรายงานเวลาของกิจกรรม ในหน่วยนาโนวินาทีตามที่ระบุไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงถึง เวลาที่เกิดเหตุการณ์และซิงค์ข้อมูลกับ นาฬิกา SystemClock.elapsedRealtimeNano()
  • [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลา ต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
  • เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกิน ผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

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

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

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

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

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

  • ควรใช้เซ็นเซอร์ประเภทเหล่านี้เมื่อ รวมเซ็นเซอร์ทางกายภาพที่ต้องมีดังที่อธิบายไว้ ในประเภทเซ็นเซอร์

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

  • [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในโอเพนซอร์สของ Android เอกสารประกอบเกี่ยวกับเซ็นเซอร์แบบผสม

หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่มี API ที่เกี่ยวข้องสําหรับนักพัฒนาซอฟต์แวร์บุคคลที่สาม และเซ็นเซอร์รายงานเพียง 1 รายการ จากนั้นติดตั้งใช้งานอุปกรณ์

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

หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่รองรับ ข้อมูลเซ็นเซอร์เพิ่มเติม#TYPE_VEC3_CALIBRATION และเซ็นเซอร์แสดงต่อนักพัฒนาซอฟต์แวร์บุคคลที่สาม

  • [C-4-1] ต้องไม่มีการปรับเทียบแบบคงที่ที่กำหนดจากโรงงาน ในข้อมูลที่ให้ไว้

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

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

7.3.1 ตัวตรวจวัดความเร่ง

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

  • [C-SR-1] แนะนําอย่างยิ่งให้ใช้ตัวตรวจวัดความเร่งแบบ 3 แกน

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้และรายงาน TYPE_ACCELEROMETER เซ็นเซอร์
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
  • [C-1-4] ต้องสามารถวัดจากฟรีฟอลต์ได้สูงสุด 4 เท่า Gravity(4g) ขึ้นไปบนแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^ โดยที่ ค่าเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนตามตัวอย่าง เก็บรวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีในอัตราการสุ่มตัวอย่างที่เร็วที่สุด
  • [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้ใช้ TYPE_SIGNIFICANT_MOTION เซ็นเซอร์คอมโพสิต
  • [C-SR-3] ได้รับการแนะนำอย่างยิ่งให้ใช้และรายงาน TYPE_ACCELEROMETER_UNCALIBRATED เซ็นเซอร์ เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android เพื่อให้เป็นไปตามข้อกำหนดดังกล่าว จะสามารถอัปเกรดเป็น รุ่นแพลตฟอร์มในอนาคต ซึ่งอาจ เป็น "ต้องระบุ"
  • ควรใช้ TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER เซ็นเซอร์คอมโพสิต ตามที่อธิบายไว้ ในเอกสาร Android SDK
  • ควรรายงานเหตุการณ์สูงสุด 200 Hz
  • ควรมีความละเอียดอย่างน้อย 16 บิต
  • ควรมีการปรับเทียบขณะใช้งานหากลักษณะเปลี่ยนไป วงจรชีวิตและการชดเชย และรักษาพารามิเตอร์การชดเชย ระหว่างการรีบูตอุปกรณ์
  • ควรมีการชดเชยอุณหภูมิ

หากการใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและ TYPE_SIGNIFICANT_MOTION TYPE_TILT_DETECTOR TYPE_STEP_DETECTOR ใช้เซ็นเซอร์ผสม TYPE_STEP_COUNTER ตัวแล้ว:

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

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

  • [C-3-1] ต้องใช้ TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION เซ็นเซอร์ผสม
  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้ใช้ TYPE_GAME_ROTATION_VECTOR เซ็นเซอร์คอมโพสิต

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

  • [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR

7.3.2 เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 3 แกน

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

  • [C-1-1] ต้องใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD
  • [C-1-2] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์อย่างน้อย 50 Hz
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
  • [C-1-4] ต้องวัดได้ระหว่าง -900 μT ถึง +900 μT ในแต่ละอุปกรณ์ ก่อนความอิ่มตัว
  • [C-1-5] ต้องมีค่าชดเชยสำหรับโลหะแข็งต่ำกว่า 700 μT และควรมี ค่าที่ต่ำกว่า 200 μT โดยการวางเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กให้ห่างจาก สนามแม่เหล็กแบบไดนามิก (กระแสไฟฟ้าขาเข้า) และคงที่ (โดยใช้แม่เหล็ก)
  • [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 μT
  • [C-1-7] ต้องรองรับการปรับเทียบและการชดเชยโลหะแข็งทางออนไลน์ ให้น้ำหนักพิเศษ และเก็บพารามิเตอร์การชดเชยไว้ระหว่างรีบูตอุปกรณ์
  • [C-1-8] ต้องใช้การชดเชยเหล็กอ่อน การปรับเทียบ ทำได้ทั้งในขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
  • [C-1-9] ต้องมีค่าเบี่ยงเบนมาตรฐาน โดยคำนวณตามแกนต่อแกน ตัวอย่างที่เก็บรวบรวมในระยะเวลาอย่างน้อย 3 วินาทีในการสุ่มตัวอย่างเร็วที่สุด ไม่เกิน 1.5 μT ควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 μT
  • [C-1-10] ต้องใช้ TYPE_MAGNETIC_FIELD_UNCALIBRATED เซ็นเซอร์

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

  • [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR

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

  • อาจใช้เซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR

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

  • [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
  • ควรสิ้นเปลืองพลังงานไม่เกิน 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดแบบกลุ่ม ที่ 10 Hz

7.3.3 GPS

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมเครื่องรับ GPS/GNSS

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

  • [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งในอัตราอย่างน้อย 1 Hz เมื่อ ขอผ่าน LocationManager#requestLocationUpdate
  • [C-1-2] ต้องกำหนดสถานที่ในสภาวะที่โล่งได้ (สัญญาณแรง, เส้นทางหลายทางที่ไม่มีประโยชน์, HDOP < 2) ภายใน 10 วินาที (เร็ว เวลาที่แก้ไขครั้งแรก) เมื่อเชื่อมต่อกับความเร็วอินเทอร์เน็ต 0.5 Mbps ขึ้นไป อินเทอร์เน็ต โดยทั่วไปข้อกำหนดนี้จะเป็นไปตามการใช้งาน รูปแบบเทคนิค GPS/GNSS สนับสนุนหรือที่คาดการณ์ไว้ เพื่อลดเวลาล็อกของ GPS/GNSS (ข้อมูลความช่วยเหลือรวมถึงเวลาอ้างอิง ตำแหน่งอ้างอิงและนาฬิกาจำลอง/นาฬิกาจากดาวเทียม)
    • [C-1-6] หลังจากคำนวณตำแหน่งแล้ว อุปกรณ์ การใช้งาน "ต้อง" ระบุตำแหน่ง ในพื้นที่เปิดโล่ง ภายใน 5 วินาที เมื่อคำขอตำแหน่งรีสตาร์ท ภายในไม่เกิน 1 ชั่วโมง การคำนวณตำแหน่งเบื้องต้น แม้ว่าคำขอที่ตามมาจะเป็น เกิดขึ้นโดยไม่เชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากปิดวงจรแล้ว
  • ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่ หรือ เคลื่อนที่โดยมีความเร่งน้อยกว่า 1 เมตรต่อวินาทียกกำลังสอง:

    • [C-1-3] ต้องสามารถระบุสถานที่ตั้งในระยะ 20 เมตร และความเร็ว ภายใน 0.5 เมตรต่อวินาที อย่างน้อย 95% ของเวลาทั้งหมด
    • [C-1-4] ต้องติดตามและรายงานพร้อมๆ กันผ่านทาง GnssStatus.Callback ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวหนึ่ง
    • ควรติดตามดาวเทียมอย่างน้อย 24 ดวงพร้อมกันได้จาก กลุ่มดาวหลายกลุ่ม (เช่น GPS + อย่างน้อย 1 กลุ่มดาว Glonass, Beidou Galileo)
  • [C-SR-2] ได้รับการแนะนำอย่างยิ่งให้ส่ง GPS/GNSS ปกติต่อไป ส่งตำแหน่งผ่าน GNSS Location Provider API ระหว่างโทรศัพท์ฉุกเฉิน การโทร

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากทุกส่วน กลุ่มดาวที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น ของ SBAS

  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้รายงาน AGC และความถี่ของ GNSS การวัดผล

  • [C-SR-5] ได้รับการแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง

  • [C-SR-6] แนะนําอย่างยิ่งให้รายงานการวัด GNSS โดยเร็วที่สุด แม้ว่าจะไม่มีข้อมูลตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม รายงานแล้ว

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ติดตั้งเซ็นเซอร์เครื่องวัดการหมุน

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE
  • [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป
  • [C-1-5] ต้องมีการชดเชยอุณหภูมิ
  • [C-1-6] ต้องมีการปรับเทียบและชดเชยขณะใช้งาน และเก็บรักษา พารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
  • [C-1-7] ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) ค่าความแปรปรวนจะแตกต่างกันไปตาม อัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดโดยค่านี้ กล่าวคือ หากคุณ วัดค่าความแปรปรวนของไจโรด้วยอัตราการสุ่มตัวอย่าง 1 Hz ไม่ควรสูงกว่า 1e-7 rad^2/s^2
  • [C-SR-2] ขอแนะนำให้มีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.01 เรเดียน/วินาที เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • [C-SR-3] ได้รับการแนะนำอย่างยิ่งให้ใช้ TYPE_GYROSCOPE_UNCALIBRATED เซ็นเซอร์
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้มีความละเอียด 16 บิตขึ้นไป
  • ควรรายงานเหตุการณ์สูงสุด 200 Hz

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

  • [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR

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

  • [C-3-1] ต้องใช้ TYPE_GRAVITY และ เซ็นเซอร์ผสม TYPE_LINEAR_ACCELERATION ตัว
  • [C-SR-5] ได้รับการแนะนำอย่างยิ่งให้ใช้ TYPE_GAME_ROTATION_VECTOR เซ็นเซอร์คอมโพสิต

7.3.5 บารอมิเตอร์

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

  • [C-SR-1] แนะนำให้ใส่บารอมิเตอร์ (ความกดอากาศแวดล้อม เซ็นเซอร์)

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

  • [C-1-1] ต้องใช้และรายงานเซ็นเซอร์ TYPE_PRESSURE
  • [C-1-2] ต้องสามารถส่งเหตุการณ์ในระดับ 5 Hz หรือสูงกว่า
  • [C-1-3] ต้องมีการชดเชยอุณหภูมิ
  • [C-SR-2] แนะนำอย่างยิ่งให้สามารถรายงานการวัดความดันใน อยู่ในช่วง 300hPa ถึง 1100hPa
  • ควรมีความแม่นยำสัมบูรณ์ที่ 1hPa
  • ควรมีความแม่นยำสัมพัทธ์ที่ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความแม่นยำประมาณ 1 ม. จากการเปลี่ยนแปลงประมาณ 200 ม. ที่ระดับน้ำทะเล)

7.3.6 เทอร์โมมิเตอร์

หากการใช้งานอุปกรณ์มีเทอร์โมมิเตอร์โดยรอบ (เซ็นเซอร์อุณหภูมิ) ดังนี้

  • [C-1-1] ต้องนิยามคำว่า SENSOR_TYPE_AMBIENT_TEMPERATURE สำหรับเซ็นเซอร์อุณหภูมิแวดล้อมและเซ็นเซอร์ต้องวัดสภาพแวดล้อม (ห้อง/ห้องโดยสารยานพาหนะ) อุณหภูมิที่ผู้ใช้โต้ตอบกับ เป็นองศาเซลเซียส

การติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์เทอร์โมมิเตอร์ที่วัดค่า นอกจากอุณหภูมิแวดล้อม เช่น อุณหภูมิของ CPU จะมีลักษณะดังนี้

หากอุปกรณ์มีเซ็นเซอร์สำหรับตรวจสอบอุณหภูมิผิวหนัง ให้ดำเนินการดังนี้

7.3.7 โฟโต้มิเตอร์

  • การใช้งานอุปกรณ์อาจมีโฟโต้มิเตอร์ (เซ็นเซอร์แสงแวดล้อม)

7.3.8 พร็อกซิมิตีเซ็นเซอร์

  • การใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์และรายงานเฉพาะ ค่าไบนารีที่อ่านได้แบบ "ใกล้" หรือ "ไกล"

  • [C-1-1] ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกันกับ บนหน้าจอ กล่าวคือ พร็อกซิมิตีเซ็นเซอร์จะต้องอยู่ในแนวสำหรับตรวจจับวัตถุ ใกล้กับหน้าจอ เนื่องจากจุดประสงค์หลักของเซ็นเซอร์ประเภทนี้คือ ตรวจพบโทรศัพท์ที่ผู้ใช้ใช้งานอยู่ หากการติดตั้งใช้งานอุปกรณ์มี พร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวแบบอื่นๆ ต้องไม่สามารถเข้าถึงได้ ผ่าน API นี้
  • [C-1-2] ต้องมีความแม่นยำอย่างน้อย 1 บิต
  • [C-1-3] ต้องใช้ 0 เซนติเมตรเท่ากับค่าใกล้เคียงและ 5 เซนติเมตรเป็นค่า อ่านไกล
  • [C-1-4] ต้องรายงานช่วงและความละเอียดสูงสุดเป็น 5

7.3.9 เซ็นเซอร์ความแม่นยำสูง

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

  • [C-1-1] ต้องระบุความสามารถผ่านทาง แฟล็กฟีเจอร์ android.hardware.sensor.hifi_sensors

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

  • [C-2-1] ต้องมีเซ็นเซอร์ TYPE_ACCELEROMETER ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง -8 ก. ถึง +8 ก. เป็นอย่างน้อย และ แนะนำอย่างยิ่งให้มีช่วงการวัดตั้งแต่ -16 ก. เป็นอย่างน้อย และ +16g
    • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
    • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควร รองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 400 μg/ทั้งหมดใน{/9}
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีการบัฟเฟอร์ สามารถตรวจจับเหตุการณ์เซ็นเซอร์อย่างน้อย 3,000 เหตุการณ์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
    • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB ที่ ความถี่อย่างน้อย 80% ของ Nyquist และสเปกตรัมของไวท์นอยส์ในส่วนนี้ แบนด์วิดท์
    • ควรมีความเร่งเดินแบบสุ่มน้อยกว่า 30 μg ¡Hz ทดสอบที่ อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
    • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.03%/C°
    • ควรมีความไวข้ามแกนของ < 2.5 % และความแปรปรวนของ ความไวข้ามแกน < 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
  • [C-2-2] ต้องมี TYPE_ACCELEROMETER_UNCALIBRATED ที่เหมือนกัน ตามข้อกำหนดด้านคุณภาพเป็น TYPE_ACCELEROMETER

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
    • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควร รองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
    • [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB ที่ ความถี่อย่างน้อย 80% ของ Nyquist และสเปกตรัมของไวท์นอยส์ในส่วนนี้ แบนด์วิดท์
    • ควรมีอัตราการเดินแบบสุ่มน้อยกว่า 0.001 °/s ¡Hz ทดสอบที่ห้อง อุณหภูมิ
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
    • ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
    • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
    • ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
    • ควรมีข้อผิดพลาดในการปรับน้อยกว่า 0.002 rad/วินาทีใน ช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่
    • ควรมีความไวต่อ g น้อยกว่า 0.1°/s/g
    • ควรมีความไวข้ามแกนของ < 4.0 % และความไวข้ามแกน รูปแบบ < 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
  • [C-2-4] ต้องมี TYPE_GYROSCOPE_UNCALIBRATED ที่มีคุณภาพเท่ากัน ข้อกำหนดในฐานะTYPE_GYROSCOPE

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
    • ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
  • [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีคุณภาพเท่ากัน เป็น TYPE_GEOMAGNETIC_FIELD และนอกจากนี้

    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีการบัฟเฟอร์ สามารถตรวจจับเหตุการณ์เซ็นเซอร์อย่างน้อย 600 เหตุการณ์
    • [C-SR-3] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึง อย่างน้อย 10 Hz เมื่ออัตราการรายงานเป็น 50 Hz หรือสูงกว่า
  • [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีการบัฟเฟอร์ สามารถตรวจจับเหตุการณ์เซ็นเซอร์อย่างน้อย 300 เหตุการณ์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 2 mW
  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR

  • [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่ง

    • ต้องมีการใช้พลังงานไม่น้อยกว่า 0.5 mW เมื่ออุปกรณ์ คงที่และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่ง

    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีการบัฟเฟอร์ สามารถตรวจจับเหตุการณ์เซ็นเซอร์อย่างน้อย 100 เหตุการณ์
    • ต้องมีการใช้พลังงานไม่น้อยกว่า 0.5 mW เมื่ออุปกรณ์ คงที่และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
  • [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่ง

    • ต้องมีการใช้พลังงานไม่น้อยกว่า 0.5 mW เมื่ออุปกรณ์ คงที่และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่ง

    • ต้องมีการใช้พลังงานไม่น้อยกว่า 0.5 mW เมื่ออุปกรณ์ คงที่และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-13] การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดย ตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กต้องอยู่ภายใน 2.5 มิลลิวินาที ระหว่างกัน การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดย ตัวตรวจวัดความเร่งและเครื่องวัดการหมุนควรอยู่ในช่วง 0.25 มิลลิวินาทีของตัวตรวจวัดความเร่ง อื่นๆ

  • [C-2-14] ต้องมีการประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุนในเวลาเดียวกัน เป็นระบบย่อยของกล้อง และมีข้อผิดพลาดภายใน 1 มิลลิวินาที

  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจาก เวลาที่ข้อมูลพร้อมใช้งานบนเซ็นเซอร์ทางกายภาพใดๆ ข้างต้น ในแอปพลิเคชัน

  • [C-2-16] ต้องไม่มีการใช้พลังงานสูงกว่า 0.5 มิลลิวัตต์ เมื่ออุปกรณ์อยู่นิ่งและ 2.0 mW ขณะอุปกรณ์เคลื่อนที่ เมื่อเปิดใช้งานเซ็นเซอร์ต่อไปนี้ร่วมกัน

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมี ต้องมี ความสามารถในการบัฟเฟอร์ขั้นต่ำอยู่ที่ 100 เหตุการณ์เซ็นเซอร์

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

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

  • [C-3-1] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและโดยตรงอย่างถูกต้อง ระดับการรายงานผ่าน isDirectChannelTypeSupported และ getHighestDirectReportRateLevel API
  • [C-3-2] ต้องรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์อย่างน้อย 1 ใน 2 ประเภท สำหรับเซ็นเซอร์ทั้งหมดที่ประกาศว่ารองรับช่องสัญญาณโดยตรงของเซ็นเซอร์
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับ เซ็นเซอร์ (ตัวแปรที่ไม่ใช่การปลุกระบบ) ในประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

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

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

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

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

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

หากการใช้งานอุปกรณ์ทำให้บุคคลที่สามใช้เซ็นเซอร์ไบโอเมตริกได้ แอปพลิเคชันผ่าน android.hardware.biometrics.BiometricManager android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL ดังนี้

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องมีอัตราการยอมรับที่เป็นเท็จน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN ที่เดายาก หรือรหัสผ่าน และแจกแจงความเสี่ยงที่จะเปิดใช้อย่างชัดเจน หาก อัตราการยอมรับการปลอมแปลงและการหลอกลวงสูงกว่า 7% ตามที่วัดโดย โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-9] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากการทดลองที่ผิดพลาดไม่เกินยี่สิบครั้ง และไม่ การยืนยันข้อมูลไบโอเมตริกน้อยกว่า 90 วินาที โดยที่ การทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ที่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-4] แนะนำอย่างยิ่งให้ลดจำนวนการทดลองที่ผิดพลาดทั้งหมด สำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุใน [C-1-9] หากการปลอมแปลงและผู้แอบอ้าง อัตราการยอมรับสูงกว่า 7% เมื่อวัดด้วยข้อมูลไบโอเมตริกของ Android ทดสอบโปรโตคอล
  • [C-1-3] ต้องพยายามจำกัดจำนวนอัตราสำหรับการยืนยันข้อมูลไบโอเมตริก โดยที่ การทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ที่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-5] แนะนำอย่างยิ่งให้ลองจำกัดอัตราคำขออย่างน้อย 1 ครั้ง 30 วินาทีหลังจากการทดลองที่ผิดพลาด 5 ครั้งสำหรับการยืนยันข้อมูลไบโอเมตริกสำหรับ จำนวนสูงสุดของการทดลองที่ผิดพลาดต่อ [C-1-9] - โดยที่การทดลองที่เป็นเท็จคือ หนึ่งครั้งที่มี คุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับ ข้อมูลไบโอเมตริกที่ลงทะเบียน
  • [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้กำหนดตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE
  • [C-1-10] ต้องปิดใช้ข้อมูลไบโอเมตริกเมื่อการย้อนกลับการตรวจสอบสิทธิ์หลักมี เกิดขึ้นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วนที่ 9.11
  • [C-1-4] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่ได้สร้าง ห่วงโซ่ความไว้วางใจโดยให้ผู้ใช้ยืนยันว่ามีอยู่แล้วหรือเพิ่มอุปกรณ์ใหม่ ข้อมูลเข้าสู่ระบบ (PIN/รูปแบบ/รหัสผ่าน) ที่รักษาความปลอดภัยโดย TEE Android Open การนำโปรเจ็กต์แหล่งที่มามาใช้จะทำให้มีกลไกในกรอบการทำงาน ดังนั้น
  • [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ของผู้ใช้ออกทั้งหมด เมื่อมีการลบบัญชีของผู้ใช้ (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
  • [C-1-6] ต้องให้เกียรติธงแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS ) อื่นๆ
  • [C-1-7] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน): ก) 1 ครั้งทุก 24 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ต่างๆ เปิดตัวด้วย Android เวอร์ชัน 9 ขึ้นไปหรือ b) 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่า สำหรับอุปกรณ์ที่อัปเกรดจาก Android 8 หรือเก่ากว่า
  • [C-1-8] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หรือข้อมูลไบโอเมตริกคลาส 3 (STRONG) ที่อยู่หลังหนึ่งใน ดังต่อไปนี้:

    • เมื่อไม่มีความเคลื่อนไหวเป็นเวลา 4 ชั่วโมง หรือ
    • ตรวจสอบสิทธิ์ข้อมูลไบโอเมตริกไม่สำเร็จ 3 ครั้ง

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

  • [C-SR-8] ได้รับการแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์

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

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

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