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

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

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

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

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

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

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

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

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

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

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

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

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

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

รหัสข้อกำหนดจะกำหนดไว้สำหรับข้อกำหนดที่ต้องปฏิบัติตาม

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

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

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

1.1.3. รหัสข้อกำหนดในส่วนที่ 2

รหัสข้อกำหนดในส่วนที่ 2 จะขึ้นต้นด้วยรหัสส่วนที่เกี่ยวข้องตามด้วยรหัสข้อกำหนดที่อธิบายไว้ข้างต้น

  • รหัสในส่วนที่ 2 ประกอบด้วย รหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. ฮาร์ดแวร์

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

  • [7.1.1.1/H-0-1] ต้องมีจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอที่มีขนาดเส้นทแยงมุมอย่างน้อย 2.5 นิ้ว และจอแสดงผลที่เข้ากันได้กับ Android แต่ละจอต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในเอกสารนี้
  • [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-3] ต้องมีฟังก์ชันหน้าแรกในจอแสดงผลทั้งหมดที่เข้ากันได้กับ Android ซึ่งมีหน้าจอหลัก
  • [7.2.3/H-0-4] ต้องมีฟังก์ชัน "กลับ" ในจอแสดงผลทั้งหมดที่เข้ากันได้กับ Android และฟังก์ชัน "ล่าสุด" ในจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอ
  • [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างไว้ของฟังก์ชัน Back (KEYCODE_BACK) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า ระบบต้องไม่ใช้เหตุการณ์เหล่านี้ และสามารถทริกเกอร์จากภายนอกอุปกรณ์ Android ได้ (เช่น แป้นพิมพ์ฮาร์ดแวร์ภายนอกที่เชื่อมต่อกับอุปกรณ์ Android)
  • [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
  • [7.2.4/H-SR] ขอแนะนำอย่างยิ่งให้เปิดแอปผู้ช่วยที่ผู้ใช้เลือก ซึ่งก็คือแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ ACTION_ASSIST เมื่อกด KEYCODE_MEDIA_PLAY_PAUSE หรือ KEYCODE_HEADSETHOOK ค้างไว้ หากกิจกรรมที่ทำงานอยู่เบื้องหน้าไม่ได้จัดการเหตุการณ์การกดค้างไว้เหล่านั้น
  • [7.3.1/H-SR] ขอแนะนำอย่างยิ่งให้ใส่ตัววัดความเร่งแบบ 3 แกน

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

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

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

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

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

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

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

  • [7.3.8/H] ควรมีเซ็นเซอร์ตรวจหาบุคคลในบริเวณ

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

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

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

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

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

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

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

  • [7.6.1/H-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบคงที่อย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
  • [7.6.1/H-0-2] MUST return “true” for ActivityManager.isLowRamDevice() when there is less than 1GB of memory available to the kernel and userspace.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เมื่อเรียก API AudioManager.getDevices() ขณะที่อุปกรณ์ต่อพ่วง USB เชื่อมต่ออยู่ ระบบจะดำเนินการดังนี้

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

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

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

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

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

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

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

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

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

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

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] โปรไฟล์ MPEG-4 AAC (AAC LC)
  • [5.1/H-0-4] โปรไฟล์ MPEG-4 HE AAC (AAC+)
  • [5.1/H-0-5] AAC ELD (AAC แบบลดเวลาหน่วงที่ปรับปรุงแล้ว)

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

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

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

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

2.2.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

หากฟังก์ชันการไปยังส่วนต่างๆ มีให้ใช้งานเป็นการกระทําบนหน้าจอโดยอิงตามท่าทางสัมผัส ให้ทําดังนี้

  • [7.2.3/H] พื้นที่การจดจำท่าทางสัมผัสสำหรับฟังก์ชัน Home ควรมีความสูงไม่เกิน 32 dp จากด้านล่างของหน้าจอ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.3.1/T-1-1] HD 1080p ที่ 29.97 เฟรมต่อวินาทีด้วยระดับสูงของโปรไฟล์หลัก
  • [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาทีด้วยระดับสูงของโปรไฟล์หลัก โดยต้องแยกเส้นวิดีโอ MPEG-2 แบบอินเตอร์เลซและทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.8.2/W] อาจ แต่ไม่ควรมีเอาต์พุตเสียง

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

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

2.4.3. ซอฟต์แวร์

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

  • [3/W-0-1] MUST declare the feature android.hardware.type.watch.
  • [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 ข้อกำหนดเกี่ยวกับยานยนต์

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

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

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

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

2.5.1. ฮาร์ดแวร์

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

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

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

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

  • [7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างไว้ของฟังก์ชัน Back (KEYCODE_BACK) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า
  • [7.3/A-0-1] ต้องติดตั้งใช้งานและรายงาน GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED และ PARKING_BRAKE_ON
  • [7.3/A-0-2] ค่าของ Flag NIGHT_MODE ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตของเซ็นเซอร์แสงโดยรอบ เซ็นเซอร์แสงแวดล้อมที่เกี่ยวข้องอาจเหมือนกับโฟโตมิเตอร์
  • [7.3/A-0-3] ต้องมีช่องข้อมูลเพิ่มเติมของเซ็นเซอร์ TYPE_SENSOR_PLACEMENT เป็นส่วนหนึ่งของ SensorAdditionalInfo สำหรับเซ็นเซอร์ทุกตัวที่ระบุ
  • [7.3/A-0-1] อาจประมาณตำแหน่งโดยรวม GPS/GNSS เข้ากับเซ็นเซอร์เพิ่มเติม หากตำแหน่งเป็นการประมาณ เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงานประเภทเซ็นเซอร์และ/หรือรหัสพร็อพเพอร์ตี้ยานพาหนะที่เกี่ยวข้อง
  • [7.3/A-0-2] ตำแหน่งที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่จับคู่กับแผนที่

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

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

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

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

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

  • [7.4.3/A-0-2] การติดตั้งใช้งาน Android Automotive จะต้องรองรับโปรไฟล์บลูทูธต่อไปนี้

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

  • [7.4.3/A-SR] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้าถึงข้อความ (MAP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. ฮาร์ดแวร์

ขนาดหน้าจอ

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

ไจโรสโคป

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

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

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

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

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

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

  • [7.7.1/แท็บ] อาจใช้ API ของอุปกรณ์เสริมแบบเปิดของ Android (AOA)

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

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

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

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

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

โปรดดูส่วนที่ [9.11]

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

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

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

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

3. ซอฟต์แวร์

3.1 ความเข้ากันได้ของ 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] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK ซึ่งหมายถึงเมธอดและฟิลด์ในแพ็กเกจภาษา Java ที่อยู่ในเส้นทางการค้นหาบูตใน AOSP และไม่เป็นส่วนหนึ่งของ SDK สาธารณะ ซึ่งรวมถึง API ที่มีคําอธิบายประกอบ @hide แต่ไม่มี @SystemAPI ตามที่อธิบายไว้ในเอกสาร SDK และสมาชิกคลาสแบบส่วนตัวและแบบแพ็กเกจส่วนตัว

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

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

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

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

3.1.1. ส่วนขยาย Android

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

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

3.1.2. ไลบรารี Android

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

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

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

3.2 ความเข้ากันได้แบบ Soft API

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

3.2.1. สิทธิ์

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

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

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

  • [C-0-1] ตารางด้านล่างมีข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนด เพื่อให้ค่าที่สอดคล้องกันและสื่อความหมายในการติดตั้งใช้งานอุปกรณ์
พารามิเตอร์ รายละเอียด
VERSION.RELEASE เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงอย่างใดอย่างหนึ่งที่กําหนดไว้ใน 10
VERSION.SDK เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 10 ช่องนี้ต้องมีค่าจำนวนเต็ม 10_INT
VERSION.SDK_INT เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 10 ช่องนี้ต้องมีค่าจำนวนเต็ม 10_INT
VERSION.INCREMENTAL ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ห้ามนำค่านี้ไปใช้กับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตที่พิมพ์ได้และตรงกับนิพจน์ทั่วไป "^[^ :\/~]+$"
กระดาน ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เฉพาะเจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือการระบุการแก้ไขที่เฉพาะเจาะจงของแผงวงจรที่จ่ายไฟให้อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
แบรนด์ ค่าที่แสดงถึงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรแสดงถึงผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่อุปกรณ์ดังกล่าวใช้ในการทำการตลาด ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
SUPPORTED_ABIS ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
SUPPORTED_32_BIT_ABIS ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
SUPPORTED_64_BIT_ABIS ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU_ABI ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU_ABI2 ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
อุปกรณ์ ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อรหัสที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
FINGERPRINT สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้

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

เช่น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] ต้องมีเมนูการตั้งค่าที่จะเรียก Intent RoleManager.createRequestRoleIntent(String) ด้วย RoleManager.ROLE_SMS เพื่อแสดงกล่องโต้ตอบสำหรับเปลี่ยนแอปพลิเคชัน 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 เป็นไปตามข้อกำหนดนี้ด้วยการแสดงเมนู "ตัวเลือกบัญชีการโทร" ในเมนูการตั้งค่า "การโทร"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • libamidi.so (รองรับ MIDI ในตัว หากมีการอ้างสิทธิ์ฟีเจอร์ android.software.midi ตามที่อธิบายไว้ในส่วนที่ 5.9)
    • libandroid.so (การรองรับกิจกรรม Android ดั้งเดิม)
    • libc (คลัง C)
    • libcamera2ndk.so
    • libdl (ตัวลิงก์แบบไดนามิก)
    • libEGL.so (การจัดการพื้นผิว OpenGL ดั้งเดิม)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (การบันทึกของ Android)
    • libmediandk.so (รองรับ API สื่อแบบเนทีฟ)
    • libm (คลังคณิตศาสตร์)
    • libneuralnetworks.so (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 บิต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. วิดเจ็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.8. การเปลี่ยนกิจกรรม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.12. ตำแหน่ง

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

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

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

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

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

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

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

Android รองรับการแสดงผลแบบอักษรเมียนมา เมียนมามีแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode หลายแบบ ซึ่งเรียกกันโดยทั่วไปว่า "ซอคยี" สำหรับการแสดงผลภาษาเมียนมา

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

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

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

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

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

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

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

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

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

3.8.15. คัตเอาท์ของจอแสดงผล

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12. TV Input Framework

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

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

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

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

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

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

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

3.14 UI ของสื่อ

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

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

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

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

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

3.15. Instant Apps

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

  • [C-0-1] แอปด่วนต้องได้รับสิทธิ์ที่มีการตั้งค่า 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 App ในอุปกรณ์ เว้นแต่ว่า Instant App จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งไว้อย่างชัดเจน
  • การติดตั้งใช้งานอุปกรณ์ต้องให้สิ่งต่อไปนี้แก่ผู้ใช้สำหรับการโต้ตอบกับ Instant App AOSP เป็นไปตามข้อกำหนดด้วย UI ระบบ การตั้งค่า และ Launcher เริ่มต้น การติดตั้งใช้งานอุปกรณ์
    • [C-0-5] ต้องให้ผู้ใช้ดูและลบ Instant App ที่แคชไว้ในเครื่องสำหรับแต่ละแพ็กเกจแอป
    • [C-0-6] ต้องแสดงการแจ้งเตือนแบบถาวรสำหรับผู้ใช้ซึ่งสามารถยุบได้ขณะที่ Instant App ทำงานอยู่เบื้องหน้า การแจ้งเตือนผู้ใช้นี้ต้องระบุว่า Instant App ไม่ต้องมีการติดตั้ง และระบุสิ่งที่ผู้ใช้ทำได้ซึ่งจะนำผู้ใช้ไปยังหน้าจอข้อมูลแอปพลิเคชันในการตั้งค่า สําหรับ Instant App ที่เปิดผ่าน Intent ของเว็บตามที่กําหนดโดยใช้ Intent ที่มีการตั้งค่าการดําเนินการเป็น Intent.ACTION_VIEW และมีรูปแบบเป็น "http" หรือ "https" ความพร้อมใช้งานเพิ่มเติมของผู้ใช้ควรอนุญาตให้ผู้ใช้ไม่เปิด Instant App และเปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กําหนดค่าไว้ หากมีเบราว์เซอร์ในอุปกรณ์
    • [C-0-7] ต้องอนุญาตให้เข้าถึง Instant App ที่ใช้งานอยู่จากฟังก์ชัน "ล่าสุด" หากฟังก์ชัน "ล่าสุด" พร้อมใช้งานในอุปกรณ์

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

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

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

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ 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 Signing
  • [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] ต้องแสดงกล่องโต้ตอบคำเตือนพร้อมสตริงคำเตือนที่ระบุผ่าน API ของระบบ PackageManager.setHarmfulAppWarning ให้แก่ผู้ใช้ก่อนเปิดใช้งานแอปพลิเคชันที่มีการทำเครื่องหมายโดย API ของระบบเดียวกัน PackageManager.setHarmfulAppWarning ว่าอาจเป็นอันตราย

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

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

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

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

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

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

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

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

5.1 ตัวแปลงรหัสสื่อ

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

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

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

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
โปรไฟล์ MPEG-4 AAC
(AAC LC) 		รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC ไฟล์ดิบ ADTS (ไม่รองรับ .aac, ADIF)
  • MPEG-TS (.ts, ไม่สามารถกรอได้ ถอดรหัสเท่านั้น)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
โปรไฟล์ MPEG-4 HE AAC (AAC+) รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
โปรไฟล์ MPEG-4 HE AACv2
(AAC+ ที่ปรับปรุงแล้ว) 		รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC แบบเวลาในการตอบสนองต่ำที่ปรับปรุงแล้ว) รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz MPEG-4 (.mp4, .m4a)
AMR-NB 4.75 ถึง 12.2 kbps ที่อัตราตัวอย่าง 8 kHz 3GPP (.3gp)
AMR-WB 9 อัตราตั้งแต่ 6.60 Kbps ถึง 23.85 Kbps ที่อัตราตัวอย่าง 16 kHz ตามที่ระบุไว้ใน AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec 3GPP (.3gp)
FLAC สำหรับทั้งโปรแกรมเข้ารหัสและโปรแกรมถอดรหัส: ต้องรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย ต้องรองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง FLAC 24 บิตต้องพร้อมใช้งานด้วยการกําหนดค่าเสียงแบบจุดลอย
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
MP3 โมโน/สเตอริโอ 8-320 Kbps แบบคงที่ (CBR) หรืออัตราบิตแบบผันแปร (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)
MIDI MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF รองรับรูปแบบริงโทน RTTTL/RTX, OTA และ iMelody
  • ประเภท 0 และ 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE ตัวแปลงรหัส PCM ต้องรองรับ PCM แบบเชิงเส้น 16 บิตและแบบลอยตัว 16 บิต เครื่องมือแยกไฟล์ WAVE ต้องรองรับ PCM แบบเชิงเส้น 16 บิต, 24 บิต, 32 บิต และ 32 บิตแบบลอย (อัตราสูงสุดตามขีดจำกัดของฮาร์ดแวร์) ต้องรองรับอัตราการสุ่มตัวอย่างตั้งแต่ 8 kHz ถึง 192 kHz WAVE (.wav)
Opus
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น)
  • Matroska (.mkv)
  • Webm (.webm)

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับการเข้ารหัส HEIC ผ่าน android.media.MediaCodec สำหรับประเภทสื่อ MIMETYPE_IMAGE_ANDROID_HEIC อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องมีตัวแปลงรหัสโปรแกรมเปลี่ยนไฟล์ HEVC ที่เร่งด้วยฮาร์ดแวร์ซึ่งรองรับโหมดการควบคุมอัตราบิต BITRATE_MODE_CQ, โปรไฟล์ HEVCProfileMainStill และขนาดเฟรม 512 x 512 พิกเซล

5.1.5. การถอดรหัสรูปภาพ

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

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] ดิบ
  • [C-0-7] HEIF (HEIC)

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

  • [C-1-1] ต้องรองรับการแสดงผลรูปแบบที่เทียบเท่า 8 บิตหากแอปพลิเคชันขอ เช่น ผ่านการกำหนดค่า ARGB_8888 ของ android.graphics.Bitmap

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

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

ตัวเข้ารหัสและตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API

  • [C-1-1] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบยืดหยุ่น (COLOR_FormatYUV420Flexible) ถึง CodecCapabilities

  • [SR] ขอแนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับโหมดอินพุต Surface

  • [C-1-3] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบ Planar หรือ Semiplanar อย่างน้อย 1 รูปแบบ ได้แก่ COLOR_FormatYUV420PackedPlanar (เทียบเท่า COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่า COLOR_FormatYUV420SemiPlanar) ขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

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

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

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

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

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

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

  • [SR] ขอแนะนำอย่างยิ่งว่าโปรแกรมเข้ารหัสและโปรแกรมถอดรหัสวิดีโอควรรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบแพลแนร์ครึ่งที่ฮาร์ดแวร์เพิ่มประสิทธิภาพอย่างน้อย 1 รูปแบบ (YV12, NV12, NV21 หรือรูปแบบที่เพิ่มประสิทธิภาพโดยผู้ให้บริการที่เทียบเท่า)

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

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

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

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

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

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

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

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

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

5.1.9. ความปลอดภัยของตัวแปลงรหัสสื่อ

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

Android รองรับ OMX ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม รวมถึง Codec 2.0 ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียที่มีค่าใช้จ่ายต่ำ

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

  • [C-1-1] ต้องรองรับตัวแปลงรหัสสื่อผ่าน OMX หรือ Codec 2.0 API (หรือทั้ง 2 อย่าง) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android และไม่ปิดใช้หรือหลบเลี่ยงการป้องกันความปลอดภัย ข้อความนี้ไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API แต่หมายความว่าต้องรองรับ API เหล่านี้อย่างน้อย 1 รายการ และการรองรับ API ที่พร้อมใช้งานต้องรวมการป้องกันความปลอดภัยไว้ด้วย
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Codec 2.0 API

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

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

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

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

5.1.10. ลักษณะของตัวแปลงรหัสสื่อ

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

  • [C-1-1] ต้องแสดงค่าที่ถูกต้องของลักษณะเฉพาะของโค้ดคิวสื่อผ่าน MediaCodecInfo API

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

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

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

  • [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ
  • 176 x 144 พิกเซล (H263, MPEG2, MPEG4)
  • 352 x 288 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4, H263, MPEG2)
  • 320 x 180 พิกเซล (VP8, VP8)
  • 320 x 240 พิกเซล (อื่นๆ)
  • 704 x 576 พิกเซล (H263)
  • 640 x 360 พิกเซล (VP8, VP9)
  • 640 x 480 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4)
  • 720 x 480 พิกเซล (อื่นๆ)
  • 1408 x 1152 พิกเซล (H263)
  • 1280 x 720 พิกเซล (อื่นๆ)
1920 x 1080 พิกเซล (ที่ไม่ใช่ MPEG4) 3840 x 2160 พิกเซล (HEVC, VP9)
  • [C-2-2] ตัวแปลงรหัสวิดีโอที่มีลักษณะเป็นการเร่งด้วยฮาร์ดแวร์ต้องเผยแพร่ข้อมูลจุดประสิทธิภาพ โดยแต่ละรายการต้องระบุจุดประสิทธิภาพมาตรฐานที่รองรับทั้งหมด (แสดงใน PerformancePoint API) เว้นแต่ว่าจุดประสิทธิภาพมาตรฐานที่รองรับรายการอื่นจะครอบคลุมจุดดังกล่าว
  • นอกจากนี้ ควรเผยแพร่จุดประสิทธิภาพเพิ่มเติมหากรองรับประสิทธิภาพวิดีโอที่ยั่งยืนนอกเหนือจากจุดมาตรฐานที่ระบุไว้

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

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

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

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือก

5.2.5. H.265

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

  • [C-1-1] ต้องรองรับโปรไฟล์แบบง่ายระดับ 3

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) ผ่าน Media API ให้ทำดังนี้

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือก

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

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

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

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

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

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

    • รูปแบบ: Linear PCM, 16 บิต และ 24 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • ช่อง: จำนวนช่องเท่ากับจำนวนไมโครโฟนในอุปกรณ์

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

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

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

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

  • [C-1-4] ต้องปฏิบัติตาม MicrophoneInfo API และป้อนข้อมูลไมโครโฟนที่มีอยู่ในอุปกรณ์ซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน AudioManager.getMicrophones() API และไมโครโฟนที่ใช้งานอยู่ในปัจจุบันซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน AudioRecord.getActiveMicrophones() และ MediaRecorder.getActiveMicrophones() API อย่างถูกต้อง หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้บันทึกเนื้อหาเสียงดิบในคุณภาพระดับวิทยุ AM และ DVD อุปกรณ์จะมีลักษณะดังนี้

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

  • [C-2-2] ต้องมีฟิลเตอร์การลบรอยหยักที่เหมาะสมสำหรับการเพิ่มหรือลดขนาด

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

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

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

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

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

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

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

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

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

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

5.4.4. การตัดเสียงก้อง

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

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

หากการติดตั้งใช้งานอุปกรณ์มี Acoustic Echo Canceler ที่แทรกไว้ในเส้นทางเสียงที่บันทึกเมื่อเลือก AudioSource.VOICE_COMMUNICATION อุปกรณ์จะดำเนินการดังนี้

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

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

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

5.4.6. ระดับการขยายเสียงของไมโครโฟน

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

  • ควรแสดงลักษณะความดังเทียบกับความถี่ที่ราบเรียบในช่วงความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
  • ควรตั้งค่าความไวของอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB ให้การตอบสนองที่มี RMS 2500 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB Full Scale สำหรับตัวอย่างแบบทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ระบบจดจำเสียง
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

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

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

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

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

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

    • รูปแบบต้นฉบับ: Linear PCM, 16 บิต, 8 บิต, ลอย
    • ช่องสัญญาณ: โมโน ส stereo การกําหนดค่าแบบหลายช่องสัญญาณที่ถูกต้องซึ่งมีได้สูงสุด 8 ช่อง
    • อัตราการสุ่มตัวอย่าง (เป็น Hz)
      • 8000, 11025, 16000, 22050, 32000, 44100, 48000 ที่การกำหนดค่าช่องที่ระบุไว้ข้างต้น
      • 96000 แบบโมโนและสเตอริโอ

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

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

5.5.2. เอฟเฟกต์เสียง

Android มี API สำหรับเอฟเฟกต์เสียงสําหรับการติดตั้งใช้งานอุปกรณ์

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

  • [C-1-1] ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมผ่านคลาสย่อย AudioEffect Equalizer และ LoudnessEnhancer
  • [C-1-2] ต้องรองรับการติดตั้งใช้งาน Visualizer API ที่ควบคุมได้ผ่านคลาส Visualizer
  • [C-1-3] ต้องรองรับการใช้งาน EFFECT_TYPE_DYNAMICS_PROCESSING ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect DynamicsProcessing
  • ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์แบบทศนิยมและหลายช่อง

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

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

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

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

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

ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้

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

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

  • [C-1-1] การประทับเวลาเอาต์พุตที่ AudioTrack.getTimestamp และ AAudioStream_getTimestamp แสดงผลจะมีความแม่นยำ +/- 2 มิลลิวินาที
  • [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 500 มิลลิวินาที

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

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

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

  • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำโดยการประกาศ Flag ฟีเจอร์ 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-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

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

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

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

  • [C-SR] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 100 มิลลิวินาที เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบัติตามข้อกำหนดเหล่านี้ในตอนนี้ ในแพลตฟอร์มรุ่นที่จะเปิดตัวในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองของอินพุตแบบ Cold ต้องเป็น 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-SR] เวลาในการตอบสนองของอินพุตแบบต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องที่ 50 มิลลิวินาทีหรือน้อยกว่า
  • [C-SR] ลดความผันผวนของอินพุตแบบ Cold Start
  • [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 Transport Stream ISO 13818 ตัวแปลงรหัสวิดีโอ:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP
และ MPEG-2 ได้ที่ส่วนที่ 5.1.3

ตัวแปลงรหัสเสียง

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

RTSP (RTP, SDP)

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

5.8. Secure Media

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

  • [C-1-1] ต้องประกาศรองรับ Display.FLAG_SECURE

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

  • [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกการเข้ารหัสที่มีประสิทธิภาพ เช่น HDCP 2.x ขึ้นไปสำหรับจอภาพที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

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

  • [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อผ่านพอร์ตแบบใช้สายที่ผู้ใช้เข้าถึงได้

5.9. Musical Instrument Digital Interface (MIDI)

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

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

  • [C-1-2] ต้องรองรับการนำส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือนจริง)

  • [C-1-3] ต้องมี libamidi.so (การรองรับ MIDI ดั้งเดิม)

5.10. เสียงระดับมืออาชีพ

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

  • [C-1-1] ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency
  • [C-1-2] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียงไม่เกิน 20 มิลลิวินาที และควรไม่เกิน 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
  • [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
  • [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
  • [C-1-5] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB โดยใช้ทั้ง API คิวบัฟเฟอร์ PCM ของ OpenSL ES และเส้นทางของ AAudio Native Audio API อย่างน้อย 1 เส้นทาง
  • [SR] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองและเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อให้ประสิทธิภาพของ CPU อยู่ในระดับที่สม่ำเสมอขณะที่เสียงทำงานอยู่และภาระงานของ CPU แตกต่างกันไป ควรทดสอบโดยใช้รหัสคอมมิต SynthMark เวอร์ชันแอป Android 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 SynthMark ใช้โปรแกรมสังเคราะห์เสียงซอฟต์แวร์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองซึ่งวัดประสิทธิภาพของระบบ แอป SynthMark ต้องทำงานโดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
    • voicemark.90 >= 32 voices
    • latencymark.fixed.little <= 15 msec
    • latencymark.dynamic.little <= 50 msec

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

  • ควรลดความคลาดเคลื่อนและการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน
  • ควรลดการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่
  • ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในเส้นทางทั้งหมด
  • ควรลดการกระตุกของเวลาในการป้อนข้อมูลการเรียกกลับเมื่อบัฟเฟอร์เสียงเสร็จสมบูรณ์ เนื่องจากจะส่งผลต่อเปอร์เซ็นต์แบนด์วิดท์ของ CPU ทั้งหมดที่ใช้งานได้จากการเรียกกลับ
  • ควรไม่มีข้อบกพร่องของเสียงเมื่อใช้งานตามปกติโดยมีเวลาในการตอบสนองตามที่รายงาน
  • ควรให้เวลาในการตอบสนองระหว่างแชแนลเป็น 0
  • ควรลดเวลาในการตอบสนองเฉลี่ยของ 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
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 ช่องในแต่ละทิศทาง, อัตราตัวอย่าง 96 kHz และความละเอียด 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Android Debug Bridge (adb)

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

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

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

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรปิดใช้งานโดยค่าเริ่มต้น แต่ต้องรองรับเมื่อใดก็ตามที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ดังที่กล่าวไว้ข้างต้น
  • Monkey
    • [C-0-8] ต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
  • SysTrace
    • [C-0-9] ต้องรองรับเครื่องมือ Systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดอยู่โดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace

  • Perfetto

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-2] ยังคงต้องแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
  • [C-0-3] ลักษณะการทํางานของ API ต้องใช้งานแบบไม่ทําการใดๆ ในลักษณะที่เหมาะสม
  • [C-0-4] เมธอด API ต้องแสดงผลค่า Null ตามที่เอกสารประกอบของ SDK อนุญาต
  • [C-0-5] เมธอด API ต้องแสดงผลการใช้งานคลาสแบบไม่มีการดำเนินการในกรณีที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
  • [C-0-6] เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
  • [C-0-7] การติดตั้งใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

ตัวอย่างทั่วไปของสถานการณ์ที่มีการใช้ข้อกำหนดเหล่านี้คือ API โทรศัพท์: แม้แต่ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็ต้องติดตั้งใช้งาน API เหล่านี้แบบไม่ดำเนินการใดๆ ที่สมเหตุสมผล

7.1. การแสดงผลและกราฟิก

Android มีเครื่องมือที่ปรับชิ้นงานแอปพลิเคชันและเลย์เอาต์ UI ให้เหมาะสมกับอุปกรณ์โดยอัตโนมัติ เพื่อให้แอปพลิเคชันของบุคคลที่สามทำงานได้อย่างราบรื่นในการกำหนดค่าฮาร์ดแวร์ต่างๆ ในจอแสดงผลที่เข้ากันได้กับ Android ซึ่งแอปพลิเคชันทั้งหมดของบุคคลที่สามที่เข้ากันได้กับ Android สามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้จะกำหนดไว้ดังนี้

  • ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้ามกัน 2 มุมของส่วนที่สว่างของจอแสดงผล
  • จุดต่อนิ้ว (dpi) จํานวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้ง 1 นิ้ว เมื่อระบุค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วง
  • สัดส่วนภาพ อัตราส่วนของพิกเซลของขนาดที่ยาวกว่าต่อขนาดที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะเป็น 854/480 = 1.779 หรือประมาณ "16:9"
  • ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นมาตรฐานของหน้าจอ 160 dpi ซึ่งคำนวณโดยสูตร pixels = dps * (density/160)

7.1.1. การกำหนดค่าหน้าจอ

7.1.1.1. ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลายขนาด และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ Configuration.screenLayout ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอพิกเซล (dp) อิสระจากความหนาแน่นตามตรรกะที่ถูกต้องดังต่อไปนี้

    • อุปกรณ์ที่มีการตั้งค่า Configuration.uiMode เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_WATCH และรายงานขนาด small สำหรับ Configuration.screenLayout ต้องมีขนาดอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด normal สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด large สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีความละเอียดอย่างน้อย 960 dp x 720 dp

  • [C-0-2] ต้องรองรับขนาดหน้าจอตามที่แอปพลิเคชันระบุไว้อย่างถูกต้องผ่านแอตทริบิวต์ <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

  • อาจมีจอแสดงผลที่รองรับ Android และมีมุมโค้งมน

หากการติดตั้งใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL และมีจอแสดงผลที่เข้ากันได้กับ Android ที่มีมุมมน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ตรวจสอบว่ารัศมีของมุมมนน้อยกว่าหรือเท่ากับ 38 dp
  • ควรมีสิ่งต่างๆ ที่ผู้ใช้สามารถโต้ตอบด้วยเพื่อเปลี่ยนไปใช้โหมดการแสดงผลที่มีมุมสี่เหลี่ยมผืนผ้า
7.1.1.2. สัดส่วนภาพหน้าจอ

แม้ว่าจะไม่มีข้อจำกัดเกี่ยวกับสัดส่วนภาพของจอแสดงผลจริงสำหรับจอแสดงผลที่เข้ากันได้กับ Android แต่สัดส่วนภาพของจอแสดงผลเชิงตรรกะซึ่งแสดงผลแอปของบุคคลที่สาม ซึ่งสามารถดึงมาจากค่าความสูงและความกว้างที่รายงานผ่าน view.Display API และ Configuration API จะต้องเป็นไปตามข้อกำหนดต่อไปนี้

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ที่มีการตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

    • แอปได้ประกาศว่ารองรับสัดส่วนภาพหน้าจอที่ใหญ่ขึ้นผ่านค่าข้อมูลเมตา android.max_aspect
    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไปและไม่ได้ประกาศ android:maxAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

  • [C-0-2] การติดตั้งใช้งานอุปกรณ์ที่มีการตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพเท่ากับหรือมากกว่า 1.3333 (4:3) เว้นแต่แอปจะขยายให้กว้างขึ้นได้โดยเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปประกาศ android:minAspectRatio ซึ่งจะจํากัดสัดส่วนภาพที่อนุญาต

  • [C-0-3] การติดตั้งใช้งานอุปกรณ์ที่มีการตั้งค่า Configuration.uiMode เป็น UI_MODE_TYPE_WATCH จะต้องมีการตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)

7.1.1.3. ความหนาแน่นของหน้าจอ

เฟรมเวิร์ก UI ของ Android จะกำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยนักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรแอปพลิเคชัน

  • [C-0-1] โดยค่าเริ่มต้น การติดตั้งใช้งานอุปกรณ์ต้องรายงานความหนาแน่นเฟรมเวิร์ก Android เพียงค่าเดียวที่แสดงใน DisplayMetrics ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องไม่เปลี่ยนแปลงไม่ว่าเมื่อใดก็ตาม อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่ต่างกันตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ซึ่งตั้งค่าไว้หลังจากการบูตครั้งแรก

  • การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับค่าความหนาแน่นจริงของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าค่าต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับค่าความหนาแน่นของอุปกรณ์มากที่สุดส่งผลให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่รองรับ (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป

หากมีตัวเลือกให้เปลี่ยนขนาดการแสดงผลของอุปกรณ์ ให้ทำดังนี้

  • [C-1-1] ขนาดการแสดงผลต้องไม่ปรับขนาดให้ใหญ่กว่าความหนาแน่นดั้งเดิม 1.5 เท่า หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพเล็กกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) แล้วแต่ว่าข้อใดจะมาก่อน
  • [C-1-2] ขนาดการแสดงผลต้องไม่ปรับขนาดให้เล็กกว่า 0.85 เท่าของความหนาแน่นดั้งเดิม
  • เราขอแนะนำให้ใช้การปรับขนาดตัวเลือกการแสดงโฆษณาเนทีฟต่อไปนี้ (ขณะที่เป็นไปตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อให้ใช้งานได้ดีและขนาดแบบอักษรสอดคล้องกัน
  • เล็ก: 0.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15 เท่า
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลหรือเอาต์พุตวิดีโอที่ใช้งานร่วมกับ Android ได้ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริก Display ทั้งหมดที่เข้ากันได้กับ Android ซึ่งกำหนดไว้ใน android.util.DisplayMetrics API

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอหรือเอาต์พุตวิดีโอแบบฝัง อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่เข้ากันได้กับ Android ตามที่ระบุไว้ใน android.util.DisplayMetrics API สำหรับ view.Display เริ่มต้นที่จำลอง

7.1.3. การวางแนวหน้าจอ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
  • [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

หากการติดตั้งใช้งานอุปกรณ์รองรับการวางแนวหน้าจอทั้ง 2 แบบ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกตามแอปพลิเคชันสำหรับการวางแนวหน้าจอในแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เฉพาะเจาะจง
  • [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
  • อาจเลือกการวางแนวเป็นแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API เดิม
  • [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API เดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุไว้ว่ารองรับ

หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดเวอร์ชันหนึ่ง อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรายงานผ่าน API ที่จัดการของ OpenGL ES และ API เดิมเกี่ยวกับส่วนขยาย OpenGL ES อื่นๆ ที่ใช้ และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
  • [C-2-2] ต้องรองรับส่วนขยาย EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable และ EGL_ANDROID_GLES_layers
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย EGL_KHR_partial_update และ OES_EGL_image_external
  • ควรรายงานอย่างถูกต้องผ่านเมธอด getString() เกี่ยวกับรูปแบบการบีบอัดพื้นผิวที่รองรับ ซึ่งโดยทั่วไปจะเจาะจงตามผู้ให้บริการ

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย OES_EGL_image_external_essl3

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องรองรับ OpenGL ES Android Extension Pack โดยสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES โดยสมบูรณ์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-5-1] ต้องระบุการรองรับผ่าน Flag ฟีเจอร์ android.hardware.opengles.aep

หากการติดตั้งใช้งานอุปกรณ์รองรับส่วนขยาย EGL_KHR_mutable_render_buffer อุปกรณ์จะมีลักษณะดังนี้

  • [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย
7.1.4.2 Vulkan

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะมีลักษณะดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1

หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้

  • ควรรองรับ Vulkan 1.1

หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.0 อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วย Flag ฟีเจอร์ android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องระบุ VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ API เนทีฟของ Vulkan vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องติดตั้งใช้งาน Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับ VkPhysicalDevice ที่ระบุไว้แต่ละรายการ
  • [C-1-4] ต้องแจกแจงเลเยอร์ที่อยู่ในไลบรารีเนทีฟชื่อ libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน API เนทีฟของ Vulkan vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
  • [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่จัดหาโดยไลบรารีนอกแพ็กเกจแอปพลิเคชัน หรือระบุวิธีอื่นๆ ในการติดตามหรือขัดจังหวะ Vulkan API เว้นแต่แอปพลิเคชันจะตั้งค่าแอตทริบิวต์ android:debuggable เป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน API เนทีฟของ Vulkan และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
  • [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย VK_KHR_driver_properties และ VK_GOOGLE_display_timing

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
  • [C-2-2] ต้องไม่แจกแจง VkPhysicalDevice สำหรับ API เนทีฟของ Vulkan vkEnumeratePhysicalDevices()

หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.1 และประกาศ Flag ฟีเจอร์ Vulkan อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องแสดงการรองรับเซมาโฟร์และตัวแฮนเดิลภายนอกประเภท SYNC_FD และส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer
7.1.4.3 RenderScript
  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือมุมมองผ่านการใช้แท็กไฟล์ Manifest android:hardwareAccelerated หรือการเรียก API โดยตรง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
  • [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งด้วยฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยนักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกันกับการใช้งาน Android เวอร์ชันที่อัปเดต
7.1.4.5 จอแสดงผลแบบช่วงสีกว้าง

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับจอแสดงผลแบบช่วงสีกว้างผ่าน Configuration.isScreenWideColorGamut() อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
  • [C-1-2] ต้องมีจอแสดงผลที่ช่วงสีครอบคลุมช่วงสี sRGB ทั้งหมดในพื้นที่สี CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่ช่วงสีมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในเชิงพื้นที่ 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_EXT_gl_colorspace_display_p3_linear และ EGL_EXT_gl_colorspace_display_p3_passthrough
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ GL_EXT_sRGB

ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับจอแสดงผลแบบช่วงสีกว้าง อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่สี xyY ของ CIE 1931 แม้ว่าช่วงสีของหน้าจอจะไม่มีการระบุ

7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม

Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทํางานในโหมดขนาดหน้าจอ "ปกติ" (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาขึ้นสําหรับ Android เวอร์ชันเก่าซึ่งอยู่ก่อนยุคที่รองรับหน้าจอทุกขนาด

7.1.6. เทคโนโลยีหน้าจอ

แพลตฟอร์ม Android มี API ที่ช่วยให้แอปพลิเคชันแสดงผลกราฟิกแบบริชมีเดียไปยังจอแสดงผลที่เข้ากันได้กับ Android ได้ อุปกรณ์ต้องรองรับ API ทั้งหมดเหล่านี้ตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตอย่างเจาะจงในเอกสารนี้

จอแสดงผลทั้งหมดที่เข้ากันได้กับ Android ของการติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีความสามารถในการแสดงผลกราฟิกสี 16 บิต
  • ควรรองรับจอแสดงผลที่แสดงกราฟิกสี 24 บิตได้
  • [C-0-2] ต้องแสดงภาพเคลื่อนไหวได้
  • [C-0-3] ต้องมีสัดส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10-15%

7.1.7. จอแสดงผลสำรอง

Android รองรับจอแสดงผลรองที่เข้ากันได้กับ Android เพื่อเปิดใช้ความสามารถในการแชร์สื่อและ API ของนักพัฒนาแอปสำหรับการเข้าถึงจอแสดงผลภายนอก

หากการติดตั้งใช้งานอุปกรณ์รองรับจอแสดงผลภายนอกผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบฝัง อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้บริการระบบและ API ของ DisplayManager ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

7.2. อุปกรณ์อินพุต

การติดตั้งใช้งานอุปกรณ์

7.2.1. แป้นพิมพ์

หากการติดตั้งใช้งานอุปกรณ์รองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.software.input_methods
  • [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
  • [C-1-3] ต้องมีแป้นพิมพ์ซอฟต์แวร์ที่ติดตั้งไว้ล่วงหน้า

การติดตั้งใช้งานอุปกรณ์: * [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 ปุ่ม) * ควรระบุการติดตั้งใช้งานแป้นพิมพ์บนหน้าจอเพิ่มเติม * อาจรวมแป้นพิมพ์ฮาร์ดแวร์

7.2.2. การนำทางแบบไม่สัมผัส

Android รองรับ D-Pad, แทร็กบอล และล้อเป็นกลไกในการไปยังส่วนต่างๆ โดยไม่ใช้การสัมผัส

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์ไม่มีการนำทางแบบไม่สัมผัส อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องมีกลไกอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสำหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือจัดการอินพุต การใช้งานโอเพนซอร์สจากฝั่งอัปสตรีมของ Android มีกลไกการเลือกที่เหมาะสมสำหรับใช้กับอุปกรณ์ที่ไม่มีอินพุตการไปยังส่วนต่างๆ ที่ไม่ใช้การสัมผัส

7.2.3. ปุ่มนำทาง

ฟังก์ชันหน้าแรก ล่าสุด และกลับ ซึ่งมักจะมีให้ใช้งานผ่านการโต้ตอบกับปุ่มบนตัวเครื่องหรือส่วนต่างๆ ของหน้าจอสัมผัสโดยเฉพาะ มีความสำคัญต่อรูปแบบการนำทางของ Android และการใช้งานอุปกรณ์

  • [C-0-1] ต้องให้ทางเลือกแก่ผู้ใช้ในการเปิดแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่มี<intent-filter>ที่ตั้งค่าไว้กับ ACTION=MAIN และ CATEGORY=LAUNCHER หรือ CATEGORY=LEANBACK_LAUNCHER สำหรับการใช้งานอุปกรณ์ทีวี ฟังก์ชันหน้าแรกควรเป็นกลไกสําหรับความสามารถของผู้ใช้นี้
  • ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"

หากมีฟังก์ชันหน้าแรก ล่าสุด หรือย้อนกลับ ฟังก์ชันเหล่านี้จะทําดังนี้

  • [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงการดำเนินการใดก็ได้
  • [C-1-2] ต้องระบุอย่างชัดเจนว่าการกระทำใดที่เรียกให้ฟังก์ชันแต่ละรายการทำงาน ตัวอย่างของการแสดงข้อมูลดังกล่าว ได้แก่ การมีไอคอนที่มองเห็นได้บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนพร้อมคำแนะนำระหว่างการตั้งค่าแบบพร้อมใช้งานทันที

การติดตั้งใช้งานอุปกรณ์

  • [SR] ขอแนะนำอย่างยิ่งว่าอย่าระบุกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานแล้วเพื่อสนับสนุนแถบการดำเนินการตั้งแต่ Android 4.0

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันเมนู อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องแสดงปุ่มรายการการดำเนินการเพิ่มเติมทุกครั้งที่เมนูรายการการดำเนินการเพิ่มเติมของป๊อปอัปไม่ว่างเปล่าและแถบการดำเนินการแสดงอยู่
  • [C-2-2] ต้องไม่แก้ไขตําแหน่งของป๊อปอัปรายการเพิ่มเติมของการดำเนินการที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการดำเนินการ แต่อาจแสดงผลป๊อปอัปรายการเพิ่มเติมของการดำเนินการในตําแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงโดยการเลือกฟังก์ชันเมนู

หากการใช้งานอุปกรณ์ไม่มีฟังก์ชันเมนู อุปกรณ์จะต้องมีลักษณะดังนี้เพื่อรองรับการใช้งานย้อนหลัง * [C-SR] ขอแนะนำอย่างยิ่งให้ทำให้แอปพลิเคชันใช้งานฟังก์ชันเมนูได้เมื่อ targetSdkVersion น้อยกว่า 10 โดยใช้ปุ่มบนอุปกรณ์ ปุ่มบนซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการไปยังส่วนต่างๆ อื่นๆ

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน Assist อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-4-1] ต้องทำให้เข้าถึงฟังก์ชัน Assist ได้ด้วยการดําเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงแป้นการนําทางอื่นๆ ได้
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้การกดฟังก์ชัน HOME ค้างไว้เป็นการโต้ตอบที่กำหนด

หากการติดตั้งใช้งานอุปกรณ์ใช้ส่วนต่างๆ ของหน้าจอเพื่อแสดงแป้นนำทาง แป้นดังกล่าวจะมีลักษณะดังนี้

  • [C-5-1] ปุ่มการไปยังส่วนต่างๆ ของหน้าจอต้องใช้พื้นที่บนหน้าจอที่แยกต่างหาก ซึ่งแอปพลิเคชันไม่สามารถใช้ได้ และต้องไม่บดบังหรือรบกวนพื้นที่บนหน้าจอที่แอปพลิเคชันใช้ได้
  • [C-5-2] ต้องจัดสรรพื้นที่ส่วนหนึ่งของจอแสดงผลให้กับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
  • [C-5-3] ต้องปฏิบัติตาม Flag ที่แอปตั้งค่าไว้ผ่านเมธอด View.setSystemUiVisibility() API เพื่อให้ส่วนที่แตกต่างกันนี้ของหน้าจอ (หรือที่เรียกว่าแถบนําทาง) ซ่อนอยู่อย่างถูกต้องตามที่ระบุไว้ใน SDK

หากฟังก์ชันการไปยังส่วนต่างๆ มีให้ใช้งานเป็นการกระทําบนหน้าจอโดยอิงตามท่าทางสัมผัส ให้ทําดังนี้

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้ในการรายงานพื้นที่การจดจำท่าทางสัมผัสของ Home เท่านั้น
  • [C-6-2] ห้ามขัดจังหวะท่าทางสัมผัสที่เริ่มต้นภายในสี่เหลี่ยมผืนผ้าการยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets() สำหรับฟังก์ชันการไปยังส่วนต่างๆ ตราบใดที่สี่เหลี่ยมผืนผ้าการยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
  • [C-6-3] ต้องส่งเหตุการณ์ MotionEvent.ACTION_CANCEL ไปยังแอปที่ทำงานอยู่เบื้องหน้าเมื่อเริ่มมีการสกัดกั้นการแตะเพื่อใช้ท่าทางสัมผัสของระบบ หากก่อนหน้านี้แอปที่ทำงานอยู่เบื้องหน้าได้รับเหตุการณ์ MotionEvent.ACTION_DOWN
  • [C-6-4] ต้องระบุสิ่งที่ผู้ใช้ทำได้เพื่อเปลี่ยนไปใช้การไปยังส่วนต่างๆ บนหน้าจอโดยอิงตามปุ่ม (เช่น ในการตั้งค่า)
  • ควรมีฟังก์ชันหน้าแรกด้วยการปัดขึ้นจากขอบด้านล่างของการวางแนวหน้าจอปัจจุบัน
  • ควรมีฟังก์ชันรายการล่าสุดด้วยการปัดขึ้นแล้วกดค้างไว้ก่อนปล่อยจากบริเวณเดียวกับท่าทางสัมผัสสำหรับหน้าแรก
  • ท่าทางสัมผัสที่เริ่มต้นภายใน WindowInsets#getMandatorySystemGestureInsets() ไม่ควรได้รับผลกระทบจากสี่เหลี่ยมผืนผ้าการยกเว้นที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน View#setSystemGestureExclusionRects()

หากมีฟังก์ชันการนำทางจากขอบด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ ให้ทำดังนี้

  • [C-7-1] ฟังก์ชันการนําทางต้องเป็น "กลับ" และให้บริการด้วยการปัดจากทั้งขอบด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
  • [C-7-2] หากมีแผงระบบที่ปัดได้ซึ่งกำหนดเองที่ขอบซ้ายหรือขวา แผงดังกล่าวต้องอยู่ใน 1/3 ด้านบนของหน้าจอพร้อมด้วยตัวบ่งชี้ที่ชัดเจนและแสดงอยู่ตลอดเวลาว่าการลากเข้าจะเป็นการเรียกแผงดังกล่าวขึ้นมา ไม่ใช่ปุ่มย้อนกลับ ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ด้านล่าง 1/3 ด้านบนของขอบหน้าจอ แต่แผงระบบต้องไม่ยาวเกิน 1/3 ของขอบ
  • [C-7-3] เมื่อแอปที่ทำงานอยู่เบื้องหน้าตั้งค่า Flag View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY การปัดจากขอบต้องทํางานตามที่ติดตั้งใช้งานใน AOSP ซึ่งมีบันทึกไว้ในSDK
  • [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้าตั้งค่า Flag View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY ไว้ ระบบจะต้องซ่อนแผงระบบที่ปัดได้ที่กำหนดเองไว้จนกว่าผู้ใช้จะเปิดแถบระบบ (หรือที่เรียกว่าแถบนําทางและแถบสถานะ) ตามที่ติดตั้งใช้งานใน AOSP

7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส

Android รองรับระบบอินพุตด้วยเคอร์เซอร์ที่หลากหลาย เช่น หน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตการสัมผัสจำลอง การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลเพื่อให้ผู้ใช้รู้สึกว่ากำลังควบคุมรายการต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อระบุวัตถุที่กำลังมีการจัดการ

การติดตั้งใช้งานอุปกรณ์

  • ควรมีระบบการป้อนข้อมูลด้วยเคอร์เซอร์บางประเภท (แบบเมาส์หรือแบบสัมผัส)
  • ควรรองรับเคอร์เซอร์ที่มีการติดตามอย่างอิสระโดยสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอสัมผัส (แบบสัมผัสเดียวหรือดีกว่า) อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงาน TOUCHSCREEN_FINGER สำหรับช่อง API Configuration.touchscreen
  • [C-1-2] ต้องรายงาน Flag ฟีเจอร์ android.hardware.touchscreen และ android.hardware.faketouch

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการสัมผัสมากกว่า 1 ครั้ง อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรายงาน Flag ฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand ซึ่งสอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงในอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส (และใช้อุปกรณ์เคอร์เซอร์เท่านั้น) และเป็นไปตามข้อกําหนดการแตะแบบจําลองในส่วนที่ 7.2.5 อุปกรณ์ดังกล่าวต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องไม่รายงาน Flag ฟีเจอร์ที่ขึ้นต้นด้วย android.hardware.touchscreen และต้องรายงานเฉพาะ android.hardware.faketouch

7.2.5. การป้อนข้อมูลด้วยการสัมผัสจำลอง

อินเทอร์เฟซแบบ Fake Touch มีระบบการป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายแบบใช้แรงโน้มถ่วง ปากกาควบคุมแบบใช้แรงโน้มถ่วง จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบสัมผัสจำลอง Android มีค่าคงที่ของฟีเจอร์ android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (อิงตามเคอร์เซอร์) ที่มีความเที่ยงตรงสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจําลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสชุดย่อยที่จำลอง

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่มีระบบอินพุตด้วยเคอร์เซอร์อื่นที่ต้องการให้บริการ ผู้ผลิตจะต้องดำเนินการดังนี้

  • ควรประกาศการรองรับ Flag ฟีเจอร์ android.hardware.faketouch

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงานตำแหน่งสัมบูรณ์บนหน้าจอ X และ Y ของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ที่มองเห็นได้บนหน้าจอ
  • [C-1-2] ต้องรายงานเหตุการณ์การสัมผัสด้วยโค้ดการดำเนินการที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นกับเคอร์เซอร์ที่เลื่อนขึ้นหรือลงบนหน้าจอ
  • [C-1-3] ต้องรองรับการกดเคอร์เซอร์ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จําลองการแตะวัตถุบนหน้าจอได้
  • [C-1-4] ต้องรองรับการกดเคอร์เซอร์ลง การกดเคอร์เซอร์ขึ้น การกดเคอร์เซอร์ลงแล้วกดขึ้นอีกครั้งในตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จําลองการแตะสองครั้งบนวัตถุบนหน้าจอได้
  • [C-1-5] ต้องรองรับการกดเคอร์เซอร์ลง ณ จุดใดก็ได้บนหน้าจอ การเลื่อนเคอร์เซอร์ไปยังจุดใดก็ได้บนหน้าจอตามด้วยเคอร์เซอร์ขึ้น ซึ่งช่วยให้ผู้ใช้จําลองการลากด้วยการแตะได้
  • [C-1-6] ต้องรองรับการกดแป้นเคอร์เซอร์ลง จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจออย่างรวดเร็ว แล้วกดแป้นเคอร์เซอร์ขึ้นบนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้เหวี่ยงวัตถุบนหน้าจอได้
  • [C-1-7] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับช่อง API Configuration.touchscreen

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.distinct อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-2-1] ต้องประกาศรองรับ android.hardware.faketouch
  • [C-2-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการแยกกัน

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.jazzhand อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องประกาศรองรับ android.hardware.faketouch
  • [C-3-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์ที่แตกต่างกันอย่างน้อย 5 รายการ (การติดตามมือของนิ้ว) โดยอิสระอย่างสมบูรณ์

7.2.6. การรองรับเกมคอนโทรลเลอร์

7.2.6.1. การแมปปุ่ม

หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.hardware.gamepad อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องมีตัวควบคุมแบบฝังหรือจัดส่งพร้อมตัวควบคุมแยกต่างหากในกล่อง ซึ่งจะเป็นช่องทางในการป้อนข้อมูลเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่าง
  • [C-1-2] ต้องสามารถแมปเหตุการณ์ HID กับค่าคงที่ view.InputEvent ของ Android ที่เกี่ยวข้องตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งาน Android ขั้นต้นรวมถึงการติดตั้งใช้งานสำหรับตัวควบคุมเกมที่เป็นไปตามข้อกำหนดนี้
ปุ่ม การใช้งาน HID2 ปุ่ม Android
ก1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
ปุ่ม D-pad ขึ้น1
ปุ่ม D-pad ลง1 		0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ขวา1 		0x01 0x00393 AXIS_HAT_X4
ปุ่ม L1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่ม L R ขวา1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกแท่งบังคับซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกแท่งบังคับด้านขวา1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Home1 0x0c 0x0223 KEYCODE_HOME (3)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 การใช้งาน HID ข้างต้นต้องประกาศภายใน CA ของเกมแพด (0x01 0x0005)

3 การใช้งานนี้ต้องมีค่าต่ำสุดเชิงตรรกะเป็น 0, ค่าสูงสุดเชิงตรรกะเป็น 7, ค่าต่ำสุดเชิงกายภาพเป็น 0, ค่าสูงสุดเชิงกายภาพเป็น 315, หน่วยเป็นองศา และขนาดรายงานเป็น 4 ค่าตรรกะจะกำหนดให้เป็นการหมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง เช่น ค่าตรรกะ 0 หมายถึงไม่มีการหมุนและมีการกดปุ่มขึ้น ส่วนค่าตรรกะ 1 หมายถึงการหมุน 45 องศาและมีการกดทั้งแป้นขึ้นและซ้าย

4 MotionEvent

การควบคุมแบบแอนะล็อก1 การใช้งาน HID ปุ่ม Android
ทริกเกอร์ซ้าย 0x02 0x00C5 AXIS_LTRIGGER
ทริกเกอร์ขวา 0x02 0x00C4 AXIS_RTRIGGER
จอยสติ๊กซ้าย 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
จอยสติ๊กขวา 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. การควบคุมระยะไกล

ดูข้อกำหนดเฉพาะอุปกรณ์ได้ที่ส่วนที่ 2.3.1

7.3. เซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการมีอยู่หรือไม่มีของเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager
  • [C-0-2] ต้องแสดงรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่าน SensorManager.getSensorList() และวิธีการที่คล้ายกัน
  • [C-0-3] ต้องทํางานอย่างสมเหตุสมผลสําหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น แสดงผล true หรือ false ตามเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียนตัวรับฟัง ไม่เรียกใช้ตัวรับฟังเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม นักพัฒนาแอปบุคคลที่สามจะทำสิ่งต่อไปนี้ได้

  • [C-1-1] ต้องรายงานค่าการวัดจากเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยวัดระหว่างประเทศ (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์โดยมีความล่าช้าสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีที่สตรีมเซ็นเซอร์มีความล่าช้าสูงสุดที่ขอ 0 มิลลิวินาทีเมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง
  • [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. ตัวตรวจวัดความเร่ง

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใส่ตัววัดความเร่งแบบ 3 แกน

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API
  • [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้สูงสุด 4 เท่าของแรงโน้มถ่วง(4g) ขึ้นไปบนแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ค่าเบี่ยงเบนมาตรฐานต้องไม่เกิน 0.05 m/s^ โดยค่าเบี่ยงเบนมาตรฐานควรคํานวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด
  • [SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION
  • [SR] แนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_UNCALIBRATED เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android มีคุณสมบัติตรงตามข้อกำหนดนี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้ ซึ่งอาจจำเป็นต้องมีคุณสมบัติตรงตามข้อกำหนดนี้
  • ควรติดตั้งเซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK
  • ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
  • ควรมีความละเอียดอย่างน้อย 16 บิต
  • ควรได้รับการปรับเทียบขณะใช้งานหากลักษณะการทำงานมีการเปลี่ยนแปลงตลอดอายุการใช้งานและได้รับการชดเชย รวมถึงเก็บรักษาพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
  • ควรมีการชดเชยอุณหภูมิ

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดความเร่ง 3 แกนและเซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ใดก็ตาม ให้ทำดังนี้

  • [C-2-1] ผลรวมของปริมาณการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
  • ควรมีค่าต่ำกว่า 2 mW และ 0.5 mW สำหรับกรณีที่อุปกรณ์อยู่ในสถานะแบบไดนามิกหรือแบบคงที่

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
  • [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน และเซ็นเซอร์แม่เหล็ก อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-4-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_ROTATION_VECTOR

7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใส่แม่เหล็กไฟฟ้า 3 แกน (เข็มทิศ)

หากการติดตั้งใช้งานอุปกรณ์มีแม่เหล็ก 3 แกน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องติดตั้งเซ็นเซอร์ TYPE_MAGNETIC_FIELD
  • [C-1-2] ต้องรายงานเหตุการณ์ได้สูงสุดที่ความถี่ 10 Hz เป็นอย่างน้อย และควรรายงานเหตุการณ์ได้สูงสุดที่ความถี่ 50 Hz เป็นอย่างน้อย
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามรายละเอียดใน Android API
  • [C-1-4] ต้องสามารถวัดได้ระหว่าง -900 µT ถึง +900 µT ในแต่ละแกนก่อนที่จะอิ่มตัว
  • [C-1-5] ต้องมีค่าออฟเซ็ตของเหล็กแข็งน้อยกว่า 700 µT และต้องมีค่าต่ำกว่า 200 µT โดยวางมาตรแม่เหล็กให้ห่างจากสนามแม่เหล็กแบบไดนามิก (เกิดจากกระแสไฟฟ้า) และแบบคงที่ (เกิดจากแม่เหล็ก)
  • [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 µT
  • [C-1-7] ต้องรองรับการปรับเทียบออนไลน์และการชดเชยความเบี่ยงเบนของเหล็กแข็ง และเก็บรักษาพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
  • [C-1-8] ต้องใช้การชดเชยเหล็กอ่อน - การปรับเทียบทำได้ขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
  • [C-1-9] ค่าเบี่ยงเบนมาตรฐานต้องคำนวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด โดยต้องไม่เกิน 1.5 µT และควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT
  • ควรติดตั้งใช้งานเซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [SR] ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่ใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-2-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีแม่เหล็ก 3 แกน ตัววัดความเร่ง อุปกรณ์จะทําสิ่งต่อไปนี้

  • อาจติดตั้งเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน ตัววัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
  • ควรใช้พลังงานน้อยกว่า 3 mW เมื่อเซ็นเซอร์ลงทะเบียนสำหรับโหมดแบตช์ที่ 10 Hz

7.3.3. GPS

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใส่เครื่องรับ GPS/GNSS

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่าน Flag ฟีเจอร์ android.hardware.location.gps อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งที่อัตราอย่างน้อย 1 Hz เมื่อมีการขอผ่าน LocationManager#requestLocationUpdate
  • [C-1-2] ต้องระบุตำแหน่งได้ในสภาพท้องฟ้าเปิด (สัญญาณแรง เส้นทางหลายเส้นทางที่ควรละเว้น HDOP < 2) ภายใน 10 วินาที (เวลาในการหาตำแหน่งครั้งแรกที่รวดเร็ว) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วข้อมูล 0.5 Mbps ขึ้นไป โดยปกติแล้วข้อกำหนดนี้จะเป็นไปตามการใช้เทคนิค GPS/GNSS แบบเสริมหรือแบบคาดการณ์รูปแบบต่างๆ เพื่อลดเวลาในการล็อก GPS/GNSS (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และข้อมูล Ephemeris/นาฬิกาของดาวเทียม)
    • [C-1-6] หลังจากคำนวณตำแหน่งดังกล่าวแล้ว การติดตั้งใช้งานอุปกรณ์ต้องระบุตำแหน่งของอุปกรณ์ในที่โล่งภายใน 5 วินาที เมื่อมีการเริ่มคําขอตำแหน่งอีกครั้ง ไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอครั้งต่อๆ ไปโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากปิด/เปิดเครื่อง

  • ในสภาวะท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยอัตราเร่งน้อยกว่า 1 เมตรต่อวินาทียกกำลัง 2 ให้ทำดังนี้

    • [C-1-3] ต้องระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วได้ภายใน 0.5 เมตรต่อวินาที อย่างน้อย 95% ของเวลา
    • [C-1-4] ต้องติดตามและรายงานผ่าน GnssStatus.Callback พร้อมกันอย่างน้อย 8 ดวงจากกลุ่มดาวหนึ่งๆ
    • ควรติดตามดาวเทียมอย่างน้อย 24 ดวงจากกลุ่มดาวหลายกลุ่มได้พร้อมกัน (เช่น GPS + Glonass, Beidou, Galileo อย่างใดอย่างหนึ่งอย่างน้อย 1 ดวง)
    • [C-SR] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ปกติผ่าน API ของผู้ให้บริการตำแหน่ง GNSS ต่อไปในระหว่างการโทรฉุกเฉิน
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
    • [C-SR] ขอแนะนําอย่างยิ่งให้รายงาน AGC และความถี่ในการวัด GNSS
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานความแม่นยำโดยประมาณทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวตั้ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานอัตราสัญญาณจำลองและอัตราสัญญาณจำลองของ GNSS ซึ่งในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลัง 2 จะเพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา

7.3.4. เครื่องวัดการหมุน

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใส่เซ็นเซอร์ Gyroscope เว้นแต่จะมีตัวตรวจวัดความเร่งแบบ 3 แกนรวมอยู่ด้วย

หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคปแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย
  • [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไปและควรมีความละเอียด 16 บิตขึ้นไป
  • [C-1-5] ต้องชดเชยอุณหภูมิ
  • [C-1-6] ต้องได้รับการสอบเทียบและชดเชยขณะใช้งาน และเก็บพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
  • [C-1-7] ต้องมีค่าความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) อนุญาตให้ความแปรปรวนเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของ Gyro ที่อัตราตัวอย่าง 1 Hz ค่าดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
  • [SR] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการสอบเทียบต้องน้อยกว่า 0.01 rad/s เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • ควรรายงานเหตุการณ์อย่างน้อย 200 Hz

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุนแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องใช้เซ็นเซอร์แบบผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
  • [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

7.3.5. บารอมิเตอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใส่บารอมิเตอร์ (เซ็นเซอร์ความกดอากาศรอบข้าง)

หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_PRESSURE
  • [C-1-2] ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
  • [C-1-3] ต้องชดเชยอุณหภูมิ
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานการวัดความดันได้ในช่วง 300hPa ถึง 1100hPa
  • ควรมีความแม่นยำสัมบูรณ์ 1hPa
  • ควรมีความแม่นยำสัมพัทธ์ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความแม่นยำประมาณ 1 เมตรเมื่อการเปลี่ยนแปลงอยู่ที่ประมาณ 200 เมตรที่ระดับน้ำทะเล)

7.3.6. เทอร์โมมิเตอร์

การติดตั้งใช้งานอุปกรณ์

  • อาจรวมเครื่องวัดอุณหภูมิแวดล้อม (เซ็นเซอร์อุณหภูมิ)
  • อาจรวมแต่ไม่ควรจะรวมเซ็นเซอร์อุณหภูมิ CPU

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดอุณหภูมิรอบตัว (เซ็นเซอร์อุณหภูมิ) อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องกำหนดเป็น SENSOR_TYPE_AMBIENT_TEMPERATURE และต้องวัดอุณหภูมิรอบข้าง (ห้อง/ห้องโดยสารของยานพาหนะ) จากจุดที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส
  • [C-1-2] ต้องกำหนดเป็น SENSOR_TYPE_TEMPERATURE
  • [C-1-3] ต้องวัดอุณหภูมิของ CPU ของอุปกรณ์
  • [C-1-4] ต้องไม่วัดอุณหภูมิอื่นๆ

โปรดทราบว่าประเภทเซ็นเซอร์ SENSOR_TYPE_TEMPERATURE ถูกเลิกใช้งานใน Android 4.0

7.3.7. โฟโตมิเตอร์

  • การติดตั้งใช้งานอุปกรณ์อาจรวมถึงโฟโตมิเตอร์ (เซ็นเซอร์แสงแวดล้อม)

7.3.8. พร็อกซิมิตีเซ็นเซอร์

  • การติดตั้งใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-1-1] ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกับหน้าจอ กล่าวคือ เซ็นเซอร์ตรวจจับบุคคลในบริเวณใกล้เคียงต้องอยู่ในแนวที่จะตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากวัตถุประสงค์หลักของเซ็นเซอร์ประเภทนี้คือการตรวจจับโทรศัพท์ที่ผู้ใช้กำลังใช้อยู่ หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวอื่น อุปกรณ์ต้องเข้าถึงผ่าน API นี้ไม่ได้
  • [C-1-2] ต้องมีความละเอียด 1 บิตขึ้นไป

7.3.9. เซ็นเซอร์ความแม่นยำสูง

หากการติดตั้งใช้งานอุปกรณ์มีชุดเซ็นเซอร์คุณภาพสูงขึ้นตามที่ระบุไว้ในส่วนนี้ และทำให้เซ็นเซอร์ดังกล่าวพร้อมใช้งานสำหรับแอปของบุคคลที่สาม แอปดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องระบุความสามารถผ่าน Flag ฟีเจอร์ android.hardware.sensor.hifi_sensors

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.sensor.hifi_sensors อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องมีเซ็นเซอร์ TYPE_ACCELEROMETER ซึ่งมีลักษณะดังนี้

    • ต้องมีช่วงการวัดระหว่าง -8 ถึง +8 กรัมเป็นอย่างน้อย ควรมีช่วงการวัดระหว่าง -16 ถึง +16 กรัมเป็นอย่างน้อย
    • ต้องมีความละเอียดการวัดอย่างน้อย 2048 LSB/g
    • ต้องมีความถี่การวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่การวัดสูงสุด 400 Hz ขึ้นไป ควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนการวัดไม่เกิน 400 μg/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์ของเซ็นเซอร์
    • ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ไม่เกิน 3 mW
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนสีขาวภายในแบนด์วิดท์นี้
    • ควรมีการเดินแบบสุ่มของอัตราเร่งน้อยกว่า 30 μg √Hz ที่ทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 1 mg/°C
    • ควรมีความไม่เป็นเชิงเส้นของเส้นที่พอดีที่สุดไม่เกิน 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิไม่เกิน 0.03%/C°
    • ควรมีความไวในแนวทแยงน้อยกว่า 2.5 % และมีความผันผวนของความไวในแนวทแยงน้อยกว่า 0.2% ในอุณหภูมิที่อุปกรณ์ทำงานได้

  • [C-2-2] ต้องมี TYPE_ACCELEROMETER_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_ACCELEROMETER

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่งมีลักษณะดังนี้

    • ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
    • ต้องมีความละเอียดการวัดอย่างน้อย 16 LSB/dps
    • ต้องมีความถี่การวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่การวัดสูงสุด 400 Hz ขึ้นไป ควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนการวัดไม่เกิน 0.014°/วินาที/√Hz
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนสีขาวภายในแบนด์วิดท์นี้
    • ควรมีการสุ่มเดินของอัตราน้อยกว่า 0.001 °/s √Hz ที่ทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 0.05 °/ วินาที / °C
    • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิไม่เกิน 0.02% / °C
    • ควรมีค่าความไม่เป็นเชิงเส้นของเส้นค่าดีที่สุดไม่เกิน 0.2%
    • ควรมีความหนาแน่นของสัญญาณรบกวนไม่เกิน 0.007 °/s/√Hz
    • ควรมีข้อผิดพลาดในการสอบเทียบน้อยกว่า 0.002 rad/s ในอุณหภูมิช่วง 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่
    • ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 0.1°/วินาที/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 ถึง 1,100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่การวัดขั้นต่ำ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่การวัดสูงสุด 10 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนการวัดไม่เกิน 2 Pa/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์ของเซ็นเซอร์
    • ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ไม่เกิน 2 mW
  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
  • [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่งมีลักษณะดังนี้
    • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 1.5 mW เมื่ออุปกรณ์เคลื่อนไหว
  • [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์ของเซ็นเซอร์
    • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 1.5 mW เมื่ออุปกรณ์เคลื่อนไหว
    • ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ดีกว่า 4 mW
  • [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่งมีลักษณะดังนี้
    • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 1.5 mW เมื่ออุปกรณ์เคลื่อนไหว
  • [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 1.5 mW เมื่ออุปกรณ์เคลื่อนไหว
  • [C-2-13] การประทับเวลาของเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่ง กริดโรส และแม่เหล็กไฟฟ้าต้องอยู่ในช่วง 2.5 มิลลิวินาทีจากกัน การประทับเวลาเหตุการณ์ของเหตุการณ์จริงเดียวกันที่รายงานโดยเครื่องวัดความเร่งและไจโรสโคปควรอยู่ภายใน 0.25 มิลลิวินาที
  • [C-2-14] ต้องมีการประทับเวลาเหตุการณ์ของเซ็นเซอร์ Gyroscope บนฐานเวลาเดียวกับระบบย่อยของกล้องและมีความผิดพลาดไม่เกิน 1 มิลลิวินาที
  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์ทางกายภาพข้างต้นไปยังแอปพลิเคชัน
  • [C-2-16] ต้องไม่ใช้พลังงานมากกว่า 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 2.0 mW เมื่ออุปกรณ์เคลื่อนไหวเมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมี ต้องมีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 100 รายการ

โปรดทราบว่าข้อกำหนดทั้งหมดเกี่ยวกับการบริโภคพลังงานในส่วนนี้ไม่รวมการบริโภคพลังงานของหน่วยประมวลผลแอปพลิเคชัน ซึ่งรวมพลังงานที่ดึงมาจากทั้งโซ่เซ็นเซอร์ ไม่ว่าจะเป็นเซ็นเซอร์เอง วงจรสนับสนุน ระบบการประมวลผลเซ็นเซอร์เฉพาะ ฯลฯ

หากการติดตั้งใช้งานอุปกรณ์มีการรองรับเซ็นเซอร์โดยตรง อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องประกาศการรองรับประเภทช่องทางโดยตรงและระดับอัตรารายงานโดยตรงอย่างถูกต้องผ่าน isDirectChannelTypeSupported และ getHighestDirectReportRateLevel API
  • [C-3-2] ต้องรองรับช่องทางโดยตรงของเซ็นเซอร์อย่างน้อย 1 ใน 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศรองรับช่องทางโดยตรงของเซ็นเซอร์
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สําหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุก) ประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. เซ็นเซอร์ไบโอเมตริก

ดูข้อมูลเบื้องต้นเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยในการปลดล็อกด้วยข้อมูลไบโอเมตริกได้ที่เอกสารประกอบเกี่ยวกับการวัดความปลอดภัยด้านข้อมูลไบโอเมตริก

หากการใช้งานอุปกรณ์มีการล็อกหน้าจอที่ปลอดภัย อุปกรณ์จะมีลักษณะดังนี้

  • ควรมีเซ็นเซอร์ไบโอเมตริก

เซ็นเซอร์ข้อมูลไบโอเมตริกสามารถแบ่งออกเป็น มีประสิทธิภาพสูง มีประสิทธิภาพต่ำ หรือสะดวก โดยอิงตามอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่น และความปลอดภัยของไปป์ไลน์ข้อมูลไบโอเมตริก การจัดประเภทนี้กำหนดความสามารถที่เซ็นเซอร์ไบโอเมตริกมีต่ออินเทอร์เฟซกับแพลตฟอร์มและแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์จะจัดอยู่ในประเภทความสะดวกโดยค่าเริ่มต้น และต้องเป็นไปตามข้อกำหนดเพิ่มเติมตามที่ระบุไว้ด้านล่างหากต้องการจัดอยู่ในประเภทอ่อนหรือแรง ทั้งข้อมูลไบโอเมตริกที่ไม่รัดกุมและรัดกุมจะมีความสามารถเพิ่มเติมตามที่ระบุไว้ด้านล่าง

วิธีทำให้เซ็นเซอร์ไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกที่มีประสิทธิภาพสูงหรือมีประสิทธิภาพต่ำตามที่ระบุไว้ในเอกสารนี้

วิธีอนุญาตให้แอปพลิเคชันของบุคคลที่สามหรือการติดตั้งใช้งานอุปกรณ์เข้าถึงคีย์สโตร์

  • [C-0-2] ต้องเป็นไปตามข้อกำหนดสำหรับแข็งแกร่งตามที่ระบุไว้ในเอกสารนี้

นอกจากนี้

  • [C-0-3] ต้องจับคู่กับการดำเนินการยืนยันอย่างชัดแจ้ง (เช่น การกดปุ่ม) หากข้อมูลไบโอเมตริกที่มีประสิทธิภาพสูงนั้นเป็นแบบพาสซีฟ (เช่น ใบหน้าหรือม่านตาที่ไม่มีสัญญาณที่ชัดเจนเกี่ยวกับความตั้งใจของผู้ใช้)
    • [C-SR] ขอแนะนำอย่างยิ่งให้ดำเนินการยืนยันสำหรับข้อมูลไบโอเมตริกแบบพาสซีฟให้ปลอดภัยเพื่อป้องกันไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่บุกรุกสามารถปลอมแปลงการดำเนินการดังกล่าวได้ ตัวอย่างเช่น การดำเนินการยืนยันโดยอิงตามปุ่มจริงจะกำหนดเส้นทางผ่านขาอินพุต/เอาต์พุต (GPIO) อเนกประสงค์สำหรับอินพุตเท่านั้นขององค์ประกอบที่ปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นนอกเหนือจากการกดปุ่มจริง

หากการติดตั้งใช้งานอุปกรณ์ต้องการใช้เซ็นเซอร์ไบโอเมตริกเป็นความสะดวก อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่าการใช้ PIN, รูปแบบ หรือรหัสผ่านที่รัดกุม และระบุความเสี่ยงของการเปิดใช้อย่างชัดเจน หากอัตราการยอมรับการปลอมแปลงและตัวตนปลอมสูงกว่า 7%
  • [C-1-3] ต้องจำกัดอัตราการพยายามเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดสอบที่ไม่สำเร็จ 5 ครั้งสำหรับการยืนยันข้อมูลไบโอเมตริก โดยที่การทดสอบที่ไม่สำเร็จคือคุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) แต่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-1-4] ต้องป้องกันไม่ให้เพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างเชนความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบใหม่ของอุปกรณ์ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การใช้งานโปรเจ็กต์โอเพนซอร์ส Android มีกลไกในเฟรมเวิร์กสำหรับดำเนินการดังกล่าว
  • [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ทั้งหมดของผู้ใช้ออกอย่างสมบูรณ์เมื่อนำบัญชีของผู้ใช้ออก (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
  • [C-1-6] ต้องปฏิบัติตามการแจ้งแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้น (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS )
  • [C-1-7] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 24 ชั่วโมงหรือน้อยกว่านั้นสำหรับอุปกรณ์ใหม่ที่เปิดตัวด้วย Android เวอร์ชัน 10 ทุก 72 ชั่วโมงหรือน้อยกว่านั้นสำหรับอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันเก่า

  • [C-1-8] ต้องกำหนดให้ผู้ใช้ดำเนินการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากเกิดเหตุการณ์อย่างใดอย่างหนึ่งต่อไปนี้

    • ระยะเวลาหมดเวลาในกรณีที่ไม่มีการใช้งาน 4 ชั่วโมง หรือ
    • พยายามตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่สำเร็จ 3 ครั้ง
    • ระบบจะรีเซ็ตระยะเวลาหมดเวลาในกรณีที่ไม่มีการใช้งานและจำนวนการตรวจสอบสิทธิ์ที่ไม่สำเร็จหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์เรียบร้อยแล้ว

    การอัปเกรดอุปกรณ์จาก Android เวอร์ชันเก่าจะได้รับการยกเว้นจาก C-1-8

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% โดยวัดจากอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเวลาที่ตรวจพบข้อมูลไบโอเมตริกจนกว่าระบบจะปลดล็อกหน้าจอสำหรับข้อมูลไบโอเมตริกที่ลงทะเบียนแต่ละรายการ

หากการติดตั้งใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นไม่ปลอดภัย อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดสำหรับความสะดวกข้างต้น ยกเว้น [C-1-2]
  • [C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวตนปลอมไม่เกิน 20%
  • [C-2-3] ต้องมีการใช้งานคีย์สโตร์ที่รองรับฮาร์ดแวร์ และทำการจับคู่ข้อมูลไบโอเมตริกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหากนอกพื้นที่ผู้ใช้หรือเคอร์เนลของ Android เช่น Trusted Execution Environment (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
  • [C-2-4] ข้อมูลทั้งหมดที่ระบุตัวบุคคลนั้นได้ต้องได้รับการเข้ารหัสและตรวจสอบสิทธิ์ด้วยวิทยาการเข้ารหัส เพื่อไม่ให้มีบุคคลอื่นรับ อ่าน หรือแก้ไขข้อมูลดังกล่าวได้นอกสภาพแวดล้อมการทํางานที่แยกส่วนหรือชิปที่มีแชแนลที่ปลอดภัยไปยังสภาพแวดล้อมการทํางานที่แยกส่วนตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
  • [C-2-5] สำหรับข้อมูลไบโอเมตริกจากกล้อง ขณะที่มีการตรวจสอบสิทธิ์หรือการลงทะเบียนโดยใช้ข้อมูลไบโอเมตริก ระบบจะดำเนินการดังนี้
    • ต้องใช้งานกล้องในโหมดที่ป้องกันไม่ให้อ่านหรือแก้ไขเฟรมกล้องจากภายนอกสภาพแวดล้อมการเรียกใช้แบบแยกหรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการเรียกใช้แบบแยก
    • สำหรับโซลูชันกล้อง RGB แบบกล้องเดียว เฟรมของกล้องจะอ่านได้นอกสภาพแวดล้อมการเรียกใช้แบบแยกเพื่อรองรับการดำเนินการต่างๆ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่ต้องยังคงแก้ไขไม่ได้
  • [C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างการลงทะเบียนข้อมูลไบโอเมตริกแต่ละรายการ
  • [C-2-7] ต้องไม่อนุญาตให้ Application Processor เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลนั้นได้หรือข้อมูลที่มาจากข้อมูลดังกล่าว (เช่น ข้อมูลฝัง) นอกบริบทของ TEE โดยไม่มีการเข้ารหัส

  • [C-2-8] ต้องมีไปป์ไลน์การประมวลผลที่ปลอดภัยเพื่อให้ระบบปฏิบัติการหรือเคอร์เนลที่บุกรุกไม่สามารถแทรกข้อมูลได้โดยตรงเพื่อตรวจสอบสิทธิ์เป็นผู้ใช้โดยที่ผู้ใช้ไม่รู้ตัว

    หากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้วและไม่สามารถปฏิบัติตามข้อกำหนด C-2-8 ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ข้อมูลไบโอเมตริกเป็นรัดกุม อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-3-1] ต้องมีคุณสมบัติตรงตามข้อกำหนดทั้งหมดของอ่อนด้านบน การอัปเกรดอุปกรณ์จาก Android เวอร์ชันเก่าๆ จะไม่ได้รับการยกเว้นจาก C-2-7
  • [C-3-2] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวตนปลอมไม่เกิน 7%
  • [C-3-3] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น

7.3.12. เซ็นเซอร์ท่าทาง

การติดตั้งใช้งานอุปกรณ์

  • อาจรองรับเซ็นเซอร์ท่าทางที่มี 6 องศาอิสระ

หากการติดตั้งใช้งานอุปกรณ์รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 องศา อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-1-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_POSE_6DOF
  • [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

7.4. การเชื่อมต่อข้อมูล

7.4.1. โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจใช้หรือไม่ได้ใช้การเปลี่ยนแพ็กเก็ต แต่ Android จะถือว่าการโทรเหล่านี้ไม่เกี่ยวข้องกับการเชื่อมต่อข้อมูลใดๆ ที่อาจใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันการทำงานและ API "โทรศัพท์" ของ Android หมายถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่โทรออกหรือส่ง/รับข้อความ SMS ไม่ได้จะไม่ถือว่าเป็นอุปกรณ์โทรคมนาคม ไม่ว่าจะใช้เครือข่ายมือถือเพื่อการเชื่อมต่อข้อมูลหรือไม่ก็ตาม

  • Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการติดตั้งใช้งานอุปกรณ์มีโทรศัพท์ GSM หรือ CDMA อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony และ Flag ฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องรองรับ API ของเทคโนโลยีนั้นอย่างเต็มรูปแบบ

หากการติดตั้งใช้งานอุปกรณ์ไม่รวมฮาร์ดแวร์โทรศัพท์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-2-1] ต้องติดตั้งใช้งาน API แบบเต็มแบบไม่ต้องดำเนินการใดๆ

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมการ์ดแบบฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามสามารถใช้ฟังก์ชันการทำงานของ eSIM ได้ นักพัฒนาแอปบุคคลที่สามจะต้องดำเนินการดังนี้

  • [C-3-1] ต้องติดตั้งใช้งาน EuiccManager API ให้เสร็จสมบูรณ์
7.4.1.1. ความเข้ากันได้ของการบล็อกหมายเลข

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony feature อุปกรณ์จะดำเนินการดังนี้

  • [C-1-1] ต้องรองรับการบล็อกหมายเลข
  • [C-1-2] ต้องใช้งาน BlockedNumberContract และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-3] ต้องบล็อกสายเรียกเข้าและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยไม่ต้องโต้ตอบกับแอป ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-4] ต้องไม่เขียนไปยังผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสําหรับสายที่บล็อก
  • [C-1-5] ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่ถูกบล็อก
  • [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่บล็อก ซึ่งเปิดขึ้นด้วย Intent ที่แสดงผลโดยเมธอด TelecomManager.createManageBlockedNumbersIntent()
  • [C-1-7] ต้องไม่อนุญาตให้ผู้ใช้รองดูหรือแก้ไขหมายเลขที่บล็อกในอุปกรณ์ เนื่องจากแพลตฟอร์ม Android จะถือว่าผู้ใช้หลักมีสิทธิ์ควบคุมบริการโทรศัพท์แบบอินสแตนซ์เดียวในอุปกรณ์อย่างเต็มรูปแบบ UI ทั้งหมดที่เกี่ยวข้องกับการบล็อกต้องซ่อนไว้สําหรับผู้ใช้รอง และระบบต้องยังคงใช้รายการที่บล็อกอยู่
  • ควรย้ายข้อมูลหมายเลขที่บล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0
7.4.1.2. Telecom API

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับ ConnectionService API ที่อธิบายไว้ใน SDK
  • [C-1-2] ต้องแสดงสายเรียกเข้าสายใหม่และมอบโอกาสให้ผู้ใช้ยอมรับหรือปฏิเสธสายเรียกเข้าเมื่อผู้ใช้กำลังอยู่ในสายที่โทรเข้ามาโดยแอปของบุคคลที่สามที่ไม่รองรับฟีเจอร์การพักสายที่ระบุผ่าน CAPABILITY_SUPPORT_HOLD
  • [C-1-3] ต้องมีแอปพลิเคชันที่ติดตั้งใช้งาน InCallService

  • [C-SR] ขอแนะนำอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบว่าการตอบสายเรียกเข้าจะเป็นการตัดสายที่โทรอยู่

    การใช้งาน AOSP เป็นไปตามข้อกำหนดเหล่านี้ด้วยการแจ้งเตือนล่วงหน้าซึ่งแจ้งให้ผู้ใช้ทราบว่าการตอบสายเรียกเข้าจะทำให้สายอื่นถูกตัดการเชื่อมต่อ

  • [C-SR] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรออกเริ่มต้นที่แสดงรายการบันทึกการโทรและชื่อแอปของบุคคลที่สามในบันทึกการโทรไว้ล่วงหน้า เมื่อแอปของบุคคลที่สามตั้งค่าคีย์ extras 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] ต้องรายงาน Flag ฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
  • [C-1-3] ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-4] ต้องรองรับมัลติแคสต์ DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ในทุกช่วงเวลาของการทำงาน ซึ่งรวมถึงในกรณีต่อไปนี้
    • แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงาน
    • สำหรับการติดตั้งใช้งานอุปกรณ์ Android Television แม้ว่าจะอยู่ในสถานะพลังงานสแตนด์บาย
  • [C-1-5] ต้องไม่ถือว่าการเรียกเมธอด WifiManager.enableNetwork() API เป็นข้อบ่งชี้ที่เพียงพอในการเปลี่ยน Network ที่ใช้งานอยู่ในปัจจุบันซึ่งระบบใช้โดยค่าเริ่มต้นสำหรับการเข้าชมแอปพลิเคชันและแสดงผลโดยเมธอด ConnectivityManager API เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ ผู้ให้บริการอาจปิดใช้การเข้าถึงอินเทอร์เน็ตที่ให้บริการโดยผู้ให้บริการเครือข่ายรายอื่น (เช่น อินเทอร์เน็ตมือถือ) ได้ก็ต่อเมื่อตรวจสอบแล้วว่าเครือข่าย Wi-Fi ให้บริการอินเทอร์เน็ตได้
  • [C-1-6] ขอแนะนำอย่างยิ่งว่าเมื่อเรียกใช้เมธอด ConnectivityManager.reportNetworkConnectivity() API ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และเมื่อการประเมินระบุว่า Network ปัจจุบันไม่มีการเข้าถึงอินเทอร์เน็ตอีกต่อไป ให้เปลี่ยนไปใช้เครือข่ายอื่นที่พร้อมใช้งาน (เช่น อินเทอร์เน็ตมือถือ) ซึ่งให้การเข้าถึงอินเทอร์เน็ต
  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอการสำรวจ 1 ครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้งขณะที่ STA ไม่ได้เชื่อมต่อ
    • กลุ่มเฟรมคำขอตรวจสอบแต่ละกลุ่มที่ประกอบด้วยการสแกน 1 ครั้งควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงกลางการสแกน)
    • หมายเลขลำดับของคำขอตรวจสอบควรซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
    • หมายเลขลำดับคำขอการสำรวจควรสุ่มระหว่างคำขอการสำรวจสุดท้ายของการสแกนกับคำขอการสำรวจแรกของการสแกนถัดไป
  • [C-SR] ขอแนะนำอย่างยิ่งว่าขณะที่ STA ตัดการเชื่อมต่อ ให้อนุญาตเฉพาะองค์ประกอบต่อไปนี้ในเฟรมคำขอตรวจสอบ
    • ชุดพารามิเตอร์ SSID (0)
    • ชุดพารามิเตอร์ DS (3)

หากการติดตั้งใช้งานอุปกรณ์รองรับโหมดประหยัดพลังงานของ Wi-Fi ตามที่ระบุไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องปิดโหมดประหยัดพลังงานของ Wi-Fi เมื่อใดก็ตามที่แอปได้รับล็อก WIFI_MODE_FULL_HIGH_PERF หรือล็อก WIFI_MODE_FULL_LOW_LATENCY ผ่าน API WifiManager.createWifiLock() และ WifiManager.WifiLock.acquire() และล็อกดังกล่าวทำงานอยู่
  • [C-3-2] เวลาในการตอบสนองไป-กลับโดยเฉลี่ยระหว่างอุปกรณ์กับจุดเข้าใช้งานขณะที่อุปกรณ์อยู่ในโหมด Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) ต้องน้อยกว่าเวลาในการตอบสนองระหว่างที่อยู่ในโหมด Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF)
  • [C-SR] ขอแนะนําอย่างยิ่งให้ลดเวลาในการตอบสนองไป-กลับของ Wi-Fi เมื่อใดก็ตามที่การล็อกเวลาในการตอบสนองต่ำ (WIFI_MODE_FULL_LOW_LATENCY) ได้รับและมีผล

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi และใช้ Wi-Fi ในการสแกนหาตำแหน่ง อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องระบุการอำนวยความสะดวกให้ผู้ใช้เพื่อเปิด/ปิดใช้ค่าที่อ่านผ่านเมธอด WifiManager.isScanAlwaysAvailable API
7.4.2.1. Wi-Fi Direct

การติดตั้งใช้งานอุปกรณ์

  • ควรรองรับ Wi-Fi Direct (Wi-Fi แบบผู้ใช้ต่อผู้ใช้)

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องติดตั้งใช้งาน Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct
  • [C-1-3] ต้องรองรับการใช้งาน Wi-Fi ปกติ
  • [C-1-4] ต้องรองรับการใช้งาน Wi-Fi และ Wi-Fi Direct พร้อมกัน

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ TDLS และ WiFiManager API เปิดใช้ TDLS อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องประกาศการรองรับ TDLS ผ่าน WifiManager.isTdlsSupported
  • ควรใช้ TDLS เฉพาะเมื่อเป็นไปได้และมีประโยชน์เท่านั้น
  • ควรใช้การเรียนรู้เชิงสืบสวนบ้างและอย่าใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าใช้งาน Wi-Fi
7.4.2.3. Wi-Fi Aware

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Aware และแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม แอปดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องติดตั้งใช้งาน WifiAwareManager API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.wifi.aware
  • [C-1-3] ต้องรองรับการใช้งาน Wi-Fi และ Wi-Fi Aware พร้อมกัน
  • [C-1-4] ต้องสุ่มที่อยู่อินเทอร์เฟซการจัดการ Wi-Fi Aware เป็นระยะๆ ไม่เกิน 30 นาที และทุกครั้งที่เปิดใช้ Wi-Fi Aware

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Aware และตำแหน่ง Wi-Fi ตามที่อธิบายไว้ในส่วนที่ 7.4.2.5 และแสดงฟังก์ชันเหล่านี้ต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

7.4.2.4. Wi-Fi Passpoint

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Passpoint อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องติดตั้งใช้งาน WifiManager API ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นหาและการเลือกเครือข่าย เช่น Generic Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)

ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Wi-Fi Passpoint ให้ทำดังนี้

  • [C-2-1] การใช้งาน WifiManager API ที่เกี่ยวข้องกับ Passpoint จะต้องแสดง UnsupportedOperationException
7.4.2.5. ตำแหน่ง Wi-Fi (ระยะเวลารับส่งข้อมูลของ Wi-Fi - RTT)

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับตำแหน่ง Wi-Fi และแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องติดตั้งใช้งาน WifiRttManager API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.wifi.rtt
  • [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางของพัลส์ RTT แต่ละรายการที่ดำเนินการขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT ไม่ได้เชื่อมโยงกับจุดเข้าใช้งาน
7.4.2.6. การลดภาระ Keepalive ของ Wi-Fi

การติดตั้งใช้งานอุปกรณ์

  • ควรรองรับการโอนข้อมูล Keepalive ของ Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รองรับการโอนข้อมูลการคงการเชื่อมต่อ Wi-Fi ไว้ และแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม แอปเหล่านั้นจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรองรับ SocketKeepAlive API

  • [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi และสล็อต Keepalive อย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับการโอนข้อมูล Keepalive ของ Wi-Fi อุปกรณ์จะดำเนินการต่อไปนี้

7.4.2.7. Wi-Fi Easy Connect (Device Provisioning Protocol)

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Easy Connect และแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

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] ต้องเปิดใช้ Bluetooth API ที่ใช้ GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) ตามที่อธิบายไว้ในเอกสารประกอบของ 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()

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธ LE และโปรไฟล์เครื่องช่วยฟังตามที่อธิบายไว้ในการรองรับเสียงจากเครื่องช่วยฟังโดยใช้บลูทูธ LE อุปกรณ์จะมีคุณสมบัติดังนี้

7.4.4. Near Field Communication

การติดตั้งใช้งานอุปกรณ์

  • ควรมีตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near Field Communication (NFC)
  • [C-0-1] ต้องใช้งาน android.nfc.NdefMessage และ android.nfc.NdefRecord API แม้ว่าจะไม่รองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc เนื่องจากคลาสแสดงรูปแบบข้อมูลที่แยกจากโปรโตคอล

หากการติดตั้งใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC และวางแผนที่จะให้บริการแก่แอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
  • ต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้
  • [C-1-2] ต้องทําหน้าที่เป็นเครื่องอ่าน/เขียน NFC Forum ได้ (ตามที่ระบุไว้ในข้อกําหนดทางเทคนิค NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • แท็ก NFC Forum ประเภท 1, 2, 3, 4, 5 (กำหนดโดย NFC Forum)

  • [SR] ขอแนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC จะระบุไว้ว่า "แนะนำอย่างยิ่ง" แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความของความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" มาตรฐานเหล่านี้เป็นมาตรฐานที่ไม่บังคับในเวอร์ชันนี้ แต่จะเป็นมาตรฐานที่จำเป็นในเวอร์ชันในอนาคต เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้ตั้งแต่ตอนนี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้

  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC

  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอที่ใช้งานอยู่และหน้าจอล็อกที่ปลดล็อก
  • ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC แบบฟิล์มบางได้

โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่มีให้บริการสำหรับข้อกำหนด JIS, ISO และ NFC Forum ที่ระบุไว้ข้างต้น

Android รองรับโหมดการจําลองบัตรของโฮสต์ (HCE) ของ NFC

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทาง Application ID (AID) อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
  • [C-2-2] ต้องรองรับ NFC HCE API ตามที่ระบุไว้ใน Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE สำหรับ NfcF และใช้ฟีเจอร์ดังกล่าวกับแอปพลิเคชันของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hcef
  • [C-3-2] ต้องใช้ NfcF Card Emulation API ตามที่ระบุไว้ใน Android SDK

หากการติดตั้งใช้งานอุปกรณ์รองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทเครื่องอ่าน/เครื่องเขียน อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องติดตั้งใช้งาน Android API ที่เกี่ยวข้องตามที่ Android SDK ระบุไว้
  • [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจะไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5. ความสามารถขั้นต่ำของเครือข่าย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต และ 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) และ NDK API เช่น 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 แต่อาจใช้แบบไม่ดำเนินการก็ได้

7.4.8. องค์ประกอบความปลอดภัย

หากการติดตั้งใช้งานอุปกรณ์รองรับองค์ประกอบที่ปลอดภัยซึ่งสามารถใช้ Open Mobile API และทำให้องค์ประกอบดังกล่าวพร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องระบุรายการเครื่องมืออ่านองค์ประกอบที่ปลอดภัยที่มีอยู่เมื่อเรียกใช้เมธอด android.se.omapi.SEService.getReaders()

7.5 กล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.camera.any
  • [C-1-2] แอปพลิเคชันต้องจัดสรรบิตแมป RGBA_8888 3 รายการพร้อมกันได้ ซึ่งเท่ากับขนาดของภาพที่ผลิตโดยเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์ ขณะที่กล้องเปิดอยู่เพื่อวัตถุประสงค์ในการดูตัวอย่างขั้นพื้นฐานและการจับภาพนิ่ง
  • [C-1-3] ต้องตรวจสอบว่าแอปพลิเคชันกล้องเริ่มต้นที่ติดตั้งไว้ล่วงหน้าซึ่งจัดการ Intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE หรือ MediaStore.ACTION_VIDEO_CAPTURE มีหน้าที่นำตำแหน่งของผู้ใช้ในข้อมูลเมตาของรูปภาพออกก่อนที่จะส่งไปยังแอปพลิเคชันฝั่งที่รับเมื่อแอปพลิเคชันฝั่งที่รับไม่มี ACCESS_FINE_LOCATION

7.5.1. กล้องหลัง

กล้องหลังคือกล้องที่อยู่ด้านข้างของอุปกรณ์ซึ่งอยู่ตรงข้ามกับจอแสดงผล กล่าวคือ กล้องจะจับภาพฉากที่อยู่ด้านไกลของอุปกรณ์ เช่นเดียวกับกล้องแบบดั้งเดิม

การติดตั้งใช้งานอุปกรณ์

  • ควรมีกล้องหลัง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหลังอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงาน Flag ฟีเจอร์ android.hardware.camera และ android.hardware.camera.any
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย 2 ล้านพิกเซล
  • ควรมีการใช้โฟกัสอัตโนมัติของฮาร์ดแวร์หรือโฟกัสอัตโนมัติของซอฟต์แวร์ในไดรเวอร์กล้อง (ซอฟต์แวร์แอปพลิเคชันทำงานได้แบบโปร่งใส)
  • อาจใช้ฮาร์ดแวร์แบบโฟกัสคงที่หรือ EDOF (ระยะชัดลึกแบบขยาย)
  • อาจใช้แฟลช

หากกล้องมีแฟลช ให้ทำดังนี้

  • [C-2-1] หลอดแฟลชต้องไม่ติดสว่างขณะที่ลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback บนแพลตฟอร์มแสดงตัวอย่างของกล้อง เว้นแต่แอปพลิเคชันจะเปิดใช้แฟลชอย่างชัดเจนโดยเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของออบเจ็กต์ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องระบบในตัวของอุปกรณ์ แต่จะมีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้ Camera.PreviewCallback เท่านั้น

7.5.2. กล้องหน้า

กล้องด้านหน้าคือกล้องที่อยู่ด้านเดียวกับจอแสดงผลของอุปกรณ์ ซึ่งก็คือกล้องที่มักใช้ถ่ายภาพผู้ใช้ เช่น สำหรับการประชุมทางวิดีโอและแอปพลิเคชันอื่นๆ ที่คล้ายกัน

การติดตั้งใช้งานอุปกรณ์

  • อาจรวมกล้องหน้า

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงาน Flag ฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
  • [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเดียวในอุปกรณ์ก็ตาม
  • [C-1-4] ภาพตัวอย่างจากกล้องต้องแสดงแบบสะท้อนในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุไว้เมื่อแอปพลิเคชันปัจจุบันส่งคำขออย่างชัดเจนให้หมุนการแสดงผลของกล้องผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน พรีวิวต้องแสดงแบบมิเรอร์ตามแนวแกนนอนเริ่มต้นของอุปกรณ์เมื่อแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนการแสดงผลของกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation()
  • [C-1-5] ต้องไม่มิเรอร์ภาพนิ่งหรือสตรีมวิดีโอที่บันทึกไว้ขั้นสุดท้ายซึ่งส่งกลับไปยังการเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ
  • [C-1-6] ต้องมีภาพมิเรอร์ที่แสดงโดยฟีเจอร์ดูตัวอย่างโพสต์ในลักษณะเดียวกับสตรีมรูปภาพตัวอย่างของกล้อง
  • อาจรวมฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่มีให้ใช้งานกับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

หากผู้ใช้สามารถหมุนการติดตั้งใช้งานอุปกรณ์ได้ (เช่น โดยอัตโนมัติผ่านเครื่องวัดความเร่งหรือด้วยตนเองผ่านการป้อนข้อมูลของผู้ใช้) ให้ทำดังนี้

  • [C-2-1] ภาพตัวอย่างจากกล้องต้องปรับให้เหมือนภาพในกระจกในแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์

7.5.3. กล้องภายนอก

การติดตั้งใช้งานอุปกรณ์

  • อาจรองรับกล้องภายนอกที่ไม่จำเป็นต้องเชื่อมต่ออยู่เสมอ

หากการติดตั้งใช้งานอุปกรณ์รองรับกล้องภายนอก อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์แพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
  • [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ตโฮสต์ USB
  • [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องโดยเชื่อมต่ออุปกรณ์กล้องภายนอก รายละเอียดการทดสอบ CTS ของกล้องมีอยู่ที่ source.android.com
  • ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้โอนสตรีมคุณภาพสูงที่ไม่ได้เข้ารหัสได้ (เช่น สตรีมรูปภาพที่ไม่มีการบีบอัดหรือบีบอัดแยกต่างหาก)
  • อาจรองรับกล้องหลายตัว
  • อาจรองรับการเข้ารหัสวิดีโอจากกล้อง

หากรองรับการเข้ารหัสวิดีโอจากกล้อง ให้ทำดังนี้

  • [C-2-1] การใช้งานอุปกรณ์ต้องเข้าถึงสตรีม MJPEG / ที่ไม่ได้เข้ารหัสพร้อมกันได้ (ความละเอียด QVGA ขึ้นไป)

7.5.4. ลักษณะการทํางานของ Camera API

Android มีแพ็กเกจ API 2 รายการสําหรับเข้าถึงกล้อง โดย android.hardware.camera2 API เวอร์ชันใหม่จะแสดงการควบคุมกล้องในระดับล่างให้กับแอป รวมถึงโฟลว์การถ่ายแบบต่อเนื่อง/สตรีมมิงแบบไม่ใช้การคัดลอกข้อมูลอย่างมีประสิทธิภาพ และการควบคุมการรับแสง อัตราขยาย อัตราขยายของการปรับสมดุลสีขาว การเปลี่ยนสี การตัดเสียงรบกวน การปรับความคมชัด และอื่นๆ ต่อเฟรม

แพ็กเกจ API เก่าอย่าง android.hardware.Camera มีสถานะ "เลิกใช้งานแล้ว" ใน Android 5.0 แต่ควรจะยังคงพร้อมให้แอปใช้งาน การติดตั้งใช้งานอุปกรณ์ Android ต้องรองรับ API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK

ฟีเจอร์ทั้งหมดที่เหมือนกันระหว่างคลาส android.hardware.Camera ที่เลิกใช้งานแล้วกับแพ็กเกจ android.hardware.camera2 ที่ใหม่กว่าต้องมีประสิทธิภาพและคุณภาพเทียบเท่ากันในทั้ง 2 API เช่น เมื่อใช้การตั้งค่าที่เทียบเท่ากัน ความเร็วและความแม่นยำของระบบโฟกัสอัตโนมัติต้องเหมือนกัน และคุณภาพของภาพที่ถ่ายต้องเหมือนกัน ฟีเจอร์ที่ขึ้นอยู่กับความหมายที่แตกต่างกันของ 2 API ไม่จำเป็นต้องมีความเร็วหรือคุณภาพที่ตรงกัน แต่ควรตรงกันมากที่สุด

การติดตั้งใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สําหรับ API ที่เกี่ยวข้องกับกล้องสําหรับกล้องทั้งหมดที่ใช้ได้ การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ส่งไปยังการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียก android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องเป็นรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบพรีวิวคือ YCbCr_420_SP ข้อมูลใน byte[] ที่ส่งไปยัง onPreviewFrame() กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
  • [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างของกล้องทั้งกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (โปรแกรมเปลี่ยนไฟล์วิดีโอและกล้องฮาร์ดแวร์อาจใช้รูปแบบพิกเซลเดิมใดก็ได้ แต่การติดตั้งใช้งานอุปกรณ์ต้องรองรับการเปลี่ยนเป็น YV12)
  • [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่โฆษณาความสามารถ 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.camera2.CaptureRequest ในทางกลับกัน การติดตั้งใช้งานอุปกรณ์ต้องไม่ยอมรับหรือรู้จักค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ใน android.hardware.Camera.Parameters กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และจะต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการถ่ายภาพแบบ High Dynamic Range (HDR) จะต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR
  • [C-0-7] ต้องรายงานระดับการสนับสนุนที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK และรายงานFlag ฟีเจอร์ของเฟรมเวิร์กที่เหมาะสม
  • [C-0-8] และต้องประกาศความสามารถของกล้องแต่ละรายการของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศFlag ฟีเจอร์ที่เหมาะสม และต้องกำหนด Flag ฟีเจอร์หากอุปกรณ์กล้องที่แนบมารองรับฟีเจอร์ดังกล่าว
  • [C-0-9] ต้องออกอากาศ Intent Camera.ACTION_NEW_PICTURE ทุกครั้งที่กล้องถ่ายภาพใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ
  • [C-0-10] ต้องออกอากาศ Intent Camera.ACTION_NEW_VIDEO ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ
  • [C-0-11] กล้องทั้งหมดต้องเข้าถึงได้ผ่าน android.hardware.Camera API ที่เลิกใช้งานแล้ว และเข้าถึงได้ผ่าน android.hardware.camera2 API ด้วย
  • [C-SR] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัวซึ่งหันไปในทิศทางเดียวกัน ขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องแบบลอจิคที่แสดงความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปในทิศทางนั้นๆ เป็นอุปกรณ์ย่อยจริง

หากการติดตั้งใช้งานอุปกรณ์มี Camera API ที่เป็นกรรมสิทธิ์ให้กับแอปของบุคคลที่สาม แอปเหล่านั้นจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องใช้ Camera API ดังกล่าวโดยใช้ android.hardware.camera2 API
  • อาจระบุแท็กและ/หรือส่วนขยายของผู้ให้บริการใน android.hardware.camera2 API

7.5.5. การวางแนวของกล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าวต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องจัดวางให้แนวยาวของกล้องสอดคล้องกับแนวยาวของหน้าจอ กล่าวคือ เมื่อถืออุปกรณ์ในแนวนอน กล้องต้องจับภาพในแนวนอน การตั้งค่านี้มีผลไม่ว่าอุปกรณ์จะวางในแนวใดก็ตาม กล่าวคือ มีผลกับอุปกรณ์ที่แสดงแนวนอนเป็นหลักและอุปกรณ์ที่แสดงแนวตั้งเป็นหลัก

7.6. หน่วยความจำและพื้นที่เก็บข้อมูล

7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีตัวจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล และต้องสามารถดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้น

7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องให้บริการพื้นที่เก็บข้อมูลสำหรับแอปพลิเคชันต่างๆ ร่วมกัน ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์" หรือเส้นทาง Linux "/sdcard" ที่ติดตั้ง
  • [C-0-2] ต้องกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งติดตั้งโดยค่าเริ่มต้น หรือที่เรียกว่า "พร้อมใช้งานทันที" ไม่ว่าพื้นที่เก็บข้อมูลจะใช้กับคอมโพเนนต์พื้นที่เก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดออกได้ (เช่น ช่องการ์ด Secure Digital) ก็ตาม
  • [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันโดยตรงในเส้นทาง Linux sdcard หรือใส่ลิงก์สัญลักษณ์ Linux จาก sdcard ไปยังจุดต่อเชื่อมจริง
  • [C-0-4] ต้องบังคับใช้สิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ในพื้นที่เก็บข้อมูลที่แชร์นี้ตามที่ระบุไว้ใน SDK
  • [C-0-5] ต้องเปิดใช้พื้นที่เก็บข้อมูลแบบจำกัดโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กำหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในสถานการณ์ต่อไปนี้
    • เมื่อติดตั้งแอปก่อนที่อุปกรณ์จะอัปเกรดเป็น API ระดับ 29 โดยไม่คำนึงถึง API เป้าหมายของแอป
    • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
    • เมื่อแอปได้รับสิทธิ์ android.permission.WRITE_MEDIA_STORAGE
  • [C-0-6] ต้องบังคับใช้ว่าแอปที่เปิดใช้พื้นที่เก็บข้อมูลแบบจำกัดจะไม่มีสิทธิ์เข้าถึงระบบไฟล์โดยตรงสำหรับไฟล์ที่อยู่นอกไดเรกทอรีเฉพาะแอปพลิเคชันตามที่แสดงผลโดยเมธอด Context API เช่น เมธอด Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() และ Context.getObbDirs()
  • [C-0-7] ต้องปกปิดข้อมูลเมตาตำแหน่ง เช่น แท็ก GPS Exif ที่เก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore ยกเว้นในกรณีที่แอปที่โทรมีสิทธิ์ ACCESS_MEDIA_LOCATION

การติดตั้งใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้

  • พื้นที่เก็บข้อมูลที่ถอดออกได้ซึ่งผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
  • พื้นที่เก็บข้อมูลภายใน (แบบถอดออกไม่ได้) บางส่วนตามที่ติดตั้งใช้งานในโปรเจ็กต์โอเพนซอร์ส Android (AOSP)

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดออกได้เพื่อปฏิบัติตามข้อกำหนดข้างต้น อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องใช้อินเทอร์เฟซผู้ใช้แบบป๊อปอัปหรือแบบแสดงเป็นข้อความแจ้งเตือนผู้ใช้เมื่อไม่มีใส่สื่อเก็บข้อมูลไว้ในช่อง
  • [C-1-2] ต้องมีสื่อบันทึกข้อมูลที่ฟอร์แมต FAT (เช่น การ์ด SD) หรือแสดงบนกล่องและสื่ออื่นๆ ที่มีในขณะซื้อว่าต้องซื้อสื่อบันทึกข้อมูลแยกต่างหาก

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดออกไม่ได้บางส่วนเพื่อให้เป็นไปตามข้อกำหนดข้างต้น อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายในตาม AOSP
  • อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

หากการติดตั้งใช้งานอุปกรณ์มีเส้นทางพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายเส้นทาง (เช่น ทั้งช่องเสียบการ์ด SD และพื้นที่เก็บข้อมูลภายในที่ใช้ร่วมกัน) อุปกรณ์จะดำเนินการดังนี้

  • [C-2-1] ต้องอนุญาตให้เฉพาะแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าและมีสิทธิ์ที่มีสิทธิ์ WRITE_MEDIA_STORAGE ในการเขียนลงในพื้นที่เก็บข้อมูลภายนอกรอง ยกเว้นเมื่อเขียนลงในไดเรกทอรีเฉพาะแพ็กเกจหรือภายใน URI ที่แสดงผลจากการเรียกใช้ Intent ACTION_OPEN_DOCUMENT_TREE
  • [C-2-2] ต้องกำหนดให้สิทธิ์เข้าถึงโดยตรงที่เชื่อมโยงกับสิทธิ์ android.permission.WRITE_MEDIA_STORAGE มอบให้กับแอปที่ผู้ใช้มองเห็นได้ก็ต่อเมื่อมีการมอบสิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ด้วย
  • [SR] ขอแนะนำอย่างยิ่งว่าแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าและมีสิทธิ์ควรใช้ API สาธารณะ เช่น MediaStore เพื่อโต้ตอบกับอุปกรณ์เก็บข้อมูลแทนการอาศัยสิทธิ์เข้าถึงโดยตรงที่ android.permission.WRITE_MEDIA_STORAGE มอบให้

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องจัดให้มีกลไกในการเข้าถึงข้อมูลในที่จัดเก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันจากคอมพิวเตอร์โฮสต์
  • ควรแสดงเนื้อหาจากทั้ง 2 เส้นทางของพื้นที่เก็บข้อมูลอย่างโปร่งใสผ่านบริการสแกนมัลติมีเดียของ Android และ android.provider.MediaStore
  • ใช้อุปกรณ์เก็บข้อมูลขนาดใหญ่แบบ USB ได้ แต่ควรใช้ Media Transfer Protocol เพื่อปฏิบัติตามข้อกำหนดนี้

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่มีโหมดอุปกรณ์ต่อพ่วง USB และรองรับโปรโตคอลการโอนสื่อ อุปกรณ์จะมีลักษณะดังนี้

  • ควรเข้ากันได้กับโฮสต์ MTP ของ Android ที่ใช้อ้างอิง ซึ่งก็คือ Android File Transfer
  • ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
  • ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable

หากอุปกรณ์มีไว้เพื่อการใช้งานแบบเคลื่อนที่ซึ่งแตกต่างจากทีวี การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [SR] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานพื้นที่เก็บข้อมูลที่พร้อมใช้งานในตำแหน่งที่มั่นคงในระยะยาว เนื่องจากการเชื่อมต่อออกโดยไม่ตั้งใจอาจทําให้ข้อมูลสูญหาย/เสียหาย

หากพอร์ตอุปกรณ์เก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่มั่นคงในระยะยาว เช่น ภายในกล่องแบตเตอรี่หรือฝาครอบป้องกันอื่นๆ การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

7.7. USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB อุปกรณ์จะมีลักษณะดังนี้

  • ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB

7.7.1. โหมดอุปกรณ์ต่อพ่วง USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง ให้ทำดังนี้

  • [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB Type-A หรือ Type-C มาตรฐานได้
  • [C-1-2] ต้องรายงานค่าที่ถูกต้องของ iSerialNumber ในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ผ่าน android.os.Build.SERIAL
  • [C-1-3] ต้องตรวจหาที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจหาการเปลี่ยนแปลงในโฆษณาหากรองรับ USB Type-C
  • [SR] พอร์ตควรใช้รูปแบบ USB micro-B, micro-AB หรือ Type-C เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้
  • [SR] พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวตามปกติ) หรือเปิดใช้การหมุนหน้าจอด้วยซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้จอแสดงผลวาดภาพได้อย่างถูกต้องเมื่ออุปกรณ์วางแนวโดยให้พอร์ตอยู่ด้านล่าง เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งรุ่นเก่าและรุ่นใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
  • [SR] ควรรองรับการดึงกระแส 1.5 A ในระหว่างการส่งสัญญาณ HS และการรับส่งข้อมูลตามที่ระบุไว้ในข้อกำหนดการชาร์จแบตเตอรี่ USB ฉบับแก้ไข 1.2 เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้
  • [SR] ขอแนะนำอย่างยิ่งว่าอย่ารองรับวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus เกินระดับเริ่มต้น หรือแก้ไขบทบาทแหล่งจ่ายไฟ/อุปกรณ์รับพลังงาน เนื่องจากอาจทำให้เกิดปัญหาการทำงานร่วมกันกับที่ชาร์จหรืออุปกรณ์ที่รองรับวิธีการจ่ายพลังงาน USB มาตรฐาน แม้ว่าเราจะระบุว่า "แนะนำอย่างยิ่ง" แต่ในอนาคต Android เวอร์ชันต่างๆ อาจกำหนดให้อุปกรณ์ Type-C ทั้งหมดต้องรองรับการทำงานร่วมกันได้อย่างเต็มที่กับที่ชาร์จ Type-C มาตรฐาน
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สําหรับการแลกเปลี่ยนบทบาทของข้อมูลและการจ่ายไฟเมื่อรองรับ USB Type-C และโหมดโฮสต์ USB
  • ควรรองรับ Power Delivery สำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่นๆ เช่น การแสดงผล
  • ควรใช้ Android Open Accessory (AOA) API และข้อกำหนดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB และใช้ข้อกำหนด AOA อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
  • [C-2-2] คลาสอุปกรณ์เก็บข้อมูลขนาดใหญ่ USB ต้องมีสตริง "android" ต่อท้ายสตริงคำอธิบายอินเทอร์เฟซ iInterface ของอุปกรณ์เก็บข้อมูลขนาดใหญ่ USB

7.7.2. โหมดโฮสต์ USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
  • [C-1-2] ต้องรองรับการเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ ต้องมีคุณสมบัติอย่างใดอย่างหนึ่งต่อไปนี้
    • มีพอร์ต Type-C ในอุปกรณ์หรือมาพร้อมกับสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์เป็นพอร์ต USB Type-C มาตรฐาน (อุปกรณ์ USB Type-C)
    • มีขั้วต่อประเภท A ในอุปกรณ์หรือมีสายสำหรับแปลงพอร์ตที่เป็นกรรมสิทธิ์ของอุปกรณ์เป็นพอร์ต USB ประเภท A มาตรฐาน
    • มีพอร์ต micro-AB ในอุปกรณ์ ซึ่งควรมาพร้อมกับสายที่เปลี่ยนเป็นพอร์ต Type-A มาตรฐาน
  • [C-1-3] ต้องไม่มีอะแดปเตอร์ที่แปลงจากพอร์ต USB Type A หรือ micro-AB เป็นพอร์ต Type-C (เต้ารับ)
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่ออยู่ขณะอยู่ในโหมดโฮสต์ แสดงกระแสแหล่งที่มาอย่างน้อย 1.5 แอมป์ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับที่ 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสเอาต์พุตของพอร์ตดาวน์สตรีมการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะของการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 สำหรับขั้วต่อ Micro-AB
  • ควรติดตั้งใช้งานและรองรับมาตรฐาน USB Type-C

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และคลาสเสียง USB อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรองรับคลาส USB HID
  • [C-2-2] ต้องรองรับการตรวจหาและการแมปช่องข้อมูล HID ต่อไปนี้ที่ระบุไว้ในตารางการใช้งาน USB HID และคําขอการใช้งานคําสั่งเสียงกับค่าคงที่ KeyEvent ดังต่อไปนี้
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0E9): KEYCODE_VOLUME_UP
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0EA): KEYCODE_VOLUME_DOWN
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CF): KEYCODE_VOICE_ASSIST

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF) อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องจดจำอุปกรณ์ MTP (Media Transfer Protocol) ที่เชื่อมต่อจากระยะไกลและทำให้เนื้อหาของอุปกรณ์เข้าถึงได้ผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องใช้งานฟังก์ชันพอร์ตแบบ 2 บทบาทตามที่ระบุไว้ในข้อกำหนด USB Type-C (ส่วนที่ 4.5.1.3.3)
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort, ควรรองรับอัตราการรับส่งข้อมูล SuperSpeed ของ USB และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทระหว่างการจ่ายไฟและการโอนข้อมูล
  • [SR] ขอแนะนำอย่างยิ่งว่าอย่ารองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก ก ของข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2
  • ควรใช้รูปแบบ Try.* ที่เหมาะสมที่สุดกับรูปแบบของอุปกรณ์ เช่น อุปกรณ์แบบพกพาควรใช้รูปแบบ Try.SNK

7.8. เสียง

7.8.1. ไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีไมโครโฟน อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-1-2] ต้องเป็นไปตามข้อกําหนดการบันทึกเสียงในส่วนที่ 5.4
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงที่ความถี่ใกล้เคียงกับอัลตราซาวด์ตามที่อธิบายไว้ในส่วนที่ 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-2-2] ต้องติดตั้งใช้งาน API การบันทึกเสียงเป็นอย่างน้อยแบบไม่ดำเนินการใดๆ ตามส่วนที่ 7

7.8.2 เอาต์พุตเสียง

หากการติดตั้งใช้งานอุปกรณ์มีลำโพงหรือพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น ช่องเสียบเสียง 3.5 มม. แบบ 4 สายหรือพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
  • [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับการเล่นที่เกือบเป็นคลื่นอัลตราซาวด์ตามที่อธิบายไว้ในส่วนที่ 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีลำโพงหรือพอร์ตเอาต์พุตเสียง อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่รายงานฟีเจอร์ android.hardware.audio.output
  • [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็น No-Op เป็นอย่างน้อย

"พอร์ตเอาต์พุต" สำหรับวัตถุประสงค์ของส่วนนี้หมายถึงอินเทอร์เฟซที่จับต้องได้ เช่น ช่องเสียบเสียง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลที่ใช้คลื่นวิทยุ เช่น บลูทูธ, Wi-Fi หรือเครือข่ายมือถือ จะไม่ถือว่ามี "พอร์ตเอาต์พุต"

7.8.2.1. พอร์ตเสียงแบบแอนะล็อก

อุปกรณ์ที่ติดตั้งใช้งานมีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ตจะต้องมีลักษณะดังนี้เพื่อให้เข้ากันได้กับชุดหูฟังและอุปกรณ์เสริมอื่นๆ สำหรับเสียงที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศ Android

  • [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] ต้องมีแรงดันไฟฟ้า Bias ของไมโครโฟนระหว่าง 1.8V ~ 2.9V
  • [C-1-7] ต้องตรวจจับและจับคู่กับรหัสคีย์สำหรับช่วงอิมพีแดนซ์ที่เทียบเท่าระหว่างไมโครโฟนและตัวนำกราวด์บนปลั๊กเสียง ดังนี้
    • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลําดับการต่อขา OMTP
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอที่มีไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีขั้วต่อ 4 เส้นของช่องเสียบเสียง 3.5 มม. และรองรับไมโครโฟน รวมถึงออกอากาศ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนค่าพิเศษเป็น 1 อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องรองรับการตรวจจับไมโครโฟนในอุปกรณ์เสริมเสียงที่เสียบอยู่
7.8.2.2. พอร์ตเสียงดิจิทัล

เพื่อให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมเสียงอื่นๆ ที่ใช้ขั้วต่อ USB-C และการใช้ (คลาสเสียง USB) ในระบบนิเวศ Android ได้ตามที่ระบุไว้ในข้อกำหนดเฉพาะของชุดหูฟัง USB สำหรับ Android

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วนที่ 2.2.1

7.8.3. อัลตราซาวด์ระยะใกล้

เสียงที่เกือบเป็นคลื่นอัลตราซาวด์คือย่านความถี่ 18.5-20 KHz

การติดตั้งใช้งานอุปกรณ์

  • ต้องรายงานการรองรับความสามารถของเสียงย่านอัลตราซาวด์อย่างถูกต้องผ่าน AudioManager.getProperty API ดังนี้

หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION และ UNPROCESSED ต้องเป็นไปตามข้อกำหนดต่อไปนี้

  • [C-1-1] การตอบสนองกำลังไฟฟ้าเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องต่ำกว่าการตอบสนองที่ 2 kHz ไม่เกิน 15 dB
  • [C-1-2] อัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ไม่ถ่วงน้ำหนักของไมโครโฟนในช่วงความถี่ 18.5-20 kHz สำหรับเสียงความถี่ 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง"

  • [C-2-1] การตอบสนองค่าเฉลี่ยของลำโพงในย่านความถี่ 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB เมื่อเทียบกับการตอบสนองที่ 2 kHz

7.8.4 ความสมบูรณ์ของสัญญาณ

การติดตั้งใช้งานอุปกรณ์

  • ควรมีเส้นทางสัญญาณเสียงที่ปราศจากข้อบกพร่องสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์แบบพกพาตามที่ระบุโดยไม่มีข้อบกพร่องใดๆ ที่วัดได้ในระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "การทดสอบข้อบกพร่องอัตโนมัติ"

การทดสอบต้องใช้ดองเกิลเสียงแบบลูปแบ็ก ซึ่งใช้กับช่องเสียบ 3.5 มม. โดยตรง และ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

ปัจจุบัน OboeTester รองรับเส้นทาง AAudio คุณจึงควรทดสอบชุดค่าผสมต่อไปนี้เพื่อหาข้อบกพร่องโดยใช้ AAudio

โหมด Perf การแชร์ อัตราการสุ่มตัวอย่างเอาต์พุต ใน Chans Out Chan
LOW_LATENCY พิเศษ ไม่ได้ระบุ 1 2
LOW_LATENCY พิเศษ ไม่ได้ระบุ 2 1
LOW_LATENCY แชร์ ไม่ได้ระบุ 1 2
LOW_LATENCY แชร์ ไม่ได้ระบุ 2 1
ไม่มี แชร์ 48000 1 2
ไม่มี แชร์ 48000 2 1
ไม่มี แชร์ 44100 1 2
ไม่มี แชร์ 44100 2 1
ไม่มี แชร์ 16000 1 2
ไม่มี แชร์ 16000 2 1

สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) และความผิดเพี้ยนตามฮาร์โมนิกทั้งหมด (THD) สำหรับไซน์ 2000 Hz

ตัวแปรสัญญาณ THD SNR
ลำโพงหลักในตัวที่วัดโดยใช้ไมโครโฟนอ้างอิงภายนอก < 3.0% >= 50 dB
ไมโครโฟนในตัวหลักที่วัดโดยใช้ลำโพงอ้างอิงภายนอก < 3.0% >= 50 dB
ช่องเสียบแอนะล็อก 3.5 มม. ในตัว ซึ่งทดสอบโดยใช้อะแดปเตอร์การวนซ้ำ < 1% >= 60 dB
อะแดปเตอร์ USB ที่มาพร้อมกับโทรศัพท์ ซึ่งทดสอบโดยใช้อะแดปเตอร์การวนลูป < 1.0% >= 60 dB

7.9. Virtual Reality

Android มี API และเครื่องมือในการสร้างแอปพลิเคชัน "Virtual Reality" (VR) รวมถึงประสบการณ์ VR บนอุปกรณ์เคลื่อนที่ที่มีคุณภาพสูง การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

7.9.1. โหมด Virtual Reality

Android รองรับโหมด VR ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลภาพ 3 มิติของการแจ้งเตือนและปิดใช้คอมโพเนนต์ UI ของระบบแบบโมโนคูลาร์ขณะที่แอปพลิเคชัน VR อยู่โฟกัสของผู้ใช้

7.9.2 โหมดความจริงเสมือน - ประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับโหมด 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 ที่ 60 fps ด้วยบริบทการเรนเดอร์ 2 รายการแสดงผลโดยไม่มีภาพแตกให้เห็น
  • [C-1-9] ต้องรองรับ Flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องรองรับ AHardwareBuffer ที่มีชุดค่าผสมของ Flag การใช้งาน 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 เลเยอร์ รวมถึง Flag และรูปแบบที่ระบุไว้ใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30 fps ซึ่งบีบอัดเป็น 40 Mbps โดยเฉลี่ย (เทียบเท่ากับ 1920 x 1080 4 อินสแตนซ์ที่ 30 fps-10 Mbps หรือ 1920 x 1080 2 อินสแตนซ์ที่ 60 fps-20 Mbps)
  • [C-1-12] ต้องรองรับ HEVC และ VP9, ต้องสามารถถอดรหัสความละเอียดอย่างน้อย 1920 x 1080 ที่ 30 fps ซึ่งบีบอัดเป็น 10 Mbps โดยเฉลี่ย และควรสามารถถอดรหัสความละเอียด 3840 x 2160 ที่ 30 fps-20 Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 fps-5 Mbps)
  • [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 เพื่อแสดงจำนวนแกนประมวลผลสำหรับแอปพลิเคชันที่ใช้งานอยู่โดยเฉพาะ

หากรองรับแกนเอกสิทธิ์ แกนจะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้มีกระบวนการอื่นใดใน Userspace ทำงาน (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่อาจอนุญาตให้มีบางกระบวนการของเคิร์กัลทำงานได้ตามความจำเป็น

8. ประสิทธิภาพและกำลังไฟ

เกณฑ์ประสิทธิภาพและกำลังขั้นต่ำบางรายการมีความสำคัญต่อประสบการณ์ของผู้ใช้และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป

8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้

ผู้ใช้ปลายทางจะได้รับอินเทอร์เฟซผู้ใช้ที่ราบรื่นหากมีข้อกำหนดขั้นต่ำบางอย่างเพื่อให้แอปพลิเคชันและเกมมีอัตราเฟรมและเวลาในการตอบสนองที่สอดคล้องกัน การติดตั้งใช้งานอุปกรณ์อาจมีข้อกำหนดที่วัดได้สำหรับเวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้และการเปลี่ยนงาน ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์ ตามที่อธิบายไว้ในส่วนที่ 2

8.2. ประสิทธิภาพการเข้าถึง I/O ของไฟล์

การกำหนดพื้นฐานทั่วไปสำหรับประสิทธิภาพการเข้าถึงไฟล์ที่สอดคล้องกันในที่จัดเก็บข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) จะช่วยให้นักพัฒนาแอปกำหนดความคาดหวังที่เหมาะสมซึ่งจะช่วยในการออกแบบซอฟต์แวร์ได้ การติดตั้งใช้งานอุปกรณ์อาจมีข้อกำหนดบางอย่างที่อธิบายไว้ในส่วนที่ 2 สำหรับการดำเนินการอ่านและเขียนต่อไปนี้ ทั้งนี้ขึ้นอยู่กับประเภทของอุปกรณ์

  • ประสิทธิภาพการเขียนแบบตามลำดับ วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการเขียนแบบสุ่ม วัดจากการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB
  • ประสิทธิภาพการอ่านแบบตามลำดับ โดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการอ่านแบบสุ่ม วัดจากการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB

8.3 โหมดประหยัดพลังงาน

หากการติดตั้งใช้งานอุปกรณ์มีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับทริกเกอร์ การดูแลรักษา อัลกอริทึมการปลุก และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน "แอปรอดำเนินการ" และ "โหมด Doze"
  • [C-1-2] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการจำกัดงาน การแจ้งเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสําหรับโหมดรอของแอป
  • [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวนที่เก็บข้อมูลแอปที่รอดำเนินการที่ใช้สำหรับแอปที่รอดำเนินการ
  • [C-1-4] ต้องติดตั้งใช้งาน App Standby Buckets และโหมด Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] MUST return true for PowerManager.isPowerSaveMode() when the device is on power save mode.
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้เปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
  • [C-SR] ขอแนะนําอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้แสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานของโหมดแอปรอและโหมดสลีป

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การใช้งานอุปกรณ์ Android อาจใช้สถานะพลังงานในโหมดสลีป 4 สถานะใดสถานะหนึ่งหรือทั้งหมดตามที่ระบุโดยอินเทอร์เฟซการกําหนดค่าและการจัดการพลังงานขั้นสูง (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
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
  • [SR] ขอแนะนําอย่างยิ่งให้รายงานการสิ้นเปลืองพลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานโมดูลเคอร์เนล uid_cputime
  • [SR] ขอแนะนำอย่างยิ่งให้นักพัฒนาแอปใช้คำสั่งเชลล์ adb shell dumpsys batterystats เพื่อดูปริมาณการใช้พลังงานนี้
  • ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน

8.5 ประสิทธิภาพที่สม่ำเสมอ

ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่ทำงานอย่างต่อเนื่องและมีประสิทธิภาพสูง เนื่องจากแอปอื่นๆ ที่ทำงานอยู่เบื้องหลังหรือการจำกัด CPU เนื่องจากขีดจำกัดอุณหภูมิ Android มีอินเทอร์เฟซแบบเป็นโปรแกรมเพื่อให้แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าสามารถขอให้ระบบเพิ่มประสิทธิภาพการจัดสรรทรัพยากรเพื่อจัดการกับความผันผวนดังกล่าวได้เมื่ออุปกรณ์มีความสามารถ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด PowerManager.isSustainedPerformanceModeSupported() API

  • ควรรองรับโหมดประสิทธิภาพที่ยั่งยืน

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องให้แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระดับบนมีประสิทธิภาพที่สอดคล้องกันอย่างน้อย 30 นาทีเมื่อแอปขอ
  • [C-1-2] ต้องปฏิบัติตาม Window.setSustainedPerformanceMode() API และ API อื่นๆ ที่เกี่ยวข้อง

หากการติดตั้งใช้งานอุปกรณ์มีแกน CPU 2 แกนขึ้นไป อุปกรณ์จะมีลักษณะดังนี้

  • ควรระบุโค้ดหลักที่ไม่ซ้ำกันอย่างน้อย 1 รายการที่แอปพลิเคชันเบื้องหน้าระดับบนสุดสามารถจองได้

หากการติดตั้งใช้งานอุปกรณ์รองรับการจองแกนหลัก 1 รายการสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับสูงสุด อุปกรณ์จะดำเนินการดังนี้

  • [C-2-1] ต้องรายงานหมายเลขรหัสของคอร์แบบพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับบนสุดสามารถจองได้ผ่านเมธอด Process.getExclusiveCores() API
  • [C-2-2] ต้องไม่อนุญาตให้มีกระบวนการใดๆ ใน User Space ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อทำงานบนแกนหลัก แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางรายการทำงานได้ตามความจำเป็น

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับแกนเอกสิทธิ์ อุปกรณ์จะมีลักษณะดังนี้

9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้รูปแบบการรักษาความปลอดภัยที่สอดคล้องกับรูปแบบการรักษาความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารประกอบสำหรับนักพัฒนาแอป Android

  • [C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงานใดๆ กล่าวโดยละเอียดคือ อุปกรณ์ที่เข้ากันได้ต้องรองรับกลไกการรักษาความปลอดภัยที่อธิบายไว้ในส่วนย่อยต่อไปนี้

9.1. สิทธิ์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับรูปแบบสิทธิ์ของ Android ตามที่ระบุไว้ในเอกสารประกอบสำหรับนักพัฒนาแอป Android กล่าวโดยละเอียดคือ คุณต้องบังคับใช้สิทธิ์แต่ละรายการตามที่อธิบายไว้ในเอกสารประกอบ SDK โดยต้องไม่ละเว้น เปลี่ยนแปลง หรือละเลยสิทธิ์ใดๆ

  • อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel ของ PROTECTION_FLAG_PRIVILEGED ต้องมอบให้กับแอปที่ติดตั้งไว้ล่วงหน้าในเส้นทางที่มีสิทธิ์ของอิมเมจระบบเท่านั้น และอยู่ภายในชุดย่อยของสิทธิ์ในรายการที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและปฏิบัติตามสิทธิ์ในรายการที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่มีสิทธิ์

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion มากกว่า 22 จะขอสิทธิ์เหล่านั้นเมื่อรันไทม์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ รวมถึงต้องมีอินเทอร์เฟซสำหรับให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย
  • [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 รายการเพียงรายการเดียว
  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งไว้ล่วงหน้า เว้นแต่ในกรณีต่อไปนี้
    • ขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้
    • สิทธิ์รันไทม์จะเชื่อมโยงกับรูปแบบ Intent ที่กำหนดแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
  • [C-0-6] MUST grant the android.permission.RECOVER_KEYSTORE permission only to system apps that register a properly secured Recovery Agent. ตัวแทนการกู้คืนที่ปลอดภัยอย่างเหมาะสมหมายถึงตัวแทนซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยพร้อมการป้องกันที่เทียบเท่าหรือดีกว่าที่อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีด้วยวิธี Brute Force กับปัจจัยความรู้ในหน้าจอล็อก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องเป็นไปตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android เมื่อแอปขอข้อมูลตำแหน่งหรือข้อมูลการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้

    • ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด)
    • ข้อมูลที่สามารถใช้เพื่อระบุหรือประมาณตำแหน่งของอุปกรณ์ (เช่น SSID, BSSID, รหัสเครือข่ายมือถือ, การสแกนบลูทูธ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
    • กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจำแนกกิจกรรมการเคลื่อนไหวร่างกาย

กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-0-8] ต้องขอความยินยอมจากผู้ใช้ในการอนุญาตให้แอปเข้าถึงข้อมูลตําแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
  • [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มีสิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น เช่น TelephonyManager#getServiceState ต้องใช้ android.permission.ACCESS_FINE_LOCATION)

คุณสามารถทําเครื่องหมายสิทธิ์เป็น "ถูกจํากัด" เพื่อเปลี่ยนลักษณะการทํางานของสิทธิ์ได้

  • [C-0-10] สิทธิ์ที่มีเครื่องหมาย hardRestricted ต้องไม่ให้สิทธิ์แก่แอป เว้นแต่ในกรณีต่อไปนี้

    • ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
    • ผู้ใช้กำหนดบทบาทที่เชื่อมโยงกับสิทธิ์ hardRestricted ให้กับแอป
    • โปรแกรมติดตั้งจะมอบ hardRestricted ให้กับแอป
    • แอปได้รับ hardRestricted ใน Android เวอร์ชันเก่า

  • [C-0-11] แอปที่มีสิทธิ์ softRestricted ต้องมีสิทธิ์เข้าถึงแบบจำกัดเท่านั้น และจะต้องไม่ได้รับสิทธิ์เข้าถึงแบบเต็มรูปแบบจนกว่าจะเพิ่มลงในรายการที่อนุญาตตามที่อธิบายไว้ใน SDK ซึ่งมีการกําหนดสิทธิ์เข้าถึงแบบเต็มรูปแบบและแบบจํากัดสําหรับสิทธิ์ softRestricted แต่ละรายการ (เช่น WRITE_EXTERNAL_STORAGE และ READ_EXTERNAL_STORAGE)

หากการติดตั้งใช้งานอุปกรณ์มีแอปที่ติดตั้งไว้ล่วงหน้าหรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งาน ผู้ใช้จะต้องดำเนินการดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้ระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อมอบหรือเพิกถอนสิทธิ์เข้าถึงสถิติการใช้งานตาม Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS สําหรับแอปที่ประกาศสิทธิ์ android.permission.PACKAGE_USAGE_STATS

หากการติดตั้งใช้งานอุปกรณ์ตั้งใจที่จะไม่อนุญาตให้แอปใดๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้าเข้าถึงสถิติการใช้งาน การดำเนินการต่อไปนี้จะเกิดขึ้น

  • [C-1-1] ยังคงต้องมีกิจกรรมที่จัดการรูปแบบ Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS แต่ต้องใช้รูปแบบดังกล่าวแบบไม่ดำเนินการใดๆ กล่าวคือมีการทำงานเทียบเท่ากับเมื่อผู้ใช้ถูกปฏิเสธการเข้าถึง

9.2. UID และการแยกกระบวนการ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับรูปแบบแซนด์บ็อกซ์แอปพลิเคชันของ Android ซึ่งแอปพลิเคชันแต่ละรายการจะทำงานเป็น UID รูปแบบ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก
  • [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการโดยใช้รหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงนามและสร้างอย่างถูกต้องตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3. สิทธิ์ในระบบไฟล์

การติดตั้งใช้งานอุปกรณ์

9.4. สภาพแวดล้อมการดําเนินการอื่น

การติดตั้งใช้งานอุปกรณ์ต้องรักษารูปแบบความปลอดภัยและสิทธิ์ของ Android ให้สอดคล้องกัน แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นนอกเหนือจากรูปแบบไฟล์ Dalvik หรือโค้ดเนทีฟก็ตาม กล่าวคือ

  • [C-0-1] รันไทม์อื่นต้องเป็นแอปพลิเคชัน Android และเป็นไปตามรูปแบบการรักษาความปลอดภัยมาตรฐานของ Android ตามที่อธิบายไว้ในส่วนอื่นๆ ในส่วนที่ 9

  • [C-0-2] รันไทม์สำรองต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

  • [C-0-3] รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากฟีเจอร์ที่ได้รับการคุ้มครองโดยสิทธิ์ของ Android ซึ่งจํากัดไว้สําหรับแอปพลิเคชันระบบเท่านั้น

  • [C-0-4] รันไทม์อื่นต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์อื่นต้องไม่นำแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่านกลไกมาตรฐานของ Android สำหรับรหัสผู้ใช้ที่แชร์และใบรับรองการรับรอง

  • [C-0-5] รันไทม์อื่นต้องไม่เปิดใช้งาน มอบสิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] รันไทม์อื่นต้องไม่เปิดใช้งาน ไม่ได้รับสิทธิ์ หรือให้สิทธิ์แก่แอปพลิเคชันอื่นๆ เกี่ยวกับสิทธิ์ของผู้ดูแลระบบ (root) หรือรหัสผู้ใช้อื่นๆ

  • [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์อื่นไว้ในอิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ ไฟล์ดังกล่าวต้องลงชื่อด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงชื่อแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการนําอุปกรณ์ไปใช้งาน

  • [C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์อื่นต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ Android ที่แอปพลิเคชันใช้

  • [C-0-9] เมื่อแอปพลิเคชันต้องใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้

  • [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่ได้บันทึกความสามารถของแอปพลิเคชันด้วยวิธีนี้ สภาพแวดล้อมรันไทม์ต้องแสดงรายการสิทธิ์ทั้งหมดที่รันไทม์มีเมื่อติดตั้งแอปพลิเคชันที่ใช้รันไทม์นั้น

  • รันไทม์อื่นควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

  • รันไทม์อื่นอาจมีแซนด์บ็อกซ์ Android เดียวที่แอปพลิเคชันทั้งหมดที่ใช้รันไทม์อื่นใช้ร่วมกัน

9.5 การรองรับผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ

  • การติดตั้งใช้งานอุปกรณ์อาจเปิดใช้ผู้ใช้หลายคนได้ แต่ไม่ควรเปิดใช้หากใช้สื่อแบบถอดออกได้สำหรับพื้นที่เก็บข้อมูลภายนอกหลัก

หากมีผู้ใช้หลายคนในการใช้งานอุปกรณ์ ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้

  • [C-1-1] ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน
  • [C-1-2] ต้องใช้รูปแบบความปลอดภัยที่สอดคล้องกับรูปแบบความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API สำหรับผู้ใช้แต่ละราย
  • [C-1-3] ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกัน (หรือที่เรียกว่า /sdcard) แยกต่างหากและแยกกันสำหรับอินสแตนซ์ผู้ใช้แต่ละรายการ
  • [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่ผู้ใช้รายหนึ่งเป็นเจ้าของและทำงานในนามของผู้ใช้รายดังกล่าวไม่สามารถแสดงรายการ อ่าน หรือเขียนลงในไฟล์ที่ผู้ใช้รายอื่นเป็นเจ้าของ แม้ว่าข้อมูลของผู้ใช้ทั้ง 2 รายจะจัดเก็บไว้ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
  • [C-1-5] ต้องเข้ารหัสเนื้อหาของการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อแบบถอดไม่ได้เท่านั้นที่ระบบเข้าถึงได้ หากการติดตั้งใช้งานอุปกรณ์ใช้สื่อแบบถอดได้สำหรับ API พื้นที่เก็บข้อมูลภายนอก เนื่องจากจะทำให้ PC โฮสต์อ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้ PC โฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม

Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมขาออก ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.telephony อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] ต้องเตือนผู้ใช้ก่อนส่ง SMS ไปยังหมายเลขที่ระบุด้วยนิพจน์ทั่วไปที่กําหนดไว้ในไฟล์ /data/misc/sms/codes.xml ในอุปกรณ์ โครงการโอเพนซอร์ส Android เวอร์ชันอัปสตรีมมีการใช้งานที่เป็นไปตามข้อกำหนดนี้

9.7 ฟีเจอร์ความปลอดภัย

การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดของฟีเจอร์ด้านความปลอดภัยทั้งในเคอร์เนลและแพลตฟอร์มตามที่อธิบายไว้ด้านล่าง

แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ระบบการควบคุมการเข้าถึงแบบบังคับ (MAC) ของ Security-Enhanced Linux (SELinux), การแซนด์บ็อกซ์ seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนล Linux การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเข้ากันได้กับแอปพลิเคชันที่มีอยู่ แม้ว่าจะมีการใช้ SELinux หรือฟีเจอร์ด้านความปลอดภัยอื่นๆ ด้านล่างเฟรมเวิร์ก Android ก็ตาม
  • [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดความปลอดภัยและมีการบล็อกการละเมิดดังกล่าวโดยฟีเจอร์ด้านความปลอดภัยที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android เรียบร้อยแล้ว แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดความปลอดภัยที่ระบบไม่ได้บล็อก ซึ่งส่งผลให้มีการแสวงหาประโยชน์ได้สำเร็จ
  • [C-0-3] ต้องไม่ทำให้ SELinux หรือฟีเจอร์ด้านความปลอดภัยอื่นๆ ที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android กำหนดค่าได้สำหรับผู้ใช้หรือนักพัฒนาแอป
  • [C-0-4] ต้องไม่อนุญาตให้แอปพลิเคชันที่สามารถส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) กำหนดค่านโยบายที่ขัดแย้งกัน
  • [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการได้แคบลงตามที่อธิบายไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
  • [C-0-6] ต้องติดตั้งใช้งานกลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนลที่อนุญาตให้กรองการเรียกระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบหลายเธรด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางเป็นไปตามข้อกำหนดนี้ผ่านการเปิดใช้ seccomp-BPF ที่มีการปรับเวลากลุ่มเธรด (TSYNC) ตามที่อธิบายไว้ในส่วนการกําหนดค่าเคอร์เนลของ source.android.com

ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการป้องกันตนเองเป็นส่วนสำคัญของความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องติดตั้งใช้งานกลไกการป้องกันการเขียนไปยังบัฟเฟอร์สแตกเกินขอบเขตที่กำหนด (stack buffer overflow) ของเคิร์นัล ตัวอย่างกลไกดังกล่าว ได้แก่ CC_STACKPROTECTOR_REGULAR และ CONFIG_CC_STACKPROTECTOR_STRONG
  • [C-0-8] ต้องใช้การป้องกันหน่วยความจำเคอร์เนลอย่างเข้มงวดในกรณีที่โค้ดที่เรียกใช้ได้เป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวจะไม่สามารถเรียกใช้ได้และเขียนไม่ได้ และข้อมูลแบบเขียนได้จะไม่สามารถเรียกใช้ได้ (เช่น CONFIG_DEBUG_RODATA หรือ CONFIG_STRICT_KERNEL_RWX)
  • [C-0-9] ต้องใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และพื้นที่เคอร์เนล (เช่น CONFIG_HARDENED_USERCOPY) ในอุปกรณ์ที่จัดส่งมาพร้อมกับ API ระดับ 28 ขึ้นไปตั้งแต่แรก
  • [C-0-10] ต้องไม่เรียกใช้หน่วยความจำสเปซผู้ใช้เมื่อเรียกใช้ในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือการจําลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งมาพร้อมกับ API ระดับ 28 ขึ้นไปตั้งแต่แรก
  • [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึงสำเนาของผู้ใช้ตามปกติ (เช่น PAN ของฮาร์ดแวร์หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งมาพร้อมกับ API ระดับ 28 ขึ้นไปตั้งแต่แรก
  • [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลหากฮาร์ดแวร์มีช่องโหว่ CVE-2017-5754 ในอุปกรณ์ทั้งหมดที่จัดส่งมาพร้อมกับ API ระดับ 28 ขึ้นไปตั้งแต่แรก (เช่น CONFIG_PAGE_TABLE_ISOLATION หรือ CONFIG_UNMAP_KERNEL_AT_EL0)
  • [C-0-13] ต้องใช้การเพิ่มความแข็งแกร่งให้กับการคาดคะเนสาขาหากฮาร์ดแวร์มีช่องโหว่ CVE-2017-5715 ในอุปกรณ์ทั้งหมดที่จัดส่งมาพร้อมกับ API ระดับ 28 ขึ้นไปตั้งแต่แรก (เช่น CONFIG_HARDEN_BRANCH_PREDICTOR)
  • [SR] ขอแนะนำอย่างยิ่งให้ทำเครื่องหมายข้อมูลเคอร์เนลที่เขียนในระหว่างการเริ่มต้นเท่านั้นว่าอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น __ro_after_init)

  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และหลีกเลี่ยงการแสดงข้อมูลที่อาจทำให้การสุ่มไม่ปลอดภัย (เช่น CONFIG_RANDOMIZE_BASE ที่มีข้อมูลความผันผวนของ Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

  • [C-SR] ขอแนะนําอย่างยิ่งให้เปิดใช้การควบคุมความสมบูรณ์ของโฟลว์ (CFI) ในเคอร์เนลเพื่อให้การป้องกันเพิ่มเติมจากการโจมตีด้วยการใช้โค้ดซ้ำ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

  • [C-SR] ขอแนะนำอย่างยิ่งว่าอย่าปิดใช้การควบคุมความสมบูรณ์ของโฟลว์ (CFI), Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) ในคอมโพเนนต์ที่เปิดใช้
  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์พื้นที่ผู้ใช้ที่มีความละเอียดอ่อนด้านความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนล Linux อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องใช้งาน SELinux
  • [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้แบบทั่วโลก
  • [C-1-3] ต้องกําหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดอนุญาต ซึ่งรวมถึงโดเมนสำหรับอุปกรณ์/ผู้ให้บริการโดยเฉพาะ
  • [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ neverallow ที่มีอยู่ในโฟลเดอร์ system/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์ด้วยกฎ neverallow ทั้งหมดที่มีอยู่ ทั้งสำหรับโดเมน SELinux ของ AOSP และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
  • [C-1-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไปในแซนด์บ็อกซ์ SELinux ของแต่ละแอปที่มีข้อจำกัด SELinux ของแต่ละแอปในไดเรกทอรีข้อมูลส่วนตัวของแอปแต่ละแอป
  • ควรเก็บนโยบาย SELinux เริ่มต้นไว้ตามที่ระบุไว้ในโฟลเดอร์ system/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง และเพิ่มนโยบายนี้สำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น

หากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้วและไม่สามารถปฏิบัติตามข้อกำหนด [C-1-1] และ [C-1-5] ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนดเหล่านี้

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงแบบบังคับซึ่งเทียบเท่ากับ SELinux

Android มีฟีเจอร์การป้องกันแบบหลายชั้นหลายรายการที่เป็นส่วนสำคัญของความปลอดภัยของอุปกรณ์

9.8 ความเป็นส่วนตัว

9.8.1 ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีระยะเวลาการเก็บรักษาประวัติผู้ใช้ดังกล่าวอย่างสมเหตุสมผล
  • [SR] ขอแนะนำอย่างยิ่งให้เก็บรักษาข้อมูลเป็นเวลา 14 วันตามที่กําหนดค่าไว้โดยค่าเริ่มต้นในการใช้งาน AOSP

Android จัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ IncidentManager System API

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องมีเฉพาะช่องที่มีเครื่องหมาย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นนอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม ระบบอาจใช้ตัวระบุ Atom อื่นในช่วง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่โหลดล่วงหน้าหรือจัดจำหน่ายคอมโพเนนต์ซอฟต์แวร์แบบสำเร็จรูปที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้หรือการแจ้งเตือนอย่างต่อเนื่องที่ชัดเจน

  • [C-0-2] ต้องแสดงและขอความยินยอมจากผู้ใช้อย่างชัดเจนซึ่งมีข้อความเหมือนกับ AOSP ทุกครั้งที่เปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอผ่าน MediaProjection หรือ API ที่เป็นกรรมสิทธิ์ ต้องไม่เปิดโอกาสให้ผู้ใช้ปิดใช้การแสดงข้อความขอความยินยอมของผู้ใช้ในอนาคต

  • [C-0-3] ต้องมีการแจ้งเตือนอย่างต่อเนื่องให้ผู้ใช้ทราบขณะเปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอ AOSP เป็นไปตามข้อกำหนดนี้ด้วยการแสดงไอคอนการแจ้งเตือนต่อเนื่องในแถบสถานะ

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่จับภาพเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์นอกเหนือจากผ่าน System API ContentCaptureService หรือวิธีอื่นๆ ที่เป็นกรรมสิทธิ์ตามที่อธิบายไว้ในส่วนที่ 9.8.6 การจับภาพเนื้อหา การดำเนินการดังกล่าวจะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องมีการแจ้งเตือนอย่างต่อเนื่องให้ผู้ใช้ทราบทุกครั้งที่เปิดใช้ฟังก์ชันการทำงานนี้และกำลังจับภาพ/บันทึกอยู่

หากการติดตั้งใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ทันที ซึ่งสามารถบันทึกเสียงรอบข้างและ/หรือบันทึกเสียงที่เล่นในอุปกรณ์เพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-2-1] ต้องไม่จัดเก็บเสียงดิบที่บันทึกไว้หรือรูปแบบใดๆ ที่แปลงกลับเป็นเสียงต้นฉบับหรือใกล้เคียงกับต้นฉบับได้ไว้ในพื้นที่เก็บข้อมูลในอุปกรณ์แบบถาวรหรือส่งออกจากอุปกรณ์ เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดเจน

9.8.3. การเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้เพื่อขอความยินยอมจากผู้ใช้ก่อนที่จะอนุญาตให้เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่แชร์ผ่านพอร์ต USB

9.8.4. การจราจรของข้อมูลในเครือข่าย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันสำหรับที่เก็บใบรับรองของผู้ออกใบรับรอง (CA) ที่เชื่อถือได้ของระบบไว้ล่วงหน้าตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
  • [C-0-2] ต้องมาพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า
  • [C-0-3] ต้องแสดงคำเตือนให้ผู้ใช้ทราบว่าอาจมีการติดตามตรวจสอบการรับส่งข้อมูลในเครือข่ายเมื่อเพิ่ม CA รูทของผู้ใช้

หากมีการเปลี่ยนเส้นทางการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องแสดงคำเตือนแก่ผู้ใช้โดยระบุข้อมูลต่อไปนี้
    • การจราจรของข้อมูลในเครือข่ายนั้นอาจถูกตรวจสอบ
    • ระบบจะเปลี่ยนเส้นทางการจราจรของข้อมูลในเครือข่ายนั้นผ่านแอปพลิเคชัน VPN ที่ให้บริการ VPN

หากการติดตั้งใช้งานอุปกรณ์มีกลไกที่เปิดใช้โดยค่าเริ่มต้นซึ่งกำหนดเส้นทางการรับส่งข้อมูลในเครือข่ายผ่านเซิร์ฟเวอร์พร็อกซีหรือเกตเวย์ VPN (เช่น การโหลดบริการ VPN ล่วงหน้าด้วย android.permission.CONTROL_VPN ที่อนุญาต) อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว เว้นแต่ว่าตัวควบคุมนโยบายอุปกรณ์จะเปิดใช้ VPN ผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ผู้ใช้ไม่จําเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับการแจ้งเตือนเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้การอำนวยความสะดวกของผู้ใช้เพื่อเปิดฟังก์ชัน "VPN แบบเปิดตลอดเวลา" ของแอป VPN ของบุคคลที่สาม การดำเนินการดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องปิดใช้การแสดงผลที่สะดวกสำหรับผู้ใช้นี้สำหรับแอปที่ไม่รองรับบริการ VPN แบบเปิดตลอดเวลาในไฟล์ AndroidManifest.xml ผ่านการตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

9.8.5. ตัวระบุอุปกรณ์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องป้องกันไม่ให้แอปเข้าถึงหมายเลขซีเรียลของอุปกรณ์ และ IMEI/MEID, หมายเลขซีเรียลของซิม และ International Mobile Subscriber Identity (IMSI) (หากมี) เว้นแต่แอปจะเป็นไปตามข้อกำหนดข้อใดข้อหนึ่งต่อไปนี้
    • เป็นแอปของผู้ให้บริการที่ลงนามซึ่งได้รับการยืนยันโดยผู้ผลิตอุปกรณ์
    • ได้รับสิทธิ์ READ_PRIVILEGED_PHONE_STATE แล้ว
    • มีสิทธิ์ของผู้ให้บริการตามที่ระบุไว้ในสิทธิ์ของผู้ให้บริการ UICC
    • เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับสิทธิ์ READ_PHONE_STATE
    • (สำหรับหมายเลขซีเรียลของ SIM/ICCID เท่านั้น) มีข้อกำหนดด้านกฎระเบียบท้องถิ่นที่ระบุว่าแอปต้องตรวจหาการเปลี่ยนแปลงข้อมูลระบุตัวตนของผู้สมัครใช้บริการ

9.8.6 การบันทึกเนื้อหา

Android รองรับกลไกสําหรับการติดตั้งใช้งานอุปกรณ์เพื่อบันทึกการโต้ตอบต่อไปนี้ระหว่างแอปพลิเคชันกับผู้ใช้ผ่าน System API ContentCaptureService หรือวิธีอื่นๆ ที่เป็นกรรมสิทธิ์

  • ข้อความและกราฟิกที่แสดงผลบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน AssistStructure API
  • ข้อมูลสื่อ เช่น เสียงหรือวิดีโอที่อุปกรณ์บันทึกหรือเล่น
  • เหตุการณ์การป้อนข้อมูล (เช่น ปุ่ม เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)
  • เหตุการณ์อื่นๆ ที่แอปพลิเคชันส่งไปยังระบบผ่าน Content Capture API หรือ API ที่เป็นกรรมสิทธิ์ที่ทํางานได้แบบเดียวกัน

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลข้างต้นไว้ อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องเข้ารหัสข้อมูลดังกล่าวทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้การเข้ารหัสตามไฟล์ของ Android หรือการเข้ารหัสใดๆ ที่แสดงเป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
  • [C-1-2] ต้องไม่สำรองข้อมูลดิบหรือที่เข้ารหัสโดยใช้วิธีการสำรองข้อมูล Android หรือวิธีการสำรองข้อมูลอื่นๆ
  • [C-1-3] ต้องส่งเฉพาะข้อมูลดังกล่าวทั้งหมดและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัว กลไกการรักษาความเป็นส่วนตัวหมายถึง "กลไกที่อนุญาตให้มีการวิเคราะห์แบบรวมเท่านั้นและป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้จากผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้สํารวจข้อมูลต่อผู้ใช้ได้ (เช่น ติดตั้งใช้งานโดยใช้เทคโนโลยีการรักษาความเป็นส่วนตัวแบบที่แตกต่างกัน เช่น RAPPOR)
  • [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น Account) ในอุปกรณ์ เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้งทุกครั้งที่มีการเชื่อมโยงข้อมูล
  • [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับแอปอื่นๆ เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดเจนทุกครั้งที่แชร์
  • [C-1-6] ต้องให้ผู้ใช้สามารถลบข้อมูลที่ ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์เก็บรวบรวมไว้ได้หากมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์มีบริการที่ใช้ System API ContentCaptureService หรือบริการที่เป็นกรรมสิทธิ์ซึ่งเก็บรวบรวมข้อมูลตามที่อธิบายไว้ข้างต้น บริการดังกล่าวจะต้องดำเนินการดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการจับภาพเนื้อหาด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้ และต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่จับภาพข้อมูลดังกล่าวได้
  • [C-2-2] ต้องไม่อนุญาตให้แอปใดๆ นอกเหนือจากกลไกบริการจับภาพเนื้อหาที่ติดตั้งไว้ล่วงหน้าสามารถจับภาพข้อมูลดังกล่าวได้
  • [C-2-3] ต้องให้ผู้ใช้ปิดใช้บริการจับภาพเนื้อหาได้
  • [C-2-4] ต้องระบุตัวเลือกให้ผู้ใช้จัดการสิทธิ์ Android ที่บริการจับภาพเนื้อหามีไว้ และเป็นไปตามรูปแบบสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้แยกคอมโพเนนต์บริการจับภาพเนื้อหาออกจากคอมโพเนนต์ระบบอื่นๆ เช่น ไม่เชื่อมโยงบริการหรือแชร์รหัสกระบวนการ ยกเว้นในกรณีต่อไปนี้

    • โทรศัพท์ รายชื่อติดต่อ UI ของระบบ และสื่อ

9.8.7. การเข้าถึงคลิปบอร์ด

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่แสดงข้อมูลที่ตัดในคลิปบอร์ด (เช่น ผ่าน ClipboardManager API) เว้นแต่แอปจะเป็น IME เริ่มต้นหรือเป็นแอปที่มีโฟกัสอยู่ในขณะนี้

9.8.8. ตำแหน่ง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมจากผู้ใช้อย่างชัดเจนหรือผู้ใช้เป็นผู้เริ่มดำเนินการ
  • [C-0-2] ต้องให้สิทธิ์แก่ผู้ใช้ในการเข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่ง ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้การสแกน Wi-Fi/บลูทูธเพื่อระบุตำแหน่ง
  • [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] เป็นเซสชันเหตุฉุกเฉินที่ผู้ใช้เริ่ม (เช่น โทรหา 911 หรือส่งข้อความถึง 911)
  • [C-0-4] ต้องรักษาความสามารถของ Emergency Location Bypass API ในการข้ามการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่ต้องเปลี่ยนการตั้งค่า
  • [C-0-5] ต้องตั้งเวลาการแจ้งเตือนเพื่อเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งโดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.9. การเข้ารหัสพื้นที่เก็บข้อมูล

อุปกรณ์ทั้งหมดต้องเป็นไปตามข้อกำหนดของส่วนที่ 9.9.1 อุปกรณ์ที่เปิดตัวใน API ระดับต่ำกว่าเอกสารนี้จะได้รับการยกเว้นจากข้อกำหนดของส่วนที่ 9.9.2 และ 9.9.3 แต่ต้องเป็นไปตามข้อกำหนดในส่วนที่ 9.9 ของเอกสารคำจำกัดความการรองรับของ Android ซึ่งสอดคล้องกับระดับ API ที่อุปกรณ์เปิดตัว

9.9.1. Direct Boot

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้ API โหมดการบูตโดยตรง แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

  • [C-0-2] ยังคงต้องออกอากาศ Intent ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED เพื่อส่งสัญญาณให้แอปพลิเคชันที่รับรู้การบูตโดยตรงทราบว่าตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) พร้อมใช้งานสำหรับผู้ใช้

9.9.2. ข้อกำหนดในการเข้ารหัส

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเข้ารหัสข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรที่ไม่สามารถนําออกได้ของอุปกรณ์
  • [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าประสบการณ์การใช้งานแบบพร้อมใช้งานทันทีเสร็จสมบูรณ์
  • [C-0-3] ต้องปฏิบัติตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นผ่านการใช้การเข้ารหัสตามไฟล์ (FBE)

9.9.3. การเข้ารหัสตามไฟล์

อุปกรณ์ที่เข้ารหัส

  • [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 หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสลับขั้นสูงที่มีความยาวคีย์การเข้ารหัส 256 บิต ซึ่งทำงานในโหมด XTS โดยความยาวเต็มของคีย์คือ 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ใน https://github.com/google/adiantum
  • [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS หรือ Adiantum

  • [C-1-12] ต้องใช้ AES-256-XTS สำหรับเนื้อหาไฟล์และ AES-256-CBC-CTS สำหรับชื่อไฟล์ (แทน Adiantum) หากอุปกรณ์มีคำสั่ง Advanced Encryption Standard (AES) คำสั่ง AES คือส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86 หากอุปกรณ์ไม่มีคำสั่ง AES อุปกรณ์อาจใช้ Adiantum

  • คีย์ที่ปกป้องพื้นที่เก็บข้อมูล CE และ DE

  • [C-1-7] ต้องเข้ารหัสผูกกับคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์

  • [C-1-8] คีย์ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบหน้าจอล็อกของผู้ใช้
  • [C-1-9] คุณต้องเชื่อมโยงคีย์ CE กับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบหน้าจอล็อก
  • [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ คีย์ CE หรือ DE ของผู้ใช้ต้องไม่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
  • [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่รองรับโดยบังคับ

  • [C-SR] ขอแนะนำอย่างยิ่งให้เข้ารหัสข้อมูลเมตาของระบบไฟล์ เช่น ขนาดไฟล์ สิทธิ์การเป็นเจ้าของ โหมด และแอตทริบิวต์แบบขยาย (xattr) ด้วยคีย์ที่เข้ารหัสซึ่งเชื่อมโยงกับรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์

  • ควรทําให้แอปที่จําเป็นซึ่งติดตั้งไว้ล่วงหน้า (เช่น การปลุก โทรศัพท์ Messenger) รับรู้การบูตโดยตรง

โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ตามที่ต้องการโดยอิงตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนล Linux

9.10. ความสมบูรณ์ของอุปกรณ์

ข้อกำหนดต่อไปนี้ช่วยให้มั่นใจได้ว่าสถานะความสมบูรณ์ของอุปกรณ์มีความโปร่งใส การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() อย่างถูกต้องว่าสถานะ Bootloader อนุญาตให้แฟลชอิมเมจระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันเก่าซึ่งไม่มีเมธอด API ของระบบใหม่นี้

  • [C-0-2] ต้องรองรับการบูตที่ยืนยันแล้วเพื่อรักษาความสมบูรณ์ของอุปกรณ์

หากมีการเปิดตัวการใช้งานอุปกรณ์ไปแล้วโดยไม่รองรับการบูตที่ยืนยันแล้วใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนดนี้

การเปิดเครื่องที่ได้รับการยืนยันเป็นฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์นี้ อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์แพลตฟอร์ม android.software.verified_boot
  • [C-1-2] ต้องทำการยืนยันในลำดับการบูตทุกรายการ
  • [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่แก้ไขไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือ และดำเนินการไปจนถึงพาร์ติชันระบบ
  • [C-1-4] ต้องใช้การยืนยันแต่ละระยะเพื่อตรวจสอบความสมบูรณ์และความถูกต้องของไบต์ทั้งหมดในขั้นถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นถัดไป
  • [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่มีประสิทธิภาพเทียบเท่ากับคําแนะนําปัจจุบันจาก NIST สําหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
  • [C-1-6] ต้องไม่อนุญาตให้บูตจนเสร็จสมบูรณ์เมื่อการยืนยันระบบไม่สำเร็จ เว้นแต่ผู้ใช้จะยินยอมให้พยายามบูตต่อไป ซึ่งในกรณีนี้ ต้องไม่ใช้ข้อมูลจากบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยัน
  • [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ยืนยันแล้วในอุปกรณ์ เว้นแต่ว่าผู้ใช้จะปลดล็อกโปรแกรมบูตอย่างชัดเจน
  • [C-SR] หากมีชิปแยกหลายตัวในอุปกรณ์ (เช่น วิทยุ หน่วยประมวลผลภาพเฉพาะ) เราขอแนะนำอย่างยิ่งให้ยืนยันทุกขั้นตอนในการบูตชิปแต่ละตัว
  • [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่ป้องกันการงัดแงะ: สำหรับจัดเก็บข้อมูลว่าปลดล็อก bootloader แล้วหรือยัง พื้นที่เก็บข้อมูลที่ตรวจจับการดัดแปลงได้หมายความว่าโปรแกรมบูตสามารถตรวจจับได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และกำหนดให้ต้องยืนยันด้วยตนเองก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ล็อกเป็นโหมด Bootloader ปลดล็อก
  • [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันบูต พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้สำหรับกำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
  • [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดด้วยเชนความน่าเชื่อถือที่รูทในพาร์ติชันที่ได้รับการปกป้องโดย Verified Boot
  • [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] ต้องตรวจสอบว่าผู้ใช้สามารถตรวจสอบและอนุมัติข้อความที่แสดงแม้ในกรณีที่ระบบปฏิบัติการ Android รวมถึงเคอร์เนลถูกบุกรุก

9.11. คีย์และข้อมูลเข้าสู่ระบบ

ระบบ Keystore ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์ และใช้คีย์ดังกล่าวในการดำเนินการเข้ารหัสผ่าน KeyChain API หรือ Keystore API การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องอนุญาตให้นำเข้าหรือสร้างคีย์ได้อย่างน้อย 8,192 คีย์
  • [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องจำกัดอัตราการพยายามและต้องมีอัลกอริทึมการลดจำนวนครั้งแบบทวีคูณ หากพยายามเกิน 150 ครั้ง ระยะเวลารอต้องนานอย่างน้อย 24 ชั่วโมงต่อการพยายาม 1 ครั้ง
  • ควรไม่จํากัดจํานวนคีย์ที่สร้างได้

เมื่อการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยก
  • [C-1-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันการแฮชของกลุ่ม MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Keystore ของ Android รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่ก็มีโซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามและปลอดภัยเป็นทางเลือกอื่น
  • [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อตรวจสอบสิทธิ์สำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบของหน้าจอล็อกต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการเรียกใช้แบบแยกส่วนเท่านั้นที่ดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
  • [C-1-4] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงนามในการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คุณต้องแชร์คีย์การรับรองที่ใช้ลงนามในอุปกรณ์จํานวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์ดังกล่าวเป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย ระบบอาจใช้คีย์อื่นสำหรับ 100,000 หน่วยแต่ละหน่วย

โปรดทราบว่าหากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นข้อกำหนดในการมีคีย์สโตร์ที่สำรองข้อมูลโดยสภาพแวดล้อมการเรียกใช้แบบแยกและรองรับการรับรองคีย์ เว้นแต่จะมีการประกาศใช้ฟีเจอร์ android.hardware.fingerprint ซึ่งกำหนดให้ต้องมีคีย์สโตร์ที่สำรองข้อมูลโดยสภาพแวดล้อมการเรียกใช้แบบแยก

  • [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกการหมดเวลาของโหมดสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นล็อก โดยมีเวลาหมดเวลาที่อนุญาตขั้นต่ำไม่เกิน 15 วินาที

9.11.1. หน้าจอล็อกและการตรวจสอบสิทธิ์ที่ปลอดภัย

การใช้งาน AOSP เป็นไปตามรูปแบบการตรวจสอบสิทธิ์แบบเป็นชั้น ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตาม Knowledge Factory สามารถรองรับข้อมูลไบโอเมตริกที่รัดกุมรอง หรือรูปแบบที่อ่อนแอกว่าในระดับที่สาม

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าวิธีการตรวจสอบสิทธิ์หลักเพียงวิธีใดวิธีหนึ่งต่อไปนี้
    • PIN เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
    • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 เท่านั้น

โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะมีลักษณะดังนี้

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกโดยอิงตามข้อมูลที่เป็นความลับที่ทราบและใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อใช้เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ ให้ทำดังนี้

  • [C-3-1] เอนโทรปีของอินพุตที่มีความยาวน้อยที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ที่นำมาใช้งานและระบุไว้ใน AOSP
  • [C-3-4] คุณต้องปิดใช้วิธีการตรวจสอบสิทธิ์ใหม่เมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านวิธีการ DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_SOMETHING
  • [C-3-5] วิธีการตรวจสอบสิทธิ์ใหม่ต้องเปลี่ยนไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยให้ผู้ใช้ทราบอย่างชัดเจนว่าระบบจะไม่สำรองข้อมูลบางอย่างเพื่อรักษาความเป็นส่วนตัวของผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอล็อก และใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามข้อมูลไบโอเมตริกเพื่อให้ระบบถือว่านี่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการใหม่นี้จะมีลักษณะดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 7.3.10 สำหรับความสะดวก
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่เป็นความลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้ใช้เฉพาะการตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ได้ตั้งค่านโยบายฟีเจอร์การป้องกันหน้าจอโดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() พร้อม Flag ข้อมูลไบโอเมตริกที่เกี่ยวข้อง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับการตรวจสอบสิทธิ์ที่รัดกุมตามที่อธิบายไว้ในส่วนที่ 7.3.10 ให้ทำดังนี้

  • [C-5-1] วิธีการต้องปิดใช้หากแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านวิธีการ DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-5-2] ผู้ใช้ต้องได้รับการแจ้งให้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากผ่านไป 4 ชั่วโมงโดยไม่มีการใช้งาน ระบบจะรีเซ็ตระยะเวลาหมดเวลาในกรณีที่ไม่มีการใช้งานหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์เรียบร้อยแล้ว
  • [C-5-3] วิธีการต้องไม่ถือว่ามีความปลอดภัยเท่ากับหน้าจอล็อก และจะต้องเป็นไปตามข้อกำหนดที่ขึ้นต้นด้วย C-8 ในส่วนนี้ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อก และวิธีการตรวจสอบสิทธิ์ใหม่นั้นอิงตามโทเค็นจริงหรือตำแหน่ง ให้ทำดังนี้

  • [C-6-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่เป็นความลับที่ทราบและเป็นไปตามข้อกำหนดเพื่อให้ระบบถือว่าหน้าจอล็อกปลอดภัย
  • [C-6-2] คุณต้องปิดใช้วิธีการใหม่และอนุญาตให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพียงวิธีใดวิธีหนึ่งในการปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ตั้งค่านโยบายด้วยวิธีการ DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือวิธีการ DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-6-3] ผู้ใช้ต้องได้รับการขอใช้การตรวจสอบสิทธิ์หลักอย่างใดอย่างหนึ่งที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 4 ชั่วโมงหรือน้อยกว่านั้น
  • [C-6-4] วิธีการใหม่ต้องไม่ถือว่ามีความปลอดภัยเท่ากับหน้าจอล็อก และต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีตัวแทนความน่าเชื่อถืออย่างน้อย 1 รายที่ใช้ TrustAgentService System API อุปกรณ์จะมีลักษณะดังนี้

  • [C-7-1] ต้องมีข้อความที่ชัดเจนในเมนูการตั้งค่าและบนหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ออกไปหรือตัวแทนที่เชื่อถือสามารถปลดล็อกอุปกรณ์ไว้ได้ ตัวอย่างเช่น AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงคำอธิบายข้อความสำหรับ "การตั้งค่าล็อกอัตโนมัติ" และ "ปุ่มเปิด/ปิดล็อกทันที" ในเมนูการตั้งค่า รวมถึงไอคอนที่แยกแยะได้ในหน้าจอล็อก
  • [C-7-2] ต้องปฏิบัติตามและใช้ API ของตัวแทนความน่าเชื่อถือทั้งหมดในคลาส DevicePolicyManager อย่างเต็มรูปแบบ เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
  • [C-7-3] ต้องไม่ใช้งานฟังก์ชัน TrustAgentService.addEscrowToken() อย่างเต็มรูปแบบในอุปกรณ์ที่ใช้เป็นอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) แต่อาจใช้งานฟังก์ชันดังกล่าวอย่างเต็มรูปแบบในการใช้งานอุปกรณ์ที่มักแชร์กัน (เช่น อุปกรณ์ Android TV หรืออุปกรณ์ยานยนต์)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่จัดเก็บคีย์การเข้ารหัสหรือโทเค็นตัวกลางในอุปกรณ์เดียวกับที่ใช้คีย์ เช่น อนุญาตให้ใช้คีย์ที่จัดเก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้ในทีวี
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบถึงผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นตัวกลางเพื่อถอดรหัสพื้นที่เก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง
  • [C-7-8] ผู้ใช้ต้องได้รับการตรวจสอบสิทธิ์ด้วยวิธีตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างใดอย่างหนึ่งอย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น เว้นแต่ว่าจะมีความเสี่ยงต่อความปลอดภัยของผู้ใช้ (เช่น การทำให้ผู้ขับขี่เสียสมาธิ)
  • [C-7-9] ผู้ใช้ต้องได้รับการตรวจสอบสิทธิ์ด้วยวิธีใดวิธีหนึ่งสำหรับการรับรองความถูกต้องหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากหมดเวลาหยุดทำงาน 4 ชั่วโมง เว้นแต่ว่าจะมีข้อกังวลเกี่ยวกับความปลอดภัยของผู้ใช้ (เช่น การทำให้ผู้ขับขี่เสียสมาธิ) ระบบจะรีเซ็ตระยะเวลาหมดเวลาในกรณีที่ไม่มีการใช้งานหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์เรียบร้อยแล้ว
  • [C-7-10] ต้องไม่ถือว่าหน้าจอล็อกเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
  • [C-7-11] ต้องไม่อนุญาตให้ TrustAgent ในอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) ปลดล็อกอุปกรณ์ และสามารถใช้ TrustAgent เพื่อเก็บอุปกรณ์ที่ปลดล็อกไว้แล้วไว้ในสถานะปลดล็อกได้สูงสุด 4 ชั่วโมง การใช้งาน TrustManagerService เริ่มต้นใน AOSP เป็นไปตามข้อกำหนดนี้
  • [C-7-12] ต้องใช้ช่องทางการสื่อสารที่ปลอดภัยจากการเข้ารหัส (เช่น UKEY2) เพื่อส่งโทเค็นที่เก็บไว้จากอุปกรณ์จัดเก็บไปยังอุปกรณ์เป้าหมาย

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อกการป้องกันหน้าจอ ให้ทำดังนี้

  • [C-8-1] คุณต้องปิดใช้วิธีการใหม่เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านวิธีการ DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-8-2] ผู้ใช้ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่กำหนดโดย DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-8-3] แอปต้องไม่เปิดเผย API ให้แอปของบุคคลที่สามใช้เพื่อเปลี่ยนสถานะล็อก

9.11.2. StrongBox

ระบบคีย์สโตร์ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ รวมถึงสภาพแวดล้อมการดำเนินการแบบแยกต่างหากตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยโดยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 ถึง C-1-11 ด้านล่างระบุข้อกำหนดที่อุปกรณ์ต้องมีคุณสมบัติตรงตามจึงจะถือเป็น StrongBox ได้

การติดตั้งใช้งานอุปกรณ์ที่มีโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ

  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ StrongBox StrongBox อาจมีความจำเป็นในรุ่นต่อๆ ไป

หากการติดตั้งใช้งานอุปกรณ์รองรับ StrongBox อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE

  • [C-1-2] ต้องมีฮาร์ดแวร์ความปลอดภัยเฉพาะที่ใช้สำรองข้อมูลคีย์สโตร์และการตรวจสอบสิทธิ์ผู้ใช้อย่างปลอดภัย ฮาร์ดแวร์ความปลอดภัยเฉพาะอาจใช้เพื่อวัตถุประสงค์อื่นๆ ด้วย

  • [C-1-3] ต้องมี CPU แบบแยกต่างหากที่ไม่ได้แชร์แคช, DRAM, หน่วยประมวลผลร่วม หรือทรัพยากรหลักอื่นๆ กับหน่วยประมวลผลแอปพลิเคชัน (AP)

  • [C-1-4] ต้องตรวจสอบว่าอุปกรณ์ต่อพ่วงที่แชร์กับ AP ไม่สามารถเปลี่ยนแปลงการประมวลผลของ StrongBox ไม่ว่าในทางใดก็ตาม หรือรับข้อมูลจาก StrongBox AP อาจปิดใช้หรือบล็อกการเข้าถึง StrongBox

  • [C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำพอสมควร (+-10%) ซึ่งไม่ได้รับผลกระทบจากการดัดแปลงของ AP

  • [C-1-6] ต้องมีเครื่องมือสร้างตัวเลขสุ่มจริงที่สร้างเอาต์พุตแบบกระจายอย่างสม่ำเสมอและคาดเดาไม่ได้

  • [C-1-7] ต้องมีการป้องกันการงัดแงะ ซึ่งรวมถึงการป้องกันการเจาะทะลุทางกายภาพและการขัดข้อง

  • [C-1-8] ต้องมีการป้องกันช่องทางข้าง ซึ่งรวมถึงการป้องกันการรั่วไหลของข้อมูลผ่านช่องทางข้างของพลังงาน ช่วงเวลา รังสีแม่เหล็กไฟฟ้า และรังสีความร้อน

  • [C-1-9] ต้องมีพื้นที่เก็บข้อมูลที่ปลอดภัยซึ่งรับประกันความลับ ความสมบูรณ์ ความถูกต้อง ความสอดคล้อง และความใหม่ของเนื้อหา พื้นที่เก็บข้อมูลต้องอ่านหรือแก้ไขไม่ได้ เว้นแต่ StrongBox API จะอนุญาต

  • หากต้องการตรวจสอบการปฏิบัติตามข้อกำหนด [C-1-3] ถึง [C-1-9] การติดตั้งใช้งานอุปกรณ์ต้องมีลักษณะดังนี้

    • [C-1-10] ต้องมีฮาร์ดแวร์ที่ผ่านการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองในระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามเกณฑ์ร่วมกันสำหรับการใช้งานศักยภาพในการโจมตีกับสมาร์ทการ์ด
    • [C-1-11] ต้องมีเฟิร์มแวร์ที่ประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองในระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามเกณฑ์ร่วมกันสำหรับการใช้งานศักยภาพในการโจมตีกับสมาร์ทการ์ด
    • [C-SR] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ประเมินโดยใช้เป้าหมายด้านความปลอดภัยระดับความเชื่อมั่นในการประเมิน (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้การป้องกันการโจมตีจากบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถผลิตเฟิร์มแวร์ที่ทำให้ StrongBox เปิดเผยความลับ เพื่อเลี่ยงข้อกำหนดด้านความปลอดภัยด้านฟังก์ชันการทำงาน หรือเพื่อเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่เราแนะนำในการใช้งาน IAR คืออนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการให้รหัสผ่านผู้ใช้หลักผ่าน HAL ของ IAuthSecret

9.12. การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องจัดเตรียมกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] MUST delete all data on the userdata filesystem.
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่เป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลักเรียกใช้ DevicePolicyManager.wipeData() API
  • อาจให้ตัวเลือกการลบข้อมูลอย่างรวดเร็วซึ่งจะดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการบูตอย่างปลอดภัย

Android มีโหมดปลอดภัย ซึ่งช่วยให้ผู้ใช้บูตเข้าสู่โหมดที่อนุญาตให้แอประบบที่ติดตั้งไว้ล่วงหน้าเท่านั้นทำงานได้ และปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการบูตอย่างปลอดภัย" ซึ่งจะช่วยให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การติดตั้งใช้งานอุปกรณ์มีดังนี้

  • [SR] ขอแนะนําอย่างยิ่งให้ใช้โหมดการบูตที่ปลอดภัย

หากการใช้งานอุปกรณ์ใช้โหมดการบูตอย่างปลอดภัย อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยในลักษณะที่ไม่สามารถหยุดชะงักจากแอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ ยกเว้นในกรณีที่แอปของบุคคลที่สามเป็นผู้ควบคุมนโยบายอุปกรณ์และตั้งค่า Flag UserManager.DISALLOW_SAFE_BOOT เป็น "จริง"

  • [C-1-2] ต้องอนุญาตให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามในโหมดปลอดภัยได้

  • ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดการบูตอย่างปลอดภัยจากเมนูการบูตโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการบูตปกติ

9.14. การแยกระบบยานพาหนะ

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายยานพาหนะ เช่น CAN Bus

การแลกเปลี่ยนข้อมูลสามารถรักษาความปลอดภัยได้ด้วยการใช้ฟีเจอร์ด้านความปลอดภัยที่อยู่ต่ำกว่าเลเยอร์เฟรมเวิร์ก Android เพื่อป้องกันไม่ให้มีการโต้ตอบกับระบบย่อยเหล่านี้โดยไม่ตั้งใจหรือเป็นอันตราย

9.15 น. แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์การเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องส่งคืนแพ็กเกจการสมัครใช้บริการไปยังแอปของผู้ให้บริการเครือข่ายมือถือที่เป็นผู้จัดหาแพ็กเกจนั้นในตอนแรกเท่านั้น
  • [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
  • [C-0-3] ต้องอนุญาตให้ลบล้างได้เฉพาะจากแอปของผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจการสมัครใช้บริการที่ถูกต้องในปัจจุบัน เช่น SubscriptionManager.setSubscriptionOverrideCongested()

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การติดตั้งใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราขอแนะนำอย่างยิ่งให้ผู้ใช้งานอุปกรณ์ทำการเปลี่ยนแปลงน้อยที่สุดเท่าที่จะเป็นไปได้กับการใช้งาน Android อ้างอิงและการใช้งานที่ต้องการซึ่งพร้อมใช้งานจากโครงการโอเพนซอร์ส Android วิธีนี้จะช่วยลดความเป็นไปได้ที่จะเกิดข้อบกพร่องซึ่งทําให้ใช้งานร่วมกันไม่ได้ ซึ่งอาจต้องทํางานใหม่และอาจต้องมีการอัปเดตอุปกรณ์

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) ซึ่งมีอยู่ในโปรเจ็กต์โอเพนซอร์สของ Android โดยใช้ซอฟต์แวร์เวอร์ชันสุดท้ายที่พร้อมจำหน่ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่ CTS มีความคลุมเครือและสำหรับการติดตั้งใช้งานบางส่วนของซอร์สโค้ดอ้างอิงอีกครั้ง

CTS ออกแบบมาเพื่อใช้งานบนอุปกรณ์จริง CTS เองก็อาจมีข้อบกพร่องเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันเป็นอิสระจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS เวอร์ชันต่างๆ สำหรับ Android 10

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องผ่าน CTS เวอร์ชันล่าสุดที่มีให้บริการ ณ เวลาที่มีการสร้างซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การติดตั้งใช้งานอ้างอิงในต้นไม้ซอร์สโค้ดแบบเปิดของ Android ให้ได้มากที่สุด

10.2. โปรแกรมตรวจสอบ CTS

CTS Verifier จะรวมอยู่ในชุดทดสอบความเข้ากันได้ และมีไว้ให้ผู้ปฏิบัติงานเป็นคนเรียกใช้เพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานของกล้องและเซ็นเซอร์ที่ถูกต้อง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเรียกใช้เคสที่เกี่ยวข้องทั้งหมดในโปรแกรมตรวจสอบ CTS อย่างถูกต้อง

CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องผ่านทุกการทดสอบฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง ต้องเรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง

ระบบอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่เอกสารนิยามความเข้ากันได้นี้ระบุว่าไม่บังคับ

  • [C-0-2] อุปกรณ์และบิลด์ทุกรุ่นต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ติดตั้งใช้งานอุปกรณ์จึงไม่จำเป็นต้องเรียกใช้โปรแกรมตรวจสอบ CTS กับบิลด์ที่แตกต่างกันเพียงเล็กน้อย กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่าน CTS Verifier เฉพาะชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมอยู่ อาจไม่ต้องทำการทดสอบ CTS Verifier

11. ซอฟต์แวร์ที่อัปเดตได้

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" กล่าวคือ คุณอาจต้องรีสตาร์ทอุปกรณ์ คุณใช้วิธีการใดก็ได้ ตราบใดที่วิธีการดังกล่าวสามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ ตัวอย่างเช่น แนวทางใดๆ ต่อไปนี้จะเป็นไปตามข้อกำหนดนี้

    • การดาวน์โหลด "ผ่านอากาศ (OTA)" ที่มีการอัปเดตแบบออฟไลน์ผ่านการรีบูต
    • การอัปเดตแบบ "ใช้การเชื่อมต่ออินเทอร์เน็ตมือถือจากมือถือ" ผ่าน USB จาก PC โฮสต์
    • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในพื้นที่เก็บข้อมูลแบบถอดได้

  • [C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android เวอร์ชัน upstream มีกลไกการอัปเดตที่เป็นไปตามข้อกำหนดนี้

  • [C-0-3] การอัปเดตทั้งหมดต้องได้รับการลงนาม และกลไกการอัปเดตในอุปกรณ์ต้องยืนยันการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้กลไกการลงนามเพื่อแฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่ออินเทอร์เน็ตแบบไม่จำกัด เช่น โปรไฟล์ 802.11 หรือ PAN (เครือข่ายส่วนบุคคล) ของบลูทูธ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับการดาวน์โหลด OTA ด้วยการอัปเดตแบบออฟไลน์ผ่านการรีบูต

สำหรับการติดตั้งใช้งานอุปกรณ์ที่เปิดตัวด้วย Android 6.0 ขึ้นไป กลไกการอัปเดตควรรองรับการยืนยันว่าอิมเมจระบบเป็นไบนารีที่เหมือนกับผลลัพธ์ที่คาดไว้หลังจาก OTA การใช้งาน OTA ตามบล็อกในโปรเจ็กต์โอเพนซอร์ส Android ต้นทางซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้

นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ควรรองรับการอัปเดตระบบ A/B AOSP ใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการบูต

หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากที่เปิดตัวแล้ว แต่อยู่ภายในอายุการใช้งานผลิตภัณฑ์ที่เหมาะสมซึ่งพิจารณาโดยปรึกษากับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม ให้ทำดังนี้

  • [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่ใช้ได้ซึ่งเป็นไปตามกลไกที่อธิบายไป

Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ หากระบบย่อยการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-3-1] ต้องใช้งานลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

สรุปการเปลี่ยนแปลงนิยามความเข้ากันได้ในรุ่นนี้

สรุปการเปลี่ยนแปลงในส่วนต่างๆ มีดังนี้

  1. บทนำ
  2. ประเภทอุปกรณ์
  3. ซอฟต์แวร์
  4. การบรรจุแอปพลิเคชัน
  5. มัลติมีเดีย
  6. เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
  7. ความเข้ากันได้ของฮาร์ดแวร์
  8. ประสิทธิภาพและกำลัง
  9. รูปแบบการรักษาความปลอดภัย
  10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
  11. ซอฟต์แวร์ที่อัปเดตได้
  12. บันทึกการเปลี่ยนแปลงของเอกสาร
  13. ติดต่อเรา

12.1. เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง

การเปลี่ยนแปลงจะมีเครื่องหมายดังต่อไปนี้

  • CDD
    การเปลี่ยนแปลงที่สำคัญในข้อกำหนดด้านความเข้ากันได้

  • เอกสาร
    การเปลี่ยนแปลงที่เกี่ยวข้องกับความสวยงามหรือบิลด์

เพิ่มพารามิเตอร์ของ URL pretty=full และ no-merges ต่อท้าย URL ของบันทึกการเปลี่ยนแปลงเพื่อให้ดูได้ดีที่สุด

13. ติดต่อเรา

คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android เพื่อขอคำชี้แจงหรือแจ้งปัญหาที่คุณคิดว่าเอกสารไม่ได้กล่าวถึง