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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. ฮาร์ดแวร์

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

  • [7.1.1.1/H-0-1] ต้องมีจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอที่วัดขนาดได้อย่างน้อย 2.2 นิ้วที่ขอบด้านสั้น และ 3.4 นิ้วที่ขอบด้านยาว

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

  • [7.1.1.1/H-0-2] ต้องรองรับการคอมโพสิชัน GPU ของบัฟเฟอร์กราฟิกที่มีขนาดใหญ่อย่างน้อยเท่ากับความละเอียดสูงสุดของจอแสดงผลในตัว

  • [7.1.1.1/H-0-3]* ต้องแมปUI_MODE_NORMALจอแสดงผลแต่ละจอที่พร้อมให้บริการสำหรับแอปพลิเคชันของบุคคลที่สามไปยังพื้นที่แสดงผลจริงที่ปราศจากสิ่งกีดขวางซึ่งมีขนาดอย่างน้อย 2.2 นิ้วที่ขอบด้านสั้นและ 3.4 นิ้วที่ขอบด้านยาว

  • [7.1.1.3/H-0-1]* ต้องตั้งค่าDENSITY_DEVICE_STABLEเป็น 92% ขึ้นไปของความละเอียดจริงของจอแสดงผลที่เกี่ยวข้อง

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

หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถืออ้างว่ารองรับจอแสดงผลแบบ 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.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการสร้างโปรไฟล์ GPU หรือไม่ผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support

หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือประกาศการรองรับผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support การดำเนินการต่อไปนี้จะเกิดขึ้น

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [7.4.3/H] ควรรองรับ Bluetooth และ Bluetooth LE

การติดตั้งใช้งานอุปกรณ์พกพาที่รองรับ Bluetooth LE

  • [7.4.3/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับการขยายความยาวของแพ็กเก็ตข้อมูล Bluetooth LE

สิ้นสุดข้อกำหนดใหม่

หากอุปกรณ์รองรับโปรโตคอล Wi-Fi Neighbor Awareness Networking (NAN) โดยประกาศ PackageManager.FEATURE_WIFI_AWARE และตำแหน่ง Wi-Fi (เวลาไปกลับของ Wi-Fi หรือ RTT) โดยประกาศ PackageManager.FEATURE_WIFI_RTT อุปกรณ์จะดำเนินการต่อไปนี้

  • [7.4.2.5/H-1-1] ต้องรายงานระยะสัญญาณอย่างถูกต้องภายใน +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นต์ไทล์ที่ 68 (ตามที่คำนวณด้วยฟังก์ชันการแจกแจงแบบสะสม), +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นต์ไทล์ที่ 68, +/-4 เมตรที่แบนด์วิดท์ 40 MHz ที่เปอร์เซ็นต์ไทล์ที่ 68 และ +/-8 เมตรที่แบนด์วิดท์ 20 MHz ที่เปอร์เซ็นต์ไทล์ที่ 68 ที่ระยะ 10 ซม., 1 ม., 3 ม. และ 5 ม. ตามที่สังเกตผ่าน WifiRttManager#startRanging Android API

  • [7.4.2.5/H-SR-1] ขอแนะนำอย่างยิ่งให้รายงานระยะสัญญาณอย่างถูกต้องภายใน +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นต์ไทล์ที่ 90 (คำนวณด้วยฟังก์ชันการแจกแจงแบบสะสม), +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นต์ไทล์ที่ 90, +/-4 เมตรที่แบนด์วิดท์ 40 MHz ที่เปอร์เซ็นต์ไทล์ที่ 90 และ +/-8 เมตรที่แบนด์วิดท์ 20 MHz ที่เปอร์เซ็นต์ไทล์ที่ 90 ที่ระยะ 10 ซม. ตามที่สังเกตผ่าน WifiRttManager#startRanging Android API

เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในการปรับเทียบการปรากฏ

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

  • [7.4.3/H-1-3] ต้องวัดและชดเชยค่าออฟเซ็ตของ Rx เพื่อให้ค่ามัธยฐานของ BLE RSSI เป็น -50dBm +/-15 dB ที่ระยะ 1 ม. จากอุปกรณ์อ้างอิงที่ส่งที่ ADVERTISE_TX_POWER_HIGH
  • [7.4.3/H-1-4] ต้องวัดและชดเชยค่าออฟเซ็ต Tx เพื่อให้ค่ามัธยฐานของ BLE RSSI เป็น -50dBm +/-15 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่วางไว้ในระยะ 1 เมตรและส่งที่ ADVERTISE_TX_POWER_HIGH

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

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

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

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

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

  • [7.6.1/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเฉพาะพื้นที่ผู้ใช้ 32 บิต (ทั้งแอปและโค้ดระบบ)

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

  • [7.6.1/H-1-1] ต้องรองรับ ABI เพียงรายการเดียว (64 บิตเท่านั้นหรือ 32 บิตเท่านั้น)

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีพอร์ต 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-1] ขอแนะนำอย่างยิ่งเมื่อเชื่อมต่ออุปกรณ์ต่อพ่วงเสียง USB-C ให้ดำเนินการแจกแจงตัวระบุ USB, ระบุประเภทขั้วต่อ และออกอากาศ Intent ACTION_HEADSET_PLUG ในเวลาน้อยกว่า 1, 000 มิลลิวินาที

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หาก สําหรับการติดตั้งใช้งานในอุปกรณ์พกพา ที่ประกาศ android.hardware.audio.output และ android.hardware.microphone อุปกรณ์ดังกล่าว ต้องเป็นไปตามข้อกําหนด RTL และ TTL ในส่วน 5.6

  • [5.6/H-1-1] ต้องมีเวลาในการตอบสนองแบบไปกลับต่อเนื่องเฉลี่ยไม่เกิน 300 มิลลิวินาทีจากการวัด 5 ครั้ง โดยความเบี่ยงเบนสัมบูรณ์เฉลี่ยต้องน้อยกว่า 30 มิลลิวินาทีในเส้นทางข้อมูลต่อไปนี้ "ลำโพงกับไมโครโฟน" อะแดปเตอร์ loopback 3.5 มม. (หากรองรับ) loopback ผ่าน USB (หากรองรับ)

  • [5.6/H-1-2] ต้องมีเวลาในการตอบสนองโดยเฉลี่ยของฟีเจอร์แตะเพื่อส่งเสียงที่ 300 มิลลิวินาทีหรือน้อยกว่าจากการวัดอย่างน้อย 5 ครั้งในเส้นทางข้อมูลจากลำโพงไปยังไมโครโฟน

สิ้นสุดข้อกำหนดใหม่

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

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

  • [7.10/H] ควรวางตัวกระตุ้นไว้ใกล้กับตำแหน่งที่ผู้ใช้มักจะจับหรือสัมผัสอุปกรณ์ด้วยมือ

  • [7.10/H] ควรย้ายตัวกระตุ้นการสัมผัสในแนว X (ซ้าย-ขวา) ของการวางแนวธรรมชาติของอุปกรณ์

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

  • [7.10/H] ควรมีย่านความถี่เรโซแนนซ์ของ LRA ในแนวแกน X ต่ำกว่า 200 Hz

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

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.2/H-0-3] AV1

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

  • [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
  • [5.3/H-0-6] AV1

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

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

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

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

  • [3.8.3/H-1-1] ต้องใช้ลักษณะการปักหมุดหน้าจอและให้เมนูการตั้งค่าแก่ผู้ใช้เพื่อเปิด/ปิดฟีเจอร์

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

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

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

  • [3.8.4/H-1-1]* ต้องแสดงการแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนimportance:high

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

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

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

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

  • [3.8.16/H-1-1] ต้องประกาศ Flag android.software.controls ของฟีเจอร์ และตั้งค่าเป็น true
  • [3.8.16/H-1-2] ต้องให้ผู้ใช้สามารถเพิ่ม แก้ไข เลือก และใช้งานการควบคุมอุปกรณ์ที่ชื่นชอบจากการควบคุมที่ลงทะเบียนโดยแอปพลิเคชันของบุคคลที่สามผ่าน ControlsProviderService และ Control API
  • [3.8.16/H-1-3] ต้องให้สิทธิ์เข้าถึงการอำนวยความสะดวกนี้แก่ผู้ใช้ภายใน 3 การโต้ตอบจาก Launcher เริ่มต้น

  • [3.8.16/H-1-4] ต้องแสดงผลชื่อและไอคอนของแอปของบุคคลที่สามแต่ละแอปที่ให้บริการควบคุมผ่าน ControlsProviderService API รวมถึงช่องที่ระบุซึ่งได้จาก Control API อย่างถูกต้องในการแสดงผลที่ผู้ใช้มองเห็น

  • [3.8.16/H-1-5] ต้องให้ผู้ใช้เลือกไม่ใช้การควบคุมอุปกรณ์แบบไม่ซับซ้อนที่ผ่านการรับรองของแอปจากการควบคุมที่แอปพลิเคชันของบุคคลที่สามลงทะเบียนไว้ผ่าน ControlsProviderService และ Control Control.isAuthRequired API

  • [3.8.16/H-1-6] การติดตั้งใช้งานอุปกรณ์ ต้องแสดงผลการแสดงผลที่ผู้ใช้สามารถโต้ตอบได้อย่างถูกต้อง ดังนี้

    • หากอุปกรณ์ตั้งค่า config_supportsMultiWindow=true และแอปประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY ในประกาศ ControlsProviderService รวมถึง ComponentName ของกิจกรรมที่ถูกต้อง (ตามที่ API กำหนด) แอปต้องฝังกิจกรรมดังกล่าวไว้ในโอกาสในการให้ประสบการณ์ของผู้ใช้นี้
    • หากแอปไม่ได้ประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY จะต้องแสดงผลฟิลด์ที่ระบุตามที่ API ของ ControlsProviderService ระบุไว้ รวมถึงฟิลด์ที่ระบุซึ่ง API ของ Control ระบุไว้

  • [3.8.16/H-1-7] หากแอปประกาศข้อมูลเมตา META_DATA_PANEL_ACTIVITY จะต้องส่งค่าของการตั้งค่าที่ระบุไว้ใน [3.8.16/H-1-5] โดยใช้ EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS เมื่อเปิดใช้งานกิจกรรมที่ฝัง

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

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

  • [3.8.17/H-1-1] ต้องแสดงการยืนยันให้ผู้ใช้ทราบว่าระบบคัดลอกข้อมูลไปยังคลิปบอร์ดแล้ว (เช่น ภาพขนาดย่อหรือการแจ้งเตือน "คัดลอกเนื้อหาแล้ว") นอกจากนี้ ให้ระบุด้วยว่าระบบจะซิงค์ข้อมูลคลิปบอร์ดในอุปกรณ์ต่างๆ หรือไม่

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

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

  • [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่จัดการผ่าน android.software.managed_usersฟีเจอร์ Flag

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

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

  • [3.2.3.1/ H-1-1] ต้องมีกิจกรรมที่จัดการ Intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY เมื่อเปิดฟังก์ชันการแยก กิจกรรมต้องได้รับการปกป้องโดย android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK และต้องเริ่มกิจกรรมของ Intent ที่แยกวิเคราะห์จาก Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้โทรออกได้ ผู้ใช้จะ

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

  • [8.1/H-0-1] เวลาในการตอบสนองของเฟรมที่สอดคล้องกัน เวลาในการตอบสนองของเฟรมที่ไม่สอดคล้องกันหรือการเลื่อนเวลาแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมใน 1 วินาที และควรน้อยกว่า 1 เฟรมใน 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/s
  • [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 และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้

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

  • [8.5/H-0-1] ต้องให้ผู้ใช้ดูแอปทั้งหมดที่มีบริการที่ทำงานอยู่เบื้องหน้าหรืองานที่ผู้ใช้เริ่ม รวมทั้งระยะเวลาของบริการแต่ละรายการเหล่านี้นับตั้งแต่เริ่มต้นตามที่อธิบายไว้ในเอกสาร SDK

  • [8.5/H-0-2]ต้องให้ผู้ใช้สามารถหยุดแอปที่ใช้บริการที่ทำงานอยู่เบื้องหน้าหรืองานที่ผู้ใช้เริ่ม

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

การติดตั้งใช้งานอุปกรณ์ต้องประกาศการรองรับ android.software.credentials และ

  • [9/H-0-2] MUST honor the android.settings.CREDENTIAL_PROVIDER intent to allow selection of a preferred provider for the Credential Manager. ระบบจะเปิดใช้ผู้ให้บริการนี้สำหรับการป้อนข้อความอัตโนมัติ และจะเป็นตำแหน่งเริ่มต้นในการบันทึกข้อมูลเข้าสู่ระบบใหม่ซึ่งป้อนผ่านเครื่องมือจัดการข้อมูลเข้าสู่ระบบด้วย

  • [9/H-0-3] ต้องรองรับผู้ให้บริการข้อมูลเข้าสู่ระบบพร้อมกันอย่างน้อย 2 ราย และแสดงตัวเลือกให้ผู้ใช้ในแอปการตั้งค่าเพื่อเปิดหรือปิดใช้ผู้ให้บริการ

สิ้นสุดข้อกำหนดใหม่

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

  • [9.5/H-1-1] ต้องไม่ตั้งค่า UserManager.isHeadlessSystemUserMode ให้เท่ากับ true

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [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 เป็นไปตามข้อกำหนดสำหรับโหมดล็อกขณะคุมสอบ

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

  • [9.11.1/H-1-1] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์ด้วยวิธีใดวิธีหนึ่งต่อไปนี้ซึ่งเป็นวิธีตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) บ่อยกว่า 1 ครั้งทุก 72 ชั่วโมง

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์พกพาตั้งค่า UserManager.isHeadlessSystemUserMode เป็น true

  • [9.5/H-4-1] ต้องไม่รองรับ eUICC หรือ eSIM ที่มีความสามารถในการโทร
  • [9.5/H-4-2] ต้องไม่ประกาศรองรับ android.hardware.telephony

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

การตั้งค่าที่จํากัด

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

  • ติดตั้งหลังจากดาวน์โหลดผ่านแอปพลิเคชัน (เช่น แอปรับส่งข้อความหรือเบราว์เซอร์) อื่นที่ไม่ใช่แอปพลิเคชัน "App Store" ที่ PackageManager ระบุว่าเป็น PACKAGE_DOWNLOADED_FILE
  • ติดตั้งจากไฟล์ในเครื่อง (เช่น แอปพลิเคชันได้รับการโหลดจากแหล่งที่ไม่รู้จัก) PackageManager ระบุแอปพลิเคชันเป็น PACKAGE_SOURCE_LOCAL_FILE

สําหรับสิทธิ์ที่บังคับใช้และตัวระบุที่เกี่ยวข้องซึ่งระบุไว้ใน [9.8/H-0-5] ด้านล่าง

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

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

  • [9.8/H-0-1] ต้องใช้การตั้งค่าที่จํากัดตามที่ระบุไว้ข้างต้นสําหรับรายการต่อไปนี้

    • สิทธิ์พิเศษ
      • ความสามารถในการเข้าถึง (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • บริการฟังการแจ้งเตือน (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • แอปผู้ดูแลระบบอุปกรณ์ (Manifest.permission.BIND_DEVICE_ADMIN)
      • แสดงทับแอปอื่นๆ (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • สิทธิ์เข้าถึงการใช้งาน (AppOpsManager.OPSTR_GET_USAGE_STATS)
    • บทบาท (แอปเริ่มต้น)
      • Dialer (RoleManager.ROLE_DIALER)
      • SMS (RoleManager.ROLE_SMS)
    • สิทธิ์รันไทม์
      • รันไทม์ SMS (Manifest.permission_group.SMS)

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

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

  • [9.8/H-0-4] ต้องอนุญาตให้ผู้ใช้ยืนยันเท่านั้นเพื่อเปิดใช้การตั้งค่าที่จํากัดจากหน้า AppInfo ของแอปพลิเคชันที่ครอบคลุมโดยใช้ EnhancedConfirmationManager API

  • [9.8/H-0-5] ขอแนะนำอย่างยิ่งให้ผสานรวมและเรียกใช้ EnhancedConfirmationManager สำหรับสิทธิ์พิเศษทั้งหมด เพื่อพิจารณาแบบไดนามิกว่าสิทธิ์เหล่านั้นเป็นการตั้งค่าที่จํากัดหรือไม่

    • การปลุกและการช่วยเตือน: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • การเข้าถึงไฟล์ทั้งหมด: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • แสดงทับแอปอื่นๆ: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • ติดตั้งแอปที่ไม่รู้จัก: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • จัดการสื่อ: AppOpsManager.OPSTR_MANAGE_MEDIA
    • แก้ไขการตั้งค่าระบบ: AppOpsManager.OPSTR_WRITE_SETTINGS
    • การแสดงภาพซ้อนภาพ: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • เปิดหน้าจอ: AppOpsManager.OPSTR_TURN_SCREEN_ON
    • การแจ้งเตือนแบบเต็มหน้าจอ: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • การควบคุม Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • การช่วยเหลือพิเศษ: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • บริการฟังการแจ้งเตือน: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • สิทธิ์เข้าถึงการใช้งาน: AppOpsManager.OPSTR_GET_USAGE_STATS
    • ผู้ดูแลระบบอุปกรณ์: Manifest.permission.BIND_DEVICE_ADMIN
    • ห้ามรบกวน: Manifest.permission.MANAGE_NOTIFICATIONS

สิ้นสุดข้อกำหนดใหม่

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

  • [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคําสั่งให้ดำเนินการสามารถส่งข้อมูลไปยังระบบ, ContentCaptureService หรือบริการจดจําคําพูดในอุปกรณ์ที่สร้างขึ้นโดย SpeechRecognizer#createOnDeviceSpeechRecognizer() เท่านั้น
  • [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคําสั่งให้ดำเนินการสามารถส่งข้อมูลเสียงจากไมโครโฟนหรือข้อมูลที่มาจากไมโครโฟนไปยังเซิร์ฟเวอร์ระบบผ่าน HotwordDetectionService API หรือไปยัง ContentCaptureService ผ่าน ContentCaptureManager API เท่านั้น
  • [9.8/H-1-3] ต้องไม่ส่งเสียงจากไมโครโฟนที่มีความยาวเกิน 30 วินาทีสำหรับคำขอที่เรียกให้บริการตรวจจับคีย์เวิร์ดแต่ละรายการจากฮาร์ดแวร์
  • [9.8/H-1-4] ต้องไม่ส่งเสียงจากไมโครโฟนที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับคำขอแต่ละรายการไปยังบริการตรวจจับคําพูดคํานิยม
  • [9.8/H-1-5] ต้องไม่ส่งเสียงจากไมโครโฟนที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีไปยังบริการโต้ตอบด้วยเสียงหรือนิติบุคคลที่คล้ายกัน
  • [9.8/H-1-6] ต้องไม่อนุญาตให้ส่งข้อมูลมากกว่า 100 ไบต์ (ไม่รวมสตรีมเสียง) ออกจากบริการตรวจจับคําสั่งให้ดำเนินการในแต่ละผลลัพธ์คําสั่งให้ดำเนินการที่สำเร็จ
  • [9.8/H-1-7] ต้องไม่อนุญาตให้ส่งข้อมูลมากกว่า 5 บิตจากบริการตรวจจับคําพูดที่กระตุ้นให้ดำเนินการ (Hotword) ไปยังผลลัพธ์ของคําพูดที่กระตุ้นให้ดำเนินการ (Hotword) เชิงลบแต่ละรายการ
  • [9.8/H-1-8] ต้องอนุญาตให้ส่งข้อมูลจากบริการตรวจจับคําสั่งให้ดำเนินการเฉพาะในคำขอตรวจสอบคําสั่งให้ดำเนินการจากเซิร์ฟเวอร์ระบบ
  • [9.8/H-1-9] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจหาคําสั่งให้ดำเนินการ
  • [9.8/H-1-10] ต้องไม่แสดงข้อมูลเชิงปริมาณเกี่ยวกับการใช้ไมโครโฟนโดยบริการตรวจจับคําสั่งให้ดำเนินการใน UI
  • [9.8/H-1-11] ต้องบันทึกจำนวนไบต์ที่รวมอยู่ในการส่งทุกครั้งจากบริการตรวจจับคําพูดให้ตรวจสอบได้สําหรับนักวิจัยด้านความปลอดภัย
  • [9.8/H-1-12] ต้องรองรับโหมดแก้ไขข้อบกพร่องที่บันทึกเนื้อหาดิบของการส่งทุกรายการจากบริการตรวจจับคําสั่งให้ดำเนินการเพื่อให้นักวิจัยด้านความปลอดภัยตรวจสอบได้

  • [9.8/H-1-14] ต้องแสดงตัวบ่งชี้ไมโครโฟนตามที่อธิบายไว้ในส่วนที่ 9.8.2 เมื่อส่งผลการค้นหาคีย์เวิร์ดสำเร็จไปยังบริการโต้ตอบด้วยเสียงหรือนิติบุคคลที่คล้ายกัน

  • [9.8/H-1-15] ต้องตรวจสอบว่าสตรีมเสียงที่ระบุในผลการค้นหาคำที่พบสำเร็จได้รับการส่งแบบทางเดียวจากบริการตรวจจับคำที่พบไปยังบริการโต้ตอบด้วยเสียง

  • [9.8/H-SR-1] ขอแนะนำอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบก่อนตั้งค่าแอปพลิเคชันเป็นผู้ให้บริการของบริการตรวจจับคําสั่งให้ดำเนินการ

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

  • [9.8/H-SR-3] ขอแนะนำอย่างยิ่งให้รีสตาร์ทกระบวนการโฮสต์บริการตรวจจับคําสั่งให้ดำเนินการอย่างน้อย 1 ครั้งทุกชั่วโมง หรือทุก 30 เหตุการณ์ที่ทริกเกอร์ฮาร์ดแวร์ แล้วแต่ว่าเหตุการณ์ใดจะเกิดขึ้นก่อน

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

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

หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับ System API VisualQueryDetectionService หรือกลไกอื่นในการตรวจหาคําค้นหา โดยไม่มีเครื่องหมายการเข้าถึงไมโครโฟนและ/หรือกล้อง อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [9.8/H-3-1] ต้องตรวจสอบว่าบริการตรวจจับข้อความค้นหาสามารถส่งข้อมูลไปยังระบบหรือ ContentCaptureService หรือบริการจดจำคำพูดในอุปกรณ์ (สร้างโดย SpeechRecognizer#createOnDeviceSpeechRecognizer()) เท่านั้น
  • [9.8/H-3-2] ต้องไม่อนุญาตให้มีการส่งข้อมูลเสียงหรือวิดีโอออกจาก VisualQueryDetectionService ยกเว้นการส่งไปยัง ContentCaptureService หรือบริการจดจำคำพูดในอุปกรณ์
  • [9.8/H-3-3] ต้องแสดงการแจ้งเตือนผู้ใช้ใน UI ของระบบเมื่ออุปกรณ์ตรวจพบความตั้งใจของผู้ใช้ที่จะโต้ตอบกับแอปพลิเคชันผู้ช่วยดิจิทัล (เช่น โดยการตรวจหาผู้ใช้ผ่านกล้อง)
  • [9.8/H-3-4] ต้องแสดงตัวบ่งชี้ไมโครโฟนและแสดงคำค้นหาที่ตรวจพบของผู้ใช้ใน UI ทันทีที่ตรวจพบคำค้นหาของผู้ใช้
  • [9.8/H-3-5] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจหาข้อความค้นหาด้วยภาพ

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

  • [9.8.2/H-4-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อมีเพียง HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService หรือแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 ที่มีตัวระบุ CDD [C-4-X] เท่านั้นที่เข้าถึงไมโครโฟน
  • [9.8.2/H-4-2] ต้องแสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ไมโครโฟนตามที่ได้จาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น
  • [9.8.2/H-4-3] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
  • [9.8.2/H-4-4] ต้องแสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ไมโครโฟนตามที่แสดงผลจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น

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

  • [9.8.2/H-5-1] ต้องแสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 ที่มีตัวระบุ CDD [C-4-X] เท่านั้นที่เข้าถึงกล้อง
  • [9.8.2/H-5-2] ต้องแสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้กล้องตามที่แสดงผลจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น
  • [9.8.2/H-5-3] ต้องไม่ซ่อนไฟสัญญาณกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [9.10/H-1-1] ต้องยืนยันพาร์ติชันที่อ่านอย่างเดียวทั้งหมดที่ใส่ข้อมูลไว้ในระหว่างลำดับการบูตของ Android และข้อมูลสรุป VBMeta ต้องรวมพาร์ติชันที่ยืนยันแล้วทั้งหมดเหล่านี้ไว้ในการคำนวณ

สิ้นสุดข้อกำหนดใหม่

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • Perfetto
    • [6.1/H-0-2]* ต้องแสดง/system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto
    • [6.1/H-0-3]* ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf ที่เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/H-0-4]* ไบนารีของ Perfetto จะต้องเขียนเป็นเอาต์พุตการติดตาม protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/H-0-5]* ต้องระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
    • [6.1/H-0-6]* ต้องเปิดใช้โปรแกรมเดรัมที่ใช้ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

สิ้นสุดข้อกำหนดใหม่

2.2.7. คลาสประสิทธิภาพสื่อในอุปกรณ์เคลื่อนที่

ดูคำจำกัดความของคลาสประสิทธิภาพสื่อได้ที่ส่วนที่ 7.11

2.2.7.1. สื่อ

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.U สําหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์มีลักษณะดังนี้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์สูงสุดที่สามารถทำงานพร้อมกันในชุดค่าผสมโค้ดใดก็ได้ผ่านวิธีการ CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-2] ต้องรองรับเซสชันโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 รายการ (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันกับเซสชัน 3 รายการที่ความละเอียด 1080p@30 fps และเซสชัน 3 รายการที่ความละเอียด 4K@30 fps สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที ตัวแปลงรหัส AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังคงต้องรองรับอินสแตนซ์ 6 รายการที่ 1080p30fps

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์ที่สามารถทำงานพร้อมกันในชุดค่าผสมของโค้ดใดก็ได้ผ่านวิธีการ CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเข้ารหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 รายการ (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมโค้ดใดก็ได้ที่ทำงานพร้อมกันกับเซสชัน 4 รายการที่ความละเอียด 1080p@30 fps และเซสชัน 2 รายการที่ความละเอียด 4K@30 fps สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที ตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังคงต้องรองรับอินสแตนซ์ 6 รายการที่ 1080p30fps

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเข้ารหัสและโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ที่ทำงานพร้อมกันได้ในการผสมผสานโค้ดใดก็ได้ผ่านวิธีการ CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-6] ต้องรองรับอินสแตนซ์ของโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 รายการ และเซสชันโปรแกรมเข้ารหัสวิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมโค้ดใดก็ได้ที่ทำงานพร้อมกันกับเซสชัน 3 รายการที่ความละเอียด 4K@30fps โดยที่เซสชันที่เข้ารหัสได้สูงสุด 2 รายการ และเซสชันที่ความละเอียด 1080p 3 รายการ สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที ตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังคงต้องรองรับอินสแตนซ์ 6 รายการที่ 1080p30fps

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-19] ต้องรองรับอินสแตนซ์ตัวถอดรหัสวิดีโอแบบฮาร์ดแวร์ 10 บิต (HDR) 3 รายการ และเซสชันโปรแกรมเข้ารหัสวิดีโอแบบฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมโค้ดใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 4K@30fps โดยที่เซสชันโปรแกรมเข้ารหัสไม่เกิน 1 รายการ ซึ่งสามารถกำหนดค่าในรูปแบบอินพุต RGBA_1010102 ผ่านพื้นผิว GL สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที ไม่จำเป็นต้องสร้างข้อมูลเมตา HDR โดยโปรแกรมเปลี่ยนไฟล์หากเข้ารหัสจากพื้นผิว GL เซสชันตัวแปลงรหัส AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้จะกำหนดให้รองรับ 4K ก็ตาม

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-7] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอ 1080p หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์ทั้งหมดเมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโอ 1080p เป็น 720p เฉพาะวิดีโอพร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ควบคู่ไปกับการเปิดใช้งานการบันทึกเสียงและวิดีโอ 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองในการเริ่มต้นของโปรแกรมแปลงรหัสต้องไม่เกิน 50 มิลลิวินาที
  • [5.1/H-1-8] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสเสียงอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโอ 1080p เป็น 720p เฉพาะวิดีโอพร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ควบคู่ไปกับการเปิดใช้งานการบันทึกเสียงและวิดีโอ 1080p

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-9] ต้องรองรับเซสชันโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 2 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 1080p@30 fps สำหรับเนื้อหาทั้ง 8 บิต (SDR) และ 10 บิต HDR สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-10] ต้องรองรับเซสชันโปรแกรมถอดรหัสวิดีโอแบบฮาร์ดแวร์ที่ไม่ปลอดภัย 3 อินสแตนซ์ควบคู่ไปกับเซสชันโปรแกรมถอดรหัสวิดีโอแบบฮาร์ดแวร์ที่ปลอดภัย 1 อินสแตนซ์ (รวมเป็น 4 อินสแตนซ์) (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ ที่ทำงานพร้อมกันกับเซสชัน 3 รายการที่ความละเอียด 4K@30fps ซึ่งรวมถึงเซสชันโปรแกรมถอดรหัสที่ปลอดภัย 1 รายการและเซสชันที่ไม่ปลอดภัย 1 รายการที่ความละเอียด 1080p@30fps โดยเซสชันที่รองรับ HDR 10 บิตได้สูงสุด 2 รายการ สำหรับเซสชันทั้งหมด จะต้องไม่มีการทิ้งเฟรมเกิน 1 เฟรมต่อวินาที เซสชันตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้จะกำหนดให้ใช้ 4K ก็ตาม

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-11] ต้องรองรับโปรแกรมถอดรหัสที่ปลอดภัยสำหรับโปรแกรมถอดรหัส AVC, HEVC, VP9 หรือ AV1 ของฮาร์ดแวร์ทุกตัวในอุปกรณ์
  • [5.1/H-1-12] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการถอดรหัสวิดีโอความละเอียด 1080p หรือต่ำกว่าสำหรับโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ทั้งหมดเมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงวิดีโอ 1080p เป็น 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการเล่นเสียงและวิดีโอ 1080p สำหรับตัวแปลงรหัส Dolby Vision เวลาในการตอบสนองในการเริ่มต้นของโปรแกรมแปลงรหัสต้องไม่เกิน 50 มิลลิวินาที
  • [5.1/H-1-13] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดไม่เกิน 30 มิลลิวินาทีสำหรับเซสชันการถอดรหัสเสียงอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับโปรแกรมถอดรหัสเสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโอ 1080p เป็น 720p เฉพาะวิดีโอพร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ควบคู่ไปกับอินทิอลไลเซชันการเล่นเสียงและวิดีโอ 1080p

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-14] ต้องรองรับโปรแกรมถอดรหัสฮาร์ดแวร์ AV1 Main 10, ระดับ 4.1 และเม็ดเกรนของฟิล์ม พร้อมเอฟเฟกต์เม็ดเกรนของฟิล์มในการคอมโพสิชัน GPU

สิ้นสุดข้อกำหนดใหม่

  • [5.1/H-1-15] ต้องมีโปรแกรมถอดรหัสวิดีโอแบบฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
  • [5.1/H-1-16] ต้องมีโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-21] ต้องรองรับ FEATURE_DynamicColorAspect สำหรับโปรแกรมถอดรหัสวิดีโอแบบฮาร์ดแวร์ทั้งหมด (AVC, HEVC, VP9, AV1 หรือเวอร์ชันที่ใหม่กว่า) หมายเหตุ: ซึ่งหมายความว่าแอปพลิเคชันจะอัปเดตแง่มุมสีของเนื้อหาวิดีโอในระหว่างเซสชันการถอดรหัสได้ ตัวถอดรหัสที่รองรับเนื้อหา 10 บิตและ 8 บิตต้องรองรับการสลับระหว่างเนื้อหา 8 บิตและ 10 บิตในโหมด Surface แบบไดนามิก ตัวถอดรหัสที่รองรับฟังก์ชันการโอน HDR จะต้องรองรับการสลับระหว่างเนื้อหา SDR และ HDR แบบไดนามิก

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-22] ต้องรองรับการเข้ารหัส การถอดรหัส การแก้ไขด้วย GPU และการแสดงเนื้อหาวิดีโอในอัตราส่วนภาพแนวตั้ง โดยไม่คำนึงถึงข้อมูลเมตาการหมุนสำหรับความละเอียดสูงสุดที่กล้องรองรับหรือ 4K แล้วแต่ว่าความละเอียดใดจะต่ำกว่า หมายเหตุ: ข้อมูลนี้รวมโปรไฟล์ HDR ด้วยหากตัวแปลงรหัสรองรับ HDR โปรแกรมเปลี่ยนไฟล์ AV1 จะต้องรองรับความละเอียด 1080p เท่านั้น ข้อกำหนดนี้ใช้กับโค้ดรูปแบบฮาร์ดแวร์, GPU และ DPU เท่านั้น

สิ้นสุดข้อกำหนดใหม่

  • [5.3/H-1-1] ต้องไม่มีการหยุดทำงานของเฟรมเกิน 1 เฟรมใน 10 วินาที (นั่นคือน้อยกว่า 0.167 เปอร์เซ็นต์ของการหยุดทำงานของเฟรม) สำหรับเซสชันวิดีโอ 4K 60 fps ภายใต้ภาระงาน
  • [5.3/H-1-2] ต้องไม่เฟรมตกเกิน 1 เฟรมใน 10 วินาทีระหว่างการเปลี่ยนแปลงความละเอียดของวิดีโอในเซสชันวิดีโอ 60 FPS ภายใต้ภาระงานสำหรับเซสชัน 4K
  • [5.6/H-1-1] ต้องมีเวลาในการตอบสนองของฟีเจอร์แตะเพื่อฟังเสียงไม่เกิน 80 มิลลิวินาทีโดยใช้การทดสอบฟีเจอร์แตะเพื่อฟังเสียงของ CTS Verifier
  • [5.6/H-1-2] ต้องมีเวลาในการตอบสนองของเสียงแบบไปกลับไม่เกิน 80 มิลลิวินาทีในเส้นทางข้อมูลที่รองรับอย่างน้อย 1 เส้นทาง
  • [5.6/H-1-3] ต้องรองรับเสียง 24 บิตขึ้นไปสำหรับเอาต์พุตสเตอริโอผ่านแจ็คเสียง 3.5 มม. (หากมี) และผ่านเสียง USB (หากรองรับ) ตลอดเส้นทางข้อมูลสำหรับการกำหนดค่าสตรีมมิงและเวลาในการตอบสนองต่ำ สําหรับการกําหนดค่าเวลาในการตอบสนองต่ำ แอปควรใช้ AAudio ในโหมดการเรียกกลับแบบเวลาในการตอบสนองต่ำ สําหรับการกําหนดค่าสตรีมมิง แอปควรใช้ Java AudioTrack ทั้งในการกำหนดค่าเวลาในการตอบสนองต่ำและการสตรีม ตัวรับสัญญาณเอาต์พุต HAL ควรยอมรับ AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT หรือ AUDIO_FORMAT_PCM_FLOAT สำหรับรูปแบบเอาต์พุตเป้าหมาย

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.6/H-1-4] ต้องรองรับอุปกรณ์เสียง USB อย่างน้อย 4 แชนแนล (ดีเจคอนโทรลเลอร์ใช้รูปแบบนี้เพื่อฟังตัวอย่างเพลง)

สิ้นสุดข้อกำหนดใหม่

  • [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่เป็นไปตามข้อกำหนดของคลาสและประกาศ Flag ฟีเจอร์ MIDI
  • [5.6/H-1-9] ต้องรองรับการมิกซ์เสียงอย่างน้อย 12 แชนแนล ซึ่งหมายความว่าสามารถเปิด AudioTrack ที่มีมาสก์ช่อง 7.1.4 และจัดวางเสียงหรือดาวน์มิกซ์ช่องทั้งหมดให้เป็นสเตอริโออย่างเหมาะสม
  • [5.6/H-SR] ขอแนะนำอย่างยิ่งให้รองรับการผสม 24 แชนแนลโดยรองรับมาสก์แชแนล 9.1.6 และ 22.2 เป็นอย่างน้อย
  • [5.7/H-1-2] ต้องรองรับ MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL ที่มีความสามารถในการถอดรหัสเนื้อหาต่อไปนี้
ขนาดตัวอย่างขั้นต่ำ 4 MiB
จำนวนตัวอย่างย่อยขั้นต่ำ - H264 หรือ HEVC 32
จำนวนตัวอย่างย่อยขั้นต่ำ - VP9 9
จำนวนตัวอย่างย่อยขั้นต่ำ - AV1 288
ขนาดบัฟเฟอร์การสุ่มตัวอย่างย่อยขั้นต่ำ 1 MiB
ขนาดบัฟเฟอร์การเข้ารหัสทั่วไปขั้นต่ำ 500 KiB
จํานวนเซสชันที่ใช้พร้อมกันขั้นต่ำ 30
จำนวนคีย์ขั้นต่ำต่อเซสชัน 20
จํานวนคีย์ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 80
จํานวนคีย์ DRM ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 6
ขนาดข้อความ 16 KiB
เฟรมต่อวินาทีที่ถอดรหัสแล้ว 60 FPS
  • [5.1/H-1-17] ต้องมีโปรแกรมถอดรหัสรูปภาพแบบฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับโปรไฟล์ Baseline ของ AVIF
  • [5.1/H-1-18] ต้องรองรับโปรแกรมเปลี่ยนไฟล์ AV1 ซึ่งสามารถเปลี่ยนไฟล์เป็นความละเอียดสูงสุด 480p ที่ 30 fps และ 1 Mbps

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [5.1/H-1-20] ต้องรองรับฟีเจอร์ Feature_HdrEditing สำหรับโปรแกรมเข้ารหัส AV1 และ HEVC ทั้งหมดที่เป็นฮาร์ดแวร์ในอุปกรณ์ที่ความละเอียด 4K หรือความละเอียดสูงสุดที่กล้องรองรับ แล้วแต่ว่าค่าใดจะต่ำกว่า

สิ้นสุดข้อกำหนดใหม่

  • [5.12/H-SR] ขอแนะนำอย่างยิ่งให้รองรับฟีเจอร์ Feature_HdrEditing ของโปรแกรมเปลี่ยนไฟล์ AV1 และ HEVC บนฮาร์ดแวร์ทั้งหมดที่มีอยู่ในอุปกรณ์
  • [5.12/H-1-2] ต้องรองรับรูปแบบสี RGBA_1010102 สำหรับโปรแกรมเปลี่ยนไฟล์ AV1 และ HEVC บนฮาร์ดแวร์ทั้งหมดที่มีอยู่ในอุปกรณ์
  • [5.12/H-1-3] ต้องโฆษณาการรองรับส่วนขยาย EXT_YUV_target เพื่อสุ่มตัวอย่างจากพื้นผิว YUV ทั้งแบบ 8 และ 10 บิต
  • [7.1.4/H-1-1] ต้องมีการวางซ้อนฮาร์ดแวร์อย่างน้อย 6 รายการในหน่วยประมวลผลการแสดงผล (DPU) โดยอย่างน้อย 2 รายการต้องแสดงเนื้อหาวิดีโอ 10 บิตได้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS และรองรับโปรแกรมเปลี่ยนไฟล์ AVC หรือ HEVC แบบฮาร์ดแวร์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

2.2.7.2. กล้อง

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.U สําหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์มีลักษณะดังนี้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [7.5/H-1-1] ต้องมีกล้องหลังหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล ซึ่งรองรับการจับภาพวิดีโอที่ 4K@30fps, 1080p@60fps และ 720p@60fps กล้องหลังหลักคือกล้องหลังที่มีรหัสกล้องต่ำที่สุด

สิ้นสุดข้อกำหนดใหม่

  • [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 6 ล้านพิกเซลและรองรับการบันทึกวิดีโอที่ 1080p@30fps กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำที่สุด
  • [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้ android.info.supportedHardwareLevel เป็น FULL ขึ้นไปสำหรับกล้องหลังหลักและ LIMITED ขึ้นไปสำหรับกล้องหน้าหลัก
  • [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-5] ต้องมีเวลาในการตอบสนองในการจับภาพ JPEG ของ camera2 น้อยกว่า 1,000 ม.ส. สำหรับความละเอียด 1080p ตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสงของ ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-6] ต้องมีเวลาในการตอบสนองในการเริ่มต้นของ camera2 (เปิดกล้องเพื่อแสดงตัวอย่างเฟรมแรก) < 500 ms โดยวัดจาก PerformanceTest ของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-8] ต้องรองรับ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW และ android.graphics.ImageFormat.RAW_SENSOR สำหรับกล้องหลังหลัก
  • [7.5/H-1-9] ต้องมีกล้องหลักที่หันหลังซึ่งรองรับ 720p หรือ 1080p @ 240fps
  • [7.5/H-1-10] กล้องหลักต้องมี ZOOM_RATIO ขั้นต่ำ < 1.0 หากมีกล้อง RGB แบบ Ultrawide ที่หันไปในทิศทางเดียวกัน
  • [7.5/H-1-11] ต้องใช้การสตรีมทั้งด้านหน้าและด้านหลังพร้อมกันในกล้องหลัก
  • [7.5/H-1-12] ต้องรองรับ CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION ทั้งสำหรับกล้องหน้าและกล้องหลังหลัก
  • [7.5/H-1-13] ต้องรองรับความสามารถ LOGICAL_MULTI_CAMERA สำหรับกล้องหลังหลักหากมีกล้องหลัง RGB มากกว่า 1 ตัว
  • [7.5/H-1-14] ต้องรองรับความสามารถ STREAM_USE_CASE สำหรับทั้งกล้องหน้าและกล้องหลังหลัก
  • [7.5/H-1-15] ต้องรองรับส่วนขยายโหมดกลางคืนผ่านทั้งส่วนขยาย CameraX และ Camera2 สำหรับกล้องหลัก
  • [7.5/H-1-16] ต้องรองรับความสามารถ DYNAMIC_RANGE_TEN_BIT สำหรับกล้องหลัก
  • [7.5/H-1-17] ต้องรองรับ CONTROL_SCENE_MODE_FACE_PRIORITY และการตรวจจับใบหน้า (STATISTICS_FACE_DETECT_MODE_SIMPLE หรือ STATISTICS_FACE_DETECT_MODE_FULL) สำหรับกล้องหลัก

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [7.5/H-1-18] ต้องรองรับ JPEG_R สำหรับกล้องหลังหลักและกล้องหน้าหลัก
  • [7.5/H-1-19] ต้องรองรับCONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONสําหรับตัวอย่างภาพ HLG10 1080p ที่มี JPEG สัดส่วนภาพ 16:9 ขนาดสูงสุด และสำหรับตัวอย่างภาพ HLG10 720p ที่มีสตรีม JPEG สัดส่วนภาพ 16:9 ขนาดสูงสุดสําหรับกล้องหลังหลัก
  • [7.5/H-1-20] ต้องเป็นค่าเริ่มต้นที่เอาต์พุต JPEG_R สำหรับกล้องหลังหลักและกล้องหน้าหลักในแอปกล้องหลัก

สิ้นสุดข้อกำหนดใหม่

2.2.7.3. ฮาร์ดแวร์

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์มีลักษณะดังนี้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

  • [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [7.1.1.3/H-2-1] ต้องมีความละเอียดของหน้าจออย่างน้อย 400 dpiหากความกว้างของหน้าจออุปกรณ์นั้น< 600 dp

สิ้นสุดข้อกำหนดใหม่

  • [7.1.1.3/H-3-1] ต้องมีจอแสดงผล HDR ที่รองรับค่าเฉลี่ยอย่างน้อย 1,000 นิต

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [7.6.1/H-2-1] ต้องมีหน่วยความจําจริงอย่างน้อย 8 GBโดยมีอย่างน้อย 6.64 GB ที่ใช้ได้กับเคอร์เนลตามที่ android.app.ActivityManager.MemoryInfo.totalMem รายงาน

สิ้นสุดข้อกำหนดใหม่

2.2.7.4. ประสิทธิภาพ

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์มีลักษณะดังนี้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

2.2.7.5. กราฟิก

หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.V สําหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์มีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

    • 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
    • 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/T-0-3] AV1

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

  • [5.2.2/T-SR-1] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส 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 เฟรมต่อวินาที ด้วยระดับ High ของโปรไฟล์หลัก และต้องแยกเส้นวิดีโอ MPEG-2 แบบอินเตอร์เลซออกเพื่อให้แอปพลิเคชันของบุคคลที่สามใช้งานได้

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

  • [5.3.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile พื้นฐาน
  • [5.3.4/T-1-2] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile หลัก
  • [5.3.4/T-1-3] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile ระดับสูง 4.2

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

  • [5.3.5/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile หลักระดับ 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-SR1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)

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

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

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

  • [5.8/T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI เป็นความละเอียดสูงสุดสำหรับรูปแบบพิกเซลที่เลือกซึ่งทำงานร่วมกับอัตราการรีเฟรช 50 Hz หรือ 60 Hz สำหรับจอแสดงผลภายนอก ทั้งนี้ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอของภูมิภาคที่จำหน่ายอุปกรณ์
  • [5.8/T-SR-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกอัตราการรีเฟรช 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.2.3.1/T-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่ระบุไว้ที่นี่
  • [3.4.1/T-0-1] ต้องติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

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

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

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

Android Television Tuner Framework (TF) รวมการจัดการเนื้อหาสดจาก Tuner เข้ากับเนื้อหาสตรีมมิงจาก IP ในอุปกรณ์ Android Television เฟรมเวิร์กตัวแปลงสัญญาณมี API มาตรฐานเพื่อสร้างบริการอินพุตที่ใช้ตัวแปลงสัญญาณทีวี Android

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

  • [3/T-1-1] ต้องรองรับ Tuner Framework API ทั้งหมดเพื่อให้ติดตั้งและใช้แอปพลิเคชันที่ใช้ API เหล่านี้ในอุปกรณ์ได้

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

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

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

  • [9.8.2/T-5-1] ต้องแสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 เข้าถึงกล้องเท่านั้น สิทธิ์ที่มีตัวระบุ CDD [C-3-X]
  • [9.8.2/T-5-2] ต้องไม่ซ่อนไฟสัญญาณกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • Perfetto
    • [6.1/T-0-1] ต้องแสดง/system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto
    • [6.1/T-0-2] ไฟล์ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/T-0-3] ไฟล์ไบนารีของ Perfetto ต้องเขียนร่องรอย protobuf เป็นเอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/T-0-4] ต้องมีแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
    • [6.1/T-0-5] ต้องมีการเปิดใช้ daemon ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

สิ้นสุดข้อกำหนดใหม่

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-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องวัดความเร่ง 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
  • [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงไว้ที่นี่

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [9/W-0-1] MUST declare the android.hardware.security.model.compatible feature.

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

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

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

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

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

  • [9.11.1/W-1-1] ต้องขอให้ผู้ใช้ดำเนินการตามวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมง

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

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

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

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

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

2.5.1. ฮาร์ดแวร์

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [7.1.1.1/A-1-1] ต้องมีหน้าจอแยกต่างหากที่มีขนาดเส้นทแยงมุมอย่างน้อย 6 นิ้วสำหรับโซนผู้นั่งแต่ละโซนสำหรับจอแสดงผลหลัก สิ่งนี้ควรติดแท็กเป็น CarOccupantZoneManager.DISPLAY_TYPE_MAIN สำหรับโซนผู้อยู่อาศัยแต่ละโซน
  • [7.1.1.1/A-1-2] ต้องมีเลย์เอาต์ขนาดหน้าจออย่างน้อย 750 dp x 480 dp สำหรับจอแสดงผลหลักแต่ละจอ

สิ้นสุดข้อกำหนดใหม่

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

  • [7.1.4.1/A-0-1] ต้องประกาศ OpenGL ES 3.1 ขึ้นไป
  • [7.1.4.1/A-0-2] ต้องรองรับ Vulkan 1.1
  • [7.1.4.1/A-0-3] ต้องมีโปรแกรมโหลด Vulkan และส่งออกสัญลักษณ์ทั้งหมด

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

สิ้นสุดข้อกำหนดใหม่

  • [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-SR1] อาจประมาณตำแหน่งโดยรวม GPS/GNSS เข้ากับเซ็นเซอร์เพิ่มเติม หากตำแหน่งเป็นการประมาณ เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงานประเภทเซ็นเซอร์และ/หรือรหัสพร็อพเพอร์ตี้ยานพาหนะที่เกี่ยวข้อง

  • [7.3/A-0-4] ตำแหน่งที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่จับคู่กับแผนที่

  • [7.3.1/A-0-4] ต้องเป็นไปตามระบบพิกัดของเซ็นเซอร์รถยนต์ Android

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

  • [7.3/A-SR-2] แนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_HEADING

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [7.3/A-1-1] ต้องตั้งค่าค่า Flag NIGHT_MODE ให้สอดคล้องกับโหมดกลางวัน/กลางคืนของหน้าแดชบอร์ดในจอแสดงผลทั้งหมด รวมถึงจอแสดงผลด้านหลัง

สิ้นสุดข้อกำหนดใหม่

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

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

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

  • [7.3.1/A-SR-1] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับตัวตรวจวัดความเร่งแบบแกนจำกัด

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

  • [7.3.1/A-1-3] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_LIMITED_AXES
  • [7.3.1/A-1-4] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED

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

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

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

  • [7.3.4/A-SR-2] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิตสำหรับไจโรสโคปแบบแกนจำกัด

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

  • [7.3.4/A-4-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_GYROSCOPE_LIMITED_AXES
  • [7.3.4/A-4-2] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเครื่องรับ GPS/GNSS แต่ไม่มีการเชื่อมต่อข้อมูลแบบเครือข่ายมือถือ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [7.3.3/A-3-1] ต้องระบุตำแหน่งในครั้งแรกที่เปิดเครื่องรับ GPS/GNSS หรือหลังจากผ่านไป 4 วันขึ้นไปภายใน 60 วินาที
  • [7.3.3/A-3-2] ต้องเป็นไปตามเกณฑ์เวลาในการแก้ไขครั้งแรกตามที่อธิบายไว้ใน 7.3.3/C-1-2 และ 7.3.3/C-1-6 สำหรับคำขอตำแหน่งอื่นๆ ทั้งหมด (นั่นคือคำขอที่ไม่ได้เกิดขึ้นเป็นครั้งแรกหรือหลังจากผ่านไป 4 วันขึ้นไป) ข้อกำหนด 7.3.3/C-1-2 มักจะเป็นไปตามข้อกำหนดในยานพาหนะที่ไม่มีการเชื่อมต่อข้อมูลผ่านเครือข่ายมือถือ โดยใช้การคาดการณ์วงโคจร GNSS ที่คำนวณในเครื่องรับ หรือใช้ตำแหน่งยานพาหนะที่ทราบล่าสุดพร้อมกับความสามารถในการหาตำแหน่งโดยประมาณเป็นเวลาอย่างน้อย 60 วินาทีโดยมีความแม่นยำของตำแหน่งที่เป็นไปตามข้อกำหนด 7.3.3/C-1-3 หรือใช้ทั้ง 2 อย่างร่วมกัน

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

  • [7.3.4/A-4-3] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 1 Hz
  • [7.3.4/A-SR-3] STRONGLY_RECOMMENDED to report events up to a frequency of at least 10 Hz.
  • ควรอ้างอิงตามทิศเหนือจริง
  • ควรพร้อมใช้งานแม้ว่ารถจะหยุดนิ่ง
  • ควรมีความละเอียดอย่างน้อย 1 องศา

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [7.4.3/A-1-1] ต้องเป็นแบบอิสระและจะไม่รบกวนประสบการณ์การใช้งาน BT ของผู้ใช้รายอื่น

สิ้นสุดข้อกำหนดใหม่

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

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

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

  • [7.4/A-1-1] ต้องประกาศรองรับ FEATURE_BROADCAST_RADIO

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

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

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

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

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

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

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

  • [7.5/A-2-1] กล้องหลักที่หันหน้าเข้าหาผู้ใช้ต้องเป็นกล้องที่หันหน้าเข้าหาผู้ใช้ซึ่งมีรหัสกล้องต่ำที่สุด
  • อาจปรับแนวเพื่อให้ขนาดยาวของกล้องสอดคล้องกับระนาบ X-Y ของแกนเซ็นเซอร์ยานยนต์ Android

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

  • [7.5/A-3-1] ต้องเป็นไปตามข้อกำหนดหลักของกล้องในส่วนที่ 7.5

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีกล้องที่เข้าถึงไม่ได้ผ่าน android.hardware.Camera หรือ android.hardware.camera2 API อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [7.5/A-4-1] ต้องเข้าถึงได้ผ่านบริการ Extended View System

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

  • [7.5/A-5-1] ต้องไม่หมุนหรือปรับภาพตัวอย่างของกล้องให้เหมือนภาพในกระจกในแนวนอน
  • [7.5/A-SR-4] ขอแนะนำอย่างยิ่งให้ใช้ความละเอียดอย่างน้อย 1.3 ล้านพิกเซล

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อย 1 ตัวที่เข้าถึงได้ผ่านทั้งบริการระบบมุมมองแบบขยายและ android.hardware.Camera หรือ android.hardware.Camera2 API กล้องดังกล่าวจะมีลักษณะดังนี้

  • [7.5/A-6-1] ต้องรายงานรหัสกล้องเดียวกัน

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

  • [7.5/A-7-1] ต้องใช้ Camera API ดังกล่าวโดยใช้ android.hardware.camera2 API หรือ Extended View System API

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [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ต่อจอแสดงผลหลักหากใช้ความหนาแน่นต่อไปนี้

    • 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
    • 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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

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-1] H.265 HEVC

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [5.5.3/A-1-1] ต้องกำหนดเส้นโค้งระดับเสียงที่เหมือนกันสำหรับสตรีมเอาต์พุตเสียงทั้งหมดที่แมปกับกลุ่มระดับเสียงเดียวกันตามที่ระบุไว้ในไฟล์การกำหนดค่าเสียงรถยนต์

สิ้นสุดข้อกำหนดใหม่

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.*

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มี API ที่เป็นกรรมสิทธิ์โดยใช้ android.car.CarPropertyManager กับ android.car.VehiclePropertyIds ระบบจะดำเนินการดังนี้

  • [3/A-1-1] ต้องไม่แนบสิทธิ์พิเศษไว้กับการใช้พร็อพเพอร์ตี้เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามใช้พร็อพเพอร์ตี้เหล่านี้
  • [3/A-1-2] ต้องไม่ทำซ้ำพร็อพเพอร์ตี้ยานพาหนะที่อยู่แล้วใน SDK

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

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

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

  • [3.4.1/A-0-1] ต้องระบุการใช้งาน android.webkit.Webview API ที่สมบูรณ์

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [3.8/A-0-1] ต้องไม่อนุญาตให้ผู้ใช้รองที่มีสิทธิ์แบบเต็มซึ่งไม่ได้เป็นผู้ใช้ที่ใช้งานอยู่ในปัจจุบันเปิดใช้งานกิจกรรมและเข้าถึง UI บนจอแสดงผลใดๆ

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

  • [3.8/A-1-1] ต้องใช้รายการ UserRestrictions ที่กําหนดไว้ล่วงหน้าต่อไปนี้สําหรับผู้ใช้รองแบบเต็มซึ่งไม่ใช่ผู้ใช้ที่ทำงานอยู่เบื้องหน้าในปัจจุบัน แต่มีสิทธิ์เข้าถึง UI ของจอแสดงผลที่กําหนดไว้ รายการ UserRestrictions ได้แก่ DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE และ DISALLOW_MICROPHONE_TOGGLE

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

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

  • [3.14/A-0-1] ต้องมีเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ Media API ตามที่อธิบายไว้ในส่วน3.14
  • [3.14/A-0-2] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับแอปพลิเคชันสื่อขณะขับรถได้อย่างปลอดภัย
  • [3.14/A-0-3] ต้องรองรับการดำเนินการ Intent ที่ไม่ชัดซึ่งใช้แอตทริบิวต์ CAR_EXTRA_MEDIA_PACKAGE เพิ่มเติมCAR_INTENT_ACTION_MEDIA_TEMPLATE
  • [3.14/A-0-4] ต้องมีความสามารถในการไปยังกิจกรรมการตั้งค่าของแอปพลิเคชันสื่อ แต่ต้องเปิดใช้เฉพาะเมื่อข้อจำกัด UX ของรถยนต์ไม่มีผล
  • [3.14/A-0-5] ต้องแสดงข้อความแสดงข้อผิดพลาดที่ตั้งค่าโดย Media Applications และต้องรองรับส่วนเสริมที่ไม่บังคับ 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

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

  • [3.14/A-1-1] ต้องมีบริการสื่อและเปิดบริการเหล่านั้นด้วย Intent CAR_INTENT_ACTION_MEDIA_TEMPLATE

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

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

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

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

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

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

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

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

  • [9.8.2/A-1-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อมีเพียง HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 ที่ใช้เข้าถึงไมโครโฟนโดยมีตัวระบุ CDD [C-4-X]
  • [9.8.2/A-1-2] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
  • [9.8.2/A-1-3] ต้องให้ผู้ใช้สามารถสลับไมโครโฟนในแอปการตั้งค่า

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [9.11/A-0-4] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงนามในการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คีย์การรับรองการรับรองต้อง แชร์ในอุปกรณ์จํานวนมากพอที่จะป้องกันไม่ให้มีการใช้คีย์ ป้องกันถาวรเป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่ช่วยให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์อื่นสำหรับ 100,000 หน่วยแต่ละหน่วย

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • Perfetto
    • [6.1/A-0-1] ต้องแสดง/system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto
    • [6.1/A-0-2] ไฟล์ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/A-0-3] ไฟล์ไบนารีของ Perfetto ต้องเขียนร่องรอย protobuf เป็นเอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [6.1/A-0-4] ต้องมีแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
    • [6.1/A-0-5] ต้องมีการเปิดใช้ daemon ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ persist.traced.enable)

สิ้นสุดข้อกำหนดใหม่

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

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

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

  • มีแหล่งจ่ายไฟที่ช่วยให้อุปกรณ์เคลื่อนที่ได้ เช่น แบตเตอรี่

  • มีขนาดหน้าจอที่แสดงผลมากกว่า 7 นิ้วแต่น้อยกว่า 18 นิ้ว โดยวัดจากเส้นทแยงมุม

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

2.6.1. ฮาร์ดแวร์

ไจโรสโคป

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

โหมดอุปกรณ์ต่อพ่วง 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

2.6.2. ซอฟต์แวร์

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

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 ชั่วคราวและ Denylist ในเส้นทาง prebuilts/runtime/appcompat/hiddenapi-flags.csv สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-0-8] ต้องไม่รองรับการติดตั้งแอปพลิเคชันที่กําหนดเป้าหมายเป็น API ระดับต่ำกว่า 23 24

สิ้นสุดข้อกำหนดใหม่

3.1.1. ส่วนขยาย Android

Android รองรับการขยายแพลตฟอร์ม API ที่มีการจัดการของ API ระดับหนึ่งๆ ด้วยการอัปเดตเวอร์ชันส่วนขยายสำหรับ API ระดับนั้น android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API จะแสดงเวอร์ชันส่วนขยายของ apiLevel ที่ระบุ หากมีส่วนขยายสําหรับระดับ API นั้น

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

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

  • [C-0-2] ต้องแสดงเฉพาะหมายเลขเวอร์ชันส่วนขยายที่ถูกต้องซึ่ง AOSP กำหนดไว้

  • [C-0-3] ต้องรองรับ API ทั้งหมดที่กําหนดโดยเวอร์ชันส่วนขยายที่ android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) แสดงผลในลักษณะเดียวกับที่รองรับ API ที่มีการจัดการอื่นๆ โดยเป็นไปตามข้อกําหนดในส่วนที่ 3.1

3.1.2. ไลบรารี Android

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

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

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

3.2 ความเข้ากันได้แบบ 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 ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงอย่างใดอย่างหนึ่งที่ระบุไว้ในสตริงเวอร์ชันที่อนุญาตสำหรับ Android 15
VERSION.SDK เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 15 ช่องนี้ต้องมีค่าจำนวนเต็ม 15_INT
VERSION.SDK&lowbar;INT เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 15 ช่องนี้ต้องมีค่าจำนวนเต็ม 15&lowbar;INT
VERSION.INCREMENTAL ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ห้ามนำค่านี้ไปใช้กับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตที่พิมพ์ได้และตรงกับนิพจน์ทั่วไป ^[^ :\/~]+$
กระดาน ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เฉพาะเจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือการระบุการแก้ไขที่เฉพาะเจาะจงของแผงวงจรที่จ่ายไฟให้กับอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$
แบรนด์ ค่าที่แสดงถึงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรแสดงถึงผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่จำหน่ายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$
ABI ที่รองรับ&lowbar; ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
ABI แบบ&lowbar;32&lowbar;บิตที่รองรับ ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
ABI ของ&lowbar;64&lowbar;บิตที่รองรับ ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ API เดิม
CPU&lowbar;ABI ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU&lowbar;ABI2 ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ API เดิม
อุปกรณ์ ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$ ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
FINGERPRINT สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้

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

เช่น

acme/myproduct/
    mydevice:15/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 หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC&lowbar;MANUFACTURER ชื่อทางการค้าของผู้ผลิตระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SoC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสได้ในรูปแบบ ASCII 7 บิต ต้องตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z ]+) ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC&lowbar;MODEL ชื่อรุ่นของระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีรุ่น SOC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z ._/+-]+)$ ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุของผลิตภัณฑ์
MODEL ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่ใช้ในการทําการตลาดและขายอุปกรณ์แก่ผู้ใช้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์ ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) และต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องอ่านออกได้ แต่ไม่จำเป็นต้องมีไว้ให้ผู้ใช้ปลายทางดู ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9_-]+$ ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ODM&lowbar;SKU ค่าที่ไม่บังคับซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือก โดยมี SKU (Stock Keeping Unit) ที่ใช้ติดตามการกำหนดค่าที่เฉพาะเจาะจงของอุปกรณ์ เช่น อุปกรณ์ต่อพ่วงที่รวมอยู่กับอุปกรณ์เมื่อขาย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z.,_-]+)$
ซีเรียล ต้องแสดงผลเป็น "UNKNOWN"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม แท็กต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป ^[a-zA-Z0-9._-]+ และต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys และ test-keys
เวลา ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น
ประเภท ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าอย่างใดอย่างหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รูปแบบ ได้แก่ user, userdebug หรือ eng
ผู้ใช้ ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")
SECURITY&lowbar;PATCH ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์ไม่มีช่องโหว่ใดๆ เกี่ยวกับปัญหาที่อธิบายไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สำหรับสาธารณะ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กําหนดไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สําหรับสาธารณะหรือใน คําแนะนําด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE&lowbar;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 อื่นๆ ได้ โปรเจ็กต์ Upstream ของ Android มีรายการแอปพลิเคชันที่ใช้รูปแบบ Intent หลายรูปแบบเพื่อดำเนินการทั่วไป

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

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

โปรดดูส่วนที่ 2 สำหรับ Intent ของแอปพลิเคชันที่จำเป็นสำหรับอุปกรณ์แต่ละประเภท

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

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

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

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

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

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

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

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

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

  • [C-2-3] ต้องปฏิบัติตามเจตนาของ 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

  • [C-2-6] ต้องปฏิบัติตาม Intent android.intent.action.SENDTO และ android.intent.action.VIEW รวมถึงระบุกิจกรรมเพื่อส่ง/แสดงข้อความ SMS

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL ด้วยแอปพลิเคชันโทรศัพท์ที่โหลดไว้ล่วงหน้าซึ่งจัดการ Intent เหล่านี้ได้ และให้บริการตามที่อธิบายไว้ใน SDK

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

  • [C-3-1] ต้องเป็นไปตามความตั้งใจของ android.settings.NFC_PAYMENT_SETTINGS ที่แสดงเมนูการตั้งค่าแอปเริ่มต้นสําหรับการชําระเงินแบบไม่ต้องสัมผัส
  • [C-3-2] ต้องปฏิบัติตาม Intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT เพื่อแสดงกิจกรรมที่เปิดกล่องโต้ตอบเพื่อขอให้ผู้ใช้เปลี่ยนบริการจำลองบัตรเริ่มต้นสำหรับบางหมวดหมู่ตามที่อธิบายไว้ใน SDK

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

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

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

  • [C-6-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อ Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS ซึ่งสําหรับการใช้งานที่มี UI_MODE_TYPE_NORMAL ต้องเป็นกิจกรรมที่ผู้ใช้สามารถให้สิทธิ์หรือปฏิเสธการเข้าถึงการกําหนดค่านโยบาย DND แก่แอปได้

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

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

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

  • [C-8-1] ต้องปฏิบัติตามความตั้งใจของ android.settings.ACCESSIBILITY_SETTINGS ที่จะมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดและปิดใช้บริการการช่วยเหลือพิเศษของบุคคลที่สามควบคู่ไปกับบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า

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

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

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

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

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

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

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

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

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

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อมอบหรือเพิกถอนสิทธิ์เข้าถึงสถิติการใช้งานตามIntent android.settings.ACTION_USAGE_ACCESS_SETTINGS สำหรับแอปที่ประกาศสิทธิ์ android.permission.PACKAGE_USAGE_STATS

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

  • [C-15-1] ต้องมีกิจกรรมที่จัดการรูปแบบ Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS อยู่เสมอ แต่ต้องใช้รูปแบบดังกล่าวแบบไม่มีการดำเนินการใดๆ กล่าวคือมีพฤติกรรมเทียบเท่ากับเมื่อผู้ใช้ถูกปฏิเสธการเข้าถึง

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

  • [C-16-1] ต้องแสดงลิงก์ดังกล่าวสำหรับบริการป้อนข้อความอัตโนมัติที่ติดตั้งไว้ทั้งหมด

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

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

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

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้ปฏิบัติตาม Intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA และ android.speech.tts.engine.GET_SAMPLE_TEXT โดยให้มี Activity เพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่

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

  • ควรรองรับโปรแกรมรักษาหน้าจอและระบุตัวเลือกการตั้งค่าเพื่อให้ผู้ใช้กำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อandroid.settings.DREAM_SETTINGS Intent

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

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

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

  • [C-1-1] ต้องตั้งค่าandroid.software.activities_on_secondary_displays Flag ฟีเจอร์
  • [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 เดิม

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

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

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

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

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

  • [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่ระบุไว้อย่างน้อย 1 รายการ
  • [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 ที่แนะนำมากที่สุดไปจนถึงน้อยที่สุด

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-0-6] ต้องรายงานชุดย่อยของ ABI ต่อไปนี้ผ่านพารามิเตอร์ข้างต้น และต้องไม่รายงาน ABI ที่ไม่ได้อยู่ในรายการ

สิ้นสุดข้อกำหนดใหม่

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

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

  • [C-1-1] ต้องอนุญาตให้ผู้ใช้ดูรายการแอปที่ถูกจำกัด
  • [C-1-2] ต้องให้ผู้ใช้เปิด / ปิดข้อจำกัดที่เป็นกรรมสิทธิ์ทั้งหมดเหล่านี้ในแอปแต่ละแอป

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

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

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

  • [C-1-6] จะต้องแสดงผลเป็น "จริง" สำหรับเมธอด ActivityManager.isBackgroundRestricted() สำหรับการเรียก API จากแอป

  • [C-1-7] ต้องไม่จํากัดแอปที่ทำงานอยู่เบื้องหน้าอันดับแรกที่ผู้ใช้ใช้อยู่อย่างชัดเจน

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

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

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

หากมีการติดตั้งแอปไว้ล่วงหน้าในอุปกรณ์และผู้ใช้ไม่เคยใช้งานแอปดังกล่าวอย่างชัดเจนนานกว่า 30 วัน [C-1-3] [C-1-5] จะได้รับการยกเว้น

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

  • [C-2-1]ต้องปฏิบัติตามการติดตั้งใช้งานที่อธิบายไว้ในเอกสารนี้

3.5.2. การพักใช้งานแอปพลิเคชัน

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

  • [C-1-1] ต้องปฏิบัติตามข้อกําหนดทั้งหมดในส่วนที่ 3.5.1 ยกเว้น [C-1-6] และ [C-1-3]
  • [C-1-2] ต้องจำกัดแอปสำหรับผู้ใช้ก็ต่อเมื่อมีหลักฐานว่าผู้ใช้ไม่ได้ใช้แอปเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้ระยะเวลานี้อย่างน้อย 1 เดือน การใช้งานต้องกำหนดโดยการโต้ตอบของผู้ใช้อย่างชัดเจนผ่าน API UsageStats#getLastTimeVisible() หรือสิ่งใดก็ตามที่จะทำให้แอปออกจากสถานะ "หยุดทำงานโดยบังคับ" ซึ่งรวมถึงการเชื่อมโยงบริการ การเชื่อมโยงผู้ให้บริการเนื้อหา การออกอากาศอย่างชัดแจ้ง ฯลฯ ซึ่งจะติดตามโดย API ใหม่อย่าง UsageStats#getLastTimeAnyComponentUsed()
  • [C-1-3] ต้องใช้ข้อจำกัดที่ส่งผลต่อผู้ใช้อุปกรณ์ทุกรายเฉพาะในกรณีที่มีหลักฐานว่าไม่มีผู้ใช้รายใดใช้แพ็กเกจเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้ระยะเวลานี้อย่างน้อย 1 เดือน
  • [C-1-4] ต้องไม่ทําให้แอปไม่สามารถตอบสนองต่อ Intent ของกิจกรรม การเชื่อมโยงบริการ คําขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่ชัดเจน

การทำให้เป็นโหมดพักของแอปใน AOSP เป็นไปตามข้อกำหนดข้างต้น

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

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

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

กล่าวคือ

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

  • [C-1-1] ต้องไม่อยู่ในไลบรารี NDK หรือไลบรารีที่เป็นขององค์กรอื่นตามที่อธิบายไว้ที่นี่

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

  • ควรทำการทดสอบ 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] ต้องรองรับทางลัดที่ปักหมุดไว้ รวมถึงทางลัดแบบไดนามิกและแบบคงที่ตามที่ระบุไว้ในหน้าทางลัดของแอป

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

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

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

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

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

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

  • [C-6-1] ต้องใช้งานเฉพาะเมื่อผู้ใช้เปิดใช้อย่างชัดเจน (เช่น ผ่านเมนูการตั้งค่าหรือเครื่องมือเลือกวอลเปเปอร์)

3.8.2. วิดเจ็ต

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

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

  • [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม android.software.app_widgets
  • [C-1-2] ต้องรองรับ App Widgets ในตัวและแสดงความสามารถในการใช้งานอินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ App Widgets ออก
  • [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-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกให้ผู้ใช้ควบคุมการแจ้งเตือนที่แสดงต่อแอปที่ได้รับสิทธิ์ Notification Listener ความละเอียดต้องเป็นแบบที่ผู้ใช้สามารถควบคุมประเภทการแจ้งเตือนที่บริดจ์ไปยัง Listener แต่ละรายการดังกล่าวได้ ประเภทต้องรวมถึงการแจ้งเตือน "การสนทนา" "การแจ้งเตือน" "ไม่มีเสียง" และ "ต่อเนื่องที่สำคัญ"

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้ระบุแอปที่จะยกเว้นไม่ให้แจ้งเตือนไปยัง Listener การแจ้งเตือนที่เฉพาะเจาะจง

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

  • ควรรองรับการแจ้งเตือนแบบริชมีเดีย

  • ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า

  • ควรมีสิ่งอํานวยความสะดวกสําหรับผู้ใช้ในการเลื่อนการแจ้งเตือน

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

Android 11 รองรับการแจ้งเตือนการสนทนา ซึ่งเป็นการแจ้งเตือนที่ใช้ MessagingStyle และระบุรหัสทางลัด People ที่เผยแพร่

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

  • [C-SR-4] ขอแนะนำอย่างยิ่งให้จัดกลุ่มและแสดง conversation notifications ก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือน importance:high ที่ทำงานอยู่

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

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

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

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

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

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

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

3.8.3.4. การป้องกันการแจ้งเตือนที่มีความละเอียดอ่อน

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

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

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

    • แอปที่ลงนามโดยระบบซึ่งมี uid < 10000
    • UI ของระบบ
    • เปลือกหอย
    • แอปอุปกรณ์ที่ใช้ร่วมกันที่กําหนด (ตามที่ CompanionDeviceManager ระบุ)
    • บทบาท SYSTEM_AUTOMOTIVE_PROJECTION
    • บทบาท SYSTEM_NOTIFICATION_INTELLIGENCE
    • บทบาท HOME

การติดตั้งใช้งาน NotificationAssistantServices ใน AOSP เป็นตัวอย่างที่เป็นไปตามข้อกำหนดเหล่านี้ ดูตัวอย่างได้ที่ android.ext.services.notification

สิ้นสุดข้อกำหนดใหม่

3.8.4. Assist 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 เพื่อแสดงสตริงแบบไม่โมดัลสั้นๆ ต่อผู้ใช้ปลายทาง ซึ่งจะหายไปหลังจากผ่านไประยะเวลาสั้นๆ และใช้ TYPE_APPLICATION_OVERLAY API ประเภทหน้าต่างเพื่อแสดงหน้าต่างแจ้งเตือนเป็นการวางซ้อนเหนือแอปอื่นๆ

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

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

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

3.8.6. ธีม

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

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

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

  • [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดงต่อแอปพลิเคชัน
  • [C-1-2] ต้องรองรับตระกูลธีม "Material" และห้ามแก้ไขแอตทริบิวต์ธีม Material หรือชิ้นงานที่แสดงต่อแอปพลิเคชัน

  • [C-1-3] ต้องตั้งค่าแบบอักษร "แบบไม่มีส่วนหัว" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือให้ทางเลือกแก่ผู้ใช้ในการเปลี่ยนแบบอักษรที่ใช้สำหรับแบบอักษร "แบบไม่มีส่วนหัว" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ

  • [C-1-4] ต้องสร้างชุดสีแบบไดนามิกตามที่ระบุไว้ในเอกสารประกอบ AOSP ของ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ดู android.theme.customization.system_palette และ android.theme.customization.theme_style)

  • [C-1-5] ต้องสร้างชุดสีแบบไดนามิกโดยใช้รูปแบบธีมสีที่ระบุไว้ในSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESเอกสารประกอบ (ดูandroid.theme.customization.theme_styles) ซึ่งได้แก่ TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD และMONOCHROMATIC

    "สีต้นทาง" ใช้ในการสร้างชุดสีโทนไดนามิกเมื่อส่งพร้อมกับ android.theme.customization.system_palette (ตามที่ระบุไว้ใน Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES)

  • [C-1-6] ต้องมีค่าสี CAM16 อย่างน้อย 5

    • ควรมาจากวอลเปเปอร์ผ่าน com.android.systemui.monet.ColorScheme#getSeedColors ซึ่งจะให้สีต้นทางที่ถูกต้องหลายสีให้เลือก

    • ควรใช้ค่า 0xFF1B6EF3 หากสีที่ระบุไม่เป็นไปตามข้อกำหนดสีของแหล่งที่มาข้างต้น

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

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

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

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

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

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

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

  • [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และรองรับ IME API ตามที่ระบุไว้ในเอกสารประกอบ Android SDK

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

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

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

ดูการตั้งค่าส่วนที่ 3.2.3.5 เพื่อกำหนดค่าการแสดงภาพพักหน้าจอ

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
  • [C-1-3] ต้องไม่นำออกหรือแก้ไข NotoColorEmoji.tff ในภาพระบบ (คุณสามารถเพิ่มแบบอักษรอีโมจิใหม่เพื่อลบล้างอีโมจิในไฟล์ NotoColorEmoji.tff ได้)
  • ควรรองรับอีโมจิสีผิวและครอบครัวที่หลากหลายตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51

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

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

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

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

  • [C-2-1] ต้องแสดงผลข้อความด้วยแบบอักษรที่เป็นไปตาม Unicode เป็นค่าเริ่มต้น ต้องไม่ตั้งค่าแบบอักษรที่ไม่เป็นไปตาม Unicode เป็นแบบอักษรเริ่มต้น เว้นแต่ว่าผู้ใช้จะเลือกแบบอักษรนั้นในเครื่องมือเลือกภาษา
  • [C-2-2] ต้องรองรับแบบอักษร Unicode และแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode หากอุปกรณ์รองรับแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode แบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode ต้องไม่นำออกหรือเขียนทับแบบอักษร Unicode
  • [C-2-3] ต้องแสดงผลข้อความด้วยแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode เฉพาะในกรณีที่มีการระบุ รหัสภาษาที่มีรหัสสคริปต์ Qaag (เช่น my-Qaag) คุณไม่สามารถใช้รหัสภาษาหรือรหัสภูมิภาค ISO อื่นๆ (ไม่ว่าจะกำหนดหรือไม่กำหนดหรือสงวนไว้) เพื่ออ้างอิงแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode สำหรับเมียนมาร์ นักพัฒนาแอปและผู้เขียนหน้าเว็บสามารถระบุ my-Qaag เป็นรหัสภาษาที่กำหนดได้เช่นเดียวกับภาษาอื่นๆ

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-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] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับหน้าต่าง PIP เมื่อแอปพลิเคชันไม่ได้ประกาศค่าใดๆ สำหรับ AndroidManifestLayout_minWidth และ AndroidManifestLayout_minHeight

    • อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าไว้เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_TELEVISION ต้องจัดสรรความกว้างและความสูงขั้นต่ำ 108 dp
    • อุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_TELEVISION ต้องจัดสรรความกว้างขั้นต่ำ 240 dp และความสูงขั้นต่ำ 135 dp

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [C-4-1] ต้องรองรับโหมดหลายหน้าต่าง

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

  • [C-5-1] ต้องใช้ส่วนขยาย Window Manager เวอร์ชันที่ถูกต้อง ระดับ API ตามที่อธิบายไว้ใน WindowManager ส่วนขยาย

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

3.8.16. ระบบควบคุมอุปกรณ์

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

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

3.8.17. คลิปบอร์ด

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

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

หากการติดตั้งใช้งานอุปกรณ์สร้างตัวอย่างที่ผู้ใช้มองเห็นได้เมื่อคัดลอกเนื้อหาไปยังคลิปบอร์ดสำหรับClipDataรายการที่ClipData.getDescription().getExtras()มีandroid.content.extra.IS_SENSITIVE รายการดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] MUST redact the user visible preview

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

Android มีฟีเจอร์ที่อนุญาต เปิดใช้แอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์เพื่อดำเนินการด้านการดูแลระบบอุปกรณ์ที่ระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือการล้างข้อมูลระยะไกล ผ่าน Android Device Administration API Device Policy Manager 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-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์ หรือเปิดใช้แอป DPC เพื่อเลือกว่าจะเป็นผู้ดูแลอุปกรณ์หรือเจ้าของโปรไฟล์ หากอุปกรณ์ประกาศการรองรับ Near Field Communication (NFC) ผ่าน Flag ฟีเจอร์ android.hardware.nfc และได้รับข้อความ NFC ที่มีระเบียนประเภท MIME MIME_TYPE_PROVISIONING_NFC
      • [C-1-8] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากที่มีการทริกเกอร์การจัดสรรเจ้าของอุปกรณ์เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ทั้งนี้ขึ้นอยู่กับค่าของ android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES เว้นแต่ว่าจะสามารถระบุจากบริบทได้ว่ามีตัวเลือกที่ถูกต้องเพียงตัวเลือกเดียว
      • [C-1-9] ต้องส่งความตั้งใจACTION_ADMIN_POLICY_COMPLIANCE ไปยังแอปเจ้าของอุปกรณ์หากมีการตั้งค่าเจ้าของอุปกรณ์ระหว่างการจัดสรร ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม ผู้ใช้ต้องดำเนินการในวิซาร์ดการตั้งค่าไม่ได้จนกว่าแอปเจ้าของอุปกรณ์จะเสร็จสิ้น
    • เมื่อการติดตั้งใช้งานอุปกรณ์มีผู้ใช้หรือข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
      • [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

  • [C-2-2] ต้องแสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับขั้นตอนที่ android.app.action.PROVISION_MANAGED_DEVICE เริ่มต้นขึ้นก่อนลงทะเบียนแอปพลิเคชัน DPC เป็น "เจ้าของอุปกรณ์"

  • [C-2-3] ต้องไม่เขียนโค้ดความยินยอมหรือป้องกันไม่ให้ใช้แอปอื่นๆ ของเจ้าของเครื่อง

สิ้นสุดข้อกำหนดใหม่

3.9.1.2. การจัดสรรโปรไฟล์ที่มีการจัดการ

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

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

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

  • [C-1-4] ต้องเปิดใช้งานตัวแฮนเดิลสำหรับ Intent ACTION_PROVISIONING_SUCCESSFUL ในโปรไฟล์งานหากมีการสร้างเจ้าของโปรไฟล์เมื่อเริ่มการกําหนดค่าโดย Intent android.app.action.PROVISION_MANAGED_PROFILE และ DPC ได้ใช้ตัวแฮนเดิล

  • [C-1-5] ต้องส่งการออกอากาศ ACTION_PROFILE_PROVISIONING_COMPLETE ไปยัง DPC ของโปรไฟล์งานเมื่อมีการเริ่มการจัดเตรียมโดย Intent android.app.action.PROVISION_MANAGED_PROFILE

  • [C-1-6] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากที่มีการเรียกให้แสดงการจัดสรรเจ้าของโปรไฟล์เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ยกเว้นในกรณีที่มีการเรียกให้แสดงการจัดสรรโดย Intent android.app.action.PROVISION_MANAGED_PROFILE

  • [C-1-7] ต้องส่ง Intent ACTION_ADMIN_POLICY_COMPLIANCE ไปยังโปรไฟล์งานเมื่อมีการสร้างเจ้าของโปรไฟล์ระหว่างการจัดเตรียม ไม่ว่าจะใช้วิธีการจัดเตรียมใดก็ตาม ยกเว้นในกรณีที่ Intent android.app.action.PROVISION_MANAGED_PROFILE ทริกเกอร์การจัดเตรียม ผู้ใช้ต้องดำเนินการในวิซาร์ดการตั้งค่าไม่ได้จนกว่าแอป Profile Admin จะเสร็จสิ้น

  • [C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ที่ออกอากาศไปยัง 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) เพื่อระบุว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่จัดการ
  • [C-1-5] ต้องแสดงข้อความแจ้งที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการเมื่ออุปกรณ์ตื่นขึ้น (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ในโปรไฟล์ที่มีการจัดการ
  • [C-1-6] หากมีโปรไฟล์ที่มีการจัดการ จะต้องแสดงสิ่งอำนวยความสะดวกที่มองเห็นได้ใน "เครื่องมือเลือก" Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อ Intent จากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หาก Device Policy Controller เปิดใช้
  • [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการ จะต้องแสดงสิ่งต่างๆ ต่อไปนี้สำหรับผู้ใช้ทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
    • แยกการนับแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
    • การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในโปรไฟล์ผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
    • การจัดการแอปพลิเคชันที่ติดตั้งภายในโปรไฟล์ผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
    • การจัดการบัญชีภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
  • [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันโทรศัพท์ รายชื่อติดต่อ และการรับส่งข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและดูข้อมูลผู้โทรจากโปรไฟล์ที่จัดการ (หากมี) ควบคู่ไปกับข้อมูลจากโปรไฟล์หลักได้ หากเครื่องมือควบคุมนโยบายอุปกรณ์อนุญาต
  • [C-1-9] ต้องตรวจสอบว่าโปรไฟล์เป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่ใช้ได้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
  • [C-1-10] ต้องตรวจสอบว่าระบบบันทึกข้อมูลภาพหน้าจอไว้ในพื้นที่เก็บข้อมูลของโปรไฟล์งานเมื่อจับภาพหน้าจอด้วยtopActivity หน้าต่างที่มีโฟกัส (หน้าต่างที่ผู้ใช้โต้ตอบด้วยครั้งล่าสุดจากกิจกรรมทั้งหมด) และเป็นของแอปในโปรไฟล์งาน
  • [C-1-11] ต้องไม่จับภาพเนื้อหาหน้าจออื่นๆ (แถบระบบ การแจ้งเตือน หรือเนื้อหาโปรไฟล์ส่วนตัว) ยกเว้นหน้าต่าง/หน้าต่างแอปพลิเคชันโปรไฟล์งานเมื่อบันทึกภาพหน้าจอไปยังโปรไฟล์งาน (เพื่อให้มั่นใจว่าระบบจะไม่บันทึกข้อมูลโปรไฟล์ส่วนตัวในโปรไฟล์งาน)

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

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

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับที่แสดงในขั้นตอนที่เริ่มต้นโดย android.app.action.PROVISION_MANAGED_DEVICE ก่อนที่จะอนุญาตให้เพิ่มบัญชีในผู้ใช้รองรายใหม่ เพื่อให้ผู้ใช้ทราบว่าอุปกรณ์มีการจัดการ

3.9.4. ข้อกำหนดของบทบาทการจัดการนโยบายอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รายงานเป็น android.software.device_admin หรือ android.software.managed_users แสดงว่าอุปกรณ์มีลักษณะดังนี้

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

หากไม่ได้กำหนดชื่อแพ็กเกจสำหรับ config_devicePolicyManagement ตามที่อธิบายไว้ข้างต้น ระบบจะทำดังนี้

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

หากมีการกําหนดชื่อแพ็กเกจสําหรับ config_devicePolicyManagement ตามที่อธิบายไว้ข้างต้น ให้ทําดังนี้

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

หากมีการกําหนดชื่อแพ็กเกจสําหรับ config_devicePolicyManagementUpdater ตามที่อธิบายไว้ข้างต้น

  • [C-4-1] แอปพลิเคชันต้องติดตั้งล่วงหน้าในอุปกรณ์
  • [C-4-2] แอปพลิเคชันต้องใช้ตัวกรอง Intent ที่แก้ไขได้ android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER

3.9.5. กรอบการแก้ปัญหาเกี่ยวกับนโยบายด้านอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รายงานเป็น android.software.device_admin หรือ android.software.managed_users แสดงว่าอุปกรณ์มีลักษณะดังนี้

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

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

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

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

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

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

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

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

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

สิ้นสุดข้อกำหนดใหม่

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] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

3.15. Instant Apps

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

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

  • การติดตั้งใช้งานอุปกรณ์ต้องให้สิ่งต่อไปนี้แก่ผู้ใช้สำหรับการโต้ตอบกับ Instant App AOSP เป็นไปตามข้อกำหนดด้วย UI ระบบ การตั้งค่า และ Launcher เริ่มต้น การติดตั้งใช้งานอุปกรณ์

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

  • [C-1-8] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการไว้ล่วงหน้า พร้อมกับตัวแฮนเดิล Intent สำหรับ Intent ที่แสดงอยู่ใน SDK ที่นี่ และทำให้ Intent แสดงสําหรับ Instant App

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

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

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

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ FEATURE_COMPANION_DEVICE_SETUP
  • [C-1-2] ต้องตรวจสอบว่า API ในแพ็กเกจ android.companion ใช้งานอย่างเต็มรูปแบบ

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

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

3.18. รายชื่อติดต่อ

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

RawContacts จะ "เชื่อมโยงกับ" หรือ "จัดเก็บใน" Account เมื่อคอลัมน์ ACCOUNT_NAME และ ACCOUNT_TYPE ของ Raw Contacts ตรงกับช่อง Account.name และ Account.type ของบัญชี

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าสร้างบัญชีในเครื่องที่กำหนดเอง

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

  • [C-1-1] ACCOUNT_NAME จากบัญชีในเครื่องที่กำหนดเองต้องส่งคืนโดย ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] ACCOUNT_TYPE จากบัญชีในเครื่องที่กำหนดเองต้องส่งคืนภายใน ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] ต้องแทรกรายชื่อติดต่อดิบที่แอปพลิเคชันของบุคคลที่สามแทรกลงในบัญชีในเครื่องเริ่มต้น (นั่นคือ การตั้งค่าค่า Null สำหรับ ACCOUNT_NAME และ ACCOUNT_TYPE) ลงในบัญชีในเครื่องที่กำหนดเอง
  • [C-1-4] รายชื่อติดต่อดิบซึ่งแทรกลงในบัญชีในเครื่องที่กำหนดเองต้องไม่ถูกนำออกเมื่อมีการเพิ่มหรือนำบัญชีออก
  • [C-1-5] การดำเนินการลบในบัญชีในเครื่องที่กำหนดเองต้องส่งผลให้ระบบล้างข้อมูลติดต่อดิบทันที (เหมือนกับมีการตั้งค่าพารามิเตอร์ CALLER_IS_SYNCADAPTER เป็น true) แม้ว่าจะมีการตั้งค่าพารามิเตอร์ CALLER\_IS\_SYNCADAPTER เป็น false หรือไม่ระบุก็ตาม

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

3.19. การตั้งค่าภาษา

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

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

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

  • [C-0-2] ต้องรองรับการยืนยันไฟล์ ".apk" โดยใช้ APK Signature Scheme v3.1, 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 ข้อยกเว้นเพียงอย่างเดียวคือการจัดการแอปโปรแกรมตรวจสอบแพ็กเกจของระบบที่มีPACKAGE_NEEDS_VERIFICATION Intent และการจัดการแอปเครื่องมือจัดการพื้นที่เก็บข้อมูลที่มีACTION_MANAGE_STORAGE Intent

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

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

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

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

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

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

  • [C-0-8] ต้องรองรับระบบไฟล์แบบเพิ่มข้อมูลตามที่ระบุไว้ที่นี่

  • [C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4 และ APK Signature Scheme v4.1

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 เพื่อกำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ DRC ของ AAC เปิดตัวใน API 21 โดยมีคีย์ดังนี้ KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_ENCODED_TARGET_LEVEL
  • [C-SR-1] ขอแนะนำอย่างยิ่งว่าโปรแกรมถอดรหัสเสียง 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

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

  • [C-7-1] แอปพลิเคชันที่ใช้การถอดรหัสต้องกำหนดค่าได้โดยใช้คีย์ KEY_MAX_OUTPUT_CHANNEL_COUNT เพื่อควบคุมว่าจะลดคุณภาพเนื้อหาเป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือส่งออกโดยใช้จำนวนช่องของต้นฉบับ (เมื่อใช้ค่าเท่ากับหรือมากกว่าจำนวนดังกล่าว) ตัวอย่างเช่น ค่า 6 ขึ้นไปจะกำหนดค่าโปรแกรมถอดรหัสให้ส่งออก 6 ช่องเมื่อป้อนเนื้อหา 5.1
  • [C-7-2] เมื่อถอดรหัส ผู้ถอดรหัสต้องแสดงหน้ากากช่องที่ใช้อยู่ในรูปแบบเอาต์พุตด้วยคีย์ KEY_CHANNEL_MASK โดยใช้ค่าคงที่ android.media.AudioFormat (เช่น CHANNEL_OUT_5POINT1)

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

  • [C-SR-2] ขอแนะนำอย่างยิ่งว่าแอปพลิเคชันที่ใช้การถอดรหัสด้วยคีย์ KEY_MAX_OUTPUT_CHANNEL_COUNT ควรกำหนดค่าโปรแกรมถอดรหัสได้เพื่อควบคุมว่าจะลดคุณภาพเนื้อหาเป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือส่งออกโดยใช้จำนวนช่องแบบดั้งเดิม (เมื่อใช้ค่าเท่ากับหรือมากกว่าจำนวนดังกล่าว) ตัวอย่างเช่น ค่า 6 ขึ้นไปจะกำหนดค่าโปรแกรมถอดรหัสให้ส่งออก 6 ช่องเมื่อป้อนเนื้อหา 5.1
  • [C-SR-3] เมื่อถอดรหัส เราขอแนะนำอย่างยิ่งให้โปรแกรมถอดรหัสแสดงหน้ากากช่องที่ใช้กับรูปแบบเอาต์พุตด้วยคีย์ KEY_CHANNEL_MASK โดยใช้ค่าคงที่ android.media.AudioFormat (เช่น CHANNEL_OUT_5POINT1)

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับการเข้ารหัส 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] AVIF (Baseline Profile)

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

  • [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)

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

  • [C-2-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)
AVIF (โปรไฟล์พื้นฐาน) โปรไฟล์พื้นฐานของรูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ คอนเทนเนอร์ HEIF (.avif)

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

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

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

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

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

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

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้โปรแกรมเข้ารหัสและถอดรหัสวิดีโอรองรับรูปแบบสี 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
AV1 ดูรายละเอียดได้ที่ส่วนที่ 5.2 และส่วนที่ 5.3
  • MPEG-4 (.mp4)
  • Matroska (.mkv, ถอดรหัสเท่านั้น)

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-1] ขอแนะนำอย่างยิ่งให้รองรับ Codec 2.0 API

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

  • [C-2-1] ต้องใส่โปรแกรมเปลี่ยนรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจากโปรเจ็กต์โอเพนซอร์สของ Android (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละประเภท (โปรแกรมเข้ารหัสหรือโปรแกรมถอดรหัส) ที่อุปกรณ์รองรับ
  • [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้โปรแกรมเปลี่ยนไฟล์ซอฟต์แวร์ 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 หรือไม่อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องระบุว่าเป็น Vendor
  • [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 พิกเซล (อื่นๆ, AV1)
  • 1408 x 1152 พิกเซล (H263)
  • 1280 x 720 พิกเซล (อื่นๆ, AV1)
 1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4, AV1) 3840 x 2160 พิกเซล (HEVC, VP9, AV1)
  • [C-2-2] โปรแกรมเปลี่ยนรหัสวิดีโอที่มีลักษณะเป็นการเร่งฮาร์ดแวร์ต้องเผยแพร่ข้อมูลจุดประสิทธิภาพ โดยแต่ละรายการต้องระบุจุดประสิทธิภาพมาตรฐานที่รองรับทั้งหมด (แสดงอยู่ใน PerformancePoint API) เว้นแต่ว่าจุดประสิทธิภาพมาตรฐานที่รองรับรายการอื่นจะครอบคลุมจุดดังกล่าว
  • นอกจากนี้ ควรเผยแพร่จุดประสิทธิภาพเพิ่มเติมหากรองรับประสิทธิภาพวิดีโอที่ยั่งยืนนอกเหนือจากมาตรฐานที่ระบุไว้

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

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

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

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

  • [C-SR-2] ขอแนะนำอย่างยิ่งว่าอย่าให้อัตราบิตสูงกว่าอัตราบิตเป้าหมายมากกว่า 15% ในช่วง 1 วินาที

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์มีการเข้ารหัส HDR อุปกรณ์จะมีลักษณะดังนี้

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

5.2.1. H.263

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

  • [C-1-1] ต้องรองรับความละเอียด QCIF (176 x 144) ใช้โปรไฟล์พื้นฐานระดับ 45 ความละเอียด SQCIF เป็นตัวเลือกที่ไม่บังคับ

5.2.2. H.264

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

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

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

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

  • [C-1-2] ต้องเผยแพร่ข้อมูลประสิทธิภาพ เช่น รายงานข้อมูลประสิทธิภาพผ่าน API ของ getSupportedFrameRatesFor() หรือ getSupportedPerformancePoints() สำหรับความละเอียดที่รองรับในตารางด้านล่าง

  • [C-1-3] ต้องยอมรับข้อมูลเมตา HDR และส่งออกไปยังบิตสตรีม

หากโปรแกรมเปลี่ยนไฟล์ AV1 มีการเร่งฮาร์ดแวร์ ก็จะมีลักษณะดังนี้

  • [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสสูงสุด HD1080p จากตารางด้านล่าง
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
อัตราบิตของวิดีโอ 5 Mbps 8 Mbps 16 Mbps 50 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 (ความละเอียด CIF, QCIF และ SQCIF ที่ 30 fps 384 Kbps) และระดับ 45 (ความละเอียด QCIF และ SQCIF ที่ 30 fps 128 Kbps)

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

  • [C-3-1] การติดตั้งใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็นจากแอปพลิเคชัน รวมถึงรองรับการดึงข้อมูลและแสดงข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์
  • [C-3-2] การติดตั้งใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR บนหน้าจออุปกรณ์หรือพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างเหมาะสม (เช่น 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] การติดตั้งใช้งานอุปกรณ์ต้องรองรับการถอดรหัสโปรไฟล์ 720, 1080 และ UHD ของ VP9 หรือ H.265 อย่างน้อย 1 รายการ
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 ผ่าน 'CodecProfileLevel' media API ให้ทำดังนี้

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

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

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

5.3.8. Dolby Vision

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

  • [C-1-1] ต้องมีโปรแกรมแยกที่สามารถแยก Dolby Vision

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

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

5.3.9. AV1

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

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

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

  • [C-2-1] ต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 720p เป็นอย่างน้อยจากตารางด้านล่างเมื่อความสูงที่รายงานโดยวิธีการของ Display.getSupportedModes() เท่ากับหรือมากกว่า 720p
  • [C-2-2] ต้องสามารถถอดรหัสโปรไฟล์การถอดรหัสวิดีโอ HD 1080p เป็นอย่างน้อยจากตารางด้านล่างเมื่อความสูงที่รายงานโดยวิธีการ Display.getSupportedModes() เท่ากับหรือมากกว่า 1080p
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
อัตราบิตของวิดีโอ 5 Mbps 8 Mbps 16 Mbps 50 Mbps

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรไฟล์ HDR ผ่าน Media API อุปกรณ์จะดำเนินการต่อไปนี้

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

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

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

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

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

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

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

    • รูปแบบ: 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 ที่ใช้งานอยู่โดยใช้ MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED หรือ VOICE_PERFORMANCE หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้บันทึกเนื้อหาเสียงดิบคุณภาพระดับวิทยุ 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

  • ควรแสดงลักษณะความดังเทียบกับความถี่ที่ราบเรียบโดยประมาณในย่านความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

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

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

  • ควรตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB (วัดข้างไมโครโฟน) ให้ผลการตอบสนอง RMS 2500 ที่เหมาะที่สุดภายในช่วง 1,770 ถึง 3,530 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB ±3dB Full Scale สำหรับตัวอย่างแบบทศนิยม/แบบละเอียด) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

  • ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงเพื่อให้ระดับแอมพลิจูด 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

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

  • [C-SR-1] เราขอแนะนำอย่างยิ่งให้ประกาศผ่านเมธอด AcousticEchoCanceler ของ AcousticEchoCanceler.isAvailable() ใน API
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย AcousticEchoCanceler API
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้ระบุการใช้งานเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกันผ่านช่อง AudioEffect.Descriptor.uuid

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

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

  • [C-1-1] ต้องอนุญาตให้เข้าถึงไมโครโฟนพร้อมกันโดยบริการการช่วยเหลือพิเศษที่บันทึกด้วย AudioSource.VOICE_RECOGNITION และแอปพลิเคชันที่บันทึกด้วย AudioSource อย่างน้อย 1 แอป
  • [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.5. การเล่นเสียง

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

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

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

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

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

  • ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์แบบทศนิยมและแบบหลายช่อง

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

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

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

5.5.4. การโอนข้อมูลเสียง

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัดเนื้อหาเสียงแบบเล่นต่อเนื่องระหว่างคลิป 2 คลิปที่มีรูปแบบเดียวกันเมื่อระบุโดย AudioTrack gapless API และคอนเทนเนอร์สื่อสำหรับ MediaPlayer

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

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

ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • เวลาในการตอบสนองจากการแตะเพื่อฟังเสียง (TTL) ที่วัดโดย CTS Verifier คือเวลาระหว่างที่มีการแตะหน้าจอไปจนถึงเวลาที่ได้ยินเสียงที่เกิดจากเสียงที่เกิดจากการแตะนั้นในลำโพง ค่านี้เป็นค่าเฉลี่ยของการวัด 5 ครั้งโดยใช้ API เสียงแบบเนทีฟของ AAudio สำหรับเอาต์พุต

  • เวลาในการตอบสนองแบบไปกลับ (RTL) ที่วัดโดยโปรแกรมตรวจสอบ CTS คือค่าเฉลี่ยของเวลาในการตอบสนองแบบต่อเนื่องจากการวัด 5 ครั้ง ซึ่งวัดผ่านเส้นทางการวนซ้ำที่ส่งเอาต์พุตกลับไปยังอินพุตโดยใช้ API เสียงแบบเนทีฟของ AAudio เส้นทางการวนลูปมีดังนี้

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

  • FEATURE_AUDIO_LOW_LATENCY ประกาศฟีเจอร์ android.hardware.audio.low_latency

  • FEATURE_AUDIO_PRO ประกาศฟีเจอร์ android.hardware.audio.pro

  • MPC คลาสประสิทธิภาพสื่อ

  • เวลาในการตอบสนองของการติดตามการเคลื่อนไหวของศีรษะ เวลาที่ใช้ในการประมวลผลการเคลื่อนไหวของศีรษะซึ่งหน่วยวัดความเฉื่อย (IMU) จับได้ไปจนถึงการตรวจจับการเปลี่ยนแปลงของเสียงที่เกิดจากการเคลื่อนไหวนี้ของทรานสดิวเซอร์หูฟัง

สิ้นสุดข้อกำหนดใหม่

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-1] การประทับเวลาเอาต์พุตที่ AudioTrack.getTimestamp และ AAudioStream_getTimestamp แสดงผลจะมีความแม่นยำ +/- 2 มิลลิวินาที

สิ้นสุดข้อกำหนดใหม่

  • [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบ Cold Start ไม่เกิน 500 มิลลิวินาที

  • [C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้ AAudioStreamBuilder_openStream() ต้องใช้เวลาไม่เกิน 1,000 มิลลิวินาที

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-4] เวลาในการตอบสนองแบบไปกลับที่คำนวณจากการประทับเวลาอินพุตและเอาต์พุตที่ AAudioStream_getTimestamp แสดงต้องอยู่ภายใน 200 มิลลิวินาทีของเวลาในการตอบสนองแบบไปกลับที่วัดได้สำหรับ AAUDIO_PERFORMANCE_MODE_NONE และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY สำหรับลำโพง เฮดเซ็ตแบบใช้สายและไร้สาย

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [C-SR-1] เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของลำโพง

  • [C-SR-2] เวลาในการตอบสนองของฟีเจอร์แตะเพื่อเปิดเสียงไม่เกิน 80 มิลลิวินาที

  • [C-SR-4] ขอแนะนำอย่างยิ่งให้เวลาในการตอบสนองแบบไปกลับที่คำนวณตามการประทับเวลาอินพุตและเอาต์พุตที่ AAudioStream_getTimestamp แสดงอยู่ภายใน 30 มิลลิวินาทีของเวลาในการตอบสนองแบบไปกลับที่วัดได้สำหรับ AAUDIO_PERFORMANCE_MODE_NONE และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY สำหรับลำโพง ชุดหูฟังแบบมีสายและไร้สาย

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลเป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงความคลาดเคลื่อนจากค่าที่ถูกต้อง

สิ้นสุดข้อกำหนดใหม่

  • [C-3-2] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 500 มิลลิวินาที
  • [C-3-3] การเปิดสตรีมอินพุตโดยใช้ AAudioStreamBuilder_openStream() ต้องใช้เวลาไม่เกิน 1,000 มิลลิวินาที

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [C-SR-12] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองไป-กลับแบบต่อเนื่องเฉลี่ยไม่เกิน 50 มิลลิวินาทีในการวัด 5 ครั้ง โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

ตารางต่อไปนี้กำหนดข้อกำหนดสำหรับ RTL สำหรับการใช้งานในอุปกรณ์พกพาตามที่ระบุไว้ใน 2.2.1 ที่ประกาศ android.hardware.audio.output และ android.hardware.microphone

อุปกรณ์และการประกาศ RTL (มิลลิวินาที) MAD (มิลลิวินาที) เส้นทาง Loopback
มือถือ 250 30 ลำโพง/ไมโครโฟน, แอนะล็อก 3.5 มม. (หากรองรับ), USB (หากรองรับ)
>= MPC_T (14) 80 15 เส้นทางอย่างน้อย 1 เส้นทาง
FEATURE_AUDIO_LOW_LATENCY 50 10 เส้นทางอย่างน้อย 1 เส้นทาง
FEATURE_AUDIO_PRO 25 5 เส้นทางอย่างน้อย 1 เส้นทาง
FEATURE_AUDIO_PRO 20 5 อนาล็อก (หากรองรับ)
FEATURE_AUDIO_PRO 25 5 USB (หากไม่รองรับแบบอนาล็อก)

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

ตารางต่อไปนี้กำหนดข้อกำหนดสำหรับ TTL สำหรับการใช้งานในอุปกรณ์พกพาตามที่ระบุไว้ใน 2.2.1 ที่ประกาศ android.hardware.audio.output และ android.hardware.microphone

อุปกรณ์และการประกาศ TTL (มิลลิวินาที)
มือถือ 250
>= MPC_T (14) 80
MPC_S (13) 100
FEATURE_AUDIO_PRO 80

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากการติดตั้งใช้งานอุปกรณ์รองรับ spatial audio ที่มีการติดตามการเคลื่อนไหวของศีรษะ และประกาศ Flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องมีการหน่วงเวลาสูงสุดในการติดตามการเคลื่อนไหวของศีรษะเพื่ออัปเดตเสียงไม่เกิน 300 มิลลิวินาที

สิ้นสุดข้อกำหนดใหม่

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

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

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

  • [C-1-1] ต้องรองรับตัวแปลงสัญญาณหรือคอนเทนเนอร์นั้นผ่าน HTTP และ HTTPS

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

  • [C-1-3] ต้องรองรับรูปแบบเพย์โหลด RTSP ที่เกี่ยวข้องตามที่แสดงในตาราง 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.8

ตัวแปลงรหัสเสียง

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

RTSP (RTP, SDP)

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

  • ควรรองรับโหมดอุปกรณ์ต่อพ่วง MIDI ผ่าน USB, ส่วน 7.7

5.10. เสียงระดับมืออาชีพ

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

  • [C-1-1] ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

  • [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
  • [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-5] ต้องเป็นไปตามข้อกำหนดเวลาในการตอบสนองและเวลาในการตอบสนองของเสียงจาก USB โดยใช้ API เสียงแบบเนทีฟของ AAudio และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY

สิ้นสุดข้อกำหนดใหม่

  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 200 มิลลิวินาที

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-8] ต้องมีเวลาในการตอบสนองโดยเฉลี่ยจากการแตะเพื่อเปิดเสียงที่ 80 มิลลิวินาทีหรือน้อยกว่าจากค่าการวัดอย่างน้อย 5 ครั้งในเส้นทางข้อมูลจากลำโพงไปยังไมโครโฟน
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้มีค่าเวลาในการตอบสนองตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียง ซึ่งมีค่าไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้ง โดยค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางจากลำโพงไปยังไมโครโฟน
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดของเสียงระดับมืออาชีพสำหรับเวลาในการตอบสนองของเสียงแบบไปกลับอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตแบบ Cold และเวลาในการตอบสนองของเอาต์พุตแบบ Cold รวมถึงข้อกำหนดของเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP

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

    • voicemark.90 >= 32 voices
    • latencymark.fixed.little <= 15 msec
    • latencymark.dynamic.little <= 50 msec

  • ควรลดความคลาดเคลื่อนและการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน

  • ควรลดการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่

  • ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์

  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB

  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในเส้นทางทั้งหมด

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

  • ควรไม่มีข้อบกพร่องของเสียงเมื่อใช้งานตามปกติโดยมีเวลาในการตอบสนองตามที่รายงาน

  • ควรให้เวลาในการตอบสนองระหว่างแชแนลเป็น 0

  • ควรลดเวลาในการตอบสนองเฉลี่ยของ MIDI ในการขนส่งทั้งหมด

  • ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI เมื่อโหลด (การกระตุก) บนทรานสปอร์ตทั้งหมด

  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการขนส่งทั้งหมด

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

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

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

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

  • ควรลดเวลาในการตอบสนองต่อการสัมผัส

  • ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระ (การกระตุก)

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

สิ้นสุดข้อกำหนดใหม่

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องโดยเฉลี่ยตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียงไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางช่องเสียบเสียงโดยใช้ดองเกิลการบันทึกเสียง

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

สิ้นสุดข้อกำหนดใหม่

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

  • [C-3-1] ต้องติดตั้งใช้งานคลาสเสียง USB

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-3-2] ต้องมีเวลาในการตอบสนองของเสียงแบบไปกลับต่อเนื่องโดยเฉลี่ยไม่เกิน 25 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB (สามารถวัดโดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์เชื่อมต่ออินพุตกับเอาต์พุต)
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 แชนแนลในแต่ละทิศทาง, อัตราตัวอย่าง 96 kHz และความละเอียด 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย
  • [C-SR-7] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

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

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

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

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

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

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

5.12. วิดีโอ HDR

Android 13 รองรับเทคโนโลยี HDR ตามที่อธิบายไว้ในเอกสารที่กำลังจะเผยแพร่

รูปแบบพิกเซล

หากโปรแกรมถอดรหัสวิดีโอโฆษณารองรับ COLOR_FormatYUVP010 ให้ทำดังนี้

  • [C-1-1] ต้องรองรับรูปแบบ P010 สำหรับการอ่านจาก CPU (ImageReader, MediaImage, ByteBuffer) ใน Android 13 จะมีการผ่อนปรน P010 เพื่ออนุญาตให้ใช้ Stride ที่กำหนดเองสำหรับระนาบ Y และ UV

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

หากโปรแกรมถอดรหัสวิดีโอโฆษณาว่ารองรับ COLOR_Format32bitABGR2101010 โปรแกรมจะมีลักษณะดังนี้

  • [C-2-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับพื้นผิวเอาต์พุตและอ่านได้โดยใช้ CPU (เอาต์พุต ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอโฆษณาว่ารองรับ COLOR_FormatYUVP010 โปรแกรมจะมีลักษณะดังนี้

  • [C-3-1] ต้องรองรับรูปแบบ P010 สำหรับอินพุตพื้นผิวและอินพุตที่ CPU เขียนได้ (ImageWriter, MediaImage, ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอโฆษณาว่ารองรับ COLOR_Format32bitABGR2101010 โปรแกรมจะมีลักษณะดังนี้

  • [C-4-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับอินพุตพื้นผิวและอินพุต (ImageWriter, ByteBuffer) ที่ CPU เขียนได้ หมายเหตุ: ไม่จำเป็นต้องแปลงระหว่างเส้นโค้งการโอนต่างๆ สำหรับโปรแกรมเปลี่ยนไฟล์

ข้อกำหนดในการจับภาพ HDR

สําหรับโปรแกรมเข้ารหัสวิดีโอทั้งหมดที่รองรับโปรไฟล์ HDR การใช้งานอุปกรณ์

  • [C-5-1] ต้องไม่ถือว่าข้อมูลเมตา HDR ถูกต้อง เช่น เฟรมที่เข้ารหัสอาจมีพิกเซลที่เกินระดับความสว่างสูงสุด หรือฮิสโตแกรมอาจไม่ได้แสดงถึงเฟรม

  • ควรรวบรวมข้อมูลเมตาแบบไดนามิกของ HDR เพื่อสร้างข้อมูลเมตาแบบคงที่ของ HDR ที่เหมาะสมสำหรับสตรีมที่เข้ารหัส และควรแสดงผลข้อมูลเมตาดังกล่าวเมื่อสิ้นสุดเซสชันการเข้ารหัสแต่ละเซสชัน

หากการติดตั้งใช้งานอุปกรณ์รองรับการจับภาพ HDR โดยใช้ CamcorderProfile API ระบบจะดำเนินการต่อไปนี้

  • [C-6-1] ต้องรองรับการจับภาพ HDR ผ่าน Camera2 API ด้วย

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

  • [C-6-3] ต้องรองรับการจับภาพ HLG เป็นอย่างน้อย

  • [C-6-4] ต้องรองรับการเขียนข้อมูลเมตา HDR (หากเกี่ยวข้องกับเทคโนโลยี HDR) ลงในไฟล์วิดีโอที่บันทึกไว้ สำหรับ AV1, HEVC และ DolbyVision การดำเนินการนี้หมายถึงการรวมข้อมูลเมตาไว้ในบิตสตรีมที่เข้ารหัส

  • [C-6-5] ต้องรองรับ P010 และ COLOR_FormatYUVP010

  • [C-6-6] ต้องรองรับการแมปโทนสี HDR เป็น SDR ในโปรแกรมถอดรหัสที่เร่งด้วยฮาร์ดแวร์เริ่มต้นสำหรับโปรไฟล์ที่บันทึกไว้ กล่าวคือ หากอุปกรณ์จับภาพ HEVC HDR10+ ได้ ตัวถอดรหัส HEVC เริ่มต้นต้องถอดรหัสสตรีมที่บันทึกไว้ในรูปแบบ SDR ได้

ข้อกำหนดในการแก้ไข HDR

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

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

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

  • [C-7-1] ต้องรองรับโปรไฟล์ HDR อย่างน้อย 1 โปรไฟล์

  • [C-7-2] ต้องรองรับ FEATURE_HdrEditing สำหรับโปรไฟล์ HDR ทั้งหมดที่ตัวแปลงรหัสนั้นโฆษณาไว้ กล่าวคือ ต้องรองรับการสร้างข้อมูลเมตา HDR เมื่อไม่มีข้อมูลเมตา HDR สำหรับโปรไฟล์ HDR ทั้งหมดที่รองรับ

  • [C-7-3] ต้องรองรับรูปแบบอินพุตโปรแกรมเปลี่ยนไฟล์วิดีโอต่อไปนี้ซึ่งจะรักษาสัญญาณที่ถอดรหัส HDR ไว้อย่างสมบูรณ์

    • RGBA_1010102 (อยู่ในเส้นโค้งการโอนเป้าหมายอยู่แล้ว) สําหรับทั้งอินพุต ByteBuffer และ Surface และต้องโฆษณาการรองรับ COLOR_Format32bitABGR2101010

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

  • [C-7-4] ต้องโฆษณาการรองรับส่วนขยาย EXT_YUV_target OpenGL

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

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

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

  • [C-0-1] ต้องรองรับเครื่องมือสําหรับนักพัฒนาแอป Android ที่ระบุไว้ใน Android SDK
  • Android Debug Bridge (adb)

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง dumpsys cmd stats และ Simpleperf

สิ้นสุดข้อกำหนดใหม่

  • [C-0-11] ต้องรองรับคำสั่งเชลล์ cmd testharness การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันเก่าที่ไม่มีบล็อกข้อมูลที่ถาวรอาจได้รับการยกเว้นจาก C-0-11
  • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ของระบบอุปกรณ์ (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับcmd statsคำสั่งเชลล์และStatsManagerคลาส System API
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyboardConfigured
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • TouchpadUsage
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

สิ้นสุดข้อกำหนดใหม่

  • [C-0-4] ต้องมี Daemon ของ adb ฝั่งอุปกรณ์ที่ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
  • [C-0-5] MUST support secure adb. Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักซึ่งผ่านการตรวจสอบสิทธิ์
  • [C-0-6] ต้องระบุกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

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

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

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องมีเมธอด AdbManager#isAdbWifiSupported() ที่แสดงผล true

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต และมีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้

  • [C-5-1] ต้องมีเมธอด AdbManager#isAdbWifiQrSupported() return true

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุน ddms จึงควรปิดอยู่โดยค่าเริ่มต้น แต่จะต้องรองรับเมื่อใดก็ตามที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามที่ระบุไว้ข้างต้น

  • SysTrace

    • [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดอยู่โดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace

  • Perfetto

    • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดง /system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto
    • [C-SR-2] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เป็นอินพุตสำหรับการกําหนดค่า protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-3] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เพื่อเขียนร่องรอย protobuf ที่เป็นเอาต์พุต ซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-4] ขอแนะนําอย่างยิ่งให้ระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto

  • Low Memory Killer

    • [C-0-12] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ลงในบันทึก statsd เมื่อแอปถูกสิ้นสุดโดย Low Memory Killer

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

  • ข้อมูลการทํางานของ GPU

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

    • [C-0-13] ต้องใช้งานคำสั่งเชลล์ dumpsys gpu --gpuwork เพื่อแสดงข้อมูลการทํางานของ GPU ที่รวบรวมไว้ซึ่งแสดงผลโดยจุดติดตามเคอร์เนล power/gpu_work_period หรือไม่แสดงข้อมูลหากระบบไม่รองรับจุดติดตาม การใช้งาน AOSP frameworks/native/services/gpuservice/gpuwork/

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

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

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

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

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

  • [C-0-1] MUST honor the android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application development-related settings. การใช้งาน Android เวอร์ชัน upstream จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปไว้โดยค่าเริ่มต้น และเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปหลังจากที่กดรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์ 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 คือหน้าจอแสดงผลที่ใช้ลักษณะการทำงานและ API ทั้งหมดที่อธิบายไว้ในนักพัฒนาแอป Android - ภาพรวมความเข้ากันได้ของหน้าจอ ส่วนนี้ (7.1) และส่วนย่อย รวมถึงลักษณะการทำงานเพิ่มเติมที่เฉพาะเจาะจงสำหรับประเภทอุปกรณ์ที่ระบุไว้ในส่วนที่ 2 ของ CDD นี้

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

  • [C-0-1] โดยค่าเริ่มต้น จะต้องแสดงผลแอปพลิเคชันของบุคคลที่สามบนจอแสดงผลที่เข้ากันได้กับ Android เท่านั้น

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

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

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การกำหนดค่าขนาด และใช้งานจอแสดงผลที่มีมุมมนเพื่อแสดงผลหน้าจอเหล่านี้ อุปกรณ์จะมีลักษณะดังนี้

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

    • รัศมีของมุมมนน้อยกว่าหรือเท่ากับ 38 dp
    • เมื่อวางกล่องขนาด 18 dp x 18 dp ที่มุมแต่ละมุมของการแสดงผลเชิงตรรกะ แต่ละกล่องจะปรากฏบนหน้าจออย่างน้อย 1 พิกเซล

  • ควรมีสิ่งต่างๆ ที่ผู้ใช้สามารถโต้ตอบด้วยเพื่อเปลี่ยนไปใช้โหมดการแสดงผลที่มีมุมสี่เหลี่ยมผืนผ้า

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

  • [C-4-1] ต้องมีขนาดเลย์เอาต์อย่างน้อย 596 dp x 384 dp ขึ้นไป โดยไม่รวมส่วนที่ถูกตัดออกของจอแสดงผล

ดูรายละเอียดเกี่ยวกับการใช้ Sidecar หรือ Extension API อย่างถูกต้องได้จากเอกสารประกอบสาธารณะของ Window Manager Jetpack

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [C-4-1] ต้องติดตั้งใช้งานส่วนขยาย Window Manager เวอร์ชันที่ถูกต้อง ระดับ API ตามที่อธิบายไว้ในส่วนขยาย WindowManager

สิ้นสุดข้อกำหนดใหม่

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

ส่วนนี้ถูกลบออกใน Android 14

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

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

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

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

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

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

  • [C-1-1] ต้องไม่ปรับขนาดการแสดงผลให้ใหญ่กว่า 1.5 เท่า DENSITY_DEVICE_STABLE หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพเล็กกว่า 320dp (เทียบเท่าตัวระบุทรัพยากร sw320dp) แล้วแต่ว่าข้อใดจะเกิดขึ้นก่อน
  • [C-1-2] ต้องไม่ปรับขนาดการแสดงผลให้เล็กกว่า 0.85 เท่าของ DENSITY_DEVICE_STABLE
  • เราขอแนะนำให้ใช้การปรับขนาดตัวเลือกการแสดงโฆษณาเนทีฟต่อไปนี้ (ขณะที่เป็นไปตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อให้ใช้งานได้ดีและมีขนาดแบบอักษรที่สอดคล้องกัน (
    • เล็ก: 0.85x
    • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
    • ใหญ่: 1.15 เท่า
    • ใหญ่ขึ้น: 1.3 เท่า
    • ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

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

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1

สิ้นสุดข้อกำหนดใหม่

  • ควรรองรับ OpenGL ES 3.2

การทดสอบ dEQP ของ OpenGL ES จะแบ่งออกเป็นรายการการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/หมายเลขเวอร์ชันที่เชื่อมโยงกัน ซึ่งอยู่ในซอร์สโค้ดของ Android ที่ external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ OpenGL ES ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทดสอบ dEQP ในรายการทดสอบทั้งหมดตั้งแต่ระดับนี้และต่ำกว่า

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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-2-3] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ OpenGL ES ที่รองรับผ่าน Flag ฟีเจอร์ android.software.opengles.deqp.level
  • [C-2-4] ต้องรองรับเวอร์ชัน 132383489 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2020) ตามที่รายงานใน Flag ฟีเจอร์ android.software.opengles.deqp.level
  • [C-2-5] ต้องผ่านการทดสอบ dEQP ของ OpenGL ES ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 กับเวอร์ชันที่ระบุในฟีเจอร์ Flag android.software.opengles.deqp.level สำหรับ OpenGL ES แต่ละเวอร์ชันที่รองรับ
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย EGL_KHR_partial_update และ OES_EGL_image_external

  • ควรรายงานอย่างถูกต้องผ่านเมธอด getString() เกี่ยวกับรูปแบบการบีบอัดพื้นผิวที่รองรับ ซึ่งโดยทั่วไปจะเจาะจงตามผู้ให้บริการ

  • ควรรองรับส่วนขยาย EGL_IMG_context_priority และ EGL_EXT_protected_content

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่สอดคล้องกันสำหรับเวอร์ชันเหล่านี้นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
  • [C-SR-3] ขอแนะนําอย่างยิ่งให้รองรับส่วนขยาย 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] ต้องระบุการรองรับผ่านandroid.hardware.opengles.aep Flag ฟีเจอร์

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.3
  • [C-4-1] ต้องไม่รองรับเวอร์ชันตัวแปรของ Vulkan (กล่าวคือ เวอร์ชันตัวแปรของ Vulkan ต้องเท่ากับ 0)

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

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

การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เกี่ยวข้อง ซึ่งอยู่ในซอร์สโค้ดของ Android ที่ external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ Vulkan ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทดสอบ dEQP ในรายการทดสอบทั้งหมดตั้งแต่ระดับนี้และต่ำกว่า

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

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วย Flag ฟีเจอร์ android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องระบุ VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ Vulkan API เดิม vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องใช้งาน Vulkan 1.1 API อย่างเต็มรูปแบบสำหรับแต่ละรายการที่ระบุไว้ VkPhysicalDevice
  • [C-1-4] ต้องระบุเลเยอร์ที่อยู่ในไลบรารีเนทีฟที่มีชื่อว่า libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน API เนทีฟของ Vulkan vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
  • [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่จัดหาโดยไลบรารีนอกแพ็กเกจแอปพลิเคชัน หรือระบุวิธีอื่นๆ ในการติดตามหรือขัดจังหวะ Vulkan API เว้นแต่แอปพลิเคชันจะตั้งค่าแอตทริบิวต์ android:debuggable เป็น true หรือตั้งค่าข้อมูลเมตา com.android.graphics.injectLayers.enable เป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน API เนทีฟของ Vulkan และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
  • [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
  • [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ Vulkan ที่รองรับผ่าน Flag ฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-9] ต้องรองรับเวอร์ชัน 132317953 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานใน Flag ฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-10] ต้องผ่านการทดสอบ dEQP ของ Vulkan ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132317953 กับเวอร์ชันที่ระบุไว้ใน Flag ฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-11] ต้องไม่แสดงรายการการรองรับส่วนขยาย VK_KHR_video_queue, VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย VK_KHR_driver_properties และ VK_GOOGLE_display_timing
  • [C-1-12] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_performance_query
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดที่ระบุไว้ในโปรไฟล์พื้นฐานของ Android ปี 2022
  • [C-SR-5] ขอแนะนำอย่างยิ่งให้รองรับ VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory และ VK_EXT_global_priority
  • [C-SR-6] ขอแนะนําอย่างยิ่งให้ใช้ SkiaVk กับ HWUI

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

  • [C-SR-8] ขอแนะนำอย่างยิ่งว่าอย่าแก้ไขตัวโหลด Vulkan
  • [C-1-14] ต้องไม่แจกแจงส่วนขยายอุปกรณ์ Vulkan ประเภท "KHR", "GOOGLE" หรือ "ANDROID" เว้นแต่ว่าส่วนขยายเหล่านี้จะรวมอยู่ในandroid.software.vulkan.deqp.level Flag ฟีเจอร์

สิ้นสุดข้อกำหนดใหม่

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

  • [C-SR-7] ขอแนะนำอย่างยิ่งให้ทำให้VK_KHR_external_fence_fdส่วนขยายพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม และเปิดใช้แอปพลิเคชันเพื่อส่งออกเพย์โหลดของรั้วและนำเข้าเพย์โหลดของรั้วจากตัวระบุไฟล์ POSIX ตามที่อธิบายไว้ที่นี่

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-1] ขอแนะนำอย่างยิ่งให้รองรับ GL_EXT_sRGB

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

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

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 เวอร์ชัน upstream มีกลไกการเลือกที่เหมาะสมสำหรับใช้กับอุปกรณ์ที่ไม่มีอินพุตการไปยังส่วนต่างๆ ที่ไม่ใช้การสัมผัส

7.2.3. ปุ่มนำทาง

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

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

หากมีฟังก์ชันหน้าแรก ล่าสุด หรือย้อนกลับ ฟังก์ชันเหล่านี้จะทําดังนี้

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

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

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

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุฟังก์ชันการไปยังส่วนต่างๆ ทั้งหมดให้ยกเลิกได้ "ยกเลิกได้" หมายถึงความสามารถของผู้ใช้ในการป้องกันการเรียกใช้ฟังก์ชันการไปยังส่วนต่างๆ (เช่น กลับไปยังหน้าแรก กลับ ฯลฯ) หากไม่ได้ปล่อยการปัดผ่านเกณฑ์ที่กำหนด

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

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

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

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

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

  • [C-4-1] ต้องทำให้เข้าถึงฟังก์ชัน Assist ได้ด้วยการดําเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงแป้นการนําทางอื่นๆ ได้
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้ใช้ฟังก์ชันการกดแป้น 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() seharusnya ไม่ได้รับผลกระทบจากสี่เหลี่ยมผืนผ้าการยกเว้นที่แอปพลิเคชันเบื้องหน้าระบุผ่านView#setSystemGestureExclusionRects()

หากมีฟังก์ชันการนำทางจากขอบด้านซ้ายและขวาของการวางแนวหน้าจอปัจจุบัน ให้ทำดังนี้

  • [C-7-1] ฟังก์ชันการนําทางต้องเป็น "กลับ" และระบุเป็นการปัดจากทั้งขอบด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
  • [C-7-2] หากมีแผงระบบที่ปัดได้ซึ่งกำหนดเองที่ขอบซ้ายหรือขวา แผงดังกล่าวต้องอยู่ใน 1/3 ด้านบนของหน้าจอพร้อมด้วยตัวบ่งชี้ที่ชัดเจนและแสดงอยู่ตลอดเวลาว่าการลากเข้าจะเป็นการเรียกแผงดังกล่าวขึ้นมา และไม่ใช่ปุ่มย้อนกลับ ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ด้านล่าง 1/3 ด้านบนของขอบหน้าจอ แต่แผงระบบต้องไม่ยาวเกิน 1/3 ของขอบ
  • [C-7-3] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่า Flag ใด Flag หนึ่งต่อไปนี้ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE การปัดจากขอบจะต้องทํางานตามที่ติดตั้งใช้งานใน AOSP ซึ่งมีเอกสารประกอบใน SDK
  • [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่า Flag ใด Flag หนึ่งต่อไปนี้ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE ระบบจะต้องซ่อนแผงระบบที่ปัดได้ที่กำหนดเองจนกว่าผู้ใช้จะแสดงหรือทำให้แถบระบบ (หรือที่เรียกว่าแถบนําทางและแถบสถานะ) สว่างขึ้นตามที่ติดตั้งใช้งานใน AOSP

หากมีฟังก์ชันการไปยังส่วนหลังและผู้ใช้ยกเลิกท่าทางสัมผัส "กลับ" ระบบจะทำดังนี้

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() ต้องเรียก
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() ต้องไม่เรียก
  • [C-8-3] ต้องไม่ส่งเหตุการณ์ KEYCODE_BACK

หากมีฟังก์ชันการนําทางกลับ แต่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าไม่ได้ลงทะเบียน OnBackInvokedCallback ไว้ ระบบจะดำเนินการดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์รองรับ API ของระบบ setNavBarMode เพื่ออนุญาตให้แอประบบที่มีสิทธิ์ android.permission.STATUS_BAR ตั้งค่าโหมดแถบนําทางได้ แอปดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-9-1] ต้องรองรับไอคอนที่เหมาะสำหรับเด็กหรือการไปยังส่วนต่างๆ โดยใช้ปุ่มตามที่ระบุไว้ในโค้ด AOSP

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

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

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

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

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

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

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

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

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

  • [C-3-1] ต้องไม่รายงาน Flag ฟีเจอร์ที่ขึ้นต้นด้วย android.hardware.touchscreen
  • [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
  • [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับช่อง API Configuration.touchscreen

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

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

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

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

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

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

  • [C-2-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.gamepad
ปุ่ม การใช้งาน 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)
กลับ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
  • [C-1-4] สําหรับ API ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์แบบต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยความผันผวนหมายถึงค่าความเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน
  • [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์ของเซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะ "หยุดชั่วคราว" หรือตื่นจากสถานะ "หยุดชั่วคราว"
  • [C-1-6] ต้องรายงานเวลาของเหตุการณ์เป็นนาโนวินาทีตามที่ระบุไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงถึงเวลาที่เกิดเหตุการณ์และซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
  • เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว ปริมาณการใช้พลังงานไม่ควรเกินยอดรวมของปริมาณการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

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

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

  • [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่าผ่านเมธอด Sensor.getResolution() API

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

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

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

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

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

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

  • [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สําหรับเซ็นเซอร์และรายงานค่าผ่านเมธอด Sensor.getResolution() API

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

  • [C-4-1] ต้องไม่มีพารามิเตอร์การสอบเทียบที่ตายตัวซึ่งกำหนดโดยโรงงานในข้อมูลที่ให้ไว้

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

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

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

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

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

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

  • [C-1-1] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามที่ระบุไว้ใน Android API
  • [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้สูงสุด 4 เท่าของ gravity(4g) ขึ้นไปบนแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ค่าเบี่ยงเบนมาตรฐานต้องไม่เกิน 0.05 m/s^ โดยค่าเบี่ยงเบนมาตรฐานควรคํานวณตามแกนแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราความถี่ในการสุ่มตัวอย่างที่เร็วที่สุด
  • ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
  • ควรมีความละเอียดอย่างน้อย 16 บิต
  • ควรได้รับการปรับเทียบขณะใช้งานหากลักษณะการทำงานมีการเปลี่ยนแปลงตลอดอายุการใช้งานและได้รับการชดเชย รวมถึงเก็บรักษาพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
  • ควรมีการชดเชยอุณหภูมิ

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

  • [C-2-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานTYPE_SIGNIFICANT_MOTION เซ็นเซอร์คอมโพสิต
  • [C-SR-5] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_UNCALIBRATED เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android มีคุณสมบัติตรงตามข้อกำหนดนี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นถัดไปได้ ซึ่งอาจจำเป็นต้องมีคุณสมบัติตรงตามข้อกำหนดนี้
  • ควรติดตั้งใช้งานเซ็นเซอร์แบบคอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK

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

  • [C-3-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_LIMITED_AXES
  • [C-SR-6] STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

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

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

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

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

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่มาตรความเข้มสนามแม่เหล็ก 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
  • [C-1-10] ต้องใช้เซ็นเซอร์ 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-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องรับ 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] ต้องติดตามและรายงานผ่านดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวหนึ่งๆ พร้อมกันผ่าน GnssStatus.Callback
    • ควรติดตามดาวเทียมได้อย่างน้อย 24 ดวงพร้อมกันจากกลุ่มดาวหลายกลุ่ม (เช่น GPS + Glonass, Beidou, Galileo อย่างใดอย่างหนึ่งอย่างน้อย 1 กลุ่ม)

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ปกติผ่าน API ของผู้ให้บริการตำแหน่ง GNSS ต่อไปในระหว่างการโทรฉุกเฉินทางโทรศัพท์

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS

  • [C-SR-4] ขอแนะนำอย่างยิ่งให้รายงาน AGC และความถี่ในการวัด GNSS

  • [C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานความแม่นยำโดยประมาณทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวตั้ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เซ็นเซอร์ไจโรสโคป

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

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

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

  • [C-2-1] ต้องติดตั้งเซ็นเซอร์ TYPE_GYROSCOPE
  • [C-SR-4] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED

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

  • [C-3-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_GYROSCOPE_LIMITED_AXES
  • [C-SR-5] STRONGLY_RECOMMENDED ให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์เทอร์โมมิเตอร์ที่วัดอุณหภูมิอื่นนอกเหนือจากอุณหภูมิแวดล้อม เช่น อุณหภูมิ CPU อุปกรณ์จะมีลักษณะดังนี้

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

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

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

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

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

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

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

7.3.9. เซ็นเซอร์ความแม่นยำสูง

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

  • [C-1-1] ต้องระบุความสามารถผ่านandroid.hardware.sensor.hifi_sensors Flag ฟีเจอร์

หากการติดตั้งใช้งานอุปกรณ์ประกาศ 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-1] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 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-2] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 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-3] ขอแนะนําอย่างยิ่งให้มีย่านความถี่ของสัญญาณรบกวนสีขาวตั้งแต่ 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. เซ็นเซอร์ไบโอเมตริก

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

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

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

เซ็นเซอร์ไบโอเมตริกสามารถแบ่งออกเป็น คลาส 3 (เดิมคือมีประสิทธิภาพสูง) คลาส 2 (เดิมคือมีประสิทธิภาพต่ำ) หรือคลาส 1 (เดิมคือสะดวก) โดยอิงตามอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่น และการรักษาความปลอดภัยของไปป์ไลน์ไบโอเมตริก การจัดประเภทนี้กำหนดความสามารถที่เซ็นเซอร์ไบโอเมตริกมีต่ออินเทอร์เฟซกับแพลตฟอร์มและแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์ต้องเป็นไปตามข้อกำหนดเพิ่มเติมตามที่ระบุไว้ด้านล่างหากต้องการจัดประเภทเป็นคลาส 1, คลาส 2 หรือคลาส 3 ทั้งข้อมูลไบโอเมตริกระดับ 2 และ 3 จะมีความสามารถเพิ่มเติมตามที่ระบุไว้ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์ทำให้เซ็นเซอร์ไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL แอปพลิเคชันเหล่านั้นจะต้องมีคุณสมบัติดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 ตามที่ระบุไว้ในเอกสารนี้
  • [C-4-2] ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็นค่าคงที่ในคลาส Authenticators และชุดค่าผสมต่างๆ ของชื่อเหล่านั้น ในทางกลับกัน ต้องไม่ยอมรับหรือรู้จักค่าคงที่แบบจำนวนเต็มซึ่งส่งไปยังเมธอด canAuthenticate(int) และ setAllowedAuthenticators(int) นอกเหนือจากค่าคงที่แบบสาธารณะที่ระบุไว้ใน Authenticators และชุดค่าผสมของค่าคงที่เหล่านั้น
  • [C-4-3] ต้องใช้งานการดำเนินการ ACTION_BIOMETRIC_ENROLL ในอุปกรณ์ที่มีข้อมูลไบโอเมตริกระดับ Class 3 หรือ Class 2 การดำเนินการนี้ต้องแสดงเฉพาะจุดแรกเข้าสำหรับการลงทะเบียนข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-4-4] ต้องอนุญาตให้แอปพลิเคชันเพิ่มเนื้อหาที่กำหนดเองลงใน BiometricPrompt ใช้รูปแบบการแสดงเนื้อหา PromptContentView รูปแบบการแสดงเนื้อหาต้องไม่ขยายให้อนุญาตภาพ ลิงก์ เนื้อหาแบบอินเทอร์แอกทีฟ หรือสื่อรูปแบบอื่นๆ ที่ไม่ได้เป็นส่วนหนึ่งของ BiometricPrompt API คุณสามารถปรับแต่งสไตล์ที่ไม่เปลี่ยนแปลง บดบัง หรือตัดเนื้อหานี้ (เช่น เปลี่ยนตำแหน่ง ระยะห่างจากขอบ ระยะขอบ และการจัดรูปแบบตัวอักษร)

สิ้นสุดข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่าการใช้ PIN, รูปแบบ หรือรหัสผ่านที่รัดกุม และระบุความเสี่ยงของการเปิดใช้อย่างชัดเจน หากอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสูงกว่า 7% โดยวัดจากโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-9] ต้องกำหนดให้ผู้ใช้ดำเนินการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ หรือรหัสผ่าน) หลังจากการพยายามที่ไม่สำเร็จไม่เกิน 20 ครั้งและเวลาพักอย่างน้อย 90 วินาทีสำหรับการยืนยันด้วยข้อมูลไบโอเมตริก โดยที่การพยายามที่ไม่สำเร็จคือการพยายามที่มีคุณภาพการจับภาพเพียงพอ (BIOMETRIC_ACQUIRED_GOOD) แต่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้ลดจำนวนการพยายามที่ไม่ถูกต้องทั้งหมดสำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุไว้ใน [C-1-9] หากอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสูงกว่า 7% ตามการวัดผลของโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-3] MUST rate limit attempts for biometric verification - where a false trial is one with an adequate capture quality (BIOMETRIC_ACQUIRED_GOOD) that does not match an enrolled biometric.
  • [C-SR-5] ขอแนะนำอย่างยิ่งให้จำกัดจำนวนครั้งที่พยายามเป็นอย่างน้อย 30 วินาทีหลังจากการพยายามที่ไม่สำเร็จ 5 ครั้งสำหรับการยืนยันข้อมูลไบโอเมตริกเพื่อกำหนดจำนวนครั้งที่พยายามที่ไม่สำเร็จสูงสุดต่อ [C-1-9] โดยที่การพยายามที่ไม่สำเร็จคือคุณภาพการจับภาพที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ที่ไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้มีตรรกะการจำกัดอัตราการส่งข้อมูลทั้งหมดใน TEE
  • [C-1-10] ต้องปิดใช้ข้อมูลไบโอเมตริกเมื่อการตรวจสอบสิทธิ์หลักเริ่มทํางานอีกครั้งเป็นครั้งแรกตามที่อธิบายไว้ใน [C-0-2] ของส่วนที่ 9.11
  • [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นไม่เกิน 30% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสำหรับประเภทเครื่องมือโจมตีด้วยการแสดงภาพ (PAI) ระดับ A ไม่เกิน 30% และ (2) อัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่นสำหรับประเภท PAI ระดับ B ไม่เกิน 40% โดยวัดตามโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-4] ต้องป้องกันไม่ให้เพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบใหม่ของอุปกรณ์ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การใช้งานโปรเจ็กต์โอเพนซอร์ส Android มีกลไกในเฟรมเวิร์กสำหรับดำเนินการดังกล่าว

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

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

สิ้นสุดข้อกำหนดใหม่

  • [C-SR-7] ขอแนะนำอย่างยิ่งให้ใช้ตรรกะในเฟรมเวิร์กจากโครงการโอเพนซอร์ส Android เพื่อบังคับใช้ข้อจำกัดที่ระบุไว้ใน [C-1-7] และ [C-1-8] สำหรับอุปกรณ์ใหม่
  • [C-SR-8] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% ตามการวัดในอุปกรณ์
  • [C-SR-9] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเวลาที่ตรวจพบข้อมูลไบโอเมตริกจนกว่าระบบจะปลดล็อกหน้าจอสำหรับข้อมูลไบโอเมตริกที่ลงทะเบียนแต่ละรายการ
  • [C-1-12] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวตนปลอมไม่เกิน 40%ต่อประเภทของเครื่องมือโจมตีด้วยการแสดงผล (PAI) ซึ่งวัดโดยโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-SR-13] ขอแนะนำอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและตัวปลอมไม่เกิน 30%ต่อประเภทของเครื่องมือโจมตีด้วยการแสดงผล (PAI) ซึ่งวัดโดยโปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-SR-8] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% โดยวัดจากอุปกรณ์

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-15] ต้องอนุญาตให้ผู้ใช้นำการลงทะเบียนข้อมูลไบโอเมตริกออกได้ทีละรายการหรือหลายรายการ

สิ้นสุดข้อกำหนดใหม่

  • [C-SR-14] ขอแนะนำอย่างยิ่งให้เปิดเผยคลาสไบโอเมตริกของเซ็นเซอร์ไบโอเมตริกและความเสี่ยงที่เกี่ยวข้องของการเปิดใช้

  • [C-SR-17] ขอแนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซ AIDL ใหม่ (เช่น IFace.aidl และ IFingerprint.aidl)

หากการติดตั้งใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ข้อมูลไบโอเมตริกเป็นระดับ 2 (ก่อนหน้านี้เรียกว่าอ่อน) อุปกรณ์จะต้องมีลักษณะดังนี้

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

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

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

  • [C-2-9] ต้องทำให้เซ็นเซอร์ข้อมูลไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม

หากการติดตั้งใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ข้อมูลไบโอเมตริกเป็นระดับ 3 (ก่อนหน้านี้เรียกว่ารัดกุม) อุปกรณ์จะต้องมีลักษณะดังนี้

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

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

  • [C-SR-11] ขอแนะนำอย่างยิ่งเพื่อป้องกันไม่ให้พื้นที่ที่สัมผัสได้ของ UDFPS รบกวนการไปยังส่วนต่างๆ ด้วยปุ่ม 3 ปุ่ม (ซึ่งผู้ใช้บางรายอาจต้องใช้เพื่อการช่วยเหลือพิเศษ)

7.3.11. เซ็นเซอร์ท่าทาง

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

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

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

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

7.3.12. เซ็นเซอร์มุมบานพับ

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

  • [C-1-1] ต้องติดตั้งใช้งานและรายงาน TYPE_HINGLE_ANGLE
  • [C-1-2] ต้องรองรับค่าที่อ่านได้อย่างน้อย 2 ค่าระหว่าง 0 ถึง 360 องศา (รวม 0 และ 360 องศา)
  • [C-1-3] ต้องแสดงเซ็นเซอร์การปลุกสำหรับ getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)

7.3.13. IEEE 802.1.15.4 (UWB)

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

  • [C-1-2] ต้องรายงาน Flag ฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
  • [C-1-3] ต้องรองรับชุดการกําหนดค่าต่อไปนี้ทั้งหมด (ชุดค่าผสมของพารามิเตอร์ FIRA UCI ที่กําหนดไว้ล่วงหน้า) ที่กําหนดไว้ในการใช้งาน AOSP
    • CONFIG_ID_1: STATIC STS DS-TWR การระบุช่วงแบบยูนิแคสต์ที่ FiRa กำหนด โหมดเลื่อนเวลา ช่วงเวลาการระบุช่วง 240 มิลลิวินาที
    • CONFIG_ID_2: STATIC STS DS-TWR การระบุตำแหน่งแบบ 1:หลายเครื่องที่ FiRa กำหนด โหมดเลื่อนเวลา ช่วงเวลาการระบุตำแหน่ง 200 มิลลิวินาที กรณีการใช้งานทั่วไป: สมาร์ทโฟนโต้ตอบกับอุปกรณ์อัจฉริยะหลายเครื่อง
    • CONFIG_ID_3: เหมือนกับ CONFIG_ID_1 ยกเว้นไม่มีการรายงานข้อมูลมุมมาถึง (AoA)
    • CONFIG_ID_4: เหมือนกับ CONFIG_ID_1 ยกเว้นเปิดใช้โหมดความปลอดภัย P-STS
    • CONFIG_ID_5: เหมือนกับ CONFIG_ID_2 ยกเว้นเปิดใช้โหมดความปลอดภัย P-STS
    • CONFIG_ID_6: เหมือนกับ CONFIG_ID_3 ยกเว้นเปิดใช้โหมดความปลอดภัย P-STS
    • CONFIG_ID_7: เหมือนกับ CONFIG_ID_2 ยกเว้นมีการเปิดใช้โหมดคีย์ของ P-STS ควบคุมบุคคล
  • [C-1-4] ต้องระบุสิ่งที่ผู้ใช้สามารถดำเนินการได้เพื่อให้ผู้ใช้เปิด/ปิดสถานะวิทยุ UWB ได้
  • [C-1-5] ต้องบังคับใช้ว่าแอปที่ใช้วิทยุ UWB ต้องมีสิทธิ์ UWB_RANGING (ในกลุ่มสิทธิ์ NEARBY_DEVICES)

การผ่านการทดสอบการปฏิบัติตามข้อกำหนดและการรับรองที่เกี่ยวข้องซึ่งกำหนดโดยองค์กรมาตรฐานต่างๆ เช่น FIRA, CCC และ CSA จะช่วยให้มั่นใจได้ว่า 802.1.15.4 จะทำงานได้อย่างถูกต้อง

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

7.4.1. โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS หรือการสร้างอินเทอร์เน็ตมือถือผ่านเครือข่ายมือถือ (เช่น GSM, CDMA, LTE, NR)GSM หรือ CDMA อุปกรณ์ที่รองรับ "โทรศัพท์" อาจเลือกให้บริการโทร การรับส่งข้อความ และอินเทอร์เน็ตบางส่วนหรือทั้งหมดตามที่เหมาะกับผลิตภัณฑ์

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

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

  • [C-1-1] ต้องประกาศandroid.hardware.telephony Flag ฟีเจอร์และ Flag ฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องรองรับ API ของเทคโนโลยีนั้นอย่างเต็มรูปแบบ
  • ควรอนุญาตบริการเครือข่ายมือถือทุกประเภทที่พร้อมใช้งาน (2G, 3G, 4G, 5G ฯลฯ) ระหว่างการโทรฉุกเฉิน (โดยไม่คำนึงถึงประเภทเครือข่ายที่SetAllowedNetworkTypeBitmap()กำหนด)

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ไม่ได้ตั้งค่าพร็อพเพอร์ตี้ระบบ ro.telephony.iwlan\_operation\_mode เป็น "เดิม" อุปกรณ์จะมีลักษณะดังนี้

หากการติดตั้งใช้งานอุปกรณ์รองรับการลงทะเบียน IP Multimedia Subsystem (IMS) รายการเดียวสำหรับทั้งฟีเจอร์บริการโทรศัพท์แบบมัลติมีเดีย (MMTEL) และ Rich Communication Services (RCS) และคาดว่าจะต้องปฏิบัติตามข้อกำหนดของผู้ให้บริการเครือข่ายมือถือเกี่ยวกับการใช้การลงทะเบียน IMS รายการเดียวสำหรับการรับส่งสัญญาณ IMS ทั้งหมด อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-5-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony.ims และระบุการใช้งาน ImsService API ที่สมบูรณ์สำหรับทั้ง MMTEL และ RCS User Capability Exchange API
  • [C-5-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony.ims.singlereg และระบุการใช้งาน SipTransport API, GbaService API, การกำหนดผู้ให้บริการเฉพาะโดยใช้ IRadio 1.6 HAL และการกําหนดค่าผ่านเซิร์ฟเวอร์การกําหนดค่าอัตโนมัติ (ACS) หรือกลไกการกําหนดค่าที่เป็นกรรมสิทธิ์อื่นๆ โดยใช้ IMS Configuration API ให้เสร็จสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony ให้ทำดังนี้

  • [C-6-1] SmsManager#sendTextMessage และ SmsManager#sendMultipartTextMessage ต้องทําให้เกิดการเรียกใช้ CarrierMessagingService ที่เกี่ยวข้องเพื่อให้บริการฟังก์ชันการรับส่งข้อความ SmsManager#sendMultimediaMessage และ SmsManager#downloadMultimediaMessage ต้องทําให้เกิดการเรียกใช้ CarrierMessagingService ที่เกี่ยวข้องเพื่อให้บริการฟังก์ชันการรับส่งข้อความมัลติมีเดีย
  • [C-6-2] แอปพลิเคชันที่ระบุโดย android.provider.Telephony.Sms#getDefaultSmsPackage ต้องใช้ API ของ SmsManager เมื่อส่งและรับข้อความ SMS และ MMS การใช้งานข้อมูลอ้างอิง AOSP ในแพ็กเกจ/แอป/การรับส่งข้อความเป็นไปตามข้อกำหนดนี้
  • [C-6-3] แอปพลิเคชันที่ตอบสนองต่อ Intent#ACTION_DIAL ต้องรองรับการป้อนรหัสโปรแกรมโทรออกที่กำหนดเองในรูปแบบ *#*#CODE#*#* และทริกเกอร์การออกอากาศ TelephonyManager#ACTION_SECRET_CODE ที่เกี่ยวข้อง
  • [C-6-4] แอปพลิเคชันที่ตอบสนองต่อ Intent#ACTION_DIAL ต้องใช้ VoicemailContract.Voicemails#TRANSCRIPTION เพื่อแสดงการถอดเสียงข้อความเสียงพร้อมภาพต่อผู้ใช้หากรองรับการถอดเสียงข้อความเสียงพร้อมภาพ
  • [C-6-5] ต้องแสดง SubscriptionInfo ทั้งหมดที่มี UUID ของกลุ่มที่เทียบเท่าเป็นการสมัครใช้บริการเดียวในองค์ประกอบที่ผู้ใช้มองเห็นทั้งหมดซึ่งแสดงและควบคุมข้อมูลซิมการ์ด ตัวอย่างของสิ่งกระตุ้นดังกล่าว ได้แก่ การตั้งค่า อินเทอร์เฟซที่ตรงกัน Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS หรือ EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
  • [C-6-6] ต้องไม่แสดงหรืออนุญาตให้ควบคุม SubscriptionInfo ที่มี group UUID ที่ไม่ใช่ค่า Null และ opportunistic bit ในการแสดงผลที่ผู้ใช้มองเห็นซึ่งอนุญาตให้กําหนดค่าหรือควบคุมการตั้งค่าของซิมการ์ด

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony และระบุแถบสถานะของระบบ ให้ทำดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony ให้ทำดังนี้

  • [C-6-7] ต้องสามารถเปิดและใช้ช่องเชิงตรรกะสูงสุด (รวม 20 ช่อง) พร้อมกันสำหรับ UICC แต่ละรายการตาม ETSI TS 102 221
  • [C-6-8] ต้องไม่ใช้ลักษณะการทำงานต่อไปนี้กับแอปของผู้ให้บริการที่ใช้งานอยู่ (ตามที่ระบุโดย TelephonyManager#getCarrierServicePackageName) โดยอัตโนมัติหรือโดยไม่ได้รับการยืนยันจากผู้ใช้อย่างชัดเจน
    • เพิกถอนหรือจํากัดการเข้าถึงเครือข่าย
    • เพิกถอนสิทธิ์
    • จำกัดการเรียกใช้แอปในเบื้องหลังหรือเบื้องหน้านอกเหนือจากฟีเจอร์การจัดการพลังงานที่มีอยู่ซึ่งรวมอยู่ใน AOSP
    • ปิดใช้หรือถอนการติดตั้งแอป

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

  • [C-8-1] ต้องปิดใช้การสมัครใช้บริการโอกาสที่ใช้งานอยู่ทั้งหมดที่เหลืออยู่ในกลุ่มเดียวกันโดยอัตโนมัติ

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

  • [C-9-1] ต้องไม่ประกาศ PackageManager#FEATURE_TELEPHONY_CDMA
  • [C-9-2] MUST throw an IllegalArgumentException upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks.
  • [C-9-3] ต้องแสดงผลสตริงว่างจาก TelephonyManager#getMeid

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

7.4.1.1. ความเข้ากันได้ของการบล็อกหมายเลข

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony.calling อุปกรณ์จะดำเนินการดังนี้

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

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

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

  • [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.calling อุปกรณ์จะมีลักษณะดังนี้

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

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

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

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

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้จัดการเหตุการณ์ KEYCODE_MEDIA_PLAY_PAUSE และ KEYCODE_HEADSETHOOK ของหูฟังแบบมีสายสำหรับ android.telecom API ดังต่อไปนี้

    • โทรหา Connection.onDisconnect() เมื่อตรวจพบการกดเหตุการณ์สำคัญสั้นๆ ในระหว่างการโทร
    • โทรหา Connection.onAnswer() เมื่อตรวจพบการกดเหตุการณ์สำคัญสั้นๆ ระหว่างสายเรียกเข้า
    • โทรหา Connection.onReject() เมื่อตรวจพบการกดเหตุการณ์สำคัญค้างไว้ระหว่างสายเรียกเข้า
    • สลับสถานะการปิดเสียงของ CallAudioState
7.4.1.3. การลดภาระ Keepalive ของ NAT-T บนเครือข่ายมือถือ

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

  • ควรรองรับการโอนข้อมูลการคงสถานะการเชื่อมต่อของเครือข่ายมือถือ

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

  • [C-1-1] ต้องรองรับ SocketKeepAlive API
  • [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ
  • [C-1-3] ต้องรองรับสล็อต Keepalive ของเครือข่ายมือถือพร้อมกันให้ได้มากที่สุดเท่าที่ HAL ของวิทยุมือถือรองรับ
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับช่อง keepalive ของเครือข่ายมือถืออย่างน้อย 3 ช่องต่ออินสแตนซ์วิทยุ

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

  • [C-2-1] MUST return ERROR_UNSUPPORTED.

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

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-4] ต้องรองรับมัลติแคสต์ DNS (mDNS) และห้ามกรองแพ็กเก็ต mDNS (224.0.0.251 หรือ ff02::fb) ไม่ว่าเมื่อใดก็ตามที่ทำงานอยู่ รวมถึงเมื่อหน้าจอไม่ได้อยู่ในสถานะทำงาน เว้นแต่การทิ้งหรือกรองแพ็กเก็ตเหล่านี้เป็นสิ่งจําเป็นเพื่อให้อยู่ในช่วงการบริโภคพลังงานตามที่ข้อกําหนดของหน่วยงานกํากับดูแลที่เกี่ยวข้องกับตลาดเป้าหมายกําหนด

  • [C-1-4] ต้องรองรับ mDNS และห้ามกรองแพ็กเก็ต mDNS (224.0.0.251 หรือ ff02::fb) ในทุกช่วงเวลาของการทำงาน รวมถึงเมื่อหน้าจอไม่ได้อยู่ในสถานะทำงาน เว้นแต่ว่าไม่ได้ล็อกมัลติแคสต์ไว้และ APF กรองแพ็กเก็ต โดยไม่จำเป็นต้องตอบสนองการดำเนินการ mDNS ที่แอปพลิเคชันขอผ่าน NsdManager API ในปัจจุบัน อย่างไรก็ตาม อุปกรณ์อาจกรองแพ็กเก็ต mDNS หากจำเป็นเพื่อให้อยู่ในช่วงการสิ้นเปลืองพลังงานตามข้อกำหนดด้านกฎระเบียบที่มีผลกับตลาดเป้าหมาย

สิ้นสุดข้อกำหนดใหม่

  • [C-1-5] ต้องไม่ถือว่าการเรียกใช้เมธอด WifiManager.enableNetwork() API เป็นข้อบ่งชี้ที่เพียงพอในการเปลี่ยน Network ที่ใช้งานอยู่ในปัจจุบัน ซึ่งระบบจะใช้โดยค่าเริ่มต้นสําหรับการเข้าชมแอปพลิเคชันและแสดงผลโดยเมธอด ConnectivityManager API เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ ผู้ให้บริการอาจปิดใช้การเข้าถึงอินเทอร์เน็ตที่ให้บริการโดยผู้ให้บริการเครือข่ายรายอื่น (เช่น อินเทอร์เน็ตมือถือ) ก็ต่อเมื่อตรวจสอบแล้วว่าเครือข่าย Wi-Fi ให้บริการอินเทอร์เน็ตได้
  • [C-1-6] ขอแนะนำอย่างยิ่งว่าเมื่อเรียกใช้เมธอด ConnectivityManager.reportNetworkConnectivity() ของ API ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และเมื่อการประเมินระบุว่า Network ปัจจุบันไม่มีบริการอินเทอร์เน็ตอีกต่อไป ให้เปลี่ยนไปใช้เครือข่ายอื่นที่พร้อมใช้งาน (เช่น อินเทอร์เน็ตมือถือ) ซึ่งให้บริการอินเทอร์เน็ต
  • [C-1-7] ต้องสุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอการสำรวจ 1 ครั้งในช่วงเริ่มต้นการสแกนแต่ละครั้งขณะที่ STA ไม่ได้เชื่อมต่อ
  • [C-1-8] ต้องใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในช่วงกลางการสแกน)
  • [C-1-9] MUST iterate probe request sequence number as normal (sequentially) between the probe requests in a scan.
  • [C-1-10] ต้องสุ่มหมายเลขลำดับคำขอการสำรวจระหว่างคำขอการสำรวจสุดท้ายของการสแกนกับคำขอการสำรวจแรกของการสแกนถัดไป
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางที่ใช้สำหรับการสื่อสาร STA ทั้งหมดกับจุดเข้าใช้งาน (AP) ขณะเชื่อมโยงและเชื่อมโยง
    • อุปกรณ์ต้องใช้ที่อยู่ MAC แบบสุ่มที่แตกต่างกันสำหรับ SSID (FQDN สำหรับ Passpoint) แต่ละรายการที่สื่อสารด้วย
    • อุปกรณ์ต้องให้ตัวเลือกแก่ผู้ใช้ในการควบคุมการสุ่มตาม SSID (FQDN สำหรับ Passpoint) ด้วยตัวเลือกแบบไม่สุ่มและสุ่ม และจะต้องตั้งค่าโหมดเริ่มต้นสำหรับการกำหนดค่า Wi-Fi ใหม่เป็นแบบสุ่ม
  • [C-SR-2] ขอแนะนําอย่างยิ่งให้ใช้ BSSID แบบสุ่มสําหรับ AP ที่สร้างขึ้น
    • ที่อยู่ MAC ต้องเป็นแบบสุ่มและคงที่ตาม SSID ที่ AP ใช้
    • อุปกรณ์อาจให้ตัวเลือกแก่ผู้ใช้ในการปิดใช้ฟีเจอร์นี้ หากมีตัวเลือกดังกล่าว จะต้องเปิดใช้การสุ่มตัวอย่างโดยค่าเริ่มต้น

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

  • ควรปิดโหมดประหยัดพลังงานของ Wi-Fi เมื่อใดก็ตามที่แอปได้รับWIFI_MODE_FULL_HIGH_PERFล็อกหรือWIFI_MODE_FULL_LOW_LATENCYล็อกผ่าน WifiManager.createWifiLock() และ WifiManager.WifiLock.acquire() API และล็อกทำงานอยู่
  • [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-3] ขอแนะนําอย่างยิ่งให้ลดเวลาในการตอบสนองไป-กลับของ 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 พร้อมกัน
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางสำหรับการเชื่อมต่อ 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 เว้นแต่จะมีการดำเนินการจัดเรียง Aware อยู่หรือเส้นทางข้อมูล Aware ทำงานอยู่ (ไม่คาดว่าจะมีการสุ่มตราบใดที่เส้นทางข้อมูลทำงานอยู่)

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

7.4.2.4. Wi-Fi Passpoint

หากการติดตั้งใช้งานอุปกรณ์รองรับ 802.11 (Wi-Fi) อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับ Wi-Fi Passpoint
  • [C-1-2] ต้องใช้ WifiManager API ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นหาและการเลือกเครือข่าย เช่น Generic Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)
  • [C-1-4] ต้องประกาศ Flag ฟีเจอร์ android.hardware.wifi.passpoint
  • [C-1-5] ต้องเป็นไปตามการใช้งาน AOSP เพื่อค้นหา จับคู่ และเชื่อมโยงกับเครือข่าย Passpoint
  • [C-1-6] ต้องรองรับโปรโตคอลการจัดสรรอุปกรณ์ชุดย่อยต่อไปนี้เป็นอย่างน้อยตามที่ระบุไว้ใน Wi-Fi Alliance Passpoint R2 ได้แก่ การตรวจสอบสิทธิ์ EAP-TTLS และ SOAP-XML
  • [C-1-7] ต้องประมวลผลใบรับรองเซิร์ฟเวอร์ AAA ตามที่อธิบายไว้ในข้อกําหนดของ Hotspot 2.0 R3
  • [C-1-8] ต้องรองรับการควบคุมการจัดสรรของผู้ใช้ผ่านเครื่องมือเลือก Wi-Fi
  • [C-1-9] ต้องเก็บการกำหนดค่า Passpoint ไว้ตลอดการรีบูต
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับฟีเจอร์การยอมรับข้อกำหนดและเงื่อนไข
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับฟีเจอร์ข้อมูลสถานที่

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

  • [C-3-1] ต้องเปิดใช้ Passpoint โดยค่าเริ่มต้น
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 ไม่ได้เชื่อมโยงกับจุดเข้าใช้งาน
  • [C-1-4] ต้องมีความแม่นยำไม่เกิน 2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นต์ไทล์ที่ 68 (คำนวณด้วยฟังก์ชันการแจกแจงแบบสะสม)
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รายงานอย่างถูกต้องภายใน 1.5 เมตร ที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ 68 (คำนวณด้วยฟังก์ชันการแจกแจงแบบสะสม)
7.4.2.6. การลดภาระ Keepalive ของ Wi-Fi

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

  • ควรรองรับการโอนข้อมูล Keepalive ของ Wi-Fi

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

  • [C-1-1] ต้องรองรับ SocketKeepAlive API
  • [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi

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

7.4.2.7. Wi-Fi Easy Connect (Device Provisioning Protocol)

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

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

7.4.2.8. การตรวจสอบใบรับรองเซิร์ฟเวอร์ Wi-Fi ขององค์กร

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

7.4.2.9. Trust On First Use (TOFU)

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อถือในการใช้งานครั้งแรก (TOFU) และอนุญาตให้ผู้ใช้กำหนดค่า WPA/WPA2/WPA3-Enterprise ผู้ใช้จะทำสิ่งต่อไปนี้ได้

  • [C-4-1] ต้องให้ตัวเลือกแก่ผู้ใช้ในการเลือกใช้ TOFU

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 ฯลฯ ตามเหมาะสมกับอุปกรณ์

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

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

  • [C-3-5] ต้องกำหนดเวลาหมดอายุของที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) ไม่เกิน 15 นาที และเปลี่ยนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์ใช้ BLE อยู่เพื่อสแกนหรือโฆษณา และต้องสุ่มช่วงเวลาหมดเวลาระหว่าง 5 ถึง 15 นาทีเพื่อป้องกันการโจมตีตามเวลา

  • ควรรองรับการโอนตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API

  • ควรรองรับการโอนการสแกนแบบเป็นกลุ่มไปยังชิปเซ็ตบลูทูธ

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สําหรับ BluetoothAdapter.isLeAudioSupported() API แสดงว่าอุปกรณ์มีลักษณะดังนี้

  • [C-7-1] ต้องรองรับไคลเอ็นต์แบบยูนิแคสต์
  • [C-7-2] ต้องรองรับ PHY 2M
  • [C-7-3] ต้องรองรับโฆษณาแบบขยายของ LE
  • [C-7-4] ต้องรองรับการเชื่อมต่อ CIS อย่างน้อย 2 รายการใน CIG
  • [C-7-5] ต้องเปิดใช้ไคลเอ็นต์ BAP แบบยูนิแคสต์ ผู้ประสานงานชุด CSIP เซิร์ฟเวอร์ MCP ตัวควบคุม VCP เซิร์ฟเวอร์ CCP พร้อมกัน
  • [C-SR-1] ขอแนะนําอย่างยิ่งให้เปิดใช้ไคลเอ็นต์ HAP แบบยูนิแคสต์

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สําหรับ BluetoothAdapter.isLeAudioBroadcastSourceSupported() API แสดงว่าอุปกรณ์มีลักษณะดังนี้

  • [C-8-1] ต้องรองรับลิงก์ BIS อย่างน้อย 2 รายการใน BIG
  • [C-8-2] ต้องเปิดใช้แหล่งที่มาของการออกอากาศ BAP และตัวช่วยการออกอากาศ BAP พร้อมกัน
  • [C-8-3] ต้องรองรับการโฆษณาเป็นระยะของ LE

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สําหรับ BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API แสดงว่าอุปกรณ์มีลักษณะดังนี้

  • [C-9-1] ต้องรองรับ PAST (Periodic Advertising Sync Transfer)
  • [C-9-2] ต้องรองรับการโฆษณาเป็นระยะของ LE

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

  • [C-10-1] การวัด RSSI ต้องอยู่ในช่วง +/-9dB สำหรับ 95% ของการวัดที่ระยะ 1 เมตรจากอุปกรณ์อ้างอิงที่ส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH ในสภาพแวดล้อมที่โล่ง
  • [C-10-2] ต้องมีการปรับแก้ Rx/Tx เพื่อลดความคลาดเคลื่อนของแต่ละช่องเพื่อให้การวัดในแต่ละช่อง 3 ช่องบนเสาอากาศแต่ละตัว (หากใช้หลายตัว) อยู่ในช่วง +/-3dB ของกันและกันสำหรับการวัด 95%
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้วัดและชดเชยค่าออฟเซ็ต Rx เพื่อให้ค่ามัธยฐานของ BLE RSSI เป็น -60dBm +/-10 dB ที่ระยะ 1 เมตรจากอุปกรณ์อ้างอิงที่ส่งที่ ADVERTISE_TX_POWER_HIGH โดยที่อุปกรณ์อยู่ใน "ระนาบคู่ขนาน" โดยที่หน้าจอหันไปในทิศทางเดียวกัน
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้วัดและชดเชยค่าออฟเซ็ตของ Tx เพื่อให้ค่ามัธยฐานของ BLE RSSI เป็น -60dBm +/-10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในระยะ 1 เมตรและส่งที่ ADVERTISE_TX_POWER_HIGH โดยอุปกรณ์อยู่ในแนวที่อยู่บน "ระนาบคู่ขนาน" โดยมีหน้าจอหันไปในทิศทางเดียวกัน

เราขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการปรับเทียบการปรากฏ

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)

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

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

  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอที่ใช้งานอยู่และหน้าจอล็อกที่ปลดล็อก

  • ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC แบบฟิล์มบางได้

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

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

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

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

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

  • [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hcef
  • [C-3-2] ต้องใช้ 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. โปรโตคอลและ API ของเครือข่าย

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

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

  • [C-0-1] ต้องรองรับรูปแบบเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, อีเทอร์เน็ต และ PAN ของบลูทูธ
  • ควรรองรับมาตรฐานการรับส่งข้อมูลไร้สายทั่วไปอย่างน้อย 1 รายการ เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
  • อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
7.4.5.2. IPv6

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

  • [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API เดิม เช่น AF_INET6 socket
  • [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 และพอร์ตที่ใช้จริงเพื่อส่งและรับแพ็กเก็ตในเครือข่าย และแสดงเป็น IP และพอร์ตต้นทางไปยังเซิร์ฟเวอร์อินเทอร์เน็ต (เว็บ)

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

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

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

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

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

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

  • [C-3-1] ต้องรองรับการใช้งาน IPv6 (IPv6 เท่านั้นและอาจรองรับแบบ Dual-Stack) บนเครือข่ายมือถือ

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

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

แคพทีฟพอร์ทัลหมายถึงเครือข่ายที่ต้องลงชื่อเข้าใช้เพื่อรับสิทธิ์เข้าถึงอินเทอร์เน็ต

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

  • [C-1-1] ต้องจัดหาแอปพลิเคชันพอร์ทัลที่กำหนดให้ผู้ใช้ต้องลงชื่อเข้าใช้เพื่อจัดการ Intent ACTION_CAPTIVE_PORTAL_SIGN_IN และแสดงหน้าการเข้าสู่ระบบของพอร์ทัลที่กำหนดให้ผู้ใช้ต้องลงชื่อเข้าใช้ โดยส่ง Intent นั้นใน CallType ไปยัง System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
  • [C-1-2] ต้องทำการค้นหาพอร์ทัลแคปทีฟและรองรับการเข้าสู่ระบบผ่านแอปพลิเคชันพอร์ทัลแคปทีฟเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายประเภทใดก็ได้ ซึ่งรวมถึงเครือข่ายมือถือ/เครือข่ายเคลื่อนที่, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
  • [C-1-3] ต้องรองรับการเข้าสู่ระบบพอร์ทัลที่กำหนดให้ใช้ DNS แบบข้อความธรรมดาเมื่ออุปกรณ์ได้รับการกำหนดค่าให้ใช้โหมด DNS ส่วนตัวแบบเข้มงวด
  • [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสารประกอบของ SDK สำหรับ android.net.LinkProperties.getPrivateDnsServerName และ android.net.LinkProperties.isPrivateDnsActive สำหรับการรับส่งข้อมูลทั้งหมดในเครือข่ายที่ไม่ได้สื่อสารกับพอร์ทัลแคปทีฟอย่างชัดเจน
  • [C-1-5] ต้องตรวจสอบว่าขณะที่ผู้ใช้เข้าสู่ระบบพอร์ทัลที่กำหนดให้ใช้เครือข่าย เครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่แสดงโดย ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback และใช้โดย API เครือข่าย Java โดยค่าเริ่มต้น เช่น java.net.Socket และ API เดิม เช่น connect()) คือเครือข่ายอื่นที่พร้อมใช้งานซึ่งให้สิทธิ์เข้าถึงอินเทอร์เน็ต (หากมี)

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

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

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

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

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

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

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

  • [C-1-1] ต้องรองรับ API ทั้งหมดในคลาส ConnectivityManager ตามที่ได้อธิบายไว้ในเอกสารประกอบ SDK

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

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

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

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

  • [C-1-2] ต้องประกาศ Flag ฟีเจอร์ที่ถูกต้องผ่าน android.hardware.se.omapi.uicc สำหรับอุปกรณ์ที่มีองค์ประกอบที่ปลอดภัยซึ่งอิงตาม UICC android.hardware.se.omapi.ese สำหรับอุปกรณ์ที่มีองค์ประกอบที่ปลอดภัยซึ่งอิงตาม eSE และ android.hardware.se.omapi.sd สำหรับอุปกรณ์ที่มีองค์ประกอบที่ปลอดภัยซึ่งอิงตาม SD

7.4.9. UWB

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

  • [C-1-1] ต้องติดตั้งใช้งาน Android API ที่เกี่ยวข้องใน android.uwb
  • [C-1-2] ต้องรายงาน Flag ฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
  • [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่ระบุไว้ในการใช้งาน Android
  • [C-1-4] ต้องระบุสิ่งที่ผู้ใช้สามารถดำเนินการได้เพื่อให้ผู้ใช้เปิด/ปิดสถานะวิทยุ UWB ได้
  • [C-1-5] ต้องบังคับใช้ว่าแอปที่ใช้วิทยุ UWB ต้องมีสิทธิ์ UWB_RANGING (อยู่ในกลุ่มสิทธิ์ NEARBY_DEVICES)
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ผ่านการทดสอบการปฏิบัติตามข้อกำหนดและการรับรองที่เกี่ยวข้องซึ่งกำหนดโดยองค์กรมาตรฐานต่างๆ ซึ่งรวมถึง FIRA, CCC และ CSA
  • [C-1-6] ต้องตรวจสอบว่าการวัดระยะทางอยู่ในช่วง +/-15 ซม. สำหรับการวัด 95% ในสภาพแวดล้อมที่มองเห็นได้ในระยะ 1 เมตรในห้องที่ไม่สะท้อนแสง
  • [C-1-7] ต้องตรวจสอบว่าค่ามัธยฐานของการวัดระยะทางที่ 1 เมตรจากอุปกรณ์อ้างอิงอยู่ภายใน [0.75 ม., 1.25 ม.] โดยวัดระยะทางจากขอบด้านบนของ DUT
  • [C-SR-2] ขอแนะนําอย่างยิ่งให้ทําตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในข้อกําหนดในการสอบเทียบการปรากฏ

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

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

  • [C-2-1] ต้องรองรับโปรไฟล์ HDR ของ HLG เป็นอย่างน้อยสำหรับอุปกรณ์กล้องทุกรุ่นที่รองรับเอาต์พุต 10 บิต
  • [C-2-2] ต้องรองรับเอาต์พุต 10 บิตสำหรับกล้องหลังหลักหรือกล้องหน้าหลัก
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอาต์พุต 10 บิตสำหรับกล้องหลักทั้ง 2 ตัว
  • [C-2-3] ต้องรองรับโปรไฟล์ HDR เดียวกันสำหรับกล้องย่อยจริงทั้งหมดที่พร้อมใช้งาน BACKWARD_COMPATIBLE ของกล้องเชิงตรรกะ และกล้องเชิงตรรกะเอง

สำหรับอุปกรณ์กล้องแบบตรรกะที่รองรับ HDR 10 บิตซึ่งใช้ android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API อุปกรณ์เหล่านี้จะมีลักษณะดังนี้

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

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. กล้องภายนอก

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

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

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

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

  • [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 รายการสําหรับเข้าถึงกล้อง โดย API เวอร์ชันใหม่อย่าง android.hardware.camera2 จะแสดงการควบคุมกล้องในระดับล่างให้กับแอป ซึ่งรวมถึงโฟลว์การถ่ายแบบต่อเนื่อง/สตรีมมิงแบบไม่คัดลอกข้อมูล (Zero-Copy) ที่มีประสิทธิภาพ และการควบคุมระดับเฟรมของการรับแสง อัตราขยาย อัตราขยายของการปรับสมดุลสีขาว การเปลี่ยนสี การตัดเสียงรบกวน การเพิ่มความคมชัด และอื่นๆ

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

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

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

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ส่งไปยังการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียก android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องเป็นรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบพรีวิวคือ YCbCr_420_SP ข้อมูลใน 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] MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.
  • [C-0-10] ต้องออกอากาศCamera.ACTION_NEW_VIDEO intent ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ
  • [C-0-11] กล้องทั้งหมดต้องเข้าถึงได้ผ่าน android.hardware.Camera API ที่เลิกใช้งานแล้ว และเข้าถึงได้ผ่าน android.hardware.camera2 API ด้วย
  • [C-0-12] ต้องไม่เปลี่ยนแปลงลักษณะใบหน้า ซึ่งรวมถึงแต่ไม่จำกัดเพียงการเปลี่ยนแปลงรูปทรงเรขาคณิตของใบหน้า สีผิวของใบหน้า หรือการทำให้ผิวหน้าเรียบเนียนสำหรับ android.hardware.camera2 หรือ android.hardware.Camera API
  • [C-SR-1] สำหรับอุปกรณ์ที่มีกล้อง 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] ต้องกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งติดตั้งโดยค่าเริ่มต้น กล่าวคือ "พร้อมใช้งานทันที" ไม่ว่าจะติดตั้งพื้นที่เก็บข้อมูลในคอมโพเนนต์พื้นที่เก็บข้อมูลภายในหรือสื่อเก็บข้อมูลแบบถอดออกได้ (เช่น ช่องการ์ดดิจิทัลที่ปลอดภัย)
  • [C-0-3] ต้องต่อเชื่อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันโดยตรงในเส้นทาง Linux sdcard หรือใส่ลิงก์สัญลักษณ์ Linux จาก sdcard ไปยังจุดต่อเชื่อมจริง
  • [C-0-4] ต้องเปิดใช้พื้นที่เก็บข้อมูลแบบจำกัดโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กำหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในกรณีต่อไปนี้
    • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
  • [C-0-5] ต้องปกปิดข้อมูลเมตาตำแหน่ง เช่น แท็ก GPS Exif ที่เก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore ยกเว้นในกรณีที่แอปที่เรียกใช้มีสิทธิ์ ACCESS_MEDIA_LOCATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.7. USB

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

  • ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB
  • ควรรองรับการปิดใช้การส่งสัญญาณข้อมูลผ่าน USB

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

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

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

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

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้พอร์ตเสียงอย่างน้อย 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-2] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลําดับการต่อพินของ OMTP
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากหูฟังสเตอริโอที่มีไมโครโฟน

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

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

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วนที่ 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 "การทดสอบข้อบกพร่องอัตโนมัติ"

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

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

โหมดประสิทธิภาพ การแชร์ อัตราการสุ่มตัวอย่างเอาต์พุต ใน 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) สำหรับไซน์ 2,000 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_EXT_protected_textures, และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งาน GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งาน VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image และแสดงในรายการส่วนขยาย Vulkan ที่พร้อมใช้งาน
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้แสดงครอบครัวคิว 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-5] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีเลเยอร์มากกว่า 1 เลเยอร์ รวมถึง Flag และรูปแบบที่ระบุไว้ใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30 fps ซึ่งบีบอัดเป็น 40 Mbps โดยเฉลี่ย (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 fps-10 Mbps หรือ 2 อินสแตนซ์ของ 1920 x 1080 ที่ 60 fps-20 Mbps)
  • [C-1-12] ต้องรองรับ HEVC และ VP9, ต้องสามารถถอดรหัสได้อย่างน้อย 1920 x 1080 ที่ 30 fps ซึ่งบีบอัดเป็น 10 Mbps โดยเฉลี่ย และควรสามารถถอดรหัส 3840 x 2160 ที่ 30 fps-20 Mbps (เทียบเท่ากับ 1920 x 1080 4 อินสแตนซ์ที่ 30 fps-5 Mbps)
  • [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าอุณหภูมิผิวหนังที่ถูกต้อง
  • [C-1-14] ต้องมีหน้าจอแบบฝังและความละเอียดต้องไม่ต่ำกว่า 1920 x 1080
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้ใช้ความละเอียดของจอแสดงผลอย่างน้อย 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-7] ขอแนะนําอย่างยิ่งให้รองรับประเภทแชแนลTYPE_HARDWARE_BUFFERโดยตรงสําหรับประเภทแชแนลโดยตรงทั้งหมดที่ระบุไว้ข้างต้น
  • [C-1-21] ต้องเป็นไปตามข้อกำหนดเกี่ยวกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors ตามที่ระบุไว้ในส่วนที่ 7.3.9
  • [C-SR-8] ขอแนะนำอย่างยิ่งให้รองรับฟีเจอร์ android.hardware.sensor.hifi_sensors
  • [C-1-22] ต้องมีเวลาในการตอบสนองจากการเคลื่อนไหวไปยังโฟตอนจากต้นทางถึงปลายทางไม่เกิน 28 มิลลิวินาที
  • [C-SR-9] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองตั้งแต่ต้นจนจบของการเคลื่อนไหวไปยังโฟตอนไม่เกิน 20 มิลลิวินาที
  • [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดําเป็นสีขาวกับความสว่างของพิกเซลสีขาวในสถานะคงที่อย่างน้อย 85%
  • [C-SR-10] ขอแนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
  • อาจจัดสรรแกนประมวลผลสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าโดยเฉพาะ และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนแกนประมวลผลที่ใช้สำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าโดยเฉพาะ

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

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

7.10. การโต้ตอบการสัมผัส

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

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

  • [7.10/C] MUST return false for Vibrator.hasVibrator().

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

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

7.11. คลาสประสิทธิภาพสื่อ

คุณดูคลาสประสิทธิภาพสื่อของการติดตั้งใช้งานอุปกรณ์ได้จาก android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API มีการกําหนดข้อกําหนดสำหรับคลาสประสิทธิภาพสื่อสำหรับ Android แต่ละเวอร์ชันที่เริ่มต้นด้วย R (เวอร์ชัน 30) ค่าพิเศษ 0 ระบุว่าอุปกรณ์ไม่ได้อยู่ในคลาสประสิทธิภาพสื่อ

หากการติดตั้งใช้งานอุปกรณ์แสดงผลค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องแสดงผลค่าเป็นอย่างน้อย android.os.Build.VERSION_CODES.R

  • [C-1-2] ต้องเป็นการติดตั้งใช้งานในอุปกรณ์พกพา

  • [C-1-3] ต้องปฏิบัติตามข้อกำหนดทั้งหมดสำหรับ "คลาสประสิทธิภาพสื่อ" ที่อธิบายไว้ในส่วนที่ 2.2.7

กล่าวคือ คลาสประสิทธิภาพสื่อใน Android T จะกำหนดไว้สำหรับอุปกรณ์มือถือในเวอร์ชัน T, S หรือ R เท่านั้น

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

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 (เช่น App Standby Bucket, โหมด Doze) หรือขยายฟีเจอร์เพื่อใช้ข้อจำกัดที่เข้มงวดกว่าApp Standby Bucket แบบจํากัด อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับทริกเกอร์ การบำรุงรักษา อัลกอริทึมการปลุก และการใช้การตั้งค่าระบบส่วนกลางหรือ DeviceConfig ของโหมดประหยัดพลังงาน "แอปรอดำเนินการ" และ "โหมดสลีป"
  • [C-1-2] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางหรือ DeviceConfig เพื่อจัดการการจำกัดงาน การแจ้งเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสําหรับโหมดรอของแอป
  • [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวนกลุ่ม App Standby ที่ใช้สำหรับ App Standby
  • [C-1-4] ต้องติดตั้งใช้งานกลุ่มแอปสแตนด์บายและโหมดสลีปตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] MUST return true for PowerManager.isPowerSaveMode() when the device is on power save mode.
  • [C-1-6] ต้องให้ทางเลือกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานของโหมด "รอดำเนินการ" ของแอปและโหมด "Doze" หรือการเพิ่มประสิทธิภาพแบตเตอรี่ และต้องใช้ Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS เพื่อขอให้ผู้ใช้อนุญาตให้แอปละเว้นการเพิ่มประสิทธิภาพแบตเตอรี่
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้เปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้แสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานของโหมดแอปรอและโหมดสลีป

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ใช้สถานะพลังงาน S3 ตามที่ ACPI กำหนดไว้ อุปกรณ์จะมีลักษณะดังนี้

  • [C-2-1] ต้องเป็นไปตาม C-1-1 ข้างต้น หรือต้องเข้าสู่สถานะ S3 เฉพาะในกรณีที่แอปพลิเคชันของบุคคลที่สามไม่ต้องการทรัพยากรของระบบ (เช่น หน้าจอ, CPU)

    ในทางกลับกัน จะต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องใช้ทรัพยากรของระบบตามที่อธิบายไว้ใน SDK นี้

    ตัวอย่างเช่น ขณะที่แอปพลิเคชันของบุคคลที่สามส่งคำขอเปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือทำให้ CPU ทำงานต่อไปผ่าน PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่เข้าสู่สถานะ S3 เว้นแต่ผู้ใช้จะดำเนินการอย่างชัดแจ้งเพื่อทำให้อุปกรณ์อยู่ในสถานะ "ไม่ทำงาน" ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน เมื่อทริกเกอร์งานที่แอปของบุคคลที่สามติดตั้งใช้งานผ่าน JobScheduler หรือส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์ต้องออกจากสถานะ S3 เว้นแต่ว่าผู้ใช้จะตั้งค่าอุปกรณ์ให้อยู่ในสถานะไม่ทำงาน ตัวอย่างเหล่านี้เป็นเพียงตัวอย่างบางส่วนเท่านั้น และ AOSP ใช้สัญญาณการปลุกที่ครอบคลุมซึ่งทริกเกอร์การปลุกจากสถานะนี้

8.4 การบัญชีการใช้พลังงาน

การบัญชีและการรายงานการสิ้นเปลืองพลังงานที่แม่นยำยิ่งขึ้นจะช่วยให้นักพัฒนาแอปมีแรงจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อองค์ประกอบ ซึ่งจะกำหนดค่าการบริโภคปัจจุบันสำหรับองค์ประกอบฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากองค์ประกอบเมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
  • [C-SR-2] ขอแนะนําอย่างยิ่งให้รายงานค่าการบริโภคพลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
  • [C-SR-3] ขอแนะนําอย่างยิ่งให้รายงานการสิ้นเปลืองพลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการติดตั้งใช้งานuid_cputimeโมดูลเคอร์เนล
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้นักพัฒนาแอปสามารถเข้าถึงการใช้พลังงานนี้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats ได้
  • ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชันได้

8.5 ประสิทธิภาพที่สม่ำเสมอ

ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่ทำงานอย่างต่อเนื่องและมีประสิทธิภาพสูง ไม่ว่าจะเกิดจากแอปอื่นๆ ที่ทำงานอยู่เบื้องหลังหรือการจำกัดซีพียูเนื่องจากขีดจำกัดอุณหภูมิ 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] ต้องรายงานหมายเลขรหัสของคอร์แบบไม่แชร์ซึ่งแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับบนสุดสามารถจองได้ผ่านเมธอด API ของ Process.getExclusiveCores()
  • [C-2-2] ต้องไม่อนุญาตให้มีกระบวนการใดๆ ใน User Space ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อทำงานบนแกนที่ไม่ซ้ำกัน แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางรายการทำงานได้ตามความจำเป็น

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับแกนเอกสิทธิ์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องแสดงผลรายการว่างผ่านเมธอด Process.getExclusiveCores() ของ API

9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องติดตั้งใช้งานรูปแบบการรักษาความปลอดภัยที่สอดคล้องกับรูปแบบการรักษาความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารประกอบสำหรับนักพัฒนาแอป Android

  • [C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงาน

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.security.model.compatible อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับข้อกำหนดที่ระบุไว้ในหัวข้อย่อยต่อไปนี้

9.1. สิทธิ์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับรูปแบบสิทธิ์ของ Android และรูปแบบบทบาทของ Android ตามที่ระบุไว้ในเอกสารประกอบสำหรับนักพัฒนาแอป Android กล่าวโดยละเอียดคือ ผู้ให้บริการต้องบังคับใช้สิทธิ์และบทบาทแต่ละรายการตามที่อธิบายไว้ในเอกสารประกอบ SDK โดยต้องไม่ละเว้น เปลี่ยนแปลง หรือละเลยสิทธิ์และบทบาทใดๆ

  • อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel ของ PROTECTION_FLAG_PRIVILEGED ต้องได้รับอนุญาตให้แอปที่ติดตั้งไว้ล่วงหน้าในเส้นทางที่มีสิทธิ์ของภาพระบบ (รวมถึงไฟล์ APEX) เท่านั้น และอยู่ภายในชุดย่อยของสิทธิ์ในรายการที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและปฏิบัติตามสิทธิ์ในรายการที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่มีสิทธิ์

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-SR-1] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_SIGNATURE ขอแนะนำอย่างยิ่งว่าให้มอบสิทธิ์นี้แก่บุคคลใดบุคคลหนึ่งต่อไปนี้เท่านั้น

    • แอปที่ติดตั้งไว้ล่วงหน้าในอิมเมจระบบ (รวมถึงไฟล์ APEX)
    • แอปในรายการที่อนุญาตซึ่งมีสิทธิ์ที่อนุญาตหากไม่ได้รวมอยู่ในภาพระบบ

สิ้นสุดข้อกำหนดใหม่

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion มากกว่า 22 จะขอสิทธิ์เหล่านั้นเมื่อรันไทม์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ รวมถึงต้องมีอินเทอร์เฟซสำหรับให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย

  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอป เว้นแต่ในกรณีต่อไปนี้

    • มีการติดฟิล์มป้องกันรอยขีดข่วนไว้ให้ ณ เวลาที่จัดส่งอุปกรณ์ และ

    • ขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้สิทธิ์

      หรือ

    • สิทธิ์รันไทม์จะได้รับการอนุญาตจากนโยบายการให้สิทธิ์เริ่มต้นหรือจากการมีบทบาทแพลตฟอร์ม

  • [C-0-6] ต้องให้สิทธิ์ android.permission.RECOVER_KEYSTORE แก่แอประบบที่ลงทะเบียน Recovery Agent ที่ปลอดภัยอย่างเหมาะสมเท่านั้น ตัวแทนการกู้คืนที่ปลอดภัยอย่างเหมาะสมหมายถึงตัวแทนซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่มีการรักษาความปลอดภัยเทียบเท่าหรือดีกว่าที่อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีด้วยวิธี Brute Force กับปัจจัยความรู้ในหน้าจอล็อก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องเป็นไปตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android เมื่อแอปขอข้อมูลตำแหน่งหรือข้อมูลการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้

    • ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด) ตามที่อธิบายไว้ในส่วนที่ 9.8.8
    • ข้อมูลที่สามารถใช้เพื่อระบุหรือประมาณตำแหน่งของอุปกรณ์ (เช่น SSID, BSSID, รหัสเครือข่ายมือถือ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
    • กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจำแนกกิจกรรมการเคลื่อนไหวร่างกาย

กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-0-8] ต้องขอความยินยอมจากผู้ใช้ในการอนุญาตให้แอปเข้าถึงข้อมูลตําแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
  • [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มีสิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น เช่น TelephonyManager#getServiceStateต้องใช้ android.permission.ACCESS_FINE_LOCATION)

ข้อยกเว้นเพียงอย่างเดียวสำหรับพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android ข้างต้นคือแอปที่ไม่ได้เข้าถึงตำแหน่งเพื่อดึงข้อมูลหรือระบุตำแหน่งของผู้ใช้ โดยเฉพาะอย่างยิ่งแอปต่อไปนี้

  • เมื่อแอปมีสิทธิ์ RADIO_SCAN_WITHOUT_LOCATION
  • เพื่อวัตถุประสงค์ในการกำหนดค่าและการตั้งค่าอุปกรณ์ เมื่อแอประบบมีสิทธิ์ NETWORK_SETTINGS หรือ NETWORK_SETUP_WIZARD

คุณสามารถทําเครื่องหมายสิทธิ์เป็น "ถูกจํากัด" เพื่อเปลี่ยนลักษณะการทํางานของสิทธิ์ได้

  • [C-0-10] สิทธิ์ที่มีเครื่องหมาย hardRestricted ต้องไม่ให้สิทธิ์แก่แอป เว้นแต่ในกรณีต่อไปนี้

    • ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
    • ผู้ใช้กำหนดบทบาทที่เชื่อมโยงกับสิทธิ์ hardRestricted ให้กับแอป
    • โปรแกรมติดตั้งจะมอบ hardRestricted ให้กับแอป
    • แอปได้รับ hardRestricted ใน Android เวอร์ชันเก่า

  • [C-0-11] แอปที่มีสิทธิ์ softRestricted ต้องมีสิทธิ์เข้าถึงแบบจํากัดเท่านั้น และจะต้องไม่ได้รับสิทธิ์เข้าถึงแบบเต็มจนกว่าจะอยู่ในรายการที่อนุญาตตามที่อธิบายไว้ใน SDK ซึ่งมีการกําหนดสิทธิ์เข้าถึงแบบเต็มและแบบจํากัดสําหรับสิทธิ์ softRestricted แต่ละรายการ (เช่น READ_EXTERNAL_STORAGE)

  • [C-0-12] ต้องไม่ระบุฟังก์ชันหรือ API ที่กําหนดเองเพื่อเลี่ยงข้อจํากัดสิทธิ์ที่กําหนดไว้ใน setPermissionPolicy และ setPermissionGrantState API

  • [C-0-13] ต้องใช้ AppOpsManager API เพื่อบันทึกและติดตามการเข้าถึงข้อมูลที่ได้รับการปกป้องโดยสิทธิ์ที่เป็นอันตรายจากกิจกรรมและบริการ Android ทุกครั้ง

  • [C-0-14] ต้องมอบหมายบทบาทให้กับแอปพลิเคชันที่มีฟังก์ชันการทำงานที่เป็นไปตามข้อกำหนดของบทบาทเท่านั้น

  • [C-0-15] ต้องไม่กำหนดบทบาทที่ซ้ำกันหรือมีฟังก์ชันการทำงานที่รวมอยู่ในบทบาทที่แพลตฟอร์มกำหนด

หากอุปกรณ์รายงาน android.software.managed_users อุปกรณ์จะดำเนินการดังนี้

  • [C-1-1] ต้องไม่มีสิทธิ์ต่อไปนี้ซึ่งผู้ดูแลระบบให้โดยไม่ได้แจ้งให้ทราบ
    • ตําแหน่ง (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
    • กล้อง (CAMERA)
    • ไมโครโฟน (RECORD_AUDIO)
    • เซ็นเซอร์ร่างกาย (BODY_SENSORS)
    • กิจกรรมการเคลื่อนไหวร่างกาย (ACTIVITY_RECOGNITION)

หากการติดตั้งใช้งานอุปกรณ์ช่วยให้ผู้ใช้เลือกได้ว่าแอปใดสามารถวาดทับแอปอื่นๆ ด้วยกิจกรรมที่จัดการACTION_MANAGE_OVERLAY_PERMISSION Intent ได้ อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง Intent สำหรับ Intent ACTION_MANAGE_OVERLAY_PERMISSION มีหน้าจอ UI เดียวกัน ไม่ว่าแอปที่เริ่มต้นหรือข้อมูลใดๆ ที่แอปให้ไว้

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องแสดงข้อจำกัดความรับผิดระหว่างการตั้งค่าอุปกรณ์ที่มีการจัดการอย่างเต็มรูปแบบ (การตั้งค่าเจ้าของอุปกรณ์) โดยระบุว่าผู้ดูแลระบบไอทีจะมีสิทธิ์อนุญาตให้แอปควบคุมการตั้งค่าในโทรศัพท์ ซึ่งรวมถึงไมโครโฟน กล้อง และตำแหน่ง โดยมีตัวเลือกให้ผู้ใช้ตั้งค่าต่อหรือออกจากการตั้งค่า เว้นแต่ผู้ดูแลระบบจะเลือกไม่ควบคุมสิทธิ์ในอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์ได้ติดตั้งแพ็กเกจที่มีบทบาทSystem UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence หรือ System Visual Intelligence ไว้ล่วงหน้า แพ็กเกจจะมีลักษณะดังนี้

  • [C-4-1] ต้องปฏิบัติตามข้อกําหนดทั้งหมดที่ระบุไว้สําหรับการติดตั้งใช้งานอุปกรณ์ในส่วน "9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลรอบตัว และ 9.8.15 การติดตั้งใช้งาน API ในแซนด์บ็อกซ์"

หากการติดตั้งใช้งานอุปกรณ์มีแอปพลิเคชันเริ่มต้นที่รองรับ VoiceInteractionService อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-5-1] ต้องไม่ให้สิทธิ์ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสําหรับแอปพลิเคชันนั้น

9.2. UID และการแยกกระบวนการ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับรูปแบบแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแอปพลิเคชันแต่ละรายการจะทำงานเป็น UID รูปแบบ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก
  • [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการโดยใช้รหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงนามและสร้างอย่างถูกต้องตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3. สิทธิ์ในระบบไฟล์

การติดตั้งใช้งานอุปกรณ์

9.4. สภาพแวดล้อมการดําเนินการอื่น

การติดตั้งใช้งานอุปกรณ์ต้องรักษาความสอดคล้องของรูปแบบความปลอดภัยและสิทธิ์ของ Android แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นที่ไม่ใช่รูปแบบไฟล์ Dalvik Executable หรือโค้ดเนทีฟก็ตาม กล่าวคือ

  • [C-0-1] รันไทม์อื่นต้องเป็นแอปพลิเคชัน Android และเป็นไปตามรูปแบบการรักษาความปลอดภัยมาตรฐานของ Android ตามที่อธิบายไว้ในส่วนส่วนที่ 9

  • [C-0-2] รันไทม์สำรองต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

  • [C-0-3] รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากฟีเจอร์ที่ได้รับการคุ้มครองโดยสิทธิ์ของ Android ซึ่งจํากัดไว้สําหรับแอปพลิเคชันระบบเท่านั้น

  • [C-0-4] รันไทม์อื่นต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์อื่นต้องไม่นําแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่านกลไกมาตรฐานของ Android สําหรับรหัสผู้ใช้และใบรับรองการรับรองที่ใช้ร่วมกัน

  • [C-0-5] รันไทม์อื่นต้องไม่เปิดขึ้นด้วย มอบสิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] รันไทม์อื่นต้องไม่เปิดใช้งาน ไม่ได้รับสิทธิ์ หรือให้สิทธิ์แอปพลิเคชันอื่นๆ เกี่ยวกับสิทธิ์ของผู้ใช้ระดับซูเปอร์ (รูท) หรือรหัสผู้ใช้อื่นๆ

  • [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์อื่นไว้ในอิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ ไฟล์ดังกล่าวต้องได้รับการเซ็นชื่อด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้เซ็นชื่อแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการนําอุปกรณ์ไปใช้งาน

  • [C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์อื่นต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ Android ที่แอปพลิเคชันใช้

  • [C-0-9] เมื่อแอปพลิเคชันต้องใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้

  • [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่ได้บันทึกความสามารถของแอปพลิเคชันด้วยวิธีนี้ สภาพแวดล้อมรันไทม์ต้องแสดงสิทธิ์ทั้งหมดที่รันไทม์มีเมื่อติดตั้งแอปพลิเคชันที่ใช้รันไทม์นั้น

  • รันไทม์อื่นควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

  • รันไทม์อื่นอาจให้บริการแซนด์บ็อกซ์ Android เดียวที่แอปพลิเคชันทั้งหมดที่ใช้รันไทม์อื่นใช้ร่วมกัน

9.5 การรองรับผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคน รวมถึงรองรับการแยกผู้ใช้โดยสมบูรณ์และการโคลนโปรไฟล์ผู้ใช้ด้วยการแยกบางส่วน(เช่น โปรไฟล์ผู้ใช้เพิ่มเติมประเภทเดียวที่เป็นandroid.os.usertype.profile.CLONE)

  • การติดตั้งใช้งานอุปกรณ์อาจเปิดใช้ผู้ใช้หลายคนได้ แต่ไม่ควรเปิดใช้หากผู้ใช้ใช้สื่อแบบถอดออกได้สำหรับพื้นที่เก็บข้อมูลภายนอกหลัก

หากการติดตั้งใช้งานอุปกรณ์รองรับผู้ใช้หลายคน ผู้ใช้จะทำสิ่งต่อไปนี้ได้

  • [C-1-2] ต้องใช้รูปแบบความปลอดภัยที่สอดคล้องกับรูปแบบความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API สำหรับผู้ใช้แต่ละราย
  • [C-1-3] ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกันแยกต่างหากและแยกส่วน (หรือที่เรียกว่า /sdcard) สำหรับอินสแตนซ์ผู้ใช้แต่ละรายการ
  • [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่ผู้ใช้รายหนึ่งเป็นเจ้าของและทำงานในนามของผู้ใช้รายนั้นไม่สามารถแสดงรายการ อ่าน หรือเขียนลงในไฟล์ที่ผู้ใช้รายอื่นเป็นเจ้าของ แม้ว่าข้อมูลของผู้ใช้ทั้ง 2 รายจะจัดเก็บไว้ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
  • [C-1-5] ต้องเข้ารหัสเนื้อหาของการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อแบบถอดไม่ได้เท่านั้นที่ระบบเข้าถึงได้ หากการติดตั้งใช้งานอุปกรณ์ใช้สื่อแบบถอดได้สำหรับ API ของพื้นที่เก็บข้อมูลภายนอก เนื่องจากพีซีโฮสต์จะอ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จึงต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

หากการติดตั้งใช้งานอุปกรณ์รองรับผู้ใช้หลายคน ผู้ใช้ทุกคนยกเว้นผู้ใช้ที่สร้างมาเพื่อเรียกใช้อินสแตนซ์คู่ของแอปเดียวกันโดยเฉพาะจะทำสิ่งต่อไปนี้ได้

  • [C-2-1] ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกันแยกต่างหากและแยกส่วน (หรือที่เรียกว่า /sdcard) สำหรับอินสแตนซ์ผู้ใช้แต่ละรายการ
  • [C-2-2] ต้องตรวจสอบว่าแอปพลิเคชันที่ผู้ใช้รายหนึ่งเป็นเจ้าของและทำงานในนามของผู้ใช้รายดังกล่าวไม่สามารถแสดงรายการ อ่าน หรือเขียนลงในไฟล์ที่ผู้ใช้รายอื่นเป็นเจ้าของ แม้ว่าข้อมูลของผู้ใช้ทั้ง 2 รายจะจัดเก็บไว้ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม

การติดตั้งใช้งานอุปกรณ์อาจสร้างโปรไฟล์ผู้ใช้เพิ่มเติมประเภท android.os.usertype.profile.CLONE รายการเดียวสำหรับผู้ใช้หลัก (และสำหรับผู้ใช้หลักเท่านั้น) เพื่อวัตถุประสงค์ในการเรียกใช้อินสแตนซ์คู่ของแอปเดียวกัน อินสแตนซ์คู่เหล่านี้ใช้พื้นที่เก็บข้อมูลแบบแยกบางส่วนร่วมกัน แสดงต่อผู้ใช้ปลายทางใน Launcher พร้อมกัน และปรากฏในมุมมองรายการล่าสุดเดียวกัน เช่น สามารถใช้เพื่อรองรับผู้ใช้ที่ติดตั้งอินสแตนซ์แยกกัน 2 รายการของแอปเดียวในอุปกรณ์แบบ 2 ซิม

หากการติดตั้งใช้งานอุปกรณ์สร้างโปรไฟล์ผู้ใช้เพิ่มเติมตามที่ได้กล่าวไว้ข้างต้น โปรไฟล์ดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลหรือข้อมูลที่โปรไฟล์ผู้ใช้หลักเข้าถึงอยู่แล้ว หรือโปรไฟล์ผู้ใช้เพิ่มเติมนี้เป็นเจ้าของโดยตรง
  • [C-3-2] ต้องไม่มีโปรไฟล์งานเป็นโปรไฟล์นี้
  • [C-3-3] ต้องมีไดเรกทอรีข้อมูลแอปส่วนตัวที่แยกจากบัญชีผู้ใช้หลัก
  • [C-3-4] ต้องไม่อนุญาตให้สร้างโปรไฟล์ผู้ใช้เพิ่มเติมหากมีการกำหนดค่าเจ้าของอุปกรณ์ไว้แล้ว (ดูส่วนที่ 3.9.1) หรืออนุญาตให้กำหนดค่าเจ้าของอุปกรณ์โดยไม่นำโปรไฟล์ผู้ใช้เพิ่มเติมออกก่อน

หากการติดตั้งใช้งานอุปกรณ์สร้างโปรไฟล์ผู้ใช้เพิ่มเติมตามที่ได้กล่าวไว้ข้างต้น โปรไฟล์ดังกล่าวจะมีลักษณะดังนี้

  • [C-4-1] ต้องอนุญาตให้แอปพลิเคชันของผู้ใช้หลักในอุปกรณ์จัดการ Intent ด้านล่างซึ่งมาจากโปรไฟล์เพิ่มเติม

    • Intent.ACTION_VIEW
    • Intent.ACTION_SENDTO
    • Intent.ACTION_SEND
    • Intent.ACTION_EDIT
    • Intent.ACTION_INSERT
    • Intent.ACTION_INSERT_OR_EDIT
    • Intent.ACTION_SEND_MULTIPLE
    • Intent.ACTION_PICK
    • Intent.ACTION_GET_CONTENT
    • MediaStore.ACTION_IMAGE_CAPTURE
    • MediaStore.ACTION_VIDEO_CAPTURE

  • [C-4-2] ต้องรับค่าข้อจำกัดของผู้ใช้นโยบายอุปกรณ์ทั้งหมดและ restrictions(list below) ที่ไม่ใช่ผู้ใช้ซึ่งเลือกไว้ซึ่งมีผลกับผู้ใช้หลักของอุปกรณ์ในโปรไฟล์ผู้ใช้เพิ่มเติมนี้

  • [C-4-3] ต้องอนุญาตให้เขียนรายชื่อติดต่อจากโปรไฟล์เพิ่มเติมนี้ผ่าน Intent ต่อไปนี้เท่านั้น

  • [C-4-4] ต้องไม่มีซิงค์รายชื่อติดต่อที่ทำงานอยู่สําหรับแอปพลิเคชันที่ทํางานในโปรไฟล์ผู้ใช้เพิ่มเติมนี้

  • [C-4-5] ต้องอนุญาตให้เฉพาะแอปพลิเคชันในโปรไฟล์เพิ่มเติมที่มีกิจกรรมตัวเปิดแอปเข้าถึงรายชื่อติดต่อที่โปรไฟล์ผู้ใช้หลักเข้าถึงได้อยู่แล้ว

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)

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนลซึ่งเขียนขึ้นในระหว่างการเริ่มต้นเท่านั้น โดยทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจากการเริ่มต้น (เช่น __ro_after_init)

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และหลีกเลี่ยงการแสดงข้อมูลที่อาจทำให้การสุ่มข้อมูลไม่ปลอดภัย (เช่น CONFIG_RANDOMIZE_BASE ที่มีข้อมูลความผันผวนของ Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

  • [C-SR-3] ขอแนะนําอย่างยิ่งให้เปิดใช้การควบคุมความสมบูรณ์ของโฟลว์ (CFI) ในเคอร์เนลเพื่อเพิ่มการป้องกันการโจมตีด้วยการใช้โค้ดซ้ำ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

  • [C-SR-4] ขอแนะนำอย่างยิ่งว่าอย่าปิดใช้ Control-Flow Integrity (CFI), Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) ในคอมโพเนนต์ที่เปิดใช้

  • [C-SR-5] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์เพิ่มเติมใน Userspace ที่มีความละเอียดอ่อนด้านความปลอดภัยตามที่อธิบายไว้ใน CFI และ IntSan

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้สแปร์มตัวแปรภายในที่ไม่ได้เริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรใช้ค่าที่คอมไพเลอร์ใช้เพื่อเริ่มต้นตัวแปรภายใน

  • [C-SR-7] ขอแนะนำอย่างยิ่งให้เปิดใช้การจัดเตรียมฮีปในเคอร์เนลเพื่อป้องกันการใช้การจัดสรรฮีปที่ไม่ได้เริ่มต้น (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) และไม่ควรใช้ค่าที่เคอร์เนลใช้เพื่อเริ่มต้นการจัดสรรเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนล Linux ที่รองรับ SELinux อุปกรณ์จะมีลักษณะดังนี้

  • [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 ต้นทาง และเพิ่มนโยบายนี้สำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux หรือ Linux ที่ไม่มี SELinux ระบบจะดำเนินการดังนี้

  • [C-2-1] ต้องใช้ระบบการควบคุมการเข้าถึงแบบบังคับที่เทียบเท่ากับ SELinux

หากการติดตั้งใช้งานอุปกรณ์ใช้อุปกรณ์ I/O ที่ทํา DMA ได้ อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-SR-9] ขอแนะนําอย่างยิ่งให้แยกอุปกรณ์ I/O แต่ละเครื่องที่ทํา DMA ได้โดยใช้ IOMMU (เช่น ARM SMMU)

Android มีฟีเจอร์การป้องกันแบบหลายชั้นหลายรายการที่เป็นส่วนสำคัญของการรักษาความปลอดภัยของอุปกรณ์ นอกจากนี้ Android ยังมุ่งเน้นที่การลดจำนวนข้อบกพร่องทั่วไปที่สำคัญซึ่งส่งผลให้คุณภาพและความปลอดภัยต่ำ

การติดตั้งใช้งานอุปกรณ์ควรทำดังนี้เพื่อลดข้อบกพร่องเกี่ยวกับหน่วยความจำ

  • [C-SR-10] ขอแนะนำอย่างยิ่งให้ทดสอบโดยใช้เครื่องมือตรวจหาข้อผิดพลาดของหน่วยความจำในพื้นที่ผู้ใช้ เช่น MTE สำหรับอุปกรณ์ ARMv9, HWASan สำหรับอุปกรณ์ ARMv8+ หรือ ASan สำหรับอุปกรณ์ประเภทอื่นๆ
  • [C-SR-11] ขอแนะนำอย่างยิ่งให้ทดสอบโดยใช้เครื่องมือตรวจหาข้อผิดพลาดของหน่วยความจำเคอร์เนล เช่น KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS สำหรับอุปกรณ์ ARMv9, CONFIG_KASAN_SW_TAGS สำหรับอุปกรณ์ ARMv8 หรือ CONFIG_KASAN_GENERIC สำหรับอุปกรณ์ประเภทอื่นๆ)
  • [C-SR-12] ขอแนะนําอย่างยิ่งให้ใช้เครื่องมือตรวจหาข้อผิดพลาดด้านหน่วยความจําในระบบจริง เช่น MTE, GWP-ASan และ KFENCE

หากการติดตั้งใช้งานอุปกรณ์ใช้ TEE ที่อิงตาม Arm TrustZone อุปกรณ์จะมีลักษณะดังนี้

  • [C-SR-13] ขอแนะนําอย่างยิ่งให้ใช้โปรโตคอลมาตรฐานสำหรับการแชร์หน่วยความจําระหว่าง Android กับ TEE เช่น Arm Firmware Framework สําหรับ Armv8-A (FF-A)
  • [C-SR-14] ขอแนะนำอย่างยิ่งให้จํากัดแอปพลิเคชันที่เชื่อถือได้ให้เข้าถึงได้เฉพาะหน่วยความจําที่แชร์กับแอปพลิเคชันดังกล่าวอย่างชัดเจนผ่านโปรโตคอลข้างต้น หากอุปกรณ์รองรับระดับข้อยกเว้น S-EL2 ของ Arm ผู้จัดการพาร์ติชันที่ปลอดภัยควรบังคับใช้ระดับนี้ มิเช่นนั้น ระบบปฏิบัติการ TEE ควรบังคับใช้

เทคโนโลยีความปลอดภัยของหน่วยความจำเป็นเทคโนโลยีที่ช่วยลดข้อบกพร่องอย่างน้อย 2 ประเภทต่อไปนี้ที่มีความน่าจะเป็นสูง (> 90%) ในแอปพลิเคชันที่ใช้ตัวเลือกไฟล์ Manifest android:memtagMode

  • การล้นบัฟเฟอร์ฮีป
  • ใช้งานหลังจากช่วงทดลองใช้ฟรี
  • มีการเรียกใช้หน่วยความจำซ้ำ
  • หน่วยความจำที่ปล่อยโดยอิสระ (ไม่มีพอยน์เตอร์ที่ไม่ใช่ malloc)

การติดตั้งใช้งานอุปกรณ์

  • [C-SR-15] ขอแนะนําอย่างยิ่งให้ตั้งค่า ro.arm64.memtag.bootctl_supported

หากการติดตั้งใช้งานอุปกรณ์ตั้งค่าพร็อพเพอร์ตี้ระบบ ro.arm64.memtag.bootctl_supported เป็น "จริง" อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-3-1] ต้องอนุญาตให้พร็อพเพอร์ตี้ระบบ arm64.memtag.bootctl ยอมรับรายการค่าต่อไปนี้ที่คั่นด้วยคอมมา โดยมีผลตามที่คาดหวังเมื่อรีบูตครั้งถัดไป

    • memtag: เปิดใช้เทคโนโลยีความปลอดภัยของหน่วยความจำตามที่ระบุไว้ข้างต้น
    • memtag-once: เทคโนโลยีความปลอดภัยของหน่วยความจำตามที่ระบุไว้ข้างต้นเปิดใช้ชั่วคราว และจะปิดใช้โดยอัตโนมัติเมื่อรีบูตครั้งถัดไป
    • memtag-off: เทคโนโลยีความปลอดภัยของหน่วยความจําตามที่ระบุไว้ข้างต้นถูกปิดใช้

  • [C-3-2] ต้องอนุญาตให้ผู้ใช้เชลล์ตั้งค่า arm64.memtag.bootctl

  • [C-3-3] ต้องอนุญาตให้กระบวนการใดก็ตามอ่าน arm64.memtag.bootctl

  • [C-3-4] ต้องตั้งค่า arm64.memtag.bootctl เป็นสถานะที่ขอในปัจจุบัน เมื่อบูต จะต้องอัปเดตพร็อพเพอร์ตี้ด้วย หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แก้ไขสถานะได้โดยไม่ต้องเปลี่ยนพร็อพเพอร์ตี้ของระบบ

  • [C-SR-16] ขอแนะนำอย่างยิ่งให้แสดงการตั้งค่าสำหรับนักพัฒนาซอฟต์แวร์ที่ตั้งค่า memtag-once แล้วรีบูตอุปกรณ์ เมื่อใช้โปรแกรมบูตที่เข้ากันได้ โปรเจ็กต์โอเพนซอร์สของ Android จะเป็นไปตามข้อกำหนดข้างต้นผ่านโปรโตคอลโปรแกรมบูต MTE

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากอุปกรณ์ประกาศ android.hardware.telephony รองรับความสามารถของวิทยุ CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK และมีโมเด็มมือถือที่รองรับการเชื่อมต่อ 2G การใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-SR-17] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้ปิดและเปิดใช้ 2G

  • [C-SR-18] ขอแนะนำอย่างยิ่งว่าอย่าลบล้างความสามารถของผู้ใช้ในการปิดและเปิดใช้ 2G ผ่านเอนทิตีอุปกรณ์อื่นๆ ยกเว้นผู้ดูแลระบบอุปกรณ์ที่ใช้ UserManager.DISALLOW_CELLULAR_2G

  • [C-SR-19] ขอแนะนำอย่างยิ่งให้โทรไปที่ TelephonyManager.setAllowedNetworkTypesForReason พร้อมเหตุผล ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G เพื่อให้เป็นไปตามข้อกำหนดนี้

  • [C-SR-20] ขอแนะนำอย่างยิ่งให้ตรวจสอบการรองรับโมเด็มเซลลูลาร์สำหรับ 2G โดยโทรไปที่ TelephonyManager.getSupportedRadioAccessFamily ดูรายละเอียดได้ที่หัวข้อปิดใช้ 2G

สิ้นสุดข้อกำหนดใหม่

9.8 ความเป็นส่วนตัว

9.8.1 ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีระยะเวลาการเก็บรักษาประวัติผู้ใช้ดังกล่าวอย่างสมเหตุสมผล
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้เก็บรักษาระยะเวลา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการติดตั้งใช้งาน AOSP

Android จัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ IncidentManager System API

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องใส่เฉพาะช่องที่มีเครื่องหมาย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร StatsLog SDK หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม ระบบอาจใช้ตัวระบุ Atom อื่นในช่วง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่โหลดล่วงหน้าหรือจัดจำหน่ายคอมโพเนนต์ซอฟต์แวร์แบบสำเร็จรูปที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้หรือการแจ้งเตือนอย่างต่อเนื่องที่ชัดเจน

  • [C-0-2] ต้องแสดงคำเตือนผู้ใช้และขอความยินยอมจากผู้ใช้อย่างชัดเจนเพื่ออนุญาตให้บันทึกข้อมูลที่ละเอียดอ่อนซึ่งแสดงบนหน้าจอของผู้ใช้ทุกครั้งที่เริ่มเซสชันเพื่อบันทึกหน้าจอผ่าน MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay() หรือ API ที่เป็นกรรมสิทธิ์

  • [C-0-3] ต้องมีการแจ้งเตือนอย่างต่อเนื่องไปยังผู้ใช้ขณะเปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอ AOSP เป็นไปตามข้อกำหนดนี้ด้วยการแสดงไอคอนการแจ้งเตือนอย่างต่อเนื่องในแถบสถานะ

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงคำเตือนผู้ใช้ซึ่งเป็นข้อความเดียวกับที่ใช้ใน AOSP แต่สามารถแก้ไขได้ ตราบใดที่ข้อความดังกล่าวเตือนผู้ใช้อย่างชัดเจนว่าระบบจะบันทึกข้อมูลที่ละเอียดอ่อนบนหน้าจอของผู้ใช้

  • [C-0-4] ต้องไม่อนุญาตให้ผู้ใช้ปิดใช้ข้อความแจ้งในอนาคตเกี่ยวกับการขอความยินยอมจากผู้ใช้ในการจับภาพหน้าจอ เว้นแต่เซสชันจะเริ่มต้นโดยแอประบบที่ผู้ใช้อนุญาตให้associate()ใช้android.app.role.COMPANION_DEVICE_APP_STREAMINGหรือโปรไฟล์android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGของอุปกรณ์

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องไม่บันทึก ฉาย หรือแคสต์ข้อมูลที่ละเอียดอ่อน เช่น

สิ้นสุดข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่จับภาพเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์ผ่านที่อื่นนอกเหนือจาก System API ContentCaptureService หรือวิธีที่เป็นกรรมสิทธิ์อื่นๆ ที่อธิบายไว้ในส่วนที่ 9.8.6 ข้อมูลระดับระบบและข้อมูลรอบข้าง การดำเนินการต่อไปนี้จะไม่สามารถทำได้

  • [C-1-1] ต้องมีการแจ้งเตือนอย่างต่อเนื่องไปยังผู้ใช้ทุกครั้งที่เปิดใช้ฟังก์ชันการทำงานนี้และกำลังจับภาพ/บันทึกอยู่

หากการติดตั้งใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ทันที ซึ่งสามารถบันทึกเสียงรอบข้างและ/หรือบันทึกเสียงที่เล่นในอุปกรณ์เพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องไม่จัดเก็บเสียงดิบที่บันทึกไว้หรือรูปแบบใดๆ ที่แปลงกลับเป็นเสียงต้นฉบับหรือใกล้เคียงกับต้นฉบับไว้ในที่จัดเก็บข้อมูลในอุปกรณ์แบบถาวรหรือส่งออกจากอุปกรณ์ เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดเจน

"ตัวบ่งชี้ไมโครโฟน" หมายถึงมุมมองบนหน้าจอที่ผู้ใช้มองเห็นได้อย่างต่อเนื่องและไม่สามารถบดบังได้ ซึ่งผู้ใช้เข้าใจว่าไมโครโฟนกำลังใช้งานอยู่(ผ่านข้อความ สี ไอคอน หรือชุดค่าผสมที่ไม่ซ้ำกัน)

"ตัวบ่งชี้กล้อง" หมายถึงมุมมองบนหน้าจอที่ผู้ใช้มองเห็นได้ตลอดเวลาและไม่สามารถบดบังได้ ซึ่งผู้ใช้เข้าใจว่ากล้องกำลังใช้งานอยู่ (ผ่านข้อความ สี ไอคอน หรือชุดค่าผสมที่ไม่ซ้ำกัน)

หลังจากแสดงครั้งแรกเป็นเวลา 1 วินาที ตัวบ่งชี้อาจเปลี่ยนแปลงลักษณะที่ปรากฏ เช่น มีขนาดที่เล็กลง และไม่จำเป็นต้องแสดงตามที่นำเสนอและเข้าใจในตอนแรก

ไฟบอกสถานะไมโครโฟนอาจผสานรวมกับไฟบอกสถานะกล้องที่แสดงอยู่ โดยให้ข้อความ ไอคอน หรือสีบอกให้ผู้ใช้ทราบว่าเริ่มใช้ไมโครโฟนแล้ว

ไฟบอกสถานะกล้องอาจผสานรวมกับไฟบอกสถานะไมโครโฟนที่แสดงอยู่ โดยให้ข้อความ ไอคอน หรือสีบอกให้ผู้ใช้ทราบว่ากล้องเริ่มทำงานแล้ว

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อมีเพียง HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X] เท่านั้นที่เข้าถึงไมโครโฟน
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ไมโครโฟนตามที่แสดงจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมกับข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น
  • [C-SR-3] ขอแนะนำอย่างยิ่งว่าอย่าซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.camera.any อุปกรณ์จะมีลักษณะดังนี้

  • [C-SR-4] ขอแนะนำอย่างยิ่งให้แสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 สิทธิ์ที่มีตัวระบุ CDD [C-3-X] เข้าถึงกล้องเท่านั้น
  • [C-SR-5] ขอแนะนำอย่างยิ่งให้แสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้กล้องตามที่แสดงผลจาก PermissionManager.getIndicatorAppOpUsageData() พร้อมข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น
  • [C-SR-6] ขอแนะนำอย่างยิ่งว่าอย่าซ่อนไฟสัญญาณกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบกับผู้ใช้โดยตรง

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

  • ข้อความและกราฟิกที่แสดงผลบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน AssistStructure API
  • ข้อมูลสื่อ เช่น เสียงหรือวิดีโอที่อุปกรณ์บันทึกหรือเล่น

  • เหตุการณ์การป้อนข้อมูล (เช่น ปุ่ม เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)

  • หน้าจอหรือข้อมูลอื่นๆ ที่ส่งผ่าน AugmentedAutofillService ไปยังระบบ

  • หน้าจอหรือข้อมูลอื่นๆ ที่เข้าถึงได้ผ่าน Content Capture API

  • ข้อมูลแอปพลิเคชันที่ส่งไปยังระบบผ่าน AppSearchManager API และเข้าถึงได้ผ่าน AppSearchGlobalManager.query

  • ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน TextClassifier API ไปยัง System TextClassifier นั่นคือบริการของระบบเพื่อทำความเข้าใจความหมายของข้อความ รวมถึงสร้างการดําเนินการถัดไปที่คาดการณ์ตามข้อความ

  • ข้อมูลที่จัดทำดัชนีโดยการติดตั้งใช้งาน AppSearch ของแพลตฟอร์ม ซึ่งรวมถึงแต่ไม่จำกัดเพียงข้อความ กราฟิก ข้อมูลสื่อ หรือข้อมูลอื่นๆ ที่คล้ายกัน

  • ข้อมูลเสียงที่ได้จากการนํา SpeechRecognizer#onDeviceSpeechRecognizer() ไปใช้กับโปรแกรมจดจําคําพูด

  • ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ Audio API อื่นๆ และไม่แสดงตัวบ่งชี้ที่ผู้ใช้มองเห็น

  • ข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ Camera API อื่นๆ และไม่ได้แสดงตัวบ่งชี้ที่ผู้ใช้มองเห็น

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลข้างต้นไว้ อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องเข้ารหัสข้อมูลดังกล่าวทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้การเข้ารหัสตามไฟล์ของ Android หรือการเข้ารหัสใดๆ ที่แสดงเป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
  • [C-1-2] ต้องไม่สำรองข้อมูลดิบหรือที่เข้ารหัสโดยใช้วิธีการสำรองข้อมูล Android หรือวิธีการสำรองข้อมูลอื่นๆ
  • [C-1-3] ต้องส่งข้อมูลดังกล่าวทั้งหมดออกจากอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัวเท่านั้น ยกเว้นในกรณีที่ได้รับความยินยอมจากผู้ใช้อย่างชัดเจนทุกครั้งที่มีการแชร์ข้อมูล กลไกการรักษาความเป็นส่วนตัวหมายถึง "กลไกที่อนุญาตให้มีการวิเคราะห์แบบรวมเท่านั้นและป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้จากผู้ใช้แต่ละราย" เพื่อไม่ให้สามารถสํารวจข้อมูลต่อผู้ใช้แต่ละรายได้ (เช่น ติดตั้งใช้งานโดยใช้เทคโนโลยีความเป็นส่วนตัวแบบที่แตกต่างกัน เช่น RAPPOR)
  • [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น Account) ในอุปกรณ์ เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล
  • [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลรอบตัว) เว้นแต่จะได้รับความยินยอมจากผู้ใช้อย่างชัดเจนทุกครั้งที่มีการแชร์ เว้นแต่ว่าฟังก์ชันดังกล่าวจะสร้างขึ้นเป็น Android SDK API (AmbientContext, HotwordDetectionService)
  • [C-1-6] ต้องให้ผู้ใช้สามารถลบข้อมูลที่การติดตั้งใช้งานหรือวิธีการที่เป็นกรรมสิทธิ์รวบรวมได้เมื่อมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์ หากผู้ใช้เลือกที่จะลบข้อมูล จะต้องนําข้อมูลย้อนหลังที่รวบรวมไว้ทั้งหมดออก

  • [C-1-7] ต้องให้ผู้ใช้เลือกไม่ใช้ข้อมูลที่รวบรวมผ่าน AppSearch หรือวิธีที่เป็นกรรมสิทธิ์ไม่ให้แสดงในแพลตฟอร์ม Android (เช่น โปรแกรมเปิดแอป)

  • [C-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าขอสิทธิ์ INTERNET

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้เข้าถึงอินเทอร์เน็ตผ่าน Structured API ที่รองรับการใช้งานโอเพนซอร์สที่เผยแพร่ต่อสาธารณะเท่านั้น

  • [C-SR-4] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานกับ Android SDK API หรือที่เก็บข้อมูลโอเพนซอร์สที่คล้ายกันซึ่ง OEM เป็นเจ้าของ และ / หรือทําในการติดตั้งใช้งานใน Sandbox (ดูที่ 9.8.15 การติดตั้งใช้งาน API ใน Sandbox)

หากการติดตั้งใช้งานอุปกรณ์มีบริการที่ใช้ System API ContentCaptureService, AppSearchManager.index หรือบริการที่เป็นกรรมสิทธิ์ใดๆ ที่เก็บรวบรวมข้อมูลตามที่อธิบายไว้ข้างต้น บริการดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้ และต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่เก็บรวบรวมข้อมูลดังกล่าว
  • [C-2-2] ต้องไม่อนุญาตให้แอปใดๆ นอกเหนือจากกลไกบริการที่ติดตั้งไว้ล่วงหน้าสามารถบันทึกข้อมูลดังกล่าว
  • [C-2-3] ต้องให้ผู้ใช้ปิดใช้บริการได้

  • [C-2-4] ต้องระบุตัวเลือกให้ผู้ใช้จัดการสิทธิ์ Android ที่บริการมีไว้ และเป็นไปตามรูปแบบสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้แยกบริการออกจากคอมโพเนนต์อื่นๆ ของระบบ (เช่น ไม่เชื่อมโยงบริการหรือแชร์รหัสกระบวนการ) ยกเว้นในกรณีต่อไปนี้

    • โทรคมนาคม รายชื่อติดต่อ UI ของระบบ และสื่อ

9.8.7. การเข้าถึงคลิปบอร์ด

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่แสดงข้อมูลที่ตัดมาจากคลิปบอร์ด (เช่น ผ่าน ClipboardManager API) เว้นแต่แอปของบุคคลที่สามจะเป็น IME เริ่มต้นหรือเป็นแอปที่มีโฟกัสอยู่ในขณะนี้

  • [C-0-2] ต้องล้างข้อมูลคลิปบอร์ดไม่เกิน 60 นาทีหลังจากที่มีการวางข้อมูลในคลิปบอร์ดหรืออ่านข้อมูลจากคลิปบอร์ดครั้งล่าสุด

9.8.8. ตำแหน่ง

ตำแหน่งประกอบด้วยข้อมูลในคลาสตำแหน่งของ Android( เช่น ละติจูด ลองจิจูด ระดับความสูง) รวมถึงตัวระบุที่แปลงเป็นตำแหน่งได้ ตำแหน่งอาจเป็นแบบละเอียดระดับ DGPS (Differential Global Positioning System) หรือแบบหยาบระดับประเทศก็ได้ (เช่น ตำแหน่งรหัสประเทศ - MCC - รหัสประเทศของอุปกรณ์เคลื่อนที่)

ต่อไปนี้คือรายการประเภทตำแหน่งที่มาจากตำแหน่งของผู้ใช้โดยตรงหรือสามารถแปลงเป็นตำแหน่งของผู้ใช้ รายการนี้ไม่ใช่รายการที่ครอบคลุมทั้งหมด แต่ควรใช้เป็นตัวอย่างของสิ่งที่สามารถดึงข้อมูลตําแหน่งได้โดยตรงหรือโดยอ้อม

  • GPS/GNSS/DGPS/PPP
    • โซลูชันการระบุตำแหน่งทั่วโลกหรือระบบดาวเทียมนำร่องทั่วโลกหรือโซลูชันการระบุตำแหน่งทั่วโลกแบบต่างหาก
    • ซึ่งรวมถึงการวัด GNSS ไฟล์ข้อมูล RAW และสถานะ GNSS ด้วย
      • ตำแหน่งที่แม่นยำสามารถมาจากค่าการวัด GNSS ไฟล์ข้อมูล RAW
  • เทคโนโลยีไร้สายที่มีตัวระบุที่ไม่ซ้ำกัน เช่น
    • จุดเข้าใช้งาน Wi-Fi (MAC, BSSID, ชื่อ หรือ SSID)
    • บลูทูธ/BLE (MAC, BSSID, ชื่อ หรือ SSID)
    • UWB (MAC, BSSID, ชื่อ หรือ SSID)
    • รหัสหอคอยสัญญาณ (3G, 4G, 5G… รวมถึงเทคโนโลยีโมเด็มมือถือในอนาคตทั้งหมดที่มีตัวระบุที่ไม่ซ้ำกัน)

โปรดดู Android API ที่ต้องได้รับสิทธิ์ ACCESS_FINE_Location หรือ ACCESS_COARSE_Location เป็นข้อมูลอ้างอิงหลัก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้หรือผู้ใช้เป็นผู้เริ่มดำเนินการ
  • [C-0-2] ต้องให้สิทธิ์แก่ผู้ใช้ในการเข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่ง ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้งานการสแกน Wi-Fi/บลูทูธเพื่อระบุตำแหน่ง
  • [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] เป็นเซสชันกรณีฉุกเฉินที่ผู้ใช้เริ่ม (เช่น โทรหา 911 หรือส่งข้อความถึง 911) อย่างไรก็ตาม สำหรับยานยนต์ ยานพาหนะอาจเริ่มเซสชันในกรณีฉุกเฉินโดยไม่มีการโต้ตอบจากผู้ใช้ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนดของ eCall)
  • [C-0-4] ต้องรักษาความสามารถของ Emergency Location Bypass API ในการเลี่ยงการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่เปลี่ยนการตั้งค่า
  • [C-0-5] ต้องตั้งเวลาการแจ้งเตือนเพื่อเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งโดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.8.9. แอปที่ติดตั้ง

แอป Android ที่กําหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะไม่เห็นรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้โดยค่าเริ่มต้น (ดูระดับการมองเห็นแพ็กเกจในเอกสารประกอบ Android SDK)

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่แสดงรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้แก่แอปที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป เว้นแต่แอปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ผ่าน API ที่มีการจัดการอยู่แล้ว ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งผู้ติดตั้งใช้งานอุปกรณ์เพิ่มเข้ามา หรือเข้าถึงได้ผ่านระบบไฟล์
  • [C-0-2] ต้องไม่อนุญาตให้แอปใดก็ตามอ่านหรือเขียนไฟล์ในไดเรกทอรีเฉพาะแอปของแอปอื่นภายในพื้นที่เก็บข้อมูลภายนอก ข้อยกเว้นเพียงอย่างเดียวมีดังนี้
    • สิทธิ์ของผู้ให้บริการพื้นที่เก็บข้อมูลภายนอก (เช่น แอปอย่าง DocumentsUI)
    • ผู้ให้บริการดาวน์โหลดที่ใช้สิทธิ์ของผู้ให้บริการ "downloads" เพื่อดาวน์โหลดไฟล์ไปยังพื้นที่เก็บข้อมูลของแอป
    • แอปโปรโตคอลการโอนสื่อ (MTP) ที่ลงนามโดยแพลตฟอร์มซึ่งใช้สิทธิ์ที่มีอภิสิทธิ์ ACCESS_MTP เพื่อเปิดใช้การโอนไฟล์ไปยังอุปกรณ์อื่น
    • แอปที่ติดตั้งแอปอื่นๆ และมีสิทธิ์ INSTALL_PACKAGES จะเข้าถึงได้เฉพาะไดเรกทอรี "obb" เพื่อจุดประสงค์ในการจัดการไฟล์ขยาย APK

9.8.10. รายงานข้อบกพร่องเกี่ยวกับการเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.hardware.telephony ระบบจะดำเนินการดังนี้

  • [C-1-1] ต้องรองรับการสร้างรายงานข้อบกพร่องเกี่ยวกับการเชื่อมต่อผ่าน BUGREPORT_MODE_TELEPHONY ด้วย BugreportManager
  • [C-1-2] ต้องได้รับความยินยอมจากผู้ใช้ทุกครั้งที่มีการใช้ BUGREPORT_MODE_TELEPHONY เพื่อสร้างรายงาน และจะต้องไม่แจ้งให้ผู้ใช้ให้ความยินยอมกับคำขอทั้งหมดในอนาคตจากแอปพลิเคชัน
  • [C-1-3] ต้องไม่ส่งรายงานที่สร้างขึ้นไปยังแอปที่ขอโดยไม่ได้รับความยินยอมจากผู้ใช้อย่างชัดเจน
  • [C-1-4] รายงานที่สร้างขึ้นโดยใช้ BUGREPORT_MODE_TELEPHONY ต้องมีข้อมูลต่อไปนี้เป็นอย่างน้อย
    • TelephonyDebugService ดัมพ์
    • TelephonyRegistry ดัมพ์
    • WifiService ดัมพ์
    • ConnectivityService ดัมพ์
    • การดัมพ์อินสแตนซ์ CarrierService ของแพ็กเกจที่เรียกใช้ (หากมีการเชื่อมโยง)
    • บัฟเฟอร์บันทึกวิทยุ
    • SubscriptionManagerService ดัมพ์
  • [C-1-5] ต้องไม่รวมข้อมูลต่อไปนี้ไว้ในรายงานที่สร้างขึ้น
    • ข้อมูลทุกประเภทที่ไม่เกี่ยวข้องกับการแก้ไขข้อบกพร่องเกี่ยวกับการเชื่อมต่อโดยตรง
    • บันทึกการเข้าชมแอปพลิเคชันที่ผู้ใช้ติดตั้งหรือโปรไฟล์โดยละเอียดของแอปพลิเคชัน/แพ็กเกจที่ผู้ใช้ติดตั้ง (ใช้ UID ได้ แต่ใช้ชื่อแพ็กเกจไม่ได้)
  • อาจรวมข้อมูลเพิ่มเติมที่ไม่ได้เชื่อมโยงกับตัวตนของผู้ใช้ (เช่น บันทึกของผู้ให้บริการ)

หากการติดตั้งใช้งานอุปกรณ์มีข้อมูลเพิ่มเติม (เช่น บันทึกของเวนเดอร์) ในรายงานข้อบกพร่อง และข้อมูลดังกล่าวส่งผลต่อความเป็นส่วนตัว/ความปลอดภัย/แบตเตอรี่/พื้นที่เก็บข้อมูล/หน่วยความจำ ข้อมูลดังกล่าวจะต้องมีลักษณะดังนี้

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ตั้งค่านักพัฒนาซอฟต์แวร์เป็น "ปิดใช้" โดยค่าเริ่มต้น การใช้งานข้อมูลอ้างอิง AOSP เป็นไปตามข้อกำหนดนี้โดยให้Enable verbose vendor loggingตัวเลือกในการตั้งค่าสำหรับนักพัฒนาแอปเพื่อรวมบันทึกเวนเดอร์เพิ่มเติมเฉพาะอุปกรณ์ไว้ในรายงานข้อบกพร่อง

9.8.11. การแชร์ข้อมูลไบนารี

Android ผ่าน BlobStoreManager อนุญาตให้แอปส่งข้อมูล Blob ไปยังระบบเพื่อแชร์กับแอปชุดที่เลือก

หากการติดตั้งใช้งานอุปกรณ์รองรับ Blob ข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องไม่แชร์ Blob ข้อมูลของแอปนอกเหนือจากที่ตั้งใจจะอนุญาต (เช่น ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreManager.session#allowPublicAccess() ต้องไม่แก้ไข) การติดตั้งใช้งานตามข้อมูลอ้างอิงของ AOSP เป็นไปตามข้อกำหนดเหล่านี้
  • [C-1-2] ต้องไม่ส่งแฮชที่ปลอดภัยของข้อมูลบล็อก (ซึ่งใช้เพื่อควบคุมการเข้าถึง) ออกจากอุปกรณ์หรือแชร์กับแอปอื่นๆ

9.8.12. การรับรู้เพลง

Android ผ่าน System API MusicRecognitionManager รองรับกลไกสําหรับการติดตั้งใช้งานอุปกรณ์เพื่อขอการจดจําเพลง โดยให้ไฟล์บันทึกเสียง และมอบสิทธิ์การจดจําเพลงแก่แอปที่มีสิทธิ์ซึ่งใช้ MusicRecognitionService API

หากการติดตั้งใช้งานอุปกรณ์มีบริการที่ใช้ System API ของ MusicRecognitionManager หรือบริการที่เป็นกรรมสิทธิ์ซึ่งสตรีมข้อมูลเสียงตามที่อธิบายไว้ข้างต้น บริการดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] MUST enforce that the caller of MusicRecognitionManager holds the MANAGE_MUSIC_RECOGNITION permission
  • [C-1-2] ต้องบังคับใช้แอปพลิเคชันการจดจําเพลงที่ติดตั้งไว้ล่วงหน้าแอปเดียวที่ใช้ MusicRecognitionService
  • [C-1-3] ต้องไม่อนุญาตให้ผู้ใช้แทนที่ MusicRecognitionManagerService หรือ MusicRecognitionService ด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้
  • [C-1-4] ต้องตรวจสอบว่าเมื่อ MusicRecognitionManagerService เข้าถึงไฟล์บันทึกเสียงและส่งต่อไปยังแอปพลิเคชันที่ใช้ MusicRecognitionService ระบบจะติดตามการเข้าถึงเสียงผ่านการเรียกใช้ AppOpsManager.noteOp / startOp

หากการใช้งาน MusicRecognitionManagerService หรือ MusicRecognitionService ในอุปกรณ์จัดเก็บข้อมูลเสียงที่บันทึกไว้ การดำเนินการต่อไปนี้จะเกิดขึ้น

  • [C-2-1] ต้องไม่จัดเก็บเสียงดิบหรือลายนิ้วมือเสียงไว้ในดิสก์เลย หรือจัดเก็บไว้ในหน่วยความจำนานกว่า 14 วัน
  • [C-2-2] ต้องไม่แชร์ข้อมูลดังกล่าวนอกเหนือจาก MusicRecognitionService เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการแชร์

9.8.13. SensorPrivacyManager

หากการใช้งานอุปกรณ์ให้ทางเลือกซอฟต์แวร์แก่ผู้ใช้ในการปิดกล้องและ/หรืออินพุตไมโครโฟนสำหรับการใช้งานอุปกรณ์ ผู้ใช้จะทำสิ่งต่อไปนี้ได้

  • [C-1-1] ต้องแสดงผล "จริง" อย่างถูกต้องสำหรับเมธอด API ที่เกี่ยวข้อง supportsSensorToggle()
  • [C-1-2] ต้องแสดงตัวเลือกที่ผู้ใช้ไม่สามารถปิดได้ซึ่งบ่งชี้อย่างชัดเจนว่าเซ็นเซอร์ถูกบล็อกและต้องมีตัวเลือกให้ผู้ใช้เลือกว่าจะบล็อกหรือเลิกบล็อกต่อไปตามการใช้งาน AOSP ที่เป็นไปตามข้อกำหนดนี้ เมื่อแอปพยายามเข้าถึงไมโครโฟนหรือกล้องที่ถูกบล็อก
  • [C-1-3] ต้องส่งเฉพาะข้อมูลกล้องและเสียงว่างเปล่า (หรือปลอม) ไปยังแอป และจะไม่รายงานรหัสข้อผิดพลาดเนื่องจากผู้ใช้ไม่ได้เปิดกล้องหรือไมโครโฟนผ่านการแสดงผลที่พร้อมใช้งานสำหรับผู้ใช้ตามที่ระบุไว้ใน [C-1-2] ด้านบน

9.8.14 ไม่มี

9.8.15 การติดตั้งใช้งาน Sandboxed API

Android มีกลไกในการประมวลผลข้อมูลระดับระบบปฏิบัติการและข้อมูลรอบข้างที่ปลอดภัยผ่านชุด API ที่รับมอบสิทธิ์ คุณสามารถมอบสิทธิ์การประมวลผลดังกล่าวให้กับ apk ที่ติดตั้งไว้ล่วงหน้าซึ่งมีสิทธิ์เข้าถึงที่มีสิทธิ์และความสามารถในการสื่อสารที่ลดลง ซึ่งเรียกว่าการติดตั้งใช้งาน API ใน Sandbox

การติดตั้งใช้งาน Sandboxed API ทั้งหมด

  • [C-0-1] ต้องไม่ขอสิทธิ์ INTERNET
  • [C-0-2] ต้องเข้าถึงอินเทอร์เน็ตผ่าน Structured API ที่รองรับการใช้งานโอเพนซอร์สที่เผยแพร่ต่อสาธารณะโดยใช้กลไกการรักษาความเป็นส่วนตัว หรือเข้าถึงผ่าน Android SDK API โดยอ้อมเท่านั้น กลไกการรักษาความเป็นส่วนตัวหมายถึง "กลไกที่อนุญาตให้มีการวิเคราะห์แบบรวมเท่านั้นและป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้จากผู้ใช้แต่ละราย" เพื่อไม่ให้สามารถสํารวจข้อมูลต่อผู้ใช้แต่ละรายได้ (เช่น ติดตั้งใช้งานโดยใช้เทคโนโลยีความเป็นส่วนตัวแบบต่างระดับ เช่น RAPPOR)
  • [C-0-3] ต้องแยกบริการออกจากคอมโพเนนต์อื่นๆ ของระบบ (เช่น ไม่เชื่อมโยงบริการหรือแชร์รหัสกระบวนการ) ยกเว้นในกรณีต่อไปนี้
    • โทรคมนาคม รายชื่อติดต่อ UI ของระบบ และสื่อ
  • [C-0-4] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้
  • [C-0-5] ต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่เก็บรวบรวมข้อมูลดังกล่าว เว้นแต่ว่าความสามารถในการเปลี่ยนทดแทนจะฝังอยู่ใน AOSP (เช่น สําหรับแอปผู้ช่วยดิจิทัล)
  • [C-0-6] ต้องไม่อนุญาตให้แอปใดๆ นอกเหนือจากกลไกบริการที่ติดตั้งไว้ล่วงหน้าสามารถบันทึกข้อมูลดังกล่าว เว้นแต่ว่าจะมีการใช้ความสามารถในการบันทึกดังกล่าวกับ Android SDK API
  • [C-0-7] ต้องให้ผู้ใช้ปิดใช้บริการได้
  • [C-0-8] ต้องระบุโอกาสให้ผู้ใช้จัดการสิทธิ์ Android ที่บริการมีไว้ให้ และเป็นไปตามรูปแบบสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์

9.8.16 ข้อมูลเสียงและกล้องแบบต่อเนื่อง

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

นอกเหนือจากข้อกำหนดที่ระบุไว้ในส่วนที่ 9.8.2 การบันทึก 9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลรอบข้าง และ 9.8.15 การติดตั้งใช้งาน API ในแซนด์บ็อกซ์ การติดตั้งใช้งานที่ใช้ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ Audio API อื่นๆ หรือข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ Camera API อื่นๆ จะต้องมีคุณสมบัติดังนี้

หากการติดตั้งใช้งานอุปกรณ์จับข้อมูลตามที่อธิบายไว้ในส่วนที่ 9.8.2 หรือส่วนที่ 9.8.6 และหากการติดตั้งใช้งานดังกล่าวใช้ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ Audio API อื่นๆ หรือข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ Camera API อื่นๆ การดำเนินการดังกล่าวจะต้องมีลักษณะดังนี้

สิ้นสุดข้อกำหนดใหม่

  • [C-0-1] ต้องบังคับใช้ตัวบ่งชี้ที่เกี่ยวข้อง (กล้องและ/หรือไมโครโฟนตามส่วนที่ 9.8.2 การบันทึก) เว้นแต่ในกรณีต่อไปนี้
    • การเข้าถึงนี้เกิดขึ้นในการใช้งานแบบแซนด์บ็อกซ์ (ดูหัวข้อ 9.8.15 การใช้งาน API แบบแซนด์บ็อกซ์) ผ่านแพ็กเกจที่มีบทบาทต่อไปนี้อย่างน้อย 1 บทบาท System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence หรือ System Visual Intelligence
    • การเข้าถึงจะดำเนินการผ่านแซนด์บ็อกซ์ ซึ่งติดตั้งใช้งานและบังคับใช้ผ่านกลไกใน AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector)
    • แอปพลิเคชันผู้ช่วยดิจิทัลจะดำเนินการเข้าถึงเสียงเพื่อวัตถุประสงค์ในการช่วยเหลือ โดยระบุ SOURCE_HOTWORD เป็นแหล่งที่มาของเสียง
    • ระบบจะดำเนินการเข้าถึงและติดตั้งใช้งานด้วยโค้ดโอเพนซอร์ส
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ขอความยินยอมจากผู้ใช้สำหรับฟังก์ชันการทำงานทั้งหมดที่ใช้ข้อมูลดังกล่าว และปิดใช้โดยค่าเริ่มต้น
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้วิธีการเดียวกัน (กล่าวคือ ปฏิบัติตามข้อจำกัดที่ระบุไว้ในส่วนที่ 9.8.2 การบันทึก 9.8.6 ข้อมูลระดับระบบปฏิบัติการและข้อมูลรอบข้าง 9.8.15 การติดตั้งใช้งาน API ในแซนด์บ็อกซ์ และ 9.8.16 ข้อมูลเสียงและกล้องแบบต่อเนื่อง) กับข้อมูลกล้องที่มาจากอุปกรณ์ที่สวมใส่ได้ระยะไกล

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากข้อมูลกล้องมาจากอุปกรณ์ที่สวมใส่ได้ระยะไกลและเข้าถึงในรูปแบบที่ไม่เข้ารหัสนอกระบบปฏิบัติการ Android การใช้งานในแซนด์บ็อกซ์ หรือฟังก์ชันการทำงานในแซนด์บ็อกซ์ที่ WearableSensingManager สร้างขึ้น บุคคลดังกล่าวจะทำสิ่งต่อไปนี้ได้

หากการติดตั้งใช้งานอุปกรณ์ได้รับข้อมูลจากกล้องหรือไมโครโฟนจากอุปกรณ์ที่สวมใส่ได้ระยะไกล และมีการเข้าถึงข้อมูลในรูปแบบที่ไม่เข้ารหัสนอกระบบปฏิบัติการ Android, การติดตั้งใช้งานในแซนด์บ็อกซ์ หรือฟังก์ชันการทำงานในแซนด์บ็อกซ์ที่สร้างขึ้นโดย WearableSensingManager การดำเนินการต่อไปนี้จะเกิดขึ้น

สิ้นสุดข้อกำหนดใหม่

  • [C-1-1] ต้องระบุให้อุปกรณ์ที่สวมใส่ได้ระยะไกลแสดงตัวบ่งชี้เพิ่มเติม

หากอุปกรณ์มีความสามารถในการโต้ตอบกับแอปพลิเคชันผู้ช่วยดิจิทัลโดยไม่มีคีย์เวิร์ดที่กำหนด (จัดการการค้นหาทั่วไปของผู้ใช้ หรือวิเคราะห์การปรากฏตัวของผู้ใช้ผ่านกล้อง) อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องตรวจสอบว่าการติดตั้งใช้งานดังกล่าวมาจากแพ็กเกจที่มีบทบาท android.app.role.ASSISTANT
  • [C-2-2] ตรวจสอบว่าการใช้งานดังกล่าวใช้ HotwordDetectionService และ/หรือ VisualQueryDetectionService Android API

9.8.17. Telemetry

Android จัดเก็บบันทึกของระบบและแอปโดยใช้ StatsLog API บันทึกเหล่านี้ได้รับการจัดการผ่าน StatsManager API ซึ่งแอปพลิเคชันระบบที่มีสิทธิ์สามารถใช้ได้

StatsManager ยังมีวิธีรวบรวมข้อมูลที่จัดหมวดหมู่ว่ามีความไวต่อความเป็นส่วนตัวจากอุปกรณ์ด้วยกลไกการรักษาความเป็นส่วนตัว โดยเฉพาะอย่างยิ่ง StatsManager::query API ช่วยให้สามารถค้นหาหมวดหมู่เมตริกที่จํากัดซึ่งกําหนดไว้ใน StatsLog

การใช้งานใดก็ตามที่ค้นหาและรวบรวมเมตริกที่จํากัดจาก StatsManager

  • [C-0-1] ต้องเป็นแอปพลิเคชัน/การใช้งานเพียงแอปเดียวในอุปกรณ์และมีสิทธิ์ READ_RESTRICTED_STATS
  • [C-0-2] ต้องส่งเฉพาะข้อมูลการวัดผลและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัว กลไกการรักษาความเป็นส่วนตัวหมายถึง "กลไกที่อนุญาตให้มีการวิเคราะห์แบบรวมเท่านั้นและป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้จากผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้มีการตรวจสอบข้อมูลต่อผู้ใช้แต่ละราย (เช่น ติดตั้งใช้งานโดยใช้เทคโนโลยีการรักษาความเป็นส่วนตัวแบบที่แตกต่างกัน เช่น RAPPOR)
  • [C-0-3] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น บัญชี) ในอุปกรณ์
  • [C-0-4] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.17 การเก็บรวบรวมข้อมูลโดยเคารพความเป็นส่วนตัว)
  • [C-0-5] ต้องให้ทางเลือกแก่ผู้ใช้ในการเปิด/ปิดการเก็บรวบรวม การใช้ และการแชร์ข้อมูลเทเลเมตริกที่รักษาความเป็นส่วนตัว
  • [C-0-6] ต้องให้ผู้ใช้สามารถลบข้อมูลที่การใช้งานรวบรวมไว้ได้หากข้อมูลดังกล่าวจัดเก็บในรูปแบบใดก็ตามในอุปกรณ์ หากผู้ใช้เลือกที่จะลบข้อมูล จะต้องนำข้อมูลทั้งหมดที่เก็บอยู่ในอุปกรณ์ออก
  • [C-0-7] ต้องเปิดเผยการใช้งานโปรโตคอลที่รักษาความเป็นส่วนตัวพื้นฐานในที่เก็บข้อมูลแบบโอเพนซอร์ส
  • [C-0-8 ]ต้องบังคับใช้นโยบายการส่งออกข้อมูลในส่วนนี้เพื่อควบคุมการเก็บรวบรวมข้อมูลในหมวดหมู่เมตริกที่ถูกจํากัดซึ่งกําหนดไว้ใน StatsLog

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 โหมดการบูตโดยตรง แม้ว่า 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] ต้องปฏิบัติตามข้อกําหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นโดยใช้วิธีการเข้ารหัสอย่างใดอย่างหนึ่งต่อไปนี้

9.9.3. วิธีการเข้ารหัส

หากมีการเข้ารหัสการใช้งานอุปกรณ์ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องบูตขึ้นโดยไม่มีการขอข้อมูลเข้าสู่ระบบจากผู้ใช้ และอนุญาตให้แอปที่ทราบการบูตโดยตรงเข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสของอุปกรณ์ (DE) หลังจากที่มีการออกอากาศข้อความ ACTION_LOCKED_BOOT_COMPLETED
  • [C-1-2] ต้องอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่มีการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) หลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยระบุข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และระบบได้ออกอากาศACTION_USER_UNLOCKEDข้อความแล้วเท่านั้น
  • [C-1-13] ต้องไม่เสนอวิธีการปลดล็อกพื้นที่เก็บข้อมูลที่ได้รับความคุ้มครองจาก CE โดยไม่ระบุข้อมูลเข้าสู่ระบบที่ผู้ใช้ระบุ คีย์ตัวกลางที่ลงทะเบียนไว้ หรือการดำเนินการต่อเมื่อรีบูตที่เป็นไปตามข้อกำหนดในส่วนที่ 9.9.4
  • [C-1-4] ต้องใช้การเปิดเครื่องที่ได้รับการยืนยัน
9.9.3.1. การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา

หากการใช้งานอุปกรณ์ใช้การเข้ารหัสตามไฟล์ร่วมกับการเข้ารหัสข้อมูลเมตา อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-5] ต้องเข้ารหัสเนื้อหาไฟล์และข้อมูลเมตาของระบบไฟล์โดยใช้ AES-256-XTS หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวคีย์การเข้ารหัส 256 บิต ซึ่งทำงานในโหมด XTS โดยความยาวเต็มของคีย์คือ 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ที่ https://github.com/google/adiantum ข้อมูลเมตาของระบบไฟล์คือข้อมูลต่างๆ เช่น ขนาดไฟล์ การเป็นเจ้าของ โหมด และแอตทริบิวต์แบบขยาย (xattr)
  • [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS, AES-256-HCTR2 หรือ Adiantum
  • [C-1-12] หากอุปกรณ์มีคำสั่งมาตรฐานการเข้ารหัสขั้นสูง (AES) (เช่น ส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86) จะต้องใช้ตัวเลือกที่อิงตาม AES ด้านบนสำหรับการเข้ารหัสชื่อไฟล์ เนื้อหาไฟล์ และข้อมูลเมตาของระบบไฟล์ ไม่ใช่ Adiantum
  • [C-1-13] ต้องใช้ฟังก์ชันการสร้างคีย์ที่รัดกุมทางวิทยาการเข้ารหัสและเปลี่ยนกลับไม่ได้ (เช่น HKDF-SHA512) เพื่อดึงข้อมูลคีย์ย่อยที่จำเป็น (เช่น คีย์ต่อไฟล์) จากคีย์ CE และ DE "เข้ารหัสได้ยากและย้อนกลับไม่ได้" หมายความว่าฟังก์ชันการสร้างคีย์มีระดับความปลอดภัยอย่างน้อย 256 บิตและทํางานเป็นตระกูลฟังก์ชันแบบสุ่มเทียมในอินพุต
  • [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยการเข้ารหัสตามไฟล์ (FBE) เดียวกันเพื่อวัตถุประสงค์การเข้ารหัสที่แตกต่างกัน (เช่น สําหรับทั้งการเข้ารหัสและการดึงข้อมูลคีย์ หรือสําหรับอัลกอริทึมการเข้ารหัส 2 รายการที่แตกต่างกัน)
  • [C-1-15] ต้องตรวจสอบว่าบล็อกเนื้อหาไฟล์ที่เข้ารหัสทั้งหมดที่ไม่ได้ถูกลบในที่จัดเก็บถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่ขึ้นอยู่กับทั้งไฟล์และออฟเซ็ตภายในไฟล์ นอกจากนี้ ชุดค่าผสมดังกล่าวทั้งหมดต้องไม่ซ้ำกัน ยกเว้นในกรณีที่การเข้ารหัสดำเนินการโดยใช้ฮาร์ดแวร์การเข้ารหัสในบรรทัดซึ่งรองรับความยาว IV เพียง 32 บิต
  • [C-1-16] ต้องตรวจสอบว่าชื่อไฟล์ที่เข้ารหัสซึ่งไม่ได้ถูกลบทั้งหมดในที่จัดเก็บถาวรในไดเรกทอรีที่แตกต่างกันได้รับการเข้ารหัสโดยใช้ชุดค่าผสมที่แตกต่างกันของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV)

  • [C-1-17] ต้องตรวจสอบว่าบล็อกข้อมูลเมตาของระบบไฟล์ที่เข้ารหัสทั้งหมดในที่จัดเก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมที่แตกต่างกันของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV)

  • คีย์ที่ปกป้องพื้นที่เก็บข้อมูล CE และ DE รวมถึงข้อมูลเมตาของระบบไฟล์

    • [C-1-7] ต้องเข้ารหัสผูกกับคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับ Verified Boot และรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
    • [C-1-8] กุญแจ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบหน้าจอล็อกของผู้ใช้
    • [C-1-9] คีย์ CE ต้องเชื่อมโยงกับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบหน้าจอล็อก
    • [C-1-10] ต้องเป็นคีย์ที่ไม่ซ้ำกัน กล่าวคือ คีย์ CE หรือ DE ของผู้ใช้ต้องไม่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
    • [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่รองรับโดยบังคับ
    • [C-1-12] ต้องลบอย่างปลอดภัยระหว่างการปลดล็อกและล็อก Bootloader ตามที่อธิบายไว้ที่นี่

  • ควรทําให้แอปที่จําเป็นซึ่งติดตั้งไว้ล่วงหน้า (เช่น การปลุก โทรศัพท์ Messenger) รองรับการบูตโดยตรง

โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานการเข้ารหัสตามไฟล์ตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนล Linux และการเข้ารหัสข้อมูลเมตาตามฟีเจอร์ "dm-default-key" ของเคอร์เนล Linux

9.9.3.2. การเข้ารหัสระดับบล็อกต่อผู้ใช้

หากการใช้งานอุปกรณ์ใช้การเข้ารหัสระดับบล็อกต่อผู้ใช้ อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องเปิดใช้การรองรับผู้ใช้หลายคนตามที่อธิบายไว้ในส่วนที่ 9.5
  • [C-1-2] ต้องมีพาร์ติชันต่อผู้ใช้ โดยใช้พาร์ติชัน RAW หรือวอลุ่มเชิงตรรกะ
  • [C-1-3] ต้องใช้คีย์การเข้ารหัสที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละรายเพื่อเข้ารหัสอุปกรณ์บล็อกที่อยู่เบื้องหลัง

  • [C-1-4] ต้องใช้ AES-256-XTS สําหรับการเข้ารหัสระดับบล็อกของพาร์ติชันผู้ใช้

  • คีย์ที่ปกป้องอุปกรณ์ที่เข้ารหัสระดับบล็อกต่อผู้ใช้

    • [C-1-5] ต้องเข้ารหัสผูกกับคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับ Verified Boot และรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
    • [C-1-6] ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง

คุณสามารถติดตั้งใช้งานการเข้ารหัสระดับบล็อกต่อผู้ใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของเคอร์เนล Linux ในพาร์ติชันต่อผู้ใช้

9.9.4. เล่นต่อเมื่อรีบูต

กลับมาทำงานต่อเมื่อรีบูตช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดได้ ซึ่งรวมถึงแอปที่ยังไม่รองรับการบูตโดยตรง หลังจากการรีบูตที่ OTA เริ่มต้น ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้หลังจากรีบูต

การใช้งาน "กลับมาทำงานต่อเมื่อรีบูต" ต้องยังคงทำงานต่อไปเพื่อให้มั่นใจว่าเมื่ออุปกรณ์ตกอยู่ในมือผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัสด้วย CE ของผู้ใช้ได้ยากมาก แม้ว่าอุปกรณ์จะเปิดอยู่ พื้นที่เก็บข้อมูล CE จะปลดล็อกอยู่ และผู้ใช้ได้ปลดล็อกอุปกรณ์หลังจากได้รับ OTA แล้วก็ตาม สำหรับการต่อต้านการโจมตีจากภายใน เราจะถือว่าผู้โจมตีสามารถเข้าถึงการออกอากาศคีย์การรับรองการเข้ารหัสได้

ดังนี้

  • [C-0-1] พื้นที่เก็บข้อมูล CE ต้องอ่านไม่ได้ แม้สำหรับผู้โจมตีที่มีอุปกรณ์อยู่จริงและมีความสามารถและข้อจำกัดต่อไปนี้

    • ใช้คีย์การรับรองของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามข้อความที่กำหนดเอง
    • ทําให้อุปกรณ์ได้รับ OTA
    • แก้ไขการทํางานของฮาร์ดแวร์ได้ (AP, Flash ฯลฯ) ยกเว้นตามที่ระบุไว้ด้านล่าง แต่การแก้ไขดังกล่าวจะมีความล่าช้าอย่างน้อย 1 ชั่วโมงและมีการปิด/เปิดเครื่องซึ่งจะทำลายเนื้อหาใน RAM
    • แก้ไขการทํางานของฮาร์ดแวร์ที่ป้องกันการงัดแงะไม่ได้ (เช่น Titan M)
    • อ่าน RAM ของอุปกรณ์ที่ใช้งานอยู่ไม่ได้
    • ไม่สามารถรับข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบ

ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่ใช้และเป็นไปตามคำอธิบายทั้งหมดที่พบที่นี่จะเป็นไปตาม [C-0-1]

9.10. ความสมบูรณ์ของอุปกรณ์

ข้อกำหนดต่อไปนี้ช่วยให้เกิดความโปร่งใสเกี่ยวกับสถานะความสมบูรณ์ของอุปกรณ์ การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานผ่านเมธอด System API อย่างถูกต้องว่าPersistentDataBlockManager.getFlashLockState()สถานะ Bootloader อนุญาตให้แฟลชอิมเมจระบบหรือไม่

  • [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-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่ป้องกันการงัดแงะ: สำหรับจัดเก็บข้อมูลว่า bootloader ปลดล็อกหรือไม่ พื้นที่เก็บข้อมูลที่ตรวจจับการงัดแงะได้หมายความว่าโปรแกรมบูตสามารถตรวจจับได้ว่ามีการรบกวนพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และกำหนดให้ต้องมีการยืนยันด้วยตนเองก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ล็อกอยู่เป็นโหมด Bootloader ปลดล็อก
  • [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันบูต พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้สำหรับกำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
  • [C-1-11] ต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยระหว่างการปลดล็อกและล็อก Bootloader ตาม "9.12 ลบข้อมูล" (รวมถึงพาร์ติชัน userdata และพื้นที่ NVRAM ทั้งหมด)

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-SR-1] หากอุปกรณ์มีชิปแยกหลายชิป (เช่น วิทยุ หน่วยประมวลผลภาพเฉพาะ) เราขอแนะนำอย่างยิ่งให้ยืนยันทุกขั้นตอนในการบูตชิปแต่ละชิป

  • [C-1-14] ต้องยืนยันลายเซ็นอย่างน้อย 1 ครั้งต่อการบูตสำหรับแพ็กเกจในรายการที่อนุญาตซึ่งแสดงเป็น require-strict-signature ในการกำหนดค่าระบบ

สิ้นสุดข้อกำหนดใหม่

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดด้วยเชนความน่าเชื่อถือที่รูทในพาร์ติชันที่ได้รับการปกป้องโดยการบูตที่ผ่านการยืนยัน
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้ยืนยันอาร์ติแฟกต์ที่เรียกใช้งานได้ซึ่งโหลดโดยแอปที่มีสิทธิ์จากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์แล้ว) ก่อนเรียกใช้ หรือขอแนะนำอย่างยิ่งว่าอย่าเรียกใช้อาร์ติแฟกต์ดังกล่าวเลย
  • ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์แบบถาวร (เช่น โมเด็ม กล้อง) และใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้สำหรับกำหนดเวอร์ชันต่ำสุดที่อนุญาต

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

หากมีการใช้งานอุปกรณ์ไปแล้วโดยไม่รองรับ C-1-8 ถึง C-1-11 ใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

สิ้นสุดข้อกำหนดใหม่

โครงการโอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ที่แนะนำในที่เก็บข้อมูล external/avb/ ซึ่งสามารถผสานรวมเข้ากับโปรแกรมโหลดที่ใช้โหลด Android ได้

หากการติดตั้งใช้งานอุปกรณ์สามารถยืนยันเนื้อหาไฟล์ในแต่ละหน้าได้ อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] รองรับการยืนยันเนื้อหาไฟล์ด้วยวิทยาการเข้ารหัสโดยไม่ต้องอ่านทั้งไฟล์

  • [C-2-2] ต้องไม่อนุญาตให้คำขออ่านในไฟล์ที่ได้รับการคุ้มครองดำเนินการสำเร็จเมื่อเนื้อหาที่อ่านไม่ได้รับการยืนยันตาม [C-2-1] ด้านบน

  • [C-2-4] ต้องแสดงผลการตรวจสอบผลรวมของไฟล์ใน O(1) สำหรับไฟล์ที่เปิดใช้

หากมีการเปิดตัวการใช้งานอุปกรณ์ไปแล้วโดยไม่สามารถยืนยันเนื้อหาไฟล์กับคีย์ที่เชื่อถือได้ใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ตามฟีเจอร์ fs-verity ของเคอร์เนล Linux ซึ่งแนะนำ

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ 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] การตรวจสอบสิทธิ์หน้าจอล็อกต้องใช้ช่วงเวลาระหว่างการพยายามที่ล้มเหลว เมื่อ n เป็นจํานวนครั้งที่พยายามไม่สําเร็จ ช่วงเวลาต้องนานอย่างน้อย 30 วินาทีสําหรับ 9 < n < 30 สำหรับ n > 29 ค่าช่วงเวลาต้องไม่ต่ำกว่า 30*2^floor((n-30)/10)) วินาที หรืออย่างน้อย 24 ชั่วโมง ขึ้นอยู่กับว่าค่าใดน้อยกว่า
  • ควรไม่จํากัดจํานวนคีย์ที่สร้างได้

เมื่อการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องสำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยก
  • [C-1-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA, ECDH (หากรองรับ IKeyMintDevice), 3DES และ HMAC รวมถึงฟังก์ชันการแฮชของกลุ่ม MD5, SHA-1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Android Keystore รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การใช้งาน Trusty แต่ก็มีโซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามซึ่งเป็นตัวเลือกทางเลือก
  • [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อตรวจสอบสิทธิ์สำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบของหน้าจอล็อกต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการเรียกใช้แบบแยกส่วนเท่านั้นที่จะทำการตรวจสอบสิทธิ์ของหน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-1-4] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงนามในการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คีย์การรับรองการรับรองต้อง แชร์ในอุปกรณ์จํานวนมากพอที่จะป้องกันไม่ให้มีการใช้คีย์ ป้องกันเพื่อใช้เป็นตัวระบุอุปกรณ์ถาวร

    หมายเหตุ: หากต้องการปฏิบัติตามข้อกำหนดนี้ คุณต้องแชร์คีย์การรับรองเดียวกันสำหรับ SKU หนึ่งๆ เว้นแต่จะมีการผลิต SKU หนึ่งๆ นั้นเป็นจำนวนอย่างน้อย 100,000 หน่วย หากมีการผลิต SKU นั้นมากกว่า 100,000 หน่วย ระบบอาจใช้คีย์อื่นสำหรับกลุ่ม 100,000 หน่วยแต่ละกลุ่มหลังจากนั้น หรืออาจใช้โซลูชันการจัดสรรคีย์ระยะไกลเพื่อจัดสรรคีย์การรับรองที่มีอายุสั้นให้กับอุปกรณ์

สิ้นสุดข้อกำหนดใหม่

โปรดทราบว่าหากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยกและรองรับการรับรองคีย์ เว้นแต่จะมีการประกาศใช้ฟีเจอร์ android.hardware.fingerprint ซึ่งต้องใช้คีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยก

  • [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกการหมดเวลาของโหมดสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นล็อก โดยมีเวลาหมดเวลาที่อนุญาตขั้นต่ำสูงสุด 15 วินาที อุปกรณ์ยานยนต์ที่ล็อกหน้าจอทุกครั้งที่ปิดส่วนหัวหรือเปลี่ยนผู้ใช้ อาจไม่มีการกำหนดค่าการหมดเวลาของโหมดสลีป
  • [C-1-6] ต้องรองรับรายการใดรายการหนึ่งต่อไปนี้
    • IKeymasterDevice 3.0,
    • IKeymasterDevice 4.0,
    • IKeymasterDevice 4.1,
    • IKeyMintDevice เวอร์ชัน 1 หรือ
    • IKeyMintDevice เวอร์ชัน 2
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ IKeyMintDevice เวอร์ชัน 1

9.11.1. หน้าจอล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือน

การใช้งาน AOSP เป็นไปตามรูปแบบการตรวจสอบสิทธิ์แบบเป็นชั้น ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตาม Knowledge Factory สามารถรองรับการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกที่ปลอดภัยรองลงมา หรือรูปแบบการตรวจสอบสิทธิ์ที่ปลอดภัยน้อยกว่าในระดับที่สาม

การติดตั้งใช้งานอุปกรณ์

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ตั้งค่าวิธีการตรวจสอบสิทธิ์หลักเป็นวิธีใดวิธีหนึ่งต่อไปนี้เท่านั้น

    • PIN เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน

    • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 เท่านั้น

      โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

  • [C-0-1] ต้องจํากัดจํานวนครั้งที่พยายามตรวจสอบสิทธิ์หลักไม่สําเร็จ

  • [C-SR-5] ขอแนะนำอย่างยิ่งให้ใช้ขีดจำกัดสูงสุด 20 ครั้งสำหรับการพยายามตรวจสอบสิทธิ์หลักที่ไม่สำเร็จ และหากผู้ใช้ยินยอมและเลือกใช้ฟีเจอร์นี้ ให้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" หลังจากพยายามตรวจสอบสิทธิ์หลักไม่สำเร็จเกินขีดจำกัด

หากการติดตั้งใช้งานอุปกรณ์ตั้งค่า PIN เป็นตัวเลขเป็นวิธีตรวจสอบสิทธิ์หลักที่แนะนำ ให้ทำดังนี้

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้ PIN มีความยาวอย่างน้อย 6 หลัก หรือเทียบเท่าความผันผวน 20 บิต
  • [C-SR-7] ขอแนะนำอย่างยิ่งว่าอย่าอนุญาตให้ป้อน PIN โดยอัตโนมัติโดยไม่ต้องมีการโต้ตอบจากผู้ใช้เพื่อหลีกเลี่ยงการเปิดเผยความยาวของ PIN หาก PIN มีความยาวน้อยกว่า 6 หลัก

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะมีลักษณะดังนี้

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกหากอิงตามข้อมูลที่เป็นความลับที่ทราบและใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อใช้เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ ให้ทำดังนี้

  • [C-3-1] เอนโทรปีของอินพุตที่มีความยาวน้อยที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ที่ติดตั้งใช้งานและระบุไว้ใน AOSP
  • [C-3-4] คุณต้องปิดใช้วิธีการตรวจสอบสิทธิ์ใหม่เมื่อแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายข้อกำหนดของรหัสผ่านผ่านเมธอด DevicePolicyManager.setRequiredPasswordComplexity() ที่มีค่าคงที่ของความซับซ้อนที่เข้มงวดกว่า PASSWORD_COMPLEXITY_NONE หรือผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-3-5] วิธีการตรวจสอบสิทธิ์ใหม่ต้องเปลี่ยนไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยให้ผู้ใช้ทราบอย่างชัดเจนว่าระบบจะไม่สำรองข้อมูลบางอย่างเพื่อรักษาความเป็นส่วนตัวของข้อมูล

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอล็อก และใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามข้อมูลไบโอเมตริกเพื่อให้ระบบถือว่านี่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการใหม่จะต้องมีลักษณะดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 7.3.10 สำหรับระดับ 1 (เดิมคือความสะดวก)
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่เป็นความลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้มีการตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ตั้งค่านโยบายฟีเจอร์การป้องกันหน้าจอโดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() พร้อม Flag ข้อมูลไบโอเมตริกที่เกี่ยวข้อง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับระดับ 3 (เดิมคือขั้นสูง) ตามที่อธิบายไว้ในส่วนที่ 7.3.10

  • [C-5-1] วิธีการต้องปิดใช้หากแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ได้ตั้งค่านโยบายคุณภาพข้อกำหนดของรหัสผ่านผ่าน DevicePolicyManager.setRequiredPasswordComplexity() ที่มีกลุ่มความซับซ้อนที่เข้มงวดกว่า PASSWORD_COMPLEXITY_LOW หรือใช้เมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-5-2] ผู้ใช้ต้องได้รับการขอข้อมูลเข้าสู่ระบบหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วนที่ 7.3.10
  • [C-5-3] วิธีการต้องไม่ถือว่ามีการรักษาความปลอดภัยระดับหน้าจอล็อก และต้องเป็นไปตามข้อกำหนดที่ขึ้นต้นด้วย C-8 ในส่วนนี้ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อก และวิธีการตรวจสอบสิทธิ์ใหม่นั้นอิงตามโทเค็นจริงหรือตำแหน่ง ให้ทำดังนี้

  • [C-6-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลที่เป็นความลับที่ทราบและเป็นไปตามข้อกำหนดเพื่อให้ระบบถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
  • [C-6-2] คุณต้องปิดใช้วิธีการใหม่และอนุญาตให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพียงวิธีใดวิธีหนึ่งเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชันตัวควบคุมนโยบายอุปกรณ์ (DPC) ตั้งค่านโยบายด้วยตัวเลือกต่อไปนี้
  • [C-6-3] ผู้ใช้ต้องได้รับการขอข้อมูลยืนยันผ่านวิธีการตรวจสอบสิทธิ์หลักที่แนะนำอย่างใดอย่างหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 4 ชั่วโมงหรือน้อยกว่านั้น เมื่อโทเค็นที่จับต้องได้เป็นไปตามข้อกำหนดในการติดตั้งใช้งาน TrustAgent ใน C-X ข้อจำกัดเกี่ยวกับระยะหมดเวลาที่กำหนดไว้ใน C-9-5 จะมีผลแทน
  • [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 หรืออุปกรณ์ยานยนต์)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่จัดเก็บคีย์การเข้ารหัสหรือโทเค็นตัวกลางในอุปกรณ์เดียวกับที่ใช้คีย์ เช่น อนุญาตให้ใช้คีย์ที่เก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้ในทีวี สำหรับอุปกรณ์ยานยนต์ ระบบไม่อนุญาตให้จัดเก็บโทเค็นตัวกลางในชิ้นส่วนใดๆ ของยานพาหนะ
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบถึงผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นตัวกลางเพื่อถอดรหัสพื้นที่เก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง
  • [C-7-9] ผู้ใช้ต้องได้รับการตรวจสอบด้วยวิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วนที่ 7.3.10 เว้นแต่ว่าความปลอดภัยของผู้ใช้ (เช่น การทำให้ผู้ขับขี่เสียสมาธิ) จะเป็นสิ่งที่น่ากังวล
  • [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_NONE หรือผ่านวิธี DevicePolicyManager.setRequiredPasswordComplexity() ที่มีค่าคงที่ด้านความซับซ้อนที่เข้มงวดกว่า 'PASSWORD_COMPLEXITY_NONE'
  • [C-8-2] ผู้ใช้ต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ตั้งค่าโดย DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-8-3] แอปต้องไม่เปิดเผย API ให้แอปของบุคคลที่สามใช้เพื่อเปลี่ยนสถานะการล็อก

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนจริงรองและไม่รองรับเหตุการณ์อินพุตที่เชื่อมโยง เช่น ผ่าน VirtualDeviceManager ระบบจะดำเนินการดังนี้

  • [C-9-1] ต้องล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ล็อกอยู่ และปลดล็อกจอแสดงผลเสมือนรองเหล่านี้เมื่อจอแสดงผลเริ่มต้นของอุปกรณ์ปลดล็อกอยู่

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนจริงรองและรองรับเหตุการณ์อินพุตที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager แอปพลิเคชันจะทําสิ่งต่อไปนี้

  • [C-10-1] ต้องรองรับสถานะการล็อกแยกกันสำหรับอุปกรณ์เสมือนแต่ละเครื่อง
  • [C-10-2] ต้องยกเลิกการเชื่อมต่ออุปกรณ์เสมือนทั้งหมดเมื่อหมดเวลาไม่ใช้งาน
  • [C-10-3] ต้องมีช่วงระยะเวลาที่ไม่มีการใช้งาน
  • [C-10-4] ต้องล็อกจอแสดงผลทั้งหมดเมื่อผู้ใช้เริ่มการล็อก รวมถึงผ่านการแสดงผลที่ผู้ใช้เห็นสำหรับการล็อกที่จำเป็นสำหรับอุปกรณ์แบบใช้มือถือ (ดูส่วนที่ 2.2.5[9.11/H-1-2])
  • [C-10-5] ต้องมีอินสแตนซ์อุปกรณ์เสมือนแยกกันต่อผู้ใช้

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-10-6] ต้องปิดใช้การสร้างเหตุการณ์อินพุตที่เชื่อมโยงผ่าน VirtualDeviceManager เมื่อระบุโดย การสตรีมแอปตามที่ระบุโดย DevicePolicyManager.setNearbyAppStreamingPolicy

สิ้นสุดข้อกำหนดใหม่

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-10-7] ต้องระบุอย่างใดอย่างหนึ่งต่อไปนี้
    • ปิดใช้คลิปบอร์ด
    • เปิดใช้คลิปบอร์ดแยกต่างหากสำหรับอุปกรณ์แต่ละเครื่องที่รองรับคลิปบอร์ด

  • [C-10-7] ต้องใช้คลิปบอร์ดแยกต่างหากสำหรับอุปกรณ์เสมือนแต่ละเครื่องเท่านั้น (หรือปิดใช้คลิปบอร์ดสำหรับอุปกรณ์เสมือน)

สิ้นสุดข้อกำหนดใหม่

  • [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึงการป้อนข้อมูลปัจจัยด้านความรู้และข้อความแจ้งให้ใช้ข้อมูลไบโอเมตริก

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-10-12] ต้องจํากัด Intent ที่เริ่มต้นจากอุปกรณ์เสมือนให้แสดงในอุปกรณ์เสมือนเดียวกันเท่านั้น

สิ้นสุดข้อกำหนดใหม่

  • [C-10-13] ต้องไม่ใช้สถานะการล็อกอุปกรณ์เสมือนเป็นการให้สิทธิ์การตรวจสอบสิทธิ์ผู้ใช้ด้วยระบบคีย์สโตร์ของ Android โปรดดูKeyGenParameterSpec.Builder.setUserAuthentication*

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

  • [C-10-14] ต้องระบุทางเลือกให้ผู้ใช้เพื่อเปิดใช้การแชร์คลิปบอร์ดระหว่างอุปกรณ์ก่อนแชร์ข้อมูลคลิปบอร์ดระหว่างอุปกรณ์จริงและเสมือน หากอุปกรณ์ใช้คลิปบอร์ดที่ใช้ร่วมกัน
  • [C-10-15] ต้องแสดงการแจ้งเตือนเมื่อมีการเข้าถึงข้อมูลคลิปบอร์ดในอุปกรณ์ต่างๆ และต้องทําให้เนื้อหาเข้าถึงไม่ได้หลังจากผ่านไป 1 นาทีโดยนับจากเวลาที่แชร์ครั้งแรก

สิ้นสุดข้อกำหนดใหม่

เมื่อการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้โอนปัจจัยความรู้ในการตรวจสอบสิทธิ์หลักจากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เช่น สำหรับการตั้งค่าเริ่มต้นของอุปกรณ์เป้าหมาย ผู้ใช้จะทำสิ่งต่อไปนี้ได้

  • [C-11-1] ต้องเข้ารหัสปัจจัยที่ทราบด้วยการรับประกันการปกป้องที่คล้ายกับที่อธิบายไว้ในเอกสารประกอบด้านความปลอดภัยของบริการ Google Cloud Key Vault เมื่อโอนปัจจัยที่ทราบจากอุปกรณ์ต้นทางไปยังอุปกรณ์ปลายทาง เพื่อไม่ให้สามารถถอดรหัสปัจจัยที่ทราบจากระยะไกลหรือนำไปใช้ปลดล็อกอุปกรณ์จากระยะไกลได้
  • [C-11-2] บนอุปกรณ์ต้นทาง จะต้องขอให้ผู้ใช้ยืนยันปัจจัยความรู้ของอุปกรณ์ต้นทางก่อนที่จะโอนปัจจัยความรู้ไปยังอุปกรณ์ปลายทาง
  • [C-11-3] ในกรณีที่อุปกรณ์เป้าหมายไม่มีปัจจัยความรู้สำหรับการรับรองความถูกต้องหลักที่ตั้งไว้ จะต้องขอให้ผู้ใช้ยืนยันปัจจัยความรู้ที่โอนในอุปกรณ์เป้าหมายก่อนที่จะตั้งค่าปัจจัยความรู้นั้นเป็นปัจจัยความรู้สำหรับการรับรองความถูกต้องหลักของอุปกรณ์เป้าหมาย และก่อนที่จะทำให้ข้อมูลที่โอนจากอุปกรณ์ต้นทางพร้อมใช้งาน

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีตัวแทนความน่าเชื่อถืออย่างน้อย 1 รายซึ่งเรียกใช้ TrustAgentService.grantTrust() System API พร้อม Flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE ตัวแทนดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-12-1] ต้องเรียก grantTrust() พร้อม Flag เฉพาะเมื่อเชื่อมต่อกับอุปกรณ์ที่จับต้องได้ซึ่งอยู่ใกล้เคียงและมีหน้าจอล็อกของตัวเอง และเมื่อผู้ใช้ตรวจสอบสิทธิ์ตัวตนกับหน้าจอล็อกนั้นแล้ว อุปกรณ์ที่อยู่ใกล้เคียงสามารถใช้กลไกการตรวจจับบนข้อมือหรือร่างกายหลังจากการปลดล็อกแบบครั้งเดียวของผู้ใช้เพื่อปฏิบัติตามข้อกำหนดการตรวจสอบสิทธิ์ของผู้ใช้
  • [C-12-2] ต้องทำให้การติดตั้งใช้งานอุปกรณ์อยู่ในTrustState.TRUSTABLEสถานะเมื่อปิดหน้าจอ (เช่น ผ่านการกดปุ่มหรือการแสดงผลหมดเวลา) และ TrustAgent ยังไม่ได้เพิกถอนความไว้วางใจ AOSP เป็นไปตามข้อกำหนดนี้
  • [C-12-3] ต้องย้ายอุปกรณ์จากสถานะ TrustState.TRUSTABLE ไปยังสถานะ TrustState.TRUSTED เฉพาะในกรณีที่ TrustAgent ยังคงให้สิทธิ์เชื่อถือตามข้อกำหนดใน C-12-1
  • [C-12-4] MUST call TrustManagerService.revokeTrust()
    • หลังจากผ่านไปไม่เกิน 24 ชั่วโมงนับจากการให้สิทธิ์เชื่อถือ หรือ
    • หลังจากผ่านไป 8 ชั่วโมงที่ไม่ได้ใช้งาน หรือ
    • หากการติดตั้งใช้งานไม่ได้ใช้ช่วงความแม่นยำและการเข้ารหัสที่รัดกุมตามที่ระบุไว้ใน [C-12-5] เมื่อการเชื่อมต่อกับอุปกรณ์จริงที่อยู่ใกล้เคียงขาดหายไป
  • [C-12-5] การติดตั้งใช้งานที่อาศัยการระบุระยะทางที่ปลอดภัยและแม่นยำเพื่อให้เป็นไปตามข้อกำหนดของ [C-12-4] ต้องใช้โซลูชันอย่างใดอย่างหนึ่งต่อไปนี้
    • การใช้งาน UWB มีดังนี้
      • ต้องเป็นไปตามข้อกำหนดการปฏิบัติตามข้อกำหนด การรับรอง ความแม่นยำ และการปรับเทียบสำหรับ UWB ที่อธิบายไว้ใน 7.4.9
      • ต้องใช้โหมดความปลอดภัย P-STS รายการใดรายการหนึ่งตามที่ระบุไว้ในหัวข้อ7.4.9
    • การใช้งานโดยใช้ Wi-Fi Neighborhood Awareness Networking (NAN)
      • ต้องเป็นไปตามข้อกำหนดด้านความแม่นยำในหัวข้อ 2.2.1 [7.4.2.5/H-SR-1] ใช้แบนด์วิดท์ 160 MHz (หรือสูงกว่า) และทำตามขั้นตอนการตั้งค่าการวัดที่ระบุไว้ในการปรับเทียบการมีอยู่
      • ต้องใช้ LTF ที่ปลอดภัยตามที่ระบุไว้ใน IEEE 802.11az

หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนจริงรองและรองรับเหตุการณ์อินพุตที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager และไม่ได้ทําเครื่องหมายจอแสดงผลด้วย VIRTUAL_DISPLAY_FLAG_SECURE จอแสดงผลดังกล่าวจะมีลักษณะดังนี้

  • [C-13-8] ต้องบล็อกกิจกรรมที่มีแอตทริบิวต์ android:canDisplayOnRemoteDevices หรือข้อมูลเมตา android.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น false ไม่ให้เริ่มต้นในอุปกรณ์เสมือน

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

สิ้นสุดข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์รองรับสถานะพลังงานของจอแสดงผลแยกต่างหากผ่าน DeviceStateManager และรองรับสถานะการล็อกจอแสดงผลแยกต่างหากผ่าน KeyguardDisplayManager อุปกรณ์จะมีลักษณะดังนี้

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้ข้อมูลเข้าสู่ระบบที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 9.11.1 หรือข้อมูลไบโอเมตริกที่เป็นไปตามข้อกำหนดระดับ 1 เป็นอย่างน้อยตามที่ระบุไว้ในส่วนที่ 7.3.10 เพื่อให้ปลดล็อกจากหน้าจออุปกรณ์เริ่มต้นได้อิสระ
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้จำกัดการปลดล็อกจอแสดงผลแยกต่างหากผ่านระยะหมดเวลาของจอแสดงผลที่กำหนด
  • [C-SR-4] ขอแนะนำอย่างยิ่งให้อนุญาตให้ผู้ใช้ล็อกหน้าจอทั้งหมดทั่วโลกผ่านโหมดล็อกดาวน์จากอุปกรณ์มือถือหลัก

9.11.2. StrongBox

ระบบ Keystore ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ รวมถึงสภาพแวดล้อมการเรียกใช้แบบแยกต่างหากตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยโดยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 จนถึง C-1-11 ด้านล่างระบุข้อกำหนดที่อุปกรณ์ต้องมีคุณสมบัติตรงตามจึงจะถือเป็น StrongBox ได้

การติดตั้งใช้งานอุปกรณ์ที่มีโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ

  • [C-SR-1] ขอแนะนําอย่างยิ่งให้รองรับ 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] สำหรับการติดตั้งใช้งานอุปกรณ์

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

สิ้นสุดข้อกำหนดใหม่

  • [C-1-11] ต้องมีเฟิร์มแวร์ที่ประเมินโดยห้องทดลองทดสอบที่ได้รับการรับรองในระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่อาจเกิดขึ้นจากการโจมตีระดับสูงตามเกณฑ์ร่วมกันสำหรับการใช้งานสมาร์ทการ์ดที่อาจถูกโจมตี
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ประเมินโดยใช้เป้าหมายด้านความปลอดภัย ระดับความเชื่อมั่นในการประเมิน (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้สามารถต้านทานการโจมตีจากบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถผลิตเฟิร์มแวร์ที่ทำให้ StrongBox เกิดการรั่วไหลของข้อมูลลับ เพื่อเลี่ยงข้อกำหนดด้านความปลอดภัยด้านฟังก์ชันการทำงาน หรือเพื่อเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่เราแนะนำในการใช้งาน IAR คืออนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการให้รหัสผ่านผู้ใช้หลักผ่าน HAL ของ IAuthSecret

9.11.3. ข้อมูลประจำตัว

ระบบข้อมูลเข้าสู่ระบบจะกำหนดและใช้งานได้ด้วยการติดตั้งใช้งาน API ทั้งหมดในแพ็กเกจ android.security.identity.* API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและเรียกดูเอกสารระบุตัวตนของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์

  • [C-SR-1] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานระบบข้อมูลเข้าสู่ระบบ

หากการติดตั้งใช้งานอุปกรณ์ใช้ระบบข้อมูลเข้าสู่ระบบเพื่อระบุตัวตน อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] วิธีการ IdentityCredentialStore#getInstance() ต้องแสดงผลลัพธ์ที่ไม่ใช่ค่า Null

  • [C-1-2] ต้องติดตั้งใช้งานระบบข้อมูลเข้าสู่ระบบ (เช่น android.security.identity.* API) ด้วยโค้ดที่สื่อสารกับแอปพลิเคชันที่เชื่อถือได้ในส่วนที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA

  • [C-1-3] การดำเนินการทางวิทยาการเข้ารหัสที่จำเป็นในการใช้ระบบข้อมูลเข้าสู่ระบบ (เช่น android.security.identity.* API) ต้องดำเนินการทั้งหมดในแอปพลิเคชันที่เชื่อถือได้ และข้อมูลคีย์ส่วนตัวต้องไม่ออกจากสภาพแวดล้อมการเรียกใช้แบบแยกส่วน เว้นแต่ API ระดับที่สูงขึ้นจะกำหนดไว้โดยเฉพาะ (เช่น วิธีการ createEphemeralKeyPair())

  • [C-1-4] แอปพลิเคชันที่เชื่อถือได้ต้องติดตั้งใช้งานในลักษณะที่ลักษณะการรักษาความปลอดภัยของแอปพลิเคชันไม่ได้รับผลกระทบ (เช่น ระบบจะไม่เปิดเผยข้อมูลเข้าสู่ระบบ เว้นแต่ว่าเงื่อนไขการควบคุมการเข้าถึงจะเป็นไปตามข้อกำหนด ไม่สามารถผลิต MAC สำหรับข้อมูลที่กำหนดเองได้) แม้ว่า Android จะทำงานผิดปกติหรือถูกบุกรุกก็ตาม

โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานแอปพลิเคชันที่เชื่อถือได้ (libeic) เพื่อเป็นข้อมูลอ้างอิง ซึ่งสามารถใช้เพื่อติดตั้งใช้งานระบบข้อมูลเข้าสู่ระบบของข้อมูลประจำตัว

9.12. การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องจัดเตรียมกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ userdata เมื่อทำการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่เป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88 เมื่อทำการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลักเรียกใช้ DevicePolicyManager.wipeData() API
  • อาจให้ตัวเลือกการลบข้อมูลอย่างรวดเร็วซึ่งจะดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการบูตอย่างปลอดภัย

Android มีโหมดการบูตอย่างปลอดภัย ซึ่งช่วยให้ผู้ใช้บูตเข้าสู่โหมดที่อนุญาตให้ทำงานเฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าและปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการบูตอย่างปลอดภัย" ซึ่งจะช่วยให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การติดตั้งใช้งานอุปกรณ์มีดังนี้

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้โหมดการบูตอย่างปลอดภัย

หากการใช้งานอุปกรณ์ใช้โหมดการบูตอย่างปลอดภัย อุปกรณ์จะมีลักษณะดังนี้

  • [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() จากแอปของผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจการสมัครใช้บริการที่ถูกต้องในปัจจุบัน

9.16 การย้ายข้อมูลแอปพลิเคชัน

หากการติดตั้งใช้งานอุปกรณ์มีความสามารถในการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งและไม่จำกัดข้อมูลแอปพลิเคชันที่คัดลอกไปยังข้อมูลที่นักพัฒนาแอปพลิเคชันกำหนดค่าไว้ในไฟล์ Manifest ผ่านแอตทริบิวต์ android:fullBackupContent การดำเนินการดังกล่าวจะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องไม่เริ่มการโอนข้อมูลแอปพลิเคชันจากอุปกรณ์ที่ผู้ใช้ไม่ได้ตั้งค่าการตรวจสอบสิทธิ์หลักตามที่อธิบายไว้ใน9.11.1 หน้าจอล็อกที่ปลอดภัยและการตรวจสอบสิทธิ์
  • [C-1-2] ต้องยืนยันการตรวจสอบสิทธิ์หลักในอุปกรณ์แหล่งที่มาอย่างปลอดภัย และยืนยันความตั้งใจของผู้ใช้ในการคัดลอกข้อมูลในอุปกรณ์แหล่งที่มาก่อนที่จะมีการโอนข้อมูล
  • [C-1-3] ต้องใช้การรับรองคีย์ความปลอดภัยเพื่อให้มั่นใจว่าทั้งอุปกรณ์ต้นทางและอุปกรณ์ปลายทางในการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งเป็นอุปกรณ์ Android ที่ถูกต้องและมี Bootloader ที่ล็อกอยู่
  • [C-1-4] ต้องย้ายข้อมูลแอปพลิเคชันไปยังแอปพลิเคชันเดียวกันในอุปกรณ์เป้าหมายเท่านั้น โดยมีชื่อแพ็กเกจและใบรับรองการรับรองเดียวกัน
  • [C-1-5] ต้องแสดงตัวบ่งชี้ว่าอุปกรณ์ต้นทางมีการย้ายข้อมูลโดยบริการย้ายข้อมูลระหว่างอุปกรณ์ในเมนูการตั้งค่า ผู้ใช้ไม่ควรนำการระบุนี้ออกได้

9.17. เฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android

เริ่มใช้ข้อกำหนดใหม่สำหรับ Android 15

API ของเฟรมเวิร์กการจำลองเสมือนของ Android (AVF) (android.system.virtualmachine.*) ช่วยให้แอปพลิเคชันสร้างเครื่องเสมือน (VM) ในอุปกรณ์ ซึ่งมีทั้งแบบมีการป้องกัน (pVM) และแบบไม่มีการป้องกัน (non-pVM) ที่โหลดและเรียกใช้ไบนารีเนทีฟเป็นเพย์โหลด

หากการติดตั้งใช้งานอุปกรณ์ตั้งค่า FEATURE_VIRTUALIZATION_FRAMEWORK เป็น true ระบบจะดำเนินการดังนี้

  • [C-1-1] MUST ensure that android.system.virtualmachine.VirtualMachineManager.getCapabilities() returns one of the following:
    • CAPABILITY_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

สิ้นสุดข้อกำหนดใหม่

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การติดตั้งใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ใช้งานอุปกรณ์ทำการเปลี่ยนแปลงน้อยที่สุดเท่าที่จะเป็นไปได้กับการใช้งาน Android อ้างอิงและการใช้งานที่แนะนำจากโครงการโอเพนซอร์ส Android วิธีนี้จะช่วยลดความเป็นไปได้ที่จะเกิดข้อบกพร่องซึ่งทำให้เกิดความเข้ากันไม่ได้ ซึ่งอาจทำให้ต้องทํางานใหม่และอาจต้องอัปเดตอุปกรณ์

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) ที่พร้อมใช้งานจากโปรเจ็กต์โอเพนซอร์สของ Android โดยใช้ซอฟต์แวร์เวอร์ชันสุดท้ายที่พร้อมจำหน่ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่ CTS มีความคลุมเครือและในกรณีที่มีการใช้โค้ดต้นฉบับอ้างอิงซ้ำ

CTS ออกแบบมาเพื่อใช้งานบนอุปกรณ์จริง CTS อาจมีข้อบกพร่องเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันแยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS เวอร์ชันต่างๆ สำหรับ Android 15

การติดตั้งใช้งานอุปกรณ์

  • [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-1] ขอแนะนำอย่างยิ่งให้กลไกการรับรองแฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อข้อมูลแบบไม่จำกัด เช่น โปรไฟล์ 802.11 หรือ PAN (เครือข่ายส่วนบุคคล) ของบลูทูธ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรองรับการดาวน์โหลด OTA ด้วยการอัปเดตแบบออฟไลน์ผ่านการรีบูต

การติดตั้งใช้งานอุปกรณ์ควรยืนยันว่าอิมเมจระบบเป็นไบนารีที่เหมือนกันกับผลลัพธ์ที่คาดไว้หลังจาก OTA การใช้งาน OTA ตามบล็อกในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง ซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้

นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ควรรองรับการอัปเดตระบบ A/B AOSP ใช้ฟีเจอร์นี้โดยใช้ HAL การควบคุมการบูต

หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากเปิดตัวแล้ว แต่อยู่ภายในอายุการใช้งานที่เหมาะสมของผลิตภัณฑ์ซึ่งพิจารณาโดยปรึกษากับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม ให้ทำดังนี้

  • [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่มีให้ใช้งานตามกลไกที่อธิบายไป

Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ หากระบบย่อยการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin อุปกรณ์จะดำเนินการดังนี้

12. บันทึกการเปลี่ยนแปลงของเอกสาร

สรุปการเปลี่ยนแปลงนิยามความเข้ากันได้ในรุ่นนี้

13. ติดต่อเรา

คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คุณคิดว่าเอกสารไม่ได้กล่าวถึง