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

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

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

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

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

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

เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 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 ประกอบด้วยรหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)

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

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

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

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

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

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

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

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

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

  • มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
  • ให้หน้าจอขนาดแนวทแยงมุม 2.5 ถึง 8 นิ้ว

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

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

2.2.1. ฮาร์ดแวร์

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

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

หากการใช้งานอุปกรณ์เคลื่อนที่อ้างว่ารองรับการแสดงผลภาพที่มีช่วงการรับแสงสูงกว่าปกติถึง 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.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] แนะนําอย่างยิ่งให้เปิดแอปผู้ช่วยที่เลือก กล่าวคือ เป็นแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ ACTION_ASSIST เมื่อกด KEYCODE_MEDIA_PLAY_PAUSE หรือ KEYCODE_HEADSETHOOK ค้างไว้ หากกิจกรรมเบื้องหน้าจัดการกิจกรรมการกดค้างเหล่านั้นไม่ได้
  • [7.3.1/H-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 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 เมตรต่อวินาทียกกำลังสอง เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที อย่างน้อยที่สุด .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] แนะนำให้รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 องศา
  • [7.4.3/H] ควรมีการรองรับบลูทูธและบลูทูธ LE

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

  • [7.4.7/H-1-1] ต้องระบุโหมดประหยัดอินเทอร์เน็ต

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

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

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

  • [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] ต้องประกาศแฟล็กฟีเจอร์ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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] ต้องมีแอปพลิเคชันที่จัดการ Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE และ ACTION_CREATE_DOCUMENT ตามที่อธิบายไว้ในเอกสาร SDK และมอบโอกาสในการเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้ API DocumentsProvider
  • [3.4.1/H-0-1] ต้องติดตั้งใช้งาน android.webkit.Webview API โดยสมบูรณ์
  • [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
  • [3.8.1/H-SR] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ WidgetFeatures ในแอป
  • [3.8.1/H-SR] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนสำหรับทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน ShortcutManager API
  • [3.8.1/H-SR] ขอแนะนำอย่างยิ่งให้รวมแอป Launcher เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป
  • [3.8.2/H-SR] ขอแนะนำอย่างยิ่งให้รองรับวิดเจ็ตแอปของบุคคลที่สาม
  • [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] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแรกที่มีให้ผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้
  • [3.8.3/H-SR] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกทั้งหมดที่ให้ผ่าน RemoteInput.Builder setChoices() ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดในหน้าต่างแจ้งเตือน
  • [3.8.3.1/H-SR] แนะนำอย่างยิ่งให้แสดงการดำเนินการที่ตั้งค่า Notification.Action.Builder.setContextual เป็น true ในบรรทัดเดียวกับการตอบกลับที่แสดงโดย Notification.Remoteinput.Builder.setChoices
  • [3.8.4/H-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย

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

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

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

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

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

  • [3.9/H-1-1] ต้องใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสาร Android SDK
  • [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่มีการจัดการผ่านแฟล็กฟีเจอร์ android.software.managed_users ยกเว้นเมื่อกำหนดค่าอุปกรณ์ให้รายงานว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือเพื่อจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

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

  • [3.10/H-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
  • [3.10/H-SR] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
  • [3.11/H-0-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
  • [3.11/H-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
  • [3.13/H-SR] ขอแนะนำอย่างยิ่งให้รวมคอมโพเนนต์ 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.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] ต้องเป็นไปตาม Intent ของ 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]* ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.2.2/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส 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 เพื่อเลือกความละเอียดสูงสุดที่รองรับอัตราการรีเฟรช 50Hz หรือ 60Hz
  • [5.8/T-SR] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกอัตราการรีเฟรช 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.4.1/T-0-1] ต้องติดตั้งใช้งาน android.webkit.Webview API โดยสมบูรณ์

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

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

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

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

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

  • [3.11/T-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ 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] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

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

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

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

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

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] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 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 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที อย่างน้อยที่สุด .9% ต่อวินาที

หากการใช้งานอุปกรณ์นาฬิกามีเครื่องวัดการหมุน 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

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

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

  • [3.10/W-1-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม

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

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

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

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

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

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

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

  • [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 โมเดลการรักษาความปลอดภัย

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

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

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

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

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

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

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

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

ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้ใช้สำหรับการติดตั้งใช้งานอุปกรณ์ Android 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] ค่าของ Flag 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() ต้องไม่ตรงกับแผนที่

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

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

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

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

  • [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] ได้รับการแนะนำอย่างยิ่งให้รองรับ Message Access Profile (MAP)

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

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

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

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

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

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

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

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

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

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

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

  • [7.6.1/A-SR] แนะนำอย่างยิ่งให้ลดค่าใช้จ่ายในการดำเนินงาน 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] H.265 HEVC

2.5.3 ซอฟต์แวร์

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

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

  • [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 ต่อแอปพลิเคชันเพื่อลดการควบคุม

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

  • [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 ของระบบ เพื่อดูแลให้มองเห็นองค์ประกอบเหล่านั้นได้อย่างชัดเจนตลอดเวลา ตามที่อธิบายไว้ใน WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS และ WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION

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

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

  • [8.2/A-0-1] ต้องรายงานจำนวนไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลที่ไม่ผันผวนต่อ UID ของกระบวนการแต่ละรายการ เพื่อให้นักพัฒนาซอฟต์แวร์ดูสถิติได้ผ่าน System API android.car.storagemonitoring.CarStorageMonitoringManager โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของ uid_sys_stats
  • [8.3/A-1-3] ต้องเข้าสู่โหมดโรงรถอย่างน้อย 1 ครั้งก่อนที่รถจะดับเครื่อง
  • [8.3/A-1-4] ต้องอยู่ในโหมดโรงรถอย่างน้อย 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] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

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

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

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

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

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

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

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

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

2.6.1 ฮาร์ดแวร์

ขนาดหน้าจอ

  • [7.1.1.1/Tab-0-1] ต้องมีหน้าจอในช่วง 7-18 นิ้ว

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

หากอุปกรณ์แท็บเล็ตมีเครื่องวัดการหมุน 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]

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

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

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

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

3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1. ส่วนขยาย Android

Android มีการรองรับการขยาย API ที่มีการจัดการโดยที่ยังคงใช้เวอร์ชัน API ระดับเดิมต่อไปได้

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

3.1.2. ไลบรารี Android

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

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

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

เช่น

acme/myproduct/
mydevice:10/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 หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
MODEL ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์ ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ที่เจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับให้ผู้ใช้ปลายทางอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ซีเรียล ต้องส่งคืน "UNKNOWN"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม แท็กต้องเข้ารหัสได้เป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 แบบ ได้แก่ คีย์การเผยแพร่ คีย์นักพัฒนาซอฟต์แวร์ และคีย์ทดสอบ
เวลา ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์
ประเภท ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ 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 ของ Android อนุญาตให้คอมโพเนนต์ของแอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์อื่นๆ ของ Android ได้ โปรเจ็กต์อัปสตรีมของ Android ประกอบด้วยรายการแอปพลิเคชันที่ถือว่าเป็นแอปพลิเคชันหลักของ Android ซึ่งใช้รูปแบบ Intent ต่างๆ เพื่อดำเนินการทั่วไป

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

    • นาฬิกาตั้งโต๊ะ
    • เบราว์เซอร์
    • ปฏิทิน
    • รายชื่อติดต่อ
    • แกลเลอรี
    • ค้นหาทั่วโลก
    • ปืนยิงลูกระเบิด
    • เพลง
    • การตั้งค่า
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 โดยทำตามขั้นตอนการตรวจสอบที่ระบุไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล ตามที่กำหนดโดยตัวจัดการแพ็กเกจในโปรเจ็กต์โอเพนซอร์สของ Android
  • [C-0-5] ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ URI ที่ผ่านการตรวจสอบความถูกต้องแล้วทั้งหมดเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI
  • อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากตัวกรองดังกล่าวได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นได้ยืนยันไม่สำเร็จ หากการติดตั้งใช้งานอุปกรณ์มีลักษณะเช่นนี้ ต้องระบุการลบล้างรูปแบบ URL ที่เหมาะสมให้กับผู้ใช้ในเมนูการตั้งค่า
  • ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้กับผู้ใช้ในการตั้งค่าดังนี้
    • [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของ App Link เริ่มต้นในภาพรวมสำหรับแอปให้เป็น "เปิดเสมอ" ถามเสมอ หรือไม่เปิดเลยได้ ซึ่ง "ต้อง" มีผลกับตัวกรอง 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 ด้วย
3.2.3.5 การตั้งค่าแอปเริ่มต้น

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

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

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

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

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

  • [C-2-1] ต้องระบุเมนูการตั้งค่าที่จะเรียกใช้ Intent ของ RoleManager.createRequestRoleIntent(String) พร้อม RoleManager.ROLE_SMS เพื่อแสดงกล่องโต้ตอบสำหรับเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องเข้ากันได้กับ ABI ที่กำหนดไว้อย่างน้อย 1 รายการและใช้ความเข้ากันได้กับ Android NDK
  • [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
    • 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
    • SETEND คำสั่ง
    • การดำเนินงานที่เป็นอุปสรรคของ 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 10 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, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

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

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

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

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

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

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

  • [C-1-1] ต้องสนับสนุน API แต่ละรายการเหล่านี้ที่เชื่อมโยงกับ HTML5
  • [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ 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] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของความตั้งใจมาตรฐาน
  • [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 มาตรฐานของ Android แบบโดยนัยในไฟล์ Manifest ของแอป เว้นแต่ Intent การเผยแพร่ต้องใช้สิทธิ์ "signature" หรือ "signatureOrSystem" protectionLevel หรืออยู่ในรายการการยกเว้น
    • [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องหยุดบริการในเบื้องหลังของแอป เช่นเดียวกับกรณีที่แอปเรียกใช้เมธอด stopSelf() ของบริการ ยกเว้นกรณีที่แอปอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่ผู้ใช้มองเห็นได้
    • [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปดังกล่าวจะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป
  • [C-0-9] อุปกรณ์ต้องแสดงผู้ให้บริการการรักษาความปลอดภัยต่อไปนี้เป็นค่าอาร์เรย์ 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

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

3.5.1 การจำกัดการทำงานในเบื้องหลัง

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

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

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 ให้กับบริษัทอื่น Namespace
  • [C-0-6] ต้องมีแพ็กเกจในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้เฉพาะแอปที่ใช้งานอย่างชัดแจ้ง (ผ่านกลไก <uses-library>) ได้รับผลกระทบจากการใช้งานหน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว

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

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

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

  • [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 ที่อนุญาตให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง) เพื่อรับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ใช้อินเทอร์เฟซการค้นหาส่วนกลาง

  • [C-1-1] ต้องใช้ 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 กำหนด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.12 ตำแหน่ง

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

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

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

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

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

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

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

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

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

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

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

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

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

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-3] ต้องรายงาน true สำหรับ DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
      • [C-1-4] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์เพื่อตอบสนองต่อการดำเนินการของ Intent android.app.action.PROVISION_MANAGED_DEVICE
      • [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ หากอุปกรณ์ประกาศการรองรับ Near Field Communications (NFC) ผ่านแฟล็กฟีเจอร์ android.hardware.nfc และได้รับข้อความ NFC ที่มีระเบียนประเภท MIME MIME_TYPE_PROVISIONING_NFC
    • เมื่อติดตั้งอุปกรณ์มีข้อมูลผู้ใช้ จะดำเนินการดังนี้
  • [C-1-2] ต้องมีการดำเนินการยืนยันบางอย่างระหว่างขั้นตอนการจัดสรรเพื่อให้ความยินยอมแก่แอปที่ตั้งเป็นเจ้าของอุปกรณ์ ความยินยอมอาจผ่านการดำเนินการของผู้ใช้หรือวิธีการแบบเป็นโปรแกรมบางอย่างในระหว่างการจัดสรร แต่ต้องไม่ใช่แบบฮาร์ดโค้ดหรือป้องกันไม่ให้ใช้แอปอื่นๆ ของเจ้าของอุปกรณ์

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

  • [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] กระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (ขั้นตอนที่เริ่มต้นโดยผู้ใช้ android.app.action.PROVISION_MANAGED_PROFILE) ประสบการณ์ของผู้ใช้ต้องสอดคล้องกับการใช้งาน AOSP

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

    • ไอคอนที่สอดคล้องกันหรือการชำระเงินอื่นๆ ของผู้ใช้ (เช่น ไอคอนข้อมูล AOSP ต้นทาง) เพื่อแสดงเมื่อผู้ดูแลระบบอุปกรณ์จำกัดการตั้งค่าบางอย่าง
    • ข้อความอธิบายสั้นๆ ตามที่ผู้ดูแลระบบอุปกรณ์ระบุไว้ผ่าน setShortSupportMessage
    • ไอคอนของแอปพลิเคชัน 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-5] ต้องแสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการหากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ภายในโปรไฟล์ที่มีการจัดการ
  • [C-1-6] เมื่อมีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีความสามารถในการมองเห็นได้ใน "ตัวเลือก" ของ Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากเปิดใช้โดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
  • [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีการจ่ายเงินสำหรับผู้ใช้ดังต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
    • แยกการพิจารณาการใช้งานแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
    • การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการโดยอิสระ
    • การจัดการอิสระของแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
    • การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
  • [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันแป้นโทรศัพท์ ที่อยู่ติดต่อ และข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลักได้ หากตัวควบคุมนโยบายด้านอุปกรณ์อนุญาต
  • [C-1-9] ต้องตรวจสอบว่าโปรไฟล์นั้นเป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่บังคับใช้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
  • [C-1-10] ต้องรองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากที่เป็นไปตามข้อกำหนดต่อไปนี้ในการให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการ
    • การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ DevicePolicyManager.ACTION_SET_NEW_PASSWORD และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ
    • ข้อมูลเข้าสู่ระบบในหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้ที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกับโปรไฟล์หลักตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์สของ Android
    • นโยบายรหัสผ่านของ DPC ต้องมีผลเฉพาะกับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการ เว้นแต่ว่ามีการเรียกใช้อินสแตนซ์ DevicePolicyManager ที่แสดงผลโดย getParentProfileInstance
  • เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนระหว่างสายและสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อติดต่อดังกล่าวควรมีป้ายติดป้ายเดียวกับที่ใช้เพื่อระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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] ต้องแตะ KEYCODE_HEADSETHOOK สองครั้งหรือ KEYCODE_MEDIA_PLAY_PAUSE เป็น KEYCODE_MEDIA_NEXT สำหรับ MediaSession.Callback#onMediaButtonEvent

3.15 Instant Apps

การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้

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

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

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

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

  • [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 ที่แอปกำหนด และต้องไม่เปลี่ยนลักษณะการทำงานของแอปตามแอตทริบิวต์นั้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] การถอดรหัสต้องดำเนินการโดยไม่ดาวน์มิกซ์ (เช่น สตรีม 5.0 AAC ต้องถอดรหัสเป็น PCM 5 ช่อง สตรีม 5.1 AAC ต้องถอดรหัสเป็น 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] เราขอแนะนำเป็นอย่างยิ่งว่าตัวถอดรหัสเสียง 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 บิตผ่าน android.media.MediaCodec API

5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ
โปรไฟล์ MPEG-4 AAC
(AAC LC) 		รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC ดิบ ADTS (ไม่รองรับ .aac, ไม่รองรับ ADIF)
  • MPEG-TS (.ts, ไม่สามารถค้นหาได้, ถอดรหัสเท่านั้น)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
โปรไฟล์ MPEG-4 HE AAC (AAC+) รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2
โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว) 		รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC) รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
ฐานความรู้ด้านสิ่งแวดล้อม (USAC) รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz MPEG-4 (.mp4, .m4a)
AMR-NB สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8 kHz 3GPP (.3gp)
AMR-WB 9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s ได้รับการสุ่มตัวอย่างที่ 16 kHz ตามที่กําหนดไว้ที่ AMR-WB, Adaptive Multi-Rate - 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)
  • OTA (.ota)
  • 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
  • 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] ดิบ
  • [C-0-7] HEIF (HEIC)

ตัวถอดรหัสรูปภาพที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง)

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

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

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

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

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

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

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

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

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
H.264 AVC ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, ไม่สามารถค้นหาได้)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
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] ต้องให้การสนับสนุนตัวแปลงรหัสสื่อผ่าน API ของ OMX หรือตัวแปลงรหัส 2.0 (หรือทั้งคู่) เช่นเดียวกับในโปรเจ็กต์โอเพนซอร์สของ Android และต้องไม่ปิดใช้หรือหลบเลี่ยงการรักษาความปลอดภัย ซึ่งไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API ต้องรองรับ API เหล่านี้อย่างน้อย 1 ตัวเท่านั้น และการรองรับ API ที่ใช้ได้ต้องมีการป้องกันความปลอดภัยด้วย
  • [C-SR] แนะนำอย่างยิ่งให้รวมการสนับสนุนสำหรับ Codec 2.0 API

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

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

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

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

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

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

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

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

  • [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อ OMX IL
  • [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ API ของตัวแปลงรหัส 2.0 และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของตัวแปลงรหัส 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 ตัวที่เปิดเผยผ่าน android.camera API

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

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

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

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

5.2.5 H.265

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
  • ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้ารหัส 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 (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) ผ่าน Media API ให้ทำดังนี้

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

  • [C-SR] เราขอแนะนำให้ใช้อุปกรณ์อย่างหนักเพื่อให้รองรับการแสดงข้อมูลเมตา MediaFormat#KEY_HDR10_PLUS_INFO สำหรับโปรไฟล์ HDR10Plus ผ่านทาง MediaCodec#getOutputFormat(int).

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

  • [C-SR] เราขอแนะนำเป็นอย่างยิ่งว่าให้ใช้อุปกรณ์แสดงเนื้อหา HDR สำหรับโปรไฟล์ HEVCProfileMain10HDR10Plus อย่างเหมาะสมบนหน้าจออุปกรณ์หรือในพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น 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 ที่จำเป็น (MediaFormat#KEY_HDR_STATIC_INFO สำหรับโปรไฟล์ HDR ทั้งหมดและพารามิเตอร์ MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชันโดยใช้ MediaCodec API รวมถึงรองรับการดึงข้อมูลข้อมูลเมตา HDR ที่จำเป็น (MediaFormat#KEY_HDR_STATIC_INFO สำหรับโปรไฟล์ HDR ทั้งหมดและ MediaFormat#KEY_HDR10_PLUS_INFO สำหรับโปรไฟล์ HDR10Plus) จากบิตสตรีมและ/หรือคอนเทนเนอร์ตามที่กำหนดโดยข้อกำหนดที่เกี่ยวข้อง และยังต้องรองรับการแสดงข้อมูลเมตา HDR ที่จำเป็น (MediaFormat#KEY_HDR_STATIC_INFO สำหรับโปรไฟล์ HDR ทั้งหมด) จากบิตสตรีมและ/หรือคอนเทนเนอร์ตามที่กำหนดโดยข้อกำหนดที่เกี่ยวข้อง

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

  • [C-SR] เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานอุปกรณ์เพื่อรองรับการส่งข้อมูลเมตา MediaFormat#KEY_HDR10_PLUS_INFO สำหรับโปรไฟล์ HDR10Plus ผ่าน MediaCodec#getOutputFormat(int)

  • [C-SR] เราขอแนะนำอย่างยิ่งให้แสดงเนื้อหา HDR อย่างเหมาะสมสำหรับโปรไฟล์ VP9Profile2HDR10Plus และ VP9Profile3HDR10Plus บนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น 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 และไมโครโฟนที่ใช้งานอยู่ในปัจจุบันซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านทาง API AudioRecord.getActiveMicrophones() และ MediaRecorder.getActiveMicrophones() หากการติดตั้งอุปกรณ์อนุญาตให้บันทึกคุณภาพวิทยุและดีวีดี 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 ถึง -18 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีความผิดเพี้ยนแบบฮาร์มอนิก (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน

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

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

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

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

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

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

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

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

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

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

หากการใช้อุปกรณ์มีตัวยกเลิกเสียงสะท้อน (Acomatic EchoCanceler) ซึ่งจะแทรกอยู่ในเส้นทางเสียงเมื่อเลือก 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 แบบ Full Scale สำหรับการบันทึกจุดลอยตัว/ไมโครโฟนคู่ และตัวอย่างการตรวจจับเสียงที่ใช้เพื่อความแม่นยำทุกตัว)
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะตั้งแต่ ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางของไมโครโฟนแต่ละตัวและไมโครโฟนที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะตั้งแต่ ±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, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
      • 96000 ในแบบโมโนและสเตอริโอ

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

    • อัตราการสุ่มตัวอย่าง: 24,000

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] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์ในจุดลอยตัวและหลายช่องทาง

5.5.3 ระดับเสียงเอาต์พุตเสียง

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

  • ควรอนุญาตให้ปรับระดับเสียงในแต่ละสตรีมเสียงแยกกันโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย AudioAttributes และการใช้เสียงในรถตามที่กำหนดไว้แบบสาธารณะใน android.car.CarAudioManager

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

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

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

  • เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM และเมื่อเสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ตัวแปลงสัญญาณหรือสัญญาณในอุปกรณ์ออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
  • เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
  • เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมที่ตามมาหลังจากที่อุปกรณ์เล่นเสียง
  • เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ตัวแปลงสัญญาณในอุปกรณ์หรือสัญญาณเข้ามาในอุปกรณ์ผ่านพอร์ต และเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM ที่สอดคล้องกัน
  • อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
  • เวลาในการตอบสนองแบบ Cold input ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
  • เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมที่ตามมาขณะที่อุปกรณ์บันทึกเสียง
  • Jitter เอาต์พุต Cold ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของเอาต์พุตเย็น
  • ความแปรปรวนของเวลาในการตอบสนองแบบ Cold Input ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของอินพุตเย็น
  • เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่อง เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่อง บวกกับช่วงเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์จะช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาสําหรับแอปเพื่อลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
  • API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
  • API เสียงดั้งเดิมของเสียง ชุด API ของ AAudio ภายใน Android NDK
  • timestamp คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง โปรดดูเพิ่มเติมที่ 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] เวลาในการตอบสนองแบบ Coldเอาต์พุต 100 มิลลิวินาทีหรือน้อยกว่า เราขอแนะนำเป็นอย่างยิ่งสำหรับอุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ในขณะนี้ สำหรับแพลตฟอร์มรุ่นที่จะออกในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่านั้น "ต้อง"
  • [C-SR] เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
  • [C-SR] ลด Jitter เอาต์พุต Cold
  • [C-SR] การประทับเวลาเอาต์พุตที่แสดงผลโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp ถูกต้องเป็น +/- 1 มิลลิวินาที

หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังการปรับเทียบเริ่มต้น เมื่อใช้ทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ API เสียงแบบ AAudio สำหรับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold ส่งออกข้อมูลดังกล่าวในอุปกรณ์เอาต์พุตเสียงอย่างน้อย 1 เครื่องที่รองรับ

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

หากการใช้อุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่านทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ 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] เวลาในการตอบสนองแบบ Cold input ไม่เกิน 100 มิลลิวินาที เราขอแนะนำเป็นอย่างยิ่งสำหรับอุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ในขณะนี้ สำหรับแพลตฟอร์มรุ่นที่จะออกในอนาคตในปี 2021 เราจะกำหนดเวลาในการตอบสนองของอินพุต Cold ไม่เกิน 200 มิลลิวินาที โดย "ต้อง"
  • [C-SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
  • [C-SR] ลดเสียงรบกวนของอินพุต Cold
  • [C-SR] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลให้เป็น +/- 1 มิลลิวินาที

5.7 โปรโตคอลเครือข่าย

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

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

  • [C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)

  • [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านโปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7

  • [C-1-3] ต้องรองรับโปรไฟล์เสียง RTP ต่อไปนี้และตัวแปลงรหัสที่เกี่ยวข้องในตาราง RTSP ด้านล่าง สำหรับข้อยกเว้น โปรดดูเชิงอรรถของตารางในส่วนที่ 5.1

รูปแบบกลุ่มสื่อ

รูปแบบกลุ่ม ข้อมูลอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
สตรีมส่ง MPEG-2 ISO 13818 ตัวแปลงรหัสวิดีโอ:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
โปรดดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP
ในหัวข้อ 5.1.3 และ MPEG-2

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

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

RTSP (RTP, SDP)

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

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 คิวบัฟเฟอร์ PCM ของ OpenSL ES และเส้นทางของ API เสียงดั้งเดิมของ AAudio อย่างน้อย 1 เส้นทาง
  • [SR] ขอแนะนำอย่างยิ่งให้ทำตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียงแบบ USB โดยใช้ API เสียงแบบเสียงเนทีฟผ่านเส้นทาง MMAP
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [SR] แนะนําอย่างยิ่งให้มอบประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและโหลดของ CPU แตกต่างกันไป ควรทดสอบโดยใช้รหัสคอมมิต SynthMark เวอร์ชัน Android 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 SynthMark ใช้ซอฟต์แวร์สังเคราะห์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองที่ช่วยวัดประสิทธิภาพของระบบ แอป SynthMark จำเป็นต้องเรียกใช้โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
    • Voicemark.90 >= 32 เสียง
    • เวลาในการตอบสนองmark.fixed.little <= 15 มิลลิวินาที
    • เวลาในการตอบสนองmark.dynamic.little <= 50 มิลลิวินาที

ดูคำอธิบายการเปรียบเทียบได้ในเอกสารประกอบของ SynthMark

  • ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
  • ควรลดการลอยของนาฬิกาเสียงที่สัมพันธ์กับ CPU CLOCK_MONOTONIC เมื่อใช้งานทั้งคู่
  • ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
  • ควรลด Jitter ในเวลาป้อน Callback ให้เสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
  • ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน
  • ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
  • ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
  • ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
  • ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
  • ควรระบุความแตกต่างของสัญญาณเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของจุดสิ้นสุดที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตช่องเสียบหูฟัง
  • ควรจัดการ Callback ที่เสร็จสมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องในเทรดเดียวกันเมื่อใช้งานทั้ง 2 ฝั่ง และป้อนเอาต์พุต Callback ทันทีหลังจาก Callback อินพุต หรือหากจัดการ Callback ในเทรดเดียวกันไม่ได้ ให้ป้อนเอาต์พุต Callback หลังจากป้อน Callback ของอินพุตเพื่อให้แอปพลิเคชันกำหนดเวลาด้านอินพุตและเอาต์พุตที่สอดคล้องกัน
  • ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง
  • ควรลดเวลาในการตอบสนองของการแตะ
  • ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)
  • ควรมีเวลาในการตอบสนองจากการป้อนข้อมูลด้วยการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 40 มิลลิวินาที

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

  • [SR] แนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager

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

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

  • [C-3-1] ต้องใช้คลาสเสียง USB
  • [C-3-2] ต้องมีเวลาในการตอบสนองไป-กลับเสียงแบบต่อเนื่องไม่เกิน 20 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB
  • เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าที่พอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 ช่องในแต่ละทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิตเมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้

หากการใช้งานอุปกรณ์มีพอร์ต 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 ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ผลตอบสนองด้วย RMS ที่ 520 สําหรับตัวอย่าง 16 บิต (หรือ -36 dB สำหรับเสียงที่ประมวลผลแบบจุดลอยตัว/คู่ที่ขาดความแม่นยำทุกตัว)

  • [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่ากันของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)

  • [C-1-7] ต้องมีความผิดเพี้ยนแบบฮาร์มอนิก (THD) รวมน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

  • ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางอื่นที่ไม่ใช่ตัวคูณระดับเพื่อปรับระดับไปยังช่วงที่ต้องการ กล่าวคือ

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

การวัด SPL ทั้งหมดจะทำข้างไมโครโฟนโดยตรงระหว่างการทดสอบ สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

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

  • [C-2-1] ต้องแสดงผล null สำหรับเมธอด AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API เพื่อระบุการขาดการรองรับอย่างเหมาะสม
  • [SR] ยังคงแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดจำนวนมากสำหรับเส้นทางสัญญาณสำหรับแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล

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-SR] ขอแนะนำอย่างยิ่งให้รองรับคำสั่ง Shell cmd testharness
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบอุปกรณ์ (batterystats , Diskstats, Fingerprint, graphicstats, netstats, notifications, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell cmd stats และคลาส System API StatsManager
      • เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
      • ตรวจพบความผิดปกติ
      • รายงานเบรดครัมบ์ของแอปแล้ว
      • แอปขัดข้อง
      • เกิดแอป
      • เปลี่ยนระดับแบตเตอรี่แล้ว
      • เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
      • 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 ที่รองรับโหมดอุปกรณ์ต่อพ่วงต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
      • ต้องระบุไดรเวอร์สำหรับ Windows 7, 9 และ 10 ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้

  • บริการตรวจสอบแก้ไขข้อบกพร่องของ 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] ขอแนะนำอย่างยิ่งให้แสดงไบนารี /system/bin/perfetto ต่อผู้ใช้ Shell ซึ่ง cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง
    • [C-SR] ขอแนะนําอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุตของการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
    • [C-SR] ขอแนะนําอย่างยิ่งให้ใช้ไบนารี Perfetto เพื่อเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
    • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto ผ่านทางไบนารี Perfetto

  • โหมดโปรแกรมทดสอบอัตโนมัติ

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

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

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

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

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

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

  • [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอัปสตรีมของ Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งในการตั้งค่า > เกี่ยวกับอุปกรณ์ > รายการในเมนูหมายเลขบิลด์
  • [C-0-2] ต้องซ่อนตัวเลือกของนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น
  • [C-0-3] ต้องระบุกลไกที่ชัดเจนว่าจะไม่ให้การจัดการเป็นพิเศษแก่แอปบุคคลที่สามแอปหนึ่ง แทนที่จะเป็นอีกแอปหนึ่งเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ ต้องระบุเอกสารหรือเว็บไซต์ที่เปิดเป็นสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ เอกสารหรือเว็บไซต์นี้ต้องลิงก์ได้จากเอกสาร Android SDK
  • ควรมีการแจ้งเตือนผู้ใช้ด้วยภาพอย่างต่อเนื่องเมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์และความปลอดภัยของผู้ใช้เป็นข้อกังวลใจในความปลอดภัยของผู้ใช้
  • อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ชั่วคราวด้วยการซ่อนหรือปิดใช้เมนูเพื่อไม่ให้เสียสมาธิในกรณีที่เกิดข้อกังวลด้านความปลอดภัยของผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์ที่เจาะจงซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสาร SDK ของ Android

หาก 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] ต้องตรวจสอบว่ารัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
  • ควรรวมทางเลือกของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยมผืนผ้า
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-2] การใช้งานอุปกรณ์ที่ตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพเท่ากับหรือมากกว่า 1.3333 (4:3) เว้นแต่ว่าแอปจะยืดได้กว้างขึ้นตามเงื่อนไขใดเงื่อนไขหนึ่งต่อไปนี้

    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปประกาศ android:minAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

  • [C-0-3] การใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_WATCH ต้องมีค่าสัดส่วนภาพเป็น 1.0 (1:1)

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

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

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

  • การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก 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] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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-SR] แนะนําอย่างยิ่งให้รองรับส่วนขยาย 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
  • [SR] แนะนําอย่างยิ่งให้สนับสนุนส่วนขยาย OES_EGL_image_external_essl3

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

  • [C-4-1] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด

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

  • [C-5-1] ต้องระบุการสนับสนุนผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

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

  • [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย
7.1.4.2 Vulkan

Android มีการสนับสนุน Vulkan ซึ่งเป็น API ข้ามแพลตฟอร์มแบบโอเวอร์เฮดสำหรับกราฟิก 3 มิติประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำงานดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้รวมการสนับสนุนสำหรับ Vulkan 1.1

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

  • ควรมีการรองรับ Vulkan 1.1

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

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องพร้อมแฟล็กฟีเจอร์ android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องแจกแจง VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ Vulkan Native 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-SR] แนะนำอย่างยิ่งให้รองรับ 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:hardware Accelerated หรือการเรียก 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] ขอแนะนำอย่างยิ่งให้สนับสนุน 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] ต้องใช้บริการของระบบและ API ของ DisplayManager ตามที่อธิบายไว้ในเอกสารประกอบของ 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] ต้องระบุตัวบ่งชี้ที่ชัดเจนว่าการดำเนินการใดจะทริกเกอร์แต่ละฟังก์ชัน การมีไอคอนที่มองเห็นได้พิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนระหว่างการตั้งค่าตั้งแต่แกะกล่องคือตัวอย่างของตัวบ่งชี้ดังกล่าว

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

  • [SR] ขอแนะนำเป็นอย่างยิ่งว่าไม่มีกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการทำงานตั้งแต่ Android 4.0 แล้ว

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

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

หากการใช้งานอุปกรณ์ไม่มีฟังก์ชัน "เมนู" สำหรับความเข้ากันได้แบบย้อนหลัง ฟังก์ชันดังกล่าวจะ * [C-SR] แนะนําอย่างยิ่งให้ทำให้ฟังก์ชันเมนูพร้อมใช้งานเมื่อ targetSdkVersion น้อยกว่า 10 รายการ ไม่ว่าจะเป็นปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันของเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการนำทางอื่นๆ

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

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

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

  • [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() ต้องไม่ถูกดักฟังสำหรับฟังก์ชันการนำทาง ตราบใดที่อนุญาตให้ใช้ URL การยกเว้นภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารสำหรับ 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 การปัดจากขอบต้องทํางานเหมือนกับการติดตั้งใช้งานใน AOSP ซึ่งระบุอยู่ใน SDK
  • [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้าตั้งค่าแฟล็ก View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY แผงระบบแบบปัดดูที่กำหนดเองต้องซ่อนจนกว่าผู้ใช้จะนำเข้าแถบระบบ (หรือที่เรียกว่าแถบนำทางและแถบสถานะ) ตามที่ใช้งานใน AOSP

7.2.4 อินพุตหน้าจอสัมผัส

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

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

  • ควรมีระบบป้อนข้อมูลตัวชี้บางประเภท (แบบเมาส์หรือการแตะ)
  • ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์

หากอุปกรณ์มีหน้าจอสัมผัส (แบบแตะครั้งเดียวหรือดีกว่า) จะมีฟีเจอร์ดังต่อไปนี้

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

หากอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะมากกว่า 1 ครั้ง ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้

  • [C-2-1] ต้องรายงานแฟล็กฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand ที่สอดคล้องกับประเภทของหน้าจอสัมผัสที่เจาะจงในอุปกรณ์

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

  • [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ใดๆ ที่ขึ้นต้นด้วย android.hardware.touchscreen และต้องรายงานเฉพาะ android.hardware.faketouch

7.2.5 การป้อนข้อมูลด้วยการสัมผัสปลอม

อินเทอร์เฟซแบบ Fake Touch มีระบบป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่บังคับเคอร์เซอร์บนหน้าจอให้อยู่ใกล้การแตะ แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วค่อยคลิก อุปกรณ์อินพุตจํานวนมาก เช่น เมาส์ แทร็กแพด เมาส์แบบลมแบบ Gyro ตัวชี้ ไจโร จอยสติ๊ก และแทร็กแพดแบบมัลติทัชรองรับการโต้ตอบด้วยการสัมผัสปลอมได้ Android มีฟีเจอร์ android.hardware.faketouch อย่างต่อเนื่อง ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่ใช่ระบบสัมผัส (ใช้ตัวชี้) ความแม่นยำสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจำลองการป้อนข้อมูลด้วยการแตะได้อย่างเพียงพอ (รวมถึงการสนับสนุนท่าทางสัมผัสพื้นฐาน) และบ่งชี้ว่าอุปกรณ์รองรับฟังก์ชันของหน้าจอสัมผัสที่จำลองขึ้นมา

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

  • ควรประกาศการรองรับ Flag ฟีเจอร์ android.hardware.faketouch

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

  • [C-1-1] ต้องรายงานตำแหน่งหน้าจอ X และ Y แบบสัมบูรณ์ของตำแหน่งตัวชี้ และแสดงตัวชี้แบบภาพบนหน้าจอ
  • [C-1-2] ต้องรายงานเหตุการณ์การแตะที่มีโค้ดการดำเนินการซึ่งระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นในตัวชี้ขึ้นหรือลงบนหน้าจอ
  • [C-1-3] ต้องรองรับการชี้ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จำลองการแตะบนวัตถุบนหน้าจอได้
  • [C-1-4] ต้องรองรับเคอร์เซอร์ลง ชี้ขึ้น ชี้ลง แล้วชี้ขึ้นที่ตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะสองครั้งบนวัตถุบนหน้าจอได้
  • [C-1-5] ต้องรองรับการชี้ลงที่จุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดใดก็ได้ที่กำหนดเองบนหน้าจอ ตามด้วยตัวชี้ขึ้น ซึ่งช่วยให้ผู้ใช้เลียนแบบการลากด้วยการแตะได้
  • [C-1-6] ต้องรองรับการชี้ลง จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นตัวชี้ขึ้นบนหน้าจอซึ่งทำให้ผู้ใช้สามารถขว้างวัตถุบนหน้าจอได้
  • [C-1-7] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับช่อง API ของ Configuration.touchscreen

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

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

  • [C-1-1] ต้องฝังตัวควบคุมหรือจัดส่งอุปกรณ์ควบคุมแยกต่างหากในกล่อง ซึ่งจะให้วิธีการในการป้อนข้อมูลเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่าง
  • [C-1-2] ต้องแมปเหตุการณ์ HID กับค่าคงที่ view.InputEvent ของ Android ที่เชื่อมโยงได้ตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งานอัปสตรีม Android รวมถึงการใช้งานสำหรับตัวควบคุมเกมที่เป็นไปตามข้อกำหนดนี้
ปุ่ม การใช้งาน HID2 ปุ่ม Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
ข1 0x09 0x0002 KEYCODE_BUTTON_B (97)
x1 0x09 0x0004 KEYCODE_BUTTON_X (99)
ปี1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad1
D-pad ลง1 		0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ด้านขวา1 		0x01 0x00393 AXIS_HAT_X4
ปุ่มไหล่ซ้าย1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกสติ๊กซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกสติ๊กขวา1 0x09 0x000f KEYCODE_BUTTON_THUMBR (107)
หน้าแรก1 0x0c 0x0223 KEYCODE_หน้าแรก (3)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

KeyEvent 1 รายการ

2 การใช้งาน HID ข้างต้นต้องมีการประกาศภายใน Game pad CA (0x01 0x0005)

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

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

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

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

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

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

7.3 เซ็นเซอร์

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

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

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

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

  • [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมดโดยใช้ค่าหน่วยเมตริกสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสาร Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time สำหรับสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองที่ร้องขอสูงสุดเท่ากับ 0 มิลลิวินาที เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
  • [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์รายการแรกภายใน 400 มิลลิวินาที + 2 * ตัวอย่าง_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำเป็น 0 ได้

  • [SR] ควรรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK โดยแสดงเวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano() เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตซึ่งอาจเป็นส่วนประกอบที่จำเป็น ข้อผิดพลาดในการซิงค์ควรต่ำกว่า 100 มิลลิวินาที

  • [C-1-4] สำหรับ API ที่ระบุโดยเอกสาร Android SDK ให้เป็นเซ็นเซอร์แบบต่อเนื่อง การใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมี Jitter ต่ำกว่า 3% โดย Jitter เป็นค่าเบี่ยงเบนมาตรฐานของผลต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่เกิดต่อเนื่องกัน

  • [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือเริ่มทำงานจากสถานะระงับ

  • เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินกว่าผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

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

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

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

  • ควรใช้เซ็นเซอร์ประเภทเหล่านี้ เมื่อมีเซ็นเซอร์ตรวจจับทางกายภาพที่จำเป็นเบื้องต้นตามที่อธิบายไว้ในประเภทเซ็นเซอร์

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

  • [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์แบบผสม

7.3.1 ตัวตรวจวัดความเร่ง

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

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

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้และรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
  • [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้ถึงสี่เท่าของแรงโน้มถ่วง(4g) หรือมากกว่าบนแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดยส่วนเบี่ยงเบนมาตรฐานควรคำนวณแบบต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีในอัตราการสุ่มตัวอย่างที่เร็วที่สุด
  • [SR] ขอแนะนําอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION
  • [SR] แนะนําอย่างยิ่งให้ใช้และรายงานเซ็นเซอร์ 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] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

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

  • [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR

7.3.2 เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 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
  • ควรใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [SR] เราขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED สำหรับอุปกรณ์ Android ทั้งใหม่และใหม่

หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 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] ขอแนะนำอย่างยิ่งให้รวมเครื่องรับ 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 ให้เหลือน้อยที่สุด (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และ Ephemeris/Clock ดาวเทียม)
    • [C-1-6] หลังจากคำนวณตำแหน่งแล้ว การใช้งานอุปกรณ์ต้องกำหนดตำแหน่งอุปกรณ์ในที่โล่งภายใน 5 วินาที เมื่อรีสตาร์ทคำขอตำแหน่ง และใช้เวลาไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอหลังจากนั้นโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากการเปิดเครื่องใหม่ก็ตาม

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

    • [C-1-3] ต้องสามารถระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วไม่เกิน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
    • [C-1-4] ต้องติดตามและรายงานในเวลาเดียวกันผ่านGnssStatus.Callbackดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว
    • ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายกลุ่มดาวได้พร้อมกัน (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อยหนึ่งดาว)
    • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน API ของผู้ให้บริการระบุตำแหน่ง GNSS ในระหว่างการโทรฉุกเฉินต่อไป
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัดของ GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ดังที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
    • [C-SR] แนะนําอย่างยิ่งให้รายงาน AGC และความถี่ของการวัด GNSS
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
    • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้รายงานช่วง Pseudoranges และอัตราเทียมของ GNSS กล่าวคือ ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่โดยมีความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลังสอง ถือว่าเพียงพอสำหรับการคำนวณตำแหน่งภายในระยะ 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อยเป็นเวลา 95%

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

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมเซ็นเซอร์เครื่องวัดการหมุน เว้นแต่จะมีตัวตรวจวัดความเร่งแบบ 3 แกนมาด้วย

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย
  • [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป และควรมีความละเอียด 16 บิตขึ้นไป
  • [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
  • [SR] ขอแนะนําอย่างยิ่งให้ใช้ข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์หยุดอยู่กับที่ที่อุณหภูมิห้อง
  • ควรรายงานเหตุการณ์สูงสุด 200 Hz

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

  • [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR

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

  • [C-3-1] ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

7.3.5 บารอมิเตอร์

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมบารอมิเตอร์ (เซ็นเซอร์ความดันอากาศแบบแอมเบียนท์)

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

  • [C-1-1] ต้องใช้และรายงานเซ็นเซอร์ TYPE_PRESSURE
  • [C-1-2] ต้องสามารถส่งเหตุการณ์ในระดับ 5 Hz หรือสูงกว่า
  • [C-1-3] ต้องมีการชดเชยอุณหภูมิ
  • [SR] แนะนําอย่างยิ่งให้สามารถรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa
  • ควรมีความแม่นยำสัมบูรณ์ที่ 1hPa
  • ควรมีความแม่นยำสัมพัทธ์ที่ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับ ความแม่นยำประมาณ 1m มากกว่า ~200m การเปลี่ยนแปลงที่ระดับน้ำทะเล)

7.3.6 เทอร์โมมิเตอร์

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

  • อาจมีเทอร์โมมิเตอร์โดยรอบ (เซ็นเซอร์อุณหภูมิ)
  • อาจ แต่ไม่ควรรวมเซ็นเซอร์อุณหภูมิของ CPU

หากอุปกรณ์มีเทอร์โมมิเตอร์วัดอุณหภูมิแวดล้อม (เซ็นเซอร์อุณหภูมิ) สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-1-1] ต้องระบุเป็น SENSOR_TYPE_AMBIENT_TEMPERATURE และต้องวัดอุณหภูมิแวดล้อม (ห้อง/ห้องโดยสาร) ที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส
  • [C-1-2] ต้องระบุเป็น SENSOR_TYPE_TEMPERATURE
  • [C-1-3] ต้องวัดอุณหภูมิของ CPU ของอุปกรณ์
  • [C-1-4] ต้องไม่วัดอุณหภูมิอื่นใด

โปรดทราบว่ามีการเลิกใช้งานเซ็นเซอร์ประเภท SENSOR_TYPE_TEMPERATURE ใน Android 4.0 แล้ว

7.3.7 โฟโต้มิเตอร์

  • การใช้งานอุปกรณ์อาจมีโฟโต้มิเตอร์ (เซ็นเซอร์แสงแวดล้อม)

7.3.8 พร็อกซิมิตีเซ็นเซอร์

  • การใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์

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

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

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] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 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] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 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] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 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 เซ็นเซอร์ไบโอเมตริก

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

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

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

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

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

  • [C-0-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกรัดกุมหรือไม่รัดกุมตามที่ระบุไว้ในเอกสารนี้

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

  • [C-0-2] ต้องมีคุณสมบัติตรงตามข้อกำหนดสำหรับรัดกุมตามที่ระบุไว้ในเอกสารนี้

นอกจากนี้

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

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

  • [C-1-1] ต้องมีอัตราการยอมรับที่เป็นเท็จน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และแจกแจงความเสี่ยงในการเปิดใช้อย่างชัดเจน หากอัตราการปลอมแปลงและการยอมรับของผู้แอบอ้างสูงกว่า 7%
  • [C-1-3] ต้องพยายามจํากัดอัตราคำขอเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดสอบที่ผิดพลาด 5 ครั้งสำหรับการยืนยันข้อมูลไบโอเมตริก โดยการทดสอบที่เป็นเท็จคือการทดสอบที่มีคุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) และไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-1-4] ต้องป้องกันไม่ให้มีการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มเอกสารรับรองอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่รักษาความปลอดภัยโดย 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 เวอร์ชัน 10 และทุก 72 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้า

  • [C-1-8] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังทำสิ่งใดสิ่งหนึ่งต่อไปนี้

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

    การอัปเกรดอุปกรณ์จาก Android เวอร์ชันก่อนหน้าสามารถได้รับการยกเว้นจาก C-1-8

  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์

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

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

  • [C-2-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดสำหรับความสะดวกสบายข้างต้น ยกเว้น [C-1-2]
  • [C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและการปลอมแปลงที่ไม่สูงกว่า 20%
  • [C-2-3] ต้องมีการใช้งานคีย์สโตร์ที่อาศัยฮาร์ดแวร์ และดำเนินการจับคู่ข้อมูลไบโอเมตริกในสภาพแวดล้อมการดำเนินการแยกต่างหากนอกผู้ใช้ Android หรือพื้นที่เคอร์เนล เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
  • [C-2-4] ต้องมีข้อมูลที่ระบุตัวบุคคลนั้นได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับ เพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยในสภาพแวดล้อมการดำเนินการที่แยกไว้ ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
  • [C-2-5] สำหรับข้อมูลไบโอเมตริกที่ใช้กล้องในระหว่างที่ตรวจสอบสิทธิ์หรือลงทะเบียนด้วยข้อมูลไบโอเมตริก
    • ต้องใช้กล้องในโหมดที่ป้องกันไม่ให้อ่านหรือเปลี่ยนแปลงเฟรมกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
    • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องสามารถอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกออกมาเพื่อสนับสนุนการดำเนินการต่างๆ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่ต้องไม่สามารถแก้ไขได้
  • [C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างการลงทะเบียนข้อมูลไบโอเมตริกแต่ละรายการ
  • [C-2-7] ต้องไม่อนุญาตการเข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวตนได้หรือข้อมูลใดก็ตามที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ไปยังผู้ประมวลผลแอปพลิเคชันโดยไม่เข้ารหัส โดยไม่เข้ารหัส TEE

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

    หากมีการเปิดตัวอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว และไม่เป็นไปตามข้อกำหนด C-2-8 ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านี้อาจได้รับการยกเว้นจากข้อกำหนดดังกล่าว

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

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

7.3.12 เซ็นเซอร์ท่าทาง

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

  • อาจรองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา

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

  • [C-1-1] ต้องใช้และรายงานเซ็นเซอร์ TYPE_POSE_6DOF
  • [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

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

7.4.1 โทรศัพท์

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

  • Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android เข้ากันได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony และแฟล็กฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องใช้การสนับสนุน API อย่างสมบูรณ์สำหรับเทคโนโลยีนั้น

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

  • [C-2-1] ต้องใช้ API เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมที่ฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามใช้งานฟังก์ชัน eSIM ได้ ฟังก์ชันดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องติดตั้งใช้งาน EuiccManager API โดยสมบูรณ์
7.4.1.1 ความเข้ากันได้ของการบล็อกหมายเลข

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

  • [C-1-1] ต้องมีการสนับสนุนการบล็อกหมายเลข
  • [C-1-2] ต้องใช้ BlockedNumberContract และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-3] ต้องบล็อกการโทรและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยที่ไม่โต้ตอบกับแอปใดๆ เลย ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-4] ต้องไม่เขียนถึงผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับสายที่ถูกบล็อก
  • [C-1-5] ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่บล็อก
  • [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งเปิดด้วย Intent ที่เมธอด TelecomManager.createManageBlockedNumbersIntent() แสดงผล
  • [C-1-7] ต้องไม่อนุญาตให้ผู้ใช้รองดูหรือแก้ไขหมายเลขที่ถูกบล็อกในอุปกรณ์เนื่องจากแพลตฟอร์ม Android จะถือว่าผู้ใช้หลักควบคุมบริการโทรศัพท์ได้อย่างเต็มรูปแบบในอุปกรณ์ เช่น การใช้อินสแตนซ์เดียว ต้องซ่อน UI ที่เกี่ยวข้องกับการบล็อกทั้งหมดสำหรับผู้ใช้รอง และรายการที่ถูกบล็อกต้องยังคงทำงานตามเดิม
  • ควรย้ายข้อมูลหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0
7.4.1.2 API โทรคมนาคม

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

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

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

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรศัพท์เริ่มต้นล่วงหน้าซึ่งแสดงรายการบันทึกการโทรและชื่อแอปของบุคคลที่สามในบันทึกการโทรเมื่อแอปของบุคคลที่สามตั้งค่าคีย์เพิ่มเติมของ EXTRA_LOG_SELF_MANAGED_CALLS ใน PhoneAccount เป็น true

  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้จัดการเหตุการณ์ KEYCODE_MEDIA_PLAY_PAUSE และ KEYCODE_HEADSETHOOK ของชุดหูฟังสำหรับ android.telecom API ดังนี้
    • โทรหา Connection.onDisconnect() เมื่อตรวจพบการกดปุ่มเหตุการณ์สำคัญสั้นๆ ระหว่างที่โทรอยู่
    • โทรหา Connection.onAnswer() เมื่อตรวจพบการกดแป้นสั้นๆ ระหว่างที่มีสายเรียกเข้า
    • โทรหา Connection.onReject() เมื่อตรวจพบการกดแป้นค้างไว้ระหว่างที่มีสายเรียกเข้า
    • สลับสถานะการปิดเสียงของ CallAudioState

7.4.2 IEEE 802.11 (Wi-Fi)

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

  • ควรมีการรองรับ 802.11 อย่างน้อย 1 รูปแบบ

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

  • [C-1-1] ต้องใช้ Android API ที่สอดคล้องกัน
  • [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
  • [C-1-3] ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-4] ต้องรองรับ Multicast DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) เมื่อใดก็ตามที่ดำเนินการ รวมถึงสิ่งต่อไปนี้
    • แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงานอยู่
    • สำหรับการใช้งานอุปกรณ์ Android TV แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย
  • [C-1-5] ต้องไม่ถือว่าการเรียกเมธอด API WifiManager.enableNetwork() เป็นตัวบ่งชี้ที่เพียงพอในการเปลี่ยน Network ที่ใช้งานอยู่ในปัจจุบัน ซึ่งใช้เป็นค่าเริ่มต้นสำหรับการรับส่งข้อมูลของแอปพลิเคชัน และจะแสดงผลโดยเมธอด API ConnectivityManager เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ อาจปิดใช้งานการเข้าถึงอินเทอร์เน็ตที่ให้บริการโดยผู้ให้บริการเครือข่ายรายอื่น (เช่น ข้อมูลมือถือ) เท่านั้น หากตรวจสอบแล้วว่าเครือข่าย Wi-Fi ได้ให้การเข้าถึงอินเทอร์เน็ต
  • [C-1-6] ขอแนะนำเป็นอย่างยิ่งว่าเมื่อมีการเรียกเมธอด ConnectivityManager.reportNetworkConnectivity() API ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และเมื่อการประเมินระบุว่า Network ปัจจุบันไม่มีการเข้าถึงอินเทอร์เน็ตแล้ว ให้เปลี่ยนไปใช้เครือข่ายอื่นๆ ที่พร้อมใช้งาน (เช่น อินเทอร์เน็ตมือถือ) ที่เข้าถึงอินเทอร์เน็ตได้
  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอตรวจสอบ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้ง ขณะที่ STA ไม่ได้เชื่อมต่อ
    • เฟรมคำขอการตรวจสอบแต่ละกลุ่มซึ่งประกอบด้วยการสแกน 1 รายการ ควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งแรกของการสแกน)
    • หมายเลขลำดับคำขอตรวจสอบควรทำซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอการตรวจสอบในการสแกน
    • หมายเลขลำดับคำขอการตรวจสอบควรสุ่มระหว่างคำขอการตรวจสอบสุดท้ายของการสแกนกับคำขอตรวจสอบแรกของการสแกนครั้งถัดไป
  • [C-SR] แนะนำอย่างยิ่งในขณะที่ STA ถูกตัดการเชื่อมต่อเพื่ออนุญาตเฉพาะองค์ประกอบต่อไปนี้ในเฟรมคำขอการตรวจสอบ:
    • ชุดพารามิเตอร์ SSID (0)
    • ชุดพารามิเตอร์ DS (3)

หากอุปกรณ์รองรับโหมดประหยัดพลังงาน Wi-Fi ตามที่ระบุไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์เหล่านี้จะมีผลดังนี้

  • [C-3-1] ต้องปิดโหมดประหยัดพลังงานของ Wi-Fi ทุกครั้งที่แอปมีการล็อก WIFI_MODE_FULL_HIGH_PERF หรือการล็อก WIFI_MODE_FULL_LOW_LATENCY ผ่าน API ของ WifiManager.createWifiLock() และ WifiManager.WifiLock.acquire() และล็อกทำงานอยู่
  • [C-3-2] เวลาในการตอบสนองไป-กลับโดยเฉลี่ยระหว่างอุปกรณ์กับจุดเข้าใช้งานในขณะที่อุปกรณ์อยู่ในโหมดล็อกเวลาในการตอบสนองต่ำของ Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) ต้องน้อยกว่าเวลาในการตอบสนองระหว่างโหมด Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF)
  • [C-SR] แนะนำอย่างยิ่งให้ลดเวลาในการตอบสนองของ Wi-Fi ไป-กลับ เมื่อใดก็ตามที่มีการล็อกเวลาในการตอบสนองต่ำ (WIFI_MODE_FULL_LOW_LATENCY) และมีผล

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

  • [C-2-1] ต้องระบุราคาของผู้ใช้ในการเปิดใช้/ปิดใช้ค่าที่อ่านผ่านเมธอด WifiManager.isScanAlwaysAvailable API
7.4.2.1 Wi-Fi Direct

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

  • ควรมีการสนับสนุน Wi-Fi Direct (Wi-Fi แบบเพียร์ทูเพียร์)

หากการใช้งานอุปกรณ์มีการรองรับ Wi-Fi Direct การทำงานจะส่งผลดังนี้

  • [C-1-1] ต้องใช้ corresponding Android API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องรายงานฟีเจอร์ของฮาร์ดแวร์ android.hardware.wifi.direct
  • [C-1-3] ต้องรองรับการทำงาน Wi-Fi ปกติ
  • [C-1-4] ต้องรองรับการดำเนินการ Wi-Fi และ Wi-Fi Direct ควบคู่กัน

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

  • ควรมีการสนับสนุนสำหรับ Wi-Fi Tunneled Direct Link Setup (TDLS) ดังที่อธิบายไว้ในเอกสารประกอบของ Android SDK

หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLS และ TDLS เปิดใช้อยู่โดย Wi-FiManager API

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

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

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

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

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

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

7.4.2.4 รหัสผ่าน Wi-Fi

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

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

  • [C-1-1] ต้องใช้ API ของ WifiManager ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องสนับสนุนมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นพบและการเลือกเครือข่าย เช่น General Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)

ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รองรับ Wi-Fi Passpoint

  • [C-2-1] การใช้งาน API ที่เกี่ยวข้องกับ WifiManager ของ Passpoint ต้องมี UnsupportedOperationException
7.4.2.5 ตำแหน่ง Wi-Fi (ระยะเวลารับส่งของ Wi-Fi - RTT)

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

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

  • [C-1-1] ต้องใช้ WifiRttManager API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.wifi.rtt
  • [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางสำหรับการถ่ายภาพ RTT แต่ละรายการที่ดำเนินการในขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT นั้นไม่ได้เชื่อมโยงกับจุดเข้าใช้งาน
7.4.2.6 การลดภาระงาน Wi-Fi Keepalive

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

  • ควรมีการสนับสนุนสำหรับการลดภาระงาน Wi-Fi Keepalive

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

  • [C-1-1] ต้องรองรับ SocketKeepAlive API

  • [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi และช่อง Keepalive อย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ

หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Wi-Fi Keepalive จะมีคุณสมบัติดังนี้

7.4.2.7 Wi-Fi Easy Connect (โปรโตคอลการจัดสรรอุปกรณ์)

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

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

7.4.3 บลูทูธ

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.vr.high_performance สิ่งต่อไปนี้

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

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

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

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

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

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

  • ควรรองรับโฆษณาหลายรายการที่มีอย่างน้อย 4 ช่อง

  • [SR] แนะนําอย่างยิ่งให้ใช้ระยะหมดเวลา Resolvable Private Address (RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้

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

  • [C-4-1] ต้องระบุราคาสำหรับการเปิด/ปิดใช้ค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable()

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

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

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

  • ควรรวมตัวรับสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near Field Communications (NFC)
  • [C-0-1] ต้องใช้ API ของ android.nfc.NdefMessage และ android.nfc.NdefRecord แม้ว่าจะไม่มีการรองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc เนื่องจากคลาสต่างๆ แสดงถึงรูปแบบการนำเสนอข้อมูลที่ขึ้นอยู่กับโปรโตคอล

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

  • [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
  • ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ดังต่อไปนี้ได้
  • [C-1-2] ต้องสามารถทำหน้าที่เป็นผู้อ่าน/ผู้เขียนฟอรัม NFC (ตามที่กำหนดโดยข้อกำหนดทางเทคนิคของฟอรัม NFC NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFC (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • ประเภทแท็กฟอรัม NFC 1, 2, 3, 4, 5 (กำหนดโดยฟอรัม NFC)

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

  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นหา NFC

  • ควรอยู่ในโหมดการค้นหา NFC ขณะอุปกรณ์ทำงานอยู่โดยที่หน้าจอทำงานอยู่และปลดล็อกหน้าจอแล้ว
  • ควรสามารถอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC ของ Thinfilm

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

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

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

  • [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
  • [C-2-2] ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK

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

  • [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hcef
  • [C-3-2] ต้องใช้ API การจำลองการ์ด NFC ตามที่ระบุไว้ใน Android SDK

หากการใช้งานอุปกรณ์รวมการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทผู้อ่าน/ผู้เขียนเนื้อหาจะมีลักษณะดังนี้

  • [C-4-1] ต้องใช้ Android API ที่สอดคล้องกันตามที่ Android SDK ระบุไว้
  • [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่าฟีเจอร์นี้ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจึงไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5 ความสามารถของเครือข่ายขั้นต่ำ

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

  • [C-0-1] ต้องมีการสนับสนุนเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ กล่าวโดยเจาะจงคือ การนำอุปกรณ์มาใช้จะต้องมีการสนับสนุนข้อมูลมาตรฐานที่ความเร็ว 200 Kbit/วินาทีอย่างน้อย 1 อย่าง ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต และ PAN บลูทูธ
  • ควรรวมการสนับสนุนมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
  • อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
  • [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API แบบเนทีฟ เช่น ซ็อกเก็ต AF_INET6
  • [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
  • ต้องตรวจสอบให้แน่ใจว่าการสื่อสารของ IPv6 มีความเสถียรเหมือนกับ IPv4 ตัวอย่างเช่น
    • [C-0-4] ต้องใช้การเชื่อมต่อ IPv6 ในโหมด Doze
    • [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่เข้ากันได้กับ IPv6 ซึ่งใช้อายุการใช้งานของ RA อย่างน้อย 180 วินาที
  • [C-0-6] ต้องมีแอปพลิเคชันของบุคคลที่สามที่มีการเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยที่ไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ เกิดขึ้นภายในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort) และ NDK API เช่น getsockname() หรือ IPV6_PKTINFO ต้องส่งคืนที่อยู่ IP และพอร์ตที่ใช้จริงเพื่อส่งและรับแพ็กเก็ตในเครือข่าย

ระดับการสนับสนุน IPv6 ที่ต้องการจะขึ้นอยู่กับประเภทเครือข่าย ดังที่ปรากฏในข้อกำหนดต่อไปนี้

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

  • [C-1-1] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi

การใช้งานอุปกรณ์รองรับอีเทอร์เน็ตจะเป็นดังนี้

  • [C-2-1] ต้องรองรับการทำงานแบบสแต็กคู่ในอีเทอร์เน็ต

หากอุปกรณ์รองรับข้อมูลเครือข่ายมือถือ ก็จะเป็นดังนี้

  • ควรรองรับการดำเนินการ IPv6 (IPv6 เท่านั้นและอาจรองรับแบบ 2 สแต็ก) ในเครือข่ายมือถือ

หากการติดตั้งใช้งานอุปกรณ์รองรับเครือข่ายมากกว่า 1 ประเภท (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ)

  • [C-3-1] ต้องตรงตามข้อกำหนดข้างต้นในแต่ละเครือข่ายพร้อมกันเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 ประเภท

7.4.6 การตั้งค่าการซิงค์

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

  • [C-0-1] ต้องเปิดการตั้งค่าการซิงค์อัตโนมัติหลักไว้โดยค่าเริ่มต้นเพื่อให้เมธอด getMasterSyncAutomatically() แสดงค่าเป็น "true"

7.4.7 ประหยัดอินเทอร์เน็ต

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

  • [SR] แนะนำอย่างยิ่งให้ใช้โหมดประหยัดอินเทอร์เน็ต

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

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

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

  • [C-2-1] ต้องส่งค่า RESTRICT_BACKGROUND_STATUS_DISABLED สำหรับ ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] ต้องไม่ออกอากาศ ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
  • [C-2-3] ต้องมีกิจกรรมที่จัดการ Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS แต่อาจใช้งานโดยไม่มีการดำเนินการ

7.4.8 องค์ประกอบความปลอดภัย

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

  • [C-1-1] ต้องแจกแจงผู้อ่านองค์ประกอบความปลอดภัยที่ใช้ได้เมื่อเรียกใช้เมธอด android.se.omapi.SEService.getReaders()

7.5 กล้อง

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

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.camera.any
  • [C-1-2] ต้องเป็นไปได้ที่แอปพลิเคชันจะจัดสรร RGBA_8888 บิตแมป 3 รายการพร้อมๆ กับขนาดของภาพที่เกิดจากเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์ ในขณะที่กล้องเปิดอยู่เพื่อการแสดงตัวอย่างเบื้องต้นและการจับภาพ
  • [C-1-3] ต้องตรวจสอบว่า Intent การจัดการแอปพลิเคชันกล้องเริ่มต้นที่ติดตั้งไว้ล่วงหน้า MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE หรือ MediaStore.ACTION_VIDEO_CAPTURE มีหน้าที่นำตำแหน่งของผู้ใช้ในข้อมูลเมตาของรูปภาพออกก่อนที่จะส่งไปยังแอปพลิเคชันที่ใช้รับข้อมูลเมื่อแอปพลิเคชันที่ใช้รับไม่มี ACCESS_FINE_LOCATION

7.5.1 กล้องหลัง

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

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

  • ควรมีกล้องหลัง

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

  • [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera และ android.hardware.camera.any
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย 2 เมกะพิกเซล
  • ควรใช้การโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง (ไม่ต่างจากซอฟต์แวร์แอปพลิเคชัน)
  • อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
  • อาจรวมแฟลชด้วย

หากกล้องมีแฟลช ให้ทำดังนี้

  • [C-2-1] โคมไฟแฟลชต้องไม่ติดสว่างในขณะที่มีการลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback บนพื้นผิวการแสดงตัวอย่างของกล้อง เว้นแต่แอปพลิเคชันได้เปิดใช้แฟลชอย่างชัดแจ้งด้วยการเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของวัตถุ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้ Camera.PreviewCallback เท่านั้น

7.5.2 กล้องหน้า

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

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

  • อาจมีกล้องหน้า

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

  • [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
  • [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวในอุปกรณ์ก็ตาม
  • [C-1-4] ภาพตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุ เมื่อแอปพลิเคชันปัจจุบันขออย่างชัดแจ้งให้หมุนจอแสดงผลของกล้องผ่านการเรียกเมธอด android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน ตัวอย่างจะต้องมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์หากแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนจอแสดงผลของกล้องผ่านการเรียกเมธอด android.hardware.Camera.setDisplayOrientation()
  • [C-1-5] ต้องไม่มิเรอร์ภาพนิ่งหรือสตรีมวิดีโอล่าสุดที่บันทึกกลับไปยังการเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ
  • [C-1-6] ต้องจำลองภาพที่แสดงในมุมมองหลังการถ่ายทำในลักษณะเดียวกับสตรีมภาพตัวอย่างจากกล้อง
  • อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

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

  • [C-2-1] ตัวอย่างจากกล้องจะต้องสะท้อนในแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์

7.5.3 กล้องภายนอก

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

  • อาจรวมการรองรับกล้องภายนอกที่ไม่จำเป็นต้องเชื่อมต่อตลอดเวลา

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

  • [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
  • [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ตโฮสต์ USB
  • [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องด้วยอุปกรณ์กล้องภายนอกที่จับต้องได้ที่เชื่อมต่ออยู่ ดูรายละเอียดการทดสอบ CTS ของกล้องได้ที่ source.android.com
  • ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้สามารถโอนสตรีมคุณภาพสูงที่ไม่เข้ารหัส (เช่น สตรีมภาพดิบหรือสตรีมที่บีบอัดแบบอิสระ)
  • อาจรองรับกล้องหลายตัว
  • อาจรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง

หากระบบรองรับการเข้ารหัสวิดีโอโดยใช้กล้อง ให้ทำดังนี้

  • [C-2-1] การใช้งานอุปกรณ์ต้องเข้าถึงสตรีม MJPEG / สตรีมที่ไม่เข้ารหัสพร้อมกัน (QVGA หรือความละเอียดสูงกว่า)

7.5.4 การทำงานของ API กล้องถ่ายรูป

Android มีแพ็กเกจ API 2 แพ็กเกจสำหรับเข้าถึงกล้อง API ใหม่ android.hardware.camera2 จะแสดงการควบคุมกล้องในระดับต่ำกว่าแก่แอป ซึ่งรวมถึงโฟลว์การถ่ายภาพ/การสตรีมแบบ Zero Copy ที่มีประสิทธิภาพ การควบคุมการรับแสง ค่าเกน การเพิ่มไวท์บาลานซ์ การแปลงสี การตัดเสียงรบกวน การทำให้คมชัด และอีกมากมาย

ระบบทำเครื่องหมายแพ็กเกจ API เวอร์ชันเก่า android.hardware.Camera ว่าเลิกใช้งานใน Android 5.0 แล้ว แต่แพ็กเกจ API ดังกล่าวจะยังพร้อมใช้งานสำหรับแอป การใช้งานอุปกรณ์ Android ต้องดูแลให้มีการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK

ฟีเจอร์ทั้งหมดที่มีการใช้งานร่วมกันระหว่างคลาส android.hardware.camera ที่เลิกใช้งานแล้วและแพ็กเกจ android.hardware.camera2 ใหม่ต้องมีประสิทธิภาพและคุณภาพเท่ากันใน API ทั้ง 2 รุ่น เช่น หากใช้การตั้งค่าที่เทียบเท่ากัน ความเร็วในการโฟกัสอัตโนมัติและความแม่นยำต้องเหมือนกัน และคุณภาพของภาพที่ถ่ายจะต้องเหมือนกัน ฟีเจอร์ที่ต้องอาศัยความหมายที่ต่างกันของ API ทั้งสองไม่จำเป็นต้องมีความเร็วหรือคุณภาพตรงกัน แต่ควรจับคู่ให้ใกล้เคียงมากที่สุด

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

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับตัวอย่างข้อมูลที่ให้ไว้กับ Callback ของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เพิ่มเติมเมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกเมธอด onPreviewFrame() และรูปแบบแสดงตัวอย่างคือ YCbCr_420_SP ซึ่งข้อมูลในไบต์[] ที่ส่งไปยัง onPreviewFrame() นั่นคือ NV21 ต้องเป็นค่าเริ่มต้น
  • [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่แสดงด้วยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างจากกล้องทั้งสำหรับกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (กล้องและโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อาจใช้พิกเซลดั้งเดิมรูปแบบใดก็ได้ แต่การใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
  • [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่โฆษณาความสามารถ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities
  • [C-0-5] ต้องใช้ กล้องถ่ายรูป API แบบเต็มซึ่งรวมอยู่ในเอกสารประกอบของ Android SDK โดยไม่คำนึงว่าอุปกรณ์ดังกล่าวจะมีระบบโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือความสามารถอื่นๆ หรือไม่ ตัวอย่างเช่น กล้องที่ไม่มีการโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback ที่ลงทะเบียนไว้ (แม้ว่าจะไม่เกี่ยวข้องกับกล้องที่ไม่โฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าหลักการนี้มีผลกับกล้องหน้า เช่น แม้ว่ากล้องหน้าส่วนใหญ่ไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับของ API ยังคงต้อง “ไม่อัปเดต” ตามที่อธิบายไว้
  • [C-0-6] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละรายการที่กำหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters และคลาส android.hardware.camera2.CaptureRequest ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยึดตามหรือรับรู้ค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() ที่ไม่ใช่ค่าคงที่ที่ระบุเป็นค่าคงที่ใน android.hardware.Camera.Parameters กล่าวคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และ "ต้องไม่รองรับ" ประเภทพารามิเตอร์กล้องที่กำหนดเอง ตัวอย่างเช่น การใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการสร้างภาพที่มีช่วงไดนามิกกว้าง (HDR) ต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR
  • [C-0-7] ต้องรายงานระดับการรองรับพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ในระดับที่เหมาะสมตามที่อธิบายไว้ใน Android SDK และรายงานแฟล็กฟีเจอร์เฟรมเวิร์กที่เหมาะสม
  • [C-0-8] ต้องประกาศความสามารถของกล้อง android.hardware.camera2 แต่ละตัวผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศแฟล็กฟีเจอร์ที่เหมาะสมด้วย ต้องกำหนดธงทำเครื่องหมายฟีเจอร์หากอุปกรณ์กล้องที่แนบอยู่รองรับฟีเจอร์นี้
  • [C-0-9] ต้องเผยแพร่เจตนาของ Camera.ACTION_NEW_PICTURE ทุกครั้งที่กล้องถ่ายภาพใหม่และมีการเพิ่มรูปภาพดังกล่าวลงในที่เก็บสื่อแล้ว
  • [C-0-10] ต้องเผยแพร่เจตนาของ Camera.ACTION_NEW_VIDEO ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของรูปภาพไปยังร้านค้าสื่อแล้ว
  • [C-0-11] ต้องมีกล้องทุกตัวที่เข้าถึงผ่าน android.hardware.Camera API ที่เลิกใช้งานแล้วและเข้าถึงผ่าน android.hardware.camera2 API ได้เช่นกัน
  • [C-SR] สำหรับอุปกรณ์ที่กล้อง RGB หลายตัวหันไปในทิศทางเดียวกัน ขอแนะนำเป็นอย่างยิ่งให้รองรับอุปกรณ์กล้องแบบลอจิคัลที่แสดงความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปทางทิศทางนั้นเสมือนเป็นอุปกรณ์ย่อยจริง

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

  • [C-1-1] ต้องใช้ API กล้องดังกล่าวโดยใช้ android.hardware.camera2 API
  • อาจให้แท็กผู้ให้บริการและ/หรือส่วนขยายแก่ android.hardware.camera2 API

7.5.5 การวางแนวกล้อง

หากอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าว

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

7.6 หน่วยความจำและพื้นที่เก็บข้อมูล

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

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

  • [C-0-1] ต้องมี Download Manager ที่แอปพลิเคชันสามารถใช้ดาวน์โหลดไฟล์ข้อมูลได้ และต้องดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ลงในตำแหน่ง "แคช" เริ่มต้นได้

7.6.2 พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน

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

  • [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยแอปพลิเคชัน หรือเรียกอีกอย่างหนึ่งว่า "ที่จัดเก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน" หรือตามเส้นทาง Linux "/sdcard" ก็ติดอยู่
  • [C-0-2] ต้องกำหนดค่าเป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งต่อเชื่อมโดยค่าเริ่มต้น หรือที่เรียกว่า "พร้อมใช้งานทันที" ไม่ว่าจะใช้งานพื้นที่เก็บข้อมูลกับคอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ดดิจิทัลที่ปลอดภัย)
  • [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันบนเส้นทาง Linux sdcard โดยตรง หรือรวมลิงก์สัญลักษณ์ของ Linux จาก sdcard ไปยังจุดต่อเชื่อมจริง
  • [C-0-4] ต้องบังคับใช้สิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนี้ตามที่ระบุไว้ใน SDK
  • [C-0-5] ต้องเปิดใช้พื้นที่เก็บข้อมูลที่กำหนดขอบเขตโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กําหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในสถานการณ์ต่อไปนี้
    • เวลาที่ติดตั้งแอปก่อนที่อุปกรณ์จะอัปเกรดเป็น API ระดับ 29 ไม่ว่า API เป้าหมายของแอปจะเป็นอะไรก็ตาม
    • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
    • เมื่อแอปได้รับสิทธิ์android.permission.WRITE_MEDIA_STORAGE
  • [C-0-6] ต้องกำหนดให้แอปที่เปิดใช้พื้นที่เก็บข้อมูลที่กำหนดขอบเขตไม่มีสิทธิ์เข้าถึงไฟล์ระบบไฟล์โดยตรงนอกไดเรกทอรีเฉพาะแอปพลิเคชัน ตามที่เมธอด Context API แสดงผล เช่น Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() และ Context.getObbDirs()
  • [C-0-7] ต้องปกปิดข้อมูลเมตาของตำแหน่ง เช่น แท็ก GPS Exif ซึ่งจัดเก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore ยกเว้นในกรณีที่แอปการโทรจะถือสิทธิ์ ACCESS_MEDIA_LOCATION

การใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้ข้อใดข้อหนึ่งต่อไปนี้

  • พื้นที่เก็บข้อมูลแบบถอดได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
  • ส่วนหนึ่งของพื้นที่เก็บข้อมูลภายใน (แบบถอดออกได้) ตามที่ใช้ในโครงการโอเพนซอร์ส Android (AOSP)

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

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

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

  • ควรใช้การใช้งาน AOSP ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายใน
  • อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

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

  • [C-2-1] ต้องอนุญาตเฉพาะแอปพลิเคชัน Android ที่ติดตั้งล่วงหน้าและสิทธิ์ WRITE_MEDIA_STORAGE ในการเขียนไปยังพื้นที่เก็บข้อมูลภายนอกสำรอง ยกเว้นเมื่อเขียนไปยังไดเรกทอรีเฉพาะแพ็กเกจหรือภายใน URI ซึ่งแสดงผลด้วยการเริ่มการทำงานของ Intent ของ ACTION_OPEN_DOCUMENT_TREE
  • [C-2-2] ต้องกำหนดให้มีการมอบการเข้าถึงโดยตรงที่เชื่อมโยงกับสิทธิ์ android.permission.WRITE_MEDIA_STORAGE แก่แอปที่ผู้ใช้มองเห็นเท่านั้นเมื่อมีการให้สิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ด้วย
  • [SR] แนะนำอย่างยิ่งว่าแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าและสิทธิ์ต่างๆ จะใช้ API สาธารณะ เช่น MediaStore เพื่อโต้ตอบกับอุปกรณ์จัดเก็บข้อมูล แทนที่จะใช้การเข้าถึงโดยตรงที่ได้รับจาก android.permission.WRITE_MEDIA_STORAGE

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

  • [C-3-1] ต้องระบุกลไกในการเข้าถึงข้อมูลในที่จัดเก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันจากคอมพิวเตอร์โฮสต์
  • ควรแสดงเนื้อหาจากเส้นทางพื้นที่เก็บข้อมูลทั้ง 2 แบบอย่างโปร่งใสผ่านบริการสแกนสื่อของ Android และ android.provider.MediaStore
  • อาจใช้พื้นที่เก็บข้อมูลแบบ USB จำนวนมาก แต่ควรใช้ Media Transfer Protocol เพื่อให้เป็นไปตามข้อกำหนดนี้

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

  • ควรเข้ากันได้กับโฮสต์ Android MTP อ้างอิงอย่าง Android File Transfer
  • ควรรายงานคลาสของอุปกรณ์ USB เป็น 0x00
  • ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

7.6.3 พื้นที่เก็บข้อมูลแบบ Adoptable

หากอุปกรณ์ควรมีลักษณะเป็นอุปกรณ์เคลื่อนที่ซึ่งต่างจากทีวี การใช้งานอุปกรณ์จะเป็นดังนี้

  • [SR] แนะนําอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลแบบนํามาใช้ในพื้นที่ที่มั่นคงในระยะยาว เนื่องจากการเลิกเชื่อมต่อโดยไม่ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย

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

7.7 USB

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

  • ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB

7.7.1 โหมดอุปกรณ์ต่อพ่วง USB

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

  • [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB ประเภท A หรือ Type-C แบบมาตรฐานได้
  • [C-1-2] ต้องรายงานค่า iSerialNumber ที่ถูกต้องในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ผ่าน android.os.Build.SERIAL
  • [C-1-3] ต้องตรวจหาที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจพบการเปลี่ยนแปลงในโฆษณาหากอุปกรณ์รองรับ USB Type-C
  • [SR] พอร์ตควรใช้รูปแบบ USB แบบ micro-B, micro-AB หรือ Type-C เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
  • [SR] พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวที่เป็นธรรมชาติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้แสดงผลได้อย่างถูกต้องเมื่ออุปกรณ์วางอยู่ในแนวเดียวกับพอร์ตที่ด้านล่าง เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
  • [SR] ควรใช้การสนับสนุนเพื่อดึงกระแสไฟฟ้า 1.5 A ในระหว่างการส่งเสียงร้อง HS และการจราจรของข้อมูลตามที่ระบุไว้ในข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้สามารถอัปเกรดเป็นรุ่นแพลตฟอร์มในอนาคตได้
  • [SR] ขอแนะนำเป็นอย่างยิ่งให้ไม่รองรับวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของซิงก์/แหล่งที่มาอาจทำให้เกิดปัญหาเกี่ยวกับความสามารถในการทำงานร่วมกันกับที่ชาร์จหรืออุปกรณ์ที่รองรับวิธีการส่งพลังงาน USB แบบมาตรฐาน แม้จะเรียกว่า "แนะนำอย่างยิ่ง" แต่สำหรับ Android เวอร์ชันต่อๆ ไป เราอาจต้องใช้อุปกรณ์ type-C ทั้งหมดเพื่อรองรับความสามารถในการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C แบบมาตรฐาน
  • [SR] แนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงานเมื่อรองรับโหมดโฮสต์ Type-C USB และ USB
  • ควรรองรับการส่งพลังงานสำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่น เช่น โหมดจอแสดงผลเอาต์
  • ควรใช้ Android Open Accessory (AOA) API และข้อมูลจำเพาะตามที่ระบุไว้ในเอกสาร Android SDK

หากอุปกรณ์มีพอร์ต USB และใช้ข้อกำหนดเฉพาะ AOA การดำเนินการดังกล่าวจะดำเนินการดังนี้

  • [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
  • [C-2-2] คลาสที่จัดเก็บข้อมูลจำนวนมากของ USB ต้องมีสตริง "android" ที่ส่วนท้ายของคำอธิบายอินเทอร์เฟซ iInterface สตริงของที่เก็บข้อมูล USB ขนาดใหญ่

7.7.2 โหมดโฮสต์ USB

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

  • [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ของฮาร์ดแวร์ android.hardware.usb.host
  • [C-1-2] ต้องมีการสนับสนุนเพื่อเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ ต้องเป็นอย่างใดอย่างหนึ่งต่อไปนี้
    • มีพอร์ต C ในอุปกรณ์หรือจัดส่งพร้อมสายซึ่งปรับพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ให้เป็นพอร์ต USB type-C มาตรฐาน (อุปกรณ์ USB Type-C)
    • มีประเภท A ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ไปยังพอร์ต USB type-A มาตรฐาน
    • มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรจัดส่งพร้อมกับสายที่ปรับให้เข้ากับพอร์ตประเภท A มาตรฐาน
  • [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB ประเภท A หรือพอร์ตไมโคร AB เป็นพอร์ต type-C (เต้ารับ)
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะอยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของการแก้ไขข้อกำหนดของสาย USB Type-C และหัวเสียบ 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสไฟขาออกของพอร์ตชาร์จดาวน์สตรีม(CDP) ตามที่ระบุไว้ในข้อมูลจำเพาะการชาร์จแบตเตอรี่ USB การแก้ไขที่ 1.2 สำหรับขั้วต่อ Micro-AB
  • ควรใช้และสนับสนุนมาตรฐาน USB Type-C

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

  • [C-2-1] ต้องรองรับคลาส USB HID
  • [C-2-2] ต้องรองรับการตรวจหาและการแมปช่องข้อมูล HID ต่อไปนี้ซึ่งระบุไว้ในตารางการใช้งาน USB HID และคำขอใช้คำสั่งเสียงกับค่าคงที่ KeyEvent ดังต่อไปนี้
    • รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0E9): KEYCODE_VOLUME_UP
    • รหัสการใช้งานหน้าการใช้งาน (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • รหัสการใช้หน้าการใช้งาน (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF)

  • [C-3-1] ต้องจดจำอุปกรณ์ MTP (Media Transfer Protocol) ที่เชื่อมต่อจากระยะไกล และทําให้เนื้อหาเข้าถึงได้ผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT

หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C ไหม

  • [C-4-1] ต้องใช้ฟังก์ชันพอร์ตบทบาทแบบคู่ตามที่ระบุไว้ในข้อกำหนดเฉพาะ USB Type-C (ส่วนที่ 4.5.1.3.3)
  • [SR] แนะนำอย่างยิ่งให้รองรับ DisplayPort และควรรองรับอัตราข้อมูล USB SuperSpeed และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
  • [SR] แนะนำอย่างยิ่งให้ไม่รองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก A ของการแก้ไขข้อกำหนดของสาย USB Type-C และขั้วต่อ 1.2
  • ควรใช้โมเดล Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบของอุปกรณ์ ตัวอย่างเช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK

7.8 เสียง

7.8.1 ไมโครโฟน

หากอุปกรณ์มีไมโครโฟน จะมีผลดังนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-1-2] ต้องมีคุณสมบัติตรงตามข้อกำหนดในการบันทึกเสียงในส่วนที่ 5.4
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] ขอแนะนำเป็นอย่างยิ่งให้สนับสนุนการบันทึกด้วยอัลตราซาวด์ระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 7.8.3

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

  • [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-2-2] ต้องใช้ API การบันทึกเสียงอย่างน้อยเป็นไม่ปฏิบัติการตามส่วนที่ 7

7.8.2 เอาต์พุตเสียง

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

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
  • [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] แนะนำอย่างเข้มงวดเพื่อรองรับการเล่นอัลตราซาวด์ในระยะใกล้ตามที่อธิบายไว้ในส่วนที่ 7.8.3

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

  • [C-2-1] ต้องไม่รายงานฟีเจอร์ android.hardware.audio.output
  • [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นไม่ต้องดำเนินการอย่างน้อย

สำหรับวัตถุประสงค์ของส่วนนี้ "พอร์ตเอาต์พุต" เป็นอินเทอร์เฟซทางกายภาพ เช่น ช่องเสียบหูฟัง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลทางวิทยุ เช่น บลูทูธ, Wi-Fi หรือเครือข่ายมือถือ จะไม่ถือว่าเป็น "พอร์ตเอาต์พุต"

7.8.2.1 พอร์ตเสียงแอนะล็อก

เพื่อให้เข้ากันได้กับชุดหูฟังและอุปกรณ์เสริมเสียงอื่นๆ ที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศของ Android หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต สิ่งต่อไปนี้

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมพอร์ตเสียงอย่างน้อย 1 พอร์ตเพื่อใช้เป็นช่องเสียบหูฟัง 3.5 มม. แบบ 4 ตัวนำ

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

  • [C-1-1] ต้องรองรับการเล่นเสียงในหูฟังสเตอริโอและชุดหูฟังสเตอริโอพร้อมไมโครโฟน
  • [C-1-2] ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับ PIN-out ของ CTIA
  • [C-1-3] ต้องรองรับการตรวจจับและการจับคู่กับรหัสคีย์สำหรับค่าอิมพีแดนซ์ 3 ช่วงต่อไปนี้ระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียง
    • ไม่เกิน 70 โอห์ม: KEYCODE_HEADSETHOOK
    • 210-290 โอห์ม: KEYCODE_VOLUME_UP
    • 360-680 โอห์ม: KEYCODE_VOLUME_DOWN
  • [C-1-4] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อมีการเสียบปลั๊ก แต่เมื่อรายชื่อติดต่อทั้งหมดบนปลั๊กสัมผัสส่วนที่เกี่ยวข้องบนช่องเสียบแล้วเท่านั้น
  • [C-1-5] ต้องสามารถขับเคลื่อนได้อย่างน้อย 150mV ± 10% ของแรงดันไฟฟ้าขาออกต่ออิมพีแดนซ์ลำโพง 32 โอห์ม
  • [C-1-6] ต้องมีแรงดันไฟฟ้าของมุมเอียงของไมโครโฟนระหว่าง 1.8 โวลต์ ~ 2.9 โวลต์
  • [C-1-7] ต้องตรวจหาและจับคู่กับรหัสคีย์สำหรับช่วงของค่าอิมพีแดนซ์ที่เท่ากันระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียงดังต่อไปนี้:
    • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอพร้อมไมโครโฟน

หากอุปกรณ์มีช่องเสียบหูฟัง 3.5 มม. ตัวนำ 4 ตัวและรองรับไมโครโฟน รวมถึงออกอากาศ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนค่าพิเศษเป็น 1 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

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

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

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

7.8.3 ใกล้อัลตราซาวด์

เสียงใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz

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

  • ต้องรายงานการรองรับความสามารถในการส่งเสียงแบบเกือบอัลตราซาวด์อย่างถูกต้องผ่าน AudioManager.getProperty API ดังต่อไปนี้

หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION และ UNPROCESSED ต้องเป็นไปตามข้อกำหนดต่อไปนี้

  • [C-1-1] การตอบสนองกำลังไฟฟ้าเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องไม่มากกว่า 15 dB ต่ำกว่าการตอบสนองที่ 2 kHz
  • [C-1-2] ไมโครโฟนที่มีอัตราส่วนสัญญาณต่อเสียงรบกวนที่ไม่ถ่วงน้ำหนักสูงกว่า 18.5 kHz ต่อ 20 kHz สำหรับเสียง 19 kHz ที่ -26 dBFS ต้องไม่เกิน 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง" ให้ทำดังนี้

  • [C-2-1] การตอบสนองเฉลี่ยของลำโพงที่มีความเร็ว 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB ต่ำกว่าการตอบสนองที่ 2 kHz

7.8.4 ความสมบูรณ์ของสัญญาณ

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

  • ควรมีเส้นทางสัญญาณเสียงที่ไม่มีข้อบกพร่องสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์มือถือ ตามที่ระบุโดยข้อบกพร่อง 0 รายการซึ่งวัดในระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "Automated Glitch Test"

การทดสอบต้องใช้ดองเกิลเสียงวนซ้ำที่ใช้กับช่องเสียบ 3.5 มม. โดยตรง และ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

ปัจจุบัน OboeTester รองรับเส้นทาง AAudio ดังนั้นคุณควรทดสอบชุดค่าผสมต่อไปนี้เพื่อหาข้อบกพร่องโดยใช้ AAudio

โหมด Perf การแชร์ อัตราการสุ่มตัวอย่างออก ในชาน เพลงชวนคุย
เวลาในการตอบสนองต่ำ พิเศษ ไม่ได้ระบุ 1 2
เวลาในการตอบสนองต่ำ พิเศษ ไม่ได้ระบุ 2 1
เวลาในการตอบสนองต่ำ แชร์ ไม่ได้ระบุ 1 2
เวลาในการตอบสนองต่ำ แชร์ ไม่ได้ระบุ 2 1
ไม่มี แชร์ 48000 1 2
ไม่มี แชร์ 48000 2 1
ไม่มี แชร์ 44100 1 2
ไม่มี แชร์ 44100 2 1
ไม่มี แชร์ 16000 1 2
ไม่มี แชร์ 16000 2 1

สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อเสียงรบกวน (SNR) และการบิดเบี้ยวรวมฮาร์โมนิก (THD) สำหรับไซน์ 2000 Hz

ตัวแปรสัญญาณ THD SNR
ลำโพงหลักในตัว วัดโดยใช้ไมโครโฟนอ้างอิงภายนอก &lt; 3.0% >= 50 เดซิเบล
ไมโครโฟนหลักในตัว วัดโดยใช้ลำโพงอ้างอิงภายนอก &lt; 3.0% >= 50 เดซิเบล
ช่องเสียบแอนะล็อกในตัว 3.5 มม. ผ่านการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ < 1% >= 60 เดซิเบล
อะแดปเตอร์ USB ที่ให้มาพร้อมกับโทรศัพท์ ได้รับการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ &lt; 1.0% >= 60 เดซิเบล

7.9 Virtual Reality

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

7.9.1 โหมด Virtual Reality

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

7.9.2 โหมด Virtual Reality - ประสิทธิภาพสูง

หากอุปกรณ์รองรับโหมด VR อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องมี 2 Physical Core เป็นอย่างน้อย
  • [C-1-2] ต้องประกาศฟีเจอร์ android.hardware.vr.high_performance
  • [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
  • [C-1-4] ต้องรองรับ OpenGL ES 3.2
  • [C-1-5] ต้องรองรับ android.hardware.vulkan.level 0
  • ควรรองรับ android.hardware.vulkan.level 1 ขึ้นไป
  • [C-1-6] ต้องใช้ EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่มีให้บริการ
  • [C-1-8] ต้องใช้ GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] แนะนําอย่างยิ่งให้ใช้ GL_EXT_external_buffer, GL_EXT_EGL_image_array และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image และเปิดเผยในรายการส่วนขยาย Vulkan ที่มีให้บริการ
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงกลุ่มคิว Vulkan อย่างน้อย 1 กลุ่มซึ่ง flags มีทั้ง VK_QUEUE_GRAPHICS_BIT และ VK_QUEUE_COMPUTE_BIT และ queueCount ต้องมีอย่างน้อย 2 กลุ่ม
  • [C-1-7] GPU และจอแสดงผลต้องสามารถซิงค์ข้อมูลการเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ ซึ่งจะทำให้การแสดงผลแบบสลับตาของเนื้อหา VR ที่ 60 FPS พร้อมบริบทในการแสดงภาพ 2 รายการจะแสดงโดยไม่มีอาร์ติแฟกต์ที่ฉีกขาดซึ่งมองเห็นได้
  • [C-1-9] ต้องใช้การรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องใช้การรองรับ AHardwareBuffer ที่มีแฟล็กการใช้งาน AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ร่วมกันสำหรับรูปแบบต่อไปนี้ AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT เป็นอย่างน้อย
  • [C-SR] แนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีมากกว่า 1 เลเยอร์ แฟล็ก และรูปแบบที่ระบุใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps โดยบีบอัดให้มีค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 1920 x1080 จำนวน 4 อินสแตนซ์ที่ 30 fps-10 Mbps หรือ 1920 x 1920 x 20fps 2 อินสแตนซ์)
  • [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920 x 1080 ที่ 30 fps ที่บีบอัดให้มีความเร็วเฉลี่ย 10 Mbps และควรสามารถถอดรหัส 3840 x 2160 bps ที่อินสแตนซ์ 10-20 fps ถึง 30 fps ถึง 30 fps เป็นความเร็วเฉลี่ย 3840 x 2160 ที่อัตรา 30 fps ถึง 30 fps เท่ากับค่าเฉลี่ย 3840 x 2160 ที่ 30 fps ถึง 20 fps
  • [C-1-13] ต้องรองรับ API ของ HardwarePropertiesManager.getDeviceTemperatures และแสดงผลค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
  • [C-1-14] ต้องมีหน้าจอแบบฝัง และความละเอียดต้องมีขนาดอย่างน้อย 1920 x 1080
  • [C-SR] แนะนำอย่างยิ่งให้ใช้ความละเอียดในการแสดงผลอย่างน้อย 2560 x 1440
  • [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
  • [C-1-17] จอแสดงผลต้องรองรับโหมดความต่อเนื่องต่ำที่มีความต่อเนื่อง ≤ 5 มิลลิวินาที ความต่อเนื่องหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
  • [C-1-18] ต้องรองรับบลูทูธ 4.2 และการขยายความยาวของข้อมูลบลูทูธ LE หัวข้อ 7.4.3
  • [C-1-19] ต้องรองรับและรายงานประเภทช่องทางโดยตรงอย่างถูกต้องสำหรับเซ็นเซอร์เริ่มต้นทุกประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับประเภทแชแนลโดยตรง TYPE_HARDWARE_BUFFER สำหรับประเภทแชแนลโดยตรงทั้งหมดที่แสดงข้างต้น
  • [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors ตามที่ระบุไว้ในส่วน 7.3.9
  • [C-SR] แนะนำอย่างยิ่งให้สนับสนุนฟีเจอร์ android.hardware.sensor.hifi_sensors
  • [C-1-22] ต้องมีเวลาในการตอบสนองของการเคลื่อนไหวจากต้นทางถึงปลายทางเป็นโฟตอนไม่สูงกว่า 28 มิลลิวินาที
  • [C-SR] แนะนำอย่างยิ่งให้มีการเปลี่ยนแปลงการเคลื่อนไหวจากต้นทางถึงปลายทางต่อเวลาในการตอบสนองของโฟตอนไม่สูงกว่า 20 มิลลิวินาที
  • [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวและความสว่างของพิกเซลสีขาวในสถานะคงที่อย่างน้อย 85%
  • [C-SR] แนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
  • อาจให้แกนเอกสิทธิ์เฉพาะสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนของแกน CPU ที่มีเฉพาะในแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า

หากระบบรองรับแกนพิเศษ แกนหลักจะเป็นดังนี้

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

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

เกณฑ์ด้านประสิทธิภาพขั้นต่ำและเกณฑ์กำลังมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป

8.1 ความสม่ำเสมอของประสบการณ์ของผู้ใช้

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

8.2 ประสิทธิภาพการเข้าถึงไฟล์ I/O

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

  • ประสิทธิภาพการเขียนตามลำดับ วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการเขียนแบบสุ่ม วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
  • ประสิทธิภาพการอ่านตามลำดับ วัดโดยการอ่านไฟล์ 256 MB โดยใช้บัฟเฟอร์การเขียน 10 MB
  • ประสิทธิภาพการอ่านแบบสุ่ม วัดโดยการอ่านไฟล์ 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB

8.3 โหมดประหยัดพลังงาน

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

  • [C-1-1] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับอัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและโหมดประหยัดพลังงาน Doze
  • [C-1-2] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการควบคุมงาน สัญญาณเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสำหรับการสแตนด์บายแอป
  • [C-1-3] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับจำนวนที่เก็บข้อมูลสแตนด์บายแอปที่ใช้สำหรับสแตนด์บายแอป
  • [C-1-4] ต้องใช้ที่เก็บข้อมูลสแตนด์บายแอปและ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] ต้องส่งคืน true สำหรับ PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
  • [C-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
  • [C-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การนำอุปกรณ์ Android ไปใช้อาจจะใช้สถานะกำลังนอนหลับใดๆ หรือทั้งหมด 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)

หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟ S4 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้

  • >

หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟฟ้า S3 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้

  • [C-2-1] ต้องตรงตาม C-1-1 ข้างต้น หรือต้องป้อนสถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่จำเป็นต้องใช้ทรัพยากรระบบ (เช่น หน้าจอ, CPU)

    ในทางกลับกัน ต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรระบบตามที่อธิบายไว้ใน SDK นี้

    เช่น ในขณะที่แอปพลิเคชันของบุคคลที่สามจะขอเปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือให้ CPU ทำงานอย่างต่อเนื่องผ่าน PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่ป้อนสถานะ S3 เว้นแต่ผู้ใช้ได้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ใช้งาน ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน ในช่วงเวลาหนึ่งเมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามทำผ่าน JobScheduler หรือมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ว่าผู้ใช้ได้เปลี่ยนอุปกรณ์ให้เป็นสถานะไม่ใช้งาน ตัวอย่างเหล่านี้ไม่ใช่ตัวอย่างที่ครอบคลุมและ AOSP ใช้สัญญาณการปลุกระบบที่ครอบคลุมซึ่งจะกระตุ้นการปลุกระบบจากสถานะนี้

8.4 การทำบัญชีการใช้พลังงาน

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

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

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

8.5 ประสิทธิภาพที่สม่ำเสมอ

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

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

  • [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด PowerManager.isSustainedPerformanceModeSupported() API

  • ควรรองรับโหมดประสิทธิภาพที่ยั่งยืน

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

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

หากการใช้งานอุปกรณ์มี CPU 2 แกนขึ้นไป การใช้งานจะมีลักษณะดังต่อไปนี้

  • ควรระบุ Core พิเศษอย่างน้อย 1 รายการที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนจะสงวนไว้

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

  • [C-2-1] ต้องรายงานหมายเลขรหัสของแกนพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าจองได้ผ่านเมธอด Process.getExclusiveCores() API
  • [C-2-2] ต้องไม่อนุญาตกระบวนการด้านพื้นที่ของผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อเรียกใช้บนแกนเฉพาะ แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น

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

  • [C-3-1] ต้องส่งคืนรายการที่ว่างเปล่าผ่านเมธอด Process.getExclusiveCores() API

9. ความเข้ากันได้กับโมเดลความปลอดภัย

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

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

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

9.1 สิทธิ์

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

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

  • อาจเพิ่มสิทธิ์เพิ่มเติม หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_FLAG_PRIVILEGED ต้องมอบให้แก่แอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบและภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอปเท่านั้น การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและยึดตามสิทธิ์ที่อยู่ในรายการที่อนุญาตของแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่ได้รับสิทธิ์

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

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

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะสำหรับผู้ใช้เพื่อตัดสินใจว่าจะให้สิทธิ์รันไทม์ตามที่ขอไหม รวมถึงต้องมีอินเทอร์เฟซให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย
  • [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงรายการเดียวเท่านั้น
  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งล่วงหน้า ยกเว้นในกรณีต่อไปนี้
    • แอปจะขอรับความยินยอมจากผู้ใช้ได้ก่อนใช้งาน
    • สิทธิ์รันไทม์เชื่อมโยงกับรูปแบบ Intent ที่มีการตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
  • [C-0-6] ต้องให้สิทธิ์แก่ android.permission.RECOVER_KEYSTORE แก่แอปของระบบที่ลงทะเบียน Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างถูกต้องเท่านั้น Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างเหมาะสมหมายถึง Agent ซอฟต์แวร์ในอุปกรณ์ที่ซิงค์ข้อมูลกับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยซึ่งมีการปกป้องเทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการห้องนิรภัยของ Google Cloud Key เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซที่ส่งผลต่อความรู้เกี่ยวกับหน้าจอล็อก

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

  • [C-0-7] ต้องปฏิบัติตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android เมื่อแอปขอข้อมูลตำแหน่งหรือการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้

    • ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด)
    • ข้อมูลที่ใช้ระบุหรือประมาณตำแหน่งของอุปกรณ์ได้ (เช่น SSID, BSSID, Cell ID, การสแกนหาบลูทูธ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
    • กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจัดประเภทกิจกรรมการเคลื่อนไหวร่างกาย

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

  • [C-0-8] ต้องได้รับความยินยอมจากผู้ใช้ในการอนุญาตให้แอปเข้าถึงข้อมูลตำแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
  • [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มีสิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น ตัวอย่างเช่น TelephonyManager#getServiceState ต้องใช้ android.permission.ACCESS_FINE_LOCATION)

ระบบอาจทำเครื่องหมายสิทธิ์ว่า "จำกัด" ซึ่งจะเปลี่ยนลักษณะการทำงานของสิทธิ์

  • [C-0-10] สิทธิ์ที่มีเครื่องหมายธง hardRestricted ต้องไม่ให้แก่แอป เว้นแต่จะ

    • ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
    • ผู้ใช้มอบหมายบทบาทที่เชื่อมโยงกับสิทธิ์ hardRestricted ให้กับแอป
    • โปรแกรมติดตั้งให้สิทธิ์ hardRestricted แก่แอป
    • แอปได้รับสิทธิ์ hardRestricted ใน Android เวอร์ชันก่อนหน้า

  • [C-0-11] แอปที่มีสิทธิ์ softRestricted ต้องได้รับสิทธิ์เข้าถึงแบบจำกัดเท่านั้น และต้องไม่มีสิทธิ์เข้าถึงโดยสมบูรณ์จนกว่าจะเพิ่มลงในรายการที่อนุญาตตามที่อธิบายไว้ใน SDK ซึ่งกำหนดสิทธิ์เข้าถึงแบบเต็มและแบบจำกัดสำหรับสิทธิ์ softRestricted แต่ละรายการ (เช่น WRITE_EXTERNAL_STORAGE และ READ_EXTERNAL_STORAGE)

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

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

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

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

9.2 การแยก UID และกระบวนการ

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

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

9.3 สิทธิ์ของระบบไฟล์

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

9.4 สภาพแวดล้อมการดำเนินการสำรอง

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

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

  • [C-0-2] รันไทม์ทางเลือกต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ป้องกันด้วยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่าน <uses-permission> Google Analytics

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

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

  • [C-0-5] รันไทม์สำรองต้องไม่เปิด ให้สิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] ต้องไม่เปิดตัว ให้รันไทม์สำรอง หรือให้สิทธิ์ของผู้ใช้ระดับสูง (รูท) หรือรหัสผู้ใช้อื่นๆ แก่แอปพลิเคชันอื่นๆ

  • [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์อื่นไว้ในอิมเมจระบบของการใช้งานอุปกรณ์ ไฟล์ "ต้อง" ต้องรับรองด้วยคีย์ที่ต่างจากคีย์ที่ใช้ในการลงนามแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการใช้งานอุปกรณ์

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

  • [C-0-9] เมื่อแอปพลิเคชันต้องใช้ทรัพยากรอุปกรณ์ที่ได้รับอนุญาตจาก Android ที่เกี่ยวข้อง (เช่น กล้องถ่ายรูป, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้

  • [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่บันทึกความสามารถของแอปพลิเคชันในลักษณะนี้ สภาพแวดล้อมรันไทม์ต้องแสดงสิทธิ์ทั้งหมดที่รันไทม์นั้นเป็นเจ้าของเมื่อทำการติดตั้งแอปพลิเคชันใดๆ ที่ใช้รันไทม์ดังกล่าว

  • รันไทม์สำรองควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android ที่แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

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

9.5 การสนับสนุนผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ

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

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

  • [C-1-1] ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน
  • [C-1-2] สำหรับผู้ใช้แต่ละราย ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API
  • [C-1-3] ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก (หรือที่เรียกอีกชื่อหนึ่งว่า /sdcard) สำหรับอินสแตนซ์ของผู้ใช้แต่ละรายการ
  • [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และการเรียกใช้ในนามของผู้ใช้นั้นๆ ไม่สามารถแสดงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองจะจัดเก็บไว้ในระบบไฟล์หรือวอลุ่มเดียวกันก็ตาม
  • [C-1-5] ต้องเข้ารหัสเนื้อหาในการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บอยู่ในสื่อที่นำออกไม่ได้ซึ่งเข้าถึงได้เฉพาะระบบเท่านั้นหากอุปกรณ์ใช้สื่อแบบถอดได้สำหรับ API การจัดเก็บข้อมูลภายนอก เนื่องจากการดำเนินการนี้จะทำให้พีซีที่เป็นโฮสต์อ่านสื่อไม่ได้ การใช้งานอุปกรณ์จึงจำเป็นจะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

9.6 คำเตือนทาง SMS แบบพรีเมียม

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

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

  • [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปซึ่งกำหนดไว้ในไฟล์ /data/misc/sms/codes.xml ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ที่มีการติดตั้งใช้งานซึ่งเป็นไปตามข้อกำหนดนี้

9.7 ฟีเจอร์ความปลอดภัย

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

แซนด์บ็อกซ์ของ Android ประกอบด้วยฟีเจอร์ที่ใช้ระบบควบคุมการเข้าถึง (MAC) ที่บังคับของ Security-Enhanced Linux (SELinux) การทำแซนด์บ็อกซ์ Seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่เดิม แม้จะใช้งาน SELinux หรือฟีเจอร์ด้านความปลอดภัยอื่นๆ ภายใต้เฟรมเวิร์กของ Android ก็ตาม
  • [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดด้านความปลอดภัยและบล็อกโดยฟีเจอร์ความปลอดภัยที่ใช้งานด้านล่างเฟรมเวิร์ก Android ได้สำเร็จ แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดด้านความปลอดภัยที่ไม่ได้บล็อก ซึ่งส่งผลให้การเจาะช่องโหว่สำเร็จ
  • [C-0-3] ต้องไม่ทำให้ SELinux หรือฟีเจอร์ความปลอดภัยอื่นใดที่ใช้งานต่ำกว่าเฟรมเวิร์ก Android ที่กำหนดค่าได้สำหรับผู้ใช้หรือนักพัฒนาแอป
  • [C-0-4] ต้องไม่อนุญาตแอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) เพื่อกำหนดค่านโยบายที่ละเมิดความเข้ากันได้
  • [C-0-5] ต้องแบ่งเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการให้แคบลงได้ตามที่อธิบายไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
  • [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนลที่อนุญาตให้กรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบหลายเธรด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางเป็นไปตามข้อกำหนดนี้ผ่านการเปิดใช้ seccomp-BPF ที่มีการซิงค์ข้อมูล Threadgroup (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่า Kernel ของ source.android.com

ความสมบูรณ์ของเคอร์เนลและฟีเจอร์การป้องกันตนเองเป็นส่วนสำคัญในการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องใช้กลไกการป้องกันการล้นของสแต็กเคอร์เนล ตัวอย่างของกลไกดังกล่าวคือ CC_STACKPROTECTOR_REGULAR และ CONFIG_CC_STACKPROTECTOR_STRONG
  • [C-0-8] ต้องใช้การป้องกันหน่วยความจำของเคอร์เนลที่เข้มงวด โดยที่โค้ดสั่งการจะเป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวจะเป็นข้อมูลที่สั่งการไม่ได้และเขียนไม่ได้ และข้อมูลที่เขียนได้นั้นไม่สามารถเรียกใช้ได้ (เช่น CONFIG_DEBUG_RODATA หรือ CONFIG_STRICT_KERNEL_RWX)
  • [C-0-9] ต้องใช้การตรวจสอบขอบเขตของขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และเคอร์เนล (เช่น CONFIG_HARDENED_USERCOPY) ในอุปกรณ์ที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป
  • [C-0-10] ต้องไม่เรียกใช้หน่วยความจำพื้นที่ผู้ใช้เมื่อทำงานในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งด้วย API ระดับ 28 ขึ้นไปแต่เดิม
  • [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำของพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึงผู้ใช้สำเนาปกติ (เช่น PAN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งด้วย API ระดับ 28 ขึ้นไปแต่เดิม
  • [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลหากฮาร์ดแวร์มีช่องโหว่ต่อ CVE-2017-5754 ในอุปกรณ์ทั้งหมดที่จัดส่งด้วย API ระดับ 28 ขึ้นไป (เช่น CONFIG_PAGE_TABLE_ISOLATION หรือ CONFIG_UNMAP_KERNEL_AT_EL0)
  • [C-0-13] ต้องใช้การเสริมการคาดการณ์สาขาในกรณีที่ฮาร์ดแวร์มีช่องโหว่ต่อ CVE-2017-5715 ในอุปกรณ์ทั้งหมดที่จัดส่งครั้งแรกด้วย API ระดับ 28 ขึ้นไป (เช่น CONFIG_HARDEN_BRANCH_PREDICTOR)
  • [SR] แนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนลที่จะเขียนเฉพาะในช่วงเริ่มต้นที่มีการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น __ro_after_init)

  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และเพื่อหลีกเลี่ยงการรับแสงที่อาจส่งผลต่อการสุ่ม (เช่น CONFIG_RANDOMIZE_BASE ด้วยเอนโทรปี Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

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

  • [C-SR] แนะนำอย่างยิ่งไม่ให้ปิดใช้ Control-Flow Integrity (CFI), Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) บนคอมโพเนนต์ที่เปิดใช้
  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์พื้นที่ผู้ใช้ที่ละเอียดอ่อนด้านความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan

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

  • [C-1-1] ต้องใช้ SELinux
  • [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
  • [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดที่อนุญาต ซึ่งรวมถึงโดเมนเฉพาะสำหรับอุปกรณ์/ผู้ให้บริการรายใดรายหนึ่ง
  • [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎNeverallow ที่อยู่ในโฟลเดอร์ระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ ไม่อนุญาตทั้งหมดที่มีอยู่ สำหรับโดเมน AOSP SELinux และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
  • [C-1-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไปในแซนด์บ็อกซ์ SELinux ตามแอปพลิเคชันที่มีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
  • ควรเก็บนโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ระบบ/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง และเพิ่มเพิ่มเติมในนโยบายนี้สำหรับการกำหนดค่าเฉพาะอุปกรณ์เท่านั้น

หากมีการเปิดตัวอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว และไม่เป็นไปตามข้อกำหนด [C-1-1] และ [C-1-5] ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านี้อาจได้รับการยกเว้นจากข้อกำหนดเหล่านี้

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

  • [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็นซึ่งเทียบเท่ากับ SELinux

Android มีฟีเจอร์การป้องกันในเชิงลึกหลายอย่างที่เป็นส่วนสำคัญในการรักษาความปลอดภัยของอุปกรณ์

9.8 ความเป็นส่วนตัว

9.8.1 ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

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

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

Android จัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ IncidentManager System API

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

  • [C-0-2] ต้องรวมเฉพาะช่องที่มีเครื่องหมาย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส API ของระบบ IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นนอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์เพิ่มเติมของระบบ ก็อาจใช้ตัวระบุอะตอมอื่นในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2 กำลังบันทึก

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

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

  • [C-0-2] ต้องแสดงและขอความยินยอมจากผู้ใช้อย่างชัดแจ้งซึ่งมีข้อความส่วนใหญ่เหมือนกับ AOSP เมื่อใดก็ตามที่เปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอผ่าน MediaProjection หรือ API ที่เป็นกรรมสิทธิ์ ต้องไม่ให้ค่าตอบแทนแก่ผู้ใช้ในการปิดใช้การแสดงความยินยอมของผู้ใช้ในอนาคต

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

หากการนำอุปกรณ์ไปใช้งานมีฟังก์ชันการทำงานในระบบซึ่งจับภาพเนื้อหาที่แสดงบนหน้าจอ และ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์นอกเหนือจากผ่านทาง System API ContentCaptureService หรือวิธีการเฉพาะอื่นๆ ซึ่งอธิบายไว้ในส่วนที่ 9.8.6 การบันทึกเนื้อหา การดำเนินการดังกล่าวจะดำเนินการดังนี้

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

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

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

9.8.3 การเชื่อมต่อ

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

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

9.8.4 การจราจรของข้อมูลในเครือข่าย

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

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

หากมีการกำหนดเส้นทางการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การใช้งานอุปกรณ์จะมีลักษณะดังนี้

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

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

  • [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว เว้นแต่จะเปิดใช้ VPN โดย Device Policy Controller ผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ซึ่งในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับแจ้งเท่านั้น

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

  • [C-3-1] ต้องปิดใช้การชำระเงินสำหรับผู้ใช้รายนี้สำหรับแอปที่ไม่รองรับบริการ VPN แบบเปิดตลอดเวลาในไฟล์ AndroidManifest.xml ผ่านการตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

9.8.5 ตัวระบุอุปกรณ์

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

  • [C-0-1] ต้องป้องกันไม่ให้มีการเข้าถึงหมายเลขซีเรียลของอุปกรณ์ และ IMEI/MEID, หมายเลขซีเรียลของซิม และหมายเลขประจําตัวสมาชิกอุปกรณ์เคลื่อนที่ระหว่างประเทศ (IMSI) จากแอป เว้นแต่จะเป็นไปตามข้อกําหนดข้อใดข้อหนึ่งต่อไปนี้
    • เป็นแอปของผู้ให้บริการที่ได้รับการรับรองและได้รับการยืนยันโดยผู้ผลิตอุปกรณ์
    • ได้รับสิทธิ์ READ_PRIVILEGED_PHONE_STATE แล้ว
    • มีสิทธิ์ของผู้ให้บริการตามที่ระบุไว้ในสิทธิ์ของผู้ให้บริการ UICC
    • เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับสิทธิ์READ_PHONE_STATE
    • (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดของกฎระเบียบท้องถิ่นที่แอปจะตรวจหาการเปลี่ยนแปลงในข้อมูลประจำตัวของผู้สมัครใช้บริการ

9.8.6 การบันทึกเนื้อหา

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

  • ข้อความและกราฟิกที่แสดงบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน AssistStructure API
  • ข้อมูลสื่อ เช่น เสียงหรือวิดีโอ ที่อุปกรณ์บันทึกหรือเล่น
  • เหตุการณ์การป้อนข้อมูล (เช่น การกดแป้น เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)
  • เหตุการณ์อื่นๆ ที่แอปพลิเคชันส่งไปยังระบบผ่าน Content Capture API หรือ API ที่เป็นกรรมสิทธิ์และมีความสามารถคล้ายกัน

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

  • [C-1-1] ต้องเข้ารหัสข้อมูลทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้ Android File-Based Encryption หรือการเข้ารหัสใดๆ ที่ระบุไว้เป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
  • [C-1-2] ต้องไม่สำรองข้อมูลข้อมูลดิบหรือที่เข้ารหัสโดยใช้วิธีการสำรองข้อมูลของ Android หรือวิธีอื่นๆ ในการสำรองข้อมูล
  • [C-1-3] ต้องส่งเฉพาะข้อมูลดังกล่าวและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัวเท่านั้น กลไกการรักษาความเป็นส่วนตัวหมายถึง "รายการที่อนุญาตให้ใช้การวิเคราะห์แบบรวมและป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละรายเท่านั้น" เพื่อป้องกันไม่ให้ข้อมูลต่อผู้ใช้แต่ละรายการสามารถตรวจสอบได้ (เช่น ใช้งานโดยใช้เทคโนโลยี Differential Privacy เช่น RAPPOR)
  • [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวของผู้ใช้ (เช่น Account) ในอุปกรณ์ ยกเว้นกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล
  • [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับแอปอื่นๆ เว้นแต่จะได้รับคำยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการแชร์
  • [C-1-6] ต้องให้เงินแก่ผู้ใช้ในการลบข้อมูลดังกล่าวที่ ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์เก็บรวบรวม หากข้อมูลดังกล่าวได้รับการจัดเก็บไว้ในรูปแบบใดๆ บนอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รวมถึงบริการที่ใช้ System API ContentCaptureService หรือบริการที่เป็นกรรมสิทธิ์ใดๆ ซึ่งบันทึกข้อมูลตามที่อธิบายไว้ข้างต้น การใช้งานเหล่านั้นจะมีลักษณะดังนี้

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

  • [C-SR] แนะนำอย่างยิ่งให้แยกองค์ประกอบของบริการที่บันทึกเนื้อหาไว้ เช่น ไม่เชื่อมโยงบริการหรือรหัสกระบวนการแชร์ จากองค์ประกอบอื่นๆ ของระบบ ยกเว้นรายการต่อไปนี้

    • โทรศัพท์, รายชื่อติดต่อ, UI ระบบ และสื่อ

9.8.7 การเข้าถึงคลิปบอร์ด

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

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

9.8.8 ตำแหน่ง

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

  • [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมที่ชัดเจนจากผู้ใช้หรือการเริ่มต้นจากผู้ใช้
  • [C-0-2] ต้องให้สิทธิ์เข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่งแก่ผู้ใช้ ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้การสแกนหา Wi-Fi/บลูทูธเพื่อระบุตำแหน่ง
  • [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ API บายพาสตำแหน่งฉุกเฉิน [LocationRequest.setLocationSettings ignored()] เป็นเซสชันฉุกเฉินที่ผู้ใช้เป็นผู้เริ่ม (เช่น กดหมายเลข 911 หรือส่งข้อความไปที่ 911)
  • [C-0-4] ต้องรักษาความสามารถของ ช่วยเหลือฉุกเฉินของ API การข้ามตำแหน่งของอุปกรณ์ไว้โดยไม่เปลี่ยนการตั้งค่า
  • [C-0-5] ต้องกำหนดเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งของผู้ใช้โดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.9 การเข้ารหัสพื้นที่เก็บข้อมูล

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

9.9.1 Direct Boot

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

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

  • [C-0-2] ระบบต้องเผยแพร่ Intent ของ ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED เพื่อส่งสัญญาณแจ้งแอปพลิเคชัน Direct Boot Aware ว่าผู้ใช้มีตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE)

9.9.2 ข้อกำหนดการเข้ารหัส

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

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

9.9.3 การเข้ารหัสตามไฟล์

อุปกรณ์ที่เข้ารหัส:

  • [C-1-1] ต้องเปิดเครื่องโดยไม่ขอให้ผู้ใช้กรอกข้อมูลเข้าสู่ระบบ และอนุญาตให้แอป Direct Boot ที่รู้จักเข้าถึงพื้นที่เก็บข้อมูล Device Encrypted (DE) หลังจากเผยแพร่ข้อความ ACTION_LOCKED_BOOT_COMPLETED
  • [C-1-2] ต้องอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสข้อมูลรับรอง (CE) เฉพาะหลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยป้อนข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และระบบเผยแพร่ข้อความ ACTION_USER_UNLOCKED
  • [C-1-3] ต้องไม่เสนอวิธีปลดล็อกพื้นที่เก็บข้อมูลที่มีการป้องกัน CE โดยไม่ต้องมีข้อมูลเข้าสู่ระบบที่ผู้ใช้มีให้หรือคีย์เอสโครว์ที่ลงทะเบียนไว้
  • [C-1-4] ต้องใช้การเปิดเครื่องที่ได้รับการยืนยันและตรวจสอบว่าคีย์ DE เชื่อมโยงกับรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์แบบเข้ารหัส
  • [C-1-5] ต้องเข้ารหัสเนื้อหาไฟล์โดยใช้ AES-256-XTS หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวคีย์เข้ารหัส 256 บิตที่ทำงานในโหมด XTS ความยาวเต็มของคีย์คือ 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ที่ https://github.com/google/adiantum
  • [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS หรือ Adiantum

  • [C-1-12] ต้องใช้ AES-256-XTS สำหรับเนื้อหาในไฟล์ และใช้ AES-256-CBC-CTS สำหรับชื่อไฟล์ (แทน Adiantum) หากอุปกรณ์มีวิธีการมาตรฐานการเข้ารหัสขั้นสูง (AES) คำสั่ง AES คือส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86 หากอุปกรณ์ไม่มีคำสั่ง AES อุปกรณ์นั้นอาจใช้ Adiantum

  • คีย์ที่ช่วยปกป้องพื้นที่เก็บข้อมูล CE และ DE มีดังนี้

  • [C-1-7] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์

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

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

  • ควรทำให้แอปสำคัญที่ติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเซนเจอร์) Direct Boot

โปรเจ็กต์โอเพนซอร์ส Android ติดตั้งใช้งานฟีเจอร์นี้ที่ต้องการโดยอิงตามเคอร์เนล "fscrypt" ของ Linux ฟีเจอร์การเข้ารหัส

9.10 ความสมบูรณ์ของอุปกรณ์

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

  • [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะ Bootloader อนุญาตให้มีการกะพริบอิมเมจของระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ระบบใหม่นี้

  • [C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

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

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

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ของแพลตฟอร์ม android.software.verified_boot
  • [C-1-2] ต้องทำการยืนยันในทุกลำดับการเปิดเครื่อง
  • [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือและไปจนถึงพาร์ติชันระบบ
  • [C-1-4] ต้องใช้การยืนยันในแต่ละขั้นตอนเพื่อตรวจสอบความถูกต้องและความน่าเชื่อถือของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
  • [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่มีความรัดกุมเช่นเดียวกับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
  • [C-1-6] ต้องไม่อนุญาตให้เปิดเครื่องเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้ยินยอมที่จะลองเปิดเครื่องต่อไป ซึ่งในกรณีนี้ ต้องไม่ใช้ข้อมูลจากการบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยัน
  • [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้จะปลดล็อก Bootloader อย่างชัดแจ้ง
  • [C-SR] หากมีชิปหลายชิปในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์ภาพพิเศษ) เราขอแนะนำให้ขั้นตอนการเปิดเครื่องของชิปแต่ละชิปดังกล่าวในแต่ละระยะในการเปิดเครื่อง
  • [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะ เพื่อจัดเก็บว่า Bootloader ถูกปลดล็อกหรือไม่ พื้นที่เก็บข้อมูลที่มีการงัดแงะหมายความว่า Bootloader ตรวจสอบได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งผู้ใช้ขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนอนุญาตให้เปลี่ยนจากโหมดล็อก Bootloader เป็นโหมดปลดล็อก Bootloader
  • [C-1-10] ต้องใช้การป้องกันย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น การเปิดเครื่อง พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่มีการปลอมแปลงในการจัดเก็บข้อมูลเมตาที่ใช้กำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
  • [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่ได้รับสิทธิ์ทั้งหมดกับเชนความน่าเชื่อถือที่รูทในพาร์ติชันที่มีการป้องกันโดยการเปิดเครื่องที่ได้รับการยืนยัน
  • [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันอาร์ติแฟกต์ที่เรียกใช้ได้ซึ่งโหลดโดยแอปที่ได้รับสิทธิ์จากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์) ก่อนที่จะเรียกใช้ หรือขอแนะนำว่าอย่าเรียกใช้เลย
  • ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์ถาวร (เช่น โมเด็ม กล้อง) และควรใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะในการจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันขั้นต่ำที่อนุญาต

หากมีการเปิดตัวอุปกรณ์โดยไม่รองรับระบบ C-1-8 ถึง C-1-10 ใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำในที่เก็บ external/avb/ ซึ่งสามารถผสานรวมเข้ากับ Bootloader ที่ใช้สำหรับการโหลด Android

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

หากอุปกรณ์รองรับ Android Protected Verifyation API

  • [C-3-1] ต้องรายงาน true สำหรับ ConfirmationPrompt.isSupported() API

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

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

9.11 คีย์และข้อมูลเข้าสู่ระบบ

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

  • [C-0-1] ต้องอนุญาตให้นำเข้าหรือสร้างคีย์ได้อย่างน้อย 8,192 คีย์
  • [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องมีการจำกัดอัตรา และต้องมีอัลกอริทึม Exponential Backoff หากเกินจากความพยายามที่ล้มเหลวเกิน 150 ครั้ง ความล่าช้าจะต้องมีอย่างน้อย 24 ชั่วโมงต่อความพยายามหนึ่งครั้ง
  • ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้

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

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

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

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

9.11.1 การล็อกหน้าจอและการตรวจสอบสิทธิ์ที่ปลอดภัย

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

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

  • [C-SR] แนะนำอย่างยิ่งให้ตั้งค่าวิธีใดวิธีหนึ่งต่อไปนี้เป็นวิธีการตรวจสอบสิทธิ์หลัก:
    • PIN ที่เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
    • รูปแบบการปัดในตารางกริดที่มีจุด 3x3 พอดี

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

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

  • [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน Requiring User Authentication For Key Use
  • [C-2-2] ต้องปลดล็อกคีย์ทั้งหมดเพื่อให้แอปนักพัฒนาซอฟต์แวร์บุคคลที่สามใช้เมื่อผู้ใช้ปลดล็อกหน้าจอล็อกที่ปลอดภัย เช่น คีย์ทั้งหมดต้องพร้อมใช้งานสำหรับแอปนักพัฒนาซอฟต์แวร์ของบุคคลที่สามผ่าน API ที่เกี่ยวข้อง เช่น createConfirmDeviceCredentialIntent และ setUserAuthenticationRequired

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

  • [C-3-1] เอนโทรปีของอินพุตที่มีความยาวสั้นที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) และระบุไว้ใน AOSP
  • [C-3-4] วิธีการตรวจสอบสิทธิ์ใหม่จะต้องปิดใช้เมื่อแอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ของคุณภาพที่เข้มงวดมากกว่า PASSWORD_QUALITY_SOMETHING
  • [C-3-5] วิธีการตรวจสอบสิทธิ์แบบใหม่จะต้องกลับไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยให้ผู้ใช้ทราบอย่างชัดเจนว่าจะไม่มีการสำรองข้อมูลข้อมูลบางอย่างเพื่อรักษาความเป็นส่วนตัวของข้อมูล

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

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในหัวข้อ 7.3.10 สำหรับความสะดวก
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ซึ่งอิงตามข้อมูลลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์การล็อกโดยเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() ด้วยแฟล็กข้อมูลไบโอเมตริกที่เกี่ยวข้อง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับขั้นสูงตามที่อธิบายไว้ในส่วนที่ 7.3.10 ให้ทำดังนี้

  • [C-5-1] ต้องปิดใช้เมธอดนี้หากแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-5-2] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) หลังจากหมดเวลาการไม่มีความเคลื่อนไหวเป็นเวลา 4 ชั่วโมง ระบบจะรีเซ็ตระยะหมดเวลาเนื่องจากไม่มีการใช้งานหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ
  • [C-5-3] วิธีการนี้ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อกำหนดที่ขึ้นต้นด้วย C-8 ในส่วนนี้ด้านล่าง

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

  • [C-6-1] ผู้ใช้ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ซึ่งอิงตามข้อมูลลับที่ทราบและตรงตามข้อกำหนดจึงจะถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
  • [C-6-2] วิธีการใหม่จะต้องปิดใช้และอนุญาตให้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำปลดล็อกหน้าจอได้เฉพาะเมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-6-3] ผู้ใช้ต้องได้รับคำถามสำหรับวิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่งที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 4 ชั่วโมงหรือน้อยกว่านั้น
  • [C-6-4] วิธีการใหม่ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง

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

  • [C-7-1] ต้องระบุข้อมูลที่ชัดเจนในเมนูการตั้งค่าและในหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ หรือสามารถปลดล็อกได้โดยเอเจนต์ความน่าเชื่อถือ เช่น AOSP เป็นไปตามข้อกำหนดนี้โดยการแสดงข้อความอธิบายสำหรับ "การตั้งค่าล็อกอัตโนมัติ" และ "ปุ่มเปิด/ปิดล็อกทันที" ในเมนูการตั้งค่าและไอคอนแยกความแตกต่างได้บนหน้าจอล็อก
  • [C-7-2] ต้องเคารพและติดตั้งใช้งาน API ของเอเจนต์ความน่าเชื่อถือทั้งหมดในคลาส DevicePolicyManager เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
  • [C-7-3] ต้องไม่ใช้ฟังก์ชัน TrustAgentService.addEscrowToken() โดยสมบูรณ์ในอุปกรณ์ที่ใช้เป็นอุปกรณ์หลักส่วนตัว (เช่น อุปกรณ์พกพา) แต่อาจใช้ฟังก์ชันเต็มรูปแบบในอุปกรณ์ที่มักใช้ร่วมกัน (เช่น Android TV หรืออุปกรณ์ Automotive)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่เก็บคีย์การเข้ารหัสหรือโทเค็นเอสโครว์ไว้ในอุปกรณ์เดียวกับที่ใช้คีย์ เช่น อนุญาตให้ใช้คีย์ที่จัดเก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้ในทีวี
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นคนกลางเพื่อถอดรหัสพื้นที่เก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีหนึ่ง
  • [C-7-8] ผู้ใช้ต้องได้รับการยืนยันตัวตนสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ หรือรหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น เว้นแต่ว่าข้อกังวลด้านความปลอดภัยของผู้ใช้ (เช่น การรบกวนผู้ขับขี่)
  • [C-7-9] ผู้ใช้จะต้องได้รับการยืนยันตัวตนสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) หลังจากหมดเวลาการไม่มีความเคลื่อนไหวเป็นเวลา 4 ชั่วโมง เว้นแต่จะคำนึงถึงความปลอดภัยของผู้ใช้ (เช่น การรบกวนผู้ขับขี่) ระบบจะรีเซ็ตระยะหมดเวลาเนื่องจากไม่มีการใช้งานหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ
  • [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องปฏิบัติตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
  • [C-7-11] ต้องไม่อนุญาตให้ TrustAgents ในอุปกรณ์หลักส่วนตัว (เช่น มือถือ) ในการปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกแล้วเป็นเวลาสูงสุด 4 ชั่วโมง การใช้งาน TrustManagerService ตามค่าเริ่มต้นใน AOSP จะเป็นไปตามข้อกำหนดนี้
  • [C-7-12] ต้องใช้ช่องทางการสื่อสารที่มีการเข้ารหัสเพื่อความปลอดภัย (เช่น UKEY2) เพื่อส่งโทเค็นคนกลางจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย

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

  • [C-8-1] ต้องปิดใช้เมธอดใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-8-2] ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ DevicePolicyManager.setPasswordExpirationTimeout() ตั้งไว้
  • [C-8-3] ต้องไม่เปิดเผย API สำหรับแอปของบุคคลที่สามเพื่อเปลี่ยนสถานะการล็อก

9.11.2 StrongBox

ระบบคีย์สโตร์ของ Android ช่วยให้นักพัฒนาแอปสามารถจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะและสภาพแวดล้อมการดำเนินการที่แยกต่างหากตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 ถึง C-1-11 ด้านล่างเป็นข้อกำหนดที่อุปกรณ์จะต้องมีคุณสมบัติตรงตาม StrongBox

การใช้งานอุปกรณ์ที่มีหน่วยประมวลผลที่ปลอดภัยโดยเฉพาะ

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

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

  • [C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE

  • [C-1-2] ต้องระบุฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะที่ใช้ในการสนับสนุนคีย์สโตร์และการตรวจสอบสิทธิ์ผู้ใช้ที่ปลอดภัย ฮาร์ดแวร์รักษาความปลอดภัยโดยเฉพาะอาจถูกใช้เพื่อวัตถุประสงค์อื่นๆ ได้เช่นกัน

  • [C-1-3] ต้องมี CPU แบบแยกส่วนที่ไม่แชร์แคช, DRAM, โปรเซสเซอร์ร่วม หรือทรัพยากรหลักอื่นๆ กับตัวประมวลผลแอปพลิเคชัน (AP)

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

  • [C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำพอสมควร (+-10%) ที่ไม่เอื้อต่อการควบคุมโดย AP

  • [C-1-6] ต้องมีโปรแกรมสร้างตัวเลขสุ่มจริงที่สร้างผลลัพธ์ที่มีการกระจายอย่างสม่ำเสมอและคาดเดาไม่ได้

  • [C-1-7] ต้องมีระดับการป้องกันการงัดแงะ รวมถึงความต้านทานต่อการเข้าถึงทางกายภาพและการแตกร้าว

  • [C-1-8] ต้องมีความต้านทานต่อช่องทางข้าง รวมถึงความต้านทานการรั่วไหลของข้อมูลทางไฟฟ้า จังหวะเวลา รังสีแม่เหล็กไฟฟ้า และช่องทางการแผ่รังสีความร้อน

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

  • หากต้องการตรวจสอบการปฏิบัติตามข้อกำหนดกับ [C-1-3] จนถึง [C-1-9] การติดตั้งใช้งานอุปกรณ์ ให้ทำดังนี้

    • [C-1-10] ต้องรวมฮาร์ดแวร์ที่ผ่านการรับรองตาม Secure IC Protection Profile BSI-CC-PP-0084-2014 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศ ซึ่งรวมการประเมินช่องโหว่ที่มีโอกาสโจมตีสูงตามการใช้เกณฑ์มาตรฐานของโอกาสการโจมตีในสมาร์ทการ์ด
    • [C-1-11] ต้องรวมเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับชาติซึ่งรวมการประเมินช่องโหว่ของศักยภาพในการโจมตีสูงตามการใช้เกณฑ์ร่วมกันของโอกาสในการโจมตีกับสมาร์ทการ์ด
    • [C-SR] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ประเมินโดยใช้เป้าหมายด้านความปลอดภัย, Evaluation Assurance Level (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในการเผยแพร่ในอนาคต

  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ป้องกันการโจมตีแบบบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox สามารถรั่วไหลข้อมูลลับ เพื่อข้ามข้อกำหนดด้านความปลอดภัยที่ใช้งานได้ หรือเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการใช้ IAR คืออนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านหลักของผู้ใช้ผ่าน IAuthSecret HAL

9.12 การลบข้อมูล

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

  • [C-0-1] ต้องระบุกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ข้อมูลผู้ใช้
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่เป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
  • [C-0-4] ต้องทริกเกอร์ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ด้านบน กระบวนการเมื่อ DevicePolicyManager.wipeData() API เรียกใช้โดยแอปตัวควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลัก
  • อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น

9.13 โหมดปลอดภัยเปิดเครื่อง

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

การใช้งานอุปกรณ์มีดังนี้

  • [SR] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง

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

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

  • [C-1-2] ต้องให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้

  • ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยจากเมนูเปิดเครื่องโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเปิดเครื่องปกติ

9.14 การแยกระบบยานพาหนะ

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายรถยนต์ เช่น CAN Bus

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

9.15 แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" ดูรายละเอียดแพ็กเกจการเรียกเก็บเงินที่เกี่ยวข้องกับผู้ให้บริการเครือข่ายมือถือผ่าน SubscriptionManager.setSubscriptionPlans()

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

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

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

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

10.1 ชุดเครื่องมือทดสอบความเข้ากันได้

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

  • [C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) จากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS และการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ

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

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

  • [C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การใช้งานการอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้มากที่สุดเท่าที่จะเป็นไปได้

10.2 ผู้ตรวจสอบ CTS

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

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

  • [C-0-1] ต้องดำเนินการกับทุกกรณีที่เกี่ยวข้องในเครื่องมือยืนยัน CTS อย่างถูกต้อง

CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางชนิดด้วย

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

  • [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีตัวตรวจวัดความเร่ง ตัวตรวจวัดความเร่งจะต้องดำเนินการกับกรอบการทดสอบตัวตรวจวัดความเร่งอย่างถูกต้องใน CTS Verifier

ระบบอาจข้ามหรือละเว้นกรอบการทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับในเอกสารคำจำกัดความความเข้ากันได้นี้

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

11. ซอฟต์แวร์ที่อัปเดตได้

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

    • การดาวน์โหลด "ผ่านอากาศ (OTA)" จะมีการอัปเดตแบบออฟไลน์ผ่านรีบูต
    • อัปเดต "Tethered" ผ่าน USB จากโฮสต์ PC
    • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนพื้นที่เก็บข้อมูลแบบถอดได้

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

  • [C-0-3] การอัปเดตทั้งหมดต้องมีการลงชื่อ และกลไกการอัปเดตในอุปกรณ์ต้องตรวจสอบการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์

  • [C-SR] เราขอแนะนำอย่างยิ่งให้แฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

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

  • [C-1-1] ต้องรองรับการดาวน์โหลด OTA ที่มีการอัปเดตแบบออฟไลน์ผ่านรีบูต

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

นอกจากนี้ การใช้งานอุปกรณ์ควรรองรับการอัปเดตระบบ A/B AOSP ใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการเปิดเครื่อง

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

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

Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ หากระบบย่อยของการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin ระบบจะดำเนินการต่อไปนี้

  • [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

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

หากต้องการดูสรุปการเปลี่ยนแปลงของแต่ละส่วน ให้ทำดังนี้

  1. บทนำ
  2. ประเภทอุปกรณ์
  3. ซอฟต์แวร์
  4. การจัดแพ็กเกจแอปพลิเคชัน
  5. มัลติมีเดีย
  6. เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
  7. ความเข้ากันได้ของฮาร์ดแวร์
  8. ประสิทธิภาพและศักยภาพ
  9. โมเดลความปลอดภัย
  10. การทดสอบความเข้ากันได้กับซอฟต์แวร์
  11. ซอฟต์แวร์ที่อัปเดตได้
  12. บันทึกการเปลี่ยนแปลงเอกสาร
  13. ติดต่อเรา

12.1 เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง

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

  • CDD
    การเปลี่ยนแปลงที่สำคัญในข้อกำหนดด้านความเข้ากันได้

  • เอกสาร
    การเปลี่ยนแปลงที่เกี่ยวข้องหรือสร้างขึ้นใหม่

เพื่อการแสดงผลที่ดีที่สุด ให้เพิ่มพารามิเตอร์ของ URL pretty=full และ no-merges ต่อท้าย URL ของบันทึกการเปลี่ยนแปลง

13. ติดต่อเรา

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