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

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

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

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

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

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

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

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

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

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

หมายเหตุ: ข้อกำหนดที่ไม่เกี่ยวข้องกับอุปกรณ์แท็บเล็ต 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] ต้องรองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม
  • [7.2.3/H-0-1] ต้องมีฟังก์ชันหน้าแรก ล่าสุด และกลับ
  • [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างไว้ของฟังก์ชัน Back (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] MUST return “true” for ActivityManager.isLowRamDevice() when there is less than 1GB of memory available to the kernel and userspace.

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

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

    • 280 dpi หรือต่ำกว่าในหน้าจอขนาดเล็ก/ปกติ*
    • 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 ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ*
    • 400 dpi ขึ้นไปบนหน้าจอขนาดใหญ่
    • xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ

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

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

    • 280 dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ*
    • 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 ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ*
    • 400 dpi ขึ้นไปบนหน้าจอขนาดใหญ่
    • 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

หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือเป็นไปตามข้อกําหนดทั้งหมดในการประกาศ Flag ฟีเจอร์ android.hardware.vr.high_performance อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [7.9.2/-1-1] ต้องประกาศ Flag ฟีเจอร์ 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] ต้องอนุญาตให้แอปของบุคคลที่สามแจ้งผู้ใช้เกี่ยวกับเหตุการณ์สำคัญผ่านคลาส Notification และ NotificationManager API
  • [3.8.3/H-0-2] ต้องรองรับการแจ้งเตือนแบบริชมีเดีย
  • [3.8.3/H-0-3] ต้องรองรับการแจ้งเตือนแบบ Heads-Up
  • [3.8.3/H-0-4] ต้องมีแผงการแจ้งเตือนเพื่อให้ผู้ใช้ควบคุมการแจ้งเตือนได้โดยตรง (เช่น ตอบกลับ เลื่อน ปิด บล็อก) ผ่านสิ่งที่ผู้ใช้สามารถโต้ตอบด้วย เช่น ปุ่มดำเนินการหรือแผงควบคุมตามที่ติดตั้งใช้งานใน AOSP
  • [3.8.4/H-SR] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการของ Assist

หากการใช้งานอุปกรณ์ 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] อัลกอริทึมการทริกเกอร์ การดูแลรักษา การปลุก และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน "แอปรอดำเนินการ" และ "โหมดสลีป" ต้องไม่เบี่ยงเบนไปจากโปรเจ็กต์โอเพนซอร์ส 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] ต้องทำให้นักพัฒนาแอปสามารถดูการใช้พลังงานนี้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats
  • [8.4/H] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน

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

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

2.2.5. รูปแบบการรักษาความปลอดภัย

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

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

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

  • [7.2.2/T-0-1] ต้องรองรับปุ่มบังคับทิศทาง
  • [7.2.3/T-0-1] ต้องมีฟังก์ชันหน้าแรกและย้อนกลับ
  • [7.2.3/T-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างไว้ของฟังก์ชัน Back (KEYCODE_BACK) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
  • [7.2.6.1/T-0-1] ต้องมีการสนับสนุนตัวควบคุมเกมและประกาศ Flag ฟีเจอร์ 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 ระดับ 4.2 และ HD 1080p (ที่ 60 fps)
  • [5.3.4/T-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีทั้งโปรไฟล์ HD ตามที่ระบุไว้ในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline, โปรไฟล์หลัก หรือโปรไฟล์ High ระดับ 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 โปรไฟล์ 2 (10 บิต)

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

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

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

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

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

  • [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] ต้องทำให้นักพัฒนาแอปสามารถดูการใช้พลังงานนี้ได้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats

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

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

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

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

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

2.4.1. ฮาร์ดแวร์

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

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

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

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

  • [7.3.1/W-SR] ขอแนะนำอย่างยิ่งให้ใส่ตัววัดความเร่งแบบ 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] MUST declare the feature android.hardware.type.watch.
  • [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH

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

ดูการใช้งานอุปกรณ์ที่ประกาศ Flag ฟีเจอร์ 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 จะจัดอยู่ในประเภทยานยนต์หากมีการประกาศฟีเจอร์ android.hardware.type.automotive หรือเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด

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

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

2.5.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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] ต้องรองรับบลูทูธและควรรองรับบลูทูธ LE

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

  • [7.4.3/ก] ควรรองรับโปรไฟล์การเข้าถึงข้อความ (MAP)

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

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

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

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

    • 280 dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
    • 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 หากใช้ความหนาแน่นต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
  • [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
  • [5.1/A-0-3] AAC ELD (AAC แบบลดเวลาหน่วงที่มีประสิทธิภาพมากขึ้น)

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

  • [3/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] ต้องติดตั้งใช้งานผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการของ Assistant

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

2.2.4. ประสิทธิภาพและกำลังไฟ

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

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

  • [8.3/A-0-2] อัลกอริทึมการทริกเกอร์ การดูแลรักษา การปลุก และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน "แอปรอดำเนินการ" และ "โหมดสลีป" ต้องไม่เบี่ยงเบนไปจากโปรเจ็กต์โอเพนซอร์ส 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/ก] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน
  • [8.4/A-0-4] ต้องทำให้นักพัฒนาแอปสามารถเข้าถึงการใช้พลังงานนี้ผ่านคำสั่ง Shell adb shell dumpsys batterystats

2.2.5. รูปแบบการรักษาความปลอดภัย

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

  • [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/แท็บ]อาจใช้ API ของอุปกรณ์เสริมแบบเปิดของ Android (AOA)

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

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

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

3. ซอฟต์แวร์

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

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

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

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

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

  • [C-0-4] การติดตั้งใช้งานอุปกรณ์ต้องยังคงมี API อยู่และทำงานอย่างสมเหตุสมผล แม้ว่าจะไม่ได้รวมฟีเจอร์ฮาร์ดแวร์บางอย่างซึ่งมี API ของ Android ไว้ก็ตาม โปรดดูข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ในส่วนที่ 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 "แบบซอฟต์" ที่สำคัญซึ่งใช้ได้เฉพาะในรันไทม์ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ขณะคอมไพล์แอปพลิเคชันได้

3.2.1. สิทธิ์

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

3.2.2. พารามิเตอร์การสร้าง

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

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

เช่น

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_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SERIAL หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^([a-zA-Z0-9]{6,20})$"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys, test-keys
เวลา ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น
ประเภท ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ user, userdebug หรือ eng
ผู้ใช้ ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")
SECURITY_PATCH ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์ไม่มีช่องโหว่ใดๆ เกี่ยวกับปัญหาที่อธิบายไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สำหรับสาธารณะ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กําหนดไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สําหรับสาธารณะหรือในคําแนะนําด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิวด์ที่เหมือนกันกับบิวด์นี้ทุกประการ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android และต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("")
BOOTLOADER ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุเวอร์ชัน Bootloader ภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+$"
getRadioVersion() ต้อง (เป็นหรือแสดงผล) ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกไว้ ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$"

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

3.2.3.1. Intent ของแอปพลิเคชันหลัก

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

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

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

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

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

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

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

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

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

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

  • [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] ต้องตั้งค่า Flag ฟีเจอร์ android.software.activities_on_secondary_displays
  • [C-1-2] ต้องรับประกันความเข้ากันได้ของ API คล้ายกับกิจกรรมที่ทำงานบนจอแสดงผลหลัก
  • [C-1-3] ต้องแสดงกิจกรรมใหม่ในจอแสดงผลเดียวกับกิจกรรมที่เปิดใช้งาน เมื่อเปิดใช้งานกิจกรรมใหม่โดยไม่ระบุจอแสดงผลเป้าหมายผ่าน ActivityOptions.setLaunchDisplayId() API
  • [C-1-4] MUST destroy all activities, when a display with the Display.FLAG_PRIVATE flag is removed.
  • [C-1-5] ต้องปรับขนาดกิจกรรมทั้งหมดใน VirtualDisplay ให้สอดคล้องกันหากปรับขนาดจอแสดงผล
  • อาจแสดง IME (เครื่องมือแก้ไขวิธีการป้อนข้อมูล ซึ่งเป็นตัวควบคุมผู้ใช้ที่ช่วยให้ผู้ใช้ป้อนข้อความได้) บนจอแสดงผลหลักเมื่อโฟกัสไปที่ช่องป้อนข้อความบนจอแสดงผลรอง
  • ควรใช้โฟกัสการป้อนข้อมูลในจอแสดงผลรองโดยแยกจากจอแสดงผลหลัก เมื่อรองรับการป้อนข้อมูลด้วยการสัมผัสหรือแป้นพิมพ์
  • ควรมี android.content.res.Configuration ซึ่งสอดคล้องกับจอแสดงผลนั้นเพื่อให้แสดงผล ทำงานได้อย่างถูกต้อง และรักษาความเข้ากันได้หากมีการเปิดใช้งานกิจกรรมในจอแสดงผลรอง

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

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

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติบนจอแสดงผลรอง และจอแสดงผลรองมี Flag 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] ต้องรายงาน Application Binary Interface (ABI) เดิมที่อุปกรณ์รองรับอย่างถูกต้องผ่านพารามิเตอร์ android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS และ android.os.Build.SUPPORTED_64_BIT_ABIS โดยแต่ละพารามิเตอร์เป็นรายการ ABI ที่คั่นด้วยคอมมาซึ่งเรียงลำดับจาก ABI ที่แนะนำมากที่สุดไปจนถึงน้อยที่สุด
  • [C-0-6] ต้องรายงานผ่านพารามิเตอร์ข้างต้นเฉพาะ ABI ที่บันทึกไว้และอธิบายไว้ในเอกสารประกอบการจัดการ ABI ของ Android NDK เวอร์ชันล่าสุด และต้องรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)

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

    • libaaudio.so (รองรับเสียงแบบเนทีฟของ AAudio)
    • 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 (Vulkan)
    • libz (การบีบอัด Zlib)
    • อินเทอร์เฟซ JNI

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

  • [C-0-9] ต้องระบุไลบรารีที่ไม่ใช่ AOSP เพิ่มเติมที่แสดงต่อแอปของบุคคลที่สามโดยตรงใน /vendor/etc/public.libraries.txt
  • [C-0-10] ต้องไม่แสดงไลบรารีแบบเนทีฟอื่นๆ ที่ติดตั้งใช้งานและจัดเตรียมไว้ใน AOSP เป็นไลบรารีระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป เนื่องจากมีการสงวนไว้
  • [C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่ระบุไว้ใน NDK ผ่านไลบรารี libGLESv3.so โปรดทราบว่าแม้ว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.1 จะอธิบายข้อกำหนดโดยละเอียดเพิ่มเติมสำหรับกรณีที่คาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างเต็มรูปแบบ
  • [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับสัญลักษณ์ฟังก์ชันหลักของ Vulkan 1.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

หากการติดตั้งใช้งานอุปกรณ์มีการใช้งาน android.webkit.Webview API อย่างสมบูรณ์ อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-1-1] MUST report android.software.webview.
  • [C-1-2] ต้องใช้บิลด์โปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android เวอร์ชันอัปสตรีมในสาขา Android 8.0 เพื่อติดตั้งใช้งาน android.webkit.WebView API

  • [C-1-3] สตริง User Agent ที่ WebView รายงานต้องเป็นรูปแบบนี้

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) 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 ต้นทาง
    • การติดตั้งใช้งานอุปกรณ์อาจไม่ใส่ Mobile ในสตริง 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 แทน Web Storage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จําเป็นใน Android เวอร์ชันในอนาคต
  • อาจจัดส่งสตริง User Agent ที่กําหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
  • ควรรองรับ HTML5 ให้ได้มากที่สุดในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit ต้นทางหรือแอปพลิเคชันทดแทนของบุคคลที่สาม)

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์มีแอป 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] ต้องมีการสนับสนุน App Widgets ในตัวและแสดงสิ่งอํานวยความสะดวกของอินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ App Widgets ออกภายใน Launcher โดยตรง
  • [C-1-3] ต้องแสดงผลวิดเจ็ตขนาด 4 x 4 ในตารางกริดมาตรฐานได้ ดูรายละเอียดได้ในหลักเกณฑ์การออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK
  • อาจรองรับวิดเจ็ตแอปพลิเคชันในหน้าจอล็อก

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ลักษณะการทำงานเริ่มต้นควรเป็นการแสดงผลการค้นหาและคำแนะนำของเครื่องมือค้นหาบนเว็บ

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

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

  • [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 และแสดง Toast จากแอปพลิเคชันต่อผู้ใช้ปลายทางในลักษณะที่มองเห็นได้ชัดเจน

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11. โปรแกรมรักษาหน้าจอ (ก่อนหน้านี้เรียกว่า "ความฝัน")

Android รองรับโปรแกรมรักษาหน้าจอแบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า "ภาพพักหน้าจอ" โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันได้เมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่ได้ใช้งานหรือวางอยู่ในแท่นชาร์จบนโต๊ะ อุปกรณ์ Android Watch อาจใช้โปรแกรมรักษาหน้าจอ แต่การใช้งานอุปกรณ์ประเภทอื่นๆ ควรรองรับโปรแกรมรักษาหน้าจอและให้ตัวเลือกการตั้งค่าแก่ผู้ใช้ในการกำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อ Intent 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] ต้องประกาศการรองรับโปรไฟล์ที่จัดการผ่าน Flag ฟีเจอร์ android.software.managed_users ยกเว้นในกรณีที่อุปกรณ์ได้รับการกำหนดค่าให้รายงานตัวเองว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือกำหนดให้จัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดออกไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

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

3.9.1.1 การจัดเตรียมเจ้าของอุปกรณ์

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

  • [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์นโยบายอุปกรณ์ (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 Communication (NFC) ผ่าน Flag ฟีเจอร์ android.hardware.nfc และได้รับข้อความ NFC ที่มีระเบียนประเภท MIME MIME_TYPE_PROVISIONING_NFC
    • เมื่อการติดตั้งใช้งานอุปกรณ์มีข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
  • [C-1-2] ต้องไม่ตั้งค่าแอปพลิเคชัน (รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า) เป็นแอปเจ้าของอุปกรณ์โดยไม่ได้รับความยินยอมหรือการดำเนินการอย่างชัดเจนจากผู้ใช้หรือผู้ดูแลระบบของอุปกรณ์

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องระบุการใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบ SDK ของ Accessibility 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] ต้องติดตั้งใช้งานบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้าเหล่านี้เป็นแอปที่รองรับการบูตโดยตรงเมื่อพื้นที่เก็บข้อมูลได้รับการเข้ารหัสด้วยการเข้ารหัสตามไฟล์ (FBE)
  • ควรมีกลไกในขั้นตอนการตั้งค่าแบบพร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงมีตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผล และท่าทางสัมผัสสำหรับการขยาย

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

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

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

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

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

3.12. TV Input Framework

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

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

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

3.12.1. แอปทีวี

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

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

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

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

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

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, Back และ Home บนอุปกรณ์อินพุตของอุปกรณ์ทีวี Android (เช่น รีโมตคอนโทรล แอปพลิเคชันรีโมตคอนโทรล หรือเกมคอนโทรลเลอร์)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องสามารถติดตั้งและเรียกใช้ไฟล์ ".apk" ของ Android ตามที่เครื่องมือ "aapt" ที่สร้างไว้ใน Android SDK อย่างเป็นทางการ
  • เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องยาก เราจึงขอแนะนำให้ใช้การติดตั้งใช้งานระบบการจัดการแพ็กเกจของการติดตั้งใช้งานอ้างอิง AOSP
  • [C-0-2] ต้องรองรับการยืนยันไฟล์ ".apk" โดยใช้ APK Signature Scheme v2 และการรับรอง JAR
  • [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik Bytecode หรือ RenderScript Bytecode ในลักษณะที่ทําให้ติดตั้งและใช้งานไฟล์เหล่านั้นในอุปกรณ์อื่นๆ ที่เข้ากันได้ไม่ได้

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

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
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

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

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

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 Kbps ถึง 23.85 Kbps ที่อัตราตัวอย่าง 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 และ Mobile XMF รองรับรูปแบบริงโทน RTTTL/RTX, OTA และ iMelody
  • ประเภท 0 และ 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 ขึ้นไป)
PCM/WAVE PCM แบบเชิงเส้น 16 บิต (อัตราสูงสุดตามขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM ดิบที่ความถี่ 8000, 11025, 16000 และ 44100 Hz WAVE (.wav)
Opus Matroska (.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
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] ดิบ

5.1.6. รายละเอียดตัวแปลงรหัสรูปภาพ

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG Base+progressive 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_FormatYUV420Flexible)

หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับโปรไฟล์ 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 ขึ้นไป)
H.265 HEVC ดูรายละเอียดได้ที่ส่วนที่ 5.3 MPEG-4 (.mp4)
MPEG-2 โปรไฟล์หลัก MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 ดูรายละเอียดที่ส่วนที่ 5.2 และ 5.3
VP9 ดูรายละเอียดได้ที่ส่วนที่ 5.3

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

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

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

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

  • [C-1-1] ต้องรองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 หรือ H.264 อย่างใดอย่างหนึ่งเป็นอย่างน้อย และทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
  • ควรรองรับทั้งโปรแกรมเปลี่ยนไฟล์วิดีโอ 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 (การจัดเรียงข้อมูลเป็นชิ้นแบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (ข้อมูลเป็นชิ้นที่ซ้ำกัน) หรือไม่ก็ได้ นอกจากนี้ เราขอแนะนำว่าโปรแกรมเปลี่ยนไฟล์ไม่ควรใช้ ASO, FMO และ RS สำหรับโปรไฟล์พื้นฐานเพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android เครื่องอื่นๆ
  • [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
  • ควรรองรับโปรไฟล์หลักระดับ 4
  • ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้

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

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

5.2.3. VP8

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

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

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน Media 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] ต้องรองรับโปรไฟล์แบบง่ายระดับ 3

5.3.4. H.264

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน การรองรับ ASO (การจัดเรียง Slice แบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (Slice ซ้ำ) เป็นตัวเลือก
  • [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline และโปรไฟล์หลักระดับ 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] ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

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

  • [C-1-2] ต้องบันทึกด้วยอัตราการสุ่มตัวอย่างที่สูงกว่าโดยไม่ต้องอัปแซมเปิล

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

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

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

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้บันทึกเนื้อหาเสียงดิบในคุณภาพระดับวิทยุ AM และ DVD อุปกรณ์จะมีลักษณะดังนี้

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

5.4.2. บันทึกเสียงเพื่อจดจำเสียงพูด

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

  • [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ที่อัตราตัวอย่างเสียง 44100 หรือ 48000
  • [C-1-2] ต้องปิดใช้การประมวลผลเสียงแบบลดเสียงรบกวนโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง AudioSource.VOICE_RECOGNITION
  • [C-1-3] โดยค่าเริ่มต้น จะต้องปิดใช้การควบคุมอัตราขยายเสียงอัตโนมัติเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง AudioSource.VOICE_RECOGNITION
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยมีลักษณะเป็นแอมพลิจูดที่ราบเรียบเทียบกับลักษณะความถี่โดยประมาณ กล่าวคือ ±3 dB จาก 100 Hz ถึง 4000 Hz
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยตั้งค่าความไวอินพุตเพื่อให้แหล่งที่มาของระดับกำลังเสียง (SPL) 90 dB ที่ 1000 Hz ให้ค่า RMS เท่ากับ 2500 สำหรับตัวอย่าง 16 บิต
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL อินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB จาก -18 dB ถึง +12 dB เทียบกับ SPL 90 dB ที่ไมโครโฟน
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยมีความเพี้ยนตามฮาร์โมนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ที่ไมโครโฟน

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

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

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

คลาส android.media.MediaRecorder.AudioSource มีแหล่งที่มาของเสียง REMOTE_SUBMIX

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

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

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

5.5. การเล่นเสียง

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

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

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

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

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

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

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

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 กับเวลาที่เสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสามารถสังเกตได้ภายนอก
  • เวลาในการตอบสนองของเอาต์พุตแบบไม่อุ่นเครื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรกเมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดอยู่ก่อนคำขอ
  • เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมต่อๆ ไปหลังจากที่อุปกรณ์เล่นเสียง
  • เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่เสียงจากสภาพแวดล้อมแสดงต่ออุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต และเวลาที่แอปพลิเคชันอ่านเฟรมที่สอดคล้องกันของข้อมูลที่เข้ารหัส PCM
  • ข้อมูลเข้าสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้งานไม่ได้หรือไม่พร้อมใช้งาน
  • เวลาในการตอบสนองของอินพุตแบบ Cold ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่ได้ใช้งานและปิดอยู่ก่อนคําขอ
  • เวลาในการตอบสนองของการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ ไปขณะที่อุปกรณ์บันทึกเสียง
  • การกระวนของเอาต์พุตแบบเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตแบบ Cold แยกกัน
  • ความผันผวนของอินพุตแบบเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบ Cold Start แยกกัน
  • เวลาในการตอบสนองแบบไปกลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่องบวกเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องบวกระยะเวลาบัฟเฟอร์ 1 รายการ ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาในการลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
  • OpenSL ES PCM buffer queue API ชุด API OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
  • API เสียงแบบเนทีฟของ AAudio ชุด AAudio API ภายใน Android NDK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

รูปแบบกลุ่ม ข้อมูลอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
MPEG-2 Transport Stream 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-LATM RFC 6416 ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
H263-1998 RFC 3551
RFC 4629
RFC 2190 		ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.3
H263-2000 RFC 4629 ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.3
AMR RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-NB ได้ที่ส่วนที่ 5.1.1
AMR-WB RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-WB ได้ที่ส่วนที่ 5.1.1
MP4V-ES RFC 6416 ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ได้ที่ส่วนที่ 5.1.3
mpeg4-generic RFC 3640 ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
MP2T RFC 2250 ดูรายละเอียดได้ที่ MPEG-2 Transport Stream ในส่วน HTTP Live Streaming

5.8. Secure Media

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

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

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

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

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

  • [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] ต้องตั้งค่าความไวของอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ค่าตอบสนอง RMS 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างแบบทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

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

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

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

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

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

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

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

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

6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

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

  • [C-0-1] ต้องรองรับเครื่องมือสําหรับนักพัฒนาแอป Android ที่มีให้ใน Android SDK

  • Android Debug Bridge (adb)

    • [C-0-2] ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK รวมถึง dumpsys
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ระบบของอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่าน dumpsys
    • [C-0-4] ต้องมีแดม่อน adb ฝั่งอุปกรณ์ที่ไม่ได้ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
    • [C-0-5] MUST support secure adb. Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักซึ่งผ่านการตรวจสอบสิทธิ์

    • [C-0-6] ต้องมีกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ เช่น

      • การติดตั้งใช้งานอุปกรณ์ที่ไม่มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วงต้องใช้ adb ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
      • ต้องจัดหาไดรเวอร์สำหรับ Windows 7, 9 และ 10 ซึ่งช่วยให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์ได้โดยใช้โปรโตคอล ADB

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรปิดใช้งานโดยค่าเริ่มต้น แต่ต้องรองรับเมื่อใดก็ตามที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ดังที่กล่าวไว้ข้างต้น
  • Monkey
    • [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 ซึ่งคำนวณโดยสูตร pixels = dps * (density/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_WATCH และรายงานขนาด small สำหรับ Configuration.screenLayout ต้องมีขนาดอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด normal สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด large สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 960 dp x 720 dp

  • [C-0-2] การติดตั้งใช้งานอุปกรณ์ต้องรองรับขนาดหน้าจอตามที่แอปพลิเคชันระบุไว้อย่างถูกต้องผ่านแอตทริบิวต์ <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

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

แม้ว่าจะไม่มีข้อจํากัดสําหรับค่าสัดส่วนภาพของหน้าจอในการแสดงผลหน้าจอจริง แต่สัดส่วนภาพของหน้าจอในการแสดงผลเชิงตรรกะที่แอปของบุคคลที่สามแสดงผลอยู่ ซึ่งสามารถดึงมาจากค่าความสูงและความกว้างที่รายงานผ่าน view.Display API และ Configuration 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 เชิงตรรกะรายการใดรายการหนึ่งต่อไปนี้ผ่าน 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.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15 เท่า
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

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

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริก Display ทั้งหมดที่กําหนดไว้ใน 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] ต้องรองรับ OpenGL ES Android Extension Pack โดยสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES โดยสมบูรณ์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-5-1] ต้องระบุการรองรับผ่าน Flag ฟีเจอร์ 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] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วย Flag ฟีเจอร์ android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องระบุ VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ API เนทีฟของ Vulkan 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 สำหรับ API เนทีฟของ Vulkan vkEnumeratePhysicalDevices()
7.1.4.3 RenderScript
  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือมุมมองผ่านการใช้แท็กไฟล์ Manifest android:hardwareAccelerated หรือการเรียก API โดยตรง

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

  • [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
  • [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งด้วยฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยนักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI

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

  • [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกันกับการใช้งาน Android เวอร์ชันที่อัปเดต
7.1.4.5 จอแสดงผลแบบช่วงสีกว้าง

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

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
  • [C-1-2] ต้องมีจอแสดงผลที่ช่วงสีครอบคลุมช่วงสี sRGB ทั้งหมดในพื้นที่สี CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่มีพื้นที่ของช่วงสีอย่างน้อย 90% ของ 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% ในพื้นที่สี xyY ของ CIE 1931 แม้ว่าช่วงสีของหน้าจอจะไม่มีการระบุ

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. แป้นพิมพ์

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

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

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

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

7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.distinct อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-2-1] ต้องประกาศรองรับ android.hardware.faketouch
  • [C-2-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการแยกกัน

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.jazzhand อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องประกาศรองรับ android.hardware.faketouch
  • [C-3-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์ที่แตกต่างกันอย่างน้อย 5 รายการ (การติดตามมือของนิ้ว) โดยอิสระอย่างสมบูรณ์

7.2.6. การรองรับเกมคอนโทรลเลอร์

7.2.6.1. การแมปปุ่ม

หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.hardware.gamepad อุปกรณ์จะต้องมีคุณสมบัติดังนี้ [C-1-1] ต้องมีตัวควบคุมแบบฝังหรือจัดส่งพร้อมตัวควบคุมแยกต่างหากในกล่อง ซึ่งจะเป็นช่องทางให้ป้อนเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่าง [C-1-2] ต้องสามารถแมปเหตุการณ์ HID กับค่าคงที่ view.InputEvent ของ Android ที่เกี่ยวข้องตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งาน Android ขั้นต้นรวมถึงการติดตั้งใช้งานสำหรับตัวควบคุมเกมที่เป็นไปตามข้อกำหนดนี้

ปุ่ม การใช้งาน HID2 ปุ่ม Android
ก1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
ปุ่ม D-pad ขึ้น1
ปุ่ม D-pad ลง1 		0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ขวา1 		0x01 0x00393 AXIS_HAT_X4
ปุ่ม L1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่ม L R ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกแท่งบังคับซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกแท่งบังคับด้านขวา1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Home1 0x0c 0x0223 KEYCODE_HOME (3)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 การใช้งาน HID ข้างต้นต้องประกาศภายใน CA ของเกมแพด (0x01 0x0005)

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

4 MotionEvent

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

1 MotionEvent

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

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

7.3. เซ็นเซอร์

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

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

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

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

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

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

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

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

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

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

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

    • [C-1-3] ต้องระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วได้ภายใน 0.5 เมตรต่อวินาที อย่างน้อย 95% ของเวลา
    • [C-1-4] ต้องติดตามและรายงานผ่าน GnssStatus.Callback พร้อมกันอย่างน้อย 8 ดวงจากกลุ่มดาวหนึ่งๆ
    • ควรติดตามดาวเทียมอย่างน้อย 24 ดวงจากกลุ่มดาวหลายกลุ่มได้พร้อมกัน (เช่น GPS + Glonass, Beidou, Galileo อย่างใดอย่างหนึ่งอย่างน้อย 1 ดวง)
    • [C-1-5] ต้องรายงานรุ่นเทคโนโลยี GNSS ผ่าน API การทดสอบ "getGnssYearOfHardware"
    • [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 Flag ฟีเจอร์และ LocationManager.getGnssYearOfHardware() Test API ที่รายงานปี "2016" ขึ้นไป อุปกรณ์จะมีลักษณะดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่าน android.hardware.location.gps Flag ฟีเจอร์และ 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) อนุญาตให้ความแปรปรวนเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของ Gyro ที่อัตราตัวอย่าง 1 Hz ค่าดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
  • [SR] ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่ใช้เซ็นเซอร์ SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
  • [SR] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการสอบเทียบต้องน้อยกว่า 0.01 rad/s เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • ควรรายงานเหตุการณ์อย่างน้อย 200 Hz

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

  • [C-2-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_ROTATION_VECTOR

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

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

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

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

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

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

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] ต้องระบุความสามารถผ่าน Flag ฟีเจอร์ 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/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์ของเซ็นเซอร์
    • ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ไม่เกิน 3 mW
    • ควรมีความเสถียรของค่าเบี่ยงเบนจากค่าเฉลี่ยของสัญญาณรบกวนแบบคงที่ที่น้อยกว่า 15 μg √Hz จากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
    • ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 1mg / °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°/วินาที/√Hz
    • ควรมีความเสถียรของค่าเบี่ยงเบนคงที่ที่ < 0.0002 °/s √Hz จากชุดข้อมูลแบบคงที่ 24 ชั่วโมง
    • ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 0.05 °/ วินาที / °C
    • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิไม่เกิน 0.02% / °C
    • ควรมีค่าความไม่เป็นเชิงเส้นของเส้นค่าดีที่สุดไม่เกิน 0.2%
    • ควรมีความหนาแน่นของสัญญาณรบกวนไม่เกิน 0.007 °/s/√Hz
    • ควรมีย่านความถี่ของสัญญาณรบกวนสีขาวเพื่อให้แน่ใจว่ามีคุณสมบัติเพียงพอสำหรับความสมบูรณ์ของสัญญาณรบกวนจากเซ็นเซอร์
    • ควรมีข้อผิดพลาดในการสอบเทียบน้อยกว่า 0.002 rad/s ในอุณหภูมิช่วง 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่

  • [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 ถึง 1,100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่การวัดขั้นต่ำ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่การวัดสูงสุด 10 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนการวัดไม่เกิน 2 Pa/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 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] ต้องมีการประทับเวลาเหตุการณ์ของเซ็นเซอร์ Gyroscope บนฐานเวลาเดียวกับระบบย่อยของกล้องและมีความผิดพลาดไม่เกิน 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] ต้องประกาศการรองรับประเภทช่องทางโดยตรงและระดับอัตรารายงานโดยตรงอย่างถูกต้องผ่าน isDirectChannelTypeSupported และ getHighestDirectReportRateLevel API
  • [C-3-2] ต้องรองรับแชแนลโดยตรงของเซ็นเซอร์อย่างน้อย 1 ใน 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศรองรับแชแนลโดยตรงของเซ็นเซอร์
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สําหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุก) ประเภทต่อไปนี้
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

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

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

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

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

  • [C-1-1] ต้องประกาศการรองรับฟีเจอร์ android.hardware.fingerprint
  • [C-1-2] ต้องใช้งาน 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] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.
  • [C-1-10] เมื่ออัปเกรดจากเวอร์ชันที่เก่ากว่า Android 6.0 จะต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้นหรือนำออก
  • [SR] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% โดยวัดจากอุปกรณ์
  • [SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเวลาที่แตะเซ็นเซอร์ลายนิ้วมือจนกว่าหน้าจอจะปลดล็อกสำหรับลายนิ้วมือที่ลงทะเบียน 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. โทรศัพท์

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

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

หากการติดตั้งใช้งานอุปกรณ์มีโทรศัพท์ GSM หรือ CDMA อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony และ Flag ฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [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] ต้องรายงาน Flag ฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
  • [C-1-3] ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-4] ต้องรองรับมัลติแคสต์ DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ในทุกช่วงเวลาของการทำงาน ซึ่งรวมถึงในกรณีต่อไปนี้
    • แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงาน
    • สำหรับการติดตั้งใช้งานอุปกรณ์ Android Television แม้ว่าจะอยู่ในสถานะพลังงานสแตนด์บาย
  • ควรสุ่มที่อยู่ 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] ต้องติดตั้งใช้งาน Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct
  • [C-1-3] ต้องรองรับการใช้งาน Wi-Fi ปกติ
  • ควรรองรับการใช้งาน Wi-Fi และ Wi-Fi Direct พร้อมกัน

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

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

  • [C-1-1] ต้องประกาศการรองรับ TDLS ผ่าน WifiManager.isTdlsSupported
  • ควรใช้ TDLS เฉพาะเมื่อเป็นไปได้และมีประโยชน์เท่านั้น
  • ควรใช้การเรียนรู้เชิงสืบสวนบ้างและอย่าใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าใช้งาน Wi-Fi
7.4.2.3. 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 Passpoint อุปกรณ์จะมีลักษณะดังนี้

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

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

  • [C-2-1] การใช้งาน WifiManager API ที่เกี่ยวข้องกับ Passpoint จะต้องแสดง UnsupportedOperationException

7.4.3. บลูทูธ

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

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

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

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

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

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

7.4.4. Near Field Communication

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

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

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

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

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

  • [C-1-3] ต้องสามารถส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบ peer-to-peer ต่อไปนี้

    • ISO 18092
    • LLCP 1.2 (กำหนดโดย NFC Forum)
    • SDP 1.0 (กำหนดโดย NFC Forum)
    • โปรโตคอล NDEF Push
    • SNEP 1.0 (กำหนดโดย NFC Forum)
  • [C-1-4] ต้องรองรับ Android Beam และต้องเปิดใช้ Android Beam โดยค่าเริ่มต้น
  • [C-1-5] ต้องสามารถส่งและรับโดยใช้ Android Beam เมื่อเปิดใช้ Android Beam หรือเปิดโหมด NFC P2p ที่เป็นกรรมสิทธิ์อื่น
  • [C-1-6] ต้องติดตั้งใช้งานเซิร์ฟเวอร์เริ่มต้น SNEP ข้อความ NDEF ที่ถูกต้องซึ่งเซิร์ฟเวอร์ SNEP เริ่มต้นได้รับต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้ Android Beam ในการตั้งค่าต้องไม่ปิดใช้การส่งข้อความ NDEF ขาเข้า
  • [C-1-7] ต้องปฏิบัติตามandroid.settings.NFCSHARING_SETTINGSความตั้งใจที่จะแสดงการตั้งค่าการแชร์ NFC
  • [C-1-8] ต้องติดตั้งใช้งานเซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP ต้องได้รับการประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้น SNEP
  • [C-1-9] ต้องติดตั้งใช้งานไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Android Beam หากไม่พบเซิร์ฟเวอร์ 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 ไปยังบลูทูธเมื่ออุปกรณ์รองรับโปรไฟล์การพุชออบเจ็กต์บลูทูธ
  • [C-1-12] ต้องรองรับการส่งต่อการเชื่อมต่อไปยังบลูทูธเมื่อใช้ android.nfc.NfcAdapter.setBeamPushUris โดยการใช้ข้อกำหนดเฉพาะ "Connection Handover เวอร์ชัน 1.2" และ "การจับคู่ที่ปลอดภัยแบบง่ายของบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" จาก NFC Forum การใช้งานดังกล่าวต้องใช้บริการ LLCP สำหรับการส่งต่อด้วยชื่อบริการ "urn:nfc:sn:handover" เพื่อแลกเปลี่ยนคำขอส่งต่อ/ระเบียนที่กำหนดผ่าน NFC และต้องใช้โปรไฟล์การพุชออบเจ็กต์บลูทูธสำหรับการโอนข้อมูลบลูทูธจริง การติดตั้งใช้งานควรยังคงยอมรับคําขอ GET ของ SNEP เพื่อแลกเปลี่ยนคําขอส่งต่อ/บันทึกที่เลือกผ่าน NFC เพื่อเหตุผลเดิม (เพื่อให้เข้ากันได้กับอุปกรณ์ Android 4.1 ต่อไป) อย่างไรก็ตาม การติดตั้งใช้งานไม่ควรส่งคําขอ SNEP GET เพื่อดําเนินการเปลี่ยนผ่านการเชื่อมต่อ
  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC
  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอที่ใช้งานอยู่และหน้าจอล็อกที่ปลดล็อก
  • ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC แบบฟิล์มบางได้

(โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่มีให้บริการสำหรับข้อกำหนด JIS, ISO และ NFC Forum ที่ระบุไว้ข้างต้น)

Android รองรับโหมดการจําลองบัตรของโฮสต์ (HCE) ของ NFC

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทาง Application ID (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] ต้องใช้ NfcF Card Emulation API ตามที่ระบุไว้ใน 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 รูปแบบ กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต, Bluetooth 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 ในโหมดสลีป
  • [C-0-5] การจำกัดอัตราการส่งข้อมูลต้องไม่ทําให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่เป็นไปตามข้อกําหนดของ IPv6 ซึ่งใช้อายุของ RA อย่างน้อย 180 วินาที
  • ควรรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 รายการ เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
  • อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ

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

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

  • [C-1-1] ต้องรองรับการใช้งานแบบ Dual-Stack และ IPv6 เท่านั้นบน Wi-Fi

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

  • [C-2-1] ต้องรองรับการดำเนินการแบบ Dual-Stack ในอีเทอร์เน็ต

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

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

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

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

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

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] ต้องรายงาน Flag ฟีเจอร์ 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] ต้องรายงาน Flag ฟีเจอร์ 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] ต้องประกาศ Flag ฟีเจอร์แพลตฟอร์ม 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. ลักษณะการทํางานของ Camera API

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

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

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

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ส่งไปยังการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียก android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องเป็นรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบพรีวิวคือ YCbCr_420_SP ข้อมูลใน byte[] ที่ส่งไปยัง 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] ยังคงต้องใช้ Camera API ทั้งหมดที่รวมอยู่ในเอกสารประกอบของ Android SDK ไม่ว่าอุปกรณ์จะมีระบบโฟกัสอัตโนมัติแบบฮาร์ดแวร์หรือความสามารถอื่นๆ ก็ตาม เช่น กล้องที่ไม่มีโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback ที่ลงทะเบียนไว้ (แม้ว่าจะไม่มีความเกี่ยวข้องกับกล้องที่ไม่ใช้โฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการดำเนินการนี้มีผลกับกล้องหน้าด้วย เช่น แม้ว่ากล้องหน้าส่วนใหญ่จะไม่รองรับโฟกัสอัตโนมัติ แต่การเรียกกลับ API ยังคงต้อง "จำลอง" ตามที่อธิบายไว้
  • [C-0-6] ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters ในทางกลับกัน การติดตั้งใช้งานอุปกรณ์ต้องไม่ยอมรับหรือรู้จักค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ใน android.hardware.Camera.Parameters กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และจะต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการถ่ายภาพแบบ High Dynamic Range (HDR) จะต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR
  • [C-0-7] ต้องรายงานระดับการสนับสนุนที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK และรายงานFlag ฟีเจอร์ของเฟรมเวิร์กที่เหมาะสม
  • [C-0-8] และต้องประกาศความสามารถของกล้องแต่ละรายการของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศFlag ฟีเจอร์ที่เหมาะสม และต้องกำหนด Flag ฟีเจอร์หากอุปกรณ์กล้องที่แนบมารองรับฟีเจอร์ดังกล่าว
  • [C-0-9] ต้องออกอากาศ Intent Camera.ACTION_NEW_PICTURE ทุกครั้งที่กล้องถ่ายภาพใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ
  • [C-0-10] ต้องออกอากาศ Intent Camera.ACTION_NEW_VIDEO ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องให้บริการพื้นที่เก็บข้อมูลสำหรับแอปพลิเคชันต่างๆ ร่วมกัน ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์" หรือเส้นทาง Linux "/sdcard" ที่ติดตั้ง
  • [C-0-2] ต้องกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งติดตั้งโดยค่าเริ่มต้น หรือที่เรียกว่า "พร้อมใช้งานทันที" ไม่ว่าพื้นที่เก็บข้อมูลจะใช้กับคอมโพเนนต์พื้นที่เก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดออกได้ (เช่น ช่องการ์ด Secure Digital) ก็ตาม
  • [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 และรองรับโปรโตคอลการโอนสื่อ อุปกรณ์จะมีลักษณะดังนี้

  • ควรเข้ากันได้กับโฮสต์ MTP ของ Android ที่ใช้อ้างอิง ซึ่งก็คือ 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 Type-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 สําหรับการแลกเปลี่ยนบทบาทของข้อมูลและการจ่ายไฟเมื่อรองรับ USB Type-C และโหมดโฮสต์ USB
  • ควรรองรับ Power Delivery สำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่นๆ เช่น การแสดงผล
  • ควรใช้ 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 มาตรฐาน กล่าวคือ ต้องมีคุณสมบัติอย่างใดอย่างหนึ่งต่อไปนี้
    • มีพอร์ต Type-C ในอุปกรณ์หรือมาพร้อมกับสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์เป็นพอร์ต USB Type-C มาตรฐาน (อุปกรณ์ USB Type-C)
    • มีขั้วต่อประเภท A ในอุปกรณ์หรือมีสายสำหรับแปลงพอร์ตที่เป็นกรรมสิทธิ์ของอุปกรณ์เป็นพอร์ต USB ประเภท A มาตรฐาน
    • มีพอร์ต micro-AB ในอุปกรณ์ ซึ่งควรมาพร้อมกับสายที่เปลี่ยนเป็นพอร์ต Type-A มาตรฐาน
  • [C-1-3] ต้องไม่มีอะแดปเตอร์ที่แปลงจากพอร์ต USB Type A หรือ micro-AB เป็นพอร์ต Type-C (เต้ารับ)
  • [SR] ขอแนะนําอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่ออยู่ขณะอยู่ในโหมดโฮสต์ แสดงกระแสแหล่งที่มาอย่างน้อย 1.5 แอมป์ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับที่ 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสเอาต์พุตของพอร์ตดาวน์สตรีมการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะของการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 สำหรับขั้วต่อ Micro-AB
  • ควรติดตั้งใช้งานและรองรับมาตรฐาน USB Type-C

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

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

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

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

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

  • [C-4-1] ต้องใช้งานฟังก์ชันพอร์ตแบบ 2 บทบาทตามที่ระบุไว้ในข้อกำหนด USB Type-C (ส่วนที่ 4.5.1.3.3)
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort, ควรรองรับอัตราการรับส่งข้อมูล SuperSpeed ของ USB และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทระหว่างการจ่ายไฟและการโอนข้อมูล
  • [SR] ขอแนะนำอย่างยิ่งว่าอย่ารองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก ก ของข้อกำหนดเฉพาะของสายและขั้วต่อ 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 ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็น No-Op เป็นอย่างน้อย

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

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

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

หากการติดตั้งใช้งานอุปกรณ์มีแจ็คเสียง 3.5 มม. แบบ 4 สาย อุปกรณ์จะมีลักษณะดังนี้

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

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

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

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

เสียงที่เกือบเป็นคลื่นอัลตราซาวด์คือย่านความถี่ 18.5-20 KHz

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

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

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

  • [C-1-1] การตอบสนองกำลังไฟฟ้าเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องต่ำกว่าการตอบสนองที่ 2 kHz ไม่เกิน 15 dB
  • [C-1-2] อัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ไม่ถ่วงน้ำหนักของไมโครโฟนในช่วงความถี่ 18.5-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 ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลภาพ 3 มิติของการแจ้งเตือนและปิดใช้คอมโพเนนต์ UI ของระบบแบบโมโนคูลาร์ขณะที่แอปพลิเคชัน VR อยู่โฟกัสของผู้ใช้

7.9.2 ประสิทธิภาพสูงสำหรับ Virtual Reality

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

  • [C-1-1] ต้องมี Physical Core อย่างน้อย 2 รายการ
  • [C-1-2] MUST declare 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] ต้องรองรับ Flag AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER และ AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ของ AHardwareBuffer ตามที่อธิบายไว้ใน 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 (เทียบเท่ากับ 1920x1080@30fps-5Mbps 4 อินสแตนซ์)
  • [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าอุณหภูมิผิวหนังที่ถูกต้อง
  • [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 เพื่อแสดงจำนวนแกนประมวลผลสำหรับแอปพลิเคชันที่ใช้งานอยู่โดยเฉพาะ

หากรองรับแกนเอกสิทธิ์ แกนจะมีลักษณะดังนี้

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

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 สถานะใดสถานะหนึ่งหรือทั้งหมดตามที่ระบุโดยอินเทอร์เฟซการกําหนดค่าและการจัดการพลังงานขั้นสูง (ACPI)

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

  • [C-1-1] ต้องเข้าสู่สถานะเหล่านี้เมื่อปิดฝาที่เป็นส่วนหนึ่งของอุปกรณ์เท่านั้น

8.4 การบัญชีการใช้พลังงาน

การบัญชีและการรายงานการใช้พลังงานที่แม่นยำยิ่งขึ้นจะช่วยให้นักพัฒนาแอปมีแรงจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน

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

  • [SR] ขอแนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ซึ่งกำหนดค่าการใช้พลังงานปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
  • [SR] ขอแนะนําอย่างยิ่งให้รายงานการสิ้นเปลืองพลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime
  • [SR] ขอแนะนำอย่างยิ่งให้นักพัฒนาแอปใช้คำสั่งเชลล์ 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 แกนขึ้นไป อุปกรณ์จะมีลักษณะดังนี้

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

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

  • [C-2-1] ต้องรายงานหมายเลขรหัสของคอร์แบบพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับบนสุดสามารถจองได้ผ่านเมธอด Process.getExclusiveCores() API
  • [C-2-2] ต้องไม่อนุญาตให้มีกระบวนการใดๆ ใน User Space ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อทำงานบนแกนหลัก แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางรายการทำงานได้ตามความจำเป็น

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

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 รูปแบบ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก
  • [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการโดยใช้รหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงนามและสร้างอย่างถูกต้องตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3. สิทธิ์ในระบบไฟล์

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

9.4. สภาพแวดล้อมการดําเนินการอื่น

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

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

  • [C-0-2] รันไทม์สำรองต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

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

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

  • [C-0-5] รันไทม์อื่นต้องไม่เปิดใช้งาน มอบสิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] รันไทม์อื่นต้องไม่เปิดใช้งาน ไม่ได้รับสิทธิ์ หรือให้สิทธิ์แก่แอปพลิเคชันอื่นๆ เกี่ยวกับสิทธิ์ของผู้ดูแลระบบ (root) หรือรหัสผู้ใช้อื่นๆ

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

หากการติดตั้งใช้งานอุปกรณ์มีผู้ใช้หลายคนและไม่ประกาศ 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 ที่มีการปรับเวลากลุ่มเธรด (TSYNC) ตามที่อธิบายไว้ในส่วนการกําหนดค่าเคอร์เนลของ source.android.com

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

  • [C-0-7] ต้องติดตั้งใช้งานกลไกการป้องกันการเขียนไปยังบัฟเฟอร์สแตกเกินขอบเขตที่กำหนด (stack buffer overflow) ของเคิร์นัล ตัวอย่างกลไกดังกล่าว ได้แก่ CC_STACKPROTECTOR_REGULAR และ CONFIG_CC_STACKPROTECTOR_STRONG
  • [C-0-8] ต้องใช้การป้องกันหน่วยความจำเคอร์เนลอย่างเข้มงวดในกรณีที่โค้ดที่เรียกใช้ได้เป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวจะไม่สามารถเรียกใช้ได้และเขียนไม่ได้ และข้อมูลแบบเขียนได้จะไม่สามารถเรียกใช้ได้ (เช่น CONFIG_DEBUG_RODATA หรือ CONFIG_STRICT_KERNEL_RWX)
  • [SR] ขอแนะนำอย่างยิ่งให้ทำเครื่องหมายข้อมูลเคอร์เนลที่เขียนในระหว่างการเริ่มต้นเท่านั้นว่าอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น __ro_after_init)
  • [SR} ขอแนะนําอย่างยิ่งให้ใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และพื้นที่เคอร์เนล (เช่น 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 ที่มีข้อมูลความผันผวนของบูตโหลดเดอร์ผ่าน /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 ที่มีอยู่ในโฟลเดอร์ system/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์ด้วยกฎ neverallow ทั้งหมดที่มีอยู่ ทั้งสำหรับโดเมน SELinux ของ AOSP และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
  • ควรเก็บนโยบาย SELinux เริ่มต้นไว้ตามที่ระบุไว้ในโฟลเดอร์ system/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 ผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ผู้ใช้ไม่จําเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับการแจ้งเตือนเท่านั้น

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9.11.1 และรองรับการเข้ารหัสพื้นที่เก็บข้อมูลด้วยประสิทธิภาพการเข้ารหัส Advanced Encryption Standard (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 เพื่อส่งสัญญาณให้แอปพลิเคชันที่รับรู้การบูตโดยตรงทราบว่าตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) พร้อมใช้งานสำหรับผู้ใช้

9.9.2. การเข้ารหัสตามไฟล์

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

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

  • ควรทำให้แอปที่จำเป็นที่โหลดไว้ล่วงหน้า (เช่น การปลุก โทรศัพท์ Messenger) รับรู้การบูตโดยตรง

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

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

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

การติดตั้งใช้งานอุปกรณ์ที่มีประสิทธิภาพการเข้ารหัส Advanced Encryption Standard (AES) มากกว่า 50 MiB/วินาที

  • [C-2-1] ต้องรองรับการบูตที่ยืนยันแล้วสำหรับความสมบูรณ์ของอุปกรณ์

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

9.11. คีย์และข้อมูลเข้าสู่ระบบ

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

  • [C-0-1] ต้องอนุญาตให้นำเข้าคีย์ได้มากกว่า 8,192 รายการเป็นอย่างน้อย
  • [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องจำกัดอัตราการพยายามและต้องมีอัลกอริทึมการลดจำนวนครั้งแบบทวีคูณ หากพยายามเกิน 150 ครั้ง ระยะเวลารอต้องนานอย่างน้อย 24 ชั่วโมงต่อการพยายาม 1 ครั้ง
  • ควรไม่จํากัดจํานวนคีย์ที่สร้างได้

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

  • [C-1-1] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ด้วยฮาร์ดแวร์ที่มีความปลอดภัย
  • [C-1-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันการแฮชของกลุ่ม MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Keystore ของ Android รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่ก็มีโซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามและปลอดภัยเป็นทางเลือกอื่น
  • [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อตรวจสอบสิทธิ์สำเร็จเท่านั้น โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
  • [C-1-4] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงนามในการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คุณต้องแชร์คีย์การรับรองที่ใช้ลงนามในอุปกรณ์จํานวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์ดังกล่าวเป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต 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-3-1] เอนโทรปีของอินพุตที่มีความยาวน้อยที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์ที่มีอยู่ (PIN,รูปแบบ, รหัสผ่าน) ที่ติดตั้งใช้งานและระบุไว้ใน AOSP
  • [C-3-4] ต้องปิดใช้เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_SOMETHING

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

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

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

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

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

  • [C-6-1] ต้องแสดงผล false สำหรับทั้งเมธอด KeyguardManager.isKeyguardSecure() และ KeyguardManager.isDeviceSecure()
  • [C-6-2] ต้องปิดใช้เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ด้วยค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-6-3] ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่กำหนดโดย DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-6-4] ต้องไม่ตรวจสอบสิทธิ์การเข้าถึงคีย์สโตร์หากแอปพลิเคชันเรียกใช้ KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true))

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

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

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

9.13. โหมดการบูตอย่างปลอดภัย

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

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

  • [SR] ขอแนะนําอย่างยิ่งให้ใช้โหมดการบูตที่ปลอดภัย

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

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

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

  • [C-0-1] ต้องเรียกใช้เคสที่เกี่ยวข้องทั้งหมดในโปรแกรมตรวจสอบ CTS อย่างถูกต้อง

CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ

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

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

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

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

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

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

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

  • การดาวน์โหลด "ผ่านอากาศ (OTA)" ที่มีการอัปเดตแบบออฟไลน์ผ่านการรีบูต
  • การอัปเดตแบบ "ใช้การเชื่อมต่ออินเทอร์เน็ตมือถือจากมือถือ" ผ่าน USB จาก PC โฮสต์

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

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

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