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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์พกพาระบุว่ารองรับการแสดงช่วงไดนามิกกว้างถึง Configuration.isScreenHdr() ระบบจะดำเนินการดังนี้

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

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

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

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

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

  • [7.1.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 อย่างน้อย 1 จอ
  • [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] ต้องรายงานอัตรา Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีในวินาทีที่ 2 เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 9% ต่อเวลาอย่างน้อย 9% ต่อวินาที

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.6.1/H-1-1] ต้องรองรับ ABI แบบ 32 บิตเท่านั้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [3.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] โซนการจดจำท่าทางสัมผัสสำหรับฟังก์ชัน Home ควรสูงจากด้านล่างของหน้าจอไม่เกิน 32 dp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคำที่นิยมสามารถส่งข้อมูลไปยัง ระบบหรือ ContentCaptureService เท่านั้น
  • [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการจะส่งได้เฉพาะข้อมูลเสียงไมค์หรือข้อมูลที่ได้มาจากเซิร์ฟเวอร์ของระบบผ่านทาง API ของ HotwordDetectionService หรือไปยัง ContentCaptureService ผ่านทาง API ของ ContentCaptureManager
  • [9.8/H-1-3] ต้องไม่ให้เสียงไมโครโฟนที่นานกว่า 30 วินาทีสำหรับคำขอที่ทริกเกอร์ด้วยฮาร์ดแวร์แต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-4] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับคำขอแต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-5] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีแก่บริการโต้ตอบด้วยเสียงหรือเอนทิตีที่คล้ายกัน
  • [9.8/H-1-6] ต้องไม่ส่งข้อมูลเกิน 100 ไบต์ออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์ของคำที่นิยมแต่ละรายการสำเร็จ
  • [9.8/H-1-7] ต้องไม่ส่งข้อมูลมากกว่า 5 บิตออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์ของคำสั่งให้ดำเนินการเชิงลบแต่ละรายการ
  • [9.8/H-1-8] ต้องอนุญาตเฉพาะการส่งข้อมูลออกจากบริการตรวจหาคำที่นิยมในคำขอตรวจสอบคำสั่งให้ดำเนินการจากเซิร์ฟเวอร์ระบบเท่านั้น
  • [9.8/H-1-9] ต้องไม่อนุญาตแอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจจับคำสั่งลัด
  • [9.8/H-1-10] ต้องไม่แสดงข้อมูลเชิงปริมาณใน UI เกี่ยวกับการใช้งานไมค์ในบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-11] ต้องบันทึกจำนวนไบต์ที่รวมอยู่ในการส่งข้อมูลทุกครั้งจากบริการตรวจจับคำสั่งให้ดำเนินการ เพื่อให้นักวิจัยความปลอดภัยสามารถตรวจสอบได้
  • [9.8/H-1-12] ต้องรองรับโหมดแก้ไขข้อบกพร่องที่บันทึกเนื้อหาดิบของการส่งข้อมูลทุกรายการจากบริการตรวจจับคำสั่งให้ดำเนินการ เพื่อให้นักวิจัยด้านความปลอดภัยสามารถตรวจสอบได้
  • [9.8/H-1-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 แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง
    • [6.1/H-0-3]* ไบนารี Perfetto ต้องยอมรับเป็น ป้อนการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [6.1/H-0-4]* ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [6.1/H-0-5]* ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto ผ่าน Perfetto Binary
    • [6.1/H-0-6]* ต้องเปิดใช้ Daemon ที่ติดตาม Perfetto โดยค่าเริ่มต้น (คุณสมบัติของระบบ persist.traced.enable)

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

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

2.2.7.1 สื่อ

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

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

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

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

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

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

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

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

2.3.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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 เฟรมต่อวินาที ด้วย High Profile ระดับ 4.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3 ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.3 ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ 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] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้าถึงข้อความ (MAP)

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

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

กล้องมุมมองภายนอกคือกล้องที่ใช้ถ่ายภาพทิวทัศน์นอกตัวอุปกรณ์ เช่น กล้องติดรถยนต์

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

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

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

  • [7.5/A-1-1] ต้องไม่มีกล้องมุมมองภายนอกที่เข้าถึงได้ผ่าน Android Camera API เว้นแต่ว่าจะเป็นไปตามข้อกำหนดหลักของกล้อง
  • [7.5/A-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าหมุนหรือมิเรอร์ภาพตัวอย่างจากกล้อง
  • [7.5.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] ควรจัดรูปแบบพาร์ติชันข้อมูล เพื่อเพิ่มประสิทธิภาพและอายุใช้งานของพื้นที่เก็บข้อมูล Flash เช่น ใช้ระบบไฟล์ 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 มัลติมีเดีย

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

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

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

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

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

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

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

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

2.5.3 ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1 ฮาร์ดแวร์

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

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

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

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

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

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

หากอุปกรณ์แท็บเล็ตมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

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

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

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

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

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

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

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

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

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

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

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

2.6.2 ซอฟต์แวร์

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

3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1. ส่วนขยาย Android

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

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

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

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

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

3.1.2. ไลบรารี Android

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

  • [C-0-1] ตารางด้านล่างระบุข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การใช้งานอุปกรณ์จะต้องสอดคล้อง เพื่อให้ได้ค่าที่มีความหมายและสอดคล้องกันตลอดการใช้งานอุปกรณ์
พารามิเตอร์ รายละเอียด
VERSION.RELEASE เวอร์ชันของระบบ Android ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ในสตริงเวอร์ชันที่ได้รับอนุญาตสำหรับ Android 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)/$(ผลิตภัณฑ์)/
$(อุปกรณ์):$(VERSION.RELEASE)/$(รหัส)/$(VERSION.INCREMENTAL):$(ประเภท)/$(แท็ก)

เช่น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รายงาน 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

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

  • [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 สิ่งที่จะเกิดขึ้นมีดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์รายงานการรองรับ ABI ของ armeabi-v7a สำหรับแอปที่ใช้ ABI นี้ การดำเนินการดังกล่าวจะมีผลดังนี้

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ทำให้การใช้งาน API android.webkit.Webview เสร็จสมบูรณ์ จะมีผลดังนี้

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

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML เช่น Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของ Intent มาตรฐาน
  • [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายขององค์ประกอบระบบบางประเภท (เช่น บริการ กิจกรรม ผู้ให้บริการเนื้อหา ฯลฯ)
  • [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
  • อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันในเบื้องหลัง กล่าวอย่างเจาะจงคือ สําหรับแอปพื้นหลัง
    • [C-0-4] ผู้ใช้ต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก GnssMeasurement และ GnssNavigationMessage
    • [C-0-5] จะต้องจำกัดความถี่ของการอัปเดตที่ให้ไว้กับแอปผ่านคลาส API LocationManager หรือเมธอด WifiManager.startScan()
    • [C-0-6] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปต้องไม่ ลงทะเบียน Broadcast Receiver สำหรับการออกอากาศโดยปริยายของ Intent มาตรฐานของแอปในไฟล์ Manifest ของแอป เว้นแต่ Intent การเผยแพร่ต้องใช้สิทธิ์ "signature" หรือ "signatureOrSystem" protectionLevel หรืออยู่ในรายการการยกเว้น
    • [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปจะต้องหยุดบริการในเบื้องหลังของแอป เช่นเดียวกับกรณีที่แอปเรียกใช้เมธอด stopSelf() ของบริการ เว้นแต่แอปจะอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่ผู้ใช้มองเห็นได้
    • [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป
  • [C-0-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 UsageStats#getLastTimeAnyComponentd() ใหม่
  • [C-1-3] ต้องใช้ข้อจำกัดที่มีผลต่อผู้ใช้อุปกรณ์ทุกรายเมื่อมีหลักฐานว่าผู้ใช้ไม่มีการใช้แพ็กเกจเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้กำหนดระยะเวลานี้อย่างน้อย 1 เดือน
  • [C-1-4] ต้องไม่แสดงผลแอปไม่ให้ตอบสนองต่อ Intent ของกิจกรรม การเชื่อมโยงบริการ คำขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่อาจไม่เหมาะสม

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

3.6 เนมสเปซ API

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.4 Assist API

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

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

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

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

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

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

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

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

3.8.6 ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.12 ตำแหน่ง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] ต้องรองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากซึ่งเป็นไปตามข้อกำหนดต่อไปนี้ในการให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการเท่านั้น
    • การนำอุปกรณ์ไปใช้งานต้องเป็นไปตามจุดประสงค์ของ DevicePolicyManager.ACTION_SET_NEW_PASSWORD และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ
    • ข้อมูลเข้าสู่ระบบในหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้พื้นที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกันกับโปรไฟล์หลักตามที่บันทึกไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
    • นโยบายรหัสผ่านของ DPC ต้องใช้กับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการเท่านั้น เว้นแต่ว่าจะมีการเรียกอินสแตนซ์ DevicePolicyManager ที่แสดงผลโดย getParentProfileInstance
  • เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนว่ากำลังอยู่ในสาย และการแจ้งเตือนสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อดังกล่าวควรมีป้ายติด ป้ายเดียวกับที่ใช้ระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ

3.9.3 การสนับสนุนผู้ใช้ที่มีการจัดการ

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

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

หากการใช้งานอุปกรณ์ประกาศ android.software.device_admin และให้ค่าตอบแทนผู้ใช้ในอุปกรณ์ในการเพิ่มผู้ใช้รองเพิ่มเติม เงื่อนไขจะมีลักษณะดังนี้

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

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

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

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

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

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

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

3.11 Text-to-Speech

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

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

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

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

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

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

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

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

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

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

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

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

3.14 UI สื่อ

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

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

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

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

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

3.15 Instant Apps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RawContacts มีการ "เชื่อมโยง" หรือ "จัดเก็บไว้ใน" บัญชี เมื่อคอลัมน์ ACCOUNT_NAME และ ACCOUNT_TYPE ข้อมูลรายชื่อติดต่อดิบตรงกับ Account.name และ Account.type ที่เกี่ยวข้อง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)

  • [C-3-1] ความดังและข้อมูลเมตาของ DRC ต้องตีความและนำไปใช้ตาม MPEG-D DRC Dynamic Range Control Profile Level 1
  • [C-3-2] ตัวถอดรหัสต้องทำงานตามการกำหนดค่าที่ตั้งไว้ด้วยคีย์ android.media.MediaFormat ต่อไปนี้ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_DRC_EFFECT_TYPE

ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2:

  • อาจรองรับความดังและการควบคุมช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิกแบบ ISO/IEC 23003-4

หากระบบรองรับ ISO/IEC 23003-4 และหากมีทั้งข้อมูลเมตา ISO/IEC 23003-4 และ ISO/IEC 14496-3 ในบิตสตรีมที่ถอดรหัสแล้ว ให้ทำดังนี้

  • ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสำคัญเหนือกว่า

ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุต:

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

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 - Wide Band Speech Codec 3GPP (.3gp)
FLAC สำหรับทั้งโปรแกรมเปลี่ยนไฟล์และเครื่องถอดรหัส: ต้องมีการรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย รองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง 24 บิตของ FLAC ต้องใช้งานได้กับการกำหนดค่าเสียงแบบลอย
  • 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 บิต เครื่องมือแยก WAVE ต้องรองรับ PCM เชิงเส้น 16 บิต, 24 บิต, 32 บิต และลอยตัว 32 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อัตราการสุ่มตัวอย่างต้องรองรับตั้งแต่ 8 kHz ถึง 192 kHz WAVE (.wav)
Opus การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz
การเข้ารหัส: รองรับเนื้อหาโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 1400, 1200 และ 1200 Hz
  • 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] ต้องรองรับรูปแบบสี YUV420 8:8:8 อย่างน้อย 1 รูปแบบ: COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) ขอแนะนำให้รองรับทั้ง 2 รูปแบบ

5.1.7 ตัวแปลงรหัสวิดีโอ

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

หากการใช้งานอุปกรณ์มีตัวถอดรหัสวิดีโอหรือโปรแกรมเปลี่ยนไฟล์

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

  • [C-1-2] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 8:8:8 (COLOR_FormatYUV420Flexible) ถึง CodecCapabilities

  • [C-1-3] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบระนาบหรือแบบกึ่งฉากอย่างน้อย 1 รายการ: COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) เราขอแนะนำเป็นอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

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

  • [C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง) ต้องรองรับเอาต์พุตในรูปแบบ 8 บิตที่เทียบเท่ากันหากแอปพลิเคชันขอ ค่านี้ต้องแสดงโดยการรองรับรูปแบบสี YUV420 8:8:8 ผ่าน android.media.MediaCodecInfo

การติดตั้งใช้งานอุปกรณ์ที่โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities จะมีผลดังนี้

  • [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ HDR

หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh ในชั้นเรียน MediaCodecInfo.CodecCapabilities การดำเนินการต่อไปนี้

  • [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10 - 60 เฟรมและทำงานอย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้

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

  • [C-4-1] ต้องใช้รูปแบบสีที่เพิ่มประสิทธิภาพสำหรับจอแสดงผลของฮาร์ดแวร์โดยค่าเริ่มต้น หากกำหนดค่าโดยใช้เอาต์พุต Surface
  • [C-4-2] ต้องมีค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพสำหรับการอ่านของ CPU หากกำหนดค่าไม่ให้ใช้เอาต์พุต Surface

5.1.8 รายการตัวแปลงรหัสวิดีโอ

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

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

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

หากอุปกรณ์รองรับตัวแปลงรหัสตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้

  • [C-3-1] ต้องรวมตัวแปลงรหัสของซอฟต์แวร์ Codec 2.0 ที่เกี่ยวข้องจาก โครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและสื่อแต่ละประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
  • [C-3-2] ต้องจัดเก็บตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ในกระบวนการของตัวแปลงสัญญาณซอฟต์แวร์ตามที่ระบุไว้ในโครงการโอเพนซอร์ส Android เพื่อให้สามารถให้สิทธิ์เข้าถึงตัวแปลงรหัสซอฟต์แวร์ได้อย่างแคบลง
  • [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android" ต้องใช้ซอร์สโค้ดของ โครงการโอเพนซอร์ส Android

5.1.10 การจำแนกลักษณะของตัวแปลงรหัสสื่อ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ ตัวแปลงสัญญาณต่อไปนี้

  • [C-1-1] ต้องส่งค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่าน API ของ MediaCodecInfo

โดยเฉพาะอย่างยิ่งในเรื่องต่อไปนี้

  • [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อ OMX IL
  • [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ API ของ Codec 2.0 และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของ Codec 2.0 สำหรับ Android
  • [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." หรือ "c2.android" ต้องไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นการเร่งฮาร์ดแวร์
  • [C-1-5] ตัวแปลงรหัสที่ทำงานในกระบวนการของตัวแปลงรหัส (ผู้ให้บริการหรือระบบ) ที่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากผู้จัดสรรหน่วยความจำและผู้ทำแผนที่ต้อง ไม่มีลักษณะเป็นเฉพาะซอฟต์แวร์เท่านั้น
  • [C-1-6] ตัวแปลงรหัสที่ไม่มีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android หรือไม่ได้อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องอยู่ในรูปแบบผู้ให้บริการ
  • [C-1-7] ตัวแปลงรหัสที่ใช้การเร่งฮาร์ดแวร์จะต้องมีลักษณะ เป็นเร่งฮาร์ดแวร์
  • [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด เช่น ตัวแปลงรหัสที่ชื่อว่า "ตัวถอดรหัส" ต้องรองรับการถอดรหัส ส่วนตัวแปลงรหัสที่ชื่อว่า "โปรแกรมเปลี่ยนไฟล์" ต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อที่มีรูปแบบสื่อต้องรองรับรูปแบบเหล่านั้น

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

  • [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ
  • 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) บนหน้าต่างเลื่อน 2 หน้าต่าง
  • ไม่ควรเกิน 100% ของอัตราบิตในหน้าต่างเลื่อน 1 วินาที

หากการใช้งานอุปกรณ์มีหน้าจอแสดงผลแบบฝังที่มีความยาวตามแนวทแยงอย่างน้อย 2.5 นิ้ว หรือมีพอร์ตเอาต์พุตวิดีโอหรือประกาศการรองรับกล้องผ่านแฟล็กฟีเจอร์ android.hardware.camera.any การดำเนินการเหล่านี้จะมีผลดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ H.264, VP8, VP9 หรือ HEVC ใดๆ ก็ตามและทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้

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

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

  • ควรสนับสนุนอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่สนับสนุน

หากการใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์สำหรับวิดีโอหรือรูปภาพที่เร่งการแสดงผลด้วยฮาร์ดแวร์ และรองรับกล้องฮาร์ดแวร์ที่ติดหรือเชื่อมต่อได้อย่างน้อย 1 ตัวที่เปิดเผยผ่าน API ของ android.camera

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

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

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

5.2.1 H.263

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

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

5.2.2 H.264

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

  • [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 แต่การรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS กับอุปกรณ์ Android อื่นๆ เพื่อคงการใช้งานร่วมกับอุปกรณ์ Android อื่นๆ
  • [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
  • ควรรองรับโปรไฟล์หลักระดับ 4
  • ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้

หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน API ของสื่อ การดำเนินการต่อไปนี้

  • [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 240 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 20 FPS 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3 VP8

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

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

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

  • [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4 VP9

หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้

  • [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
  • [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
  • [C-1-3] ต้องสร้างข้อมูล CodecPrivate
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
  • เราขอแนะนำเป็นอย่างยิ่งว่า [C-SR-1] จะรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

หากการใช้อุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน API สื่อ

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

5.2.5 H.265

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
  • ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
  • เราขอแนะนำเป็นอย่างยิ่งว่า [C-SR-1] จะรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps
อัตราบิตของวิดีโอ 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3 การถอดรหัสวิดีโอ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องรองรับความละเอียดของวิดีโอแบบไดนามิกและการเปลี่ยนอัตราเฟรมผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดในแบบเรียลไทม์และสูงสุดถึงความละเอียดสูงสุดที่ตัวแปลงรหัสแต่ละตัวบนอุปกรณ์รองรับ

5.3.1 MPEG-2

หากการติดตั้งอุปกรณ์รองรับตัวถอดรหัส MPEG-2 การดำเนินการต่อไปนี้

  • [C-1-1] ต้องสนับสนุนระดับสูงของโปรไฟล์หลัก

5.3.2 H.263

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

  • [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 30 และระดับ 45

5.3.3 MPEG-4

หากอุปกรณ์มีตัวถอดรหัส MPEG-4 สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-1-1] ต้องรองรับ Simple Profile ระดับ 3

5.3.4 H.264

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน ระบบรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) ไม่บังคับ
  • [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงอยู่ในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์พื้นฐาน และโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
  • ควรสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้

หากความสูงที่เมธอด Display.getSupportedModes() รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ การใช้งานอุปกรณ์

  • [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในตารางต่อไปนี้
  • [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 240 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 60 FPS 30 FPS (60 FPS ทีวี)
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5 H.265 (HEVC)

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

  • [C-1-1] ต้องสนับสนุนระดับหลักของโปรไฟล์หลักระดับ 3 และโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
  • [C-1-2] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีตัวถอดรหัสฮาร์ดแวร์

หากความสูงที่เมธอด Display.getSupportedModes() รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

  • [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส H.265 หรือ VP9 ของโปรไฟล์ 720, 1080 และ UHD อย่างน้อย 1 รายการ
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 352 x 288 พิกเซล 720 x 480 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30/60 FPS (60 fps ทีวีที่มีการถอดรหัสฮาร์ดแวร์ H.265) 60 FPS
อัตราบิตของวิดีโอ 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

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

5.3.6 VP8

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

  • [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
  • ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่ตรงตามข้อกำหนด
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้

หากความสูงตามที่เมธอด Display.getSupportedModes() รายงาน เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

  • [C-2-1] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในตารางต่อไปนี้
  • [C-2-2] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 FPS (60 FPS ทีวี) 30 (60 FPSทีวี)
อัตราบิตของวิดีโอ 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7 VP9

หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้

  • [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
  • ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้

หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์

  • [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้

หากความสูงที่เมธอด Display.getSupportedModes() รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

  • [C-3-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส VP9 หรือ H.265 อย่างน้อย 1 รายการของโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ 320 x 180 พิกเซล 640 x 360 พิกเซล 1280 x 720 พิกเซล 1920 x 1080 พิกเซล 3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ 30 fps 30 fps 30 fps 30 fps (60 fpsทีวีที่มีการถอดรหัสฮาร์ดแวร์ VP9) 60 FPS
อัตราบิตของวิดีโอ 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2 หรือ VP9Profile3 ผ่าน API สื่อ "CodecProfileLevel"

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

หากการนำอุปกรณ์ไปใช้งานอ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) ผ่าน API สื่อ ให้ทำดังนี้

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

5.3.8 Dolby Vision

หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION ระบบจะดำเนินการดังต่อไปนี้

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

5.3.9 AV1

หากอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำงานดังนี้

  • [C-1-1] ต้องรองรับโปรไฟล์ 0 ที่รวมเนื้อหาแบบ 10 บิต

5.4 การบันทึกเสียง

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

5.4.1 การบันทึกเสียงและข้อมูลไมโครโฟนแบบข้อมูลดิบ

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

  • [C-1-1] ต้องอนุญาตการบันทึกเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้

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

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 อินพุตแบบเชิงเส้นที่ช่วง -18 dB ถึง +12 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน
  • ควรบันทึกสตรีมเสียงการจดจำเสียงที่มีการบิดเบี้ยว แบบฮาร์โมนิกทั้งหมด (THD) ต่ำกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน

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

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

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

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

หากการใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output และ android.hardware.microphone ระบบจะดำเนินการต่อไปนี้

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

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

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

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

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

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

5.4.5 จับภาพพร้อมกัน

หากใช้อุปกรณ์ประกาศ android.hardware.microphone ก็ต้องใช้การจับภาพพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้

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

5.4.6 ระดับเสียงไมโครโฟน

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

  • ควรแสดงลักษณะเฉพาะของแอมพลิจูดกับความถี่แบบแบนราบโดยประมาณในช่วงความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวและทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
  • ควรตั้งค่าความไวของอินพุตเสียงให้แหล่งสัญญาณเสียงไซนัสอยัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB ตอบสนองด้วย RMS ที่ 2500 สำหรับตัวอย่างเสียง 16 บิต (หรือ -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 ชุด API ที่เกี่ยวข้องกับ PCM OpenSL ES API ภายใน Android NDK
  • API เสียงดั้งเดิมของเสียง ชุดของ AAudio API ภายใน Android NDK
  • การประทับเวลา คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง ดู AudioTimestamp เพิ่มเติม
  • glitch มีการขัดจังหวะชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง โดยทั่วไปจะเกิดจากการบัฟเฟอร์น้อยของเอาต์พุต บัฟเฟอร์มากเกินไปสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนดิจิทัลหรือแอนะล็อก
  • หมายถึงส่วนเบี่ยงเบนสัมบูรณ์ ค่าเฉลี่ยของค่าสัมบูรณ์ของค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า
  • เวลาในการตอบสนองแบบแตะเพื่อโทนเสียง ช่วงเวลาระหว่างที่แตะหน้าจอจนถึงเวลาที่ได้ยินเสียง ที่เกิดจากการแตะนั้นได้ยินในลำโพง

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

  • [C-1-1] การประทับเวลาเอาต์พุตที่ได้จาก AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำที่ +/- 2 มิลลิวินาที
  • [C-1-2] เวลาในการตอบสนองแบบ Cold 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 เอาต์พุตบนอุปกรณ์เอาต์พุตเสียงอย่างน้อย 1 เครื่องที่รองรับ ระบบจะดำเนินการดังต่อไปนี้

  • [C-SR-5] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์ android.hardware.audio.low_latency
  • [C-SR-6] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
  • [C-SR-7] ขอแนะนำอย่างยิ่งให้ตรวจสอบให้แน่ใจว่าสำหรับสตรีมที่แสดงผล AAUDIO_PERFORMANCE_MODE_LOW_LATENCY จาก AAudioStream_getPerformanceMode() ค่าที่ AAudioStream_getFramesPerBurst() แสดงผลน้อยกว่าหรือเท่ากับค่าที่ android.media.AudioManager.getProperty(String) แสดงผลสำหรับคีย์พร็อพเพอร์ตี้ AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER

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

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

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

  • [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลให้เป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงค่าเบี่ยงเบนไปจากค่าที่ถูกต้อง
  • [C-3-2] เวลาในการตอบสนองแบบ Cold 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,
และ MPEG-2 ในหัวข้อ 5.1.8

ตัวแปลงสัญญาณเสียง:

  • AAC
ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรได้ในส่วนที่ 5.1.3
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 ISO 13818-7 ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.1
WebVTT WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์ ข้อมูลอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC RFC 6184 ดูรายละเอียดเกี่ยวกับ H264 AVC ในหัวข้อ 5.1.8
MP4A-ลาตินอเมริกา RFC 6416 ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.3
H263-1998 RFC 3551
RFC 4629
RFC 2190
ดูรายละเอียดเกี่ยวกับ H263 ในส่วนที่ 5.1.8
H263-2000 RFC 4629 ดูรายละเอียดเกี่ยวกับ H263 ในส่วนที่ 5.1.8
AMR RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-NB ในส่วนที่ 5.1.3
AMR-WB RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-WB ในส่วนที่ 5.1.3
MP4V-ES RFC 6416 ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ในส่วน 5.1.8
Mpeg4-ทั่วไป RFC 3640 ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.3
MP2T RFC 2250 ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming

5.8 สื่อที่ปลอดภัย

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

  • [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และรองรับโปรโตคอลการแสดงผลแบบไร้สาย สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-2-1] ต้องรักษาความปลอดภัยลิงก์ด้วยกลไกที่มีการเข้ารหัสที่รัดกุม เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และรองรับจอแสดงผลภายนอกแบบใช้สาย ระบบจะดำเนินการดังต่อไปนี้

  • [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อ ผ่านพอร์ตแบบมีสายที่ผู้ใช้เข้าถึงได้

5.9 Musical Instrument Digital Interface (MIDI)

หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านชั้นเรียน android.content.pm.PackageManager ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องรองรับ MIDI กับการส่งฮาร์ดแวร์ที่ใช้ MIDI ทั้งหมด ซึ่งให้บริการการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป ซึ่งการขนส่งดังกล่าวมีลักษณะดังนี้

  • [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 เสียงดั้งเดิมของ AAudio
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-SR-1] แนะนำให้ทำให้สอดคล้องกับเวลาในการตอบสนองตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ที่ความเร็ว 20 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดที่มีค่าเบี่ยงเบนเฉลี่ยค่าสัมบูรณ์น้อยกว่า 5 มิลลิวินาทีในเส้นทางไมโครโฟนระหว่างลำโพง
  • [C-SR-2] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับ Pro สำหรับเวลาในการตอบสนองของเสียงไป-กลับที่ต่อเนื่อง เวลาในการตอบสนองของอินพุตที่เย็น เวลาในการตอบสนองที่ต่ำ และข้อกำหนดเสียง 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 เมื่อทำงานอยู่ทั้ง 2 อย่าง
  • ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดค่าเวลาในการตอบสนองของเสียงในทุกเส้นทาง
  • ควรลด Jitter ในเวลาป้อน Callback ให้เสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
  • ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน
  • ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
  • ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
  • ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
  • ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
  • ควรระบุความแตกต่างของเวลานาฬิกาเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง เมื่อทั้ง 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 (วัดได้โดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์ที่เชื่อมต่ออินพุตกับเอาต์พุต)
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 ช่องในแต่ละทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิตเมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้
  • [C-SR-7] เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ AAudio Native Audio API ผ่านเส้นทาง MMAP

หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้

  • ควรรองรับเอาต์พุตแบบสเตอริโอและ 8 ช่องสัญญาณที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มเนื้อหาซ้ำในการกำหนดค่าอย่างน้อย 1 รายการ

5.11 จับภาพสำหรับที่ไม่ได้ประมวลผล

Android รองรับการบันทึกเสียงที่ไม่ได้ประมวลผลผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES จะสามารถเข้าถึงได้ด้วยค่าระเบียนที่กำหนดล่วงหน้า SL_ANDROID_RECORDING_PRESET_UNPROCESSED

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

  • [C-1-1] ต้องรายงานการสนับสนุนผ่านพร็อพเพอร์ตี้ android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

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

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

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

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

  • [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนแต่ละตัว และไมโครโฟนทุกตัวที่ใช้ในการบันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่ากันของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)

  • [C-1-7] ต้องมีความผิดเพี้ยนแบบฮาร์มอนิก (THD) รวมน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

  • [C-1-8] ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางอื่นที่ไม่ใช่ตัวคูณระดับเพื่อเพิ่มระดับไปยังช่วงที่ต้องการ กล่าวคือ

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

การวัด SPL ทั้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

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

  • [C-2-1] ต้องแสดงผล null สำหรับเมธอด AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API เพื่อระบุอย่างเหมาะสมว่ารับการสนับสนุนไม่เพียงพอ
  • [C-SR-1] ยังคงแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดจำนวนมาก สำหรับเส้นทางสัญญาณสำหรับแหล่งบันทึกที่ไม่ได้ประมวลผล

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 , Dataprocs, Fingerprint, graphicstats, netstats, notification, procstats) บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell cmd stats และคลาส StatsManager System API
      • เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
      • ตรวจพบความผิดปกติ
      • รายงานเบรดครัมบ์ของแอปแล้ว
      • แอปขัดข้อง
      • เกิดแอป
      • เปลี่ยนระดับแบตเตอรี่แล้ว
      • เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
      • BleScanผลลัพธ์ได้รับ
      • เปลี่ยนสถานะ BleScan แล้ว
      • เปลี่ยนสถานะการชาร์จแล้ว
      • เปลี่ยนสถานะโหมดอุปกรณ์ชั่วคราวแล้ว
      • เปลี่ยนสถานะของบริการที่ทำงานอยู่เบื้องหน้าแล้ว
      • เปลี่ยนสถานะการสแกน GPS แล้ว
      • เปลี่ยนสถานะของงานแล้ว
      • สถานะเสียบปลั๊กเปลี่ยน
      • เปลี่ยนสถานะงานที่กำหนดเวลาไว้แล้ว
      • สถานะหน้าจอเปลี่ยน
      • สถานะการซิงค์เปลี่ยนแปลง
      • แบบเรียลไทม์โดยระบบ
      • เปลี่ยนสถานะ UidProcess แล้ว
      • เปลี่ยนสถานะ Wake Lock แล้ว
      • ตั้งปลุกแล้ว
      • เปลี่ยนสถานะ WifiLock
      • เปลี่ยนสถานะ Wifiมัลติแคสต์ล็อกแล้ว
      • เปลี่ยนสถานะการสแกน Wi-Fi แล้ว
    • [C-0-4] ต้องมี adb daemon ฝั่งอุปกรณ์ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
    • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android มีการสนับสนุนสำหรับ adb ที่ปลอดภัย Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แล้วที่รู้จัก
    • [C-0-6] ต้องระบุกลไกที่ทำให้สามารถเชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

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

    • [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
    • [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 ซึ่งทำให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้

    หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi ระบบจะดำเนินการดังต่อไปนี้

    • [C-4-1] ต้องมีเมธอด AdbManager#isAdbWifiSupported() ที่แสดง true

    หากการใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi และมีกล้องอย่างน้อย 1 ตัว

    • [C-5-1] ต้องมีเมธอด AdbManager#isAdbWifiQrSupported() ที่แสดง true
  • บริการตรวจสอบแก้ไขข้อบกพร่องของ 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 แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง
    • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุตสำหรับการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-3] ขอแนะนําอย่างยิ่งให้เขียนไบนารี Perfetto เป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-4] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto โดยใช้ไบนารี Perfetto
  • ประหยัดหน่วยความจำต่ำ

    • [C-0-10] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ลงในบันทึกสถิติเมื่อ Low Memory Killer สิ้นสุดการทำงานของแอป
  • โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่ง Shell cmd testharness และเรียกใช้ cmd testharness enable การดำเนินการดังกล่าวจะส่งผลดังนี้

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

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

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

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

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

  • [C-0-1] ต้องปฏิบัติตาม android.settings.APPLICATION_DEVELOPMENT_SETTINGS ความตั้งใจในการแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอัปสตรีมของ Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
  • [C-0-2] ต้องซ่อนตัวเลือกของนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น
  • [C-0-3] ต้องระบุกลไกที่ชัดเจนว่าจะไม่ให้การจัดการตามความพิเศษกับแอปของบุคคลที่สามแอปหนึ่ง ไม่ใช่อีกแอปหนึ่งเพื่อเปิดใช้ตัวเลือกของนักพัฒนาซอฟต์แวร์ ต้องระบุเอกสารหรือเว็บไซต์ที่เปิดเป็นสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ เอกสารหรือเว็บไซต์นี้จะต้องลิงก์ได้จากเอกสาร Android SDK
  • ควรมีการแจ้งเตือนผู้ใช้ด้วยภาพอย่างต่อเนื่องเมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์แล้ว และข้อกังวลด้านความปลอดภัยของผู้ใช้
  • อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ชั่วคราวด้วยการซ่อนหรือปิดใช้เมนูเพื่อไม่ให้เสียสมาธิในกรณีที่เกิดข้อกังวลด้านความปลอดภัยของผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีคอมโพเนนต์ฮาร์ดแวร์ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม

  • [C-0-1] การปรับใช้อุปกรณ์ต้องนำ API นั้นไปใช้ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

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

  • [C-0-2] ต้องมีการนำเสนอคำจำกัดความคลาสที่สมบูรณ์ (ตามที่ SDK บันทึกไว้) สำหรับ API คอมโพเนนต์
  • [C-0-3] ลักษณะการทำงานของ API ต้องนำมาใช้เป็นแบบ "ไม่ดำเนินการ" ตามแฟชั่นที่สมเหตุสมผล
  • [C-0-4] เมธอด API ต้องแสดงค่า Null ตามที่ได้รับอนุญาตโดยเอกสาร SDK
  • [C-0-5] เมธอด API ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่เอกสาร SDK ไม่อนุญาตค่า Null
  • [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบ SDK
  • [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

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

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

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

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

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

7.1.1 การกำหนดค่าหน้าจอ

7.1.1.1 ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลายแบบ และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

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

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

    • อุปกรณ์ที่ตั้งค่า Configuration.uiMode เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_Wwatch และรายงานขนาด small สําหรับ Configuration.screenLayout ต้องมีค่าอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด normal สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด large สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 960 dp x 720 dp
  • [C-0-2] ต้องปฏิบัติตามการรองรับขนาดหน้าจอของแอปพลิเคชันที่ระบุไว้อย่างถูกต้องผ่านแอตทริบิวต์ <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

  • อาจมีจอแสดงผลที่ใช้งานได้กับ Android ซึ่งมีมุมโค้งมน

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

  • [C-1-1] ต้องตรวจสอบว่าตรงตามข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ

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

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

  • [C-2-1] ต้องใช้ extensions API เวอร์ชันเสถียรล่าสุดที่มีให้ใช้งาน หรือ sidecar API เวอร์ชันเสถียรที่จะใช้โดยไลบรารี Window Manager Jetpack

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

  • [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือพับผ่าน API ส่วนขยายหรือไฟล์ช่วยเหลือไปยังแอปพลิเคชัน

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

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

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

  • [C-0-1] การใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

    • แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา android.max_aspect
    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ android:maxAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต
  • [C-0-3] การใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_WATCH ต้องตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)

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

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

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

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

หากไม่สามารถปรับขนาดจอแสดงผลของอุปกรณ์ได้ ให้ทำดังนี้

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

7.1.2 แสดงเมตริก

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

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกดิสเพลย์ทั้งหมดที่ใช้ร่วมกับ Android ได้ที่กำหนดไว้ใน android.util.DisplayMetrics API

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

  • [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่รองรับ Android ตามที่กำหนดไว้ใน android.util.DisplayMetrics API สำหรับ view.Display เริ่มต้นที่เลียนแบบ

7.1.3 การวางแนวหน้าจอ

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

  • [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ ตัวอย่างเช่น อุปกรณ์ที่มีหน้าจอแนวนอนตามการวางแนวที่คงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
  • [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ เมื่อใดก็ตามที่ค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

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

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

7.1.4 การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

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

  • [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) ผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API แบบเนทีฟอย่างถูกต้อง
  • [C-0-2] ต้องมีการรองรับสำหรับ API ที่มีการจัดการและ API เนทีฟทั้งหมดที่เกี่ยวข้องสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุให้รองรับ

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

  • [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่รวมไว้และอธิบายอย่างละเอียดในเอกสารประกอบ Android SDK
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

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

  • [C-5-1] ต้องระบุการรองรับผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

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

  • [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย
7.1.4.2 Vulkan

Android มีการรองรับ Vulkan ซึ่งเป็น API ข้ามแพลตฟอร์มแบบโอเวอร์เฮดสำหรับกราฟิก 3 มิติประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำงานดังนี้

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.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 อย่างน้อย 1 รายการสำหรับ Vulkan API เนทีฟ vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องใช้ Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับแต่ละรายการที่แจกแจง VkPhysicalDevice
  • [C-1-4] ต้องแจกแจงเลเยอร์ซึ่งอยู่ในไลบรารีแบบเนทีฟที่ชื่อว่า libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน API แบบเนทีฟของ Vulkan vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
  • [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่มาจากไลบรารีที่อยู่นอกแพ็กเกจแอปพลิเคชัน หรือให้วิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะตั้งค่าแอตทริบิวต์ android:debuggable เป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่ระบบรองรับผ่าน API แบบเนทีฟของ Vulkan และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
  • [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
  • [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ Vulkan dEQP ที่รองรับผ่านแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-9] ต้องรองรับเวอร์ชัน 132317953 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-10] ต้องผ่านการทดสอบ Vulkan dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132317953 กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-11] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_video_queue, VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue
  • [C-SR-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 และประกาศ Flag ฟีเจอร์ Vulkan จะมีผลดังนี้

  • [C-3-1] ต้องแสดงการสนับสนุน SYNC_FD ประเภทแฮนเดิลภายนอก และประเภทแฮนเดิล รวมถึงส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer
7.1.4.3 RenderScript
  • [C-0-1] การใช้งานอุปกรณ์ต้องรองรับ Android RenderScript โปรดดูรายละเอียดในเอกสารประกอบเกี่ยวกับ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือดูผ่านการใช้แท็กไฟล์ Manifest android:hardwareAccelerated หรือการเรียก API โดยตรง

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

  • [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปส่งคำขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
  • [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาซอฟต์แวร์ผสานรวมพื้นผิว OpenGL ES ที่ใช้ฮาร์ดแวร์เร่งการแสดงผลได้โดยตรงเป็นเป้าหมายการแสดงผลในลำดับชั้นของ UI

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

  • [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการติดตั้งใช้งานอัปสตรีม Android
7.1.4.5 จอแสดงผลขอบเขตกว้าง

หากการใช้งานอุปกรณ์อ้างว่ารองรับการแสดงผลแบบกว้างผ่าน Configuration.isScreenWideColorGamut() ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
  • [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ CIE 1931 xyY
  • [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
  • [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear และ EGL_EXT_gl_colorspace_display_p3_passthrough
  • [C-SR-1] แนะนําอย่างยิ่งให้สนับสนุน GL_EXT_sRGB

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

  • [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่ CIE 1931 xyY แม้ว่าไม่ได้ระบุขอบเขตสีของหน้าจอก็ตาม

7.1.5 โหมดความเข้ากันได้กับแอปพลิเคชันเดิม

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

7.1.6 เทคโนโลยีหน้าจอ

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

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

  • [C-0-1] ต้องแสดงภาพกราฟิกสี 16 บิตได้
  • ควรสนับสนุนจอแสดงผลที่รองรับกราฟิกสี 24 บิต
  • [C-0-2] ต้องแสดงภาพภาพเคลื่อนไหวได้
  • [C-0-3] ต้องมีอัตราส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 นั่นคือ สัดส่วนภาพพิกเซลต้องใกล้เคียงกับรูปสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10 ~ 15%

7.1.7 จอแสดงผลสำรอง

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

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

  • [C-1-1] ต้องใช้บริการของระบบ DisplayManager และ API ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

7.2 อุปกรณ์อินพุต

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

7.2.1 แป้นพิมพ์

หากการนำอุปกรณ์ไปใช้งานรองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม จะมีผลดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.software.input_methods
  • [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
  • [C-1-3] ต้องมีซอฟต์แวร์แป้นพิมพ์ที่ติดตั้งไว้ล่วงหน้า

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

  • [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 คีย์)
  • ควรมีการใช้งานแป้นพิมพ์เสมือนเพิ่มเติม
  • อาจรวมแป้นพิมพ์ที่เป็นฮาร์ดแวร์ด้วย

7.2.2 การนำทางแบบไม่สัมผัส

Android มีการสนับสนุนสำหรับ D-pad แทร็กบอล และวงล้อเป็นกลไกสำหรับการนำทางแบบไม่สัมผัส

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

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

  • [C-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] แนะนำอย่างยิ่งให้ใช้การกดค้างที่ฟังก์ชันหน้าแรกเป็นการโต้ตอบที่กำหนดนี้

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

  • [C-5-1] แป้นนำทางต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมให้ใช้งานสำหรับแอปพลิเคชัน และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่ใช้งานได้สำหรับแอปพลิเคชัน
  • [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่มีคุณสมบัติตรงตามข้อกำหนดที่ระบุไว้ในหัวข้อ 7.1.1
  • [C-5-3] ต้องยึดตามแฟล็กที่แอปตั้งค่าผ่านเมธอด View.setSystemUiVisibility() API เพื่อซ่อนส่วนเฉพาะของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ให้อยู่ในตำแหน่งที่เหมาะสมตามที่ระบุไว้ใน SDK

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

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสในหน้าแรกเท่านั้น
  • [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในวิดีโอยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets() ต้องไม่มีการสกัดกั้นสำหรับฟังก์ชันการนำทาง ตราบใดที่การยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
  • [C-6-3] ต้องส่งเหตุการณ์ MotionEvent.ACTION_CANCEL ให้แอปที่ทำงานอยู่เบื้องหน้าเมื่อการแตะเริ่มถูกดักจับสำหรับท่าทางสัมผัสของระบบ ในกรณีที่แอปที่ทำงานอยู่เบื้องหน้ามีการส่งเหตุการณ์ MotionEvent.ACTION_DOWN ไว้ก่อนหน้านี้
  • [C-6-4] ต้องให้ผู้ใช้จ่ายเพื่อเปลี่ยนไปใช้การนำทางบนหน้าจอ โดยใช้ปุ่ม (เช่น ในการตั้งค่า)
  • ควรมีฟังก์ชัน "หน้าแรก" โดยการปัดขึ้นจากขอบด้านล่างของการวางแนวปัจจุบันของหน้าจอ
  • ควรมีฟังก์ชัน "ล่าสุด" เป็นการปัดขึ้นแล้วค้างไว้ก่อนที่จะปล่อยนิ้ว จากพื้นที่เดียวกับท่าทางสัมผัส "หน้าแรก"
  • ท่าทางสัมผัสที่เริ่มต้นภายใน WindowInsets#getMandatorySystemGestureInsets() ไม่ควรได้รับผลกระทบจากการแก้ไขการยกเว้นซึ่งมาจากแอปพลิเคชันเบื้องหน้าผ่านทาง View#setSystemGestureExclusionRects()

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

  • [C-7-1] ฟังก์ชันการนำทางต้อง "กลับ" และจะต้องเป็นการปัดจากขอบทั้งด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
  • [C-7-2] หากแผงระบบแบบปัดดูที่กำหนดเองมีอยู่ที่ขอบด้านซ้ายหรือขวา แผงดังกล่าวจะต้องวางไว้ใน 1/3 ของส่วนบนสุดของหน้าจอ โดยมีภาพบ่งชี้ที่ชัดเจนและมองเห็นได้ตลอดเวลาว่า การลากนิ้วจะเรียกใช้แผงที่กล่าวถึงข้างต้น และด้วยเหตุนี้ จึงไม่ "ย้อนกลับ" ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ใต้ 1/3 ของขอบหน้าจอด้านบน แต่แผงระบบต้องไม่ยาวกว่าขอบ 1/3 ของขอบหน้าจอ
  • [C-7-3] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANS_BARS_BY_SWIOR_SHOW_TRANS_BARS_BY_SWIG
  • [C-7-4] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_S ระบบซ่อนแถบการนำทางที่กำหนดเอง

7.2.4 อินพุตหน้าจอสัมผัส

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

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

  • ควรมีระบบป้อนข้อมูลตัวชี้ในบางลักษณะ (แบบเมาส์หรือการแตะ)
  • ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์

หากอุปกรณ์มีหน้าจอสัมผัส (แบบแตะครั้งเดียวหรือดีกว่า) บนจอแสดงผลหลักที่รองรับ Android ฟีเจอร์ดังกล่าวจะส่งผลดังนี้

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

หากอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะ มากกว่า 1 ครั้งบนจอแสดงผลหลักที่รองรับ Android ฟีเจอร์ดังกล่าว

  • [C-2-1] ต้องรายงานแฟล็กฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand ตามประเภทของหน้าจอสัมผัสที่เจาะจงในอุปกรณ์

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

  • [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่เริ่มต้นด้วย android.hardware.touchscreen
  • [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
  • [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับช่อง API ของ Configuration.touchscreen

7.2.5 การป้อนข้อมูลด้วยการสัมผัสปลอม

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

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

  • ควรประกาศการรองรับ Flag ฟีเจอร์ android.hardware.faketouch

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch ระบบจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องรายงานตำแหน่งหน้าจอ X และ Y แบบสัมบูรณ์ ของตำแหน่งเคอร์เซอร์ และแสดงตัวชี้แบบภาพบนหน้าจอ
  • [C-1-2] ต้องรายงานเหตุการณ์การแตะที่มีโค้ดการดำเนินการซึ่งระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นบนตัวชี้ที่ขึ้นหรือลงบนหน้าจอ
  • [C-1-3] ต้องรองรับการชี้ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จำลองการแตะบนวัตถุบนหน้าจอได้
  • [C-1-4] ต้องรองรับเคอร์เซอร์ลง ชี้ขึ้น ชี้ลง แล้วชี้ขึ้นที่ตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะ 2 ครั้งบนวัตถุบนหน้าจอได้
  • [C-1-5] ต้องรองรับการชี้ลงที่จุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดใดก็ได้ที่กำหนดเองบนหน้าจอ ตามด้วยตัวชี้ขึ้น ซึ่งช่วยให้ผู้ใช้สามารถจำลองการลากด้วยการแตะได้
  • [C-1-6] ต้องรองรับการชี้ลง ซึ่งช่วยให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นตัวชี้ขึ้นบนหน้าจอซึ่งทำให้ผู้ใช้สะบัดวัตถุบนหน้าจอได้

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.distinct ระบบจะดำเนินการต่อไปนี้

  • [C-2-1] ต้องประกาศการรองรับ android.hardware.faketouch
  • [C-2-2] ต้องรองรับการติดตามอินพุตตัวชี้อิสระ อย่างน้อย 2 รายการแยกกัน

หากการใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.jazzhand ระบบจะดำเนินการต่อไปนี้

  • [C-3-1] ต้องประกาศการรองรับ android.hardware.faketouch
  • [C-3-2] ต้องรองรับการติดตามค่า 5 (การติดตามการใช้นิ้วมือ) หรือการป้อนข้อมูลด้วยตัวชี้อื่นๆ แยกกันโดยสิ้นเชิง

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

7.2.6.1 การแมปปุ่ม

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

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

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

  • [C-2-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.gamepad
Button การใช้งาน HID2 ปุ่ม Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
1 0x09 0x0002 KEYCODE_BUTTON_B (97)
x1 0x09 0x0004 KEYCODE_BUTTON_X (99)
ปี1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad ขึ้น1
D-pad ลง1
0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ขวา1
0x01 0x00393 AXIS_HAT_X4
ปุ่มไหล่ซ้าย1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกสติ๊กซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกสติ๊กขวา1 0x09 0x000f KEYCODE_BUTTON_THUMBR (107)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

KeyEvent 1 รายการ

2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน CA ของ Gamepad CA (0x01 0x0005)

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

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 ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียนผู้ฟัง ไม่เรียกผู้ฟังเซ็นเซอร์เมื่อเซ็นเซอร์ที่เกี่ยวข้องไม่ได้อยู่ ฯลฯ)

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

  • [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมด โดยใช้ค่าหน่วยเมตริก (เมตริก) สากลที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภท ตามที่ระบุไว้ในเอกสาร Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * ตัวอย่างเวลา สำหรับกรณีของสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองตามที่ขอไม่เกิน 0 มิลลิวินาที เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
  • [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์รายการแรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีค่าความแม่นยำเป็น 0 ได้
  • [C-1-4] สำหรับ API ที่ระบุไว้ในเอกสารประกอบของ Android SDK ให้เป็นเซ็นเซอร์แบบต่อเนื่อง การใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมี Jitter ต่ำกว่า 3% โดย Jitter เป็นค่าเบี่ยงเบนมาตรฐานของผลต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์
  • [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือตื่น จากสถานะระงับ
  • [C-1-6] ต้องรายงานเวลาของเหตุการณ์ เป็นนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK โดยแสดง เวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
  • [C-SR-1] ขอแนะนำเป็นอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
  • เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินกว่าผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

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

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

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

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

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

  • ควรใช้เซ็นเซอร์ประเภทเหล่านี้ เมื่อมีเซ็นเซอร์ทางกายภาพที่จำเป็นก่อนตามที่อธิบายไว้ในประเภทเซ็นเซอร์

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

  • [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เรื่องเซ็นเซอร์แบบผสม

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

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

หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์เฉพาะที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์แสดงต่อนักพัฒนาซอฟต์แวร์บุคคลที่สาม เหตุการณ์ดังกล่าวจะเกิดขึ้นดังนี้

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

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

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

7.3.1 ตัวตรวจวัดความเร่ง

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

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

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้และรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
  • [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้ถึง 4 เท่าของแรงโน้มถ่วง(4g) หรือมากกว่าบนแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดยส่วนเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 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 ดวง)
  • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ระหว่างการโทรฉุกเฉินต่อไป

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากทุกกลุ่มดาวที่ติดตาม (ตามรายงานในข้อความ GnssStatus) ยกเว้น SBAS

  • [C-SR-4] แนะนําอย่างยิ่งให้รายงาน AGC และความถี่ในการวัดผล GNSS

  • [C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทางของทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รายงานการวัดของ GNSS ทันทีที่พบ แม้ว่าจะไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม

  • [C-SR-7] ขอแนะนำเป็นอย่างยิ่งให้รายงานช่วง Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยอัตรากำลังสองของความเร่งน้อยกว่า 0.2 เมตรต่อวินาที ก็เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ติดตั้งเซ็นเซอร์เครื่องวัดการหมุน

หากอุปกรณ์มีเครื่องวัดการหมุน 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] แนะนำอย่างยิ่งให้สามารถรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa
  • ควรมีความแม่นยำสัมบูรณ์ที่ 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 ก. ถึง +16 ก. เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
    • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 400 μg/ทั้งหมดใน{/9}
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
    • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมของไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีความเร่งเดินแบบสุ่มน้อยกว่า 30 μg ¡Hz ทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
    • ควรมีค่าความไม่เป็นเชิงเส้นของเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิ ≤ 0.03%/C°
    • ควรมีความไวข้ามแกน < 2.5 % และความไวข้ามแกน < 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
  • [C-2-2] ต้องมี TYPE_ACCELEROMETER_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_ACCELEROMETER

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
    • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
    • [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมของไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีอัตราการเดินแบบสุ่มน้อยกว่า 0.001 °/s CMP อัตราการเดินที่ทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
    • ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
    • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
    • ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
    • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาทีในช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่
    • ควรมีความไวต่อ g น้อยกว่า 0.1°/s/g
    • ควรมีความไวข้ามแกน < 4.0 % และความไวข้ามแกน < 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
  • [C-2-4] ต้องมี TYPE_GYROSCOPE_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_GYROSCOPE

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
    • ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
  • [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_GEOMAGNETIC_FIELD และมีคุณสมบัติดังต่อไปนี้

    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
    • [C-SR-3] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ไปจนถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานเป็น 50 Hz หรือสูงกว่า
  • [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 2 mW
  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR

  • [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่ง

    • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่ง

    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์เซ็นเซอร์
    • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
  • [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่ง

    • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่ง

    • จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
  • [C-2-13] การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กต้องอยู่ห่างจากกันไม่เกิน 2.5 มิลลิวินาที การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่งและเครื่องวัดการหมุนควรอยู่ภายใน 0.25 มิลลิวินาทีของกันและกัน

  • [C-2-14] ต้องมีการประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุน อยู่ในฐานเวลาเดียวกับระบบย่อยของกล้อง และมีข้อผิดพลาดภายใน 1 มิลลิวินาที

  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงใดๆ ข้างต้นไปยังแอปพลิเคชัน

  • [C-2-16] ต้องไม่มีปริมาณการใช้พลังงานสูงกว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่งและ 2.0 mW เมื่ออุปกรณ์กำลังเคลื่อนที่ เมื่อเปิดใช้เซ็นเซอร์ใดๆ ต่อไปนี้ร่วมกัน

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมี ต้องมีความสามารถในการบัฟเฟอร์ขั้นต่ำที่ 100 เหตุการณ์เซ็นเซอร์

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

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

  • [C-3-1] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและระดับอัตราการรายงานโดยตรงอย่างถูกต้องผ่าน API ของ isDirectChannelTypeSupported และ getHighestDirectReportRateLevel
  • [C-3-2] ต้องรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์อย่างน้อย 1 จาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศการรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุกระบบ) ประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

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

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

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

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

เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 3 (เดิมชื่อรัดกุม), คลาส 2 (เดิมชื่อต่ำ) หรือคลาส 1 (เดิมเรียกว่าความสะดวกสบาย) โดยอิงตามอัตราการยอมรับการปลอมแปลงและตัวปลอม รวมถึงความปลอดภัยของไปป์ไลน์ข้อมูลไบโอเมตริก การแยกประเภทนี้จะดูความสามารถที่เซ็นเซอร์ไบโอเมตริกมีในการเชื่อมต่อกับแพลตฟอร์มและกับแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์จะได้รับการจัดประเภทเป็นคลาส 1 โดยค่าเริ่มต้น และต้องปฏิบัติตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่างหากต้องการจัดประเภทเป็นคลาส 2 หรือคลาส 3 ข้อมูลไบโอเมตริกทั้งคลาส 2 และคลาส 3 มีความสามารถเพิ่มเติมตามรายละเอียดด้านล่าง

หากการใช้งานอุปกรณ์ทำให้เซ็นเซอร์ข้อมูลไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL ระบบจะดำเนินการดังต่อไปนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2 ตามที่ระบุไว้ในเอกสารนี้
  • [C-4-2] ต้องรู้จักและใช้ชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ในคลาส Authenticators และชุดค่าผสมของพารามิเตอร์ดังกล่าว ในทางกลับกัน ต้องไม่ยึดตามหรือรับรู้ค่าคงที่จำนวนเต็มที่ส่งไปยังเมธอด canAuthenticate(int) และ setAllowedAuthenticators(int) อื่นนอกเหนือจากที่ระบุไว้เป็นค่าคงที่สาธารณะใน Authenticators และการผสมผสานค่าดังกล่าว
  • [C-4-3] ต้องใช้การดำเนินการ ACTION_BIOMETRIC_ENROLL ในอุปกรณ์ที่มีข้อมูลไบโอเมตริก คลาส 3 หรือ คลาส 2 การดำเนินการนี้ต้องแสดงจุดแรกเข้าของการลงทะเบียนสำหรับข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ต้องการให้เซ็นเซอร์ข้อมูลไบโอเมตริกเป็นคลาส 1 (เดิมชื่อความสะดวก) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] ต้องมีอัตราการยอมรับที่เป็นเท็จน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจมีความปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และแจกแจงความเสี่ยงในการเปิดใช้อย่างชัดเจน หากอัตราการยอมรับการปลอมแปลงและการหลอกลวงสูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-9] ต้องให้ผู้ใช้ทำการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) หลังจากทำการทดลองที่ผิดพลาดไม่เกิน 20 ครั้ง และไม่มีเวลาเกิน 90 วินาที Backoff สำหรับยืนยันข้อมูลไบโอเมตริก
  • [C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้ลดจำนวนการทดลองทั้งหมดที่ผิดพลาดสำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุไว้ใน [C-1-9] หากอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 7% เมื่อวัดโดยใช้โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-3] ต้องพยายามจำกัดจำนวนอัตราสำหรับการยืนยันด้วยข้อมูลไบโอเมตริก โดยการทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกเพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-5] แนะนำอย่างเข้มงวดให้กำหนดอัตราการจำกัดเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดลองที่ผิดพลาด 5 ครั้งเพื่อการยืนยันข้อมูลไบโอเมตริกสูงสุดสำหรับจำนวนการทดลองที่ผิดพลาดสูงสุดต่อ [C-1-9] โดยการทดลองที่ผิดพลาดเป็นการทดลองที่มีคุณภาพในการบันทึก (BIOMETRIC_ACQUIRED_GOOD) ที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลชีวภาพที่ลงทะเบียน
  • [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้กำหนดตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE
  • [C-1-10] ต้องปิดใช้ข้อมูลไบโอเมตริกเมื่อการย้อนกลับการตรวจสอบสิทธิ์หลักเริ่มทำงานเป็นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วนที่ 9.11
  • [C-1-4] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/pattern/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโปรเจ็กต์โอเพนซอร์สของ Android เป็นกลไกในเฟรมเวิร์กในการดำเนินการ
  • [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ของผู้ใช้ออกทั้งหมด เมื่อมีการนำบัญชีออก (รวมถึงการรีเซ็ตเป็นค่าเริ่มต้น)
  • [C-1-6] ต้องให้เกียรติแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS)
  • [C-1-7] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ หรือรหัสผ่าน): ก) 1 ครั้งทุก 24 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ที่เปิดตัว Android เวอร์ชัน 9 ขึ้นไป หรือ ข) 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 หรือพื้นที่เคอร์เนล เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (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] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น
  • [C-3-5] ต้องสร้างรหัส Authenticator อีกครั้งสำหรับข้อมูลไบโอเมตริกระดับ 3 ทั้งหมดที่รองรับในอุปกรณ์ หากมีการลงทะเบียนซ้ำ
  • [C-3-6] ต้องเปิดใช้คีย์สโตร์ที่ใช้ข้อมูลไบโอเมตริกกับแอปพลิเคชันของบุคคลที่สาม

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ลายนิ้วมือใต้จอแสดงผล (UDFPS) ระบบจะดำเนินการดังนี้

  • [C-SR-11] ขอแนะนำอย่างยิ่งเพื่อป้องกันไม่ให้พื้นที่ที่สัมผัสได้ของ UDFPS รบกวนการนำทางแบบ 3 ปุ่ม( ซึ่งผู้ใช้บางรายอาจต้องการเพื่อการเข้าถึง)

7.3.12 เซ็นเซอร์ท่าทาง

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

  • อาจรองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา

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

  • [C-1-1] ต้องใช้และรายงานเซ็นเซอร์ TYPE_POSE_6DOF
  • [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

7.3.13 เซ็นเซอร์มุมบานพับ

หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์วัดมุมแบบบานพับ อุปกรณ์จะทำงานดังนี้

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

7.4.1 โทรศัพท์

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

  • Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์สำหรับโทรศัพท์ กล่าวคือ Android เข้ากันได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony และแฟล็กฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องใช้การสนับสนุน API อย่างสมบูรณ์สำหรับเทคโนโลยีนั้น
  • ควรอนุญาตบริการเครือข่ายมือถือทุกประเภท (2G, 3G, 4G, 5G ฯลฯ) ระหว่างการโทรฉุกเฉิน (ไม่ว่าเครือข่ายจะตั้งโดย SetAllowedNetworkTypeBitmap() ประเภทใดก็ตาม)

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

  • [C-2-1] ต้องใช้ API เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมที่ฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามใช้งานฟังก์ชัน eSIM ได้ ฟังก์ชันดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องติดตั้งใช้งาน EuiccManager API โดยสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์ไม่ได้ตั้งค่าพร็อพเพอร์ตี้ของระบบ ro.telephony.iwlan\_operation\_mode เป็น "เดิม" ระบบจะดำเนินการดังต่อไปนี้