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

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

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

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

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

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

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

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

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

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

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

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

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

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

มีการกำหนดรหัสข้อกำหนดสำหรับข้อกำหนด "ต้อง" แล้ว

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

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

  • รหัสประเภทอุปกรณ์ (ดูข้อมูลเพิ่มเติมใน 2. ประเภทอุปกรณ์)
    • C: หลัก (ข้อกำหนดที่มีผลกับการใช้งานอุปกรณ์ Android ทั้งหมด)
    • H: อุปกรณ์ Android แบบพกพา
    • T: อุปกรณ์ Android TV
    • ตอบ: การติดตั้งใช้งาน Android Automotive
    • 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 นี้ มีอุปกรณ์ 2-3 ประเภทที่มีระบบนิเวศการจัดจำหน่ายแอปพลิเคชันค่อนข้างดีกว่า

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

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

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

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

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

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

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

  • มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
  • หน้าจอมีขนาดตามจริงในช่วง 4 นิ้ว 3.3 นิ้ว (หรือ 2.5 นิ้วสำหรับการติดตั้งใช้งานอุปกรณ์ซึ่งจัดส่งใน API ระดับ 29 หรือ ก่อนหน้า) ถึง 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% หรือมากกว่าความหนาแน่นจริงของความหนาแน่น ของจอแสดงผลที่เกี่ยวข้อง

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

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

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

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

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

หากการใช้งานอุปกรณ์พกพาระบุว่ารองรับการแสดงช่วงไดนามิกกว้างถึง 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] ต้องมีการสนับสนุนสำหรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม
  • [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์ปกติและเหตุการณ์การกดค้างของฟังก์ชันกลับ (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 และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps สิ่งต่อไปนี้

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

หากการใช้งานอุปกรณ์พกพามีเครื่องวัดการหมุน 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 องศา
  • [7.4.3/H] ควรมีการรองรับบลูทูธและบลูทูธ LE

หากอุปกรณ์รองรับโปรโตคอล Wi-Fi Neighbor Awareness Networking (NAN) โดยประกาศ PackageManager.FEATURE_WIFI_AWARE และตำแหน่ง Wi-Fi (Wi-Fi Round Time — RTT) โดยประกาศ PackageManager.FEATURE_WIFI_RTT อุปกรณ์จะมีลักษณะดังนี้

  • [7.4.2.5/H-1-1] ต้องรายงานช่วงอย่างถูกต้องภายในช่วงแบนด์วิดท์ +/-1 เมตรที่แบนด์วิดท์ 160 MHz ที่เปอร์เซ็นไทล์ที่ 68 (ตามการคำนวณด้วยฟังก์ชันการกระจายสะสม) +/-2 เมตรที่แบนด์วิดท์ 80 MHz ที่เปอร์เซ็นไทล์ที่ 68+ Manager และแบนด์วิดท์ที่ 68 MHz ที่เปอร์เซ็นไทล์ที่ 68+

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

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

เริ่มข้อกำหนดใหม่

หากการใช้งานอุปกรณ์พกพาประกาศเป็น 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 ถึง องศา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.6.1/H-9-1] ต้องประกาศ 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")
  • ควรประกาศแฟล็กฟีเจอร์ android.hardware.ram.normal

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

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

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

  • [7.6.1/H-1-1] ต้องรองรับ ABI แบบ 32 บิตเท่านั้น

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

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

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

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

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

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

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

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

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

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

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

  • [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์เกี่ยวกับโค้ด HID ต่อไปนี้
การทำงาน การแมป บริบท ลักษณะการทำงาน
A หน้าการใช้งาน HID: 0x0C
การใช้งาน HID: 0x0CD
คีย์เคอร์เนล: KEY_PLAYPAUSE
คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE		 การเล่นสื่อ อินพุต: กดสั้นๆ
เอาต์พุต: เล่นหรือหยุดชั่วคราว
อินพุต: กดค้าง
เอาต์พุต: เปิดคำสั่งเสียง
ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ล็อกอยู่หรือหน้าจอปิดอยู่ ให้ส่ง android.speech.RecognizerIntent.ACTION_WEB_SEARCH
สายเรียกเข้า อินพุต: กดสั้นๆ
เอาต์พุต: รับสาย
อินพุต: กดค้าง
เอาต์พุต: ปฏิเสธสาย
สายที่สนทนาอยู่ อินพุต: กดสั้นๆ
เอาต์พุต: วางสาย
อินพุต: กดค้าง
เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน
หมื่นล้าน หน้าการใช้งาน 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 ด้วย การตั้งค่า "ไมโครโฟน" ส่วนเกินเป็น 0

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

  • [7.8.2.2/H-3-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ส่วนเกินที่ตั้งค่าเป็น 1

เมื่อมีการเรียกใช้ API AudioManager.get Devices() ขณะที่ต่ออุปกรณ์ต่อพ่วง 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.hardware.audio.output และ android.hardware.microphone สิ่งที่จะเกิดขึ้นมีดังนี้

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

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

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

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

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

  • [3.8.16/H-1-1] ต้องประกาศ แฟล็กฟีเจอร์ 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 รวมถึงช่องที่ระบุโดย API ของ Control

  • [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 แอปจะต้องแสดงผลช่องที่ระบุตามที่ ControlsProviderService API ระบุไว้ รวมถึงช่องที่ระบุโดย Control API
  • [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

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

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

เริ่มข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์ช่วยให้ผู้ใช้โทรออกได้ทุกประเภท

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

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

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

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

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

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

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

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

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

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

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

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

  • [8.5/H-0-1] ต้องมี ค่าใช้จ่ายของผู้ใช้ในเมนูการตั้งค่า เพื่อดูแอปทั้งหมดที่มีบริการที่ทำงานอยู่เบื้องหน้าหรืองานที่เริ่มต้นโดยผู้ใช้ รวมถึงระยะเวลาของบริการแต่ละบริการนับตั้งแต่เริ่มตามที่อธิบายไว้ในเอกสาร SDK และความสามารถในการหยุดแอปที่เรียกใช้บริการที่ทำงานอยู่เบื้องหน้าหรืองานที่เริ่มต้นโดยผู้ใช้
    • แอปบางแอปอาจได้รับการยกเว้นไม่ต้องถูกหยุดหรือระบุไว้ในราคาของผู้ใช้ตามที่อธิบายไว้ในเอกสาร 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.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, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
  • [9.11/H-0-4] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
  • [9.11/H-0-5] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

  • [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคำที่นิยมส่งข้อมูลไปยังระบบ ContentCaptureService หรือบริการจดจำคำพูดในอุปกรณ์ที่สร้างโดย SpeechRecognizer#createOnDeviceSpeechRecognizer() เท่านั้น
  • [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคำสั่งให้ดำเนินการจะส่งได้เฉพาะข้อมูลเสียงไมค์หรือข้อมูลที่ได้มาจากเซิร์ฟเวอร์ของระบบผ่านทาง API ของ HotwordDetectionService หรือไปยัง ContentCaptureService ผ่านทาง API ของ ContentCaptureManager
  • [9.8/H-1-3] ต้องไม่ให้เสียงไมโครโฟนที่นานกว่า 30 วินาทีสำหรับคำขอที่ทริกเกอร์ด้วยฮาร์ดแวร์แต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-4] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับคำขอแต่ละรายการไปยังบริการตรวจจับคำสั่งให้ดำเนินการ
  • [9.8/H-1-5] ต้องไม่ให้เสียงไมค์ที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีแก่บริการโต้ตอบด้วยเสียงหรือเอนทิตีที่คล้ายกัน
  • [9.8/H-1-6] ต้องไม่ส่งข้อมูลเกิน 100 ไบต์ออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์คำสั่งที่ประสบความสำเร็จแต่ละรายการ ยกเว้นข้อมูลเสียงที่ส่งผ่าน HotwordAudioStream
  • [9.8/H-1-7] ต้องไม่ส่งข้อมูลมากกว่า 5 บิตออกจากบริการตรวจจับคำสั่งให้ดำเนินการในผลลัพธ์ของคำสั่งให้ดำเนินการเชิงลบแต่ละรายการ
  • [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() พร้อมกับข้อความ ระบุแหล่งที่มาที่เกี่ยวข้อง

หากการใช้งานอุปกรณ์พกพาประกาศเป็น android.hardware.camera.any สิ่งที่จะเกิดขึ้นมีดังนี้

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

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

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

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

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

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

2.2.7 ชั้นเรียนประสิทธิภาพของสื่อแบบมือถือ

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

2.2.7.1 สื่อ

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

เริ่มข้อกำหนดใหม่

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

  • [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์ ที่เรียกใช้พร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันกับ 3 เซสชันที่ความละเอียด 1080p AVS และ 3 เซสชันที่ความละเอียด 4k ยกเว้น 30.fps ตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับอินสแตนซ์ 6 ตัวที่ 1080p30fps ด้วย
  • [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ที่เรียกใช้พร้อมกันได้ในการรวมตัวแปลงรหัสอย่างไรผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 อินสแตนซ์ (AVC, HEVC, VP9, AV1 ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันกับ 4 เซสชันที่ความละเอียด 1080p ที่ความละเอียด 30 fps และ 2 เซสชันที่ความละเอียด 4k AV1.s ยกเว้น AV1.s ตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับอินสแตนซ์ 6 ตัวที่ 1080p30fps ด้วย
  • [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์และ เซสชันโปรแกรมถอดรหัสที่เรียกใช้พร้อมกันในชุดค่าผสมใดๆ ของตัวแปลงรหัสผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-6] ต้องรองรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ 8 บิต (SDR) 6 อินสแตนซ์ และเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันกับ 3 เซสชันที่ความละเอียด 4K@30fps ความละเอียด (ยกเว้น AV1) โดยไม่เกิน 302 เซสชัน โดยเป็นโปรแกรมเปลี่ยนไฟล์ที่มีความละเอียดไม่เกิน 302 เซสชัน ตัวแปลงรหัส AV1 ต้องรองรับความละเอียด 1080p เท่านั้น แต่ยังต้องรองรับอินสแตนซ์ 6 ตัวที่ 1080p30fps ด้วย
  • [5.1/H-1-19] ต้องรองรับตัวถอดรหัสวิดีโอฮาร์ดแวร์ 10 บิต (HDR) 3 อินสแตนซ์และเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 4K@30fps (ยกเว้นว่า AV1) จะมีการกำหนดค่าไม่เกิน 1A0 ในรูปแบบอินพุต GL0 คุณไม่จำเป็นต้องสร้างข้อมูลเมตา 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
  • [5.1/H-1-9] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 2 อินสแตนซ์ (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 4K@30 FPS (ยกเว้น AV1) สำหรับเนื้อหา HDR ทั้ง 8 บิต (SDR) และ 10 บิต เซสชันตัวแปลงรหัส AV1 จำเป็นต้องรองรับความละเอียด 1080p เท่านั้น แม้ว่าข้อกำหนดนี้ต้องใช้ความละเอียดระดับ 4K ก็ตาม
  • [5.1/H-1-10] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ไม่ปลอดภัย 3 อินสแตนซ์ ร่วมกับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ที่ปลอดภัย 1 อินสแตนซ์ (ทั้งหมด 4 อินสแตนซ์) (AVC, HEVC, VP9, AV1 หรือใหม่กว่า) ในชุดค่าผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันกับ 3 เซสชันที่ความละเอียด 4K-secure-0fps สูงสุด 1 เซสชัน ซึ่งจะมีความละเอียด 4K-secure@30 ที่ความละเอียด 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
  • [5.1/H-1-14] ต้องรองรับตัวถอดรหัสฮาร์ดแวร์ AV1 Main 10, ระดับ 4.1 และเนื้อฟิล์ม
  • [5.1/H-1-15] ต้องมีตัวถอดรหัสวิดีโอฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ 4K60
  • [5.1/H-1-16] ต้องมีโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์อย่างน้อย 1 โปรแกรมที่รองรับ 4K60
  • [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 ในโหมด Callback ที่มีเวลาในการตอบสนองต่ำ แอปควรใช้ Java AudioTrack สำหรับการกำหนดค่าสตรีมมิง ทั้งสำหรับการกำหนดค่าสตรีมมิงและเวลาในการตอบสนองต่ำ ซิงก์เอาต์พุต HAL ควรยอมรับ AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT หรือ AUDIO_FORMAT_PCM_FLOAT สำหรับรูปแบบเอาต์พุตเป้าหมาย
  • [5.6/H-1-4] ต้องรองรับอุปกรณ์เสียง USB ที่มีช่องสัญญาณ >=4 ช่อง (ตัวควบคุมของดีเจจะใช้สำหรับการแสดงตัวอย่างเพลง)
  • [5.6/H-1-5] ต้องรองรับอุปกรณ์ MIDI ที่เป็นไปตามข้อกำหนดของคลาสและประกาศแฟล็กฟีเจอร์ 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 28
จำนวนตัวอย่างย่อยขั้นต่ำ - VP9 9
จำนวนตัวอย่างย่อยขั้นต่ำ - AV1 288
ขนาดบัฟเฟอร์ของตัวอย่างย่อยขั้นต่ำ 1 MiB
ขนาดบัฟเฟอร์คริปโตทั่วไปขั้นต่ำ 500 KiB
จํานวนเซสชันที่เกิดขึ้นพร้อมกันขั้นต่ำ 30
จำนวนคีย์ขั้นต่ำต่อเซสชัน 20
จำนวนคีย์ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 80
จำนวนคีย์ DRM ทั้งหมดขั้นต่ำ (เซสชันทั้งหมด) 6
ขนาดข้อความ 16 KiB
เฟรมที่ถอดรหัสต่อวินาที 60 FPS
  • [5.1/H-1-17] ต้องมีตัวถอดรหัสรูปภาพฮาร์ดแวร์อย่างน้อย 1 ตัวที่รองรับ AVIF โปรไฟล์พื้นฐาน
  • [5.1/H-1-18] ต้องรองรับโปรแกรมเปลี่ยนไฟล์ AV1 ซึ่งเข้ารหัสได้สูงสุดความละเอียด 480p ที่ 30 FPS และ 1 Mbps
  • [5.12/H-1-1] ต้อง [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.os.Build.VERSION_CODES.U สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS และมีการรองรับโปรแกรมเปลี่ยนไฟล์ AVC หรือ HEVC ด้วยฮาร์ดแวร์

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

2.2.7.2 กล้อง

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

เริ่มข้อกำหนดใหม่

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

  • [7.5/H-1-1] ต้องมีกล้องหลังตัวหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล ซึ่งรองรับการบันทึกวิดีโอที่ 4k@30fps กล้องหลังตัวหลักคือกล้องหลังที่มีรหัสกล้องต่ำสุด
  • [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 6 เมกะพิกเซลและรองรับการบันทึกวิดีโอที่ 1080p@30 FPS กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
  • [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] ต้องมีเวลาในการตอบสนองในการจับภาพ Camera2 JPEG < 1,000 900 มิลลิวินาที สำหรับความละเอียด 1080p ตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูเฟรมตัวอย่างแรก) < 500 มิลลิวินาทีซึ่งวัดโดยการทดสอบประสิทธิภาพของกล้อง CTS ภายใต้เงื่อนไขแสงของ ITS (3,000 K) สำหรับกล้องหลักทั้ง 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 มุมกว้างพิเศษที่หันไปในทิศทางเดียวกัน
  • [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) สำหรับกล้องหลัก

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

2.2.7.3 ฮาร์ดแวร์

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

เริ่มข้อกำหนดใหม่

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

  • [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
  • [7.1.1.3/H-2-1] ต้องมีความหนาแน่นของหน้าจออย่างน้อย 400 dpi
  • [7.1.1.3/H-3-1] ต้องมีจอแสดงผล HDR ที่รองรับค่าเฉลี่ยอย่างน้อย 1,000 นิต
  • [7.6.1/H-2-1] ต้องมีหน่วยความจำจริงอย่างน้อย 8 GB

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

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

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

เริ่มข้อกำหนดใหม่

หากการใช้งานอุปกรณ์พกพาแสดงผล android.os.Build.VERSION_CODES.U สำหรับ 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/วินาที

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

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

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

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

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

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

2.3.1 ฮาร์ดแวร์

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

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

หากการใช้งานอุปกรณ์โทรทัศน์มีเครื่องวัดการหมุน 3 แกน การใช้งานจะดำเนินการดังนี้

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

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

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

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

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

หากอุปกรณ์ทีวีเป็นแบบ 32 บิต

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

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

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

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

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

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

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

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

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

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

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

  • [5.3.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ Main Tier หลัก 10 ระดับ 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 สำหรับจอแสดงผลภายนอก ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอในภูมิภาคที่ขายอุปกรณ์ ต้องตั้งค่าโหมดเอาต์พุต 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] ต้องมีการติดตั้งใช้งาน API ของ android.webkit.Webview ให้เสร็จสมบูรณ์

หากใช้งานอุปกรณ์ 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 ของบุคคลที่สาม

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

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

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

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

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

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

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

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

  • [8.3/T-1-3] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ 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] จะต้องทำให้การใช้พลังงานนี้พร้อมใช้งาน ผ่านคำสั่ง Shell 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, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและสูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
  • [9.11/T-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
  • [9.11/T-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

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

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

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

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

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

อุปกรณ์ Android Watch หมายถึงการใช้งานอุปกรณ์ Android ที่มีจุดประสงค์เพื่อสวมใส่บนร่างกาย หรืออาจเป็นบนข้อมือ

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

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

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

2.4.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์นาฬิกามีเครื่องวัดการหมุน 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] ต้องประกาศฟีเจอร์ android.hardware.type.watch
  • [3/W-0-2] ต้องรองรับ uiMode = UI_mode_TYPE_Wwatch
  • [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดยจุดประสงค์ของแอปพลิเคชันต่อไปนี้ที่แสดงที่นี่

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

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

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

2.4.5 โมเดลการรักษาความปลอดภัย

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

  • [9/W-0-1] ต้องประกาศฟีเจอร์ android.hardware.security.model.compatible

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

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

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

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

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

2.5.1 ฮาร์ดแวร์

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

  • [7.1.1.1/A-0-1] ต้องมีหน้าจอขนาดแนวทแยงมุมจริงอย่างน้อย 6 นิ้ว
  • [7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจออย่างน้อย 750 dp x 480 dp
  • [7.2.3/A-0-1] ต้องระบุฟังก์ชัน "หน้าแรก" และอาจมีฟังก์ชัน "กลับ" และ "ล่าสุด"
  • [7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์ปกติและเหตุการณ์การกดค้างของฟังก์ชันกลับ (KEYCODE_BACK) ไปยังแอปพลิเคชันเบื้องหน้า
  • [7.3/A-0-1] ต้องใช้และรายงาน GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED และ PARKING_BRAKE_ON
  • [7.3/A-0-2] ค่าของการแจ้ง NIGHT_MODE ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตเซ็นเซอร์แสงแวดล้อม เซ็นเซอร์แสงแวดล้อมที่อยู่ข้างใต้อาจเหมือนกับ Photometer
  • [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] STRONGLY_RECOMMENDED รวมตัวตรวจวัดความเร่ง 3 แกนและเครื่องวัดการหมุน 3 แกน

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับ 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 และส่งออกสัญลักษณ์ทั้งหมด

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

  • [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] ขอแนะนำอย่างยิ่งให้กำหนดค่าช่วงการวัดของอุปกรณ์วัดการหมุนเป็น +/-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

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

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

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

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

  • [7.5/A-1-1] ต้องไม่มีกล้องมุมมองภายนอกที่เข้าถึงได้ผ่าน Android Camera API เว้นแต่ว่าจะเป็นไปตามข้อกำหนดหลักของกล้อง

  • [7.5/A-SR-1] ขอแนะนำเป็นอย่างยิ่งว่าอย่าหมุนหรือมิเรอร์ภาพตัวอย่างจากกล้อง

  • [7.5/A-SR-2] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 เมกะพิกเซล

  • ควรมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)

  • อาจมีการใช้ฮาร์ดแวร์โฟกัสอัตโนมัติหรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง

หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว และโหลดบริการระบบมุมมองภายนอก (EVS) กล้องจะทำหน้าที่ดังนี้

  • [7.5/A-2-1] ต้องไม่หมุนหรือมิเรอร์ในแนวนอนของตัวอย่างกล้อง

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

  • อาจมีกล้องอย่างน้อย 1 ตัวที่พร้อมใช้งานกับแอปพลิเคชันของบุคคลที่สาม

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

  • [7.5/A-3-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any
  • [7.5/A-3-2] ต้องไม่ประกาศว่ากล้องเป็นกล้องของระบบ
  • อาจรองรับกล้องภายนอกที่อธิบายไว้ในหัวข้อ 7.5.3
  • อาจมีฟีเจอร์ (เช่น การโฟกัสอัตโนมัติ ฯลฯ) ที่ใช้ได้กับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

เริ่มข้อกำหนดใหม่

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

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

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

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

หากการใช้งานอุปกรณ์ยานยนต์มีกล้องอย่างน้อย 1 ตัวที่หันหน้าจอได้ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.* เนมสเปซ

หากการติดตั้งใช้งานอุปกรณ์ Automotive มี 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] ต้องมีการติดตั้งใช้งาน API ของ android.webkit.Webview ให้เสร็จสมบูรณ์

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

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

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

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

2.5.5 โมเดลการรักษาความปลอดภัย

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

เริ่มข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์ประกาศ 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 สิทธิ์ ที่มีตัวระบุ CDD [C-4-X][C-3-X]
  • [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, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
  • [9.11/A-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น "ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อก" ต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกออกมาเท่านั้นสำหรับการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
  • [9.11/A-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU ที่ระบุอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

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

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

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

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

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

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

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

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

  • มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่

  • มีขนาดการแสดงผลของหน้าจอใหญ่กว่า 7 นิ้วและน้อยกว่า 18 นิ้ว โดยวัดในแนวทแยง

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

2.6.1 ฮาร์ดแวร์

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

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

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

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

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

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

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

  • [7.7.1/Tab] อาจใช้ Android Open Accessory (AOA) API

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

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

ข้อกำหนดเกี่ยวกับ Virtual Reality ใช้ไม่ได้กับแท็บเล็ต

2.6.2 โมเดลการรักษาความปลอดภัย

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

โปรดดูหัวข้อ [9.11]

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

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

หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและประกาศแฟล็กฟีเจอร์ 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 ความเข้ากันได้กับ API ที่มีการจัดการ

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

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

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

  • [C-0-2] ต้อง support/รักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมดที่ทำเครื่องหมายโดยคำอธิบายประกอบ 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 แต่ละรายการในรายการแบบจำกัดเดียวกันกับที่ระบุผ่านแฟล็กชั่วคราวและรายการที่ปฏิเสธในเส้นทาง prebuilts/runtime/appcompat/hiddenapi-flags.csv สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP

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

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

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

3.2 ความเข้ากันได้ของ Soft API

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

3.2.1. สิทธิ์

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

3.2.2 พารามิเตอร์บิลด์

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

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

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

เช่น

acme/myproduct/
mydevice:14/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_ผู้ผลิต การแลกเปลี่ยนชื่อของผู้ผลิตระบบหลักบนชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SOC รายเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เกี่ยวกับค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต ต้องตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ]+)" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ช่องนี้ต้องไม่มีการเปลี่ยนแปลงตลอดอายุการใช้งานผลิตภัณฑ์
โมเดล SOC_MODEL ชื่อรุ่นของระบบหลักบนชิป (SOC) ที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มี SOC รุ่นเดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อใช้ค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ._/+-]+)$" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยช่องว่าง และต้องไม่เท่ากับ "ไม่ทราบ" ช่องนี้ต้องไม่มีการเปลี่ยนแปลงในระหว่างอายุการใช้งานของผลิตภัณฑ์
MODEL ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่อของอุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ เว้นแต่ช่องต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") โดยช่องนี้ต้องไม่มีการเปลี่ยนแปลงในระหว่างอายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์ ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ผู้ใช้ปลายทางไม่จำเป็นต้องอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ "ต้องไม่เปลี่ยนแปลง" ตลอดอายุการใช้งานของผลิตภัณฑ์
ODM_SKU ค่าที่ไม่บังคับซึ่งผู้ให้บริการอุปกรณ์เลือกซึ่งมี SKU (สต็อกคีปปิ้งยูนิต) ซึ่งใช้เพื่อติดตามการกำหนดค่าเฉพาะของอุปกรณ์ เช่น อุปกรณ์ต่อพ่วงใดๆ ที่รวมอยู่ในอุปกรณ์เมื่อจำหน่าย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "[0-9A-Za-z.,_-])"
ซีเรียล ต้องส่งคืน "UNKNOWN"
แท็ก รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ให้บริการอุปกรณ์เลือกให้แยกความแตกต่างระหว่างบิลด์เพิ่มเติม แท็กต้องเข้ารหัสได้เป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองบนแพลตฟอร์ม Android 3 รายการทั่วไป ได้แก่ Release-key, dev-key และ test-key
เวลา ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์
ประเภท ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android 3 แบบ ได้แก่ user, userdebug หรือ eng
ผู้ใช้ ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบเฉพาะของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่างเปล่า ("")
แพตช์ด้านความปลอดภัย ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องหมายความว่าบิลด์ไม่มีช่องโหว่ต่อปัญหาต่างๆ ที่อธิบายไว้ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ ค่านี้ต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กำหนดซึ่งบันทึกไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android หรือใน คำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่เหมือนกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android โดยต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("")
รองเท้าบู๊ต ค่าที่ผู้ให้บริการอุปกรณ์เลือกซึ่งระบุเวอร์ชัน Bootloader ภายในเฉพาะที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$"
getRadioVersion() ต้อง (หรือส่งคืน) ค่าที่เลือกโดยเครื่องมือของอุปกรณ์ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-,]+$”
getSerial() ต้อง (หรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ซึ่งต้องมีพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่ใช้ MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9]+$”

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

3.2.3.1 Intent ทั่วไปของแอปพลิเคชัน

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

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

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

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

3.2.3.2 ความละเอียดของความตั้งใจ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เริ่มข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.uicc หรือ android.hardware.nfc.ese ระบบจะดำเนินการต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่กำหนดไว้อย่างน้อย 1 รายการ
  • [C-0-2] ต้องรวมการรองรับโค้ดที่เรียกใช้ในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกโค้ดแบบเนทีฟ โดยใช้อรรถศาสตร์มาตรฐานของ Java Native Interface (JNI)
  • [C-0-3] ต้องเข้ากันได้กับต้นทาง (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) ด้วยไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
  • [C-0-5] ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชันแบบเนทีฟ (ABI) ที่อุปกรณ์รองรับผ่านพารามิเตอร์ android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS และ android.os.Build.SUPPORTED_64_BIT_ABIS โดยคั่นแต่ละรายการด้วยคอมมาของ ABI โดยเรียงลำดับจากมากที่สุดไปน้อยที่สุด

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

    • armeabi (NDK ไม่รองรับการกําหนดเป้าหมายอีกต่อไป)
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

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

    • libaaudio.so (รองรับเสียงแบบเสียงเนทีฟ)
    • 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 (API เครือข่ายประสาทเทียม)
    • libOpenMAXAL.so (การสนับสนุน OpenMAX AL 1.0.1)
    • libOpenSLES.so (การสนับสนุนระบบเสียง OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (การสนับสนุนขั้นต่ำสำหรับ C++)
    • libvulkan.so (วัลคาน)
    • libz (การบีบอัด Zlib)
    • อินเทอร์เฟซ JNI

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

  • [C-0-9] ต้องระบุไลบรารีเพิ่มเติมที่ไม่ใช่ AOSP ที่เปิดเผยกับแอปของบุคคลที่สามโดยตรงใน /vendor/etc/public.libraries.txt

  • [C-0-10] ต้องไม่แสดงไลบรารีแบบเนทีฟอื่นๆ ที่มีการใช้งานและให้มีไว้ใน AOSP เป็นไลบรารีระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป เนื่องจากมีการจองไว้

  • [C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่กำหนดไว้ใน NDK ผ่านไลบรารี libGLESv3.so โปรดทราบว่าแม้สัญลักษณ์ทั้งหมดจะต้องมี แต่ส่วนที่ 7.1.4.1 ได้อธิบายข้อกำหนดโดยละเอียดว่าควรจะนำฟังก์ชันที่เกี่ยวข้องแต่ละรายการไปใช้เมื่อใด

  • [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับ Vulkan 1.0 หลัก สัญลักษณ์ของฟังก์ชัน 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 บิต

การนำอุปกรณ์ไปใช้รายงานการรองรับ ABI ของ armeabi สิ่งที่จะเกิดขึ้นมีดังนี้

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

หากการใช้งานอุปกรณ์รายงานการรองรับ ABI ของ armeabi-v7a สำหรับแอปที่ใช้ 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

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

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

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

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML เช่น 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 ต้นทาง
    • การใช้งานอุปกรณ์อาจเว้น "อุปกรณ์เคลื่อนที่" ในสตริง User Agent

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

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

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

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

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

  • [C-1-1] ต้องรองรับ API แต่ละรายการต่อไปนี้ที่เชื่อมโยงกับ HTML5
  • [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ HTML5/W3C IndexedDB API โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ IndexedDB แทน Webstorage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันในอนาคต
  • อาจจัดส่งสตริง User Agent ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
  • ควรใช้การรองรับ HTML5 ให้มากที่สุดในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ทั้งนี้จะขึ้นอยู่กับแอปพลิเคชันเบราว์เซอร์ WebKit ของอัปสตรีมหรือการแทนที่ของบุคคลที่สาม)

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

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

3.5 ความเข้ากันได้ด้านพฤติกรรมของ API

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

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

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

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

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

  • [C-1-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดในข้อ 3.5.1 ยกเว้น [C-1-6] และ [C-1-3]
  • [C-1-2] ต้องใช้ข้อจำกัดในแอปสำหรับผู้ใช้เมื่อมีหลักฐานว่าผู้ใช้ไม่ได้ใช้แอปเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้กำหนดระยะเวลานี้อย่างน้อย 1 เดือน การใช้งานต้องถูกกำหนดโดยการโต้ตอบของผู้ใช้อย่างชัดแจ้งผ่าน UsageStats#getLastTimeVisible() หรืออะไรก็ตามที่จะทำให้แอปออกจากสถานะที่บังคับให้หยุด ซึ่งรวมถึงการเชื่อมโยงบริการ การเชื่อมโยงผู้ให้บริการเนื้อหา การออกอากาศที่ชัดเจน และอื่นๆ ซึ่งจะมีการติดตามโดย API UsageStats#getLastTimeAnyComponentd() ใหม่
  • [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 ในเนมสเปซข้างต้น "องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือโครงสร้างที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง

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

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

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

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

ผู้ใช้อุปกรณ์อาจเพิ่ม API ที่กำหนดเองในภาษาหลักที่ไม่ใช่ API ของ NDK ได้ แต่ 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 Format และระบบการจัดการแพ็กเกจของการติดตั้งข้อมูลอ้างอิง

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

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

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

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

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

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

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

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

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

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

3.8.2 วิดเจ็ต

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

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

  • [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม android.software.app_widgets

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

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

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

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

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

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

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

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

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

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

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

3.8.4 Assist API

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

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

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

3.8.5 การแจ้งเตือนและขนมปังปิ้ง

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

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

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

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

3.8.6 ธีม

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

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

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

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

  • [C-1-3] ต้องตั้งค่าชุดแบบอักษร "sans-serif" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือเสนอค่าใช้จ่ายในการเปลี่ยนแบบอักษรที่ใช้ในชุดแบบอักษร "sans-serif" เป็น 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] ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ความแรงของสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบออกให้ ยกเว้นกรณีที่ไอคอนแสดงสถานะที่เป็นปัญหาหรือแอปขอแถบสถานะไฟโดยใช้ธง 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] ต้องรายงานแฟล็กฟีเจอร์แพลตฟอร์ม 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 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)

ดูส่วนที่ 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 แบบเต็มของภาษาละติน กรีก และซีริลลิก รวมถึงช่วง Latined 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 ออกหรือเขียนทับแบบอักษร Unicode
  • [C-2-3] ต้องแสดงผลข้อความด้วยแบบอักษรที่ไม่สอดคล้องกับ Unicode เฉพาะกรณีที่มีการระบุรหัสภาษาที่มี script code 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 ผ่านทาง API ของ setAspectRatio()
  • [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

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 Content Capture และ App Search

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

  • [C-1-1] ต้องปกปิดตัวอย่างที่ผู้ใช้เห็นได้

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

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

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

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

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

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

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

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

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

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

  • [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 ดังต่อไปนี้

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

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

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

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

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

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

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

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

  • [C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ไปยัง DPC ของโปรไฟล์ส่วนตัวเมื่อมีการสร้างเจ้าของโปรไฟล์ ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม

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

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

  • [C-1-1] ต้องรองรับโปรไฟล์ที่มีการจัดการผ่าน API ของ android.app.admin.DevicePolicyManager
  • [C-1-2] ต้องอนุญาตให้สร้างโปรไฟล์ที่มีการจัดการได้ 1 รายการเท่านั้น
  • [C-1-3] ต้องใช้ป้ายไอคอน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ รวมถึงองค์ประกอบ UI อื่นๆ ที่มีตราสถานะ เช่น ล่าสุดและการแจ้งเตือน
  • [C-1-4] ต้องแสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อระบุว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการเมื่อใด
  • [C-1-5] ต้องแสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการหากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ภายในโปรไฟล์ที่มีการจัดการ
  • [C-1-6] เมื่อมีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีการแสดงผลใน Intent ตัวเลือก เพื่อให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากถูกเปิดใช้งานโดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
  • [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 ตามที่อธิบายไว้ข้างต้น

หากมีการกำหนดชื่อแพ็กเกจสำหรับ 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 เฟรมเวิร์กการแก้ปัญหาของ Device Policy

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

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

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

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

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

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

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

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

3.11 Text-to-Speech

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

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

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

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

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

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

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

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

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

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

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

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

3.14 UI สื่อ

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

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

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

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

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

3.15 Instant Apps

หากอุปกรณ์รองรับ Instant Apps แอปจะต้องเป็นไปตามข้อกำหนดต่อไปนี้

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

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

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

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

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

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

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

3.17. แอปขนาดใหญ่

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

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

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

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

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

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

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

บัญชีเริ่มต้นในเครื่อง: บัญชีสำหรับรายชื่อติดต่อดิบที่จัดเก็บไว้ในอุปกรณ์เท่านั้น และไม่ได้เชื่อมโยงกับบัญชีใน Account Manager ซึ่งสร้างขึ้นด้วยค่า 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 ได้รับการตั้งค่าเป็นจริง) แม้ว่าพารามิเตอร์ CALLER\_IS\_SYNCADAPTER จะตั้งค่าเป็น "เท็จ" หรือไม่ได้ระบุ

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

  • [C-0-4] ต้องไม่อนุญาตให้แอปอื่นนอกเหนือจาก "โปรแกรมติดตั้งระเบียน" ปัจจุบันของแพ็กเกจทำการถอนการติดตั้งแอปโดยไม่มีการยืนยันจากผู้ใช้ ตามที่ระบุไว้ใน SDK สำหรับสิทธิ์ DELETE_PACKAGE ข้อยกเว้นเดียวคือแอปของผู้ยืนยันแพ็กเกจระบบที่จัดการ ความตั้งใจ PACKAGE_NEEDS_VERIFICATION และจุดประสงค์ในการจัดการแอปของตัวจัดการพื้นที่เก็บข้อมูล ACTION_MANAGE_STORAGE

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

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

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

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

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

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

  • [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] โอปัส

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

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

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
  • MP3 [C-1-6]
  • [C-1-7] MIDI
  • [C-1-8] เวอร์บี
  • [C-1-9] PCM/WAVE รวมรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และช่อง 8 ช่อง โปรดทราบว่าข้อกำหนดนี้มีไว้สำหรับการถอดรหัสเท่านั้น และอนุญาตให้อุปกรณ์ลดตัวอย่างและดาวน์มิกซ์ได้ในระยะการเล่น
  • [C-1-10] โอปัส

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

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

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

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

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

  • อาจรองรับความดังและการควบคุมช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิกแบบ 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 บิตผ่าน API ของ android.media.MediaCodec

หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต 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 - Wide Band Speech Codec 3GPP (.3gp)
FLAC สำหรับทั้งโปรแกรมเปลี่ยนไฟล์และเครื่องถอดรหัส: ต้องมีการรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย รองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง 24 บิตของ FLAC ต้องใช้งานได้กับการกำหนดค่าเสียงแบบลอย
  • 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 และ XMF สำหรับอุปกรณ์เคลื่อนที่ รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody
  • ประเภท 0 และ 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (.iMelody)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE ตัวแปลงรหัส PCM ต้องรองรับ PCM เชิงเส้น 16 บิตและแบบลอย 16 บิต เครื่องมือแยก WAVE ต้องรองรับ PCM เชิงเส้น 16 บิต, 24 บิต, 32 บิต และลอยตัว 32 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อัตราการสุ่มตัวอย่างต้องรองรับตั้งแต่ 8 kHz ถึง 192 kHz WAVE (.wav)
Opus การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz
การเข้ารหัส: รองรับเนื้อหาโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 1400, 1200 และ 1200 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
  • GIF [C-0-2]
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] ดิบ
  • [C-0-7] AVIF (โปรไฟล์พื้นฐาน)

หากอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC * [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)

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

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

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

รูปแบบ/ตัวแปลงรหัส รายละเอียด รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG ฐาน +โพรเกรสซีฟ JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
แบบข้อมูลดิบ ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ HEIF (.heif), HEIC (.heic)
AVIF (โปรไฟล์พื้นฐาน) รูปภาพ คอลเล็กชันรูปภาพ โปรไฟล์ Baseline ของลำดับรูปภาพ คอนเทนเนอร์ 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 แบบระนาบหรือแบบกึ่งฉากอย่างน้อย 1 รายการ: COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) เราขอแนะนำเป็นอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

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

  • [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, ถอดรหัสเท่านั้น)
HEVC ของ H.265 ดูรายละเอียดในส่วนที่ 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 การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม และตัวแปลงรหัส 2.0 ซึ่งเป็น API การเร่งสื่อมัลติมีเดียแบบโอเวอร์เฮดต่ำ

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

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

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

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

หากอุปกรณ์รองรับตัวแปลงรหัสตัวแปลงรหัส 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] ต้องส่งค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่าน API ของ MediaCodecInfo

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

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

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

  • [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) SD (คุณภาพสูง) HD 720p HD 1080p UHD
ความละเอียดของวิดีโอ
  • 176 x 144 พิกเซล (H263, MPEG2, MPEG4)
  • 352 x 288 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4, H263, MPEG2)
  • 320 x 180 พิกเซล (VP8, VP8)
  • 320 x 240 พิกเซล (อื่นๆ)
  • 704 x 576 พิกเซล (H263)
  • 640 x 360 พิกเซล (VP8, VP9)
  • 640 x 480 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4)
  • 720 x 480 พิกเซล (อื่นๆ, 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 การเข้ารหัสวิดีโอ

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

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

เริ่มข้อกำหนดใหม่

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

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

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

  • [C-6-1] ต้อง [C-SR-2] แนะนำอย่างยิ่งให้ อัตราบิตเป้าหมายไม่เกิน 15% ในหน้าต่างเลื่อน 1 วินาที

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

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

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

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

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

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

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุปลั๊กอินสำหรับ API การแปลงที่ราบรื่นเพื่อแปลงจากรูปแบบ HDR เป็นรูปแบบ SDR

5.2.1 H.263

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

  • [C-1-1] ต้องรองรับความละเอียด QCIF (176 x 144) โดยใช้ Baseline Profile ระดับ 45 คุณจะระบุความละเอียด SQCIF หรือไม่ก็ได้
  • ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกสำหรับโปรแกรมเปลี่ยนไฟล์ที่รองรับ

5.2.2 H.264

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

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

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

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

5.2.3 VP8

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

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

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

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

5.2.4 VP9

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

  • [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 ผ่าน API สื่อ

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

5.2.5 H.265

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

  • [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3 สูงสุด 512 x 512
  • ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
  • [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] ต้องรองรับความละเอียดระดับ Baseline Profile 30 (ความละเอียด CIF, QCIF และ SQCIF @ 30fps 384kbps) และระดับ 45 (ความละเอียด QCIF และ SQCIF @ 30fps 128kbps)

5.3.3 MPEG-4

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

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

5.3.4 H.264

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

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

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

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

5.3.5 H.265 (HEVC)

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

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

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

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

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

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

  • การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ

หากการนำอุปกรณ์ไปใช้งานอ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) ผ่าน 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
  • [C-1-2] ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องในหน้าจอของอุปกรณ์หรือ บนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
  • [C-1-3] ต้องตั้งค่ารหัสแทร็กของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับรหัสแทร็กของเลเยอร์ Dolby Vision แบบรวม

5.3.9 AV1

หากอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำงานดังนี้

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

เริ่มข้อกำหนดใหม่

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

  • [C-1-1] ต้องสนับสนุนโปรไฟล์หลัก ซึ่งรวมถึงเนื้อหาแบบ 8 บิตและ 10 บิต

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

  • [C-2-1] ต้องถอดรหัสโปรไฟล์การถอดรหัสวิดีโอความละเอียดสูง 720p เป็นอย่างน้อยจากตารางด้านล่างได้เมื่อความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่า 720p
  • [C-2-2] ต้องถอดรหัสโปรไฟล์การถอดรหัสวิดีโอความละเอียดสูง 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 INPUT ที่เปิดได้สำเร็จ อย่างน้อยที่สุด ต้องมีการสนับสนุนลักษณะต่อไปนี้:

    • รูปแบบ: PCM เชิงเส้น 16 บิต
    • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
    • ช่องสัญญาณ: โมโน
    • แหล่งที่มาของเสียง: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED หรือ VOICE_PERFORMANCE และยังใช้กับค่าที่กำหนดล่วงหน้าซึ่งเทียบเท่ากับอินพุตใน AAudio ด้วย เช่น AAUDIO_INPUT_PRESET_CAMCORDER

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

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

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

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

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

    • รูปแบบ: 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 ของเนื้อหาเสียงดิบ จะมีผลดังนี้

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

  • ควรตั้งค่าความไวของอินพุตเสียงให้แหล่งสัญญาณเสียงไซนัสโซอิดัล 1000 Hz เล่นที่ระดับความดันเสียง (SPL) 90 dB (วัดที่ระยะห่าง 30 ซม.) ข้างๆ ไมโครโฟน) ให้การตอบสนองสัญญาณเสียงในอุดมคติตั้งแต่ 1-5 บิต ต่อไมโครโฟน 1200-2503 สำหรับการรับรู้เสียงแบบ 30 dB และระดับเสียง 30 dB (วัดที่ระยะ 30 ซม.) ข้างๆ ไมโครโฟน) ให้การตอบสนองเสียงในอุดมคติของตัวอย่างเสียง RMS 2503 ถึงระดับ 170bd30 สำหรับตัวอย่างเสียง 170-2503 ในช่วง 17 ดักซ์

  • ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL อินพุตแบบเชิงเส้นที่ช่วง -18 dB ถึง +12 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน

  • ควรบันทึกสตรีมเสียงการจดจำเสียงที่มีการบิดเบี้ยว แบบฮาร์โมนิกทั้งหมด (THD) ต่ำกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน

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

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

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

คลาส android.media.MediaRecorder.AudioSource ประกอบด้วย แหล่งที่มาของเสียง REMOTE_SUBMIX

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

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

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

5.4.4 อุปกรณ์ตัดเสียงก้อง

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

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

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

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

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

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

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

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

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

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

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

    • รูปแบบต้นฉบับ: 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

เริ่มข้อกำหนดใหม่

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

  • เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ มา ขณะอุปกรณ์บันทึกเสียง

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

  • API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ที่เกี่ยวข้องกับ PCM OpenSL ES API ภายใน Android NDK

  • API เสียงดั้งเดิมของเสียง ชุดของ AAudio API ภายใน Android NDK

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

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

  • หมายถึงส่วนเบี่ยงเบนสัมบูรณ์ ค่าเฉลี่ยของค่าสัมบูรณ์ของค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า

  • เวลาในการตอบสนองแบบแตะเพื่อโทนเสียง ช่วงเวลาระหว่างที่แตะหน้าจอจนถึงเวลาที่ได้ยินเสียง ที่เกิดจากการแตะนั้นได้ยินในลำโพง

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

  • [C-1-1] การประทับเวลาเอาต์พุตที่ได้จาก AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำที่ +/- 2 มิลลิวินาที

  • [C-1-2] เวลาในการตอบสนอง เอาต์พุต แบบ Cold 500 มิลลิวินาทีหรือน้อยกว่า

  • [C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้ AAudioStreamBuilder_openStream() ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที

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

  • [C-SR-1] เวลาในการตอบสนองเอาต์พุตแบบเย็นไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของลำโพง
  • [C-SR-2] เวลาในการตอบสนองเมื่อแตะโทนเสียงไม่เกิน 80 มิลลิวินาที

  • [C-SR-4] การประทับเวลาเอาต์พุตที่แสดงผลโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำที่ +/- 1 มิลลิวินาที

เริ่มข้อกำหนดใหม่

  • [C-SR-4] เวลาในการตอบสนองไป-กลับที่คำนวณตามการประทับเวลา อินพุตและเอาต์พุตซึ่งแสดงผลโดย AAudioStream_getTimestamp ขอแนะนำอย่างหนัก ให้อยู่ภายใน 30 มิลลิวินาทีของเวลาในการตอบสนองไป-กลับที่วัดได้สำหรับ AAUDIO_PERFORMANCE_MODE_NONE และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY สำหรับลำโพง ชุดหูฟังแบบมีสายและไร้สาย

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

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

  • [C-SR-5] แนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศแฟล็กฟีเจอร์ android.hardware.audio.low_latency
  • [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

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

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

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

  • [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลให้เป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงค่าเบี่ยงเบนไปจากค่าที่ถูกต้อง
  • [C-3-2] เวลาในการตอบสนองอินพุตแบบ Cold 500 มิลลิวินาทีหรือน้อยกว่า
  • [C-3-3] การเปิดสตรีมอินพุตโดยใช้ AAudioStreamBuilder_openStream() ต้อง ใช้เวลาน้อยกว่า 1,000 มิลลิวินาที

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

  • [C-SR-8] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลไมโครโฟน

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

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

  • [C-SR-12] ขอแนะนำเป็นอย่างยิ่งให้มีเวลาในการตอบสนองเฉลี่ยอย่างต่อเนื่องอยู่ที่ 50 มิลลิวินาทีหรือน้อยกว่าในการวัด 5 ครั้ง โดยมีค่าเบี่ยงเบนเฉลี่ยต่ำกว่า 10 มิลลิวินาทีสำหรับเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง

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 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-ลาตินอเมริกา 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-ทั่วไป RFC 3640 ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในส่วนที่ 5.1.3
MP2T RFC 2250 ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming

5.8 สื่อที่ปลอดภัย

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

  • [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

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

  • [C-2-1] ต้องรักษาความปลอดภัยลิงก์ด้วยกลไกที่มีการเข้ารหัสที่รัดกุม เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และรองรับจอแสดงผลภายนอกแบบใช้สาย ระบบจะดำเนินการดังต่อไปนี้

  • [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อ ผ่านพอร์ตแบบมีสายที่ผู้ใช้เข้าถึงได้

5.9 Musical Instrument Digital Interface (MIDI)

หากการใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ 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
  • [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ไม่เกิน 25 มิลลิวินาทีขึ้นไปจากเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
  • [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
  • [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
  • [C-1-5] ต้องเป็นไปตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียงแบบ USB ที่ใช้ API เสียงดั้งเดิมของ AAudio และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า

  • [C-1-8] ต้องมีเวลาในการตอบสนอง "แตะเพื่อโทนเสียง" โดยเฉลี่ยไม่เกิน 80 มิลลิวินาที สำหรับการวัดอย่างน้อย 5 ค่าผ่านทางเส้นทางข้อมูลระหว่างลำโพงและไมโครโฟน

  • [C-SR-1] แนะนำให้ทำให้สอดคล้องกับเวลาในการตอบสนองตามที่กำหนดไว้ในส่วนเวลาในการตอบสนองของเสียง 5.6 ที่ความเร็ว 20 มิลลิวินาทีหรือน้อยกว่า สำหรับการวัดที่มีค่าเบี่ยงเบนเฉลี่ยค่าสัมบูรณ์น้อยกว่า 5 มิลลิวินาทีในเส้นทางไมโครโฟนระหว่างลำโพง

  • [C-SR-2] แนะนำอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับ Pro สำหรับเวลาในการตอบสนองของเสียงไป-กลับที่ต่อเนื่อง เวลาในการตอบสนองของอินพุตที่เย็น เวลาในการตอบสนองที่ต่ำ และข้อกำหนดเสียง USB โดยใช้ API เสียงเนทีฟ AAudio ผ่านเส้นทาง MMAP

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

    • Voicemark.90 >= 32 เสียง
    • เวลาในการตอบสนองmark.fixed.little <= 15 มิลลิวินาที
    • เวลาในการตอบสนองmark.dynamic.little <= 50 มิลลิวินาที

  • ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน

  • ควรลดการเลื่อนของนาฬิกาเสียงให้สัมพันธ์กับ CPU CLOCK_MONOTONIC เมื่อทำงานอยู่ทั้ง 2 อย่าง

  • ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์

  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB

  • ควรบันทึกการวัดค่าเวลาในการตอบสนองของเสียงในทุกเส้นทาง

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

  • ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน

  • ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0

  • ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด

  • ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด

  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด

  • ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start

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

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

  • ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง

  • ควรลดเวลาในการตอบสนองของการแตะ

  • ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)

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

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

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

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

  • [C-3-1] ต้องใช้คลาสเสียง USB
  • [C-3-2] ต้องมีค่าตอบสนองเฉลี่ยของเสียงไป-กลับแบบต่อเนื่องไม่เกิน 25 มิลลิวินาที หรือค่าเบี่ยงเบนเฉลี่ย 5 ค่าที่มีค่าเบี่ยงเบนเฉลี่ยน้อยกว่า 5 มิลลิวินาทีสำหรับพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB ที่ใช้คลาสเสียง USB (วัดได้โดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์ที่เชื่อมต่ออินพุตกับเอาต์พุต)
  • [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 ช่องในแต่ละทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิตเมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้
  • [C-SR-7] เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ AAudio Native Audio API ผ่านเส้นทาง MMAP

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

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

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

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

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

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

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

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

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

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

  • [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนแต่ละตัว และไมโครโฟนทุกตัวที่ใช้ในการบันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ 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-read (ImageReader, MediaImage, ByteBuffer) ใน Android 13 นั้น P010 จะผ่อนคลายเพื่อให้เครื่องบิน Y และ UV วิ่งได้อย่างอิสระ

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

หากตัวถอดรหัสวิดีโอโฆษณาการรองรับ COLOR_Format32bitABGR2101010 เครื่องมือดังกล่าวจะ:

  • [C-2-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับรูปแบบเอาต์พุตและ CPU ที่อ่านได้ (เอาต์พุต ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_FormatYUVP010 โปรแกรมจะ:

  • [C-3-1] ต้องรองรับรูปแบบ P010 สำหรับแพลตฟอร์มอินพุตและอินพุตแบบ CPU-writeable (ImageWriter, MediaImage, ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอสนับสนุน COLOR_Format32bitABGR2101010 โปรแกรมดังกล่าวจะมีลักษณะดังนี้

  • [C-4-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับพื้นผิวอินพุตและอินพุตแบบ CPU-Writer (ImageWriter, ByteBuffer) หมายเหตุ: โปรแกรมเปลี่ยนไฟล์ไม่จำเป็นต้องใช้การแปลงเส้นโค้งการโอนต่างๆ

ข้อกำหนดในการจับภาพ 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 และต้องโฆษณาการรองรับ COLOR_Format32bitABGR2101010

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

  • [C-7-4] ต้องโฆษณาการรองรับส่วนขยาย OpenGL EXT_YUV_target

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

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

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

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

  • Android Debug Bridge (adb)

    • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปใช้ได้ รวมถึง dumpsys cmd stats
    • [C-0-11] ต้องรองรับคำสั่ง Shell cmd testharness การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มีการบล็อกข้อมูลแบบถาวรอาจได้รับการยกเว้นจาก C-0-11
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบอุปกรณ์ (batterystats , Dataprocs, Fingerprint, graphicstats, netstats, notification, procstats) บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell cmd stats และคลาส StatsManager System API
      • เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
      • ตรวจพบความผิดปกติ
      • รายงานเบรดครัมบ์ของแอปแล้ว
      • แอปขัดข้อง
      • เกิดแอป
      • เปลี่ยนระดับแบตเตอรี่แล้ว
      • เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
      • BleScanผลลัพธ์ได้รับ
      • เปลี่ยนสถานะ BleScan แล้ว
      • เปลี่ยนสถานะการชาร์จแล้ว
      • เปลี่ยนสถานะโหมดอุปกรณ์ชั่วคราวแล้ว
      • เปลี่ยนสถานะของบริการที่ทำงานอยู่เบื้องหน้าแล้ว
      • เปลี่ยนสถานะการสแกน GPS แล้ว
      • เปลี่ยนสถานะของงานแล้ว
      • สถานะเสียบปลั๊กเปลี่ยน
      • เปลี่ยนสถานะงานที่กำหนดเวลาไว้แล้ว
      • สถานะหน้าจอเปลี่ยน
      • สถานะการซิงค์เปลี่ยนแปลง
      • แบบเรียลไทม์โดยระบบ
      • เปลี่ยนสถานะ UidProcess แล้ว
      • เปลี่ยนสถานะ Wake Lock แล้ว
      • ตั้งปลุกแล้ว
      • เปลี่ยนสถานะ WifiLock
      • เปลี่ยนสถานะ Wifiมัลติแคสต์ล็อกแล้ว
      • เปลี่ยนสถานะการสแกน Wi-Fi แล้ว
    • [C-0-4] ต้องมี adb daemon ฝั่งอุปกรณ์ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
    • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android มีการสนับสนุนสำหรับ adb ที่ปลอดภัย Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แล้วที่รู้จัก
    • [C-0-6] ต้องระบุกลไกที่ทำให้สามารถเชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

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

    • [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ 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() ที่แสดง true

  • บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (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 แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง
    • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุตสำหรับการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-3] ขอแนะนําอย่างยิ่งให้เขียนไบนารี Perfetto เป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
    • [C-SR-4] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto โดยใช้ไบนารี Perfetto

  • ประหยัดหน่วยความจำต่ำ

    • [C-0-12] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ไปยังบันทึก statsd เมื่อแอปถูก Low Memory Killer สิ้นสุดการทำงาน

  • โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่ง Shell cmd testharness และเรียกใช้ cmd testharness enable การดำเนินการดังกล่าวจะส่งผลดังนี้

  • ข้อมูลการทำงานของ GPU

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

    • [C-0-13] ต้องใช้คำสั่ง Shell dumpsys gpu --gpuwork เพื่อแสดงข้อมูลงานของ GPU แบบรวมที่ส่งคืนโดยจุดการติดตามของเคอร์เนล power/gpu_work_period หรือไม่แสดงข้อมูลใดๆ หากระบบไม่รองรับ Tracepoint ดังกล่าว การติดตั้งใช้งาน AOSP คือ frameworks/native/services/gpuservice/gpuwork/

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

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

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

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

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

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

เริ่มข้อกำหนดใหม่

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

  • [C-0-1] โดยค่าเริ่มต้น แอปพลิเคชันของบุคคลที่สามต้องแสดงผลบน จอแสดงผลที่รองรับ Android เท่านั้น

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

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

  • ขนาดแนวทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุม 2 ด้านที่ตรงข้ามกันของส่วนที่สว่างของจอแสดงผล
  • จุดต่อนิ้ว (dpi)ความหนาแน่น จำนวนพิกเซลที่ครอบคลุมโดยช่วงแนวตั้งหรือแนวนอนแบบเชิงเส้น 1 นิ้วซึ่งแสดงเป็นพิกเซลต่อนิ้ว (ppi หรือ dpi) เมื่อมีการแสดงค่า dpi ppi และ dpi ทั้ง DPI แนวนอนและแนวตั้งจะต้องอยู่ในช่วงที่แสดง
  • อัตราส่วน อัตราส่วนของพิกเซลด้านที่ยาวกว่ากับขนาดที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซล จะมีขนาด 854/480 = 1.779 หรือโดยประมาณเป็น "16:9"
  • ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือน ได้รับการทำให้เป็นมาตรฐานเป็นหน้าจอ 160 dpi ความหนาแน่นของหน้าจอ 160 สำหรับความหนาแน่นบางส่วน d และจำนวนพิกเซล p จำนวนความหนาแน่นของพิกเซลอิสระ dp จะคำนวณเป็น พิกเซล = dps * (ความหนาแน่น/160) 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_Wwatch และรายงานขนาด small สําหรับ Configuration.screenLayout ต้องมีค่าอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด normal สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานขนาด large สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีอย่างน้อย 960 dp x 720 dp

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

  • อาจมีจอแสดงผลที่ใช้งานได้กับ Android ซึ่งมีมุมโค้งมน

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

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

    • รัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
    • เมื่อกล่อง dp ของ 15 18 dp คูณ 1518 ตรึงอยู่ที่มุมของจอแสดงผลเชิงตรรกะ อย่างน้อย 1 พิกเซลของแต่ละกล่องจะปรากฏบนหน้าจอ

  • ควรรวมทางเลือกของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยมผืนผ้า

เริ่มข้อกำหนดใหม่

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

  • [C-4-1] ต้องมีขนาดเลย์เอาต์โดยไม่รวมหน้าจอรอยบากอย่างน้อย 596 dp x 384 dp หรือสูงกว่า

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

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

  • [C-2-1] ต้องใช้ extensions API เวอร์ชันเสถียรล่าสุดที่มีให้ใช้งาน หรือ sidecar API เวอร์ชันเสถียรที่จะใช้โดยไลบรารี Window Manager Jetpack

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

  • [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือพับผ่าน API ส่วนขยายหรือไฟล์ช่วยเหลือไปยังแอปพลิเคชัน

หากต้องการรายละเอียดเกี่ยวกับการใช้ API ไฟล์ช่วยเหลือหรือส่วนขยายอย่างถูกต้อง โปรดดูเอกสารสาธารณะของ Window Manager Jetpack

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

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

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

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

การใช้งานอุปกรณ์

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

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

เริ่มข้อกำหนดใหม่

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

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

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

  • [C-1-1] ไม่ต้องปรับขนาดการแสดงผลใดๆ ต้องไม่ปรับขนาดจอแสดงผล ให้ใหญ่กว่า 1.5 เท่า DENSITY_DEVICE_STABLE ความหนาแน่นดั้งเดิม หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพน้อยกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) ขึ้นอยู่กับว่ากรณีใดจะเกิดขึ้นก่อน
  • [C-1-2] ไม่ต้องปรับขนาดการแสดงผล ต้องไม่ปรับขนาดการแสดงผล ให้เล็กกว่า 0.85 เท่าของความหนาแน่นดั้งเดิมของ DENSITY_DEVICE_STABLE
  • เราแนะนำให้กำหนดการปรับขนาดของตัวเลือกการแสดงโฆษณาเนทีฟต่อไปนี้ (โดยที่ยังปฏิบัติตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อดูแลให้ใช้งานจริงได้ดีและมีขนาดแบบอักษรที่สอดคล้องกัน
    • เล็ก: 0.85 เท่า
    • ค่าเริ่มต้น: 1 เท่า (ขนาดโฆษณาแบบดิสเพลย์เนทีฟ)
    • ใหญ่: 1.15 เท่า
    • ใหญ่กว่า: 1.3 เท่า
    • ใหญ่ที่สุด 1.45 เท่า

7.1.2 แสดงเมตริก

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

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

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

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

7.1.3 การวางแนวหน้าจอ

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

  • [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ ตัวอย่างเช่น อุปกรณ์ที่มีหน้าจอแนวนอนตามการวางแนวที่คงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
  • [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ เมื่อใดก็ตามที่ค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

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

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

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

7.1.4.1 OpenGL ES

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

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

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

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

การทดสอบ dEQP ของ OpenGL ES แบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมีหมายเลขวันที่/เวอร์ชันที่เกี่ยวข้องกัน รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/glesXX-main-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 ที่รองรับผ่านแฟล็กฟีเจอร์ android.software.opengles.deqp.level
  • [C-2-4] ต้องรองรับเวอร์ชัน 132383489 (ตั้งแต่วันที่ 1 มีนาคม 2020) เป็นอย่างน้อย ตามที่รายงานในแฟล็กฟีเจอร์ android.software.opengles.deqp.level
  • [C-2-5] ต้องผ่านการทดสอบ OpenGL ES dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 และเวอร์ชันที่ระบุในแฟล็กฟีเจอร์ 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] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด

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

  • [C-5-1] ต้องระบุการรองรับผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

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

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

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

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

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3
  • [C-4-1] ต้องไม่รองรับเวอร์ชันตัวแปร Vulkan (เช่น ส่วนตัวแปรของเวอร์ชันหลักของ Vulkan ต้องเป็น 0)

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

  • [C-SR-2] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.3

การทดสอบ Vulkan dEQP ได้รับการแบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมีวันที่/เวอร์ชันที่เกี่ยวข้อง รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ Vulkan ในระดับที่รายงานด้วยตนเองบ่งชี้ว่าอุปกรณ์สามารถผ่านการทดสอบ dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้า

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

  • [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วยแฟล็กฟีเจอร์ android.hardware.vulkan.level และ android.hardware.vulkan.version
  • [C-1-2] ต้องแจกแจง VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ Vulkan API เนทีฟ vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องใช้ API Vulkan 1.0 อย่างเต็มรูปแบบ Vulkan 1.1 สำหรับการแจกแจงแต่ละรายการ 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] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ Vulkan dEQP ที่รองรับผ่านแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-9] ต้องรองรับเวอร์ชัน 132317953 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
  • [C-1-10] ต้องผ่านการทดสอบ Vulkan dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132317953 กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์ 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

  • ควรรองรับ VkPhysicalDeviceProtectedMemoryFeatures และ VK_EXT_global_priority

  • [C-1-12] ต้องไม่แจกแจงการรองรับส่วนขยาย VK_KHR_performance_query

เริ่มข้อกำหนดใหม่

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

  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดที่ระบุไว้ในโปรไฟล์ Android Baseline 2022

เริ่มข้อกำหนดใหม่

  • [C-SR-5] แนะนําอย่างยิ่งให้สนับสนุน VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory และ VK_EXT_global_priority

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้ใช้ SkiaVk กับ HWUI

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

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

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

หากการติดตั้งใช้งานอุปกรณ์มีการรองรับ Vulkan 1.1 และประกาศแฟล็กฟีเจอร์ 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 ในพื้นที่ CIE 1931 xyY
  • [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% ในพื้นที่ CIE 1931 xyY แม้ว่าไม่ได้ระบุขอบเขตสีของหน้าจอก็ตาม

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] ต้องใช้บริการของระบบ DisplayManager และ API ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

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

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

7.2.1 แป้นพิมพ์

หากการนำอุปกรณ์ไปใช้งานรองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม จะมีผลดังนี้

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

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

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

7.2.2 การนำทางแบบไม่สัมผัส

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

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

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

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

7.2.3 ปุ่มนำทาง

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

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

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

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

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

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

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

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

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสในหน้าแรกเท่านั้น
  • [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในวิดีโอยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets() ต้องไม่มีการสกัดกั้นสำหรับฟังก์ชันการนำทาง ตราบใดที่การยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
  • [C-6-3] ต้องส่งเหตุการณ์ MotionEvent.ACTION_CANCEL ให้แอปที่ทำงานอยู่เบื้องหน้าเมื่อการแตะเริ่มถูกดักจับสำหรับท่าทางสัมผัสของระบบ ในกรณีที่แอปที่ทำงานอยู่เบื้องหน้ามีการส่งเหตุการณ์ MotionEvent.ACTION_DOWN ไว้ก่อนหน้านี้
  • [C-6-4] ต้องให้ผู้ใช้จ่ายเพื่อเปลี่ยนไปใช้การนำทางบนหน้าจอ โดยใช้ปุ่ม (เช่น ในการตั้งค่า)
  • ควรมีฟังก์ชัน "หน้าแรก" โดยการปัดขึ้นจากขอบด้านล่างของการวางแนวปัจจุบันของหน้าจอ
  • ควรมีฟังก์ชัน "ล่าสุด" เป็นการปัดขึ้นแล้วค้างไว้ก่อนที่จะปล่อยนิ้ว จากพื้นที่เดียวกับท่าทางสัมผัส "หน้าแรก"
  • ท่าทางสัมผัสที่เริ่มต้นภายใน WindowInsets#getMandatorySystemGestureInsets() ไม่ควรได้รับผลกระทบจากการแก้ไขการยกเว้นซึ่งมาจากแอปพลิเคชันเบื้องหน้าผ่านทาง View#setSystemGestureExclusionRects()

หากฟังก์ชันการนำทางมาจากที่ใดก็ได้จากขอบซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ

  • [C-7-1] ฟังก์ชันการนำทางต้อง "ย้อนกลับ" และแสดงขึ้นจากการปัดจากขอบทั้งด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
  • [C-7-2] หากแผงระบบแบบปัดดูที่กำหนดเองมีอยู่ที่ขอบด้านซ้ายหรือขวา แผงดังกล่าวจะต้องวางไว้ใน 1/3 ของส่วนบนสุดของหน้าจอ โดยมีภาพบ่งชี้ที่ชัดเจนและมองเห็นได้ตลอดเวลาว่า การลากนิ้วจะเรียกใช้แผงที่กล่าวถึงข้างต้น และด้วยเหตุนี้ จึงไม่ "ย้อนกลับ" ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ใต้ 1/3 ของขอบหน้าจอด้านบน แต่แผงระบบต้องไม่ยาวกว่าขอบ 1/3 ของขอบหน้าจอ
  • [C-7-3] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANS_BARS_BY_SWIOR_SHOW_TRANS_BARS_BY_SWIG
  • [C-7-4] เมื่อแอปเบื้องหน้ามี View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_S ระบบซ่อนแถบการนำทางที่กำหนดเอง

หากมีฟังก์ชันการนำทางกลับ และผู้ใช้ยกเลิกท่าทางสัมผัสกลับแล้ว ให้ทำดังนี้

  • [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] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.touchscreen และ android.hardware.faketouch

หากอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะ มากกว่า 1 ครั้งบนจอแสดงผลหลักที่รองรับ Android ฟีเจอร์ดังกล่าว

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

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

  • [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่เริ่มต้นด้วย android.hardware.touchscreen
  • [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
  • [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับช่อง API ของ Configuration.touchscreen

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

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

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

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

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

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

KeyEvent 1 รายการ

2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน CA ของ Gamepad CA (0x01 0x0005)

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

4 เหตุการณ์การเคลื่อนไหว

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

เหตุการณ์การเคลื่อนไหว 1 รายการ

7.2.7 รีโมตคอนโทรล

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

7.3 เซ็นเซอร์

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

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

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

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

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

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

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

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

    • [C-1-3] ต้องสามารถระบุตำแหน่งได้ภายใน 20 เมตร และความเร็ว ภายใน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
    • [C-1-4] ต้องติดตามและรายงานพร้อมกันผ่าน GnssStatus.Callback ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว
    • ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายดวงพร้อมกันได้ (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อย 1 ดวง)

  • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ระหว่างการโทรฉุกเฉินต่อไป

  • [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] ขอแนะนำเป็นอย่างยิ่งให้รายงานช่วง Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยอัตรากำลังสองของความเร่งน้อยกว่า 0.2 เมตรต่อวินาที ก็เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที

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) ค่าความแปรปรวนจะแตกต่างกันไปตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดโดยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโรด้วยอัตราการสุ่มตัวอย่าง 1 Hz ค่าไม่ควรสูงกว่า 1e-7 rad^2/s^2
  • [C-SR-2] เราขอแนะนำเป็นอย่างยิ่งว่าข้อผิดพลาดในการปรับเทียบให้น้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • [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 hPa ถึง 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

หากการติดตั้งใช้งานอุปกรณ์ประกาศ 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/ทั้งหมดใน{/9}
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
    • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมของไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีความเร่งเดินแบบสุ่มน้อยกว่า 30 μg ¡Hz ทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
    • ควรมีค่าความไม่เป็นเชิงเส้นของเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิ ≤ 0.03%/C°
    • ควรมีความไวข้ามแกน < 2.5 % และความไวข้ามแกน < 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

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

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่ง

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

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

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่ง

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

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

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

  • [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่ง

    • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
    • ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
    • ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
    • ต้องใช้พลังงานแบบกลุ่มไม่เกิน 2 mW

  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR

  • [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] ต้องมีการประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุน อยู่ในฐานเวลาเดียวกับระบบย่อยของกล้อง และมีข้อผิดพลาดภายใน 1 มิลลิวินาที

  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงใดๆ ข้างต้นไปยังแอปพลิเคชัน

  • [C-2-16] ต้องไม่มีปริมาณการใช้พลังงานสูงกว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่งและ 2.0 mW เมื่ออุปกรณ์กำลังเคลื่อนที่ เมื่อเปิดใช้เซ็นเซอร์ใดๆ ต่อไปนี้ร่วมกัน

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมี ต้องมีความสามารถในการบัฟเฟอร์ขั้นต่ำที่ 100 เหตุการณ์เซ็นเซอร์

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

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

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

หากอุปกรณ์รองรับข้อมูลไบโอเมตริกแบบแพสซีฟ ข้อมูลเหล่านั้นจะมีลักษณะดังนี้

  • [C-5-1] โดยค่าเริ่มต้น ต้องมีขั้นตอนการยืนยันเพิ่มเติม (เช่น การกดปุ่ม)
  • [C-SR-1] แนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ลบล้างค่ากำหนดแอปพลิเคชันและต้องมีขั้นตอนการยืนยันประกอบเสมอ
  • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งให้ดำเนินการยืนยันเพื่อความปลอดภัย เพื่อให้ระบบปฏิบัติการหรือเคอร์เนลถูกบุกรุกไม่สามารถปลอมแปลงได้ ตัวอย่างเช่น การดำเนินการยืนยันตามปุ่มจริงจะส่งผ่าน PIN อินพุต/เอาต์พุต (GPIO) สำหรับอินพุตเฉพาะวัตถุประสงค์ทั่วไปขององค์ประกอบความปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นๆ นอกเหนือจากการกดปุ่มจริง
  • [C-5-2] ต้องใช้ขั้นตอนการตรวจสอบสิทธิ์แบบโดยนัยเพิ่มเติม (ไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationrequired(boolean) ซึ่งแอปพลิเคชันสามารถตั้งค่าเพื่อใช้สำหรับขั้นตอนการลงชื่อเข้าใช้ได้

หากอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกหลายตัว ระบบจะดำเนินการต่อไปนี้

เริ่มข้อกำหนดใหม่

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

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

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

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

  • [C-SR-3] ขอแนะนำเป็นอย่างยิ่งให้ยืนยันข้อมูลไบโอเมตริกเพียงรายการเดียวต่อการตรวจสอบสิทธิ์ (เช่น หากทั้งเซ็นเซอร์ลายนิ้วมือและใบหน้าในอุปกรณ์ใช้งานได้ ควรส่ง 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 วินาที Backoff สำหรับยืนยันข้อมูลไบโอเมตริก
  • [C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้ลดจำนวนการทดลองทั้งหมดที่ผิดพลาดสำหรับการยืนยันข้อมูลไบโอเมตริกที่ระบุไว้ใน [C-1-9] หากอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 7% เมื่อวัดโดยใช้โปรโตคอลการทดสอบข้อมูลไบโอเมตริกของ Android
  • [C-1-3] ต้องพยายามจำกัดจำนวนอัตราสำหรับการยืนยันด้วยข้อมูลไบโอเมตริก โดยการทดสอบที่ผิดพลาดคือการทดสอบที่มีคุณภาพการบันทึกเพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
  • [C-SR-5] แนะนำอย่างเข้มงวดให้กำหนดอัตราการจำกัดเป็นเวลาอย่างน้อย 30 วินาทีหลังจากการทดลองที่ผิดพลาด 5 ครั้งเพื่อการยืนยันข้อมูลไบโอเมตริกสูงสุดสำหรับจำนวนการทดลองที่ผิดพลาดสูงสุดต่อ [C-1-9] โดยการทดลองที่ผิดพลาดเป็นการทดลองที่มีคุณภาพในการบันทึก (BIOMETRIC_ACQUIRED_GOOD) ที่เพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลชีวภาพที่ลงทะเบียน
  • [C-SR-6] ขอแนะนำเป็นอย่างยิ่งให้กำหนดตรรกะการจำกัดอัตราคำขอทั้งหมดใน TEE

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

  • [C-1-11] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 30% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีการนำเสนอ (PAI) ระดับ A ไม่เกิน 30% และ (2) อัตราการยอมรับโปรโตคอลที่แปลงและไม่เป็นจริงของสปีชีส์ระดับ BAI ไม่เกิน 40% เนื่องจากการทดสอบโปรโตคอลระดับ BAI ต่ำกว่า 40%

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

  • [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ของผู้ใช้ออกทั้งหมด เมื่อมีการนำบัญชีออก (รวมถึงการรีเซ็ตเป็นค่าเริ่มต้น)

  • [C-1-6] ต้องให้เกียรติแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้นๆ (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS)

  • [C-1-7] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 24 ชั่วโมงหรือน้อยกว่านั้น หมายเหตุ: การอัปเกรดอุปกรณ์ที่เปิดตัวใน Android เวอร์ชัน 9 หรือเก่ากว่าต้องแก้ปัญหาให้ผู้ใช้ทำการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งในทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น

  • [C-1-8] ต้องให้ผู้ใช้ยืนยันการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หรือข้อมูลไบโอเมตริกคลาส 3 (STRONG) หลังจากทำอย่างใดอย่างหนึ่งต่อไปนี้

    • เมื่อไม่มีความเคลื่อนไหวเป็นเวลา 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-14] ขอแนะนำอย่างยิ่งให้เปิดเผยคลาสข้อมูลไบโอเมตริกของเซ็นเซอร์ไบโอเมตริกและความเสี่ยงที่เกี่ยวข้องในการเปิดใช้เซ็นเซอร์ดังกล่าว

  • [C-SR-17] แนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซ AIDL ใหม่ (เช่น IFace.aidl และ IFingerprint.aidl)

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

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

  • [C-2-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 1 ข้างต้น

  • [C-2-2] ต้องมีอัตราการยอมรับการปลอมแปลงและตัวปลอมสูงกว่า 20% โดยมี (1) อัตราการยอมรับการปลอมแปลงและการยอมรับตัวปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีระดับ A (PAI) ไม่สูงกว่า 20% และ (2) อัตราการยอมรับโปรโตคอลที่หลอกลวงและปลอมของสปีชีส์ระดับ B PAI ที่ไม่สูงกว่า 30% เนื่องจากการทดสอบ Android

เริ่มข้อกำหนดใหม่

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

  • [C-2-3] ต้องดำเนินการจับคู่ข้อมูลไบโอเมตริกในสภาพแวดล้อมการดำเนินการแยกต่างหากนอกผู้ใช้ Android หรือพื้นที่เคอร์เนล เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือบนชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหากหรือในเครื่องเสมือนที่มีการป้องกันที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17
  • [C-2-4] ต้องมีข้อมูลที่ระบุตัวตนได้ทั้งหมดที่เข้ารหัสและตรวจสอบสิทธิ์แบบเข้ารหัสลับเพื่อที่จะไม่สามารถได้มา อ่าน หรือเปลี่ยนแปลงนอกสภาพแวดล้อมการดำเนินการที่แยกไว้ หรือชิปที่มีช่องทางที่ปลอดภัยสำหรับสภาพแวดล้อมการดำเนินการที่แยกไว้ดังที่ระบุในหลักเกณฑ์การใช้งาน ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android หรือเครื่องเสมือนที่มีการป้องกันซึ่งควบคุมโดย Hypervisor ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17
  • [C-2-5] สำหรับข้อมูลไบโอเมตริกที่ใช้กล้องขณะที่การตรวจสอบสิทธิ์หรือลงทะเบียนด้วยข้อมูลไบโอเมตริก
    • ต้องใช้กล้องในโหมดที่ป้องกันไม่ให้อ่านหรือเปลี่ยนแปลงเฟรมกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกต่างหาก หรือชิปที่มีช่องทางที่ปลอดภัยในสภาพแวดล้อมการดำเนินการแยกต่างหากหรือเครื่องเสมือนที่มีการป้องกันซึ่งควบคุมโดย Hypervisor ที่เป็นไปตามข้อกำหนดในส่วนที่ 9.17
    • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องจะอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกออกมาเพื่อสนับสนุนการดำเนินการ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่ต้องไม่สามารถแก้ไขได้
  • [C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามในการแยกความแตกต่างระหว่างการลงทะเบียนข้อมูลไบโอเมตริกแต่ละรายการ
  • [C-2-7] ต้องไม่อนุญาตการเข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวตนได้หรือข้อมูลใดก็ตามที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ไปยังตัวประมวลผลแอปพลิเคชันโดยไม่เข้ารหัส นอกบริบทของ TEE หรือเครื่องเสมือนที่มีการป้องกันที่ควบคุมโดย Hypervisor ซึ่งเป็นไปตามข้อกำหนดในข้อ 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) อัตราการยอมรับการปลอมแปลงและการยอมรับปลอมสำหรับสปีชีส์ประเภทเครื่องมือโจมตีระดับ A (PAI) ไม่สูงกว่า 7% และ (2) อัตราการยอมรับการปลอมแปลงและตัวปลอมของสปีชีส์ PAI ระดับ B ที่ไม่สูงกว่า 20% การวัดไบโอเมตริกของ Android
  • [C-3-4] ต้องขอให้ผู้ใช้ตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่านั้น
  • [C-3-5] ต้องสร้างรหัส Authenticator อีกครั้งสำหรับข้อมูลไบโอเมตริกระดับ 3 ทั้งหมดที่รองรับในอุปกรณ์ หากมีการลงทะเบียนซ้ำ
  • [C-3-6] ต้องเปิดใช้คีย์สโตร์ที่ใช้ข้อมูลไบโอเมตริกกับแอปพลิเคชันของบุคคลที่สาม

เริ่มข้อกำหนดใหม่

  • [C-SR-16] ขอแนะนำเป็นอย่างยิ่งให้มีอัตราการยอมรับการปลอมแปลงและผู้แอบอ้างไม่เกิน 7% ต่อสปีชีส์ประเภทเครื่องมือโจมตี (PAI) สำหรับการนำเสนอ ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android

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

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

  • [C-SR-11] ขอแนะนำอย่างยิ่งเพื่อป้องกันไม่ให้พื้นที่ที่สัมผัสได้ของ UDFPS รบกวนการนำทางแบบ 3 ปุ่ม( ซึ่งผู้ใช้บางรายอาจต้องการเพื่อการเข้าถึง)

7.3.11 เซ็นเซอร์ท่าทาง

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

  • อาจรองรับเซ็นเซอร์ตรวจจับท่าทางที่มีอิสระ 6 องศา

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

  • [C-1-1] ต้องใช้และรายงานเซ็นเซอร์ TYPE_POSE_6DOF
  • [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

7.3.12 เซ็นเซอร์มุมบานพับ

หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์วัดมุมแบบบานพับ อุปกรณ์จะทำงานดังนี้

7.3.13 IEEE 802.1.15.4 (UWB)

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

เริ่มข้อกำหนดใหม่

  • [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
  • [C-1-3] ต้องรองรับชุดการกำหนดค่าต่อไปนี้ทั้งหมด (ชุดค่าผสมพารามิเตอร์ FIRA UCI ที่กำหนดไว้ล่วงหน้า) ซึ่งกำหนดไว้ในการใช้งาน AOSP
    • CONFIG_ID_1: ช่วง Unicast STATIC STS DS-TWR ที่กำหนดโดย FiRa, โหมดหน่วงเวลา ช่วงเวลา 240 มิลลิวินาที
    • CONFIG_ID_2: ช่วง 1 ต่อ STATIC STS DS-TWR ที่ 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 โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย API ของ Android และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรออกด้วยเสียงและการส่งข้อความ SMS หรือการจัดทำข้อมูลมือถือผ่านระบบมือถือ (เช่น GSM, CDMA, LTE, NR)GSM หรือเครือข่าย CDMA อุปกรณ์ที่รองรับ "โทรศัพท์" อาจเลือกเสนอบริการการโทร การรับส่งข้อความ และข้อมูลบางส่วนหรือทั้งหมดตามความเหมาะสมของผลิตภัณฑ์

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

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

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA

  • [C-1-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony และแฟล็กฟีเจอร์ย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องใช้การสนับสนุน API อย่างสมบูรณ์สำหรับเทคโนโลยีนั้น
  • ควรอนุญาตบริการเครือข่ายมือถือทุกประเภท (2G, 3G, 4G, 5G ฯลฯ) ระหว่างการโทรฉุกเฉิน (ไม่ว่าเครือข่ายจะตั้งโดย SetAllowedNetworkTypeBitmap() ประเภทใดก็ตาม)

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

  • [C-2-1] ต้องใช้ API เต็มรูปแบบเป็นแบบไม่ต้องดำเนินการ

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมที่ฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้นักพัฒนาแอปบุคคลที่สามใช้งานฟังก์ชัน eSIM ได้ ฟังก์ชันดังกล่าวจะมีลักษณะดังนี้

หากการติดตั้งใช้งานอุปกรณ์ไม่ได้ตั้งค่าพร็อพเพอร์ตี้ของระบบ ro.telephony.iwlan\_operation\_mode เป็น "เดิม" ระบบจะดำเนินการดังต่อไปนี้

หากการใช้งานอุปกรณ์รองรับการลงทะเบียนระบบย่อยแบบมัลติมีเดีย (IMS) แบบ IP เดียวสำหรับทั้งฟีเจอร์บริการโทรศัพท์มัลติมีเดีย (MMTEL) และฟีเจอร์บริการสื่อสารที่สมบูรณ์ (RCS) และเป็นไปตามข้อกำหนดของผู้ให้บริการเครือข่ายมือถือเกี่ยวกับการใช้การลงทะเบียน IMS เดียวสำหรับการรับส่งข้อมูลการส่งสัญญาณ IMS ทั้งหมด

  • [C-5-1] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony.ims และติดตั้งใช้งาน ImsService API โดยสมบูรณ์สำหรับทั้ง User Capability Exchange API ของ MMTEL และ RCS
  • [C-5-2] ต้องประกาศ Flag ฟีเจอร์ android.hardware.telephony.ims.singlereg และติดตั้งใช้งาน SipTransport API, GbaService API, ตัวบ่งชี้สำหรับผู้ถือโดยเฉพาะโดยใช้ IRadio 1.6 HAL และการจัดสรรผ่าน Auto Configuration Server (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 ต้องใช้ SmsManager API เมื่อส่งและรับข้อความ 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 ด้วย UUID กลุ่มและบิตของโอกาสที่ไม่เป็นค่าว่าง โดยอนุญาตให้กำหนดค่าหรือควบคุมการตั้งค่าซิมการ์ดได้

หากการใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.telephony และมีแถบสถานะของระบบ ให้ทำดังนี้

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

หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ 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] ต้องใส่ IllegalArgumentException เมื่อมีการพยายามตั้งค่าประเภทเครือข่าย 3GPP2 เป็นบิตมาสก์ประเภทเครือข่ายที่ต้องการหรือที่ได้รับอนุญาต
  • [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 API โทรคมนาคม

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

  • [C-1-1] ต้องรองรับ API ของ ConnectionService ที่อธิบายไว้ใน 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 สำหรับ API ของ android.telecom ดังนี้

    • โทรหา Connection.onDisconnect() เมื่อตรวจพบการกดปุ่มเหตุการณ์สำคัญสั้นๆ ระหว่างที่โทรอยู่
    • โทรหา Connection.onAnswer() เมื่อตรวจพบการกดแป้นสั้นๆ ระหว่างที่มีสายเรียกเข้า
    • โทร Connection.onReject() เมื่อตรวจพบการกดแป้นค้างระหว่างที่มีสายเรียกเข้า
    • สลับสถานะการปิดเสียงของ CallAudioState
7.4.1.3 การลดภาระงาน NAT-T Keepalive ของเครือข่ายมือถือ

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

  • ควรมีการสนับสนุนสำหรับการลดภาระงาน Keepalive ผ่านเครือข่ายมือถือ

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

  • [C-1-1] ต้องรองรับ SocketKeepAlive API
  • [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ
  • [C-1-3] ต้องรองรับสล็อต Keepalive ผ่านเครือข่ายมือถือพร้อมกันได้มากเท่าที่ Cellular Radio HAL รองรับ
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับช่อง Keepalive ของเครือข่ายมือถืออย่างน้อย 3 ช่องต่ออินสแตนซ์วิทยุ

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

  • [C-2-1] ต้องแสดงผล ERROR_UNSUPPORTED

7.4.2 IEEE 802.11 (Wi-Fi)

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

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

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

  • [C-1-1] ต้องใช้ Android API ที่สอดคล้องกัน
  • [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
  • [C-1-3] ต้องใช้ multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-4] ต้องรองรับ Multicast DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251 or ff02::fb) ได้ทุกเมื่อที่ต้องการ รวมถึงเมื่อหน้าจอไม่ได้อยู่ในสถานะทำงานอยู่ เว้นแต่ความจำเป็นในการลดหรือกรองแพ็กเก็ตเหล่านี้เพื่อให้อยู่ภายในช่วงข้อกำหนดของตลาดเป้าหมายตามข้อกำหนดด้านการใช้พลังงานเป้าหมาย สำหรับการใช้งานอุปกรณ์ Android TV แม้ว่าจะอยู่ในสถานะกำลังสแตนด์บาย
  • [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 ที่สอดคล้องกันเพียงรายการเดียว (ไม่ควรสุ่มที่อยู่ MAC ในช่วงครึ่งทางของการสแกน)
  • [C-1-9] ต้องทำซ้ำหมายเลขลำดับการตรวจสอบของคำขอตามปกติ (ตามลำดับ) ระหว่างคำขอตรวจสอบในการสแกน
  • [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 ใช้
    • DEVICE อาจให้ตัวเลือกกับผู้ใช้ในการปิดใช้งานฟีเจอร์นี้ หากมีตัวเลือกดังกล่าว การสุ่มต้องเปิดใช้งานโดยค่าเริ่มต้น

หากการใช้งานอุปกรณ์รวมการสนับสนุนสำหรับโหมดประหยัดพลังงาน 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 (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] ต้องใช้ corresponding 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 และ TDLS เปิดใช้อยู่โดย WiFiManager API จะมีการดำเนินการดังนี้

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

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

  • ควรมีการสนับสนุนสำหรับ Wi-Fi Aware

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

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

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

7.4.2.4 รหัสผ่าน Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์มีการรองรับ 802.11 (Wi-Fi) อุปกรณ์ดังกล่าวจะดำเนินการดังนี้

  • [C-1-1] ต้องมีการรองรับ Wi-Fi Passpoint
  • [C-1-2] ต้องใช้ API ของ WifiManager ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับ SDK
  • [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นพบและการเลือกเครือข่าย เช่น General 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 ตามที่อธิบายไว้ในข้อมูลจำเพาะของฮอตสปอต 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 การลดภาระงาน Wi-Fi Keepalive

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

  • ควรมีการสนับสนุนสำหรับการลดภาระงาน Wi-Fi Keepalive

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

  • [C-1-1] ต้องรองรับ SocketKeepAlive API
  • [C-1-2] ต้องรองรับสล็อต Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi

หากการใช้งานอุปกรณ์ไม่รองรับการลดภาระงาน Wi-Fi Keepalive สิ่งที่จะเกิดขึ้นมีดังนี้

7.4.2.7 Wi-Fi Easy Connect (โปรโตคอลการจัดสรรอุปกรณ์)

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

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

7.4.2.8 การตรวจสอบใบรับรองเซิร์ฟเวอร์ Wi-Fi ขององค์กร

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

7.4.2.9 Trust On First Use (TOFU)

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

  • [C-3-5] ต้องใช้ระยะหมดเวลา Resolvable Private Address (RPA) ที่ไม่เกิน 15 นาทีและหมุนที่อยู่ในระยะหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์กำลังใช้ BLE ในการสแกนหรือการโฆษณา และในการป้องกันการโจมตีแบบจับเวลา ระยะหมดเวลาจะต้องเป็นแบบสุ่มระหว่าง 5 ถึง 15 นาทีด้วย

  • ควรรองรับการลดภาระของตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API

  • ควรรองรับการลดการโหลดของการสแกนแบบกลุ่มไปยังชิปเซ็ตบลูทูธ

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

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

  • [C-4-1] ต้องระบุราคาสำหรับการเปิด/ปิดใช้ค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable()

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

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

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

หากการใช้งานอุปกรณ์รวมการรองรับบลูทูธหรือบลูทูธพลังงานต่ำ และไฟล์ Manifest ของแอปไม่ได้รวมประกาศจากนักพัฒนาแอปที่ระบุว่า อุปกรณ์ไม่ได้มาจากบลูทูธ ก็จะมีการทำดังนี้

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioSupported() API ระบบจะดำเนินการดังต่อไปนี้

  • [C-7-1] ต้องรองรับไคลเอ็นต์ unicast
  • [C-7-2] ต้องรองรับ 2M PHY
  • [C-7-3] ต้องรองรับการโฆษณา LE Extended
  • [C-7-4] ต้องรองรับการเชื่อมต่อ CIS อย่างน้อย 2 รายการใน CIG
  • [C-7-5] ต้องเปิดใช้ไคลเอ็นต์ BAP unicast, ผู้ประสานงานชุด CSIP, เซิร์ฟเวอร์ MCP, ตัวควบคุม VCP, เซิร์ฟเวอร์ CCP พร้อมกัน
  • [C-SR-1] แนะนําอย่างยิ่งให้เปิดใช้ไคลเอ็นต์ Unicast HAP

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioBroadcastSourceSupported() API ระบบจะดำเนินการดังต่อไปนี้

  • [C-8-1] ต้องรองรับลิงก์ BIS อย่างน้อย 2 ลิงก์ใน BIG
  • [C-8-2] ต้องเปิดใช้แหล่งที่มาของการออกอากาศ BAP, ผู้ช่วยออกอากาศ BAP พร้อมกัน
  • [C-8-3] ต้องรองรับการโฆษณาของ LE Periodic

หากการติดตั้งใช้งานอุปกรณ์แสดงผล true สำหรับ BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API ระบบจะดำเนินการดังต่อไปนี้

  • [C-9-1] ต้องรองรับ PAST (Periodic Advertising Sync Transfer)
  • [C-9-2] ต้องรองรับการโฆษณา LE Periodic

การใช้งานอุปกรณ์จะประกาศ 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 โดยที่อุปกรณ์จะอยู่ในทิศทางเดียวกันโดยอยู่ใน "ระนาบคู่ขนาน" เมื่อหน้าจออยู่ในทิศทางเดียวกัน

    เปลี่ยนข้อกำหนด [C-10-3] และ [C-10-4] เป็น 2.2.1 ฮาร์ดแวร์

  • [C-10-3] ต้องวัดและค่าชดเชย Rx เพื่อให้แน่ใจว่าค่ามัธยฐานของ BLE RSSI คือ -55dBm +/-10 dB ที่ระยะทาง 1 เมตรจากอุปกรณ์อ้างอิงที่ส่งที่ ADVERTISE_TX_POWER_HIGH
  • [C-10-4] ต้องวัดและชดเชยค่าชดเชย Tx เพื่อให้ค่ามัธยฐานของ BLE RSSI เท่ากับ -55dBm +/-10 dB เมื่อสแกนจากอุปกรณ์อ้างอิงที่อยู่ในตำแหน่งระยะ 1 เมตรและส่งสัญญาณที่ ADVERTISE_TX_POWER_HIGH

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

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

  • [C-SR-4] ได้รับการแนะนำอย่างยิ่งให้สนับสนุนสิ่งต่อไปนี้
    • เล 2 เอ็ม ฟี
    • LE Codec PHY
    • ส่วนขยายโฆษณา LE
    • การโฆษณาตามระยะเวลา
    • ชุดโฆษณาอย่างน้อย 10 ชุด
    • การเชื่อมต่อพร้อมกันอย่างน้อย 8 LE การเชื่อมต่อแต่ละรายการอาจอยู่ในบทบาท โทโพโลยีการเชื่อมต่ออย่างใดอย่างหนึ่ง
    • นโยบายความเป็นส่วนตัวของ LE Link Layer
    • ขนาด "รายการที่กำลังแก้ไข" อย่างน้อย 8 รายการ

7.4.4 การสื่อสารระยะใกล้

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

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

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

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

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

  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นหา NFC

  • ควรอยู่ในโหมดการค้นหา NFC ในขณะที่อุปกรณ์ทำงานอยู่ขณะที่หน้าจอทำงานอยู่และปลดล็อกหน้าจอล็อกแล้ว

  • ควรสามารถอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์บาร์โค้ด NFC แบบ Thinfilm

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

Android มีการสนับสนุนโหมด NFC Host Card Emulation (HCE)

หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NFC และ/หรือ NfcB) และรองรับการกำหนดเส้นทางรหัสแอปพลิเคชัน (AID) การใช้งานดังกล่าวจะส่งผลดังนี้

  • [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
  • [C-2-2] ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK

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

  • [C-3-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hcef
  • [C-3-2] ต้องใช้ API การจำลองการ์ด NFC ตามที่ระบุไว้ใน Android SDK

หากการใช้งานอุปกรณ์รวมการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทผู้อ่าน/ผู้เขียนเนื้อหาจะมีลักษณะดังนี้

  • [C-4-1] ต้องใช้ Android API ที่สอดคล้องกันตามที่ Android SDK บันทึกไว้
  • [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่าฟีเจอร์นี้ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจึงไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5 โปรโตคอลและ 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
  • [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
    • ต้องตรวจสอบว่าการสื่อสารของ IPv6 มีความเสถียรเหมือนกับ IPv4 ตัวอย่างเช่น
      • [C-0-4] ต้องใช้การเชื่อมต่อ IPv6 ในโหมด Doze
      • [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] ต้องรองรับการทำงานแบบ 2 สแต็กและ IPv6 เท่านั้นใน Wi-Fi

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

  • [C-2-1] ต้องรองรับการดำเนินการแบบ 2 สแต็กและ IPv6 เท่านั้นบนอีเทอร์เน็ต

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

  • [C-3-1] ต้องรองรับการดำเนินการ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ 2 สแต็ก) ในเครือข่ายมือถือ

หากการติดตั้งใช้งานอุปกรณ์รองรับเครือข่ายมากกว่า 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 ดังกล่าว ไปยัง System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
  • [C-1-2] ต้องดำเนินการตรวจจับแคพทีฟพอร์ทัล และรองรับการเข้าสู่ระบบ ผ่านแอปพลิเคชันแคพทีฟพอร์ทัลเมื่ออุปกรณ์เชื่อมต่อกับ เครือข่ายทุกประเภท รวมถึงเครือข่ายมือถือ/มือถือ, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
  • [C-1-3] ต้องรองรับการเข้าสู่ระบบแคพทีฟพอร์ทัลโดยใช้ DNS แบบ cleartext เมื่อกำหนดค่าอุปกรณ์ให้ใช้โหมด 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() แสดงค่า "true"

7.4.7 ประหยัดอินเทอร์เน็ต

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

  • [C-SR-1] แนะนำอย่างยิ่งให้ใช้โหมดประหยัดอินเทอร์เน็ต

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

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

  • [C-2-1] ต้องแสดงค่า RESTRICT_BACKGROUND_STATUS_DISABLED สำหรับ ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] ต้องไม่ออกอากาศ ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

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

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

  • [C-1-1] ต้องแจกแจงผู้อ่านองค์ประกอบความปลอดภัยที่ใช้ได้ผ่าน android.se.omapi.SEService.getReaders() API

  • [C-1-2] ต้องประกาศแฟล็กฟีเจอร์ที่ถูกต้องผ่าน 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] ต้องรายงานแฟล็กฟีเจอร์ฮาร์ดแวร์ android.hardware.uwb
  • [C-1-3] ต้องรองรับโปรไฟล์ UWB ที่เกี่ยวข้องทั้งหมดที่กำหนดไว้ใน การใช้งาน Android
  • [C-1-4] ต้องระบุค่าบริการเพื่อให้ผู้ใช้สามารถสลับสถานะเปิด/ปิดวิทยุ UWB
  • [C-1-5] ต้องบังคับใช้การใช้สิทธิ์ UWB_RANGING ของแอปโดยใช้สิทธิ์ 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 หงายขึ้นและเอียง 45 องศา
  • [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] ต้องรองรับโปรไฟล์ HLG HDR เป็นอย่างน้อยสำหรับอุปกรณ์กล้องทุกตัวที่รองรับเอาต์พุต 10 บิต
  • [C-2-2] ต้องรองรับเอาต์พุต 10 บิตสำหรับกล้องหลังหรือกล้องหน้าหลัก
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอาต์พุต 10 บิตสำหรับกล้องหลักทั้ง 2 ตัว
  • [C-2-3] ต้องรองรับโปรไฟล์ HDR เดียวกันสำหรับกล้องย่อยตัวจริงที่รองรับ BACKWARD_COMPATIBLE ของกล้องตรรกะ และกล้องตรรกะเอง

สำหรับอุปกรณ์กล้อง Logical ที่รองรับ HDR 10 บิตที่ใช้ android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้

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

7.5.1 กล้องหลัง

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

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

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

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

7.5.2 กล้องหน้า

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

เริ่มข้อกำหนดใหม่

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

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

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

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

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

  • [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
  • [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ กล้องถ่ายรูป 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 การทำงานของ API กล้องถ่ายรูป

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

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

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

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

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับตัวอย่างข้อมูลที่ให้ไว้กับ Callback ของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เพิ่มเติมเมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกเมธอด onPreviewFrame() และรูปแบบแสดงตัวอย่างคือ YCbCr_420_SP ซึ่งข้อมูลในไบต์[] ที่ส่งผ่านไปยัง onPreviewFrame() นั่นคือ NV21 ต้องเป็นค่าเริ่มต้น
  • [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่แสดงด้วยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างจากกล้องทั้งสำหรับกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (อุปกรณ์เปลี่ยนไฟล์วิดีโอและกล้องอาจใช้รูปแบบพิกเซลดั้งเดิม แต่การใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
  • [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่ โฆษณาความสามารถของ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities
  • [C-0-5] ต้องใช้ กล้องถ่ายรูป 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 และรายงานแฟล็กฟีเจอร์เฟรมเวิร์กที่เหมาะสม
  • [C-0-8] ต้องประกาศความสามารถของกล้องแต่ละตัวของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศแฟล็กฟีเจอร์ที่เหมาะสม และต้องระบุแฟล็กฟีเจอร์หากอุปกรณ์กล้องที่แนบอยู่รองรับฟีเจอร์นี้
  • [C-0-9] ต้องเผยแพร่ความตั้งใจ Camera.ACTION_NEW_PICTURE เมื่อใดก็ตามที่กล้องถ่ายภาพใหม่และมีการเพิ่มรูปภาพดังกล่าวไปยังที่เก็บสื่อแล้ว
  • [C-0-10] ต้องเผยแพร่ความตั้งใจ Camera.ACTION_NEW_VIDEO ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการของรูปภาพไปยังร้านค้าสื่อแล้ว
  • [C-0-11] ต้องมีกล้องทุกตัวที่เข้าถึงได้ผ่านทาง API ที่เลิกใช้งานแล้ว 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 ทั้งหมดที่หันไปทางทิศทางนั้นเป็นอุปกรณ์ย่อยจริง

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

  • [C-1-1] ต้องใช้ API กล้องดังกล่าวโดยใช้ android.hardware.camera2 API
  • อาจให้แท็กผู้ให้บริการและ/หรือส่วนขยายแก่ android.hardware.camera2 API

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

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

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

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

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

เริ่มข้อกำหนดใหม่

  • การใช้งานอุปกรณ์ที่ผู้ใช้หมุนเวียนไม่ได้ เช่น อุปกรณ์ยานยนต์

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

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

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

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

  • [C-0-1] ต้องมี Download Manager ที่แอปพลิเคชันอาจใช้ในการดาวน์โหลดไฟล์ข้อมูล และต้องดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 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

  • ควรเข้ากันได้กับโฮสต์ Android MTP อ้างอิงอย่าง 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 แบบ type-A หรือ type-C แบบมาตรฐานได้
  • [C-1-2] ต้องรายงานค่า iSerialNumber ที่ถูกต้องในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ผ่าน android.os.Build.SERIAL
  • [C-1-3] ต้องตรวจหาที่ชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และ "ต้องตรวจจับการเปลี่ยนแปลงในโฆษณา" หากรองรับ USB Type-C
  • [C-SR-1] พอร์ตควรใช้รูปแบบ micro-B, micro-AB หรือ Type-C USB เราแนะนำอย่างยิ่งให้อุปกรณ์ 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] แนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับข้อมูลและ ขับเคลื่อนการสลับบทบาทเมื่อรองรับโหมดโฮสต์ Type-C USB และ USB
  • ควรรองรับการส่งพลังงานสำหรับการชาร์จไฟแรงสูง และรองรับโหมดอื่น เช่น โหมดจอแสดงผลเอาต์
  • ควรใช้ Android Open Accessory (AOA) API และข้อมูลจำเพาะตามที่ระบุไว้ในเอกสารประกอบ Android SDK

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

  • [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
  • [C-2-2] คลาสที่จัดเก็บข้อมูล USB ขนาดใหญ่ต้องมีสตริง "android" ที่ตอนท้ายของสตริงคำอธิบายอินเทอร์เฟซ iInterface ของพื้นที่เก็บข้อมูล USB ขนาดใหญ่
  • ไม่ควรใช้เสียง AOAv2 ที่ระบุในเอกสารประกอบ Android Open Accessory Protocol 2.0 เสียง AOAv2 เลิกใช้งานแล้วตั้งแต่ Android เวอร์ชัน 8.0 (API ระดับ 26)

7.7.2 โหมดโฮสต์ USB

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

  • [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ของฮาร์ดแวร์ android.hardware.usb.host
  • [C-1-2] ต้องมีการสนับสนุนเพื่อเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ อุปกรณ์ต้องมีลักษณะดังนี้
    • มีพอร์ต C ในอุปกรณ์หรือจัดส่งพร้อมสายซึ่งปรับพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ไปยังพอร์ต USB type-C มาตรฐาน (อุปกรณ์ USB Type-C)
    • มีประเภท A ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ไปยังพอร์ต USB type-A มาตรฐาน
    • มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรจัดส่งพร้อมกับสายที่ปรับให้เข้ากับพอร์ตประเภท A แบบมาตรฐาน
  • [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB ประเภท A หรือพอร์ตไมโคร AB เป็นพอร์ตประเภท C (เต้ารับ)
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้ใช้ คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะอยู่ในโหมดโฮสต์ การโฆษณาแหล่งกระแสไฟฟ้าอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของการแก้ไขข้อมูลจำเพาะของสาย USB Type-C 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงเอาต์พุตปัจจุบันสำหรับการชาร์จ Downstream Port(CAB2) ตามที่ระบุไว้ในข้อมูลจำเพาะของการชาร์จแบตเตอรี่ USB2
  • ควรใช้และสนับสนุนมาตรฐาน USB Type-C

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

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

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

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

หากอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C ไหม

  • [C-4-1] ต้องใช้ฟังก์ชันการทำงานของพอร์ตบทบาทแบบคู่ตามที่ระบุไว้ในข้อกำหนดเฉพาะ USB Type-C (ส่วนที่ 4.5.1.3.3) สำหรับ Dual Role Ports ในอุปกรณ์ที่มีช่องเสียบเสียง 3.5 มม. การตรวจหาซิงก์ USB (โหมดโฮสต์) อาจปิดอยู่โดยค่าเริ่มต้น แต่ผู้ใช้ต้องเปิดใช้ได้
  • [C-SR-2] ขอแนะนำให้รองรับ DisplayPort และควรรองรับอัตราข้อมูล SuperSpeed ของ USB และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทข้อมูลและพลังงาน
  • [C-SR-3] แนะนำอย่างยิ่งให้ไม่รองรับโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก A ของการแก้ไขข้อกำหนดของสาย USB Type-C และขั้วต่อ 1.2
  • ควรใช้โมเดล Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบของอุปกรณ์ ตัวอย่างเช่น อุปกรณ์มือถือควรใช้รูปแบบ try.SNK

7.8 เสียง

7.8.1 ไมโครโฟน

หากอุปกรณ์มีไมโครโฟน จะมีผลดังนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-1-2] ต้องเป็นไปตามข้อกำหนดเกี่ยวกับการบันทึกเสียงใน ส่วนที่ 5.4
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงใน ส่วนที่ 5.6
  • [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 ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นไม่ต้องดำเนินการอย่างน้อย

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

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

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

โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2.2.1

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

เสียงใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz

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

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

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

  • [C-1-1] การตอบสนองกำลังเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องมีขนาดไม่เกิน 15 dB ต่ำกว่าการตอบสนองที่ 2 kHz
  • [C-1-2] อัตราส่วนสัญญาณที่ไม่มีน้ำหนักต่อสัญญาณรบกวนของไมโครโฟนสูงกว่า 18.5 kHz ต่อ 20 kHz สำหรับเสียง 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง" ให้ทำดังนี้

  • [C-2-1] การตอบสนองเฉลี่ยของลำโพงที่มีความเร็ว 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB ต่ำกว่าการตอบสนองที่ 2 kHz

7.8.4 ความสมบูรณ์ของสัญญาณ

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

  • ควรมีเส้นทางสัญญาณเสียงที่ไม่มีข้อบกพร่องสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์มือถือ ตามที่กำหนดโดยข้อบกพร่อง 0 รายการที่วัดได้ระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ OboeTester "Automated Glitch Test"

การทดสอบต้องใช้ดองเกิลเสียงวนซ้ำซึ่งใช้ในช่องเสียบ 3.5 มม. โดยตรงและ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

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

โหมด Perf การแชร์ อัตราการสุ่มตัวอย่างออก ในชาน เพลงชวนคุย
เวลาในการตอบสนองต่ำ พิเศษ ไม่ได้ระบุ 1 2
เวลาในการตอบสนองต่ำ พิเศษ ไม่ได้ระบุ 2 1
เวลาในการตอบสนองต่ำ แชร์ ไม่ได้ระบุ 1 2
เวลาในการตอบสนองต่ำ แชร์ ไม่ได้ระบุ 2 1
ไม่มี แชร์ 48000 1 2
ไม่มี แชร์ 48000 2 1
ไม่มี แชร์ 44100 1 2
ไม่มี แชร์ 44100 2 1
ไม่มี แชร์ 16000 1 2
ไม่มี แชร์ 16000 2 1

สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อเสียงรบกวน (SNR) และการบิดเบี้ยวรวมฮาร์โมนิก (THD) สำหรับไซน์ 2000 Hz

ตัวแปรสัญญาณ THD SNR
ลำโพงหลักในตัว วัดโดยใช้ไมโครโฟนอ้างอิงภายนอก น้อยกว่า 3.0% >= 50 เดซิเบล
ไมโครโฟนหลักในตัว วัดโดยใช้ลำโพงอ้างอิงภายนอก น้อยกว่า 3.0% >= 50 เดซิเบล
ช่องเสียบแบบแอนะล็อกในตัว 3.5 มม. ผ่านการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ < 1% >= 60 เดซิเบล
อะแดปเตอร์ USB ที่ให้มาพร้อมกับโทรศัพท์ ได้รับการทดสอบโดยใช้อะแดปเตอร์แบบวนกลับ น้อยกว่า 1.0% >= 60 เดซิเบล

7.9 Virtual Reality

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

7.9.1 โหมด Virtual Reality

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

7.9.2 โหมด Virtual Reality - ประสิทธิภาพสูง

หากอุปกรณ์รองรับโหมด VR อุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องมี 2 Physical Core เป็นอย่างน้อย
  • [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] ต้องใช้การรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องใช้การรองรับ AHardwareBuffer ที่มีชุดค่าผสมแฟล็กการใช้งานทั้งหมด AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT สำหรับรูปแบบต่อไปนี้เป็นอย่างน้อย: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
  • [C-SR-5] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีมากกว่า 1 เลเยอร์ รวมถึงแฟล็กและรูปแบบที่ระบุใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps โดยบีบอัดให้มีค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 1920 x1080 จำนวน 4 อินสแตนซ์ที่ 30 fps-10 Mbps หรือ 1920 x 1920 x 20fps 2 อินสแตนซ์)
  • [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องสามารถถอดรหัสได้อย่างน้อย 1920 x 1080 ที่ 30 fps ที่บีบอัดให้มีค่าเฉลี่ย 10 Mbps และควรสามารถถอดรหัสได้ 3840 x 2160 ที่อัตรา 30 fps - 20 fps เป็น 30 fps ถึง 30 fps ที่ความเร็วเฉลี่ย 3840 x 2160 ต่อวินาทีเป็นอย่างน้อย (30 fps ถึง 20 FPS
  • [C-1-13] ต้องรองรับ API ของ HardwarePropertiesManager.getDeviceTemperatures และแสดงผลค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
  • [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 เพื่อแสดงจำนวนของแกน CPU ที่มีเฉพาะในแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าเท่านั้น

หากระบบรองรับแกนพิเศษ แกนหลักจะเป็นดังนี้

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

7.10 การโต้ตอบการสัมผัส

เริ่มข้อกำหนดใหม่

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

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

  • [7.10/C] ต้องคืนค่า "เท็จ" สำหรับ Vibrator.hasVibrator()

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

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามการแมปค่าคงที่แบบรู้สึกได้ สิ่งที่จะเกิดขึ้นมีดังนี้

สิ้นสุดข้อกำหนดใหม่

โปรดดูข้อกำหนดเฉพาะอุปกรณ์ในส่วน 2.2.1

7.11 ชั้นเรียนประสิทธิภาพของสื่อ

สามารถดูระดับประสิทธิภาพของสื่อของการใช้งานอุปกรณ์ได้จาก API ของ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะมีการกำหนดข้อกำหนดสำหรับคลาสประสิทธิภาพสื่อสำหรับ 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 โดยใช้บัฟเฟอร์การเขียนขนาด 4KB

8.3 โหมดประหยัดพลังงาน

หากการใช้งานอุปกรณ์มีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP (เช่น ที่เก็บข้อมูลสแตนด์บายแอป, Doze) หรือขยายฟีเจอร์ต่างๆ เพื่อใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ถูกจำกัด การดำเนินการดังกล่าวจะส่งผลดังต่อไปนี้

  • [C-1-1] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการทริกเกอร์ การบำรุงรักษา อัลกอริทึมการปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางหรือ DeviceConfig ของโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
  • [C-1-2] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางหรือ DeviceConfig เพื่อจัดการการควบคุมงาน สัญญาณเตือน และเครือข่ายสำหรับแอปในแต่ละที่เก็บข้อมูลสำหรับการสแตนด์บายแอป
  • [C-1-3] ต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP สำหรับจำนวนที่เก็บข้อมูลสแตนด์บายแอปที่ใช้สำหรับสแตนด์บายแอป
  • [C-1-4] ต้องใช้ที่เก็บข้อมูลสแตนด์บายแอปและ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] ต้องแสดงผล true เป็นเวลา PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
  • [C-1-6] ต้องมีค่าใช้จ่ายสำหรับผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้น จากโหมดสแตนด์บายแอปและ Doze หรือการเพิ่มประสิทธิภาพแบตเตอรี่ใดๆ และต้องใช้ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS ในการขอให้ผู้ใช้อนุญาตให้แอปละเว้นการเพิ่มประสิทธิภาพแบตเตอรี่
  • [C-SR-1] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้สามารถเปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
  • [C-SR-2] ขอแนะนำเป็นอย่างยิ่งว่าจะแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze

หากการนำอุปกรณ์ไปใช้งานขยายขอบเขตฟีเจอร์การจัดการพลังงานที่รวมอยู่ใน AOSP และส่วนขยายดังกล่าวใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลสแตนด์บายแอปที่หายาก โปรดดูส่วนที่ 3.5.1

นอกจากโหมดประหยัดพลังงานแล้ว การติดตั้งใช้งานอุปกรณ์ Android อาจใช้สถานะกำลังนอนหลับส่วนใดส่วนหนึ่งหรือทั้งหมด 4 แบบตามที่กำหนดโดยการกำหนดค่าขั้นสูงและอินเทอร์เฟซพลังงาน (ACPI)

หากการติดตั้งใช้งานอุปกรณ์มีสถานะกำลังไฟ S4 ตามที่กำหนดโดย ACPI มีดังนี้

  • [C-1-1] ต้องป้อนสถานะนี้หลังจากที่ผู้ใช้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ใช้งานเท่านั้น (เช่น ปิดฝาที่ชิ้นส่วนของอุปกรณ์หรือปิดยานพาหนะหรือโทรทัศน์) และก่อนที่ผู้ใช้จะเปิดใช้งานอุปกรณ์อีกครั้ง (เช่น โดยเปิดฝาหรือเปิดรถยนต์หรือโทรทัศน์)

หากการติดตั้งใช้งานอุปกรณ์มีสถานะพลังงาน S3 ตามที่กำหนดโดย ACPI มีดังนี้

  • [C-2-1] ต้องตรงตาม C-1-1 ข้างต้น หรือต้องป้อนสถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่จำเป็นต้องใช้ทรัพยากรระบบ (เช่น หน้าจอ, CPU)

    ในทางกลับกัน ต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรระบบตามที่อธิบายไว้ใน SDK นี้

    ตัวอย่างเช่น ในขณะที่แอปพลิเคชันของบุคคลที่สามจะขอเปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือให้ CPU ทำงานอย่างต่อเนื่อง PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่ป้อนสถานะ S3 เว้นแต่ผู้ใช้ได้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ใช้งาน ดังที่ได้อธิบายไว้ใน C-1-1 ในทางกลับกัน ในช่วงเวลาหนึ่งเมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามทำผ่าน JobScheduler หรือมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ว่าผู้ใช้ทำให้อุปกรณ์อยู่ในสถานะไม่ใช้งาน ตัวอย่างเหล่านี้ไม่ใช่ตัวอย่างที่ครอบคลุมและ AOSP ใช้สัญญาณการปลุกระบบที่ครอบคลุมซึ่งจะกระตุ้นการปลุกระบบจากสถานะนี้

8.4 การทำบัญชีการใช้พลังงาน

การทำบัญชีและการรายงานการใช้พลังงานที่ถูกต้องแม่นยำมากขึ้นจะทำให้นักพัฒนาแอปได้รับทั้งสิ่งจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

  • [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 ประสิทธิภาพที่สม่ำเสมอ

ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่มีประสิทธิภาพสูงเป็นเวลานาน เนื่องจากแอปอื่นๆ ทำงานอยู่เบื้องหลังหรือการควบคุม CPU เนื่องจากขีดจำกัดอุณหภูมิ Android มีอินเทอร์เฟซแบบเป็นโปรแกรมที่เมื่ออุปกรณ์มีความสามารถ แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอันดับต้นๆ จะสามารถขอให้ระบบเพิ่มประสิทธิภาพการจัดสรรทรัพยากรเพื่อจัดการกับความผันผวนดังกล่าวได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด API ของ PowerManager.isSustainedPerformanceModeSupported()

  • ควรรองรับโหมดประสิทธิภาพที่ยั่งยืน

หากการใช้งานอุปกรณ์รายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืน การตั้งค่าดังกล่าวจะมีผลดังนี้

  • [C-1-1] ต้องให้ระดับประสิทธิภาพที่สม่ำเสมอแก่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าสูงสุดเป็นเวลาอย่างน้อย 30 นาทีเมื่อแอปขอ
  • [C-1-2] ต้องใช้ Window.setSustainedPerformanceMode() API และ API อื่นๆ ที่เกี่ยวข้อง

หากการใช้งานอุปกรณ์มี CPU 2 แกนขึ้นไป การใช้งานจะมีลักษณะดังต่อไปนี้

  • ควรระบุแกนพิเศษอย่างน้อย 1 รายการที่แอปพลิเคชันพื้นฐานอันดับต้นๆ จองได้

หากการใช้งานอุปกรณ์รองรับการจองแกนพิเศษ 1 แกนสำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า จะมีการดำเนินการต่อไปนี้

  • [C-2-1] ต้องรายงานหมายเลขรหัสของแกนพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนจองได้ผ่านเมธอด Process.getExclusiveCores() API
  • [C-2-2] ต้องไม่อนุญาตให้กระบวนการด้านพื้นที่ของผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้ให้ทำงานบนแกนเฉพาะ แต่อาจอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานตามความจำเป็น

หากอุปกรณ์ไม่รองรับการใช้งานอุปกรณ์หลัก (พิเศษ) ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้

  • [C-3-1] ต้องแสดงผลรายการที่ว่างเปล่าผ่านทางเมธอด API Process.getExclusiveCores()

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 Roles Model ตามที่ระบุไว้ในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ Android กล่าวอย่างเจาะจงคือ ต้องบังคับใช้สิทธิ์และบทบาทแต่ละรายการตามที่กำหนดไว้ในเอกสาร SDK ไม่อนุญาตให้ละ แก้ไข หรือละเว้นสิทธิ์และบทบาทใดๆ

  • อาจเพิ่มสิทธิ์เพิ่มเติม หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_FLAG_PRIVILEGED ต้องให้สิทธิ์แก่แอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจของระบบ (รวมถึง ไฟล์ APEX) เท่านั้น และอยู่ภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอป การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและยึดตาม สิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง system/priv-app etc/permissions/

สิทธิ์ที่มีระดับการป้องกันที่เป็นอันตรายคือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะขอขณะรันไทม์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะสำหรับผู้ใช้เพื่อตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอไหม และมีอินเทอร์เฟซให้ผู้ใช้จัดการสิทธิ์รันไทม์หรือไม่

  • [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงรายการเดียวเท่านั้น

  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอป ยกเว้นในกรณีต่อไปนี้

    • โดยจะติดตั้งไว้แล้วเมื่อมีการจัดส่งอุปกรณ์ และ

    • จะขอคำยินยอมจากผู้ใช้ได้ ก่อนที่แอปพลิเคชันจะใช้สิทธิ์นั้น

      หรือ

    • สิทธิ์รันไทม์มาจากนโยบายการให้สิทธิ์เริ่มต้นหรือสำหรับการคงบทบาทแพลตฟอร์ม

  • [C-0-6] ต้องให้สิทธิ์ android.permission.RECOVER_KEYSTORE แก่แอประบบที่ลงทะเบียน Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างถูกต้องเท่านั้น Agent การกู้คืนที่มีการรักษาความปลอดภัยอย่างเหมาะสมหมายถึง Agent ซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งมาพร้อมกับฮาร์ดแวร์ที่ปลอดภัยซึ่งมีการปกป้องเทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key ห้องนิรภัย เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซในปัจจัยที่เกี่ยวข้องกับหน้าจอล็อก

การติดตั้งใช้งานอุปกรณ์

  • [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 ที่กำหนดเองเพื่อข้ามการจำกัดสิทธิ์ที่กำหนดไว้ใน setPermissionsPolicy และ setPermissionsGrantState 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 ได้ สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง 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 Content Capture" "ข้อมูลระดับระบบปฏิบัติการและข้อมูลแอมเบียนท์ รวมถึง 9.8.15 การติดตั้งใช้งาน API ที่แซนด์บ็อกซ์"

  • [C-4-2] ต้องไม่มีสิทธิ์ android.permission.INTERNET ซึ่งจะเข้มงวดกว่า "แนะนำอย่างยิ่ง" ในหัวข้อ 9.8.6
  • [C-4-3] ต้องไม่เชื่อมโยงกับแอปอื่นๆ ยกเว้นแอประบบต่อไปนี้ บลูทูธ, รายชื่อติดต่อ, สื่อ, โทรศัพท์, SystemUI และคอมโพเนนต์ที่ให้บริการ Internet API ซึ่งจะเข้มงวดกว่า "แนะนำอย่างยิ่ง" ในหัวข้อ 9.8.6

เริ่มข้อกำหนดใหม่

หากการใช้งานอุปกรณ์มีแอปพลิเคชันเริ่มต้นเพื่อรองรับ VoiceInteractionService การใช้งานจะมีลักษณะดังนี้

  • [C-5-1] ต้องไม่ให้ ACCESS_FINE_LOCATION เป็นค่าเริ่มต้นสำหรับแอปพลิเคชันนั้น

สิ้นสุดข้อกำหนดใหม่

9.2 การแยก UID และกระบวนการ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับโมเดลแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น Unixstyle UID ที่ไม่ซ้ำกัน และอยู่ในกระบวนการที่แยกจากกัน
  • [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็นรหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงนามและสร้างขึ้นอย่างถูกต้อง ดังที่ระบุไว้ในข้อมูลอ้างอิงความปลอดภัยและสิทธิ์

9.3 สิทธิ์ของระบบไฟล์

การติดตั้งใช้งานอุปกรณ์

9.4 สภาพแวดล้อมการดำเนินการสำรอง

การใช้งานอุปกรณ์ต้องรักษารูปแบบการรักษาความปลอดภัยและสิทธิ์ของ Android ให้สอดคล้องกัน แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นซึ่งไม่ใช่ Dalvik Executable Format หรือโค้ดแบบเนทีฟ กล่าวคือ

  • [C-0-1] รันไทม์สำรองต้องเป็นแอปพลิเคชัน Android เอง และปฏิบัติตามรูปแบบความปลอดภัยของ Android แบบมาตรฐานตามที่อธิบายไว้ในส่วนที่ 9

  • [C-0-2] รันไทม์สำรองจะต้องไม่มีสิทธิ์เข้าถึงทรัพยากรที่ปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

  • [C-0-3] รันไทม์สำรองต้องไม่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จาก ฟีเจอร์ที่มีการป้องกันโดยสิทธิ์ของ Android ซึ่งจำกัดไว้เฉพาะแอปพลิเคชันระบบ

  • [C-0-4] รันไทม์สำรองต้องเป็นไปตามโมเดลแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์สำรองต้องไม่ใช้แซนด์บ็อกซ์ของแอปอื่นๆ ที่ติดตั้งในอุปกรณ์ซ้ำ ยกเว้นในกรณีที่ใช้กลไกมาตรฐานของ Android ที่มีรหัสผู้ใช้และใบรับรองที่ลงนามร่วมกัน

  • [C-0-5] รันไทม์สำรองต้องไม่เปิด ให้สิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่เกี่ยวข้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] ต้องไม่เปิดตัวรันไทม์สำรอง อนุญาต หรือให้สิทธิ์ของผู้ใช้ระดับสูง (รูท) หรือรหัสผู้ใช้อื่นๆ แก่แอปพลิเคชันอื่นๆ

  • [C-0-7] เมื่อมีการรวมไฟล์ .apk ของรันไทม์ทางเลือกไว้ในอิมเมจระบบของการใช้งานอุปกรณ์ ไฟล์ดังกล่าวต้องเซ็นชื่อด้วยคีย์ที่ต่างจากคีย์ที่ใช้ในการรับรองแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์

  • [C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์สำรองต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ของ Android ที่แอปพลิเคชันใช้

  • [C-0-9] เมื่อแอปพลิเคชันต้องใช้ทรัพยากรของอุปกรณ์ที่มีสิทธิ์ของ Android ที่เกี่ยวข้อง (เช่น กล้องถ่ายรูป, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้

  • [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่บันทึกความสามารถของแอปพลิเคชันในลักษณะนี้ สภาพแวดล้อมรันไทม์ต้องแสดงสิทธิ์ทั้งหมดที่รันไทม์นั้นมีอยู่เมื่อติดตั้งแอปพลิเคชันที่ใช้รันไทม์ดังกล่าว

  • รันไทม์สำรองควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android ที่แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

  • รันไทม์สำรองอาจมีแซนด์บ็อกซ์ Android รายการเดียวที่แชร์โดยแอปพลิเคชันทั้งหมดโดยใช้รันไทม์สำรอง

9.5 การสนับสนุนผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบและโคลนโปรไฟล์ผู้ใช้ด้วยการแยกบางส่วน(เช่น โปรไฟล์ผู้ใช้เพิ่มเติมเดี่ยวในประเภท android.os.usertype.profile.CLONE)

  • การใช้งานอุปกรณ์อาจแต่ไม่ควรเปิดใช้ผู้ใช้หลายคน หากใช้สื่อแบบถอดได้สำหรับที่จัดเก็บข้อมูลภายนอกหลัก

หากการใช้งานอุปกรณ์มีการรองรับผู้ใช้หลายคน จะมีผลดังนี้

  • [C-1-2] สำหรับผู้ใช้แต่ละราย ต้องใช้โมเดลการรักษาความปลอดภัย ที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ใน เอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ ใน API
  • [C-1-3] ต้องมีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก (หรือที่เรียกอีกชื่อหนึ่งว่า /sdcard) สำหรับอินสแตนซ์ของผู้ใช้แต่ละรายการ
  • [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และเรียกใช้ในนามของผู้ใช้นั้นไม่สามารถลงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองคนจะจัดเก็บอยู่ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
  • [C-1-5] ต้องเข้ารหัสเนื้อหาในการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บอยู่ในสื่อที่นำออกไม่ได้ซึ่งเข้าถึงได้เฉพาะระบบเท่านั้นหากอุปกรณ์ใช้สื่อที่นำออกได้สำหรับ API การจัดเก็บข้อมูลภายนอก เนื่องจากการดำเนินการดังกล่าวจะทำให้พีซีโฮสต์อ่านสื่อไม่ได้ การใช้งานอุปกรณ์จึงจำเป็นจะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

หากการใช้งานอุปกรณ์รวมการรองรับผู้ใช้หลายคนแล้ว สำหรับผู้ใช้ทั้งหมด ยกเว้นผู้ใช้ที่สร้างขึ้นเพื่อการใช้อินสแตนซ์คู่ของแอปเดียวกันโดยเฉพาะ จะมีการดำเนินการดังต่อไปนี้

  • [C-2-1] ต้องมีพื้นที่เก็บข้อมูลแอปพลิเคชันที่แชร์แบบแยกต่างหากและแยกต่างหาก (หรือ /sdcard) สำหรับอินสแตนซ์ผู้ใช้แต่ละรายการ
  • [C-2-2] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของผู้ใช้และทำงานอยู่ในนามของผู้ใช้ที่กำหนดนั้นไม่สามารถแสดงรายการ อ่าน หรือเขียนในไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้งสองจะเก็บไว้ในปริมาณหรือระบบไฟล์เดียวกันก็ตาม

การใช้งานอุปกรณ์อาจสร้างโปรไฟล์ผู้ใช้ประเภท android.os.usertype.profile.CLONE เพิ่มเติม 1 รายการสำหรับผู้ใช้หลัก (และกับผู้ใช้หลักเท่านั้น) เพื่อวัตถุประสงค์ในการเรียกใช้อินสแตนซ์คู่ของแอปเดียวกัน อินสแตนซ์คู่เหล่านี้ใช้พื้นที่เก็บข้อมูลที่แยกบางส่วน โดยแสดงต่อผู้ใช้ใน Launcher พร้อมกันและปรากฏในมุมมองล่าสุดเดียวกัน เช่น ใช้เพื่อรองรับผู้ใช้ติดตั้ง 2 อินสแตนซ์แยกกันของแอปเดียวในอุปกรณ์แบบ 2 ซิม

หากการนำอุปกรณ์ไปใช้งานสร้างโปรไฟล์ผู้ใช้เพิ่มเติมที่กล่าวถึงข้างต้น ระบบจะดำเนินการดังต่อไปนี้

  • [C-3-1] ต้องให้สิทธิ์เข้าถึงเฉพาะพื้นที่เก็บข้อมูลหรือข้อมูลที่โปรไฟล์ผู้ใช้หลักเข้าถึงได้อยู่แล้ว หรือเป็นของโปรไฟล์ผู้ใช้เพิ่มเติมนี้โดยตรง
  • [C-3-2] ต้องไม่มีเป็นโปรไฟล์งาน
  • [C-3-3] ต้องมีการแยกไดเรกทอรีข้อมูลแอปส่วนตัวจากบัญชีผู้ใช้หลัก
  • [C-3-4] ต้องไม่อนุญาตให้สร้างโปรไฟล์ผู้ใช้เพิ่มเติมหากมีการจัดสรรเจ้าของอุปกรณ์ (ดูหัวข้อ 3.9.1) หรืออนุญาตให้มีการจัดสรรเจ้าของอุปกรณ์โดยไม่ต้องนำโปรไฟล์ผู้ใช้เพิ่มเติมออกก่อน

เริ่มข้อกำหนดใหม่

หากการนำอุปกรณ์ไปใช้งานสร้างโปรไฟล์ผู้ใช้เพิ่มเติมที่กล่าวถึงข้างต้น ระบบจะดำเนินการดังต่อไปนี้

  • [C-4-5] ต้องแยกความแตกต่างของไอคอนแอปพลิเคชันแบบอินสแตนซ์คู่ เมื่อแสดงไอคอนต่อผู้ใช้
  • [C-4-6] ต้องจัดสรรค่าใช้จ่ายให้กับผู้ใช้ในการลบข้อมูลโปรไฟล์โคลนทั้งหมด
  • [C-4-7] ต้องถอนการติดตั้งแอปโคลนทั้งหมด ลบไดเรกทอรีข้อมูลแอปส่วนตัวและเนื้อหาในแอป และลบข้อมูลโปรไฟล์โคลนเมื่อผู้ใช้เลือกที่จะลบข้อมูลโปรไฟล์โคลนทั้งหมด
  • ควรแจ้งให้ผู้ใช้ลบข้อมูลโปรไฟล์โคลนทั้งหมดเมื่อมีการลบแอปโคลนรายการสุดท้าย
  • [C-4-8] ต้องแจ้งให้ผู้ใช้ทราบว่าระบบจะลบข้อมูลแอปเมื่อถอนการติดตั้งแอปพลิเคชัน การโคลน หรือให้ตัวเลือกกับผู้ใช้ในการเก็บข้อมูลแอป เมื่อถอนการติดตั้งแอปพลิเคชันจากอุปกรณ์แล้ว
  • [C-4-9] ต้องลบไดเรกทอรีข้อมูลแอปส่วนตัวและเนื้อหาเมื่อผู้ใช้เลือกลบข้อมูลระหว่างถอนการติดตั้ง

  • [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] ต้องรับค่าข้อจำกัดทั้งหมดของผู้ใช้นโยบายด้านอุปกรณ์ และข้อจำกัดที่ไม่เกี่ยวข้องกับผู้ใช้ที่เลือกไว้(รายการด้านล่าง) จะมีผลกับผู้ใช้หลักของอุปกรณ์กับโปรไฟล์ผู้ใช้เพิ่มเติมนี้

  • [C-4-3] ต้องอนุญาตให้เขียนเฉพาะรายชื่อติดต่อจากโปรไฟล์เพิ่มเติมนี้ผ่าน Intent ต่อไปนี้เท่านั้น

  • [C-4-4] ต้องไม่มีการซิงค์รายชื่อติดต่อสำหรับแอปพลิเคชันที่ทำงานในโปรไฟล์ผู้ใช้เพิ่มเติมนี้

  • [C-4-14] ต้องมีสิทธิ์และการจัดการพื้นที่เก็บข้อมูลแยกต่างหาก สำหรับแอปพลิเคชันที่ทำงานในโปรไฟล์เพิ่มเติมนี้

  • [C-4-5] ต้องอนุญาตเฉพาะแอปพลิเคชันในโปรไฟล์เพิ่มเติมที่มีกิจกรรม Launcher เพื่อเข้าถึงรายชื่อติดต่อที่โปรไฟล์ผู้ใช้หลักเข้าถึงได้อยู่แล้ว

สิ้นสุดข้อกำหนดใหม่

9.6 คำเตือนทาง SMS แบบพรีเมียม

Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมขาออก ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการเครือข่ายซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony ระบบจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปซึ่งกำหนดในไฟล์ /data/misc/sms/codes.xml ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ที่มีการติดตั้งใช้งาน ซึ่งเป็นไปตามข้อกำหนดนี้

9.7 ฟีเจอร์ความปลอดภัย

การใช้งานอุปกรณ์ต้องแน่ใจถึงการปฏิบัติตามข้อกำหนดของฟีเจอร์ความปลอดภัยทั้งในเคอร์เนลและแพลตฟอร์มตามที่อธิบายไว้ด้านล่าง

แซนด์บ็อกซ์ของ Android ประกอบด้วยคุณลักษณะที่ใช้ระบบการควบคุมการเข้าถึง (MAC) ที่บังคับของการรักษาความปลอดภัย (SELinux) แซนด์บ็อกซ์ Seccomp และ คุณลักษณะด้านความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่เดิม แม้ในขณะที่ใช้งาน SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ภายใต้เฟรมเวิร์กของ Android ก็ตาม
  • [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดด้านความปลอดภัยและถูกบล็อกโดยฟีเจอร์ความปลอดภัยที่อยู่ด้านล่างเฟรมเวิร์ก Android แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อมีการละเมิดด้านความปลอดภัยที่ไม่ได้ถูกบล็อก ซึ่งส่งผลให้การเจาะช่องโหว่สำเร็จ
  • [C-0-3] ต้องไม่ใช้งาน SELinux หรือฟีเจอร์ด้านความปลอดภัยอื่นใดภายใต้เฟรมเวิร์ก Android ที่กำหนดค่าสำหรับผู้ใช้หรือนักพัฒนาแอป
  • [C-0-4] ต้องไม่อนุญาตแอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) เพื่อกำหนดค่านโยบายที่ละเมิดความเข้ากันได้
  • [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการให้แคบลงได้ตามที่อธิบายไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์สของ Android
  • [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์แอปพลิเคชันเคอร์เนล ซึ่งอนุญาตการกรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบหลายเธรด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางเป็นไปตามข้อกำหนดนี้ผ่านการเปิดใช้ seccomp-BPF ที่มี Threadgroup synchronization (TSYNC) ตามที่อธิบายไว้ ในส่วน Kernel Configuration ของ source.android.com

ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการปกป้องตนเองเป็นส่วนสำคัญในการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องใช้กลไกการป้องกันการล้นของสแต็กเคอร์เนล ตัวอย่างของกลไกดังกล่าวคือ 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] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในเครื่องที่ไม่ได้กำหนดค่าเริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคาดเดาค่าที่คอมไพเลอร์ใช้ในการเริ่มต้นในเครื่อง

  • [C-SR-2] แนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนล ซึ่งเขียนเฉพาะระหว่างการเริ่มต้นที่ได้รับการทำเครื่องหมายเป็นอ่านอย่างเดียวหลังจาก การเริ่มต้น (เช่น __ro_after_init)

  • [C-SR-3] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของรหัสเคอร์เนลและหน่วยความจำ และเพื่อหลีกเลี่ยงการรับแสงที่อาจส่งผลต่อการสุ่ม (เช่น CONFIG_RANDOMIZE_BASE ด้วยเอนโทรปี Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

  • [C-SR-4] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้ความสมบูรณ์ของโฟลว์การควบคุม (CFI) ในเคอร์เนล เพื่อเสริมการป้องกันการโจมตีโดยใช้โค้ดซ้ำ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

  • [C-SR-5] แนะนำอย่างยิ่งไม่ให้ปิดใช้ Control-Flow Integrity (CFI), Shadow Call Stack (SCS) หรือ Integer Overflow Sanitization (IntSan) บนคอมโพเนนต์ที่เปิดใช้

  • [C-SR-6] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์พื้นที่ผู้ใช้ที่ละเอียดอ่อนด้านความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan

  • [C-SR-7] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนล เพื่อป้องกันการใช้ตัวแปรภายในเครื่องที่ไม่ได้เริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรคิดเอาค่าที่คอมไพเลอร์ใช้เพื่อเริ่มต้นในเครื่อง

  • [C-SR-8] แนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นฮีปในเคอร์เนลเพื่อป้องกันการใช้งานการจัดสรรฮีปแบบไม่เริ่มต้น (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) และไม่ควรคาดเดาค่าที่เคอร์เนลใช้ในการเริ่มต้นการจัดสรรเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนลของ Linux ที่รองรับ SELinux จะ

  • [C-1-1] ต้องใช้ SELinux
  • [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้ส่วนกลาง
  • [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนในโหมดที่อนุญาต ซึ่งรวมถึงโดเมนที่เจาะจงเฉพาะอุปกรณ์/ผู้ให้บริการ
  • [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่มีอยู่ในโฟลเดอร์ระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ ไม่อนุญาตทั้งหมดที่มีอยู่ สำหรับทั้งโดเมน AOSP SELinux และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
  • [C-1-5] ต้องใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไป ในแซนด์บ็อกซ์ SELinux ตามแอปพลิเคชันที่มีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
  • ควรเก็บนโยบาย SELinux เริ่มต้นที่ระบุไว้ในโฟลเดอร์ระบบ/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_SRMW_TAGS สำหรับอุปกรณ์ AGAv8 หรือ CONFIG_KASAN)
  • [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] ขอแนะนำอย่างยิ่งให้จำกัดแอปพลิเคชันที่เชื่อถือได้ให้เข้าถึงเฉพาะหน่วยความจำที่มีการแชร์อย่างชัดแจ้งกับแอปพลิเคชันผ่านโปรโตคอลข้างต้นเท่านั้น หากอุปกรณ์รองรับระดับข้อยกเว้น Arm S-EL2 ควรบังคับใช้โดยเครื่องมือจัดการพาร์ติชันที่ปลอดภัย มิฉะนั้น ระบบปฏิบัติการ TEE ควรบังคับใช้

เริ่มข้อกำหนดใหม่

เทคโนโลยีความปลอดภัยของหน่วยความจำเป็นเทคโนโลยีที่ช่วยลดข้อบกพร่องในชั้นต่อไปนี้เป็นอย่างน้อย ซึ่งมีความเป็นไปได้สูง (>90%) ในแอปพลิเคชันที่ใช้ตัวเลือกไฟล์ Manifest android:memtagMode

  • ฮีปบัฟเฟอร์ล้น
  • ใช้หลังจากฟรี
  • ดับเบิลฟรี
  • ปราศจาก (ไม่มีมัลแวร์)

การติดตั้งใช้งานอุปกรณ์

  • [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] ต้องอนุญาตให้ผู้ใช้ Shell ตั้งค่า arm64.memtag.bootctl

  • [C-3-3] ต้องอนุญาตให้กระบวนการอ่าน arm64.memtag.bootctl ได้

  • [C-3-4] ต้องตั้งค่า arm64.memtag.bootctl เป็นสถานะที่ขอในปัจจุบันเมื่อเปิดเครื่อง อุปกรณ์ต้องอัปเดตพร็อพเพอร์ตี้ด้วยหากการใช้งานอุปกรณ์อนุญาตให้แก้ไขสถานะได้โดยไม่ต้องเปลี่ยนคุณสมบัติของระบบ

  • [C-SR-16] ขอแนะนำอย่างยิ่งให้แสดงการตั้งค่าสำหรับนักพัฒนาซอฟต์แวร์ที่ตั้งค่าความทรงจำครั้งเดียวและรีบูตอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android มีคุณสมบัติตรงตามความต้องการข้างต้นผ่านโปรโตคอล Bootloader ของ MTE ด้วย Bootloader ที่เข้ากันได้

  • [C-SR-17] ขอแนะนำอย่างยิ่งให้แสดงการตั้งค่าในเมนูการตั้งค่าความปลอดภัยที่อนุญาตให้ผู้ใช้เปิดใช้ memtag

สิ้นสุดข้อกำหนดใหม่

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 ในรายงานเหตุการณ์ที่สร้างโดยคลาส API ของระบบ IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบในการบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์เพิ่มเติมของระบบ เหตุการณ์เหล่านั้นอาจใช้ตัวระบุอะตอมอื่นในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2 กำลังบันทึกเสียง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่โหลดล่วงหน้าหรือแจกจ่ายส่วนประกอบซอฟต์แวร์ออกจากกล่องที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้ หรือล้างการแจ้งเตือนอย่างต่อเนื่อง
  • [C-0-2] ต้องแสดงคำเตือนของผู้ใช้และได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้ง ให้บันทึกข้อมูลที่ละเอียดอ่อนซึ่งแสดงบนหน้าจอของผู้ใช้ได้เปิดใช้โดยมี ข้อความเดียวกับ AOSP ทุกครั้ง ทุกครั้งที่มีเซสชันในการจับภาพหน้าจอ การแคสต์หรือการบันทึกหน้าจอ เปิดใช้ MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() ต้องไม่ให้เงินแก่ผู้ใช้ในการปิดใช้การแสดงความยินยอมของผู้ใช้ในอนาคต
  • [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

    สิ้นสุดข้อกำหนดใหม่

หากการนำอุปกรณ์ไปใช้มีฟังก์ชันการทำงานในระบบซึ่งจับภาพเนื้อหาที่แสดงบนหน้าจอ และ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์นอกเหนือจากผ่านทาง 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
    • (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดของกฎระเบียบท้องถิ่น เพื่อให้แอปตรวจพบการเปลี่ยนแปลงข้อมูลประจำตัวของผู้สมัครใช้บริการ

9.8.6 การบันทึกเนื้อหาและการค้นหาแอปข้อมูลระดับระบบปฏิบัติการและข้อมูลแวดล้อม

Android ผ่าน System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query หรือด้วยวิธีการที่เป็นกรรมสิทธิ์อื่นๆ สนับสนุนกลไกในการติดตั้งใช้งานอุปกรณ์เพื่อบันทึกการโต้ตอบของข้อมูลแอปพลิเคชันต่อไปนี้ระหว่างแอปพลิเคชันกับผู้ใช้ ข้อมูลที่ละเอียดอ่อนต่อไปนี้

  • ข้อความและกราฟิกที่แสดงบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน AssistStructure API
  • ข้อมูลสื่อ เช่น เสียงหรือวิดีโอ ที่อุปกรณ์บันทึกหรือเล่น
  • เหตุการณ์การป้อนข้อมูล (เช่น การกดแป้น เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)

เริ่มข้อกำหนดใหม่

  • หน้าจอหรือข้อมูลอื่นๆ ที่ส่งผ่าน AugmentedAutofillService ไปยังระบบ
  • หน้าจอหรือข้อมูลอื่นๆ ที่เข้าถึงได้ผ่าน API Content Capture
  • หน้าจอหรือข้อมูลอื่นๆ ที่เข้าถึงได้ผ่าน API ของ FieldClassificationService
  • ข้อมูลแอปพลิเคชันที่ส่งไปยังระบบผ่าน AppSearchManager API และเข้าถึงได้ผ่าน AppSearchGlobalManager.query

สิ้นสุดข้อกำหนดใหม่

  • เหตุการณ์อื่นๆ ที่แอปพลิเคชันมอบให้ระบบผ่าน Content Capture API หรือ AppSearchManager API ที่เป็น Android ที่มีความสามารถใกล้เคียงกันและ API ที่เป็นกรรมสิทธิ์

  • ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน TextClassifier API ไปยัง System TextClassifier เช่น ไปยังบริการของระบบเพื่อทำความเข้าใจความหมายของข้อความ รวมถึงสร้างการดำเนินการถัดไปที่คาดการณ์ไว้ตามข้อความ
  • ข้อมูลที่จัดทำดัชนีโดยใช้ AppSearch ของแพลตฟอร์ม ซึ่งรวมถึงแต่ไม่จำกัดเพียงข้อความ กราฟิก ข้อมูลสื่อ หรือข้อมูลอื่นๆ ที่คล้ายกัน

เริ่มข้อกำหนดใหม่

  • ข้อมูลเสียงที่ได้มาจากการใช้ SpeechRecognizer#onDeviceSpeechRecognizer() จากการใช้โปรแกรมรู้จำคำพูด
  • ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ API เสียงอื่นๆ และไม่ส่งผลให้มีสัญญาณบอกสถานะที่ผู้ใช้มองเห็นได้
  • ข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ API กล้องอื่นๆ และไม่ได้ส่งผลให้มีสัญญาณบอกสถานะที่ผู้ใช้มองเห็นได้

สิ้นสุดข้อกำหนดใหม่

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลใดๆ ข้างต้น สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-1-1] ต้องเข้ารหัสข้อมูลทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้ Android File-Based Encryption หรือการเข้ารหัสใดๆ ที่ระบุไว้เป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
  • [C-1-2] ต้องไม่สำรองข้อมูลข้อมูลดิบหรือที่เข้ารหัสโดยใช้ วิธีการสำรองข้อมูลของ Android หรือ วิธีการสำรองอื่นๆ
  • [C-1-3] ต้องส่งข้อมูลดังกล่าวทั้งหมดและบันทึกออกจากอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัวเท่านั้น ยกเว้นกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการแชร์ข้อมูล กลไกการรักษาความเป็นส่วนตัวหมายถึง "รายการที่อนุญาตให้ใช้การวิเคราะห์แบบรวมและป้องกันการจับคู่เหตุการณ์ที่บันทึกหรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละรายเท่านั้น" เพื่อป้องกันไม่ให้ข้อมูลผู้ใช้แต่ละรายการสามารถตรวจสอบได้ (เช่น ใช้งานโดยใช้เทคโนโลยี Differential Privacy เช่น RAPPOR)
  • [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวผู้ใช้ (เช่น Account) ในอุปกรณ์ ยกเว้นกรณีที่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล
  • [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (การบันทึกเนื้อหา ระดับระบบปฏิบัติการและข้อมูลรอบข้าง) ยกเว้นกรณีที่ได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้งทุกครั้งที่มีการแชร์ เว้นแต่ฟังก์ชันดังกล่าวจะสร้างเป็น Android SDK API (AmbientContext, HotwordDetectionService)
  • [C-1-6] ต้องให้เงินแก่ผู้ใช้ในการลบข้อมูลดังกล่าวที่ ContentCaptureService การใช้งานหรือ วิธีการที่เป็นกรรมสิทธิ์เก็บรวบรวม หาก เมื่อ จัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์ หากผู้ใช้เลือกที่จะลบข้อมูล "ต้องนำข้อมูลย้อนหลังทั้งหมดที่รวบรวมไว้ออก
  • [C-1-7] ต้องให้เงินแก่ผู้ใช้ในการเลือกไม่ใช้ข้อมูลที่เก็บรวบรวมผ่าน AppSearch หรือวิธีการที่เป็นกรรมสิทธิ์เพื่อไม่ให้แสดงในแพลตฟอร์ม Android เช่น Launcher
  • [C-SR-1] แนะนำอย่างยิ่งไม่ให้ขอสิทธิ์อินเทอร์เน็ต
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้เข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างซึ่งสนับสนุนโดยการใช้งานโอเพนซอร์สที่เผยแพร่ต่อสาธารณะเท่านั้น

เริ่มข้อกำหนดใหม่

  • [C-SR-4] แนะนําอย่างยิ่งให้นําไปใช้กับ Android SDK API หรือที่เก็บโอเพนซอร์สที่ OEM เป็นเจ้าของ และ / หรือนําไปใช้ในการติดตั้งใช้งานแซนด์บ็อกซ์ (ดูการใช้งาน API ที่แซนด์บ็อกซ์เวอร์ชัน 9.8.15)

สิ้นสุดข้อกำหนดใหม่

หากการนำอุปกรณ์ไปใช้งานครอบคลุมบริการที่ใช้ 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 ระบบ และสื่อ

Android ผ่านทาง SpeechRecognizer#onDeviceSpeechRecognizer() จะช่วยให้ใช้การจดจำคำพูด บนอุปกรณ์ได้โดยไม่เกี่ยวข้องกับเครือข่าย การใช้งาน SpeechRecognizer ในอุปกรณ์ต้องเป็นไปตามนโยบายที่ระบุไว้ในส่วนนี้

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
    • โซลูชันการจัดตำแหน่งระดับโลก หรือระบบดาวเทียมการนำทางทั่วโลก หรือโซลูชันการวางตำแหน่งทั่วโลกแบบ Differential
    • ซึ่งรวมถึงการวัด GNSS ไฟล์ข้อมูล GNSS และสถานะ 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] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ API การข้ามตำแหน่งกรณีฉุกเฉิน [LocationRequest.setLocationSettingsignored()] เป็นเซสชันฉุกเฉินที่ผู้ใช้เป็นผู้เริ่ม (เช่น กดหมายเลข 911 หรือส่งข้อความไปที่ 911) แต่สำหรับยานยนต์ รถยนต์อาจเริ่มเซสชันฉุกเฉินโดยไม่มีการโต้ตอบของผู้ใช้ที่ใช้งานอยู่ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนด eCall)
  • [C-0-4] ต้องคงความสามารถของ API การข้ามตำแหน่งในกรณีฉุกเฉิน ในการข้ามการตั้งค่าตำแหน่งของอุปกรณ์ไว้โดยไม่เปลี่ยนการตั้งค่า
  • [C-0-5] ต้องกำหนดเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งโดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.8.9 แอปที่ติดตั้ง

แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้โดยค่าเริ่มต้นไม่ได้ (ดูระดับการเข้าถึงแพ็กเกจในเอกสารประกอบ SDK ของ Android)

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่เปิดเผยข้อมูลแอปที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป เกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ เว้นแต่ว่าแอปจะสามารถเห็นรายละเอียดของ แอปที่ติดตั้งอยู่อีกแอปหนึ่งผ่าน API ที่มีการจัดการ ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งเพิ่มโดยผู้ใช้อุปกรณ์ หรือเข้าถึงได้ผ่านระบบไฟล์
  • [C-0-2] ต้องไม่ให้สิทธิ์อ่านหรือเขียนไฟล์ในไดเรกทอรีเฉพาะแอปเฉพาะของแอปใดๆ ภายในพื้นที่เก็บข้อมูลภายนอก ข้อยกเว้นมีดังนี้
    • สิทธิ์ของผู้ให้บริการพื้นที่เก็บข้อมูลภายนอก (เช่น แอปอย่าง DocumentsUI)
    • ผู้ให้บริการดาวน์โหลดที่ใช้สิทธิ์ของผู้ให้บริการ "ดาวน์โหลด" ในการดาวน์โหลดไฟล์ไปยังพื้นที่เก็บข้อมูลของแอป
    • แอป Media Transfer Protocol (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 การแชร์ข้อมูล BLOB

Android ผ่านทาง BlobStoreManager ทำให้แอปที่แชร์ Blob ของข้อมูลไปยังระบบกับชุดแอปที่เลือกได้

หากการติดตั้งใช้งานอุปกรณ์รองรับ Blob ของข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสาร SDK ระบบจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องไม่แชร์ข้อมูล BLOB ที่เป็นของแอปนอกเหนือจากที่แอปตั้งใจจะอนุญาต (เช่น ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreAccessManager())#PublicAccessManager) การใช้ข้อมูลอ้างอิง AOSP จะเป็นไปตามข้อกำหนดเหล่านี้
  • [C-1-2] ต้องไม่ส่งแฮชที่ปลอดภัยของ Data Blob (ซึ่งใช้เพื่อควบคุมการเข้าถึง) ให้กับแอปอื่นหรือแชร์กับแอปอื่นๆ

9.8.12 การรับรู้เพลง

Android ที่ใช้ MusicRecognitionManager ซึ่งเป็น System API รองรับกลไกการนำอุปกรณ์ไปใช้งานเพื่อขอการจดจำเพลง มอบการบันทึกเสียง และให้สิทธิ์การจดจำเพลงแก่แอปที่ได้รับสิทธิ์ที่ใช้ MusicRecognitionService API

หากการใช้งานอุปกรณ์รวมถึงบริการที่ใช้ System API MusicRecognitionManager หรือบริการที่เป็นกรรมสิทธิ์ใดๆ ซึ่งสตรีมข้อมูลเสียงตามที่อธิบายไว้ข้างต้น

  • [C-1-1] ต้องบังคับให้ผู้เรียกใช้ MusicRecognitionManager มีสิทธิ์ MANAGE_MUSIC_RECOGNITION
  • [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 ผู้จัดการเซ็นเซอร์ความเป็นส่วนตัว

หากการติดตั้งอุปกรณ์ช่วยให้ผู้ใช้มีเงินพอที่จะปิดอินพุตกล้องและ/หรือไมโครโฟนสำหรับการติดตั้งใช้งานอุปกรณ์ได้

  • [C-1-1] ต้องแสดงผล "true" อย่างถูกต้องสำหรับเมธอด API ที่เกี่ยวข้อง supportsSensorToggle()
  • [C-1-2] ต้องเสนอเมื่อแอปพยายามเข้าถึงไมโครโฟนหรือกล้องที่ถูกบล็อก โดยต้องให้ผู้ใช้ได้เห็นราคาที่ปิดไม่ได้แก่ผู้ใช้ซึ่งระบุอย่างชัดเจนว่าเซ็นเซอร์ถูกบล็อกและกำหนดให้ต้องเลือกว่าจะบล็อกหรือเลิกบล็อกต่อไปตามการใช้งาน AOSP ซึ่งเป็นไปตามข้อกำหนดนี้
  • [C-1-3] จะต้องส่งข้อมูลกล้องและเสียงที่ไม่มี (หรือปลอม) ไปยังแอปเท่านั้น และไม่รายงานรหัสข้อผิดพลาดเนื่องจากผู้ใช้ไม่ได้เปิดกล้อง หรือไมโครโฟนผ่านงบของผู้ใช้ตามราคาที่ [C-1-2] ด้านบน

เริ่มข้อกำหนดใหม่

9.8.14 เครื่องมือจัดการข้อมูลเข้าสู่ระบบ

นำออกแล้ว

9.8.15 การใช้งาน API ที่แซนด์บ็อกซ์

Android จะใช้ชุด API ที่มอบสิทธิ์ซึ่งมีกลไกในการประมวลผลข้อมูลระดับระบบปฏิบัติการและข้อมูลแวดล้อมที่ปลอดภัย การประมวลผลดังกล่าวสามารถมอบสิทธิ์ให้กับ APK ที่ติดตั้งล่วงหน้าด้วยการเข้าถึงที่เป็นสิทธิ์เฉพาะและลดความสามารถในการสื่อสาร หรือที่เรียกว่าการใช้งาน API ที่แซนด์บ็อกซ์ไว้

การใช้ Sandboxed API

  • [C-0-1] ต้องไม่ขอสิทธิ์อินเทอร์เน็ต
  • [C-0-2] ต้องเข้าถึงอินเทอร์เน็ตผ่าน API ที่มีโครงสร้างซึ่งรับการสนับสนุนโดยการใช้งานโอเพนซอร์สที่พร้อมใช้งานแบบสาธารณะโดยใช้กลไกการรักษาความเป็นส่วนตัว หรือผ่าน API ของ Android SDK โดยอ้อมเท่านั้น กลไกการรักษาความเป็นส่วนตัวหมายถึง "รายการที่อนุญาตให้ใช้การวิเคราะห์แบบรวมเท่านั้นและป้องกันการจับคู่เหตุการณ์ที่บันทึกหรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้ข้อมูลผู้ใช้แต่ละรายการสามารถตรวจสอบได้ (เช่น มีการใช้งานโดยใช้เทคโนโลยี Differential Privacy เช่น 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 ข้อมูลเสียงและกล้องแบบต่อเนื่อง

นอกเหนือจากข้อกำหนดที่ระบุไว้ใน 9.8.2 การบันทึก, ข้อมูลระดับระบบปฏิบัติการและสภาพแวดล้อม 9.8.6 และการติดตั้งใช้งาน API ที่แซนด์บ็อกซ์เวอร์ชัน 9.8.15 แล้ว การใช้งานที่ใช้ข้อมูลเสียงที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน AudioRecord, SoundTrigger หรือ API เสียงอื่นๆ หรือ API เสียงอื่นๆ หรือข้อมูลกล้องที่ได้รับในเบื้องหลัง (อย่างต่อเนื่อง) ผ่าน CameraManager หรือ API กล้องอื่นๆ

  • [C-0-1] ต้องใช้สัญญาณบอกสถานะที่สอดคล้องกัน (กล้องและ/หรือไมโครโฟนตามส่วนที่ 9.8.2 การบันทึก) ยกเว้นในกรณีต่อไปนี้
    • การเข้าถึงนี้เกิดขึ้นจากการใช้งานแบบแซนด์บ็อกซ์ (ดูการใช้งาน Sandboxed API เวอร์ชัน 9.8.15) ผ่านแพ็กเกจที่มีบทบาทต่อไปนี้อย่างน้อย 1 บทบาท ได้แก่ System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence หรือ System Text 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 การใช้งานแซนด์บ็อกซ์หรือฟังก์ชันการทำงานที่ทำแซนด์บ็อกซ์หรือสร้างขึ้นโดย 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 บันทึกเหล่านี้ได้รับการจัดการผ่าน API ของเครื่องมือจัดการสถิติ ซึ่งแอปพลิเคชันระบบที่ได้รับสิทธิ์สามารถใช้ได้

นอกจากนี้ StatsManager ยังมอบวิธีเก็บรวบรวมข้อมูลที่จัดหมวดหมู่ว่ามีความละเอียดอ่อนด้านความเป็นส่วนตัวจากอุปกรณ์ที่มีกลไกการรักษาความเป็นส่วนตัว โดยเฉพาะอย่างยิ่ง StatsManager::query API จะช่วยให้ค้นหาหมวดหมู่เมตริกที่ถูกจำกัดที่กำหนดไว้ ใน StatsLog ได้

การค้นหาการติดตั้งใช้งานและการรวบรวมเมตริกที่ถูกจำกัดจาก StatsManager

  • [C-0-1] ต้องเป็นแอปพลิเคชัน/การติดตั้งใช้งานเพียงอย่างเดียวในอุปกรณ์และมีสิทธิ์ READ_RESTRICTED_STATS
  • [C-0-2] ต้องส่งเฉพาะข้อมูลทางไกลและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัว กลไกการรักษาความเป็นส่วนตัวหมายถึง "รายการที่อนุญาตให้วิเคราะห์แบบรวมและป้องกันการจับคู่เหตุการณ์ที่บันทึกหรือผลลัพธ์ที่ได้รับกับผู้ใช้แต่ละรายเท่านั้น" เพื่อป้องกันไม่ให้ข้อมูลผู้ใช้แต่ละรายการสามารถตรวจสอบได้ (เช่น มีการใช้งานโดยใช้เทคโนโลยี Differential Privacy เช่น RAPPOR)
  • [C-0-3] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวผู้ใช้ (เช่น บัญชี) ในอุปกรณ์
  • [C-0-4] ต้องไม่แชร์ข้อมูลดังกล่าวกับคอมโพเนนต์อื่นๆ ของระบบปฏิบัติการที่ไม่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนปัจจุบัน (9.8.17 การส่งข้อมูลทางไกล)
  • [C-0-5] ต้องให้เงินแก่ผู้ใช้ในการเปิด/ปิดใช้การรวบรวม การใช้งาน และการแชร์ที่รักษาความเป็นส่วนตัว
  • [C-0-6] ต้องให้เงินแก่ผู้ใช้ในการลบข้อมูลดังกล่าวที่การติดตั้งรวบรวมไว้หากมีการจัดเก็บข้อมูลในรูปแบบใดๆ ก็ตามในอุปกรณ์ หากผู้ใช้เลือกลบข้อมูล "ต้องนำข้อมูลทั้งหมดที่จัดเก็บไว้ในอุปกรณ์" ออก
  • [C-0-7] ต้องเปิดเผยการใช้โปรโตคอลการรักษาความเป็นส่วนตัวที่สำคัญในที่เก็บโอเพนซอร์ส
  • [C-0-8 ]ต้องบังคับใช้นโยบายข้อมูลขาออกในส่วนนี้เพื่อล็อกการเก็บรวบรวมข้อมูลในหมวดหมู่เมตริกที่จำกัดซึ่งกำหนดไว้ใน StatLog

สิ้นสุดข้อกำหนดใหม่

9.9 การเข้ารหัสพื้นที่เก็บข้อมูล

อุปกรณ์ทั้งหมดต้องตรงตามข้อกำหนดของส่วนที่ 9.9.1 อุปกรณ์ที่เปิดตัวในระดับ API ก่อนวันที่ในเอกสารนี้จะได้รับการยกเว้นจากข้อกำหนดในส่วนที่ 9.9.2 และ 9.9.3 แต่ต้องเป็นไปตามข้อกำหนดในส่วนที่ 9.9 ของเอกสารคำจำกัดความความเข้ากันได้ของ Android ที่สอดคล้องกับระดับ API ที่อุปกรณ์เปิดตัวไป

9.9.1 Direct Boot

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้ API โหมดการเปิดเครื่องโดยตรง แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

  • [C-0-2] ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED Intent ต้องยังคงออกอากาศอยู่เพื่อส่งสัญญาณแจ้งแอปพลิเคชันที่รับรู้การเปิดเครื่องโดยตรงว่า ตำแหน่งพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) จะพร้อมใช้งานสำหรับผู้ใช้

9.9.2 ข้อกำหนดการเข้ารหัส

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเข้ารหัสข้อมูลส่วนตัวของแอปพลิเคชัน (/data พาร์ติชัน) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรและนำออกไม่ได้ของอุปกรณ์
  • [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าเริ่มต้นเสร็จแล้ว

  • [C-0-3] ต้องเป็นไปตามข้อกำหนดในการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้น โดยการใช้วิธีการเข้ารหัส 1 ใน 2 วิธีต่อไปนี้

9.9.3 วิธีการเข้ารหัส

การติดตั้งใช้งานอุปกรณ์จะได้รับการเข้ารหัสดังนี้

  • [C-1-1] ต้องเปิดเครื่องโดยไม่ให้ผู้ใช้ขอข้อมูลเข้าสู่ระบบและอนุญาตให้แอป Direct Boot ที่รู้จักเข้าถึงพื้นที่เก็บข้อมูล Device Encrypted (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 Cryptography Extensions ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86) คุณต้องใช้ตัวเลือกแบบ AES ข้างต้นสำหรับชื่อไฟล์ เนื้อหาไฟล์ และการเข้ารหัสข้อมูลเมตาของระบบไฟล์ ไม่ใช่ Adiantum
  • [C-1-13] ต้องใช้ฟังก์ชันดึงข้อมูลคีย์ที่มีการเข้ารหัสที่รัดกุมและย้อนกลับไม่ได้ (เช่น HKDF-SHA512) เพื่อรับคีย์ย่อยที่จำเป็น (เช่น คีย์ต่อไฟล์) จากคีย์ CE และ DE "มีประสิทธิภาพในการเข้ารหัสและย้อนกลับไม่ได้" หมายความว่าฟังก์ชันการดึงคีย์มีความรัดกุมด้านความปลอดภัยอย่างน้อย 256 บิต และทํางานเป็นชุดฟังก์ชัน Pseudorandom สําหรับอินพุต
  • [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยที่เข้ารหัสตามไฟล์ (FBE) เดียวกันเพื่อวัตถุประสงค์ในการเข้ารหัสที่แตกต่างกัน (เช่น ทั้งการเข้ารหัสและการดึงคีย์ หรือสำหรับอัลกอริทึมการเข้ารหัสที่แตกต่างกัน 2 รายการ)
  • [C-1-15] ต้องตรวจสอบว่าบล็อกเนื้อหาไฟล์ที่เข้ารหัสซึ่งไม่ได้ลบทั้งหมดบนพื้นที่เก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่ขึ้นอยู่กับทั้งไฟล์และออฟเซ็ตภายในไฟล์ นอกจากนี้ ชุดค่าผสมทั้งหมดต้องแตกต่างกัน ยกเว้นในกรณีที่การเข้ารหัสโดยใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่รองรับความยาว IV ที่ 32 บิตเท่านั้น
  • [C-1-16] ต้องตรวจสอบว่าชื่อไฟล์ที่เข้ารหัสซึ่งไม่ได้ลบทั้งหมดบนพื้นที่เก็บข้อมูลถาวรในไดเรกทอรีแยกได้รับการเข้ารหัสโดยใช้ชุดคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่แตกต่างกัน

  • [C-1-17] ต้องตรวจสอบว่าบล็อกข้อมูลเมตาของระบบไฟล์ที่เข้ารหัสทั้งหมดในพื้นที่เก็บข้อมูลถาวรได้รับการเข้ารหัสโดยใช้ชุดค่าผสมของคีย์การเข้ารหัสและเวกเตอร์การเริ่มต้น (IV) ที่แตกต่างกัน

  • คีย์ที่ปกป้องพื้นที่เก็บข้อมูลของ CE และ DE และข้อมูลเมตาของระบบไฟล์มีดังนี้

    • [C-1-7] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
    • [C-1-8] คีย์ CE ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้
    • [C-1-9] คีย์ CE ต้องเชื่อมโยงกับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบในหน้าจอล็อก
    • [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ ไม่มีคีย์ CE หรือ DE ของผู้ใช้ที่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น
    • [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่สนับสนุนที่จำเป็น
    • [C-1-12] ต้องลบข้อมูลอย่างปลอดภัยในระหว่างการปลดล็อก Bootloader และล็อกตามที่อธิบายไว้ที่นี่

  • ควรทำให้แอปสำคัญที่ติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ เมสเสนเจอร์) รับรู้การเปิดเครื่องโดยตรง

โปรเจ็กต์ต้นทางของ Android ต้นทางมีการติดตั้งใช้งานที่แนะนำสำหรับการเข้ารหัสตามไฟล์ โดยอิงตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนลของ Linux และการเข้ารหัสข้อมูลเมตาที่อิงตามฟีเจอร์ "dm-default-key" ของเคอร์เนลของ Linux

9.9.3.2 การเข้ารหัสระดับการบล็อกต่อผู้ใช้

หากการใช้งานอุปกรณ์ใช้การเข้ารหัสระดับบล็อกต่อผู้ใช้ การใช้งานจะมีลักษณะดังนี้

  • [C-1-1] ต้องเปิดใช้การสนับสนุนผู้ใช้หลายคนตามที่อธิบายไว้ในส่วน 9.5
  • [C-1-2] ต้องระบุพาร์ติชันต่อผู้ใช้ ไม่ว่าจะใช้พาร์ติชันดิบหรือวอลุ่มเชิงตรรกะ
  • [C-1-3] ต้องใช้คีย์การเข้ารหัสที่ไม่ซ้ำกันและไม่ซ้ำกันต่อผู้ใช้สำหรับการเข้ารหัสอุปกรณ์บล็อกพื้นฐาน

  • [C-1-4] ต้องใช้ AES-256-XTS สำหรับการเข้ารหัสระดับบล็อกของพาร์ติชันผู้ใช้

  • คีย์ที่ช่วยปกป้องอุปกรณ์ที่เข้ารหัสระดับการบล็อกต่อผู้ใช้มีดังนี้

    • [C-1-5] ต้องเข้ารหัสแบบเข้ารหัสกับคีย์สโตร์ที่ใช้ฮาร์ดแวร์ คีย์สโตร์นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์
    • [C-1-6] ต้องเชื่อมโยงกับข้อมูลเข้าสู่ระบบในหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง

การเข้ารหัสระดับบล็อกต่อผู้ใช้สามารถนำมาใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของ Linux เหนือพาร์ติชันต่อผู้ใช้

9.9.4 ดำเนินการต่อเมื่อรีบูต

"กลับมาทำงานอีกครั้งเมื่อรีบูต" จะช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมด รวมถึงแอปที่ยังไม่รองรับ Direct Boot หลังจากการรีบูตที่เริ่มต้นโดย 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] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ว่าผู้ใช้ปลดล็อก Bootloader อย่างชัดแจ้ง
  • [C-SR-1] หากมีชิปแยกต่างหากหลายชิปในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์พิเศษ) ขอแนะนำอย่างยิ่งให้เปิดเครื่องของแต่ละชิปดังกล่าวเพื่อยืนยันทุกขั้นตอนเมื่อเปิดเครื่อง
  • [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะ เพื่อจัดเก็บว่า Bootloader ถูกปลดล็อกหรือไม่ พื้นที่เก็บข้อมูลที่มีการงัดแงะหมายความว่า Bootloader ตรวจสอบได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งผู้ใช้ขณะใช้อุปกรณ์ และต้องขอการยืนยันทางกายภาพก่อนอนุญาตให้เปลี่ยนจากโหมดล็อก Bootloader เป็นโหมดปลดล็อก Bootloader
  • [C-1-10] ต้องใช้การป้องกันย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น การเปิดเครื่อง พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่ชัดเจนสำหรับการจัดเก็บข้อมูลเมตาที่ใช้กำหนดเวอร์ชันระบบปฏิบัติการขั้นต่ำที่อนุญาต
  • [C-1-11] ต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยในระหว่างการปลดล็อกและล็อก Bootloader ตาม "9.12" การลบข้อมูล (รวมถึงพาร์ติชันข้อมูลผู้ใช้และพื้นที่ทำงาน NVRAM)
  • [C-SR-2] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดกับเชนความน่าเชื่อถือที่รูทในพาร์ติชันที่มีการป้องกันโดยการเปิดเครื่องที่ได้รับการยืนยัน
  • [C-SR-3] ขอแนะนำเป็นอย่างยิ่งให้ยืนยันอาร์ติแฟกต์ที่เรียกใช้ได้ซึ่งโหลดโดยแอปที่ได้รับสิทธิ์จากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์) ก่อนที่จะเรียกใช้ หรือขอแนะนำว่าอย่าเรียกใช้เนื้อหาดังกล่าวเลย
  • ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์ถาวร (เช่น โมเด็ม กล้อง) และควรใช้พื้นที่เก็บข้อมูลที่มีการงัดแงะในการจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันต่ำสุดที่อนุญาต

หากการใช้งานอุปกรณ์เปิดตัวไปแล้วโดยไม่รองรับ C-1-8 ถึง C-1-11 ใน Android เวอร์ชันเก่าและไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านี้อาจได้รับการยกเว้นจากข้อกำหนดนั้นๆ

โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำในที่เก็บ external/avb/ ซึ่งผสานรวมเข้ากับ Bootloader ที่ใช้สำหรับการโหลด Android

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์มีความสามารถในการยืนยันเนื้อหาไฟล์แบบต่อหน้าได้ สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-0-3 C-2-1] รองรับการยืนยันเนื้อหาไฟล์แบบเข้ารหัสต่อคีย์ที่เชื่อถือได้โดยไม่ต้องอ่านทั้งไฟล์

  • [C-0-4 C-2-2] ต้องไม่อนุญาตให้คำขออ่านในไฟล์ที่มีการป้องกันทำงานสำเร็จเมื่อเนื้อหาที่อ่านแล้ว ไม่ยืนยันกับคีย์ที่เชื่อถือได้ ไม่ได้รับการยืนยันตาม [C-2-1] ข้างต้น

เริ่มข้อกำหนดใหม่

  • [C-2-4] ต้องส่งคืน checksum ของไฟล์ใน O(1) สำหรับไฟล์ที่เปิดใช้งาน

สิ้นสุดข้อกำหนดใหม่

หากมีการเปิดตัวอุปกรณ์ไปแล้วโดยไม่สามารถยืนยันเนื้อหาไฟล์กับคีย์ที่เชื่อถือได้ใน Android เวอร์ชันก่อนหน้า และจะเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบไม่ได้ การใช้งานอุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด โปรเจ็กต์โอเพนซอร์ส Android มีฟีเจอร์การใช้งานที่แนะนำโดยอิงตามฟีเจอร์ fs-verity ของเคอร์เนลของ Linux

การติดตั้งใช้งานอุปกรณ์

หากอุปกรณ์รองรับ Android Protected Verifyation API

  • [C-3-1] ต้องรายงาน true สำหรับ ConfirmationPrompt.isSupported() API

  • [C-3-2] ต้องตรวจสอบว่าโค้ดที่ทำงานในระบบปฏิบัติการ Android รวมถึงเคอร์เนลของระบบปฏิบัติการ Android เป็นอันตรายหรือไม่เช่นนั้น ต้องไม่สร้างการตอบสนองเชิงบวกหากไม่มีการโต้ตอบจากผู้ใช้

  • [C-3-3] ต้องตรวจสอบว่าผู้ใช้ตรวจสอบและอนุมัติข้อความที่แจ้งแล้วได้ แม้ว่าระบบปฏิบัติการ Android ซึ่งรวมถึงเคอร์เนลจะมีช่องโหว่ก็ตาม

9.11 คีย์และข้อมูลเข้าสู่ระบบ

ระบบคีย์สโตร์ของ 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-0-3] ต้องจำกัดจำนวนการตรวจสอบสิทธิ์หลักที่ล้มเหลว
  • [C-SR-2] แนะนำอย่างยิ่งให้ใช้ขอบเขตสูงสุดของการพยายามตรวจสอบสิทธิ์หลักที่ไม่สำเร็จ 20 ครั้ง และหากผู้ใช้ยินยอมและเลือกใช้ฟีเจอร์ ให้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" หลังจากพยายามตรวจสอบสิทธิ์หลักที่ล้มเหลวเกินจำนวนครั้งที่กำหนด

หากใช้อุปกรณ์ จะเพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกหากอิงตามข้อมูลลับที่ทราบ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อให้เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ ให้ทำดังนี้

  • [C-SR-3] เราขอแนะนำอย่างยิ่งให้ป้อน PIN อย่างน้อย 6 หลักหรือเอนโทรปี 20 บิตที่เทียบเท่า
  • [C-2-1] PIN ที่มีความยาวน้อยกว่า 6 หลักจะต้องไม่อนุญาตให้มีการป้อนโดยอัตโนมัติโดยไม่ต้องโต้ตอบกับผู้ใช้ เพื่อหลีกเลี่ยงการเปิดเผยความยาวของ PIN

สิ้นสุดข้อกำหนดใหม่

เมื่อใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องสำรองข้อมูลการใช้คีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการที่แยกไว้
  • [C-1-2] ต้องมีการใช้งาน RSA, AES, ECDSA, ECDH (หากรองรับ IKeyMintDevice), 3DES, และอัลกอริทึมการเข้ารหัส HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่รองรับระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานอย่างปลอดภัยในเคอร์เนล การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามสำหรับการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
  • [C-1-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อทำสำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกจะต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากเท่านั้นในการตรวจสอบสิทธิ์หน้าจอล็อก โปรเจ็กต์โอเพนซอร์ส Android นี้มี Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
  • [C-1-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการลงนามในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพียงพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตหน่วยของ SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก

  • [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปเพื่อเปลี่ยนจาก ปลดล็อกเป็นสถานะล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตสูงสุด 15 วินาที อุปกรณ์ยานยนต์ที่จะล็อกหน้าจอเมื่อมีการปิด เครื่องเสียงหรือสลับผู้ใช้ อาจไม่มีการกำหนดค่า ระยะหมดเวลาสลีป
  • [C-1-6] ต้องรองรับ IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice เวอร์ชัน 1 หรือ IKeyMintDevice เวอร์ชัน 2
  • [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ IKeyMintDevice เวอร์ชัน 1

9.11.1 หน้าจอล็อกที่ปลอดภัย การตรวจสอบสิทธิ์ และอุปกรณ์เสมือน

การใช้งาน AOSP เป็นไปตามโมเดลการตรวจสอบสิทธิ์แบบเป็นขั้น ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตามความรู้สามารถรองรับได้โดยใช้ข้อมูลไบโอเมตริกระดับรองที่แข็งแกร่งหรือวิธีการที่สามซึ่งมีประสิทธิภาพน้อยกว่า

การติดตั้งใช้งานอุปกรณ์

  • [C-SR-1] แนะนำอย่างยิ่งให้ตั้งค่าวิธีใดวิธีหนึ่งต่อไปนี้เป็นวิธีการตรวจสอบสิทธิ์หลัก

    • PIN ที่เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน

    • รูปแบบการปัดในตารางกริดที่มีจุด 3x3 พอดี

      โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเป็นวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

เริ่มข้อกำหนดใหม่

  • [C-0-1] ต้องจำกัดจำนวนความพยายามในการตรวจสอบสิทธิ์หลักที่ล้มเหลว
  • [C-SR-5] ขอแนะนำเป็นอย่างยิ่งให้ใช้ขอบเขตสูงสุดของการพยายามตรวจสอบสิทธิ์หลักที่ไม่สำเร็จ 20 ครั้ง และหากผู้ใช้ยินยอมและเลือกใช้ฟีเจอร์ ให้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" หลังจากพยายามตรวจสอบสิทธิ์หลักที่ล้มเหลวเกินจำนวนครั้งที่กำหนด

หากใช้อุปกรณ์ตั้ง PIN ที่เป็นตัวเลขเป็นวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ให้ทำดังนี้

  • [C-SR-6] เราขอแนะนำอย่างยิ่งให้ป้อน PIN อย่างน้อย 6 หลักหรือเอนโทรปี 20 บิต
  • [C-SR-7] เราขอแนะนำเป็นอย่างยิ่งว่า PIN ที่มีความยาวน้อยกว่า 6 หลักจะไม่อนุญาตการป้อนโดยอัตโนมัติโดยไม่ต้องโต้ตอบกับผู้ใช้เพื่อหลีกเลี่ยงการเปิดเผยความยาวของ PIN

สิ้นสุดข้อกำหนดใหม่

หากการใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำและใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะเป็นดังนี้

  • [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ใน Requiring User Authentication For Key Use

หากใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกหากอิงตามข้อมูลลับที่ทราบ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อให้ถือว่าเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ

  • [C-3-1] เอนโทรปีของอินพุตที่มีความยาวสั้นที่สุดต้องไม่เกิน 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) และระบุไว้ใน AOSP
  • [C-3-4] วิธีการตรวจสอบสิทธิ์ใหม่จะต้องปิดใช้เมื่อ แอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้ง นโยบายข้อกำหนดของรหัสผ่านผ่าน DevicePolicyManager.setrequiredPasswordComplexity() ด้วยค่าคงที่ที่มีความซับซ้อนมากกว่า PASSWORD_COMPLEXITY_NONE หรือผ่านเมธอด DevicePolicyManager.setPasswordQITY() โดยมีค่าคงที่มากกว่า PasswordQMETRICITY
  • [C-3-5] วิธีการตรวจสอบสิทธิ์แบบใหม่ต้องกลับไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุก 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยให้ผู้ใช้ทราบอย่างชัดเจนว่าจะไม่มีการสำรองข้อมูลบางส่วนเพื่อรักษาความเป็นส่วนตัวของข้อมูล

หากการใช้อุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในการปลดล็อกหน้าจอล็อกและใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามข้อมูลไบโอเมตริกเพื่อให้เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ เราจะใช้วิธีการใหม่ดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วนที่ 7.3.10 สำหรับคลาส 1 (เดิมคือความสะดวกสบาย)
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ ซึ่งอิงตามข้อมูลลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้การตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ตั้งค่านโยบายฟีเจอร์การล็อกโดยเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() ด้วยแฟล็กข้อมูลไบโอเมตริกที่เกี่ยวข้อง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับคลาส 3 (เดิมเรียกว่ารัดกุม) ตามที่อธิบายไว้ในส่วนที่ 7.3.10 ให้ทำดังนี้

  • [C-5-1] จะต้องปิดใช้เมธอดหากแอปพลิเคชัน Device Policy Controller (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] ต้องปิดใช้วิธีการใหม่นี้และอนุญาตเฉพาะวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นในการปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (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 TV หรืออุปกรณ์ Automotive)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บไว้ทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่เก็บคีย์การเข้ารหัสหรือโทเค็นเอสโครว์ไว้ในอุปกรณ์เดียวกับที่ใช้คีย์ เช่น อนุญาตให้ใช้คีย์ที่จัดเก็บไว้ในโทรศัพท์เพื่อปลดล็อกบัญชีผู้ใช้ในทีวี สำหรับอุปกรณ์ยานยนต์ ระบบไม่อนุญาตให้จัดเก็บโทเค็นเอสโครว์ไว้ในส่วนใดๆ ของยานพาหนะ
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นเอสโครว์เพื่อถอดรหัสพื้นที่เก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีหนึ่ง
  • [C-7-8] ผู้ใช้ต้องได้รับคำถามสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุก 72 ชั่วโมงหรือน้อยกว่า เว้นแต่ว่าความปลอดภัยของผู้ใช้ (เช่น การเสียสมาธิของผู้ขับ)
  • [C-7-9] ผู้ใช้ต้องได้รับการยืนยันตัวตนสำหรับวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในหัวข้อ 7.3.10 เว้นแต่ว่าจะคำนึงถึงความปลอดภัยของผู้ใช้ (เช่น การรบกวนผู้ขับขี่)
  • [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องปฏิบัติตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
  • [C-7-11] ต้องไม่อนุญาตให้ TrustAgents ในอุปกรณ์หลักส่วนตัว (เช่น มือถือ) ในการปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกแล้วเป็นเวลาสูงสุด 4 ชั่วโมงเท่านั้น การใช้งาน TrustManagerService ตามค่าเริ่มต้นใน AOSP เป็นไปตามข้อกำหนดนี้
  • [C-7-12] ต้องใช้ช่องทางการสื่อสารที่มีการเข้ารหัสเพื่อความปลอดภัย (เช่น UKEY2) เพื่อส่งโทเค็นคนกลางจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย

หากใช้อุปกรณ์ ให้เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อกการล็อกปุ่มกด

  • [C-8-1] ต้องปิดใช้วิธีการใหม่เมื่อแอปพลิเคชัน Device Policy Controller (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] ต้องมีอินสแตนซ์อุปกรณ์เสมือนแยกกันต่อผู้ใช้
  • [C-10-6] ต้องปิดใช้การสร้างเหตุการณ์อินพุตที่เกี่ยวข้องผ่าน VirtualDeviceManager เมื่อระบุโดย DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] ต้องใช้คลิปบอร์ดแยกกันสำหรับอุปกรณ์เสมือนแต่ละเครื่องเท่านั้น (หรือปิดใช้คลิปบอร์ดสำหรับอุปกรณ์เสมือน)
  • [C-10-11] ต้องปิดใช้ UI การตรวจสอบสิทธิ์ในอุปกรณ์เสมือน ซึ่งรวมถึง การป้อนปัจจัยความรู้และข้อความแจ้งข้อมูลไบโอเมตริก
  • [C-10-12] ต้องจำกัด Intent ที่เริ่มต้นจากอุปกรณ์เสมือนให้แสดงเฉพาะ บนอุปกรณ์เสมือนเครื่องเดียวกันเท่านั้น
  • [C-10-13] ต้องไม่ใช้สถานะล็อกอุปกรณ์เสมือนเป็นการให้สิทธิ์การตรวจสอบสิทธิ์ผู้ใช้ด้วยระบบ Android Keystore โปรดดู KeyGenParameterSpec.Builder.setUserAuthentication*

เมื่อใช้งานอุปกรณ์อนุญาตให้ผู้ใช้โอนปัจจัยความรู้ในการตรวจสอบสิทธิ์หลักจากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เช่น การตั้งค่าเริ่มต้นของอุปกรณ์เป้าหมาย การดำเนินการเหล่านี้จะมีผลดังนี้

  • [C-11-1] ต้องเข้ารหัสฐานความรู้โดยมีการรับประกันการปกป้องที่คล้ายคลึงกับที่ระบุไว้ในสมุดปกขาวเกี่ยวกับความปลอดภัยของบริการ Google Cloud Key Vault เมื่อโอนปัจจัยความรู้จากอุปกรณ์ต้นทางไปยังอุปกรณ์เป้าหมาย เพื่อไม่ให้ระบบสามารถถอดรหัสหรือใช้เครื่องมือความรู้จากระยะไกลเพื่อปลดล็อกอุปกรณ์ใดอุปกรณ์หนึ่งได้จากระยะไกล
  • [C-11-2] ต้องขอให้ผู้ใช้ยืนยันปัจจัยความรู้ของอุปกรณ์ต้นทางก่อนที่จะโอนปัจจัยความรู้ไปยังอุปกรณ์เป้าหมาย
  • [C-11-3] ในอุปกรณ์เป้าหมายที่ไม่มีองค์ความรู้ด้านการตรวจสอบสิทธิ์หลักที่ตั้งไว้ ขอให้ผู้ใช้ยืนยันปัจจัยความรู้ที่โอนในอุปกรณ์เป้าหมายก่อนตั้งค่ากราฟความรู้เป็นปัจจัยหลักในการตรวจสอบสิทธิ์สำหรับอุปกรณ์เป้าหมาย และก่อนที่จะทำให้ข้อมูลที่โอนมาจากอุปกรณ์ต้นทางพร้อมใช้งาน

หากการนำอุปกรณ์ไปใช้งานมีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายการ ซึ่งเรียกใช้ TrustAgentService.grantTrust() System API ด้วยแฟล็ก FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE จะมีคำสั่งต่อไปนี้

  • [C-12-1] ต้องเรียกใช้ grantTrust() พร้อมธงเฉพาะเมื่อเชื่อมต่อกับอุปกรณ์จริงในบริเวณใกล้เคียงที่มีหน้าจอล็อกของตนเอง และเมื่อผู้ใช้ตรวจสอบสิทธิ์ตัวตนกับหน้าจอล็อกนั้นแล้ว อุปกรณ์ที่อยู่ในบริเวณใกล้เคียงสามารถใช้กลไกการตรวจจับบนข้อมือหรือบนร่างกายหลังจากที่ปลดล็อกผู้ใช้ครั้งเดียวแล้วเพื่อให้เป็นไปตามข้อกำหนดในการตรวจสอบสิทธิ์ของผู้ใช้
  • [C-12-2] ต้องทำให้การใช้งานอุปกรณ์อยู่ในสถานะ TrustState.TRUSTABLE เมื่อหน้าจอปิด (เช่น การกดปุ่มหรือหมดเวลาหน้าจอ) และ TrustAgent ไม่ได้เพิกถอนความไว้วางใจ AOSP เป็นไปตาม ข้อกำหนดนี้
  • [C-12-3] ต้องย้ายอุปกรณ์จาก TrustState.TRUSTABLE ไปยังสถานะ TrustState.TRUSTED เฉพาะเมื่อ TrustAgent ยังคงให้ความไว้วางใจตามข้อกำหนดใน C-12-1
  • [C-12-4] ต้องเรียกใช้ TrustManagerService.revokeTrust() หลังจากเวลาสูงสุด 24 ชั่วโมงนับจากที่ให้สิทธิ์ กรอบเวลาที่ไม่มีการใช้งาน 8 ชั่วโมง หรือเมื่อการเชื่อมต่อพื้นฐานกับอุปกรณ์จริงที่อยู่ใกล้ๆ ขาดหาย

หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันสร้างจอแสดงผลเสมือนรองและรองรับเหตุการณ์การป้อนข้อมูลที่เกี่ยวข้อง เช่น ผ่าน VirtualDeviceManager และจอแสดงผลไม่ได้ทำเครื่องหมายด้วย VIRTUAL_DISPLAY_FLAG_SECURE ไว้ สิ่งต่อไปนี้จะเกิดขึ้น

  • [C-13-8] ต้องบล็อก activities ด้วยแอตทริบิวต์ android:canDisplayOnRemote Devices หรือเมตา-data android.activity.can_display_on_remote_devices ที่ตั้งค่าเป็น "เท็จ" ไม่ให้เริ่มทำงานในอุปกรณ์เสมือนจริง
  • [C-13-9] ต้องบล็อกกิจกรรม ซึ่งไม่ได้เปิดใช้สตรีมมิงอย่างชัดแจ้ง และ ระบุว่าแสดงเนื้อหาที่ละเอียดอ่อนผ่าน SurfaceView#setSecure, FLAG_SECURE หรือ SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS ไม่ให้เริ่มทำงานบนอุปกรณ์เสมือน
  • [C-13-10] ต้องปิดใช้การติดตั้งแอปที่เริ่มต้นจากอุปกรณ์เสมือน

หากการใช้งานอุปกรณ์รองรับสถานะกำลังแสดงผลแบบแยกกันผ่าน DeviceStateManager และรองรับสถานะการล็อก Display แยกกันผ่าน KeyguardDisplayManager ระบบจะดำเนินการต่อไปนี้

  • [C-SR-2] แนะนำอย่างยิ่งให้ใช้ข้อกำหนดในการรับรองเอกสารรับรองตามที่ระบุไว้ในส่วนที่ 9.11.1 หรือข้อกำหนดเฉพาะด้านข้อมูลไบโอเมตริกอย่างน้อย คลาส 1 ที่ระบุไว้ในข้อ 7.3.10 เพื่อให้สามารถปลดล็อกด้วยตนเองจากจอแสดงผลของอุปกรณ์เริ่มต้น
  • [C-SR-3] ขอแนะนำอย่างยิ่งให้จำกัดการปลดล็อกจอแสดงผลแยกต่างหาก ผ่านระยะหมดเวลาการแสดงผลที่กำหนดไว้
  • [C-SR-4] ขอแนะนำอย่างยิ่งเพื่ออนุญาตให้ผู้ใช้ล็อกจอแสดงผลทั้งหมดทั่วโลกผ่านการปิดล็อกจากอุปกรณ์พกพาหลัก

9.11.2 StrongBox

ระบบ Android Keystore ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะได้เช่นเดียวกับสภาพแวดล้อมการดำเนินการที่แยกต่างหากตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยเฉพาะดังกล่าวเรียกว่า "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] การติดตั้งใช้งานอุปกรณ์ ให้ทำดังนี้

    • [C-1-10] ต้องรวมฮาร์ดแวร์ที่ได้รับการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่เป็นไปได้ในการโจมตีสูงตามการใช้เกณฑ์ทั่วไปของโอกาสในการโจมตีกับสมาร์ทการ์ด
    • [C-1-11] ต้องรวมเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับชาติซึ่งรวมการประเมินช่องโหว่ของการโจมตีที่มีโอกาสเกิดการโจมตีสูงตามการใช้เกณฑ์ร่วมกันของโอกาสในการโจมตีกับสมาร์ทการ์ด
    • [C-SR-2] แนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ประเมินโดยใช้เป้าหมายความปลอดภัย, Evaluation Assurance Level (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มจะเป็นข้อกำหนด สำหรับการเผยแพร่ในอนาคต
    • [C-SR-3] ขอแนะนำอย่างยิ่งให้เสริมการป้องกันการโจมตีจากบุคคลภายใน (IAR) ซึ่งหมายความว่าบุคคลภายในที่มีสิทธิ์เข้าถึงคีย์การรับรองเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox สามารถเปิดเผยข้อมูลลับ เพื่อหลบเลี่ยงข้อกำหนดด้านความปลอดภัยด้านฟังก์ชันการทำงาน หรือให้สิทธิ์เข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการใช้ IAR คืออนุญาตการอัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านหลักของผู้ใช้ผ่าน IAuthSecret HAL

9.11.3 ข้อมูลประจำตัว

ระบบจะกำหนดและใช้ระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัวด้วยการใช้ API ทั้งหมดในแพ็กเกจ android.security.identity.* API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและเรียกข้อมูลเอกสารข้อมูลประจำตัวของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์

  • [C-SR-1] ได้รับการแนะนำอย่างยิ่งให้ใช้ระบบข้อมูลประจำตัว

หากการติดตั้งใช้งานอุปกรณ์นำระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัวมาใช้ ระบบจะดำเนินการดังต่อไปนี้

  • [C-1-1] ต้องแสดงผลค่าที่ไม่ใช่ null สำหรับเมธอด IdentityCredentialStore#getInstance()

  • [C-1-2] ต้องใช้ระบบข้อมูลเข้าสู่ระบบข้อมูลประจำตัว (เช่น API ของ android.security.identity.*) ที่มีการสื่อสารโค้ดกับแอปพลิเคชันที่เชื่อถือในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและสูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA

  • [C-1-3] การดำเนินการเข้ารหัสที่จำเป็นในการติดตั้งใช้งานระบบข้อมูลประจำตัว (เช่น API ของ android.security.identity.*) จะต้องดำเนินการทั้งหมดในแอปพลิเคชันที่เชื่อถือและเนื้อหาของคีย์ส่วนตัวต้องไม่ออกจากสภาพแวดล้อมการดำเนินการที่แยกออกมา เว้นแต่จะต้องการอย่างเจาะจงสำหรับ API ระดับสูงกว่า (เช่น เมธอด createEphemeralKeyPair())

  • [C-1-4] แอปพลิเคชันที่เชื่อถือได้จะต้องใช้งานในลักษณะที่ไม่กระทบต่อคุณสมบัติด้านความปลอดภัย (เช่น ระบบจะไม่เผยแพร่ข้อมูลเข้าสู่ระบบ เว้นแต่จะเป็นไปตามเงื่อนไขการควบคุมการเข้าถึง จึงไม่สามารถสร้าง MAC สำหรับข้อมูลที่กำหนดเองได้) แม้ว่า Android จะทำงานผิดปกติหรือถูกบุกรุก

โปรเจ็กต์โอเพนซอร์ส Android มีการติดตั้งใช้งานข้อมูลอ้างอิงของแอปพลิเคชันที่เชื่อถือได้ (libeic) ซึ่งสามารถใช้เพื่อติดตั้งใช้งานระบบข้อมูลประจำตัวได้

9.12 การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องระบุกลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ข้อมูลผู้ใช้เมื่อดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88 เมื่อดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ข้างต้นเมื่อแอป Device Policy Controller ของผู้ใช้หลักเรียกใช้ API ของ DevicePolicyManager.wipeData() API
  • อาจมีตัวเลือกการล้างข้อมูลที่รวดเร็วซึ่งดำเนินการลบข้อมูลแบบลอจิคัลเท่านั้น

9.13 โหมดปลอดภัยเปิดเครื่อง

Android มีเซฟโหมดซึ่งช่วยให้ผู้ใช้เปิดเครื่องในโหมดที่ อนุญาตให้เรียกใช้ได้เฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าและ ปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการเปิดเครื่องที่ปลอดภัย" ช่วยให้ผู้ใช้ถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การใช้งานอุปกรณ์มีดังนี้

  • [C-SR-1] แนะนำอย่างยิ่งให้ใช้โหมดปลอดภัยในการเปิดเครื่อง

หากติดตั้งใช้งานอุปกรณ์ไว้ในโหมดปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้

  • [C-1-1] ต้องระบุตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยด้วยการเปิดเครื่องในลักษณะที่ไม่ขัดจังหวะการทำงานของแอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ ยกเว้นในกรณีที่แอปของบุคคลที่สามเป็นตัวควบคุมนโยบายด้านอุปกรณ์ และได้ตั้งค่าสถานะ UserManager.DISALLOW_SAFE_BOOT เป็น "จริง"

  • [C-1-2] ต้องให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามภายในโหมดปลอดภัยได้

  • ควรให้ตัวเลือกแก่ผู้ใช้ในการเข้าสู่โหมดปลอดภัยจากเมนูเปิดเครื่องโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเปิดเครื่องปกติ

9.14 การแยกระบบยานพาหนะ

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายรถยนต์ เช่น CAN Bus

การแลกเปลี่ยนข้อมูลจะปลอดภัยได้ด้วยการใช้ฟีเจอร์ความปลอดภัยด้านล่างเลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายหรือไม่ได้ตั้งใจกับระบบย่อยเหล่านี้

9.15 แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ด้านการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องส่งคืนแพ็กเกจการสมัครใช้บริการไปยังแอปของผู้ให้บริการเครือข่ายมือถือที่ได้จัดเตรียมแพ็กเกจไว้ในตอนแรกเท่านั้น
  • [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
  • [C-0-3] ต้องอนุญาตเฉพาะการลบล้าง เช่น SubscriptionManager.setSubscriptionOverrideCongested() จากแอปของผู้ให้บริการเครือข่ายมือถือที่กำลังเสนอแพ็กเกจการสมัครใช้บริการที่ถูกต้องอยู่เท่านั้น

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 Virtualization Framework (android.system.virtualmachine.*) โฮสต์ Android จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับ API ทั้งหมดที่กำหนดโดยแพ็กเกจ android.system.virtualmachine
  • [C-1-2] ต้องไม่แก้ไข SELinux ของ Android และโมเดลสิทธิ์สำหรับ การจัดการเครื่องเสมือนที่มีการป้องกัน (pVM)

  • [C-1-3] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎNeverallow ที่อยู่ภายในระบบ/sepolicy ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android อัปสตรีม (AOSP) และนโยบายต้องคอมไพล์ด้วยกฎที่ไม่อนุญาตทั้งหมดที่มีอยู่

  • [C-1-4] ต้องอนุญาตเฉพาะโค้ดที่ลงนามของแพลตฟอร์มและแอปที่ได้รับสิทธิ์ต้องไม่อนุญาตโค้ดที่ไม่น่าเชื่อถือ (เช่น แอป 3p) ให้สร้างและเรียกใช้ Virtual Machine ที่มีการป้องกัน pVM หมายเหตุ: ข้อมูลนี้อาจเปลี่ยนแปลงได้ใน Android รุ่นต่อๆ ไป

  • [C-1-5] ต้องไม่อนุญาตให้ Virtual Machine ที่มีการป้องกัน pVM เรียกใช้โค้ดที่ไม่ได้เป็นส่วนหนึ่งของอิมเมจเริ่มต้นหรือการอัปเดต สิ่งใดก็ตามที่ไม่ได้อยู่ภายใต้การเปิดเครื่องที่ได้รับการยืนยันของ Android (เช่น ไฟล์ที่ดาวน์โหลดจากอินเทอร์เน็ตหรือไซด์โหลด) ต้องไม่ได้รับอนุญาตให้เรียกใช้ในเครื่องเสมือนที่มีการป้องกัน

เริ่มข้อกำหนดใหม่

  • [C-1-5] ต้องอนุญาตเฉพาะ pVM ที่แก้ไขข้อบกพร่องไม่ได้ให้เรียกใช้โค้ดจากอิมเมจเริ่มต้นหรือการอัปเดตแพลตฟอร์ม ซึ่งรวมถึงการอัปเดตแอปที่ได้รับสิทธิ์ด้วย

สิ้นสุดข้อกำหนดใหม่

หากอุปกรณ์รองรับ Android Virtualization Framework API (android.system.virtualmachine.*) อินสแตนซ์ Protected Virtual Machine pVM ทั้งหมดดังนี้

  • [C-2-1] ต้องเรียกใช้ระบบปฏิบัติการทั้งหมดที่มีอยู่ใน APEX เสมือนใน Protected Virtual Machine pVM ได้
  • [C-2-2] ต้องไม่อนุญาตให้ Virtual Machine ที่มีการป้องกัน pVM เรียกใช้ระบบปฏิบัติการ ที่ไม่ได้รับรองโดยผู้ติดตั้งอุปกรณ์หรือผู้ให้บริการระบบปฏิบัติการ
  • [C-2-3] ต้องไม่อนุญาตให้ Virtual Machine ที่มีการป้องกัน pVM ประมวลผลข้อมูลเป็นโค้ด (เช่น SELinux ไม่อนุญาต execmem)

  • [C-2-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ noallow ที่อยู่ในระบบ/sepolicy/microdroid ที่อยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP)

  • [C-2-5] ต้องใช้ Protected Virtual Machine pVM กลไกการป้องกันเชิงลึก (เช่น SELinux สำหรับ pVM) แม้แต่สำหรับระบบปฏิบัติการที่ไม่ใช่ Microdroid
  • [C-2-6] ต้องตรวจสอบว่า pVM ไม่ ปฏิเสธเฟิร์มแวร์ในการเปิดเครื่องหากยืนยันอิมเมจเริ่มต้นที่ VM จะเรียกใช้ไม่ได้ ซึ่งต้องดำเนินการภายใน VM
  • [C-2-7] ต้องตรวจสอบว่า pVM ไม่ เฟิร์มแวร์ปฏิเสธ ในการเปิดเครื่องหากความสมบูรณ์ของอินสแตนซ์.img ถูกละเมิด

หากอุปกรณ์ใช้การรองรับ Android Virtualization Framework (android.system.virtualmachine.*) ไฮเปอร์ไวเซอร์

  • [C-3-1] ต้องตรวจสอบว่าหน้าหน่วยความจำที่เป็นของ VM โดยเฉพาะ (pVM หรือ VM ของโฮสต์) เข้าถึงได้จากตัวเครื่องเสมือนหรือไฮเปอร์ไวเซอร์เท่านั้น ไม่ใช่เครื่องเสมือนอื่นๆ ไม่ว่าจะได้รับการป้องกันหรือไม่มีการป้องกัน ต้องไม่อนุญาตให้ pVM เข้าถึงหน้าเว็บของเอนทิตีอื่น (เช่น pVM อื่น หรือ Hypervisor) เว้นแต่เจ้าของเพจจะแชร์อย่างชัดแจ้ง ซึ่งรวมถึง VM ของโฮสต์ ซึ่งจะมีผลกับทั้งการเข้าถึง CPU และ DMA
  • [C-3-2] ต้องล้างข้อมูลหน้าหลังจากที่ใช้โดย pVM และก่อนที่จะส่งไปยังโฮสต์ (เช่น pVM ถูกทำลาย)
  • [C-3-3SR-1] แนะนําอย่างยิ่งเพื่อให้มั่นใจว่า ต้องตรวจสอบว่าเฟิร์มแวร์ pVM นั้นโหลดและเรียกใช้ก่อนโค้ดใดๆ ใน pVM
  • [C-3-4] ต้องตรวจสอบว่า VM แต่ละรายการได้รับข้อมูลลับต่อ VM ซึ่ง {Boot Certificate Chain (BCC) และ Compound Device Identifier (CDI) ที่ให้ไว้กับอินสแตนซ์ pVM ดึงข้อมูลมาจากอินสแตนซ์ VM นั้นเท่านั้นและจะเปลี่ยนแปลงเมื่อรีเซ็ตเป็นค่าเริ่มต้นและ OTA

หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การดำเนินการทั้งหมดจะมีผลดังนี้

  • [C-4-1] ต้องไม่มอบฟังก์ชันการทำงานให้แก่ pVM ที่อนุญาตให้ข้ามโมเดลความปลอดภัยของ Android

หากอุปกรณ์ใช้การรองรับ API ของ Virtualization Framework ของ Android คุณจะต้องดำเนินการต่อไปนี้

  • [C-5-1] ต้องสามารถรองรับการคอมไพล์แยก แต่อาจปิดใช้ฟีเจอร์การคอมไพล์ที่แยก (Isolated Compilation) ในการจัดส่งอุปกรณ์ ของการอัปเดตรันไทม์ ART

หากอุปกรณ์รองรับ API ของ Virtualization Framework ของ Android การจัดการคีย์จะมีผลดังนี้

  • [C-6-1] ต้องรูทเชน DICE ตรงจุดที่ผู้ใช้แก้ไขไม่ได้แม้ในอุปกรณ์ที่ไม่ได้ล็อก (เพื่อให้แน่ใจว่าไม่มีการปลอมแปลง)

  • [C-SR-26-2] แนะนําอย่างยิ่งให้ใช้ DICE เป็นกลไกการรับข้อมูลลับต่อ VM ต้องใช้ DICE อย่างถูกต้อง กล่าวคือ ระบุค่าที่ถูกต้อง

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจการทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ทำการเปลี่ยนแปลงข้อมูลอ้างอิงและการติดตั้งใช้งาน Android ที่ต้องการจากโปรเจ็กต์โอเพนซอร์ส Android ให้น้อยที่สุดเท่าที่จะเป็นไปได้ วิธีนี้จะช่วยลดความเสี่ยงในการเกิดข้อบกพร่องที่ก่อให้เกิดความไม่เข้ากัน ซึ่งต้องมีการปรับปรุงและอัปเดตอุปกรณ์ที่อาจเกิดขึ้น

10.1 ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องผ่านชุดทดสอบความเข้ากันได้ของ Android (CTS) ที่มีให้จากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความกำกวมใน CTS และการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงมาใช้ซ้ำ

CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง CTS เองอาจมีข้อบกพร่องอยู่ในตัวเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันต่างๆ แยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และเวอร์ชัน CTS เวอร์ชันต่างๆ อาจมีการเผยแพร่สำหรับ Android 14

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องส่ง CTS เวอร์ชันล่าสุดที่มีอยู่ขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การใช้งานข้อมูลอ้างอิงในโครงสร้างโอเพนซอร์สของ Android ให้มากที่สุด

10.2 ผู้ตรวจสอบ CTS

เครื่องมือตรวจสอบ CTS จะรวมอยู่ในชุดทดสอบความเข้ากันได้ โดยมีเป้าหมายให้เจ้าหน้าที่ดำเนินการทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น กล้องและเซ็นเซอร์ทำงานได้อย่างถูกต้อง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องดำเนินการกับทุกกรณีที่เกี่ยวข้องในเครื่องมือยืนยัน CTS อย่างถูกต้อง

CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางชนิดที่ไม่บังคับ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีตัวตรวจวัดความเร่ง ตัวตรวจวัดความเร่งจะต้องดำเนินการกับเคสทดสอบตัวตรวจวัดความเร่งอย่างถูกต้องในโปรแกรมตรวจสอบ CTS

กรณีทดสอบสำหรับฟีเจอร์ที่ระบุว่าไม่บังคับโดยคำจำกัดความความเข้ากันได้นี้ ระบบอาจข้ามหรือละเว้นเอกสารดังกล่าว

  • [C-0-2] อุปกรณ์ทุกเครื่องและทุกบิลด์ต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่กล่าวไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ติดตั้งใช้งานอุปกรณ์จึงไม่คาดว่าจะเรียกใช้ CTS Verifier อย่างชัดแจ้งในบิลด์ที่แตกต่างกันเพียงเล็กน้อยเท่านั้น กล่าวอย่างเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่านการตรวจสอบ CTS Verifier ผ่านชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมไว้ อาจข้ามการทดสอบ CTS Verifier ได้

11. ซอฟต์แวร์ที่อัปเดตได้

  • [C-0-1] การใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "จริง" กล่าวคืออาจจำเป็นต้องรีสตาร์ทอุปกรณ์ คุณจะใช้วิธีการใดก็ได้ โดยมีเงื่อนไขว่าจะแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการใดต่อไปนี้จะสอดคล้องกับข้อกำหนดนี้

    • การดาวน์โหลด "ผ่านอากาศ (OTA)" ด้วยการอัปเดตแบบออฟไลน์ผ่านรีบูต
    • การอัปเดต "Tethered" ผ่าน USB จากคอมพิวเตอร์โฮสต์
    • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและอัปเดตจากไฟล์บนที่เก็บข้อมูลแบบถอดได้

  • [C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ต้องล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องเก็บรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android อัปสตรีมมีกลไกการอัปเดตที่เป็นไปตามข้อกำหนดนี้

  • [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 ระบบจะดำเนินการต่อไปนี้

  • [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

สำหรับสรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้ ให้ทำดังนี้

13. ติดต่อเรา

คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารนั้นไม่ครอบคลุม