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

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

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

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

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

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

เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 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
    • แท็บ: การใช้งานแท็บเล็ต 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] ต้องมีหน้าจอขนาดแนวทแยงมุมจริงอย่างน้อย 2.5 นิ้ว
  • [7.1.1.3/H-SR] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้มีโอกาสในการเปลี่ยนขนาดการแสดงผล (ความหนาแน่นของหน้าจอ)
  • [7.1.5/H-0-1] ต้องมีการรองรับโหมดความเข้ากันได้ของแอปพลิเคชันแบบเดิม ซึ่งติดตั้งใช้งานโดยโค้ดโอเพนซอร์สของ Android ต้นทาง กล่าวคือ การใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่จะเปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนลักษณะการทำงานของโหมดความเข้ากันได้
  • [7.2.1/H-0-1] ต้องมีการรองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม
  • [7.2.3/H-0-1] ต้องมีฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ
  • [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดค้างและเหตุการณ์ปกติของฟังก์ชันกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันเบื้องหน้า
  • [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
  • [7.3.1/H-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.9.1/H-1-1] ต้องประกาศฟีเจอร์ android.software.vr.mode

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

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

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

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

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

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

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

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

  • [5.1.2/H-0-1] AMR-NB
  • [5.1.2/H-0-2] AMR-WB

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

  • [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.4.1/H-0-1] ต้องติดตั้งใช้งาน android.webkit.Webview API โดยสมบูรณ์
  • [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
  • [3.8.1/H-SR] ขอแนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัดและวิดเจ็ตในแอป
  • [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.4/H-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย

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

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

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

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

  • [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.15/H-1-1] ต้องรองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน

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/วินาที
  • [8.3/H-0-1] แอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze ต้องปรากฏต่อผู้ใช้ปลายทาง
  • [8.3/H-0-2] อัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและ Doze ต้องไม่เบี่ยงเบนไปจากโครงการโอเพนซอร์สของ Android

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

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

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

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

หากการใช้งานอุปกรณ์ทีวีมีเครื่องวัดการหมุนรวมอยู่ด้วย ให้ทำดังนี้

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

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

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

หากอุปกรณ์ทีวีเป็นแบบ 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 AVC
  • [5.2/T-0-2] VP8

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

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

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

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

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

  • [5.3/T-SR] MPEG-2

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

  • [5.3.4/T-1-1] ต้องรองรับ High Profile Level 4.2 และโปรไฟล์การถอดรหัสแบบ HD 1080p (ที่ 60 FPS)
  • [5.3.4/T-1-2] ต้องถอดรหัสวิดีโอที่มีโปรไฟล์ HD ทั้ง 2 โปรไฟล์ได้ตามที่ระบุไว้ในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐาน โปรไฟล์หลัก หรือโปรไฟล์ระดับสูงระดับ 4.2

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

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

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

  • [5.3.5/T-2-1] ตัวแปลงรหัสต้องรองรับโปรไฟล์หลักของระดับ Main10 ระดับ 5

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

  • [5.3.6/T-1-1] ต้องรองรับโปรไฟล์การถอดรหัส HD 1080p60

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

  • [5.3.6/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส HD 720p60

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

  • [5.3.7/T-1-1] ต้องรองรับความลึกของสี 8 บิตและควรรองรับ VP9 Profile 2 (10 บิต)

หากการใช้อุปกรณ์โทรทัศน์รองรับตัวแปลงรหัส VP9, โปรไฟล์ 1080p และการเข้ารหัสฮาร์ดแวร์ VP9 จะมีการดำเนินการต่อไปนี้

  • [5.3.7/T-2-1] ต้องรองรับ 60 FPS สำหรับ 1080p

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

  • [5.8/T-SR] ขอแนะนำอย่างยิ่งให้รองรับการถอดรหัสสตรีมที่ปลอดภัยพร้อมกัน ขอแนะนำเป็นอย่างยิ่งให้ถอดรหัสแบบ 2 ไอน้ำพร้อมกันเป็นอย่างน้อย

หากอุปกรณ์เป็นอุปกรณ์ Android TV และรองรับความละเอียดระดับ 4K ระบบจะดำเนินการดังต่อไปนี้

  • [5.8/T-1-1] ต้องรองรับ HDCP 2.2 สำหรับจอแสดงผลภายนอกแบบมีสายทั้งหมด

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

  • [5.8/T-2-1] ต้องรองรับ HDCP 1.4 สำหรับจอแสดงผลภายนอกแบบมีสายทั้งหมด

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

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

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.2.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/วินาที

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

  • [8.3/T-0-2] อัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดสแตนด์บายแอปและ Doze ต้องไม่เบี่ยงเบนไปจากโครงการโอเพนซอร์สของ Android

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

  • [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.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 แกน

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

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

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

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

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] ต้องมีฟังก์ชัน Home และอาจจัดให้มีฟังก์ชัน "กลับ" และ "ล่าสุด"

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

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

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

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

  • [7.3.3/A-1-1] รุ่นเทคโนโลยี GNSS ต้องเป็นปี "2017" ขึ้นไป

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

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

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

  • [7.3.11/A] ควรระบุอุปกรณ์ปัจจุบันเป็น SENSOR_TYPE_GEAR

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

  • [7.3.11.2/A-0-1] ต้องรองรับโหมดกลางวัน/กลางคืนที่กำหนดไว้เป็น SENSOR_TYPE_NIGHT
  • [7.3.11.2/A-0-2] ค่าของแฟล็ก SENSOR_TYPE_NIGHT ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตเซ็นเซอร์แสงแวดล้อม

  • เซ็นเซอร์แสงแวดล้อมที่อยู่ข้างใต้อาจเหมือนกับ Photometer

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

  • [7.3.11.4/A-0-1] ต้องระบุความเร็วของยานพาหนะที่กำหนดไว้เป็น SENSOR_TYPE_CAR_SPEED

  • [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] ควรรองรับ Message Access Profile (MAP)

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

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

หากใช้อุปกรณ์ 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)

การใช้งานอุปกรณ์ Automotive ต้องรองรับการเข้ารหัสวิดีโอต่อไปนี้

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

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

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

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

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

2.5.3 ซอฟต์แวร์

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

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

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

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

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

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

  • [3.14/A-0-1] ต้องระบุเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วนที่ 3.14

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

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

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

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

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

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

  • [9.5/A-1-1] ต้องระบุบัญชีผู้มาเยือนที่อนุญาตฟังก์ชันทั้งหมดของระบบในรถโดยที่ผู้ใช้ไม่ต้องเข้าสู่ระบบ

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

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

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

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

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

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

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

2.4.1 ฮาร์ดแวร์

ขนาดหน้าจอ

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

หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ (ส่วนที่ 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 ใช้ไม่ได้กับแท็บเล็ต

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 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้

3.1.1. ส่วนขยาย Android

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

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

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

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

เช่น

acme/myproduct/
mydevice:8.0/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_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ซีเรียล หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องมีพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ทุกเครื่องที่มี MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^([a-zA-Z0-9]{6,20})$”
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม 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._-,]+$”

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

3.2.3.1 จุดประสงค์ของแอปพลิเคชันหลัก

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

  • [C-0-1] การใช้งานอุปกรณ์ต้องมีแอปพลิเคชัน คอมโพเนนต์บริการ หรือเครื่องจัดการเหล่านี้อย่างน้อย 1 ตัว สำหรับรูปแบบตัวกรอง 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 android.provider.Telephony.ACTION_CHANGE_DEFAULT เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น

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

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

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

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

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

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

3.2.4 กิจกรรมในจอแสดงผลรอง

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

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

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติในจอแสดงผลรอง รวมถึงจอแสดงผลหลักและจอแสดงผลรองจะมี android.util.DisplayMetrics ที่แตกต่างกัน ดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้ใช้กิจกรรมที่ปรับขนาดไม่ได้ (ซึ่งมี resizeableActivity=false ใน AndroidManifest.xml) และแอปที่กำหนดเป้าหมายเป็น API ระดับ 23 หรือต่ำกว่าในจอแสดงผลรอง

หากการใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม 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-4] ต้องรองรับ ABI 32 บิตที่เทียบเท่า หากมีการสนับสนุน ABI แบบ 64 บิต
  • [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 ที่จัดทำเอกสารและอธิบายไว้ในเอกสารประกอบเกี่ยวกับ Android NDK ABI Management เวอร์ชันล่าสุด และต้องรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)

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

    • libaaudio.so (รองรับเสียงแบบเสียงเนทีฟ)
    • 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 (ห้องสมุดคณิตศาสตร์)
    • 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 NDK รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม

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

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

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

    • วิธีการสำหรับ SWP และ SWPB
    • คำสั่ง SETEND
    • การดำเนินการเพื่อกีดขวาง CP15ISB, CP15DSB และ CP15DMB

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

  • [C-2-1] ต้องรวมบรรทัดต่อไปนี้ใน /proc/cpuinfo เมื่ออ่านโดยแอปพลิเคชัน ARM 32 บิตเพื่อให้เข้ากันได้กับแอปพลิเคชันที่สร้างขึ้นโดยใช้ Android NDK เวอร์ชันเดิม

    • Features: ตามด้วยรายการฟีเจอร์เสริมของ CPU ARMv7 ที่อุปกรณ์รองรับ
    • CPU architecture: ตามด้วยจำนวนเต็มที่อธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)

  • ไม่ควรเปลี่ยน /proc/cpuinfo เมื่ออ่านโดยแอปพลิเคชัน ARM 64 บิตหรือที่ไม่ใช่ ARM

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

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

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

  • [C-1-1] ต้องรายงาน android.software.webview
  • [C-1-2] ต้องใช้บิลด์ของโปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางใน Android 8.0 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

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

ลักษณะการทำงานของ 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 ขึ้นไป แอปดังกล่าวจะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป

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

3.6 เนมสเปซ API

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

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

กล่าวคือ

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

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

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

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

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

หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซของแพ็กเกจรายการใดรายการหนึ่งข้างต้น (เช่น โดยการเพิ่มฟังก์ชันใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือเพิ่ม API ใหม่) ผู้ติดตั้งใช้งานควรไปที่ 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
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36MB
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
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
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
160 dpi (mdpi) 48MB
213 dpi (tvdpi) 80MB
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
160 dpi (mdpi) 80MB
213 dpi (tvdpi) 96MB
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 เริ่มต้นที่รองรับการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้

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

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

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

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

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

3.8.2 วิดเจ็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อเจตจำนง 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
  • [C-SR] แนะนำอย่างยิ่งให้ใช้การกดแป้น HOME ค้างไว้เป็นการโต้ตอบที่กำหนดนี้

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

  • อาจแสดงรายการล่าสุดที่เชื่อมโยงเป็นกลุ่มที่ย้ายไปด้วยกัน

  • [C-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 แบบเต็มของภาษาละติน กรีก และซีริลลิก รวมถึงช่วงภาษาละตินแบบขยาย A, B, C และ D และรูปอักขระทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0
  • ควรสนับสนุนอีโมจิผิวสีและอีโมจิที่หลากหลายสำหรับครอบครัวตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51

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

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

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

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

  • [C-1-1] ต้องใช้โหมดหลายหน้าต่างดังกล่าวตามลักษณะการทำงานของแอปพลิเคชันและ API ที่อธิบายไว้ในเอกสารสนับสนุนโหมดหลายหน้าต่างของ Android SDK และเป็นไปตามข้อกำหนดต่อไปนี้
  • [C-1-2] แอปพลิเคชันสามารถระบุได้ว่าทำงานในโหมดหลายหน้าต่างในไฟล์ AndroidManifest.xml ได้หรือไม่ ไม่ว่าจะผ่านการตั้งค่าแอตทริบิวต์ android:resizeableActivity เป็น true หรือโดยปริยายด้วยการใช้ targetSdkVersion > 24 แอปที่ตั้งค่าแอตทริบิวต์นี้เป็น false อย่างชัดเจนในไฟล์ Manifest ต้องไม่เปิดขึ้นในโหมดหลายหน้าต่าง แอปเก่าที่มี targetSdkVersion < 24 ที่ไม่ได้ตั้งค่าแอตทริบิวต์ android:resizeableActivity นี้อาจเปิดในโหมดหลายหน้าต่างได้ แต่ระบบต้องแสดงคำเตือนว่าแอปอาจไม่ทำงานตามที่คาดไว้ในโหมดหลายหน้าต่าง
  • [C-1-3] ต้องไม่เสนอโหมดแยกหน้าจอหรือโหมดรูปแบบอิสระหากความสูงของหน้าจอ < 440 dp และความกว้างของหน้าจอน้อยกว่า 440 dp
  • การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ 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.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
  • [C-1-3] ต้องประกาศการรองรับโปรไฟล์ที่จัดการผ่านแฟล็กฟีเจอร์ android.software.managed_users ยกเว้นในกรณีที่อุปกรณ์ได้รับการกำหนดค่าให้รายงานว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือเพื่อจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

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

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

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

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

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

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

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

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

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

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

3.11 Text-to-Speech

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

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

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

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

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

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

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

  • [C-1-1] ต้องประกาศฟีเจอร์ของแพลตฟอร์ม android.software.live_tv
  • [C-1-2] ต้องโหลดแอปพลิเคชัน TV (แอป TV) ไว้ล่วงหน้าและเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 3.12.1

3.12.1 แอป TV

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

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

แอป TV ที่จำเป็นสำหรับการใช้งานอุปกรณ์ Android ที่ประกาศ Flag ฟีเจอร์ android.software.live_tv ต้องเป็นไปตามข้อกำหนดต่อไปนี้

  • การใช้งานอุปกรณ์ควรอนุญาตให้ติดตั้งและจัดการอินพุตที่อิงตาม TIF ของบุคคลที่สาม (อินพุตของบุคคลที่สาม)
  • การใช้งานอุปกรณ์อาจมีการแยกภาพระหว่างอินพุตตาม TIF ที่ติดตั้งไว้ล่วงหน้า (อินพุตที่ติดตั้งไว้) และอินพุตของบุคคลที่สาม
  • การใช้งานอุปกรณ์ไม่ควรแสดงอินพุตของบุคคลที่สามในการไปยังส่วนต่างๆ จากแอป TV มากกว่า 1 ครั้ง (เช่น การขยายรายการอินพุตของบุคคลที่สามจากแอป TV)

โครงการโอเพนซอร์ส Android นำเสนอการใช้งานแอป TV ที่เป็นไปตามข้อกำหนดข้างต้น

3.12.1.1 คู่มือโปรแกรมอิเล็กทรอนิกส์

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

  • [C-1-1] ต้องแสดงโฆษณาซ้อนทับแบบอินเทอร์แอกทีฟที่ให้ข้อมูลและโต้ตอบได้ โดยต้องมีคู่มือโปรแกรมอิเล็กทรอนิกส์ (EPG) ที่สร้างจากค่าในช่อง TvContract.Programs
  • [C-1-2] เมื่อเปลี่ยนช่อง การใช้งานอุปกรณ์ต้องแสดงข้อมูล EPG สำหรับโปรแกรมที่เล่นอยู่ในปัจจุบัน
  • [SR] EPG ขอแนะนำอย่างยิ่งให้แสดงอินพุตที่ติดตั้งไว้และอินพุตของบุคคลที่สามโดยมีความโดดเด่นเท่ากัน EPG ไม่ควรแสดงอินพุตของบุคคลที่สามมากกว่าการไปยังส่วนต่างๆ เพียงครั้งเดียวจากอินพุตที่ติดตั้งไว้ใน EPG
  • EPG ควรแสดงข้อมูลจากอินพุตทั้งหมดที่ติดตั้งไว้และอินพุตของบุคคลที่สาม
  • EPG อาจมีการแยกภาพระหว่างอินพุตที่ติดตั้งไว้และอินพุตของบุคคลที่สาม
3.12.1.2 การนำทาง

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

  • [C-1-1] ต้องอนุญาตการนำทางสำหรับฟังก์ชันต่อไปนี้ผ่านแป้น D-pad, ย้อนกลับ และ Home ในอุปกรณ์อินพุตของอุปกรณ์ Android TV (เช่น รีโมตคอนโทรล แอปพลิเคชันรีโมตคอนโทรล หรือตัวควบคุมเกม)

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

  • ควรส่งเหตุการณ์สำคัญไปยังอินพุต HDMI ผ่าน CEC

3.12.1.3 การลิงก์แอปอินพุตทีวี

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

  • [C-1-1] การใช้งานอุปกรณ์ Android TV ต้องรองรับการลิงก์แอปอินพุตทีวี ซึ่งอนุญาตให้อินพุตทั้งหมดแสดงลิงก์กิจกรรมจากกิจกรรมปัจจุบันไปยังกิจกรรมอื่น (เช่น ลิงก์จากรายการสดไปยังเนื้อหาที่เกี่ยวข้อง)
  • [C-1-2] แอปทีวีต้องแสดงการลิงก์แอปอินพุตทีวีเมื่อมีให้
3.12.1.4 การเปลี่ยนเวลา

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

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

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

  • [SR] แนะนำอย่างยิ่งให้สนับสนุนการบันทึกรายการทีวี
  • ควรมีอินเทอร์เฟซผู้ใช้ในการเล่นรายการที่บันทึกไว้
  • หากอินพุตของทีวีรองรับการบันทึก แต่การบันทึกรายการไม่ใช่สิ่งต้องห้าม EPG อาจมอบวิธีบันทึกรายการให้

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

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

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

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

3.14 UI สื่อ

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

  • [C-1-1] ต้องแสดงไอคอน MediaItem และไอคอนการแจ้งเตือนโดยไม่เปลี่ยนแปลง
  • [C-1-2] ต้องแสดงรายการเหล่านั้นตามที่อธิบายไว้โดย MediaSession เช่น ข้อมูลเมตา ไอคอน ภาพ
  • [C-1-3] ต้องแสดงชื่อแอป
  • [C-1-4] ต้องมีลิ้นชักเพื่อแสดงลำดับชั้นของ MediaBrowser

3.15 Instant Apps

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ ซึ่งสร้างโดยเครื่องมือ “aapt” ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ
  • เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย การติดตั้งใช้งานอุปกรณ์จึงแนะนำให้ใช้การติดตั้งใช้งาน System Management SystemDevice ของการใช้งานการอ้างอิง AOSP
  • [C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ 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() หากการใช้งานอุปกรณ์ไม่ต้องการให้ผู้ใช้มีทางเลือกนี้ อย่างไรก็ตาม แม้ในกรณีดังกล่าว ควรระบุให้ผู้ใช้ทราบว่าเหตุใดจึงไม่มีตัวเลือกดังกล่าว

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

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

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

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

  • [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
  • [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
  • [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงใหม่)
  • [C-1-4] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
  • [C-1-5] FLAC
  • MP3 [C-1-6]
  • [C-1-7] MIDI
  • [C-1-8] เวอร์บี
  • [C-1-9] PCM/WAVE
  • [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

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, ไม่สามารถค้นหาได้)
โปรไฟล์ MPEG-4 HE AAC (AAC+) รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
โปรไฟล์ MPEG-4 HE AACv2
(AAC+ ที่ได้รับการปรับปรุง) 		รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC) รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
AMR-NB สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8 kHz 3GPP (.3gp)
AMR-WB 9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s แบบสุ่มตัวอย่างที่ 16 kHz
FLAC โมโน/สเตอริโอ (ไม่ใช่แบบหลายช่องทาง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz สำหรับอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากเครื่องวัดอัตราการสุ่มตัวอย่างเสียงต่ำ 48 ถึง 44.1 kHz ไม่มีตัวกรองแบบ Low Pass) แนะนำให้ใช้ 16 บิต ไม่ได้ใช้ที่ต่างกันสำหรับ 24 บิต FLAC (.flac) เท่านั้น
MP3 ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR) MP3 (.mp3)
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)
  • Matroska (.mkv, Android 4.0 ขึ้นไป)
PCM/WAVE PCM เชิงเส้น 16 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM แบบ RAW ที่ความถี่ 8000, 11025, 16000 และ 44100 Hz WAVE (.wav)
Opus มาโทรสกา (.mkv), Ogg(.ogg)

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

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

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

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

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] ดิบ

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)

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

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

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

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

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

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

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

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

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

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์ที่รองรับ/
รูปแบบคอนเทนเนอร์
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, เสียง AAC เท่านั้น, ไม่สามารถค้นหาได้, Android 3.0 ขึ้นไป)
HEVC ของ H.265 ดูรายละเอียดในส่วนที่ 5.3 MPEG-4 (.mp4)
MPEG-2 โปรไฟล์หลัก MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3
VP9 ดูรายละเอียดในส่วนที่ 5.3

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

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

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

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

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

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

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

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

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

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
  • ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (ความละเอียดสูง) ต่อไปนี้
  • ควรรองรับการเขียนไฟล์ 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 อุปกรณ์จะทำงานดังนี้

  • ควรรองรับการเขียนไฟล์ Matroska WebM

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

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

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

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

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

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

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

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

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

5.4.1 การบันทึกเสียงแบบ RAW

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

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

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100 Hz
    • ช่องสัญญาณ: โมโน

  • [C-1-2] ต้องจับอัตราการสุ่มตัวอย่างสูงกว่าโดยไม่มีการสุ่มตัวอย่าง

  • [C-1-3] ต้องระบุตัวกรองการลดรอยหยักที่เหมาะสมเมื่ออัตราการสุ่มตัวอย่างที่ระบุข้างต้นได้รับการบันทึกในการสุ่มตัวอย่าง

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

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
    • ช่องสัญญาณ: สเตอริโอ

หากการติดตั้งอุปกรณ์อนุญาตให้บันทึกคุณภาพวิทยุและดีวีดี 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.5 การเล่นเสียง

Android มีการสนับสนุนเพื่ออนุญาตให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงตามที่ระบุไว้ในส่วนที่ 7.8.2

5.5.1 การเล่นเสียงดิบ

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

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

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 32000, 44100
    • ช่องสัญญาณ: โมโน สเตอริโอ

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

    • อัตราการสุ่มตัวอย่าง: 24,000, 48,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
  • ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer

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

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

  • [SR] เวลาในการตอบสนองเอาต์พุตแบบ Cold 100 มิลลิวินาทีหรือน้อยกว่า
  • [SR] เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
  • [SR] ลด Jitter เอาต์พุต Cold

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

  • [SR] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์ android.hardware.audio.low_latency
  • [SR] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API ด้วย

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

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

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

  • [SR] เวลาในการตอบสนองการป้อนข้อมูลแบบ Cold 100 มิลลิวินาทีหรือน้อยกว่า
  • [SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
  • [SR] ลดเสียงรบกวนของอินพุต Cold

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

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

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

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

  • [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบสื่อประเภท Segmant ด้านล่างผ่านโปรโตคอลฉบับร่างของ 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
และ MPEG-2 ในหัวข้อ 5.1.3

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

  • 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-ทั่วไป 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)

หากการใช้งานอุปกรณ์รองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน) และรองรับ MIDI มากกว่าการส่งฮาร์ดแวร์ที่ใช้ MIDI ทั้งหมดต่อไปนี้ได้ ซึ่งให้บริการการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป จะเป็น

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

การรับส่งข้อมูลฮาร์ดแวร์ที่ใช้ MIDI ได้มีดังนี้

  • โหมดโฮสต์ USB (ส่วนที่ 7.7 USB)
  • โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7 USB)
  • MIDI ผ่าน Bluetooth LE ดำเนินการในบทบาทหลัก (ส่วนที่ 7.4.3 บลูทูธ)

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

  • [C-1-1] ต้องไม่รายงานการรองรับฟีเจอร์ android.software.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
  • ควรทำให้ประสิทธิภาพของ CPU ในระดับที่ยั่งยืนขณะใช้งานเสียง
  • ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
  • ควรลดการลอยของนาฬิกาเสียงที่สัมพันธ์กับ 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)

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

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

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดผ่าน API คิวบัฟเฟอร์ OpenSL ES PCM จะดำเนินการดังต่อไปนี้

  • [SR] แนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเดียวกันผ่าน AAudio API ด้วย

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

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

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

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

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

หากการใช้งานอุปกรณ์มีพอร์ต HDMI การใช้งานจะดังนี้

  • [C-5-1] ต้องรองรับเอาต์พุตแบบสเตอริโอและแชนเนล 8 ช่องที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มเนื้อหาซ้ำ

5.11 จับภาพสำหรับที่ไม่ได้ประมวลผล

Android รองรับการบันทึกเสียงที่ไม่ได้ประมวลผลผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES จะสามารถเข้าถึงได้ด้วยค่าระเบียนที่กำหนดล่วงหน้า SL_ANDROID_RECORDING_PRESET_UNPROCESSED

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

  • [C-1-1] ต้องรายงานการสนับสนุนผ่านพร็อพเพอร์ตี้ android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

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

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

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

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

  • [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 ทั้งหมดตามที่ระบุไว้ใน SDK ของ Android ซึ่งรวมถึง dumpsys
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ระบบอุปกรณ์ (batterystats , Dataprocs, Fingerprint, graphicstats, netstats, notifications, procstats) ที่บันทึกผ่าน dumpsys
    • [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

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

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

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

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

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

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

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

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

  • [C-0-2] ยังคงต้องนำเสนอคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK บันทึกไว้) สำหรับ API ของคอมโพเนนต์
  • [C-0-3] ต้องมีการนำลักษณะการทำงานของ API มาใช้เป็น "ไม่ดำเนินการ" ด้วยวิธีการที่สมเหตุสมผล
  • [C-0-4] เมธอด API ต้องแสดงค่า Null ตามที่ได้รับอนุญาตโดยเอกสาร SDK
  • [C-0-5] เมธอด API ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่เอกสาร SDK ไม่อนุญาตค่า Null
  • [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
  • [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

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

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

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

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

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

  • [C-0-1] การใช้งานอุปกรณ์โดยตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพระหว่าง 1.3333 (4:3) ถึง 1.86 (ประมาณ 16:9) เว้นแต่แอปจะถือว่าพร้อมยืดขยายนานขึ้นเมื่อเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

    • แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา android.max_aspect
    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปกําหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ android:MaxAspectRatio ที่จะจํากัดสัดส่วนภาพที่อนุญาต

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

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

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

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

    • 120 dpi (ldpi)
    • 160 dpi (mdpi)
    • 213 dpi (tvdpi)
    • 240 dpi (hdpi)
    • 260 dpi (260dpi)
    • 280 dpi (280dpi)
    • 300 dpi (300dpi)
    • 320 dpi (Xhdpi)
    • 340 dpi (340dpi)
    • 360 dpi (360dpi)
    • 400 dpi (400dpi)
    • 420 dpi (420dpi)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

  • การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก 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 แสดงเมตริก

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

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่กำหนดไว้ใน android.util.DisplayMetrics API

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

  • [C-2-1] ต้องรายงานค่าที่สมเหตุสมผลสำหรับเมตริกการแสดงผลทั้งหมดที่กำหนดไว้ใน 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.0 และ 2.0 ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.0
  • ควรรองรับ OpenGL ES 3.1 หรือ 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
  • [SR] แนะนำอย่างยิ่งให้สนับสนุน EGL_KHR_partial_update
  • ควรรายงานอย่างถูกต้องผ่านเมธอด getString() ซึ่งเป็นรูปแบบการบีบอัดพื้นผิวที่ระบบรองรับ ซึ่งโดยทั่วไปจะเป็นเฉพาะผู้ให้บริการ

หากการใช้งานอุปกรณ์ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 ก็จะมีผลดังนี้

  • [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้ นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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.0 หรือ 3.1 อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

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

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

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

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

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

  • [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan ใดๆ (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
  • [C-2-2] ต้องไม่แจกแจง VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()
7.1.4.3 RenderScript
  • [C-0-1] การใช้งานอุปกรณ์ต้องรองรับ Android RenderScript โปรดดูรายละเอียดในเอกสารประกอบเกี่ยวกับ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือดูผ่านการใช้แท็กไฟล์ Manifest android: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% ของ NTSC 1953 ในพื้นที่ CIE 1931 xyY
  • [C-1-4] ต้องรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
  • [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย EGL_KHR_no_config_context, EGL_EXT_pixel_format_float,EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear และ EGL_GL_colorspace_display_p3
  • [SR] แนะนำอย่างยิ่งให้สนับสนุน GL_EXT_sRGB

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

  • [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่ CIE 1931 xyY แม้ว่าไม่ได้ระบุขอบเขตสีของหน้าจอก็ตาม

7.1.5 โหมดความเข้ากันได้กับแอปพลิเคชันเดิม

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

7.1.6 เทคโนโลยีหน้าจอ

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

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

  • [C-0-1] ต้องรองรับจอแสดงผลที่สามารถแสดงผลกราฟิกสี 16 บิต
  • ควรสนับสนุนจอแสดงผลที่รองรับกราฟิกสี 24 บิต
  • [C-0-2] ต้องรองรับการแสดงผลที่สามารถแสดงผลภาพเคลื่อนไหว
  • [C-0-3] ต้องใช้เทคโนโลยีการแสดงผลที่มีอัตราส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความอดทน 10 ~ 15%

7.1.7 จอแสดงผลสำรอง

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] ต้องระบุฟังก์ชัน Home
  • ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"

หากมีฟังก์ชัน "หน้าแรก" "ล่าสุด" หรือ "ย้อนกลับ" อยู่ ฟังก์ชันดังกล่าวจะส่งผลดังนี้

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

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

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

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

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

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

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

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

  • [C-5-1] แป้นนำทางต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมใช้งานกับแอปพลิเคชันต่างๆ และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่ใช้งานได้ของแอปพลิเคชัน
  • [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในหัวข้อ 7.1.1
  • [C-5-3] ต้องยึดตามแฟล็กที่แอปตั้งค่าผ่านเมธอด View.setSystemUiVisibility() API เพื่อให้ส่วนเฉพาะของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ถูกซ่อนอย่างเหมาะสมตามที่ระบุไว้ใน SDK

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 รวมถึงการใช้งานสำหรับตัวควบคุมเกมที่เป็นไปตามข้อกำหนดนี้

Button การใช้งาน HID2 ปุ่ม Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
ข1 0x09 0x0002 KEYCODE_BUTTON_B (97)
x1 0x09 0x0004 KEYCODE_BUTTON_X (99)
ปี1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad ขึ้น1
D-pad ลง1 		0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ขวา1 		0x01 0x00393 AXIS_HAT_X4
ปุ่มไหล่ซ้าย1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่มไหล่ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกสติ๊กซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกสติ๊กขวา1 0x09 0x000f KEYCODE_BUTTON_THUMBR (107)
หน้าแรก1 0x0c 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 สำหรับเคสของเซ็นเซอร์ที่สตรีมโดยมีเวลาในการตอบสนองขั้นต่ำที่ต้องการคือ 5 ms + 2 * sample_time เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
  • [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 ตัวตรวจวัดความเร่ง

  • การใช้งานอุปกรณ์ควรมีตัวตรวจวัดความเร่งแบบ 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 หากมีการปรับเทียบตัวตรวจวัดความเร่งออนไลน์
  • ควรใช้เซ็นเซอร์ผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK
  • ควรรายงานเหตุการณ์สูงสุด 200 Hz
  • ควรมีความละเอียดอย่างน้อย 16 บิต
  • ควรมีการปรับเทียบขณะใช้งานหากลักษณะมีการเปลี่ยนแปลงตลอดวงจรและการชดเชย รวมถึงคงพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
  • ควรมีการชดเชยอุณหภูมิ
  • ควรใช้เซ็นเซอร์ TYPE_ACCELEROMETER_UNCALIBRATED ด้วย

หากใช้อุปกรณ์รวมถึงตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER จะมีการใช้งานดังนี้

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

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

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

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

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

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

  • การใช้งานอุปกรณ์ควรมีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 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 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์วัดการหมุน สิ่งที่จะเกิดขึ้นมีดังนี้

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

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

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

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

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

หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps และรายงาน LocationManager.getGnssYearOfHardware() Test API ในปี "2016" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้

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

หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps และรายงาน LocationManager.getGnssYearOfHardware() Test API ในปี "2017" ขึ้นไป การดำเนินการดังกล่าวจะส่งผลดังนี้

  • [C-3-1] ต้องให้เอาต์พุตตำแหน่ง GPS/GNSS ตามปกติต่อไปในระหว่างการโทรออกฉุกเฉิน
  • [C-3-2] ต้องรายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ตามรายงานในข้อความ GnssStatus) ยกเว้น SBAS
  • [C-3-3] ต้องรายงาน AGC และความถี่ของการวัด GNSS
  • [C-3-4] ต้องรายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS แต่ละตำแหน่ง

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

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

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

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

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

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

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

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

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

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

  • การใช้งานอุปกรณ์ควรมีบารอมิเตอร์ (เซ็นเซอร์ความกดอากาศแวดล้อม)

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

  • [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 ก. เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 1024 LSB/G
    • ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่การวัดสูงสุด 400 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงกว่า 400 uG/Cellular คนอื่นๆ
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
    • ควรมีความเสถียรของเบี่ยงเบนสัญญาณรบกวนแบบอยู่กับที่ที่ \<15 μg เครื่องหมาย การแปลแบบอินเทอร์แอ็กทีฟจากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก. / °C
    • ควรมีระดับความไม่เป็นเชิงเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิสูงสุด ≤ 0.03%/C°
    • ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ

  • [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 หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
    • ควรมีความเสถียรของเบี่ยงเบนแบบอยู่กับที่ที่ < 0.0002 °/s {/9}Hz จากชุดข้อมูลแบบคงที่ตลอด 24 ชั่วโมง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
    • ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
    • ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
    • ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
    • ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ
    • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่

  • [C-2-4] ต้องมี TYPE_GYROSCOPE_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_GYROSCOPE

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่งมีคุณสมบัติดังนี้
    • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 uT เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
    • ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
  • [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกําหนดด้านคุณภาพเดียวกันกับ TYPE_GEOMAGNETIC_FIELD และมีคุณสมบัติต่อไปนี้
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
    • ควรมีสเปกตรัมของสัญญาณไวท์นอยส์เพื่อให้มีความสมบูรณ์ของสัญญาณรบกวนในเซ็นเซอร์ที่เพียงพอ
  • [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 ซึ่งมีคุณสมบัติดังนี้
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
  • [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 มิลลิวินาที
  • [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_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุกระบบ) ในประเภทต่อไปนี้
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10 เซ็นเซอร์ลายนิ้วมือ

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

  • ควรมีเซ็นเซอร์ลายนิ้วมือ

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

  • [C-1-1] ต้องประกาศการรองรับฟีเจอร์ android.hardware.fingerprint
  • [C-1-2] ต้องใช้ corresponding API อย่างสมบูรณ์ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
  • [C-1-3] ต้องมีอัตราการยอมรับที่เป็นเท็จไม่เกิน 0.002%
  • [C-1-4] ต้องพยายามจำกัดจำนวนอัตราอย่างน้อย 30 วินาทีหลังจากการทดลองตรวจสอบลายนิ้วมือที่ไม่ถูกต้อง 5 ครั้ง
  • [C-1-5] ต้องมีการใช้งานคีย์สโตร์ที่ใช้ฮาร์ดแวร์ และดำเนินการจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
  • [C-1-6] ต้องมีข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับ เพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอกระบบ Trusted Execution Environment (TEE) ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานบนเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
  • [C-1-7] ต้องป้องกันไม่ให้มีการเพิ่มลายนิ้วมือโดยไม่สร้างเครือข่ายความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันว่ามีหรือเพิ่มข้อมูลรับรองอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัย การใช้งานโปรเจ็กต์โอเพนซอร์สของ Android จะเป็นกลไกในเฟรมเวิร์ก
  • [C-1-8] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างลายนิ้วมือแต่ละรายการ
  • [C-1-9] ต้องทำตามแฟล็ก DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
  • [C-1-10] ต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้นเมื่ออัปเกรดจากเวอร์ชันที่เก่ากว่า Android 6.0 หรือนำข้อมูลลายนิ้วมือออกอย่างปลอดภัย
  • [SR] แนะนําอย่างยิ่งให้มีอัตราการปฏิเสธเท็จน้อยกว่า 10% ตามที่วัดในอุปกรณ์
  • [SR] แนะนำอย่างยิ่งให้เวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเมื่อเซ็นเซอร์ลายนิ้วมือถูกแตะจนกระทั่งหน้าจอปลดล็อกสำหรับนิ้วเดียวที่ลงทะเบียน
  • ควรใช้ไอคอนลายนิ้วมือของ Android ที่ให้ไว้ในโครงการโอเพนซอร์สของ Android

7.3.11 เซ็นเซอร์สำหรับ Android Automotive เท่านั้น

เซ็นเซอร์สําหรับยานยนต์ได้รับการกำหนดไว้ในandroid.car.CarSensorManager API

7.3.11.1 เฟืองปัจจุบัน

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

7.3.11.2 โหมดกลางวัน/กลางคืน

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

7.3.11.3 สถานะการขับรถ

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

7.3.11.4 ความเร็วของล้อ

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

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 เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ
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.2 IEEE 802.11 (Wi-Fi)

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

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

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

  • [C-1-1] ต้องใช้ Andr:oid 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 แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย
  • ควรสุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอการตรวจสอบ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้ง ขณะที่ STA ไม่ได้เชื่อมต่ออยู่
    • เฟรมคำขอการตรวจสอบแต่ละกลุ่มที่ประกอบด้วยการสแกน 1 รายการควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งทางของการสแกน)
    • หมายเลขลำดับคำขอตรวจสอบควรทำซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
    • หมายเลขลำดับคำขอการตรวจสอบควรสุ่มอยู่ระหว่างคำขอการตรวจสอบสุดท้ายของการสแกนและคำขอการตรวจสอบแรกของการสแกนครั้งถัดไป
  • ควรอนุญาตเฉพาะองค์ประกอบข้อมูลต่อไปนี้ในเฟรมคำขอการตรวจสอบ ส่วน STA ไม่ได้เชื่อมต่อ
    • ชุดพารามิเตอร์ SSID (0)
    • ชุดพารามิเตอร์ DS (3)
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 ปกติ
  • ควรรองรับการทำงาน Wi-Fi และ Wi-Fi Direct ควบคู่กัน

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

หากการใช้งานอุปกรณ์รวมถึงการรองรับ 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 อยู่
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.3 บลูทูธ

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ 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, AVCP, OBEX ฯลฯ ตามความเหมาะสมกับอุปกรณ์

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

  • [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 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้

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-3] ต้องมีความสามารถในการส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลระหว่างเครื่องต่อไปนี้

  • [C-1-4] ต้องมีการสนับสนุนสำหรับ Androidบีม และควรเปิดใช้ Androidบีมโดยค่าเริ่มต้น
  • [C-1-5] ต้องรับและส่งโดยใช้ Androidบีมได้ เมื่อเปิดใช้ Androidบีม หรือเปิดโหมด NFC P2p ที่เป็นกรรมสิทธิ์อื่นๆ
  • [C-1-6] ต้องใช้เซิร์ฟเวอร์เริ่มต้นของ SNEP ข้อความ NDEF ที่ถูกต้องซึ่งได้รับจากเซิร์ฟเวอร์ SNEP เริ่มต้นจะต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้ Androidบีมในการตั้งค่าต้องไม่ปิดใช้การส่งข้อความ NDEF ที่เข้ามาใหม่
  • [C-1-7] ต้องปฏิบัติตาม Intent ของ android.settings.NFCSHARING_SETTINGS จึงจะแสดงการตั้งค่าการแชร์ NFC ได้
  • [C-1-8] ต้องใช้เซิร์ฟเวอร์ NPP ข้อความที่เซิร์ฟเวอร์ NPP ได้รับจะต้องประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้นของ SNEP
  • [C-1-9] ต้องใช้ไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Androidบีม หากไม่พบเซิร์ฟเวอร์ SNEP ที่เป็นค่าเริ่มต้น ไคลเอ็นต์ต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
  • [C-1-10] ต้องอนุญาตให้กิจกรรมที่ทำงานอยู่เบื้องหน้าตั้งค่าข้อความ NDEF แบบ P2P ขาออกโดยใช้ android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback และ android.nfc.NfcAdapter.enableForegroundNdefPush
  • ควรใช้ท่าทางสัมผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อบีม" ก่อนส่งข้อความ NDEF แบบ P2P ขาออก
  • [C-1-11] ต้องรองรับการส่งมอบการเชื่อมต่อ NFC ไปยังบลูทูธเมื่ออุปกรณ์รองรับ Bluetooth Object Push Profile
  • [C-1-12] ต้องรองรับการส่งมอบการเชื่อมต่อไปยังบลูทูธเมื่อใช้ android.nfc.NfcAdapter.setBeamPushUris โดยใช้ข้อกำหนดของ "การแฮนด์โอเวอร์การเชื่อมต่อเวอร์ชัน 1.2" และ "การจับคู่อย่างง่ายที่ปลอดภัยบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" จากฟอรัม NFC การติดตั้งใช้งานดังกล่าวต้องใช้บริการ Handover LLCP ที่มีชื่อว่าบริการชื่อ "urn:nfc:sn:handover" สำหรับการแลกเปลี่ยนคำขอโอน/เลือกบันทึกผ่าน NFC และต้องใช้โปรไฟล์พุชของ Bluetooth Object Push สำหรับการโอนข้อมูลบลูทูธจริง ด้วยเหตุผลเดิม (เพื่อให้ยังคงสามารถทำงานร่วมกับอุปกรณ์ Android 4.1 ได้) การใช้งานควรจะยอมรับคำขอ SNEP GET สำหรับการแลกเปลี่ยนคำขอส่ง/บันทึกที่เลือกผ่าน NFC อย่างไรก็ตาม การนำไปใช้ไม่ควรส่งคำขอ SNEP GET เพื่อทำการส่งมอบการเชื่อมต่อ
  • [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 บลูทูธ ฯลฯ
  • [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 วินาที
  • ควรรวมการสนับสนุนมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
  • อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ

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

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

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

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

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

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

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

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.5 กล้อง

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

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

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

การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ 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
  • [C-0-5] ต้องใช้ กล้องถ่ายรูป API แบบเต็มซึ่งรวมอยู่ในเอกสารประกอบของ Android SDK โดยไม่คำนึงว่าอุปกรณ์ดังกล่าวจะมีระบบโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือความสามารถอื่นๆ หรือไม่ ตัวอย่างเช่น กล้องที่ไม่มีการโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback ที่ลงทะเบียนไว้ (แม้ว่าจะไม่เกี่ยวข้องกับกล้องที่ไม่โฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการทำงานนี้มีผลกับกล้องหน้าด้วย เช่น แม้ว่ากล้องหน้าส่วนใหญ่ไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับของ API ยังคงต้อง "ไม่อัปเดต" ตามที่อธิบายไว้
  • [C-0-6] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละรายการที่กำหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยึดตามหรือรับรู้ค่าคงที่สตริงที่ส่งไปยังเมธอด 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 ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของรูปภาพไปยังร้านค้าสื่อแล้ว

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยแอปพลิเคชัน หรือมักเรียกว่า "ที่จัดเก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน" หรือตามเส้นทาง "/sdcard" ของ Linux ที่ต่อเชื่อมอยู่
  • [C-0-2] ต้องกำหนดค่าเป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งต่อเชื่อมโดยค่าเริ่มต้น หรือที่เรียกว่า "พร้อมใช้งานทันที" ไม่ว่าจะใช้งานพื้นที่เก็บข้อมูลกับคอมโพเนนต์ที่จัดเก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ดดิจิทัลที่ปลอดภัย)
  • [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันบนเส้นทาง Linux sdcard โดยตรง หรือรวมลิงก์สัญลักษณ์ของ Linux จาก sdcard ไปยังจุดต่อเชื่อมจริง
  • [C-0-4] ต้องบังคับใช้สิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนี้ตามที่ระบุไว้ใน SDK พื้นที่เก็บข้อมูลที่ใช้ร่วมกันต้องเขียนได้โดยแอปพลิเคชันใดๆ ที่มีสิทธิ์ดังกล่าว

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

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

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

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

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

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

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

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

หากอุปกรณ์มีพอร์ต 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 (เต้ารับ)
  • [SR] แนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสาร Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะที่อยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของการแก้ไขข้อมูลจำเพาะของสาย USB Type-C 1.2 สำหรับขั้วต่อ USB Type-C หรือการใช้เอาต์พุตพอร์ตดาวน์สตรีม(CDP) สำหรับการชาร์จช่วงปัจจุบันตามที่ระบุไว้ในข้อมูลจำเพาะของการชาร์จสาย USB Type-C สำหรับหัวชาร์จ USB Type-C การแก้ไขที่ 1.2
  • ควรใช้และสนับสนุนมาตรฐาน 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 พอร์ต พอร์ตเสียงอย่างน้อย 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 โวลต์
  • [SR] แนะนำอย่างเข้มงวดให้ตรวจหาและแมปกับคีย์โค้ดสำหรับช่วงค่าอิมพีแดนซ์ที่เท่ากันต่อไปนี้ระหว่างไมโครโฟนและตัวนำกราวด์ของปลั๊กเสียง
    • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
  • ควรรองรับปลั๊กเสียงที่มีลำดับการปักหมุด OMTP
  • ควรรองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอพร้อมไมโครโฟน

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

  • [C-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.9 Virtual Reality

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

7.9.1 โหมด Virtual Reality

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

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

หากการใช้งานอุปกรณ์ระบุถึงการรองรับ VR ประสิทธิภาพสูงในช่วงเวลาของผู้ใช้ที่ยาวนานขึ้นผ่านแฟล็กฟีเจอร์ android.hardware.vr.high_performance ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องมี 2 Physical Core เป็นอย่างน้อย
  • [C-1-2] ต้องประกาศ android.software.vr.mode feature
  • [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
  • [C-1-4] ต้องรองรับ OpenGL ES 3.2
  • [C-1-5] ต้องรองรับ Vulkan ฮาร์ดแวร์ระดับ 0 และควรรองรับ Vulkan ฮาร์ดแวร์ระดับ 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 ที่มีให้บริการ
  • [C-1-7] GPU และจอแสดงผลต้องสามารถซิงค์ข้อมูลการเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ ซึ่งจะทำให้การแสดงผลแบบสลับตาของเนื้อหา VR ที่ 60 FPS พร้อมบริบทในการแสดงภาพ 2 รายการจะแสดงโดยไม่มีอาร์ติแฟกต์ที่ฉีกขาดซึ่งมองเห็นได้
  • [C-1-8] ต้องใช้ GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-1-9] ต้องใช้การรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER และ AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องใช้การสนับสนุนสำหรับ AHardwareBuffers ที่มีมากกว่า 1 เลเยอร์
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840x2160@30fps-40Mbps (เทียบเท่ากับ 1920x1080@30fps-10Mbps 4 อินสแตนซ์ หรือ 1920x1080@60fps-20Mbps 2 อินสแตนซ์)
  • [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920x1080@30fps-10Mbps และควรถอดรหัส 3840x2160@30fps-20Mbps ได้ (เทียบเท่ากับ 1920x1920x1 อินสแตนซ์ 4 fps)
  • [C-1-13] ต้องรองรับ API ของ HardwarePropertiesManager.getDeviceTemperatures และแสดงผลค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
  • [C-1-14] ต้องมีหน้าจอแบบฝัง และความละเอียดอย่างน้อยต้องเป็น FullHD(1080p) และแนะนำให้ใช้เป็น QuadHD (1440p) ขึ้นไป
  • [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
  • [C-1-16] เวลาในการเปลี่ยนการแสดงผลระหว่างสีเทาเป็นสีเทา ขาวเป็นดำ และดำเป็นขาวต้องอยู่ที่ ≤ 3 มิลลิวินาที
  • [C-1-17] จอแสดงผลต้องรองรับโหมดความต่อเนื่องต่ำที่มีความต่อเนื่อง ≤5 มิลลิวินาที ความต่อเนื่องหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
  • [C-1-18] ต้องรองรับบลูทูธ 4.2 และการขยายความยาวของข้อมูลบลูทูธ LE หัวข้อ 7.4.3
  • [SR] แนะนําอย่างยิ่งให้รองรับฟีเจอร์ android.hardware.sensor.hifi_sensors และต้องมีคุณสมบัติตรงตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors
  • อาจให้แกนเอกสิทธิ์เฉพาะสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า และอาจรองรับ 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 โหมดประหยัดพลังงาน

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

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การนำอุปกรณ์ Android ไปใช้อาจจะใช้สถานะกำลังนอนหลับใดๆ หรือทั้งหมด 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)

หากการติดตั้งใช้งานอุปกรณ์ใช้สถานะกำลัง S3 และ S4 ตามที่กำหนดโดย ACPI สิ่งต่อไปนี้

  • [C-1-1] ต้องป้อนสถานะเหล่านี้เฉพาะเมื่อปิดฝาอุปกรณ์

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 ที่มีการตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น

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

  • [SR] ขอแนะนำเป็นอย่างยิ่งให้กลไกที่ผู้ใช้เข้าถึงได้เพื่อให้หรือเพิกถอนการเข้าถึงสถิติการใช้งานตาม Intent ของ 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>

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

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

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

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

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

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)
  • [SR] แนะนำอย่างเข้มงวดให้เก็บข้อมูลเคอร์เนลที่จะเขียนเฉพาะในช่วงเริ่มต้นที่มีการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น __ro_after_init)
  • [SR} แนะนำอย่างยิ่งให้ใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่าง User-space และ Kernel-space (เช่น CONFIG_HARDENED_USERCOPY)
  • [SR] แนะนำอย่างยิ่งไม่ให้เรียกใช้หน่วยความจำพื้นที่ผู้ใช้เมื่อทำงานในเคอร์เนล (เช่น PXN ของฮาร์ดแวร์หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN)
  • [SR] แนะนำอย่างยิ่งว่าอย่าอ่านหรือเขียนหน่วยความจำของพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึงผู้ใช้สำเนาปกติ (เช่น PAN ของฮาร์ดแวร์หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN)
  • [SR] แนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และเพื่อหลีกเลี่ยงการเปิดเผยที่อาจเป็นอันตรายต่อการสุ่ม (เช่น CONFIG_RANDOMIZE_BASE ด้วยเอนโทรปี Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

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

  • [C-1-1] ต้องใช้ SELinux
  • [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
  • [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดที่อนุญาต ซึ่งรวมถึงโดเมนเฉพาะสำหรับอุปกรณ์/ผู้ให้บริการรายใดรายหนึ่ง
  • [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎNeverallow ที่อยู่ในโฟลเดอร์ระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ ไม่อนุญาตทั้งหมดที่มีอยู่ สำหรับโดเมน AOSP SELinux และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
  • ควรเก็บนโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ระบบ/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง และเพิ่มในนโยบายนี้เพิ่มเติมเฉพาะสำหรับการกำหนดค่าเฉพาะอุปกรณ์เท่านั้น

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

  • [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็นซึ่งเทียบเท่ากับ SELinux

9.8 ความเป็นส่วนตัว

9.8.1 ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

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

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

9.8.2 กำลังบันทึกเสียง

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

  • [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() ซึ่งในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับแจ้งเท่านั้น

9.9 การเข้ารหัสพื้นที่เก็บข้อมูล

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

  • [C-1-1] ต้องรองรับการเข้ารหัสพื้นที่เก็บข้อมูลของข้อมูลส่วนตัวของแอปพลิเคชัน (/data partition) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (/sdcard partition) ถ้าเป็นส่วนแบบถาวรและไม่สามารถนำออกได้ของอุปกรณ์

หากการใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9.11.1 และรองรับการเข้ารหัสพื้นที่เก็บข้อมูลด้วยประสิทธิภาพคริปโตมาตรฐานการเข้ารหัสขั้นสูง (AES) ที่สูงกว่า 50 MiB/วินาที การดำเนินการดังกล่าวจะส่งผลดังนี้

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

  • ควรปฏิบัติตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นผ่านการใช้การเข้ารหัสตามไฟล์ (FBE)

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 การเข้ารหัสตามไฟล์

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

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

  • [C-1-6] ต้องรองรับชื่อไฟล์การเข้ารหัสโดยใช้ AES ที่มีความยาวคีย์ 256 บิตในโหมด CBC-CTS

  • คีย์ที่ช่วยปกป้องพื้นที่เก็บข้อมูล CE และ DE มีดังนี้

  • [C-1-7] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์

  • [C-1-8] คีย์ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้
  • [C-1-9] คีย์ CE ต้องผูกกับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบในหน้าจอล็อก

  • [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ ไม่มีคีย์ CE หรือ DE ของผู้ใช้ที่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น

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

  • ควรทำให้แอปสำคัญที่โหลดไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเซนเจอร์) Direct Boot

  • อาจรองรับการเข้ารหัสอื่นๆ ความยาวคีย์ และโหมดสำหรับเนื้อหาไฟล์และการเข้ารหัสชื่อไฟล์

โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำโดยอิงตามฟีเจอร์การเข้ารหัส Kernel ext4 ของ Linux

9.9.3 การเข้ารหัสดิสก์เต็มรูปแบบ

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

  • [C-1-1] ต้องใช้ AES กับคีย์ขนาด 128 บิต (หรือสูงกว่า) และโหมดที่ออกแบบมาสำหรับพื้นที่เก็บข้อมูล (เช่น AES-XTS, AES-CBC-ESSIV)
  • [C-1-2] ต้องใช้รหัสผ่านเริ่มต้นเพื่อรวมคีย์การเข้ารหัสและต้องไม่เขียนคีย์การเข้ารหัสไปยังพื้นที่เก็บข้อมูลได้ทุกเมื่อโดยไม่มีการเข้ารหัส
  • [C-1-3] ต้องให้ความเป็นไปได้แก่ผู้ใช้ AES จะเข้ารหัสคีย์การเข้ารหัส ยกเว้นกรณีที่ใช้งานอยู่ ซึ่งมีการยืดข้อมูลเข้าสู่ระบบหน้าจอล็อกโดยใช้อัลกอริทึมการขยายช้า (เช่น PBKDF2 หรือ scrypt)
  • [C-1-4] อัลกอริทึมการขยายรหัสผ่านที่เป็นค่าเริ่มต้นข้างต้นจะต้องผูกกับแหล่งเก็บคีย์นั้นแบบเข้ารหัสในกรณีที่ผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกหรือได้ปิดใช้รหัสผ่านสำหรับการเข้ารหัสและอุปกรณ์มีคีย์สโตร์แบบฮาร์ดแวร์
  • [C-1-5] ต้องไม่ส่งคีย์การเข้ารหัสออกไปนอกอุปกรณ์ (แม้ว่าจะพันด้วยรหัสผ่านของผู้ใช้และ/หรือคีย์ที่ผูกกับฮาร์ดแวร์ก็ตาม)

โปรเจ็กต์โอเพนซอร์ส Android ติดตั้งใช้งานฟีเจอร์นี้ที่ต้องการ โดยอิงตาม dm-crypt ของฟีเจอร์เคอร์เนลของ Linux

9.10 ความสมบูรณ์ของอุปกรณ์

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

  • [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะ Bootloader อนุญาตให้มีการกะพริบอิมเมจของระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ระบบใหม่นี้

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

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

โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำในที่เก็บ external/avb/ ซึ่งสามารถผสานรวมเข้ากับ Boot Loader ที่ใช้สำหรับการโหลด Android

การใช้งานอุปกรณ์กับประสิทธิภาพคริปโตมาตรฐานการเข้ารหัสขั้นสูง (AES) ที่สูงกว่า 50 MiB/วินาที

  • [C-2-1] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

หากมีการเปิดตัวอุปกรณ์โดยไม่รองรับการเปิดเครื่องที่ได้รับการยืนยันใน 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 ซึ่งต้องใช้คีย์สโตร์แบบใช้ฮาร์ดแวร์

9.11.1 หน้าจอล็อกที่ปลอดภัย

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

  • [C-1-1] ต้องระบุผู้ใช้ในการตั้งค่าและอินเทอร์เฟซผู้ใช้แบบหน้าจอล็อกในกรณีที่ระบบเลื่อนการล็อกหน้าจออัตโนมัติ หรือเอเจนต์ความน่าเชื่อถือสามารถปลดล็อกหน้าจอได้ AOSP เป็นไปตามข้อกำหนดโดยแสดงข้อความอธิบายสำหรับเมนู "การตั้งค่าล็อกอัตโนมัติ" และ "การตั้งค่าปุ่มเปิด/ปิดล็อกการตั้งค่าทันที" และไอคอนแยกได้บนหน้าจอล็อก
  • [C-1-2] ต้องเคารพและติดตั้งใช้งาน API ของเอเจนต์ความน่าเชื่อถือทั้งหมดในคลาส DevicePolicyManager เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
  • [C-1-3] ต้องไม่ใช้ฟังก์ชัน TrustAgentService.addEscrowToken() โดยสมบูรณ์ในอุปกรณ์ที่ใช้เป็นอุปกรณ์หลักส่วนตัว (เช่น อุปกรณ์พกพา) แต่อาจใช้ฟังก์ชันอย่างเต็มรูปแบบในการติดตั้งใช้งานอุปกรณ์ที่โดยปกติใช้ร่วมกัน
  • [C-1-4] ต้องเข้ารหัสโทเค็นที่เพิ่มโดย TrustAgentService.addEscrowToken() ก่อนจัดเก็บไว้ในอุปกรณ์
  • [C-1-5] ต้องไม่เก็บคีย์การเข้ารหัสไว้ในอุปกรณ์
  • [C-1-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นคนกลางเพื่อถอดรหัสพื้นที่เก็บข้อมูล

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

  • [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] ต้องปิดใช้เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_SOMETHING

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

  • [C-4-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและตรงตามข้อกำหนดจึงจะถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
  • [C-4-2] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเฉพาะเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-4-3] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลัก (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น

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

  • [C-5-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักวิธีใดวิธีหนึ่ง ซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตามข้อกำหนดจึงจะถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
  • [C-5-2] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเฉพาะเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์คีย์การ์ดโดยเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)
  • [C-5-3] ต้องมีอัตราการยอมรับที่เป็นเท็จซึ่งเท่ากับหรือดีกว่าที่กำหนดไว้สำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10 หรือ "ต้องปิดใช้" และอนุญาตให้การตรวจสอบสิทธิ์หลักปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพของรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ซึ่งมีคุณภาพคงที่มากกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK เท่านั้น
  • [C-5-4] ผู้ใช้ต้องได้รับแจ้งสำหรับการตรวจสอบสิทธิ์หลัก (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น

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

9.12 การลบข้อมูล

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

  • [C-0-1] ต้องระบุกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลที่ผู้ใช้สร้างขึ้นทั้งหมด ซึ่งก็คือข้อมูลทั้งหมดยกเว้นข้อมูลต่อไปนี้
    • อิมเมจระบบ
    • ไฟล์ระบบปฏิบัติการใดๆ ก็ตามที่ต้องใช้ในอิมเมจระบบ
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่เป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอปตัวควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลักเรียกใช้ API ของ DevicePolicyManager.wipeData()
  • อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น

9.13 โหมดปลอดภัยเปิดเครื่อง

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

การใช้งานอุปกรณ์มีดังนี้

  • [SR] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง

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

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

  • [C-1-2] ต้องให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้

  • ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยจากเมนูเปิดเครื่องโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเปิดเครื่องปกติ

9.14 การแยกระบบยานพาหนะ

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายรถยนต์ เช่น CAN Bus

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

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

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

10.1 ชุดเครื่องมือทดสอบความเข้ากันได้

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

  • [C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) จากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS และการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ

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

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

  • [C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การใช้งานการอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้มากที่สุดเท่าที่จะเป็นไปได้

10.2 ผู้ตรวจสอบ CTS

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

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

  • [C-0-1] ต้องดำเนินการกับทุกกรณีที่เกี่ยวข้องในเครื่องมือยืนยัน CTS อย่างถูกต้อง

CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางชนิดด้วย

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

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

ระบบอาจข้ามหรือละเว้นกรอบการทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับในเอกสารคำจำกัดความความเข้ากันได้นี้

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

11. ซอฟต์แวร์ที่อัปเดตได้

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

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

  • การดาวน์โหลด "ผ่านอากาศ (OTA)" จะมีการอัปเดตแบบออฟไลน์ผ่านรีบูต
  • อัปเดต "Tethered" ผ่าน USB จากโฮสต์ PC

  • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนพื้นที่เก็บข้อมูลแบบถอดได้

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

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