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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • มีแหล่งจ่ายไฟที่ช่วยให้เคลื่อนที่ได้ เช่น แบตเตอรี่
  • มีขนาดหน้าจอแนวทแยงจริงในช่วง 3.3 นิ้ว (หรือ 2.5 นิ้วสำหรับอุปกรณ์ที่เปิดตัวใน API ระดับที่ต่ำกว่า Android 11) ถึง 8 นิ้ว

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

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

2.2.1. ฮาร์ดแวร์

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

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

หากการใช้งานอุปกรณ์ถือรองรับการหมุนหน้าจอซอฟต์แวร์ จะมีข้อกำหนดดังนี้

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

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

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

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

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

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

  • [7.1.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการสร้างโปรไฟล์ GPU ผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support หรือไม่

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

  • [7.1.4.6/H-1-1] ต้องรายงานเป็นเอาต์พุตการติดตาม Protobuf ที่เป็นไปตามสคีมาสำหรับตัวนับ GPU และการแสดงผล GPU ที่กำหนดไว้ในเอกสารประกอบ Perfetto
  • [7.1.4.6/H-1-2] ต้องรายงานค่าที่เป็นไปตามข้อกำหนดสำหรับตัวนับ GPU ของอุปกรณ์ตาม gpu counter trace packet proto
  • [7.1.4.6/H-1-3] ต้องรายงานค่าที่สอดคล้องสำหรับ RenderStage ของ GPU ของอุปกรณ์ตาม render stage trace packet proto
  • [7.1.4.6/H-1-4] ต้องรายงานจุดติดตามความถี่ของ GPU ตามที่ระบุไว้ในรูปแบบ power/gpu_frequency

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

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

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

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

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

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

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

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

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

  • [7.3.8/H] ควรมีพร็อกซิมิตีเซ็นเซอร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.8.2.2/H-4-2] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และมีบทบาทเป็น Sink() หากฟิลด์ประเภทเทอร์มินัลเสียง 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 และ role isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB คือ 0x400

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

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

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

  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งว่าไม่ควรใช้ตัวกระตุ้นแบบสัมผัส (เครื่องสั่น) ที่มีมวลหมุนเยื้องศูนย์(ERM)
  • [7.10/H]* ควรวางตำแหน่งของแอคทูเอเตอร์ไว้ใกล้กับตำแหน่งที่โดยปกติแล้วผู้ใช้จะถือหรือสัมผัสอุปกรณ์ด้วยมือ
  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ใช้ค่าคงที่สาธารณะทั้งหมดสำหรับการตอบสนองแบบสัมผัสที่ชัดเจนใน android.view.HapticFeedbackConstants ซึ่งได้แก่ (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START และ GESTURE_END)
  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ใช้ค่าคงที่สาธารณะทั้งหมดสำหรับ clear haptics ใน android.os.VibrationEffect ได้แก่ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ EFFECT_DOUBLE_CLICK) และค่าคงที่สาธารณะทั้งหมดสำหรับ rich haptics ใน android.os.VibrationEffect.Composition ได้แก่ (PRIMITIVE_CLICK และ PRIMITIVE_TICK)
  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ใช้การแมปค่าคงที่แบบสัมผัสที่ลิงก์เหล่านี้
  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ทำตามการประเมินคุณภาพสำหรับ API createOneShot() และ createWaveform()
  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ยืนยันความสามารถในการปรับขนาดแอมพลิจูดโดยเรียกใช้ android.os.Vibrator.hasAmplitudeControl()

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

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

  • [7.10/H]* ควรเลื่อนตัวกระตุ้นแบบสัมผัสในแกน X ของการวางแนวตั้ง

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

  • [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ 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.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

2.2.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ถือรวมถึงการรองรับ 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 อย่างถูกต้องในส่วนนี้ รวมถึงฟิลด์ที่ระบุซึ่งได้รับจาก Control API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5. โมเดลความปลอดภัย

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ถือรวมผู้ใช้หลายรายและประกาศฟีเจอร์แฟล็ก android.hardware.telephony จะมีลักษณะดังนี้

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

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

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

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

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

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

2.2.7 Handheld Media Performance Class

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

2.2.7.1. สื่อ

หากการใช้งานอุปกรณ์ถือส่งคืน android.os.Build.VERSION_CODES.R สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์ดังกล่าวมีลักษณะดังนี้

  • [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวถอดรหัสวิดีโอฮาร์ดแวร์ ที่เรียกใช้พร้อมกันได้ในชุดค่าผสมของตัวแปลงรหัสผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 6 รายการ (AVC หรือ HEVC) ในการผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 720p@30 fps
  • [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวเข้ารหัสวิดีโอฮาร์ดแวร์ ที่สามารถเรียกใช้พร้อมกันในชุดค่าผสมของตัวแปลงรหัสใดก็ได้ผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-4] ต้องรองรับเซสชันตัวเข้ารหัสวิดีโอฮาร์ดแวร์ 6 รายการ (AVC หรือ HEVC) ในการผสมตัวแปลงรหัสใดๆ ที่ทำงานพร้อมกันที่ความละเอียด 720p@30 FPS
  • [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของตัวเข้ารหัสวิดีโอฮาร์ดแวร์ และตัวถอดรหัสที่สามารถเรียกใช้พร้อมกันในชุดค่าผสมของตัวแปลงรหัส ผ่านเมธอด CodecCapabilities.getMaxSupportedInstances() และ VideoCapabilities.getSupportedPerformancePoints()
  • [5.1/H-1-6] ต้องรองรับอินสแตนซ์ของตัวถอดรหัสวิดีโอฮาร์ดแวร์และฮาร์ดแวร์ 6 รายการ เซสชันตัวเข้ารหัสวิดีโอ (AVC หรือ HEVC) ในการผสมตัวแปลงรหัสใดๆ ที่ทำงาน พร้อมกันที่ความละเอียด 720p@30 fps
  • [5.1/H-1-7] ต้องมีเวลาในการเริ่มต้นตัวแปลงรหัสไม่เกิน 65 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอ 1080p หรือเล็กกว่าสำหรับตัวเข้ารหัสวิดีโอฮาร์ดแวร์ทั้งหมด (ยกเว้นตัวแปลงรหัส Dolby Vision) เมื่ออยู่ภายใต้ภาระงาน ภาระงานที่นี่หมายถึงเซสชันการแปลงรหัสวิดีโออย่างเดียวจาก 1080p เป็น 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียงและวิดีโอ 1080p
  • [5.1/H-1-8] ต้องมีเวลาในการเริ่มต้นตัวแปลงรหัสไม่เกิน 50 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสเสียงที่มีบิตเรต 128 Kbps หรือต่ำกว่าสำหรับตัวเข้ารหัสเสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงาน โดยภาระงานในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโออย่างเดียวจาก 1080p เป็น 720p ที่เกิดขึ้นพร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ร่วมกับการเริ่มต้นการบันทึกเสียงและวิดีโอที่ความละเอียด 1080p
  • [5.3/H-1-1] ต้องไม่ทิ้งเฟรมมากกว่า 1 เฟรมใน 10 วินาที (เช่น มีการทิ้งเฟรมน้อยกว่า 0.333 เปอร์เซ็นต์) สำหรับเซสชันวิดีโอ 1080p 30 FPS ภายใต้ภาระงาน โหลดหมายถึงเซสชันการแปลงรหัสวิดีโออย่างเดียวจาก 1080p เป็น 720p พร้อมกัน โดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึง การเล่นเสียง AAC ที่ 128 kbps
  • [5.3/H-1-2] ต้องไม่ดรอปเฟรมมากกว่า 1 เฟรมใน 10 วินาทีระหว่างการเปลี่ยนความละเอียดของวิดีโอในเซสชันวิดีโอ 30 FPS ภายใต้ภาระงาน โหลดหมายถึงเซสชันการแปลงรหัสวิดีโออย่างเดียวจาก 1080p เป็น 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC ที่ 128Kbps
  • [5.6/H-1-1] ต้องมีเวลาในการตอบสนองแบบแตะเพื่อส่งเสียงน้อยกว่า 100 มิลลิวินาที โดยใช้การทดสอบแบบแตะเพื่อส่งเสียงของ OboeTester หรือการทดสอบแบบแตะเพื่อส่งเสียงของ CTS Verifier
2.2.7.2. กล้อง

หากการใช้งานอุปกรณ์ถือส่งคืน android.os.Build.VERSION_CODES.R สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์ดังกล่าวมีลักษณะดังนี้

  • [7.5/H-1-1] ต้องมีกล้องหลักที่หันไปทางด้านหลังซึ่งมีความละเอียดอย่างน้อย 12 ล้านพิกเซลที่รองรับการจับภาพวิดีโอที่ 4k@30fps กล้องหลังหลัก คือกล้องหลังที่มีรหัสกล้องต่ำที่สุด
  • [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 4 เมกะพิกเซลที่รองรับการจับภาพวิดีโอที่ 1080p@30fps กล้องหน้าหลัก คือกล้องหน้าที่มีรหัสกล้องต่ำที่สุด
  • [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้ android.info.supportedHardwareLevel เป็น FULL หรือดีกว่าสำหรับกล้องหลักด้านหลัง และ LIMITED หรือดีกว่าสำหรับกล้องหลักด้านหน้า
  • [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME สำหรับทั้งกล้องหลัก
  • [7.5/H-1-5] ต้องมีเวลาในการตอบสนองของการจับภาพ JPEG ของ camera2 น้อยกว่า 1,000 มิลลิวินาทีสำหรับ ความละเอียด 1080p ตามที่วัดโดย Camera PerformanceTest ของ CTS ภายใต้ สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
  • [7.5/H-1-6] ต้องมีเวลาในการเริ่มต้น camera2 (เปิดกล้องไปยังเฟรมตัวอย่างแรก) น้อยกว่า 600 มิลลิวินาทีตามที่วัดโดย CTS camera PerformanceTest ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
2.2.7.3. ฮาร์ดแวร์

หากการใช้งานอุปกรณ์ถือระบุ android.os.Build.VERSION_CODES.R สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์ดังกล่าวมีลักษณะดังนี้

  • [7.1.1.1/H-1-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
  • [7.1.1.3/H-1-1] ต้องมีความหนาแน่นของหน้าจออย่างน้อย 400 DPI
  • [7.6.1/H-1-1] ต้องมีหน่วยความจำจริงอย่างน้อย 6 GB
2.2.7.4. ประสิทธิภาพ

หากการใช้งานอุปกรณ์ถือระบุ android.os.Build.VERSION_CODES.R สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS แสดงว่าอุปกรณ์ดังกล่าวมีลักษณะดังนี้

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

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. ซอฟต์แวร์

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

  • [3/T-0-1] ต้องประกาศฟีเจอร์ android.software.leanback และ android.hardware.type.television
  • [3.2.3.1/T-0-1] ต้องโหลดล่วงหน้าอย่างน้อย 1 แอปพลิเคชันหรือคอมโพเนนต์บริการที่มีตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
  • [3.4.1/T-0-1] ต้องมีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.5. โมเดลความปลอดภัย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. ฮาร์ดแวร์

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

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

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

  • [7.2.4/W-0-1] ต้องรองรับการป้อนข้อมูลด้วยหน้าจอสัมผัส

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.5. โมเดลความปลอดภัย

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

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

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

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

2.5 ข้อกำหนดด้านยานยนต์

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

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

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

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

2.5.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเครื่องรับ 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 อย่างร่วมกัน

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

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

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

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

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

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

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

  • ควรมีกล้องที่มองเห็นภายนอกอย่างน้อย 1 ตัว

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.5. โมเดลความปลอดภัย

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

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

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

ขนาดหน้าจอ

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

ไจโรสโคป

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

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

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

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

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

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

  • [7.7.1/แท็บ] อาจใช้ Android Open Accessory (AOA) API

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

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

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

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 ความเข้ากันได้ของ Managed API

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

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

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

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

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

  • [C-0-4] ต้องยังคงแสดง API และทำงานอย่างสมเหตุสมผล แม้ว่าจะละเว้นฟีเจอร์ฮาร์ดแวร์บางอย่างที่ Android มี API ไว้ให้ก็ตาม ดูข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ได้ที่ส่วนที่ 7

  • [C-0-5] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK ซึ่งกำหนดเป็นเมธอดและฟิลด์ในแพ็กเกจภาษา Java ที่อยู่ในเส้นทางการบูตใน AOSP และไม่ได้เป็นส่วนหนึ่งของ SDK สาธารณะ ซึ่งรวมถึง API ที่ตกแต่งด้วยคำอธิบายประกอบ @hide แต่ไม่ได้ตกแต่งด้วย @SystemAPI ตามที่อธิบายไว้ในเอกสาร SDK และสมาชิกคลาสแบบส่วนตัวและแบบแพ็กเกจส่วนตัว

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

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

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

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

3.1.1. ส่วนขยาย Android

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

การใช้งานอุปกรณ์ Android

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

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

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

3.1.2. ไลบรารี Android

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

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

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

3.2 ความเข้ากันได้ของ API แบบยืดหยุ่น

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

3.2.1. สิทธิ์

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

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

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

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

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

เช่น

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

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

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

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

3.2.3.1. Intent ของแอปพลิเคชันที่พบบ่อย

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

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

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

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

3.2.3.2. การแก้ปัญหา Intent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-5] ต้องมีตัวเลือกให้ผู้ใช้เลือกแอปที่มีบทบาท android.app.role.CALL_REDIRECTION
  • [C-2-6] ต้องปฏิบัติตาม Intent android.intent.action.SENDTO และ android.intent.action.VIEW และจัดหากิจกรรมเพื่อส่ง/แสดงข้อความ SMS
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW และ android.intent.action.DIAL ด้วยแอปพลิเคชันโทรศัพท์ที่โหลดไว้ล่วงหน้าซึ่งสามารถจัดการ Intent เหล่านี้และให้บริการตามที่อธิบายไว้ใน SDK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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] ต้องซ่อนเนื้อหาอย่างปลอดภัยในทุกหน้าจอเมื่ออุปกรณ์ล็อกด้วยหน้าจอล็อกที่ปลอดภัย เว้นแต่แอปจะเลือกแสดงที่ด้านบนของหน้าจอล็อกโดยใช้ API Activity#setShowWhenLocked()
  • ควรมี android.content.res.Configuration ที่สอดคล้องกับจอแสดงผลนั้นเพื่อให้แสดงผล ทำงานได้อย่างถูกต้อง และรักษาความเข้ากันได้หากมีการเปิดใช้งานในจอแสดงผลรอง

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

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

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

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

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

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

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

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

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

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

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

    • libaaudio.so (การรองรับเสียงดั้งเดิมของ AAudio)
    • libamidi.so (การรองรับ MIDI ดั้งเดิม หากมีการอ้างสิทธิ์ฟีเจอร์ android.software.midi ตามที่อธิบายไว้ในส่วนที่ 5.9)
    • libandroid.so (รองรับกิจกรรม Android ดั้งเดิม)
    • libc (ไลบรารี C)
    • libcamera2ndk.so
    • libdl (ตัวลิงก์แบบไดนามิก)
    • libEGL.so (การจัดการพื้นผิว OpenGL ดั้งเดิม)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (การบันทึกของ Android)
    • libmediandk.so (รองรับ API สื่อดั้งเดิม)
    • libm (ไลบรารีคณิตศาสตร์)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (รองรับ OpenMAX AL 1.0.1)
    • libOpenSLES.so (รองรับเสียง OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (รองรับ C++ ขั้นต่ำ)
    • libvulkan.so (Vulkan)
    • libz (การบีบอัด Zlib)
    • อินเทอร์เฟซ JNI

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

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

โปรดทราบว่า Android รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.1. การจำกัดแอปพลิเคชัน

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

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

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

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เลย์เอาต์หน้าจอ ความหนาแน่นของหน้าจอ หน่วยความจำแอปพลิเคชันขั้นต่ำ
Android Watch 120 dpi (ldpi) 32MB
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] ต้องมีส่วนที่ผู้ใช้สามารถโต้ตอบได้เพื่อขอความยินยอมจากผู้ใช้ก่อนเพิ่มทางลัดที่แอปขอผ่านเมธอด API ShortcutManager.requestPinShortcut()
  • [C-2-3] ต้องรองรับทางลัดที่ปักหมุด รวมถึงทางลัดแบบไดนามิกและแบบคงที่ตามที่ระบุไว้ในหน้าทางลัดของแอป

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

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

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

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

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

3.8.2. วิดเจ็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ดูส่วน 3.2.3.5 สำหรับ Intent การตั้งค่าเพื่อกำหนดค่าโปรแกรมพักหน้าจอ

3.8.12. ตำแหน่ง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับหน้าต่าง 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 API ของ DisplayCutout จะกำหนดพื้นที่ที่ขอบของจอแสดงผลซึ่งอาจใช้งานไม่ได้สำหรับแอปพลิเคชันเนื่องจากรอยบากของจอแสดงผลหรือจอแสดงผลโค้งที่ขอบ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์ประกาศ 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 ผู้ใช้ต้องเข้าถึงฟีเจอร์นี้ได้จากหน้าจอล็อกโดยไม่ต้องปลดล็อกอุปกรณ์

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

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

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

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

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

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

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

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

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

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

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

3.12. กรอบงานอินพุตทีวี

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

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

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

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

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

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

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

3.14. UI ของสื่อ

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

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

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

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

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

3.15. Instant Apps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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 , APK Signature Scheme v2 และการลงนาม JAR
  • [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik bytecode หรือ RenderScript bytecode ในลักษณะที่จะป้องกันไม่ให้ติดตั้งและเรียกใช้ไฟล์เหล่านั้นได้อย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้

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

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

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

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

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

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

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

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

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

  • หากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้วและไม่สามารถปฏิบัติตามข้อกำหนด [C-0-8] และ [C-0-9] ผ่านการอัปเดตซอฟต์แวร์ระบบได้ ระบบอาจยกเว้นข้อกำหนดเหล่านี้ให้

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-3-1] เฟรมเสียง PCM 16 บิตที่มีลำดับไบต์ดั้งเดิมผ่าน 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 (โปรไฟล์ HE AAC แบบขยายของ ISO/IEC 23003-3 ซึ่งรวมถึงโปรไฟล์พื้นฐานของ USAC และโปรไฟล์การควบคุมช่วงไดนามิกของ ISO/IEC 23003-4)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE รวมถึงรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และ 8 ช่อง โปรดทราบว่าข้อกำหนดนี้มีไว้สำหรับการถอดรหัสเท่านั้น และอุปกรณ์ได้รับอนุญาตให้ลดตัวอย่างและลดมิกซ์ในระหว่างขั้นตอนการเล่น
  • [C-1-10] Opus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการใช้งานอุปกรณ์รองรับการถอดรหัสวิดีโอ 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] ต้องส่งคืนค่าที่ถูกต้องของการกำหนดลักษณะตัวแปลงรหัสสื่อผ่าน MediaCodecInfo API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.5. H.265

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 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) ผ่าน Media API ให้ทำดังนี้

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-SR] ขอแนะนำให้ประกาศผ่านเมธอด AcousticEchoCanceler API AcousticEchoCanceler.isAvailable()
  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้เอฟเฟกต์เสียงนี้เพื่อให้ควบคุมได้ด้วย API AcousticEchoCanceler
  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ระบุการติดตั้งใช้งานเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกันผ่านฟิลด์ AudioEffect.Descriptor.uuid

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

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

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

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

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

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

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

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

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

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

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

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

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

    • อัตราการสุ่มตัวอย่าง: 24000, 48000

5.5.2. เอฟเฟกต์เสียง

Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.audio.output จะมีผลดังนี้

  • [C-1-1] ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect Equalizer และ LoudnessEnhancer
  • [C-1-2] ต้องรองรับการติดตั้งใช้งาน Visualizer API ซึ่งควบคุมได้ผ่านคลาส Visualizer
  • [C-1-3] ต้องรองรับการใช้งาน EFFECT_TYPE_DYNAMICS_PROCESSING ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect DynamicsProcessing
  • ควรจะรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์ในรูปแบบทศนิยมและหลายช่อง

5.5.3. ระดับเสียงเอาต์พุตเสียง

การติดตั้งใช้งานอุปกรณ์ยานยนต์

  • ควรอนุญาตให้ปรับระดับเสียงแยกกันสำหรับแต่ละสตรีมเสียงโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย AudioAttributes และการใช้งานเสียงในรถยนต์ตามที่กำหนดไว้แบบสาธารณะใน android.car.CarAudioManager

5.6 เวลาในการตอบสนองของเสียง

เวลาในการตอบสนองของเสียงคือความล่าช้าของเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายประเภทต้องอาศัยเวลาในการตอบสนองที่สั้นเพื่อให้ได้เอฟเฟกต์เสียงแบบเรียลไทม์

สำหรับวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้

  • เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM กับเวลาที่เสียงที่เกี่ยวข้องจะแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
  • เวลาในการตอบสนองของเอาต์พุตที่ไม่ได้แคช เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดเครื่องก่อนที่จะมีคำขอ
  • เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมถัดไปหลังจากที่อุปกรณ์เล่นเสียง
  • เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต กับช่วงเวลาที่แอปพลิเคชันอ่านเฟรมที่สอดคล้องกันของข้อมูลที่เข้ารหัส PCM
  • อินพุตสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
  • เวลาในการตอบสนองต่อการป้อนข้อมูลครั้งแรก ผลรวมของเวลาที่สูญเสียไปในการป้อนข้อมูลและเวลาในการตอบสนองต่อการป้อนข้อมูลสำหรับเฟรมแรก เมื่อระบบป้อนข้อมูลเสียงไม่ได้ใช้งานและปิดเครื่องก่อนคำขอ
  • เวลาในการตอบสนองต่อการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมถัดไปขณะที่อุปกรณ์บันทึกเสียง
  • ความกระตุกของเอาต์พุตเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตเย็นแยกกัน
  • ความกระตุกของอินพุตเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบเย็นแยกกัน
  • เวลาในการรับส่งข้อมูลแบบต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่องบวกกับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องบวกกับระยะเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและมีเวลาลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
  • OpenSL ES PCM buffer queue API ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
  • AAudio Native Audio API ชุด API ของ AAudio ภายใน Android NDK
  • การประทับเวลา คู่ประกอบด้วยตำแหน่งเฟรมที่สัมพันธ์กันภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าหรือออกจากไปป์ไลน์การประมวลผลเสียงในอุปกรณ์ปลายทางที่เชื่อมโยง ดูAudioTimestamp ด้วย
  • ข้อบกพร่อง การหยุดชะงักชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง ซึ่งโดยปกติเกิดจากบัฟเฟอร์ขาดสำหรับเอาต์พุต บัฟเฟอร์เกินสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนแบบดิจิทัลหรืออนาล็อก

หากการใช้งานอุปกรณ์ประกาศ android.hardware.audio.output อุปกรณ์ดังกล่าวต้องเป็นไปตามหรือเกินกว่าข้อกำหนดต่อไปนี้

  • [C-1-1] การประทับเวลาเอาต์พุตที่ส่งคืนโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำ +/- 2 มิลลิวินาที
  • [C-1-2] เวลาในการตอบสนองของเอาต์พุตเย็นไม่เกิน 500 มิลลิวินาที

หากการใช้งานอุปกรณ์ประกาศว่าandroid.hardware.audio.output ขอแนะนำอย่างยิ่งให้เป็นไปตามหรือเกินกว่าข้อกำหนดต่อไปนี้

  • [C-SR] เวลาในการตอบสนองเอาต์พุตแบบเริ่มใหม่ไม่เกิน 100 มิลลิวินาที เราขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ ในการเปิดตัวแพลตฟอร์มในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold ต้องเป็น 200 มิลลิวินาทีหรือน้อยกว่า
  • [C-SR] เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
  • [C-SR] ลดความกระวนกระวายของเอาต์พุตเย็น
  • [C-SR] การประทับเวลาเอาต์พุตที่ส่งคืนโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำ +/- 1 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังจากทำการปรับเทียบครั้งแรกแล้ว เมื่อใช้ทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ AAudio Native Audio API สำหรับเวลาในการตอบสนองเอาต์พุตต่อเนื่องและเวลาในการตอบสนองเอาต์พุตเย็นในอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อย 1 เครื่อง จะมีลักษณะดังนี้

  • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำโดยการประกาศฟีเจอร์แฟล็ก android.hardware.audio.low_latency
  • [C-SR] ขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
  • [C-SR] ขอแนะนำอย่างยิ่งเพื่อให้มั่นใจว่าสำหรับสตรีมที่แสดงผล AAUDIO_PERFORMANCE_MODE_LOW_LATENCY จาก AAudioStream_getPerformanceMode() ค่าที่แสดงผลโดย AAudioStream_getFramesPerBurst() จะน้อยกว่าหรือเท่ากับค่าที่แสดงผลโดย android.media.AudioManager.getProperty(String) สำหรับคีย์พร็อพเพอร์ตี้ AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER

หากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่านทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ API เสียงดั้งเดิมของ AAudio อุปกรณ์ดังกล่าวจะ

  • [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

หากการใช้งานอุปกรณ์มี android.hardware.microphone อุปกรณ์ดังกล่าวต้องเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

  • [C-3-1] จำกัดข้อผิดพลาดในประทับเวลาของอินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลไว้ที่ +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงค่าเบี่ยงเบนจากค่าที่ถูกต้อง
  • [C-3-2] เวลาในการตอบสนองต่ออินพุตเย็นไม่เกิน 500 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์มี android.hardware.microphone เราขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

  • [C-SR] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาที เราขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ ในการเปิดตัวแพลตฟอร์มในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองอินพุตแบบเย็นต้องไม่เกิน 200 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองของอินพุตอย่างต่อเนื่องไม่เกิน 30 มิลลิวินาที
  • [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
  • [C-SR] ลดความกระวนกระวายของอินพุตเย็น
  • [C-SR] จำกัดข้อผิดพลาดในไทม์สแตมป์อินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลเป็น +/- 1 มิลลิวินาที

5.7. โปรโตคอลเครือข่าย

การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบ Android SDK

หากการใช้งานอุปกรณ์มีตัวถอดรหัสเสียงหรือวิดีโอ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)

  • [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านโปรโตคอลฉบับร่าง HTTP Live Streaming เวอร์ชัน 7

  • [C-1-3] ต้องรองรับโปรไฟล์เสียงและวิดีโอ RTP และตัวแปลงรหัสที่เกี่ยวข้องในตาราง RTSP ด้านล่าง ดูข้อยกเว้นได้ที่เชิงอรรถของตารางในส่วนที่ 5.1

รูปแบบกลุ่มสื่อ

รูปแบบกลุ่ม การอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
สตรีมส่ง MPEG-2 ISO 13818 ตัวแปลงรหัสวิดีโอ:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP
และ MPEG-2 ได้ที่ส่วนที่ 5.1.3

ตัวแปลงสัญญาณเสียง:

  • AAC
ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
AAC ที่มีเฟรม ADTS และแท็ก ID3 ISO 13818-7 ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
WebVTT WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์ การอ้างอิง การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC RFC 6184 ดูรายละเอียดเกี่ยวกับ H264 AVC ได้ที่ส่วนที่ 5.1.3
MP4A-LATM RFC 6416 ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
H263-1998 RFC 3551
RFC 4629
RFC 2190 		ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.3
H263-2000 RFC 4629 ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.3
AMR RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-NB ได้ที่ส่วน 5.1.1
AMR-WB RFC 4867 ดูรายละเอียดเกี่ยวกับ AMR-WB ได้ที่ส่วน 5.1.1
MP4V-ES RFC 6416 ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ได้ที่ส่วนที่ 5.1.3
mpeg4-generic RFC 3640 ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
MP2T RFC 2250 ดูรายละเอียดได้ที่ MPEG-2 Transport Stream ในส่วน HTTP Live Streaming

5.8 Secure Media

หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับพื้นผิวที่ปลอดภัย อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

หากการใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE และรองรับโปรโตคอลการแสดงผลแบบไร้สาย อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกที่แข็งแกร่งทางคริปโตกราฟี เช่น HDCP 2.x ขึ้นไป สำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และรองรับจอแสดงผลภายนอกแบบมีสาย อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อผ่านพอร์ตแบบมีสายที่ผู้ใช้เข้าถึงได้

5.9. Musical Instrument Digital Interface (MIDI)

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมด ซึ่งมีการเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI โดยการรับส่งดังกล่าวต้องมีลักษณะดังนี้

    • โหมดโฮสต์ USB ส่วน 7.7
    • MIDI ผ่านบลูทูธ LE ที่ทำหน้าที่เป็นศูนย์กลาง ส่วน 7.4.3

  • [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 เวลาในการตอบสนองของเสียง ต้องไม่เกิน 20 มิลลิวินาที และควรไม่เกิน 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
  • [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
  • [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
  • [C-1-5] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB โดยใช้ทั้ง API คิวบัฟเฟอร์ PCM ของ OpenSL ES และเส้นทางอย่างน้อย 1 เส้นทางของ API AAudio native audio
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้ API AAudio native audio ผ่าน MMAP path เพื่อให้เป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB
  • [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตเย็นไม่เกิน 200 มิลลิวินาที
  • [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุตแบบเย็นไม่เกิน 200 มิลลิวินาที
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อรักษาประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและภาระงานของ CPU เปลี่ยนแปลง ควรทดสอบโดยใช้แอป Android เวอร์ชันรหัสคอมมิต 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 ของ SynthMark SynthMark ใช้ซินธิไซเซอร์ซอฟต์แวร์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองซึ่งวัดประสิทธิภาพของระบบ คุณต้องเรียกใช้แอป SynthMark โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และให้ได้ผลลัพธ์ต่อไปนี้
    • voicemark.90 >= 32 เสียง
    • latencymark.fixed.little <= 15 มิลลิวินาที
    • latencymark.dynamic.little <= 50 มิลลิวินาที

ดูคำอธิบายเกี่ยวกับเกณฑ์มาตรฐานได้ในเอกสารประกอบของ SynthMark

  • ควรลดความไม่ถูกต้องและการเลื่อนของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน
  • ควรลดการเลื่อนของนาฬิกาเสียงที่สัมพันธ์กับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่
  • ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์
  • ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
  • ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
  • ควรลดความกระวนกระวายในเวลาเริ่มต้นของโปรแกรมเรียกกลับการเสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากจะส่งผลต่อเปอร์เซ็นต์ที่ใช้ได้ของแบนด์วิดท์ CPU เต็มรูปแบบโดยโปรแกรมเรียกกลับ
  • ควรไม่มีเสียงขัดข้องภายใต้การใช้งานปกติที่เวลาในการตอบสนองที่รายงาน
  • ควรไม่มีความแตกต่างของเวลาในการตอบสนองระหว่างช่อง
  • ควรลดเวลาในการตอบสนองของ MIDI โดยเฉลี่ยในการรับส่งทั้งหมด
  • ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI ภายใต้ภาระงาน (ความกระตุก) ในการรับส่งข้อมูลทั้งหมด
  • ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งทั้งหมด
  • ควรลดสัญญาณรบกวนของสัญญาณเสียงในทรานสดิวเซอร์ในอุปกรณ์ ซึ่งรวมถึงช่วงเวลาหลังจาก Cold Start ทันที
  • ควรให้ความแตกต่างของสัญญาณนาฬิกาเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของอุปกรณ์ปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตแจ็คเสียง
  • ควรจัดการการเรียกกลับเมื่อบัฟเฟอร์เสียงของอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้องในเธรดเดียวกันเสร็จสมบูรณ์เมื่อทั้ง 2 อย่างทำงานอยู่ และเข้าสู่การเรียกกลับของเอาต์พุตทันทีหลังจากกลับจากการเรียกกลับของอินพุต หรือหากไม่สามารถจัดการการเรียกกลับในเธรดเดียวกัน ให้ป้อนการเรียกกลับเอาต์พุตหลังจากป้อนการเรียกกลับอินพุตไม่นาน เพื่อให้แอปพลิเคชันมีเวลาที่สอดคล้องกันของฝั่งอินพุตและเอาต์พุต
  • ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง
  • ควรลดเวลาในการตอบสนองต่อการสัมผัส
  • ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระงาน (ความกระตุก)
  • ควรมีเวลาในการตอบสนองจากอินพุตการแตะไปยังเอาต์พุตเสียงไม่เกิน 40 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด อุปกรณ์จะ

  • [SR] ขอแนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager

หากการใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์ จะต้องมีคุณสมบัติดังนี้

หากการติดตั้งใช้งานอุปกรณ์ไม่มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB อุปกรณ์ดังกล่าวจะ

  • [C-3-1] ต้องใช้คลาสเสียง USB
  • [C-3-2] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงอย่างต่อเนื่องไม่เกิน 20 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB
  • เวลาในการตอบสนองไป-กลับของเสียงอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่าผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันได้สูงสุด 8 ช่องต่อทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต HDMI อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรรองรับเอาต์พุตแบบสเตอริโอและ 8 แชนเนลที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มตัวอย่างใหม่ ในการกำหนดค่าอย่างน้อย 1 รายการ

5.11. จับภาพสำหรับรายการที่ยังไม่ได้ประมวลผล

Android รองรับการบันทึกเสียงที่ยังไม่ได้ประมวลผลผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES คุณจะเข้าถึงได้ด้วยค่าที่กำหนดล่วงหน้าสำหรับการบันทึก SL_ANDROID_RECORDING_PRESET_UNPROCESSED

หากการติดตั้งใช้งานอุปกรณ์มีจุดประสงค์เพื่อรองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผลและทำให้พร้อมใช้งานในแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานการรองรับผ่านพร็อพเพอร์ตี้ android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

  • [C-1-2] ต้องแสดงลักษณะแอมพลิจูดเทียบกับความถี่ที่ค่อนข้างคงที่ในช่วงความถี่กลาง กล่าวคือ ±10dB จาก 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

  • [C-1-3] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ กล่าวคือ ตั้งแต่ ±20 dB จาก 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

  • [C-1-4] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่สูง กล่าวคือ ตั้งแต่ ±30 dB จาก 7000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

  • [C-1-5] ต้องตั้งค่าความไวของอินพุตเสียงเพื่อให้แหล่งกำเนิดเสียงโทนไซนูโซดัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ผลลัพธ์ที่มี RMS 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างแบบจุดลอย/ความแม่นยำสองเท่า) สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งกำเนิดเสียงที่ยังไม่ได้ประมวลผล

  • [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล (ในขณะที่ SNR วัดเป็นความแตกต่างระหว่าง 94 dB SPL กับ SPL ที่เทียบเท่าของสัญญาณรบกวนในตัว ซึ่งถ่วงน้ำหนัก A)

  • [C-1-7] ต้องมีค่าความเพี้ยนฮาร์มอนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ในไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

  • ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมอัตราขยายอัตโนมัติ ตัวกรองแบบผ่านสูง หรือการตัดเสียงก้อง) ในเส้นทางนอกเหนือจากตัวคูณระดับเพื่อนำระดับไปยังช่วงที่ต้องการ กล่าวคือ

  • [C-1-8] หากมีการประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าจะด้วยเหตุผลใดก็ตาม จะต้องปิดใช้และทำให้เส้นทางสัญญาณไม่มีการหน่วงเวลาหรือเวลาในการตอบสนองเพิ่มเติม
  • [C-1-9] ตัวคูณระดับ แม้ว่าจะอนุญาตให้ใช้ในเส้นทางได้ แต่ต้องไม่ทำให้เกิดความล่าช้าหรือเวลาในการตอบสนองในเส้นทางสัญญาณ

การวัด SPL ทั้งหมดจะดำเนินการข้างไมโครโฟนที่อยู่ระหว่างการทดสอบโดยตรง สำหรับการกำหนดค่าไมโครโฟนหลายรายการ ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone แต่ไม่รองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องแสดงผล null สำหรับเมธอด API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) เพื่อระบุว่าไม่มีการรองรับอย่างถูกต้อง
  • [SR] ยังคงเป็นตัวเลือกที่แนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดส่วนใหญ่สำหรับเส้นทางสัญญาณของแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล

6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์

6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับเครื่องมือสำหรับนักพัฒนาแอป Android ที่มีให้ใน Android SDK

  • Android Debug Bridge (adb)

    • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง dumpsys cmd stats
    • [C-0-11] ต้องรองรับคำสั่ง Shell cmd testharness การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มีการบล็อกข้อมูลถาวรอาจได้รับการยกเว้นจาก C-0-11
    • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบของอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
    • [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับcmd statsคำสั่ง Shell และคลาส System API ของ StatsManager
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] ต้องมี daemon adb ฝั่งอุปกรณ์ที่ไม่ได้ใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
    • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่ได้รับการตรวจสอบสิทธิ์ที่รู้จัก
    • [C-0-6] ต้องมีกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

    หากการใช้งานอุปกรณ์ที่ไม่มีพอร์ต USB รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

    • [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

  • บริการตรวจสอบข้อบกพร่องของ Dalvik (ddms)

    • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรปิดใช้งานโดยค่าเริ่มต้น แต่ต้องรองรับทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามที่ระบุไว้ข้างต้น
  • Monkey
    • [C-0-8] ต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
  • SysTrace
    • [C-0-9] ต้องรองรับเครื่องมือ Systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace
  • Perfetto
    • [C-SR] ขอแนะนำอย่างยิ่งให้แสดง/system/bin/perfettoไบนารีต่อผู้ใช้เชลล์ซึ่งบรรทัดคำสั่งเป็นไปตามเอกสารประกอบของ Perfetto
    • [C-SR] ขอแนะนำอย่างยิ่งให้ไบนารีของ Perfetto ยอมรับการกำหนดค่า Protobuf เป็นอินพุตซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ไบนารีของ Perfetto เพื่อเขียนเอาต์พุตเป็นร่องรอย Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
    • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไบนารีของ Perfetto
  • Low Memory Killer
    • [C-0-10] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBERAtom ลงในบันทึก statsd เมื่อ Low Memory Killer ปิดแอป
  • โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่ง Shell cmd testharness และเรียกใช้ cmd testharness enable อุปกรณ์จะทำสิ่งต่อไปนี้

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านฟีเจอร์แฟล็ก android.hardware.vulkan.version อุปกรณ์ดังกล่าวจะ

  • [C-1-1] ต้องมีส่วนที่นักพัฒนาแอปใช้เปิด/ปิดเลเยอร์การแก้ไขข้อบกพร่อง GPU ได้
  • [C-1-2] ต้องแสดงรายการเลเยอร์ในไลบรารีที่เครื่องมือภายนอกจัดหาให้ (กล่าวคือ ไม่ได้เป็นส่วนหนึ่งของแพลตฟอร์มหรือแพ็กเกจแอปพลิเคชัน) ซึ่งพบในไดเรกทอรีฐานของแอปพลิเคชันที่แก้ไขข้อบกพร่องได้ เพื่อรองรับเมธอด API vkEnumerateInstanceLayerProperties() และ vkCreateInstance() เมื่อเปิดใช้เลเยอร์การแก้ไขข้อบกพร่องของ GPU

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

Android มีการรองรับให้นักพัฒนาแอปกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาแอป โดยมีข้อกำหนดดังนี้

  • [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การติดตั้งใช้งาน Android ต้นทางจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาแอปได้หลังจากกด 7 ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
  • [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น
  • [C-0-3] ต้องมีกลไกที่ชัดเจนซึ่งไม่ให้สิทธิพิเศษแก่แอปของบุคคลที่สามแอปใดแอปหนึ่งเมื่อเทียบกับแอปอื่นเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป ต้องระบุเอกสารหรือเว็บไซต์ที่มองเห็นได้แบบสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป เอกสารหรือเว็บไซต์นี้ต้องลิงก์จากเอกสาร Android SDK ได้
  • ควรมีการแจ้งเตือนด้วยภาพอย่างต่อเนื่องแก่ผู้ใช้เมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปและมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้
  • MAY อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาแอปชั่วคราวโดยการซ่อนหรือปิดใช้เมนูเพื่อป้องกันไม่ให้ผู้ใช้เสียสมาธิในสถานการณ์ที่กังวลเรื่องความปลอดภัยของผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีคอมโพเนนต์ฮาร์ดแวร์ที่เฉพาะเจาะจงซึ่งมี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งาน API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่ระบุว่าไม่บังคับและอุปกรณ์ที่ใช้งานไม่มีคอมโพเนนต์ดังกล่าว

  • [C-0-2] ต้องยังคงแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้ในเอกสาร) สำหรับ API ของคอมโพเนนต์
  • [C-0-3] ต้องใช้ลักษณะการทำงานของ API เป็นการดำเนินการที่ไม่มีผลในลักษณะที่สมเหตุสมผล
  • [C-0-4] เมธอด API ต้องแสดงค่า Null ในกรณีที่เอกสารประกอบของ SDK อนุญาต
  • [C-0-5] เมธอด API ต้องแสดงผลการติดตั้งใช้งานแบบไม่มีการดำเนินการของคลาสที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
  • [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
  • [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

ตัวอย่างทั่วไปของสถานการณ์ที่ต้องใช้ข้อกำหนดเหล่านี้คือ Telephony API แม้ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ API เหล่านี้ก็ต้องได้รับการติดตั้งใช้งานเป็นแบบไม่มีการดำเนินการที่สมเหตุสมผล

7.1. การแสดงผลและกราฟิก

Android มีเครื่องมือที่ปรับเนื้อหาของแอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติให้เหมาะสมกับอุปกรณ์ เพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะทำงานได้ดีในการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย ในจอแสดงผลที่รองรับ Android ซึ่งแอปพลิเคชันทั้งหมดของบุคคลที่สามที่รองรับ Android สามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้มีการกำหนดดังนี้

  • ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้าม 2 มุมของส่วนที่สว่างของจอแสดงผล
  • จุดต่อนิ้ว (DPI) จํานวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งเชิงเส้น 1 นิ้ว เมื่อระบุค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วง
  • สัดส่วนภาพ อัตราส่วนของพิกเซลด้านที่ยาวกว่าต่อด้านที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะมีอัตราส่วนเป็น 854/480 = 1.779 หรือประมาณ "16:9"
  • ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นหน้าจอ 160 dpi โดยคำนวณเป็นพิกเซล = dp * (ความหนาแน่น/160)

7.1.1. การกำหนดค่าหน้าจอ

7.1.1.1. ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลากหลาย และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ Configuration.screenLayout ตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอเป็นพิกเซลอิสระ (dp) เชิงตรรกะที่ถูกต้องดังนี้

    • อุปกรณ์ที่ตั้งค่า Configuration.uiMode เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_WATCH และรายงานขนาด small สำหรับ Configuration.screenLayout จะต้องมีขนาดอย่างน้อย 426 dp x 320 dp
    • อุปกรณ์ที่รายงานnormalขนาดสำหรับConfiguration.screenLayoutต้องมีขนาดอย่างน้อย 480 dp x 320 dp
    • อุปกรณ์ที่รายงานlargeขนาดสำหรับConfiguration.screenLayoutต้องมีขนาดอย่างน้อย 640 dp x 480 dp
    • อุปกรณ์ที่รายงานขนาด xlarge สำหรับ Configuration.screenLayout ต้องมีขนาดอย่างน้อย 960 dp x 720 dp

  • [C-0-2] ต้องปฏิบัติตามการรองรับขนาดหน้าจอที่แอปพลิเคชันระบุอย่างถูกต้องผ่านแอตทริบิวต์ <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

  • อาจมีจอแสดงผลที่ใช้ได้กับ Android ซึ่งมีมุมโค้งมน

หากการติดตั้งใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL และมีจอแสดงผลที่รองรับ Android พร้อมมุมโค้ง อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องตรวจสอบว่ามีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ
  • รัศมีของมุมโค้งมนน้อยกว่าหรือเท่ากับ 38 dp

  • เมื่อยึดกล่องขนาด 15 dp x 15 dp ไว้ที่มุมแต่ละมุมของจอแสดงผลเชิงตรรกะ จะมองเห็นอย่างน้อย 1 พิกเซลของแต่ละกล่องบนหน้าจอ

  • ควรมีส่วนที่ผู้ใช้สามารถเปลี่ยนเป็นโหมดแสดงผลที่มีมุมเป็นสี่เหลี่ยมผืนผ้า

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่รองรับ Android ซึ่งพับได้ หรือมีบานพับระหว่างแผงจอแสดงผลหลายแผงและทำให้จอแสดงผลดังกล่าวพร้อมใช้งานเพื่อแสดงผลแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่เข้ากันได้กับ Android ซึ่งพับได้ หรือมีบานพับที่พับได้ระหว่างแผงจอแสดงผลหลายแผง และหากบานพับหรือรอยพับตัดผ่านหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอ จะต้องมีลักษณะดังนี้

  • [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือรอยพับผ่านส่วนขยายหรือ API แบบ Sidecar ไปยังแอปพลิเคชัน

ดูรายละเอียดเกี่ยวกับการติดตั้งใช้งาน Sidecar หรือ Extension API อย่างถูกต้องได้ในเอกสารประกอบแบบสาธารณะของ Window Manager Jetpack

7.1.1.2. สัดส่วนภาพของหน้าจอ

แม้ว่าจะไม่มีข้อจำกัดเกี่ยวกับสัดส่วนภาพของจอแสดงผลจริงสำหรับจอแสดงผลที่ใช้ร่วมกับ Android แต่สัดส่วนภาพของจอแสดงผลเชิงตรรกะที่แอปของบุคคลที่สามแสดงผล ซึ่งได้มาจากค่าความสูงและความกว้างที่รายงานผ่าน API ของ view.Display และ API ของ Configuration จะต้องเป็นไปตามข้อกำหนดต่อไปนี้

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_NORMAL ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะมีคุณสมบัติตรงตามเงื่อนไขต่อไปนี้

    • แอปได้ประกาศว่ารองรับสัดส่วนภาพของหน้าจอที่ใหญ่ขึ้นผ่านค่าข้อมูลเมตา android.max_aspect
    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไปและไม่ได้ประกาศ android:maxAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

  • [C-0-2] การติดตั้งใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_NORMAL จะต้องมีค่าสัดส่วนภาพเท่ากับหรือมากกว่า 1.3333 (4:3) เว้นแต่จะขยายแอปให้กว้างขึ้นได้โดยเป็นไปตามเงื่อนไขต่อไปนี้

    • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
    • แอปประกาศ android:minAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

  • [C-0-3] การติดตั้งใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_WATCH จะต้องมีค่าสัดส่วนภาพตั้งค่าเป็น 1.0 (1:1)

7.1.1.3. ความหนาแน่นของหน้าจอ

เฟรมเวิร์ก UI ของ Android กำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยให้นักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรของแอปพลิเคชัน

  • [C-0-1] โดยค่าเริ่มต้น การติดตั้งใช้งานอุปกรณ์ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android เพียงรายการเดียวที่แสดงใน DisplayMetrics ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องไม่เปลี่ยนแปลงในทุกกรณี อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่กำหนดเองที่แตกต่างกันตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ซึ่งตั้งค่าหลังจากบูตครั้งแรก

  • การใช้งานอุปกรณ์ควรระบุความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานซึ่งมีค่าตัวเลขใกล้เคียงกับความหนาแน่นทางกายภาพของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าขนาดต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพมากที่สุดส่งผลให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่รองรับ (ความกว้าง 320 dp) การติดตั้งใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป

หากมีตัวเลือกในการเปลี่ยนขนาดการแสดงผลของอุปกรณ์ ให้ทำดังนี้

  • [C-1-1] ขนาดการแสดงผลต้องไม่ปรับขนาดให้ใหญ่กว่าความหนาแน่นดั้งเดิม 1.5 เท่า หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพให้เล็กกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) ไม่ว่ากรณีใดจะเกิดขึ้นก่อน
  • [C-1-2] ขนาดการแสดงผลต้องไม่ได้รับการปรับขนาดให้เล็กกว่าความหนาแน่นดั้งเดิม 0.85 เท่า
  • เพื่อรับประกันความสามารถในการใช้งานที่ดีและขนาดแบบอักษรที่สอดคล้องกัน เราขอแนะนำให้ระบุการปรับขนาดตัวเลือกโฆษณา Display เนทีฟต่อไปนี้ (พร้อมทั้งปฏิบัติตามขีดจำกัดที่ระบุไว้ข้างต้น)
  • เล็ก: 0.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15x
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

7.1.2. เมตริกการแสดงผล

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่ใช้ร่วมกับ Android หรือเอาต์พุตวิดีโอไปยังหน้าจอแสดงผลที่ใช้ร่วมกับ Android อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่ใช้ร่วมกับ Android ได้ซึ่งกำหนดไว้ใน API ของ android.util.DisplayMetrics

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอแบบฝังหรือเอาต์พุตวิดีโอ อุปกรณ์ดังกล่าวจะ

  • [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่ใช้ร่วมกับ Android ตามที่กำหนดไว้ใน API ของ android.util.DisplayMetrics สำหรับ view.Display เริ่มต้นที่จำลอง

7.1.3. การวางแนวหน้าจอ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น โทรทัศน์หรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
  • [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

หากการใช้งานอุปกรณ์รองรับทั้งการวางแนวหน้าจอ 2 แบบ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันให้เป็นแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เฉพาะเจาะจง
  • [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
  • MAY อาจเลือกการวางแนวเป็นแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API ดั้งเดิม
  • [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API ดั้งเดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุว่ารองรับ

หากการใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุและอธิบายไว้ในเอกสารประกอบ Android SDK
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
  • ควรรองรับ OpenGL ES 3.2

หากการใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดเวอร์ชันหนึ่ง จะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องรายงานผ่าน API ที่จัดการของ OpenGL ES และ API ดั้งเดิมของส่วนขยาย OpenGL ES อื่นๆ ที่ได้ติดตั้งใช้งาน และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
  • [C-2-2] ต้องรองรับส่วนขยาย EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable และ EGL_ANDROID_GLES_layers
  • [C-SR] ขอแนะนําอย่างยิ่งให้รองรับส่วนขยาย EGL_KHR_partial_update และ OES_EGL_image_external
  • ควรรายงานอย่างถูกต้องผ่านเมธอด getString() รูปแบบการบีบอัดพื้นผิวใดก็ตามที่รองรับ ซึ่งโดยปกติแล้วจะเป็นรูปแบบเฉพาะของผู้ให้บริการ

หากการใช้งานอุปกรณ์ประกาศการรองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้ นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย OES_EGL_image_external_essl3

หากการใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 อุปกรณ์จะ

  • [C-4-1] ต้องรองรับ OpenGL ES Android Extension Pack ทั้งหมด

หากการใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES ทั้งหมด อุปกรณ์จะทำสิ่งต่อไปนี้ได้

  • [C-5-1] ต้องระบุการรองรับผ่านฟีเจอร์แฟล็ก android.hardware.opengles.aep

หากการติดตั้งใช้งานอุปกรณ์เปิดเผยการรองรับส่วนขยาย EGL_KHR_mutable_render_buffer อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย
7.1.4.2 Vulkan

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

หากการใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำสิ่งต่อไปนี้

  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1

หากการใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • ควรมีการรองรับ Vulkan 1.1

การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เชื่อมโยง โดยไฟล์เหล่านี้อยู่ในโครงสร้างแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/vk-master-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 รายการสำหรับ API ดั้งเดิมของ Vulkan vkEnumeratePhysicalDevices()
  • [C-1-3] ต้องใช้ API ของ Vulkan 1.0 อย่างเต็มรูปแบบสำหรับแต่ละ VkPhysicalDevice ที่ระบุ
  • [C-1-4] ต้องแสดงรายการเลเยอร์ที่อยู่ในไลบรารีเนทีฟซึ่งมีชื่อเป็น libVkLayer*.so ในไดเรกทอรีไลบรารีเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน Vulkan Native API vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
  • [C-1-5] ต้องไม่แจงนับเลเยอร์ที่จัดทำโดยไลบรารีภายนอกแพ็กเกจแอปพลิเคชัน หรือจัดหาวิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีandroid:debuggableแอตทริบิวต์ที่ตั้งค่าเป็น true
  • [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน Vulkan Native API และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
  • [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
  • [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของ Vulkan dEQP Tests ที่รองรับผ่านฟีเจอร์แฟล็ก android.software.vulkan.deqp.level
  • [C-1-9] ต้องรองรับเวอร์ชัน 132317953 (ตั้งแต่วันที่ 1 มี.ค. 2019) เป็นอย่างน้อยตามที่รายงานในฟีเจอร์แฟล็ก android.software.vulkan.deqp.level
  • [C-1-10] ต้องผ่านการทดสอบ dEQP ของ Vulkan ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132317953 กับเวอร์ชันที่ระบุในฟีเจอร์แฟล็ก android.software.vulkan.deqp.level
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย VK_KHR_driver_properties และ VK_GOOGLE_display_timing

หากการใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 จะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่ประกาศฟีเจอร์แฟล็ก Vulkan ใดๆ (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
  • [C-2-2] ต้องไม่แจงนับ VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()

หากการใช้งานอุปกรณ์รองรับ Vulkan 1.1 และประกาศค่าสถานะฟีเจอร์ Vulkan ใดๆ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องแสดงการรองรับSYNC_FDประเภทภายนอกของ Semaphore และประเภทแฮนเดิล รวมถึงส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer
7.1.4.3 RenderScript
  • [C-0-1] การใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน, กิจกรรม, หน้าต่าง หรือมุมมองผ่านการใช้แท็ก Manifest android:hardwareAccelerated หรือการเรียก API โดยตรง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปขอให้ทำเช่นนั้นโดยการตั้งค่า android:hardwareAccelerated="false” หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
  • [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งด้วยฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการใช้งาน Android ต้นทาง
7.1.4.5 จอแสดงผลแบบขอบเขตสีกว้าง

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับจอแสดงผลแบบไวด์แกมมาผ่าน Configuration.isScreenWideColorGamut() จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสีแล้ว
  • [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตสีครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
  • [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตสีซึ่งมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ xyY ของ CIE 1931
  • [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
  • [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear และ EGL_EXT_gl_colorspace_display_p3_passthrough
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ GL_EXT_sRGB

ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รองรับจอแสดงผลแบบ Wide Gamut จะเกิดสิ่งต่อไปนี้

  • [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] ต้องใช้บริการระบบและ API ของ DisplayManager ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

7.2. อุปกรณ์อินพุต

การติดตั้งใช้งานอุปกรณ์

7.2.1. แป้นพิมพ์

หากการใช้งานอุปกรณ์รองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องประกาศฟีเจอร์แฟล็ก android.software.input_methods
  • [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
  • [C-1-3] ต้องมีแป้นพิมพ์ซอฟต์แวร์ที่ติดตั้งไว้ล่วงหน้า

การใช้งานอุปกรณ์: * [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 ปุ่ม) * ควรมีการติดตั้งใช้งานแป้นพิมพ์เสมือนเพิ่มเติม * อาจมีแป้นพิมพ์ฮาร์ดแวร์

7.2.2. การไปยังส่วนต่างๆ โดยไม่ต้องสัมผัส

Android รองรับ D-pad, แทร็กบอล และวงล้อเป็นกลไกสำหรับการไปยังส่วนต่างๆ แบบไม่สัมผัส

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์ไม่มีการนำทางแบบไม่สัมผัส อุปกรณ์จะ

  • [C-1-1] ต้องมีกลไกอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสำหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือจัดการอินพุต การใช้งานโอเพนซอร์สของ Android ต้นทางมีกลไกการเลือกที่เหมาะกับการใช้กับอุปกรณ์ที่ไม่มีอินพุตการนำทางแบบไม่สัมผัส

7.2.3. ปุ่มนำทาง

ฟังก์ชันหน้าแรก ล่าสุด และกลับ ซึ่งโดยปกติจะมาจากการโต้ตอบกับปุ่มจริงเฉพาะหรือส่วนที่แตกต่างกันของหน้าจอสัมผัส เป็นสิ่งจำเป็นสำหรับกระบวนทัศน์การนำทางของ Android และการใช้งานอุปกรณ์

  • [C-0-1] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้เปิดแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่มี <intent-filter> ตั้งค่าด้วย ACTION=MAIN และ CATEGORY=LAUNCHER หรือ CATEGORY=LEANBACK_LAUNCHER สำหรับการติดตั้งใช้งานอุปกรณ์โทรทัศน์ ฟังก์ชันหน้าแรกควรเป็นกลไกสำหรับความสามารถของผู้ใช้รายนี้
  • ควรมีปุ่มสำหรับฟังก์ชันล่าสุดและย้อนกลับ

หากมีฟังก์ชันหน้าแรก แอปที่ใช้ล่าสุด หรือย้อนกลับ แอปจะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงได้
  • [C-1-2] ต้องระบุอย่างชัดเจนว่าการดำเนินการเดียวใดที่จะเรียกใช้ฟังก์ชันแต่ละอย่าง ตัวอย่างของการระบุเช่นนี้ ได้แก่ การมีไอคอนที่มองเห็นได้ซึ่งพิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนที่มีคำแนะนำในระหว่างประสบการณ์การตั้งค่าเมื่อแกะกล่อง

การติดตั้งใช้งานอุปกรณ์

  • [SR] ขอแนะนำอย่างยิ่งว่าอย่าระบุกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากฟังก์ชันนี้เลิกใช้งานแล้วและเปลี่ยนไปใช้แถบการทำงานตั้งแต่ Android 4.0

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันเมนู อุปกรณ์ดังกล่าวจะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องแสดงปุ่มเมนูการดำเนินการเพิ่มเติมทุกครั้งที่เมนูป๊อปอัปการดำเนินการเพิ่มเติมไม่ว่างเปล่าและแถบการดำเนินการปรากฏอยู่
  • [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มเพิ่มเติมในแถบการดำเนินการ แต่สามารถแสดงป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขบนหน้าจอได้เมื่อแสดงโดยการเลือกฟังก์ชันเมนู

หากการติดตั้งใช้งานอุปกรณ์ไม่มีฟังก์ชันเมนู เพื่อให้มีความเข้ากันได้แบบย้อนหลัง อุปกรณ์จะต้องมีลักษณะดังนี้

  • [C-3-1] ต้องทำให้ฟังก์ชันเมนูพร้อมใช้งานสำหรับแอปพลิเคชันเมื่อ targetSdkVersion น้อยกว่า 10 ไม่ว่าจะผ่านปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการนำทางอื่นๆ

หากการใช้งานอุปกรณ์มีฟังก์ชันช่วยเหลือ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-4-1] ต้องทำให้ฟังก์ชันช่วยเหลือเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงปุ่มนำทางอื่นๆ ได้
  • [SR] ขอแนะนำอย่างยิ่งให้ใช้การกดฟังก์ชันหน้าแรกค้างไว้เป็นการโต้ตอบที่กำหนด

หากการใช้งานอุปกรณ์ใช้ส่วนที่แตกต่างกันของหน้าจอเพื่อแสดงปุ่มนำทาง อุปกรณ์ดังกล่าวจะ

  • [C-5-1] ปุ่มนำทางต้องใช้ส่วนที่แตกต่างกันของหน้าจอซึ่งแอปพลิเคชันไม่สามารถเข้าถึงได้ และต้องไม่บดบังหรือรบกวนส่วนของหน้าจอที่แอปพลิเคชันเข้าถึงได้
  • [C-5-2] ต้องจัดสรรพื้นที่แสดงผลส่วนหนึ่งให้กับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
  • [C-5-3] ต้องปฏิบัติตามค่าสถานะที่แอปตั้งค่าผ่านเมธอด API View.setSystemUiVisibility() เพื่อให้ส่วนที่แตกต่างกันของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ซ่อนไว้อย่างถูกต้องตามที่ระบุไว้ใน SDK

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการกระทำบนหน้าจอที่อิงตามท่าทางสัมผัส ให้ทำดังนี้

  • [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 การปัดจากขอบจะต้องทํางานตามที่ได้ติดตั้งใช้งานใน AOSP ซึ่งมีการบันทึกไว้ในSDK
  • [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่าแฟล็ก View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY ระบบจะต้องซ่อนแผงระบบที่ปัดได้แบบกำหนดเองจนกว่าผู้ใช้จะนำแถบระบบ (หรือที่เรียกว่าแถบนำทางและแถบสถานะ) เข้ามาตามที่ใช้งานใน 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 ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (อิงตามเคอร์เซอร์) ที่มีความเที่ยงตรงสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจำลองอินพุตแบบสัมผัสได้อย่างเหมาะสม (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสที่จำลองมาบางส่วน

หากการใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่มีระบบอินพุตพอยน์เตอร์อื่นที่ต้องการให้ใช้งานได้ ผู้ผลิตจะต้องดำเนินการดังนี้

  • ควรประกาศการรองรับฟีเจอร์แฟล็ก android.hardware.faketouch

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานตำแหน่ง X และ Y แบบสัมบูรณ์บนหน้าจอของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ภาพบนหน้าจอ
  • [C-1-2] ต้องรายงานเหตุการณ์การแตะด้วยรหัสการดำเนินการที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นกับเคอร์เซอร์เลื่อนลงหรือขึ้นบนหน้าจอ
  • [C-1-3] ต้องรองรับการกดและการปล่อยเคอร์เซอร์บนออบเจ็กต์บนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้จำลองการแตะออบเจ็กต์บนหน้าจอได้
  • [C-1-4] ต้องรองรับการกดตัวชี้ การปล่อยตัวชี้ การกดตัวชี้แล้วปล่อยตัวชี้ในตำแหน่งเดียวกันบนออบเจ็กต์บนหน้าจอภายในเกณฑ์เวลา ซึ่งจะช่วยให้ผู้ใช้จำลองการแตะสองครั้งบนออบเจ็กต์บนหน้าจอได้
  • [C-1-5] ต้องรองรับการกดตัวชี้ที่จุดใดก็ได้บนหน้าจอ การย้ายตัวชี้ไปยังจุดอื่นๆ บนหน้าจอ และการปล่อยตัวชี้ ซึ่งจะช่วยให้ผู้ใช้จำลองการลากด้วยการสัมผัสได้
  • [C-1-6] ต้องรองรับการกดตัวชี้ จากนั้นอนุญาตให้ผู้ใช้ย้ายออบเจ็กต์ไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว แล้วปล่อยตัวชี้บนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้ปัดออบเจ็กต์บนหน้าจอได้

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ 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
ปุ่ม การใช้งาน HID2 ปุ่ม Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
ปุ่ม D-pad ขึ้น1
ปุ่ม D-pad ลง1 		0x01 0x00393 AXIS_HAT_Y4
D-pad ซ้าย1
D-pad ขวา1 		0x01 0x00393 AXIS_HAT_X4
ปุ่ม L1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
ปุ่ม R1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
คลิกที่ก้านซ้าย1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
คลิกที่ก้านขวา1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
หน้าแรก1 0x0c 0x0223 KEYCODE_HOME (3)
กลับ1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 ต้องประกาศการใช้งาน HID ข้างต้นภายใน CA ของ Game pad (0x01 0x0005)

3 การใช้งานนี้ต้องมีค่าต่ำสุดเชิงตรรกะเป็น 0 ค่าสูงสุดเชิงตรรกะเป็น 7 ค่าต่ำสุดเชิงกายภาพเป็น 0 ค่าสูงสุดเชิงกายภาพเป็น 315 หน่วยเป็นองศา และขนาดรายงานเป็น 4 ค่าตรรกะจะกำหนดให้เป็นการหมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง เช่น ค่าตรรกะ 0 หมายถึงไม่มีการหมุนและมีการกดปุ่มขึ้น ในขณะที่ค่าตรรกะ 1 หมายถึงการหมุน 45 องศาและมีการกดทั้งปุ่มขึ้นและปุ่มซ้าย

4 MotionEvent

การควบคุมแบบอนาล็อก1 การใช้งาน HID ปุ่ม Android
ทริกเกอร์ซ้าย 0x02 0x00C5 AXIS_LTRIGGER
ทริกเกอร์ขวา 0x02 0x00C4 AXIS_RTRIGGER
จอยสติ๊กซ้าย 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
จอยสติ๊กขวา 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. การควบคุมระยะไกล

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วนที่ 2.3.1

7.3 เซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK และเอกสารประกอบของ Android Open Source เกี่ยวกับเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager
  • [C-0-2] ต้องแสดงรายการเซ็นเซอร์ที่รองรับอย่างถูกต้องผ่าน SensorManager.getSensorList() และวิธีการที่คล้ายกัน
  • [C-0-3] ต้องทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น โดยการแสดงผล true หรือ false ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียกใช้ Listener ของเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

  • [C-1-1] ต้องรายงานการวัดเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK
  • [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีของสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองที่ขอสูงสุด 0 มิลลิวินาทีเมื่อโปรเซสเซอร์แอปพลิเคชันทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง
  • [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำเป็น 0 ได้
  • [C-1-4] สำหรับ API ใดๆ ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์ต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะๆ อย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยที่ความผันผวนหมายถึงค่าเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน
  • [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือปลุกจากสถานะระงับ
  • [C-1-6] ต้องรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กําหนดไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงเวลาที่เกิดเหตุการณ์และซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีข้อผิดพลาดในการซิงโครไนซ์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงโครไนซ์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
  • เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น โดยพฤติกรรมที่บันทึกไว้ของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์ถือเป็นแหล่งข้อมูลที่เชื่อถือได้

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

  • [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่าผ่านเมธอด API Sensor.getResolution()

เซ็นเซอร์บางประเภทเป็นแบบผสม ซึ่งหมายความว่าสามารถได้มาจากข้อมูลที่เซ็นเซอร์อื่นๆ อย่างน้อย 1 ตัวให้ไว้ (ตัวอย่างเช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์ความเร่งเชิงเส้น)

การติดตั้งใช้งานอุปกรณ์

  • ควรใช้เซ็นเซอร์ประเภทเหล่านี้เมื่อมีเซ็นเซอร์จริงที่เป็นข้อกำหนดเบื้องต้นตามที่อธิบายไว้ในประเภทเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์แบบผสม อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์แบบผสม

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม และเซ็นเซอร์รายงานค่าเพียงค่าเดียว การใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สำหรับเซ็นเซอร์และรายงานค่าผ่านเมธอด API Sensor.getResolution()

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์นั้นแสดงต่อผู้พัฒนาแอปบุคคลที่สาม ผู้พัฒนาแอปบุคคลที่สามจะต้องดำเนินการต่อไปนี้

  • [C-4-1] ต้องไม่รวมพารามิเตอร์การปรับเทียบที่กำหนดจากโรงงานและคงที่ไว้ในข้อมูลที่ให้

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการผสมผสานระหว่างตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์ไจโรสโคปแบบ 3 แกน หรือเซ็นเซอร์แมกนีโตมิเตอร์ จะมีลักษณะดังนี้

  • [C-SR] ขอแนะนำอย่างยิ่งเพื่อให้แน่ใจว่าตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมีตำแหน่งสัมพัทธ์คงที่ เพื่อให้หากอุปกรณ์แปลงสภาพได้ (เช่น พับได้) แกนเซ็นเซอร์จะยังคงสอดคล้องและสอดคล้องกับระบบพิกัดเซ็นเซอร์ตลอดสถานะการแปลงสภาพที่เป็นไปได้ทั้งหมดของอุปกรณ์

7.3.1. ตัวตรวจวัดความเร่ง

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมตัวตรวจวัดความเร่งแบบ 3 แกน

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
  • [C-1-4] ต้องวัดได้ตั้งแต่การตกอย่างอิสระจนถึง 4 เท่าของแรงโน้มถ่วง(4g) ขึ้นไปในแกนใดก็ได้
  • [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
  • [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดยควรคำนวณค่าเบี่ยงเบนมาตรฐานต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด
  • [SR] ขอแนะนำเป็นอย่างยิ่งให้ใช้TYPE_SIGNIFICANT_MOTIONเซ็นเซอร์แบบผสม
  • [SR] ขอแนะนำเป็นอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_UNCALIBRATED ขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีคุณสมบัติตรงตามข้อกำหนดนี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้ ซึ่งอาจต้องใช้ข้อกำหนดนี้
  • ควรใช้เซ็นเซอร์แบบผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK
  • ควรรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 200 Hz
  • ควรมีความละเอียดอย่างน้อย 16 บิต
  • ควรได้รับการปรับเทียบขณะใช้งานหากลักษณะเปลี่ยนแปลงตลอดวงจรการใช้งานและได้รับการชดเชย และเก็บรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
  • ควรมีการชดเชยอุณหภูมิ

หากการใช้งานอุปกรณ์มีมาตรวัดความเร่ง 3 แกนและมีการใช้งานเซ็นเซอร์แบบผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER อย่างใดอย่างหนึ่ง ให้ทำดังนี้

  • [C-2-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
  • ควรมีกำลังต่ำกว่า 2 มิลลิวัตต์และ 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่ในสภาวะไดนามิกหรือสภาวะคงที่

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องใช้เซ็นเซอร์ผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
  • [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-4-1] ต้องติดตั้งใช้งานTYPE_ROTATION_VECTORเซ็นเซอร์แบบผสม

7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเครื่องวัดสนามแม่เหล็กแบบ 3 แกน (เข็มทิศ)

หากการใช้งานอุปกรณ์มีแมกนีโตมิเตอร์ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องติดตั้งใช้งานTYPE_MAGNETIC_FIELDเซ็นเซอร์
  • [C-1-2] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
  • [C-1-4] ต้องวัดค่าได้ระหว่าง -900 µT ถึง +900 µT ในแต่ละแกนก่อนที่จะอิ่มตัว
  • [C-1-5] ต้องมีค่าออฟเซ็ตของเหล็กกล้าต่ำกว่า 700 µT และควรมีค่าต่ำกว่า 200 µT โดยวางแมกนีโตมิเตอร์ให้ห่างจากสนามแม่เหล็กแบบไดนามิก (เกิดจากกระแส) และแบบคงที่ (เกิดจากแม่เหล็ก)
  • [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 µT
  • [C-1-7] ต้องรองรับการปรับเทียบและการชดเชยออฟเซ็ตฮาร์ดไอรอนแบบออนไลน์ และเก็บรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
  • [C-1-8] ต้องมีการชดเชยเหล็กอ่อน การปรับเทียบสามารถทำได้ทั้งขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
  • [C-1-9] ต้องมีค่าเบี่ยงเบนมาตรฐานที่คำนวณตามแกนแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด โดยต้องไม่เกิน 1.5 µT และควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT
  • [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องใช้TYPE_ROTATION_VECTORเซ็นเซอร์ผสม

หากการติดตั้งใช้งานอุปกรณ์มีแมกนีโตมิเตอร์แบบ 3 แกนและตัววัดความเร่ง อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • อาจติดตั้งใช้งานเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน ตัวตรวจวัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR จะมีลักษณะดังนี้

  • [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
  • ควรใช้พลังงานน้อยกว่า 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดเป็นชุดที่ 10 Hz

7.3.3. GPS

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเครื่องรับ GPS/GNSS

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่านฟีเจอร์แฟล็ก android.hardware.location.gps อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งที่อัตราอย่างน้อย 1 Hz เมื่อมีการขอผ่าน LocationManager#requestLocationUpdate
  • [C-1-2] ต้องระบุตำแหน่งในสภาพท้องฟ้าเปิด (สัญญาณแรง, การรบกวนจากหลายเส้นทางน้อยมาก, HDOP < 2) ได้ภายใน 10 วินาที (เวลาในการหาตำแหน่งครั้งแรกอย่างรวดเร็ว) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วในการรับส่งข้อมูลตั้งแต่ 0.5 Mbps ขึ้นไป โดยปกติแล้ว ข้อกำหนดนี้จะทำได้โดยใช้เทคนิค GPS/GNSS ที่มีการช่วยหรือคาดการณ์ในรูปแบบใดรูปแบบหนึ่งเพื่อลดเวลาในการล็อก GPS/GNSS (ข้อมูลการช่วยประกอบด้วยเวลาอ้างอิง สถานที่อ้างอิง และตารางวงโคจร/นาฬิกาของดาวเทียม)
    • [C-1-6] หลังจากทำการคำนวณตำแหน่งดังกล่าวแล้ว การใช้งานอุปกรณ์จะต้องกำหนดตำแหน่งในที่โล่งภายใน 5 วินาที เมื่อมีการรีสตาร์ทคำขอตำแหน่ง นานถึง 1 ชั่วโมงหลังจากคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอครั้งต่อๆ ไปโดยไม่มีการเชื่อมต่อข้อมูล และ/หรือหลังจากเปิดปิดเครื่อง

  • ในสภาพท้องฟ้าเปิดหลังจากกำหนดตำแหน่งแล้ว ขณะที่อยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 1 เมตรต่อวินาทีกำลังสอง ให้ทำดังนี้

    • [C-1-3] ต้องระบุตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.5 เมตรต่อวินาทีได้อย่างน้อย 95% ของเวลาทั้งหมด
    • [C-1-4] ต้องติดตามและรายงานผ่าน GnssStatus.Callback พร้อมกันอย่างน้อย 8 ดาวเทียมจากกลุ่มดาวเทียม 1 กลุ่ม
    • ควรติดตามดาวเทียมอย่างน้อย 24 ดวงจากกลุ่มดาวหลายกลุ่มได้พร้อมกัน (เช่น GPS + อย่างน้อย 1 กลุ่มจาก Glonass, Beidou, Galileo)
    • [C-SR] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ต่อไปในระหว่างการโทรฉุกเฉิน
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวเทียมทั้งหมดที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
    • [C-SR] ขอแนะนําอย่างยิ่งให้รายงาน AGC และความถี่ของการวัด GNSS
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึง Bearing, Speed และ Vertical) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
    • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานระยะเทียม GNSS และอัตราการเปลี่ยนแปลงของระยะเทียม ซึ่งในสภาพท้องฟ้าเปิดหลังจากกำหนดตำแหน่งแล้ว ขณะที่อยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีกำลังสอง จะเพียงพอต่อการคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา

7.3.4. เครื่องวัดการหมุน

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเซ็นเซอร์ไจโรสโคป

หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคปแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
  • [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย
  • [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป และควรมีความละเอียด 16 บิตขึ้นไป
  • [C-1-5] ต้องมีการชดเชยอุณหภูมิ
  • [C-1-6] ต้องได้รับการปรับเทียบและชดเชยขณะใช้งาน และรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
  • [C-1-7] ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) ความแปรปรวนจะแตกต่างกันไปตามอัตราการสุ่มตัวอย่างได้ แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโรที่อัตราการสุ่มตัวอย่าง 1 Hz ความแปรปรวนดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
  • [SR] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการปรับเทียบควรน้อยกว่า 0.01 เรเดียน/วินาทีเมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
  • ควรรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 200 Hz

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุนแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องใช้TYPE_ROTATION_VECTORเซ็นเซอร์ผสม

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องใช้เซ็นเซอร์ผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
  • [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR

7.3.5. บารอมิเตอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีบารอมิเตอร์ (เซ็นเซอร์ความดันอากาศโดยรอบ)

หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องติดตั้งใช้งานและรายงานTYPE_PRESSUREเซ็นเซอร์
  • [C-1-2] ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
  • [C-1-3] ต้องมีการชดเชยอุณหภูมิ
  • [SR] ขอแนะนำอย่างยิ่งเพื่อให้สามารถรายงานการวัดความดันในช่วง 300hPa ถึง 1100hPa
  • ควรมีความแม่นยำสัมบูรณ์ 1 hPa
  • ควรมีความแม่นยำสัมพัทธ์ 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 บิตขึ้นไป

7.3.9. เซ็นเซอร์ที่มีความแม่นยำสูง

หากการติดตั้งใช้งานอุปกรณ์มีชุดเซ็นเซอร์คุณภาพสูงกว่าตามที่กำหนดไว้ในส่วนนี้ และทำให้แอปของบุคคลที่สามใช้งานได้ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องระบุความสามารถผ่านฟีเจอร์แฟล็ก android.hardware.sensor.hifi_sensors

หากการใช้งานอุปกรณ์ประกาศ android.hardware.sensor.hifi_sensors จะมีข้อกำหนดดังนี้

  • [C-2-1] ต้องมีเซ็นเซอร์ TYPE_ACCELEROMETER ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง -8g ถึง +8g เป็นอย่างน้อย และขอแนะนำอย่างยิ่งให้มีช่วงการวัดระหว่าง -16g ถึง +16g เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
    • ต้องมีความถี่ในการวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 400 μg/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 3,000 รายการ
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 3 มิลลิวัตต์
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนแบบไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีการเดินแบบสุ่มของการเร่งความเร็วที่น้อยกว่า 30 μg √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
    • ควรมีเส้นแนวโน้มที่เหมาะสมที่สุดที่มีความไม่เป็นเชิงเส้น ≤ 0.5% และการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.03%/C°
    • ควรมีความไวต่อแกนขวางน้อยกว่า 2.5 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

  • [C-2-2] ต้องมี TYPE_ACCELEROMETER_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_ACCELEROMETER

  • [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดอย่างน้อยระหว่าง -1000 ถึง +1000 dps
    • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
    • ต้องมีความถี่ในการวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.014°/s/√Hz
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนแบบไวท์นอยส์ภายในแบนด์วิดท์นี้
    • ควรมีการเดินแบบสุ่มของอัตราที่น้อยกว่า 0.001 °/s √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
    • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
    • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.02% / °C
    • ควรมีเส้นที่เหมาะสมที่สุดซึ่งมีความไม่เชิงเส้น ≤ 0.2%
    • ควรมีความหนาแน่นของสัญญาณรบกวน ≤ 0.007 °/s/√Hz
    • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่
    • ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 0.1°/s/g
    • ควรมีความไวต่อแกนขวางน้อยกว่า 4.0 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

  • [C-2-4] ต้องมี TYPE_GYROSCOPE_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ TYPE_GYROSCOPE

  • [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
    • ต้องมีความถี่ในการวัดอย่างน้อย 5 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 50 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.5 uT

  • [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ TYPE_GEOMAGNETIC_FIELD และนอกจากนี้

    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 600 รายการ
    • [C-SR] ขอแนะนำอย่างยิ่งให้มีสเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานอยู่ที่ 50 Hz ขึ้นไป

  • [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่งมีคุณสมบัติดังนี้

    • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
    • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
    • ต้องมีความถี่ในการวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
    • ต้องมีความถี่ในการวัดสูงสุด 10 Hz ขึ้นไป
    • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 2 Pa/√Hz
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 300 รายการ
    • ต้องมีการใช้พลังงานแบบเป็นกลุ่มไม่เกิน 2 มิลลิวัตต์
  • [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
  • [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 100 รายการ
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
    • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 4 มิลลิวัตต์
  • [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่งมีลักษณะดังนี้
    • ต้องมีการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • [C-2-13] การประทับเวลาของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่ง ไจโรสโคป และเครื่องวัดสนามแม่เหล็กต้องอยู่ภายใน 2.5 มิลลิวินาทีของกันและกัน การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่งและไจโรสโคปควรอยู่ภายใน 0.25 มิลลิวินาทีของกันและกัน
  • [C-2-14] ต้องมีการประทับเวลาของเหตุการณ์เซ็นเซอร์ไจโรสโคปบนฐานเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดภายใน 1 มิลลิวินาที
  • [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงข้างต้นไปยังแอปพลิเคชัน
  • [C-2-16] ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 2.0 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่เมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] อาจมีเซ็นเซอร์ TYPE_PROXIMITY แต่หากมีจะต้องมีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์จากเซ็นเซอร์

โปรดทราบว่าข้อกำหนดการใช้พลังงานทั้งหมดในส่วนนี้ไม่รวมการใช้พลังงานของ Application Processor ซึ่งรวมถึงกำลังไฟที่ใช้โดยห่วงโซ่เซ็นเซอร์ทั้งหมด ได้แก่ เซ็นเซอร์ วงจรสนับสนุน ระบบประมวลผลเซ็นเซอร์เฉพาะ ฯลฯ

หากการใช้งานอุปกรณ์รวมถึงการรองรับเซ็นเซอร์โดยตรง อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องประกาศการรองรับประเภทช่องทางโดยตรงและระดับอัตราการรายงานโดยตรงอย่างถูกต้องผ่าน API isDirectChannelTypeSupported และ getHighestDirectReportRateLevel
  • [C-3-2] ต้องรองรับประเภทช่องทางเซ็นเซอร์โดยตรงอย่างน้อย 1 ประเภทจาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศว่ารองรับช่องทางเซ็นเซอร์โดยตรง
  • ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (รูปแบบที่ไม่ใช่การปลุก) ประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. เซ็นเซอร์ไบโอเมตริก

ดูข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยของการปลดล็อกด้วยข้อมูลไบโอเมตริกได้ที่เอกสารประกอบเกี่ยวกับการวัดความปลอดภัยของไบโอเมตริก

หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรมีเซ็นเซอร์ไบโอเมตริก

เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 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] ขอแนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ลบล้างค่ากำหนดของแอปพลิเคชันและกำหนดให้มีขั้นตอนการยืนยันประกอบเสมอ
  • [C-SR] ขอแนะนำอย่างยิ่งให้ดำเนินการยืนยันอย่างปลอดภัยเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกปลอมแปลงการดำเนินการดังกล่าวได้ ตัวอย่างเช่น การดำเนินการยืนยันที่อิงตามปุ่มจริงจะกำหนดเส้นทางผ่านพินอินพุต/เอาต์พุตอเนกประสงค์ (GPIO) แบบอินพุตเท่านั้นขององค์ประกอบที่ปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นใดนอกเหนือจากการกดปุ่มจริง
  • [C-5-2] ต้องใช้ขั้นตอนการตรวจสอบสิทธิ์โดยนัย (ไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationRequired(boolean) เพิ่มเติม ซึ่งแอปพลิเคชันสามารถตั้งค่าเพื่อใช้สำหรับขั้นตอนการลงชื่อเข้าใช้ได้

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกหลายตัว จะมีลักษณะดังนี้

  • [C-SR] ขอแนะนำอย่างยิ่งให้กำหนดให้ยืนยันข้อมูลไบโอเมตริกเพียงรายการเดียวต่อการตรวจสอบสิทธิ์ 1 ครั้ง (เช่น หากมีทั้งเซ็นเซอร์ลายนิ้วมือและเซ็นเซอร์ใบหน้าในอุปกรณ์ ควรส่ง onAuthenticationSucceeded หลังจากยืนยันข้อมูลไบโอเมตริกรายการใดรายการหนึ่ง)

การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามเข้าถึงคีย์ในที่เก็บคีย์ โดยมีข้อกำหนดดังนี้

  • [C-6-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 3 ตามที่กำหนดไว้ในส่วนด้านล่างนี้
  • [C-6-2] ต้องแสดงเฉพาะข้อมูลไบโอเมตริกระดับ 3 เมื่อการตรวจสอบสิทธิ์ต้องใช้ BIOMETRIC_STRONG หรือเมื่อเรียกใช้การตรวจสอบสิทธิ์ด้วย CryptoObject

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 1 (เดิมคือความสะดวก) จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดน้อยกว่า 0.002%
  • [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่รัดกุม และระบุความเสี่ยงของการเปิดใช้โหมดนี้อย่างชัดเจน หากอัตราการยอมรับการสวมรอยและการแอบอ้างสูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
  • [C-1-3] ต้องจำกัดอัตราการพยายามเป็นเวลาอย่างน้อย 30 วินาทีหลังจากพยายามยืนยันไบโอเมตริกไม่สำเร็จ 5 ครั้ง โดยการพยายามไม่สำเร็จคือการพยายามที่มีคุณภาพการจับภาพเพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับไบโอเมตริกที่ลงทะเบียนไว้
  • [C-1-4] ต้องป้องกันการเพิ่มไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อนด้วยการให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์ที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบของอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การใช้งาน Android Open Source Project มีกลไกในเฟรมเวิร์กเพื่อดำเนินการดังกล่าว
  • [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ทั้งหมดของผู้ใช้ออกโดยสมบูรณ์เมื่อมีการนำบัญชีของผู้ใช้ออก (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
  • [C-1-6] ต้องปฏิบัติตามการแจ้งว่าไม่ต้องการสำหรับข้อมูลไบโอเมตริกนั้น (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS)
  • [C-1-7] ต้องขอให้ผู้ใช้ยืนยันตัวตนด้วยการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 24 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ใหม่ที่เปิดตัวด้วย Android เวอร์ชัน 10 และทุกๆ 72 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้า

  • [C-1-8] ต้องท้าทายผู้ใช้สำหรับการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้

    • ระยะเวลาที่ไม่มีการใช้งาน 4 ชั่วโมง หรือ
    • พยายามตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก 3 ครั้งไม่สำเร็จ
    • ระบบจะรีเซ็ตระยะหมดเวลาเมื่อไม่มีการใช้งานและจำนวนครั้งที่ตรวจสอบสิทธิ์ไม่สำเร็จหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ

    การอัปเกรดอุปกรณ์จาก Android เวอร์ชันก่อนหน้าอาจได้รับการยกเว้นจาก C-1-8 * [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ตรรกะในเฟรมเวิร์กที่จัดทำโดยโปรเจ็กต์โอเพนซอร์สของ Android เพื่อบังคับใช้ข้อจำกัดที่ระบุไว้ใน [C-1-7] และ [C-1-8] สำหรับอุปกรณ์ใหม่ * [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์ * [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดตั้งแต่ตรวจพบข้อมูลไบโอเมตริกจนถึงปลดล็อกหน้าจอสำหรับข้อมูลไบโอเมตริกแต่ละรายการที่ลงทะเบียนไว้

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 2 (เดิมคืออ่อน) จะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องมีคุณสมบัติตรงตามข้อกำหนดทั้งหมดสำหรับคลาส 1 ด้านบน
  • [C-2-2] ต้องมีอัตราการยอมรับการสวมรอยและการแอบอ้างเป็นบุคคลอื่นไม่เกิน 20% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
  • [C-2-3] ต้องทำการจับคู่ไบโอเมตริกในสภาพแวดล้อมการดำเนินการที่แยกจากกันภายนอกพื้นที่ผู้ใช้หรือเคอร์เนลของ Android เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกจากกัน
  • [C-2-4] ต้องเข้ารหัสข้อมูลที่ระบุตัวบุคคลได้ทั้งหมดและตรวจสอบสิทธิ์ด้วยการเข้ารหัสลับเพื่อให้ไม่สามารถรับ อ่าน หรือเปลี่ยนแปลงข้อมูลภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้หรือชิปที่มีแชแนลที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์ Android Open Source Project
  • [C-2-5] สำหรับข้อมูลไบโอเมตริกที่อิงตามกล้อง ขณะที่กำลังมีการตรวจสอบสิทธิ์หรือการลงทะเบียนด้วยข้อมูลไบโอเมตริก ให้ทำดังนี้
    • ต้องใช้งานกล้องในโหมดที่ป้องกันไม่ให้อ่านหรือแก้ไขเฟรมกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกต่างหากหรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
    • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องจะอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกต่างหากเพื่อรองรับการดำเนินการต่างๆ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่จะยังคงต้องแก้ไขไม่ได้
  • [C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างการลงทะเบียนไบโอเมตริกแต่ละรายการ
  • [C-2-7] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลนั้นได้หรือข้อมูลใดๆ ที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) ที่ไม่ได้เข้ารหัสไปยัง Application Processor นอกบริบทของ TEE

  • [C-2-8] ต้องมีไปป์ไลน์การประมวลผลที่ปลอดภัยเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกสามารถแทรกข้อมูลโดยตรงเพื่อตรวจสอบสิทธิ์อย่างไม่ถูกต้องในฐานะผู้ใช้

    หากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้วและไม่เป็นไปตามข้อกำหนด C-2-8 ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมการตรวจจับความมีชีวิตสำหรับรูปแบบไบโอเมตริกทั้งหมด และการตรวจจับความสนใจสำหรับไบโอเมตริกใบหน้า

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 3 (เดิมคือรัดกุม) จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดของคลาส 2 ด้านบน ยกเว้น [C-1-7] และ [C-1-8] การอัปเกรดอุปกรณ์จาก Android เวอร์ชันก่อนหน้าจะไม่ได้รับการยกเว้นจาก C-2-7
  • [C-3-2] ต้องมีการติดตั้งใช้งานที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์
  • [C-3-3] ต้องมีอัตราการยอมรับการสวมรอยและการแอบอ้างไม่เกิน 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
  • [C-3-4] ต้องแจ้งให้ผู้ใช้ยืนยันตัวตนด้วยการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 72 ชั่วโมงหรือน้อยกว่า

7.3.12. เซ็นเซอร์ท่าทาง

การติดตั้งใช้งานอุปกรณ์

  • อาจรองรับเซ็นเซอร์ท่าทางที่มีองศาอิสระ 6 องศา

หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 ระดับ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_POSE_6DOF
  • [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

7.3.13. เซ็นเซอร์มุมบานพับ

หากการติดตั้งใช้งานอุปกรณ์รองรับเซ็นเซอร์มุมบานพับ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องใช้และรายงาน TYPE_HINGLE_ANGLE
  • [C-1-2] ต้องรองรับการอ่านค่าอย่างน้อย 2 ครั้งระหว่าง 0 ถึง 360 องศา (รวม 0 และ 360 องศา)
  • [C-1-3] ต้องแสดงผลเซ็นเซอร์ปลุกสำหรับ getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)

7.4 การเชื่อมต่อข้อมูล

7.4.1. โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจใช้หรือไม่ใช้การสลับแพ็กเก็ต แต่ก็มีไว้เพื่อวัตถุประสงค์ของ Android ซึ่งถือว่าแยกจากการเชื่อมต่อข้อมูลใดๆ ที่อาจมีการใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันการทำงานและ API ของ "โทรศัพท์" ใน Android จะอ้างอิงถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่ไม่สามารถโทรออกหรือส่ง/รับข้อความ SMS จะไม่ถือว่าเป็นอุปกรณ์โทรศัพท์ ไม่ว่าอุปกรณ์นั้นจะใช้เครือข่ายมือถือเพื่อการเชื่อมต่อข้อมูลหรือไม่ก็ตาม

  • Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องประกาศandroid.hardware.telephonyฟีเจอร์แฟล็กและฟีเจอร์แฟล็กย่อยอื่นๆ ตามเทคโนโลยี
  • [C-1-2] ต้องรองรับ API สำหรับเทคโนโลยีนั้นอย่างเต็มรูปแบบ

หากการติดตั้งใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์โทรศัพท์ จะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องใช้ API ทั้งหมดเป็น no-op

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/SIM แบบฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้ฟังก์ชัน eSIM พร้อมใช้งานสำหรับนักพัฒนาแอปบุคคลที่สาม อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-3-1] ต้องมีการติดตั้งใช้งาน EuiccManager API อย่างสมบูรณ์
7.4.1.1. ความเข้ากันได้ของการบล็อกหมายเลข

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony feature จะมีลักษณะดังนี้

  • [C-1-1] ต้องมีการรองรับการบล็อกหมายเลข
  • [C-1-2] ต้องใช้ BlockedNumberContract และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-3] ต้องบล็อกสายและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยไม่ต้องมีการโต้ตอบกับแอป ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-4] ต้องไม่เขียนไปยังผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก
  • [C-1-5] ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่ถูกบล็อก
  • [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งจะเปิดด้วย Intent ที่ส่งคืนโดยเมธอด TelecomManager.createManageBlockedNumbersIntent()
  • [C-1-7] ต้องไม่อนุญาตให้ผู้ใช้ระดับรองดูหรือแก้ไขหมายเลขที่ถูกบล็อกในอุปกรณ์ เนื่องจากแพลตฟอร์ม Android ถือว่าผู้ใช้หลักมีสิทธิ์ควบคุมบริการโทรศัพท์อย่างเต็มรูปแบบ ซึ่งเป็นอินสแตนซ์เดียวในอุปกรณ์ ระบบต้องซ่อน UI ที่เกี่ยวข้องกับการบล็อกทั้งหมดสำหรับผู้ใช้รอง และต้องยังคงใช้รายการที่ถูกบล็อก
  • ควรย้ายหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0
7.4.1.2. Telecom API

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony จะมีลักษณะดังนี้

  • [C-1-1] ต้องรองรับ API ConnectionService ที่อธิบายไว้ใน SDK
  • [C-1-2] ต้องแสดงสายเรียกเข้าใหม่และให้ผู้ใช้เลือกรับหรือปฏิเสธสายเรียกเข้าเมื่อผู้ใช้กำลังโทรอยู่ซึ่งดำเนินการโดยแอปของบุคคลที่สามที่ไม่รองรับฟีเจอร์พักสายที่ระบุผ่าน CAPABILITY_SUPPORT_HOLD
  • [C-1-3] ต้องมีแอปพลิเคชันที่ใช้ InCallService

  • [C-SR] ขอแนะนำอย่างยิ่งให้แจ้งผู้ใช้ว่าการรับสายเรียกเข้าจะทำให้สายที่กำลังสนทนาอยู่หลุด

    การใช้งาน AOSP เป็นไปตามข้อกำหนดเหล่านี้โดยการแจ้งเตือนแบบลอยซึ่งจะแจ้งให้ผู้ใช้ทราบว่าการรับสายเรียกเข้าจะทำให้สายอื่นถูกตัด

  • [C-SR] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรออกเริ่มต้นล่วงหน้าซึ่งจะแสดงรายการบันทึกการโทรและชื่อของแอปของบุคคลที่สามในบันทึกการโทรเมื่อแอปของบุคคลที่สามตั้งค่าคีย์พิเศษ EXTRA_LOG_SELF_MANAGED_CALLS ใน PhoneAccount เป็น true

  • [C-SR] ขอแนะนำอย่างยิ่งให้จัดการเหตุการณ์ KEYCODE_MEDIA_PLAY_PAUSE และ KEYCODE_HEADSETHOOK ของชุดหูฟังเสียงสำหรับ API android.telecom ดังนี้
    • เรียกใช้ Connection.onDisconnect() เมื่อตรวจพบการกดเหตุการณ์คีย์สั้นๆ ระหว่างการโทรที่กำลังดำเนินอยู่
    • เรียกใช้ Connection.onAnswer() เมื่อตรวจพบการกดเหตุการณ์สำคัญแบบสั้นระหว่างสายเรียกเข้า
    • เรียกใช้ Connection.onReject() เมื่อตรวจพบการกดเหตุการณ์คีย์ค้างระหว่างสายเรียกเข้า
    • สลับสถานะการปิดเสียงของ CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

การติดตั้งใช้งานอุปกรณ์

  • ควรมีการรองรับรูปแบบ 802.11 อย่างน้อย 1 รูปแบบ

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 และเปิดเผยฟังก์ชันการทำงานให้กับแอปพลิเคชันของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้ Android API ที่เกี่ยวข้อง
  • [C-1-2] ต้องรายงานฟีเจอร์แฟล็กของฮาร์ดแวร์ android.hardware.wifi
  • [C-1-3] ต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-4] ต้องรองรับมัลติแคสต์ DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ในเวลาใดก็ตามของการดำเนินการ ซึ่งรวมถึง
    • แม้ว่าหน้าจอจะไม่ได้อยู่ในสถานะที่ใช้งานอยู่
    • สำหรับการติดตั้งใช้งานอุปกรณ์โทรทัศน์ Android แม้ว่าจะอยู่ในสถานะพลังงานสแตนด์บายก็ตาม
  • [C-1-5] ต้องไม่ถือว่าการเรียกเมธอด API WifiManager.enableNetwork() เป็นข้อบ่งชี้ที่เพียงพอในการเปลี่ยน Network ที่ใช้งานอยู่ในปัจจุบันซึ่งใช้โดยค่าเริ่มต้นสำหรับการเข้าชมแอปพลิเคชัน และส่งคืนโดยเมธอด API ConnectivityManager เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ แอปอาจปิดใช้การเข้าถึงอินเทอร์เน็ตที่ผู้ให้บริการเครือข่ายรายอื่น (เช่น เน็ตมือถือ) ให้บริการได้ก็ต่อเมื่อตรวจสอบแล้วว่าเครือข่าย Wi-Fi ให้บริการการเข้าถึงอินเทอร์เน็ต
  • [C-1-6] ขอแนะนำอย่างยิ่งให้เมื่อมีการเรียกใช้เมธอด API ของ ConnectivityManager.reportNetworkConnectivity() ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และเมื่อการประเมินระบุว่า Network ปัจจุบันไม่สามารถเข้าถึงอินเทอร์เน็ตได้อีกต่อไป ให้เปลี่ยนไปใช้เครือข่ายอื่นที่พร้อมใช้งาน (เช่น เน็ตมือถือ) ซึ่งมีการเข้าถึงอินเทอร์เน็ต
  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอ Probe หนึ่งครั้งเมื่อเริ่มต้นการสแกนแต่ละครั้งขณะที่ STA ไม่ได้เชื่อมต่อ
    • เฟรมคำขอ Probe แต่ละกลุ่มที่ประกอบกันเป็น 1 การสแกนควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC ในระหว่างการสแกน)
    • หมายเลขลำดับคำขอ Probe ควรวนซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอ Probe ในการสแกน
    • หมายเลขลำดับคำขอ Probe ควรสุ่มระหว่างคำขอ Probe สุดท้ายของการสแกนกับคำขอ Probe แรกของการสแกนครั้งถัดไป
  • [C-SR] ขอแนะนำอย่างยิ่งในขณะที่ STA ไม่ได้เชื่อมต่อ เพื่ออนุญาตเฉพาะองค์ประกอบต่อไปนี้ในเฟรมคำขอ Probe
    • ชุดพารามิเตอร์ SSID (0)
    • ชุดพารามิเตอร์ DS (3)

หากการใช้งานอุปกรณ์รวมถึงการรองรับโหมดประหยัดพลังงาน Wi-Fi ตามที่กำหนดไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องปิดโหมดประหยัดพลังงาน Wi-Fi ทุกครั้งที่แอปได้รับWIFI_MODE_FULL_HIGH_PERFล็อกหรือWIFI_MODE_FULL_LOW_LATENCYล็อกผ่าน API WifiManager.createWifiLock() และ WifiManager.WifiLock.acquire() และล็อกยังคงใช้งานอยู่
  • [C-3-2] เวลาในการตอบสนองไป-กลับโดยเฉลี่ยระหว่างอุปกรณ์กับจุดเข้าใช้งานขณะที่อุปกรณ์อยู่ในโหมดล็อก Wi-Fi ที่มีความหน่วงต่ำ (WIFI_MODE_FULL_LOW_LATENCY) ต้องน้อยกว่าเวลาในการตอบสนองในโหมดล็อก Wi-Fi ที่มีประสิทธิภาพสูง (WIFI_MODE_FULL_HIGH_PERF)
  • [C-SR] ขอแนะนําอย่างยิ่งให้ลดเวลาในการตอบสนองไป-กลับของ Wi-Fi ให้เหลือน้อยที่สุดทุกครั้งที่ได้รับล็อกเวลาในการตอบสนองต่ำ (WIFI_MODE_FULL_LOW_LATENCY) และมีผล

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi และใช้ Wi-Fi สำหรับการสแกนหาตำแหน่ง อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องมีส่วนควบคุมสำหรับผู้ใช้เพื่อเปิด/ปิดใช้การอ่านค่าผ่านเมธอด WifiManager.isScanAlwaysAvailable API
7.4.2.1. Wi-Fi Direct

การติดตั้งใช้งานอุปกรณ์

  • ควรรองรับ Wi-Fi Direct (Wi-Fi แบบเพียร์ทูเพียร์)

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Direct อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้ Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-2] ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct
  • [C-1-3] ต้องรองรับการทำงานของ Wi-Fi ปกติ
  • [C-1-4] ต้องรองรับการทำงานของ Wi-Fi และ Wi-Fi Direct พร้อมกัน

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLS และ API ของ WiFiManager เปิดใช้ TDLS อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องประกาศการรองรับ TDLS ผ่าน WifiManager.isTdlsSupported
  • ควรใช้ TDL เฉพาะในกรณีที่เป็นไปได้และเป็นประโยชน์
  • ควรมีฮิวริสติกและไม่ใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าถึง Wi-Fi
7.4.2.3. Wi-Fi Aware

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Aware และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้ WifiAwareManager API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องประกาศandroid.hardware.wifi.awareฟีเจอร์แฟล็ก
  • [C-1-3] ต้องรองรับการทำงานของ Wi-Fi และ Wi-Fi Aware พร้อมกัน
  • [C-1-4] ต้องสุ่มที่อยู่อินเทอร์เฟซการจัดการ Wi-Fi Aware ทุกๆ 30 นาทีและทุกครั้งที่เปิดใช้ Wi-Fi Aware เว้นแต่จะมีการดำเนินการวัดระยะ Aware อย่างต่อเนื่องหรือเส้นทางข้อมูล Aware ใช้งานอยู่ (ไม่จำเป็นต้องสุ่มตราบใดที่เส้นทางข้อมูลใช้งานอยู่)

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Aware และตำแหน่ง Wi-Fi ตามที่อธิบายไว้ในส่วน 7.4.2.5 และเปิดเผยฟังก์ชันการทำงานเหล่านี้ต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

7.4.2.4. Passpoint ของ Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 (Wi-Fi) จะต้องมีคุณสมบัติดังนี้

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Passpoint อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-1-2] ต้องใช้ WifiManager API ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
  • [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นหาและการเลือกเครือข่าย เช่น Generic Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)

ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Wi-Fi Passpoint

  • [C-2-1] การใช้งาน API ที่เกี่ยวข้องกับ Passpoint WifiManager ต้องส่ง UnsupportedOperationException
7.4.2.5. ตำแหน่งของ Wi-Fi (ระยะเวลารับส่งข้อมูลของ Wi-Fi - RTT)

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์รองรับตำแหน่ง Wi-Fi และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องดำเนินการต่อไปนี้

  • [C-1-1] ต้องใช้ WifiRttManager API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
  • [C-1-2] ต้องประกาศandroid.hardware.wifi.rttฟีเจอร์แฟล็ก
  • [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางสำหรับแต่ละ RTT Burst ซึ่งดำเนินการในขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT ไม่ได้เชื่อมโยงกับ Access Point
7.4.2.6. การลดภาระการทำงานของ Keepalive ของ Wi-Fi

การติดตั้งใช้งานอุปกรณ์

  • ควรมีการรองรับการส่งต่อการทำงานของ Wi-Fi Keepalive

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับการออฟโหลดการทำงานของ Wi-Fi Keepalive และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องรองรับ API SocketKeepAlive

  • [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi และช่อง Keepalive อย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ

หากการใช้งานอุปกรณ์ไม่รองรับการส่งผ่านการทำงานของ Wi-Fi Keepalive ไปยังฮาร์ดแวร์ อุปกรณ์จะ

7.4.2.7. Wi-Fi Easy Connect (โปรโตคอลการจัดสรรอุปกรณ์)

การติดตั้งใช้งานอุปกรณ์

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Easy Connect และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

7.4.3. บลูทูธ

หากการใช้งานอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ อุปกรณ์จะทำสิ่งต่อไปนี้

  • ควรรองรับตัวแปลงสัญญาณเสียงขั้นสูงและตัวแปลงสัญญาณเสียงบลูทูธ (เช่น LDAC)

หากการใช้งานอุปกรณ์รองรับ HFP, A2DP และ AVRCP อุปกรณ์จะทำสิ่งต่อไปนี้

  • ควรรองรับอุปกรณ์ที่เชื่อมต่อทั้งหมดอย่างน้อย 5 เครื่อง

หากการใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.vr.high_performance จะมีข้อกำหนดดังนี้

  • [C-1-1] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวข้อมูลของบลูทูธ LE

Android รองรับบลูทูธและบลูทูธพลังงานต่ำ

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธและบลูทูธพลังงานต่ำ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องประกาศฟีเจอร์แพลตฟอร์มที่เกี่ยวข้อง (android.hardware.bluetooth และ android.hardware.bluetooth_le ตามลำดับ) และใช้ API ของแพลตฟอร์ม
  • ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVRCP, OBEX, HFP ฯลฯ ตามความเหมาะสมกับอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธพลังงานต่ำ (BLE) อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-3-1] ต้องประกาศฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le
  • [C-3-2] ต้องเปิดใช้ API บลูทูธที่อิงตาม GATT (Generic Attribute Profile) ตามที่อธิบายไว้ในเอกสารประกอบของ SDK และ android.bluetooth
  • [C-3-3] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isOffloadedFilteringSupported() เพื่อระบุว่ามีการใช้ตรรกะการกรองสำหรับคลาส API ของ ScanFilter หรือไม่
  • [C-3-4] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isMultipleAdvertisementSupported() เพื่อระบุว่ารองรับการโฆษณาแบบประหยัดพลังงานหรือไม่
  • [C-3-5] ต้องใช้การหมดเวลาของที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) ไม่เกิน 15 นาที และหมุนเวียนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์ใช้ BLE อย่างต่อเนื่องเพื่อสแกนหรือโฆษณา ช่วงหมดเวลาต้องสุ่มระหว่าง 5 ถึง 15 นาทีด้วยเพื่อป้องกันการโจมตีแบบกำหนดเวลา
  • ควรสนับสนุนการส่งต่อตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API
  • ควรรองรับการส่งต่อการสแกนแบบเป็นชุดไปยังชิปเซ็ตบลูทูธ
  • ควรรองรับโฆษณาหลายรายการที่มีช่องอย่างน้อย 4 ช่อง

หากการใช้งานอุปกรณ์รองรับ Bluetooth LE และใช้ Bluetooth LE สำหรับการสแกนหาตำแหน่ง อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-4-1] ต้องมีส่วนที่ผู้ใช้สามารถเปิด/ปิดใช้ค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable() ได้

หากการใช้งานอุปกรณ์รวมถึงการรองรับโปรไฟล์บลูทูธ LE และเครื่องช่วยฟังตามที่อธิบายไว้ในการรองรับเสียงของเครื่องช่วยฟังโดยใช้บลูทูธ LE อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

7.4.4. Near Field Communication

การติดตั้งใช้งานอุปกรณ์

  • ควรมีตัวรับส่งและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near-Field Communication (NFC)
  • [C-0-1] ต้องใช้ API ของ android.nfc.NdefMessage และ android.nfc.NdefRecord แม้ว่าจะไม่รองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc เนื่องจากคลาสต่างๆ แสดงรูปแบบการแสดงข้อมูลที่ไม่ขึ้นอยู่กับโปรโตคอล

หากการติดตั้งใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC และวางแผนที่จะทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
  • ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ได้
  • [C-1-2] ต้องทำหน้าที่เป็นเครื่องอ่าน/เขียน NFC Forum ได้ (ตามที่กำหนดไว้ในข้อกำหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • ประเภทแท็ก NFC Forum 1, 2, 3, 4, 5 (กำหนดโดย NFC Forum)

  • [SR] ขอแนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC จะระบุว่า "ขอแนะนำอย่างยิ่ง" แต่คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตมีแผนที่จะเปลี่ยนมาตรฐานเหล่านี้เป็น "ต้อง" มาตรฐานเหล่านี้ไม่บังคับในเวอร์ชันนี้ แต่จะต้องใช้ในเวอร์ชันต่อๆ ไป เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้

  • [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC

  • ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานโดยที่หน้าจอเปิดอยู่และหน้าจอล็อกปลดล็อกแล้ว
  • ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์ Thinfilm NFC Barcode ได้

โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่มีให้บริการสำหรับข้อกำหนด JIS, ISO และ NFC Forum ที่อ้างอิงข้างต้น

Android รองรับโหมด Host Card Emulation (HCE) ของ NFC

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทาง Application ID (AID) อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
  • [C-2-2] ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK

หากการใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE สำหรับ NfcF และใช้งานฟีเจอร์สำหรับแอปพลิเคชันของบุคคลที่สาม จะต้องมีลักษณะดังนี้

  • [C-3-1] ต้องรายงานandroid.hardware.nfc.hcefค่าคงที่ของฟีเจอร์
  • [C-3-2] ต้องใช้ NfcF Card Emulation APIs ตามที่กำหนดไว้ใน Android SDK

หากการใช้งานอุปกรณ์รวมถึงการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้ และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทของเครื่องอ่าน/เครื่องเขียน อุปกรณ์ดังกล่าวจะ

  • [C-4-1] ต้องใช้ Android API ที่เกี่ยวข้องตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
  • [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android จึงไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5. โปรโตคอลและ API ของเครือข่าย

7.4.5.1. ความสามารถของเครือข่ายขั้นต่ำ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับการเชื่อมต่อเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่สามารถรองรับ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, Ethernet และ Bluetooth 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 ในโหมดพัก
    • [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่รองรับ IPv6 ซึ่งใช้ช่วงเวลาที่ RA มีผลอย่างน้อย 180 วินาที
  • [C-0-6] ต้องให้การเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายแก่แอปพลิเคชันของบุคคลที่สามเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ เกิดขึ้นในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort) และ API ของ NDK เช่น getsockname() หรือ IPV6_PKTINFO จะต้องแสดงที่อยู่ IP และพอร์ตที่ใช้จริงในการส่งและรับแพ็กเก็ตในเครือข่าย และมองเห็นเป็น IP และพอร์ตต้นทางไปยังเซิร์ฟเวอร์อินเทอร์เน็ต (เว็บ)

ระดับการรองรับ IPv6 ที่จำเป็นจะขึ้นอยู่กับประเภทเครือข่าย ดังที่แสดงในข้อกำหนดต่อไปนี้

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi อุปกรณ์จะทำสิ่งต่อไปนี้ได้

  • [C-1-1] ต้องรองรับการทำงานแบบ Dual-stack และ IPv6 เท่านั้นบน Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รองรับอีเทอร์เน็ต อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องรองรับการทำงานแบบ Dual Stack และ IPv6 เท่านั้นบนอีเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์รองรับอินเทอร์เน็ตมือถือ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องรองรับการทำงานของ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ Dual-stack) บนเครือข่ายมือถือ

หากการใช้งานอุปกรณ์รองรับเครือข่ายมากกว่า 1 ประเภท (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ) จะมีลักษณะดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดข้างต้นพร้อมกันในแต่ละเครือข่ายเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 ประเภทพร้อมกัน
7.4.5.3. แคพทีฟพอร์ทัล

แคพทีฟพอร์ทัลหมายถึงเครือข่ายที่ต้องลงชื่อเข้าใช้เพื่อรับสิทธิ์เข้าถึงอินเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์มีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องมีแอปพลิเคชันแคปทีฟพอร์ทัลเพื่อจัดการ Intent ACTION_CAPTIVE_PORTAL_SIGN_IN และแสดงหน้าเข้าสู่ระบบแคปทีฟพอร์ทัลโดยการส่ง Intent นั้นเมื่อเรียกใช้ System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
  • [C-1-2] ต้องตรวจหาแคปทีฟพอร์ทัลและรองรับการเข้าสู่ระบบผ่านแอปพลิเคชันแคปทีฟพอร์ทัลเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายประเภทใดก็ตาม ซึ่งรวมถึงเครือข่ายมือถือ/เซลลูลาร์, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
  • [C-1-3] ต้องรองรับการเข้าสู่ระบบแคปทีฟพอร์ทัลโดยใช้ DNS แบบข้อความธรรมดาเมื่อกำหนดค่าอุปกรณ์ให้ใช้โหมดเข้มงวดของ DNS ส่วนตัว
  • [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสารประกอบ SDK สำหรับ android.net.LinkProperties.getPrivateDnsServerName และ android.net.LinkProperties.isPrivateDnsActive สำหรับการรับส่งข้อมูลทั้งหมดในเครือข่ายที่ไม่ได้สื่อสารกับแคปทีฟพอร์ทัลอย่างชัดเจน
  • [C-1-5] ต้องตรวจสอบว่าในขณะที่ผู้ใช้เข้าสู่ระบบแคปทีฟพอร์ทัล เครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่ส่งคืนโดย ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback และใช้โดยค่าเริ่มต้นโดย Java Networking API เช่น java.net.Socket และ API ดั้งเดิม เช่น connect()) คือเครือข่ายอื่นที่พร้อมใช้งานซึ่งให้สิทธิ์เข้าถึงอินเทอร์เน็ต หากมี

7.4.6. การตั้งค่าการซิงค์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีการตั้งค่าการซิงค์อัตโนมัติหลักเป็นเปิดโดยค่าเริ่มต้น เพื่อให้เมธอด getMasterSyncAutomatically() แสดงผลเป็น "จริง"

7.4.7. ประหยัดอินเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อแบบคิดตามปริมาณการใช้งาน จะมีลักษณะดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้ระบุโหมดประหยัดอินเทอร์เน็ต

หากการใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต จะต้องมีลักษณะดังนี้

หากการติดตั้งใช้งานอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต จะมีลักษณะดังนี้

  • [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] ต้องแสดงรายการเครื่องอ่าน Secure Element ที่พร้อมใช้งานผ่าน 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.5 กล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องประกาศandroid.hardware.camera.anyฟีเจอร์แฟล็ก
  • [C-1-2] แอปพลิเคชันต้องสามารถจัดสรรบิตแมป RGBA_8888 จำนวน 3 รายการที่มีขนาดเท่ากับรูปภาพที่เซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์สร้างขึ้นได้พร้อมกัน ขณะที่กล้องเปิดอยู่เพื่อวัตถุประสงค์ในการแสดงตัวอย่างพื้นฐานและการจับภาพนิ่ง
  • [C-1-3] ต้องตรวจสอบว่าแอปพลิเคชันกล้องเริ่มต้นที่ติดตั้งไว้ล่วงหน้าซึ่งจัดการ Intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE หรือ MediaStore.ACTION_VIDEO_CAPTURE มีหน้าที่ลบตำแหน่งของผู้ใช้ในข้อมูลเมตาของรูปภาพก่อนที่จะส่งไปยังแอปพลิเคชันที่รับเมื่อแอปพลิเคชันที่รับไม่มี ACCESS_FINE_LOCATION

7.5.1. กล้องหลัง

กล้องหลังคือกล้องที่อยู่ด้านข้างของอุปกรณ์ตรงข้ามกับจอแสดงผล ซึ่งหมายความว่ากล้องจะถ่ายภาพฉากที่อยู่ด้านไกลของอุปกรณ์ เช่น กล้องทั่วไป

การติดตั้งใช้งานอุปกรณ์

  • ควรมีกล้องหลัง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องด้านหลังอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานฟีเจอร์แฟล็ก android.hardware.camera และ android.hardware.camera.any
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย 2 เมกะพิกเซล
  • ควรมีฮาร์ดแวร์โฟกัสอัตโนมัติหรือซอฟต์แวร์โฟกัสอัตโนมัติที่ติดตั้งใช้งานในไดรเวอร์กล้อง (โปร่งใสต่อซอฟต์แวร์แอปพลิเคชัน)
  • อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
  • อาจมีแฟลช

หากกล้องมีแฟลช ให้ทำดังนี้

  • [C-2-1] ต้องไม่เปิดหลอดแฟลชขณะที่ลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback บนพื้นผิวตัวอย่างกล้อง เว้นแต่แอปพลิเคชันจะเปิดใช้แฟลชอย่างชัดเจนโดยการเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของออบเจ็กต์ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องของระบบในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้ Camera.PreviewCallback เท่านั้น

7.5.2. กล้องหน้า

กล้องด้านหน้าคือกล้องที่อยู่ด้านเดียวกับจอแสดงผลของอุปกรณ์ ซึ่งโดยปกติแล้วจะเป็นกล้องที่ใช้ถ่ายภาพผู้ใช้ เช่น สำหรับการประชุมผ่านวิดีโอและแอปพลิเคชันที่คล้ายกัน

การติดตั้งใช้งานอุปกรณ์

  • อาจมีกล้องหน้า

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องรายงานฟีเจอร์แฟล็ก android.hardware.camera.any และ android.hardware.camera.front
  • [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
  • [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเดียวในอุปกรณ์ก็ตาม
  • [C-1-4] พรีวิวของกล้องต้องสะท้อนในแนวนอนเทียบกับการวางแนวที่แอปพลิเคชันระบุเมื่อแอปพลิเคชันปัจจุบันได้ขอให้หมุนจอแสดงผลของกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน พรีวิวต้องได้รับการมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์เมื่อแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนจอแสดงผลของกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation()
  • [C-1-5] ต้องไม่กลับด้านภาพนิ่งหรือสตรีมวิดีโอที่จับภาพสุดท้ายซึ่งส่งคืนไปยังการเรียกกลับของแอปพลิเคชันหรือจัดเก็บไว้ในที่เก็บข้อมูลสื่อ
  • [C-1-6] ต้องมิเรอร์รูปภาพที่แสดงโดยการดูภายหลังในลักษณะเดียวกับสตรีมรูปภาพตัวอย่างของกล้อง
  • อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับกล้องด้านหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

หากการติดตั้งใช้งานอุปกรณ์สามารถหมุนได้โดยผู้ใช้ (เช่น โดยอัตโนมัติผ่านเครื่องวัดความเร่ง หรือด้วยตนเองผ่านอินพุตของผู้ใช้) ให้ทำดังนี้

  • [C-2-1] ภาพตัวอย่างกล้องต้องปรับให้เหมือนภาพในกระจกในแนวนอนเมื่อเทียบกับการวางแนวปัจจุบันของอุปกรณ์

7.5.3. กล้องภายนอก

การติดตั้งใช้งานอุปกรณ์

  • อาจรวมถึงการรองรับกล้องภายนอกที่ไม่จำเป็นต้องเชื่อมต่ออยู่เสมอ

หากการใช้งานอุปกรณ์รองรับกล้องภายนอก อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องประกาศค่าสถานะฟีเจอร์แพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
  • [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ตโฮสต์ USB
  • [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องโดยเชื่อมต่ออุปกรณ์กล้องภายนอกจริง ดูรายละเอียดการทดสอบ CTS ของกล้องได้ที่ source.android.com
  • ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้โอนสตรีมคุณภาพสูงที่ไม่ได้เข้ารหัสได้ (เช่น สตรีมรูปภาพแบบดิบหรือแบบบีบอัดแยกกัน)
  • อาจรองรับกล้องหลายตัว
  • อาจรองรับการเข้ารหัสวิดีโอที่อิงตามกล้อง

หากรองรับการเข้ารหัสวิดีโอที่ใช้กล้อง ให้ทำดังนี้

  • [C-2-1] การติดตั้งใช้งานอุปกรณ์ต้องเข้าถึงสตรีมที่ไม่ได้เข้ารหัส / MJPEG พร้อมกัน (ความละเอียด QVGA ขึ้นไป) ได้

7.5.4. ลักษณะการทำงานของ Camera API

Android มีแพ็กเกจ API 2 รายการสำหรับเข้าถึงกล้อง โดย API android.hardware.camera2 ที่ใหม่กว่าจะแสดงการควบคุมกล้องระดับล่างให้กับแอป ซึ่งรวมถึงโฟลว์การสตรีม/การถ่ายภาพต่อเนื่องแบบไม่มีการคัดลอกที่มีประสิทธิภาพ และการควบคุมการรับแสง เกน เกนสมดุลสีขาว การแปลงสี การลดสัญญาณรบกวน การเพิ่มความคมชัด และอื่นๆ ต่อเฟรม

แพ็กเกจ API รุ่นเก่าandroid.hardware.Cameraได้รับการทำเครื่องหมายว่าเลิกใช้งานแล้วใน Android 5.0 แต่แอปยังคงใช้งานได้ การใช้งานอุปกรณ์ Android ต้องรับประกันการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK

ฟีเจอร์ทั้งหมดที่ใช้ร่วมกันระหว่างคลาส android.hardware.Camera ที่เลิกใช้งานแล้วกับแพ็กเกจ android.hardware.camera2 ที่ใหม่กว่าจะต้องมีประสิทธิภาพและคุณภาพเทียบเท่ากันในทั้ง 2 API ตัวอย่างเช่น เมื่อใช้การตั้งค่าที่เทียบเท่า ความเร็วและความแม่นยำของโฟกัสอัตโนมัติต้องเหมือนกัน และคุณภาพของรูปภาพที่ถ่ายต้องเหมือนกัน ฟีเจอร์ที่ขึ้นอยู่กับความหมายที่แตกต่างกันของ API ทั้ง 2 รายการไม่จำเป็นต้องมีความเร็วหรือคุณภาพที่ตรงกัน แต่ควรตรงกันให้มากที่สุด

การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ API ที่เกี่ยวข้องกับกล้องสำหรับกล้องที่มีอยู่ทั้งหมด การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ระบุในการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียก android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบตัวอย่างเป็น YCbCr_420_SP ข้อมูลในไบต์[] ที่ส่งไปยัง onPreviewFrame() กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
  • [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับตัวอย่างกล้องทั้งกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (ตัวเข้ารหัสวิดีโอฮาร์ดแวร์และกล้องอาจใช้รูปแบบพิกเซลดั้งเดิมใดก็ได้ แต่การติดตั้งใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
  • [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่โฆษณาความสามารถ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities
  • [C-0-5] ต้องยังคงใช้ Camera API แบบเต็มที่รวมอยู่ในเอกสารประกอบ Android SDK ไม่ว่าอุปกรณ์จะมีฮาร์ดแวร์โฟกัสอัตโนมัติหรือความสามารถอื่นๆ หรือไม่ก็ตาม เช่น กล้องที่ไม่มีโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback ที่ลงทะเบียนไว้ (แม้ว่าอินสแตนซ์นี้จะไม่เกี่ยวข้องกับกล้องที่ไม่มีโฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการดำเนินการนี้ใช้กับกล้องหน้าด้วย ตัวอย่างเช่น แม้ว่ากล้องหน้าส่วนใหญ่จะไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับ API ก็ยังต้อง "จำลอง" ตามที่อธิบายไว้
  • [C-0-6] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters และคลาส android.hardware.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 ด้วย
  • [C-0-12] ต้องตรวจสอบว่าไม่ได้ดัดแปลงลักษณะใบหน้า ซึ่งรวมถึงแต่ไม่จำกัดเพียงการดัดแปลงรูปทรงเรขาคณิตของใบหน้า สีผิวของใบหน้า หรือการปรับผิวหน้าให้เนียนสำหรับ API android.hardware.camera2 หรือ android.hardware.Camera
  • [C-SR] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัวที่หันไปในทิศทางเดียวกัน ขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องเชิงตรรกะที่แสดงความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปในทิศทางนั้นเป็นอุปกรณ์ย่อยทางกายภาพ

หากการติดตั้งใช้งานอุปกรณ์มี API กล้องที่เป็นกรรมสิทธิ์ให้กับแอปของบุคคลที่สาม จะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องใช้ Camera API ดังกล่าวโดยใช้ android.hardware.camera2 API
  • อาจระบุแท็กผู้ให้บริการและ/หรือส่วนขยายไปยัง android.hardware.camera2 API

7.5.5. การวางแนวของกล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องวางแนวให้ด้านยาวของกล้องตรงกับด้านยาวของหน้าจอ กล่าวคือ เมื่อถืออุปกรณ์ในแนวนอน กล้องจะต้องจับภาพในแนวนอน การตั้งค่านี้จะมีผลไม่ว่าอุปกรณ์จะวางในแนวใดก็ตาม กล่าวคือ จะมีผลกับอุปกรณ์ที่วางในแนวนอนเป็นหลักและอุปกรณ์ที่วางในแนวตั้งเป็นหลัก

7.6. หน่วยความจำและพื้นที่เก็บข้อมูล

7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีตัวจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล และต้องดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้นได้

7.6.2. Shared Storage ของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่แอปพลิเคชันใช้ร่วมกันได้ ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชัน" หรือตามเส้นทาง Linux "/sdcard" ที่ติดตั้ง
  • [C-0-2] ต้องกำหนดค่าให้มีที่เก็บข้อมูลที่แชร์ซึ่งติดตั้งไว้โดยค่าเริ่มต้น กล่าวคือ "พร้อมใช้งาน" ไม่ว่าที่เก็บข้อมูลจะติดตั้งใช้งานในคอมโพเนนต์ที่เก็บข้อมูลภายในหรือสื่อที่เก็บข้อมูลแบบถอดออกได้ (เช่น ช่องเสียบการ์ด Secure Digital)
  • [C-0-3] ต้องติดตั้งที่เก็บข้อมูลที่แชร์ของแอปพลิเคชันโดยตรงในเส้นทาง Linux sdcard หรือรวมลิงก์สัญลักษณ์ Linux จาก sdcard ไปยังจุดติดตั้งจริง
  • [C-0-4] ต้องเปิดใช้พื้นที่เก็บข้อมูลที่จำกัดขอบเขตโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กำหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในกรณีต่อไปนี้
    • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
  • [C-0-5] ต้องปกปิดข้อมูลเมตาของตำแหน่ง เช่น แท็ก Exif ของ GPS ที่จัดเก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore เว้นแต่แอปที่เรียกใช้จะมีสิทธิ์ ACCESS_MEDIA_LOCATION

การใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้อย่างใดอย่างหนึ่งต่อไปนี้

  • ที่เก็บข้อมูลแบบถอดได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
  • พื้นที่เก็บข้อมูลภายใน (ถอดออกไม่ได้) บางส่วนตามที่ใช้ในโครงการโอเพนซอร์ส Android (AOSP)

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดได้เพื่อให้เป็นไปตามข้อกำหนดข้างต้น อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้คำเตือนแบบข้อความป๊อปอัปหรืออินเทอร์เฟซผู้ใช้แบบป๊อปอัปเพื่อเตือนผู้ใช้เมื่อไม่มีสื่อบันทึกข้อมูลเสียบอยู่ในช่อง
  • [C-1-2] ต้องมีสื่อบันทึกข้อมูลที่ฟอร์แมตเป็น FAT (เช่น การ์ด SD) หรือแสดงบนกล่องและสื่ออื่นๆ ที่มีในขณะที่ซื้อว่าต้องซื้อสื่อบันทึกข้อมูลแยกต่างหาก

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดไม่ได้บางส่วนเพื่อให้เป็นไปตามข้อกำหนดข้างต้น อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • ควรใช้การติดตั้งใช้งาน AOSP ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายใน
  • อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องมีกลไกในการเข้าถึงข้อมูลในที่เก็บข้อมูลที่แชร์ของแอปพลิเคชันจากคอมพิวเตอร์โฮสต์
  • ควรแสดงเนื้อหาจากทั้ง 2 เส้นทางการจัดเก็บอย่างโปร่งใสผ่านบริการ Media Scanner ของ Android และ android.provider.MediaStore
  • อาจใช้ที่เก็บข้อมูลแบบกลุ่มผ่าน USB แต่ควรใช้โปรโตคอลการโอนสื่อเพื่อให้เป็นไปตามข้อกำหนดนี้

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่มีโหมดอุปกรณ์ต่อพ่วง USB และรองรับโปรโตคอลการโอนสื่อ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • ควรใช้ร่วมกับโฮสต์ MTP ของ Android อ้างอิง ซึ่งก็คือ Android File Transfer
  • ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
  • ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable

หากคาดว่าอุปกรณ์จะเคลื่อนที่ได้เหมือนโทรศัพท์มือถือ ไม่เหมือนโทรทัศน์ การติดตั้งใช้งานอุปกรณ์จะเป็นดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานที่เก็บข้อมูลที่ปรับใช้ได้ในตำแหน่งที่เสถียรในระยะยาว เนื่องจากหากถอดการเชื่อมต่อโดยไม่ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย

หากพอร์ตอุปกรณ์เก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่เสถียรในระยะยาว เช่น ภายในช่องใส่แบตเตอรี่หรือฝาครอบป้องกันอื่นๆ การติดตั้งใช้งานอุปกรณ์จะเป็นดังนี้

7.7. USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรจะรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรจะรองรับโหมดโฮสต์ USB

7.7.1. โหมดอุปกรณ์ต่อพ่วง USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง ให้ทำดังนี้

  • [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB มาตรฐานประเภท A หรือประเภท C ได้
  • [C-1-2] ต้องรายงานค่าที่ถูกต้องของ iSerialNumber ในตัวอธิบายอุปกรณ์มาตรฐาน USB ผ่าน android.os.Build.SERIAL
  • [C-1-3] ต้องตรวจจับเครื่องชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจจับการเปลี่ยนแปลงในโฆษณาหากรองรับ USB Type-C
  • [SR] พอร์ตควรใช้รูปแบบ USB แบบ Micro-B, Micro-AB หรือ Type-C ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
  • [SR] พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวปกติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้จอแสดงผลวาดได้อย่างถูกต้องเมื่อวางแนวอุปกรณ์โดยให้พอร์ตอยู่ด้านล่าง ขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่ให้เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
  • [SR] ควรใช้การรองรับเพื่อดึงกระแสไฟ 1.5 A ระหว่างการส่งเสียงร้อง HS และการรับส่งข้อมูลตามที่ระบุไว้ในข้อกำหนดการชาร์จแบตเตอรี่ USB ฉบับแก้ไข 1.2 ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
  • [SR] ขอแนะนำอย่างยิ่งว่าไม่ควรสนับสนุนวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus ให้เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของ Sink/Source เนื่องจากอาจทำให้เกิดปัญหาในการทำงานร่วมกันกับเครื่องชาร์จหรืออุปกรณ์ที่รองรับวิธีการ USB Power Delivery มาตรฐาน แม้ว่าเราจะระบุว่า "แนะนำอย่างยิ่ง" แต่ใน Android เวอร์ชันในอนาคต เราอาจกำหนดให้อุปกรณ์ Type-C ทั้งหมดรองรับการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C มาตรฐาน
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับการจ่ายไฟเพื่อสลับบทบาทของข้อมูลและพลังงานเมื่ออุปกรณ์รองรับ USB Type-C และโหมดโฮสต์ USB
  • ควรรองรับ Power Delivery สำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่น เช่น การแสดงผล
  • ควรใช้ Android Open Accessory (AOA) API และข้อกำหนดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

หากการใช้งานอุปกรณ์มีพอร์ต USB และใช้ข้อกำหนด AOA อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

  • [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
  • [C-2-2] คลาสที่เก็บข้อมูลจำนวนมากของ USB ต้องมีสตริง "android" ที่ท้ายสตริงคำอธิบายอินเทอร์เฟซ iInterface ของที่เก็บข้อมูลจำนวนมากของ USB

7.7.2. โหมดโฮสต์ USB

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
  • [C-1-2] ต้องรองรับการเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ ต้องมีลักษณะใดลักษณะหนึ่งต่อไปนี้
    • มีพอร์ต Type C ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์เป็นพอร์ต USB Type-C มาตรฐาน (อุปกรณ์ USB Type-C)
    • มีพอร์ต Type A ในตัวเครื่องหรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในตัวเครื่องเป็นพอร์ต USB Type-A มาตรฐาน
    • มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรมาพร้อมกับสายที่แปลงเป็นพอร์ต Type-A มาตรฐาน
  • [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB ประเภท A หรือ micro-AB เป็นพอร์ตประเภท C (เต้ารับ)
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
  • ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะอยู่ในโหมดโฮสต์ โดยประกาศกระแสไฟต้นทางอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสไฟขาออกของพอร์ตดาวน์สตรีมสำหรับการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะของการชาร์จแบตเตอรี่ USB ฉบับแก้ไข 1.2 สำหรับขั้วต่อ Micro-AB
  • ควรติดตั้งใช้งานและรองรับมาตรฐาน USB Type-C

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และคลาสเสียง USB อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องรองรับคลาส USB HID
  • [C-2-2] ต้องรองรับการตรวจหาและการแมปฟิลด์ข้อมูล HID ต่อไปนี้ที่ระบุไว้ในตารางการใช้งาน USB HID และคำขอการใช้งานคำสั่งเสียงกับค่าคงที่ KeyEvent ดังนี้
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0E9): KEYCODE_VOLUME_UP
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0EA): KEYCODE_VOLUME_DOWN
    • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CF): KEYCODE_VOICE_ASSIST

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF) อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-3-1] ต้องรู้จักอุปกรณ์ MTP (Media Transfer Protocol) ที่เชื่อมต่อจากระยะไกลและทำให้เข้าถึงเนื้อหาของอุปกรณ์ได้ผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT .

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-4-1] ต้องใช้ฟังก์ชันพอร์ตแบบ Dual Role ตามที่กำหนดโดยข้อกำหนด USB Type-C (ส่วน 4.5.1.3.3)
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort, ควรจะรองรับอัตราการรับส่งข้อมูล USB SuperSpeed และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทด้านข้อมูลและพลังงาน
  • [SR] ขอแนะนำอย่างยิ่งว่าไม่ควรสนับสนุนโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก ก ของข้อกำหนดของสายและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2
  • ควรใช้รูปแบบ Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบอุปกรณ์ เช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK

7.8. เสียง

7.8.1. ไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีไมโครโฟน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-1-2] ต้องเป็นไปตามข้อกำหนดในการบันทึกเสียงในส่วนที่ 5.4
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงที่เกือบจะเป็นอัลตราซาวด์ตามที่อธิบายไว้ในส่วน 7.8.3

หากการใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์ดังกล่าวจะ

  • [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
  • [C-2-2] ต้องใช้การบันทึกเสียง API อย่างน้อยเป็นแบบไม่มีการดำเนินการ ตามส่วนที่ 7

7.8.2. เอาต์พุตเสียง

หากการใช้งานอุปกรณ์มีลำโพงหรือพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น แจ็กเสียง 3.5 มม. แบบ 4 คอนดักเตอร์หรือพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

  • [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
  • [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
  • [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
  • [SR] ขอแนะนำอย่างยิ่งให้รองรับการเล่นเสียงที่เกือบจะเป็นอัลตราซาวด์ตามที่อธิบายไว้ในส่วน 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีลำโพงหรือพอร์ตเอาต์พุตเสียง อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องไม่รายงานฟีเจอร์ android.hardware.audio.output
  • [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นฟังก์ชันที่ไม่มีการดำเนินการอย่างน้อย

สำหรับวัตถุประสงค์ของส่วนนี้ "พอร์ตเอาต์พุต" คืออินเทอร์เฟซจริง เช่น ช่องเสียบเสียง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลที่ใช้คลื่นวิทยุ เช่น บลูทูธ, Wi-Fi หรือเครือข่ายมือถือ ไม่ถือว่าเป็นการรวม "พอร์ตเอาต์พุต"

7.8.2.1. พอร์ตเสียงแอนะล็อก

หากต้องการให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมสำหรับเสียงอื่นๆ ที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศ Android ได้ หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-SR] ขอแนะนำอย่างยิ่งให้มีพอร์ตเสียงอย่างน้อย 1 พอร์ตเป็นแจ็คเสียง 3.5 มม. แบบ 4 คอนดักเตอร์

หากการติดตั้งใช้งานอุปกรณ์มีแจ็คเสียง 3.5 มม. แบบ 4 คอนดักเตอร์ อุปกรณ์จะ

  • [C-1-1] ต้องรองรับการเล่นเสียงไปยังหูฟังสเตอริโอและชุดหูฟังสเตอริโอที่มีไมโครโฟน
  • [C-1-2] ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับการต่อพิน CTIA
  • [C-1-3] ต้องรองรับการตรวจจับและการแมปกับรหัสคีย์สำหรับช่วงความต้านทานเทียบเท่า 3 ช่วงต่อไปนี้ระหว่างไมโครโฟนกับตัวนำกราวด์บนปลั๊กเสียง
    • 70 โอห์มหรือน้อยกว่า: KEYCODE_HEADSETHOOK
    • 210-290 โอห์ม: KEYCODE_VOLUME_UP
    • 360-680 โอห์ม: KEYCODE_VOLUME_DOWN
  • [C-1-4] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่หลังจากที่ขั้วต่อทั้งหมดบนปลั๊กสัมผัสกับส่วนที่เกี่ยวข้องบนแจ็คแล้วเท่านั้น
  • [C-1-5] ต้องสามารถขับแรงดันไฟฟ้าเอาต์พุตอย่างน้อย 150mV ± 10% บนอิมพีแดนซ์ของลำโพง 32 โอห์ม
  • [C-1-6] ต้องมีแรงดันไฟฟ้าไบแอสของไมโครโฟนระหว่าง 1.8V ~ 2.9V
  • [C-1-7] ต้องตรวจหาและแมปกับรหัสแป้นสำหรับช่วงความต้านทานสมมูลต่อไปนี้ระหว่างตัวนำไมโครโฟนกับตัวนำกราวด์บนปลั๊กเสียง
    • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการต่อพิน OMTP
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอที่มีไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีแจ็กเสียง 3.5 มม. แบบ 4 คอนดักเตอร์และรองรับไมโครโฟน รวมถึงออกอากาศ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนที่มีค่าพิเศษเป็น 1 อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องรองรับการตรวจหาไมโครโฟนในอุปกรณ์เสริมสำหรับเสียงที่เสียบอยู่
7.8.2.2. พอร์ตเสียงดิจิทัล

เพื่อให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมสำหรับเสียงอื่นๆ ที่ใช้ขั้วต่อ USB-C และใช้ (USB audio class) ในระบบนิเวศ Android ตามที่กำหนดไว้ในข้อกำหนดเฉพาะของชุดหูฟัง USB สำหรับ Android

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 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 ต้องไม่ต่ำกว่าการตอบสนองที่ 2 kHz เกิน 15 dB
  • [C-1-2] อัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ไม่มีการถ่วงน้ำหนักของไมโครโฟนในช่วง 18.5 kHz ถึง 20 kHz สำหรับโทนเสียง 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง"

  • [C-2-1] การตอบสนองเฉลี่ยของลำโพงที่ 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB ต่ำกว่าการตอบสนองที่ 2 kHz

7.8.4. ความสมบูรณ์ของสัญญาณ

การใช้งานอุปกรณ์: * ควรมีเส้นทางสัญญาณเสียงที่ไม่มีข้อบกพร่องสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์พกพา ตามที่กำหนดโดยไม่มีข้อบกพร่องที่วัดได้ในระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "การทดสอบข้อบกพร่องอัตโนมัติ"

การทดสอบต้องใช้ดองเกิลเสียงลูปแบ็กที่ใช้ในแจ็ก 3.5 มม. โดยตรง และ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

ปัจจุบัน OboeTester รองรับเส้นทาง AAudio ดังนั้นควรทดสอบชุดค่าผสมต่อไปนี้เพื่อหาข้อบกพร่องโดยใช้ AAudio

โหมด Perf การแชร์ อัตราการสุ่มตัวอย่างเอาต์พุต ในช่อง ช่องที่ถูกบล็อก
LOW_LATENCY พิเศษ ไม่ได้ระบุ 1 2
LOW_LATENCY พิเศษ ไม่ได้ระบุ 2 1
LOW_LATENCY แชร์ ไม่ได้ระบุ 1 2
LOW_LATENCY แชร์ ไม่ได้ระบุ 2 1
ไม่มี แชร์ 48000 1 2
ไม่มี แชร์ 48000 2 1
ไม่มี แชร์ 44100 1 2
ไม่มี แชร์ 44100 2 1
ไม่มี แชร์ 16000 1 2
ไม่มี แชร์ 16000 2 1

สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) และความเพี้ยนฮาร์มอนิกทั้งหมด (THD) สำหรับไซน์ 2000 Hz

ทรานสดิวเซอร์ THD SNR
ลำโพงหลักในตัวเครื่อง ซึ่งวัดโดยใช้ไมโครโฟนอ้างอิงภายนอก < 3.0% >= 50 dB
ไมโครโฟนหลักในตัว ซึ่งวัดโดยใช้ลำโพงอ้างอิงภายนอก < 3.0% >= 50 dB
แจ็คแอนะล็อก 3.5 มม. ในตัว ซึ่งทดสอบโดยใช้อะแดปเตอร์ลูปแบ็ก < 1% >= 60 dB
อะแดปเตอร์ USB ที่มาพร้อมกับโทรศัพท์ ทดสอบโดยใช้อะแดปเตอร์ลูปแบ็ก < 1.0% >= 60 dB

7.9. Virtual Reality

Android มี API และเครื่องมือในการสร้างแอปพลิเคชัน "Virtual Reality" (VR) ซึ่งรวมถึงประสบการณ์ VR บนอุปกรณ์เคลื่อนที่คุณภาพสูง การใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

7.9.1. โหมด Virtual Reality

Android รองรับโหมด VR ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลแบบสเตอริโอของการแจ้งเตือนและปิดใช้คอมโพเนนต์ UI ของระบบแบบตาเดียวในขณะที่แอปพลิเคชัน VR ได้รับโฟกัสจากผู้ใช้

7.9.2. โหมด Virtual Reality - ประสิทธิภาพสูง

หากการใช้งานอุปกรณ์รองรับโหมด VR อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องมี Physical Core อย่างน้อย 2 คอร์
  • [C-1-2] ต้องประกาศฟีเจอร์ android.hardware.vr.high_performance
  • [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
  • [C-1-4] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.2
  • [C-1-5] ต้องรองรับ android.hardware.vulkan.level 0
  • ควรสนับสนุน android.hardware.vulkan.level 1 ขึ้นไป
  • [C-1-6] ต้องใช้ EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่พร้อมใช้งาน
  • [C-1-8] ต้องใช้ GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image และแสดงในรายการส่วนขยาย Vulkan ที่พร้อมใช้งาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้แสดงคิวตระกูล Vulkan อย่างน้อย 1 รายการที่ flags มีทั้ง VK_QUEUE_GRAPHICS_BIT และ VK_QUEUE_COMPUTE_BIT และ queueCount มีค่าอย่างน้อย 2
  • [C-1-7] GPU และจอแสดงผลต้องซิงค์การเข้าถึงบัฟเฟอร์หน้าส่วนกลางได้เพื่อให้การแสดงผลเนื้อหา VR แบบสลับตาที่ 60fps ด้วยบริบทการแสดงผล 2 รายการแสดงโดยไม่มีอาร์ติแฟกต์การฉีกขาดที่มองเห็นได้
  • [C-1-9] ต้องรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
  • [C-1-10] ต้องรองรับ AHardwareBuffer โดยใช้ชุดค่าผสมใดก็ได้ของแฟล็กการใช้งาน AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT สำหรับรูปแบบต่อไปนี้อย่างน้อย AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีเลเยอร์มากกว่า 1 เลเยอร์ รวมถึงการตั้งค่าสถานะและรูปแบบที่ระบุไว้ใน C-1-10
  • [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30fps โดยบีบอัดให้มีค่าเฉลี่ย 40Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 fps-10 Mbps หรือ 2 อินสแตนซ์ของ 1920 x 1080 ที่ 60 fps-20 Mbps)
  • [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องถอดรหัสอย่างน้อย 1920 x 1080 ที่ 30 FPS ที่บีบอัดเป็นค่าเฉลี่ย 10 Mbps ได้ และควรถอดรหัส 3840 x 2160 ที่ 30 FPS-20 Mbps ได้ (เทียบเท่ากับ 1920 x 1080 ที่ 30 FPS-5 Mbps จำนวน 4 รายการ)
  • [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
  • [C-1-14] ต้องมีหน้าจอฝังตัว และความละเอียดต้องเป็นอย่างน้อย 1920 x 1080
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีความละเอียดในการแสดงผลอย่างน้อย 2560 x 1440
  • [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
  • [C-1-17] จอแสดงผลต้องรองรับโหมดความคงทนต่ำที่มีความคงทน ≤ 5 มิลลิวินาที โดยความคงทนจะกำหนดเป็นระยะเวลาที่พิกเซลเปล่งแสง
  • [C-1-18] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวข้อมูลของบลูทูธ LE มาตรา 7.4.3
  • [C-1-19] ต้องรองรับและรายงานประเภทแชแนลโดยตรงอย่างถูกต้องสำหรับเซ็นเซอร์เริ่มต้นทุกประเภทต่อไปนี้
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับประเภทช่องทางโดยตรง TYPE_HARDWARE_BUFFER สำหรับประเภทช่องทางโดยตรงทั้งหมดที่ระบุไว้ข้างต้น
  • [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors ตามที่ระบุไว้ในส่วนที่ 7.3.9
  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับandroid.hardware.sensor.hifi_sensors
  • [C-1-22] ต้องมีเวลาในการตอบสนองตั้งแต่การเคลื่อนไหวจนถึงการแสดงผลภาพไม่เกิน 28 มิลลิวินาที
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองตั้งแต่การเคลื่อนไหวจนถึงโฟตอนแบบต้นทางถึงปลายทางไม่เกิน 20 มิลลิวินาที
  • [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวกับความสว่างของพิกเซลสีขาวในสถานะคงที่ อย่างน้อย 85%
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
  • อาจจัดสรรคอร์หลักเฉพาะให้กับแอปพลิเคชันที่ใช้งานอยู่ และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนคอร์ CPU ที่จัดสรรเฉพาะให้กับแอปพลิเคชันที่ใช้งานอยู่ด้านบนสุด

หากรองรับคอร์แบบเฉพาะ คอร์จะมีลักษณะดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้กระบวนการในพื้นที่ผู้ใช้ใดๆ อื่นทํางานบนนั้น (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่สามารถอนุญาตให้กระบวนการเคอร์เนลบางอย่างทํางานได้ตามความจําเป็น

7.10. การโต้ตอบการสัมผัส

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.1

7.11. คลาสประสิทธิภาพสื่อ

คุณดูคลาสประสิทธิภาพสื่อของการติดตั้งใช้งานอุปกรณ์ได้จาก android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API ข้อกำหนด สำหรับคลาสประสิทธิภาพของสื่อจะกำหนดไว้สำหรับ Android แต่ละเวอร์ชันโดยเริ่มจาก R (เวอร์ชัน 30) ค่าพิเศษ 0 หมายความว่าอุปกรณ์ไม่ได้อยู่ใน คลาสประสิทธิภาพสื่อ

หากการใช้งานอุปกรณ์แสดงค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะมีลักษณะดังนี้

  • [C-1-1] ต้องแสดงผลค่าอย่างน้อย android.os.Build.VERSION_CODES.R

  • [C-1-2] ต้องเป็นการติดตั้งใช้งานอุปกรณ์พกพา

  • [C-1-3] ต้องมีคุณสมบัติตรงตามข้อกำหนดทั้งหมดสำหรับ "คลาสประสิทธิภาพของสื่อ" ที่อธิบายไว้ ในส่วน 2.2.7

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.7

8. ประสิทธิภาพและพลังงาน

เกณฑ์ด้านประสิทธิภาพและกำลังขั้นต่ำบางอย่างมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป

8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้

คุณสามารถมอบอินเทอร์เฟซผู้ใช้ที่ราบรื่นให้กับผู้ใช้ปลายทางได้หากมีข้อกำหนดขั้นต่ำบางอย่างเพื่อให้มั่นใจว่าแอปพลิเคชันและเกมจะมีอัตราเฟรมและเวลาตอบสนองที่สอดคล้องกัน การติดตั้งใช้งานอุปกรณ์อาจมีข้อกำหนดที่วัดได้สำหรับเวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้และการสลับงานตามที่อธิบายไว้ในส่วนที่ 2 ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์

8.2 ประสิทธิภาพการเข้าถึง I/O ของไฟล์

การกำหนดเกณฑ์พื้นฐานทั่วไปสำหรับประสิทธิภาพการเข้าถึงไฟล์ที่สอดคล้องกันในที่เก็บข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) ช่วยให้นักพัฒนาแอปสามารถตั้งค่าความคาดหวังที่เหมาะสมซึ่งจะช่วยในการออกแบบซอฟต์แวร์ การใช้งานอุปกรณ์อาจมีข้อกำหนดบางอย่างที่อธิบายไว้ในส่วนที่ 2 สำหรับการอ่านและการเขียนต่อไปนี้ ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์

  • ประสิทธิภาพการเขียนตามลำดับ วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการเขียนแบบสุ่ม วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
  • ประสิทธิภาพการอ่านตามลำดับ วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
  • ประสิทธิภาพการอ่านแบบสุ่ม วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB

8.3 โหมดประหยัดพลังงาน

หากการใช้งานอุปกรณ์มีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP (เช่น กลุ่มพักแอป, โหมดพักเครื่อง) หรือขยายฟีเจอร์ที่ไม่ได้ใช้ข้อจำกัดที่เข้มงวดกว่ากลุ่มพักแอปที่ใช้ไม่บ่อย จะมีลักษณะดังนี้

  • [C-1-1] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับอัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุก และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน App Standby และโหมดพัก
  • [C-1-2] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการจำกัดงาน การปลุก และเครือข่ายสำหรับแอปในแต่ละ Bucket สำหรับ App Standby
  • [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวนกลุ่มการพักแอปที่ใช้สำหรับการพักแอป
  • [C-1-4] ต้องใช้ที่เก็บพักแอปและโหมดพักเครื่องตามที่อธิบายไว้ในการจัดการพลังงาน
  • [C-1-5] ต้องส่งคืน true สำหรับ PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายของแอปและโหมดประหยัดพลังงาน Doze

หากการใช้งานอุปกรณ์ขยายฟีเจอร์การจัดการพลังงานที่รวมอยู่ใน AOSP และส่วนขยายนั้นใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลการพักแอปที่ใช้ไม่บ่อย โปรดดูส่วนที่ 3.5.1

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การติดตั้งใช้งานอุปกรณ์ Android อาจใช้สถานะพลังงานขณะพัก 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)

หากการใช้งานอุปกรณ์ใช้สถานะเปิด/ปิด S4 ตามที่กำหนดโดย ACPI จะมีลักษณะดังนี้

  • [C-1-1] ต้องเข้าสู่สถานะนี้หลังจากที่ผู้ใช้ดำเนินการอย่างชัดเจนเพื่อให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งานเท่านั้น (เช่น ปิดฝาซึ่งเป็นส่วนหนึ่งของอุปกรณ์ หรือปิดรถหรือโทรทัศน์) และก่อนที่ผู้ใช้จะเปิดใช้งานอุปกรณ์อีกครั้ง (เช่น เปิดฝา หรือเปิดรถหรือโทรทัศน์อีกครั้ง)

หากการใช้งานอุปกรณ์ใช้สถานะเปิด/ปิด S3 ตามที่กำหนดโดย ACPI จะมีลักษณะดังนี้

  • [C-2-1] ต้องเป็นไปตาม C-1-1 ด้านบน หรือต้องเข้าสู่สถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่ต้องการทรัพยากรของระบบ (เช่น หน้าจอ, CPU)

    ในทางกลับกัน จะต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรของระบบ ตามที่อธิบายไว้ใน SDK นี้

    ตัวอย่างเช่น ขณะที่แอปพลิเคชันของบุคคลที่สามขอให้เปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือให้ CPU ทำงานต่อไปผ่าน PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่เข้าสู่สถานะ S3 เว้นแต่ว่าผู้ใช้ได้ดำเนินการอย่างชัดเจนเพื่อให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน เมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามใช้ผ่าน JobScheduler หรือเมื่อมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ผู้ใช้จะทำให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน นี่เป็นเพียงตัวอย่างโดยสังเขปเท่านั้น และ AOSP ใช้สัญญาณปลุกที่ครอบคลุมซึ่งทริกเกอร์การปลุกจากสถานะนี้

8.4. การบัญชีการใช้พลังงาน

การบัญชีและการรายงานการใช้พลังงานที่แม่นยำยิ่งขึ้นจะช่วยให้นักพัฒนาแอปได้รับทั้งสิ่งจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

  • [SR] ขอแนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้กระแสไฟฟ้าสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการระบายแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์ Android Open Source Project
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ชั่วโมง (mAh)
  • [SR] ขอแนะนำอย่างยิ่งให้รายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านuid_cputimeการติดตั้งใช้งานโมดูลเคอร์เนล
  • [SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การใช้พลังงานนี้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats แก่นักพัฒนาแอป
  • ควรระบุแหล่งที่มาของคอมโพเนนต์ฮาร์ดแวร์เองหากระบุแหล่งที่มาของการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชันไม่ได้

8.5 ประสิทธิภาพที่สม่ำเสมอ

ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่มีประสิทธิภาพสูงและทำงานเป็นเวลานาน ไม่ว่าจะเป็นเพราะแอปอื่นๆ ที่ทำงานในเบื้องหลังหรือการควบคุมปริมาณ CPU เนื่องจากขีดจำกัดด้านอุณหภูมิ Android มีอินเทอร์เฟซแบบเป็นโปรแกรมเพื่อให้แอปพลิเคชันที่อยู่ด้านบนสุดในเบื้องหน้าสามารถขอให้ระบบเพิ่มประสิทธิภาพการจัดสรรทรัพยากรเพื่อรับมือกับความผันผวนดังกล่าวได้เมื่ออุปกรณ์พร้อม

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด API ของ PowerManager.isSustainedPerformanceModeSupported()

  • ควรสนับสนุนโหมดประสิทธิภาพที่ยั่งยืน

หากการติดตั้งใช้งานอุปกรณ์รายงานว่ารองรับโหมดประสิทธิภาพที่ยั่งยืน อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องให้แอปพลิเคชันที่อยู่เบื้องหน้าสูงสุดมีระดับประสิทธิภาพที่สม่ำเสมอเป็นเวลาอย่างน้อย 30 นาที เมื่อแอปขอ
  • [C-1-2] ต้องปฏิบัติตาม API ของ Window.setSustainedPerformanceMode() และ API อื่นๆ ที่เกี่ยวข้อง

หากการติดตั้งใช้งานอุปกรณ์มีคอร์ CPU 2 คอร์ขึ้นไป อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • ควรมีคอร์หลักแบบพิเศษอย่างน้อย 1 คอร์ที่แอปพลิเคชันที่อยู่ด้านหน้าสุดสามารถจองได้

หากการใช้งานอุปกรณ์รองรับการจองคอร์แบบพิเศษ 1 คอร์สำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าสูงสุด อุปกรณ์จะดำเนินการต่อไปนี้

  • [C-2-1] ต้องรายงานผ่านวิธีการ API ของ Process.getExclusiveCores() หมายเลขรหัสของคอร์แบบพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนสามารถจองได้
  • [C-2-2] ต้องไม่อนุญาตให้กระบวนการในพื้นที่ผู้ใช้ใดๆ ทำงาน ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อเรียกใช้ในคอร์แบบเฉพาะ แต่สามารถอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานได้ตามความจำเป็น

หากการใช้งานอุปกรณ์ไม่รองรับคอร์แบบเฉพาะ จะเกิดกรณีต่อไปนี้

9. ความเข้ากันได้ของโมเดลความปลอดภัย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องใช้โมเดลความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารประกอบสำหรับนักพัฒนาแอป Android

  • [C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงานใดๆ โดยเฉพาะอย่างยิ่ง อุปกรณ์ที่รองรับต้องรองรับกลไกการรักษาความปลอดภัยที่อธิบายไว้ในส่วนย่อยต่อไปนี้

9.1. สิทธิ์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับรูปแบบสิทธิ์ของ Android ตามที่กำหนดไว้ในเอกสารประกอบสำหรับนักพัฒนาแอป Android โดยเฉพาะอย่างยิ่ง แอปต้องบังคับใช้สิทธิ์แต่ละรายการที่กำหนดไว้ตามที่อธิบายไว้ในเอกสารประกอบของ SDK โดยจะละเว้น เปลี่ยนแปลง หรือเพิกเฉยต่อสิทธิ์ใดๆ ไม่ได้

  • อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

  • [C-0-2] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_FLAG_PRIVILEGED ต้องให้เฉพาะแอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบและภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอปเท่านั้น การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและให้สิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่ได้รับสิทธิ์

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะขอสิทธิ์รันไทม์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ และต้องมีอินเทอร์เฟซเพื่อให้ผู้ใช้จัดการสิทธิ์รันไทม์ได้
  • [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงแบบเดียวเท่านั้น
  • [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งไว้ล่วงหน้า เว้นแต่ในกรณีต่อไปนี้
    • คุณขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้ข้อมูล
    • สิทธิ์รันไทม์จะเชื่อมโยงกับรูปแบบ Intent ที่ตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
  • [C-0-6] ต้องให้android.permission.RECOVER_KEYSTOREเฉพาะแอปของระบบที่ลงทะเบียน Recovery Agent ที่ปลอดภัยอย่างเหมาะสม ตัวแทนการกู้คืนที่ปลอดภัยอย่างเหมาะสมคือตัวแทนซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยพร้อมการป้องกันที่เทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีแบบ Brute Force ในปัจจัยความรู้ของหน้าจอล็อก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องปฏิบัติตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งใน Android เมื่อแอปขอข้อมูลตำแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้

    • ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด)
    • ข้อมูลที่ใช้ระบุหรือประมาณตำแหน่งของอุปกรณ์ได้ (เช่น SSID, BSSID, รหัสเซลล์ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
    • กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจัดประเภทกิจกรรมการเคลื่อนไหวร่างกาย

กล่าวโดยละเอียดคือการใช้งานอุปกรณ์

  • [C-0-8] ต้องได้รับความยินยอมจากผู้ใช้เพื่ออนุญาตให้แอปเข้าถึง ข้อมูลตำแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
  • [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มี สิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น เช่น TelephonyManager#getServiceState ต้องใช้ android.permission.ACCESS_FINE_LOCATION

คุณสามารถทําเครื่องหมายสิทธิ์เป็นแบบจํากัดเพื่อเปลี่ยนลักษณะการทํางานของสิทธิ์ได้

  • [C-0-10] ต้องไม่ให้สิทธิ์ที่ทำเครื่องหมายด้วยธง hardRestricted แก่แอป เว้นแต่ในกรณีต่อไปนี้

    • ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
    • ผู้ใช้กำหนดบทบาทที่เชื่อมโยงกับhardRestrictedสิทธิ์ให้กับแอป
    • โปรแกรมติดตั้งจะให้สิทธิ์ hardRestricted แก่แอป
    • แอปได้รับhardRestrictedใน Android เวอร์ชันก่อนหน้า

  • [C-0-11] แอปที่มีสิทธิ์ softRestricted ต้องได้รับสิทธิ์เข้าถึงแบบจำกัดเท่านั้น และต้องไม่ได้รับสิทธิ์เข้าถึงแบบเต็มจนกว่าจะได้รับอนุญาตตามที่อธิบายไว้ใน SDK ซึ่งมีการกำหนดสิทธิ์เข้าถึงแบบเต็มและแบบจำกัดสำหรับสิทธิ์ softRestricted แต่ละรายการ (เช่น READ_EXTERNAL_STORAGE)

หากการติดตั้งใช้งานอุปกรณ์มีตัวเลือกให้ผู้ใช้เลือกแอปที่สามารถวาดทับแอปอื่นๆ ด้วยกิจกรรมที่จัดการ Intent ACTION_MANAGE_OVERLAY_PERMISSION จะมีข้อกำหนดดังนี้

  • [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง Intent สำหรับ Intent ACTION_MANAGE_OVERLAY_PERMISSION มีหน้าจอ UI เดียวกัน ไม่ว่าแอปที่เริ่มต้นหรือข้อมูลใดๆ ที่แอปนั้นระบุจะเป็นอย่างไรก็ตาม

9.2. UID และการแยกกระบวนการ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรองรับโมเดลแซนด์บ็อกซ์แอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID รูปแบบ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกกัน
  • [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็นรหัสผู้ใช้ Linux เดียวกัน โดยแอปพลิเคชันจะต้องได้รับการลงนามและสร้างอย่างถูกต้องตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3 สิทธิ์ของระบบไฟล์

การติดตั้งใช้งานอุปกรณ์

9.4 สภาพแวดล้อมการดำเนินการอื่น

การติดตั้งใช้งานอุปกรณ์ต้องรักษาความสอดคล้องของโมเดลความปลอดภัยและสิทธิ์ของ Android แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นๆ นอกเหนือจากรูปแบบที่เรียกใช้งานได้ของ Dalvik หรือโค้ดแบบเนทีฟก็ตาม กล่าวคือ

  • [C-0-1] รันไทม์สำรองต้องเป็นแอปพลิเคชัน Android และต้องปฏิบัติตามรูปแบบความปลอดภัยมาตรฐานของ Android ตามที่อธิบายไว้ในส่วนที่ 9

  • [C-0-2] ต้องไม่อนุญาตให้รันไทม์สำรองเข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

  • [C-0-3] รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ฟีเจอร์ที่ได้รับการปกป้องโดยสิทธิ์ของ Android ซึ่งจำกัดไว้สำหรับแอปพลิเคชันระบบ

  • [C-0-4] รันไทม์สำรองต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์สำรองต้องไม่นำแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่านกลไกมาตรฐานของ Android สำหรับรหัสผู้ใช้ที่แชร์และใบรับรองการลงนาม

  • [C-0-5] รันไทม์สำรองต้องไม่เปิดตัวพร้อมกับ ไม่ให้สิทธิ์ หรือไม่ได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่สอดคล้องกับแอปพลิเคชัน Android อื่นๆ

  • [C-0-6] รันไทม์สำรองต้องไม่เปิดตัว ไม่ได้รับ หรือไม่ให้สิทธิ์ใดๆ ของผู้ใช้ขั้นสูง (รูท) หรือรหัสผู้ใช้อื่นๆ แก่แอปพลิเคชันอื่น

  • [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์สำรองไว้ในอิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ จะต้องลงนามด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงนามแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์

  • [C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์สำรองต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ Android ที่แอปพลิเคชันใช้

  • [C-0-9] เมื่อแอปพลิเคชันต้องการใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรดังกล่าวได้

  • [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่ได้บันทึกความสามารถของแอปพลิเคชันในลักษณะนี้ สภาพแวดล้อมรันไทม์จะต้องแสดงรายการสิทธิ์ทั้งหมดที่รันไทม์ถือครองอยู่เมื่อติดตั้งแอปพลิเคชันใดก็ตามที่ใช้รันไทม์นั้น

  • รันไทม์สำรองควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

  • รันไทม์สำรองอาจมีแซนด์บ็อกซ์ Android เดียวที่แอปพลิเคชันทั้งหมดใช้รันไทม์สำรองใช้ร่วมกัน

9.5 การรองรับผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ

  • การใช้งานอุปกรณ์อาจแต่ไม่ควรเปิดใช้แบบหลายผู้ใช้หากใช้สื่อแบบถอดได้สำหรับพื้นที่เก็บข้อมูลภายนอกหลัก

หากการใช้งานอุปกรณ์มีผู้ใช้หลายคน จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน
  • [C-1-2] ต้องใช้โมเดลความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API สำหรับผู้ใช้แต่ละราย
  • [C-1-3] ต้องมีไดเรกทอรีที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกันแยกต่างหากและแยกกัน (หรือที่เรียกว่า /sdcard) สำหรับอินสแตนซ์ของผู้ใช้แต่ละราย
  • [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของและทำงานในนามของผู้ใช้ที่ระบุไม่สามารถแสดง อ่าน หรือเขียนไฟล์ที่เป็นของผู้ใช้รายอื่นได้ แม้ว่าข้อมูลของผู้ใช้ทั้ง 2 รายจะจัดเก็บอยู่ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
  • [C-1-5] ต้องเข้ารหัสเนื้อหาของการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อที่ถอดออกไม่ได้เท่านั้น ซึ่งระบบจะเข้าถึงได้เท่านั้น หากการติดตั้งใช้งานอุปกรณ์ใช้สื่อที่ถอดออกได้สำหรับ API พื้นที่เก็บข้อมูลภายนอก เนื่องจากวิธีนี้จะทำให้โฮสต์พีซีอ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้โฮสต์พีซีเข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม

Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมที่ส่งออก ข้อความ SMS แบบพรีเมียมคือข้อความที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการ ซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปที่กำหนดไว้ใน/data/misc/sms/codes.xmlไฟล์ในอุปกรณ์ โครงการโอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานที่เป็นไปตามข้อกำหนดนี้

9.7. ฟีเจอร์ความปลอดภัย

การใช้งานอุปกรณ์ต้องเป็นไปตามฟีเจอร์ความปลอดภัยทั้งในเคอร์เนลและแพลตฟอร์มตามที่อธิบายไว้ด้านล่าง

แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ระบบการควบคุมการเข้าถึงที่จำเป็น (MAC) ของ Security-Enhanced Linux (SELinux), การแซนด์บ็อกซ์ seccomp และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนล Linux การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่ แม้ว่าจะมีการติดตั้งใช้งาน SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ใต้เฟรมเวิร์ก Android ก็ตาม
  • [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดความปลอดภัยและฟีเจอร์ความปลอดภัยที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android บล็อกการละเมิดดังกล่าวได้สำเร็จ แต่จะมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดความปลอดภัยที่ไม่ได้บล็อกซึ่งส่งผลให้มีการใช้ช่องโหว่สำเร็จ
  • [C-0-3] ต้องไม่อนุญาตให้ผู้ใช้หรือนักพัฒนาแอปกำหนดค่า SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ที่ติดตั้งไว้ใต้เฟรมเวิร์ก Android
  • [C-0-4] ต้องไม่อนุญาตให้แอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) กำหนดค่านโยบายที่ทำให้เกิดความไม่เข้ากัน
  • [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการได้แคบลงตามที่อธิบายไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
  • [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์ของแอปพลิเคชันเคอร์เนลที่อนุญาตให้กรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบมัลติเธรด Android Open Source Project ต้นทางเป็นไปตามข้อกำหนดนี้โดยการเปิดใช้ seccomp-BPF ที่มีการซิงโครไนซ์กลุ่มเธรด (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่าเคอร์เนลของ source.android.com

ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการปกป้องตนเองเป็นส่วนสำคัญของการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

  • [C-0-7] ต้องใช้กลไกการป้องกันการเขียนไปยังสแตกเกินขอบเขตที่กำหนดของเคอร์เนล ตัวอย่างกลไกดังกล่าว ได้แก่ 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 การเข้าถึง usercopy ปกติ (เช่น PAN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
  • [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลหากฮาร์ดแวร์มีความเสี่ยงต่อ CVE-2017-5754 ในอุปกรณ์ทั้งหมดที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป (เช่น CONFIG_PAGE_TABLE_ISOLATION หรือ CONFIG_UNMAP_KERNEL_AT_EL0)
  • [C-0-13] ต้องใช้การเสริมความแข็งแกร่งในการคาดการณ์กิ่งก้านหากฮาร์ดแวร์มีความเสี่ยงต่อ CVE-2017-5715 ในอุปกรณ์ทั้งหมดที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป (เช่น CONFIG_HARDEN_BRANCH_PREDICTOR)
  • [SR] ขอแนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนลซึ่งเขียนเฉพาะในระหว่างการเริ่มต้นระบบ โดยทำเครื่องหมายเป็นแบบอ่านอย่างเดียวหลังจากการเริ่มต้นระบบ (เช่น __ro_after_init)

  • [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และหลีกเลี่ยงการเปิดเผยที่จะทำให้การสุ่มเสี่ยงต่อการถูกบุกรุก (เช่น CONFIG_RANDOMIZE_BASE ด้วยเอนโทรปีของ Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การตรวจสอบความสมบูรณ์ของโฟลว์การควบคุม (CFI) ในเคอร์เนลเพื่อเพิ่มการป้องกันการโจมตีแบบนำโค้ดกลับมาใช้ใหม่ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

  • [C-SR] ขอแนะนำอย่างยิ่งว่าไม่ควรปิดใช้การตรวจสอบความสมบูรณ์ของโฟลว์การควบคุม (CFI), สแต็กการเรียกแบบเงา (SCS) หรือการล้างข้อมูลการล้นของจำนวนเต็ม (IntSan) ในคอมโพเนนต์ที่เปิดใช้
  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์ในพื้นที่ผู้ใช้ที่คำนึงถึงความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan
  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในที่ไม่ได้เริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรสมมติค่าที่คอมไพเลอร์ใช้ในการเริ่มต้นตัวแปรภายใน
  • [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นฮีปในเคอร์เนลเพื่อป้องกันการใช้การจัดสรรฮีปที่ไม่ได้เริ่มต้น (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) และไม่ควรสมมติค่าที่เคอร์เนลใช้เพื่อเริ่มต้นการจัดสรรเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนล Linux จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องใช้ SELinux
  • [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดบังคับใช้ทั่วโลก
  • [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดที่อนุญาต ซึ่งรวมถึงโดเมนที่เฉพาะเจาะจงสำหรับอุปกรณ์/ผู้ให้บริการ
  • [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ neverallow ที่อยู่ในโฟลเดอร์ system/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ neverallow ทั้งหมดที่มีอยู่สำหรับทั้งโดเมน SELinux ของ AOSP และโดเมนเฉพาะของอุปกรณ์/ผู้ให้บริการ
  • [C-1-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไปในแซนด์บ็อกซ์ SELinux ต่อแอปพลิเคชัน โดยมีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
  • ควรเก็บรักษานโยบาย SELinux เริ่มต้นที่อยู่ในโฟลเดอร์ system/sepolicy ของ Android Open Source Project ต้นทาง และเพิ่มนโยบายนี้เพิ่มเติมสำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น

หากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้วและไม่สามารถปฏิบัติตามข้อกำหนด [C-1-1] และ [C-1-5] ผ่านการอัปเดตซอฟต์แวร์ระบบได้ ระบบอาจยกเว้นข้อกำหนดเหล่านี้ให้

หากการใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux จะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็นซึ่งเทียบเท่ากับ SELinux

Android มีฟีเจอร์การป้องกันหลายชั้นซึ่งเป็นส่วนสำคัญของความปลอดภัยของอุปกรณ์

9.8 ความเป็นส่วนตัว

9.8.1. ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดยใช้ UsageStatsManager

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเก็บประวัติผู้ใช้ดังกล่าวไว้ตามระยะเวลาการเก็บรักษาที่สมเหตุสมผล
  • [SR] ขอแนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการติดตั้งใช้งาน AOSP

Android จะจัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ System API ของ IncidentManager

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องมีเฉพาะฟิลด์ที่ทำเครื่องหมายด้วย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager
  • [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม เหตุการณ์เหล่านั้นอาจใช้ตัวระบุ Atom อื่นในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่โหลดล่วงหน้าหรือแจกจ่ายคอมโพเนนต์ซอฟต์แวร์ที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้หรือไม่มีการแจ้งเตือนที่ชัดเจนอย่างต่อเนื่อง
  • [C-0-2] ต้องแสดงและขอความยินยอมอย่างชัดแจ้งจากผู้ใช้ที่อนุญาตให้บันทึกข้อมูลที่ละเอียดอ่อน ซึ่งแสดงบนหน้าจอของผู้ใช้ได้ทุกเมื่อที่เปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอผ่าน MediaProjection หรือ API ที่เป็นกรรมสิทธิ์ ต้องไม่ให้ผู้ใช้มีตัวเลือกในการปิดใช้การแสดงความยินยอมของผู้ใช้ในอนาคต
  • [C-0-3] ต้องมีการแจ้งเตือนที่กำลังดำเนินการอยู่ให้ผู้ใช้ทราบขณะเปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอ AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงไอคอนการแจ้งเตือนที่กำลังดำเนินการในแถบสถานะ

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่จับภาพเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นบนอุปกรณ์นอกเหนือจากผ่าน System API ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์อื่นๆ ที่อธิบายไว้ในส่วนที่ 9.8.6 การจับภาพเนื้อหา จะต้องมีลักษณะดังนี้

  • [C-1-1] ต้องมีการแจ้งเตือนอย่างต่อเนื่องให้ผู้ใช้ทราบทุกครั้งที่เปิดใช้ฟังก์ชันนี้และมีการจับภาพ/บันทึกอย่างต่อเนื่อง

หากการติดตั้งใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ทันทีที่แกะกล่อง ซึ่งสามารถบันทึกเสียงรอบข้างและ/หรือบันทึกเสียงที่เล่นบนอุปกรณ์เพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ คอมโพเนนต์ดังกล่าวจะต้องมีลักษณะดังนี้

  • [C-2-1] ต้องไม่จัดเก็บเสียงดิบที่บันทึกไว้หรือรูปแบบใดๆ ที่แปลงกลับเป็นเสียงต้นฉบับหรือเสียงที่คล้ายกันมากไว้ในที่เก็บข้อมูลแบบถาวรในอุปกรณ์หรือส่งออกจากอุปกรณ์ เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้

9.8.3. การเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้ที่ขอความยินยอมจากผู้ใช้ก่อนที่จะอนุญาตให้เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่แชร์ผ่านพอร์ต USB

9.8.4. การจราจรของข้อมูลในเครือข่าย

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันล่วงหน้าสำหรับที่เก็บผู้ออกใบรับรอง (CA) ที่ระบบเชื่อถือตามที่ระบุไว้ใน Android Open Source Project ต้นทาง
  • [C-0-2] ต้องจัดส่งพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า
  • [C-0-3] ต้องแสดงคำเตือนแก่ผู้ใช้ที่ระบุว่าอาจมีการตรวจสอบการรับส่งข้อมูลในเครือข่าย เมื่อมีการเพิ่ม CA หลักของผู้ใช้

หากการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

  • [C-1-1] ต้องแสดงคำเตือนแก่ผู้ใช้ซึ่งระบุอย่างใดอย่างหนึ่งต่อไปนี้
    • การรับส่งข้อมูลในเครือข่ายอาจได้รับการตรวจสอบ
    • การรับส่งข้อมูลในเครือข่ายดังกล่าวจะได้รับการกำหนดเส้นทางผ่านแอปพลิเคชัน VPN ที่เฉพาะเจาะจงซึ่งให้บริการ VPN

หากการติดตั้งใช้งานอุปกรณ์มีกลไกที่เปิดใช้ทันทีโดยค่าเริ่มต้น ซึ่งกำหนดเส้นทางการรับส่งข้อมูลในเครือข่ายผ่านเซิร์ฟเวอร์พร็อกซีหรือเกตเวย์ VPN (เช่น การโหลดบริการ VPN ล่วงหน้าโดยได้รับandroid.permission.CONTROL_VPN) กลไกดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนที่จะเปิดใช้กลไกดังกล่าว เว้นแต่ว่า Device Policy Controller จะเปิดใช้ VPN นั้นผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับการแจ้งเตือนเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้ความสามารถของผู้ใช้ในการเปิด/ปิดฟังก์ชัน "VPN แบบเปิดตลอดเวลา" ของแอป VPN ของบุคคลที่สาม จะต้องดำเนินการดังนี้

  • [C-3-1] ต้องปิดใช้ความสามารถนี้สำหรับแอปที่ไม่รองรับบริการ VPN ที่เปิดตลอดเวลาในไฟล์ AndroidManifest.xml โดยตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

9.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 หรือผ่านวิธีการที่เป็นกรรมสิทธิ์อื่นๆ

  • ข้อความและกราฟิกที่แสดงบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน API ของ AssistStructure
  • ข้อมูลสื่อ เช่น เสียงหรือวิดีโอที่อุปกรณ์บันทึกหรือเล่น
  • เหตุการณ์การป้อนข้อมูล (เช่น แป้นพิมพ์ เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)
  • เหตุการณ์อื่นๆ ที่แอปพลิเคชันระบุต่อระบบผ่าน Content Capture API หรือ API ที่เป็นกรรมสิทธิ์ซึ่งมีความสามารถคล้ายกัน
  • ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน TextClassifier API ไปยัง TextClassifier ของระบบ ซึ่งก็คือไปยังบริการของระบบเพื่อทำความเข้าใจความหมายของข้อความ รวมถึงสร้างการดำเนินการถัดไปที่คาดการณ์ไว้ตามข้อความ

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลข้างต้น อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องเข้ารหัสข้อมูลดังกล่าวทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้การเข้ารหัสตามไฟล์ของ Android หรือการเข้ารหัสใดๆ ที่ระบุเป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
  • [C-1-2] ต้องไม่สำรองข้อมูลดิบหรือข้อมูลที่เข้ารหัสโดยใช้วิธีการสำรองข้อมูลของ Android หรือวิธีการสำรองข้อมูลอื่นๆ
  • [C-1-3] ต้องส่งข้อมูลดังกล่าวทั้งหมดและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัวเท่านั้น กลไกการรักษาความเป็นส่วนตัวได้รับการกําหนดให้เป็น "กลไกที่อนุญาตให้วิเคราะห์แบบรวมเท่านั้น และป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้กับผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้ข้อมูลต่อผู้ใช้แต่ละรายสามารถตรวจสอบได้ (เช่น การใช้เทคโนโลยีความเป็นส่วนตัวเชิงอนุพันธ์ เช่น RAPPOR)
  • [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวของผู้ใช้ (เช่น Account) ในอุปกรณ์ เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล
  • [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับแอปอื่นๆ เว้นแต่จะได้รับความยินยอมจากผู้ใช้ทุกครั้งที่มีการแชร์
  • [C-1-6] ต้องมีตัวเลือกให้ผู้ใช้ลบข้อมูลดังกล่าวที่ ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์รวบรวม หากมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์มีบริการที่ใช้ System API ContentCaptureService หรือบริการที่เป็นกรรมสิทธิ์ซึ่งบันทึกข้อมูลตามที่อธิบายไว้ข้างต้น บริการดังกล่าวจะต้องมีคุณสมบัติดังนี้

  • [C-2-1] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการจับภาพเนื้อหาด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้ และต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าจับภาพข้อมูลดังกล่าว
  • [C-2-2] ต้องไม่อนุญาตให้แอปอื่นนอกเหนือจากกลไกบริการจับภาพเนื้อหาที่ติดตั้งไว้ล่วงหน้าสามารถจับภาพข้อมูลดังกล่าวได้
  • [C-2-3] ต้องมีตัวเลือกให้ผู้ใช้ปิดใช้บริการจับภาพเนื้อหา
  • [C-2-4] ต้องไม่ละเลยความสามารถของผู้ใช้ในการจัดการสิทธิ์ของ Android ที่บริการจับภาพเนื้อหามี และต้องปฏิบัติตามรูปแบบสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้แยกคอมโพเนนต์บริการจับภาพเนื้อหาออกจากคอมโพเนนต์อื่นๆ ของระบบ เช่น ไม่ผูกรหัสกระบวนการบริการหรือการแชร์กับคอมโพเนนต์อื่นๆ ของระบบ ยกเว้นในกรณีต่อไปนี้

    • โทรศัพท์ รายชื่อติดต่อ UI ของระบบ และสื่อ

9.8.7. การเข้าถึงคลิปบอร์ด

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่แสดงข้อมูลที่ตัดในคลิปบอร์ด (เช่น ผ่าน ClipboardManager API) เว้นแต่แอปจะเป็น IME เริ่มต้นหรือเป็นแอปที่โฟกัสอยู่

9.8.8. ตำแหน่ง

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้หรือผู้ใช้ไม่ได้เป็นผู้เริ่มดำเนินการ
  • [C-0-2] ต้องมีเครื่องมือสำหรับผู้ใช้เพื่อเข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่ง ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้การสแกน Wi-Fi/บลูทูธเพื่อระบุตำแหน่ง
  • [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] เป็นเซสชันฉุกเฉินที่ผู้ใช้เริ่มต้น (เช่น โทรหา 911 หรือส่งข้อความถึง 911) อย่างไรก็ตาม สำหรับยานยนต์ รถยนต์อาจเริ่มเซสชันฉุกเฉินได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนดของ eCall)
  • [C-0-4] ต้องคงความสามารถของ Emergency Location Bypass API ในการข้ามการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่ต้องเปลี่ยนการตั้งค่า
  • [C-0-5] ต้องตั้งเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งของผู้ใช้โดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.8.9. แอปที่ติดตั้ง

โดยค่าเริ่มต้นแล้ว แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไม่ได้ (ดูระดับการเข้าถึงแพ็กเกจในเอกสารประกอบ Android SDK)

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องไม่เปิดเผยรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งให้กับแอปใดๆ ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป เว้นแต่แอปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งผ่าน API ที่มีการจัดการได้อยู่แล้ว ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งผู้ติดตั้งใช้งานอุปกรณ์เพิ่ม หรือเข้าถึงได้ผ่านระบบไฟล์

9.8.10. รายงานข้อบกพร่องเกี่ยวกับการเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์สร้างรายงานข้อบกพร่องโดยใช้ System API BUGREPORT_MODE_TELEPHONY กับ BugreportManager จะมีลักษณะดังนี้

  • [C-1-1] ต้องได้รับความยินยอมจากผู้ใช้ทุกครั้งที่มีการเรียกใช้ System API BUGREPORT_MODE_TELEPHONY เพื่อสร้างรายงาน และต้องไม่แจ้งให้ผู้ใช้ยินยอมสำหรับคำขอในอนาคตทั้งหมดจากแอปพลิเคชัน
  • [C-1-2] ต้องแสดงและขอรับความยินยอมอย่างชัดแจ้งจากผู้ใช้เมื่อเริ่มสร้างรายงาน และต้องไม่ส่งรายงานที่สร้างขึ้นไปยังแอปที่ขอโดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้
  • [C-1-3] ต้องสร้างรายงานที่ขอซึ่งมีข้อมูลต่อไปนี้เป็นอย่างน้อย
    • ดัมพ์ TelephonyDebugService
    • การดัมพ์ TelephonyRegistry
    • ดัมพ์ WifiService
    • ConnectivityService dump
    • การทิ้งอินสแตนซ์ CarrierService ของแพ็กเกจการโทร (หากมีการเชื่อมโยง)
    • บัฟเฟอร์บันทึกวิทยุ
  • [C-1-4] ต้องไม่รวมข้อมูลต่อไปนี้ในรายงานที่สร้างขึ้น
    • ข้อมูลทุกประเภทที่ไม่เกี่ยวข้องกับการแก้ไขข้อบกพร่องด้านการเชื่อมต่อ
    • บันทึกการเข้าชมแอปพลิเคชันที่ผู้ใช้ติดตั้ง หรือโปรไฟล์โดยละเอียดของแอปพลิเคชัน/แพ็กเกจที่ผู้ใช้ติดตั้ง (ใช้ UID ได้ แต่ใช้ชื่อแพ็กเกจไม่ได้)
  • อาจมีข้อมูลเพิ่มเติมที่ไม่ได้เชื่อมโยงกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น บันทึกของผู้ให้บริการ)

หากการติดตั้งใช้งานอุปกรณ์มีข้อมูลเพิ่มเติม (เช่น บันทึกของผู้ให้บริการ) ในรายงานข้อบกพร่อง และข้อมูลดังกล่าวส่งผลต่อความเป็นส่วนตัว/ความปลอดภัย/แบตเตอรี่/พื้นที่เก็บข้อมูล/หน่วยความจำ จะต้องดำเนินการดังนี้

  • [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าเริ่มต้นของนักพัฒนาซอฟต์แวร์เป็นปิดใช้ AOSP ตอบโจทย์ข้อกำหนดนี้โดยมีEnable verbose vendor loggingตัวเลือกในการตั้งค่าสำหรับนักพัฒนาแอปเพื่อรวมบันทึกเวนเดอร์เพิ่มเติมเฉพาะอุปกรณ์ไว้ในรายงานข้อบกพร่อง

9.8.11. การแชร์ Blob ข้อมูล

Android อนุญาตให้แอปมีส่วนร่วมในการส่ง Blob ข้อมูลไปยังระบบเพื่อแชร์กับชุดแอปที่เลือกผ่าน BlobStoreManager

หากการติดตั้งใช้งานอุปกรณ์รองรับ Blob ข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องไม่แชร์ Blob ข้อมูลที่เป็นของแอปเกินกว่าที่ตั้งใจจะอนุญาต (กล่าวคือ ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreManager.session#allowPublicAccess() ต้องไม่ได้รับการแก้ไข) การติดตั้งใช้งานอ้างอิงของ AOSP เป็นไปตามข้อกำหนดเหล่านี้
  • [C-1-2] ต้องไม่ส่งออกจากอุปกรณ์หรือแชร์กับแอปอื่นๆ ซึ่งแฮชที่ปลอดภัยของ Blob ข้อมูล (ซึ่งใช้เพื่อควบคุมการเข้าถึง)

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 Direct Boot mode แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

  • [C-0-2] ต้องยังคงออกอากาศ Intent ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED เพื่อส่งสัญญาณไปยังแอปพลิเคชันที่รับรู้การบูตโดยตรงว่าตำแหน่งที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และตำแหน่งที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) พร้อมใช้งานสำหรับผู้ใช้

9.9.2. ข้อกำหนดด้านการเข้ารหัส

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเข้ารหัสข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรที่ถอดออกไม่ได้ของอุปกรณ์
  • [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าประสบการณ์การใช้งานครั้งแรกเสร็จสมบูรณ์

  • [C-0-3] ต้องเป็นไปตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นโดยใช้วิธีการเข้ารหัส 2 วิธีต่อไปนี้

9.9.3. วิธีการเข้ารหัส

หากการติดตั้งใช้งานอุปกรณ์มีการเข้ารหัส จะมีลักษณะดังนี้

  • [C-1-1] ต้องเปิดเครื่องโดยไม่ต้องขอข้อมูลเข้าสู่ระบบจากผู้ใช้ และอนุญาตให้แอปที่รับรู้การเปิดเครื่องโดยตรงเข้าถึงที่เก็บข้อมูลที่เข้ารหัสของอุปกรณ์ (DE) หลังจากที่ออกอากาศข้อความ ACTION_LOCKED_BOOT_COMPLETED
  • [C-1-2] ต้องอนุญาตให้เข้าถึงที่เก็บข้อมูลที่เข้ารหัสด้วยข้อมูลเข้าสู่ระบบ (CE) หลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยระบุข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และมีการออกอากาศข้อความ ACTION_USER_UNLOCKED เท่านั้น
  • [C-1-13] ต้องไม่เสนอวิธีการใดๆ ในการปลดล็อกที่เก็บข้อมูลที่ได้รับการปกป้องโดย CE โดยไม่มีข้อมูลเข้าสู่ระบบที่ผู้ใช้ระบุ คีย์การฝากที่ลงทะเบียน หรือการดำเนินการต่อเมื่อรีบูตซึ่งเป็นไปตามข้อกำหนดในส่วน 9.9.4
  • [C-1-4] ต้องใช้การเปิดเครื่องที่ได้รับการยืนยัน

9.9.3.1. การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา

หากการติดตั้งใช้งานอุปกรณ์ใช้การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-5] ต้องเข้ารหัสเนื้อหาของไฟล์และข้อมูลเมตาของระบบไฟล์โดยใช้ AES-256-XTS หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวของคีย์การเข้ารหัส 256 บิต ซึ่งทำงานในโหมด XTS โดยมีความยาวของคีย์ทั้งหมด 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ที่ https://github.com/google/adiantum ข้อมูลเมตาของระบบไฟล์คือข้อมูล เช่น ขนาดไฟล์ การเป็นเจ้าของ โหมด และแอตทริบิวต์เพิ่มเติม (xattrs)
  • [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS หรือ Adiantum
  • [C-1-12] หากอุปกรณ์มีคำสั่งมาตรฐานการเข้ารหัสขั้นสูง (AES) (เช่น ส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86) จะต้องใช้ตัวเลือกที่ใช้ AES ด้านบนสำหรับการเข้ารหัสชื่อไฟล์ เนื้อหาไฟล์ และข้อมูลเมตาของระบบไฟล์ ไม่ใช่ Adiantum
  • [C-1-13] ต้องใช้ฟังก์ชันการได้คีย์ (KDF) ที่มีการเข้ารหัสที่รัดกุมและย้อนกลับไม่ได้ (เช่น HKDF-SHA512) เพื่อได้คีย์ย่อยที่จำเป็น (เช่น คีย์ต่อไฟล์) จากคีย์ CE และ DE "เข้ารหัสอย่างแน่นหนาและย้อนกลับไม่ได้" หมายความว่าฟังก์ชันการได้คีย์มีความแข็งแกร่งด้านความปลอดภัยอย่างน้อย 256 บิต และทํางานเป็นตระกูลฟังก์ชันแบบสุ่มเทียมในอินพุต

  • [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยของการเข้ารหัสที่อิงตามไฟล์ (FBE) เดียวกันเพื่อวัตถุประสงค์ในการเข้ารหัสที่แตกต่างกัน (เช่น ทั้งสำหรับการเข้ารหัสและการสร้างคีย์ หรือสำหรับอัลกอริทึมการเข้ารหัส 2 แบบที่แตกต่างกัน)

  • คีย์ที่ปกป้องพื้นที่เก็บข้อมูล CE และ DE รวมถึงข้อมูลเมตาของระบบไฟล์

  • [C-1-7] ต้องผูกกับการเข้ารหัสกับที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทของความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์

  • [C-1-8] คีย์ CE ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้
  • [C-1-9] ต้องเชื่อมโยงคีย์ CE กับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบของหน้าจอล็อก
  • [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ คีย์ CE หรือ DE ของผู้ใช้รายใดรายหนึ่งต้องไม่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น

  • [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่รองรับตามข้อกำหนด

  • ควรทำให้แอปที่จำเป็นซึ่งติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ Messenger) รู้จักการบูตโดยตรง

โปรเจ็กต์ Android Open Source ต้นทางมีการติดตั้งใช้งานที่ต้องการสำหรับการเข้ารหัสตามไฟล์โดยอิงตามฟีเจอร์การเข้ารหัส "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] ต้องผูกกับการเข้ารหัสกับที่เก็บคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและรูทของความน่าเชื่อถือของฮาร์ดแวร์ของอุปกรณ์

  • [C-1-6] ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง

การเข้ารหัสระดับบล็อกต่อผู้ใช้สามารถใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของเคอร์เนล Linux ผ่านพาร์ติชันต่อผู้ใช้

9.9.4. ดำเนินการต่อเมื่อรีบูต

การทำงานต่อเมื่อรีบูตช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดได้ ซึ่งรวมถึงแอปที่ยังไม่รองรับการบูตโดยตรงหลังจากรีบูตที่เริ่มต้นโดย OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้หลังจากรีบูต

การติดตั้งใช้งานฟีเจอร์ดำเนินการต่อเมื่อรีบูตต้องดำเนินการต่อไปเพื่อให้มั่นใจว่าเมื่ออุปกรณ์ตกอยู่ในมือของผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัส CE ของผู้ใช้ได้ยากมาก แม้ว่าอุปกรณ์จะเปิดอยู่ ที่เก็บข้อมูล CE จะปลดล็อก และผู้ใช้จะปลดล็อกอุปกรณ์หลังจากได้รับ OTA แล้วก็ตาม นอกจากนี้ เรายังถือว่าผู้โจมตีได้รับสิทธิ์เข้าถึงคีย์การลงนามแบบเข้ารหัสสำหรับการออกอากาศเพื่อป้องกันการโจมตีจากคนใน

ดังนี้

  • [C-0-1] ที่เก็บข้อมูล CE ต้องอ่านไม่ได้แม้แต่ผู้โจมตีที่มีอุปกรณ์อยู่กับตัวและมีความสามารถและข้อจำกัดต่อไปนี้

    • ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามข้อความที่กำหนดเอง
    • อาจทำให้อุปกรณ์ได้รับการอัปเดต OTA
    • สามารถแก้ไขการทำงานของฮาร์ดแวร์ (AP, แฟลช ฯลฯ) ได้ ยกเว้นตามที่ระบุไว้ด้านล่าง แต่การแก้ไขดังกล่าวจะทำให้เกิดความล่าช้าอย่างน้อย 1 ชั่วโมงและต้องปิดเปิดเครื่องใหม่ ซึ่งจะล้างเนื้อหาใน RAM
    • แก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการดัดแปลง (เช่น Titan M) ไม่ได้
    • อ่าน RAM ของอุปกรณ์ที่ใช้งานจริงไม่ได้
    • ไม่สามารถขอข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้มีการป้อนข้อมูลดังกล่าว

ตัวอย่างเช่น การใช้งานอุปกรณ์ที่ใช้และเป็นไปตามคำอธิบายทั้งหมดที่ระบุที่นี่จะเป็นไปตาม [C-0-1]

9.10. ความสมบูรณ์ของอุปกรณ์

ข้อกำหนดต่อไปนี้ช่วยให้มั่นใจได้ถึงความโปร่งใสเกี่ยวกับสถานะความสมบูรณ์ของอุปกรณ์ การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะ Bootloader อนุญาตให้แฟลชอิมเมจระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN จะสงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ของระบบใหม่นี้

  • [C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

หากมีการเปิดตัวการใช้งานอุปกรณ์โดยไม่รองรับการเปิดเครื่องที่ได้รับการยืนยันใน Android เวอร์ชันก่อนหน้า และเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบไม่ได้ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

การเปิดเครื่องที่ได้รับการยืนยันเป็นฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์นี้ อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องประกาศฟีเจอร์แฟล็กของแพลตฟอร์ม android.software.verified_boot
  • [C-1-2] ต้องทำการยืนยันในทุกๆ ลำดับการบูต
  • [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรากฐานของความน่าเชื่อถือ และดำเนินการไปจนถึงพาร์ติชันของระบบ
  • [C-1-4] ต้องใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความสมบูรณ์และความถูกต้องของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
  • [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่แข็งแกร่งเท่ากับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
  • [C-1-6] ต้องไม่อนุญาตให้บูตจนเสร็จเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้จะยินยอมให้ลองบูตต่อไป ในกรณีนี้ต้องไม่ใช้ข้อมูลจากบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้ยืนยัน
  • [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้จะปลดล็อก Bootloader อย่างชัดเจน
  • [C-SR] หากมีชิปแยกหลายตัวในอุปกรณ์ (เช่น วิทยุ โปรเซสเซอร์รูปภาพเฉพาะ) ขอแนะนำอย่างยิ่งให้กระบวนการบูตของชิปแต่ละตัวตรวจสอบทุกขั้นตอนเมื่อบูต
  • [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลง: สำหรับจัดเก็บว่ามีการปลดล็อก Bootloader หรือไม่ พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงหมายความว่า Bootloader สามารถตรวจหาได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
  • [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ที่ล็อกเป็นโหมด Bootloader ที่ปลดล็อก
  • [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันการบูตและระบบ) และใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชัน OS ขั้นต่ำที่อนุญาต
  • [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดด้วยห่วงโซ่ความน่าเชื่อถือที่ฝังอยู่ในพาร์ติชันที่ได้รับการปกป้องโดย Verified Boot
  • [C-SR] ขอแนะนำอย่างยิ่งให้ตรวจสอบอาร์ติแฟกต์ที่เรียกใช้งานได้ซึ่งแอปที่มีสิทธิ์พิเศษโหลดจากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์แล้ว) ก่อนที่จะเรียกใช้งาน หรือขอแนะนำอย่างยิ่งไม่ให้เรียกใช้งานเลย
  • ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์แบบถาวร (เช่น โมเด็ม กล้อง) และควรใช้ที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันขั้นต่ำที่อนุญาต

หากมีการเปิดตัวการติดตั้งใช้งานอุปกรณ์โดยไม่รองรับ C-1-8 ถึง C-1-10 ใน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

โครงการโอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานฟีเจอร์นี้ที่แนะนำในที่เก็บ external/avb/ ซึ่งสามารถผสานรวมเข้ากับ Bootloader ที่ใช้โหลด Android ได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องรองรับการยืนยันเนื้อหาของไฟล์โดยใช้การเข้ารหัสเทียบกับคีย์ที่เชื่อถือได้โดยไม่ต้องอ่านทั้งไฟล์
  • [C-0-4] ต้องไม่อนุญาตให้คำขออ่านในไฟล์ที่ได้รับการปกป้องสำเร็จเมื่อเนื้อหาที่อ่านไม่ได้รับการยืนยันเทียบกับคีย์ที่เชื่อถือได้

หากมีการเปิดตัวการใช้งานอุปกรณ์โดยที่ไม่มีความสามารถในการยืนยันเนื้อหาไฟล์กับคีย์ที่เชื่อถือได้ใน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด โครงการโอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานฟีเจอร์นี้ที่แนะนำโดยอิงตามฟีเจอร์ fs-verity ของเคอร์เนล Linux

การติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Protected Confirmation API จะมีลักษณะดังนี้

  • [C-3-1] ต้องรายงาน true สำหรับ ConfirmationPrompt.isSupported() API

  • [C-3-2] ต้องตรวจสอบว่าโค้ดที่ทำงานในระบบปฏิบัติการ Android ซึ่งรวมถึงเคอร์เนล ไม่ว่าจะเป็นโค้ดที่เป็นอันตรายหรือไม่ก็ตาม จะไม่สามารถสร้างการตอบกลับเชิงบวกได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้

  • [C-3-3] ต้องตรวจสอบว่าผู้ใช้สามารถตรวจสอบและอนุมัติข้อความที่แจ้งได้ แม้ในกรณีที่ระบบปฏิบัติการ Android รวมถึงเคอร์เนลถูกบุกรุก

9.11. คีย์และข้อมูลเข้าสู่ระบบ

ระบบ Android Keystore ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์และใช้คีย์เหล่านั้นในการดำเนินการเข้ารหัสผ่าน KeyChain API หรือ Keystore API ได้ การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องอนุญาตให้นำเข้าหรือสร้างคีย์อย่างน้อย 8,192 รายการ
  • [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องจำกัดอัตราการพยายามและต้องมีอัลกอริทึมการถอยแบบทวีคูณ หากพยายามไม่สำเร็จเกิน 150 ครั้ง การหน่วงเวลาต้องเป็นอย่างน้อย 24 ชั่วโมงต่อการพยายาม 1 ครั้ง
  • ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้

เมื่อการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้

  • [C-1-1] ต้องสำรองข้อมูลการใช้งาน Keystore ด้วยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
  • [C-1-2] ต้องมีการติดตั้งใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮช MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Android Keystore รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและเหนือกว่าอย่างปลอดภัย การแยกอย่างปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือโค้ดในพื้นที่ผู้ใช้อาจใช้เพื่อเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยก รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานที่ปลอดภัยซึ่งได้รับการตรวจสอบจากบุคคลที่สามของการแยกตามไฮเปอร์ไวเซอร์ที่เหมาะสมก็เป็นตัวเลือกอื่นเช่นกัน
  • [C-1-3] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการที่แยกจากกัน และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้เมื่อดำเนินการสำเร็จเท่านั้น ต้องจัดเก็บข้อมูลเข้าสู่ระบบของหน้าจอล็อกในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกจากกันทำการตรวจสอบสิทธิ์ของหน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android ต้นทางมีเลเยอร์การแยกฮาร์ดแวร์ (HAL) ของ Gatekeeper และ Trusty ซึ่งใช้เพื่อตอบสนองข้อกำหนดนี้ได้
  • [C-1-4] ต้องรองรับเอกสารรับรองคีย์ในกรณีที่คีย์การลงนามเอกสารรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่ปลอดภัย และการลงนามดำเนินการในฮาร์ดแวร์ที่ปลอดภัย ต้องแชร์คีย์การลงนามการรับรองในอุปกรณ์จำนวนมากพอเพื่อป้องกันไม่ให้ใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย

โปรดทราบว่าหากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีที่เก็บคีย์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกจากกันและรองรับการรับรองคีย์ เว้นแต่จะประกาศฟีเจอร์ android.hardware.fingerprint ซึ่งต้องมีที่เก็บคีย์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกจากกัน

  • [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกการหมดเวลาสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นสถานะล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตได้ไม่เกิน 15 วินาที อุปกรณ์ยานยนต์ที่ล็อกหน้าจอทุกครั้งที่ปิดเฮดยูนิตหรือเปลี่ยนผู้ใช้ อาจไม่มีการกำหนดค่าการหมดเวลาสลีป

9.11.1. หน้าจอล็อกและการตรวจสอบสิทธิ์ที่ปลอดภัย

การใช้งาน AOSP เป็นไปตามรูปแบบการตรวจสอบสิทธิ์แบบแบ่งระดับ ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตามปัจจัยด้านความรู้สามารถสำรองข้อมูลได้ด้วยไบโอเมตริกที่รัดกุมรอง หรือด้วยรูปแบบการตรวจสอบสิทธิ์ระดับที่สามที่รัดกุมน้อยกว่า

การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าวิธีการตรวจสอบสิทธิ์หลักเป็นเพียงหนึ่งในวิธีการต่อไปนี้
    • PIN ที่เป็นตัวเลข
    • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
    • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 พอดี

โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นเรียกว่าวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะมีลักษณะดังนี้

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกโดยอิงตามข้อมูลลับที่ทราบ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อถือเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ ให้ทำดังนี้

  • [C-3-1] เอนโทรปีของความยาวอินพุตที่สั้นที่สุดที่อนุญาตต้องมากกว่า 10 บิต
  • [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
  • [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ซึ่งใช้งานและมีให้ใน AOSP
  • [C-3-4] ต้องปิดใช้การตรวจสอบสิทธิ์แบบใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_SOMETHING
  • [C-3-5] วิธีการตรวจสอบสิทธิ์ใหม่ต้องเปลี่ยนกลับไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 72 ชั่วโมงหรือน้อยกว่า หรือเปิดเผยต่อผู้ใช้อย่างชัดเจนว่าจะไม่มีการสำรองข้อมูลบางอย่างเพื่อรักษาความเป็นส่วนตัวของข้อมูล

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอล็อกและใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามไบโอเมตริกซ์เพื่อให้ถือเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการใหม่นี้จะมีลักษณะดังนี้

  • [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วน 7.3.10 สำหรับคลาส 1 (เดิมคือความสะดวก)
  • [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลลับที่ทราบ
  • [C-4-3] ต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายฟีเจอร์ Keyguard โดยการเรียกใช้เมธอด 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.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) ได้ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-6-3] ผู้ใช้ต้องได้รับแจ้งให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำอย่างใดอย่างหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 4 ชั่วโมงหรือน้อยกว่านั้น
  • [C-6-4] วิธีการใหม่ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง

หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีตัวแทนความน่าเชื่อถืออย่างน้อย 1 รายที่ใช้ TrustAgentService System API จะมีลักษณะดังนี้

  • [C-7-1] ต้องมีข้อบ่งชี้ที่ชัดเจนในเมนูการตั้งค่าและบนหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ออกไปหรือเมื่อเอเจนต์ที่เชื่อถือได้ปลดล็อกอุปกรณ์ได้ เช่น AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงคำอธิบายข้อความสำหรับการตั้งค่า "ล็อกอัตโนมัติ" และ "ปุ่มเปิด/ปิดล็อกทันที" ในเมนูการตั้งค่า และไอคอนที่แยกแยะได้บนหน้าจอล็อก
  • [C-7-2] ต้องปฏิบัติตามและใช้ API ของตัวแทนที่เชื่อถือได้ทั้งหมดในคลาส DevicePolicyManager อย่างครบถ้วน เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
  • [C-7-3] ต้องไม่ใช้ฟังก์ชัน TrustAgentService.addEscrowToken() อย่างเต็มรูปแบบในอุปกรณ์ที่ใช้เป็นอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) แต่สามารถใช้ฟังก์ชันดังกล่าวอย่างเต็มรูปแบบในการติดตั้งใช้งานอุปกรณ์ที่มักใช้ร่วมกัน (เช่น อุปกรณ์ Android Television หรือ Automotive)
  • [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
  • [C-7-5] ต้องไม่จัดเก็บคีย์การเข้ารหัสหรือโทเค็นการฝากคีย์ไว้ในอุปกรณ์เดียวกันกับที่ใช้คีย์ เช่น อนุญาตให้คีย์ที่จัดเก็บไว้ในโทรศัพท์ปลดล็อกบัญชีผู้ใช้ในทีวีได้ สำหรับอุปกรณ์ยานยนต์ ระบบไม่อนุญาตให้จัดเก็บโทเค็นการดูแลจัดการในส่วนใดๆ ของยานพาหนะ
  • [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบถึงผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นการฝากไว้เพื่อถอดรหัสที่จัดเก็บข้อมูล
  • [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง
  • [C-7-8] ผู้ใช้ต้องได้รับการแจ้งเตือนให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำอย่างใดอย่างหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น เว้นแต่จะมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้ (เช่น การที่ผู้ขับขี่เสียสมาธิ)
  • [C-7-9] ระบบต้องท้าทายให้ผู้ใช้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วน 7.3.10 เว้นแต่จะมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้ (เช่น การที่ผู้ขับขี่เสียสมาธิ)
  • [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
  • [C-7-11] ต้องไม่อนุญาตให้ TrustAgent ในอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) ปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกได้นานสูงสุด 4 ชั่วโมงเท่านั้น การใช้งาน TrustManagerService ใน AOSP โดยค่าเริ่มต้นเป็นไปตามข้อกำหนดนี้
  • [C-7-12] ต้องใช้ช่องทางการสื่อสารที่ปลอดภัยด้วยการเข้ารหัส (เช่น UKEY2) เพื่อส่งโทเค็นการฝากจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย

หากการติดตั้งใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อก Keyguard ให้ทำดังนี้

  • [C-8-1] ต้องปิดใช้เมธอดใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
  • [C-8-2] พวกเขาต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ตั้งค่าโดย DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-8-3] อุปกรณ์ต้องไม่เปิดเผย API เพื่อให้แอปของบุคคลที่สามใช้เปลี่ยนสถานะล็อก

9.11.2. StrongBox

ระบบที่เก็บคีย์ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ รวมถึงสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 ถึง C-1-11 ด้านล่างนี้กำหนดข้อกำหนดที่อุปกรณ์ต้องมีจึงจะมีสิทธิ์เป็น StrongBox

การติดตั้งใช้งานอุปกรณ์ที่มีโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ

  • [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ StrongBox StrongBox มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป

หากการติดตั้งใช้งานอุปกรณ์รองรับ StrongBox จะมีลักษณะดังนี้

  • [C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE

  • [C-1-2] ต้องมีฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะซึ่งใช้เพื่อสำรองข้อมูลที่เก็บคีย์และรักษาความปลอดภัยในการตรวจสอบสิทธิ์ผู้ใช้ นอกจากนี้ ฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะอาจใช้เพื่อวัตถุประสงค์อื่นๆ ได้ด้วย

  • [C-1-3] ต้องมี CPU แยกต่างหากที่ไม่แชร์แคช, DRAM, ตัวประมวลผลร่วม หรือทรัพยากรหลักอื่นๆ กับ Application Processor (AP)

  • [C-1-4] ต้องตรวจสอบว่าอุปกรณ์ต่อพ่วงที่แชร์กับ AP จะไม่สามารถเปลี่ยนแปลงการประมวลผล StrongBox ในทางใดทางหนึ่ง หรือรับข้อมูลใดๆ จาก StrongBox AP อาจปิดใช้หรือบล็อกการเข้าถึง StrongBox

  • [C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำที่สมเหตุสมผล (+-10%) ซึ่งไม่ได้รับผลกระทบจากการดัดแปลงโดย AP

  • [C-1-6] ต้องมีเครื่องสร้างตัวเลขสุ่มจริงที่สร้างเอาต์พุตที่กระจายอย่างสม่ำเสมอและคาดเดาไม่ได้

  • [C-1-7] ต้องมีความต้านทานการดัดแปลง ซึ่งรวมถึงความต้านทานต่อการเจาะทางกายภาพและการเกิดข้อบกพร่อง

  • [C-1-8] ต้องมีความต้านทานช่องทางด้านข้าง ซึ่งรวมถึงความต้านทานต่อการรั่วไหลของข้อมูลผ่านช่องทางด้านข้างของกำลังไฟฟ้า เวลา การแผ่รังสีแม่เหล็กไฟฟ้า และการแผ่รังสีความร้อน

  • [C-1-9] ต้องมีพื้นที่เก็บข้อมูลที่ปลอดภัยซึ่งรับประกันความลับ ความสมบูรณ์ ความถูกต้อง ความสอดคล้อง และความใหม่ของเนื้อหา ระบบต้องอ่านหรือแก้ไขที่เก็บข้อมูลไม่ได้ เว้นแต่จะได้รับอนุญาตจาก StrongBox API

  • หากต้องการตรวจสอบความสอดคล้องกับ [C-1-3] ถึง [C-1-9] การใช้งานอุปกรณ์ต้องมีลักษณะดังนี้

    • [C-1-10] ต้องมีฮาร์ดแวร์ที่ได้รับการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วมกัน
    • [C-1-11] ต้องมีเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วมกัน
    • [C-SR] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ได้รับการประเมินโดยใช้เป้าหมายด้านความปลอดภัย ระดับการรับประกันการประเมิน (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป

  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อป้องกันการโจมตีจากภายใน (IAR) ซึ่งหมายความว่าผู้ที่อยู่ภายในซึ่งมีสิทธิ์เข้าถึงคีย์การลงนามเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox รั่วไหลความลับ บายพาสข้อกำหนดด้านความปลอดภัยในการทำงาน หรือเปิดใช้การเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ วิธีที่แนะนำในการติดตั้งใช้งาน IAR คือการอนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านของผู้ใช้หลักผ่าน IAuthSecret HAL

9.11.3. ข้อมูลประจำตัว

ระบบข้อมูลเข้าสู่ระบบประจำตัวได้รับการกำหนดและสร้างขึ้นโดยการติดตั้งใช้งาน API ทั้งหมดในแพ็กเกจ android.security.identity.* API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและดึงเอกสารระบุตัวตนของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานระบบข้อมูลเข้าสู่ระบบเพื่อยืนยันตัวตน

หากการติดตั้งใช้งานอุปกรณ์ใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-0-1] ต้องแสดงผลที่ไม่ใช่ Null สำหรับเมธอด IdentityCredentialStore#getInstance()

  • [C-0-2] ต้องใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว (เช่น android.security.identity.* API) กับโค้ดที่สื่อสารกับแอปพลิเคชันที่เชื่อถือได้ในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและเหนือกว่าอย่างปลอดภัย การแยกอย่างปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือโค้ดในพื้นที่ผู้ใช้อาจใช้เพื่อเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยก รวมถึง DMA

  • [C-0-3] การดำเนินการเข้ารหัสที่จำเป็นต่อการใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว (เช่น android.security.identity.* API) ต้องดำเนินการทั้งหมดในแอปพลิเคชันที่เชื่อถือได้ และห้ามไม่ให้คีย์ส่วนตัวออกจากสภาพแวดล้อมการดำเนินการที่แยกต่างหาก เว้นแต่ API ระดับสูงกว่าจะกำหนดไว้โดยเฉพาะ (เช่น เมธอด createEphemeralKeyPair())

  • [C-0-4] ต้องติดตั้งใช้งานแอปพลิเคชันที่เชื่อถือได้ในลักษณะที่พร็อพเพอร์ตี้ความปลอดภัยไม่ได้รับผลกระทบ (เช่น จะไม่ปล่อยข้อมูลเข้าสู่ระบบจนกว่าจะตรงตามเงื่อนไขการควบคุมการเข้าถึง ไม่สามารถสร้าง MAC สำหรับข้อมูลที่กำหนดเองได้) แม้ว่า Android จะทำงานผิดปกติหรือถูกบุกรุกก็ตาม

9.12. การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องจัดหากลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
  • [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ userdata
  • [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
  • [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้นจากโรงงาน" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของDevicePolicyManager.wipeData() API ของผู้ใช้หลักเรียกใช้
  • อาจมีตัวเลือกการล้างข้อมูลอย่างรวดเร็วที่ดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการเปิดเครื่องที่ปลอดภัย

Android มีโหมดการรีบูตอย่างปลอดภัย ซึ่งอนุญาตให้ผู้ใช้รีบูตเข้าสู่โหมดที่อนุญาตให้เฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่ทำงานได้ และปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการบูตอย่างปลอดภัย" ซึ่งช่วยให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การติดตั้งใช้งานอุปกรณ์มีดังนี้

  • [SR] ขอแนะนำอย่างยิ่งให้ใช้โหมดการเปิดเครื่องที่ปลอดภัย

หากการติดตั้งใช้งานอุปกรณ์ใช้โหมดการเริ่มต้นระบบที่ปลอดภัย อุปกรณ์จะทำสิ่งต่อไปนี้

  • [C-1-1] ต้องมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยในลักษณะที่แอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ไม่สามารถขัดขวางได้ เว้นแต่ว่าแอปของบุคคลที่สามจะเป็นตัวควบคุมนโยบายอุปกรณ์และได้ตั้งค่าสถานะ UserManager.DISALLOW_SAFE_BOOT เป็นจริง

  • [C-1-2] ต้องให้ความสามารถแก่ผู้ใช้ในการถอนการติดตั้งแอปของบุคคลที่สามในโหมดปลอดภัย

  • ควรมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดการเริ่มต้นระบบแบบปลอดภัยจากเมนูการเริ่มต้นระบบโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการเริ่มต้นระบบปกติ

9.14. การแยกระบบยานยนต์

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายยานพาหนะ เช่น CAN Bus

การแลกเปลี่ยนข้อมูลสามารถรักษาความปลอดภัยได้โดยการใช้ฟีเจอร์ความปลอดภัยที่อยู่ใต้เลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายหรือไม่ตั้งใจกับระบบย่อยเหล่านี้

9.15. แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ในการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

  • [C-0-1] ต้องแสดงแพ็กเกจการสมัครใช้บริการเฉพาะในแอปของผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจดังกล่าวตั้งแต่แรกเท่านั้น
  • [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
  • [C-0-3] ต้องอนุญาตการลบล้าง เช่น SubscriptionManager.setSubscriptionOverrideCongested() จากแอปผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจการสมัครใช้บริการที่ถูกต้องในปัจจุบันเท่านั้น

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] ต้องแสดงข้อบ่งชี้ว่าอุปกรณ์ต้นทางได้ย้ายข้อมูลโดยการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งในเมนูการตั้งค่า ผู้ใช้ไม่ควรนำข้อบ่งชี้นี้ออกได้

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าแพ็กเกจการทดสอบซอฟต์แวร์ไม่มีแพ็กเกจใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ทำการเปลี่ยนแปลงจำนวนน้อยที่สุดเท่าที่จะเป็นไปได้ในการติดตั้งใช้งานอ้างอิงและที่ต้องการของ Android ซึ่งพร้อมให้บริการจากโครงการโอเพนซอร์ส Android ซึ่งจะช่วยลดความเสี่ยงในการทำให้เกิดข้อบกพร่องที่สร้างความไม่เข้ากันซึ่งต้องมีการแก้ไขและอาจต้องมีการอัปเดตอุปกรณ์

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android ที่พร้อมใช้งานจากโปรเจ็กต์โอเพนซอร์สของ Android โดยใช้ซอฟต์แวร์การจัดส่งขั้นสุดท้ายในอุปกรณ์

  • [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความคลุมเครือใน CTS และสำหรับการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงกลับมาใช้ใหม่

CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง เช่นเดียวกับซอฟต์แวร์อื่นๆ CTS อาจมีข้อบกพร่องในตัว CTS จะมีการกำหนดเวอร์ชันแยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS หลายฉบับสำหรับ Android 11

การติดตั้งใช้งานอุปกรณ์

  • [C-0-3] ต้องผ่าน CTS เวอร์ชันล่าสุดที่พร้อมใช้งานในขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

  • ควรใช้การติดตั้งใช้งานอ้างอิงในโครงสร้าง Android Open Source ให้มากที่สุด

10.2. โปรแกรมตรวจสอบ CTS

CTS Verifier รวมอยู่ใน Compatibility Test Suite และมีไว้ให้ผู้ปฏิบัติงานที่เป็นมนุษย์เรียกใช้เพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานที่ถูกต้องของกล้องและเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

  • [C-0-1] ต้องเรียกใช้กรณีที่เกี่ยวข้องทั้งหมดใน CTS Verifier อย่างถูกต้อง

CTS Verifier มีการทดสอบสำหรับฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ

การติดตั้งใช้งานอุปกรณ์

  • [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง อุปกรณ์ต้องเรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง

ระบบอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่เอกสารนิยามความเข้ากันได้นี้ระบุว่าเป็นฟีเจอร์ที่ไม่บังคับ

  • [C-0-2] อุปกรณ์และบิลด์ทุกรายการต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก เราจึงไม่คาดหวังให้ผู้ติดตั้งใช้งานอุปกรณ์เรียกใช้ CTS Verifier อย่างชัดเจนในบิลด์ที่แตกต่างกันเพียงเล็กน้อย กล่าวโดยเจาะจงคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่าน CTS Verifier เฉพาะชุดภาษาที่รวมไว้ การสร้างแบรนด์ ฯลฯ อาจข้ามการทดสอบ CTS Verifier ได้

11. ซอฟต์แวร์ที่อัปเดตได้

  • [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" ซึ่งหมายความว่าอาจต้องรีสตาร์ทอุปกรณ์ คุณใช้วิธีใดก็ได้ตราบใดที่สามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการต่อไปนี้จะตรงตามข้อกำหนดนี้

    • การดาวน์โหลด "ผ่านอากาศ (OTA)" พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต
    • การอัปเดตแบบ "เชื่อมต่อ" ผ่าน USB จาก PC โฮสต์
    • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในที่เก็บข้อมูลแบบถอดได้

  • [C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แอปพลิเคชันแชร์ โปรดทราบว่าซอฟต์แวร์ Android ต้นทางมีกลไกการอัปเดตที่ตรงตามข้อกำหนดนี้

  • [C-0-3] การอัปเดตทั้งหมดต้องได้รับการลงนาม และกลไกการอัปเดตในอุปกรณ์ต้องยืนยันการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์

  • [C-SR] ขอแนะนำอย่างยิ่งให้กลไกการลงนามแฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

หากการใช้งานอุปกรณ์รวมถึงการรองรับการเชื่อมต่ออินเทอร์เน็ตแบบไม่จำกัด เช่น โปรไฟล์ 802.11 หรือ Bluetooth PAN (เครือข่ายส่วนบุคคล) อุปกรณ์จะต้องมีคุณสมบัติดังนี้

  • [C-1-1] ต้องรองรับการดาวน์โหลด OTA พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต

สำหรับการติดตั้งใช้งานอุปกรณ์ที่เปิดตัวด้วย Android 6.0 ขึ้นไป กลไกการอัปเดตควรจะรองรับการยืนยันว่าอิมเมจของระบบเป็นไบนารีที่เหมือนกับผลลัพธ์ที่คาดไว้หลังจากการอัปเดตผ่าน OTA การติดตั้งใช้งาน OTA แบบบล็อกในโครงการโอเพนซอร์ส Android ต้นทาง ซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้

นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ควรจะรองรับการอัปเดตระบบ A/B AOSP จะใช้ฟีเจอร์นี้โดยใช้ HAL ของการควบคุมการบูต

หากพบข้อผิดพลาดในการติดตั้งใช้งานอุปกรณ์หลังจากที่เผยแพร่แล้ว แต่ยังอยู่ในช่วงอายุการใช้งานผลิตภัณฑ์ที่สมเหตุสมผลซึ่งกำหนดขึ้นโดยการปรึกษากับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม ให้ดำเนินการดังนี้

  • [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่พร้อมใช้งานซึ่งสามารถใช้ได้ตามกลไกที่อธิบายไว้ข้างต้น

Android มีฟีเจอร์ที่ช่วยให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบได้ หากระบบย่อยการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin แสดงว่าอุปกรณ์มีลักษณะดังนี้

  • [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

สรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้

สรุปการเปลี่ยนแปลงในแต่ละส่วนมีดังนี้

  1. บทนำ
  2. ประเภทอุปกรณ์
  3. ซอฟต์แวร์
  4. การแพ็กเกจแอปพลิเคชัน
  5. มัลติมีเดีย
  6. เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
  7. ความเข้ากันได้ของฮาร์ดแวร์
  8. ประสิทธิภาพและกำลัง
  9. โมเดลความปลอดภัย
  10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
  11. ซอฟต์แวร์ที่อัปเดตได้
  12. บันทึกการเปลี่ยนแปลงของเอกสาร
  13. ติดต่อเรา

12.1 เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง

การเปลี่ยนแปลงจะมีการทำเครื่องหมายดังนี้

  • CDD
    การเปลี่ยนแปลงที่สำคัญต่อข้อกำหนดความเข้ากันได้

  • เอกสาร
    การเปลี่ยนแปลงที่เกี่ยวข้องกับการสร้างหรือการเสริมความงาม

เพื่อการรับชมที่ดีที่สุด ให้เพิ่มพารามิเตอร์ของ URL pretty=full และ no-merges ลงใน URL ของบันทึกการเปลี่ยนแปลง

13. ติดต่อเรา

คุณเข้าร่วมฟอรัมความเข้ากันได้ของ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ได้กล่าวถึงได้