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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์ต่อไปนี้สำหรับรหัส HID

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

• [7.8.2.2/H-1-2] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่ต้องหลังจากที่อินเทอร์เฟซเสียงและปลายทาง USB ได้รับการระบุอย่างถูกต้องแล้วเพื่อระบุประเภทของขั้วต่อที่เชื่อมต่อ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.10/H]* ควรยืนยันสถานะการติดตั้งใช้งานโดยเรียกใช้ API ของ android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitivesSupported()

• [7.10/H]* ควรทำการประเมินคุณภาพสำหรับค่าคงที่ของการสัมผัส

• [7.10/H]* ควรตรวจสอบและอัปเดตการกำหนดค่าสำรองสำหรับองค์ประกอบพื้นฐานที่ไม่รองรับหากจำเป็นตามที่อธิบายไว้ในคำแนะนำการใช้งานสำหรับค่าคงที่

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

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

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

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

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

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

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

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

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

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

• [3.9/H-1-1] ต้องปฏิบัติตามนโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่ระบุไว้ในเอกสารประกอบของ Android SDK

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

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

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

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

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

• [3.8.16/H-2-1] ต้องรายงาน null สำหรับ ControlsProviderService และ Control API
• [3.8.16/H-2-2] ต้องประกาศ Flag android.software.controls ของฟีเจอร์ และตั้งค่าเป็น false

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.5.4/H-1-1] ต้องปฏิบัติตาม Intent ของ android.media.action.STILL_IMAGE_CAMERA และ android.media.action.STILL_IMAGE_CAMERA_SECURE และเปิดกล้องในโหมดภาพนิ่งตามที่อธิบายไว้ใน SDK
• [7.5.4/H-1-2] ต้องปฏิบัติตามandroid.media.action.VIDEO_CAMERA ความตั้งใจที่จะเปิดกล้องในโหมดวิดีโอตามที่อธิบายไว้ใน SDK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [6.1/H-0-1]* ต้องรองรับคำสั่งเชลล์ 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. คลาสประสิทธิภาพสื่อในอุปกรณ์เคลื่อนที่

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

2.2.7.1. สื่อ

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

• ต้องเป็นไปตามข้อกำหนดด้านสื่อที่ระบุไว้ใน CDD ของ Android 13 ส่วน 2.2.7.1

2.2.7.2. กล้อง

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

• ต้องเป็นไปตามข้อกำหนดด้านสื่อที่ระบุไว้ใน CDD ของ Android 13 ส่วน 2.2.7.2

2.2.7.3. ฮาร์ดแวร์

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

• ต้องเป็นไปตามข้อกำหนดด้านสื่อที่ระบุไว้ใน CDD ของ Android 13 ส่วน 2.2.7.3

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

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

• ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพที่ระบุไว้ใน CDD ของ Android 13 ส่วน 2.2.7.4

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

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

  • 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
  • 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-1] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส H.264 ของวิดีโอความละเอียด 720p และ 1080p ที่ 30 เฟรมต่อวินาที

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [8.3/T-1-2] ต้องลงทะเบียนอุปกรณ์เป็นอุปกรณ์แบบไม่มีแบตเตอรี่ตามที่อธิบายไว้ในการรองรับอุปกรณ์แบบไม่มีแบตเตอรี่

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.3. ซอฟต์แวร์

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

• [3/W-0-1] MUST declare the feature android.hardware.type.watch
• [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH
• [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงไว้ที่นี่

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มี 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-1] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการ Assist

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

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

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

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

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

• [3.9.3/A-1-1] ต้องติดตั้งใช้งานพร็อพเพอร์ตี้วงจรของลูกค้าทั้งหมด
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER

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

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

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

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

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

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

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

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

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

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

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

• [9.5/A-1-1] ต้องไม่อนุญาตให้ผู้ใช้โต้ตอบกับระบบหรือเปลี่ยนไปใช้ผู้ใช้ระบบแบบ Headless ยกเว้นการจัดสรรอุปกรณ์
• [9.5/A-1-2] ต้องเปลี่ยนไปเป็นผู้ใช้รองก่อน BOOT_COMPLETED
• [9.5/A-1-3] ต้องรองรับการสร้างผู้ใช้ชั่วคราวแม้ว่าจะมีผู้ใช้ในอุปกรณ์ถึงจำนวนสูงสุดแล้วก็ตาม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. ฮาร์ดแวร์

ไจโรสโคป

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. ซอฟต์แวร์

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

3. ซอฟต์แวร์

3.1 ความเข้ากันได้ของ Managed API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

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

พารามิเตอร์	รายละเอียด
VERSION.RELEASE	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงใดสตริงหนึ่งที่ระบุไว้ในสตริงเวอร์ชันที่อนุญาตสำหรับ Android 14
VERSION.SDK	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 14 ช่องนี้ต้องมีค่าจำนวนเต็ม 14_INT
VERSION.SDK_INT	เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 14 ช่องนี้ต้องมีค่าจำนวนเต็ม 14_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 ความเข้ากันได้ของ API เดิม
CPU_ABI	ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API
CPU_ABI2	ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ API เดิม
อุปกรณ์	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
FINGERPRINT	สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้ $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) เช่น acme/myproduct/     mydevice:14/LMYXX/3359:userdebug/test-keys ลายนิ้วมือต้องไม่มีอักขระช่องว่าง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้
ฮาร์ดแวร์	ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งเคอร์เนลหรือ /proc) ควรอ่านออกได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$"
โฮสต์	สตริงที่ระบุโฮสต์ที่ใช้สร้างบิลด์อย่างเจาะจงในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("")
รหัส	ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างอิงถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ช่องนี้อาจเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายมากพอที่ผู้ใช้ปลายทางจะแยกความแตกต่างระหว่างบิลด์ซอฟต์แวร์ได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+$"
ผู้ผลิต	ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC_MANUFACTURER	ชื่อทางการค้าของผู้ผลิตระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SoC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ ต้องตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ]+)" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
SOC_MODEL	ชื่อรุ่นของระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีรุ่น SOC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ._/+-]+)$" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
MODEL	ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่ใช้ในการทําการตลาดและขายอุปกรณ์แก่ผู้ใช้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ผลิตภัณฑ์	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) และต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องอ่านออกได้ แต่ไม่จำเป็นต้องมีไว้ให้ผู้ใช้ปลายทางดู ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์
ODM_SKU	ค่าที่ไม่บังคับซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือก โดยมี SKU (Stock Keeping Unit) ที่ใช้ติดตามการกำหนดค่าที่เฉพาะเจาะจงของอุปกรณ์ เช่น อุปกรณ์ต่อพ่วงที่รวมอยู่กับอุปกรณ์เมื่อขาย ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z.,_-]+)$
SERIAL	ต้องแสดงผลเป็น "UNKNOWN"
แท็ก	รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม แท็กต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys และ test-keys
เวลา	ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น
ประเภท	ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าอย่างใดอย่างหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ user, userdebug หรือ eng
ผู้ใช้	ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("")
SECURITY_PATCH	ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์ไม่มีช่องโหว่ใดๆ เกี่ยวกับปัญหาที่อธิบายไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สำหรับสาธารณะ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กําหนดไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สําหรับสาธารณะหรือใน คําแนะนําด้านความปลอดภัยของ Android เช่น "2015-11-01"
BASE_OS	ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิวด์ที่เหมือนกันกับบิวด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android และต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("")
BOOTLOADER	ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุเวอร์ชัน Bootloader ภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+$"
getRadioVersion()	ต้อง (เป็นหรือแสดงผล) ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกไว้ ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$"
getSerial()	ต้องเป็น (หรือแสดง) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9]+$"

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

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

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

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

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

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

3.2.3.2. การแก้ไข Intent

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

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

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

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

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

• [C-0-4] ต้องพยายามตรวจสอบตัวกรอง Intent โดยทำตามขั้นตอนการตรวจสอบที่ระบุไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัลตามที่ Package Manager นำมาใช้ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
• [C-0-5] ต้องพยายามตรวจสอบตัวกรอง Intent ในระหว่างการติดตั้งแอปพลิเคชันและตั้งค่าตัวกรอง Intent ของ URI ทั้งหมดที่ตรวจสอบเรียบร้อยแล้วเป็นตัวจัดการแอปเริ่มต้นสำหรับ URI ของแอป
• อาจตั้งค่าตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงเป็นตัวจัดการแอปเริ่มต้นสำหรับ URI ของแอปนั้นๆ หากได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นๆ ที่เป็นไปได้ไม่ได้รับการยืนยัน หากการใช้งานอุปกรณ์ทําเช่นนี้ อุปกรณ์ต้องระบุการลบล้างรูปแบบต่อ URI ที่เหมาะสมสําหรับผู้ใช้ในเมนูการตั้งค่า
• ต้องให้การควบคุม App Link ต่อแอปแก่ผู้ใช้ในการตั้งค่า ดังนี้
  • [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทํางานของลิงก์แอปเริ่มต้นโดยรวมเพื่อให้แอปเปิดเสมอ ถามเสมอ หรือไม่เคยเปิด ซึ่งมีผลกับตัวกรอง Intent ของ URI ทั้งหมดที่เป็นไปได้อย่างเท่าเทียมกัน
  • [C-0-7] ผู้ใช้ต้องดูรายการตัวกรองความตั้งใจของ URI ที่เป็นไปได้ได้
  • การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้สามารถลบล้างตัวกรอง Intent ของ URI ที่เป็นไปได้ซึ่งได้รับการยืนยันเรียบร้อยแล้ว โดยอิงตามตัวกรอง Intent แต่ละรายการ
  • [C-0-8] การติดตั้งใช้งานอุปกรณ์ต้องให้สิทธิ์ผู้ใช้ในการดูและลบล้างตัวกรอง Intent ของ URI ที่เป็นผู้สมัครบางรายการ หากการติดตั้งใช้งานอุปกรณ์ทําให้ตัวกรอง Intent ของ URI ที่เป็นผู้สมัครบางรายการยืนยันสําเร็จ ขณะที่ตัวกรองอื่นๆ ยืนยันไม่สําเร็จ

3.2.3.3. เนมสเปซของ Intent

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

3.2.3.4. เจตนาการออกอากาศ

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

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

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

3.2.3.5. Intent ของแอปพลิเคชันแบบมีเงื่อนไข

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-4-1] ต้องปฏิบัติตาม Intent เหล่านี้ android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED เพื่อแสดงกิจกรรมที่ตรงกับความต้องการของนักพัฒนาแอปสำหรับ Intent เหล่านี้ตามที่อธิบายไว้ใน SDK

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

• [C-5-1] ต้องปฏิบัติตาม Intent ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ และแสดงกิจกรรมของระบบเพื่อให้ผู้ใช้เปิดบลูทูธได้
• [C-5-2] ต้องปฏิบัติตาม Intent "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" และแสดงกิจกรรมของระบบที่ขอโหมดที่ค้นพบได้

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

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

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

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

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

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

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

• [C-9-1] ต้องใช้ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API ตามที่อธิบายไว้ในเอกสารประกอบ SDK

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

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

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

• [C-11-1] ต้องมีกิจกรรมที่จัดการกับ Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS แต่อาจใช้แบบไม่ดำเนินการก็ได้

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

• [C-12-3] ต้องจัดการและอนุญาตให้เฉพาะแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่จะจัดการ Intent ต่อไปนี้ได้ MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE และ MediaStore.ACTION_VIDEO_CAPTURE ตามที่อธิบายไว้ในเอกสาร SDK

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

• [C-13-1] ต้องเป็นไปตามความตั้งใจ android.app.action.ADD_DEVICE_ADMIN ในการเรียกใช้ UI เพื่อนำผู้ใช้ไปยังการเพิ่มผู้ดูแลระบบอุปกรณ์ในระบบ (หรืออนุญาตให้ผู้ใช้ปฏิเสธ)

• [C-13-2] ต้องปฏิบัติตาม Intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION และมีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสําหรับสัญลักษณ์ฟังก์ชันหลักของ Vulkan 1.0 Vulkan 1.1 รวมถึงส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 และ VK_KHR_get_physical_device_properties2 ผ่านไลบรารี libvulkan.so โปรดทราบว่าแม้ว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.2อธิบายข้อกำหนดอย่างละเอียดเพิ่มเติมสำหรับกรณีที่คาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างเต็มรูปแบบ

• ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโครงการโอเพนซอร์ส Android ต้นทาง

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

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

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

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

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

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

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

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

  • วิธีการ SWP และ SWPB
  • การดำเนินการกับสิ่งกีดขวาง CP15ISB, CP15DSB และ CP15DMB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กล่าวคือ

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

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

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

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

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

ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กําหนดเองในภาษาท้องถิ่นนอก NDK API ได้ แต่ API ที่กําหนดเองต้องมีลักษณะดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-3-1] ต้องรายงาน false สำหรับ ShortcutManager.isRequestPinShortcutSupported()

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

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

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

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

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

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

3.8.2. วิดเจ็ต

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

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

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

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

• [C-1-3] ต้องแสดงผลวิดเจ็ตขนาด 4 x 4 ในตารางกริดมาตรฐานได้ ดูรายละเอียดได้ในหลักเกณฑ์การออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK

• อาจรองรับวิดเจ็ตแอปพลิเคชันในหน้าจอล็อก

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

• [C-2-1] ต้องรายงาน true สำหรับ AppWidgetManager.html.isRequestPinAppWidgetSupported()
• [C-2-2] ต้องมีการแสดงข้อมูลให้ผู้ใช้ทราบเพื่อขออนุญาตจากผู้ใช้ก่อนเพิ่มทางลัดที่แอปขอผ่านเมธอด AppWidgetManager.requestPinAppWidget() API

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

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

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

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

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

• [C-1-7] ต้องแสดงผลทรัพยากรทั้งหมด (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่ระบุผ่าน Notification.MessagingStyle อย่างถูกต้องควบคู่ไปกับข้อความการแจ้งเตือนโดยที่ผู้ใช้ไม่ต้องโต้ตอบเพิ่มเติม เช่น ต้องแสดงทรัพยากรทั้งหมด รวมถึงไอคอนที่ระบุผ่าน android.app.Person ในการสนทนากลุ่มที่ตั้งค่าผ่าน setGroupConversation

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกให้ผู้ใช้ควบคุมการแจ้งเตือนที่แสดงต่อแอปที่ได้รับสิทธิ์ Notification Listener ความละเอียดต้องเป็นแบบที่ผู้ใช้สามารถควบคุมประเภทการแจ้งเตือนที่บริดจ์ไปยัง Listener แต่ละรายการดังกล่าวได้ ประเภทต้องรวมถึงการแจ้งเตือน "การสนทนา" "การแจ้งเตือน" "ไม่มีเสียง" และ "ต่อเนื่องที่สำคัญ"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3.2. บริการฟังการแจ้งเตือน

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

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

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

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

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

3.8.3.3. โหมด DND (ห้ามรบกวน) / โหมดสำคัญ

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

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

3.8.4. Assist API

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

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

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

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

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

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

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

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 7 รายการ
• ควรแสดงชื่อกิจกรรมอย่างน้อย 4 รายการพร้อมกัน

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

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

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

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

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

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

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

3.8.11. ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า "ความฝัน")

ดูการตั้งค่าส่วนที่ 3.2.3.5 สำหรับการตั้งใจกำหนดค่าโปรแกรมรักษาหน้าจอ

3.8.12. ตำแหน่ง

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

• [C-1-2] ต้องแสดงสถานะปัจจุบันของตำแหน่งในเมนูตำแหน่งภายในการตั้งค่า
• [C-1-3] ต้องไม่แสดงโหมดตำแหน่งในเมนูตำแหน่งภายในการตั้งค่า

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับหน้าต่าง PIP เมื่อแอปพลิเคชันไม่ได้ประกาศค่าใดๆ สำหรับ AndroidManifestLayout_minWidth และ AndroidManifestLayout_minHeight

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

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

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

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

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

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

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

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

3.8.17. คลิปบอร์ด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ที่ออกอากาศไปยัง DPC ของโปรไฟล์ส่วนบุคคลเมื่อมีการสร้างเจ้าของโปรไฟล์ โดยไม่คำนึงถึงวิธีการจัดสรรที่ใช้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] ต้องรองรับ API ของเฟรมเวิร์ก TTS ของ Android

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

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

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

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

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

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

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

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

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

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

3.14. UI ของสื่อ

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

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

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

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

• [C-1-5] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

3.15. Instant Apps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-0-2] ต้องรองรับการยืนยันไฟล์ ".apk" โดยใช้ APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 และ JAR Signing

• [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik Bytecode หรือ RenderScript Bytecode ในลักษณะที่ทําให้ไฟล์เหล่านั้นติดตั้งและทํางานอย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะต้องรองรับการเข้ารหัสรูปแบบเสียงต่อไปนี้และทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

โปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดต้องรองรับรายการต่อไปนี้

• [C-3-1] เฟรมเสียง PCM 16 บิตตามลำดับไบต์เนทีฟผ่าน android.media.MediaCodec API

5.1.2. การถอดรหัสเสียง

ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงรหัสเสียง

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับฟีเจอร์ android.hardware.audio.output อุปกรณ์นั้นต้องรองรับการถอดรหัสรูปแบบเสียงต่อไปนี้

• [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
• [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
• [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงแล้ว)
• [C-1-4] AAC ELD (AAC แบบลดเวลาหน่วงที่ปรับปรุงแล้ว)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile ซึ่งรวมถึง USAC Baseline Profile และ ISO/IEC 23003-4 Dynamic Range Control Profile)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE รวมถึงรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และ 8 แชนแนล โปรดทราบว่าข้อกำหนดนี้ใช้กับการถอดรหัสเท่านั้น และอุปกรณ์ได้รับอนุญาตให้ลดขนาดและลดคุณภาพเสียงในระหว่างการเล่น
• [C-1-10] Opus

หากการติดตั้งใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมหลายช่อง (นั่นคือมากกว่า 2 ช่อง) เป็น PCM ผ่านโปรแกรมถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec API อุปกรณ์จะต้องรองรับสิ่งต่อไปนี้

• [C-2-1] ต้องมีการถอดรหัสโดยไม่ลดขนาด (เช่น สตรีม AAC 5.0 ต้องถอดรหัสเป็น PCM 5 แชนแนล สตรีม AAC 5.1 ต้องถอดรหัสเป็น PCM 6 แชนแนล)
• [C-2-2] ข้อมูลเมตาช่วงไดนามิกต้องเป็นไปตามที่ระบุไว้ใน "การควบคุมช่วงไดนามิก (DRC)" ใน ISO/IEC 14496-3 และคีย์ android.media.MediaFormat DRC เพื่อกำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ DRC ของ AAC เปิดตัวใน API 21 โดยมีคีย์ดังนี้ KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_ENCODED_TARGET_LEVEL
• [C-SR-1] ขอแนะนำอย่างยิ่งว่าโปรแกรมถอดรหัสเสียง AAC ทั้งหมดต้องเป็นไปตามข้อกำหนด C-2-1 และ C-2-2 ข้างต้น

เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)

• [C-3-1] ข้อมูลเมตาระดับเสียงและ DRC ต้องได้รับการตีความและนำไปใช้ตามโปรไฟล์การควบคุมช่วงไดนามิกแบบไดนามิก (DRC) ระดับ 1 ของ MPEG-D
• [C-3-2] ตัวถอดรหัสต้องทํางานตามการกําหนดค่าที่ระบุด้วยandroid.media.MediaFormatคีย์ต่อไปนี้ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL และ KEY_AAC_DRC_EFFECT_TYPE

ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2

• อาจรองรับการควบคุมระดับเสียงและช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิก ISO/IEC 23003-4

หากระบบรองรับ ISO/IEC 23003-4 และมีข้อมูลเมตาทั้ง ISO/IEC 23003-4 และ ISO/IEC 14496-3 ในบิตสตรีมที่ถอดรหัสแล้ว ระบบจะดำเนินการดังนี้

• ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสําคัญเหนือกว่า

ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุตต่อไปนี้

• [C-6-1] เฟรมเสียง PCM 16 บิตตามลำดับไบต์เนทีฟผ่าน android.media.MediaCodec API

หากการติดตั้งใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมหลายช่อง (นั่นคือมากกว่า 2 ช่อง) เป็น PCM ผ่านโปรแกรมถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec API อุปกรณ์จะต้องรองรับรายการต่อไปนี้

• [C-7-1] แอปพลิเคชันที่ใช้การถอดรหัสต้องกำหนดค่าได้โดยใช้คีย์ KEY_MAX_OUTPUT_CHANNEL_COUNT เพื่อควบคุมว่าจะลดคุณภาพเนื้อหาเป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือส่งออกโดยใช้จำนวนช่องของเนื้อหาต้นฉบับ (เมื่อใช้ค่าเท่ากับหรือมากกว่าจำนวนดังกล่าว) ตัวอย่างเช่น ค่า 6 ขึ้นไปจะกำหนดค่าโปรแกรมถอดรหัสให้ส่งออก 6 ช่องเมื่อป้อนเนื้อหา 5.1
• [C-7-2] เมื่อถอดรหัส ผู้ถอดรหัสต้องแสดงหน้ากากช่องที่ใช้อยู่ในรูปแบบเอาต์พุตด้วยคีย์ KEY_CHANNEL_MASK โดยใช้ค่าคงที่ android.media.AudioFormat (เช่น CHANNEL_OUT_5POINT1)

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมถอดรหัสเสียงอื่นที่ไม่ใช่โปรแกรมถอดรหัสเสียง AAC เริ่มต้นและสามารถส่งออกเสียงหลายช่อง (มากกว่า 2 ช่อง) เมื่อป้อนเนื้อหาหลายช่องที่บีบอัดไว้ ให้ทำดังนี้

• [C-SR-2] ขอแนะนำอย่างยิ่งว่าแอปพลิเคชันที่ใช้การถอดรหัสด้วยคีย์ KEY_MAX_OUTPUT_CHANNEL_COUNT ควรกำหนดค่าโปรแกรมถอดรหัสได้เพื่อควบคุมว่าจะลดคุณภาพเนื้อหาเป็นสเตอริโอ (เมื่อใช้ค่า 2) หรือส่งออกโดยใช้จำนวนช่องแบบดั้งเดิม (เมื่อใช้ค่าเท่ากับหรือมากกว่าจำนวนดังกล่าว) ตัวอย่างเช่น ค่า 6 ขึ้นไปจะกำหนดค่าโปรแกรมถอดรหัสให้ส่งออก 6 ช่องเมื่อป้อนเนื้อหา 5.1
• [C-SR-3] เมื่อถอดรหัส เราขอแนะนำอย่างยิ่งให้โปรแกรมถอดรหัสแสดงหน้ากากช่องที่ใช้กับรูปแบบเอาต์พุตด้วยคีย์ KEY_CHANNEL_MASK โดยใช้ค่าคงที่ android.media.AudioFormat (เช่น CHANNEL_OUT_5POINT1)

5.1.3. รายละเอียดตัวแปลงรหัสเสียง

รูปแบบ/ตัวแปลงรหัส	รายละเอียด	ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
โปรไฟล์ MPEG-4 AAC (AAC LC)	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC ไฟล์ดิบ ADTS (ไม่รองรับ .aac, ADIF) MPEG-TS (.ts, ไม่สามารถกรอได้ ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
โปรไฟล์ MPEG-4 HE AAC (AAC+)	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว)	รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC แบบเวลาในการตอบสนองต่ำที่ปรับปรุงแล้ว)	รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 ถึง 12.2 kbps ที่อัตราตัวอย่าง 8 kHz	3GPP (.3gp)
AMR-WB	9 อัตราตั้งแต่ 6.60 kbit/s ถึง 23.85 kbit/s ที่อัตราตัวอย่าง 16 kHz ตามที่ระบุไว้ที่ AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	สำหรับทั้งโปรแกรมเข้ารหัสและโปรแกรมถอดรหัส: ต้องรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย ต้องรองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง FLAC 24 บิตต้องพร้อมใช้งานด้วยการกําหนดค่าเสียงแบบจุดลอย	FLAC (.flac) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MP3	โมโน/สเตอริโอ 8-320 Kbps แบบคงที่ (CBR) หรืออัตราบิตผันแปร (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MIDI	MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF การรองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody	ประเภท 0 และ 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	การถอดรหัส: รองรับเนื้อหาแบบโมโน สเตอริโอ 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz การเข้ารหัส: รองรับเนื้อหาแบบโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv) Webm (.webm)
PCM/WAVE	ตัวแปลงรหัส PCM ต้องรองรับ PCM แบบเชิงเส้น 16 บิตและแบบลอยตัว 16 บิต โปรแกรมแยกไฟล์ WAVE ต้องรองรับ PCM แบบเชิงเส้น 16 บิต, 24 บิต, 32 บิต และแบบลอยตัว 32 บิต (อัตราสูงสุดที่ฮาร์ดแวร์รองรับ) ต้องรองรับอัตราการสุ่มตัวอย่างตั้งแต่ 8 kHz ถึง 192 kHz	WAVE (.wav)
Opus	การถอดรหัส: รองรับเนื้อหาแบบโมโน สเตอริโอ 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz การเข้ารหัส: รองรับเนื้อหาแบบโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, ถอดรหัสเท่านั้น) Matroska (.mkv) Webm (.webm)

5.1.4. การเข้ารหัสรูปภาพ

ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ

การติดตั้งใช้งานอุปกรณ์ต้องรองรับการเข้ารหัสรูปภาพต่อไปนี้

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

หากการติดตั้งใช้งานอุปกรณ์รองรับการเข้ารหัส HEIC ผ่าน android.media.MediaCodec สำหรับประเภทสื่อ MIMETYPE_IMAGE_ANDROID_HEIC อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องมีตัวแปลงรหัสโปรแกรมเปลี่ยนไฟล์ HEVC ที่เร่งด้วยฮาร์ดแวร์ซึ่งรองรับ BITRATE_MODE_CQ โหมดการควบคุมอัตราบิต HEVCProfileMainStill โปรไฟล์ และขนาดเฟรม 512 x 512 พิกเซล

5.1.5. การถอดรหัสรูปภาพ

ดูรายละเอียดเพิ่มเติมใน 5.1.6 รายละเอียดตัวแปลงรหัสรูปภาพ

การติดตั้งใช้งานอุปกรณ์ต้องรองรับการถอดรหัสการเข้ารหัสรูปภาพต่อไปนี้

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] ดิบ
• [C-0-7] AVIF (Baseline Profile)

หากการติดตั้งใช้งานอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC อุปกรณ์จะต้องมีคุณสมบัติดังนี้ * [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)

ตัวถอดรหัสรูปภาพที่รองรับรูปแบบความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง)

• [C-2-1] ต้องรองรับการแสดงผลรูปแบบที่เทียบเท่า 8 บิตหากแอปพลิเคชันขอ เช่น ผ่านการกำหนดค่า ARGB_8888 ของ android.graphics.Bitmap

5.1.6. รายละเอียดตัวแปลงรหัสรูปภาพ

รูปแบบ/ตัวแปลงรหัส	รายละเอียด	ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
JPEG	Base+progressive	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
แบบข้อมูลดิบ		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ	HEIF (.heif), HEIC (.heic)
AVIF (โปรไฟล์พื้นฐาน)	โปรไฟล์พื้นฐานของรูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ	คอนเทนเนอร์ HEIF (.avif)

ตัวเข้ารหัสและตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API

• [C-1-1] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบยืดหยุ่น (COLOR_FormatYUV420Flexible) ถึง CodecCapabilities

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับโหมดพื้นผิวอินพุต

• [C-1-3] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบแพลแนร์ครึ่งอย่างน้อย 1 รูปแบบ ได้แก่ COLOR_FormatYUV420PackedPlanar (เทียบเท่า COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่า COLOR_FormatYUV420SemiPlanar) ขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

5.1.7. ตัวแปลงรหัสวิดีโอ

• การติดตั้งใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดเพื่อให้ได้คุณภาพที่ยอมรับได้สำหรับบริการสตรีมมิงวิดีโอบนเว็บและการประชุมทางวิดีโอ

หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมถอดรหัสหรือโปรแกรมเปลี่ยนไฟล์วิดีโอ ให้ทำดังนี้

• [C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดบัยบ์บัฟเฟอร์เอาต์พุตและอินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดได้ใหญ่ที่สุดตามมาตรฐานและการกําหนดค่า แต่ต้องไม่จัดสรรเกินขนาด

• [C-1-2] ตัวเข้ารหัสและตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีแบบยืดหยุ่น YUV420 8:8:8 (COLOR_FormatYUV420Flexible) ถึง CodecCapabilities

• [C-1-3] โปรแกรมเปลี่ยนไฟล์วิดีโอและโปรแกรมถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบเซมิแพลแนร์อย่างน้อย 1 รูปแบบ ได้แก่ COLOR_FormatYUV420PackedPlanar (เทียบเท่ากับ COLOR_FormatYUV420Planar) หรือ COLOR_FormatYUV420PackedSemiPlanar (เทียบเท่ากับ COLOR_FormatYUV420SemiPlanar) เราขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ

• [C-SR-1] ขอแนะนำอย่างยิ่งให้โปรแกรมเข้ารหัสและถอดรหัสวิดีโอรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบแพลแนร์ครึ่งที่ฮาร์ดแวร์เพิ่มประสิทธิภาพอย่างน้อย 1 รูปแบบ (YV12, NV12, NV21 หรือรูปแบบที่เพิ่มประสิทธิภาพโดยผู้ให้บริการที่เทียบเท่า)

• [C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง) จะต้องรองรับการแสดงผลรูปแบบเทียบเท่า 8 บิตหากแอปพลิเคชันขอ ซึ่งต้องแสดงโดยรองรับรูปแบบสี YUV420 8:8:8 ผ่าน android.media.MediaCodecInfo

หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตา HDR แบบคงที่

หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh ในคลาส MediaCodecInfo.CodecCapabilities ระบบจะดำเนินการดังนี้

• [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10-60 เฟรม และทำงานได้อย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้

การใช้งานโปรแกรมถอดรหัสวิดีโอจะมีลักษณะดังนี้ เว้นแต่แอปพลิเคชันจะระบุไว้เป็นอย่างอื่นโดยใช้คีย์รูปแบบ KEY_COLOR_FORMAT

• [C-4-1] ต้องตั้งค่าเริ่มต้นเป็นรูปแบบสีที่เพิ่มประสิทธิภาพสำหรับจอแสดงผลฮาร์ดแวร์หากกําหนดค่าโดยใช้เอาต์พุต Surface
• [C-4-2] ต้องตั้งค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพสำหรับการอ่าน CPU หากกำหนดค่าให้ไม่ใช้เอาต์พุต Surface

5.1.8. รายการตัวแปลงรหัสวิดีโอ

รูปแบบ/ตัวแปลงรหัส	รายละเอียด	ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)
H.264 AVC	ดูรายละเอียดได้ที่ส่วนที่ 5.2 และ 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, ไม่สามารถกรอได้) Matroska (.mkv, ถอดรหัสเท่านั้น)
H.265 HEVC	ดูรายละเอียดได้ที่ส่วนที่ 5.3	MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-2	โปรไฟล์หลัก	MPEG2-TS (.ts, ไม่สามารถกรอได้) MPEG-4 (.mp4, ถอดรหัสเท่านั้น) Matroska (.mkv, ถอดรหัสเท่านั้น)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)
VP8	ดูรายละเอียดได้ที่ส่วนที่ 5.2 และ 5.3	WebM (.webm) Matroska (.mkv)
VP9	ดูรายละเอียดได้ที่ส่วนที่ 5.3	WebM (.webm) Matroska (.mkv)
AV1	ดูรายละเอียดที่ส่วนที่ 5.2 และส่วนที่ 5.3	MPEG-4 (.mp4) Matroska (.mkv, ถอดรหัสเท่านั้น)

5.1.9. ความปลอดภัยของตัวแปลงรหัสสื่อ

การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามฟีเจอร์ด้านความปลอดภัยของโค้ดคิวเอดสื่อตามที่อธิบายไว้ด้านล่าง

Android รองรับ OMX ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม รวมถึง Codec 2.0 ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียที่มีค่าใช้จ่ายต่ำ

หากการติดตั้งใช้งานอุปกรณ์รองรับมัลติมีเดีย อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับตัวแปลงรหัสสื่อผ่าน OMX หรือ Codec 2.0 API (หรือทั้ง 2 อย่าง) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android และไม่ปิดใช้หรือหลบเลี่ยงการป้องกันความปลอดภัย ข้อความนี้ไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API แต่หมายความว่าต้องรองรับ API เหล่านี้อย่างน้อย 1 รายการ และการสนับสนุน API ที่พร้อมใช้งานต้องรวมการป้องกันความปลอดภัยไว้ด้วย
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Codec 2.0 API

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Codec 2.0 API อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องใส่โปรแกรมเปลี่ยนรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจากโปรเจ็กต์โอเพนซอร์สของ Android (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละประเภท (โปรแกรมเข้ารหัสหรือโปรแกรมถอดรหัส) ที่อุปกรณ์รองรับ
• [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android
• [C-SR-2] ขอแนะนำอย่างยิ่งให้โปรแกรมเปลี่ยนไฟล์ซอฟต์แวร์ OMX ทำงานในกระบวนการเปลี่ยนไฟล์ที่ไม่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากโปรแกรมแมปหน่วยความจำ

หากการติดตั้งใช้งานอุปกรณ์รองรับ Codec 2.0 API อุปกรณ์จะดำเนินการต่อไปนี้

• [C-3-1] ต้องมีตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ที่เกี่ยวข้องจากโครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละประเภท (โปรแกรมเข้ารหัสหรือโปรแกรมถอดรหัส) ที่อุปกรณ์รองรับ
• [C-3-2] ต้องจัดเก็บโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ Codec 2.0 ในกระบวนการของโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android เพื่อให้สามารถให้สิทธิ์เข้าถึงโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ได้แคบลง
• [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android." ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android

5.1.10. ลักษณะของตัวแปลงรหัสสื่อ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องแสดงค่าที่ถูกต้องของลักษณะเฉพาะของโค้ดคิวสื่อผ่าน MediaCodecInfo API

โดยเฉพาะอย่างยิ่งในเรื่องต่อไปนี้

• [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และต้องมีชื่อที่เป็นไปตามหลักเกณฑ์การตั้งชื่อ OMX IL
• [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ Codec 2.0 API และมีชื่อที่เป็นไปตามหลักเกณฑ์การตั้งชื่อ Codec 2.0 สำหรับ Android
• [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." หรือ "c2.android." ต้องไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นฮาร์ดแวร์ที่เร่งความเร็ว
• [C-1-5] โค้ดที่ทำงานในกระบวนการโค้ด (ผู้ให้บริการหรือระบบ) ที่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากตัวจัดสรรและโปรแกรมแมปหน่วยความจำต้องไม่มีลักษณะเป็นซอฟต์แวร์เท่านั้น
• [C-1-6] โปรแกรมเปลี่ยนรหัสที่ไม่ได้อยู่ในโปรเจ็กต์โอเพนซอร์ส Android หรือไม่อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องระบุว่าเป็น Vendor
• [C-1-7] โปรแกรมเปลี่ยนรหัสที่ใช้การเร่งฮาร์ดแวร์ต้องระบุว่าใช้การเร่งฮาร์ดแวร์
• [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด ตัวอย่างเช่น ตัวแปลงรหัสที่มีชื่อว่า "ตัวถอดรหัส" จะต้องรองรับการถอดรหัส และตัวแปลงรหัสที่มีชื่อว่า "ตัวเข้ารหัส" จะต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อซึ่งมีรูปแบบสื่อต้องรองรับรูปแบบเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสวิดีโอ ให้ทำดังนี้

• [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	176 x 144 พิกเซล (H263, MPEG2, MPEG4) 352 x 288 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4, H263, MPEG2) 320 x 180 พิกเซล (VP8, VP8) 320 x 240 พิกเซล (อื่นๆ)	704 x 576 พิกเซล (H263) 640 x 360 พิกเซล (VP8, VP9) 640 x 480 พิกเซล (โปรแกรมเปลี่ยนไฟล์ MPEG4) 720 x 480 พิกเซล (อื่นๆ, AV1)	1408 x 1152 พิกเซล (H263) 1280 x 720 พิกเซล (อื่นๆ, AV1)	1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4, AV1)	3840 x 2160 พิกเซล (HEVC, VP9, AV1)

• [C-2-2] โปรแกรมเปลี่ยนรหัสวิดีโอที่มีลักษณะเป็นการเร่งฮาร์ดแวร์ต้องเผยแพร่ข้อมูลจุดประสิทธิภาพ โดยแต่ละรายการต้องระบุจุดประสิทธิภาพมาตรฐานที่รองรับทั้งหมด (แสดงอยู่ใน PerformancePoint API) เว้นแต่ว่าจุดประสิทธิภาพมาตรฐานที่รองรับรายการอื่นจะครอบคลุมจุดดังกล่าว
• นอกจากนี้ ควรเผยแพร่จุดประสิทธิภาพเพิ่มเติมหากรองรับประสิทธิภาพวิดีโอที่ยั่งยืนนอกเหนือจากมาตรฐานที่ระบุไว้

5.2 การเข้ารหัสวิดีโอ

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลแบบฝังที่มีความยาวเส้นทแยงมุมอย่างน้อย 2.5 นิ้ว หรือมีพอร์ตเอาต์พุตวิดีโอ หรือประกาศการรองรับกล้องผ่านandroid.hardware.camera.anyฟีเจอร์ Flag อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 หรือ H.264 อย่างน้อย 1 รายการ และทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
• ควรรองรับทั้งโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 และ H.264 รวมถึงทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ H.264, VP8, VP9 หรือ HEVC และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้ แอปพลิเคชันเหล่านั้นจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรองรับบิตเรตที่กำหนดค่าแบบไดนามิกได้
• ควรรองรับอัตราเฟรมที่เปลี่ยนแปลงได้ โดยโปรแกรมเปลี่ยนไฟล์วิดีโอควรกำหนดระยะเวลาเฟรมทันทีตามการประทับเวลาของบัฟเฟอร์อินพุต และจัดสรรที่เก็บบิตตามระยะเวลาเฟรมนั้น

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ MPEG-4 SP และทำให้แอปของบุคคลที่สามใช้งานได้ แอปเหล่านั้นจะทำสิ่งต่อไปนี้

• ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกได้สำหรับโปรแกรมเปลี่ยนไฟล์ที่รองรับ

หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์วิดีโอหรือรูปภาพที่เร่งด้วยฮาร์ดแวร์ และรองรับกล้องฮาร์ดแวร์ที่ต่ออยู่หรือเสียบได้อย่างน้อย 1 ตัวที่แสดงผ่านandroid.camera API ให้ทำดังนี้

• [C-4-1] ตัวแปลงรหัสวิดีโอและรูปภาพที่เร่งด้วยฮาร์ดแวร์ทั้งหมดต้องรองรับการเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์
• ควรรองรับการเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์ผ่านโปรแกรมเปลี่ยนไฟล์วิดีโอหรือโปรแกรมเปลี่ยนไฟล์รูปภาพทั้งหมด

หากการใช้งานอุปกรณ์มีการเข้ารหัส HDR อุปกรณ์จะมีลักษณะดังนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้จัดเตรียมปลั๊กอินสำหรับ API การแปลงรหัสแบบราบรื่นเพื่อแปลงจากรูปแบบ HDR เป็นรูปแบบ SDR

5.2.1. H.263

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์ H.263 และทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม แอปเหล่านั้นจะทำสิ่งต่อไปนี้ได้

• [C-1-1] ต้องรองรับความละเอียด QCIF (176 x 144) ใช้โปรไฟล์พื้นฐานระดับ 45 ความละเอียด SQCIF เป็นตัวเลือกที่ไม่บังคับ
• ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกได้สำหรับโปรแกรมเปลี่ยนไฟล์ที่รองรับ

5.2.2. H.264

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.264 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 อย่างไรก็ตาม การสนับสนุน ASO (การจัดเรียงข้อมูลเป็นชิ้นแบบไม่เจาะจง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (ข้อมูลเป็นชิ้นที่ซ้ำกัน) นั้นไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS สำหรับโปรไฟล์ Baseline เพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android เครื่องอื่นๆ
• [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
• ควรรองรับโปรไฟล์หลักระดับ 4
• ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน Media API อุปกรณ์เหล่านั้นจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p
ความละเอียดของวิดีโอ	320 x 240 พิกเซล	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	20 FPS	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD
• ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ต่อไปนี้
• [C-1-2] ต้องรองรับการเขียนไฟล์ Matroska WebM
• ควรจัดหาตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดการโค้ดฮาร์ดแวร์ RTC ของโปรเจ็กต์ WebM เพื่อให้มั่นใจว่าบริการสตรีมมิงวิดีโอบนเว็บและการประชุมทางวิดีโอมีคุณภาพที่ยอมรับได้

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน Media API อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p
ความละเอียดของวิดีโอ	320 x 180 พิกเซล	640 x 360 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะมีลักษณะดังนี้

• [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
• [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
• [C-1-3] ต้องสร้างข้อมูล CodecPrivate
• ควรรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมเปลี่ยนไฟล์ฮาร์ดแวร์

	SD	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล	3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน Media API ให้ทำดังนี้

• การรองรับรูปแบบ 12 บิตเป็นตัวเลือก

5.2.5. H.265

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3 ที่มีความละเอียดสูงสุด 512 x 512
• ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์ SD 720 x 480 และโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมเปลี่ยนไฟล์เป็นวิดีโอแบบฮาร์ดแวร์

	SD	HD 720p	HD 1080p	UHD
ความละเอียดของวิดีโอ	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล	3840 x 2160 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	30 fps	30 fps
อัตราบิตของวิดีโอ	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3 การถอดรหัสวิดีโอ

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับความละเอียดวิดีโอแบบไดนามิกและการเปลี่ยนอัตราเฟรมผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดแบบเรียลไทม์และสูงสุดถึงความละเอียดที่ตัวแปลงรหัสแต่ละรายการในอุปกรณ์รองรับ

5.3.1. MPEG-2

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมถอดรหัส MPEG-2 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์หลักระดับสูง

5.3.2. H.263

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.263 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 30 (ความละเอียด CIF, QCIF และ SQCIF ที่ 30 fps 384 kbps) และระดับ 45 (ความละเอียด QCIF และ SQCIF ที่ 30 fps 128 kbps)

5.3.3. MPEG-4

หากติดตั้งใช้งานอุปกรณ์ที่มีโปรแกรมถอดรหัส MPEG-4 อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับโปรไฟล์แบบง่ายระดับ 3

5.3.4. H.264

หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมถอดรหัส H.264 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน การรองรับ ASO (การจัดเรียงสไลซ์แบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (สไลซ์ที่ซ้ำกัน) นั้นไม่บังคับ
• [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline และโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
• ควรถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ได้ตามที่ระบุไว้ในตารางต่อไปนี้

หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่าความละเอียดของวิดีโอ การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในตารางต่อไปนี้
• [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในตารางต่อไปนี้

	SD (คุณภาพต่ำ)	SD (คุณภาพสูง)	HD 720p	HD 1080p
ความละเอียดของวิดีโอ	320 x 240 พิกเซล	720 x 480 พิกเซล	1280 x 720 พิกเซล	1920 x 1080 พิกเซล
อัตราเฟรมของวิดีโอ	30 fps	30 fps	60 FPS	30 FPS (60 FPSโทรทัศน์)
อัตราบิตของวิดีโอ	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์ Main ระดับ 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 ผ่าน 'CodecProfileLevel' media API ให้ทำดังนี้

• การรองรับรูปแบบ 12 บิตเป็นตัวเลือก

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) ผ่าน Media API ให้ทำดังนี้

• [C-4-1] การติดตั้งใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็น (KEY_HDR_STATIC_INFO สำหรับโปรไฟล์ HDR ทั้งหมด รวมถึง 'KEY_HDR10_PLUS_INFO' สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชัน นอกจากนี้ เครื่องมือยังต้องรองรับการดึงข้อมูลและแสดงข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์
• [C-4-2] การติดตั้งใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR บนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างเหมาะสม (เช่น HDMI)

5.3.8. Dolby Vision

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับโปรแกรมถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้

• [C-1-1] ต้องมีโปรแกรมแยกที่สามารถแยก Dolby Vision
• [C-1-2] ต้องแสดงเนื้อหา Dolby Vision บนหน้าจออุปกรณ์หรือพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างถูกต้อง (เช่น HDMI)
• [C-1-3] ต้องตั้งค่ารหัสแทร็กของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับรหัสแทร็กของเเลเยอร์ Dolby Vision ที่รวม

5.3.9. AV1

5.4. การบันทึกเสียง

แม้ว่าข้อกำหนดบางประการที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" มาตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ที่ระบุว่า "ควร" ไม่เช่นนั้นอุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต

5.4.1. การบันทึกเสียงดิบและข้อมูลไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบสำหรับสตรีมอินพุต AudioRecord หรือ AAudio ที่เปิดขึ้นสําเร็จ อย่างน้อยที่สุดต้องรองรับลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
  • ช่อง: โมโน
  • แหล่งที่มาของเสียง: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED หรือ VOICE_PERFORMANCE ซึ่งมีผลกับค่ากําหนดล่วงหน้าของอินพุตที่เทียบเท่าใน AAudio ด้วย เช่น AAUDIO_INPUT_PRESET_CAMCORDER

• ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต และ 24 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • ช่อง: ช่องเท่ากับจำนวนไมโครโฟนในอุปกรณ์

• [C-1-2] ต้องบันทึกที่อัตราการสุ่มตัวอย่างข้างต้นโดยไม่ต้องอัปแซมเปิล

• [C-1-3] ต้องมีตัวกรองการลบรอยหยักที่เหมาะสมเมื่อบันทึกอัตราตัวอย่างที่ระบุไว้ข้างต้นด้วยการลดขนาดการสุ่มตัวอย่าง

• ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบคุณภาพระดับวิทยุ AM และ DVD ซึ่งหมายความว่ามีลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
  • ช่อง: สเตอริโอ

• [C-1-4] ต้องปฏิบัติตาม MicrophoneInfo API และป้อนข้อมูลไมโครโฟนที่มีอยู่ในอุปกรณ์อย่างถูกต้องเพื่อให้แอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน AudioManager.getMicrophones() API สำหรับ AudioRecord ที่ใช้งานอยู่โดยใช้ MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED หรือ VOICE_PERFORMANCE หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้บันทึกเนื้อหาเสียงดิบคุณภาพระดับวิทยุ AM และ DVD อุปกรณ์จะดำเนินการดังนี้

• [C-2-1] ต้องบันทึกโดยไม่มีการอัปแซมเปิลที่อัตราส่วนสูงกว่า 16000:22050 หรือ 44100:48000

• [C-2-2] ต้องมีตัวกรองการลบรอยหยักที่เหมาะสมสำหรับการเพิ่มหรือลดขนาด

5.4.2. บันทึกเสียงเพื่อใช้การจดจำเสียง

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ที่อัตราการสุ่มตัวอย่างอย่างใดอย่างหนึ่งต่อไปนี้ 44100 และ 48000
• [C-1-2] ต้องปิดใช้การประมวลผลเสียงแบบลดเสียงรบกวนโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง AudioSource.VOICE_RECOGNITION

• [C-1-3] ต้องปิดใช้การควบคุมอัตราขยายเสียงอัตโนมัติโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง AudioSource.VOICE_RECOGNITION

• ควรแสดงลักษณะความดังเทียบกับความถี่ที่ราบเรียบโดยประมาณในย่านความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

• [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 30 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

• [C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

• ควรตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB (วัดที่ระยะ 30 ซม.จาก ข้าง ไมโครโฟน) ให้เกิดการตอบสนองที่เหมาะเจาะของ RMS 2500 ภายในช่วง 1770 ถึง 3530 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB ±3dB Full Scale สำหรับตัวอย่างทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง

• ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL อินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB จาก -18 dB ถึง +12 dB เทียบกับ SPL 90 dB ที่ไมโครโฟน

• ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยมีความเพี้ยนตามฮาร์โมนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ที่ไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่า android.hardware.microphone และเทคโนโลยีการลดเสียงรบกวน (การลด) ได้รับการปรับแต่งสำหรับการจดจำคำพูด อุปกรณ์จะดำเนินการต่อไปนี้

• [C-2-1] ต้องอนุญาตให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย android.media.audiofx.NoiseSuppressor API
• [C-2-2] ต้องระบุการใช้งานเทคโนโลยีลดเสียงรบกวนแต่ละรายการโดยไม่ซ้ำกันผ่านฟิลด์ AudioEffect.Descriptor.uuid

5.4.3. บันทึกเพื่อเปลี่ยนเส้นทางการเล่น

คลาส android.media.MediaRecorder.AudioSource มีREMOTE_SUBMIXแหล่งที่มาของเสียง

หากการติดตั้งใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output และ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องติดตั้งใช้งานแหล่งที่มาของเสียง REMOTE_SUBMIX อย่างถูกต้องเพื่อให้แอปพลิเคชันใช้ android.media.AudioRecord API เพื่อบันทึกจากแหล่งที่มาของเสียงนี้ โดยบันทึกสตรีมเสียงทั้งหมดยกเว้นสตรีมต่อไปนี้

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. การตัดเสียงก้อง

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

• ควรใช้เทคโนโลยีตัวตัดเสียงก้อง (AEC) ที่ปรับแต่งมาเพื่อการสื่อสารด้วยเสียงและใช้กับเส้นทางการบันทึกเมื่อบันทึกโดยใช้ AudioSource.VOICE_COMMUNICATION

หากการติดตั้งใช้งานอุปกรณ์มีการตัดเสียงสะท้อนแบบอะคูสติกซึ่งแทรกอยู่ในเส้นทางเสียงที่บันทึกเมื่อเลือก AudioSource.VOICE_COMMUNICATION ระบบจะดำเนินการต่อไปนี้

• [C-SR-1] เราขอแนะนำอย่างยิ่งให้ประกาศผ่านเมธอด AcousticEchoCanceler ของ AcousticEchoCanceler.isAvailable() ใน API
• [C-SR-2] ขอแนะนำอย่างยิ่งให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย AcousticEchoCanceler API
• [C-SR-3] ขอแนะนำอย่างยิ่งให้ระบุการใช้งานเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกันผ่านช่อง AudioEffect.Descriptor.uuid

5.4.5. การจับภาพพร้อมกัน

หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.microphone การติดตั้งใช้งานจะต้องใช้การบันทึกพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้

• [C-1-1] ต้องอนุญาตให้เข้าถึงไมโครโฟนพร้อมกันโดยบริการการช่วยเหลือพิเศษที่บันทึกด้วย AudioSource.VOICE_RECOGNITION และแอปพลิเคชันที่บันทึกด้วย AudioSource อย่างน้อย 1 แอป
• [C-1-2] ต้องอนุญาตให้แอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งมีบทบาท Assistant และแอปพลิเคชันอย่างน้อย 1 แอปที่บันทึกด้วย AudioSource ยกเว้น AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER เข้าถึงไมโครโฟนพร้อมกัน
• [C-1-3] ต้องปิดเสียงการบันทึกเสียงสำหรับแอปพลิเคชันอื่นๆ ทั้งหมด ยกเว้นบริการการช่วยเหลือพิเศษ ขณะที่แอปพลิเคชันกำลังบันทึกด้วย AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER อย่างไรก็ตาม เมื่อแอปหนึ่งบันทึกผ่าน AudioSource.VOICE_COMMUNICATION แอปอื่นจะบันทึกเสียงการโทรได้หากเป็นแอปที่มีสิทธิ์ (ติดตั้งไว้ล่วงหน้า) ที่มีสิทธิ์ CAPTURE_AUDIO_OUTPUT
• [C-1-4] หากแอปพลิเคชัน 2 แอปขึ้นไปกำลังบันทึกพร้อมกันและหากแอปไม่มี UI แสดงอยู่ด้านบน แอปที่เริ่มบันทึกล่าสุดจะได้รับเสียง

5.5. การเล่นเสียง

Android รองรับการอนุญาตให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงตามที่ระบุไว้ในส่วนที่ 7.8.2

5.5.1. การเล่นเสียงดิบ

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้

  • รูปแบบต้นฉบับ: Linear PCM, 16 บิต, 8 บิต, ฟลอยท์
  • ช่อง: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องที่ถูกต้องซึ่งมีได้สูงสุด 8 ช่อง
  • อัตราการสุ่มตัวอย่าง (เป็น Hz)
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
    • 96000 แบบโมโนและสเตอริโอ

5.5.2. เอฟเฟกต์เสียง

Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.audio.output ระบบจะดำเนินการดังนี้

• [C-1-1] ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมผ่านคลาสย่อย AudioEffect Equalizer และ LoudnessEnhancer
• [C-1-2] ต้องรองรับการติดตั้งใช้งาน Visualizer API ซึ่งควบคุมได้ผ่านคลาส Visualizer
• [C-1-3] ต้องรองรับการใช้งาน EFFECT_TYPE_DYNAMICS_PROCESSING ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect DynamicsProcessing

• ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์แบบทศนิยมและแบบหลายช่อง

5.5.3. ระดับเสียงเอาต์พุตเสียง

การติดตั้งใช้งานอุปกรณ์ยานยนต์

• ควรอนุญาตให้ปรับระดับเสียงแยกกันสำหรับสตรีมเสียงแต่ละรายการโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่ระบุโดย AudioAttributes และการใช้งานระบบเสียงรถยนต์ตามที่ระบุแบบสาธารณะใน android.car.CarAudioManager

5.5.4. การโอนข้อมูลเสียง

หากการติดตั้งใช้งานอุปกรณ์รองรับการเล่นที่ส่งผ่านข้อมูลเสียง อุปกรณ์จะดำเนินการต่อไปนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัดเนื้อหาเสียงแบบเล่นต่อเนื่องระหว่างคลิป 2 คลิปที่มีรูปแบบเดียวกันเมื่อระบุโดย AudioTrack gapless API และคอนเทนเนอร์สื่อสำหรับ MediaPlayer

5.6. เวลาในการตอบสนองของเสียง

เวลาในการตอบสนองของเสียงคือความล่าช้าของเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองที่สั้นเพื่อให้ได้เสียงเอฟเฟกต์แบบเรียลไทม์

ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้

• เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมข้อมูลที่เข้ารหัส PCM และเวลาที่เสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์ หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสามารถสังเกตได้ภายนอก
• เวลาในการตอบสนองของเอาต์พุตแบบไม่อุ่นเครื่อง เวลาที่ผ่านไประหว่างการเริ่มสตรีมเอาต์พุตกับเวลาแสดงเฟรมแรกตามการประทับเวลา เมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดอยู่ก่อนคำขอ
• เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมต่อๆ ไปหลังจากอุปกรณ์เล่นเสียง
• เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่เสียงจากสภาพแวดล้อมส่งไปยังอุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต และแอปพลิเคชันอ่านเฟรมข้อมูลที่เข้ารหัส PCM ที่เกี่ยวข้อง
• ข้อมูลเข้าสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้งานไม่ได้หรือใช้งานไม่ได้
• เวลาในการตอบสนองของอินพุตแบบ Cold เวลาที่ผ่านไประหว่างที่เริ่มสตรีมกับเวลาที่ระบบได้รับเฟรมแรกที่ถูกต้อง เมื่อระบบอินพุตเสียงไม่ได้ทำงานและปิดอยู่ก่อนคำขอ

• เวลาในการตอบสนองของการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ ไปขณะที่อุปกรณ์บันทึกเสียง

• เวลาในการตอบสนองแบบไปกลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่องบวกเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องบวกระยะเวลาบัฟเฟอร์ 1 รายการ ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาในการลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต

• OpenSL ES PCM buffer queue API ชุด API OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK

• AAudio Native Audio API ชุด AAudio API ภายใน Android NDK

• การประทับเวลา คู่ที่ประกอบด้วยตําแหน่งเฟรมแบบสัมพัทธ์ภายในสตรีม และเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงในอุปกรณ์ปลายทางที่เกี่ยวข้อง ดูข้อมูลเพิ่มเติมได้ที่ AudioTimestamp

• ข้อบกพร่อง การหยุดชะงักชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง ซึ่งมักเกิดจากบัฟเฟอร์ไม่เพียงพอสำหรับเอาต์พุต บัฟเฟอร์เกินสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนแบบดิจิทัลหรือแบบอนาล็อก

• ความเบี่ยงเบนสัมบูรณ์เฉลี่ย ค่าเฉลี่ยของค่าสัมบูรณ์ของค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า

• เวลาในการตอบสนองของฟีเจอร์แตะเพื่อเปิดเสียง เวลาที่ผ่านไประหว่างที่มีการแตะหน้าจอกับเวลาที่ได้ยินเสียงที่เกิดจากเสียงที่เกิดจากการแตะนั้นในลำโพง

หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.audio.output อุปกรณ์นั้นต้องเป็นไปตามข้อกำหนดต่อไปนี้เป็นอย่างน้อย

• [C-1-1] การประทับเวลาเอาต์พุตที่ AudioTrack.getTimestamp และ AAudioStream_getTimestamp แสดงผลจะมีความแม่นยำ +/- 2 มิลลิวินาที

• [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบ Cold Start ไม่เกิน 500 มิลลิวินาที

• [C-1-3] การเปิดสตรีมเอาต์พุตโดยใช้ AAudioStreamBuilder_openStream() ต้องใช้เวลาไม่เกิน 1,000 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.audio.output เราขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดต่อไปนี้หรือมากกว่า

• [C-SR-1] เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของลำโพง
• [C-SR-2] เวลาในการตอบสนองของฟีเจอร์แตะเพื่อเปิดเสียงไม่เกิน 80 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังจากการปรับเทียบครั้งแรก เมื่อใช้ AAudio Native Audio API สำหรับเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold บนอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อย 1 เครื่อง ข้อมูลต่อไปนี้จะแสดง

• [C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศใช้android.hardware.audio.low_latency Flag ฟีเจอร์
• [C-SR-6] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
• [C-SR-7] ขอแนะนําอย่างยิ่งให้ตรวจสอบว่าสตรีมที่แสดงผล AAUDIO_PERFORMANCE_MODE_LOW_LATENCY จาก AAudioStream_getPerformanceMode() มีค่าที่แสดงผลโดย AAudioStream_getFramesPerBurst() น้อยกว่าหรือเท่ากับค่าที่แสดงผลโดย android.media.AudioManager.getProperty(String) สําหรับคีย์พร็อพเพอร์ตี้ AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER

หากการติดตั้งใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน API เสียงแบบเนทีฟของ AAudio อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

หากการติดตั้งใช้งานอุปกรณ์มี android.hardware.microphone อุปกรณ์นั้นต้องเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

• [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลเป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงความคลาดเคลื่อนจากค่าที่ถูกต้อง
• [C-3-2] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 500 มิลลิวินาที
• [C-3-3] การเปิดสตรีมอินพุตโดยใช้ AAudioStreamBuilder_openStream() ต้องใช้เวลาไม่เกิน 1,000 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์มี android.hardware.microphone เราขอแนะนำอย่างยิ่งให้อุปกรณ์ดังกล่าวเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

• [C-SR-8] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของไมโครโฟน

• [C-SR-11] จำกัดข้อผิดพลาดในการประทับเวลาของอินพุตตามที่แสดงผลโดย AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp เป็น +/- 1 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output และ android.hardware.microphone อุปกรณ์จะมีลักษณะดังนี้

• [C-SR-12] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองไป-กลับแบบต่อเนื่องเฉลี่ยไม่เกิน 50 มิลลิวินาทีในการวัด 5 ครั้ง โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง

5.7. โปรโตคอลเครือข่าย

การติดตั้งใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

สำหรับแต่ละรูปแบบโค้ดและคอนเทนเนอร์ที่การติดตั้งใช้งานอุปกรณ์ต้องรองรับ การติดตั้งใช้งานอุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรองรับตัวแปลงสัญญาณหรือคอนเทนเนอร์นั้นผ่าน HTTP และ HTTPS

• [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่เกี่ยวข้องตามที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างในโปรโตคอลฉบับร่าง HTTP Live Streaming เวอร์ชัน 7

• [C-1-3] ต้องรองรับรูปแบบเพย์โหลด RTSP ที่เกี่ยวข้องตามที่แสดงในตาราง RTSP ด้านล่าง ดูข้อยกเว้นได้ที่เชิงอรรถของตารางในส่วนที่ 5.1

รูปแบบกลุ่มสื่อ

รูปแบบกลุ่ม	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
MPEG-2 Transport Stream	ISO 13818	ตัวแปลงรหัสวิดีโอ: H264 AVC MPEG-4 SP MPEG-2 ดูรายละเอียดเกี่ยวกับ H264 AVC, MPEG2-4 SP, และ MPEG-2 ได้ที่ส่วนที่ 5.1.8 ตัวแปลงรหัสเสียง AAC ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3	ISO 13818-7	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1
WebVTT	WebVTT

RTSP (RTP, SDP)

ชื่อโปรไฟล์	ข้อมูลอ้างอิง	การรองรับตัวแปลงรหัสที่จำเป็น
H264 AVC	RFC 6184	ดูรายละเอียดเกี่ยวกับ H264 AVC ได้ที่ส่วนที่ 5.1.8
MP4A-LATM	RFC 6416	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
H263-1998	RFC 3551 RFC 4629 RFC 2190	ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8
H263-2000	RFC 4629	ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8
AMR	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-NB ได้ที่ส่วนที่ 5.1.3
AMR-WB	RFC 4867	ดูรายละเอียดเกี่ยวกับ AMR-WB ได้ที่ส่วนที่ 5.1.3
MP4V-ES	RFC 6416	ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ได้ที่ส่วนที่ 5.1.8
mpeg4-generic	RFC 3640	ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3
MP2T	RFC 2250	ดูรายละเอียดได้ที่ MPEG-2 Transport Stream ในส่วน HTTP Live Streaming

5.8 Secure Media

หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพลตฟอร์มที่ปลอดภัย อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องประกาศรองรับ Display.FLAG_SECURE

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE และรองรับโปรโตคอลจอแสดงผลไร้สาย อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกการเข้ารหัสที่มีประสิทธิภาพ เช่น HDCP 2.x ขึ้นไปสำหรับจอภาพที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE และรองรับจอแสดงผลภายนอกแบบใช้สาย อุปกรณ์จะมีลักษณะดังนี้

• [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อผ่านพอร์ตแบบใช้สายที่ผู้ใช้เข้าถึงได้

5.9. Musical Instrument Digital Interface (MIDI)

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager ระบบจะดำเนินการดังนี้

• [C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมดสำหรับการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป ซึ่งการรับส่งดังกล่าว ได้แก่

  • โหมดโฮสต์ 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 เวลาในการตอบสนองของเสียงไม่เกิน 25 มิลลิวินาทีผ่านเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
• [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
• [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
• [C-1-5] ต้องเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองและเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio และ AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
• [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
• [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 200 มิลลิวินาที

• [C-1-8] ต้องมีเวลาในการตอบสนองโดยเฉลี่ยจากการแตะเพื่อเปิดเสียงที่ 80 มิลลิวินาทีหรือน้อยกว่าจากค่าการวัดอย่างน้อย 5 ครั้งในเส้นทางข้อมูลจากลำโพงไปยังไมโครโฟน

• [C-SR-1] ขอแนะนำอย่างยิ่งให้มีค่าเวลาในการตอบสนองตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียง ซึ่งมีค่าไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้ง โดยค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางจากลำโพงไปยังไมโครโฟน

• [C-SR-2] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดของเสียงระดับมือโปรสำหรับเวลาในการตอบสนองของเสียงแบบไปกลับอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตแบบ Cold และเวลาในการตอบสนองของเอาต์พุตแบบ Cold รวมถึงข้อกำหนดของเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP

• [C-SR-3] ขอแนะนำอย่างยิ่งให้รักษาระดับประสิทธิภาพของ CPU ให้สม่ำเสมอขณะที่เสียงทำงานอยู่และภาระงานของ CPU แตกต่างกันไป คุณควรทดสอบโดยใช้แอป Android SynthMark SynthMark ใช้โปรแกรมสังเคราะห์เสียงซอฟต์แวร์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองซึ่งวัดประสิทธิภาพของระบบ ดูคำอธิบายการเปรียบเทียบได้จากเอกสารประกอบ SynthMark แอป SynthMark ต้องทำงานโดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้

  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

• ควรลดความคลาดเคลื่อนและการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน

• ควรลดการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่

• ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์

• ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB

• ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในเส้นทางทั้งหมด

• ควรลดการกระตุกของเวลาในการป้อนข้อมูล Callback เมื่อบัฟเฟอร์เสียงเล่นจนจบ เนื่องจากเวลานี้ส่งผลต่อเปอร์เซ็นต์แบนด์วิดท์ของ CPU ทั้งหมดที่ Callback ใช้งานได้

• ควรไม่มีข้อบกพร่องของเสียงเมื่อใช้งานตามปกติโดยมีเวลาในการตอบสนองตามที่รายงาน

• ควรให้เวลาในการตอบสนองระหว่างแชแนลเป็น 0

• ควรลดเวลาในการตอบสนองเฉลี่ยของ MIDI ในการขนส่งทั้งหมด

• ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI เมื่อโหลด (การกระตุก) บนทรานสปอร์ตทั้งหมด

• ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการขนส่งทั้งหมด

• ควรลดสัญญาณรบกวนทางเสียงจากทรานสดิวเซอร์ในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจากการเริ่มต้นระบบเย็น

• ควรระบุความแตกต่างของนาฬิกาเสียงเป็น 0 ระหว่างฝั่งอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 ฝั่งทำงานอยู่ ตัวอย่างอุปกรณ์ปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตของช่องเสียบเสียง

• ควรจัดการการเรียกกลับเมื่อบัฟเฟอร์เสียงเสร็จสมบูรณ์สำหรับฝั่งอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้องในเธรดเดียวกันเมื่อทั้ง 2 ฝั่งทำงานอยู่ และเข้าสู่การเรียกกลับเอาต์พุตทันทีหลังจากการกลับมาจากการเรียกกลับอินพุต หรือหากจัดการกับคอลแบ็กในเธรดเดียวกันไม่ได้ ให้ป้อนคอลแบ็กเอาต์พุตหลังจากป้อนคอลแบ็กอินพุตไม่นานเพื่ออนุญาตให้แอปพลิเคชันมีการกำหนดเวลาของฝั่งอินพุตและเอาต์พุตที่สอดคล้องกัน

• ควรลดความแตกต่างของเฟสระหว่างบัฟเฟอร์เสียง HAL สำหรับอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้อง

• ควรลดเวลาในการตอบสนองต่อการสัมผัส

• ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระ (การกระตุก)

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด อุปกรณ์จะมีคุณสมบัติดังนี้

• [C-SR-4] ขอแนะนําอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager

หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย อุปกรณ์จะต้องมีลักษณะดังนี้

• [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องโดยเฉลี่ยตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียงไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางช่องเสียบเสียงโดยใช้ดองเกิลการบันทึกเสียง

• [C-SR-5] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดเฉพาะของอุปกรณ์เคลื่อนที่ (แจ็ค) ของข้อกำหนดเฉพาะของหูฟังแบบมีสาย (v1.1)

หากการติดตั้งใช้งานอุปกรณ์ไม่มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB อุปกรณ์ดังกล่าวต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องติดตั้งใช้งานคลาสเสียง USB
• [C-3-2] ต้องมีเวลาในการตอบสนองของเสียงแบบไปกลับต่อเนื่องโดยเฉลี่ยไม่เกิน 25 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB (สามารถวัดโดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์เชื่อมต่ออินพุตกับเอาต์พุต)
• [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 แชนแนลในแต่ละทิศทาง, อัตราตัวอย่าง 96 kHz และความละเอียด 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย
• [C-SR-7] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต HDMI อุปกรณ์จะมีลักษณะดังนี้

• ควรรองรับเอาต์พุตแบบสเตอริโอและ 8 แชนแนลที่ความลึก 20 หรือ 24 บิตและ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มตัวอย่างอีกครั้งในการกำหนดค่าอย่างน้อย 1 รายการ

5.11. จับภาพสำหรับ "ไม่ได้ประมวลผล"

Android รองรับการบันทึกเสียงที่ไม่ได้ผ่านกระบวนการผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES คุณจะเข้าถึงการตั้งค่าล่วงหน้าการบันทึกได้โดยใช้ SL_ANDROID_RECORDING_PRESET_UNPROCESSED

หากการติดตั้งใช้งานอุปกรณ์มีจุดประสงค์เพื่อรองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผลและทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานการรองรับผ่านandroid.media.AudioManager พร็อพเพอร์ตี้ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

• [C-1-2] ต้องมีแอมพลิจูดเทียบกับลักษณะความถี่ที่ราบเรียบโดยประมาณในช่วงความถี่กลาง กล่าวคือ ±10 dB จาก 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

• [C-1-3] ต้องมีระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 5 z ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล

• [C-1-4] ต้องมีระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 7000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล

• [C-1-5] ต้องตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ค่าตอบสนอง RMS 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างแบบทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

• [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดเป็นความแตกต่างระหว่าง 94 dB SPL กับ SPL ที่เทียบเท่าของสัญญาณรบกวนจากตัวอุปกรณ์เอง โดยปรับตามการถ่วงน้ำหนัก A)

• [C-1-7] ต้องมีความผิดเพี้ยนตามฮาร์โมนิก (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล

• [C-1-8] ต้องไม่มีระบบประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมระดับสัญญาณอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงสะท้อน) ในเส้นทาง ยกเว้นตัวคูณระดับเพื่อปรับระดับให้อยู่ในช่วงที่ต้องการให้ได้ กล่าวคือ

  • [C-1-9] หากมีระบบประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม จะต้องปิดใช้ระบบดังกล่าวและเพิ่มเวลาในการตอบสนองเป็น 0 หรือเพิ่มเวลาในการตอบสนองเพิ่มเติมในเส้นทางสัญญาณ
  • [C-1-10] ตัวคูณระดับแม้จะอยู่ในเส้นทางได้ แต่ต้องไม่ทำให้เกิดความล่าช้าหรือเวลาในการตอบสนองในเส้นทางสัญญาณ

การวัด SPL ทั้งหมดจะดำเนินการข้างไมโครโฟนทดสอบโดยตรง สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone แต่ไม่รองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องแสดงผล null สำหรับเมธอด AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API เพื่อบ่งชี้ว่าไม่รองรับอย่างถูกต้อง
• [C-SR-1] เรายังคงขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดมากที่สุดสำหรับเส้นทางสัญญาณของแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล

5.12. วิดีโอ HDR

Android 13 รองรับเทคโนโลยี HDR ตามที่อธิบายไว้ในเอกสารที่กำลังจะเผยแพร่

รูปแบบพิกเซล

หากโปรแกรมถอดรหัสวิดีโอโฆษณารองรับ COLOR_FormatYUVP010 ให้ทำดังนี้

• [C-1-1] ต้องรองรับรูปแบบ P010 สำหรับการอ่านจาก CPU (ImageReader, MediaImage, ByteBuffer) ใน Android 13 จะมีการผ่อนปรน P010 เพื่ออนุญาตให้ใช้ Stride ที่กำหนดเองสำหรับระนาบ Y และ UV

• [C-1-2] GPU ต้องสามารถสุ่มตัวอย่างบัฟเฟอร์เอาต์พุต P010 ได้ (เมื่อจัดสรรการใช้งาน GPU_SAMPLING) ซึ่งจะช่วยให้แอปใช้การจัดองค์ประกอบ GPU และการปรับโทนสีที่กำหนดเองได้

หากโปรแกรมถอดรหัสวิดีโอโฆษณาว่ารองรับ COLOR_Format32bitABGR2101010 โปรแกรมจะมีลักษณะดังนี้

• [C-2-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับพื้นผิวเอาต์พุตและอ่านได้โดยใช้ CPU (เอาต์พุต ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอโฆษณาว่ารองรับ COLOR_FormatYUVP010 โปรแกรมจะดำเนินการดังนี้

• [C-3-1] ต้องรองรับรูปแบบ P010 สำหรับอินพุตพื้นผิวและอินพุตที่ CPU เขียนได้ (ImageWriter, MediaImage, ByteBuffer)

หากโปรแกรมเปลี่ยนไฟล์วิดีโอโฆษณาว่ารองรับ COLOR_Format32bitABGR2101010 โปรแกรมจะมีลักษณะดังนี้

• [C-4-1] ต้องรองรับรูปแบบ RGBA_1010102 สำหรับอินพุตพื้นผิวและอินพุต (ImageWriter, ByteBuffer) ที่ CPU เขียนได้ หมายเหตุ: ไม่จำเป็นต้องแปลงระหว่างเส้นโค้งการโอนต่างๆ สำหรับโปรแกรมเปลี่ยนไฟล์

ข้อกำหนดในการจับภาพ HDR

สําหรับโปรแกรมเข้ารหัสวิดีโอทั้งหมดที่รองรับโปรไฟล์ HDR การใช้งานอุปกรณ์

• [C-5-1] ต้องไม่ถือว่าข้อมูลเมตา HDR ถูกต้อง เช่น เฟรมที่เข้ารหัสอาจมีพิกเซลที่เกินระดับความสว่างสูงสุด หรือฮิสโตแกรมอาจไม่ได้แสดงถึงเฟรม

• ควรรวบรวมข้อมูลเมตาแบบไดนามิกของ HDR เพื่อสร้างข้อมูลเมตาแบบคงที่ของ HDR ที่เหมาะสมสำหรับสตรีมที่เข้ารหัส และควรแสดงผลข้อมูลเมตาดังกล่าวเมื่อสิ้นสุดเซสชันการเข้ารหัสแต่ละครั้ง

หากการติดตั้งใช้งานอุปกรณ์รองรับการจับภาพ HDR โดยใช้ CamcorderProfile API ระบบจะดำเนินการต่อไปนี้

• [C-6-1] ต้องรองรับการจับภาพ HDR ผ่าน Camera2 API ด้วย

• [C-6-2] ต้องรองรับโปรแกรมเปลี่ยนไฟล์วิดีโอที่เร่งด้วยฮาร์ดแวร์อย่างน้อย 1 รายการสำหรับเทคโนโลยี HDR แต่ละรายการที่รองรับ

• [C-6-3] ต้องรองรับการจับภาพ HLG เป็นอย่างน้อย

• [C-6-4] ต้องรองรับการเขียนข้อมูลเมตา HDR (หากเกี่ยวข้องกับเทคโนโลยี HDR) ลงในไฟล์วิดีโอที่บันทึกไว้ สำหรับ AV1, HEVC และ DolbyVision การดำเนินการนี้หมายถึงการรวมข้อมูลเมตาไว้ในบิตสตรีมที่เข้ารหัส

• [C-6-5] ต้องรองรับ P010 และ COLOR_FormatYUVP010

• [C-6-6] ต้องรองรับการแมปโทนสี HDR เป็น SDR ในโปรแกรมถอดรหัสที่เร่งด้วยฮาร์ดแวร์เริ่มต้นสำหรับโปรไฟล์ที่บันทึกไว้ กล่าวคือ หากอุปกรณ์จับภาพ HEVC HDR10+ ได้ ตัวถอดรหัส HEVC เริ่มต้นต้องถอดรหัสสตรีมที่บันทึกในรูปแบบ SDR ได้

ข้อกำหนดในการแก้ไข HDR

หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์วิดีโอที่รองรับการแก้ไข HDR อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• ควรใช้เวลาในการตอบสนองน้อยที่สุดในการสร้างข้อมูลเมตา HDR เมื่อไม่มีข้อมูลเมตา และควรจัดการสถานการณ์ที่มีข้อมูลเมตาสำหรับบางเฟรมและไม่มีข้อมูลเมตาสำหรับเฟรมอื่นๆ อย่างราบรื่น ข้อมูลเมตานี้ควรมีความแม่นยำ (เช่น แสดงระดับความสว่างสูงสุดจริงและฮิสโตแกรมของเฟรม)

หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนรหัสที่รองรับ FEATURE_HdrEditing โปรแกรมเปลี่ยนรหัสเหล่านั้นจะมีลักษณะดังนี้

• [C-7-1] ต้องรองรับโปรไฟล์ HDR อย่างน้อย 1 โปรไฟล์

• [C-7-2] ต้องรองรับ FEATURE_HdrEditing สำหรับโปรไฟล์ HDR ทั้งหมดที่ตัวแปลงรหัสนั้นโฆษณาไว้ กล่าวคือ ต้องรองรับการสร้างข้อมูลเมตา HDR เมื่อไม่มีข้อมูลเมตา HDR สำหรับโปรไฟล์ HDR ทั้งหมดที่รองรับ

• [C-7-3] ต้องรองรับรูปแบบอินพุตโปรแกรมเปลี่ยนไฟล์วิดีโอต่อไปนี้ซึ่งจะรักษาสัญญาณที่ถอดรหัส HDR ไว้อย่างสมบูรณ์

  • RGBA_1010102 (อยู่ในเส้นโค้งการโอนเป้าหมายอยู่แล้ว) สําหรับทั้งอินพุต ByteBuffer และ Surface และต้องโฆษณาการรองรับ COLOR_Format32bitABGR2101010

หากการติดตั้งใช้งานอุปกรณ์มีโค้ดที่รองรับ FEATURE_HdrEditing อุปกรณ์จะมีลักษณะดังนี้

• [C-7-4] ต้องโฆษณาการรองรับส่วนขยาย EXT_YUV_target OpenGL

6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป

6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับเครื่องมือสําหรับนักพัฒนาแอป Android ที่ระบุไว้ใน Android SDK

• Android Debug Bridge (adb)

  • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง dumpsys cmd stats
  • [C-0-11] ต้องรองรับคำสั่งเชลล์ cmd testharness การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันเก่าที่ไม่มีบล็อกข้อมูลที่ถาวรอาจได้รับการยกเว้นจาก C-0-11
  • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ของระบบอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
  • [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับcmd statsคำสั่งเชลล์และStatsManagerคลาส System API
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] ต้องมี Daemon ของ adb ฝั่งอุปกรณ์ที่ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
  • [C-0-5] MUST support secure adb. Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักซึ่งผ่านการตรวจสอบสิทธิ์
  • [C-0-6] ต้องระบุกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

  หากการติดตั้งใช้งานอุปกรณ์ที่ไม่มีพอร์ต USB รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์จะมีลักษณะดังนี้

  • [C-3-1] ต้องใช้ adb ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
  • [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 ซึ่งช่วยให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล ADB ได้

  หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต อุปกรณ์จะมีลักษณะดังนี้

  • [C-4-1] ต้องมีเมธอด AdbManager#isAdbWifiSupported() ที่แสดงผล true

  หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi หรืออีเทอร์เน็ต และมีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้

  • [C-5-1] ต้องมีเมธอด AdbManager#isAdbWifiQrSupported() return true

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุน ddms จึงควรปิดอยู่โดยค่าเริ่มต้น แต่จะต้องรองรับเมื่อใดก็ตามที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามที่ระบุไว้ข้างต้น

• SysTrace

  • [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดอยู่โดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace

• Perfetto

  • [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดง /system/bin/perfetto ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto
  • [C-SR-2] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เป็นอินพุตสำหรับการกําหนดค่า protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
  • [C-SR-3] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เพื่อเขียนร่องรอย protobuf ที่เป็นเอาต์พุต ซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
  • [C-SR-4] ขอแนะนําอย่างยิ่งให้ระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto

• Low Memory Killer

  • [C-0-12] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ลงในบันทึก statsd เมื่อแอปถูกสิ้นสุดโดย Low Memory Killer

• โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคําสั่งเชลล์ cmd testharness และ cmd testharness enable อุปกรณ์จะทําสิ่งต่อไปนี้

  • [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] ต้องใช้งานโหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบโหมดโปรแกรมทดสอบอัตโนมัติ

• ข้อมูลการทํางานของ GPU

  การติดตั้งใช้งานอุปกรณ์

  • [C-0-13] ต้องใช้คำสั่งเชลล์ dumpsys gpu --gpuwork เพื่อแสดงข้อมูลการทํางานของ GPU ที่รวบรวมไว้ซึ่งแสดงผลโดยจุดติดตามเคอร์เนล power/gpu_work_period หรือไม่แสดงข้อมูลหากระบบไม่รองรับจุดติดตาม การใช้งาน AOSP frameworks/native/services/gpuservice/gpuwork/

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านฟีเจอร์ Flag ของ android.hardware.vulkan.version อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้

• [C-1-1] ต้องระบุทางเลือกให้นักพัฒนาแอปเปิด/ปิดใช้เลเยอร์การแก้ไขข้อบกพร่อง GPU
• [C-1-2] ต้องระบุเลเยอร์ในไลบรารีที่ได้จากเครื่องมือภายนอก (ไม่ใช่แพ็กเกจแพลตฟอร์มหรือแอปพลิเคชัน) ซึ่งพบในไดเรกทอรีฐานของแอปพลิเคชันที่แก้ไขข้อบกพร่องได้เพื่อรองรับเมธอด vkEnumerateInstanceLayerProperties() และ vkCreateInstance() เมื่อเปิดใช้เลเยอร์การแก้ไขข้อบกพร่องของ GPU

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

Android รองรับให้นักพัฒนาแอปกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอป

การติดตั้งใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกของนักพัฒนาแอป โดยตัวเลือกดังกล่าวต้องมีลักษณะดังนี้

• [C-0-1] MUST honor the android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application development-related settings. การใช้งาน Android เวอร์ชันอัปสตรีมจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปไว้โดยค่าเริ่มต้น และเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปหลังจากที่กดรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์ 7 ครั้ง
• [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น
• [C-0-3] ต้องระบุกลไกที่ชัดเจนซึ่งไม่แสดง favoritism ต่อแอปของบุคคลที่สามแอปหนึ่งเมื่อเทียบกับแอปอื่นเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป ต้องแสดงเอกสารหรือเว็บไซต์ที่เข้าถึงได้แบบสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป เอกสารหรือเว็บไซต์นี้ต้องลิงก์ได้จากเอกสาร Android SDK
• ควรมีการแจ้งเตือนด้วยภาพอย่างต่อเนื่องแก่ผู้ใช้เมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปและมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้
• อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาแอปชั่วคราว โดยซ่อนหรือปิดใช้เมนูเพื่อไม่ให้ผู้ใช้เสียสมาธิในสถานการณ์ที่ผู้ใช้อาจไม่ปลอดภัย

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์บางอย่างที่มี API ที่เกี่ยวข้องสําหรับนักพัฒนาแอปบุคคลที่สาม ให้ทำดังนี้

• [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่ระบุว่าไม่บังคับ และการใช้งานอุปกรณ์ไม่มีคอมโพเนนต์ดังกล่าว ให้ทำดังนี้

• [C-0-2] คุณต้องยังแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับคอมโพเนนต์ API
• [C-0-3] ลักษณะการทํางานของ API ต้องติดตั้งใช้งานแบบ No-Ops ในลักษณะที่เหมาะสม
• [C-0-4] เมธอด API ต้องแสดงผลค่า Null ในกรณีที่เอกสารประกอบ SDK อนุญาต
• [C-0-5] เมธอด API ต้องแสดงผลการใช้งานคลาสแบบไม่มีการดำเนินการในกรณีที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
• [C-0-6] เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
• [C-0-7] การติดตั้งใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

ตัวอย่างทั่วไปของสถานการณ์ที่มีการใช้ข้อกำหนดเหล่านี้คือ API โทรศัพท์: แม้ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็ต้องติดตั้งใช้งาน API เหล่านี้แบบไม่มีการดำเนินการใดๆ ที่สมเหตุสมผล

7.1. การแสดงผลและกราฟิก

Android มีเครื่องมือที่ปรับชิ้นงานแอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติให้เหมาะสมกับอุปกรณ์ เพื่อให้แอปพลิเคชันของบุคคลที่สามทำงานได้ดีในการกำหนดค่าฮาร์ดแวร์ที่หลากหลายการแสดงผลและการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย จอแสดงผลที่เข้ากันได้กับ Android คือหน้าจอแสดงผลที่ใช้ลักษณะการทำงานและ API ทั้งหมดที่อธิบายไว้ในนักพัฒนาแอป Android - ภาพรวมความเข้ากันได้ของหน้าจอ ส่วนนี้ (7.1) และส่วนย่อย รวมถึงลักษณะการทำงานเพิ่มเติมที่เฉพาะเจาะจงสำหรับประเภทอุปกรณ์ที่ระบุไว้ในส่วนที่ 2 ของ CDD นี้ ในจอแสดงผลที่ใช้ได้กับ Android ซึ่งแอปพลิเคชันของบุคคลที่สามทั้งหมดที่ใช้ได้กับ Android สามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้จะกำหนดไว้ดังนี้

• ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้ามกัน 2 มุมของส่วนที่สว่างของจอแสดงผล
• ความหนาแน่นของจุดต่อนิ้ว (dpi) จํานวนพิกเซลที่ล้อมรอบด้วยช่วงแนวนอนหรือแนวตั้ง 1 นิ้วซึ่งแสดงเป็นพิกเซลต่อนิ้ว (ppi หรือ dpi) ในกรณีที่ระบุค่า dpi ppi และ dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วงที่ระบุ
• สัดส่วนภาพ อัตราส่วนของพิกเซลของขนาดที่ยาวกว่าต่อขนาดที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะเท่ากับ 854/480 = 1.779 หรือประมาณ "16:9"
• ความหนาแน่นของพิกเซลอิสระ (dp) หน่วย พิกเซลเสมือนที่ปรับให้เป็นหน้าจอ 160 dpi ความหนาแน่นของหน้าจอ 160 สำหรับความหนาแน่น d และจำนวนพิกเซล p จำนวนพิกเซลอิสระตามความหนาแน่น dp จะคำนวณได้ดังนี้ pixels = dps * (density/160) dp = (160 / d) * p

7.1.1. การกำหนดค่าหน้าจอ

7.1.1.1. ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลายขนาด และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ Configuration.screenLayout ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอพิกเซลอิสระจากความหนาแน่น (dp) เชิงตรรกะที่ถูกต้องดังต่อไปนี้

  • อุปกรณ์ที่มีการตั้งค่า Configuration.uiMode เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_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 ได้โดยมีมุมโค้งมน

หากการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอที่รองรับการกำหนดค่าขนาด และมีอุปกรณ์ที่ใช้งานร่วมกับ Android ได้ ใช้จอแสดงผลที่มีมุมมนเพื่อแสดงผลหน้าจอเหล่านี้ อุปกรณ์จะต้องมีคุณสมบัติดังนี้UI_MODE_TYPE_NORMAL

• [C-1-1] ต้องปฏิบัติตามข้อกำหนดข้อใดข้อหนึ่งต่อไปนี้เป็นอย่างน้อยสำหรับจอแสดงผลแต่ละรายการดังกล่าว

  • รัศมีของมุมมนน้อยกว่าหรือเท่ากับ 38 dp
  • เมื่อมีการยึดกล่อง 1518 dp คูณ 1518 dp ที่มุมแต่ละมุมของการแสดงผลเชิงตรรกะ ผู้ใช้จะเห็นอย่างน้อย 1 พิกเซลของกล่องแต่ละกล่องบนหน้าจอ

• ควรมีสิ่งต่างๆ ที่ผู้ใช้สามารถโต้ตอบด้วยเพื่อเปลี่ยนไปใช้โหมดการแสดงผลที่มีมุมสี่เหลี่ยมผืนผ้า

ดูรายละเอียดเกี่ยวกับการใช้ Sidecar หรือ Extension API อย่างถูกต้องได้จากเอกสารประกอบสาธารณะของ Window Manager Jetpack

7.1.1.3. ความหนาแน่นของหน้าจอ

เฟรมเวิร์ก UI ของ Android จะกำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยนักพัฒนาแอปกำหนดเป้าหมายทรัพยากรแอป

การติดตั้งใช้งานอุปกรณ์:

• [C-0-1] ค่าเริ่มต้นคือ การใช้งานอุปกรณ์ต้องรายงานค่าความหนาแน่นเฟรมเวิร์ก Android เพียงค่าเดียวที่แสดงอยู่ใน DisplayMetrics ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องเป็นค่าคงที่สำหรับจอแสดงผลจริงแต่ละจอ ต้องไม่เปลี่ยนแปลงไม่ว่าเมื่อใดก็ตาม อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่กำหนดเองที่แตกต่างกัน DisplayMetrics.density ตามความเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ซึ่งตั้งค่าไว้หลังจากการบูตครั้งแรก

หากการติดตั้งใช้งานอุปกรณ์ให้ มีความสามารถในการเปลี่ยนแปลงขนาดการแสดงผลของอุปกรณ์ อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ขนาดการแสดงผลต้องไม่ปรับขนาด ต้องไม่ปรับขนาดการแสดงผล ให้ใหญ่กว่า 1.5 เท่าของDENSITY_DEVICE_STABLE ความหนาแน่นของหน้าจอเริ่มต้น หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพเล็กกว่า 320dp (เทียบเท่าตัวระบุทรัพยากร sw320dp) แล้วแต่ว่าเงื่อนไขใดจะเกิดขึ้นก่อน
• [C-1-2] ขนาดการแสดงผลต้องไม่ปรับขนาด ต้องไม่ปรับขนาดการแสดงผล ให้เล็กกว่า 0.85 เท่าของDENSITY_DEVICE_STABLE ความหนาแน่นดั้งเดิม
• เราขอแนะนำให้ใช้การปรับขนาดตัวเลือกการแสดงโฆษณาเนทีฟต่อไปนี้ (โดยเป็นไปตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อให้ใช้งานได้ดีและมีขนาดแบบอักษรที่สอดคล้องกัน (
  • เล็ก: 0.85x
  • ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
  • ใหญ่: 1.15 เท่า
  • ใหญ่ขึ้น: 1.3 เท่า
  • ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่รองรับ Android หรือเอาต์พุตวิดีโอไปยังหน้าจอแสดงผลที่รองรับ Android อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริก Display ทั้งหมดที่เข้ากันได้กับ Android ซึ่งกำหนดไว้ใน android.util.DisplayMetrics API

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอที่ฝังหรือเอาต์พุตวิดีโอ อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่เข้ากันได้กับ Android ตามที่ระบุไว้ใน android.util.DisplayMetrics API สำหรับ view.Display เริ่มต้นที่จำลอง

7.1.3. การวางแนวหน้าจอ

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
• [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

หากการติดตั้งใช้งานอุปกรณ์รองรับการวางแนวหน้าจอทั้ง 2 แบบ อุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกตามแอปพลิเคชันเพื่อการวางแนวหน้าจอเป็นแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคําขอของแอปพลิเคชันเกี่ยวกับการวางแนวหน้าจอที่เฉพาะเจาะจง
• [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
• อาจเลือกการวางแนวเป็นแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API เดิม
• [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API เดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุไว้ว่ารองรับ

หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้

• [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุและอธิบายไว้ในเอกสารประกอบ Android SDK
• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
• ควรรองรับ OpenGL ES 3.2

การทดสอบ OpenGL ES dEQP จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/หมายเลขเวอร์ชันที่เชื่อมโยงกัน ซึ่งอยู่ในซอร์สโค้ดของ Android ที่ external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ OpenGL ES ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทดสอบ dEQP ในรายการทดสอบทั้งหมดตั้งแต่ระดับนี้และต่ำกว่า

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดเวอร์ชันหนึ่ง อุปกรณ์จะมีลักษณะดังนี้

• [C-2-1] ต้องรายงานผ่าน API ที่จัดการของ OpenGL ES และ API เดิมเกี่ยวกับส่วนขยาย OpenGL ES อื่นๆ ที่ใช้ และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
• [C-2-2] ต้องรองรับส่วนขยาย EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable และ EGL_ANDROID_GLES_layers
• [C-2-3] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ OpenGL ES ที่รองรับผ่าน Flag ฟีเจอร์ android.software.opengles.deqp.level
• [C-2-4] ต้องรองรับเวอร์ชัน 132383489 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2020) ตามที่รายงานใน Flag ฟีเจอร์ android.software.opengles.deqp.level
• [C-2-5] ต้องผ่านการทดสอบ dEQP ของ OpenGL ES ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 กับเวอร์ชันที่ระบุในฟีเจอร์ Flag android.software.opengles.deqp.level สำหรับ OpenGL ES แต่ละเวอร์ชันที่รองรับ
• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย EGL_KHR_partial_update และ OES_EGL_image_external

• ควรรายงานอย่างถูกต้องผ่านเมธอด getString() เกี่ยวกับรูปแบบการบีบอัดพื้นผิวที่รองรับ ซึ่งโดยทั่วไปจะเจาะจงตามผู้ให้บริการ

• ควรรองรับส่วนขยาย EGL_IMG_context_priority และ EGL_EXT_protected_content

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่สอดคล้องกันสำหรับเวอร์ชันเหล่านี้นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
• [C-SR-3] ขอแนะนําอย่างยิ่งให้รองรับส่วนขยาย OES_EGL_image_external_essl3

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 อุปกรณ์จะมีลักษณะดังนี้

• [C-4-1] ต้องรองรับ OpenGL ES Android Extension Pack โดยสมบูรณ์

หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES โดยสมบูรณ์ อุปกรณ์จะมีลักษณะดังนี้

• [C-5-1] ต้องระบุการรองรับผ่านandroid.hardware.opengles.aep Flag ฟีเจอร์

หากการติดตั้งใช้งานอุปกรณ์รองรับEGL_KHR_mutable_render_buffer ส่วนขยาย อุปกรณ์จะมีลักษณะดังนี้

• [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย

7.1.4.2 Vulkan

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะมีลักษณะดังนี้

• [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.3
• [C-4-1] ต้องไม่รองรับเวอร์ชันตัวแปรของ Vulkan (กล่าวคือ เวอร์ชันตัวแปรของ Vulkan ต้องเท่ากับ 0)

หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้

• [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.3

การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เกี่ยวข้อง ซึ่งอยู่ในซอร์สโค้ดของ Android ที่ external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ Vulkan ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทด�