นิยามความเข้ากันได้ของ Android 9

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

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

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

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

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

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

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

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

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

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

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

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

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

ระบบจะกำหนดรหัสข้อกำหนดสำหรับข้อกำหนดที่ต้องมี

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

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

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

1.1.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 แบบถือเท่านั้น

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

2.2.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

  • [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] ควรมีการรองรับ Bluetooth และ Bluetooth LE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์พกพา Android ประกาศการรองรับ FEATURE_BLUETOOTH หรือ FEATURE_WIFI จะมีลักษณะดังนี้

  • [3.16/H-1-1] ต้องรองรับฟีเจอร์การจับคู่อุปกรณ์เสริม

2.2.4. ประสิทธิภาพและพลังงาน

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

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

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

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

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

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

  • [8.4/H-0-1] ต้องระบุโปรไฟล์การใช้พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้กระแสไฟฟ้าสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการใช้แบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์ Android Open Source Project
  • [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

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

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

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.3.4.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีพร้อมโปรไฟล์ Baseline
  • [5.3.4.4/T-1-2] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Main Profile
  • [5.3.4.4/T-1-3] HD 1080p ที่ 60 เฟรมต่อวินาทีที่มี High Profile Level 4.2

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

  • [5.3.5.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีที่มี Main Profile Level 4.1

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์โทรทัศน์รองรับการถอดรหัส UHD และรองรับจอแสดงผลภายนอก อุปกรณ์ดังกล่าวจะ

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

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

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

2.3.3. ซอฟต์แวร์

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

  • [3/T-0-1] ต้องประกาศฟีเจอร์ android.software.leanback และ android.hardware.type.television
  • [3.4.1/T-0-1] ต้องมีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

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

  • [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 Engine ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
  • [3.11/T-1-1] ต้องรองรับการติดตั้งโปรแกรมอ่านออกเสียงข้อความ (TTS) ของบุคคลที่สาม

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

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

2.3.4. ประสิทธิภาพและพลังงาน

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

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

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

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

  • [8.4/T-0-1] ต้องระบุโปรไฟล์การใช้พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้พลังงานปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการใช้แบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์ Android Open Source Project
  • [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] ต้องประกาศฟีเจอร์ android.hardware.type.watch
  • [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH

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

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

ดูการติดตั้งใช้งานอุปกรณ์ที่ประกาศฟีเจอร์แฟล็ก 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.4.4. ประสิทธิภาพและพลังงาน

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

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

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

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

2.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] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดฟังก์ชันย้อนกลับค้างไว้ (KEYCODE_BACK) ไปยังแอปพลิเคชันที่อยู่เบื้องหน้า

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

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

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

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

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

  • [7.3.11/A-0-1] ต้องระบุเกียร์ปัจจุบันเป็น SENSOR_TYPE_GEAR

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

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

  • เซ็นเซอร์แสงแวดล้อมพื้นฐานอาจเหมือนกับโฟโตมิเตอร์

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

  • [7.3.11.5/A-0-1] ต้องระบุสถานะเบรกมือตามที่กำหนดโดย SENSOR_TYPE_PARKING_BRAKE

  • [7.4.3/A-0-1] ต้องรองรับบลูทูธและควรจะรองรับบลูทูธ LE

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

  • [7.4.3/A-SR] ขอแนะนำอย่างยิ่งให้รองรับ Message Access Profile (MAP)

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

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

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

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

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

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

  • [7.6.1/A-SR] ขอแนะนำอย่างยิ่งให้ลดค่าใช้จ่าย I/O ในการดำเนินการที่ทำในพื้นที่เก็บข้อมูลภายนอก เช่น โดยใช้ SDCardFS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

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

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

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

  • [3.13/A-SR] ขอแนะนำอย่างยิ่งให้รวมคอมโพเนนต์ UI การตั้งค่าด่วน

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

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

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

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

2.5.4. ประสิทธิภาพและพลังงาน

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

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

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

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

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

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

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

  • [9.9.2/A-1-1] ต้องรองรับการเข้ารหัสต่อคีย์การตรวจสอบสิทธิ์ที่เฉพาะเจาะจงของผู้ใช้ การเข้ารหัสตามไฟล์ (FBE) เป็นวิธีหนึ่งในการดำเนินการดังกล่าว

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

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

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

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

  • โดยปกติจะใช้โดยถือด้วยมือทั้ง 2 ข้าง
  • ไม่มีการกำหนดค่าแบบฝาพับหรือแบบแปลงสภาพ
  • การติดตั้งใช้งานแป้นพิมพ์จริงที่ใช้กับอุปกรณ์ต้องเชื่อมต่อด้วยการเชื่อมต่อมาตรฐาน
  • มีแหล่งพลังงานที่ช่วยให้เคลื่อนที่ได้ เช่น แบตเตอรี่
  • มีขนาดหน้าจอตามแนวทแยงมุมจริงในช่วง 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/แท็บ] อาจใช้ Android Open Accessory (AOA) API

โหมดความจริงเสมือน (ส่วนที่ 7.9.1)

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

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

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 และทำงานอย่างสมเหตุสมผล แม้ว่าจะละเว้นฟีเจอร์ฮาร์ดแวร์บางอย่างที่ Android มี API ไว้ให้ก็ตาม ดูข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ได้ที่ส่วนที่ 7

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

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

3.1.1. ส่วนขยาย Android

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

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

3.1.2. ไลบรารี Android

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

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

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

3.2 ความเข้ากันได้ของ 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 ที่กำลังดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้ต้องมีค่าสตริงค่าใดค่าหนึ่งที่กำหนดไว้ใน 9
VERSION.SDK เวอร์ชันของระบบ Android ที่กำลังดำเนินการอยู่ในขณะนี้ในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 9 ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 9_INT
VERSION.SDK_INT เวอร์ชันของระบบ Android ที่กำลังดำเนินการอยู่ในขณะนี้ในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 9 ช่องนี้ต้องมีค่าจำนวนเต็มเป็น 9_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_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ลายนิ้วมือ สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นรูปแบบที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้

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

เช่น

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

ลายนิ้วมือต้องไม่มีอักขระช่องว่าง หากฟิลด์อื่นๆ ที่รวมอยู่ในเทมเพลตด้านบนมีอักขระช่องว่าง คุณต้องแทนที่อักขระเหล่านั้นในลายนิ้วมือของบิลด์ด้วยอักขระอื่น เช่น อักขระขีดล่าง ("_") ค่าของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตได้

ฮาร์ดแวร์ ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) ควรเป็นรูปแบบที่มนุษย์อ่านได้ ค่าของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
โฮสต์ สตริงที่ระบุโฮสต์ที่ใช้สร้างบิลด์ได้อย่างไม่ซ้ำกันในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่ใช่ค่า Null หรือสตริงว่าง ("")
รหัส ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ฟิลด์นี้อาจเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกแยะระหว่างบิลด์ซอฟต์แวร์ ค่าของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+$"
ผู้ผลิต ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าฟิลด์นี้ต้องไม่ใช่ค่า Null หรือสตริงว่าง ("") และต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
MODEL ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่ออุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ชื่อนี้ควรเป็นชื่อเดียวกันกับที่ใช้ในการทำการตลาดและขายอุปกรณ์แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าฟิลด์นี้ต้องไม่ใช่ค่า Null หรือสตริงว่าง ("") และต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์ ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อในการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ (SKU) ที่เฉพาะเจาะจงซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นข้อความที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีไว้เพื่อให้ผู้ใช้ปลายทางดู ค่าของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ซีเรียล ต้องแสดงผลเป็น "UNKNOWN"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์ ฟิลด์นี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการลงนามในแพลตฟอร์ม 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._-,]+$"
getSerial() ต้อง (เป็นหรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของฟิลด์นี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$"

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

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

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

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

    • นาฬิกาตั้งโต๊ะ
    • เบราว์เซอร์
    • ปฏิทิน
    • รายชื่อติดต่อ
    • แกลเลอรี
    • GlobalSearch
    • Launcher
    • เพลง
    • การตั้งค่า
3.2.3.2. การแก้ปัญหา Intent

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

  • [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่แนบสิทธิ์พิเศษกับการใช้รูปแบบ 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 โดยทำตามขั้นตอนการตรวจสอบที่กำหนดไว้ในข้อกำหนดของ Digital Asset Links ตามที่ Package Manager ได้นำไปใช้ในโปรเจ็กต์ Android Open Source ต้นทาง
  • [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. เนมสเปซของความตั้งใจ
  • [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. Broadcast Intents

แอปพลิเคชันของบุคคลที่สามอาศัยแพลตฟอร์มในการออกอากาศ 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] ต้องปฏิบัติตามเจตนาของ android.settings.HOME_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 ความเข้ากันได้ของ Native API

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

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

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

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

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

  • [C-0-1] ต้องใช้ได้กับ ABI ที่กำหนดอย่างน้อย 1 รายการ และใช้ร่วมกับ Android NDK ได้
  • [C-0-2] ต้องรองรับการเรียกใช้โค้ดในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกใช้โค้ดเนทีฟ โดยใช้ความหมายของ Java Native Interface (JNI) มาตรฐาน
  • [C-0-3] ต้องเข้ากันได้กับแหล่งที่มา (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) กับไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
  • [C-0-5] ต้องรายงาน 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 ที่ไม่ได้อยู่ในรายการ

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

    • [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 (ไลบรารีคณิตศาสตร์)
    • libneuralnetworks.so (Neural Networks API)
    • 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 รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม

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

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

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

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

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

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

  • [C-2-2] ต้องทำให้การดำเนินการต่อไปนี้พร้อมใช้งานเสมอ แม้ในกรณีที่ใช้ ABI ในสถาปัตยกรรม ARMv8 ไม่ว่าจะผ่านการรองรับ CPU ดั้งเดิมหรือผ่านการจำลองซอฟต์แวร์

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

  • [C-2-3] ต้องรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)

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

3.4.1. ความเข้ากันได้ของ WebView

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

  • [C-1-1] ต้องรายงาน android.software.webview
  • [C-1-2] ต้องใช้บิลด์โปรเจ็กต์ Chromium จากโปรเจ็กต์ Android Open Source ต้นทางในสาขา Android 9 สำหรับการติดตั้งใช้งาน API android.webkit.WebView

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

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

    • ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ android.os.Build.VERSION.RELEASE
    • สตริง $(MODEL) อาจว่างเปล่า แต่หากไม่ว่างเปล่า สตริงดังกล่าวต้องมีค่าเดียวกับ android.os.Build.MODEL
    • อาจละเว้น "Build/$(BUILD)" ได้ แต่หากมี สตริง $(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] ต้องรองรับ Web Storage 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

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

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

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

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

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

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

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

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

3.6 เนมสเปซของ API

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) ทั้งหมด รวมถึงข้อกำหนดและความหมายของ Dalvik bytecode

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

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

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

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

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

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

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

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

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

3.8.2. วิดเจ็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์รายงานฟีเจอร์แฟล็ก android.hardware.ram.normal จะมีลักษณะดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.5. การแจ้งเตือนและข้อความป๊อปอัป

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

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

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

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องรายงานค่าสถานะฟีเจอร์แพลตฟอร์ม android.software.live_wallpaper

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11. โปรแกรมรักษาหน้าจอ (เดิมชื่อดรีม)

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

3.8.12. ตำแหน่ง

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์มี IME จะต้องมีคุณสมบัติดังนี้

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

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

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

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

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

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

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

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

3.8.15. คัตเอาท์ดิสเพลย์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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. กรอบงานอินพุตทีวี

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

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

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

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

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

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

  • [C-1-1] ต้องอนุญาตให้ผู้ใช้เพิ่มหรือนำไทล์ที่ได้รับผ่าน API ของ quicksettings ออกจากแอปของบุคคลที่สาม
  • [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 และให้ความสามารถแก่ผู้ใช้สำหรับลำดับชั้นของ MediaBrowser
  • [C-1-5] ต้องพิจารณาการแตะสองครั้งที่ KEYCODE_HEADSETHOOK หรือ KEYCODE_MEDIA_PLAY_PAUSE เป็น KEYCODE_MEDIA_NEXT สำหรับ MediaSession.Callback#onMediaButtonEvent

3.15. Instant Apps

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

  • [C-0-1] Instant App ต้องได้รับสิทธิ์ที่มี android:protectionLevel ตั้งค่าเป็น "instant" เท่านั้น
  • [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 Apps ในอุปกรณ์ เว้นแต่ Instant App จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งอย่างชัดเจน

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

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

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

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

3.17. แอปที่ใช้ทรัพยากรมาก

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

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

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

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

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

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

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

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

  • [C-0-2] ต้องรองรับการยืนยันไฟล์ ".apk" โดยใช้ APK Signature Scheme v3 , 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() ได้ หากการติดตั้งใช้งานอุปกรณ์ไม่ต้องการอนุญาตให้ผู้ใช้มีตัวเลือกนี้ อย่างไรก็ตาม แม้ในกรณีดังกล่าว ผู้เผยแพร่โฆษณาก็ควรระบุให้ผู้ใช้ทราบว่าเหตุใดจึงไม่มีตัวเลือกดังกล่าว

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

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

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

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

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

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

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

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

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

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-11] xHE-AAC (โปรไฟล์ HE AAC แบบขยายของ ISO/IEC 23003-3 ซึ่งรวมถึงโปรไฟล์พื้นฐานของ USAC และโปรไฟล์การควบคุมช่วงไดนามิกของ ISO/IEC 23003-4)
  • [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 เพื่อกำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ DRC ของ AAC เปิดตัวใน 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

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

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

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

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

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

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

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
โปรไฟล์ AAC ของ MPEG-4
(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
USAC รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz MPEG-4 (.mp4, .m4a)
AMR-NB 4.75 ถึง 12.2 kbps ที่ 8 kHz 3GPP (.3gp)
AMR-WB 9 อัตราตั้งแต่ 6.60 kbit/s ถึง 23.85 kbit/s ที่สุ่มตัวอย่าง @ 16 kHz
FLAC โมโน/สเตอริโอ (ไม่มีหลายช่องทาง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz ในอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากตัวอย่างที่ลดลงจาก 48 เป็น 44.1 kHz ไม่มีตัวกรองแบบผ่านต่ำ) แนะนำ 16 บิต ไม่มีการใช้ดีเทอร์สำหรับ 24 บิต FLAC (.flac) เท่านั้น
MP3 อัตราบิตคงที่ (CBR) หรืออัตราบิตแปรผัน (VBR) แบบโมโน/สเตอริโอ 8-320 Kbps 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] ดิบ
  • [C-0-7] HEIF (HEIC)

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG ฐาน + โปรเกรสซีฟ JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
แบบข้อมูลดิบ ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ HEIF (.heif), HEIC (.heic)

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

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

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

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

  • [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-frame) ในช่วงเวลา 2 ช่วง
  • ไม่ควรสูงกว่าบิตเรตประมาณ 100% ในช่วงเวลา 1 วินาที

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

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

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

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

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

  • ควรสนับสนุนบิตเรตที่กำหนดค่าแบบไดนามิกได้สำหรับตัวเข้ารหัสที่รองรับ

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

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

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

  • [C-1-1] ต้องรองรับ Baseline Profile ระดับ 30 และระดับ 45

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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. การบันทึกเสียงดิบ

หากการใช้งานอุปกรณ์ประกาศ 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 เดซิเบลจาก -18 เดซิเบลถึง +12 เดซิเบลเทียบกับ 90 เดซิเบล SPL ที่ไมโครโฟน
  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีค่าความเพี้ยนฮาร์มอนิกทั้งหมด (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 บิต, 8 บิต, Float
    • ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องสัญญาณที่ถูกต้องซึ่งมีช่องสัญญาณสูงสุด 8 ช่อง
    • อัตราการสุ่มตัวอย่าง (ในหน่วย Hz):
      • 8000, 11025, 16000, 22050, 32000, 44100, 48000 ในการกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
      • 96000 ในระบบเสียงโมโนและสเตอริโอ

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

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

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

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

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

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

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

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

  • เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM กับเวลาที่เสียงที่เกี่ยวข้องจะแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
  • เวลาในการตอบสนองของเอาต์พุตที่ไม่ได้แคช เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดเครื่องก่อนที่จะมีคำขอ
  • เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมถัดไปหลังจากที่อุปกรณ์เล่นเสียง
  • เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต กับช่วงเวลาที่แอปพลิเคชันอ่านเฟรมที่สอดคล้องกันของข้อมูลที่เข้ารหัส PCM
  • อินพุตสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
  • เวลาในการตอบสนองต่อการป้อนข้อมูลครั้งแรก ผลรวมของเวลาที่สูญเสียไปในการป้อนข้อมูลและเวลาในการตอบสนองต่อการป้อนข้อมูลสำหรับเฟรมแรก เมื่อระบบป้อนข้อมูลเสียงไม่ได้ใช้งานและปิดเครื่องก่อนคำขอ
  • เวลาในการตอบสนองต่อการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมถัดไปขณะที่อุปกรณ์บันทึกเสียง
  • ความกระตุกของเอาต์พุตเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตเย็นแยกกัน
  • ความกระตุกของอินพุตเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบเย็นแยกกัน
  • เวลาในการรับส่งข้อมูลแบบต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่องบวกกับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องบวกกับระยะเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและมีเวลาลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
  • OpenSL ES PCM buffer queue API ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
  • AAudio Native Audio API ชุด API ของ AAudio ภายใน Android NDK
  • การประทับเวลา คู่ประกอบด้วยตำแหน่งเฟรมที่สัมพันธ์กันภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าหรือออกจากไปป์ไลน์การประมวลผลเสียงในอุปกรณ์ปลายทางที่เชื่อมโยง ดูAudioTimestamp ด้วย

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

  • [C-SR] เวลาในการตอบสนองของเอาต์พุตเย็นไม่เกิน 100 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองของเอาต์พุตต่อเนื่องไม่เกิน 45 มิลลิวินาที
  • [C-SR] ลดความกระวนกระวายของเอาต์พุตที่ไม่ได้แคช
  • [C-SR] การประทับเวลาเอาต์พุตที่ส่งคืนโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำ +/- 1 มิลลิวินาที

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

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

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

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

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

  • [C-SR] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองของอินพุตอย่างต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
  • [C-SR] ลดความกระวนกระวายของอินพุตเย็น
  • [C-SR] จำกัดข้อผิดพลาดในไทม์สแตมป์อินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลเป็น +/- 1 มิลลิวินาที

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมด ซึ่งมีการเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI โดยการรับส่งดังกล่าวต้องมีลักษณะดังนี้

  • [C-1-2] ต้องรองรับการนำส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ 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 โดยใช้ทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ API AAudio native audio
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อรักษาประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและภาระงานของ CPU เปลี่ยนแปลง ควรทดสอบโดยใช้คอมมิต SimpleSynth 1bd6391 แอป SimpleSynth ต้องทำงานโดยใช้พารามิเตอร์ด้านล่างและไม่มีการประมวลผลไม่ทันหลังจากผ่านไป 10 นาที
    • รอบการทำงาน: 200,000
    • โหลดตัวแปร: เปิด (การตั้งค่านี้จะสลับระหว่าง 100% กับ 10% ของค่ารอบการทำงานทุกๆ 2 วินาที และออกแบบมาเพื่อทดสอบลักษณะการทำงานของตัวควบคุม CPU)
    • โหลดที่เสถียร: ปิด
  • ควรลดความไม่ถูกต้องและการเลื่อนของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน
  • ควรลดการเลื่อนของนาฬิกาเสียงที่สัมพันธ์กับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่
  • ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
  • ควรลดความกระวนกระวายในเวลาเริ่มต้นของโปรแกรมเรียกกลับการเสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากจะส่งผลต่อเปอร์เซ็นต์ที่ใช้ได้ของแบนด์วิดท์ CPU เต็มรูปแบบโดยโปรแกรมเรียกกลับ
  • ควรไม่มีการขาดหายของเสียง (เอาต์พุต) หรือการล้นของเสียง (อินพุต) ภายใต้การใช้งานปกติที่เวลาในการตอบสนองที่รายงาน
  • ควรไม่มีความแตกต่างของเวลาในการตอบสนองระหว่างช่อง
  • ควรลดเวลาในการตอบสนองของ MIDI โดยเฉลี่ยในการรับส่งทั้งหมด
  • ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI ภายใต้ภาระงาน (ความกระตุก) ในการรับส่งข้อมูลทั้งหมด
  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งทั้งหมด
  • ควรลดสัญญาณรบกวนของสัญญาณเสียงในทรานสดิวเซอร์ในอุปกรณ์ ซึ่งรวมถึงช่วงเวลาหลังจาก Cold Start ทันที
  • ควรให้ความแตกต่างของสัญญาณนาฬิกาเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของอุปกรณ์ปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตแจ็คเสียง
  • ควรจัดการการเรียกกลับเมื่อบัฟเฟอร์เสียงของอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้องในเธรดเดียวกันเสร็จสมบูรณ์เมื่อทั้ง 2 อย่างทำงานอยู่ และเข้าสู่การเรียกกลับของเอาต์พุตทันทีหลังจากกลับจากการเรียกกลับของอินพุต หรือหากไม่สามารถจัดการการเรียกกลับในเธรดเดียวกัน ให้ป้อนการเรียกกลับเอาต์พุตหลังจากป้อนการเรียกกลับอินพุตไม่นาน เพื่อให้แอปพลิเคชันมีเวลาที่สอดคล้องกันของฝั่งอินพุตและเอาต์พุต
  • ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง
  • ควรลดเวลาในการตอบสนองต่อการสัมผัส
  • ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระงาน (ความกระตุก)
  • ควรมีเวลาในการตอบสนองจากอินพุตการแตะไปยังเอาต์พุตเสียงไม่เกิน 40 มิลลิวินาที

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Android Debug Bridge (adb)

    • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง dumpsys และ cmd stats
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบของอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับcmd statsคำสั่ง Shell และคลาส System API ของ StatsManager
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] ต้องมี daemon adb ฝั่งอุปกรณ์ที่ไม่ได้ใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
    • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่ได้รับการตรวจสอบสิทธิ์ที่รู้จัก

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

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

  • บริการตรวจสอบข้อบกพร่องของ Dalvik (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

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

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

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

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

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

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

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 สำหรับลายนิ้วมือของบิลด์เดียวกัน

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

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

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

หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้มีการกำหนดดังนี้

  • ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้าม 2 มุมของส่วนที่สว่างของจอแสดงผล
  • จุดต่อนิ้ว (DPI) จํานวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งเชิงเส้น 1 นิ้ว เมื่อระบุค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วง
  • สัดส่วนภาพ อัตราส่วนของพิกเซลด้านที่ยาวกว่าต่อด้านที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะมีอัตราส่วนเป็น 854/480 = 1.779 หรือประมาณ "16:9"
  • ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นหน้าจอ 160 dpi โดยคำนวณเป็นพิกเซล = dp * (ความหนาแน่น/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

  • อาจมีจอแสดงผลที่มีมุมโค้งมน

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

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

    • 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 เท่า
  • เพื่อรับประกันความสามารถในการใช้งานที่ดีและขนาดแบบอักษรที่สอดคล้องกัน เราขอแนะนำให้ระบุการปรับขนาดตัวเลือกโฆษณา Display เนทีฟต่อไปนี้ (พร้อมทั้งปฏิบัติตามขีดจำกัดที่ระบุไว้ข้างต้น)
  • เล็ก: 0.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15x
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

7.1.2. เมตริกการแสดงผล

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

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

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

  • [C-2-1] ต้องรายงานค่าที่สมเหตุสมผลสําหรับเมตริกการแสดงผลทั้งหมดที่กําหนดไว้ใน API ของ android.util.DisplayMetrics สําหรับ 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] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
  • MAY อาจเลือกการวางแนวเป็นแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

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

  • [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API ดั้งเดิม
  • [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API ดั้งเดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุว่ารองรับ

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

  • [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุและอธิบายไว้ในเอกสารประกอบ Android SDK
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

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

  • [C-2-1] ต้องรายงานผ่าน API ที่จัดการของ OpenGL ES และ API ดั้งเดิมของส่วนขยาย OpenGL ES อื่นๆ ที่ได้ติดตั้งใช้งาน และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
  • [C-2-2] ต้องรองรับส่วนขยาย EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage และ EGL_ANDROID_recordable
  • [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] ต้องระบุการรองรับผ่านฟีเจอร์แฟล็ก android.hardware.opengles.aep

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

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

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

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

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

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

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

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

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วยฟีเจอร์แฟล็ก android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องแสดง VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ API ดั้งเดิมของ Vulkan vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องใช้ API ของ Vulkan 1.0 อย่างเต็มรูปแบบสำหรับแต่ละ VkPhysicalDevice ที่ระบุ
  • [C-1-4] ต้องแสดงรายการเลเยอร์ที่อยู่ในไลบรารีเนทีฟซึ่งมีชื่อเป็น libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน Vulkan Native API vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
  • [C-1-5] ต้องไม่แจงนับเลเยอร์ที่จัดทำโดยไลบรารีภายนอกแพ็กเกจแอปพลิเคชัน หรือจัดหาวิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีandroid:debuggableแอตทริบิวต์ที่ตั้งค่าเป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน Vulkan Native API และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
  • [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present

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

  • [C-2-1] ต้องไม่ประกาศฟีเจอร์แฟล็ก Vulkan ใดๆ (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
  • [C-2-2] ต้องไม่แจงนับ VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()

หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.1 อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องแสดงการรองรับSYNC_FDประเภทภายนอกของ Semaphore และประเภทแฮนเดิล
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer
7.1.4.3 RenderScript
  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

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

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

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

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

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

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

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

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสีแล้ว
  • [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตสีครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตสีซึ่งมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ xyY ของ CIE 1931
  • [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
  • [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 และ EGL_KHR_gl_colorspace_display_p3
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ GL_EXT_sRGB

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องใช้บริการระบบและ API ของ DisplayManager ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

7.2. อุปกรณ์อินพุต

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

7.2.1. แป้นพิมพ์

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

  • [C-1-1] ต้องประกาศฟีเจอร์แฟล็ก android.software.input_methods
  • [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
  • [C-1-3] ต้องมีแป้นพิมพ์ซอฟต์แวร์ที่ติดตั้งไว้ล่วงหน้า

การใช้งานอุปกรณ์: * [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 ปุ่ม) * ควรมีการติดตั้งใช้งานแป้นพิมพ์เสมือนเพิ่มเติม * อาจมีแป้นพิมพ์ฮาร์ดแวร์

7.2.2. การไปยังส่วนต่างๆ โดยไม่ต้องสัมผัส

Android รองรับ D-pad, แทร็กบอล และวงล้อเป็นกลไกสำหรับการไปยังส่วนต่างๆ แบบไม่สัมผัส

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

หากการใช้งานอุปกรณ์ไม่มีการนำทางแบบไม่สัมผัส อุปกรณ์จะ

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

7.2.3. ปุ่มนำทาง

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

  • [C-0-1] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้เปิดแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่มี <intent-filter> ตั้งค่าด้วย ACTION=MAIN และ CATEGORY=LAUNCHER หรือ CATEGORY=LEANBACK_LAUNCHER สำหรับการติดตั้งใช้งานอุปกรณ์โทรทัศน์ ฟังก์ชันหน้าแรกควรเป็นกลไกสำหรับความสามารถของผู้ใช้รายนี้
  • ควรมีปุ่มสำหรับฟังก์ชันล่าสุดและย้อนกลับ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ควรประกาศการรองรับฟีเจอร์แฟล็ก 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. การแมปปุ่ม

หากการใช้งานอุปกรณ์ประกาศฟีเจอร์แฟล็ก android.hardware.gamepad จะมีข้อกำหนดดังนี้

  • [C-1-1] ต้องมีตัวควบคุมแบบฝังหรือจัดส่งพร้อมตัวควบคุมแยกต่างหากในกล่อง ซึ่งจะช่วยให้ป้อนเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่างได้
  • [C-1-2] ต้องสามารถแมปเหตุการณ์ HID กับค่าคงที่ view.InputEvent ของ Android ที่เกี่ยวข้องตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งาน Android ต้นทางรวมถึงการติดตั้งใช้งานสำหรับเกมคอนโทรลเลอร์ที่เป็นไปตามข้อกำหนดนี้
ปุ่ม การใช้งาน HID2 ปุ่ม Android
A1 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)
ปุ่ม R1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกที่ก้านซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกที่ก้านขวา1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
หน้าแรก1 0x0c 0x0223 KEYCODE_HOME (3)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 ต้องประกาศการใช้งาน HID ข้างต้นภายใน CA ของ Game pad (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 Open Source เกี่ยวกับเซ็นเซอร์

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

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

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

  • [C-1-1] ต้องรายงานการวัดเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีของเซ็นเซอร์ที่สตรีมด้วยเวลาในการตอบสนองขั้นต่ำที่จำเป็น 5 มิลลิวินาที + 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 ม./วินาที^ โดยควรคำนวณค่าเบี่ยงเบนมาตรฐานต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 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 มิลลิวัตต์และ 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่ในสภาวะไดนามิกหรือสภาวะคงที่

หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 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 และรายงานความสามารถไปยังแอปพลิเคชันผ่านฟีเจอร์แฟล็ก android.hardware.location.gps อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งที่อัตราอย่างน้อย 1 Hz เมื่อมีการขอผ่าน LocationManager#requestLocationUpdate
  • [C-1-2] ต้องระบุตำแหน่งในสภาพท้องฟ้าเปิด (สัญญาณแรง, การรบกวนจากหลายเส้นทางน้อยมาก, HDOP < 2) ได้ภายใน 10 วินาที (เวลาในการหาตำแหน่งครั้งแรกอย่างรวดเร็ว) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วในการรับส่งข้อมูลตั้งแต่ 0.5 Mbps ขึ้นไป โดยปกติแล้ว ข้อกำหนดนี้จะทำได้โดยใช้เทคนิค GPS/GNSS ที่มีการช่วยหรือคาดการณ์ในรูปแบบใดรูปแบบหนึ่งเพื่อลดเวลาในการล็อก GPS/GNSS (ข้อมูลการช่วยประกอบด้วยเวลาอ้างอิง สถานที่อ้างอิง และตารางวงโคจร/นาฬิกาของดาวเทียม)
    • [C-1-6] หลังจากทำการคำนวณตำแหน่งดังกล่าวแล้ว การใช้งานอุปกรณ์จะต้องกำหนดตำแหน่งในที่โล่งภายใน 5 วินาที เมื่อมีการรีสตาร์ทคำขอตำแหน่ง นานถึง 1 ชั่วโมงหลังจากคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอครั้งต่อๆ ไปโดยไม่มีการเชื่อมต่อข้อมูล และ/หรือหลังจากเปิดปิดเครื่อง

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

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

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

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

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

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

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

  • [C-4-1] ต้องส่งเอาต์พุต GPS/GNSS ตามปกติไปยังแอปพลิเคชันต่อไปในระหว่างการโทรเซสชันฉุกเฉินที่เครือข่ายเริ่มต้น (MS-Based)
  • [C-4-2] ต้องรายงานตำแหน่งและการวัดผลไปยัง API ของ GNSS Location Provider

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

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

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

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

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และควรใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย
  • [C-1-3] ต้องวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
  • [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป และควรมีความละเอียด 16 บิตขึ้นไป
  • [C-1-5] ต้องมีการชดเชยอุณหภูมิ
  • [C-1-6] ต้องได้รับการปรับเทียบและชดเชยขณะใช้งาน และรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
  • [C-1-7] ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) ความแปรปรวนจะแตกต่างกันไปตามอัตราการสุ่มตัวอย่างได้ แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโรที่อัตราการสุ่มตัวอย่าง 1 Hz ความแปรปรวนดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android เครื่องใหม่และเครื่องที่ใช้อยู่เพื่อติดตั้งใช้งานSENSOR_TYPE_GYROSCOPE_UNCALIBRATEDเซ็นเซอร์
  • [SR] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการปรับเทียบควรน้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • ควรรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 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
  • ควรมีความแม่นยำสัมบูรณ์ 1 hPa
  • ควรมีความแม่นยำสัมพัทธ์ 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] ต้องระบุความสามารถผ่านฟีเจอร์แฟล็ก android.hardware.sensor.hifi_sensors

หากการใช้งานอุปกรณ์ประกาศ android.hardware.sensor.hifi_sensors จะมีข้อกำหนดดังนี้

  • [C-2-1] ต้องมีเซ็นเซอร์ TYPE_ACCELEROMETER ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง -8g ถึง +8g เป็นอย่างน้อย ควรมีช่วงการวัดระหว่าง -16g ถึง +16g เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
    • ต้องมีความถี่ในการวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 400 μg/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 3,000 รายการ
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 3 มิลลิวัตต์
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนแบบไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีการเดินแบบสุ่มของการเร่งความเร็วที่น้อยกว่า 30 μg √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
    • ควรมีเส้นแนวโน้มที่เหมาะสมที่สุดซึ่งมีความไม่เป็นเชิงเส้น ≤ 0.5% และการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.03%/C°
    • ควรมีความไวต่อแกนขวางน้อยกว่า 2.5 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

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

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดอย่างน้อยระหว่าง -1000 ถึง +1000 dps
    • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
    • ต้องมีความถี่ในการวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.014°/s/√Hz
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนแบบไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีการเดินแบบสุ่มของอัตราที่น้อยกว่า 0.001 °/s √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
    • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.02% / °C
    • ควรมีเส้นที่เหมาะสมที่สุดซึ่งมีความไม่เชิงเส้น ≤ 0.2%
    • ควรมีความหนาแน่นของสัญญาณรบกวน ≤ 0.007 °/s/√Hz
    • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่
    • ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 0.1°/s/g
    • ควรมีความไวต่อแกนขวางน้อยกว่า 4.0 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

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

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
    • ต้องมีความถี่ในการวัดอย่างน้อย 5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 50 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.5 uT

  • [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ TYPE_GEOMAGNETIC_FIELD และนอกจากนี้

    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 600 รายการ
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีสเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานอยู่ที่ 50 Hz ขึ้นไป

  • [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่ในการวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 10 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 2 Pa/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 300 รายการ
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 2 มิลลิวัตต์
  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR ซึ่งมีลักษณะดังนี้
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 300 รายการ
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 4 มิลลิวัตต์
  • [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 100 รายการ
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 4 มิลลิวัตต์
  • [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-13] การประทับเวลาของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่ง ไจโรสโคป และเครื่องวัดสนามแม่เหล็กต้องอยู่ภายใน 2.5 มิลลิวินาทีของกันและกัน การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่งและไจโรสโคปควรอยู่ภายใน 0.25 มิลลิวินาทีของกันและกัน
  • [C-2-14] ต้องมีการประทับเวลาของเหตุการณ์เซ็นเซอร์ไจโรสโคปบนฐานเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดภายใน 1 มิลลิวินาที
  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงข้างต้นไปยังแอปพลิเคชัน
  • [C-2-16] ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 2.0 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่เมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมีจะต้องมีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์จากเซ็นเซอร์

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

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

  • [C-3-1] ต้องประกาศการรองรับประเภทช่องทางโดยตรงและระดับอัตราการรายงานโดยตรงอย่างถูกต้องผ่าน API isDirectChannelTypeSupported และ getHighestDirectReportRateLevel
  • [C-3-2] ต้องรองรับประเภทช่องทางเซ็นเซอร์โดยตรงอย่างน้อย 1 ประเภทจาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศว่ารองรับช่องทางเซ็นเซอร์โดยตรง
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (รูปแบบที่ไม่ใช่การปลุก) ประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. เซ็นเซอร์ไบโอเมตริก

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

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

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

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

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

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

  • [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดไม่เกิน 0.002%
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการสวมรอยและการแอบอ้างเป็นบุคคลอื่นไม่เกิน 7%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจมีความปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่เดายาก และระบุความเสี่ยงของการเปิดใช้โหมดนี้อย่างชัดเจน หากอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสูงกว่า 7%
  • [C-1-3] ต้องจำกัดอัตราการพยายามเป็นเวลาอย่างน้อย 30 วินาทีหลังจากพยายามยืนยันไบโอเมตริกไม่สำเร็จ 5 ครั้ง โดยการพยายามไม่สำเร็จคือการพยายามที่มีคุณภาพการจับภาพเพียงพอ (ACQUIRED_GOOD) ซึ่งไม่ตรงกับไบโอเมตริกที่ลงทะเบียนไว้
  • [C-1-4] ต้องมีการใช้งานที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ และทำการจับคู่ไบโอเมตริกใน TEE หรือในชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
  • [C-1-5] ต้องเข้ารหัสข้อมูลที่ระบุตัวบุคคลได้ทั้งหมดและตรวจสอบสิทธิ์ด้วยการเข้ารหัสลับเพื่อให้ไม่สามารถรับ อ่าน หรือเปลี่ยนแปลงข้อมูลภายนอก TEE หรือชิปที่มีแชแนลที่ปลอดภัยไปยัง TEE ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์ Android Open Source Project
  • [C-1-6] ต้องป้องกันการเพิ่มไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อนด้วยการให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์ที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบของอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การติดตั้งใช้งาน Android Open Source Project มีกลไกในเฟรมเวิร์กเพื่อดำเนินการดังกล่าว
  • [C-1-7] ต้องไม่อนุญาตให้แอปพลิเคชันของบุคคลที่สามแยกความแตกต่างระหว่างการลงทะเบียนไบโอเมตริก
  • [C-1-8] ต้องปฏิบัติตามการแจ้งว่าไม่เหมาะสมของแต่ละบุคคลสำหรับข้อมูลไบโอเมตริกนั้น (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS)
  • [C-1-9] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ทั้งหมดของผู้ใช้ออกอย่างสมบูรณ์เมื่อมีการนำบัญชีของผู้ใช้ออก (รวมถึงการรีเซ็ตเป็นค่าเริ่มต้น)
  • [C-1-10] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลนั้นได้หรือข้อมูลใดๆ ที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ที่ไม่ได้เข้ารหัสไปยัง Application Processor นอกบริบทของ TEE
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที ซึ่งวัดจากเวลาที่ตรวจพบไบโอเมตริกจนกว่าจะปลดล็อกหน้าจอสำหรับไบโอเมตริกแต่ละรายการที่ลงทะเบียนไว้

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. สถานะการขับรถ

ข้อกำหนดนี้เลิกใช้งานแล้ว

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

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

7.3.11.5. เบรกมือ

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วนที่ 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] ต้องประกาศandroid.hardware.telephonyฟีเจอร์แฟล็กและฟีเจอร์แฟล็กย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องรองรับ API สำหรับเทคโนโลยีนั้นอย่างเต็มรูปแบบ

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

  • [C-2-1] ต้องใช้ API ทั้งหมดเป็น no-op
7.4.1.1. ความเข้ากันได้ของการบล็อกหมายเลข

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

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

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

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

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

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

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

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

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

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

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

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

  • [C-2-1] ต้องมีส่วนควบคุมสำหรับผู้ใช้เพื่อเปิด/ปิดใช้การอ่านค่าผ่านเมธอด WifiManager.isScanAlwaysAvailable API
7.4.2.1. Wi-Fi Direct

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

  • ควรรองรับ Wi-Fi Direct (Wi-Fi แบบเพียร์ทูเพียร์)

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Direct อุปกรณ์จะต้องมีคุณสมบัติดังนี้

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

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

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

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

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

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

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

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

7.4.2.4. Passpoint ของ Wi-Fi

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

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 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] การใช้งาน API ที่เกี่ยวข้องกับ Passpoint WifiManager ต้องส่ง UnsupportedOperationException
7.4.2.5. ตำแหน่งของ Wi-Fi (ระยะเวลารับส่งข้อมูลของ Wi-Fi - RTT)

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

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

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

7.4.3. บลูทูธ

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

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

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

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

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

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

Android รองรับบลูทูธและบลูทูธพลังงานต่ำ

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

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

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

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

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

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

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

  • [C-4-1] ต้องมีส่วนที่ผู้ใช้สามารถเปิด/ปิดใช้ค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable() ได้

7.4.4. Near Field Communication

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

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

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

  • [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
  • ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ได้
  • [C-1-2] ต้องทำหน้าที่เป็นเครื่องอ่าน/เขียน NFC 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] ต้องสามารถส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบเพียร์ทูเพียร์ต่อไปนี้

  • [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 Intent เพื่อแสดงการตั้งค่าการแชร์ผ่าน NFC
  • [C-1-8] ต้องติดตั้งใช้งานเซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP ต้องได้รับการประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้นของ SNEP
  • [C-1-9] ต้องใช้ไคลเอ็นต์ SNEP และพยายามส่ง NDEF แบบ P2P ขาออกไปยังเซิร์ฟเวอร์ 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" และ "Bluetooth Secure Simple Pairing Using NFC เวอร์ชัน 1.0" จาก NFC Forum การติดตั้งใช้งานดังกล่าวต้องติดตั้งใช้งานบริการ LLCP การส่งต่อที่มีชื่อบริการ "urn:nfc:sn:handover" เพื่อแลกเปลี่ยนคำขอ/บันทึกการเลือกการส่งต่อผ่าน NFC และต้องใช้โปรไฟล์การส่งออบเจ็กต์ผ่านบลูทูธสำหรับการโอนข้อมูลผ่านบลูทูธจริง ด้วยเหตุผลด้านระบบเดิม (เพื่อให้ยังคงใช้งานร่วมกับอุปกรณ์ Android 4.1 ได้) การติดตั้งใช้งานควรยังคงยอมรับคำขอ SNEP GET สำหรับการแลกเปลี่ยนคำขอส่งต่อ/เลือกบันทึกผ่าน NFC อย่างไรก็ตาม การติดตั้งใช้งานเองไม่ควรส่งคำขอ SNEP GET เพื่อดำเนินการส่งต่อการเชื่อมต่อ
  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC
  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานโดยที่หน้าจอเปิดอยู่และหน้าจอล็อกปลดล็อกแล้ว
  • ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์ Thinfilm NFC Barcode ได้

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

Android รองรับโหมด Host Card Emulation (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 APIs ตามที่กำหนดไว้ใน 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, Ethernet และ Bluetooth PAN
  • ควรมีการรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายแบบมีสาย (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
  • อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
  • [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API ดั้งเดิม เช่น ซ็อกเก็ต AF_INET6
  • [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
  • ต้องตรวจสอบว่าการสื่อสาร IPv6 มีความน่าเชื่อถือเท่ากับ IPv4 เช่น
    • [C-0-4] ต้องรักษาการเชื่อมต่อ IPv6 ในโหมดพัก
    • [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่รองรับ IPv6 ซึ่งใช้ช่วงเวลาที่ RA มีผลอย่างน้อย 180 วินาที
  • [C-0-6] ต้องให้การเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายแก่แอปพลิเคชันของบุคคลที่สามเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ เกิดขึ้นในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort) และ API ของ NDK เช่น getsockname() หรือ IPV6_PKTINFO จะต้องแสดงที่อยู่ IP และพอร์ตที่ใช้จริงในการส่งและรับแพ็กเก็ตในเครือข่าย

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

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

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

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

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

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

  • ควรรองรับการทำงานของ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ Dual-stack) บนเครือข่ายมือถือ

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

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

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 แต่สามารถใช้เป็น no-op ได้

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

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

  • [C-1-1] ต้องแสดงรายการเครื่องอ่าน Secure Element ที่พร้อมใช้งานเมื่อเรียกใช้เมธอด android.se.omapi.SEService.getReaders()

7.5 กล้อง

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

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

7.5.1. กล้องหลัง

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

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

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

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

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

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

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

7.5.2. กล้องหน้า

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.5.4. ลักษณะการทำงานของ Camera API

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

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

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

การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ 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 ข้อมูลในไบต์[] ที่ส่งไปยัง onPreviewFrame() กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
  • [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับตัวอย่างกล้องทั้งกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (ตัวเข้ารหัสวิดีโอฮาร์ดแวร์และกล้องอาจใช้รูปแบบพิกเซลดั้งเดิมใดก็ได้ แต่การติดตั้งใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
  • [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่โฆษณาความสามารถ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities
  • [C-0-5] ต้องยังคงใช้ 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 และรายงานฟีเจอร์แฟล็กของเฟรมเวิร์กที่เหมาะสม
  • [C-0-8] ต้องประกาศความสามารถของกล้องแต่ละตัวของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศฟีเจอร์แฟล็กที่เหมาะสมด้วย ต้องกำหนดฟีเจอร์แฟล็กหากอุปกรณ์กล้องที่เชื่อมต่อรองรับฟีเจอร์ดังกล่าว
  • [C-0-9] ต้องออกอากาศCamera.ACTION_NEW_PICTUREเจตนาทุกครั้งที่กล้องถ่ายภาพใหม่และมีการเพิ่มรายการรูปภาพลงในร้านค้าสื่อ
  • [C-0-10] ต้องออกอากาศCamera.ACTION_NEW_VIDEOเจตนาทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการรูปภาพลงในร้านค้าสื่อ
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องตรรกะที่แสดงความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA สำหรับอุปกรณ์ที่มีกล้องหลายตัวที่หันไปในทิศทางเดียวกัน ซึ่งประกอบด้วยกล้องจริงแต่ละตัวที่หันไปในทิศทางนั้น ตราบใดที่เฟรมเวิร์กรองรับประเภทกล้องจริงและ CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL สำหรับกล้องจริงเป็น LIMITED, FULL หรือ LEVEL_3

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

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

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

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

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

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

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

7.6.2. Shared Storage ของแอปพลิเคชัน

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

  • [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 เส้นทางการจัดเก็บอย่างโปร่งใสผ่านบริการ Media Scanner ของ Android และ android.provider.MediaStore
  • อาจใช้ที่เก็บข้อมูลแบบกลุ่มผ่าน USB แต่ควรใช้โปรโตคอลการโอนสื่อเพื่อให้เป็นไปตามข้อกำหนดนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.8.3. เกือบอัลตราซาวด์

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

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

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

หาก 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 kHz ถึง 20 kHz สำหรับโทนเสียง 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง"

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

7.9. Virtual Reality

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

7.9.1. โหมด Virtual Reality

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

7.9.2. โหมด Virtual Reality - ประสิทธิภาพสูง

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

  • [C-1-1] ต้องมี Physical Core อย่างน้อย 2 คอร์
  • [C-1-2] ต้องประกาศฟีเจอร์ android.hardware.vr.high_performance
  • [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
  • [C-1-4] ต้องรองรับ OpenGL ES 3.2
  • [C-1-5] ต้องรองรับ android.hardware.vulkan.level 0
  • ควรสนับสนุน android.hardware.vulkan.level 1 ขึ้นไป
  • [C-1-6] ต้องใช้ EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่พร้อมใช้งาน
  • [C-1-8] ต้องใช้ GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ GL_EXT_external_buffer, GL_EXT_EGL_image_array และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image และแสดงในรายการส่วนขยาย Vulkan ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงคิวตระกูล Vulkan อย่างน้อย 1 รายการที่ flags มีทั้ง VK_QUEUE_GRAPHICS_BIT และ VK_QUEUE_COMPUTE_BIT และ queueCount มีค่าอย่างน้อย 2
  • [C-1-7] GPU และจอแสดงผลต้องซิงค์การเข้าถึงบัฟเฟอร์หน้าส่วนกลางได้เพื่อให้การแสดงผลเนื้อหา VR แบบสลับตาที่ 60fps ด้วยบริบทการแสดงผล 2 รายการแสดงโดยไม่มีอาร์ติแฟกต์การฉีกขาดที่มองเห็นได้
  • [C-1-9] ต้องรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องรองรับ AHardwareBuffer โดยใช้ชุดค่าผสมใดก็ได้ของแฟล็กการใช้งาน AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT สำหรับรูปแบบต่อไปนี้อย่างน้อย AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีเลเยอร์มากกว่า 1 เลเยอร์ รวมถึงการตั้งค่าสถานะและรูปแบบที่ระบุไว้ใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps โดยบีบอัดให้มีค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 fps-10 Mbps หรือ 2 อินสแตนซ์ของ 1920 x 1080 ที่ 60 fps-20 Mbps)
  • [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องถอดรหัสอย่างน้อย 1920 x 1080 ที่ 30 FPS ที่บีบอัดเป็นค่าเฉลี่ย 10 Mbps ได้ และควรถอดรหัส 3840 x 2160 ที่ 30 FPS-20 Mbps ได้ (เทียบเท่ากับ 1920 x 1080 ที่ 30 FPS-5 Mbps จำนวน 4 รายการ)
  • [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
  • [C-1-14] ต้องมีหน้าจอฝังตัว และความละเอียดต้องเป็นอย่างน้อย 1920 x 1080
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีความละเอียดในการแสดงผลอย่างน้อย 2560 x 1440
  • [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
  • [C-1-17] จอแสดงผลต้องรองรับโหมดความคงทนต่ำที่มีความคงทน ≤ 5 มิลลิวินาที โดยความคงทนจะกำหนดเป็นระยะเวลาที่พิกเซลเปล่งแสง
  • [C-1-18] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวข้อมูลของบลูทูธ LE มาตรา 7.4.3
  • [C-1-19] ต้องรองรับและรายงานประเภทแชแนลโดยตรงอย่างถูกต้องสำหรับเซ็นเซอร์เริ่มต้นทุกประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับประเภทช่องทางโดยตรง TYPE_HARDWARE_BUFFER สำหรับประเภทช่องทางโดยตรงทั้งหมดที่ระบุไว้ข้างต้น
  • [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors ตามที่ระบุไว้ในส่วนที่ 7.3.9
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับandroid.hardware.sensor.hifi_sensors
  • [C-1-22] ต้องมีเวลาในการตอบสนองตั้งแต่การเคลื่อนไหวจนถึงการแสดงผลภาพไม่เกิน 28 มิลลิวินาที
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองตั้งแต่การเคลื่อนไหวจนถึงโฟตอนแบบต้นทางถึงปลายทางไม่เกิน 20 มิลลิวินาที
  • [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวกับความสว่างของพิกเซลสีขาวในสถานะคงที่ อย่างน้อย 85%
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
  • อาจจัดสรรคอร์หลักเฉพาะให้กับแอปพลิเคชันที่ใช้งานอยู่ และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนคอร์ CPU ที่จัดสรรเฉพาะให้กับแอปพลิเคชันที่ใช้งานอยู่ด้านบนสุด

หากรองรับคอร์แบบเฉพาะ คอร์จะมีลักษณะดังนี้

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

8. ประสิทธิภาพและพลังงาน

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

8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้

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

8.2 ประสิทธิภาพการเข้าถึง I/O ของไฟล์

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

  • ประสิทธิภาพการเขียนตามลำดับ วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการเขียนแบบสุ่ม วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
  • ประสิทธิภาพการอ่านตามลำดับ วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการอ่านแบบสุ่ม วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB

8.3 โหมดประหยัดพลังงาน

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

  • [C-1-1] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับอัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุก และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน App Standby และโหมดพัก
  • [C-1-2] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการจำกัดงาน การปลุก และเครือข่ายสำหรับแอปในแต่ละ Bucket สำหรับ App Standby
  • [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวนกลุ่มการพักแอปที่ใช้สำหรับการพักแอป
  • [C-1-4] ต้องใช้ที่เก็บพักแอปและโหมดพักเครื่องตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] ต้องส่งคืน true สำหรับ PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายของแอปและโหมดประหยัดพลังงาน Doze

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

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

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

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

  • [C-2-1] ต้องเป็นไปตาม C-1-1 ด้านบน หรือต้องเข้าสู่สถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่ต้องการทรัพยากรของระบบ (เช่น หน้าจอ, CPU)

    ในทางกลับกัน จะต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรของระบบ ตามที่อธิบายไว้ใน SDK นี้

    ตัวอย่างเช่น ในขณะที่แอปพลิเคชันของบุคคลที่สามขอให้เปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือให้ CPU ทำงานต่อไปผ่าน PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่เข้าสู่สถานะ S3 เว้นแต่ว่าผู้ใช้ได้ดำเนินการอย่างชัดเจนเพื่อให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน เมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามใช้ผ่าน JobScheduler หรือเมื่อมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ผู้ใช้จะทำให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน นี่เป็นเพียงตัวอย่างโดยสังเขปเท่านั้น และ AOSP ใช้สัญญาณปลุกที่ครอบคลุมซึ่งทริกเกอร์การปลุกจากสถานะนี้

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

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

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

  • [SR] ขอแนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้กระแสไฟฟ้าสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการระบายแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์ Android Open Source Project
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ชั่วโมง (mAh)
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านuid_cputimeการติดตั้งใช้งานโมดูลเคอร์เนล
  • [SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การใช้พลังงานนี้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats แก่นักพัฒนาแอป
  • ควรระบุแหล่งที่มาของคอมโพเนนต์ฮาร์ดแวร์เองหากระบุแหล่งที่มาของการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชันไม่ได้

8.5 ประสิทธิภาพที่สม่ำเสมอ

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

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

  • [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด API ของ PowerManager.isSustainedPerformanceModeSupported()

  • ควรสนับสนุนโหมดประสิทธิภาพที่ยั่งยืน

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

  • [C-1-1] ต้องให้แอปพลิเคชันที่อยู่เบื้องหน้าสูงสุดมีระดับประสิทธิภาพที่สม่ำเสมอเป็นเวลาอย่างน้อย 30 นาที เมื่อแอปขอ
  • [C-1-2] ต้องปฏิบัติตาม API ของ Window.setSustainedPerformanceMode() และ API อื่นๆ ที่เกี่ยวข้อง

หากการติดตั้งใช้งานอุปกรณ์มีคอร์ CPU 2 คอร์ขึ้นไป อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรมีคอร์หลักแบบพิเศษอย่างน้อย 1 คอร์ที่แอปพลิเคชันที่อยู่ด้านหน้าสุดสามารถจองได้

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

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

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

9. ความเข้ากันได้ของโมเดลความปลอดภัย

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

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

  • [C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงานใดๆ โดยเฉพาะอย่างยิ่ง อุปกรณ์ที่รองรับต้องรองรับกลไกการรักษาความปลอดภัยที่อธิบายไว้ในส่วนย่อยต่อไปนี้

9.1. สิทธิ์

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

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

  • อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_FLAG_PRIVILEGED ต้องให้เฉพาะแอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบและภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอปเท่านั้น การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและปฏิบัติตามสิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่ได้รับสิทธิ์

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะขอสิทธิ์รันไทม์

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

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ และต้องมีอินเทอร์เฟซเพื่อให้ผู้ใช้จัดการสิทธิ์รันไทม์ได้
  • [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงแบบเดียวเท่านั้น
  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งไว้ล่วงหน้า เว้นแต่ในกรณีต่อไปนี้
    • คุณขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้ข้อมูล
    • สิทธิ์รันไทม์จะเชื่อมโยงกับรูปแบบ Intent ที่ตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
  • [C-0-6] ต้องให้android.permission.RECOVER_KEYSTOREเฉพาะแอปของระบบที่ลงทะเบียน Recovery Agent ที่ปลอดภัยอย่างเหมาะสม ตัวแทนการกู้คืนที่ปลอดภัยอย่างเหมาะสมคือตัวแทนซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยพร้อมการป้องกันที่เทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีแบบ Brute Force ในปัจจัยความรู้ของหน้าจอล็อก

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

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

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

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

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

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

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

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

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

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

9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม

Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ 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 Open Source Project ต้นทางเป็นไปตามข้อกำหนดนี้โดยการเปิดใช้ seccomp-BPF ที่มีการซิงโครไนซ์กลุ่มเธรด (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่าเคอร์เนลของ source.android.com

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

  • [C-0-7] ต้องใช้การป้องกันบัฟเฟอร์สแต็กเคอร์เนลล้น (เช่น CONFIG_CC_STACKPROTECTOR_STRONG)
  • [C-0-8] ต้องใช้การป้องกันหน่วยความจำเคอร์เนลอย่างเข้มงวดซึ่งโค้ดที่เรียกใช้งานได้เป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวเรียกใช้งานและเขียนไม่ได้ และข้อมูลที่เขียนได้เรียกใช้งานไม่ได้ (เช่น CONFIG_DEBUG_RODATA หรือ CONFIG_STRICT_KERNEL_RWX)
  • [C-0-9] ต้องใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และพื้นที่เคอร์เนล (เช่น CONFIG_HARDENED_USERCOPY) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
  • [C-0-10] ต้องไม่ดำเนินการกับหน่วยความจำในพื้นที่ผู้ใช้เมื่อดำเนินการในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
  • [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำในพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึง usercopy ปกติ (เช่น PAN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
  • [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลในอุปกรณ์ทั้งหมดที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป (เช่น CONFIG_PAGE_TABLE_ISOLATION หรือ `CONFIG_UNMAP_KERNEL_AT_EL0)
  • [SR] ขอแนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนลซึ่งเขียนเฉพาะในระหว่างการเริ่มต้นระบบ โดยทำเครื่องหมายเป็นแบบอ่านอย่างเดียวหลังจากการเริ่มต้นระบบ (เช่น __ro_after_init)
  • [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 และโดเมนเฉพาะของอุปกรณ์/ผู้ให้บริการ
  • [C-1-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไปในแซนด์บ็อกซ์ SELinux ต่อแอปพลิเคชัน โดยมีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
  • ควรเก็บรักษานโยบาย SELinux เริ่มต้นที่อยู่ในโฟลเดอร์ system/sepolicy ของ Android Open Source Project ต้นทาง และเพิ่มนโยบายนี้เพิ่มเติมสำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น

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

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

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

Android มีฟีเจอร์การป้องกันหลายชั้นซึ่งเป็นส่วนสำคัญของความปลอดภัยของอุปกรณ์

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

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

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

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

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

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

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

Android จะจัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ System API ของ IncidentManager

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

  • [C-0-2] ต้องมีเฉพาะฟิลด์ที่ทำเครื่องหมายด้วย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม เหตุการณ์เหล่านั้นอาจใช้ตัวระบุ Atom อื่นในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

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

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

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

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

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

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

9.8.3. การเชื่อมต่อ

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

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

9.8.4. การจราจรของข้อมูลในเครือข่าย

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

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

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

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

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

  • [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนที่จะเปิดใช้กลไกดังกล่าว เว้นแต่ว่า Device Policy Controller จะเปิดใช้ VPN นั้นผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับการแจ้งเตือนเท่านั้น

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

  • [C-3-1] ต้องปิดใช้ความสามารถนี้สำหรับแอปที่ไม่รองรับบริการ VPN ที่เปิดตลอดเวลาในไฟล์ AndroidManifest.xml โดยตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

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

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

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

หากประสิทธิภาพการเข้ารหัส AES อยู่ที่หรือต่ำกว่า 50 MiB/วินาที การติดตั้งใช้งานอุปกรณ์อาจใช้ Adiantum-XChaCha12-AES แทนรูปแบบของ AES ที่ระบุไว้ในข้อใดข้อหนึ่งต่อไปนี้ AES-256-XTS ในส่วนที่ 9.9.2 [C-1-5], AES-256 ในโหมด CBS-CTS ในส่วนที่ 9.9.2 [C-1-6], AES ในส่วนที่ 9.9.3 [C-1-1], AES ในส่วนที่ 9.9.3 [C-1-3]

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

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

9.9.1. Direct Boot

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

  • [C-0-1] ต้องใช้ API Direct Boot mode แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

  • [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 AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวคีย์ 256 บิต ซึ่งทำงานในโหมด XTS ความยาวเต็มของคีย์ XTS คือ 512 บิต

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องประกาศฟีเจอร์แฟล็กของแพลตฟอร์ม android.software.verified_boot
  • [C-1-2] ต้องทำการยืนยันในทุกๆ ลำดับการบูต
  • [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรากฐานของความน่าเชื่อถือ และดำเนินการไปจนถึงพาร์ติชันของระบบ
  • [C-1-4] ต้องใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความสมบูรณ์และความถูกต้องของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
  • [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่แข็งแกร่งเท่ากับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
  • [C-1-6] ต้องไม่อนุญาตให้บูตจนเสร็จเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้จะยินยอมให้ลองบูตต่อไป ในกรณีนี้ต้องไม่ใช้ข้อมูลจากบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้ยืนยัน
  • [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้จะปลดล็อก Bootloader อย่างชัดเจน
  • [C-SR] หากมีชิปแยกหลายตัวในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์รูปภาพเฉพาะ) ขอแนะนำอย่างยิ่งให้กระบวนการบูตของชิปแต่ละตัวตรวจสอบทุกขั้นตอนเมื่อบูต
  • [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลง: สำหรับจัดเก็บว่ามีการปลดล็อก Bootloader หรือไม่ พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงหมายความว่าโปรแกรมโหลดระบบปฏิบัติการจะตรวจหาได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ที่ล็อกเป็นโหมด Bootloader ที่ปลดล็อก
  • [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันการบูตและระบบ) และใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชัน OS ขั้นต่ำที่อนุญาต
  • [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดด้วยห่วงโซ่ความน่าเชื่อถือที่เริ่มต้นใน /system ซึ่งได้รับการปกป้องโดยการบูตที่ยืนยันแล้ว
  • [C-SR] ขอแนะนำอย่างยิ่งให้ตรวจสอบอาร์ติแฟกต์ที่เรียกใช้งานได้ซึ่งแอปที่มีสิทธิ์พิเศษโหลดจากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์แล้ว) ก่อนที่จะเรียกใช้งาน หรือขอแนะนำอย่างยิ่งไม่ให้เรียกใช้งานเลย
  • ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์แบบถาวร (เช่น โมเด็ม กล้อง) และควรใช้ที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันขั้นต่ำที่อนุญาต

หากมีการเปิดตัวการติดตั้งใช้งานอุปกรณ์โดยไม่รองรับ C-1-8 ถึง C-1-10 ใน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

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

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

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

  • [C-3-1] ต้องรายงาน true สำหรับ ConfirmationPrompt.isSupported() API
  • [C-3-2] ต้องตรวจสอบว่าฮาร์ดแวร์ที่ปลอดภัยควบคุมการแสดงผลได้อย่างเต็มที่ในลักษณะที่ระบบปฏิบัติการ Android ไม่สามารถบล็อกได้โดยที่ฮาร์ดแวร์ที่ปลอดภัยไม่ตรวจพบ
  • [C-3-3] ต้องตรวจสอบว่าฮาร์ดแวร์ที่ปลอดภัยควบคุมหน้าจอสัมผัสได้อย่างเต็มที่

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

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

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

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

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

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

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

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

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าวิธีการตรวจสอบสิทธิ์หลักเป็นเพียงหนึ่งในวิธีการต่อไปนี้
    • PIN ที่เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
    • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 พอดี

โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

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

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

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

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

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วน 7.3.10.2
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายฟีเจอร์ keguard โดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() พร้อมกับค่าสถานะไบโอเมตริกที่เกี่ยวข้อง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)
  • [C-4-4] ต้องขอให้ผู้ใช้ดำเนินการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 72 ชั่วโมงหรือน้อยกว่า
  • [C-4-5] ต้องมีอัตราการยอมรับที่ผิดพลาดเท่ากับหรือมากกว่าที่กำหนดไว้สำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วน 7.3.10 หรือต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและการแอบอ้างที่เท่ากับหรือสูงกว่าข้อกำหนดสำหรับเซ็นเซอร์ลายนิ้วมือตามที่อธิบายไว้ในส่วนที่ 7.3.10
  • [C-4-6] ต้องมีไปป์ไลน์การประมวลผลที่ปลอดภัยเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกสามารถแทรกข้อมูลโดยตรงเพื่อรับรองความถูกต้องอย่างไม่ถูกต้องในฐานะผู้ใช้
  • [C-4-7] ต้องจับคู่กับการดำเนินการยืนยันอย่างชัดเจน (เช่น การกดปุ่ม) เพื่ออนุญาตให้เข้าถึงคีย์ในที่เก็บคีย์ หากแอปพลิเคชันตั้งค่า true สำหรับ KeyGenParameterSpec.Built.setUserAuthenticationRequired() และข้อมูลไบโอเมตริกเป็นแบบพาสซีฟ (เช่น ใบหน้าหรือม่านตาที่ไม่มีสัญญาณความตั้งใจอย่างชัดเจน)
  • [C-SR] ขอแนะนำอย่างยิ่งให้รักษาความปลอดภัยของการดำเนินการยืนยันสำหรับไบโอเมตริกแบบพาสซีฟเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกปลอมแปลงได้ ตัวอย่างเช่น การดำเนินการยืนยันที่อิงตามปุ่มจริงจะกำหนดเส้นทางผ่านพินอินพุต/เอาต์พุตอเนกประสงค์ (GPIO) แบบอินพุตเท่านั้นขององค์ประกอบที่ปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นใดนอกเหนือจากการกดปุ่มจริง

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

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

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

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

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

  • [C-7-1] ต้องมีข้อบ่งชี้ที่ชัดเจนในเมนูการตั้งค่าและบนหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ออกไปหรือเมื่อเอเจนต์ที่เชื่อถือได้ปลดล็อกอุปกรณ์ได้ เช่น AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงคำอธิบายข้อความสำหรับการตั้งค่า "ล็อกอัตโนมัติ" และ "ปุ่มเปิด/ปิดล็อกทันที" ในเมนูการตั้งค่า และไอคอนที่แยกแยะได้บนหน้าจอล็อก
  • [C-7-2] ต้องปฏิบัติตามและใช้ API ของตัวแทนที่เชื่อถือได้ทั้งหมดในคลาส DevicePolicyManager อย่างครบถ้วน เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
  • [C-7-3] ต้องไม่ใช้ฟังก์ชัน TrustAgentService.addEscrowToken() อย่างเต็มรูปแบบในอุปกรณ์ที่ใช้เป็นอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) แต่สามารถใช้ฟังก์ชันนี้อย่างเต็มรูปแบบในการติดตั้งใช้งานอุปกรณ์ที่มักใช้ร่วมกัน (เช่น อุปกรณ์ Android Television หรือ Automotive)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่จัดเก็บคีย์การเข้ารหัสในอุปกรณ์เดียวกันกับที่ใช้คีย์ เช่น อนุญาตให้คีย์ที่จัดเก็บไว้ในโทรศัพท์ปลดล็อกบัญชีผู้ใช้ในทีวีได้
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบถึงผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นการฝากไว้เพื่อถอดรหัสที่จัดเก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง
  • [C-7-8] ผู้ใช้ต้องได้รับแจ้งให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำอย่างใดอย่างหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น
  • [C-7-9] ระบบต้องแจ้งให้ผู้ใช้ยืนยันตัวตนด้วยวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) วิธีใดวิธีหนึ่งหลังจากช่วงหมดเวลาเนื่องจากไม่มีการใช้งาน 4 ชั่วโมง ระบบจะรีเซ็ตระยะหมดเวลาเนื่องจากไม่มีการใช้งานหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ
  • [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อก Keyguard ให้ทำดังนี้

  • [C-8-1] ต้องปิดใช้เมธอดใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-8-2] พวกเขาต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ตั้งค่าโดย DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-8-3] ต้องไม่ตรวจสอบสิทธิ์การเข้าถึงที่เก็บคีย์เมื่อแอปพลิเคชันตั้งค่า true สำหรับ KeyGenParameterSpec.Builder.setUserAuthenticationRequired())

9.11.2. StrongBox

ระบบที่เก็บคีย์ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ รวมถึงสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่อธิบายไว้ข้างต้น

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ StrongBox

หากการติดตั้งใช้งานอุปกรณ์รองรับ StrongBox จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE

  • [C-1-2] ต้องมีฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะซึ่งใช้เพื่อสำรองข้อมูลที่เก็บคีย์และรักษาความปลอดภัยในการตรวจสอบสิทธิ์ผู้ใช้

  • [C-1-3] ต้องมี CPU แยกต่างหากที่ไม่แชร์แคช, DRAM, ตัวประมวลผลร่วม หรือทรัพยากรหลักอื่นๆ กับตัวประมวลผลแอปพลิเคชัน (AP)

  • [C-1-4] ต้องตรวจสอบว่าอุปกรณ์ต่อพ่วงที่แชร์กับ AP จะไม่สามารถเปลี่ยนแปลงการประมวลผล StrongBox ในทางใดทางหนึ่ง หรือรับข้อมูลใดๆ จาก StrongBox AP อาจปิดใช้หรือบล็อกการเข้าถึง StrongBox

  • [C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำที่สมเหตุสมผล (+-10%) ซึ่งไม่ได้รับผลกระทบจากการดัดแปลงโดย AP

  • [C-1-6] ต้องมีเครื่องสร้างตัวเลขสุ่มจริงที่สร้างเอาต์พุตที่กระจายอย่างสม่ำเสมอและคาดเดาไม่ได้

  • [C-1-7] ต้องมีความต้านทานการดัดแปลง ซึ่งรวมถึงความต้านทานต่อการเจาะทางกายภาพและการเกิดข้อบกพร่อง

  • [C-1-8] ต้องมีความต้านทานช่องทางด้านข้าง ซึ่งรวมถึงความต้านทานต่อการรั่วไหลของข้อมูลผ่านช่องทางด้านข้างของกำลังไฟฟ้า เวลา การแผ่รังสีแม่เหล็กไฟฟ้า และการแผ่รังสีความร้อน

  • [C-1-9] ต้องมีพื้นที่เก็บข้อมูลที่ปลอดภัยซึ่งรับประกันความลับ ความสมบูรณ์ ความถูกต้อง ความสอดคล้อง และความใหม่ของเนื้อหา ระบบต้องอ่านหรือแก้ไขที่เก็บข้อมูลไม่ได้ เว้นแต่จะได้รับอนุญาตจาก StrongBox API

  • หากต้องการตรวจสอบความสอดคล้องกับ [C-1-3] ถึง [C-1-9] การใช้งานอุปกรณ์ต้องมีลักษณะดังนี้

    • [C-1-10] ต้องมีฮาร์ดแวร์ที่ได้รับการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วมกัน
    • [C-1-11] ต้องมีเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วมกัน
    • [C-SR] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ได้รับการประเมินโดยใช้เป้าหมายด้านความปลอดภัย ระดับการรับประกันการประเมิน (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อป้องกันการโจมตีจากภายใน (IAR) ซึ่งหมายความว่าผู้ที่อยู่ภายในซึ่งมีสิทธิ์เข้าถึงคีย์การลงนามเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox รั่วไหลความลับ บายพาสข้อกำหนดด้านความปลอดภัยในการทำงาน หรือเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการติดตั้งใช้งาน IAR คือการอนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านของผู้ใช้หลักผ่าน IAuthSecret HAL

9.12. การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องจัดหากลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลทั้งหมดที่ผู้ใช้สร้างขึ้น กล่าวคือ ข้อมูลทั้งหมด ยกเว้นรายการต่อไปนี้
    • อิมเมจระบบ
    • ไฟล์ระบบปฏิบัติการที่อิมเมจระบบต้องการ
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้นจากโรงงาน" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของDevicePolicyManager.wipeData() API ของผู้ใช้หลักเรียกใช้
  • อาจมีตัวเลือกการล้างข้อมูลอย่างรวดเร็วที่ดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการเปิดเครื่องที่ปลอดภัย

Android มีโหมดการรีบูตอย่างปลอดภัย ซึ่งอนุญาตให้ผู้ใช้รีบูตเข้าสู่โหมดที่อนุญาตให้เฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่ทำงานได้ และปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการบูตอย่างปลอดภัย" ซึ่งช่วยให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การติดตั้งใช้งานอุปกรณ์มีดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้ใช้โหมดการเปิดเครื่องที่ปลอดภัย

หากการติดตั้งใช้งานอุปกรณ์ใช้โหมดการเริ่มต้นระบบที่ปลอดภัย อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยในลักษณะที่แอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ไม่สามารถขัดขวางได้ เว้นแต่ว่าแอปของบุคคลที่สามจะเป็นตัวควบคุมนโยบายอุปกรณ์และได้ตั้งค่าสถานะ UserManager.DISALLOW_SAFE_BOOT เป็นจริง

  • [C-1-2] ต้องให้ความสามารถแก่ผู้ใช้ในการถอนการติดตั้งแอปของบุคคลที่สามในโหมดปลอดภัย

  • ควรมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดการเริ่มต้นระบบแบบปลอดภัยจากเมนูการเริ่มต้นระบบโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเริ่มต้นระบบปกติ

9.14. การแยกระบบยานยนต์

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายยานพาหนะ เช่น CAN Bus

การแลกเปลี่ยนข้อมูลสามารถรักษาความปลอดภัยได้โดยการใช้ฟีเจอร์ความปลอดภัยที่อยู่ใต้เลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายหรือไม่ตั้งใจกับระบบย่อยเหล่านี้

9.15. แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ในการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องแสดงแพ็กเกจการสมัครใช้บริการเฉพาะในแอปของผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจดังกล่าวตั้งแต่แรกเท่านั้น
  • [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
  • [C-0-3] ต้องอนุญาตการลบล้าง เช่น SubscriptionManager.setSubscriptionOverrideCongested() จากแอปผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจการสมัครใช้บริการที่ถูกต้องในปัจจุบันเท่านั้น

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าแพ็กเกจการทดสอบซอฟต์แวร์ไม่มีแพ็กเกจใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ทำการเปลี่ยนแปลงจำนวนน้อยที่สุดเท่าที่จะเป็นไปได้ในการติดตั้งใช้งานอ้างอิงและที่ต้องการของ Android ซึ่งพร้อมให้บริการจากโครงการโอเพนซอร์ส Android ซึ่งจะช่วยลดความเสี่ยงในการทำให้เกิดข้อบกพร่องที่สร้างความไม่เข้ากันซึ่งต้องมีการแก้ไขและอาจต้องมีการอัปเดตอุปกรณ์

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android ที่พร้อมใช้งานจากโปรเจ็กต์โอเพนซอร์สของ Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความคลุมเครือใน CTS และสำหรับการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงกลับมาใช้ใหม่

CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง เช่นเดียวกับซอฟต์แวร์อื่นๆ CTS อาจมีข้อบกพร่องในตัว CTS จะมีการกำหนดเวอร์ชันแยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS หลายฉบับสำหรับ Android 9

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องผ่าน CTS เวอร์ชันล่าสุดที่พร้อมใช้งานในขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การติดตั้งใช้งานอ้างอิงในโครงสร้าง Android Open Source ให้มากที่สุด

10.2. โปรแกรมตรวจสอบ CTS

CTS Verifier รวมอยู่ใน Compatibility Test Suite และมีไว้ให้ผู้ปฏิบัติงานที่เป็นมนุษย์เรียกใช้เพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานที่ถูกต้องของกล้องและเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเรียกใช้กรณีที่เกี่ยวข้องทั้งหมดใน CTS Verifier อย่างถูกต้อง

CTS Verifier มีการทดสอบสำหรับฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง อุปกรณ์ต้องเรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง

ระบบอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่เอกสารนิยามความเข้ากันได้นี้ระบุว่าเป็นฟีเจอร์ที่ไม่บังคับ

  • [C-0-2] อุปกรณ์และบิลด์ทุกรายการต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก เราจึงไม่คาดหวังให้ผู้ติดตั้งใช้งานอุปกรณ์เรียกใช้ CTS Verifier อย่างชัดเจนในบิลด์ที่แตกต่างกันเพียงเล็กน้อย กล่าวโดยเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่าน CTS Verifier เฉพาะชุดภาษาที่รวมไว้ การสร้างแบรนด์ ฯลฯ อาจข้ามการทดสอบ CTS Verifier ได้

11. ซอฟต์แวร์ที่อัปเดตได้

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" ซึ่งหมายความว่าอาจต้องรีสตาร์ทอุปกรณ์ คุณใช้วิธีใดก็ได้ตราบใดที่สามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการต่อไปนี้จะตรงตามข้อกำหนดนี้

    • การดาวน์โหลด "ผ่านอากาศ (OTA)" พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต
    • การอัปเดตแบบ "เชื่อมต่อ" ผ่าน USB จาก PC โฮสต์
    • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในที่เก็บข้อมูลแบบถอดได้

  • [C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แอปพลิเคชันแชร์ โปรดทราบว่าซอฟต์แวร์ Android ต้นทางมีกลไกการอัปเดตที่ตรงตามข้อกำหนดนี้

หากการใช้งานอุปกรณ์รวมถึงการรองรับการเชื่อมต่ออินเทอร์เน็ตแบบไม่จำกัด เช่น โปรไฟล์ 802.11 หรือ Bluetooth 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 และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ได้กล่าวถึงได้